SDLC ontrafeld: fasen, modellen en de cruciale rol van Artefacten

De Software Development Life Cycle (SDLC): Structuur, stappen en tastbare resultaten

De Software Development Life Cycle (SDLC) is de ruggengraat van elk succesvol softwareproject. Het is het gestructureerde kader dat bepaalt wát we moeten doen (de fasen), maar het is geen methode. Of we nu kiezen voor een strak georganiseerde aanpak zoals de Watervalmethode of de flexibele, iteratieve aanpak van Agile en Scrum, het succes van het project staat of valt altijd bij duidelijke output en controleerbare artefacten.

Dit artikel ontrafelt de SDLC als het universele proces en belicht de cruciale rol van artefacten, de tastbare bijproducten van dit proces. We bekijken hoe deze artefacten, samen met deliverables en mijlpalen, niet alleen de voortgang meten, maar ook de noodzakelijke flexibiliteit bieden om tijdens de reis van methodiek te veranderen, zonder de focus en de kwaliteit te verliezen.

Wat is SDLC?

SDLC staat voor Software Development Life Cycle (Levenscyclus voor Softwareontwikkeling). Het is een systematisch proces dat een gestructureerde aanpak biedt voor het plannen, creëren, testen en implementeren van hoogwaardige software.

Het doel van de SDLC is om een efficiënte en georganiseerde workflow te garanderen, zodat het eindproduct voldoet aan de eisen van de gebruiker en binnen het gestelde budget en de tijdlijn wordt opgeleverd.

De belangrijkste fasen van de SDLC (het abstracte kader)

Hoewel de exacte namen en het aantal fasen per model kunnen variëren, omvat een typische SDLC de volgende kernstappen. Dit zijn de generieke stappen die we in elk softwareontwikkelingsproces moeten doorlopen:

1. Planning: De haalbaarheid van het project wordt beoordeeld. Hier definiëren we de projectdoelen, scope, middelen (tijd, budget) en risico’s.
2. Analyse van vereisten (Requirements): Hier verzamelen we de behoeften van de klant en alle belanghebbenden. Vervolgens vindt er analyse en documentatie plaats.
3. Ontwerp (Design): Op basis van de vereisten wordt de architectuur en de structuur van de software ontworpen.
4. Implementatie/Ontwikkeling (Coding): De ontwikkelaars schrijven de daadwerkelijke code volgens de specificaties uit de ontwerpfase.
5. Testen: De software testen we rigoureus om ervoor te zorgen dat deze aan de oorspronkelijke eisen voldoet en tevens vrij is van fouten (bugs).
6. Implementatie (Deployment): De software wordt geïnstalleerd en vervolgens geactiveerd in de productieomgeving.
7. Onderhoud: De software houden we bij, en bovendien lossen we waar nodig, op basis van feedback, fouten op.

Wat zijn artefacten?

Artefacten in de context van softwareontwikkeling zijn de tastbare uitkomsten, documenten of componenten die tijdens het ontwikkelproces worden gecreëerd en gebruikt. Ze dienen als bewijs van de uitgevoerde werkzaamheden, bieden de nodige context en zijn de input voor de volgende fase.

Kortom: Artefacten zijn de “producten” van het ontwikkelproces, naast de uiteindelijke software zelf.

Waarom artefacten belangrijk zijn

Artefacten zijn essentieel voor het succes van een softwareproject om de volgende redenen:

• Transparantie: Ze maken de voortgang en de beslissingen inzichtelijk voor alle belanghebbenden.
• Kennisbehoud: Ze zorgen ervoor dat informatie niet verloren gaat wanneer teamleden vertrekken.
• Kwaliteitsborging: Documenten zoals testplannen bewijzen dat de software aan de eisen voldoet.
• Traceerbaarheid: Ze leggen een link tussen de oorspronkelijke eisen en de uiteindelijke code.

Opsomming van de meest generieke SDLC -artefacten

Hier is een overzicht van de universele artefacten die toepasbaar zijn in iedere ontwikkelmethode. In vrijwel elke SDLC-fase produceren ontwikkelaars dus artefacten:

Categorie	Artefact	Beschrijving	Belangrijkste Doel
Requirements	Eisen Specificatie	Een formeel document dat alle eisen van de klant gedetailleerd beschrijft.	De basislijn vastleggen voor de scope en de functionaliteit.
Requirements	Gebruiksscenario’s/User Stories	Beschrijven hoe een gebruiker met het systeem interageert (bv. “Als klant wil ik in kunnen loggen”).	Vastleggen van de gebruikersbehoeften.
Ontwerp	Systeem-/Software-Architectuur	Een blauwdruk die de structuur, componenten, interfaces en de relaties daartussen beschrijft.	Dient als leidraad voor de technische consistentie en schaalbaarheid.
Ontwerp	Database Schema	Visuele representatie van de structuur van de data, inclusief tabellen en relaties.	Zorgt ervoor dat de data correct en efficiënt wordt opgeslagen.
Ontwerp	User Interface (UI) Mockups	Visuele schetsen of modellen van hoe de schermen en interacties eruit zullen zien.	Goedkeuring krijgen over de gebruikerservaring.
Implementatie	Broncode	De geschreven code in de programmeertaal die de functionaliteit van de software definieert.	Het kernproduct van de ontwikkelingsfase.
Test	Testgevallen en Testscenario’s	Gedetailleerde stappen, invoer en verwachte resultaten om de software te valideren.	Bewijzen dat de software voldoet aan de eisen en kwaliteit levert.
Test	Testrapporten	Documenten die de resultaten van het testen vastleggen, inclusief gedetecteerde bugs en hun status.	Bieden transparantie over de kwaliteit en risico’s.
Management	(Product) Backlog	Een geprioriteerde en dynamische lijst van alles wat nodig is voor het product (functies, bugs).	Dient als de enkele bron van waarheid voor het te verrichten werk.

Artefacten versus deliverables en mijlpalen

De termen artefact, deliverable en mijlpaal zijn verwant, maar verschillen in hun functie:

Term	Wat is het?	Type	Focus
Artefact	Een bijproduct van het werk. Elk document, bestand of stuk code dat tijdens het proces ontstaat.	Interne output	Het vastleggen van informatie en context.
Deliverable	Een afgesproken, tastbaar resultaat dat wordt geleverd aan een klant of belanghebbende.	Externe output	Het voldoen aan de klanteis en het leveren van waarde.
Mijlpaal	Een punt in de tijd dat een belangrijke gebeurtenis markeert.	Tijd/Gebeurtenis	Het meten van voortgang en het afronden van een fase.

Belangrijkste Verschil:

• De ruwe broncode is een artefact.
• De werkende, geïnstalleerde applicatie is de deliverable.
• “Ontwerp Goedgekeurd” is een mijlpaal, die we bereiken wanneer het Ontwerpdocument (de deliverable) is ondertekend.

SDLC -modellen: waterval versus abstractie

De SDLC die we beschreven lijkt op het eerste gezicht op een watervalmethode maar is abstracter dan dat. De SDLC is namelijk het fundamentele kader dat stelt: “Om van een idee naar een werkend softwaresysteem te komen, moet je deze basisactiviteiten uitvoeren.” Het beschrijft wat we moeten doen (eisen verzamelen, ontwerpen, bouwen), maar niet hoe of in welke volgorde.

Een SDLC-model is de concrete implementatie van dat abstracte kader en bepaalt de specifieke volgorde:

• Watervalmethode: Volgt de abstracte fasen in een strikt sequentiële, lineaire volgorde.
• Agile/Scrum: De complete SDLC-cyclus herhalen we in kleine, snelle iteraties (Sprints). We plannen, ontwerpen, bouwen en testen kleine stukjes functionaliteit daardoor constant opnieuw.

Kortom, de SDLC is de theorie, en de Watervalmethode en Scrum zijn slechts twee van de vele praktische modellen om die theorie uit te voeren.

De cruciale rol van artefacten bij methodeverandering

Artefacten zijn dus onafhankelijk van de methode te herkennen en in te passen, maar ze zijn niet de kleinst denkbare producten (taken en deeltaken zijn kleiner). Ze zijn echter cruciaal omdat ze de brug vormen bij een verandering van methodiek.

Als we van methode willen veranderen tijdens een project, is het essentieel om te beginnen met de bestaande artefacten van de “oude” methode. Tijdens dit proces kunnen we gewoon doorwerken in de oude methode maar met toepassing van de nieuwe artefacten.

Overbrugging door artefacten

Artefacten maken een overstap gemakkelijker door:

1. Kennisoverdracht: Artefacten zoals de Eisen Specificatie (uit Waterval) kunnen we direct omgezetten in items op de Product Backlog (in Scrum). Zonder deze documenten zouden we moeten gissen naar de volledige scope.
2. Controlepunten: Een voltooid artefact (bv. Goedgekeurd Basisontwerp) dient als een vast beginpunt voor de eerste sprint in een nieuwe methode.

De bestaande artefacten zijn de enige objectieve bron van waarheid over wat er is gedaan en wat er moet gebeuren. Ze transformeren een methodeverandering van een sprong in het diepe in een gecontroleerde kennisoverdracht.

Conclusie: de SDLC, artefacten en flexibiliteit

De Software Development Life Cycle (SDLC) is het universele, abstracte kader van wat er moet gebeuren om software te maken (plannen, bouwen, testen). De keuze voor een specifieke methodologie bepaalt hoe en wanneer die stappen worden uitgevoerd.

De cruciale verbindende factor in dit proces is de rol van artefacten.

Artefacten zijn de sleutel tot flexibiliteit en succes, ongeacht de methode.

Ieder softwareproject, van het meest rigide tot het meest flexibele, produceert logische artefacten. Deze documenteren niet alleen de voortgang en de besluitvorming, maar vergemakkelijken ook de overgang tussen verschillende SDLC-modellen. Dit is omdat ze zorgen voor de noodzakelijke kennisoverdracht en voorkomen dat we het project bij een verandering van methode opnieuw moeten uitvinden. Kortom, of een organisatie nu kiest voor de strikte structuur van Waterval of de adaptieve cyclus van Agile, een goed beheer en gebruik van artefacten is de belangrijkste voorwaarde om de kwaliteit van de software te waarborgen en te kunnen reageren op onvermijdelijke veranderingen in het project.

Discussieer mee op ITpedia LinkedIn of op Financial Executives LinkedIn.