Chapter Learning Goals

Größe: px

Ab Seite anzeigen:

Download "Chapter Learning Goals"

Helmuth Kramer
vor 8 Jahren
Abrufe

1 Process Identify corporate practices - assess capability - specify standards - e.g. CMM level Plan project Plan configuration management - how to manage documents & code - document: SCMP next chapter: Plan development process Plan quality assurance - how to ensure quality - document: SQAP Plan verification & validation - verify the product satisfies requirements - validate each phase by showing it succeeded document: SVVP Analyze requirements Design Development phases Integrate & test system Maintain Implement Test units Martin Jud Software-Engineering - Prozess 1 Chapter Learning Goals Distinguish among development processes Indicate benefits and disadvantages Understand documentation needed Approximately one for each waterfall phase Plan for configuration management Define Software Quality quantitatively Institute collection Martin Jud Software-Engineering - Prozess 2

document: SQAP Plan verification & validation - verify the product satisfies requirements - validate each phase by showing it succeeded document: SVVP Analyze requirements Design Development phases

2 Some Application Types Stand-alone residing on a single computer / not connected to other SW or HW e.g., word processor Embedded part of unique application involving hardware e.g., automobile controller Realtime functions must execute within small time limit (typically µs) e.g., radar software Network consist of parts interacting across a network e.g., web-based video game Martin Jud Software-Engineering - Prozess 3 Typical Project Roadmap 1. Understand nature & scope of proposed product 2. Select the development process, and create a plan -- section 4 and chapter 2 3. Gather requirements -- chapters 3 and 4 4. Design and build the product -- chapters 5, 6, and 7 5. Test the product -- chapters 8 and 9 6. Deliver and maintain the product -- chapter 10 Martin Jud Software-Engineering - Prozess 4

Understand nature & scope of proposed product 2. Select the development process, and create a plan -- section 4 and chapter 2 3. Gather requirements -- chapters 3 and 4 4.

3 Was man erwarten darf Used for process development Influenced by people 1. Messbare Qualitätsziele festlegen 2. Informationen über den Prozess beschaffen 3. Arbeitsresultate offen legen 4. - Entwurf folgt Anforderungen - Programm folgt Entwurf - Test erfolgt gegen Anforderungen und Entwurf 5. Qualität messen Part of the project Aspect of the product Martin Jud Software-Engineering - Prozess 5 Entwicklungsprozess Ein Prozess beschreibt, wer was wie wann macht. Der Unified Software Development Process (USDP) stützt sich dabei auf vier Modeling Elements: Workers "wer" Activities "wie" Workflows "wann Artifacts "was" Document Artifacts: Model -- a view of the application (design etc.) Component -- physical (source code etc.) Martin Jud IntroductionSoftware-Engineering - Prozess 6 Adaptiert von den Software Engineering Unterlagen von Jörg Hofstetter (HTA Luzern, 2002)

2004 Software-Engineering - Prozess 5 Entwicklungsprozess Ein Prozess beschreibt, wer was wie wann macht.

4 Activities, Artifacts, and Workers Martin Jud IntroductionSoftware-Engineering - Prozess 7 Adaptiert von den Software Engineering Unterlagen von Jörg Hofstetter (HTA Luzern, 2002) Artifacts and Roles USDP term Symbol & examples Artifacts: the entities that software engineering deals with. Document Model -- a view of the application (design etc.) Component -- physical (source code etc.) Workers: responsibilities allocated to people (roles). Worker Worker instance (e.g., Joe Smith) Martin Jud Software-Engineering - Prozess 8 Adaptiert von den Software Engineering Unterlagen von Jörg Hofstetter (HTA Luzern, 2002)

Document Model -- a view of the application (design etc.) Component -- physical (source code etc.) Workers: responsibilities allocated to people (roles).

5 Example of a Workflow: Requirements Martin Jud IntroductionSoftware-Engineering - Prozess 9 Adaptiert von den Software Engineering Unterlagen von Jörg Hofstetter (HTA Luzern, 2002) Martin Jud Software-Engineering - Prozess 10

den Software Engineering Unterlagen von Jörg Hofstetter

6 Phasenmodelle 3er / 4er Gruppen Lifecycle-Sammlung auswerten: wozu Phasen gibt es Modellfamilien Andere Strukturierungshilfen Zeit: 20 Minuten Martin Jud Software-Engineering - Prozess 11 Martin Jud Software-Engineering - Prozess 12

Strukturierungshilfen Zeit: 20 Minuten Martin Jud

7 Martin Jud Software-Engineering - Prozess 13 Martin Jud Software-Engineering - Prozess 14

8 Martin Jud Software-Engineering - Prozess 15 Martin Jud Software-Engineering - Prozess 16

9 Martin Jud Software-Engineering - Prozess 17 Martin Jud Software-Engineering - Prozess 18

10 Martin Jud Software-Engineering - Prozess 19 Martin Jud Software-Engineering - Prozess 20

11 Martin Jud Software-Engineering - Prozess 21 XP - Lifecycle 1) Erkundung (einige Wochen) 2) Planung (ein, zwei Tage) 3) erster Release (2-6 Monate) 4) Unterhalt (Jahre) 5) Tod Martin Jud Software-Engineering - Prozess 22

12 Main Disciplines Inception Phases Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Disciplines Configuration Mgmt Management Environment Preliminary Iteration(s) Iterations Martin Jud Software-Engineering - Prozess 23 #1 #2 #n #n+1 #n+2 #m #m+1 Iterative, Incremental Development Functionality of runtime system time A A A D D D I I I T T T Iteration 1 Iteration 2 Iteration 3 time Milestone1 Milestone2 Milestone3 Martin Jud Process AlternativesSoftware-Engineering - Prozess 24 Adaptiert von den Software Engineering Unterlagen von Jörg Hofstetter (HTA Luzern, 2002)

2004 Software-Engineering - Prozess 23 #1 #2 #n #n+1 #n+2 #m #m+1 Iterative, Incremental Development Functionality of runtime system time A A A D D D I I I T T T

13 Milestones Ein geplanter Punkt im Projektablauf an dem vorher festgelegte (Zwischen-)Ergebnisse vorliegen, die es erlauben den Projektfortschritt zu messen. At each milestone there should be a formal output. deliverables / working results e.g. report, software component... If the deliverables are available and are positively checked the milestone is reached. Review, meetings, tests Deliverables should be checkable! Martin Jud Software-Engineering - Prozess 25 XP-Grundideen Regeln - nicht Steuern 4 Werte: Kommunikation Einfachheit Feedback Mut 5 Prinzipien: rascher Feedback grösstmögliche Einfachheit kleine Schritte stetige Veränderung hohe Qualität 4 Aktivitäten: codieren testen zuhören entwerfen 12 Praktiken Planspiel kleine Releases Metapher einfaches Design Testen Refactoring Pair-Programming gemeinsamer Besitz Laufende Integration 40-Stunden-Woche Kunde vor Ort Codier-Richtlinien Martin Jud Software-Engineering - Prozess 26

.. If the deliverables are available and are positively checked the milestone is reached. Review, meetings, tests Deliverables should be checkable! Martin Jud 09.03.

14 Praktiken (I) Das Planspiel den Umfang des nächsten Releases wird ermittelt indem die Prioritäten aus Produktmanagement-Sicht und Aufwandschätzungen aus der Entwicklung Schätzungen miteinander verknüpft werden. Stimmt die Planung nicht mehr mit der Realität überein, wird der Plan aktualisiert. Kleine Releases so schnell wie möglich mit einem einfachen System in Produktion gehen und dann in kurzen Abständen neue Versionen herausgeben. Metapher die Entwicklung lenken mit einer einfachen leicht zu kommunizierenden Geschichte, die bildhaft beschreibt, wie das ganze System funktioniert. Martin Jud Software-Engineering - Prozess 27 Praktiken (II) Einfaches Design das System hat zu jedem Zeitpunkt das einfachst mögliche Design. Unnötige Komplexität wird beseitigt, sobald sie entdeckt wird. Testen die Entwickler schreiben laufend Unit-Tests. Nur wenn diese problemlos laufen, wird weiter entwickelt. Die Anwender bzw. Produkt- Manager schreiben Funktionstests, die zeigen dass ein bestimmtes Feature funktioniert. Refactoring Programmierer strukturieren das System um, ohne sein Verhalten zu ändern, um Verdopplung zu beseitigen, verbessern Kommunikation, vereinfachen oder fügen Flexibilität hinzu. Martin Jud Software-Engineering - Prozess 28

Kleine Releases so schnell wie möglich mit einem einfachen System in Produktion gehen und dann in kurzen Abständen neue Versionen herausgeben.

15 Praktiken (III) Pair-Programming der Source-Code wird vollständig im Pair- Programming, d.h. von Entwicklern die zu zweit an einem Rechner arbeiten geschrieben. Gemeinschaftlicher Besitz jedermann kann jederzeit jeglichen Code im gesamten System ändern. Laufende Integration jedes Mal wenn eine Aufgabe abgeschlossen ist, wird eine Systemintegration durchgeführt. Martin Jud Software-Engineering - Prozess 29 Praktiken (IV) 40-Stunden-Woche in der Regel wird nicht mehr als 40 Stunden die Woche gearbeitet. Keinesfalls werden in zwei aufeinander folgenden Wochen Überstunden gemacht. Kunde vor Ort Damit offene Punkte jederzeit geklärt werden können nimmt man am besten einen Anwender ins Team auf. Codier-Richtlinien Der Code ist das wesentliche Kommunikationsmittel zwischen den Entwicklern, deshalb müssen sich alle an gemeinsame Codier-Richtlinien halten. Martin Jud Software-Engineering - Prozess 30

Laufende Integration jedes Mal wenn eine Aufgabe abgeschlossen ist, wird eine Systemintegration durchgeführt.

16 USDP vs. Classical Terminology (I) Classification of iterations Individual iteration Inception Elaboration Construction Transition Prelim. iterations #1.. #n #n+1.. #m #m+1 #k Requirements Analysis Design Implementation Test USDP calls these core workflows (Classically called phases ) Martin Jud Software-Engineering - Prozess 31 USDP vs. Classical Terminology (II) USDP Terminology Classical Terminology Requirements Analysis Design Implementation Test Requirements analysis Design Implementation Integration Test Martin Jud Software-Engineering - Prozess 32

. #m #m+1 #k Requirements Analysis Design Implementation Test USDP calls these core workflows (Classically called phases ) Martin Jud 09.03.

17 The Six USDP Models Use-case model Test model Analysis model Implementation model Design model Deployment model Martin Jud Software-Engineering - Prozess 33 Identify the Process You Will Use 1. Decide which of waterfall, spiral, and incremental processes is appropriate. Combining parts is OK e.g. start with spiral, end with incremental 2. Decide how many iterations. Usually two for a semester project (there are many artifacts to coordinate at the end of each iteration). Three provides lots of practice -- but this is a challenge; make the first increment as minor as possible Three promotes the collection and use of metric data -- use metric data collected from each iteration on next. 3. Rough out a weekly schedule. Coordinate with course assignments. Martin Jud Software-Engineering - Prozess 34

Decide how many iterations. Usually two for a semester project (there are many artifacts to coordinate at the end of each iteration).

Ähnliche Dokumente

Prozess: Übersicht. Plan. configuration management - how to manage documents & code - document: SCMP. next chapter: Plan development process

Prozess: Übersicht. Plan. configuration management - how to manage documents & code - document: SCMP. next chapter: Plan development process Prozess: Übersicht Process Identify corporate practices - assess capability - specify standards - e.g. CMM level Plan project Plan configuration management - how to manage documents & code - document: