Miro Lozej

1. RAZVOJNO VZDRŽEVANJE NAMENSKE PROGRAMSKE OPREMEohranjanje uporabne vrednostiobstoječim aplikacijam Miro Lozej Ministrstvo za kmetijstvo, gozdarstvo in prehrano

2. Vsebina • Licenčna programska oprema • Namenska programska oprema • Življenjski cikel namenske programske opreme • Razlogi za spremembe • Razvojno vzdrževanje • Do kdaj • Zaključki

3. Vrste programske opreme • Kdo je naročnik razvoja in vzdrževanja • Razvijalec za neznanega naročnika: licenčna programska oprema • Naročnik za svoje specifične potrebe: namenska programska oprema

4. Licenčna programska oprema • Izdelek, ki pokriva tržno nišo • Ciljna skupina je večje število vnaprej neznanih naročnikov • Lastnik je razvijalec ki podeljuje pravice za uporabo • Različne oblike odnosa kupca z lastnikom • Prosta uporaba • Enkratni nakup • Vzdrževanje licenc • Posebni dogovori • Verzije in njihovo vzdrževanje

5. Stroški uporabe licenčna programska oprema • Nakup in vzdrževanje licenc • Namestitve • Izobraževanje in usposabljanje • Podpora pri reševanju zapletov • Pridobitev novih verzij • Namestitev novih verzij

6. Namenska programska oprema • Večine posebnih potreb uporabnikov v okviru konkretnih procesov ne moremo podpreti samo z licenčno programsko opremo. • Namenska programska oprema je razvita za znanega naročnika in podpira njegove specifične zahteve. • Naročnik je neposredno udeležen pri razvoju in vzdrževanju te opreme. • Konkurenčna podjetja ne morejo pridobiti enake opreme, zato je ta ključna primerjalna prednost.

7. Življenjski cikel • Priprava specifikacije • Izbor izvajalca (razpis?) • Razvojni projekt • Primopredaja • Razvojno vzdrževanje • Začetno obdobje: odpravljanje napak, vsebinske dograditve • Nadaljevanje: dopolnitve za prilagajanje spremembam v okolju • Zrelo obdobje – malo dopolnitev • Zaključek: opustitev ali reinženiring

8. Specifikacija • Definicija procesov • Postopki • Podatki • Vloge • Ne preveč splošno • Ne preveč podrobno • Računalniško podprt sistem je drugačen kot ročno voden sistem – kar je v enem enostavno je lahko v drugem zelo komplicirano, in obratno

9. Izbor izvajalca • Programerji v hiši ali zunanji izvajalci? • Razpis za izbor izvajalca • Kriterij cena razvoja in vsaj eno leto razvojnega vzdrževanja • Nevarnost: neizkušeni izvajalec dobi razpis, ker je podcenil obseg dela, izkušeni pa je z realno oceno predrag. • Pogoji: • Najmanjše število zaposlenih • Imena in kvalifikacije delavcev na projektu • Reference (in njihova vrednost za ocenjevanje) • Standardi kvalitete • Metodologija razvoja

10. Lastništvo kode • Naročnik je lastnik kode namenske programske opreme • Izvajalec ne more garantirati delovanja, če drugi posegajo v njegovo kodo • Predaja kode v zaprti kuverti – formalno OK, sicer pa ni koristi • Zamenjava izvajalca pomeni reinženiring kode celotnega projekta

11. Investicija ali storitev • Neopredmeteno osnovno sredstvo? • Stroški knjiženi na konto za investicije • Inventarna številka • Amortizacija • Ob vsaki spremembi revalorizacija • Storitev? • Program je rezultat storitve • Nima amortizacijske dobe • Programa ne revaloriziramo • Primerjalna prednost – nedotakljivo sredstvo • Kaj je rezultat dela zaposlenih programerjev iz podjetja?

12. Testiranje • Testiranje je edini način, kako povečati zanesljivost delovanja novega sistema • Zahtevno delo: • Načrt testiranja • Testni podatki • Intenzivna udeležba bodočih uporabnikov • Pogoste spremembe zaradi odpravljanja napak • Ob koncu projekta zmanjkuje časa in denarja • Mamljivo: takoj v produkcijo

13. Prvi tedni produkcije • Primopredaja? • Uvajanje še ni bilo v celoti izvedeno • Klicni center, direktna pomoč uporabnikom • Odpravljanje napak “na živo” • Krizni štab • Začasne rešitve in kompromisi • Izjemni napori

14. In potem? • Pozornost vodstva se preusmeri na druge težave • Začasne rešitve ostajajo trajne • Sistemci, razvijalci najbolje poznajo sistem – • zato tudi ostanejo nosilci rutinskih opravil • Po nekaj projektih nimajo več časa za nove razvojne naloge • Za delovanje sistema ostanejo nepogrešljivi • Garancijsko obdobje ni dovolj • Pojavljajo se zahteve po dopolnitvah in spremembah

15. Spremembe? • Zakaj niso bile nove zahteve že upoštevane v projektu? • Spregledani postopki • Izjeme • Nove možnosti novega sistema – nove potrebe • Optimizacije na osnovi izkušenj • Spremembe v zakonskih osnovah • Reorganizacije • Spremembe v podatkovnem okolju (zunanji viri) • Kasneje spremembe v sistemskem okolju

16. Razvojno vzdrževanje • Spremembe in dograditve – oblika razvoja programske kode • Na začetku produkcije največ potreb, kasneje počasi vedno manj – to ni odprava obrab in okvar! • Razvojno-vzdrževalna pogodba definira poslovni odnos • Naročila: • Enolične oznake naročil • Ocena obsega del in vrednosti po naročilih (vnaprej) • Spremljanje naročil ter ustreznih računov in plačil • Administracija naročil je tudi strošek

17. Koliko stane? • Licenčna programska oprema: letno vzdrževanje in tehnična podpora med 20% in 25% vrednosti nakupa – z vzdrževanjem kupimo novo verzijo v 4-5 letih. • Razvojno vzdrževanje namenske programske opreme: med 25% in 35% vrednosti začetnega razvoja – razvojno vzdrževanje doseže vrednost začetne investicije v prvih 3-4 letih. Kasneje vpade. • Odstopanja: • Velikost sistema (pri manjših sistemih je manj sprememb, ki pa so sorazmerno z začetno investicijo dražje) • Število uporabnikov • Kritičnost za poslovni sistem • Živahnost zakonodaje

18. Nov projekt ali dograditev? • Projekt ali samo dograditev - ni objektivnih kriterijev • Projekt • Nov razpis • Možen še en izvajalec, konkurenca, dodatno usklajevanje • Strošek novega projekta ne bremeni vzdrževalne pogodbe • Lažje zagovarjati pred nadzorniki • Dograditev • Težje zagovarjati odločitev • Isti izvajalec • Boljše poznavanje obstoječega okolja in soodvisnosti • Enostavnejše usklajevanje • Ponovna uporaba stare kode

19. Pretirani stroški? • Sistem deluje, zakaj novi stroški, • Spremembe bi bile v ročno vodenem sistemu preproste, • V očeh uporabnikov se zdi, da izvajalci komplicirajo s podrobnimi vprašanji, • Sprememba je potrebna, a le uporabljena samo izjemoma, • Sprememba nekaterim celo nalaga dodatno delo, • Sum, da izvajalec zaračunava preveč ur, • Sistem je še nov, pa že toliko zahtevkov po spremembah, • Sedaj pa “spet nič ne dela!”

20. Pretirani stroški? • Sistem deluje, zakaj novi stroški, • Spremembe bi bile v ročno vodenem sistemu preproste, • V očeh uporabnikov se zdi, da izvajalci komplicirajo s podrobnimi vprašanji, • Sprememba pride le redko v poštev, samo izjemoma, • Sprememba nekaterim celo nalaga dodatno delo, • Sum, da izvajalec zaračunava preveč ur, • Sistem je še nov, pa že toliko zahtevkov po spremembah, • Sedaj pa “spet nič ne dela!”

21. Ali obstajajo enostavne rešitve? • Sistem, ki ne podpira sprememb v okolju postane neuporaben, • Sistem mora zagotavljati konsistentnost podatkov v vseh možnih primerih, • Obseg programerskega dela je odvisen od kompleksnosti in ne od tega, kolikokrat je tista koda v uporabi, • Naročila: pisno potrjevanje zahtevkov od vsebinskega vodje, • Truda, da sistem normalno deluje, končni uporabnik ne opazi, • Uporabnik pa opazi vsako malenkost, ki ga moti – in takrat “nič ne dela!”

22. Pavšal • Po nekaj letih je zaloga idej in potreb izčrpana. • Ni pa izčrpana možnost • Spremembe zakonske osnove • Reorganizacij • Sprememb v podatkovnem okolju zunanjih virov • Sprememb v sistemskem okolju • Ker je sistem v uporabi, ima zastoj lahko velike posledice, se vedno “zelo mudi” izvesti spremembe • Spremembe težko napovemo, zato je potrebna stalna pripravljenost • Razpoložljivost izvajalcev je strošek tudi, če ni naročil

23. Prenova? • Sčasoma je zaporedje majhnih sprememb povzročilo nepreglednost, nestabilnost in nezanesljivost sistema • Velike spremembe v okolju je priložnost za celovito prenovo • Dobavitelji sistemske opreme ne podpirajo več verzij, ki so potrebne za delovanje, potrebno je nadgraditi razvojno okolje • Partnersko razmerje z izvajalcem se je skrhalo in stroški ne dajejo želenih učinkov – izbor drugega izvajalca obeta boljše rezultate

24. Kako dolgo še? Dokler so stroški razvojnega vzdrževanja manjši od škode, če sistem ne bi deloval. Dokler sistem deluje ne znamo (si ne upamo) oceniti škode, ki bi jo povzročil izpad delovanja.

25. Zaključki • Ljudje reagiramo, ko problem preraste v krizo • Namensko vzdrževanje je sprotno in stalno ohranjanje primerjalne prednosti, ki jo imamo zaradi delovanja namenske programske opreme • Razvojno vzdrževanje se podreja drugačnim zakonitostim, kot veljajo za vzdrževanje materialnih sredstev in nima majhne cene • Stroški razvoja in vzdrževanja niso merilo za oceno vrednosti sistema. Sistem je vreden toliko, kot je velika škoda, ki bi nastala, ko sistem ne bi deloval.