Streamade föreläsningar på webben. Medan vi väntar: Diskutera. Utmaning. Föreläsning 1: Projektuppgift & kravhantering. Om man utvecklar ett system...

Transkript

1 Medan vi väntar: Diskutera Streamade föreläsningar på webben Om man utvecklar ett system... Vad kan gå fel? Vad brukar gå fel? Varför då? Synligt inom LU Vad kan man göra åt det? Vänligen sprid inte filmerna!... samt notera kurswebben: Ni bör inte synas... samt köp kurskompendium för 50;- Man kan skicka frågor via webbformulär 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 Utmaning Föreläsning 1: uppgift & kravhantering Kan man förstå software engineering utan att ha upplevt stora programvaruprojekt? INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT Kan man förstå vad som händer i stora programvaruprojekt utan att ha studerat software engineering? 3 4

2 Jonas Wisbrant - kort CV Samhällsvetare vid LU 1989 Kommunikation och webbutveckling 1990 Programvaruingenjör LTH i Helsingborg 2002 Institutionen för Datavetenskap Agenda F1 Kursen & projektuppgiften hantering: LUCAS - Center for Applied Software Research Det Norske Veritas 2008 Institutionen för Datavetenskap I pausen: Bilda projektgrupper och köpa kompendier Vad är ett krav? Hur hittar vi dem? Hur vet vi att de är bra? Diverse undervisning Att göra inför övning 1A EASE / Programvaruportalen / kommunikation Datorer i System OBS! Ingenjörsprocessen 5 Datavetenskap + LU-webb 2011 Datavetenskap + LTH-webb? 2013 Ti kl 08 i Hacke & to kl 8 i E:3308 Wiki-support för C och I 6 Kursen Om kursen Innehåll Formalia ering 5 hp hantering Obligatorisk för C1, D1, alternativobligatorisk för IE3 Arkitekturdesign Moment Testning Föreläsningar Modeller av utvecklingsprocessen för programvara Övningar Övningar Föreläsning Hemarbete 7 8 Hemtentamen Del 1 av 3 kurser Vi genomför ett utvecklingsprojekt under rimligt ordnade former och belyser det med teori och reflektioner.

3 ETSA01: Ingenjörsprocessen metodik VT2013 v Veckoschema - kurs måndag tisdag onsdag torsdag fredag V tid K K K K K lö sö Kurslitteratur ETSA01: Ingenjörsprocessen metodik VT2013 v Veckoschema - kurs Bok Pankaj Jalote, A Concise Introduction to Software Engineering, Springer, V tid K K K K K lö sö Ö0a F1 Ö0b Ö1a Ö0c Ö1b 12 J: 6.2-5, kursivt Handledare -> fb0 F2 Ö2 15 L2 G1 Handledare > fb > fb2 F3 Ö3 16 > L3 Kompendium Examples and Exercises in the Software Engineering Process, Handledare > fb3 F4 Ö4 17 G2 > L4 G3 G4 Handledare > fb4 18 > L5 måndag tisdag onsdag torsdag fredag Säljs av CS-institutionen för 50;- Handledare > fb5 Ö5 L1 Ö0a F1 Ö0b Ö1a Ö0c Ö1b 12 L1 Handledare -> fb0 F2 Ö2 15 L2 G1 Handledare > fb > fb2 F3 Ö3 16 > L3 Handledare > fb3 Ö4 F4 17 G2 > L4 G3 G4 Handledare > fb4 Ö5 18 > L5 Handledare > fb5 F5 19 Handledare F6 20 T T T T T T T 22 Personal Personal Handledare F5 24 Personal Personal > fb6 fbt F6 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 T T T T T T T 22 Personal Personal Personal Personal > fb6 fbt 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 Planerad återkoppling från projekthandledare L1 1 samt funktionella krav och fb1 Att gruppen har förstått grunderna i formulering av kvalitetskrav användarfall och krav. L2 specifikation 0.x fb2 Att kravspecifikationen har struktur i Wikin. G1 av specifikation 0.99 L3 specifikation 0.99, sprotokoll från granskning inför - tillräcklig kvalitet för att milstolpe 1 ska kunna passeras. fb3 Att krav, granskningsprotokoll och projektplan är av specifikation med tider och risker. G2 inför specifikation 1.0 L4 specifikation 1.0, granskningsprotokoll fb4 OK eller ytterligare iteration G3 inför design 1.0 L5 Testplan 1.0, 1.0, G4 inför Testplan med sprotokoll från granskningar fb5 Översiktlig återkoppling på testplan och design testspecifikation 1.0 inför Testplan 1.0 och 1.0 Sista versionen av spec,, fb6 och bedömning av samtliga dokument Testplan,, exekverbar kod, fbt Tentamensresultat i LADOK (ej från projekthandledare). testprotokoll, manual för systemstart Föreläsningar Förberedelser Övningstillfällen Förbered Sker på plats F1 Kursöversikt, kravhantering, gruppindelning, J: 1, 3, 4 Ö1 hantering: kriterier, beskrivning A: R.7-10 projektuppgiften, Intro till övning 1,, relationen en avsnitt 1-4 på Introduktion, mellan, och skall-krav, kurswebben. diskussion kring L1 F2 hantering, ering,. J: 3, 4, 7.5 projektuppgiften A: R.1-6 F3 Testning J: 8 Ö2 ering: Intressentanalys, A: P.1-5 Diskussion: affärsmål, produktmål, projektmål, A: I.1 A: P.1-6 F4 Arkitektur, design, kodning, versioner J: 5, 6, 7 riskanalys, riskkategorier, uppställning Göra A: I.2-3 F5 Utvecklingsprocesser, vidareutveckling, om tentamen J: 2 Dokumentgranskning (inspection) 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 Preliminära granskningsmöten i projektet L1 L2 Föreläsningar F1 F2 F3 F6 Leveranser från projektet 1 samt funktionella krav och kvalitetskrav specifikation 0.x G1 av specifikation 0.99 L3 specifikation 0.99, s- fb3 protokoll från granskning inför specifikation med tider och risker. G2 inför specifikation 1.0 L4 specifikation 1.0, granskningsprotokoll fb4 G3 inför design 1.0 L5 Testplan 1.0, 1.0, G4 inför Testplan med sprotokoll från granskningar fb5 testspecifikation 1.0 inför Testplan 1.0 och 1.0 Examination Sista versionen av spec,, fb6 arbete Kursöversikt, kravhantering, gruppindelning, Testplan,, exekverbar kod, testprotokoll, manual för systemstart Förberedelser J: 1, 3, 4 projektuppgiften, Intro till övning 1 hantering, 26 timmar ering, hemtenta. J: 24-25/5: 3, 4, 7.5 Testning J: 8 F4 Arkitektur, design, kodning, versioner J: 5, 6, 7 U3 granskning (10 av 60 p) F5 Utvecklingsprocesser, vidareutveckling, om tentamen J: 2 Inför tentamen, sammanfattning av kursen J: 1-8, A:HE1 Ö3 Ändringshantering, Testplanering, A: T.1-8 Diskussion: varför denna typ av granskning är viktig, vem som bör delta, samt A:T.1-8 Ö1 Ö2 Ö4 Ö5 Planerad återkoppling från projekthandledare fb1 fb2 fbt Återkoppling testplan och design Att gruppen har förstått grunderna i formulering av användarfall och krav. Att kravspecifikationen har struktur i Wikin. Att krav, granskningsprotokoll och projektplan är av tillräcklig kvalitet för att milstolpe 1 ska kunna passeras. OK eller ytterligare iteration och bedömning av samtliga dokument Tentamensresultat i LADOK (ej från projekthandledare). Övningstillfällen Förbered Sker på plats hantering: kriterier,,, relationen mellan, och skall-krav, projektuppgiften ering: Intressentanalys, affärsmål, produktmål, projektmål, riskanalys, riskkategorier, uppställning Dokumentgranskning (inspection) Test forts, Översiktlig återkoppling på testplan och design beskrivning en avsnitt 1-4 på kurswebben. A: R.1-6 A: P.1-5 Beskriv hur en kravgranskning går till och förklara målsättning, vilka typer av fel man bör leta efter. A: I.1 Besked ges vid F4 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. A: R.7-10 Introduktion, diskussion kring L1 Diskussion: A: P.1-6 Göra A: I.2-3 Göra: A: T A: T.9-10 Ö4 Test forts, Besked ges vid F4 A: T Ö5 Återkoppling testplan och design 12

4 Personal Hälsningar från förra årets studenter Jonas Wisbrant, kursansvarig, föreläsningar, övningar Anna Axelsson övningar, projekthandledning Markus Borg övningar, projekthandledning Kursboken kan upplevas som svår - det är den inte. et 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. Emelie Engström övingar, projekthandledning Nytt och obeprövat i kursen: Kim Weyns övningar, projekthandledning Krzysztof Wnuk övningar, projekthandledning - bara en vecka till påskuppehållet kraftigt modifierad inledning - en mycket bättre test-labb?!? uppgiften Om 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 15 16

5 grupp: Kick-start: Etablera projektgrupper i pausen ETSA01: Ingenjörsprocessen metodik VT personer --> 26,3 26 grupper L2 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 Handledare > fb4 18 Ö5 vt 2013 Första deadline om 109,5 h V tid K K K K K lö sö 12 Ö0a F1 Ö0b Ö1a Ö0c Ö1b 1,0 L1 spec 1,0 2,0 1,0 1,0 1,0 0,5 Handledare -> fb0 15 F2 Ö2 spec 1,0 3,0 1,0 G1 Handledare fb > fb2 16 F3 Ö3 spec > L3 Testplan Handledare > fb3 17 F4 Ö4 spec G2 > L4 Testplan G3 G4 Code måndag tisdag onsdag torsdag fredag L4 18 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 E:3308 Lisa Larsson Kalle Karlsson Notera grupp och övningslokal Köp kompendium D1 IE3 spec Testplan > L5 > L5 Code Test Handledare > fb5 Veckoschema för projekten - idé 19 F5 spec ETSA01: Ingenjörsprocessen metodik VT2013 Testplan V Code tid K K K K K lö sö 12 Test Ö0a F1 Ö0b Ö1a Ö0c Ö1b 1,0 L1 Startman. spec Handledare 1,0 2,0 1,0 1,0 1,0 0,5 Handledare -> fb0 20 F6 15 F2 Ö2 spec spec 1,0 3,0 1,0 G1 Testplan Handledare fb > fb2 16 Code F3 Ö3 Test Startman spec > L3 Handledare -> Testplan F Schemalagd föreläsning Ö Schemalagd övning L Leverabel från projektet G smöte? fb Återkoppling T Tentamen 1,0 Timmar per projektmedlem Handledare > fb3 17 F4 Ö4 grupp: L2 xls finns på kurswebben vt 2013 måndag tisdag onsdag torsdag fredag wikin Självförklarande ;-) Läsrätt: egen grupp kursledning (med automatik) 19 spec G2 > L4 L4 Testplan G3 G4 20 Code Handledare > fb4 18 Ö5

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

7 täckning beslut täckning täckning beslut beslut V-modellen i ingenjörsprocessen täckning beslut V-modellen V-modellen i ingenjörsprocessen för programvaruutvecking täckning b Acceptanste Tes Fel Sy Integrationste Olika sorters krav Beskriver vilka funktioner systemet ska erbjuda Tillförlitlighet - Mognadsgrad, feltolerans, återhämtningsförmåga Begränsningar för funktionerna Påverkar ofta hela produkten Användbarhet - Begriplighet, lärbarhet, handhavande, attraktivitet Effektivitet - Tidsbeteende, resursutnyttjande sbarhet - Analyserbarhet, ändringsbarhet, stabilitet, testbarhet Portabilitet Uppfyllandegrad (standarder etc) Delar av ISO9126, se också Ingproc 2

8 täckning täckning beslut beslut täckning täckning beslut beslut, exempel, exempel Om kunden erlägger belopp större än en varas pris ska systemet returnera mellanskillnaden. Det får maximalt gå 1.0 sekund från en myntiläggning till att systemet är redo att ta emot nästa mynt. Vid time-out returnerar systemet erlagda mynt. 99% av personerna på perrongen ska var korrekt identifierade inom 15 sekunder Om en kund trycker på en knapp för en vara som inte finns händer ingenting. Programvaran får högt använda 65 kb ROM Systemet får vara ur funktion högst 30 minuter om året hanteringsprocessen Identifiera krav En Process enligt wikipedia Identifiera krav Från olika personer med olika behov Ta hänsyn till lagar, regler och standarder En samling i förväg uttänkta aktiviteter som ska användas varje gång man skapar ett visst resultat... Analysera krav Dokumentera krav krav Hur? Marknadsanalyser Kundkontakter Analys av gamla system och processer Intervjuer, Kartläggningar (frågeformulär etc), Observationer Prototyper 31 32

9 täckning täckning beslut beslut täckning täckning beslut beslut Analysera krav Dokumentera 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 Dvs ta fram kravspecifikation Olika format möjliga Text Grafisk form Formell notation etc Användningsfall (use case) - exempel välja kurs Identifiera, analysera, dokumentera och validera krav, utgående från typiska exempel på användning. Primär aktör: Förhandsvilkor: en är inloggad Administrera kurs Anmäla sig Lista kurser Lärare Huvudscenario 1. en listar tillgängliga kurser 2. en väljer en kurs 3. Systemet registrerar valet och meddelar studenten Undantagsfall 3a) en 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 35 36

10 täckning täckning beslut beslut täckning täckning beslut beslut - Metod hanteringsprocessen Identifiera aktörer och deras mål För varje användningsfall: - förstå och specificera huvudscenario - beskriv förhandsvillkor För varje huvudscenario - identifiera undantagsscenarier För varje undantagsfall: - definiera vad som ska hända Val av detaljnivå beror på situationen... Aktör UC1 UC2 UC3 S S S U U U U U 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? 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 Dataflödesdiagram ER-diagram - exempel Data lagras i systemet (entitet + attribut), t ex: : pnr, namn, inskrivningsår Kurs: kurskod, namn, #hp Program: beteckning, namn * Läser Följer Program * 1 * Ingår på * * Kurs ER-diagram - Entity Relationship Används ofta för att modellera data i databaser 39 40

11 Skillnad? eslut b n mentatio nstest Accepta rfall krav Använda ella Funktion krav Kvalitets täck ning Testdoku rt Felrappo Dokumentera krav med naturligt språk a ål Affärsm plan test System ll Utvärd Valider tproduk mål Underhå ering beslut täckning king tvec aruu prog V-model ramv beslut täckning len för de Gränsvär st ing Granskn nsklasser Ekvivale skning Kodgran x Whitebo tt hårdvara Gränssni kod nd kod r Program Återanvä Versione tionste Integra ning Kodtäck rationer r tion est Enhetst Konfigu Variante Applika essen Science Jonas Wisbrant ETSA01 metodik Ingenjörsproc Computer Lund f Data University ER-dia gram - Läser Lund Unive rsity Comp ute r Scien ce Jo isbran nas W SA01 t ET Ingen jörsp sen me ram - En versity tity Relat ionship Compute r Science mål progra mvaru ing g täckning beslu est ng d sser Integration Wisbrant ETSA01 stest Konfiguratio ner Jonas Testdokumen tation Ekvivalenskla Science t Acceptanst Kodgranskni kod Programko Computer Nackdelar: Generellt Flexibelt Lätt att använda och förstå Utvärderin krav hårdvara Återanvänd Lund University utveck Funktionella plan Gränssnitt Ingenjörsprocessen metodik Otydligt Risk att blanda olika sorters krav Risk att slå samman flera krav i ett Ingår på * Kurs ER-diag Lund Uni ellen för Produkt- - * * 36 Fördelar: V-mod ex empel Data la gras i sy stemet Studen (e ntitet t: pnr, + attrib namn, ut), t e Kurs: k inskrivn x: urskod ingsår, namn Progra, #hp m: bete ckning, namn Studen Följer t * * Progra 1 m am di a g r lödes Jonas Wisbra nt ETS A01 Inge todik roces njörspro cessen metodik Använd s ofta för att mod ellera data i databa ser 42 Table of contents 3. Specific Requirements 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview Appendix 2. General Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies Index -krav Test - krav -krav kod Återanvänd kod 44 beslut täckning [IEEE Guide to Software Requirements Specifications, ANSI/IEEE Std ] - källan Spårbarhet beslut täckning 43 Delar i en kravspecifikation beslut täckning

12 täckning täckning beslut beslut täckning täckning beslut beslut kraven Tidiga faser är viktiga Kontrollera att kravspecifikationen är korrekt och av hög kvalitet Exempel på metoder: (vanligast) Utveckla testfall Verktygsstöd för formellt skrivna krav [Alan Davis] Bra egenskaper hos krav och en kravspecifikation Checklista för granskning för kursens projekt 47 Korrekt Heltäckande Otvetydig Verifierbar Enskilt eller tillsammans? Vid time-out returnerar systemet erlagda mynt. Konsistent Prioriterad / nödvändighet Spårbar Genomförbar Korrekt Heltäckande Otvetydigt Konsistent Verifierbart Nödvändigt Spårbart Rankat - - x 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

13 täckning täckning beslut beslut täckning beslut prioritering Exempel prioritering - värde/kostnad 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 Värde Kostnad 13 beslut täckning och projekt i ett större perspektiv Sammanfattning - Plattform Produkter Produktledning Impl Test Impl Test Impl Test Impl Test 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ällakrav, krav-krav, krav-design/kod är en viktig del i arbetet med produktledning och produktplanering Mer om krav i hantering (ETS170)

14 Att göra nu uppgiften - storyn Prio 1: Kom på banan nu! C & I: Wiki ti kl 8 i Hacke Ta gärna med laptop Alla: Övningar on kl 13: och projekt to kl 8: utan lokal Wikiguide i E:3308 Prio 2: to kl 13: med lokal & HL Läsa J:3-4 Uppdatera: gruppxx/gruppmedlemmar fr kl 24: L1 i wikin :-) V2 Kursledning: Prio 1: Kom på banan nu! Rigga kurswikin Förbereda övning 1a och 1b 53 Tidag efter påsk + tentavecka E:A kl 13: Mer om kursen Om Om Val av kursombud 54 Uppdrag Faser och leverabler Målmiljö specifikation = barcode reader Operator = electronic lock Barcode printer PC = pincode terminal Fas 1 Specifikation Testplan Fas 2 Entry door dokument Extra exit door Bicycle garage Fas 3 Implementation och enhetstest Exit door Fas 4 Utvecklingsmiljö Aktörer Dokumentmiljö handledare grupp 55 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 - - Denna vecka Skaffa wiki-konton enligt kurswebb. Hitta INTE på egna namn Läsa in er på projektbeskrivningen Göra R.1-6 QA från IP3 Exekverbar källkod Dokumenterat genomförda systemtest Leverabler specifikation Testplan & testspecifikation srapporter dokument Manual Testrapporter Exekverbar applikation Plattformar Moinwiki för dokumenten Java/swing för programvaran