Streamade föreläsningar på webben

Transkript

1 Medan vi väntar: Diskutera Om man utvecklar ett system... Vad kan gå fel? Vad brukar gå fel? Varför då? Vad kan man göra åt det?... samt notera kurswebben: samt köp kurskompendium för 50;- Streamade föreläsningar på webben Synligt inom LU Vänligen sprid inte filmerna! Ni bör inte synas Skicka gärna frågor om innehåll via formuläret! Möjligen nacken på 2-3 främre rader Ni kan komma att höras Säg till om jag ska klippa bort ljud 2

2 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 1: Kursen & Projektuppgift Utvecklingsprojekt & Kravhantering Jonas Wisbrant 3 Utmaning Kan man förstå software engineering utan att ha upplevt stora programvaruprojekt? Kan man förstå vad som händer i stora programvaruprojekt utan att ha studerat software engineering? 4

3 Jonas Wisbrant - kort CV Samhällsvetare vid LU Kommunikation och webbutveckling Programvaruingenjör LTH i Helsingborg Institutionen för Datavetenskap LUCAS - Center for Applied Software Research Diverse undervisning Det Norske Veritas 2008 Institutionen för Datavetenskap EASE / Programvaruportalen / kommunikation Datorer i System Ingenjörsprocessen Datavetenskap + LU webb Agenda F1 Kursen & projektuppgiften Vad är ett utvecklingsprojekt Kravhantering: Vad är ett krav? Hur hittar vi dem? Hur vet vi att de är bra? I pausen: Bilda projektgrupper och köpa kompendier Att göra inför övning 1 kl i E:3308 Wiki-intro för C och I 6

4 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Kursen Kursen Innehåll Projektplanering Kravhantering Arkitekturdesign Testning Modeller av utvecklingsprocessen för programvara 7 Formalia 5 hp Obligatorisk för C1, D1, alternativobligatorisk för IE3 Moment - Föreläsningar Övningar Övningar Föreläsning Projekt Projekt Hemtentamen Hemarbete Del 1 av 3 kurser Vi genomför ett utvecklingsprojekt under rimligt ordnade former och belyser det med teori och reflektioner. 8

5 Kurslitteratur Bok Pankaj Jalote, A Concise Introduction to Software Engineering, Springer, J: 6.2-5, kursivt Kompendium Examples and Exercises in the Software Engineering Process, Säljs av institutionen för 50;- ETSA01: Ingengörsprocessen metodik VT 2011 Tidplan v 1.0 V3 (28/3-1/4) V2 (21-25/3) V1 (14-18/3) Detta dokument kan komma att uppdateras under kursen! Dag Aktivitet Innehåll Läsa Må F1 Kursöversikt, kravhantering, projektplanering, gruppindelning Introduktion till projektwiki för C1&I (E:3308) Kravhantering: Kravkriterier, Kvalitetskrav, Use-Case, relationen mellan USE-case och skall-krav. J: 1, 3, 4 Må To Ö1 Må F2 Ti I To Ö2 Översiktligt: J 3-4 K: Detaljerat: J: Kravhantering, Granskning, Projektplanering Kravspecifikation 0.x J: 3, 4, 7.5 Projektplanering: Intressentanalys, Affärsmål, projektmål, produktmål Riskanalys, riskkategorier, uppställning Dokumentgranskning (inspection) Testning J: 4.1 J: J: 7.5 Må F3 Må I Kravspecifikation 0.99, Projektplan 0.99, granskningsprotokoll från intern granskning av de versioner som föregick 0.99orna. Manual 0.1 To Ö3 Ändringshantering Testplanering, Systemtest Må F4 Arkitektur, design, kodning, versioner Ti kl I MS1 Uppdaterade krav och plan som Kravspecifikation 1.0 och Projektplan 1.0 To Ö4 Test forts. Design Må F5 Må kl I MS2 9 Förklaring J = Jalote, Pankaj K = Kurskompendium A = Övning på kurswebben P = Projektbeskrivning på kurswebben Gör i förväg Händer på plats A: R kl Projektåterkoppling Diskussion: A: R.1-6 Göra: A: R.7-10 A: P.1-5 A: I.1 Att wikin är igång och dokument är upprättade och påbörjade. Kort återkoppling på kravspecifikationen Diskussion: A: P.1-6 Göra A: I.2-3 J: 8 A: T.1-8 Att krav, plan och granskningsprotokoll är av tillräcklig kvalitet för att milstolpe 1 ska kunna passeras. Att manualen beskriver de viktigaste scenarierna. Återkoppling Kravspecifikation 0.99 och Projektplan 0.99 Diskussion: A:T.1-8 V4 (4-8/4) Göra: A: T J: 5, 6, 7 A: T.9-11 Diskussion: A: T.9-11 V5 (11-15/4) Göra: A: T.9-14 Lunds universitet / LTH / To Ö5 Utvecklingsprocesser, vidareutveckling, J: 2 om tentamen Testplan 1.0, Design 1.0, Datavetenskap / ETSA01 VT 2010 / F1 Granskningsprotokoll från granskningar inför Testplan 1.0 och Design 1.0 Inför tentamen De 4 dokumenten används 10 tillsammans med A: HE.1 versionshistoriken som bas när projektets slutleverans bedöms. Göra A: HE.2-3 Övergripande återkoppling på Diskussion A: HE.2-3 Testplan 1.0 och Design 1.0

6 Examination Projektarbete 26 timmar hemtenta 26-27/5: U3 Kravgranskning (10 av 60 p) Beskriv hur en kravgranskning går till och förklara målsättning, varför denna typ av granskning är viktig, vem som bör delta, samt vilka typer av fel man bör leta efter. Diskutera vilka svårigheter som finns då man vill införa denna typ av granskningar i en organisation samt ange tänkbara lösningar på dessa problem. Ange också om det finns några alternativ till denna typ av granskning och vilka dessa i så fall är. 11 Hälsningar från förra årets studenter Kursboken kan upplevas som svår Projektet innebär att man ofta känner osäkerhet Det är viktigt att alla i projektgruppen har koll på tidplanen (vem, vad, när) Nytt och obeprövat i kursen Mycket material från kompendium --> kurswebben nu på svenska Modifierad projektuppgift (manualer) Modifierade övningar Modifierad wikistruktur Ny server-lösning för filmerna 2v-påsk-3v-bygg ---> 5v-påsk&bygg 12

7 Bilda projektgrupper och köp kompendium i pausen Skriv upp dig på en av grupperna Alla grupper ska ha sex deltagare. Grupp XX Deltagare (namn) Program Lisa Larsson D1 Kalle Karlsson IE3 E:0522 Notera grupp och övningslokal Köp kompendium 13 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Projektuppgiften 14

8 Projektuppgiften Leverabler Arbeta i grupper om 6 personer Genomför utvecklingsprojekt från början till slut Kravidentifiering och kravanalys Projektplanering Design och implementation Testning Leverans Kravspecifikation Projektplan Testplan & testspecifikation Granskningsrapporter Designdokument Manual Testrapporter Exekverbar applikation Plattformar Moinwiki för dokumenten Java/swing för programvaran 15 Uppgift: Programmera ett cykelgarage Uppdrag Faser och leverabler Målmiljö Kravspecifikation = barcode reader Operator = electronic lock Barcode printer PC = pincode terminal Fas 1 Specifikation Projektplan Testplan Fas 2 Design Extra exit door Bicycle garage Entry door Designdokument Fas 3 Implementation och enhetstest Exit door Fas 4 Systemtest Utvecklingsmiljö Aktörer Dokumentmiljö Projekthandledare Projektgrupp QA från IP3 Exekverbar källkod t genomförda systemtest

9 Kick-start: Etablera projektgrupper senast i pausen 156 personer --> 26,16 Första deadline om 201,5 h 26 grupper Anmäl dig på anslagna lappar i senast i pausen Kursledningen fördelar de som inte anmält sig Grupperna är igång på TORSDAG KL 8. Har konto i projekt-wikin Har förbrett Övning 1! Har läst in sig på projektuppgiften Nästa tisdag kl 24 är det första dokumentet inlämnat 17 Projektwikin Självförklarande ;-) Läsrätt: egen grupp QA-grupp från IP3 kursledning (med automatik) 18

10 Wiki-intro för C och I kl i E: ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Om utvecklingsprojekt Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F1 20

11 Om man utvecklar ett system... Vad kan gå fel? Vad brukar gå fel? Varför då? Vad kan man göra åt det? Hur svårt det är att koka pasta beror på om man gjort det förut... och var man börjar 22

12 Projekt är något mer eller mindre unikt Från beställares synvinkel: en investering som ska gå med vinst avstämningspunkter för att se om det går som man tänkt sig Från utförares synvinkel: en teknisk uppgift som ska bli klar i tid avstämningspunkter för att visa att man klarar att utföra uppgiften UTMANING: Vi bygger inte ytterligare ett hus, gipsar nästa ben eller kokar pasta igen vi gör innovation on demand 23 Utvecklingsprojekt vs. en-gång-till-projekt Likheter Planering och uppföljning Samarbete och kommunikation... Skillnader Hög komplexitet Kan ändra sent... Utvecklingsprojekt är något som man gör när man inte vet från början exakt hur det ska gå till 24

13 Ska vi börja med projektplanen eller kravspecifikationen? Kravspecifikation Fas 1 Specifikation Beroende av varandra Projektplan Testplan Fas 2 Design Designdokument Fas 3 Implementation och enhetstest Exekverbar källkod Kraven är en del av produkten. Sista versionen måste sparas. Planen hör till organisationen. Erfarenheterna bör sparas. t genomförda systemtest Fas 4 Systemtest 25 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Om kravhantering 26

14 Agenda Krav Definition, olika sorter Kravhanteringsprocessen identifiera analysera dokumentera validera 27 Top 10 challenges Standish Group Survey Chaos Report (1994) Top 10 Challenges 1. Lack of User Input 2. Incomplete Requirements 3. Changing Requirements 4. Lack of Executive Support 5. Technology Incompetence 6. Lack of Resources 7. Unrealistic Expectations 8. Unclear Objectives 9. Unrealistic Time Frames 10. New Technology Om man utvecklar ett system... Vad kan gå fel? Vad brukar gå fel? Varför då? Vad kan man göra åt det? [Standish Group, 1995] 28

15 Vad är ett krav? Idé Önskemål Begränsning Behov Funktion Måste Produktegenskap Underlag för test Lönsam Investering Kontrakt Beslut 29 Olika abstraktionsnivåer 30

16 Olika sorters krav Funktionella krav Beskriver vilka funktioner systemet ska erbjuda Kvalitetskrav (kallas även icke-funktionella krav) Begränsningar för funktionerna Påverkar ofta hela produkten 31 Kvalitetskrav Tillförlitlighet Mognadsgrad, feltolerans, återhämtningsförmåga Användbarhet Begriplighet, lärbarhet, handhavande, attraktivitet Effektivitet Tidsbeteende, resursutnyttjande Underhållsbarhet Analyserbarhet, ändringsbarhet, stabilitet, testbarhet Portabilitet Uppfyllandegrad (standarder etc) Delar av ISO9126, se också Ingproc 2 32

17 Funktionella krav, exempel Om kunden erlägger belopp större än en varas pris ska systemet returnera mellanskillnaden. Vid time-out returnerar systemet erlagda mynt. Om en kund trycker på en knapp för en vara som inte finns händer ingenting. 33 Kvalitetskrav, exempel Det får maximalt gå 1.0 sekund från en myntiläggning till att systemet är redo att ta emot nästa mynt. Programvaran får högt använda 6 kbyt RAM Programvaran får högt använda 65 kbyt ROM Systemet får vara ur funktion högst 30 minuter om året. 34

18 Kravhanteringsprocessen krav Nu vet vi hur vi formuerar funktions- och kvalitets-krav. Men... krav Hur hittar vi, analyserar och dokumenterar krav krav Hur säkerställer vi att vi förstått? Hur ska vi prioritera? krav Process enligt wikipedia En samling i förväg uttänkta aktiviteter som ska användas varje gång man skapar ett visst resultat krav Från olika personer med olika behov Ta hänsyn till lagar, regler och standarder Hur? Marknadsanalyser Kundkontakter Analys av gamla system och processer Intervjuer, Kartläggningar (frågeformulär etc), Observationer Prototyper 36

19 krav Förstå problemen som systemet ska lösa nya krav, stryk krav, omformulera krav, värdera, dvs iterera Viktiga önskemål om kravspecifikation i denna fas: Korrekt, dvs stämmer med bakomliggande behov Komplett, dvs inga viktiga saker saknas etc 37 krav Dvs ta fram kravspecifikation Olika format möjliga Text Grafisk form Formell notation 38

20 Användningsfall (use case), analysera, dokumentera och validera krav, utgående från typiska exempel på användning. Administrera kurs Anmäla sig Lärare Student Lista kurser 39 Användarfall - exempel UC3: Register for course Primary actor: Student Precondition: the student has logged in Main success scenario: 1. Student lists available courses 2. Student selects one course 3. System accepts the selection Exception scenarios: 3a) The student has not been accepted on earlier required courses --> The system tells the student this situation 3b) The course is full and no more students are admitted --> The system tells the student this situation 40

21 Användarfall - Metod 1. aktörer och deras mål 2. För varje användningsfall: förstå och specificera normalscenario (main success scenario) 3. För varje normalscenario: identifiera undantagsscenario 4. För varje undantagsscenario: definiera vad som ska hända Val av detaljnivå beror på situationen... Mer i ETS170 OBS! Sub-sub-process :-) 41 Att göra Nu Kursdeltagare: Prio 1: Kom på banan nu! Skaffa wiki-konton enligt kurswebb. Hitta INTE på egna namn Läsa in er på projektbeskrivningen Göra R.1-6 Kl 15.15: C & I vi ses i E:3308 Nästa måndag Mer om krav Mer om projekt Granskning Kursombud Prio 2: Läsa J:3-4 Uppdatera: ETSA01/gruppXX/gruppmedlemmar Kursledning: Prio 1: Kom på banan nu! Rigga kurswikin Förbereda övning 1 42

22 Dataflödesdiagram * = AND + = OR 43 ER-diagram - Entity Relationship Data lagras i systemet (entitet + attribut), t ex: Student: pnr, namn, inskrivningsår Kurs: kurskod, namn, #hp Program: beteckning, namn Används ofta för att modellera data i databaser Student Kurs n Läser n n 1 Följer Ingår på n Program n 44

23 Naturligt språk 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 45 Delar i en kravspecifikation Table of contents 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2. General Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies 3. Specific Requirements Appendix Index [IEEE Guide to Software Requirements Specifications, ANSI/IEEE Std ] 46

24 Spårbarhet Från krav till källan till krav Mellan krav (visar beroende) Från design och kod till krav Från testfall till krav 47 Kravvalidering Kontrollera att kravspecifikationen är korrekt och av hög kvalitet Exempel på metoder: Granskning (vanligast) Utveckla testfall Verktygsstöd för formellt skrivna krav 48

25 Tidiga faser är viktiga [Alan Davis] 49 Bra egenskaper hos en kravspecifikation Korrekt Komplett Otvetydig Verifierbar Konsistent Prioriterad Genomförbar Modifierbar Spårbar 50

26 Granskningslista för kursens projekt 1. Saknas några krav? 2. Är samtliga krav nödvändiga? 3. Finns det några motstridiga krav? 4. Kan samtliga krav verifieras? 5. Ä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? 10.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? 51 Kravprioritering Omöjligt att implementera alla bra idéer! 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 52

27 Exempel, prioritering 13 6 Värde Kostnad 53 Krav och projekt i ett större perspektiv Björn Regnell kommer F6 Produktledning Plattform Krav Design Impl Test Produkter Krav Design Impl Test Krav Design Impl Test Krav Design Impl Test 54

28 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 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) 55 Att göra Nu Kursdeltagare: Prio 1: Kom på banan nu! Skaffa wiki-konton enligt kurswebb. Hitta INTE på egna namn Läsa in er på projektbeskrivningen Göra R.1-6 Kl 15.15: C & I vi ses i E:3308 Nästa måndag Mer om krav Mer om projekt Granskning Kursombud Prio 2: Läsa J:3-4 Uppdatera: ETSA01/gruppXX/gruppmedlemmar Kursledning: Prio 1: Kom på banan nu! Rigga kurswikin Förbereda övning 1 56