8.0 Vandfald vs. cyklisk projektledelse (del 1)

EN vandfaldsmodel , den seksfasede model er en vandfaldsmodel. Med andre ord forekommer stadierne i rækkefølge. Ligesom svømning opstrøms mod et vandfald er umulig, forhindrer den rene vandfaldsteknik at vende tilbage til en fase, efter at den er afsluttet.

Det er ikke ideelt at beslutte at ændre designet under implementeringsfasen og dermed standse implementeringen. Vandfaldstilgangen er ofte mindre egnet til softwareudviklingsprojekter af forskellige årsager.

  • Softwareudvikling er et kunstnerisk bestræbelse; det er stort set svært at forudse alle behov (funktionaliteter).
  • Det er meget udfordrende at estimere den tid, det tager at udvikle en funktion.
  • I hele projektets livscyklus skal brugerne kunne teste alle mellemliggende resultater.

Softwareudvikling er en kunstnerisk indsats #

For de uindviede synes softwareudvikling mere at handle om teknik end om opfindelse. Det vedrører imidlertid på en række måder at opfinde. I skabelsesprocessen ved man aldrig præcis, hvad der vil ske.

De designere og programmører, der er ansvarlige for at udvikle ny software, skal komme med svar på de spørgsmål, de bliver præsenteret for. Uanset de mange teknikker og forskrifter til arbejde er oprettelse af computerkode stadig for det meste ukendt og derfor uforudsigelig. Programmerere kan vælge mellem millioner af løsninger skrevet på snesevis af programmeringssprog og operere på tusindvis af forskellige hardware -kombinationer og softwareplatforme. Selvom denne fleksibilitet har mange fordele, gør det også projektet mere udfordrende at styre end mere konventionelt projektledelse (såsom bygge- eller byggeprojekter).

Opsætning af implementering #

Vandfaldstilgangen kræver, at krav defineres som en konsekvens af projektets definerende fase . Ideelt set bør der forekomme en minimal yderligere afvigelse fra disse kriterier for resten af projektet. Vandfaldstilgangen til softwareudvikling kræver en indledende forpligtelse til en betydelig indsats for at analysere den nødvendige funktionalitet (krav). Dette resulterer i et funktionelt design (se I for yderligere oplysninger om funktionelle designs). Softwarearkitekten skaber et teknisk design under hele designprocessen ved hjælp af det funktionelle design som reference. Desuden giver det tekniske design instruktioner om, hvordan den nødvendige funktionalitet skal udføres.

Selvom dette kan synes at være et simpelt problem, skal du overveje følgende scenario. Et nyt køretøj udvikles som en del af et projekt. Som aktiv bilfører har du til opgave at udvikle bilbehov. Du taler med andre bilister og udarbejder en udtømmende liste:

  • Bilen skal rumme fire personer;
  • Bilen skal have et rat foran på førerens venstre side; • Bilen skal have en bremsepedal, en gaspedal og en håndbremse.
  • Bilens forlygter skal være hvide, og baglygterne skal være røde. (naturligvis ville den rigtige liste være enorm)

Design og modellering #

Designerne opretter et nyt design ved hjælp af din liste som vejledning, som derefter konstrueres mange måneder senere. Når du går ned ad gaden, ser du, at et køretøj er standset. Du indser, at du har udeladt bremselys fra din liste! Du kontakter hurtigt bilproducentens ingeniør, der næsten brister som reaktion på dit opkald. Du påstår, at det er en mindre justering. Det er dog en katastrofe for bilproducenter. Biler, der allerede er fremstillet, skal demonteres fuldstændigt, ledninger fra bremsepedalerne til bagsiden skal forlænges, køretøjets bageste skal være fuldstændigt redesignet for at passe til bremselysene, og allerede fremstillede bagagerumsluger skal skrottes, og listen fortsætter.

Selvom ovenstående scenario virker latterligt, repræsenterer det en næsten daglig forekomst i softwareudvikling. Programmerere gør den fejlagtige antagelse om, at klienter, kunder eller brugere af produktet, der oprettes, forstår præcis, hvad de vil. Kunder tror forkert, at softwareudviklere kan oprette (og ændre) alt på den mindst mulige tid. Dette er den primære årsag til strid mellem forbrugere og softwareudviklere.