Struktureret system udvikling - Aalborg Universitetkom.aau.dk/~rlo/lectures/SSU-2011/mm1.pdf · HW...

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

http://www.ist-magnet.org/



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



• Projektfaser

• Aktiviteter


• V model


• 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



• Projektfaser

• Aktiviteter


• V model


• 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



• Projektfaser

• Aktiviteter


• V model


• 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



• Projektfaser

• Aktiviteter


• V model


• 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



• 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



• 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

Struktureret system udvikling - Aalborg Universitetkom.aau.dk/~rlo/lectures/SSU-2011/mm1.pdf · HW...

Documents

Transcript of Struktureret system udvikling - Aalborg Universitetkom.aau.dk/~rlo/lectures/SSU-2011/mm1.pdf · HW...