osio_08.1_procesi_odrzavanja_softvera_2015.0_3.11

Univerzitet u Kragujevcu FAKULTET TEHNIČKIH

NAUKA ČAČAK

Predmetni nastavnik:drdr Živadin Micić Živadin Micić

11. III 2015.

- Procesi održavanja u živ. ciklusu softvera, modeli

procesa i zadaci održavanja

IT

Predmet: OS i održavajeOS i održavaje

Softverski inženjering

IT - Ž. Micić ---/ 2015FTN 2/48

1 Sadržajni okvir i zadaci nastavne/ temastke jedinice

2 Osnovni pojmovi, definicije, koncepti, proces održavanja

u životnom ciklusu softvera (ŽCS) – aktivnosti – zadaci Klasični razvojni modeli softvera

(ŽCS - IS održavanja – IV deo) Problem održavanja i evolucije softvera Evolutivni modeli održavanja softvera

11 Aktivnosti studenata i kontrolna pitanja12 Literatura

SadržajSadržaj

1 Sadržajni okvir i zadaci nastavne/tematske jedinice

8. Procesi održavanja, zadaci i efikasnost – potrebe za praćenjem efikasnosti održavanja - u fokusu

su procesi održavanja (tematski) aktivnosti i procesi održavanja: “управљање садржајем, распоређивање садржаја (фајл систем, структура...), администрација сервера, упутства и група за управљање, Backup, менаџмент безбедности, управљање ресурсима, аутоматизација управљања (аутоматско заказивање посла), системска подршка, корисничка подршка и образовање za odžavanje.”

3/48

Funkcija ZA UPRAVLJANJE

KONTROLERIMA I/O UREĐAJA


PROCESOROM

Funkcija ZA UPRAVLJANJE MEMORIJOM

Funk

cija

ZA

UPR

AVLJ

ANJE

DAT

OTE

KAM

A

Zadatak OPERATIVNOG SISTEMA je da upravlja fizičkim

(procesor, kontroleri i radna memorija) i logičkim (datoteke i procesi) delovima računara, pa

se OS može posmatrati sa aspekta upravljačkih funkcija:

VIII

IX

XI

II

Funkcija ZA UPRAVLJANJE PROCESIMA

III


KONFIGURACIJOM/ ARHITEKTUROM

X

Funkcija ZA PODRŠKU

APLIKACIJAMA

XII

Funkcija ZA UPRAVLJANJE PREKIDIMA

V-VIFunkcija ZA RAD U

LOKALNIM MREŽAMAFunkcija ZA

PODRŠKU GLOBALNIM MREŽAMA

1 Sadržajni okvir i zadaci

nastavne/ temastke jedinice




PROCESOROM


Funk

cija

ZA

UPR

AVLJ

ANJE

DAT

OTE

KAM

A





APLIKACIJAMA

XII

Funkcija ZA

UPRAVLJANJE

PREKIDIMA

Funkcija ZA RAD U

LOKALNIM

MREŽAMAFunkcija ZA PODRŠKU

GLOBALNIM MREŽAMA

2.

Man

agem

ent -

Rukov

odst

vo

3. Men - Čovek

4. Method/model –

Metod/model razvoja softvera

5. Metrics – Merenje (9126-

x)

6. Milieu – Okruženje

10. Measurement -

Merenje9. Material - Materijal

7. Maintenance - Održavanje

11. Memory - Memorija

8. Machine - Mašina

10M10M

Analogija: OS – IS u održavanju?




Funk

cija

ZA

UPR

AVLJ

ANJE

DAT

OTE

KAM

A

VIII

IX

XI

II


III



X


APLIKACIJAMA

XII


V-VI Funkcija ZA RAD U LOKALNIM MREŽAMA


GLOBALNIM MREŽAMA

MODUL ZA UPRAVLJANJE PROCESOROMPROCESOROM

Uvodi operaciju preključivanja čiji poziv dovodi do preključivanja

procesora sa jedne niti na drugu, koje mogu pripadati istom ili raznim

procesima.U toku preključivanja procesora između niti istog procesa ne dolazi

do izmene adresnog prostora procesa, pa je ovakvo

preključivanje brže (kraće) nego preključivanje procesora između

niti raznih procesa.

Po analogiji: kreirati IS u održavanju?




Funk

cija

ZA

UPR

AVLJ

ANJE

DAT

OTE

KAM

A

VIII

IX

XI

II

Funkcija ZA UPRAVLJANJE PROCESIMAPROCESIMA



X


APLIKACIJAMA

XII


V-VIFunkcija ZA RAD U

LOKALNIM MREŽAMAFunkcija ZA

PODRŠKU GLOBALNIM MREŽAMA

MODUL ZA MODUL ZA UPRAVLJANJE UPRAVLJANJE

PROCESOROMPROCESOROM

Omogućava stvaranje i uništavanje procesa, kao i stvaranje i

uništavanje njihovih niti, odnosno omogućava istovremeno postojanje

više procesa (višeprocesni režim rada), tj. više niti. Poziva operaciju čitanja, radi

preuzimanja sadržaja izvršnih datoteka, koje su potrebne za

stvaranje slike procesa, a pošto je za stvaranje slike procesa potrebna radna memorija,

pozivaju se i operacije zauzimanja, odnosno oslobađanja.

III

Elementi IS-a i podsistem održavanja u okruženju poslovnog sistema

Marketing

Alati

Naabavka CAP

Zahtevi Planiranje

PROIZVODNI PROCESI Podaci o kvalitetu

CAM

Korisnici

ULAZ

Doba - vljači

Korisnic Dokumentac

K

V

A

L

I

T

E

T

Ciljevi, strategija i upravljanje PPCS

QA

QA

QA

QA

C A L

(PPS) CAL

Održavanje

Nabavka

Arhiva

Izveštaji

Tehnološki procesi

Audit

Ekonomika i resursi

TQM

I

N

F O R

M

A

C

I O N

I

S

I

S

T

E

M

Upravljanje

Dokumentac.

Razvoj

IZLAZ

FMEA QDM

QPM

QAM

QMB

QPB

QCM

RMS

SPC

CCSE

QFD

QT

Ishikawa

CAQ

-

EDM

I S

QTM

SISTEM ZA OBRADU

INFORMACIJA ORGANIZA-

CIONI RESURSI

TEHNIKA LJUDI

FINANSIJE

Obezbeđ. distribucije informacija

S I S T E M Z A O B R A D U P O D A T A K A

Mera i količina

Teorija inform.

Osobine informac.

Komunikacije i oprema (uređaji)

Tokovi informacija

Vrste informacija

Nosioci informacija

Troškovi i ekonomičnost informacija

Obrada i prenos informacija

M I S QSD

CAT

QMM

Sadržaj1 Sadržajni okvir i zadaci nastavne/ temastke jedinice

2 Osnovni pojmovi, definicije, koncepti, proces održavanja

u životnom ciklusu softvera (ŽCS) – aktivnosti – zadaci Klasični razvojni modeli softvera (IS održavanja – IV deo) Problem održavanja i evolucije softvera Evolutivni modeli održavanja softvera


9/48

10/48

Održavanje u prosecima životnog ciklusa softvera

SRPS ISO/IEC 12207

1 PPrimarnirimarni procesi životnog ciklusa softvera 1.5 Proces održavanja iz aktivnosti: 1.5.1) Implementacija procesa; 1.5.2) Analiza problema i modifikacija; 1.5.3) Implementacija modifikacije; 1.5.4) Pregled/ prijem održavanja; 1.5.5) Migracija; 1.5.6) Povlačenje softvera.

sa p

rošl

og

časa

2 Procesi podrškepodrške u životnom ciklusu 2.1 Proces dokumentovanja 1.projektovanje i razvoj, 2.izrada, 3.implementacija i 4.održavanje 3 OrganizacioniOrganizacioni procesi životnog ciklusa 3.1 Proces upravljanja

3.2 Proces infrastrukture (akt. održavanja infrastrukture) 3.3 Proces poboljšanja (održavati podatke o troškovima) 3.4 Proces obuke (održavanje obučenosti osoblja)

Proces održavanja

5.5 Proces održavanja (5.5 u [110])• Sadrži aktivnosti i zadatke projektanta održavanja; • Aktivira se zbog nekog problema ili potrebe za poboljšanjem

ili prilagođavanjem, kada se softverski proizvod podvrgne modifikacijama koda i prateće dokumentacije;

• Cilj je modifikacija postojećeg softverskog proizvoda i da se pri tom očuva njegov integritet;

• Obuhvata migraciju i povlačenje softverskog proizvoda;• Završava se povlačenjem softverskog proizvoda;• Može koristiti procese podrške i procese organizacije;• Ako se koristi proces razvoja (5.3 u [110]), izraz projektant

treba tumačiti kao projektant održavanja.

11/48

SRPS ISO/IEC 12207 [110]

Proces održavanja

5.5 Proces održavanja• Projektant održavanja upravlja procesom održavanja na

nivou projekta pridržavajući se:– procesa upravljanja (7.1 u [110]); – uspostavlja infrastrukturu pridržavajući se procesa

infrastrukture (7.2 u [110]); – prilagođava proces prema projektu služeći se procesom

prilagođavanja (4 aktivnosti) održava podatke o troškovima i

* upravlja procesom na organizacionom nivou sledeći proces poboljšanja (7.3 u [110]) i

– proces obuke za održavanje (7.4 u [110]).

Kada je projektant održavanja isporučilac usluge održavanja, on obavlja proces isporuke (5.2 u [110]). 12/48

SRPS ISO/IEC 12207, [110]

Proces održavanja – kroz 6 aktivnosti 24 zadataka

5.5 Proces održavanja

Sledi spisak 6 aktivnosti primarnog procesa održavanja sa pratećim zadacima.

Ovaj proces se sastoji od sledećih aktivnosti (∑24 zadat):

• 1) Implementacija procesa ... 3 zadatka (PO*);

• 2) Analiza problema i modifikacija5 zadataka (PO);

• 3) Implementacija modifikacije ... 2 zadatka (PO);

• 4) Pregled/ prijem održavanja ... 2 zadatka (PO);

• 5) Migracija ... ... ... 7 zadataka;

• 6) Povlačenje softvera ... ... 5 zadataka.

* PO – Projektant održavanja (nadležan za zadatke)13/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci implementacije procesa

.1 Implementacija procesa. Aktivnost se sastoji od tri zadatka Projektanta održavanja:

.1.1 razvija, dokumentuje i izvršava planove i procedure za sprovođenje aktivnosti i zadataka iz procesa održavanja;

.1.2 utvrđuje procedure za prijem i praćenje izveštaja o problemima i zahtevima za modifikaciju koje korisnik dostavlja i uspostavlja povratnu spregu sa korisnicima. Uvek kada se naiđe na probleme, oni se moraju registrovati i uneti u proces rešavanja problema (6.8 u [110]);

.1.3 implementira proces upravljanja konfiguracijom (6.2 u [110]) (ili uspostavlja organizacioni interfejs sa njim) radi upravljanja modifikacijama postojećeg sistema.

14/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci analize problema i modifikacije

.2 Analiza problema i modifikacija. Aktivnost se sastoji od sledećih pet zadataka Projektanta održavanja:

.2.1 analizira izveštaj o problemu ili zahtev za modifikacijom u pogledu njegovog uticaja na organizaciju, postojeći sistem i sisteme sa kojima se sučeljava u pogledu sledećeg:

• a) tip: na primer, korektivan, poboljšavajući, preventivan ili prilagođavajući novom okruženju;

• b) obim: na primer, veličina modifikacije, troškovi, potrebno vreme;

• c) kritičnost: na primer, uticaj na performanse, bezbednost ili sigurnost.

15/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci analize problema i modifikacije

.2 Analiza problema i modifikacija. Aktivnost se sastoji od pet zadataka Projektanta održavanja:

.2.2 osporava ili potvrđuje postojanje problema;

.2.3 razvija opcije za implementiranje modifikacije (na osnovu analize);

.2.4 mora da dokumentuje zahtev o problemu/ modifikaciji, rezultate analize i opcije implementacije;

.2.5 mora da dobija/ traži odobrenje za izabranu opciju modifikacije kao što je naznačeno u ugovoru.

16/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci implementacije modifikacije

.3 Implementacija modifikacije. Aktivnost se sastoji od sledeća dva zadatka Projektanta održavanja:

.3.1 sprovodi opširnu analizu i određuje koja dokumentacija, softverske jedinice i verzije treba da se modifikuju (ovo se mora dokumentovati);

.3.2 ulazi u proces razvoja (5.3 u [110]) da implementira modifikaciju.

17/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci implementacije modifikacije

.3 Implementacija modifikacije. Aktivnost se sastoji od sledećih zadataka i zahteva procesa razvoja:

.3.2. Zahtevi procesa razvoja dopunjuju se:• a) kriterijumima za ispitivanje i vrednovanje kojima se

ispituju i vrednuju modifikovani i nemodifikovani delovi sistema (softverske jedinice, komponente i elementi konfiguracije) i koji moraju biti definisani i dokumentovani;

• b) potpunom i ispravnom implementacijom novih i modifikovanih zahteva.

• Sem toga, proverava se da li su ostali neizmenjeni originalni, nemodifikovani zahtevi.

• Rezultati ispitivanja moraju da se dokumentuju. 18/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci pregleda/prijema održavanja

.4 Pregled/ prijem održavanja. Aktivnost se sastoji od sledeća dva zadatka Projektanta održavanja (C-faza u PDCA konceptu):

.4.1 izvršava pregled(e) sa organizacijom koja je odobrila modifikaciju u cilju utvrđivanja celovitosti modifikovanog sistema;

.4.2 dobija saglasnost o zadovoljavajućem završetku modifikacije kao što je naznačeno u ugovoru.

19/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci migracije

.5 Migracija. Aktivnost se sastoji od sledećih 7 zadataka:

.5.1 Ako se jedan sistem ili softverski proizvod (uključujući podatke) prenese iz starog u novo radno okruženje, treba proveriti da li su softverski proizvod ili podaci koji su modifikovani za vreme migracije i dalje u skladu sa standardom SRPS ISO/IEC 1207.

.5.2 Plan migracije se izrađuje, dokumentuje i izvršava. U aktivnosti planiranja uključeni su i korisnici. Plan sadrži:

• a) analizu zahteva i definiciju migracije;• b) razvoj alata za migraciju;• c) konverziju softvera i podataka;• d) izvršenje migracije;• e) proveru migracije;• f) podršku za staro okruženje u budućnosti.

20/48

SRPS ISO/IEC 12207


.5.3 Korisnici se obaveštavaju o planovima migracije i aktivnostima migracije.

Obaveštenja sadrže:• a) Iskaz zašto se staro okuženje više ne podržava;• b) Opis novog okruženja i kada će biti na raspolaganju;• c) Opis drugih raspoloživih opcija za podršku, ako postoje,

kada se podrška starom okruženju povuče.

.5.4 Paralelni rad starog i novog okruženja može se sprovoditi radi lakšeg prelaza u novo okruženje.

Za vreme ovog perioda treba sprovesti neophodnu obuku, kako je utvrđeno ugovorom.

21/48

SRPS ISO/IEC 12207


.5.5 Kada se planirana migracija približi, mora se poslati svima zainteresovanim obaveštenje o tome.

Treba da se arhivira sva pripadajuća dokumentacija o starom okruženju, registri i kod.

.5.6 Posle korišćenja se obavi pregled kako bi se procenio uticaj prelaska u novo okruženje.

Rezultati pregleda moraju se poslati nadležnima radi informacije, upravljanja i akcije.

.5.7 Podaci koji su korišćeni ili povezani sa starim okruženjem moraju da budu dostupni u skladu sa zahtevima ugovora o zaštiti podataka i proverama koje se primenjuju na podatke.

22/48

SRPS ISO/IEC 12207

Proces održavanja – zadaci povlačenja softvera

.6 Povlačenje softvera. Softverski proizvod se povlači na zahtev vlasnika. Aktivnost se sastoji od sledećih pet zadataka:

.6.1 Plan povlačenja softvera kojim se uskraćuje aktivna podrška organizacija koje izrađuju i održavaju softver mora da se izradi i dokumentuje. Aktivnosti plana moraju da obuhvate i korisnike. Plan mora da sadrži niže navedene elemente. Plan mora da bude izvršen.

• a) Prestanak potpune ili delimične podrške posle izvesnog vremena;

• b) Arhiviranje softverskog proizvoda i pripadajuće dokumentacije;

• c) Odgovornost za bilo koju buduću podršku;• d) Prelaz na novi softverski proizvod, ako je primenjiv;• e) Mogućnost pristupa arhivskim kopijama podataka.

23/48

SRPS ISO/IEC 12207


.6.2 Korisnicima se upućuju obaveštenja o planu povlačenja softvera i aktivnostima.

Obaveštenja obuhvataju:• a) Opis zamene ili nadgradnje s naznakom datuma

raspoloživosti;• b) Izjavu o tome zašto se softverski proizvod ne može dalje

podržavati;• c) Opis drugih opcija za podršku koje stoje na raspolaganju,

kada podrška prestane.

.6.3 Paralelni rad softverskog proizvoda koji se povlači i novog softverskog proizvoda sprovodi se radi lakšeg prelaza na novi sistem. Tokom ovog perioda mora da se obezbedi obuka korisnika, kako je utvrđeno ugovorom. 24/48

SRPS ISO/IEC 12207


.6.4 Kada dođe vreme planiranog povlačenja, svima zainteresovanima se šalje obaveštenje o tome. Sva pripadajuća razvojna dokumentacija, registri i kod treba da se arhiviraju kada to bude pogodno.

.6.5 Podaci koji su korišćeni ili povezani sa povučenim softverskim proizvodom moraju da budu i dalje pristupačni u skladu sa zahtevima ugovora o zaštiti podataka i proverama koje se primenjuju na podatke.

25/48

SRPS ISO/IEC 12207

26


2 Osnovni pojmovi, definicije, koncepti,

proces održavanja softvera – aktivnosti – zadaci Klasični razvojni modeli softvera (IS održavanja – IV deo) Problem održavanja i evolucije softvera Evolutivni modeli održavanja softvera


27

Problem održavanja i evolucije Softver stalno evoluira, jer evoluiraju problemi koje on

rešava i realni sistemi koje modeluje. Potreba za posebnom pažnjom koju treba posvetiti

održavanju softvera najbolje se vidi kroz primere. Udeo cene održavanja softvera u ukupnoj ceni životnog ciklusa: - uvek preko 50% (varira zavisno od vrste softvera i načina merenja

troškova). Trend rasta udela cene održ. tokom vremena, može da iznosi preko 90%!

Zbog greške u računarskom sistemu za naplatu kazni vlasnicima kućnih ljubimaca, Toronto je 2000. godine izgubio oko 700 000 dolara jer je jedini inženjer koji je u potpunosti razumeo sistem otpušten nešto ranije u sklopu akcije smanjenja gradske administracije!

Otklanjanje “nasleđenih” problema, na primer, Y2K: - Nokia je potrošila oko 90 miliona dolara, a - vlada SAD čak oko 8,38 milijardi za otklanjanje Y2K...

28

Problem održavanja i evolucije Održavanje softvera podeljeno je na 4 tipa: Korektivno – ispravljanje bagova nastalih u nekoj fazi razvoja Adaptivno – prilagođavanje softvera promenama u okruženju

(operativni sistem, pravna regulativa, Y2K problem, hardver itd) Perfektivno – prilagođavanje izmenjenim korisničkim

zahtevima (poboljšanje performansi, nove funkcionalnosti, bolji interfejs)

Preventivno – aktivnosti čiji je cilj povećanje održivosti softverskog sistema (poboljšanje dokumentacije, komentarisanje i refaktorisanje koda).

Samo je korektivno održavanje održavanje u bukvalnom smislu, ostali tipovi se mogu podvesti pod evoluciju softvera.

29

Problem održavanja i evolucije Raspodela vremena i truda posvećenog održavanju po

tipovima (orijentacione vrednosti): plansko 50%, adaptivno 25%, korektivno 20% i perfektivno svega 5%.

Posebno je upadljiv mali udeo perfektivnog održavanja, iako je to jedini tip održavanja koji smanjuje kompleksnost koda i pozitivno utiče na održivost i dužinu životnog veka sistema.

Neophodna je daleko veća svest o značaju održavanja i održivosti softverskih projekata, kao i mogućnosti njihovog unapređivanja.

Ovo moraju znati kako programeri, tako i klijenti, a posebno menadžment softverskih projekata.

30

Problem održavanja i evolucije U softverskom inženjeringu su i dalje suviše česte pojave

koje su nezamislive u drugim inženjerskim oblastima (na primer, građevini ili mašinstvu):

- dizajnu, planiranju i testiranju - nedovoljna pažnja; - dokumentacija - često nije adekvatna; - održavanje se zanemaruje dok ne postane kritično, a

onda se sprovodi stihijski; - odluke o tehničkim pitanjima donose netehnička lica,

umesto inženjera. Sve ovo zbog specifične, apstraktne, prirode softvera, koja

stvara privid jednostavnosti realizacije bilo koje ideje. Razvojni modeli nisu primenljivi u održavanju softvera (nije

isto softver napraviti od nule ili dodati na postojeći sistem), a da bi se prevazišli opisani problemi, razvijeni su mnogi modeli procesa održavanja i evolucije softvera.

31


2 Osnovni pojmovi, definicije, koncepti,

proces održavanja softvera – aktivnosti – zadaci Klasični razvojni modeli softvera (IS održavanja – IV deo) Problem održavanja i evolucije softvera Evolutivni modeli održavanja softvera


32

Evolutivni modeli održavanja softvera Sledi opis nekih od najvažnijih modela održavanja softvera

i razvojnih modela koji posebnu pažnju obraćaju na evoluciju.

Reč je o sledećim modelima: 1- Brza popravka - Quick fix 2- Boehm-ov model - Boehm's model 3- Model iterativnog poboljšanja –

Iterative enhancement model 4- Model ponovnog iskorišćenja - Reuse oriented model 5- Model otvorenog izvornog koda - Open source model 6- Osborne-ov model - Osborne's model

33

Evolutivni modeli održavanja softvera

1 Brza popravka - Quick fix

Odgovara code and fix razvojnom modelu.

Jednostavan i brz – samo dve faze:otkrivanje i ispravljanje problema.

Ne predviđa analizu posledica izmene.

Koristi se i dalje za privremena, brza rešenja, zbog nedostatka resursa i vremena za zahtevnije modele.

Može biti efikasan za male sisteme, ali ga treba ga izbegavati a rešenja treba detaljno proveriti kasnije u sklopu nekog ozbiljnijeg modela.

34

Evolutivni modeli održavanja softvera2 Boehm-ov model - Boehm's model 1/2

Definišu se tri faze u životnom ciklusu softverskog sistema: – niska isplativost softvera, uglavnom se ispravljaju defekti

(Investment) – softver donosi veliku dobit, dodaju se nove funkcionalnosti

(High payoff) – sve manja dobit, isplativost izmena opada

(Diminishing returns)

35

Evolutivni modeli održavanja softvera2 Boehm-ov model - Boehm's model 2/2

Model je zasnovan na ekonomskim principima.

Izmene se odobravaju na osnovu analize isplativosti i svakoj se dodeljuje poseban budžet koji utiče na implementaciju.

Menadžer održavanja dređuje prioritete i budžet na osnovu ciljeva i ograničenja, pa on ima centralnu ulogu u ovom modelu.

Odluke menadžmenta su pokretač ciklusa.

36


Bazira se na ideji da izmene tokom životnog veka softvera treba dodavati na iterativan način.

Nastao od iterativnih razvojnih modela (spiral i sličnih). Svaka iteracija (realizacija jedne izmene) se sastoji od 3 faze:

1- analize, 2- karakterizacije predloženih izmena, 3- redizajna sistema i implementacije izmena.

Model može “obuhvatiti” neki jednostavniji (kao quick fix) koji se može primeniti kod potrebe za hitnom izmenom, dok se detaljnija analiza izmene i eventualne prepravke, kao i ažuriranje dokumentacije, ostavljaju za narednu iteraciju.

Model iterativnog poboljšanja - Iterative enhancement model (1/2)

37


U svakoj iteraciji analiza se oslanja na postojeću dokumentaciju, a redizajn sistema i implementacija izmene započinju njenim izmenama i to od vrha (tj. najopštijeg dokumenta) naniže, do samog koda.

U idealnom svetu, ovo bi funkcionisalo savršeno i ostavljalo ne samo prepravljen kod, već i uvek ažurnu dokumentaciju posle svake iteracije.

Model se primenjuje u slučajevima kada: - u realnosti ne postoji uvek potpuna i kvalitetna

dokumentacija o postojećem sistemu, - održavalac nema vremena za ažuriranje dokumentacije

u iterativnom postupku održavanja.

Model iterativnog poboljšanja - Iterative enhancement model (2/2)

38


Zasniva se na filozofiji ponovnog iskorišćavanja postojećih resursa.

Kandidati za re-upotrebu ne moraju biti samo komponente koda, već to može biti i deo dokumentacije, deo test podataka, skup znanja o domenu problema itd.

Postoje 4 glavna koraka u primeni ovog modela: 1- identifikacija delova postojećeg sistema čija je re-

upotreba moguća, 2- potpuno razumevanje tih delova, 3- njihova modifikacija u skladu sa novim zahtevima, 4- integracija modifikovanih delova u novi sistem.

4 Model ponovnog iskorišćenja - Reuse oriented model

39


U pitanju je pre filozofija nego model razvoja softvera. Često poenta nije u ceni, već u slobodi. Model razvoja je najčešće neka vrsta iterativnog u okviru

zajednice okupljene oko projekta, gde svako može postati član zajednice i doprineti napretku projekta (sav kod mora ostati javno dostupan).

Značaj release-ova je smanjen, jer je celokupan kod dostupan i pre i posle zvaničnog objavljivanja neke verzije, a najčešće ne postoji jedan klijent za koga se razvija softver.

Ne postoji jasna granica između razvoja i održavanja – proizvod se stalno unapređuje (Linux filozofija “release early, release often”).

5 Model otvorenog izvornog koda - Open Source model (1/3)

40


Softverski sistemi su sve složeniji, pa nije uvek jednostavno izmeniti kod, iako je Open Source svakom dostupan.

Korisnici (kompanije, organizacije) ne žele da izdvajaju resurse za samostalno unapređivanje i održavanje koda.

Postoje (uslužno-komercijalne) kompanije koje se bave pružanjem podrške za unapređivanje koda, obukom korisnika za Open Source projekte.

U smislu održavanja Open Source model je u prednosti utoliko što je svaki korisnik ne samo tester, već i potencijalni programer, što dovodi do bržeg pronalaženja i otklanjanja nedostataka.

Korisnici nisu zavisni od proizvođača softvera kada je održavanje u pitanju, jer imaju kompletan izvorni kod.


41


Značajna većina velikih softverskih kompanija ima neku vrstu Open Source licenciranja nekih ili svojih proizvoda (Sun, Google, pa i Microsoft).

Mnoge kompanije koriste Open Source projekte kao razvojne poligone za nove tehnologije koje uključuju u svoje (komercijalne) proizvode (OpenSuse - Suse, Fedora - Red Hat Enterprise Linux, OpenSolaris – Solaris itd).

Primeri najuspešnijih Open Source projekata: Firefox, OpenOffice, Linux...


42


Uzima u obzir realnost softverske industrije. Ne pretpostavlja postojanje idealnih uslova i svih neophodnih

preduslova za uspešno održavanje softverskog sistema (na primer, neograničene količine vremena ili potpune dokumentacije).

Osborne tvrdi da većina tehničkih problema u održavanju softvera nastaje zbog loše komunikacije sa menadžmentom i loše kontrole projekta i predlaže sledeće mere:

- uključivanje zahteva za održavanje u svaku izmenu, - postojanje jasnog programa kontrole kvaliteta softvera, - postojanje načina za proveru zahteva za održavanje, - stalan uvid menadžmenta u stanje projekta kroz redovne

prikaze (performance reviews).

6 Osborne-ov model - Osborne's model (1/3)

43


Slika prikazuje predloženi životni ciklus jedne izmene (od otkrivanja potrebe za izmenom do pojave izmene u produkcionoj verziji softvera).

Da bi se uzeli u obzir mogući propusti u prethodnim fazama razvoja i održavanja, ciklus uključuje mnoštvo povratnih petlji.

Moguće je i više iteracija kroz pojedine petlje. Na primer: tokom implementacije mogu se uočiti nedostaci

u komentarima i dokumentaciji, tokom testiranja moguće je otkrivanje nepoznatih problema koji dovode do novih zahteva za izmenu itd.

6 Osborne-ov model - Osborne's model (2/3)

44

Evolutivni modeli održavanja softvera6 Osborne-ov model - Osborne's model (3/3)

IT - Ž. Micić & stud.---/2014 FTN 45/48

Literatura

Домаћи задатак 3:

студент ---/2014

-студира дати материјал

-допуњује материјал (слајдове), литературу,

-презентира исти следећег часа

-предлаже контролна питања...

11 Aktivnosti studenata i kontrolna pitanja

IT - Ž. Micić & stud.---/2014 FTN 46/48

12 Literatura

[81] Dragan Bojić, Marko Mitrović, Evolucija softvera, Modeli procesa u održavanju i evoluciji softvera, Elektrotehnički fakultet u Beogradu, 2009.

[109] SRPS ISO/IEC 9126-1: 2011. Софтверски инжењеринг — Квалитет производа — Део 1: Модел квалитета

[110] SRPS ISO/IEC 12207: 1997. Informaciona tehnologija - Procesi životnog ciklusa softvera

osio_08.1_procesi_odrzavanja_softvera_2015.0_3.11

Documents