Programų sistemų inžinerijos špargalkė dokumentas
5 (100%) 1 vote

Programų sistemų inžinerijos špargalkė dokumentas

1. Kokie yra svarbiausieji inžinerijos ir amato skirtumai?(3) 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 talentas, 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ę discipliną 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.

Dirbant amatininkiškais metodais, produkto kokybė dažniausiai yra užsakovo norų ir realių produktą kuriančio kolektyvo galimybių kompromiso rezultatas. Taikant inžinerinius metodus(produktą gaminant pramoniniu būdu), kokybė planuojama, atsižvelgiant į ekonominio tikslingumo kriterijus.

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 jas apibūdinkite. (5) Programavimo krizė – tai aklavietė, kurioje atsiduria programavimas dėl tam tikrų priežasčių: uždavinių algoritmizavimo, naujų kompiuterių resursų, galimybių išnaudojimo.

Programavimo krizė pasireiškia trim pagrindiniais aspektais: 1) augančiomis sąnaudomis programų sistemoms kurti ir prižiūrėti; 2) nuolatiniu planuotų terminų žlugdymu; 3) naudotojų reiškiamu nepasitenkinimu gaunamos programinės įrangos kokybe.

1)Programinės įrangos tiražavimo, diegimo, modernizavimo bei priežiūros sąnaudos pradeda gerokai viršyti kūrimo sąnaudas. Valstybės mastu tai didžiulės sumos, didėjančios kartu su skaičiavimo technikos naudojimo sferos plėtote. Priežasčių, lemiančių tokią padėtį, yra daug. Svarbiausios – standartizacijos stoka, žemas programavimo darbų automatizavimo laipsnis, nekokybiška projektinė dokumentacija ir netinkamas projekto vykdymas.

2)Programinis projektas nebaigiamas laiku: vėluoja eksploatavimo dokumentacija; daug laiko praeina nuo sistemos sukūrimo iki jos įdiegimo. Būna ir taip, kad sistema pasensta anksčiau negu ji baigiama. Šiuos trūkumus taip pat lemia blogas planavimas, žemas darbo našumas, naudojamų technologijų neefektyvumas ir netikę darbo organizavimo būdai.

3)Sistemos yra visai ne tokios, kokiomis naudotojai jas įsivaizduoja. Jei sistema ir daro beveik tą, ką turi daryti, tačiau dirba visai ne taip, kaip tikimasi. Pvz.: automatizuojant vieną ar kitą veiklos sritį, ji dažniausiai iškelia naudotojams nelauktų problemų, tokių kaip, duomenų paruošimas ir analizė, mažas patikimumas, sąveikos sudėtingumas, modernizavimo sunkumai ir kt.

3. Kokie yra svarbiausi pramoninio programavimo ypatumai? Trumpai apibūdinkite juos. (5) Kuriant sistemas pramoniniu būdu, turi būti užtikrinta, kad sistemos bus pateikiamos naudotojams laiku, nebus viršijamas skirtas biudžetas, bus garantuota sukurtos sistemos kokybė ir tenkinama daug kitų reikalavimų. Be to, šiam tikslui naudojamos priemonės turi būti pritaikytos kolektyvinio pobūdžio darbui. Taip pat reikia atsižvelgti į tai, kad kolektyvuose, kuriančiuose programų sistemas, tenka bendradarbiauti skirtingo profilio specialistams.

Programuotojų darbo našumas: Programavimo automatizavimo priemonės (transliatoriai, redaktoriai ir pan.) pradėtos kurti dar šeštajame dešimtmetyje, tačiau jos palengvino tik programų rašymą, o tai tik penktadalis ar net dešimtadalis visos darbų apimties. Programavimo metodika, technologija bei darbų organizavimas pradėti tobulinti aštunto dešimtmečio pradžioje, bet tai leido amatininkiškus darbo metodus pakeisti tik manufaktūriniais, bet ne pramoniniais. Projektavimo, dokumentavimo ir daugelį kitų darbų rimtai pradėti automatizuoti tik aštuntojo dešimtmečio pabaigoje. Sukaupta instrumentinių priemonių kūrimo patirtis pirma kartą buvo apibendrinta viename iš JAV gynybos ministerijos projektų. Jame, be plačiai žinomos programavimo kalbos ADA ir jos transliatorių, į bendrą sistemą buvo sujungta dar virš šimto įvairių instrumentinių priemonių. Instrumentinių sistemų srityje Pentagonas ir NASA tebepirmauja po šiai dienai. Masiškai automatizavimo priemones buvo pradėta naudoti tik devintojo dešimtmečio viduryje, kuomet masiškai pradėta naudoti personalinius kompiuterius.

Serijinė gamyba: Taikomųjų programų paketai: Pereiti prie programų serijinio gamybos būdo įgalino taikomųjų programų
paketai. Paketų koncepcija buvo suformuluota apie 1966 metus, tačiau iki reikiamo lygmens buvo ištobulinta tik atsiradus personaliniams kompiuteriams ir susiformavus pakankamai didelei rinkai..

Užsakymas ir rinka: Tiražuoti daugeliu egzempliorių tikslinga tik sistemas, tenkinančias didelės naudotojų klasės poreikius. Todėl tenka atsisakyti pagal individualius užsakymus atliekamo unikalių sistemų kūrimo ir persiorientuoti į abstraktaus, statistinio naudotojo poreikius. Tokių poreikių nustatymas reikalauja gilaus rinkos tyrimo. Šitaip suformuluoti programų sistemos reikalavimus žymiai sudėtingiau negu dirbant su konkrečiu užsakovu. Dirbant rinkai negalima išsiversti ir be kokybės planavimo.

Serijinės gamybos privalumai: Tiražavimo išlaidos yra daug mažesnės negu naujos sistemos kūrimo, tad serijinė gamyba atpigina programinės įrangos kainą. Be to, tai teigiamai veikia standartizacijos procesus, nes kai kurios sistemos paplinta taip plačiai, kad susiklosto vadinamieji de facto standartai, kurie palaipsniui perauga į de jure standartus.

Kolektyvinis gamybos pobūdis: Dideles programų sistemas kuria dideli kolektyvai. Grupinis darbas nuo individualaus visų pirma skirias tuo, kad tuo pat metu yra vykdomi keli projektai ir kolektyvo nariams tenka specializuotis atskirų užduočių vykdymui (projektavimas, programavimas, testavimas ir kt.). Užduotys perduodamos iš rankų į rankas, todėl kyla standartizavimo, planavimo, kontrolės ir kitos projekto valdymo problemos.

Kokybės planavimas ir valdymas: Dirbant pramoninio programavimo metodais kokybė planuojama atsižvelgiant į ekonominio tikslingumo kriterijus. Leistiną klaidų skaičių, programų patikimumą, naudojimo patogumą ir kitus kokybės parametrus nustato standartai, reikalavimų specifikacija, kontraktas bei kiti dokumentai. Tačiau reikia išmokti kokybę ne tik planuoti, bet ir kontroliuoti. Taigi, reikia išmokti ją matuoti. Deja kol kas tą mokama daryti tik iš dalies.

Standartai: Kolektyvinis gamybos pobūdis ir darbų automatizavimas neįmanomi be standartizacijos ir kuriamų produktų nuasmeninimo. Be standartizacijos neįmanomas ir programų tiražavimas dideliu mastu . Sistemos ir atskirų jos modulių struktūrą, realizavimo metodus ir apipavidalinimą turi lemti pasirinkti standartai, o ne atskirų programuotojų kvalifikacija ar skonis. Šiandien jau turime gana aukštą standartizacijos lygį. Pradeda dominuoti vadinamosios atvirosios sistemos, sukurti šimtai tarptautinių standartų. Tačiau Lietuvoje jie vis dar yra nepakankamai žinomi ir taikomi praktikoje.

Projektų valdymas: Kuriant programų sistemas, prognozuoti darbų apimtį, vertinti gaminio užbaigtumo laipsnį ir organizuoti pastovų darbų ritmą gerokai sunkiau, negu, tarkime, gamyboje, nes programuotojo darbas – tai visų pirma projektuotojo, konstruktoriaus darbas, todėl nustatyti normatyvus bei planuoti lėšas yra sudėtinga. Tačiau konstruktorių biuruose sukaupta panaši (techninių sistemų projektavimo patirtis) ir devintajame dešimtmetyje ją pradėta taikyti programų sistemų kūrimo projektams valdyti. Pasiūlyta keletas programų kūrimo projektų valdymo būdų, paremtų tinklinio planavimo ir valdymo metodais. Dažniausiai jie naudojami didelėse firmose, nes smulkūs kolektyvai yra nepajėgūs sukurti atitinkamą infrastruktūrą. Jiems tai per brangu.

Ypatumai: 1) aukštas darbų automatizavimo lygis, 2)serijinė gamyba, 3) kolektyvinis gamybos pobūdis, 4) kokybės planavimas ir valdymas, 5) produkto nuasmeninimas, 6) planingas gamybos pobūdis, 7) griežti teoriniai pagrindai.

4. Kokius komponentus reikia sukurti, kuriant programų sistemą? Ką reikia padaryti, kad sukurtų komponentų rinkinys taptų sistema? (1) Programų sistema – tai integruota programų, failų, duomenų bazių ir žinių bazių visuma, skirta tam tikros klasės uždaviniams spręsti arba tam tikriems įrenginiams ar procesams valdyti. Būtina bet kokios programų sistemos sudėtinė dalis – jos 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. Abiem 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šorinę programų sistemos elgseną nusako jos elgesys pastebimas iš išorės. Vidinę programų sistemos elgseną nusako programų sistemos architektūra.

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.
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 jos 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ūros 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 dalykine ir kas problemine sritimi? (1) Programų sistemos taikymo sritis vadinama dalykine sritimi. Šiuolaikines programų sistemos dažniausiai taip kuriamos, kad jomis galėtų be tarpininku naudotis dalykines srities specialistai. Tokios sistemos vadinamos specialios arba dalykines paskirties sistemomis. Dalykines paskirties sistemos turi sudaryti naudotojams sąlygas formuluoti užduotis vartojant įprastus jų profesines veiklos terminus, nutylint neesmines detales ir galbūt remiantis negriežtoms ir nevienareikšmėmis formuluotėmis. Tokius reikalavimus tenkinančios programų sistemos vadinamos intelektualizuotomis. Jų architektūra būna labai sudėtinga ir be PSI metodų tokias sistemas sukurti praktiškai neįmanoma.

Programų sistemos taikymo sritis – dalykinė sritis.

Programų sistemos problemine sritimi(angl. Problem domain) vadinama jos sprendžiamų uždavinių visuma.

10. 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.

Programų sistemų inžinerija – tai naujo tipo inžinerinė disciplina, atsiradusi jungiant technikos, matematikos ir socialinių mokslų pasiekimus. Programų sistemų inžinerija – teorinis pramoninio programavimo pagrindas.

11. 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ų diegimas ir priežiūra.

12. 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.

13. Kas tai yra sistemų analizė? Ką ji nagrinėja? Koks pagrindinis sistemų analizės tikslas? (1) Sistemų analizė – tai sistemos skaidymo į sudėtines dalis procesas, vykdomas siekiant suvokti analizuojamosios 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.

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.

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ą.

Šiuo metu Jūs matote 30% šio straipsnio.
Matomi 2546 žodžiai iš 8467 žodžių.
Peržiūrėkite iki 100 straipsnių per 24 val. Pasirinkite apmokėjimo būdą:
El. bankininkyste - 1,45 Eur.
Įveskite savo el. paštą (juo išsiųsime atrakinimo kodą) ir spauskite Tęsti.
SMS žinute - 2,90 Eur.
Siųskite sms numeriu 1337 su tekstu INFO MEDIA ir įveskite gautą atrakinimo kodą.
Turite atrakinimo kodą?
Po mokėjimo iškart gausite atrakinimo kodą, kurį įveskite į laukelį žemiau:
Kodas suteikia galimybę atrakinti iki 100 straispnių svetainėje ir galioja 24 val.