Vajad kellegagi rääkida?
Küsi julgelt abi LasteAbi
Logi sisse

Sissejuhatus Reaalajatarkvaratehnikasse (2)

5 VÄGA HEA
Punktid
  • Mille poolest erinevad süsteemitehnika ja tarkvaratehnika ? Sarnasused?
    Tarkvaratehnika on süsteemitehnika konkretiseering tarkvaratoodete tegemise valdkonda. Tarkvaratehnika on tugevalt seotud arvutiteadusega., erinev on suhtumine reaalsesse maailma. Tarkvaratehnika tunneb rohkem huvi tarkvara loomise protsessi administratiivsele ja tehnilise korraldamisele ning juhtimisele. Tarkvaratehnika peab ideaalis oluliseks, et töötluseks kasutatav lähteinfo vastaks võimalikult täpselt tegelikkusele. Tarkvaratehnika toode valideeritakse näidates tema vastavust reaalse maailma vajadustele. Tarkvaraprojekti lähteülesanne tuleneb vahetult süsteemile esitavatest nõuetest, lahendus sõltub oluliselt kogu süsteemile ja süsteemi arendamisele seatud kitsendustest ning konkreetsetest nõuetest.
    Süsteemitehnika on tehnokäsitluse rakendamine süsteemide projekteerimiseks ja loomiseks.
  • Mida tuleb silmas pidada süsteemi tükeldamisel alamsüsteemideks?
    Süsteem on kogum omavahel ühendatud, interaktsioonis olevaid alamsüsteeme. Süsteemi tükeldamisel peaks iga alamsüsteem säilitama oma funktsionaalsuse. Alamsüsteemid peavad suutma töötada ka üksi. Üksikute alamsüsteemide omaduste ja funktsioonide kombineerimisel saadakse teenuse uus kvaliteet.
  • Alamsüsteemide ühendamisel tekkiva sünergismi põhjused
    Alamsüsteemid eraldi ei suuda tagada teenuse kvaliteeti. Alamsüsteemid võivad oma kitsast funktsiooni täita perfektselt, kuid see alamsüsteem ei suuda hõlmata kogu käsitletavat funktsionaalsust. Alles alamsüsteemide sünergism üheks suuremaks süsteemiks annab oodatud tulemuse. Süsteem ei saa olla alati optimaalne iga üksiku alamsüsteemi mõttes, küll aga peaks olema kõikide nõudmiste suhtes võimalikult hästi funktsioneeriv.
  • Omadused, mis põhjustavad reaalajasüsteemide klassi ja modelleerimissüsteemide klassi erinevuse
    Modelleerimissüsteemid tegelevad reaalsemaailma nähtuse modelleerimisega kasutades mudeleid . Esmaseks probleemiks on tagada olemasolevate matemaatiliste teooriate ja nende arvutirealisatsioonide võimalikult täpne vastavus. Süsteemide realiseerimisel on raskuseks mittetäielikult kirjeldatud nõuete spetsifikatsioon .
    Reaalajasüsteemid on tegelikkuse uus komponent , mis toimib iseseisvalt reaalses maailmas, on interaktsioonis teda ümbritsevate maailma osadega ja võib aktiivselt mõjutada nende käitumist. Reaalajasüsteem toimib sageli üsna pika aja jooksul sõltumatult oma kasutajast.
  • Miks on vaja süsteemi elutsüklit jagada etappideks ?
    Tarkvara on toode ja tema loomise protsess on oma suure keerukuse tõttu mitte kuigi hästi juhitav. Süsteemi loomise protsessi lihtsustamiseks on see jagatud etappideks. Läbitud etappide käigus liigutakse mitte formaalsest tegelikust maailmast formaalsema poole. Süsteemide spetsifitseerimine, projekteerimine , analüüs, verifitseerimine ja osaliselt testimine toimub (pool)formaalses maailmas. Lõpliku realiseerimise käigus viiakse süsteem tagasi tegelikult eksisteerivasse maailma. Etappideks jagamisega saab igat sammu kirjeldada sama skeemiga – probleemi fikseerimine, täiendava info otsimine, meetodi ja tööriistade valik, probleemi lahendamine, saadud kogemuse analüüsimine ning meetodite ja tööriistade modifitseerimine.
  • Erinevus süsteemi spetsifikatsiooni ja tegeliku süsteemi vahel
    Süsteemi spetsifitseerimine toimub (pool)formaalses maailmas, tegelik süsteem eksisteerib aga mitteformaalses maailmas.
  • Miks ei saa süsteemile esitatavad kasutajanõuded kunagi täielikult kirjeldada süsteemi soovitavat funktsioneerimist?
    Süsteem toimib reaalses maailmas, kus objektidel on loendumatu arv omadusi. Arvuti kaudu tekib suletud juhtimisahel, mis võib oluliselt muuta esialgselt hinnatud (ilma arvutita eksisteerinud) süsteemi omadusi ja temale esitatud nõudeid ja kitsendusi.
  • Tarkvarasüsteemi funktsionaalsed nõuded
    Mittefunktsionaalsed nõuded tulenevad vajalikest ajalistest kitsendustest ning töökindluse, ohutuse, hooldatavuse, turvalise jms nõuetest.
  • Mis on reaalajasüsteem?
    Reaalajasüsteemi võib vaadelda kui loodus- või tehiskeskkonda sisseehitatud arvutisüsteem, mis muudab oluliselt esialgse keskkonna funktsioneerimise kvaliteeti ja/või vormi. Reaalajasüsteem moodustab liidese kolme valdkonna – juhitav või jälgitav objekt, arvutisüsteem ja inimene – vahel.
  • Mis teeb arvutisüsteemist reaalajas töötava süsteemi?
    Arvutisüsteem töötab reaalaajas, kui süsteemi töö õigus on defineeritud mitte ainult algoritmi täitmisel saadud arvutustulemuste alusel, vaid oluline on ka ajahetk, millal need tulemused saadi. Reaalajas töötav arvutisüsteem on vahetult ühenduses lähteinformatsiooni allikaga, sageli ka arvutustulemusi kasutava objektiga.
  • Termodünaamiliselt avatud ja suletud süsteemid
    Andme- ja infotöötlussüsteemid on suletud – lähteinfo liigub arvutist sisse ja tulemused välja läbi väga rangelt tsenseeritud kanalite , hästi defineeritud kujul. Reaalajasüsteemid on avatud. Sel on kaks liidest – inimliidese kaudu liigub enamus infot hästi defineeritud kujul, läbi protsessiliidese liigub väga erinevatesse esinemisvormidesse kodeeritud informatsioon. Lisaks puudub arvutil valida info vastuvõtu hetke (infovahetus toimub tihti peale keskkonna initsiatiivil).
  • Erinevus paralleelsete ja sundparalleelsete programmide vahel
    Sundparalleelsus on paralleelsus, mis on tarkvara insenerile peale surutud ümbritseva keskkonna poolt. Vajalik reaalajasüsteemide nõuete täitmiseks.
  • Funktsionaalsete ja mittefunktsionaalsete nõuete erinevus
    Funktsionaalsete nõuete all mõistetakse inim-operaatori ja juhitava/jälgitava kobara poolt arvutikobarale esitatavaid nõudeid. Funktsionaalsed nõuded iseloomustavad kasutaja ootusi süsteemi poolt täidetavatele funktsioonidele. Mittefunktsionaalsed nõuded kujutavad endast nõudeid töökindluse, ohutuse ja turvalisus suhtes ning ajakitsenduse täitmine.
  • Olekumuutuja kehtivusintervalli määramine
    Iga olekumuutuja väärtus on aja funktsioon. Kehtivusintervalli pikkus sõltub juhitava objekti dünaamikast ja väärtuse kasutamiseesmärgist.
  • Mõõtmise eeltöötlus
    Andurilt tulev signaal on tavaliselt mingi füüsikaline suurus, mis on arvutile arusaamatu. Toorandmed tuleb kalibreerida ja teisendada vajalikkudesse mõõtühikutesse.
  • Inimliidese ja alarmiseire omavaheline seos
    Alarmiseire tähendab mõõdetud andmete ja vastuvõetud sündmuste pidev seire , selleks et õigeaegselt avastada ja teatada operaatorile objekti ebatavaline käitumine. Alarmisõnumite täpne järjestamine aitab operaatorit vigade avastamisel ja kõrvaldamisel.
  • Alarmlaviin. Miks on ohuallikas?
    Alarmlaviin tekib paljude andmeelementide kõrvalekaldumisel normist . Arvutikobar peab avastama ja kuvama kõik need teated ja aitama operaatoril välja selgitada laviini põhjustanud primaarse põhjuse. Alarmlaviini ajal on sidevõrgu koormus tavapärasest palju kordi suurem ja kui süsteem pole projekteeritud piisava varuga ei pruugi kõik sõnumid pärale jõuda või jõuavad suure hilinemisega.
  • Milliseid juhtimise liike eristatakse reaalajasüsteemides?
    Superviisorjuhtimine tehnoloogiliste protsesside juhtimises – tegeleb strateegiate väljatöötamisega ning realiseerimisega teiste süsteemi osade kaudu.
    Juhtimine, mis tegeleb strateegilistest eesmärkidest ja otsustest lähtuvate konkreetsemate tegevuste valiku ja realiseerimisega nii, et täiturite kaudu sobivalt mõjutada juhtivat kobarat, rahuldades samas ka kõiki kitsendusi.
  • Kas juhtimisalgoritmi realiseerimine arvutis võib muuta selle omadusi?
    Juhtimisel võivad tekkida probleemid erinevate teooriate, nende arvutirealisatsioonide ja tegelikkuse mittepiisava ühildumisega, mis viib tegeliku oleku väära hindamiseni, algoritmi tulemuste ebapiisava täpsuseni või juhitava objekti, täiturite või muude süsteemi osade kitsenduste rikkumiseni.
  • Miks ei õnnestu alati taastada esialgset pidevat signaali?
    Diskreetsetel ajahetkedel tehtud mõõtmistest saadakse pideva funktsiooni rekonstrueerimisel varifunktsioon. Mõõtmise sagedus peab olema piisavalt suur fs>2fmax Kuna mõõdetakse diskreetsetel ajahetkedel pole teada, mida teeb signaal tegelikult vahepeal .
  • Reaalajasüsteemides kasutatav inimliides
    Inimliides võimaldab arvutiga suhelda inimesele sobilike meetoditega. Inimliides peab tagama juhitava/jälgitava kobara seisundi kohta info esitamise kooskõlalisuse, võimaldama infot vastavalt vajadusele filtreerida, hõlpsat juurdepääsu otsuste tegemise abivahenditele. Inimliidese koosseisus sisaldub tavaliselt ka andmete ajaloo salvestamise ja aruandluse alamsüsteem.
  • Mida kujutab endast eriolukordade töötlus?
    Eriolukordade töötlus hõlmab endas kõike, mis on seotud vigade automaatse kompenseerimisega, valesti tehtud arvutuste korrigeerimisega, tarkvara ja riistvara diagnostikaga, rikete puhul süsteemi funktsionaalsuse muutmine jms.
  • Millisest etapist peaks hakkama tõsiselt tegelema eriolukordade spetsifitseerimisega ja lahendamisega?
    Iga süsteemi loomise elutsükli etapil keskendutakse konkreetsetele, sellel etapil tekkivatele ja lahendatavatele eriolukordadele. Kui tarkvara areneb edasi, lisanduvad uued detailid ja ilmnevad uued eriolukorrad.
  • Eriolukordade näited
    Kasutaja nõuete kirjeldamise etapil fikseeritakse potentsiaalset huvi pakkuvad vead juhitavas/jälgitavas kobaras , kirjeldatakse vigade kõrvaldamise teed.
    Projekteerimise etapil fikseeritakse vead rakendustarkvaras, mis detailse projekteerimise etapil tükeldatakse edasi arhitektuuriga seotud või detailse loogilise projektiga seotud eriolukordadeks, ja vigade kõrvaldamise võimalused.
    Realiseerimise etapil fikseeritakse huvi pakkuvad vead konkreetses arvutisüsteemis ja nende kõrvaldamise võimalused.
  • Miks on vaja andmeelementide kehtivusaega?
    Õige tulemus valel ajal on vale tulemus. Teooria aluseks olev aksiomaatiline baas ei tohi muutuda teooria kasutamise ajal.
  • Ajakitsenduste ja fluktuatsiooni poolt põhjustatud realiseerimisraskused
    Ajakitsendustest lähtuvalt tuleb tagada andmeelementide kehtivusaeg, tulemuste õigeaegne kasutamine, sundparalleelsus.
    Fluktuatsiooni suurusel on oluline mõju juhtimise kvaliteedile. Enamus algoritme toimib diskreetses ajas, kus eelduseks on ajaühiku konstantne suurus, mida on aga arvutis realiseerimisel väga raske tagada.
  • Ajakitsenduste grupid reaalajasüsteemides
    Jõudluskitsendused – käivitusperiood, töö kestus, kitsendused sündmuste järjekorrale.
    Kitsendused protsesside vahelisele interaktsioonile – alustamise hetk, töö sünkroniseerimise režiim ja täpsus.
    Andmete ja sündmuste kehtivuse intervallid – sündmuste ekvivalentsuse intervall , sündmuste samaaegsuse intervall.
  • Töökindluse ja valmisoleku erinevus
    Süsteemi töökindlus on tõenäosus, et süsteem garanteerib ettenähtud teenuse ajahetkest t0 kuni ajahetkeni t, eeldusel, et süsteem oli töökorras ajahetkel t0.
    Valmisolek on ettenähtud teenuse osutamise valmiduse mõõt. Valmisolek näitab suhtelistes ühikutes, mille jooksul süsteem on võimeline tagama teenuse täies mahus .
  • Milliseid nõudeid peab süsteem täitma sertifitseerimiseks?
    Sertifitseerimisel kontrollitakse järgmisi süsteemi omadusi: kas ohutu töö seisukohalt kriitilised alamsüsteemid on muust süsteemist isoleeritud liidestega; kas kõigile koormus- ja veahüpoteesidele vastavad stsenaariumid on läbi mängitud; süsteemi arhitektuur toetab sertifitseerimisprotsessi.
    Süsteem peab olema projekteeritud nii, et tema kohta oleks võimalik koostada täielik ja täpne töökindluse mudel, mis ei tohi sisaldada projekteerimise vigu kirjeldavat olekumudelit. Projekteerimisel tehtud otsused peavad eelistama lahendusi, mis minimiseerivad töökindluse mudeli uurimiseks vajalike mõõdetavate parameetrite arvu ja lihtsustavad analüütilist arutelu.
  • Ranges ja nõrgas reaalajas töötavate süsteemide erinevus
    Ranges reaalajas töötav süsteem peab tulemused väljastama täpselt ettenähtud ajaks, ohutus on sageli kriitilise tähtsusega. Kõik kriitilised arvutused tuleb teha paralleelselt kahel või enamal protsessoril, mis peavad kontrollima üksteise korrasolekut.
  • Aja ja sündmuste poolt juhitud süsteemid
    Sündmuste poolt juhitud süsteemis saab igasugune interaktsioon algatatud olulise muudatuse tõttu ümbritseva keskkonna olekus, mis toimuvad juhuslikel ajahetkedel. Aja poolt juhitud süsteemides on kõik interaktsioonid algatatud aja kulgemise järgi. Arvutisüsteem kontrollib vahetult möödunud ajaintervallis toimunud sündmuseid ja valib redigeerimiseks nende hulgast välja olulised. Lisaraskus tekib kellade sünkroniseerimisega.
  • Sardsüsteemid kitsamas ja laiemas mõttes
    Kitsamas mõttes tähendab sardsüsteem reaalaja süsteemi, mis on ehitatud seadme sisse ja ei ole tavakasutajale üldse märgatav. Sellistes rakendustes on tavaliselt tegemist mikroprotsessoritega ja spetsiaalsete kiipidega, mis on nii sisendi, kui väljundi poolt vahetult ühendatud juhitava/jälgitava objektiga.
    Laiemas mõttes tähendab sardsüsteem suvalist reaalajasüsteemi, kus vähemalt osa sisendeid ja väljundeid on vahetult ühendatud objektiga.
  • Mille poolest on tarkvaratehnika erinev ja raskemini hallatav ?
    Tarkvaratehnika on osa keerulisest riistvara, inimeste, süsteem- ja rakendustarkvara ning bürokraatlike protseduuride kompleksist. Tähtis on aja ja raha planeerimine .
  • Mudeli ja tegelikkuse vahekorra ähmasuse poolt tekitatavad raskused tarkvaratehnikas.
    Ümbritseva keskkonna omadusi saab uurida vaid keskkonna mudelite abil, sama lugu on tulevase toote enda omadustega. Mudel on tegeliku maailma eeskujul tehtud passiivne seade, mis võimaldab uurida tegelikkuses toimuvaid protsesse vastavalt inimese soovile. Tegelikkus on see, mis toimib koostöös loodusliku keskkonnaga vastavalt loodusseadustele ka ilma inimese sekkumiseta. Reaalajatarkvara toimib termodünaamiliselt avatud süsteemis ja teda ei saa käsitleda mudeli mudelina.
  • Tarkvara- inseneri töö sarnasused süsteemi-inseneri tööga
    Ohukriitiliste reaalajasüsteemide tegemisel ja kasutamisel on tarkvara inseneride vastutus viidud äärmuseni. Süsteemi insener peab looma vastastikuse arusaamise tellija /kasutaja ja tarkvara loova grupi vahel. On soovitatav, et süsteemiinsener lülitub töösse juba süsteemi analüüsi faasis. Tarkvara insener peab aitama koostada projekti üldplaani.
  • Süsteemi tegemise algus
    Süsteemi loomine algab süsteemi eesmärkide, nõuete ja kitsenduste defineerimisega. Iga uue süsteemi loomise idee esimene konkretiseering tekib tulevase süsteemi projekti planeerimisel. Esimesena koostatakse süsteemi üldplaan.
  • Projekti jagamine konkreetseteks töödeks
    Kogu projekt tuleks jagada paraja suurusega töödeks nii, et need osad oleks hästi juhitavad ja kontrollitavad. Samuti tuleks silmas pidada ka varem tehtud tarkvara osade taaskasutamise vajadust. Igal hetkel peab projekti osade kohta saama teada nende peale kulutatud raha, nende olekut võrreldes plaaniga, iga üksiku hallatava programmistide grupi integraalne jõudlus.
  • Miks on vaja Gantt ’i ja PERT ’i diagramme ?
    Neid diagramme kasutatakse projektitöödeks jagamise kirjeldamiseks, samuti ka iga töö sisese tükelduse kirjeldamiseks. Gantt’i diagramm koondab andmed üksikute tööde alguse, lõpu ja vahepealsete ülevaatuste kohta, ning fikseerib tegijad ja töömahud. PERT’i diagramm loetleb vajalikud tegevused ja nende vahelised põhjuslikud seosed.
  • Kuidas hinnata projekti üldmaksumust?
    Projekti üldmaksumuse lähenduseks saab võtta ressursside vajaduse hinnangu. Tarkvaratoote maksumuse arvutamine eeldab varasemat kogemust ja tarkvara meetrika vahendite kasutamise kogemust ning võimalust. Projekti maksumuse hinnangute täpsus sõltub projekti kohta teadaoleva informatsiooni kogusest ja usaldusväärsusest. Peamised tarkvara maksumuse hindamise meetodid on: 1) Algoritmilised mudelid (tarkvara meetrika tulemuste alusel arvutatakse eeldatav üldkulude summa) 2) Ekspert hinnangud 3) Võrdlemine analoogsete projektidega 4) Parkinson ’i meetod (projekti maksumus surutakse tellija poolt etteantud summa sisse) 5) Võidupakkumise hind 6) Langev meetod (projekti maksumust hinnatakse lõpptoote üldiste parameetrite alusel) 7) Tõusev meetod (iga projekti kuuluva tarkvara komponendi maksumust hinnatakse eraldi, kogu projekti maksumus saadakse nende summeerimisel ja üldkulude lisamisel). Praktikas tuleks kasutada mitut erinevat meetodit, võrrelda neid ja hinnata projekti maksumust korduvalt.
  • Millest koosneb projekti üldmaksumus?
    Ressurssideks leotakse vajalik riistvara, tarkvaratehnika tööriistad, inimesed ja paljudel juhtudel ka ruumide üür ning firma arenduskulud.
  • Kas suurema arvu programmistidega saab alati töö kiiremini valmis?
    Tänu tarkvara tootmise keerukusele ja tegijate vahelise infovahetuse olulisusele on igal projektil oma optimaalne tegijate arv.
  • Mille peale kulub tegelikult programmisti tööaeg?
    Projekti meeskonna liikmed kulutavad päevas vaid 50% tööajast projektiga vahetult seotud tööde jaoks. Ülejäänud aeg kulub arvutite ja tarkvara probleemide kõrvaldamiseks, kõrge prioriteediga tööde tegemiseks, koosolekuteks, bürokraatiaks, isiklikeks asjadeks jne. Programmistid on isiksused ja järelikult erineb ka nende töö tootlikkus.
  • Projekti tehnilised ülevaatused
    Projekti ülevaatused on tavaliselt seotud projekti plaanis fikseeritud verstapostidega. Traditsioonilised on tarkvara nõuete spetsifikatsiooni ülevaatus, kõrgtasemega projekti ülevaatus, detailprojekti ülevaatus ja lõppkatsetusteks valmisoleku ülevaatus. Projekti tehniline ülevaatus eeldab põhjalikku ettevalmistust.
  • Mis tuleb arutlusele projekti ülevaatusel?
    Ülevaatuse eesmärk on hinnata tehtud töö kvaliteeti, kontrollida selle vastavust kasutaja nõuetele ja kokkulepitud standarditele, kontrollida projekti ressursside kasutamist ja projekti meeskonna poolt tehtud riskihinnangute paikapidavust. Ülevaatusel antakse soovitusi projekti jätkamise teede kohta.
  • Muudatuste sisseviimine tarkvaraprojekti
    Muudatused on iga projekti käigus paratamatud. Segaduste vältimiseks on tähtis sisse viia muudatuste tegemise lubade andmise, muudatuste tegemise, tehtud muudatuste kohta info levitamise ja muudatustele eelnenud versioonide arhiveerimise täpne kord. Iga üksiku muudatuse vajaduse peab otsustama spetsiaalne selleks määratud isik (projekti juht).
  • Tarkvara loomise plaan
    Tarkvara loomise plaani saab lõplikult kokku panna alles pärast süsteem nõuete spetsifitseerimist ja sellest lähtuva tarkvara nõuete spetsifikatsiooni koostamist. Plaan peab sisaldama realistliku tarkvara toote maksumuse ja realistliku valmimistähtaja. Pllani komponentideks on: projektiga valmivad tooted, ülevaatuse ja etapi lõppude kuupäevad, eelarve.
  • Milleks on vaja tarkvara elutsükli mudelit?
    Elutsükli mudel tekkis projektijuhtide abistamiseks projekti haldamisega seotud tegevuste objektiivse pildi saamisel, projekti haldamise otsuste tegemisel, tehniliste projektiotsuste tegemisel, riskide minimiseerimiseks jne.
  • Tarkvara elutsükkel
    Tarkvara läbib oma loomise käigus kuus generatiivse elutsükli etappi : 1) nõuete formuleerimine ja analüüs 2) projekteerimine 3) kodeerimine ja üksikosade katsetamine 4) katsetamine ja osade ühendamine tervikuks 5) vastuvõtu katsetused 6) kasutamine ja hooldus.
  • Kaskaadmudeli omadused
    Kaskaadmudel eeldab, et paralleelselt nõuete analüüsiga ja projekteerimisega toimub ka nende etappide tulemuste kontrollimine prototüübil. Iga elutsükli etappi lõpus peab valmima dokument selle töö tulemustest koos hinnangutega ja tarkvara hindamise grupi heakskiiduga. Nii väheneb vigade ja mittekokkusobivate osade tekkimise tõenäosus projektis . Kaskaadmudeli puudused tulenevad tema tugevast orientatsioonist dokumentatsioonile – elutsükli etapp saab lõppeda vaid siis, kuinõutav dokument on koostatud ja allkirjastatud. Kaskaadmudel ei peegelda tarkvara loomisprotsessi paralleelset ja iteratiivset olemust ning soodustab töö planeerimist rangelt järjestikuliste etappide kaupa.
  • DOD mudeli erinevused kaskaadmudelist
    DOD mudeli kohaselt saab tarkvara nõuete analüüsi etapp oma lähtematerjalid vahetult süsteemi väljatöötamisel valminud dokumentidest. Tarkvara projekteerimisetapp on jagatud kaheks – eelprojekteerimiseks ja detailseks projekteerimiseks. Katsetamise ja integreerimise etapp jaguneb kaheks: tarkvara katsetamine ja integreerimine ning süsteemi katsetamine ja integreerimine.
  • Spiraalmudel
    Spiraalne elutsükli mudel baseerub toote loomise riski osatähtsuse arvestamise märgataval suurendamisel ning kombineerib klassikalise elutsükli mudeli parimad omadused prototüüpide loomisega ja varem valmistatud tarkvara osade taaskasutamisega. Hästi töötav võimalus on valmistada toode prototüüpide jadana. Spiraalmudeli iga etapi alguses on kohustuslik riskianalüüs ja iga etappi lõpus on kohustuslik testimine, valideerimine ja/või sertifitseerimine. Spiraalmudeli eelised: sobib hästi nii uute süsteemide loomiseks kui olemasolevate modifitseerimiseks, sisseehitatud riskianalüüs võimaldab aegsasti avastada palju ohtusid ja neid vältida.
  • Tarkvara protsessi kirjeldamise mudelid
    Tarkvara protsessi kirjeldavad mudelid on firmade küpsuse, professionaalsuse ja töövõime hindamise vahendid, haarates endasse nii tarkvara loomisega seotud tehnilised kui ka haldusaspektid.
  • Tarkvaratehnika tööriistad
    Tarkvara loomiseks on kasutusel suur hulk erinevaid meetodeid ja neid toetavaid tööriistu. Neid võib liigitada: 1) üksiku töö tegemiseks mõeldud tööriistad 2) tööde kompleksi tegemist toetavad tööriistad
  • Kuidas abistab andmesõnastik meeskonna liikmeid?
    Andmesõnastiku põhieesmärk on projektis kasutatavate nimede ja mõistete üheselt mõistetav ning täpne defineerimine . Nii räägivad meeskonna liikmed samadest asjadest kasutades samu mõisteid. Lisaks lihtsustub ka nimede ning mõistete unikaalsuse kontroll. Andmesõnastikku salvestatud terminite alusel valitakse diskussioonide ja arutluste käigus välja edasise töö jaoks olulised mõisted.
  • Kompromisside maatriks
    Kompromissi maatriksi read moodustatakse valikut mõjutavatest kriteeriumitest , veerud igale alternatiivile vastavast kriteeriumite väärtustest ja iga kriteeriumi suhtelisest tähtsusest otsuste tegemisel. Koostatud maatriks annab objektiivse aluse otsuste tegemiseks ja näitab ühtlasi iga alternatiivi nõrgad ja tugevad kohad.
  • Kuidas toimib Delphi meetod?
    Sõltumatutelt ekspertidelt kogutakse vastused küsimustikule, millest koostatakse anonüümne tabel ja saadetakse kõigile vastanud ekspertidele. Seejärel korrigeerivad paljud eksperdid oma eelmisi vastuseid, millest koostatakse uus tabel. Protsessi korratakse seni, kuni saavutatakse ekspertide piisav üksmeel. Delphi meetodi eelis on, et arvamusi saavad mõjutada vaid tegelikud vastused.
  • Kuidas mõjutavad stsenaariumid tarkvara projekti arengut?
    Stsenaariumid on paljudel juhtudel asendamatud tarkvara katsetuste planeerimisel ja tarkvara valideerimisel. Eriti olulised on harvaesinevaid situatsioone kirjeldavad stsenaariumid süsteemi töö- ja veakindluse testimisel. Eriti kasulikud on stsenaariumid kasutaja nõuete valideerimisel.
  • Lõplikud automaadid ja StateCharts
    Lõplikud automaadid on formaalsed mudeleid, mida kasutakse süsteemi käitumise kirjeldamiseks. StateCharts võimaldab kirjeldada mitme samaaegselt ja paralleelselt toimiva lõpliku automaadi koostööd.
  • Millega tegeleb tarkvara meetrika?
    Tarkvara meetrika tegeleb tarkvara parameetrite ja tarkvara loomise protsessi parameetrite mõõtmisega.
  • Haldusmeetrika ja kvaliteedimeetrika
    Haldusmeetrika tulemusi kasutatakse tarkvara protsessi juhtimiseks. Haldusmeetrika on tarkvaraprotsessis kulutatud aeg, kasutatud inimpäevad, toodetud koodi maht, kulutatud raha jne. Kvaliteedimeetrika tulemusena saab hinnata tarkvara toote kvaliteeti ja omadusi. Kvaliteedimeetrika on näiteks kasutajajuhendi loetavus ja tarkvara hooldatavus.
  • Tarkvara toodet iseloomustavad parameetrid
  • Tarkvara identifikaator – määrab üheselt nime, funktsioonid, liidesed jms, mis on vajalik tarkvaratoote taaskasutamiseks
  • Tarkvara ridade arv – iseloomustab tarkvara mahtu
  • Funktsiooni punktide arv – arvestab sisendite, väljundite, päringute, failide ja välisliideste hulka vaadeldavas tarkvaratootes
  • Omaduste punktide arv – funktsiooni punktide arvule on lisatud punktid algoritmi omaduste ja kogu toote keerukuse eksperthinnangutest
  • Toodet iseloomustavad koefitsiendid
    1) nõuded tarkvaratoote töökindlusele, veakindlusele 2) nõuded andmebaasile ja andmebaasi iseloomustus 3) tarkvaratoote keerukuse hinnang
  • Realisatsiooni iseloomustavad koefitsiendid
    1) realiseerimiseks soovitatud protsessorite poolt esitatud piirangud 2) mälujaotussüsteemist tulenevate piirangute ja mälumahu poolt seatud kitsenduste mõju 3) arvutikonfiguratsiooni ja süsteemtarkvara töökindluse ja muude omaduste poolt põhjustatud täiendav risk
  • Arenduskeskkonna ja projekti meeskonna kogemust arvestavad koefitsiendid
    1) arvutite kättesaadavus meeskonna liikmetele 2) arenduskeskkonna töö stabiilsus 3)liikmete eelnev töökogemus ja üldine töövõime 4) meeskonna eelnev kogemus antud projektis kasutatavate projekteerimis- ja programmeerimisvahenditega 5) kasutatavate tarkvaratehnikavahendite efektiivsus 6) toote loomise plaani pingelisus
  • Tarkvaraprojekti tüüpilised riskifaktorid
    1) tööjõu vähesus 2) mitterealistlik tootmisplaan ja eelarve 3) valede tarkvara funktsioonide loomine 4) vale kasutajaliidese loomine 5) liigsed lubadused ja liigne enesekiitus 6) pidev nõuete muutmine 7) probleemid väljastpoolt ostetud komponentidega 8) probleemid allettevõtjatega 9) probleemid jõudlusnõuete rahuldamisega 10) töötamine teoreetilise ja tehnoloogilise piiri peal
    66. Riski mudel
    Riski mudel peab võimaldama hinnata üksikutest faktoritest põhjustatud riski ja ka koguriski suurust. Risk mudelleeritakse ebaõnnestumise tõenäosuse ja selle mõju suhtelise suuruse koosmõjuna.
    67. Riski haldamine
    Riski haldamine seisneb olulistema riskifaktorite väljavalimises ja nendest põhjustatud riskide vähendamises. Riski haldamise moodused: 1) riski vältimine 2) riski tõkestamine 3) riskiga leppimine 4) riski ülekanne 5) riski vastu valmistumine
  • Vasakule Paremale
    Sissejuhatus Reaalajatarkvaratehnikasse #1 Sissejuhatus Reaalajatarkvaratehnikasse #2 Sissejuhatus Reaalajatarkvaratehnikasse #3 Sissejuhatus Reaalajatarkvaratehnikasse #4 Sissejuhatus Reaalajatarkvaratehnikasse #5 Sissejuhatus Reaalajatarkvaratehnikasse #6 Sissejuhatus Reaalajatarkvaratehnikasse #7 Sissejuhatus Reaalajatarkvaratehnikasse #8 Sissejuhatus Reaalajatarkvaratehnikasse #9
    Punktid 50 punkti Autor soovib selle materjali allalaadimise eest saada 50 punkti.
    Leheküljed ~ 9 lehte Lehekülgede arv dokumendis
    Aeg2012-01-04 Kuupäev, millal dokument üles laeti
    Allalaadimisi 121 laadimist Kokku alla laetud
    Kommentaarid 2 arvamust Teiste kasutajate poolt lisatud kommentaarid
    Autor iku27 Õppematerjali autor
    eksami küsimuste vastused

    Sarnased õppematerjalid

    SRT Kontrolltöö vastused 2011 sügissemestril
    2
    doc

    SRT Kontrolltöö vastused 2011 sügissemestril

    alamsüsteem. Eriolukordade töötluse alamsüsteem on näide, kuidas mittefunktsionaalsed nõuded võivad segi lüüa ainult funktsionaalsete nõuete alusel projekteeritud süsteemi. Vähegi nõudlikemates rakendusvaldkondades algab eriolukordade töötlus suuremast või väiksemast süsteemtarkvara spetsialiseerimisest. Eriolukordade töötlus hõlmab endas kõike, mis on seotud vigade automaatse kompenseerimisega, valesti tehtud arvutuste korrigeerimisega, tarkvara ja riistvara diagnostikaga, rikete puhul süsteemi funktsionaalsuse muutmine jms. Näidetena välja tuua: projekteerimise etapil fikseeritakse vead rakendustarkvaras, mis detailse projekteerimise etapil tükeldatakse edasi arhitektuuriga seotud või detailse loogilise projektiga seotud eriolukordadeks, ja vigade kõrvaldamise võimalused; realiseerimise etapil fikseeritakse huvi pakkuvad vead konkreetses arvutisüsteemis ja nende kõrvaldamise võimalused. 10/10 4

    Sissejuhatus reaalajatarkvaratehnikasse
    RAS operatsioonisüsteemid - reaalajalised tuumad
    21
    pdf

    RAS operatsioonisüsteemid - reaalajalised tuumad

    RAS operatsioonisüsteemid - reaalajalised tuumad 1.Millised reaalajalised nõuded määravad RAS tarkvara koostamise eripära? RAS nõuded määravad tarkvara valmistamise eripärad (enamasti tekib sundparalleelsus): · Jõudlus tippkoormusel peab olema ennustatav · Töökiiruse juhtimine toimub ümbritsevast keskkonnast · Ohutus on sageli kriitilise tähtsusega · Andmemahud on väikesed või keskmised · Aktiivne liiasus (dubleerimine, jne) · Andmete terviklikkus nõutav lühiajaliselt · Autonoomne vigade avastamine 2.Selgitada sundparalleelsuse ja traditsioonilise paralleeltöötluse erinevusi.

    Reaalajasüsteemid
    Tarkvara kvaliteet ja standardid
    21
    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 metoodika: tulemuste kasutamine; tulemuste edasiarendamine; uute arenduste tegemine

    Tarkvara kvaliteet ja standardid
    Tarkvaratehnika 2016 2017 eksami materjal
    138
    docx

    Tarkvaratehnika 2016/2017 eksami materjal

    Tarkvaratehnika: Loeng 1:  Taust: o Tarkvara iseloom o Kõrgenenud nõudmised:  Suuremad süsteemid  Keerulisemad süsteemid  Kiiremini  Erinevad näited vigadest mis on tehtud: o Ariane Crash 1996 kosmosesüstiku alla kukkumine, tuli välja et selle alla kukkumise põhjuseks oli tarkvarasüsteemis viga ilmus trajektoori osas. o Therac-25 kiiritusravi andmises tehti viga kasutaja liideses, kus

    Tarkvaratehnika
    Tarkvaratehnika konspekt eksamiks
    62
    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
    Tarkvaraprojekti esijalgne kavandamine
    12
    doc

    Tarkvaraprojekti esijalgne kavandamine

    Projekti visioon. Enne mistahes projekti käivitamist peab projektimeeskond projekti põhieesmärgi suhtes kujundama ühised arusaamad ja need ka kirjalikult lühidalt formuleerima. Põhieesmärk peab olema kõrge, kuid reaalne. Halvim on, kui projekti täitjad saavad aru eesmärkide ebareaalsusest, kuid projekti juhtkond mitte; sellisel juhul täitjate motivatsioon langeb kiiresti. Visioonist peaks lähtuma, määratlemaks, mida loodav tarkvara peab võimaldama ja mida mitte. Näiteks MS Word for Windows 1.0 arendamine võttis algselt kavandatud ühe aasta asemel aega viis aastat, kuna eesmärgid olid seatud liiga kõrged! Seega on näiteks "Luua maailma parim tekstitöötlussüsteem" liiga üldine, parem oleks "Luua maailma kõige kasutajasõbralikum tekstitöötlussüsteem", kuna annab arendajatele ka ideid, mida ei peaks tarkvara koosseisu lülitama. Põhiotsustaja määratlemine

    Projektijuhtimine
    Tarkvaratehnika konspekt ja kordamisküsumused 2016-2017
    24
    docx

    Tarkvaratehnika konspekt ja kordamisküsumused 2016-2017

    KORDAMISKÜSIMUSED 1. Kvaliteetse tarkvara atribuudid. eksam 2. Mis on tarkvaratehnika? 3. Üldistatud protsessid tarkvaraarenduses. 4. Tarkvaraprotsesside 2 suuremat liiki. 5. Manifesto for Agile Software Development. 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

    Tarkvaratehnika
    Tarkvaratehnika kordamisküsimused
    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




    Kommentaarid (2)

    IndrekT profiilipilt
    IndrekT: üsna põhjalikult vastatud!
    08:15 28-03-2016
    Oneiros profiilipilt
    Gerd Kukemilk: Väga kena konspekt
    22:12 17-11-2012



    Sellel veebilehel kasutatakse küpsiseid. Kasutamist jätkates nõustute küpsiste ja veebilehe üldtingimustega Nõustun