Session D-LARG

Konvertierung von Großprojekten

Alf Borrmann
Wizards & Builders GmbH


Agenda

  • Was ist ein großes Projekt
  • spezielle Anforderungen an Großprojekte
    • Bestandsaufnahme
    • Vorgehensweise festlegen
    • Planung
  • Ausblick

Projektziele

  • bessere Performance
  • leichter zu bedienende Oberfläche
  • bessere Anpaßbarkeit an neue Forderungen
  • Projekt läuft, z.Z. etwa Halbzeit

Projekt-Randdaten

  • System für Versicherungs-Außendienst
  • ca. 2500 Installationen
  • Datenverbindung zur Firmenzentrale
  • Basissystem FPW 2.6

Inhalt des Altsystems

  • Code
  • Formulare
  • Geschäftsprozesse

Mengengerüst

  • ca. 200 Projektdateien
  • ca. 600 Formulare
  • ca. 6400 Funktionen in Prozedur- und Formulardateien
  • ca. 200.000 Zeilen Code

Technische Randdaten

  • starke Modularisierung
  • Nutzung von Arrays in public-Variablen
    • public-Variablen für Nachrichtenaustausch
  • keine Nutzung von GenscreenX: Formulare im .SPR-Code angepaßt

Dokumentation

  • „Dokumentation im Code“
  • keine Cross-Reference der Variablen
  • keine Variablendokumentation
  • Aufteilung auf viele Projekte: keine Xref-Listen möglich
  • keine Dokumentation der Geschäftsprozesse außerhalb des Codes
    • schlechte Nachvollziehbarkeit der Abläufe
  • Fachkonzepte lagen vor
    • Anbindung des Codes an die Fachkonzepte nicht nachvollziehbar

Der Projektplan

  • Termine
  • Teilprojekte
  • Programmierteam von 8 Personen
    • 16 Mannjahre Programmierleistung
    • zusätzlich: Test, Dokumentation, Datenkonvertierung

Konvertierung, die erste:

  • Konvertierung von Code
  • Codekonvertierung heißt:
    • Übernahme der Funktionsaufteilung
    • Übernahme der FPW 2.6-Anweisungen

Vorgehensweise

  • keine 1:1-Konvertierung
    • dadurch keine Verbesserung der Codestruktur
    • keine Verbesserung der Dokumentation
  • durch Module des Altsystems Mapping auf Objekte möglich
    • jedes Projekt ein Objekt
    • jede Prozedur eine Methode

Codekonstruktionen I

  • in FPW 2.6:
    • Arrays als „Objekte“
    • Datenspeicherung in Arrayvariablen
    • Zugriffsfunktionen als Objekte
  • „Verteilerfunktionen“
    • gesteuert durch Parameter
    • „do case“-Anweisungen mit rekursivem Aufruf
    • entsprechen mehreren Methoden eines Objektes
    • Beispiel: „Doit( <eigentliche Tätigkeit>)

Codeprobleme

  • Arrays als Objekte
    • Durchbrechen des Zugriffs auf Arrays per zugehöriger Funktion
    • Kapselung durchbrochen
  • Verteilerfunktionen
    • bei Konvertierung keine saubere Schnittstellenbeschreibung des Objektes möglich
    • erfordert hohen Aufwand für Parameterprüfung (Laufzeitprobleme)

Codekonvertierung: weiteres

  • FPW 2.6-Code macht keinen Gebrauch von VFP-Features
    • Parameterprüfung zur Laufzeit
    • kein Nutzen von neuen Parametern in seek(), kein keymatch( )
    • keine „Outer Joins“ in SQL-Statements, stattdessen unions
    • ...

Folgen Codekonvertierung

  • keine Verbesserung des Laufzeitverhaltens
  • Fehleranfälligkeit wird bei Codekonvertierung übernommen
  • konvertierter Code hätte keine OO-Struktur

Konvertierung die zweite:

  • Analyse der Funktionen
  • Aufbau eines Objektmodells
  • Trennen der Geschäftsprozesse vom Code
    • Aufbau einer Informationsdatenbank

Analyse der Funktionen

  • Projektanalysedatenbank
    • implementiert in VFP
    • Werkzeug, um Informationen zu bekommen
    • Kategorisierung der Projektteile möglich

Tabellenaufteilung

  • Projektgruppen, Projekte, Programme, Funktionen
  • jeweils eigene Dokumentationsmöglichkeit
    • vom Code unabhängige Beschreibung des Ablaufs
  • Vergabe von Kategorien für Funktionen und Projekte

Übergang zum OO-Design

  • Tabelle zum Modellieren von Objekten
  • abhängige Tabelle mit Methoden
  • Verknüpfung mit beliebigem Projektteil
  • Benennung mit aussagekräftigem Namen möglich
  • Navigation vom Quellcode zur Objektmethode möglich

Projektrepository

  • Rational Rose
    • übernimmt die graphische Darstellung
    • Erzeugung eines VFP-Klassengerüstes möglich
  • Übergabetools

Abschluß Projekttechnik

  • 1:1-Konvertierung I.d.R. nicht möglich
  • genaue Analyse des gefundenen Codes nötig
  • ohne Projektsetup keine Aussagen über Aufwand oder Vorgehensweise möglich

Projektplanung

  • Aufteilung des Projektes in Teilschritte
    • Formulierung der Schritte in MS-Project
    • Aufteilung der Tasks auf Mitarbeiter
  • Personalplanung

Projektverfolgung

  • Verschieben von Milestones sofort berichten
  • keine neuen Features zulassen
  • Basis für jeden nächsten Schritt: Festlegung der zu implementierenden Funktionen
    • notfalls selbst festlegen

Teambildung

  • Übereinstimmung in der Verfolgung der Projektziele
    • Teammitglieder mit Privatzielen nicht tragbar
  • „soft skills“
    • Teamfähigkeit
    • Teamführung
    • „Marketing“
  • Zu entwickelnde Fähigkeiten
  • Schulung reicht nicht
    • Zeitplanung für Ausbildung
    • Produktion von Code so spät wie möglich
  • Rolle des Supervisors
    • offenlegen der „stilen Post“
  • Widerstände und Teamfraktionen

Zusammenfassung

  • Konvertierung auf Codeebene nicht wünschenswert
    • kein Gewinn an Transparenz
    • jede einzelne Codezeile muß geprüft werden
    • OO-Struktur nicht automatisiert erreichbar
  • Teamstruktur kritischer Faktor
    • Klarheit der Aufgabenverteilung

Literaturverzeichnis

  • Brooks, The Mythical Man Month, Addison-Wesley, 1979
  • Gilb, Principles of Software Engineering Management, Addison-Wesley, 1988
  • Maguire, Debugging The Development Process, Microsoft Press, 1994
  • Page-Jones, Praktisches DV-Projektmanagement, Hanser,1991
  • Pagel/Six, Software Engineering, Addison-Wesley, 1994
  • Pigoski, Practical Software Maintenance, Wiley, 1996
  • Webster, Pitfalls of Object-Oriented Development, M&T, 1995
  • Yourdon, Death March Projects, Prentice Hall, 1997
  • Grady, Practical Software Metrics for Project Management and Process Improvement, Prentice Hall, 1992
  • McConnell, Rapid Development, Microsoft Press, 1996
  • Hentzen, The 1997 Developer‘s Guide, Hentzenwerke, 1997
  • Wallmüller, Software-Qualitätssicherung in der Praxis, Hanser, 1990