OBS! Grupp 12-16 och 23-26 har övning i E:3336 på torsdag [http://www.google.com/googlebooks/chrome/] 1 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 5 Processer, vidare utveckling Jonas Wisbrant 2
Agenda Kursinformation Om återkoppling MS2 Om slutbedömning Om ett testfall Utvecklingsprocesser Processer vad är det och vilka typer finns? Processledning, processförbättring Vad händer sedan: Vidareutveckling Legacy-system 3 Detta har hänt... 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? Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2011 / F4 4
OBS! Kursinformation Grupp 12-16 och 23-26 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 5 Å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 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: http://cs.lth.se/kurs/etsa01/projekt2011/stoed_och_mallar/ 6.8 Återkoppling troligtvis i klartext 7 Projektbeskrivning avsnitt 8: Acceptanstest - MS4 i korthet Vad händer i maj/juni?...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 8
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. 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 9 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 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 10
Utvecklingsprocesser 11 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, 1972 12
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 Fler lösningar: Utveckla iterativt Dela upp projekt i delprojekt 13 Processer och processmodeller centrala begrepp Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 14
Utvecklingsprocesser - begrepp 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 15 Olika sorters aktiviteter i processer Specifikationsaktiviteter Utvecklingsaktiviteter Verifieringsaktiviteter Vidareutvecklingsaktiviteter Finns i alla processer, men kan komma i olika ordning etc. 16
Varför bra att fokusera på processer? Koppling processkvalitet produktkvalitet Gemensamt för flera projekt Ramverk för organisatoriskt lärande 17 Processmodeller Aktivitetsorienterade, t ex Möjlighetsstudie Kravinsamling Design Implementation Testning Resultatorienterade, t ex Testrapport Kod Design Kravspecifikation Möjlighetsrapport 18
Att ha med i en processmodell Aktiviteter Processer en serie steg med gemensamt mål Leverabler Villkor startvillkor, slutvillkor Roller Informationsvägar Undantag 19 Exempel Requirements Planning Plan Design Scripts Code Process Aktivitet Guide Compile Test Postmortem Finished product Defects Time Logs Results Project Plan Summary Leverabel 20
Ett exempel till 21 Några kända exempel på processer på olika nivåer Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 22
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. Fas 1 Specifikation Kravspecifikation Projektplan Fas 2 Design Testplan Designdokument Fas 3 Implementation och enhetstest Exekverbar källkod Fas 4 Systemtest Dokumenterat genomförda systemtest
0.x Good version Individual inspection Inspection meeting Inspection protocoll 0.99 Better version Supervisor review 0.0991 Supervisor feedback 1.0 Acceptanstest (VoV) Kravhantering Systemtest (Verifiering) Design Integrations-test Implementation Enhetstest Aktör A Meddelande Media Meddelande Aktör B Återkoppling
Många olika processmodeller för utveckling 27 Vattenfallsmodellen Requirements specification Design Implementation Unit test Integration System test Maintenance 28
V-modellen - vattenfall med återkoppling Drift & underhåll Mål Acceptanstest Kravhantering Systemtest Design Integrationstest Implementation + enhetstest 29 Vattenfallsmodellen: Problem Kraven kan sällan frysas: Flexibilitet är ett av motiven för programvara hårdvara hinner utvecklas under långa projekt Big bang-integration sällan framgångsrik Ökar risk för nice-to-have bland kraven för säkerhets skull... Kostnaden för att underhålla dokument (som kanske inte ger kundnytta) är hög 30
Evolutionär utveckling Utkast Utvecklingsprocessen (vidareutv. eller prototyputv) Slutgiltig version Versioner för kommentarer Kund / användare 31 Två varianter av evolutionär utveckling 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 32
Timeboxing 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 TB3 33 Timeboxing ett verkligt exempel 34
Spiralmodellen 35 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 36
Diskutera Ge exempel på projekt när följande processer är lämpliga Vattenfallsmodellen Prototyper Inkrementell utveckling med kontinuerliga releaser R D C T R D C T R D D T Release T Release Release Prototyp D T Rel R D C T Release 37 Lättrörliga processer (agile) 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 38
XP Practices Planning Game Small Releases Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-hour week On-site Customer Coding Standard 39 Processer för hela företaget Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F5 40
Processer på företagsnivå Processer Processmodeller Processförbättring Projektstyrning Organisationsprocesser Projektstyrningsprocesser Utvecklingsprocesser V-modell, prototyping, XP...? 41 Projektstyrningsprocess PS: Planering Uppföljning och styrning Post mortem Utv: Utvecklingsprocessen = mätvärden = styrning Vad ingår i pilarna? 42
Olika sorters processer Process Produktutvecklingsprocess Process för utveckling av processer Projektledningsprocess Utvecklingsprocess Kravprocess Mer generella CM-process Testprocess Granskningsprocess 43 Processmodell för kursen på hög nivå Faser och leverabler Kravspecifikation Fas 1 Specifikation Projektplan Testplan Fas 2 Design Designdokument Fas 3 Implementation och enhetstest Fas 4 Systemtest Exekverbar källkod Dokumenterat genomförda systemtest 44
Processer för att utveckla och anpassa processer 45 Utveckling av processer Anpassning Organisation Projekt Erfarenhet 46
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 47 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. 48
Processer lösning på allt? År 1969: NATO-konferens myntade begreppet Software Engineering År 1987: No silver bullet! Frederick Brooks, No Silver Bullet Essence and Accidents of Software Engineering, IEEE Computer, April 1987. 49 Vad händer efter release? Legacy Systems 50
Legacy system 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. 51 Legacy systems Kan vara affärskritiska Kan vara gamla (ibland > 20 år) Innehåller: Applikationsprogram (flera?) Data (mycket data i flera filer, udda format) Affärsprocesser Prog A Prog B Prog C Prog D 52
Hur använder vi och underhåller legacy system? 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 Prog C Prog D 53 Lehmans Lagar (1985) 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. Organisatorisk stabilitet Utvecklingshastigheten blir konstant oberoende av resurser. 54
Release planning Underhåll efter release Kräver Ändringshantering Konfigurationshantering Påverkansanalys Spårbarhet Regressionstest Delivery Change request Impact analysis Man skiljer mellan: Felrättande (Corrective) Anpassande (Adaptive) Förbättrande (Perfective) Preventivt (Preventive) Verification Implementation 55 Sammanfattning - processer 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 56
Vecka 6 Stora system + och sedan då... Kravhantering Programvarutestning Objektorienterad modellering och design Design Konfigurationshantering Projektplan Test Ingengörsprocessen - ekonomi och kvalitet Krav Kod Binär Utvprocess Programvaruutveckling i grupp Coaching av programvaruteam Programvaruutveckling för stora system 57