Pievienot darbus Atzīmētie0
Darbs ir veiksmīgi atzīmēts!

Atzīmētie darbi

Skatītie0

Skatītie darbi

Grozs0
Darbs ir sekmīgi pievienots grozam!

Grozs

Reģistrēties

interneta bibliotēka
Atlants.lv bibliotēka
7,49 € Ielikt grozā
Gribi lētāk?
Identifikators:454126
 
Vērtējums:
Publicēts: 23.01.2018.
Valoda: Latviešu
Līmenis: Augstskolas
Literatūras saraksts: 6 vienības
Atsauces: Nav
Darba fragmentsAizvērt

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.…

Autora komentārsAtvērt
Darbu komplekts:
IZDEVĪGI pirkt komplektā ietaupīsi −7,70 €
Materiālu komplekts Nr. 1364060
Parādīt vairāk līdzīgos ...

Atlants

Izvēlies autorizēšanās veidu

E-pasts + parole

E-pasts + parole

Norādīta nepareiza e-pasta adrese vai parole!
Ienākt

Aizmirsi paroli?

Draugiem.pase
Facebook

Neesi reģistrējies?

Reģistrējies un saņem bez maksas!

Lai saņemtu bezmaksas darbus no Atlants.lv, ir nepieciešams reģistrēties. Tas ir vienkārši un aizņems vien dažas sekundes.

Ja Tu jau esi reģistrējies, vari vienkārši un varēsi saņemt bezmaksas darbus.

Atcelt Reģistrēties