de traditionele Watervalbenadering
De Watervalbenadering voor systeemanalyse en-ontwerp was de eerste gevestigde moderne benadering van het bouwen van een systeem. Deze methode werd oorspronkelijk gedefinieerd door Winston W. Royce in 1970, (“The Waterfall Development Methodology”, 2006). Het kreeg snel steun van managers omdat alles logisch verloopt vanaf het begin van een project tot het einde (Jonasson, 2008)., Bronnen verschillen als het gaat om de specifieke stappen in het Watervalproces (Jonasson, 2008), en Ik zal een aantal van deze verschillen in de volgende paragraaf. Echter, de fundamentele onderliggende logica en stappen presenteren zich in elke interpretatie.
figuur 1: watervalmethode
(“The Waterfall Development Methodology”, 2006)
de oorspronkelijke watervalmethode, zoals ontwikkeld door Royce, is opgenomen in Figuur 1. De stappen omvatten eisen bepaling, ontwerp, implementatie, verificatie en onderhoud., Andere modellen veranderen de vereisten fase in de idee fase (Jonasson, 2008), of breken de vereisten fase uit in Planning en analyse (Hoffer, George, Valacich, 2008). Bovendien breken sommige modellen de ontwerpfase verder uit in logische en fysieke ontwerp subfasen (Hoffer, et al, 2008). Zoals eerder vermeld, blijven de basisprincipes echter dezelfde.
bij de watervalmethode wordt ervan uitgegaan dat alle vereisten vooraf kunnen worden verzameld tijdens de vereisten-fase (Kee, 2006)., De communicatie met de gebruiker wordt vooraf geladen in deze fase, omdat de projectmanager zijn of haar best doet om een gedetailleerd inzicht te krijgen in de behoeften van de gebruiker. Zodra deze fase is voltooid, loopt het proces “downhill” (Hoffer, et al, 2008).
de ontwerpfase kan het best worden beschreven door deze op te splitsen in logische en fysieke ontwerp subfasen. Tijdens de logische ontwerpfase maken de analisten van het systeem gebruik van de informatie die is verzameld in de vereisten-fase om het systeem onafhankelijk van een hardware-of softwaresysteem te ontwerpen (Hoffer, et al, 2008)., Zodra het logische ontwerp op hoger niveau is voltooid, begint de systeemanalist het om te zetten in een fysiek ontwerp dat afhankelijk is van de specificaties van specifieke hardware-en softwaretechnologieën (“Software Development Lifecycle”, n.d.)
de implementatiefase is wanneer alle werkelijke code wordt geschreven (“SDLC Phases”, n.d.). Deze fase behoort toe aan de programmeurs in de waterval methode, omdat zij de projectvereisten en specificaties nemen en de applicaties coderen.,
De verificatiefase werd oorspronkelijk gevraagd door Royce om ervoor te zorgen dat het project voldoet aan de verwachtingen van de klant. Echter, bij Real-world analyse en ontwerp, wordt deze fase vaak genegeerd. Het project wordt uitgerold naar de klant en de onderhoudsfase begint.
tijdens de onderhoudsfase gebruikt de klant de ontwikkelde applicatie. Als er problemen worden gevonden Als gevolg van onjuiste eisen bepaling of andere fouten in het ontwerpproces, of als gevolg van wijzigingen in de eisen van de gebruikers, wijzigingen worden aangebracht in het systeem tijdens deze fase. (“SDLC fasen”, n. d.).,
de watervalmethode heeft bepaalde voordelen, waaronder:
- ontwerpfouten worden vastgelegd voordat software wordt geschreven, waardoor tijd wordt bespaard tijdens de implementatiefase.
- uitstekende technische documentatie maakt deel uit van de te leveren producten en het is gemakkelijker voor nieuwe programmeurs om op snelheid te komen tijdens de onderhoudsfase.
- de aanpak is zeer gestructureerd en het is gemakkelijker om de vooruitgang te meten aan de hand van duidelijk gedefinieerde mijlpalen.,
- de totale kosten van het project kunnen nauwkeurig worden geschat nadat de vereisten zijn gedefinieerd (via de functionele specificaties en de specificaties van de gebruikersinterface). het testen van
- is eenvoudiger omdat dit kan worden gedaan aan de hand van de scenario ‘ s die zijn gedefinieerd in de functionele specificatie (“The Waterfall Development Methodology”, 2006).,
helaas brengt de watervalmethode nogal wat nadelen met zich mee, zoals:
- cliënten zullen het vaak moeilijk vinden om hun vereisten op het abstracte niveau van een functionele specificatie te vermelden en zullen alleen volledig waarderen wat nodig is wanneer de toepassing wordt geleverd. Het wordt dan erg moeilijk (en duur) om de toepassing opnieuw te ontwerpen.
- het model houdt geen rekening met de mogelijkheid dat de behoeften tijdens de ontwikkelingscyclus veranderen.,
- een project kan vaak aanzienlijk langer duren dan wanneer het wordt ontwikkeld met een iteratieve methodologie zoals de agile development method. (“The Waterfall Development Methodology”, 2006).door deze en soortgelijke problemen zijn systeemanalisten op zoek gegaan naar alternatieve methoden voor het ontwerpen van systemen. In de volgende secties, Ik zal gaan over selecteer methoden die zijn ontwikkeld. Ik zal me concentreren op methodologieën die zijn geclassificeerd als Agile. In deze paper zal ik me concentreren op Extreme programmering, Scrum en Testgestuurde ontwikkeling.