Mirëmbajtja e softuerit
Mirëmbajtja e softuerit ose en:Software maintenance në inxhinierinë softuerike është ndryshimi i një produkti softuerik pas lëshimit, për të përmirsuar ndonjë problem, për të përmirësuar performancën apo cilësi të tjera [1].
Një perceptim i zakonshëm i mirëmbajtjes është se përfshin vetëm rregullimin e defekteve (bug). Megjithatë, një studim tregoi se pjesa më e madhe, mbi 80%, e përpjekjeve të mirëmbajtjes është përdorur për qëllime jo-korrigjuese të veprimeve (Pigosky 1997) [2].
Çështjet kryesore të mirëmbajtjes softuerike janë dy, menaxhuese dhe teknike. Çështjet kryesore të menaxhimit janë: përafrimi me prioritetet e konsumatorëve, personelit, organizimi i të cilës bën mirëmbajtjen, vlerësimin e kostos. Çështjet kryesore teknike janë: kuptimi i kufizuar, analizat e ndikimit, testimi, matjen e gjendjes.
Koncepti i mirëmbajtjes
[Redakto | Redakto nëpërmjet kodit]Mirëmbajtja dhe përmirësimi i softuerit, procesi për tu përballur me problemet e reja të zbuluara ose kërkesat e reja mund të marrë më shumë kohë se sa fillimi i ndërtimit të një softueri. Jo vetëm që mund të jetë e nevojshme të shtoni kod që nuk përshtatet me dizajnin origjinal, por vetëm përcaktimi se sa softueri punon në një pikë të caktuar pasi është e përfunduar mund të kërkojë shumë përpjekje për kuptimin nga një inxhinier softuerik. Rreth 2/3 e punës së inxhinierisë softuerike është mirëmbajtja, por kjo statistikë mund të jetë konfuze. Një pjesë e vogël e saj është për përmirësimin e gabimeve. Pjesa më e madhe e mirëmbajtjes është shtimi i sistemit për të bërë funksione të reja, e cila në shumë mënyra mund të konsiderohet si punë e re. Inxhinieria civile, arkitektura dhe punët me konstruksione, mirëmbajtja kryhet me mënyrë të njëjtë[3].
Mirëmbajtja softuerike dhe evolucioni i sistemeve u drejtua së pari nga Meir M. Lehman në vitin 1969. Gjatë një periudhe prej njëzet vjetësh, hulumtimi e tij çoi në formulimin e "Ligjeve të Lehman për Inxhinieri softuerike" (Lehman 1997). Përfundimet kryesore të hulumtimit të tij përfshijnë atë që mirëmbajtja është me të vërtetë zhvillimi evolutiv dhe se vendimet e mirëmbajtjes janë ndihmuar nga të kuptuarit se çfarë ndodh me sistemet (dhe softuerët) me kalimin e kohës. Lehman tregoi se sistemet vazhdojnë të evoluojnë me kalimin e kohës.
Rëndësia e mirëmbajtjes të softuerit
[Redakto | Redakto nëpërmjet kodit]Në fund të viteve 1970, një studim i famshëm dhe të cituar gjerësisht nga Lientz dhe Swanson, ekpozoj një pjesë shumë të lartë të kostos së ciklit të jetës që janë duke u shpenzuar për mirëmbajtjen. Ata kategorizuan aktivitet të mirëmbajtjes në katër klasa:
- Adaptive - që kanë të bëjnë me ndryshimet dhe përshtatjes në gjendjen e softuerit
- Perfektive - akomodimin me ndryshimin ose kërkesat e reja të përdoruesve që preokupojnë në zgjerimin e funksioneve të softuerit
- Korrigjuese - që kanë të bëjnë me gjetjen e gabimeve dhe rregullimin e tyre
- Parandaluese - aktivitetet e shqetësuese që synojnë në rritjen e qëndrueshmërisë të softuerit dhe për të parandaluar problemet në të ardhmen
Anketa tregon se rreth 75% e mirëmbajtjes ishte në të dy llojet e para, ndërsa për korrigjimin e gabimeve rreth 21%. Shumë studime të mëvonshme tregojnë një madhësi të ngjashëm të problemit. Studimet tregojnë se kontributi i përdoruesi të fundit është vendimtar për analizat dhe grumbullimin e të dhënave sipas kërkesave të reja. Ky është shkaku kryesor i ndonjë problem gjatë evolucionit të softuerit dhe mirëmbajtjes. Pra, mirëmbajtja e softuerit është e rëndësishme sepse ajo konsumon një pjesë të madhe të shpenzimeve të përgjithshme të ciklit jetësor "lifecycle" dhe gjithashtu paaftësia për të ndryshimin në mënyrë më të shpejtë dhe të besueshëm do të thotë se mundësitë e biznesit janë të humbura [4] [5] [6].
Modeli i procesit të mirëmbajtjes të softuerit
[Redakto | Redakto nëpërmjet kodit]
Në procesin e mirëmbajtjes softuerike, përdoret termi ri-innxhinieri ose ri-ndërtimi i pjesëve të ndryshme të softuerit.
Modeli i procesit ka disa principe, për të implementuar këto principe, aplikohet një model i procesit që definon gjashtë aktivitete (të treguar në figurën djathtas). Në disa raste, këto aktivitete ndodhin në një sekuencë lineare, por kjo nuk është gjithmonë shkaku. Për shembull, mund të jetë inxhinieria e kundërt(të kuptuarit e punëve të brendshme të një programi) mund të ndodhë para se ristrukturimi i dokumentimit të fillojë.
Paradigma e ri-inxnxhinierisë është një model ciklik. Kjo do të thotë që secili nga aktivitetet e paraqitura si pjesë e modelit të mund të rishikohen. Për ndonjë cikël të veçantë, procesi mund të përfundojë pas çdo njërit prej këtyre aktiviteteve [7][8].
Referime
[Redakto | Redakto nëpërmjet kodit]- ^ ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance
- ^ http://www.cs.washington.edu/education/courses/cse403/11sp/lectures/lecture16-refactoring.pdf Pigosky (1997)
- ^ Fetaji, Bekim (2012). Software engineering (Manuscript).
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!),UEJL- Teotvë, Maqedoni - ^ Lientz B., Swanson E., 1980: Software Maintenance Management. Addison Wesley, Reading, MA
- ^ Lehman M. M., 1980: Program, Life-Cycles and the Laws of Software Evolution. In Proceedings of IEEE, 68, 9,1060-1076
- ^ Penny Grubb, Armstrong A. Takang, 2003: Software Maintenance: Concepts and Practice. World Scientific Publishing Company
- ^ Roger S. Pressman, Ph.D. (2001). Software engineering: a practitioner’s approach / Roger S. Pressman.—5th ed. New York: McGraw-Hill Higher Education. ISBN 0-07-365578-3.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!) - ^ "Kopje e arkivuar" (PDF). Arkivuar nga origjinali (PDF) më 22 gusht 2014. Marrë më 6 maj 2012.
{{cite web}}: Mungon ose është bosh parametri|language=(Ndihmë!)Mirëmbajtja CS1: Archived copy si titull (lidhja)
Lexime të tjera
[Redakto | Redakto nëpërmjet kodit]- Pigoski, Thomas M. (1996). Practical Software Maintenance. New York: John Wiley & Sons. ISBN 978-0-471-17001-3.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!) - Pigoski, Thomas M. Description for Software Evolution and Maintenance (version 0.5). SWEBOK Knowledge Area.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!) - April, Alain; Abran, Alain (2008). Software Maintenance Management. New York: Wiley-IEEE. ISBN 978-0470-14707-8.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!)Mirëmbajtja CS1: Emra të shumëfishtë: lista e autorëve (lidhja) - Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Software maintenance : effective practices for geographically distributed environments. New Delhi: Tata McGraw-Hill. ISBN 9780070483453.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!)Mirëmbajtja CS1: Emra të shumëfishtë: lista e autorëve (lidhja) - Grubb, Penny; Takang, Armstrong (2003). Software Maintenance. New Jersey: World Scientific Publishing. ISBN 9789812384256.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!)Mirëmbajtja CS1: Emra të shumëfishtë: lista e autorëve (lidhja) - Lehman, M.M.; Belady, L.A. (1985). Program evolution : processes of software change. London: Academic Press Inc. ISBN 0-12-442441-4.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!)Mirëmbajtja CS1: Emra të shumëfishtë: lista e autorëve (lidhja) - Page-Jones, Meilir (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. ISBN 0-917072-17-0.
{{cite book}}: Mungon ose është bosh parametri|language=(Ndihmë!)
Lidhje të jashtme
[Redakto | Redakto nëpërmjet kodit]- Journal of Software Maintenance Arkivuar 3 dhjetor 2010 tek Archive.today Transclusion error: {{En}} is only for use in File namespace. Use {{lang-en}} or {{in lang|en}} instead.
- Software Maintenance Maturity Model Arkivuar 7 qershor 2008 tek Wayback Machine Transclusion error: {{En}} is only for use in File namespace. Use {{lang-en}} or {{in lang|en}} instead.
- Software Product Development Transclusion error: {{En}} is only for use in File namespace. Use {{lang-en}} or {{in lang|en}} instead.