Sonntag, 18. Februar 2007
Thema: Methoden
Scott Sehlhorst hat auf Tyner Blain eine interessante Methode "Estimating With Use Case Points (alternativer Artikel bei methodsandtools.com) vorgestellt, um den Aufwand für ein Software-Projekt vorherzusagen. Entwickelt wurde die Methode von Gustav Karner bei Rational Software Corporation Mitte der neunziger Jahre.
1. Technische Faktoren
Im ersten Schritt werden nicht-funktionale Anforderungen bewertet. Z. B. bewirken die Faktoren verteiltes System, hohe Usability-Anforderungen, einfache Installation oder kritische Antwortzeiten einen erhöhten Aufwand.
2. Umgebungs-Faktoren
Anschließend wird in der Methode die Umgebung betrachtet, in der das Projekt abläuft. Z. B. die Erfahrung des Projektteams, die Motivation und Anforderungs-Stabilität.
3. Use-Cases
Der dritte Schritt ist die Bewertung der Komplexität der Use-Cases. Komplexere Use-Cases sind aufwendiger umzusetzen.
4. Aktoren
Zuletzt werden die Anwender des Systems bewertet. Einfache Aktoren sind Nachbarsysteme, die das System über eine definierte API ansprechen. Komplexe Aktoren sind Anwender, die das System über eine flexible (z. B. AJAX) Oberfläche nutzen.
Für die Projekte bei Spirit Link ist die Aufwandsschätzung eine ständige Herausforderung, da wir Festpreisprojekte anbieten. Schätzen wir zu niedrig, müssen wir draufzahlen, schätzen wir zu hoch, bekommen wir das Projekt nicht. Wir haben hier eigene Methoden entwickelt, um in kurzer Zeit eine relativ genaue Schätzung zu bekommen.
An Karners Methode gefällt mir gut, dass nicht-funktionale Anforderungen und "weiche" Projektfaktoren eine explizite Rolle spielen.
Im Prinzip werden bestimmte Faktoren bewertet und gewichtet, und aus dem Ergebnis der Aufwand abgeleitet. Interessant sind die Faktoren, die in der Methode einbezogen werden.
Bei der Lektüre der Artikel habe ich keine Überraschungen erlebt. Bei jedem der Faktoren ist es einleuchtend, dass er Einfluss auf den Aufwand des Projekts hat. Selten habe ich aber eine so kompakte und knackige Zusammenfassung gesehen.
Um ein Projekt planen zu können, müssen die Faktoren mit Einfluss auf den Entwicklungsaufwand bekannt sein. Als Business Analyst ist es also meine Aufgabe, die Faktoren möglichst früh in einem Projekt in Erfahrung zu bringen. Dafür ist natürlich eine Art "Checkliste" interessant, um keinen der Faktoren zu vergessen. Genau diese Liste liefert die Methode.
Um meinen Teil der Aufwände in einem Projekt zu schätzen, also die Analyse und Spezifikation, sind diese Faktoren ebenso relevant.
1. Technische Faktoren
Im ersten Schritt werden nicht-funktionale Anforderungen bewertet. Z. B. bewirken die Faktoren verteiltes System, hohe Usability-Anforderungen, einfache Installation oder kritische Antwortzeiten einen erhöhten Aufwand.
2. Umgebungs-Faktoren
Anschließend wird in der Methode die Umgebung betrachtet, in der das Projekt abläuft. Z. B. die Erfahrung des Projektteams, die Motivation und Anforderungs-Stabilität.
3. Use-Cases
Der dritte Schritt ist die Bewertung der Komplexität der Use-Cases. Komplexere Use-Cases sind aufwendiger umzusetzen.
4. Aktoren
Zuletzt werden die Anwender des Systems bewertet. Einfache Aktoren sind Nachbarsysteme, die das System über eine definierte API ansprechen. Komplexe Aktoren sind Anwender, die das System über eine flexible (z. B. AJAX) Oberfläche nutzen.
Für die Projekte bei Spirit Link ist die Aufwandsschätzung eine ständige Herausforderung, da wir Festpreisprojekte anbieten. Schätzen wir zu niedrig, müssen wir draufzahlen, schätzen wir zu hoch, bekommen wir das Projekt nicht. Wir haben hier eigene Methoden entwickelt, um in kurzer Zeit eine relativ genaue Schätzung zu bekommen.
An Karners Methode gefällt mir gut, dass nicht-funktionale Anforderungen und "weiche" Projektfaktoren eine explizite Rolle spielen.
Im Prinzip werden bestimmte Faktoren bewertet und gewichtet, und aus dem Ergebnis der Aufwand abgeleitet. Interessant sind die Faktoren, die in der Methode einbezogen werden.
Bei der Lektüre der Artikel habe ich keine Überraschungen erlebt. Bei jedem der Faktoren ist es einleuchtend, dass er Einfluss auf den Aufwand des Projekts hat. Selten habe ich aber eine so kompakte und knackige Zusammenfassung gesehen.
Um ein Projekt planen zu können, müssen die Faktoren mit Einfluss auf den Entwicklungsaufwand bekannt sein. Als Business Analyst ist es also meine Aufgabe, die Faktoren möglichst früh in einem Projekt in Erfahrung zu bringen. Dafür ist natürlich eine Art "Checkliste" interessant, um keinen der Faktoren zu vergessen. Genau diese Liste liefert die Methode.
Um meinen Teil der Aufwände in einem Projekt zu schätzen, also die Analyse und Spezifikation, sind diese Faktoren ebenso relevant.
... kommentieren