Ais projektų valdymas. AIS „Projektų valdymas. Pagrindinės AIS dizaino koncepcijos

Yra daug AIS kūrimo metodų ir variantų, kurių naudojimas priklauso nuo įvairių veiksnių, pavyzdžiui, įmonių dydžio ir (ar) jų IS, IS sukūrimo tikslo, turimų išteklių ir kt. IS aptariami ankstesniuose skyriuose.

Programinės įrangos projekto gyvavimo ciklas yra programinės įrangos kūrimo etapų ir etapų visuma, pradedant sistemos analize ir pradinių reikalavimų kūrimu, baigiant jos įdiegimu (įdiegimu) kompiuteryje.

Įvairių AIS klasių kūrimo ir diegimo patirtis parodė didelį jų taikymo efektyvumą (įskaitant ekonominį), ypač didelėse įmonėse. Tai atsispindi gerame darbo ir gamybos organizavime, didinant planuojamų ir įgyvendinamų užduočių vykdymo tikslumą, užtikrinant įmonės ritmą, mažinant rankų darbo dalį, veiksmingą (įskaitant operatyvinę) informacijos palaikymą įvairių kategorijų naudotojams, ir kt. Vidutinis tokių sistemų atsipirkimo laikotarpis paprastai neviršija dvejų metų.

Kuriant IS, daugeliu atvejų pirmenybė teikiama standartiniams projektavimo sprendimams, pritaikytiems konkrečioms Kliento sąlygoms ir galimybėms. Individualūs projektai rengiami nesant standartinių sprendimų arba kai pagrindiniai organizacijos parametrai labai skiriasi (daugiau nei 10-15%) nuo standartinių sprendimų. Paprastai tai taikoma didelėms ir didžiausioms organizacijoms.

Jokia IC kūrimo schema nėra absoliuti. Galimi įvairūs variantai, pavyzdžiui, atsižvelgiant į pradines vystymo sąlygas: kuriama visiškai nauja sistema; įmonės apklausa jau atlikta ir yra jos veiklos modelis; įmonė jau turi IS, kuri gali būti naudojama kaip pradinis prototipas arba turėtų būti integruota į sukurtą.

Išsamus AIS projekto kūrimas reiškia, kad yra visas organizacinės, projektinės, technologinės ir eksploatacinės dokumentacijos rinkinys.

Bet kokio objekto projektavimas atliekamas naudojant:

• a) nustatyti jo funkcinę paskirtį (kodėl to reikia, ką ir kaip suprojektuotas objektas daro),
• b) nustatyti loginius ryšius (kaip suprojektuotas objektas atlieka savo funkcinę paskirtį, kokia informacija yra apdorojama ir kokia seka),
• c) materialinių priemonių pasirinkimas projektuojamam objektui įgyvendinti - funkcinis, technologinis ir techninis aspektas (laikmenos, duomenų apdorojimo įrankiai ir kt.),
• d) materialinių pardavimo priemonių erdvinis (teritorinis) išdėstymas tam skirtose ar galimose naudoti srityse,
• e) suprojektuoto objekto organizacinės ir valdymo struktūros formavimas (padalinių sudėtis, įgaliojimai ir funkcinės pareigos darbininkai)

Pasirinkus AIS projektavimo metodą, būtina suplanuoti darbų rinkinį, kad būtų sukurta sistema pagal tipinius jos kūrimo etapus. Projektą peržiūri ir patvirtina užsakovas. AIS dizainas apima tam tikrų etapų ir etapų įgyvendinimą.

Sėkmingam projekto įgyvendinimui būtina nustatyti tikrus etapus su aiškiai pažymėta pradžia ir pabaiga. Detaliojo darbo plano rengimas yra susijęs su kiekviename etape atliekamų procesų ir jų sekos aprašymu, reikiamais specialistais, lėšomis ir ištekliais. Šis metodas labiau padeda išvengti aplaidumo ir klaidų. Tai būtina darbuotojams, įgyvendinantiems automatizavimo projektą, taip pat turi teigiamą poveikį jį finansuojantiems asmenims.

Efektyvus etapinis projektavimo darbų įgyvendinimas yra susijęs su poreikiu parengti jų įgyvendinimo grafiką, įskaitant išteklius ir jų įgyvendinimo laiką (etapus) (žr. Ankstesnius grafikus ir skaičius). Ištekliai apima reikiamą personalą, techninę įrangą, programinę įrangą, finansavimą ir infrastruktūrą. Tuo pačiu metu geriau jį finansuoti atskirai kiekvienam darbo tipui (lėšų ir programinės įrangos pirkimas, diegimas, mokymai, individualūs projektavimo etapai ir kt.).

Dėl automatikos skirtingi tipai veiklai (valdymas, projektavimas, tyrimai ir kt.), įskaitant jų derinius, naudojamos GOST 34.601-90 nuostatos. Jame numatyti šie projektavimo etapai ir etapai (1 lentelė).

2 lentelė

Standartas taip pat nurodo, kad:

• · Organizacijos, dalyvaujančios kuriant AS, etapai ir etapai yra nustatyti pagal šį standartą sudarytose sutartyse ir techninėse užduotyse.
• · Leidžiama neįtraukti etapo „Projekto projektas“ ir atskirus darbo etapus visuose etapuose, sujungti „Techninį projektą“ ir „Darbo dokumentus“ į vieną etapą „Techninis darbinis dizainas“. Atsižvelgiant į kuriamų AE specifiką ir jų sukūrimo sąlygas, leidžiama atlikti atskirus darbo etapus iki ankstesnių etapų pabaigos, lygiagrečiai vykdant darbų etapus, įtraukiant naujus darbo etapus.

Techniniame projekte (preliminariame projekte) yra kūrimo objekto ir jo komponentų schemos ir projektinė dokumentacija, pasirinktų gatavų programinės įrangos įrankių sąrašas ir Techninė pagalba(įskaitant kompiuterių tipus, operacines sistemas, taikomąsias programas ir kt.), naujų programinės įrangos įrankių kūrimo problemų sprendimo algoritmus).

Detalusis dizainas - paskutinis projektavimo etapas, apskritai numatantis ankstesnių etapų rezultatų patobulinimą ir detalizavimą, automatikos objekto prototipo sukūrimą ir bandymą, programinės įrangos produktų kūrimą ir bandymą, technologinę ir eksploatacinę dokumentaciją.

Šiuolaikinėje automatinių informacinių sistemų (pvz., AIPS, ASNTI, ACS ir kt.) Projektavimo praktikoje tai gali būti pradinis jų įgyvendinimo etapas projekto užsakovo organizacijos ar tarnybos darbe. vienas iš daugelio kitų automatizuotų organizacijų, paslaugų ir kt.

Išsamus sistemos projekto kūrimas reiškia, kad yra visas organizacinės, projektinės, technologinės ir eksploatacinės dokumentacijos rinkinys.

Valstybinis standartas GOST 19.102-77 nustato šiuos programinės įrangos dokumentacijos kūrimo etapus:

• 1. Darbo sąlygos;
• 2. Projekto projektas;
• 3. Techninis projektas;
• 4. Darbinis projektas;
• 5. Įgyvendinimas.

Atminkite, kad mažiems projektams etapų skaičių galima sumažinti.

Vykdant pirmąjį etapą „Reikalavimų AS formavimas“, objektas apžiūrimas ir būtinybė sukurti AIS yra pateisinama, atsižvelgiant į vartotojo reikalavimus suprojektuotai AIS. Šios pirmojo projektavimo etapo procedūros yra išankstinio projektavimo tyrimo dalis. Tai taip pat gali apimti antrojo projektavimo etapo „AE koncepcijos kūrimas“ procedūras.

Atliekant išankstinio projektavimo tyrimus, atliekama galimybių studija dėl AIS sukūrimo galimybių; bendrųjų AIS kūrimo reikalavimų kūrimas.

Atliekant išankstinio projektavimo tyrimą, skirtą įgyvendinti būtinus projektavimo darbus, nustatoma:

• · materialinius išteklius,
• · finansiniai ištekliai,
• · Žmogiškieji ištekliai,
• · Laikini ištekliai.

Šiuo metu bet kuri organizacija gali turėti tam tikrų materialinių išteklių, kurie paprastai yra nevienalytės kilmės. Siekiant užtikrinti šių išteklių saugumą, būtina saugoti įrašus ir paskirti atsakingus asmenis. Šios problemos sprendimas gali būti atliktas naudojant įvairias programas, tokias kaip 1C: Enterprise, AVARD ir daugelis kitų. Tačiau šios programos yra labai brangios tiek perkant, tiek prižiūrint. Reikalauti specialaus išsilavinimo ir personalo mokymo.

Pagal dizainą turėtų suprasti siūlomo ar galimo objekto prototipo kūrimo procesą.

Šiuolaikinės AIS kūrimo technologijos yra veiksmingų projektavimo įrankių ir metodų, kurie supaprastina šį procesą, sumažina sąnaudas, sutrumpina sistemos projektavimo laiką ir pagerina kūrimo kokybę, derinant platų patikrintų pažangių dizaino sprendimų derinį.

Prie pagrindinio projektavimo įrankiai galima priskirti:

Tipiški dizaino sprendimai (TPD) ir programų paketai (PPP). TPR - algoritminių ir programinės įrangos elementų rinkinys, užtikrinantis užduočių įgyvendinimą kompiuteryje, pasitelkiant atitinkamas technines priemones;

Kompiuterinės projektavimo sistemos (CAD), apimančios kompiuterių naudojimą visuose AIS kūrimo etapuose.

Bendrieji projektavimo įrankių reikalavimai:

Pilnas viso AIS kūrimo proceso aprėptis;

Suderinamumas, t.y. nuoseklumas tiek sistemos kūrimo, tiek jos veikimo procese;

Universalumas, t.y. galimybė naudoti tuos pačius įrankius skirtingiems objektams;

Prieinamumas kuriant ir paprastumas (paprastumas) įgyvendinant;

Galimybė organizuoti projektavimo procesą interaktyvios sistemos kūrėjo, dizainerio ir kompiuterio sąveikos režimu;

Prisitaikymas ir ekonomiškumas.

Tarp projektavimo metodai skirti:

Originalus dizainas;

Tipiškas dizainas ir jo tipai: elementinis, posistemis, modulinis, grupinis;

Dizainas padarytas kompiuterio pagalba.

Originalus projektavimo metodas yra tradicinis ir orientuotas į vieną konkrečią įmonę. Būdingas bruožasŠis metodas yra originalių objektų apžiūros metodų kūrimas ir būtinos dokumentacijos sukūrimas individualaus projekto forma. Šio metodo pranašumas yra specifinių automatizavimo objekto savybių atspindys AIS projekte. Trūkumai yra gana didelis darbo intensyvumas ir ilgas vystymosi laikas, žemas funkcinio patikimumo ir prisitaikymo prie kintančių sąlygų rodiklis. Tačiau originaliu metodu sukurti projektai gali būti modernizuojami gryna formašis metodas naudojamas retai. Šiandien jo įgyvendinimo metu naudojamos įvairios projektavimo priemonės, ir tik tam tikroms projekto dalims reikia originalių dizaino sprendimų. Tai šiek tiek išlygina jo trūkumus. Tačiau šis metodas išlieka aktualus automatizuojant sudėtingus, nepaprastus objektus.

V šiuolaikinėmis sąlygomis AIS paprastai nėra kuriama nuo nulio. Šiuo metu ekonomikoje, beveik visuose valdymo lygiuose ir visuose ekonominiuose objektuose veikia automatizuotos informacijos apdorojimo sistemos. Dėl padidėjusio savalaikės, kokybiškos ir operatyvios informacijos poreikio būtina sukurti naują techninę ir technologinę AIS.

Racionalių projektavimo būdų paieška vyksta šiomis kryptimis:

1. standartinių dizaino sprendimų, įdiegtų taikomojoje programinėje įrangoje (PPP), kūrimas, siekiant išspręsti ekonomines problemas ir vėliau susieti PPP su konkrečiomis įgyvendinimo ir veikimo sąlygomis;

2. automatizuoto projektavimo sistemų kūrimas.

Pirmasis būdas yra galimybė naudoti standartinius dizaino sprendimus, įtrauktus į taikomųjų programų paketus.

Tipiškas dizainas- pramoninis AIS kūrimo metodas naudojant TPR ir PPP. Šiam metodui būdingos patikrintos, standartinės organizacinės-ekonominės, techninės, informacinės, matematinės ir programinės įrangos valdymo automatizavimo priemonės. Taikant šį metodą, galima sumažinti darbo intensyvumą, sumažinti išlaidas ir sutrumpinti projektavimo laiką bei pagerinti dizaino kokybę. Įprastą projektavimo procesą sudaro atrankos posistemių parinkimas ir surišimas pagal konkrečios AIS reikalavimus. Tipiška AIS dalis yra informacijos, programinės ir techninės įrangos kompleksas. Tipiškas informacijos palaikymo pobūdis pasiekiamas griežtai laikantis informacinės bazės struktūros vienybės, masyvų sudėties, įvesties ir išvesties dokumentų formų. Tipiškas programinės įrangos pobūdis pasiekiamas naudojant PPP, o tipinis techninės pagalbos pobūdis - naudojant to paties ar kombinuoto tipo kompiuterius.

1. Tipiško projektavimo metodo variantas yra metodas elementarus dizainas, kuri remiasi TPR. Kuriant projektą naudojamas paruoštas sprendimas su nedideliais pakeitimais, o naujas nėra kuriamas.

2. Kai naudojate modulinis metodas TPR yra kuriami moduliniu būdu, kai kiekvienas dizaino sprendimas yra padalintas į atskiras komponentines dalis - modulius, įgyvendinančius tam tikrą TPR dalį. Tai leidžia jums sukurti naujos automatizuotos sistemos projektą, derinant atskirus standartinius modulius.

3. Kai naudojate posistemio projektavimo metodas kiekvienam posistemiui sukuriami sprendimų projektai ir programų paketai - visos sistemos ir funkcionalūs. Posistemių paskirstymas priklauso nuo ekonominio ir gamybos proceso objekto. Kiekvienam posistemiui yra sukurtas jo automatinis projektavimo sprendimas ir PPP, kurie gali būti visos sistemos arba funkcionalūs. Visos sistemos VPSP apima duomenų valdymo PPP, standartinių duomenų apdorojimo procedūrų PPP, matematinės statistikos ir atskiro programavimo metodus ir tt ir sektorių valdymas.

Svarbus RFP reikalavimas yra suderinamumas, nes kuriant AIS, patartina naudoti kelis paketus vienu metu. Sistemų, naudojančių PPP, dizainas iš tikrųjų yra sumažintas iki paketų, parinktų pagal tam tikrus parametrus, susiejimo su konkrečiomis automatizavimo objekto sąlygomis. Teigiamos savybėsŠį požiūrį į dizainą galima pavadinti: mažiau darbo reikalaujantis procesas, projektavimo laiko sutrumpinimas, palyginti su originaliu projektu, pažangių duomenų apdorojimo metodų diegimas, projekto dokumentacijos supaprastinimas (kadangi naudojama paketo dokumentacija), padidėjęs suprojektuotos AIS patikimumas.

4. Be to, yra grupės projektavimo metodas... Jos esmė yra išankstinis to paties tipo objektų grupės pasirinkimas pagal savybes. Tarp jų parenkamas pagrindinis objektas, kuriam projektas yra kuriamas, taip pat gali būti naudojami įvairūs metodai ir projektavimo metodai. Svarbiausia yra užtikrinti aukštą projekto pritaikomumą. Pagrindinė šio metodo taikymo sritis yra nepramoniniai įrenginiai (pavyzdžiui, sandėliai).

Automatizavimui efektyviausiai tinka ši veikla:

1. apskaita, įskaitant valdymą ir finansus. Daugiausia RFP buvo sukurta apskaitos tikslais. Tarp jų yra „1C: Apskaita“, „Turbo-buhalteris“, „Informacinis buhalteris“, „Parus“, „ABACUS“, „Bambi +“ ir kt .;

2. Pagalbos ir informacijos tarnyba ekonominė veikla... Atstovauja šie PPP: „GARANT“ (mokesčiai, apskaita, auditas, verslumas, bankininkystė, valiutos reguliavimas, muitinės kontrolė); „CONSULBTANT +“ (mokesčiai, apskaita, auditas, verslumas, bankininkystė, valiutos reguliavimas, muitinės kontrolė).

3.ekonominis ir finansinė veikla... Atstovauja šis RFP:

a) „Įmonės, organizacijos ekonominė analizė ir veiklos prognozė“ (įmonė „INEK“), kuri įgyvendina šias funkcijas: ekonominė analizėįmonės, įmonės veikla; verslo planų sudarymas; paskolos grąžinimo galimybių studija; veiklos variantų analizė ir parinkimas; balanso, pinigų srautų ir gatavų prekių prognozė.

b) „Galaktika“ korporacijos (UAB „Novy Atlant“) daugiafunkcinis tinklo kompleksas, apimantis planavimą, veiklos valdymą, apskaitą ir kontrolę, analizę, be to, leidžia DSS sistemoje užtikrinti verslo planavimo sprendimą problemų naudojant PPP projekto ekspertą.

4. vadovo darbo organizavimas;

5. dokumentų apyvartos automatizavimas;

6. mokymas.

Pastaruoju metu įmonės ir firmos nori pirkti paruoštus paketus ir technologijas ir, jei reikia, pridėti prie jų savo programinę įrangą, nes savo AIS kūrimas yra susijęs su didelėmis išlaidomis ir rizika. Paprastai kuriama ir siūloma pagrindinė sistema, kuri yra pritaikoma pagal atskirų klientų norus. Tuo pat metu vartotojams teikiamos konsultacijos, kurios padeda sutrumpinti sistemų ir technologijų diegimo laiką, kuo efektyviau jas naudoti ir pakelti personalo kvalifikaciją.

Kompiuterinės projektavimo sistemos - antras, sparčiai besivystantis projektavimo darbų atlikimo būdas.

Tarp kompiuterinio projektavimo metodų modelių projektavimo metodai užima ypatingą vietą. CAD sistemų sukūrimas ir naudojimas užtikrina pakankamai aukštą funkcinio patikimumo lygį, visapusišką visų technologinių procesų aprėptį, projektavimo darbų darbo intensyvumo mažinimą, maksimaliai atsižvelgiant į automatizavimo objekto interesus. Tačiau šis metodas yra gana brangus ir reikalauja aukštos kvalifikacijos kūrėjų. Pagrindinis CAD reikalavimas yra gebėjimas tinkamai sukurti ir išlaikyti tam tikrą automatizavimo objekto pasaulinės ekonominės informacijos modelį projektavimo sistemoje. Modelis yra aiškus automatikos objekto informacijos komponentų ir jų tarpusavio santykių rodymas. Pagrindinis modelio kūrimo tikslas yra sukurti šį modelį atitinkantį AIS projektą, atsižvelgiant į visas objekto charakteristikas ir aktyviai jas naudojant. Tokiame modelyje oficialiai turėtų būti pateiktas informacijos komponentų rinkinių ir jų tarpusavio santykių aprašymas, įskaitant informacijos nuorodas ir algoritminę sąveiką. Naudojant modelio projektavimo metodą, sisteminis požiūris, kuris lemia kompiuterių naudojimą ne tik visuose sistemos kūrimo etapuose, bet ir analizuojant jos pramoninės veiklos rezultatus. CAD kūrimas ir taikymas lėmė perėjimą prie kūrimo individualūs projektai, bet žymiai aukštesniu lygiu nei pradinis projektavimo metodas.

Per pastarąjį dešimtmetį IC ir IT projektavimo automatizavimo srityje atsirado nauja kryptis - CASE kompiuterinės programinės įrangos kūrimo technologija(CASE - kompiuterinė programinė įranga / sistemos inžinerija). Didėjant informacinių sistemų sudėtingumui ir didėjant joms keliamiems reikalavimams, atsirado poreikis industrializuoti jų kūrimo technologijas.

CASE technologija yra IS analizės, projektavimo, kūrimo ir priežiūros metodų rinkinys, kurį palaiko tarpusavyje sujungtų automatizavimo įrankių rinkinys. CASE yra įrankių rinkinys sistemų analitikams, kūrėjams ir programuotojams, kuris automatizuoja IC projektavimo ir kūrimo procesą. CASE sistemos naudojamos kaip galingas įrankis sprendžiant mokslinių tyrimų ir projektavimo problemas, tokias kaip struktūrinė dalykinės srities analizė, projekto įgyvendinimas naudojant naujausios kartos programavimo kalbas, projekto dokumentų išdavimas, projekto įgyvendinimo testavimas, planavimas ir stebėjimas, verslo programų modeliavimas. siekiant išspręsti veiklos problemas.ir strateginis planavimas ir išteklių valdymas ir kt.

Pagrindinis CASE tikslas yra maksimaliai automatizuoti sistemų kūrimą ir veikimą.

Naudojant CASE technologijas, keičiasi darbo technologija visuose automatizuotų sistemų gyvavimo ciklo etapuose. CASE sistemose dizainas grindžiamas vizualiais vizualiniais kūrimo metodais, o grafikai, diagramos, lentelės, diagramos ir tekstiniai paaiškinimai naudojami projektuojamo IS modeliui apibūdinti. Tokios metodikos pateikia griežtą ir aprašomąjį projektuojamos sistemos aprašymą, kuris prasideda sistemos apžvalga, o paskui išsamiau ir tampa hierarchine struktūra, kuriai būdingas vis daugiau lygių.

Programavimo automatizavimas grindžiamas automatiniu programų kodų, kuriuose yra duomenų aprašymai, generavimu, pagrindine jų apdorojimo logika, duomenų bazių schemomis, sąsajos aprašymo failais ir tt Kodai yra tobulinami ir tobulinami, tačiau kai kuriais atvejais automatizavimas pasiekia 90%. Be to, CASE technologija sukuria būtiną projekto dokumentaciją, paruoštą naudoti.

Naudojant CASE technologiją, teikiama vieno projekto bazės parama, t.y. visa informacija apie sukurtą AIS automatiškai įtraukiama į vieno projekto duomenų bazę. Taip išlaikomas projektavimo duomenų nuoseklumas, nuoseklumas, išsamumas ir minimalus perteklius.

CASE technologija užtikrina komandinį kūrėjų komandų darbą, nes skirtingoms specialistų grupėms suteikiamos tinkamos priemonės, taip pat galimybė nuosekliai ir teisingai atlikti įvairių specialistų projekto pakeitimus realiuoju laiku.

CASE technologijos sėkmingai naudojamos beveik visų tipų AIS kūrimui. CASE taip pat naudojamas kuriant sistemų modelius, kurie padeda komercinėms struktūroms spręsti strateginio planavimo, finansų valdymo, tvirtos politikos nustatymo, personalo mokymo ir kt.

CASE turi šiuos pagrindinius privalumus:

Gerinti sukurtos IS (IT) kokybę naudojant automatinį valdymą (pirmiausia projekto kontrolę);

Leiskite per trumpą laiką sukurti būsimos IS (IT) prototipą, kuris leidžia greitai, ankstyvosiose stadijose, įvertinti numatomą rezultatą;

Paspartinti sistemos projektavimo ir kūrimo procesą;

Išlaisvinkite kūrėją nuo įprastų darbų, leisdami jam visą dėmesį sutelkti į kūrybinę dizaino dalį;

Jie remia jau veikiančios IS kūrimą ir palaikymą.

Iki šiol susiformavo galinga CASE pramonė, kuri sujungė šimtus įvairių krypčių įmonių ir įmonių. Tarp jų išsiskiria:

Įmonės-IP ir IT analizės ir projektavimo įrankių kūrėjos

Įmonės-specialių įrankių kūrėjos, daugiausia dėmesio skiriančios siauroms temoms arba atskiriems IP gyvavimo ciklo etapams;

Mokymo įmonės, organizuojančios seminarus ir mokymo kursus specialistams;

Konsultacinės firmos, teikiančios praktinę pagalbą naudojant CASE paketus kuriant konkrečias IS;

Įmonės, kurios specializuojasi periodinių leidinių ir biuletenių apie CASE technologijas leidyboje.

Nbsp; AIS gyvavimo ciklo modeliai

AIS gyvavimo ciklo modelis yra struktūra, apibūdinanti vykdomus procesus, veiksmus ir užduotis bei kūrimo, veikimo ir priežiūros eigą per visą sistemos gyvavimo ciklą.

Gyvavimo ciklo modelio pasirinkimas priklauso nuo projekto specifikos, masto, sudėtingumo ir sąlygų, kuriomis sukuriama ir veikia AIS, rinkinio.

AIS gyvavimo ciklo modelis apima:

Darbo rezultatai kiekviename etape;

Svarbiausi įvykiai ar užbaigimo ir sprendimų priėmimo taškai.

Remiantis gerai žinomais programinės įrangos gyvavimo ciklo modeliais, nustatomi AIS gyvavimo ciklo modeliai - kaskadas, pasikartojantis, spiralinis.

I. Krioklio modelis apibūdina klasikinį požiūrį į sistemų kūrimą bet kurioje dalyko srityje; buvo plačiai naudojamas aštuntajame ir devintajame dešimtmečiuose.

Krioklio modelis numato nuoseklų darbo organizavimą, o pagrindinis modelio bruožas yra visų darbų padalijimas į etapus. Perėjimas iš ankstesnio etapo į kitą įvyksta tik baigus visus ankstesnio darbo darbus.

Paskirti penki stabilūs vystymosi etapai, praktiškai nepriklausantys nuo dalyko srities (1.1 pav.).

Įjungta PirmasŠiame etape atliekamas probleminės srities tyrimas, suformuluojami kliento reikalavimai. Šio etapo rezultatas yra užduotis (kūrimo užduotis), suderinta su visomis suinteresuotomis šalimis.

Per antra etape, pagal techninės užduoties reikalavimus, kuriami tam tikri projektiniai sprendimai. Dėl to pasirodo projekto dokumentų rinkinys.

Trečias etapas - projekto įgyvendinimas; iš esmės programinės įrangos kūrimas (kodavimas) pagal ankstesnio etapo projektavimo sprendimus. Šiuo atveju įgyvendinimo metodai neturi esminės reikšmės. Šio etapo rezultatas yra galutinis programinės įrangos produktas.

Įjungta ketvirtasŠiame etape tikrinama, ar gauta programinė įranga atitinka techninėje užduotyje nurodytus reikalavimus. Bandomoji operacija leidžia nustatyti įvairius paslėptus trūkumus, kurie atsiranda tikromis AIS sąlygomis.

Paskutinis etapas yra pasidavimas baigtas projektas, ir čia svarbiausia įtikinti klientą, kad visi jo reikalavimai yra visiškai įvykdyti.

1.1 pav. Krioklio AIS gyvavimo ciklo modelis

Darbo etapai pagal krioklio modelį dažnai vadinami AIS projekto ciklo dalimis, nes etapus sudaro daug kartotinių procedūrų, skirtų išsiaiškinti sistemos reikalavimus ir projektavimo galimybes. AIS gyvavimo ciklas yra daug sudėtingesnis ir ilgesnis: jis gali apimti savavališką skaičių paaiškinimų, jau priimtų ir įdiegtų dizaino sprendimų pakeitimų ir papildymų. Šiais ciklais vyksta AIS kūrimas ir atskirų jo komponentų modernizavimas.

Kaskadinio modelio pranašumai:

1) kiekviename etape sudaromas visas projekto dokumentų rinkinys, atitinkantis išsamumo ir nuoseklumo kriterijus. Paskutiniame etape sukuriama vartotojo dokumentacija, apimanti visų tipų standartų teikiamą AIS palaikymą (organizacinę, informacinę, programinę, techninę ir kt.);

2) nuoseklus darbo etapų įgyvendinimas leidžia planuoti užbaigimo laiką ir atitinkamas išlaidas.

Krioklio modelis iš pradžių buvo sukurtas įvairioms inžinerinėms problemoms spręsti ir iki šiol neprarado savo reikšmės taikomam laukui. Be to, krioklio metodas idealiai tinka AIS plėtrai, nes jau kūrimo pradžioje visi reikalavimai gali būti pakankamai tiksliai suformuluoti, kad kūrėjams būtų suteikta techninio įgyvendinimo laisvė. Tokia AIS visų pirma apima sudėtingas atsiskaitymo sistemas ir realaus laiko sistemas.

Krioklio modelio trūkumai:

Didelis vėlavimas gauti rezultatus;

Klaidos ir trūkumai bet kuriame etape paprastai atsiranda vėlesniuose darbo etapuose, todėl reikia grįžti;

Lygiagretaus projekto darbo sudėtingumas;

Per didelis informacijos perpildymas kiekviename etape;

Projekto valdymo sudėtingumas;

Didelis rizikos lygis ir investicijų nepatikimumas.

Vėlavimas gauti rezultatus pasireiškia tuo, kad nuoseklus požiūris į rezultatų susitarimo su suinteresuotosiomis šalimis vystymąsi atliekamas tik pasibaigus kitam darbo etapui. Dėl to gali pasirodyti, kad sukurta AIS neatitinka reikalavimų, ir tokie neatitikimai gali atsirasti bet kuriame kūrimo etape; be to, tiek analitikai, tiek programuotojai gali netyčia įvesti klaidų, nes jos neprivalo gerai išmanyti temų, kurioms AIS yra kuriama.

Grįžkite į ankstesnius etapus.Šis trūkumas yra viena iš ankstesnio apraiškų: žingsnis po žingsnio nuoseklus projekto darbas gali lemti tai, kad ankstesnėse stadijose padarytos klaidos aptinkamos tik vėlesniuose etapuose. Dėl to projektas grąžinamas į ankstesnį etapą, perdirbamas ir tik tada perkeliamas į vėlesnį darbą. Dėl to gali sutrikti tvarkaraštis ir pasunkėti tam tikrus etapus atliekančių vystymosi grupių santykiai.

Blogiausias variantas, kai ankstesnio etapo trūkumai aptinkami ne kitame etape, o vėliau. Pavyzdžiui, bandomojo veiksmo etape gali atsirasti klaidų dalyko srities aprašyme. Tai reiškia, kad dalis projekto turi būti grąžinta į pradinį darbo etapą.

Lygiagretaus darbo sudėtingumas susijęs su poreikiu koordinuoti skirtingas projekto dalis Kuo stipresni atskirų projekto dalių santykiai, tuo dažniau ir nuodugniau turėtų būti atliekama sinchronizacija, tuo labiau priklausys viena nuo kitos kūrimo komandos. Dėl to paralelinio darbo nauda tiesiog prarandama; lygiagretumo nebuvimas neigiamai veikia visos komandos darbo organizavimą.

Problema informacijos perpildymas atsiranda dėl stiprios priklausomybės tarp skirtingų vystymosi grupių. Faktas yra tas, kad, keičiant vieną iš projekto dalių, būtina pranešti tiems kūrėjams, kurie jį naudojo (galėjo naudoti) savo darbe. Esant daugybei tarpusavyje sujungtų posistemių, vidinės dokumentacijos sinchronizavimas tampa atskira svarbia užduotimi: kūrėjai turi nuolat susipažinti su pakeitimais ir įvertinti, kaip šie pakeitimai paveiks gautus rezultatus.

Projektų valdymo sudėtingumas daugiausia dėl griežtos kūrimo etapų sekos ir sudėtingų santykių tarp skirtingų projekto dalių. Reguliuojama darbų seka lemia tai, kad kai kurios plėtros grupės turi laukti kitų komandų darbo rezultatų, todėl, norint susitarti dėl pateiktų dokumentų laiko ir sudėties, reikalinga administracinė intervencija.

Jei darbe aptinkamos klaidos, būtina grįžti į ankstesnius etapus; suklydusiųjų dabartinis darbas nutraukiamas. To pasekmė paprastai yra vėlavimas užbaigti tiek pataisytą, tiek naują projektą.

Galima supaprastinti kūrėjų sąveiką ir sumažinti dokumentų perteklių, sumažinant jungčių skaičių tarp atskirų projekto dalių, tačiau ne kiekvieną AIS galima suskirstyti į silpnai susietus posistemius.

Aukštas rizikos lygis. Kuo sudėtingesnis projektas, tuo ilgiau trunka kiekvienas kūrimo etapas ir tuo sudėtingesni yra atskirų projekto dalių tarpusavio ryšiai, kurių skaičius taip pat didėja. Be to, kūrimo rezultatus tikrai galima pamatyti ir įvertinti tik bandymo etape, t. Y. Baigus analizės, projektavimo ir kūrimo etapus, kurių įgyvendinimas reikalauja daug laiko ir pinigų.

Vėlyvas vertinimas sukelia rimtų problemų nustatant analizės ir projektavimo klaidas - reikia grįžti į ankstesnius etapus ir pakartoti kūrimo procesą. Tačiau grįžimas į ankstesnius etapus gali būti siejamas ne tik su klaidomis, bet ir su pokyčiais, įvykusiais dalyko srityje ar kliento reikalavimais kūrimo metu. Tuo pačiu metu niekas negarantuoja, kad dalyko sritis nepasikeis, kol bus parengta kita projekto versija. Tiesą sakant, tai reiškia, kad yra tikimybė „sukti“ kūrimo procesą: projekto išlaidos nuolat augs, o galutinio produkto pristatymo terminai nuolat nukeliami.

II. Iteracinis modelis susideda iš kelių trumpų planavimo, įgyvendinimo, tyrimo, veiksmų ciklų (etapų).

Kuriant sudėtingą AIS reikia patvirtinti projektinius sprendimus, gautus įgyvendinant atskiras užduotis. Taikant „iš apačios į viršų“ projektavimo metodą, reikia tokių grąžinimo pakartojimų, kai atskirų užduočių projektavimo sprendimai sujungiami į bendrus sisteminius. Kartu reikia peržiūrėti anksčiau suformuotus reikalavimus.

Privalumas pasikartojantis modelis yra tas, kad tarppakopiniai koregavimai, palyginti su krioklio modeliu, suteikia mažiau darbo jėgos.

trūkumus pasikartojantis modelis:

· Kiekvieno etapo tarnavimo laikas pratęsiamas visam darbo laikotarpiui;

· Dėl didelio pakartojimų skaičiaus yra neatitikimų įgyvendinant projektinius sprendimus ir dokumentaciją;

· Architektūros sudėtingumas;

· Dėl sunkumų naudojant projektavimo dokumentus įgyvendinimo ir eksploatavimo etapuose reikia pertvarkyti visą sistemą.

III. Spiralinis modelis, priešingai nei kaskados, tačiau panaši į ankstesnę, ji apima kartotinį AIS kūrimo procesą. Tuo pat metu padidėja pradinių etapų, tokių kaip analizė ir projektavimas, svarba, kai tikrinami techninių sprendimų įgyvendinamumai ir jie pagrįsti kuriant prototipus.

Kiekviena iteracija yra visas kūrimo ciklas, dėl kurio išleidžiama vidinė ar išorinė produkto versija (arba galutinio produkto pogrupis), kuri nuo iteracijos iki iteracijos tobulėja ir tampa visa sistema (1.2 pav.).

Ryžiai. 1.2. Spiralinis gyvenimo ciklo AIS modelis

Taigi kiekvienas spiralės posūkis atitinka programinės įrangos produkto fragmento ar versijos sukūrimą, jame išaiškinami projekto tikslai ir charakteristikos, nustatoma jo kokybė, planuojamas darbas kitam spiralės posūkiui. Kiekviena iteracija padeda gilinti ir nuosekliai konkretinti projekto detales, todėl pasirenkama pagrįsta galutinio įgyvendinimo galimybė.

Naudojant spiralinį modelį galima pereiti į kitą projekto etapą, nelaukiant, kol bus baigtas dabartinis - nebaigtas darbas gali būti baigtas kitos iteracijos metu. pagrindinė užduotis kiekviena iteracija - kuo greičiau sukurkite veiksmingą produktą, kurį naudotojai galėtų demonstruoti. Taigi projekto koregavimo ir papildymo procesas yra labai supaprastintas.

Spiralinis požiūris į programinės įrangos kūrimą įveikia daugumą krioklio modelio trūkumų, be to, jis suteikia nemažai papildomų galimybių, todėl kūrimo procesas tampa lankstesnis.

Privalumai pasikartojantis metodas:

Iteracinė plėtra labai supaprastina projekto pakeitimus, kai keičiasi kliento reikalavimai;

Naudojant spiralinį modelį, atskiri AIS elementai palaipsniui integruojami į vieną visumą. Kadangi integracija prasideda nuo mažiau elementų, ją įgyvendinant kyla daug mažiau problemų;

Rizikos lygio sumažinimas (ankstesnio pranašumo pasekmė, nes rizika aptinkama tiksliai integracijos metu). Rizikos lygis yra didžiausias projekto kūrimo pradžioje; tolesniam vystymuisi jis mažėja;

Iteratyvus kūrimas suteikia daugiau lankstumo valdant projektus, nes leidžia keisti kuriamą produktą. Taigi, galite sutrumpinti kūrimo laiką, sumažindami sistemos funkcionalumą arba naudokite ją kaip sudedamosios dalys trečiųjų šalių įmonių produktai, o ne jų pačių plėtra (aktualu rinkos ekonomikoje, kai reikia atsispirti konkurentų produktų reklamai);

Pasikartojantis metodas leidžia lengviau pakartotinai naudoti komponentus, nes daug lengviau nustatyti (nustatyti) bendras projekto dalis, kai jos jau yra iš dalies sukurtos, nei bandyti jas izoliuoti pačioje projekto pradžioje. Projekto analizė po kelių pradinių pakartojimų atskleidžia bendrus daugkartinio naudojimo komponentus, kurie bus patobulinti vėlesnėse iteracijose;

Spiralinis modelis leidžia sukurti patikimesnę ir stabilesnę sistemą. Taip yra dėl to, kad sistemai tobulėjant, kiekvienos iteracijos metu aptinkamos ir ištaisomos klaidos ir trūkumai. Tuo pačiu metu koreguojami kritiniai veikimo parametrai, kurie krioklio modelio atveju yra prieinami tik prieš įdiegiant sistemą;

Pasikartojantis metodas pagerina procesą
plėtra - atlikus analizę kiekvienos iteracijos pabaigoje, atliekamas kūrimo organizacijos pokyčių įvertinimas; jis pagerėja kitoje iteracijoje.

Pagrindinė spiralinio ciklo problema- sunku nustatyti perėjimo į kitą etapą momentą. Norint ją išspręsti, būtina nustatyti kiekvieno gyvenimo ciklo etapo terminus. Priešingu atveju kūrimo procesas gali virsti begaliniu to, kas jau padaryta, tobulinimu.

Naudotojų įtraukimas į programos kūrimo ir kopijavimo procesą leidžia tiesiogiai gauti programos komentarus ir papildymus dėl reikalavimų, taip sumažinant kūrimo laiką. Klientų atstovai gauna galimybę kontroliuoti sistemos kūrimo procesą ir daryti įtaką jos funkciniam turiniui. Rezultatas - paleisti sistemą, kuri atsižvelgia į daugumą kliento poreikių.

Pateikiamos modernios metodikos ir jas įgyvendinančios AIS projektavimo technologijos elektroniniu formatu kartu su CASE įrankiais ir apima procesų, šablonų, metodų, modelių ir kitų komponentų, skirtų kurti tos klasės sistemų, į kurias orientuota metodika, programinę įrangą, bibliotekas. Elektroninės metodikos ir technologijos sudaro sutartų dalykų pagrindą įrankiai AIS kūrimas. Šiuolaikinių AIS projektavimo metodinių sprendimų ypatybės negali būti įgyvendintos be tam tikrų projektavimo technologijų, atitinkančių projekto mastą ir specifiką.

AIS projektavimo technologija yra AIS projektavimo metodų ir priemonių rinkinys, taip pat projektavimo organizavimo metodai ir įrankiai (AIS projekto kūrimo ir modernizavimo proceso valdymas).

Pagal TP dizainą AIS yra nuosekliai lygiagrečių, sujungtų ir pavaldžių veiksmų grandinių rinkinys, kurių kiekviena gali turėti savo temą. Veiksmai, atliekami projektuojant AIS, gali būti apibrėžiami kaip nedalomos technologinės operacijos arba technologinių operacijų papildomi procesai. Visi veiksmai gali būti tinkami dizainas, kurie formuoja arba keičia dizaino rezultatus, ir apskaičiuotas, kurios yra sukurtos pagal nustatytus projektavimo rezultatų vertinimo kriterijus.

Taigi projektavimo technologiją nustato reglamentuota technologinių operacijų seka, atliekama kuriant projektą pagal konkretų metodą.

Pasirinktos projektavimo technologijos objektas turėtų būti tarpusavyje susijusių projektavimo procesų atspindys visuose AIS gyvavimo ciklo etapuose.

Pagrindiniai pasirinktos projektavimo technologijos reikalavimai yra šie:

· Šios technologijos pagalba sukurtas projektas turi atitikti užsakovo reikalavimus;

· Technologija turėtų kuo labiau atspindėti visus projekto gyvavimo ciklo etapus;

· Ši technologija turėtų užtikrinti minimalias darbo ir išlaidų išlaidas projektavimui ir projektų rėmimui;

· Ši technologija turėtų prisidėti prie dizainerių našumo augimo;

· Technologija turėtų užtikrinti projekto projektavimo ir veikimo patikimumą;

· Ši technologija turėtų palengvinti paprastą projekto dokumentų priežiūrą.

AIS projektavimo technologija įgyvendina specifinę projektavimo metodiką. Savo ruožtu projektavimo metodika prisiima tam tikrą koncepciją, projektavimo principus ir yra įgyvendinama metodų ir įrankių rinkiniu.

AIS projektavimo metodai gali būti klasifikuojami pagal automatizavimo įrankių naudojimo laipsnį, tipinius dizaino sprendimus, pritaikomumą numatomiems pokyčiams.

Pagal automatizavimo laipsnį jie išskiriami:

rankinis dizainas, kuriame AIS komponentų projektavimas atliekamas nenaudojant specialių programinės įrangos įrankių; programavimas atliekamas algoritminėmis kalbomis;

kompiuterio projektavimas, kuriame projektavimo sprendimų generavimas ar konfigūravimas (derinimas) atliekamas naudojant specialias programinės įrangos priemones.

Pagal tipiškų dizaino sprendimų naudojimo laipsnį jie išskiriami:

originalus (individualus) dizainas, kai dizaino sprendimai kuriami „nuo nulio“ pagal AIS keliamus reikalavimus;

tipiškas dizainas, darant prielaidą, kad AIS konfigūracija atliekama iš paruoštų standartinių dizaino sprendimų (programinės įrangos modulių).

Originalus dizainas AIS prisiima maksimalų dėmesį į automatizuoto įrenginio ypatybes.

Tipiškas dizainas atliekamas remiantis paruošti sprendimai ir apibendrina anksčiau įgytą patirtį kuriant susijusius projektus.

Pagal dizaino sprendimų pritaikomumo laipsnį skiriasi šie metodai:

rekonstrukcija- dizaino sprendimų pritaikymas atliekamas apdorojant atitinkamus komponentus (programinės įrangos modulių perprogramavimas);

parametrų nustatymas- projektiniai sprendimai derinami pagal nurodytus ir kintančius parametrus;

modelio pertvarkymas- keičiasi domeno modelis, dėl kurio automatiškai pertvarkomi dizaino sprendimai.

Įvairių projektavimo metodų klasifikavimo ženklų derinys lemia naudojamos AIS projektavimo technologijos pobūdį. Yra dvi pagrindinės dizaino technologijų klasės: kanoninis ir pramoninis... Pramoninio dizaino technologija yra padalinta į du poklasius: automatizuotas(naudojant CASE technologijas) ir tipiškas(orientuotas į parametrus arba į modelį) dizainas.

1.1 lentelė.Dizaino technologijų klasių charakteristikos

Kanoninis AIS dizainas daugiausia dėmesio skiriama AIS gyvavimo ciklo krioklio modelio naudojimui.

Atsižvelgiant į automatizavimo objekto sudėtingumą ir užduočių, kurias reikia išspręsti kuriant konkrečią AIS, rinkinį, darbo etapai ir etapai gali turėti skirtingą darbo intensyvumą. Leidžiama derinti vienas po kito einančius etapus ir neįtraukti kai kurių iš jų į bet kurį projekto etapą. Taip pat leidžiama kito etapo darbus pradėti prieš ankstesnio etapo pabaigą.

AIS kūrimo etapai ir etapai, kuriuos atlieka dalyvaujančios organizacijos, yra numatyti sutartyse ir darbo atlikimo užduotyse.

1 etapas. Reikalavimų AIS formavimas:

· Įrenginio tyrimas ir poreikio sukurti AIS pagrindimas;

· Vartotojo reikalavimų AIS formavimas;

· Ataskaitos apie atliktą darbą ir taktinio bei techninio tobulinimo užduoties parengimas.

2 etapas. AIS koncepcijos kūrimas:

· Automatikos objekto tyrimas;

· Atlikti reikiamus tiriamuosius darbus;

· AIS koncepcijos variantų, atitinkančių vartotojų reikalavimus, kūrimas;

· Ataskaitos rengimas ir koncepcijos patvirtinimas.

3 etapas. Techninė užduotis:

AIS kūrimo techninių specifikacijų kūrimas ir patvirtinimas.

4 etapas. Preliminarus dizainas:

· Preliminarių sistemos ir jos dalių projektavimo sprendimų kūrimas;

· AIS ir jos dalių kontūro dokumentų rengimas.

5 etapas. Techninis projektas:

· Sistemos ir jos dalių projektavimo sprendimų kūrimas;

· AIS ir jos dalių dokumentacijos rengimas;

· Komponentų tiekimo dokumentacijos kūrimas ir vykdymas;

· Dizaino užduočių kūrimas susijusiose projekto dalyse.

6 etapas. Darbo dokumentacija:

· AIS ir jos dalių darbo dokumentų rengimas;

· Programų kūrimas ir pritaikymas.

7 etapas. Eksploatacijos pradžia:

· Automatikos objekto paruošimas; personalo mokymas;

· Visas AIS tiekiamų produktų rinkinys (programinė ir techninė įranga, programinės ir aparatinės įrangos kompleksai, informaciniai produktai);

· Statybos ir montavimo darbai; paleidimo darbai;

· Preliminarių bandymų atlikimas;

· Bandomosios operacijos atlikimas;

· Priėmimo testų atlikimas.

8 etapas. AIS palyda:

· Darbų atlikimas pagal garantinius įsipareigojimus;

· Pogarantinis aptarnavimas.

Apklausa Ar studijuojama ir analizuojama įmonės organizacinė struktūra, jos veikla ir esama sistema informacijos apdorojimas.

Apklausos metu gautos medžiagos naudojamos:

Sistemų kūrimo ir laipsniško diegimo pagrindimas;

Sistemų kūrimo techninių specifikacijų rengimas;

Techninių ir darbinių sistemų projektų kūrimas.

Apklausos etape patartina išskirti du komponentus: AIS diegimo strategijos apibrėžimą ir išsamią organizacijos veiklos analizę.

Pagrindinis pirmojo tyrimo etapo uždavinys yra įvertinti tikrąją projekto apimtį, jo tikslus ir uždavinius, remiantis nustatytomis aukšto lygio automatizuoto objekto funkcijomis ir informaciniais elementais. Šias užduotis AIS klientas gali atlikti savarankiškai arba įtraukdamas konsultacines organizacijas. Šis etapas apima glaudžią sąveiką su pagrindiniais potencialiais sistemos vartotojais ir verslo ekspertais. Pagrindinis sąveikos uždavinys yra visiškai ir nedviprasmiškai suprasti kliento reikalavimus. Paprastai jums reikalingos informacijos galima gauti per interviu, pokalbius ar seminarus su vadovybe, ekspertais ir vartotojais.

Baigus apklausos etapą tampa įmanoma nustatyti tikėtinus techninius sistemos kūrimo būdus ir įvertinti jos įgyvendinimo išlaidas (aparatinei įrangai, įsigytai programinei įrangai ir naujos programinės įrangos kūrimui).

Strategijos apibrėžimo etapo rezultatas yra dokumentas (galimybių studija - galimybių studija - projektas), kuriame aiškiai suformuluota, ką klientas gaus, jei sutiks finansuoti projektą, kada gaus gatavą produktą (darbo grafikas) ir kaip kiek tai kainuos (dideliems projektams - tai finansavimo grafikas skirtingais darbo etapais). Pageidautina, kad dokumente atsispindėtų ne tik išlaidos, bet ir projekto nauda, ​​pavyzdžiui, numatomas projekto atsipirkimo laikas ekonominis poveikis(jei galima įvertinti).

Apribojimai, rizika, kritiniai veiksniai, galintys turėti įtakos projekto sėkmei;

Sąlygų, kuriomis numatoma eksploatuoti būsimą sistemą, rinkinys - sistemos architektūra, techninės ir programinės įrangos ištekliai, eksploatavimo sąlygos, aptarnaujantis personalas ir sistemos vartotojai;

Atskirų etapų užbaigimo sąlygos, darbų priėmimo / pristatymo forma, susiję ištekliai, priemonės informacijai apsaugoti;

Sistemos atliekamų funkcijų aprašymas;

Sistemos kūrimo ir modernizavimo galimybės;

Sąsajos ir funkcijų pasiskirstymas tarp asmens ir sistemos;

programinės įrangos ir duomenų bazių valdymo sistemų (DBVS) reikalavimus.

Išsamios organizacijos veiklos analizės etape tiriama veikla, užtikrinanti valdymo funkcijų įgyvendinimą, organizacinė struktūra, personalo ir darbo su įmonės valdymu turinio, taip pat pavaldumo aukštesniems valdymo organams pobūdžio. Čia būtina išdėstyti mokomąją-metodinę ir direktyvinę medžiagą, pagal kurią nustatoma posistemių sudėtis ir užduočių sąrašas, taip pat galimybė naudoti naujus problemų sprendimo metodus.

Analitikai renka ir įrašo informaciją dviem tarpusavyje susijusiomis formomis:

Funkcijos - informacija apie įvykius ir procesus, vykstančius automatizuotoje organizacijoje;

Subjektai - informacija apie organizacijai svarbias objektų klases ir apie kuriuos renkami duomenys.

Nagrinėjant kiekvieną funkcinio valdymo užduotį, nustatoma:

Užduoties pavadinimas; savo sprendimo sąlygas ir dažnumą;

Problemos formalizavimo laipsnis;

Informacijos šaltiniai, reikalingi problemai išspręsti;

Rodikliai ir jų kiekybinės charakteristikos;

Informacijos taisymo tvarka;

Rodiklių skaičiavimo ir galimų valdymo metodų veikimo algoritmai;

Esamos informacijos rinkimo, perdavimo ir apdorojimo priemonės;

Esamos ryšio priemonės;

Priimtas problemos sprendimo tikslumas;

Problemos sprendimo sudėtingumas;

Esamos pradinių duomenų pateikimo formos ir jų apdorojimo rezultatai dokumentų forma;

Vartotojai gautą informaciją apie užduotį.

Viena iš daugiausiai laiko reikalaujančių, nors ir gerai įformintų šio etapo užduočių yra organizacijos darbo eigos aprašymas. Nagrinėjant darbo eigą, sudaroma dokumentų judėjimo maršruto schema, kuri turėtų atspindėti:

Dokumentų skaičius;

Dokumentų rodiklių sudarymo vieta;

Dokumentų santykiai jų formavimo metu;

Dokumento perkėlimo maršrutas ir trukmė;

Šio dokumento naudojimo ir saugojimo vieta;

Vidaus ir išorės informacinis ryšys;

Dokumento apimtis ženklais.

Remiantis apklausos rezultatais, sudaromas automatizuojamų I valdymo užduočių sąrašas ir jų rengimo seka.

Tyrimo etape planuojamos sistemos funkcijos turėtų būti klasifikuojamos pagal jų svarbą. Vienas iš galimų tokios klasifikacijos pateikimo formatų yra „MuSCoW“. Ši santrumpa reiškia: Turi turėti - būtinas funkcijas; Turėtų turėti - norimas funkcijas; Galėtų turėti - galimas funkcijas; Neturės trūkstamų funkcijų.

Pirmosios kategorijos funkcijos yra labai svarbios I sėkmingas darbas sistemų galimybes. Antrosios ir trečiosios kategorijų funkcijų įgyvendinimą riboja laikas ir finansinė programa: būtinas ir maksimalus įmanomas prioritetų tvarka antros ir trečios kategorijų funkcijų skaičius. Paskutinė funkcijų kategorija yra ypač svarbi, nes būtina aiškiai suprasti I projekto ribas ir funkcijų, kurių sistemoje nebus, rinkinį.

Organizacinės veiklos modeliai sukurti dviejų tipų 1:

Modelis „toks, koks yra“ atspindi verslo procesus, egzistuojančius organizacijoje;

Modelis „būti“ atspindi būtinus verslo procesų pokyčius, atsižvelgiant į AIS įdiegimą. j

Jau analizės etape būtina įtraukti testavimo grupę į darbą, kad būtų išspręstos šios užduotys:

Aparatinės įrangos platformų, operacinių sistemų, DBVS ir kt. Lyginamųjų charakteristikų gavimas;

Darbo plano, skirto užtikrinti AIS ir jo testavimo patikimumą, sukūrimas.

Testuotojų įtraukimas į kūrimo pradžią yra gera idėja bet kuriam projektui. Kuo vėliau aptinkamos dizaino sprendimų klaidos, tuo brangiau jas ištaisyti; blogiausias scenarijus yra jų aptikimas įgyvendinimo etape. Taigi, kuo greičiau bandymų grupės pradeda nustatyti AIS klaidas, tuo mažesnės darbo su sistema išlaidos. Sistemos testavimo ir aptiktų klaidų ištaisymo laikas turėtų būti numatytas ne tik kūrimo, bet ir projektavimo etape.

Specialios klaidų sekimo sistemos yra skirtos palengvinti ir padidinti bandymų efektyvumą. Jų naudojimas leidžia turėti vieną klaidų saugyklą, sekti jų pasikartojimą, kontroliuoti klaidų taisymo greitį ir efektyvumą, matyti nestabiliausius sistemos komponentus, taip pat palaikyti ryšį tarp kūrėjų komandos ir bandymų komandos.

Apklausos rezultatai yra objektyvus AIS techninių specifikacijų sudarymo pagrindas.

Techninė užduotis Tai dokumentas, kuriame apibrėžiami tikslai, reikalavimai ir pagrindiniai pradiniai duomenys, būtini kuriant automatizuotą valdymo sistemą.

Kuriant techninę užduotį (TOR), būtina išspręsti šias užduotis:

· Nustatyti bendrą AIS kūrimo tikslą;

· Nustatyti bendrus suprojektuotos sistemos reikalavimus;

· Parengti ir pagrįsti informacijos, matematikos, programinės įrangos, techninės ir techninės pagalbos reikalavimus;

· Nustatyti posistemių sudėtį ir funkcines užduotis;

· Parengti ir pagrįsti posistemiams keliamus reikalavimus;

· Nustatyti sistemos kūrimo etapus ir jų įgyvendinimo laiką;

Iš anksto apskaičiuokite sistemos sukūrimo išlaidas ir nustatykite lygį ekonominis efektyvumasįgyvendinimas;

· Nustatyti atlikėjų sudėtį.

Tipiniai techninės užduoties sudėties ir turinio reikalavimai pateikti lentelėje. 1.6.

Tablitsa 1.6. Techninės užduoties sudėtis ir turinys (GOST 34.602-89)

Išskirtinis projektas numato parengti preliminarius sistemos ir jos dalių projektavimo sprendimus. Preliminarus projektavimas nėra griežtai privalomas etapas. Jei pagrindiniai projektavimo sprendimai yra apibrėžti anksčiau arba yra pakankamai akivaizdūs konkrečiam AIS ir automatikos objektui, tuomet šį etapą galima neįtraukti į bendrą darbų seką.

AIS funkcijos;

Posistemių funkcijos, jų tikslai ir numatomas įgyvendinimo poveikis;

Užduočių rinkinių ir individualių užduočių sudėtis;

Informacinės bazės koncepcija ir jos padidinta struktūra;

Duomenų bazių valdymo sistemos funkcijos;

Kompiuterinės sistemos ir kitų techninių priemonių sudėtis;

Pagrindinės programinės įrangos funkcijos ir parametrai.

Remiantis atlikto darbo rezultatais, parengiama dokumentacija, dėl kurios susitarta ir patvirtinama tokia suma, kurios reikia, kad būtų galima apibūdinti visą priimtų projektavimo sprendimų rinkinį, ir to pakanka tolesniam sistemos kūrimo darbui.

Remiantis GOST 19.102-77, preliminariame projektavimo etape yra du etapai: preliminariojo projekto kūrimas; projekto projekto patvirtinimas.

Pirmąjį vystymosi etapą sudaro:

Išankstinis įvesties ir išvesties duomenų struktūros kūrimas;

Problemos sprendimo metodų tobulinimas;

Bendro problemos sprendimo algoritmo aprašymo sukūrimas;

Galimybių studijos rengimas;

Aiškinamojo rašto parengimas.

Šiuo atveju leidžiama sujungti ir neįtraukti kai kurių kūrinių.

Žemiau yra dokumentų rinkinys, kurį reikia ir galima parengti eskizo projekto pabaigoje.

Privalomi dokumentai:

1) atnaujinti projektavimo ir kūrimo įgaliojimai
AIS darbas;

2) AIS kvalifikacinių reikalavimų specifikacija;

3) funkcinės programinės įrangos komponentų ir duomenų aprašymų reikalavimų specifikacijų rinkinys;

4) komponento vidinėms sąsajoms ir sąsajoms su išorine aplinka taikomų reikalavimų specifikacija;

5) duomenų bazės valdymo sistemos aprašymas, programinės įrangos ir informacijos objektų duomenų bazėje struktūra ir paskirstymas;

6) parengti informacijos apsaugos ir AIS veikimo patikimumo užtikrinimo gairių projektus;

7) preliminari AIS administratoriaus vadovo versija;

8) preliminari AIS vartotojo vadovo versija;

9) patikslintas projekto įgyvendinimo planas;

10) patobulintas AIS kokybės užtikrinimo valdymo planas;

11) preliminarus AIS projekto aiškinamasis raštas;

12) peržiūrėta sutartis (sutartis) su klientu dėl išsamesnės informacijos
naujas AIS dizainas.

Dokumentai, sudaryti susitarus su klientu:

1) preliminarus AIS veikimo aprašymas;

2) duomenų srautų tarp funkcinių AIS komponentų schema;

3) patobulinta AIS architektūros schema, programinės įrangos ir informacijos komponentų sąveika, skaičiavimo proceso organizavimas ir išteklių paskirstymas;

4) komponentų kokybės rodiklių ir jiems keliamų reikalavimų aprašymas pagal AIS kūrimo etapus;

5) techninių ir ekonominių rodiklių, projekto įgyvendinimo grafiko, išteklių paskirstymo ir biudžeto ataskaita;

6) specialistų pasiskirstymo pagal komponentus ir darbo etapus lentelė;

7) kūrėjų sertifikatai dėl teisės naudoti technologijas ir automatizavimo priemones AIS kūrimui;

8) gautų dokumentų sudėties ir formų reikalavimų aprašymas pagal darbo etapus;

9) programinės įrangos komponentų derinimo planas, suteikiant jam bandymų automatizavimo metodus ir priemones;

10) preliminarios detaliojo projekto gairės
vanija, AIS komponentų programavimas ir derinimas;

11) preliminarus pardavimo ir įgyvendinimo planas;

12) preliminarios duomenų bazės struktūros aprašymas.

Techninis projektas sistemos yra techninė dokumentacija, apimanti visos sistemos projektavimo sprendimus, problemų sprendimo algoritmus, taip pat AIS ekonominio efektyvumo įvertinimą. Šiame etape atliekamas mokslinių tyrimų ir eksperimentinio darbo kompleksas, siekiant pasirinkti pagrindinius projektavimo sprendimus ir apskaičiuoti ekonominis sistemos efektyvumas. Techninio projekto sudėtis ir turinys pateikti lentelėje. 1.7

1.7 lentelė. Techninio projekto turinys

„Darbo dokumentacijos“ etape sukuriamas programinės įrangos produktas ir parengiama visa pridedama dokumentacija. Dokumentuose turėtų būti visa reikalinga ir pakankama informacija, užtikrinanti AIS paleidimo ir jos veikimo darbų atlikimą, taip pat sistemos veikimo charakteristikų (kokybės) lygio palaikymą. Parengta dokumentacija turi būti tinkamai parengta, suderinta ir patvirtinta.

AIS etape „Pradėjimas eksploatuoti“ nustatomi šie pagrindiniai bandymų tipai: preliminarūs bandymai, bandomasis veikimas ir priėmimo bandymai. Jei reikia, leidžiama papildomai atlikti kitų tipų sistemos ir jos dalių bandymus.

Atsižvelgiant į ryšį tarp AIS komponentų ir automatikos objekto, bandymai gali būti savarankiški ir sudėtingi. Sistemos komponentai dalyvauja autonominiame bandyme. Jie atliekami, kai tik sistemos dalys yra paruoštos paleidimui. Kompleksiniai bandymai atliekami tarpusavyje sujungtų komponentų (posistemių) grupėms arba visai sistemai.

Siekiant planuoti visų tipų bandymų atlikimą, rengiamas dokumentas „Programa ir bandymų metodika“. Dokumento rengėjas yra nustatytas sutartyje arba TK. Bandymus ar bandymų atvejus galima įtraukti į dokumentą kaip priedą.

Derinimas yra daugiausiai laiko reikalaujantis projektavimo procesas. Paslėptos klaidos kartais atsiranda po daugelio metų sistemos veikimo. Neįmanoma visiškai išvengti klaidų, o tai lemia astronominis sistemos veikimo galimybių skaičius. Artimiausiu metu beveik neįmanoma patikrinti, ar jie visi veikia tinkamai.

Klaidų nustatymo ir pašalinimo išlaidos vėlesniuose projektavimo etapuose padidėja maždaug eksponentiškai (1.10 pav.).

Mokslininkai suskaičiuoja 169 klaidų rūšis, apibendrintas 19 didelių klasių:

1) logiškas;

2) manipuliavimo duomenimis klaidos;

3) įvesties / išvesties klaidos;

4) skaičiavimų klaidos;

Ryžiai. 1.10. Santykinės vienos klaidos aptikimo ir taisymo išlaidos

5) klaidos vartotojo sąsajose;

6) operacinės sistemos ir pagalbinių programų klaidos;

7) išdėstymo klaidos;

8) tarpprogramavimo sąsajų klaidos;

9) klaidos sąsajose „Programa - sistemos programinė įranga“;

10) klaidos tvarkant išorinius įrenginius;

11) sąsajos su duomenų baze (DB) klaidos;

12) duomenų bazės inicijavimo klaidos;

13) pakeitimų klaidos, gavus prašymą iš išorės;

14) klaidos, susijusios su pasauliniais kintamaisiais;

15) pasikartojančios klaidos;

16) dokumentacijos klaidos;

17) techninių reikalavimų pažeidimas;

18) nepripažintos klaidos;

19) operatoriaus klaidos.

Ne visos klaidos kyla iš kūrėjo. Įvairių tyrėjų duomenimis, nuo 6 iki 19% klaidų atsiranda dėl dokumentų klaidų.

Ryšys tarp kūrimo ir bandymų įvairiuose AIS projektavimo etapuose parodytas fig. 1.11.

Ši grandinė tik sąlygiškai „ištempta“ į liniją. Jo viduje visada yra pasikartojančių kilpų. Norėdami nustatyti klaidas, kūrėjai sukuria specialius testus ir atlieka derinimo etapą. Jei klaidų nerandama, tai nereiškia, kad jų nėra - galbūt testas pasirodė per silpnas.

Ryžiai. 1.11. Ryšys tarp kūrimo ir bandymų pagal AIS projektavimo etapus

Derinimo technika atsižvelgia į galimų klaidų simptomus:

Neteisingas apdorojimas (neteisingas atsakymas, rezultatas) - iki 30%;

Neteisingas kontrolės perdavimas - 16%;

Programų nesuderinamumas su naudojamais duomenimis - 15%;

Programų nesuderinamumas perduodamiems duomenims - iki 9%.

Kuriant derinimo užduotis sprendžiamos šios užduotys:

Rašymo testai;

Taškų, zonų ir kontrolės maršrutų pasirinkimas;

Kontroliuojamų kiekių sąrašo nustatymas ir jų verčių nustatymo tvarka;

Testavimo tvarkos nustatymas;

Derinimo patikimumo ir sudėtingumo įvertinimas.

Derinama programa turi bent kartą dirbti su kiekviena algoritmo šaka ir tuo pačiu priskirti kintamiesiems reikšmių seriją, užfiksuoti diapazono ribas, kelias jo reikšmes, nulines reikšmes ir vienaskaitos taškai (jei yra). Specialioms sistemoms sukurtos specialios derinimo kalbos. Juose gali būti palyginti nedaug komandų (20–30) su papildomais derinimo parametrais, kad būtų galima išspręsti šias užduotis:

Pasitraukimo kontrolė;

Derinamos programos vykdymo proceso modeliavimas;

Atminties komponentų būsenos išdavimas vykdant programą;

Tikrinant sąlygas tam tikroms būsenoms pasiekti programos vykdymo procese;

Pradinių duomenų bandymo verčių nustatymas;

Sąlyginių šuolių diegimas bandymuose, atsižvelgiant į kitų makrokomandų ar įvairių testų vykdymo rezultatus;

Aptarnavimo operacijų atlikimas, siekiant paruošti programą bandymams.

Derinimo procesas negali būti klasifikuojamas kaip visiškai įformintas, todėl yra empirinių jo elgesio rekomendacijų, kurios pateikiamos toliau.

1. Naudokite semantinį, iš anksto apgalvotą derinimo metodą, planuokite derinimo procesą ir kruopščiai suprojektuokite bandymų duomenų rinkinius iš paprasčiausių galimų variantų, pašalindami labiausiai tikėtinus klaidų šaltinius.

2. Surinkite ir išanalizuokite informaciją, kad supaprastintumėte testavimo procesą:

Savybės ir klaidų statistika;

Apie pradinių duomenų specifiką ir programos kintamųjų keitimo seką bei jų tarpusavio įtaką;

Apie algoritmo struktūrą ir jo programinės įrangos diegimo ypatybes.

3. Vienu metu suraskite tik vieną klaidą.

Naudokite informacijos apie klaidas registravimo ir rodymo priemones, įskaitant specialų programos derinimo kodą, skirtą atspausdinti kintamųjų atrinktas vertes, pranešimus apie atskirų programos skyrių pabaigą, sekimą, logines sąlygas ir kt.

5. Atidžiai išstudijuokite gautą rezultatą ir palyginkite jį su numatytais, iš anksto apskaičiuotais rezultatais.

6. Naudodami ribines reikšmes ir neteisingai įvesdami, atkreipkite dėmesį į duomenis, atidžiai išanalizuokite programos veikimą; valdyti duomenų tipus, diapazonus, lauko dydžius ir tikslumą.

7. Naudokite duomenų srautų analizę ir valdymo srautų analizę, kad patvirtintumėte ir nustatytumėte duomenų apimtis skirtingiems programos vykdymo keliams.

8. Vienu metu naudokite skirtingus derinimo įrankius, nesvarstydami vienos galimybės. Vienu metu naudokite automatizuotus įrankius ir rankinį derinimą bei testavimą, tikrindami kodo veikimą pagal labiausiai tikėtinas klaidas.

9. Dokumentuokite visas rastas ir ištaisytas klaidas, jų skirtumus, vietą ir tipą. Ši informacija bus naudinga siekiant išvengti klaidų ateityje.

10. Išmatuokite programų sudėtingumą. Didelio sudėtingumo programose yra didelė specifikacijų ir dizaino klaidų tikimybė, o sudėtingumo, kodavimo ir rašymo klaidų yra mažai.

11. Padidinti derinimo patirtį ir praktiką dirbtinai įdėti klaidų į programas. Po tam tikro derinimo laikotarpio programuotojas turėtų nurodyti visas likusias klaidas, kurių nerado. Toks „sėjimas“ yra plačiai naudojamas neaptinkamų klaidų skaičiui įvertinti (jei tiek dirbtinės, tiek realios klaidos yra vienodai aptinkamos ir ištaisomos, tada įvestų įvestų klaidų ir realių klaidų procentas gali būti naudojamas prognozuojant, kiek jų liko).

Atliekami preliminarūs bandymai, siekiant nustatyti sistemos veikimą ir išspręsti klausimą dėl galimybės ją priimti į bandomąją operaciją. Išankstiniai bandymai turėtų būti atlikti po to, kai kūrėjas ištaisė ir išbandė pateiktą sistemos programinę ir techninę įrangą bei pateikė atitinkamus dokumentus apie jų pasirengimą bandymams, taip pat po to, kai AIS darbuotojai susipažino su eksploatacijos dokumentais.

Bandomasis sistemos veikimas atliekamas siekiant nustatyti faktines sistemos kiekybinių ir kokybinių charakteristikų vertes ir darbuotojų pasirengimą dirbti jos veikimo sąlygomis, taip pat nustatyti faktinį efektyvumą ir koreguoti jei reikia, dokumentus.

Atliekami priėmimo bandymai, siekiant nustatyti sistemos atitiktį techninėms specifikacijoms, įvertinti bandomojo veikimo kokybę ir išspręsti klausimą dėl galimybės priimti sistemą nuolatiniam naudojimui.

Siųsti savo gerą darbą žinių bazėje yra paprasta. Naudokite žemiau esančią formą

Studentai, magistrantai, jaunieji mokslininkai, kurie žinių bazę naudoja savo studijose ir darbe, bus jums labai dėkingi.

Publikuotas http://www.allbest.ru/

Švietimo ir mokslo ministerija Rusijos Federacija

Federalinis valstybės biudžetas švietimo įstaiga aukštasis profesinis išsilavinimas

Sankt Peterburgo valstybinis technologijų ir dizaino universitetas

Kursinis darbas

Pagal discipliną: „Informacinių sistemų architektūra“

Tema: „Automatizuotų informacinių sistemų projektavimas“

ĮVADAS

Šiuo metu kompiuterinės technologijos vis labiau plinta tiek gamyboje, tiek įmonių darbo eigoje, o užduočių, kurias jos apima, sąrašas tampa vis platesnis. Apdorojamos informacijos apimtis ir sudėtingumas nuolat auga, todėl reikia naujų jos pateikimo tipų.

Štai tik keletas kompiuterių naudojimo pranašumų organizacijai:

* Galimybė operatyviai kontroliuoti informacijos tikslumą;

* Galimų klaidų skaičiaus mažinimas generuojant išvestinius duomenis;

* Galimybė greitai pasiekti bet kokius duomenis;

* Gebėjimas greitai generuoti ataskaitas;

* Taupo darbo sąnaudas ir laiką, praleistą informacijos apdorojimui.

Visus šiuos privalumus šiuo metu vertina daugelis organizacijų, todėl šiandien vyksta greitas automatizuotų informacinių sistemų kūrimas ir jų diegimas įvairių institucijų darbe. Šiuo atžvilgiu mano pasirinkta tema šiuo metu yra labai aktuali.

Pagrindinis įvairių įmonių ir institucijų automatizavimo sistemų pramonės bruožas, kuriam būdingas platus įvesties duomenų spektras įvairiais šių duomenų apdorojimo būdais, yra sudėtingumo koncentracija pradiniuose reikalavimų analizės ir sistemos specifikacijų projektavimo etapuose. mažas tolesnių etapų sudėtingumas ir darbo intensyvumas. Tiesą sakant, čia ir yra supratimas, ką darys būsima sistema ir kaip ji veiks, kad atitiktų jai keliamus reikalavimus. Būtent dėl ​​sistemos reikalavimų neapibrėžtumo ir neužbaigtumo, neišspręstų problemų ir klaidų, padarytų analizės ir projektavimo etapuose, kyla sunkių, dažnai neišsprendžiamų problemų vėlesniuose etapuose ir galiausiai sukuriama viso darbo nesėkmė. Paprasta net labai geros įmonės valdymo sistemos kopija klientui niekada netiks, nes ji negali atsižvelgti į jos specifiką. Be to, šiuo atveju iškyla problema pasirinkti būtent tą sistemą, kuri labiausiai tinka konkrečiai įmonei. Ir šią problemą dar labiau apsunkina tai, kad raktiniai žodžiai, apibūdinantys įvairias informacines sistemas, yra praktiškai vienodi:

* Vieninga įmonės informacinė aplinka;

* Realaus laiko režimas;

* Nepriklausomybė nuo teisės aktų;

* Integracija su kitomis programomis (įskaitant įmonėje jau veikiančias sistemas);

* Laipsniškas įgyvendinimas ir kt.

Tiesą sakant, sudėtingos automatizavimo problema tapo aktuali kiekvienai įmonei. Norėdami atlikti sudėtingą automatizavimą, jums reikia struktūrinių žinių šioje srityje.

Šio darbo tikslas: Susipažinti su automatizuotų informacinių sistemų koncepcija, apsvarstyti projektavimo procesą.

Norint pasiekti tikslą, būtina išspręsti šias užduotis:

§ Suformuluoti pagrindinių sąvokų ir terminų apibrėžimus;

§ Apsvarstykite dizaino tikslus ir uždavinius;

§ Susipažinkite su pagrindiniais projektavimo etapais;

§ Išryškinti automatizuotų informacinių sistemų kūrimo etapus;

§ Apsvarstykite techninės užduoties ir techninio projekto sudėtį ir struktūrą.

1. SĄVOKŲ APIBRĖŽIMAS AUTOMATINĖ INFORMACIJOS SISTEMA (AIS), INFORMACIJOS SISTEMA (IS), PROJEKTAS IR DIZAINAS

Struktūrizuojant procesus žmogaus veiklos srityje, naudojami skirtingi komponentų (dalinių procesų) išskyrimo metodai ir gaunami įvairūs rezultatai, pavyzdžiui, tyrimai ir plėtra, analizė ir sintezė ir kt.

Dizainas yra gana priimtinas, kad jį būtų galima laikyti apibendrinančia daugelio intelektinių užduočių, išspręstų mąstymo procese ir skirtingais būdais, koncepcija.

Žodžio dizaino šaknis pabrėžia ryšį tarp proceso, turinčio tokį pavadinimą, ir pagrindinių šio proceso rezultatų:

a) projekcija - tai, kas gaunama analizuojant sudėtingus reiškinius, siekiant gauti supaprastintus vaizdus, ​​ir

b) projektas - tai, kas gaunama sintezuojant sudėtingus vaizdus iš paprastesnių vaizdų rinkinio.

Šios dvi priežastys buvo pagrindu dabartiniam žodžio dizaino pasirinkimui kaip terminui, reiškiančiam pagrindinės kompiuterių mokslo veiklos kryptį.

Kuriant informacines sistemas, informacinės sistemos yra projektavimo objektai, ir tai yra visiškai natūralu informatikai (nes IS laikomi pagrindiniais jos objektais).

Kaip žinote, informacinės sistemos pačios gali parodyti įvairiausius visatos reiškinius, todėl visi reiškiniai taip pat yra potencialūs dizaino objektai.

Informacinės sistemos daugeliu atvejų tampa dizaino objektais, t.y. tų atlikėjų, kurie patys atlieka projektavimo procesą. Studijuodami projektavimo procesą, mes iš esmės užsiimame informacinių sistemų tyrimu.

Sistema suprantama kaip bet koks objektas, kuris vienu metu laikomas ir viena visuma, ir kaip nevienalyčių elementų visuma, sujungta siekiant tikslų. Sistemos labai skiriasi viena nuo kitos tiek sudėtimi, tiek pagrindiniais tikslais.

Kompiuterių moksle sistemos sąvoka yra plačiai paplitusi ir turi daug semantinių reikšmių. Dažniausiai jis naudojamas aparatinės ir programinės įrangos rinkinio atžvilgiu. Žodžio informacinės sistemos sąvokos papildymas atspindi jos sukūrimo ir veikimo tikslą. Informacinės sistemos teikia informacijos, reikalingos sprendžiant bet kokios srities problemas, rinkimą, saugojimą, apdorojimą, paiešką ir pristatymą. Jie padeda analizuoti problemas ir kurti naujus produktus.

Informacinė sistema (IS) - tarpusavyje susijęs įrankių, metodų ir personalo rinkinys, naudojamas informacijai saugoti, apdoroti ir išduoti siekiant tikslo.

Šiuolaikinės informacinės technologijos suteikia platų IP diegimo metodų spektrą, kurio pasirinkimas grindžiamas numatomų vartotojų reikalavimais, kurie, kaip taisyklė, keičiasi kūrimo proceso metu.

Sąvokos „automatizuotas“ įtraukimas į „sistemos“ sąvoką atspindi tokios sistemos kūrimo ir veikimo būdus.

Automatizuota sistema(pagal GOST) yra sistema, susidedanti iš tarpusavyje susijusių organizacinių vienetų rinkinio ir veiklos automatizavimo įrankių rinkinio, įgyvendinančio automatizuotas funkcijas tam tikros rūšys veiklą.

Automatizuota informacinė sistema (AIS) yra programinės įrangos, techninių, informacinių, kalbinių, organizacinių ir technologinių priemonių bei personalo kompleksas, skirtas spręsti informacinių ir informacinių paslaugų ir (arba) informacijos palaikymo vartotojams problemas.

Automatizuota informacinė sistema yra informacijos, ekonominių ir matematinių metodų ir modelių, techninių, programinės įrangos, technologinių priemonių ir specialistų rinkinys, skirtas informacijai apdoroti ir valdymo sprendimams priimti.

Pagrindinis automatizuotų informacinių sistemų tikslas yra ne tik rinkti ir išsaugoti elektroninius informacijos išteklius, bet ir suteikti vartotojams prieigą prie jų. Vienas iš svarbiausių AIS bruožų yra duomenų paieškos jų informacijos masyvuose (duomenų bazėse) organizavimas.

Pagal AIS projektą turime omenyje projektavimo ir technologinę dokumentaciją, kurioje aprašomi projektavimo sprendimai kuriant ir eksploatuojant IS konkrečioje programinės ir techninės įrangos aplinkoje.

Galima išskirti šiuos pagrindinius projekto, kaip valdymo objekto, skiriamuosius bruožus:

· Ribotas galutinis tikslas;

· Ribota trukmė;

· Ribotas biudžetas;

· Reikalingi riboti ištekliai;

· Naujovė įmonei, kuriai įgyvendinamas projektas;

· Sudėtingumas;

· Teisinė ir organizacinė pagalba.

Atsižvelgiant į projektų planavimą ir valdymą, būtina aiškiai suprasti, kad kalbame apie tam tikro dinamiško objekto valdymą. Todėl projektų valdymo sistema turi būti pakankamai lanksti, kad ją būtų galima keisti be pasaulinių pokyčių darbo programa... Darbų vykdymą užtikrina būtinų išteklių prieinamumas: medžiagos; įranga; Žmogiškieji ištekliai. Kontrolės sistemų teorijos požiūriu, projektas kaip kontrolės objektas turi būti stebimas ir kontroliuojamas, tai yra, išskiriamos kai kurios charakteristikos, kuriomis galima nuolat stebėti projekto eigą. Be to, reikia mechanizmų, kurie leistų laiku paveikti projekto eigą.

AIS dizainas suprantamas kaip įvesties informacijos apie objektą, metodų ir patirties projektuojant panašios paskirties objektus pagal GOST pavertimas IS projektu.

Šiuo požiūriu AIS kūrimas susijęs su nuosekliu dizaino sprendimų įforminimu įvairiuose AIS gyvavimo ciklo etapuose: reikalavimų planavimas ir analizė, techninis ir išsamus dizainas, AIS diegimas ir veikimas.

Kuriamų sistemų mastas lemia projektavimo proceso sudėtį ir dalyvių skaičių. Turėdami didelę apimtį ir griežtus terminus projektavimo darbams įgyvendinti, sistemos kūrime gali dalyvauti kelios projektavimo komandos (kūrimo organizacijos). Šiuo atveju paskirta pirminė organizacija, kuri koordinuoja visų kartu vykdančių organizacijų veiklą.

AIS projektavimo technologija yra AIS metodikos ir projektavimo priemonių rinkinys, taip pat jo organizavimo metodai ir priemonės (AIS projekto kūrimo ir modernizavimo proceso valdymas).

Projektavimo technologija pagrįsta technologiniu procesu, kuris lemia veiksmus, jų seką, reikiamą atlikėjų sudėtį, priemones ir išteklius.

Visas AIS projektavimo technologinis procesas yra suskirstytas į nuosekliai lygiagrečių, sujungtų ir pavaldžių veiksmų grandinių rinkinį, kurių kiekvienas gali turėti savo temą. Taigi projektavimo technologiją nustato reglamentuota technologinių operacijų seka, atliekama remiantis vienu ar kitu metodu, todėl paaiškėja ne tik tai, ką reikia padaryti norint sukurti projektą, bet ir kaip, kas, ir kokia seka.

Bet kurios pasirinktos projektavimo technologijos objektas turėtų būti tarpusavyje susijusių projektavimo procesų atspindys visuose AIS gyvavimo ciklo etapuose. Pagrindiniai pasirinktos projektavimo technologijos reikalavimai yra šie:

· Sukurtas projektas turi atitikti užsakovo reikalavimus;

· Maksimalus visų projekto gyvavimo ciklo etapų atspindys;

· Užtikrinti minimalias darbo ir išlaidų išlaidas projektavimui ir projektų paramai;

· Technologijos turėtų būti dizaino ir paramos projektui komunikacijos pagrindas;

· Dizainerio produktyvumo padidėjimas;

· Projekto projekto ir veikimo patikimumas;

· Paprasta projekto dokumentacijos priežiūra.

AIS projektavimo technologija grindžiama metodika, kuri apibrėžia esmę, pagrindines skiriamąsias technologines ypatybes.

Projektavimo metodika reiškia, kad egzistuoja tam tikra koncepcija, projektavimo principai, įgyvendinami metodų rinkiniu, kurie savo ruožtu turi būti paremti tam tikromis priemonėmis.

Dizaino organizavimas apima dizainerių ir kliento sąveikos metodų apibrėžimą kuriant AIS projektą, kurį taip pat galima paremti specialių įrankių rinkiniu.

kompiuterinė projektavimo informacinė sistema

2. TIKSLAS IR DIZAINO TIKSLAI

Informacinių sistemų projektavimas visada prasideda nuo projekto tikslo apibrėžimo. Projekto tikslas yra techninės ir informacijos, matematinės, programinės įrangos ir organizacinės bei teisinės pagalbos formavimas.

Techninė pagalba turėtų būti parinkta taip, kad būtų užtikrintas savalaikis informacijos rinkimas, registravimas, perdavimas, saugojimas, užpildymas ir apdorojimas.

Informacinė parama turėtų numatyti vieno sistemos informacijos fondo, kurį sudaro įvairūs informacijos masyvai, duomenų rinkinys ar duomenų bazė, sukūrimą ir veikimą.

Sistemų matematinės paramos formavimas apima visą funkcinių problemų sprendimo metodų ir algoritmų rinkinį. Kuriant programinės įrangos sistemas ypatingas dėmesys skiriamas programų ir vartotojo instrukcijų rinkinio sukūrimui bei efektyvių programinės įrangos produktų parinkimui.

Pagrindinis bet kurio sėkmingo projekto uždavinys yra užtikrinti, kad sistemos paleidimo metu ir jos veikimo metu būtų galima užtikrinti:

· Reikalingas sistemos funkcionalumas ir prisitaikymo prie kintančių jos veikimo sąlygų laipsnis;

· Reikalingas sistemos pralaidumas;

· Reikalingas sistemos atsakymo į užklausą laikas;

· Netrukdomas sistemos veikimas reikiamu režimu, kitaip tariant - sistemos pasirengimas ir prieinamumas apdoroti vartotojų užklausas;

· Lengvas sistemos veikimas ir palaikymas;

· Būtinas saugumas.

Našumas yra pagrindinis sistemos efektyvumo veiksnys. Geras dizainas yra aukštos kokybės sistemos pagrindas.

Automatizuotų informacinių sistemų projektavimas apima tris pagrindines sritis:

· Duomenų objektų, kurie bus įdiegti duomenų bazėje, projektavimas;

· Kuriant programas, ekranus, ataskaitas, kurios užtikrins duomenų užklausų vykdymą;

· Atsižvelgiant į konkrečią aplinką ar technologiją, būtent: tinklo topologiją, aparatūros konfigūraciją, naudojamą architektūrą (failų serveris arba klientas-serveris), lygiagretų apdorojimą, paskirstytą duomenų apdorojimą ir kt.

Esant realioms sąlygoms, dizainas yra metodo, atitinkančio sistemos funkcionalumo reikalavimus, paieška naudojant turimas technologijas, atsižvelgiant į nurodytus apribojimus.

Bet kuriam projektui keliama daugybė absoliučių reikalavimų, pavyzdžiui, maksimalus projekto kūrimo laikas, maksimalios finansinės investicijos į projektą ir kt. Vienas iš projektavimo sunkumų yra tai, kad tai nėra tokia struktūrizuota užduotis kaip projekto reikalavimų analizė ar tam tikro dizaino sprendimo įgyvendinimas.

3. DIZAINO ETAPAI

AIS kūrimo procesas suskirstytas į keletą etapų (etapų), ribojamų tam tikru laikotarpiu ir baigiantis konkretaus produkto išleidimu.

Kiekvienas projektas, neatsižvelgiant į jo įgyvendinimui reikalingų darbų sudėtingumą ir apimtį, kuriamas tam tikromis būsenomis. Iš būsenos, kai „projekto dar nėra“, į būseną, kai „projekto nebėra“. Plėtros etapų rinkinys nuo idėjos atsiradimo iki visiško projekto užbaigimo paprastai skirstomas į etapus.

Pradinių AIS kūrimo etapų, atliekamų organizacijos veiklos analizės etape, tikslas yra suformuluoti AIS reikalavimus, kurie teisingai ir tiksliai atspindėtų klientų organizacijos tikslus ir uždavinius. Norint patikslinti organizacijos poreikius atitinkančios AIS kūrimo procesą, būtina išsiaiškinti ir aiškiai suformuluoti, kokie yra šie poreikiai. Norėdami tai padaryti, būtina nustatyti klientų reikalavimus AIS ir modelių kalba susieti juos su AIS projekto kūrimo reikalavimais, kad būtų užtikrintas organizacijos tikslų ir uždavinių laikymasis.

Galima išskirti šiuos automatizuotų informacinių sistemų kūrimo etapus:

3.1 Sąvokos formavimas. Koncepcinis etapas

Tai įtraukia:

· Idėjų formavimas;

· Pagrindinės projekto komandos sudarymas;

· Kliento ir kitų dalyvių motyvacijos ir reikalavimų tyrimas;

· Pradinių duomenų rinkimas ir esamos būklės analizė;

· Pagrindinių reikalavimų ir apribojimų, reikalingų materialinių, finansinių ir darbo išteklių nustatymas;

· Lyginamasis alternatyvų vertinimas;

· Pasiūlymų teikimas, jų nagrinėjimas ir tvirtinimas.

Užduotis suformuoti AIS reikalavimus yra viena iš svarbiausių, sunkiai įforminamų ir brangiausių bei sunkiai ištaisomų klaidos atveju. Šiuolaikiniai įrankiai ir programinės įrangos produktai leidžia greitai sukurti AIS pagal paruoštus reikalavimus. Tačiau dažnai šios sistemos netenkina klientų, reikalauja daugybės pakeitimų, o tai labai padidina faktines AIS išlaidas. Pagrindinė šios situacijos priežastis yra neteisingas, netikslus ar neišsamus AIS reikalavimų apibrėžimas analizės etape.

3.2 Techninio pasiūlymo rengimas

§ pagrindinio projekto struktūros pagrindinio turinio kūrimas;

§ techninių specifikacijų rengimas ir patvirtinimas;

§ pagrindinio projekto struktūrinio modelio planavimas, skaidymas;

§ projekto sąmatų ir biudžeto sudarymas;

§ plėtra kalendoriniai planai ir padidintas darbo grafikas;

§ sutarties su klientu pasirašymas;

§ pradėti eksploatuoti projekto dalyvių komunikacijos priemones ir darbo eigos kontrolės priemones.

3.3 Dizainas

Projektavimo etape nustatomi posistemiai, jų tarpusavio ryšiai ir parenkami efektyviausi išteklių projektavimo ir naudojimo būdai. Įprasti šio etapo darbai:

§ pagrindinių projektavimo darbų atlikimas;

§ privačių techninių specifikacijų rengimas;

§ koncepcinio dizaino įgyvendinimas;

§ techninių specifikacijų ir instrukcijų rengimas;

§ projekto rengimo, tikrinimo ir patvirtinimo pristatymas.

Projektavimo etape pirmiausia formuojami duomenų modeliai. Dizaineriai gauna analizės rezultatus kaip įvestį. Loginių ir fizinių duomenų modelių kūrimas yra esminė duomenų bazės kūrimo dalis. Analizės metu gautas informacijos modelis pirmiausia paverčiamas loginiu, o paskui fiziniu duomenų modeliu.

3.4 Plėtra

Plėtros etape atliekamas projekto darbo koordinavimas ir operatyvinė kontrolė, posistemių gamyba, derinimas ir bandymas.

Sėkmingai išlaikius autonominį testą, modulis įtraukiamas į sukurtą sistemos dalį, o sugeneruotų modulių grupei atliekami ryšio bandymai, kurie turėtų sekti jų tarpusavio įtaką.

Be to, modulių grupė yra patikrinta dėl veikimo patikimumo, tai yra, jie, pirma, praeina bandymus, imituojančius sistemos gedimus, ir, antra, bandymų trukmę tarp gedimų. Pirmoji bandymų grupė parodo, kaip gerai sistema atsigauna po programinės įrangos gedimų, aparatinės įrangos gedimų. Antroji bandymų grupė nustato sistemos stabilumo laipsnį įprasto darbo metu ir leidžia įvertinti sistemos veikimo laiką. Į stabilumo bandymų rinkinį turėtų būti įtraukti bandymai, imituojantys didžiausią sistemos apkrovą.

Tada visas modulių rinkinys atlieka sistemos testą - vidinį produkto priėmimo testą, parodantį jo kokybės lygį. Tai apima funkcionalumo testus ir sistemos patikimumo testus.

Paskutinis automatinis testas informacinė sistema- priėmimo testai. Toks bandymas apima informacinės sistemos parodymą klientui ir turi apimti bandymų grupę, imituojančią realius verslo procesus.

3.5 Sistemos paleidimas

Sistemos eksploatavimo etape atliekami bandymai, sistema bandoma realiomis sąlygomis, vyksta derybos dėl projekto rezultatų ir dėl galimų naujų sutarčių.

Pagrindinės darbo rūšys:

§ sudėtingi bandymai;

§ personalo mokymas kuriamos sistemos veikimui;

§ darbo dokumentų parengimas, sistemos pristatymas vartotojui ir jos paleidimas;

§ lydėjimas, palaikymas, aptarnavimas;

§ projekto rezultatų vertinimas ir galutinių dokumentų rengimas.

4. TECHNINIO DIZAINO IR TECHNINIO DIZAINO SUDĖTIS IR STRUKTŪRA

1. Bendrosios nuostatos

1.1. Techninės užduotys (TOR) yra pagrindinis dokumentas, apibrėžiantis informacinės sistemos sukūrimo (kūrimo ar modernizavimo - tolesnio kūrimo) reikalavimus ir tvarką, pagal kurią vykdomas IS kūrimas ir priėmimas jį paleidus. .

1.2. TK yra sukurta visai sistemai, skirta dirbti savarankiškai arba kaip kitos sistemos dalis.

1.3. Šio standarto nustatytos apimties IS reikalavimus galima įtraukti į naujai sukurto informacinio objekto projektavimo užduotį. Šiuo atveju TK nėra išvystytas.

1.4. Į TK įtraukti reikalavimai turi atitikti esamą išsivystymo lygį informacines technologijas ir nepasiduoti panašiems reikalavimams geriausiems šiuolaikiniams šalies ir užsienio kolegoms. TK nustatyti reikalavimai neturėtų riboti sistemos kūrėjo ieškant ir įgyvendinant efektyviausius techninius, techninius, ekonominius ir kitus sprendimus.

1.5. TK apima tik tuos reikalavimus, kurie papildo tokio tipo sistemoms keliamus reikalavimus ir yra nulemti konkretaus objekto, kuriam sukurta sistema, specifikos.

1.6. TK pakeitimai sudaromi papildant arba protokolu, kurį pasirašo užsakovas ir kūrėjas. Papildymas arba nurodytas protokolas yra neatskiriama TK IP dalis. Tituliniame TK puslapyje turėtų būti įrašas „Galioja nuo ...“.

2. Sudėtis ir turinys

2.1. TK yra šie skyriai, kuriuos galima suskirstyti į poskyrius:

1) bendra informacija;

2) sistemos kūrimo (plėtojimo) tikslas ir tikslai;

3) objektų charakteristikos;

4) sistemos reikalavimai;

5) sistemos sukūrimo darbų sudėtis ir turinys;

6) sistemos kontrolės ir priėmimo tvarka;

7) kūrimo objekto paruošimo sistemos paleidimui darbo sudėties ir turinio reikalavimai;

8) reikalavimai dokumentacijai;

9) vystymosi šaltiniai.

TK gali apimti programas.

2.2. Atsižvelgiant į projekto tipą, paskirtį, specifines ypatybes ir sistemos veikimo sąlygas, leidžiama įforminti TK skyrius paraiškų forma, įvesti papildomus, neįtraukti arba sujungti TK poskyrius.

Sistemos dalių TK neapima sekcijų, kurios dubliuoja viso TK sekcijų turinį.

2.3. Skiltyje „Bendra informacija“ nurodykite:

1) visas sistemos pavadinimas ir jos simbolis;

2) temos kodas arba sutarties kodas (numeris);

3) sistemos kūrėjo ir kliento (vartotojo) įmonių pavadinimai ir jų duomenys;

4) dokumentų, kuriais remiantis sukurta sistema, sąrašą, kas ir kada šiuos dokumentus patvirtino;

5) planuojamos sistemos sukūrimo pradžios ir pabaigos datos;

6) informacija apie darbų finansavimo šaltinius ir tvarką;

7) sistemos (jos dalių) kūrimo, atskirų priemonių (aparatūros, programinės įrangos, informacijos) ir programinės bei aparatinės įrangos (programinės įrangos ir metodikos) registravimo ir pateikimo klientui darbo rezultatų ( ) sistemos kompleksai.

2.4. Skyrius „Sistemos kūrimo (plėtojimo) tikslas ir tikslai“ susideda iš poskyrių:

1) sistemos paskirtis;

2) sistemos sukūrimo tikslas.

2.4.1. Poskyryje „Sistemos paskirtis“ nurodykite sistemos veiklos rūšį (valdymas, projektavimas ir kt.) Ir informacinių objektų (objektų), kuriuose ji turėtų būti naudojama, sąrašą.

2.4.2. Poskirsnyje „Sistemos kūrimo tikslai“ pateikiami informacinio objekto techninių, technologinių, gamybinių-ekonominių ar kitų rodiklių pavadinimai ir reikalaujamos vertės, kurios turi būti pasiektos sukūrus IS. , ir nurodyti sistemos kūrimo tikslų pasiekimo vertinimo kriterijai.

2.5. Skiltyje „Informacinio objekto charakteristikos“ nurodykite:

1) trumpa informacija apie informavimo objektą arba nuorodos į dokumentus, kuriuose yra tokios informacijos;

2) informacija apie automatikos objekto veikimo sąlygas.

2.6. Sistemos reikalavimų skyrių sudaro šie poskyriai:

1) reikalavimai visai sistemai;

2) reikalavimai sistemos vykdomoms funkcijoms (užduotims);

3) reikalavimai saugumo rūšims.

Sistemai keliamų reikalavimų, įtrauktų į šį TK IS skiltį, sudėtis nustatoma atsižvelgiant į konkrečios sistemos tipą, paskirtį, specifines savybes ir veikimo sąlygas.

2.6.1. Skiltyje „Reikalavimai visai sistemai“ nurodykite:

reikalavimai sistemos struktūrai ir veikimui;

reikalavimai sistemos darbuotojų skaičiui ir kvalifikacijai bei jų darbo režimui;

paskirties rodikliai;

patikimumo reikalavimai;

saugos reikalavimai;

ergonomikos ir techninės estetikos reikalavimai;

sistemos komponentų eksploatavimo, priežiūros, remonto ir laikymo reikalavimai;

informacijos apsaugos nuo neteisėtos prieigos reikalavimai;

informacijos saugos reikalavimai avarijų atveju;

apsaugos nuo išorės įtakos poveikio reikalavimai;

patento grynumo reikalavimai;

standartizacijos ir suvienodinimo reikalavimai;

Papildomi reikalavimai.

2.6.1.1. Reikalavimai sistemos struktūrai ir veikimui yra šie:

1) posistemių sąrašas, jų paskirtis ir pagrindinės charakteristikos, reikalavimai hierarchijos lygių skaičiui ir sistemos centralizavimo laipsniui;

2) keitimosi informacija tarp sistemos komponentų ryšio metodų ir priemonių reikalavimai;

3) reikalavimai kuriamos sistemos ir gretimų sistemų jungčių charakteristikoms, jos suderinamumo reikalavimai, įskaitant instrukcijas, kaip keistis informacija (automatiškai, siunčiant dokumentus, telefonu ir pan.);

4) reikalavimai sistemos veikimo režimams;

5) sistemos diagnostikos reikalavimai;

6) sistemos plėtros, modernizavimo perspektyvos.

2.6.1.2. IS personalo skaičiui ir kvalifikacijai keliami šie reikalavimai:

§ IS personalo (vartotojų) skaičiaus reikalavimai;

§ personalo kvalifikacijos reikalavimai, jų mokymo ir žinių bei įgūdžių kontrolės tvarka;

§ būtinas IS personalo darbo režimas.

2.6.1.3. Reikalavimuose IS tikslo rodikliams nurodomos parametrų, kurie apibūdina sistemos atitikties jos tikslui laipsnį, vertės.

2.6.1.4. Patikimumo reikalavimai apima:

1) visos sistemos ar jos posistemių patikimumo rodiklių sudėtis ir kiekybinės vertės;

2) avarinių situacijų, dėl kurių turi būti reglamentuojami patikimumo reikalavimai, sąrašas ir atitinkamų rodiklių vertės;

3) techninės ir programinės įrangos patikimumo reikalavimai;

4) patikimumo rodiklių vertinimo ir stebėjimo metodų reikalavimai įvairiuose sistemos kūrimo etapuose pagal galiojančius norminius ir techninius dokumentus.

2.6.1.5. Saugos reikalavimai apima sistemos pristatymo, paleidimo, eksploatavimo ir priežiūros saugos reikalavimus.

2.6.1.6. Ergonomikos ir techninės estetikos reikalavimai apima IP rodiklius, nustatančius reikiamą žmogaus ir mašinos sąveikos kokybę bei personalo darbo sąlygų patogumą.

2.6.1.7. Informacijos apsaugos nuo neteisėtos prieigos reikalavimai apima pramonės ir kliento informacinės aplinkos nustatytus reikalavimus.

2.6.1.8. Informacijos saugos reikalavimuose pateikiamas įvykių sąrašas: nelaimingi atsitikimai, techninių priemonių gedimai (įskaitant galios praradimą) ir kt., Kuriuose turi būti užtikrintas informacijos saugumas sistemoje.

2.6.1.9. Patento grynumo reikalavimuose nurodomas šalių, kuriose turi būti užtikrintas sistemos ir jos dalių patento grynumas, sąrašas.

2.6.1.10. Papildomi reikalavimai apima specialius reikalavimus sistemos kūrėjo ar kliento nuožiūra.

2.6.2. Poskyryje „Reikalavimai funkcijoms (užduotims)“, kuriuos atlieka sistema, pateikiama:

§ kiekvieno posistemio funkcijų, užduočių ar jų kompleksų (įskaitant tuos, kurie užtikrina sistemos dalių sąveiką), sąrašą, kurį reikia automatizuoti;

§ kuriant sistemą dviejose ar daugiau eilių - funkcinių posistemių, atskirų funkcijų ar užduočių, kurios pradedamos eksploatuoti 1 -oje ir vėlesnėse eilėse, sąrašas;

§ kiekvienos funkcijos, užduoties (ar užduočių rinkinio) įgyvendinimo grafikas;

§ reikalavimai kiekvienos funkcijos (užduoties ar užduočių komplekso) įgyvendinimo kokybei, išvesties informacijos pateikimo formai, reikiamo tikslumo ir vykdymo laiko charakteristikoms, reikalavimai tuo pačiu metu atlikti funkcijų grupę, patikimumas apie rezultatus;

§ kiekvienos funkcijos gedimų sąrašas ir kriterijai, kuriems nustatyti patikimumo reikalavimai.

2.6.3. Poskyryje „Reikalavimai paramos rūšims“, atsižvelgiant į sistemos tipą, pateikiami matematinių, informacinių, kalbinių, programinės, techninės, metrologinės, organizacinės, metodinės ir kitų sistemų palaikymo reikalavimų reikalavimai.

2.6.3.2. Informacinei sistemos palaikymui pateikiami šie reikalavimai:

1) į duomenų sudėtį, struktūrą ir metodus sistemoje;

2) keistis informacija tarp sistemos komponentų;

3) informacijos suderinamumas su susijusiomis sistemomis;

4) dėl duomenų bazių valdymo sistemų taikymo;

5) duomenų rinkimo, apdorojimo, duomenų perdavimo sistemoje ir pateikimo proceso struktūrai;

6) duomenų apsaugai;

7) duomenų valdymas, saugojimas, atnaujinimas ir atkūrimas;

2.6.3.3. Kalbant apie sistemos palaikymą, pateikiami aukšto lygio programavimo kalbų naudojimo sistemoje reikalavimai, naudotojų ir sistemos techninių priemonių sąveikos kalbos, taip pat duomenų kodavimo ir dekodavimo reikalavimai. duomenų įvesties ir išvesties kalbos, duomenų manipuliavimo kalbos, dalyko srities apibūdinimo priemonės, dialogo organizavimo metodai.

2.6.3.4. Sistemos programinei įrangai pateikiamas įsigytos programinės įrangos sąrašas ir reikalavimai:

1) programinės įrangos priklausomybę nuo veiklos aplinkos;

2) programinės įrangos kokybei, taip pat jos teikimo ir kontrolės metodams;

2.6.3.5. Sistemos techninei pagalbai pateikti šie reikalavimai:

1) techninių priemonių rūšims, įskaitant techninių priemonių kompleksų tipus, programinės ir aparatinės įrangos kompleksus bei kitus komponentus, leidžiamus naudoti sistemoje;

2) į sistemos techninės pagalbos funkcines, konstrukcines ir eksploatacines charakteristikas.

2.6.3.6. Metrologinei paramai keliami šie reikalavimai:

1) preliminarus matavimo kanalų sąrašas;

2) parametrų matavimo tikslumo ir (arba) matavimo kanalų metrologinių charakteristikų reikalavimai;

3) sistemos techninių priemonių metrologinio suderinamumo reikalavimai;

4) sistemos valdymo ir skaičiavimo kanalų, kurių tikslumo charakteristikas būtina įvertinti, sąrašas;

5) reikalavimai, taikomi metrologinei techninės ir programinės įrangos, kurios yra sistemos matavimo kanalų dalis, priemonėms, integruotam valdymui, matavimo kanalų ir matavimo priemonių, naudojamų sistemai nustatyti ir išbandyti, metrologiniam tinkamumui;

6) metrologinio sertifikavimo tipas (valstybinis ar departamentinis), nurodant jo įgyvendinimo tvarką ir sertifikavimą vykdančias organizacijas.

2.6.3.7. Organizacinei paramai pateikti šie reikalavimai:

1) padalinių, dalyvaujančių sistemos veikime ar veikiančių operacijų, struktūrai ir funkcijoms;

2) sistemos veikimo organizavimui ir IS personalo bei informacinio objekto personalo sąveikos tvarkai;

3) apsaugoti nuo klaidingų sistemos darbuotojų veiksmų.

2.7. Skiltyje „Sistemos kūrimo (kūrimo) darbo sudėtis ir turinys“ turi būti sistemos kūrimo etapų ir etapų sąrašas, jų įgyvendinimo laikas, organizacijų - darbų vykdytojų sąrašas , nuorodos į dokumentus, patvirtinančius šių organizacijų sutikimą dalyvauti kuriant sistemą, arba įrašas, kuriame nurodomas už šiuos darbus atsakingas asmuo (užsakovas ar kūrėjas).

Šiame skyriuje taip pat pateikiama:

1) dokumentų, pateiktų atitinkamų darbo etapų ir etapų pabaigoje, sąrašas;

2) techninės dokumentacijos nagrinėjimo rūšis ir tvarka (patikrintų dokumentų stadija, etapas, apimtis, ekspertų organizacija);

3) darbo programa, kuria siekiama užtikrinti reikiamą kuriamos sistemos patikimumo lygį (jei reikia);

4) darbų, susijusių su metrologine parama visuose sistemos kūrimo etapuose, sąrašas, nurodant jų terminus ir vykdančias organizacijas (jei reikia).

2.8. Skiltyje „Sistemos kontrolės ir priėmimo tvarka“ nurodykite:

1) sistemos ir jos komponentų tipai, sudėtis, apimtis ir bandymo metodai;

2) bendrieji darbų priėmimo etapais reikalavimai, priėmimo dokumentų derinimo ir tvirtinimo tvarka;

2.9. Skiltyje „Automatizavimo objekto paruošimo sistemos paleidimui darbo sudėties ir turinio reikalavimai“ būtina pateikti pagrindinių veiklų ir jų vykdytojų, kuriuos reikia atlikti rengiant projektą, sąrašą. IS paleidimas.

Pagrindinių veiklų sąrašą sudaro:

1) į sistemą įeinančios informacijos pateikimas (pagal informacijos ir kalbinės pagalbos reikalavimus);

2) sąlygų projekto veikimui sukūrimas, pagal kurį garantuojama sukurtos sistemos atitiktis TK nustatytiems reikalavimams;

3) sistemos veikimui būtinų padalinių ir paslaugų kūrimas;

4) personalo ir personalo mokymo laikas ir tvarka.

2.10. Skiltyje „Dokumentacijos reikalavimai“ pateikiama:

1) dokumentų, kuriuos reikia sukurti, rinkinių ir tipų sąrašas, suderintas su sistemos kūrėju ir užsakovu;

2) mašininėje laikmenoje išduotų dokumentų sąrašas;

3) jei nėra valstybinių standartų, nustatančių sistemos elementų dokumentavimo reikalavimus, papildomai įtraukite reikalavimus dėl tokių dokumentų sudėties ir turinio.

2.11. Skyriuje „Plėtros šaltiniai“ turėtų būti išvardyti dokumentai ir informacinė medžiaga, kurios pagrindu buvo sukurtas TK ir kurie turėtų būti naudojami kuriant sistemą.

3. Dizaino taisyklės.

3.1. TK skyriai ir poskyriai turi būti išdėstyti skyriuje nustatyta tvarka. 2 šio standarto.

3.2. Lakštų (puslapių) skaičius dedamas nuo pirmojo lapo po titulinio puslapio viršutinėje lapo dalyje (virš teksto, viduryje) po TK kodo žymėjimo IP.

3.3. Tituliniame puslapyje yra užsakovo, kūrėjo ir patvirtinančių įmonių parašai, kurie yra užantspauduoti. Jei reikia, titulinis puslapis sudaromas iš kelių puslapių. TK kūrėjų ir pareigūnų, dalyvaujančių susitarime ir TK projekto svarstymo IP, parašai pateikiami paskutiniame lape.

TK titulinio lapo forma pateikta 2 priede. Paskutinio TK puslapio forma pateikta 3 priede.

3.4. TK priedo titulinis lapas sudaromas taip pat, kaip ir techninės užduoties titulinis puslapis. Vietoj pavadinimo „Įgaliojimai“ jie rašo „TK priedas Nr. ... AC“.

3.5. Vėlesniuose TK papildymo lapuose pateikiamas pakeitimo pagrindas, pakeitimo turinys ir nuorodos į dokumentus, pagal kuriuos šie pakeitimai daromi.

3.6. Pateikiant TK papildymo tekstą, turėtų būti nurodyti atitinkamų punktų, poskyrių, pagrindinių TK lentelių ir kt. Numeriai ir žodžiai „pakeisti“, „papildyti“, „neįtraukti“, „pakeisti “Turėtų būti naudojamas.

TK IP kūrimo, koordinavimo ir patvirtinimo procedūra.

1. TK projektą rengia organizacijos organizacija-kūrėja, dalyvaujant klientui, remiantis techniniais reikalavimais (taikomosiomis programomis, taktinėmis ir techninėmis specifikacijomis ir kt.).

Organizuodamas konkurencinį darbo organizavimą, TK projekto projektus apsvarsto klientas, kuris arba pasirenka pageidaujamą variantą, arba, remdamasis lyginamąja analize, parengia galutinę TK versiją AC, dalyvaujant būsimas IS kūrėjas.

2. Poreikį patvirtinti TK projektą su valstybinėmis priežiūros institucijomis ir kitomis suinteresuotomis organizacijomis bendrai nustato sistemos užsakovas ir TK projekto dėl IS rengėjas,

TK projekto IC patvirtinimo darbus bendrai atlieka TK kūrėjas ir sistemos klientas, kiekvienas savo ministerijos (departamento) organizacijose.

3. TK projekto patvirtinimo terminas kiekvienoje organizacijoje neturėtų viršyti 15 dienų nuo jo gavimo dienos. Rekomenduojama TK projekto kopijas (kopijas) vienu metu siųsti visoms organizacijoms (skyriams) tvirtinti.

4. Pastabos dėl TOR projekto turėtų būti pateiktos kartu su techniniu pagrindimu. Sprendimus dėl pastabų turėtų priimti TK projekto rengėjas ir sistemos klientas prieš patvirtindami TK dėl IS.

5. Jei, sutariant dėl ​​TK projekto, tarp kūrėjo ir užsakovo (ar kitų suinteresuotų organizacijų) kilo nesutarimų, tada surašomas nesutarimų protokolas (savavališka forma) ir priimamas konkretus sprendimas. nustatyta tvarka.

6. Patvirtinus TK projektą leidžiama surašyti atskirą dokumentą (raštą). Šiuo atveju antraštėje „Sutarta“ padarykite nuorodą į šį dokumentą.

7. TK patvirtinimą atlieka sistemos kūrėjo ir užsakovo įmonių vadovai.

8. Patvirtinto TK kopijas per 10 dienų po patvirtinimo TK kūrėjas siunčia sistemos kūrimo dalyviams.

9. TK papildymų koordinavimas ir patvirtinimas atliekamas taip, kaip nustatyta TK IP.

10. Pateikus sistemą ar jos eilę priėmimo testams, neleidžiama patvirtinti TK pakeitimų.

Sistemos techninio projekto rengimo pagrindas yra užsakovo patvirtinta techninė užduotis.

Techninis sistemos projektas yra nustatyta tvarka patvirtinta techninė dokumentacija, kurioje yra visos sistemos projektavimo sprendimai, problemų sprendimo algoritmas, taip pat automatizuotos valdymo sistemos ekonominio efektyvumo įvertinimas ir priemonių, skirtų parengti, sąrašas įgyvendinimo priemonę.

Techninis projektas rengiamas siekiant nustatyti pagrindinius sistemos kūrimo projektinius sprendimus. Šiame etape atliekamas tyrimų ir eksperimentinių darbų kompleksas, siekiant atrinkti geriausius sprendimus, atliekamas eksperimentinis pagrindinių projektinių sprendimų patikrinimas ir apskaičiuojamas sistemos ekonominis efektyvumas.

Tiesą sakant, techniniame projekte yra ekonominių, matematinių ir algoritminių modelių kompleksas.

Pilną sistemos techninį projektą sudaro 10 dokumentų:

1. Aiškinamasis raštas.

2. Funkcinė ir organizacinė sistemos struktūra.

3. Problemos konstatavimas ir sprendimo algoritmas.

4. Informacinės bazės organizavimas.

5. Dokumentų formų albumas.

6. Programinės įrangos sistema.

7. Techninių priemonių komplekso konstravimo principas.

8. Sistemos ekonominio efektyvumo apskaičiavimas.

9. Priemonės parengti įrenginį sistemos diegimui.

10. Dokumentų sąrašas.

Iš aukščiau pateikto sąrašo 3 dokumentas „Užduočių ataskaita ir sprendimo algoritmas“ atliekamas kiekvienai atskirai į EIS įtrauktai užduočiai, o kiti dokumentai yra bendri visai sistemai. Be to, atskiriems posistemiams galima parengti 1, 2, 5, 8 ir 9 dokumentus.

Visi išvardyti dokumentai gali būti sugrupuoti ir pateikti keturių pagrindinių techninio projekto dalių forma: ekonominė-organizacinė, informacinė, matematinė, techninė.

Ekonominėje ir organizacinėje techninio projekto dalyje yra aiškinamasis raštas, pagrindžiantis sistemos kūrimą, kūrėjų organizacijų sąrašas, trumpas objekto aprašymas, nurodant pagrindinius techninius ir ekonominius jo veikimo ir sąsajų su kitais objektais rodiklius, trumpas informacija apie pagrindinius funkcinių ir pagalbinių sistemos dalių projektavimo sprendimus.

Techninio projekto skyriuje, skirtame organizacinei ir funkcinei sistemos struktūrai, pateikiama: paskirstytų posistemių pagrindimas, jų sąrašas ir paskirtis; užduočių, kurias reikia išspręsti kiekviename posistemyje, sąrašas ir trumpas jų turinio aprašymas; informacinių ryšių tarp posistemių ir užduočių kiekviename posistemyje schema.

Kiekvienai užduočiai, įtrauktai į prioritetinių užduočių rinkinį, atliekamas jos teiginys ir jo sprendimo algoritmas. Į šį techninio projekto skyrių įeina:

§ organizacinė ir ekonominė problemos esmė (pavadinimas, sprendimo tikslas, santrauka, metodas, problemos sprendimo dažnumas ir laikas, duomenų rinkimo ir perdavimo metodai, problemos susiejimas su kitomis problemomis, rezultatų naudojimo pobūdis). tirpalas, kuriame jie naudojami);

§ ekonominis ir matematinis problemos modelis (struktūrinė ir išsami pateikimo forma);

§ įvesti operatyvinę informaciją (rodiklių charakteristikos, jų reikšmė ir pokyčių diapazonas, pateikimo formos);

§ norminė informacinė informacija (NSI) - pateikimo turinys ir formos;

§ informacija, saugoma bendraujant su kitomis užduotimis;

§ informacija, sukaupta vėlesniems šios problemos sprendimams;

§ informacija apie pakeitimus (pakeitimų atlikimo sistema ir keistinos informacijos sąrašas);

§ problemos sprendimo algoritmas (skaičiavimo etapų seka, diagrama, skaičiavimo formulės);

§ bandomasis atvejis (įvesties dokumento formų rinkinys, užpildytas duomenimis, sąlyginiai dokumentai su sukaupta ir saugoma informacija, išvesties dokumentų formos, užpildytos remiantis ekonominės ir techninės problemos sprendimo rezultatais ir pagal sukurtą skaičiavimo algoritmą).

Dokumente „Sistemos ekonominio efektyvumo apskaičiavimas“ pateikiamas konsoliduotas išlaidų, susijusių su sistemų eksploatavimu, sąmata, pateikiamas metinio ekonominio efektyvumo apskaičiavimas, kurio šaltiniai yra sistemos gamybos struktūros optimizavimas. ekonomika (asociacija), gamybos sąnaudų mažinimas dėl racionalaus gamybos išteklių naudojimo ir nuostolių mažinimas, valdymo sprendimai.

Dokumente „Priemonės parengti įrenginį sistemos diegimui“ yra organizacinių priemonių, skirtų pagerinti esamą valdymo struktūrą, sąrašas, darbų, susijusių su sistemos diegimu, sąrašas, kuris turi būti atliktas detaliojo projektavimo etape, sąrašas, nurodant laiką ir atsakingus asmenis.

Informacinė techninio projekto dalis sujungia 4 ir 5 dokumentus. Dokumente „Informacinės bazės organizavimas“ atsispindi: informacijos šaltiniai ir jos perdavimo būdai pirminiam funkcinių užduočių kompleksui spręsti; sistemoje naudojamų rodiklių rinkinys; dokumentų sudėtis, terminai ir jų gavimo dažnumas; pagrindiniai NSI fondo organizavimo projektiniai sprendimai; NSI sudėtis, įskaitant išsamų sąrašą, jų apibrėžimą, reikšmingumą, pokyčių diapazoną ir NSI dokumentų sąrašą; pamatinių duomenų duomenų rinkinių sąrašas, jų apimtis, informacijos taisymo tvarka ir dažnis; pasiūlymai suvienodinti dokumentus, bandomasis NSI pakeitimo atvejis; struktūrinė NSI forma su elementų ryšio aprašymu; reikalavimai fondo kūrimo ir išlaikymo technologijai; pamatinių duomenų informacijos saugojimo, paieškos, modifikavimo ir kontrolės metodai, apimčių ir srautų nustatymas.

„Dokumentų formų albume“ yra nuorodų duomenų formos.

Techninio projekto matematinėje dalyje pateikiamas programinės įrangos struktūros pagrindimas, programavimo sistemos pasirinkimo pagrindimas, įskaitant standartinių programų sąrašą.

Techninę projekto dalį sudaro: techninių duomenų apdorojimo proceso schemos aprašymas ir pagrindimas; nestandartinės įrangos kūrimo reikalavimų pagrindimas; techninių priemonių komplekso ir jo funkcinių grupių struktūros pagrindimas ir pasirinkimas; priemonių rinkinys, užtikrinantis techninių priemonių veikimo patikimumą.

IŠVADA

Informacinės sistemos kūrimas, kaip taisyklė, atliekamas gana ilgai konkrečią įmonę... Įmonės dalykinės veiklos ypatybės, žinoma, turi įtakos informacinės sistemos struktūrai, tačiau tuo pat metu skirtingų įmonių struktūros paprastai yra panašios viena į kitą. Kiekviena organizacija, nepriklausomai nuo jos veiklos rūšies, susideda iš daugybės padalinių, tiesiogiai vykdančių vienokią ar kitokią įmonės veiklą, ir tokia situacija galioja beveik visoms organizacijoms, nesvarbu, kokia veikla jie užsiima.

Įdiegus šiuolaikines informacines technologijas, galima sutrumpinti konkrečių rinkodaros ir gamybos projektų rengimui reikalingą laiką, sumažinti neproduktyvias išlaidas jų įgyvendinimo metu, pašalinti klaidų galimybę rengiant apskaitos, technologinius ir kitokio pobūdžio dokumentus , kuris komercinei įmonei suteikia tiesioginį ekonominį poveikį.

Žinoma, norint atskleisti visas galimas kompiuterių naudojimo galimybes, jų darbe būtina naudoti programinę ir techninę įrangą, kuri geriausiai atitinka nustatytas užduotis. Todėl šiuo metu labai reikia komercinių įmonių kompiuterines programas kurie palaiko įmonės vadovybės darbą, taip pat informacija apie tai, kaip kuo geriau išnaudoti įmonės kompiuterinę įrangą.

Įgyvendinant AIS dizainą projektuotojai naudoja tam tikrą projektavimo technologiją, atitinkančią rengiamo projekto mastą ir charakteristikas.

NAUDOTOS LITERATŪROS SĄRAŠAS

1. Diskusijos „Automatizuotos informacinės sistemos“ [Elektroninis išteklius] studijų gairės. - Maskva, 2006. - Prieigos režimas:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Pavadinimas. iš ekrano.

2. Vikipedija, nemokama enciklopedija [Elektroninis šaltinis]/Straipsnis „Informacinė sistema“ - Prieigos režimas: http://ru.wikipedia.org/wiki/Information system.

3. Kompiuterinė spauda: interneto žurnalas. - Elektronas. Danas. - [B.m., 2001]. - Prieigos režimas: http://compress.ru/article.aspx?id=12282.

4. Vendrov AM, „Ekonominių informacinių sistemų programinės įrangos projektavimas“ / А.М. Vendra. - M.: „Finansai ir statistika“, 2000. - 364 p.

5. „Automatinės sistemos kūrimo sąlygos“ / - M.: GOST 34.602-89, 1990 m.

6. Grekul V.I. „Informacinių sistemų projektavimas“ / V.I. Grekulis, G. N. Denischenko, N.L. Korovkinas. - M.: Interneto informacinių technologijų universitetas, 2008 m.

Paskelbta „Allbest.ru“

Panašūs dokumentai

Informacinių sistemų kūrimas. Šiuolaikinė rinka finansinė ir ekonominė taikomoji programinė įranga. Automatinių informacinių sistemų diegimo privalumai ir trūkumai. Automatizuotų informacinių sistemų projektavimo metodai.

disertacija, pridėta 2015-11-22


Automatizuotų informacinių sistemų palaikymo tipai. Techninių specifikacijų rengimas, informacinės sistemos kūrimas, programos vartotojo vadovo parengimas. Programavimo įrankiai paskirstytoms informacijos apdorojimo sistemoms.

praktikos ataskaita, pridėta 2017 04 16


Automatizuotų informacinių sistemų gyvavimo ciklas. Automatizuotų sistemų, pagrįstų CASE technologijomis, projektavimo metodikos pagrindai. Automatizuotos sistemos analizės ir planavimo, konstravimo ir diegimo etapas. Krioklio ir spiralės modelis.

kursinis darbas pridėtas 2010-11-20


Informacinės sistemos samprata, informacinių sistemų tipai. Automatizuotų informacinių sistemų kūrimo priemonių analizė. Reikalavimai programai ir programinės įrangos produktui. Grafinės sąsajos formų ir duomenų bazių kūrimas.

disertacija, pridėta 2015-06-23


Sistemos, susidedančios iš personalo ir įrankių, skirtų jų veiklai automatizuoti, organizavimo principai. Įmonių automatizuotų informacinių sistemų projektavimas. Struktūra, įvesties ir išvesties srautai, automatinių sistemų apribojimai.

pristatymas pridėtas 2013-10-14


Informacinės sistemos koncepcija. Informacinių sistemų kūrimo etapai. Procesai informacinėje sistemoje. Informacinė sistema, skirta rasti rinkos nišas, sumažinti gamybos sąnaudas. Informacinės sistemos struktūra. Techninė pagalba.

santrauka, pridėta 2011-11-17


Informacinės sistemos organizavimas, architektūra ir struktūra. Jos darbo efektyvumo rodikliai. ACS analizės tikslai ir uždaviniai. Automatizuotų sistemų komponentai. Temos srities, įvesties ir išvesties duomenų aprašymas. Naudojimo pavyzdžių schemos sudarymas.

kursinis darbas pridėtas 2014-11-04


Automatizuotų informacinių sistemų (AIS) kūrimas ir organizavimas. Pagrindiniai AIS komponentai ir technologiniai procesai. AIS kūrimo etapai ir etapai nuo organizacijos vadovybės pozicijos. Automatizuotos sistemos dizaino sprendimų kompleksų kūrimas.

santrauka, pridėta 2012-10-18


Pagrindiniai veiksniai, turintys įtakos įmonių automatizuotų informacinių sistemų kūrimo istorijai. Jų bendrosios savybės ir klasifikacija. Integruotos AIS sudėtis ir struktūra. ERP sistemos kaip modernios rūšies įmonių informacinė sistema.

pristatymas pridėtas 2013-10-14


Dalyko srities analizė, automatizuotų informacinių sistemų projektavimo etapai. Programinės įrangos kūrimo įrankių sistemos. CASE įrankių vaidmuo kuriant informacinį modelį. Suprojektuotos duomenų bazės loginis modelis.

2015 m. Gruodžio 1 d. Įvyko atvira automatizuotos projektų valdymo informacinės sistemos (AIS PU) gynyba, sukurta Rusijos pramonės ir prekybos ministerijos įsakymu. Gynyboje, kuriai pirmininkavo Rusijos Federacijos pramonės ir prekybos ministro pirmasis pavaduotojas Glebas Nikitinas, dalyvavo ministerijos departamentų vadovai, Ekonominės plėtros ministerijos ir Rusijos Federacijos gynybos ministerijos atstovai.

Automatizuota projektų valdymo sistema skirta pagerinti Rusijos pramonės ir prekybos ministerijos efektyvumą remiant, prižiūrint ir įgyvendinant projektus, kurių tikslas, be kita ko, yra importo pakeitimas, eksporto didinimas, gamybos technologinė plėtra, kūrimas ir našių darbo vietų modernizavimas ir pramonės infrastruktūros (pramonės parkų, technologijų parkų, pramoninio dizaino ir inžinerijos centrų) plėtra.

Pagrindiniai sukurtos sistemos vartotojai kartu su ministerijos vadovybe ir darbuotojais, atsakingomis už valstybinių programų ir federalinių tikslinių programų įgyvendinimą, bus pramonės įmonės, įgyvendinančios savo investicinius projektus, federalinės vykdomosios valdžios institucijos, teikiančios valstybės paramą įmonėms, bankams, instituciniai investuotojai ir kitos finansų institucijos, dalyvaujančios finansuojant pramonės įmonių investicinius projektus ir pramonės infrastruktūros plėtros projektus.

Sistemą sukūrė Rusijos sistemų integratorius „Inline-Technologies“, dalyvaujant šalies programinės įrangos kūrėjui „LM-Soft“. AIS PU buvo sukurta remiantis rusiška 1C platforma, naudojant nemokamą programinę įrangą ir patentuotą programinę įrangą.

Remiantis sistemos funkcionalumo tyrimo rezultatais, teigiami atsiliepimai buvo gauti tiek iš Pramonės ir prekybos ministerijos vadovybės ir darbuotojų, tiek iš Ekonominės plėtros ministerijos, kuri yra atsakinga už projektų valdymo mechanizmų įgyvendinimą vyriausybėje. kūnai. Be to, teigiamų atsiliepimų apie AIS PU galimybes pateikė pramonės įmonės, kurios pristatė savo bandomuosius projektus kaip sistemos kūrimo dalį. Visų pirma, Krylovo valstybinio mokslinio centro, UAB Mokslo ir gamybos korporacijos „Uralvagonzavod“ ir Federalinės valstybės įmonių mokslinio tyrimo instituto „Geodezija“ atstovai teigiamai atsiliepė apie bandomąją AIS PU veiklą. Taip pat reikėtų pažymėti, kad Gynybos ministerijos jurisdikcijai priklausančios UAB „Garrison“ atstovai, taip pat kai kurių bankų, dalyvaujančių valstybėje, atstovai parodė didelį susidomėjimą šia sistema ir susidomėjimą bendru bendradarbiavimu įgyvendinant projektų valdymą. .

„Sukurta projektų valdymo sistema ne tik padidins ministerijos darbuotojų efektyvumą, bet ir leis organizuoti efektyvią sąveiką su pramonės projektų dalyviais iš pramonės įmonių, valdžios institucijų ir plėtros institucijų, finansų institucijų. „AIS PU“ veikia „vieno langelio“ principu, maksimaliai panaudodama elektronines dokumentų valdymo technologijas “, - apie Pramonės ir prekybos ministerijos Informacinių technologijų ir viešųjų ryšių departamento direktoriaus Sergejaus Valuevo komentavimą. sistema.

„Pagrindinis AIS PU diegimo tikslas yra pagerinti kontrolės ir valdymo kokybę, palengvinti valdžios institucijų ir didelio masto projektų vykdytojų sąveiką. Kuriant sistemą pirmiausia buvo atsižvelgiama į pramonės standartus, Vyriausybės dekretus ir įsakymus, Prezidento dekretus ir pramonės ir prekybos ministro įsakymus, taip pat į geriausią vidaus ir užsienio praktiką. AIS PU buvo sukurta daugiau nei 600 komponentų, įkelta daugiau nei 20 000 žinynų, žodynų ir klasifikatorių. Vykdant tolesnį darbą kuriant AIS PU, planuojama sistemą integruoti kaip vieną iš Pramonės valstybinės informacinės sistemos posistemių, kurią šiuo metu kuria Rusijos pramonės ir prekybos ministerija “, - sakė Sergejus Valuevas.

Projektų valdymo metodų įvedimas apibrėžiamas kaip viena iš pagrindinių viešojo administravimo modernizavimo priemonių ir yra įtvirtintas naujame leidinyje „Pagrindinės Rusijos Federacijos Vyriausybės veiklos kryptys laikotarpiui iki 2018 m.“, Kurį pasirašė Ministras Pirmininkas. Ministras Dmitrijus Medvedevas.