Referens: Sommerville, Software Engineering, 10 ed., kapitel 2

En programvaruprocess är en strukturerad uppsättning aktiviteter som krävs för att utveckla ett programvarusystem. Observera att vi talar om en ”programvaruprocess” — inte en ”programvaruutvecklingsprocess”.”

Det finns många olika typer av mjukvaruprocesser, men var och en av dem involverar dessa fyra typer av grundläggande aktiviteter:

• Mjukvaruspecifikation – att definiera vad systemet ska göra;
• Mjukvarudesign och -implementering – att definiera systemets organisation och att implementera systemet;
• Mjukvaruvalidering – att kontrollera att det gör det som kunden vill ha;
• Mjukvaruekonomisk utveckling – att förändra systemet för att svara på förändrade kundbehov.

En processmodell för programvara är en abstrakt representation av en process. Den presenterar en beskrivning av en process ur ett visst perspektiv. När vi beskriver och diskuterar programvaruprocesser brukar vi tala om aktiviteterna i dessa processer, t.ex. specificering av en datamodell, utformning av ett användargränssnitt osv. och ordningsföljden för dessa aktiviteter.Processbeskrivningar kan också innehålla:

• Produkter, som är resultatet av en processaktivitet;
• Roller, som återspeglar ansvaret för de personer som är involverade i processen;
• För- och eftervillkor, som är påståenden som är sanna före och efter det att en processaktivitet har genomförts eller en produkt producerats.

Planstyrda processer är processer där alla processaktiviteter planeras i förväg och framstegen mäts mot denna plan. I agila processer är planeringen inkrementell och det är lättare att ändra processen för att återspegla förändrade kundkrav. I praktiken innehåller de flesta praktiska processer delar av både planerings- och agila metoder.

Vattenfallsmodellen Planeringsdriven modell. Separata och distinkta faser av specifikation, programvarudesign, implementering, testning och underhåll. Inkrementell utveckling Specifikation, utveckling och validering är sammanflätade. Systemet utvecklas som en serie versioner (stegvis), där varje version lägger till funktionalitet till den föregående versionen. Kan vara planerad eller flexibel. Integration och konfiguration Baserat på förekomsten av ett betydande antal återanvändbara komponenter/system. Systemutvecklingsprocessen är inriktad på att integrera dessa komponenter i ett system snarare än att utveckla dem från grunden. Kan vara planerad eller agil.

I praktiken utvecklas de flesta stora system med hjälp av en process som innehåller element från alla dessa modeller.

Det finns separata identifierade faser i vattenfallsmodellen:

Kravanalys och -definition Systemets tjänster, begränsningar och mål fastställs i samråd med systemets användare. De definieras sedan i detalj och fungerar som en systemspecifikation. System- och programvaruutformning I systemutformningsprocessen fördelas kraven på antingen hårdvaru- eller programvarusystem genom att en övergripande systemarkitektur upprättas. Programvarudesign innebär att man identifierar och beskriver de grundläggande abstraktionerna i programvarusystemet och deras relationer. Genomförande och enhetstestning Under detta skede förverkligas programvarudesignen som en uppsättning program eller programenheter. Testning av enheter innebär att man kontrollerar att varje enhet uppfyller sin specifikation. Integration och systemtestning De enskilda programenheterna eller programmen integreras och testas som ett komplett system för att säkerställa att programvarukraven har uppfyllts. Efter testningen levereras programvarusystemet till kunden. Drift och underhåll Normalt (men inte nödvändigtvis) är detta den längsta livscykelfasen. Systemet installeras och tas i praktisk användning. Underhållet innebär att man korrigerar fel som inte upptäcktes i tidigare skeden av livscykeln, förbättrar genomförandet av systemenheterna och förbättrar systemets tjänster i takt med att nya krav upptäcks.

Den största nackdelen med vattenfallsmodellen är svårigheten att tillgodose förändringar efter att processen har inletts. I princip måste en fas vara avslutad innan man går vidare till nästa fas. Vattenfallsmodellens problem är bland annat:

Svårt att hantera förändringar Den oflexibla uppdelningen av projektet i distinkta faser gör det svårt att reagera på förändrade kundkrav. Därför är denna modell endast lämplig när kraven är väl förstådda och förändringarna kommer att vara ganska begränsade under designprocessen. Få affärssystem har stabila krav. Mycket få tillämpningar i verkligheten Vattenfallsmodellen används främst för stora systemtekniska projekt där ett system utvecklas på flera ställen. under dessa omständigheter hjälper vattenfallsmodellens planstyrda karaktär till att samordna arbetet.

Fördelar med inkrementell utveckling:

Lägre kostnad för ändringar Kostnaden för att tillgodose förändrade kundkrav minskar. Mängden analys och dokumentation som måste göras om är mycket mindre än vad som krävs med vattenfallsmodellen. Frekvent återkoppling Det är lättare att få kundåterkoppling på det utvecklingsarbete som har utförts. Kunderna kan kommentera demonstrationer av programvaran och se hur mycket som har genomförts. Snabbare leverans Det är möjligt att snabbare leverera och distribuera användbar programvara till kunden. Kunderna kan använda och få värde av programvaran tidigare än vad som är möjligt med en vattenfallsprocess.

Problem med inkrementell utveckling (ur ledningens perspektiv):

Processen är inte synlig Cheferna behöver regelbundna leveranser för att mäta framstegen. Om system utvecklas snabbt är det inte kostnadseffektivt att ta fram dokument som speglar varje version av systemet. Systemets struktur tenderar att försämras när nya steg läggs till Om inte tid och pengar spenderas på refaktorisering för att förbättra programvaran tenderar regelbundna förändringar att förstöra dess struktur. Det blir allt svårare och dyrare att införliva ytterligare ändringar i programvaran.

Detta tillvägagångssätt bygger på systematiskt återanvändning där system integreras från befintliga komponenter eller COTS-system (Commercial-off-the-shelf).Processstegen omfattar:

• Komponentanalys;
• Kravmodifiering;
• Systemdesign med återanvändning;
• Utveckling och integration.

Återanvändning är numera standardmetoden för att bygga många typer av affärssystem.

Typer av programvarukomponenter:

• Webbtjänster som utvecklas i enlighet med tjänstestandarder och som är tillgängliga för anrop på distans.
• Samlingar av objekt som utvecklas som ett paket som ska integreras med ett ramverk för komponenter, t.ex. .NET eller J2EE.
• Stand-alone system från kommersiell hyllan (COTS) som är konfigurerade för användning i en viss miljö.

Egna mjukvaruprocesser är sammanhängande sekvenser av tekniska, samarbets- och ledningsrelaterade aktiviteter med det övergripande målet att specificera, utforma, genomföra och testa ett mjukvarusystem.

De fyra grundläggande processaktiviteterna specifikation, utveckling, validering och utveckling är organiserade på olika sätt i olika utvecklingsprocesser. I vattenfallsmodellen är de organiserade i sekvens, medan de i inkrementell utveckling är interfolierade.

Programvaruspecifikation Processen för att fastställa vilka tjänster som krävs och vilka begränsningar som gäller för systemets drift och utveckling. Process för kravhantering:

• Genomförbarhetsstudie: Är det tekniskt och ekonomiskt möjligt att bygga systemet?
• Kravuttag och analys: Vad kräver eller förväntar sig systemets intressenter av systemet?
• Kravspecifikation: Definiering av kraven i detalj
• Kravvalidering: Kontroll av kravens giltighet

Mjukvarudesign och -implementering Processen för att omvandla systemspecifikationen till ett körbart system.

• Programvarudesign: utformar en programvarustruktur som förverkligar specifikationen;
• Implementering: översätter denna struktur till ett exekverbart program;

Aktiviteterna design och implementering är nära förknippade med varandra och kan vara interfolierade. Designaktiviteterna omfattar följande:

• Arkitektonisk utformning: identifiera systemets övergripande struktur, de viktigaste komponenterna (ibland kallade delsystem eller moduler), deras relationer och hur de är distribuerade.
• Gränssnittsutformning: definiera gränssnitten mellan systemkomponenter.
• Komponentutformning: ta varje systemkomponent och utforma hur den ska fungera.
• Databasutformning: Utforma systemets datastrukturer och hur dessa ska representeras i en databas.

Validering av programvara Verifiering och validering (V & V) syftar till att visa att ett system överensstämmer med sin specifikation och uppfyller systemkundens krav.

• Validering: bygger vi rätt produkt (det som kunden vill ha)?
• Verifiering: bygger vi produkten rätt?

V & V & V innefattar kontroll- och granskningsprocesser och systemtestning. Systemtestning innebär att systemet exekveras med testfall som härleds från specifikationen av de verkliga data som ska behandlas av systemet. Testning är den vanligaste V & V-aktiviteten och omfattar följande steg:

• Utvecklings- eller komponenttestning: enskilda komponenter testas oberoende av varandra; komponenter kan vara funktioner eller objekt eller sammanhängande grupperingar av dessa enheter.
• Systemtestning: testning av systemet som helhet, testning av framväxande egenskaper är särskilt viktigt.
• Acceptanstestning: testning med kunduppgifter för att kontrollera att systemet uppfyller kundens behov.

Mjukvaruutveckling Mjukvara är av naturliga skäl flexibel och kan ändras. När kraven förändras genom förändrade affärsvillkor måste den programvara som stöder verksamheten också utvecklas och förändras. även om det har funnits en avgränsning mellan utveckling och utveckling (underhåll) är detta alltmer irrelevant eftersom allt färre system är helt nya.

Förändringar är oundvikliga i alla stora mjukvaruprojekt.Verksamhetsförändringar leder till nya och förändrade systemkravNy teknik öppnar nya möjligheter att förbättra implementeringarna.Förändrade plattformar kräver applikationsförändringar.Förändringar leder till omarbetning, så kostnaderna för förändringar innefattar både omarbete (t.ex.t.ex. omanalys av krav) samt kostnader för att implementera ny funktionalitet.

Två strategier för att minska kostnaderna för omarbete:

Förändringsundvikande Mjukvaruprocessen omfattar aktiviteter som kan förutse möjliga förändringar innan betydande omarbete krävs. Till exempel kan ett prototypsystem utvecklas för att visa några viktiga funktioner i systemet för kunderna. Förändringstolerans Processen är utformad så att förändringar kan tillgodoses till en relativt låg kostnad, vilket normalt innebär någon form av inkrementell utveckling. Föreslagna ändringar kan genomföras i steg som ännu inte har utvecklats. Om detta är omöjligt kan endast ett enda steg (en liten del av systemet) behöva ändras för att införliva ändringen.

En prototyp är en första version av ett system som används för att demonstrera koncept och prova designalternativ. En prototyp kan användas i:

• Kravhanteringsprocessen för att hjälpa till med kravuttag och validering;
• I designprocesser för att utforska alternativ och utveckla en användargränssnittsdesign;
• I testprocessen för att köra back-to-back-tester.

Fördelar med prototyper:

• Förbättrad användbarhet av systemet.
• Närmare överensstämmelse med användarnas verkliga behov.
• Förbättrad kvalitet på designen.
• Förbättrad underhållbarhet.
• Förlorad utvecklingsinsats.

Prototyperna kan vara baserade på språk eller verktyg för snabbprototyper. De kan innebära att funktionalitet utelämnas:

• Prototypen bör fokusera på områden av produkten som inte är väl förstådda;
• Felkontroll och återställning får inte ingå i prototypen;
• Fokusera på funktionella snarare än icke-funktionella krav som tillförlitlighet och säkerhet.

Prototyper bör kasseras efter utvecklingen eftersom de inte är en bra grund för ett produktionssystem:

• Det kan vara omöjligt att ställa in systemet så att det uppfyller icke-funktionella krav;
• Prototyper är normalt odokumenterade;
• Prototypens struktur försämras vanligen genom snabba förändringar;
• Prototypen kommer förmodligen inte att uppfylla normala organisatoriska kvalitetsstandarder.

Istället för att leverera systemet som en enda leverans, delas utvecklingen och leveransen upp i steg med varje steg som levererar en del av den nödvändiga funktionaliteten.Användarkraven prioriteras och de högst prioriterade kraven ingår i tidiga steg. när utvecklingen av ett steg har påbörjats är kraven frysta även om kraven för senare steg kan fortsätta att utvecklas.

Fördelar med stegvis leverans:

• Kundernytta kan levereras med varje steg så att systemets funktionalitet är tillgänglig tidigare.
• Främre steg fungerar som en prototyp för att hjälpa till att ta fram krav för senare steg.
• Lägre risk för övergripande projektmisslyckanden.
• De högst prioriterade systemtjänsterna tenderar att få mest testning.

Problem med inkrementell leverans:

• De flesta system kräver en uppsättning av grundläggande faciliteter som används av olika delar av systemet. Eftersom kraven inte definieras i detalj förrän ett steg ska implementeras kan det vara svårt att identifiera gemensamma faciliteter som behövs av alla steg.
• Kärnan i iterativa processer är att specifikationen utvecklas tillsammans med programvaran. Detta strider dock mot upphandlingsmodellen i många organisationer, där den fullständiga systemspecifikationen är en del av kontraktet för systemutveckling.

Många programvaruföretag har valt att använda sig av processförbättring som ett sätt att höja kvaliteten på sin programvara, minska kostnaderna eller påskynda sina utvecklingsprocesser. Processförbättring innebär att man förstår befintliga processer och ändrar dessa processer för att öka produktkvaliteten och/eller minska kostnaderna och utvecklingstiden.

Processmognadsstrategi Fokuserar på att förbättra process- och projektledning och införa god praxis för programvaruteknik. Nivån på processmognad återspeglar i vilken utsträckning god teknisk praxis och god förvaltningspraxis har införts i organisationens programvaruutvecklingsprocesser. Agil metod Fokuserar på iterativ utveckling och minskning av omkostnader i programvaruprocessen. De främsta kännetecknen för agila metoder är snabb leverans av funktionalitet och reaktionsförmåga på förändrade kundkrav.

Processförbättringsaktiviteter bildar en kontinuerlig cykel med en återkopplingsslinga:

• Mät en eller flera egenskaper hos programvaruprocessen eller produkten. Dessa mätningar utgör en baslinje som hjälper till att avgöra om processförbättringarna har varit effektiva.
• Analysera den nuvarande processen och identifiera eventuella flaskhalsar.
• Ändra processen för att åtgärda några av de identifierade svagheterna i processen. Dessa införs och cykeln återupptas för att samla in data om förändringarnas effektivitet.

Processmätning

• Om möjligt bör kvantitativa processdata samlas in.
• Processmätningar bör användas för att utvärdera processförbättringar.
• Metri kan inkludera:
  • Tid som det tar för processaktiviteterna att slutföras, e.
  • Resurser som krävs för processer eller aktiviteter, t.ex. total insats i persondagar.
  • Antal förekomster av en viss händelse, t.ex. antal upptäckta defekter.

The SEI capability maturity model

• Initial: I huvudsak okontrollerad
• Repeterbar: Produkthanteringsförfaranden definieras och används
• Definierad: Processhanteringsförfaranden och -strategier definierade och använda
• Förvaltas: Strategier för kvalitetsstyrning definieras och används
• Optimering: Strategier för processförbättring definieras och används

.