Transcript Bandau - Matematikos ir Informatikos fakultetas

Vilniaus universitetas
Matematikos 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
1
VU MIF Programų sistemų katedra
Programų sistemų įsigijimas
2
Įvadas (1)
Užsiėmimų forma
a) 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.
3
Įvadas (2)
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 (3)
2. Mokomojo dalyko skyriai
1) 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;
5
Į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.
6
Įvadas (5)
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.
7
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
8
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ų.
9
I. PĮ ypatumai (3)
3. Įprastos kitokių projektų valdymo veiklos netinka PĮ
įsigijimo atveju
4. Prie PĮ įsigijimo projektų ypatumų galima prisitaikyti
10
II. PĮ įsigijimo platesnis kontekstas (1)
1. PĮ yra tik kažkokios sudėtingesnės sistemos dalis
Organizac.
poreikių
analizė
Siūlomi
sprendimo
keliai
Sistemos
samprata
Sistemos
įsigijimas
Naudojimas ir
priežiūra
Tolesnis
planavimas
11
II. PĮ įsigijimo platesnis kontekstas (2)
2. Sistemos įsigijimo proceso veiklos
Sistemos
samprata
Sistemos įsigijimas
Sistemos
reikalavimai
Sistemos
projektavim.
AĮ
įsigijimas
Sistem. dalių
integracija
Sistemos
priėmimas
PĮ
įsigijimas
Naudojimas ir
priežiūra
12
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.
13
III. Požiūriai į PĮ įsigijimo procesą (2)
2. Ką turėtų daryti užsakovas
1) 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.
14
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.
15
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.
16
V. PĮ įsigijimo nuostatos (2)
3. Žmogiškųjų santykių nuostatos
1) 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.
17
V. PĮ įsigijimo nuostatos (3)
4. Ko neturėtų daryti užsakovas
1) 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ėjas
1) nesistengti atlikti viską tiksliai;
2) siekti užsitikrinti darbo ateičiai nepriimtinu būdu;
3) tikėtis reikalavimų sušvelninimo.
18
VI. PĮ įsigijimo veiklos ir jų seka (1)
1. Dvi pagrindinės veiklos
1) 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.
19
VI. PĮ įsigijimo veiklos ir jų seka (2)
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.
20
VI. PĮ įsigijimo veiklos ir jų seka (3)
4. Keletas pastovių veiklų PĮ įsigijimo procese
1) įsigijimo grupės sudarymas;
2) plano rengimas;
3) kalendorinio darbų grafiko rengimas;
4) PĮ reikalavimų rengimas ir sandorio su tiekėju sudarymas.
21
VI. PĮ įsigijimo veiklos ir jų seka (4)
5. Apytikris PĮ įsigijimo veiklų grafikas
Išankstinė veikla
PĮ kūrimas
PĮ naudojimas ir priežiūra
Grupės
sudarymas
Plano
rengimas
Projekto samprata
Projekto
planas
Reikalavimų
rengimas
Aplinkos
apibrėžimas
Galutiniai
reikalavimai
Reikalavimų
peržiūra
Reikalavimų valdymas
Projekto darbų grafikas
PĮ priėmimas
Priėmimo testų ir priežiūros planavimas
Tikrinimas ir priėmimas
Mokymas
Priežiūra
Projekto valdymas
PĮ konfigūracijos valdymas
Rizikos valdymas
22
VI. PĮ įsigijimo veiklos ir jų seka (5)
6. Apytikris tiekėjo išrinkimo veiklų grafikas
Grupės PĮ
įsigijimui
sudarymas
Sprendimo
kurti naują ar
pirkti gatavą PĮ
priėmimas
Sandorio
tipo
pasirinkimas
PĮ reikalavimų
peržiūra
Prašymo teikti
pasiūlymus (RFP)
rengimas
Tiekėjo
išrinkimas
Sandorio
sudarymas
Intelektinės
nuosavybės
teisių klausimų
sprendimas
VI. PĮ įsigijimo veiklos ir jų seka (6)
7. PĮ reikalavimų išsamumas ir rengimo laikas
PĮ reikalavimų metmenys
pirkti
Kurti ar
pirkti?
PĮ savybių sąrašo
sudarymas
Produkto
išrinkimas
kurti
Sandorio tipo
pasirinkimas
Tiekėjo
išrinkimas
Išsamių reikalavimų
rengimas
Užsakymo vykdymas
24
VII. Grupės PĮ įsigyti sudarymas (1)
Grupė – tai nedidelis kiekis įvairių sugebėjimų žmonių, dirbančių,
siekiančių ir atsakingų už bendrą tikslą.
1. Kas turėtų būti grupėje
1) 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.
25
VII. Grupės PĮ įsigyti sudarymas (2)
2. Kur ieškoti žmonių sudarant darbo grupę?
3. Paskiausiai į grupę įtraukiamas narys – tiekėjas
26
VIII. Įsigijimo projekto planavimas (1)
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 plane
1) į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;
27
VIII. Įsigijimo projekto planavimas (2)
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);
28
VIII. Įsigijimo projekto planavimas (3)
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).
29
IX. Įsigyjamos PĮ reikalavimai (1)
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);
30
IX. Įsigyjamos PĮ reikalavimai (2)
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);
31
IX. Įsigyjamos PĮ reikalavimai (3)
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;
32
IX. Įsigyjamos PĮ reikalavimai (4)
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.);
33
IX. Įsigyjamos PĮ reikalavimai (5)
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ų;
34
IX. Įsigyjamos PĮ reikalavimai (6)
į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;
35
IX. Įsigyjamos PĮ reikalavimai (7)
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.
36
IX. Įsigyjamos PĮ reikalavimai (8)
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;
37
IX. Įsigyjamos PĮ reikalavimai (9)
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.
38
IX. Įsigyjamos PĮ reikalavimai (10)
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ų);
39
IX. Įsigyjamos PĮ reikalavimai (11)
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ą;
40
IX. Įsigyjamos PĮ reikalavimai (12)
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į;
41
IX. Įsigyjamos PĮ reikalavimai (13)
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į.
42
IX. Įsigyjamos PĮ reikalavimai (14)
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.
43
X. Kurti naują ar pirkti gatavą PĮ? (1)
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.
44
X. Kurti naują ar pirkti gatavą PĮ? (2)
2. Sprendimo kurti naują ar pirkti gatavą PĮ priėmimo veiksniai
1) 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.
45
X. Kurti naują ar pirkti gatavą PĮ? (3)
3. Gatavos PĮ pirkimo rizika, rizikos priežastys ir kaip ją
sumažinti
Rizikos priežastis
Kaip sumažinti riziką
Gatava PĮ negali idealiai
1. 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.
PĮ neatitikimas pardavėjo
2. tvirtinimams; tikrovės ir
reklamos neatitikimas.
Reikalaukime akivaizdaus PĮ veikimo
pademonstravimo arba padirbėkime su
demonstracine arba skolinta PĮ versija.
46
X. Kurti naują ar pirkti gatavą PĮ? (4)
Rizikos priežastis
Kaip sumažinti riziką
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Į.
47
X. Kurti naują ar pirkti gatavą PĮ? (5)
Rizikos priežastis
Kaip sumažinti riziką
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.
48
X. Kurti naują ar pirkti gatavą PĮ? (6)
Rizikos priežastis
Kaip sumažinti riziką
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.
49
X. Kurti naują ar pirkti gatavą PĮ? (7)
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;
50
X. Kurti naują ar pirkti gatavą PĮ? (8)
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;
51
X. Kurti naują ar pirkti gatavą PĮ? (9)
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;
52
X. Kurti naują ar pirkti gatavą PĮ? (10)
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.
53
XI. Įsigijimo sandorių sudarymas (1)
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.
54
XI. Įsigijimo sandorių sudarymas (2)
2. Kokio tipo sandorį reikėtų rinktis?
Sandorio tipas
1) fiksuotos kainos
sandoris;
Pastabos
- 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.
55
XI. Įsigijimo sandorių sudarymas (3)
Sandorio tipas
2) išlaidas
padengiantysis
sandoris;
Pastabos
- 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.
56
XI. Įsigijimo sandorių sudarymas (4)
Sandorio tipas
3) laiko ir medžiagų
apmokėjimo
sandoris.
Pastabos
- 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.
XI. Įsigijimo sandorių sudarymas (5)
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.
58
XI. Įsigijimo sandorių sudarymas (6)
4. Įvairaus pobūdžio sandorių pliusai ir minusai
1) darbų prižiūrėtojo/tiekėjo sandoris (engineer/contractor)
Pliusai
- 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.
Minusai
- 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.
59
XI. Įsigijimo sandorių sudarymas (7)
2) sistemų vadovo sandoris (system manager)
Pliusai
- 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.
Minusai
- 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ą.
60
XI. Įsigijimo sandorių sudarymas (8)
3) projektavimo/kūrimo sandoris (design/build)
Pliusai
- 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.
Minusai
- 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.
61
XI. Įsigijimo sandorių sudarymas (9)
4) projektavimo atsižvelgiant į turimas lėšas ir laiko terminus sandoris
(design to cost and shedule)
Pliusai
- mažiau kaitaliojami reikalavimai;
- mažesnė kainos viršijimo ir
nukrypimo nuo laiko grafiko rizika.
Minusai
- tiekėjas gali nesistengti pateikti
alternatyvių projektų;
- per daug optimistiški pasiūlymai
gali būti išrinkti laimėjusiais.
62
XI. Įsigijimo sandorių sudarymas (10)
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ų.
63
XI. Įsigijimo sandorių sudarymas (11)
5. Kokio pobūdžio sandorį reikėtų rinktis?
Sandorio pobūdis:
1) darbų prižiūrėtojo/
tiekėjo sandoris;
Pastabos
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.
64
XI. Įsigijimo sandorių sudarymas (12)
Sandorio pobūdis:
2) sistemų vadovo
sandoris;
Pastabos:
- 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.
65
XI. Įsigijimo sandorių sudarymas (13)
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čų.
66
XII. PĮ naudojimo aplinkos apibrėžimas (1)
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.
67
XII. PĮ naudojimo aplinkos apibrėžimas (2)
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ų.
68
XII. PĮ naudojimo aplinkos apibrėžimas (3)
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.;
69
XII. PĮ naudojimo aplinkos apibrėžimas (4)
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.
70
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (1)
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.
71
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (2)
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Į.
72
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (3)
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?
73
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (4)
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?
74
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (5)
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;
75
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (6)
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ų?
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (7)
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);
77
XIII. Autorinių ir nuosavybės teisių
klausimo sprendimas (8)
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?
78
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (1)
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);
79
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (2)
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;
80
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (3)
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);
81
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (4)
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).
82
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (5)
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).
83
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (6)
4. Darbų grafiko suspaudimo poveikis projekto kainai
PĮ įsigijimo
projekto
bendra kaina
Neįmanoma
zona
Laikas
84
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (7)
5. Darbų grafiko trukmės nustatymas
1) 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.
85
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (8)
6. Rekomendacijos PĮ dydžiui įvertinti
1) 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.
86
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (9)
7. PĮ dydžio įvertinimų paklaidos
(projekto pradžioje padarytas įvertinimas toli gražu neatitinka tikrovės)
Projekto
dydžio
paklaida
Laikas
Projekto
samprata
Reikalavimai
Projektavimas
Programavimas
Testavimas
87
XIV. PĮ įsigijimo projekto darbų grafiko sudarymas (10)
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.
88
XV. Įsigyjamos PĮ testavimas (1)
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.
89
XV. Įsigyjamos PĮ testavimas (2)
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.
90
XV. Įsigyjamos PĮ testavimas (3)
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.);
91
XV. Įsigyjamos PĮ testavimas (4)
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
92
XV. Įsigyjamos PĮ testavimas (5)
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).
93
XV. Įsigyjamos PĮ testavimas (6)
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?
94
XV. Įsigyjamos PĮ testavimas (7)
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);
XV. Įsigyjamos PĮ testavimas (8)
kas daroma, jei testas neišlaikomas?
11) pakartotino testavimo vaidmuo;
testų sąrašas, kiekvienam testui nurodoma
12) 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.
96
XV. Įsigyjamos PĮ testavimas (9)
10. Kas nurodoma testavimo procedūrose
1) 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šį.
97
XV. Įsigyjamos PĮ testavimas (10)
11. Kas nurodoma testavimo variantuose
1) į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.
98
XV. Įsigyjamos PĮ testavimas (11)
12. Kas turėtų būti testavimo įrašuose
1) 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.
99
XV. Įsigyjamos PĮ testavimas (12)
13. Kas rašoma testavimo ataskaitoje
1) 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).
100
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (1)
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;
101
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (2)
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.
102
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (3)
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Į.
103
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (4)
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ą;
104
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (5)
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?
105
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (6)
4. PĮ priežiūra
1) 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;
106
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (7)
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.
107
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (8)
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;
108
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (9)
- 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ų.
109
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (10)
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).
110
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (11)
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.
111
XVI. Darbuotojų mokymas, PĮ naudojimas
ir priežiūra (12)
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.
112
XVII. PĮ įsigijimo projekto valdymas (1)
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;
113
XVII. PĮ įsigijimo projekto valdymas (2)
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ų.
114
XVII. PĮ įsigijimo projekto valdymas (3)
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.
115
XVII. PĮ įsigijimo projekto valdymas (4)
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.
XVII. PĮ įsigijimo projekto valdymas (5)
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 Iškilusių ir išspręstų problemų kiekiai duotu laiku.
problemos
7.
PĮ reikalavimų
pastovumas
PĮ reikalavimų keitimų kiekis ir bendras reikalavimų
kiekis duotu laiku.
XVII. PĮ įsigijimo projekto valdymas (6)
Metrikų tikėtinų ir tikrųjų reikšmių žymėjimas laiko bėgyje yra naudingas
dalykas, ir tai yra kaip valdymo įrankis.
Problemos
Problemų būsenos
(iškilusi/išspręsta)
40
iškilusios
30
20
išspręstos
10
Laikas
Projektavimas
Kūrimas
PĮ kūrimo eiga
Testavimas
118
XVII. PĮ įsigijimo projekto valdymas (7)
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.
119
XVII. PĮ įsigijimo projekto valdymas (8)
4. Kaip tvarkytis su nukrypimais nuo darbų grafiko
1) 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.
120
XVII. PĮ įsigijimo projekto valdymas (9)
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.
121
XVII. PĮ įsigijimo projekto valdymas (10)
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
122
XVIII. PĮ konfigūracijos valdymas (1)
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.
123
XVIII. PĮ konfigūracijos valdymas (2)
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.
124
XVIII. PĮ konfigūracijos valdymas (3)
3. PĮ konfigūracijos valdymo žingsniai
1) 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).
125
XVIII. PĮ konfigūracijos valdymas (4)
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ų.
126
XVIII. PĮ konfigūracijos valdymas (5)
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?
127
XVIII. PĮ konfigūracijos valdymas (6)
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?
128
XVIII. PĮ konfigūracijos valdymas (7)
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.
129
XIX. PĮ įsigijimo rizikos valdymas (1)
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ė).
130
XIX. PĮ įsigijimo rizikos valdymas (2)
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.
131
XIX. PĮ įsigijimo rizikos valdymas (3)
2. Rizikos šaltinių sritys
Rizikos sritis
PĮ inžinerija
1. PĮ reikalavimai.
2. PĮ projektas.
3. PĮ kūrimas ir testavimas.
4. PĮ integravimas ir
testavimas.
5. Technikos sritis.
PĮ kūrimo aplinka
1. Kūrimo procesas.
2. Kūrimo sistema.
3. Valdymo planas.
4. Valdymas.
5. Darbo aplinka.
Projekto apribojimai
1. Ištekliai.
2. Sandoris.
3. Projekto sąsajos.
132
XIX. PĮ įsigijimo rizikos valdymas (4)
3. Rizikos valdymo žingsniai
Rizikos
veiksnių
įvardinimas
Rizikos
analizė
Rizikos
mažinimas
Rizikos
stebėsena
133
XIX. PĮ įsigijimo rizikos valdymas (5)
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ė.
134
XIX. PĮ įsigijimo rizikos valdymas (6)
Rizikos veiksnių apibūdinimo lentelė
Atsiradimo tikėtinumas
Aukštas
Aukštas
Poveikis Vidutinis
Žemas
Vidutinis
Žemas
Rizikos veiksnys Nr.1
Rizikos veiksnys Nr.3
Rizikos veiksnys Nr.4
---
Rizikos veiksnys Nr.8
Rizikos veiksnys Nr.2
Rizikos veiksnys Nr.5
Rizikos veiksnys Nr.7
Rizikos veiksnys Nr.6
---
---
135
XIX. PĮ įsigijimo rizikos valdymas (7)
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;
136
- rizikos prisiėmimas. Prisiimama žemesnio prioriteto rizika.
XIX. PĮ įsigijimo rizikos valdymas (8)
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
137
VU MIF Programų sistemų katedra
Programų sistemų priežiūra
138
Įvadas (1)
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.
139
Įvadas (2)
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.
140
Įvadas (3)
1. PĮ priežiūros klausimų grupės
PĮ priežiūra
Apibrėžimai ir
terminai
Priežiūros
esmė
Priežiūros
poreikis
PĮ priežiūros
pagrindai
Pagrindiniai PĮ
priežiūros
klausimai
Priežiūros
procesas
Priežiūros
gerinimo
būdai
Pagrindinės
priežiūros
išlaidos
Techniniai
klausimai
Priežiūros
procesai
PĮ
suprantamumo
gerinimas
PĮ plėtra
Valdymo
klausimai
Priežiūros
veiklos
Reinžinerija
Priežiūros
darbų
kategorijos
Priežiūros
išlaidų
įvertinimas
PĮ priežiūros
įvertinimas
Atvirkščioji
inžinerija
141
Įvadas (4)
2. Pagrindiniai šaltiniai PĮ priežiūros klausimais
1) IEEE Std 1219-1998, IEEE Standard for Software Maintenance, 1998.
http://www.cs.uah.edu/~rcoleman/CS499/CourseTopics/IEEE_Std_12191998.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
142
I. PĮ priežiūros pagrindai (1)
1. Apibrėžimai ir sąvokos
PĮ 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.
143
I. PĮ priežiūros pagrindai (2)
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.
144
I. PĮ priežiūros pagrindai (3)
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.
145
I. PĮ priežiūros pagrindai (4)
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.
146
I. PĮ priežiūros pagrindai (5)
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ė.
147
I. PĮ priežiūros pagrindai (6)
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.
148
I. PĮ priežiūros pagrindai (7)
6. PĮ priežiūros darbų kategorijos
ISO/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.
149
I. PĮ priežiūros pagrindai (8)
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ų kategorijos
Koregavimo
kategorijos darbai
Galimybių plėtros
kategorijos darbai
Inicijuojamieji
Prevenciniai
Tobulinimo
Reaguojantieji
Klaidų taisymo
Pritaikymo (adapt.)
150
II. Pagrindiniai PĮ priežiūros klausimai (1)
1. Techniškieji priežiūros klausimai
1) ž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.
151
II. Pagrindiniai PĮ priežiūros klausimai (2)
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.
152
II. Pagrindiniai PĮ priežiūros klausimai (3)
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;
153
II. Pagrindiniai PĮ priežiūros klausimai (4)
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.
154
II. Pagrindiniai PĮ priežiūros klausimai (5)
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.
155
II. Pagrindiniai PĮ priežiūros klausimai (6)
3. Išlaidų PĮ priežiūrai įvertinimas
Rengiant 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:
156
II. Pagrindiniai PĮ priežiūros klausimai (7)
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.
157
II. Pagrindiniai PĮ priežiūros klausimai (8)
4. PĮ priežiūros sudėtingumo įvertinimas
Tai 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;
158
II. Pagrindiniai PĮ priežiūros klausimai (9)
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.
159
III. PĮ priežiūros procesas (1)
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.
160
III. PĮ priežiūros procesas (2)
1) PĮ priežiūros proceso veiklos (IEEE1219-98):
Pageidavimas keisti
1. Pakeitimų
klasifikavimas ir
įvardinimas
4. Keičiamos PĮ
kūrimas
2. Analizavimas
5. Testavimas
3. Projektavimas
6. Testavimo
rezultatų
priėmimas
7. Pakeitimų
diegimas
161
III. PĮ priežiūros procesas (3)
2. PĮ priežiūros veiklos
Daug 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;
162
III. PĮ priežiūros procesas (4)
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;
163
III. PĮ priežiūros procesas (5)
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.
164
III. PĮ priežiūros procesas (6)
PĮ priežiūros planavimas
1) į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;
165
III. PĮ priežiūros procesas (7)
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.
166
III. PĮ priežiūros procesas (8)
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.
167
III. PĮ priežiūros procesas (9)
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.
168
IV. PĮ priežiūros gerinimo būdai (1)
1. Programų suprantamumo gerinimas
Programuotojai 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.
169
IV. PĮ priežiūros gerinimo būdai (2)
2. Reinžinerija
Reinž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.
170
IV. PĮ priežiūros gerinimo būdai (3)
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ų.
171
VU MIF Programų sistemų katedra
Pabaiga
172