Diskutera medan vi väntar

Transkript

1 Diskutera medan vi väntar Kan man utveckla programvara täckning på olika sätt? beslut 226 Föreläsning 5: Processer och vidareutveckling Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 227

2 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? 228 Agenda Kursinformation Om slutbedömning av projekt Utvecklingsprocesser Utvecklingsprocesser vad är det och vilka typer finns? Processledning, processförbättring Vad händer sedan: - Vidareutveckling - Legacy-system 229

3 Kursinformation Nu är det vecka 20 -> slutinlämning om 11 dagar V 20: Må kl 10 F: Utvecklingsprocesser, vidareutveckling, om tentamen V 21: Må kl 15 F: Om tentamen, sammanfattning, utvärdering Fr kl 24: Slutleverans projekt V 23: må-ti: Hemtentamen Före midsommar: Återkoppling på projekt och projektbetyg Resultat från hemtentan 230 Projektbeskrivning avsnitt 8: - korthet Vad händer i maj/juni?...uppfyller följande kriterier: Levererad programvara uppfyller projektets kravspecifikation. Testas med projektets testfall + egna test specifikationens och testplanens kvalitet är god. Kontrolleras med checklistor och projektets granskningar. Det är särskilt viktigt att de testbara kraven adresseras av minst ett testfall. Projektets betyg baseras på samtliga dokument 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 och installationsmanual. verifiering av ändringshantering konsistens mellan slutversionerna av krav, design, test och applikation. 231

4 Utvecklingsprocesser Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 232 Software Engineering bakgrund: The Software Crisis Försenade projekt [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 Många fel i levererade produkter Projekt som fick avbrytas Stora kostnader Produkter som bara blir större och större 233

5 Lösning: 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 234 Stora subprocesser i ingenjörsprocessen 235

6 Processer i ingenjörsprocessen täckning beslut 236 Processer och processmodeller - centrala begrepp Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 237

7 täckning täckning beslut beslut 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 Utvecklings- process 238 Aktiviteter i alla processer Specifikationsaktiviteter Utvecklingsaktiviteter Verifieringsaktiviteter Vidareutvecklingsaktiviteter! Finns i alla utvecklingsprocesser,...men kan komma i olika ordning...med olika fokus etc. 239

8 täckning täckning beslut beslut Processmodeller Aktivitetsorienterade, t ex Möjlighetsstudie insamling Implementation Testning Resultatorienterade, t ex Möjlighetsrapport specifikation Kod Testrapport 240 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? 241

9 täckning täckning beslut beslut Processmodell - exempel Requirements Planning Plan Scripts Code Process Aktivitet Guide Compile Test Postmortem Finished product Defects Time Logs Results Project Plan Summary Leverabel 242 Processmodell - exempel Startvillkor Modul kompilerad utan syntaxfel Roll Test- ingenjör Stoppvillkor Alla definierade test går igenom Input Modulspecifikation Ansvarig för Testmodul Process Output Signerad testrapport Testdata från modulen 243

10 täckning beslut Varför engagera sig i processer? Kvalitet Koppling processkvalitet - produktkvalitet Rationellt Gemensamt för flera projekt Organisationsutveckling Ramverk för lärande 244 Många olika processmodeller för utveckling Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 245

11 täckning täckning beslut beslut Vattenfallsmodellen specifikation Implementation Integration 246 V-modellen - vattenfall med återkoppling Drift & underhåll Mål hantering Implementation + enhetstest 247

12 täckning täckning beslut beslut Vattenfallsmodellen: Problem en 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 är hög - kundnytta? 248 Evolutionär utveckling Utvecklingsprocessen Prototyputveckling, vidareutveckling? Utkast Rapport Test Test Behov Beslut Rapport Slutgiltig version A B C D F för kommentarer Kund / användare 249

13 täckning täckning beslut beslut 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 Utmaningar Svag insyn Kan ge dålig struktur Höga krav på utvecklarna 250 Timeboxing Timebox 1 /impl Deploy Timebox 1 /impl Deploy Timebox 2 /impl Deploy team TB1 TB2 TB3 Utveckling /impl TB1 /impl TB2 /impl TB2 Drift Deploy TB1 Deploy TB2 Deploy TB3 251

14 täckning täckning beslut beslut Timeboxing ett verkligt exempel 252 Spiralmodellen 253

15 täckning täckning beslut beslut Inkrementell utveckling Parallell utveckling Tidiga leverabler R Möjlighet att identifiera krav under utvecklingen D T Minskad risk D T Tidiga inkrement kan testas många gånger D T 254 Diskutera Ge exempel på projekt när följande processer är lämpliga Vattenfallsmodellen Prototyper Inkrementell utveckling med kontinuerliga releaser Req Code R D C T R D D T T Test Prototyp R D C T D T 255

16 täckning täckning beslut beslut 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 XP DSDM FDD SCRUM Crystal Nightly build ASD 256 XP Practices Planning Game Small s Metaphor Simple Testing Pair Programming Collective Ownership Continuous Integration 40-hour week On-site Customer Refactoring!! Coding Standard Mer om detta i Programvaruutveckling i grupp - projekt ETS

17 täckning beslut Exempel på processbeskrivningar från kursen Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 258 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 259

18 täckning täckning beslut beslut Fas 1 Specifikation specifikation Fas 2 Testplan dokument Fas 3 Implementation och enhetstest Exekverbar källkod Fas 4 Dokumenterat genomförda systemtest F k1 F k2 F kn Plattform v. k F k+1.1 F k+1.2 F k+1.m Plattform v. k x Good version Individual inspection Inspection meeting Inspection protocoll 0.99 Better version Supervisor review Supervisor feedback

19 täckning beslut (VoV) hantering (Verifiering) Integrations-test Implementation Aktör A Meddelande Media Meddelande Aktör B Återkoppling 262 Processer för hela företaget Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 263

20 täckning täckning beslut beslut Processer på företagsnivå Organisationsprocesser Processer Processmodeller Processförbättring Projektstyrning Projektstyrningsprocesser PPS, PROPS, PRINCE...? Utvecklingsprocesser V-modell, prototyping, XP...? SCRUM? RUP? 264 Projektstyrningsprocess Projektstyrningsprocess Planering Uppföljning och styrning Post mortem = mätvärden! = styrning Utvecklingsprocessen Beställare Utvecklare Spons Kundansva Slutanvänd IT- Projektled Utveckla Vad ingår i pilarna? Underleverantör 265 Gränssnitt

21 täckning täckning beslut beslut Olika sorters processer Process Produkt- utvecklingsprocess Process för utveckling av processer process Utvecklingsprocess CM-process Projektledningsprocess Mer generella Testprocess sprocess 266 Processmodell för kursen på hög nivå Faser och leverabler Fas 1 Specifikation Fas 2 specifikation Testplan dokument Aktivitetseller resultatorienterad? Fas 3 Implementation och enhetstest Exekverbar källkod Fas 4 Dokumenterat genomförda systemtest 267

22 täckning beslut Processer för att utveckla och anpassa processer Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 268 Processförbättringsprocess Identifiera förbättringar Processmodell Bestäm förbättringar Ändringsplan, utbildningsplan Introducera ändringar Återkoppling Finjustera processen Uppdaterad processmodell GOTO 1 Organisation Anpassning Erfarenhet Projekt 269

23 täckning täckning beslut beslut Skillnad: Verklig process vs. 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 observerad process. 270 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

24 Vad händer efter release? Legacy Systems Ingenjörsprocessen metodik ETSA01 VT14 Jonas Wisbrant 272 Legacy system beslut täckning 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. 273

25 Legacy systems Kan vara affärskritiska Kan vara gamla (ibland > 30 år)!! Prog A Prog B Innehåller: Prog C sprogram (flera?) Data (mycket data i flera filer, udda format) Affärsprocesser Prog D 274 Hur använder vi och underhåller legacy system? beslut täckning beslut täckning 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 Prog C Prog B Prog D Konvertera program så att ny hårdvara, kommunikationssystem etc kan användas Avveckla system 275

26 täckning beslut täckning beslut 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. 276 efter release Kräver Ändringshantering Konfigurationshantering Påverkansanalys Spårbarhet Regressionstest Man skiljer mellan: Felrättande (Corrective) Anpassande (Adaptive) Förbättrande (Perfective) Preventivt (Preventive) Delivery Verification Change request Impact analysis Implementation 277

27 täckning beslut 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 har 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 278