Software Aufwände sichtbar machen

Die Wochen und Monate vergehen und die Software wird und wird nicht fertig. Kennen Sie dieses Problem? Dann kann ihnen dieser Beitrag vielleicht helfen. Denn Aussagen wie “wir sind bei ca. 80%” oder “wir benötigen noch ein bis zwei Monate” sind mit Vorsicht zu genießen und entbehren meistens jeglicher Grundlage.

Warum ist es so schwer Software Aufwände zu ermitteln?

Die Beziehung zwischen Software Entwicklern und Projektleitern ist nicht immer einfach. Software Entwickler haben eine eigene Sprache und drücken sich für den Projektleiter oft sehr unverständlich aus. Das kann dazu führen, dass der Projektleiter nicht nachvollziehen kann, was der Software Entwickler tut. Er hofft, dass der Software Entwickler seinen Job macht und die Software zu einem Termin abschließt. Doch diese Annahme tritt in den meisten Fällen nicht ein. Das Problem ist, dass dem Software Entwickler selbst Methoden fehlen, um Abschätzungen durchzuführen. Gerade bei Software können vergessene Arbeitspakete dazu führen, dass Aufwände explodieren.

Wie kommt man zu qualifizierten Aussagen über die Aufwände?

Als Basis für eine qualifizierte Aussage muss eine freigegebene Software Spezifikation vorliegen. In dieser Spezifikation müssen die Anforderungen an das Software System enthalten sein. Auf Basis dieser Spezifikation wird eine Software Architektur erstellt. Dabei bildet meist eine Software, die auf einem Prozessor läuft das Software System. Das Software System wird dann hierarchisch in Software Items und schließlich in Software Units heruntergebrochen. Die Software Unit stellt die kleinste Einheit dar, die aus Architektursicht nicht mehr weiter aufgeteilt wird. Die Units sind somit die einzelnen Bausteine der Software. Die Software Architektur kann nun dazu genutzt werden, die Aufwände zu ermitteln und Aufgaben zu planen.

Für jede Software sind bestimmte Tätigkeiten durchzuführen. Die Architektur Dokumentation ist zu erstellen und freizugeben, es ist ein Detailed Design zu dokumentieren. Der

IDTitleSoftware Safety ClassArchitecture approvedDetailed DesignImplementedCode ReviewUnit TestIntegratedUnit finished
SW-895VersioningToolSafety Class Bdoneopenopenopenopenopenopen
SW-887TroubleshootModeSafety Class Bdoneopenopenopenopenopenopen
SW-890ToolSettingsSafety Class BReviewopenopenopenopenopenopen
Goran Madzar

Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Wir haben ein Ingenieurbüro im Innovations- und Gründerzentrum in Erlangen aufgebaut. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.