Basic HTML-Version
CM
Controller
magazin 2/07 - Alfred Bezler / Sebastian Popescu
Problem definitions
Problemdefinition
requiremenls analysis
Anforderüngsanalyse
I
Specificalions
Spezifikation
•
Design
,
Entwurf
Implementat ion
Implement ierung
Field lest
Test und Erprobung
Del ivenng/Tfansmisston
Auslieferung
Change Mangemen l
Anderungsmanagem
Abb. 1: sequen–
tielle Modelle
Problem definitions
Problemdefinition
f
•
,
requirements ana l ys i s '
\
Anforderungsanalyse
Specificalions
Spezifikation
I
Design
Entwurf
Implementation
Implementierung
\
Field tesl
Test und Erprobung
I
)eti¥enng/TransmfSS(on
Auslieferung
Change Mangemenl /
Anderungsmanagem
Abb. 2: nicht sequentielle
Modelle
Abb i l dung 1 zeigt ein sequent i e l l es
Model l . Es stellt den organisatorischen
I dea l zus t and d a r Demn a c h beg i nn t
eine neue Phase erst dann , wenn der
Vorgänger beendet ist. Eine Rückkehr
zur Vorgängenphase ist nicht mögl ich.
Zu den bekanntesten Vertretern dieser
sequent iel len Model le zählen beispiels–
weise das abgebi ldete Wasserfall- oder
das V-Model l . Mode l l e dieser Gruppe
haben m. E. nur eine akademische Da–
seins-Berecht igung, auch wenn nach
einer Studie des Fraunhofer Instituts^
41 % der befragten Unt ernehmen diese
Model le einsetzen. Viel zu lebendig, dy–
namisch und meist zu terminkr i t isch ist
die Sof tware-Entwicklung, als dass ma n
bei Störungen im Betriebsablauf immer
wieder an der obersten Stufe, z. B. bei der
Problemdef ini t ion, beginnt .
Wesen t l i ch p r a x i s n ä h e r u n d somi t
emp f eh l enswe r t e r sind nicht -sequen–
t iel le Mode l l e (siehe Abb . 2) , deren
Phasen nicht absolut streng hinterein–
ander ablaufen. Es gibt zwar eine Haupt –
prozessrichtung, aber begründete Rück-
und Quersprünge sind mögl ich. Zu dieser
Gruppe zählen u. a. die evolut ionäre
Sof tware-Entwicklung, das Prototyping,
das Spiral- und Fontänenmodel l oder
das „Extreme Programming*"' . Model le
dieser Art bergen ab einer best immten
Komplexi tät die latente Gefahr, organi–
satorisch nicht mehr beherrschbar zu
sein. Mi t tels geeigneter Entwicklungs–
und Steuerungswerkzeuge kann dieses
Risiko jedoch restlos ausgeschlossen
werden.
2.3. Entwicklungswerkzeuge
Für eine rationelle und zeitsparen–
de Sof tware-Entwicklung lassen
sich in nahezu al len Phasen des
Software-Lifecycle (Entwicklungs–
prozesses) sog. CASE^-Tools (Ent–
wicklungswerkzeuge) einsetzen.
Ein Großtei l der angebo t enen
CASE-Tools unterstützen einzelne
Phasen bzw. konzentr ieren sich
auf ausgewähl te Funkt ionen. Bei–
spiele für diese Single-Funktions–
tools sind die Unterstützung der
Analyse- und Designphase, das
automat ische Generieren der Co–
dierung oder die Erstellung stan–
dardisierter Dokumen t a t i onen .
Für den Entwi ck l ungsprozess
bedeut e t dies, dass ma n ver–
schiedene CASE-Tools ggf. von
un t e r sch i ed l i chen Hers t e l l ern
einsetzt und diese - wenn nöt ig
- mi t Schnittstel len verbindet .
l ahre l ang wa r en diese Umgebungen
Standard. Aus heutiger Sicht plädieren wi r
jedoch für den Einsatz integrierter und
phasenübergrei fender Werkzeuge*". Bei
diesen Systemen handel t es sich nicht nur
um ein Technologie-, sondern auch um ein
Management konzept , da alle Beteiligten
wie Analyst , Designer, Programmierer,
Tester, Dokument ierer und Produktma–
nager in einer geme insamen Umgebung
arbei ten. Bedingt durch die Mächt igkei t
dieser Systeme ist man häuf ig an deren
Methodologi e gebunden und hat ggf.
bewähr t e firmeninterne Prozesse an das
CASE-Tool anzupassen.
2. 4. Ticketsystem zur Prozess–
steuerung
Zur akt iven Prozess- und Ressourcen–
steuerung empf i ehl t sich der Einsatz
eines phasenübergrei fenden Ticketsy–
stems. In diesem System werden alle
strategischen Neuentwicklungen, anste–
henden Anforderungen und notwendigen
Verbesserungen produkt- und release–
scharf gesammel t , jeder Eintrag erhäl t
eine eindeut ige Ident i f ikat ionsnummer
( = Ticket ) . Im Sinne eines Work f l ow-
Ma n a g eme n t s beglei tet jedes Ticket
sys t emges t euer t den gesamt en Her–
s t e l l ungsprozess . En t sp r echend der
Arbe i tswe i se von nicht -sequent iel len
Model len lassen sich durch das Ticketsy–
stem Teilphasen kontrolliert überspringen
bzw. ein Ticket zur erneuten Bearbei tung
an eine Vorphase zurückweisen.
Initiiert über ein Ticket (Arbeitsauftrag)
beginnt der Mi tarbei ter mi t der Realisie–
rung. Die Fert igmeldung dieses Arbeits–
vorgangs bestätigt er durch elektronische
Signatur Das Ticket wi rd dann - wie bei
einem Staffellauf - an die nächste Stelle in
der Herstel lungskette wei tergelei tet . Am
„Leitstand" ist man zu jedem Zei tpunkt
über die aktuel le Bearbei tungsphase,
Status und Reifegrad eines einzelnen
Tickets bzw. aller Tickets, die zu einem
Lieferumfang gehören, informiert .
Das Dokumen t i e r en im Ticketsystem
stellt zwar anfangs eine bürokrat ische
Hürde dar, dennoch sind es u. a. folgende
Vorteile, die den Einsatz rechtfert igen:
5 * Garant ierte Einhal tung der Kernpro–
zesse,
>• Gesicherte Abarbe i tung aller Anfor–
derungen,
Definierte Verantwort l ichkei ten und
geregelte Freigabe,
Beschleunigte Bearbe i tung durch
kürzere Liegezeiten,
Unterstützung bei Outsourcing-Akti-
vi täten,
>- Kenntnis der Istzeiten u.a. für Nach–
kalkulat ion.
3. ARBEITEN IM HERSTELLUNGS–
PROZESS
Auf derGrundlageder genannten aufbau-
und ablauforganisator ischen Rahmen–
bed i ngungen sowie der vorgestel l ten
Werkzeuge zeigt ma n im folgenden, wie
der Soft:ware Entwicklungsprozess aus
Sicht des Control l ings ablaufen kann.
Neben reinen I TThemen richtet sich der
Fokus vor al lem auf betriebswirtschaft–
liche Aspekte. Um den Umfang dieser
Dokumentat ion nicht zu sprengen, kon–
zentriert man sich dabei auf die „Kernpha-
sen" der Sof tware-Entwicklung.
3 . 1 . Erste Phase: Systemanalyse
Mi t der Systemanalyse beginnt der ope–
rat ive Teil der Sof tware -Entwi ck l ung .
Hi er we r d e n u.a. die s t r a t eg i schen
Vo r gaben aus der P r odu k t p l a nung ,
die I nha l t e des An f o r de r ungs - u n d
Change -Managemen t s sowie erkann–
te Fehler und St örungen ana l ys i er t ,
spe z i f i z i e r t u n d als V o r g a b e n für
die Impl ement i erung aufberei tet .
148