Ziel­gruppe

Inter­essierte Par­teien

Ein Auf­trag­geber ist eine inter­essierte Par­tei mit einem star­ken wirt­schaft­lichen und stra­tegischen Inter­esse am Pro­dukt. Der Auf­trag­geber ist erster Ansprech­part­ner für den Pro­dukt­verant­wort­lichen. Er ist Leser der Pro­dukt­doku­men­tation. Die Bau­steine der System­beschrei­bung ver­wen­det der Auf­trag­geber für seine Gespräche mit Fach­abtei­lungen. Sie hel­fen ihm, die Fach­abtei­lungen als Ver­treter der Nutzer und als Geld­geber zu moti­vieren, Ver­besse­rungen oder Erweite­rungen an der Soft­ware zu beauf­tra­gen. Sie disku­tie­ren in einer gemein­samen Sprache und profi­tie­ren dabei vom Glossar. Bei Ver­hand­lungen ist es sehr prak­tisch, wenn eine Pro­dukt­doku­men­tation exis­tiert, die einen Über­blick (engl. big picture) über das Pro­dukt ver­mitteln kann. Das Wissen über bereits reali­sierte Fähig­keiten der Soft­ware hilft bei einer schnellen Ein­schätzung einer Anfor­derung an das IT-System.

Nutzer sind inter­essierte Par­teien und Exper­ten für das IT-System. Indivi­duelle Soft­ware wird in der Regel produ­ziert, um Geschäfts­prozesse im Unter­nehmen zu unter­stützen. Nutzer arbei­ten effi­zienter und machen weni­ger Fehler, weil unter­nehmens­spezi­fische Abläufe und damit ver­bundene beson­dere Fähig­keiten in der Soft­ware abge­bildet werden. Nutzer sind auf jeden Fall Leser für Hand­bücher und Online-Hil­fen. Nutzer sind aber auch Leser der Pro­dukt­doku­men­tation, wenn sie der Pro­dukt­verant­wort­licher als Domä­nen­exper­ten für die Anfor­derungs­ana­lyse hinzu­zieht.


Defini­tion

Was zählt zur Leistung­beschrei­bung eines Pro­duk­tes?

Bau­stein Topic

Der Bau­stein Topic gibt den Umfang (engl. scope) des Pro­duk­tes vor. Hier wird Bezug auf die Unter­nehmens­pro­zesse genom­men.

Bau­stein Epic

Der Bau­stein Epic grup­piert verwandte Fähig­kei­ten zu Funktio­nali­täten. Hier befin­den sich auch Aus­schlüs­se und Abgren­zun­gen.

Bau­stein Case

Der Bau­stein Case beschrei­bt eine ein­zelne gefor­der­te Fähig­keit der Soft­ware und nach dem Abschluss der Reali­sierung mit den Essenz­schrit­ten der Lösung.

Bau­stein Decision

Mit dem Bau­stein Decision werden vom Auf­trag­ge­ber gefor­derte Quali­täts­merk­male der Soft­ware mit Begrün­dung fest­gehal­ten.

Bau­stein Layout

Der Bau­stein Layout wird für die Siche­rung der Ent­würfe einer Bedien­ober­fläche ver­wen­det, die mit dem Auf­trag­geber abge­stimmt wur­den.

Bau­stein Service

Den Bau­stein Service dient der Fest­legung von Schnitt­stel­len des IT-Systems nach außen. Er beschreibt die End­pun­kte auf bei­den Sei­ten.


Ziel­gruppe

Pro­jekt­organi­sation

Ein Pro­jekt ist nach üblicher Defini­tion ein Vor­haben mit min­des­tens einem Ziel, einem Anfang und einem Ende. Eine Pro­jekt­organi­sation umfasst alle Per­sonen, die an diesem Vor­haben mit­wir­ken. Im Zusam­men­hang mit agiler Soft­ware-Ent­wicklung reden wir kon­kret von einem Pro­dukt­verant­wort­lichen und einem Reali­sierungs­team. Das Team setzt sich zusam­men aus Ana­lysten, Ent­wick­lern, Testern und Redak­teuren. Ana­lysten unter­stützen den Pro­dukt­verant­wort­lichen im Pro­jekt­manage­ment und in der Anfor­derungs­ana­lyse. Ent­wick­ler und Tester ent­wickeln die Soft­ware. Redak­teure kümmern sich um pro­fessio­nelle Hand­bücher und unter­stützen den Pro­dukt­verant­wort­lichen beim Marke­ting für das Pro­dukt. In einem Scrum-Pro­zess kommt noch der Scrum-Master dazu. Ein Pro­jekt­leiter ist immer dann not­wendig, wenn nur das Ent­wick­lungs­pro­jekt agil ist, der Auf­trag­geber aber eher klassisch unter­wegs ist.

Der Pro­dukt­verant­wort­liche ist Autor der Bau­steine der System­beschrei­bung. Er nutzt die Bau­steine für sein Back­log-Manage­ment. Ent­wickler und Tester im Team sind damit auto­matisch Leser der System­beschrei­bung.

Der Pro­dukt­verant­wort­liche und Ver­treter des Teams sind Autoren der Bau­steine der System­struktur. Sie teilen sich die Arbeit. Der Pro­dukt­verant­wort­liche arbeitet im Wiki. In Abstim­mung mit dem Team legt er Bau­steine für Dienste und Objekte an. Ver­treter des Teams ver­öffent­lichen Teile vom Code, code-nahe Arte­fakte oder Spezifi­kationen im Wiki, sobald sie ihrer Imple­men­tie­rung an den Diensten und Objekten abge­schlos­sen haben. Tester aus dem Team ver­öffent­lichen Test­pläne im Wiki. Außer­dem unter­sützen das Team den Pro­dukt­verant­wort­liche bei der Formu­lierung der Essenz­schritte der Lösung im Bau­stein Case — min­destens mit ihrem Feed­back als Leser.

Der Pro­dukt­verant­wort­liche und Ver­treter des Teams sind Autoren der Bau­steine für den Archi­tektur­entwurf. Sie nutzen den Bau­stein Decision für die Erfas­sung und Begrün­dung wich­tiger Ent­schei­dungen. Den Bau­stein Spec ver­wenden sie, um ein wieder­kehren­des Ent­wurfs­muster bei der Imple­men­tierung (engl. software pattern) oder ein über­greifen­des Kon­zept pro­dukt­spezi­fisch zu beschrei­ben.

Das Kon­zept der DevOps, also die Kombi­nation von Ent­wick­ler (engl. developer) und Betrei­ber (engl. operator) von Soft­ware, ist aus einem agilen Ent­wick­lungs­pro­jekt nicht mehr wegzu­denken. Ent­wick­ler beglei­ten die Soft­ware bis zur kunden­wirk­same Pro­duktions­umge­bung. Als Autoren der Hand­lungs­anwei­sungen haben sie die Auf­gabe, bereits während der Ent­wick­lung der Soft­ware über Instal­lation und Betrieb nachzu­denken.


Ziel­gruppe

Betriebs­organi­sation

Die Betriebs­organi­sation umfasst als Ziel­gruppe alle Per­sonen, die Verant­wortung für den kunden­wirks­amen Betrieb tragen. Ein Betrei­ber (engl. operator) ist not­wendig, um ein IT-System unter­brechungs­los und störungs­frei zu betrei­ben. Dazu muss ein Unter­nehmen spezielles Per­sonal haben, das einem Schicht­betrieb einen täg­lich ver­füg­baren 24-stündigen Bereit­schafts­dienst dauer­haft auf­recht­erhal­ten kann. Diese Ziel­gruppe hat natur­gemäß sehr hohe Erwar­tungen an die Quali­tät der Soft­ware.

Betrei­ber sind Leser der gesam­ten Pro­dukt­doku­mentation. Sie brauchen ein grund­legendes Ver­ständ­nis der Soft­ware. Die Bau­steine der System­struk­tur ver­mitteln genau dieses Wissen. In den Spezifi­kationen finden sie Infor­mationen über die einge­setzten Techno­logien und Quali­täts­merk­male der Kate­gorien Sicher­heit Zuver­lässig­keit. Der Bau­stein Service zeigt die Zusammen­hänge zwischen einem abstrak­ten Dienst und der Infra­struk­tur, in der die Pro­zesse betrie­ben werden. Die Bau­steine Event und Entity helfen ihnen beim Ver­stehen von Daten­flüssen im IT-System.

Das Kon­zept der DevOps, also die Kombi­nation von Ent­wick­ler (engl. developer) und Betrei­ber (engl. operator) von Soft­ware, ist aus einer effi­zienten Betriebs­organi­sation nicht mehr wegzu­denken. Betrei­ber sind min­destens Co-Autoren der Hand­lungs­anwei­sungen für das IT-System. Sie kümmern sich um die Ver­öffent­lichung der Hand­lungs­anwei­sungen und geben es als Betriebs­hand­buch frei.