Kundenspezifische Softwareentwicklung
 
Rahmenaufgaben
 
 
Die Reihenfolge, wie sie eigentlich richtig wäre ...
 
  • Consulting (Beratungstätigkeit)
  • Projektmanagement
  • Customising (kundenspezifische Anpassung)
  • Auftragsentwicklung
  •  
    .. 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,
     
  • vorhandene Prozesse zu ermitteln,
  • zu dokumentieren, auf Plausibilität zu prüfen,
  • den Istzustand zu dokumentieren,
  • mit den zuständigen Fachkräften einen Anforderungs- und bei Bedarf einen Änderungskatalog zu erarbeiten,
  • das Ergebnis zu optimieren,
  • den Funktionsumfang zu definieren,
  • zu verwendende Verfahren und oder Programme festzulegen,
  •    (Beispielsweise einen bereits vorhandenen SQL-Datenbankserver mitzuverwenden)
  • sowie die zugehörigen "Usecases bzw. Anwendungsfälle" zu definieren.
  •  
    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:
     
  • Definition von Teilaufgaben,
  • Festlegen der Zeitphasen und Abarbeitungsreihenfolge,
  • Ressourcenplanung,
  •    (Wann macht wer was und welche Schritte hängen voneinander ab ..)
  • Kundenabstimmung, Einpflegen von Änderungen,
  • Budgetkontrolle,
  • Monitoring des Projektfortschritts und ggf. Anpassung der Planung.
  •  
    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:
     
  • Projektlaufzeit (Termintreue),
  • Ergebnissicherung,
  • und Qualitätsmanagement.
  •  
    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:
     
     
  • Programmierrichtlinien
  • Richtlinien zur Erstellung von Usecases
  • Richtlinien zur Erstellung von Testfällen
  • Namensnotationen
  • Ablaufrichtlinien für Entwicklungs-, Abnahme - sowie Regressionstest
  •  
    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.
     
     
    Passbild
     

    Projektbegleitende Dokumente
     
     
  • Das Fachkonzept:
  •  endgültige Version vor! Projektmanagementbeginn
     
    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:
  •  endgültige Version zum! Projektabschluß
     
    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!
     
  • Das DB - Konzept:
  •  endgültige Version zum! Projektabschluß
     
    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.
     
     
    Unsere Erfahrung .. Ihr Vorteil .. unsere Standards und Standardbausteine
     
     
    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)
     
     
    Qualitätssicherung
     
     
    Wenn Sie diese Seite bis hierhin durchgegangen sind, dann ist jetzt nicht mehr viel zu tun:
     
  • Die Nutzungsfälle sind (Usecases) definiert
  • darauf aufbauend sind Testfälle definiert worden, mit denen auch die Entwicklungstests gemacht wurden.
  • Für die Übergabe- bzw. Abschlußtests können Sie als Kunde weitere, eigene Testfälle definieren. (Auf Basis der Usecases).
  • Bleibt nur noch die Wartung im laufenden Betrieb:
  •    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.
     
     
    Abgrenzung
     
     
    In diesem Dokument wurde die Abgrenzung zu unseren Lösungen innerhalb der einzelnen Kapitel vorgenommen.
     
     
     
    Zurück