Ud med V-modellen!

I begyndelsen var vandfaldsmodellen.

Her er test beskrevet som noget, der sker til sidst efter krav, design, fremstilling og integration - dvs. lige inden levering. Det ser i princippet sådan her ud:

Illustration: Privatfoto

I begyndelsen af 1990'erne kom V-modellen; og det var en øjenåbner for mange. Test var noget, man kunne foretage på flere niveauer, og måske endda undervejs i udviklingsprocessen?! 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):

Det så (og ser) stadig ud, som om testen kommer til sidst, og oveni købet, som om testen forlænger forløbet. Så de fleste troede, og tror stadig, at test er noget, man gør til sidst. Desværre støttet af ISO 12207 (en gammel, men stadig levende standard for softwareudvikling), som selv i sin nyeste version fra sidste år(!) placerer én testaktivitet til sidst efter alle de andre aktiviteter - trods protester fra testere.

Men nu må det da snart trænge igennem, at kvalitet ikke er noget, man kan teste ind i produkterne, lige før de skal afleveres! Kvalitet skal arbejdes ind hele vejen fra projektet bliver sat igang! Vi testere har 'kun' prædiket det i over 20 år.

Og det må også snart trænge igennem, at kvalitetssikring ikke bare er dynamisk test, der udføres på softwaren, efterhånden som den bliver skrevet! Det omfatter også statisk test (f.eks. review), der kan foretages, så snart de første skitser af modeller af systemet, i form af f.eks. use cases og andre typer krav, er blevet produceret. Det er 'kun' blevet prædiket i endnu længere tid.

Udvikling skal se sådan ud:

Test- og udvikingsarbejde foregår samtidig! Test består af statisk test af modellerne af systemet, f.eks. krav og design, og af dynamsik test. Og dynamisk test består af design af test, afvikling af test og rapportering af test! Så der foregår en hel masse i hver af de røde kasser. Det vender jeg tilbage til; hvis der er interesse for det.

For en sikkerheds skyld: tegningen ovenfor viser én iteration i et agilt projekt (et sprint, hvis man bruger SCRUM) - fra ready-ready til done-done. Den kunne sådan set også vise et langt udviklingsprojekt fra start til slut. Principperne er ens.

Så ud med V-modellen, der efterhånden har gjort mere skade end gavn.

Jeg har ikke lige nogen ide til, hvad den viste model skal hedde. Måske kunne vi udskrive en navngivningskonkurrence?!

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Stricker

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)

Jeg kan da godt komme med nogle gæt, men jeg vil nu alligevel opfordre dig til at sætte navne på niveauerne.

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'.

  • 2
  • 0
Erik Silkjær

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.

  • 1
  • 0
Anne Mette Hass

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

  • 2
  • 0
Peter Makholm Blogger

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

  • 4
  • 2
Anne Mette Hass

Hej,

Det var nu ikke min mening at hænge opfinderne af vandfaldsmodellen ud. Jeg ville bare give et historisk rids. Alting skal jo starte et sted, og derfra bliver vi forhåbentlig klogere og klogere på området. Det er der ikke noget galt i, tværtimod.
Med vandfaldsmodellen kom test på banen, og det var godt!
Men det er da lidt trist at miste interessen, bare fordi udviklingen går videre. Det er da noget, man skulle glæde sig over, synes jeg.
AM

  • 2
  • 0
Nikolaj Brinch Jørgensen

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.

  • 1
  • 1
Mogens Hansen

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.

  • 1
  • 0
Nikolaj Brinch Jørgensen

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.


Ja men det er så fint at følge vandfaldsmodellen, det er jo også de facto standarden for udbud. Det store problem er bare at den virkelige verden ikke lader sig putte ned i den lille dåse der blev skabt på udbudskontoret i sin tid.
Et andet problem er så, at modellen ikke tillader de projektinvolverede at blive klogere gennem forløbet, og eventuelt spare kunden for en hulens bunke penge, som følge af at man nu blev klogere.

Det er klart at tidlig test er en fordel og det skal man da sørge for, men det behøver man ikke en omskrivning af vandfaldsmodellen til. Man skal jo også huske hvad vi læret før, nemlig at kvalitet skal bygges ind, ikke testes ind. Derfor skal der ikke skrues op for test, tværtimod. Der skal verifikation til, men ikke mere end hvad der lige er nødvendigt.

De test specifikationer jeg har set defineret på større projekter, er jo efter 2-3 års udvikling helt ved siden af hvor verden har bevæget sig hen.
Jeg huske milepæls testkravene fra et projekt. Top 200 URL's i access loggen på webserveren på produktionssystemet var ikke en del af testen. Jeg mener det udstiller jo i den grad, både hvor ringe V-model og vandfaldsmodel er, jo længere tid et projekt strækker sig over. Men også hvor farligt det er, at tro man er super godt testmæssigt dækket ind, fordi man har specificeret sig ud af det. Der skal verificeres, og testene skal også verificeres. Det hjælper ikke noget at købe dyrt ind i form af værktøj som MS Word, MS Project, MS Excel, QC, Remedy, QTP. Testere er dem som køber langt dyrest ind, og har klart de største omkostninger til værktøj - de er samtidigt dem som er mindst villige til at prøve nogle nye værktøjer af som faktisk ikke koster noget, eller ganske lidt, og som gør arbejdet langt bedre og nemmere. Det er igen udviklerne der tager tyren ved hornene for at forsøge at øge kvaliteten. Ingen testere har foreslået SoapUI, Cucumber, RSpec, LoadUI, JMeter, Selenium, Fit osv. osv. osv. Det er altid udviklere.

  • 1
  • 4
Mogens Hansen

Jeg synes got nok du blander mange ting sammen. Det virker mere som et hævntogt mod test og testere end en egentlig stillingtagen til de forskellige modeller, som du alle skærer over en kam. At kravspec'en ikke indeholder et givent krav (dine 200 top URLer) er jo ikke modellens skyld.

Ikke alle projekter er færdige efter 2-3 år. Nogle af os arbejder med tidshorisonter på 6-8 år i implementering, adskillige interessenter og 30, sandsynligvis flere, års drift derefter.

  • 4
  • 0
Nikolaj Brinch Jørgensen

Jeg synes got nok du blander mange ting sammen. Det virker mere som et hævntogt mod test og testere end en egentlig stillingtagen til de forskellige modeller, som du alle skærer over en kam. At kravspec'en ikke indeholder et givent krav (dine 200 top URLer) er jo ikke modellens skyld.


Ja det har du ret i - jeg blander for meget sammen. Det var ikke et tiltænkt hævntogt mod testere. Blot at "proces over people" er og bliver skidt. Det gælder projektledere, testere og alle de medarbejdere der er højt på admin siden (dem som er gode til systematik go organisation), at sørge for at skrue ned for det til tider, så der kommer flow i tingene, og lytte til dem som rent faktisk udfører arbejdet (TPS). Det fik jeg så sagt på en forfærdeligt dum måde.

Den med URL'erne er jo netop modellens skyld, fordi testen er specificeret i forhold til en virkelighed der aldrig vil eksistere samtidigt med løsningen. Modellen tager ikke højde for ændringer.

Ikke alle projekter er færdige efter 2-3 år. Nogle af os arbejder med tidshorisonter på 6-8 år i implementering, adskillige interessenter og 30, sandsynligvis flere, års drift derefter.


Ja nogle af os arbejder sågar på produkter som har andre livscyklus.
Men de fleste arbejder med at et projekt i udbud, helst skal afleveres i produktion indenfor relativ kort tid, da udbuddet er baseret på en mangel/et hul, der skal fyldes ud, og hullet bliver dybere jo længere der mangler en løsning (tag f.eks. inddrivelse af offentlig gæld - det bliver en større og større pose penge, som forrentes negativt, jo længere der går).

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.
Problemet opstår tit der hvor specifikationen er nødt til at være så nøjagtig for at det kan lade sig gøre, at løsningen først kodes i Word, Excel, VISIO osv. med alle de normale tilbageløb (blot i Microsoft kontorsoftware og ikke i programkode), at det rent faktisk ikke tilføre kvalitet eller omkostningsbesparelser, men derimod omkostningsforøgelser, specifikationer der alligevel ikke specificere det som implementeres.
Vi ikke kan tage højde for teknologien i specifikationerne. Husk på, at langt de fleste tilbud der afgives på et udbud, afgives uden at der er afprøvet noget som helst. Tilbuddene er baseret på antagelser, antagelser lavet at folk hvis størte IT kundskaber ofte er PowerPoint og samtale med en leverandør som Oracle, IBM eller lignende.

Vandfaldsmodel (herunder V-model) kræver meget rigide specifikationer, for ikke at afføde tilbageløb (som jo er spild i LEAN termer, og det ondeste i en proces, noget om for enhver pris må undgås).

Det er i mine øjne en illusion at tro at man kan specificere et projekt på 6-8 års tid up front, i en sådan detaljegrad at der ikke skal rettes i det. Det system man får 6-8 år efter er muligvis det man specificerede, men er det et der kan bruges?
Hvis vi specificerede et mobil OS nu, og så om 6-8 år ville lancere det på markedet, hvor mange mobiler ville vi så sælge? Nok ikke så mange for alle de landvindinger der vil ske på alle fronter, kan vi jo ikke tage med i vores specifikation, de er jo sket efter specifikationen blev skrevet. Det er det sande onde ved vandfald.

PS: Jeg er selv startet som tester i sin tid. Det er væsenligt at test inddrages på lige fod med udvikling helt up front, og bliver taget med til alle møder der foregår om afklaring osv. Det er dem som skal verificere at vi lever op til kundes krav.

  • 3
  • 0
Mogens Hansen

Vandfaldsmodel (herunder V-model) kræver meget rigide specifikationer, for ikke at afføde tilbageløb (som jo er spild i LEAN termer, og det ondeste i en proces, noget om for enhver pris må undgås).

Hvis du ser v-modellen som underkategori til vandfaldsmodellen og mener at den ikke tillader feed/loopback, ... så har du vist slet ikke forstået V-modellen.

Og så lige for at understrege overskriften på denne tråd: Jeg kan godt lide V-modellen til de projekter og forudsætninger jeg sider med. Jeg påstår på ingen måde at den passer i alle sammenhænge.

  • 0
  • 0
Nikolaj Brinch Jørgensen
  • 0
  • 0
Anne Mette Hass

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

  • 0
  • 0
Tommy Vestermark

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" :-)

  • 1
  • 0
Nikolaj Brinch Jørgensen

Har jeg ret i, at din viden om V-modellen primært stammer fra Wikipedia og ikke praksis?


Nej det har du ikke ret i, det vil du også finde svaret på, hvis du havde læst havde jeg skrev.
Et softwareudviklingsprojekt, er ikke et testprojekt. Det skal det ikke være. Hovedaktiviteten skal være udvikling af software, ellers er projektet et andet projekt. Test er en del af softwareudvikling, som vi ikke kan være foruden. I den ideelle verden findes test ikke i et softwareudviklingsprojekt. Vi lever bare ikke i den ideelle verden, men vi skal søge at forbedre vores proces henimod det ideelle. Derfor skal alle aktiviteter i frembringelse af software mm. der ikke direkte frembringer software begrænses til det absolutte minimum, da de forsinker processen.
En model der hårdt dikterer hvornår noget skal ske, er i mine øjne forkert, da det ikke er givet, at de aktiviteter modellen omhandler bidrager positivt.
Desuden reducere det projektledere til manual-mennesker, som kan erstattes af robotter, og fjerne totalt ansvar fra menneskerne. De følger jo blot et skema der fortæller dem at nu skal de gøre sådan og sådan.
Jeg er meget mere pro en dynamisk proces, der kostant tilpasse kravene, de involverede mennesker, og målet.

  • 0
  • 0
Nikolaj Brinch Jørgensen

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.


Det kan godt være intentionerne var gode, men den bliver, som Anne Mette sagde tidligere, benyttet på måder som så er langt fra intentionerne.

V-modellen ER er en modifikation af vandfaldsmodellen (det er alle modeller vel i virkeligheden - de iterative, er bare mange, på hinanden følgende vandfald). Den ER faseopdelt, og den forudsætter at kravene ikke ændrer sig.
Hvis de gør så har vi change board balladen (som i vandfaldsmodellen), som er meget dyr, og uproduktiv.
Det er desuden en test model, som tilfører projektet meget mere test. Det er dino agtigt, for det er som Anne Mette rigtigt beskriver ikke muligt at test kvalitet ind i noget som helst, derfor er modellen i sit udgangspunkt FAIL.
En model der beskriver at der skal mere test til for at højne kvaliteten, har afsæt i en forkert tankegang.

Når det så er sagt, så giver det sikkert en bedre kvalitet end vandfald, spiral osv. osv. men det er stadigt ikke godt nok for mig.

Mængden af test siger ikke noget om kvalitet. Mængden af kode siger heller ikke specielt meget om et stykke software (måske bortset fra at kvaliteten af software oftest er omvendt proportional med mængden af kode).

  • 0
  • 0
Anne Mette Hass

Lige en lille bemærkning med på vejen.

Mængden af test bestemmer, hvormeget man kan sige om produktets kvalitet. Det er det, der er formålet med testen: at skaffe information om, hvilken kvalitet produktet havde på det tidspunkt, hvor testen blev gennemført.

Herfra kan 'man' så vælge at leve med den opnåede kvalitet eller forbedre den.

Dette er IKKE for at starte en diskussion om, hvad kvalitet er - sådanne diskussioner er der allerede (for?) mange af.

AM

  • 0
  • 0
Nikolaj Brinch Jørgensen
  • 0
  • 0
Tommy Vestermark

V-modellen ER er en modifikation af vandfaldsmodellen (det er alle modeller vel i virkeligheden - de iterative, er bare mange, på hinanden følgende vandfald). Den ER faseopdelt, og den forudsætter at kravene ikke ændrer sig.
Hvis de gør så har vi change board balladen (som i vandfaldsmodellen), som er meget dyr, og uproduktiv.

Nikolaj, du svarer på mit indlæg, men det er som om, du ikke har læst hvad jeg skrev: V-modellen er en systemudviklingsmodel.

Større systemer er ofte karakteriseret ved at involvere mange udviklere i flere hierarkier i et kunde-/leverandørforhold. Systemerne indeholder typisk også mange andre elementer end software. Det er noget vrøvl, at man forudsætter, at kravene ikke ændrer sig (det er der ikke noget revolutionerende nyt i) - men større systemer er ofte karakteriseret ved, at kravsændringer kan være meget dyre - og det kræver en helt anden disciplin omkring krav.

Du skriver, at meget test er "dino agtigt". Jeg er sikker på, at både de certificerende myndigheder og slutbrugerne til en sikkerhedskritisk flight-control software har en helt anden holdning til værdien af krav, grundig analyse af problemstillingen, struktureret implementering og ikke mindst grundig test!

Hvis du kunne se klart for din agile religion, så ville du måske se, at alle problemer ikke er skruer til dit fine værktøj - og at alle andre metoder ikke bare er "FAIL".

  • 0
  • 0
Nikolaj Brinch Jørgensen

Større systemer er ofte karakteriseret ved at involvere mange udviklere i flere hierarkier i et kunde-/leverandørforhold.

Hvilke store systemer taler vi om? Hvor mange udviklere, hvor mange leverandører. Jeg har været involveret i udvikling med 1000+ udviklere, men det var i USA. I DK har jeg siddet som arkitekt og teknisk projektleder på integrationsdelen af et projekt med 140 konsulenter (8 leverandører) - budget lidt over 1 mia.

Det er noget vrøvl, at man forudsætter, at kravene ikke ændrer sig (det er der ikke noget revolutionerende nyt i) - men større systemer er ofte karakteriseret ved, at kravsændringer kan være meget dyre - og det kræver en helt anden disciplin omkring krav.


At forudsætte at kravsændringer er dyre, er netop en fejl. Verden og krav ændrer sig hele tiden, specielt på store projekter der løber over lang tid. Netop derfor må det ikke have høje omkostninger at skulle ændre i kravene.

Du skriver, at meget test er "dino agtigt". Jeg er sikker på, at både de certificerende myndigheder og slutbrugerne til en sikkerhedskritisk flight-control software har en helt anden holdning til værdien af krav, grundig analyse af problemstillingen, struktureret implementering og ikke mindst grundig test!


Ja det må du godt citere mig for. At teste mere, giver ikke en bedre kvalitet. Kvalitet er noget man bygger ind fra bunden. Se evt. på TPS, andre brancher forstod det her i starten af 80'erne. Der levede vi vel stadigt efter Ed Yourdons principper.

Der er ikke nogen der stiller spørgsmåltegn ved grundig analyse, struktureret implementering og grundig test - i hvert fald ikke mig. Hvis du læser hvad jeg skriver, så stiller jeg spørgsmåltegn ved processen. Ikke aktiviteterne. Du er nødt til at kunne adskille aktiviteterne fra processen.
Desuden kan jeg ikke forstå hvorfor du ikke er enig i betragtningen af test i en ideel verden ikke burde forekomme, så hvis vi stræbe mod en ideel verden, skal vi stræbe mod så lidt test som muligt?
Det samme gælder iøvrigt dokumentation, og andre artefakter som i bund og grund er spild. F.eks. projektledere.

Og hvis du så var lidt seriøs, så kunne du lidt længere oppe i tråden læse at jeg netop siger at jeg er overbevist om at der findes projekter hvor folk som dig kan benytte jeres vandfaldsmodel med god ret. En flight controller er sikkert sådan en.
Et spørgsmål er så om det er et specielt godt eksempel. Jeg formoder at en flight controller vil være noget i retning af version 300, da der er en del af dem i forvejen, og det derfor er ret kendt stof for dem som har med den slags at gøre - eller er det helt forkert?
Tag derimod store projekter som dem SKAT har kørende, som kører over mange år med rigtigt mange leverandører. De fleste projekter her er true green field.
Bootm linbe er, at hvis kravene ikke ændrer sig, så er vandfald sikkert billigt og bedst (det fordrer næsten en constraint på at projektet samtidigt er kort), mens hvis kravene ændrer sig gennem projektets forløb, skal man have en model/proces der tager højde herfor (længerevarende projekter har alle denne egenskab).

Hvis du kunne se klart for din agile religion, så ville du måske se, at alle problemer ikke er skruer til dit fine værktøj - og at alle andre metoder ikke bare er "FAIL".


Jeg tror ikke lige jeg har nævnt agil noget sted. Men når vi nu er der. Så kan jeg forstå på dig at du muligvis har en anti-agil meget religiøs overbevisning? Hvad bygger den på? Erfaringer eller som for det meste uvidenhed.
Jeg har ikke nævnt agil. Men derimod nævnt at der er en paletter at metoder, modeller og processer, og dem skal man vælge med omhu, afhængigt af den konkrete problemstilling. Der ser ud til at du ikke er enig heri, men du forsøger så kluntet at tørre den af på mig, som om jeg skulle have en eller ande agil agenda. Tyndt!

Jeg er tilhænger af at man tænker sig om, og arbejder med mennesker, og ikke gemmer sig bag bøger, modeller, certificeringer osv. Det kommer der ikke brugbare resultater ud af, og alle kan gøre det. Det er ikke ledelse - det er management (læs: MS Excel mm.). Det er som at følge en bageopskrift i en kogebog, alle kan gøre det, og det gør ingen forskel hvem du sætter til det.

Jeg kan anbefale af læse Bents indlæg http://www.version2.dk/blog/vision-billigt-til-salg-43256

  • 0
  • 0
Tommy Vestermark

Jeg har været involveret i udvikling med 1000+ udviklere, men det var i USA. I DK
har jeg siddet som arkitekt og teknisk projektleder på integrationsdelen af
et projekt med 140 konsulenter (8 leverandører) - budget lidt over 1 mia.

Flot! Men inden I satte alle 1000+ udviklere i sving, foregik der nok en nedbrydning af jeres system i nogle del-elementer - og det evt. i flere hierarkier? I lavede sikkert også en eller anden form for beskrivelse af, hvad udviklerne af disse del-elementer skulle lave? Nogle af disse udviklingsteams lavede sikkert også noget del-integration og del-test inden det hele blev integreret på toppen? Det foregik højst sandsynligt ikke strengt kronologisk, forhåbentlig i flere iterationer og måske arbejdede flere af disse teams endda efter forskellige metoder. Men alt i alt meget godt beskrevet med en V-model...

Læg forøvrigt mærke til, at betydningen af ordet "model" adskiller sig fra ordene "proces" og "metode".

At forudsætte at kravsændringer er dyre, er netop en fejl. Verden og krav
ændrer sig hele tiden, specielt på store projekter der løber over lang
tid. Netop derfor må det ikke have høje omkostninger at skulle ændre i
kravene.

Ja, det er en fejl at forudsætte enten det ene eller det andet (det var altså heller ikke det jeg skrev!!). Men nogle gange er det et vilkår, at ændringer er dyre - især hvis systemet har en vis kritikalitet eller når man ikke kun laver software.

At teste mere, giver ikke en bedre kvalitet. Kvalitet er noget man bygger ind fra bunden.

Helt enig. Test/verifikation har ikke som direkte formål at give kvalitet - men at sikre kvalitet.

... mens hvis kravene ændrer sig gennem projektets forløb,
skal man have en model/proces der tager højde herfor (længerevarende
projekter har alle denne egenskab).

Igen fuldstændig enig. Nogle gange er det bare nødvendigt med en rigid proces, fordi omkostningerne ved ændringer eller fejl som følge deraf er meget høje. Ved mindre kritiske systemer kan man være mere pragmatisk.

Så kan jeg forstå på dig at du muligvis har en anti-agil meget religiøs
overbevisning?

Helt forkert forstået. Jeg har snarere en anti-religiøs agil overbevisning ;-) Jeg forsøger netop at bruge ordet “skal” med omhu overfor andre (tænk lidt over det).

Min pointe igennem det her har været, at denne tråd har som udgangspunkt, at V-modellen er en softwareudviklingsproces. Det er den ikke!

  • 0
  • 0
Nikolaj Brinch Jørgensen

Læg forøvrigt mærke til, at betydningen af ordet "model" adskiller sig fra ordene "proces" og "metode".


Ja det er rigtigt. Når i bruger V-modellen, hvilken proces bruger i så, og hvilken metode? V-modellen beskrive en proces.

Ja, det er en fejl at forudsætte enten det ene eller det andet (det var altså heller ikke det jeg skrev!!). Men nogle gange er det et vilkår, at ændringer er dyre - især hvis systemet har en vis kritikalitet eller når man ikke kun laver software.


At ændringer er dyre og at systemet har en vis kritikalitet, er ikke to korrelerede størrelser.

Helt enig. Test/verifikation har ikke som direkte formål at give kvalitet - men at sikre kvalitet.


Og derfor skal testen ske før vi skriver kode - it is the only way. TFD/TDD.

PS: Who watches the watchmen?

Igen fuldstændig enig. Nogle gange er det bare nødvendigt med en rigid proces, fordi omkostningerne ved ændringer eller fejl som følge deraf er meget høje. Ved mindre kritiske systemer kan man være mere pragmatisk.


Nej der er vi ikke enige. Omkostningerne ved fejl og ændringer er meget høje fordi man bruger en meget rigid proces - og ikke omvendt som du forsøger at beskrive. Man er ikke nødt til at benytte en rigid proces, fordi det man laver er kritisk eller ikke.

Helt forkert forstået. Jeg har snarere en anti-religiøs agil overbevisning ;-) Jeg forsøger netop at bruge ordet “skal” med omhu overfor andre (tænk lidt over det).


Helt fint. Du begyndte bare at pådutte mig en bestemt religion, og det brød jeg mig ikke om, specielt fordi den var forkert. Hvordan du benytter ordet skal, må du helt selv bestemme.

Min pointe igennem det her har været, at denne tråd har som udgangspunkt, at V-modellen er en softwareudviklingsproces. Det er den ikke!


Og hvad tror du så den er? Det er det jo, det er en modifikation af Waterfall, så test er med fra starten og hele vejen igennem.Men det er over 20 år siden, og tiden er løbet fra den, og der er kommet bedre metoder siden da (det gør der hele tiden).
Men dem der laver forsvar og astronaut tror de laver noget som er meget mere kritisk end dem som laver biler og medicinaludstyr. Så de skal bruge nogle helt andre metoder - det skal være rigidt, faseopdelt, og helst godt med silo-tænkning. De skal også have alle mulige certificeringer for overhovedet at komme i betragtning (CMMI Level 5 - den kan jo så ikke bruges til det helt store, når emnet falder på kvalitet, men det er jo så heller ikke derfor den er lavet).
Men der er jo masser af fejl i deres software også.

Jeg tror vi kan blive enige om behovet for test (for det er der). Men hvilke former for test og hvornår det bør ske, samt hvorledes man gruber udviklingen an - det tror jeg ikke vi bliver enige om. Jeg er tilhænger af at processen formes efter projektet (menneskene involveret, opgaven osv.). Det ser ud som om du læner mere til den side der siger at projektet må indordne sig under en bestemt model for hvordan vi når til målet?

  • 0
  • 0
Log ind eller Opret konto for at kommentere