Zusammenfassung Software-Engineering
Inhalt
Zusammenfassung Software-Engineering ............................................................................................... 1
•
Notizen zu den Abschnitten ........................................................................................................ 3
1 Software-Krise und Software Engineering.................................................................................... 3
1.1 Krisenstimmung .................................................................................................................... 3
1.3 Software Krise....................................................................................................................... 3
1.4 Begriff und Disziplin “Software Engineering”......................................................................... 3
2 Grundlagen des Software Engineering......................................................................................... 4
2.1 Phasen der Software-Entwicklung ........................................................................................ 4
2.2 Grundlegende Prinzipien....................................................................................................... 4
2.3 Prinzip Modularisierung......................................................................................................... 5
2.4 Bereiche des Software Engineering...................................................................................... 5
3 Projektmanagement ..................................................................................................................... 6
3.1 Grundlagen ........................................................................................................................... 6
3.2 Projektaufbau und Rollen...................................................................................................... 6
3.3 Projektplanung und Darstellung ............................................................................................ 6
3.4 Projektkontrolle und –steuerung ........................................................................................... 8
3.5 Brook’sches Gesetz .............................................................................................................. 9
3.6 Aufwandsschätzung............................................................................................................ 10
Vokabeln................................................................................................................................... 10
4 Konfigurationsmanagement........................................................................................................ 11
4.1 Motive und Begriffe ............................................................................................................. 11
4.2 Aufgaben und Verfahren ..................................................................................................... 11
4.3 Konfigurationselemente ...................................................................................................... 11
4.4 Konfigurationsmanagement Plan ........................................................................................ 11
4.5 Projektstruktur..................................................................................................................... 11
4.6 Verwaltung der Konfigurationselemente ............................................................................. 12
4.7 Release-Management......................................................................................................... 13
4.8 Werkzeug zur Versionskontrolle: Subversion...................................................................... 13
4.9 Automatisierung des Build-Prozesses................................................................................. 13
Vokabeln................................................................................................................................... 14
5 Software-Modelle ....................................................................................................................... 14
5.1 Grundlagen und Modelltypen .............................................................................................. 14
5.2 Programmablaufplan........................................................................................................... 15
5.3 Struktogramm ..................................................................................................................... 15
5.4 Funktionsbaum ................................................................................................................... 15
5.5 Strukturierte Analyse (SA)................................................................................................... 16
5.6 EBNF und Syntaxdiagramm................................................................................................ 16
5.7 Entity-Relationship-Modellierung (ERM) ............................................................................. 17
5.8 Objektorientierte Modellierung mit UML .............................................................................. 17
5.9 Geschäftsprozessmodellierung mit ARIS............................................................................ 20
5.10 Formale Modellierung mit Petri-Netzen............................................................................. 21
6 Softwareprozesse und Vorgehensmodelle................................................................................. 22
6.1 Softwareentwicklung in Phasen .......................................................................................... 22
6.2 Unsystematische „Modelle“................................................................................................. 22
1
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
6.3 Lineare / Sequentielle Modelle............................................................................................ 22
6.4 Frühe Prototypen / Rapid Prototyping................................................................................. 23
6.5 Evolutionäre, inkrementelle Modelle ................................................................................... 23
6.6 Objektorientierte Modelle .................................................................................................... 24
6.7 Microsoft Vorgehen............................................................................................................. 25
6.8 Agile Modelle ...................................................................................................................... 25
6.9 Weitere Phasenmodelle ...................................................................................................... 26
6.10 Fokus: Analysephase, Requirements Engineering............................................................ 26
6.11 Fokus: Entwurfsphase....................................................................................................... 27
7 Qualität....................................................................................................................................... 27
7.1 Einordnung und Begriff ....................................................................................................... 27
7.2 Qualitätseigenschaften........................................................................................................ 27
7.3 Wege zur Qualität ............................................................................................................... 28
7.4 Qualität und Softwareentwicklung....................................................................................... 28
Quellennachweis: .......................................................................................................................... 29
2
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
• Notizen zu den Abschnitten
1 Software-Krise und Software Engineering
1.1 Krisenstimmung
Es gab für die Software-Krise vor allem folgende Gründe:
Fehlerhaft
Unzuverlässig
Wartungsunfreundlich
schwer portierbar
Um auf diese Probleme zu reagieren fand 1967/1968 das NATO Science Committee statt.
1.3 Software Krise
Als Folge dieses Treffens fand eine Zäsur in der Softwareherstellung statt mit der resultierenden
Entwicklung von neuen Methoden:
Spezifikationsmethoden, Formalismen,
Spezifikationssprachen, Requirements Engineering
Brookssches Gesetz, Kommunikationsregeln,
Gruppenorganisation, Schnittstellendefinition
Projektmanagement, Organisation, Ermittlung des Projektfortschritts
Validierung nach jedem Schritt statt nur einmal
Schnittstellenbeschreibung, Administration von Komponenten
Falschbedienung vorsehen, Dialoge planen, Handbücher, Tutorials
Versionskontrolle, Release Management, Strukturierung, Dokumentation
1.4 Begriff und Disziplin “Software Engineering”
Oberstes Ziel bei dieser Neuausrichtung war:
Suche nach einem wissenschaftlichen Vorgehen, das eine systematische und
qualitätsorientierte Entwicklung ermöglicht: ingenieurswissenschaftliches Vorgehen
3
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
2 Grundlagen des Software Engineering
2.1 Phasen der Software-Entwicklung
1. Anforderungsphase
(Kosten ca. 3%)
Analyse der Kundenwünsche
Exploration des Anwendungsgebietes (Domäne)
Erarbeitung der Anforderungen
2. Spezifikationsphase
(Kosten ca. 4%)
Präzise Festlegung der Leistungen
Spezifikationsdokument (→ Kontrakt)
3. Planungsphase
(Kosten ca. 2%)
Entwurf der Projektdurchführung
Projektmanagementplan
Zeitdauer, Aufwandsabschätzung
(Kosten ca. 6%)
4. Entwurfsphase
Hardware-/Softwareentwurf
Systemarchitektur (Konzeption im Großen, Zerlegung in Module)
Detailentwurf (Implementierung der Module)
5. Implementierungsphase (Kosten ca. 12%)
Implementierung der Programmkomponenten (arbeitsteilig)
Testen der Komponenten (Modultest)
6. Integrationsphase
(Kosten ca. 6%)
Integration der Komponenten
Test des Gesamtsystems (Integrations- und Systemtest)
Auslieferung an den Kunden
7. Wartungsphase
(Kosten ca. 67%)
Betrieb beim Kunden
Fehlerbeseitigung
Verbesserung (Effizienz)
Erweiterung
Anpassung
8. Rückzugsphase
Einstellung der Nutzung
Datensicherung/-übertragung
2.2 Grundlegende Prinzipien
Abstraktion und Konkretisierung
Zerlegung / Dekomposition – „Divide et Impera“
Perspektivenbildung / Sichtensystem
Wiederholung und Wiederverwendung
Automatisierung
Iteration und Evolution
4
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
2.3 Prinzip Modularisierung
Zerlegung großer System in kleine und übersichtliche Komponenten bzw. Teile.
Geheimnisprinzip:
Kommunikation nur über eine klar definierte Modulschnittstelle
Import-Schnittstelle: welche Konstrukte werden von außen benutzt
Export-Schnittstelle: worauf kann von außen zugegriffen werden
Zusammensetzung der Module kann ohne Kenntnis ihrer Funktionsweise geschehen
Modul ist für sich alleine testbar.
Modul verbirgt Entscheidungen für seinen inneren Entwurf
Design by Contract
Server mit angebotener Leistung (Post Condition) wird von Client mit den korrekten
Eingaben (Pre Condition) verwendet
Bindungstypen (von niedriger bis hoher Bindung) Optimum: hohe Bindung:
zufällig, logisch, temporal, prozedural, kommunikatorisch, sequentiell, funktional
Modulkopplung (von niedriger bis hoher Kopplung) Optimum: niedrige Kopplung:
Keine direkte K., Datenk., Stempelk., Steuerk., ext. K., Common K., Inhaltsk.
2.4 Bereiche des Software Engineering
5
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
3 Projektmanagement
3.1 Grundlagen
Management:
Planung der Arbeit für die ausführenden Mitarbeiter
Magisches SWE Dreieck:
Zeit – Kosten – Qualität haben gemeinsam Einfluss auf die Produktivität
Produktivität:
Leistung * Qualität / Ressourcen
Meilenstein:
Zeitpunkt im Projekt zur Entscheidung über den weiteren Verlauf (Ist-Soll-Abgleich)
Kritischer Pfad:
Wichtige Tätigkeiten, deren Verzögerung die gesamte Projektdauer verlängert
Projektmanagement:
Koordination der Prozesse in einem Projekt (Planung, Kontrolle & Steuerung)
3.2 Projektaufbau und Rollen
Wichtigste Rolle: Menschen (Psychologie)
Entwickler / Spezialisten
Projekt- oder Gruppenleiter
Kunde oder Anwender
Kontrollgremien
Man unterscheidet bei der Organisationsstruktur des Unternehmens zwischen
Primärorganisation (legt Aufgabenverteilungen und Beziehungen der Mitarbeiter fest)
Sekundärorganisation (meistens für temporäre Phasen: Projekte)
Bei der Form der Organisation gibt es mehrere Typen:
Funktionale Organisation (Abteilungsleiter mit Untergebenen)
Reine Projektorganisation (schwache bzw. keine Primärorganisation)
Matrixorganisation (sowohl gewöhnliche Hierarchie als auch projektbezogene Kleingruppen)
Zum Strukturieren der Kleingruppen bzw. Teams unterscheidet man zwischen:
Kleine Teams / Einzelkämpfer
Anarchische Teams (Zusammenarbeit ohne Hierarchie)
Demokratisches Team (wie anarchisches Team mit einem „Motivator“ der Gruppe)
Hierarchisches Team (Projektleiter plant, verteilt und kontrolliert)
Chief-Programmer-Teams (Projektleiter sind auch technisch aktiv, holen sich aber
Unterstützung von Spezialisten und Assistenten)
3.3 Projektplanung und Darstellung
Jedes Softwareprojekt gliedert sich in drei Projektphasen
Startphase
Ernennung des Projektleiters, der den Projektplan erstellt:
Abgrenzung des Liefer- und Leistungsumfangs
Aufgabenplanung und Ressourcenplanung
Terminplanung und Verteilung von Aufgaben an Mitarbeiter
Risikoplanung
Projektdurchführung
Die Durchführung kann sich in mehrere Phasen gliedern, die wiederum innere
Vorgänge enthalten und durch Meilensteine markiert werden.
Abschlussarbeiten
6
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Es gibt verschiedene Arten, Vorgänge während des Projekts darzustellen
Projektstrukturplan PSP zum Darstellen der geplanten Aufgaben
Projekt wird in Teilaufgaben gegliedert, welche jeweils mit einem eindeutigen Kürzel
versehen wird (z.B. „B“)
Unterbäume sind Aufgabensammlungen und die Blätter sind die eigentlichen Aufgaben
Basis für einen Aufwandsplan – Schätzung des Aufwandes pro Paket
Terminplan als Netzplan (PERT-Chart)
Jeder Kasten enthält den Namen der Aufgabe, die geschätzte Dauer der Bearbeitung
und zwei Zeilen mit relativen Zeitangaben zu dem Start und dem Ende der Aufgabe.
Diese Zeitangaben werden in einer Vorwärts- (ausgehend vom Projektstart) und einer
Rückwärtsrechnung (ausgehend vom Endzeitpunkt des Projekts) ermittelt.
Über den Netzplan kann man zusätzlich noch Pufferzeiten erkennen bzw. Abschnitte,
die wegen Planungsfehlern nicht rechtzeitig fertig werden können (negativer Puffer).
Daneben lässt sich auch ein kritischer Pfad aus dem Plan ablesen (über Aufgaben,
deren Zeiten in beiden Rechnungsrichtungen gleich sind).
7
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Vorgangsliste als Alternative zum Netzplan
Gantt-Chart mit Balkendiagramm zur Übersicht über die zeitlichen Projektphasen
Marken und Meilensteine können zusätzlich noch dargestellt werden.
Zusätzlich sollte man die Arbeitstage in einem Projektkalender verwalten (Feiertage, Schulungen,
Ferien)
Allgemeine Folgenbeziehungen:
Normalfolge (A endet B beginnt)
Endfolge (bevor B beginnen kann, muss A beendet werden)
Sprungfolge (A kann nur dann beendet werden, wenn B bereits angefangen hat)
Anfangsfolge (damit A anfangen kann, muss auch B angefangen worden sein)
3.4 Projektkontrolle und –steuerung
Bei der Projektbetreuung gilt als wichtigstes Ziel: Einhaltung der geplanten Projektdauer. Um dies
während des Projekts zu ermöglichen verwendet man die folgenden Hilfsmittel:
Projekttagebuch mit Besprechungsprotokollen
Aufwandserfassung (Time Sheets)
Berichte (intern oder an Kunden)
8
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Meilenstein-Trendanalyse
Mit der Trendanalyse kann man bereits während des Projekts feststellen, ob das
Projekt rechtzeitig fertig werden kann. Verlaufen die Verbindungen zwischen den
gleichen Meilensteinen parallel zur Winkelhalbierenden durch den Ursprung, dann ist
dies ein Signal für gravierende Probleme in der Entwicklung.
3.5 Brook’sches Gesetz
Aufgrund des steigenden Kommunikationsaufwandes bei der Einstellung weiterer Mitarbeiter, gibt es
einen optimalen Punkt, bei dem die Mitarbeiterzahl genau dem Aufwand des Projekts entspricht:
9
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
3.6 Aufwandsschätzung
Die Aufwandsschätzung folgt der Machbarkeitsstudie. Nachdem die Aufwandsschätzung
durchgeführt wurde und sie ein rentables Projekt ergab wird direkt die Auftragsvergabe folgen. Auf
Basis des Pflichtenheftes in der Auftragsvergabe erfolgt die konkrete Projektplanung.
In der Aufwandsschätzung können folgende Punkte geklärt werden:
Entwicklungskosten für die Erstellung eines Angebots (hier gibt es wiederum die Strategien
auch unrentable Projekte anzugehen, um z.B. Know-How aufzubauen oder die Kundenbindung
zu stärken)
Entscheidungsgrundlage zur Eigenentwicklung oder dem Kauf von Teilprodukten, die für das
Projekt notwendig sind
Wirtschaftlichkeitsberechnungen
Zeit-, Kapazitäts-, Ressourcen- und Personalplanung
Zur Abschätzung des Aufwandes existieren in der Praxis meist zwei Methoden:
Expertenbefragung (Delphi-Methode!)
Algorithmische Schätzverfahren
COCOMO, COCOMO II, Function Points, Use Case Points
Vokabeln
Function Points (FP)
Use Case Points (UCP)
Delphi-Methode bei der Expertenbefragung
(Ansatzarten der Aufwandsschätzung)
CoCoMo
KLOC
SLOC
NCSS
10
funktionale Anforderungen an die Software (was
für Funktionen sind enthalten)
Interaktionsmöglichkeiten und -szenarien mit dem
Benutzer
Es werden Experten unabhängig voneinander und
ohne gegenseitiges Bescheidwissen gefragt um
Seiteneffekte zu vermeiden.
Constructive Cost Model – setzt sich aus dem
geschätzten Codezeilen und einem
Aufwandsfaktor zusammen (Nachteil: sehr grob,
Vorteil: leicht zu errechnete Zahlenwerte)
Kilo Lines of Code
Source Lines of Code
Non-Commentary Source Statements
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
4 Konfigurationsmanagement
4.1 Motive und Begriffe
Das Konfigurationsmanagement hilft dabei den Projektfortschritt und die damit verbundene
Informationsverwaltung in den Griff zu kriegen. So kann der Mitarbeiter die Historie jeder Datei und den
Gesamtumfang des Projekts überblicken. Zudem erleichtert es das gemeinsame Arbeiten in dem
gleichen Datenpaket oder an derselben Datei. Somit erhalten wir als Hauptmotive
Qualität verbessern
Produktivität steigern
Änderungen protokollieren
Transparenz verbessern
4.2 Aufgaben und Verfahren
Versionskontrolle
Konfigurationskontrolle
Build-Automatisierung
Änderungskontrolle
Koordination der Teamarbeit
Ableitung und Bereitstellung von Messverfahren / Metriken
4.3 Konfigurationselemente
Dem KM sind alle anfallenden Projektdateien untergeordnet außer der generierten Dateien
(Javadoc, *.class-Dateien) zu den eigentlichen editierten Dateien (z.B. Quellcode).
4.4 Konfigurationsmanagement Plan
4.5 Projektstruktur
Nach der Erstellung des KM-Plans muss die Projektstruktur festgelegt werden. Hierbei muss man
beachten, dass die Projektstruktur einen starken Einfluss auf die Softwarearchitektur haben kann
und diese einschränken könnte (Conway’s Law 1968).
Das Gesamtprojekt kann also in Teilprojekte gegliedert werden und dort noch mal nach
Konfigurationselementen getrennt unterschieden sein.
11
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
4.6 Verwaltung der Konfigurationselemente
Die gesamte KM-Datenbasis wird im Repository untergebracht. An das Repository müssen folgende
Anforderungen gestellt werden:
Verfügbarkeit
Integrität
Zugriffskontrolle (Rechtemanagement)
Änderungsverfolgung und Wiederherstellung (Überblick über die Versionshistorie)
Effizienz bei großen Datenmengen
Der Ablauf bei der Arbeit mit dem Repository ist schematisch wie folgt:
Daten befinden sich im Rep. Check-Out (Kopieren der Daten in die lokale
Arbeitsumgebung) Modifikation der kopierten Daten / Erstellung neuer Dateien Check-In (lokale Daten werden wieder ins Rep. Kopiert)
Bevor die Dateien wieder zurück ins Repository kopiert werden können, müssen alle vorhanden
Konflikte gelöst werden. Diese Konflikte können nur dann auftreten, wenn die Dateien, die vom
Benutzer nach dem Check-Out verändert wurden, parallel auch von anderen Benutzern an der gleichen
Stelle in der Datei verändert worden sind. Dies kann von vornherein durch z.B. einen Lock-UnlockMechanismus verhindert werden, der die Datei bis zum nächsten Check-In für andere Benutzer sperrt.
Daneben wird ein Projekt in der Praxis gerne in Unterabschnitte unterteilt, die ein vorzeitiges Ausliefern
von z.B. einem Prototypen möglich machen sollen. Dazu definiert man Tags und Baselines, auf die
dann das Release folgt. Hier liegt häufig eine Überschneidung mit den Meilensteinen zugrunde.
Die Projektentwicklung kann auch in mehrere Entwicklungslinien aufgespaltet werden. Hierbei gibt es
drei Möglichkeiten der parallelen Entwicklung:
Code-Freeze und Linearisierung (während des Code-Freeze wird nicht weiterentwickelt,
sondern nur die Software für das Release oder die Baseline vorbereitet)
Verzweigte Entwicklungspfade mit Branches
Echte Parallelentwicklung ohne anschließendes Zusammenfügen (sinnvoll bei z.B.
Betriebssystemen)
12
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
4.7 Release-Management
Versionsbezeichnung für das Release: (Hauptrelease).(Wartungsrelease).(Patch)
z.B. 2.1.0
4.8 Werkzeug zur Versionskontrolle: Subversion
Subversion ist eine Weiterentwicklung von CVS und behebt einige Nachteile von CVS:
Verzeichnisse werden auch versioniert
Check-In geschieht ganz oder gar nicht (atomar)
Client-Server-Architektur
4.9 Automatisierung des Build-Prozesses
Durch den Einsatz von Build-Werkzeugen lässt sich die Produktivität, Widerverwendbarkeit und
Reproduzierbarkeit steigern.
Man unterscheidet zwischen verschiedenen Build-Varianten: Entwickler-, Integrations- (alle
Komponenten zusammen) und Produktions-Build (für den Kunden).
Werkzeuge:
Make (Makefiles schreiben)
Ant (allgemeines plattformunabhängiges Verfahren mit XML)
Maven
13
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Vokabeln
Repository
Datenbank mit allen zum Projekt gehörigen
Dateien
Erweiterung oder Weiterentwicklung einer Datei
Alternative Umsetzung eines ähnlichen
Funktionsumfangs einer Datei
Auswahl von Versionen und Varianten als
Zusammenstellung zu einem Gesamtpaket
Art, wie mit Änderungen an Dateien umgegangen
wird
Ursprungsversion liegt als Ganzes vor und die
anschließenden Änderungen werden mitverfolgt
immer liegt die Endversion als Ganzes vor und die
Änderungen zum Vorgänger werden festgehalten
Markierung für eine Forschrittsstufe im Repository
Zum Trunk parallel verlaufende Entwicklungslinie
Stabile lauffähige Konfiguration (auch als
Bezugspunkt für spätere Versionen)
Konfiguration, die ausgeliefert werden kann
Code wird nur noch debugged und es werden
keine zusätzlichen Funktionalitätserweiterungen
daran vorgenommen
Versionierte Metadaten, beschreiben die
Eigenschaften der erfassten Dateien
„Versionsnummer“ von dem Stand des gesamten
Repository
Enthält alle Änderungen an der Datenstruktur in
dem gesamten Repository
Version
Variante
Konfiguration (SWE)
Deltamechanismus
Vorwärtsdelta
Rückwärtsdelta
Tag (engl.)
Branch
Baseline
Release
Code-Freeze
Properties im Repository
Revision
Change Set
5 Software-Modelle
5.1 Grundlagen und Modelltypen
Arten von Modellierungssprachen:
Algorithmenorientierte Modellierung (z.B. PAP)
Regelbasierete Modellierung (Entscheidungen und Regeln)
Zustandsorientierte Modellierung (Automaten mit Zustandsübergängen, Petri-Netz)
Funktionsorientierte Modellierung (Funktionsbaum, -hierarchie)
Datenflussorientierte Modellierung (Structured Analysis)
Datenstrukturorientierte Modellierung (Entity Relationship Model oder Syntaxdiagramm)
Szenariobasierte Modellierung (Interaktionsdiagramme)
Objektorientierte Modellierung (Klassenstrukturen)
Geschäftsprozessorientierte Modellierung (ARIS – Architektur integrierter
Informationssysteme)
Formale Modellierung (alles algebraisch und logisch beschreiben)
Spezielle Modellierungssprachen (z.B. für Echtzeitsysteme oder für Unternehmen)
14
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
5.2 Programmablaufplan
Geeignet zum Darstellen von
Algorithmen in einem Programm
Folge von Operationen zur Lösung einer Aufgabe
Allgemeinen Prozessen
Bestandteile:
Sequenz von Operationen (verbunden durch
Kontrollflusslinien)
Auswahl und Verzweigung
Schleifen (Verzweigung, die zurück leitet)
Unterprogrammaufrufe
Ein- und Ausgaben
Anfang und Ende
Nachteile:
Datenstrukturen werden nicht modelliert
Für große Systeme ungeeignet.
5.3 Struktogramm
Geeignet zum Darstellen von
Kontrollstrukturen ohne
Programmsprünge
Logikdarstellung sprachunspezifisch
Zerlegung eines Gesamtproblems
Bestandteile:
Anweisung
Sequenz / linearer Ablauf
Aufruf eines Unterprogramms
Auswahl und Verzweigung
Fallunterscheidung (select case)
Schleifen (viele Typen)
Nachteile:
Sprünge können nicht dargestellt werden
Manuell aufwendig zu zeichnen und
ändern
5.4 Funktionsbaum
Geeignet zum Darstellen von
Gliederungen von Funktionen in (allgemeine)
Hauptfunktionen und spezifische Teilfunktionen
Zusammenstellungs- und Aufrufbeziehungen (obere
Funktion ruft auf / besteht aus unteren Funktionen)
Bestandteile:
Hierarchie
Nachteile:
Geben nur groben Überblick über den
Funktionsumfang.
15
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
5.5 Strukturierte Analyse (SA)
Geeignet zum Darstellen von
a) Datenflüssen in einem System
b) Datenlexikon mit einer Struktur der Daten
c) Mini-Spezifikation als Leistungsbeschreibung
einzelner Systemteile
Zerlegungen eines Systems in seine Bestandteile
bis man bei selbsterklärenden Komponenten
angekommen ist.
Bestandteile (eines SA-Modells):
a) Prozesse, Terminatoren, Datenspeicher,
Datenflüsse (alle Objekte mit eindeutigem Namen)
b) Zuweisungen (=), Sequenz (+), Iteration ({…}),
Wiederholung von M bis N (M{…}N), Selektion
([…|…|…]), Option ((…)), Kommentar (*…*)
c) Minispecs sind wenig formalisiert, bis auf
Namensmarkierungen (#Name)
allgemein kann jedes Datenflussdiagramm noch
verfeinert werden, so entstehen dann mehrere
Ebenen (einfache und abgeleitete Konsistenz).
MSP Eis verkaufen
Aufgrund des #Kundenwunsch wird eine
#Tüte mit #Eis zusammengestellt.
5.6 EBNF und Syntaxdiagramm
Geeignet zum Darstellen von
Syntax in Programmiersprachen
Datenstrukturen
Das Datenlexikon bei der SA wird
mit der EBNF gebildet.
Bestandteile:
Terminale und Nicht-terminale
Symbole („Z“ oder A)
Sequenzen (A B)
Alternativen (A | B)
Optionen ([A])
Wiederholungen ({A})
Zu definierendes Symbol („A ::=“)
Gruppierung („(…)“)
16
EBNF:
Syntaxdiagramm:
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
5.7 Entity-Relationship-Modellierung (ERM)
Geeignet zum Darstellen von
Beziehungen zwischen Einheiten
(Entitäten)
Attributen von Entitäten
Vor allem Datenbankstrukturen
Kompletten Systemen durch Menge
aller Entitäten, Attributen und
Beziehungen
Bestandteile:
Entitäten (Rechteck)
Attribute (Ovale)
Beziehungen (Rauten)
Kardinalitäten (1 zu 1, 1 zu n,
n zu m)
Nachteile:
Keine Beschreibung von Funktionen
Vor allem statische Sicht
5.8 Objektorientierte Modellierung mit UML
UML ist eine halbformale, von Programmiersprachen unabhängige und graphische
Modellierungssprache. Sie besteht in UML 2.0 aus 13 verschiedenen Diagrammen und ist trotzdem
kein Ersatz für geschriebenen Text.
Überblick:
17
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Klassendiagramm
Objektdiagramm
Sequenzdiagramm
Zustandsdiagramm
18
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Kommunikationsdiagramm
Anwendungsfalldiagramm
Paketdiagramm
Verteilungsdiagramm
Komponentendiagramm
Aktivitätsdiagramm
19
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Gesamtüberblick über die Anwendungsfälle der Diagramme
5.9 Geschäftsprozessmodellierung mit ARIS
Mit ARIS kann ein gesamtes System modelliert werden und anschließend auch überprüft werden, ob
das System den Anforderungen genügt. Dazu beschreibt man das Informationssystem in fünf
verschiedenen Sichten:
Funktionssicht: Vorgänge und Tätigkeiten, die Leistungen transformieren (Funktionsbaum)
Organisationssicht: alle Organisationseinheiten und ihre Beziehungen (Organigramm)
Datensicht: Ereignisse, die Daten generieren (Entity-Relationship-Modell)
Leistungssicht: Dienst-, Sach- und finanziellen Leistungen (Produktbaum)
Steuerungssicht: Verknüpfung der anderen Sichten (EPKs)
Diese Sichten lassen sich durch das ARIS-Haus visualisieren:
20
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Bestandteile von ARIS Modellen:
Beispieldiagramm mit mehreren Sichten:
5.10 Formale Modellierung mit Petri-Netzen
Die Petri-Netze basieren auf einem vollständigen Formalismus und sind somit
mathematisch exakt beschreibbar. Sie lassen sich zur Modellierung von
nebenläufigen Systemen verwenden.
Bestandteile:
Stelle bzw. Platz (als Kreis mit evtl. Markierung)
Übergang bzw. Transition (Rechteck); falls in den vorherigen Stellen
Markierungen sind, kann die Transition geschaltet werden, sodass die
nachfolgenden Stellen eine Markierung dazubekommen
Datenfluss (als Pfeil mit Beschriftung)
21
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
6 Softwareprozesse und Vorgehensmodelle
6.1 Softwareentwicklung in Phasen
Motivation hinter der Entwicklung in Phasen ist vor allem die bessere Planungsmöglichkeit und
Kalkulierbarkeit von Aufwand. Es gibt dabei drei große Schwierigkeiten:
Abgrenzungsproblem (Phasen sind in der Realität nicht scharf trennbar)
Abfolgeproblem (Sequentielle Anordnung der einzelnen Phasen)
Angemessenheitsproblem (ist das Modell dem Projekt angemessen)
Ein Großteil aller Entwicklungsprozesse besteht aus den folgenden 5 Phasen:
Anforderungsanalyse (Requirements Analysis)
Entwurf (Design)
Implementierung (Implementation)
Wartung und Betrieb (Maintainance)
Außerbetriebsetzung (Retirement)
6.2 Unsystematische „Modelle“
Code-and-Fix Modell
Ohne Design und Spezifikation wird losprogrammiert und das Programm soweit an die
Wünsche des Kunden angepasst, bis er zufrieden ist. Diese Vorgehensweise eignet
sich vor allem für kleinere (einmalige) Programmierarbeiten, da man so schnell und
intuitiv zu Resultaten kommt. Allerdings wird ein so programmiertes Produkt ab einem
gewissen Umfang zu einem „Wartungs-Albtraum“.
6.3 Lineare / Sequentielle Modelle
Wasserfallmodell:
Vorteile:
Einzelne Phasen
können vorausschauend
geplant werden.
Nachteile:
Einführung des Systems
auf einen Schlag („Big
Bang“).
Zu starres Konzept bei
unvorhergesehenen
Ereignissen.
Frühe Festlegung auf
Systemeigenschaften
muss perfekt sein, damit
später keine Konflikte
entstehen
22
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
V-Modell:
Vorteile:
Die Tests werden
zusätzlich betont.
Großes Regelwerk
eignet sich vor allem für
Behörden.
Nachteile:
Sprünge zwischen
Phasen nicht
vorgesehen.
Keine Einbeziehung von
Kunden-Feedback.
6.4 Frühe Prototypen / Rapid Prototyping
Vorteile:
Durch den Prototyp
kann früh Erfahrung mit
den gesamten
Anforderungen
gesammelt werden. Die
Entwicklungszeit nimmt
insgesamt ab.
Vertikale Prototypen: Hier wird die gesamte Abstraktionshierarchie (Pfeil
Anwender-Hardware) und der Funktionsumfang (f1 bis fn) stufenweise
implementiert. Daneben existiert noch das Modell der Horizontalen Prototypen.
Nachteile:
Weiterhin keine Sprünge
möglich und Big Bang.
Achtung: Durch den frühen Prototypen kann beim Auftraggeber zusätzlich der Eindruck entstehen,
dass der Aufwand für das ganze Projekt gar nicht so groß ist, wie angenommen.
6.5 Evolutionäre, inkrementelle Modelle
Software wird hierbei in einem Wachstumsprozess erstellt. Dabei durchläuft sie stets die drei
aufeinanderfolgenden Phasen:
Prototyp (einsetzbares kleines Testsystem zum Überprüfen der Benutzeranforderungen).
Erweiterung (füge Funktionalität hinzu und korrigiere Mängel).
Konsolidierung (Entwurfsfehler werden erkannt und beseitigt, neue Abstraktionen eingeführt)
Durch diese Vorgehensweise gibt es keine plötzliche Einführung eines Systems und damit keinen Big
Bang. Insgesamt ist man schneller bei größeren Projekten, als mit dem reinen Wasserfallmodell.
23
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Spiralmodell:
Vorteile:
Der Big Bang Effekt
kann verhindert werden.
Bessere Umsetzung der
Anforderungen.
Durch Iterationen kann
gut gesprungen werden.
Nachteile:
Organisatorischer
Aufwand bei der
Planung der Iteration
steigt.
Gesamte Projektdauer
nicht mehr genau
einschätzbar.
6.6 Objektorientierte Modelle
Baseball Modell
Zwischen den einzelnen Teilgebieten (OOA, OOD und OOP) kann beliebig gewechselt
werden, aber jeder im (kleinen) Spezialistenteam hat eine bestimmte Fachrichtung. In
enger Zusammenarbeit wird das System objektorientiert entwickelt.
Macro Process
Gesamtüberblick:
24
Unterprozesse je Phase:
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Unified (Software Development) Process (UP)
Begriffe: Worker (hat Aufgaben, Verantwortlichkeiten und Fähigkeiten), Aktivität (wird
einem Worker zugewiesen) und Artefakt (explizite Information, die von einem Worker
bei einer Aktivität erstellt wird)
6.7 Microsoft Vorgehen
Microsoft erstellt unter Berücksichtigung der Wünsche eines großen Kundenkreises Software mit sehr
großem Funktionsumfang, der in den seltensten Einsatzfällen tatsächlich komplett benutzt wird.
Kernelemente bei der Entwicklung von Software im Unternehmen Microsoft sind/waren:
Flache Hierarchien (kleine Entwicklerteams stehen gleich großen Gruppen von Testern
gegenüber). Jeder Entwickler trägt eine Gesamtverantwortung.
Mind. 2 Mal pro Woche wird eine lauffähige Version erstellt (Gefühl, dass Projekt vorankommt).
Psychosoziale Schikanen wie das Motivieren der Arbeiter durch Aussondern von Losern.
6.8 Agile Modelle
Weitere Modelle weisen ähnliche Prinzipien vor:
Versuch Kompromiss zwischen steifem Vorgehenskonzept und der wilden DrauflosProgrammierung zu finden.
Die Vorgehensweise muss dem Projektumfang entsprechen (Abwägen zwischen
Vorhersagbarkeit, Anpassbarkeit und schneller Umsetzung).
Entwicklungsstil basiert auf einem Wertegefühl:
Individuen
> Prozesse und Werkzeuge („geht vor“-Beziehung)
Lauffähige Software
> Dokumentation
Kundenzufriedenheit
> Vertragsverhandlung
Auf Änderungen reagieren
> Verfolgen eines Plans
Inkrementelle Arbeitsabläufe und Auslieferung der Systeme
Kurze Iterationen fixer Länge („time-boxed“) mit parallelen Aktivitäten
Zahlreiche Beispiele für konkrete agile Prozesse:
Adaptative Sw. Dev.. (ASD 2000), Feature Driven Dev.. (FDD 1999), Crystal Methoden
(2001), Dynamic Sw. Dev. Method (DSDM), Rapid Appl. Dev. (RAD), Scrum, Xtreme
Programming (XP 1998), Agile Unify Process (AUP), Lean Dev. (LSD 2001)
Agile Prozesse am Beispiel des eXtreme Programming:
Zentrales Prinzip: wir treiben jede praktische Technik bis zum Extremum
Sehr kurze Iterationen (1 bis 4 Wochen)
Es wird vor allem programmiert und technisch herangegangen.
25
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Das meiste wird direkt in Code umgesetzt und nur wenige Artefakte produziert.
Vier Kernwerte: Einfachheit, Mut, Kommunikation und Kundenrückmeldung
15 Prinzipien: z.B. sofortiges Feedback, Veränderung wollen, Qualitätsarbeit, Lernen lehren,
geringe Anfangsinvestitionen, arbeite auf den Sieg hin, gezielte Experimente, offene
Kommunikation, nutze Instinkte des Teams, übernehme Verantwortung, Anpassung an lokale
Umstände, reise mit leichtem Gepäck, Messungen ehrlich durchführen.
13 weitere zu einander in Beziehung stehende Praktiken
Zu Beginn eines Projekts werden die Anforderungen des Kunden („stories“) notiert und
anschließend wird der Aufwand jeder Story geschätzt, ein Plan erstellt, wann und wo die stories
implementiert werden und Testfälle für sie definiert.
6.9 Weitere Phasenmodelle
Da es noch viele weitere Phasenmodelle gibt, wird hier noch aufgeführt, durch welche Kriterien man
sich für ein bestimmtes entscheiden sollte:
Größe und Kultur des Unternehmens
Management
Fähigkeiten der Angestellten
Projekt und die Natur des Produkts
Deswegen wird in der Realität oft eine Mischung („mix-and-match“) oder Beschränkung („Tailoring“)
einzelner Modelle gebraucht.
6.10 Fokus: Analysephase, Requirements Engineering
Das Requirements Engineering beschäftigt sich mit der systematischen, ingenieursmäßigen
Entwicklung einer Anforderungsdefinition, welche die Leistungen eines Systems vollständig und
eindeutig beschreibt.
Als Ergebnis wird (unter Zuhilfenahme des Lastenhefts) ein Pflichtenheft oder eine Produktdefinition
erstellt. Darin werdn neben der genauen Funktionsbeschreibung des Programms noch Anforderungen
an die Dokumentation, Richtlinien und physikalische Betriebsbedingungen festgelegt.
Verfahren: Noun Approach (Extrahieren von Nomen aus einem Beschreibungstext als
Kandidaten für Klassen im System)
Verfahren: textuelle Beschreibung von Use-Cases (Festlegung von: Name des Falls,
Akteure, Beschreibung, Startereignis, Ausnahmen & Fehler)
26
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
6.11 Fokus: Entwurfsphase
Zunächst muss man eine Anforderungsbeschreibung vorliegen haben. Mit dieser kann man dann
schrittweise Entwurfsentscheidungen treffen (design decisions).
Bei dem Entwurf bedient man sich geläufiger Entwurfsmuster (design patterns). Dabei beschreibt ein
Muster:
Ein wiederkehrendes Problem
Kontext des auftretenden Problems
Kern der Lösung des Problems (in vielen Variationen anwendbar)
Die Struktur einer Musterbeschreibung:
Name
Problem: Beispiel, Motivation, Kontext, Anwendungsbereich
Einschränkungen
Lösung: Struktur, Implementierung (Code), Konsequenzen (Vor- und Nachteile)
Varianten
Verwandte Muster
7 Qualität
7.1 Einordnung und Begriff
„Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die
sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen.“
7.2 Qualitätseigenschaften
Mit Metriken versucht man die Qualität zu messen und messbar zu machen.
27
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
7.3 Wege zur Qualität
Qualitätssicherung (QS): Summe der Maßnahmen für die Gewährleistung der Qualität
Qualitätsmanagement (QM): organisatorische Maßnahmen zur Erreichung/Nachweis einer
hohen Qualität
7.4 Qualität und Softwareentwicklung
Erfahrung mit Fehlern bei der Qualitätsbestimmung:
28
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
Quellennachweis:
Folien zur Vorlesung „Software Engineering“ von Jun. Prof. Dr.-Ing. Elke Pulvermüller an
der Universität Osnabrück
UML Cheat Sheets: Lou Franco, Laurent Grégoire, oose Innovative Informatik GmbH
(www.oose.de)
Wikipedia
29
Zusammengestellt in 2010 - Sharing welcome! – wladislaw.gusew.de
© Copyright 2024 ExpyDoc
