Sissejuhatus Tarkvara rolli evolutsioon 1950 - 1960+ : paketttöötlus, “oma” (lokaalne) tarkvara 1960+ - 1970+ : multitöötlus, distributeeritav tarkvara (produkt), andmebaasid, reaalaja tarkvara 1970+ - 1990- : mikroelektroonika (hinna ja mõõtmete drastiline - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Sissejuhatus
Tarkvara rolli evolutsioon1950 - 1960+ : paketttöötlus, “oma” (lokaalne) tarkvara1960+ - 1970+ : multitöötlus, distributeeritav tarkvara (produkt),
~1979 : “arvuti- ja tööstusrevolutsioon”~1980 : mikroelektroonika = “uus muutuste laine inimkonna ajaloos”~1982 : “infoühiskond”~1989 : kaugvõrkude “läbimurre”~1990 : “võimu ja valitsemise tagamine “
2
Vajadus tarkvaratehnika (kui inseneridistsipliini) järeleligemale 30 viimase aasta jooksul täheldatakse tarkvara “kriisi”, õigemini kroonilisi hädasid :välisest vaatekohast (tellijad, mänedžerid)
• miks programmprodukti valmimine on nii ajakulukas• miks hind on nii soolane• miks ei leita kõiki vigu enne tellijale/ostjale üleandmist• miks on tarkvara arendusprotsessi raske jälgida
asjatundjate vaatekohast• arendustöö graafik ja kulude hinnangud on ülimalt ebatäpsed• tarkvara-inimeste produktiivsus ei vasta vajadustele• tarkvara kvaliteet on pahatihti lubamatult madal• olemasolevat tarkvara on väga raske ja kulukas hooldada
Kokkuvõttes, tarkvaratehnika olemuseks on metodoloogia, sihitusega võimalikult adekvaatselt rahuldada üha kasvavat nõudmist optimaalse kvaliteedi ja hinna suhtega tarkvara järele. Selle fookuses on tarkvara loomise protsessi enda kvaliteetja standardid, mille järgimine tagaks nii arendustöö kui ka hoolduse efektiivsuse.
3
Müüdid = eksitavad hoiakud, levinud “tõekspidamised”, mis on visad kaduma.
Tarkvara tootmise, arendustööde juhid, olles alalises pinges eelarve, töö graafikuja tulemuse kvaliteedi pärast, kalduvad kergesti uskuma nt. järgmisi müüte.
• Meil on raamat(ud) standardite ja protseduurireeglitega. Seega on mu inimesed varustatud vajalike teadmistega.Tegelikkus: Kas seda ikka kasutatakse? Või üldse teatakse? Kas see on piisavalt kaasaegne ja täielik? Enamasti on vastuseks ei.
• Meie inimestel on kaasaegsed arendusvahendid. Pealegi varustame neidparima tehnikaga.Tegelikkus: Riistvara tipptase pole nii oluline. Kvaliteedi ja produktiiv-suse aspektist on automatiseeritud arendusvahendid küll tähtsad, kuid enamus tarkvara arendajatest neid siiski ei kasuta.
• Kui jääme graafikust maha, siis lisame projekti uusi inimesi ja likvidee-rime mahajäämuse.Tegelikkus: See ei ole nii lihtne. Uusi inimesi saab otstarbekohaselt lisada ainult varem planeeritult ja hästi koordineeritud viisil. Tihtipealeei arvestata, et uustulnuka lülitamine võtab tööd ja aega. Kui see jääb projekti täitjate hooleks, siis ajalist efekti ei pruugi saadagi.
4
Tellija (kas klient - lõpptulemuse ootaja, või nt. teine koguprojekti alam-töörühm) ilmutab tihti pealiskaudset suhtumist ülesande formuleerimise osas.
• Kui on olemas üldine ülesande püstitus, siis võib lasta hakata programme kirjutama. Detailid täpsustame hiljem.Tegelikkus: Ebaselge lähteülesanne on üks peamisi vigu. Tingimata on vaja formaalset ja detailset kirjeldust, milles piiritletakse valdkond, funktsioon, jõudlus, liidesed, kavanduskitsendused ja valideerimise kriteerium. Seda saab teha vaid tellija ja arendaja tihedas koostöös.
• Parandused seoses muutustega projekti nõuetes saab tarkvara kompo-nenti(desse) kergesti sisse viia, kuna tegemist on tarkvaraga (mis teatavasti on hõlpsasti muudetav).Tegelikkus: muudatusi nõuetes tuleb kindlasti ette, kuid nende arvesse-võtmise raskus (ja paranduse maksumus) sõltub oluliselt sellest, milliseletapil see toimub:
lähteülesande püstitamise ajal 1arendustööde ajal 1,5 - 6hoolduse ajal 60 - 100.
5
Programmeerijate seas on levinud nt. järgmised eksiarvamused.
• Minu töö on tehtud, kui olen kirjutanud programmi ja selle käima saanud.Tegelikkus: Siin pole päris selge, mida mõista käima saamise all. Igatahes on teada, et 50 -70 protsenti kogu tööst, mis ühele programmile kulub, tehakse pärast seda, kui programm on esimest korda kasutajale/tellijale üle antud.
• Kuni ma pole programmi käima saanud pole kuidagi võimalik selle kvaliteeti hinnata.Tegelikkus: On küll - nimelt projekti jooksva inspekteerimise käigus, mil rakendatakse nn. tarkvara arvustust [software review]. See formaalnemeetod on osutunud isegi efektiivsemaks kui testimine.
• Eduka projekti tulemuseks (üleantavaks produktiks) on laitmatult töötav programm.Tegelikkus. Töötav programm on ainult üks osa tarkvara konfiguratsioo-nist, kuhu kuuluvad ka nõuete spetsifikatsioon, kavandus, programmi tekst, andmestruktuuride kirjeldus, testimistulemused. Need on hädavaja-likud tarkvara hoolduseks.
6
Tarkvaratehnika paradigmad
Klassikaline elutsükkel (“kosk-mudel”)
Süsteemianalüüs
Analüüs
Kavandus
Kood
Test
Hooldus
4GLSpetsifikatsioon neljanda põlvkonna keeles.
autom.
7
Süsteemianalüüs
Analüüs
Kavandus
Kood
Test
Hooldus
Kiirkavandus
Test
Prototüüp
Tellija hinnang
Prototüüpimine
8
Planeerimine Riskianalüüs
Tellija hinnang Produkti loomine
Nõuete kogumine japrojekti planeerimine
Projekti planeeriminevastavalt tellija hinnangule
Esialgne
Vastavalt tellija reaktsioonile
? Stopp
Prototüübina
Spiraalmudel
9
Tarkvara konstrueerimise etapid
1. Defineerimine (sätestamine) - mida tuleb teha? [definition] Süsteemianalüüs. Millised on koht ja seosed hõlmavas süsteemis.
Loodava süsteemi otstarve ja eesmärk. Tarkvaraprojekti planeerimine. Riskide analüüsimine, ressursside
määratlemine, maksumuse hindamine, tööülesannete ja -graafiku fikseerimine.
Nõuete analüüs. Detailse lähteülesande püstitamine kõiki nõudeid arvesse võttes.
2. Arendamine (arendustöö) - programmsüsteemi loomine. [development]Kavandamine. Nõuetele vastavalt kirjeldatakse (loomulikus keeles
ja/või graafiliselt ja/või tabelitena jm.) loodava süsteemi andmestruktuurid, arhitektuur, protseduurid, liidesed.
Kodeerimine. Tulemuseks on arvuti programm(süsteem). See saadakse kavandi realiseerimisel mingit programmeerimis- või spetsi-fitseerimiskeelt (nt. 4GL) kasutades.
Testimine. Programm(süsteem)i võimalikult igakülgne katsetamine - lähteülesandele vastavuse katseline kontrollimine. Avastatud vigade parandamine.
10
[maintenance]3. Hooldus (olemasoleva tarkvara korral). Enamasti kaasneb ka defineerimise ja
arendamise etappide taasrakendamine. [correction]
Korrigeerimine (korrigeeriv hooldus). Kasutamisel avastatud vigade korrigeerimine.
[adaption]Kohandamine (kohandav hooldus). Tarkvara modifitseerimine vastavalt
kasutava keskkonna muutustele.[enhancement]
Täiustamine (täiustav hooldus). Tarkvara modifitseerimine vastavalt tellija/kasutaja uutele, täiendavatele soovidele. Võib vaja minnapöördkonstrueerimist. [reverse engineering]
11
Projekti juhtimise protsess
Projekti juhtimine toimub pidevalt, alates selle algusest kuni lõpuni.
Alustamine: koos tellijaga sätestatakse eesmärk ja ulatus. [scope]Eesmärk - üldine, mida on vaja? (Lahus sellest, kuidas?).Ulatus - üldine funktsionaalsuse (funktsioonide) kirjeldus,
kuid juba koos selle piirangutega.Alternatiivid - arutatakse läbi, millised (alternatiivsed)
lahendusteed tulevad arvesse.Mõõdud ja meetrika. [measures; metrics]
Mõõdetakse nii tehnilist protsessi ennast (et seda parandada)kui ka tulemust (et tagada selle kvaliteeti) ja ressursse.
Hindamine [estimation] on eeskätt aluseks planeerimisel (inimtöö maht, kestus, maksumus). Vastavad hindamise meetodid, lisaks kogemusele.
Kasutatakse korraga mitmeid meetodeid. Seejuures• eeldatakse, et projekti ulatus on eelnevalt kindlaks määratud• baasina kasutatakse varasemaid mõõtmistulemusi• projekti osi hinnatakse eraldi.
12
Riskianalüüs. Toimub pidevalt. Kaalutletakse ja hinnatakse “kahtlasi” momente, mis võiksid projektile (ja selle tähtaegsele valmimisele) saatuslikult mõjuda. Nt. kas kasutaja nõuded on ikka tegelikult õigesti mõistetud, kas on karta graafikust mahajäämist, kas paistab tulevat ootamatuid tehnilisi probleeme.
Ajakava. [scheduling]See on alati küll olemas, kuid peab olema kvaliteetne.
Jälgimine ja juhtimine. [tracking; control]Eeskätt ajakava osas. Mahajäämuste (ennetav) likvideerimine.
13
[metrics; measurement]Projekti juhtimine: tarkvara meetrika (mõõtmine, mõõdistus)
Funktsionaalsuse mõõtmine. [function-oriented metrics]Programmeerimiskeelest sõltumatu, kuid subjektiivne.Funktsioonpunktide meetod. [function-points]
Sisendeid arv kaal(3\4\6) arv × kaalVäljundeid arv kaal(4\5\7) arv × kaalPäringuid arv kaal(3\4\6) arv × kaalFaile arv kaal(7\10\15) arv × kaalLiideseid arv kaal(5\7\10) arv × kaalKokku Summa
FP = Summa × (0.65 + 0.01 × (F1 + F2 + … +F14))kus Fi on järgmiste momentide hinnang 5-punkti skaalal:F 1: taastuse vajadus [back-up; recovery]F 2: kommunikatsiooni vajadusF 3: leidub üldfunktsioone (mujal vajalikke)F 4: on aja-kriitilineF 5: töötab raskelt koormatud keskkonnasF 6: on otsekontakne [on-line] F 7: otsekontaktsus on transaktne (nt. multi-aknad)F 8: põhifailide otsekontaktne modifitseerimineF 9: sisend- ja väljundandmed, failid ja päringud on keerulisedF10: sisemine töötlus on keerulineF11: kood on kavandatud taaskasutamist arvestadesF12: kavandis on ette nähtud konverteerimine ja installeerimineF13. kuulub installeerimisele mitmetes erinevates asutustesF14: kavandis on arvestatud, et kasutamine/jooksev muutmine oleks kerge.
15
Tunnuspunktide meetod. [feature-points]Sisendeid arv kaal(4) arv × kaalVäljundeid arv kaal(5) arv × kaalPäringuid arv kaal(4) arv × kaalFaile arv kaal(7) arv × kaalLiideseid arv kaal(7) arv × kaalAlgoritme arv kaal(3) arv × kaalKokku Summa
16
Projekti juhtimine: hindamine Planeerimise etapil.
Dekomponeerimisel põhinev hindamine.Käsuridade (KR) või punktide alusel.
COCOMO on kasutatav ka modifitseerimise töömahu hindamiseks:TKR asemel kasutatakse siis ekvivalenti TEKR, TEKR = TMKR × MF / 100,
kus TMKR on modifitseeritud koodiridade arv (tuh.) ja MF - modifitseerimisfaktor, MF =
0,4 (mitme % ulatuses muutus kavand) +0,3 (mitme % ulatuses muutus kood) +0,3 (mitme % ulatuses tuli taasintegreerida)
Halvemal juhul võib % olla ka suurem kui 100.
COCOMO variante (ja pakette): Ada Process Model (APM), REVIC, Costar, COSTMODL, COCOMOID, ...
25
Putnami mudel [Putnam Estimation Model]
Eeskätt väga suurte tarkvaraprojektide korral (30 inimaastat ja rohkem).Dünaamiline, sisaldab (projekti, töö kestust).
Baseerub tarkvara võrrandil (Rayleigh-Nordeni kõvera kirjeldusest)L = C (K/B)1/3 t4/3
(tulemuse maht) = C ((töö kogumaht)/B)1/3 (töö aeg e. kestus)4/3
KR inimaastad kalendriaastad B on projekti mahulise taseme faktor TKR < 20, B = 0,16; TKR ~ 20, B = 0,18; TKR ~ 30, B = 0,28; TKR ~ 40, B = 0,34; TKR ~ 50, B = 0,37; TKR > 60, B = 0,39. C on tootlikkuse (tööviljakuse) faktor, saadakse tarkvara võrrandi lahendamisel valminud projektide korral (üle 2000, 1990.a), reaalajasüsteemid C = 3238 vilets metoodika C=2000
… hea metoodika C=8000telefonisüsteemid C = 8478 + automatis. C=11000
…kommerts C = 28240
26
SLIM (Putman)jt. automatiseeritud abivahendid, sh. juba ka funktsioonpunktide ja tunnuspunktide alusel.
Projekti juhtimine: planeerimine (ca. 2-3% projekti töömahust)
• projekti eesmärgid (ülesanne, põhinõuded)• üldine hindamine (maht, ressursid, eelarve)• riskid (analüüs, juhtimine)• ajaline planeerimine (ajagraafikute koostamine) [scheduling]• loomine vs. soetamine [acquisition]• loomine vs. taasloomine (ümberkonstrueerimine) [re-engineering]• teiste juhtimistegevuste planeerimine
Süsteemi analüüsIga arvutiseeritud süsteemi loomise esimene etapp. (Eelneb tarkvara projektile.)Süsteemianalüütik(ud). 10 - 20 % kogumahust.• Süsteemi kontseptsioon (vajadus) [system concept (identification of need)]• Teostuvusuuring [feasibility study]• Majanduslik ja tehniline analüüs• Funktsioonide jaotamine [allocation]
andmebaasid, inimesed, riistvara, tarkvara - nende koht süsteemis => . . . tarkvaraprojekt
Süsteemi arhitektuur
Süsteemi modelleerimine
Süsteemi spetsifikatsioon e. kirjeldus
Süsteemi spetsifikatsiooni retsensioon
31
Süsteemi analüüs +•Süsteemi kontseptsioon (vajadus) [system concept (identification of need)]
Põhiküsimused: loodav info, kasutatav info, peamised funktsioonid ja jõudlusmida kasutaja vajab (oluline),mida kasutaja tahab (kuid pole nii oluline)
Eriküsimused: kas vajalik tehnoloogia eksisteerib,millised eriarendused ja -toomisbaas on vajalikud,millised on hinna- ja ajapiirangud,potentsiaalne turg (kui tehakse müügiks)jm.
Süsteemi kontseptsioon (dokument)
32
Süsteemi analüüs +•Teostuvusuuring [feasibility study] majanduslik teostuvus, tehniline teostuvus, juriidiline teostuvus,
alternatiivide puudumine.Kui on ilmsed, siis pole (erilist uuringut) tarvis.
Majanduslik teostuvus: ~majanduslik analüüs, ~ kasu(hüved)/hind(kulutused)
Esmakontakt tellijaga Koosolekud tellijaga [FAST meeting] Tulemuste (turu)hinnang Luua esialgne kirjeldus Esialgne kirjeldus kinnitatud Süsteemitehniline analüüs Määrata süsteemi elemendid Majanduslik teostuvusuuring Süsteemi mudelid Simulatsioon Süsteemi revideerimine Luua süsteemi kirjeldus Süsteemi kirjeldus kinnitatud
. . .
36
Tarkvara nõuete analüüsi alused
Nõuete analüüsSüsteemi-analüüs
Nõuete analüüs Tarkvara
kavandami-ne (disain)
Ülesanded• probleemi selgitamine [recognition]• lahkamine [evaluation] ja süntees• modelleerimine• spetsifitseerimine• ülevaatus [review]
Planeeri-mine
AnalüütikSuhtlemisoskus, üldistamisoskus, võime mõelda abstraktsemateskategooriates, mõningane kompetents tark- ja riistvara alal.
37
RaskusedInfo kättesaamine, selle täielikkus; suhtlemine, eesmärkide muutuvus, vasturääkivused (ka varasemaga), mida üldse tahetakse?, alternatiivide käsitlemine, kiustaus lakoniseerida, kohati “üle nurga lasta”.
Analüüsi printsiibidValdkond (domeen) ja eesmärgid õigesti mõistetud ning selgesti esitatud,ammendavad mudelid koostatud, võimalikult hierarhiline (kihiline) struktuur, üldine suund: olulisemalt realiseerimise detailide poole.
PrototüüpimineKui (odavalt) teostatav, siis kindlasti.
SpetsifitseerimineAnalüüsi tulemuste (kirjalik) kokkuvõtmine, sh. valiidsuskriteeriumid.Igati nõuetekohane vormistus ja retsenseeritus.
38
Tarkvara nõuete spetsifikatsioon
Üldosa Koht süsteemis (~ süsteemi sptsifikatsioon); üldine kirjeldus, kitsendused (~ projekti plaan).
Info [Information description] Info sisu ja vood, info esitusviis(id), süsteemi liidesed.
Käitumine [Behavioral description]Olekud; sündmused ja reaktsioonid. [events, actions]
Valiidsuskriteeriumid [Validation criteria] Jõudluspiirid, testiklassid, oodatav tarkvara reaktsiooni (kuuletuvuse) kiirus [respond]ja muud kaalutlused.
Viited Kirjandus, muu dokumentatsioon (sh. nt. ka standardid).Lisad Täiendavad andmed. Ka prototüüp(e), esialgne kasutajajuhend.
39
Struktuurne analüüs ja selle laiendused
Andmevoo diagramm [DFD, data flow diagram]
Sümboolika
Väline olem [external entity] Ward-Mellor
Protsess
Andmed
Andmeladu, -fail(id)
Juhtimis-andmed
Juhtimisandmete ladu
ProtsessJuhtimis-protsess
Hatley-Pribhai(juhtvoo diagrammis)
Pidev-andmed
40
Mudeli kihid
P0
A
B
C
D
F
A
B
P1P1
P1P2
P1P3
P1P4
P1P5
P1P6
C
D
F
Tase 0
Tase 1
E
F
GHI
S
J K L
41
Protsessikirjeldus [PSPEC]
Jutustavat laadi, eriti ülemistes kihtides. [narrative]
P0:
Andmekirjeldus
Enamasti olem-relatsiooni diagramm [ E-R, entitiy-relationship]
42
Juhtimisvoo diagramm [CFD, control flow diagram]
Lihtsamatel juhtudel lisatakse andmevoo diagrammile juhtimisprotsessid ja juhtimisinfo (sündmuste) liikumine.
Keerulisematel juhtudel tehakse eraldi diagramm, mis sisaldab kõik protsessid, juhtimisinfo (sündmuste) tekkimise ning sisenemised juhtimiskirjeldusse. Ei sisalda andmete liikumise nooli.
43
Juhtimiskirjeldus [CSPEC, control spetsification]
1. Olekumuutuste diagramm [STD, state transition diagram]
SündmusOlek . . . S[12] . . .
O[1])
. . . O[9]) P3; P8 O[7]
. . .
O[9]
O[7]
S[12]P3; P8
44
2. Juhtimiskirjeldus fikseerib, kuidas reageeritakse erinevatele sündmustele. Millised protsessid milliseid sündmusi võivad esile kutsuda.
Protsesside aktiviseerimise tabel [PAT, Process Activation Table]
kasutaja tööülesanded [tasks]kommunikatsioondialoogtunnetusjuhtimine
Arvutiga suhtlemise stiil [styles of human-computer interaction]käsuridalihtmenüüaknad, rippmenüüd, hiir
[windows, icons, menus, pointing - WIMP]
52
Suhtlusliidese kavandamineLähtemudelid
tarkvara kavand [design model]kasutajamudel [user model]kasutaja mudel, süsteemi tajumine [user’s model, system perception]süsteemi imidž [system image]
Tööülesannete analüüs ja modelleeriminetööülesannete väljaselgitamine
tavategevustest lähtudesobjektidest lähtudes
iga tööülesande korraleesmärgid/kavatsusediga eesmärgi/kavatsuse korral
tegevuste järjendolek (liidese vorm) iga tegevuse ajal
kasutajapoolsed juhtimismehhanismid oleku muutmisekskuidas juhtimismehhanismid mõjutavad olekutkuidas kasutaja interpreteerib süsteemi olekut liidesest saadava
Üldine suhtlus [general interaction]ole järjekindel [be consistent]paku sisukat tagasisidet [offer meaningful feedback]küsi kinnitust igale destruktiivsele tegevuselevõimalda kerget tagasivõttu võimalikult igale tegevuseleminimiseeri tegevuste vahel meeldejätta tulev info taotle dialoogi, liikumise ja mõtlemise efektiivsustandesta veadliigita tegevused funktsioonide järgi, vastavalt grupeeri ekraaniltaga kontekstne abi-infokasuta käaskude nimedena lihtsaid verbe (verbirühmi)
Andmekuva kuva ainult asja(jooksva konteksti)kohast infotära koorma kasutajat arv- ja tekstiandmetega, kui saab teisitikasuta ühtseid märgendeid, standardseid lühendeid ja värvevõimalda kasutajal mõista asukohta visuaalses konrekstisanna arusaadavaid veateateidrakenda soodsat tekstiformaati (suur/väiketähed, taanded, grupid) kasuta eri aknaid erinevat tüüpi andmete samaaegseks kuvakskasuta “analoog”-vormi, kus sobibkasuta ekraani kasutajale soodsal viisil
55
Andmesisestusminimiseeri sisestustegevuste arvhoolitse andmekuva ja andmesisestuse kooskõlalisuse eestvõimalda valida erineva tasemega sisestusrežiime [customize]võimalda valida suhtlusstiilideaktiveeri jooksvas kontekstis võimatud käsudlase kasutajal juhtida suhtlusttaga abi-info iga sisestustegevuse jaoks elimineeri kõik liiasused (ühik, null murdosana, vaikeväärtused,
Testimisstrateegiad• musta kasti meetod (testitakse funktsionaalsust)• valge kasti meetod (testitakse siseehitust)
Valge kasti meetod
Teoreetiliselt tuleks läbi proovid kõik teed. Praktiliselt võimatu.Kontsentreerutakse tähtsamatele teedele.1. Iga sõltumatu tee - vähemalt üks kord.2. Kõik loogilised kontrollid - nii - kui ka + .3. Tsüklid - nii ääreväärtustel, kui ka (mõnedel) normaalväärtustel.4. Läbi proovida kõik sisemised andmestruktuurid (ja osad).
Testandmete konstrueerimine.
62
Tarkvara hooldus [software maintenance]
Olemasoleva tarkvara korral. Enamasti kaasneb ka defineerimise ja arendamise etappide taasrakendamine. 70% kogu tööst tarkvaraga.
[corrective maintenance]Korrigeerimine (korrigeeriv hooldus). Kasutamisel avastatud vigade
korrigeerimine.[adaptive maintenance]
Kohandamine (kohandav hooldus). Tarkvara modifitseerimine vastavaltkasutava keskkonna muutustele.
[enhancement][perfective maintenance]
Täiustamine (täiustav hooldus). Tarkvara modifitseerimine vastavalt tellija/kasutaja uutele, täiendavatele soovidele. Võib vaja minnapöördkonstrueerimist. [reverse engineering]
[preventive maintenance]Ennetamine (preventiivne hooldus). Tarkvara hooldatavuse ja usaldus-
väärsuse parandamine edasise täiustamise paremaks tagamiseks.
63
Hooldustegevus
--- Antud: tarkvara konfiguratsioon,--- hooldusnõueUurida kavandit (projekti)Planeerida tegevused
• Hooldatava tarkvara loomise protsessi ebaselgus. -- mõistmine raske või võimatu
• Hooldatava tarkvara evolutisooni ebaselgus. Muutused (versioonide, väljalasete jt. muudatuste tekkimine dokumenteerimata. -- mõistmine raske või võimatu
• “Kellegi teise” programmist aru saamine. -- eksponentsiaalselt raske
• See “keegi teine” pole kättesaadav.
• Dokumentatsiooni pole või on see kohutav.
• Hooldustöö respekt on madal.
Hooldatavus: kergus, millega saab tarkvara mõista, korrigeerida, adapteerida, laiendada.Hooldatavuse aspekti tuleb silmas pidada tarkvara loomise igal etapil. Sellel peab olema kindel koht ka igas tehnoülevaatuses.
65
Hoolduse organisatsioon
Hoolduse aruandlus
Hoolduse korraldamineHooldusnõude analüüs (viga või muu?). Vea korral: kas tõsine viga või mitte.Muu korral: kas kohandamine või täiustamine. Võib ka võimatuks osutuda.Analüüsitud hooldusnõue läheb teatava prioriteediga eelistusjärjekorda.Eelistusjärjekorrast võetakse täitmisele pririteetide järjekorras.
Hooduse andmebaas
Hoolduse kõrvalefektid
Võõra või pärandunud tarkvara hooldus [alien or legacy software]pöördkonstrueerimine [reverse engineering]ümberkonstrueerimine [re-engineering]
66
Tarkvara konfiguratsiooni juhtimine [software configuration management]
Tarkvara konfiguratsioon: tarkvara arendusprotsessi tulemus -- programmid, neid kirjeldav kogu dokumentatsioon, sisemised ja välimised andmestruktuurid (, + arenduskeskkond).
Tarkvara konfiguratsiooni juhtimine: tegevused tarkvara konfiguratsiooni muudatuste juhtimiseks kogu tarkvara elutsükli jooksul; süstemaatiline “arvepidamine” muudatuste üle.
Lävejooned [baselines]
Tarkvara konfiguratsiooni objektid (üksused) [SCI ]Koos omavaheliste seostega moodustavad tarkvara konfiguratsiooni andmebaasi.
Muudatuse nõueMuudatuse nõude kirjeldusMuudatuste juht otsustab
Nõue järjekorda Muudatuse nõue tagasi lükatudTellimus (order)Muudatuste tegijad igale konf. objektileKonfig. objektide muutmineKvaliteedi tagamise ja testimistegevusedUued versioonidKõikide muudatuste auditUus tarkvara versioon