Logo Schrift
Moebiuskreis Logo
financialSoftwareEvolutionTeam
Ohne professionelle Planung kein sinnvolles Ergebnis!
Unser Vorgehen in der Analysephase
Planung

Planung

Bitte wählen Sie Ihren gewünschten Bereich durch Anklicken des entsprechenden Symbols:
Allgemeines

Allgemeines

Initialisierung

Initialisierung

Planung

Planung

Realisierung

Realisierung

Test

Test

Produktion

Produktion

Im Bereich „COBOL Nachfolge / Vorgehensmodell / Planung (Analyse)“ finden Sie folgende Informationen:

  • Allgemeines zur Vorgehensweise in der Planungsphase
  • die Aufgaben der Projektleitung in dieser Phase
  • Erstellung und Inhalt der fachlichen Analyse
  • Erstellung und Inhalt der technischen Analyse
  • Gedanken zur Planung der Datenmigration
  • Erstellung von Vorgaben für den Entwicklertest

Für Details bitte einfach die entsprechenden Reiter anwählen!

Im Rahmen der Projektdefinitionsphase wurden schon alle wichtigen Eckdaten des künftigen Projekts und die notwendigen Inhalte der Detailanalyse ermittelt. Die Detailplanung und Analyse bewegt sich jetzt innerhalb des festgelegten Rahmens.

Spätestens zu Beginn der Analysephase wird ein Projektleiter bestimmt. Dieser kann sowohl vom Kunden als auch von finSET gestellt werden, bei kleineren Projekten kann diese Position durchaus auch in Personalunion mit einem der Analysten besetzt sein.

Wenn finSET den Projektleiter stellt, ist dieser mit einer Reihe von Dokumenten-Templates für die Projektführung (Excel, Word) ausgestattet. Diese kommen zur Anwendung, wenn der Kunde keine eigenen Vorgaben für die Dokumentation macht und werden an die speziellen Erfordernisse des Projekts angepasst.

Zeitlich startet in der Regel die Detailanalyse des abzulösenden Systems und die Festlegung des resultierenden fachlichen Funktionsumfangs eher als die technische Analyse, da letztere schon profunde Kenntnisse der zu realisierenden Funktionen bedingt.

Die fachliche Analyse wird in der Regel von anderen Personen durchgeführt als die technische Analyse, da hier andere Schwerpunkte in Bezug auf die Kenntnisse gefordert sind.

Zwischen fachlicher und technischer Analyse erfolgt eine laufende, enge Abstimmung. Beispielsweise gibt die fachliche Seite bekannt, wenn belastbare Teilergebnisse vorliegen, die bereits technisch analysiert werden können. Die Koordination erfolgt dabei über den Projektleiter.

Die Projektleitung hat in der Analysephase unter anderem die folgenden Aufgaben:

  • Sicherstellung der Einhaltung von vereinbarten Konventionen, z. B. bezüglich der Dokumentation oder der Benutzung von kundeneigenen Systemen, sofern diese während der Analysephase eingesetzt werden.
  • Sicherstellen, dass die vom Kunden genannten internen Ansprechpartner tatsächlich im erforderlichen Umfang und zur erforderlichen Zeit zur Verfügung stehen und dass entsprechende Vertretungsregelungen getroffen werden.
  • Sicherstellen, dass das Projektteam unter förderlichen Bedingungen hinsichtlich Arbeitsplatz, technischer Ausstattung, Zugang zu Test- und Produktivsystemen, Programmsourcen usw. arbeitet.
  • Zeitliche, personelle und räumliche Koordination aller anfallenden Tätigkeiten und Sicherstellen der Verfügbarkeit der nötigen Resourcen (Personen, Räumlichkeiten, Konferenztechnik usw.).
  • Organisation von jour-fixes, bei denen regelmäßig der Projektfortschritt und offene Punkte besprochen werden (wenn sinnvoll, getrennt für den fachlichen und technischen Bereich).
  • Methodische Unterstützung der Analysten bei speziellen Aufgaben, z.B. Mithilfe bei der Erstellung von Beschlussvorlagen und ähnliches.
  • Regelmäßige Berichte, soweit sie vom Kunden oder finSET gefordert werden.
  • Information der Analysten, wenn parallel laufende Aktionen die Analysearbeit beeinflussen, z.B. Programmänderungen in der umzustellenden Software.
  • Einleitung der Eskalation, wenn Unstimmigkeiten auftreten, Terminverzögerungen drohen oder sonstige ungewöhnliche Umstände dies rechtfertigen.

Die fachliche Analyse beinhaltet die Sichtung und Dokumentation der bestehenden Anwendung sowie der zusätzlichen inhaltlichen Anforderungen an die zu konzipierende objektorientierte Software. Das Resultat sind Aufzeichnungen, die als Basis für die technische Analyse dienen.

Zunächst wird als Bestandsaufnahme eine detaillierte Aufstellung aller abzulösenden Softwarekomponenten erstellt bzw. aus den Unterlagen des Kunden entnommen.
mehr...
  • Sourcen von allen umzustellenden Programmen und Modulen inkl. zugehöriger Copy-Strecken und eventueller Makro-Generierungsanweisungen
  • Verfügbare Beschreibungen der umzustellenden Programme
  • Beschreibung aller verwendeten Datenbanktabellen, Index- und sonstigen Dateien
  • Schnittstellenbeschreibung zu zentralen Funktionen, die von der umzustellenden Software verwendet werden
  • Bedieneroberfläche (Erfassungsmasken usw.) inkl. repräsentativer Hardcopies
  • Listbilder von Auswertungen und sonstigen Batch-Programmen
  • Schnittstellenbeschreibungen (Inhalt, zeitliche Aspekte, Abhängigkeiten)
  • Jobcontrol inkl. Angaben zur zeitlichen Abfolge und Abhängigkeiten
  • Übergreifende fachliche und organisatorische Beschreibungen, soweit für das Vorhaben von Relevanz

Wenn im Rahmen der Projektdefinitionsphase bekannt wurde, dass Erweiterungs- oder Fehlerbehebungsanforderungen vorliegen, dann wird entschieden, welche hiervon Teil des Projekts werden sollen. Die ausgewählten Anforderungen werden bei den folgenden Schritten bereits berücksichtigt.

Es wird eine Gliederung der Softwarekomponenten in fachliche Aspekte vorgenommen. Wenn vorhanden, können diese Angaben aus bestehenden Dokumentationen übernommen werden.

Die Quellprogramme werden für das Projekt kopiert und mit Kommentarzeilen versehen, wobei schon bestehende Auswertungsmöglichkeiten (Crossreferenzen über Sourcen / Compilerlisten und ähnliches) natürlich genutzt werden, wo möglich.
mehr...

Die Untersuchung des Quellcodes umfasst unter anderem:

  • Zugehörigkeit zur fachlichen Gliederung
  • Grad der Strukturierung und Eignung für automatische Umstellungen.
  • Verwendete Datenbanktabellen und Dateien.
  • "Tote" Zweige, d.h. solche, die laut Kunde oder aus technischen Gründen nicht mehr durchlaufen werden.
  • Verwendung von Standard-Routinen inkl. Routinen, die in der jeweiligen Sprache unterstützt werden (z.B. COBOL-Sort, Aufrufe von Systemroutinen über Assembler-Unterprogramme und ähnliches).
  • Spezielle Routinen, die aber im Sinne der Objektorientierung durch Standard-Funktionen ersetzt werden sollten.
  • Spezielle Vorkehrungen für den Ausnahmefall (Declaratives für den Fehlerfall, Lockbehandlung bei Datenzugriffen, programmgesteuerter Rollback u. ä.).
Aus der Summe der ausgewerteten Programmsourcen und ggfs. der Job-Control werden Ergebnisse zusammengestellt, die den Schnittpunkt zur folgenden technischen Analyse bilden.
mehr...

Folgende Aspekte sind für die technische Analyse relevant:

  • Datenbank-Design; dieses kann 1:1 bestehen bleiben, wenn schon optimal. Anderenfalls werden umzustellende Indexfiles oder ähnliches in bestehende / neue Tabellen integriert und ein entsprechendes Redesign der Datenbank vorgenommen.
  • Allgemeines Oberflächendesign aus Anwendersicht, d. h. die Anforderungen hinsichtlich Optik, Bedienbarkeit usw. werden zusammengestellt.
  • Fachliche Inhalte der einzelnen Screens der neuen Oberfläche mit Zusammenstellung der durchzuführenden Prüfungen und der Zugehörigkeit zu den Datenbankfeldern.
  • Wenn Auswertungen über spezielle Generatoren erzeugt werden sollen: Zusammenstellung der benötigten Daten in geeigneter Form.
  • Zusammenstellung aller benötigten Dateizugriffe, die in Form spezieller Datenbank-Zugriffsklassen und -Methoden zu realisieren (oder bereits vorhanden) sind.
  • Zusammenstellung von bestehenden Standard-Funktionen, die in der Zielwelt bereits existieren und zu verwenden sind (falls die Zielwelt bereits feststeht).
  • Zusammenstellung von benötigten Standardfunktionen mit Varianten, die zur Entwicklung von Bereitstellung entsprechender Klassen und Methoden führen sollen.
  • Kennzeichnung von individuellem Code, der in der neuen Umgebung individuell zu erstellen ist.

In stetiger Abstimmung mit der technischen Analyse wird die fachliche Analyse so weit verfeinert, dass sie zusammen mit den zugehörigen Quellcodes der umzustellenden Software als alleinige Quelle für die technische Analyse dienen kann.

Die fachliche Analyse wird bei Fertigstellung förmlich vom Kunden abgenommen.

Die technische Analyse stellt die Ausgangsbasis für die folgende Realisierungsphase dar. Als Basis dient dabei die fachliche Analyse lt. jeweiliger Vorgabe.

Wenn im Rahmen der Projektdefinitionsphase bereits eine konkrete "Zielwelt" festgelegt wurde, dann werden die folgenden, der Zielwelt-Findung dienenden Aktivitäten übersprungen.

Zunächst werden alle Aspekte zusammengestellt, die für die Entscheidungsfindung in Bezug auf die Zielwelt von Bedeutung sind.
mehr...
  • Welche speziellen Anforderungen werden an die zu erstellende Software hinsichtlich Datenvolumen, Performance, Verfügbarkeit, Bedienbarkeit usw. gestellt?
  • Gibt es im Unternehmen schon Anwendungen, deren technische Basis sich für das vorliegende Projekt eignet und deren Anwendung vom Unternehmen strategisch gewünscht ist?
  • Gibt es sonstige strategische Überlegungen im Unternehmen oder auf Vorschlag von finSET, die in Bezug auf die Auswahl der Zielwelt von Bedeutung sein oder werden könnten, z.B. in Bezug auf die Zukunftsfähigkeit oder die Resourcen des Kunden in der Zielwelt?
  • Die bestmögliche Eingliederung in bereits bestehende und als strategisch sinnvoll eingestufte Bestandssysteme wird angestrebt.
Bei der Auswahl der Zielumgebungen werden diverse Optionen betrachtet.
mehr...
  • Generell kommen alle objektorientierten Sprachen in Frage.
  • Typische Sprachen sind: Java, C#, C++
  • Datenhaltung typischerweise auf relationalen Datenbanken, wie z.B. Oracle, Microsoft SQL etc.
  • Benutzeroberfläche GUI oder Browser
  • Systemumgebung typischerweise UNIX (auch auf Midrange/Großrechnern)
  • Architektur Browser-basiert oder Client/Server
  • Zugriffsintensive Operationen auf der Server-Seite evtl. auch als "Stored Procedure"
Nach getroffener Auswahl der Zielwelt wird diese detailliert beschrieben.
mehr...
  • Zu verwendende Programmiersprache und zugehörige Entwicklungstools
  • Zu verwendende Datenbank und technische Realisierung der Datenbankdefinition sowie der Zugriffsmethoden
  • Zu verwendendes User-Interface
  • Zu verwendende Reporting-Tools
  • Hardware und Betriebssystemsoftware, unter der die Anwendung laufen soll, inkl. der zu verwendenden Job-Control
  • Technische Basis für Schnittstellen zu anderen, bereits vorhandenen oder während der Projektlaufzeit entstehenden Systemen

Wenn die Entscheidung für eine bestimmte Zielwelt gefallen ist, beginnt die Detailarbeit der Analyse.

Zunächst werden Übersichten über die zu erstellenden bzw. zu verwendenden Komponenten erstellt.
mehr...
  • Welche vorhandenen Klassen und Methoden können direkt verwendet und welche müssen neu entwickelt oder angepasst werden?
  • Gibt es seitens finSET oder anderer Seite bereits vorhandene betriebswirtschaftliche oder technische Klassen, die wir mit einbeziehen können und deren Verwendung individuelle Entwicklungsarbeit erspart?
  • Welche Datenbanktabellen, Beziehungen usw. sind zu ändern oder neu anzulegen?
  • Welche Erfassungs- und Abfragedialoge sind zu konzipieren?
  • Welche Schnittstellen sind zu realisieren?
  • Welche Reports sind zu generieren?
  • Welche Funktionalitäten müssen individuell codiert werden?

Ausgehend von den Übersichten lt. vorhergehendem Punkt werden für jede dort genannte Komponente die Details in einer Tiefe beschrieben, die für die geplante Form der Realisierung ausreichend ist. Die Tiefe der Darstellung variiert dabei von relativ oberflächlich, wenn Programmierer mit umfassenden Kenntnissen die Realisierung übernehmen bis sehr genau, wenn an Outsourcing oder Offshoring gedacht wird.

Bevor die technische Analyse beendet wird, erfolgt noch ein Quercheck gegen die fachliche Analyse, ob wirklich alle dort genannten Funktionen und Aspekte berücksichtigt sind.

Danach erfolgt eine Zusammenstellung aller für die Realisierung erforderlichen Resourcen.
mehr...
  • Personelle Resourcen für Projektleitung und eigentliche Entwicklung mit Angabe der erforderlichen Fertigkeiten.
  • Optional, da auch als eigener Schritt planbar: personelle Resourcen für Testmanagement und Test-Durchführung sowie für die folgenden Schritte (Schulung, Go-Live, Post-Go-Live).
  • Technische Resourcen, die für die Entwicklungsarbeit gebraucht werden (Entwicklungsumgebung und Umgebung für den Entwicklertest)

Die technische Analyse wird vom Kunden formell abgenommen.

Wenn die Realisierung durch den Kunden oder Dritte vorgenommen werden soll, endet die Tätigkeit von finSET an dieser Stelle. Alle entstandenen Analyseergebnisse sind Eigentum des Kunden und können von diesem für die nächsten Projektschritte weiterverwendet werden.

Wenn laut Kundenwunsch finSET die Realisierung ganz oder teilweise anbieten soll, werden vor Abgabe eines Angebots diverse Punkte geklärt und festgelegt.
mehr...
  • Ungefährer Start- und Endtermin für die Realisierung
  • Definition von Teilmengen, die getrennt kalkuliert und geliefert werden sollen (sog. "Software Deliverable Objects")
  • Angabe, unter welchen Umständen Optionen wie Outsourcing oder Offshoring im Angebot berücksichtigt werden sollen.
  • Angabe, ob das Angebot nur die reine Realisierung oder auch die folgenden Stufen (Test, Schulung, Go-Live, Post-Go-Live) umfassen soll, oder ob diese Stufen in einem eigenen Zyklus betrachtet werden.

Auf Basis der vorgenannten Punkte wird finSET ein detailliertes und verbindliches Fixpreis-Angebot für die (Teil-)Realisierung abgeben, wenn gewünscht. Alternativ kommt auch die Rekrutierung von Fachkräften auf Tagessatzbasis in Frage, die dann in flexibler Form die anfallenden Arbeiten unter Regie des Kunden erledigen.

Wenn von finSET entwickelte Standardklassen und Methoden zum Einsatz kommen sollen, wird für den Einsatz im Projekt ein entsprechender Fixpreis genannt.

Die Migrationsplanung geht von der fertiggestellten technischen Analyse aus. Sie beschäftigt sich mit der Wanderung der Dateninhalte von der alten in die neue technische Welt.

Vertraglich werden technische Komponenten, die aufgrund der Migrationsplanung erstellt oder parametrisiert werden müssen, im Rahmen des Realisierungsangebotes betrachtet.

Für die Migrationsplanung sind vor allem die Unterschiede in der Datenhaltung zwischen bestehender Anwendung und der neu konzipierten Anwendung entscheidend.

  • Wird von Index-File auf Datenbank umgestellt oder von einer Datenbank auf eine andere?
  • Ist der Zeichensatz im Quellsystem und Zielsystem unterschiedlich? Diese Frage ist vor allem bei der Umstellung von fixen Satzstrukturen aus Indexfiles in Richtung Datenbank entscheidend, da hier spezielle Vorkehrungen für die Übertragung numerischer Felder erforderlich sind.
  • Die Migrationsplanung berücksichtigt natürlich auch vereinbarte inhaltliche Unterschiede in der Datenhaltung, d.h. entsprechende Umsetzroutinen müssen mit eingeplant werden.

Bei der zeitlichen Planung der Realisierung der Migration wird berücksichtigt, dass die Migration schon in frühen Phasen des Tests hilfreich ist, um von Anfang an ein realistisches Datengerüst zur Verfügung zu haben.

Um in den Entwicklern über den rein technischen Test hinaus sinnvolle und möglichst vollständige funktionelle Tests zu ermöglichen, wird bereits im Rahmen der technischen Analyse eine Vorgabe für die zu erfüllenden Testvorfälle erstellt.

Die Entwicklertests sind integraler Bestandteil der gesamten Teststrategie, siehe entsprechenden Abschnitt. Das bedeutet, dass diese Tests inhaltlich einen speziell gewählten Ausschnitt aus dem technischen Basistest darstellen.

Bezüglich der Vorgabe zur Testdokumentation gilt, dass nach Möglichkeit das gleiche Tool verwendet wird, das auch bei allen anderen Testphasen Verwendung findet. Wenn dies nicht möglich ist (z.B. wegen externer Entwicklung mit anderer technischer Umgebung), dann sollten die von der Entwicklerseite angelieferten Testergebnisse nachträglich im zentralen Testtool eingepflegt werden, um eine durchgängige und revisionsfeste Dokumentation aller Testergebnisse zu erreichen.