Tarkvaratehnika Software engineering

1. tarkvara

1.1. arvutiprogrammid + dokumentatsioon

1.2. Huvigrupid: *klient *arendaja *kasutaja

1.3. tarkvararakendused, liigid, näited

1.3.1. kohalikud stand alone rakendused

1.3.1.1. nt. Microsoft Office, Exel jne

1.3.2. pangarakendused, e-kaubandus

1.3.3. embedded control systems

1.3.3.1. nt. Mikrolaineahju kontrollivad süsteemid

1.3.4. Andmetöötlusrakendused

1.3.5. meelelahutusrakendused

1.3.5.1. mängud

1.3.6. modelleerimis-ja simulatsioonirakendused

1.3.7. andmekogumisrakendused

1.3.7.1. keskkonna kohta datat koguvad jpm

1.3.8. süsteemide süsteemid (systems of systems)

1.3.9. Tarkvaratoode

1.3.9.1. Arendamise käigus hangitud infotehnoloogia vahendid

1.3.9.1.1. riistvara

1.3.9.1.2. standardtarkvara

1.3.9.1.3. sideseadmed

1.3.9.2. Arenduse käigus tehtud töö

1.3.9.3. Muudatused tellija organisatsioonis

1.3.9.4. Tulemuste kasutamine ja edasi arendamine

1.3.9.5. Kasutajajuhendid

1.3.9.6. Õigused levitamiseks

1.3.9.7. Õigused arendamiseks

1.3.9.8. Vahendid, et hooldada

1.4. Tarkvara(Arendus)protsess

1.4.1. protsess

1.4.1.1. sammude jada

1.4.1.1.1. hõlmab tulemi loomiseks

1.4.1.2. tuleb eristada

1.4.1.2.1. protsessi raamistikke

1.4.2. Eesmärk:

1.4.2.1. tarkvara loomine

1.4.2.2. tarkvara haldamine

1.4.3. Üldistatud tegevused:

1.4.3.1. Spesifitseerimine

1.4.3.1.1. Mida peab süsteem tegema, ja mis on piirangud tema arendamisel?

1.4.3.2. Arendamine

1.4.3.2.1. tarkvarasüsteemi tootmine

1.4.3.3. Valideerimine

1.4.3.3.1. Kas toodetud tarkvarasüsteem on see, mida kasutaja soovis?

1.4.3.4. Evolutsioon

1.4.3.4.1. tarkvarasüsteemi muutmine vastavalt kasutajate muutuvatele nõudmistele

1.4.4. mudel

1.4.4.1. Tarkvara(arendus)protsessi mudel

1.4.4.1.1. protsessi lihtsustatud esitus teatud vaatepunktist

1.4.4.2. Tuleb eristada

1.4.4.2.1. Elutsüklimudeleid

1.4.5. Plaanipõhine

1.4.5.1. kõik tegevused on ette planeeritud ja edu kriteeriumiks on plaani järgimine

1.4.5.2. Kose mudel

1.4.5.2.1. Requirements->Design(kavandamine)->Implementation(realisatsioon)->Verification->Mainterance

1.4.5.2.2. Puudused

1.4.5.2.3. Eelised

1.4.5.2.4. Modifitseeritud kose mudel

1.4.6. Iteratiivne

1.4.6.1. Agiilne

1.4.6.1.1. planeerimine toimub sammude kaupa töö käigus

1.4.6.1.2. mingi osa kliendi juures live, kliendi tagasiside oluline. Testing/Evaluation koos kliendiga või kliendi keskkonnas

1.4.6.2. Initial Planning. Planeerimine -> Planning -> . Requirements.Nõuded -> Analysis & Design.Analüüs ja kavandamine -> Implementation.Realisatsioon Deployment -> <-Testing <-Evaluation *hindamine*

1.4.6.3. Eelised

1.4.6.3.1. Klient saab anda tagasisidet kogu tarkvaraprotsessi käigus

1.4.6.3.2. Klient kohe ja KOGUAEG saab anda tagasisidet ja seega lõpptulemit peab vähem ümber tegema ja saab täiustada

1.4.6.3.3. Klient saab hakata tarkvara varem kasutama, katsetada

1.4.6.3.4. Painduvus

1.4.6.3.5. Raha kokkuhoid Ei pea kogu protsessi läbima et teha ümber asju!

1.4.6.4. Puudused

1.4.6.4.1. Tarkvaraprotsess pole lõpuni dokumenteeritud, sest pidevad ümbertegemised

1.4.6.4.2. Võib ajakavast üle minna

1.4.6.4.3. Puudub struktuur, ei ole läbi nähtav mida lõpuks tehakse.

1.4.7. Komponendipõhine

1.4.7.1. Requirements specification(Nõudete täpsustustamine) -> Component analysis -> Requirements modification (Nõuete muutmine) ->System design with reuse(süsteemi kavandamine korduvkasutamisega) -> Development and integration(Arendus ja ) -> System Validation(ehk testimine)

1.4.7.1.1. komponentide analüüs

1.4.7.1.2. nõuete muutmine

1.4.7.2. Lähtumine valmis olevatest komponentidest ja saavutada nende kokkupanek, vähendades programmeerimistööd

1.4.7.3. Eelised

1.4.7.3.1. Koodi ei pea ise kirjutama, komponent teeb ära

1.4.7.3.2. Komponendid testitud - väiksemad riskid

1.4.7.3.3. Parem vastavus standarditele

1.4.7.4. Puudused

1.4.7.4.1. Päringud võtavad kaua aega, võivad võtta

1.4.7.4.2. Piiratud on võimalus, et hulk komponente ja viise, kuidas neid kokku panna.

1.4.7.4.3. suuremad hoolduskulud, komponent ei tee enam seda mida vaja.

1.4.7.4.4. Library ülalpidamiseks vaja eraldi süsteeme

1.4.7.4.5. Korduvkasutatavate komponentide leidmine, neist arusaamine ja nende kohandamine

1.4.7.5. Võib teha iteratiivselt kui ka planeeritult

1.4.7.6. Komponendid

1.4.7.6.1. Veebiteenused - APId

1.4.7.6.2. Library / Teegid

1.4.7.6.3. Kasutajaliides - GUI

1.4.7.6.4. Objektraamistikud

1.4.8. Kombinatsioon kõigist kolmest erinevast tarkvaraarendusprotsessist on kõige enam kasutusel olev protsessimudel l!

1.4.8.1. Puhtaid meetodeid on vähe!

1.4.8.2. Üks võib olla domineeriv, aga siiski võib olla segu.

1.5. Tarkvara arenduskulud

1.5.1. Mida vaja tarkvara tootmiseks algselt?

1.5.1.1. Nõuded Requirements Engineering Peavad olema testitavad!

1.5.1.1.1. Funktsionaalsed Functional

1.5.1.1.2. Mittefunktsionaalsed Non-Functual

1.5.1.1.3. Süsteemi Nõuded

1.5.1.1.4. Tarkvara Nõuded

1.5.1.1.5. Enne nõuete esitamist välja valitudolemas süsteemi domain/valdkonna mudel.

1.5.1.1.6. Esialgne definitsioon

1.5.1.1.7. Tarkvara 3 mõõdikut

1.5.1.1.8. Lausestus / statements

1.5.1.1.9. Nõuete dokument

1.5.1.1.10. Target Qualities

1.5.1.1.11. Role and stakes of RE

1.5.1.1.12. Meelde jätta

1.5.1.2. Disain(kavandamine)

1.5.1.3. Spesifikatsioonid

1.5.1.4. Programmikoodi

1.5.1.4.1. Testimine

1.5.2. Mida vaja tarkvara ülalhoiuks?

1.5.2.1. Evolutsioon

1.5.2.2. Hooldus

1.5.2.3. Palju kulukam.

1.5.3. Jaotumine

1.5.3.1. Mittekriitilised süsteemid

1.5.3.1.1. Nõuete analüüs/kavandamine (40) - Kodeerimine (20) - Testimine (40)

1.5.3.2. Kriitilised süsteemid

1.5.3.2.1. Nõuete analüüs/kavandamine (60) - Kodeerimine (20) - Testimine (20)

1.5.4. Töötajad

1.5.4.1. Tarkvarainsenerid

1.5.4.1.1. eetilised ja vastutustundlikud

1.6. Types of software products

1.6.1. Greenfield

1.6.2. Brownfield

1.6.3. Customer-driven

1.6.4. Market-driven

1.6.5. In house

1.6.6. Outsourced

1.6.7. Single product

1.6.8. Product line

2. -Business processes- -Application system- -Communications and data management- -Operating System-

2.1. -Organization- -Business processes- -Application system- -Communications and data management- -Operating System- -Equipment-

2.1.1. Süsteemitehnika System engineering

2.1.1.1. Sotsiotehniliste süsteemide

2.1.1.1.1. spesifitseerimine(täpsustamine)

2.1.1.1.2. kavandamine

2.1.1.1.3. realiseerimine

2.1.1.1.4. valideerimine

2.1.1.1.5. installeerimine

2.1.1.1.6. hooldamine

2.1.2. -Society- -Organization- -Business processes- -Application system- -Communications and data management- -Operating System- -Equipment-

2.1.2.1. Sotsio-tehniline süsteem

2.1.2.1.1. Süsteem

2.1.2.1.2. Tehnline süsteem + inimesed

2.1.2.1.3. Käitimusviisid, karakteristikud:

2.2. Tarkvaratehnika on osa laiemast sotsio-tehnilisest süsteemist!

3. Milleks

3.1. keeruliste süsteemide *loomiseks *haldamiseks

4. Eesmärk

4.1. olla kulueffektiivne terve kestvuse vältel

4.2. Organiseerida tegevusi, mis on vajalikud tarkvara toodete arendamiseks.

5. tehnika

6. Tarkvara kvaliteet

6.1. Toote vastavus nõuetele

6.1.1. Nõuded

6.1.2. Toode

6.1.3. Protsessid

6.2. Lõpptulemus sõltub kogu arendusprotsessist.

6.2.1. Standardid

6.2.2. Riistvara

6.2.3. Tarkvara arenduse meetodid ja vahendid

6.2.4. Projekti ja kvaliteedihaldus

6.2.5. Organisatsioonist

7. DISAINID

7.1. Funktsionaalne

7.1.1. Seosed süsteemi komponentide vahel

7.1.2. Juhivad FUNKTSIONAALSED NÕUDED

7.2. Arhidektuur

7.2.1. Vundament, millele tarkvara ehitatakse, aitab aru saada, kuidas süsteem töötab.

7.2.1.1. Arhidektuurne

7.2.1.1.1. defineeritakse tarkvara ja riistvara komponendid ja nende liidesed

7.2.1.1.2. et kujundada välja raamistik tarkvara arendamiseks

7.2.1.1.3. JUHIVAD MITTEFUNKTSIONAALSED NÕUDED

7.2.2. Klient-Server Arhidektuur

7.2.2.1. Kliendid suhtlevad läbi serveri

7.2.2.1.1. Peer 2 peer süsteem

7.2.2.1.2. kliendid omavahel ei suhtle otse

7.2.2.1.3. andmed viidud serverisse

7.2.2.1.4. kõrgem turvalisus ümber serveri

7.2.3. erosioon

7.2.3.1. Üks asi läheb siis hakkab kogu asi logisema

7.2.3.2. arhidektuuri mitteteadlik lõhkumine

7.2.4. Control Model View

7.2.5. Oluline sest hiljem lihtsam süsteemi arendada.

7.2.6. Komponentidel põhinev arhidektuur

7.2.6.1. Süsteem jaotatud komponentideks ja igal komponentil on ülesanne

7.2.6.1.1. komponente saab muuta

7.2.6.1.2. KAPSELDATUD

7.2.7. Kihiline arhidektuur

7.2.7.1. Enterprisis kõige enam kasutatud

7.2.7.1.1. Iga kiht teeb oma ülesannetega, üks ülesanne

7.2.8. EI ASENDA TEINETEIST VAID SAAB VAHETADA. Näiteks kihtideks ja siis komponentideks.

7.2.9. Enterprise Service Message Bus

7.2.9.1. Kiht kus terve suhtlus läbi käib.

7.2.9.1.1. X-tee

7.2.9.2. Rakendused suhtlevad

7.2.9.3. Et ei peaks iga rakendust ümber ehitama, mis tahab millegiga suhelda tahab

7.2.9.4. Kuidas andmeid konverditakse ühest keelest teise.

7.2.9.5. Skaleeritav? laiendatav

7.2.9.6. Aplikatsioonid muutuvad lihtsamaks

7.2.9.7. eesti riigi infosüsteemi arhidektuur

7.2.10. N-tier

7.2.10.1. Mitmekihiline arhidektuur, aga kihid on RIISTVARAS

7.2.10.1.1. Application kiht

7.2.10.1.2. Session kiht

7.2.10.2. Erinevates masinates füüsiliselt

7.2.10.3. Hallatavus

7.2.10.4. Painlik ja kättesaadav

7.2.10.5. Skaleeritav - laiendatav.

7.2.10.6. Rakendus paralleelselt mitmes arvutis tööle

7.2.11. ObjektOrieneeritud Arhidektuur

7.2.11.1. Objektil ülesanne, laiendamine, sidumine

7.2.11.2. abstraktseid objekte, kombineerida, pärida, laiendada, kapseldada funktsionaalsust, polümorfism

7.2.11.3. kasu on arusaadavus

7.2.11.4. taaskasutatavus

7.2.11.5. testitavus

7.2.11.6. Domain Driven Design

7.2.11.6.1. räägitakse domeenikeeles ehk ärikeeles

7.2.11.6.2. äriliselt mõistetav

7.2.11.6.3. samad kasud mis OOP

7.2.12. Teenus-Orienteeritud arhidektuur

7.2.12.1. rakendused suhtlevad omavahel, bus polnud vahel vaid iga rakendus suhtleski omavahel.

7.2.12.2. lepiti kokku rakenduste vahel leping, kuidas suhelda, mis andmestruktuure kasutada

7.2.12.2.1. vastavalt lepingule suheldi

7.2.12.3. autonoomne ehk iga teenus iseseisev

7.2.12.3.1. saab iseseisvalt tetida

7.2.12.4. nõrgalt seotud

7.2.12.5. jagatakse lepinguid ja skeeme, mitte sisemisii klasse

7.2.12.6. abstraktsus

7.2.12.7. leitavus

7.2.12.7.1. iga süsteem vastutab oma osa eest ja see on teada kus ta asub

7.2.12.8. erinevad platvormid

7.2.12.8.1. tehnoloogiline stack ületatud

7.2.12.9. ratsionaalsus

7.2.12.10. Mikroteenused

7.2.12.10.1. Sarnane TOA'le

7.2.12.10.2. Väikesed rakendused/teenused

7.2.12.10.3. suhtlemine üle teenuste

7.2.12.10.4. Kui rakendusse tuuakse uus komponent tehakse see iseseivaks ja saab kasutada teistsugust tehnoloogilist stackki.

7.2.13. Monoliitne arhidektuur

7.2.13.1. Lahutatud komponente pole

7.2.13.2. üks suur rakendus ja serveriga ühendatud

7.2.13.3. lihtsamad süsteemide puhul väga hea

7.2.13.4. tavaline hello world

7.2.14. Arhidektuuri disainimine

7.2.14.1. Milline osa muutub arhidektuurist kõige rohkem, selle järgi saab valida, mis arhidektuuri valida.

7.2.14.2. ei tasu üle inseneerida ja ei tasu teha eeldusi, küsida kliendilt.

7.2.14.3. Mis on arhidektuuri fundamentaalsed osad ja mille valesti tegemised on suur roll läbikukkumisele

7.2.14.4. millised osad võib edasi lükata

7.2.14.4.1. info saamisega kaasas käimine

7.2.15. Modelleerima arhidektuuri

7.2.15.1. Püüa disainist lähtuvalt arhidektuur realiseerida

7.2.16. Haldab keerukust, mõeldud inimestele