Detta har hänt... Pratat krav Bildat projektgrupper :-) Skaffat litteratur? Kommit igång med projektwikin: Formulerar krav Genomfört en övning: Hur var den? ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 2: Projekt, Kravhantering, Dokumentgranskning Jonas Wisbrant 2 Agenda Kursinformation Kursinformation Projektet, wikin och deadlines Kursombud Mer om projekt Mer om kravhantering Dokumentgranskning V 2: Måndag: Nu Tisdag kl 24: Deadline Kravspecifikation 0.x Till övning to: 3 OBS! Grupp 17-26 har övning i E:A på torsdag P1-6 I:1 Granska ABC- video Fråga: När ska ni ha granskningsmöte Man kan även lägga upp en PDF-fil och länka till den V 3: Måndag kl 13 F: Testning Måndag kl 24 deadline: Granskningsprotokoll + Kravspecifikation 0.99 Granskningsprotokoll + Projektplan 0.99 4
Inlämning nästa tisdag kl 24: Kravspec 0.x Kursinformation forts Projekt i IP3: Ska föreslå förbättingar i utvecklingsprocessen inför en tänkt vidare utveckling av systemet... De kanske kontaktar er Har egen sida i projektwikin Kan göra anspråk på typ 2 h per projektmedlem + enligt ök Projekthandledarna vill veta: Dokumentet är påbörjat och innehåller tänk Återkoppling via mail & övning 6 7 Inlämning måndag v3 kl 24: Krav 0.99 Utse kursombud } granskning krav Plan 0.99 Påbörjad manual Möten To 2011-03-31 kl 12.30 i LUCAS-rummet (E:4130) Må 2011-0-09 kl 12.30 i LUCAS-rummet (E:413 Återkoppling Beslut: granskning plan Innehåll Form (C) (C) (D) (D) Korrigering Krav 1.0 Plan 1.0 (I) Ändringshantering 8 9
Tre meddelanden från webbformulären :-) Tydliggör kontextdiagram (boken suger där..) Omvärldens kommunikation med systemet på en ganska hög nivå Märklig matte i Avancerad checklista för granskning av kravspecifikation: Har inte hunnit titta på det... Nu vet vi hur vi formuerar funktions- och kvalitets-krav. Men... krav Hur hittar vi, analyserar och dokumenterar krav krav krav Hur ska vi prioritera? Process enligt wikipedia En samling i förväg uttänkta aktiviteter som ska användas varje gång man skapar ett visst resultat... Dataflödesdiagram krav Hur säkerställer vi att vi förstått? Course Webb feedback P4: Figur 4.3 kommer över texten i Crome Åtgärdat Kravhanteringsprocessen 11 ER-diagram - Entity Relationship Data lagras i systemet (entitet + attribut), t ex: Student: pnr, namn, inskrivningsår Kurs: kurskod, namn, #hp Program: beteckning, namn 1 n Student Program Följer Används ofta för att modellera data i databaser n n Läser Ingår på n * = AND + = OR Kurs 12 n 13
Naturligt språk Delar i en kravspecifikation Fördelar: Generellt Flexibelt Lätt att använda och förstå Nackdelar: Otydligt Lätt att blanda olika sorters krav Lätt att slå samman flera krav i ett Table of contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1. Overview 2. General Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2. Assumptions and Dependencies 3. Specific Requirements Appendix Index [IEEE Guide to Software Requirements Specifications, ANSI/IEEE Std 830-1984] 14 Spårbarhet 1 Kravvalidering Från krav till källan till krav Kontrollera att kravspecifikationen är korrekt och av hög kvalitet Exempel på metoder: Granskning (vanligast) Utveckla testfall Verktygsstöd för formellt skrivna krav Mellan krav (visar beroende) Från design och kod till krav Från testfall till krav 16 17
Tidiga faser är viktiga Bra egenskaper hos en kravspecifikation Korrekt Komplett Otvetydig Verifierbar Konsistent Prioriterad Genomförbar Modifierbar Spårbar [Alan Davis] 18 Granskningslista för kursens projekt 19 Kravprioritering 1. Saknas några krav? 2. Är samtliga krav nödvändiga? Omöjligt att implementera alla bra idéer! 3. Finns det några motstridiga krav? Jämför krav med avseende på Värde för kund Kostnad att implementera Ledtid att implementera Risk Värde för nya kunder 4. Kan samtliga krav verifieras?. Är samtliga krav tydligt formulerade eller kan några krav misstolkas? 6. Finns samtliga nödvändiga definitioner? 7. Är det möjligt för dokumentets målgrupp att förstå dokudokumentet begripligt för sin målgrupp? 8. Följer kravspecifikationen sin dokumentmall? 9. Är något krav formulerat för detaljerat?.har något krav formulerats på för hör abstraktionsnivå? 11.Är någon text eller illustration nödvändig Guidat alternativ 12.Har samtliga krav unika identifierare? 20 21
Exempel, prioritering Krav och projekt i ett större perspektiv Björn Regnell kommer F6 Produktledning 13 Plattform Värde 6 Krav Design Impl Test 1 4 2 3 7 8 9 11 12 14 Produkter Kostnad 22 Krav Krav Krav Design Impl Design Impl Design Impl Test Test Test 23 Sammanfattning - Krav Kravhantering viktigt eftersom tidiga faser påverkar mycket Krav kan finnas på olika abstraktionsnivåer Kvalitetskrav beskriver kvalitetsattribut och påverkar hela produkten Kravhanteringsprocessen: identifiering, analysering, dokumentering, validering Viktiga attribut: korrekt, komplett, otvetydig, verifierbar, konsistent, prioriterad, genomförbar, modifierbar, spårbar ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Om projektplanering och projektplaner Spårbarhet viktigt: källa > krav, krav > krav, krav -> design/ kod Krav är en viktig del i arbetet med produktledning och produktplanering Mer om krav i Kravhantering (ETS170) 24 2
Diskussion: Förklara för varandra Signaler i projektet Vad är det för skillnad mellan projektets: Affärsmål Projektmål Produktmål? Behov Idéer Visioner Förväntningar Krav Avtal Plan Data Specifikationer Pengar Protokoll Beslut Förslag Prototyper Frågor Förtydliganden System Testresultat Acceptans Aktör A Meddelande Media Meddelande Aktör B Återkoppling 27 Kommunikation i projektet över tiden Beställarens projekt Visioner & krav Specifikation & plan Bekräfta System Godkänna Utvecklarens projekt Typiskt innehåll i en projektplan Inledning: projektmodell, utvecklad produkt, målsättningar, begränsningar Projektorganisation: utvecklingsorganisationen, andra intressenter Hårdvara och programvara som krävs för projektets genomförande Arbetsnedbrytning: aktiviteter, leverabler, milstolpar Tidplan: när varje aktivitet påbörjas och avslutas, när varje milstolpe ska uppnås Uppföljning och rapportering: hur detta ska ske? Riskanalys Aktör A Meddelande Media Återkoppling Meddelande Be Aktör B Visio Spec Bekr Syst God Ut 29
Fyra viktiga delområden inom projektplanering Underleverantör Intressent analys (stakeholders) Vad vill varje intressent? Intressentanalys Utvecklare Beställare Konflikter? Kundansvarig Sponsor Kostnadsskattning Projektledare IT-funktion September Schemaläggning October November Date finished (2007) 7 september 21 September 21 September 20 October 20 October 20 October 9 November 16 November 16 November 23 November 23 November Project planning Requirements definition Milestone 1 Test planning High-level design Milestone 2 Implementation and unit testing Integration and system building Milestone 3 System testing Milestone 4 Slutanvändare Utvecklare Underleverantör Riskhantering Gränssnitt 30 Kostnadsskattning 31 Schemaläggning Aktivitetsnätverk för kritisk väg Persontid viktigaste (dvs dyraste) faktorn Alltid svårt att veta, men viktigt ändå Olika angreppssätt Aktivitet A1 Tid (d) Beroenden A2 A3 A1 A4 2 A3 A A6 Expertbedömning Algoritmiska modeller 1 1 A A6 start A1 2 A3 A4 slut A2 A3, A Gantt-diagram 32 September October Project planning Requirements definition Milestone 1 Test planning High-level design Milestone 2 Implementation and unit testing Integration and system building Milestone 3 System testing Milestone 4 universitet / LTH / Datavetenskap / ETSA01 VT 20 / F1 Lunds November 33 Date finished (2007) 7 september 21 September 21 September 20 October 20 October 20 October 9 November 16 November 16 November 23 November 23 November
Riskhantering Frågor om typiskt innehåll i en projektplan? Riskprocess Sannolikhet Inledning: projektmodell, utvecklad produkt, affärsmål, begränsningar hög Projektorganisation: utvecklingsorganisationen, andra intressenter Strategier låg låg [1] Risk Konsekvens hög [] Reducera konsekvens Minska risk Alternativ (plan B) Arbetsnedbrytning: aktiviteter, leverabler, milstolpar Tidplan: när varje aktivitet påbörjas och avslutas, när varje milstolpe ska uppnås S K Prio (S x K) Strategi Hårdvara försenad 2 Ont om persontid 4 2 8 Undersöka alternativ Konstruera simulator Minska scope Strulig beställare 1 Andas... Lunds universitet / LTH / Datavetenskap / ETSA01 VT 20 / F1 Hårdvara, programvara och andra resurser som krävs för projektets genomförande 34 Uppföljning och rapportering: hur detta ska ske? Riskanalys 3 Sammanfattning projektplanering Programvaruprojekt speciella eftersom de är en av, komplexa, och eftersom det går att ändra sent Projektplanen beskriver t ex projektorganisation, arbetsnedbrytning, tidplan och riskanalys, mm. ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Dokumentgranskning Kostnadsskattning kan göras baserat på expertbedömningar eller algoritmiska modeller (statisk testning) Riskhantering sker i fyra steg: identifiera risker, bedöm risker, behandla risker, följ upp risker 36 37
Granskningar grundläggande idé Läs dokument på ett strukturerat sätt Hitta fel tidigt utan att exekvera kod dvs statisk testning Hitta felet (fault) direkt utan debugging Alla dokument kan granskas (krav, test, design, kod, testfall, ) Rätt personer ska läsa Personerna ska läsa på rätt sätt Alla viktiga delar av dokumenten ska läsas Granskningsprocessen Planering ABC-video: Krav & plan: Roller Moderator Författare Sekreterare Granskare Individuell granskning Nu ti/on to Introduktion Granskningsmöte Omarbete Uppföljning?????? före nästa MS1 måndag 24 Test & design:?????? före 3/ MS2 Tips: Planera in det mötet idag! - - 38 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 20 / F1 39 Lästekniker (individuell granskning) Några exempel på siffror Ad-hoc Upp till granskaren Checklist-baserad Stöd av en checklista Kan t ex ha tagits fram av organisationen Antal personer på ett granskningsmöte: 4- Mängd material [Ebenau, et.al., Software Inspection Process]: Krav: sid/h Design: 4 sid/h Kod: LOC/h (utan kommentarer) Testplan: 4 sid/h Scenario-baserad Följ ett användningsscenario under granskningen Perspektiv-baserad Granska som en specifik roll (användare, testare, operatör, utvecklare, etc) 40 41
Hur många lejon finns det i skogen? Med två granskare A N = totalt antal fel (som man vill veta) NA = antal fel som granskare A hittar NB = antal fel som granskare B hittar NAB = antal fel som båda hittar B Andel som granskare A hittar = NAB/NB Andel som granskare A hittar = NA/N NA/N = NAB/NB --> N = NA* NB/NAB Lejonen kan vara fel och jägarna kan vara granskare 42 Sammanfattning - Granskning 43 Att göra inför övning 2 Systematisk metod för att identifiera problem i material som inte kan exekveras Tar tid men lönar sig i allmänhet Disdag kl 24: Deadline P.1-6 Risker och intressenter Måndag v3: I:1: Granska ABC-video inför granskningsmöte Under stabila förhållanden kan man uppskatt hur många fel som finns kvar Föreläsning om testning x deadline ETSA 01 Ingen jörsp roces sen - Meto dik Gran sknin gsko mm Granskning är bra Pos ition Che ckli punkt ste- Kom entar er menta r OBS! Grupp 17-26 har övning i E:A på torsdag 44 Lunds universitet / LTH / Datavetenskap / ETSA01 VT 20 / F1 4
Frågor om projekt som sådana? kursprojektets projektplan? kursprojektets kravspecifikation? 46