Diskutera medan vi väntar. Detta har hänt... Agenda. Föreläsning 5: Processer och vidareutveckling. Kan man utveckla programvara

Transkript

1 Diskutera medan vi väntar Kan man utveckla programvara täckning på olika sätt? beslut Föreläsning 5: Processer och vidareutveckling Detta har hänt... Agenda 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? 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

2 Kursinformation Projektbeskrivning avsnitt 8: - korthet Vad händer i maj/juni? Nu är det vecka 20 -> slutinlämning om 11 dagar...uppfyller följande kriterier: 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 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 V 23: må-ti: Hemtentamen Före midsommar: Återkoppling på projekt och projektbetyg Resultat från hemtentan 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 Software Engineering bakgrund: The Software Crisis Utvecklingsprocesser 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,

3 Lösning: Ordning och reda Stora subprocesser i ingenjörsprocessen 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 Processer i ingenjörsprocessen täckning beslut Processer och processmodeller - centrala begrepp

4 täckning täckning beslut beslut täckning täckning beslut beslut Utvecklingsprocesser - begrepp Aktiviteter i alla processer Process: Det arbete som görs för att utveckla programvara Specifikationsaktiviteter Utvecklingsaktiviteter Processmodell: En beskrivning av processen Verifieringsaktiviteter Processförbättring: Arbetet med att förbättra processen Vidareutvecklingsaktiviteter Finns i alla utvecklingsprocesser, Utvecklings- process...men kan komma i olika ordning...med olika fokus etc Processmodeller Att ha med i en processmodell Aktiviteter Processer en serie steg med gemensamt mål Aktivitetsorienterade, t ex Möjlighetsstudie insamling Implementation Testning Resultatorienterade, t ex Möjlighetsrapport specifikation Kod Testrapport Leverabler Villkor startvillkor, slutvillkor Roller Informationsvägar Undantag Process, subprocess, aktivitet, procedur?

5 täckning täckning beslut beslut täckning beslut Processmodell - exempel Processmodell - exempel Requirements Planning Plan Startvillkor Modul kompilerad utan syntaxfel Roll Test- ingenjö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 Testmodul Process Signerad testrapport Testdata från modulen Leverabel Varför engagera sig i processer? Kvalitet Koppling processkvalitet - produktkvalitet Rationellt Gemensamt för flera projekt Organisationsutveckling Ramverk för lärande Många olika processmodeller för utveckling

6 täckning täckning beslut beslut täckning täckning beslut beslut Vattenfallsmodellen V-modellen - vattenfall med återkoppling Drift & underhåll specifikation Mål Implementation hantering Integration Implementation + enhetstest Vattenfallsmodellen: Problem Evolutionär utveckling 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 Utkast Rapport Test Utvecklingsprocessen Prototyputveckling, vidareutveckling? Test Behov Beslut Rapport Slutgiltig version Ökar risk för nice-to-have bland kraven för säkerhets skull... A B C D F Kostnaden för att underhålla dokument är hög - kundnytta? för kommentarer Kund / användare

7 täckning täckning beslut beslut täckning täckning beslut beslut Två varianter av evolutionär utveckling Timeboxing 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 Timebox 1 Timebox 1 Timebox 2 team Utveckling /impl Deploy TB1 TB2 TB3 /impl TB1 /impl Deploy /impl TB2 /impl Deploy /impl TB2 Drift Deploy TB1 Deploy TB2 Deploy TB Timeboxing ett verkligt exempel Spiralmodellen

8 täckning täckning beslut beslut täckning täckning beslut beslut Inkrementell utveckling Diskutera Parallell utveckling Tidiga leverabler Möjlighet att identifiera krav under utvecklingen Minskad risk Tidiga inkrement kan testas många gånger R D D D T T T Req Ge exempel på projekt när följande processer är lämpliga Vattenfallsmodellen Prototyper Inkrementell utveckling med kontinuerliga releaser Code Test R D C T Prototyp R D C T R D D D T T T Lättrörliga processer (agile) XP Practices 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 SCRUM Nightly build Crystal ASD FDD Planning Game Small s Metaphor Simple Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-hour week On-site Customer Coding Standard Mer om detta i Programvaruutveckling i grupp - projekt ETS

9 V-modellen för programvaruutvecking beslut täckning Exempel på processbeskrivningar från kursen 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 V-modellen för programvaruutvecking V-modellen för programvaruutvecking täckning 0.x Good version Exekverbar källkod Inspection protocoll 0.99 Better version Fk1 Fk2 Supervisor review Fkn Supervisor feedback Plattform v. k Fk+1.1 Fk Fk+1.m Plattform v. k Inspection meeting Dokumenterat genomförda systemtest Fas 4 Individual inspection Testplan beslut täckning dokument Fas 3 Implementation och enhetstest Fas 2 beslut specifikation Fas 1 Specifikation

10 täckning täckning beslut beslut täckning beslut hantering Implementation (Verifiering) Integrations-test (VoV) Processer för hela företaget Aktör A Meddelande Media Meddelande Aktör B Återkoppling Processer på företagsnivå Projektstyrningsprocess Processer Processmodeller Processförbättring Projektstyrning Organisationsprocesser Projektstyrningsprocesser PPS, PROPS, PRINCE...? = mätvärden = styrning Projektstyrningsprocess Planering Uppföljning och styrning Post mortem Utvecklingsprocessen Utvecklingsprocesser V-modell, prototyping, XP...? SCRUM? RUP? Beställare Spons IT- Slutanvänd Utvecklare Kundansva Projektled Utveckla Vad ingår i pilarna? Underleverantör Gränssnitt

11 täckning beslut täckning täckning beslut beslut Olika sorters processer Processmodell för kursen på hög nivå Process Produkt- utvecklingsprocess Process för utveckling av processer Faser och leverabler Fas 1 Specifikation specifikation Aktivitetseller resultatorienterad? Testplan process Utvecklingsprocess Testprocess CM-process sprocess Projektledningsprocess Mer generella Fas 2 Fas 3 Implementation och enhetstest Fas 4 dokument Exekverbar källkod Dokumenterat genomförda systemtest Processer för att utveckla och anpassa processer 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

12 täckning beslut täckning täckning beslut beslut Skillnad: Verklig process vs. referensprocess? Processer lösning på allt? Referensprocess en process som man vill använda År 1969: NATO-konferens myntade begreppet Software Engineering 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. År 1987: No silver bullet Frederick Brooks, No Silver Bullet Essence and Accidents of Software Engineering, IEEE Computer, April Vad händer efter release? Legacy Systems 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

13 täckning täckning beslut beslut täckning täckning beslut beslut Legacy systems Hur använder vi och underhåller legacy system? Kan vara affärskritiska Rätta fel i kod Prog A Prog B Kan vara gamla (ibland > 30 år) Prog A Prog B Rätta fel i krav och design Förbättra design Förbättra programmen Prog C Prog D Innehåller: Prog C sprogram (flera?) Data (mycket data i flera filer, udda format) Affärsprocesser Prog D Koppla samman med andra system Konvertera program så att ny hårdvara, kommunikationssystem etc kan användas Avveckla system Lehmans Lagar (1985) efter release 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. 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

14 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