Den mest komplette veiledningen for kravhåndtering og sporbarhet

Hvor lang tid tar kravene?

Har du noen gang lurt på hvor mye tid det vil ta å lage kravene til ditt kommende prosjekt? Forretningsanalytikere og ledere stiller ofte dette spørsmålet.

For de fleste problemstillinger knyttet til programvare- og produktutvikling finnes det ikke noe entydig svar; responsen avhenger virkelig av dine unike omstendigheter.

Flere variabler bidrar til dette problemet, ledende bransjegjennomsnitt antyder hvilken prosentandel av et prosjekts innsats som bør vies til kravutvikling som innsamling og fremkalling.

Hvordan kan du finne ut hvor mye tid og innsats som kreves for aktiviteter som kravinnsamling? Ikke overraskende er det ikke alltid data fra forskjellige referanser jibber med hverandre. Det kan også diskuteres om disse "vanlige" prosjektene er beslektet med dine egne. For å hjelpe deg med å løse dette problemet, har jeg tilpasset noen ideer fra boken min "Mer om programvarekrav" i denne artikkelen - sjekk det ut!

Industriverdiene

For å gi et eksempel på den potensielle nytten av benchmarks, vennligst se tabell 1. Dataene som presenteres indikerer bransjegjennomsnitt for ulike kravutstedelse og prototypearbeid angående prosjekter som er 10,000 XNUMX funksjonspunkter i størrelse (omtrent en million linjer med kode), hentet fra Capers Jones "Programvarevurderinger, benchmarks og beste praksis." Hvor relevante er disse tallene for ditt eget prosjekt?

Å bruke industristandarder som disse er ikke uten ulemper. Dataene forteller oss ikke om prosjektene virkelig var vellykkede eller om det var noen sammenheng mellom suksess og innsats for å frembringe krav. Denne informasjonen gir oss bare et gjennomsnitt av hva som er utført, og gjør det derfor vanskelig å nøyaktig beskrive suksessen til hvert enkelt prosjekt.

Å allokere 10 % eller mindre av teamets innsats til oppgaver som kravinnsamling kan vise seg å være fordelaktig, forutsatt at de ikke blir sittende fast i analyselammelse. I motsetning til hva mange tror, vil det å investere en økt mengde innsats i å forbedre utviklingsprosessen for krav faktisk øke hastigheten på produksjonen. Å utnytte dette konseptet gir en enorm avkastning på investeringen for ethvert prosjekt!

Ettersom jeg jobbet med mindre prosjekter da jeg var ansatt i Kodak, allokerte teamet vårt ofte 15 % til 18 % av den totale innsatsen til behovsaktiviteter. Vi fant ut at denne investeringen reduserte mengden nødvendige endringer etter levering. Det er vanskelig å koble sammen årsaker og virkninger med sikkerhet, men det er sannsynlig at vår lave vedlikeholdsrate i stor grad skyldtes å dyrke betydelig brukermedvirkning.

Å prøve å finne ut nøyaktig hvor lang tid det vil ta å samle inn for ditt neste prosjekt, er en vanskelig spørre, og kan være vanskelig å måle nøyaktig. Men heldigvis gir figur 1 oss litt innsikt i variablene som kan forkorte eller forlenge prosessen; hjelper deg å beregne mer effektivt når du oppretter de nødvendige kravene.

Din egen erfaring

For å komme i gang kan det være nyttig å gå gjennom dataene fra tidligere prosjekter for å finne ut hva slags innsats som ble dedikert spesifikt til kravinnsamling. Dette vil tillate deg å vurdere hvor vellykket utviklingsprosessen din har vært tidligere og bruke denne informasjonen når du estimerer kostnadene for fremtidige bestrebelser. Som en tilleggsfaktor, juster dine første estimater ved å referere til figur 1 som skisserer forskjeller mellom kommende prosjekter og benchmark-prosjekter, samt tar i betraktning eventuelle andre relevante hensyn angående prosjektet ditt. Ved å vurdere hvert av elementene oppført i figur 1 på en skala fra 0 (ingen påvirkning) til 5 (stor effekt), kan denne evalueringen hjelpe deg med å oppdage risikofaktorer som kan forlenge kravutviklingsprosessen.

Ved siden av andre elementer er det viktig å vurdere prosjektets livssyklus. Ikke anta at alle krav skal akkumuleres i begynnelsen som i en sekvensiell eller fossefallstilnærming (illustrert med den stiplede linjen i figur 2). I stedet for å ha en særegen "kravfase", tenk på en rekke krav som går gjennom hvert utviklingstrinn. Etter hvert som vår System Requirements Specification (SRS) utvikler seg og endringsforespørsler begynner å dukke opp, må vi være flittige med å aktivt administrere kravenes basislinjer. Dette er en pågående prosess som krever konsekvent oppmerksomhet.

Iterative og inkrementelle tilnærminger

Agile utviklingstilnærminger, som Scrum, tar en progressiv vei. Dette lar brukere få tak i produktets potensielt nyttige funksjoner raskt og enkelt endre kravene deres etter behov. Dermed kan utviklere holde tritt med stadig skiftende forretningskrav uten problemer. Med smidige prosjekter er det sjelden behov for store rekvisisjonsinitiativer på grunn av liten, men regelmessig kravinnkreving (heltrukken linje i figur 2).

I stedet for å være fokusert på starten av prosjektet, spres kravinnsatsen i et smidig prosjekt på ulike stadier. Innledende utforskninger fører til en backlog som beskriver funksjonalitet basert på prioritetsnivået. Når det er tid for utvikling og testing, avgrenser team kravene slik at de har nok detaljer til å fortsette trygt med hver iterasjon.

For mange år siden var jeg en del av et programvareutviklingsteam som utnyttet en inkrementell tilnærming for å sikre suksess. Hver syklus vil prosjektet vårt bli utgitt i tre ukers faser, med den første delen dedikert til å planlegge ut krav og utvikle for det spesifikke inkrementet. Vi ble møtt med gode resultater fra denne metoden da den brakte nyttig funksjonalitet med noen få ukers mellomrom til bedriftens brukerbase. Teamet jobbet iherdig for raskt å levere ny funksjonalitet i trinn, og ga brukerne hyppige oppdateringer. Denne brukerinnsikten var uvurderlig for å veilede prosjektet og bidra til å sikre at maksimal verdi ble oppnådd ved fullføringen.

Ikke alle tiltak egner seg for å levere i små biter. Når du bygger om en eksisterende applikasjon, må det nye systemet ha et betydelig funksjonsnivå før brukere kan gå over til det. Uavhengig av hvor mye teamet ditt fullfører på hver prosjektsyklus, må de forstå kravene for den bestemte sekvensen for å forhindre utstrakte gjentakelser og omskrivninger av design, kode eller tester.

Planleggingskrav fremkalling

Det er ofte mer komplisert enn det ser ut til når du begynner å sette sammen kravene til et nytt prosjekt. Når du brainstormer aktiviteter som analytikerne dine må gjøre, må du huske på om de må utføre oppgaver som disse:

Å dyrke relasjoner med produktforkjempere gjennom forhandlinger.
Innhenting av innsikt gjennom interaktive workshops og dybdeintervjuer.
Undersøker eksisterende poster og produkter for å avdekke potensielle forbedringer.
Konstruere, formidle og tyde undersøkelser.
Designe og vurdere prototyper, studere modeller og andre kravperspektiver for suksess.
Å oppnå suksess gjennom risikovurdering, sikre at sikkerhets- og sikkerhetsprotokoller blir overholdt, analysere potensielle feil og gjennomføre fareundersøkelser.
Logge detaljene om dine behov inn i et datalager.
Undersøker nøye kravene som er beskrevet i kravspesifikasjonene.
Utforme testcases fra de oppførte kravene, og nøye evaluere ytelsen deres.
Etter en grundig gjennomgang eller testing, finjuster kravspesifikasjonene for å sikre nøyaktighet.

For å bedre kunne estimere innsatsen som trengs for fremtidige prosjekter, er det viktig å lære om de ulike oppgavene teamet ditt kan måtte påta seg som en del av kravfremkalling, analyse, spesifikasjon og validering. Denne kunnskapen vil ytterligere hjelpe deg å forstå hvor mye tid hver oppgave innebærer og hjelpe deg med å forbedre prosjektets ytelse. Det betyr ikke nødvendigvis at alle aktiviteter må gjøres på hver virksomhet, men snarere å forstå hva som må gjøres leder veien mot et vellykket resultat.

Ikke glem å dele dette innlegget!