IEM HERMES. strategische Informatikplanung. Information strategy planning (ISP) Initialisierung. Voranalyse. reduzierte ISP. Business area analysis

Transkript

1 14 Anhang B: Schnittstellen zu Vorgehensmodellen und Methoden 14.1 Die Methode IEM und das Werkzeug IEF Einleitung IEM (Information Engineering Method) ist eine integrierte Methode zur Entwicklung von Anwendungssystemen [IEM 90/2]. Die Methode umfasst den ganzen Lebenszyklus eines Systems, von der strategischen Planung und Entwicklung bis zur Einführung, Nutzung, Wartung und Ablösung. Die Methode wird weitgehend durch das Werkzeug «Information Engineering Facility 1» (IEF) unterstützt. Die folgenden Ausführungen basieren auf praktischen Erfahrungen beim Einsatz des Projektführungssystems HERMES in einem Informatikprojekt des Eidg. Justiz- und Polizeidepartementes (EJPD). Den Kern der Projektinfrastruktur bildeten das Werkzeug IEF und die Methode IEM (IEM/IEF). Zum Verständnis für das Zusammenspiel des Projektführungssystems HERMES mit IEM/IEF sind folgende Hinweise nützlich: HERMES wird in allen Informatikprojekten angewendet. IEM ist hingegen auf die Entwicklung von Software fokussiert. Das Phasenmodell im HERMES legt die essentiellen Eckpunkte der Entwicklung auf der Grundlage der Ergebnisse und Entscheidungspunkte fest. Auch IEM gliedert den Lebenzyklus in Phasen. Während HERMES für die Ergebnisse nur eine grobe Inhaltsstruktur vorgibt, definiert IEM zusammen mit dem Werkzeug IEF eine feinstrukturierte Entwicklungsdatenbank (Enzyklopädie). Die Ergebnisse sind Modelle, die in der Entwicklungsdatenbank gespeichert werden, deshalb liegt innerhalb der Phasen der Fokus auf der Aktivitätsfolge und weniger auf jener der Ergebnisse. Die Erfahrungen haben gezeigt, dass das Projektführungssystem HERMES und das Entwicklungsverfahren IEM/IEF sich gegenseitig ergänzen Schnittstelle HERMES-IEM Die Gestaltung der Schnittstelle zwischen HERMES und IEM basiert auf folgenden Grundsätzen [IEM-EJPD]: Der Rahmen wird vom Projektführungsinstrument HERMES gebildet. 1 Warenzeichen von Texas Instruments Anhang B Seite 14-1

2 Die Ergebnisse der «technischen» Systementwicklung werden vollständig durch IEM/IEF bestimmt. Alle anderen Ergebnisse werden von HERMES übernommen. Die IEM-Phasen werden den HERMES-Phasen und dazugehörigen Entscheidungspunkten zugeordnet (Abb. 14-1). Hierzu wird der «klassische» IEM-Lebenszyklus verwendet. Das Vorgehen in der «technischen» Systementwicklung innerhalb der Phasen wird durch IEM/IEF bestimmt. IEM Information strategy planning (ISP) strategische Informatikplanung HERMES Initialisierung reduzierte ISP Voranalyse Business area analysis Konzept Business system implementation Realisierung Transition Einführung Production Nutzung, Betrieb Wartung Abb Zuordnung der Phasen Seite 14-2 Anhang B

3 Zuordnung der Die folgenden Tabellen zeigen die Zuordnung der zu den n, mit dem Schwerpunkt im Bereich Systementwicklung. Die Phase «Initialisierung» Der Phase «Initialisierung» kann keine entsprechende IEM-Phase zugeordnet werden. Projektantrag Projekthandbuch Projektplan Keine Aktivitäten, Grundlage für den Projektantrag sind aber Ergebnisse der ISP-Phase. Ergänzung der HERMES-Aktivitäten durch: Grobe Identifikation der Organisationsstruktur Grobe Formulierung des Informationsbedarfs Definition der groben Informationsarchitektur Das IEM-Vorgehen ist Grundlage für die Planung der «technischen» Systementwicklung. Die Phase «Voranalyse» Die HERMES-Phase «Voranalyse» entspricht der IEM-Phase «Information Strategy Planning» (ISP). Der Untersuchungsbereich umfasst allerdings nicht das ganze Unternehmen, sondern ist auf das Informatikprojekt eingeschränkt. Projekthandbuch Projektplan Ergänzung der HERMES-Aktivitäten durch: Analyse der Strategien und Vorgehen (Organisationsstruktur). Das IEM-Vorgehen ist Grundlage für die Planung der «technischen» Systementwicklung. Anhang B Seite 14-3

4 Qualitätssicherungsplan Konfigurationsmanagementplan Situationsanalyse Systemziele Systemanforderungen Lösungsvorschläge Marktanalyse Wirtschaftlichkeit Keine zur Erstellung des QS-Plans, aber folgende QS-Massnahmen sind in IEM integriert: Analyse des Ist-Zustands (Überprüfung der Bewertung) Definition der Anwendungssystemarchitektur (Überprüfung des Implementierungsplans) Definition der technischen Architektur (Überprüfung der vorgeschlagenen technischen Architektur, Analyse und Definition der Sicherheitsaspekte) Ergänzung der HERMES-Aktivitäten wie folgt: Definition der Anwendungssystemarchitektur Analyse des Ist-Zustands Analyse der Strategien und Vorgehen (Systemziele) Analyse der Strategien und Vorgehen (Informationsbedarf) Definition der Informationsarchitektur Definition der Anwendungssystemarchitektur Definition der technischen Architektur Definition der Anwendungssystemarchitektur (Priorisierung der BAA- Projekte) Definition der technischen Architektur In IEM nicht vorgesehen. Die Phase «Konzept» Diese HERMES-Phase «Konzept» entspricht der IEM-Phase «Business Area Analysis» (BAA). Projekthandbuch Projektplan Wie in der Phase «Voranalyse». Seite 14-4 Anhang B

5 Qualitätssicherungsplan Konfigurationsmanagementplan Systemanforderungen Systemarchitektur Systemintegrationsplan Einführungskonzept Prototyp Detailstudie Fertigprodukte Fertigproduktevaluation Sachmittelbedarf Sachmittelevaluation Wirtschaftlichkeit Folgende QS-Massnahmen sind in IEM integriert: IST-Systemanalyse (Verifizierung der IST-System-Probleme) Verteilungsanalyse (Kontrollieren der Verteilung) Revision (Bestätigung der Korrektheit) Daten- und Aktivitätenanalyse Verteilungsanalyse Interaktionsanalyse IST-Systemanalyse Revision BSI-Vorbereitung BSI-Vorbereitung (Systemeinführungsanalyse) IST-Systemanalyse (Planung der Migration) IEM definiert verschiedene Prototypen, zum Beispiel: user interface prototype business case prototype Daneben ist innerhalb der Phase auch ein evolutionäres Prototyping möglich. IEM bietet verschiedenen Methoden (Techniken) zur Durchführung von Detailstudien, zum Beispiel: Activity-dependency diagram Entity-type life cycle diagram Business event analysis In IEM nicht vorgesehen. Anhang B Seite 14-5

6 Die Phase «Realisierung» Diese HERMES-Phase «Realisierung» entspricht der IEM-Phase «Business System Implementation» (BSI). Projekthandbuch Projektplan Konfigurationsmanagement Qualitätssicherungsplan Systemdesign Migrationsdesign, Systemintegrationsplan Prototyp Informatiksystem, Konfigurationsidentifikation Ergänzung der HERMES-Aktivitäten durch: Definieren des Projektes Bilden der Ressourcen Erstellen der Pläne Wie in der Phase «Voranalyse». Ergänzung der HERMES-Aktivitäten durch das Systemstrukturdesign. Folgende QS-Massnahmen sind in IEM integriert: Koordination der Entwicklung Kontrolle der Systemstruktur Test Systemstrukturdesign: Entwicklung der Systemstruktur Kontrolle der Systemstruktur Datenstruktur Design Verfeinerung des Datenmodelles Entwicklung der Datenstruktur Entwicklung der Datenbank Technischer Systementwurf: Definition der technischen Umgebung Systemeinführungsdesign: Planen der Systemeinführung Migrationsplanung Entwicklung eines funktionsfähigen Prototyp um die Machbarkeit der Systemstruktur und den Einsatz der Technologien zu prüfen. Systemstrukturdesign: Entwicklung der Systemstruktur Kontrolle der Systemstuktur Datenstruktur Design: Verfeinern des Datenmodelles Entwicklung der Datenstruktur Entwicklung der Datenbank Konstruktion Seite 14-6 Anhang B

7 Prüfprotokolle Anwendungshandbuch, Organisationshandbuch, Betriebshandbuch Ausbildungskonzept, Migrationsverfahren Sachmittel Konstruktion: Entwicklung der Anwendungssysteme (Unit Test) Test: Planen der Tests Durchführen der Integrationstests Durchführen des Systemtests Durchführen des Abnahmetests Dokumentationsdesign Technischer Systementwurf: Entwicklung der Operating-Prozeduren Systemeinführungsdesign: Planen der Sytemeinführung Nicht Teil des IEM. Die Phase «Einführung» Diese HERMES-Phase «Einführung» entspricht der IEM-Phase «Transition» (TRAN). Projekthandbuch Projektplan Wie in der Phase «Voranalyse». Qualitätssicherungsplan Konfigurationsmanagement Ergänzung der HERMES-Aktivitäten durch die Aktivität «Produktionsumgebung aufbauen». Prüfprotokolle System Organisationshandbuch, Betriebshandbuch Konfigurationsidentifikation Ausbildung Test wie in der Phase «Realisierung». System Einführen: Einführen der Infrastruktur Einführen der Applikation Einführen der manuellen Prozeduren Produktionsumgebung aufbauen Daten konvertieren Dokumentationsdesign analog der Phase «Realisierung». Nicht Teil des IEM. Ausbildung: Planung der Ausbildung Installation der Ausbildungsinfrastruktur Durchführung der Ausbildung Anhang B Seite 14-7

8 14.2 Die Methode MSA/SD nach Yourdon Die Methode MSA/SD (Modern Structured Analysis / Structured Design) ist eine Erweiterung der klassischen «Structured Analysis» um die ereignisorientierte Perspektive [Yourdon 89]. Ein zentraler Grundsatz der Methode MSA/SD ist die Modellierung des zu entwickelnden Systems, bevor es real erstellt wird. Die Methode stellt zur Darstellung des Systems verschiedene Hilfsmittel (Modelle, Techniken) zur Verfügung, von denen jedes einen bestimmten Aspekt des Gesamtsystems betrachtet. MSA/SD wird aufgeteilt in: essentielles Modell bzw. MSA (implementationsunabhängige Analyse), Implementationsmodell bzw. SD (Anwendung der Analyse für den Entwurf einer konkreten Implementation). Moderne Strukturierte Analyse MSA (essentielles Modell) Das essentielle Modell ist eine implementationsunabhängige Beschreibung der essentiellen (wesentlichen) Anforderungen an das zu entwickelnde System (logisches Modell). Es beschreibt, was das System tun soll (Sicht des Fachdienstes), nicht aber wie das System implementiert werden soll (Sicht der Informatik). Das essentielle Modell wird unterteilt in: Umgebungsmodell Verhaltensmodell Strukturierter Design SD (Implementationsmodell) Das Implementationsmodell ist die Abbildung der im essentiellen Modell erfassten Systemanforderungen auf eine konkrete Implementation. Hierbei wird das Verhaltensmodell mit zusätzlichen, implementationsabhängigen Elementen erweitert. Das Implementationsmodell beschreibt das «WIE» eines Systems. Das Implementations-Modell wird unterteilt in: Prozessor-Modell (Benutzer-Implementationsmodell) Task-Modell (System-Implementationsmodell) Code-Organisations-Modell (Programm-Implementationsmodell) Die folgende Tabelle stellt die den Ergebnissen von MSA/SD gegenüber. Seite 14-8 Anhang B

9 HERMES Systemanforderungen 2 Umgebungsmodell MSA/SD Kontextdiagramm Ereignis-/Reaktions-Liste Entity-Relationship-Diagramme Data Dictionary (Datenelemente) Verhaltensmodell First-Cut-DFD Upward-Levelling DFD Downward-Levelling DFD Prozess-Spezifikationen Entity-Relationship-Diagramme Data Dictionary (Datenelemente) Systemarchitektur, Systemdesign Prozessor-Modell DFD's je Prozessor Prozess-Spezifikation Entity-Relationship-Diagramme Data Dictionary (Datenelemente) Task-Modell DFD's State-Transition-Diagramme Entity-Relationship-Diagramme Prozess-Spezifikationen Data Dictionary (Datenelemente) Code-Organisations-Modell Structure Charts Modulspezifikationen Data Dictionary (Datenelemente) 2 MSA/SD deckt funktionale und datenbezogene Anforderungen an das System ab. Alle übrigen Anforderungen werden von MSA/SD nicht berücksichtigt. Anhang B Seite 14-9

10 14.3 Die Methode SSADM SSADM ist ein offener Standard [SSADM 90]. Ziel des Einsatzes von SSADM ist die Entwicklung von Informationssystemen auf der Basis von Datenbanksystemen. Die methodischen Schwerpunkte liegen auf der Betrachtung von Datenflussmodellen, Datenmodellen, zeitlichen Lebenszyklen von Entitäten und Effektkorrespondenz-Diagrammen der Ereignisse. Die integrierte Methode SSADM definiert für Analyse und Design sowohl ein detailliertes Vorgehensmodell als auch detailliert beschriebene Elementarmethoden. Sie gibt vor: welche Aktivitäten ausgeführt und welche Ergebnisse erzeugt werden (Vorgehensmodell), wie die Aktivitäten durchzuführen sind (Elementarmethoden), wo und in welcher Form die Ergebnisse aufzuzeichnen sind (Darstellung und Inhalt). Ausgeklammert sind alle Implementierungs- und Integrationsaktivitäten. Die begleitenden Aktivitäten der Submodelle PM, KM und QS sind nicht Teil von SSADM, sondern sind in die eigenständige Methode PRINCE [PRINCE 90] ausgelagert. PRINCE ist wie SSADM ein offener Standard. SSADM liegt seit 1990 in der Version 4 vor; im Mai 1995 wurde das erweiterte und verbesserte «SSADM4+» (Version 4.2 [SSADM 95]) freigegeben. Verschiedene Erweiterungen mit objektorientierten Ansätzen werden zur Zeit in Fachkreisen diskutiert. Die nachfolgenden Tabellen stellen den n die entsprechenden Ergebnisse von SSADM (Version 4) sowie PRINCE gegenüber. Die Methode SSADM kann als Submodell «Systementwicklung» zusammen mit HERMES eingesetzt werden. HERMES hat gegenüber PRINCE im Projektmanagement einen ähnlichen Umfang an Aktivitäten und Ergebnissen; die zu Grunde liegenden Prinzipien und Konzepte sind gleich. HERMES ist insbesondere im Submodell «Projektrollen» konform zu PRINCE. Seite Anhang B

11 HERMES SSADM PRINCE Projektmanagement Arbeitsaufträge Berichtsdokumente Bericht «Voranalyse» Bericht «Konzept» Bericht «Projektschlussbeurteilung» Protokoll Projektbericht Projektantrag Projekthandbuch Projekthistorie Projektplan Wirtschaftlichkeit Systementwicklung Situationsanalyse Marktanalyse Systembausteine Fertigproduktevaluation Fertigprodukte Sachmittelevaluation Sachmittel Systemintegration Einführungskonzept Migrationsdesign Migrationsverfahren Ausbildungskonzept Ausbildung Systemintegrationsplan System Informatiksystem System (produktives) Handbuchinformationen Anwendungshandbuch Betriebshandbuch Organisationshandbuch Project Initiation Document Business Systems Options Current Services Description Requirements Catalogue User Catalogue Individual Work Plans Feasibility Report Requirements Spec. Report Logical System Spec. Report Project Evaluation Report Records of Project Boards Checkpoint Meeting Reports End Stage Assessment Approv. Highlight Reports Project Initiation Document Project Initiation Document Terms of Reference Project File Project Plan Stage Plan Detailed Plan Exception Plan Project Initiation Document Current System Survey Hardware environment User Consumables Install. + Conversion Strategy Education strategy Education specification Education Materials & Guide System Build Strategy Operations Products User Guide Operations Guide User Procedures Anhang B Seite 14-11

12 HERMES SSADM PRINCE Systemmodell Ziele und Anforderungen Systemziele Systemanforderungen Systemlösung Lösungsvorschläge Systemarchitektur Systemdesign Prototyp Detailstudien Qualitätssicherung QS-Plan Prüfplan Prüfspezifikationen Prüfprozeduren Prüfprotokoll Konfigurationsmanagement KM-Plan Konfigurationsidentifikation Änderungsdokumente Meldung Änderungsvorschlag Änderungsauftrag Änderungsmitteilung Änderungsstatusliste Project Initiation Document Requirements Specification - Requirements Catalogue - Processing Specification - Data Catalogue Business Systems Options, Technical Systems Options Logical System Specification - Selected Techn. Syst. Opt. - Techn. Environment Descr. - Logical Design Physical Design - Physical Data Design - Process Data Interface - Phys. Process Specification Prototype Requirements Specification Logical System Design Physical System Design, Program Specification, Program Design Project Plan (Quality Plan) Stage Plan System Test Strategy Accepance Test Strategy System Test Specification Acceptance Test Specification System Test Data Acceptance Test Data System Test Results Acceptance Test Results Quality Review Result Notific. Conf. Management Plan Configuration Identification Project Issue Report, Off-Specification Report Request for change Seite Anhang B