Software analysis Flashcards
(13 cards)
Het software-ontwikkelingsproces
Het ontwikkelen van software is enorm veranderd. Hierdoor meer nood aan een duidelijk kader waarmee een project werd aangemaakt. Bij software-ontwikkelingsproces kunnen we terugvallen op drie basiselementen. Men moet rekening houden met volgende pijlers:
1. scope
2. resources
3. budget
Groot belang om goeie afweging te maken en een product af te leveren dat voldoende functionaliteit bevat die de klant wilt maar ook binnen een bepaalde kost en tijd kan worden opgeleverd. Duidelijke analyse maken… De scope van het project bevat dan alle te realiseren functionaliteiten
Hoe verloopt een project?
Eens de scope, middelen en budget vastliggen niet meteen beginnen coderen! Meer dan dat. Om het project de meeste kansen op slagen te geven is het nodig om minstens volgende stappen uit te werken: analyse, ontwerp, programmeren, testen. Indien het project ook ingepast moet worden in bestaande structuur is er ook nood aan integratie.
Rollen Software-ontwikkelingsproces.
Het team dat het project zal uitwerken bestaat uit mensen die volgende rollen zullen vervullen:
1. Analist
2. Ontwerper
3. Programmeur
4. Tester
5. Projectleider
Daarnaast ook andere rollen betrokken die niet rechtstreeks tot het team behoren maar wel een cruciale rol hebben in het proces.
1. Klant/opdrachtgever
2. Management/business
Projectleider Software-ontwikkelingsproces
De projectleider is de persoon die het project leidt. Hij neemt beslissingen of het project nog verder moet gezet worden of niet. Hij verzorgt ook de juiste communicatie naar het team, maar evenzeer naar de klant als naar het management
Analist software-ontwikkelingsproces
De analist staat in voor een correcte vertaling van de eisen van de klant, ook wel requirements genoemd, waaran het eindproduct zal moeten voldoen. Indien analist deze niet goed capteert, gevolgen voor andere fases. De analist zorgt er ook voor dat de ontwerpers duidelijk aan de slag kunnen met die eisen. Hij moet dus enerzijds op een niet-technologische manier communiceren met de klant, maar toch wel voldoende technisch met de ontwerpers.
Een voorbeeld van het belangrijkste schema, en dus ook communicatiemiddel is het domeinmodel
Ontwerper Software-ontwikkelingsproces
Ontwerper maakt de vertaalslag van de niet-technische stukken die gebruikt worden om vooral met de klant te communiceren naar diepgaande documenten om door te kunnen geven aan de programmeurs. Vb: sequence diagram met bijhorende operation contracts
Programmeur Software-ontwikkelingsproces
Programmeur is de rol die de documenten van de analist en ontwerper gebruikt om deze om te zetten in de juiste code met klassen en methodes om zo het gewenste product met alle functionaliteiten te verwerzenlijken
Tester Software-ontwikkelingsproces
De tester is verantwoordelijk alle fouten te vinden die kunnen optreden tijdens het uitvoeren van het programma zodat deze voor release kunnen worden weggewerkt. Tester gebruikt het activity diagram omdat dit alle mogelijke wegen beschrijft die het programma kan volgen bij het uitvoeren van de functionaliteiten
Waterval methode
Historisch gezien een methode om projecten in 1 keer af te werken. Na het afwerken van een fase niet meer teruggekeerd kan worden naar een voorgaande fase. Alles wordt in volgorde afgewerkt maar elke fase komt slechts één keer aan bod. Alles moet dus op voorhand heel duidelijk zijn wat de klant wil want eens de requirements bepaald zijn komt de volgende interactie met de klant pas bij de oplevering van het project.
Hierdoor is de kans groot dat het project niet voldoet aan alle eisen van de klant. Zorgt dan voor extra kosten als er nog aanpassingen moeten gebeuren.
Waterval kan nog wel perfect lukken bij kleinere projecten
Agile methode
Agile (= wendbaar/flexibel) is een methode die vooral inzet op het opdelen van het project in kleinere stukken(= iteraties) zodat het makkelijker kan inspelen op de wijzigingen doorheen het project. Per iteratie leggen we een aantal doelen (=milestones) vast die het product moet kunnen bij het einde van de periode.
Agile zelf is gebouwd rond 2 pijlers: iteratief & incrementeel
Iteratief betekent dat we het software-ontwikkelingsproces een aantal keer gaan herhalen om zo in kleine stukken het volledig project af te werken. We delen het volledig project op in stukken en werken elk stuk van functionaliteiten na elkaar uit met telkens een analyse, ontwerp, implementatie, testen en integratie. Een integratie is typisch een periode van 2 tot maximaal 6 weken en zorgt er zo voor dat de klant snel feedback kan geven en dus ook sneller kan aangeven dat het project niet de goeie richting uitgaat. Zo zakt het projectrisico ook veel sneller dat bij waterval en kan het project sneller worden stopgezet om zo overbodige kosten te vermijden.
Incrementeel wil zeggen dat we het project stap voor stap uitbreiden met nieuwe functionaliteiten. Het is immers onmogelijk om alles in één keer te ontwikkelen dus zullen we steeds per iteratie de belangrijkste functionaliteiten toevoegen. Zo zorgen we er ook voor dat de klant opnieuw snel werkbare software heeft die hij telkens ziet groeien en zo ook beter gepaste feedback kan geven.
Agile Stappenplan
- De opdrachtgever formuleert het probleem
- Analist noteert het verhaal en de eisen of behoeften
- Analist stelt een Use Case Diagram op met betrokken rollen en use cases
- Analist vertaalt het verhaal naar use cases
- Analist stelt aan de hand van use case(s) het domeinmodel op
- Analist stelt per use case een activity diagram op met het oog op testen
- Analist stelt per use case, voor minstens het normaal verloop, een Systeem Sequentie Diagram (SSD) op met bijhorende Operation Contracts (OC)
UML
Unified modeling language
Een modelleertaal om objectgeoriënteerde analyses en ontwerpen voor een informatiesysteem te kunnen maken
UML zelf is geen methode , maar een notatiewijze die bij verschillende methodes kan worden gebruikt
Voorbeelden slides
Vereisten behoeftenanalyse
De behoeften van de klant waaraan het project moet voldoen worden ook wel vereisten genoemd. We kunnen de behoeften opdelen in 2 categorieën: functionele vereisten en niet-functionele vereisten
Functionele vereisten zijn de eisen die beschrijven w
