Priežiūros procesai ir modeliai.
Paveldėtinės sistemos
Prof. Vytautas Štuikys vytautas.stuikys@ktu.lt
Prof. Robertas Damaševičius robertas.damasevicius@ktu.lt
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
Priežiūros procesai ir modeliai
2
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)
Priežiūros procesai ir modeliai
3
Keitimų 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‘)
Priežiūros procesai ir modeliai
4
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
Priežiūros procesai ir modeliai
5
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
.
Priežiūros procesai ir modeliai
6
Code-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ą
Priežiūros procesai ir modeliai
7
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
Priežiūros procesai ir modeliai
8
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į
Priežiūros procesai ir modeliai
9
Krioklio 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.
Priežiūros procesai ir modeliai
10
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
Priežiūros procesai ir modeliai
11
Inkrementinis 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.
Priežiūros procesai ir modeliai
12
Inkrementinis 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ą.
Priežiūros procesai ir modeliai
13
Evoliuciniai 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ūros procesai ir modeliai
14
Priežiūrą įvertinantis
(“Maintenance-aware” life-cycle)
Priežiūros procesai ir modeliai
15
“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 procesai ir modeliai
16
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 (ReuseOriented Model)
• Versijų pakopomis grindžiamas (Versioned
staged model)
• IEEE standartų modeliai
Priežiūros procesai ir modeliai
17
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
Priežiūros procesai ir modeliai
18
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
Priežiūros procesai ir modeliai
19
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)
Priežiūros procesai ir modeliai
20
Į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
Priežiūros procesai ir modeliai
21
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
Priežiūros procesai ir modeliai
22
Capability 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
Priežiūros procesai ir modeliai
23
Paprastas pakopinis modelis
(Simple staged model)
•
•
•
•
•
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
K. H. Bennett V.T Rajlich, 2000, Software Maintenance and Evolution: a Roadmap
K. H. Bennett, SOFTWARE EVOLUTION AND THE STAGED MODEL OF THE SOFTWARE LIFECYCLE
Priežiūros procesai ir modeliai
24
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.
Priežiūros procesai ir modeliai
25
Versijomis grįstas pakopinis modelis
(Versioned staged model)
Priežiūros procesai ir modeliai
26
SMmm (SOFTWARE
MAINTENANCE MATURITY MODEL)
• Panašus į CMMi
modelį
• Remiasi gera
praktika
Alain April, Jean-Marc Desharnais, SOFTWARE MAINTENANCE MATURITY MODEL (SMmm): A SOFTWARE
MAINTENANCE PROCESS MODEL
Priežiūros procesai ir modeliai
27
Maintenance process model (IEEE 1219
Standard for Software Maintenance)
• Starts the software maintenance effort during the postdelivery 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
Priežiūros procesai ir modeliai
28
ISO/IEC 14764-00 Priežiūros
Proceso Modelis
Priežiūros procesai ir modeliai
29
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.
Priežiūros procesai ir modeliai
30
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
Priežiūros procesai ir modeliai
31
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
Priežiūros procesai ir modeliai
32
Š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.
Priežiūros procesai ir modeliai
33
Paveldėtosios (liktinės) sistemos
ir jų įvertinimo modelis
(Legacy systems)
Paveldėtinės sistemos
Turinys
• 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
Paveldėtinės sistemos
Tikslai
• 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ė
Paveldėtinės sistemos
Kas yra paveldėtoji (legacy)
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ėtinės sistemos
Paveldė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
Paveldėtinės sistemos
Problemos
• Sistemos kūrėjai nepasiekiami
• Sistema sukurta pasenusiais metodais
• Sistema patyrė intensyvias modifikacijas ir
taisymus
• Dokumentacijos nėra arba ji neatnaujinta
Priežiūros procesai ir modeliai
39
Paveldėtųjų (legacy) sistemų
atributai
•
•
•
•
•
•
•
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ą
Paveldėtinės sistemos
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”
Priežiūros procesai ir modeliai
41
Paveldėtosios sistemos
pakeitimas
• 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ėtinės sistemos
Paveldė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ėtinės sistemos
Paveldė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 kompiuteriaimainframe
– 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ėtinės sistemos
Paveldėtųjų sistemų komponentai
(srities modelis)
Palaikymo
programos
Veikia
Naudoja
Taikomosios
programos
Apima žinias
Verslo
taisyklės
Naudoja
Veikia
Apriboja
Naudoja
Sisteminė
aparatūra
Duomenys
Paveldėtinės sistemos
Verslo
procesai
Socio-techninės sistemos
sluoksniuotasis modelis
Verslo procesai
Taikomosios programos
Palaikanti programinė įranga
Aparatūra
Paveldėtinės sistemos
Sistemos 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ėtinės sistemos
Paveldė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ą
Paveldėtinės sistemos
Paveldėtųjų sistemų struktūra
• Dauguma paveldėtųjų sistemų buvo sukurtos
dar prieš atsirandant objektiniam projektavimui
• Paveldėtosios sistemos dažniausia buvo
kuriamos naudojant funkcinio projektavimo
metodus
Paveldėtinės sistemos
Paveldė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
Paveldėtinės sistemos
Sistemos kokybė ir verslo vertė
(vertės modelis)
Business value
High business value
Low quality
9
10
High business value
High quality
8
6
7
Low business value
High quality
Low business value
Low quality
2
1
3
4
5
System quality
Paveldėtinės sistemos
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ėtinės sistemos
Paveldė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
Paveldėtinės sistemos
Problema: kaip įvertinti verslo
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
Paveldėtinės sistemos
Verslo vertės įvertinimas
• Įvertinant sistemos vertę verslui reikia atsižvelgti
į įvairias nuomones
–
–
–
–
Galutinių sistemos vartotojų
Verslo klientų
Informacinių technologijų vadybininkų
Vyresniųjų vadybininkų
Paveldėtinės sistemos
Sistemos 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ė?
Paveldėtinės sistemos
Verslo 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?
Paveldėtinės sistemos
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?
Paveldėtinės sistemos
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?
Paveldėtinės sistemos
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?
Paveldėtinės sistemos
Taikomųjų programų įvertinimas
(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?
Paveldėtinės sistemos
Sistemos į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)
Paveldėtinės sistemos
Paveldėtųjų sistemų struktūra
User interface
User interface
Services
Services
Database
Database
Ideal model for distribution
Real legacy systems
Paveldėtinės sistemos
Paveldėtos sistemos
paskirstymas
Desktop PC clients running application
Legacy system
Application
services
Middleware layer (wrapper)
Database
User interface
Legacy system
Character terminals
Paveldėtinės sistemos
Paveldėtųjų sistemų automatinis
transformavimas į naujas aplinkas
Paveldėtinės sistemos
Iš C į C++
Priežiūros procesai ir modeliai
66
Transformavimo 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
Priežiūros procesai ir modeliai
67
Dirbtinio intelekto metodais
grį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)
Priežiūros procesai ir modeliai
68
Cognizant’s InstaWeb
Priežiūros procesai ir modeliai
69
Ar paveldėtosios sistemos
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).
Paveldėtinės sistemos
Iš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
Paveldėtinės sistemos