View
10
Download
0
Category
Preview:
Citation preview
Struktureret system udvikling
Minimodul 1: Introduktion, projekt- og tidsplanlægning
Rasmus L. Olsen, 2 februar 2011
1
Dagens program
• Introduktion og overblik over kursus
• Motivation for struktureret systemudvikling
• Projektfaser
• Aktiviteter
• Tidsmæssige sammenhænge
• V model
• Parallel udvikling
• Tidsplaner
2
Introduktion
Kursets hjemmeside
• http://www.control.aau.dk/~jdn/edu/courses/11-1/UdvModeller/
Kursus holder
• Rasmus L. Olsen, Jan D. Bendtsen, Jens D. Nielsen
Kort om mig selv
• Færdiguddannet i 2003 (Intelligente Autonome Systemer)
• Stærkt involveret i bl.a. AAU Cubesat 1 og ADAROS
• Forsvaret PhD projekt i Januar 2008
• Arbejdet i Europæisk forskningsprojekter
• MAGNET 2004-2005 Udvikling af nyt netværksparadigmer (Personal Networks)
• MAGNET Beyond 2006-2008 (http://www.ist-magnet.org)
• OPEN 2008-2010 (service migration)
3
Kursus indhold og mål
Viden der gør de studerende i stand til at:
• kunne redegøre for og skelne mellem forskellige udviklingsmodeller
• kunne redegøre for sammenhængen mellem en udviklingsproces og
tidsplanlægning
• kunne redegøre for designmetoder til både hardware og softwareudvikling
• kunne forklare betydningen af en krav-analyse og specifikation for et
udviklingsforløb
• kunne forklare interaktion mellem system og eksterne aktører
• kunne identificere og klassificere generelle grænseflader, f.eks. med henblik
på genbrugelighed af grænseflader
• kunne skelne mellem prototype implementation, emulering og simulering
• kunne redegøre for black- og whitebox testmetoder
4
Væsentlige kompetencer
• Kompetencer, der gør de studerende i stand til at:
• være i stand til at definere et system, nedbrydelse i
delsystemer samt integration af delsystemer
• være i stand til at vurdere og perspektivere system verifikation
i forhold til systemkrav
5
Opfyldelse af studiemål
• Læsning af litteratur (primære og supplerende)
• Forelæsninger
• Opgaveløsninger
• Aktiv deltagelse i opgaveløsninger
• Fordelagtigt, også i forhold til jeres projekt
• NB! I studieordningen står der enten mundtlig eller skriftlig
prøve med bestået/ikke bestået. Det er ikke klarlagt endnu
hvilken metode evalueringen består i.
6
Kursusoversigt og tidsplan
Mm1: Introduktion, projekt og tidsplanlægning (Rasmus)
Mm2: Analyse og indledende design (Rasmus, selvstudie)
Mm3: Krav og accepttest (Rasmus)
Workshop I : Opsummering af mm1 – 3 (Rasmus, Jens, Jan)
Mm4: SPU – I (Jens)
Mm5: SPU – II (Jens, selvstudie)
Mm6: Object Orienteret programmering – I (Jan)
Mm7: Object Orienteret programmering – II (Jan)
Mm8: Object Orienteret programmering – III (Jan, selvstudie)
Mm9: Scrum og xTreme programmering - I (Jens)
Mm10: Scrum og xTreme programmering - II (Jens, selvstudie)
Workshop 2: Opsummering af mm 4-10 (Rasmus, Jens, Jan)
Mm11: Test in real life - I (Rasmus)
Mm12: Test in real life - II (Rasmus, selvstudie)
Workshop 3: Opsummering af mm 12-13 (Rasmus, Jens, Jan)
Opfølgning (selvstudie)
7
Kursusbog #1
Introduction to Systems
• Chapter 1 Systems Science and Engineering
• Chapter 2 Bringing Systems Into Being
The system design process
• Chapter 3 Conceptual System Design
• Chapter 4 Preliminary System Design
• Chapter 5 Detail Design and Development
• Chapter 6 System Test, Evaluation, and Validation
System analysis and design evaluation
• Chapter 7 Alternatives and Models in Decision Making
• Chapter 8 Models For Economic Evaluation
• Chapter 9 Optimization in Design and Operations
• Chapter 10 Queuing Theory and Analysis
• Chapter 11 Control Concepts and Methods
8
Kursusbog #2
Design for operational feasability
• Chapter 12 Design for Reliability
• Chapter 13 Design for Maintainability
• Chapter 14 Design for Usability (Human Factors)
• Chapter 15 Design for Logistics and Supportability
• Chapter 16 Design for Producibility, Disposability, and Sustainability
• Chapter 17 Design for Affordability (Life-cycle Costing)
System engineering management
• Chapter 18 Systems Engineering Planning and Organization
• Chapter 19 Program Management, Control, and Evaluation
• + Flere nyttige appendices
9
Dagens program
• Introduktion og overblik over kursus
• Motivation for struktureret systemudvikling
• Projektfaser
• Aktiviteter
• Tidsmæssige sammenhænge
• V model
• Parallel udvikling
• Tidsplaner
10
System udvikling set i perspektiv
EfterspørgselUdbud
Krav
System udvikling Forretningsmuligheder
Resultater
Udbud
Marked
Efterspørgsel
Forventninger
Krav Udbud
Ekstern proces
(f.eks. samfundet)
Intern proces
(f.eks. virksomhed)
Kvalitets mangel
11
Marked
Forventninger Resultater
Kvalitets mangel
Problemstillingen i en nøddeskal
12
Hvorfor en struktureret tilgang?
• Tidsstyring
• Vedligeholdelse
• Dokumenentation
• Risikominimering
• Kvalitetsoptimering
• Genbrug
• m.m.
13
Fejlretningsudgifter
Jo længere henne i udviklingsprocessen,
jo mere koster det at rette fejl i tid og penge
Krav Design Impl. Test Drift
Relativ udgift for
fejlretning
1
10
100
• Systematisk design gør
det lettere at rette fejl!
• Kravfejl -> Designfejl
• Designfejl -> Impl. fejl
• Impl. fejl -> tid og penge
Årsager (eksempler)
• Mangel på erfaring
• Dårlig kommunikation
• Indforståetheder
14
Nooooo
Styringsproblemer
Hvad går galt her?
• Problemer bliver først opdaget når moduler er implementeret
og skal integreres!
Krav Design Impl. Test Integration
Planlagt
Realitet
Udgifter/
Tidsplan/
Problemer
Årsager (eksempler)
• Manglende kravspecifikation
-> ringe estimeringsgrundlag
• Mangel på indsigt i
udviklingsproblematik
• Dårlig koordinering mellem
udviklere pga. dårlige
interface design
• Mangel på forståelse mellem
udviklere
15
AARRGGhh
Software fejludvikling
Introduktion af SW opdateringer
• Skal være nemt for brugeren og ikke stille alt for store krav
• Skal ikke introducere flere problemer end der løses
• Spaghetti kode er svært at
vedligeholde
- Umuligt at huske efter 10 mdr.
• Udokumenteret kode er
svært at udvikle videre på
- Centreret omkring få udviklere
- Øger afhængighed af disse
Ustruktureret/
Udokumenteret
UdviklingStart V1.0 V2.0 V3.0
Fejlhyppighed
Held
Uheld
Struktureret
16
Undtagelser
• En person om en simpel ting, f.eks.
• Ens personlige hjemmeside
• Et lille hobby projekt
• Eller mere generelt: når der er tale om et minimalt personligt system
til engangsbrug
• Ellers altid en god ide at bruge struktureret system design
17
Udvikling er ikke let, specielt ikke hvis det skal ende med succes!
Højere succesrate: Struktureret Systemudvikling
Konklusion
18
Dagens program
• Introduktion og overblik over kursus
• Motivation for struktureret systemudvikling
• Projektfaser
• Aktiviteter
• Tidsmæssige sammenhænge
• V model
• Parallel udvikling
• Tidsplaner
19
Projektfaser og plan
1. Benyt en udviklingsmodel2. Udarbejd en kravspecifikation3. Design før kodning4. Planlæg test5. Anvend review teknikken6. Foretag projektstyring7. Dokumentér undervejs8. Foretag konfigurationsstyring
20
Projektforløb
21
Ide- og
analyse
fase
Krav-
specifikation
System
Design
HW udvikling
SW udvikling
Test og
validering
Hvorfor? Hvad? Hvordan?Sådan!
Værsgo’!
Iterativt projektforløb
22
AnalyseKrav
Spec.Design Impl.
Inte-
gration
Accept
test
Vedlige-
holdelse
- Iteration af projektforløbet er en vital del af struktureret system udvikling
- Jo kortere loops, jo bedre, men ingen loop er urealistisk!
U-model – for udviklingsaktiviteter
Analyse og
kravspecifikation
Analyse
Kra
vsp
ecifik
atio
n
Use Case Model
Arki-
tektur
Design
SW og HW
implementering
af use case X
System
Integra-
tionstest
Acce
ptte
st
Iteration
23
24
Lidt flere detaljer i projektforløbet
Tid
SPU modellen
Kravspecifikation:
• Analyse og use case specificering
• Kravspecifikation
• Accepttest specifikation
• Foreløbelig brugervejledning
• Evt. en simpel prototype/demo
• Review af kravspecifikation
25
SPU modellen
Program design:
• Opdeling af system i parallelle processer
• Eksterne grænseflader
• Interne grænseflader
• Synkronisering af processer
• Procesintegration-specifikation
• Hvordan integreres processerne?
• Hvad integreres hvornår?
Kritiske komponenter først!
• Vigtigt at alle i gruppen er aktive og enige!
26
SPU modellenProcesdesign:
• Opdeling af proces i moduler
• Sekventielt program
• Fællesmoduler
• Modul specifikation (krav, funktioner,
grænseflader)
• Modulintegrations-specifikation
• Identifikation af test programmer/stubbe
• Integration og test
27
SPU modellen
Moduldesign:
• Specialiseret design af modul
• Hvordan – Algoritme/flow chart/diagram
udlægning
• Specifikation af datastrukturer
• Modul test specifikation
• Black-boks test
• White-boks test
28
SPU modellen
Modulimplementering
• Omsætning af design til kode/hardware
• Følg standarder, f.eks.
• Kodestandarder såsom ANSI-C
• Ledningefarver, f.eks. sort: stel, rød: +5V
• Stikforbindelser
• Kodegranskning
• Forbedrer kode kvalitet
• Opdagelse af logiske fejl
• Læring af andres succeser/fejl
• Nedbrudt ”ejerskab”
29
SPU modellen
Modultest:
• Verificering at modulet overholder
modulspecifikationen
• Skrivning af test moduler/stubbe
• Brug af test apparater
• Udfyldning af test rapport
• Dokumentation over hvad der er,
og ikke er blevet testet for!
• Dokumentation over hvilke
problemer der eventuelt er fundet.
30
SPU modellen
Modulintegration:
• Samling af moduler
• Test af proces - integrationsrapport
• Dokumentation over hvad der er,
og ikke er blevet testet for!
• Dokumentation over hvilke
problemer der eventuelt er fundet.
• Vær forsigtig/realistisk
• Koble kun et modul sammen ad gangen
• Vær beredt på at skulle ”gå tilbage til start”
31
SPU modellen
Processintegration:
• Samling af parallelle processer
• Sikring at proces kommunikation virker
• Udarbejdelse af procesintegrationsrapport
• Det står i bogen det kan være svært,
men hvorfor?
• Manglende funktionaliteter (ups, det mangler vi)
• Dobbeltarbejde (det er jo det jeg har lavet…)
• Misforståelser under projektforløbet
• Forkerte interfaces (jeg troede du mente…)
• Forkerte datatyper (skulle det være en Float??)
• Forkert opfattelse af funktionaliteter (skulle den
have beregnet kvadratroden også??)
• ….
32
SPU modellen
Accepttest:
• Skal svare på det helt store spørgsmål:
• Er produktet som køberen forventer?
33
V-modellen - overordnet
Kravspecifikation Accepttest
ArkitekturdesignSystem inte-
grationstest
SW & HW
Implementering
34
V - modellen (Software)
Kravspec.
Programdesign
Procesdesign
Moduldesign
Implementation
Procesintegration
Accept-
test
Modultest
Modulintegration
35
V - model (Hardware)
Kravspec.
Strukturdesign
HW moduldesign
Layoutdesign
Wrapning/Printudlægning
Integrationstest
Accept-
test
Forbindelsestest
HW Modultest
36
Review undervejs Reviews
37
Med går det så gnidningsfrit???
NEJ!!!Men sandsynligheden for det
går helt galt reduceres betydeligt
38
Dagens program
• Introduktion og overblik over kursus
• Motivation for struktureret systemudvikling
• Projektfaser
• Aktiviteter
• Tidsmæssige sammenhænge
• V model
• Parallel udvikling
• Tidsplaner
39
Et problem: Parallel udvikling af software og hardware
• Spørgsmål:
• Hvordan udvikler man SW der skal køre på HW, SAMTIDIGT???
Modul
design
Detaljeret
designKodning
Unit
test
Modul
Integrationstest
SW Implementering af use case X
HW Implementering af use case X
Diagram
tegning
Komponent
beregning…
Wrapning/
LodningTest
Modul
Integrationstest
40
Realiteten er ofte en balancegang mellem to metoder
Pa
rall
el u
dv
ikli
ng
Se
kv
en
tiel u
dv
iklin
g
41
Eksempel på et blok opdelt system – fjernstyret robot
• Hvordan får man effektivt distribueret opgaver, således?
• Alle laver noget hele tiden
• Undgår tidspres i slutningen af projektet
• Alle kan tale sammen og se hinanden i øjnene efter projektet
42
Højttaler Joystick WLAN
Aktuator (lyd) SW driver Kommunikation
Platform
GUI
Platform
ControllerPC Robot
Hemmeligheden er .....
• Grænseflader (Interfaces)
• Hvorfor? Eksempel:
• Antag vi har fastlagt kommunikation til, så kan GUI folkene snakke med en
hurtig ”stub” som imiterer den relle kommunikation
• Ligeså med hardware/software
43
WLAN
Kommunikation
Platform
TCP/IP
HTTP: Besked x og y
802.11.g
GUI
Test stub(HTTP via127.0.0.1)
Joystick2 pins: [0..5V]
SW
Test stub-> 0..1024 (0-5V)
Dagens program
• Introduktion og overblik over kursus
• Motivation for struktureret systemudvikling
• Projektfaser
• Aktiviteter
• Tidsmæssige sammenhænge
• V model
• Parallel udvikling
• Tidsplaner
44
Tidsplaner, projektstyring, resourceudnyttelse
Kravspecifikation
System specifikation
HW Modul 1
HW Modul 2
HW Modul 3
SW Modul 1
SW Modul 2
SW Modul 3
SW Modul 1
SW Modul 2
SW Modul 3
Aktiviteter
M1 M3.1tidStart
M2 M3.3
M3.2M3
Design & impl.
med test stub
Design & Impl.
Integration
45
Værktøjer
• Der findes en lang række software produkter der kan være behjælpelig med grafisk repræsentation af tidslinjer
• Kan også være en stor kalender, gule sedler, ….
• En del af dagens opgave at finde et fornuftigt værktøj i kan benytte i jeres projekt, og få det afprøvet
Eksempel fra Microsoft Project, taget fra Wikipedia (http://en.wikipedia.org/wiki/File:Pert_example_gantt_chart.gif)
46
W-model – for leverancer
• Spørgsmål:
• Hvorledes bestemmer man hvor leverancerne skal ligge tidsmæssigt?
Leverancetid
E E E
L L
X tid
E EY tid Z tid
• Andre gruppe (medlemmer) kan også være modtagere af (del)produkt!
47
Bestemmelse af leveringstider/synkroniseringspunkter
• God planlægning kræver erfaring!
• Estimering af tid til opgaver der inddrager forskellige, svært
vurder bare parametre
• Analogi: Hvor lang tid tog en lignende opgave sidst?
• Faktor vurdering: Hvor erfaren er vedkommende/gruppen man
sætter på at lave modul X eller Y?
• Nyskabelse: Er der noget nyt involveret i aktiviteten?
• Forudsigelse: Kan der forudses problemer?
• Kommunikation mellem involverede er
ALTAFGØRENDE!!!!
48
Bestemmelse af leveringstider/synkroniseringspunkter -
”Arbejd” bagfra #1
• Lige før aflevering• Hvornår skal i aflevere?
• Hvor lang tid skal i bruge til at rette de sidste ting? Printe og samle? Hvad hvis printeren ikke fungerer eller computeren går ned?
• Test og validering• Hvor lang tid skal i bruge på at teste? Hvad nu når tingene
giver anledning til problemer i ikke har set før?
• Hvad nu når i opdager det i har testet ikke er godt nok, er forvirrende og ingen mening giver? Hvis i opdager en fejl i test opstillingen?
49
Bestemmelse af leveringstider/synkroniseringspunkter -
”Arbejd” bagfra #2
• Integration
• Hvor lang tid tager det at ændre et interface til det rigtige?
• SW interfaces er hurtigere at ændre end HW interfaces, men det kan til
gengæld være svært at opdage fejl i SW interfaces
• Hvor mange moduler har i? Et modul sættes sammen ad gangen (ingen
Big Bang test).
Hvad når et modul fejler når i har sat noget sammen?
• Hvad er plan B, C eller D?
• Modul
• Hvor svært er det i har med at gøre for det enkelte modul?
• Har i gjort noget lignende før?
• Er der dele i modulet som er svært at anskaffe?
50
Bestemmelse af leveringstider/synkroniseringspunkter -
”Arbejd” bagfra #3
• System design• Hvor komplekst er jeres system? Hvor meget dokumentation
skal udarbejdes og gennemarbejdes?
• Brug tid på at blive enige om interfaces; forstå jeres interfaces!
• Kravspecifikation og system definition• Hvor komplekst er jeres system? Hvor meget dokumentation
skal udarbejdes og gennemarbejdes?
• Skal der støves regler og standarder op fra diverse databaser?
• Er ”kunden” kendt som langsom eller hurtig responderende?
• Husk, i kan og bør altid iterere på jeres kravspecifikation, og system definition
51
Køkkenvask syndromet.... Mer’ vil ha’ mer problemet (scope creep)
52
Kunderne vil
Have dit og dat
Det kunne nu
også være
smart, hvis
den også
havde…
Det skal de
nok nå, så det
er en aftale
Den her mangler
vi altså!
Er den ikke lidt
kedelig at se på?
Et par yderligere gode råd
• Løbende feedback og justeringer ved hjælp af status møder og
opfølgning er nødvendigt
• Det er en del af jeres læringsproces!!
• Brug jeres vejleder til estimering af tid til opgaver
53
At lave projektarbejde kræver samarbejde….
54
Opgaver
• Undersøg hvilke værktøjer der findes til projektstyring/tidsplanlægning, evt. se på ovenstående links, og forbered på at argumentere hvorfor lige netop det værktøj i har fundet er et rigtig godt værktøj? Hvordan definerer i et 'godt' værktøj? Hvilke krav har i til at benytte et eller flere styringsværktøjer?
• Hvis i kunne gå tilbage i tiden med den viden og erfaring i har nu, hvordan vil i så planlægge jeres tid i P1 projekt perioden?
• Antag i er blevet spurgt om at lede en større projektgruppe (de andre grupper) om at bygge en satellit (eller et andet stort projekt), hvordan vil i gribe opgaven an?
55
Recommended