Vilniaus universitetas Matematikos ir informatikos fakultetas Programų sistemų katedra

1

Vilniaus universitetasMatematikos ir informatikos fakultetas

Programų sistemų katedra

Valdas Undzėnas

http://www.mif.vu.lt/~valund

Programų sistemų įsigijimas ir priežiūra

Dalykas skaitomas MIF Programų sistemų 1 kurso magistrantams

2014

2

VU MIF Programų sistemų katedra

Programų sistemų įsigijimas

3

Įvadas (1)

Užsiėmimų formaa) paskaitos;b) seminarai. Įvairiais aspektais nagrinėjama dalyko medžiaga.

Atsiskaitymas už dėstomą dalykąa) pranešimas seminare ir referatas duota tema; b) egzaminas;c) svoris galutiniame įvertinime: 30% - pranešimas ir referatas; 70% - egzaminas.

1. Pradinės pastabos- programinė įranga arba programų sistema

(toliau – PĮ, angl. – SW); - “įsigyti” reiškia, kad gali būti kuriama nauja arba perkama jau egzistuojanti PĮ

(COTS – Commercial Of The Shelf, komercinė nuo lentynos);

- PĮ įsigijimo žinių poreikis (jų reikia organizacijų vadovams, projektų vykdytojams, kt.);

- PĮ įsigijimas skiriasi nuo kitokių objektų įsigijimo (pvz., nuo pastatų, mašinų, medžiagų įsigijimo).

Įvadas (2)

5

2. Mokomojo dalyko skyriai1) PĮ ypatumai;2) skirtingi požiūriai į PĮ įsigijimo procesą;3) PĮ tipai;4) PĮ įsigijimo platesnis kontekstas;5) PĮ įsigijimo nuostatos;6) įsigijimo proceso veiklos ir jų seka;7) darbuotojų grupės PĮ įsigyti sudarymas;8) įsigyjamos PĮ reikalavimų rengimas ir valdymas;9) įsigijimo proceso planavimas;

Įvadas (3)

6

Įvadas (4)

10) kurti naują ar pirkti gatavą PĮ sprendimo priėmimas;

11) įsigijimo sandorių sudarymas; 12) PĮ naudojimo aplinkos apibrėžimas; 13) autorinių ir nuosavybės teisių klausimo sprendimas; 14) PĮ įsigijimo projekto darbų grafiko sudarymas; 15) įsigyjamos PĮ testavimas; 16) darbuotojų mokymas, PĮ naudojimas ir priežiūra; 17) įsigijimo projekto valdymas; 18) PĮ konfigūracijos valdymas; 19) PĮ įsigijimo rizikos valdymas.

7

3. Pagrindiniai šaltiniai PĮ įsigijimo klausimais

1) ISO/IEC 12207:2008, Information technology – Software life cycle processes. 2008;

2) B.Craig Meyers, Patricia Oberndorf. Managing Software Acquisition: open systems and COTS. 2001.

3) CMMI for Acquisition. Version 1.3. November 2010. Technical report. http://www.sei.cmu.edu/reports/10tr032.pdf

4) Valdas Undzėnas. Programų sistemų įsigijimas ir priežiūra. Mokymo medžiaga. 2007. http://www.mif.vu.lt/~valund.

Įvadas (5)

8

I. PĮ ypatumai (1)

1. Dažnos PĮ įsigijimo projektų bėdos

1) galutiniai rezultatai gaunami pavėluotai, t.y. pasibaigus projekto terminui;2) viršijamas projekto biudžetas.

Apskritai apie projektus:a) “Nustatyta, kad pasaulyje tik 16 proc. projektų įgyvendinama laiku. Apie 50 proc. jų dėl blogos vadybos pabrangsta 220 proc., o jų įgyvendinimo laikas pailgėja iki 167 proc. Neinvestuojam į kvalifikuotą žmogų, kad jis vadovautų projektui, ir taip padarom nuostolių valstybei” [„Valstybės tarnybos aktualijos“, 2007 liepa, Nr. 8, „NIEKO NEKEISDAMI, PRIEISIME LIEPTO GALĄ”];

b) The Standish Group's just-released report, "CHAOS Summary 2009" . "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding ...; 44% were challenged ...; 24% failed ...“ http://www1.standishgroup.com/newsroom/chaos_2009.php

9

I. PĮ ypatumai (2)

2. PĮ įsigijimo projektų nesėkmių priežastys

1) PĮ yra žymiai sudėtingesnis objektas, nei kitokios rūšies objektai (pastatai, keliai, mašinos, kt.);

2) žmogaus ir PĮ sąveikos realizacija;

3) PĮ projektavimo išlaidų ir PĮ kainos santykis yra visai kitoks nei kitokių objektų;

4) valdyti PĮ įsigijimo projektus yra sunkiau nei kitokių objektų įsigijimo projektus;

5) supratimas apie PĮ įgyjamas sunkiai;

6) netgi sėkmingo PĮ įsigijimo atveju gali atsirasti neatitikimų tarp poreikių ir PĮ galimybių.

10

3. Įprastos kitokių projektų valdymo veiklos netinka PĮ įsigijimo atveju

4. Prie PĮ įsigijimo projektų ypatumų galima prisitaikyti

I. PĮ ypatumai (3)

11

II. PĮ įsigijimo platesnis kontekstas (1)

1. PĮ yra tik kažkokios sudėtingesnės sistemos dalis

Organizac. poreikių analizė

Siūlomi sprendimo

keliaiSistemos įsigijimas

Naudojimas ir priežiūra

Tolesnis planavimas

Sistemos samprata

12

2. Sistemos įsigijimo proceso veiklos

II. PĮ įsigijimo platesnis kontekstas (2)

Naudojimas ir priežiūra

Sistemos reikalavimai

Sistemos projektavim.

PĮ įsigijimas

AĮ įsigijimas Sistem. dalių

integracijaSistemos

priėmimas

Sistemos įsigijimas

Sistemos samprata

13

III. Požiūriai į PĮ įsigijimo procesą (1)

1. Užsakovų ir tiekėjų požiūriai į klausimus

1) netapk priklausomas nuo tiekėjo;

2) įsigyk individualius poreikius atitinkančią PĮ;3) siek naudos.

14

2. Ką turėtų daryti užsakovas1) jei įmanoma, reikėtų pirkti egzistuojančią PĮ, o ne kurti naują,

individualių poreikių PĮ;

2) palaikyti atvirus užsakovo ir tiekėjo ryšius;

3) parengti formalų testavimo planą PĮ priimti, išdėstyti priėmimo

kriterijus;4) pasirūpinti PĮ priežiūra ir užsakovo darbuotojų mokymu įsigijimo

projekto bėgyje;

5) sandoriuose vengti reikalavimo tiekėjui, kad jis teiktų ir pradinius programų tekstus.

III. Požiūriai į PĮ įsigijimo procesą (2)

15

IV. PĮ tipai

1. PĮ dažnai nulemia sudėtingų sistemų funkcionalumą, patogumą, patikimumą

2. PĮ kategoriją lemiantys veiksniai 1) sukūrimo rizika, “realaus laiko” reikalavimai PĮ; 2) technologinis lygis; 3) įdiegimo vietų kiekis; 4) gatavų produktų tinkamumas PĮ kurti; 5) gebėjimas integruoti įvairias sistemas.

16

V. PĮ įsigijimo nuostatos (1)

1. Nuostatos (požiūris) dėl PĮ 1) nekurkime PĮ patys, jei galima nusipirkti gatavą; 2) kurkime įveikiamos apimties PĮ.

2. Valdymo nuostatos 1) lankstumas; 2) nėra visa apimančių sprendimų; 3) išankstinis planavimas.

17

3. Žmogiškųjų santykių nuostatos1) bendradarbiavimas (tarp užsakovo darbuotojų, su kitų

organizacijų atstovais žvalgantis, su tiekėju);

2) grupės PĮ įsigyti sudarymas užsakovo organizacijoje;

3) atviri užsakovo ir tiekėjo ryšiai;

4) aktyvus užsakovo dalyvavimas įsigijimo procese.


18

4. Ko neturėtų daryti užsakovas1) griežtai reikalauti iš tiekėjo laikytis nustatytų

PĮ reikalavimų ir darbų atlikimo terminų;2) stengtis sutrumpinti įsigijimo darbų grafiką; 3) kurti sudėtingą PĮ vienu užsimojimu, o ne etapais; 4) stengtis gauti iš tiekėjo daugiau, nei numatyta sandoryje; 5) pasirinkus tiekėją, palikti jį dirbti vieną.

5. Ko neturėtų daryti tiekėjas1) nesistengti atlikti viską tiksliai;2) siekti užsitikrinti darbo ateičiai nepriimtinu būdu;3) tikėtis reikalavimų sušvelninimo.


19

1. Dvi pagrindinės veiklos1) PĮ reikalavimų rengimas;2) tiekėjo išrinkimas.

2. Santykis tarp PĮ reikalavimų rengimo ir tiekėjo išrinkimo 1) pirma parengus PĮ reikalavimus yra galimybės pasirinkti

geresnį įsigijimo būdą (kurti naują ar pirkti gatavą PĮ); 2) pirma pasirinkus įsigijimo būdą, sprendžiama, ar PĮ

reikalavimai turi būti parengti iki tiekėjo išrinkimo, ar gali būti rengiami bendradarbiaujant su jau išrinktu tiekėju.

VI. PĮ įsigijimo veiklos ir jų seka (1)

20

3. Apie veiklų eiliškumą1) veiklos dažniausiai būna persidengiančios;

2) PĮ įsigijimo veiklos būna iteracinės (pvz., PĮ reikalavimų rengimo eiga);

3) nagrinėdami veiklas laikysime, kad PĮ reikalavimai parengiami iki tiekėjo išrinkimo, nors veiklų eilės tvarka kartais varijuoja.


21

4. Keletas pastovių veiklų PĮ įsigijimo procese1) įsigijimo grupės sudarymas;2) plano rengimas;3) kalendorinio darbų grafiko rengimas;4) PĮ reikalavimų rengimas ir sandorio su tiekėju sudarymas.


22

5. Apytikris PĮ įsigijimo veiklų grafikas


Išankstinė veikla PĮ kūrimas PĮ naudojimas ir priežiūra

Grupės sudarymas

Plano rengimas

Projekto planas

Projekto samprataReikalavimų

rengimasReikalavimų

peržiūra

Galutiniai reikalavimai

Reikalavimų valdymas

Aplinkos apibrėžimas

Projekto darbų grafikas

Tikrinimas ir priėmimas Mokymas Priežiūra

Projekto valdymas

PĮ konfigūracijos valdymas

Rizikos valdymas

Priėmimo testų ir priežiūros planavimas

PĮ priėmimas

6. Apytikris tiekėjo išrinkimo veiklų grafikas


Grupės PĮ įsigijimui

sudarymas

Sprendimokurti naują ar

pirkti gatavą PĮ priėmimas

Sandorio tipo

pasirinkimas

Prašymo teikti pasiūlymus (RFP)

rengimas

Tiekėjo išrinkimas

Intelektinės nuosavybės

teisių klausimų sprendimas

PĮ reikalavimų peržiūra

Sandorio sudarymas

24

7. PĮ reikalavimų išsamumas ir rengimo laikas


PĮ reikalavimų metmenys

Kurti ar pirkti?

PĮ savybių sąrašo sudarymas

Produkto išrinkimas

Sandorio tipo pasirinkimas

Išsamių reikalavimų rengimas

Užsakymo vykdymas

Tiekėjo išrinkimas

pirkti kurti

25

Grupė – tai nedidelis kiekis įvairių sugebėjimų žmonių, dirbančių, siekiančių ir atsakingų už bendrą tikslą.

1. Kas turėtų būti grupėje1) PĮ techniniai ekspertai; 2) tiesioginiai PĮ naudotojai;3) prižiūrėtojai ir PĮ administratoriai;4) PĮ naudojimo ekspertai; 5) sandorių sudarymo ir viešųjų pirkimų pareigūnai;

6) PĮ srities teisininkai;7) vertėjai.

VII. Grupės PĮ įsigyti sudarymas (1)

26

2. Kur ieškoti žmonių sudarant darbo grupę?

3. Paskiausiai į grupę įtraukiamas narys – tiekėjas

VII. Grupės PĮ įsigyti sudarymas (2)

27

1. Kada rengti planą? (Rengiamas po grupės PĮ įsigijimui sudarymo.

Planas periodiškai turi būti peržiūrimas, kad atitiktų projekto pasiekimus)

2. Plano nauda (padeda vienyti įsigijimo grupės narius, palaikyti ryšį su vadovybe, kt.).

3. Kas turėtų būti plane1) įsigijimo projekto esmė (tikslai, siekiai ir apimtis);2) pagrindimas (kodėl reikia PĮ: taupymas, našumas, kokybė);3) įsigijimo projekto darbų grafikas (nurodomi pagr. kontroliniai taškai);4) projekto dalyviai, jų pareigos;5) sąmata ir finansavimo šaltiniai;

VIII. Įsigijimo projekto planavimas (1)

28

6) kur bus atliekami darbai, darbo sąlygos;

7) įsigijimo strategija (kuriama nauja PĮ, perkami komponentai ar visa PĮ);

8) PĮ darbo aplinka (su kokiomis sistemomis, organizacijomis PĮ turės sąveikauti);

9) kokių standartų reikės laikytis;

10) pagrindinė rizika ir jos valdymas;

11) sandorių strategija (kas bus atliekama pas užsakovą, kas pas tiekėją, konsultantai, kt.);

12) sandorių tipas (fiksuotos kainos, atsiskaitymo už medžiagas ir laiką, kt.);

13) sandorių valdymas (kaip bus vertinama ir valdoma projekto eiga);


29

14) tiesioginiai naudotojai;

15) PĮ priėmimo strategija (priėmimo pagrindas);

16) kaip bus mokomi PĮ naudotojai;

17) kaip bus prižiūrima PĮ po priėmimo;

18) apribojimai (tikrovė, su kuria reikia skaitytis).


30

1. Reikalavimų rengimas

1) reikalavimų svarba (projekto apimties, darbų planavimo, sąmatos, kūrimo, testavimo, t.t. pagrindas);

2) kas rengia reikalavimus (grupės nariai):

- PĮ naudojimo ekspertas (rūpinasi, kad PĮ atitiktų naudotojų darbinius poreikius);

- PĮ techninis ekspertas (rengia aiškius, neprieštaringus, patikrinamus, įgyvendinamus reikalavimus);

- tiesioginis PĮ naudotojas (išdėsto naudotojų poreikius);

- PĮ prižiūrėtojas, administratorius (rūpinasi sutrikimų diagnostikos ir jų šalinimo dalykais);

IX. Įsigyjamos PĮ reikalavimai (1)

31

3) reikalavimų rengimo pradžia (galimos rengimo iteracijos; aiškinamasi, kokios PĮ reikia; turint viziją lankomos parodos, klausinėjama kitose organizacijose, kt.);

4) reikalavimai – tai dokumentas;

5) gerų reikalavimų charakteristikos (ką reikia daryti, o ne kaip reikia daryti; aiškūs, nedviprasmiški, patikrinami, įmanomi įdiegti,

tarpusavyje suderinti);


32

6) kas turi būti reikalavimų dokumente (reikalavimų grupės): funkciniai reikalavimai

- PĮ funkcijos, ką PĮ turi gebėti;- reikalavimai funkcijoms (pvz., išvesti pranešimus apie klaidas);- nurodymai funkcijų atlikimo būdui (rankinis, pusiau ar visiškai automatizuotas);- bendrieji žmogaus ir PĮ sąveikos reikalavimai;- algoritmai ar matematiniai reiškiniai;- atitikties teisės aktams, standartams, PĮ įsigyjančiosios

organizacijos struktūrai reikalavimai;


33

eksploatacinių sąvybių reikalavimai

- vidutinis PĮ reakcijos į kreipinius laikas;- įvesties reikalavimai (pvz., keliais ryšio kanalais);- informacijos perdavimo sparta (transakcijos per laiko vienetą);- sistemos atminties talpa;- klaidingų pavojaus paskelbimų dažnis;- PĮ veikimo tikslumas, nurodant algoritmus; - patikimumas ir priežiūros patogumas (vidutinis laikas tarp gedimų, gedimų šalinimo trukmė);- duomenų saugumas (vientisumas, autentiškumas);- PĮ apsauga (apsauga nuo sugadinimo, nesankcionuoto keitimo, kt.);


34

reikalavimai sąsajoms: vidinėms ir išorinėms

- sąsaja su išorės įrenginiais, jutikliais, kt.;- sąsaja su monitoriais;- sąsaja su naudotojais;- sąsaja su savo ir kitų organizacijų sistemomis, įskaitant nuo

seniau veikiančias;

- sąsaja tarp PĮ komponentų;


35

įvesties reikalavimai

- įvesties duomenų šaltiniai (žmonės, automatai);- duomenų įvesties dažnis;- duomenų leistini dydžiai ir matavimo vienetai;- unikalaus identifikatoriaus suteikimo įvesties duomenims reikalavimas;


36

išvesties reikalavimai

- išvesties laiko nurodymo būtinumas (pvz., perspėjimuose, spausdinamose suvestinėse, kt.) ; - išvesties duomenų adresatai (žmonės, automatai); - duomenų išvesties dažnis;- išvesties duomenų leistini dydžiai ir matavimo vienetai; - unikalaus identifikatoriaus suteikimo išvesties duomenims reikalavimas.


37

7) nereikalaukime pernelyg daug (sumažinus reikalavimus, PĮ kūrimo pastangos, projekto sudėtingumas, darbų trukmė sumažėja žymiai didesniu laipsniu; taip pat žymiai padidėja PĮ patikimumas);

8) PĮ kokybės rodikliai reikalavimuose:- patikimumas (sutrikimų kiekis per laiko vienetą);- veiksnumas (availability; PĮ nesutrinkamo darbo trukmės santykis su visu darbo laiku, proc.);- priežiūros patogumas;- naudojimo patogumas;- plėtros galimybė (plėtoti arba gerinti PĮ);- perkėlimo galimybė, tinkamumas naudoti kitur;


38

9) PĮ reikalavimų lankstumas (reikėtų kurti tokią PĮ, kad joje pakeitimų darymas būtų kiek įmanoma neskausmingas);

10) PĮ reikalavimų rengimo užbaigimo variantai:

- rengiami išsamūs reikalavimai prieš išrenkant tiekėją (argumentai už ir prieš);

- rengiami preliminarūs reikalavimai, kurie tikslinami vėliau drauge su išrinktu tiekėju;

- rengiami tik bendrieji reikalavimai. Detalius rengia tiekėjas;

- skelbiamas prašymas parengti reikalavimus.


39

2. Reikalavimų valdymas (peržiūra, keitimas)1) reikalavimų valdymo būtinumas

(sunku iš anksto tiksliai apibrėžti PĮ; klaidingos prielaidos sėkmei pasiekti - kruopščiai parengti PĮ reikalavimai, griežtas reikalavimų laikymasis, tiekėjo vertimas įgyvendinti visus užsakovo norus; PĮ reikalavimai būna neaiškūs, prastai dokumentuoti);

2) prašykime pastabų dėl reikalavimų (iš galimų tiekėjų, PĮ naudotojų);


40

3) laikas nuo laiko peržiūrėkime PĮ reikalavimus (su išrinktu tiekėju iki sandorio pasirašymo ir vėliau).

Peržiūrų darbotvarkė: - neaiškumų įvardinimas; - reikalavimų nesuderinamumo šalinimas; - trūkstamų reikalavimų įtraukimas; - esamų reikalavimų keitimas geresniais; - nebūtinų arba sunkių reikalavimų šalinimas arba jų prioriteto

mažinimas; - likusių reikalavimų surikiavimas pagal prioritetą;


41

4) pasirašyti PĮ reikalavimai perduodami PĮ konfigūracijos priežiūrai;

5) du prieštaringi norai: koreguoti reikalavimus ir nustatyti nekeičiamą jų dalį (projekto sėkmės rodiklis – patenkinti užsakovo

poreikiai);

6) spręskime PĮ reikalavimų klausimus neatidėliodami, būkime lankstūs;

7) apibrėžkime nekeičiamą PĮ reikalavimų dalį;


42


8) PĮ reikalavimų keitimai:

geri blogi

- šalinantys neaiškumus; - supaprastinantys PĮ; - žemesnio lygmens reikalavimų įtraukimas aukštesnio lygmens reikalavimams paremti.

- didinantys funkcionalumą;- įnešantys naujus reikalavimus; - didinantys projekto apimtį.

43

9) laikykimės formalių procedūrų keisdami PĮ reikalavimus:- iš anksto susitarkime, kaip bus daromi pakeitimai;- PĮ reikalavimų pakeitimų nerealizuokime tol, kol jie nėra pasirašyti;

- siūlomus pakeitimus svarstykime atsižvelgdami į PĮ apimtį, kainą ir darbų grafiką;

- susitarkime dėl reikalavimų dokumento galiojimo trukmės (pvz., iki projekto pabaigos arba kol neatsiras pageidavimas ir bus susitarta keisti reikalavimus); - užsakovo ir tiekėjo atsakomybės už PĮ reikalavimų valdymą;

10) kurkime žmogaus ir PĮ sąsajos reikalavimus greito prototipų rengimo būdu.


44

1. Apie gatavą PĮ (angl. COTS - Commercial Of The Shelf )

1) tai labai dažnai reikalinga PĮ, pvz., tekstų rengyklės, DBVS, kompiliatoriai;

2) gátava PĮ paprastai prekiauja daugiau kaip vienas pardavėjas;

3) jei nėra poreikių atitinkančios gatavos PĮ ir negalima apsieiti be naujos PĮ kūrimo, būtina kruopščiai išsiaiškinti priežastis ir reikalavimus, reikėtų samdyti atitinkamoje srityje patyrusius specialistus.

X. Kurti naują ar pirkti gatavą PĮ? (1)

45

2. Sprendimo kurti naują ar pirkti gatavą PĮ priėmimo veiksniai1) vietinės aplinkybės (pvz., kalba);

2) gatavos PĮ modifikavimo, adaptavimo, kt. reikalingumas;

3) gatavos PĮ veikimo užsakovo aplinkoje galimybės;

4) gatavos PĮ sąsajų su užsakovo turimomis PĮ galimybės;

5) ar gatava PĮ atitinka įvairias užsakovo galimybes;

6) užsakovui priimtinų PĮ kūrėjų buvimas ir jų kaina;

7) gatavos PĮ dokumentų, tinkančių užsakovui, buvimas;

8) užsakovo planai ir galimybės prižiūrėti, plėtoti PĮ;

9) laikas, per kurį PĮ turi būti įdiegta.


46


3. Gatavos PĮ pirkimo rizika, rizikos priežastys ir kaip ją sumažinti

Rizikos priežastis Kaip sumažinti riziką

1. Gatava PĮ negali idealiai atitikti individualių pirkėjo reikalavimų.

Jei gatava PĮ atitinka 80 proc. pirkėjo reikalavimų, sprendimas pirkti ją yra pateisinamas. Didesnis atitikimo proc. – mažesnė rizika.

2. PĮ neatitikimas pardavėjo tvirtinimams; tikrovės ir reklamos neatitikimas.

Reikalaukime akivaizdaus PĮ veikimo pademonstravimo arba padirbėkime su demonstracine arba skolinta PĮ versija.

47



3. PĮ yra blogai suderinta ar ištestuota, gali būti klaidų.

Reikliai žiūrėkime į naujas PĮ versijas; prašykime PĮ kopijos pabandymui.

4. Gatavos PĮ integravimo su kita PĮ ir to patikrinimo rizika. Perkamos PĮ sąsajos gali būti uždaros, nedokumentuotos ir būti privačia nuosavybe.

Patikrinkime visų produktų tarpusavio sąveiką gavę jų kopijas. Tik po to spręskime, ar pirkti gatavus produktus. Gaukime sąsajų aprašus. Reikalavimuose pernelyg nedetalizuokime PĮ darbo aplinkos.

5. PĮ dokumentuota prastai arba iš viso nėra aprašų.

Sužinokime, kokio tipo dokumentai yra PĮ licencijoje. Išnagrinėkime dokumentus prieš pirkdami PĮ.

48



6. Gatavos PĮ uždarumas (ši rizika taip pat yra ir kuriant naują PĮ).

Naudokime standartais paremtą atvirojo tipo PĮ, atvirųjų formatų duomenis, kad juos būtų galima apdoroti ir kitomis priemonėmis.

7. Pardavėjas gali nutraukti prekybą gatava PĮ arba bankrutuoti (ši rizika taip pat yra ir kuriant naują PĮ).

Įvertinkime pardavėjo finansinį stabilumą ir jo parduodamos PĮ paplitimą rinkoje. Reikalaukime raštiškų pardavėjo pasižadėjimų (abejotinas reikalavimas).

8. Pristatymo terminai. Atidžiai sudarykime PĮ pristatymo grafiką, kad būtų realios datos; patikrinkime, ar PĮ jau yra leidžiama.

49



9. Parduodama gatava PĮ gali greitai pasikeisti. Naujų funkcijų įdiegimas viename produkte gali versti atnaujinti ir kitus produktus.

Planuokime keitimus. Parenkime naujos laidos produktų diegimo strategiją. Planuokime licencijų atnaujinimus, PĮ priežiūrą ir administracines išlaidas.

10 Gali būti verčiama pirkti ir diegti tokią PĮ, kurioje šalia jums reikalingų funkcijų yra ir nepageidaujamų.

Peržiūrėkime PĮ modulinę struktūrą, atskirų modulių kainas, įvertinkime nebūtinas PĮ funkcijas ir plėtros galimybes.

50

4. Kaip pirkti gatavą PĮ? Gatavos PĮ įsigijimo žingsniai ir samprotavimai:

1) rengiant PĮ reikalavimus įvardijama, kurie iš jų yra privalomi, o kurie papildomi. Reikalavimuose reikia atspindėti funkcionalumą ir lankstumą, pagrindinį dėmesį skiriant poreikiams, o ne kaip visa tai turėtų būti padaryta;

2) sudaroma grupė gatavai PĮ vertinti ir parengiamas darbų grafikas;

3) įvardinami vertinimo kriterijai, gatavos PĮ pasirinkimo veiksniai ir jų prioritetai. Nurodoma, kokiu laipsniu perkama gatava PĮ turi atitikti reikalavimus ir santykinė PĮ funkcijų svarba biudžeto ir darbų grafiko prasmėmis;


51

4) sudaroma lentelė-matrica, kurioje nurodoma, kokia gatava PĮ ir kokius jūsų reikalavimus atitinka. Į ją įtraukiami PĮ funkciniai ir veikimo

reikalavimai (reikalavimų atitikimas vertinamas taip/ne arba balu 1-10);

5) atsisakoma tos PĮ, kuri neatitinka jūsų nustatytų privalomų reikalavimų. Būkime atidūs, nes PĮ gali būti nauja, moderni;

6) privalomus reikalavimus atitikusi PĮ vertinama kruopščiau, išbandoma artimoje jūsų organizacijai aplinkoje. Vertinimo kriterijai:

PĮ lankstumas, galimybė pritaikyti PĮ naudotojo poreikiams, reikiami pakeitimai, integravimo paprastumas, kiekvieno veiksmo rizika.

Vertinimo kriterijumi gali būti ir pardavėjo kreditavimo galimybės, jo finansinis gyvybingumas;


52

7) gatavą PĮ nupirkusiųjų sąrašo gavimas iš pardavėjo, jų klausinėjimas apie PĮ kokybę, pardavėjo teikiamą pagalbą; išrenkama pirkėjo poreikius geriausiai atitinkanti gatava PĮ;

8) pasirašomas PĮ pirkimo sandoris; jame numatomi punktai, leidžiantys daryti pakeitimus (pvz., reikalavimų, funkcijų, kainos);

sutariama dėl kainos, licencijavimo sąlygų, vartotojų kiekio ir PĮ atnaujinimų;

9) kuriama speciali PĮ nupirktai gatavai PĮ integruoti su anksčiau esama sistema arba kitais posistemiais;

10) įgijus darbo su nupirkta gatava PĮ patirtį, teikiami siūlymai tobulinti ją. Drauge su pardavėju išnagrinėjama, kokius pakeitimus lengviau

daryti;


53

11) jei organizacijos specifiniams poreikiams tenkinti sukurta PĮ derinama su nupirkta gatava PĮ, aptariami intelektinės nuosavybės teisių

klausimai.

Aukščiau išdėstyti gatavos PĮ įsigijimo žingsniai dažnai naudojami formaliame tiekėjo išrinkimo procese.


54

1. Sandorių tipai (pagal apmokėjimą)

1) fiksuotos kainos (mažiausios kainos) sandoriai;

2) išlaidas padengiantieji sandoriai;

3) laiko ir medžiagų apmokėjimo sandoriai.

XI. Įsigijimo sandorių sudarymas (1)

55


2. Kokio tipo sandorį reikėtų rinktis?

Sandorio tipas Pastabos

1) fiksuotos kainos sandoris;

- PĮ kuriama už sutartą kainą; - didesnė rizika tenka tiekėjui;- “laimėjimo-pralaimėjimo” atmosfera tarp užsakovo ir tiekėjo;- sudarant sandorį daroma prielaida, kad visi reikalavimai yra žinomi;- realiai įsigijimo projekto mažiausios kainos nustatyti neįmanoma.

56



2) išlaidas padengiantysis sandoris;

- pasižymi lankstumu; - trūkumas, kad reikia kaupti duomenis auditui, kur lėšos

buvo išleistos;- patarimai naudojantiems šitokius sandorius: • nesiteisinti lėšų stoka sandorio sąlygoms nevykdyti; • nenaudoti išlaidas padengiančiojo sandorio PĮ įsigyti, o fiksuotos kainos sandorių - aparatinei įrangai įsigyti, viename projekte; • didesnių pertvarkymų nereikalaujančiai gatavai PĮ pirkti naudoti fiksuotos kainos sandorius.



3) laiko ir medžiagų apmokėjimo sandoris.

- gerai tinka naujos PĮ kūrimo atveju, ypač kai projektas skaidomas į atskirus etapus;

- įgalina kurti PĮ palaipsniui, planavimą tęsiant projekto eigoje;

- kai prireikia daryti pakeitimus, nereikia grįžti į sandorio pradžią ir iš naujo derėtis dėl viso projekto kainos;

- gali būti nepriimtinas, kai PĮ kūrimo rizika yra maža ir naudojami gatavi komponentai.

58

3. Sandorių pobūdis (pagal vykdymo būdą, aplinkybes)

1) darbų prižiūrėtojo/tiekėjo sandoris (visų pirma parenkamas darbų prižiūrėtojas, o darbus vykdo parinktas tiekėjas);

2) sistemų vadovo sandoris (parenkamas vadovas ar firma, kuri yra atsakinga už visos sistemos sukūrimą ir įdiegimą);

3) projektavimo/kūrimo sandoris (individualių poreikių PĮ kūrimo sandoriai dažniausiai būna šitokio pobūdžio);

4) projektavimo atsižvelgiant į turimas lėšas ir laiko terminus sandoris;

5) kitur įdiegtos PĮ naudojimo ar nuomojimo sandoriai.


59


4. Įvairaus pobūdžio sandorių pliusai ir minusai1) darbų prižiūrėtojo/tiekėjo sandoris (engineer/contractor)

Pliusai Minusai

- seniai sutinkami sandoriai;- gerai apibrėžti vaidmenys;- teisiniai ginčų sprendimo būdai yra įprasti;- galutinis objektas gerai apibrėžiamas ankstyvojoje stadijoje;- tiekėjas valdo subrangovus.

- nelankstus ryšys tarp objekto projekto (design) ir paties objekto;- netinka PĮ kūrimo darbams; - PĮ integravimą ne visada atlieka pirmasis (pagrindinis) tiekėjas;- tiekėjas turi finansinį stimulą ieškoti trūkumų RFP dokumentuose, keisti projektą;- apriboja užsakovo ir tiekėjo bendravimą, kai objektą kuria subrangovas.

60


2) sistemų vadovo sandoris (system manager)

Pliusai Minusai

- PĮ kūrimą, integravimą, bandymus prižiūri vienas asmuo;- PĮ kūrėjas paprastai būna pirmasis (pagrindinis) tiekėjas;- minimali galimybė išsiginti kaltės;- didesnis lankstumas daryti keitimus;- galimybė atmesti mažiausios kainos pasiūlymus; - užsakovui yra lengviau palaikyti ryšį su sistemos vadovu.

- yra mažai sistemų vadovų (firmų);- sistemų vadovai gali būti nežinomi PĮ užsakovams ar pirkėjams;- didelė užsakovo priklausomybė nuo sistemų vadovo;- galutinė PĮ ne taip gerai apibrėžta nei darbų prižiūrėtojo/tiekėjo sandorio pobūdžio atveju;- reikalavimas laikytis mažiausios kainos principo parenkant tiekėją ir perkant aparatinę įrangą.

61


3) projektavimo/kūrimo sandoris (design/build)

Pliusai Minusai

- visa atsakomybė tenka projektuotojų/kūrėjų grupei;- atkrenta projektuotojo žinių perdavimas kūrėjui;- greičiau vykdomi projektai; - geriau organizuoti pirkimus; - bendravimas tik su viena firma; - yra finansinis stimulas greičiau užbaigti darbus; - yra didesnės darbų atlikimo garantijos.

- didesnė užsakovo atsakomybė už tikrinimo ir aprobavimo procesus; - projektavimo/kūrimo sandoris sunkiai skiriamas nuo darbų prižiūrėtojo/tiekėjo sandorio, jei prižiūrėtojas prisideda prie detalių planų rengimo;- galima didesnė kaina dėl tiekėjo rizikos ir aukštos pasiūlymų kainos (PĮ projektas dar nebūna parengtas);- daugiau galimybių pažeisti įstatymus.

62


4) projektavimo atsižvelgiant į turimas lėšas ir laiko terminus sandoris (design to cost and shedule)

Pliusai Minusai

- mažiau kaitaliojami reikalavimai; - mažesnė kainos viršijimo ir nukrypimo nuo laiko grafiko rizika.

- tiekėjas gali nesistengti pateikti alternatyvių projektų;- per daug optimistiški pasiūlymai gali būti išrinkti laimėjusiais.

63


5) kitur įdiegtos PĮ naudojimo ar nuomojimo sandoriai

Tai ilgalaikiai sandoriai, apimantys finansavimą, projektavimą, kūrimą, eksploatavimą ir pajamų rinkimą iš aptarnaujamų asmenų. PĮ diegimo fazėje šitokio pobūdžio sandoriai yra ekvivalentiški projektavimo/kūrimo sandoriams. Skirtumai atsiranda sistemos naudojimo ir priežiūros fazėse. Tai dažnai sutinkamo pobūdžio sandoriai, nes jie nereikalauja iš PĮ užsakovo pradinių (išankstinių) kapitalo investicijų.

64


5. Kokio pobūdžio sandorį reikėtų rinktis?

Sandorio pobūdis: Pastabos

1) darbų prižiūrėtojo/ tiekėjo sandoris;

Nepriimtinas PĮ atveju dėl šių priežasčių: - jie naudojami tik gerai specifikuotoms sistemoms, o parengti detalius PĮ reikalavimus iš anksto neįmanoma; - supriešina užsakovą ir tiekėją, nėra bendradarbiavimo tarp jų; - riboja užsakovo galimybes dalyvauti įsigijimo procese; - tinka kuriant sistemas, kuriose naudojamos žinomos technologijos, kt.

65


Sandorio pobūdis: Pastabos:

2) sistemų vadovo sandoris;

- sistemų vadovas samdomas PĮ įsigijimo laikotarpiui. Jis turi visą įsigyjamos PĮ vaizdą;

- nesklandumai: užsakovas gali turėti ir daugiau sandorių; sistemų vadovui gali tekt rengti PĮ darbui su kitomis sistemomis, kurioms jis nėra pritaręs.

3) projektavimo / kūrimo sandoris.

- suteikia galimybę išspręsti daugumą problemų, būdingų kitokiems sandoriams. Yra lankstesnis;

- atsakomybė tenka vienam tiekėjui.

66

6. Kiti galimi sandorių pasirinkimai 1) konkrečių užduočių sandoriai (projektas skaidomas į dalis); 2) kelių tiekėjų lygiagretus darbas, gale atrenkant vieno rezultatus; 3) pavedant, pvz., universitetams atlikt įsigijimo projektą.

7. Pasirinkto sandorio tipo ar pobūdžio įtaka įsigijimo projektui (pvz., PĮ reikalavimų rengimui).

8. Remkimės sėkmingų įsigijimų pavyzdžiais, ne sandorių tipais 1) nežiūrint sandorio tipo, turi būti sudarytos sąlygos dažniems ir atviriems užsakovo ir tiekėjo kontaktams. Reikalinga aiški

sandorių kalba, ypač jei į PĮ kūrimą įtraukiami subrangovai;2) sandoriuose turi būti numatytas reikiamas lankstumas. Jis turi

būti toks, kad jų metu nebūtų prieinama iki teisminių ginčų.


67

Aplinka – tai išorinės sąlygos, kuriose turės dirbti įsigyjama PĮ. Tai kompiuteriai, operacinė sistema, spausdintuvai, tinklo įranga, DBVS, kitokia PĮ.

1. Kada apibrėžiama PĮ darbo aplinka? Tai daroma rengiant PĮ reikalavimus;

reikalavimai aplinkai – kaip funkciniai arba/ir techniniai.

2. Aplinką apibrėžiantys asmenys užsakovo organizacijoje esantys arba kitose organizacijose samdomi IT specialistai.

XII. PĮ naudojimo aplinkos apibrėžimas (1)

68

3. Aplinkos apibrėžimo detalumas Aplinkos apraše turi būti tik būtini reikalavimai. Pernelyg detalūs aplinkos reikalavimai gali sumažinti potencialių tiekėjų ratą ir padidinti PĮ kūrimo laiką ir kainą.

Pernelyg smulkiai apibrėžta aplinka gatavos PĮ pirkimo atveju įneša tokią riziką: 1) gali būti bereikalinga kliūtis priimti sprendimą dėl gatavos PĮ pirkimo; 2) gali pareikalauti žymių išlaidų gatavai PĮ pertvarkyti, kad ji galėtų

dirbti nurodytoje operacinėje sistemoje, su konkrečia aparatine įranga; 3) pertvarkyta gatava PĮ gali pasidaryti mažiau patikima; 4) galimybė ateityje netekti gatavos PĮ atnaujinimo ir naujų versijų

tiekimo paslaugų.


69

4. Kas nurodoma aplinkos apibrėžime 1) sąsajos su užsakovo organizacijoje ir kitur esančiomis reikalingomis sistemomis;2) esami kompiuterių tinklai ir ryšių priemonės, įskaitant protokolus, tinklo tipą, svarbiausius komponentus, ryšio kanalų tipą ir greitaveiką;3) sąsajos su ateityje planuojama PĮ; 4) naudotojų kiekis ir naudotojų sąsajos (pvz., grafinė sąsaja ar kitokia); 5) vieta ir fizinė aplinka: įstaiga, kambarys; apšviestumas,

erdvės apribojimai, turintys įtakos darbui su pele ar klaviatūra; nenutrūkstamas energijos tiekimas, kt.;


70

6) saugos priemonės:

- fizinės saugos sistemos (užrakinami kambariai); - PĮ apsauga (slaptažodžių naudojimas); - kompiuterinės saugos sistemos (ugniasienės);

7) veikimo būdas: kiek duomenų ir kaip greitai juos reikia apdoroti, darbo tikslumas;

8) standartai.


71

Intelektinės nuosavybės teisės – tai sąvoka, apimanti licencijų, nuosavybės teisių ir autorinių teisių klausimus.

1. Ginčų dėl teisių priežastis Sandorio pusės dažnai nevienodai supranta licencijos, nuosavybės teisės,

autorinės teisės ir teisės parduoti ar nuomoti PĮ sąvokas.

XIII. Autorinių ir nuosavybės teisiųklausimo sprendimas (1)

72

2. Intelektinės nuosavybės teisių į PĮ reikalingumas užsakovui Užsakovo supratimas apie būsimą PĮ priežiūrą dalinai apsprendžia poreikį įgyti intelektinės nuosavybės teises. Išsiaiškinus, kad nepajėgsime naudotis PĮ pradiniu tekstu, nereikalaukime intelektinės nuosavybės teisių.

3. Intelektinės nuosavybės teisių klausimai spręstini atvirai pasitelkus teisininkus Sandoriuose išdėstykime užsakovo ir tiekėjo teises į PĮ.


73

4. Intelektinės nuosavybės teisių klausimai sandoriuose

bendrosios teisės

1) kieno nuosavybė bus PĮ? Kokias teises tai apima?

2) kam priklausys PĮ autorinės teisės? Ką jos apima? 3) ar autorinių teisių nuoroda kaip komentaras turės būti įtraukiama į PĮ pradinį tekstą (source code)? Kas bus įrašytas į PĮ registrą kaip

autorinių teisių turėtojas?


74

užsakovo teisės

4) ar užsakovas galės daryti papildomas darbinės PĮ kopijas vidiniam naudojimui? 5) ar užsakovas galės platinti darbinės PĮ kopijas kitoms giminingoms organizacijoms ar departamentams? 6) ar užsakovas galės platinti darbinės PĮ kopijas ir išduoti licencijas kitiems? 7) ar užsakovas galės dalinti darbinės PĮ kopijas už dyką arba už tam tikrą

mokestį? 8) ar užsakovas galės daryti darbinės PĮ pakeitimus arba kitokius su ja susijusius darbus?


75

9) ar užsakovas galės atskleisti darbinės PĮ pradinį tekstą kitiems tiekėjams arba leisti jiems daryti PĮ pakeitimus?

10) kokios darbinės PĮ dalys galės būti kopijuojamos ar platinamos: pradinis tekstas, objektinis kodas ir/ar dokumentacija? Kiek kopijų gali būti daroma?

11) ar užsakovas turės teisę į tiekėjo vėliau padarytus PĮ atnaujinimus?

12) ar PĮ sudėtyje bus dalys, kurioms naudoti reikės atskirai pirkti licencijas (pvz., UNIX, DBVS, kt.)? Gali reikėti skirtingo šių sistemų kopijų kiekio, norint leisti platinti ar daryti kažką kitą su likusia PĮ dalimi;


13) ar užsakovas turės prieigą prie PĮ pradinių tekstų? Jei taip, tai ar pradiniai tekstai bus kompiliavimui tinkančiuose

failuose, ar tik atspausdinti popieriuje;

14) ar užsakovas turės prieigą prie palaikymo instrumentų ir kūrimo aplinkos, kuri buvo naudota kompiliuojant PĮ, valdant konfigūraciją, testuojant, kt.;

15) ar užsakovas turės teisę į visą mokymo medžiagą?

16) ar užsakovas turės teisę į vykdomąją aplinką, reikalingą PĮ leisti, ar jis privalės ją atskirai įsigyti iš kito tiekėjo?

17) ar užsakovas turės prieigą prie DB formatų ir sąsajų protokolų dokumentų?


77

18) keliuose kompiuteriuose galės būti saugomos PĮ kopijos? Keliuose kompiuteriuose PĮ galės būti leidžiama? (Šie kiekiai gali skirtis, nes, pvz., atstatomosios (backup) kopijos gali būti tik kai kuriuose kompiuteriuose);19) kiek kompiuterių vienu metu galės dirbti su PĮ ar kreiptis į ją? (Tinkle visi kompiuteriai gali turėti galimybę naudoti PĮ arba kreiptis į duomenų bazę, tačiau licencija gali riboti dirbančiųjų kiekį);20) kiek vartotojų gaus licenciją naudoti PĮ? Kiek galės naudoti PĮ vienu

metu? 21) ar bus leidžiama naudoti PĮ tinkle? (PĮ gali būti leidžiama

nuotoliniu būdu, kur ji laikoma pastoviai, arba PĮ kopija laikinai gali būti įkelta į jūsų vietinį kompiuterį ir leidžiama jame);


78

tiekėjo teisės

22) ar tiekėjas galės platinti PĮ kitiems klientams? Jei taip, ar jie turės mokėti už ją?

23) ar tiekėjas galės pakartotinai naudoti PĮ dalis kituose sandoriuose?

24) ar tiekėjas galės patentuoti ar gauti PĮ autorines teises arba patentuoti PĮ dalis? Jei taip, ar užsakovas turės mokėti jam autorinį honorarą (procentus)?

25) ar tiekėjas turės teises į visus užsakovo padarytus PĮ patobulinimus?


79

1. PĮ įsigijimo veiklos ir kontrolės taškai projekto darbų grafike

sandorio sudarymas 1) intelektinės nuosavybės teisės klausimų peržiūra;2) sandorio pasirašymas (kontrolės taškas);3) datos, iki kada užsakovas pateikia tiekėjui sandoriui vykdyti reikalingus

dalykus - įrangą, patalpas, paslaugas (kontrolės taškai);

XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (1)

80

PĮ reikalavimų tvarkymas

4) reikalavimų peržiūra;5) reikalavimų pasirašymas (kontrolės taškas);6) greitas prototipų rengimas;

darbų apimčių vertinimas 7) tiekėjo atliekamas nepriklausomas darbų apimčių ir grafiko

įvertinimas;8) nesutarimų aiškinimasis ir šalinimas;


81

valdymo veiklos

9) rizikos veiksnių peržiūra;10) įsigijimo projekto peržiūra; 11) tikrinimai;12) dokumentų peržiūra;13) dokumentų tvirtinimas (kontrolės taškas);

testavimas PĮ priėmimo metu 14) detalių priėmimo testų planavimas;15) priėmimo testų vykdymas;16) priėmimo testavimo rezultatų analizė;17) PĮ priėmimas (kontrolės taškas);


82

mokymo veiklos

18) mokymo rengimas ir planavimas; 19) mokymas;

PĮ priežiūra 20) PĮ priežiūrai reikalingos infrastruktūros rengimas; 21) perėjimas prie eksploatacijos ir priežiūros (kontrolės taškas).


83

2. Kontrolės taškų nustatymas (jie turi būti vienareikšmiai darbų atlikimo prasme, jokių pasiteisinimų;

vertinimas tik taip: “atlikta” arba “neatlikta”; 100 proc. įvykdymas).

3. Tipinės darbų grafiko sudarymo klaidos

1) nesiremiama formaliais dokumentais (pvz., nesiremiama PĮ reikalavimais, terminai nustatomi įtakojant politiniams ar kitokiems veiksniams. Darbų grafikas ir reikalavimai privalo atitikti vienas kitą);

2) sudaromas pernelyg glaustas grafikas (realus darbų grafikas yra vienas iš dviejų pagrindinių PĮ įsigijimo projekto sėkmės veiksnių. Kitas veiksnys – tai reikalavimų pastovumas).


84

4. Darbų grafiko suspaudimo poveikis projekto kainai


PĮ įsigijimo projekto bendra kaina

Neįmanoma

zona

Laikas

85

5. Darbų grafiko trukmės nustatymas1) PĮ dydžio įvertinimas

(pradinio teksto eilučių kiekių ar funkcijų kiekiu);

2) po to nustatomas laikas ir darbuotojų kiekis, kurių reikės PĮ kurti.

Dažniausiai PĮ skaidoma į kiek įmanoma didesnį komponentų kiekį, įvertinamas kiekvieno jų dydis, o susumavus juos gaunamas visos PĮ dydis.


86

6. Rekomendacijos PĮ dydžiui įvertinti1) tam reikėtų pasitelkti darbo grupės PĮ ekspertus;

2) surinkti kiek įmanoma daugiau PĮ dydžio įvertinimų iš skirtingų asmenų, ypač nepriklausomų;

3) prašyti tiekėjo parengti PĮ dydžio įvertinimą, išsiaiškinti nuomonių skirtumus;

4) PĮ dydį vertinti skaidant ją į kiek įmanoma mažesnes dalis ir vertinant kiekvienos dalies dydį;

5) ekspromtu nevertinti darbų grafiko ar PĮ dydžio.


87

7. PĮ dydžio įvertinimų paklaidos (projekto pradžioje padarytas įvertinimas toli gražu neatitinka tikrovės)


Projekto dydžio

paklaida

Laikas

Projekto samprata

Reikala- vimai

Projekta- vimas

Programa- vimas

Testa- vimas

88

Projekto vadovo dilema: pvz., prašymas vadovybei “leisti kurti PĮ, kas gali trukti nuo 8 mėnesių iki 2 metų ir gali kainuoti nuo 300 tūkst. Lt iki 1,5 mln. Lt“ vargu ar bus patenkintas.

Patarimai projektų vadovams: - pradėti projektą nurodant apytikrį darbų grafiką ir

biudžetą, dalinti projektą į nedideles dalis, įvykdžius dalį tikslinti PĮ apimtį; - stebėti projekto eigą ir išnaudoti tai kaip grįžtamąjį ryšį būsimiems įvertinimams.


89

PĮ testavimas – tai formalus PĮ tikrinimas, ar ji atitinka nustatytus reikalavimus.

1. Laikykimės formalaus, gerai dokumentuoto PĮ testavimo jos priėmimo metu požiūrio

2. Testavimo pagrindas - PĮ reikalavimai

3. Du požiūriai į PĮ testavimą priėmimo metu 1) PĮ veikimas pagal reikalavimus nustatytą laiką;

2) formalus tikrinimas, remiantis testavimo dokumentais.

XV. Įsigyjamos PĮ testavimas (1)

90

4. Priėmimo testo įtraukimas į projektą1) projekto plane nurodomi bendrieji testavimo klausimai: - kur bus atliekami priėmimo testai? - kas atliks testavimą? - bendrieji priėmimo kriterijų reikalavimai, kuriuos turi

atitikti PĮ;

2) darbų grafike nurodomas laikas, kada bus atliekami priėmimo testai, analizuojami testavimo rezultatai, atliekami pataisymai, kartojami testai esant klaidoms.


91

5. PĮ testavimas yra grupinė veikla

6. Formalaus priėmimo testų tipai (testai kruopštūs ir griežti)

1) testai PĮ tikrinti ekstremaliomis sąlygomis (testuojama įvedant klaidingas duomenų reikšmes, tikrinant PĮ našumą ir kas atsitinka, kai PĮ per daug apkraunama);

2) testai PĮ tikrinti darbo aplinkoje (testuojamos galimybės administruoti ją, kiek laiko reikia PĮ paleisti, kas atsitinka, kai nutrūksta ryšio linija su išoriniu įrenginiu; kt.);


92

3) testų tipai: - funkciniai testai; - maksimalių galimybių ir darbo ekstremaliomis

aplinkybėmis testai; - klaidingų įvesties duomenų testai; - stabilumo testai (nepertraukiamo darbo testai); - integralumo testai (tikrinamas PĮ gebėjimas užkirsti kelią

nesankcionuotiems veiksmams).

7. Testavimo kruopštumas


93

8. PĮ priėmimo testavimo dokumentai 1) testavimo planas; 2) testavimo procedūros; 3) testavimo variantai (priklausomai nuo įvesties duomenų); 4) testavimo įrašai; 5) testavimo ataskaita (išvados, ar PĮ atitinka reikalavimus).


94

9. Kas nurodoma testavimo plane užsakovo, tiekėjo ar kitos organizacijos vaidmuo

1) kas bus atsakingas už testų leidimą?2) kas bus atsakingas už testų duomenų registravimą?3) kas bus atsakingas už testų rezultatų analizę ir ataskaitos

(išvadų) parengimą?

kur bus testuojama?

4) pas užsakovą ar kitur? 5) kokioje operacinėje aplinkoje?


testavimo grafikas

6) kompiuterių testams leisti tikrinimas;7) išorinių įrengimų tikrinimas;8) ryšio su kitomis užsakovo organizacijoje ar kitur esančiomis sistemomis tikrinimas;

testavimui reikalinga papildoma PĮ

9) speciali testavimo PĮ (ypatingų situacijų imitatoriai, analizės rezultatų skaičiuoklės, kt.);

bendrieji PĮ priėmimo kriterijai

10) PĮ neatitikimų reikalavimams priėmimo metu leistinas lygis (pvz., visų kritinių ir 80 % likusių testų išlaikymas);


96

kas daroma, jei testas neišlaikomas?11) pakartotino testavimo vaidmuo;

testų sąrašas, kiekvienam testui nurodoma12) testo identifikatorius (pvz., 1A);13) testo paskirtis (trumpas jo apibūdinimas);14) kokie duomenys turi būti registruojami testo metu;15) testo išlaikymo/neišlaikymo kriterijus;

testų ir PĮ reikalavimų ryšys (atsekamumas) 16) kiekvienam testui nurodoma, koks PĮ reikalavimas juo tikrinamas;17) kiekvienam PĮ reikalavimui nurodoma, kokiais testais jis tikrinamas.


97

10. Kas nurodoma testavimo procedūrose1) išankstiniai veiksmai testui paleisti (pvz., įjungti tam tikrus

įrenginius, įdiegti tam tikras PĮ dalis);2) procedūros, kaip žingsnis po žingsnio turi būti atliekamas testas;3) duomenų trumpinimo ir analizės procedūros (aiškios lygtys,

statistikos formulės, apvalinimo būdai, kt.);4) testams leisti ir rezultatams analizuoti reikiami kompiuteriai;5) testui leisti reikalingi išoriniai įrengimai (pvz., jutikliai, indikatoriai); 6) kitos sistemos, su kuriomis reikia palaikyti ryšį.


98

11. Kas nurodoma testavimo variantuose1) įvesties duomenys;2) įvesties duomenų šaltinis (rankinis įvedimas; išoriniai įrenginiai, jutikliai); 3) testo trukmė (pvz., kaupti kažkokio indikatoriaus duomenis vieną

valandą);4) laukiami išvesties duomenys; 5) testo išlaikymo/neišlaikymo kriterijus;6) testų variantų ir testų ryšiai (galimybei atsekti), kad žinotume, ar variantas taikytinas visiems testams.


99

12. Kas turėtų būti testavimo įrašuose1) testo pavadinimas ir identifikatorius;2) testavimo pradžios data ir laikas;3) testavimo pabaigos data ir laikas (tik tiems testams, kurie trunka

ilgesnį laiką); 4) kas leido testą;5) bet kokie testavimo procedūrų nukrypimai (pvz., netyčia praleistas kažkoks žingsnis; testavimo procedūroje aptikta ir ištaisyta klaida); 6) gauti testavimo duomenys.


100

13. Kas rašoma testavimo ataskaitoje1) bendroji informacija (pvz., kada buvo testuojama);2) bendroji išvada, ar sistema išlaikė testus, ir tolesni veiksmai;

kiekvienam testui 3) testo identifikatorius, procedūra ir testo variantas; 4) bet kokie testavimo procedūros nukrypimai; 5) gauti testavimo duomenys; 6) apskaičiuoti duomenys; 7) testas išlaikytas ar neišlaikytas (vertinant pagal dokumentuotus

kriterijus).


101

PĮ naudojimui ir priežiūrai turi būti rengiamasi dar PĮ kūrimo metu, nes vėliau pasirengti tam būna sunkiau ir brangiau.

1. PĮ naudojimo ir priežiūros klausimai, kuriuos reikėtų spręsti planuojant PĮ įsigijimo projektą1) kaip integruoti PĮ į organizacijos darbinę aplinką; 2) kaip naudoti PĮ efektyviai; 3) PĮ naudosiančių darbuotojų komplektavimas; 4) darbuotojų mokymas dirbti su PĮ ir prižiūrėti ją;5) operatyvios (on-line arba telefonu) pagalbos PĮ naudojimo

klausimais organizavimas;

XVI. Darbuotojų mokymas, PĮ naudojimas ir priežiūra (1)

102

6) atsakinėjimas į PĮ naudotojų klausimus; 7) PĮ sudėtyje panaudotų gatavų komponentų (COTS)

palaikymas, pristačius PĮ; 8) PĮ priežiūra; 9) rūpinimasis PĮ priežiūros priemonėmis (instrumentais);10) kilnojimų (migration) planavimas, atnaujinant PĮ.

PĮ įsigijimo plane kiekvienam auksčiau išvardintam punktui turi būti atsakymas, kas tą darys.


103

2. Mokymas (jis gali būti įvairių tipų) 1) darbuotojų mokymas naudoti PĮ; 2) su PĮ priežiūra ir administravimu susijęs mokymas.Kas ves mokymus?Kokios užsakovo teisės į mokomąją medžiagą?

3. Gatavų komponentų (COTS) palaikymas Gatavą PĮ paprastai prižiūri tiekėjas. Jis išduoda tik naudojimo licencijas. Išėjus naujai gatavos PĮ versijai, kyla klausimas, ar atnaujinti įsigytą PĮ, kurioje kaip komponentas yra ta gatava PĮ.


104

Argumentai už visos įsigytos PĮ atnaujinimą:

1) įgyjamas naujas PĮ funkcionalumas; 2) pašalinamos klaidos;3) neatnaujindami savo PĮ, neturėsime atnaujinto komponento

teikiamų galimybių ir tiekėjo paslaugų.

Argumentai prieš visos įsigytos PĮ atnaujinimą:

1) gatavos PĮ naujų versijų galimas nepageidaujamas poveikis

visai jūsų sistemai (pvz., gali reikėti naujos aparatinės įrangos); 2) naujoji gatavos PĮ versija gali būti nesuderinama su senąja. Gatavos PĮ patobulinimas gali sugriauti visą likusią jūsų sistemą;


105

3) poreikis apmokyti vartotojus dirbti su naujos versijos PĮ, atsiradus naudotojo sąsajos pokyčiams;4) tobulinimų išlaidos.

Tinkamai ir laiku pasirūpinkime gatavos PĮ licencijomis, kuriose turėtų būti atspindėti šie klausimai:

1) ar numatyti gatavos PĮ atnaujinimai? Jei taip, tai kiek kartų per metus?

2) ar teikiamos konsultacijos telefonu? Jei taip, tai kiek valandų per dieną, kiek dienų per metus? 3) per kiek laiko gatavos PĮ tiekėjas turi atsakyti į jūsų klausimus?


106

4. PĮ priežiūra1) kas yra PĮ priežiūra? Tai PĮ naudojimo metu rastų klaidų taisymas, PĮ darbo našumo arba funkcionalumo didinimas, PĮ tinkamumo keičiantis aplinkai palaikymas, PĮ darbingumo palaikymas.

PĮ priežiūra apima tokius klausimus, kaip: - metodai klaidoms (trūkumams) nustatyti;

- pasiūlymų diegti naujas funkcijas arba plėsti senąsias teikimas; - keitimų prioritetų nustatymas, taisymų ir tobulinimų grafiko sudarymas bei jų įgyvendinimo stebėjimas; - keitimų tikrinimas, ar po jų PĮ veikia gerai ir ar jie neiššaukė kitų

kliūčių; - PĮ konfigūracijos valdymo procedūrų vykdymas: PĮ keitimų, problemų, pakeistų programos kodų ir dokumentų registravimas, testų vykdymas;


107

2) kas turėtų prižiūrėti PĮ? Svarbu numatyti, kas rūpinsis: - PĮ naudojimo sferos plėtra; - PĮ našumo didinimu; - PĮ papildymu naujomis funkcijomis ir vartotojų mokymu naudoti jas; - klaidų ieškojimu ir informavimu apie jas; - klaidų taisymu; - PĮ dokumentų keitimu.


108

PĮ prižiūrėti gali:- užsakovo personalas;- PĮ tiekėjas (labiausiai patrauklus variantas, nes jis geriausiai žino vidinę PĮ struktūrą, turi kvalifikuotus specialistus ir priežiūrai būtiną įrangą);- samdomas trečiasis paslaugų tiekėjas (sandoris pasirašomas dar iki PĮ naudojimo pradžios).

Užsakovui imantis prižiūrėti PĮ, jam reikia: - turėti kvalifikuotą personalą;- supažindinti personalą su PĮ vidine struktūra, priežiūros aplinka ir instrumentais;


109

- imtis dokumentų tvarkymo ir PĮ konfigūracijos valdymo darbų;- sukurti ir įdiegti priežiūrai reikalingą aplinką; - turėti prieigą prie: • PĮ pradinių tekstų (source code) kompiliavimui tinkamuose kompiuterių failuose; • duomenų bazių dokumentų, duomenų struktūrų, sąsajų protokolų; • programų rašymo (pvz., kompiliatorių), PĮ konfigūracijos valdymo, testavimo, kitų priemonių.


110

3) priežiūros priemonės (instrumentai). PĮ priežiūrai naudojama aparatinė ir programinė įranga,

įskaitant testavimui ir rezultatų analizei naudojamą specialią įrangą. Šios priemonės paprastai skiriasi nuo PĮ kūrimo priemonių.

PĮ priežiūros priemonės turi būti nurodytos sandoryje su tiekėju ir sukurtos jo metu. Priežiūros priemonių laikymo vieta, joms funkcionuoti

reikalingos bendrosios sąlygos (patalpos, kondicionieriai, elektros tiekimas, darbų grafikas, biudžetas, personalas).


111

4) PĮ prižiūrinčių darbuotojų pareigos:

- vadovavimas tiesioginių PĮ naudotojų pamainai; - PĮ administravimas, kad ji veiktų normaliai;

- PĮ veikimo ataskaitų rengimas ir peržiūra; - naujos aparatinės įrangos instaliavimas; - PĮ klaidų (bugs) taisymas; - PĮ tobulinimas (upgrade); - aparatinės įrangos gedimų diagnozavimas ir taisymas; - darbuotojų mokymas diegiant sistemą ir keičiantis darbuotojams.


112

5) PĮ priežiūros biudžetas: - mokymo kaina; - priežiūros priemonių sukūrimo kaina; - priežiūros kaina (PĮ kūrimo kaina sudaro tik apie 30%

visos PĮ gyvavimo ciklo kainos, o PĮ priežiūra - 70%). Priežiūros kainos įvertinimo būdai:

• imant 20-50% PĮ kūrėjų kiekio išlaikymo išlaidų; • vadovaujantis 30-70% taisykle ir laikant priežiūros periodą

lygų 10 metų; • apskaičiuojant priežiūros kainą įvertinamas pakeisto PĮ

kodo (pradinio teksto) dydis.


113

PĮ įsigijimo projektų užsakovams svarbu suprasti tiekėjo atliekamus darbus, mokėti stebėti ir koreguoti projekto eigą.

1. PĮ įsigijimo projekto valdymo priemonės 1) PĮ projekto peržiūros.

Jų metu problemos keliamos bet nesprendžiamos. Būna: - formalios peržiūros. Jos numatomos darbų grafike. Jų metu

tikrinama, ar įsigijimo projekte laikomasi sutartų metrikų, ar daroma tai, kas sutarta;

- neformalios peržiūros. Tai periodiški techniniai pasitarimai;

XVII. PĮ įsigijimo projekto valdymas (1)

114

2) dokumentų peržiūros: - formali peržiūra. Ji atliekama įsigijimo projekto etapų pabaigoje.

Tai, pvz., reikalavimų, PĮ projekto (design) peržiūra, kt.; - neformali peržiūra. Tai tiekėjo atliekama darbo metu gimstančių

vidinių dokumentų peržiūra. Planuojant dokumentų peržiūras rekomenduojama: • prieš peržiūrą išplatinti dokumentus visiems dalyviams; • formali dokumento peržiūra neturėtų būti pirmoji galimybė užsakovui pamatyti produktą. Neformalios peržiūros turėtų

vykti nuolatos; • neatidėkime dokumentų peržiūros į įsigijimo projekto pabaigą, nes nebebus galimybės ištaisyti klaidų.


115

3) metrikų stebėjimas. Metrika – tai kiekybiškai išmatuojamas dydis. Dvi visuose sandoriuose naudojamos metrikos:

- išlaidos. Tai įprasta tiekėjų finansinių ataskaitų dalis;- darbų grafikas. Jo pavidalas gali varijuoti nuo projekto

kontrolės taškų sąrašo iki sudėtingų schemų.

Apie PĮ įsigijimo projektų specifines metrikas – kitose skaidrėse.



PĮ įsigijimo projektų specifinės metrikos:

Nr.Metrikos

pavadinimas Paaiškinimai

1. PĮ kūrimo eiga Sukurtų ir planuotų sukurti PĮ vienetų ar komponentų kiekiai duotu metu.

2. Testavimo eiga Leistų testų kiekis ir visas testų kiekis, kuris turi būti leidžiamas darbų grafike numatytu laiku.

3. Personalas Tikrasis ir planuotas PĮ kūrėjų kiekis duotu laiku.

4. PĮ dydis Sukurtos ir planuotos PĮ dydis duotu laiku.PĮ dydis – programos eilučių, funkcijų, moduliųar objektų kiekis.


Nr.Metrikos

pavadinimas Paaiškinimai

5. Kompiuterio resursų panaudojimas

Centrinio procesoriaus, atminties įrenginių, įvesties/išvesties resursų panaudojimo procentas, lyginant su planuotais maksimaliais poreikiais.

6. Iškilusios ir išspręstos problemos

Iškilusių ir išspręstų problemų kiekiai duotu laiku.

7. PĮ reikalavimų pastovumas

PĮ reikalavimų keitimų kiekis ir bendras reikalavimų kiekis duotu laiku.

118

Metrikų tikėtinų ir tikrųjų reikšmių žymėjimas laiko bėgyje yra naudingas dalykas, ir tai yra kaip valdymo įrankis.


Problemų būsenos(iškilusi/išspręsta)

Problemos

Laikas

40

30

20

10

Projektavimas Kūrimas Testavimas

PĮ kūrimo eiga

iškilusios

išspręstos

119

2. Pagrindinio tiekėjo subrangovų veiklų kontrolė Pagrindinis tiekėjas turi žinoti visus galimus projekto vykdymo subrangovus. Jo sandoriai su subrangovais turi būti sudaromi iš anksto ir būti projekto plano dalis. Visa tai turi būti atitinkamai atspindėta užsakovo prašyme teikti pasiūlymus (RFP) ir užsakovo sandoryje su pagrindiniu tiekėju.

3. Korekcinių veiksmų stebėjimas Iškilusios problemos, kurios turi būti išspręstos, skirstomos į: 1) aukščiausio sunkumo. Jos gali sukelti avarijas; 2) sunkias. Mažina PĮ funkcionalumą; 3) nesunkias. PĮ veikia ne taip, pvz., lėčiau, nei planuota; 4) lengvas. Tai dokumentų klaidos, smulkios problemos.


120

4. Kaip tvarkytis su nukrypimais nuo darbų grafiko1) planuoti trūkstamo laiko kompensavimą vėliau;2) pailginti viso projekto trukmę trūkstamu laiku;3) trūkstamą laiką naudoti kaip atitinkamą daugiklį likusio darbų grafiko laikui pakoreguoti;

4) mažinti kai kuriuos PĮ reikalavimus, kad būtų lengviau juos įgyvendinti; 5) mažinti planuotą PĮ funkcionalumą.

3, 4 ir 5 galimybės suteikia įsigijimo projektui lankstumo.


121

5. PĮ reikalavimų valdymas (peržiūra, keitimas)

Šiuos klausimus jau nagrinėjome 9.2 skyriuje.

6. Valdymo žingsniai PĮ kokybei pasiekti Prisiminkime: PĮ kokybės rodikliai yra patikimumas, veiksnumas, priežiūros patogumas, naudojimo patogumas, plėtros galimybė.

Kokybės valdymas susijęs su: 1) PĮ, kaip produkto, kokybe; 2) PĮ kūrimo proceso kokybe.


122

Kaip siekiama PĮ kokybės?Užsakovų naudotini metodai PĮ kokybei pasiekti: 1) kokybės reikalavimų išdėstymas PĮ reikalavimuose; 2) įsitikinimas, kad tiekėjo organizacijoje yra įdiegta kokybės valdymo

sistema; 3) įsigyjamos PĮ vertinimas, kurį atlieka nuo tiekėjo nepriklausoma ir

bendrais interesais nesusaistyta organizacija.

7. Užsakovo darbuotojų, nedalyvaujančių PĮ įsigijimo projekte, lūkesčių valdymas


123

1. Kas yra konfigūracijos valdymas? Tai PĮ keitimų valdymas. Projekto etapo planuotasis stovis (baseline) arba kitaip - PĮ pradinis stovis nustatytu laiko momentu, yra būsimų darbų kontrolės pagrindas. Pradinis stovis atspindi tai, ką turime ir ką žinome apie PĮ duotu laiko momentu. (baseline, milestone, checkpoint) Pradinis stovis rodo, kad PĮ elementai (PĮ reikalavimai - PĮ projektas – PĮ įgyvendinimas - t.t.), yra suderinti vienas su kitu. Pradinio stovio bet kurio elemento pakeitimai turi būti atspindėti ir visuose kituose to pradinio stovio elementuose, kad išliktų elementų suderinamumas. Tai yra PĮ konfigūracijos valdymo esmė. Pakeitimai fiksuojami tvirtinamuose dokumentuose ir daromi užsakovo ir tiekėjo sutarimu.

XVIII. PĮ konfigūracijos valdymas (1)

124

2. Kas atsitinka, jei PĮ konfigūracija nėra valdoma?1) negalima rasti programos pradinio teksto paskutinės versijos;2) ankstesnėje PĮ versijoje ištaisytos klaidos pasirodo vėl;3) tiekėjo atstovai nežino, iš kurių modulių sudaryta PĮ buvo pateikta užsakovui;4) programuotojai dirba su sena programos kodo versija;5) testuojama sena programos kodo versija;6) sunku atsekti ryšį arba jo iš viso nebėra tarp reikalavimų, dokumentų ir programos kodo.


125

3. PĮ konfigūracijos valdymo žingsniai1) PĮ konfigūracijos valdymo plano rengimas ir tvirtinimas;2) konfigūracijos valdymui perduodamų PĮ komponentų įvardinimas;3) komponentų sunumeravimas ar kitoks pažymėjimas; 4) pradinio stovio, apimančio visų komponentų visus elementus,

pokyčių priežiūra; 5) buvusio pradinio stovio kopijos priežiūra. Turi išlikti galimybė

patikimai atstatyti buvusį PĮ pradinį stovį;6) patvirtinimų gavimas prieš darant pradinio stovio keitimus.

Laikykimės darbų plano ir registruokime pakeitimus dokumente (keitimų kontrolė);

7) tikrinimas, ar PĮ reikalavimai, PĮ projektas, programos kodas, testavimo variantai, kt. atitinka vienas kitą pagal jų seką, ypač kai ateina PĮ diegimo laikas (konfigūracijos auditas).


126

4. Atsakomybė už PĮ konfigūracijos valdymąUž PĮ konfigūracijos valdymą visų pirma yra atsakingas kūrėjas (tiekėjas). Tačiau užsakovas privalo:1) reikalauti iš PĮ kūrėjo, kad jis vykdytų konfigūracijos valdymo

procesą ir aprašytų šį procesą konfigūracijos valdymo plane;2) peržiūrėti ir patvirtinti konfigūracijos valdymo planą;3) tikrinti, ar konfigūracijos valdymo planas yra vykdomas;4) spręsti, kokių PĮ kūrimo etapų pradiniai stoviai turi būti nustatyti ir kaip jie turi būti valdomi. Gali būti sudaryta, pvz., Konfigūracijos kontrolės

komisija konfigūracijos valdymo procesui prižiūrėti;5) kontroliuoti sąveiką tarp produktų, gaunamų iš skirtingų tiekėjų.


127


Klausimai, padedantys užsakovui nustatyti, ar tiekėjo PĮ konfigūracijos valdymas yra adekvatus įsigyjamai PĮ.

Nr. Klausimas

1. Ar parengtas projekto konfigūracijos valdymo planas?

2. Ar išvardinti PĮ komponentai, kurie turi būti perduoti konfigūracijos valdymui?

3. Ar konfigūracijos valdymo procesas yra įtrauktas į įsigijimo projekto planą ir ar jis yra natūrali šio plano dalis?

4. Ar visos konfigūracijos valdymo objektų versijos yra valdomos?

5. Ar sukurta biblioteka PĮ pradiniams stoviams saugoti ir atstatyti?

128


Nr. Klausimas

6. Ar PĮ stovio apskaitai ir konfigūracijos pasikeitimų eigai stebėti naudojami konfigūracijos valdymo instrumentai?

7. Ar visi gauti pasiūlymai ir iškeltos problemos PĮ konfigūracijai keisti yra registruojami, patvirtinami ir sekami dokumentais nustatyta tvarka?

8. Ar visi PĮ pradinių stovių keitimai kontroliuojami laikantis nustatytų procedūrų?

9. Ar visi PĮ pradiniai stoviai periodiškai peržiūrimi ir tikrinami, kad būtų įvertintas konfigūracijos valdymo proceso efektyvumas?

10. Ar visa konfigūracijos valdymo žinioje esanti informacija perduodama kitoms organizacijoms?

129

5. Nepersistenkime su konfigūracijos valdymu Perdėtas konfigūracijos valdymas nėra gerai. Jei per anksti versime tiekėją atlikti konfigūracijos valdymo procedūras, projekto eiga gali pasidaryti lėtesnė. Jei PĮ kūrėjai atlieka nedidelius testus, kad patikrintų, kaip pasisekė sukurti kažkokį modulį, arba bando duomenų bazės galimybes, nereikalaukime, kad tokia medžiaga būtų perduota konfigūracijos kontrolei. Kai dokumentai ir kiti PĮ produktai parengiami tinkamu lygiu ir jau gali būti pradinio stovio elementais, tik tada reikėtų vykdyti konfigūracijos valdymo procedūras.


130

Rizika - tai nepageidaujamas dalykas, kuris gali atsitikti, bet gali ir neatsitikti. Rizika gali būti įvertinta tokiais dydžiais, kaip PĮ kai kurių reikalavimų neįgyvendinimas, projekto kalendorinio darbų plano terminų nukėlimas, išlaidų padidėjimas. Rizikos valdymo tikslas – įvertinti pavojus anksčiau, kad jie nesukeltų problemų. PĮ įsigijimo projektuose rizikos poveikis projekto išlaidoms gali siekti net kelis šimtus procentų (pvz., statybų projektuose rizika, dėl kurios gali 50% išaugti išlaidos, laikoma labai didelė).

XIX. PĮ įsigijimo rizikos valdymas (1)

131

1. Rizikos valdymo būtinumas PĮ įsigijimo projektuose Tai ypač aktualu didelės PĮ įsigijimo projektuose, kuriant sistemas. Bet koks papildomai kuriamų ar modifikuojamų komponentų kiekio didinimas didina ir visos PĮ sukūrimo riziką. Rizika laikoma maža, jei PĮ sudaro ne daugiau kaip dešimt svarbiausių komponentų, kurių realizavimas nuolat stebimas. Efektyviausias rizikos sumažinimo būdas yra gatavos PĮ pirkimas.


132


2. Rizikos šaltinių sritys

Rizikos sritis

PĮ inžinerija PĮ kūrimo aplinka Projekto apribojimai

1. PĮ reikalavimai.2. PĮ projektas.3. PĮ kūrimas ir testavimas.4. PĮ integravimas ir testavimas.5. Technikos sritis.

1. Kūrimo procesas.2. Kūrimo sistema.3. Valdymo planas.4. Valdymas.5. Darbo aplinka.

1. Ištekliai.2. Sandoris.3. Projekto sąsajos.

133

3. Rizikos valdymo žingsniai


Rizikos veiksnių

įvardinimas

Rizikos analizė

Rizikos mažinimas

Rizikos stebėsena

134

1) rizikos veiksnių įvardinimas. Tai dalykų, kurie, jaučiama, gali rutuliotis ne taip, kaip norima, nustatymas. Rizika gali būti dalinama į atskiras kategorijas: techniškąją ir kalendorinio darbų plano;

2) rizikos analizė. Šiame žingsnyje įvardinti rizikos veiksniai charakterizuojami atsiradimo tikėtinumu ir poveikio dydžiu. Šie dydžiai dažniausiai atspindimi taip: aukštas, vidutinis arba žemas. Laikantis tokio vertinimo, sudaroma rizikos apibūdinimo lentelė.


135


Rizikos veiksnių apibūdinimo lentelė

Atsiradimo tikėtinumas

Aukštas Vidutinis Žemas

Poveikis

AukštasRizikos veiksnys Nr.1Rizikos veiksnys Nr.3

Rizikos veiksnys Nr.4 ---

VidutinisRizikos veiksnys Nr.8 Rizikos veiksnys Nr.2

Rizikos veiksnys Nr.5Rizikos veiksnys Nr.7

Žemas Rizikos veiksnys Nr.6 --- ---

136

3) rizikos mažinimas. Šio žingsnio metu nustatoma, kas turi būti daroma su kiekvienu

įvardintu rizikos veiksniu. Rizikos valdymo veiksmų kategorijos: - rizikos vengimas. Vienas iš būdų tam pasiekti yra riziką keliančių PĮ

reikalavimų mažinimas. Pvz., rizika, kad PĮ nebus priimta, jei ji neatitinka 99% reikalavimų, gali būti pašalinta, sumažinus reikalavimų atitikimą iki 95%;

- pagrindinės rizikos priežasties šalinimas. Pvz., gali būti pasitelkiami papildomi kompiuteriniai resursai, jei jų trūkumas kelia kalendorinio darbų plano pažeidimo riziką;

- rizikos valdymas. Tai kompromiso dėl kainos didinimo, kalendorinio darbų plano ilginimo ar PĮ galimybių mažinimo darymas rizikai mažinti;

- rizikos prisiėmimas. Prisiimama žemesnio prioriteto rizika.


137

4) rizikos stebėsena. Priimtiems sprendimams patikslinti periodiškai peržiūrima rizikos

veiksnių apibūdinimo lentelė. Ši peržiūra gali būti kaip įsigijimo projekto normalaus peržiūros proceso dalis. Rizikos veiksniai vertinami iš naujo, kad būtų nustatyta, ar pasikeitė jų atsiradimo tikėtinumas ir poveikio svarba. Ar atidėta rizika išnyko, o gal priešingai, jos prioritetas išaugo? Ar neatsirado nauji rizikos veiksniai, kuriuos reikėtų įtraukti į lentelę? Jei taip, grįžtama į rizikos veiksnių įvardinimo žingsnį.

4. Rizika turi būti valdoma viso projekto bėgyje

5. Rizikos valdymas – tai grupinė veikla


138


Programų sistemų priežiūra

139

PĮ įsigijimo rezultatas yra naudotojo poreikius atitinkanti PĮ. Tačiau laikui bėgant PĮ produktai turi būti keičiami, plėtojamos jų galimybės, nes gali būti aptinkami defektai, gali keistis darbo aplinka, atsirasti nauji naudotojo poreikiai.

PĮ gyvavimo cikle priežiūros procesas eina po PĮ įdiegimo garantinio periodo, nors kai kurios priežiūros veiklos pradedamos žymiai anksčiau.

Istoriškai PĮ priežiūrai nėra skiriama tiek dėmesio, kiek kitoms PĮ gyvavimo ciklo dalims. Tačiau organizacijos, siekdamos didesnės naudos iš įdėtų investicijų į PĮ kūrimą, stengiasi kiek įmanoma pratęsti PĮ naudojimo laiką ir todėl priežiūrai ima skirti daugiau dėmesio.

Įvadas (1)

140

PĮ priežiūra - tai veiklų visuma PĮ veiksmingumui palaikyti. Dalis šių veiklų organizacijose pradedamos iki PĮ pristatymo, o kita dalis

vykdoma po PĮ pristatymo.

Veiklos iki PĮ pristatymo: 1) operacijų po PĮ pristatymo planavimas; 2) priežiūros patogumo užtikrinimo planavimas; 3) įrangos pristatymo reikiamu laiku planavimas.

Veiklos po PĮ pristatymo:1) darbuotojų mokymas; 2) PĮ pakeitimų darymas;3) pagalbos priemonių (help desk) naudojimas.

Įvadas (2)

141

1. PĮ priežiūros klausimų grupės

Įvadas (3)

PĮ priežiūra

PĮ priežiūros pagrindai

Pagrindiniai PĮ priežiūros

klausimai

Priežiūros procesas

Priežiūros gerinimo

būdai

Apibrėžimai ir terminai

Priežiūros esmė

Priežiūros poreikis

Pagrindinės priežiūros išlaidos

PĮ plėtra

Priežiūros darbų

kategorijos

Techniniai klausimai

Valdymo klausimai

Priežiūros išlaidų

įvertinimas

PĮ priežiūros įvertinimas

Priežiūros procesai

Priežiūros veiklos

PĮ suprantamumo

gerinimas

Reinžinerija

Atvirkščioji inžinerija

142

2. Pagrindiniai šaltiniai PĮ priežiūros klausimais1) IEEE Std 1219-1998, IEEE Standard for Software Maintenance, 1998.

http://www.cs.uah.edu/~rcoleman/CS499/CourseTopics/IEEE_Std_1219-1998.pdf

2) Software Maintenance Capability Maturity Model (SM-CMM)

Model to Evaluate and Improve the Quality of Software Maintenance Process: Overview of the model http://s3.amazonaws.com/publicationslist.org/data/a.april/ref-233/812.pdf

3) Penny Grub, Armstrong A.Takang. Software maintenance. Concepts and practice, Second edition, World Scientific Publishing Co., 2005. VU MIF biblioteka. 4) V.Undzėnas. Programų sistemų įsigijimas ir priežiūra.

Mokymo medžiaga. 2007. http://www.mif.vu.lt/~valund

Įvadas (4)

143

1. Apibrėžimai ir sąvokosPĮ priežiūra yra apibrėžta IEEE 1219 standarte. Tai PĮ keitimas po

jos pristatymo pastebėtiems trūkumams pašalinti, jos veikimo ar kitų parametrų gerinimas, pritaikymas prie kintančios aplinkos. PĮ gyvavimo ciklo procesus aprašančiame standarte ISO12207 priežiūra yra vienas iš pagrindinių procesų, kurio metu PĮ keičiama bei atitinkamai taisomi jos dokumentai, šalinant pastebėtus trūkumus arba tobulinant PĮ. Tikslas - kiek galima ilgiau išsaugoti egzistuojančios PĮ tinkamą veiksnumą. ISO/IEC 14764 standarte PĮ priežiūra apibūdinama panašiai kaip ir ISO/IEC 12207 standarte, tik jame geriau išryškinamos priežiūros veiklos, kurios vykdomos dar iki PĮ pristatymo, pvz., planavimai.

I. PĮ priežiūros pagrindai (1)

144

2. PĮ priežiūros esmė PĮ priežiūra – tai PĮ darbingumo išlaikymas visą jos naudojimo laikotarpį. Siūlymai keisti PĮ yra registruojami ir sekami, nustatoma siūlomų pakeitimų įtaka, keičiamas programos kodas ir kiti su PĮ susiję produktai (pvz., dokumentai, atliekamas testavimas, išleidžiamos naujos PĮ versijos. Taip pat mokomi vartotojai, jiems teikiama pagalba). Priežiūra yra platesnė veiklos sritis nei kūrimas. PĮ prižiūrėti gali jos turėtojas, PĮ kūrėjas, samdoma firma. Pagrindinės PĮ priežiūros veiklos: 1) priežiūros proceso suorganizavimas; 2) klaidų ir keitimų analizė, keitimų darymas; 3) priežiūros stebėsena; 4) priežiūros perkėlimas (migracija) ir atsisakymas.


145

3. Priežiūros poreikis PĮ priežiūra reikalinga tam, kad PĮ kiek įmanoma ilgiau atitiktų naudotojo poreikius. PĮ priežiūros eigoje turi būti atliekami tokie darbai:

1) trūkumų (pastebėtų klaidų) šalinimas;2) PĮ projekto gerinimas;3) patobulinimų diegimas;4) sąsajų su kitomis sistemomis diegimas;5) PĮ pritaikymas darbui su įvairia kompiuterių aparatine ir programine bei telekomunikacijų įranga;

6) organizacijoje anksčiau turėtos PĮ perkėlimas ir naudojimas; 7) nereikalingos PĮ šalinimas.


146

Prižiūrėtojų veiklos skirstomos į tokias keturias grupes: 1) kasdienė PĮ priežiūra; 2) PĮ keitimų priežiūra; 3) esamų PĮ funkcijų tobulinimas; 4) naujų PĮ funkcijų diegimas.


147

4. PĮ priežiūros pagrindinės išlaidos Priežiūrai sunaudojama didžiuma (60-70 proc.) viso PĮ gyvavimo ciklo finansinių išteklių. Pastebėtų klaidų taisymas sudaro tik apie 20 proc. PĮ priežiūros darbų. PĮ priežiūros kainą įtakojantys veiksniai:

1) PĮ taikymo srities tipas;2) PĮ naujumas;3) personalo PĮ priežiūrai turėjimas;4) PĮ gyvavimo trukmė;5) aparatinės įrangos (hardware) charakteristikos;6) PĮ projekto, konstrukcijos, dokumentų, testavimo kokybė.


148

5. PĮ plėtra Priežiūra yra PĮ kūrimo proceso tęsinys, atsiradus naujiems poreikiams.

Didelė egzistuojanti PĮ niekada nebūna užbaigta, ji visą laiką plėtojama. Taip PĮ darosi vis sudėtingesnė, kol nesiimama jos supaprastinimo veiksmų.

Pastoviai naudojama PĮ turi tendenciją keistis, kas turi būti kažkaip išmatuojama. Priežiūros pastangoms įvertinti yra tam tikri metodai, instrumentai.


149

6. PĮ priežiūros darbų kategorijosISO/IEC 14764 standarte yra apibrėžtos keturios PĮ priežiūros darbų kategorijos: 1) klaidų taisymas, siekiant pašalinti pastebėtas klaidas; 2) pritaikymas (adaptavimas), siekiant išlaikyti PĮ tinkamumą

kintančioje aplinkoje; 3) tobulinimas, siekiant pagerinti PĮ darbo charakteristikas arba

priežiūros galimybes; 4) prevenciniai darbai, siekiant atskleisti nenumatytus atvejus ir atlikti

atitinkamas korekcijas.


150


ISO/IEC 14764 standarte pritaikymo (adaptavimo) ir tobulinimo darbai priklauso PĮ galimybių plėtros kategorijai. Klaidų taisymo ir prevenciniai darbai skiriami PĮ koregavimo kategorijai. Prevenciniai darbai yra naujausia priežiūros darbų kategorija, dažniausiai atliekami tokiai PĮ, kuriai svarbios yra saugumo problemos.

PĮ priežiūros darbų kategorijosKoregavimo

kategorijos darbai Galimybių plėtros kategorijos darbai

Inicijuojamieji Prevenciniai Tobulinimo

Reaguojantieji Klaidų taisymo Pritaikymo (adapt.)

151

1. Techniškieji priežiūros klausimai1) žinių apie PĮ ribotumas. Prižiūrėtojo žinios apie PĮ lemia, kaip greitai jis gali nustatyti, kurioje PĮ vietoje reikia daryti pakeitimus ar pataisymus. 40-60 proc. priežiūros pastangų sunaudojama tam, kol nustatoma, ką gi reikėtų keisti;2) testavimas, padarius PĮ pakeitimus. Būtina patikrinti, ar pakeitimai neduoda nepageidaujamų reiškinių;3) PĮ pakeitimų poveikio analizė. Analizuojant pageidavimus PĮ pakeitimams daryti, nustatoma, kokioms sistemoms ir produktams tai turės įtaką, ir įvertintos visos su keitimais susijusios išlaidos. Turi būti įvertinta ir pakeitimų rizika.

II. Pagrindiniai PĮ priežiūros klausimai (1)

152

PĮ pakeitimų poveikio analizės tikslai yra: - apibrėžti pakeitimų apimtį, kad galima būtų suplanuoti ir įvykdyti šiuos darbus; - numatyti keitimo darbams atlikti reikalingus resursus; - išanalizuoti pageidaujamų pakeitimų kainą ir naudą; - informuoti kitus apie pakeitimus. Problemos sunkumas: kaip ir kada turi būti iškeltas PĮ keitimo klausimas. Tik po to programuotojai gali nustatyti PĮ elementus, kuriuos reikėtų keisti;

4) PĮ priežiūros patogumas. Priežiūros patogumo charakteristikos turi būti apibrėžtos ir kontroliuojamos dar PĮ kūrimo metu.


153

2. Priežiūros valdymo klausimai 1) PĮ priežiūros darbų ir organizacijos veiklos tikslų derinimas. Organizacijos siekia, kad PĮ priežiūra atsipirktų, ir nori pratęsti PĮ gyvavimo laiką kiek galima ilgiau. Bet, laikui bėgant, PĮ gali būti keičiama ir tobulinama pagal naudotojo poreikius. Abiem šiais PĮ priežiūros atvejais investicijų atsipirkimas yra mažiau aiškus, todėl organizacijų vadovai, neįžvelgdami naudos, vengia skirti lėšas PĮ priežiūrai; 2) PĮ priežiūros personalas. Būtina sudaryti PĮ prižiūrėtojų grupę. Tačiau PĮ priežiūra dažnai nėra patrauklus darbas, todėl prižiūrėtojai jaučiasi kaip „antrarūšiai“ darbuotojai;


154

3) PĮ priežiūros procesas. PĮ priežiūros procesas yra veiklų, metodų,

taisyklių ir kt. rinkinys. PĮ priežiūros ir PĮ kūrimo procesai turi daug bendro (pvz., PĮ konfigūracijos valdymas, testavimas yra svarbios veiklos abiem atvejais). Tačiau PĮ priežiūra reikalauja keleto veiklų, kurių nesutiksime PĮ kūrimo procese. Apie jas ir jų sunkumus kalbėsime vėliau;

4) PĮ priežiūros organizaciniai aspektai. Šie aspektai atspindi, kas bus atsakingas už PĮ priežiūrą: pati įsigyjančioji organizacija, PĮ kūrėjas (jis gali ir nesiimti tokio darbo) ar samdoma trečioji organizacija. Šiuo klausimu sprendimas priimamas kiekvienu atveju atskirai.


155

5) PĮ prižiūrėtojų samdymas. Šiais laikais PĮ priežiūros paslaugų tiekėjų ratas plinta. Didelės organizacijos nuomoja netgi ištisas sistemas, įskaitant jų priežiūrą. Dažniausiai prižiūrėtojai samdomi mažiau reikšmingai PĮ, nes organizacijos nenori prarasti jiems svarbiausios PĮ kontrolės.

PĮ priežiūros paslaugų tiekėjams rimtos problemos yra priežiūros darbų apimties ir sandorio detalių nustatymas. Manoma, kad apie 50% tiekėjų pasirašo sandorius be aiškaus PĮ priežiūros paslaugų lygio apibrėžimo. Kitas sunkumas yra PĮ perdavimas priežiūros paslaugų tiekėjui.


156

3. Išlaidų PĮ priežiūrai įvertinimasRengiant PĮ priežiūros planus, įvertinant reikalingas išlaidas, būtina suprasti PĮ priežiūros darbų kategorijas. Nagrinėjant PĮ pakeitimų poveikį,įvardinama ir kita PĮ, kuriai įtakos turi daromi pakeitimai. Kartu įvertinamos ir išlaidos tiems keitimams atlikti. Pačiam išlaidų vertinimo procesui įtakos turi nemažai techniškųjų ir

kitokio pobūdžio veiksnių. ISO/IEC14764 standartas nustato du pagrindinius PĮ priežiūrai reikalingų resursų vertinimo būdus:

- paremtą parametriniais modeliais; - paremtą patirtimi.

Dažniausiai naudojama šių abiejų būdų kombinacija:


157

1) parametriniai išlaidų vertinimo modeliai. Juose priežiūros išlaidoms

įvertinti reikalingi anksčiau baigtų PĮ priežiūros projektų duomenys. Kai kuriuose moksliniuose darbuose nagrinėjami visi išlaidų vertinimo aspektai ir pateikiamas išsamus PĮ priežiūros išlaidų vertinimo aprašas;2) išlaidų vertinimas remiantis patirtimi. Patirtis išreiškiama kaip ekspertų nuomonė, analogai (panašumai), darbų organizacinė schema. Tai būdai papildomiems duomenims gauti iš parametrinių modelių. Geriausias PĮ priežiūros išlaidų įvertinimo būdas yra toks, kuomet remiamasi sukauptais empiriniais duomenimis ir patirtimi.


158

4. PĮ priežiūros sudėtingumo įvertinimasTai susiję su PĮ dydžiu, priežiūros pastangų dydžiu, darbų grafiku ir kokybe. Šie matai yra pradinis atramos taškas PĮ prižiūrėtojams. Procesų ir produktų matavimo klausimai plačiai nagrinėjami PĮ inžinerijos procesų ir PĮ inžinerijos valdymo disciplinose. Specifiniai priežiūros sudėtingumo vertinimo rodikliai: 1) analiziškumas. Su šia charakteristika yra susiję tokie rodikliai, kaip prižiūrėtojo pastangų dydis (darbuotojų kiekis, laikas) ir būtini resursai (patalpos, įranga, kt.), kurių reikia PĮ trūkumų ar darbo sutrikimų priežastims nustatyti, pakeitimų reikalaujančioms PĮ dalims įvardinti;


159

2) pakeitimų atlikimo sudėtingumas. Šis rodiklis atspindi prižiūrėtojo pastangų dydį, kurių reikia apsibrėžtiems PĮ pakeitimams atlikti; 3) stabilumas. Jis atspindi pastangų dydį nenumatytiems PĮ veikimo atvejams išsiaiškinti, įskaitant netikėtumus testavimo metu;4) testavimo galimybės. Tai prižiūrėtojo ir naudotojų pastangų dydis reikalingas modifikuotai PĮ patikrinti.


160

1. PĮ priežiūros procesas

PĮ priežiūros procesas apima reikiamas veiklas bei šių veiklų įeities/išeities duomenis. Tai yra aprašyta PĮ priežiūros standartuose IEEE1219 ir ISO14764-99.

IEEE 1219 standarte priežiūros pastangos pristatomos pradedant veiklomis, kurios vykdomos po PĮ įsigijimo (įdiegimo), bei aptariami priežiūros planavimo klausimai.

ISO/IEC14764-99 standarte PĮ priežiūros procesas yra labiau išplėtotas. Jame priežiūros procesai yra panašūs kaip ir IEEE12207-96 standarte, išskyrus tai, kad procesai yra agreguoti kitaip.

III. PĮ priežiūros procesas (1)

161

1) PĮ priežiūros proceso veiklos (IEEE1219-98):


1. Pakeitimų klasifikavimas ir

įvardinimas 2. Analizavimas 3. Projektavimas

4. Keičiamos PĮ kūrimas

5. Testavimas6. Testavimo

rezultatų priėmimas

Pageidavimas keisti

7. Pakeitimų diegimas

162

2. PĮ priežiūros veiklosDaug PĮ priežiūros veiklų yra panašios į PĮ kūrimo veiklas.

Prižiūrėtojai taip pat susiduria su analizės, projektavimo, programavimo (kodavimo), testavimo ir dokumentavimo darbais. Jie, kaip ir PĮ kūrėjai, savo veikloje turi laikytis PĮ reikalavimų, atnaujinti dokumentus padarius pakeitimą.

Tačiau yra ir unikalių PĮ priežiūros veiklų.

Unikalios PĮ priežiūros veiklos 1) PĮ perdavimas prižiūrėtojui. Tai kontroliuojamų ir koordinuotų veiklų seka, kurios metu kūrėjas palaipsniui perduoda PĮ prižiūrėtojui;


163

2) pageidavimo keisti PĮ priėmimas arba atmetimas. Prižiūrėtojas pageidavimą keisti PĮ tam tikru požiūriu gali atmesti ir

nukreipti PĮ kūrėjui;3) pageidavimo keisti PĮ ir iškilusių problemų perdavimas pagalbos tarnybai. Tai pagalbos tiesioginiams naudotojams funkcija, kuri savo ruožtu iššaukia pakeitimo įvertinimą, prioritetų ir kainos nustatymą; 4) pakeitimų poveikio analizė;5) PĮ palaikymas. Tai pagalbinės informacijos ir patarimų tiesioginiams naudotojams teikimas, pvz., darbo taisyklių, duomenų prasmės, apie specialias užklausas/pranešimus;


164

6) susitarimų dėl paslaugų lygio ir specializuotos priežiūros sandorių sudarymas. Už juos yra atsakingas prižiūrėtojas.

Pagalbinės PĮ priežiūros veiklos Tai PĮ priežiūros planavimas, konfigūracijos valdymas, tikrinimas ir tvirtinimas, PĮ kokybės užtikrinimas, peržiūra, auditas, naudotojų mokymas, taip pat ir prižiūrėtojų mokymas.


165

PĮ priežiūros planavimas1) įstaigos veiklos, įskaitant PĮ priežiūrą, planavimas (organizacinis lygmuo). Tai aukščiausias priežiūros planavimo lygmuo. Numatomi finansavimo klausimai, paskiriami priežiūrai reikalingi darbuotojai visuose įstaigos padaliniuose; 2) PĮ priežiūros planavimas (pereinamasis lygmuo).

Rengiamame PĮ priežiūros plane turi būti nurodoma:- priežiūros apimtis (scope);- priežiūros proceso adaptacija;- prižiūrinti organizacija;- priežiūros kainos įvertinimas;


166

3) PĮ naujos versijos išleidimo planavimas (PĮ lygmuo). Planuodamas leisti naują PĮ versiją, prižiūrėtojas turi:

- surinkti duomenis apie individualių pageidavimų naudą; - susitarti su naudotojais dėl būsimos PĮ versijos turinio; - įvardinti galimas konfliktines situacijas ir numatyti veiksmus jų atveju; - įvertinti naujos PĮ versijos riziką ir parengti problemų sprendimo

planą iškilus joms; - informuoti visus kitus naudotojus (akcininkus); 4) individualių pageidavimų keisti PĮ planavimas (pageidavimų lygmuo). Toks planavimas atliekamas PĮ pakeitimų poveikio analizės metu.


167

PĮ konfigūracijos valdymas

PĮ konfigūracijos valdymas yra kritinė PĮ priežiūros veikla, kuri turi būti atliekama kiekviename PĮ pakeitimų įvardinimo, analizės, kūrimo ar diegimo žingsnyje. Nepakanka vien registruoti pastebėtus trūkumus ar pageidavimus keisti PĮ.

Bet kokie PĮ pakeitimai turi būti kontroliuojami. Tokia kontrolė įvedama ir atliekama laikantis institucijos vadovybės patvirtinto PĮ konfigūracijos valdymo proceso.


168

PĮ kokybės užtikrinimas PĮ kokybė negerėja net esant tinkamai PĮ priežiūrai. Kokybės gerinimas turi būti planuojamas, ir tai turi būti atliekama PĮ priežiūros bėgyje. Pasirinktos PĮ kokybės užtikrinimo, vertinimo ir tvirtinimo, peržiūros ir audito veiklos ir būdai turi būti derinami su kitomis veiklomis, kad būtų pasiektas norimas PĮ kokybės lygis. Rekomenduojama prižiūrėtojams savo darbe pritaikyti PĮ kūrimo procesus, juose naudojamus būdus ir formuojamus rezultatus.


169

1. Programų suprantamumo gerinimasProgramuotojai sugaišta daug laiko nagrinėdami pradinius programų tekstus (kodus), kad galėtų atlikti norimus pakeitimus. Kodų naršyklės yra pagrindinės programų suprantamumą palengvinančios priemonės. Aiški ir trumpa dokumentacija taip pat prisideda prie programų suprantamumo.

IV. PĮ priežiūros gerinimo būdai (1)

170

2. ReinžinerijaReinžinerija - tai PĮ nagrinėjimas ir perdarymas, siekiant suteikti jai naują pavidalą ir įtraukti tolesnius sumanymus. Manoma, kad reinžinerija yra radikaliausias ir brangiausias PĮ perdarymo būdas. Dažnai tai nepalengvina PĮ priežiūros, bet prailgina jos amžių. Sprendžiant reinžinerijos klausimus susiduriama su PĮ bendrojo supratimo, tvarkymo instrumentų ir būdų, įvairių faktų, rizikos ir naudos nagrinėjimu.


171

3. Atvirkščioji inžinerija (reverse engineering).

Tai PĮ analizavimo būdas, kurio metu siekiama įvardinti PĮ komponentus, atskleisti jų sąveiką ir pavaizduoti juos aukštesniu abstrakcijos lygiu. Atvirkščioji inžinerija yra pasyvus procesas. Ji neatlieka jokių esamos PĮ keitimų. Atvirkščiosios inžinerijos pastangomis gaunamas PĮ kreipinių grafas (call graph) ir valdymo veiksmų (control graph) grafas iš pradinio programos teksto (source code). Vienas iš atvirkščiosios inžinerijos pavyzdžių yra dokumentacijos perdarymas. Kitas – PĮ projekto atstatymas, pvz., pametus projektą. Pertvarkymas (refactoring) yra tokia reorganizacija, kai PĮ veikimo būdas nekeičiamas, o tik siekiama pagerinti jos struktūrą. Dar vienas atvirkščiosios inžinerijos tipas yra toks, kai PĮ loginės schemos atstatomos iš fizinių duomenų bazių.


172

P a b a i g a


Documents

Vilniaus universitetas Matematikos ir informatikos fakultetas Programų sistemų katedra