Enwicklungskosten

Diese Seite soll ihnen als "Nicht Entwickler" die Gründe aufzeigen, warum eine Eigenentwicklung komplexer Programme aber auch kleiner überschaubarer Skripte oft länger dauert und entsprechend teurer wird. Auf der MSXFAQ finden Sie viele kleine Scripte, die den Eindruck erwecken, dass Programmieren ganz schnell geht und eine Lösung in einigen Stunden oder wenigen Tagen umgesetzt werden kann. Dass dem nicht so ist, erkennen Sie spätestens bei der Höhe eines Angebots oder dem geschätzten Aufwand in Tagen. Warum ist Entwicklung dann immer so teuer bzw. auf jeden Fall teurer als zuerst vermutet

Proof of Concept

Die meisten Entwicklungen von "Tools" starten mit einem konkreten Problem, welches zu lösen ist. Wenn sich der Entwickler und Auftraggeber schon fachlich verstehen, kann der Entwickler sehr schnell mal "prüfen", ob es prinzipiell eine realisierbare Möglichkeit gibt.

Der Entwurf wird in einzelne Komponenten zerlegt um die kritischen Teile zu entdecken. Sehr oft wird jemand dann schon den ein oder anderen Teil experimentell programmieren. Wer z.B. noch nicht mit dem Active Directory gearbeitet hat, wird eben mal schnell mit einem kleinen Codefragment einen Benutzer anlegen, ändern, löschen oder suchen. Im Bereich Exchange wird man z.B. einfach mal schnell per MAPI eine bestimmte Mail im Postfach lesen wollen.

So was bezeichne ich als "Proof of Concept", d.h. ein Code, der die kleines Einheit einer Aufgabenstellung umsetzt. Meist enthält dieser Code aber noch keine Fehlerbehandlung, KonfigurationsMöglichkeit oder GUI. Er dient einfach dazu, Unsicherheiten zu beseitigen.

Auf diesem Level sind sehr viele Beispiele der MSXFAQ unter Programmieren mit Exchange und Franks Tools. Einige davon sind aber schon weiter. Nur was kommt denn nun noch alles dazu, bis aus einem Codeschnipsel eine Lösung wird ?

Was noch dazu gehört !

Es kann ganz schön erschrecken, wenn ein erster Testcode nach einigen Stunden schon vorzeigbar ist, aber dann doch noch einige Tage oder gar Wochen ins Land ziehen, bis das Bauwerk vollendet ist. Hier ein paar Stichpunkte:

  • Pflichten/Lastenheft
    Jede Programmierung sollte mit der möglichst genauen Aufstellung der gewünschten Funktion beginnen. Idealerweise erstellen Sie als Auftragnehmer ein Lastenheft mit den Anforderungen auf die der Auftragnehmer mit einem Pflichtenheft beschreibt, wie die Anforderungen umzusetzen sind. Gerade durch die Festlegung, was eine Software leisten soll, werden sehr schnell die Tragweite und der umfang deutlich und Unsicherheiten und ungenauigkeiten erkannt und aufgelöst.
  • Sonderfälle
    Was gerne übersehen wird sind Sonderfälle und Ausnahmen, die beim großen Bild auf das Ganze gerne unten durchrutschen und später den Aufwand erhöhen. Haben Sie sich z.B. überlegt, wie ihr Programm mit koreanischen Benutzernamen umgeht oder was passiert, wenn ein MAPI-Aufruf aufgrund eines defekten Eintrags in der Datenbank ungeplant abbricht. Wie behandeln Sie Sonderzeichen in einem Ordner ? So hat sich das Zeichen "/" als Trennung der Ordner in einem Pfad eingebürgert aber es ist genauso gut im Namen eines Ordners verwendbar. Auch ein "," im LDAP-Namen ist erlaubt, obwohl es auch ein Trennzeichen ist. So etwas ist zudem schwer zu testen, da Sie sich gar nicht alle Sonderkombinationen ausdenken können.
  • Fehlplanung, Erweiterungen
    Planen Sie hier auch einige Reserve ein da auch bei der Entwicklung nicht nur weitere Ausnahmen und Sonderfälle auffallen werden, sondern auch die Wunschliste gerne vergrößert wird. War Anfangs nur ein Script gewünscht, dann soll es aber noch per MOM überwacht werden oder weitere Funktionen umsetzen. Das sind nicht immer nur ein paar Prozent Mehraufwand. Gut ist hier eine Versionierung, d.h. eine Übersicht welche Funktionen in welcher Version realisiert werden sollen.
  • Dokumentation, Handbuch und Schulungsunterlagen
    Dokumentieren Sie sowohl das Programm selbst und dessen Einsatzzweck aber speziell bei größeren Projekten gehört auch ein Handbuch für die Administratoren und eventuell auch für die Anwender zwingend dazu. Es muss dabei kein Buch mit Formatierung herauskommen. Auch ein WIKI oder eine Webseite kann hier gute Dienste leisten. Dazu gehört aber auch eine Dokumentation des Code selbst mit entsprechenden Kommentaren. Der erste Schritt ist eine Versionskennzeichnung.
  • Test
    Vergessen Sie nicht umfangreiche Tests. Nur weil das Programm einmal mit ein paar Musterdaten funktioniert und vielleicht auch ihre Produktionsdaten korrekt verarbeitet hat ist noch keine Garantie für eine zukünftige Funktion. Es gibt Aussagen, dass Testen durchaus 30% der Gesamtzeit in Anspruch nehmen kann. Ideal ist, wenn der Test durch eine andere Person durchgeführt wird und dabei einzelne Funktionen mit eigenen Testprogrammen geprüft werden.
  • Installation und Konfiguration
    Natürlich können eine Installation per XCOPY und im Code hinterlegte Parameter für den Anfang ausreichend sein, aber sehr bald soll die Installation z.B. als MSI-Datei möglich sein und die Konfiguration über eine grafische Oberfläche erfolgen. Notepad ist ja doch auch fehleranfällig. Aber auch das dauert und kostet Zeit und letztlich Geld.
  • Überwachung und Fehlerbehandlung
    Das schönste Script taugt nichts, wenn es nicht überwacht werden kann und etwaige Fehler nicht kontrolliert abfängt. Windows bietet hierzu das Eventlog und Performance Counter an. Besonders wenn es wie z.B.: Grp2ExInet regelmäßig im Hintergrund erfolgreich ausgeführt werden soll.

Vielleicht geben ihnen all diese Punkte einen Einblick, dass es ein langer Weg von einem Beispielskript bis zu eine Lösung für einen Kunden oder sogar zu einem Produkt für den Markt ist. Als Ergänzung finden Sie hier eine kleine Übersicht für eine eigene Abschätzung bzw. zur Weiterentwicklung für ihr eigenes Projekt.

Zeitschätzung

Die Planung von Softwareprojekten ist oft durch Fehleinschätzungen der verschiedenen Tätigkeiten und dem damit verbundenen Aufwand verbunden. So werden sehr häufig die Themen “Test“, „Dokumentation“ aber auch Randbereich wie Planung und Vertrieb unterschätzt.

Diese Ausführungen können natürlich kein Ersatz für professionelle Beschreibungen von Entwicklungsmodellen sein. Suchen Sie im Internet oder Buchhandel einfach mal nach Begriffen wie Wasserfallmodell, V-Modell (bei öffentlichen Auftraggebern oft verwendet) und "Rational unified Prozess"

Gerade Entwickler unterliegen oft dem Versuch im Kopf schon den Code zu entwerfen und schnell eine große Aufwandschätzung abzugeben, die um Welten unter dem späteren realen Aufwand liegt. Der Kern einer Lösung kann vielleicht ein 1-2 Tagen tatsächlich durchdacht und codiert werden, aber bis die komplette Lösung einen brauchbaren Stand erreicht hat, sind noch viele weiteren Tage erforderlich. Folgende Tabelle könnte ein erster Anhaltspunkt sein.

Aufwand Tätigkeitsbereich

10%

Analyse und Design

10%

Projektmanagement

50%

Implementierung/Codierung

15%

Test

5%

Systemkonfiguration

10%

Dokumentation

Die Tabelle ist nicht als zeitlicher Ablauf zu verstehen. Eine genauere Einschätzung erhalten Sie, wenn Sie die verschiedenen Tätigkeiten wirklich einmal komplett Aufschlüsseln, mit Aufwänden und vor allem auch mit Personen versehen.

Die nachfolgend aufgeführten Tätigkeiten erheben nicht den Anspruch einer Vollständigkeit und sind auch nicht in jedem Fall erforderlich. Welche Tätigkeiten Sie mit Personen und Aufwänden zu versehen haben, hängt stark von dem jeweiligen Projekt und der Gesamtgröße ab. Ganze Firmen, Produkte, Diplom und Doktorarbeitenarbeiten beschäftigen sich mit diesem Thema.

 Auch hier eine Mustertabelle, wie so etwas aussehen könnte.

Top Thema Aufwand Person

Organisation

 

Meetings

 

 

 

Zeiterfassung

 

 

 

Ansprechbar sein

 

 

Produktplanung

 

Aufnehmen von Anforderungen und wünschen

 

 

 

Erstellen von Meilensteinen

 

 

 

Bestimmen von Prioritäten

 

 

 

Pflichtenheft

 

 

 

Marktbeobachtung

 

 

 

Änderungen von Schnittstellen zu anderen (Fremd-)Produkten

 

 

Dokumentation

 

Installationsdokumentation

 

 

 

Handbuch für Anwender

 

 

 

Handbuch für Administratoren

 

 

 

Knowledgebase pflegen/entwickeln

 

 

Entwicklung

 

Modularisierung

 

 

 

Objektmodell

 

 

 

Codieren

 

 

 

Entfehlern

 

 

 

Codedokumentation

 

 

Design

 

Programmoberfläche

 

 

 

Icons, Farben, Stylesheets

 

 

 

Menustrukturen

 

 

Qualitätssicherung

 

Entwickeln von Testfällen

 

 

 

durchführen der Test (Bedienung, Installation, Update)

 

 

Support/Training

 

Betreuung der Produktanwender

 

 

 

Betreuung bei Installation/Update

 

 

 

Training

 

 

 

Fehlersuche

 

 

Vertrieb und Marketing

 

Produktdatenblätter und Internetpräsenz

 

 

 

Messen, Preislisten

 

 

 

Aufbau Partnernetz und Vertriebsstrukturen

 

 

Sie können solche eine Tabelle natürlich zu einmaligen Bestimmung der Gesamtkosten nutzen. Sie können aber den Aufwand auch einfach in "Stunden  pro Zeiteinheit" angeben und damit eine Art Ressourcenplanung während eines Entwicklungszyklus machen. Sehr oft werden Sie nämlich feststellen, dass Sie einfach zu bestimmten Zeiten "zu wenig Personal" haben. Hinzu kommt. dass die Phasen bei Projekten nicht "gleichverteilt" sind. Am Anfang überwiegt sicher die Projektplanung. Dann folgt ein Schwerpunkt beim Codieren und Testen. Die Anwenderschulungen und Handbücher werden dann eher gegen Ende erstellt, während die Projektsteuerung und Dokumentation die ganze Zeit entsprechende Ressourcen bedarf.

Sie sehen also, dass neben dem kleinen Baustein "Codierung" sehr viele andere Aspekte mit zu berücksichtigen sind.