8.0 Vattenfall kontra cyklisk projektledning (del 1)

A vattenfallsmodell , sexfasmodellen är en vattenfallsmodell. Med andra ord sker stadierna sekventiellt. Precis som att simma uppströms mot ett vattenfall är omöjligt, hindrar den rena vattenfallstekniken att återgå till en fas efter att den är klar.

Det är inte idealiskt att besluta om att ändra designen under implementeringsfasen och därmed stoppa implementeringen. Vattenfallet är ofta mindre lämpligt för mjukvaruutvecklingsprojekt av olika anledningar.

  • Programvaruutveckling är en konstnärlig strävan; det är praktiskt taget svårt att förutse alla behov (funktioner).
  • Att uppskatta den tid som krävs för att utveckla en funktion är mycket utmanande.
  • Under projektets livscykel ska användarna kunna testa alla mellanresultat.

Programvaruutveckling är en konstnärlig strävan #

För den oinvigde verkar mjukvaruutveckling mer handla om teknik än om uppfinning. Det hänför sig dock på ett antal sätt att uppfinna. I skapandeprocessen vet man aldrig exakt vad som kommer att hända.

De designers och programmerare som ansvarar för att utveckla ny programvara måste komma med svar på de frågor de presenteras för. Oavsett de många teknikerna och föreskrifterna för arbete är det fortfarande mest okänt att skapa datorkod och därför oförutsägbart. Programmerare kan välja bland miljontals lösningar skrivna på dussintals programmeringsspråk och som fungerar på tusentals olika hårdvarukombinationer och mjukvaruplattformar. Även om denna flexibilitet har många fördelar, gör det också projektet mer utmanande att hantera än mer konventionellt projektledning (t.ex. bygg- eller byggprojekt).

Implementation Set Up #

Vattenfallet kräver att kraven definieras som en konsekvens av projektets definierande fas . Helst bör en minimal avvikelse från dessa kriterier ske för resten av projektet. Vattenfallsmetoden för mjukvaruutveckling kräver ett initialt åtagande av betydande insatser för att analysera den nödvändiga funktionaliteten (kraven). Detta resulterar i en funktionell design (se I för ytterligare information om funktionella mönster). Programvaruarkitekten skapar en teknisk design under hela designprocessen, med funktionell design som referens. Vidare ger den tekniska designen instruktioner om hur man utför den nödvändiga funktionaliteten.

Även om detta kan tyckas vara en enkel fråga, överväg följande scenario. Ett nytt fordon utvecklas som en del av ett projekt. Som aktiv bilförare har du i uppgift att utveckla fordonsbehov. Du konfererar med andra bilister och sammanställer en uttömmande lista:

  • Bilen måste rymma fyra personer;
  • Bilen måste ha en ratt framtill på förarens vänstra sida; • Bilen måste ha en bromspedal, en gaspedal och en handbroms.
  • Bilens strålkastare måste vara vita och baklyktorna måste vara röda. (uppenbarligen skulle den verkliga listan vara enorm)

Design och modellering #

Formgivarna skapar en ny design med din lista som en guide, som sedan konstrueras många månader senare. När du går ner på gatan ser du att ett fordon har stannat. Du inser att du utelämnade bromsljus från din lista! Du kontaktar snabbt biltillverkarens ingenjör, som nästan spricker som svar på ditt samtal. Du hävdar att det är en mindre justering. Det är dock en katastrof för biltillverkare. Bilar som redan tillverkats måste demonteras helt, ledningar från bromspedalerna till baksidan måste förlängas, fordonets baksida måste omformas helt för att passa bromsljusen och redan tillverkade bagageluckor måste skrotas och listan fortsätter.

Även om ovanstående scenario verkar löjligt, representerar det en nästan daglig förekomst i mjukvaruutveckling. Programmerare gör det felaktiga antagandet att kunder, kunder eller användare av produkten som skapas förstår exakt vad de vill ha. Kunder tror felaktigt att mjukvaruutvecklare kan skapa (och ändra) vad som helst på minsta möjliga tid. Detta är den främsta orsaken till tvister mellan konsumenter och mjukvaruutvecklare.