G.Heyer Digitale Informationsverarbeitung 1 19. Software-Lebenszyklus und Anforderungsanalyse...
-
Upload
karlotte-eggenberger -
Category
Documents
-
view
104 -
download
0
Transcript of G.Heyer Digitale Informationsverarbeitung 1 19. Software-Lebenszyklus und Anforderungsanalyse...
G.Heyer Digitale Informationsverarbeitung1
19. Software-Lebenszyklus und Anforderungsanalyse
Anforderungs-analyse
Spezifikation
Verifikation (Test)
Implementierung
(Programmierung)
Entwurf (Design)
Integration
• abschließender Schritt: Wartung der erstellten Software
• Wahl der Programmiersprache beeinflußt auch frühere Phasen
Der Software-Entwicklungsprozeß
G.Heyer Digitale Informationsverarbeitung2
Der Software-Entwicklungsprozeß (2)
FORDERUNGS-ANALYSE
ARCHITEKTUR
SYSTEM-SPEZIFIKATION
WARTUNG / PFLEGE
DETAILLIERTER ENTWURF
QUELLTEXTSCHREIBEN UNDFEHLER SUCHEN
TESTENDES MODULS
TESTENDES SYSTEMS
Entwurf: 40 %
Implementierung: 20 %
Testen und Dokumentation: 40 %
G.Heyer Digitale Informationsverarbeitung3
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
G.Heyer Digitale Informationsverarbeitung4
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
G.Heyer Digitale Informationsverarbeitung5
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.
G.Heyer Digitale Informationsverarbeitung6
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, ...)
G.Heyer Digitale Informationsverarbeitung7
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“.
G.Heyer Digitale Informationsverarbeitung8
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.
G.Heyer Digitale Informationsverarbeitung9
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.
G.Heyer Digitale Informationsverarbeitung10
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.
G.Heyer Digitale Informationsverarbeitung11
Seminaranmeldung
Als Teilnehmer zu nachfolgenden Seminaren wird angemeldet:
Titel Vorname Name
vom bis
Anmeldebestätigung und Rechnung erbeten an:Titel Vorname Name
Firma Straße / Postfach LKZ
ORTPLZ Telefon
Veranstaltungs-Nr. Seminarbezeichnung
G.Heyer Digitale Informationsverarbeitung12
Produkt-DefinitionDiese 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
G.Heyer Digitale Informationsverarbeitung13
Abb. Zu beschreibende Sichten und ihre Konzpte
Benutzer
• Grafik-Editor
• Kontroll-
Strukturen
• Regeln
Daten
• ER (Entity Relationship)
• DD (Data Dictionary)
• DFD (Datenfluß-Diagramm)
Dynamik
• Petri-Netz
• Zustandsautomat
• Kontroll-Strukturen
• Interaktions-Strukturen
Funktionen
• Funktions-Baum
• DFD (Datenfluß-
Diagramm)
SystemOOA
RT-Erweiterung von SA
Assoziations-Matrix
Masken-Generator
SA
G.Heyer Digitale Informationsverarbeitung14
Begriffe zur Abbildung
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.
Benutzer-Oberfläche
G.Heyer Digitale Informationsverarbeitung15
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 1.000 und 1.500 Funktionen.
Ein DTP-System hat einen Funktionsumfang von 700 bis 1.000 Funktionen.
G.Heyer Digitale Informationsverarbeitung16
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.
G.Heyer Digitale Informationsverarbeitung17
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.
G.Heyer Digitale Informationsverarbeitung18
Ein Basiskonzept läßt sich durch folgende Eigenschaften charakterisieren:
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.
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.
G.Heyer Digitale Informationsverarbeitung19
Ü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.
G.Heyer Digitale Informationsverarbeitung20
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.
G.Heyer Digitale Informationsverarbeitung21
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.
G.Heyer Digitale Informationsverarbeitung22
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)
G.Heyer Digitale Informationsverarbeitung23
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)
G.Heyer Digitale Informationsverarbeitung24
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)