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.
