Medan vi väntar: Diskutera

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: http://cs.lth.se/etsa01...... samt köp kurskompendium för 50;- Streamade föreläsningar på webben 2 Synligt inom LU Vänligen sprid inte filmerna! Ni bör inte synas Möjligen nacken på 2-3 främre rader Ni kan komma att höras Säg till om jag ska klippa bort ljud Man kan skicka frågor via webbformulär

Föreläsning 1: Projektuppgift & kravhantering INGENJÖRSPROCESSEN METODIK ETSA01 VT13 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

Jonas Wisbrant - kort CV Samhällsvetare vid LU 1989 Kommunikation och webbutveckling 1990 Programvaruingenjör LTH i Helsingborg 2002 Institutionen för Datavetenskap 1 2002 LUCAS - Center for Applied Software Research Diverse undervisning Det Norske Veritas 2008 Institutionen för Datavetenskap 2 2009 EASE / Programvaruportalen / kommunikation Datorer i System Ingenjörsprocessen Datavetenskap + LU-webb 2011 Datavetenskap + LTH-webb? 2013 5 Agenda F1 Kursen & projektuppgiften hantering: 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 1A OBS! Ti kl 08 i Hacke & to kl 8 i E:3308 Wiki-support för C och I 6

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

Kurslitteratur Bok Pankaj Jalote, A Concise Introduction to Software Engineering, Springer, 2008. J: 6.2-5, 7.1.1-7.1.3 kursivt Kompendium Examples and Exercises in the Software Engineering Process, 2011. Säljs av CS-institutionen för 50;- 9 måndag tisdag onsdag torsdag fredag V tid 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K lö sö Student Ö0a F1 Ö0b Ö1a Ö0c Ö1b 12 Projekt L1 Handledare -> fb0 Student F2 Ö2 15 Projekt L2 G1 Handledare - - - - - -> fb1 - - - -> fb2 Student F3 Ö3 16 Projekt > L3 Handledare - - - - - - - - - - - - -> fb3 Student F4 Ö4 17 Projekt G2 > L4 G3 G4 Handledare - - - - -> fb4 Student 18 Projekt > L5 Ö5 Handledare - - - - - - - - - -> fb5 19 Student Projekt F5 20 Handledare Student Projekt F6 L6 Student T T T T T T T 22 Personal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23 Personal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 24 Personal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 25 Personal - - - - - - - - - - - -> fb6 fbt 10 Preliminära granskningsmöten i projektet Leveranser från projektet 1 samt funktionella krav och kvalitetskrav specifikation 0.x Att gruppen har förstått grunderna i formulering av användarfall och krav. Att kravspecifikationen har struktur i Wikin.

F Schemalagd föreläsning Ö Schemalagd övning L Leverabel från projektet G smöte? T Tentamen fb Återkoppling J=Jalote, Pankaj K=Kurskompendium A= Övning på kurswebben P=projektbeskrivning på kurswebben Preliminära granskningsmöten i projektet Leveranser från projektet L1 L2 1 samt funktionella krav och kvalitetskrav specifikation 0.x Planerad återkoppling från projekthandledare fb1 fb2 Att gruppen har förstått grunderna i formulering av användarfall och krav. Att kravspecifikationen har struktur i Wikin. G1 av specifikation 0.99 L3 specifikation 0.99, sprotokoll fb3 från granskning inför - specifikation 0.99. med tider och risker. Att krav, granskningsprotokoll och projektplan är av tillräcklig kvalitet för att milstolpe 1 ska kunna passeras. G2 inför specifikation 1.0 L4 specifikation 1.0, granskningsprotokoll fb4 G3 G4 inför design 1.0 inför Testplan med testspecifikation 1.0 L5 Testplan 1.0, 1.0, sprotokoll från granskningar inför Testplan 1.0 och 1.0 fb5 OK eller ytterligare iteration Översiktlig återkoppling på testplan och design L6 Sista versionen av spec,, Testplan,, exekverbar kod, testprotokoll, manual för systemstart fb6 fbt och bedömning av samtliga dokument Tentamensresultat i LADOK (ej från projekthandledare). Föreläsningar F1 F2 Kursöversikt, kravhantering, gruppindelning, projektuppgiften, Intro till övning 1 hantering, ering,. Förberedelser J: 1, 3, 4 J: 3, 4, 7.5 Övningstillfällen Förbered Sker på plats Ö1 hantering: kriterier,,, relationen mellan, och skall-krav, projektuppgiften Projektbeskrivning en avsnitt 1-4 på kurswebben. A: R.1-6 A: R.7-10 Introduktion, diskussion kring L1 F3 F4 Testning J: 8 Arkitektur, design, kodning, versioner J: 5, 6, 7 F5 Utvecklingsprocesser, vidareutveckling, om tentamen J: 2 Ö2 ering: Intressentanalys, A: P.1-5 affärsmål, produktmål, projektmål, A: I.1 riskanalys, riskkategorier, uppställning Dokumentgranskning (inspection) Diskussion: A: P.1-6 Göra A: I.2-3 F6 Inför tentamen, sammanfattning av kursen J: 1-8, A:HE1 Ö3 Ändringshantering, Testplanering, A: T.1-8 Diskussion: A:T.1-8 Göra: A: T.11-12 Ö4 Test forts, Besked ges vid F4 A: T.9-10 Ö5 Återkoppling testplan och design 11 Examination Projektarbete 26 timmar hemtenta 24-25/5: U3 granskning (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. 12

Personal Jonas Wisbrant, kursansvarig, föreläsningar, övningar Anna Axelsson övningar, projekthandledning Markus Borg övningar, projekthandledning Emelie Engström övingar, projekthandledning Kim Weyns övningar, projekthandledning Krzysztof Wnuk övningar, projekthandledning 13 Hälsningar från förra årets studenter Kursboken kan upplevas som svår - det är den inte. 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 & varför ;-) Bred medverkan i projektet ger stor fördel på tentan. Nytt och obeprövat i kursen: - bara en vecka till påskuppehållet kraftigt modifierad inledning - en mycket bättre test-labb?!? 14

Om projektuppgiften 15 Projektuppgiften Arbeta i grupper om 6 personer Genomför utvecklingsprojekt från början till slut identifiering och kravanalys ering och implementation Testning Leverans Leverabler specifikation Testplan & testspecifikation srapporter dokument Manual Testrapporter Exekverbar applikation Plattformar Moinwiki för dokumenten Java/swing för programvaran 16

Kick-start: Etablera projektgrupper i pausen Första deadline om 109,5 h 158 personer --> 26,3 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å ONSDAG KL 13. Har konto i projekt-wikin Har förberett Övning 1! Har läst in sig på projektuppgiften 17 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 Kalle Karlsson D1 IE3 E:3308 Notera grupp och övningslokal Köp kompendium 18

spec Testplan > L5 > L5 Code Test Handledare - - - - - - - - -> fb5 Veckoschema för projekten - idé 19 Student F5 Projekt spec xls finns på kurswebben Testplan måndag tisdag onsdag torsdag fredag V Code tid 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K 8 10 12 13 15 K lö sö 12 Test Student Ö0a F1 Ö0b Ö1a Ö0c Ö1b Startman. Projekt 1,0 L1 spec Handledare 1,0 2,0 1,0 1,0 1,0 0,5 Handledare 20 Student F6 -> fb0 15 Projekt Student F2 Ö2 Projekt spec L2 L6 spec 1,0 3,0 1,0 G1 L6 Testplan L6 Handledare fb1 - - - -> fb2 16 Code Student F3 Ö3 L6 L6 Test Startman L6 L6 Handledare -> F Schemalagd föreläsning Ö Schemalagd övning L Leverabel från projektet G smöte? fb Återkoppling T Tentamen 1,0 Timmar per projektmedlem 19 Projektwikin Självförklarande ;-) Läsrätt: egen grupp kursledning (med automatik) 20

Om kravhantering 21 Agenda Definition Olika sorter hanteringsprocessen identifiera analysera dokumentera validera 22

Top 10 challenges 23 1. Låg användaråterkoppling 2. Ofullständiga krav 3. en ändras 4. Lågt stöd från ledningen 5. Behärskar inte teknologin 6. Resursbrist 7. Orealistiska förväntningar 8. Oklara mål 9. Orealistiska tidsplaner 10. Ny teknik Standish Group Survey Chaos Report (1994) Top 10 Challenges [Standish Group, 1995] Vad är ett krav? Önskemål Behov Kontrakt Måste Underlag för test Beslut Funktion Produktegenskap Begränsning Nytta Lönsamhet 24

täckning V-modellen i ingenjörsprocessen täckning 25 V-modellen i ingenjörsprocessen täckning 26

täckning täckning Olika sorters krav Beskriver vilka funktioner systemet ska erbjuda Begränsningar för funktionerna Påverkar ofta hela produkten 27 Tillförlitlighet - Mognadsgrad, feltolerans, återhämtningsförmåga Användbarhet - Begriplighet, lärbarhet, handhavande, attraktivitet Effektivitet - Tidsbeteende, resursutnyttjande sbarhet - Analyserbarhet, ändringsbarhet, stabilitet, testbarhet Portabilitet Uppfyllandegrad (standarder etc) 28 Delar av ISO9126, se också Ingproc 2

täckning täckning, 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. 29, 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. 99% av personerna på perrongen ska var korrekt identifierade inom 15 sekunder Programvaran får högt använda 65 kb ROM Systemet får vara ur funktion högst 30 minuter om året. 30

täckning täckning hanteringsprocessen En Process enligt wikipedia En samling i förväg uttänkta aktiviteter som ska användas varje gång man skapar ett visst resultat... Identifiera krav Analysera krav Dokumentera krav krav 31 Identifiera 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 32

täckning täckning Analysera krav Förstå problemen som systemet ska lösa Identifiera 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 33 Dokumentera krav Dvs ta fram kravspecifikation Olika format möjliga Text Grafisk form Formell notation 34

täckning täckning Användningsfall (use case) Identifiera, analysera, dokumentera och validera krav, utgående från typiska exempel på användning. Administrera kurs Student Anmäla sig Lärare Lista kurser 35 - exempel välja kurs Primär aktör: Student Förhandsvilkor: Studenten är inloggad Huvudscenario 1. Studenten listar tillgängliga kurser 2. Studenten väljer en kurs 3. Systemet registrerar valet och meddelar studenten Undantagsfall 3a) Studenten saknar förkunskapskrav från någon tidigare kurser => Systemet meddelar studenten att och orsak till detta 3b) Kursen är fulltecknad, studenten får inte plats => Systemet registerar studenten i kö och meddelar studenten 36

täckning täckning - Metod Identifiera aktörer och deras mål För varje användningsfall: - förstå och specificera huvudscenario - beskriv förhandsvillkor Aktör För varje huvudscenario - identifiera undantagsscenarier För varje undantagsfall: - definiera vad som ska hända UC1 UC2 UC3 S S S U U U U U Val av detaljnivå beror på situationen... 37 hanteringsprocessen Ny har vi formulerar funktionsoch kvalitets-krav. Men... Hur hittar vi bland kraven? Hur analyserar och dokumenterar vid dem? Hur säkerställer vi att vi förstått? Hur ska vi prioritera? Identifiera krav Analysera krav Dokumentera 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 38

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

täckning täckning täckning I Enh Skillnad? täckning V-modellen för programvaruutvecking Dataflödesdiagram ER-diagram - exempel Data lagras i systemet (entitet + attribut), t ex: Student: pnr, namn, inskrivningsår Kurs: kurskod, namn, #hp Program: beteckning, namn modellen för programvaruu Student * Följer * 1 Läser Ingår på Program * 36 * * Kurs Används ofta för att modellera ER-diagram - Entity Relationship data i databaser 35 41 Dokumentera krav med naturligt språk Fördelar: Generellt Flexibelt Lätt att använda och förstå Nackdelar: Otydligt Risk att blanda olika sorters krav Risk att slå samman flera krav i ett 42

täckning täckning 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 830-1984] 43 Spårbarhet - källan -krav -krav Test - krav täckning Återanvänd kod- kod 44

täckning täckning kraven Kontrollera att kravspecifikationen är korrekt och av hög kvalitet Exempel på metoder: (vanligast) Utveckla testfall Verktygsstöd för formellt skrivna krav 45 Tidiga faser är viktiga [Alan Davis] 46

täckning täckning Bra egenskaper hos krav och en kravspecifikation Korrekt Heltäckande Otvetydig Verifierbar Enskilt eller tillsammans? Konsistent Prioriterad / nödvändighet Spårbar Genomförbar Vid time-out returnerar systemet erlagda mynt. Korrekt Heltäckande Otvetydigt Konsistent Verifierbart Nödvändigt Spårbart Rankat - - x - 47 Checklista för granskning för kursens projekt 48 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å dokumentet? 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ög abstraktionsnivå? 11. Är all texter och illustrationer nödvändiga? 12. Har samtliga krav unika identifierare? Guidat alternativ på kurswebben

Värde täckning täckning prioritering 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 49 Exempel prioritering - värde/kostnad täckning 1 5 6 13 2 4 3 7 8 9 11 12 10 14 Kostnad 50

täckning och projekt i ett större perspektiv Produktledning Plattform Impl Test Produkter Impl Test Impl Test Impl Test 51 Sammanfattning - Viktigt eftersom tidiga faser påverkar mycket kan finnas på olika abstraktionsnivåer påverkar ofta hela produkten Egenskaper hos krav: korrekt, komplett, otvetydig, verifierbar, konsistent, prioriterad, spårbar, genomförbar Spårbarhet: källa krav, krav-krav, krav-design/kod är en viktig del i arbetet med produktledning och produktplanering Mer om krav i hantering (ETS170) 52

53 Att göra nu 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 Prio 2: Läsa J:3-4 Uppdatera: http://wiki.cs.lth.se/etsa01/ gruppxx/gruppmedlemmar Kursledning: Prio 1: Kom på banan nu! Rigga kurswikin Förbereda övning 1a och 1b Denna vecka C & I: Wiki ti kl 8 i Hacke Ta gärna med laptop Alla: Övningar on kl 13: och projekt to kl 8: Projekt utan lokal Wikiguide i E:3308 to kl 13: Projekt med lokal & HL fr kl 24: L1 i wikin :-) V2 Tidag efter påsk + tentavecka E:A kl 13: Mer om kursen Om Projekt Om Val av kursombud Projektuppgiften - storyn Utveckla och leverera programvara till ett organiserat garage som förvarar cyklar. - - Installationsmanual Arbetsgivaren och beställare vill ha insyn: - - sprotokoll - Testrapporter från systemtest Vi vet att det ska vidareutvecklas av någon annan: - specifikation - Testspecifikation - - Leverabler specifikation Testplan & testspecifikation srapporter dokument Manual Testrapporter Exekverbar applikation Plattformar Moinwiki för dokumenten Java/swing för programvaran 54

Operator Uppdrag Målmiljö Faser och leverabler PC Barcode printer = barcode reader = electronic lock = pincode terminal Fas 1 Specifikation specifikation Testplan Fas 2 dokument Bicycle garage Extra exit door Entry door Exit door Fas 3 Implementation och enhetstest Exekverbar källkod Fas 4 Dokumenterat genomförda systemtest Utvecklingsmiljö Aktörer Dokumentmiljö Projektgrupp Projekthandledare 55