süsteemi nõuete esiletoomine ja analüüs
DESCRIPTION
TTÜ informaatikatudengitele 17.10.2011TRANSCRIPT
Priit Potter
• „Solution architect“
– Äri arendamine
– Selleks IT vahendite leidmine
– IT vahendite efektiivne arendamine
• Peamine taust ning kogemus Webmediast
• 10+ aastat IT projektide käivitamisi ja läbiviimist:
– EMT, Elion, Sertifitseerimiskeskus, Statistikaamet, EAS
– TeliaSonera, Fruugo
– Pangad, kindlustused, välisettevõtted jne
Kommunikatsioon ja vastutus
Äriarendus
Süsteemianalüüs
Arendus,
testimine jt
Mille jaoks on mõtet tarkvara teha?
• Otsest rahalist võitu andvad eesmärgid – Kõnekeskus vs iseteenindus
• Ajalist võitu andvad eemärgid
– Sünniakt – Järjekorraautomaat
• “Seadusest” tulenevad eesmärgid
– Euro – EL Struktuurifondide register
• Isiklikust motivatsioonist tulenevad eesmärgid
Tarkvara äriline kasu
• Äriettevõtte jaoks peab loodav tarkvara (mingis perspektiivis) suurendama kasumit
• Kasum: tulud > kulud
• Iga lisakulu peab olema põhjendatud, sest lükkab edasi kasumisse jõudmist!
Analüütiku vastutus
Analüütik vastutab selle eest, et klient saab süsteemi, mida
vajab!
Loengu eesmärk
Kuidas esitada süsteemi kirjeldus arendustiimile võimalikult efektiivselt, st võimalikult väikeste lisakuludega?
Üks näide
• Infosüsteemi on võimalik kirjeldada erinevatest aspektidest – sellist kirjeldamist nimetame nõuete kogumiseks
Nõuded süsteemile
• „Nõue“ ei ole äri poolt esitatav nõudmine!
• Requirement: something required
– something wanted or needed : necessity <production was not sufficient to satisfy military requirements>
– something essential to the existence or occurrence of something else : condition <failed to meet the school's requirements for graduation>
* http://www.merriam-webster.com/dictionary/requirement
Mis on nõue?
• Nõude 3 baasomadust:
– Ühene kontrollitavus – küsimusele „kas nõue on täidetud?“ peab saama võimalikult üheselt vastata “jah” või “ei”
– Kerge kontrollitavus – nõude kontroll ei tohi võtta palju aega
– Sõnastuse lihtsus ja lühidus – nõude sisutekst ei tohiks minna pikemaks kui nt 30 sõna, max 50 sõna
Kas need on head nõuded?
• „Iseteenindus peab suutma vastu võtta 50 liitumist tunnis“
• „Koduleht peab olema ilus“
• „Toetust ei maksta juhul, kui taotluse esitamisel on vähemalt ühel lapsevanemal võlgnevus Rae valla ees (sh maamaksu võlg)“
• „Liitumise leht peab avanema väga kiiresti“
• „Koduleht peab avanema kõigis maailma riikides“
13
Nõuete kogumik
• Nõuete kogumiku moodustamisel on eesmärgiks: – Ühtlane kaetus – nõuete hulk peab ühtlaselt ja
piisava tihedusega katma kogu arendatavat teemat.
– Piisav hulk – nõuete hulk peab olema piisavalt suur, et katta kõik oluline. Aga mitte liiga detailne!
– Struktuurne jaotus – nõuete kogumik peaks sisaldama hierarhilist struktuuri. Esmane jaotus funktsionaalsed ja mittefunktsionaalsed nõuded.
Nõuete kogumik
• Nõuded on aluseks töö vastuvõtmisel!
– Dokumentatsioon
– Arendus (kood jm seotud tulemid)
– Testjuhtumite kirjeldused, testiraportid
– jne
Nõuete kogumik
Funktsionaalsed Mittefunktsionaalsed
Jõudlus
Käideldavus
Kasutatavus
Toetatavus
+
Funktsionaalsus 1
Funktsionaalsus 2
…
…
…
…
17
Nõuete kogumik
• FURPS+ – Functionality (funktsionaalsus) – Usability (kasutatavus) – Reliability (käideldavus) – Performance (jõudlus) – Supportability (toetus) – + (disain, tehnilise realiseerimise piirangud, liideste
piirangud, majutuse piirangud jms)
• … samas: oluline ei ole metoodika, vaid see, et kõik oluline saaks kirja!
18
Funktsionaalsed nõuded
sisend väljund
Funktsionaalsed nõuded kirjeldavad, kuidas süsteem peaks käituma kasutajapoolsete või teisest süsteemist pärinevate sisendite peale.
Võimaldab kasutajal esitada pangale kaarditaotlus
Võimaldab otsida isikukoodi järgi võlgnevusi
Ei võta vastu taotlust kui laenusumma lahter on täitmata
Kuvab tähtajaks tasumata arved punasena
„Äriloogika“
19
Näide: lift
• Peab saama lifti kutsuda
• Peab saama korrust valida
• Peab informeerima tellimuse vastuvõtmisest ja täitmise progressist
• Peab saama abi kutsuda
• Peab saama lifti peatada
• Peab saama uksi avada
• Peab võimaldama „tuletõrje kasutust“
20
Kasutatavus (usability)
• Sobivus kasutaja mõttemudeliga: millised kasutajad ja millises situatsioonis teie rakendust kasutavad?
• Vahendid: – Esteetika (disain, pildid, ikoonid) – Õpitavus – Tagasiside aeg (response time) – Lihtne navigeerimine – Kasutajaliidese ühtlus – Abiinfo, dokumentatsioon
21
Kasutatavus (usability)
Eesmärk: pakkuda lõppkasutajale SUPERMANi
tunnet – süsteem võimaldab teha kõike, mis vaja kasutajapoolse lisapingutuseta!
• Swype
• Metroo vs loomaaia värav
• Sõiduauto
Kasutatavus: lift
23
Kasutatavus: lift
• Lihtne kutsumine
• Selge korruse valik
• Info käesoleva korruse kohta
• Info kutsenupu seisundi kohta
• Valitud korruse indikaator peab olema eristatav ka värvipimedale
24
Käideldavus (reliability)
• Lubatav vigade arv ning tõsidus
• Vigade esinemise vahele jääv ajavahemik (MTBF – mean time between failures)
• Taastamisele kuluv aeg
• Väga kriitilised ärirakendused, reaalajasüsteemid
• Service Level Agreement
25
Käideldavus: lift
• Lifti mittetöötamist ei tohi olla rohkem kui 5 tundi (minutit) kuus
• Ei tohi juhtuda rohkem kui üks selline tõrge aastas, mille tulemusena inimesed jäävad lifti lõksu
• Sellist tüüpi vead tuleb lahendada 30 minuti jooksul
26
Jõudlus (performance)
• Tegevuse kestus (keskmine, maks)
• Tegevuste arv (tegevusi sekundis)
• Võimsus (maks. samaaegsete klientide arv)
• Läbilaskevõime (lehekülgi või MB sekundis)
• Piirkoormus, lubatavad jõudluse languse piirid kõrge koormuse tingimustes
27
Jõudlus: lift
• Lift peab suutma teenindada 300 inimest tunnis
• Lift peab samaaegselt teenindama 8 inimest / 500 kg
• Lifti keskmine tulekuaeg peab jääma alla 1 minuti, tippajal alla 2 minuti
28
Toetatavus (supportability)
• Kui palju raha peab kulutama süsteemi käigus hoidmisele?
• Testitavus (vigade diagnoosimise lihtsus)
• Hooldatavus (regulaarsed uuendused)
• Konfigureeritavus (runtime vs koodis)
• Laiendatavus
• Lokaliseeritavus
29
Toetatavus: lift
• Lifti tarkvara uuendamine ei tohi võtta üle 10 minuti
• Lift ei tohi nõuda hooldust tihemini kui kord aastas
30
Nõuded: kokkuvõte
• Hästi organiseeritud ja läbi mõeldud nõuete kogumik: – Vähendab ümbertegemist ja sellest tekkivat stressi
– Vähendab ajakulu kõigis arenduse lõikudes
– Aitab keskenduda olulisele
• -> tagab lõpptarbijale meeldivama/parema/efektiivsema lahenduse, mille tagajärjel suureneb süsteemi eesmärkide täitmine
Mis edasi?
• Nõuete kogumiku alusel koostatakse süsteem ja vajalikud lisatulemid: – Arenduse eelarve – Kasutusjuhud – Komponendi kirjeldused – Andmemudel – Programmikood – Paigaldamise skriptid – Automaattestid – Manuaalsed testid – Projekti aruanne – Jne… – Jne… vastavalt kliendiga kokkulepitule
• Millised neist tulemitest on hädavajalikud?
– Arenduse eelarve
– Kasutusjuhud
– Komponendi kirjeldused
– Andmemudel
– Programmikood
– Paigaldamise skriptid
– Automaattestid
– Manuaalsed testid
– Projekti aruanne
– Jne
Analüütiku vastutus
• Analüütik vastutab selle eest, et klient saab süsteemi, mida ta vajab!
• NB! Kõik saavad kirjutatust erinevat moodi aru!
• NB! Kes viitsib lugeda 500 lk dokumenti ja on võimeline tagama, et seal kõik kirjas on?
• NB! Mis saab agiilsest arendusest??
Kuidas seda tagada?
• Hea, tasakaalus, hierarhiline nõuete kogumik
• Dokumentatsiooni koostamine tasakaalustatult kogu projekti jooksul
• Elagu prototüüpimine!
Prototüüpimise vajalikkus?
• Lahendus mõeldakse detailides läbi • Lõppkasutaja saab testida funktsionaalsust enne
realisatsiooni • Tellijal ja täitjal ühine nägemus lõpptulemusest ja
vahetulemitest • Leitakse vastused “väiksematele” aga olulistele
küsimustele • Mis on lihtsam ja mis keerulisem funktsionaalsus • Selgemalt saab eraldada, mis on muudatus, mis on
puudujääk ja mis täitja viga • Selgem ülevaade kui palju projektist valmis on
Visualiseerimise meetodid
• Seinatehnika ja prototüübikaust – Whiteboard ja fotoaparaat – Paber, pliiats ja faksiaparaat – ...
• Passiivsed kuvad – Olemasolev rakendus ja „Paint“ – Excel, Visio, jne – Tehniline ülesanne koos ekraanivaatega – ...
• Staatilise infoga prototüüplahendused: – Prototüübimootorid – Lihtsamad HTML või klient-server rakendused – „Mina ütlen, Sina joonistad“ lahendus – ...
Wireframe’i näited
Wireframe’i näited
http://www.balsamiq.com/
Prototüübimootori näide
Ekraanivaadete elemendid
• Ekraanivaate elemendid
• Component library, UIG (User Interface Guidelines kirjeldus) jne
• Miks neid vaja on? – Mõju arenduskiirusele
– Rakenduse intuitiivsus
– Mõttemaailma raamid
– Lõppkasutajate koolitus
Kasutatavusest korra veel
Kuidas lõppkasutajad rakendust kasutavad?
• Kasutuslugude testimine koos lõppkasutajaga
• http://www.realeyesit.com/
• Analüüsimeetrika logides ja andmebaasides
Kokkuvõtteks
• Efektiivseks süsteemianalüüsiks on vaja:
– aru saada, milleks süsteem luuakse (!!)
– head nõuete kogumikku
– head viisi kliendiga skoobi jm detailide kokkuleppimiseks
