Održavanje softvera
| Razvojni ciklus softvera |
|---|
| Delatnost |
| Paradigme i modeli |
| Metodologije i okviri |
| Podrška discipline |
| Alati |
| Standardi i knjige |
Održavanje softvera u softverskom inženjerstvu je modifikacija softverskog proizvoda nakon stvaranja da ispravi greške, da bi poboljšali performanse ili druge atribute..[1][2]
Zajednička percepcija održavanja je da se samo uključuje vezivanje nedostataka. Međutim, jedna studija pokazala je da se preko 80% napora održavanja koristi za ne-korektivne akcije.[3] Ovo mišljenje su ovekovečili korisnici koji podnose probleme javljanja da je u stvarnosti funkcionalnost poboljšanja u sistemu. Novije studije stavile bag-pričvršćivanje bliže 21%.[4]
Istorija
[uredi | uredi izvor]Za održavanje softvera i evoluciju sistema se prvo obratio Meir M. Leman 1969. U periodu od dvadeset godina, njegova istraživanja dovela su do formulisanja Leman zakona (Leman 1997). Ključni nalazi njegovog istraživanja uključuju da je održavanje zaista evolutivni razvoj i da odluke održavanja su pomagale razumevanju šta se dešava sa sistemima (i softvera) tokom vremena. Leman je pokazao da je sistem nastavio da se razvija tokom vremena. Dok evoluiraju, oni rastu više kompleksno, osim ako se neka akcija kao što je refaktorisanje koda uzima da se smanji složenost.
U kasnim 1970-im, poznato i široko citirano studijsko istraživanje Lienc i Svanson, izložilo je veoma visok deo troškova životnog ciklusa koji se utrošio na održavanje. Aktivnosti održavanja su podeljene u četiri klase:
- Adaptivna - menjanje sistema da se nosi sa promenama u okruženju softvera (DBMS, OS)[5]
- Perfektna - implementacija novih ili izmenjenih potreba korisnika koje se tiču funkcionalnog poboljšanja softvera
- Korektivna - dijagnoze i ispravljanje grešaka, eventualno one koje pronađu korisnici[5]
- Preventivna - povećanje održavanja softvera i pouzdanosti kako bi se sprečili problemi u budućnosti[5]
Istraživanje je pokazalo da je oko 75% od napora održavanja bilo na prva dva tipa, i ispravljanje grešaka konzumira oko 21%. Mnogi kasniji studiji pokazuju sličnu veličinu problema. Studije pokazuju da doprinos krajnjeg korisnika je od ključne važnosti tokom novog prikupljanja podataka uslova i analize. I to je bio glavni uzrok problema tokom evolucije softvera i održavanje. Dakle, održavanje softvera je važno jer troši veliki deo ukupnih troškova životnog ciklusa i takođe nemogućnosti da brzo i pouzdano promenite softver i znači da su poslovne mogućnosti izgubljene. [6] [7] [8]
Značaj održavanja softvera
[uredi | uredi izvor]Ključna pitanja održavanja softvera su i menadžerska i tehnička. Ključna pitanja upravljanja su: usklađivanje sa prioritetima klijenata, osoblja, koje organizacija nema održavanja, procena troškova. Ključna tehnička pitanja su: ograničeno razumevanje, analiza uticaja, testiranje, merenje održavanje.
Održavanje softvera je veoma široka aktivnost koja uključuje korekciju grešaka, poboljšanja sposobnosti, brisanje zastarelih mogućnosti i optimizaciju. Zbog promena je neizbežna, moraju biti uspostavljeni mehanizmi za evaluaciju, kontrolu i pravljenjem izmena.
Dakle, sve što je urađeno da promeni softver nakon što je u funkciji smatra se radovima na održavanju. Cilj je da se očuva vrednost softvera tokom vremena. Vrednost se može poboljšati proširenjem baze klijenata, ispunjavanjem dodatnih zahteva, postaje lakši za korišćenje, efikasniji i zapošljava noviju tehnologiju. Održavanje može span za 20 godina, dok razvoj može biti 1-2 godina.
Planiranje održavanja softvera
[uredi | uredi izvor]Sastavni deo programa je održavanje, što zahteva precizni plan održavanja da bude urađen u toku razvoja softvera. To bi trebalo da precizira koliko će korisnici zahtevati izmene ili prijaviti problem. Budžet treba da obuhvati resurse i troškove. Nova odluka treba da bude upućena u razvoju svakog novog sistema funkcija i ciljeva kvaliteta. Održavanje softvera, koji može trajati 5-6 godina (ili čak decenija) nakon procesa razvoja, poziva na efektivan plan koji može obratiti obim održavanja softvera, zanat na post isporuke / raspoređivanja procesa, imenovanje ko će obezbediti održavanje i procenu troškova životnog ciklusa. Izbor pravilnog sprovođenja standarda je pravi izazov od rane faze softverskog inženjerstva koja nije dobila definitivan značaj od strane zainteresovanih strana.
Procesi održavanja softvera
[uredi | uredi izvor]Ovo poglavlje opisuje šest procesa održavanja softver kao:
- Proces implementacije sadrži softverske pripreme i tranzicione aktivnosti, kao što su koncepcije i stvaranje plana održavanja; priprema za rukovanje problema identifikovanih tokom razvoja; i praćenje o upravljanju konfiguracijom proizvoda.
- Proces analize problema i modifikacija, koja se izvršava nakon primene postala je odgovornost grupe održavanja. Programer održavanje mora da analizira svaki zahtev, potvrdi (za reprodukciju situacije) i proveri njegovu valjanost, istraži ga i predloži rešenje, dokumentuje zahtev i predlog rešenja, i konačno, dobije sva potrebna ovlašćenja da primeni izmene.
- Proces s obzirom na primenu same modifikacije.
- Prihvatanje procesa modifikacije, potvrđujući modifikovan rad sa pojedincem koji je podneo zahtev kako bi bili sigurni da je modifikacija bezbedno rešenje.
- Proces migracije (platforma migracije, na primer) je izuzetan, i nije deo svakodnevnih zadataka održavanja. Ako program mora biti promenjen na drugu platformu, bez bilo kakve promene u funkcionalnosti, ovaj proces će se koristiti i projekat održavanja tima će verovatno biti dodeljen ovom zadataku.
- Konačno, poslednji proces održavanja, takođe događaj koji se ne javlja svakodnevno, je penzionisanje komada softvera.
Postoji veliki broj procesa, aktivnosti i prakse koje su jedinstvene za održavaoca, na primer:
- Tranzicija: kontrolisana i koordinirana sekvenca aktivnosti tokom kojih je sistem prenesen progresivno od programera do održavaoca;
- Service Level Agreements (SLAs) i specijalizovanog (Domain-Specific) ugovora o održavanju dogovorene sa maintainers;
- Izmena zahteva i Problem prijave pomoći : proces problema rukovanja koristi održavaoca kao prioritet, dokumenta i putem zahtevima koje primaju;
Kategorije održavanja u ISO/IEC 14764.
[uredi | uredi izvor]E. B. Svanson, prvobitno identifikovane tri kategorije održavanja: korektivnu, adaptivnu, i perfektivnu.
- Interventno održavanje: reaktivna modifikacija softvera proizvoda vrši se nakon isporuke da ispravi otkrivene probleme.
- Adaptivno održavanje: Modifikacija softverskog proizvoda obavlja se nakon isporuke kako bi softverski proizvod bio upotrebljiv u izmenjenom ili promenljivom okruženju.
- Perfektno održavanje: Modifikacija softverskog proizvoda nakon isporuke za poboljšanje performansi ili sposobnosti snabdevanja.
- Preventivno održavanje: Modifikacija softverskog proizvoda nakon stvaranja za otkrivanje i ispravljanje latentnih grešaka u softverskom proizvodu pre nego što postanu efektivne greške.
Tu je i pojam pre isporuke / pre puštanja održavanja koji sve dobre stvari koje radite da smanji ukupne troškove vlasništva softvera. Stvari kao u skladu sa kodiranjem standarda koji uključuje softver održavanja ciljeva. Upravljanje spojnicama i kohezija softvera. Postizanje softverskih mogućnosti podrške ciljeva (SAE JA 1004 JA 1005 i 1006 JA na primer). Postizanje softverskih mogućnosti podrške ciljeva. Imajte na umu da neke akademske institucije vrše istraživanja kvantifikovati troškova za tekuće održavanje softvera, zbog nedostatka sredstava, kao što su projektne dokumentacije i sistem / Softver razumevanja obuke i resursa (pomnožite troškove za oko 1.5-2.0 gde. nema dizajn raspoloživih podataka).
Faktori održavanja
[uredi | uredi izvor]Uticaj ključnih faktora prilagođavanja na održavanju (razvrstanih u cilju maksimalnog pozitivnog uticaja)
| Faktori održavanja | Plus opseg |
|---|---|
| Specijalisti održavanja | 35% |
| Visoko iskustvo osoblja | 34% |
| Promenljive i podaci tabele | 33% |
| Niska složenost baze koda | 32% |
| Y2K i specijalni pretraživači | 30% |
| Alati za restrukturiranja koda | 29% |
| Reinženjerski alati | 27% |
| Programski jezici na visokom nivou | 25% |
| Alati za inženjerski preokret | 23% |
| Alati za složenost analize | 20% |
| Alati defekta praćenja | 20% |
| Y2K “Masovna ažuriranja” specijalisti | 20% |
| Alati za automatsku kontrolu promene | 18% |
| Neplaćeni prekovremeni rad | 18% |
| Merenja kvaliteta | 16% |
| Formalna baza koda inspekcije | 15% |
| Regresija test biblioteke | 15% |
| Odlično vreme odziva | 12% |
| Godišnja obuka> 10 dana | 12% |
| Visoko iskustvo menadžmenta | 12% |
| Šalter informacija automatizacije | 12% |
| Nema modula sklonih greškama | 10% |
| U prodaji izveštavanje defekta | 10% |
| Produktivnost merenja | 8% |
| Odlična lakoća upotrebe | 7% |
| Merenja zadovoljstva korisnika | 5% |
| Visoki timski moral | 5% |
| Zbir | 503% |
Ne samo da su greškama skloni moduli problematično, ali mnogi drugi faktori mogu degradirati performanse previše. Na primer, veoma kompleksni "špageti kod" je prilično teško da se bezbedno održava. Veoma česte situacije koje često degradiraju performanse je nedostatak odgovarajućih alata za održavanje, kao što su praćenje defekta softvera, upravljanje promenama softvera, i testa biblioteka softvera. Ispod opisuje neke od faktora i raspon uticaja na održavanja softvera.
Uticaj ključnih faktora prilagođavanja na održavanju (razvrstanih u cilju maksimalnog negativnog uticaja)
| Faktori održavanja | Minus opseg |
|---|---|
| Moduli skloni greškama | -50% |
| Ugrađene promenljive i podaci | -45% |
| Neiskustvo osoblja | -40% |
| Visoka kompleksnost koda | -30% |
| Nema Y2K posebnih pretraživača | -28% |
| Ručne metode kontrole promena | -27% |
| Programski jezici niskog nivoa | -25% |
| Nema alata za praćenje defekta | -24% |
| Nema Y2K "Masovna ažuriranja" | -22% |
| Slaba jednostavnost upotrebe | -18% |
| Nekvalitet merenja | -18% |
| Nema specijalista za održavanje | -18% |
| Loše vreme odziva | -16% |
| Nema koda inspekcije | -15% |
| Nema regresije testa biblioteke | -15% |
| Nema šaltera informacija automatizacije | -15% |
| Nema onlajn izveštavanje defekta | -12% |
| Menadžment iskustvo | -15% |
| Nema alati za restrukturiranje koda | -10% |
| Ne godišnja obuka | -10% |
| Nema alata reinžinjeringa | -10% |
| Nema alata za inženjerski preokret | -10% |
| Nema alata za složenost analize | -10% |
| Ne merenje produktivnosti | -7% |
| Slab timski moral | -6% |
| Nema merenja zadovoljstva korisnika | -4% |
| Ne neplaćeni prekovremeni rad | 0% |
| Zbir | -500% |
Vidi još
[uredi | uredi izvor]- Aplikacija za penzionisanje
- ''Journal of Software Maintenance and Evolution: Research and Practice''
- Dugoročna podrška
- Arheologija softvera
- Održavalac softvera
- Razvoj softvera
- Softverski dizajn
- Debagovanje
- Softversko raspoređivanje
- Analiza zahteva
- Konstrukcija softvera
- Testiranje softvera
- Razvojni ciklus softvera
- Softversko ineženjerstvo
Reference
[uredi | uredi izvor]- ^ „ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance”. Iso.org. 17. 12. 2011. Pristupljeno 2. 12. 2013.
- ^ Pigoski, Thomas. „Chapter 6: Software Maintenance” (PDF). SWEBOK. IEEE. Pristupljeno 5. 11. 2012.
- ^ Pigoski, Thomas M., 1997: Practical software maintenance: Best practices for managing your software investment.
- ^ Eick, S., Graves, T., Karr, A., Marron, J., and Mockus, A. 2001.
- ^ a b v Software Maintenance and Re-engineering, CSE2305 Object-Oriented Software Engineering
- ^ Lientz B., Swanson E., 1980: Software Maintenance Management.
- ^ Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution.
- ^ Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice.
- ^ „E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, (1976). str. 492 — 497”. Portal.acm.org. doi:10.1145/359511.359522. Pristupljeno 2. 12. 2013.
- ^ „The Economics Of Software Maintenance In The Twenty First Century” (PDF). Arhivirano iz originala (PDF) 19. 3. 2015. g. Pristupljeno 2. 12. 2013.
Literatura
[uredi | uredi izvor]- ISO/IEC 14764 IEEE Std 14764-2006 Software Engineering — Software Life Cycle Processes — Maintenance. 2006. ISBN 978-0-7381-4960-8. doi:10.1109/IEEESTD.2006.235774.
- Pigoski, Thomas M. (1996). Practical Software Maintenance. New York: John Wiley & Sons. ISBN 978-0-471-17001-3.
- Pigoski, Thomas M. Description for Software Evolution and Maintenance (version 0.5). SWEBOK Knowledge Area.
- April, Alain; Abran, Alain (2008). Software Maintenance Management. New York: Wiley-IEEE. ISBN 978-0-470-14707-8.
- Ramesh, Gopalaswamy; Bhattiprolu, Ramesh (2006). Software maintenance : effective practices for geographically distributed environments. New Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3.
- Grubb, Penny; Takang, Armstrong (2003). Software Maintenance. New Jersey: World Scientific Publishing. ISBN 978-981-238-425-6.
- Lehman, M. M.; Belady, L. A. (1985). Program evolution : processes of software change. London: Academic Press Inc. ISBN 978-0-12-442441-8.
- Page-Jones, Meilir (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. ISBN 978-0-917072-17-8.
