synligt inom lu • vänligen sprid inte filmerna! • ni bör inte...

Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2012 / F1

Streamade föreläsningar på webben

• 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

2

Skicka gärna frågor om innehåll via formuläret!

Jonas Wisbrant

ETSA01 Ingenjörsprocessen förprogramvaruutveckling – Metodik


Föreläsning 1:Kursen & Projektuppgift

Utvecklingsprojekt & Kravhantering

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

5

Samhällsvetare vid LU 1989Kommunikation och webbutveckling 1990Programvaruingenjör LTH i Helsingborg 2002Institutionen för Datavetenskap 1 2002

LUCAS - Center for Applied Software Research Diverse undervisning

Det Norske Veritas 2008

Institutionen för Datavetenskap 2 2009EASE / Programvaruportalen / kommunikationDatorer i SystemIngenjörsprocessen

Datavetenskap + LU webb 2011


Agenda F1

• Kursen & projektuppgiften

• Vad är ett utvecklingsprojekt• Kravhantering:

– Vad är ett krav?– Hur hittar vi dem?– Hur vet vi att de är bra?

• Att göra inför övning 1

• On kl 13 & to kl 10 i E:Hacke – Wiki-praktik för C och I

6

I pausen: Bilda projektgrupper och köpa kompendier



Kursen

7


Kursen

Innehåll• Projektplanering

• Kravhantering

• Arkitekturdesign

• Testning

• Modeller av utvecklingsprocessen för programvara

Formalia• 5 hp

• Obligatorisk för C1, D1, alternativobligatorisk för IE3

• Moment

- Föreläsningar

- Övningar

- Projekt

- Hemtentamen

• Del 1 av 3 kurser

8

Föreläsning

Hemarbete

Övningar

Projekt

Vi genomför ett utvecklingsprojekt under rimligt ordnade former och belyser det med teori och reflektioner.


Kurslitteratur

• BokPankaj Jalote, A Concise Introduction to Software Engineering, Springer, 2008.

– J: 6.2-5, 7.1.1-7.1.3 kursivt

• KompendiumExamples and Exercises in the Software Engineering Process, 2011.

– Säljs av institutionen för 50;-

9

Lunds universitet / LTH / Datavetenskap / ETSA01 VT 2010 / F1 10

ETSA01: Ingenjörsprocessen metodik VT 2012 2012-02-20 kl 10.02

Dag Aktivitet Innehåll Läsa Gör i förväg Händer på plats Projektåterkoppling

Må kl 9 Teoretisk introduktion till projektwiki för C&I (E:3308)

Genomgång av den wiki som kommer att användas under projekten

Må kl 15 F1 Kursöversikt, kravhantering, projektplanering, gruppindelning

J: 1, 3, 4

On kl 13 Praktisk introduktion till projektwiki för C&I Tillfälle 1 (E:Hacke)

Enkla övningsuppgifter för att komma in i wikin.

To kl 8 Ö1 Kravhantering: Kravkriterier, Kvalitetskrav, Use-Case, relationen mellan USE-case och skall-krav.

Översiktligt: J 3-4K: 2 + 4-6Detaljerat:J: 3.4-5

A: R.1-6 Diskussion:A: R.1-6

Göra:A: R.7-10

To kl 10 Praktisk introduktion till projektwiki för C&I Tillfälle 2 (E:Hacke)

Enkla övningsuppgifter för att komma in i wikin.

Må kl 15 F2 Kravhantering, Granskning, Projektplanering

J: 3, 4, 7.5

Ti 24.00 I Kravspecifikation 0.x Att wikin är igång och dokument är upprättade och påbörjade.

To kl 8 Ö2 Projektplanering:• Intressentanalys, • Affärsmål, projektmål, produktmål• Riskanalys, riskkategorier, uppställningDokumentgranskning (inspection)

J: 4.1J: 4.4-5J: 7.5

A: P.1-5A: I.1

Diskussion:A: P.1-6

Göra A: I.2-3

Kort återkoppling på kravspecifikationen

Må kl 15 F3 Testning J: 8

Må 24.00 I Kravspecifikation 0.99, Projektplan 0.99, granskningsprotokoll från intern granskning av de versioner som föregick 0.99orna.

Att krav, plan och granskningsprotokoll är av tillräcklig kvalitet för att milstolpe 1 ska kunna passeras.

To kl 8 Ö3 • Ändringshantering• Testplanering, Systemtest

A: T.1-8 Diskussion:A:T.1-8

Göra: A: T.15-16

Återkoppling Kravspecifikation 0.99 och Projektplan 0.99

Ti kl 15 F4 Arkitektur, design, kodning, versioner J: 5, 6, 7

On kl 24.00 I MS1 Uppdaterade krav och plan som Kravspecifikation 1.0 och Projektplan 1.0

To kl 8 Ö4 • Test forts.• Design

A: T.9-11 Diskussion: A: T.9-11

Göra: A: T.9-14Må kl 24.00 I MS2 Testplan 1.0, Design 1.0,

Granskningsprotokoll från granskningar inför Testplan 1.0 och Design 1.0

De 4 dokumenten används tillsammans med versionshistoriken som bas när projektets slutleverans bedöms.

To kl 9 Ö5 Övergripande återkoppling på Testplan 1.0 och Design 1.0

V19

(7-1

1/5) Må kl 15 F5 Utvecklingsprocesser, vidareutveckling,

om tentamenJ: 2

Må kl 15 F6 Inför tentanUtvärdering

A: HE.1-3

On 24.00 I Slut-inlämning

Sista versionen av Kravspecifikation, Projektplan, Testplan, Design, exekverbar kod, testprotokoll samt manual för systemstart

Granskning och bedömning av samtliga dokument

T

24/5 kl 08.00 - 25/5 kl 10.00

Hem-tentamen

Hela kursen

V13

(26

-30/

3)

Påskuppehåll

V16

(16

-20/

4)V

17 (

23-2

7/4)

Ingen schemalagd verksamhet

V20

(14

-18/

5)

Tidplan v 1.0 FörklaringJ = Jalote, PankajK = Kurskompendium

A = Övning på kurswebbenP = Projektbeskrivning på kurswebben

OBS! Dokumentet kan komma att uppdateras före och under kursen!

V11

(12

-16/

3)V

12 (

19-2

3/3)


Examination

• Projektarbete

• 26 timmar hemtenta 24-25/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


Nytt och obeprövat i kursen

• Modifierad projektuppgift (manualer)

• Filmer publicerade i förväg

• Studenter som projekthandledare

• 5v-påsk&bygg --> 3v-påsk-2v-bygg --->

12

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)


Bilda projektgrupper och köp kompendium i pausen

• Skriv upp dig på en av grupperna Alla grupper ska ha sex deltagare.

• Notera grupp och övningslokal• Köp kompendium

13

Grupp XX Deltagare (namn) Program

E:3308

Lisa Larsson D1

E:3308

Kalle Karlsson IE3

E:3308E:3308E:3308E:3308



Projektuppgiften

14


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

15

Leverabler– Kravspecifikation– Projektplan– Testplan & testspecifikation– Granskningsrapporter– Designdokument– Manual– Testrapporter– Exekverbar applikation

Plattformar– Moinwiki för dokumenten– Java/swing för programvaran

Operator

PCBarcodeprinter

Bicyclegarage

Entry door Exit door

Extraexit door

= barcode reader

= electronic lock

= pincode terminal

Målmiljö

Uppgift: Programmera ett cykelgarage

Fas 1Specifikation

Fas 2 Design

Fas 3Implementation och enhetstest

Fas 4Systemtest

Kravspecifikation

Projektplan

Testplan

Designdokument

Exekverbar källkod

Dokumenterat genomförda systemtest

Faser och leverabler

Projektgrupp

Projekt-handledare

QA från IP3

Aktörer DokumentmiljöUtvecklingsmiljö

Uppdrag


Kick-start:Etablera projektgrupper senast i pausen

• 188 personer --> 31,3 31 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örberett Övning 1!

– Har läst in sig på projektuppgiften

• Nästa tisdag kl 24 är det första dokumentet inlämnat

17

Första deadline om

200,5 h


Projektwikin

• Självförklarande ;-)

• Läsrätt:– egen grupp– kursledning (med

automatik)

18


On kl 13To kl 10 i E:Hacke Wiki-praktik för C och I

19



Om utvecklingsprojekt

20


• Vad kan gå fel?• Vad brukar gå fel?• Varför då?• Vad kan man göra åt det?

Om man utvecklar ett system...


Hur svårt det är att koka pasta

22

... och var man börjar

beror på om man gjort det förut


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

23

UTMANING:Vi bygger inte ytterligare ett hus, gipsar nästa ben eller kokar pasta igen...... vi gör innovation on demand


Utvecklingsprojekt vs. en-gång-till-projekt

Likheter– Planering och uppföljning– Samarbete och

kommunikation– ...

24

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


Ska vi börja med projektplanen eller kravspecifikationen?

• Beroende av varandra

• Kraven är en del av produkten. Sista versionen måste sparas.

• Planen hör till organisationen. Erfarenheterna bör sparas.

25

Fas 1Specifikation

Fas 2 Design

Fas 3Implementation och enhetstest

Fas 4Systemtest

Kravspecifikation

Projektplan

Testplan

Designdokument

Exekverbar källkod

Dokumenterat genomförda systemtest



Om kravhantering

26


Agenda

• Krav– Definition, olika sorter

• Kravhanteringsprocessen– identifiera– analysera– dokumentera– validera

27


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

[Standish Group, 1995]

“Top 10 challenges”

28

Om man utvecklar ett system...• Vad kan gå fel?• Vad brukar gå fel?• Varför då?• Vad kan man göra åt det?


Måste

Önskemål

Produkt-egenskap

Kontrakt Beslut

Begränsning

Funktion

Idé

Behov

LönsamInvestering

Underlag för test

Vad är ett krav?

29


Olika abstraktionsnivåer

30


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)

32

Delar av ISO9126, se också Ingproc 2


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 kb RAM

• Programvaran får högt använda 65 kb ROM

• Systemet får vara ur funktion högst 30 minuter om året.

34


Kravhanteringsprocessen

35

Dokumentera krav

Validera krav

Analysera krav

Identifiera krav

Nu vet vi hur vi formuerar funktions- och kvalitets-krav. Men...

– Hur hittar vi, analyserar och dokumenterar krav

– 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

• 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

Dokumentera

Validera

Analysera

Identifiera


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

37

Dokumentera

Validera

Analysera

Identifiera


Dokumentera krav

• Dvs ta fram kravspecifikation

• Olika format möjliga– Text– Grafisk form– Formell notation

38

Dokumentera

Validera

Analysera

Identifiera


Student

Administrera kurs

Identifiera, analysera, dokumentera och validera krav, utgående från typiska exempel på användning.

Användningsfall (use case)

39

Anmäla sig

Lista kurser

Lärare

Dokumentera

Validera

Analysera

Identifiera


Användarfall - exempel

UC3: Register for coursePrimary actor: StudentPrecondition: the student has logged inMain success scenario:

1. Student lists available courses2. Student selects one course3. 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

Dokumentera

Validera

Analysera

Identifiera


Mer i ETS170…

Användarfall - Metod

1. Identifiera aktörer och deras mål2. För varje användningsfall: förstå och specificera

normalscenario (main success scenario)3. För varje normalscenario:

- identifiera undantagsscenarier4. För varje undantagsscenario:

- definiera vad som ska hända

Val av detaljnivå beror på situationen...

41

Dokumentera

Validera

Analysera

Identifiera

OBS! Sub-sub-process :-)


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

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 1

42

C & I ses i Hackeon kl 13, to kl 10

Alla: Övning to kl 8

Nästa måndag här– Mer om krav– Mer om projekt– Granskning

synligt inom lu • vänligen sprid inte filmerna! • ni bör inte...

Documents