U ovoj lekciji obrađivaćemo:
- Lakoću održavanja
- Karakteristike i specifična merenja održavanja
- Aktivnosti procesa održavanja
- Tehnike održavanja
Procena troškova održavanja
Softver inženjeri moraju razumeti različite kategorije softverskog održavanja u cilju adresiranja pitanja procene troškova softverskog održavanja. Za svrhe planiranja, procena troškova je važan aspekt softverskog održavanja. ISO/IEC14764 navodi da su dva najpopularnija pristupa u procenjivanju resursa za softversko održavanje - korišćenje parametarskih modela i iskustava. Najčešće se koristi kombinacija ovih pristupa.
Merenja softverskog održavanja
Grady and Caswell [1] u svojim radovima, diskutuju uspostavljanje programa za merenje širokih primena u kompanijama. Praktična softverska i sistemska merenja (Practical Software and Systems Measurement (PSM)) opisuju tematski vođen proces merenja koji se koristi od strane mnogih organizacija.
Specifična merenja
Održavalac mora da odredi koja merenja su odgovarajuća za datu organizaciju. Standardi [IEEE1219-98; ISO9126-01] predlažu merenja koja su više specifična za softversko održavanje.
Ovo uključuje brojna merenja za svake od 4 podkarakteristike lakoće održavanja:
- Mogućnost analize - Merenja napora održavanja ili resursa potrošenih u pokušaju dijagosticiranja uzroka padova ili identifikovanju delova koji treba da se modifikuju
- Promenjivost - Merenja napora održavanja pridruženih implementaciji specificiranih modifikacija
- Stabilnost - Merenja neočekivanih ponašanja softvera, ukljućujući i ona koja se pojave prilikom testiranja
- Mogućnost testiranja - Merenja napora održavanja i korisničkih napora u pokušaju testiranja modifikovanog softvera
Proces održavanja
Podoblast „proces održavanja" prema SWEBOK-u pruža reference i standarde korišćene za implementaciju procesa softverskog održavanja. Tema aktivnosti održavanja razlikuje održavanje od razvoja i prikazuje njegovu povezanost sa ostalim aktivnostima softverskog inženjerstva.
Slika 1. ISO/IEC 14764-00 Software Maintenance Process
izvor: Guide to the SWEBOK
Aktivnosti održavanja
Mnoge aktivnosti održavanja su slične onima iz softverskog razvoja. Održavaoci takođe rade analize, dizajn, kodiranje, testiranje i dokumentaciju. Moraju pratiti zahteve na isti način kao što se radi u razvoju i ažuriranje dokumentacije. Standard ISO/IEC14764 preporučuje da, kada održavalac referiše neki sličan razvojni proces, mora da ga prilagodi radi ispunjena svojih specifičnih potreba. Medjutim, za softversko održavanje, neke aktivnosti uključuju procese jedinstvene samo za softversko održavanje.
Slika 2. Aktivnosti procesa održavanja
izvor: Guide to the SWEBOK
Jedinstvene aktivnosti
Postoji nekoliko procesa, aktivnosti i praksi koje su jedinstvene samo za softversko održavanje, kao na primer:
- Tranzicija - Kontrolisana i koordinirana sekvenca aktivnosti tokom kojih je softver transferisan progresivno od programera ka održavaocima
- Prihvatanje/Odbijanje zahteva za promenama - Zahtevi za promenama rade preko određenih veličina/napora/kompleksnosti i mogu biti odbijeni od strane održavaoca i preusmereni na programera
- Zahtev za promenama i izveštavanje o greškama - Pokreće se od strane krajnjeg korisnik, što pokreće za sobom i procenjivanje iznosa, dodelu prioriteta i koštanje zahteva za promenama
- Analiza uticaja
- Pomoć i savet korisnicima što se tiče zahteva za informacijama
Aktivnosti podrške
Održavaoci mogu da izvode i aktivnosti podrške kao što su:
- Planiranje softverskog održavanja
- Software Configuration Management (SCM)
- Verifikacija i validacija,
- Obezbeđenje kvaliteta softvera,
- Obuka održavaoca,
- Pregledi i provere,
- Korisnički trening.
Aktivnosti planiranja održavanja
Važna aktivnost za softversko održavanje je planiranje i održavaoci moraju razmotriti i teme vezane za brojne aktivnosti planiranja:
- Poslovno planiranje (na organizacionom nivou)
- Planiranje održavanja (na tranzicionom nivou)
- Planiranje puštanja verzija (na softverskom nivou)
- Planiranje individualnih zahteva za promenama (na nivou zahteva)
Ako razvoj softvera tipično traje nekoliko meseci ili nekoliko godina, faza održavanja obično traje mnogo godina. Pravljenje procena resursa je ključni element planiranja održavanja. Ovi resursi treba da budu uključeni u planiranje budžeta razvoja projekta. Planiranje održavanja treba da počne sa odlukom da se razvija novi sistem i treba da razmotri ciljeve kvaliteta. Potrebno je razviti koncept dokument, za kojim se radi i plan održavanja.
Koncept dokument za održavanje treba da obuhvati:
- Opseg softverskog održavanja
- Adaptaciju procesa softverskog održavanja
- Identifikaciju organizacije softverskog održavanja
- Procenu troškova softverskog održavanja
Planiranje izdavanja verzije
Planiranje izdavanja verzije zahteva da održavalac:
- Prikupi datume raspoloživosti individualnih zahteva
- Saglasnost sa korisnicima na sadržaju sledećih verzija
- Identifikuje potencijalne konflikte i razvija alternative
- Proceni rizik datog izdanja i razvije „plan povratka izdanja" u slučaju porasta problema
- Informiše sve zainteresovane učesnike
Tehnike održavanja
Ova podoblast predstavlja neke od generalno prihvaćenih tehnika korišćenih u softverskom održavanju.
- Razumevanje programa - Programeri troše značajno vreme u čitanju i razumevanju programa u cilju implementacije promena. Jasna i koncizna dokumentacija doprinosi razumevanju programa.
- Reengineering - Reengineering se definiše kao ispitivanje i preinačenje softvera radi uspostavljanja u novoj formi i uključuje naknadnu implementaciju u novoj formi. Reengineering je najradikalniji i najskuplji oblik preinačenja.
- Reverse engineering - Reverse engineering je proces analiziranja softvera radi identifikovanja softverskih komponenata i njihovih interrelacija i kreiranja reprezentacije softvera u drugoj formi. Reverse engineering je pasivan i ne menja softver. Reverse engineering proizvodi grafove poziva i kontrole toka iz izvornog koda. Jedan tip reverse engineering-a je redokumentacija, drugi tip je redizajn. Refaktorisanje je transformacija programa koja reorganizuje program bez promena njegovog ponašanja, i forma je reverse engineering-a koji nastoji da poboljša strukturu programa.
Za kraj, pogledajmo kako izgleda proces razvoja softvera opisan na interesantan način:
| Software Development Life
izvor: The Eye On Security Research Group India (www.eos-india.net)
- Programmer produces code he believes is bug-free.
- Product is tested. 20 bugs are found.
- Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
- Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
- See 3.
- See 4.
- See 5.
- See 6.
- See 7.
- See 8.
- Due to marketing pressure and an extremely pre-mature product announcement based on overly-optimistic programming schedule, the product is released.
- Users find 137 new bugs.
- Original programmer, having cashed his royalty check, is nowhere to be found.
- Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
- Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
- Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
- New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
- Programmer produces code he believes is bug-free....
|
Reference:
- R.B. Grady and D.L. Caswell, Software Metrics: Establishing a Company-Wide Program, Prentice Hall, 1987
