Statistika teigia, kad apie ¾ programinės įrangos projektų nepasiekia užsibrėžtų tikslų — vėluoja, viršija biudžetą arba visiškai sužlunga ir yra nutraukiami. Apklausos rodo, kad didžioji dalis problemų identifikuojama reikalavimų apibrėžimo ir valdymo srityje. Straipsnyje sužinosite, kaip reikia išsamiai dokumentuoti reikalavimus bei taikyti apibrėžtas procedūras pakeitimų valdymui.
Reikalavimų svarba projektų sėkmei
Statistika teigia, kad apie ¾ programinės įrangos projektų nepasiekia užsibrėžtų tikslų — vėluoja, viršija biudžetą arba visiškai sužlunga ir yra nutraukiami. Apklausos rodo, kad didžioji dalis problemų identifikuojama reikalavimų apibrėžimo ir valdymo srityje. Reikalavimai neteisingai suprantami dėl nepakankamo vartotojo įtraukimo, jie nepilnai arba nevienareikšmiškai apibrėžiami, todėl keičiasi projekto eigoje. Pagal reikalavimus vertinama projekto apimtis ir kaštai, planuojamos veiklos bei sekamas progresas. Paprastai reikalavimų pasikeitimų kaina smarkiai išauga projektui pereinant į vėlesnes fazes, kadangi gali tekti taisyti daug jau sukurtų artefaktų: susijusių reikalavimų aprašymus, projektavimo modelius, programinį kodą. Dėl šių priežasčių tradiciniai reikalavimų inžinerijos principai siūlo išsamiai dokumentuoti reikalavimus, siekiant sumažinti reikalavimų pasikeitimų tikimybę, bei taikyti apibrėžtas procedūras pakeitimų valdymui: pateikimui, vertinimui bei realizavimui.
Tradiciniai reikalavimų dokumentavimo ir valdymo metodai
Siekiant tiksliau išsiaiškinti vartotojo poreikius, juos aprašyti ir taip išvengti dažnų reikalavimų pakeitimų, praktikoje yra taikomi įvairūs reikalavimų dokumentavimo būdai:
- projekto vizija;
- verslo modeliavimas;
- verslo srities terminų žodynai;
- vartotojų scenarijai (user stories);
- funkcinių reikalavimų specifikavimas, taikant panaudos atvejų metodą;
- nefunkcinių reikalavimų dokumentavimas;
- funkcionalumo aprašymas, naudojant vartotojo sąsajos prototipus.
Reikalavimų dokumentavimui paprastai yra paruošiami dokumentų šablonai bei jų pildymo taisyklės ir pavyzdžiai. Siekiant reikalavimų aiškumo, dažnai naudojamos grafinės UML diagramos:
- klasių diagramos – verslo srities objektų ir jų ryšių modeliavimui;
- panaudos atvejų diagramos – verslo procesų ir funkcinių reikalavimų realizacijos vizualizavimui;
- veiklos diagramos – vartotojo scenarijų, panaudos atvejų realizacijos vizualizavimui;
- būsenų diagramos – abstrakčiam vartotojo sąsajos veikimo modeliavimui.
Įvairūs procesai, pvz. RUP (Rational Unified Process), siūlo reikalavimų dokumentavimo metodikas bei reikalavimų dokumentų šablonus, kuriuose apibrėžta struktūra ir pateikiami nurodymai, ką kiekviename skyriuje reikėtų rašyti. Tačiau praktikoje standartinės procesų siūlomos metodikos ir dokumentų šablonai yra retai pritaikomi tiesiogiai, nes reikalavimų dokumentavimas priklauso nuo įvairių faktorių:
- projekto specifikos;
- naudojamų programinės įrangos kūrimo metodų;
- tiek užsakovų, tiek kūrėjų kvalifikacijos.
Daugelyje Lietuvoje įgyvendinamų programinės įrangos kūrimo projektų yra taikomi tik keli dokumentavimo būdai. Dažniausiai yra ruošiamos funkcinės reikalavimų specifikacijos, kuriose aprašomos produkto funkcinės savybės (features) arba panaudos atvejai (use cases), reikalavimai detalizuojami naudojant grafinės vartotojo sąsajos prototipus. Dažnai svarbiausi ar sunkiai suprantami iš tekstinio aprašymo reikalavimai atvaizduojami UML arba paprastomis diagramomis.
Efektyviai reikalavimų analizei reikalingi darbuotojai, turintys atitinkamą sistemų analitiko specializaciją.
|
Iš UAB „Baltijos programinė įranga“ analitikų komandos darbo patirties: Kuriant „MagicDraw UML“, kiekvienos versijos naujas funkcionalumas yra išskaidomas į savybes (feature) arba modulius (jeigu tai yra nauja dalis, kuri gali būti gerai atskirta nuo esančio funkcionalumo). Kiekvienai daliai paskiriamas atsakingas analitikas, kuris ruošia atskirą reikalavimų dokumentą: aprašo realizavimo reikalavimus, ypatingą dėmesį skiria vartotojo sąsajai, naudojimo patogumui (usability) ir nefunkciniams reikalavimams. Vėliau analitikas seka jam priskirto funkcionalumo realizavimo procesą, konsultuoja programuotojus ir kokybės inžinierius. Atsakomybė ir kontrolė padeda geriau realizuoti reikalavimus ir paruošti kokybiškesnį produktą. |
|---|
Dokumentuojant reikalavimus dažnai susiduriama su įvairiomis problemomis:
| Nepakankamas vartotojo įtraukimas | Dažnai sunku įtraukti vartotojus į reikalavimų analizę ir verifikavimą. Užsakovą reikia įtikinti kuriamo produkto vartotojų įtraukimo svarba ir surasti tuos asmenis, kurie galėtų aktyviai dalyvauti projekte. |
|---|---|
| Neefektyvi komunikacijos priemonė | Deja tiksliausiai reikalavimus vartotojai suformuluoja vertindami jau realizuotą ir veikiančią programinę įrangą. Šioje situacijoje gelbsti įvairūs reikalavimų dokumentavimo būda, efektyviau perduodantys informaciją: UML diagramos, grafinės vartotojo sąsajos prototipai. |
| Nepilni reikalavimai | Reikalingos dažnos peržiūros, analizė ir testavimas pagal vartojimo scenarijus, kadangi įvairios problemos ir papildomi reikalavimai atsiranda tiktai realizavus pradinę, jau veikiančią programinės įrangos versiją. |
| Neaiškūs reikalavimai | Reikalinga vieninga dokumentavimo sistema: šablonai, apibrėžiantys dokumentų struktūrą bei stilius, užpildymo taisyklės, pavyzdiniai dokumentai, dokumentų peržiūros ir taisymo taisyklės. Taip pat reikalingi reikalavimus dokumentuojančių žmonių apmokymai. |
Nors ir išsamiai dokumentuojant reikalavimus, beveik visada projekto eigoje atsiranda daugiau ar mažiau pakeitimų. Kuo vėliau įvyksta pakeitimas, tuo didesnė yra jo įgyvendinimo kaina. Pakeitimai taip pat turi įtakos projekto apimčiai ir darbų tvarkaraščiams, todėl reikia juos įvertinti, priimti arba atmesti, suskirstyti pagal prioritetus, tikrinti jų realizavimą.
Pav. 1 — Reikalavimų pakeitimų valdymo procedūra
|
Iš UAB „Baltijos programinė įranga“ analitikų komandos darbo patirties: Kuriant „MagicDraw UML“, analitikas aprašo kiekvienos funkcionalumo savybės reikalavimus atskirame dokumente, kurį programuotojai naudoja realizuodami tą savybę. Nepaisant išsamaus aprašymo, dažnai kyla įvairių nesusipratimų ir klausimų, kurie nebuvo išspręsti rašant reikalavimus. Taip pat neretai kyla esminių nesutarimų, dėl reikalavimų pakeitimų ir programinio kodo perdarymų priežasčių. Norint sumažinti tokių pasikeitimų, reikalingos reikalavimų dokumentų peržiūros prieš pradedant projekto realizavimą. Reikalavimus ir jų siūlomus pakeitimus visų pirma peržiūri analitikų vadovas, techninis projekto vadovas bei kokybės grupės vadovas. Mūsų patirtis rodo, kad efektyviausiai reikalavimai peržiūrimi ir išanalizuojami tuomet, kai kokybės inžinieriai testavimo planus parengia pagal aprašytus reikalavimus. Kadangi neišsamiai ar neaiškiai parašyti reikalavimai sukelia daug klausimų, jie išsprendžiami dar prieš realizuojant projektą. |
|---|
„Agile“ reikalavimų valdymas
Šiuo metu sparčiai populiarėja „Agile“ procesai, siūlantys kuo mažiau dėmesio skirti dokumentavimui. Programinė įrangą kuriama trumpomis iteracijomis, o vartotojo poreikiai išsiaiškinami bendraujant tiesiogiai. Tarpinių programinės įrangos versijų vertinimas atliekamas kiekvienos iteracijos pabaigoje.
Grupė žymių programinės įrangos metodologų pasirašė „Agile“ manifestą, kuriame paskelbė, kad labiau vertina:
- Žmones ir bendravimą nei procesus ir įrankius.
- Veikiančią programinę įrangą nei išsamią dokumentaciją.
- Bendradarbiavimą su užsakovais nei kontrakto pasirašymą.
- Reagavimą į pakeitimus nei plano vykdymą.
Jie taip pat išdėstė pagrindinius principus, iš kurių su reikalavimų valdymu labiausiai susiję yra šie:
- Vartotojai ir verslo atstovai turi būti įtraukti į kūrimo procesą ir kasdien jame dalyvauti.
- Efektyviausias informacijos perdavimo būdas yra gyvas bendravimas.
- Reikalavimų pakeitimai yra priimtini netgi vėlyvose projekto fazėse.
Nors „Agile“ siūlomi metodai gali būti labai efektyvūs, tačiau jie reikalauja visiškai kitokio programinės įrangos kūrimo proceso, jo planavimo, valdymo ir finansavimo. Visų pirma, „Agile“ metodai pagrįsti tuo, kad programinės įrangos kūrimas yra apmokamas už trumpo periodo iteracijas pagal dirbtų valandų skaičių. Daugelyje projektų toks požiūris nėra priimtinas, nes iš anksto nustatomas viso projekto biudžetas, pagal numatytus reikalavimus skelbiami konkursai programinei įrangai kurti.
Taip pat sunku įtraukti vartotoją, kai jam pateikiamos dažnai atnaujinamos programinės įrangos versijos. Tai ypač keblu, kai kalbama apie kritines arba svarbias verslo valdymo sistemas (bankinės, gamyklų valdymo, apskaitos sistemos), kurių galutiniai vartotojai neturėtų dirbti su tarpinėmis neišbaigtomis programinės įrangos versijomis. Be to praktikoje dažniausiai yra labai sunku, o kartais ir neįmanoma, įtraukti vartotojus ir verslo atstovus į kasdienius programinės įrangos kūrimo procesus.
Bendraujant gyvai galima išsiaiškinti daug detalių, tačiau nedokumentuota informacija paprastai yra įvairiai interpretuojama ir kinta ją perduodant. Greitai reaguoti į pakeitimus ir atsisakyti formalaus reikalavimų pakeitimų valdymo galima tik tuomet, kai pakeitimai yra nežymūs. Tačiau stambesni pakeitimai turi būti apsvarstomi, įvertinami, jiems turi būti suteikiami prioritetai. Dideli pakeitimai lemia ne tik vykdomo projekto apimtį, darbų tvarkaraščius, bet ir produkto išleidimo į rinką laiką.
Dėl minėtų priežasčių „Agile“ metodai labiau tinkami naujiems produktams kurti bei vykdyti vidinius projektus, kur galutinius vartotojus gali pakeisti kompanijos darbuotojai. Šiuo atveju prioritetų suteikimas ir pakeitimų valdymas tampa mažiau formalus, nes yra lengviau valdyti projekto apimtį, tvarkaraščius ir biudžetą.
Nors „Agile“ metodai beveik idealiai tinka produktams, vidiniams projektams ir atviro kodo sistemoms kurti, tačiau užsakomiems projektams jų tiesiogiai taikyti neverta, nes nėra tenkinamos dauguma potencialios sėkmės sąlygų.
Dokumentavimo artefaktų aprašymai ir pavyzdžiai
Reikalavimų dokumentavimo artefaktų aprašymas:
| Artefaktas | Aprašymas |
|---|---|
| Vizijos dokumentas | Vizijos dokumentas yra vienas svarbiausių reikalavimų dokumentų. Jis padeda užsibrėžti projekto tikslą, ir viso projekto vykdymo metu padeda nenukrypti į šoną. Vizijos dokumente apžvelgiami vartotojo poreikiai bei produkto funkcionalumas, aprašoma dalykinė sritis bei siūlomas sprendimas. |
| Dalykinės srities sąvokų žodynas | Dažnai reikalavimai yra keičiami dėl to, kad jie buvo aprašyti nevienareikšmiškai ir skirtingai suprasti skirtingų žmonių, dalyvaujančių projekte. Reikalavimų daugiareikšmiškumo padeda išvengti dalykinės srities sąvokų žodynas. Jis padeda užtikrinti, kad vartotojas bei sistemos kūrėjas naudotų tą pačią terminologiją, išvengti programinės įrangos kūrėjų nesusišnekėjimo su vartotoju bei įsigilinti į dalykinę sritį. Dalykinės srities sąvokų žodyne reikia paaiškinti visus sistemai specifinius žodžius bei jais apibūdinamų sąvokų svarbiausias savybes. |
| Dalykinės srities analizės modelis | Sudaromas dalykinės srities grafinis modelis, aprašytas statinėmis ir dinaminėmis UML diagramomis. Modeliuojami dalykinės srities terminai, jų tarpusavio ryšiai bei scenarijai, kaip vykdomos tikslinės veiklos. Dinaminis analizės modelis dar yra vadinamas verslo modeliavimu. |
| Funkcinių reikalavimų modelis pagrįstas panaudos atvejais | Aprašomi sistemos funkciniai reikalavimai: kokias funkcijas turi atlikti kuriama sistema, ir kaip šios funkcijos turi būti atliekamos. Šiuolaikiniai programinės įrangos kūrimo metodai paprastai siūlo funkcinius reikalavimus modeliuoti taikant panaudos atvejų metodiką. |
| Nefunkcinių reikalavimų specifikacija | Šalia funkcinių reikalavimų aprašomi ir visi nefunkciniai reikalavimai: kokybės atributai (patogumas, patikimumas, greitis, palaikomumas, saugumas), juridiniai bei kontrolės reikalavimai, palaikomos operacinės sistemos, suderinamumas ir kt. |
| Vartotojo sąsajos specifikacija | Dokumentuojant sistemos reikalavimus galima įtraukti ir vartotojo sąsajos eskizus. Vartotojo sąsajos eskizai padeda klientui lengviau suprasti reikalavimus, jis lengviau įsitraukia i reikalavimų rinkimo bei analizės procesą. Reikalavimai detaliau išsiaiškinami dar reikalavimų rinkimo fazėje, ir išvengiama reikalavimų pasikeitimų vėlesnėse sistemos kūrimo fazėse. |
1 pvz. Dalykinės srities sąvokų žodynas:
| Terminas | Paaiškinimas |
|---|---|
| Draudimo polisas | Dokumentas, aprašantis konkretaus draudimo detales (kliento informaciją, draudimą tipą, parametrus) ir bendras draudimo kontraktui taikomas sąlygas (kliento ir draudimo kompanijos įsipareigojimus). |
| Draudimo kontraktas | Sutartis, kurią pasirašo klientas su draudimo kompanija. Yra trijų rūšių draudimo kontraktai – gyvybės draudimo, turto draudimo ir civilinės atsakomybės. Kiekvienam draudimo kontraktui yra paruošiamas draudimo polisas. |
| Gyvybės draudimas | Gyvybės draudimas yra draudimo rūšis, kada yra apdraudžiama nurodyto asmens gyvybė ir sveikata bei nurodomas naudos gavėjas — asmuo, kuris gauna naudą, jeigu apdraustas asmuo miršta arba suserga kritine liga. Dalis gyvybės draudimo įmokų yra naudojamos lėšų kaupimui, ir naudos gavėjas po kontrakte numatyto laiko, pvz. 10 metų, gali atsiimti sukauptas lėšas. Jeigu gyvybės draudimas yra taikomas ne mažiau nei nustatytą laikotarpį, klientui yra pritaikoma mokesčių lengvata. Gyvybės draudimas yra sudaromas periodui ne trumpesniam nei 5 metai, tačiau gali būti bet kada nutrauktas. |
| Turto draudimas | Turto draudimas yra draudimo rūšis, pagal kurią klientas apdraudžia turtą nurodytai sumai. Įvykus nelaimei, pvz. vagystei, naudos gavėjas gauna išmokas už patirtus nuostolius. Turto draudimas yra sudaromas nurodytam laikotarpiui. |
| Transporto priemonės civilinės atsakomybės draudimas | Transporto priemonės civilinės atsakomybės draudimas yra susiejamas su nurodyta transporto priemone ir apdraudžia nuo eismo įvykių, kuriuos padaro asmuo, vairuojantis kontrakte nurodytą transporto priemonę. Šis draudimas yra privalomas, tačiau visada sudaromas tik vieneriems metams, todėl reikia iš anksto informuoti klientus apie besibaigiančius draudimus. |
| Naudos gavėjas | Asmuo, kuris pagal draudimo kontraktą gauna pinigines išmokas, įvykus draudiminiam įvykiui. |
2 pvz. Dalykinės srities modelis – esybių ir ryšių (ER) diagrama:
3 pvz. Vartotojų poreikių apibrėžimas panaudos atvejų diagrama:
4 pvz. Veiklos diagramų panaudojimas verslo modeliavimui – gyvybės draudimo procedūros aprašymas:
