1 Kurzdarstellung von ISOTEC
ISOTEC (Integrierte Software-Technologie) unterstützt die Entwicklung von Anwendungssystemen und die Integration von Standardsoftware organisatorisch und technisch über den gesamten Software Life Cycle durch aufeinander abgestimmte übergreifende Konzepte und spezifische Methoden. Zielsetzung ist die Modellierung von Informationssystemen, die typischerweise auf (relationalen) Datenbanksystemen implementiert werden. Zu den übergreifenden Konzepten von ISOTEC, die den gesamten SW-Entwicklungsprozeß begleiten, gehören:
- Vorgehenskonzept (VGK)
Das Vorgehenskonzept bietet verschiedene Vorgehensmodelle für unterschiedliche Projekttypen. Die Modelle strukturieren den Softwareentwicklungsprozeß und regeln den Einsatz von Methoden und die Dokumentation der Entwicklungsergebnisse.
- Projektmanagementkonzept (PMK)
Das PM-Konzept dient der Planung, Disposition und Kontrolle von personellen und materiellen Ressourcen in der Projektabwicklung. Es beschreibt außerdem die Aufgaben zur Initiierung von Projekten, der Projektrahmenplanung und der Projektorganisation.
- Administrationskonzept (ADMIN)
Das Administrationskonzept regelt die Handhabung und Verwaltung von Entwicklungsergebnissen auf der Basis einer zentralen Entwicklungsdatenbank.
- Qualitätssicherung (QS)
Die Aktivitäten der Softwareentwicklung werden durch Qualitätssicherungsmaßnahmen begleitet, die in einem QS-Handbuch beschrieben sind.
Neben den übergreifenden Konzepten bietet ISOTEC Methoden an, die den Softwareentwicklungsprozeß in einzelnen Entwicklungsphasen spezifisch unterstützen. Diese sind:
- Informationsstrukturanalyse (ISA)
Die Informationsstrukturanalyse basiert auf dem Entity-Relationship-Modell nach Chen, das um übergeordnete semantische Konzepte erweitert wurde.
- Funktionsstrukturanalyse (FSA)
Mit der Funktionsstrukturanalyse wird ein Modell der betrieblichen Funktionen erstellt. Sie beschreibt die hierarchische Zerlegung der betrieblichen Funktionen in Teilfunktionen, die zeitliche Abhängigkeit der Funktionen sowie die Kommunikation der Funktionen untereinander und mit der Außenwelt des Systems.
- Strukturierung und Spezifikation von Systemfunktionen (SSF)
Der Inhalt der Methode SSF regelt, wie die durch die FSA ermittelten betrieblichen Funktionen durch ein IT-System realisiert werden sollen. Die Methode unterstützt die Standardisierung und Wiederverwendung fachlicher und technischer Leistung.
- Dialogentwurf (DIA)
Der Dialogentwurf legt die Grundlage für die Gestaltung und Steuerung von Dialogen im Rahmen der Bestimmung der Benutzerschnittstelle.
- Systemspezifischer Datenstrukturentwurf (SDS)
Beim Systemspezifischen Datenstrukturentwurf wird aus einem mit Hilfe der ISA entwickelten Anwendungsdatenmodell ein spezifisches Datenbankschema abgeleitet.
Die Methoden sind aufeinander abgestimmt und unterstützen durchgängig den gesamten Software-Entwicklungsprozeß.
ISOTEC wurde durch das Beratungsunternehmen Ploenzke entwickelt. Seit Beginn der Entwicklung im Jahre 1981 wurde ISOTEC in vielen internen und externen Projekten eingesetzt und kontinuierlich weiterentwickelt. Der vorliegende Abgleich bezieht sich auf die Version Juni 1991 / Ploenzke, 91 /.
2 Tabellarische Gegenüberstellung
Die folgende Tabelle stellt den Elementarmethoden die methodischen Komponenten von ISOTEC gegenüber. Falls sich in der zweiten Spalte der Tabelle kein Eintrag befindet, gibt es in ISOTEC keine Entsprechung. Sonst verweist ein Eintrag auf die entsprechende Stelle in der ISOTEC-Literatur. Eine Erläuterung zum Eintrag findet sich in Teil 3 des Abgleichs. Einträge, die durch einen Stern (*) gekennzeichnet sind, betreffen Methoden, die durch ISOTEC vollständig abgedeckt sind. Diese werden in Teil 3 des Abgleichs nicht weiter erläutert.
|
Gegenüberstellung der Elementarmethoden und der methodischen Komponenten von ISOTEC |
||
| AUD Audit | ||
| AVK Analyse verdeckter Kanäle | ||
| BALK Balkenplan | ||
| BAUM Baumdiagramm | ||
| BBTE Black-box-Testfallentwurf |
Qualitätssicherung
/ Ploenzke, 91 / Kapitel 2.3.2 |
|
| CRC Class-Responsibility-Collaboration | ||
| DIAL Dialog Design Modellierung |
Strukturierung und Spezifikation von
Systemfunktionen / Ploenzke, 91 / Anhang A (*) |
|
| DFM Datenfluß-Modellierung |
Funktionsstrukturanalyse
/ Ploenzke, 91 / Kapitel 4.4 |
|
| DNAV Data Navigation Modelling | ||
| DVER Designverifikation | ||
| ELH Entity Life History |
Informationsstrukturanalyse
/ Ploenzke, 91 / Kapitel 4.4 |
|
| ER E/R-Modellierung |
Informationsstrukturanalyse
/ Ploenzke, 91 / Kapitel 4.2 (*) |
|
| ETAB Entscheidungstabellentechnik | ||
| EVV Earned Value Verfahren | ||
| EXPM Expertisemodell | ||
| FKTD Funktionale Dekomposition |
Funktionsstrukturanalyse
/ Ploenzke, 91 / Kapitel 3.4 (*) |
|
| FMEA Failure Mode Effect Analysis | ||
| FNET Funktionsnetz-Modellierung |
Funktionsstrukturanalyse
/ Ploenzke, 91 / Kapitel 4.2 (*) |
|
| FS Formale Spezifikation | ||
| IAM Interaktionsmodellierung | ||
| KFM Kontrollfluß-Modellierung | ||
| KOM Klassen-Objektmodellierung | ||
| LOGM Logische DB-Modellierung |
Systemspezifischer Datenstrukturentwurf
/ Ploenzke, 91 / Kapitel 4.1 |
|
| MODIAG Moduldiagramme | ||
| NORM Normalisierung |
Informationsstrukturanalyse
/ Ploenzke, 91 /, Kapitel 5.3 (*) |
|
| NPT Netzplan-Technik |
PM-Konzept
/ Ploenzke, 91 / Kapitel H11 |
|
| NWA Nutzwert-Analyse | ||
| OBJE Objektentwurfstechnik | ||
| OGG Organigramm | ||
| PCODE Pseudocode |
Spezifikation der Systemfunktionen
/ Ploenzke, 91 / Kapitel 3.6.3 (*) |
|
| PRODIAG Prozeßdiagramme | ||
| PVER Programmverifikation | ||
| PZIM Prozeßinteraktionsmodellierung | ||
| REV Review |
Qualitätssicherung
/ Ploenzke, 91 / Kapitel 2.3.1.1 "Code Inspection" und Kapitel 2.3.1.2 "Walk-Through" |
|
| SIMU Simulationsmodelle | ||
| SMOD Schätzmodelle |
PM-Konzept, Schätzmethode IFA
/ Ploenzke, 91 / Anhang A |
|
| SSM Subsystemmodellierung | ||
| STAT Statische Analyse | ||
| STRD Structured Design |
Spezifikation der Systemfunktionen
/ Ploenzke, 91 / Kapitel 3.2 |
|
| SVM Systemverhaltensmodelle | ||
| T Testen |
Qualitätssicherung
/ Ploenzke, 91 / Kapitel 2.3.2 "Black-Box-Test" und Kapitel 2.3.3 "White-Box-Methoden" |
|
| TRDA Trend-Analyse |
PM-Konzept
/ Ploenzke, 91 / Kapitel D53 |
|
| UCM Use-Case-Modellierung | ||
| WBTE White-box-Testfallentwurf |
Qualitätssicherung
/ Ploenzke, 91 / Kapitel 2.3.3 |
|
| ZUST Zustandsübergangsmodellierung | ||
| ZUSTO Zustandsmod. im obj.-orient. Bereich | ||
| ZUVM Zuverlässigkeitsmodelle | ||
Tabelle 2.3: Elementarmethoden - ISOTEC
3 Detaillierung der Zuordnung
Black-box-Testfallentwurf (BBTE)
Entsprechung in ISOTEC: / Ploenzke, 91 / QS Qualitätssicherung, Kapitel 2.3.3 "Black- Box-Test", S. 43
Erläuterung
Beim Black-Box-Test wird die Struktur eines Programms und die Programmlogik nicht berücksichtigt, d. h. das Programm ist die Black-Box. Zentrale Bedeutung haben die Testdaten und die erwarteten Ergebnisse. Die ISOTEC-Methoden decken den Bereich
- Äquivalenzklassenbildung,
- Grenzwertanalyse und
- intuitive Testfallermittlung
ab. Ebenfalls wird hier die Durchführung der Tests beschrieben.
Datenfluß-Modellierung (DFM)
Entsprechung in ISOTEC: / Ploenzke, 91 / FSA Funktionsstrukturanalyse Kapitel 4.4 "Inhalte der Kommunikationsstruktur", S. 67
Erläuterung
Die Kommunikationsstruktur beschreibt, welche Datengruppen zwischen Funktionen des Systems und den Externen Partnern, zwischen Funktionen und Informationsobjekten und zwischen zwei Funktionen ausgetauscht werden. Darstellungsmittel ist ein Kommunikationsdiagramm.
Die Elemente der Kommunikationsstruktur entsprechen denen der Datenflußmodellierung. Lediglich Datenspeicher werden nicht benötigt, da ISOTEC für diese Zweck die Informationsstruktur verwendet.
Entity Life History (ELH)
Entsprechung in ISOTEC: / Ploenzke, 91 / ISA Informationsstrukturanalyse Kapitel 4.3.4 "Zustandsbedingungen und Übergangsbedingungen", S. 73
Erläuterung
Zustandsbedingungen und Übergangsbedingungen kontrollieren die Integrität einer Informationsstruktur. Es werden die zulässigen Zustände, die eine Entität einnehmen kann, sowie die Operationen, die in bestimmten Zuständen zulässig sind, festgelegt. Das Ergebnis wird in einem Zustandsdiagramm festgehalten.
Logische DB-Modellierung (LOGM)
Entsprechung in ISOTEC: / Ploenzke, 91 / SDS Systemspezifischer Datenstrukturentwurf, Kapitel 4.1 "Abbildung der Objekte", S. 49
Erläuterung
Der Systemspezifische Datenstrukturentwurf, d. h. die Ableitung eines technischen Datenmodells aus der Informationsstruktur, ist Gegenstand einer eigenen Methode. Das Handbuch beschreibt die Abbildung auf die Zielsysteme ADABAS 5.1 und DB2 2.2.
Netzplan-Technik (NPT)
Entsprechung in ISOTEC: / Ploenzke, 91 / PM Konzept Kapitel H11 "Netzplantechnik", S. 142
Erläuterung
Die Netzplantechnik dient der Projektstrukturierung auf Aktivitätenebene. Mit ihrem Einsatz läßt sich der zeitliche und logische Projektverlauf modellieren, optimieren und grafisch mittels eines Netzplanes darstellen.
Review (REV)
Entsprechung in ISOTEC: / Ploenzke, 91 / QS Qualitätssicherung Kapitel 2.2.2.5.2 "Review", S. 38, Kapitel 2.3.1.1 "Code Inspection" S. 40, Kapitel 2.3.1.2 "Walk Through" S. 42
Erläuterung
Der Review dient im Gegensatz zur Inspektion in erster Linie dazu, ein fertiggestelltes Produkt von einem Expertenkreis beurteilen zu lassen.
Bei der Code-Inspektion soll ein Team durch gemeinsames Lesen des Programmcodes Fehler finden, d. h. Abweichungen von der Programmiernorm ermitteln und Situationen aufdecken, bei denen sich das Programm nicht gemäß der Spezifikation verhält.
Die Methode wird bei ISOTEC für den Spezialfall Code-Inspektion beschrieben, sie läßt sich jedoch ebenfalls auf die übrigen V-Modell-Produkte anwenden.
Beim Walk-Through wird in einer Gruppensitzung auf der Basis des Programmcodes und mit zuvor ermittelten Testfällen "Computer gespielt".
Die Methode wird bei ISOTEC für die bei der Softwareerstellung anfallenden Produkte beschrieben, läßt sich aber ebenfalls auf die übrigen V-Modell-Produkte anwenden.
Schätzmodelle l (SMOD)
Entsprechung in ISOTEC: / Ploenzke, 91 / PM Projektmanagement Anhang A "Schätzmethode IFA" (ISOTEC-basierende Function-Point-orientierte Aufwandsschätzung)
Erläuterung
Die funktionsorientierte Aufwandsplanung (IFA) erstellt eine Prognose des zu erwartenden Ressourcenbedarfs zur Anforderungserfüllung, gemessen in einer zur jeweiligen Ressourcenart passenden Maßeinheit (z.B. Mannmonate für den Personalbedarf). Diese Schätzung bildet die Basis der Kapazitäts-, Termin- und Kostenplanung.
Eine Aufwandsschätzung ist unter Nutzung des jeweiligen Kenntnisstandes zu mehreren Zeitpunkten im Projektverlauf durchzuführen. Die Methode unterstellt eine Projektabwicklung nach ISOTEC.
Structured Design (STRD)
Entsprechung in ISOTEC: / Ploenzke, 91 / SSF Spezifikation der Systemfunktionen, Kapitel 3.2 "Systemfunktionen", S. 48
Erläuterung
Das Anwendungsmodell wird auf der Funktionsseite in Systemfunktionen (Module) zerlegt. Als Spezifikationsmittel für Systemfunktionen kann Pseudocode verwendet werden. Die Systemfunktionen stehen zueinander in einer Aufruf- oder Anstoßbeziehung. Als Darstellungsmittel werden Structure Charts verwendet, die neben den Kontrollflüssen auch die Informationsflüsse zwischen den Systemfunktionen darstellen.
Testen (T)
Entsprechung in ISOTEC: / Ploenzke, 91 / QS Qualitätssicherung Kapitel 2.3.2 Black-Box-Tests, S. 43, Kapitel 2.3.3 "White-Box-Methoden", S. 53
Erläuterung
Die ISOTEC-Methoden decken den Bereich der Black-Box-Tests sowie den der White-Box-Test ab.
Trend-Analyse (TRDA)
Entsprechung in ISOTEC: / Ploenzke, 91 / PM Konzept Kapitel D53 "Managementbericht" S. 88
Erläuterung
Die Aussagen des Managementberichtes zur terminlichen Situation des Projektes sowie zum Verhältnis von Plan-Aufwand zu Ist-Aufwand werden in einer Trend-Analyse veranschaulicht.
White-box-Testfallentwurf (WBTE)
Entsprechung in ISOTEC: / Ploenzke, 91 / QS Qualitätssicherung Kapitel 2.3.3 "White-Box-Methoden", S. 53
Erläuterung
Die ISOTEC-Methoden decken den Bereich
ab. Ebenfalls wird hier die Durchführung der Tests beschrieben.
4 Literatur
/ Ploenzke, 91 / Ploenzke Informatik: ISOTEC, Freigabedatum Juni 1991