Tarkvaratehnika Software Engineering

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

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

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

4. 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 “

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

6. 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 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. Tihtipeale • ei 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, millisel • etapil see toimub: • lähteülesande püstitamise ajal 1 • arendustööde ajal 1,5 - 6 • hoolduse 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 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 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 4GL Spetsifikatsioon neljanda põlvkonna keeles. Analüüs Kavandus autom. Kood Test Hooldus

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

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

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 minna pöö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/1000 • tööviljakus = TKR/inimkuid • kvaliteet = defekte/TKR • hinnatase = kogumaksumus/KR • dokumentatsioon = 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 × kaal Väljundeid arv kaal(4\5\7) arv × kaal Päringuid arv kaal(3\4\6) arv × kaal Faile arv kaal(7\10\15) arv × kaal Liideseid arv kaal(5\7\10) arv × kaal Kokku 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 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 F10: sisemine töötlus on keeruline F11: kood on kavandatud taaskasutamist arvestades F12: kavandis on ette nähtud konverteerimine ja installeerimine F13. kuulub installeerimisele mitmetes erinevates asutustes F14: kavandis on arvestatud, et kasutamine/jooksev muutmine oleks kerge.

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

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

20. Hinnangulised F-n Optim. Tõen. Pessim. Oodatav $/rida Rida/kuus HindKuid KL) 1800 2400 2650 2340 14 315 327607,4 2D) 4100 5200 7400 5380 20 220 3D) 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

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

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

23. Tegevusmahu põhjal. F-n Analüüs Kavandamine Kodeerimine Testimine Kokku KL) 1,0 2,0 0,5 3,5 7,0 2D) 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,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 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 • d • orgaaniline 0,38 • autonoomne 0,35 • sisseehitatud 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 b orgaaniline 2,4 1,05 autonoomne 3,0 1,12 sisseehitatud 3.6 1,20 a b orgaaniline 3,2 (2,8) 1,05 autonoomne 3,0 (2,8) 1,12 sisseehitatud 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=8000 telefonisü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 • kontrollimine • standarditest 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. 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, 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 Tegijad (2-5) {Toetusgrupp} { } Erinõus- taja(d) Tehniline abitööjõud Tarkvara- hoidja Mitte tingimata täiskoormusega

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

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

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

37. Tarkvaratehnika kolm faasi • defineerimine [definition phase] • planeerimine => tarkvaraprojekti (esialgne) plaan • tarkvara nõuete analüüs => nõuete spetsifikatsioon • plaani täpsustamine => tarkvaraprojekti plaan • arendus [development phase] • üldine kavandamine => üldkavandi spetsifikatsioon • kavandi detailiseerimine => kavandi spetsifikatsioon • kodeerimine => programmi kood • verifitseerimine, üleandmine, hooldus [verification, release, maintenance] • testimine • kvaliteedikontroll • üleandmine kasutajale • hilisvigade 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üüs Süsteemi- analüüs Nõuete analüüs Tarkvara kavandami- ne (disain) Planeeri- mine • Ü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.

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

41. Tarkvara nõuete spetsifikatsioon ÜldosaKoht 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. ViitedKirjandus, 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 Juhtimis- protsess Protsess Hatley-Pribhai (juhtvoo diagrammis) Pidev- andmed Andmed Juhtimis- andmed Andmeladu, -fail(id) Juhtimisandmete ladu

43. Mudeli kihid C A D P0 B F Tase 0 C A G D P1 E P1 P5 P1 P1 P3 H F B P1 P4 P1 I F P2 P1 P6 K L J Tase 1 S

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ündmus Olek . . . S[12] . . . O[1]) . . . O[9]) P3; P8 O[7] . . . S[12] P3; P8 O[9] O[7]

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 0 Rõhk liiga suur 0 0 0 1 0 Pöörded alla normi 0 0 0 0 1 . . . Protsess s1 s2 . . . P1 P2 . . .

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

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

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