31.01.2017

ÕSSS

Vestlus oli.

30.01.2017: tarkvara arendusprotsess x2 (Väino L.), veebirakenduste loomise alused (eesti keel) x2 (Aire I.)

Väino tunnis tegin UML kasutuslugu õpperestoran Neljapäev jaoks loodava veebikeskkonnale. Eesti keele tunnis tegime õigkirjaharjutusi.

27.01.2017: programmeerimine x2 (Marko L.)

Jätkasime veebilehe tegemisega õpperestoran Neljapäev jaoks. Ei saanud valmis.

26.01.2017: hajusrakenduste alused x4 (Ain E.)

Enne lõunat tegi iga õpilane lühikese esitluse ühest tarkvarametoodikatega seotud luhendist. Ma tegin REST'ist. Ei saanud ikkagi lõpuks aru, mida see tähendab. Peale lõunat tegime kasutusjuhendit. Kasutusjuhend oli sisselogimisprogrammi kohta, mille me tegime eelmina aasta ühes Aini tunnis.

Mida õppisin: midagi ikka.

25.01.2017: tarkvara arendusprotsess x2 (Väino L.), vene keel x2 (Tatjana P.)

Cleanroom SE- "puhta toa" tarkvaraarendus
luua tarkvara sertifitseeritud usaldustasemega
on üles ehitatud vigade vältimisele

Kesksed põhimõtted
  1)tarkvaraarendus põhineb formaalsel matemaatikal, mis sisaldab mudelite kontrolli ja protsessi algebrat, Petri-võrku
  2)Statistiline kvaliteedi kontroll
  3)statistiliselt mõttekas kontroll

TSP- meeskonna tarkvaraprotsess
KLOC- kilorida koodi (1000 rida)
  1)plaanimise protsess
  2)PSP- personal software process
  3)ajaraamistiku hindamine
  4)meeskonna töö planeerimine
CMMI- võimekuste küpsuse mudel
  1)level 1: Algne- protsess on ettearvamatu
  2)level 2: Hallatud- protsessi viiakse projektidena läbi
  3)level 3: Määratletud- protsess on proaktiivne, sekkutakse kui vaja
  4)level 4: Kvantitatiivselt hallatud- protsesse mõõdetakse ja juhitakse
  5)level 5: Optimeeritud- fookus on protsessi parendamisel

PSP ülesanded:
  1)paranda planeerimise, kavandamise ning hindamise oskust
  2)panusta meeskonnatöösse
  3)halda projektide kvaliteeti
  4)vähenda oma vigu

PSP
  1)skriptid
    a)suurus
    b)jõupingutus
    c)kvaliteet
    d)ajakava
  2)mõõtmised
  3)standardid

MSF aluspõhimõtted
  1)avatud suhtluse edendamine
  2)ühise nägemuse poole koos töötamine
  3)meeskonnaliikmete toeatamine
  4)jagatud vastutus
  5)äriväärtuse kliendile pakkumise vastutus
  6)oota muudatusi ning ole agiilne
  7)investeeri kvaliteeti
  8)õpi oma kõikidest kogemustest
  9)ole kliendile partner

PUP (Phases of unified process)
1)inception(algatus)
2)väljatöötamine (elaboration)
3)construction (koodiuhamine)
4)transition (väljalase)

UP (unified process) tegevust
  1)ärimodelleerimine (ärireeglid)
  2)nõuded (SRS)
  3)analüüs ja disain (SDD)
  4)implementation (kood)
  5)test (STD)
  6)deployment (skriptid)
  7)config. and change management (skriptid)
  8)projektihaldus (SPMD)
  9)keskkond (EUP)

Agule Unified Process (AUP)
Basic --- (BUP)
Enterprise --- (EUP)
Essential --- (EssUP)
Open --- (OpenUP)
Rational --- (RUP)
Oracle Unified Method (OUM)

Test-driven development
  1)lisa test
  2)tee kõik testid läbi ning vaata kas test põrus läbi
  3)kirjuta koodi
  4)jooksuta teste
  5)paranda koodi

ATDD (acceptance test-driven development) - klient testib rakendust

DDD (domain-dirven design)- domeenipõhine disain / keskkonnast lähtuv disain / tegevusvaldkonnast lähtuv disain

FDD - valdkonna parimad praktikad kõik koos
BDD - kasutab valdkonnapõhist arendust

24.01.2017: tarkvara arendusprotsess x4 (Väino L.)

Tarkvara prototüüpimine on mittelõplike tarkvaraprogrammi versioonide loomine.

Prototüüpimise variandid:
äravisatav:
    1)kirjuta algelised nõuded
    2)disainimine
    3)prototüübi kasutamine annab uusi nõudeid
    4)kordab kui vaja
    5)kirjutab lõplikud nõuded

arenguline prototüüpimine:
    peamine eesmärk on ehitada on ehitada jäme prototüüp ning hakata seda täpsustama

inkrementaalne prototüüpimine:
eraldiseisvad prototüübid pannakse kokku lõpptooteks

ekstreemne prototüüpimine:
jaotatakse faasideks,
esimeses faasis koosneb veebirakendus peamiselt html failidest;
teises faasis luuakse kasutajaliides ning aknad;
kolmandas faasis luuakse teenused;


eelised: 
    1)hoiab kokku aega ja raha
    2)parendatud ja suurendatud kasutajate kaasatus

puudused:
    1)ebapiisav analüüs
    2)kasutajade segadus prototüübi ning lõpliku süsteemi osas
    3)kasutaja eesmärkide arendajapoolne mittemõistmine
    4)arendaja kiindumus prototüübile
    5)prototüübile liiga palju aega raisatud
    6)prototüübi liiga kõrge maksumus

DSDM: dünaamiline süsteemiarendusmeetod

Põhitehnika on prototüüpimine
ISO 9001
Prototüüp võib olla skeem, äriprotsess või tootmisse lülitatud süsteem

need prototüübid võivad olla äravisatavad või arenevad.

Neli prototüüpi:
  1)äriprototüübid
  2)kasutatavuse prototüübid (UI)
  3)jõudluse ja mittefunktsionaalsete nõuete osatähtsus
 

  1)tuvasta prototüüp
  2)lepi kokku plaani suhtes
  3)loo prototüüp
  4)vaata prototüüp üle

Neljanda gen. progemiskeelte liigid
  1)koodita programmeerimine

SOAP (simple object access protocol)
WSDL (web service description language)
DSDM - dünaamiline süsteemiarendusmeetod

DSDM põhitehnikad:

Timeboxing: projekt jaotatakse juppideks ning iga jupp saab etteantud tähtajaks valmis
MoSCoW: must have, should have, could have,  won't have
Prototüüpimine
Testimine
Töötoad
Modeleerimine
Seadistuste haldus

teostatavuse variandid:
1)tehniline
2)juriidiline
3)ajaline

http://wp1087322.server-he.de/ ->Developer

Inkrementaalne arendusmudel

eelised:
    1)peale iga iteratsiooni tuleb teha regressioonitest
    2)lihtsam testida ja vigu leida kui teiste meetoditega, sest iga iteratsiooniga tehakse vähe muudatusi
    3)klient saab reageerida muudatustele
    4)algse toote kliendile tarnimine on kiirem ja maksab vähem

puudused
    1)eelarve võib lõhki minna
    2)lisafunktsioonide korral võivad tekkida süsteemivead

V-mudel

Tarkvara arhitektuur

Spiraalmudel: riskipõhine protsessimudel

Määratle tehised samaaegselt
eeldused:
  1)nõuded olemas enne koodi kirjutamist
  2)nõuded ei sisalda kõrge risti faktoreid
  3)nõuete olemus ei muutu väga palju arenduse käigus
  4)nõuded on kooskõlas kõigi süsteemi kasutajatega
  5)süs. arhit. on kõigi poolt arusaadav
  6)aega on piisavalt


neli põhitegevust igas tsüklis

  1)arvesta võidutingimustega
  2)tuvasta ja hinda alternatiivlähenemisi
  3)tuvasta ja lahenda riskid
  4)saa huvigruppide heakskiit

vesrtapostid
  1)elutsükli ülesanded
  2)elutsükli arhitektuur
  3)algne töövõimekus

23.01.2017: programmeerimine x3 (Marko L)

Alustasime veebilehe loomisega õpperestoran Neljapäev jaoks. Meile jaotati ülesanded. Mina pean tegema menüü poolt. Pidin koos Marekuga tegema aga ta ei olnud kohal. Bert on projektijuht.
Ei saanud valmis.

Mida õppisin: midagi ikka.

20.01.2017: tarkvara arendusprotsess x2 (Väino L.)

Kasutajad ja spetsifitseerimine

Üks tagumik-tund võtab 500 kJ (120 kCal).
Tagumiktunni energiakulu taastamiseks tuleb süüa 2 burgerit.

19.01.2017: programmeerimine x2 (Marko L.), tarkvara arendusprotsess x2 (Väino L.)

Marko tunnis tegime tööd PowerShell'iga. Tegime skripti, mis kirjutas kuni 9999 faili ning kirjutas igasse faili ühe rea. Siis kirjutas kõikide failide sisud ühte faili. Teeb töölauale ka kausta, kuhu kõik failid lähevad. Kausta nimi on skriptis ette antud. Kui töölaual on sellise nimega kaust olemas, kustutab selle sisu. Näitab ka kui kaua kogu töö tegemiseks läheb.


Tarkvara arendusprotsess

Kasutusloo mall
Kasutusjuhtumi nimi
Kirjeldus:

käsutaja(d):
  Sündmuste jada:
  Põhisündmused:
    Sündmus 1
    Sündmus 2
    .................
    Sündmus n
  Alternatiivsed sündmused:
    Sündmus 1
    Sündmus 2
    ..................
________________
Eeltingimused
Järeltingimused

http://dspace.ut.ee/bitstream/handle/10062/41862/peedo_marco.pdf

joongraafik- Gantt Chart

Tarkvara projekti näide

Mida õppisin: kuidas natuke PowerShell'i kasutada.

18.01.2017: programmeerimine x2 (Marko L.), andmebaasirakenduste arendaja x2 (Tatjana P.)

Marko tundides me ei teinud midagi. Tatjana tunnis õppisime vene keelt.

Mida õppisin: vene keeles enda tutvustamine (algeline).

17.01.2017: veebirakenduste loomise alused x4 (Triin M.), veebirakenduste loomise alused x1 (Aire I.)

Triinu tunnis tegime alguses mingit veebilehte. Hiljem hakkasime tegema peamajja telekate jaoks Xibo'ga informatiivset GUI'd. Seal näitab hetke tunde, ilmateadet, uudiste RSS feed'i, ning kooli Facebook'i. Facebooki ei näidanud see telekas. Keskkond, millega ehitasime seda GUI'd, oli lihtne kasutada.

Mida õppisin: kuidas Xibo't vähesel määral kasutada.

16.01.2017: veebirakenduste loomise alused x3 (Triin M.)

Pidime täitma ülesandeid lehel https://google-gruyere.appspot.com/. Pidime  õpetuse järgi turvaauke leidma ning nendega kurja teha. Üks ülesanne oli teha sellel lehel omale konto ning tavakasutajast admini tegema. Siis tuli üles laadida html fail skriptiga, et saada teada küpsiste formaat. Tuli ka välja uurida teiste kasutajate privaatinfot. Üks ülesannetest oli ka leida üles fail nimega "secret.txt".

Mida õppisin: ei oska öelda

13.01.2017

Aivari tunnid jäid ära kuna teda ei tulnud.

12.01.2017: tarkvara arendusprotsess x4 (Väino L.)

Tarkvara disain:
protsess, kus agent loob tarkvaratehise spetsifikatsiooni, kasutades algseid komponente

1)Algoritmi disain

Algoritmid:
1)probleemi määraimine

Jada liikmed käivad loogeliste sulgude vahele

CASE vahendid: Eclipse, NetBeans
CASE: tööriistade valdkond, mida kasutatakse tarkvara loomiseks ja disainimiseks

CASE kolm gruppi:
1)Tööriistad
2)Tööpingid
3)Keskkonnad

Tööriistad:
1)Äri ning analüüsi modelleerimine
2)Arendus, debuggerid
3)Verifitseerimine ning valideerimine; koodi analüsaatorid
4)Seadistuste haldus
5)mõõtmine; koodi analüsaatorid koodi keerukuse suhtes
6)projektijuhtimine

Tööpingid: 
integreerivad kaks või rohkem CASE tööriista

Fundamentaalsed modelleerimis kontseptid (FMC)
1)süsteemi struktuur
2)protsess süsteemis
3)domeeniväärtused süsteemis

*Liitstruktuuri skeem ehk FMC plokk-skeem
*Dünaamilise struktuuri skeem ehk FMC Petri-net
*Väärtuste raadiuse struktuuri skeem ehk FMC E/R skeem

FMC plokkskeem
Pilt (see link siin eelmisel real) on liitstruktuuri skeemi näide. Selles on agendid tellimuse protsessor (Order Processor), tarnija haldur (Supplier Manager) , tarnija (Supplier), veebipood (Online Shop), ning nimetu inimagent (Human Agent)

DAVIS 
1)disainiprotsess ei tohiks kannatada "silmaklappidest", peaks proovima erinevaid lähenemisi
2)disain peaks olema seotud ning jälitatav
3)ära leiuta jalgratast
4)disain peaks näima ühtlane,
5)peaks olema struktuurne ning peaks võimaldama muutuste sisseviimist
6)peaks olema disainitud nii, et suudaks ootamatustele vastata
7)disain pole koodimine, koodimine pole disain
8)peaks hindama disaini kvaliteetsust
9)disaini peab üle vaatama, et minimiseerida põhimõttelisi vigu

Disaini põhimõtted
1)abstraktsioon - üldistamine
2)viimistlemine/täpsustamine:
3)modulaarsus- tarkvara arhitektuur võiks olla jaotatud komponentideks
4)Tarkavara arhitektuur
5)Juhtimise hirearhia
6)jaotiste ülesehitus- programmi ülesehitus tuleks jagada horisontaalselt ning vertikaalselt juppideks
7)Andmestruktuur
8)Tarkvaraprotseduur
9)Polümorfism

Disaini kaalutlused
1)ühilduvus: tarkvara peab töötama teiste toodetega koos
2)laiendatavus: võimalus lisada uusi võimekusi
3)modulaarsus
4)hooldatavus
5)taaskasutatav
6)robustne
7)turvalisus
8)kasutatavus
9)jõudlus: asi ei tohi venima jääda
10)porditavus
11)mastaapsus

Arhitektuuri kirjeldamise keel
https://github.com/osate

camunda.org/bpmn/tutorial/

https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation#Overview

EEML

Vooskeem

IDEF: modelleerimiskeelte perekond

Jackson

LePUS3: kuulub objekt-orienteeritud programmeerimiskeelte hulka

Alloy: on loodud keeruliste struktuursete piirangute kirjeldamiseks (uuri Alloy'd!)

Service-oriented modeling framework (SOMF)

hirmus UI
Disaini mustrid 

11.01.2017: Tarkvara arendusprotsess x2 (Väino L.), andmebaasirakenduste arendaja x2 (Tatjana P.)

Nõuete esilekutsumine:
sisaldab intervjuusid, küsimustikke, kasutaja vaatlusi, töötubasid, ajurünnakuid, kasutajalugusid, rollimänge ning prototüüpimine.

Enne kui nõudeid saab analüüsida, modelleerida või spetsifitseerida, tuleb neid koguda esilekutsumise protsessiga.

Süsteemi modelleerimis keeli on mitmesugused.

Tavaline esilekutsumisprotsess on huvigruppidega kohtumine või intervjuud. Nt esimene tähtis kohtumine oleks tarkvara arendajate ning klientide kus nad arutavad nõuete perspektiivi.

Probleemid:
1)Probleemide ulatus: ei tasu kliente terminoloogiaga segadusse ajada
2)Mõistmise probleem: kliendid ei ole kindlad, mida vaja, ei tea arvutite suutlikkust, ei suuda selgitada
3)Muutumise probleem: nõuded muutuvad ajaga.

Nõuete kvaliteedi parandamine:
1)visualiseerimine
2)kooskõlaline keel: kasuta lihtsat/loomulikku keelt nõuete kirjeldamiseks
3)reeglid: järgi ettevõttes väljakujunenud reegleid.
4)pidev mallide kasutamine
5)dokumenteerimise sõltuvused
6)muudatuste analüüs

Nõuete esiletoomise juhised:
1)hinda süsteemi ärilist ning tehnilist teostatavust
2)inimeste, kes võiksid nõuete väljaselgitamist aidata, leidmine
3)määratle tehniline keskkond, nt op-süsteem
4)tuvasta tegevusvaldkonna piirangud
5)määratle rohkem kui üks esiletõstmismeetod
6)korralda erinevate huvigruppidega kohtumisi
7)tuvasta tähtsaimad nõuded, mida on vaja prototüübi loomised
8)loo kasutuslood, et aidata klientidel tuvastada võtmenõudmisi

Sammude järjekord:
1)tuvasta reaalne probleem, võimalus või väljakutse
2)tuvasta jooksvad meetmed, mis tõestavad, et probleem on reaalne
3)tuvasta eesmärk-meetmed et tõestada probleemi olemasolu
4)tuvasta probleem olemus
5)määratle ärivaldkonna "miksid"
6)määratle tootedisain

Täiendavad lähenemised:
1)tuvasta huvigrupid
2)modelleerimise eesmärgid
3)modelleerimise kontekst
4)stsenaariumite avastamine (kasutuslugude jaoks)
5)kvaliteetide ning piirangute avastamine
6)eelduste ja kirjapaneku modelleerimine
7)sõnastiku kirjutamine
8)mõõtmete analüüsimine
9)

Analüüs:
võtame arvesse kõik vastuolud mida proovib nõuete kirjapanekul lahendada

Huvigrupid:
1)ükskõik, kes tegelevad süsteemiga (tavakasutajad ning hooldajad)
2)igaüks, kes saavad süsteemist tulu
3)igaüks, kes ostits süsteemi
4)ettevõtted, mis reguleerivad süsteemi aspekte
5)inimesed või ettevõtted kes on selle süsteemi vastu
6)ettevõtted, mis vastutavad teatud süsteemiliidese eest

Läbivad funktsionaalsused

Lepingu-stiilis nõuete loetelud
CIA: konfiguratsioon, tervikus, kättesaadavus

Kohustuslik kirjandus: "Tarkvaratehnika sissejuhatus 2008"

SRS on suhtlusvahend huvigruppide ning tarkvaraarendajate vahel

SRS eesmärgid:
1)aluseks koodiülevaatustele
2)tööulatuse kirjeldamine
3)tarvaradisaineritele annab viite
4)aluseks testimisele, testidokumendile (testiraamistik)
5)sisaldab iseärasusui kliendi nõuetega
6)on platvormiks edasiseks arenduseks

Uuri FreeMind'i

Tatjana tunnis õppisime vene keelt ning tegime harjutusi.

Mida õppisin: kes on huvigrupid.

10.01.2017: veebirakenduste loomise alused x4 (Jaan P.)

Esmaspäeval toodi kooli uued arvutid. Neil olid osadel BIOS lukus. Pidime BIOS luku deaktiveerima. Peale seda pidime paigaldama nendele arvutitele Windows 7. Win 7 Pro 4GB RAM'iga arvutile. Win 7 Home 2 GB RAM'iga arvutile. Ühele arvutile paigaldati Kodi MediaCenter.

Mida õppisin: kuidas BIOS lukku eemaldada.

9.01.2017: Tarkvara arendusprotsess x2 (Väino L.), veebirakenduste loomise alused x1 (Aire I.)

Tarkvaraarendus on:

1)teaduslike ja tehnoloogiliste teadmiste ja meetodite süstemaatiline rakendamine;
2)süstemaatiline, distsiplineeritud ja oluline lähenemine tarkvara arendamisele ja haldamisele;
3)kindlate arendusmeetodite rajamine ning kasutamine, et ekonoomiliselt saada tarkvara, mis on usaldusväärne ning töötab päris masinates

Nelja P meetod: product (toode), valitud meetod, people (inimested kes realiseerivad), project (projekt)

COCOMO (Constructive Cost Model)- tarkvara arendamise panus programmile, mees-aastates T, lähtekoodi ridadeni (SLOC- source lines of code). T = k*SLOC^(1+x)

Tarkvaranõuded: väli tarkvara arenduses mis tegeleb huvigruppide nõuete täitmisega.
Nõuded
1)Tingimus või võimekus mida kasutaja vajab, et lahendada probleeme või eesmärke saavutada.
2)Tingimus või võimekus millele süsteem peab vastama, standard, spetsifikatsioon
3)punktide 1 või kahe dokumenteeritud esitlus

SRS osad (SRS malli leiab siit):

(PS: osasid asju aru ei saanud, sisukord on kaos)
1)projekti muudatuste ajalugu

2)dokumendi heakskinnitajad

3)sisukord
   1)Sissejuhatus
     a)eesmärk
     b)ulatus
     c)definitsioonid, akronüümid. lühendid
     d)viited
     e)ülevaade
   2)
   3)Nõuded
      a)Välise liidese nõuded
         1)Kasutajaliidesed
         2)Riistvaraliidesed
         3)tarkvaralised liidesed
      b)Funktsionaalsed nõuded
      c)
      d)klassid/objektid
   5)Mittefunktsionaalsed nõudued (link dokumendile ria.ee's)
       1)jõudlus
       2)portimine
     f)Pöörded
     g)disainipiirangud
Andmeobjekt Register sisu ja piirangud:
  1)Sissejuhatus
  2)Sisendid
  3)Andmete töötlemine
  4)Väljundid
  5)Veakäitlus

Aire tunnis tegime arvsõnade käänamise harjutusi.

Mida õppisin: mis on nelja P meetod.