Software Engineering
Zusammenfassung
Softwareengeneering <--- ---> Softwareengeneering Part2
Inhaltsverzeichnis:
1 Software-Engineering...................................................................................................................... 4
1.1 Phasen der SW-Entwicklung......................................................................................................
4
1.2 OO SW-Entwicklung..................................................................................................................
4
1.3 Phasen der Booch-Methode........................................................................................................
4
1.3.1 Anforderungsanalyse:........................................................................................................
4
1.3.2 Domain-Analyse...............................................................................................................
4
1.3.3 Systementwurf..................................................................................................................
4
1.3.4 Evaluation........................................................................................................................
4
2 Anforderungsanalyse (AA)............................................................................................................... 5
2.1 Qualitätsmerkmale einer Anforderungsspezifikation.......................................................................
5
2.2 Musterinhaltsverzeichnis für Anforderungsspezifikation..................................................................
6
2.3 Qualitätsmerkmale von Software.................................................................................................
6
2.4 Schlüsselmechanismen (use cases)...........................................................................................
6
2.4.1 Use Case Modell..............................................................................................................
6
2.4.2 Beschreibung eines Use Cases..........................................................................................
6
3 Domain-Analyse (DA)....................................................................................................................... 7
3.1 Dokumentation der Domain-Analyse............................................................................................
7
3.2 Objekte und Klassen finden........................................................................................................
7
3.2.1 Beschreibung von Klassen.................................................................................................
7
3.2.2 Zustandsdiagramm für Klassen..........................................................................................
7
3.3 Beziehungen finden....................................................................................................................
8
3.3.1 Assoziation (gleichrangige Beziehung)................................................................................
8
3.3.2 Aggregation (Ganzes und Teile)..........................................................................................
8
3.4 Methoden definieren – What I do.................................................................................................
8
3.4.1 Implizite Methoden............................................................................................................
8
3.5 Hinweise für Objektszenarios......................................................................................................
8
3.6 Attribute definieren - What I Know...............................................................................................
9
3.7 Vererbung definieren..................................................................................................................
9
4 System Design SD ............................................................................................................ 9
4.1 Prinzipien ...........................................................................................................................
9
4.2 Qualitätskriterien der Modularisierung........................................................................................
10
4.2.1 Kopplung ....................................................................................................................
10
4.2.2 Kohäsion ........................................................................................................
10
4.3 Gliederung des Entwurfs ..........................................................................................
10
4.3.1 Architekturentwurf .........................................................................................
10
4.3.2 Subsystementwurf .........................................................................................
11
4.3.3 Detailentwurf .................................................................................................
11
4.4 Entwurfsdokumentation ..........................................................................................
11
4.5 Releaseplan ..........................................................................................................
12
5 Evolution ........................................................................................................................ 12
5.1 Dokumentation der Implemetation..............................................................................................
13
5.2 Test und Integration .................................................................................................
13
5.2.1 Testkategorien ................................................................................................
13
5.2.2 Testebenen ....................................................................................................
14
5.2.3 Testmethoden .................................................................................................
14
6 Projektmanagment und Qualitätssicherung .................................................................. 15
6.1 Projektmanagement PM .........................................................................................
15
6.2 Qualitätssicherung QS ............................................................................................
16
6.2.1 Was ist Softwarequalität..................................................................................................
16
6.3 Konfigurationsmanagement KM .............................................................................
16
7 Phasen- und Prozessmodelle der SW-Entwicklung........................................................................ 16
7.1 Das Wasserfallmodell .............................................................................................
17
7.2 Das V-Modell .........................................................................................................
17
7.3 Generell über Vorgehensmodelle .............................................................................
17
Software-Engineering ist die Anwendung eines systematischen, disziplinierten und messbaren Verahrens in der Entwicklung, dem Betrieb und der Wartung von Software, d.h. Software-Engineering ist die Anwendung von Engineering auf Software.
Gründe für ein Modell: - Modelle sind Kommunikationsmittel!
- Ein Modell hilft, Fehler und Lücken in den Anforderungen zu finden!
Je später im Entwicklungsprozess ein Fehler gefunden wird, desto teurer.
Eigenschaften von Modellen: - Ein Bild sagt mehr als tausend Worte.
Grafiken vermitteln schnell Übersicht.
- Modelle erlauben, ein System in Teile zu gliedern (Überblick)
- Modelle verwenden Regeln. (Syntaxregeln, Semantische Regeln)
- Analyse à Anforderungsspezifikation,
Projektplan
- Systementwurf à Systementwurfsbeschreibung
- Detailentwurf à Detailentwurfsbeschreibung
- Implementation à Ausgetestete und dokumentierte
Komponenten bzw. Subsysteme
- Integration, Systemtest à Verifiziertes
und validiertes Softwareprodukt
- Wartung à Betriebsfähiges Softwareprodukt
OO SW-Entwicklung: es gibt nur ein Modell. Entwicklungsvorgehen
nicht sequentiell, sondern iterativ.
Das iterative Vorgehen ermöglicht, folgende Aspekte früh
zu beurteilen:
- Eignung des Entwurfs.
- Identifikation von Risikobereichen.
- Akzeptanz beim Kunden - Gültigkeit
von Aufwandabschätzungen und Terminen
Die AA legt die Anforderungen an das System so fest, dass sie als Vereinbarung zwischen Auftraggeber und SW-Ersteller dienen können.
Die DA modelliert den Problembereich entsprechend den in der Anforderungsspezifikation enthaltenen funktionalen Anforderungen in einem formalen, grafischen OO-Modell. Das Domainmodell enthält die essentielle, logische Struktur des Systems.
Der Systementwurf legt die Architektur fest und wie das realisiert wird.
In der Evaluation wird das System in Schritten (evolutionäre Prototypen) vollständig implementiert.
Die AA ist zweiteilig: 1. Sich mit dem Problembereich
vertraut machen. (PA)
2. Anforderungen
spezifizieren. (AS)
Ziel: siehe
1.3.1
Ergebnisse:
- Anforderungsspezifikation (AS) mit Schlüsselmechanismen
- (vorläufiger) Projektplan
Eigenschaften der AS:
Anforderungen sollen nur festlegen, was für Eigenschaften das
Produkt haben soll und nicht, wie diese Eigenschaften realisiert werden.
Um das Was auszudrücken sind Black-Box-Beschreibungen geeignet. Bei komplexen
Zusammenhängen ist eine White-Box sinnvoll.
Korrektheit
· Jede Anforderung ist eine Anforderung die mit der Software erfüllt wird.
Eindeutigkeit
·
Jede Anforderung hat nur eine Interpretation (Problem
mit natürlicher Sprache)
·
Begriffsdefinitionen, Glossar wichtig
Vollständigkeit
·
Nicht nur funktionale Anforderungen
·
Verhalten in allen möglichen Situationen (z.B. unzulässige
Eingabedaten)
·
Struktur nach Norm mit durchgehender Numerierung
(auch Figuren, etc.)
Konsistenz
·
Nicht verschiedene Begriffe für gleiche Objekte,
Sachverhalte
·
Keine widersprechende Anforderungen
Mit Gewichtung versehen, bez. Wichtigkeit/Stabilität
·
Wichtigkeit: Muss- / Soll- / Wunschanforderungen
·
Stabilität: Erwartete Änderungen
Überprüfbarkeit
·
Jede Anforderung überprüfbar (z.B. nicht einfach
"benutzerfreundlich")
·
Keine schwammigen Formulierungen (wie z.B. "normalerweise")
·
Keine Anforderungen wie "fehlerfrei" (lässt sich
nicht nachprüfen)
Änderbarkeit
·
Struktur, Inhaltsverzeichnis, Glossar, Querverweise
·
Vorsicht mit Redundanz (Querverweis).
·
Leistungsfähiges Dokumentationswerkzeug und Verfahren.
Verfolgbarkeit
·
Jede Anforderung muss eindeutig referenzierbar sein
·
Rückverfolgbarkeit auf Quelle jeder Anf.
·
Vorwärts-Verfolgbarkeit zur Realisierung jeder Anforderung
|
1.
Einführung 2.
Allgemeine Beschreibung |
|
3.2.3.
Software Schnittstellen |
· Funktionalität: Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmässigkeit, Sicherheit
· Zuverlässigkeit: Reife, Fehlertoleranz, Wiederherstellbarkeit
· Benutzbarkeit: Verständlichkeit, Erlernbarkeit, Bedinbarkeit
· Effizienz: Zeitverhalten, Verbrauchsverhalten
· Änderbarkeit: Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit
· Übertragbarkeit: Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit
Eine verhaltensmässig zusammenhängende Folge von Transaktionen (transaction), die von einem System angeboten werden und einem Aktor (actor) einen messbaren Nutzen bringen.
Aktor: Eine Rolle (oder eine Menge von Rollen), die jemand oder etwas in der Umgebung des Systems in Zusammenhang mit dem System spielt. Ein Aktor liegt ausserhalb des zu beschreibenden Systems.
Transaktion: Eine Folge von Aktionen, die entweder als Ganzes oder gar nicht durchgeführt werden. Eine Transaktion wird durch ein Ereignis gestartet. Ein Ereignis wird durch einen Aktor oder durch das Erreichen eines Zeitpunktes ausgelöst.
Das Use Case Modell besteht aus: Aktor, Use Case, Zusammenhang zwischen Aktor und Use Case, Beschreibung des Use Case. Das Use Case Modell ist ein externes Modell, es beschreibt nur das was von aussen aus dem Blickwinkel der Aktoren sichtbar ist.
·Auslösender Aktor und auslösendes Ereignis
·Grundlegender Ablauf
Ø Aktion 1
Ø Aktion 2
Ø ...
Ø Aktion n
·Alternative Abläufe für Spezialfälle, Fehlerbedingungen
·Vorbedingungen und Nachbedingungen
Ziel:
siehe 1.3.2
Ergebnisse: Klassendiagramme (statische Sicht des Problembereichs), Klassenspezifikationen
(evtl. mit Zustandsdiagramm), Objekt-Szenario-Diagramme
bzw. Interaktionsdia-gramme (dynamische Sicht der Systemfunktionalität).
Schritte der DA:
·
Objekte und Klassen finden, welche die Schlüsselabstraktionen
des Problembereichs bilden.
·
Beziehungen zwischen den Klassen finden, d.h. Assoziationen
und Aggregationen.
·
Methoden definieren.
·
Attribute festlegen.
·
Generalisierungen und Spezialisierungen finden:
Vererbung festlegen.
|
1.1.1.1.1 Aggregation ag 2. Das
dynamische Modell – die Schlüsselmechanismen (use cases) 3.3.2.3 Alternative 1 |
|
3. Einführung 4. Das statische Modell – die Klassenstruktur
|
· Suchen nach Strukturen
· Andere Systeme mit denen das System zusammenarbeitet
· Geräte: Mit welchen externen Geräten tauscht das System Informationen aus?
· Ereignisse: Welche Dinge oder Ereignisse müssen erinnert werden?
· Rollen: über welche Personen bzw. Rollen von Personen verwaltet das System Informationen? (in der Regel keine Aktoren, ausser das System muss etwas über sie erinnern.)
·
Orte: Muss das System Orte kennen, z.B. Standorte
von Geräten, seinen eigenen Standort?
·
Organisatorische Einheiten: Zu welchen Organisationen
gehören die Personen?
Die Beschreibung von Klassen enthält den Namen der Klasse, die Definition, die Randbedingungen, Attribute, Methoden, eventuell Zustandsdiagramm der Klasse und die Datentypen der Attribute.
Zeigen Objekte ein zustandsabhängiges Verhalten wird dies in einem Zustandsdiagramm modelliert:
Zustandsabhängiges Verhalten heisst:
·
Dass ein Methodenaufruf je nach Zustand eine andere
Wirkung zeigt oder
·
Dass ein Methodenaufruf nur in bestimmten Zuständen
zulässig ist.
·
Welche anderen Objekte muss ein Objekt einer Klasse
kennen?
·
Von welchen andern Objekten benötigt das Objekt
Dienstleistungen, bzw. von welchen anderen Objekten benutzt es Methoden?
·
Teile die zu einem Ganzen zusammengesetzt sind.
(Assembly-Part Pattern)
·
Teile die sich in einem Ganzen (in einem Container)
befinden. (Container-Content Pattern)
·
Mitglieder einer Ansammlung von Dingen. (Group-Member
Pattern)
by value: Teile existieren nur mit seinem Ganzen.
by referenz: Teile können auch ohne Ganzes existieren.
Um Methoden zu finden sind die Schlüsselmechanismen auszuführen, dabei werden die erf. Methoden ersichtlich.
- "Do
iIt Myself" Strategie: Was mit realen Objekten getan wird, tun Software-Objekte
selbst. Z.B. Einzahlen auf ein Bankkonto-Objekt. Ausnahme Simulationssoftware.
- "Put
Services With The Attributes They Work On" Strategy.
- "Placing
Services" Strategy: Collection-Objekte bearbeiten ihre eigenen Attribute. Collection-Objekte
verlangen in der Regel einen Service und nicht nur Datenwerte von ihren Worker-Objekten.
- "Service
in The Smallest Applicable Container" Strategy.
|
Implizite Methoden werden erst im Entwurf untersucht. |
· Erzeugen und initialisieren von Objekten
· Verbinden von Objekten
·
Zugriff auf Attribute
·
Löschen von Objekten
- "Don’t Ask What Kind?" Strategy: Man soll nicht ein Objekt fragen, was für eine Art von Objekt es ist und abhängig von der Antwort von ihm einen entsprechenden Service verlangen. Statt dessen sollten entsprechende Spezialisierungen des Objektes geschaffen werde, so dass das Objekt selbst weiss, was zu tun ist.
- "Search Then Interact" Strategy: Wenn auf ein Objekt über mehrere Objektverbindungen zugegriffen werden muss: Zuerst das Objekt suchen, dann direkt von ihm den gewünschten Service verlangen. So werden die dazwischenliegenden Objekte einfacher.
- "Act, Rather than Poll" Strategy.
- "Get Values Only When You Need Them" Strategy: Übergebe nicht einzelne Werte (Attribute) als Parameter, sondern das ganze Objekt. Hole die Werte erst aus dem Objekt, wenn sie gebraucht werden.
Um Attribute zu identifizieren, kann man folgende Fragen stellen:
·
Was muss ein Objekt einer Klasse wissen?
·
Aus der Sicht eines Objektes fragt man:
Ø
Wie werde ich im Kontext der Verantworung des Systems
beschrieben?
Ø
Was muss ich wissen?
Ø
Welche Zustandsinformation muss ich erinnern?
Ø
In welchen Zuständen kann ich sein?
·
Man wähle natürliche Attribute: einzelne Daten (z.B.
AHV-Nummer) oder eng zusammengehörige Daten (z.B. Adresse).
·
Jede Klasse betrachte man als Verallgemeinerung
und suche potentielle Spezialisierungen.
·
Jede Klasse betrachte man als Spezialisierung und
suche potentielle Verallgemeinerungen.
·
Klassen mit mehreren gleichen Attributen können
Spezialisierungen der gleichen Verallgemeinerung sein.
·
Klassen mit mehreren gleichen Operationen können
Spezialisierungen der gleichen Verallgemeinerung sein.
·
Treten alle Attribute und Operationen einer Klasse
auch in einer anderen auf, kann diese eine Spez. der ersten sein.
Das SD definiert, wie das Domainmodell und die Schlüsselmechanismen implementiert werden. Ausserdem legt es die Architektur des Softwaresystems fest.
è Klassenkategorien–Diagramm
è Architekturbeschreibung
è Entwurfs–Klassendiagramme
è Vollständige–Klassenspezifikationen
è Entwurfs–Objektszenario–Diagramme
|
1 |
Architektur mit loser Kopplung und hoher Kohäsion der Strukturelemente. Lose Kopplung erreicht man z.B. mit einer Schichtenarchitektur. Die Schichten selbst können auch in Subsysteme unterteilt werden, welche lose gekoppelt sind, aber eine hohe Kohäsion aufweisen. Subsysteme können auch durch Klassenkategorien modelliert werden. Die grösste Kohäsion weisen Systemteile auf, die nur einer einzigen Funktion dienen. |
|
2 |
Domainmodell und implementationstechnische Aspekte trennen. Implementationstechnische Systemteile, wie z.B. Benutzerschnittstelle, Datenverwaltung und Betriebssystemaufrufe, sollten vom Domainmodell getrennt werden. è bessere Verständlichkeit und Wartbarkeit. |
|
3 |
Jede Entwurftsentscheidung in einer Klassenkategorie kapseln. Sind die einzelnen Implementationstechnologien in verschiedenen Klassenkategorien isoliert, so können sie ausgetauscht werden, ohne dass der Rest des Systems beeinflusst wird. |
|
4 |
Iterative Entwicklung (Entwurf und Implementierung) einer Folge von Prototypen oder Releases. Es ist schneller eine lauffähige Version verfügbar. Es können zuerst die mit grossen Unsicherheiten behafteten Teile realisiert werden, so kann das Risiko mit jedem Release reduziert werden. Der Benutzer kann rasch ein Feedback geben. |
|
5 |
Entwurf für Wiederverwendbarkeit. Wiederverwendbarkeit ist ein wichtiges Qualitätsmerkmal von Software. |
Eine gute Struktur zeichnet sich aus durch gute Wartbarkeit und hohe Wiederverwendbarkeit.
Kopplung ist der Grad der Abhängigkeit zwischen Modulen.
Kohäsion ist der Grad der funktionellen Zusammengehörigkeit der Elemente eines Moduls. Die Kohäsion eines Moduls soll möglichst hoch sein. Folgende Tabelle zeigt verschiedene Stufen mit abnehmender Kohäsion.
Im Architekturentwurf geht es darum, über die einzusetzende Technologie (SW–Bausteine) zu entscheiden, das heisst, das System in einzelne Subsysteme zu unterteilen und die Schnittstellen zwischen den Subsystemen (Exportklassen) zu definieren.
Das Festlegen einer Architektur beinhaltet:
1.
Eine Reihe von strategischen Entscheidungen bezüglich
der eingesetzten Technologie (HW, SW–Bausteine,...).
2.
Das Unterteilen des Systems in eine Reihe von Subsystemen
(Klassenkategorien) die unabhängig entwickelt werden können.
Folgende Architekturbausteine sind zu evaluieren:
|
·
Betriebsystem |
·
Gerätetreiber für Peripherie |
Der Architekturentwurf besteht aus folgenden Schritten:
1.
Auswahl geeigneter Subsysteme (Klassenkategorien).
2.
Schnittstellen der Klassenkategorien spezifizieren.
Im Subsystementwurf wird die innere Struktur der Klassenkategorien
erarbeitet und in einem Klassendiagramm dargestellt.
Folgende Tätigkeiten sind inbegriffen:
·
Bestimmen von Assoziationen
·
Bestimmen von Aggregationen (By Value / By Reference)
·
Festlegen von Container (Stack, Listen, Baumstrukturen...)
·
Festlegen der Zugriffsebenen (implementation ,private,
protected, public)
·
Festlegen der Synchronisation (simple: keine Spezifikation
der Synchronisation; synchronous: Sender muss warten, bis Empfänger Botschaft
übernommen hat; asynchronous: Meldung wird abgeschickt. Sender kann weiterfahren.
Empfänger kann irgend einmal lesen; timeout: Sender wartet nur gewisse Zeit;
balking: Ist Empfänger nicht bereit, abbrechen)
Im Detailentwurf wird die innere Struktur der Klassen,
das heisst im wesentlichen die Methoden, erarbeitet und beschrieben.
Für einfache Methoden genügt die Beschreibung in der DA.
Komplexere (umfangreiche Algorithmen, interagierende Methoden) Methoden müssen
im Detail entworfen werden.
·
Interagierende Methoden werden am besten mit Interaktionsdiagrammen
und zugehörigem Skript (Pseudocode, N–S–Diagramm oder Zustands–Diagramm) beschrieben.
Man stellt sich folgende Fragen:
1. Gehört jedes angesprochene Objekt einer definierten Klasse an?
2. Besitzt diese Klasse die erforderlichen Methoden, welche das gewünschte
Resultat liefern?
3. Gibt es einen
Weg (Navigationspfad), durch welchen die Methode das angesprochene Objekt lokalisieren
kann?
·
Algorithmen werden am besten mit N–S–Diagrammen
oder Zustands–Diagrammen beschrieben.
Nur wenn man in der Lage ist, eine Software–Architektur verständlich zu beschreiben, besteht eine Gewisse Gewähr, dass man sie auch realisieren kann.
Inhaltsverzeichnis:
|
1.
Einführung 2.3.
Schnittstellen der
Klassenkategorien · Eventuell Illustration mit Interaktionsdiagramm 2.4.
Architekturkonzepte 3. Beschreibung der Klassenkategorie 1 3.1.
Klassendiagramm |
3.2.
Klassenspezifikationen 3.3.
Architekturkonzepte
für Klassenkategorie 4.
Modulstruktur 5.
Prototypen |
Mit jedem Release wird ein bestimmtes Ziel anvisiert.
Ein Release ist ein lauffähiges System.
Als Leitlinie sollte gelten, das Entwicklungsrisiko für
das Gesamtsystem zu minimieren, das heisst kritische Teile möglichst frühzeitig
zu implementieren.
Ein Releaseplan sollte folgende Punkte enthalten:
·
Eine Übersicht über die geplanten Prototypen und
deren Abhängigkeiten
·
Für jeden Prototyp:
·
Ziel, das mit dem Release erreicht werden soll.
·
Identifikation der Klassen, die für den Release
implementiert werden.
·
Aufzählung der Schlüsselmechanismen, die implementiert
werden.
·
Notwendige Ein- und Ausgabedaten.
·
Gegebenenfalls Angaben über notwendigen Hilfscode.
Die Evolution besteht hauptsächlich aus Implementierung,
Test und Integration. Das SD wird laufend ergänzt. Allenfalls müssen noch Änderungen
an AS, DA und SD gemacht werden.
Gemäss SD wird Prototyp für Prototyp erstellt und Dokumentiert.
·
Welche Klasse in welchem File
·
Welche Subsysteme gibt es, welche Klassenkategorien
importiert sie
·
Sourcecode strukturiert nach Subsystemen, alphabetisch
·
Codegenerierung ist nicht zu empfehlen.
Ein Fehler ist
das Nichterfüllen einer Anforderung
Error : verursacht durch menschliche Fehlkonstruktion.
Fault: Error kann zu Fault in Programmausführung
führen.
Failure: Mission nicht erfüllt aufgrund von Faults.
J Ein Test ist reproduzierbar
·
Testablauf festgelegt
·
Testfälle spezifiziert
·
Vor allem wichtig für Regressionstests (Wiederholung
eines früheren Tests, um festzustellen, ob nachträgliche Änderungen nicht zu
neuen Fehlern geführt haben) wichtig.
K Die Zielumgebung wird mitgeprüft.
K Der Test zeigt die Fehlerursache nicht.
L Die Ergebnisse des Tests werden überschätzt.
Es können keine Tests für alle Eingabewerte durchgeführt
werden
Ein Test besteht aus Testvorbereitung, Testausführung und
Testauswertung. All dies wird im Testbericht zusammengefasst.
Funktionale Tests (Black-Box-Test)
·
Prüfen der funktionalen Anforderungen.
·
Die Auswahl der Testfälle richtet sich nach den
Eingaben, Ausgaben und ihrer funktionellen Verknüpfung
|
Äquivalenzklassenmethode: |
Ein Wertebereich einer Eingabegrösse, für welche der Prüfling voraussichtlich das gleiche Verhalten zeigt, wird als Äquivalenzklasse bezeichnet. Um die Anzahl der Tests in Grenzen zu halten, wird man oft für jede Äquivalenzklasse nur einen Testfall auswählen. |
|
Grenzwertanalyse |
Fehler treten erfahrungsgemäss oft an Grenzen zulässiger Wertebereiche von Eingabegrössen auf. Darum werden hier die Testfälle an den Grenzen gewählt. |
|
Zustandsbasiertes Testen |
Für jeden Zustand wird ein Testfall definiert. |
Leistungstests (Black-Box-Test)
Leistungstest prüfen das Erreichen der Leistungsanforderungen.
Stresstests (Black-Box-Test)
Mit Stresstests versucht man die Software zum Abstürzen
zu bringen, das heisst das Qualitätsmerkmal Robustheit zu prüfen.
Modultest
Der Modultest testet eine einzelne, isolierte Programmeinheit.
Ein Modultest kann Black- oder White–Box–Test sein.
Integrationstest
Der Integrationstest testet mehrere zusammenhängende
Module oder Subsysteme. Integrationstests sind eigentlich White-Box-Tests bezüglich
der Modulstruktur, aber Black-Box gegenüber den einzelnen Modulen.
|
Bottom-up Test |
Man beginnt mit den Modulen auf der untersten Ebene der Aufrufhierarchie. Bei diesem Vorgehen braucht man keine Teststummel, jedoch Testtreiber. |
|
Bottom-down Test |
Man beginnt mit den Modulen auf der obersten Ebene der Aufrufhierarchie. Bei diesem Vorgehen braucht man keine Testtreiber, jedoch Teststummel. |
Systemtest
Der Systemtest testet das Gesamtsystem. Ist in der
Regel ein Black-Box-Test.
Überblick über Testmethoden:
White-Box-Test (Strukturtest)
Die Auswahl der Testfälle richtet sich nach den Ablaufmöglichkeiten
des Programms.
|
Kontrollflussorienterter Test |
·
Anweisungsabdeckung (min 100%) |
|
Integrationstest |
·
Programmeinheiten Abdeckung |
|
Datenflussorientierter Test |
· Defs/Uses – Verfahren (jeder Variabel-Zugriff wird kategorisiert (defs: Wertzuweisung; c-use: lesen zum Berechnen eines Ausdrucks; p-use: lesen in Bedingung) |
Black – Box – Test
Die Auswahl der Testkriterien richtet sich nicht nach
der Implementation, sondern nach den gegen aussen Spezifizierten Randbedingungen
(Use-Case)
Ein Softwareprojekt ist grundsätzlich in 4 Teile Gegliedert. (Die Softwareerstellung wurde in den vorderen Kapiteln behandelt)
Grundsätzliche Probleme der Softwareentwicklung.
·
Strukturierung des Entwicklungsablaufes
·
Aufwandabschätzung bzw. Planung
·
Bewerten des Erreichten, der Qualität
·
Einsatz von analytischen Qualitätssicherungsmassnahmen
(z.B. Reviews, Tests)
·
Verständnis für die Kosten im Zusammenhang mit Fehlern
·
Änderungen der Anforderungen
·
Umgang mit Fehlern
Wie die meisten Systemmodelle beinhaltet ein umfassendes Modell der Softwareentwicklung eine statische (funktionale) und eine dynamische Sicht. Ist ein solches Modell so detailliert, dass es die einzelnen Tätigkeiten mit Ein- und Ausgabedaten zeigt, so sprechen wir von einem Prozessmodell. Wird der Ablauf einer Softwareentwicklung in einzelne Phasen unterteilt, so sprechen wir von einem Phasenmodell.
Das Projektmanagement hat das Ziel, das Projekt
erfolgreich abzuschliessen.
·
mit den vorgesehenen Mitteln (Personal, Kosten,
Ressourcen)
·
innerhalb der Termine
·
mit Resultaten der geforderten Qualität.
Die Wichtigsten Aufgaben des PM sind:
·
Planung und Kommunikation
·
Schaffen und Wahren geeigneter Rahmenbedingungen
·
Motivation und Kontrolle der Mitarbeiter
·
Schutz des Projektes vor der Umgebung
·
Frühes Erkennen und Neutralisieren unerwarteter
Schwierigkeiten
Software-Qualitätssicherung: Alle geplanten und systematischen Tätigkeiten, die notwendig sind, um ein hinreichendes Vertrauen zu schaffen, dass das Produkt die festgelegten Qualitätsanforderungen erfüllen wird.
|
Konstruktive Massnahmen |
·
Präventiv Qualitäsmängeln entegenwirken |
|
Analytische Massnahmen |
· Prüfung und Bewertung der Qualität |
Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.
Software-Konfigurationsmanagement unterstützt alle Tätigkeiten der SW-Entwicklung indem KM sich der anfallenden Arbeitsresultate (Dateien) annimmt und dafür sorgt, dass jederzeit klar ist WER, WAS, WANN und WIE geändert hat.
Das KM ist ein Satz von Verfahren technischer Natur und organisatorischer Natur, mit denen gewisse Objekte zu bestimmten Zeitpunkten eindeutig identifizierbar sind (Konfigurationsverwaltung) und mit denen die Änderungen dieser Objekte, ein nachvollziebarer Vorgang ist (Änderungswesen).
Die Verfahren für KM hängen stark von der Grösse des Projektes ab.
Unterteilung des Projektablaufes in zeitlich und funktional abgegrenzte Teile mit dem Ziel sie planbar, überschaubar und kontrollierbar zu machen und eine bessere Qualität des SW-Produktes zu erreichen.
Die Verwendung von Vorgehensmodellen hat folgende
Vorteile:
·
Fördert die Kommunikation im Projekt.
·
Verbessert die Führbarkeit eines Projektes.
·
Erleichtert die Zuordnung von Ressourcen.
·
Erleichtert Kostenkontrolle.
·
Erhöht die Qualität des entstehenden SW-Produktes.
·
Erst planen, dann ausführen ergibt bessere Systemstruktur.
·
Erzwingt Dokumentation
Einzelne Phasen (AS, DA, SD, Imp...) laufen zeitlich
sequentiell ab. Für die praktische Anw. liegt hier das Probelm:
·
Anforderungen ändern während der Entwicklung
·
Bei völlig neuen Produkten lassen sich Anforderungen
oft nicht vollständig definieren.
·
Aufwandabschätzung zu Projektbeginn schwierig.
·
Fehler erfordern Rückgriffe in frühere Phasen.
·
Es dauert bei grossen Projekten zu lange bis ein
Produkt praktisch erprobt werden kann.
Merkmale des V – Modells:
|
J
Verbesserte Kommunikation der Projektbeteiligten |
L Die Vorgehenskonzepte, die für grosse eingebettete Systeme sinnvoll sind, werden unkritisch auf andere Anwendungstypen übertragen. L Ohne geeignetes CASE-Tool ist das V-Modell nicht handhabbar. L Für kleine und mittlere Softwareentwicklungen führt das V-Modell zu einer unnötigen Software-Bürokratie. L Es fehlen in der Dokumentation vollständige Beispiele. |
Es gibt kein Vorgehensmodell, das sich für alle Software-Projekte
geeignet wäre. Die Wahl hängt von verschiedenen Faktoren ab:
·
Anwendungsbranche: z.B. Bankwesen, Industrie
·
Art der Anwendung (EDV, Informationssystem, Echtzeitsystem...)
·
Architektur der zu entwickelnden Anwendung
·
Grösse und Komplexität der Anwendung
·
Organisation Firma
·
Marksituation
·
Vertragsentwicklung für Auftraggeber
·
Produktentwicklung für Markt
·
Tenchologie (Prozedurale- / OO-Programmiersprachen,
4GL, Wiederverwendung von Komponenten)
Softwareengeneering <--- ---> Softwareengeneering Part2