Bliv gratis medlem
|
|
Søger udvikler
|
Det kan være et problem for en ikke-teknisk person at vurdere økonomien i de forskellige dele af en løsning. Men kunden er selvfølgelig central i udviklingen af en kravsspec. Ofte er den endelige kravsspecifikation baseret på et skriftligt oplæg fra kunden. Det vigtigste for os er egentlig også at kunden er tilfreds med pris og kvalitet. |
|
|
 |
Nu kan det snart være nok..... ;o)
Den artikel glæder jeg mig meget til at se. Der er skrevet og sagt meget om kravspecifikationer de seneste 20 år, hvor jeg har beskæftiget mig med softwareudvikling (primært C og C++). Hvis det er lykkedes en ung gut på 24 år at finde de vise sten, så er det jo bare super :-) Min erfaring er at kravspecifikationer udarbejdet vha. Use Case teknikken, giver bedre specifikationer, idet specifikationen så tager udgangspunkt i opfyldelse af funktioner, der er til gavn for systemets aktører og interessenter. Ellers er jeg meget enig i det Jon Hauge skriver. Kunsten er netop at omsætte kundens ønsker til en GOD kravspecifikation, der skal danne grundlaget for det videre udviklingsarbejde. Bruger man Use cases, kan de anvendes i udviklingsforløbet til at definere iterationerne med, og dermed til at styre projektets leverancer, ligesom Use Casene danner udgangspunkt for specifikation af accepttesten. Når du nu siger, at det er noget fis jeg skriver, synes jeg absolut at du bør gøre alvor af at poste din artikel herinde. Jeg er ikke for gammel til at lære noget nyt, så jeg venter i spænding ;-) |
|
Men hvis du smider mig en mail på mail@mc-solutions.dk skal jeg da gerne sende den til dig med det samme hvis du har nogen kommentarer. Vil skam gerne have kommentarer på det, alting kan jo forbedres. |
Nej, bestemt ikke! Så skulle jeg da nærmere blive fornærmet over, at du bruger ordet "fis", om det jeg skrev ;-) Jeg har sendt dig en mail for at kunne modtage din artikel. På forhånd tak! |
|
Jeg tror ikke det giver mening, at diskuterer hvad der præcist ligger bag ordet en kravspecifikation. Det har mange forskellige betydninger for mange forskellige mennesker, og det er svært at se hvorfor en skulle være mere rigtig end en anden. Så hvis en diskussion skal havde et facit er det nok nødvendigt at fastlægge en ramme, i form af et process valg. F.eks. Rational Unified Process, XP eller Microsoft Solutions Framework. I RUP''en vil en krav. spec. nok bestå af nogle Use Case beskrivelser plus supplerende specifikationer og iXP ville det være noget så abstrakt som en metafor. Men det er lidt kedeligt at diskuterer noget med et endegyldigt facit, den slags bør nok slås op. Hvad der derimod er interessant, er diskussion om hvor tidligt udviklerer og arkitekter skal involveres i udarbejdelsen af krav. Her er det min egen erfaring at det ikke kan ske for tidligt, så jeg ser det bestemt som positivt og proffesionelt at Jon vil hjælpe trådens ophavsmand med uarbejdelse af krav. |
|
|
Opret bruger