Ud med V-modellen!

Modellerne fejler ikke noget. De er bare ikke lavet til at beskrive netop DIN pointe.

Vandfaldsmodellen (~ analyse, design, implementering, verifikation) er nu engang den enkleste (kanoniske) model for praktisk taget enhver problemløsning. Men det er IKKE det samme som, at man skal bruge den som en rigid faseopdelt udviklingsprocess - uanset at det var religionen for visse processfolk for år tilbage...

Din udlægning af V-modellen overser helt, at den primært er lavet som en model til beskrivelse af et system af systemer af systemer... Den siger ikke nødvendigvis noget om, hvornår aktiviteter skal foregå eller i hvor mange iterationer. Krav og design (nedbrydning) foregår således på alle niveauer i venstre side af V-et og er modsvaret af integration og verifikation i højre side af V-et. Hvis du vender siden til på V'et vil du se et systemtræ i dybden. Det er altså ikke en "one-tier" model som din foreslåede erstatning. Nej, V-modellen er heller ikke bare en vandfaldsmodel tegnet som et V.

Selvom du har ret i din pointe, at verifikation bør ske tidligt, ofte og på alle niveauer, så er modellerne ikke forkerte i sig selv. Man kunne med samme argumenter sige, at så skal krav, design og implementering også tegnes "ud over det hele" :-)

Når jeg så tidligere sagde at vandfald (V-modellen er bare en anden måde at optegne vndfaldsmodellen på - man kan godt tro anderledes, men det er bedrag), godt kan give mening. Så er der projekter der kan laves i totalt vakum, hvor man kan lave en specifikation, og så implementere løsningen.

Uha, der er vist et par ikke helt ualmindelig misforståelser her. V-modellen er absolut ikke bare en anden mde at tegne vandfaldmodellen på! Det er netop derfor, vi må finde en anden måde at tegne test som en underliggende aktivitet under alle de andre aktiviteter - og her mener jeg både statisk test (altså review) og dynamisk test. Der kan desuden sagtens være tilbageløb i V-modellen; dummere er projektledere og udviklere altså heller ikke.

Og - NEJ - testere skal ikke diktere udviklingsforløbet. Vi skal passe testen ind i det udviklingsforløb der er besluttet for det projekt, vi deltager i, således at der bliver testet i forhold til formålet for alle de faser, der måtte være relevante i et projekt. Tegningerne er jo kun principskitser. Der kan være fra nogle få faser til mange faser i et givet projekt; det er bestemt af produktets natur og andre faktorer, men ikke af test.

Er der ikke andre, der har en holdning til V-modellen?

AM

Vi udbyder tit opgaver, og forlanger at leverandøren skal følge V-modellen. For mens det er korrekt at V-modellen først tester til sidst i hver fase, så opfordrer den i høj grad til, at tests specificeres på et meget tidligt tidspunkt. Fra det sekund leverandøren har skrevet kontrakt og leveret den første tekniske beskrivelse af det system de vil levere, så punker vi dem til at levere test specifikationerne så hurtigt som muligt.

Til stor irritation for leverandøren, der ofte har en "stol på os" attitude. Men så er de klar over, at vi tager tests meget alvorligt.

Jeg kan godt forstå at V-modellen er ugleset til interne projekter, hvor man i sagens natur kan have meget større fleksibilitet og måske mindre stramme krav til specifikations-processen. Men jeg mener nu heller ikke, at det er der, den oftest bliver brugt.

At testerne nu tager æren for hvorledes en udviklingsmodel skal se ud. Sågar står der de sidste 20 år i artiklen. Jeg har endnu til gode at møde en tester som er procesorienteret nok til at foreslå særlig meget omkring ændring af arbejdets form. Det er nok samtidigt derfor at procesforbedringer og initiativer om procesforndringer kommer fra udviklere og ikke testere. Den eneste tester jeg har hørt prædike proces, var en test manager fra et body-shopping konsulenthus, som skulle være nok så respekteret, og han forvandlede et udviklingsprojekt til et test projekt efter en meget sindsyg V-model (mange flere faser end dem du har skitseret).

Det er ikke for at nedgøre test, men alle de kvalitetstiltag jeg har set er kommet fra udviklere og ikke testere.

Din SCRUM model er iøvrigt ikke korrekt. Der er ikke noget K i et sprint. Det sker inden et sprint sættes igang. Derudover er der ikke disse blokke af D, F, I. Alle de faser der er (D, F, I og de forskellige xT, sker for hver user story - det er ligesom hele ideen i one piece flow). Med Kanban blier det hele endnu bedre.

Din pointe om at man ikke kan teste kvalitet ind i software (eller hvad det nu skulle være) er ret god, og jeg tror det var i forbeindelse med TPS jeg hørte den først. Det kan man nemlig ikke, og det er rart at høre en tester der gør sig tanker om dette, men det ærgrer mig at du skriver "udvikling skal se således ud", for det kan man ikke generalisere. Der er mange forskellige måder at tilrettelægge udvikling på, som afhænger af kunde, organisation og projekt/produkt, og alt muligt andet. Til nogen projekter er det ikke udelukket at vandfaldsmodellen er bedre end så meget andet (jeg tvivler dog selv). Jeg vil selv anbefale alle at starte med Kanban og inddrage eXtreme Programming, det ser jeg som meget mere bang for the buck end SCRUM. Kanban kan samtidigt benyttes effektivt som indlejring i andre procesformer, til AM opgaver mm.

Og så lige en sidste ting. Kvalitet kommer ikke kun af at have den rigtige proces (den er en forudsætning). Der skal stadigvæk være goe håndværkere på projektet.

Hvor er det sjovt at alle artikler om udviklingsmetodik begynder med "I begyndelsen var vandfaldsmodellen" og så en god lang kunstpause hvor den bedrevidende læser kan sidde og tænk "høhø, hvor var de dumme dengang".

Selv artiklen der siges at have formaliseret vandfaldsmodelen[0] begynder stort set på denne måde på den måde. "Dette er vandfaldmodellen, den er godt nok risikabel og indbyder til fiasko. Resten af artiklen går med at rette op på de mest gabende problemer."

Jeg har simpelthen mistet interessen mens I godter jer over hvor meget klogere I er en dem der fandt på vandfaldsmodellen er.

0. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Hej,

Først mange tak for kommentarer! Dernæst nogle forklaringer, som måske kan opklare lidt.

*- Analyse

• Design
• Implementation
• Test*

Kære børn har mange navne. Og der findes mange varianter af V-modellen og de forskellige faser. Jeg regner med, at 'Analyse' er det samme som det, jeg kalder kravarbejde, dvs. det at finde ud af, hvad forventningerne til systemet er. Design er det at finde ud af, hvordan systemet skal struktureres. Jeg har undgået 'Implementering', fordi det ord også bruges om at sætte systemet i drift, men her svarer det til 'Fremstilling', som er mere neutralt end 'Kodning' (det kan jo sagtens være, at der er noget af systemet, der ikke kan klares med kode, f.eks. brugermanual). De testniveauer, jeg har antydet, er Komponenttest (også kaldet f.eks. modultest eller unittest), Integrationstest og Systemtest. Der kan også være flere, afhængig af, hvordan udviklingsforløbet er delt op.

Og Erik, du har helt ret i, at V-modellen står for, at man starter testarbejdet sammen med udviklingsarbejdet; det bliver desværre ofte ikke helt forstået eller efterlevet. AM

Hej Anne Mette. Dejligt at se, at du kæmper for TEST. Jeg er ikke helt sikker på, at V-modellen har været så tosset. Med de rette forklaringer er jeg ret sikker på, at mange har fået et godt billede af test i udviklingsforløb. F.eks. at man kan planlægge accepttest allerede når kravene skrives. Men fint at du prøver at 'modernisere' beskrivelse af test. Om ikke andet, kan det formentlig få nogle til at tænke lidt mere over test.

Desværre kom V-modellen til at se ca. sådan her ud (jeg håber I kan regne ud, hvad de forskellige testniveauer er)

Du kunne jo risikere, at din blog bliver læst af folk, for hvem det er en helt ny tankegang, at man i det hele taget kan vente med at teste til allersidst. Eller som slet ikke kender til 'allersidst'.

I min skole er vandfaldsmodellen:

• Analyse
• Design
• Implementation
• Test , så jeg kunne godt bruge en forklaring. Bare lige for at være helt sikker :)