1

TarkvaratehnikaSoftware Engineering

R.S.Pressman. Software Engineering: Practitioner’s Approach. European 3Rev.ed.McGraw-Hill, UK, 1994, 801 p.

I.Sommerville. Software Engineering. Addison-Wesley, 1992, 649 p.R.Jürgenson, V.Vahe. Objektorienteeritud lähenemine programmeerimisele. TTÜ, 1999 107 lk.

I. Tarkvara - protsess ja selle juhtimine1. Tarkvara ja tarkvaratehnika2. Projekti juhtimine: tarkvara meetrika [management; metrics] 3. Projekti juhtimine: hinnangud [estimation]4. Projekti juhtimine: planeerimine

II. Süsteemi ja tarkvara nõuete analüüs5. Süsteemitehnika (süsteemianalüüs) [computer system engineering]6. Tarkvara nõuete analüüsi alused7. Struktuurne analüüs ja selle laiendused8. Objekt-orienteeritud analüüs ja andmete modelleerimine9. Alternatiivsed analüüsi meetodid ja formaalsed meetodid

2

III. Tarkvara kavandamine ja realiseerimine [design; implementation]10. Tarkvara kavandamise alused11. Andmevoole orienteeritud kavandus12. Objekt-orienteeritud kavandus13. Andmetele orienteeritud kavandus14. Kasutajaliidese kavandamine15. Reaalajale kavandamine16. Programmeerimiskeeled ja kodeerimine

IV. Kindlustamine, verifitseerimine ja tarkvara terviklikkuse korrashoid[ensuring; integrity; maitaining]

17. Tarkvara kvaliteedi tagamine [assurance] 18. Tarkvara testimismeetodid19. Tarkvara testimise strateegiad20. Tarkvara hooldus [maintainance]21. Tarkvara konfiguratsiooni juhtimine

V. Automatiseerimise roll22. Arvutiseeritud tarkvaratehnika (CASE)

[computer-aided software engineering]23. Integreeritud CASE-keskkonnad24. Perspektiiv

3

1. Tarkvara ja tarkvaratehnika1.1. Tarkvara tähtsus

1.1.1. Tarkvara evolutsiooniline roll1.1.2. Tööstuse perspektiiv1.1.3. Vananev tarkvaratehas

1.2. Tarkvara1.2.1. Tarkvara iseloomustus1.2.2. Tarkvara komponendid1.2.3. Tarkvara rakendused

1.3. Tarkvara: kriis tulemas1.3.1. Probleemid1.3.2. Põhjused

1.4. Tarkvara müüdid1.5. Tarkvaratehnika paradigmad

1.5.1. Tarkvaratehnika definitsioon1.5.2. Klassikaline elutsükkel1.5.3. Prototüüpimine1.5.4. Spiraalmudel1.5.5. Neljanda põlvkonna meetodid1.5.6. Kombineeritud paradigmad

1.6. Tarkvaratehnika geneeriline aspekt

4

Sissejuhatus

Tarkvara rolli evolutsioon1950 - 1960+ : paketttöötlus, “oma” (lokaalne) tarkvara1960+ - 1970+ : multitöötlus, distributeeritav tarkvara (produkt),

andmebaasid, reaalaja tarkvara1970+ - 1990- : mikroelektroonika (hinna ja mõõtmete drastiline

langus), hajussüsteemid, tarkvara tellija (klient)1990- - 2000 : võimsad personaalarvutid, Internet, OO tehnoloogia,

paralleelarvutused, ekspertsüsteemid, intellektitehnikaMärksõnu

~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 “

5

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.

6

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.

7

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.

8

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.

9

Tarkvaratehnika paradigmad

Klassikaline elutsükkel (“kosk-mudel”)

Süsteemianalüüs

Analüüs

Kavandus

Kood

Test

Hooldus

4GLSpetsifikatsioon neljanda põlvkonna keeles.

autom.

10

Süsteemianalüüs

Analüüs

Kavandus

Kood

Test

Hooldus

Kiirkavandus

Test

Prototüüp

Tellija hinnang

Prototüüpimine

11

Planeerimine Riskianalüüs

Tellija hinnang Produkti loomine

Nõuete kogumine japrojekti planeerimine

Projekti planeeriminevastavalt tellija hinnangule

Esialgne

Vastavalt tellija reaktsioonile

? Stopp

Prototüübina

Spiraalmudel

12

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.

13

[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]

14

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.

15

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.

16

[metrics; measurement]Projekti juhtimine: tarkvara meetrika (mõõtmine, mõõdistus)

• Mahu mõõtmine• Funktsionaalsuse mõõtmine• Kvaliteedi mõõtmine

Mahu mõõtmine. [size-oriented metrics]Objektiivne, kuid programmeerimiskeelest sõltuv.

KR - koodiridade arv TKR = KR/1000tööviljakus = TKR/inimkuidkvaliteet = defekte/TKRhinnatase = kogumaksumus/KRdokumentatsioon = lk.arv/TKR

17

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.

18

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

19

Projekti juhtimine: hindamine Planeerimise etapil.

Dekomponeerimisel põhinev hindamine.Käsuridade (KR) või punktide alusel.

Põhifunktsioonidkasutajaliidese juhtimine (KL)2D-graafika (2D)3D-graafika (3D)andmestruktuuride haldamine (AS)graafikakuva juhtimine (GR)

muude välisseadmete juhtimine (VS)disaini juhtimine (DS)

20

F-n Optim. Tõen. Pessim. Oodatav $/rida Rida/kuus Hind Kuid KL) 1800 2400 2650 2340 14 315 32760 7,42D) 4100 5200 7400 5380 20 2203D) 4600 6900 8600 20 220AS) 2950 3400 3600 18 240GR) 4050 4900 6200 22 200VS) 2000 2100 2450 28 140DS) 6600 8500 9800 18 300

Optim + 4×Tõen + Pessim 6

Hinnangulised

21

F-n Optim. Tõen. Pessim. Oodatav $/rida Rida/kuus Hind Kuid KL) 1800 2400 2650 2340 14 315 32760 7,42D) 4100 5200 7400 5380 20 220 107600 24,43D) 4600 6900 8600 6800 20 220 136000 30,9AS) 2950 3400 3600 3350 18 240 60300 13,9GR) 4050 4900 6200 4950 22 200 108900 24,7VS) 2000 2100 2450 2140 28 140 59920 15,2DS) 6600 8500 9800 8400 18 300 151200 28,0Hinnang

22

F-n Optim. Tõen. Pessim. Oodatav $/rida Rida/kuus Hind Kuid KL) 1800 2400 2650 2340 14 315 32760 7,42D) 4100 5200 7400 5380 20 220 107600 24,43D) 4600 6900 8600 6800 20 220 136000 30,9AS) 2950 3400 3600 3350 18 240 60300 13,9GR) 4050 4900 6200 4950 22 200 108900 24,7VS) 2000 2100 2450 2140 28 140 59920 15,2DS) 6600 8500 9800 8400 18 300 151200 28,0Hinnang 33360 656680 144,5

23

Tegevusmahu põhjal.

F-n Analüüs Kavandamine Kodeerimine Testimine Kokku KL) 1,0 2,0 0,5 3,5 7,02D) 2,0 10,0 4,5 9,5 26,0 3D) 2,5 12,0 6,0 11,0 31,5 AS) 2,0 6,0 3,0 4,0 15,0GR) 1,5 11,0 4,0 10,5 27,0 VS) 1,5 6,0 3,5 5,0 16,0DS) 4,0 14,0 5,0 7,0 30,0

Kokku 14,5 61,0 26,5 50,5 152,5

$kuu 5200 4800 4250 4500 Hind 75400 292800 112625 227250 708075

24

Empiirilised hinangud COCOMO - constructive cost model B.Boehm, 1981

Hinnatava süsteemi kategooriad:• orgaaniline: [organic]

väike, lihtliidestega, stabiilses keskkonnas, tuttavas ümbruses • autonoomne: [semi-detached]

keskmine suurus ja tase• sisseehitatud (sardsüsteem): [embedded] ranged kitsendused, muutuv keskkond, tundmatu ümbrus

Tööde kestuse empiiriline valem:D = 2,5 E d , kus D - kestus kuudes, E - maht inimkuudes ja

dorgaaniline 0,38 autonoomne 0,35sisseehitatud 0,32

25

Töömahu [effort] E (inimkuudes) hindamine.

1. COCOMO baasmudel. [basic]Empiiriline valem:

E = a (TKR) b , kus TKR - käsuridu (tuhandetes) ja

2. COCOMO täpsustatud mudel. [intermediate] E = a (TKR) b MKT, kus TKR - käsuridu (tuhandetes) ja

ning MKT on töömahtu korrigeeriv tegur, [AEF; effort adjustment factor]mis arvutatakse COCOMO täpsustatud mudeli atribuutide tabeli põhjal: MKT on viieteistkümne atribuudi korrutis (igast tabeli reast üks atribuut).

a borgaaniline 2,4 1,05 autonoomne 3,0 1,12sisseehitatud 3.6 1,20

a borgaaniline 3,2 (2,8) 1,05 autonoomne 3,0 (2,8) 1,12sisseehitatud 2,8 1,20

26

COCOMO täpsustatud mudeli atribuutide tabel madal norm. kõrge

Tarkvara usaldusväärsuse olulisus 0,77 0,88 1,00 1,15 1,40 - andmete maht ( / KR) keerukus 0,70 0,85 1,00 1,15 1,30 1,65 Riistvara protsessori ajapiirangud mälupiirangud muutumine “mõtlemisaeg”[turnaround] - 0,87 1,00 1,07 1,15 - Inimesed analüüsija võimekus programmeerija võimekus 1,42 1,17 1,00 0,86 0,70 - rakenduslik kogemus keeleline kogemus virtuaalarvuti kogemus Projekt tarkvaratehnika meetodid 1,24 1,10 1,00 0,91 0,82 - automaatvahendite kasutus arendustööde graafik

27

3. COCOMO detailne mudel. [advanced]Vähem kasutatud.

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, ...

28

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

29

SLIM (Putman)jt. automatiseeritud abivahendid, sh. juba ka funktsioonpunktide ja tunnuspunktide alusel.

30

Projekti juhtimine: põhitegevused

• planeerimine ülesanne, põhinõuded, hinnangud, riskid, graafikud, ressursid,

eelarve, plaanid teiste juhtimistegevuste jaoks: • organiseerimine organisatsiooniline struktuur, töökohad ja nende täitjate

kvalifikatsiooninõuded, vastutus ja volitused • personaliküsimused [staffing]

kohtadele määramine, uustulnukate assimileerimine, personali õpetamine, hindamine, stimuleerimine, vallandamine

• tiimi juhtimine [leading] tiimide loomine, koordineerimine, suunamine; inimeste jälgimine, volituste delegeerimine, motiveerimine, kontaktide soodustamine, konfliktide lahendamine, muutuste korraldamine, tööatmosfääri parandamine

• kontrolliminestandarditest kinnipidamise, aruannete esitamise jälgimine, töötulemuste mõõtmine, korrigeerivad tegevused, tasustus ja distsipliin

31

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

32

RiskidAnalüüs: identifitseerimine, tõenäosused, mõjud,

olulisemad neist (20% katab 80% tegelikult tekkida võivatest).Juhtimine: vastumeetmed, jälgimine.

Töögraafikud Eeldusgraaf (võrkgraafik), ajatabel, ajatabel koos täitjatega (ressursitabel). Etapilõpud.

[milestones]Organisatsioonilised küsimusedsh. tiimi struktuur, aruandlusvormid, jälgimise ja kontrolli mehhanismid.

Peaprogrammeerija tiim [chief programmer team] Peategija (plan., koord., retsenseerimine)

Tegijad (2-5)

Varumees {Toetusgrupp}

Tarkvara-hoidja

Erinõus-taja(d)

TehnilineabitööjõudMitte tingimata

täiskoormusega{ }

33

Süsteemitehnika [computer system engineering]

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

34

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)

35

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)

kasu: kiirendab, soodustab, hõlbustab, . . .hind: (lisa)soetamine, algatamine(algõpe, rütmihäired asutuses), (lisa)juhtimistegevused, . . . pidev õpe, andmekogumine, . . . hoolduskulud (tarkvara, riistvara, inimesed), . . .

Tehniline teostuvus: enamasti (kahjuks) selgub lõplikult edasises.

Teostuvusuuring (dokument)

36

Süsteemi analüüs +

Süsteemi spetsifikatsioonI. Sissejuhatus

1. Eesmärgid2. Kitsendused

II. Funktsioonide ja andmete kirjeldus1. Üldine funktsionaalne arhitektuur2. Üldine andmete arhitektuur

III. Alamsüsteemide kirjeldused1.. . .i. Sõnaline kirjeldus. Arhitektuur. Kitsendused.. . .

IV. Modelleerimise tulemused.. . .

V. Projekti esialgne plaan1. Arenduskulud2. Ajagraafik

VI. Lisad

37

Tarkvaratehnika kolm faasi

•defineerimine [definition phase]planeerimine => tarkvaraprojekti (esialgne) plaantarkvara nõuete analüüs => nõuete spetsifikatsioonplaani täpsustamine => tarkvaraprojekti plaan

•arendus [development phase]üldine kavandamine => üldkavandi spetsifikatsioon kavandi detailiseerimine => kavandi spetsifikatsioon kodeerimine => programmi kood

•verifitseerimine, üleandmine, hooldus [verification, release, maintenance]testiminekvaliteedikontrollüleandmine kasutajalehilisvigade korrigeerimine, adapteerimine, laiendamine

38

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

. . .

39

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.

40

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”.

Kommunikatsiooni (läbirääkimiste) meetodidOmaette valdkond. Esimene kohtumine tellijaga (intervjuu). Koosolekute korraldamine, nt. FAST-vormis [Facilitated Application Specification Technigue].

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.

41

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.

Funktsionaalsus [Functional description]Jaotus, kirjeldused (sõnaliselt; piirangud, jõudlunõuded,kavanduskitsendused; selgitavad diagrammid),juhtimisstruktuurid (kirjeldus, kavanduskitsendused)

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.

42

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

43

Mudeli kihid

P0

A

B

C

D

F

A

B

P1P1

P1P2

P1P3P1P4

P1P5

P1P6

C

D

F

Tase 0

Tase 1

E

F

GHI

SJ K L

44

Protsessikirjeldus [PSPEC]

Jutustavat laadi, eriti ülemistes kihtides. [narrative]

P0:

Andmekirjeldus

Enamasti olem-relatsiooni diagramm [ E-R, entitiy-relationship]

45

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.

46

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

47

2. Juhtimiskirjeldus fikseerib, kuidas reageeritakse erinevatele sündmustele. Millised protsessid milliseid sündmusi võivad esile kutsuda.

Protsesside aktiviseerimise tabel [PAT, Process Activation Table]

Sündmus P1 P2 . . . P7 P8 P9. . .Operaatori sekkumine 0 1 1 0 0Rõhk liiga suur 0 0 0 1 0Pöörded alla normi 0 0 0 0 1 . . .

Protsess s1 s2 . . . P1P2. . .

48

Koopiamasin.Andmevoo diagramm, tase0.

P0

A

B

Klaviatuur

Kuvar

A: sisendandmedB: teatedP0: diagnoosib (kontrollib sisendandmeid, tuvastab kopeerimise võimalikkust),

seab kopeerimise rezhiimi, juhib kopeerimist

Start/stopp

49

Koopiamasin.Andmevoo diagramm, tase1.

A(sisendandmed)

Sisendi töötlus

Koopiatevalmistamisejuhtimine

Diagnoo-simine

Kuvajuhtimine

Riistvarasignaalidetöötlemine

teated

saadud korraldused

rezhiim

riistvara seisund

rezhiimjooksev seis

veateated

50

Kasutajaliidese kavandamine

Inimfaktoridtaju [perception]oskuste tase ja käitumine [skill level, behavior]

psühholoogiline skaalariskialtis, kohusetundlik, impulsiivnemuretsev, stressi taluv, motiveeritudmitmesust salliv, aktiivne, paremakäeline

kasutaja tööülesanded [tasks]kommunikatsioondialoogtunnetusjuhtimine

Arvutiga suhtlemise stiil [styles of human-computer interaction]käsuridalihtmenüüaknad, rippmenüüd, hiir

[windows, icons, menus, pointing - WIMP]

51

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

info abil

52

Eriküsimusedreaktsiooniaeg [response time]abi-info vahendid [help facilities]veakäsitlus [error information handling]käsunimed [command labeling]

Realiseerimise vahendid

Kavandi hindamine

Eelkavand

Esimene prototüüp

Kasutaja hinnang

Kavandaja otsus

Järjekordne prototüüp

Valmis

53

Kavandamise juhiseid [interface design guidelines]

Ü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

54

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,

arvutatavad väärtused)

55

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.

56

Hooldustegevus

--- Antud: tarkvara konfiguratsioon,--- hooldusnõueUurida kavandit (projekti)Planeerida tegevused

Modifitseerida kavand RekodeeridaÜlevaatus: korras?

Regressioontestid--- Tulemus: uus väljalase

Hoolduse maht (hind)

M = p + K e (c - d )

keerukuse mõõt, pöörd-võrdeline kvaliteediga

empiiriline konstant

vahetu produktiivne töö(kavandi uurimine, modifitseeri-mine, rekodeerimine)

tuttavlikkuse mõõt

57

Hoolduse raskuste põhjusi

• 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.

58

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]

59

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.

Objektide identifitseerimine

Versioonide juhtimine [version (revision) control]

Variandid

60

Muudatuste juhtimine [change control]Konfiguratsiooni objekti muutmine

Sisseregist-reerimine

Väljaregist-reerimine

Juurdepää-su kontroll

Konfigurats.andmebaas

Tarkvarainsener

Lukustada

Avada

Konfiguratsiooniobjekt (lävejoone versioon)Konfiguratsiooni

objekt (väljavõetud)

Konfiguratsiooniobjekt (muudetud versioon)

Audit. info

Konfiguratsiooniobjekt (lävejoone versioon)

61

Muudatuste juhtimineTarkvara muutmine

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