4(4)h DI Klaus Battlogg DI Diethard Kaufmann

Transkript

1 3 Software Entwicklungsprozesse 3.1 Wasserfallmodell 3.2 RUP (Rational Unified Process) 3.3 SCRUM 3.4 XP PPM1 4ai Schuljahr 2007/2008 4(4)h DI Klaus Battlogg DI Diethard Kaufmann

2 3 Software Entwicklungsprozesse Ziele von Software Engineering (SE): Software Systeme in ökonomischer Art und Weise zu erstellen, welche bestimmten Qualitätsanforderungen genügen. Qualitativ hochwertige Software in kurzer Zeit entwickeln Effizienz!

3 3 Software Entwicklungsprozesse Qualitätsanforderungen: Korrektheit: Die Software realisiert genau die Funktionen, die in den Anforderungen und ihren Spezifikationen festgelegt sind. Alle zulässigen Eingaben führen zu dem korrekten Ergebnis. Robustheit: Die Software gelangt in einen definierten Zustand, falls Situationen auftreten, die nicht in den Anforderungen bzw. Spezifikationen festgelegt sind. Nicht zulässige Eingaben werden vernünftig bearbeitet; kein Absturz des Systems o.ä. Ausfallsicherheit: Das Software System gelangt in einen definierten Zustand auch dann, wenn zugrunde liegende Systeme wie Hardware, Peripherie Geräte usw. ausfallen oder fehlerhaft arbeiten. Zuverlässigkeit: Korrektheit + Robustheit + Ausfallsicherheit

4 3 Software Entwicklungsprozesse Qualitätsanforderungen: Erweiterbarkeit und Anpassbarkeit: Die Software erlaubt Erweiterungen und Anpassungen an sich ändernde Anforderungen und Spezifikationen. Änderungen einzelner Funktionen bleiben lokal in ihren Auswirkungen; das globale Verhalten bleibt unverändert. Wiederverwendbarkeit: Ergebnisse, die bei der Software Entwicklung für eine Aufgabenstellung erzielt worden sind, können bei anderen Aufgabenstellungen nutzbringend wiederverwendet werden (z.b. Patterns, Module, Bibliotheken, Objekte..)

5 3 Software Entwicklungsprozesse Qualitätsanforderungen: Kompatibilität: Das Software System kann leicht mit anderen kombiniert werden; es kann ggf. in andere Systeme integriert werden. Portabilität: Der Aufwand, um Software auf einer anderen Hardware bzw. in einer anderen Software Umgebung (z.b. Betriebssystem) zu installieren ist gering. Java : ) Benutzerfreundlichkeit: Die Software ist mit vertretbarem Aufwand zu benutzen (Anwendung, Installation, Wartung, Konfiguration usw.) Effizienz: Bezeichnet den Umfang an Ressourcenverbrauch: Prozessorzeit Hauptspeicher Festplattenspeicher

6 3 Software Entwicklungsprozesse Fehleraufteilung in Software Projekten

7 3 Software Entwicklungsprozesse Definition: Software Entwicklungsprozess (SEP) UML ist eine Methodik, aber kein Prozess! Als SEP bezeichnet man die Erstellung von Software (bzw. eines Software Systems) von der ersten Idee über die fertige Software bis hin zu ihrer Auslieferung, Erweiterung und Wartung ggf. schon existierender Software. z.b. RUP (Rational Unified Process)

8 3 Software Entwicklungsprozesse Kennzeichen eines Prozesses: jeder Prozess hat ein Anfang und ein Ende ( sind vorgegeben!) Ergebnisse Ziele Eigentümer Rolle Kunde Auftraggeber Projektleiter (fachlich, technisch) Entwickler Designer Tester

9 3 Software Entwicklungsprozesse Ein Prozess besteht aus Tätigkeiten Incl. Verantwortliche, Mitarbeiter, Hinweise, Material, Dokumente... Entscheidungen Mit Ein und Ausgängen Schnittstellen Zu Prozessen, Abteilungen etc. Unterprozesse Diese sind selbst Prozesse Verbindungen zwischen diesen Elementen Legen die Reihenfolge fest

10 3 Software Entwicklungsprozesse Prozessvisualisierung z.b.: UML Aktivitätendiagramm EPK (ereignisgesteuerte Prozessketten)

11 3 Software Entwicklungsprozesse UML Aktivitätendiagramm Beispiel: Abwicklung Banküberweisung [ hb ol.de/uta/gi rg/uml.pdf]

12 3 Software Entwicklungsprozesse EPK Beispiel: Abwicklung Versandauftrag [ stuttgart.de/links_download/dl_de/vorlesung/skripte/qualitaetsmanagement/vl3_prozessvisualisierung_folie.pdf]

13 3 Software Entwicklungsprozesse Phasen des Software Entwicklungsprozesses: Der Software Entwicklungsprozess wird in einzelne Phasen gegliedert. Ein Prozessmodell beschreibt einen Rahmen für den Software Entwicklungsprozess. Es legt fest: Reihenfolge der Phasen Durchzuführende Aktivitäten Endprodukte jeder Phase Verantwortlichkeiten und Kompetenzen Anzuwendende Standards, Richtlinien, Methoden und Werkzeuge

14 3 Software Entwicklungsprozesse Dokumente / Artefakte in einem SEP Definition Ein Artefakt ist ein Stück Information,, das erzeugt, manipuliert oder genutzt wird. Beispiele Use Case DG Pflichtenheft Benutzer Dokumentation Online Hilfe Source Code Executeables

15 3 Software Entwicklungsprozesse Dokumente / Artefakte im SEP Wasserfallmodell : Initialisierung & Planungsphase Business Plan Lastenheft (=grobes Pflichtenheft; was & wofür? ) Projektplan (Milestones) Analyse & Definitionsphase Detailspezifikation / Fachkonzept / Pflichtenheft Entwurfsphase UML Diagramme (Klassendiagramm, Use Case DG )

16 3 Software Entwicklungsprozesse Dokumente / Artefakte im SEP Wasserfallmodell Realisierungs/Implementierungsphase Quellprogramm + Dokumentation Test Drehbuch Einführungsphase Abnahmeprotokoll Benutzerdokumentation Nutzung/Wartungsphase Bug Tracking Protokolle Bugfixes / Patches 2.2

17 3 Software Entwicklungsprozesse SEP Modelle (Auszug): 3.1 Wasserfallmodell Modell, bei welchem man immer nach vorne entwickelt; zum Schluss bekommt der Kunde das fertige Produkt (welches aber nicht genau seinen Forderungen entspricht) da es keine Rückkopplung gibt (weil z.b. nicht mehr mit dem Kunden gesprochen wird) ist es ein gefährliches Modell, da man dem Kunden das Falsche liefert 3.2 RUP (Rational Unified Process) Hier werden Rückkopplungen eingebaut (Iterationen) Verwendung von Rollen Herkunft von der Firma Rational

18 3 Software Entwicklungsprozesse SEP Modelle: 3.3 SCRUM Scrum (engl. das Gedränge) ) ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung. Es ist ein Vorgehensmodell, das wenige Festlegungen trifft. Teams bzw. Entwickler organisieren sich weitgehend selbst und wählen auch die eingesetzten Methoden. Das Vorgehen und die Methoden werden fortlaufend aktuellen Erfordernissen angepasst. 3.4 XP (extreme Programming) es wird immer in kleinen Teams programmiert (weniger Fehler); Testprogrammierung! Programmierung wird in kleine Einzelteile unterteilt, es wird paarweise programmiert (Pairprogramming)

19 3.1 Wasserfallmodell SEP Wasserfallmodell Das Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell in der Softwareentwicklung Derr Softwareentwicklungsprozess ist in Phasen organisiert (vgl.:( Projektstrukturplan PSP) Die Phasenergebnisse gehen wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefer liegende Phase ein. [

20 Wasserfallmodell 3.1 Wasserfallmodell Im Wasserfallmodell hat jede Phase vordefinierte Start und Endpunkte mit eindeutig definierten Ergebnissen. In Meilensteinsitzungen am jeweiligen Phasenende werden die Ergebnisdokumente verabschiedet. Zu den wichtigsten Dokumenten zählen dabei das Lastenheft sowie das Pflichtenheft. Es gibt viele Varianten des reinen Modells und ist das traditionell am weitesten verbreitete Vorgehensmodell. Der Name Wasserfall kommt von der häufig gewählten grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen.

21 Wasserfallmodell 3.1 Wasserfallmodell Erweiterungen des einfachen Modells (Wasserfallmodell mit Rücksprung) führen iterative Aspekte ein und erlauben ein schrittweises Aufwärtslaufen der Kaskade, sofern in der aktuellen Phase etwas schieflaufen sollte, um den Fehler auf der nächsthöheren Stufe beheben zu können.

22 Wasserfallmodell 3.1 Wasserfallmodell 1. Initialisierung & Planung (mit Erstellung des Lastenhefts, Projektkalkulation und Projektplan) (engl. Systems Engineering) 2. Analyse & Definition (mit Erstellung des Pflichtenhefts, Produktmodell, GUI Modell und evtl. schon Benutzerhandbuch) (engl. Analysis) 3. Entwurf (UML, Struktogramme) (engl. Design) 4. Realisierung/Implementierung (engl. Coding) 5. Testen (engl. Testing) 6. Einsatz und Wartung (engl. Maintenance)

23 3.1 Wasserfallmodell Prozessablauf / Rollen & Aktivitäten im Detail

24 Vorteile 3.1 Wasserfallmodell klare Trennung mit Meilensteinen vereinfacht Projektplanung Kosten und Personalzuordnung möglich Umfassender Vorgehensplan Nachteile Abgrenzung der Phasen ist schwierig Phasen sind nicht streng sequentiell Ergebnis einer Phase ist selten fehlerfrei Fehler fallen nicht schon in der nächsten Phase auf: Erfordern in späteren Phasen erheblichen Aufwand Man muss ggf. in frühere Phasen zurückkehren

25 3.2 RUP (Rational Unified Process) Typische Problem Symptome bei SEP Ungenügendes Verständnis der Anforderungen von Anwendern Ungeeigneter Umgang mit neuen oder sich ändernden Anforderungen Softwareteile, die nicht zusammen passen Software, die schwer zu pflegen ist oder kaum weiter entwickelt werden kann Späte Entdeckung von schwerwiegenden Fehlern Schlechte Softwarequalität Unzureichende Leistungsfähigkeit (Performance) der Software Sich gegenseitig behindernde Projektmitarbeiter Unzuverlässige Build Prozesse und Release Prozesse

26 3.2 RUP (Rational Unified Process) Ursachen dieser Symptome Ungeplante (ad hoc) Verwaltung von Anforderungen. Mehrdeutige und unpräzise Kommunikation. Instabile Softwarearchitekturen. Ausufernde Komplexität der Software. Versteckte Inkonsistenzen zwischen Anforderungen, Entwürfen und Implementierungen. Unzureichende Tests. Subjektive Einschätzung des Projektzustands. Unzureichender Umgang mit Risiken. Unkontrollierte Softwareänderungen. Unzureichende Automatisierung.

27 3.2 RUP (Rational Unified Process) Unified Process definiert best practice 1. Entwickle Software iterativ. 2. Verwalte (engl. manage) Anforderungen (engl. requirements) 3. Verwende komponentenbasierte Softwarearchitekturen. 4. Modelliere Software visuell. 5. Prüfe Software kontinuierlich. 6. Ändere Software kontrolliert.

28 3.2 RUP (Rational Unified Process) 4 Grundprinzipien des RUP Use Case driven Use Cases steuern die Softwareentwicklung Architecture Centric Die Architektur des Systems (und seiner Subsysteme) stehen geminsam mit den Use Cases im Mittelpunkt. Iterative Incremental [

29 3.2 RUP (Rational Unified Process) Phasen / 2 D Darstellung Statische Dimension: Gliederung von Aktivitäten nach dem Inhalt. Zeigt logische und zweckdienliche Zusammenhänge zwischen Aktivitäten, Rollen Artifakten. Diese Zusammenhänge gelten weitgehend unabhängig von der konkreten Entwicklung eines Produkt Lebenszyklusses und sind insofern statisch. Dynamische Dimension: Gliederung von Aktivitäten nach der Zeit. Zeigt die schrittweise Entwicklung des Produkt Lebenszyklusses in Form von projekttypischen, situationsbedingten und insofern dynamischen Verläufen von Iterationen und Zyklen.

30 3.2 RUP (Rational Unified Process)

31 3.2 RUP (Rational Unified Process) Dynamische Dimension repräsentiert den Lebenszyklus in dem der Prozess verläuft teilt sich in vier Phasen auf, die mehrfach iterativ durchlaufen werden: Inception (Konzeption) Elaboration (Entwurf) Construction (Konstruktion) Transition (Übergang)

32 3.2 RUP (Rational Unified Process) Phasen im Detail Inception (Konzeption) = Ideenphase: Produktziele und Umfang, Anforderungen verstehen, Projektbudget Elaboration (Entwurf) = Ausarbeitungsphase: Anforderungen im Detail, Architektur entwickeln, Kenntnisse über Techniken und Werkzeuge vertiefen Construction (Konstruktion) = Konstruktionsphase: Von Prototypen ausgehend ein lauffähiges Produkt entwickeln Transition (Übergang) = Übergangsphase: Produktqualität an gesteckte Ziele anpassen, Produktfähigkeiten anpassen, Anwender einführen finale Produktversion erstellen und ausliefern

33 3.2 RUP (Rational Unified Process) Zyklen Die genannten Phasen bilden einen Entwicklungszyklus (I E C T( I E C T) ) und führen zu einer neuen Generation (Version, u. U. auch Variante) eines Softwareprodukts. Iterationen Zur Verringerung von Risiken werden pro Zyklus lediglich ein Teil der Anforderungen bearbeitet (I), die dazu notwendigen Entwürfe erstellt (E), implementiert und getestet (C) und dem Auftraggeber übergeben (T).

34 3.2 RUP (Rational Unified Process) Iterationen Jede Iteration folgt einem Muster ähnlich dem des Wasserfall Modells mit den Besonderheiten, dass sich die Workflows (z. B. Anforderungsanalyse, Design und Implementierung) überlagern und die Aktivitätsschwerpunkte von Phase zu Phase und von Iteration zu Iteration verschieben.

35 3.2 RUP (Rational Unified Process) Meilensteine Meilensteine sind Punkte am Ende von Phasen, an denen anhand von Evaluationskriterien Entschieden wird über die Weiterführung, die Änderung oder den Abbruch eines Prozesses.

36 3.2 RUP (Rational Unified Process) Meilensteine LO (Lifecycle Objective) Produktinteressenten haben Übereinkunft erzielt über allgemeine und hauptsächliche Anforderungen, Ressourceplan ist plausibel, Architekturprototyp deckt kritische Bereiche ab. LA (Lifecycle Architecture) Produktvision ist stabil, Architektur ist stabil, Plan für die Konstruktionsphase ist plausibel nachvollziehbar, der aktuelle Ressourcenverbrauch ist gegenüber dem geplanten vertretbar.

37 3.2 RUP (Rational Unified Process) Meilensteine OC (Initial Operational Capability) Produkt ist reif und stabil genug für ein Beta Release, der aktuelle Ressourcenverbrauch ist gegenüber dem geplanten vertretbar. PR (Product Release) Benutzer sind mit dem Produkt zufrieden, der aktuelle Ressourcenverbrauch ist gegenüber dem geplanten vertretbar.

38 3.2 RUP (Rational Unified Process) Statische Dimension Die "Statische Dimension" wird durch die logische Gruppierung zusammengehöriger Kernprozesse charakterisiert. Der Rational Unified Process beschreibt, wie auch andere Vorgehensmodelle, wer wann wie etwas zu erledigen hat. In diesem Zusammenhang spielen Begriffe, wie Aktivitäten, Artefakte und Worker eine Rolle.

39 3.2 RUP (Rational Unified Process) Aktivitäten, Artefakte und Rollen(Worker)

40 3.2 RUP (Rational Unified Process) Rollen Unter dem Begriff Worker versteht man eine Rolle. Diese Rolle schreibt einem Einzelnen oder einer Gruppe von Personen vor, wie sie diese Rolle ausführen soll. Eine Person kann dabei mehreren Rollen in einem Prozess zugeordnet sein. Aktivität Der Begriff der Aktivität beschreibt einen Teil einer Aufgabe, die ein Worker zu erledigen hat. Aktivitäten erzeugen neue Informationen oder manipulieren schon bestehende Informationen.

41 3.2 RUP (Rational Unified Process) Artefakte Als Artefakte werden im Rational Unified Process Teile einer Information bzw. die Information selbst bezeichnet. Artefakte sind sowohl der Input für einen Worker als auch dessen Output. Workflow (Arbeitsablauf) Als Workflow (Arbeitsablauf) wird im Rational Unified Process eine Abfolge von Aktivitäten bezeichnet. Workflows koordinieren Worker und deren Aktivitäten anhand der Produkte.

42 3.2 RUP (Rational Unified Process) Prozesse / Workflows im RUP

43 3.2 RUP (Rational Unified Process) Kernprozesse im RUP Business Modeling Requirements Analysis & Design Implementation Test Deployment

44 3.2 RUP (Rational Unified Process) Kernunterstützungs Prozesse im RUP Environment Configuration & Change Management Project Management

45 3.2 RUP (Rational Unified Process) Aktivitäten diagramme z.b. Requirements

46 Engl.: das Gedränge SCRUM

47 Motivation: : ( Klassische Methoden 3.3 SCRUM Grosser Aufwand in der Planungsphase nötig Anpassung mit großen Aufwand > schlechte Umsetzungsperformance bei schnell änderndem Umfeld Mitarbeiter als Produktionsfaktor : ) Agile Methoden Inkrementelles Arbeiten in sehr kurzen Zyklen Ständige Anpassung an neue Anforderungen Besondere Berücksichtigung der menschlichen Komponente

48 Geschichte: 3.3 SCRUM Scrum entstand durch vereinte Bemühungen von Advanced Development Methods [ADM] und VMARK Software (VMARK) wollte ADM die internen Entwicklungsprozesse optimieren Die meisten der Entwicklungsmethoden gehen davon aus, dass Software in wiederholbaren, klar definierten und vorhersagbaren Prozessen entsteht. Software Entwicklungsprozesse sind jedoch meist nicht vorhersagbar und nicht wiederholbar Hauptsächlich handelte es sich dabei um Jeff Sutherland (VMARK) und Ken Schwaber (ADM), welche gemeinschaftlich Scrum entwickelten

49 Beschreibung 3.3 SCRUM Scrum ist ein iterativer Prozess zur Entwicklung von Software in einem chaotischen, sich schnell ändernden Umfeld. Dabei besteht Scrum aus einer Serie von 30 Tage dauernden Iterationen, den sogenannten Sprints. Nach jedem Sprint liegt das Produkt in einer neuen, lauffähigen Version vor, welche dem Kunden ausgeliefert werden könnte. Zwischen zwei Sprints werden die Fortschritte, welche im letzten Sprint gemacht wurden, durch Management und Kunden überprüft und daraufhin bei Bedarf die Anforderungen an das Produkt neu gesetzt. Daraufhin kann der nächste Sprint gestartet werden.

50 Prozessablauf 3.3 SCRUM

51 Sprint Verlauf Beispiel: 3.3 SCRUM

52 3.4 extreme Programming (XP) Eckdaten: publiziert von Kent Beck bekanntestes agiles Vorgehensmodell XP wird extrem genannt, da es viele bekannte und erprobte Praktiken in extremem Umfang betreibt. Wenn beispielsweise Code Reviews gut sind, dann soll man es permanent einsetzen [

53 3.4 extreme Programming (XP) Eckdaten: ist ein flexibles Vorgehensmodell in der Softwaretechnik Anwendung von wiederholten kleinen Schritten Verwendung von Rückkoppelungen kommunikationsintensive Herangehensweise agil, iterativ und inkrementell

54 3.4 extreme Programming (XP) Eckdaten: Basiert auf best practises Strukturiertes Vorgehen (kein Chaos!) Bejaht Ungewissheit, mit der SE verbunden ist Teamarbeit steht im Vordergrund (Pairprogramming) Geht davon aus, dass sich Anforderungen & Prioritäten während Projekt ändern & weiterentwickeln Kunde wird aktiv beteiligt

55 3.4 extreme Programming (XP) XP Lebenszyklus: Angefangen mit einer ersten kleinen Version der Software vergrößert sich der Entwicklungsrahmen ständig. Neue Funktionalität wird permanent entwickelt, integriert und getestet. Um zu der zu entwickelnden Funktionalität zu gelangen, werden gewöhnlich jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (Prototyping) und ein Akzeptanztest durchgeführt.

56 3.4 extreme Programming (XP)

57 3.4 extreme Programming (XP) Zusammenfassung: Ein Softwaresystem wird iterativ und evolutionär in kleinen Schritten entwickelt und fortlaufend getestet. Anforderungen werden für jedes Release neu aufgenommen das Design wird von Release zu Release über Refactoring verbessert. Jedes Release ist ein jeweils lauffähiges, nutzbares Softwaresystem, das vom Kunden abgenommen wird.