Kõige täielikum nõuete haldamise ja jälgitavuse juhend

Projekti õnnestumiseks peavad nõuded olema kvaliteetsed. Standardeid ja tingimusi kehtestades saavad meeskonnad hinnata oma edusamme nende eesmärkide saavutamisel. Kasutatavad mõõdikud erinevad olenevalt tehtavast tööst; mõned üldised jälgimisnõuete näitajad on siiski järgmised:

Testimise ulatus – Kui palju iga süsteemi funktsioone on testitud?
Hinnangu täpsus – Kas spetsifikatsioonides on suur õigsus?
Funktsionaalsuse täielikkus – Kas kõik funktsioonivaldkonnad on piisavalt üksikasjalikult määratletud?
Vastuvõtukriteeriumide selgus – Kas kasutaja aktsepteerimise kriteeriumid on dokumentatsioonist hõlpsasti tuvastatavad?
Muudatustaotlused – Kui palju muutmistaotlusi on pärast spetsifikatsioonide kirjutamist esitatud?

Neid kvalitatiivseid tegureid regulaarselt mõõtes saate kindlaks teha, kuhu teie meeskond peab oma jõupingutused koondama ja projektide kvaliteeti parandama.

Kuidas mõõta nõuete kvaliteeti

Miks on oluline nõuete kvaliteeti hinnata?

Peame kõigepealt kindlaks tegema, kas meil on nõuete probleem ja kui suur see on, et täpselt arvutada, kui palju jõupingutusi on vaja meie ebapiisavate ressursside rahuldavateks muutmiseks.
Juhendajatena püüame nõuete spetsifikatsiooni koostamisel või nõuete analüüsi läbiviimisel tagada, et meie meeskond töötaks tulemuslikult. Kas nad täidavad oma eesmärke?
Võttes arvesse erinevaid stsenaariume, lõime oma nõuete spetsifikatsioonide jaoks võrdlusaluse kriteeriumide kvaliteedimõõdiku väärtuse osas. Iga olukorra kajastamiseks määrasime neli väärtust:
- Originaalse romaani meisterdamine keerulises keskkonnas pole lihtne.
- Uuendusliku narratiivi loomine ilma surve ja piiranguteta.
- Igapäevane areng
- Mittearenduslike esemete soetamine
Oma projektide kõrgeima kvaliteedi tagamiseks kehtestame süsteeminõuete ülevaatuste ja tarkvaranõuete ülevaatuse kirjete võrdlusaluse.

Mis puutub tehnilistesse mõõdikutesse, siis nõuete kvaliteedimõõdik on üks võimsamaid saadaolevaid tööriistu. Ajalooliselt võttes on ju algselt kavandatust erineva väljatöötamine olnud inseneride jaoks tavaline probleem. Kuigi objektiivse standardi kasutamine ei taga iga kord täiuslikke tulemusi, võib see oluliselt vähendada lõpptoote võimalikke riske ja vigu.

toote suurus

Projekti nõuete arvu mõistmine on oluline. Seda saab saavutada kasutusjuhtude, funktsionaalsete nõuete, kasutajalugude, funktsioonide kirjelduste, sündmuste-vastuse tabelite või analüüsimudelite abil. Kuid teie meeskonna valik neid nõudeid esindada ei mõjuta mingil juhul nende põhifunktsiooni – konkreetsetel tingimustel ja funktsionaalsetel vajadustel põhinevate süsteemikäitumiste rakendamist.

Alustage oma nõuete hindamisprotsessi toote väljalaske või arenduse iteratsiooni jaoks määratud individuaalsete funktsionaalsete nõuete loendamisega. Kui erinevad isikud ei saa loendamisel sarnaseid tulemusi, on oluline arvestada ka muud liiki arusaamatuste ja ebaselgustega, mis võivad tulevikus tekkida. Oma meeskonna edusammude täpseks jälgimiseks peate olema teadlik paljudest nõuetest, mis väljalaske moodustavad. Ilma nende teadmisteta ei saa te projekti lõpetamist hinnata! Jälgides, kui palju tööd on teie mahajäämuses veel alles, tagab, et kõik mõistavad, mis peab enne lõpetamist juhtuma.

Tagamaks, et teie funktsionaalsed nõuded on süsteemi suuruse täpne mõõt, on oluline, et analüütikud koostaksid need ühtlaselt üksikasjalikult. Suurepärane viis seda teha on kõrgetasemeliste nõuete jagamine väiksemateks alamkomponentideks, mida saab individuaalselt testida. Teisisõnu peaksid testijad koostama lihtsad testid, mis teevad kindlaks, kas iga nõuet on õigesti rakendatud või mitte. See tagab, et kõik ülesanded nõuavad sama palju rakendamist ja testimist, olenemata nende keerukusest. Tagamaks, et arendajad ja testijad saaksid iga nõuet õigesti rakendada ja testida, on oluline jälgida, kui palju alamnõudeid on. Muud alternatiivsed suuruse määramise meetodid hõlmavad kasutusjuhtumeid ja loo punkte, mis kõik mõõdavad konkreetselt määratletud funktsionaalsuse osa jaoks vajalikku hinnangulist pingutust.

Kuigi funktsionaalsed nõuded on olulised, ei saa tähelepanuta jätta ka mittefunktsionaalseid nõudeid. Need konkreetsed nõudmised nõuavad suuremaid jõupingutusi, et kavandada ja tõhusalt rakendada. Teatud funktsioonid sõltuvad loetletud mittefunktsionaalsetest vajadustest, nagu turvaprobleemid, mis peaksid olema funktsionaalsete funktsioonide hinnangulises suuruses esindatud. Siiski ei kuvata siin kõiki mittefunktsionaalseid soove – nende mõju oma hinnangule on kriitilise tähtsusega! Mõelge järgmistele olukordadele:

Teatud funktsiooni kasutamiseks mitme võimaluse pakkumine suurendab kasutajakogemust; selline ettevõtmine nõuab aga arendajatelt rohkem aega ja energiat, kui ainult ühe juurdepääsuviisi korral.
Isegi kui te ei juuruta uusi tootefunktsioone, võivad sunnitud disaini- ja juurutamispiirangud, nagu välised liidesed, et kohandada olemasolevat töökeskkonda, oluliselt suurendada liidesega seotud töö mahtu.
Maksimaalse jõudluse tagamiseks võib kiire reageerimise tagamiseks olla vaja põhjalikku algoritmi ja andmebaasi kujundamist.
Rangete kättesaadavuse ja töökindluse nõuete täitmiseks on vaja luua tõrkesiirde ja andmete taastamise mehhanismid, mis võivad olla aeganõudvad. Lisaks võivad need nõudmised mõjutada ka teie valitud süsteemiarhitektuuri.

Jälgides nõuete suurenemist aja jooksul, olenemata kasutatud suurusest, saate kasulikku teavet. Minu klient märkas, et nende projektid kasvasid enne tarnimist tavaliselt umbes kakskümmend viis protsenti. Lisaks kestis enamik nende projekte oodatust vähemalt kakskümmend viis protsenti kauem! Siin pole juhus – on selge, et nende kahe suundumuse vahel on seos.

Nõuded Kvaliteet

Võtke aega oma nõuete kvaliteedi mõõtmiseks, tehes neid kontrollides. Dokumenteerige leitud defektid ja jagage need erinevatesse kategooriatesse, nagu puuduvad nõuded, valed, mittevajalikud, ebamäärasus jne. Seejärel analüüsige neid defektitüüpe koos nende algpõhjustega, et tulevased päringud saaks algusest lõpuni õigesti tehtud. Kasutage neid andmeid täiustamisvõimalusena, et suurendada oma nõudmisprotsessi tõhusust! Näiteks kui teete kindlaks, et puuduvad nõuded on tavaliselt korduv probleem, tuleb teie leidmismeetodeid muuta. Võimalik, et teie ärianalüütikud ei küsi piisavalt või ei küsi õigeid päringuid või peate vajaduste väljatöötamise protsessi kaasama veelgi sobivamaid kasutajate esindajaid.

Kui meeskond tunneb kõigi oma nõuete dokumentatsiooni uurimisel ajapuudust, on tõhusam võimalus kontrollida paar lehekülge ja seejärel arvutada välja keskmine defektide tihedus – defektide arv spetsifikatsiooni leheküljel. Eeldades, et see näidis kajastab täpselt kogu dokumenti (mis võib olla üsna oletus), võib selle korrutamine kontrollimata lehtedega anda meile hinnangu, kui palju peidetud vigu võib meie spetsifikatsioonides alles jääda. Kogenematud inspektorid ei pruugi kõiki defekte tuvastada, seega kasutage minimaalse hinnanguna hinnangulist märkimata vigade arvu. Kontrollproovide võtmisega saate hinnata dokumendi kvaliteeti ja otsustada, kas ülejäänud nõuete spetsifikatsiooniga tutvumine on rahaliselt otstarbekas – mis kahtlemata on jah!

Lisaks registreeritakse nõuete vead, mis avastati pärast lähtetaseme kindlaksmääramist. Need probleemid oleksid nõuete väljatöötamisel kvaliteedikontrolli käigus tähelepanuta jäänud. Arvutage oma meeskonna edukuse määr nende vigade leidmisel selles varajases staadiumis – see on palju kulutõhusam kui proovida neid parandada, kui projekteerimine ja kodeerimine on juba lõpetatud!

Ülevaatusandmed võivad anda teile kaks väga väärtuslikku mõõdikut: tõhusus ja tõhusus. Tõhusus väljendab avastatud defektide keskmist arvu töötunnis, samas kui tõhusus näitab, kui suur osa kõigist olemasolevatest puudustest tuvastati kontrolli käigus – meede, mis näitab, kui edukad on teie kontrollid (või muud kvaliteeditagamise tavad) olnud. Tõhusus võimaldab hinnata vea avastamise kulusid kontrollimise teel. Saate võrrelda seda kulu summaga, mis kulub hiljem arenduse käigus või pärast tarnimist leitud nõuete defektide käsitlemiseks, mis võimaldab teil otsustada, kas teie nõuete kvaliteedi parandamine on rahaliselt kasulik.

Nõuete olek

Projektiga kursis püsimiseks jälgige iga nõuet kogu selle eluea jooksul. Täiendava turvalisuse ja täpsuse tagamiseks võite selle teabe salvestamiseks isegi määrata atribuudi väärtuse. Seda tüüpi oleku jälgimine aitab vähendada tarkvaraprojektide puhul levinud dilemmat – valeväiteid, et see on üheksakümmend protsenti tehtud. Igal nõudel peab mis tahes aja jooksul olema üks järgmistest olekutest:

Toetas (keegi toetas seda jõuliselt)
Heakskiitmise protsess oli edukas ja eraldamine on seatud lähtetasemele.
Pärast koodi hoolikat koostamist, skriptimist ja testimist rakendasime selle.
Kui nõue läbis ja testid läbis, kontrolliti selle edukat integreerimist tootega.
See nõue täidetakse hiljem.
Otsustate selle kustutada ja mitte rakendada.
Loobunud (kontseptsioonile ei antud kunagi rohelist tuld)

Lisaks eelnimetatud olekuvalikutele võib kaaluda ka muid olekuid. Mõned võivad valida oleku „Üle vaadatud”, et kinnitada oma nõuded enne nende lisamist põhikonfiguratsioonidesse. Teise võimalusena võivad organisatsioonid kasutada „Kliendile tarnitud” vahendit, et kontrollida, kas nad on nõude puutumata ja õigesti vabastanud.

Kui uurite arendaja käekäiku, võib ta vastata, et selle konkreetse projekti jaoks on 87 nõuet. 61 on juba kinnitatud ja 9 on paigas, kuid ootavad veel kontrollimist, samas kui 17 on veel lõpetamata. Siiski on oluline märkida, et kõik need taotlused ei ühti, kui rääkida nende suurusest või mõjust klientide rahulolule. need võivad nõuda ka erinevat pingutust. Projektijuhina poleks mul kahtlustki, et meil oli täpne arusaam allsüsteemi suurusest ja sellest, kui lähedal see valmimisele oli. See on palju tõhusam, kui lihtsalt öelda: "Ma olen umbes üheksakümmend protsenti valmis". Üldise edusammude pildiga võin kindlalt öelda: "See näeb suurepärane välja!"

Muuda taotlusi

Eduka nõuete haldamise saavutamiseks peab teie organisatsioon tegelema iga nõuete lisamise, kustutamise ja muutmisega. See võimaldab teil jälgida kõigi muudatustaotluste olekut ja mõju. Saate neid andmeid kasutada ka mitmele päringuküsimusele vastamiseks, näiteks:

Kui palju muutmistaotlusi on määratud aja jooksul esitatud?
Kui paljudele taotlustele on vastatud ja kui paljud on jäänud lahendamata?
Kui suur oli taotluste heakskiitmise määr ja kui suur protsent lükati tagasi?
Mil määral kulutas meeskond energiat iga lubatud muudatuse tegemiseks?
Kui kaua on taotlused tavaliselt avatud?
Kui paljusid üksusi (nt nõudeid või artefakte) iga esitatud muudatustaotlus mõjutab keskmiselt?

Veenduge, et jälgiksite kõiki arendusprotsessi käigus tehtud muudatusi pärast iga versiooni lähtetaseme määramist. Pidage meeles, et üks muudatustaotlus võib avaldada mõju paljudele eri tüüpi nõuetele (kasutajale suunatud, funktsionaalsed ja mittefunktsionaalsed). Et hinnata, kui palju muudatusi konkreetsel ajavahemikul tehti, jagage muudatuste arv sellele perioodile eelnevate nõuete kogusummaga (nagu baastaseme määratlemisel).

Me ei taha nõuete volatiilsust täielikult eemaldada. Lõppude lõpuks on nende muutmisel sageli õigustatud põhjendus. Kuid samal ajal peame tagama, et meie projekt saab muudatustega hakkama ja täidab endiselt oma kohustusi. Lõpetamisele lähemale jõudmine toob kaasa lisakulusid, kui muudatusi tehakse sageli; see muudab raskeks kindlaks teha, millal oma toote maailmale lasete! Arengu edenedes peaks enamik projekte muutuma muutustele vastupidavamaks; teisisõnu peaks muudatuste vastuvõtmise kiirus järk-järgult vähenema, kuni see jõuab vabastamise lõppedes nullini. Iteratiivne lähenemine annab meeskondadele mitu võimalust lisada hilisematesse iteratsioonidesse täiustusi, jäädes samal ajal siiski iga tsükli ajaskaala järgi.

Kui teie meeskond on muudatustaotlustega üle ujutatud, on tõenäoline, et valimisprotsess ei olnud kõikehõlmav või projekti edenedes tekivad ideed jätkuvalt. Seetõttu on oluline jälgida, kust need muudatused tulevad turundusest, kasutajatest, müügiinimestest, juhtimismeeskondadest jne. Selle teabe jälgimine aitab teil kindlaks teha, kes ja mis vajab tähelepanu, et minimeerida tähelepanuta jäetud nõudeid ja vältida kommunikatsioonihäireid.

Kui muudatustaotlused jäävad pikemaks ajaks lahendamata, on see selge märk sellest, et teie muudatuste haldamise protsess vajab tähelepanu. Olen olnud isiklikult tunnistajaks ühele organisatsioonile, millel olid mitu aastat vanad ja endiselt pooleliolevad täiustamistaotlused. Selleks, et projektijuht saaks prioriteediks seada oma energiat mahajäämuse kõige olulisemate üksuste osas, peaks see meeskond määrama konkreetsed avatud taotlused kavandatud hooldusväljaanneteks ja muutma muud pikaajalised edasilükatud muudatused tagasilükatuks. Nii saavad nad hõlpsamini tegeleda esmatähtsate ja kiireloomuliste asjadega, enne kui hakkavad tegelema vähem pakilisemate küsimustega.

Aeg ja pingutus

Optimaalse jõudluse tagamiseks soovitame teil tungivalt üles märkida aeg, mille teie meeskond kulutab nõuete kavandamise ülesannetele. See hõlmab kvaliteedinõuete koostamist ja muudatuste juhtimist, edenemise jälgimist, jälgitavuse andmete loomist ja muid selle protsessiga seotud tegevusi.

Inimesed küsivad minult sageli, kui palju aega ja energiat tuleks pühendada projekti vajadustele. See vastus sõltub suuresti selle suurusest, meeskonnast, organisatsioonist ja selle eesmärgist. Selliste projektide kriitilistesse ülesannetesse investeeritud jõupingutuste jälgimine aitab teil tulevasi ülesandeid täpsete hinnangute abil paremini planeerida.

Kui teie meeskond on varem projekti lõpetanud ja pühendanud 10% oma ajast nõuetele, olete järelemõtlemisel märganud, et nende nõuete kvaliteeti saab palju parandada. Kui tegemist on mõne teise samalaadse projektiga, oleks projektijuhil mõistlik tagada, et põhjalike spetsifikatsioonide koostamiseks panustatakse rohkem – piisama peaks olema üle kümne protsendi olemasolevatest ressurssidest!

Andmeid kogudes ja analüüsides võrrelge projekti arendustegevust toote suuruse mõõtmisega. Teie dokumenteeritud nõuded annavad aimu selle üldisest suurusest. Täpsemalt saate võrrelda jõupingutusi testitavate individuaalsete spetsifikatsioonide, kasutusjuhtumite või funktsioonipunktide loendamiseks – olenemata sellest, mis on proportsionaalne teie toote mõõtudega. Selles kontekstis joonisel 1 viidates saadakse mõõteriist teie arendusmeeskonna võimete hindamiseks, mis aitab veelgi prognoosida väljalaske sisu ja seda täpselt määrata! Kogudes oma toote suurusega seotud andmeid ja pannes tähele sellega seotud juurutamispingutusi, saate koostada täpsed hinnangud sarnaste tulevaste projektide ettevalmistamiseks.

Hirm võib mõlguda paljude meeles; karta, et tarkvara mõõtmisprogrammi väljatöötamine röövib oluliste ülesannete jaoks väärtuslikku aega. Vastupidi, tõhusa ja sihipärase meetrikasüsteemi rakendamine ei nõua liiga palju pingutusi ega energiat. Kõik, mida pead tegema, on luua andmete kogumiseks ja analüüsimiseks põhiinfrastruktuur ning julgustada oma meeskonnaliikmeid oma töötegevuse kohta asjakohaseid üksikasju logima. Kui loote oma ettevõttes mõõdikutel põhineva kultuuri, on hämmastav, mida selle meetodi abil saab õppida!

Järeldus

Nõuete väljaselgitamine ja analüüs on tarkvaraarenduse olulised komponendid. Ilma nendeta võib projekt puuduvate või ebaõigete spetsifikatsioonide tõttu ebaõnnestuda, mis toob kaasa kuluka ümbertöötlemise ja potentsiaalselt ebarahuldavaid tulemusi. Seetõttu on oluline tagada, et kogu projekti ajakava jooksul oleks olemas tõhus protsess nõuete kogumiseks ja täpsuse kontrollimiseks. Nõuetekohase juhtimisega saavad meeskonnad edu saavutada, luues üksikasjalikud nõuded, mis kirjeldavad täpselt kõiki soovitud funktsioone, tagades, et midagi ei jää kahe silma vahele. Hinnates regulaarselt iga ettevõtmise olemasolevaid protsesse ja mõõdikuid, saavad meeskonnad arendustsüklite ajal kasutajate tagasisidet otsides paremini aru saada, mis nende jaoks kõige paremini sobib. See aitab hoida projekte õigel teel ja aitab saavutada kvaliteetsemaid tulemusi.

Ärge unustage seda postitust jagada!