19. Software-Lebenszyklus und Anforderungsanalyse

Präsentation zum Thema: "19. Software-Lebenszyklus und Anforderungsanalyse"—  Präsentation transkript:

1 19. Software-Lebenszyklus und Anforderungsanalyse
Der Software-Entwicklungsprozeß Anforderungs-analyse Spezifikation Entwurf (Design) Implementierung (Programmierung) Verifikation (Test) abschließender Schritt: Wartung der erstellten Software Wahl der Programmiersprache beeinflußt auch frühere Phasen Integration

2 Der Software-Entwicklungsprozeß (2)
SYSTEM- SPEZIFIKATION Der Software-Entwicklungsprozeß (2) FORDERUNGS- ANALYSE ARCHITEKTUR DETAILLIERTER ENTWURF QUELLTEXT SCHREIBEN UND FEHLER SUCHEN TESTEN DES MODULS TESTEN DES SYSTEMS Entwurf: 40 % Implementierung: 20 % Testen und Dokumentation: 40 % WARTUNG / PFLEGE

3 Planen eines Produkts Voruntersuchung des Produkts Ist-Analyse, falls ein Vorgänger- Produkt bereits vorhanden ist Festlegen der Hauptanforderungen Festlegen der Hauptfunktionen Festlegen der Hauptdaten Festlegen der Hauptleistungen Festlegen der wichtigsten Aspekte der Benutzungsschnittstelle Festlegen der wichtigsten Qualitätsmerkmale

4 Durchführbarkeits-Untersuchung
- Prüfen der fachlichen Durchführbarkeit (softwaretechnische Realisierbarkeit, Verfügbarkeit geeigneter Entwicklungs- und Zielmaschinen - Prüfen alternativer Lösungsvorschläge (z. B. Kauf und Anpassung von Standardsoftware vs. Individualentwicklung) - Prüfen der personellen Durchführbarkeit (Verfügbarkeit qualifizierter Fachkräfte für die Entwicklung) - Prüfen der Risiken

5 Prüfen der ökonomischen Durchführbarkeit
- Aufwands- und Terminschätzung - Wirtschaftlichkeitsrechnung Die Ergebnisse dieser Tätigkeiten münden in eine Durchführbarkeitsstudie (feasibility study ), die folgende Teildokumente enthält: - Lastenheft (grobes Pflichtenheft) - Projektkalkulation - Projektplan Die Tätigkeiten in der Planungsphase haben das Ziel zu prüfen, ob ein Produkt entwickelt werden soll.

6 Hinzu kommt, daß die durchzuführenden Tätigkeiten und die involvierten Personengruppen stark von der jeweiligen Firmensituation abhängen: Erstellt die Software-Abteilung Individualsoftware für die eigene Firma, dann erfolgen die Planungen zusammen mit der jeweiligen Fachabteilung. Stellt ein Software-Haus Standard-Software für den anonymen Markt her, dann unterliegen Produktplanungen anderen Randbedingungen (Marketing, Produktfamilie und CI, Kooperationen, Standards, Termine, Kosten, ...)

7 Aufbau eines Lastenheftes
Aufgabe: Das Lastenheft enthält eine Zusammenfassung aller fachlichen Basisanforderungen, die das zu entwickelnde Software-Produkt aus der Sicht des Auftraggebers erfüllen muß. „Basisanforderungen“ bedeutet eine bewußte Konzentration auf die fundamentalen Eigenschaften des Produktes und ihre Beschreibung auf einem hinreichenden Abstraktionsniveau. Adressaten: Auftraggeber (extern oder intern, z. b. Marketing), sowie Auftragnehmer repräsentiert durch den Projektleiter und die Systemanalytiker. Inhalt: Bewußte Konzentration auf die fundamentalen Eigenschaften des Produktes. Beschreibung des „Was“, nicht des „Wie“.

8 Form: Vorgegebenes, standardisiertes, grobes Gliederungsschemas mit festgelegten Inhalten.
Sprache: Beschreibung auf notwendigem und hinreichendem Abstraktionsniveau in verbaler Form. Die einzelnen Anforderungen werden numeriert ( in 10-er Schritten für evtl. Einfügungen), um sich in späteren Phasen darauf beziehen zu können. Didaktik: Das Gliederungsschema ist so aufgebaut, daß das Lastenheft gut lesbar ist. Zeitpunkt:Das Lastenheft ist das erste Dokument, das die Anforderungen an ein neues Produkt grob beschreibt.

9 Gliederungsschema eines Lastenheftes
1. Zielbestimmung Hier wird beschrieben, welche Ziele durch den Einsatz des Produktes erreicht werden sollen. 2. Produkteinsatz Es wird festgelegt, für welche Anwendungsbereiche und für welche Zielgruppen das Produkt vorgesehen ist. 3. Produktfunktionen Die Hauptfunktionen des Produktes werden aus Auftraggebersicht beschrieben. Es ist darauf zu achten, daß die Kernfunktionen und nicht sekundäre Funktionen beschrieben werden. Auf Detailbeschreibungen ist zu verzichten.

10 4. Produktdaten Die Hauptdaten des Produktes, die permanent gespeichert werden müssen, werden festgelegt. 5. Produktleistungen Werden an einzelne Hauptfunktionen und Hauptdaten Leistungsanforderungen bzgl. Zeit, Datenumfang oder Genauigkeit gestellt, dann werden sie hier aufgeführt. 6. Qualitätsanforderungen Die wichtigsten Qualitätsanforderungen sollten hier aufgeführt werden, wie gute Zuverlässigkeit, gute Benutzbarkeit, normale Effizienz usw. 7. Ergänzungen Hier werden Ergänzungen oder spezielle Anforderungen beschrieben, z. B. außergewöhnliche Anforderungen an die Benutzerschnittstelle.

11 Seminaranmeldung Als Teilnehmer zu nachfolgenden Seminaren wird angemeldet: Titel Vorname Name vom bis Anmeldebestätigung und Rechnung erbeten an: Firma Straße / Postfach LKZ ORT PLZ Telefon Veranstaltungs-Nr. Seminarbezeichnung

12 Produkt-Definition Diese kann sich - je nach gewählter Methodik - aus verschiedenen Teilprodukten zusammensetzen. Meistens ist die Produkt-Definition - oder zumindest Teile davon - auch ein juristisches Dokument. Mit der Unterzeichnung dieses Dokuments durch Auftraggeber und Auftragnehmer sind die Anforderungen verabschiedet. Die Produkt-Definition bildet die Grundlage für den Software-Entwurf. Was muß definiert werden? Modelliert man ein neues System, dann müssen vier verschiedene Sichten und ihre Zusammenhänge beschrieben werden: Daten Funktionen Dynamik Benutzungsoberfläche

13 Abb. Zu beschreibende Sichten und ihre Konzpte
Assoziations-Matrix Daten ER (Entity Relationship) DD (Data Dictionary) DFD (Datenfluß-Diagramm) Masken-Generator SA Funktionen Funktions-Baum DFD (Datenfluß- Diagramm) Benutzer Grafik-Editor Kontroll- Strukturen Regeln System OOA Dynamik Petri-Netz Zustandsautomat Kontroll-Strukturen Interaktions-Strukturen RT-Erweiterung von SA

14 Begriffe zur Abbildung
Benutzer-Oberfläche ER = Entity Relationship DD = Data Dictionary DFD = Datenfluß-Diagramm RT = Real Time Analysis OOA = Object Oriented Analysis SA = Structured Analysis Die Bedeutung der einzelnen Sichten ist nicht bei jeder Anwendung gleich groß. Es gibt Anwendungen, bei denen alle 4 Sichten weitgehend gleich wichtig sind. Es gibt aber auch Anwendungen, bei denen eine oder zwei Sichten dominieren.

15 Komplexität der Funktionen:
Komplexitätsarten Unabhängig von einer konkreten Anwendungklasse lassen sich Anwendungen nach Komplexitätsarten gliedern. Sechs Dimensionen der Software-Komplexität können unterschieden werden: Komplexität der Funktionen: Software-Systeme, die eine Vielzahl von Funktionen enthalten, Textverarbeitungssysteme, DTP-Systeme und integrierte Büroprogramme sind Beispiele dafür. Integrierte Büroprogramme mit Textverarbeitung, Tabellenkalkulation, Bürografik und Datenbank besitzen zwischen und Funktionen. Ein DTP-System hat einen Funktionsumfang von 700 bis Funktionen.

16 Komplexität der Algorithmen
Komplexität der Daten Software-Systeme, die eine Vielzahl von Datenstrukturen oder sehr komplexe Datenstrukturen enthalten. Ein Beispiel hierfür sind Datenbanksysteme. Komplexität der Algorithmen Software-Systeme, die z. B. komplexe numerische Berechnungen durchführen. Komplexität des zeitabhängigen Verhaltens Software-Systeme, die sich durch nebenläufige Prozesse, gegenseitigen Ausschluß, Synchronisation, definierte Zeitbedingungen und ähnliches auszeichnen. Beispiele dafür sind Betriebssysteme, verteilte Systeme, Prozeßsteuerungen.

17 Komplexität der Systemumgebung
Software-Systeme, die in andere Systeme eingebettet sind (embedded systems). Da diese Software-Systeme nur Teilkomponenten des Gesamtsystems sind, kommt es hierbei ganz wesentlich auf das Zusammenwirken von Software-System und Gesamtsystem an. Beispiele hierfür sind Flugzeugsteuerungen, Radaranlagen, Kraftwerkssteuerungen. Komplexität der Benutzungsoberfläche Software-Systeme mit komplexer Interaktion zwischen Benutzer und Computersystem. Beispiele dafür sind CAD- und CASE-Systeme, Büroanwendungen, Grafiksysteme.

18 Die in den letzten Jahren entwickelten Konzepte zur Beschreibung eines Produktmodells lassen sich in vielen Fällen auf seit längerem bekannte Basiskonzepte zurückführen. Ein Basiskonzept läßt sich durch folgende Eigenschaften charakterisieren: atomares Konzept besagt, daß das Konzept elementar und originär ist. Es ist nicht auf andere Basiskonzepte reduzierbar. Um von einem Basiskonzept zu sprechen, muß die erste Eigenschaft und mindestens eine der anderen Eigenschaften erfüllt sein. konzeptuell langlebig, phasenübergreifend verwendbar, in unterschiedlichen Kontexten einsetzbar.

19 Überblick über Basiskonzepte,
gegliedert nach den Sichten, die sie beschreiben. Funktionale Sicht (Funktionale Hierarchie, Informationsfluß) Datenorientierte Sicht (Datenstrukturen, Entitäten und Beziehungen) Objektorientierte Sicht (Klassenstrukturen) Algorithmische Sicht (Kontrollstrukturen) Regelbasierte Sicht (Wenn- Dann-Strukturen) Zustandsorientierte Sicht (Endlicher Automat, Nebenläufige Strukturen) Scenario-basierte Sicht (Interaktions-Strukturen) Internationale Standardisierung 1984 Der Standard Guide for Software Requirements wurde von der IEEE verabschiedet und 1985 von der ANSI (American National Standard Institute) übernommen.

20 Aufbau eines Pflichtenheftes
Das Ergebnisdokument einer Anforderungsdefinition wird oft als Pflichtenheft bezeichnet. Aufgabe: Das Pflichtenheft enthält eine Zusammenfassung aller fachlichen Anforderungen, die das zu entwickelnde Software-Produkt aus der Sicht des Auftraggebers erfüllen muß. Adressaten: Auftraggeber (extern oder intern, z. B. Fachabteilung), Auftragnehmer repräsentiert durch den Projektleiter und die Systemanalytiker, Entwerfer, Qualitätskontrolle, Benutzerrepräsentant oder ausgewählte potentielle Benutzer.

21 Inhalt: Fachlicher Funktions-, Daten-, Leistungs- und Qualitätsumfang des Produktes. Beschreibung des Was, nicht des Wie. Das Pflichtenheft muß so abgefaßt sein, daß es als Basis eines juristischen Vertrages dienen kann. Das Pflichtenheft stellt also die vertragliche Beschreibung des Lieferumfanges dar. Anhand des Pflichtenheftes soll das fertige Produkt abgenommen werden können. Die beschriebenen Anforderungen sollen realisierbar sein. Entwurfs- und Implementierungs-Entscheidungen sollen nicht vorweggenommen oder unnötig eingeschränkt werden. Form: Vorgegebenes, standardisiertes, grobes Gliederungsschema mit festgelegten Inhalten, um Pflichtenhefte gut lesen und vergleichen zu können. Sprache: Detaillierte verbale Beschreibung mit Numerierung einzelner Anforderungen.

22 Kurzfassung: IEEE SRS (Software Requirement Specification)
1 Einleitung (Introduction) Gibt einen Überblick über die Anforderungsdefinition 1.1 Zielsetzung (Purpose) 1.2 Produktziele (Scope) 1.3 Definitionen, Akronyme und Abkürzungen (Definitions, Acronyms and Abbreviations) 1.4 Referenzen (References) 1.5 Überblick (Overview)

23 2. Allgemeine Beschreibung (General Description)
Gibt einen Überblick über das Produkt und die allgemeinen Faktoren, die seine Konzeption beeinflussen 2.1 Produkt-Umgebung (Product Perspective) 2.2 Produkt-Funktionen (Product Functions) 2.3 Benutzer-Eigenschaften (User Characteristics) 2.4 Allgemeine Restriktionen (General Contraints) 2.5 Annahmen und Abhängigkeiten (Assumptions and Dependencies)

24 3 Spezifische Anforderungen (Specific Requirements)
Beschreibung aller Details, die für die Erstellung des System-Entwurfs benötigt werden. Das am besten geeignete Gliederungsschema dieses Kapitels hängt von der Anwendung und der zu spezifizierenden Software ab. Die IEEE-Richtlinie enthält dazu vier Vorschläge: Unabhängig von der Strukturierung sollte das Kapitel folgende Informationen enthalten: Funktionale Anforderungen (Funktional Requirements) Leistungsanforderungen (Performance Requirements) Entwurfsrestriktionen (Design Contraints) Qualitätsmerkmale (Attributes) Externe Schnittstellen-Anforderungen (External Interface Requirements)