Reference: Sommerville, Software Engineering, 10 ed., Chapter 2

Det store billede

En softwareproces er et struktureret sæt af aktiviteter, der er nødvendige for at udvikle et softwaresystem. Bemærk, at vi taler om en “softwareproces” — ikke en “softwareudviklingsproces”.”

Der findes mange forskellige slags softwareprocesser, men hver eneste af dem involverer disse fire typer grundlæggende aktiviteter:

• Softwarespecifikation – at definere, hvad systemet skal gøre;
• Software design og implementering – at definere systemets organisation og implementere systemet;
• Softwarevalidering – at kontrollere, at det gør det, som kunden ønsker;
• Softwareudvikling – at ændre systemet som reaktion på ændrede kundebehov.

En softwareprocesmodel er en abstrakt repræsentation af en proces. Den præsenterer en beskrivelse af en proces ud fra et bestemt perspektiv. Når vi beskriver og diskuterer softwareprocesser, taler vi normalt om aktiviteterne i disse processer som f.eks. specifikation af en datamodel, design af en brugergrænseflade osv. og rækkefølgen af disse aktiviteter.Procesbeskrivelser kan også omfatte:

• Produkter, som er resultaterne af en procesaktivitet;
• Roller, som afspejler ansvaret for de personer, der er involveret i processen;
• For- og efterbetingelser, som er udsagn, der er sande før og efter, at en procesaktivitet er blevet iværksat eller et produkt fremstillet.

Plan-drevne processer er processer, hvor alle procesaktiviteterne er planlagt på forhånd, og hvor fremskridtene måles i forhold til denne plan. I agile processer er planlægningen inkrementel, og det er lettere at ændre processen, så den afspejler ændrede kundekrav. I praksis indeholder de fleste praktiske processer elementer af både plan-drevne og agile tilgange.

Vandfaldsmodellen Den plandrevne model Plan-drevne model. Separate og adskilte faser af specifikation, softwaredesign, implementering, test og vedligeholdelse. Inkrementel udvikling Specifikation, udvikling og validering er sammenflettet. Systemet udvikles som en række versioner (inkrementer), hvor hver version tilføjer funktionalitet til den foregående version. Kan være planstyret eller agil. Integration og konfiguration Baseret på, at der findes et betydeligt antal genanvendelige komponenter/systemer. Systemudviklingsprocessen fokuserer på at integrere disse komponenter i et system i stedet for at udvikle dem fra bunden. Kan være planstyret eller agil.

I praksis udvikles de fleste store systemer ved hjælp af en proces, der indeholder elementer fra alle disse modeller.

Der er særskilte identificerede faser i vandfaldsmodellen:

Analyse og definition af krav Systemets tjenester, begrænsninger og mål fastlægges ved høring af systemets brugere. De defineres derefter i detaljer og tjener som en systemspecifikation. System- og softwaredesign I systemdesignprocessen tildeles kravene til enten hardware- eller softwaresystemer ved at etablere en overordnet systemarkitektur. Softwaredesign indebærer identifikation og beskrivelse af de grundlæggende abstraktioner af softwaresystemet og deres relationer. Implementering og enhedstest I denne fase realiseres softwaredesignet som et sæt programmer eller programenheder. Test af enheder indebærer, at det kontrolleres, at hver enhed opfylder sin specifikation. Integration og systemtest De enkelte programeenheder eller programmer integreres og testes som et komplet system for at sikre, at softwarekravene er blevet opfyldt. Efter afprøvning leveres softwaresystemet til kunden. Drift og vedligeholdelse Normalt (men ikke nødvendigvis) er dette den længste livscyklusfase. Systemet installeres og tages i brug i praksis. Vedligeholdelse omfatter rettelse af fejl, som ikke blev opdaget i tidligere faser af livscyklus, forbedring af implementeringen af systemenheder og forbedring af systemets tjenester, efterhånden som der opdages nye krav.

Den største ulempe ved vandfaldsmodellen er, at det er vanskeligt at imødekomme ændringer, efter at processen er i gang. I princippet skal en fase være afsluttet, før man kan gå videre til den næste fase. Vandfaldsmodellens problemer omfatter:

Vanskeligt at imødekomme ændringer Den ufleksible opdeling af projektet i forskellige faser gør det vanskeligt at reagere på ændrede kundekrav Derfor er denne model kun hensigtsmæssig, når kravene er velforståede, og ændringerne vil være ret begrænsede i løbet af designprocessen. Kun få forretningssystemer har stabile krav. Meget få anvendelser i den virkelige verden Vandfaldsmodellen bruges mest til store systemtekniske projekter, hvor et system udvikles på flere steder. under disse omstændigheder hjælper vandfaldsmodellens planmæssige karakter med at koordinere arbejdet.

Fordele ved inkrementel udvikling:

Lavere omkostninger ved ændringer Omkostningerne ved at imødekomme ændrede kundekrav reduceres. Mængden af analyse og dokumentation, der skal laves om, er meget mindre, end det er nødvendigt med vandfaldsmodellen. Hyppig feedback Det er lettere at få kundefeedback på det udviklingsarbejde, der er udført. Kunderne kan kommentere på demonstrationer af softwaren og se, hvor meget der er blevet implementeret. Hurtigere levering Der er mulighed for hurtigere levering og implementering af nyttig software til kunden. Kunderne er i stand til at bruge og få værdi af softwaren tidligere, end det er muligt med en vandfaldsproces.

Problemer med inkrementel udvikling (fra ledelsesperspektivet):

Processen er ikke synlig Lederne har brug for regelmæssige leverancer for at måle fremskridt. Hvis systemer udvikles hurtigt, er det ikke omkostningseffektivt at producere dokumenter, der afspejler hver version af systemet. Systemets struktur har en tendens til at blive forringet, når der tilføjes nye inkrementer Medmindre der bruges tid og penge på refactoring for at forbedre softwaren, har regelmæssige ændringer en tendens til at ødelægge dens struktur. Det bliver stadig vanskeligere og dyrere at indarbejde yderligere ændringer i softwaren.

Denne tilgang er baseret på systematisk genbrug, hvor systemer integreres fra eksisterende komponenter eller COTS-systemer (Commercial-off-the-shelf).Procesfaser omfatter:

• Komponentanalyse;
• Kravmodifikation;
• Systemdesign med genbrug;
• Udvikling og integration.

Genbrug er nu standardmetoden for opbygning af mange typer forretningssystemer.

Typer af softwarekomponenter:

• Webtjenester, der er udviklet i henhold til servicestandarder, og som er tilgængelige for fjernopkald.
• Samlinger af objekter, der udvikles som en pakke, der skal integreres med en komponentramme som .NET eller J2EE.
• Stand-alone kommercielle off-the-shelf-systemer (COTS), der er konfigureret til brug i et bestemt miljø.

Egte softwareprocesser er indbyrdes forbundne sekvenser af tekniske, samarbejds- og ledelsesmæssige aktiviteter med det overordnede mål at specificere, designe, implementere og teste et softwaresystem.

De fire grundlæggende procesaktiviteter specifikation, udvikling, validering og udvikling er organiseret forskelligt i de forskellige udviklingsprocesser. I vandfaldsmodellen er de organiseret i rækkefølge, mens de i den inkrementelle udvikling er indskudt i hinanden.

Softwarespecifikation Processen, hvor man fastlægger, hvilke tjenester der er nødvendige, og hvilke begrænsninger der gælder for systemets drift og udvikling. Proces for udarbejdelse af krav:

• Gennemførlighedsundersøgelse: Er det teknisk og økonomisk muligt at bygge systemet?
• Kravudarbejdelse og -analyse: Hvad kræver eller forventer systemets interessenter af systemet?
• Kravspecifikation: Definition af kravene i detaljer
• Kravvalidering: Kontrol af kravets gyldighed

Softwaredesign og -implementering Processen, hvor systemspecifikationen omdannes til et eksekverbart system.

• Softwaredesign: design af en softwarestruktur, der realiserer specifikationen;
• Implementering: omsætter denne struktur til et eksekverbart program;

Aktiviteterne design og implementering er nært beslægtede og kan være sammenkoblet. Designaktiviteterne omfatter:

• Arkitektonisk design: identificere systemets overordnede struktur, de vigtigste komponenter (undertiden kaldet delsystemer eller moduler), deres relationer og hvordan de er fordelt.
• Grænsefladedesign: definere grænsefladerne mellem systemkomponenterne.
• Komponentdesign: Udvælg hver enkelt systemkomponent og design, hvordan den skal fungere.
• Databasedesign: Design af systemets datastrukturer, og hvordan disse skal repræsenteres i en database.

Softwarevalidering Verifikation og validering (V & V) har til formål at vise, at et system er i overensstemmelse med dets specifikation og opfylder systemkundens krav.

• Validering: bygger vi det rigtige produkt (det kunden ønsker)?
• Verifikation: bygger vi produktet rigtigt?

V & V & V omfatter kontrol- og gennemgangsprocesser og systemafprøvning. Systemafprøvning omfatter udførelse af systemet med testcases, der er afledt af specifikationen af de reelle data, der skal behandles af systemet. Testning er den mest almindeligt anvendte V & V-aktivitet og omfatter følgende faser:

• Udviklings- eller komponenttest: individuelle komponenter testes uafhængigt af hinanden; komponenter kan være funktioner eller objekter eller sammenhængende grupperinger af disse enheder.
• Systemtest: test af systemet som helhed, test af emergente egenskaber er særlig vigtig.
• Acceptancetest: test med kundedata for at kontrollere, at systemet opfylder kundens behov.

Softwareudvikling Software er i sagens natur fleksibel og kan ændre sig. I takt med at kravene ændrer sig som følge af ændrede forretningsforhold, skal den software, der understøtter forretningen, også udvikle sig og ændre sig. Selv om der har været en afgrænsning mellem udvikling og evolution (vedligeholdelse), er dette i stigende grad irrelevant, da færre og færre systemer er helt nye.

Forandringer er uundgåelige i alle store softwareprojekter.Forretningsmæssige ændringer fører til nye og ændrede systemkravNye teknologier åbner op for nye muligheder for at forbedre implementeringer.Ændrede platforme kræver applikationsændringer.Ændringer fører til omarbejde, så omkostningerne ved ændringer omfatter både omarbejde (e.f.eks. genanalyse af krav) samt omkostninger til implementering af ny funktionalitet.

To strategier til at reducere omkostningerne ved omarbejde:

Forebyggelse af ændringer Softwareprocessen omfatter aktiviteter, der kan foregribe mulige ændringer, før der er behov for betydeligt omarbejde. Der kan f.eks. udvikles et prototypesystem for at vise nogle af systemets nøglefunktioner til kunderne. Ændringstolerance Processen er udformet således, at ændringer kan imødekommes med relativt lave omkostninger, hvilket normalt indebærer en form for trinvis udvikling. Foreslåede ændringer kan gennemføres i trinvis udvikling, som endnu ikke er blevet udviklet. Hvis dette er umuligt, kan det være nødvendigt kun at ændre et enkelt trin (en lille del af systemet) for at indarbejde ændringen.

En prototype er en første version af et system, der bruges til at demonstrere koncepter og afprøve designmuligheder. En prototype kan bruges i:

• Den kravtekniske proces til at hjælpe med kravudarbejdelse og validering;
• I designprocesser til at undersøge muligheder og udvikle et UI-design;
• I testprocessen til at køre back-to-back-tests.

Fordele ved prototyping:

• Forbedret anvendelighed af systemet.
• Et tættere match til brugernes reelle behov.
• Forbedret designkvalitet.
• Forbedret vedligeholdbarhed.
• Reduceret udviklingsindsats.

Prototyper kan være baseret på sprog eller værktøjer til hurtig prototyping. De kan indebære udeladelse af funktionalitet:

• Prototypen bør fokusere på områder af produktet, som ikke er velforstået;
• Fejlkontrol og genopretning må ikke indgå i prototypen;
• Fokus på funktionelle frem for ikke-funktionelle krav såsom pålidelighed og sikkerhed.

Prototyper bør kasseres efter udviklingen, da de ikke er et godt grundlag for et produktionssystem:

• Det kan være umuligt at indstille systemet til at opfylde ikke-funktionelle krav;
• Prototyper er normalt udokumenterede;
• Prototypestrukturen af prototypen nedbrydes normalt ved hurtige ændringer;
• Prototypen vil sandsynligvis ikke opfylde normale organisatoriske kvalitetsstandarder.

I stedet for at levere systemet som en enkelt levering, er udviklingen og leveringen opdelt i trinvis udvikling og levering, hvor hvert trin leverer en del af den krævede funktionalitet.Brugerkravene prioriteres, og de højest prioriterede krav indgår i de tidlige inkrementer.

Når udviklingen af et inkrement er påbegyndt, er kravene fastfrosset, selvom kravene til senere inkrementer kan fortsætte med at udvikle sig.

Fordele ved inkrementel levering:

• Kundernes værdi kan leveres med hvert inkrement, så systemets funktionalitet er tilgængelig tidligere.
• De tidlige inkrementer fungerer som en prototype, der hjælper med at fremkalde krav til senere inkrementer.
• Mindre risiko for, at det samlede projekt mislykkes.
• De højest prioriterede systemtjenester har tendens til at få flest tests.

Problemer ved inkrementel levering:

• De fleste systemer kræver et sæt grundlæggende faciliteter, som bruges af forskellige dele af systemet. Da kravene ikke defineres i detaljer, før et trin skal implementeres, kan det være svært at identificere fælles faciliteter, som er nødvendige for alle trin.
• Kernen i iterative processer er, at specifikationen udvikles i forbindelse med softwaren. Dette er imidlertid i konflikt med indkøbsmodellen i mange organisationer, hvor den komplette systemspecifikation er en del af systemudviklingskontrakten.

Mange softwarefirmaer har valgt softwareprocesforbedring som en måde at forbedre kvaliteten af deres software på, reducere omkostningerne eller fremskynde deres udviklingsprocesser. Procesforbedring betyder, at man forstår de eksisterende processer og ændrer disse processer for at øge produktkvaliteten og/eller reducere omkostningerne og udviklingstiden.

Procesmodningstilgang Fokuserer på forbedring af proces- og projektstyring og indførelse af god softwareudviklingspraksis. Niveauet af procesmodning afspejler, i hvilket omfang god teknisk og ledelsesmæssig praksis er blevet indført i organisationens softwareudviklingsprocesser. Agil tilgang Fokuserer på iterativ udvikling og reduktion af overheadomkostninger i softwareprocessen. De primære kendetegn ved agile metoder er hurtig levering af funktionalitet og lydhørhed over for ændrede kundekrav.

Procesforbedringsaktiviteter danner en kontinuerlig cyklus med et feedback loop:

• Måler en eller flere egenskaber ved softwareprocessen eller -produktet. Disse målinger danner en basislinje, der hjælper med at afgøre, om procesforbedringer har været effektive.
• Analyser den nuværende proces og identificer eventuelle flaskehalse.
• Ændre processen for at afhjælpe nogle af de identificerede svagheder i processen. Disse indføres, og cyklussen genoptages for at indsamle data om ændringernes effektivitet.

Procesmåling

• Hvor det er muligt, bør der indsamles kvantitative procesdata.
• Procesmålinger bør anvendes til at vurdere procesforbedringer.
• Målinger kan omfatte:
  • Den tid, det tager for procesaktiviteter at blive gennemført, f. eks.f.eks. kalendertid eller indsats for at gennemføre en aktivitet eller proces.
  • Ressourcer, der kræves til processer eller aktiviteter, f.eks. den samlede indsats i persondage.
  • Antal af forekomster af en bestemt begivenhed, f.eks. antal fundne defekter.

The SEI capability maturity model

• Initial: I det væsentlige ukontrolleret
• Gentagelig: Produktstyringsprocedurer defineret og anvendt
• Defineret: Processtyringsprocedurer og -strategier defineret og anvendt
• Forvaltet: Kvalitetsstyringsstrategier defineret og anvendt
• Optimering: Strategier for procesforbedring defineret og anvendt