Software-ontwikkelingsproces PDF

**[1.0 Inleiding]** - Doorheen jaren is ontwikkelen v/software enorm veranderd - Dit zorgde er ook voor dat er steeds meer nood was aan duidelijk kader waarmee project werd aangemaakt om die software te maken - Programma's werden steeds complexer maar ook steeds krachterige...

**[1.0 Inleiding]** - Doorheen jaren is ontwikkelen v/software enorm veranderd - Dit zorgde er ook voor dat er steeds meer nood was aan duidelijk kader waarmee project werd aangemaakt om die software te maken - Programma's werden steeds complexer maar ook steeds krachterige n meer diverse hardware zorgden er voor dat goed kader nodig was - Toch kunnen we voor elk software-ontwikkelingsproces terugvallen op 3 basiselementen - Om kwaliteit v/product te garanderen is noodzakelijk om tijdens ontwikkelingsproces rekening te houden met: - Scope \| Resources \| Budget - Is ! dat we een goeie afweging maken n er voor zorgen dat we product afleveren dat voldoende functionaliteit bevat die klant wilt maar ook binnen bepaalde kost n tijd kan worden opgeleverd - Klant wil uiteraard steeds luxueus n uitgebreide versie v/z'n programma tgn volgende week, maar wenst slechts te betalen voor basisversie - Is dus noodzakelijk om v/alle gewenste functionaliteiten duidelijke analyse te maken n te focussen op wat voor klant meest meerwaarde heeft zodat ook beschikbare budget n middelen kunnen gerespecteerd worden - Scope v/project bevat dan alle te realiseren functionaliteiten **[2.0 Hoe verloopt een project]** - Eens scope, middelen n budget vastliggen zou je kunnen denken dat we direct met programmeren aan slag kunnen - Softwareproject bestaat echter uit meer dan enkel maar coderen - Immers onmogelijk om project tot goede einde te brengen zonder aandacht te besteden aan andere facetten die betrekking hebben tot software - Dus zomaar starten met coderen is nooit goed idee leidt alleen maar tot meer werk nadien omdat het project zelden kan opgeleverd worden volgens noden v/klant - Om project meeste kansen op slagen te geven is nodig om min. volgende stappen uit te werken: - Analyse \| Ontwerp \| Programmeren \| Testen - Indien project ook ingepast moet worden i/bestaande structuur is er ook nood aan integratie **[3.0 Rollen]** - Team dat project zal uitwerken bestaat uit mensen die volgende rollen zullen vervullen: - Analist - = persoon die instaat voor correcte vertaling v/eisen v/klant, ook wel requirements genaamd, waaraan eindproduct zal moeten voldoen - Indien hij deze eisen x goed capteert, zal dit gevolgen hebben voor andere fases i/proces waardoor fouten alleen groter worden nrgelang project vordert - Anderzijds moet hij er ook voor zorgen dat ontwerpers duidelijk aan slag kunnen met die eisen - Moet dus enerzijds op x-technologische manier communiceren met klant, maar toch wel voldoende technisch met ontwerps - Voorbeeld v/!ste schema (dus ook communicatiemiddel), is domeinmodel - Ontwerper - Maakt vertaalslag v/x-technische stukken die gebruikt worden om vooral met klant te communiceren nr diepgaandere docs om door te kunnen geven aan programmeurs - Voorbeeld v/zo doc = sequence diagram met bijhorende operation contracts - Programmeur - Is rol die docs v/analist n ontwerper gebruikt om deze om te zetten i/juiste code met klassen n methodes om zo gewenste product met alle functionaliteiten te verwezenlijken - Tester - = persoon die er voor verantwoordelijk wordt gesteld alle fouten te vinden die kunnen optreden tijdens uitvoeren v/programma zodat deze nog voor release kunnen worden weggewerkt - Testen = x eenvoudig n vaak wordt ook verkeerde getest maar goede tester = noodzakelijk om kwaliteit v/programma te definiëren - Vanuit analyse is voornaamste doc dat tester kan gebruiken acitivity diagram omdat dit alle mogelijke wegen beschrijft die programma kan volgen bij uitvoeren v/functionaliteiten - Projectleider - = persoon die zoals naam al zegt project leidt - Neemt ook beslissingen of project nog verder gezet moet worden of x - Verzorgt ook juiste communicatie nr team, maar evenzeer nr klant als nr management - Daarnaast zijn er ook nog andere rollen betrokken die x rechtstreeks tot team behoren maar wel cruciale rol hebben i/proces - Klant / Opdrachtgever \| Management / Business **[4.0 Methodes]** ***4.1 Waterval*** - Historisch gezien is watervalmethode methode die ontwikkeld werd om projecten af te werken i/1 keer - Dit betekent dat, net zoals bij waterval, er na afwerken v/fase x meer terug kan gekeerd worden nr voorgaande fase - M.a.w. wordt alles i/volgorde uitgewerkt maar elke fase komt slechts 1 keer aan bod - Dit zorgt er natuurlijk voor dat alles op voorhand heel duidelijk moet zijn wat klant wil, want eens requirements zijn bepaald, komt volgende interactie met klant er pas bij oplevering v/project - Dit zorgt er uiteraard voor dat er heel geringe kans is dat project voldoet aan alle eisen v/klant - Hierdoor zullen er nog heel veel extra kosten volgen na oplevering op project om te vormen n aan te passen nr wat klant echt wil - Wil dit dan zeggen dat waterval helemaal x kan werken? Helemaal niet! - Voor kleine projecten waarbij doorlooptijd maar max. 3maanden, kan waterval werken perfect lukken ***4.2 Agile*** - Als antwoord op ontwikkelen via waterval methode n i/ene poging om grootste nadeel v/die methode weg te werken, zijnde gebrek aan feedback n communicatie met klant, werd Agile ontwikkeld - Agile (=wendbaar/flexibel) = methode die vooral inzet op opdelen v/project i/kleinere stukken (=iteraties) zodat makkelijker kan inspelen op wijzigen doorheen project - Per iteratie leggen we \# doelen (=milestones) vast die product moet kunnen bij einde v/periode - Ander voordeel v/project i/kleinere stukken uit te werken is mogelijkheid om zo sneller i/te spelen op veranderingen die doorheen project zullen optreden - Deze veranderingen kunnen enerzijds wisselende eisen zijn v/klant, maar anderzijds ook bv. wijzigingen i/hardware, nieuwe technologieën - Agile zelf is gebouwd rond 2 pijlers: iteratief & incrementeel - Iteratief betekent dat we software-ontwikkelingsproces \# keer gaan herhalen om zo i/kleine stukken volledige project af te werken - We delen volledig project op i/stukken n werken elk stuk v/functionaliteiten na elkaar uit met telkens analyse, ontwerp, implementatie, testen n integratie - Iteratie = typisch periode v/2 tot max. 6 weken n zorgt er zo voor dat klant snel feedback kan geven n dus ook sneller kan aangeven dat project x goeie richting uitgaat - Zo zakt projectrisico ook veel sneller dan bij waterval n kunnen we eventueel project ook sneller stopzetten om zo te veel overbodige kosten te vermijden - Incrementeel wil zeggen dat we project stap voor stap uitbreiden met nieuwe functionaliteiten - Is immers onmogelijk om alles i/1 keer te ontwikkelen dus zullen we steeds per iteratie !ste functionaliteiten toevoegen - Zo zorgen we er ook voor dat klant opnieuw snel werkbare software heeft die hij telkens ziet groeien n zo ook beter gepast feedback kan geven - Dit tegenoverstaande waterval waarbij klant pas op einde v/proces feedback kan geven, dus pas bij afgewerkt product