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

Een softwareproces is een gestructureerde reeks activiteiten die nodig zijn om een softwaresysteem te ontwikkelen. Merk op dat we het hebben over een “softwareproces” — niet over een “softwareontwikkelingsproces.”

Er zijn veel verschillende soorten softwareprocessen, maar elk van hen omvat deze vier soorten fundamentele activiteiten:

• Softwarespecificatie – definiëren wat het systeem moet doen;
• Softwareontwerp en -implementatie – de organisatie van het systeem definiëren en het systeem implementeren;
• Softwarevalidatie – controleren of het doet wat de klant wil;
• Software-evolutie – het veranderen van het systeem in reactie op veranderende behoeften van de klant.

Een softwareprocesmodel is een abstracte weergave van een proces. Het geeft een beschrijving van een proces vanuit een bepaald perspectief. Wanneer we softwareprocessen beschrijven en bespreken, hebben we het meestal over de activiteiten in deze processen, zoals het specificeren van een gegevensmodel, het ontwerpen van een gebruikersinterface, enz. en de volgorde van deze activiteiten.Procesbeschrijvingen kunnen ook bevatten:

• Producten, die de uitkomsten zijn van een procesactiviteit;
• Rollen, die de verantwoordelijkheden weergeven van de mensen die bij het proces betrokken zijn;
• Pre- en post-condities, dat zijn uitspraken die waar zijn voordat en nadat een procesactiviteit is uitgevoerd of een product is geproduceerd.

Plangestuurde processen zijn processen waarbij alle procesactiviteiten van tevoren zijn gepland en de voortgang wordt afgemeten aan dit plan. Bij agile processen is de planning incrementeel en is het eenvoudiger het proces aan te passen aan veranderende eisen van de klant. In de praktijk bevatten de meeste praktische processen elementen van zowel een plangestuurde als een agile aanpak.

Het watervalmodel Plan-gedreven model. Afzonderlijke en afzonderlijke fasen van specificatie, softwareontwerp, implementatie, testen en onderhoud. Incrementele ontwikkeling Specificatie, ontwikkeling en validatie lopen in elkaar over. Het systeem wordt ontwikkeld als een reeks versies (incrementen), waarbij elke versie functionaliteit toevoegt aan de vorige versie. Kan planmatig of wendbaar zijn. Integratie en configuratie Gebaseerd op het bestaan van een significant aantal herbruikbare componenten/systemen. Het systeemontwikkelingsproces concentreert zich op het integreren van deze componenten in een systeem eerder dan ze van nul af aan te ontwikkelen. Kan planmatig of agile zijn.

In de praktijk worden de meeste grote systemen ontwikkeld met behulp van een proces waarin elementen van al deze modellen zijn verwerkt.

Het watervalmodel kent afzonderlijke fasen:

Analyse en definitie van de eisen De diensten, beperkingen en doelstellingen van het systeem worden vastgesteld in overleg met de gebruikers van het systeem. Deze worden vervolgens in detail gedefinieerd en dienen als systeemspecificatie. Systeem- en softwareontwerp Het systeemontwerpproces wijst de eisen toe aan hard- of softwaresystemen door een algemene systeemarchitectuur vast te stellen. Het softwareontwerp omvat het identificeren en beschrijven van de fundamentele softwaresysteemabstracties en hun relaties. Implementatie en unit testing In dit stadium wordt het softwareontwerp gerealiseerd als een reeks programma’s of programma-eenheden. Bij het testen van de eenheden wordt geverifieerd of elke eenheid aan de specificatie voldoet. Integratie en systeemtesten De afzonderlijke programma-onderdelen of programma’s worden geïntegreerd en getest als een volledig systeem om te verzekeren dat aan de software-eisen is voldaan. Na het testen wordt het softwaresysteem aan de klant geleverd. Gebruik en onderhoud Normaal gesproken (hoewel niet noodzakelijk) is dit de langste levenscyclusfase. Het systeem wordt geïnstalleerd en in de praktijk gebruikt. Het onderhoud omvat het corrigeren van fouten die in eerdere fasen van de levenscyclus niet zijn ontdekt, het verbeteren van de uitvoering van systeemeenheden en het verbeteren van de diensten van het systeem naarmate nieuwe eisen worden ontdekt.

Het grootste nadeel van het watervalmodel is de moeilijkheid om veranderingen op te vangen nadat het proces is begonnen. In principe moet een fase voltooid zijn voordat naar de volgende fase kan worden overgegaan. De problemen van het watervalmodel zijn onder meer:

Moeilijk om op veranderingen in te spelen De inflexibele verdeling van het project in verschillende fasen maakt het moeilijk om op veranderende eisen van de klant te reageren.Daarom is dit model alleen geschikt wanneer de eisen goed begrepen zijn en de veranderingen tijdens het ontwerpproces vrij beperkt zullen zijn. Weinig bedrijfssystemen hebben stabiele vereisten. Het watervalmodel wordt meestal gebruikt voor grote systeemontwikkelingsprojecten waarbij een systeem op verschillende plaatsen wordt ontwikkeld. In die omstandigheden helpt het planmatige karakter van het watervalmodel om het werk te coördineren.

Voordelen van incrementele ontwikkeling:

Lagere kosten van wijzigingen De kosten van het tegemoetkomen aan veranderende eisen van de klant worden verlaagd. De hoeveelheid analyse en documentatie die opnieuw moet worden gemaakt, is veel minder dan nodig is bij het watervalmodel. Frequente feedback Het is gemakkelijker om klantenfeedback te krijgen over het ontwikkelingswerk dat is gedaan. Klanten kunnen commentaar geven op demonstraties van de software en zien hoeveel er is geïmplementeerd. Snellere oplevering Een snellere oplevering en uitrol van bruikbare software naar de klant is mogelijk. Klanten zijn in staat de software eerder te gebruiken en er waarde uit te halen dan mogelijk is met een watervalproces.

Problemen met incrementele ontwikkeling (vanuit het managementperspectief):

Het proces is niet zichtbaar Managers hebben regelmatige deliverables nodig om de voortgang te meten. Als systemen snel worden ontwikkeld, is het niet kosteneffectief om documenten te produceren die elke versie van het systeem weergeven. De structuur van het systeem heeft de neiging te verslechteren naarmate nieuwe incrementen worden toegevoegd Tenzij tijd en geld worden besteed aan refactoring om de software te verbeteren, heeft regelmatige verandering de neiging de structuur ervan te corrumperen. Het wordt steeds moeilijker en kostbaarder om verdere wijzigingen in de software op te nemen.

Deze benadering is gebaseerd op systematisch hergebruik waarbij systemen worden geïntegreerd uit bestaande componenten of COTS (Commercial-off-the-shelf)-systemen.Procesfasen omvatten:

• Analyse van componenten;
• Aanpassing van eisen;
• Systeemontwerp met hergebruik;
• Ontwikkeling en integratie.

Hergebruik is nu de standaardaanpak voor het bouwen van veel soorten bedrijfssystemen.

Typen softwarecomponenten:

• Webservices die zijn ontwikkeld volgens servicenormen en die beschikbaar zijn voor aanroep op afstand.
• Objectenverzamelingen die zijn ontwikkeld als pakket om te worden geïntegreerd met een componentenframework zoals .NET of J2EE.
• Stand-alone commercial-off-the-shelf-systemen (COTS) die zijn geconfigureerd voor gebruik in een bepaalde omgeving.

Echte softwareprocessen zijn opeenvolgende opeenvolgingen van technische, collaboratieve en bestuurlijke activiteiten met als algemeen doel het specificeren, ontwerpen, implementeren en testen van een softwaresysteem.

De vier basisprocesactiviteiten van specificatie, ontwikkeling, validatie en evolutie zijn verschillend georganiseerd in verschillende ontwikkelingsprocessen. In het watervalmodel worden ze in volgorde georganiseerd, terwijl ze bij incrementele ontwikkeling door elkaar lopen.

Software specificatie Het proces waarbij wordt vastgesteld welke diensten vereist zijn en welke beperkingen gelden voor de werking en ontwikkeling van het systeem. Requirements engineering proces:

• Haalbaarheidsstudie: is het technisch en financieel haalbaar om het systeem te bouwen?
• Requirements elicitation and analysis: wat eisen of verwachten de stakeholders van het systeem?
• Requirements specification: het in detail definiëren van de requirements
• Requirements validation: het controleren van de geldigheid van de requirements

Software design and implementation Het proces van het omzetten van de systeemspecificatie in een uitvoerbaar systeem.

• Softwareontwerp: ontwerpen van een softwarestructuur die de specificatie realiseert;
• Implementatie: vertalen van deze structuur in een uitvoerbaar programma;

De activiteiten van ontwerp en implementatie zijn nauw verwant en kunnen worden afgewisseld. Ontwerpactiviteiten omvatten:

• Architectonisch ontwerp: identificeren van de algemene structuur van het systeem, de belangrijkste componenten (soms subsystemen of modules genoemd), hun relaties en hoe ze zijn verdeeld.
• Interface-ontwerp: definiëren van de interfaces tussen systeemcomponenten.
• Component ontwerp: neem elke systeemcomponent en ontwerp hoe het zal werken.
• Database ontwerp: ontwerp de systeem data structuren en hoe deze moeten worden weergegeven in een database.

Softwarevalidatie Verificatie en validatie (V & V) is bedoeld om aan te tonen dat een systeem voldoet aan zijn specificatie en aan de eisen van de systeemklant.

• Validatie: bouwen we het juiste product (wat de klant wil)?
• Verificatie: bouwen we het product juist?

V & V omvat controle- en beoordelingsprocessen en systeemtesten. Systeemtesten houdt in dat het systeem wordt uitgevoerd met testgevallen die zijn afgeleid van de specificatie van de werkelijke gegevens die door het systeem moeten worden verwerkt. Testen is de meest gebruikte V & V activiteit en omvat de volgende fasen:

• Ontwikkelings- of componenttesten: afzonderlijke componenten worden onafhankelijk getest; componenten kunnen functies of objecten zijn of samenhangende groeperingen van deze entiteiten.
• Systeemtesten: testen van het systeem als geheel, het testen van emergente eigenschappen is bijzonder belangrijk.
• Acceptatietesten: testen met klantgegevens om te controleren of het systeem aan de behoeften van de klant voldoet.

Software-evolutie Software is van nature flexibel en kan veranderen. Naarmate de eisen veranderen door veranderende bedrijfsomstandigheden, moet ook de software die het bedrijf ondersteunt, evolueren en veranderen.Hoewel er een afbakening is geweest tussen ontwikkeling en evolutie (onderhoud), is dit steeds minder relevant omdat steeds minder systemen volledig nieuw zijn.

Verandering is onvermijdelijk in alle grote softwareprojecten.Veranderingen in de bedrijfsvoering leiden tot nieuwe en gewijzigde systeemvereistenNieuwe technologieën openen nieuwe mogelijkheden voor het verbeteren van implementaties.Veranderende platforms vereisen applicatieveranderingen.Verandering leidt tot herbewerking, dus de kosten van verandering omvatten zowel herbewerking (bijv.b.v. het opnieuw analyseren van eisen) als de kosten van het implementeren van nieuwe functionaliteit.

Twee strategieën om de kosten van rework te verminderen:

Change avoidance Het softwareproces omvat activiteiten die kunnen anticiperen op mogelijke veranderingen voordat significant rework nodig is. Er kan bijvoorbeeld een prototype van het systeem worden ontwikkeld om enkele belangrijke kenmerken van het systeem aan klanten te laten zien. Wijzigingstolerantie Het proces is zo opgezet dat wijzigingen tegen betrekkelijk lage kosten kunnen worden verwerkt. Dit impliceert gewoonlijk een vorm van incrementele ontwikkeling. Voorgestelde wijzigingen kunnen worden doorgevoerd in incrementen die nog niet zijn ontwikkeld. Indien dit onmogelijk is, kan het zijn dat slechts een enkel increment (een klein deel van het systeem) hoeft te worden gewijzigd om de wijziging te verwerken.

Een prototype is een eerste versie van een systeem dat wordt gebruikt om concepten te demonstreren en ontwerpopties uit te proberen. Een prototype kan worden gebruikt in:

• Het requirements engineering-proces om te helpen bij requirements elicitatie en validatie;
• In ontwerpprocessen om opties te verkennen en een UI-ontwerp te ontwikkelen;
• In het testproces om back-to-back tests uit te voeren.

Voordelen van prototyping:

• Betere bruikbaarheid van het systeem.
• Nauwere aansluiting bij de werkelijke behoeften van gebruikers.
• Betere ontwerpkwaliteit.
• Betere onderhoudbaarheid.
• Verlaagde ontwikkelingsinspanning.

Prototypen kunnen zijn gebaseerd op rapid prototyping talen of tools. Ze kunnen inhouden dat functionaliteit wordt weggelaten:

• Prototype moet zich richten op gebieden van het product die niet goed worden begrepen;
• Foutcontrole en herstel mogen niet worden opgenomen in het prototype;
• Focus op functionele in plaats van niet-functionele eisen, zoals betrouwbaarheid en veiligheid.

Prototypen moeten na ontwikkeling worden afgedankt, omdat ze geen goede basis vormen voor een productiesysteem:

• Het kan onmogelijk zijn het systeem af te stemmen op niet-functionele eisen;
• Prototypen zijn gewoonlijk niet gedocumenteerd;
• De prototype-structuur wordt gewoonlijk aangetast door snelle verandering;
• Het prototype zal waarschijnlijk niet voldoen aan de normale kwaliteitsnormen van de organisatie.

In plaats van het systeem in één keer op te leveren, wordt de ontwikkeling en oplevering opgedeeld in incrementen, waarbij elk increment een deel van de vereiste functionaliteit oplevert.De gebruikerseisen worden geprioriteerd en de eisen met de hoogste prioriteit worden opgenomen in de eerste incrementen. Zodra de ontwikkeling van een increment is gestart, worden de eisen bevroren, hoewel de eisen voor latere incrementen kunnen blijven evolueren.

Voordelen van incrementele levering:

• De waarde voor de klant kan met elk increment worden geleverd, zodat de systeemfunctionaliteit eerder beschikbaar is.
• Eerste incrementen fungeren als een prototype om te helpen eisen voor latere incrementen te eliciteren.
• Lager risico van algehele mislukking van het project.
• De hoogste prioriteit systeem diensten hebben de neiging om de meeste testen te ontvangen.

Incrementele oplevering problemen:

• De meeste systemen vereisen een set van basisvoorzieningen die worden gebruikt door verschillende delen van het systeem. Aangezien de eisen pas in detail worden gedefinieerd wanneer een increment moet worden geïmplementeerd, kan het moeilijk zijn om gemeenschappelijke faciliteiten te identificeren die door alle incrementen nodig zijn.
• De essentie van iteratieve processen is dat de specificatie wordt ontwikkeld in samenhang met de software. Dit is echter in strijd met het inkoopmodel van veel organisaties, waar de volledige systeemspecificatie deel uitmaakt van het systeemontwikkelingscontract.

Veel softwarebedrijven hebben zich gewend tot verbetering van softwareprocessen als een manier om de kwaliteit van hun software te verbeteren, de kosten te verlagen of hun ontwikkelingsprocessen te versnellen. Procesverbetering houdt in dat inzicht wordt verkregen in bestaande processen en dat deze processen worden gewijzigd om de productkwaliteit te verhogen en/of de kosten en ontwikkelingstijd te verlagen.

Procesvolwassenheidsbenadering Richt zich op het verbeteren van proces- en projectbeheer en het invoeren van goede software engineeringpraktijken. Het niveau van procesvolwassenheid weerspiegelt de mate waarin goede technische en managementpraktijken zijn overgenomen in de softwareontwikkelingsprocessen van de organisatie. Agile aanpak Nadruk op iteratieve ontwikkeling en de vermindering van overheadkosten in het softwareproces. De primaire kenmerken van agile methoden zijn snelle levering van functionaliteit en het inspelen op veranderende eisen van de klant.

Procesverbeteringsactiviteiten vormen een continue cyclus met een feedback-loop:

• Meet een of meer attributen van het softwareproces of -product. Deze metingen vormen een basislijn die helpt beslissen of procesverbeteringen effectief zijn geweest.
• Analyseer het huidige proces en identificeer eventuele knelpunten.
• Wijzig het proces om enkele van de geïdentificeerde proceszwakheden aan te pakken. Deze worden ingevoerd en de cyclus wordt hervat om gegevens te verzamelen over de effectiviteit van de veranderingen.

Procesmeting

• Waar mogelijk moeten kwantitatieve procesgegevens worden verzameld.
• Procesmetingen moeten worden gebruikt om procesverbeteringen te beoordelen.
• Metingen kunnen het volgende omvatten:
  • De tijd die nodig is voor procesactiviteiten om te worden voltooid, bijv.b.v. kalendertijd of inspanning om een activiteit of proces te voltooien.
  • Resources required for processes or activities, b.v. total effort in person-days.
  • Number of occurrences of a particular event, b.v. number of defects discovered.

The SEI capability maturity model

• Initial: In essentie ongecontroleerd
• Herhaalbaar: Product management procedures gedefinieerd en gebruikt
• Gedefinieerd: Procesmanagement procedures en strategieën gedefinieerd en gebruikt
• Beheerd: Kwaliteitsmanagement strategieën gedefinieerd en gebruikt
• Optimaliseren: Procesverbeteringsstrategieën gedefinieerd en gebruikt