Grundlagen des Software Engineering

Transkript

1 Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann

2 Einleitung Historie des Konfigurationsmanagements: In den fünfziger Jahren von der amerikanischen Raumfahrtindustrie eingeführt. Entwicklung von Raumfahrzeugen unterlag zahlreichen undokumentierten Veränderungen. In den Tests wurden die Raumfahrzeuge zerstört und es war nicht oder nur schwer möglich, den Prototyp nachzubauen. Konfigurationsmanagement sollte diesen Informationsverlust verhindern.

3 Probleme der SW-Entwicklung Häufige Änderungen an SW-Elementen => Aufzeichnung der Historie (Änderungen) Unklarheit, ob Fehler bereits behoben wurden => Verknüpfung von Änderungswünschen und vorgenommenen Änderungen Berücksichtigung aller Fehlermeldungen zu einem bestimmten Termin => Automatische Konfigurationsselektion Unsicherheit einer vollständigen Übersetzung und dem Vorliegen der neuesten Version für den Kunden => Vollständige Aufzeichnung aller Änderungen

4 Konfigurationen Software-Konfiguration: Benannte und formal freigegebene Menge von SW-Elementen, inklusive gültiger Versionsangaben. Elemente sind aufeinander abgestimmt und erfüllen vorgesehene Aufgabe. Software-Element: Jeder identifizierbare und maschinenlesbare Bestandteil des entstehenden Produkts oder der entstehenden Produktlinie. Jedes SW-Element hat eindeutigen Bezeichner; jede Änderungen erzeugt neues Element mit neuem Bezeichner.

5 Klassen von SW-Elementen Quellelemente sind SW-Elemente, die durch manuelle Eingaben erzeugt werden (Bsp. Quelltext). Abgeleitete Elemente sind vollautomatisch erzeugte Elemente (Bsp. Objektcode) -> können bei Platzbedarf gelöscht werden! Atome sind SW-Elemente, die für ein Produkt eine unteilbare Einheit bilden. Sie enthalten keine Untereinheiten, die unabhängig voneinander variieren. Konfigurationen sind SW-Elemente, die sich aus mehreren anderen SW- Elementen zusammensetzen, die unabhängig voneinander variieren können.

6 Übung 1. Geben Sie für das von Ihnen im dritten Semester durchgeführte Programmierprojekt konkrete Beispiele für Quellelemente, abgeleitete Elemente, Atome und Konfigurationen an! 2. Wie ist das Verhältnis zwischen den verschiedenen Objekttypen? Kann es beispielsweise abgeleitete Atome geben? Welche Typen von SW-Elementen schließen sich gegenseitig aus? Haben Sie bei den oben angegebenen Beispielen alle Möglichkeiten abgedeckt?

7 Verwaltung von Konfigurationen Das Konfigurations-Identifikationsdokument (KID) führt auf, welche SW- Elemente zu einer Konfiguration gehören. Dieses Dokument wird auch als Konfigurationshierarchie oder Elementstrukturplan bezeichnet. Es werden in der Regel auch Hilfsmittel oder Werkzeuge aufgeführt, die zur Erstellung beigetragen haben, aber nicht an den Kunden ausgeliefert werden. Neue Konfigurationen ergeben sich durch Pflege und Wartung Entwicklung im Prozess (baselines) Eine Referenzkonfiguration (baseline) ist zu einem Zeitpunkt im Entwicklungsprozess ausgewähltes, gesichertes und freigegebenes Zwischenergebnis.

8 Beispiel für ein KID KID Seminarorganisation Typ der Konfiguration: Anforderungskonfiguration Versionsnummer: 1.0 Zustand: akzeptiert Datum der letzten Änderung: Bestandteile: a b... Pflichtenheft SemOrgV2.3 (Datei: SemOrg/Def/PfV23) OOA-Modell SemOrgV2.1 (Datei: SemOrg/Def/OOAV21) I Textsystem MS-Word 2000 (für Produkte a und d) (Datei: Word2000/...) II OO-Case-Tool Otool V2.3 (für das Produkt b) (Datei: SemOrg/Tools/OToolV23/...)...

9 Versionen und ihre Verwaltung Eine Version ist die Ausprägung eines SW-Elements zu einem bestimmten Zeitpunkt. Sie erhält eine Nummer. Die Versionsnummer besteht im allgemeinen aus zwei Teilen: Release-Nummer steht getrennt durch einen Punkt vor der Level- Nummer und bezeichnet kleinere formale oder inhaltliche Ändrungen Level-Nummer beschreibt größere oder gravierende Änderungen Versionszählung: V 1.0 V 1.1 V 1.2 V 2.0 Release 1 Release 2

10 Checkin/Checkout-Modell Sammlung von SW-Elementen in Archiven Checkout: Checkin: holt Kopie aus dem Archiv und reserviert es für den Ausbucher. Die Kopie darf geändert werden. Wird erneut ausgebucht, wird dies verhindert oder ein paralleler Entwicklungsast wird abgespalten. Geändertes SW-Element wird in das Archiv befördert und Reservierung wird aufgehoben. Ändeungen werden formal erfaßt (Autor, Buchungszeitpunkt etc.). Eingebuchte Elemente können nicht mehr geändert werden; es kann nur durch erneutes Checkout/Checkin ein weiteres Element erzeugt werden. Realisierung durch Deltatechnik: Es werden die Unterschiede von zeitlich aufeinanderfolgenden Elementen gespeichert. Das ist transparent für den Nutzer.

11 Varianten Der Variantenbegriff kann verschiedene Sachverhalte bezeichnen: Zeitgleich nebeneinander liegende Ausprägungen von SW- Elementen Darstellung paralleler Entwicklungslinien Verschiedene Implementierungen derselben Schnittstelle Unterschiede durch bedingte Übersetzung Unterschiede für verschiedene HW-/SW-Konstellationen Ab einem bestimmten Abstraktionsniveau nicht mehr zu unterscheidende Implementierungen

12 Beispiel Variante mit einem Zweig Die Versionen 1.0 und 1.1 befinden sich bei Kunden im Einsatz. Die Entwicklung findet an Version 1.2 statt. In Version 1.0 wird ein Fehler entdeckt, der Kunde kann jedoch nicht auf 1.1 übergehen. Somit wird eine abgespaltene Version entwickelt ( ) V 1.0 V 1.1 V 1.2 V 2.0 Release 1 Release 2 Variante Zweig 1 V V Variante Varianten, die aus Verzweigungen von Versionen bestehen, kann man folgendermaßen aufbauen: Variantennummer = release.level.branch.sequence

13 Beispiel Variante mit zwei Zweigen Der Kunde mit V benötigt eine spezielle Funktion; er erhält die Variante V und nach Fehlerbehebung die Variante V Version 2.0 ist so fehlerhaft, daß Version 2.1 aus Version 1.1 abgeleitet wird. V 1.0 V 1.1 V 1.2 V 2.0 V 2.1 Release 1 Release 2 Zweig 1 V V V Zweig 2 Varianten V

14 Übung 1. Das Produkt RobotPlot liegt aktuell in der Version 3.2 vor. Aus welchen Teilen setzt sich die Versionsnummer zusammen? Seit der letzten Version wurden nur geringe Änderungen vorgenommen. Wie lautet die Versionsnummer des Vorgängers? In der nächsten Version wird der Funktionsumfang des Produkts RobotPlot erheblich erhöht. Welche Versionsnummer sollte das Produkt dann tragen? Für einen Kunden müssen spezifische Anpassungen an die Version 3.2 gemacht werden. Wie behandelt man diesen Fall im Konfigurationsmanagement? 2. Beschreiben Sie das Verhältnis zwischen einer Version und einer Variante. Kann jede Variante eine Version und umgekehrt sein?

15 Namensvergabe Unterschiedliche SW- und HW-Konstellationen werden häufig mit kleinen Buchstaben bezeichnet: a: Intel, Windows; b: Intel, Solaris; c: SUN, Solaris Ein Numerierungsschema legt fest: Struktur bzw. Aufbau des Identifikators Informationen, die der Identifikator enthalten soll Verfahren, wie sich der Identifikator bei Änderungen verhält Beispiel: Kombination eines hierarchischen Namensschemas mit Versions- und Variantenkennung SemOrg Dokumentationshierarchie: Def Ent Imp PflichtV23a.doc OODV13a.gif KundeV18c.cpp

16 Mangement von Konfigurationen Änderungen an einem SW-Element müssen einen formalen Änderungsprozeß durchlaufen, da sich somit die gesamte Konfiguration ändert. QS geplant In Bearb. BH 2.5 Autor vorgelegt BH 2.5 QS akzeptiert BH 2.5 BH = Benutzerhandbuch KID = Konfigurations- Identifikationsdokument QS = Qualitätssicherung KM = Konfigurationsmanagement In Bearb. KID 1.1 QS Autor KM vorgelegt KID 1.1 QS akzeptiert KID 1.1

17 Übung 1. Woraus kann sich sich der Inhalt eines Dokuments im Konfigurationsmanagement erschließen? 2. Warum kann eine Variantenidentifikation über eine Dokumentationshierarchie gegebenenfalls zu Fehlern führen? 3. Warum wird beim Konfigurationsmanagement zwischen der qualitätssichernden Prüfung eines neu erstellten/ veränderten Einzeldokuments und dem Konfigurations-Identifikaktionsdokuments (KID) unterschieden? Geben Sie ein Beispiel für den Fall, dass die erste Prüfung gelingt und die zweite Prüfung fehlschlägt!