PROGRAMŲ SISTEMŲ

INŽINERIJA
2 paskaita:
Chroniška programavimo krizė

Doc. dr. Diana Kalibatienė

diana.kalibatiene@vgtu.lt
 2

Pagrindiniai šaltiniai
1. A. Čaplinskas. Programų sistemų inžinerijos
pagrindai. Matematikos ir informatikos institutas,
1996, 1998.
2. Standish Group 2011 Chaos Report.
3. BA Promoter. 5 Reasons Software Projects Fail.
Seilevel, Inc. 2015. http://requirements.seilevel.com/blog/2012/03/5-reasons-
software-projects-fail-hint-its-often-due-to-incomplete-incorrect-requirements.html
4. D. Haughey. Why Software Projects Fail and How to
Make Them Succeed. 2015 Project Smart.
https://www.projectsmart.co.uk/why-software-projects-fail.php

5. J. Sutherland, K. Schwaber. The Crisis in Software:

The Wrong Process Produces the Wrong Results. p. 3-
16.
http://static1.1.sqspcdn.com/static/f/447037/17413904/1333204284693/S3D+First+Chapter.pd
f?token=nFU9j0UywQor8oyE5aw%2B%2B%2BM6Nd8%3D
6. Šaltiniai nurodyti skaidrėse.
CHRONIŠKA
PROGRAMAVIMO KRIZĖ
 4

Chroniška programavimo krizė

• Vienoje kompiuterių mugėje Bilas Geitsas,
lygindamas kompiuterių ir automobilių
pramonę, padarė tokį pareiškimą:
• „Jei
„General Motors“ būtų taip ištobulinę
technologijas, kaip mes ištobulinome
kompiuterių gamybos technologijas, tai mes
šiandien visi važinėtumėm automobiliais, kurie
kainuotų 25 dolerius, o su 1 galonu benzino
nuvažiuotumėm 1000 mylių“.
 5

Chroniška programavimo krizė

• Atsakydama „General Motors“ padarė tokį
pareiškimą:
• „Jei mes būtumėm ištobulinę savo technologijas
taip, kaip tą padarė „Microsoft“, tai visi važinėtų
automobiliais, tirinčiais tokias savybes:
• Jūsų automobilis be jokios aiškios priežasties
dukart į dieną sulūžtų.
• Reikėtų pirkti naują automobilį kiekvieną kartą, kai
gatvėje iš naujo buvo pažymėtos linijos.
 6

Chroniška programavimo krizė

• Greitkelyje automobilis kartkartėmis tiesiog užgestų
be jokios priežasties, bet tai būtų laikoma normaliu,
savaime suprantamu dalyku, variklis būtų
užvedamas iš naujo ir ramiai važiuojama toliau.
• Atliekant tam tikrus manevrus, kaip, tarkime,
posūkis į kairę, automobilis užgestų ir daugiau
nebeužsivestų. Reikėtų variklį išardyti ir surinkti iš
naujo.
• Automobiliu būtų galima važiuoti tik vienam žmogui,
nebent nusipirktumėt „CarNT“ arba „CarXP“, bet
tada reikėtų pirkti ir kiekvieną sėdynę atskirai.
 7

Chroniška programavimo krizė

• Naudojant „Macintosh“ technologijas, būtų
gaminami automobiliai, naudojantys saulės
energiją, patikimi, 5 kartus greitesni ir 2 kartus
lengviau vairuojami, bet jie galėtų važinėti tik 5
procentais esamų kelių.
• Tepalo kontrolės lemputė, perspėjamosios
akumuliatoriaus ir temperatūros lemputės būtų
pakeistos viena perspėjančia lempute:
„Esminis variklio gedimas“.
• Naujos sėdynės reikalautų, kad visi keleiviai
turėtų vienodą užpakalio dydį.
 8

Chroniška programavimo krizė

• Oro pagalvė prieš prisipūsdama paklaustų: “Ar jūs tikrai
įsitikinęs, kad pakliuvote į avariją?“
• Kartais automobilis be jokios suprantamos priežasties jus
užrakintu viduje. Atsirakinti būtų įmanoma tik šitaip: tuo pat
metu traukiant durų rankenėlę, sukant užvedimo raktelį ir
viena ranka laikantis už radijo antenos.
• Perkant „General Motors“ automobilį, būtina būtų pirkti
dukterinės firmos išleistų žemėlapių paketa, nepaisant to, ar
jums tų žemėlapių reikia ir ar jie jums patinka. Jei jūs to
nepadarytumėt, automobilis iš karto taptų per pusę lėtesnis.
Be to, dėl šios priežasties, jums dar būtų iškelta byla, dėl
nuostolių kuriuos patyrė „General Motors“ dėl neparduotų
žemėlapių.
 9

Chroniška programavimo krizė

• Kiekvieną kartą, kai „General Motors“ sukurtų
naują automobilio modelį, vairuotojai turėtų iš
naujo mokytis vairuoti, kadangi joks įrenginys ar
jungiklis neliktų automobilyje toje pačioje vietoje,
kaip ankstesniuose modeliuose.
• Norint užgesinti variklį, reikėtų spausti mygtuką,
pavadintą vardu „Start“.“
 10

Chroniška programavimo krizė

• Jei vairuotojams įsidarbinant būtų keliami
tokie pat reikalavimai kaip
programuotojams, skelbimas apie ieškomus
darbuotojus atrodytų taip:
"Siūlome darbą vairuotojui.
 11

Chroniška programavimo krizė

• Reikalavimai: aukštasis išsilavinimas,
profesionali darbo patirtis vairuojant troleibusus,
tramvajus, traukinius, laivus, funikulierius, metro,
ekskavatorius bei atomines elektrines. Ralio
varžybų bei lėktuvo dispečerio patirtis būtina.
Kandidatas privalo turėti patirtį gaminant
dyzelinius variklius bei turbinas. Taip pat, būtina
turėti BMW, Mercedes, KamAZ, ir Boeing
inžinieriaus sertifikatus. Gali būti studentas.
Privalumai: darbo patirtis tiesiant kelius, dažant
kėbulus. Atlyginimas: 600 litu.
 12

Chroniška programavimo krizė

• Didelės programų sistemos dažnai:
• Neužtikrina reikiamo funkcionalumo
• Yra kuriamos per ilgai
• Reikalauja per daug lėšų joms sukurti
• Vykdymui reikalauja reikalauja per daug resursų
(laiko, atminties)
• Yra nepatikimos
• Negali evoliucionuoti ir prisitaikyti prie nuolat
kintančių vartotojų poreikių
Tai ir yra vadinama chroniška
programavimo krize!
 13

Chroniška programavimo krizė

Problemos su PS funkcionalumu
2002 metais atlikta JAV IT organizacijų apžvalga
nustatė, kad
• net 78% tokių organizacijų teisėsi teismuose su
užsakovais.
• 67% iš besiteisiančių organizacijų buvo
paduotos į teismą todėl, kad užsakovams
pateiktos IS programinės įrangos
funkcionalumas iš tiesų neatitiko to, ką apie jį
tvirtino vykdytojai.
 14

Ataskaita apie projektus

CHAOSO ataskaitos rezultatas

Ginčitini
21% Sėkmingi
42%
Nesėkmingi

37%
Sėkmingi - Baigti laiku,
neviršijant biudžeto,
norimas funkcionalumas
realizuotas

Standish Group 2011 Chaos Report, software projects

conducted between 2002 and 2010
 15

Ataskaita apie projektus –

Palyginimas pagal naudojamus PS kūrimo
modelius
WATERFALL AGILE

14% 9%

42%
Nesėkmingi Nesėkmingi
29% 57%
Ginčitini 49% Ginčitini
Sėkmingi Sėkmingi

Projektų, vykdytų naudojant tradicinį ir agilųjį

PS kūrimo modelį, 2002-2010 metais
• Agilieji projektai sėkmingesni 3 kartus.
 16

Chroniška programavimo krizė

Kaina
• Priežiūros kaštai viršija 60% visų programų
sistemos kūrimo kaštų:
• 20% klaidų taisymas
• 30% keitimai, susiję su reikalavimų ir/arba TĮ
pokyčiais
• 50% tobulinimas (papildomas funkcionalumas)
 17

Chroniška programavimo krizė

Problemos su PS kaina
• 1000 vykdomojo kodo eilučių yra daroma
maždaug 50-60 klaidų.
• Didžioji jų dalis yra užsakovo ir vykdytojų
nesusikalbėjimo pasekmė.
• Vykdytojai nesuprato, ko iš tiesų iš jų norima.
 18

Chroniška programavimo krizė

• Kodėl žlunga projektai?
• Pagal Standish Group 2011 ataskaitą:
• tik 37% projektų buvo sėkmingi,
• 42% – ginčitini ir
• 21% – nesėkmingi.
• Dažniausiai projektai:
• užtrunka 222% ilgiau negu buvo planuota,
• 189% - viršija biudžetą ir
• tik 61% - pasižymi norimu funkcionalumu.
 19

Chroniška programavimo krizė

• Kodėl žlunga projektai?
1. Nepakanka laiko
• Dažniausiai projekto trukmė nustatoma dar projektui
neprasidėjus.
• Siekiama kuo greičiau pradėti kodavimo darbus, darant
prielaidą, kad tuo greičiau bus pasiektas norimas
rezultatas ir projektas bus baigtas.
• Tai dažniausiai yra klaidinantis būdas. Yra svarbu
tinkamai suprojektuoti kuriamą programų sistemą. Gero
projekto nebūvimas sąlygoja nuolatinius pakeitimus
paskesnėse stadijose (taip pat kodavimo metu). Kai taip
atsitinka, laiko ir biudžeto suvartojimas sparčiai didėja.
 20

Chroniška programavimo krizė

• Kodėl žlunga projektai?
1. Nepakanka laiko
• Sprendimas: paskirkite laiką geram projektui
sukurti. Nepraleiskite projektavimo ir
nepereikite iš karto prie kodavimo. Paskirkite
laiką projektavimui ir tada projektas vyks žymiai
sklandžiau. Produkto, tenkinančio kliento
poreikius ir pateikto laiku, pateikimas pagerins
Jūsų reputaciją.
 21

Chroniška programavimo krizė

• Kodėl žlunga projektai?
2. Nepakanka biudžeto
• Dažniausiai projektai vadovaujasi „žemiausios
kainos“ politika arba paskiriamas nerealiai mažas
biudžetas, neatsižvelgiant į tikrus vartotojų
poreikius. Kai taip atsitinka, projekto vykdymas
sulėtėja. Resursai lėtai pristatomi arba iš viso
nepristatomi. Toks apkarpymas nulemia ir kokybės
mažėjimą.
• Sprendimas: Būkite realistais ir planuodami
biudžetą remkitės reikalavimais. Venkite kliento
siūlomos „mažiausios kainos“ politikos. Remkitės tik
detaliai suplanuotu biudžetu.
 22

Chroniška programavimo krizė

• Kodėl žlunga projektai?
3. Prastas bendradarbiavimas
• Sakoma: „nieko neturėk omenyje “ ir tai ypač
galioja projektuojant programų sistemas. Geras
bendradarbiavimas tarp klientu, vartotojų ir
projektuotojų komanda svarbus projekto sėkmės
faktorius.
• Ar visi komandoje Jus suprato?
• Ar komanda žino ko tiksliai tikimasi?
• Ar komandos nariai tinkamai bendrauja
tarpusavyje, su vartotojais?
 23

Chroniška programavimo krizė

• Kodėl žlunga projektai?
3. Prastas bendradarbiavimas
• Sprendimas: Nustatykite galimus
komunikavimo trūkius kuo anksčiau. Tokių
trūkių nenustatymas gali sąlygoti nesusipratimų
atsiradimą vėliau. Niekada negalvokite, kad visi
suprato. Skirkite laiko sukurti aplinkai, kad
projektas būtų užbaigtas laiku, pagal numatytą
biudžetą ir atitiktų kliento poreikius.
 24

Chroniška programavimo krizė

• Kodėl žlunga projektai?
4. Niekada neperžiūrima projekto pažanga
• Vykstant projektui, tam tikri dalykai keičiasi, o tai
gali smarkiai sąlygoti projektą. Todėl būtina
reguliariai peržiūrėti projektą. Tai leis nustatyti
naujus iššūkius ir reikalui esant informuoti klientą
apie galimą vėlavimą ir produkto pasikeitimus.
• Sprendimas: Nustatykite dažnus kontrolės taškus
(milestones), kai bus peržiūrimas projektas.
Bendraukite su savo komanda. Tai leis Jums
suprasti kas vyksta ir su kokiais sunkumais
susiduriama.
 25

Chroniška programavimo krizė

• Kodėl žlunga projektai?
5. Nepakankamas testavimas
• Kai laikas spaudžia, dažnai apkarpomas produkto
testavimui skirtas laikas. Visas testavimas
paliekamas pabaigai ir tikima, kad viskas pasiseks.
• Gaunamas produktas pilnas klaidų -> klientai
nepatenkinti.
• Sprendimas: atlikite testavimą kiekvienoje
produkto gyvavimo ciklo stadijoje. Testuokite
kiekvieną modulį arba komponentą, kai jis yra
sukuriamas. Pabaigoje liks tik galutinis viso
produkto testavimas.
 26

Chroniška programavimo krizė

• Kodėl žlunga projektai?
6. Testuojama gamyklinėje aplinkoje
• Daugelis įmonių savo produktus testuoja taip
vadinamoje produktų gamyklinėje aplinkoje.
• Tai sąlygoja saugumo spragų atsiradimą ir
galimybę sutrikdyti gamybinę aplinką.
• Sprendimas: sukurkite kokybės užtikrinimo
procesą ir realizuokite naujus programų sistemų
produktus. Sukurkite aplinką atskirą gamybinei.
 27

Chroniška programavimo krizė

• Kodėl žlunga projektai?
7. Kokybės užtikrinimo trūkumas
• Dažnai skubant pristatyti PS laiku, nukenčia
kokybės užtikrinimas. Dokumentacija nepilna,
kodo pakeitimai neužfiksuoti, projektas pilnas
trūkumų, įgyvendinimas nepilnas. Visa tai
sąlygoja perdarymus, laiko praradimą ir
galiausiai klientai yra nepatenkinti.
• Sprendimas: skirkite laiką kokybės užtikrinimui
ir dokumentuokite (aprašykite) PS prieš ją
paleidžiant.
 28

Chroniška programavimo krizė

• Kodėl žlunga projektai?
8. Nesilaikoma standartų
• Besilaikant visuotinai pripažintų standartų, padidinamas
projekto efektyvumas ir užtikrinamas produkto
prieinamumas (accessibility), perkeliamumas
(portability), panaudojamumas (usability), patikimumą
(robustness) ir sumažinama problemų dabar ir ateityje.
• Organizacijos, tokios kaip Tarptautinių standartų
organizacija (International Organisation for
Standardisation (ISO)) ir World Wide Web Consortium
(W3C), sukūrė atvirąjį standartą.
• Sprendimas: skirkite laiko standartams įdiegti Jūsų
projekte. Nustatykite kas veikia gerai – ir taip darykite ir
toliau, ir kas veikia blogai – tai pakeiskite. Peržiūrėkite ir
atnaujinkite savo standartus.
 29

Chroniška programavimo krizė

• Stacey grafikas (The Stacey Graph)
• R. Stacey, Complexity and Emergence in
Organizations (London: Routledge, 2001).
• Tai naudingas įrankis projekto tikimybėms ir
prognozėms įvertinti.
• Stacey grafikas leidžia palyginti projekto
įvykdymą (apibrėžtumą) su projekto žlugimu
(neapibrėžtumu).
• Jis naudojamas PS projektavimo aspektams
apžvelgti. Tai: reikalavimai, technologijos ir
žmonės.
 30

Chroniška programavimo krizė

• Stacey grafikas (The Stacey Graph)
• Reikalavimai: Kai yra griežtai apibrėžti – nekinta,
kai nėra apibrėžti – tikėtina kad kis.
• Technologijos: yra suprantamos ir gerai žinomos,
nėra apibrėžtos, dažniausiai tai daugelis produktų
sujungtų ir bendraujančių per interfeisus
skirtinguose PS projektavimo lygmenyse.
• Žmonės: žinomi ir pastovūs esant nedidelei
komandai, ir pastoviai kintantys dideliuose
projektuose. Žmonės savaime turi nuomones,
požiūrius ir nuotaikas. Dirbant grupėse arba
komandose, padidėja jų tarpusavio sąryšiai ir
nenuspėjamumas darbe.
 31

Chroniška programavimo krizė

• Stacey grafikas (The Stacey Graph)

Close to Certainty – griežtai apibrėžti

Far from Certainty – prastai apibrėžti
Close to Agreement – sutarta dėl
Far from Agreement – nesutarta dėl
 32

Chroniška programavimo krizė

• Stacey grafikas (The Stacey Graph)
• Pagal Stacey grafiką PS projektas dažniausiai
sudėtingas ir dažniausiai chaotiškas.
• Nuspėjami procesai, kuriais grindžiami krioklio ir
tradicinis PS projektavimas, taikytinas tik
paprastiems, kartotiniams darbams
• Tačiau pagal Standish ataskaitą, PS projektai
dažniausiai nuspėjami tik 14%.
 33

Chroniška programavimo krizė

• Stacey grafikas (The Stacey Graph)
• Žmonės dažnai tapatina PS projektavimą su
statyba arba tilto tiesimu.
• Pagal Stacey grafiką, inžinerinės disciplinos,
kaip tiltų tiesimas ir statyba, priskirtinos
intervalui [paprastos; sudėtingos].
• Kodėl PS projektavimas sudėtingas
ir dažniausiai chaotiškas?
 34

Chroniška programavimo krizė

• Stacey grafikas (The Stacey Graph)
• Standartizavimas tik pasunkina darbą.
• Yra trys standartizavimo formos:
1. Niutono dėsnis aiškinantis kaip fiziniai objektai
bendradarbiauja.
2. Standartinių medžiagų, kaip medinių sijų, metalinių
statramsčių ir tvirtinimo detalių, turinčių standartinį
dydį ir žinomas charakteristikas, naudojimas.
3. Standartai visų tipų konstrukcijoms.
• Programų sistemų inžinerijoje to nėra. Be to,
evoliucionuojant programų sistemų
inžinerijai, jie keičiasi.
 35

Chroniška programavimo krizė

Kitos 5 priežastys
• Kodėl žlunga projektai?
(Project Management Solutions)
1. Reikalavimai: jeigu PS reikalavimai yra
apibrėžiami prastai (neaiškiai, nenustatant
prioritetų, kad juos neįmanoma panaudoti
(unconsumable), nepilnai, neatspindi verslo tikslų
ir uždavinių), didelė tikimybė, kad projektas
žlugs.
2. Resursai: jeigu neatsižvelgiama į projektuotojų
komandos įgūdžius ir projektavimo procesą, toks
projektas bus rizikingas.
 36

Chroniška programavimo krizė

• Kodėl žlunga projektai? Kitos 5 priežastys
(Project Management Solutions)
3. Grafikas: sukurkite poveikių tvarkaraštį.
Jeigu analitikų komanda nepateikia pilno ir
panaudojamo reikalavimų sąrašo, klaidų ir
perdarymų skaičius padidės. Be to, tinkamai
įvertinus ir skirus pakankamai laiko, reikalingo
geriems reikalavimams sukurti, tinkamai
suplanuojamas darbas.
 37

Chroniška programavimo krizė

• Kodėl žlunga projektai? Kitos 5 priežastys
(Project Management Solutions)
4. Planavimas: tokiems projektams, kaip pensijų
fondai, e-komercija/transakcinė sistema, ir pnš.,
reikalavimų apibrėžimas yra planavimo dalis, kurią
reikia atlikti, kad sumažinti projekto žlugimo
tikimybę dėl duomenų trūkumo, nepilno arba prasto
detalių apibrėžimo ir dėl verslo tikslų aiškumo
stokos.
5. Rizikos: nuodugnus ir pilnas reikalavimų išgavimas
padės nustatyti prielaidas, dėl kurių atsiranda
"nenumatytos" projekto rizikos.
 38

Chroniška programavimo krizė

Kodėl projekto biudžetas yra viršijamas?
• Projekto kainos formulė
Kaina = Apimtis x Sudėtingumas/Našumas
projekto pradžioje turi 3 nežinomuosius: apimtis,
sudėtingumas ir našumas.
Netikslūs projekto kainos ir
trukmės vertinimai sužlugdė
daugelį projektų!
 39

Klausimai?