Tarkvaratehnika 2016/2017 eksami materjal (0)

Tarkvaratehnika :
Loeng 1:

• Taust:
  
  • Tarkvara iseloom
    
  • Kõrgenenud nõudmised:
    
    • Suuremad süsteemid
      
    • Keerulisemad süsteemid
      
    • Kiiremini
      
• Erinevad näited vigadest mis on tehtud:
  
  • Ariane Crash 1996 kosmosesüstiku alla kukkumine , tuli välja et selle alla kukkumise põhjuseks oli tarkvarasüsteemis viga ilmus trajektoori osas.
    
  • Therac-25 kiiritusravi andmises tehti viga kasutaja liideses, kus pandi vale täht ühte kohta, mille tulemusena anti 125 kordne doos patsiendile.
    
  • MCO marsi satelliidi maandumise ebaõnnestumine, nimelt tarkvara arvutas vale trajektoori, kuna oli kaks eri pikkusühikut ehk meetreid ja naela.
    
• Tarkvaratehnika ajalugu:
  
  • Esmakordselt kasutati seda NATO -s 1968, oli mõeldud ideena, kuidas toime tulla tarkvaratehnikakriisiga.
    
• Tarkvaratehnika „point“
  
  • Tarkvaratehnika= tarkvara inseneeria
    
  • On suunatud professionaalsele tarkvaraarendusele
    
  • Ei tegele tarkvaraarenduse endaga vaid sellega, kuidas organiseerida tarkvaraarendust
    
• Mis on tarkvara(toode) – arvutiprogrammid + nende dokumentatsioon
  
• Kvaliteetse tarkvara atribuudid :
  
  • Evib nõutud funktsionaalsust (teeb nii nagu vaja)
    
  • Hooldatav
    
    • Tarkvara peab arenema, et vastata muutuvatele vajadustele
      
  • Usaldusväärne
    
    • Tarkvara peab olema töökindel
      
  • Efektiivne
    
    • Tarkvara ei tohi raisata süsteemi ressursse
      
  • Vastuvõetav
    
    • Tarkvara peab olema aktsepteeritud kasutajate poolt, kelle jaoks on ta loodud. See tähendab, et tarkvara peab olema arusaadav, kasutatav ja ühilduv teiste süsteemidega
      
• Mis on tarkvaratehnika?
  
  • Tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel- „Engineer Australia “ definitsioon
    
  • Süstemaatilise, distsiplineeritud ja mõõdetava lähenemisviisi rakendamine tarkvara arendamisel, käitumisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale.- IEEE definitsioon.
    
  • Tarkvaraarendus on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu, standardeid, jne.
    
  • Hallatakse ja kontrollitakse:
    
    • Kvaliteeti
      
    • Keerukust
      
    • Ressursse: eelarvet, aega, inimesi
      
    • Riske
      
• Tarkvaratehnika huvigrupid
  
  • Klient
    
  • Arendaja
    
  • Kasutaja
    
• Tarkvaratehnika kui distsipliini eesmärgid
  
  • Kuluefektiivne tarkvaraarendus
    
  • Tarkvaraarenduse organiseerimine kogu tarkvara elukaare ulatuses, arvestades organisatsiooniliste ja rahaliste piirangutega
    
  • Hõlmata tarkvaraarenduse kõiki aspekte , mitte ainult tehnoloogiat.
    
• Millised on parimad tarkvaratehnika meetodid?
  
  • Erinevat tüüpi meetodid erinevat liiki süsteemidele
    
• Tarkvararakenduste liigid
  
  • Kohalikud ( stand -alone) rakendused , nt. MS Office ja fotode manipuleerimise süsteemid
    
  • Interaktiivsed transaktsioonipõhised rakendused, nt. pangarakendused ja e-kaubanduse rakendused
    
  • Mähisrakendused (embedded control systems), nt. ABS-pidureid ja mikrolaineahju kontrollivad süsteemid
    
  • Andmetöötlusrakendused (batch processing systems), nt arvete ja palgaarvestuste süsteemid
    
  • Meelelahutusrakendused, nt. mängud
    
  • Modelleerimis- ja simulatsioonirakendused
    
  • Andmekogurakendused (data collection systems), nt. keskkonna kohta andmeid koguvad süsteemid
    
  • Süsteemide süsteemid (systems of systems)
    
• Mis on protsess?
  
  • Protsess on sammude jada, mis hõlmab tegevusi, piiranguid ja ressursse mingit liiki tulemi loomisel
    
  • Nt protsessidest
    
    • Õppetöö
      
• Mis on tarkvara arendusprotsess e. tarkvaraprotsess?
  
  • Tarkvaraprotsess on sammude jada, mille eesmärgiks on tarkvara loomine ja haldamine
    
  • Üldistatud tegevused tarkvaraprotsessides:
    
    • Spetsifitseerimine- mida süsteem peab tegema ja mis on piirangud tema arendamisel?
      
    • Arendamine- tarkvarasüsteemi tootmine
      
    • Valideerimine - kas toodetud tarkvarasüsteem on see, mida kasutaja soovis? (üks meetod selleks on testimine )
      
    • Evolutsioon - tarkvarasüsteemi muutmine vastavalt kasutajate muutuvatele nõudmistele
      
• Plaanipõhine vs agiilne tarkvaraprotsess
  
  • Plaanipõhine tarkvaraprotsess: kõik tegevused on ette planeeritud ja edu kriteeriumiks on plaani järgmine
    
  • Agiilne tarkvaraprotsess: planeerimine toimub sammude kaupa töö käigus
    
  • Kumb on parem? Mõlemad on ok, see sõltub kus seda kasutatakse.
    
• Tarkvaraprotsessi mudelite põhitüübid
  
  • Kosk
    
    • Selle mudel:
      

Requirements – nõuete analüüs
Design- disain
Implementation- realiseerimine
Modifitseeritud mudeli juures, saab minna ka vastavalt iga astme juurest eelneva juurde, et teha parendusi eelmises.
Vertification-
kõik mis puudutab töö tegemist ( kodeerimine , programeerimine, valideerimine jne)
Maintenance- ülalpidamine

• Selle mudeli puudused ja eelised
  
  • Puudused:
    
    • Saab kasutada ainult siis, kui nõuded on fikseeritud
      
    • Iga tarkvaraprotsessi etapp peab olema lõpetatud enne kui alustatakse järgmist etappi
      
  • Eelised:
    
    • Eelarve prognoositav
      
    • Kindel lõppu aeg
      
    • Jälgitav
      
    • Defineeritud
      
    • Tööjõu vajadused ette teada
      
    • Arendustööd on koordineeritavad
      

• Iteratiivne arendamine
  
  • Selle mudel:
    

Requirements
Anaysis & Design
Planning
Implementation
Initial Planning
Evaluation
Testing
Deployment

• Iteratiivse arendamise eelised ja puudused
  
  • Eelised:
    
    • Klient saab anda tagasisidet kogu tarkvaraprotsessi jooksul
      
    • Kliendi tagasisidet on odavam arvestada-peab vähem ümber tegema
      
    • Klient saab hakata tarkvara varem kasutama
      
  • Puudused:
    
    • Tarkvaraprotsess ei ole läbipaistev ega lõpuni dokumenteeritud
      
    • Tarkvarasüsteemi struktuur degradeerub ( entroopia suureneb) -> vajadus kasutada koodi refaktoreerimist!
      
• Agiilne arendamine
  
  • Selle mudel:
    

Process and tools
Individuals and interactions
Comprehensive documentation
Working software
Contract negotiation
Customer collaboration
Responding to change
Following a plan

• Kokkuvõte
  
  • Tarkvaratehnika e. tarkvara inseneeria on professionaalsele tarkvaraarendusele suunatud distsipliin, mis tegeleb sellega, kuidas organiseerida tarkvaraarendust
    
  • Tarkvaraprotsess koosneb tegevustest, mis on vajalikud tarkvaratoodete arendamiseks . Nende tegevuste organiseerimisega tegelebki tarkvaratehnika.
    
  • Agiilne tarkvaratehnika on kindlate põhimõtete järgi organiseeritud iteratiivne tarkvara arendusprotsess
    
    • Eksamil võib olla küsimus: mis on agiilse ja iteratiivse tarkvaraarenduse vahe? Agiilne tarkvaratehnika paneb piirid iteratsiivsele tarkvaratehnikale. Küsimus on selles, kuidas on iteratiivne tarkvaratehnika täpselt organiseeritud.
      
  • Tarkvaratooted koosnevad väljatöötatud programmidest ja nende dokumentatsioonist
    
  • Tarkvaratehnika eesmärgiks on kuluefektiivne tarkvaraarendus kogu tarkvaratoote elukaare ulatuses.
    

Loeng 2:

• Mis on nõue?
  
  • Dokumenteeritud vajadus, mida tarkvarasüsteem peab rahuldama.
    
• Nõuete esitamise tasemed
  
  • Mõningad nõuded peavad olema detailselt ja matemaatiliselt ning funktsionaalselt spetsifitseeritud, seda on vaja nt sõjanduses. Kõik peab olema ülimalt täpne
    
  • Tavakasutaja nõuetele vastavad, nt. mängud, rakendused, aplikatsioonid, mis ei nõu nii täpseid matemaatilisi kontrolle vaid pigem lõppkasutaja mugavust vms
    
  • Isikupõhistele nõuetele vastav, nt ÕIS, kus iga nõue on isiku põhine.
    
• Nõuete tüübid
  
  • Kasutaja nõuded
    
    • Milliseid nõudeid peab antud tarkvarasüsteem täitma. Mida kasutaja peab saama süsteemi abil teha. See toimub siis kui alles hange kuulutatakse välja ning hakkavad alles nn läbirääkimised.
      
  • Süsteemi nõuded
    
    • Millised on süsteemi täpsed/detailsed nõuded, millised on konkreetsed funktsionaalsused, ning samuti ka piirangud, mis lepitakse kokku vastavalt lepingule. Mida peab funktsionaalselt süsteem tegema, et kasutaja saaks seda kasutada. See toimub siis kui antud projekt vms on võidetud.
      
• Mis on nõuete analüüs?
  
  • Protsess, mis on mõeldud saavutamaks teenuseid, mida klient soovib süsteemist saada. Süsteemi poolt kirjeldame, mida süsteem peab tegema, et kasutaja mingeid vajadusi rahuldada, sinna alla kuuluvad ka piirangud. See on see protsess, kuidas see toimib ja kuidas me neid kirjeldame.
    
• Miks on nõuete analüüs oluline?
  
  • Parenduste ja probleemide lahendamine on kallis, ning selle minimaliseerimiseks on vaja teha nõuete analüüs.
    
  • 
    
• Põhiprobleem nõuete analüüs?
  
  • Nõuete ühtlustamine kliendi ja tegija poolt, et mõlemad osapooled saaks ühtmoodi asjast /nägemusest aru.
    
• Nõude kolm põhiomadust
  
  • Ü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 olla pikem kui ~30 sõna.
    

• EKSAMIL KÜSIMUS: Nõude 3 põhiomadust, tooge näited nõuetest ja selgitage kuidas need nõuded vastavad nõuete kolmele põhiomadusele?
  

• Head nõuded
  
  • “Iseteenindus peab suutma vastu võtta 50 liitumist tunnis“
    
• Halvad nõuded
  
  • „ 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“
    
• Nõuete liigid
  
  • Funktsionaalsed nõuded
    
  • Mittefunktsionaalsed (kvaliteedi) nõuded
    
• Funktsionaalsed nõuded
  
  • Kirjeldus, kuidas süsteem peaks käituma kasutajapoolsete või teistest süsteemist pärinevate sisendite peale.
    
    • „Võimaldab isikukoodi järgi võlgnevuste nimekirja filtreerida “
      
    • „Ei võta vastu taotlust kui laenusumma lahter on täitmata“
      
    • „Kuvab tähtajaks tasumata arved punasena“
      
• Mittefunktsionaalsed (kvaliteedi) nõuded
  
  • Kirjeldus selle kohta, millised süsteemi kvaliteediomadusi peab silmas pidama funktsionaalsete nõuete rahuldamisel
    
    • Näiteks
      
      • Kasutatavus (usability)
        
        • Esteetika (disain, pildid, ikoonid)
          
        • Õpitavus
          
        • Tagasiside aeg (response time)
          
        • Lihtne navigeerimine
          
        • Kasutajaliidese ühtlus
          
        • Abiinfo, dokumentatsioon
          
      • Käideldavus (reliability)
        
        • Lubatav vigade arv ning tõsidus
          
        • Vigade esinemise vahele jääv ajavahemik (MTBF- mean time between failures)
          
        • Taastamisele kuluv aeg
          
        • Service Level Agreement
          
      • Jõudlus (performance)
        
        • Tegevuse kestvus (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
          
      • 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
          
• Nõuete esitamise viisid
  
  • Naturaalne keel (Loomulik keel).
    
    • Nõuded on kirjutatud kui loomulik keel, mille laused on pandud diagrammidesse ja tabelitesse.
      
    • Probleem on tihti selles, et meil ei ole võimalik loomulikus keeles nõudeid üheselt esitada, niimoodi et iga nõu, mis on loomulikus keeles esitatud, vastaks nõuete kolmele põhiomadusele.
      
    • Tihti on raske vahet teha funktsionaalsete ja mittefunktsionaalsete (kvaliteedi) nõuete vahel, see teeb selle raskesti aru saadavaks.
      
  • Struktureeritud loomulik keel, nt kasutaja lood, kasutusjuhud, tsenaariumid.
    
  • Mudelid, mis illustreerivad nõudeid, ehk graafilised notatsioonid. Nt iteratsioonidiagrammid, klassidiagrammid , süsteemi käitumis diagrammid jne.
    
  • Formaalsed ehk matemaatilised spetsifikatsioonid, nt Z keel.
    
• Kaks olulist nõuete esitamise viisi
  
  • Kasutajalood ( user stories )
    
    • Üldkuju : Kui kasutaja mängib üht teatud rolli, siis mina pean olema võimeline tegema mingeid tegevusi, et tellimus saavutaks eesmärgi.
      
      • Nt. ÕIS-i puhul, võttes õppejõu siis tema peab sisestama mingi hinde õpilasele.
        
      • 
        
      • Kasutajalood jagatakse omakorda taskideks, et asja veidi detailsemaks teha ja korrektsemaks, ehk tehnilised ülesanded.
        
      • Kasutajalood täidavad kasutaja nõudeid
        
      • Taskid täidavad aga süsteemi nõudeid
        
  • Kasutajajuhud (user cases)
    
    • Kirjeldab süsteemi kasutaja iteratsioone süsteemiga.
      
    • On kaks notatsiooni:
      
      • Graafiline
        
      • Tabeli kujuline
        
    • Hea näide kasutajajuhtude kohta on meditsiiniline tarkvarasüsteem, kus patsient saab panna arsti juurde aega, arst saab patsiendi kohta andmeid jne.
      
  • Need on erinevad asjad!
    
    • Nende erinevused on näiteks:
      
      • Kasutusjuhud on keerulisemad ja tänu sellele võimalik kasutada laialdasematel aladel
        
      • Kasutuslugu reaalse maailma protsess ja kasutusjuht selle abstraktsioon
        
      • Kasutusjuht näitab seost erinevate tegutsejate vahel ja kasutuslugu on ühe tegutseja piires
        
      • Kasutuslool on kindel stsenaarium ja kasutajajuht on süsteemi stsenaarium.
        
      • Peamiselt on kasutusel kasutajalugu, mis lüüakse lahti task -ideks, kuna see on efektiivsem ja kiirem võrreldes kasutajajuhtudega.
        
• Nõuete spetsifikatsiooni dokument ehk nõuete kogumik (System Requirements Specification)
  
  • See on põhimõtteliselt ainuke dokument, mida kasutatakse agiilse tarkvarasüsteemi puhul
    
  • See on vajalik selleks, et oleks hiljem võimalik kontrollida süsteemi nõudeid
    

• Eksamil on oluline nõuete analüüsi protsessi kohta teada:
  
  • 
    
  • See on iteratiivne
    
• Nõuete valideerimise tehnikad
  
  • Eksamil võib olla küsimus:
    
    • Millised on nõuete valideerimise tehnikad?
      
  • Nõuete läbivaatused
    
  • Prototüüpimine
    
  • Nõuete valideerimine testnõuete kaudu
    
• Prototüüpimise plussid
  
  • Lahendus mõeldakse detailselt läbi
    
  • Lõppkasutaja saab „proovida“ funktsionaalsust enne realisatsiooni
    
  • Tellija ja täitjal ühine nägemus lõpptulemusest
    
  • Tellija ja täitja saavad täpsemalt kokku leppida projekti skoobis ning vahetulemites
    
  • Saab eraldada, mis on lihtsam ja mis keerulisem funktsioonalsus
    
  • Selgemalt saab eraldada, mis on muudatus , mis on puudujääk ja mis täitja viga
    
  • Selgem ülevaade kui palju projektist valmis on
    
• Kokkuvõte
  
  • Nõude definitsioon
    
  • Nõuete tüübid
    
  • Nõude kolm põhiomadust
    
  • Nõuete liigid
    
  • Nõuete esitamine
    
  • Kasutuslood
    
  • Kasutusjuhud
    
  • Nõuete spetsifikatsiooni dokument
    
  • Nõuete analüüsi protsess
    
  • Nõuete valideerimine
    

Loeng 3
Arhitektuurne kavandamine

• Tarkvara arhitektuur ?
  
  • Tarkvara arhitektuuri kontseptsioon on pärit Edsger Dijkstra 1968 ja David Parnas 1970 aastate uurimistöödest – ametlikus vormis tuldi selleni hiljem
    
  • Süsteemi illustratsioon, mis aitab aru saada süsteemi käitumisest (Software Engineering Institute https://www.sei.cmu.edu/ )
    
  • Süsteemi arhitektuur on struktuuride kogum, mis aitavad mõista süsteemi, hõlmates tarkvara elemente, seoseid nende vahel ja elementide ning seoste omadusi (wikipedia)
    
  • Arhidektuur on vundament millele tarkvara ehitatakse. Arhitektuuri mudel defineerib vundamendi visiooni (agilemodeling)
    
• Erinevused funktsionaalsest disainist
  
  • IEEE 1990 sõnastik:
    
    • Arhitektuurne disain- protsess, mille käigus defineeritakse riistvara ja tarkvara komponendid ja nende liidesed , kujundamaks välja raamistikku tarkvara arendamiseks
      
    • Eeldisain- protsess, mille käigus analüüsitakse arhitektuuri alternatiivne ja defineeritakse arhitektuur, komponendid, liigesed igale tarkvara komponendile.
      
    • Detaildisain- eeldisaini tulemi laiendamine/täpsustamine saavutamaks vajalikku täpsust arendamise alustamiseks
      
    • Funktsionaaldisain- protsess, mille käigus defineeritakse seosed süsteemi komponentide vahel.
      
  • Arhitektuur on disain aga mitte kõik disainid ei ole arhitektuur
    
  • Arhitektuuri juhivad mittefunktsionaalsed nõuded, funktsionaaldisaini juhivad funktsionaalsed nõuded
    
  • Pseudo kood kuulub detaildisaini dokumentatsiooni
    
  • UML komponendi-, paigaldus- ja paketidiagrammid on enamasti arhitektuuri dokumentatsioonis
    
  • UML klassi-, objekti-, käitumisdiagrammid funktsionaaldisaini dokumentatsiooni
    
• Erosioon
  
  • 
    

• See tähendab seda, et lepitakse kokku ühes aga tulemus on teine, ning selle tulemuseks on suur jama
  

• 
  

• 
  

• Klient- Server –See on süsteem mida kasutati rohkem kunagi
  
  • Client-Queue-Client süsteem
    
  • P2P
    
  • Aplikatsioonide server
    
  • Kasu
    
    • Kõrgem turvalisus
      
    • Andmed on tsentraliseeritud
      
    • Kerge hallata
      
• 
  
  • Taaskasutatav
    
  • Asendatav
    
  • Laiendatav
    
  • Kapseldatud
    
  • Sõltumatus
    
  • Kasu:
    
    • Kerge paigaldada
      
    • Kerge ehitada
      
    • Odav hind
      
    • Taaskasutav
      
    • Lahendab tehnilist keerukust
      
• 
  
  • Abstraktne
    
  • Kapseldatud
    
  • Selgelt defineeritud kihid
    
  • Taaskasutatav
    
  • Nõrgalt seotud
    
  • Kasud :
    
    • Abstraktne
      
    • Manageeritav
      
    • Isoleeritud
      
    • Jõudlus
      
    • Taaskasutatav
      
    • Testitav
      
• 
  
  • Kasud:
    
    • Laiendatavus
      
    • Nõrgalt seotud
      
    • Skaleeritavus
      
    • Aplikatsioonide lihtsus
      
• 
  
  • Kasud:
    
    • Hallatavus
      
    • Skaleeritavus
      
    • Paindlikus
      
    • Kättesaadavus
      
• 
  
  • Abstraktsioon
    
  • Kompositsioon
    
  • Pärilus
    
  • Kapseldamine
    
  • Polümorfism
    
  • Eraldatus
    
  • Kasu:
    
    • Arusaadavus
      
    • Taaskasutatavus
      
    • Testitavus
      
    • Laiendatavus
      
    • Kõrge kohesiivsus- seotud funktsionaalsus on ühendatud samasse klassi
      
• DDD
  
  • Objektorienteeritud arhidektuur kus lähtutakse ärilisest domeenist.
    
  • Kasu:
    
    • Äriline mõistmine
      
    • OO kasud
      
• 
  
  • Autonoomne
    
  • Jagatav
    
  • Nõrgalt seotud
    
  • Jagatakse lepingut ja skeemi, mitte sisemisi klasse
    
  • Kasu:
    
    • Abstraktsus
      
    • Leitavus
      
    • Erinevad platvormid
      
    • Ratsionaalsus
      
• 
  

• Mikroteenused
  
  • Sarnane teenus orienteeritud arhitektuurile
    
  • Teenused on väiksemad
    
  • Teenused komponentide vahel mitte erinevate rakenduste vahel
    
  • Kasud:
    
    • Sama mis teenusorienteeritud arhitektuuril
      
    • Lihtsalt skaleeritav
      
    • Tehnoloogiliste valikute muutmise osas vabam
      
• Kuidas valida arhitektuuri?
  
  • Kuidas kasutajad kasutavad loodavat süsteemi
    
  • Kuidas süsteemi paigaldada
    
  • Millised on mittefunktsionaalsed nõuded: turvalisus, jõudlus, paralleelsus, multikeelsus, konfiguratsioon
    
  • Kuidas saavutada paindlikus ja hallatavus läbi aja
    
  • Millised on arhitektuursed trendid, mis võivad mõjutada süsteemi praegu või tulevikus
    
• Võtme jõud …
  

… mis mõjutavad arhitektuuri

• Kasutaja volitused - kasutaja kogemus: ära dikteeri
  
• Turu küpsus – kasuta valmis komponente, ära leiuta jalgratast
  
• Paindlik disain-taaskasutatavus, hallatavus, skaleeritavus
  
• Tuleviku trendid
  
• Arhitektuuri disain
  

Ära üle inseneri. Ära tee eeldusi, mida ei saa kontrollida.

• Mis on fundamentaalsed osad arhitektuurist, mille valesti tegemine on väga suure riskiga süsteemi toimumisele
  
• Milline osa süsteemist on suurim muutumise tõenäosusega
  
• Milliste osade disainimist võib edasi lükata ilma märkimisväärsete mõjudeta
  
• Millised on võtme eeldused ja kuidas neid kontrollida
  
• Mis võib põhjustada süsteemi ümber disainimise
  
• Arhitektuuri disainimise protsess
  
  • Tarkvaraarhitektuuri disainimeks ei ole universaalset, aktsepteeritud protsessi
    
• ADD (Attribute Driven Design)
  
  • ADD töötati välja Carnegie Melloni Ülikooli pool
    
  • Väljakutsed
    
    • Milline arhitektuur kataks kõige paremini kasutajate vajadusi
      
    • Kuidas täita kujuteldava süsteemi nõudeid
      
    • Kuidas otsustada, milline arhitektuuri strateegia on sobilik
      
    • Kuidas hinnata nõuete täitmisel tehtavate kompromisside mõjusid
      
  • ADD on rekursiivne
    
    • 1. osa taktika
      
      • Kontrolli, et nõuded oleks piisavad
        
      • Vali süsteemi osa, mida komponentideks lahutada
        
      • Identifitseeri arhitektuuri juhtivad nõuded
        
      • Vali kontseptioon, mis täidab juhtivad nõuded
        
    • 2. osa dokumenteerimine
      
      • Algväärtusta arhitektuuri elemendid ja jaota vastutused
        
      • Defineeri elementide liidesed
        
      • Verifitseeri ja viimistle nõudeid ning määra nende pealt piirangud elementidele
        
    • Korda samme kõikide süsteemi osade kohta
      
  • Kasu:
    
    • Nõuete vahelised kompromissid tulevad varajases staadiumis välja, mis omakorda aitab valida parima arhitektuuri nõuete katmiseks
      
• Won Kim pakutud protsess
  
  • Won Kim is Senior Advisor at Samsung Electronics and Distringuished Professor at SungKyunKwan University
    
    • Koosta esialgne paigaldusplaan (deployment plan). See annab ülevaate kasutatavast keskkonnast
      
    • Mängi esialgsed kasutuslood läbi paigaldusplaani peal. See peaks sisaldama andmevooge läbi keskkonna, andmete sisenemisi, väljastamist ja talletamist põhi andmetüüpidega
      
    • Grupeeri ja prioriteeri nõuded
      
    • Vali üks kuni mitu mustrit moodulite vaatele ja defineeri kaetud nõuded
      
    • Vali üks kuni mitu mustrit komponentide vaatele ja defineeri kaetud nõuded
      
    • Vali üks või miitu mustrit paigutusvaatele ja defineeri kaetud nõuded
      
    • Teosta järelkontroll arhitektuurile
      
    • Itereeri punkte 1-7
      
• Agiilne arhitektuur
  
  • Arhitektuur ei ole mitte midagi erilist
    
  • Karda kivisse raiutud arhitektuuri
    
  • Igal süsteemil on arhitektuur
    
  • Arhitektuur skaleerub
    
  • Arhitektuur evoleerub
    

• Kes vastutab arhitektuuri eest? – Kõik vastutavad.
  
  • Probleem:
    
    • Vahel inimesed ei ole üksteisega nõus
      
    • Suurtes tiimides skaleeruvus
      

• Nimeta arhitektuuri manager /omanik/vastutaja
  
• Arhitektuur suures meeskonnas
  
  • Arhitektuuri juhitud lähenemine
    
  • Featuuri juhitud lähenemine
    
  • Avatud lähtekoodi lähenemine
    
  • Kombinatsioon eelnevatest
    
  • 
    

• Arhitektuuri testimine
  
  • Küsi endalt:
    
    • Millistele eeldustele tugineb arhitektuur
      
    • Millised nõuded arhitektuur katab
      
    • Mis on selle arhitektuuri võtme riskid
      
    • Milliste meetmetega leevendada riske
      
    • Mil moel on see arhitektuur edasiminek viimase kandidaadi/baas arhitektuuri suhtes
      
• Agiilne tarkvara arhitektuur
  
  • Nõuded juhivad arhitektuuri v.a. kui sa häkid
    
• Agiilne arhitektuur
  
  • Modelleeri
    
  • Ära unusta alternatiive
    
  • Arvesta äri kitsendustega
    
  • Lenda valguskiirusel
    
    • Ole nii väle kui võimalik
      
    • Ära kirjuta 50 lehekülge kui 5 kõlbab
      
    • Ära kirjuta 5 lehekülge, kui pilt kõlbab
      
    • Ära joonista pilti, kui metafoor kõlbab
      
    • TAGTI- They Ain´t Gonna Read It
      
  • Tõesta oma arhitektuuri
    
    • Parim tõestus on kood
      
    • Kommunikeeri oma arhitektuuri
      
    • Mõtle tulevikule aga ära pinguta üle
      
• Agiilne arhitektuur –tavaline praktika
  
  • Arhitektid tõstetakse või veel hullem tõstavad end ise kõrgemale pjedestaali astmele
    
  • Arhitektid onn liiga hõivatud, et „määrida“ oma käsi koodi kirjutamisega
    
  • Arhitektuuri mudelid on piisavalt robustsed, et lahendada ka tulevikus tekkivaid probleeme
    
  • Eesmärk on luua lõplik arhitektuur võimalikult vara
    
  • Hästi sokumenteeritud mudelid
    
  • Arhitektuuri mudeleid presenteeritakse vaid „sobilikele kuulajatele“
    
  • Arhitektuurile tehakse enne järel kontroll ja seejärel läheb arhitektuur arendamisele
    
  • Arhitektidel on alandlikkust tunnistada, et nad ei oska vee peal käia
    
  • Arhitektid osalevad aktiivselt arendustegevuses. Nad on meeskonna konsultandid
    
  • Arhitektidel on alandlikkust tunnistada, et nad ei oska tulevikku ennustada. Küll aga on nad enesekindlad selles, et homseid probleeme saab lahendada homme
    
  • Arhitektuur tekib iteratiivselt koos arendusega
    
  • Valguskiirus. Dokumenteeri nii palju kui on vaja kommunikatsiooniks
    
  • Mudeleid kommunikeeritakse avalikult kõigile osapooletele, ka poolikuid, et saada tagasisidet
    
  • Arhitektuuri kontrollitakse eksperimentidega
    

Loeng 4
Disain- Erik Jõgi [email protected]

• Miks disain loeb?
  
  • Kestvus – koodi kasutatakse aastaid ja aastaid
    
  • 
    
• Puhas kood ( Clean Code)
  
  • Sa tead, et loed puhast koodi, kui loed mingit koodi siis kõik tundub loogiline ja iga järgnev rida vms on oodatud, ettenähtud sinna – Ward Cunningham
    
• 4 elementi lihtsast disaini
  
  • Läbib kõik testid
    
  • Ei ole kordusi
    
  • Koodi kavatsus arusaadav
    
  • Lühike/väike
    
• Nimed
  
  • Nimed on olulised inimese jaoks, mitte arvuti jaoks. Hea oleks panna õiged nimetused asjadele (klassid, meetodid, jne).
    
  • Pane nimed kindlasti inglis keeles
    
  • Sõna sõnalt tõlkimine ei pruugi olla õige lahendus
    
  • Kasuta õiget domeeni terminoloogiat- küsi domeeni eksperdi käest, mida nad kasutavad
    
  • Hääldus ja grammatika peavad samuti olema korrektsed
    
  • Kas sa suudad oma koodi lugeda nagu mingit lugu/raamatust?
    
  • Nimede kasutusi:
    
    • Customer – Client – Party – Counterparty
      
    • state – status
      
    • Contract – Agreement
      
    • get – load – fetch – find – retrieve
      
    • regCode – regNumber – personalCode
      

• ärge kasutage samasid nimesid erinevate asjade puhul
  

• Funktsioonid –hea funktsioon
  
  • Lühike
    
  • Väga vähe astmeid
    
  • Teeb ainult üht asja- ühe astmega
    
  • Funktsioon peab tegema üht asja
    
    • Need peaks tegema neid hästi
      
    • Need peaksid tegema ainult seda
      
• Hea refaktoorimise näide https://echo360.e-ope.ee/ess/echo/presentation/860a7aab-83b0-4c45-8ba5-aef64c433060 minutid 35-51.
  
  • Kasutab Java keelt
    
  • Kasutab puhta koodi tegemiseks IntelliJ Community
    
• Funktsiooni argumendid
  
  • Vähem on parem
    
  • Idaalis oleks hea kui oleks 1 või 2 parameetrit
    
  • Kolme parameetrit kasutades on liiga palju, kõik muu on disaini „hais“ 
    
• Ei kõrval mõjudele!
  
  • Funktsioon mis tundub olevat read-only nime järgi, peaks see ka nii toimima
    
  • Kui funktsioon muutub (selle tööpõhimõte) siis tuleks ka funktsiooni nime muutma
    
• Kommentaarid
  
  • Kommentaare ei kirjutata
    
  • Kommentaarid valetavad:
    
    • Sa ei saa neid siduda koodiga
      
    • Sa ei saa neid refaktoorida
      
    • Sa ei saa neid testida
      
  • Tõde on koodis
    
  • Ära kasuta kommentaare, kui sul on koodis parameetrid vms õigete nimedega
    
  • Võib kasutada, kui sa ei suuda ennast väljendada koodis
    
  • Kommentaaridena kasutatakse:
    
    • Legaalsed kommentaarid
      
    • Hoiatused
      
    • TODO kommentaarid
      
    • Mingite võimenduste jaoks
      
    • Javadoc-side jaoks publikulise API jaoks
      
• Hoia oma koodi puhtana
  
  • „The Boy Scout Rule“
    
    • Hoia kasutuses olev kämpingu plats puhas, ära lagasta seda, kuna ka teised kasutavad seda.
      
• Objekt orienteeridud disain
  
  • Agile Software Development hea raamat mida lugeda
    
• Liidesed ja abstraktsed klassid
  
  • Eira sisetatud detaile (ignore implementation details)
    
  • Programmeeri otse liidesesse
    
• Java kollektsioonide API
  
  • Implamatsioon
    
    • Kollektsioonid
      
      • Listid: ArrayList, LinkedList
        
      • „Set“id: HashSet, LinkedHashSet
        
        • „SortedSet“id: TreeSet
          
  • „Map“ Kaardid: HashMap, LinkedHashMap
    
    • SortedMap: TreeMap
      
• Java.IO
  
  • Baitide peale pandud I/O
    
    • InputSteam ja OutputStream
      
      • FileInPutStream, SocketInputStream, ByteArrayInputStream, GZIPInputStream
        
  • Karakterid, mis põhinevad I/O
    
    • Loendur ja Kirjutaja
      
      • FileWriter, StringWriter, OutputStreamWriter
        
• Sõltuvus „Injection“ inversiooni kontroll- Sõltuvus antakse ette
  
  • Hollywood-i põhimõte- Ära kutsu meid- Me kutsume sind
    
  • Ära loo ise sõltumatuseid, need antakse sulle ise
    
  • Puhtam disain
    
  • Lihtsam testida
    
• Sõltuvus „Injection“
  
  • Guice - github .com/google/guice
    
  • Dagger - google.github.io/dagger/
    
  • Spring Framework - projects.spring.io/spring-framework/
    
  • Mockito - mockito.org
    
• Lemmik kompositsioon üle päranduse
  
  • Pärilikus on „is-a“ suhe- kui sama liides on siis on mõistlik kasutada
    
  • Kompositsioon on „consists-of“, „contains“, „used“, „has“ suhtes- pakkudes eraldamist-sõltumatust iga muudatuse juures
    
• Muutumatus
  
  • Muutumatud objektid on objektid, mille staatust ei saa enam muuta pärast loomist
    
• Mustrid
  
  • Laialdased lahendused läbinud probleemidele ilmuvad objekt orienteeritud disainist
    
  • Süstematiseeritud kataloogid lahendustest tasemel ja kogenud arendajatelt
    
  • Lihtsustab suhtlust erinevate arendajate vahel- „me kasutame Strategy mustrit“
    

• LOOMISMUSTER
  
  • Protsess objekti loomisel
    
    • Algne meetod „ Factory Method“
      
    • Abstraktne loomine „Abstract Factory“
      
    • Ehitamine „Builder“
      
    • Prototüüp „Prototype“
      
    • Ainustamine „Singleton“
      
• STRUKTUURNE MUSTER
  
  • Kompositsioon klassidest
    
    • Kujundaja „Decorator“
      
    • Adapter (Pakkija) „Adapter (Wrapper)“
      
    • Volikiri „Proxy“
      
    • Fassaad „Façade“
      
    • Kergem/lihtsam klass „Flyweight“
      
    • Sild „Bridge“
      
    • Kompositsioon „Composite“
      
    • Null objekt „Null Object “
      
• KÄITUMISE MUSTER
  
  • Kuidas klassid ja objektid omavahel suhtlevad ja jaotavad vastutust
    
    • Šabloon „Template“
      
    • Vaatleja „Observer (Publish-Subscribe, Listener)“
      
    • Tõlk „Interpreter“
      
    • „Memento“ ehk undo/tagasi võtmine
      
    • Vastutusahel „Chain of Responsibility“
      
• KÄITUMISE MUSTER
  
  • Kuidas klassid ja objektid omavahel suhtlevad ja jaotavad vastutust
    
    • Peamine seisukoht „State“
      
    • Käsk „Command“
      
    • Strateegia „strategy“
      
    • Iteraator „Iterator“ – object, mis laseb programmeerijal läbida konteinereid ja eriti liste
      
    • Külaline „Visitor“
      
    • Vahendaja „Mediator“ – objekt, mis kapseldab, kuidas objektid käituvad/suhtlevad
      

Loeng 5
Arenduse infrastruktuur ja konfiguratsioonihaldus- Aho Augasmägi [email protected]

• Mida endast kujutab arenduse infrastruktuur?
  
  • 
    
• Inimesed
  
  • Oluliseim komponent
    
  • Suhted ja suhtlemine on nagu õli, mis paneb kogu masinavärgi tööle
    
  • Tööriistad üksi tööd ei tee
    
  • Klient, testija, arendaja …
    
• Nõuded
  
  • Nõuetest arusaamine on eduka projekti alus
    
  • Milleks hallata?
    
    • Muutuvad ajas
      
    • Ununevad
      
    • Olulisus muutub
      
    • Tekivad ja kaovad
      
    • Folkloor
      
    • Ebakõlad/vead
      
    • Progressi jälgimine
      
  • Millega hallata?
    
    • Tekstiredaktor
      
    • Google docs
      
    • Joonistamise vahendid (mocuping/wireframing)
      
    • Pivotal Tracker (www.privotaltracker.com)
      
    • JIRA ( https://www.atlassian.com/software/jira )
      
    • …
      
  • Praktilisi näpunäiteid:
    
    • Vahendite puhul alusta minimaalsest, mis sul on vajalik
      
    • Pane kiirja koos kliendiga
      
    • Tee võimalikult väikseks
      
    • Räägi
      
• Planeerimine
  
  • „Plaanid on kasutud, planeerimine on kõik“ Dwight D.Eisenhower
    
  • Alusta väga üldisest
    
  • Planeerimine ei ole ainult kuupäevad, millal asi peab valmis olema
    
  • Nõuete olemasolu/puudumine annab plaanidele uue mõõtme
    
  • Resursside olemasolu/puudumine
    
  • Plaane tuleb ümber vaadata ja muuta vastavalt olukorrale
    
  • Plaan on realistlik kuni 2 nädalat ette
    
  • Vahendid:
    
    • Paber, pliiats, whiteboard
      
    • Excel
      
    • MS Project
      
    • JIRA, Pivotal Tracker
      
  • HEA VAHEND ON OSA NÕUETE HALDUSEST
    
• Arendusvahendid
  
  • Notepad
    
  • Vi/vim
    
  • Eclipse
    
  • NetBeand
    
  • IntelliJ IDEA
    
  • XCode
    
  • AppCode
    
  • Visual Studio
    
  • +100 muud vahendit lisaks
    

• Õigesti valitud vahend võib tõsta arendaja produktiivsust väga palju
  
• Õpi oma vahendit kasutama ja tunne selle võimalusi
  
• Kasuta shortcute
  
• Ära aja pilti liiga suureks
  
• Versioonihaldus
  
  • Ajalugu. Seotus nõuetehaldusega
    
  • Muudab arenduse paindlikumaks
    
  • Meeskonnatöö
    
  • Arusaamise, milline lähtekood on hetkel toodangus
    
  • Kes selle siia tegi?
    

• Hajusad vahendid
  
  • Git/GitHub ( https://github.co m)
    
  • Mercurial
    
  • TeamWare
    
• Tsentraliseeritud vahendid
  
  • SVN
    
  • CVS
    
  • Perforce
    
  • Microsoft TFS
    

• Bitbucket ( https://bitbucket.org ) – rohkem kui ainult versioonihaldus
  
  • Projekti kodu:
    
    • Lähtekood
      
    • Wiki
      
    • Reliisid
      
    • Veahaldus
      
• Harud (branch) – luuakse repositooriumi peaharust eraldi haru
  
  • Projektid arendatakse harus ja mergetakse peaharu
    
  • Harus arendatakse eksperimentaalset osa
    
  • Ainuke pikad projektid harus, lühemad peaharus
    
• Milleks peaks haudega ettevaatlikult ringi käima?
  

• Build /Deploy
  
  • Iga commiti järgi peab tekkima veendumus, et töötab ka kood, mis on koodihoidlast kättesaadav.
    
  • Continuous integration:
    
    • Kompileerib vajadusel koodi
      
    • Koodianalüsaator?
      
    • Paigaldab rakenduse
      
    • Käivitab unit testid
      
    • Käivitab funktsionaalsed (UI) testid
      
  • Vahendid:
    
    • Shell script
      
    • Ant script
      
    • Jenkins ( https://jenkins-ci.org )
      
    • Atlassion bamboo ( https://www.atlassian.com/software/bamboo )
      
    • Travis CI ( https://travis-ci.org )
      
    • Circle CI ( https://circeleci.co m)
      
  • Toodangusse minek
    
  • Väldi käsitööd. Sellega kaasnevad vead
    
  • Kasuta seda tulemust, mis sa continuos integration vahenditega juba valmis tegid.
    
  • Kui ei saa siis tee selgeks, miks ei saa. Elimineeri need põhjused ja kasuta ikka
    
  • Kui siis ka ei saa siis kasuta vähemalt samu build skripte
    
  • … muud moodi liigub asi kontrollimatuse suunas
    

• Sõltuvuste haldus:
  
  • Sõltuvused koos lähtekoodiga repositooriomis
    
  • Sõltuvused hallatakse vahenditega
    
    • Ivy, Maven
      
• Rakenduse konfiguratsioon:
  
  • Dünaamiline , sõltub keskkonnast
    
  • Staatiline, luuakse rakenduse ehitamisel
    
  • Healthy mix
    

• Konfiguratsioon:
  
  • .properties fail, .ini faili, .yaml
    
  • XML, servlet
    
  • Andmebaas
    
  • JNDI
    
  • Lähtekood
    
  • …
    

• Proovi saavutada olukorda, kus versioonihaldusest tulev asi on kompileeriv ja vajadusel pakenduv kohe, ilma lisaknfigureerimisteta
  
• Virtualiseerimine
  
  • Arendus mitmele operatsioonisüsteemile
    
    • Arendus
      
    • Testimine
      
  • Erinevatele operatsioonisüsteemidele kompileerimine (continuous integration)
    
  • Töölaua/serveripargi virtualiseerimise vahendid:
    
    • Parallels desktop
      
    • VM Workstation
      
    • Virtualbox- tasuta
      
• Testimine
  
  • Unit test
    
  • Acceptance test
    
  • Regressioon test
    
  • Jõudlustest
    

• Selenium
  
• Selenide
  
• Cucumber
  
• FitNesse
  
• …
  

• Rational robot-IBM
  
• Test Studio –Telerik
  
• HP QuickTest Professional-HP
  
• …
  

Loeng 6:
Nõuete analüüs- Erkki Lindepuu [email protected]

• 
  
• Aasa Global
  
  • Finants teenused: Soome, Poola, Indoneesia, Tšiili , (Rootsi, Tsehhi=
    
  • Big Data Scoring
    
  • Agiilne (äri)arendus
    
• Nõuete Kaardistus ja süsteemi analüüs
  
  • Millist probleemi me selle projektiga lahendame?
    
  • Mis on selle arenduse business case ?
    
  • Nendele küsimustele peab olema selge 1-2 lauseline seletus. Muidu projekt töösse ei lähe
    

• Protsessi analüüs
  
  • AS—IS kaardistus TO-BE kirjeldamine (ei nimeta IT süsteeme)
    
• Ärilised funktsionaalsed nõuded
  
  • Süsteem peab tegema …
    
• Ärilised mittefunktsionaalsed nõuded
  
  • Peab teenindama 1000 üheaegset kasutajat
    
  • Peab olema kättesaadav välisvõrgus
    
  • Peab saama kasutada õues päikese käes
    
• Süsteemsed mittefunktsionaalsed nõuded
  
  • Milliseid tehnoloogiaid kasutamine
    
  • Kuidas toimub logimine
    
  • Kuidas süsteemi konfigureeritakse
    
• Töövahendid ja meetodid EEs
  
  • Äriprotsesse modelleerime EPC notatsioonis
    
  • Äriprotsesside ühtset registrit hoiame ARISes (oracle business process architect)
    
  • Ärinõuete register
    
  • Ärimõistete register (infovarade register)
    
• Töövahendid ja meetodid AASAs
  
  • Äriprotsesse modelleerime BPMN notatsioon
    
  • Äriprotsesside ühtset registrit hoiame Bizagis´s
    
• Ärisüsteemide vahetus
  
  • 2006 aastal liitusin Eega eesmärgiga analüüsida CRM´i juurutamise võimalusi. –kliendi suhtlus kanal
    
    • EE klienditeenindusel ja jaotusvõrgul ( Elektrilevi OÜ) oli kasutusel üks ühine „Kodukootud“ süsteem + hull „satelliite“
      
    • Süsteemi oli arendatud 10 aastat
      
    • Süsteemi keerukus oli kasvanud üle kriitilise piiri
      
    • EE juhtimismudel oli muutmas piirkondlikust funktsioonipõhiseks
      
  • Juhtimissüsteem ei olnud läbipaistev
    
    • Probleemid kuhjusid ahela viimasele lülile
      
    • Vastu piiride vahetulemis ei olnud süsteemist must-valgelt kättesaadavad
      
    • Erinevad äriüksused eitasid vastu käivad ootusi samale andmeolemile või funktsionaalsusele
      
  • Vastused, protsessid, andmed paika
    
    • 8 liikmeline ärianalüütikute meeskond kaardistas AS-IS seisu
      
    • Koos tippjuhtidega pandi paika To-Be pilt helikopter vaatest
      
    • Ärianalüütikud + äriarhitekt+osakonnajuhid panid paika To-Be detailselt
      
  • Kuulutati välja IT süsteemi hange
    
    • Nõuete list oli ligi 400 lk
      
  • Probleem: Äriprotsessid on läbipaistmatud ja tulemeid ei saa mõõta
    
• Vabaturu projekt
  
  • 2013 aastal mindi Eestis energiamüügi osas vabaturule
    
    • Seadusandlus puudus veel sügisel 2012 (osaliselt tänaseni)
      
    • Äri ei teadnud , mida ja kuidas nad vabaturul vajavad
      
  • Probleem: Seadusest tulenev muudatus
    
  • Analüüs ja nõuete kogumine käis agiilselt paralleelselt IT arendusega
    
    • Analüüsi ja nõuete kogumise käigus sisuliselt töötati välja seadusandlikus, mille MKM määruseks vormistas
      
    • Analüüsi ja nõuete kogumise käigus tuli minna väljapoole oma ettevõtet
      
• Nõuete kaardistamine AASA LOBALIS
  
  • Arendus toimub agiilselt väikeste tükkidena
    
  • Kiire otsus, kiire teostus
    
  • Rahvusvaheline meeskond
    
• Miks on nõuete kaardistus vajalik
  
  • Miks EEs on nõuete kaardistus vajalik
    
    • Suures ettevõttes vananeb nii dokumentatsioon kui teadmus tohutu kiirusega
      
    • Segadused vastutusvaldkondades
      
    • Informatsiooni kogutakse „igaks juhuks“
      
    • Tehakse poolikuid lahendusi
      
    • Dubleeriv aruandlus - vastu käivad tulemused
      
    • Andmete väärkasutus
      
    • „Nendega on pidev mure, ma teen ise“- sündroom
      
• Mida meelde jätta
  
  • Nõuded on vaja kirjeldada ka agiilsearenduse käigus
    
  • Süsteem on laiem mõiste kui konkreetne „IT“ süsteem.
    
  • Head nõuded on eelduseks edukale projektile
    

• Miks tal seda tegelikult vaja läheb?
  
• Mida ta tegelikult vajab?
  
• Kellele seda tegelikult vaja on?
  

• Miks -> Mida -> Kellele
  
• Ära usu esimest vastest!!!
  
• Kas „Mida“ on defineeritud?
  
• Kas „Kellele“ on tegelikult nõude omanik?
  
• Mine nii sügavale kui vaja, et leida juurpõhjus/nõue.
  

Loeng 7:
Tarkvarasüsteemi kvaliteet ja testimine- Jekaterina Tšukrejeva

• Plaan
  
  • Millest koosneb tarkvara kvaliteet
    
  • 
    
  • Tarkvara kontroll:
    
    • Meetodid
      
    • Korraldus
      
• Tarkvara kvaliteet koosneb:
  
  • Väga lühidalt on kvaliteet toote vastavus nõuetele
    
  • Keerukate toodete puhul tuleb vastvuse hindamisel arvesse võtta ka toote loomise protsessi
    
  • Seega seob kvaliteet toote, nõuded tootele ja tootmise protsessi.
    
  • Tarkvara kvaliteet = toode +nõuded +protsessid
    
• Tarkvara kvaliteedist
  
  • Kvaliteeti ei saa sisse testida
    
  • Halvasti arendatud süsteemi pole võimalik kontrolli abil heaks muuta
    
  • Lõpptulemus sõltub kogu arendusprotsessist:
    
    • Sealhulgas vajadustele vastavast riistvarast
      
    • Tarkvara arenduse meetoditest ja vahenditest
      
    • Projekti- ja kvaliteedihaldusest
      
    • Organisatsioonist
      
    • Standardist
      
• Kvaliteedist rääkides:
  
  • Kvaliteet kui ideaal (arvamus ühelt arutelult: „tarkvara kvaliteeti pole olemas, kogu aeg on kiirustamine ja pole aega ühte asja valmis saada, juba tuleb järgmine“) –ideaalset
    
  • Kvaliteet kui mingi tootja või kaubamärgiga kaasas käiv omadus )“see on kvaliteettoode“) – selline teadmine võib anda kasulikku infot hankimisel
    
  • Kvaliteet kui suhe toote, nõuete, protsesside vahel („hinnataset arvestades oli hotelli kvaliteet väga hea“) –selline suhe on alati olemas ja abiks hinnaefektiivsel tegutsemisel kõigis rollides
    
  • Kvaliteet kui mõõt- mõõt on alati olemas (ka näiteks siis, kui „selle süsteemi kvaliteet on madal“)
    
• Tarkvaraprotsessid
  
  • 
    
  • Tarkvara modelleerib tegelikkust ja võib olla väga keerukas, samuti võib olla väga keerukas selle arendus.
    
  • Et selle keerukusega hakkama saada, on tarkvaraga seonduvaid tegevusi, tulemeid, dokumentatsiooni jne mõistlik kuidagi struktureerida. Seda saab teha protsesside ja elutsükli mudelite abil.
    
  • Tuleks eristada tarkvara elutsükli mudeleid ja protsessiraamistikke.
    
  • Teenuste protsesside raamistikud: ISO/IEC 12207, CMMI, COBIT, ITIL .
    
  • Nad hõlmavad väga mitmesuguseid protsesse, mi0e ainult tarkvara arendust. Näiteid protsessidest: hankimine , tarnimine, ekspluatatsioon , hooldus , konfiguratsiooni haldus, muudatuste haldus jne.
    
  • Protsessid:
    
    • Eesmärkide püstitamine ja ärivaate loomine
      
    • Nõuete spetsifitseerimine
      
    • Projektiplaani koostamine
      
    • Arhitektuuri planeerimine
      
    • Riskide ja nende maandamise võimaluste hindamine
      
    • Arendus
      
    • Toote hindamine
      
    • Probleemide haldamine
      
    • Muudatuste haldamine
      
    • Tugi
      
  • Tarkvara elutsükli mudelid
    
    • Kui vaadata iga mudeli sisse, siis näeme, et kõik nad koosnevad: põhikomponentidest:
      
      • Eesmärkide püstitamine ja ärivaate loomine
        
      • Nõuete spetsifikatsioon
        
      • Projektiplaani koostamine
        
      • Arhidetktuuri planeerimine
        
      • Riskide ja nende maandamise võimaluste hindamine
        
      • Arendus
        
      • Toote hindamine
        
      • Probleemide haldamine
        
      • Muudatuste haldamine
        
      • Tugi
        

Eksamil võib olla küsimus: Mis on SCRUM ?

• Nõuded
  
  • Erinevatel osapooltel on erinevad nõuded
    
    • Omanik võib nõuda, et süsteem oleks kuluefektiivne
      
    • Kasutaja või soovida loetavat kirja ekraanil
      
    • Hooldaja näeks heameelega arusaadavat koodi
      
    • Jne
      
  • Nõuete liigid:
    
    • Funktsionaalsed nõuded ja mittefunktsionaalsed nõuded
      
      • Testitav
        
      • Mittetestitav
        
      • Realistlik
        
      • Mitterealistlik
        
    • 
      
    • Funktsionaalne nõue
      
      • Vastavad küsimusele: „Mida peab tarkvara tegema?“
        
        • Näide: Bussijuhina tahan näha nimekirja järgmise päeva liinidest, et saaksin ennast ette valmistada
          
      • Tavalised on need:
        
        • Ärinõudmised, ärireeglid, standardid
          
        • Funktsionaalsus
          
    • Mittefunktsionaalne nõue
      
      • Vastab küsimusele: „Kuidas tarkvara peab vajalikke funktsioone täitma?“
        
        • Näide: Kurja häkkerina tahan varastada krediitkaartide andmeid, et saaksin kalleid asju osta.
          
      • Tavalised need on:
        
        • Süsteemsed nõudmised ja piirangud
          
        • Tõhusus , turvalisus, töökindlus , kasutajaliides jne
          
        • Muud piirangud
          
    • Testitav/Mittetestitav nõue
      
      • Nõuete püstitamisel on oluline, et nad oleksid testitavad!
        
        • Nõue: Süsteem peab väljastama jooksva hetke laoseisu.- nõue on hea ja testitav, funktsionaalne nõue
          
        • Nõue: Süsteem peab olema töökindel- ei ole hea nõue
          

Parem on nii:

• Nõue: Süsteemi töö võib kuu aja pikkuses ekspluatatsioonis keskkonnas X, kasutusaktiivuse Y ja kasutuslaadi Z korral olla häiritud maksimaalselt ühe tunni jooksul.
  
• Reaalne/ Ebareaalne nõue
  
  • Nõue võib olla testitav, kuid ebareaalne, ebamõistlik, ebapiisavalt spetsifitseeritud jne
    
    • Näide: Otsingu vastuse aeg peab jääma alla 1 sekundi –see ei ole hea nõue
      
• Hea nõue on:
  
  • Üheselt mõistetav
    
  • Selge ja lühike
    
  • Täpne, arusaadav
    
  • Realiseeritav
    
  • Sõltumatu
    
  • Vajalik ja aktuaalne
    
  • Täielik, kõik info ühe nõude juures
    
• Näide
  
  • Võiks paremini: Kasutaja võib sisestada lennujaama koodi. Võib sisestada ka lähedal asuva linna, et kasutaja ei peaks meeles pidama kõiki lennujaamade koode, kuid süsteem peab teadma lennujaamade koode. – Funktsionaalne nõue, mis on testitav ja on reaalne
    
  • Hea: Kasutaja võib otsida lennujaama sisestades linna või lennujaama koodi.
    
  • Võiks paremini: Kasutaja ei saa sisestada parooli, mis on pikem kui 15 sümbolit
    
  • Hea: Kasutaja ei saa sisestada parooli, mis on pikem kui 15 sümbolit. Kui kasutaja sisestab pikema parooli kui 15 sümbolit, vastab süsteem sellele veateatega. Reaalne nõue.
    
• Nõuded. Kokkuvõte.
  
  • Kas nõue peab olema koguaeg testitav?
    
  • Otstarbekas on püstitada testitavad nõuded, muidu ei saa nende täidetust hinnata.
    
• Tarkvaratoode
  
  • Millest koosneb?
    
    • Arenduse käigus hangitud infotehnoloogiavahendid: riistvara, standardtarkvara, sideseadmed.
      
    • Arenduse käigus tehtud töö: täitja arendatud tarkvara (sealhulgas lähtekood, objektkood, täitmiskood jm); installatsioonid, kohandamised, muudatused; andmehõive
      
    • Muudatused tellija organisatsioonis, protsessides, töökorralduses…
      
    • Metoodika: tulemuste kasutamine; tulemuste edasiarendamine; uute arenduste tegemine
      
    • Projektdokumentatsioon kasutamise kohta (kasutajajuhendid); objektsüsteemi (nt organisatsioon , mille jaoks tarkvara arendatakse) kohta; loodavate objektide kohta (programmi/testimise dokumentatsioon); installeerimise ja seadmise kohta; arenduse (sh testimise) kohta.
      
    • Teadmised projekti tulemuste kasutamisest; objektsüsteemist( süsteemianalüüs või vajalikud muudatused seadusandluses); projektist; arendusest.
      
    • Õigused tööks, arendamiseks, levitamiseks
      
    • Vahendid hoolduseks, muudatusteks, arenduseks.
      
  • Tarkvara kvaliteet= toode + nõuded +protsessid
    
• Testimine
  
  • 
    
  • Põhimõtted
    
    • Kitsamas mõttes on testimine tarkvara täitmine/ käivitamine kontrollimaks, kas ta vastab ettenähtud nõuetele ning leidmaks vigu
      
    • Laiemas mõttes on testimine tarkvara analüüsi protsess eesmärgiga leida erinevusi olemasolevate ja nõutud tingimuste vahel ning hinnata tarkvara omadusi
      
    • Testimist võib laias mõttes määratleda ka kui kõikidest elutsükli tegevustest (nii staatilistest kui ka dünaamilistest) koosnevat protsessi, mis puudutab tarkvara ja sellega seotud toodete planeerimist, ettevalmistust ja hindamist ning mille eesmärk on kindlaks teha toodete vastavus spetsifitseeritud nõuetele, näidata et nad vastavad eesmärgile ning leida defekte.
      
  • Testimine
    
    • Efektiivseks testimiseks ei piisa vaid süsteemist. On vaja teada nõudeid ja protsesse, mis omakorda tulenevad:
      
      • Ülesande püstitusest
        
      • Organisatsioonist
        
      • Seadusandlusest
        
      • Standarditest
        
      • Riskianalüüsist
        
      • Headest tavadest
        
      • Kasutajatest
        
      • Kasutusviisist jne
        
  • Testimis meetodid
    
    • Staatiline või dünaamiline
      
    • Kastide testimine
      
      • Musta kasti meetodid
        
        • Visuaalne testimine
          
      • Halli kasti meetodid
        
  • Staatiline ja dünaamiline testimine
    
    • Staatiline testimine (static testing) – süsteemi või komponendi (koodi või dokumendi) testimine ilma testitavat tulemit käivitamata
      
      • Läbivaatuse(review)
        
      • Staatiline analüüs (static analysis)
        
    • Dünaamiline testimine- testimine, mille käigus testitavat tarkvara käivitatakse
      
      • „tavaline testimine“
        
    • 
      
  • Statistikat läbivaatuste kohta
    
    • Tarkvara inspektsioon võimaldab leida 70-80% vigadest enne funktsionaalset testimist
      
    • Tunni jooksul leitav vigade keskmine arv
      
      • Funktsionaalne valge kasti testimine -0,282
        
      • Funktsionaalne musta kasti testimine-0,322
        
      • Läbivaatused- 1,056
        
    • Reeve´i rusikareegel – iga inspektsiooni käigus leitud viga sööstab 9,3 töötundi
      
  • Millele teha läbivaatust?
    
    • Nõuetele
      
    • Arhitektuuri joonisele
      
    • Tarkvaraga seotud erinevate joonised: UML diagrammid jne
      
    • Koodile , kood struktuurile, kas kood vastab Clean Code nõuetele
      
    • Protsessile: kas töö on organiseeritud valitud protsessi järgi?
      
    • Tegevusele: Scrum
      
  • Kastide testimised:
    
    • Valge kasti testimine
      
      • Testijal on juurdepääs sisemistele andmestruktuuridele ja algoritmidele (ja koodile, mida rakendatakse). Testija püüab süstemaatiliselt läbida programmi mingeid osasid, näiteks lauseid , harusid, teid.
        
      • Valge kasti testimise tüübid on:
        
        • Rakendusliideste (API) testimine – rakendust testitakse avalike ja privaatsete rakendusliideste kaudu
          
        • Koodi ulatus – luuakse teste , mis testivad koodi ulatust. Näiteks testi disainer võib luua testi, mille käigus kõiki avaldisi (lauseid/käske) programmis käivitatakse vähemalt ühe korra.
          
        • Vigade süstimine – koodi ulatuse parandamine kontrollides, kas tarkvara töötab vigade lisamisel
          
        • Staatiline testimine – valge kasti testimine hõlmab kogu staatilist testimist
          
    • Musta kasti testimine
      
      • Testimine kohtleb tarkvara kui "musta kasti", teadmata midagi selle sisemisest teostusest.
        
      • Musta kasti testimismeetodite hulka kuuluvad:
        
        • Spetsifikatsiooni põhine testimine
          
        • Juhuslikud sisendid ja lisatud vead
          
        • Uurimuslik testimine
          
        • Piirväärtuste analüüs
          
        • Suitsu testimine
          
        • Kasutusmugavuse testimine
          
    • Halli kasti testimine
      
      • Testimisel on olemas juurdepääs sisemistele andmestruktuuridele ja algoritmidele testjuhtumite koostamisel, kuid testimine viiakse läbi kasutaja või musta kasti tasemel.
        
      • Halli kasti testimise alla kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja väljaspool testitavat süsteemi andmeid muuta.
        
      • Halli kasti testimine võib hõlmata ka pöördprojekteerimist leidmaks näiteks piirväärtusi või tõrketeateid.
        

• Testimise tasandid:
  
  • Ühiktestimine
    
    • Ühiktestimisel vastab üks test konkreetsele koodi osale, tavaliselt funktsioonile. Objektorienteeritud keskkonnas testitakse klasside tasemel ja minimaalsesse testi kaasatakse ka konstruktorid ja destruktorid.
      
    • Ühikteste kirjutavad arendajad tavaliselt valge kasti stiilis, et kontrollida, kas mingi funktsioon töötab, nagu e0e nähtud. Ühe funktsiooni kohta võib olla mitu testi, et kontrollida funktsiooni töötamist piirväärtustel või erinevaid koodi harusid. Ühiktestimisega ei saa tagada terve tarkvaratoote õigsust. Pigem kontrollitakse sellega, kas erinevad tarkvara osad töötavad üksteisest eraldi.
      
  • Lõimumise testimine. Integration testing
    
    • Kontrollitakse, kas komponentide vahelised liidesed vastavad tarkvara disainile. Tarkvara komponente võib integreerida järk-järgult või ühekorraga. Tavaliselt eelistatakse viimast, sest nii saab kiiremini leida ja parandada vigu liidestes.
      
    • Selline testimine paljastab defektid liidestes ja vastastikustes toimetes integreeritud komponentide (moodulite) vahel.
      
    • Integreeritakse ja testitakse järjest suuremaid tarkvara komponentide gruppe, mis vastavad arhitektuurilise disaini elementidele, kuni kogu tarkvara töötab ühtse süsteemina.
      
  • Süsteemi testimine
    
    • Testitakse täielikult integreeritud süsteemi, et kinnitada süsteemi nõuetele vastavust. Musta kasti testimine.
      
    • 
      
  • Süsteemi integratsiooni testimine
    
    • Kinnitatakse, et süsteem on integreeritud mistahes välise või kolmanda osapoole süsteemiga, mis on määratletud süsteemi nõuetes.
      
  • Regressioonitestimine
    
    • Eesmärgiks on otsida vigu pärast koodi olulist muutmist .
      
    • Tavaline regressioonitestimise meetod on läbi viia varem kasutatud teste, et kontrollida, kas eelnevalt kindlaks tehtud rikked on taas esile kerkinud. Regressioonitestimise ulatus sõltub arendustegevuse etapist ja lisatud funktsionaalsuse kaalukusest.
      
    • Testimine võib olla täielik, kui muudatused on riskantsed või neid tehakse arenduse hilistes järkudes, või osaline, kui muudatused tehakse vara või ei ole eriti riskantsed.
      
      • 
        
  • Vastuvõtu testimine
    
    • Vastuvõtu testimine võib tähendada kahte asja:
      
      • Viiakse läbi proovitest, et kontrollida, kas uus tarkvara komponent on vastuvõetav peamisse testimise protsessi, näiteks enne lõimumis - või regressioonitestimist.
        
      • Kliendi tehtud testimist, tihti tema enda arenduskeskkonnas ja riistvaral, nimetatakse kasutaja vastuvõtu testimiseks.
        
• Testimise tüübid
  
  • Funktsionaalne testimine
    
    • Riskipõhine
      
      • Riskipõhise testimise idee on testida esmalt tootega seotud kriitilisi riske
        
    • Uuriv testimine
      
      • Uuriv testimine (exploratory testing) on mitteformaalne tarkvara testimise tehnika, mille puhul testija hindab testide kavandamist nende täitmise käigus ja kasutab saadud informatsiooni uute ja paremate testide projekteerimiseks
        
    • Suitsu testimine
      
      • Suitsutestimisel (smoke testing) täidetakse alamhulk kõigist testidest selgitamaks, kas põhilised funktsioonid töötavad. Nimetus tuleneb elektroonikatööstusest (seadme esmane sisselülitamine).
        
    • Ekspertteadmiste põhine
      
      • Kogenud arendaja või testija oskab tõenäolisi vea kohti ette aimata. Tõenäoliste vigade leidmine võib sõltuda mitut sorti eelteadmistest, milleks on:
        
        • Üldised teadmised
          
        • Teadmised konkreetse rakendusvaldkonna kohta
          
        • Teadmised riist - või tarkvarakeskkonna (näiteks konkreetse programmeerimiskeele) kohta
          
        • Teadmised mingi vigade tüübi kohta (näiteks tüüpilised infoturbega seotud kodeerimise vead)
          
        • Teadmised arendusmetoodika kohta
          
        • Teadmised konkreetse arendaja või tellija kohta jne
          
  • Mittefunktsionaalne testimine
    
    • Jõudlustestimine ja koormustestimine
      
      • Jõudlustest kontrollib, kui kiiresti tarkvara töötab kindla koguse andmete või kasutajatega.
        
      • Koormustestimisega kontrollitakse, kas tarkvara suudab püsivalt töötada kindlal koormusel.
        
      • Kui koormustestimist tehakse mittefunktsionaalselt, siis nimetatakse seda tihti vastupidavuse testimiseks.
        
      • Jõudlustestimise ja koormustestimise all mõeldakse tihti sama asja.
        
    • Stabiilsuse testimine
      
      • Stabiilsuse testimine kontrollib, kas tarkvara on võimeline pidevalt töötama kindla ajaperioodi jooksul. Seda nimetatakse mõnikord vastupidavuse testimiseks.
        
    • Kasutatavuse testimine
      
      • Kasutuse katsetamine on vajalik, et kontrollida, kas kasutajaliidest on lihtne kasutada ja mõista
        
    • Turvalisuse testimine
      
      • Turvalisuse testimine on oluline tarkvara puhul, mis töötleb konfidentsiaalseid andmeid, et vältida süsteemi haakimist või ründamist.
        
    • Destruktiivne testimine
      
      • Destruktiivsel testimisel üritatakse tekitada tõrkeid tarkvaraprogrammis või käitumiskeskkonnas, et testida selle robustsust.
        
• Testimise protsess
  
• Testimise tsükkel
  
  • Nõuete analüüs. Katsetamine peaks algama tarkvaraarenduse elutsükli nõuete faasis. Sellel etapil töötavad testijad arendajatega, et teha kindlaks, millised tarkvara aspektid on testitavad ja milliste parameetritega need testid töötavad.
    
  • Testimise planeerimine. Testimise strateegia, plaani ja testimiskeskkonna loomine. Kuna testimisel on palju tegevusi, siis on plaan vajalik.
    
  • Testide arendamine. Tarkvara testimiseks kasutatavate protseduuride, stsenaariumite, testjuhtumite, andmekogude ja skripride loomine.
    
  • Testide täitmine. Testijad käivitavad testid plaanide ja testimise dokumentide alusel ja seejärel teavitavad arendusmeeskonda leitud vigadest.
    
  • Testide aruandlus. Kui testimine on lõpetatud, loovad testijad mõõtarve ja teevad lõpliku aruande testimise kohta ja selle kohta, kas tarkvara on valmis väljastamiseks.
    
  • Testitulemuste vigade analüüs. Seda teeb arendusmeeskond tavaliselt koos kliendiga, et otsustada, milliseid vigu tuleks parandada, millised tagasi lükata (st leiti , et tarkvara töötab korralikult) ja milliseid vigu parandada millalgi tulevikus.
    
  • Vigade uuesti testimine. Kui arendusmeeskond on üritanud viga parandada, siis testitakse seda uuesti.
    
  • Regressioonitestimine. Tihti luuakse teatud hulgast testidest koosnev väike testprogramm iga uue, muudetud või parandatud tarkvara versiooni kohta, et t ägada, et viimased muudatused midagi ära lõhkunud ja tarkvaratoode tervikuna töötab endiselt õigesti.
    
  • Testimise lõpetamine . Kui katse vastab lõpetamise kriteeriumitele, siis tegevused nagu väljundi püüdmine, õppetunnid, tulemused, logid ja projektiga seotud dokumendid arhiveeritakse ja neid kasutatakse viitena tulevastes projektides.
    
• Testimise maht ja lõpetamine. Millal piisab ?
  
  • Testimise resultatiivsust pole kerge hinnata. Seepärast pole ka testimise mahu üle otsustamine kerge.
    
  • Ideaalselt peaks testimise maht sõltuma tarkvarale esitatud nõuetest- testitakse seni, kuni need on rahuldatud. Praktiliselt tehakse nii vaid tõesti kriitiliste rakenduste korral.
    
  • Põhjusi on palju, näiteks:
    
    • Nõudeid ja nende rahuldatust on raske hinnata;
      
    • Töö tuleb kiiresti üle anda;
      
    • On olemas eelnev kogemus ja see määrab testimise mahu;
      
    • Rakendus ei ole kriitiline (kui midagi juhtub, keegi eriliselt ei kannata) jne
      
  • Kriteeriumid
    
    • Esimesed testid jooksid läbi
      
    • Kasutaja ei oska rohkem tahta
      
    • Testimise (või halvemal juhul süsteemiarenduse) aeg või raha on läbi
      
    • Eelmine kord testisime samapalju ja oli hea küll
      
    • Süsteemi üleandmise tähtaeg on käes
      
    • Paistab, et edasine testimine ei anna uusi vigu
      
    • Pole enam huvitav, tahaks midagi muud teha
      
    • Jne
      

• Kõik ekvivalentsiklassid (piirjuhud) peavad olema testitud
  
• Testimine peab vastama haruadekvaatsuse kriteeriumile
  
• Olulisemad andmekombinatsioonid peavad olema testitud
  
• Andmepõhise testimise piirjuhud peavad olema testitud
  
• V% lisatud vigadest peavad olema avastatud
  
• Tarkvara töökindlus peab olema P%
  
• Kokkuvõtte
  
  • Tarkvara kvaliteet = toode + nõuded+ protsessid
    
  • Nõuded peavad olema reaalsed ja testitavad
    
  • Testida tuleb juba siis, kui esimesed nõuded on kirja pandud
    
  • Enne testimist tee valmis test juhtumid ja vaata üle koos arendajaga
    
  • Analüüsi testimistulemusi
    
  • Suhtle tiimiga
    
  • Määrake kliendiga testimise mahu
    
  • Pange kliendiga paika testimise lõpetamise kriteeriumid
    

Loeng 8
Testimisest – Mart Toom [email protected]

• Testimine on informatsiooni kogumine testitava objekti kohta.
  
• Tarkvara testimine päriselus
  
  • Riigiamet
    
  • Ajakiri Tehnikamaailm
    
    • … tasuta aastatellimus
      
  • Telisa 2
    
    • Pisikeses kirjas olevad tekstid
      
  • Jne
    
• Testijale abiks omadused ja oskused
  
  • Detailid, detailid, detailiid
    
  • Oskus näha suurt pilti
    
  • Fookuse vahetamine
    
  • Oskus ja julgus küsida küsimusi
    
    • Ka teravaid küsimusi aga viisakalt
      
  • Uudishimu
    
  • Suhtlemisoskus
    
  • Lugemisoskus
    
  • Kirjutamisoskus
    
• Valik jaotusi testismisele
  
  • Arendus testine ja vastuvõtmine
    
  • Dünaamiline ja staatiline testimine
    
  • Checkimine ja testimine
    
  • Regressioonitestimine ja re-testimine
    
  • Funktsionaalne ja mittefunktsionaalne testimine
    
  • Manuaalne ja automatiseeritud testime
    
• Sobiv testimine
  
  • Desktop nimegeneraator lapsele nime valimiseks – elementaarne kasutaja testimine, tegelikult kui sa ise ainult seda kasutad, siis pole üldse mõtet testida.
    
  • Netipanga mobiilirakendus – ühiktestid, koormustestid, funktsionaalsed testid, jne nii palju kui saad ja võimalik on
    
  • Ülikooli harjutustunni tehtud rakendus – ühiktestid, kasutajatestid
    
• Testijaks olemise võlud
  
  • Palju huvitavaid projekte
    
  • Koguaeg on põnev
    
  • Saab kombata piire
    
  • Suhelda saab palju ja paljudega
    
  • Zen töö
    
  • Emotsioonide rohkus
    
• Kokkuvõtteks
  
  • Testimine on info hankimine
    
  • Ära häki live süsteemides luba küsimata
    
  • Oskuste T-mudel
    
  • Testimise võimalusi on väga palju
    
  • Testimine on äge.
    

Loeng 9
Ekstreemne programmeerimine – Erik Jõgi

• Manifest Agiilsele programmeerimisele – www.agilemanifesto.org
  

• Meie kõrgeim prioriteet
  

On rahuldada meie klienti
Läbi varajase ja jätkusuutliku saadetise
Mis on väärtuslik tarkvara

• Töötamine tarkvaraga on
  

peamine mõõteriist progressist

• Tervita muutuvaid nõudmisi
  

Isegi hilises faasis.
Ekstreemne programmeerimine
Võta parimad praktikad ja vii need ekstreemsele tasemele

• Tarkvara-arendus distsipliin
  

Mis organiseerib inimest
Tootma kõrgema kvaliteediga tarkvara
Produktiivsemalt

• XP väärtused
  
  • Arenda suhtlust
    
  • Otsi lihtsust
    
  • Saa tagasisidet
    
  • Tegutse julgusega
    
• XP @ Codeborne
  
  • Projekt
    
    • Klient kirjeldab probleemi
      
    • Me arutame ja mõtleme mida saame teha
      
    • Me nõustume
      
      • Tunnihinnas, üldine ajakulu vms
        
    • Töökäik
      
      • Storytelling - Userstory ehk loo rääkimine , mis töö tuleb ära teha, see on kliendi jaoks aru saadav, kaastakse sellesse kliendi poolt valitud spetsialistid, kes hakkavad tarkvara kasutama, Codeborne poolt on samuti arendajad jne juures. Väga suurte projektide puhul on vaja kokku saada ka mitu korda.
        
      • Iteratsiooni kohtumised - iga nädal, räägitakse läbi projekti detailid, klient täpsustab prioriteedid - me ei hakka kunagi tegema midagi, mida klient pole prioriteediks määranud. Hea kliendi jaoks ülevaateks.
        
      • Igapäeva töö – stand-up kohtumine , mis on lühike ja sisutihe. Kutsutakse kokku kogu tiim .
        

• Iga päeva töö, tootmine-
  
  • paarisprogrammeerimine-üldjuhul on rollid üle võetud rallisõidust, üks on see kes jälgib nn strateegiat ja teine programmeerib, hea oleks rolle vahetada iga 5 min järel, teine variant on nii, et üks kirjutab käsu ja teine sellele testi ja siis vahetatakse. Paarisprogrammeerimise puhul on ka väga hea õppeprotsess.
    
  • Tuleks kasutada ka Test-driven development, ehk testidele põhinevat tootmist, kus enne kirjutad valmis testi ja siis alles vastavalt sellele koodi. Testid aitavad ka paremini välja mõelda, milline peaks olema koodi disain.
    
  • Refaktoorimine, kohe peale testide loomist tee oma kood puhtamaks ja refaktoori see, et see oleks veel parem.
    
• BDUF
  
  • Big Design Up Front - mingi meetod, mis põhineb esmalt disainil. Kui sa teed piisavalt vähe disaini, siis see lihtsustab hiljem koodi muutmist kui sul on rohkem teadmisi ja oskusi. Kui sa aga teed liiga detailse disaini, siis see viib selleni, et sa pole võimeline enam koodi ja tehtavat disaini kokku viia.
    
• Koodi tootmine
  
  • Kood kirjutatakse kollektiivselt, mitte ainuomandi koodina. Kogu koodist peab saama aru terve tiim, mitte ainult üks. Oluline on see, et tiimist mingi inimese ära võtmisel, ei jääks projekt seisma ja toppama.
    
  • Automaatsed aksepteerimise testid, sellised testid, mis teeks lihtsamaid kasutaja teste, et see testiks kas kogu kood ka reaalselt töötaks. Neid käivitatakse harvem kui automaatteste.
    
• Saatmine
  
  • Jätkusuutlik integratsioon - oluline et kõik see kood kompileeriks, et see kõik töötaks. Kõik integratsiooni vahendid peavad seda toetama ja selle käigus ka koguma vajaliku infot, et sellest saaks ka teavitatud teised tiimiliikmed.
    
  • Jätkusuutlik kasutuselevõtmine- et klient näeks võimalikult ruttu, mida me oleme loonud ja saaks juba koguda tagasisidet, mida saaks veel muuta ja parandada. See annab väga palju väärtust juurde kliendi suhtes.
    
• Klientidega suhtlus
  
  • Pidev suhtlus erinevates keskkondades , nt Skype, slack jne kliendiga. See on hea ka selleks, et oleks võimalikult ruttu avastada bug-e, see on odavam ja lihtsam. Mida kiirem on tagasiside seda odavam ja efektiivsem on tarkvara.
    
• Iteratsiooni kohtumine
  
  • Kliendiga, mille käigus esmalt näidatakse kliendile demo varianti. Selle käigus tihti peale ka saadakse lisainfot, mis võib valesti olla, mida teha teisiti, mida lisada jne. Sellel hetkel antakse ka suure tõenäosusega uued prioriteedid.
    
• Jätka, seda mida sa siiani teinud oled
  
  • Jätkusuutlikus- nt ei tohi teha ületunde, kuna see kurnab inimesi. Teine osa sellest näitab koodi disaini ja refaktoorimist, ka neid tuleb pidevalt ja jätkusuutlikult vaadata ja arendada.
    
  • Hinda, nt storydele hinnangu andmine, et sa saaksid jällegi tagasisidet. See on ka hea tagasiside kliendile.
    
• Vabasta tarkvara live
  
  • Nii kiirelt kui võimalik
    
• Arenda
  
  • Arenda kogu protsessi käigus iseennast , õpi pidevalt
    
  • Vaata tagasi, mida on tehtud
    
• Ole Agiilne! – nii saab head tarkvara
  

Loeng 10
Agiilne programmeerimine LHV-s – Rainer Tikk

• Tehnoloogia ei ole lihtsalt vahend
  
• Üha rohkem äri sisu ja tarkust on tehnoloogias kinni
  
• Agiilne arendus ei ole mingi „asi, mida IT teeb“
  
• Äri peab arenema agiilselt
  
• Äri ja tehnoloogia arenevad koos
  
• Cross-funktsional tiim
  
  • Kõik vajalikud rollid on kaetud
    
  • Teistest sõltumatu
    
  • Fookus koostööl ja tulemusel
    
  • Iga inimene oskab kõike
    
  • 
    
• Self-organizing tiim
  
  • Meeskond on isemajandav
    
  • Ühised eesmärgid, vastutus, otsused
    
  • 
    
• Pank on üks suur iteratsiooni süsteem
  
  • 
    
• Metoodika ja tehnikad
  
  • Agile (Scrum, Lean , XP, …)
    
    • Lean-
      
      • Ehita õiget asja (45% ehitatakse mida pole vaja- milline raiskamine)
        
        • Iteratsioonid/tagasiside
          
        • MVP- kõige väiksem tükk mida vaja on, kuid on kasulik
          
        • Mõõdikud
          
        • „Raiskamise“ minimaliseerimine
          
        • Kvaliteedi sisse ehitamine
          
        • Pidev areng – kuidas koguaeg asja paremini teha
          
  • Waterfall
    
  • Kanban – valge tahvel, kuhu saab joonistada, lisada post-it pabereid jne
    
    • Visualiseerib töövoogu
      
    • Limiteeritakse töös olevaid taskide arvu ehk WIP ( work in progress)
      
    • Tootlikuse voog ( pull system) reguleerib nn laiust, et kui palju on asju torus ning kui kiirelt sealt see ka välja tuleb
      
    • Muuda protsessi poliitika oleks selge
      
    • Parendada mingeid protsesse
      
  • Test-driven Development (TDD)
    
  • Persona -driven Development (PDD)
    
  • BDD, ATDD, …
    
  • Continuous Integration
    
  • Continuous Delivery
    
  • UAT
    
  • …
    

• Neid võiks teada vähemalt nii palju, et mida mingi asi teeb
  

• Kommunikatsioon
  
  • StandUp kohtumised
    
  • Protsessi arengu kohtumised
    
  • Toote planeerimis kohtumised
    
• Mõõdikud
  
  • Miks, mida, kuidas mõõta?
    
  • Kuidas aru saada, et midagi muutub paremaks, kiiremaks, efektiivsemaks?
    
  • Actionable metrics vs Vanity metrics
    
  • Tavaliselt, mida sa muudad, need muutuvad need paremaks, kuna enam jaolt need muutuvad teiste arvelt
    

Loeng 13
Modelleerimine ja UML agiilse tarkvaratehnika kontekstis- Kuldar Taveter

• Mis on mudel?
  
  • Hüpoteetiline lihtsustatud kirjeldus keerulisest protessist vms
    
  • Mudel peab olema nii keeruline kui vaja aga mitte üleliia
    
  • Peame vaatama mis on olulised
    
  • Peame ka vaatama, mida pole vaja
    
• Näiteid mudelitest
  
  • Päikesepaneelide süsteemid
    
  • Kaevanduse mudel
    
  • Lennu liikluse simulaator
    
  • Jne
    
• UML
  
  • Tööstuse abil saanud modelleerimiskeel/ modelleerimis standard tarkvara süsteemide loomiseks. Enam jaolt esitatakse neid just tarkvarasüsteemide vms ehitamisel, et asja visualiseerida, selleks kasutataksegi UML-i.
    
• Miks on mudeleid vaja?
  
  • Vahendid, et soodustada sikussiooni olemasoleva või loodava süsteemi üle
    
  • Vahendid dokumenteerimaks olemasolevat süsteemi
    
  • Detailne süsteemi esitus, millest saab (osaliselt) genereerida süsteemi realisatsiooni
    
• Tarkvaratehnika vaated
  
  • Omaniku vaade
    
  • Kavandaja vaade
    
  • Ehitaja vaade
    
• Tarkvaraprotsessi etapid
  
  • Nõuete esiletoomine ja analüüs
    
  • Kavandamine e. disain
    
    • Arhitektuuriline kavandamine
      
    • Detailne kavandamine
      
  • Realiseerimine
    
  • Testimine
    
  • Hooldus ja evolutsioon
    

• Iteratiivne arendamine
  
  • 
    
• Scrum
  
  • 
    
• Modelleerimine
  
  • Igal etapis ja igas faasis on oma „tehised“ (artefacts): graafilised ja tabulaarsed mudelid, dokumendid, kood jne.
    
• Mudelite klassifikatsioon
  
  • 
    
  • Eksamil on küsinud nt: Rääkige mudelitest analüüsi iteratsiooni vaatepunktist, tooge välja selle mudel, punane kast ümber, mille kohta võib küsida. Vastus Videos 00:24-01:15
    
• Käitumise analüüs
  
  • Mis eesmärke süsteem peaks saavutama?
    
  • Millised rollid on nende eesmärkide saavutamiseks vajalikud?
    
  • Milliseid tegevusi süsteem peaks toetama?
    

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• Iteraktsioonide analüüs
  
  • Kuidas süsteem peaks suhtlema kasutajaga ja teiste süsteemidega?
    
  • 
    
  • 
    
  • 
    
  • 
    
  • 
    
  • 
    

• Struktuuri analüüs
  
  • Mis osadest süsteem koosneb ja kuidas need on omavahel seotud?
    
  • Millist tüüpi olemite kohta peaks süsteem informatsiooni esitama ja kuidas need olemid on omavahel seotud?
    
  • 
    
  • 
    
  • 
    
  • 
    
  • 
    
  • 
    
• Interaktsioonide disain
  
  • Milliseid teateid süsteemi osad vahetavad omavahel ja kasutajaga?
    
  • 
    
  • 
    
  • 
    
• Struktuuri disain
  
  • Millist informatsiooni süsteemis esitada?
    
  • 
    
  • 
    
  • 
    
• Käitumise disain
  
  • Kuidas süsteemi olemid käituvad?
    
  • 
    
  • 
    
  • 
    
• Soovitus
  
  • Modelleerige oma tarkvarasüsteemi abstraktsioonitasemete ja vaatepunktide kontekstis
    
• Kokkuvõte
  
  • Igal tarkvaraprotsessi etapis ja igas faasis on oma „tehised“ (artefacts): graafilised ja tabulaarsed mudelid, dokumendid, kood jne
    
  • Mudelid on vajalikud selleks, et keerulisest süsteemist aru saada
    
  • Mudelitel on oma klassifikatsioon horisontaalsete ja vertikaalsete dimensioonide järgi
    
  • Agiilse tarkvaratehnika metodoloogiad -> probleemvaldkonna esialgne liigendamine on kriitilise tähtsusega!
    
  • Ka analüüs peab toimuma iteratiivselt!
    
  • Organiseeri tarkvaraarendus eesmärgipõhiselt, kus kasutuslood kirjeldavad ärieesmärkide realiseerimist
    
  • Üldiselt hõlmab üks Scrumi Sprint mitut ärieesmärki
    
  • Kasutuslood võib omakorda jaotada ülesanneteks- Taskideks.
    

Loeng 14
Kokkuvõte agiilsest arendamisest- Kuldar Taveter

• 
  

• 
  

• 
  
• 
  
• See võib olla ka eksamis sees
  
• See on eksamil, tuua juurde ka näiteid selle kohta, rohkem iseloomustada seda. Agiilse arendamise põhimõte, illustreerida seda näidetega, mis on ühe või teise põhimõtte all mõeldud
  
  • Individuaalid ja nende suhtlus on tähtsamad kui protsessid ja tööriistad
    
  • Töötav tarkvara on olulisem kui ulatuslik dokumentatsioon
    
  • Pidev koostöö kliendiga on tähtsam, kui kliendiga algul lepinguga läbirääkimine
    
  • Muudatustele allumine on tähtsam, kui jälgida plaani
    
    • Kõiki neid paremal kaste on vaja kuid olulisemad on vasakul pool
      
• 
  

Kasutatakse tavaliselt mitut metoodikat korraga.
Eksamil võib olla küsimus: Võrdle kolme meetodikat omavahel.

• XP- rohkem rõhku koodil, refaktoreerimine, clean code, paarisprogrammeerimine.
  
  • Ingrementaalne planeerimine- kus kogu plaan pole ette tehtud vaid plaanime ainult ühe interatsioonii kaupa.
    
  • Väikesed tootemustandid, mis välja antakse ja mida klient saab proovida.
    
  • Lihtne disain, seda tehakse piisavalt nõuetele vastavalt.
    
  • Oluline on testimine ja refaktoorimine.
    
  • Oluline on paarisprogrammeerimine ja see, et kogu kood oleks kollektiivne, mitte ainuisikuline.
    
  • Interatsioon peab olema jätkusuutlik.
    
  • Kindlasti on oluline õige tempo.
    
  • Klient peab osalema kogu projekti vältel arendustöös ning pidevalt suhtluses olema.
    

• Scrum- põhiline rõhk projektihaldus, projekti juhtimis metoodikad on toodud tarkvaratehnika süsteemide loomisesse.
  

Eksamil võib eraldi olla küsimus: Kirjelda SCRUMi aluseid

• Scrum töötab põhimõttel: Jaga ja valitse.
  
  • Esmalt jagatakse toode mõistlikeks tükkideks, mis esindaks tervikut ehk interatsioonideks.
    
  • Teiseks tuleb jagada oma organisatsioon tiimideks, millele on antud mõistlikud projektid.
    
  • Kolmandaks tuleb ära jagada aeg, ehk millal tuleb toode valmis olema ja see tuleb panna ajateljele, mis ajal mingi etapp vms toimub.
    

• Scrumi põhimõtted:
  
  • Rollid jagatakse vastavlt
    
    • toote omanik
      
      • kliendi esindaja, kes otsustab mida toode teeb, millal peab valmis olema ja palju maksab
        
      • teeb ajatelje
        
      • õigus aktsepteerida või tagasi lükata toode igas interatsiooni lõpus
        
    • scrumi-i juht/ projektijuht
      
      • Garanteerima, et töö toimub SCRUMi põhimõtetele
        
      • Kõrvaldab takistused
        
      • Peab tagama tiimi funktsionaalsuse ja et nad oleksid tootlikud
        
      • Kaitsma tiimi väliste mõjutuste vastu
        
    • tiim.
      
      • Tavaliselt on tiimis 5-9 inimest
        
      • Nad on kokku pandud nii, et kõik oskavad kõike, mingil määral on siiski sildistatud vastavalt nende proffesionaalsusele ehk siis programmeerija , testija, jne
        
      • Liikmelisus võib muutuda vaid interatsioonide vahel, mitte selle keskel
        
  • Tseremooniad: Sprindi /interatsiooni planeerimine, sprindi/interatsiooni järelvaatus enne üleandmist, interatsiooni järelvaatused ja igapäevased scrumi kohtumised.
    
  • Tehised: Tooted mis on jagatud tükkideks, interatsioonideks jagatud tükid ning erinevad graafikud, mida kasutatakse edukuse mõõtmiseks.
    
• 
  
• Kasutuslood (user stories)
  
  • Üldkuju: Kui kasutaja mängib üht teatud rolli, siis mina pean olema võimeline tegema mingeid tegevusi, et tellimus saavutaks eesmärgi
    
  • 
    
  • 
    
  • 
    

• Kanban- põhi rõhk on konveier süsteemil, mis on omal ajal tulnud Ford-i autotööstusest
  
  • Selle põhimõtted:
    
    • Pull Value through the Value Stream- ehk kogu protsessi käigus toimub tõmbe süsteem, ehk ühes otsas on sisend ja teises otsas on väljud
      
    • Limit WIP- ei tohi olla liiga palju tööd parasjagu töös, ehk kindlalt on ette antud, mitu asja parasjagu või pooleli olla
      
    • Tee kõik nähtavaks
      
      • 
        
      • 
        
  • Ideoloogia
    
    • „Lean“- keskendu sellel, mida klient vajab
      
      • Ära loo mingit väärtust, ilma et seda vajataks
        
      • Ära loo rohkem nõudeid, kui sa suudad kodeerida
        
      • Ära kirjuta rohkem koodi, kui sa ei suuda seda kõike testida
        
      • Ära testi rohkem koodi, kui sa oled võimeline seda installeerima
        
    • Väldi inimeste või ressursside ülekoormamist
      
    • Väldi ebaühtlast töökoormust
      
    • Väldi tegevusi, mis ei lisa väärtust
      
  • Minimal Marketable Feature (MMF)
    
    • Täielik toode mida saab kliendile esitada, isegi kui osa funktsionaalsusest on nn dummy-d ehk täieliku funktsionaalsust pole taga, kuid klient näeb ära kuidas asi peaks tulevikus välja nägema
      
    • Meil on vaja user storid teha nii, et need oleks hallatavad, üks variant selleks oleks see, et panna külge kindel eesmärk.
      
    • Näide:
      
      • 
        
      • 
        
• Scrumi kokkuvõte
  
  • Toote omanik paneb paika toote ajatelje
    
  • Interatsiooni planeerimise käigus toote omanik annab ette prioriteedid
    
  • Tiimil on aja kast kuhu tuleb mahtuda, et eesmärk täita: Iteratsioonid
    
  • Iga päev tiim mõõdab nende protsessi 15 min koosoleku käigus, ehk päevane Crum kohtumine
    
  • Kogu projekti jooksul projektijuht tagab, et tiim oleks fokuseeritud
    
  • Interatsiooni lõpus peab olema toode reaalselt saadetav, esitatav kliendile
    
  • Interatsioon lõppeb selle analüüsiga
    
  • Kogu projekti interatsiooni protsess on lõpetatud, kui kõik kasutuslood on realiseeritud või kui eelarve on kulutatud või isegi aeg läbi
    
• Kanbani võimalikud eelised Scrumi ees
  
  • Lihtsus!
    
  • Puudub suurte Backgide haldamine
    
  • Puudub „time boxing“ Sprint Backlogide jaoks
    
  • Puudub arendamise edukuse hindamine ja mõõtmine (st „puhtal“ Kanbanil)
    
  • EKSAMIL võib olla küsimus millegi nende võrdlemisega, kui sa suudad oma arvamust põhjendada siis see on ka õige vastus, valesid vastuseid pole sellisel juhul
    
• 
  
  • Kanban paneb piirid WIP töövoo staadiumis, kui aga Scrum piirab WIP-id mis on parasjagu töös ühes iteratsioonis
    
  • Scrumi puhul teeme me nn reserdi iga kord kui iteratsioon lõppeb, kuid Kanban-i puhul on töö on pidev ja reserdi ei toimu.
    
  • Scrumi puhul on meil tiimid, mille liikmed oskavad igat asja, kuid Kanbani puhul on spetsialiseeritud tiimi liikmed
    
  • Scrumi puhul interatsiooni osad peavad mahtuma täpselt interatsiooni, kuid Kanbani puhul võivad olla pikemalt aega nõudvad user storid, või selle kogumid, puudub time boxing
    
  • Kanbani päevased kohtumised fokuseerivad muutustele tahvlil, kui aga Scrum fokuseerib inimestele, ehk kaugel on inimesed, mis on nad ära teinud jne
    
  • Puhtas Kanban-is ei kasutada mõõdikuid, meetrikat, mida aga kasutab Scrum
    
• Muud agiilsed meetodikad
  
  • Lean Startup : rakendatakse startup-ide puhul, edu kriteerium on valideeritud õppimine, praktikas läbi proovitav, arendatakse toodet, mitte just tarkvara
    
  • Lean UX: kliendi poolt tajutav väärtus, mitte tingimata tarkvara.
    

Küsimused eksami kohta:

• Tarkvaraarenduse kolmnurga näide- ressurss, aeg, funktsionaalsus. Selgitada, probleemiülesande kontekstis. Nt. Aeg hakkab otsa saama- kas tuleb raha juurde küsida või ületunde teha vms
  
• Kvaliteetse tarkvara funktsionaalsed ja mittefunktsionaalsed atribuudid. 1 loengu teema. Vastuvõetavus, efektiivsus, kasutatavus jne.
  
• Metoodikad tarkvaraarenduses ja mida nad kirjeldavad. Mis on metoodika, miks on seda vaja. See on mingi kindel viis, mis on kindalt defineeritud tarkvarasüsteemide arendamiseks
  
• Erinevate tarkvarasüsteemide nõuete kirjeldamine. Näiteks panga veebi iseteeninduskeskkond, iPhone aplikatsioon jne. Nõuete vastavus nõuete kolmele olulisele omadusele.
  

Nõuete kolm olulist omadust: üheselt mõistetav, testitav ja lihtne

• Komponentidel, teenustel jne. põhinevad arhitektuuride positiivsed ja negatiivsed omadused, kasutusvaldkonnad. LEMMIK
  
• Mudeli olemus ja mudelite klassifitseerimine
  
• Tarkvarasüsteemi kvaliteediatribuutid nii lõppkasutaja, arendaja ja kui äri vaatenurgast. Igaühe mõju süsteemi arhitektuuriotsustele. EI PRUUGI TULLA
  
• Testitasemete (test levels) teooria ja erinevate tasemete kirjeldused. Ühiktestid, interatsioonitestid, kasutajtestid jne Jekaterina loeng
  
• Clean Code põhimõtted ja erinevatele reeglitele vastavus. Erik Jõgi loengus
  
• Tarkvara arendumetoodikate (XP, Scrumi, Kanban, jne) elemendid ja nende kirjeldused.