Die Reihenfolge, wie sie eigentlich richtig wäre ...
.. ist weniger umfangreich als es den Anschein hat. Genauso wie Füller
und Papier benötigt werden, um aus einer Idee ein Konzept zu machen, dienen diese Werkzeuge
dazu, Problemlösungen effizienter zu gestalten und überprüfbare Ergebnisse zu erhalten. Die oben aufgezählten und
im Folgenden näher beschriebenen Verfahren dienen der Sicherstellung leistungsfähiger, effizienter und robuster Ergebnisse.
Ein weiterer Aspekt ist die Vergleichbarkeit von Aufgabenstellung und Lösung.
Am Einfachsten sind die einzelnen Phasen, die sich auch durchaus überlappen können, anhand der phasenbezogenen Dokumentationen
nachvollziehbar. In dem Absatz projektbegleitende Dokumente finden Sie eine Übersicht
über diese Dokumentationen, deren Inhalte und welche Projektaufgaben damit abgedeckt werden.
Die einzelnen Projektphasen:
Die Consultingphase wird benötigt um,
(Beispielsweise einen bereits vorhandenen SQL-Datenbankserver mitzuverwenden)
Nachdem in der Consultingphase der Aufgabenumfang und zu verwendende Verfahren und die grundlegenden Programme
(3.rd Party Tools Beispiel Datenbank) festgelegt wurden, startet die Projektmanagementphase, die das Projekt bis zu seinem Abschluß begleitet:
(Wann macht wer was und welche Schritte hängen voneinander ab ..)
Im Anschluß an die Ressourcenplanung beginnen die Phasen Customizing und Entwicklung. Das Customizing bezieht sich auf die eingesetzten Standards
(Verfahren sowie Module) und pflegt die kundenspezifischen Aufgaben ein. In der Entwicklungsphase werden die kundenspezifische Lösungen erstellt,
die durch die Standards nicht abgedeckt werden. Durch die projektübergreifende Verwendung von Standards entstehen Kosten- sowie durch die breitere
Nutzungsbasis Qualitätsvorteile. Ein weiterer Vorteil ist, dass mögliche Fehler oder Probleme nicht überall gleichzeitig auftreten und deren Auswirkungen
somit eng begrenzt werden können. Voraussetzung ist allerdings ein funktionierendes Rüge- und Gewährleistungsmanagement mit möglichst kurzen Reaktionszeiten.
Die kundenspezifische Entwicklung ist die Projektphase mit dem höchsten Risiko - und das erstreckt sich auf alle Bereiche:
Auf der Seite Bausteine Standardmodule stellen wir Ihnen Module zu Verfügung, die dazu dienen, das Risiko dieser Projektphase zu reduzieren und auf
diese Weise Qualität und Termintreue zu gewährleisten. Darüber hinaus gibt es Dokumente, die Ihnen ebenfalls helfen, Projekte nachvollziehbar,
transparent und kostendeckend zu gestalten:
Manche Dokumente sind sehr hilfreich, Bsp. Erstellung von Usecases, andere haben wir (mit sehr gutem Resultat) erweitert (Bsp. Ungarische Notation), andere komplett
neu erstellt (Bsp. Programmierrichtlinien). Zu den Programmierrichtlinien ist zu sagen, dass wir sie aus dem Grund neu verfasst haben, weil die von großen
Softwarehäusern herausgegebenen Muster unseren Anforderungen nicht gerecht werden. Man kann die Einarbeitungszeit in ein fremdes Softwareprojekt auf wenige Stunden
(und bei hausinternen Projekten auf eine 1/2 Stunde) reduzieren, wenn die Regeln eingehalten wurden, die wir auf zwei Seiten zusammengefasst haben. Ebenso schnell
geht dann auch die Fehlersuche, sowie die Fremdwartung. Auf Wunsch präsentieren wir Ihnen unsere Standards und Verfahren, stellen Ihnen diese bei Bedarf zu Verfügung
und schulen Ihre Mitarbeiter in diesen Abläufen. Das Ergebnis ist, dass die Projekte und der Code so transparenter werden. Änderungen an bestehenden Systemen sind mit
vorher überschaubarem Aufwand realisierbar. Sollten sich diese Aussagen nicht mit Ihren Erfahrungen decken, dann sprechen Sie uns bitte an. Sowohl die Objekt-
als auch die threadgestützte Softwareentwicklung eröffnet in diesem Zusammenhang völlig neue Möglichkeiten.
|
|
Anforderungsanalyse sowie die Definition des Funktionsumfangs sind die Voraussetzungen für das Projektmanagement.
(Ohne die Aufgabe zu kennen, ist es schwierig zu sagen, wie lange sie dauert). Ausserdem ist das Dokument bei
Projektende der Maßstab für den zu realisierenden Funktionsumfang. Aus dem Fachkonzept leitet sich die
Checkliste ab, ob alle Anforderungen erfüllt sind. Das Fachkonzept ist auch der Maßstab, ob nachträgliche Änderungen
innerhalb des Projektrahmens zu realisieren sind, oder ob es sich um Projektänderungen handelt, die Einfluß auf
Funktionsumfang, Zeitvorgaben sowie Budget haben.
Das DV-Konzept beschreibt die Umsetzung der Anforderung in eine DV-konforme Lösung. Es beinhaltet alle Module, Schnittstellen,
Datenformate, sowie ein OOP-Design (Object Orientiertes Programmdesign). Zusammen mit der Quellcode- (auch Inline-)
Dokumentation ergibt sich so eine lückenlose Ablaufdokumentation. Diese ist wichtig, damit bei späteren Änderungen
ermittelt werden kann, an welchen Stellen in das System eingegriffen werden muß, und wie groß der Änderungsaufwand ist. Inhalt,
Usecases sowie Testfälle müssen dem letzten Stand entsprechen. Sie wollen doch schließlich wissen, wofür Sie Ihr Geld ausgegeben
haben!
Kommt ein relationales Datenmodell oder eine Datenbank zum Einsatz, dann beschreibt dieses Dokument die Datenformate
(bei Datenbanken die Tabellen) sowie deren Beziehungen zueinander. Besonderes Gewicht haben hierbei Primärschlüssel,
Sekundärschlüssel und der Bezug zwischen den einzelnen Tabellen bzw. Dateien.
|
Im Grunde ist an dieser Stelle (ebenso wie zur Qualitätssicherung) nicht mehr viel zu sagen:
Durch eine sorgfältige Analyse unterschiedlichster Projekte haben wir eine Reihe immer gleicher
Aufgabenstellungen ermittelt. Für diese Anforderungen haben wir projektübergreifende Lösungen in Form von Standards,
(Bsp. Programmierrichtlinien, erweiterte ungarische Notation), Modulen (siehe Bausteine Standardmodule) und Systemen (siehe IP-Mediation
und Datenbanken) entwickelt. Durch diese so entstandenen Standards können wir Ihnen die beschriebenen
Lösungen anbieten, und da alle unsere Standardlösungen frei von Rechten Dritter sind, auch als
Wiederverwertungslizenzen bzw. als Sammellizenz. (Bsp. Softwarehersteller oder zentrale It-Abteilungen)
|
Wenn Sie diese Seite bis hierhin durchgegangen sind, dann ist jetzt nicht mehr viel zu tun:
Sollten Störungen auftreten, sind die Testfälle um die (anonymisierten) Störungsdaten zu erweitern,
und das korrigierte System ist in einer Testumgebung mit allen Testfällen zu überprüfen.
|
In diesem Dokument wurde die Abgrenzung zu unseren Lösungen innerhalb der einzelnen Kapitel vorgenommen. |
Zurück |