Transcript Metodik för programvaruutveckling Kursinformation Innehåll

Kursinformation
Metodik för
programvaruutveckling
Föreläsning 3
Innehåll
•
•
•
•
•
•
Processer
Processmodeller
Iterationer
Specifikation
Design och implementation
Verifiering och validering
• Latex ok för litteraturstudierapport
(prata med mig bara)
• Nästa föreläsning är av Björn Regnell
(jag är med också)
• Presentationer imorgon
Utvecklingsprocessen för
programvara
Resurser
Behov
Produkter
En strukturerad mängd
aktiviteter som krävs för att
utveckla programvara
–
–
–
–
Specifikation
Design
Validering
Vidareutveckling
Processmodell
Exempel
Requirements
• En modell av utvecklingsprocessen
– Uppgiftsorienterad
– Dokumentorienterad
– Ofta grafisk
Process
Planning
Plan
Design
Scripts
Code
Guide
Compile
Test
Postmortem
Logs
Defects
Time
Results
Project
Plan
Summary
Finished product
några bilder från www.software-engin.com
Vad är en bra process?
• Lätt att förstå
• Ger insyn
• Kan stödjas med
CASE-verktyg
• Accepterad
•
•
•
•
Tillförlitlig
Robust
Underhållbar
Effektiv
Frågor
1. Vilka fördelar finns med en process
som används i många projekt?
2. Vilka svårigheter är förknippade
med att införa denna typ av
process?
3. Vad kan man göra för att underlätta
införandet?
Generiska modeller
•
•
•
•
Vattenfallsmodellen
Iterativ utveckling
Utveckling med formella metoder
Utveckling baserat på
återanvändning
Vattenfallsmodellen
Kravdefinition
Design
Implementation
enhetstest
Integration
Systemtest
Underhåll
Vattenfallsmodellen
• Fördelar
– Välplanerat då man
har välförstådda
krav
– God insyn
Iterativ utveckling
• Problem
– Svåranvänd om
man inte förstår
kraven väl från
början (t ex om
kunderna ändrar
sina krav)
– Uppdelning i faser
kan vara
omotiverad
Utkast
Utvecklingsprocessen
Slutgiltig
version
Versioner för kommentarer
Kund / användare
några bilder från www.software-engin.com
Två sorters iterativ utveckling
• Utforskande utveckling
– Arbete sker hela tiden med den produkt
som ska levereras
– Börja med de krav som man förstår bäst
• Slängprototyper
– Arbete sker med en prototyp som ska
slängas
– Börja med de krav som man förstår
sämst
Prototyputveckling
• För att definiera och validera krav
• Man kan göra avkall på kvalitetskrav
• Tekniker som 4GL, komponentbaserad utveckling, gränssnittsprototyper
Iterativ utveckling
• Användningsområden
– Små och
medelstora
interaktiva system
– Delar av system
– För system med
kort livstid
• Problem
– Dålig insyn
– Kan ge dålig
struktur
– Ställer höga krav på
utvecklarna
Formell utveckling
• Användningsområden
– Säkerhetskritiska
system
• Svårigheter
– Specialkunskaper
krävs
– Vissa delar av
system är mycket
svåra att specificera
på detta sättet, t ex
gränssnitt
Formell systemutveckling
1.
2.
3.
4.
5.
Kravdefinition
Formell specifikation
Transformation
Integration
Testning
Utveckling baserat på
återanvändning
• Kravspecifikation
• Genomgång av tillgängliga
komponenter
• Kravjustering
• Utveckling och återanvändning av
komponenter
• Verifiering
några bilder från www.software-engin.com
Inkrementell utveckling
Inkrementell utveckling
• Man måste alltid anpassa och justera
kraven vid utveckling av stora system
• För de de tidigare modellerna och t
ex för
1. Bestäm övergripande krav
2. Definiera inkrement och ange vilka
krav som ska implementeras i vilka
inkrement
3. Design, utveckling och verifiering av
varje inkrement
4. Integrera och validera systemet
5. Gå till 3 till systemet är klart
– Spiralmodellen
– Inkrementell utveckling
Inkrementell utveckling
1 2
3
4
3
4
3
4
• Parallell utveckling
• Man kan leverera till
kunden tidigt
• Man kan identifiera
krav
• Minskad risk
• De tidiga inkrementen
testas många gånger
(välj kritiska)
Spiralmodellen
Determine objectives
alternatives and
constraints
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Plan next phase
• Mål
– Införskaffa komponentkatalog
• Begränsningar
– Inom ett år
– Måste stödja existerande komponenttyper
– Måste kosta mindre än 1Mkr
• Alternativ
– Köp in existerande informationssystem
– Köp in databas och utveckla komponenter med 4GL
– Utveckla komponenter ”som vanligt”
• Risker
– Kanske omöjligt att upphandla med begränsningarna
– Specifikationen av katalogen är oklar
Operational
protoype
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Development
plan
Requirement
validation
Integration
and test plan
Design
V&V
Service
Exempel – ett varv i
spiralmodellen
Prototype 3
Prototype 2
Risk
analysis Prototype 1
Acceptance
test
Product
design
Detailed
design
Code
Unit test
Integration
test
Develop, verify
next-level product
• Riskresolution
– Utveckla prototyp för at klargöra kraven
– Förläng tidplanen
• Resultat
– Informationssystem är svåra att anpassa för
ändamålet
– Komponentkatalog utvecklad ”som vanligt” är
inte kostnadseffektiv
– Prototyp kan vidareutvecklas
• Planer
– Utveckla 4GL-system baserat på den prototyp
son finns
• Åtagande
– Ytterligare 12 månaders finansiering
några bilder från www.software-engin.com
Specifikation
• Bestämma tjänster, kvalitetskrav och
begränsningar på systemet
Design
• Att få ett implementationsunderlag
från kravspecifikationen
• Det finns många designmetoder och
verktyg för att stödja arbetet
• Exempel på modeller
– Dataflödesmodeller
– ER-modeller
– Objektmodeller
Programmering och felrättning
• Från design till exekverbart system
• Det finns ingen generisk process för
detta
• Enehtestestning
Verifiering och validering
Modultest
M1
Delsystemtest
Systemtest Acceptanstest
Ds1
M2
M3
M5
M4
…
Ds1
…
Mn-1
Dsm
S
S
Mn
Underhåll
•
Alla system som används måste
underhållas!
– Lägga till och förbättra
– Anpassa till omvärlden (som förändras)
– Rätta till felaktigheter
•
Metod
1. Uppdatera kraven
2. Utvärdera befintligt system och föreslå
förändringar
3. Modifiera systemet
CASE (Compute Aided
Software Engineering), t ex
• Grafiska editorer för att utveckla
systemmodeller
• Grafiska hjälpmedel för att utveckla
användargränssnitt
• ”Debuggers”
• Verktyg som genererar käöllkod från
designbeskrivningar
några bilder från www.software-engin.com
Olika uppdelningar
Funktionsperspektiv
Tool type
Planning tools
• Funktionsperspektiv
• Processperspektiv
• Integrationsperspektiv
Editing tools
Change ma nagement tools
Configuration management tools
Prototyping tools
Method-su pport tools
La nguage-proce ssing tools
Program analysis tools
Te sting t ools
Deb ugging tools
Doc um entation tools
Re-e ngine ering tools
Processperspektiv
Examples
PERT tools, estimation tools,
spreadsheets
Te xt editors, diagram editors, word
proce ssors
Requirements traceability tool s, chan ge
control sys tems
Version m anagement systems , sys tem
building tools
Very h igh-level languag es,
user in terface generators
Design editors, data dictionaries, co de
gene rators
Com pilers, interprete rs
Cross reference generators, static
analys ers, dynamic analysers
Te st data generators, file co mp arators
Interact ive de bugging s ystems
Page layout programs , ima ge editors
Cross-r eferenc e systems , program restructuring s ystems
Integrationsperspektivet:
verktyg, arbetsbänkar, miljöer
Reengineering tools
Testing tools
CASE
technology
Debugging tools
Program analysis tools
Language-processing
tools
Tools
Workbenches
Environments
Method support tools
Prototyping tools
Configuration
management tools
Editors
Compilers
File
comparators
Integrated
environments
Process-centred
environments
Change management tools
Documentation tools
Analysis and
design
Editing tools
Programming
Testing
Planning tools
Specification
Design
Implementation
Verification
and
Validation
Multi-method
workbenches
Single-method
workbenches
General-purpose
workbenches
Language-specific
workbenches
Sammanfattning
• Processer: idé, resurser -> produkter
• Generiska processer: vattenfallsmodellen,
iterativ utveckling, formella
transformationer, återanvändning
• Inkrementell utveckling kan bland annat
öka effektiviteten
• Viktiga faser: specifikation, design,
implementering, verifiering, underhåll
• Case: finns för alla faser och de flesta
funktioner i utvecklingen
några bilder från www.software-engin.com