Sistemų inžinerijos kompromisas. 2. Prekybos sistemos analizės grupė. Pagrindiniai programinės įrangos kūrimo metodai

sistemų inžinerijos kompromisas

Kokie yra svarbiausieji inžinerijos ir amato skirtumai? 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. Jis paprastai nežino, kokia tvarka, kuo remiantis ir kokie sprendimai buvo priimti.

Inžinerija: 1 Gaminio kokybė ir kiti ribojimai nustatomi, remiantis ekonominio tikslingumo kriterijais. Jie fiksuojami reikalavimų specifikacija ir sandoriu kontraktu. Tačiau vien teorinių žinių inžinieriui nepakanka. 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ūdukokybė planuojama, atsižvelgiant į ekonominio tikslingumo kriterijus. Baigdami pastebėsime, kad programų sistemų inžinerija sistemų inžinerijos kompromisas tai naujo tipo inžinerinė disciplina, at tsiradusi jungiant technikos, matematikos ir socialinių mokslų pasiekimus.

Kokios yra jos apraiškos? Trumpai jas apibūdinkite. 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. 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.

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ų sistemų inžinerijos kompromisas ir netikę darbo organizavimo būdai.

Jei sistema ir daro beveik tą, ką turi daryti, tačiau dirba visai ne taip, kaip tikimasi. Kokie yra sv varbiausi pramoninio programavimo ypatumai? Trumpai apibūdinkite juos. 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. 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.

Sistemos architektūros kompromisų analizės metodas

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ų sistemų inžinerijos kompromisas priemonių. 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ų pr rogramų paketai.

Paketų koncepcija sistemų inžinerijos kompromisas suformuluota apie 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 sistemų inžinerijos kompromisas 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 binariniai opcionai porcelianas, 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.

#LaisveErdveVeikti Informatika ir informatikos inžinerija

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ą sistemų inžinerijos kompromisas skaičių, programų patikimumą, naudojimo patogumą ir kitus kokybės parametrus nu ustato standartai, reikalavimų specifikacija, kontraktas bei kiti dokumentai. Tačiau reikia išmokti kokybę ne vomma opciono prekyba 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 sistemų inžinerijos kompromisas 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 sistemų inžinerijos kompromisas gamybos pobūdis, 4 kokybės planavimas ir valdymas, 5 produkto nuasmeninimas, 6 planingas gamybos pobūdis, 7 griežti teoriniai pagrindai.

Kokius komponentus reikia sukurti, kuriant programų sistemą? Ką reikia padaryti, kad sukurtų komponentų rinkinys taptų sistema? Būtina bet kokios programų sistemos sudėtinė sistemų inžinerijos kompromisas — jos naudojimo instrukcijos. Kas svarbiau: klaida programoje ar jos naudojimo instrukcijoje? Abiem atvejais rezultatas yra tas pats: arba programų sistema apskritai neveikia, arba ji veikia ne taip, kaip numatyta jos reikalavimų specifikacijoje.

Kokiais aspektais galima nagrinėti programų sistemą, ją kuriant?

Kur stoti | Informacinių sistemų inžinerija Utenos kolegijoje

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. Kas nusako išorinę programų sistemos elgseną?

Kas nusako vidinę programų sistemos elgseną? Vidinę programų sistemų inžinerijos kompromisas elgseną nusako programų sistemos architektūra. Išorinis aspektas: Nagrinėjamos tos programų sistemos sistemų inžinerijos kompromisas, 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 honkongo akcijų opcionų prekyba 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 sistemų inžinerijos kompromisas, 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. 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? Programų sistemos architektūros aprašas nusako sistemos konstrukcinius elementus, jų vykdomas funkcijas, sąveikos būdus ir juos siejantį konstrukcijos santykį.

Kokie yra svarbiausieji inžinerijos ir amato skirtumai?

Sistemos architektūros aprašas yra vadinamas jos eskiziniu sistemų inžinerijos kompromisas. Eskiziniu projektavimu vadinamas kuriamosios programų sistemos funkcinės, modulinės, duomenų ir interfeiso architektūros projektavimo procesas.

Dokumentas, kuriame aprašomi prekyba reiškia grįžimą su opcionais 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. Kas vadinama programų sistemos dalykine ir kas problemine sritimi? Šiuolaikines programų sistemos dažniausiai taip kuriamos, kad jomis galėtų be tarpininku naudotis dalykines srities specialistai.

Tokios sistemos vadinamos specialios sistemų inžinerijos kompromisas dalykines sistemų inžinerijos kompromisas 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ė sistemų inžinerijos kompromisas. Programų sistemos problemine sritimi angl. Problem domain vadinama jos sprendžiamų uždavinių visuma.

Kas vadinama programų sistemų inžinerija? 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.

Informacinių sistemų inžinerija Utenos kolegijoje

Programų sistemų inžinerija — teorinis pramoninio programavimo pagrindas. Kokios yra programų sistemų inžinerijos pagrindinės dalys? Ką nagrinėja reikalavimų inžinerija? Kokios yra jos pagrindinės dalys? 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ą.

sistemų inžinerijos kompromisas

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.

sistemų inžinerijos kompromisas

Š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 sistemų inžinerijos kompromisas, 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.

sistemų inžinerijos kompromisas

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. Kas tai yra sistemų analizė? Ką ji nagrinėja?

Koks pagrindinis sistemų analizės tikslas?

Galbūt jus domina