Föreläsning 5 Processer, vidare utveckling

Transkript

1 OBS! Grupp och har övning i E:3336 på torsdag ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 5 Processer, vidare utveckling Jonas Wisbrant [ 1 Agenda 2 Detta har hänt... Kursinformation Om återkoppling MS2 Om slutbedömning Om ett testfall 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? Utvecklingsprocesser Processer vad är det och vilka typer finns? Processledning, processförbättring Vad händer sedan: Vidareutveckling Legacy-system 3 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4 4

2 OBS! Kursinformation Grupp och har Nu är det vecka 5 -> slutinlämning om övning i knappt fem veckor (20 maj) E:3336 på V 5: torsdag F: Nu Idag: kl 24: inlämning av Testplan 1.0 och Design 1.0, Granskningsprotokoll inför dem Ö To: Om hemtentamen + Återkoppling MS2 - ta med era dokument Påskuppehåll i tre veckor? V 6: F: Stora projekt / stora företag V 7: Ingen föreläsning, ingen övning Inlämning fredag 20 maj: Sista versionen av Kravspecifikation, Projektplan, Testplan, Design, exekverbar kod, Manual och lathund samt testprotokoll Återkoppling MS2: Testplan MS2: Vi tittar på formalia och dokumentkrav: Refererar testplanen till rätt kravspec.? Anges hur testrapporter ska hanteras? Finns kravtäckningsmatris och stämmer den? Beskrivs hur kvalitetskrav skulle kunna testas? Endast stickprov - rimliga testfall! Exempel: Testar testet kravet Kan det genomföras (blackbox)? Är testet konkret (PIN-kod eller 1358) Hanteras svårtestade krav 5 6 Återkoppling MS2: Designdokument Vi tittar på formalia och dokumentkrav: Refererar designdokumentet till rätt kravspecifikation? Finns klassdiagram för alla egna klasser Ej Attribut och metoder, ej GUI eller färdiga klasser Beskrivs alla klasser begripligt? Finns ansvarig person? Listas publika metoder? Ger metoderna rimliga returer? Stämmer klass-diagrammet? Se ny: Återkoppling troligtvis i klartext 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 verifying change management procedures konsistens mellan krav, design, test och kod. Projektets betyg baseras på samtliga dokument Vad händer i maj/juni? 7 8

3 Test case 4: Press more than one button Pre-condition: Machine in start state. Post-condition: Machine in start state. A water can is recieved. Test case 4: Press more than one button Pre-condition: Machine in start state. Post-condition: Machine in start state. A water can is recieved. start-state - water can + #coins...? Vad är start state? Antal mynt? Antal burkar? 1. Press the water selection button. 2. Press the beer selection button. 3. Insert a 5kr coin. 4. Insert 2 x 1kr. 5. Recieve a water can 1. Press the water selection button. 2. Press the beer selection button. 3. Insert a 5kr coin. 4. Insert 2 x 1kr. 5. Recieve a water can Hur och varför kollar vi pre- och post-condition? Pre- och post-condition används för att skapa vettiga testserier. Ansvaret ligger på testaren - icke uppfyllda möjlig fel-källa 9 10 Utvecklingsprocesser Software Engineering bakgrund: The Software Crisis Försenade projekt Många fel i levererade produkter Projekt som fick avbrytas Stora kostnader Produkter som bara blir större och större [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. Edsger Dijkstra, The Humble Programmer,

4 Lösning 1: ordning och reda 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 Processer och processmodeller centrala begrepp Fler lösningar: Utveckla iterativt Dela upp projekt i delprojekt 13 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 14 Utvecklingsprocesser - begrepp Olika sorters aktiviteter i processer Process: Det arbete som görs för att utveckla programvara Processmodell: En beskrivning av processen Processförbättring: Arbetet med att förbättra processen Utvecklingsprocess Specifikationsaktiviteter Utvecklingsaktiviteter Verifieringsaktiviteter Vidareutvecklingsaktiviteter Finns i alla processer, men kan komma i olika ordning etc

5 Varför bra att fokusera på processer? Koppling processkvalitet produktkvalitet Gemensamt för flera projekt Ramverk för organisatoriskt lärande Processmodeller Aktivitetsorienterade, t ex Möjlighetsstudie Kravinsamling Design Implementation Testning Resultatorienterade, t ex Testrapport Kod Design Kravspecifikation Möjlighetsrapport Att ha med i en processmodell Exempel Aktiviteter Processer en serie steg med gemensamt mål Leverabler Villkor startvillkor, slutvillkor Roller Informationsvägar Undantag Process Aktivitet Scripts Guide Requirements Planning Design Code Compile Test Postmortem Finished product Defects Time Logs Plan Results Project Plan Summary Leverabel 19 20

6 Ett exempel till Några kända exempel på processer på olika nivåer 21 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 Kravspecifikation Fas 1 Specifikation Projektplan Testplan Fas 2 Design Designdokument 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 22

7 Acceptanstest (VoV) Kravhantering Systemtest (Verifiering) Integrations-test Design Implementation 0.x Good version Aktör A Individual inspection Meddelande 0.99 Supervisor review Media Meddelande Återkoppling Inspection meeting Inspection protocoll Enhetstest Better version Supervisor feedback 1.0 Vattenfallsmodellen Requirements specification Design Många olika processmodeller för utveckling Implementation Unit test Integration System test Maintenance Aktör B

8 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 Design Integrationstest Systemtest Big bang-integration sällan framgångsrik Ökar risk för nice-to-have bland kraven för säkerhets skull... Implementation + enhetstest Kostnaden för att underhålla dokument (som kanske inte ger kundnytta) är hög Evolutionär utveckling Två varianter av evolutionär utveckling Utkast Utvecklingsprocessen (vidareutv. eller prototyputv) Slutgiltig version Prototyputveckling Först prototyp, sedan riktigt system Stora risker med tekniken Börja med svåra krav Versioner för kommentarer Utforskande utveckling - iterativ Arbeta hela tiden med riktigt system Stora risker med kraven Börja med viktiga krav Kund / användare 31 32

9 Timeboxing Timeboxing ett verkligt exempel Timebox 1 Krav Design/impl Deploy Timebox 1 Krav Design/impl Deploy Timebox 2 Krav Design/impl Deploy Kravteam Krav TB1 Krav TB2 Krav TB3 Utveckling Design/impl TB1 Design/impl TB2 Design/impl TB3 Drift Deploy TB1 Deploy TB2 Deploy TB 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 35 36

10 Diskutera Lättrörliga processer (agile) R Ge exempel på projekt när följande processer är lämpliga Vattenfallsmodellen Prototyper Inkrementell utveckling med kontinuerliga releaser D C T Release R D C T Prototyp R D D T Release T Release D T Rel 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 Kundsamverkan i stället för kontraktsförhandlingar Anpassning till förändringar i stället för följande av plan R D C T Release XP Practices Planning Game Pair Programming Small Releases Collective Ownership Metaphor Simple Design Continuous Integration 40-hour week Processer för hela företaget Testing On-site Customer Refactoring Coding Standard 39 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 40

11 Processer på företagsnivå Projektstyrningsprocess Organisationsprocesser Processer PS: Planering Uppföljning och styrning Utv: Utvecklingsprocessen Post mortem Processmodeller Processförbättring Projektstyrning Projektstyrningsprocesser Utvecklingsprocesser Vad ingår i pilarna? = mätvärden V-modell, prototyping, XP...? = styrning 41 Olika sorters processer 42 Processmodell för kursen på hög nivå Process Faser och leverabler Produktutvecklingsprocess Process för utveckling av processer Kravspecifikation Fas 1 Specifikation Projektplan Testplan Fas 2 Design Projektledningsprocess Utvecklingsprocess Kravprocess Testprocess CM-process Designdokument Fas 3 Implementation och enhetstest Mer generella Fas 4 Systemtest Exekverbar källkod Dokumenterat genomförda systemtest Granskningsprocess 43 44

12 Utveckling av processer Anpassning Processer för att utveckla och anpassa processer Organisation Projekt Erfarenhet 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 5.GOTO 1 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

13 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 Legacy system 50 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 > 20 år) Innehåller: Applikationsprogram (flera?) Data (mycket data i flera filer, udda format) Affärsprocesser 51 Prog A Prog B Prog C Prog D 52

14 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 Prog A Prog B Koppla samman med andra system Konvertera program så att ny hårdvara, kommunikationssystem etc kan användas Avveckla system 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 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 55 56

15 Vecka 6 Stora system + och sedan då... Kravhantering Programvarutestning Objektorienterad modellering och design Projektplan Test Design Konfigurationshantering Ingengörsprocessen - ekonomi och kvalitet Krav Kod Binär Utvprocess Programvaruutveckling i grupp Coaching av programvaruteam Programvaruutveckling för stora system 57