Tarkvaratehnika Software Engineering R S Pressman Software Engineering

Tarkvaratehnika Software Engineering R. S. Pressman. Software Engineering: Practitioner’s Approach. European 3 Rev. ed. Mc. Graw. 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 H. -E. Erksson, M. Penker. UML Toolkit. John Wiley & Sons, 1998, 397 p. I. Tarkvara - protsess ja selle juhtimine 1. Tarkvara ja tarkvaratehnika 2. Projekti juhtimine: tarkvara meetrika [management; metrics] 3. Projekti juhtimine: hinnangud [estimation] 4. Projekti juhtimine: planeerimine II. Süsteemi ja tarkvara nõuete analüüs 5. Süsteemitehnika (süsteemianalüüs) [computer system engineering] 6. Tarkvara nõuete analüüsi alused 7. Struktuurne analüüs ja selle laiendused 8. Objekt-orienteeritud analüüs ja andmete modelleerimine 9. Alternatiivsed analüüsi meetodid ja formaalsed meetodid 1

III. Tarkvara kavandamine ja realiseerimine [design; implementation] 10. Tarkvara kavandamise alused 11. Andmevoole orienteeritud kavandus 12. Objekt-orienteeritud kavandus 13. Andmetele orienteeritud kavandus 14. Kasutajaliidese kavandamine 15. Reaalajale kavandamine 16. Programmeerimiskeeled ja kodeerimine IV. Kindlustamine, verifitseerimine ja tarkvara terviklikkuse korrashoid [ensuring; integrity; maitaining] 17. Tarkvara kvaliteedi tagamine [assurance] 18. Tarkvara testimismeetodid 19. Tarkvara testimise strateegiad 20. Tarkvara hooldus [maintainance] 21. Tarkvara konfiguratsiooni juhtimine V. Automatiseerimise roll 22. Arvutiseeritud tarkvaratehnika (CASE) [computer-aided software engineering] 23. Integreeritud CASE-keskkonnad 24. Perspektiiv 2

1. Tarkvara ja tarkvaratehnika 1. 1. Tarkvara tähtsus 1. 1. 1. Tarkvara evolutsiooniline roll 1. 1. 2. Tööstuse perspektiiv 1. 1. 3. Vananev tarkvaratehas 1. 2. Tarkvara 1. 2. 1. Tarkvara iseloomustus 1. 2. 2. Tarkvara komponendid 1. 2. 3. Tarkvara rakendused 1. 3. Tarkvara: kriis tulemas 1. 3. 1. Probleemid 1. 3. 2. Põhjused 1. 4. Tarkvara müüdid 1. 5. Tarkvaratehnika paradigmad 1. 5. 1. Tarkvaratehnika definitsioon 1. 5. 2. Klassikaline elutsükkel 1. 5. 3. Prototüüpimine 1. 5. 4. Spiraalmudel 1. 5. 5. Neljanda põlvkonna meetodid 1. 5. 6. Kombineeritud paradigmad 1. 6. Tarkvaratehnika geneeriline aspekt 3

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 langus), hajussüsteemid, tarkvara tellija (klient) 1990 - - 2000 : võimsad personaalarvutid, Internet, OO tehnoloogia, paralleelarvutused, ekspertsüsteemid, intellektitehnika Mä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 “ 4

Vajadus tarkvaratehnika (kui inseneridistsipliini) järele ligemale 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 kvaliteet ja standardid, mille järgimine tagaks nii arendustöö kui ka hoolduse efektiivsuse. 5

Müüdid = eksitavad hoiakud, levinud “tõekspidamised”, mis on visad kaduma. Tarkvara tootmise, arendustööde juhid, olles alalises pinges eelarve, töö graafiku ja 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 neid parima tehnikaga. Tegelikkus: Riistvara tipptase pole nii oluline. Kvaliteedi ja produktiivsuse 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 likvideerime mahajäämuse. Tegelikkus: See ei ole nii lihtne. Uusi inimesi saab otstarbekohaselt lisada ainult varem planeeritult ja hästi koordineeritud viisil. Tihtipeale ei arvestata, et uustulnuka lülitamine võtab tööd ja aega. Kui see jääb 6 projekti täitjate hooleks, siis ajalist efekti ei pruugi saadagi.

Tellija (kas klient - lõpptulemuse ootaja, või nt. teine koguprojekti alamtöö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 komponenti(desse) kergesti sisse viia, kuna tegemist on tarkvaraga (mis teatavasti on hõlpsasti muudetav). Tegelikkus: muudatusi nõuetes tuleb kindlasti ette, kuid nende arvessevõtmise raskus (ja paranduse maksumus) sõltub oluliselt sellest, millisel etapil see toimub: lähteülesande püstitamise ajal 1 arendustööde ajal 1, 5 - 6 hoolduse ajal 60 - 100. 7

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 formaalne meetod 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 konfiguratsioonist, kuhu kuuluvad ka nõuete spetsifikatsioon, kavandus, programmi tekst, andmestruktuuride kirjeldus, testimistulemused. Need on hädavajalikud tarkvara hoolduseks. 8

Tarkvaratehnika paradigmad Klassikaline elutsükkel (“kosk-mudel”) Süsteemianalüüs 4 GL Spetsifikatsioon neljanda põlvkonna keeles. Analüüs Kavandus autom. Kood Test Hooldus 9

Prototüüpimine Kiirkavandus Prototüüp Test Süsteemianalüüs Tellija hinnang Analüüs Kavandus Kood Test Hooldus 10

Spiraalmudel Planeerimine Nõuete kogumine ja projekti planeerimine Riskianalüüs Esialgne Vastavalt tellija reaktsioonile Projekti planeerimine vastavalt tellija hinnangule ? Stopp Prototüübina Tellija hinnang Produkti loomine 11

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 spetsifitseerimiskeelt (nt. 4 GL) kasutades. Testimine. Programm(süsteem)i võimalikult igakülgne katsetamine lähteülesandele vastavuse katseline kontrollimine. Avastatud vigade parandamine. 12

[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 minna pöördkonstrueerimist. [reverse engineering] 13

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

Riskianalüüs. Toimub pidevalt. Kaalutletakse ja hinnatakse “kahtlasi” momente, mis võiksid projektile (ja selle tähtaegsele valmimisele) saatuslikult mõjuda. Nt. 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. 15

[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/1000 tööviljakus = TKR/inimkuid kvaliteet = defekte/TKR hinnatase = kogumaksumus/KR dokumentatsioon = lk. arv/TKR 16

Funktsionaalsuse mõõtmine. [function-oriented metrics] Programmeerimiskeelest sõltumatu, kuid subjektiivne. Funktsioonpunktide meetod. [function-points] Sisendeid arv kaal(346) arv × kaal Väljundeid arv kaal(457) arv × kaal Päringuid arv kaal(346) arv × kaal Faile arv kaal(71015) arv × kaal Liideseid arv kaal(5710) arv × kaal Kokku Summa FP = Summa × (0. 65 + 0. 01 × (F 1 + F 2 + … +F 14)) kus Fi on järgmiste momentide hinnang 5 -punkti skaalal: F 1: taastuse vajadus [back-up; recovery] F 2: kommunikatsiooni vajadus F 3: leidub üldfunktsioone (mujal vajalikke) F 4: on aja-kriitiline F 5: töötab raskelt koormatud keskkonnas F 6: on otsekontakne [on-line] F 7: otsekontaktsus on transaktne (nt. multi-aknad) F 8: põhifailide otsekontaktne modifitseerimine F 9: sisend- ja väljundandmed, failid ja päringud on keerulised F 10: sisemine töötlus on keeruline F 11: kood on kavandatud taaskasutamist arvestades F 12: kavandis on ette nähtud konverteerimine ja installeerimine F 13. kuulub installeerimisele mitmetes erinevates asutustes 17 F 14: kavandis on arvestatud, et kasutamine/jooksev muutmine oleks kerge.

Tunnuspunktide meetod. Sisendeid arv Väljundeid arv Päringuid arv Faile arv Liideseid arv Algoritme arv Kokku kaal(4) kaal(5) kaal(4) kaal(7) kaal(3) [feature-points] arv × kaal arv × kaal Summa 18

Projekti juhtimine: hindamine Planeerimise etapil. Dekomponeerimisel põhinev hindamine. Käsuridade (KR) või punktide alusel. Põhifunktsioonid kasutajaliidese juhtimine (KL) 2 D-graafika (2 D) 3 D-graafika (3 D) andmestruktuuride haldamine (AS) graafikakuva juhtimine (GR) muude välisseadmete juhtimine (VS) disaini juhtimine (DS) 19

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

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

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

Tegevusmahu põhjal. F-n Analüüs Kavandamine Kodeerimine Testimine Kokku KL) 1, 0 2, 0 0, 5 3, 5 7, 0 2 D) 2, 0 10, 0 4, 5 9, 5 26, 0 3 D) 2, 5 12, 0 6, 0 11, 0 31, 5 AS) 2, 0 6, 0 3, 0 4, 0 15, 0 GR) 1, 5 11, 0 4, 0 10, 5 27, 0 VS) 1, 5 6, 0 3, 5 5, 0 16, 0 DS) 4, 0 14, 0 5, 0 7, 0 30, 0 Kokku 14, 5 61, 0 $kuu 5200 Hind 75400 4800 292800 26, 5 4250 112625 50, 5 4500 227250 152, 5 708075 23

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 orgaaniline autonoomne sisseehitatud d 0, 38 0, 35 0, 32 24

Töömahu [effort] E (inimkuudes) hindamine. 1. COCOMO baasmudel. [basic] Empiiriline valem: E = a (TKR) b , kus TKR - käsuridu (tuhandetes) ja a b orgaaniline 2, 4 1, 05 autonoomne 3, 0 1, 12 sisseehitatud 3. 6 1, 20 2. COCOMO täpsustatud mudel. [intermediate] E = a (TKR) b MKT, kus TKR - käsuridu (tuhandetes) ja a b orgaaniline 3, 2 (2, 8) 1, 05 autonoomne 3, 0 (2, 8) 1, 12 sisseehitatud 2, 8 1, 20 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). 25

COCOMO täpsustatud mudeli atribuutide tabel madal norm. kõrge Tarkvara usaldusväärsuse olulisus andmete maht ( / KR) keerukus 0, 77 0, 88 1, 00 1, 15 1, 40 - 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 rakenduslik kogemus keeleline kogemus virtuaalarvuti kogemus 1, 42 1, 17 1, 00 0, 86 0, 70 1, 24 1, 10 1, 00 0, 91 0, 82 - Projekt tarkvaratehnika meetodid automaatvahendite kasutus arendustööde graafik - 26

3. COCOMO detailne mudel. Vähem kasutatud. [advanced] 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, . . . 27

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 t 4/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 … telefonisüsteemid C = 8478 … kommerts C = 28240 vilets metoodika C=2000 hea metoodika C=8000 + automatis. C=11000 28

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

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 • kontrollimine standarditest kinnipidamise, aruannete esitamise jälgimine, töötulemuste mõõtmine, korrigeerivad tegevused, tasustus ja distsipliin 30

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) • loomine vs. soetamine • loomine vs. taasloomine (ümberkonstrueerimine) • teiste juhtimistegevuste planeerimine [scheduling] [acquisition] [re-engineering] 31

Riskid Analüü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 koos täitjatega (ressursitabel). Etapilõpud. [milestones] Organisatsioonilised küsimused sh. tiimi struktuur, aruandlusvormid, jälgimise ja kontrolli mehhanismid. Peaprogrammeerija tiim [chief programmer team] Peategija (plan. , koord. , retsenseerimine) Varumees Mitte tingimata täiskoormusega Tegijad (2 -5) { Tarkvarahoidja {Toetusgrupp} Erinõustaja(d) } Tehniline abitööjõud 32

Süsteemitehnika [computer system engineering] Süsteemi analüüs Iga 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 33

Süsteemi analüüs + • Süsteemi kontseptsioon (vajadus) [system concept (identification of need)] Põhiküsimused: loodav info, kasutatav info, peamised funktsioonid ja jõudlus mida 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) 34

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) 35

Süsteemi analüüs + Süsteemi spetsifikatsioon I. Sissejuhatus 1. Eesmärgid 2. Kitsendused II. Funktsioonide ja andmete kirjeldus 1. Üldine funktsionaalne arhitektuur 2. Üldine andmete arhitektuur III. Alamsüsteemide kirjeldused 1. . i. Sõnaline kirjeldus. Arhitektuur. Kitsendused. . IV. Modelleerimise tulemused. . V. Projekti esialgne plaan 1. Arenduskulud 2. Ajagraafik VI. Lisad 36

Tarkvaratehnika kolm faasi • defineerimine planeerimine tarkvara nõuete analüüs plaani täpsustamine [definition phase] => tarkvaraprojekti (esialgne) plaan => nõuete spetsifikatsioon => tarkvaraprojekti plaan • arendus üldine kavandamine kavandi detailiseerimine kodeerimine [development phase] => üldkavandi spetsifikatsioon => programmi kood • verifitseerimine, üleandmine, hooldus [verification, release, maintenance] testimine kvaliteedikontroll üleandmine kasutajale hilisvigade korrigeerimine, adapteerimine, laiendamine 37

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

Tarkvara nõuete analüüsi alused Nõuete analüüs Süsteemianalüüs Nõuete analüüs Planeerimine Tarkvara kavandamine (disain) Ülesanded • probleemi selgitamine [recognition] • lahkamine [evaluation] ja süntees • modelleerimine • spetsifitseerimine • ülevaatus [review] Analüütik Suhtlemisoskus, üldistamisoskus, võime mõelda abstraktsemates kategooriates, mõningane kompetents tark- ja riistvara alal. 39

Raskused Info 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) meetodid Omaette valdkond. Esimene kohtumine tellijaga (intervjuu). Koosolekute korraldamine, nt. FAST-vormis [Facilitated Application Specification Technigue]. Analüüsi printsiibid Valdkond (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üüpimine Kui (odavalt) teostatav, siis kindlasti. Spetsifitseerimine Analüüsi tulemuste (kirjalik) kokkuvõtmine, sh. valiidsuskriteeriumid. Igati nõuetekohane vormistus ja retsenseeritus. 40

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

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) Juhtimisprotsess Pidevandmed Protsess Juhtimisandmed Hatley-Pribhai (juhtvoo diagrammis) Juhtimisandmete ladu 42

Mudeli kihid C A D P 0 B F Tase 0 C A B E P 1 P 1 P 3 P 1 P 2 J S G H F P 1 P 4 I K L P 1 P 5 D F P 1 P 6 Tase 1 43

Protsessikirjeldus [PSPEC] Jutustavat laadi, eriti ülemistes kihtides. [narrative] P 0: Andmekirjeldus Enamasti olem-relatsiooni diagramm [ E-R, entitiy-relationship] 44

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

Juhtimiskirjeldus [CSPEC, control spetsification] 1. Olekumuutuste diagramm [STD, state transition diagram] Sündmus Olek . . . S[12] O[1]) . . . S[12] P 3; P 8 O[9] . . . O[9]) P 3; P 8 O[7] . . . 46

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 Operaatori sekkumine Rõhk liiga suur Pöörded alla normi. . . P 1 P 2. . . P 7 P 8 P 9. . . 0 1 1 0 0 0 0 0 1 Protsess P 1 P 2. . . s 1 s 2. . . 47

Koopiamasin. Andmevoo diagramm, tase 0. Klaviatuur Start/stopp A P 0 B Kuvar A: sisendandmed B: teated P 0: diagnoosib (kontrollib sisendandmeid, tuvastab kopeerimise võimalikkust), seab kopeerimise rezhiimi, juhib kopeerimist 48

Koopiamasin. Andmevoo diagramm, tase 1. teated A(sisendandmed) Sisendi töötlus Kuva juhtimine saadud korraldused rezhiim jooksev seis Koopiate valmistamise juhtimine veateated Diagnoosimine riistvara seisund Riistvara signaalide töötlemine 49

Objekt-orienteeritud nõuete analüüs Esialgne klasside/objektide nimekiri Potentsiaalne objekt <nimisõnad spetsifikatsioonist> Üldine liik välisolem asi sündmus roll organisatoorne koht struktuur(ne) 50

Objekti analüüsi mudelisse võtmise kriteeriumid (Coad, Yourdon) 1. Info objekti kohta on vajalik süsteemi funktsioneerimiseks. [Retained information] 2. Objekt omab teatavat hulka atribuutide muutmise operatsioone. [Needed services] 3. Atribuute on rohkem kui 1 (NB! nõuete analüüsil). [Multiple attributes] 4. Atribuudid on ühised selle klassi isenditele. [Common attributes] 5. Operatsioonid on ühised selle klassi isenditele. [Common operations] 6. See on süsteemile olulist infot andev infot tarbiv välisolem. [Essential requirements] 51

Mudelid objekt-orienteeritud analüüsis (Coad, Yourdon) I. Objektide identifitseerimine • Atribuutide spetsifitseerimine • Operatsioonide spetsifitseerimine • Objektidevaheline kommunikatsioon II. Struktuuride identifitseerimine Liigitus [classification] Kooslus [assembly] 52

III. Alamosade määratlemine [defining subjects] IV. Objektiseosed [object connections] 0: 1 1: 1 0: palju 1: palju V. Teateseosed [message connections] 53

Kasutajaliidese kavandamine Inimfaktorid taju [perception] oskuste tase ja käitumine [skill level, behavior] psühholoogiline skaala riskialtis, kohusetundlik, impulsiivne muretsev, stressi taluv, motiveeritud mitmesust salliv, aktiivne, paremakäeline kasutaja tööülesanded [tasks] kommunikatsioon dialoog tunnetus juhtimine Arvutiga suhtlemise stiil [styles of human-computer interaction] käsurida lihtmenüü aknad, rippmenüüd, hiir [windows, icons, menus, pointing - WIMP] 54

Suhtlusliidese kavandamine Lä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 modelleerimine tööülesannete väljaselgitamine tavategevustest lähtudes objektidest lähtudes iga tööülesande korral eesmärgid/kavatsused iga eesmärgi/kavatsuse korral tegevuste järjend olek (liidese vorm) iga tegevuse ajal kasutajapoolsed juhtimismehhanismid oleku muutmiseks kuidas juhtimismehhanismid mõjutavad olekut kuidas kasutaja interpreteerib süsteemi olekut liidesest saadava info abil 55

Eriküsimused reaktsiooniaeg abi-info vahendid veakäsitlus käsunimed Realiseerimise vahendid [response time] [help facilities] [error information handling] [command labeling] Kavandi hindamine Eelkavand Esimene prototüüp Järjekordne prototüüp Valmis Kasutaja hinnang Kavandaja otsus 56

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 tegevusele võimalda kerget tagasivõttu võimalikult igale tegevusele minimiseeri tegevuste vahel meeldejätta tulev info taotle dialoogi, liikumise ja mõtlemise efektiivsust andesta vead liigita tegevused funktsioonide järgi, vastavalt grupeeri ekraanil taga kontekstne abi-info kasuta käaskude nimedena lihtsaid verbe (verbirühmi) Andmekuva ainult asja(jooksva konteksti)kohast infot ära koorma kasutajat arv- ja tekstiandmetega, kui saab teisiti kasuta ühtseid märgendeid, standardseid lühendeid ja värve võimalda kasutajal mõista asukohta visuaalses konrekstis anna arusaadavaid veateateid rakenda soodsat tekstiformaati (suur/väiketähed, taanded, grupid) kasuta eri aknaid erinevat tüüpi andmete samaaegseks kuvaks kasuta “analoog”-vormi, kus sobib 57 kasuta ekraani kasutajale soodsal viisil

Andmesisestus minimiseeri sisestustegevuste arv hoolitse andmekuva ja andmesisestuse kooskõlalisuse eest võimalda valida erineva tasemega sisestusrežiime [customize] võimalda valida suhtlusstiili deaktiveeri jooksvas kontekstis võimatud käsud lase kasutajal juhtida suhtlust taga abi-info iga sisestustegevuse jaoks elimineeri kõik liiasused (ühik, null murdosana, vaikeväärtused, arvutatavad väärtused) 58

Kvaliteedi tagamine [Quality Assurance] Tarkvara kvaliteedi faktorid Korrektsus [Correctness] Usaldusväärsus [Reliability] Efektiivsus [Efficiency] Turvalisus [Integrity] Kasutatavus [Usability] Hooldatavus [Maintainability] Paindlikkus [Flexibility] Testitavus [Testability] Portatiivsus [Portability] Taaskasutatavus [Reusability] Ristkasutatavus [Interoperability] 59

Tarkvara kvaliteedi meetrika [metrics] Auditeeritavus [Auditability] Akuraatsus [Accuracy] Arvutuste ja juhtimise täpsus Kommunikatsiooni ühtlus [Communication commonality] Standardprotok. Täielikkus [Completeness] Kõik funktsioonid Sisutihedus [Conciseness] Ühtlus [Consistency] Arendusmetoodika Andmeühtlus [Data commonality] Standardsed andmestr. ja -tüübid Veataluvus [Error tolerance] Tekkiv kahju Täitmisefektiivsus [Execution efficiency] Käitusaegne sooritus Laiendatavus [Expandability] Kavandi laiendamine Üldisus [Generality] Potentsiolsed rakendused Riistvara-sõltumatus [Hardware independence] Instrumentaalsus [Instrumentation] Enesemonitooring Modulaarsus [Modularity] Opereeritavus [Operability] Käsitluslihtsus 60

Turvalisus [Security] Programmide ja andmete kaitse Dokumenteeritus [Self-documentation] Lihtsus [Simplicity] Arusaadavus Tarkvaraline sõltumatus [Software system independence] Keele/OS veidr. Jälgitavus [Traceability] Kavand --> nõuded Väljaõpe [Training] Õppimisabi kasutajale FURPS (Hewlett-Packard) Deatail. Kavandam. Realiseerim. Test. Tugi Functionality Usability Reliability Performance Supportability Projektijuht: olulisimad kvaliteedi faktorid; juba algusest peale. 61

Proj. audit. Eneseparand. Personali arend. Kvalit. ressurs. Stand. ja prots. Aruand. üles ISO 9001 Kvaliteedi juhtimise süsteem Kvaliteedi juhendmaterjalid Standardid Protseduurid Juhtimine Väljanägem. Kuidas arend. Kuidas kv. tag. Projekt 1 Projekt 2 Projekt 3 Projekt 4 Kvaliteedi plaan 1 Kvaliteedi plaan 2 Kvaliteedi plaan 3 Kvaliteedi plaan 4 Kuidas/millele rakend. ülevaat. , testi aspektid, aruandlus, stand. jälgim. 62

Testimine Andmevoo diagramm tarkvara testimine tulemuste analüüs vead testandmed veasageduse andmed silumine usaldusväärsuse mudel parandused usaldusväärsuse prognoos 63

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

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 vastavalt kasutava keskkonna muutustele. [enhancement] [perfective maintenance] Täiustamine (täiustav hooldus). Tarkvara modifitseerimine vastavalt tellija/kasutaja uutele, täiendavatele soovidele. Võib vaja minna pöördkonstrueerimist. [reverse engineering] [preventive maintenance] Ennetamine (preventiivne hooldus). Tarkvara hooldatavuse ja usaldusväärsuse parandamine edasise täiustamise paremaks tagamiseks. 65

Hooldustegevus Hoolduse maht (hind) --- Antud: tarkvara konfiguratsioon, --hooldusnõue Uurida kavandit (projekti) Planeerida tegevused M = p + K e (c - d ) Modifitseerida kavand Rekodeerida Ülevaatus: korras? Regressioontestid --- Tulemus: uus väljalase tuttavlikkuse mõõt keerukuse mõõt, pöördvõrdeline kvaliteediga empiiriline konstant vahetu produktiivne töö (kavandi uurimine, modifitseerimine, rekodeerimine) 66

Hoolduse raskuste põhjusi • Hooldatava tarkvara loomise protsessi ebaselgus. -- mõistmine raske võimatu • Hooldatava tarkvara evolutisooni ebaselgus. Muutused (versioonide, väljalasete jt. muudatuste tekkimine dokumenteerimata. -- mõistmine raske 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. 67

Hoolduse organisatsioon Hoolduse aruandlus Hoolduse korraldamine Hooldusnõ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 pöördkonstrueerimine ümberkonstrueerimine [alien or legacy software] [reverse engineering] [re-engineering] 68

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 69

Muudatuste juhtimine Konfiguratsiooni objekti muutmine [change control] Sisseregistreerimine Konfiguratsiooni objekt (muudetud versioon) Avada Konfiguratsiooni objekt (lävejoone versioon) Audit. info Tarkvara insener Konfiguratsiooni objekt (väljavõetud) Juurdepääsu kontroll Lukustada Konfigurats. andmebaas Konfiguratsiooni objekt (lävejoone versioon) Väljaregistreerimine 70

Muudatuste juhtimine Tarkvara muutmine Muudatuse nõude kirjeldus Muudatuste juht otsustab Nõue järjekorda Muudatuse nõue tagasi lükatud Tellimus (order) Muudatuste tegijad igale konf. objektile Konfig. objektide muutmine Kvaliteedi tagamise ja testimistegevused Uued versioonid Kõikide muudatuste audit Uus tarkvara versioon 71

CVS Version Control System Versioonijuhtimise süsteem http: //www. cvshome. org/ http: //www. cs. ut. ee/~kiho/SE/ CVS. ps 72

Põhimõisted • repositoorium • töökataloog • moodul • versioonide numeratsioon [repository] [working directory] [module] [revisions, releases] • töösse võtmine • tagasi panemine • töökataloogi kustutamine • erinevuste leidmine • failide/kataloogide lisamine/kustutamine [checkout] [commit] [release] [diff] [add, remove] Grupitöö faili olek tööfaili uuendamine teiste jälgimine [Multiple developers] [status] [update] [watch, watchers, editors] 73