Logo Schrift
Moebiuskreis Logo
financialSoftwareEvolutionTeam
Wir helfen Ihrer Anwendung in die objektorientierte Welt
Initialisierung

Initialisierung

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 / Projektinitialisierung“ finden Sie folgende Informationen:

  • wie aus einem vertrieblichen Kontakt ein Projekt wird
  • welche Informationen zusammengetragen werden, um den Umfang der nötigen Analysearbeiten seriös einschätzen zu können

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

Die Projektanbahnungsphase läuft komplett im Rahmen der Akquisition ab, ist also für den Kunden prinzipiell kostenlos und unverbindlich.

Voraussetzung für eine Projektanbahnung ist die Existenz eines Programmpakets in prozeduraler Sprache (z.B. Cobol), das aus Sicht des Kunden in eine objektorientierte Umgebung umgesetzt werden soll.

Um den Umfang der erforderlichen Arbeiten grob einschätzen zu können, wird von finSET eine Voruntersuchung durchgeführt. Hierfür bedarf es einer Rahmenvereinbarung, die finSET die Einsicht in alle für die Voruntersuchung relevanten Eigenschaften des bestehenden Programmpakets ermöglicht. Im Rahmen dieser Vereinbarung werden auch die Ansprechpartner im Hause des Kunden festgelegt und verständigt. Der Umfang der Voruntersuchung bewegt sich zwischen einem Tag und maximal einer Woche.

Die Voruntersuchung stellt die Voraussetzung für die Projektdefinitionsphase (siehe nächsten Reiter) dar. Es werden daher fachliche und technische Aspekte gesichtet und dokumentiert, aber nur in einer Tiefe, die es ermöglicht, den Aufwand für die eigentliche Projektdefinition einzuschätzen. Alle gewonnenen Erkenntnisse werden direkt in die Rahmendokumente der Projektdefinition eingefügt, um spätere Übertragungsarbeiten zu vermeiden.

Das Ergebnis der Voruntersuchung ist eine Einschätzung von finSET bezüglich des Aufwands für die Projektdefinitionsphase. Diese Einschätzung teilt finSET dem Kunden mit.

Wenn der Kunde entscheidet, den nächsten Projekt-Schritt zu gehen, erstellt finSET ein Angebot für die Projektdefinitionsphase. In diesem Angebot sind die in der Projektdefinitionsphase zu erwartenden Ergebnisse detailliert beschrieben.

Das Angebot für die Projektdefinitionsphase beruht in der Regel auf einer geschätzten Anzahl von zu erbringenden Personentagen unter Rahmenbedingungen (z.B. bezüglich der Mitarbeit des Kunden, Projektleitung usw.), die vorab abgestimmt werden. Fixpreisangebote sind möglich, wenn das Projekt gut überschaubar ist und wesentliche Entscheidungen (z.B. über das Zielsystem) schon vorliegen.

Die Projektdefinitionsphase stellt eine Vorstufe zur eigentlichen Planungsphase (Analysephase) dar. Ziel der Projektdefinition ist es, den genauen Umfang des Projekts mit allen relevanten Aspekten zu untersuchen und somit den Projektumfang richtig einschätzen zu können.

Wenn auf Grund des Umfangs erforderlich, wird ein regulärer Projektleiter bestellt (Aufgaben Projektleitung siehe Planungsphase), ansonsten werden vom Kunden die Ansprechpartner für die verschiedenen fachlichen und technischen Bereiche benannt und über die anstehende Untersuchung informiert. Nach Möglichkeit wird schon zu diesem Zeitpunkt die Sprache der zu erstellenden Dokumente festgelegt, damit die erarbeiteten Inhalte später nicht übersetzt werden müssen.

Die Analyse startet mit der Untersuchung der bestehenden Software. Die Zielsysteme werden zeitlich nachgelagert betrachtet, sobald genügend Informationen über die fachlichen und technischen Anforderungen bestehen.

Die Ergebnisse der Projektdefinition werden direkt in den Dokumenten der späteren Planungs- /Analysephase eingetragen, d.h. diese Dokumente füllen sich bereits zu einem gewissen Teil. Dies erspart in der nächsten Phase die Übernahme der Ergebnisse bzw. einen Verweis auf diese, sofern die Sprache schon endgültig gewählt wurde.

In Bezug auf das umzustellende Softwareprodukt (Ausgangsprodukt) werden diverse Aspekte untersucht.
mehr...
  • fachlicher Umfang des Produkts mit Abgrenzung zu angrenzenden Produkten
  • Programmiersprache(n) und Umfang des vorhandenen Quellcodes mit genauer Abgrenzung der im Rahmen des Projekts zu betrachtenden Komponenten
  • Zustand des Quellcodes in Bezug auf Strukturierung, Leserlichkeit, Dokumentation usw.
  • beim Kunden vorhandenes fachliches und technisches Know-how in Bezug auf das Ausgangsprodukt sowie nötige Fachkenntnisse für die Analysephase
  • vorhandene offene Anforderungen bezüglich
  • Fehlerbehebungen
  • inhaltlicher Erweiterungen
  • Performance-Verbesserungen
  • Verbesserung der Benutzeroberfläche
  • Verbesserungen in der Sicherheit (Ausfallsicherheit, Zugriffsschutz usw.).
  • "tote Zweige", d.h. Funktionen, die zwar vorhanden sind, aber nicht mehr genützt werden
  • Art der Dateizugriffe (Datenbanken, Indexfiles, Zwischendateien usw.)
  • systemtechnische Einbettung (Hardware, Betriebssystem, Job-Control usw.)
  • Einbettung in zentrale betriebswirtschaftliche Abläufe, z.B. Online-Disposition, Online-Banking, Buchungen, Tagesende-Verarbeitung, internes Reporting inkl. Data-Warehouse, externes Meldewesen usw. Hierbei wird auch festgehalten, in welchen technischen Umgebungen diese zentralen Abläufe realisiert sind
  • direkte Abhängigkeit von anderen Software-Modulen, z. B. im Sinne von:
  • Zugriffe auf zentrale Stammdaten
  • Verwendung von zentralen Zugriffsschutz-Funktionen und Auswahlmenüs
  • Lieferung von Daten an andere Anwendungen, z. B. Buchungsinformationen (Batch oder Echtzeit)
  • Zulieferung von Daten durch andere Systeme
  • bestehende Anforderungen an die Performance, Ausfallsicherheit usw.
  • bestehende Anforderungen an die Usability, z.B. Online-Hilfe je Anwendersprache.
Wenn vorhanden, werden besonders wichtige und kritische Punkte gesondert festgehalten.
mehr...
  • zeitliche Überlappungen mit anderen Projekten, aus denen sich durch Schnittstellen eine direkte Auswirkung auf das geplante Umstellungsprojekt ergibt
  • zentrale Umstellungen im Berechtigungssystem
  • technische Umstellung von Hardware, Betriebssystemsoftware oder Datenbank
  • anstehende gesetzliche Änderungen, die bis zu einem bestimmten Zeitpunkt zu realisieren sind
  • organisatorische Aspekte (Fusionen, Auslagerung von Funktionen, räumliche Verlagerung in einen anderen Sprachraum und ähnliches)
Danach werden die erforderlichen Eigenschaften des Zielsystems untersucht, wobei natürlich die vorhandenen Systemlandschaften sowie strategische Überlegungen des Kunden eine wichtige Rolle spielen.
mehr...
  • Mit welchen technischen Umgebungen muss das Zielprodukt kommunizieren?
  • Welche Systemumgebung soll verwendet werden?
  • Wie ist die gewünschte Software-Architektur (Client-Server, Browser-basiert usw.).
  • In welcher Programmiersprache (z.B. Java, C#, C++) soll realisiert werden?
  • Welche Datenbank ist zu verwenden?
  • Sollen "Stored Procedures" innerhalb der Datenbank verwendet werden?
  • Wie soll die Benutzeroberfläche gestaltet sein?
  • Ist für die Zielumgebung(en) bereits Know-how im Hause vorhanden, oder muss dieses erst aufgebaut werden?
  • Müssen voraussichtliche Hard- und Systemsoftware-Anschaffungen mit eingeplant werden?
Damit sind alle Informationen vorhanden, um die Rahmenbedingungen für das Vorgehen festzulegen.
mehr...
  • Soll zunächst versucht werden, die Funktionalitäten ganz oder teilweise durch eine Standardsoftware abzubilden?
  • Soll das Datenmodell möglichst gleich bleiben oder soll die Leistungsfähigkeit einer relationalen Datenbank so weit wie möglich genutzt werden?
  • Soll die Notwendigkeit kleinerer Änderungen in umgebenden Softwaresystemen in Kauf genommen werden oder ist das unbedingt zu vermeiden?
  • Soll die Umstellung unter Zuhilfenahme von Automatismen möglichst 1:1 erfolgen? Neben dem Vorteil einer (teil-)automatischen Umstellung gibt es hier mögliche Nachteile:
  • nicht alle Bestandteile der bestehenden Software eignen sich für eine automatisierte Umstellung
  • die Lesbarkeit des entstehenden Codes ist nicht optimal
  • der entstehende Code liegt zwar in der Zielsprache vor, aber die Objektorientierung ist nicht gegeben
  • die Benutzeroberfläche orientiert sich nach wie vor an den alten 25 x 80 Bildschirmformaten
  • die Möglichkeiten der relationalen Datenbank werden weiterhin nur zu einem kleinen Teil genutzt
  • Alternativ: soll die Umstellung von den Gegebenheiten rein ergebnisorientiert, d. h. ohne direkte oder indirekte Verwendung des Quellcodes erfolgen? Dies bietet sich z. B. an, wenn der Quellcode nicht als Basis für eine (teil-)automatische Umstellung geeignet oder schlecht auswertbar ist und bedeutet in der Praxis:
  • bezüglich der Benutzeroberfläche werden nur die Ein- und Ausgabedaten zusammen mit deren Beziehungen und Plausibilitäten betrachtet
  • auch die Datenbankoperationen werden unter Beachtung von Relationen und Einschränkungen auf die lesenden und schreibenden Zugriffe der einzelnen Datenmengen reduziert
  • die Auswertungen und Schnittstellen werden in Bezug auf ihren Informationsgehalt analysiert
  • für die technische Realisierung der Zielanwendung finden neben der individuellen Programmierung zu definierende Tools Anwendung, z. B. zur Generierung von Reports
  • Alternativ zu den beiden oben genannten extremen Vorgehensweisen wird es wohl in der Praxis häufig zu einer Mischform kommen, z. B.:
  • Die bestehende Benutzeroberfläche wird inhaltlich (nicht optisch) sinngemäß übernommen und in der Zieloberfläche abgebildet. Dabei werden selbstverständlich Features der neuen Oberfläche, wie z. B. Scroll-Bereiche und ähnliches genutzt.
  • Die Datenbankseite wird auf Optimierungsmöglichkeiten untersucht, bleibt aber im Wesentlichen erhalten. Indexfiles werden durch Datenbanktabellen ersetzt, wobei die Möglichkeiten einer relationalen Datenbank so weit wie möglich genutzt werden.
  • Auswertungen liefern den gleichen Informationsgehalt wie das Altsystem, werden aber durch geeignete Tools erzeugt, wo möglich (ansonsten individuelle Programmierung). Die gewählten Auswertungstools stehen dann natürlich auch für weitere, künftige Auswertungen zur Verfügung.
  • Ein- und Ausgangsschnittstellen bleiben inhaltlich unverändert, nur die Übernahme- bzw. erzeugenden Programme werden umgestellt.
Auf Basis der zusammengetragenen Erkenntnisse werden Zusammenstellungen erzeugt, die als Grundlage für die nächsten Schritte dienen.
mehr...
  • grober Zeitplan, d.h. Start- und Endezeitpunkt für die Analysephase und vorläufige Annahmen für die folgenden Phasen
  • Übersicht über alle Positionen, die im anschließenden Analyseprojekt zu besetzen sind:
  • Beschreibung der Position (Projektleitung, fachliche Analyse, technische Analyse)
  • geschätzter zeitlicher Umfang der Tätigkeit (Intensität und Zeitspanne)
  • nötige Erfahrungen (Skills) der einzusetzenden Personen
  • Vereinbarung, wie diese Personen ins Projekt geholt werden sollen (vom Kunden gestellt oder Vermittlung durch finSET)

Wenn die Realisierung und die darauf folgenden Projektstufen komplett vom Kunden oder Dritten abgewickelt werden sollen, endet das Projekt an dieser Stelle für finSET. Die entstandenen Analyseergebnisse sind natürlich Eigentum des Kunden und können von diesem weiterverwendet werden.

Ansonsten wird finSET sich um Besetzung der Positionen kümmern, die nicht vom Kunden ausgefüllt werden sollen.
mehr...
  • Falls noch nicht geschehen, erfolgt spätestens jetzt eine Abstimmung, in welcher Sprache die Analysedokumente erstellt werden sollen, da dies Auswirkungen auf die geforderte sprachliche Qualifikation der Beteiligten hat.
  • Achtung: Wenn für die Realisierung auch Outsourcing bzw. Offshoring in Frage kommt, sollte zumindest die technische Analyse in Englisch formuliert sein, besser auch noch die fachliche Analyse.
  • finSET eruiert aus den eigenen Reihen oder über externe Verbindungen geeignete Personen, die im geplanten Zeitraum tätig werden könnten
  • finSET stellt das mögliche Team dem Kunden vor
  • Der Kunde nennt organisatorische Vorgaben, die während der folgenden Analysephase zu beachten sind, beispielsweise:
  • Konventionen bezüglich des Zugangs zu Test- und Produktivsystemen, soweit sie für die Durchführung der Analyseaufgabe erforderlich sind
  • Verwendung von internen Tools zur Ablage der entstehenden Projektergebnisse
  • Tools zur Zeiterfassung
  • Tools zur Projektfortschrittsdokumentation
  • Weitere organisatorische Tools, die zu verwenden sind

Nach Übereinkunft über die personelle Besetzung und sonstigen Umstände macht finSET ein Angebot für die (Teil-) Durchführung der Planungs-/Analysephase. Normalerweise werden hier Tagessätze genannt, Fixpreise sind aber bei relativ kleinen und komplett überschaubaren Projekten möglich.