agiles softwareanforderungs- management und …...auf. geben sie ihnen das umfeld und die...

www.siemens.com/polarion

Agiles Softwareanforderungs- management und Einhaltung gesetzlicher Bestimmungen: ein praxisnaher Live-Ansatz

Agile Methoden haben bereits bewiesen, dass sich mit ihnen die Erfolgsquoten von Projekten verbessern lassen, dennoch gibt es immer noch große, unberührte Bereiche, die es noch zu erkunden gilt. Zum Beispiel gilt es, die Frage zu klären, wie die Nachverfolgbarkeit von Informationen hinsichtlich Softwareanforderungsermittlung unterstützt werden kann, während gleichzeitig die Risiken der Nichteinhaltung von Branchenstandards und sonstigen regulato-rischen Anforderungen gesteuert werden, die mit der Anwendung agiler Methoden einher gehen? Dieser Leitfaden beschreibt den Live-Ansatz und wie durch die praktische Umsetzung und Weiterentwicklung agiler Methoden das Risiko für das Scheitern von Projekten erheblich reduziert und die Einhaltung gesetzlicher Bestimmungen verbessert werden kann.

White Paper ausgegeben von: Siemens PLM Software


White Paper | Agiles Softwareanforderungsmanagement und Einhaltung gesetzlicher Bestimmungen: ein praxisnaher Live-Ansatz

2

Inhalt

Kurzdarstellung ..............................................................3

Einführung .....................................................................4

Nutzenversprechen agiler Prinzipien .............................5

Die gängigsten agilen Methoden ...................................6

Agil bleiben: Ist das möglich? .........................................7

Das Rätsel um Agile: Anforderungen und Steuerung vs. Entwicklung ....................................................................7

Hochmoderne Softwareentwicklungstools ....................9

Die „schlechten alten Zeiten“: unterschiedliche Tools und Daten ..............................................................................9

Nutzenversprechen der heutigen modernen Tools ...........10

Das neue ALM ...............................................................10

Integration von Agile mit ALM .....................................11

Der Live-Ansatz ............................................................12

Richtlinien zum Live-Ansatz ............................................12

Richtlinie 1: Einziger übergeordneter Knoten ...................12

Leitfaden 2: Single-Source ..............................................12

Leitfaden 3: Einziges Repository .....................................12

Richtlinie 4: Individuelle Spezialisierungen der Work Item-Klasse ...........................................................................13

Richtlinie 5: Live-Funktionen ..........................................13

Richtlinie 6: Speicher .....................................................13

Live-Ebenen ..................................................................14

Live-Informationen ........................................................14

Verfügbarkeit der Informationen .................................15

Der Live-Ansatz und agile Entwicklung ........................17

Fazit .............................................................................18

Referenzen ...................................................................19



3

Kurzdarstellung

Agile Methoden haben sich aus den Einschränkungen des Wasserfallmodells heraus entwickelt – insbesondere die erst zum Abschluss eines Projekts sichtbar werdenden Ergebnisse und die zu späte Einbindung von Projektbeteiligten, was Testprozesse unnötigerweise hinauszögert, sind dabei als wesentliche Ursachen zu nennen. Aufgrund der starken Kundenorientierung und der Bemühungen, die Anforderungen der Kunden genau zu identifizieren, haben sich agile Methoden als Softwareentwicklungsansatz etabliert.

Stärken des traditionellen Wasserfallmodells sind grundsätz-lich in den genau definierten Planungsprozessen des plangesteuerten Modells zu sehen. Genaue Anforderungen, die Nachverfolgbarkeit, die Prüfbarkeit dieser Anforderungen sowie klar definierte Abnahmekriterien sind bei diesem Modell von zentraler Bedeutung. Außerdem liegen die Stärken dieses Modells in der Vergleichbarkeit und Wiederholbarkeit, die aus standardisierten Prozessen herrüh-ren. Das Wasserfallmodell wird grundsätzlich als das Entwicklungsmodell betrachtet, das die geringsten Risiken birgt, und wird daher gerne bei großen und langfristigen Softwareentwicklungsprojekte eingesetzt – insbesondere in Branchen mit Projekten oder Produkten, die mit Risiken für Leib und Leben oder für die Freiheit verbunden sind und durch staatliche Stellen überwacht werden.

In der Realität wird jedoch von keiner Organisation bloß ein einzelner bindender Ansatz verfolgt. Vielmehr kommen Mischformen aus Wasserfallmodell, Agile (Scrum, eXtreme Programming), Rational Unified Process (RUP), Spiralmodell oder andere Methoden zum Einsatz, um die Anforderungen der Projekte zu erfüllen und schließlich mit den Organisationen erfolgreich zu sein.

Um diese Mischformen an ihre Anforderungen anzupassen, ersetzen Organisationen ihre Legacy-Werkzeuge, die ineffizi-ent sind und Sperrbereiche schaffen, durch Application-Lifecycle-Management-Tools (ALM). Mit diesen webbasierten Tools, die über ein einheitliches Design verfü-gen und einfach zu individualisieren sind, können mehrere, sich ständig weiterentwickelnde Prozesse unterstützt werden.

In diesem White Paper wird beschrieben, wie die gängigsten Best Practices – insbesondere die praktische Umsetzung und Weiterentwicklung agiler Methoden – zu einer erheblichen Reduzierung von Entwicklungsrisiken im Hinblick auf die Einhaltung gesetzlicher Bestimmungen und erhöhte Projekterfolgsquoten beigetragen haben. Dieser Leitfaden wird im Folgenden als „Live-Ansatz“ bezeichnet, weil er auf hybriden Agile-Wasserfallmethoden aufbaut und mithilfe moderner ALM-Lösungen Daten bedarfsorientiert liefert.



4

Einführung

Es gilt als bewiesen, dass Mitarbeiter von F&E-Abteilungen in einem inspirierenden Umfeld zusammen arbeiten müssen und nur wenigen oder gar keinen Ablenkungen ausgesetzt sein dürfen, um mithilfe agiler Methoden überdurchschnitt-liche Leistungen zu erzielen.

Betrachten Sie als Beispiel den Ansatz, eXtreme Programming (XP)-Anforderungen („Anwendergeschichten“) zu sammeln. Demnach soll der Kunde (oder Benutzer) als integraler Bestandteil des Entwicklungsteams – und nicht einer externen Instanz – auf die Fragen der Entwickler in Echtzeit antworten. Allerdings ist dies in der Praxis nur schwer umzusetzen, weil der Kunde sehr häufig eine ganze Organisation mit Tausenden von über mehrere Länder verstreuten Mitarbeitern ist, bei dem komplexe Festlegungs- und Genehmigungsprozesse für seine Anforderungen vorherrschen.

Außerdem treffen agile Teams häufig zusammen, um zu beschließen, was innerhalb der nächsten Tagen oder sogar Stunden zu erreichen ist. Solche Best Practices können bei Managern und Führungskräften jedoch schnell zu Frustrationen führen. Denn diese brauchen langfristige Planungssicherheit und eine Möglichkeit zur strategischen Steuerung der Projektkosten. Sie brauchen Meilensteine und Ergebnisse und keine Zielsetzungen, die täglich neu bestimmt werden.

Der Live-Ansatz bietet Unternehmen ein Werkzeug zum Umgang mit Projektinformationen und schließlich zur Vereinbarung dieser gegensätzlichen und doch existenziel-len Anforderungen. Drei große Interessensbereiche rund um die agile Softwareentwicklung können von der Einführung von Tools profitieren, die den Live-Ansatz unterstützen: die Unternehmensführung, das Anforderungs- und das Projektmanagement. Sämtliche neuen Tools und Methoden müssen bei der F&E von Software Bereiche wie Software Requirements Engineering, Projektplanung und Unternehmenssteuerung unmittelbar berücksichtigen. Gleichzeit müssen F&E-Teams ihre Agilität beibehalten, ohne dass sie durch zusätzliche Arbeit oder Ablenkungen bei ihrer Arbeit beeinträchtigt werden.

Der Live-Ansatz ist mit Methoden wie XP, Scrum oder RUP nicht zu vergleichen. Er ist eher eine Sammlung von Richtlinien, mit denen das Ziel verfolgt wird, eine mögliche Roadmap für Softwareentwicklungsumgebungen und -tools festzulegen, die Unternehmen offen für unterschiedliche Entwicklungsmethoden mit einem höheren Grad an Benutzerfreundlichkeit zu machen und darüber hinaus „Live-“Informationen über Projektstatus zu erhalten.



5

Nutzenversprechen agiler Methoden

Agile Methoden haben bereits bewiesen, dass mit ihnen die Erfolgsquoten von Projekten verbessert werden können. Die verbreitete Anwendung einiger dieser Methoden – insbeson-dere XP, Dynamic Systems Development Method (DSDM) und Scrum – zeigt, dass die meisten Prinzipien des Agile-Manifests1 von Kunden und Entwicklern geschätzt werden.

Zum Beispiel schätzen Kunden folgende im Manifest enthal-tenen Äußerungen:

• „Unsere höchste Priorität ist, die Kundenanforderungen durch rechtzeitige und kontinuierliche Lieferung wertvol-ler Software zu befriedigen.“

• „Sich ändernde Anforderungen sind willkommen, sogar in späteren Entwicklungsphasen. Agile Prozesse nutzen gezielt Veränderungen, um dem Kunden einen Wettbewerbsvorteil zu verschaffen.“

• „Liefern Sie regelmäßig Arbeitssoftware – in Zyklen von einigen Wochen bis einigen Monaten – und legen Sie dabei den Schwerpunkt auf die kürzeren Zeiträume.“

Auf der anderen Seite werden auf Entwicklerseite eher folgende Aussagen geschätzt:

• „Bauen Sie Ihre Projekte rund um motivierte Mitarbeiter auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie Ihnen, dass sie ihre Arbeit erledigen.“

• „Agile Prozesse fördern nachhaltige Entwicklung“

• „Einfachheit – die Kunst, unerledigte Arbeit zu maximieren – ist dabei von zentraler Bedeutung.“

• „Die besten Architekturen, Anforderungen und Designs werden von Teams hervorgebracht, die sich selbst organisieren“



6

Lassen Sie mich kurz die am häufigsten verwendeten agilen Methoden beleuchten. Die wichtigsten Praktiken für die folgende Diskussion sind in den unten stehenden Punkten erläutert. Eine ausführlichere Erläuterung finden Sie unter Ökosysteme der agilen Softwareentwicklung2.

Dynamic System Development Method (DSDM)DSDM ist eine Weiterentwicklung und Erweiterung von Rapid Application Development-Praktiken (RAD). DSDM bietet im Vergleich zu jeder anderen agilen Methode die am besten unterstützten Schulungen und Dokumentationen. Die neun Prinzipien von DSDM umfassen die aktive Nutzereinbindung, häufige Lieferungen, zielgerichtete Entscheidungen im Team, integriertes Testing über den gesamten Projektlebenszyklus hinweg sowie reversible Änderungen bei der Entwicklung.

Extreme Programming (XP)XP predigt die Werte von Community, Einfachheit, Feedback und Mut. Wichtige Aspekte von XP sind, dass es dazu beige-tragen hat, eine Meinungsänderung in Bezug auf die Kosten in Zusammenhang mit den Veränderungen zu bewirken und dass dabei auf technische Kompetenz durch Refactoring und testgetriebene Entwicklung Wert gelegt wurde. XP bietet ein System dynamischer Praktiken, deren Integrität als ganzheit-liches System erwiesen wurde. Diesen Praktiken umfassen u. a. das tägliche Stand-Up-Meeting und die direkte Beteiligung des Kunden.

ScrumScrum bietet ein Projekt Management-Framework, das die Entwicklung in 30-tägige Sprintzyklen bündelt, in denen bestimmte Backlog Features geliefert werden. Das tägliche, 15-minütige Team-Meeting für Koordination und Integration zählt zur üblichen Praxis in Scrum. Scrum, das schon seit fast 10 Jahren im Einsatz ist, wird für die erfolgreiche Bereitstellung einer breiten Palette an Produkten verwendet.

Es wird deutlich, dass die gängigsten agilen Methoden völlig im Einklang mit den Agile-Schlüsselwerten sind:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge

• Funktionierende Software mehr als umfassende Dokumentation

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wich-tig finden, schätzen wir die Werte auf der linken Seite höher ein.“

Die gängigsten agilen Methoden



7

Die vorgenannten Agile-Werte sind jedoch nicht in jeder Umgebung anwendbar. Stellen Sie sich einfach ein internati-onales Unternehmen mit F&E Software vor, die über 3 Kontinente hinweg verteilt ist, und in dem die F&E für andere, auf der ganzen Welt verteilten Abteilungen der Organisation im Dienst ist.

Ist es möglich, den Kunden mit dem F&E-Team an einem Ort zusammenzubringen? Wie sieht es mit Prozessen, mehrspra-chigen Handbüchern, Unternehmens- und F&E-Budgets und Lieferung - plus Ressourcenplanung aus?

In Großunternehmen wird die Softwareentwicklung (u. a.) in zunehmendem Maße an Offshore-Betriebe und -Provider outgesourct, wodurch ein wachsender Bedarf in puncto Anforderungsspezifikation und Projektfortschrittskontrolle entsteht. In allen diesen Situationen ist Code nicht das einzige Produkt, das zu produzieren ist.

Diese Fakten (und vieles mehr) sind die Basis für die Entwicklung von Capability Maturity Model Integration (CMMI)3. Das Ziel von CMM bestand darin, die Qualität der Softwareentwicklung eines Software-F&E-Teams zu zertifi-zieren, wohingegen CMMI viel weitreichendere Geschäftsprozesse in einem Unternehmen, inkl. der Softwareentwicklung, zertifiziert. Ein weiterer sehr interes-santer Grund für den Wechsel von CMM zu CMMI ist die Notwendigkeit, Unternehmensprozesse und Konformität mit der Softwareentwicklung zu integrieren.

Angesichts dessen scheinen CMMI- und agile Methoden unvereinbar aufgrund des viel breiteren Anwendungsspektrums von CMMI gegenüber Agile zu sein.

Das Rätsel um Agile: Anforderungen und Steuerung vs. EntwicklungÜber die Jahre hinweg hat Siemens PLM Software groß angelegte Implementierungsprojekte durchgeführt, in denen wir damit beauftragt wurden, Agile Entwicklungsteams und das Verlangen des Unternehmens nach höherer Konformität mit CMMI zusammenzubringen. „Extreme Programming from a CMM Perspective“ behan-delte ebenfalls das Thema der Integration von XP und Scrum in CMM und stellte fest, dass es einige Bereiche in CMM gibt, die nicht im Anwendungsspektrum der betrachteten, agilen Methoden liegen. Solche nicht darin abgedeckten Bereiche umfassen die Prozess- und Projektsteuerung und die Überwachung und Kontrolle der Lieferanten.

Eine weitere interessante Perspektive ist die Kundenbeteiligung. Bei komplexen Systemen kann dieses Problem nicht durch Kundenpräsenz beim F&E-Team vor Ort gelöst werden, da formelle Anforderungen von Dutzenden oder gar Hunderten von Mitarbeitern gesammelt und wei-terentwickelt werden, die oftmals in allen Teilen der Welt verstreut sind. Agile Requirements, Methods and Tools 13.35 zufolge werden bei Arbeiten zur Festlegung von Anforderungen fast immer Dokumente produziert, die vom Autor an den Leser, wie beispielsweise vom Kunden an F&E, gerichtet sind und dann auf Eis gelegt werden - d. h. keine Unterstützung von Änderungsinitiativen - und dies steht in direktem Konflikt mit iterativen und änderungsgesteuerten, agilen Methoden. Agile Methoden erfordern des weiteren eine Zusammenstellung von Teams und ein hohes Fachwissen, und deshalb entspricht es nicht dem Agile-Prinzip, wenn Auftragnehmer bzw. outgesourcte Partner an anderen Standorten arbeiten.

Eine weitere interessante Tatsache: „Ungeachtet dessen, was viele Leute denken, trifft es nicht zu, dass agile Methoden ohne Artefakte sind, obwohl sie gewiss weniger dokumenta-tionslastig als traditionelle Verfahren sind. Dies ist immer noch ein Thema für Organisationen, für die CMMI die Basis für deren Bewertung ist.“ 6

Agil bleiben: Ist das möglich?



8

So können das Softwareanforderungsmanagement, genauso wie das Risikomanagement, die Einhaltung gesetzlicher Bestimmungen, Unternehmensführung und Projektmanagement-Fachbereiche tatsächlich durch die Einführung agiler Methoden in der F&E beeinträchtigt werden.

Die Antwort ist in einem der Prinzipien des Agile-Manifests zu finden:

„Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie Ihnen, dass sie ihre Arbeit erledigen.“

Dies könnten so interpretiert werden: „Geben Sie den Entwicklern ein Toolset, das in die weitreichenden Prozesse des Unternehmens komplett integriert ist, lassen Sie sie Remote zusammenarbeiten, als ob sie sich am gleichen Standort wie ihre Kunden aufhielten und lassen Sie ihre Arbeit nahtlos auditieren und kontrollieren.“

In der Praxis bedeutet dies, dass, während Entwickler in einer agilen Welt mithilfe von agilen Tools Software kodie-ren, andere Mitarbeiter im Unternehmen in der Lage sein müssen, Anforderungen zu definieren und weiterzuentwi-ckeln, Änderungen zu senden, Testfälle zu verwalten und den Projektstatus mithilfe ihrer bevorzugten Methoden und Tools nachzuverfolgen.

Ist dies realistisch? Bieten Tool-Anbieter etwas an, das dieses Bedürfnis anspricht?



9

Die Softwareentwicklung und ihre unterstützenden Umgebungen treten in ein historisches Zeitalter ein. Das eigentliche Nutzenversprechen der Tools folgt einem ziem-lich alten Konzept, dass mit einigen Ausnahmen stark im Wasserfallmodell verwurzelt ist.

Die „schlechten alten Zeiten“: unterschiedliche Tools und DatenDer Grund für unterschiedliche Tools und Daten ist in den letzten Erfolgen bei der Bereitstellung von Support in jeder Phase des Softwareentwicklungsprozesses zu suchen: an einem gewissen Zeitpunkt war klar, dass die Softwareentwicklungs-Community Versionsmanagement-Lösungen zur Unterstützung von Collaborative Programming („gemeinschaftliches Programmieren“) benötigte. Einige Zeit später wurde offensichtlich, dass Softwarearchitekten und deren Kunden neue Tools für die Anforderungsspezikation und -freigabe benötigten, um komplexe Beziehungen zwischen Kunde und Provider zu regeln. Die Liste lässt sich beliebig fortführen und umfasst Testmanagement, Änderungsanfragen und Weitergaben, Kunden-Support und andere Funktionen.

Hochmoderne Softwareentwicklungstools

Das Problem, das schnell entstand, war, dass mit jedem neuen Toolset, dass die Anbieter auf den Markt brachten, eine neue Insel der Automatisierung definiert wurde. Mit jeder dieser Inseln wurde tatsächlich ein neues Datenmodell, neue Zugriffsrichtlinien, ein neues Repository usw. definiert. Natürlich wurde bald mehr als deutlich, dass die in verschiedenen logischen Datenmodellen und Repositories gespeicherten Informationen integriert werden mussten. Aus diesem Grund fingen die Anbieter an, Brücken zu bauen, um die Inseln miteinander zu verbinden.

In vielen Fällen wurden Features, die zur Unterstützung eines Prozesses eingeführt wurden in einen anderen Prozess verlagert, um den Support bestimmter Informationen auszu-weiten. Nach diesen Verbesserungen starteten die Anbieter damit, Lösungen auf den Markt zu bringen, mit denen Versionsanforderungen, Änderungsanfragen in Verbindung mit dem Quellcode usw. unterstützt werden sollten.



10

Nutzenversprechen der heutigen modernen ToolsApplication Lifecycle Management ist das Nutzenversprechen auf dem Markt der modernen Softwareentwicklungstools. Aus der Perspektive der vorgenannten Geschichte der Softwareentwicklungstools betrachtet, stellt ALM die letzte zu erreichende Stufe auf der Leiter zur Integration der Inseln der Automatisierung dar. Egal was Analysten predigen mögen, werden traditionelle Anbieter mit Dinosaurier-Code niemals ALM erreichen, das sie aus wirtschaftlichen und ethischen Gründen nicht auf Nachzügler, die jährliche Wartungsgebühren zahlen, verzichten können. Traditionelle Anbieter reagieren auf die Entwicklung in Richtung ALM, indem sie versuchen, Ihren Kunden teure, unzuverlässige Einmal-Integrationen zwischen Tools unterschiedlicher Anbieter zur Verfügung zu stellen. Dieses Maß an Aufwand, den sie betreiben, ist nichts weiter als ein einfacher Datenaustausch zwischen Tools, unvereinbar mit den Agile-Prinzipien und für den Live-Ansatz nicht zu empfehlen.

Testpläne-Insel

Projektplan-Insel

Anforderungs-Insel

Code-Insel

Das neue ALMBei näherer Betrachtungsweise der neuen ALM-Nutzenversprechen ergeben sich folgende, gemeinsame Charakteristika: ALM-Lösungen verfolgen das Ziel, breitgefä-chert zu sein, mit einem breiten Anwendungsspektrum von Funktionen und Support für mehrere Projektrollen und intensiven und umfangreichen Support für die Funktionen, die von der jeweiligen Projektrolle benötigt werden.

Mit den ALM-Lösungen werden fast immer interessante Leitfaden oder gar vollständig Methoden zur Unterstützung der Softwareentwicklung mitgeliefert. Methoden und Tools sind natürlich integriert. Was Kunden von ALM-Lösungen erwarten können ist Integration (sowie Detailliertheit und Vielseitigkeit).

Neben der Integration erwarten Kunden Unternehmenssteuerung, Risiko- und Compliance Management, die vollständige Nachverfolgung des Projektfortschritts und projektspezifische Kostenkontrolle über verteilte Teams. Warum nicht? Ein wahres ALM-System ist einheitlich, mit konsolidierten, verknüpften Daten und Work Items, die mit Suchanfragen problemlos gefunden und in den Standardberichten der Organisation dargestellt werden können, ohne auf Entwickler, zusätzliche IT oder Auftragnehmer zurückgreifen zu müssen.

Abschließend bieten ALM-Lösungen einen breitgefächerten Support für Mitarbeiter, die verschiedene Rollen in der Softwareentwicklung abdecken, ein umfassendes Set von Funktionen für jede dieser Rollen und integrierte Funktionalitäten zur Überbrückung der Informationsinseln, die von den verschiedenen Tools erzeugt werden, die die Software Suites beinhalten.



11

Das IT-Forschungs- und Beratungsunternehmen Gartner ist sich einig, dass Agile ALM für das Erzielen optimaler Ergebnisse integrieren sollte. In deren Veröffentlichung „Key Issues for ALM“ (Schlüsselfragen zu ALM) erklärt Gartner: „Projekte, die agile Methoden implementieren und geogra-fisch verteilte Projekte - in denen Anwendungen von weltweit agierenden Teams erstellt und verwaltet werden, und komplexe Prozess- und Produktentwicklungssituationen vorhanden sind - profitieren alle von einem effektiveren ALM.“ Ein Hybridprozess ermöglicht Ihnen die benötigte Flexibilität und Sie profitieren dabei von größerer Kontrolle.

Auch wenn solche ALM-Lösungen von vielen Unternehmen weitgehend in die Praxis umgesetzt wurden, finden sie bei agilen Teams aus verschiedenen Gründen wenig Anklang:

• Integrierte Tools, die ihre „integrierten“ Methoden unter-stützen, werden als nicht förderlich für eine agile Kultur wahrgenommen.

• Bei der agilen Entwicklung laufen alle Aktivitäten parallel. Integrationen älterer ALM-Tools beinhalten den Batch-Transport von Informationen von einem Repository in ein anderes (Brücken zwischen Inseln), wodurch das sofortige Mitteilen von Zustandsänderungen verhindert wird.

• ALM-Lösungen unterstützen verschiedene Rollen mit verschiedenen Tools in verschiedenen Prozessen. In agilen Prozessen werden Teams dazu angehalten, im gleichen Raum zu arbeiten sowie das gleiche Tool und die gleiche Methode zu verwenden.

• Einer der am meisten geschätzten Vorteile agiler Methoden ist die Austauschbarkeit der Mitarbeiter. ALM stützt sich mehr auf die Spezialisierung der Projektrolle.

Der Live-Ansatz kann das Problem der Integration agiler Entwicklungsteams in eine breitgefächerte Unternehmensinfrastruktur lösen, indem den Entwicklern der Live-Zugriff auf weitreichende Unternehmensinformationen über die Tools verfügbar gemacht wird, die sie bevorzugt verwenden (verwenden müssen).

Zusammenfassend ist folgendes bis jetzt erörtert worden:

1. Die Verwendung agiler Methoden in der Softwareentwicklung bringt zufriedenstellende Ergebnisse.

2. Das Isolieren agiler Teams gestaltet sich in vielen Situationen als ziemlich schwierig: sie sind oftmals Teil breitgefächerter und ganz und gar nicht agiler Unternehmensprozesse.

3. Verfügbare Softwareentwicklungstools sind für agile Teams unzureichend, die sie in weitreichende Unternehmensprozesse wie beispielsweise Risiko- oder Compliance Management eingebunden sein müssen.

Integration von Agile mit ALM 11



12

Der Live-Ansatz von Siemens PLM Software besteht aus einer Reihe Richtlinien und Systematiken. Mit diesen Richtlinien wird eine neue Philosophie für das Verwalten von Softwareentwicklungsartefakten und entwicklungsspezifi-schen Informationen vorgestellt. Aus diesen Richtlinien leiten sich eine Reihe von Systematik definierende Kriterien ab, um den Grad der praktischen Umsetzung des Live-Ansatzes in Entwicklungsumgebungen und -Tools zu überprüfen.

Leitfaden zum Live-AnsatzDie Richtlinien zum Live-Ansatz (nachstehend Live-Richtlinien genannt) lassen sich in zwei Hauptbereiche unterteilen:

1. In Bezug auf Live-Daten: Informationsmodell und Speicher (Richtlinien 1 bis 4)

2. In Bezug auf Datenverfügbarkeit: die Art und Weise des Zugriffs auf Live-Daten und die Art und Weise der Offenlegung dieser Daten

Richtlinie 1: Einziger übergeordneter KnotenDie Klasse der Work Items (Arbeitspositionen) ist der gemeinsame, übergeordnete Knoten in einer Vererbungshierarchie aller Informationen und Artefakte, die mit den Entwicklungsaktivitäten verbunden sind. Seine Instanzen werden als Work Items bezeichnet.

Salopp gesagt: nach dieser Richtlinie sind alle zu erzeugen-den Artefakte und alle im Softwarelebenszyklus durchzuführende Aktivitäten (wie beispielsweise Anforderungen, Änderungsanfragen, Tasks und Testpläne) Work Items. Dies bedeutet, dass alles, was während der Softwareentwicklung gemanagt wird, von den Anforderungen bis hin zum Code, in die Instanz der Work Item-Klasse fällt.

Richtlinie 2: Single-SourceDie Instanzen der Work Item-Klasse und die Instanzen aller ihrer Spezialisierungen sind „Single Source“, d. h. alle Projektdaten existieren nur einmal in der Entwicklungsumgebung. Stellen Sie sich als Beispiel einen Testplan vor, der während der Anforderungsspezifikation erstellt wurde. Es muss der gleiche Testplan sein, der mit den Anforderungen, die ihn generiert haben, und mit den festgestellten Fehlern während der Testausführung ver-knüpft ist (niemals eine Kopie davon).

Richtlinie 3: Einziges RepositoryDas Repository, in dem die Work Items gespeichert sind, sollte logisch eindeutig sein. Das bedeutet nicht notwendi-gerweise, dass nur ein einziges Repository vorhanden sein darf, sondern es muss aus Benutzersicht eindeutig sein.

Es ist zwar theoretisch möglich, ein logisch eindeutiges Repository auf mehrere integrierte Repositories zu bauen, aber diese Methode wird nicht empfohlen, da sie wahr-scheinlich zu einer Situation führt, die mit dem Bau von Brücken zwischen den Inseln der Automatisierung vergleich-bar ist. Es gilt einige Ausnahmen zu berücksichtigen; z. B. zur Unterstützung von Skalierungsanforderungen können mehrere Repositories eine bessere Leistung bei Spiegelung, Load Balancing, Remote-Replikation usw. bieten.

Der Live-Ansatz

Anforderung Testfall

Anforderung Fehler

Anforderung Fehler

Task

Deckt ab

Bezieht sich auf

Hängt ab von

Implementiert

Bezieht sich auf

DuplikateÜbergeordne-tes Element

Übergeordn. Elem.



13

Richtlinie 4: Individuelle Spezialisierungen der Work Item-KlasseBenutzer können ihre eigenen Spezialisierungen der Work Item-Klasse entsprechend ihrer Unternehmens- oder Projektanforderungen definieren. Beispiele können mehr oder weniger folgendes sein: „Anforderung“, „Änderungsanfrage“, „Task“, „Quelldatei“, „Codeänderungsprotokoll“, aber auch „Kundenauftrag“ oder alles, was für die Organisation oder für ein einzelnes Projekt Sinn ergibt. Die Informationen, die in den Spezialisierungen der Work Item-Klasse und der Work Item-Klasse selbst gespeichert werden, lassen sich individuell anpassen.

Richtlinie 5: Live-FunktionenEine Funktion ist Live, wenn es sich dabei um eine Operation handelt, die für jede Instanz der Work Item-Klasse und deren Spezialisierungen anwendbar ist. Mit anderen Worten ist eine Funktion dann Live, wenn sie auf alle Work Items angewendet werden kann.

Als ein nützliches Beispiel dient die Operation „Fortschrittsanzeige“, die üblicherweise auf eine Task ange-wendet wird, um den Fortschritt dieser zu erfahren. Weitet man diese Funktion auf eine „Live-Fortschrittsanzeige“ aus, kann sie auf alle Work Items angewandt werden: auf diese Weise ist es möglich, den aktuellen Fortschritt auf einem Testplan, einer Anforderungsspezifikation, auf einer Änderungsanfrage usw. zu erhalten.

Es sollte bereits deutlich geworden sein, dass je mehr Live-Funktionen es gibt und es je leistungsfähiger sie in einer bestimmten Lifecycle-Management-Lösung sind, um so mehr profitiert der Benutzer davon.

Das Schaffen neuer Live-Funktionen sollte für die Provider vertikaler Tools anregend sein: bis dato entwickelten sie Funktionen für eine bestimmte Phase des Softwarelebenszyklus und/oder für eine bestimmte Rolle in der Entwicklungskette weiter; und nun sollen sie eine Vorstellung entwickeln, wie diese Funktionen so erweitert werden können, dass sie sich für jede Rolle in jeder Phase der Softwareentwicklung als wertvoll erweisen.

Betrachten Sie als weiteres Beispiel den Vorteil von Live-Wirkungsanalysen Das heißt, die aktuelle anforderungsorientierte Link-Navigation, die Sie benötigen, um die von einer Änderung betroffenen Anforderungen zu finden, wurde so verbessert, dass Sie mehr Navigationsmöglichkeiten haben, um alle von den Änderung betroffenen Bereitstellungsartefakte und Aktivitäten zu finden. Die Durchführung einer Live-Wirkungsanalyse wird den Benutzer somit in die Lage versetzen, alle Aktivitäten, die zur Implementierung einer Anforderung erfolgten, deren Kosten, die Beteiligten, alle zu ändernden Artefakte (wie z. B. Quellcode und Benutzerhandbücher) plus schlussendlich die Auswirkungen der praktischen Umsetzung der Änderung auf die Projektplanergebnisse zu bestimmten Meilensteinen zu finden.

Richtlinie 6: OffenlegungBei der Verwendung von Live-Funktionen zum Zugriff auf Work Items, sollten die resultierenden Informationen so offengelegt werden, dass es für jede einzelne Benutzerrolle angemessen ist. Das bedeutet, dass Live-Funktionen für verschiedene Benutzerrollen im bevorzugten Format und mit den speziellen von den Benutzern gewünschten Inhalten zur Verfügung stehen sollen. Projektmanager möchten z. B. Zugriff auf Projektfortschrittsinformationen in einem Planformat, leitende Manager dagegen möchten nur die kritischen Pfade bei der Erreichung von Meilensteinen in einem Dashboard zusammengefasst sehen, wohingegen Entwickler die ihnen zugewiesenen Aufgaben und ihre Termine direkt in ihrer Integrated Development Environment (IDE) angezeigt haben wollen.

Es wird deutlich, dass jede Entwicklungsumgebung mit diesen Richtlinien auf einer unterschiedlichen Ebene an einem bestimmten Zeitpunkt konform sein kann.

Gleiche Daten – unterschiedliche Ansichten



14

Live-EbenenDieses Kapitel behandelt die Compliance-Systematik des Live-Ansatzes. Die Systematik enthält eine Reihe von Kriterien, nach denen jede Entwicklungsumgebung (d. h. jede Art von Entwicklungsinfrastruktur und Zugriffs-Toolset) geprüft wird, um die Ebene der Konformität mit dem Live-Ansatz festzustellen: derlei Konformitätsebenen werden nachstehend Live-Ebenen genannt.

Die Systematik enthält fünf Live-Ebenen. Die letzte Ebene liefert vollständige Konformität mit allen Richtlinien und zusätzlich eine Reihe von Live-Funktionen, die für jede unterschiedliche Benutzerrolle korrekt offengelegt sind. Obwohl die letzte Ebene für den Endzustand stehen sollte, den jedes Toolset am Ende der Revolution der Entwicklungstools erreichen soll, werden die Zwischenebenen 1 bis 4 als „Karte“ definiert, um diesen Zustand zu erreichen. Diese Zwischenebenen sollten Unternehmen dabei unterstützen, den eigentlichen Grad des Supports für den Live-Ansatz anhand ihrer Entwicklungsinfrastruktur zu beurteilen und weitere Schritte zur Verbesserung anregen, so dass ein Sprung in die nächst höhere Ebene erfolgen kann.

Die fünf Live-Ebenen sind:

• Ebene 1 - Basis

• Ebene 2 - Verbindung

• Ebene 3 - Verschmelzung

• Ebene 4 - Kontrolle

• Ebene 5 - Steuerung

Jede Ebene enthält Kriterien zur Bewertung der Konformität der Softwareentwicklungsumgebung mit den Live-Richtlinien. Jede Ebene erweitert die Kriterien der vorigen Ebene. Im weiteren Verlauf werden die Kriterien erörtert und die Live-Richtlinien in ihre beiden Bereiche getrennt: Live-Informationen und Verfügbarkeit der Informationen

Basis Live-Suche

Verbindung Live-Aufspüren

Kontrolle Live-Plan

Verschmelzung Live-Nachverfolgen

Steuern Live-Dashboard

Live-InformationenDieses Kapitel stellt die Kriterien vor, mit denen der Konformitätsgrad der Softwareentwicklungsumgebung anhand den Live-Richtlinien 1 bis 4 bewertet werden soll. Daher werden diese Kriterien mit der Art und Weise ver-knüpft, wie die Informationen organisiert sind: Datenmodell und Speicher.

1. Basis-Ebene. In dieser Ebene muss Richtlinie 1 (einzig übergeordneter Knoten) und Richtlinie 2 (Single-Source) unterstützt werden. So wird die Work Item-Klasse als der einzige übergeordnete Knoten definiert und alle ihre Instanzen und Nachfolgeinstanzen sind „Single-Source“ (aus einer Quelle).

2. Verbindungsebene. Work Items werden durch Links miteinander verbunden. Links müssen verschiedene Verbindungstypen entsprechend den Link-Rollen unterstützen. So können z. B. Work Items mit „Containment“-Links bzw. „Impact“-Links verbunden werden.

3. Verschmelzungsebene. In dieser Ebene wird Richtlinie 3 (Einziges Repository) unterstützt: Work Items werden in einem einzigen, logischen Repository gespeichert. Daneben muss das Repository folgendes unterstützen: Versions- und Verlaufsmanagement von Work Items und Links plus Work Item-Workflow-Management mit Status, Übergängen, den damit Beauftragten und Benutzerbenachrichtungs-Mechanismen über die neuesten Statusänderungen. Schlussendlich muss der Zugriff auf das Repository sicher sein.

4. Kontrollebene. Work Items speichern Informationen in Bezug auf Zeit, Priorität und Kosten, unterstützende Gespräche und Genehmigungen ab. Beachten Sie, dass die Zeit-, Kosten und Prioritätsinformationen inhaltsreich sind: dabei kann es sich handeln um den geschätzten Zeitaufwand bis zur Fertigstellung, den geplanten Beginn, das geplante Ende, zugewiesene Projektmeilensteine, geschätzte Kosten, Istkosten, Mehrwert, Priorität, Schweregrad usw.

5. Steuerungsebene. In der letzten Ebene wird Richtlinie 4 (Individuelle Spezialisierungen der Work Item-Klasse) unterstützt. Link-Typen sind auch benutzerdefiniert. Auf diese Weise können Work Item-Typen, Inhalte und Verbindungen auf der Grundlage von Benutzer-, Projekt- und Unternehmensanforderungen individuell angepasst werden. Informationen in puncto Risiken, Ressourcen und Finanzmanagement sind auch enthalten.



15

Dieses Kapitel stellt die Kriterien vor, mit denen der Konformitätsgrad einer Softwareentwicklungsumgebung anhand den Live-Richtlinien 5 bis 6 bewertet werden soll. Daher werden diese Kriterien mit der Art und Weise ver-knüpft, wie die Informationen verwaltet werden: Funktionen und deren Offenlegung.

Die Live-Funktionen, die auf jeder Ebene hinzuzufügen sind, lauten:

1. Basis-Ebene. Live-Suche: Durch jedes Attribut kann nach Work Items gesucht werden.

2. Verbindungsebene. Live-Aufspüren: Work Items unter-stützen Navigation auf Rollenbasis sowie Wirkungs- und Nachverfolgbarkeitsanalysen.

3. Verschmelzungsebene. Live-Nachverfolgen: erweitertes Lebenszyklusmanagement für die Work Items.

4. Kontrollebene. Live-Plan über Projektplanungs und -fortschritt: dort sind alle Work Items oder die zu ausgewählten Spezialisierungen der Work Item-Klasse zugehörigen Work Items in einem Plan aufgeführt, der sich von selbst aktualisiert. Dies bedeutet, dass der Plan automatisch aus den in den Work Items gespeicherten Informationen (wie z. B. Prioritäten, Schweregrade und Abhängigkeiten) erstellt und infolge etwaiger Änderungen an den geplanten Work Items neu erstellt wird.

5. Steuerungsebene. Live-Dashboard: zur Steuerung jeder Projektaktivität in Echtzeit. Das Dashboard ist auch in der Lage, Multiprojektmanagement-Informationen wie z. B. Ressourcen-Workload und projektübergreifende Code-Wiederverwendung anzuzeigen.

In jeder Ebene müssen die Live-Funktionen den Benutzer mit Informationen im entsprechenden Format für die Benutzerrolle versorgen. Im Ansatz der „Insel der Automation“ gibt es nur rollenspezifische Informationen, die im entsprechenden Format für die Benutzer zur Verfügung stehen, die eine Rolle einnehmen. Im Live-Ansatz stehen sämtliche Informationen für alle Benutzer im gewünschten Format zur Verfügung.

Verfügbarkeit der Informationen

Ebene Live-Informationen Verfügbarkeit der Informationen

Ebene 1 - Basis Die Work Item-Klasse wird als der einzige übergeordnete Knoten definiert und alle ihre Instanzen und Nachfolgeinstanzen sind „Single-Source“ (aus einer Quelle).

Live-Suche

Ebene 2 - Verbindung Work Items werden durch eingegebene Links miteinander verbunden.

Live-Aufspüren

Ebene 3 - Verschmelzung Work Items sind in der gleich versionierten Umgebung enthalten, die Änderungen und Workflow-Management unterstützt.

Live-Nachverfolgen

Ebene 4 - Kontrolle Work Items speichern Informationen in Bezug auf Zeit und Kosten

Live-Plan

Ebene 5 - Steuerung Work Item-Typen, -Inhalte und -Verbindungen können individuell angepasst werden.

Live-Dashboard

Die Tabelle fasst die Kriterien für die Konformität der Live-Ebenen zusammen.



16

Betrachten Sie Projektleiter, die mit Projektplänen und Gantt-Diagrammen arbeiten. Um einen Überblick über den Status ihrer Projekte erhalten zu können, müssen sie sich mit in Office-Dokumenten enthaltenen Anforderungen, Problemen in Verfolgungs-Tools und mit in Versionierungssystemen gespeichertem Code herumschla-gen. Mit dem Live-Ansatz steht der aktuelle Status aller Work Items (d.h. der Status ihres Projekts) direkt für sie im Planformat zur Verfügung.

Die Informationen, die durch die Live-Funktionen in jeder Ebene geliefert werden, müssen jedem Benutzer zur Verfügung stehen. Wenn somit die Ergebnisse einer Live-Suche in Live-Ebene 1 jedem Benutzer durch eine einzige Web-Schnittstelle zur Verfügung gestellt werden können, werden auf der Live-Ebene 4 unterschiedliche Benutzer den Live-Plan auf verschiedene Art nutzen: Entwickler berichten ihren Fortschritt in ihre IDEs, Projektleiter ordnen die Prioritäten auf einem Gantt-Diagramm an, und Führungskräfte schauen sich die Geldausgaben in einer Tabelle an, in der sie ihre Budgets neu anpassen können.



17

Der Live-Ansatz kann problemlos zur Überbrückung der Kluft zwischen agilen (im F&E-Team) und formalen (außerhalb von F&E) Prozessen mithilfe von Tools überbrückt werden, die Live-Projektinformationen ab Live-Ebene 4 liefern, wie im vorigen Kapitel erläutert wurde.

Auf Live-Ebene 4 z. B. existieren Anforderungen, Tasks, Projektmeilensteine und Projektkosteninformationen sowie Änderungsanfragen, Testpläne, Funktionen, Quellcodes, Builds usw. alle als Single-Source in einem versionierten, völlig nachvollziehbaren und workflow-orientierten Repository. Zusätzlich stehen alle für die jeweilige Unternehmens- oder Projektrolle relevanten Informationen im bevorzugten Format der Rolle zur Verfügung.

Beispiel: Komplexe AnforderungseinführungVorausgesetzt, die passenden Tools des Live-Ansatzes ste-hen zur Verfügung, kann beispielsweise eine komplexe Anforderungseinführungsphase mit Weiterentwicklung und verschiedenen Genehmigungsstufen im Kundenunternehmen in Atlanta mittels Office-Dokumenten in der gleichen Umgebung durchgeführt werden, in der der Projektmanager in München die Tasks, Prioritäten und Meilensteine in einem Gantt-Format spezifiziert und in der das Entwicklungsteam in Delhi seine Artefakte und Fortschritte mit agilen Methoden nachverfolgt.

Beim Übergang auf Live-Ebene 5 werden geografisch ver-streute Teams die Unternehmensleitung in San Francisco nahtlos mit detaillierten Informationen zu Verzögerungen, Engpässen, Kosten und Risiken versorgen können.

Der Live-Ansatz und Agile Entwicklung



18

Agile Methoden, die eine Art Ablehnung aller der in den letzten Jahrzehnten zur Herstellung von Software aufgebau-ten Infrastrukturen von Methoden und Tools repräsentieren, haben einen neuen, erfolgreichen und „freien“ Weg zur Programmierung eines funktionierenden Codes definiert. Agile Methoden sind leider nicht immer praktisch anwend-bar aufgrund von Risiko-Management, Compliance Management oder prozessorientierten Umgebungen größe-rer und verstreuterer Unternehmen.

Agil zu bleiben in Software-F&E-Abteilungen und Unternehmensanforderungen immer noch zu erfüllen, ist möglich dank einer neuen Kategorie von Softwareentwicklungstools, die tatsächlich bereits den Markt erobert und sich schnell in Unternehmen etabliert hat, die bereits in die in diesem Dokument beschriebene

Verlegenheit kamen: bewährte Agile Softwareentwicklungsmethoden innerhalb eines breiter gefächerten (weniger oder nicht agilen) Unternehmenskontext anwenden zu müssen. Ein Beispiel eines solchen Tools ist Polarion® ALM von Siemens PLM Software, das aktuell auf der Ebene 5 in der Live-Ebenen-Systematik zu finden ist.

Dass nun die Vermischung der Vorteile agiler Softwareentwicklung mit formelleren Anforderungsmanagement-, Planungs- und Steuerungsmethoden des Live-Ansatzes möglich ist, eröffnet eine neue Richtung für zukünftige Forschungen bei der Schaffung vertikaler Live-Methoden zur Unterstützung der Anforderungen verschiedener Geschäftsbereiche.

Fazit

Problem- und

Risikomanage-ment

Audits und Metriken, Berichte

Wiederverwen-dungs- und

Verteilungsma-nagement

Anforde-rungsmanage-

mentBuild- und

Release-Ma-nagement

Agiles/hybri-des

Projektma-nagement

Test- und

Qualitätsma-nagement

Ände-rungs- und Konfigura-tions-Ma-nagement

Planungs- und

Ressour-cen-Manage-

ment

Zusammen-arbeit

Verfolgbarkeit Workflow



19

1. Manifesto for Agile Software Development [Manifest für Agile Softwareentwicklung], http://agilemanifesto.org

2. J. Highsmith, Agile Software Development Ecosystems, Pearson Education, 2002

3. CMMI, http://www.sei.cmu.edu/cmmi/4. M. Paulk, „Extreme Programming from a CMM Perspective,“ IEEE

Software 18.6. 20015. R. Davies, Agile Requirements, Methods and Tools 13.3. 20056. D. Kane, S. Ornburn, „Agile Development: Weed or Wildflower?“

InformIT, 31 Aug. 2002

Referenzen



20

Polarion® ALM™Die einheitliche Application Lifecycle Management-Lösung.

Verbinden Sie Teams und Projekte und verbessern Sie die Prozesse Ihrer Anwendungsentwicklung mit einer einzelnen, einheitlichen Lösung für Anforderungen, Coding, Testing und Release.

Polarion® Requirements™Komplette Softwareanforderungsmanagement-Lösung

Sammeln, verfassen, genehmigen und verwalten Sie Softwareanforderungen für komplexe Systeme entlang der gesamten Projektlebenszyklen.

Polarion® QA™Komplette Test- und Qualitätsmanagement-Lösung

Entwerfen, koordinieren und protokollieren Sie Ihre sämtli-chen Testmanagement-Aktivitäten in einer einzigen, kollaborativen QA-Umgebung.

Hauptfunktion

Softwareanforderungs-Management

Änderungs- und Konfigurations-Management

Problem- und Risikomanagement

Agiles/hybrides Projektmanagement

Variantenmanagement

Metriken und Berichte

Test- und Qualitätsmanagement

Planungs- und Ressourcen-Management

Wiederverwendungs- und Verteilungsmanagement

Build- und Release-Management

PLM-ALM-Integration

Polarion® ALM Polarion® QA Polarion® Requirements

Polarion® Reviewer™

– Reviewen/G

enehmigen

Polarion® Pro™ – N

ur Tasks

Add-on - Funktionalität mit separater Lizenz

Volle Funktionalität



21

www.siemens.com/plm© 2017 Siemens Product Lifecycle Management Software Inc. Siemens und das Siemens-Logo sind eingetragene Marken der Siemens AG. ALM, D-Cubed, Femap, Fibersim, Geolus, GO PLM, I-deas, Insight, JT, NX, Parasolid, Polarion, Solid Edge, Syncrofit, Teamcenter und Tecnomatix sind Marken oder eingetragene Marken der Siemens Product Lifecycle Management Software Inc. oder ihrer Niederlassungen in den USA und in anderen Ländern. (Je nach Dokument: Automotive SPICE ist eine Marke oder eingetragene Marke des Verbands der Automobilindustrie e.V. MATLAB ist eine Marke oder eingetragene Marke von The MathWorks, Inc. Microsoft Office ist eine Marke oder eingetragene Marke von Microsoft Corporation.) Alle anderen Logos, Marken, eingetragenen Marken oder Dienstleistungsmarken sind Eigentum der jeweiligen Inhaber.60680-A6 9/17 o2e

Über Siemens PLM SoftwareSiemens PLM Software ist eine Business Unit der Siemens Digital Factory Division. Der führende, weltweit agierende Anbieter von Software-Lösungen für die digitale Transformation in der Industrie bietet Herstellern neue Möglichkeiten, Innovationen umzusetzen. Siemens PLM Software mit Hauptsitz in Plano, Texas, und mehr als 140.000 Kunden in aller Welt arbeitet eng mit Unternehmen jeder Größe zusammen, um die Art und Weise zu verändern, wie Ideen realisiert, Produkte und Anlagen entwickelt und sinnvoll eingesetzt werden. Weitere Informationen über die Produkte und Leistungen von Siemens PLM Software unter www.siemens.com/plm.

Über den AutorDr. Stefano Rizzo ist Produktmanager und Visionär bei Siemens PLM Software. Er verfügt über 18 Jahre Erfahrung im Bereich IT und Beratung in verschiedenen Geschäftsbereichen, darunter Finanzen, Telekommunikation, Software und öffentliche Verwaltung. Als Berater hat er Dutzende von Großunternehmen bei der Einführung neuer Entwicklungsprozesse und -verfahren unterstützt. Als Lehrer hat er Tausende von Mitarbeiter in ULM, Anforderungsmanagement und Agile-Entwicklung geschult. Als ein Methodenverfechter hat er Hunderten von Unternehmen dahingehend unterstützt, seine Visionen über gemeinschaftliche Softwareentwicklung zu teilen. Sein aktueller Fokus liegt auf der Forschung und Entwicklung von Methoden und Best Practices für Agile- und Live-Softwareentwicklungsprozesse.

Siemens PLM Software

DeutschlandSiemens Industry Software GmbH Franz-Geuer-Straße 10 50823 Köln Tel. +49 221 20802-0

SchweizSiemens Industry Software AG Freilagerstrasse 40 8047 Zürich Tel. +41 44 755 72 72 [email protected]

ÖsterreichSiemens Industry Software GmbH Wolfgang-Pauli-Straße 2 4020 Linz Tel. +43 732 37 75 50 [email protected]

HauptsitzGranite Park One 5800 Granite Parkway Suite 600 Plano, TX 75024 USA +1 972 987 3000

agiles softwareanforderungs- management und …...auf. geben sie ihnen das umfeld und die...

Documents