| |
Samstag, 7. Juni 2008Montag, 29. Oktober 2007Lastenheft
Das Lastenheft stellt eine grobe Produktskizze für ein zu erstellendes Software-Produkt dar. Damit ist das Lastenheft vereinfachte Form des Pflichtenhefts. Da es nicht detailliert ausfallen soll, muss es vom Umfang so knapp wie erforderlich gehalten werden, meist werden nur wenige Seiten benötigt.
Es wird nicht beschrieben, "wie" etwas gemacht werden soll, sondern nur "was" die neue Software leisten soll. Die Basisfunktionen der neuen Software und ihr Sinn muss deutlich herausgearbeitet werden. Da das Lastenheft die Grundlage für Entscheider darstellt, muss es sprachlich so gehalten sein, dass diese es verstehen und vor allem die Argumente nachvollziehen können. Wenn der Auftraggeber eine Fachsprache verwendet, sollten die entsprechenden Begriffe auch an den erforderlichen Stellen eingesetzt werden, hier sollte eine Fachkraft der Branche gegebenenfalls noch einmal Korrektur lesen. Hier sagt ein Bild auch oft mehr als 1000 Worte - eine Zeichnung kann viele Abläufe verdeutlichen! Auch Tabellen sollten eigesetzt werden, um Werte übersichtlich zu präsentieren. Zahlenreihen sollten in grafischer Darstellung visualiert werden. Die Gliederung des Lastenhefts ist nicht verbindlich geregelt und es gibt verschiedene Empfehlungen dazu: Balzert empfiehlt Zielbestimmung: Was soll die Software können? Produkteinsatz: Wer soll die Software einsetzen? Produktfunktionen: Welches sind die Hauptfunktionen? Produktdaten: Welche Daten werden verarbeitet? Produktleistungen: Wie schnell, umfassend, genau? Qualitätsanforderungen: Wie zuverlässig, portabel...? Ergänzungen: Was sonst noch? Montag, 29. Oktober 2007Projektstudie (feasibility study)
Die Projektstudie wie sie nach DIN 69905 richtig heißt, auch Machbarkeitsstudie oder auf plattdeutsch auch "feasibility study" genannt, steht am Anfang größerer Projekte als erste Projektphase, teilweise noch vor dem Kick-off. Über die Tätigkeiten und Ergebnisdokumente gibt es in der Literatur keine Einigkeit. da die Gestaltung dieser Phase sehr von der Situation abhängt.
Mit der Projektstudie soll das Risiko für eine Erreichen des Projektziels geprüft werden, wenn nicht sicher ist ob dies überhaupt möglich ist. So kann man versuchen herauszubekommen, mit welchen Aufwand (zeitlich und damit auch finanziell) der Projekt realisiert werden kann. Rein organisatorisch bringt die Projektstudie Ordnung ins anfängliche Chaos. Im Hauptteil der Projektstudie steht die Machbarkeitsprüfung: Hier wird die organisatorische Umsetzung und wirtschaftliche Machbarkeit (z.B. Kostenrahmen, Finanzierung), aber auch die technische Machbarkeit und die Verfügbarkeit von Ressourcen (Mitarbeiter, Räume, Geräte und Zeit) geklärt. Für die Projektstudie wird üblicherweise ein strammes Zeitfenster angesetzt, nach deren die Untersuchungen abgeschlossen sein müssen. Ist das Ergebnis dieser Studie negativ muss das Projekt abgelehnt oder komplett geändert werden. Nach der Machbarkeitsstudie fällt auf jeden Fall die Entscheidung "stop-or-go". Im Bereich der Software-Entwicklung hat die Projektstudie auch noch eine weitere Funktion neben der eigentlichen Untersuchung der Machbarkeit, nämlich festzulegen, was die Software überhaupt leisten soll. Neben den Anforderungen an die Software und die Funktionen sind auch die Gestaltung des Benutzer-Interfaces der Inhalt einer Vorstudie zu einer Software-Entwicklung. Ergebnis der Studie sollte daher auch ein Lastenheft sein. Dazu sind Ausschreibungsunterlagen und gesetzliche Vorgaben zu beachten, es muss der Markt oder die bestehende Software analysiert werden sowie Interviews mit Anwendern und späteren Fachleuten geführt werden. Montag, 29. Oktober 2007Wasserfall-Modell
Das Wasserfallmodell ist eine klassische Vorstellung von der Aufeinanderfolge von Projektphasen im Software-Engineering, der Softwareentwicklungsprozess in Phasen aufgeteilt. Der Name kommt daher, weil man dabei davon ausgeht, dass Ergenisse einer Phase wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase eingehen.
Das Problem des Wasserfallmodells ist jedoch, dass es nur dann problemlos eingesetzt werden kann, wenn sich die Anforderungen und Kundenwünsche an das Projekt und das fertige Software-Produkt schon in der Planungsphase präzise beschreiben lassen. Ende jeder Projektphase sind dabei sogenannte Meilensteine, Sitzungen an denen die Ergebnisse der Projektphasen dokumentiert werden. Die Phasen können dabei in ihrer Anzahl und Bezeichnung unterschiedlich ausfallen, aber immer findet man die grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen:  Davon gibt es einige Varianten, beispielsweise gehört in bei der Integration gehört auch ein Test zur Qualitätssicherung mit dazu. Zum Kickoff kann es nur ein kurzes Meeting geben, diese Phase kann aber auch die Durchführung einer Studie bedeuten, nach der erst weiter über das Projekt entschieden wird. In der Praxis überschneiden sich Projektphasen und es ist auch immer wieder mal erforderlich, einen Schritt zurück zu gehen. Dies kann das Wasserfallmodell mit dem Ansatz, dass die Phasen nacheinander ablaufen und voneinander sauber abgrenzbar sind nicht mehr abbilden. Damit ist das Wasserfallmodell nur auf einfache Projekte anwendbar und unflexibel gegenüber Änderungen. Es ist nur dann verwendbar wenn es möglich ist, schon früh die Anforderungen festzuschreiben. Werden Fehler erst spät erkannt, müssen sie mit erheblichem Aufwand entfernt werden. Wegen der gravierenden Nachteile des Wasserfallmodells, die meist erhöhten finanzielle Aufwand bedeuten, hat das Wasserfallmodell heute kaum noch praktischen Wert und wurde in der IT-Industrie durch eine Vielfalt alternativer oder ergänzender Vorgehensweisen ersetzt. |
SucheNavigationKategorienBlogroll |