PDF 1,3 MB - beim Arbeitskreis Requirements
PDF 1,3 MB - beim Arbeitskreis Requirements
PDF 1,3 MB - beim Arbeitskreis Requirements
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Gesellschaft für Informatik e.V.<br />
<strong>Arbeitskreis</strong> <strong>Requirements</strong><br />
20.03.2006<br />
Thomas Bauer, Peli Service GmbH:<br />
Überblick über Begriffe, Methoden und<br />
Standards des <strong>Requirements</strong> Management<br />
20. März 2006, Thomas Bauer, Seite 1
Abstract<br />
Wie für alle anerkannten Fachgebiete gibt es auch für das <strong>Requirements</strong><br />
Management eine klare Definition, typischerweise eingesetzte Methoden sowie<br />
Fachbegriffe, welche der Kommunikation zwischen den Anforderungsingenieuren<br />
zu Grunde liegen.<br />
Der Vortrag gibt einen Überblick über die Disziplin "<strong>Requirements</strong> Management".<br />
Es wird der Begriff <strong>Requirements</strong> Management definiert und in die umgebenden<br />
Disziplinen eingeordnet sowie wichtige Fachbegriffe, Abläufe, Konzepte und<br />
Methoden aus diesem Gebiet erläutert.<br />
Themen:<br />
- Betrachtung von Grundbegriffen<br />
- welche RM-Methoden werden eingesetzt ?<br />
- Schlüsselfaktoren im <strong>Requirements</strong> Management<br />
- Standards zum SW-Lebenszyklus und <strong>Requirements</strong> Management<br />
- Product Life Cycle Management und Vorgehensmodelle<br />
20. März 2006, Thomas Bauer, Seite 2
Das Unternehmen<br />
Firmensitz<br />
20. März 2006, Thomas Bauer, Seite 3
Unternehmensdaten<br />
Firmensitz Niederlassung Gründung<br />
Hartstraße 54<br />
82210 Germering<br />
www.peli-gmbh.de<br />
www.peli gmbh.de<br />
Carl-Schurz-Straße 17<br />
28209 Bremen<br />
1979<br />
20. März 2006, Thomas Bauer, Seite 4
Produkte und Dienstleistungen<br />
plus<br />
FOB<br />
• Programmpaket für die Realisierung von<br />
Forderungen und Forderungsmanagement<br />
• Front Office Banking - IT System für alle<br />
Geschäftsprozesse von Banken und Sparkassen<br />
• Integrierte Warenwirtschaftssysteme<br />
für Presse, Buch & Convenience<br />
• Business-Software für den Fachgroßhandel<br />
mit offener Kommunikationsschnittstelle<br />
Referenzen: CC Bank, KSK Göppingen, Falter, VALORA, Börner, HEW,<br />
Interrent Europcar, Hansen u.a.<br />
20. März 2006, Thomas Bauer, Seite 5
zur Person<br />
Diplominformatiker Thomas Bauer<br />
Studium: Fachhochschule München<br />
Abteilungsleiter bei der Fa. Peli Service GmbH seit 1995<br />
Profil: www.diplominformatiker-thomas-bauer.de<br />
Kernaufgaben:<br />
Personalführung<br />
Projektleitung<br />
Systemanalyse, Anforderungsmanagement<br />
Erstellung Feinkonzepte<br />
Datenmodellierung, Softwarearchitektur<br />
Leitung / Durchführung Anwendungsentwicklung<br />
Qualitätssicherung<br />
Kommunikation mit den Kunden<br />
20. März 2006, Thomas Bauer, Seite 6
Die Anforderung<br />
Bedürfnisse und<br />
Einschränkungen<br />
in den gegebenen<br />
Prozessen bei Kunde<br />
und Lieferant<br />
Prozess<br />
Kosten, Durchlaufzeit, Marketing,<br />
Organisation, Dokumentation,<br />
gesetzliche Vorgaben, Standards<br />
Vertrieb und Verteilung<br />
Randbedingungen<br />
des späteren Projektes<br />
Benutzersicht<br />
(Nutzen, für den, der zahlt)<br />
Benutzerschnittstelle<br />
Anwendungsfälle<br />
Dienstleistungen<br />
Anforderung<br />
funktional<br />
Entwicklungssicht<br />
Architektur<br />
Lastbalancierung<br />
Stromversorgung<br />
Eigenschaft, Bedingung, Fähigkeit,<br />
Beschränkung, Bedürfnis, Nutzen<br />
Produkt<br />
nichtfunktional<br />
(Qualitätsattribute)<br />
Benutzersicht<br />
(Nutzen für den, der zahlt)<br />
Antwortzeiten<br />
Zuverlässigkeit<br />
Benutzbarkeit<br />
Entwicklungssicht<br />
Testbarkeit<br />
Wartbarkeit<br />
Bibliotheken<br />
Werkzeuge<br />
in der Regel gut verifizierbar und validierbar in der Regel schwer belegbar,<br />
daß (nicht) erfüllt<br />
20. März 2006, Thomas Bauer, Seite 7
Anforderung und Lösung<br />
unscharfer<br />
Problemraum<br />
Prozess<br />
Anforderung<br />
eingeengter<br />
Lösungsraum<br />
Produkt<br />
Lastenheft<br />
Lösung<br />
funktional nichtfunktional<br />
(Qualitätsattribute)<br />
Lösungsspezifikation,<br />
Pflichtenheft, Design<br />
Softwareeigenschaften<br />
konkrete Eigenschaften<br />
Vermischung<br />
führt zu Strukturbruch<br />
(z.B.<br />
Endanwender<br />
definiert Design)<br />
was braucht der Benutzer, um sein Ziel unter<br />
den gegebenen Beschränkungen zu erreichen ?<br />
20. März 2006, Thomas Bauer, Seite 8
Prozessfähigkeit<br />
wie sie kommuniziert<br />
und trainiert werden<br />
ist heute<br />
vielfach Forderung<br />
an Lieferanten<br />
im System- und<br />
Softwarebereich<br />
Prüfung erfolgt über<br />
Reifegradmodelle, welche<br />
Zielvorgaben definieren.<br />
Bewertet wird, wie die<br />
Prozesse gelebt werden<br />
ob sie auch in<br />
Grenzsituationen und<br />
Feuerwehreinsätzen<br />
gelebt werden<br />
Prozessfähigkeit<br />
z.B. Capability<br />
Maturity* Model<br />
(CMM)<br />
Software-CMM<br />
für RM z.B. lauten die Zielvorgaben:<br />
Anforderungen müssen erfaßt<br />
und kontrolliert werden.<br />
Projektpläne müssen darauf<br />
abgestimmt werden.<br />
Änderungen der Anforderungen<br />
müssen kontrolliert erfolgen und<br />
nach Akzeptanz in den Projektergebnissen<br />
nachgezogen werden<br />
integriertes<br />
CMM (CMMI)<br />
Bewertung der Prozessfähigkeit<br />
in mehrstufiger Skala von<br />
"nicht vorhanden" bis<br />
"kontinuierlich optimierend"<br />
* mature = with fully<br />
developed powers<br />
of body and mind,<br />
duly careful and<br />
adequate, ripe,<br />
adult (Concise<br />
Oxford Dict.)<br />
20. März 2006, Thomas Bauer, Seite 9
<strong>Requirements</strong> Management<br />
wird zum Projektmanagement<br />
zugeordnet und gehorcht<br />
auch primär den Gesetzmäßigkeiten<br />
dieser Disziplin<br />
nicht<br />
realistisch<br />
notwendig<br />
sinnvoll<br />
standardisiertes<br />
RM<br />
professionelles<br />
RM<br />
ohne Projekt sind Anforderungen<br />
nur Visionen/Wünsche<br />
Anforderungen existieren<br />
nur im Kontext eines Projektes<br />
primär Projektbezug<br />
<strong>Requirements</strong><br />
Management<br />
definierte RM-Prozesse<br />
für bestimmte eingeschränkte<br />
Projektgruppen<br />
(z.B. Produktion von Produktlinien<br />
und Varianten davon)<br />
Zweck<br />
Ziel<br />
Einverständnis<br />
zwischen Kunde und<br />
dem Softwareprojekt<br />
(=Lieferant) erzielen<br />
ist eine Disziplin innerhalb des<br />
Software-Engineering, die sich<br />
mit den gewünschten Eigenschaften<br />
und den Beschränkungen<br />
von Softwaresystemen<br />
befaßt<br />
qualitative gute<br />
(nicht perfekte !)<br />
Anforderungen zu<br />
generieren<br />
Projektstart<br />
mit akzeptablem<br />
Risiko<br />
20. März 2006, Thomas Bauer, Seite 10
RM als Querschnittsprozess<br />
Fragestellungen im Bezug<br />
auf das frühe Marketing,<br />
das Produktmanagement,<br />
der Angebotserstellung,<br />
der Projektplanung,<br />
der Projektausführung,<br />
Implementierung, Test<br />
Wartung<br />
RM betrachtet<br />
SW-Produkt<br />
Dienstleistung<br />
Umgebung, in welcher<br />
das System einmal<br />
arbeiten soll<br />
RM muss nicht nur die Ziel des<br />
Softwaresystems präzisieren,<br />
sondern auch dessen Umgebung<br />
RM betrachtet als Querschnittsprozess<br />
die Fragestellungen der Ziele und der<br />
Zielerreichung eines Software-Systems<br />
Einplatzsystem<br />
Mehrplatzumgebung<br />
Online-Umgebung<br />
gemischtes<br />
HW-/SW-System<br />
eingebettetes<br />
System<br />
20. März 2006, Thomas Bauer, Seite 11
Vision und Wartung ?<br />
Fragen, die das letzte<br />
Glied in der Entwicklungskette<br />
betreffen, sind<br />
plötzlich ganz vorne<br />
Wartung<br />
wie lange<br />
wird die<br />
Laufzeit sein ?<br />
Vision<br />
welche Varianten wird<br />
es geben, werden<br />
sich entwickeln ?<br />
jedes Produkt/Projekt<br />
hat (mind. :-)) eine<br />
jedes Produkt/Projekt<br />
sollte eine abgestimmte<br />
haben, die allen<br />
Beteiligten bekannt ist<br />
die Vision macht transparent, was anders<br />
sein wird, wenn das Produkt fertig ist.<br />
wie wird sich das System<br />
nach dem ersten Release<br />
weiterentwickeln ?<br />
was wiederum die Basis<br />
ist für lebenswichtige<br />
Überlegungen<br />
ist das System<br />
die Investition Wert ?<br />
20. März 2006, Thomas Bauer, Seite 12
Problem und Lösung<br />
problemorientierte<br />
Disziplin<br />
übergeordnete Fragestellungen<br />
(Marketing, Produktmanagement,<br />
Psychologie)<br />
Betrachtung der Ziele<br />
im Gesamtkontext<br />
des späteren<br />
Systems<br />
der Personen, welche<br />
Nutzen aus dem<br />
späteren System ziehen<br />
<strong>Requirements</strong><br />
Management<br />
der gegebenen<br />
Beschränkungen<br />
RM ist ein<br />
Schlüsselprozess des<br />
Software Engineering<br />
bzw. des<br />
System Engineering<br />
Funktionen<br />
lösungsorientierte<br />
Disziplin<br />
enge Bindung zum<br />
Software Engineering<br />
Softwareanforderungen<br />
Qualitätsziele<br />
Lastenheft Pflichtenheft<br />
20. März 2006, Thomas Bauer, Seite 13<br />
...
systematische Vorgehensweise<br />
<strong>Requirements</strong> Management ist die<br />
systematische Vorgehensweise, um:<br />
zu definieren<br />
zu analysieren<br />
Prozessanforderungen<br />
funktionale Anforderungen<br />
nichtfunktionale Anforderungen<br />
zu vereinbaren und einem<br />
Projekt zuzuweisen<br />
Ermittlung Analyse Vereinbarung<br />
zu spezifizieren<br />
Spezifikation / Verifikation<br />
im Projekt zu verfolgen und Änderungen zu vereinbaren<br />
Verfolgungs- / Änderungsmanagement<br />
20. März 2006, Thomas Bauer, Seite 14
Kernaufgabe des RM<br />
Überwindung der<br />
inhärenten Unsicherheit<br />
der Anforderungen<br />
Kernaufgabe<br />
des RM<br />
Management der<br />
verbleibenden<br />
Unsicherheit der<br />
Anforderungen<br />
20. März 2006, Thomas Bauer, Seite 15
Begriffe der Anforderungsanalyse (1)<br />
Prinzip:<br />
z.B. Objektorientierung oder iterative Entwicklung<br />
Grundlegende Regeln, die als gegeben gesetzt sind. Regeln von sehr genereller Natur.<br />
Methode:<br />
z.B. OOA<br />
Vom Prinzip abgeleitet. Verfeinert das Prinzip. Spezifiziert Prozeduren und Techniken,<br />
z.B eine Vorgehensweise, wie Objekte aus den Gegenständen des Anwendungsbereiches<br />
extrahiert werden können. In der Praxis sieht man sich einem großem<br />
Methodenbaukasten gegenüber (angefangen bei Top-Down bzw. Bottum-Up) und muss<br />
permanent entscheiden, welche Methode aktuell sinnvoll einsetzbar ist. Jede Methode<br />
ist besser als ad-hoc, weil sie den Ingenieur zwingt, strukturiert und diszipliniert zu<br />
arbeiten.<br />
Prinzip<br />
Prozess Modell<br />
Methode<br />
Konzept Notation<br />
Werkzeug<br />
20. März 2006, Thomas Bauer, Seite 16
Begriffe der Anforderungsanalyse (2)<br />
Konzept:<br />
z.B. Objekt, Klasse<br />
Erlaubt eine Sache aus einer bestimmten oder verschiedenen Perspektiven zu<br />
modellieren. Konzepte bilden Bestandteile von Methoden.<br />
Notation:<br />
z.B. UML<br />
Eine Menge von Symbolen, die es erlauben, ein oder mehrere Konzepte zu repräsentieren<br />
Prozess:<br />
z.B. Anforderungsanalyse<br />
Definierte Abfolge von Tätigkeiten. In Prozessen werden Methoden und Konzepte<br />
umgesetzt. Im Projekt sind die Prozesse in der Regel definiert.<br />
Prinzip<br />
Methode<br />
Konzept Notation<br />
Werkzeug<br />
Prozess Modell<br />
20. März 2006, Thomas Bauer, Seite 17
Begriffe der Anforderungsanalyse (3)<br />
Modell:<br />
z.B. Analysemodell<br />
Abstrakte Repräsentation einer realen Sache. Ziel ist es, einen bestimmen Aspekt der<br />
Realität vereinfacht darzustellen (unter Vernachlässigung anderer Aspekte derselben<br />
Realität). Beispiele: Graphik, mathematische Symbolik, verbale Beschreibung. Ein<br />
Modell ist das Ergebnis des Einsatzes einer Methode und häufig stark mit dieser<br />
gekoppelt. Modelle beschreiben z.B. einen Datenfluss zwischen zwei Verarbeitungsschritten,<br />
die Folge von Prozessschritten in einem Workflow etc.<br />
Werkzeuge:<br />
Bieten automatisierte Unterstützung bei der praktischen Arbeit mit Prozessen,<br />
Methoden, Konzepten und Notationen. Gute Werkzeuge forcieren den Einsatz einer<br />
Methode und erzwingen den korrekten Umgang mit einer Notation, verbessern die<br />
Produktivität der Entwickler und machen<br />
Prinzip<br />
Prozess Modell<br />
die Modelle und Spezifikationen wartbar.<br />
Methode<br />
Konzept Notation<br />
Werkzeug<br />
20. März 2006, Thomas Bauer, Seite 18
Projekterfolgsfaktoren<br />
Mitarbeit des<br />
Kunden / Benutzers<br />
Projekterfolgsfaktoren<br />
(Stanley 2003)<br />
Unterstützung<br />
durch das<br />
Management klare<br />
Anforderungen<br />
realistische<br />
Annahmen<br />
genaue und<br />
realistische Planung<br />
20. März 2006, Thomas Bauer, Seite 19
Einsatz von Vorgehensweisen<br />
Einsatz von<br />
Vorgehensweisen<br />
(Stanley 2003)<br />
sequentielles Wasserfallmodell: 40%<br />
evolutionäre und iterative<br />
Vorgehensmodelle: 40%<br />
keine: 5%<br />
bei Projekten<br />
> 2 Jahre<br />
dominierend<br />
weitere Zahlen:<br />
=> 33% haben keinerlei RM-Methodik, 29% sprechen von einer ausreichenden Methodik<br />
und zugehöriger Technik.<br />
=> 30% verwenden OOA<br />
=> 50% aller Befragten verwenden UML<br />
=> 51% sammeln ihren Anforderungen rein informell (Text). Nur wenige nutzen formale<br />
Techniken.<br />
20. März 2006, Thomas Bauer, Seite 20
Einsatz von Methoden des RM<br />
Strukturiertes Entity-Relationship-Model<br />
Strukturierte Systemanalyse & Design-Methodik<br />
Strukturierte Anforderungsdefinition<br />
Strukturierte Analyse und Desgin<br />
Seite 26<br />
Objektorientierte Analyse<br />
Keine<br />
Grafik aus Christof Ebert, Systematisches <strong>Requirements</strong> Management, dpunkt.verlag<br />
0 5 10 15 20 25 30 35<br />
20. März 2006, Thomas Bauer, Seite 21
Einsatz von Techniken des RM<br />
Szenarios und Use-Cases<br />
Fokusgruppen<br />
Informelle Modellierung<br />
Halbformale Modellierung<br />
Kooperative Sammlung von Anforderungen<br />
Joint Application Desgin<br />
Benutzerzentrierte Entwicklung<br />
Wegwerf-Prototypen<br />
Data-Mining<br />
Seite 26<br />
Interviews<br />
Evolutionär, Designer as Apprentice<br />
Soft System Methods<br />
Andere<br />
Protokollanalyse<br />
Quality Function Development<br />
Formale Modellierung<br />
Grafik aus Christof Ebert, Systematisches <strong>Requirements</strong> Management, dpunkt.verlag<br />
0 10 20 30 40 50 60<br />
20. März 2006, Thomas Bauer, Seite 22
Wichtigste Risiken <strong>beim</strong> RM<br />
Anforderungen werden<br />
nicht oder nur unzureichend<br />
geprüft / inspiziert<br />
Beschreibung von<br />
Anforderungen als<br />
Entwurf ("Wie" anstatt<br />
"Was")<br />
unkontrollierte<br />
Änderung der<br />
Anforderungen<br />
Folge: nicht<br />
akzeptiertes<br />
Produkt<br />
Ansprechpartner<br />
sind nicht die<br />
eigentlichen<br />
Endbenutzer<br />
Perfektionierung von<br />
Anforderungen und<br />
Spezifikationen<br />
wichtigste<br />
Risiken <strong>beim</strong><br />
RM<br />
Endbenutzer ist nicht<br />
ausreichend eingebunden<br />
keine kontinuierlichen Konsultationen<br />
(z.B. zum nächsten<br />
Projektreview werden Kataloge<br />
von abzustimmenden Punkten<br />
gesammelt)<br />
der Business<br />
Case ist nicht<br />
ausreichend klar<br />
kritischen<br />
Anforderungen<br />
werden übersehen<br />
nur funktionale<br />
Anforderungen<br />
werden berücksichtigt<br />
etwas, was im<br />
Zusammenhang<br />
mit dem erhofften<br />
Nutzen wichtig ist,<br />
wurde nicht berücksichtigt<br />
Prozessanforderungen<br />
?<br />
nicht-funktionale<br />
Anforderungen ?<br />
Reflektion, ob Anforderung<br />
korrekt formuliert ist,<br />
erfolgt spät<br />
offen Punkte, Fragen<br />
können nicht sofort<br />
geklärt werden<br />
20. März 2006, Thomas Bauer, Seite 23
RM – worauf kommt es an<br />
Tester<br />
Systemanalysten<br />
Anforderungen müssen<br />
geprüft / inspiziert und<br />
ggf. präzisiert oder<br />
erweitert werden<br />
trenne Anforderung<br />
vom Entwurf<br />
Anforderungen<br />
beschreiben, was<br />
geliefert werden muß<br />
WAS ?<br />
Produktmanager<br />
Projektmanager<br />
der Entwurf<br />
beschreibt den<br />
Lösungsansatz<br />
WIE ?<br />
Lastenheft Pflichtenheft<br />
Konzentration auf das,<br />
was gewünscht bzw.<br />
gefordert ist und dies<br />
ausreichend präzisieren<br />
vermeide Überspezifikation<br />
RM – worauf<br />
kommt es an<br />
Business Case<br />
des Kunden<br />
verstehen<br />
alle Anforderungen<br />
berücksichtigen<br />
vertraglich fixieren,<br />
was der Kunde<br />
wünscht<br />
was will der Kunde<br />
anders machen, wenn<br />
er das Produkt hat?<br />
welche Funktionen<br />
bzw. Anorderungen<br />
werden großen<br />
Nutzen bringen?<br />
Prozessanforderungen<br />
?<br />
nicht-funktionale<br />
Anforderungen ?<br />
funktionale<br />
Anforderungen<br />
20. März 2006, Thomas Bauer, Seite 24
RM – worauf kommt es an (2)<br />
Rückwärtsplanung:<br />
ab wann dürfen wir<br />
keine Änderungen<br />
mehr bekommen, wenn<br />
wir rechtzeitig fertig<br />
sein wollen?<br />
Änderung der<br />
Anforderungen<br />
kontrollieren<br />
Änderungsrate<br />
überwachen und<br />
mit Projektdauer<br />
reduzieren<br />
Puffer für<br />
Änderungsanforderungen<br />
einplanen<br />
RM – worauf<br />
kommt es an<br />
Diskussion von<br />
Änderungsanforderungen<br />
nur, wenn<br />
Einflussanalyse<br />
erfolgt ist<br />
je weiter das Projekt,<br />
desto höher die<br />
Zugangsbarriere für<br />
Änderungsanforderungen<br />
Reflektion,<br />
ob korrekt<br />
verstanden<br />
Kunde / Endbenutzer<br />
einbeziehen<br />
klar geregelte und<br />
dosierte Kunden-<br />
mitarbeit<br />
kontinuierliche<br />
Abstimmung<br />
offen Punkte,<br />
Fragen<br />
wenn nicht möglich:<br />
Kunde muss klar<br />
gemacht werden,<br />
wie präzise seine<br />
Anforderungen<br />
dann geliefert<br />
werden müssen<br />
ist der Ansprechpartner<br />
auch der Endbenutzer?<br />
20. März 2006, Thomas Bauer, Seite 25
Standards zum SW-Lebenszyklus<br />
ISO 15504<br />
Norm für Prozesse<br />
und Assessments<br />
nutzt<br />
ISO/IEC 15288<br />
System Life<br />
Cycle Processes<br />
CMMI und ISO 11504 stellen<br />
jeweils einen Rahmen<br />
für die IT-Entwicklung<br />
gemäß ISO 9000 / 9001<br />
Standards zum<br />
Software-<br />
Lebenszyklus<br />
nutzt<br />
CMMI<br />
integriertes Capability<br />
Maturity Model<br />
ISO/IEC/IEEE 12207<br />
Standard für Software<br />
Life Cycle Processes<br />
Beispiel für<br />
Konkretisierung<br />
IEEE 1220<br />
Standard for Application<br />
and Management of the<br />
Systems Engineering Process<br />
20. März 2006, Thomas Bauer, Seite 26
CMM / CMMI<br />
CMM = Capability Maturity Model (von SEI = Software Engineering<br />
Institute)<br />
CMMI = integriertes CMM<br />
Das Modell beschreibt einen Satz von aufeinander abgestimmten Best<br />
Practices für den gesamten Lebenszyklus der Software von der<br />
Konzeption bis zur Lieferung.<br />
Die Elemente sind individuell einführbar und unabhängig von der<br />
eingesetzten Methodik, von der Projektgröße, von der Produktart und<br />
von der Unternehmensart.<br />
CMMI definiert keinen Prozess, sondern ist ein Prozessmodell. CMMI<br />
adressiert dabei nicht nur die Entwicklungsprojekte, sondern auch die<br />
projektbezogenen Aufgaben der Organisation (z.B. Bereitstellung von<br />
Ressourcen, Durchführung von Trainingsmaßnahmen).<br />
Zusätzliche Info zu CMMI u.a.: wikipedia oder http://www.kneuper.de/Cmmi/cmmi-ueberblick.html<br />
20. März 2006, Thomas Bauer, Seite 27
CMM / CMMI<br />
Für jedes Prozessgebiet, definiert CMMI die Anforderungen jeweils in<br />
Form eines Bündels von Best Practices, die (sofern gemeinsam<br />
durchgeführt) Ziele erfüllen, die für eine Verbesserung auf diesem<br />
Gebiet wichtig sind.<br />
Beispiel: <strong>beim</strong> Prozessgebiet "Projektplanung"<br />
sind die Ziele<br />
"Schätzungen aufstellen",<br />
"Einen Projektplan entwickeln"<br />
"Verpflichtung auf den Plan herbeiführen".<br />
Die Praktiken zum Ziel "Schätzungen aufstellen"<br />
"Umfang des Projekts schätzen",<br />
" Attribute der Arbeitsergebnisse und Aufgaben schätzen",<br />
"Projektlebenzyklus definieren"<br />
"Schätzungen von Aufwand und Kosten aufstellen".<br />
CMMI adressiert auch die Institutionalisierung der Prozesse, also den<br />
Grad, wie die Prozesse in der täglichen Arbeit gelebt und auch in<br />
Stressphasen eingehalten werden. Dazu sind in CMMI zu den<br />
einzelnen Prozessgebieten auch Praktiken beschrieben zur<br />
Umsetzung der Institutionalisierung.<br />
20. März 2006, Thomas Bauer, Seite 28
CMMI-Fähigkeitsgrade<br />
5<br />
4<br />
3<br />
2<br />
1<br />
0<br />
Fähigkeitsgrad (Capability Level)<br />
(Betrachtung pro Prozessbereich !)<br />
Managed<br />
Performed<br />
Incomplete<br />
Optimized<br />
Quantitatively<br />
Managed<br />
Defined<br />
.<br />
der Prozess wird mit den Daten aus der<br />
statistischen Prozesskontrolle verbessert<br />
der Prozess steht unter statistischer<br />
Prozesskontrolle<br />
der Prozess wird auf Basis eines angepassten<br />
Standard-Prozesses gemanagt<br />
und verbessert<br />
der Prozess wird gemanagt<br />
die spezifischen Ziele des Prozessgebiets<br />
werden erreicht<br />
Ausgangszustand, keine Anforderungen<br />
20. März 2006, Thomas Bauer, Seite 29
CMMI-Reifegrade<br />
5<br />
4<br />
3<br />
2<br />
1<br />
Reifegrade (Maturity Levels).<br />
Umfassen eine Menge von Prozessgebieten,<br />
die zu einem bestimmten Fähigkeitsgrad<br />
umgesetzt sein müssen.<br />
Quantitativ<br />
geführt<br />
Definiert<br />
Geführt<br />
Ad hoc<br />
Qualitativ<br />
geführt<br />
kontinuierlicheVerbesserung<br />
Prozessabstimmung<br />
Produkt komplett<br />
unter<br />
Kontrolle<br />
Prozessmessung<br />
Vereinbarungen<br />
werden gehalten<br />
Prozessbeschreibung<br />
wiederholbare Ergebnisse<br />
aber starke<br />
Abweichungen<br />
Managementgrundsätze<br />
unzuverlässig bezüglich<br />
Kosten, Termin<br />
und Qualität<br />
Prozessoptimierung<br />
mit den Daten aus<br />
der statistischen<br />
Prozesskontrolle<br />
statistische Prozesskontrolle<br />
wird<br />
durchgeführt<br />
Projektdurchführung<br />
gemäß Standard-<br />
Prozess, kontinuierl.<br />
Prozessverbesserung<br />
Gemanagte Projekte.<br />
Ähnliche Projekt<br />
können erfolgreich<br />
wiederholt werden<br />
Kein oder nur sehr<br />
informeller Prozess<br />
vorhanden<br />
Prozessgebiete, für welche CMMI die Anforderungen jw.<br />
in Form eines Bündels von Best Practices definiert, die<br />
(sofern gemeinsam durchgeführt) Ziele erfüllen, die für<br />
eine Verbesserung auf diesem Gebiet wichtig sind<br />
Organisationsweite .<br />
Innovation und Verbreitung,<br />
Ursachenanalyse und Problemlösung.<br />
Performanz der organisationsweiten Prozesse, quantitatives<br />
Projektmanagement<br />
Anforderungsentwicklung, technische Umsetzung,<br />
Produktintegration, Verifikation, Validierung, Prozessfokus,<br />
Prozessdefinition, Training, integriertes Projektmanagement,<br />
Risikomanagement, Entscheidungsanalyse und –findung<br />
Anforderungsmanagement, Projektplanung,<br />
Projektverfolgung und –steuerung, Management von<br />
Lieferantenvereinbarungen, Messung und Analyse,<br />
Qualitätssicherung, Konfigurationsmanagement.<br />
20. März 2006, Thomas Bauer, Seite 30
weiteres zu CMMI<br />
RM ist zudem in<br />
verschiedenen weiteren<br />
Prozessbereichen eingebettet<br />
Ebene 2<br />
Vereinbarung und<br />
Management von<br />
Anforderungen<br />
RM<br />
Ebene 3<br />
Entwicklung von Anforderungen<br />
Zuweisung von Anforderungen<br />
zu einem Projekt bzw.<br />
Produktkomponenten<br />
CMMI<br />
Assessment<br />
definiert<br />
fünf aufeinander<br />
aufbauende Reifegrade<br />
Maturity Levels<br />
jeder dieser Reifegrade<br />
definiert Schlüsselbereiche,<br />
die vollständig vorhanden<br />
sein müssen<br />
= Prüfung jedes der<br />
Schlüsselbereiche, ob die<br />
nötigten Maßnahmen<br />
eingeführt sind und<br />
praktiziert werden<br />
20. März 2006, Thomas Bauer, Seite 31
ISO 9000<br />
http://www.wibas.de/download/BITKOM_v1.pdf<br />
20. März 2006, Thomas Bauer, Seite 32
ISO 9000<br />
http://www.wibas.de/download/BITKOM_v1.pdf<br />
20. März 2006, Thomas Bauer, Seite 33
ISO/IEC 15288<br />
umfassender Standard zum<br />
Systemlebenszyklus (Rahmenplan<br />
für alle Prozesse rund<br />
um die Produktentwicklung)<br />
Ziele<br />
Prozesse<br />
Bewertung Verbesserung<br />
Grundlage für<br />
Verträge mit<br />
Lieferanten<br />
Beschreibung von<br />
Schnittstellen im<br />
gesamten Lebenszyklus,<br />
z.B. zwischen Kunde<br />
und Lieferant<br />
ISO / IEC<br />
15288<br />
System Life<br />
Cycle Process<br />
deckt Systementwicklung<br />
inkl. SW, HW und<br />
Benutzerschnittstelle ab<br />
ist ein generischer Lebenszyklusstandard<br />
(abstrakter Standard), der<br />
konkrete weitere Standards erfordert,<br />
um implementiert zu werden<br />
z.B. IEEE 1220<br />
Standard for Application<br />
and Management of the<br />
Systems Engineering<br />
Process<br />
beginnt <strong>beim</strong> Kostenplan<br />
des Systems<br />
:<br />
endet mit dem Ersetzen<br />
aller installierten Systeme<br />
konkretisierter Standard<br />
mit Schwerpunkt<br />
"Entwicklung von<br />
SW-Systemen"<br />
20. März 2006, Thomas Bauer, Seite 34
ISO/IEC/IEEE 12207<br />
Einkauf<br />
Wartung<br />
Betrieb<br />
Verifikation<br />
Validierung<br />
Reviews<br />
Audits<br />
Verteilung<br />
Problemmanagement<br />
Entwicklung<br />
primäre<br />
Prozesse<br />
Trennung<br />
Unterstützungsprozesse<br />
Qualitätssicherung<br />
Tailoring: Anpassung / Reduzierung<br />
des Standards für das Tagesgeschäft<br />
unter bestimmten Voraussetzungen<br />
ISO / IEC / IEEE<br />
12207<br />
Standard für Software<br />
Life Cycle Processes<br />
Konfigurations-<br />
Management<br />
Dokumentation<br />
organisatorische<br />
Prozesse<br />
reiner SW-Entwicklungs-<br />
Standard<br />
Basis für Lebenzyklusbeschreibungen<br />
der SW-Entwicklung<br />
(von der Ideenfindung<br />
bis zur Stilllegung)<br />
Projektmanagement<br />
Infrastrukturmanagement<br />
Änderungsmanagement<br />
Training<br />
20. März 2006, Thomas Bauer, Seite 35
Standards für das RM<br />
ISO / IEC 9126<br />
Software Engineering<br />
Product Quality<br />
nützliche Richtlinie zum<br />
Identifizieren und Behandlung<br />
von nichtfunktionalen<br />
Anforderungen<br />
VDI 2519 – Blatt 1<br />
Vorgehensweise bei<br />
der Erstellung von<br />
Lasten-/Pflichtenheften<br />
Standards für<br />
das RM<br />
IEEE 1362<br />
Guide for Information<br />
Technology – System<br />
Definition<br />
VDI 2519 ist ein gutes<br />
Gerüst, das mit den swspezifischen<br />
Aspekten von<br />
IEEE 1362 und IEEE 830<br />
angereichert werden kann.<br />
IEEE 1233<br />
Guide for Developing<br />
of System <strong>Requirements</strong><br />
Specifications<br />
IEEE 830<br />
Recommended Practice<br />
for Software <strong>Requirements</strong><br />
Specifications<br />
bilden zusammen eine solide<br />
Basis für die Entwicklung eines<br />
praktikablen Anforderungsdokumentes<br />
aus Lieferanten-,<br />
Kunden- und Benutzersicht.<br />
20. März 2006, Thomas Bauer, Seite 36
IEEE 1362<br />
setzt sich mit den<br />
Anforderungen an den<br />
Betrieb eines SW-Systems<br />
auseinander<br />
ist ein Standard für<br />
Anforderungsdokumente<br />
Benutzerperspektive<br />
beschreibt die aus<br />
Benutzersicht<br />
relevanten Tätigkeiten<br />
IEEE 1362<br />
Guide for Information Technology – System Definition<br />
(Definition - Concept of Operations Document)<br />
Der Fokus liegt auf<br />
Concept of Operations<br />
Document = Software-<br />
Lastenheft<br />
beschreibt technische<br />
und organisatorische<br />
Randbedingen für<br />
den korrekten Betrieb<br />
der Software<br />
20. März 2006, Thomas Bauer, Seite 37
VDI 2519 – Blatt 2<br />
ist häufig Basis für<br />
Ausschreibungen<br />
VDI 2519 – Blatt 1<br />
Vorgehensweise bei<br />
der Erstellung von<br />
Lasten-/Pflichtenheften<br />
klare Trennung in der<br />
Aufgabenbeschreibung<br />
Benutzersicht Systemsicht<br />
http://217.160.141.52/DC-IIT/data/multimedia/einfuehrung-lastenheft-projektarbeit.pdf<br />
Definiert was Lasten- und<br />
Pflichtenhefte sind, was sie<br />
enthalten sollten und wie sie<br />
erstellt werden sollten.<br />
ist ein generischer<br />
Standard<br />
20. März 2006, Thomas Bauer, Seite 38
IEEE 830<br />
Grundlage für Werkzeugeinsatz<br />
konkreter praxisnaher Standdard<br />
für Beschreibung und Definition<br />
von Softwareanforderungen<br />
Struktur für<br />
Anforderungsspezifikation<br />
IEEE 830<br />
Kapitelstruktur<br />
1 Einführung<br />
2 Glossary<br />
3 Spezifikation der Kundenanforderungen<br />
4 Systemarchitektur<br />
5 Spezifikation der Systemanforderungen<br />
6 Systemmodelle<br />
7 Evolution des Systems<br />
8 Anhänge<br />
9 Index<br />
Aufbau von Anforderungen<br />
Lastenheft<br />
Pflichtenheft<br />
Anforderungsnummer, Anforderungstitel, Status,<br />
Erläuterung, Einschränkungen, Begründung,<br />
Priorität, Querbezüge, Einflüsse, Aufwand,<br />
Akzeptanzkriterien, Kommentare, ...<br />
Satzstruktur von<br />
Anforderungen<br />
als Grundlage für den<br />
Kauf von fertigen SW-<br />
Komponenten geeignet<br />
kurze Sätze nach<br />
vorgegebenem<br />
Muster Mustersätze<br />
pro Anforde-<br />
vermeidet vage bzw.<br />
abstrakte Formulierungen<br />
keine Konditionalsätze<br />
jeder Satz<br />
ein Verb<br />
rungstyp<br />
führt zu klar<br />
strukturierten<br />
und verständlichenAnforderungstexten<br />
Beispiel:<br />
Das soll oder<br />
muss <br />
Die Kaffeemaschine soll<br />
Kaffee brühen<br />
20. März 2006, Thomas Bauer, Seite 39
IEEE 1233<br />
IEE 1233<br />
Guide for Developing<br />
of System <strong>Requirements</strong><br />
Specifications<br />
beschreibt Entwicklung und<br />
Spezifikation von Anforderungen<br />
und deren Behandlung in der<br />
gesamten Produktentwicklung<br />
deckt auch die frühen Phasen in<br />
der Entwicklung ab, wo es um<br />
Extraktion von konkreten<br />
Anforderungen aus vage<br />
geäußerten Bedürfnissen geht<br />
Änderungsmanagement<br />
von Anforderungen<br />
Organisation<br />
von Anforderungen<br />
im Projekt<br />
20. März 2006, Thomas Bauer, Seite 40
Produktlebenszyklus<br />
PLC = Procduct Life Cycle<br />
Betrachtung des Produktes (bzw. der Lösung) als Ergebnis von einem oder<br />
mehreren Projekten. Betrachtet werden alle notwendigen Schritte, um die<br />
Lösung (und deren Varianten und Versionen):<br />
zu definieren<br />
zu entwickeln<br />
zu produzieren<br />
zu betreiben<br />
zu pflegen<br />
zu betreiben<br />
zu warten / zu erweitern<br />
aus dem Betrieb zu nehmen<br />
PLCM = Product Life Cycle Management<br />
Hier wird der gesamte Lebenszyklus von Lösungen als ein Prozess<br />
betrachtet, der vereinheitlicht, überwacht, gesteuert, verbessert und<br />
informationstechnisch automatisiert werden kann.<br />
20. März 2006, Thomas Bauer, Seite 41
PLC<br />
Business Case<br />
Kosten-Nutzen-Rechnung<br />
Inhalte, Ziele,<br />
Meilensteine<br />
Projekt "aufsetzen"<br />
Portierbarkeit<br />
Festlegung von<br />
"Nach-Entwicklungs-<br />
Anforderungen"<br />
weitere Entwicklungsschritte<br />
Wartung<br />
Dienstleisttungen<br />
um<br />
das Produkt<br />
herum<br />
Analyse Benutzerverhalten<br />
1. Planung<br />
Vision, Strategie,<br />
Spezifikation,<br />
Analyse<br />
Implementierung<br />
Paketierung<br />
Analyse Systemumgebung<br />
Entwurf<br />
Management der<br />
Anforderungen<br />
2. Entwicklung<br />
Analyse,<br />
Entwicklung,<br />
Entwicklungsprozess<br />
Strukturierung der einzelnen<br />
Schritte in Vorgehensmodellen<br />
V-Modell iterative Entwicklung ...<br />
Entwicklung Architektur<br />
Qualitätskontrolle<br />
Verifikations- und<br />
Validierungsstrategie<br />
3. Wartung,<br />
Pflege<br />
4. Lebensende<br />
20. März 2006, Thomas Bauer, Seite 42
V-Modell<br />
Anforderungsermittlung<br />
Systemanalyse<br />
Anforderungen,<br />
Anforderungen,<br />
Lastenheft<br />
Lastenheft<br />
Systemmodell,<br />
Systemmodell,<br />
Pflichtenheft<br />
Pflichtenheft<br />
System- und<br />
Softwareentwurf<br />
Architektur,<br />
Architektur,<br />
Entwurf<br />
Entwurf<br />
Implementierung<br />
(und Verifikation)<br />
Code<br />
Code<br />
Systemtest<br />
Integrationstest<br />
Freigabetest,<br />
Abnahme<br />
System<br />
System<br />
in<br />
in<br />
Entwicklung<br />
Entwicklung<br />
Subsysteme<br />
Subsysteme<br />
in<br />
in<br />
Entwicklung<br />
Entwicklung<br />
System<br />
System<br />
in<br />
in<br />
Produktion<br />
Produktion<br />
Legende<br />
Schritte<br />
Ergebnisse<br />
20. März 2006, Thomas Bauer, Seite 43
iterative Entwicklung<br />
Analyse Entwurf<br />
<strong>Requirements</strong> Management<br />
Implementierung<br />
Analyse Entwurf<br />
ValidierungI<br />
Implementierung<br />
Analyse Entwurf<br />
Inkrement 1<br />
Die hier dargestellte inkrementelle Vorgehensweise (iterative Entwicklung) ist<br />
letztendlich nur eine andere Form der Anordnung der Elemente aus dem V-Modell.<br />
In kleinen Schritten wird jeweils ein Teil der Anforderungen implementiert.<br />
ValidierungI<br />
Implementierung<br />
Inkrement 2<br />
Validierung<br />
Kontinuierliche Stabilisierung, Integration, Systemtest, Lieferung<br />
Zeit<br />
Inkrement 3<br />
20. März 2006, Thomas Bauer, Seite 44
iterative Entwicklung<br />
Inkrement 3<br />
Inkrement 2<br />
Inkrement 1<br />
Anforderungsermittlung<br />
Anforderungen,<br />
Anforderungen,<br />
Lastenheft<br />
Lastenheft<br />
Validierung (Nutzen für<br />
Interessengruppen)<br />
Validierung<br />
Systemanalyse<br />
(Systemanforderungen)<br />
Systemmodell,<br />
Systemmodell,<br />
Pflichtenheft<br />
Pflichtenheft<br />
System- und Verifikation)<br />
Softwareentwurf<br />
Architektur,<br />
Architektur,<br />
Entwurf<br />
Entwurf<br />
Implementierung<br />
(und Verifikation)<br />
Code<br />
Code<br />
Freigabetest,<br />
Abnahme<br />
System<br />
System<br />
in<br />
in<br />
Produktion<br />
Produktion<br />
Systemtest<br />
Integrationstest<br />
System<br />
System<br />
in<br />
in<br />
Entwicklung<br />
Entwicklung<br />
Subsysteme<br />
Subsysteme<br />
in<br />
in<br />
Entwicklung<br />
Entwicklung<br />
Schritte<br />
Ergebnisse<br />
Testphasen<br />
Legende<br />
20. März 2006, Thomas Bauer, Seite 45
Vorgehensmodelle<br />
großes Projekt<br />
lange Lebensdauer<br />
hoher Wartungsanteil<br />
viele Varianten / Releases<br />
kleines Projekt<br />
kurze Lebensdauer<br />
Wasserfall<br />
-modell<br />
V-Modell<br />
stabile Anforderungen<br />
bekannte Anforderungen<br />
wenig Kundeneinfluss<br />
Grafik aus Christof Ebert, Systematisches <strong>Requirements</strong> Management, dpunkt.verlag<br />
InkrementelleEntwicklungEvolutionär<br />
Agile Prozesse (z.B. XP)<br />
volatile Anforderungen<br />
unbekannte Anforderungen<br />
starke Kundenbeteiligung<br />
20. März 2006, Thomas Bauer, Seite 46
Notwendigkeit von Zyklen<br />
Ermittlung, Analyse<br />
und Beschreibung<br />
der Wünsche der<br />
verschiedenen<br />
Interessensgruppen<br />
konkreter<br />
in Sprache<br />
der Lieferranten<br />
für Kunde<br />
verständliche<br />
Sprache<br />
Ergebnis von Vertragsverhandlungen<br />
Kundenanforderungen<br />
Lösungs- oder<br />
Systemanforderungen<br />
Analyse der<br />
Kundenanforderungen<br />
Bereiningung der<br />
Kundenanforderungen<br />
um bestehende<br />
Konflikte<br />
meist unscharf,<br />
vage, inkonsistent<br />
Abbildung<br />
auf<br />
notwendiger<br />
Zyklus für<br />
Konkretisierung<br />
der Kundenanforderungen,<br />
Erkennung von<br />
Abhängigkeiten,<br />
Einflüssen und<br />
Zusammenhängen<br />
Produkt- und<br />
Komponentenanforderungen<br />
Lösungsanforderungen in<br />
der Sprache des Produktes<br />
Funktionen Eigenschaften<br />
Verfolgung von<br />
Anforderungen,<br />
Änderungsmanagement<br />
Zs.fassung, Gliederung<br />
Zuordnung zu Projekten<br />
und Teilprojekten<br />
Vereinbarung<br />
Budget<br />
Termin<br />
20. März 2006, Thomas Bauer, Seite 47
Änderungen verfolgen<br />
Anforderungsermittlung<br />
Systemanalyse<br />
Anforderungen,<br />
Anforderungen,<br />
Lastenheft<br />
Lastenheft<br />
Systemmodell,<br />
Systemmodell,<br />
Pflichtenheft<br />
Pflichtenheft<br />
System- und<br />
Softwareentwurf<br />
Architektur,<br />
Architektur,<br />
Entwurf<br />
Entwurf<br />
Änderungswunsch<br />
Implementierung<br />
(und Verifikation)<br />
Code<br />
Code<br />
Systemtest<br />
Integrationstest<br />
Freigabetest,<br />
Abnahme<br />
System<br />
System<br />
in<br />
in<br />
Entwicklung<br />
Entwicklung<br />
Subsysteme<br />
Subsysteme<br />
in<br />
in<br />
Entwicklung<br />
Entwicklung<br />
System<br />
System<br />
in<br />
in<br />
Produktion<br />
Produktion<br />
Legende<br />
Schritte<br />
Ergebnisse<br />
direkter Einfluss<br />
indirekter Einfluss<br />
Eine Änderung in der Anforderungsspezifikation während des laufenden Projektes muss in den darauf<br />
aufbauenden Projektergebnissen nachgezogen werden. Dies geschieht über dokumentenbezogene Verknüpfung<br />
von Projektergebnissen (bzw. weitere Verknüpfungen wie z.B. Unit-Test mit Klassen /Prozeduren)<br />
20. März 2006, Thomas Bauer, Seite 48
praktische Hinweise<br />
Buch: "Christof Ebert, Systematisches <strong>Requirements</strong><br />
Management"<br />
Checkliste zur Anforderungsermittlung: Seite 103<br />
Checkliste zur Anforderungsspezifikation: Seiten 127 bis 131<br />
Checkliste zur Anforderungsanalyse: Seiten 172 bis 173<br />
Checkliste zur Testbarkeit: Seiten 205 bis 206<br />
Weitere nützliche Tipps und Checklisten zur Gestaltung des<br />
<strong>Requirements</strong> Management findet man in diesem Buch jeweils<br />
man Ende der Hauptkapitel.<br />
Umfangreiches Glossar zu RM-Begriffen<br />
Aufstellung RM-bezogener Links<br />
20. März 2006, Thomas Bauer, Seite 49
praktische Hinweise<br />
Buch: "Mario Winter, Methodische objektorientierte<br />
Softwareentwicklung"<br />
Beschreibung der verschiedenen UML-Diagramme mit<br />
Beispielen.<br />
Beschreibung des vollständigen Prozesses von<br />
Anforderungsermittlung über Softwarespezifikation,<br />
Architekturspezifikation bis hin zum Entwurf.<br />
Bei allen Beschreibungen wird der Einsatz der jeweilig<br />
geeigneten Modelle am Bespiel gezeigt.<br />
20. März 2006, Thomas Bauer, Seite 50
Change language