Šperos
Programų sistemų inžinerija
1. Kokie yra svarbiausieji inžinerijos ir amato skirtumai? (3) Programų sistemos inžinerija skiriasi nuo amato tuo, kad nusako, kokia tvarka, kuo remiantis ir kokius sprendimus reikia priimti projektuojant ir konstruojant programų sistemas. Programų sistemų inžinerija - teorinis pramoninio programavimo pagrindas. Tai inžinerinė disciplina, įgalinanti kurti programų sistemas, tenkinančias iš anksto nustatytus apribojimus. Kaip ir kiekviena inžinerinė disciplina, ji skiriasi nuo amato tuo, kad nusako, kokia tvarka, kuo remiantis ir kokius sprendimus reikia priimti projektuojant ir konstruojant programų sistemas. Amatas: 1)Gaminio kokybę lemia amatininko talantas, patirtis ir sąžiningumas. 2) Kurdamas gaminį, amatininkas sprendimus priima intuityviai. Jis paprastai nežino, kokia tvarka, kuo remiantis ir kokie sprendimai buvo priimti. 3) Amato mokomasi dirbant su patyrusiu meistru, žiūrint kaip jis dirba, vykdant jo užduotis, gaunant patarimus ir pamokymus (pameistrių institutas). Inžinerija: 1) Gaminio kokybė ir kiti ribojimai nustatomi, remiantis ekonominio tikslingumo kriterijais. Jie fiksuojami reikalavimų specifikacija ir sandoriu (kontraktu). 2) Kokia tvarka, kuo remiantis ir kokius sprendimus reikia priimti nustato atitinkama inžinerinė disciplina. 3) Inžinerinę disccipliną galima aprašyti, todėl ją galima studijuoti skaitant atitinkamą literatūrą. Tačiau vien teorinių žinių inžinieriui nepakanka. Jam reikia taip pat ir praktinių įgūdžių, kuriuos galima įgyti tik kartu su "patyrusio meistru" atliekant praktines užduotis. Baigdami pastebėsime, kad programų sistemų inžinerija - tai naujo tipo inžinerinė disciplina, atsiradusi jungiant technikos, matematikos ir socialinių mokslų pasiekimus. 2. Kas vadinama “programavimo krize”? Kokios yra jos apraiškos? Trumpai apibūdinkite juos. (5) Buvo manoma, kad vienintelė programavimo problema – uždavinių algoritmizavimas. Visi kiti sunkumai esą kyla dėl nepakankamo kompiuterių galingumo. Tačiau techninė pažanga programavimo problemų ne tik kad neišsprendė, bet ir sukūrė nemažai naujų problemų ir visų pirma jos pačios produkto panaudojimo problemą – kilo programavimo krizė, kuri pasireiškė trimis pagrindiniais aspektais: 1) augančiomis sąnaudomis programų sistemoms kurti ir prižiūrėti: programinės įrangos: programinės įrangos tiražavimo, diegimo, modernizavimo bei priežiūros sąnaudos savo ruožtu pradėjo gerokai viršyti jos kūrimo sąnaudas. Svarbiausios priežastys, lemiančios tokią padėtį: standartizacijos stoka, žemas programavimo darbų automatizavimo laipsnis, nekokybiška projektinė dokumentacija ir netinkamas projekto valdymas; 2) nuolatiniu planuotų terminų žlugdymu: retas programinis projektas buvo baigiamas laiku. Vėluodavo eksplotavimo dokumentacija, daug laiko praeidavo nuo sistemos sukūrimo iki jos įdiegimo, todėl kartais sistema pasendavo ankščiau, nei būdavo baigiama; 3) programų naudotojų reiškiamu nepasitenkinimu, dėl gaunamos programinės įrangos kokybės: vartotojai dažnai gaudavo programinę sistemą, kuri būdavo visai ne tokia, kokią ją įsivaizdavo vartotojas. Tai irgi lėmė blogas planavimas, žemas darbo našumas, naudojamų technologijų neefektyvumas, netikę darbo organizavimo būdai. Antrinė programavimo krizės apraiška – dėl mažo darbo našumo labai išaugo programuotojų skaičius. 3. Kokie yra svarbiausieji pramoninio programavimo ypatumai? Trumpai apibūdinkite juos. (5) 1) Aukštas darbų automatizavimo lygis. Siekiant padidinti programuotojų darbo našumą, buvo pradėtos kurti programavimo automatizavimo priemonės. Tačiau tradicinės automatizavimo priemonės (transliatoriai, redaktoriai ir kt.) palengvina tik programų rašymą, todėl norint pasiekti aukštą automatizavimo lygį, reikia papildomai automatizuoti ir programos projektavimą, dokumentavimą bei daugelį kitų darbų. 2) Serijinė gamyba. Norint pereiti prie serijinio programų gaminimo būdo, reikia atsisakyti unikalių sistemų pagal individualius užsakymus kūrimo ir persiorentuoti į abstraktaus, statistinio vartotojo poreikius. Tiražuoti dideliu egzempliorių skaičiumi galima tik tas sistemas, kurios tenkina didelės vartotojų klasės poreikius. 3) Kokybės planavimas. Kadangi serijinė gamyba neįmanoma be kokybės planavimo, todėl leistiną programos klaidų skaičių, jos patikimumą, naudojimo patogumą bei kitus kokybinius parametrus pradėta reglamentuoti technine užduotimi. 4)Produkto nuasmeninimas. Sistemos ir atskirų jos modulių struktūrą, realizavimo metodus bei apipavidalinimą turi lemti standartai, o ne atskirų programuotojų kvalifikacija ar skonis. 5)Planingas gamybos pobūdis. Programinio produkto gamyba turi būti reguliuojama atsižvelgiant į ekonominio tikslingumo kriterijus. 4. Kokius komponentus reikia sukurti, kuriant programų sistemą? Ką reikia padaryti, kad sukurtų komponentų rinkinys taptų sistema? (1) Komponentai: programos, failai, duomenų bazės, žinių bazės, protokolai, interfeisai. PS – integruota šių komponentų visuma, skirta tam tikros klasės uždaviniams spręsti ar tam tikriems įrenginiams (procesams) valdyti. Būtina PS dalis – naudojimo instrukcijos. 5. Kas svarbiau: klaida programoje ar jos naudojimo instrukcijoje? (1) Programų sistemos naudotojui nėra jokio skirtumo ar padaryta klaida pačiose programose, ar programų sistemos dokumentacijoje. Abiems atvejais rezultatas yra tas pats: arba programų sistema apskritai neveikia, arba ji veikia ne taip, kaip numatyta jos reikalavimų specifikacijoje. 6. Kokiais aspektais galima nagrinėti programų sistemą, ją kuriant? (1) Kuriant programų sistemas, jas būtina nagrinėti dviem skirtingais požiūriais: išoriniu ir vidiniu. Pirmuoju atveju nagrinėjamos jos vykdomos funkcijos, elgsena ir kitos iš išorės stebimos savybės. Tai - sistemos naudotojų požiūris į sistemą. Antruoju atveju nagrinėjama jos architektūra. Tai - sistemos kūrėjų (projektuotojų, programuotojų ir pan.) požiūris į sistemą. 7. Kas nusako išorinę programų sistemos elgseną? Kas nusako vidinę programų sistemos elgseną? (1) Išorinis aspektas: Nagrinėjamos tos programų sistemos savybės, kurias galima stebėti iš jos išorės: funkcijos, elgsena, interfeisas, patikimumas ir pan. Šitaip į sistemą žiūri jos užsakovai, reikalavimų specifikaciją rengiantys analitikai, naudotojai ir ją aptarnaujantis bei prižiūrintis personalas. Aprašant sistemos išorinį aspektą, ji aprašoma kaip vadinamoji juodoji dėžė. Vidinis aspektas: Nagrinėjamos tos programų sistemos savybės, kurias galima stebėti tik iš jos vidaus: architektūra, architektūros įgyvendinimo būdas, sistemos veikimas ir pan. Šitaip į sistemą žiūri jos projektuotojai, programuotojai ir kiti ją kuriantys asmenys. Aprašant sistemos vidinį aspektą, ji aprašoma kaip vadinamoji perregimoji dėžė. Perregimosios dėžės aprašai (eskizinis projektas, detalusis projektas ir kt.) sudaro programų sistemos projektinę dokumentaciją. 8. Kas vadinama programų sistemos architektūra? Koks santykis sieja programų sistemos architektūrą ir tos sistemos eskizinį projektą? Kas vadinama eskiziniu programų sistemos projektavimu? Kas vadinama detaliu programų sistemos projektavimu? (1) Programų sistemos architektūra vadinamas jos sudėtinių dalių (konstrukcinių elementų) sujungimo būdas. Programų sistemos architektūros aprašas nusako sistemos konstrukcinius elementus, jų vykdomas funkcijas, sąveikos būdus ir juos siejantį konstrukcijos santykį. Sistemos architektūros aprašas yra vadinamas jos eskiziniu projektu. Eskiziniu projektavimu vadinamas kuriamosios programų sistemos funkcinės, modulinės, duomenų ir interfeiso architektūrų projektavimo procesas. Dokumentas, kuriame aprašomi eskizinio projektavimo metu priimti projektiniai sprendimai, pateikiami tų sprendimų motyvacija ir eskizinio projektavimo rezultatai, vadinamas programų sistemos eskiziniu projektu. Detaliuoju programų sistemos projektavimu yra vadinamas architektūrinių programų sistemos komponentų vidinės struktūros ir logikos (veikimo algoritmų) projektavimas. Dokumentas, kuriame aprašomi projektiniai sprendimai, priimti detalaus projektavimo metu, pateikiami tų sprendimų motyvacija ir detaliojo projektavimo rezultatai, vadinamas detaliuoju programų sistemos projektu. 9. Kas vadinama programų sistemos funkcine architektūra? Kokie yra funkcinės architektūros aprašymo metodai? (1) Funkcine programų sistemos architektūra vadinama pasirinktuoju konstrukcijos santykiu susieta sistemos vykdomų funkcijų visuma. Funkcinė programų sistemos specifikacija nusako sistemos vykdomas funkcijas, tų funkcijų paskirtį ir jų tarpusavio sąveikos būdus. Funkcinė architektūra projektuojama techninės užduoties pagrindu. Sudarant funkcinę specifikaciją, formalizuojami ne tik funkciniai, bet ir kiti techninėje užduotyje pateikti reikalavimai. Jie performuluojami funkcinės architektūros terminais. Techninės užduoties formalizavimas yra gana imlus darbas. Tačiau daugumos specialistų nuomone, sudėtingesnėms programų sistemoms sugaištas laikas atsiperka, nes taip yra gerokai sumažinamos išlaidos klaidoms sukurtose programose šalinti ir komponentams į vieną visumą integruoti. Aprašoma vykdomos funkcijos, jų paskirtis ir tarpusavio sąveika, funkcijų hierarchija. 10. Kas vadinama programų sistemos moduline architektūra? Kokie yra modulinės architektūros aprašymo metodai? (1) Moduline programų sistemos architektūra vadinamas jos suskaidymo į modulius ir tų modulių sujungimo būdas. Modulinė architektūra nusako modulinę sistemos struktūrą, tarpmodulinius interfeisus ir modulių sąveikos būdus. Projektuojant modulinę programų sistemos architektūrą, reikia: 1) suskaidyti sistemą į modulius, t.y. nustatyti, kokie moduliai kokias sistemos funkcijas turi įgyvendinti, 2) nustatyti kiekvieno modulio interfeisą, 3) nustatyti tarpmodulinius ryšius, t.y. nustatyti kokie moduliai kokius kitus modulius ir kokiu būdu aktyvuoja, 4) aprašyti suprojektuotą modulinę architektūrą kokia nors projektavimo kalba. Modulinė architektūra projektuojama funkcinės architektūros pagrindu. Tikslas - supakuoti funkcijas į modulius. Dažniausiai elementarios (žemiausio jos lygmens) funkcijos realizuojamos savarankiškais moduliais, bet kartais, atsižvelgiant į efektyvumo ar kitus reikalavimus, tas funkcijas tenka jungti arba skaidyti. Modulinės architektūros parinkimas daro didelę įtaką programavimui ir atvirkščiai, vienos ar kitos programavimo kalbos arba programų kodavimo technikos parinkimas gali nulemti pagrindinius modulinės architektūros bruožus. Moduliarizavimo būdas taip pat priklauso nuo operacinės aplinkos, kurioje funkcionuos kuriamoji programa. Universalių receptų kaip moduliarizuoti sistemą nėra ir projektavimo rezultatų kokybę didele dalimi lemia projektuotojo sugebėjimai bei jo praktinė patirtis. 11. Kas vadinama programų sistemos duomenų (duomenų bazių) architektūra? Kokie yra jos aprašymo metodai? (1) Duomenų bazės architektūra yra vadinama loginė bazės struktūra. Duomenų bazės architektūra nusako is kokių dalių (segmentų, lentelių ir pan.) yra sudaryta bazė ir kokiu konstrukcijos santykiu tos dalys yra jungiamos viena su kita. Duomenų bazės architektūra aprašoma naudojant specialiai tam skirtas kalbas. Projektuojant reliacines duomenų bazes, esybės ir ryšiai dažnai gali būti vaizduojami savarankiškomis lentelėmis, bet taip yra toli gražu ne visada. Atsižvelgiant į patikimumo reikalavimus, lenteles tenka normalizuoti. Jos taip pat gali būti keičiamos ir dėl našumo, duomenų išskirstymo, sąveikos su kitomis sistemomis bei kitų reikalavimų. Be to, kartais lentelės arba jų stulpeliai gali būti virtualizuojami, t.y. saugomi juos generuojančių procedūrų pavidalu. Projektuojant duomenų bazės architektūrą, būtina numatyti jos audito ir kontrolės priemones bei priemones, skirtas duomenų bazei atkurti po avarinių situacijų. Duomenų bazėje taip pat turi būti numatytos duomenų paieškos (indeksai ir pan.) bei skirtingų naudotojų grupių turimų dalykinės srities įvaizdžių įgyvendinimo priemonės. 12. Kas vadinama programų sistemos architektūros stiliumi? (2) PS architektūros stiliumi vadinamas ketvertas ArchSt = , kur δ – leistini ps dalių tipai (struktūriniai primityvai), η – leistini sistemos dalių jungčių tipai (primityvieji konstruktoriai), ω – leistini konstrukcijos santykiai (aukštesnės eilės konstruktoriai), γ – sistemos veikimo semantiką nusakantys ribojimai. Architektūros stilius aprašomas išvardijant ^ anuos. Populiariausieji stiliai: valdymo srautų, duomenų srautų, objektinis, įvykiais valdomas, sluoksninis, lentelėmis valdomas, saugyklos, pandemoniumo 13. Valdymo srautų stiliaus architektūros. (5) Vald. srautų stiliaus arch. sukurtos pgl. Neumano pasiūlytos kompiuterių architektūros pavyzdį. PS architektūra yra valdymo srautų stiliaus architektūra, jei atliekant užduotis, operacijos vykdomos viena po kitos valdymo srauto nustatyta tvarka. Tokiose arch. naudojami ne mažiau kaip 2 tipų struktūriniai primityvai – valdantieji moduliai ir apdorojantieji moduliai. Kartu su jais gali būti naudojami failai, db ir kt. Imp. arch. ps valdomos komandomis, t.y. nurodant, ką sistema turi daryti. Komandas galima duoti įvairiai: paspaudus klavišą klaviatūroje, pasirinkus meniu punktą ir pan.(kartais komandos gali būti paslėptos, duodamos neišreikštiniu būdu). Reaktyviosios arch. ps valdomos duomenimis. Analizuodama įvesties duomenis, sistema vertina jais aprašytą situaciją ir reaguoja į tą situaciją, priimdama sprendimą atlikti vienus ar kitus veiksmus. Šitaip veikia, pvz., transakcijų apdorojimo sistemos. 14. Duomenų srautų stiliaus architektūros. (5) PS arch. yra duomenų srautų stiliaus arch., jei, atliekant užduotis, operacijų vykdymo tvarką nustato duomenų srautai ir operacijos vykdomos tuomet, kai srautu ateina joms įvykdyti reikalingi duomenys. Duom. sr. stiliaus arch. yra neprocedūrinės. Tipiškas pavyzdys – vamzdžių ir filtrų stiliaus arch. Metafora: vamzdžiais teka duomenų srautai. Jie yra filtruojami. Filtrai turi įvesties ir išvesties lizdus. Duomenų srautai patenka į filtrą per įvesties lizdus ir perfiltruoti išteka per išvesties lizdus. Filtrų išvesties lizdai jungiami vamzdžiais su kitų filtrų įvesties lizdais. Pradinis srautas teka ne iš filtro, o iš kokio nors duomenų šaltinio (failo, klaviatūros,..). Vamzdyno gale srautas suteka į kokį nors duomenų imtuvą (komp. Ekraną, spausdintuvą, failą).Atskiru atveju srauto šaltinis ir jo imtuvas gali sutapti. Sakoma, kas ps arch. yra vamzdžių ir filtrų stiliaus arch., jei ji tenkina šias sąlygas: 1. Sistema sukonstruota iš trijų tipų primityvų: duomenų šaltinių, duomenų imtuvų ir filtrų, 2. Sistemai konstruoti naudotos vienintelės jungtys – vamzdžiai, 3. Vamzdyno konstrukcija aprašoma orientuotu grafu su ciklais, 4. Sistema veikia pakaitomis atlikdama duomenų srauto perdavimo iš filtro į filtrą ir filtravimo operacijas, 5. Bet kuri filtravimo operacija aprašoma baigtine būsenų mašina. 15. Kas vadinama programų sistemos problemine sritimi? (1) Probleminė sritis: (angl. Problem domain) Programų sistemos problemine sritimi vadinama jos sprendžiamų uždavinių visuma. 16. Kokios programų sistemos vadinamos specialios probleminės paskirties programų sistemomis? (1) Šiuolaikinės programų sistemos dažniausiai taip kūriamos, kad jomis galėtų be tarpininkų naudotis dalykinės srities specialistai. Tokios sistemos vadinamos specialios arba dalykinės paskirties sistemomis. 17. Kas vadinama programų sistemų inžinerija? (1) Mokslinis aspektas: Kaip inžinerijos mokslo šaka, programų sistemų inžinerija nagrinėja, kaip apskritai reikia spręsti įvairias programų sistemų kūrimo, aptarnavimo bei priežiūros problemas ir kokių priemonių (instrumentų) tam reikia. Praktinis aspektas: Kaip praktinės inžinerijos šaka, programų sistemų inžinerija naudojama konkrečioms programų sistemoms kurti, aptarnauti bei prižiūrėti. Programų sistemų inžinerijos apibrėžtis: Programų sistemų inžinerija vadinama sistemų inžinerijos šaka, nagrinėjanti pramoninio programų sistemų kūrimo priemones (metodus, instrumentus, kalbas, procedūras) bei veiksmingus jų naudojimo būdus. 18. Kokios yra programų sistemų inžinerijos pagrindinės dalys? (1) Pagrindinės programų sistemos inžinerijos dalys yra šios: 1) reikalavimų inžinerija, 2) programų inžinerija, 3) interfeiso inžinerija, 4) duomenų bazių inžinerija, 5) žinių inžinerija, 6) programų sistemų architektūra, 7) programų sistemų kūrimo projektų valdymas, 8) programų sistemų kokybės vertinimas ir valdymas, 9) instrumentinių sistemų teorija, 10) programų sistemų deigimas ir priežiūra. 19. Ką nagrinėja reikalavimų inžinerija? Kokios yra jos pagrindinės dalys? (1) Reikalavimų inžinerija nagrinėja, kaip turi būti rengiami ir pateikiami funkciniai, kokybės ir kiti kuriamos sistemos reikalavimai. Pagrindinės reikalavimų inžinerijos dalys yra dalykinės srities sisteminė analizė, koncepcinis modeliavimas ir reikalavimų analizė. Pastebėsime, kad sisteminė analizė ir sistemų analizė yra skirtingi dalykai ir jų nevalia painioti. Pirmuoju atveju kalbama apie analizės metodą, o antruoju - apie jos objektą. Dalykinės srities sisteminė analizė yra specifinė bendrosios sisteminės analizės rūšis. Bendroji sisteminė analizė nagrinėja, kaip taikyti sisteminį požiūrį analizuojant bet kokios prigimties reiškinius. Tai labai bendra mokslo šaka. Dalykinės srities sisteminė analizė nagrinėja metodus, instrumentus bei kitas priemones dalykinės srities analizei atlikti. Šias priemones įvaldęs specialistas vadinamas sisteminiu analitiku. Dalykinės srities sisteminė analizė atliekama siekiant ištirti dalykinės srities specialistų poreikius ir suformuluoti kuriamos sistemos reikalavimus. Analizės rezultatai fiksuojami vadinamojoje reikalavimų specifikacijoje. Reikalavimų specifikacija vadinamas dokumentas, kuriame išsamiai aprašoma, kokioms užduotims vykdyti yra skirta kuriamoji sistema ir kokios turi būti kitos jos pageidaujamos savybės. Koncepcinis modeliavimas nagrinėja dalykinės srities koncepcinio modeliavimo metodus ir priemones. Dalykinės srities koncepcinis modelis sudaromas rengiant specifikaciją. Modeliams aprašyti naudojamos specialiai tam tikslui skirtos kalbos, vadinamos koncepcinio modeliavimo kalbomis. Dalykinės srities koncepciniai modeliai naudojami sisteminiams analitikams, užsakovams ir sistemos projektuotojams tarpusavyje aptariant kompiuterizuojamos dalykinės srities ypatumus ir yra konstruojami taip, kad juos pagal tam tikras taisykles būtų galima transformuoti į kuriamų sistemų koncepcinius modelius. Būtent tuo koncepciniai modeliai, nagrinėjami reikalavimų inžinerijoje, skiriasi nuo koncepcinių modelių, nagrinėjamų dirbtinio intelekto teorijoje. Norint transformuoti dalykinės srities koncepcinį modelį į kuriamos programų sistemos koncepcinį modelį ir parengti tos sistemos specifikaciją, reikia išnagrinėti tos sistemos reikalavimus. Tai - reikalavimų analizės objektas. Kartais reikalavimų analizė dar yra vadinama sistemos analize. 20. Kas tai yra sistemų analizė? Ką ji nagrinėja? Koks pagrindinis sistemų analizės tikslas? (1) Sistemos analizė - tai sistemos skaidymo į sudėtines dalis procesas, vykdomas siekiant suvokti analizuojamosios sistemos savybes. Sistemų analizė nagrinėja sistemas. Pagrindinis jos tikslas – suvokti analizuojamos sistemos savybes. Analizės samprata universali. Tačiau kiekviena sistemų klasė paprastai turi tam tikrų tik jai būdingų ypatumų, todėl jos analizės metodai taip pat yra specifiniai. Programų sistemų inžinerijoje nagrinėjami dalykinių sričių ir programų sistemų analizės metodai. Pastebėsime, kad sisteminė analizė ir sistemų analizė yra skirtingi dalykai ir jų nevalia painioti. Pirmuoju atveju kalbama apie analizės metodą, o antruoju - apie jos objektą. 21. Kaip vadinamas dokumentas, aprašantis kuriamos programų sistemos paskirtį ir jos pageidaujamas savybes? (1) Ikiprojektiniai tyrimai atliekami dalykinės srities analizės metu. Priklausomai nuo to, kokie dokumentavimo standartai yra naudojami, jų rezultatai gali būti pateikti viename ar keliuose dokumentuose. Lietuvoje ikiprojektinių tyrimų rezultatai dažniausiai yra aprašomi specialiai tam skirtuose dokumento, vadinamo technine užduotimi sistemai sukurti, skyriuose. Reikalavimų specifikacija. 22. Kuo skiriasi koncepciniai modeliai, nagrinėjami programų sistemų inžinerijoje, nuo koncepcinių modelių, nagrinėjamų dirbtinio intelekto teorijoje? Kam programų sistemų inžinerijoje naudojamas koncepcinis modeliavimas? (1) Koncepcinis modeliavimas nagrinėja dalykinės srities koncepcinio modeliavimo metodus ir priemones. Dalykinės srities koncepcinis modelis sudaromas rengiant specifikaciją. Modeliams aprašyti naudojamos specialiai tam tikslui skirtos kalbos, vadinamos koncepcinio modeliavimo kalbomis. Dalykinės srities koncepciniai modeliai naudojami sisteminiams analitikams, užsakovams ir sistemos projektuotojams tarpusavyje aptariant kompiuterizuojamos dalykinės srities ypatumus ir yra konstruojami taip, kad juos pagal tam tikras taisykles būtų galima transformuoti į kuriamų sistemų koncepcinius modelius. Būtent tuo koncepciniai modeliai, nagrinėjami reikalavimų inžinerijoje, skiriasi nuo koncepcinių modelių, nagrinėjamų dirbtinio intelekto teorijoje. DS koncepciniai modeliai, naudojami PSI skiriasi tuo, kad jie gali būti transformuojami į kuriamos PS koncepcinius modelius. Pagrindinė reikalavimų verifikavimo ir vertinimo problema tai analitikų, užsakovų, naudotojų, dalykinės srities ekspertų ir projektuotojų tarpusavio bendravimas. Gana dažnai užsakovai, naudotojai ir dalykinės srities ekspertai nesupranta šio proceso svarbos ir nenori jame dalyvauti. Be to, labai sunku parengti konkretų, formalų ir kartu visiems suinteresuotiems asmenims lengvai suprantamą dokumentą. Koncepcinis modeliavimas - pirmasis programų sistemos reikalavimų formalizavimo žingsnis. Pagal tradiciją koncepcinis modeliavimas priskiriamas dalykinės srities analizės stadijai, nors jį būtų galima laikyti ir pirmuoju projektavimo stadijos etapu. Taip esti dėl to, kad koncepcinis modelis kartais yra konstruojamas reikalavimams verifikuoti ir vertinti. Vadinasi, griežtos ribos tarp atskirų programų sistemos gyvavimo ciklo stadijų nėra. Kiekvienu konkrečiu atveju jos turi būti konstruojamos iš bazinių technologinių procesų savaip, atsižvelgiant į konkrečius vykdomo projekto ypatumus. Koncepcinis modeliavimas ir yra vienas iš tų bazinių technologinių procesų. 23. Kas vadinama programų inžinerija? Kuo programų inžinerija skiriasi nuo programų sistemų inžinerijos? (1) Programų inžinerija nagrinėja programų projektavimo ir konstravimo problemas, instrumentus bei priemones. Svarbiausios projektavimo problemos yra geriausio kuriamos programos reikalavimų įgyvendinimo būdo parinkimas ir dokumentavimas kokia nors specialiai tam skirta programų projektavimo kalba. Programos projektavimas - tai kuriamos programos specifikacijos įgyvendinimo būdo parinkimas ir to būdo modeliavimas specialiai tam skirta kalba (programų projektavimo kalba). Programos įgyvendinimo būdas modeliuojamas specifikuojant jos išorinius ir vidinius interfeisus, valdymo mechanizmus bei kitus programos konstrukdnius elementus. Programos konstravimas - tai jos specifikacijos įgyvendinimas projektavimo metu parinktu būdu. Konstruojant programą, koduojami ir jungiami į vieną visumą jos moduliai. Svarbiausios programų konstravimo problemos yra tinkamos programavimo kalbos parinkimas, modulių teksto struktūrizavimas ir apipavidalinimas bei konstruojamos programos konfigūracijos valdymas. Pagrindiniai objektai, sukuriami procesais, naudojamais kuriant programų sistemas, yra šie: 1) ikiprojektinių tyrimų rezultatai (poreikių specifikacijos, tikslų specifikacijos ir pan.), 2) techniniai sistemos aprašai (specifikacijos, projektinė dokumentacija, kodas, naudojimo instrukcijos ir pan.), 3) sistemos mazgai (moduliai, failai, bazės, posistemiai ir pan.), 4) sistemos distributyvinės versijos, 5) funkcionuojančios sistemos, 6) pagalbinė medžiaga (planai, užduotys, ataskaitos, testai, testavimo užduotys, testavimo rezultatai ir pan.). Programų sistemų inžinerija nagrinėja šių objektų struktūrą, jų apipavidalinimo standartus ir kitus panašaus pobūdžio klausimus. PI yra PSI dalis. 24. Kokius klausimus nagrinėja duomenų inžinerija? Kokius klausimus nagrinėja žinių inžinerija? (1) Duomenų inžinerija nagrinėja duomenų bazių bei failų sistemų projektavimo problemas. Ši programų sistemų inžinerijos šaka taip pat nagrinėja metodus, instrumentus ir kitas priemones, skirtas duomenų bazėms projektuoti bei konstruoti. Pagrindinės duomenų bazių bei failų sistemų projektavimo problemos yra našumo, patikimumo bei darnos įgyvendinimas ir perteklinių duomenų eliminavimas. Žinių inžinerija nagrinėja žinių bazių projektavimo problemas. Ši programų sistemų inžinerijos šaka taip pat nagrinėja metodus, instrumentus ir kitas priemones, skirtas žinių bazėms projektuoti bei konstruoti. Pagrindinės problemos yra panašios į duomenų inžinerijos problemas. Specifinė problema – kaip išgauti iš ekspertų žinias ir jas panaudoti. 25. Kas vadinama projekto valdymu? Kas sudaro kokybės valdymo esmę? (1) Projektų valdymas. Terminas "projektas" programų sistemų inžinerijoje vartojamas dviem prasmėm: pirmoji - tai dokumento, aprašančio projektavimo rezultatus, pavadinimas, antroji -programų sistemos kūrimo proceso pavadinimas. Kai kalbama apie projektų valdymą, omeny turima antroji termino prasmė. Projektų, skirtų programų sistemoms kurti, valdymo metodai ir priemonės yra panašūs į kitų inžinerinių projektų valdymo metodus bei priemones. Pagrindinis jų tikslas - taip struktūrizuoti sistemos kūrimo procesą, kad jis būtų suskaidytas į lengvai kontroliuojamas ir valdomas dalis. Siekiama, kad bet kuriuo laiko momentu būtų galima įvertinti tai, kas jau yra padaryta, nustatyti, ar neatsiliekama nuo numatytų terminų ir ar nėra sunaudota daugiau lėšų, negu buvo numatyta. Pažymėtina, kad kokybės ir konfigūracijos valdymas taip pat yra sudėtinės projekto valdymo dalys Kokybės valdymo esmę sudaro kokybės standartų parinkimas, tų standartų diegimas ir jų vykdymo kontrolė. Einamoji kuriamosios programų sistemos versija ir jos kūrimo procesas turi būti nuolat kontroliuojami, visi nukrypimai nuo pasirinktųjų standartų turi būti fiksuojami ir nedelsiant šalinami. Kokybei matuoti reikalingos atitinkamos metrikos, matavimo priemonės ir metodai. Pagrindinis PS kokybės matavimo būdas- testavimas. 26. Ką nagrinėja instrumentinių sistemų teorija? (1) Instrumentinių sistemų teorija nagrinėja priemones skirtas PS kūrimo palengvinimui. (Dokumentatoriai, projektų bazių tvarkymo priemonės, kompiliatoriai, programų generatoriai) ir jų jungimo į vieną instrumentinę sistemą būdus. Norint palengvinti programų sistemų kūrimą, tikslinga įvairius kompiuterinius instrumentus (dokumentatorius, projektavimo bazių tvarkymo priemones, kompiliatorius, testavimo priemones ir pan.), naudojamus programoms projektuoti, konstruoti, testuoti bei kitiems darbams atlikti, jungti į vieną instrumentinę sistemą. Instrumentai dažniausiai jungiami pasirinktojo programų sistemos gyvavimo ciklo arba pasirinktojo projektavimo metodo nusakomu būdu. Svarbus tokių sistemų komponentas yra automatinio programavimo sistemos, kartais dar vadinamos programų generatoriais. Automatinio programavimo sistemos yra skirtos kuriamoms programoms generuoti. Programos tokiose sistemose yra generuojamos žingsnis po žingsnio transformuojant kuriamosios sistemos specifikaciją į atitinkamų programų tekstus. Dažniausiai programos yra surenkamos iš anksčiau parengtų modulių arba kitų konstrukcinių elementų. Todėl toks programų konstravimo būdas dar yra vadinamas struktūrine sinteze arba surenkamuoju programavimu. Transformacijos parenkamos taip, kad būtų išsaugotas transformuojamojo objekto korektiškumas. Tai reiškia, kad iš teisingos specifikacijos visuomet bus sugeneruota teisinga programa. Generatorių darbą paprastai valdo projektuotojas. Jei reikia, jis gali patikslinti specifikacijas ir parengti geriausiai tinkančius jų įgyvendinimo būdus. 27. Kokie darbai vykdomi, vykdant programų sistemos priežiūrą? Kas vadinama programų sistemos parengimu darbui, aptarnavimu, modernizavimu ir demontavimu? (1) Priežiūros metu PS pritaikoma pakitusiems poreikiams, techniniai įrangai, taip pat tikrinamas funkcionalumas, šalinami trikiai, keičiama konfigūracija ir pan. Turi būti atliekama taip, kad sistema nuolat būtų tinkama naudotis. Tam, kad sistema būtų parengta darbui, reikia ją instaliuoti, patikrinti kaip ji veikia, suformuoti reikiamas duomenų bazes ir atlikti kitus darbus. Sistemos parengimo darbui procesą nagrinėja programų sistemų inžinerijos šaka, vadinama sistemų diegimu ir priežiūra. Ji taip pat nagrinėja ir sistemos aptarnavimo, modernizavimo bei demontavimo procesus. Šie procesai apibrėžiami šitaip: Sistemos parengimas darbui - tai sistemos veikimui reikalingų resursų akumuliavimo ir jos adaptavimo konkrečiai darbo vietai procesas. Sistemos aptarnavimas - tai specifikacijoje numatytos sistemos elgsenos palaikymo procesas. Sistemos modernizavimas - tai veikiančios sistemos vidinės arba išorinės elgsenos modifikavimo procesas. Sistemos demontavimas - tai laipsniškas vienos veikiančios sistemos funkcijų perdavimo kitai veikiančiai sistemai procesas. Perduodant senos sistemos funkcijas naujai sistemai, kuria ji yra keičiama, senoji sistema palaipsniui demontuojama. 28. Kas programų sistemų inžinerijoje vadinama baziniu procesu? Kokie baziniai procesai naudojami programų sistemų inžinerijoje? (1) Baziniais procesais programų sistemų inžinerijoje yra vadinami tokie procesai, be kurių negali būti sukurtos ir panaudotos programų sistemos. Skiriami šie baziniai procesai: 1) analizė, 2) specifikavimas, 3) projektavimas, 4) programavimas, 5) surinkimas, 6) parengimas darbui, 7) aptarnavimas, 8) modernizavimas, 9) demontavimas. 29. Kas programų sistemų inžinerijoje vadinama pagalbiniu procesu? Kokie pagalbiniai procesai naudojami programų sistemų inžinerijoje?(1) Pagalbiniais procesais programų sistemų inžinerijoje yra vadinami procesai, skirti bazinių procesų vykdymui palengvinti ir padedantys užtikrinti jų sėkmę. Pagrindiniai pagalbiniai procesai yra šie: 1) testavimas, 2) verifikavimas, 3) vertinimas, 4) dokumentavimas, 5) konfigūracijos valdymas, 6) peržiūra, 7) inspektavimas, 8) problemų sprendimas. 30. Kas programų sistemų inžinerijoje vadinama organizaciniu procesu? Kokie organizaciniai procesai naudojami programų sistemų inžinerijoje? (1) Organizaciniais procesais programų sistemų inžinerijoje yra vadinami procesai, skirti organizacinėms struktūroms, kuriančioms programų sistemas, sukurti ir palaikyti. Pagrindiniai organizaciniai procesai yra šie: 1) valdymas, 2) infrastruktūros kūrimas ir palaikymas, 3) procesų vykdymas, 4) apmokymas. 31. Kas vadinama programų sistemos specifikavimu? Kokie yra programų sistemos specifikavimo būdai? (1) Sistemos specifikavimas - tai iš išorės stebimos sistemos elgsenos modeliavimo procesas. Šios apibrėžtys tinka bet kokioms sistemoms, tačiau kiekviena konkreti sistemų klasė dažniausiai turi ir savitų, tik jai būdingų ypatumų. Todėl kiekvienos sistemų klasės analizės ir specifikavimo metodai taip pat yra specifiniai. Programų sistemų inžinerija nagrinėja dalykinių sričių ir programų sistemų analizės bei specifikavimo procesų ypatumus. Programų sistemos gali būti specifikuojamos natūraliosiomis arba specialiai tam skirtomis formaliosiomis kalbomis. Kai kurioms formalioms kalboms yra sudaryti jų interpretatoriai. Tada sakoma, kad mes turime vykdomą specifikaciją. Kartais programų sistemoms specifikuoti yra naudojami jų prototipai arba maketai. 32. Kas vadinama programų sistemos projektavimu? Kas tai yra programavimas? (1) Sistemos projektavimas - tai geriausio sistemos specifikacijos įgyvendinimo būdo parinkimo ir to būdo modeliavimo procesas. Ši apibrėžtis visiškai tinka ir programų sistemoms. Būsimos sistemos modelis yra aprašomas specialiai tam skirtomis kalbomis, vadinamomis projektavimo kalbomis. Tai dar vadinama projektinių sprendimų dokumentavimu. Kartais sistemos įgyvendinimo būdui modeliuoti naudojami veikiantys maketai. Programų konstravimas yra suprantamas kaip priimtų projektinių sprendimų aprašymas pasirinktąja programavimo kalba. Programų konstravimą įprasta vadinti programavimu arba kodavimu. Programavimas - tai pasirinktojo procesoriaus vykdomų instrukcijų rinkinio, užtikrinančio specifikacijoje numatytą to procesoriaus veiką, realizuojamą sistemos projekte numatytu būdu, sudarymo procesas. Programų sistemos konstravimo sąvoka yra platesnė negu programavimo. Konstruojant sistemą, yra ne tik sudaromos programos, bet ir kuriamos duomenų bei žinių bazės. Be to, visi konstrukciniai elementai dar turi būti integruoti į vieną visumą taip, kaip tai yra numatyta sistemos architektūroje. Visa tai apima sistemos surinkimo procesas. 33. Kas vadinama programų sistemos surinkimu? (1) Sistemos surinkimas - tai sistemos sudėtinių dalių (programų, duomenų bazių ir kitų konstrukcinių elementų) jungimo procesas. Kartais jis dar yra vadinamas sistemos integravimu. Reikia pažymėti, kad kai kuriais atvejais sistema gali būti renkama iš gatavų konstrukcinių elementų, pavyzdžiui, programų paketų. Tokiais atvejais programavimo procesas yra apskritai nereikalingas. 34. Kas vadinama programų sistemos konfigūracijos valdymu? (1) Konfigūracijos valdymas - tai procesas, kuriuo siekiama, kad bet kuriuo laiko momentu sistemoje būtų visos jos sudėtinės dalys ir kad tos dalys būtų tarpusavyje suderintos. Pagrindinis konfigūracijos valdymo tikslas sukontroliuoti "kas kur yra". Tuo tikslu kiekvienas "kas" traktuojamas kaip komponentas ir jam priskiriamas unikalus vardas. Steigiamos komponentų saugyklos ir pradedama jų apskaita. Antrasis tikslas - įvertinti, kokiu mastu yra išbaigtas konkretus gaminys. Tam išskiriamos gaminio gyvavimo stadijos (išbaigtumo būsenos) ir kiekvienai jų rengiami gaminio konfigūracijų aprašai. Kiekviena tokia būsena taip pat turi turėti unikalų vardą. Kadangi komponentai gali kisti, konfigūracijos valdymas turi padėti nepainioti panašių komponentų, t.y. valdyti pokyčius. 35. Kas vadinama programų sistemos testavimu ir verifikavimu? (1) Sistemos testavimas - tai empirinis sistemos atitikimo jos specifikacijai tikrinimo procesas. Verifikavimas - tai sistemos kūrimo žingsnio korektiškumo tikrinimo procesas. 36. Kuo skiriasi programų sistemos vertinimas, peržiūra ir inspektavimas? (1) Sistemos vertinimas - tai procesas, kuriuo siekiama nustatyti, ar sistema, jos projektas arba specifikacija tenkina realius jos naudotojų poreikius. Sistemos peržiūra - tai procesas, kuriuo siekiama patikrinti, ar sistemos kurimas vyksta pagal numatytą planą, ar gauti visi plane numatyti rezultatai ir, jei to nėra, išsiaiškinti nukrypimų nuo planuotos darbų eigos priežastis. Sistemos inspektavimas - tai procesas, kuriuo siekiama patikrinti, ar kuriant sistemą nenukrypstama nuo numatytų standartų bei specifikacijomis, sutartimis ar kitais dokumentais numatytų reikalavimų. 37. Kokie objektai yra kuriami programų sistemos kūrimo eigoje? (1) Pagrindiniai objektai, sukuriami procesais, naudojamais kuriant programų sistemas, yra šie: 1) ikiprojektinių tyrimų rezultatai (poreikių specifikacijos, tikslų specifikacijos ir pan.), 2) techniniai sistemos aprašai (specifikacijos, projektinė dokumentacija, kodas, naudojimo instrukcijos ir pan.), 3) sistemos mazgai (moduliai, failai, bazės, posistemiai ir pan.), 4) sistemos distributyvinės versijos, 5) funkcionuojančios sistemos, 6) pagalbinė medžiaga (planai, užduotys, ataskaitos, testai, testavimo užduotys, testavimo rezultatai ir pan.). Programų sistemų inžinerija nagrinėja šių objektų struktūrą, jų apipavidalinimo standartus ir kitus panašaus pobūdžio klausimus. 38. Kokios prielaidos yra daromos, taikant programų inžinerijos procesus? (1) Nagrinėjant aukščiau aptartus inžinerinius procesus ir jais kuriamus objektus, programų sistemų inžinerijoje, kaip ir kitose inžinerijos šakose, daromos tam tikros prielaidos apie tai, kaip šie procesai vyksta praktikoje. Tokios prielaidos yra būtinos, nes, neatsižvelgiant į jas, procesai yra idealizuojami ir nebegali būti efektyviai taikomi praktinėje veikloje. Trumpai aptarsime šias prielaidas. 1 prielaida: Neįmanoma pašalinti atotrūkio tarp sistemos specifikacijų ir realių naudotojų poreikių. Taip yra dėl dviejų pagrindinių priežasčių. Pirmoji priežastis - tai, kad joks analitikas negali nustatyti visų naudotojų poreikių, nes dažniausiai visų savo poreikių nesuvokia ir patys naudotojai. Antroji priežastis - tai, kad naudotojų poreikiai nuolat kinta. Poreikių pokyčius sąlygoja realaus gyvenimo pokyčiai. Todėl programų sistemų inžinerijoje visuose nagrinėjamuose procesuose stengiamasi atsižvelgti į tai, kad nė viena specifikacija nėra adekvati realiems naudotojų poreikiams. 2 prielaida: Neįmanoma išvengti klaidų nė viename iš techninių sistemos aprašų. Atsižvelgiant į šią prielaidą, yra numatomos klaidų paieškos ir šalinimo procedūros bei priemonės. 3 prielaida: Neįmanoma visiškai sumodeliuoti sistemos elgsenos trikių metu. 4 prielaida: Įmanoma surinkti tik nedidelę dalį duomenų, reikalingų tam, kad būtų galima adekvačiai įvertinti visus programų sistemų inžinerijoje naudojamų procesų eigoje sukuriamus objektus. 39. Kuo skiriasi programų sistemų inžinerijos principai ir jos paradigmos? (1) Kaip ir kitose inžinerinėse disciplinose, programų sistemų inžinerijoje yra vadovaujamasi tam tikrais principais ir tam tikromis paradigmomis. Principais programų sistemų inžinerijoje yra vadinamos pačios bendriausios metodinės programų sistemų kūrimo prielaidos. Paradigma programų sistemų inžinerijoje vadinama teorinių ir metodinių prielaidų visuma, nusakanti tam tikrą požiūrį į tai, kaip turi būti kuriama programų sistema. Pastebėsime, kad pagrindiniai principai naudojami visose arba daugelyje paradigmų. Tačiau skirtingose paradigmose jie naudojami skirtingiems tikslams. 40. Kokios yra pagrindinės programų sistemų inžinerijos paradigmos? (1) Skiriamos šios pagrindinės programų sistemų inžinerijos paradigmos: 1) sistemų kūrimo iš apačios aukštyn paradigma, 2) sistemų kūrimo iš viršaus žemyn paradigma, 3) riešuto paradigma, 4) formalizuoto sistemų kūrimo paradigma, 5) evoliucinio sistemų kurimo paradigma, 6) karkaso paradigma. 41. Kokia yra sistemų kūrimo iš viršaus žemyn paradigma? (1) Taikant šią paradigmą, pirmiausiai yra projektuojami išoriniai programų sistemos interfeisai ir nustatomi iš išorės stebimos sistemos elgsenos vertinimo kriterijai, o tik po to formuluojami reikalavimai kompiuterinės technologijos, garantuojančios suprojektuotų interfeisų veikimą ir norimą sistemos elgseną. Kuriant sistemą tokiu būdu, galima apsisaugoti nuo naudotojų vizijos iškraipymų, gaunamų dėl technologinių prielaidų. Tačiau ši vizija vis vien gali būti iškraipyta, nes, kaip jau buvo minėta anksčiau, sisteminiai analitikai dažniausiai iki galo naudotojų poreikius bei reikalavimus suvokia ne iš karto ir dėl to juos iškraipo. 42. Kokia yra riešuto paradigma? (1) Riešuto paradigma dažniausiai naudojama kuriant operacines sistemas, programavimo sistemas ir kitą sisteminę programinę įrangą. Taikant šią paradigmą, programų sistema pradedama kurti nuo vadinamojo branduolio. Branduolys - tai programų rinkinys, realizuojantis bazines sistemos funkcijas. Jis traktuojamas kaip virtuali mašina, kurios kalba programuojamos papildomos funkcijos, praplečiančios šią kalbą. Taip yra sukuriamas branduolį supantis kevalas, kuris laikomas nauja virtualia mašina, naudojama naujam kevalui kurti. Procesas tęsiamas tol, kol sistema įgyja tas savybes, kurios yra nurodytos jos specifikacijoje. Kalbant apie tokį sistemos kūrimo būdą, sakoma, kad sistema "išvyniojama" iš branduolio. 43. Kokia yra sistemų kūrimo iš apačios aukštyn paradigma? (1) Tai viena iš populiariausių programų sistemų kūrimo paradigmų. Taikant šią paradigmą, pirmiausia parenkama viena ar kita kompiuterinė technologija, o po to sprendžiama, kaip šios technologijos priemonėmis reikia kurti norimą sistemą. Sistemų kūrimo iš apačios aukštyn paradigmos populiarumas yra natūralus, nes naudojama technologija visuomet lemia tai, kokio pobūdžio programų sistemas galima sukurti. Rinkoje pasirodantys naujo tipo produktai dažniausiai yra naujų technologinių pasiekimų pasekmė. Kūrimo iš apačios aukštyn paradigma gana gerai tinka nedidelėms programų sistemoms kurti. Projektuojant didesnius arba sudėtingesnius produktus, šia paradigma naudotis nepatariama, nes dėl iš anksto daromų technologinių prielaidų dažniausiai arba iškraipoma naudotojų turima būsimosios sistemos vizija, arba galutinėje jos versijoje tenka naudoti papildomas priemones, transformuojančias žemo (technologinio) lygmens interfeisus į pavidalą, atitinkantį naudotojų viziją. Pirmuoju atveju sudėtingėja naudotojų darbas, antruoju – projekto įgyvendinimas. 44. Kokia yra evoliucinio sistemų kūrimo paradigma? (1) Pagrindinė šios paradigmos idėja yra laipsniško sistemos konstravimo idėja. Kaip ir naudojant riešuto paradigmą, pirmiausia yra kuriamas būsimosios sistemos branduolys. Tačiau šiuo atveju branduolys yra traktuojamas ne kaip virtuali mašina, naudojama sistemos funkcijoms plėsti, o kaip būsimos sistemos prototipas, įgyvendinantis pagrindines taikomojo pobūdžio funkcijas. Branduolys atiduodamas naudotojams ir toliau yra keičiamas bei plečiamas, atsižvelgiant į jų pastabas bei pageidavimus. Šitaip bandoma išvengti galimų naudotojų turimos sistemos vizijos iškraipymų. Taikant šią paradigmą programų sistemos konstravimas vyksta visą jos kūrimo laiką. Atskiros sistemos dalys sukonstruojamos jau pačioje jos kūrimo pradžioje. 45. Kokia yra formalizuoto sistemų kūrimo paradigma? (1) Šios paradigmos esmę sudaro matematinės logikos ir kitų formalių metodų taikymas programų sistemoms kurti. Paradigma siūlo formalizuoti kuriamosios sistemos specifikaciją (naudojant Z, VDL ar kitą formalaus specifikavimo kalbą) ir tą specifikaciją formaliai transformuoti į reikiamų programų kodą. Tai gali daryti žmogus arba speciali programa. Pirmuoju atveju kalbama apie įrodomąjį programavimą, antruoju - apie programų sintezę. Programų sintezės uždavinys kol kas yra išspręstas tik iš dalies. Kol kas sukurti tik jau minėtos struktūrinės sintezės metodai. Be to, tie metodai dažniausia yra pritaikyti kokiai nors konkrečiai dalykinei sričiai. 46. Kokia yra karkaso paradigma? (1) Ši paradigma grindžiama vadinamųjų mišriųjų skaičiavimų teorija. Taikant šią paradigmą, pirmiausiai yra kuriama apibendrinta (parametrizuota) programų sistemos versija, vadinama karkasu. Karkasas taip kuriamas, kad jis tiktų visoms dalykinėms sritims, turinčioms panašią loginę struktūrą. Turint konkrečios sistemos specifikaciją, karkasas yra konkretizuojamas, pritaikomas konkrečiam atvejui. Toks sistemų kūrimo būdas kartais dar yra vadinamas parametriniu programavimu. 47. Kokie yra pagrindiniai programų sistemų inžinerijos principai? (1) Didžioji dauguma programų sistemų inžinerijos principų - tai konkretizuoti atitinkami sistemų inžinerijos principai. Taikant šiuos principus konkrečiuose programų sistemų inžinerijos procesuose, jie dažniausiai dar kartą konkretizuojami atsižvelgiant į nagrinėjamo proceso ypatumus. Pagrindiniai programų sistemų inžinerijos principai yra šie: 1) dekompozicijos principas, 2) abstrakcijos principas, 3) struktūrizavimo principas, 4) juodosios dėžės principas, 5) unifikavimo principas, 6) sistemų atvirumo principas, 7) metaforizavimo principas, 8) konceptualizavimo principas, 9) interfeiso komfortiškumo principas, 10) nuoseklių patikslinimų principas. 48. Ką teigia dekompozicijos principas? (1) Dekompozicijos principas: Visus sudėtingus programų sistemų inžinerijoje vykdomų procesų objektus (užduotis, procesus, struktūras ir kt.) reikia skaidyti į kiek galima paprastesnes sudėtines dalis (modulius) ir vykdomąjį procesą taikyti kiekvienam moduliui atskirai. Nagrinėjamojo proceso požiūriu visi moduliai turi būti vieno lygmens. Jie taip pat turi būti nepriklausomi, t.y. tokie, kad, atlikus norimus veiksmus su kiekvienu iš jų atskirai ir sujungus tokiu būdu gautus rezultatus į vieną visumą, būtų gautas pageidaujamas galutinis rezultatas. Procesas turi būti kartojamas tol, kol objektas nėra suskaidytas į primityvus, t.y. lengvai suvokiamas ir neskaidžias dalis. Dalys vadinamos neskaidžiomis, jei jų negalima išskaidyti į sudėtines dalis nepažeidžiant savarankiškumo reikalavimo. Taikant dekompozicijos principą, supaprastinami analizės, projektavimo, konstravimo, testavimo ir kai kurie kiti procesai. Principas taikomas funkcijoms, programoms, duomenų struktūroms ir kitiems objektams skaidyti. Tada kalbama apie funkcinę dekompoziciją, duomenų dekompoziciją, programų moduliarizavimą ir pan. Geras programų sistemų projektavimas - tai geba skaidyti sistemą į modulius ir organizuoti tų modulių sąveiką. 49. Ką teigia abstrakcijos principas? Abstrakcijos principas: Programų sistemos inžinerijos procesai turi būti iteraciniai. Tai reiškia, kad kiekvienam objektui procesas turi būti taikomas kelis kartus. Be to, kiekvieno proceso taikymo metu objektas turi buti nagrinėjamas skirtingu detalumu, t.y. kiekvienos anksčiau vykdomos iteracijos metu yra ignoruojama daugiau nagrinėjamojo objekto detalių, jis yra labiau apibendrinamas negu vėliau vykdomų iteracijų metu. Iteracijos vadinamos abstrakcijos lygmenimis. Abstrakcijos lygmenų panaudojimas leidžia paskirstyti dėmesį ir taip supaprastinti projektavimą, konstravimą bei kai kuriuos kitus procesus. Aukštesni abstrakcijos lygmenys yra labiau apibendrinti negu žemesni. Juose sutapatinami kai kurie objektai, kurie žemesniuose abstrakcijos lygmenyse turi būti skiriami. Taigi kiekvieną abstrakcijos lygmenį galima detalizuoti daugeliu skirtingų būdų. Tai reiškia, kad kiekvienas abstrakcijos lygmuo aprašo visą šeimą žemesnių lygmenų. Todėl, norint optimizuoti taikomojo proceso rezultatus, pakanka optimizuoti perėjimus iš vieno abstrakcijos lygmens į kitą. Taip pat supaprastėja ir taikomojo proceso rezultatų modifikavimas, nes dažniausiai pakanka modifikuoti tik kai kuriuos apatinius abstrakcijos lygmenis. Abstrakcijos principas turi daug skirtingų konkretizacijų. Kalbama apie procedūrinę abstrakciją, duomenų abstrakciją, valdymo struktūrų abstrakciją, virtualiųjų mašinų hierarchijas ir pan. Jis naudojamas įvairiose paradigmose. Pavyzdžiui, taikant sistemų kūrimo iš viršaus žemyn paradigmą, pirmojoje iteracijoje projektuojama dalykinės srities terminais. Dėmesys sutelkiamas sistemos funkcijų aprašymui, konkretūs jos realizavimo būdai abstrahuojami. Paskutiniojoje iteracijoje projektuojama programavimo kalbos, duomenų struktūrų ir kompiuterio resursų terminais. Čia pagrindinis dėmesys skiriamas sistemos realizavimui ir abstrahuojamos taikymų srities sąvokos bei vaizdiniai. Kitos iteracijos užima tarpinę padėtį, jų skaičių lemia projektuojamos programų sistemos sudėtingumas ir pasirinktas projektavimo metodas. 50. Ką teigia nuoseklių patikslinimų principas? (1) Konkrečioms programoms (moduliams) projektuoti taikoma abstrakcijų principo konkretizacija vadinama nuoseklių tikslinimų principu. Nuosekliu tikslinimu principas: Projektuojant konkrečią programą, pirmiausiai reikia suformuluoti jos sprendžiamą uždavinį. Uždavinio formuluotė turi būti traktuojama kaip projektuojamosios programos specifikacija. Po to specifikacija yra detalizuojama. Tam nagrinėjami galimi jos tikslinimo būdai ir iš jų, taikant našumo ar kitus kriterijus, yra išrenkamas geriausias. Taip gaunama nauja, patikslinta programos specifikacija. Procesas kartojamas ir baigiamas tuomet, kai gaunamas kodas kokia nors programavimo kalba. Nuoseklių tikslinimų principas yra esminė sistemų kūrimo iš viršaus žemyn paradigmos dalis. Jis grindžiamas prielaida, kad galima pateikti tikslią ir nekintamą sprendžiamojo uždavinio formuluotę. Deja, tai įmanoma padaryti tik kai kuriais atvejais. 51. Ką teigia struktūrizavimo principas? (1) Struktūrizavimo principas: Programų sistemų inžinerijos procesų eigoje kuriami objektai turi būti konstruojami iš tipizuotų, patikimų elementų, kurių savybės yra gerai žinomos ir patikrintos. Struktūrizavimo principą išgarsino vadinamasis "struktūrinis programavimas". Iš pradžių šis principas buvo suabsoliutintas ir mėgintas pateikti kaip panacėja. Tai, be abejo, netiesa, nors struktūrinio programavimo metodų nauda neabejotina. Beje, plačiai paplitusi nuomonė, kad kaip tipines būtina naudoti vadinamąsias D struktūras, taip pat klaidinga. D struktūros parinktos remiantis programos analogija teoremos įrodymui ir pasižymi daugeliu gerų savybių, bet nėra vienintelės galimos. Programų sistemų inžinerijoje struktūrizuojamos ne tik programos, bet ir duomenys, sistemos, procesai bei kiti objektai. 52. Ką teigia juodos dėžės principas? Kas tai yra informacijos maskavimas?(1) Juodosios dėžės principas: Objektai turi būti taip konstruojami, kad jais butų galima manipuliuoti, nežinani jų veikimo principų. Tam, kad būtų galima pasinaudoti objektu, turi pakakti žinių apie tai, kaip jo elgesį keičia išorinis poveikis. Juodosios dėžės principą programų sistemų inžinerija perėmė iš kibernetikos. Joje juodąja dėže vadinama sistema, kuria galima naudotis nežinant tos sistemos veikimo principų. Gerai sukonstruota programų sistema naudotojui turi būti juodoji dėžė. Ja turi būti ir kiekvienas sistemos modulis. Kad programų sistema taptų juodąja dėže, reikia parinkti atitinkamą architektūrą, parengti gerą jos naudojimo instrukciją, atlikti išsamią įvesties duomenų kontrolę ir apsaugoti sistemą nuo galimų naudotojo klaidų poveikio. Be to, juodosios dėžės principas bus pažeistas, jei pranešimai naudotojui bus formuluojami vidinių sistemos konstrukcijų, o ne dalykinės srities terminais. Sistemos ir naudotojo dialogas turi vykti naudotojui įprastais terminais, sistema turi suprasti jį ir būti jo suprasta. Daugeliu atveju šį tikslą pavyksta pasiekti naudojant abstrakcijos ir konceptualizavimo principus. Pažymėsime, kad juodosios dėžės principas programų sistemų inžinerijoje taikomas daugeliui objektų ir todėl turi keletą konkretizacijų. Svarbiausia iš jų - informacijos maskavimo principas. Jis formuluojamas šitaip: Informacijos maskavimo principas: Modulių vidinės duomenų struktūros ir procedūros turi buti nematomos išoriniams naudotojams. Iš išorės prieinamos duomenų struktūros turi būti inkapsuliuotos, t.y. naudotojui turi būti pateiktas procedūrų, skirtų manipuliuoti tomis struktūromis, rinkinys. Šių duomenų struktūrų vaizdavimo būdas naudotojams turi būti nežinomas. Informacijos maskavimo principas yra svarbus tuo, kad jis leidžia keisti vidinę programų sistemų modulių konstrukciją be jokio poveikio tų modulių naudojimui. Tai labai supaprastina programų sistemų modernizavimą. Be to, taikant šį principą, padidinamas modulių patikimumas, nes duomenų struktūros yra apsaugomos nuo pažeidimų. 53. Ką teigia unifikavimo principas? (1) Unifikavimo principas: Programų sistema turi būti taip projektuojama ir konstruojama, kad ji būtų vienalytė. Visos sistemos dalys turi būti suprojektuotos ir sukonstruotos vienodai. Tam turi būti numatyti atitinkami standartai. Unifikavimo principas palengvina programų sistemų modernizavimą, sudaro prielaidas jas nuasmeninti, t.y. "atplėšti" nuo autorių. Unifikuotą sistemą gali suvokti ir keisti ne tik jos kūrėjai, bet ir kiti ją kuriant naudotus standartus įsisavinę asmenys. 54. Koks yra sistemų atvirumo principas? (1) Su unifikavimo ir juodosios dėžės principais labai glaudžiai siejasi sistemų atvirumo principas. Jis formuluojamas taip: Sistemų atvirumo principas: Programų sistemos turi būti atviros, t.y. jos turi būti konstruojamos is komponentų, turincių standartizuotus sąveikos su išorine aplinka interfeisus. Bet kuris sistemos komponentas gali būti keičiamas kitu, turinčiu tą pacią išorinę, bet galbūt kitos vidinės elgsenos, komponentu. Tai vienas iš svarbiausių programų sistemų inžinerijos principų. Jis sudaro prielaidas sistemoms plėsti, integruoti tarpusavyje bei perkelti iš vienos aparatūrinės-operacinės aplinkos į kitą. Atvirąja, arba atviros architektūros sistema, vadinama tokia programų sistema, kurios visi išoriniai interfeisai yra suprojektuoti pagal tarptautinius atvirųjų sistemų standartus. Atvirųjų sistemų standartų yra gana daug. Pagrindinės naudojamų standartų rūšys parodytos paveiksle. Interfeiso reikalavimuose būtina nurodyti, kokiems konkretiems standartams turi atitikti kiekvienas išorinis kuriamos programų sistemos interfeisas. 55. Ką teigia konceptualizavimo principas? (1) Konceptualizavimo principas: Programų sistemos turi būti taip projektuojamos ir konstruojamos, kad dalykinės srities konceptai turėtų sistemoje tiesioginius atitikmenis. Sistemos dalių sąveika turi tiksliai atspindėti probleminės srities konceptų ryšius. Tai reiškia, kad programų sistema turi būti kuriama remiantis atitinkamos dalykinės srities koncepciniu modeliu. Taikant šį principą, programų sistema dažniausiai yra konstruojama kaip specialių struktūrų, vadinamų objektais, hierarchija. Šiuo atveju objektais yra vadinami duomenų struktūrų ir su šiomis struktūromis dirbti skirtų procedurų paketai. Jie konstruojami pagal juodosios dėžės ir duomenų maskavimo principus. Objektai modeliuoja dalykinės srities sąvokas ir todėl juos patogu naudoti dialogui dalykinės srities terminais realizuoti. 56. Ką teigia metaforizacijos principas? (1) Metaforizavimo principas: Programų sistemos sąveikos su naudotoju interfeisas turi būti konstruojamas kaip datykinės srities metafora, atspindinti naudotojų vaizdinius, tradicijas bei įpročius. Taikomas kartu su konceptualizavimo principu, metaforizacijos principas sudaro visas prielaidas sukonstruoti interfeisą, modeliuojantį naudotojų požiūrį į dalykinę sritį ir sprendžiamus uždavinius. Kad sistema suprastų, ko nori naudotojas, reikia aprašyti jo vaizdinius, sukonstruoti kompiuterinę dalykinės srities metaforą ir susieti ją su koncepciniu tos sistemos modeliu. Sukonstravus vykusią metaforą, pavyksta naudotojo darbą su sistema priartinti prie jam įprasto darbo stiliaus. Jis gali įsivaizduoti sistemą kaip savo darbo stalą, paštą, kalkuliatorių ar kitą jam gerai žinomą objektą. Metaforoms konstruoti naudojami užduočių analizės metodai. Analizuojant užduotis, nagrinėjamas veiklos, kurią sistema automatizuoja, pobūdis, o ne objektas, į kurį ši veikla nukreipta. Kokias funkcijas turi realizuoti sistema čia ne tiek svarbu. Svarbiausia, koks sistemos darbo režimas tinkamiausias naudotojams. Vienaip nori sistema naudotis inžinierius, kitaip - medikas, dar kitaip - buhalteris. Būtina atsižvelgti ne tik į darbo pobūdį, bet ir į naudotojų įgūdžius, tradicijas bei mąstymo būdą. Programų sistemų inžinerijos metodų tam nepakanka, todėl tenka naudotis atitinkamais psichologijos bei pedagogikos metodais. 57. Ką teigia interfeiso komfortiškumo principas? (1) Su metaforizacijos ir konceptualizavimo principais artimai susietas ir svarbus naudotojo interfeiso konstravimo principas, vadinamas interfeiso komfortiškumo principu. Jis formuluojamas šitaip: Interfeiso komfortiškumo principas: Programų sistemos sąveikos su naudotoju interfeisas turi būti komfortiškas, t.y. darbas su sistema turi kuo mažiau varginti naudotoją, būti malonus ir nesukelti psichologinio diskomforto būsenos. Interfeisas turi buti lengvai individualizuojamas, t.y. pritaikomas prie konkretaus naudotojo pomėgių. Visų vieno tipo naudotojų naudojamų sistemų interfeisai turi būti panašūs. Šį principą realizuoti padeda ergonomikos metodai. Svarbus yra ir meninis interfeiso apipavidalinimas, medžiagos pateikimo būdas ir pan. Taigi tenka naudotis ir techninės estetikos, psichologijos bei pedagogikos metodais. 58. Kokiu tikslu programų sistemų inžinerijoje įvesta programų sistemos gyvavimo ciklo modelio sąvoka? (1) Programų sistemos gyvavimo ciklo modelio sąvoka buvo įvesta siekiant palengvinti programų sistemų kūrimo projektų planavimą ir valdymą. Programų sistemos kūrimas – ilgas, sudėtingas ir brangus procesas. Jis gali trukti keletą metų. Norint planuoti tokio projekto baigimo terminus ir sąmatinę vertę, reikia numatyti, kokius ir kokio sudėtingumo darbus teks vykdyti. Svarbi ir tų darbų vykdymo eilės tvarka. Nežinat jos, negalima planuoti kaip bus naudojami resursai. Norint veiksmingai valdyti jau vykdomą projektą, taip pat reikia žinoti, kokie darbai ir kokia eilės tvarka turi būti vykdomi. Be to, būtina sugebėti bet kuriuo momentu įvertinti esamą projekto būklę, nustatyti, kokie darbai jau atlikti, kokie dar tik pradedami, įpusėti, baigiami ir t.t. Prielaida: planuoti ir valdyti projektus yra neįmanoma jų nesuskaidžius į pakankamai mažas, matuojamas, kontroliuojamas ir lengvai valdomas dalis, vadinamas darbais. Tam naudojamas dekompozicijos principas. Pageidautina, kad projekto skaidymo būdas nebūtų unikalus, t.y. pageidautina jį tipizuoti. Kitaip kiekvieną projektą tektų skaidyti, planuoti ir valdyti savaip. Tipizuoti programų sistemų kūrimo projektų suskaidymo į darbus būdai yra vadinami programų sistemų gyvavimo ciklo modeliais. Įvesta siekiant palengvinti PS kūrimo projektų planavimą ir valdymą. 59. Kas vadinama programų sistemos gyvavimo ciklu ir kas programų sistemos gyvavimo ciklo modeliu? (1) Programų sistemos gyvavimo ciklu vadinamas laikotarpis nuo tos sistemos sumanymo iki jos demontavimo momento. Modeliuojant programų sistemos gyvavimo ciklą, visų pirma nustatoma, kokias kokybiškai skirtingas ir prasmingas būsenas gali įgyti sistema tame cikle. Išskirtosios būsenos sutvarkomos eilės tvarka ir kiekvienai viena po kitos einančių būsenų porai parenkami technologiniai procesai, reikalingi vėlesnei sistemos būsenai iš ankstesnės formuoti Programų sistemos gyvavimo ciklo modelis - tai tos sistemos gyvavimo ciklo eigoje vykdomų procesų, veikų, užduočių ir technologinių operacijų visuma, sutvarkyta laiko atžvilgiu. Modelis numato vykdomų procesų kontrolės taškus ir nustato, kokie tarpiniai ir galutiniai produktai turi būti sukurti gyvavimo ciklo eigoje. Gyvavimo ciklo modelis apibūdina programų sistemos kūrimo technologinius procesus.Modelio paskirtis: nustatyti stadijų vykdymo eiliškumą ir perėjimo iš vienos stadijos į kitą kriterijus, padėti gauti atsakymus į klausimus, kada baigti šiuo metu atliekamus darbus ir kokius darbus reiks daryti po to. 60. Kas tai yra projekto palaikymo sistema? (1) Gyvavimo ciklo modelio aspektai: 1) modelis konstruojamas kokios nors programų sistemų inžinerijos paradigmos pagrindu, 2) jis nusako programų sistemos kūrimo proceso struktūrą, 3) sistemos kūrimo procesas turi būti valdomas, todėl su juo turi būti susietas atitinkamas projekto valdymo modelis, nustatantis projekto organizacinę struktūrą bei jo valdymo procedūras. Projekto aspektų sąsajos: 1) Gyvavimo ciklo modelis ir projekto valdymo modelis turi būti suderinti, nes abu operuoja stadijomis, kontroliniais taškais ir apibrėžia kitas programų sistemos kūrimo proceso ypatybes. 2) Nustatant programų sistemos kūrimo proceso ypatybes, ribojamas metodų, naudojamų vykdant konkrečias projekto stadijas, parinkimas. 3) Naudojami metodai nustato, kokia informacija apie kuriamąją sistemą ir jos kūrimo procesą yra reikalinga darbo eigoje, t.y. nustato projekto duomenų modelio reikalavimus. Projekto duomenų bazėje saugomi projekto tikslų bei apribojimų ir kuriamosios sistemos specifikacijos, konfigūracijų aprašai, duomenys apie vidinius projekto informacijos srautus, projekto dalyvius, jų atsakomybę ir pan. 4) Duomenys saugomi kompiuteryje, duomenų paieškai ir apdorojimui naudojama programinė įranga. Naudojamas duomenų modelis lemia daugelį naudojamos programinės įrangos reikalavimų. Kita vertus, programinės įrangos parinkimą riboja naudojama kompiuterinė platforma. Projekto palaikymo sistemos diegimas Praktinė patirtis rodo, kad konkrečią projekto palaikymo sistemą galima įdiegti ne kiekviename projekte. Projekto dalyviai turi būti pasirengę naudoti su diegiamąja sistema susietą technologiją. Pasirengimo laipsnis priklauso ne tik nuo vidinių, bet ir nuo išorinių veiksnių. Norint panaudoti konkrečią technologiją, reikalingos tam tikros žinios ir tam tikri įgūdžiai. Jei projekto dalyvių išsilavinimo nepakanka reikiamoms žinioms įgyti arba jei jų praktinė patirtis yra visai kitokio pobūdžio, tai technologiją įdiegti yra labai sunku. Kliudyti gali ir kolektyvo tradicijos bei galiojančios teisinės normos. Pasinaudoti modernia technine bei programine įranga gali nepavykti ir dėl nepakankamai išvystytos šalies infrastruktūros (ryšio ir elektros perdavimo linijų, įrenginių remonto, apmokymo, konsultacijų ir pan.). 61. Kas tai yra inovacinis slenkstis? (1) Inovacinis slenkstis – tai kliūtis, trukdanti įdiegti technologiją. Kliūtis yra tokio pobūdžio: projekto dalyvių išsilavinimas per menkas, jų praktinė patirtis – kitokio požiūrio, šalies infrastruktūra (komunikacijos pvz.), mąstymo stereotipai. 62. Kokia programų sistemų inžinerijos paradigma grindžiamas klasikinis gyvavimo ciklo modelis? (1) Klasikinis gyvavimo ciklo modelis grindžiamas programų sistemų kūrimo iš viršaus žemyn paradigma. Jame numatyti tokie abstrakcijos lygmenys, kaip sistemos specifikacija, eskizinis projektas, detalusis projektas ir kodas. Tačiau sistemos konstravimas yra grindžiamas programų sistemų kūrimo iš apačios aukštyn paradigma. Modelyje yra numatyta, kad iš pradžių sistemos sudėtinės dalys testuojamos ir tikrinamos kiekviena atskirai, po to jos integruojamos ir tik po to testuojama visa sistema. 63. Kokias stadijas numato klasikinis gyvavimo ciklo modelis?(1) Modelis numato septynias stadijas: 1) sistemos specifikavimas, 2) eskizinis sistemos projektavimas, 3) detalusis sistemos projektavimas, 4) programavimas ir programų derinimas, 5) sistemos surinkimas ir aprobavimas, 6) sistemos diegimas (tiražavimas), 7) sistemos naudojimas ir priežiūra. 64. Kokie yra programų sistemos specifikavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje? (1) Pagrindiniai sistemos specifikavimo stadijos tikslai yra šie: 1) ištirti būsimų sistemos naudotojų poreikius, 2) nustatyti tikslus, kurių siekiama kuriant sistemą, 3) transformuoti tikslus į programų sistemos reikalavimus, 4) išanalizuoti galimus sistemos įsigijimo variantus ir pasirinkti genausiąjį iš jų, 5) nustatyti finansinius ir kitus projekto apribojimus, 6) organizuoti konkursą, 7) inicijuoti tolimesnius projekto darbus. 65. Kokiais aspektais nagrinėjama programų sistema techninėje užduotyje? (1) Dalykinės srities analizės pagrindu yra rengiamas dokumentas, kuriame aprašomos reikiamos PS-os funkcijos, pateikiami reikalavimai, kuriuos ji turi tenkinti., ir kalendorinis projektavimo bei konstravimo arba įsigyjimo ir instaliavimo darbų planas. Techninės užduoties paskirtis keleriopa: 1) tai dokumentas, kuriame aprašomi dalykinės srities analizės rezultatai, 2) tai juridinio susitarimo tarp užsakovo ir tiekėjo pagrindas, 3) tai dokumentas, kuriuo vadovaujantis projektuojama kuriamoji programų sistema, 4) tai dokumentas, kuriuo vadovaujantis sprendžiama, kokie resursai bus reikalingi programų sistemai kurti, 5) tai dokumentas, kuriuo vadovaujantis rengiama programų sistemos bandymų programa ir metodika. Techninė užduotis nusako: 1) kodėl yra kuriama programų sistema (operacinė sistemos naudojimo koncepcija), 2) kam ir kokia nauda bus sukūrus sistemą (operacinė sistemos naudojimo koncepcija), 3) kokie darbai turi būti atlikti ir kas turi būti padaryta tų darbų metu (darbo užduotis), 4) kokias funkcijas turi vykdyti sukurtoji sistema ir kokiomis kitomis ypatybėmis ji turi pasižymėti (programų sistemos reikalavimai), 5) kaip turi būti dokumentuojami atlikti darbai ir jų rezultatai (darbo užduotis), 6) kokiais terminais ir kokie darbai turi būti atlikti (projekto reikalavimai), 7) kaip turi būti kontroliuojama darbų eiga ir kokia atsiskaitymo už atliktus darbus tvarka (projekto reikalavimai). Techninė užduotis programų sistemai sukurti tvirtinama pirmojoje stadijoje prieš skelbiant konkursą sistemai įsigyti. Ją tvirtina oficialus užsakovo atstovas. Tikslas - aprobuoti tikslų ir reikalavimų specifikacijas. Tai vienas iš sistemos vertinimo procesų Techninė užduotis inspektuojama pirmosios stadijos pabaigoje, po sutarties pasirašymo. Tikslas - pašalinti galimus sutarties ir techninių užduočių tekstų prieštaravimus. Techninė užduotis yra lyginama su sudarytąja sutartimi. Prireikus ruošiami ir tvirtinami atitinkami techninės užduoties pakeitimai. Eskizinis projektas inspektuojamas antrosios stadijos pabaigoje. Eskizinis projektas yra lyginamas su technine užduotimi. Radus neatitikimus, keičiamas eskizinis projektas arba ruošiami nauji techninės užduoties pakeitimai. Be to, inspektavimo metu nustatoma, kuriuos sistemos komponentus tikslinga pirkti arba užsakyti subvykdytojams. 66. Kas daroma programų sistemos specifikavimo stadijoje klasikiniame gyvavimo ciklo modelyje? (1) Stadijos pradžioje analizuojama dalykinė sritis, nustatomi naudotojų poreikiai ir priimamas sprendimas įsigyti sistemą. Priėmus tokį sprendimą, formuluojami sistemos kūrimo tikslai bei reikalavimai, kuriuos ji turi tenkinti ir atliekama tų tikslų įgyvendinamumo analizė techniniu, ekonominiu bei juridiniu požiūriais. Po to sprendžiama, kokiu būdu sistema bus įsigyjama. Ji gali būti perkama, užsakoma sukurti arba kuriama savo pačių jėgomis. Galimas yra ir mišrus sistemos įsigyjimo būdas, t.y. vienos sistemos dalys gali būti perkamos, kitos - užsakomos, dar kitos - kuriamos savo jėgomis. Jei yra nuspręsta sistemą pirkti arba užsakyti, tai parengus techninę užduotį skelbiamas konkursas geriausiems pasiūlymams išrinti. Išrinkus nugalėtoją su juo deramasi dėl sutarties salygų ir pasirašoma sutartis. Derantis gali būti keičiami tecninės užduoties reikalavimai. 67. Kokie yra programų sistemos projektavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje? (1) Projektuojant programų sistemą, yra siekiama šių pagrindinių tikslų: 1) nustatyti visas kuriamosios programų sistemos vykdomas funkcijas ir jų tarpusavio sąryšius, 2) nustatyti iš kokių sudėtinių dalių turi būti sudaryta kuriamoji sistema ir pasiūlyti tas dalis jungiantį konstrukcijos santykį, 3) pasiūlyti kuriamosios programų sistemos ir kiekvienos sudėtinės dalies veikimo principus, 4) nustatyti, kokie duomenys bus apdorojami su kuriama programų sistema ir pasiūlyti, kaip tie duomenys turi būti gaunami, organizuojami ir saugomi, 5) pasiūlyti kuriamosios programų sistemos išorinius interfeisus ir jų realizavimo būdus, 6) nustatyti, kokioje operacinėje aplinkoje veiks kuriamoji programų sistema, 7) pasiūlyti kuriamosios programų sistemos darbo kompiuteriniame tinkle principus. Visi pateikti pasiūlymai turi būti ekonomiškai ir techniškai pagrįsti. Juos reikia fiksuoti raštiškai. 68. Kokie yra pagrindiniai programų sistemos projektavimo žingsniai klasikiniame gyvavimo ciklo modelyje? (1) Programų sistemų projektavimo žingsniai ir jų vykdymo tvarka priklauso nuo pasirinkto projektavimo metodo. Nepaisant to, galima išskirti šiuos pagrindinius projektavimo žingsnius, bendrus daugumai projektavimo metodų: 1) funkcinės architektūros projektavimas, 2) modulinės architektūros projektavimas, 3) duomenų architektūros projektavimas, 4) išorinių interfeisų projektavimas. 5) programų projektavimas. Projektuojant intelektualizuotas programų sistemas, papildomai tenka projektuoti žinių bazes. Be to, kartu su sistema yra projektuojami jos eksploatavimo dokumentai, testai, demonstraciniai pavyzdžiai ir pan. 69. Kokie yra programavimo ir programų derinimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje? (1) Šioje stadijoje programuojami, derinami ir autonomiškai testuojami kuriamosios programų sistemos moduliai. Autonominio testavimo rezultatai protokoluojami. Taip pat yra rašomos sistemos naudojimo instrukcijos ir kiti jos eksploatavimo dokumentai. Dokumentacijos sudėtis ir jos apipavidalinimo reikalavimai nurodomi techninėje užduotyje. (???) 70. Kas daroma programavimo ir programų derinimo stadijoje klasikiniame gyvavimo ciklo modelyje? (1) Šioje stadijoje programuojami, derinami ir autonomiškai testuojami kuriamosios programų sistemos moduliai. Autonominio testavimo rezultatai protokoluojami. Taip pat yra rašomos sistemos naudojimo instrukcijos ir kiti jos eksploatavimo dokumentai. Dokumentacijos sudėtis ir jos apipavidalinimo reikalavimai nurodomi techninėje užduotyje. 71. Kokie yra programų sistemos integravimo ir aprobavimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje? (1) Pagrindiniai integravimo ir aprobavimo stadijos tikslai yra šie: 1) sujungti visus sistemos komponentus į vieną visumą ir patikrinti to sujungimo korektiškumą, 2) patikrinti, ar visi techninės užduoties reikalavimai yra įgyvendinti, ir pašalinti sistemoje esančius techninės užduoties reikalavimų pažeidimus, 3) parengti sistemą tiražavimo ir diegimo darbams. 72. Kas daroma programų sistemos integravimo ir aprobavimo stadijoje klasikiniame gyvavimo ciklo modelyje? (1) Šioje stadijoje programos, programų sistemos moduliai, duomenų bazės ir kiti komponentai jungiami vienas su kitu. Sujungus sistemos komponentus į vieną visumą, atliekamas struktūrinis sistemos testavimas, tikslinama eksploatacinė dokumentacija ir atliekami kiti planuoti sistemos bandymai. Jų tikslas - įsitikinti, ar sistemos kūrimo darbai yra baigti ir ar užsakovas gali pradėti oficialų sistemos priėmimą. Kad patikrinti, kaip sistema veikia, ir ją pripažinti tinkama, vykdomi vadinamieji priėmimo bandymai. Jų tvarką nustato specialus dokumentas, vadinamas "Bandymų programa ir metodika". Bandymų rezultatai protokoluojami. Protokolų pagrindu rekomenduojama parengti ataskaitą apie bandymų rezultatus. Tokia ataskaita yra naudinga ne tik priimant sistemą, bet ir vėliau ją plečiant bei tobulinant. Padarius kokius nors pakeitimus, naudinga pakartoti bandymų metu naudotus testus ir patikrinti, ar nebuvo padaryta kokių nors klaidų. Visi priėmimo bandymų metu rasti sistemos defektai yra šalinami. Planuojant sistemos kūrimo darbus, tam turi būti numatyti atitinkami resursai. Pašalinus defektus, bandymai yra kartojami ir ruošiamas programų sistemos distributyvas, t.y. sistemos ruošinys, skirtas jai tiražuoti. 73. Kokie yra programų sistemos diegimo stadijos tikslai klasikiniame gyvavimo ciklo modelyje? (1) Įdiegti sistemą, apmokyti būsimus naudotojus, sukaupti būtinus pradinius duomenis. 74. Kas daroma programų sistemos diegimo stadijoje klasikiniame gyvavimo ciklo modelyje? (1) Sistemos diegimo (tiražavimo) stadija. Tai - sistemos pateikimo naudotojams stadija. Ją reikia nagrinėti užsakovo ir vykdytojo požiūriu. Užsakovo požiūriu vyksta įsigytosios programų sistemos diegimas. Jo atliekami darbai nepriklauso nuo to, kokiu būdu sistema buvo įsigyta, pirkta ar sukurta. Sistema yra instaliuojama kompiuteriuose, naudotojai mokomi su ja dirbti, duomenų bazėse kaupiami sistemai dirbti reikalingi duomenys ir atliekami kiti parengiamieji darbai. Jei sistema diegiama vietoj kitos anksčiau naudotos sistemos, tai šioje stadijoje demontuojama ankstesnioji sistema. Vykdytojų atliekami darbai priklauso nuo to, kaip ir kam sistema buvo kuriama. Jeigu ji buvo sukurta pagal konkretų užsakymą, tai vykdytojai užsiima diegimo darbais. Kartais jie kurį laiką vykdo autorinę įdiegtosios sistemos priežiūrą. Jeigu sistema buvo kuriama ją parduoti rinkoje, tai vykdytojai šioje stadijoje užsiima programų sistemos distributyvo ir jos dokumentacijos tiražavimu, reklama ir kitais su sistemos pardavimu rinkoje susijusiais darbais. 75. Kokie yra programų sistemos naudojimo ir priežiūros stadijos tikslai klasikiniame gyvavimo ciklo modelyje? (1) Išspręsti konkrečius uždavinius, aptarnauti, tobulinti, administruoti DB, periodiškai testuoti. Jei reikia sukurti naują versiją. 76. Kas daroma programų sistemos naudojimo ir priežiūros stadijoje klasikiniame gyvavimo ciklo modelyje? (1) Šioje stadijoje sistema yra naudojama konkretiems uždaviniams spręsti, vykdomas jos aptarnavimas, ji yra tobulinama. Sistemos aptarnavimas apima duomenų bazių administravimą, periodišką kontrolinį testavimą, eksploatacijos metu pastebėtų klaidų šalinimą ir kitus panašaus pobūdžio darbus. Sistemai pasenus, pradedamas naujos jos versijos kūrimas - gyvavimo ciklas kartojasi iš naujo. 77. Kokie yra kontroliniai taškai klasikiniame gyvavimo ciklo modelyje? (1) Projekto kontrolės taškais vadinami projekto inspektavimo ir peržiūrų momentai. Kontrolės taškai įvedami tam, kad laiku būtų pastebėti nuokrypiai nuo planuotos darbų eigos arba nuo techninėje užduotyje pateiktų kokybės reikalavimų, nustatytos tų nuokrypių priežastis ir imtasi priemonių toms priežastims pašalinti. Kontrolės taškai turi būti parinkti taip, kad jie sutaptų su tais laiko momentais, kuriuose numatyta gauti kokius nors reikšmingesnius rezultatus. Kontrolės taškai priklauso nuo projekto valdymo būdo, konkretaus kolektyvo tradicijų ir kitų specifinių projekto ypatumų. Rekomenduotini šie kontrolės taškai: 1) techninės užduoties tvirtinimas, 2) techninės užduoties inspektavimas, 3) eskizinio projekto inspektavimas, 4) darbo rezultatų peržiūra, inspektavimas ir vertinimas, 5) bandymų rezultatų peržiūra ir vertinimas, 6) galutinė sistemos konfigūracijos peržiūra. Techninė užduotis programų sistemai sukurti tvirtinama pirmojoje stadijoje prieš skelbiant konkursą sistemai įsigyti. Ją tvirtina oficialus užsakovo atstovas. Tikslas - aprobuoti tikslų ir reikalavimų specifikacijas. Tai vienas iš sistemos vertinimo procesų Techninė užduotis inspektuojama pirmosios stadijos pabaigoje, po sutarties pasirašymo. Tikslas - pašalinti galimus sutarties ir techninių užduočių tekstų prieštaravimus. Techninė užduotis yra lyginama su sudarytąja sutartimi. Prireikus ruošiami ir tvirtinami atitinkami techninės užduoties pakeitimai. Eskizinis projektas inspektuojamas antrosios stadijos pabaigoje. Eskizinis projektas yra lyginamas su technine užduotimi. Radus neatitikimus, keičiamas eskizinis projektas arba ruošiami nauji techninės užduoties pakeitimai. Be to, inspektavimo metu nustatoma, kuriuos sistemos komponentus tikslinga pirkti arba užsakyti subvykdytojams. Darbo rezultatai tikrinami ketvirtosios stadijos pabaigoje. Šiame kontrolės taške persipina sistemos vertinimo, inspektavimo ir peržiūros procesai. Inventorizuojamos sistemos dalys, dokumentai bei testai ir tikrinama, ar konstravimo rezultatai yra išsamūs, t.y. ar jie yra tokie, kokie buvo numatyti eskiziniame projekte, techninėje užduotyje bei bandymų programoje ir metodikoje. Sistemos bandymų rezultatai peržiūrimi penktosios stadijos pabaigoje. Peržiūrą atlieka sistemos priėmimo komisija. Pasirašomas komponento priėmimo aktas arba nurodomas laikas defektams pašalinti ir planuojami pakartotiniai bandymai. Galutinai sistema peržiūrima pasirašius jos priėmimo aktą. Peržiūros metu sudaromas oficialus sistemos konfigūracijos aprašas, kuris perduodamas tarnybai, atsakingai už nuolatinį sistemos distributyvo originalo saugojimą. 78. Kokie yra klasikinio gyvavimo ciklo modelio trūkumai? (1) Klasikinis gyvavimo ciklo modelis naudojamas gana plačiai. Tačiau paaiškėjo, kad jį naudoti tikslinga ne visuose projektuose ir kad jis turi keletą esminių trūkumų. Pagrindiniai klasikinio gyvavimo ciklo modelio trūkumai yra šie: 1) nenumatyta lygiagretaus stadijų vykdymo galimybė, 2) remiamasi daugeliu atvejų nerealia prielaida, kad galima iš karto suformuluoti visus sistemos reikalvimus ir juos tiksliai specifikuoti, 3) programų sistema konstruojama iš apačios aukštyn, 4) skirtingose klasikinio gyvavimo ciklo modelio stadijose yra naudojamos skirtingos kalbos, pereinant iš vienos stadijos į kitą, aprašus tenka rankiniu būdu transliuoti iš vienos kalbos į kitą. 5) naudojant nepakankamai formalias kalbas, pradinėse stadijose neįmanoma reikiamu laipsniu patikrinti gautų rezultatų korektiškumą, todėl pagrindiniai sistemos tikrinimai ir vertinimai nustumiami į ciklo pabaigą ir daugelis padarytų klaidų randama per vėlai. 6) Kritikuotinas ir naudojamų kalbų pobūdis, nes jos yra sintaksinio pobūdžio, t.y. tokios, kuriose pagrindinis dėmesys skiriamas formai (kaip sakoma), o ne turiniui (kas sakoma) Programavimo kalbų teorijoje tokios kalbos vadinamos sintaksiškai orientuotomis kalbomis. Norint formalizuoti tekstų, parašytų sintaksiškai orientuotomis kalbomis, prasmę, reikia sukonstruoti kalbos sintaksinių struktūrų semantinio interpretavimo taisykles. Kadangi klasikiniame gyvavimo ciklo modelyje naudojamų kalbų sintaksė yra skirtinga, tai joms interpretuoti tenka naudoti skirtingus semantinius metodus. 79. Kaip praplėstas klasikinis gyvavimo modelis struktūriniame modelyje. (3) Struktūrizuotas programų sistemos gyvavimo ciklo modelis grindžiamas vadinamąja struktūrine programų sistemų kūrimo metodika. Sudėtinės struktūrinės metodikos dalys yra struktūrinė analizė, struktūrinis projektavimas, struktūrinis programavimas ir struktūrinis testavimas. Struktūrinė metodika reglamentuoja visus pagrindinius programų sistemos kūrimo procesus. Viena iš pagrindinių jos idėjų yra brėžinio arba, autorių žodžiais tariant, "popierinio" kuriamojo objekto modelio idėja [127]. Brėžiniai nuo seno yra naudojami statomiems pastatams, konstruojamoms mašinoms ir kitiems inžineriniams objektams modeliuoti. Struktūrinėje metodologijoje pirmą kartą pabandyta brėžinio idėją nuosekliai pritaikyti programų sistemoms. Iki to laiko, naudojant blokines schemas ir kitus panašius būdus, buvo modeliuojami tik atskiri kuriamųjų sistemų aspektai. Dažniausiai būdavo modeliuojami valdymo srautai. Struktūrinėje metodikoje pateiktas suderintų kalbų rinkinys, kurį naudojant galima modeliuoti visus kuriamosios sistemos aspektus. Struktūrinė metodika turi ir kitų privalumų. Vienas iš jų - projektinių sprendimų vertinimo kriterijai. Naudojant šiuos kriterijus, galima tiksliau įvertinti sisteminio analitiko, projektuotojo ir programuotojo darbo rezultatus. Dar vienas metodikos privalumas - galimybė vienu metu vykdyti keletą skirtingų veikų. Šia metodika pagrįstame programų sistemų gyvavimo ciklo modelyje numatyta, kad kai kurios veikos gali būti pradėtos nebaigus prieš tai vykdytų veikų ir kad kai kurios veikos dėl pakitusios situacijos ar dėl padarytų klaidų gali būti pakartotos. Modelis numato 9 stadijas: apžvalga, analizė, projektavimas, konstravimas, testų konstravimas, kokybės vertinimas, procedūrų aprašymas, duomenų bazių pertvarkymas, instaliavimas. 80. Kaip praplėstas klasikinis gyvavimo modelis evoliuciniame modelyje. (3) Evoliucinis programų sistemos gyvavimo ciklo modelis grindžiamas evoliucinio sistemų kūrimo paradigma. Pagrindinė idėja - veikiančių kuriamosios sistemos maketų naudojimas jos dinaminėms savybėms modeliuoti. Maketu vadinamas veikiantis programų sistemos modelis, naudojamas sistemos reikalavimams patikslinti arba jos prognozuojamai elgsenai tirti. Modelis gali būti nepilnas funkciniu požiūriu, bet privalo adekvačiai modeliuoti tiriamus sistemos aspektus. Motyvacija: 1) Sistemos reikalavimų negalima suformuluoti iš karto. Jie formuluojami visą sistemos kūrimo laikotarpį. Be to, programų sistema yra dinaminė sistema ir vien statiniais reikalavimais jos elgsenos pilnai aprašyti neįmanoma. 2) Maketas imituoja ir statines, ir dinamines sistemos savybes, todėl su juo eksperimentuojant galima tikslinti visus sistemos reikalavimus. Jį daug lengviau sukonstruoti, modifikuoti ir plėsti negu realią sistemą, nes pakanka sumodeliuoti naudotojo interfeisą ir imituoti sistemos dinamiką. 3) Maketus tikslinga naudoti ir projektuojant sistemos architektūrą (imituojama sistemos komponentų elgsena ir modeliuojami jų interfeisai) ir šitaip patikrinti dinamines būsimos sistemos modulinės architektūros charakteristikas. Stadijos perkloja viena kitą, iš dalies vykdomos lygiagrečiai. Išsiskiria dvi stadijų, kuriose naudojamas maketavimas, grupės. Poreikių analizė ir reikalavimų formulavimas grupuojami su naudotojo interfeiso maketavimu, sistemos projektavimas, konstravimas ir aprobavimas - su sistemos modulinės architektūros ir jos komponentų maketavimu. 81. Kam skirtas pagrindinis dėmesys spiraliniame programų sistemos gyvavimo ciklo modelyje? (1) Pagrindinis dėmesys skiriamas ne tam, kaip specifikuoti ar maketuoti kuriamąją sistemą, o tam, kaip nustatyti sistemos kūrimo proceso rizikos veiksnius ir kaip juos šalinti. 82. Kokios stadijos yra spiraliniame programų sistemos gyvavimo ciklo modelyje? (1) Kiekvienam projektui projektuojamas konkretus, geriausiai jam tinkantis spiralinis gyvavimo ciklo modelis. Projektavimo metu nustatomas konkretus to projekto stadijų skaičius. Spiraliniame gyvavimo ciklo modelyje visų stadijų struktūra vienoda. Pagrindinės stadijos: alternatyvų vertinimas, rizikos faktorių analizė ir eliminavimas; sistemos kūrimo tikslų, alternatyvų ir apribojimų formulavimas; Produkto kūrimas, tikrinimas ir vertinimas. 83. Kas vadinama programų sistemos atestavimu? (1) Programų sistemos atestavimu vadinamas sistemos našumo vertinimas pagal etaloninio testavimo rezultatus. Etaloniniu vadinamas toks testas, kurį naudojant sistemos darbo rezultatus galima palyginti su kitų analogiškos paskirties sistemų našumu. 84. Kokie matai naudojami lyginant programų sistemos gyvavimo ciklo modelius? (1) Lyginant gyvavimo ciklo modelius naudojami šie matai: Delsa - vadinamas laikotarpis nuo programų sistemos reikalavimų formulavimo pradžios iki užsakovo poreikių, buvusių tuo metu, įgyvendinimo momento; Sistemos gyvavimas -laikotarpis nuo sistemos įdiegimo iki jos demontavimo momento; Atotrūkis - dydis, nusakantis skirtumą tarp užsakovo poreikių ir sistemos galimybių; Sistemos adaptyvumas - kampas, kurį sudaro programos sistemos galimybių grafikas su laiko ašimi; Sistemos neatitikimo užsakovams dydis - plotas tarp užsakovo poreikių grafiko ir programų sistemos galimybių grafiko. Neatitikimo dydis nusako atotrūkio kitimą bėgant laikui. 85. Kokia yra objektinės paradigmos esmė? Ką vadiname objektais? Kokios esti objektų sąvybes? (1) Objektinė paradigma ::= duomenų abstrakcija + objektų tipizavimas + tipų paveldėjimo mechanizmas. Pagr. objektinės paradigmos sąvoka – objektas. Bet kokia PS konstruojama kaip vienu ar kitu būdu organizuotas objektų rinkinys. Objekto savybės skirstomos į atributus (struktūrinės savybės) ir operacijas (dinaminės savybės). 86. Ką vadiname objekto būsena? Kaip ji yra inkapsuliuojama? Ką vadiname objekto interfeisu? (1) Atributai aprašo objekto būseną. Dažniausiai jie inkapsuliuojami į operacijas. Tai reiškia, kad vidinė objekto struktūra yra maskuojama, išoriniams stebėtojams ji nematoma. Jie mato tik objekto interfeiso aprašą, kuriame yra išvardinamos objekto operacijos. Sužinoti atributų reikšmes ir jas keisti galima tik naudojant atitinkamas operacijas. Kaip pavaizduoti atributai yra nežinoma ir dirbti su jais leidžiama tik naudojant atitinkamas operacijas. Maskuojant objekto struktūrą, yra paslepiami projektiniai sprendimai. Todėl veikiančioje sistemoje bet kokio objekto realizaciją galima keisti. Jei objekto interfeisas nebuvo pakeistas, tai nieko daugiau, išskyrus tą objektą, keisti nereikės. Kai kuriose objektinėse sistemose, klientui leidžiama naudotis ir kai kuriais atributais. Savybės, kurias mato klientas, vadinamos eksportuojamomis. Objekto interfeisas aprašo eksportuojamąsias savybes ir kartu apibrėžia objekto matomumo klientui laipsnį. 87. Kokia yra kliento-serverio metaforos esmė? (1) Galima maskuoti ne tik atributus, bet ir operacijas. Tuomet objekto interfeisinėje dalyje yra išvadinami pranešimas, kuriuos tas objektas gali priimti. Norint pasinaudoti tokiu objektu jam reikia pasiųsti pranešimą ir paprašyti atitinkamos paslaugos. Norintieji pasinaudoti objekto teikiamomis paslaugomis vadinami objekto klientais, o objektas, teikiantis paslaugas – serveriu. Gavęs pranešimą, objektas jį interpretuoja, t.y. vykdo atitinkamas operacijas. Vienas pranešimas gali inicijuoti ištisos objektų grandinės būsenų pokyčius. Šitaip veikianti sistema vadinama kliento-serverio architektūros sistema. 88. Kas tai yra klasės, kaip jos aprašomos ir kaip naudojamos? (1) Visose objektinėse sistemose objektai yra klasifikuojami. Vienai klasei priskiriami objektai, turintys tas pačias savybes. Klasei aprašyti naudojamas specialus aprašas, vadinamas klasės signatūra. Signatūroje aprašomi tai klasei priklausančių objektų savybės ir tų objektų interfeisas. Klasės naudojamos įvairiai: abstraktiems duomenų tipams realizuoti, naudojant kelias skirtingas klases vieną ir tą patį abstraktų tipą galima realizuoti keliais skirtingais būdais. Klasės – vienas iš mechanizmų, leidžiančių pakartotinai panaudoti modulius. Kadangi objektais galima manipuliuoti tik per interfeisus, tai objektus galima laikyti moduliais, kuriuos galima naudoti daugelyje skirtingų programų. 89. Kuo skiriasi paveldėjimas ir delegavimas? (2) Paveldėjimas – resursų skirstymas. Paveldintysis objektas gauna teisę naudotis paveldą perduodančio objekto resursais, įskaitant ir jo savybes. Delegavimas – taip pat resursų skirstymo mechanizmas. Jei paveldėjimas grindžiamas objektų klasifikavimu ir naudojamas resursams tarp klasių skirstyti, tai delegavimas pagrystas resursų perdavimui objektui prototipui ir leidža naudotis tuo pačiu resursu iš karto keliems objektams. Tokiu resursu gali būti ir operacija ir atributas. Kai objektas deleguoja kokia nors savybę prototipui, tai bet kokie deleguotos savybės pokyčiai viename iš objektų automatiškai įvyksta ir kitame objekte. Kadangi klasės gali turėti ir nuosavų savybių, tai naudojantis paveldėjimo mechanizmu ir tomis savybėmis, galima modeliuoti delegavimo mechanizmą tose kalbose, kuriose jo nėra. Paveldėjimo vien delegavimo priemonėmis sumodeliuoti negalima, nes nėra kaip sumodeliuoti schemos sąvokos. Delegavimas neleidžia aprašyti savybių viename objekte, o saugoti jas kitame. 90. Kas tai yra polimorfizmas? Kokios yra polimorfizmų rūšys? (2) Polimorfizmas – kai kintamasis arba reikšmė gali būti keleto tipų. Polimorfizmo rūšys: Parametrinis polimorfizmas – jei funkcija tais pačiais veiksmais apdoroja skirtingų tipų objektus. Šiuo atveju visi apdorojami objektai turi būti panašios struktūros. Sakoma, kad jie yra giminingi. Polimorfinė funkcija naudoja tik panašias objektų savybes ir abstrahuojasi nuo kitų jų savybių. Tariamasis polimorfizmas – kai klientui atrodo, kad funkcija apdoroja skirtingų tipų objektus. Iš tikrųjų kiekvieno tipo objektai apdorojami saarankiškai. Polimorfizmo iliuzija sukuriama funkcijų perklojimu arba koersija. 91. Koks yra objektinės programų sistemos gyvavimo ciklo modelis. (2) Objektinės programų sistemos gyvavimo ciklo modelis grindžiamas vadinamąja objektine programų sistemų kūrimo metodika. Metodika apima visas programų sistemos gyvavimo ciklo stadijas. Kalbama apie objektinę dalykinės srities analizę, objektinį projektavimą, objektinį programavimą ir t.t. Tačiau objektinių programų sistemų kūrimo metodikų turime keletą. Todėl tiksliau būtų kalbėti apie objektinių metodikų šeimą. Objektinis požiūris į programas ir programų sistemas - viena iš populiariausių šiuolaikinio programavimo paradigmų. Šioje paradigmoje programų sistema traktuojama kaip tam tikru konstrukcijos santykiu susietų objektų rinkinys. Ypatumai: 1) Objektines sistemas nesunku maketuoti ir bet kuriame gyvavimo ciklo taške. Tam pakanka paspartinti atitinkamų klasių projektavimą ir kodavimą. Aišku, turi būti naudojama tokia objektinio programavimo kalba, kuri tai leidžia daryti. 2) Jeigu sąmoningai taikoma evoliucinio sistemų kūrimo paradigma, tai klasės yra klasterizuojamos, t.y. išskiriamos tampriai tarpusavyje susijusių klasių grupės, vadinamos klasteriais. Tokių klasių objektai naudojasi vieni kitų paslaugomis, ir todėl visas klasteris turi būti realizuojamas kartu. Kiekvienoje sistemos versijoje yra realizuojamas vienas naujas klasteris. Klasteriai nuosekliai jungiami į sistemą tol, kol sukuriama galutinė sistemos versija. Prieš pradedant kurti naują versiją, peržiūrimi sistemos maketavimo rezultatai ir galbūt modifikuojami reikalavimai jau realizuotiems klasteriams. 3) Objektinėje metodikoje numatytos tos pačios pagrindinės veikos, kaip ir klasikiniame programų sistemos gyvavimo ciklo modelyje. Tai analizė, projektavimas ir konstravimas. Todėl galimi mišrūs gyvavimo ciklo modeliai, kuriuose derinami objektinės ir, pavyzdžiui, struktūrinės metodikos metodai. Kita vertus, objektiniai metodai yra evoliucinio, iteracinio pobūdžio ir, taikant juos tik atskirose stadijose, prarandami pagrindiniai objektinio požiūrio privalumai. "Fontano" modelis. 1 stadija. Reikalavimų analizė. Analizės metu dalykinės srities esybių egzemplioriai modeliuojami objektais. Analizuojama, koks objektas kam ir kokias paslaugas teikia. Programų sistemos reikalavimai formuluojami klasių ir teikiamų paslaugų terminais. Kaip reikalavimų specifikavimo kalba gali būti panaudota kokia nors objektinio programavimo kalba. Pranašumai: 1) visų stadijų rezultatai aprašomi ta pačia kalba, 2) visos specifikacijos yra vykdomos. 2 stadija. Objektų identifikavimas. Tai koncepcinio projektavimo stadija. Jos metu dalykinę sritį modeliuojantys objektai atvaizduojami į kuriamosios programų sistemos objektus, t.y. operaciniai reikalavimai transformuojami į projektinius. Klasių rinkinys papildomas klasėmis, neturinčiomis tiesioginio atitikmens dalykinėje srityje ir reikalingomis tam, kad kuriamoji programų sistema galėtų veiksmingai dirbti. Nustatomi visų objektų atributai, sudaromi tų objektų teikiamų paslaugų sąrašai. Paslaugos taip pat aprašomos programų sistemos, o ne dalykinės srities terminais. Sudėtingi objektai suskaidomi į paprastesnius, formuojamos klasių hierarchijos. 3 stadija. Eskizinis projektavimas. 4 stadija. Detalusis projektavimas 5 stadija. Konstravimas. 6 stadija. Klasių hierarchijų projektavimas. 7 stadija. Eskizinis projektavimas. Atsižvelgiant į šeštosios stadijos rezultatus, peržiūrimi informacijos srautai tarp klasių. Be to, maketuojama sistema ir tikslinami jos operaciniai reikalavimai. Maketas kartu yra ir kuriamosios sistemos prototipas, t.y. jos pirmoji versija. Taip ciklas užsidaro ir pradeda kartotis iš naujo. Objektinės programų sistemos gyvavimo ciklo modelis susideda iš 5 stadijų: Objekto ir jo atributų nustatymas, Objekto operacijų nustatymas, Objekto matomumo nustatymas, Objekto interfeiso definavimas, Objekto realizavimas. Šiame modelyje nėra griežtos ribos tarp projektavimo ir kodavimo stadijų. Gvavimo ciklas pradedamas arba poreikių, arba sistemos, kurios dalimi yra kuriamoji programų sistema, reikalavimų analize. Analizės metu dalykinės srities esybių egzemplioriai modeliuojami objektais. Analizuojama, koks objektas, kam ir kokias paslaugas teikia. Programų sistemos reikalavimai formuojami klasių ir teikiamų paslagų terminais bei specifikuojami objektinio programavimo kalba. 92. Kas PSI vadinama reikalavimų įgyvendinimo delsa? (1) Reikalavimų įgyvendinimo delsa vadinamas laikotarpis nuo programų sistemos reikalavimų formulavimo pradžios iki užsakovo poreikių, buvusių tuo metu, įgyvendinimo momento 93. Kas PSI vadinama programų sistemos ilgaamžiškumu? (1) Sistemos gyvavimu (ilgaamžiškumu) vadinamas laikotarpis nuo sistemos įdiegimo iki jos demontavimo momento. 94. Kas PSI vadinama atotrūkiu tarp užsakovo poreikių ir sistemos galimybių? (1) Atotrūkiu vadinamas dydis, nusakantis skirtumą tarp užsakovo poreikių ir sistemos galimybių 95. Kas PSI vadinama adaptyvumu? (1) Kampas, kurį sudaro programos sistemos galimybių grafikas su laiko ašimi, yra vadinamas sistemos adaptyvumu. Adaptyvumas – PS galimybių santykis su laiku. 96. Kas tai yra operacinė sistemos koncepcija? (1) Reikalavimų rengimas - vienas iš svarbiausių bet kokio pobūdžio sistemos kūrimo etapų, nes reikalavimais nusakomi tos sistemos funkcijos (operacijos), charakteristikos ir apribojimai. Tai - būsimosios sistemos vizija. Todėl, prieš pradedant rengti reikalavimus, būtina ištirti būsimųjų sistemos naudotojų operacinius poreikius ir suformuluoti vadinamąją operacinę sistemos koncepciją. Operacinė sistemos koncepcija - tai dokumentas, apibrėžiantis tikslinę sistemos paskirtį ir operacinę bei technologinę aplinką, kurioje ji bus naudojama (veiks). Operacinė sistemos koncepcija aprašo: 1) tikslus, kurių bus siekiama naudojant sukurtąją sistemą, 2) kokiu būdu sistema tenkins operacinius naudotojų poreikius, 3) numatomus sistemos naudojimo scenarijus, 4) organizacinius, valdymo, technologinius ir kitokius procesus, kurių priemonėmis numatoma įgyvendinti sistemos naudojimo scenarijus. 97. Kas tai yra programų sistemos naudojimo siekis? (1) Siekiu (mission) vadinamas pagrindinis tikslas, kurio numatoma siekti naudojant sukurtąją sistemą. Siekiu apibūdinama nauda, kurios galima tikėtis iš sistemos, ir pagrindžiamas tos sistemos kūrimo tikslingumas. Siekiai yra skaidomi į potikslius, vadinamus strateginiais tikslais. 98. Kas tai yra programų sistemos strateginiai tikslai? (1) Strateginiai sistemos naudojimo tikslai - tai pagrindinio jos naudojimo tikslo potiksliai, nusakantys pačius bendriausius, ilgalaikius kuriamosios sistemos užsakovo ketinimus. 99. Kas tai yra programų sistemos operaciniai tikslai? (1) Operaciniai sistemos naudojimo tikslai (sistemos sprendžiami uždaviniai) - tai konstruktyvūs, matuojami ir terminuoti strateginių tikslų potiksliai. Kiekvienam operaciniam tikslui nurodoma: laikas, per kurį jis turi būti pasiektas, rezultatai, kurie turi būti gauti, ir būdas nustatyti, kiek tą tikslą pavyko pasiekti. 100. Kas tai yra programų sistemos naudojimo scenarijus ir jo realizacija? (2) Sistemos naudojimo scenarijus - tai veiksmų planas, nustatantis operacinio tikslo įgyvendinimo būdą. Jei plane numatyti keli skirtingi to paties tikslo įgyvendinimo būdai, tai scenarijus vadinamas alternatyviuoju. Sistemos naudojimo scenarijaus realizacija - tai scenarijui įgyvendinti reikalingų procesų ir nurodymų, kaip tuos procesus vykdyti, aprašas. Nurodant, kaip vykdyti procesą, nusakoma, kas, kur ir kokiu būdu turi vykdyti tą procesą ir kokiais kriterijais reikia vadovautis, vertinant rezultatus, gautus jį vykdant. Procesais čia vadiname organizacinius, valdymo, technologinius ir kitokius procesus, kuriuos vykdant numatoma naudoti kuriamąją sistemą. Sistemos naudojimo scenarijų realizacijos išsamiai aprašo sistemos operacinę ir technologinę aplinką. Taigi operacinė sistemos koncepcija nusako siekį, strateginius ir operacinius tikslus, sistemos naudojimo scenarijus ir jų realizacijas. 101. Kas tai yra funkcinė sistemos dekompozicija? funkciniai agregatai? funkciniai primityvai? (2) Remiantis operacine sistemos koncepcija, formuluojami sistemos reikalavimai. Suformulavus reikalavimus, paaiškėja sistemos funkcijos. Tai savo ruožtu sudaro prielaidas pradėti funkcinę sistemos dekompoziciją. Funkcine sistemos dekompozicija vadinamas jos funkcinės architektūros projektavimo procesas. Funkcinė dekompozicija - iteracinis procesas. Pirmajame šio proceso žingsnyje sistema skaidoma į funkcinius komponentus, iš kurių kiekvienas vykdo vieną ir tik vieną tiksliai apibrėžtą ir nepriklausomą funkciją. Po to kiekvienas funkcinis komponentas skaidomas į žemesniojo lygmens funkcinius komponentus. Procesas tęsiamas tol, kol sistema suskaidoma į funkcinius primityvus. Funkciniai sistemos komponentai, kurių vykdomas funkcijas galima isreiksti pasirinktų primityvesnių funkcijų kompozicijomis, yra vadinami funkciniais sistemos agregatais. Funkciniai sistemos komponentai, kuriems to padaryti negalima, vadinami funkciniais sistemos primityvais. Funkcinio sistemos primityvo sąvoka yra santykinė. Kiekviename konkrečiame projekte susitariama, kokias funkcijas laikyti primityviomis dalykinės srities funkcijomis. Funkcinių primityvų visuma vadinama pasirinktqja projektavimo baze. 102. Kas programų sistemų inžinerijoje vadinama reikalavimu? reikalavimų specifikacija? (1) Objekto (proceso) reikalavimu vadinama specifikacija, sutartimi su užsakovu, standartu arba kokiu nors kitu juridinę galią turinčiu ir įpareigojančiu dokumentu numatyta to objekto (proceso) savybė. Reikalavimų specifikacija - tai dokumentas, skirtas kokio nors objekto (proceso) reikalavimams aprašyti. 103. Kas vadinama programų sistemos reikalavimų lokalizavimu? (1) Nustačius pirmojo funkcinės sistemos architektūros lygmens funkcinius komponentus, pradedamas sistemos reikalavimų lokalizavimas. Sistemos reikalavimų lokalizavimu vadinamas sistemos reikalavimų skaidymo į galbūt bendrus elementus turinčias grupes ir tų grupių susiejimo su atitinkamais funkciniais sistemos komponentais procesas. Reikalavimai turi būti taip lokalizuojami, kad kiekvienas sistemos reikalavimas pakliūtų bent į vieną reikalavimų grupę ir kad su kiekvienu duotojo hierarchijos lygmens funkciniu komponentu būtų susieta viena ir tik viena netuščia reikalavimų grupė. Reikalavimų lokalizavimo rezultatai aprašomi reikalavimų lokalizavimo matrica (pav.). Lokalizuojant sistemos reikalavimus, gali paaiškėti, kad jie buvo suformuluoti nekorektiškai ir yra keistini. 104. Koks reikalavimas vadinamas abstrakčiu? (1) Reikalavimas yra vadinamas abstrakčiu, jei jis specifikuoja operacinę (t.y. stebimą iš isorės) objekto (proceso) savybę. Norint, kad reikalavimai būtų abstraktūs, reikia operacinius reikalavimus griežtai atskirti nuo projektinių ir realizacinių reikalavimų. Pažymėsime, kad reikalavimų abstraktumas yra santykinė sąvoka, priklausanti nuo nagrinėjamojo funkcinės architektūros lygmens. Projektiniai funkcinio agregato reikalavimai, perėjus į žemesnįjį funkcinės architektūros lygmenį, tampa operaciniais jo komponentų reikalavimais. 105 Koks reikalavimas vadinamas įgyvendinamu? (1) Reikalavimas vadinamas įgyvendinamu, jei yra žinomas toks ekonominiu, juridiniu bei kitais požiūriais priimtinas technologinis procesas, kurio inovaciniai slenksčiai gali būti pašalinti per priimtiną laikotarpį ir už priimtiną kainą ir kurį taikant galima sukurti objektą (procesą), turintį tuo reikalavimu specifikuojamą savybę. 106. Koks reikalavimas vadinamas integruojamu? (1) Reikalavimas vadinamas integruojamu, jei, sujungus jį su kitais reikalavimais, yra gaunamas tarpusavyje suderintų reikalavimų rinkinys. 107. Koks reikalavimas vadinamas išsamiu? (1) Reikalavimas vadinamas išsamiu, jei jis turi prasmę ne tik tuomet, kai yra nagrinėjamas kartu su kitais reikalavimais, bet ir tuomet, kai jis nagrinėjamas atskirai. 108. Koks reikalavimas vadinamas lokalizuojamu? (1) Reikalavimas vadinamas lokalizuojamu, jei jį galima susieti su bent vienu specifikuojamojo objekto (proceso) komponentu. 109. Koks reikalavimas vadinamas trasuojamu? (1) Reikalavimas vadinamas trasuojamu, jei jis yra vienareikšmiškai įvardinamas ir turi nuorodą į šaltinį. Norint, kad reikalavimai būtų trasuojami, kiekvienam reikalavimui reikalavimų specifikacijoje reikia skirti atskirą struktūrinį teksto elementą, pavyzdžiui, pastraipą, ir tuos elementus sunumeruoti. Nuorodos į reikalavimų šaltinius turi būti daromos ne tik išvestiniuose, bet ir pradiniuose reikalavimuose. Išvestiniuose reikalavimuose nuorodos daromos į reikalavimus, iš kurių jie yra išvesti. Pradiniuose reikalavimuose nuorodos daromos į išorinius šaltinius, pavyzdžiui, į atitinkamus teisinius dokumentus, kompiuterizuojamos organizacijos statutą ar kompiuterizuojamo technologinio proceso dokumentaciją. 110. Koks reikalavimas vadinamas suprantamu? (1) Reikalavimas vadinamas suprantamu, jei jis yra vienareikšmis. Norint pasiekti, kad reikalavimai būtų vienareikšmiai, reikia vengti sintaksinių dviprasmybių ir duoti visų vartojamų terminų, sutrumpinimų bei žymėjimų aiškinimus. 111. Koks reikalavimas vadinamas glaustu? (1) Reikalavimas vadinamas glaustu, jei jame aprašoma tik specifikuojamoji objekto (proceso) savybė ir nėra aiškinami reikalavimo motyvai, tos savybės paskirtis ir pan. 112. Koks reikalavimas vadinamas unikaliu? (1) Reikalavimas vadinamas unikaliu, jei jame nėra kartojama kituose reikalavimuose pateikta informacija. 113. Koks reikalavimas vadinamas verifikuojamu? (1) Reikalavimas vadinamas verifikuojamu, jei egzistuoja baigtinis kainos ir kitais požiūriais priimtinas procesas, kurį taikant galima nustatyti, kiek reikalavimas yra įgyvendintas. 114. Kas vadinama programų sistemos reikalavimų nuleidimu žemyn? (1) Reikalavimų nuleidimas žemyn. Lokalizavus reikalavimus, jie nuleidžiami į žemesnįjį funkcinės architektūros lygmenį. Sistemos reikalavimų nuleidimas lygmeniu žemiau - tai funkcinių komponentų reikalavimų išvedimo iš lokalizuotų funkcinio agregato, į kurio sudėtį tie komponentai įeina, reikalavimų ir išvestųjų reikalavimų papildymo procesas. Nuleidžiant reikalavimus, jie yra detalizuojami. Šiuo atveju detalizacija suprantama ne kaip reikalavimų skaidymas. Detalizuotas reikalavimas gali išplaukti ir iš kelių aukštesniojo lygmens reikalavimų. Kadangi operaciniai sistemos reikalavimai aprašo tik išorinę sistemos elgseną, jie yra nepilni. Todėl, nuleidžiant reikalavimus, jie gali būti papildomi. 115. Kokie sistemos funkcinio komponento reikalavimai vadinami išvestiniais? (1) Išvestiniais funkcinio sistemos komponento reikalavimais vadinami tie jo reikalavimai, kurie išplaukia is aukštesniojo lygmens funkcinio agregato lokalizuotų reikalavimų. Kiti to komponento reikalavimai yra vadinami papildomais reikalavimais. Tai, kad reikalavimas C yra išvestas iš reikalavimų A ir B, žymime sitaip: A,B —> C. Nuleidus reikalavimus į žemesnįjį funkcinės architektūros lygmenį, paaiškėja, kokie to lygmens komponentai yra funkciniai primityvai, kokie - funkciniai agregatai. Taip sudaromos galimybės to architektūros lygmens funkcinei dekompozicijai atlikti. Pažymėsime, kad nuleidžiant operacinius sistemos reikalavimus į pirmąjį funkcinės architektūros lygmenį, jie transformuojami į projektinius reikalavimus. 116. Kas tai yra reikalavimų sąryšio matrica? (1) Reikalavimų trasavimas. Nuleidžiant reikalavimus iš vieno funkcinės architektūros lygmens į kitą, jų skaičius sparciai didėja. Projektuotojant sistemą, reikia žinoti ne tik reikalavimus, bet ir jų šaltinius, t.y. kokie reikalavimai iš kokių reikalavimų ir kokiu būdu yra išvesti. Todėl reikalavimų nuleidimo procesą reikia dokumentuoti. Tam naudojamos reikalavimų ryšio matricos (pav.) Jomis aprašomi reikalavimų, lokalizuotų dviejuose gretimuose funkcinės architektūros lygmenyse, ryšiai. Reikalavimas Iš kokių aukštesniojo lygmens reikalavimų išvestas Kokiame funkciniame sistemos komponente lokalizuotas Reikalavimo aprobavimo būdas Aprobavimo rezultatai Reikalavimų trasavimu vadinamas žemesniojo lygmens reikalavimo išvedimo iš aukštesniojo lygmens kelių nustatymo ir tų kelių dokumentavimo procesas. 117. Kokie turi būti gerai suformuluoti programų sistemos reikalavimai? (1) Gerai suformuluotas reikalavimas turi būti abstraktus, įgyvendinamas, lokalizuojamas, išsamus, integruojamas, suprantamas, unikalus, glaustas, verifikuojamas ir trasuojamas. Be to, reikalavimas turi būti formuluojamas vartojant to funkcinės architektūros lygmens, kuriame jis yra lokalizuojamas, terminus. 118. Kas tai yra anotuoti reikalavimai? (1) Reikalavimas vadinamas anotuotu, jeigu yra nurodytas jo statusas, kritiškumas ir galiojimo laikas. 119. Kas yra reikalavimo statusas? (1) Ne visi programų sistemos reikalavimai yra vienodai svarbūs. Dažniausiai juos galima suskirstyti į tris skirtingo statuso grupes: 1) privalomi reikalavimai, 2) pageidavimai, 3) papildomi reikalavimai. Privalomais vadinami tie reikalavimai, kurių neįgyvendinus negali būti realizuotas sistemos naudojimo siekis. Pažeidus privalomus reikalavimus, užsakovas sistemos priimti negali, nes ji bus netinkama naudoti. Pageidavimais vadinami reikalavimai, kuriuos įgyvendinus palengvėja arba supaprastėja sistemos siekio realizavimas. Užsakovas sistemą gali priimti ir neįgyvendinus kai kurių jo pageidavimų. Ji bus tinkama naudoti tik galbūt mažiau patogi. Papildomais vadinami tokie reikalavimai, kuriuos įgyvendinus yra praplečiamas sistemos naudojimo siekis. Jie įgyvendinami už papildomą mokestį. 120. Kas yra reikalavimo kritiškumas? (1) Reikalavimų kritiškumo laipsnis: 1) Reikalavimo kritiškumo laipsnį nusako jo pažeidimo pasekmės. Jos gali būti sunkios, apysunkės arba lengvos. 2) Pasekmių sunkumo laipsnis yra nustatomas pagal materialinės arba kitokios galimos žalos dydį. 3) Projektuotojams labai svarbu žinoti visų programų sistemos reikalavimų kritiškumą. 121. Kuo skiriasi programų sistemos reikalavimai ir projekto reikalavimai? (1) Skiriami programų sistemos reikalavimai ir projekto reikalavimai. Programų sistemos reikalavimais nusakoma, kokia programų sistema turi būti sukurta, o projekto reikalavimais – kaip ta sistema turi būti kuriama. Paprastai projekto reikalavimai aprašomi užsakovo ir tiekėjo sandoriu. 122. Į kokias grupes skirstomi projekto reikalavimai? (1) Projekto reikalavimai dažniausiai yra aprašomi užsakovo ir tiekėjo sutartyje. Jie skirstomi į šias pagrindines grupes: 1) technologiniai reikalavimai, 2) kokybės valdymo reikalavimai, 3) konfigūracijos valdymo reikalavimai, 4) vykdymo terminų reikalavimai, 5) vykdymo kontrolės reikalavimai, 6) finansavimo reikalavimai, 7) projekto rezultatų ir jų pateikimo reikalavimai, 8) projekto rezultatų aprobavimo reikalavimai, 9) garantijų reikalavimai, 10) ginčų sprendimo tvarkos reikalavimai, 11) ypatingieji reikalavimai. 123. Ką apibūdina technologiniai projekto reikalavimai? (1) Technologiniai reikalavimai savo ruožtu skirstomi į projektavimo, realizavimo ir parengties darbui reikalavimus. Projektavimo reikalavimais nustatomi: 1) projektavimo metodai, 2) projektavimo technologija, 3) projektavimo priemonės, 4) projektavimo rezultatų dokumentavimo būdai. Realizavimo reikalavimais nustatoma: 1) kokiomis programavimo kalbomis rašyti programas, 2) kokią instrumentinę programinę įrangą naudoti programų sistemai realizuoti, 3) kokią kompiuterinę platformą ir kokią konkrečią jos konfigūraciją naudoti programoms derinti bei testuoti, 4) kokius struktūrizavimo metodus naudoti programoms bei duomenims struktūrizuoti, 5) kaip apipavidalinti programų tekstus. Parengties darbui reikalavimais nustatoma: 1) kaip instaliuoti sukurtas programas, 2) kaip kurti ir pildyti duomenų bazes, 3) kaip atlikti kitus parengiamuosius darbus. 124. Ką apibūdina projekto kokybės valdymo reikalavimai? (1) Kokybės valdymo reikalavimais nustatoma, kaip planuoti ir kontroliuoti kuriamosios programų sistemos kokybę ir kaip šalinti pastebėtus nuokrypius nuo kokybės plano. 125. Ką apibūdina projekto konfiguracijos valdymo reikalavimai? (1) Konfigūracijos valdymo reikalavimais nustatomi konfigūracijos valdymo metodai, naudojami kuriamosios programų sistemos konfigūracijai valdyti. 126. Ką apibūdina projekto vykdymo reikalavimai? (1) Vykdymo terminų reikalavimais nustatomi projekto stadijos, etapai ir jų baigimo terminai. Vykdymo kontrolės reikalavimais nustatomi projekto kontrolės taškai ir tuose taškuose naudojamas kontrolės procedūros. Kontrolės taškais dažniausiai numatomi tie laiko momentai, kuriuose planuojama gauti kokius nors išbaigtus rezultatus. Kontrolės taškuose tikrinama, ar yra gauti visi reikiami rezultatai ir ar jie yra korektiški. Galima atlikti ir rezultatų vertinimą. Rezultatams vertinti naudojamos inspektavimo, audito ir peržiūros procedūros. 127. Ką apibūdina projekto finansavimo reikalavimai? (1) Finansavimo reikalavimais nustatomi: 1) projekto kaina, 2) finansavimo būdas, 3) finansavimo tvarka. Finansavimo būdas ir finansavimo tvarka glaudžiai susiję. Dažniausiai jie priklauso nuo to, ar programų sistema yra užsakoma, ar ji kuriama savos organizacijos jėgomis. Pirmuoju atveju visa apmokėjimo suma dažniausiai yra nustatoma iš anksto. Ji mokama tiekėjui etapais. Tam tikra etapo darbų dalis dažnai apmokama iš anksto. Kartais papildomai numatoma premijuoti tiekėją už spartesnius terminus, papildomas darbų apimtis ar geresnę kokybę. Jei sistema kuriama savo organizacijos jėgomis, formaliai projektas dažniausiai nėra įteisinamas ir jo biudžetas nėra sudaromas. Visus reikiamus darbus atlieka nuolatinį atlyginimą gaunantys etatiniai darbuotojai, o kitos išlaidos dengiamos iš organizacijos biudžeto. Toks projekto vykdymo būdas nerekomenduotinas, nes jis neskatina vykdytojo nei taupyti lėšas, nei gerinti darbų kokybę. Daug geriau formaliai įteisinti projektą ir sudaryti jam savarankišką biudžetą. Tada projektas gali būti finansuojamas pagal tas pačias taisykles, kaip ir sudarius sutartį su kita organizacija. Klasifikuojant projektus pagal jų finansavimo būdą, vadovaujamasi dviem pagrindiniais kriterijais: 1) kam tenka pagrindinė rizika dėl nenumatytų išlaidų, 2) kokio pobūdžio ir kokios apimties paskatinimai yra numatyti tiekėjui už pageidavimų ir papildomų reikalavimų įgyvendinimą arba už kokybiškesnius rezultatus, negu buvo reikalauta. Pagal šiuos kriterijus projektai skirstomi į keturias grupes: 1) projektai su iš anksto nustatyta apmokėjimo suma, 2) projektai, kuriuose numatoma kompensuoti tiekėjo išlaidas, 3) projektai su skatinančiuoju finansavimu, 4) kitaip finansuojami projektai. 128. Ką apibūdina projekto rezultatų ir jų pateikties reikalavimai? (1) Projekto rezultatų pateikties reikalavimais nustatoma: 1) kokie galutiniai ir tarpiniai rezultatai (programos, duomenų bazės, dokumentai, testai, demonstraciniai pavyzdžiai ir pan.) turi būti gauti projekto vykdymo metu, 2) kaip jie turi būti apipavidalinti, 3) kaip juos pateikti užsakovui. Projekto rezultatų pateikimo reikalavimais programų sistema specifikuojama kaip prekė, t.y.: 1) nurodoma, kas ir kokiais terminais turi būti pateikta, 2) apibrėžiama, kas vadinama "rezultatų pateikimu (pristatymu)" ir "rezultatų pateikimo (pristatymo data)", 3) nustatomos rezultatų pateikimo ir jų gavimo patvirtinimo procedūros, 4) numatomos baudos už pavėluotą rezultatų pateikimą, 5) nustatoma, kam tenka rizika dėl galimų nuostolių transportuojant siuntas, 6) nurodomi pateikiamos dokumentacijos sudėtis, dokumentų struktūra ir turinys, dokumentų apipavidalinimo būdas ir jų pateikimo forma, 7) aprašoma, į kokias laikmenas turi būti įrašyti distributyvinės programų sistemos versijos originalas ir kopijos, kaip tos laikmenos turi būti paruoštos, 8) nustatoma, kokie klasifikatoriai turi būti naudojami programų sistemai kaip prekei klasifikuoti, 9)nurodoma, kaip turi būti pakuojamos ir markiruojamos laikmenos su distributyvine programų sistemos versija, 10) numatomos tiekėjo ir užsakovo pareigos rengiant programų sistemą darbui ir vykdant sistemos bandomąjį eksploatavimą. 129. Ką apibūdina projekto rezultatų aprobavimo reikalavimai? (1) Projekto rezultatų aprobavimo reikalavimais nustatomi projekto rezultatų vertinimo kriterijai ir darbų priėmimo tvarka. Jais numatoma, kas turi parengti bandymų programą ir metodiką, kur bus vykdomi baigiamieji programų sistemos bandymai, kas sudarys priėmimo komisiją, koks bus oficialus tų bandymų statusas ir kaip įsipareigoja elgtis šalys, jei bandymai bus nesėkmingi. 130. Ką apibūdina projekto garantijų reikalavimai? ypatingieji reikalavimai? (1) Garantijų reikalavimais nustatomi: 1) garantinio laikotarpio pradžia ir trukmė, 2) garantiniai tiekėjo įsipareigojimai (nemokamas klaidų šalinimas, konsultacijos, techninė parama ir pan.), 3) užsakovo atsakomybė už neteisėtas pretenzijas (defektus dėl užsakovo kaltės, bereikalingą tiekėjo atstovų iškvietimą ir pan.), 4) užsakovo ir tiekėjo įsipareigojimai saugoti intelektualinės ir pramoninės nuosavybės teises, neskleisti gaunamos informacijos ir vartoti ją tik tam tikslui, kuriam ji yra skirta. Kartais dar yra nustatomos tiekėjo finansinės garantijos laikytis prisiimtų įsipareigojimų. Ginčų sprendimo reikalavimais nustatoma galimų tiekėjo ir užsakovo ginčų sprendimo tvarka. Ypatingaisiais reikalavimais nustatoma, kaip turi elgtis šalys ypatingų aplinkybių (karas, stichinės nelaimės, streikai ir pan.) atveju. 131. Į kokias grupes skirstomi programų sistemos reikalavimai? (1) Programų sistemos reikalavimų rūšys: 1) funkciniai reikalavimai, 2) nefunkciniai reikalavimai Funkciniai reikalavimai: 1) Funkciniais programų sistemos reikalavimais nusakoma, ką ta sistema turi gebėti daryti. 2) Jais specifikuojamos pagrindinės ir pagalbinės kuriamosios sistemos funkcijos. 3) Pagrindinėmis vadinamos funkcijos skirtos kuriamosios sistemos siekiui realizuoti. 4) Pagalbinės funkcijos išplaukia iš technologinių reikalavimų. Jomis naudojamasi aptarnaujant ir prižiūrint sistemą. Pavyzdžiai: programų sistemos darbo protokolavimas, duomenų archyvavimas, statistikos apie sistemos darbą kaupimas ir pan. Formuluojant funkcinius reikalavimus, kiekvienai funkcijai yra nurodomi: 1) pradiniai duomenys, 2) atliekami veiksmai, 3) rezultatai. Be to, reikia nurodyti funkcijų vykdymo tvarką ir jų vykdymo technologinius apribojimus, pavyzdžiui, funkcijas, kurias draudžiama vykdyti vieno darbo seanso metu. Nefunkciniais programų sistemos reikalavimais vadinami reikalavimai, ribojantys aibę potencialiai galimų projektinių sprendimų apie funkcinių reikalavimų įgyvendinimo būdą. 132. Kas įvyksta pažeidus funkcinius sistemos reikalavimus? (1) Pažeidus funkcinius reikalavimus, programų sistema tampa nekorektiška. Sistema, procesas arba bet koks kitas objektas vadinama korektišku, jei jo savybės sutampa su duoto etalono savybėmis. Etalonas gali būti nurodytas ir netiesiogiai, kaip daugiau ar mažiau formalizuotas etaloninių reikalavimų rinkinys. Programų sistemos korektiškumas nusakomas jos atitikimo specifikacijoje suformuluotiems reikalavimams laipsniu. Programų sistemos korektiškumas - statinė savybė. Pagrindinės programų sistemų nekorektiškumo priežastys - tai projektavimo ir kodavimo klaidos. 133. Į kokias pagrindines grupes skirstomi nefunkciniai sistemos reikalavimai?(1) Nefunkciniais programų sistemos reikalavimais vadinami reikalavimai, ribojantys aibę potencialiai galimų projektinių sprendimų apie funkcinių reikalavimų įgyvendinimo būdą. Nefunkcinių reikalavimų rūšys: 1) interfeiso reikalavimai, 2) veikimo reikalavimai, 3) iš ekonominių apribojimų išplaukiantys reikalavimai, 4) iš politinių apribojimų išplaukiantys reikalavimai, 5) iš teisinių apribojimų išplaukiantys reikalavimai. 134. Kokios yra interfeiso reikalavimų grupės? trumpai apibūdinkite jas? (2) Interfeiso reikalavimais vadinami tokie nefunkciniai programų sistemos reikalavimai, kuriuos pažeidus sistema nebegali funkcionuoti toje aplinkoje, kurioje ją buvo numatyta naudoti, pavyzdžiui, jos nebegalima vykdyti turimoje kompiuterinėje platformoje arba nebegalima suformuluoti tų užduočių, kurias ta sistema turi vykdyti. Kitaip tariant, pažeidus interfeiso reikalavimus, sistema gali vykdyti visas numatytas funkcijas, bet kai kuriomis iš tų funkcijų pasinaudoti tampa neįmanoma. Rūšys:1) semantiniai (prasminiai) reikalavimai, 2) sintaksiniai (struktūriniai) reikalavimai, 3) pragmatiniai (tikslinės paskirties) reikalavimai, 4) protokolo (sąveikos būdo) reikalavimai. Semantiniais interfeiso reikalavimais nusakomi sistemai per jos interfeisus pateikiamos informacijos pobūdis ir tos informacijos interpretacija. Sintaksiniais interfeiso reikalavimais nusakomi informacijos pateikimo forma ir jos struktūrinių elementų vaizdavimas. Pragmatiniais interfeiso reikalavimais nusakoma tikslinė interfeiso paskirtis. Pavyzdys. Skirtingose programų sistemose naudotojo interfeisas gali turėti labai skirtingą tikslinę paskirtį. Interfeiso naudojimo būdas lemia pragmatinių reikalavimų pobūdį. Pavyzdžiui, tekstų redagavimo sistema yra dažnai naudojama ir skirta rutininėms operacijoms atlikti. Pagrindinis reikalavimas tokiai sistemai - maksimizuoti naudotojo darbo greitį. Kitaip yra tuomet, kai sistemos retai naudojamos: tada naudotojas gali tiesiog pamiršti jos interfeisą. Tokiu atveju pagrindinis reikalavimas - kuo akivaizdesnis interfeisas. Pragmatiniai interfeiso reikalavimai turi būti griežti ir tikslūs. Geriausia juos formuluoti taip, kad jų realizavimo laipsnį būtų galima įvertinti kiekybiškai. Protokolo reikalavimais aprašomi darbo su sistema taisyklės ir susitarimai. Kitaip tariant, jais nurodoma, kaip per interfeisus sistemai perduoti informaciją. 135. Kokios yra sistemos veikimo reikalavimų grupės? trumpai apibūdinkite jas. (2) Sistemos veikimo reikalavimų rūšys: tikslumo reikalavimai, patikimumo reikalavimai, robastiškumo reikalavimai, našumo reikalavimai. Tikslumo reikalavimai skirstomi į duomenų vaizdavimo tikslumo, skaičiavimo tikslumo. Programų sistemos realizuojamu duomenų vaizdavimo tikslumu vadinama sistemos skiriamoji geba, t.y. geba skirti jos apdorojamus objektus vienas nuo kito. Programų sistemos skaičiavimų tikslumu vadinamas jos gaunamų rezultatų nesutapimo su tais rezultatais, kuriuos ji turi gauti, laipsnis. Programų sistemos patikimumo samprata yra gana sudėtinga ir šiuo metu dar nėra pakankamai suvokta. Ji išreiškiama remiantis sistemos funkcionalumo, trykio, funkcionalumo praradimo ir funkcionalumo atkūrimo sąvokomis. Programų sistemos funkcionalumu vadinama tos sistemos geba vykdyti specifikacijoje numatytas funkcijas. Programų sistemos trykiu vadinamas vidinis įvykis, pažeidžiantis jos funkcionalumą. Vidiniais vadinami įvykiai, sąlygoti pačios sistemos atliekamų veiksmų. Programų sistemos funkcionalumo praradimu vadinamas gebos vykdyti specifikacijoje numatytas funkcijas praradimas. Programų sistemos funkcionalumo atkūrimu yra vadinami veiksmai, kuriuos reikia atlikti tam, kad būtų atkurta sistemos geba vykdyti jos specifikacijoje numatytas funkcijas. Programų sistemos patikimumu vadinama jos trykių poveikio operacinių tikslų realizavimui dydis. Programų sistemos robastiškumu vadinama jos geba automatiškai atkurti savo funkcionalumą. Prarastą dėl trykių arba išorinių poveikių, ir atnaujinti savo veikimą. PS vadinama našia (veiksminga), jei ji naudoja tik tiek resursų, kiek jų reikia specifikacija numatytoms funkcijoms korektiškai vykdyti. 136. Kokios yra iš ekonominių apribojimų išplaukiančių reikalavimų grupės? trumpai apibūdinkite jas? (2) Iš ekonominių ribojimų išplaukiančių reikalavimų grupės: diegimo reikalavimai, aptarnavimo reikalavimai, modernizavimo reikalavimai, komponentų tiražuojamumo reikalavimai. PS diegimo reikalavimais siekiama minimizuoti išlaidas, reikalingas naudotojams ir aptarnaujančiam personalui apmokyti bei sistemą darbui parengti. Aptarnavimo procedūrų automatizavimo reikalavimai formuluojami kaip funkciniai reikalavimai. Jais nurodoma, kokios priemonės turi būti numatytos kuriamojoje PS: archyvams aptarnauti, gedimams lokalizuoti, komplektiškumui ir komponentų funkcionalumui (veikimo korektiškumui) tikrinti. Modernizavimo reikalavimai yra šie: pritaikomumo reikalavimai, universalumo reikalavimai, perkeliamumo reikalavimai, lankstumo reikalavimai, adaptyvumo reikalavimai, praplečiamumo reikalavimai. PS komponentas vadinamas tiražuojamu, jei juo galima naudotis ne tik tuomet, kai jis yra sistemos sudėtyje, bet ir savarankiškai. 137. Kokie reikalavimai išplaukia iš politinių apribojimų? trumpai apibūdinkite juos? (2) Dauguma politinio pobūdžio reikalavimų yra specifiniai, būdingi konkrečiai organizacijai. Vienintelis universalus reikalavimas yra PS apsauga nuo neteisėto naudojimo. Teisėtu PS naudojimu vadinamas sistemos naudojimas pagal jos paskirtį, atliekamas asmens, turinčio tam oficialius įgaliojimus. PS apsaugos mechanizmu vadinamos priemonės skirtos tos sistemos saugumui gresiančioms grėsmėms nustatyti ir pašalinti. Mechanizmo veiksmingumas nusakomas tikimybe, kad bus nustatyta ir pašalinta bet kokia potencialiai galima grėsmė. Apsaugos reikalavimais nustatoma, koks turi būti kuriamos sistemos apsaugos mechanizmo veiksmingumas, ir galbūt specifikuojami to mechanizmo komponentai. 138. Kokie reikalavimai išplaukia iš teisinių apribojimų? trumpai apibūdinkite juos. (2) Teisiniai ribojimai (įstatymai, vyriausybės nutarimai, organizacijų statutai ir kiti normatyviniai dokumentai) nustato: kurios funkcijos gali būti kompiuterizuotos, kokie duomenis gali būti renkami bei kaupiami. Formuluojant funkcinius PS reikalavimus, būtina atsižvelgti į konstitucinį įstatymų leidžiamosios, vykdomosios ir teisminės valdžių atskyrimo principą. Reikia atsižvelgti ir į tai, kad PS nepažeistų konkurencijos įstatymo. Ypač tai aktualu sistemoms, kurios keičiasi informacija apie rinką arba ją platina. Projektuojant tokias sistemas, reikia užtikrinti, kad nebūtų atskleistos komercinės paslaptys, informacija apie vieną varžovą nebūtų prieinama kitam varžovui. Ar PS nepažeis teisinio organizacijos statuso Ar PS išspausdinti dokumentai bus pripažįstami teisiškai Ar nepažeis telekomunikacijos įstatymų, etcų 139. Kas tai yra dalykinės srities analizė? Pagal kokią schemą ji vyksta? (2) Programų sistemos reikalavimų formulavimo būdai priklauso nuo to, ar ta sistema yra kokios nors kitos, platesnės sistemos komponentu, ar savarankiška sistema. Pirmuoju atveju programų sistemos reikalavimai yra išskiriami iš sistemos reikalavimų, antruoju - formuluojami apibendrinant dalykinės srities analizės rezultatus. Programų sistemos dalykinės srities analize vadinamas informacijos apie dalykinę sritį rinkimo, agregavimo, apibendrinimo ir suvokimo procesas. Analizuojant dalykinę sritį, nagrinėjami joje vykstantys procesai. Analizuojamų procesų pobūdis priklauso nuo kuriamosios sistemos pobūdžio. Pavyzdžiui, kuriant informacinę įstaigos sistemą, analizuojamas tos įstaigos padalinių darbas, o kuriant technologinių procesų valdymo sistemas, analizuojami kompiuterizuojami technologiniai procesai. Analizės metu siekiama: 1) išsiaiškinti užsakovų pageidavimus, 2) operacinius būsimų sistemos naudotojų poreikius, 3) suformuluoti kuriamosios sistemos reikalavimus, 4) sukaupti dalykinės srities specialistų naudojamų žinių bazę. Siekiama nustatyti, kokias užduotis tikslinga kompiuterizuoti ir išsiaiškinti kaip tas užduotis atlieka dalykinės srities specialistai. Reikalavimų formulavimo proceso schema: 140. Ką reikia padaryti, planuojant sisteminės analizės procesą? (2) Planuojant dalykinės srities sisteminės analizės procesą, reikia: 1) nustatyti analizės ribas, sudaryti apklausiamų asmenų ir studijuojamų dokumentų sąrašus (analizės objektas), 2) sudaryti užduočių sąrašą (analizės tikslai), 3) numatyti vykdytojus, skirti jiems darbo vietą, reikalingas darbo priemones ir lėšas (analizės resursus), 4) nustatyti užduočių vykdymo tvarką ir terminus (analizės planas). Visų pirma reikia nustatyti analizės objektą ir suformuluoti analizės tikslus. Kitaip tariant, reikia nuspręsti, kokie procesai, vykstantys dalykinėje srityje, kokiu mastu ir kokiais aspektais bus analizuojami. Deja, to dažniausiai padaryti negalima nesuformulavus kuriamosios programų sistemos naudojimo siekio. Siekio formulavimas, savo ruožtu, yra sudėtingas iteracinis procesas. Siekį suformuluoti gali tik užsakovas, nes tik jis žino, kokių tikslų siekia ir kodėl jam reikalinga kuriamoji programų sistema. Kita vertus, užsakovui sunku suformuluoti siekį, kol dar nėra analizės rezultatų. Būtent ši aplinkybė ir lemia iteracinį proceso pobūdį. Problema sprendžiama išskaidant analizės procesą į dvi dalis. Pirmiausia analizuojama dalykinės srities aplinka. Tai vadinama išorine analize. Jos rezultatų pagrindu formuluojamas preliminarinis programų sistemos naudojimo siekis. Jis gali būti netikslus ir negriežtas. Remiantis preliminariniu siekiu, planuojamas pagrindinis analizės procesas, t.y. sprendžiama, kokie procesai ir kokiais aspektais yra susiję su to siekio įgyvendinimu, bei nustatoma, kas ir kokiu mastu turi būti analizuojama. Tada pradedama vidinė dalykinės srities analizė. Jos metu preliminarinis siekis yra tikslinamas, o kartais net ir keičiamas. Pakeitus siekį, peržiūrimos analizės ribos ir keičiamas analizės planas. Taigi analizė negali būti iš karto suplanuota, nes tai - dinaminis procesas. Todėl pradinis analizės planas gali būti tik apytikris. Jį reikia nuolat tikslinti. 141. Kas tai yra programų sistemos naudojimo siekis? Kokios problemos kyla jį formuluojant? Kas tai yra išorinė ir vidinė analizė? (2) Siekis – užsakovo tikslai, kuriuos padės pasiekti kuriama PS. Norint apibrėžti analizės objektą, reikia nuspręsti: 1) kokie dalykinės srities procesai bus analizuojami, 2) kokiais aspektais jie bus analizuojami, 3) kokiu mastu tai bus daroma. To padaryti neįmanoma nesuformulavus kuriamosios programų sistemos naudojimo siekio. Tai sudėtingas iteracinis procesas. Siekį suformuluoti gali tik užsakovas, nes tik jis žino, kokių tikslų siekia ir kodėl jam reikalinga programų sistema. Kita vertus, jam sunku suformuluoti siekį, kol dar nėra analizės rezultatų. Tai lemia iteracinį proceso pobūdį. Procesas išskaidomas į dvi dalis. Pirmiausia analizuojama dalykinės srities aplinka (išorinė analizė). Jos rezultatų pagrindu formuluojamas preliminarinis siekis. Jis gali būti netikslus ir negriežtas. Remiantis preliminariniu siekiu, planuojamas pagrindinis analizės procesas (vidinė analizė), t.y. sprendžiama, kokie procesai ir kokiais aspektais yra susiję su siekio įgyvendinimu, bei nustatoma, kas ir kokiu mastu turi būti analizuojama. Vidinės dalykinės srities analizės metu preliminarinis siekis yra tikslinamas, o kartais net ir keičiamas. Pakeitus siekį, peržiūrimos analizės ribos ir keičiamas analizės planas. Taigi analizė negali būti iš karto suplanuota, nes tai - dinaminis procesas. Pradinis analizės planas gali būti tik apytikris. Jį reikia nuolat tikslinti. Atliekant išorinę analizę, dalykinė sritis traktuojama kaip tikslinės paskirties procesas (veikla. Žinant proceso vykdymo tikslus ir jų įgyvendinimo strategiją, galima formuluoti preliminarinį programų sistemos naudojimo siekį. Išorinės analizės metu nagrinėjami kompiuterizuojamo proceso ryšiai su aplinka. Proceso tikslų įgyvendinimo strategija turi būti susieta su procesais, vykstančiais dalykinės srities viduje (vidiniais procesais), nes jų vyksmas turi būti nukreiptas tai strategijai palaikyti. Todėl suformulavus kompiuterizuojamo proceso vykdymo tikslus ir tų tikslų įgyvendinimo strategiją, reikia atlikti vidinę dalykinės srities analizę ir susieti vidinius procesus su bendrąja proceso vykdymo strategija. Išnagrinėjus analizės rezultatus, gali būti nuspręsta patikslinti arba pakeisti ne tik kompiuterizuojamo proceso vykdymo tikslus. Atliekant dalykinės srities vidinę analizę, stengiamasi atsakyti į šiuos klausymus: 1) kokia yra funkcinė analizuojamos dalykinės srities struktūra ir kaip tos funkcijos tiesiogiai ar netiesiogiai palaiko suformuluotą strategiją, 2) kokie vidiniai procesai naudojami funkcijoms realizuoti, 3) kokios užduotys atliekamos vykdant vidinius procesus, 4) kokie agentai organizuoja analizuojamų procesų vykdymą, kokia atsakomybė tenka kiekvienam iš jų ir kokias užduotis jie atlieka, 5) kaip keisis tų agentų veiksmai (kokią naudą jie turės) įdiegus kuriamąją programų sistemą. 142. Kas tai yra proceso vyksmo, programų sistemos naudojimo ir laukiamos naudos kontekstinės diagramos? Kam jos reikalingos? Kaip jos sudaromos? (5) Išorinės analizės metu nagrinėjami kompiuterizuojamo proceso ryšiai su aplinka. Tam rengiama proceso vyksmo kontekstinė diagrama (pav.), kurioje nurodomi visi veiksniai, vienaip ar kitaip veikiantys proceso eigą. Pavyzdžiui, verslo proceso atveju tais veiksniais gali būti: teisinis reguliavimas, išoriniai resursai, skirstymo (pardavimo) tinklas ir pan. Nagrinėjant proceso vyksmo kontekstinę diagramą, stengiamasi atsakyti į tokius klausimus: 1) kokios yra galimybės procesui vykti (rutuliotis) ir ar jos racionaliai yra išnaudojamos? 2) kokie aplinkos veiksniai ir kaip kliudo procesui? 3) kokios yra pasirinktosios tikslų siekimo strategijos silpnosios ir stipriosios pusės? 4) ar galima technologinėmis priemonėmis padidinti, palyginus su analogiškais procesais, nagrinėjamojo proceso konkurencinę gebą? Parengus atsakymus į pateiktus klausimus, rengiama kuriamosios sistemos naudojimo kontekstinė diagrama (pav.). Joje parodoma, kokie vidiniai procesai ir kokio pobūdžio ryšius turės su kuriamaja programų sistema. Parengus sistemos naudojimo kontekstinę diagramą, procesai joje keičiami jų agentais ir ji pertvarkoma į kontekstinę laukiamos naudos diagramą (pav). Pastarojoje pavaizduoti agentai, kurie naudosis sistema, ir nauda kuri bus gauta sukūrus tą sistemą. Agentais dažniausiai esti padaliniai, atsakingi už atitinkamų procesų vykdymą. Diagrama gali būti naudojama siekiui patikrinti. Iš jos matyti, kaip pasirinktojo siekio įgyvendinimas keis vidinį kompiuterizuojamojo proceso vyksmą. Kitą vertus, diagrama gana tiksliai nusako analizės objektą ir jos tikslus. Tai išeities duomenys analizės planui parengti. Analizuojant kontekstinę laukiamos naudos diagramą, sudaromas sąrašas asmenų, kuriuos reikia apklausti analizės metu, ir sąrašas dokumentų, kuriuos reikia išstudijuoti. Parenkant apklausiamuosius, patariama vadovautis šiais kriterijais: 1) parinkti bent po vieną kiekvieno kompiuterizuojamos veiklos aspekto atstovą, 2) parinkti bent po vieną kiekvieno valdymo lygmens atstovą, 3) pirmenybę teikti linkusiems bendradarbiauti, projekto atžvilgiu palankiai nusiteikusiems ir iniciatyviems asmenims, 4) pirmenybę asmenims, įgaliotiems priimti sprendimus, 5) pirmenybę teikti asmenims, palaikantiems gerus santykius ir su savo viršininkais, ir su savo pavaldiniais. 143. Kokie informacijos rinkimo metodai naudojami sisteminėje analizėje? Trumpai apibūdinkite juos. (5) Informacijos apie dalykinę sritį rinkimu vadinamas žinių, duomenų, nuomonių ir požiūrių apie dalykinės srities struktūrą, joje vykstančius įvykius ir procesus, tų procesų vykdymo tikslus bei būdus ir tuos procesus vykdančių agentų išsilavinimą, kvalifikaciją bei tradicijas rinkimas. Pagrindiniai informacijos rinkimo metodai: 1) interviu, 2) anketavimas, 3) rašytinių šaltinių analizė, 4) naudojamų duomenų analizė ir stebėjimas. Interviu - tai iš anksto suplanuota užsakovo, kuriamosios sistemos naudotojo, dalykinės srities eksperto ar kito asmens žodinė apklausa, atliekama tikslu išsiaiškinti to asmens nuomonę konkrečiu analitikui rūpimu klausimu. Interviu tipai: 1) įvadiniai interviu: a) susipažinimas su analizės objektu, b) informacijos apie analizuojamo proceso struktūrą, paskirtį, ir funkcijas rinkimas, 2) pagrindiniai interviu (atliekami susisteminus ir apdorojus įvadinių interviu metu surinktą medžiagą; tikslas surinkti reikalavimams parengti reikalingą medžiagą): a) 1 tipas: faktų ir kitos reikalingos informacijos rinkimas: *) pirmiausia renkama informacija apie sprendžiamus uždavinius, vidinius procesus ir juos vykdančių agentų atliekamas operacijas, *) po to pereinama prie problemų ir poreikių identifikavimo, *) identifikavus problemas ir poreikius, renkamos nuomonės apie galimus problemų sprendimo būdus. b) 2 tipas: surinktų faktų verifikavimas (kadangi kai kurie surinkti faktai gali būti klaidingi, juos reikia patikrinti, dėl to rengiami antrojo tipo interviu). c) 3 tipas: interpretacijos verifikavimas (trečiojo tipo interviu reikalingi tam, kad analitikas įsitikintų, jog jis teisingai interpretuoja surinktus faktus). d) 4 tipas: surinktos informacijos papildymas ir patikslinimas (ketvirtojo tipo interviu planuojami po pirminio surinktų faktų apdorojimo). Anketavimas - tai raštiška dalykinės srities specialistų ir ekspertų apklausa pagal iš anksto parenktą klausimyną (anketą). Kuriant dideles išskirstytas sistemas, apklausiamųjų dažniausiai esti labai daug ir jie išsimėtę po didelę teritoriją. Atlikti interviu yra sunku arba iš viso neįmanoma. Be to, gali prireiktiti ne tik individualių, bet ir grupinių nuomoniu. Visas šias problemas išsprendžia anketavimas. Jį galima atlikti kompiuteriniu paštu. Anketų tipai: 1) faktams rinkti, 2) nuomonėms rinkti. Rašytinių šaltinių (įstatymų, statutų, nuostatų, nurodymų, pareigybinių instrukcijų, darbo vadovų, žinynų, įvairių dokumentų ir pan.) analizė planuojama panašiai kaip interviu arba apklausa. Visų pirma sudaromas analizės tikslų sąrašas. Po to, sudaromi analizuotinų dokumentų sąrašas ir sąrašas klausimų, į kuriuos reikia atsakyti analizuojant tuos dokumentus. Atsakymai rengiami raštu, daromos tikslios nuorodos į atitinkamus dokumentus. Panašiai analizuojami ir duomenys. Dar naudojamas aptarimas – diskusija tarp analitikų ir užsakovų, DS ekspertų bei būsimųjų PS naudotojų, kurios tikslas – įvertiniti analitikų pateiktus teiginius apie DS arbar jų siūlomus PS reikalavimus. 144. Kaip atliekami dalykinės analizės metu surinktų faktų klasifikavimas ir apibendrinimas? Kas vadinama nuostata? perspektyva? požiūriu? Kas vadinama požiūrių integravimu? Kaip jis atliekamas? (5) Faktų klasifikavimas ir apibendrinimas. Analizės metu surinkti faktai ir nuomonės retai kada būna tarpusavyje suderinti. Analitiko neturi stebinti nevienodi, netgi prieštaringi skirtingų asmenų požiūriai tuo pačiu klausimu. Žmogus visuomet mano, kad jo veikla svarbiausia, ir tai lemia jo požiūrį į visumą. Sisteminio analitiko pareiga - integruoti visus skirtingus, taip pat ir prieštaringus požiūrius ir tokiu būdu gauti objektyvius vertinimus. Labai svarbu nepasiduoti atskirų asmenų įtaigai, neleisti jiems primesti savo požiūrio. Todėl apie dalykinę sritį surinktą informaciją reikia suklasifikuoti, apibendrinti ir taip išspręsti konfliktus, Tai vadinama požiūrių integravimu. Nuostata - tai individuali arba grupinė dalykinėje srityje stebimų faktų interpretacija. Perspektyva - tai kokio nors dalykinės srities aspekto modelis, sudarytas vadovaujantis tam tikra nuostata. Požiūris - tai daugiaaspektis dalykinės srities modelis, gautas sujungus visas viena nuostata pagrįstas perspektyvas. Visų tam tikra nuostata pagrįstų perspektyvų sujungimas į vieną modelį vadinamas poziūrio konstravimu. Požiūrių konstravimas - pirmasis požiūrių integravimo žingsnis. Bendroji požiūrio konstravimo schema pavaizduota pav. Kiekvienas sukonstruotas požiūris turi būti dokumentuojamas. Požiūriui dokumentuoti naudojamas formalizmas, numatytas naudojamoje analizės metodikoje. Dokumentuojant požiūrį, butina nurodyti, kas jį išsakė ir kas yra tas asmuo (sisteminis analitikas, dalykinės srities ekspertas, užsakovas ir pan.). Šie duomenys naudojami požiūriams identifikuoti. Požiūrių integravimu vadinamas dviejų požiūrių palyginimo, jų skirtumų nustatymo, tų skirtumų klasifikavimo, vertinimo ir kompromiso paieskos procesas. Schematiškai šis procesas pavaizduotas pav. Iš pateiktos schemos matyti, kad integruojant požiūrius tenka atlikti požiūrių analizę ir požiūrių suderinimą. Požiūrių analizė apima požiūrių palyginimą, skirtumų nustatymą, tų skirtumų klasifikavimą ir vertinimą. Tai faktografinės analizės procesas. Norint suderinti požiūrius, reikia pasiekti kompromisą tarp asmenų, atstovaujančių skirtingus požiūrius. Tai daroma derybomis. Požiūriai integruojami po du. Todėl asmenų, su kuriais yra deramasi, grupė nuolat didėja. Panagrinėsime požiūrių integravimą detaliau. Jis pradedamas dviejų skirtingų požiūrių lyginimu. Lyginant du požiūrius, visų pirma sudaromas kiekvieno požiūrio terminų žodynas ir lyginamos tuose požiūriuose naudojamų terminų interpretacijos. Taip gali paaiškėti, kad kitokius požiūrius išsakę asmenys nevienodai įvardija tas pačias esybes: arba tuo pačiu vardu vadina skirtingas esybes arba savaip suvokia tas pačias esybes. Nustačius skirtinguose požiūriuose naudojamos terminijos skirtumus, reikia juos pašalinti ir sudaryti bendrą terminų žodyną. Po to požiūriai analizuojami. Rekomenduojama analizuoti kiekvieną perspektyvą atskirai. Pirmiausia analizuojama agentų perspektyva, vėliau - duomenų ir paskiausiai – procesų. Kiekvienai perspektyvai reikia: 1) nustatyti, kokie faktai yra su ja susiję, 2) aprašyti faktus vartojant bendro terminų žodyno terminus, 3) sugrupuoti faktus į tris grupes: faktus apie esybes, faktus apie veiksmus ir faktus apie agentus, 4) tarpusavyje sugretinti faktus apie: tas pačias esybes, tuos pačius veiksmus arba tuos pačius agentus, 5) sudaryti nustatytų skirtumų sąrašą. Faktais šiuo atveju vadinami esybių ryšiai. Nustačius požiūrių skirtumus, reikia juos suklasifikuoti ir įvertinti, t.y. suformuluoti kiekvieno požiūrio privalumus ir trūkumus. Įvertinus požiūrius, formuluojamos alternatyvos. Kadangi požiūriai integruojami po du, kiekvienam faktui gali būti ne daugiau kaip dvi alternatyvos 145. Kas tai yra reikalavimų specifikacija? Kokios yra pageidautinos reikalavimų specifikacijų savybės? (5) Reikalavimų specifikacija - tai dokumentas, skirtas kokio nors objekto (proceso) reikalavimams aprašyti. Kuriamos programų sistemos reikalavimai aprašomi dokumente, vadinamame programų sistemos specifikacija. Projekto, skirto programų sistemai sukurti, reikalavimai aprašomi dokumente, vadinamame projekto specifikacija. Ir vienas, ir kitas dokumentas dar yra vadinami reikalavimų specifikacija Gerai parengta reikalavimų specifikacija turi būti: 1) konceptuali, 2) suvokiama, 3) lengvai keičiama, 4) tinkama naudoti kaip žinynas, 5) konkreti, 6) tiksli, 7) darni, 8) išsami, 9) trasuojama. Reikalavimų specifikacija vadinama konceptualia, jei visi joje pateikti reikalavimai yra abstraktūs. Reikalavimų specifikacija vadinama suvokiama, jei visi joje pateikti reikalavimai yra išsamūs, glausti, unikalūs ir suformuluoti vartojant dalykinės srities terminiją. Reikalavimų specifikacija vadinama konkrečia, jei visi joje pateikti reikalavimai yra verifikuojami. Reikalavimų specifikacija vadinama tikslia, jei visi joje suformuluoti reikalavimai yra vienareikšmiai. Reikalavimų specifikacija vadinama formalia, jei ji parašyta kokia nors formalia kalba, t.y. kalba, kurios žodynas, sintaksė ir semantika yra formaliai apibrėžti. Formalizuotomis vadinamos specifikacijos, parašytos kalbomis, kurioms formaliai apibrėžti tik žodynai ir sintaksė. Reikalavimų specifikacija vadinama darnia, jei visi joje suformuluoti reikalavimai yra integruojami. Reikalavimų specifikacija vadinama išsamia, jei joje yra visi numatyti leksiniai junginiai ir specifikuoti visi iš išorės stebimi aprošomosios sistemos (proceso) elgsenos aspektai. Reikalavimų specifikacija vadinama trasuojama, jei ji yra identifikuojama, visi joje suformuluoti reikalavimai – lokalizuojami ir trasuojami. 146. Kaip yra atliekami reikalavimų specifikacijos verifikavimas ir vertinimas? Kokią specifikaciją vadiname korektiška? pagrįsta? įgyvendinama? (2) Reikalavimai verifikuojami ir vertinami, siekiant: 1) įsitikinti jų korektiškumu bei pagrįstumu, 2) išanalizuoti jų įgyvendinimo galimybes, 3) galutinai įvertinti sistemos kūrimo tikslingumą, 4) nustatyti ir kuo anksčiau pašalinti (arba bent jau kuo daugiau sumažinti) projekto rizikos veiksnius. Verifikuojant reikalavimus, bandoma atsakyti į klausimą, ar reikalavimai yra korektiški. Vertinant reikalavimus, bandoma atsakyti į klausimą, ar planuojama kurti būtent tokią sistemą, kokios užsakovui reikia ir ar ją iš tikrųjų įmanoma sukurti. Rekomenduojama, kad reikalavimus vertintų ir verifikuotų asmenys, tiesiogiai nedalyvavę juos rengiant. Planuojant reikalavimų verifikavimą ir vertinimą, reikia: 1) nustatyti, kurie reikalavimai bus verifikuojami ir vertinami (apibrėžti verifikavimo ir vertinimo objektą), 2) išreikštiniu būdu suformuluoti verifikavimo ir vertinimo tikslus, 3) nustatyti verifikavimo ir vertinimo mastą, 4) nustatyti vertinimo kriterijus, 5) nustatyti verifikavimo ir vertinimo metodus, 6) numatyti kas, kada ir kur turi atlikti planuojamus darbus, kokios priemonės ir kokie resursai tam bus reikalingi, kokie rezultatai turi būti gauti ir kaip gautieji rezultatai bus dokumentuojami ir aprobuojami. Reikalavimų specifikacija vadinama korektiška, jei ji yra konceptuali, suvokiama, konkreti, tiksli, darni, išsami, trasuojama ir tenkina darbo užduotyje numatyto dokumentavimo standarto reikalavimus. Reikalavimų specifikacija vadinama pagrįsta, jei ji yra adekvati operaciniams užsakovų ir būsimųjų sistemos vartotojų poreikiams. Reikalavimų specifikacija vadinama įgyvendinama, jei visi joje pateikti reikalavimai yra įgyvendinami. 147. Kokie yra reikalavimų verifikavimo ir vertinimo metodai? Trumpai apibūdinkite juos? (5) Reikalavimų verifikavimo ir vertinimo metodai skirstomi į rankinius, iš dalies kompiuterizuotus ir kompiuterizuotus. Svarbiausieji metodai yra šie: 1) reikalavimų lyginimas su kitų panašių sistemų ar projektų reikalavimais, 2) reikalavimų peržiūra, 3) reikalavimų inspektavimas, 4) reikalavimų pristatymas, 5) modeliavimas, 6) scenarijų testavimas. Lyginimas su analogais: Palyginti reikalavimus su analogiškų sistemų ar projektų reikalavimais galima tik tuomet, kai tiekėjas specializuojasi vienos rūšies projektuose ir turi sukaupęs pakankamą tokių projektų vykdymo patirtį. Prieš pradedant lyginti reikalavimus, reikia išreikštiniu būdu suformuluoti lyginimo tikslus ir vertinimo kriterijus bei parengti atitinkamą klausimyną. Reikalavimai vertinami atsakymų į klausimyno klausimus pagrindu. Reikalavimų specifikacijos peržiūra - tai formalizuotas reikalavimų vertinimo metodas, naudojamas norint susipažinti su peržiūrimąja specifikacija, įsitikinti, kad ji iš tikrųjų parengta, ir įvertinti joje pateiktų reikalavimų funkcinį pilnumą, pagrįstumą ir įgyvendinamumą. Reikalavimų inspektavimas - tai formalizuota daugiažingsnė reikalavimų specifikacijos korektiškumo tikrinimo procedūra. Inspektuoti galima dokumentaciją, programų kodą, duomenis, testus ir kitus projekto rezultatus. Reikalavimų pristatymas - tai grupinė reikalavimų specifikacijos peržiūra, kurios metu specifikacijos autoriai pasakoja apie jų rengtas specifikacijos dalis, o peržiūros grupės nariai juos klausinėja ir reiškia savo nuomonę apie tą specifikaciją. Reikalavimų modeliavimas: Ar reikalavimai yra įgyvendinami, kartais galima įvertinti atliekant matematinį reikalavimų modeliavimą. Matematinio modeliavimo metodai padeda įvertinti taip pat ir programų sistemos veikimo reikalavimus. Sudarant matematinį būsimosios sistemos modelį, reikalavimai formalizuojami, užrašomi diferencialinių lygčių ar kokiu nors kitu formaliu pavidalu. Sudarius matematinį sistemos modelį, jį galima analizuoti ir vertinti formaliai. Deja, tokį modelį pavyksta sudaryti tik kai kurioms sistemoms. Be to, šis darbas yra sudėtingas ir ilgai trunkantis. Matematiniam modeliavimui artimas vykdomų specifikacijų sudarymo metodas. Sistemos naudojimo scenarijų testavimas - tai eksperimentinis reikalavimų vertinimo metodas, naudojamas tikslu įvertinti specifikacijoje pasiūlytų scenarijų priimtinumą būsimiesiems kuriamos sistemos naudotojams. 148. Kokia yra dalykinės srities struktūra ir kaip ji kinta laike? Ką vadiname esybėmis ir ką jų egzemplioriais? Kokios esti esybių ir jų egzempliorių charakteristikos? ką vadiname esybių egzempliorių būsenomis? kaip vyksta būsenų pokyčiai? (5) Pagrindinis struktūrinis dalykinės srities vienetas yra esybė. Esybėmis vadinamos realaus pasaulio dalykų klasės, t.y. visa tai, ką galima apibųdinti bendriniais daiktavardžiais. skiriamos fizinės (daiktai, reiškiniai, procesai, subjektai, agentai, struktūros ir pan.) ir koncepcinės (sąvokos, idėjos ir pan.) esybės. Konkrečios esybių realizacijos (t.y. konkretųs daiktai, reiškiniai, procesai ir pan.) vadinami esybių egzemplioriais. Pavyzdys: Asmuo yra esybė, o konkretus asmuo – jos egempliorius. Visų vienos esybės egzempliorių charakteristikos yra vienodos. Jos skirstomos į aprašomąsias, operacines ir organizacines. Analizės metu analizuojamos ir esybių, ir jų egzempliorių charakteristikos, tačiau toliau dažniausiai kalbėsime apie esybių egzempliorių charakteristikas. Aprašomosiomis vadinamos charakteristikos, nustatančios esybės arba jos egzempliorių individualias ypatybes. Aprašomosiomųjų harakteristikų kategorijos: • fizinės (dydis, forma, svoris) • chronologiniai duomenys (gimimo data) • buvimo vieta (gimimo vieta) • nefizinės charakteristikos (kaina) • kvalifikacija (pareigos) • tarpiniai arba galutiniai veiklos rezultatai • duomenys apie esybės dalivavimą kokioje nors veikloje dabar, praeityje arba ateityje • duomenys apie esamą, ankstesnę arba būsimą esybės būseną. Organizacinėmis vadinamos charakteristikos, nustatančios esybės arba jos egzempliorių ryšius su tos pačios ar kitos esybės egzemplioreis. Operacinėmis charakteristikomis vadinami veiksmai, keičiantys esybės egzemplioriaus būseną. Pavyzdys: esybei asmuo vedybos, profesijos įsigyjimas traktuojami kaip įvykiai, keičiantys tos esybės egzempliorių būsenas. Esybės ekzemplioriaus būsenomis vadinamos vienareikšmiškai nusakomos to ekzemplioriaus apraiškos. Ekzemplioriaus būsena nusakoma jo reikšme (t.y. aprašomųjų ir organizacinių charakteristikų reikšmių visuma) ir toje būsenoje leistinos esybės egzemplioriaus elgsenos taisyklėmis. Būsenos nėra statinės. Jos kinta laikuin bėgant. Būsenas keičia dalykinėje srityje vykstantys įvykiai. Bet kuris įvykis veikia ne visas, o tik tam tikras esybes ir keičia tik tam tikrų jo veikiamų esybių egzempliorių būsenas. Įvykiai patys savaime būsenų nekeičia. Jie tik inicijuoja tam tikrus veiksmus, keičiančius atitinkamų aprašomųjų arba organizacinių charakteristikų reikšmes. Kokie veiksmai gali būti potencialiai atlikti, nusakomi operacinėmis esybės charakteristikomis. Kokie iš jų gali būti atlikti su konkrečia esybės egzemplioriaus būsena, nusakoma toje būsenoje esybės egzemplioriaus elgsenos taisyklėmis. Pažymėsime, kad visi tos pačios esybės egzemplioriai įgyja tas pačias būsenas ir kad visų jų elgsena reglamentuojama tomis pačiomis elgsenos taisyklėmis. 149, Ką vadiname modeliu? Kokios esti modelių rūšys? (5) Modelis – aiškiai nusakytą tikslinę paskirtį turintis supaparstintas sistemos, proceso, reiškinio ar kito originalo analogas, tapatus orginalui modeliavimo tiklsų atžvilgiu. Rūšys: struktūrinis – atsoindi tik struktūrines originalo savybes imitacinis – imituoja originalo elgseną kompleksimis – struktūrinis + imitacinis Pagal realizavimo būdą fizinis – materialus originalo analogas abstraktus – teisingų tvirtinimų ir teiginių apie originalo savybes bei charakteristikas rinkinys, interpretuojamas pakankamai vienareikšmiškai. Lingvistinis modelis – originalo aprašas natūraliąja kalba arba spec. pokalbiu modeliavimo tikslams. 150. Iš kokių dalių sudarytas informacinio modeliavimo formalizmas? Trumpai apibūdinkite jas? (formalią apibrėžtį pateikti nebūtina) (5) F=
Šį darbą sudaro 27828 žodžiai, tikrai rasi tai, ko ieškai!
★ Klientai rekomenduoja
Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?
Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!
Norint atsisiųsti šį darbą spausk ☞ Peržiūrėti darbą mygtuką!
- Programavimo špera
- 12 psl., (27828 ž.)
- Word failas 775 KB
Atsisiųsti šią šperą
Mūsų mokslo darbų bazėje yra daugybė įvairių mokslo darbų, todėl tikrai atrasi sau tinkamą!
Panašūs darbai
Privalumai
Darbo pakeitimo garantija
Atsisiuntei rašto darbą ir neradai jame reikalingos informacijos? Pakeisime jį kitu nemokamai.
Gauk 25% nuolaidą
Pirkdamas daugiau nei vieną darbą, nuo sekančių darbų gausi 25% nuolaidą.
Greitas aptarnavimas
Išsirink norimus rašto darbus ir gauk juos akimirksniu po sėkmingo apmokėjimo!
Atsiliepimai
