Präsenz in China verstärkt
Fortsetzung des Artikels von Teil 2
Mit der Software ist’s wie beim Kochen
Sind die Prozesse definiert, erprobt und sollen in der Organisation gelebt werden, kommt es zu Fragestellungen wie: Warum werden Arbeitsprodukte wie eine Anforderungsspezifikation oder ein Design benötigt? Sollte denn der Quellcode nicht alle Informationen enthalten? Die Essenz einer Software zu ermitteln – selbst wenn der Quellcode vorhanden ist – fällt ebenso schwer, wie die Zutaten und die Zubereitungsart einer Mahlzeit aus deren Geruch und Geschmack herzuleiten. Eine Speise kann nur nachgekocht beziehungsweise verändert werden, wenn bekannt ist, welche Zutaten verwendet werden und wie die Zubereitung erfolgt.
Jobangebote+ passend zum Thema
Im übertragenen Sinn stehen die Zutatenliste für die Anforderungen und die Zubereitungsschritte für das Design eines Softwareprojektes. Somit ist klar, dass der Quellcode nicht eindeutig die Anforderungen und Designentscheidungen abbildet. Oft wird gefragt, wie genau die Anforderungen an ein Softwareprojekt beschrieben sein sollen. Hierfür gibt es keine feste Regel, jedoch können einige Hinweise hilfreich sein: Stets muss geprüft werden, ob alle notwendigen Aspekte in der Breite abgedeckt sind – zum Beispiel Funktion, Fehlerbehandlung und Diagnose. Noch schwieriger ist es, eine Aussage zur Tiefe der Anforderungsbeschreibung zu treffen. Hierbei ist festzulegen, wer die Beschreibung verstehen soll. Um beim Beispiel mit dem Kochen zu bleiben: Ist der Anwender Gelegenheitskoch oder Profikoch? Dementsprechend greift dann das Risikomanagement nach dem Motto »So wenig wie möglich und soviel wie nötig« ein, damit die Adressaten die Beschreibung verstehen und nicht mit nutzloser Information überflutet werden. Es ist hilfreich, wenn die niedergeschriebenen Anforderungen durch eine Person geprüft werden, die auch die Sprache der Zielgruppe spricht.
Nicht jede Metrik ist geeignet
Metriken machen den Erfolg von Verbesserungen messbar. Dadurch lassen sich unerwünschte Abweichungen vom Prozess quantifizieren. Dazu weist die Metrik anhand historischer Daten nach, dass Abweichungen in relevanter Anzahl vorliegen, sich daher das Verbessern lohnt und der Umfang der Abweichungen durch die Verbesserungen abnimmt (Bild 2).
| << vorherige Seite | 1 | 2 | 3 | 4 | nächste Seite >> |
Damit das Ergebnis des Assessments für die Organisation repräsentativ ist, müssen die assessierten Projekte die unterschiedlichen Facetten der Organisation abdecken. Selbstverständlich muss die Abteilung vor dem Assessment festlegen, welche Prozesse untersucht werden sollen. Gegebenenfalls bedarf es einer plausiblen Begründung, warum ein Prozess für die Organisation nicht relevant ist. Auch die Definition, bis zu welchem Level die einzelnen Prozesse geprüft werden, muss in die Planung des Assessments einfließen. Sonst besteht die Gefahr, dass die Assessoren für einen bestimmten Prozess auf Level 2 so wenige Eigenschaften erfüllt sehen, dass sie den Level 3 überhaupt nicht mehr prüfen. Dies erschwert der geprüften Organisation das Aufsetzen eines Verbesserungsprojektes, da wichtige Informationen über Prozessdefizite fehlen können. Die wiederholte Zusammenarbeit mit denselben Assessoren und einem eingespieltem Assessorenteam erleichtern das Kommunizieren, das Abstimmen und das Einhalten des Assessment-Plans (Bild 1).
- Präsenz in China verstärkt
- Mit der Software ist’s wie beim Kochen
