19 software lebenszyklus und anforderungsanalyse
This presentation is the property of its rightful owner.
Sponsored Links
1 / 24

19. Software-Lebenszyklus und Anforderungsanalyse PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on
  • Presentation posted in: General

19. Software-Lebenszyklus und Anforderungsanalyse. Der Software-Entwicklungsprozeß. Anforderungs-analyse. Spezifikation. Entwurf (Design ). Implementierung (Programmierung). Verifikation (Test). abschließender Schritt: Wartung der erstellten Software

Download Presentation

19. Software-Lebenszyklus und Anforderungsanalyse

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


19 software lebenszyklus und anforderungsanalyse

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


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


Planen eines produkts

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


Durchf hrbarkeits untersuchung

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


Pr fen der konomischen durchf hrbarkeit

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.


19 software lebenszyklus und anforderungsanalyse

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, ...)


Aufbau eines lastenheftes

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“.


19 software lebenszyklus und anforderungsanalyse

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.


19 software lebenszyklus und anforderungsanalyse

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.


19 software lebenszyklus und anforderungsanalyse

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.


Seminaranmeldung

Als Teilnehmer zu nachfolgenden Seminaren wird angemeldet:

Titel

Vorname

Name

vombis

Veranstaltungs-Nr.

Seminarbezeichnung

Anmeldebestätigung und Rechnung erbeten an:

Titel

Vorname

Name

Firma

Straße / Postfach

LKZ

PLZ

ORT

Telefon

Seminaranmeldung


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

Produkt-Definition


Abb zu beschreibende sichten und ihre konzpte

Assoziations-Matrix

Abb. Zu beschreibende Sichten und ihre Konzpte

  • 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


Begriffe zur abbildung

Begriffe zur Abbildung

Benutzer-Oberfläche

ER= Entity RelationshipDD= Data Dictionary

DFD= Datenfluß-DiagrammRT= Real Time Analysis

OOA= Object Oriented AnalysisSA= 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.


Komplexit tsarten

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.


Komplexit t der daten

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.


Komplexit t der systemumgebung

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.


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.

Ein Basiskonzeptläß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.


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

    1984Der Standard Guide for Software Requirements wurdevon der IEEE

    verabschiedet und 1985 von der ANSI (American National Standard

    Institute) übernommen.

Überblick über Basiskonzepte,


Aufbau eines pflichtenheftes

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.


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.

Inhalt:


Kurzfassung ieee srs software requirement specification

Kurzfassung: IEEE SRS(Software Requirement Specification)

1Einleitung (Introduction)

Gibt einen Überblick über die Anforderungsdefinition

1.1Zielsetzung (Purpose)

1.2Produktziele(Scope)

1.3Definitionen, Akronyme und Abkürzungen(Definitions,

Acronyms and Abbreviations)

1.4Referenzen(References)

1.5Überblick (Overview)


2 allgemeine beschreibung general description

2.Allgemeine Beschreibung (General Description)

Gibt einen Überblick über das Produkt und die allgemeinen

Faktoren, die seine Konzeption beeinflussen

2.1Produkt-Umgebung (Product Perspective)

2.2Produkt-Funktionen (Product Functions)

2.3Benutzer-Eigenschaften (User Characteristics)

2.4Allgemeine Restriktionen (General Contraints)

2.5Annahmen und Abhängigkeiten (Assumptions and Dependencies)


3 spezifische anforderungen specific requirements

3Spezifische 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)


  • Login