Visure lahendused


Toetus
Registreeri
Logi sisse
Alusta tasuta prooviversiooni

Kui kaua nõuded aega võtavad?

Kui kaua nõuded aega võtavad?

Sisukord

Kas olete kunagi mõelnud, kui palju aega kuluks teie tulevase projekti jaoks nõuete loomiseks? Seda küsimust küsivad sageli ärianalüütikud ja juhid.

Enamiku tarkvara ja tootearendusega seotud probleemide puhul ei ole ühest vastust, mis sobiks kõigile; vastus sõltub tõesti teie ainulaadsetest asjaoludest.

Sellele probleemile aitavad kaasa mitmed muutujad, valdkonna juhtivad keskmised näitavad, kui suur protsent projekti jõupingutustest tuleks pühendada nõuete väljatöötamisele, nagu kogumine ja esilekutsumine.

Kuidas saate määrata, kui palju aega ja vaeva kulub selliste tegevuste jaoks nagu nõuete kogumine? Pole üllatav, et erinevate võrdlusaluste andmed ei ole alati üksteisega kooskõlas. Samuti on vaieldav, kas need "tavalised" projektid on teie omadega sarnased. Selle probleemi lahendamiseks kohandasin selles artiklis mõningaid ideid oma raamatust "Lisateave tarkvaranõuete kohta" – vaadake seda!

Tööstuse võrdlusalused

Et tuua näiteid võrdlusaluste võimalikust kasulikkusest, vaadake tabelit 1. Esitatud andmed näitavad valdkonna keskmisi näitajaid erinevate nõuete väljaselgitamise ja prototüüpide loomise jõupingutuste kohta projektide puhul, mille suurus on 10,000 XNUMX funktsioonipunkti (umbes miljon koodirida), mis pärinevad Capers Jonesi "Tarkvarahinnangud, võrdlusalused ja parimad tavad". Kui asjakohased on need arvud teie enda projekti jaoks?

Selliste tööstusharu võrdlusaluste kasutamine ei ole ilma puudusteta. Andmed ei näita meile, kas projektid olid tõeliselt edukad või kas edu ja nõuete väljaselgitamiseks tehtud jõupingutuste vahel oli seos. See teave annab meile vaid keskmise, mis on tehtud, mistõttu on raske iga üksiku projekti edu täpselt kirjeldada.

ALM-i nõuete haldustööriist

10% või vähem meeskonna jõupingutuste eraldamine sellistele ülesannetele nagu nõuete kogumine võib osutuda kasulikuks eeldusel, et nad ei jää analüüsi halvatusse. Vastupidiselt levinud arvamusele kiirendab tootmist tegelikult veelgi, kui investeerite oma nõuete arendamise protsessi täiustamisse suuremaid jõupingutusi. Selle kontseptsiooni võimendamine tagab iga projekti jaoks tohutu investeeringutasuvuse!

Kuna Kodakis töötades töötasin väiksemate projektidega, eraldas meie meeskond sageli 15–18% kogu jõupingutusest nõuetekohastele tegevustele. Leidsime, et see investeering vähendas vajalike tarnejärgsete muudatuste hulka. Põhjusi ja tagajärgi on keeruline kindlalt seostada, kuid on tõenäoline, et meie madal hooldusmäär oli suuresti tingitud kasutajate märkimisväärsest osalusest.

Püüdes täpselt välja selgitada, kui palju aega teie järgmise projekti jaoks nõuete kogumine võtab, on keeruline küsimus ja seda võib olla raske täpselt hinnata. Kuid õnneks annab joonis 1 meile ülevaate muutujatest, mis võivad nimetatud protsessi lühendada või pikendada; aitab teil nende vajalike nõuete loomisel tõhusamalt hinnata.

Teie enda kogemus

Alustuseks võib olla kasulik vaadata üle varasemate projektide andmed, et teha kindlaks, milliseid jõupingutusi konkreetselt nõuete kogumiseks pühendati. See võimaldab teil hinnata, kui edukas on teie arendusprotsess minevikus olnud, ja kasutada seda teavet tulevaste ettevõtmiste kulude hindamisel. Täiendava tegurina kohandage oma esialgseid hinnanguid, viidates joonisele 1, millel on välja toodud erinevused tulevaste projektide ja võrdlusprojektide vahel ning võttes arvesse kõiki muid asjakohaseid kaalutlusi seoses teie projektiga. Hindades kõiki joonisel 1 loetletud elemente skaalal vahemikus 0 (mõju puudub) kuni 5 (suur mõju), võib see hinnang aidata teil tuvastada riskitegureid, mis võivad teie nõuete väljatöötamise protsessi laiendada.

Nõuete haldussüsteem

Lisaks muudele elementidele on oluline arvestada projekti elutsükliga. Ärge eeldage, et kõik nõuded tuleks alguses koguda nagu järjestikuse või kosepõhise lähenemise korral (joonisel 2 illustreeritud punktiirjoonega). Selle asemel, et omada eristavat "nõuete faasi", mõelge rekvisiitide hulgale, mis läbivad iga arenguetapi. Kuna meie süsteeminõuete spetsifikatsioon (SRS) areneb ja muudatustaotlused hakkavad tekkima, peame jääma usinaks nõuete algtasemete aktiivsel haldamisel. See on pidev protsess, mis nõuab järjepidevat tähelepanu.

Iteratiivne ja järkjärguline lähenemine

Agiilsed arendusviisid, nagu Scrum, kasutavad progressiivset teed. See võimaldab kasutajatel toote potentsiaalselt kasulikke funktsioone kiiresti kätte saada ja vajaduse korral hõlpsalt oma nõudeid muuta. Seega saavad arendajad pingutuseta sammu pidada pidevalt muutuvate ärinõuetega. Agiilsete projektide puhul on harva vajadus suurte rekvireerimisalgatuste järele väikeste, kuid korrapäraste nõuete kogumise jõupingutuste tõttu (joonis 2 on pidev joon).

Nõuded Baastase

Selle asemel, et keskenduda projekti algusesse, jaotatakse agiilse projekti nõuded erinevatele etappidele. Esialgsed uuringud viivad selle prioriteeditasemel põhinevate funktsioonide üksikasjade kuvamiseni. Kui on aeg arendamiseks ja testimiseks, täpsustavad meeskonnad nõudeid, et neil oleks piisavalt üksikasju, et iga iteratsiooniga enesekindlalt edasi minna.

Aastaid tagasi olin osa tarkvaraarendusmeeskonnast, mis kasutas edu tagamiseks järkjärgulist lähenemist. Igas tsüklis avaldatakse meie projekt kolmenädalaste etappidena, kusjuures esimene osa on pühendatud nõuete kavandamisele ja selle konkreetse juurdekasvu jaoks väljatöötamisele. Selle meetodi abil saavutasime suurepäraseid tulemusi, kuna see tõi ettevõtte kasutajaskonnale iga paari nädala tagant kasulikke funktsioone. Meeskond töötas usinalt uute funktsioonide kiireks pakkumiseks järk-järgult, pakkudes kasutajatele sagedasi värskendusi. Need kasutajate arusaamad olid projekti juhtimisel hindamatud ja aitasid tagada, et selle lõpuleviimisega saavutatakse maksimaalne väärtus.

Kõik algatused ei sobi väikeste tükkidena edastamiseks. Olemasoleva rakenduse ümberehitamisel peab uuel süsteemil olema oluline funktsionaalsus, enne kui kasutajad saavad sellele üle minna. Sõltumata sellest, kui palju teie meeskond iga projektitsükli jooksul lõpetab, peavad nad mõistma selle konkreetse järjestuse nõudeid, et vältida kujunduste, koodide või testide venivaid ümbertegemisi ja ümberkirjutamist.

Planeerimisnõuete väljaselgitamine

Sageli on see keerulisem, kui tundub, kui hakkate koostama uue projekti nõudeid. Ajurünnakute tegemisel, mida teie analüütikud peavad tegema, pidage meeles, kas nad peavad täitma selliseid ülesandeid nagu:

  • Suhete arendamine tootemeistritega läbirääkimiste teel.
  • Arusaamade kogumine interaktiivsete töötubade ja põhjalike intervjuude kaudu.
  • Olemasolevate kirjete ja toodete uurimine võimalike täiustuste leidmiseks.
  • Küsitluste koostamine, levitamine ja dešifreerimine.
  • Prototüüpide kujundamine ja hindamine, mudelite uurimine ja muud edu saavutamiseks vajalikud perspektiivid.
  • Edu saavutamine riskianalüüsi, ohutus- ja turvaprotokollide järgimise, võimalike rikete analüüsimise ja ohuuuringute läbiviimisega.
  • Teie vajaduste üksikasjade logimine andmehoidlasse.
  • Nõuete spetsifikatsioonides kirjeldatud nõudmiste hoolikas kontrollimine.
  • Katsejuhtumite koostamine loetletud nõuete järgi ja nende toimivuse hoolikas hindamine.
  • Pärast põhjalikku ülevaatamist või testimist täpsustage nõuete spetsifikatsioone, et tagada täpsus.

Tulevaste projektide jaoks vajalike jõupingutuste paremaks hindamiseks on oluline õppida tundma erinevaid ülesandeid, mida teie meeskond võib nõuete väljaselgitamise, analüüsi, täpsustamise ja valideerimise raames täita. Need teadmised aitavad teil mõista, kui palju aega iga ülesanne hõlmab, ja aitavad teie projekti jõudlust parandada. See ei tähenda tingimata, et kõik tegevused tuleb iga ettevõtmise juures ära teha, vaid pigem viib eduka tulemuseni arusaam, mida on vaja teha.

Ärge unustage seda postitust jagada!

top