Utmaning. Föreläsning 1: Kursen & Projektuppgift Utvecklingsprojekt & Kravhantering. Agenda F1. Jonas Wisbrant - kort CV

Transkript

1 Utmaning Kan man förstå software engineering utan att ha upplevt stora programvaruprojekt? ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Föreläsning 1: Kursen & Projektuppgift Utvecklingsprojekt & Kravhantering Jonas Wisbrant Kan man förstå vad som händer i stora programvaruprojekt utan att ha studerat software engineering? 3 Jonas Wisbrant - kort CV 4 Agenda F1 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 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 Kursen & projektuppgiften kl i E:3308 Wiki-intro för C och I 6

2 Kursen Formalia Innehåll Projektplanering Kravhantering Arkitekturdesign Testning Modeller av utvecklingsprocessen för programvara ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Kursen 5 hp Obligatorisk för C1, D1, alternativobligatorisk för IE3 Moment - Övningar Föreläsningar Ö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. ETSA01: Ingengörsprocessen metodik VT kl Tidplan v 1.0 Detta dokument kan komma att uppdateras under kursen! V1 (14-18/3) Kurslitteratur V3 (28/3-1/4) V2 (21-25/3) 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;- Dag Aktivitet Innehåll Läsa 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 To Ö1 F2 Ti I To Ö2 F 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 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 F5 kl I MS2 Ö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: 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.1-6 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 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

3 Hälsningar från förra årets studenter Examination Kursboken kan upplevas som svår Projektarbete Projektet innebär att man ofta känner osäkerhet 26 timmar hemtenta 26-27/5: Det är viktigt att alla i projektgruppen har koll på tidplanen (vem, vad, när) 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. 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 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) ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Program Lisa Larsson D1 Kalle Karlsson IE3 Projektuppgiften E:0522 Notera grupp och övningslokal Köp kompendium 13 14

4 Uppgift: Programmera ett cykelgarage Projektuppgiften Arbeta i grupper om 6 personer Genomför utvecklingsprojekt från början till slut Kravidentifiering och kravanalys Projektplanering Design och implementation Testning Leverans Uppdrag Leverabler Kravspecifikation Projektplan Testplan & testspecifikation Granskningsrapporter Designdokument Manual Testrapporter Exekverbar applikation Faser och leverabler lmiljö Kravspecifikation = barcode reader Operator = electronic lock Barcode printer PC = pincode terminal Fas 1 Specifikation Projektplan Testplan Fas 2 Design Entry door Designdokument Extra exit door Bicycle garage Fas 3 Implementation och enhetstest Exit door Fas 4 Systemtest Utvecklingsmiljö Aktörer Dokumentmiljö Plattformar Moinwiki för dokumenten Java/swing för programvaran Projekthandledare Projektgrupp QA från IP3 15 Kick-start: Etablera projektgrupper senast i pausen 156 personer --> 26,16 Projektwikin 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 Självförklarande ;-) Läsrätt: egen grupp QA-grupp från IP3 kursledning (med automatik) Har förbrett Övning 1! Har läst in sig på projektuppgiften Nästa tisdag kl 24 är det första dokumentet inlämnat Exekverbar källkod t genomförda systemtest

5 ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Om utvecklingsprojekt Wiki-intro för C och I kl i E: Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F1 20 Hur svårt det är att koka pasta beror på om man gjort det förut Om man utvecklar ett system... Vad kan gå fel? Vad brukar gå fel? Varför då? Vad kan man göra åt det?... och var man börjar 22

6 Projekt är något mer eller mindre unikt Utvecklingsprojekt vs. en-gång-till-projekt 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: Likheter Planering och uppföljning Samarbete och kommunikation... Skillnader Hög komplexitet Kan ändra sent... 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 Utvecklingsprojekt är något som man gör när man inte vet från början exakt hur det ska gå till 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 Fas 4 Systemtest Kraven är en del av produkten. Sista versionen måste sparas. ETSA01 Ingenjörsprocessen för programvaruutveckling Metodik Om kravhantering Planen hör till organisationen. Erfarenheterna bör sparas. t genomförda systemtest 25 26

7 Agenda Top 10 challenges Krav Definition, olika sorter Kravhanteringsprocessen identifiera analysera dokumentera validera 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 Om man utvecklar ett system... Vad kan gå fel? Vad brukar gå fel? Varför då? Vad kan man göra åt det? 8. Unclear Objectives 9. Unrealistic Time Frames 10. New Technology [Standish Group, 1995] 27 Vad är ett krav? 28 Olika abstraktionsnivåer Idé Önskemål Begränsning Behov Funktion ste Produktegenskap Underlag för test Lönsam Investering Kontrakt Beslut 29 30

8 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 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 Funktionella krav, exempel Kvalitetskrav, 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. 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

9 Kravhanteringsprocessen krav krav Nu vet vi hur vi formuerar funktions- och kvalitets-krav. Men... Hur hittar vi, analyserar och dokumenterar krav Från olika personer med olika behov Ta hänsyn till lagar, regler och standarder krav 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 Hur? Marknadsanalyser Kundkontakter Analys av gamla system och processer Intervjuer, Kartläggningar (frågeformulär etc), Observationer Prototyper krav Hur säkerställer vi att vi förstått? Hur ska vi prioritera? 36 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: Dvs ta fram kravspecifikation Olika format möjliga Text Grafisk form Formell notation Korrekt, dvs stämmer med bakomliggande behov Komplett, dvs inga viktiga saker saknas etc 37 38

10 Användningsfall (use case), analysera, dokumentera och validera krav, utgående från typiska exempel på användning. 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 Administrera kurs Anmäla sig Lärare Exception scenarios: 3a) The student has not been accepted on earlier required courses --> The system tells the student this situation Student Lista kurser 3b) The course is full and no more students are admitted --> The system tells the student this situation 39 Användarfall - Metod Att göra Nu 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 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 Val av detaljnivå beror på situationen... Mer i ETS170 Kursledning: Prio 1: Kom på banan nu! OBS! Sub-sub-process :-) Kursdeltagare: 40 Rigga kurswikin Förbereda övning