Den mest komplette guide til kravstyring og sporbarhed

Hvor lang tid tager kravene?

Har du nogensinde spekuleret på, hvor lang tid det ville tage at skabe kravene til dit kommende projekt? Forretningsanalytikere og ledere stiller ofte dette spørgsmål.

For de fleste spørgsmål relateret til software- og produktudvikling er der ikke noget entydigt svar; svaret afhænger virkelig af dine unikke omstændigheder.

Adskillige variabler bidrager til dette problem, førende branchegennemsnit antyder, hvor stor en procentdel af et projekts indsats der bør afsættes til kravudvikling såsom indsamling og fremkaldelse.

Hvordan kan du bestemme den korrekte mængde tid og indsats, der kræves til aktiviteter såsom kravindsamling? Det er ikke overraskende, at data fra forskellige benchmarks ikke altid jibber med hinanden. Det kan også diskuteres, om disse "sædvanlige" projekter er beslægtet med dine egne. For at hjælpe dig med at løse dette problem har jeg tilpasset nogle ideer fra min bog "Mere om softwarekrav" i denne artikel - tjek det ud!

Industri benchmarks

For at give et eksempel på den potentielle anvendelighed af benchmarks henvises til tabel 1. De præsenterede data angiver branchegennemsnit for forskellige krav-elicitation og prototyping-indsats vedrørende projekter, der er 10,000 funktionspunkter i størrelse (ca. en million linjer kode), hentet fra Capers Jones' "Softwarevurderinger, benchmarks og bedste praksis." Hvor relevante er disse tal for dit eget projekt?

Brug af industribenchmarks som disse er ikke uden ulemper. Dataene fortæller os ikke, om projekterne virkelig var succesfulde, eller om der var nogen sammenhæng mellem succes og indsats for at fremkalde krav. Disse oplysninger giver os kun et gennemsnit af, hvad der er blevet udført, hvilket gør det svært at præcist beskrive succesen for hvert enkelt projekt.

At allokere 10 % eller mindre af teamets indsats til opgaver såsom kravindsamling kan vise sig gavnligt, forudsat at de ikke bliver hængende i analyselammelse. I modsætning til hvad folk tror, vil en øget indsats for at forbedre din udviklingsproces for dine krav faktisk fremskynde produktionen. At udnytte dette koncept giver et massivt investeringsafkast for ethvert projekt!

Da jeg arbejdede på mindre projekter, da jeg var ansat hos Kodak, allokerede vores team ofte 15 % til 18 % af den samlede indsats til behovsaktiviteter. Vi fandt ud af, at denne investering reducerede mængden af nødvendige ændringer efter levering. Det er vanskeligt at forbinde årsager og virkninger med sikkerhed, men det er sandsynligt, at vores lave vedligeholdelsesprocent i høj grad skyldtes, at vi dyrkede en betydelig brugerdeltagelse.

At prøve at finde ud af præcis, hvor lang tid det vil tage at samle op til dit næste projekt, er en vanskelig opgave, og det kan være svært at måle præcist. Men heldigvis giver figur 1 os en vis indsigt i de variabler, der kan forkorte eller forlænge nævnte proces; hjælper dig med at estimere mere effektivt, når du opretter de nødvendige krav.

Din egen oplevelse

For at komme i gang kan det være nyttigt at gennemgå dataene fra tidligere projekter for at afgøre, hvilken slags indsats der specifikt var dedikeret til kravindsamling. Dette vil give dig mulighed for at vurdere, hvor vellykket din udviklingsproces har været i fortiden og bruge disse oplysninger, når du estimerer omkostningerne til fremtidige bestræbelser. Som en yderligere faktor kan du justere dine indledende estimater ved at henvise til figur 1, som skitserer forskelle mellem kommende projekter og benchmarkprojekter samt tager højde for eventuelle andre relevante overvejelser vedrørende dit aktuelle projekt. Ved at vurdere hvert af de elementer, der er anført i figur 1, på en skala fra 0 (ingen indflydelse) til 5 (stor effekt), kan denne evaluering hjælpe dig med at opdage risikofaktorer, der kan udvide din kravudviklingsproces.

Ud over andre elementer er det væsentligt at overveje projektets livscyklus. Antag ikke, at alle krav skal akkumuleres i begyndelsen som i en sekventiel tilgang eller vandfaldstilgang (illustreret med den stiplede linje i figur 2). I stedet for at have en karakteristisk "kravfase", så tænk på en række krav, der går gennem hvert udviklingstrin. Efterhånden som vores System Requirements Specification (SRS) udvikler sig, og ændringsanmodninger begynder at opstå, skal vi forblive flittige med aktivt at administrere kravenes basislinjer. Dette er en løbende proces, der kræver konsekvent opmærksomhed.

Iterative og inkrementelle tilgange

Agile udviklingstilgange, som Scrum, tager en progressiv vej. Dette giver brugerne mulighed for at få fingrene i produktets potentielt nyttige funktioner hurtigt og nemt ændre deres krav efter behov. Således kan udviklere nemt følge med i konstant skiftende forretningskrav. Med agile projekter er der sjældent behov for store rekvisitionsinitiativer på grund af en lille, men regelmæssig kravindsamlingsindsats (helttrukket linje i figur 2).

I stedet for at være fokuseret på starten af projektet, er kravindsatsen i et agilt projekt spredt ud over forskellige stadier. Indledende udforskninger fører til et efterslæb, der detaljerer funktionalitet baseret på dets prioritetsniveau. Når det er tid til udvikling og testning, justerer teams kravene, så de har nok detaljer til at fortsætte trygt med hver iteration.

For år siden var jeg en del af et softwareudviklingsteam, der udnyttede en trinvis tilgang til at sikre succes. Hver cyklus ville vores projekt blive frigivet i tre-ugers faser, hvor den første del var dedikeret til at planlægge krav og udvikle til det specifikke trin. Vi blev mødt med gode resultater fra denne metode, da den bragte nyttig funktionalitet med få ugers mellemrum til virksomhedens brugerbase. Teamet arbejdede flittigt for hurtigt at levere ny funktionalitet i trin, hvilket gav brugerne hyppige opdateringer. Disse brugerindsigter var uvurderlige til at vejlede projektet og hjælpe med at sikre, at der blev opnået maksimal værdi ved dets afslutning.

Ikke alle tiltag egner sig til at levere i små bidder. Ved genopbygning af en eksisterende applikation skal det nye system have et betydeligt funktionsniveau, før brugerne kan gå over til det. Uanset hvor meget dit team fuldfører på hver projektcyklus, skal de forstå kravene til den pågældende sekvens for at forhindre udstrakte gentagelser og omskrivninger af design, kode eller test.

Udvikling af planlægningskrav

Det er ofte mere kompliceret, end det ser ud til, når du begynder at samle kravene til et nyt projekt. Når du brainstormer aktiviteter, som dine analytikere skal udføre, skal du huske på, om de bliver nødt til at udføre opgaver som disse:

Dyrkelse af relationer med produktvindere gennem forhandling.
Indsamling af indsigt gennem interaktive workshops og dybdegående interviews.
Undersøgelse af eksisterende optegnelser og produkter for at afdække potentielle forbedringer.
Konstruere, formidle og dechifrere undersøgelser.
Design og vurdering af prototyper, undersøgelse af modeller og andre kravperspektiver for succes.
At opnå succes gennem risikovurdering, sikre, at sikkerheds- og sikkerhedsprotokoller overholdes, analysere potentielle fejl og udføre fareundersøgelser.
Logning af detaljerne om dine behov i et datalager.
Omhyggeligt at undersøge kravene i kravspecifikationerne.
Udarbejdelse af testcases ud fra de anførte krav og omhyggelig evaluering af deres ydeevne.
Efter en grundig gennemgang eller test, finjuster kravspecifikationerne for at sikre nøjagtighed.

For bedre at kunne estimere den nødvendige indsats for fremtidige projekter, er det vigtigt at lære om de forskellige opgaver, dit team muligvis skal påtage sig som en del af kravfremkaldelse, analyse, specifikation og validering. Denne viden vil yderligere hjælpe dig med at forstå, hvor meget tid hver opgave involverer og hjælpe med at forbedre dit projekts ydeevne. Det betyder ikke nødvendigvis, at alle aktiviteter skal udføres på hver venture, men snarere at forstå, hvad der skal gøres, fører vejen til et vellykket resultat.

Glem ikke at dele dette opslag!