Prasību iegūšana un analīze
Prasību izzināšanas avoti.
Prasību pilnīgai izzināšanai un specificēšanai projekta sākuma posmā tiek
veltīta mazāka uzmanība, izdalot tikai pamata funkcionalitāti. Evolucionārajā
DZCM galvenā prasību izzināšana notiek pēc pirmo programmatūras
prototipu izstrādes, mijiedarbojoties ar pasūtītāja un lietotāju sniegto
atgriezenisko saiti (feedback) un vēlamajām izmaiņām, ieteikumiem un
jaunajām prasībām.
Priekšrocības:
+Projekts var tikt uzsākts arī bez pilnīgas prasību apzināšanas vai izpratnes
par tām, specificētās prasības var nebūt viennozīmīgas;
+Prasības nav fiksētas, izstrādes gaitā tās iespējams ievērojami papildināt,
pilnveidot (izdevīgi pasūtītājam un gala lietotājam (end-user));
+Izdevīgi pasūtītājam, jo par prasību izzināšanas avotiem var kalpot
iepriekšējie programmatūras prototipi.
Trūkumi:
-Jāspēj izvērtēt to, kuri prasību izzināšanas avoti ir būtiski un vērā ņemami,
piemēram, nebūtu iespējams apmierināt katra atsevišķā lietotāja vēlmi
attiecībā pret programmatūras produktu;
-Konkrētas prasības jāspēj apzināt izstrādes gaitā, turklāt tām jābūt pietiekami
nemainīgām, citādi izstrādes process var būt ļoti ilgs un dārgs, tas var
nenonākt līdz pilnībā pabeigtam risinājumam (tikai DZCM starpposmu
prototipu stadijām).
Prasību iegūšanas metodes.
Daļa prasību tiek iegūtas tādos veidos, kā minēts šī darba 1. un 2. nodaļā, taču
galvenā uzmanība veltīta pasūtītāja atgriezeniskajai saite pēc katra
programmatūras prototipa izveides. Salīdzinoši neliela loma ir standartizētai
prasību dokumentācijai, ņemot prasību biežās izmaiņas, īpaši projekta sākuma
stadijā.
Priekšrocības:
+Pasūtītājam ir ļoti elastīgi ieviest vai piedāvāt jaunas prasības, izmaiņas.
Trūkumi:
-Nekonkrētās prasības ir jānoskaidro vēlākajā projekta gaitā, kas var radīt
sarežģījumus projekta plānošanā, izmaksās un laika patēriņā;
-Pietiekami bieži precizētās vai jaunieviestās prasības var būt apgrūtinoši
implementēt, jo tās neatbilst iepriekš projektētajai un veidotajai sistēmas
arhitektūrai; iespējamas situācijas, kurās nepieciešams veikt ievērojamas
programmatūras daļas vai IS pārprojektēšanu.
Prasību dokumentēšanas formas.
Dokumentācijas galvenais objekts ir pabeigtais programmatūras produkts,
nevis tā attīstība (evolūcija) un starpposmos iegūtie prototipi, tādēļ, salīdzinot
ar ūdenskrituma un inkrementālo modeli, dokumentācijai tiek pievēsta
mazāka loma.
Priekšrocības:
+Jāvelta mazāk laika un cilvēkresursu dokumentācijas izveidei un uzturēšanai.
Trūkumi:
-Salīdzinoši grūta prasību trasējamība un specifiskas informācijas atrašanas
problēmsituāciju gadījumā;
-Tā kā prasības ne vienmēr ir viennozīmīgi dokumentētas vai arī nav
dokumentētas vispār, tad tās iespējams dažādi interpretēt.…
