den traditionella Vattenfallsmetoden
Vattenfallsmetoden för systemanalys och design wass den första etablerade moderna metoden för att bygga ett system. Denna metod definierades ursprungligen av Winston W. Royce 1970, (”The Waterfall Development Methodology”, 2006). Det fick snabbt stöd från chefer eftersom allt flyter logiskt från början av ett projekt genom slutet, (Jonasson, 2008)., Källor skiljer sig när det gäller de specifika stegen i Vattenfallsprocessen (Jonasson, 2008), och jag kommer att detaljera några av dessa skillnader i nästa stycke. Men den grundläggande underliggande logiken och stegen presenterar sig i varje tolkning.
Figur 1: Vattenfallsmetod
(”the Waterfall Development Methodology”, 2006)
den ursprungliga Vattenfallsmetoden, som utvecklats av Royce, finns i Figur 1. Stegen omfattar krav bestämning, Design, genomförande, verifiering och underhåll., Andra modeller ändrar Kravfasen till idéfasen (Jonasson, 2008), eller bryter kraven fas ut i planering och analys (Hoffer, George, Valacich, 2008). Dessutom bryter vissa modeller ytterligare designfasen ut i logiska och fysiska Designunderfaser (Hoffer, et al, 2008). Som tidigare nämnts är dock de grundläggande underliggande principerna desamma.
Vattenfallsmetoden förutsätter att alla krav kan samlas upp på framsidan under Kravfasen (Kee, 2006)., Kommunikation med användaren är front-laddad i denna fas, som projektledaren gör sitt bästa för att få en detaljerad förståelse av användarens krav. När detta stadium är klart, går processen ”downhill” (Hoffer, et al, 2008).
designfasen beskrivs bäst genom att bryta upp den i logisk Design och fysiska Designunderfaser. Under den logiska konstruktionsfasen använder sig systemets analytiker av den information som samlats in i Kravfasen för att utforma systemet oberoende av vilken hårdvara eller mjukvara som helst (Hoffer, et al, 2008)., När den logiska designen på högre nivå är klar börjar systemanalytikern sedan omvandla den till en fysisk Design som är beroende av specifikationerna för specifik hårdvaru-och mjukvaruteknik (”Programvaruutvecklingens livscykel”, n.d.)
implementeringsfasen är när hela den faktiska koden skrivs (”SDLC-faser”, n.d.). Denna fas hör till programmerarna i Vattenfallsmetoden, eftersom de tar projektkraven och specifikationerna och kodar applikationerna.,
Verifieringsfasen krävdes ursprungligen av Royce för att säkerställa att projektet uppfyller kundernas förväntningar. Men under verklig analys och design ignoreras detta stadium ofta. Projektet rullas ut till kunden, och underhållsfasen börjar.
under underhållsfasen använder kunden det utvecklade programmet. Eftersom problem uppstår på grund av felaktig kravbestämning eller andra misstag i designprocessen, eller på grund av ändringar i användarnas krav, görs ändringar i systemet under denna fas. (’SDLC-faser’, ej i detaljhandelsförpackningar).,
Vattenfallsmetoden har vissa fördelar, inklusive:
- designfel fångas innan någon programvara skrivs sparar tid under genomförandefasen.
- utmärkt teknisk dokumentation är en del av leveranserna och det är lättare för nya programmerare att komma igång under underhållsfasen.
- tillvägagångssättet är mycket strukturerat och det är lättare att mäta framsteg med hänvisning till tydligt definierade milstolpar.,
- den totala kostnaden för projektet kan uppskattas noggrant efter att kraven har definierats (via funktions-och Användargränssnittets SPECIFIKATIONER).
- testning är enklare eftersom det kan göras med hänvisning till de scenarier som definieras i den funktionella specifikationen (”The Waterfall Development Methodology”, 2006).,
tyvärr bär Vattenfallsmetoden med sig en hel del nackdelar, till exempel:
- klienter kommer ofta att ha svårt att ange sina krav på abstrakt nivå av en funktionell specifikation och kommer bara att uppskatta vad som behövs när ansökan levereras. Det blir då mycket svårt (och dyrt) att omkonstruera ansökan.
- modellen tillgodoser inte möjligheten att kraven ändras under utvecklingscykeln.,
- ett projekt kan ofta ta betydligt längre tid att leverera än när det utvecklas med en iterativ metod såsom agile development method. (”Vattenfall Utveckling Av Metodik”, 2006).
på grund av dessa och liknande problem började systemanalytiker leta efter alternativa metoder för att designa system. I följande avsnitt kommer jag att gå över utvalda metoder som har utvecklats. Jag kommer att koncentrera mig på metoder som har klassificerats som smidiga. I detta dokument kommer jag att koncentrera mig på extrem programmering, Scrum och testdriven utveckling.