Visure-løsninger


Support
Tilmeld
Login
Start gratis prøveversion

Sådan måler du kravkvalitet

Kravene skal besidde kvalitet, hvis projektet skal lykkes. Ved at sætte standarder og betingelser kan teams evaluere deres fremskridt hen imod at nå disse mål. De anvendte målinger vil variere afhængigt af det arbejde, der udføres; nogle generelle indikatorer for sporingskrav omfatter dog:

  • Testdækning – Hvor mange af hvert systems funktioner er blevet testet?
  • Vurderingsnøjagtighed – Er der en høj grad af korrekthed i specifikationerne?
  • Fuldstændig funktionalitet – Er alle funktionsområder specificeret tilstrækkeligt detaljeret?
  • Acceptkriterier Klarhed – Kan brugeracceptkriterier let identificeres ud fra dokumentationen?
  • Ændringsanmodninger – Hvor mange ændringsanmodninger er der blevet indgivet, siden specifikationerne blev skrevet?

Ved regelmæssigt at måle disse kvalitative faktorer, vil du være i stand til at identificere, hvor dit team skal fokusere deres indsats og forbedre kvaliteten af ​​dine projekter.

Sådan måler du kravkvalitet

Indholdsfortegnelse

Hvorfor er det vigtigt at vurdere kvaliteten af ​​kravene?

  • Vi skal først afgøre, om vi har et kravsproblem, og hvor stort et problem det er, for nøjagtigt at kunne beregne mængden af ​​indsats, der er nødvendig for at omdanne vores utilstrækkelige ressourcer til tilfredsstillende.
  • Som supervisorer stræber vi efter at sikre, at vores team arbejder produktivt, mens de konstruerer en kravspecifikation eller udfører en kravanalyse. Opfylder de deres mål?
  • Under hensyntagen til de forskellige scenarier etablerede vi et benchmark for vores kravspecifikationer med hensyn til værdien af ​​en kriteriekvalitetsmåling. Vi sætter fire værdier for at afspejle hver situation henholdsvis:
    • At lave en original roman i et vanskeligt miljø er ikke let.
    • Udarbejdelse af en innovativ fortælling uden pres eller begrænsninger.
    • Mundan udvikling
    • Anskaffelse af ikke-udviklingsmæssige genstande
  • For at sikre den højeste kvalitet for vores projekter etablerer vi et benchmark for systemkravsanmeldelser og softwarekravgennemgange.

Når det kommer til tekniske målinger, er en kravkvalitetsmåling et af de mest kraftfulde værktøjer, der findes. Det har jo historisk set været et almindeligt problem for ingeniører at udvikle noget andet, end det oprindeligt var meningen. Selvom brug af en objektiv standard ikke garanterer perfekte resultater hver gang, kan det drastisk reducere potentielle risici og mangler i det endelige produkt.

Produkt Størrelse

Det er vigtigt at forstå antallet af krav i et projekt. Dette kan opnås gennem use cases, funktionelle krav, brugerhistorier, funktionsbeskrivelser, hændelsesresponstabeller eller analysemodeller. Dit teams valg om at repræsentere disse krav påvirker dog på ingen måde deres primære funktion – implementering af systemadfærd baseret på specifikke forhold og funktionelle nødvendigheder.

Start din kravvurderingsproces ved at tælle de individuelle funktionelle krav, der er allokeret til en produktudgivelse eller udviklingsiteration. Hvis forskellige personer ikke kan få lignende resultater, når de tæller, er det vigtigt at tage højde for andre former for misforståelser og uklarheder, der kan opstå i fremtiden. Du skal være opmærksom på antallet af krav, der udgør en udgivelse, for nøjagtigt at kunne spore dit teams fremskridt. Uden denne viden vil du ikke have nogen måde at måle, hvornår du er færdig med projektet! At holde øje med, hvor meget arbejde, der stadig er tilbage i din backlog, sikrer, at alle forstår, hvad der skal ske før færdiggørelse.

For at sikre, at dine funktionelle krav er et nøjagtigt mål for systemstørrelse, er det vigtigt for analytikere at skabe dem på et ensartet detaljeringsniveau. En god måde at gøre dette på er ved at opdele krav på højt niveau i mindre underordnede komponenter, som kan testes individuelt. Med andre ord bør testere designe enkle test, som vil fastslå, om hvert krav er blevet korrekt implementeret eller ej. Dette sikrer, at alle opgaver kræver den samme mængde implementering og testindsats uanset deres kompleksitet. For at sikre, at udviklerne og testerne kan implementere og teste hvert enkelt krav korrekt, er det vigtigt at holde styr på, hvor mange underordnede krav der er. Andre alternative dimensioneringsmetoder omfatter use case points og story points, som alle måler den anslåede indsats, der er nødvendig for en særlig defineret del af funktionalitet.

Selvom funktionelle krav er væsentlige, kan ikke-funktionelle heller ikke overses. Disse særlige krav kræver en øget indsats for at designe og implementere effektivt. Visse funktioner er afhængige af de anførte ikke-funktionelle behov såsom sikkerhedsproblemer, som bør være repræsenteret i den estimerede størrelse for funktionelle funktioner. Alle ikke-funktionelle ønsker vil dog ikke blive vist her - det er afgørende at tage deres indflydelse på dit estimat i betragtning! Overvej følgende situationer:

  • At give flere veje til at bruge en bestemt funktion forbedrer brugeroplevelsen; et sådant tiltag kræver dog mere tid og energi af udviklerne, end hvis der kun er én adgangsmetode tilgængelig.
  • Selv hvis du ikke implementerer nye produktfunktioner, kan tvungne design- og implementeringsbegrænsninger som eksterne grænseflader for at imødekomme et eksisterende driftsmiljø øge mængden af ​​det nødvendige grænsefladearbejde betydeligt.
  • For at sikre maksimal ydeevne kan det være nødvendigt med omhyggelig algoritme- og databasedesignarbejde for at garantere hurtige svar.
  • For at opfylde strenge krav til tilgængelighed og pålidelighed er det nødvendigt at bygge failover- og datagendannelsesmekanismer, der kan være tidskrævende. Derudover kan den systemarkitektur, du vælger, også blive påvirket af disse krav.

Ved at spore stigningen i krav over tid, uanset den anvendte størrelsesmåling, får du nyttig indsigt. Min klient bemærkede, at deres projekter normalt steg med omkring femogtyve procent før levering. Derudover kørte de fleste af deres projekter mindst femogtyve procent længere end forventet! Ingen tilfældighed her - det er klart, at der er en sammenhæng mellem disse to tendenser.

Krav Kvalitet

Brug lidt tid på at måle kvaliteten af ​​dine krav ved at udføre inspektioner på dem. Dokumenter eventuelle defekter, du finder, og opdel dem i forskellige kategorier, såsom manglende krav, ukorrekte, unødvendige, vagheder osv. Analyser derefter disse defekttyper sammen med deres grundlæggende årsag, så fremtidige anmodninger udføres korrekt fra start til slut. Brug disse data som en mulighed for forbedringer for at øge effektiviteten af ​​din kravproces! Hvis du for eksempel fastslår, at manglende krav normalt er et tilbagevendende problem, skal dine udløsningsmetoder ændres. Det er muligt, at dine virksomhedsanalytikere ikke stiller nok eller de rigtige forespørgsler, eller måske er du nødt til at inddrage endnu flere passende brugerrepræsentanter i processen med at udvikle behov.

Hvis teamet føler sig presset på tid, når de undersøger al deres kravdokumentation, er en mere effektiv mulighed at inspicere et par sider og derefter beregne den gennemsnitlige defekttæthed - antallet af defekter pr. specifikationsside. Hvis vi antager, at denne prøve nøjagtigt afspejler hele dokumentet (hvilket kan være noget af en antagelse), kan multiplicering af det med uinspekterede sider give os et estimat af, hvor mange skjulte fejl, der kan forblive i vores specifikationer. Uerfarne inspektører er muligvis ikke i stand til at opdage alle defekter, så brug det estimerede antal uplettede fejl som et minimalt skøn. Ved at bruge kontrolprøver kan du vurdere dokumentets kvalitet og tage stilling til, om det er økonomisk muligt at efterse resten af ​​kravspecifikationen – hvilket uden tvivl vil være ja!

Derudover skal du registrere kravdefekter, der er opdaget, efter at baseline er etableret. Disse problemer ville være gået ubemærket hen under kvalitetskontrollen, mens kravene blev udviklet. Beregn dit teams succesrate med at finde disse fejl på dette tidlige stadie – det vil være langt mere omkostningseffektivt end at forsøge at rette dem, når design og kodning allerede er afsluttet!

Inspektionsdata kan give dig to meget værdifulde målinger: effektivitet og effektivitet. Effektivitet kvantificerer det gennemsnitlige antal defekter, der er opdaget pr. arbejdstime, mens Effektivitet angiver, hvor stor en andel af alle eksisterende mangler, der blev identificeret via inspektion – et mål, der giver en indikation af, hvor vellykket dine inspektioner (eller anden kvalitetssikringspraksis) har været. Effektivitet giver dig mulighed for at estimere omkostningerne ved at opdage en defekt gennem inspektion. Du kan afveje denne omkostning i forhold til det beløb, der er brugt på at håndtere defekter i krav, der findes senere i udviklingen eller efter levering, så du kan afgøre, om det er økonomisk værd at forbedre dine kravkvalitet.

Medicinsk udstyr risikostyring

Krav Status

For at være på toppen af ​​projektet skal du spore hvert krav gennem dets levetid. Du kan endda tildele en attributværdi for at gemme disse oplysninger for ekstra sikkerhed og nøjagtighed. Denne type statussporing vil hjælpe med at reducere det almindelige dilemma med softwareprojekter - fejlagtigt hævde, at det er "halvfems procent udført". Ethvert krav skal have en af ​​disse statusser inden for en given tidsramme:

  • Advokate (nogen støttede det kraftigt)
  • Godkendelsesprocessen var vellykket, og tildelingen er blevet placeret på en basislinje.
  • Efter omhyggeligt udformning, scripting og test af koden implementerede vi den.
  • Når kravet gennemgik og bestod sine tests, blev det verificeret for vellykket integration i produktet.
  • Dette krav vil blive opfyldt på et senere tidspunkt.
  • Du beslutter dig for at slette det og ikke implementere det.
  • Afvist (konceptet fik aldrig grønt lys)

Udover de førnævnte statusmuligheder kan andre statusser overvejes. Nogle kan vælge en "Reviewed"-status for at validere deres krav, før de tilføjer dem til baseline-konfigurationer. Alternativt kan organisationer bruge "Leveret til kunden" som et middel til at bekræfte, at de har frigivet kravet intakt og korrekt.

Hvis du spørger til en udviklers fremskridt, svarer han måske, at der er 87 krav til netop dette projekt. 61 er allerede blevet bekræftet, og 9 er på plads, men afventer stadig bekræftelse, mens 17 mangler at blive afsluttet. Det er dog vigtigt at bemærke, at disse anmodninger ikke alle stemmer overens, når det kommer til størrelse eller effekt på kundetilfredshed; de kan også kræve forskellige mængder af indsats. Som projektleder ville jeg ikke være i tvivl om, at vi havde en præcis forståelse af delsystemets størrelse, og hvor tæt det var på færdiggørelsen. Dette er meget mere effektivt end blot at sige "Jeg er omkring halvfems procent færdig". Med et overordnet billede af fremskridt kan jeg trygt sige "det ser godt ud!"

Skift anmodninger

For at opnå en vellykket kravstyring skal din organisation tage sig af hver enkelt kravtilføjelse, sletning og ændring. Dette vil gøre dig i stand til at spore status såvel som implikationerne af alle ændringsanmodninger. Du kan også bruge disse data til at besvare flere forespørgselsspørgsmål såsom:

  • Hvor mange anmodninger om ændring er der blevet fremsat inden for den angivne tidsramme?
  • Hvor mange af anmodningerne er blevet besvaret, og hvor mange er stadig uafklarede?
  • Hvad var godkendelsesgraden for anmodninger, og hvor mange procent blev afvist?
  • I hvilket omfang brugte teamet energi på at udføre hver autoriseret ændring?
  • Hvad er det typiske tidsrum, hvor anmodninger forbliver åbne?
  • Hvor mange elementer (f.eks. krav eller artefakter) påvirkes i gennemsnit af hver indsendt ændringsanmodning?

Kravstyringssystem

Sørg for, at du sporer eventuelle ændringer, der er foretaget under udviklingsprocessen, efter at du har angivet en basislinje for hver udgivelse. Husk, at én ændringsanmodning kan have en effekt på adskillige krav af forskellig art (brugerorienteret, funktionel og ikke-funktionel). For at vurdere, hvor mange ændringer der blev gennemgået i en bestemt periode, skal du dividere antallet af ændringer med det samlede antal krav forud for denne periode (som når du definerer din basislinje).

Vi ønsker ikke helt at fjerne ustabiliteten i kravene. Når alt kommer til alt, er der ofte en legitim begrundelse for at ændre dem. Men samtidig skal vi sikre, at vores projekt kan håndtere ændringer og stadig opfylde sine forpligtelser. At komme tættere på færdiggørelse medfører ekstra omkostninger, når der ofte foretages ændringer; dette gør det svært at afgøre, hvornår du vil frigive dit produkt til verden! Efterhånden som udviklingen skrider frem, bør de fleste projekter blive mere modstandsdygtige over for ændringer; med andre ord, hastigheden for accept af ændringer skal gradvist falde, indtil den når nul, når udgivelsen er færdig. En iterativ tilgang giver teams flere chancer for at inkorporere forbedringer i senere iterationer, mens de stadig holder sig på sporet med hver cyklus tidslinje.

Hvis dit team bliver oversvømmet med ændringsanmodninger, er chancerne for, at udløsningsprocessen ikke var omfattende, eller at ideer fortsætter med at opstå, efterhånden som projektet skrider frem. Som sådan er det vigtigt at holde styr på, hvor disse ændringer kommer fra marketing, brugere, sælgere, ledelsesteams osv. At holde styr på disse oplysninger vil hjælpe dig med at bestemme, hvem og hvad der skal være opmærksom på for at minimere oversete krav og forhindre fejlkommunikation hen ad vejen.

Når ændringsanmodninger forbliver uløste over en længere periode, er det en klar indikation af, at din ændringshåndteringsproces har brug for opmærksomhed. Jeg har personligt været vidne til en organisation, der havde anmodninger om forbedringer, der var flere år gamle og stadig afventende. For at få projektlederen til at prioritere deres energi på de vigtigste poster i efterslæbet, bør dette team tildele specifikke åbne anmodninger til planlagte vedligeholdelsesudgivelser og konvertere andre langsigtede udskudte ændringer som afviste. På denne måde kan de lettere tage fat på det, der er væsentligt og presserende først, før de løser mindre presserende spørgsmål.

Tid og indsats

For at sikre optimal ydeevne anbefaler vi på det kraftigste, at du registrerer den tid, dit team bruger på kravtekniske opgaver. Dette omfatter udarbejdelse af kvalitetskrav og styring af ændringer, sporing af fremskridt, oprettelse af sporbarhedsdata og andre aktiviteter relateret til denne proces.

Folk spørger mig ofte, hvor meget tid og energi der skal dedikeres til et projekts fornødenheder. Dette svar afhænger i høj grad af størrelsen, teamet, organisationen, der bygger det, og dets formål. At holde styr på din indsats, der er investeret i kritiske opgaver til projekter som disse, kan hjælpe dig med bedre at planlægge fremtidige med nøjagtige skøn.

Hvis dit team tidligere har gennemført et projekt og allokeret 10 % af sin tid til kravene, har du måske ved eftertanke bemærket, at kvaliteten af ​​disse krav kunne forbedres meget. Hvis du står over for et andet lignende projekt, vil det være klogt for projektlederen at sikre, at der bliver ydet mere for at skabe grundige specifikationer - mere end ti procent af de samlede tilgængelige ressourcer burde være tilstrækkeligt!

Tid og indsats

Mens du indsamler og analyserer data, skal du sammenligne projektudviklingsindsatsen med et mål for produktstørrelse. Dine dokumenterede krav vil give en idé om dens samlede størrelse. For at være mere præcis kan du korrelere indsats for at tælle testbare individuelle specifikationer, use case-punkter eller funktionspunkter – hvad end der er proportionalt med dit produkts målinger. Ved at henvise til figur 1 i denne sammenhæng giver det en målestav til evaluering af dit udviklingsteams evner, som yderligere hjælper med at forudsige udgivelsesindholdet samt scope dem nøjagtigt! Ved at indsamle størrelsesrelaterede data for dit produkt og notere den tilhørende implementeringsindsats, kan du formulere nøjagtige estimater som forberedelse til lignende fremtidige projekter.

Frygt kan blive hængende i manges sind; frygt for, at udvikling af et softwaremåleprogram vil stjæle værdifuld tid fra væsentlige opgaver. Tværtimod kræver implementering af et effektivt og målrettet metrisk system ikke for meget indsats eller energi. Alt du skal gøre er at opbygge en grundlæggende infrastruktur til indsamling og analyse af data, samt opfordre dine teammedlemmer til at logge nogle relevante detaljer om deres arbejdsaktiviteter. Når du skaber en kultur baseret på målinger i din virksomhed, er det utroligt, hvad man kan lære gennem denne metode!

Konklusion

Kravfremkaldelse og analyse er væsentlige komponenter i softwareudvikling. Uden dem kan et projekt mislykkes på grund af manglende eller ukorrekte specifikationer, hvilket kan føre til dyrt omarbejde og potentielt utilfredsstillende resultater. Derfor er det vigtigt at sikre, at du har en effektiv proces på plads til at indsamle krav og verificere nøjagtigheden gennem hele projektets tidslinje. Med korrekt ledelse kan teams opnå succes ved at skabe detaljerede krav, der præcist beskriver al ønsket funktionalitet, hvilket sikrer, at intet overses. Ved at evaluere eksisterende processer og målinger regelmæssigt på hver venture, vil teams være i stand til bedre at forstå, hvad der fungerer bedst for dem, når de søger brugerfeedback under udviklingscyklusser. Dette vil hjælpe med at holde projekter på sporet og bidrage til resultater af højere kvalitet.

Glem ikke at dele dette opslag!

Top