Struktureret system udvikling Minimodul 1: Introduktion, projekt- og tidsplanlægning

Struktureret system udvikling Minimodul 1: Introduktion, projekt- og tidsplanlægning Rasmus L. Olsen, 2 februar 2011 1

Dagens program Introduktion og overblik over kursus Motivation for struktureret systemudvikling Projektfaser Aktiviteter Tidsmæssige sammenhænge V model Parallel udvikling Tidsplaner 2

Introduktion Kursets hjemmeside http://www.control.aau.dk/~jdn/edu/courses/11-1/udvmodeller/ Kursus holder Rasmus L. Olsen, Jan D. Bendtsen, Jens D. Nielsen Kort om mig selv Færdiguddannet i 2003 (Intelligente Autonome Systemer) Stærkt involveret i bl.a. AAU Cubesat 1 og ADAROS Forsvaret PhD projekt i Januar 2008 Arbejdet i Europæisk forskningsprojekter MAGNET 2004-2005 Udvikling af nyt netværksparadigmer (Personal Networks) MAGNET Beyond 2006-2008 (http://www.ist-magnet.org) OPEN 2008-2010 (service migration) 3

Kursus indhold og mål Viden der gør de studerende i stand til at: kunne redegøre for og skelne mellem forskellige udviklingsmodeller kunne redegøre for sammenhængen mellem en udviklingsproces og tidsplanlægning kunne redegøre for designmetoder til både hardware og softwareudvikling kunne forklare betydningen af en krav-analyse og specifikation for et udviklingsforløb kunne forklare interaktion mellem system og eksterne aktører kunne identificere og klassificere generelle grænseflader, f.eks. med henblik på genbrugelighed af grænseflader kunne skelne mellem prototype implementation, emulering og simulering kunne redegøre for black- og whitebox testmetoder 4

Væsentlige kompetencer Kompetencer, der gør de studerende i stand til at: være i stand til at definere et system, nedbrydelse i delsystemer samt integration af delsystemer være i stand til at vurdere og perspektivere system verifikation i forhold til systemkrav 5

Opfyldelse af studiemål Læsning af litteratur (primære og supplerende) Forelæsninger Opgaveløsninger Aktiv deltagelse i opgaveløsninger Fordelagtigt, også i forhold til jeres projekt NB! I studieordningen står der enten mundtlig eller skriftlig prøve med bestået/ikke bestået. Det er ikke klarlagt endnu hvilken metode evalueringen består i. 6

Kursusoversigt og tidsplan Mm1: Introduktion, projekt og tidsplanlægning (Rasmus) Mm2: Analyse og indledende design (Rasmus, selvstudie) Mm3: Krav og accepttest (Rasmus) Workshop I : Opsummering af mm1 3 (Rasmus, Jens, Jan) Mm4: SPU I (Jens) Mm5: SPU II (Jens, selvstudie) Mm6: Object Orienteret programmering I (Jan) Mm7: Object Orienteret programmering II (Jan) Mm8: Object Orienteret programmering III (Jan, selvstudie) Mm9: Scrum og xtreme programmering - I (Jens) Mm10: Scrum og xtreme programmering - II (Jens, selvstudie) Workshop 2: Opsummering af mm 4-10 (Rasmus, Jens, Jan) Mm11: Test in real life - I (Rasmus) Mm12: Test in real life - II (Rasmus, selvstudie) Workshop 3: Opsummering af mm 12-13 (Rasmus, Jens, Jan) Opfølgning (selvstudie) 7

Kursusbog #1 Introduction to Systems Chapter 1 Systems Science and Engineering Chapter 2 Bringing Systems Into Being The system design process Chapter 3 Conceptual System Design Chapter 4 Preliminary System Design Chapter 5 Detail Design and Development Chapter 6 System Test, Evaluation, and Validation System analysis and design evaluation Chapter 7 Alternatives and Models in Decision Making Chapter 8 Models For Economic Evaluation Chapter 9 Optimization in Design and Operations Chapter 10 Queuing Theory and Analysis Chapter 11 Control Concepts and Methods 8

Kursusbog #2 Design for operational feasability Chapter 12 Design for Reliability Chapter 13 Design for Maintainability Chapter 14 Design for Usability (Human Factors) Chapter 15 Design for Logistics and Supportability Chapter 16 Design for Producibility, Disposability, and Sustainability Chapter 17 Design for Affordability (Life-cycle Costing) System engineering management Chapter 18 Systems Engineering Planning and Organization Chapter 19 Program Management, Control, and Evaluation + Flere nyttige appendices 9

Dagens program Introduktion og overblik over kursus Motivation for struktureret systemudvikling Projektfaser Aktiviteter Tidsmæssige sammenhænge V model Parallel udvikling Tidsplaner 10

System udvikling set i perspektiv Udbud Forventninger Marked Kvalitets mangel Efterspørgsel Resultater Ekstern proces (f.eks. samfundet) Krav System udvikling Forretningsmuligheder Resultater Kvalitets mangel Forventninger Udbud Marked Efterspørgsel Intern proces (f.eks. virksomhed) Krav Udbud 11

Problemstillingen i en nøddeskal 12

Hvorfor en struktureret tilgang? Tidsstyring Vedligeholdelse Dokumenentation Risikominimering Kvalitetsoptimering Genbrug m.m. 13

Fejlretningsudgifter 100 10 1 Relativ udgift for fejlretning Nooooo Krav Design Impl. Test Drift Jo længere henne i udviklingsprocessen, jo mere koster det at rette fejl i tid og penge Systematisk design gør det lettere at rette fejl! Kravfejl -> Designfejl Designfejl -> Impl. fejl Impl. fejl -> tid og penge Årsager (eksempler) Mangel på erfaring Dårlig kommunikation Indforståetheder 14

Styringsproblemer Udgifter/ Tidsplan/ Problemer AARRGGhh Realitet Planlagt Årsager (eksempler) Manglende kravspecifikation -> ringe estimeringsgrundlag Mangel på indsigt i udviklingsproblematik Dårlig koordinering mellem udviklere pga. dårlige interface design Mangel på forståelse mellem udviklere Krav Design Impl. Test Integration Hvad går galt her? Problemer bliver først opdaget når moduler er implementeret og skal integreres! 15

Software fejludvikling Fejlhyppighed Uheld Ustruktureret/ Udokumenteret Spaghetti kode er svært at vedligeholde - Umuligt at huske efter 10 mdr. Held Struktureret Start V1.0 V2.0 V3.0 Udvikling Udokumenteret kode er svært at udvikle videre på - Centreret omkring få udviklere - Øger afhængighed af disse Introduktion af SW opdateringer Skal være nemt for brugeren og ikke stille alt for store krav Skal ikke introducere flere problemer end der løses 16

Undtagelser En person om en simpel ting, f.eks. Ens personlige hjemmeside Et lille hobby projekt Eller mere generelt: når der er tale om et minimalt personligt system til engangsbrug Ellers altid en god ide at bruge struktureret system design 17

Konklusion Udvikling er ikke let, specielt ikke hvis det skal ende med succes! Højere succesrate: Struktureret Systemudvikling 18

Dagens program Introduktion og overblik over kursus Motivation for struktureret systemudvikling Projektfaser Aktiviteter Tidsmæssige sammenhænge V model Parallel udvikling Tidsplaner 19

Projektfaser og plan 1. Benyt en udviklingsmodel 2. Udarbejd en kravspecifikation 3. Design før kodning 4. Planlæg test 5. Anvend review teknikken 6. Foretag projektstyring 7. Dokumentér undervejs 8. Foretag konfigurationsstyring 20

Projektforløb Hvorfor? Hvad? Hvordan? Sådan! Værsgo! Ide- og analyse fase Kravspecifikation System Design SW udvikling HW udvikling Test og validering 21

Iterativt projektforløb Analyse Krav Spec. Design Impl. Accept test Integration Vedligeholdelse - Iteration af projektforløbet er en vital del af struktureret system udvikling - Jo kortere loops, jo bedre, men ingen loop er urealistisk! 22

Kravspecifikation U-model for udviklingsaktiviteter Analyse og kravspecifikation Analyse Arkitektur Design SW og HW implementering af use case X System Integrationstest Accepttest Use Case Model Iteration 23

Lidt flere detaljer i projektforløbet Tid 24

SPU modellen Kravspecifikation: Analyse og use case specificering Kravspecifikation Accepttest specifikation Foreløbelig brugervejledning Evt. en simpel prototype/demo Review af kravspecifikation 25

SPU modellen Program design: Opdeling af system i parallelle processer Eksterne grænseflader Interne grænseflader Synkronisering af processer Procesintegration-specifikation Hvordan integreres processerne? Hvad integreres hvornår? Kritiske komponenter først! Vigtigt at alle i gruppen er aktive og enige! 26

SPU modellen Procesdesign: Opdeling af proces i moduler Sekventielt program Fællesmoduler Modul specifikation (krav, funktioner, grænseflader) Modulintegrations-specifikation Identifikation af test programmer/stubbe Integration og test 27

SPU modellen Moduldesign: Specialiseret design af modul Hvordan Algoritme/flow chart/diagram udlægning Specifikation af datastrukturer Modul test specifikation Black-boks test White-boks test 28

SPU modellen Modulimplementering Omsætning af design til kode/hardware Følg standarder, f.eks. Kodestandarder såsom ANSI-C Ledningefarver, f.eks. sort: stel, rød: +5V Stikforbindelser Kodegranskning Forbedrer kode kvalitet Opdagelse af logiske fejl Læring af andres succeser/fejl Nedbrudt ejerskab 29

SPU modellen Modultest: Verificering at modulet overholder modulspecifikationen Skrivning af test moduler/stubbe Brug af test apparater Udfyldning af test rapport Dokumentation over hvad der er, og ikke er blevet testet for! Dokumentation over hvilke problemer der eventuelt er fundet. 30

SPU modellen Modulintegration: Samling af moduler Test af proces - integrationsrapport Dokumentation over hvad der er, og ikke er blevet testet for! Dokumentation over hvilke problemer der eventuelt er fundet. Vær forsigtig/realistisk Koble kun et modul sammen ad gangen Vær beredt på at skulle gå tilbage til start 31

SPU modellen Processintegration: Samling af parallelle processer Sikring at proces kommunikation virker Udarbejdelse af procesintegrationsrapport Det står i bogen det kan være svært, men hvorfor? Manglende funktionaliteter (ups, det mangler vi) Dobbeltarbejde (det er jo det jeg har lavet ) Misforståelser under projektforløbet Forkerte interfaces (jeg troede du mente ) Forkerte datatyper (skulle det være en Float??) Forkert opfattelse af funktionaliteter (skulle den have beregnet kvadratroden også??). 32

SPU modellen Accepttest: Skal svare på det helt store spørgsmål: Er produktet som køberen forventer? 33

V-modellen - overordnet Kravspecifikation Accepttest Arkitekturdesign System integrationstest SW & HW Implementering 34

V - modellen (Software) Kravspec. Programdesign Procesdesign Moduldesign Accepttest Procesintegration Modulintegration Modultest Implementation 35

V - model (Hardware) Kravspec. Strukturdesign Accepttest Integrationstest HW moduldesign Layoutdesign HW Modultest Forbindelsestest Wrapning/Printudlægning 36

Review undervejs Reviews 37

Med går det så gnidningsfrit??? NEJ!!! Men sandsynligheden for det går helt galt reduceres betydeligt 38

Dagens program Introduktion og overblik over kursus Motivation for struktureret systemudvikling Projektfaser Aktiviteter Tidsmæssige sammenhænge V model Parallel udvikling Tidsplaner 39

Et problem: Parallel udvikling af software og hardware SW Implementering af use case X Modul design Detaljeret design Kodning Unit test Modul Integrationstest Diagram tegning Komponent beregning Wrapning/ Lodning Test Modul Integrationstest HW Implementering af use case X Spørgsmål: Hvordan udvikler man SW der skal køre på HW, SAMTIDIGT??? 40

Parallel udvikling Realiteten er ofte en balancegang mellem to metoder Sekventiel udvikling 41

Eksempel på et blok opdelt system fjernstyret robot GUI PC Controller Robot Platform Platform Aktuator (lyd) SW driver Kommunikation Højttaler Joystick WLAN Hvordan får man effektivt distribueret opgaver, således? Alle laver noget hele tiden Undgår tidspres i slutningen af projektet Alle kan tale sammen og se hinanden i øjnene efter projektet 42

Hemmeligheden er... Grænseflader (Interfaces) Hvorfor? Eksempel: Antag vi har fastlagt kommunikation til, så kan GUI folkene snakke med en hurtig stub som imiterer den relle kommunikation Platform Kommunikation WLAN HTTP: Besked x og y TCP/IP 802.11.g GUI Test stub (HTTP via127.0.0.1) Ligeså med hardware/software Joystick 2 pins: [0..5V] SW Test stub -> 0..1024 (0-5V) 43

Dagens program Introduktion og overblik over kursus Motivation for struktureret systemudvikling Projektfaser Aktiviteter Tidsmæssige sammenhænge V model Parallel udvikling Tidsplaner 44

Tidsplaner, projektstyring, resourceudnyttelse Aktiviteter Design & impl. med test stub SW Modul 3 SW Modul 3 Integration SW Modul 2 SW Modul 2 SW Modul 1 SW Modul 1 HW Modul 2 HW Modul 1 HW Modul 3 System specifikation Design & Impl. Kravspecifikation Start M1 M2 M3.1 M3.3 M3.2 M3 tid 45

Værktøjer Eksempel fra Microsoft Project, taget fra Wikipedia (http://en.wikipedia.org/wiki/file:pert_example_gantt_chart.gif) Der findes en lang række software produkter der kan være behjælpelig med grafisk repræsentation af tidslinjer Kan også være en stor kalender, gule sedler,. En del af dagens opgave at finde et fornuftigt værktøj i kan benytte i jeres projekt, og få det afprøvet 46

W-model for leverancer X tid E E L Leverancetid L Y tid Z tid E E E Andre gruppe (medlemmer) kan også være modtagere af (del)produkt! Spørgsmål: Hvorledes bestemmer man hvor leverancerne skal ligge tidsmæssigt? 47

Bestemmelse af leveringstider/synkroniseringspunkter God planlægning kræver erfaring! Estimering af tid til opgaver der inddrager forskellige, svært vurder bare parametre Analogi: Hvor lang tid tog en lignende opgave sidst? Faktor vurdering: Hvor erfaren er vedkommende/gruppen man sætter på at lave modul X eller Y? Nyskabelse: Er der noget nyt involveret i aktiviteten? Forudsigelse: Kan der forudses problemer? Kommunikation mellem involverede er ALTAFGØRENDE!!!! 48

Bestemmelse af leveringstider/synkroniseringspunkter - Arbejd bagfra #1 Lige før aflevering Hvornår skal i aflevere? Hvor lang tid skal i bruge til at rette de sidste ting? Printe og samle? Hvad hvis printeren ikke fungerer eller computeren går ned? Test og validering Hvor lang tid skal i bruge på at teste? Hvad nu når tingene giver anledning til problemer i ikke har set før? Hvad nu når i opdager det i har testet ikke er godt nok, er forvirrende og ingen mening giver? Hvis i opdager en fejl i test opstillingen? 49

Bestemmelse af leveringstider/synkroniseringspunkter - Arbejd bagfra #2 Integration Hvor lang tid tager det at ændre et interface til det rigtige? SW interfaces er hurtigere at ændre end HW interfaces, men det kan til gengæld være svært at opdage fejl i SW interfaces Hvor mange moduler har i? Et modul sættes sammen ad gangen (ingen Big Bang test). Hvad når et modul fejler når i har sat noget sammen? Hvad er plan B, C eller D? Modul Hvor svært er det i har med at gøre for det enkelte modul? Har i gjort noget lignende før? Er der dele i modulet som er svært at anskaffe? 50

Bestemmelse af leveringstider/synkroniseringspunkter - Arbejd bagfra #3 System design Hvor komplekst er jeres system? Hvor meget dokumentation skal udarbejdes og gennemarbejdes? Brug tid på at blive enige om interfaces; forstå jeres interfaces! Kravspecifikation og system definition Hvor komplekst er jeres system? Hvor meget dokumentation skal udarbejdes og gennemarbejdes? Skal der støves regler og standarder op fra diverse databaser? Er kunden kendt som langsom eller hurtig responderende? Husk, i kan og bør altid iterere på jeres kravspecifikation, og system definition 51

Køkkenvask syndromet... Mer vil ha mer problemet (scope creep) Det skal de nok nå, så det er en aftale Den her mangler vi altså! Det kunne nu også være smart, hvis den også havde Kunderne vil Have dit og dat Er den ikke lidt kedelig at se på? 52

Et par yderligere gode råd Løbende feedback og justeringer ved hjælp af status møder og opfølgning er nødvendigt Det er en del af jeres læringsproces!! Brug jeres vejleder til estimering af tid til opgaver 53

At lave projektarbejde kræver samarbejde. 54

Opgaver Undersøg hvilke værktøjer der findes til projektstyring/tidsplanlægning, evt. se på ovenstående links, og forbered på at argumentere hvorfor lige netop det værktøj i har fundet er et rigtig godt værktøj? Hvordan definerer i et 'godt' værktøj? Hvilke krav har i til at benytte et eller flere styringsværktøjer? Hvis i kunne gå tilbage i tiden med den viden og erfaring i har nu, hvordan vil i så planlægge jeres tid i P1 projekt perioden? Antag i er blevet spurgt om at lede en større projektgruppe (de andre grupper) om at bygge en satellit (eller et andet stort projekt), hvordan vil i gribe opgaven an? 55