Süsteemiarenduse elutsükkel (0)

Kutsekool - Informaatika - Tarkvaratehnika

5 VÄGA HEA

Elu - Luuletused, mis räägivad elus olemisest, kuid ka elust pärast surma ja enne sündi.

Tallinna Polütehnikum
It- Telekommunikatsioon
Süsteemiarenduse elutsükkel
Referaat
Noorem Tarkvaraarendaja
Rasmus Karm
Ta-17E
Juhendaja : Kaupo Nõlvak
Tallinn 2017

Sisukord

1. Elutsükli üldised mudelid 3
2. Koskmudel 5
Kokkuvõte: 7
3. Inkrementaalne arendusmudel 8
Inkrementaalse arenduse eelised: 11
Inkrementaalse arendused probleemid: 11
4.Agiilsed arendusmeetodid 12
5.Spiraalmudel 14
6. Prototüüpimine 16
Prototüüpimise etapid on järgmised: 17
Ühekordse prototüüpimise põhimõtted on järgmised: 17
7. Dokumentatsioon 18
8.Viited 21

Elutsükli üldised mudelid

Süsteemiarenduse elutsükli mudel on arendusprotsessi üldistatud ( abstraktne ) kirjeldus. See on protsessi kirjeldus teatud vaatenurgast lähtudes. Protsessimudelite kirjeldustes räägitakse tavaliselt tegevustest nagu andmemudeli kavandamine, kasutajaliidese disain jne, kuid nad võivad sisaldada ka dokumentatsiooni ja rollide kirjeldusi.
Protsessimudelites võib kohata kahte põhimõttelist lähenemist.
Tugev planeerimine . See vanem lähenemine seisneb tegevuste ja tarkvara põhjalikus planeerimises ja järgnevas kindlalt plaani järgivas arenduses. Arendustegevuse progressi mõõdetakse sama plaani abil.
Agiilne ehk paindlik arendus, kus planeerimine toimub osade kaupa (inkrementaalselt) ning tänu millele on võimalik protsessi käiku muuta, tulles vastu kasutajate muutuvatele nõuetele. Paindliku protsessi kasutuselevõtt tulenes klientide vajaduste kiirest muutumisest. Protsess peab olema paindlik ja suutma reageerida toote muutmise, täiendamise ja kohandamise soovidele.
Kui vahepeal toimus süsteemi üldiste arendusmudelite jaotamine rangelt ühte või teise kategooriasse, siis praegu leiab Ian Sommerville, et üldisel tasemel ei ole range jaotus otstarbekas ja nii mõnegi mudeli järgi on võimalik panna käima nii agiilne kui planeeritud arendusmeetod.
Läbi ajaloo on pakutud mitmeid üldisi süsteemiarenduse mudeleid ja olulisemad neist on:
1) koskmudel ( waterfall model);
2) spiraalmudel (spiral model);
3) inkrementaalmudel ( incremental model);
4) prototüüpimine (prototyping).
Järgnevalt käsitleme eelpoolnimetatud süsteemiarenduse mudeleid lähemalt.

Koskmudel

Koskmudel (ka klassikaline mudel) on esimene kirjeldatud tarkvarasüsteemi elutsükli mudel, mis lähtus tavalistest tootmisprotsessidest ehituses, mehhaanikas vms. Mudeli kirjeldas Winston W. Royce 1970. aastal. Koskmudel on kõige vanem ja kõige rohkem kritiseeritud protsessimudel
Põhiidee kohaselt jagatakse tegevused nii, et iga tegevus toimub jadamisi eraldi etapina . Royce jagas protsessi järgmisteks põhietappideks (tasub tähele panna, et etappide nimekiri varieerub erinevate autorite esituses):
1. Nõuete määratlemine. See etapp võib olla ka jaotatud kaheks - süsteemi analüüs (kõik see, mis konkreetset tarkvara ümbritseb) ja nõuete analüüs. Dokumenteeritakse süsteemi käitumine, jõudlus, liides jne
2. Süsteemi Ja Tarkvara Kavandamine. Keskendub Põhilistele Programmi Omadustele Nagu Andmestruktuurid , Tarkvara Arhitektuur , Liideste Omadused Ja Protseduurilised Ning Algoritmilised Detailid. Projekti Kvaliteeti On Võimalik Hinnata. Tulemus Dokumenteeritakse.
3. Teostus ja moodulite testimine . Projektis kirjeldatud süsteem programmeeritakse moodulite ja programmide kogumina ja need testitakse eraldi. Mida detailsem on projekt, seda lihtsam ja mehhaanilisem saab olla teostuse etapp.
4. Integratsioon ja süsteemi testimine. - programmid ja moodulid integreeritakse ning testitakse kogu süsteemi, peale testimist antakse toode kliendile. Testimisel keskendutakse nii loogilistele detailidele kui ka sellele, kas süsteem oma funktsionaalsuse osas nõudeid täidab ( valideerimine ).
5. Kasutamine ja hooldus - on tavaliselt kõige pikem faas. Süsteemi muudetakse, kui kasutajad avastavad vigu, ümbrus ja töökeskkond muutuvad või klient vajab uut funktsionaalsust. Faas kordab kõiki eelnevaid faase olemasoleva süsteemi muutmise raames.
Iga faasi tulemiks on üks või mitu dokumenti, mis kinnitatakse. Järgmine faas ei tohiks alata enne, kui eelmine on lõpetatud . Faasidel on teatav ülekate ja info edastamine ühest teise. Vt ka joonist 1.
Joonis 1-1. Koskmudel

Kommentaariks joonis 1 juurde - tihti joonistatakse koskmudeli loogikat nii, et on vaid ülalt allapoole (eelmisest faasist järgmisesse) suunduvad nooled. Eelnevate sammude juurde tagasi ei pöörduta, samuti nagu majaehitusel ei pöörduta tagasi vundamendi juurde peale katuse paigaldamist. Sel juhul oleks mudeli kohaselt üldse võimatu midagi süsteemis hiljem muuta. Sellist varianti pidas ka Royce oma artiklis võimatuks. Royce lisas tegelikult juba alguses iga etapi kohta tagasisidet kujutava noole . Siiski ei ole tagasipöördumine igast etapist eelmisesse võimalik. Kui testimise käigus avastatakse viga, mille juured on arhitektuuris, siis koskmudeli kohaselt saab pöörduda tagasi arhitektuuri muutmise juurde alles siis, kui tarkvara on kasutusse läinud (vt noolte suundi joonisel).

Kokkuvõte:

Otsused süsteemi kohta tehakse varajases faasis ja süsteem ei pruugi lõpuks teha seda, mida kasutaja tahab (nõuded on varakult külmutatud) Samas ei tea ka klient alguses, mida ta tahab ja tema ebakindlus on täiesti loomulik.
Projekti range jaotus faasideks ei luba kliendi muutunud nõuetele kergelt vastu tulla. Seega on mudel kasutatav siis, kui nõuded on selged ja nad muutuvad vähe.
Koskmudel on sobilik suurtele süsteemidele, mida arendatakse mitmes erinevas kohas korraga. Sel juhul lubab eelnev korralik planeerimine töid paremini koordineerida

Inkrementaalne arendusmudel

Tarkvaraarenduse üks võtmeküsimusi on - kuidas tulla toime muudatustega, sest suurte tarkvaraprojektide puhul on muutused vältimatud. Äritegevus muutub ja see toob endaga kaasa muutunud nõuded, tekivad uued tehnoloogiad, mida oleks otstarbekas tarkvarasüsteemides nende täiustamiseks rakendada ning muutuvad platvormid, millele süsteem on rajatud. Nimetatud muutused nõuavad ümbertegemist ning maksab nii nõuete korduv analüüsimine koos teostusega kui ka uute funktsionaalsuste realiseerimine . Muudatuste maksumust tuleb hoida nii väiksena kui võimalik. Seega tuleb arendusprotsessi tuua sisse tegevused, mis aitavad muudatusi ette näha enne kui nende sisseviimine olulist tööd nõuab. Näiteks prototüüpimise abil saab kliendile näidata varakult süsteemi olulisi omadusi. Muudatusi on parem teha siis, kui nende sisseviimine on võimalikult odav. Sellest tulenevalt on mõistlik toote järk-järguline (inkrementaalne) arendus ja üleandmine . Nii saab muudatusi teha ka nendes osades, mida pole veel arendama asutud.
Mõistelist segadust tekitavad iteratiivne ja inkrementaalne arendus. Alistair Cockburni järgi on tegemist kahe erineva arendusmudeliga:
Inkrementaalne arendus on etapiviisiline ja ajagraafikut järgiv strateegia, kus süsteemi erinevaid osi arendatakse erinevatel aegadel ja erineva kiirusega ning kui üks osa valmis saab, integreeritakse see juba valmis süsteemiga.
Alternatiivne strateegia oleks kodeerida kõik süsteemi osad ja siis kogu kood integreerida ühekorraga.
Iteratiivne arendus on nö muutmisstrateegia, kus nähakse ette olemasolevate süsteemi osade ümbertegemine ja parandamine. Alternatiivne strateegia oleks planeerida tegevused selliselt , et kõik tehtaks õigesti esimesel katsel
Ian Sommerville järgi on iteratiivne arendusmudel pigem üldine nimetus mitmele nn hübriidmudelile (sh inkrementaal- ja spiraalmudel). Sõna "iteratiivne" rõhutab seda, et tegevused selles mudelis korduvad.
Sõltumata tähendusest, mis pannakse iteratiivse arenduse taha, on inkrementaalne arendus erinevates allikates üsna üheselt kirjeldatud.
Inkrementaalne arendus võib olla nii plaanipärane kui ka paindlik. Mudel näeb ette ehitada valmis algul väike osa süsteemist ning seda järgnevalt mitmes etapis laiendada. Inkrementaalne lähenemine võimaldab arendajatel ja ka tulevastel süsteemi kasutajatel varajastest iteratsioonidest õppida, saada tagasisidet veel siis kui on võimalik teha muudatusi nt süsteemi arhitektuuri kirjutamata kogu koodi ümber.
Joonis 1-2. Inkrementaalne arendus
Tarkvara spetsifikatsioon, projekt ja teostus jaotatakse osadeks (increment), mida asutakse ükshaaval arendama. Sel viisil väheneb ümbertegemist vajavate süsteemi osade hulk ja kliendid saavad võimaluse oma soove pikema aja vältel ringi mõelda. Tüüpiliseks tuleks pidada veel seda, et valminud süsteemi osad on kasutatavad ning see aitab kliendil oma edasistes soovides paremat selgust saada.
Tegevuste käik on järgmine: kõigepealt määratakse nõuded üldisemal kujul ning nad jaotatakse tähtsamateks ja vähemtähtsateks. Järgnevalt määratakse tarneosad - mitme tarnena ja millest koosnevana klient oma tarkvara saama hakkab. Tarne all mõeldakse süsteemi osa ehk inkrementi. Iga tarne peab lisama süsteemile kindla funktsionaalsuse. Sealjuures tootmist alustatakse kõrgema prioriteediga osadest. Kui süsteemi osad on määratud, võetakse ette 1. osa ja hakatakse seda detailiseerima, kasutades selleks sobivaimat protsessi (ja miks ka mitte koskmudelit). Samaaegselt saab täpsustada teiste osade nõudeid, kuid töös oleva osa nõuded on külmutatud. Kui väga vaja, pöördutakse selle osa juurde tagasi hiljem. Kui osa saab valmis, tarnitakse see kliendile, kes saab selle töösse rakendada (või vähemalt seda tõsiselt katsetada). See aitab kliendil täpsustada nõudeid järgmiste osade jaoks (või sama osa hilisemate versioonide tarvis). Seejärel võetakse käsile järgmine osa. Uued osad liidestatakse olemasoleva süsteemiga. Kõiki osi ei pea arendama sama protsessi kasutades.

Inkrementaalse arenduse eelised:

1. Kulutused, mida tehakse kasutaja nõuete muutumise tõttu, vähenevad, uuesti tehtava analüüsi ja dokumentatsiooni hulk väheneb oluliselt võrreldes koskmudeliga.
2. Kergem on saada kliendi tagasisidet juba tehtud arendustööle - kliendid saavad anda kommentaare valminud osadele ja ka näevad, kui palju on tehtud. Sel viisil on esimesed süsteemi osad nagu prototüübid kogu süsteemile.
3. Kliendile on võimalik kiiremini tarnida ja evitada loodavat tarkvara - kliendid võivad saada süsteemist reaalset kasu varem, kui see oleks võimalik koskmudeliga.

Inkrementaalse arendused probleemid:

1. Progress ei ole hästi jälgitav - haldurid vajavad pidevalt materjale progressi mõõtmiseks. Kiire arenduse korral ei ole tasuv tekitada dokumente iga pisikese versioonimuudatuse jaoks.
2. Süsteemi struktuur kipub halvenema uute osade lisandumisel - pidev muutmine rikub süsteemi struktuuri. Selle vältimiseks ja tarkvara kvaliteedi parandamiseks on vaja kulutada lisaks aega ja raha refaktoreerimisele. Halb struktuur muudab tarkvara hilisema muutmise keerulisemaks ja kulukamaks.

Agiilsed arendusmeetodid

Agiilsete arendusmeetodite jaoks sobib kasutada inkrementaaset mudelit. Agiilse tarkvaraarenduse levimise algus läheb 2001 aastasse, kui senise üliplaanipärase arenduse vastased kirjutasid alla "The Agile Manifesto"-le, mille kõige olulisemates punktides rõhutakse inimesele ja inimeste vahelisele suhtlemisele:

Inimesed ja suhtlemine on tähtsamad kui protsessid ja tööriistad.
Töötav tarkvara on tähtsam kui dokumentatsioon.
Koostöö kliendiga on tähtsam kui läbirääkimised lepingu üle.
Muudatussoovidele vastutulek on tähtsam kui plaani järgmine.

Enam arvestatakse tagasiside (koormustestimine, kasutajate arvamus jm) käigus saadud infoga kui loodetakse hoolika etteplaneerimise tehnikale. Põhitähelepanu on inimestel, sh kasutajatel, ja pideval testimisel. Öeldakse, et agiilmeetoditega saavutatakse parem tulemus sama raha eest, aga agiilmeetoditega on raskem ette planeerida, millal tarkvara mingi funktsioon valmis saab - „Agile process will provide the most bang for the buck , but won't say exactly when that bang will be".
Tuntumad ja levinumad agiilsed arendusmeetodid on ekstreemprogrammeerimine (XP), Scrum , Feature Driven Development (FDD), Open Unified Process (OpenUP) jt
Ekstreemprogrammeerimine ehk XP on tuntumaid agiilmeetoodeid. XP-s viiakse sammud läbi äärmuslikult (ekstreemselt - siit meetodi nimetus) lühikestena, võrreldes klassikaliste arendusmudelitega - esimene sammude läbimistsükkel võib olla päevad või nädal pikk, samas kui klassikalistes mudelites kestab see kuid ja aastaid. Enne kodeerimist kirjutatakse automatiseeritud testid, mida tarkvara peab läbima, seejärel programmeeritakse paarides (so kaks programmeerijat ühe arvuti taga kodeerivad ühte programmilõiku - nn "paarisprogrammeerimine"). Kui valminud kood läbib testid, on programmeerimise samm antud iteratsioonis lõpetatud.

Spiraalmudel

Spiraalmudel on samuti üks iteratiivseid arendusmudeleid.
Spiraalmudelit kirjeldas esimest korda Barry Boehm oma 1986 a. artiklis. Protsessi kulgemist kujutab spiraal . Esimene kordus võib olla näiteks seotud süsteemi teostatavuse uurimisega, teine nõudmiste kirjeldamisega, järgmine kavandamisega jne. Mitu kordust on enamasti seotud tarkvara realiseerimisega, kus tema ehitamine toimub inkrementaalselt. Kuid kindlasti ei tohiks spiraali korduseid võrdsustada tavapäraste arendusprotsessi faasidega. Iga kordus on jaotatud 3 kuni 6 sektorisse (erinevad autorid jagavad erinevalt). Iga kordus algab lähema eesmärgi kavandamise ja riskide hindamisega ning lõppeb nö kliendiga - ehk eesmärk peab saama täidetud ja kontrollitud. Sektorite töömahukus ei pruugi olla ühesugune. Boehm'i järgi on sektoreid neli (vt ka joonis 3):
1. Eesmärkide seadmine (Objective setting ) - määratakse selle faasi ehk korduse eesmärgid, piirangud protsessis, tulemused, juhtimisplaan, võimalikud riskid ning alternatiivsed strateegiad lähtudes riskidest.
2. Riskide hindamine ja maandamine (Risk assessment and reduction ) - iga leitud riski jaoks tehakse analüüs, võetakse midagi ette riskide maandamiseks (nt risk, et nõudmised pole adekvaatsed: tehakse prototüüp )
3. Arendus ja valideerimine (Development and validation) - valitakse arendusmudel, mis lähtub hinnatud riskidest (mudel peab olema selline, mis riske vähendada aitab). Nt kui kasutajaliides on suurim risk, siis võib aidata prototüüpide tegemine.
4. Planeerimine (Planning) - projekt vaadatakse üle ja tehakse otsus, kas jätkata järgmisel kordusel, kui otsustatakse jätkata, tehakse järgmise faasi jaoks plaan.
Joonisel 3 on kujutatud üks näide spiraalmudelist. Tegelik arendusprotsess võib varieeruda nii iteratsioonide arvu kui ka tegevuste paigutuse osas.

Joonis 1-3. Spiraalmudel (Boehm 1988) (Allikas: I. Sommerville "Software Engineering " slaidid)
Selle mudeli kõige olulisem erinevus teistest on riskidega arvestamine. Risk - so võimalus, et midagi saab untsu minna. Riskide realiseerumise tõttu ületatakse tähtajad ja maksumus, seepärast peab riskidega arvestama ning võtma midagi ette nende maandamiseks.
Sommerville'i järgi täpselt sellist mudelit kasutatakse harva, kuid ta on aidanud mõista iteratiivse arenduse olemust ja juhtinud tähelepanu riskidega tegelemise vajalikkusele.

Prototüüpimine

Prototüüp on süsteemi algne versioon , mida kasutatakse disaini võimaluste katsetamiseks ning ideede demonstreerimiseks. Prototüüpe saab kasutada erinevates arenduse faasides . Näiteks nõuete analüüsi etapil nende leidmiseks ja valideerimiseks; disaini etapil valikuvõimaluste uurimiseks ning kasutajaliidese kavandamiseks
Kasu prototüüpimisest on: parem süsteemi kasutusmugavus, täpsem ühildumine kasutaja tegelike vajadustega; parem kvaliteet ja hooldatavus ning väiksem vaev arendamisel.
Joonis 1-4 Prototüübi loomise protsess

Prototüüpimise etapid on järgmised:

Nõuete kogumine - seda tehakse üldisemal tasemel ja samas ka fikseeritakse, mida on kindlasti vaja edaspidi täpsustama hakata.
Kiire kavandamine - keskendub nähtavale osale ( sisend , väljund, vormid jms) ja selle tulemuseks on prototüüp. Klient hindab prototüüpi ja oskab selle alusel ka oma soove täpsustada.
Järgneb iteratsioon prototüübi parandamiseks, kuni see rahuldab kasutajat. Samal ajal saab arendaja uusi teadmisi kliendi soovide kohta.
Prototüübi arendamisel on oluline, et see saaks loodud kiiresti, kasutades selleks abivahendeid (kiire prototüüpimise keeled ja tööriistad). Prototüüp ei pea sisaldama kogu funktsionaalsust - ta peab keskenduma sellele, millest ei ole hästi aru saadud; prototüübis ei pea olema vigade kontrolli ning prototüüp on suunatud funktsionaalsetele nõuetele (mitte näiteks turvalisuse probleemidele)
Prototüüpimist võib teha erineval põhimõttel - näiteks ühekordne prototüüpimine ( Throw away prototyping), evolutsiooniline prototüüpimine (Evolutionary prototyping), lisanduv prototüüpimine (Incremental prototyping).

Ühekordse prototüüpimise põhimõtted on järgmised:

Sellised prototüübid tuleb peale loomist likvideerida , sest nad ei ole heaks baasiks tegelikule süsteemile - näiteks ei pruugi nende alusel täita mittefunktsionaalseid nõudeid, prototüübi struktuur ei sobi edasiseks arenduseks ega vasta ka muudele kvaliteedi nõuetele.
Kokkuvõtvalt, erinevalt koskmudelist ei koostata iteratiivsete arendusmudelite järgi esmalt kõikehõlmavat analüüsidokumenti, milline sisaldab muutumatuid kasutajate vajadusi ning „kirjutatakse verega alla" süsteemi tellija ja realiseerija vahel - iteratiivsed mudelid võimaldavad lihtsamalt viia sisse muudatusi süsteemi, saada kasutajatelt varajast tagasisidet, testida arendusprojekti varajases faasis süsteemi arhitektuurilise lahenduse sobivust jmt.
Ei ole ühte, parimat süsteemiarenduse mudelit. Otsus, millist mudelit valida, tuleb langetada lähtuvalt konkreetsest tarkvaraprojektist: tulemist, meeskonna oskustest ja teadmistest, ajagraafikust, kliendi vajaduste selgusest ja stabiilsusest.

Dokumentatsioon

Lisaks eelnevalt vaadeldud tegevustele, vaatleme nüüd tegevuste tulemeid ja tegevuste sooritajaid.
Süsteemi nõuete dokument on nõuete kogumise ja analüüsi tegevuse väljundiks , ning sisaldab kasutajate ning huvipoolte vajadustest lähtuvat süsteemi omaduste ja piirangute kogumit. Toome näiteid nõuetest: funktsionaalne nõue on, et kasutaja saab süsteemi abil hallata klientide andmeid ja arveid, turvanõude näide on, et süsteemist peab saama andmeid kätte ainult selleks volitatud isik. Tehnoloogiline piirang on, et kasutaja peab saama süsteemiga suhelda veebilehitseja abil.
Süsteemi nõuete dokument peaks katma järgmised teemad:
sissejuhatus: dokumendi eesmärk, projekti ulatus, kasutatavate terminite ja lühendite seletused (nn süsteemi sõnastik ), viited teistele dokumentidele, dokumendi struktuuri kirjeldus;
toote kirjeldus;
kasutajate ja huvipoolte profiilid, eesmärgid, vajadused, kogemused. Kasutajate kirjeldamine aitab paremini mõista kasutajate vajadusi ning oskusi loodava tootega ümber käia;
piirangud: kasutajatest või ümbritsevast keskkonnast lähtuvad piirangud, nt olemasolevate süsteemidega seostamine, arendusvahendid, õigusaktid ;
eeldused ja sõltuvused: toote loomine võib eeldada teatud tingimuste täitmist, nt et peatselt jõustatakse õigusakt; kolmas osapool loob liidestatava süsteemi;
käitluskeskkond - kirjeldab platvormid, millel toode peab töötama, sh operatsioonisüsteemid, riistvaraplatvormid, andmebaasimootorid, veebiserverid, rakendusserverid, monitooringuliidesed jms;
kõikide funktsionaalsete ja tehniliste (turva-, kasutatavus - jm) nõuete detailne kirjeldus, sh kasutuslood ja UML kasutuslooskeemid.
Nõuete dokumendi koostab analüütik koostöös tulevaste kasutajatega.
Arhitektuurse disaini dokument kirjeldab süsteemi ülesehitust, süsteemi komponente ning mooduleid, liideseid komponentide vahel ja liideseid teiste süsteemidega. Kirjeldatakse ka füüsiline arhitektuur - riistvara ja näidatakse, milline tarkvara komponent millisele riistvarale paigutatakse.
Arhitektuurse disaini dokument peaks katma järgmised teemad:
sissejuhatus: dokumendi eesmärk, viited teistele dokumentidele, dokumendi struktuuri kirjeldus;
arendusvahendite valiku ja häälestuse, arenduskeskkond;
kodeerimise, sh kommenteerimise ja nimetamise standardid ;
liidesed teiste süsteemidega, andmevahetusformaadid ja meetodid;
toote sisemise struktuuri, ülesehituse: süsteemi jaotuse komponentideks, komponentide kohustused ja rollid, komponentide andmevahetus ;
arhitektuuriotsuste tausta , alternatiivid, valikukriteeriumid;
jõudlusnõuded. Väljendatakse viisil, mida on võimalik testimise käigus kontrollida;
suhtlusviisid kasutajatega, vigade kuvamise viisid;
ressursinõuded, st kui palju toode nõuab mälu, arvutusvõimsust jms;
turvalisuse tagamise meetmed;
porditavus, so võimalus käitada tarkvara erinevatel platvormidel.
Süsteemi nõuded ja arhitektuursed otsused peavad olema omavahel ristviidatud, st vajadusel on võimalik mingi nõude muutmisel muuta temaga seotud arhitektuurilisi lahendusi, ning vastupidi - mingi arhitektuuriotsuse muutmisel nt rahalistel põhjustel leida, milliseid nõudeid selline muutmisotsus puudutab.
Arhitektuurse disaini dokumendi koostab arhitekt lähtudes nõuete dokumendis toodud nõuetest.
Kasutajajuhend on dokument, milline käsitleb kasutaja vaadet süsteemile - milleks toodet saab kasutada, kuidas toodet kasutada, millised on võimalikud veasituatsioonid ning nende lahendamine. Kasutajajuhend ei vaatle süsteemi „sisemust" vaid seda, mis on kasutajale nähtav.
Projektidokumentatsioon käsitleb projektijuhtimisega seotud materjale.
Haldusjuhend käsitleb toote installeerimist, andmesiiret, toote hooldust ja administreerimist, konfigureerimist, muudatuste sisseviimise korda.

Viited

.DOCX Laadi alla originaalfail 21 lk · .docx · 19 allalaadimist

50 punkti Autor soovib selle materjali allalaadimise eest saada 50 punkti.

~ 21 lehte Lehekülgede arv dokumendis

2017-11-02 Kuupäev, millal dokument üles laeti

19 laadimist Kokku alla laetud

0 arvamust Teiste kasutajate poolt lisatud kommentaarid

Dravvu. Õppematerjali autor

1.Elutsükli üldised mudelid 3
2.Koskmudel 5
Kokkuvõte: 7
3.Inkrementaalne arendusmudel 8
Inkrementaalse arenduse eelised: 11
Inkrementaalse arendused probleemid: 11
4.Agiilsed arendusmeetodid 12
5.Spiraalmudel 14
6.Prototüüpimine 16
Prototüüpimise etapid on järgmised: 17
Ühekordse prototüüpimise põhimõtted on järgmised: 17
7.Dokumentatsioon 18
8.Viited 21

tarkvara arhitekt Ühekordse prototüüpimise põhimõtted Prototüüpimise etapid

Kasutatud allikad

Sarnased õppematerjalid

pdf

Tarkvaratehnika konspekt eksamiks

Tarkvaratehnika konspekt. Tarkvaratehnika Tarkvaratehnika e. tarkvara inseneeria on professionaalsele tarkvaraarendusele suunatud distsipliin, mis tegeleb sellega, kuidas organiseerida tarkvaraarendust, arvestades organisatsiooniliste ja rahaliste piirangutega. Tarkvaratooted koosnevad valjatöötatud programmidest ja nende dokumentatsioonist. Tarkvaratehnika eesmärgiks on kuluefektiivne tarkvaraarendus kogu tarkvara elukaare ulatuses. Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale. Tarkvaratehnika „point“: Tarkvaratehnika on suunatud professionaalsele tarkvaraarendusele. Tarkvaratehnika ei tegele tarkvaraarenduse endaga vaid sellega, kuidas organiseerida tarkvaraarendust. Tarkvaratehnika vajadus - kõrgenenud nõudmised: suuremad süsteemid, keerulisemad süsteemid, kiiremini arendatavad süsteemid. Insener suuda

Tarkvaratehnika

138

docx

Tarkvaratehnika 2016/2017 eksami materjal

 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? o  Inimesed o Oluliseim komponent o Suhted ja suhtlemine on nagu õli, mis paneb kogu masinavärgi tööle o Tööriistad üksi tööd ei tee o Klient, testija, arendaja …  Nõuded o Nõuetest arusaamine on eduka projekti alus o Milleks hallata?  Muutuvad ajas  Ununevad  Olulisus muutub  Tekivad ja kaovad

Tarkvaratehnika

docx

Tarkvara kvaliteet ja standardid

1. Tarkvaratoode mis siia kuulub? Tarkvara arenduse tulem (toode, teenus) hõlmab mitmesuguseid komponente, mis kõik võivad olla kvaliteedihalduse objektid, näiteks 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... projektdokumentatsioon kasutamise kohta (kasutajajuhendid); objektsüsteemi kohta; loodavate objektide kohta (programmi/testimise dokumentatsioon); installeerimise ja seadistamise kohta; arenduse (sh testimise) kohta

Tarkvara kvaliteet ja standardid

docx

Tarkvaratehnika konspekt ja kordamisküsumused 2016-2017

6. Kuidas liigitada nõudeid? eksam 7. Nõude 3 põhiomadust. 8. Nõuete valideerimise tehnikad. 9. Komponentidel põhinev arhitektuur 10.Kihiline arhitektuur eksam 11.Objektorienteeritud arhitektuur 12.Teenusorienteeritud arhitektuur 13.Lihtsa koodi disaini 4 elementi 14.Miks peab nõudeid haldama? 15.Milleks kasutatakse versioonihaldust? eksam 16.Funktsionaalne nõue eksam 17.Mittefunktionaalne nõue eksam 18.Tarkvara elutsükkel 19.Millest koosneb tarkvara? 20.Mis on testimine? 21.Staatiline testimine eksam 22.Dünaamiline testimine eksam 23.Valge kasti testimine 24.Musta kasti testimine 25.Testimise tasemed 26.Re-testmine ja regressioonitestimine 27.eXtreme programmingu alustalad 28.Kirjelda lühidalt XP-d 29.Mis on mudel? eksam 30.Mis on UML? Miks on seda vaja? 31.Tarkvaratehnika 3 vaadet. 32.Tarkvara protsessi etapid. 33

Tarkvaratehnika

210

pdf

Tarkvaratehnika kordamisküsimused

TARKVARATEHNIKA KORDAMISKÜSIMUSED 1. Mis on tarkvaratehnika? Software engineering ! “Engineers Australia” definitsioon: Tarkvaratehnika on tiimide poolt rakendatav distsipliin tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset tarkvara mis rahuldab kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel. IEEE definitsioon: Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisviisi rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale. Tarkvaraarendus on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu, standardeid, jne. Tarkvaraarendus on progemine + konfigursatsiooni haldus. Tarkvaratehnika ei ole ainult programmi kirjutamine, vaid teemad hõlmavad ka kvaliteeti, ajakavasid,

Tarkvaratehnika

docx

Tarkvara kvaliteet ja standardid kordamisküsimused

Kui kvaliteet on mingi tootja või kaubamärgiga kaasas käiv omadus. 4. Kuidas suhtuda väitesse "Tarkvara kvaliteeti pole olemas, kogu aeg on kiirustamine ja pole aega ühte asja valmis saada, juba tuleb järgmine"? Millist kvaliteedi mõistet siin arvestatakse? Kas / millal on võimalik, et kvaliteeti pole? See oleneb keskkonnast, kus see toode asub. Mõeldud on ideaalse kvaliteedi mõistet. Sageli ei pruugi ideaalset kvaliteeti olemas olla. 5. Tarkvara arenduse tulemid Toode, teenus, mis hõlmab:  Arenduse käigus hangitud infotehnoloogia vahendeid  Arenduse käigus tehtud tööd  Muudatusi tellija organisatsioonis  Projektdokumentatsioon kasutamise, loodavate objektide, installeerimise ja seadistamise, arenduse kohta  Metoodika  Vahendid hoolduseks  Teadmised projekti tulemuste kasutamisest  Õigused kasutamiseks 6. Tarkvara nõuete liigitusi

Tarkvara kvaliteet ja standardid

docx

Artikleid dokumenteerimisest

Tallinna Transpordikool Ragnar Järviste Artikleid dokumenteerimisest Tallinn 2013 Dokumentatsioon Süsteemi nõuete dokument on nõuete kogumise ja analüüsi tegevuse väljundiks, ning sisaldab kasutajate ning huvipoolte vajadustest lähtuvat süsteemi omaduste ja piirangute kogumit. Toome näiteid nõuetest: funktsionaalne nõue on, et kasutaja saab süsteemi abil hallata klientide andmeid ja arveid, turvanõude näide on, et süsteemist peab saama andmeid kätte ainult selleks volitatud isik. Tehnoloogiline piirang on, et kasutaja peab saama süsteemiga suhelda veebilehitseja abil. Süsteemi nõuete dokument peaks katma järgmised teemad: · sissejuhatus: dokumendi eesmärk, projekti ulatus, kasutatavate terminite ja lühendite seletused (nn süsteemi sõnastik), viited teistele dokumentidele, dokumendi struktuuri kirjeldus; · toote kirjeldus; · kasutajate ja hu

Ühiskond

204

docx

Süsteemianalüüsi kontrolltöö 1

 Valdkonna visiooni esitamiseks kasutatavad mudelid ja notatsioonid  Iteratiivsest arendusprotsessist UP (eelmise loengu jätkuna) o Analüüsi mudeli haldamine iteratiivses arendusprotsessis M. Roost , TTÜ Informaatikainstituut, Loengukonspektid aines Süsteemianalüüs, 2014 Intervjueerimisest kui ühest analüüsi tehnikast  Suuline versus kirjalik intervjueerimine  Intervjuu elutsükkel (Ettevalmistamine -> läbiviimine -> tulemuste analüüs)  Intervjuu plaan: eesmärgid, küsimused, rollijaotus o Seos Zachmani raamistikuga (milliseid ridu, veerge, lahtreid tahame ’sisustada’? Kuidas küsimused sõnastada?  Intervjuu protokoll: protokolli täpsus, mis on oluline, mis mitte? Valdkonna visiooni esitamiseks kasutatavad mudelid ja notatsioonid Vaata eraldi dokumenti harjutustundides modelleerimise

Modulatsioon

Rohkem sarnaseid