top - download
⟦60f6cd629⟧ Wang Wps File
Length: 11021 (0x2b0d)
Types: Wang Wps File
Notes: LSNs foredrag
Names: »4676A «
Derivation
└─⟦ea7a1ecf3⟧ Bits:30006190 8" Wang WCS floppy, CR 0437A
└─ ⟦this⟧ »4676A «
WangText
…00……00……00……00……00…<…0a……00……00…<…0b…<…0d…< ;…0d…;…07…:…86…1 …02… …02… …02… …02…
- # -
P R A K T I S K A N V E N D T E
P R O J E K T S T Y R I N G S M E T O D E R
F O R
S O F T W A R E U D V I K L I N G
Direkt]r Lars Stig Nielsen
Christian Rovsing A/S
Foredrag i Dansk Automationsselskab
den 7.marts 1984.
B̲A̲G̲G̲R̲U̲N̲D̲
Styring af st]rre softwareudviklingsprojekter hos Chr.
Rovsing A/S baseres p> en metodik, som tager udgangs-
punkt i erfaringer i forbindelse med rumfartsprojekter
og datakommunikationsnetv`rk, hvor der p> grund af
pro- jekternes st]rrelse og systemernes kompleksitet
stilles s`rligt store krav til systematisk planl`gning
og op- f]lgning.
1̲.̲ ̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲P̲L̲A̲N̲
Ved opstart af et projekt udarbejdes en "Project Imple-
mentation Plan" (PIP), som beskriver alle v`sentlige
elementer for styring af det p>g`ldende projekt.
Denne PIP fastl`gger en "Baseline" for alle projektak-
tiviteter og er det faste udgangspunkt for evaluering
og kontrol af projektstatus, fremdrift og produktivitet.
PIP'en er s>ledes systematisk struktureret, og hvert
afsnit beskriver en gruppe af aktiviteter med indhold,
omfang, organisation og procedurer.
Aktiviteterne er k`det sammen i et PERT-netv`rk med
tilh]rende overordnet Master-Schedule. For hver aktivi-
tet er beskrevet det kr`vede resultat med reference
til elementer i kontrakten.
Se figur 1, 2 og 3.
2̲.̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲L̲I̲F̲E̲-̲C̲Y̲C̲L̲E̲ ̲&̲ ̲B̲A̲S̲E̲L̲I̲N̲E̲S̲
Software udviklingen baseres p> en fase-model, hvor
re- sultatet af hver fase udg]r en "Baseline" for den
f]l- gende fase.
F]lgende faser anvendes normalt:
- Requirements
- System Design (Product Design)
- Preliminary System Design (udelades evt.)
- Detailed Design
- Code and Unit Test
- System Integration and Test.
Requirements fasen udg]r den kontraktuelle baseline,
som specificeres ved en beskrivelse af funktionelle
og tekniske krav samt en r`kke interface dokumenter.
Fasen afsluttes med et System Requirement Review (SRR),
denne baseline skal v`re godkendt, f]r projektet kan
forts`tte.
System Design fasen afsluttes med et Product Design
Re- view (PDR).
Detailed Design fasen afsluttes ligeledes med et Criti-
cal Design Review (CDR), hvorefter systemet er fastlagt
og godkendt i alle detaljer.
Code and Unit Test samt System Integration faserne
vil ofte foreg> ved en incremental udvikling med henblik
p> en gradvis f`rdigg]relse af selvst`ndige dele af
syste- met. Denne incrementale udvikling kan dog ogs>
starte ved Detailed Design, men ikke f]r alle interfaces
er fastlagte. System Integration fasen afsluttes med
en eller flere Acceptance Tests, hvorefter systemet
god- kendes til operationel anvendelse.
Gennemf]relse af Acceptance Tests er baseret p> konkre-
te Test Procedures, som er udarbejdet med henblik p>
en systematisk verifikation af kravsspecifikationens
en- kelte punkter.
Se figur 4, 5, 6 og 7.
3̲.̲ ̲ ̲V̲E̲R̲I̲F̲I̲C̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲V̲A̲L̲I̲D̲A̲T̲I̲O̲N̲
For hver enkelt fase gennemf]res en systematisk verifi-
kation og/eller validering. Midlerne hertil er dels
kritiske reviews af dokumenter, dels semiautomatiske
tests og valideringer af de enkelte software komponen-
ter.
I tilf`lde af afvigelser eller inkonsistens udarbejdes
Discrepancy Notes (DN's), som herefter tages op til
evaluering og beslutning af et Configuration Control
Board.
Ved Moduletests aftestes alle forgreninger og gr`nse-
v`rdier, og resultaterne dokumenteres i en test log.
P> tilsvarende vis aftestes interfaces og systemkrav
ved Subpackage Tests, Package Tests og System Tests
efter en strategi, hvor ethvert krav skal aftestes
s> tidligt som overhovedet muligt i faseforl]bet, idet
om- kostninger og komplikationer ved korrektion stiger
ef- terh>nden som projektet skrider frem.
Det kontrolleres at alle krav er verificeret ved hj`lp
af et Verification and Control Document (VCD), hvor
de enkelte krav krydsrefereres mod specifikke testcases
p> henholdsves modul, pakke og system niveau.
Se figure 8, 9 og 10.
4̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲P̲L̲A̲N̲N̲I̲N̲G̲ ̲&̲ ̲C̲O̲N̲T̲R̲O̲L̲
Med udgangspunkt i fasemodellen, de definerede base-
lines samt en systematisk estimering af projektets
om- fang af omkostninger udfyldes de planl`gningselementer,
som er beskrevet i Project Implementation Plan (PIP).
Der anvendes en Top-Down Development fremgangsm>de
s>- vel ved planl`gning som ved konstruktion af software.
Projektaktiviteterne nedbrydes hierarkisk i 5-6 ni-
veauer ved hj`lp af en Work Breakdown Structure (WBS),
hvor hver enkelt aktivitet identificeres ved et nummer-
system og p>f]res reference til baseline dokumenter.
Schedules optegnes p> PERT-networks i 3-4 niveauer,
s>- ledes at afh`ngigheder er vist s>vel p> detail-niveau
som p> Master Schedule, men ikke n]dvendigvis p> alle
mellemliggende niveauer. Master schedule afbildes des-
uden som et Gantt-kort. Schedules for kortsigtede akti-
viteter p> laveste niveau optegnes ligeledes som stav-
diagrammer med en opl]sningsevne helt ned til en dag
med henblik p> at hver enkelt person har en operationel
og konkret arbejdsplan.
Aktiviteterne samles i Work Packages (WPs), hvis igangs`tning
autoriseres s`rskilt med angivelse af m>l- s`tning,
kravsspecifikation, budget og tidsplan. En WP b]r som
rettesnor ikke overstige et omfang p> 6 person- m>neder
og en varighed p> 3 kalenderm>neder. Beskrivel- serne
af aktiviteterne for de enkelte software-pakker eller
del-pakker afh`ngig at omfanget samles i Unit Development
Folders (UDFs), s>ledes at hver enkelt per- son p>
projektet har en velafgr`nset opgave, som er be- skrevet
i et ringbind. Denne UDF indeholder Work Au- thorization,
Schedule, Status Reports, Requirements, Design Specification,
Unit Test Plan, Unit Source Code, Test Plan, Test log
med test cases og testresultater, Problem Reports,
kommentarer fra Reviews samt tekniske noter.
Et Early-Warning system bygges op omkring systematisk
statusrapportering og opf]lgning, hvor kvantitative
da- ta registreres, rapporteres og sammenstilles p>
ugent- lig basis. For hver enkelt Work Package
monitoreres fremdrift ved hj`lp af en grafisk afbild-
ning af opgavens estimerede omfang m>lt i antal linier-
kildekode, faktisk produceret antal linier kode hen-
holdsvis kompileret, testet og integreret. Disse data
akkumuleres herefter, s>ledes at status og fremdrift
kan monitoreres p> s>vel pakke-niveau som system- niveau.
I andre faser anvendes som m>lestok f.eks. an- tal
sider tekst eller antal test cases.
Se figure 11, 12, 13, 14, 15 og 16.
5̲ ̲ ̲Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲ ̲&̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
Med henblik p> at sikre et kvalitetsniveau, som lever
op til de specificerede standarder udf]res l]bende
kva- litetskontrol og konfigurationsstyring af uafh`ngige
funktioner, som er aktive gennem hele projektforl]bet.
V`sentlige opgaver for Configuration Management er:
- Identification of Configuration Items
- Change Control
- Status Accounting
- Configuration Auditing.
Hver enkel software komponent og dokument tildeles
et identifikationsnummer, et udgave-nummer og en dato
for release. Tilsvarende nummereres `ndringer til Baselined
Configuration Items.
Change Control sikres ved hj`lp af en procedure, som
kr`ver at enhver `ndring og ethver problem i relation
til Baseline Items rapporteres p> en formular (Discre-
pancy Note, Problem Report, Engineering Change Propo-
sal). Evaluering, klassifikation og beslutning foreg>r
herefter p> et Configuration Control Board (CCB), hvori
der deltager Quality Assurance, Configuration Manage-
ment og Software Management samt relevante eksperter
ad hoc.
Configuration Management f]rer herefter logbog og sta-
tistik, s>ledes at alle `ndringer kan spores, seneste
baseline klart kan identificeres og eventuelle s`rlige
problemomr>der kan identificeres s>vel kvalitativt
som kvantitativt.
Se figur 17, 18, 19, 20 og 21.
FIGURE 1
FIGURE 2
FIGURE 3
FIGURE 4
FIGURE 5
FIGURE 6
FIGURE 7
FIGURE 8
FIGURE 9
FIGURE 10
FIGURE 11
FIGURE 12
FIGURE 13
FIGURE 14
FIGURE 15
FIGURE 16
FIGURE 17
FIGURE 18
FIGURE 19
FIGURE 20
FIGURE 21
