sissejuhatus tarkvara rolli evolutsioon 1950 - 1960+ : paketttöötlus, “oma” (lokaalne)...
DESCRIPTION
Sissejuhatus Tarkvara rolli evolutsioon 1950 - 1960+ : paketttöötlus, “oma” (lokaalne) tarkvara 1960+ - 1970+ : multitöötlus, distributeeritav tarkvara (produkt), andmebaasid, reaalaja tarkvara 1970+ - 1990- : mikroelektroonika (hinna ja mõõtmete drastiline - PowerPoint PPT PresentationTRANSCRIPT
1
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 “
2
Vajadus tarkvaratehnika (kui inseneridistsipliini) järeleligemale 30 viimase aasta jooksul täheldatakse tarkvara “kriisi”, õigemini kroonilisi hädasid :välisest vaatekohast (tellijad, mänedžerid)
• miks programmprodukti valmimine on nii ajakulukas• miks hind on nii soolane• miks ei leita kõiki vigu enne tellijale/ostjale üleandmist• miks on tarkvara arendusprotsessi raske jälgida
asjatundjate vaatekohast• arendustöö graafik ja kulude hinnangud on ülimalt ebatäpsed• tarkvara-inimeste produktiivsus ei vasta vajadustele• tarkvara kvaliteet on pahatihti lubamatult madal• olemasolevat tarkvara on väga raske ja kulukas hooldada
Kokkuvõttes, tarkvaratehnika olemuseks on metodoloogia, sihitusega võimalikult adekvaatselt rahuldada üha kasvavat nõudmist optimaalse kvaliteedi ja hinna suhtega tarkvara järele. Selle fookuses on tarkvara loomise protsessi enda kvaliteetja standardid, mille järgimine tagaks nii arendustöö kui ka hoolduse efektiivsuse.
3
Müüdid = eksitavad hoiakud, levinud “tõekspidamised”, mis on visad kaduma.
Tarkvara tootmise, arendustööde juhid, olles alalises pinges eelarve, töö graafikuja tulemuse kvaliteedi pärast, kalduvad kergesti uskuma nt. järgmisi müüte.
• Meil on raamat(ud) standardite ja protseduurireeglitega. Seega on mu inimesed varustatud vajalike teadmistega.Tegelikkus: Kas seda ikka kasutatakse? Või üldse teatakse? Kas see on piisavalt kaasaegne ja täielik? Enamasti on vastuseks ei.
• Meie inimestel on kaasaegsed arendusvahendid. Pealegi varustame neidparima tehnikaga.Tegelikkus: Riistvara tipptase pole nii oluline. Kvaliteedi ja produktiiv-suse aspektist on automatiseeritud arendusvahendid küll tähtsad, kuid enamus tarkvara arendajatest neid siiski ei kasuta.
• Kui jääme graafikust maha, siis lisame projekti uusi inimesi ja likvidee-rime mahajäämuse.Tegelikkus: See ei ole nii lihtne. Uusi inimesi saab otstarbekohaselt lisada ainult varem planeeritult ja hästi koordineeritud viisil. Tihtipealeei arvestata, et uustulnuka lülitamine võtab tööd ja aega. Kui see jääb projekti täitjate hooleks, siis ajalist efekti ei pruugi saadagi.
4
Tellija (kas klient - lõpptulemuse ootaja, või nt. teine koguprojekti alam-töörühm) ilmutab tihti pealiskaudset suhtumist ülesande formuleerimise osas.
• Kui on olemas üldine ülesande püstitus, siis võib lasta hakata programme kirjutama. Detailid täpsustame hiljem.Tegelikkus: Ebaselge lähteülesanne on üks peamisi vigu. Tingimata on vaja formaalset ja detailset kirjeldust, milles piiritletakse valdkond, funktsioon, jõudlus, liidesed, kavanduskitsendused ja valideerimise kriteerium. Seda saab teha vaid tellija ja arendaja tihedas koostöös.
• Parandused seoses muutustega projekti nõuetes saab tarkvara kompo-nenti(desse) kergesti sisse viia, kuna tegemist on tarkvaraga (mis teatavasti on hõlpsasti muudetav).Tegelikkus: muudatusi nõuetes tuleb kindlasti ette, kuid nende arvesse-võtmise raskus (ja paranduse maksumus) sõltub oluliselt sellest, milliseletapil see toimub:
lähteülesande püstitamise ajal 1arendustööde ajal 1,5 - 6hoolduse ajal 60 - 100.
5
Programmeerijate seas on levinud nt. järgmised eksiarvamused.
• Minu töö on tehtud, kui olen kirjutanud programmi ja selle käima saanud.Tegelikkus: Siin pole päris selge, mida mõista käima saamise all. Igatahes on teada, et 50 -70 protsenti kogu tööst, mis ühele programmile kulub, tehakse pärast seda, kui programm on esimest korda kasutajale/tellijale üle antud.
• Kuni ma pole programmi käima saanud pole kuidagi võimalik selle kvaliteeti hinnata.Tegelikkus: On küll - nimelt projekti jooksva inspekteerimise käigus, mil rakendatakse nn. tarkvara arvustust [software review]. See formaalnemeetod on osutunud isegi efektiivsemaks kui testimine.
• Eduka projekti tulemuseks (üleantavaks produktiks) on laitmatult töötav programm.Tegelikkus. Töötav programm on ainult üks osa tarkvara konfiguratsioo-nist, kuhu kuuluvad ka nõuete spetsifikatsioon, kavandus, programmi tekst, andmestruktuuride kirjeldus, testimistulemused. Need on hädavaja-likud tarkvara hoolduseks.
6
Tarkvaratehnika paradigmad
Klassikaline elutsükkel (“kosk-mudel”)
Süsteemianalüüs
Analüüs
Kavandus
Kood
Test
Hooldus
4GLSpetsifikatsioon neljanda põlvkonna keeles.
autom.
7
Süsteemianalüüs
Analüüs
Kavandus
Kood
Test
Hooldus
Kiirkavandus
Test
Prototüüp
Tellija hinnang
Prototüüpimine
8
Planeerimine Riskianalüüs
Tellija hinnang Produkti loomine
Nõuete kogumine japrojekti planeerimine
Projekti planeeriminevastavalt tellija hinnangule
Esialgne
Vastavalt tellija reaktsioonile
? Stopp
Prototüübina
Spiraalmudel
9
Tarkvara konstrueerimise etapid
1. Defineerimine (sätestamine) - mida tuleb teha? [definition] Süsteemianalüüs. Millised on koht ja seosed hõlmavas süsteemis.
Loodava süsteemi otstarve ja eesmärk. Tarkvaraprojekti planeerimine. Riskide analüüsimine, ressursside
määratlemine, maksumuse hindamine, tööülesannete ja -graafiku fikseerimine.
Nõuete analüüs. Detailse lähteülesande püstitamine kõiki nõudeid arvesse võttes.
2. Arendamine (arendustöö) - programmsüsteemi loomine. [development]Kavandamine. Nõuetele vastavalt kirjeldatakse (loomulikus keeles
ja/või graafiliselt ja/või tabelitena jm.) loodava süsteemi andmestruktuurid, arhitektuur, protseduurid, liidesed.
Kodeerimine. Tulemuseks on arvuti programm(süsteem). See saadakse kavandi realiseerimisel mingit programmeerimis- või spetsi-fitseerimiskeelt (nt. 4GL) kasutades.
Testimine. Programm(süsteem)i võimalikult igakülgne katsetamine - lähteülesandele vastavuse katseline kontrollimine. Avastatud vigade parandamine.
10
[maintenance]3. Hooldus (olemasoleva tarkvara korral). Enamasti kaasneb ka defineerimise ja
arendamise etappide taasrakendamine. [correction]
Korrigeerimine (korrigeeriv hooldus). Kasutamisel avastatud vigade korrigeerimine.
[adaption]Kohandamine (kohandav hooldus). Tarkvara modifitseerimine vastavalt
kasutava keskkonna muutustele.[enhancement]
Täiustamine (täiustav hooldus). Tarkvara modifitseerimine vastavalt tellija/kasutaja uutele, täiendavatele soovidele. Võib vaja minnapöördkonstrueerimist. [reverse engineering]
11
Projekti juhtimise protsess
Projekti juhtimine toimub pidevalt, alates selle algusest kuni lõpuni.
Alustamine: koos tellijaga sätestatakse eesmärk ja ulatus. [scope]Eesmärk - üldine, mida on vaja? (Lahus sellest, kuidas?).Ulatus - üldine funktsionaalsuse (funktsioonide) kirjeldus,
kuid juba koos selle piirangutega.Alternatiivid - arutatakse läbi, millised (alternatiivsed)
lahendusteed tulevad arvesse.Mõõdud ja meetrika. [measures; metrics]
Mõõdetakse nii tehnilist protsessi ennast (et seda parandada)kui ka tulemust (et tagada selle kvaliteeti) ja ressursse.
Hindamine [estimation] on eeskätt aluseks planeerimisel (inimtöö maht, kestus, maksumus). Vastavad hindamise meetodid, lisaks kogemusele.
Kasutatakse korraga mitmeid meetodeid. Seejuures• eeldatakse, et projekti ulatus on eelnevalt kindlaks määratud• baasina kasutatakse varasemaid mõõtmistulemusi• projekti osi hinnatakse eraldi.
12
Riskianalüüs. Toimub pidevalt. Kaalutletakse ja hinnatakse “kahtlasi” momente, mis võiksid projektile (ja selle tähtaegsele valmimisele) saatuslikult mõjuda. Nt. kas kasutaja nõuded on ikka tegelikult õigesti mõistetud, kas on karta graafikust mahajäämist, kas paistab tulevat ootamatuid tehnilisi probleeme.
Ajakava. [scheduling]See on alati küll olemas, kuid peab olema kvaliteetne.
Jälgimine ja juhtimine. [tracking; control]Eeskätt ajakava osas. Mahajäämuste (ennetav) likvideerimine.
13
[metrics; measurement]Projekti juhtimine: tarkvara meetrika (mõõtmine, mõõdistus)
• 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
14
Funktsionaalsuse mõõtmine. [function-oriented metrics]Programmeerimiskeelest sõltumatu, kuid subjektiivne.Funktsioonpunktide meetod. [function-points]
Sisendeid arv kaal(3\4\6) arv × kaalVäljundeid arv kaal(4\5\7) arv × kaalPäringuid arv kaal(3\4\6) arv × kaalFaile arv kaal(7\10\15) arv × kaalLiideseid arv kaal(5\7\10) arv × kaalKokku Summa
FP = Summa × (0.65 + 0.01 × (F1 + F2 + … +F14))kus Fi on järgmiste momentide hinnang 5-punkti skaalal:F 1: taastuse vajadus [back-up; recovery]F 2: kommunikatsiooni vajadusF 3: leidub üldfunktsioone (mujal vajalikke)F 4: on aja-kriitilineF 5: töötab raskelt koormatud keskkonnasF 6: on otsekontakne [on-line] F 7: otsekontaktsus on transaktne (nt. multi-aknad)F 8: põhifailide otsekontaktne modifitseerimineF 9: sisend- ja väljundandmed, failid ja päringud on keerulisedF10: sisemine töötlus on keerulineF11: kood on kavandatud taaskasutamist arvestadesF12: kavandis on ette nähtud konverteerimine ja installeerimineF13. kuulub installeerimisele mitmetes erinevates asutustesF14: kavandis on arvestatud, et kasutamine/jooksev muutmine oleks kerge.
15
Tunnuspunktide meetod. [feature-points]Sisendeid arv kaal(4) arv × kaalVäljundeid arv kaal(5) arv × kaalPäringuid arv kaal(4) arv × kaalFaile arv kaal(7) arv × kaalLiideseid arv kaal(7) arv × kaalAlgoritme arv kaal(3) arv × kaalKokku Summa
16
Projekti juhtimine: hindamine Planeerimise etapil.
Dekomponeerimisel põhinev hindamine.Käsuridade (KR) või punktide alusel.
Põhifunktsioonidkasutajaliidese juhtimine (KL)2D-graafika (2D)3D-graafika (3D)andmestruktuuride haldamine (AS)graafikakuva juhtimine (GR)
muude välisseadmete juhtimine (VS)disaini juhtimine (DS)
17
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
18
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
19
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
20
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
21
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
22
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
23
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
24
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, ...
25
Putnami mudel [Putnam Estimation Model]
Eeskätt väga suurte tarkvaraprojektide korral (30 inimaastat ja rohkem).Dünaamiline, sisaldab (projekti, töö kestust).
Baseerub tarkvara võrrandil (Rayleigh-Nordeni kõvera kirjeldusest)L = C (K/B)1/3 t4/3
(tulemuse maht) = C ((töö kogumaht)/B)1/3 (töö aeg e. kestus)4/3
KR inimaastad kalendriaastad B on projekti mahulise taseme faktor TKR < 20, B = 0,16; TKR ~ 20, B = 0,18; TKR ~ 30, B = 0,28; TKR ~ 40, B = 0,34; TKR ~ 50, B = 0,37; TKR > 60, B = 0,39. C on tootlikkuse (tööviljakuse) faktor, saadakse tarkvara võrrandi lahendamisel valminud projektide korral (üle 2000, 1990.a), reaalajasüsteemid C = 3238 vilets metoodika C=2000
… hea metoodika C=8000telefonisüsteemid C = 8478 + automatis. C=11000
…kommerts C = 28240
26
SLIM (Putman)jt. automatiseeritud abivahendid, sh. juba ka funktsioonpunktide ja tunnuspunktide alusel.
27
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
28
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
29
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{ }
30
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
31
Süsteemi analüüs +•Süsteemi kontseptsioon (vajadus) [system concept (identification of need)]
Põhiküsimused: loodav info, kasutatav info, peamised funktsioonid ja jõudlusmida kasutaja vajab (oluline),mida kasutaja tahab (kuid pole nii oluline)
Eriküsimused: kas vajalik tehnoloogia eksisteerib,millised eriarendused ja -toomisbaas on vajalikud,millised on hinna- ja ajapiirangud,potentsiaalne turg (kui tehakse müügiks)jm.
Süsteemi kontseptsioon (dokument)
32
Süsteemi analüüs +•Teostuvusuuring [feasibility study] majanduslik teostuvus, tehniline teostuvus, juriidiline teostuvus,
alternatiivide puudumine.Kui on ilmsed, siis pole (erilist uuringut) tarvis.
Majanduslik teostuvus: ~majanduslik analüüs, ~ kasu(hüved)/hind(kulutused)
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)
33
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
34
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
35
Esmakontakt tellijaga Koosolekud tellijaga [FAST meeting] Tulemuste (turu)hinnang Luua esialgne kirjeldus Esialgne kirjeldus kinnitatud Süsteemitehniline analüüs Määrata süsteemi elemendid Majanduslik teostuvusuuring Süsteemi mudelid Simulatsioon Süsteemi revideerimine Luua süsteemi kirjeldus Süsteemi kirjeldus kinnitatud
. . .
36
Tarkvara nõuete analüüsi alused
Nõuete analüüsSüsteemi-analüüs
Nõuete analüüs Tarkvara
kavandami-ne (disain)
Ülesanded• probleemi selgitamine [recognition]• lahkamine [evaluation] ja süntees• modelleerimine• spetsifitseerimine• ülevaatus [review]
Planeeri-mine
AnalüütikSuhtlemisoskus, üldistamisoskus, võime mõelda abstraktsemateskategooriates, mõningane kompetents tark- ja riistvara alal.
37
RaskusedInfo kättesaamine, selle täielikkus; suhtlemine, eesmärkide muutuvus, vasturääkivused (ka varasemaga), mida üldse tahetakse?, alternatiivide käsitlemine, kiustaus lakoniseerida, kohati “üle nurga lasta”.
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.
38
Tarkvara nõuete spetsifikatsioon
Üldosa Koht süsteemis (~ süsteemi sptsifikatsioon); üldine kirjeldus, kitsendused (~ projekti plaan).
Info [Information description] Info sisu ja vood, info esitusviis(id), süsteemi liidesed.
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.
39
Struktuurne analüüs ja selle laiendused
Andmevoo diagramm [DFD, data flow diagram]
Sümboolika
Väline olem [external entity] Ward-Mellor
Protsess
Andmed
Andmeladu, -fail(id)
Juhtimis-andmed
Juhtimisandmete ladu
ProtsessJuhtimis-protsess
Hatley-Pribhai(juhtvoo diagrammis)
Pidev-andmed
40
Mudeli kihid
P0
A
B
C
D
F
A
B
P1P1
P1P2
P1P3
P1P4
P1P5
P1P6
C
D
F
Tase 0
Tase 1
E
F
GHI
S
J K L
41
Protsessikirjeldus [PSPEC]
Jutustavat laadi, eriti ülemistes kihtides. [narrative]
P0:
Andmekirjeldus
Enamasti olem-relatsiooni diagramm [ E-R, entitiy-relationship]
42
Juhtimisvoo diagramm [CFD, control flow diagram]
Lihtsamatel juhtudel lisatakse andmevoo diagrammile juhtimisprotsessid ja juhtimisinfo (sündmuste) liikumine.
Keerulisematel juhtudel tehakse eraldi diagramm, mis sisaldab kõik protsessid, juhtimisinfo (sündmuste) tekkimise ning sisenemised juhtimiskirjeldusse. Ei sisalda andmete liikumise nooli.
43
Juhtimiskirjeldus [CSPEC, control spetsification]
1. Olekumuutuste diagramm [STD, state transition diagram]
SündmusOlek . . . S[12] . . .
O[1])
. . . O[9]) P3; P8 O[7]
. . .
O[9]
O[7]
S[12]P3; P8
44
2. Juhtimiskirjeldus fikseerib, kuidas reageeritakse erinevatele sündmustele. Millised protsessid milliseid sündmusi võivad esile kutsuda.
Protsesside aktiviseerimise tabel [PAT, Process Activation Table]
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. . .
45
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
46
Koopiamasin.Andmevoo diagramm, tase1.
A(sisendandmed)
Sisendi töötlus
Koopiatevalmistamisejuhtimine
Diagnoo-simine
Kuvajuhtimine
Riistvarasignaalidetöötlemine
teated
saadud korraldused
rezhiim
riistvara seisund
rezhiimjooksev seis
veateated
47
Objekt-orienteeritud nõuete analüüs
Esialgne klasside/objektide nimekiri
Potentsiaalne objekt Üldine liik
<nimisõnad spetsifikatsioonist> välisolemasisündmusrollorganisatoornekohtstruktuur(ne)
48
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]
49
• Atribuutide spetsifitseerimine
• Operatsioonide spetsifitseerimine
• Objektidevaheline kommunikatsioon
I. Objektide identifitseerimine
Mudelid objekt-orienteeritud analüüsis (Coad, Yourdon)
II. Struktuuride identifitseerimine
Liigitus [classification]
Kooslus [assembly]
50
III. Alamosade määratlemine [defining subjects]
IV. Objektiseosed [object connections]
V. Teateseosed [message connections]
0:1 1:1 0:palju 1:palju
51
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]
52
Suhtlusliidese kavandamineLähtemudelid
tarkvara kavand [design model]kasutajamudel [user model]kasutaja mudel, süsteemi tajumine [user’s model, system perception]süsteemi imidž [system image]
Tööülesannete analüüs ja modelleeriminetööülesannete väljaselgitamine
tavategevustest lähtudesobjektidest lähtudes
iga tööülesande korraleesmärgid/kavatsusediga eesmärgi/kavatsuse korral
tegevuste järjendolek (liidese vorm) iga tegevuse ajal
kasutajapoolsed juhtimismehhanismid oleku muutmisekskuidas juhtimismehhanismid mõjutavad olekutkuidas kasutaja interpreteerib süsteemi olekut liidesest saadava
info abil
53
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
54
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
55
Andmesisestusminimiseeri sisestustegevuste arvhoolitse andmekuva ja andmesisestuse kooskõlalisuse eestvõimalda valida erineva tasemega sisestusrežiime [customize]võimalda valida suhtlusstiilideaktiveeri jooksvas kontekstis võimatud käsudlase kasutajal juhtida suhtlusttaga abi-info iga sisestustegevuse jaoks elimineeri kõik liiasused (ühik, null murdosana, vaikeväärtused,
arvutatavad väärtused)
56
Kvaliteedi tagamine [Quality Assurance]
Tarkvara kvaliteedi faktoridKorrektsus [Correctness]Usaldusväärsus [Reliability]Efektiivsus [Efficiency]Turvalisus [Integrity]Kasutatavus [Usability]Hooldatavus [Maintainability]Paindlikkus [Flexibility]Testitavus [Testability]Portatiivsus [Portability]Taaskasutatavus [Reusability]Ristkasutatavus [Interoperability]
57
Tarkvara kvaliteedi meetrika [metrics]
Auditeeritavus [Auditability]Akuraatsus [Accuracy] Arvutuste ja juhtimise täpsus
Kommunikatsiooni ühtlus [Communication commonality] Standardprotok.
Täielikkus [Completeness] Kõik funktsioonidSisutihedus [Conciseness]Ühtlus [Consistency] ArendusmetoodikaAndmeühtlus [Data commonality] Standardsed andmestr. ja -tüübidVeataluvus [Error tolerance] Tekkiv kahjuTäitmisefektiivsus [Execution efficiency] Käitusaegne sooritusLaiendatavus [Expandability] Kavandi laiendamineÜldisus [Generality] Potentsiolsed rakendusedRiistvara-sõltumatus [Hardware independence]Instrumentaalsus [Instrumentation] EnesemonitooringModulaarsus [Modularity]Opereeritavus [Operability] Käsitluslihtsus
58
Turvalisus [Security] Programmide ja andmete kaitseDokumenteeritus [Self-documentation]Lihtsus [Simplicity] ArusaadavusTarkvaraline sõltumatus [Software system independence] Keele/OS veidr.Jälgitavus [Traceability] Kavand --> nõudedVäljaõpe [Training] Õppimisabi kasutajale
FURPS (Hewlett-Packard) Deatail. Kavandam. Realiseerim. Test. Tugi
FunctionalityUsabilityReliabilityPerformanceSupportability
Projektijuht: olulisimad kvaliteedi faktorid; juba algusest peale.
59
ISO 9001
Kvaliteedi juhtimise süsteem
Kvaliteedi juhendmaterjalid
StandardidProtseduuridJuhtimine
Projekt 1
Kvaliteediplaan 1
Projekt 2
Kvaliteediplaan 2
Projekt 3
Kvaliteediplaan 3
Projekt 4
Kvaliteediplaan 4
Proj. audit.Eneseparand.Personali arend.Kvalit. ressurs.Stand. ja prots.Aruand. üles Väljanägem.
Kuidas arend.Kuidas kv. tag.
Kuidas/millele rakend. ülevaat., testi aspektid, aruandlus, stand. jälgim.
60
Testimine
tarkvara
testandmed
testimine
tulemuste analüüs
silumine
usaldusväär-suse mudel
tulem
veasageduseandmed
vead
parandused
usaldusväärsuseprognoos
Andmevoo diagramm
61
Testimisstrateegiad• musta kasti meetod (testitakse funktsionaalsust)• valge kasti meetod (testitakse siseehitust)
Valge kasti meetod
Teoreetiliselt tuleks läbi proovid kõik teed. Praktiliselt võimatu.Kontsentreerutakse tähtsamatele teedele.1. Iga sõltumatu tee - vähemalt üks kord.2. Kõik loogilised kontrollid - nii - kui ka + .3. Tsüklid - nii ääreväärtustel, kui ka (mõnedel) normaalväärtustel.4. Läbi proovida kõik sisemised andmestruktuurid (ja osad).
Testandmete konstrueerimine.
62
Tarkvara hooldus [software maintenance]
Olemasoleva tarkvara korral. Enamasti kaasneb ka defineerimise ja arendamise etappide taasrakendamine. 70% kogu tööst tarkvaraga.
[corrective maintenance]Korrigeerimine (korrigeeriv hooldus). Kasutamisel avastatud vigade
korrigeerimine.[adaptive maintenance]
Kohandamine (kohandav hooldus). Tarkvara modifitseerimine vastavaltkasutava keskkonna muutustele.
[enhancement][perfective maintenance]
Täiustamine (täiustav hooldus). Tarkvara modifitseerimine vastavalt tellija/kasutaja uutele, täiendavatele soovidele. Võib vaja minnapöördkonstrueerimist. [reverse engineering]
[preventive maintenance]Ennetamine (preventiivne hooldus). Tarkvara hooldatavuse ja usaldus-
väärsuse parandamine edasise täiustamise paremaks tagamiseks.
63
Hooldustegevus
--- Antud: tarkvara konfiguratsioon,--- hooldusnõueUurida kavandit (projekti)Planeerida tegevused
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
64
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.
65
Hoolduse organisatsioon
Hoolduse aruandlus
Hoolduse korraldamineHooldusnõude analüüs (viga või muu?). Vea korral: kas tõsine viga või mitte.Muu korral: kas kohandamine või täiustamine. Võib ka võimatuks osutuda.Analüüsitud hooldusnõue läheb teatava prioriteediga eelistusjärjekorda.Eelistusjärjekorrast võetakse täitmisele pririteetide järjekorras.
Hooduse andmebaas
Hoolduse kõrvalefektid
Võõra või pärandunud tarkvara hooldus [alien or legacy software]pöördkonstrueerimine [reverse engineering]ümberkonstrueerimine [re-engineering]
66
Tarkvara konfiguratsiooni juhtimine [software configuration management]
Tarkvara konfiguratsioon: tarkvara arendusprotsessi tulemus -- programmid, neid kirjeldav kogu dokumentatsioon, sisemised ja välimised andmestruktuurid (, + arenduskeskkond).
Tarkvara konfiguratsiooni juhtimine: tegevused tarkvara konfiguratsiooni muudatuste juhtimiseks kogu tarkvara elutsükli jooksul; süstemaatiline “arvepidamine” muudatuste üle.
Lävejooned [baselines]
Tarkvara konfiguratsiooni objektid (üksused) [SCI ]Koos omavaheliste seostega moodustavad tarkvara konfiguratsiooni andmebaasi.
Objektide identifitseerimine
Versioonide juhtimine [version (revision) control]
Variandid
67
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)
68
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
69
CVS
Version Control System
Versioonijuhtimise süsteem
http://www.cvshome.org/
http://www.cs.ut.ee/~kiho/SE/ CVS.ps
70
Põhimõisted• repositoorium [repository]• töökataloog [working directory]• moodul [module]• versioonide numeratsioon [revisions, releases]
• töösse võtmine [checkout]• tagasi panemine [commit]• töökataloogi kustutamine [release]• erinevuste leidmine [diff]• failide/kataloogide lisamine/kustutamine [add, remove]
Grupitöö [Multiple developers]faili olek [status]tööfaili uuendamine [update]teiste jälgimine [watch, watchers, edit, editors]