Detta har hänt... ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 5 Processer Vidare utveckling Pratat krav, plan, test, design Övning 4: Test, partitioner och täckning Jobbat med testplan och design Börjat programmera? Hunnit göra några ändringar i kraven efter 1.0? Jonas Wisbrant 2 Agenda 3 Kursinformation Nu är det vecka 19 -> slutinlämning om 10 dagar Kursinformation Om Acceptanstest slutbedömning av projekt V 19: Må kl 15 F: Utvecklingsprocesser, vidareutveckling, om tentamen Utvecklingsprocesser Processer vad är det och vilka typer finns? Processledning, processförbättring Vad händer sedan: Vidareutveckling Legacy-system V 20: Må kl 15 F: Om tentamen, sammanfattning, utvärdering On kl 24: Slutleverans projekt V 21: To-fr: Hemtentamen I pausen: Experiment 1: Hur laddade är ord? Kognition & Engelska Före midsommar: I pausen: Inbjudan till experiment 2: Tekniker för kreativitet? Datavetenskap 4 Återkoppling på projekt och projektbetyg Resultat från hemtentan 5
Projektbeskrivning avsnitt 8: Acceptanstest - MS4 i korthet...uppfyller följande kriterier: Levererad programvara uppfyller projektets kravspecifikation. Testas med projektets testfall + egna test Kravspecifikationens och testplanens kvalitet är god. Kontrolleras med checklistor. Det är särskilt viktigt att samtliga funktionella krav adresseras av minst ett testfall. Projektmodellen så som den presenterats följs i tillräcklig utsträckning. Detta kontrolleras genom: analys av levererade dokument: plan, krav, test, design, testrapport, granskningsprotokoll, manualer och lathund. verifiering av ändringshantering konsistens mellan krav, design, test och kod. Vad händer i maj/juni? Utvecklingsprocesser Projektets betyg baseras på samtliga dokument 6 7 Software Engineering bakgrund: The Software Crisis Lösning 1: Ordning och reda F1 #28 10 challenges [The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. Försenade projekt Många fel i levererade produkter Projekt som fick avbrytas Stora kostnader Produkter som bara blir större och större Edsger Dijkstra, The Humble Programmer, 1972 NATO-konferens i Garmish-Partenkirschen 1968 myntade begreppet Software Engineering Ta efter hur utveckling sker i andra ingenjörsdiscipliner Ordning och reda Löste många problem, men svårt ta hänsyn till ändringar Fler lösningar: Utveckla iterativt Dela upp projekt i delprojekt 8 9
Utvecklingsprocesser - begrepp Process: Det arbete som görs för att utveckla programvara Processmodell: En beskrivning av processen Processer och processmodeller centrala begrepp Processförbättring: Arbetet med att förbättra processen Utvecklingsprocess Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 10 11 Aktiviteter i alla processer Specifikationsaktiviteter Utvecklingsaktiviteter Verifieringsaktiviteter Vidareutvecklingsaktiviteter Varför engagera sig i processer? Kvalitet Koppling processkvalitet - produktkvalitet Rationellt Gemensamt för flera projekt Finns i alla processer utvecklingsprocesser,...men kan komma i olika ordning...med olika fokus etc. Organisationsutveckling Ramverk för lärande 12 13
Processmodeller Aktivitetsorienterade, t ex Möjlighetsstudie Kravinsamling Implementation Testning Resultatorienterade, t ex Möjlighetsrapport Kravspecifikation Kod Testrapport Att ha med i en processmodell Aktiviteter Processer en serie steg med gemensamt mål Leverabler Villkor startvillkor, slutvillkor Roller Informationsvägar Undantag Process, subprocess, aktivitet, procedur? 14 15 Processmodell - exempel Processmodell - exempel Requirements Planning Plan Startvillkor Modul kompilerad utan syntaxfel Roll Testingenjör Stoppvillkor Alla definierade test går igenom Scripts Code Ansvarig för Output Process Aktivitet Guide Compile Test Postmortem Finished product Defects Time Logs Results Project Plan Summary Input Modulspecifikation Process Testmodul Signerad testrapport Testdata från modulen Leverabel 16 17
Vattenfallsmodellen Kravspecifikation Många olika processmodeller för utveckling Implementation Enhetstest Integration Systemtest Underhåll 18 19 V-modellen - vattenfall med återkoppling Mål Drift & underhåll Acceptanstest Vattenfallsmodellen: Problem Kraven kan sällan frysas: Flexibilitet är ett av motiven för programvara hårdvara hinner utvecklas under långa projekt Kravhantering Systemtest Big bang-integration sällan framgångsrik Ökar risk för nice-to-have bland kraven för säkerhets skull... Implementation + enhetstest Integrationstest Kostnaden för att underhålla dokument är hög - kundnytta? 20 21
Evolutionär utveckling Två varianter av evolutionär utveckling Utkast Utvecklingsprocessen Prototyputveckling, vidareutveckling? Rapport Test Utvärdering Krav Test Behov Beslut Rapport A B C D F Versioner för kommentarer Krav Krav Slutgiltig version Prototyputveckling Först prototyp, sedan riktigt system Stora risker med tekniken Börja med svåra krav Utforskande utveckling - iterativ Arbeta hela tiden med riktigt system Stora risker med kraven Börja med viktiga krav Utmaningar Svag insyn Kan ge dålig struktur Höga krav på utvecklarna Kund / användare 22 23 Timeboxing Timeboxing ett verkligt exempel Timebox 1 Krav /impl Deploy Timebox 1 Krav /impl Deploy Timebox 2 Krav /impl Deploy Kravteam Krav TB1 Krav TB2 Krav TB3 Utveckling /impl TB1 /impl TB1 /impl TB1 Drift Deploy TB1 Deploy TB1 Deploy TB1 24 25
Spiralmodellen Inkrementell utveckling Parallell utveckling Tidiga leverabler Möjlighet att identifiera krav under utvecklingen Minskad risk Tidiga inkrement kan testas många gånger R D T D T D T 26 27 Diskutera Lättrörliga processer (agile) Ge exempel på projekt när följande processer är lämpliga Vattenfallsmodellen Prototyper Inkrementell utveckling med kontinuerliga releaser Några viktiga delar Individer och interaktion i stället för processer och verktyg Fungerande programvara i stället för fullständig dokumentation Req Code Test Release R D C T Prototyp R D D T Release T Release D T Release Kundsamverkan i stället för kontraktsförhandlingar Anpassning till förändringar i stället för följande av plan XP DSDM FDD R D C T Release SCRUM Crystal Nightly build ASD 28 29
XP Practices Planning Game Pair Programming Small Releases Collective Ownership Metaphor Continuous Integration Simple 40-hour week Testing On-site Customer Refactoring Coding Standard Några exempel på processbeskrivningar från kursen - olika nivåer Mer om detta i Programvaruutveckling i grupp - projekt ETS260 30 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 Kravspecifikation Fas 1 Specifikation Projektplan Testplan Fas 2 dokument Fas 3 Implementation och enhetstest Fas 4 Systemtest Kort version av vår process: 1. Person A finds out that there is something wrong in a document 2. Person A locates the fault in the document (currently in version 1.0) 3. Person A notifies the person responsible for the document (person B) and asks for permission to change it 4. Person B gives person A permission to change the document 5. Person A updates the document, updates the version number to 1.1 and gives it to person B. 6. Person B is now responsible for telling all persons that are working with the document or depend on it, that there is a new version. Exekverbar källkod Dokumenterat genomförda systemtest 31
Acceptanstest (VoV) 0.x Good version Kravhantering Individual inspection 0.99 Supervisor review Integrations-test Inspection meeting Inspection protocoll Systemtest (Verifiering) Implementation Enhetstest Better version Aktör A Meddelande 0.0991 Media Meddelande Aktör B Återkoppling Supervisor feedback 1.0 Processer på företagsnivå Processer Organisationsprocesser Processmodeller Processförbättring Processer för hela företaget Projektstyrning Projektstyrningsprocesser PPS, PROPS, PRINCE...? SCRUM? RUP? Utvecklingsprocesser V-modell, prototyping, XP...? Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 36 37
Pr oje k tst Pla Intressentanalys (stakeholders) yrn ne ing rin sp g roc es Up s Utvecklare Beställare pfö ljn ing oc hs tyr nin Kundansvarig Sponsor g Ut ve ck lin gs Projektledare pro IT-funktion ce ss en Slutanvändare Projektstyrningsprocess Projektstyrningsprocess Planering Uppföljning och styrning Post mortem Utvecklingsprocessen Utvecklare Underleverantör Vad vill varje intressent? Konflikter? Vad ingår i pilarna? = mätvärden Gränssnitt Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F4 = styrning 38 Olika sorters processer 39 Processmodell för kursen på hög nivå Process Faser och leverabler Produktutvecklingsprocess Process för utveckling av processer Kravspecifikation Fas 1 Specifikation Projektplan Aktivitetseller resultatorienterad? Testplan Fas 2 Projektledningsprocess Utvecklingsprocess Kravprocess Testprocess CM-process dokument Fas 3 Implementation och enhetstest Mer generella Fas 4 Systemtest Exekverbar källkod Dokumenterat genomförda systemtest Granskningsprocess 40 41
Utveckling av processer Anpassning Processer för att utveckla och anpassa processer Organisation Projekt Erfarenhet 42 43 Processförbättringsprocess 1.Identifiera förbättringar! Processmodell 2.Bestäm förbättringar! Ändringsplan, utbildningsplan 3.Introducera ändringar! Återkoppling 4.Finjustera processen! Uppdaterad processmodell Anpassning Organisation Projekt Erfarenhet Skillnad verklig process referensprocess? Referensprocess en process som man vill använda Verklig process den process man verkligen använder Målprocess den process man vill uppnå på sikt Tänk även på: upplevd process och observerad process. 5.GOTO 1 44 45
Processer lösning på allt? År 1969: NATO-konferens myntade begreppet Software Engineering År 1987: No silver bullet! Vad händer efter release? Legacy Systems Frederick Brooks, No Silver Bullet Essence and Accidents of Software Engineering, IEEE Computer, April 1987. 46 Legacy system 47 Legacy systems Wikipedia: A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available. A legacy system may include procedures or terminology which are no longer relevant in the current context, and may hinder or confuse understanding of the methods or technologies used. Kan vara affärskritiska Kan vara gamla (ibland > 30 år) Innehåller: Applikationsprogram (flera?) Data (mycket data i flera filer, udda format) Affärsprocesser 48 Prog A Prog B Prog C Prog D 49
Hur använder vi och underhåller legacy system? Lehmans Lagar (1985) Rätta fel i kod Rätta fel i krav och design Förbättra design Förbättra programmen Koppla samman med andra system Prog A Konvertera program så att ny hårdvara, kommunikationssystem etc kan användas Avveckla system Prog B Kontinuerliga krav på förändring Om ett program används så kommer det att behöva ändras. Ökande komplexitet När man ändrar i ett program blir det mer komplext och svårare att förstå. Vidareutveckling av stora programvaruprodukter Självreglerande m.a.p. antal nya funktioner, problemrapport, etc per version. Inte lönt försöka göra en för stor förändring på en gång. Prog C Prog D Organisatorisk stabilitet Utvecklingshastigheten blir konstant oberoende av resurser. 50 51 Underhåll efter release Sammanfattning - processer Kräver Ändringshantering Konfigurationshantering Påverkansanalys Spårbarhet Regressionstest Man skiljer mellan: Felrättande (Corrective) Anpassande (Adaptive) Förbättrande (Perfective) Preventivt (Preventive) Change request Delivery Impact analysis Verification Implementation Release planning Utvecklingsprocessen är det som görs för att utveckla programvara Processmodellen är en beskrivning av processen Några exempel på processmodeller: vattenfall, prototyputveckling, iterativ utveckling, timeboxing, spiralmodellen, lättrörlig utveckling Projektstyrningsprocessen är ett annat perspektiv på projektet Processförbättring görs för att få bättre projekt m.a.p. kostnad, ledtid och kvalitet Legacy system är gamla system som levt kvar länge, i många fall längre än vad man förväntade sig från början Fyra sorters underhåll: felrättande, anpassande, förbättrande, preventivt 52 53
Tentafråga att suga på inför nästa vecka: U2 Testa ditt system (10 p) Jalote presenterar flera olika metoder för att välja ut testfall och/eller för att säkerställa att de täcker projektets behov:! Equivalence Class Partitioning! Boundary Value Analysis! Pairwise Testing! State-Based Testing! Control Flow-Based Criteria a) Förklara kortfattat vad respektive metod går ut på. b) Anta sedan att du ska formulera en serie testfall för nivåerna:! Enhetstest! Integrationstest! Systemtest Välj för varje nivå ut en eller två av de metoder som du förklarade i första delen av uppgiften som du finner mest lämpliga och argumentera för ditt val av metod (er). Nästa vecka: Kravhantering Ingenjörsprocessen - ekonomi och kvalitet Coaching av programvaruteam Programvarutestning Krav Test Kod Binär Programvaruutveckling för stora system Objektorienterad modellering och design Konfigurationshantering Projektplan Utvprocess Programvaruutveckling i grupp 55