priežiūros matavimas ir kokybės įvertinimas

PriePriežiūros procesai ir modeliai.žiūros procesai ir modeliai.PaveldPaveldėėtintinės sistemosės sistemos

Prof. Vytautas Štuikys [email protected]

Prof. Robertas Damaševičius [email protected]

Priežiūros procesai ir modeliai 2

Turinys

• Terminai ir motyvacija • Priežiūros procesas ir jo modeliai

– Tradiciniai projektavimo modeliai – Priežiūrą įvertinantys modeliai (Maintenance-aware models)

• Priežiūros modelių apibūdinimas– Greito taisymo (Quick-fix model)– Boehm’o modelis (Boehm’s model)– Osborne's Model– Interaktyvaus gerinimo (Iterative Enhancement Model)– Pakartotine panauda grindžiamas (Reuse-Oriented Model)– Versijų pakopų modelis (Versioned staged model)– IEEE standartų modeliai


Apibrėžtys

• Procesas – veiksmų seka, skirta tam tikram pakeitimui atlikti (the progress or course taken, methods of operation, a series

of actions taken to effect a change)

• Proceso modelis – abstraktus veiksmų sekos atvaizdavimas

• PĮ priežiūros procesas – veiksmų seka skirta atlikti keitimus sistemą prižiūrint

• PĮ priežiūra - Trumpalaikiai keitimai sistemoje (day-to-day

changes)

• PĮ tobulinimas – procesų nagrinėjimas ilgalaikėje perspektyvoje (what happens to software long-term, during its

entire life span)


Keitimų reikalavimų nustatymasKeitimų reikalavimų nustatymas

• Iš anksto nustatyti, kokie bus reikalavimai sistemai keisti, yra labai sunku

• Reikalavimai ir vartotojo problemos paaiškėja dažniausiai tik tada, kai sistema naudojama.

• Daugelis vartotojų žino ko nori, bet neturi gebėjimų paversti savo norus į tokią formą, kuri būtų suprantama analitikui ar programuotojui.

• Taip yra dėl taip vadinamos informacinės spragos ('information gap‘)


Tradicinių procesų modelių pritaikymas

• Programų priežiūros/tobulinimo modeliai buvo kuriami vienalaikiai su PĮ ir kompiuterijos mokslo evoliucija

• Žinojimas ar pažinimas su priežiūra siejamų dalykų dar neseniai buvo žemas

• PĮ priežiūra, kaip studijų sritis, yra nauja lyginant su PĮ projektavimu

• Proceso gyvavimo ciklo modeliai buvo tobulinami jau žinant PĮ projektavimo modelius

• Įtaka buvo neišvengiama ir iš tikrųjų kai kurie priežiūros modeliai yra adaptuoti projektavimo modeliai


Kai kurie tradiciniai modeliai

• Daug PĮ proceso modelių su tam tikromis ypatybėmis

• Pavyzdžiai : – Kodavimo-pataisymo (code-and-fix)– Krioklio (waterfall)– Spiralinis (spiral)– Inkrementinis

.


Code-and-fixCode-and-fix modelis

• Code-and-fix (koduoti-taisyti klaidas klaidas)

• Tai yra ad hoc modelis• Neformalizuotas• Sudaro 2 etapai

– 1) Rašyti kodą– 2) Taisyti kodą


Kodavimo-fiksavimo modelio įvertinimas

• Fiksavimas čia suprantamas kaip klaidų koregavimas (ištaisymas) ar funkcionalumo išplėtimas. Naudojant modelį, kodas greitai tampa sunkiai koreguojamu ir sunkiai gerinamu (unfixable and unenhanceable).

• Yra labai maža laisvės analizuoti, pritaikyti įvairius projektavimo proceso aspektus detaliai, struktūrizuoti

• Sunku palikti erdvės ateities išplėtimams • Klaidų skaičius didėja, priežiūra sunkėja


Krioklio modelis

• Sudaro prielaidas daryti klaidas specifikacijoje, o jas aptikti vėlesnėse stadijose per grįžtamąjį ryšį

• Daro prielaidą, kad tam tikras etapas baigsis be klaidų, kas yra nerealu

• Klaidos aptinkamos vėlesnėse stadijose

• Neįvertina PĮ evoliucinę prigimtį

Krioklio modelisKrioklio modelis

• Trūkumai:• Nelankstus projekto skirstymas į stadijas;• Yra sunkumų, kai reikia taisyti klaidas arba reaguoti į vartotojo

reikalavimų pasikeitimą;• Vykstant procesui, sunku daryti pakeitimus, paprastai jie atliekami

po paskutinės fazės, grįžtant į kurią nors fazę;• Privalumai:• Lengvai diegiamas, kadangi jo struktūra yra paprasta;• Procesas aiškus, lengvai koordinuojamas;• Lengvai valdomi projekto bei jo etapų terminai.• Tikslinga taikyti nedideliuose projektuose, kai vartotojo reikalavimai

yra iš anksto apibrėžti bei uždavinys yra gerai žinomas arba nesudėtingas.



PĮ evoliucinis/spiralinis modelis

• Spiralės modelis• Sudėtinga suderinti su

priežiūros personalui keliamais reikalavimais

• Griežti laiko ribojimai neleidžia atlikti rizikos įvertinimo

Inkrementinis modelisInkrementinis modelis

• Modelio veikimo principas yra „krioklio“ modelio iteracijų sujungimas. Kiekviena iteracija – veikianti projekto dalis. – Pirmoji iteracija - bazinis produktas, atsižvelgiant į pagr. reikalavimus.

– Sekanti iteracija yra bazinio produkto plėtimas arba atskiro komponento sukūrimas.


Inkrementinis modelisInkrementinis modelis

• Trūkumai:– Sunku apibrėžti projekto vykdymo terminus;– Dažnai gali keistis projekto tikslas bei apimtis;– Ilgas projekto vykdymo laikotarpis, kadangi kiekvieną kartą

sukūrus naują iteraciją yra planuojamas sekantis projekto plėtimas.

• Privalumai:– Leidžia vartotojui įvertinti produktą pradinėse stadijose;– Klaidų taisymas yra žymiai efektyvesnis, kadangi produktas gali

būti tikrinamas kiekvieną kartą sukūrus naują iteraciją;– Paprasčiau valdyti riziką, kadangi rizikos veiksniai yra

identifikuojami kiekvieną kartą sukuriant naują iteraciją.


Evoliuciniai modeliaiEvoliuciniai modeliai

• Evoliucinis modelis grindžiamas evoliucinio sistemų kūrimo paradigma.

• Iteratyvus, progresyviai sudėtingėjančių PS versijų kūrimo principas.

• Užsakovui sistema pateikiama ne iš karto, bet pateikiant jos branduolį ir prieaugius (angl. increments).

• Taikoma kai:• Kuriamos PS reikalavimai dažnai keičiasi ir klasikiniai

modeliai nepasiteisina;• Aiškūs tik pagr. produkto reikalavimai, tačiau produkto

išplėtimo detalės dar ne.



Priežiūrą įvertinantis (“Maintenance-aware” life-cycle)


“Maintenance-aware” model

• Panašus į tradicinius modelius• Skirtumai:

– Daugiau pastangų dedama priežiūros poreikių numatymui ankstyvosiose stadijose, kad vėlyvosiose stadijose būtų taupomi laikas ir resursai


Priežiūros proceso modeliai

• Greito-pataisymo (Quick-fix model)• Boehm’o modelis (Boehm’s model)• Osborno Model (Osborne's Model)• Iteracinio gerinimo (Iterative Enhancement Model)• Pakartotine panauda grindžiamas (Reuse-

Oriented Model)• Versijų pakopomis grindžiamas (Versioned

staged model)• IEEE standartų modeliai


Quick-Fix model (gaisro gesinimo modelis)

• Analogiškas Code-and-fix modeliui, tik taikomas programų priežiūrai• Remiasi „gaisro gesinimo“, kai atsiradus problemai stengiamasi kuo greičiau ją išspręsti•Pataisymai atliekami be ilgalaikio poveiklio analizės nenumatant pakeitimų sklaidos (ripple effects) poveikio kitoms PS dalims•Dokumentuojama mažai•Paprastai naudojama, kai sistemą kūrė ir prižiūri tas pats žmogus


Boehm’o modelio aprašas

• Boehm modelis (1983) remiasi ekonominiais modeliais ir principais

• Šie modeliai ne tik leidžia pagerinti našumą bet ir padeda suprasti priežiūros procesą

• Priežiūros procesas – uždaras ciklas, kuriame priežiūros veiksmus apsprendžia vadybiniai sprendimai

• Keitimai patvirtinami atlikus kaštų analizę ir taikant tam tikrą strategiją

• Patvirtintiems keitimams priskiriami reikalingi resursai ir biudžetas


Osborne modelis

• Remiasi kokybės užtikrinimo reikalavimais

• Į pokyčių specifikaciją įtraukiami priežiūros reikalavimai

• Yra priemonės skirtos patikrinti, ar priežiūros tikslai buvo pasiekti

• Atliekamos peržiūros ir teikiamos ataskaitos vadybininkams (grįžtamasis ryšys)


Įteratyvaus tobulinimo modelis

• Trijų pakopų ciklas– Analizė– Siūlomų keitimų specifikavimas– Rekonstravimas ir realizavimmas

• Reikalauka pilnos dokumentacijos prieš pradedant keitimus

• Kiekvieno etapo dokumentacija (reikalavimų spec., modeliai, testavimo dok. tr t.t.) atnaujinama

• Keitimai „paskleidžiami“ visoje keičiamoje sistemoje ir jos dokumentacijoje


Pakartotine panauda grindžiamas modelis (Reuse-Oriented Model)

• Identification of the parts of the old system that are candidates for reuse

• Understanding these system parts• Modification of the old system parts appropriate to the new

requirements• Integration of the modified parts into the new system

Capability Maturity modelisCapability Maturity modelis

• A maturity model describes to what extend a process model is used in an organization.

• The capability maturity model developed by the Software Engineering Institute (SEI) defines five levels of maturity of processes:– 1. Initial: ad hoc software process– 2. Repeatable: basic processes are established (tracking costs,

scheduling, . . . )– 3. Defined: processes are documented and standardized– 4. Managed: measures of the quality of the process– 5. Optimized: continuous evaluation and use of the quantitative

feedback of projects



Paprastas pakopinis modelis (Simple staged model)

K. H. Bennett V.T Rajlich, 2000, Software Maintenance and Evolution: a RoadmapK. H. Bennett, SOFTWARE EVOLUTION AND THE STAGED MODEL OF THE SOFTWARE LIFECYCLE

• Architecture and team knowledge make evolution (substantial changes without loss of integrity) possible.

• No longer evolvable system enters stage of servicing (maturity) - only small changes (patches, code changes and wrappers) - transition irreversible.

• Phase-out, no more servicing is being undertaken, but the system still may be in use. Users must work around deficiencies.

• Close-down , the software use is disconnected and the users are directed towards a replacement

• Aim: keep a system within a particular stage for as long as possible


Aptarnavimo pakopa (Servicing stage)

• Only minor corrections, enhancements and preventative work should be undertaken

• Senior designers and architects do not need to be available

• The staff do not require the same level of domain engineering or software engineering expertise

• Tools and processes are very different• A typical engineer will be assigned only part of the

software to support, and thus will have partial knowledge of the system.

• The process is (or should be) now stable, well understood and mature. Its iterative nature means it is well suited to process improvement, and measurement.

• Accurate cost prediction is needed.


Versijomis grįstas pakopinis modelis (Versioned staged model)

SMmm (SMmm (SOFTWARE SOFTWARE MAINTENANCE MATURITY MAINTENANCE MATURITY

MODELMODEL))• Panašus į CMMi

modelį• Remiasi gera

praktika


Alain April, Jean-Marc Desharnais, SOFTWARE MAINTENANCE MATURITY MODEL (SMmm): A SOFTWARE MAINTENANCE PROCESS MODEL


Maintenance process model (IEEE 1219 Standard for Software MaintenanceStandard for Software Maintenance)

• Starts the software maintenance effort during the post-delivery stage and discusses items such as planning for maintenance and metrics outside the process model. – Problem identification – Impact analysis – Design – Implementation– System testing– Acceptance– Delivery


ISO/IEC 14764-00 Priežiūros Proceso Modelis


ISO/IEC 14764-00 Software Maintenance Process Model

• ISO/IEC FDIS 14764 is an elaboration of the maintenance activity from ISO/IEC 12207

• ISO/IEC 14764-00 defines the following activities:– Process Implementation– Problem and Modification Analysis– Modification Implementation– Maintenance Review/Acceptance– Migration– Software Retirement

• Activities of the maintenance process are similar although they are aggregated a little differently.


Santrauka ir įgytos žinios(1)

• Tradiciniai gyvavimo ciklo modeliai neįvertina PĮ evoliucionuojančią prigimtį, t.y. PĮ turi tendenciją keisti ar būti keičiama

• PĮ Priežiūros modeliai gali būti sukurti remiantis tradiciniais PĮ proceso modeliais

• Pagrindiniai PĮP modeliai: – Greito pataisymo modelis remiasi ad hoc principu, Tai gaisro

gesinimo būdas (fire-fighting approach);– Iteracinio pagerinimo modelis pagrįstas iteraciniais sistemos

keitimais– Pakartotinės panaudos modelis mato (akcentuoją) komponentų

atkartojimą sukuriant naujus (komponentinis atkartojimas)

– Pakopiniai modeliai pateikia naujas pakopas kaip aptarnavimą– IEEE standartų modelis yra išvestinis, kitų modelių

apibendrinimas


Santrauka ir įgytos žinios (2)

• Modeliai turi savo skirtumų. Vieni orientuoti į ekonominius aspektus, kiti į produktus, treti į procesus.

• Visi modeliai turi stipriąsias ir silpnąsias puses. • Nėra modelio kuris tiktų visoms situacijoms. Modelių

kombinacija galėtų būti geriausias sprendimas


Šaltiniai

• Pagrindinis:• Penny Grubb, Armstrong A. Takang. Software Maintenance:

Concepts and Practice. World Scientific Publishing Company; 2 ed., 2003.

• Papildomi:• Bill Blunden. Software Exorcism: A Handbook for Debugging and

Optimizing Legacy Code. Apress, 2003.• Diomidis Spinellis. Code Quality: The Open Source Perspective.

Addison Wesley Professional, 2006.• Stan Jarzabek, Effective software maintenance and evolution : a

reuse‑based approach. Taylor & Francis Group, LLC, 2007.

Paveldėtinės sistemos

Paveldėtosios (liktinės) sistemos Paveldėtosios (liktinės) sistemos ir jų įvertinimo modelisir jų įvertinimo modelis

(Legacy systems)


TurinysTurinys

• Tikslas, terminologija, paveldėtų sistemų atributai

• Paveldėtų sistemų struktūra• Paveldėtų sistemų (PS) duomenų struktūra• Kokybės modelis• Verslo vertės ir PS kokybės įvertinimas


TikslaiTikslai

• Išsiaiškinti, kas yra paveldėtoji sistema, ir kodėl šios sistemos yra tokios svarbios

• Įvesti žinomas paveldėtųjų sistemų struktūras• Išaiškinti, kaip gali būti įvertinta paveldėtųjų

sistemų vertė


Kas yra paveldėtoji (legacy) Kas yra paveldėtoji (legacy) sistema?sistema?

• Termino “legacy” išaiškinimas (Oxford English Dictionary)– A sum of money, or a specified article, given to another

by will; anything handed down by an ancestor or predecessor. T.y., testamentu paveldėtas turtas.

• A legacy system is a piece of software that: – 1) you have inherited, and– 2) is valuable to you.


Paveldėtosios sistemosPaveldėtosios sistemos

• Sistemos, kurios yra kuriamos specialiai tam tikrai organizacijai ir kurios gyvuoja pakankamai ilgai

• Daugelis naudojamų sistemų buvo sukurtos labai seniai naudojant pasenusias technologijas

• Tačiau tos sistemos vis dar reikalingos normaliai organizacijos veiklai užtikrinti

• Todėl jos yra vadinamos paveldėtosiomis sistemomis, paveldo sistemos (legacy systems)

• Pavedėtosios sistemos – šio kurso nagrinėjimo objektas

ProblemosProblemos

• Sistemos kūrėjai nepasiekiami• Sistema sukurta pasenusiais metodais• Sistema patyrė intensyvias modifikacijas ir

taisymus• Dokumentacijos nėra arba ji neatnaujinta



Paveldėtųjų (Paveldėtųjų (legacylegacy) sistemų ) sistemų atributaiatributai

• Svarbios įmonei• paprastai labai senos• plačiai modifikuotos• pagrįstos sena technologija• sistemos kūrėjų jau nebėra• labai brangi priežiūra• Sprendimai

– viską palikti taip, kaip yra– sukurti naują sistemą– rekonstruoti seną sistemą


Paradigmų / technologijų pasikeitimas

• Yra didelis skaičius sistemų, kurios suprojektuotos ir realizuotos naudojant senas technologijas

• COBOL (Common Business Oriented Language) – programavimo kalba, sukurta 1959-1960 metais daugiausiai finansinių uždavinių sprendimui, naudojama bankų IS

• Fortran, sukurta 1957 m., tinka įvairiems sudėtingiems matematiniams apskaičiavimams, tebėra plačiai naudojama.

• Pasenusio naudojamo kodo kiekis– Viso: 1 trilijonas eilučių (2001), iš jų C/C++: 180 mlrd., Assembler: 140-220 mlrd.,

COBOL: 225 mlrd. (vertė 2 mlrd. $)

• Programuotojų skaičius: – viso 14.6 mln (2009), COBOL: 1.5 - 2 mln. (2008).

• 200 kartų daugiau Cobol transakcijų nei Google paieškų, 75% vis7 verslo transakcijų

• Bendroji problema: “Pasenusios paradigmos dirbančioms (gyvybingoms) sistemoms”


Paveldėtosios sistemos Paveldėtosios sistemos pakeitimaspakeitimas

• Yra didelė rizika pakeisti paveldėtąją sistemą naujai sukurta sistema– paveldėtos sistemos retai turi pilną specifikaciją. – Verslo procesai naudoja paveldėtąją sistemą– Naujos sistemos kūrimas gali būti nesėkmingas


Paveldėtosios sistemos keitimasPaveldėtosios sistemos keitimas

• Sistemos turi keistis, kad išliktų naudingos• Paveldėtų sistemų keitimas yra labai brangus

– Nėra vieningo programavimo stiliaus: skirtingos dalys buvo sukurtos skirtingų grupių

– Sistema galėjo būti sukurta pasenusia programavimo kalba

– Sistemos struktūra gali būti sugadinta– Priemonės, skirtos atminčiai taupyti arba greičiui

didinti, sumažino suprantamumą– Failų struktūros gali būti nesuderinamos


Paveldėtųjų sistemų struktūraPaveldėtųjų sistemų struktūra

• Paveldėtosios sistemos nėra paprastos programos ir gali būti laikomos socio-techninėmis sistemomis– Sisteminė aparatūra - gali būti net didieji kompiuteriai-

mainframe

– Palaikanti programinė įranga - operacinės sistemos ir tarnybinės programos

– Taikomosios programos

– Duomenys - naudoja taikomosios programos

– Verslo procesai - procesai, kurie remiasi paveldėtosiomis sistemomis

– Verslo taisyklės - apribojimai verslo operacijoms


Paveldėtųjų sistemų komponentai Paveldėtųjų sistemų komponentai (srities modelis)(srities modelis)

Palaikymoprogramos

Sisteminėaparatūra

Taikomosiosprogramos

Duomenys

Verslotaisyklės

Versloprocesai

Naudoja

Naudoja

Apriboja

Naudoja Apima žinias

VeikiaVeikia


Socio-techninės sistemos Socio-techninės sistemos sluoksniuotasis modelissluoksniuotasis modelis

Verslo procesai

Taikomosios programos

Palaikanti programinė įranga

Aparatūra


Sistemos keitimasSistemos keitimas

• Teoriškai įmanoma pakeisti lygmenį sistemoje neliečiant kitų lygmenų

• Praktiškai tai yra neįmanoma– Vieno lygmens keitimas įneša naujas priemones ir

aukštesnieji lygmenys turi pasikeisti, kad galėtų šias priemones naudoti

– Programų keitimas gali sulėtinti sistemą, todėl gali reikėti pakeisti ir aparatūrą

– Dažnai neįmanoma prižiūrėti aparatūrinių sąsajų dėl jų nesuderinamumo


Paveldėtieji duomenysPaveldėtieji duomenys

• Duomenys gali būti saugomi nesuderinamuose failuose.– Reikiamas pakeitimas: perėjimas prie duomenų bazės

• Paveldėtoji sistema gali naudoti pasenusią duomenų bazės valdymo sistemą



• Dauguma paveldėtųjų sistemų buvo sukurtos dar prieš atsirandant objektiniam projektavimui

• Paveldėtosios sistemos dažniausia buvo kuriamos naudojant funkcinio projektavimo metodus


Paveldėtų sistemų įvertinimasPaveldėtų sistemų įvertinimas

• Organizacijos, naudojančios paveldėtąsias sistemas, turi pasirinkti šių sistemų evoliucijos strategiją– visiškai atsisakyti sistemos ir modifikuoti verslo

procesus taip, kad sistemos daugiau nereikėtų– tęsti sistemos priežiūrą– rekonstruoti sistemą tam, kad būtų galima pagerinti jos

prižiūrimumą– pakeisti paveldėtąją sistemą nauja sistema

• Pasirinkta strategija turi priklausyti nuo sistemos kokybės ir jos vertės verslui


Sistemos kokybė ir verslo vertėSistemos kokybė ir verslo vertė(vertės modelis)(vertės modelis)

12

3 4 5

67

89

10

System quality

Business valueHigh business valueLow quality High business value

High quality

Low business valueLow quality

Low business valueHigh quality


Kaip suprasti vertės modelį?Kaip suprasti vertės modelį?

• Turime 10 paveldėtųjų sistemų (ar komponentų): 1, 2, 3,...,10

• Jos (jie) sugrupuotos (ti) pagal verslo vertę ir kokybę dvibalėje vertinimo skalėje

• Verslo vertė: – Aukšta– Žema

• Kokybė– Aukšta– Žema


Paveldėtųjų sistemų kategorijosPaveldėtųjų sistemų kategorijos

• Žemos kokybės, žemos verslo vertės– tokių sistemų reikia atsisakyti

• Žemos kokybės, aukštos verslo vertės– turi būti rekonstruojamos arba pakeistos kita tinkama

sistema

• Aukštos kokybės, žemos verslo vertės– visiškai pakeisti arba prižiūrėti

• Aukštos kokybės, aukštos verslo vertės– toliau naudoti prižiūrint


Problema: kaip įvertinti verslo Problema: kaip įvertinti verslo kokybę ir sistemos kokybę?kokybę ir sistemos kokybę?

• Apklausos metodas / ekspertinis įvertinimo metodas

• Ekspertinio įvertinimo esmė:• Pateikti gerai, teisingai parengtus klausimus

ekspertams– Parinkti ekspertus– Surinkti, apdoroti, klasifikuoti atsakymus– Daryti išvadą, gauti atsakymą-įvertinimą

• Problema: ekspertų nepriklausomumas, atsakymų patikimumas


Verslo vertės įvertinimasVerslo vertės įvertinimas

• Įvertinant sistemos vertę verslui reikia atsižvelgti į įvairias nuomones– Galutinių sistemos vartotojų– Verslo klientų– Informacinių technologijų vadybininkų– Vyresniųjų vadybininkų


Sistemos kokybės įvertinimasSistemos kokybės įvertinimas

• Verslo proceso įvertinimas– Kaip verslo procesai palaiko verslo tikslą?

• Aplinkos įvertinimas– Ar sistemos aplinka dirba efektyviai ir kiek kainuoja

jos priežiūra?

• Taikomųjų programų įvertinimas– Kokia yra taikomųjų programų kokybė?


Verslo proceso įvertinimasVerslo proceso įvertinimas

• Reikia užduoti tokius klausimus– Ar yra apibrėžtas proceso modelis ir ar jo yra

laikomasi?– Ar skirtingos organizacijos dalys (padaliniai)

naudoja skirtingus procesus tai pačiai veiklai?– Kaip procesas buvo adaptuotas?– Kokie yra sąryšiai su kitais verslo procesais?– Ar procesą palaiko paveldėtoji taikomoji

programinė įranga?


Aplinkos įvertinimas (1)Aplinkos įvertinimas (1)

• Tiekėjo stabilumas– Ar tiekėjas vis dar egzistuoja? Ar sistemas palaiko

kas nors kitas?

• Gedimų lygmuo– Ar aparatūra dažnai genda? Ar palaikančios

programos dažnai “lūžta”?

• Amžius– Koks aparatūros ir programinės įrangos amžius?

• Greitis– Ar sistemos greitis tenkina sistemos vartotojus?


Aplinkos įvertinimas (2)Aplinkos įvertinimas (2)

• Reikalavimai palaikymui– Kokio palaikymo reikia aparatūrai ir programinei

įrangai?

• Priežiūros kaštai– Kokie aparatūros priežiūros ir palaikančiųjų

programų licenzijų kaštai?

• Sąveika su kitomis sistemomis– Ar yra problemų sąveikaujant su kitomis

sistemomis? Ar reikia aparatūros emuliavimo?


Taikomųjų programų įvertinimas (1)Taikomųjų programų įvertinimas (1)

• Suprantamumas– Ar sunku suprasti sistemos išeities kodą? Ar naudojamos

sudėtingos valdymo struktūros? Ar kintamieji turi prasmingus vardus? Čia turima omenyje ne visa sistema, o jos fragmentas, kuris reikalauja kokybės įvertinimo

• Dokumentavimas– Ar sistema dokumentuota? Ar sistemos dokumentacija yra pilna,

išsami ir atnaujinama?

• Duomenys– Ar yra išreikštas sistemos duomenų modelis? Ar duomenys

dubliuojami?

• Greitis– Ar sistemos vartotojus tenkina greitis?


Taikomųjų programų įvertinimas Taikomųjų programų įvertinimas (2)(2)

• Programavimo kalba– Ar programavimo kalba vis dar naudojama? Ar yra jai

šiuolaikinių kompiliatorių? Pavyzdys: COBOL

• Konfigūravimo valdymas– Ar sistemos versijos yra valdomos konfigūravimo sistemos?

• Testiniai duomenys– Ar yra sistemos testiniai duomenys?

• Personalo patyrimas– Ar yra žmonių, susipažinusių su sistema? Galinčių ją prižiūrėti?


Sistemos įvertinimasSistemos įvertinimas

• Galima surinkti kiekybinę informaciją, kad būtų galima įvertinti taikomosios sistemos kokybę– sistemos pakeitimo užklausų skaičius– sistemos naudojamų skirtingų vartotojo sąsajų skaičius– sistemos naudojamų duomenų kiekis

• Reikia turėti kiekybinius kokybės matus (metrikas)



Database

User interface

Services

Ideal model for distribution Real legacy systems

Database

User interface

Services


Paveldėtos sistemos Paveldėtos sistemos paskirstymaspaskirstymas

User interface

Applicationservices

Database

Character terminals

Legacy system

Desktop PC clients running application

Middleware layer (wrapper)

Legacy system


PaveldPaveldėtųjų sistemų automatinis ėtųjų sistemų automatinis transformavimas į naujas aplinkastransformavimas į naujas aplinkas

Iš C į C++Iš C į C++


Transformavimo metodaiTransformavimo metodai

• Screen Scraping: Legacy applications can be just screen scraped and the values will be shown in a browser instead of an emulator.

• Servicification: transactions are converted to messages, which can serve the front-end Java application. Involves minimal or no backend changes. These messages provide get/set methods and Java application can transfer data with legacy application.

• Componentization: legacy application can be reengineered into reusable business components separating presentation and business logic. Business components can be called from Java application as needed


Dirbtinio intelekto metodais Dirbtinio intelekto metodais grįstas transformavimasgrįstas transformavimas

• Įvertinimas (Assessment): išgaunama esamos sistemos būsena ir charakteristikos

• Transformavimas (Transformation): pilnai automatizuotas kodo generavimas

• Rekonstrukcija (Refactoring): sistemos struktūra naujai pertvarkoma siekiant pagerinti jos našumą

• Internetizacija (Web-enablement): sistema pritaikoma darbui interneto aplinkoje (pvz., naršyklėje)


Cognizant’s InstaCognizant’s InstaWebWeb



Ar paveldėtosios sistemos Ar paveldėtosios sistemos neišnyks? neišnyks?

• It is seductive to think that current technology developments, such as components, middleware, enterprise computing and so on will provide the ultimate answer to all problems, and once software applications are expressed in this form, there will be no more legacy software. Experience acquired over the past 40 years shows this is extremely naïve.

• The ‘end of history’ scenario has proved to be entirely false on a number of occasions, and not just in software engineering

• In 20 years, software engineering will change in ways which we cannot imagine now, and we shall have to work out how to cope with what now is the latest technology, but will become tomorrow’s legacy.

• Legacy software is not so much a technological problem as an organisational and management problem: solutions need to be addressed at a higher level of abstraction than the software.

• The software legacy problem is enduring (t.y. amžina).


IšvadosIšvados

• Liktinės sistemos gyvavimo laiką lemia vertė verslui ir kokybė

• Sistemų kokybės įvertinimas yra vienas sudėtingiausių dalykų, nes kokybę reikia išmatuoti ir įvertinti ne tik kokybiškai, bet ir kiekybiškai.

• Kai kokybę lemiančių parametrų daug ir jie tarpusavyje susieti, problema darosi paini ir sunkiai sprendžiama

priežiūros matavimas ir kokybės įvertinimas

Documents