Ais projektijuhtimine. AIS “Projektijuhtimine. AIS -i disaini põhimõisted

AIS -i arendamiseks on palju meetodeid ja võimalusi, mille kasutamine sõltub erinevatest teguritest, näiteks ettevõtete suurusest ja (või) nende IS -ist, IS -i loomise eesmärgist, olemasolevatest ressurssidest jne. IS on arutatud eelnevates peatükkides.

Tarkvaraprojekti elutsükkel on tarkvaraarenduse etappide ja etappide kogum, alates süsteemi analüüsist ja esialgsete nõuete väljatöötamisest kuni selle installimiseni (installimiseni) arvutisse.

Kogemused erinevate AIS -klasside väljatöötamisel ja rakendamisel on näidanud nende rakendamise kõrget tõhusust (sealhulgas majanduslikku), eriti suurtes ettevõtetes. See väljendub töö- ja tootmise heas korralduses, püstitatud ülesannete kavandamise ja elluviimise täpsuse suurendamises, ettevõtte rütmi tagamises, füüsilise töö osakaalu vähendamises, tõhusas (sh operatiivses) teabetoes erinevate kasutajate kategooriate jaoks, jne. Selliste süsteemide keskmine tasuvusaeg ei ületa tavaliselt kahte aastat.

IS -i väljatöötamisel eelistatakse enamikul juhtudel standardseid disainilahendusi, mis on kohandatud vastavalt kliendi konkreetsetele tingimustele ja võimalustele. Üksikuid projekte arendatakse standardlahenduste puudumisel või kui organisatsiooni põhiparameetrid erinevad oluliselt (rohkem kui 10-15%) standardlahendustest. See kehtib tavaliselt suurte ja suuremate organisatsioonide kohta.

Ükski IC arendusskeem pole absoluutne. Võimalikud on erinevad variandid, mis sõltuvad näiteks arendamise esialgsetest tingimustest: töötatakse välja täiesti uus süsteem; ettevõte on juba läbi viidud ja ettevõtte tegevusmudel on olemas; ettevõttel on juba olemas IS, mida saab kasutada esialgse prototüübina või integreerida arendatavaga.

AIS -projekti üksikasjalik väljatöötamine eeldab täieliku organisatsioonilise, projekteerimis-, tehnoloogilise ja tegevusdokumentatsiooni olemasolu.

Iga objekti kujundamine toimub järgmiselt:

• a) selle funktsionaalse eesmärgi kindlaksmääramine (miks seda vaja on, mida ja kuidas kavandatud objekt teeb),
• b) loogiliste seoste tuvastamine (kuidas kavandatud objekt täidab oma funktsionaalset eesmärki, millist teavet töödeldakse ja millises järjestuses),
• c) kavandatud objekti elluviimiseks vajalike materiaalsete vahendite valik - funktsionaalne, tehnoloogiline ja tehniline aspekt (meedia, andmetöötlusvahendid jne),
• d) materiaalsete müügivahendite ruumiline (territoriaalne) paigutamine eraldatud või võimalikuks kasutamiseks mõeldud aladele,
• e) kavandatud objekti organisatsioonilise ja juhtimisstruktuuri kujundamine (osakondade koosseis, volitused ja funktsionaalsed kohustused töötajad)

Pärast AIS -i kujundusmeetodi valimist on vaja kavandada tööde komplekt süsteemi loomiseks vastavalt selle tüüpilistele arenguetappidele. Projekti vaatab läbi ja kinnitab tellija. AIS -i disain hõlmab teatud etappide ja etappide rakendamist.

Projekti edukaks elluviimiseks on vaja kehtestada tõelised verstapostid, millel on selgelt märgitud algus ja lõpp. Üksikasjaliku tööplaani väljatöötamine on seotud protsesside ja nende järjepidevuse kirjeldamisega igas etapis, vajalike spetsialistide, vahendite ja vahenditega. Selline lähenemine aitab suuremal määral vältida tegematajätmisi ja vigu. See on vajalik töötajatele, kes rakendavad automatiseerimisprojekti, ning avaldab positiivset mõju ka seda rahastavatele isikutele.

Projekteerimistööde järkjärguline rakendamine on seotud vajadusega koostada nende rakendamise ajakava, sealhulgas ressursid ja nende rakendamise ajastus (etapid) (vt varasemad ajakavad ja joonised). Ressursid hõlmavad vajalikku personali, riistvara, tarkvara, rahastamist ja infrastruktuuri. Samal ajal on parem seda rahastada iga tööliigi jaoks eraldi (raha ja tarkvara ostmine, installimine, koolitus, eraldi projekteerimisetapid jne).

Automatiseerimiseks erinevad tüübid tegevused (juhtimine, projekteerimine, uurimistöö jne), sealhulgas nende kombinatsioonid, kasutavad GOST 34.601-90 sätteid. See näeb ette kavandamise järgmised etapid ja etapid (tabel 1).

tabel 2

Standard ütleb ka järgmist:

• · Aafrika Liidu loomisel osalevate organisatsioonide etapid ja etapid on sätestatud käesoleval standardil põhinevates lepingutes ja lähteülesannetes.
• · Kõigil etappidel on lubatud välistada etapp „Eskiisprojekt” ja eraldi tööetapid, ühendada „Tehniline disain” ja „Töödokumentatsioon” üheks etapiks „Tehniline tööprojekt”. Sõltuvalt loodavate tuumaelektrijaamade eripärast ja nende loomise tingimustest on lubatud teha üksikuid tööetappe enne eelmiste etappide lõppu, paralleelselt tööetappide ajalises täitmises, uute tööetappide kaasamises.

Tehniline projekt (eelprojekt) sisaldab arendusobjekti ja selle komponentide lülitusskeeme ja projekteerimisdokumentatsiooni, valitud valmis tarkvara tööriistade loendit ja tehniline abi(sh arvutitüübid, operatsioonisüsteemid, rakendusprogrammid jne), algoritmid probleemide lahendamiseks uute tarkvaravahendite väljatöötamisel).

Detailne projekteerimine - projekteerimise viimane etapp, mis näeb üldiselt ette eelmiste etappide tulemuste selgitamist ja üksikasjalikku kirjeldamist, automaatikaobjekti prototüübi loomist ja katsetamist, tarkvaratoodete, tehnoloogilise ja operatiivdokumentatsiooni väljatöötamist ja katsetamist.

Kaasaegses automatiseeritud infosüsteemide (näiteks AIPS, ASNTI, ACS jne) kavandamise praktikas võib see olla nende rakendamise esialgne etapp projekti kliendi organisatsiooni või teenuse töös. üks paljudest teistest automatiseeritud organisatsioonidest, teenustest jne.

Süsteemi disaini üksikasjalik väljatöötamine eeldab täieliku organisatsioonilise, projekteerimis-, tehnoloogilise ja operatiivdokumentatsiooni olemasolu.

Osariigi standard GOST 19.102-77 kehtestab tarkvaradokumentatsiooni väljatöötamise järgmised etapid:

• 1. Lähteülesanne;
• 2. Eskiisprojekt;
• 3. Tehniline disain;
• 4. Töö eelnõu;
• 5. Rakendamine.

Pange tähele, et väikeste projektide puhul saab etappide arvu vähendada.

Esimese etapi "Nõudete kujundamine AU -le" rakendamise raames uuritakse objekti ja põhjendatakse AIS -i loomise vajadust, võttes arvesse kasutaja nõudeid projekteeritud AIS -ile. Need projekteerimise esimese etapi protseduurid on osa projektieelsest uuringust. See võib hõlmata ka projekteerimise teise etapi protseduure - „Tuumaelektrijaama kontseptsiooni väljatöötamine”.

Projekteerimiseelsete uuringute käigus viiakse läbi teostatavusuuring AIS-i loomise otstarbekuse kohta; üldiste nõuete väljatöötamine AIS -i arendamiseks.

Projekteerimiseelsete uuringute käigus vajalike projekteerimistööde tegemiseks tehakse kindlaks järgmised:

• · materiaalseid ressursse,
• · rahalised vahendid,
• · inimressursid,
• · Ajutised vahendid.

Praegu on iga organisatsiooni käsutuses teatud materiaalne ressurss, mis on reeglina heterogeenne. Nende ressursside ohutuse tagamiseks on vaja pidada arvestust ja määrata vastutavad isikud. Sellele probleemile saab lahenduse leida erinevate rakenduste abil, näiteks 1C: Enterprise, AVARD ja paljud teised. Kuid need programmid on nii ostmisel kui ka hooldamisel väga kallid. Nõuda personali eriharidust ja väljaõpet.

Disaini all peaks mõistma kavandatava või võimaliku objekti prototüübi loomise protsessi.

Kaasaegne tehnoloogia AIS -i loomiseks on kombinatsioon tõhusatest projekteerimisvahenditest ja -meetoditest, mis lihtsustavad seda protsessi, vähendavad kulusid, lühendavad süsteemi kavandamise kalendriaega ja parandavad arenduskvaliteeti tänu laiale valikule tõestatud täiustatud disainilahendustele.

Peamise juurde disainivahendeid võib omistada:

Tüüpilised disainilahendused (TPD) ja rakenduspaketid (PPP). TPR - algoritmiliste ja tarkvaraelementide kogum, mis tagab ülesannete täitmise arvutis sobivate tehniliste vahendite abil;

Arvutipõhised projekteerimissüsteemid (CAD), mis hõlmavad arvutite kasutamist AIS-i loomise kõikides etappides.

Üldnõuded projekteerimisvahenditele:

Kogu AIS -i loomise protsessi täielik katvus;

Ühilduvus, s.t. järjepidevus nii süsteemi loomise kui ka selle toimimise protsessis;

Mitmekülgsus, s.t. võimalus kasutada samu tööriistu erinevate objektide jaoks;

Juurdepääsetavus arendamisel ja lihtsus (lihtsus) rakendamisel;

Võimalus korraldada projekteerimisprotsess süsteemi arendaja, disaineri ja arvuti interaktiivse suhtluse režiimis;

Kohanemisvõime ja kulutõhusus.

Nende hulgas disainimeetodid eraldama:

Originaalne disain;

Tüüpiline disain ja selle tüübid: elementaarne, alamsüsteem, modulaarne, rühm;

Arvutipõhine disain.

Algne disainimeetod on traditsiooniline ja keskendub ühele konkreetsele ettevõttele. Iseloomulik tunnus See meetod on objekti kontrollimise originaalsete meetodite väljatöötamine ja vajaliku dokumentatsiooni loomine individuaalse projekti kujul. Selle meetodi eeliseks on automaatikaobjekti eripärade kajastamine AIS -projektis. Puuduste hulka kuuluvad suhteliselt kõrge töömahukus ja pikk arendusaeg, madal funktsionaalse töökindluse ja muutuvate tingimustega kohanemisvõime näitaja. Algse meetodiga loodud projekte saab aga moderniseerida aastal puhas vorm seda meetodit kasutatakse harva. Tänapäeval kasutatakse selle rakendamise ajal erinevaid projekteerimisvahendeid ja ainult teatud projekti osad nõuavad originaalseid disainilahendusi. See tasandab mõnevõrra selle puudused. See meetod jääb aga oluliseks keeruliste, erakordsete objektide automatiseerimisel.

V kaasaegsed tingimused AIS -i ei ehitata tavaliselt nullist. Praegu töötavad majanduses, peaaegu kõigil juhtimistasanditel ja kõikidel majandusüksustel automatiseeritud infotöötlussüsteemid. Suurenenud vajadus õigeaegse, kvaliteetse ja operatiivse teabe järele nõuab uue tehnilise ja tehnoloogilise aluse loomist.

Mõistlike kujundusviiside otsimine toimub järgmistes suundades:

1. rakendustarkvarapakettides (PPP) rakendatavate standardsete disainilahenduste väljatöötamine majanduslike probleemide lahendamiseks, millele järgneb PPP sidumine rakendamise ja toimimise eritingimustega;

2. automatiseeritud projekteerimissüsteemide väljatöötamine.

Esimene võimalus on rakendusprogrammide pakettides sisalduvate standardsete disainilahenduste kasutamine.

Tüüpiline disain- tööstuslik meetod AIS -i loomiseks, kasutades TPR -i ja RFP -d. Seda meetodit iseloomustavad tõestatud, standardsed organisatsioonilised ja majanduslikud, tehnilised, informatiivsed, matemaatilised ja tarkvara juhtimise automatiseerimise tööriistad. Selle meetodi rakendamine võimaldab vähendada töömahukust, vähendada kulusid ja lühendada projekteerimisaega ning parandada disaini kvaliteeti. Tüüpiline projekteerimisprotsess seisneb toetavate alamsüsteemide valimises ja sidumises vastavalt konkreetse AIS -i nõuetele. AIS -i tüüpiline osa on teabe, tarkvara ja riistvara kompleks. Teabetoetuse tüüpiline olemus saavutatakse rangelt järgides infobaasi struktuuri ühtsust, massiivide koostist, sisend- ja väljunddokumentide vorme. Tarkvara tüüpiline olemus saavutatakse PPP abil ja tehnilise toe tüüpiline olemus saavutatakse sama või kombineeritud tüüpi arvutite abil.

1. Tüüpilise projekteerimismeetodi variatsioon on meetod elementaarne disain, mis põhineb TPR -il. Projekti väljatöötamisel kasutatakse väikeste muudatustega valmislahendust ja uut ei arendata.

2. Kasutades modulaarne meetod TPR luuakse modulaarselt, kui iga disainilahendus on jagatud eraldi komponentideks - mooduliteks, mis rakendavad teatud TPR -i osa. See võimaldab teil luua uue automatiseeritud süsteemi projekti, kombineerides üksikuid standardmooduleid.

3. Kasutades allsüsteemi projekteerimise meetod iga alamsüsteemi jaoks luuakse lahendusprojektid ja rakenduspaketid - kogu süsteemi hõlmavad ja funktsionaalsed. Allsüsteemide eraldamine sõltub majandus- ja tootmisprotsessi objektist. Iga alamsüsteemi jaoks töötatakse välja oma automaatne projekteerimislahendus ja PPP, mis võivad olla kogu süsteemi hõlmavad või funktsionaalsed. Süsteemi hõlmavad avaliku ja erasektori partnerlused hõlmavad andmehalduse ja avaliku sektori avaliku ja erasektori partnerlusi, standardseid andmetöötlusprotseduure, matemaatilise statistika ja diskreetse programmeerimise meetodeid jne. Funktsionaalsed avaliku ja erasektori partnerlused hõlmavad pakette, mis on suunatud tööstusettevõtetele, kelle tootmine on diskreetne või pidev, mittetööstuslikus valdkonnas, ja valdkondlik juhtimine.

RFP oluline nõue on ühilduvus, sest AIS -i kavandamisel on soovitatav kasutada mitut paketti korraga. PPP -d kasutavate süsteemide disain on tegelikult taandatud teatud parameetrite järgi valitud pakettide sidumisele automaatikaobjekti konkreetsete tingimustega. Positiivsed omadused Seda lähenemisviisi disainile võib nimetada: vähem töömahukat protsessi, projekteerimisaja lühendamist võrreldes esialgse disainiga, täiustatud andmetöötlusmeetodite rakendamist, projekti dokumentatsiooni lihtsustamist (kuna kasutatakse pakettdokumentatsiooni), kavandatud AIS-i suuremat töökindlust.

4. Lisaks on olemas rühma kujundamise meetod... Selle olemus seisneb sama tüüpi objektide rühma eelmises valikus omaduste poolest. Nende seast valitakse välja baasobjekt, mille jaoks projekti arendatakse, ning saab kasutada erinevaid meetodeid ja projekteerimismeetodeid. Siin on peamine tagada projekti kõrge kohanemisvõime. Selle meetodi peamine rakendusala on mittetööstuslikud rajatised (näiteks laod).

Järgmised tegevused sobivad kõige tõhusamalt automatiseerimiseks:

1. raamatupidamine, sealhulgas juhtimine ja rahandus. Kõige rohkem RFP -sid on loodud raamatupidamise eesmärgil. Nende hulgas on "1C: raamatupidamine", "Turbo-raamatupidaja", "Info-raamatupidaja", "Parus", "ABACUS", "Bambi +" jne;

2. Abi- ja infoteenus majanduslik tegevus... Esindatud järgmise PPP -ga: "GARANT" (maksud, raamatupidamine, audit, ettevõtlus, pangandus, valuuta reguleerimine, tollikontroll); "CONSULBTANT +" (maksud, raamatupidamine, audit, ettevõtlus, pangandus, valuuta reguleerimine, tollikontroll).

3.ökonoomiline ja finantstegevus... Esindaja on järgmine RFP:

a) "Ettevõtte, organisatsiooni majandusanalüüs ja prognoos" (ettevõte "INEK"), mis täidab järgmisi funktsioone: majanduslik analüüs ettevõtte, ettevõtte tegevus; äriplaanide koostamine; teostatavusuuring laenu tagasimaksmiseks; tegevuste valikute analüüs ja valik; tasakaalu, rahavoogude ja valmistoodete prognoos.

b) Korporatsiooni Galaktika (JSC Novy Atlant) täisautomaatika mitme kasutaja võrgukompleks, mis hõlmab planeerimist, operatiivjuhtimist, raamatupidamist ja kontrolli, analüüsi, lisaks võimaldab DSS-i raames tagada äriplaneerimise lahenduse probleeme PPP projektieksperdi kasutamisel.

4. juhataja töö korraldamine;

5. dokumentide ringluse automatiseerimine;

6. koolitus.

Hiljuti eelistavad ettevõtted ja ettevõtted osta valmispakette ja tehnoloogiaid ning vajadusel lisada neile oma tarkvara, kuna nende enda AIS-i arendamine on seotud suurte kulude ja riskidega. Reeglina töötatakse välja ja pakutakse välja põhisüsteem, mida kohandatakse vastavalt üksikute klientide soovidele. Samal ajal pakutakse kasutajatele konsultatsioone, mis aitavad minimeerida süsteemide ja tehnoloogiate kasutuselevõtmise aega, kasutada neid kõige tõhusamal viisil ja tõsta personali kvalifikatsiooni.

Arvutipõhised projekteerimissüsteemid - teine ​​kiiresti arenev viis projekteerimistööde läbiviimiseks.

Arvutipõhiste projekteerimismeetodite hulgas on mudeli kujundamise meetoditel eriline koht. CAD -süsteemide loomine ja kasutamine tagab piisavalt kõrge funktsionaalse töökindluse, kõikide tehnoloogiliste protsesside igakülgse katvuse, projekteerimistööde töömahu vähendamise, arvestades maksimaalselt automatiseerimisobjekti huve. See meetod on aga üsna kallis ja nõuab kõrgelt kvalifitseeritud arendajaid. CAD -i põhinõue on oskus konstrueerida ja säilitada projekteerimissüsteemis piisavas olekus automaatikaobjekti teatud globaalse majandusinfo mudel. Mudel on automaatobjekti teabekomponentide ja nendevaheliste suhete selgesõnaline kuvamine. Mudeli koostamise peamine eesmärk on luua sellele mudelile vastav AIS -projekt, võttes arvesse ja aktiivselt kasutades kõiki objekti omadusi. Selline mudel peaks sisaldama vormistatud kujul teabekomponentide kogumite ja nendevaheliste suhete kirjeldust, sealhulgas teabelinke ja algoritmilist koostoimet. Kasutades mudeli kujundamise meetodit, süsteemne lähenemine, mis määrab arvutite kasutamise mitte ainult süsteemi loomise kõikides etappides, vaid ka selle tööstusliku töö tulemuste analüüsimisel. CAD -i väljatöötamine ja rakendamine määras kindlaks ülemineku loomisele üksikud projektid, kuid oluliselt kõrgemal tasemel kui esialgne disainimeetod.

Viimase kümnendi jooksul on IC ja IT disaini automatiseerimise valdkonnas ilmnenud uus suund - CASE arvutipõhine tarkvaraarendustehnoloogia(CASE - arvutipõhine tarkvara / süsteemitehnoloogia). Infosüsteemide üha keerukamaks muutumine ja neile esitatavad nõuded on tekitanud vajaduse nende loomiseks vajalike tehnoloogiate industrialiseerimise järele.

CASE tehnoloogia on IS -i analüüsimise, projekteerimise, arendamise ja hooldamise meetodite kogum, mida toetavad omavahel ühendatud automatiseerimisvahendid. CASE on tööriistakomplekt süsteemianalüütikutele, arendajatele ja programmeerijatele, mis automatiseerib IC -de kavandamise ja arendamise protsessi. CASE süsteeme kasutatakse võimsa vahendina uurimis- ja projekteerimisprobleemide lahendamiseks, nagu ainevaldkonna struktuurianalüüs, projekti elluviimine viimase põlvkonna programmeerimiskeelte abil, projektdokumentatsiooni avaldamine, projekti elluviimise testimine, arengute kavandamine ja kontroll, modelleerimine ärirakendused, et lahendada tegevusprobleeme. ning strateegiline planeerimine ja ressursside haldamine jne.

CASE peamine eesmärk on süsteemide arendamise ja toimimise automatiseerimine nii palju kui võimalik.

CASE-tehnoloogiate kasutamisel muutub töötehnoloogia automatiseeritud süsteemide elutsükli kõigil etappidel. CASE-süsteemides põhineb disain visuaalsetel visuaalsetel arendusmeetoditel, graafikuid, diagramme, tabeleid, diagramme ja tekstilisi selgitusi neile kasutatakse kavandatud IS mudeli kirjeldamiseks. Sellised metoodikad kirjeldavad kavandatavat süsteemi rangelt ja kirjeldavalt, mis algab süsteemi ülevaatest ja läheb seejärel üksikasjalikumaks, muutudes järjest suureneva tasemega hierarhiliseks struktuuriks.

Programmeerimise automatiseerimine põhineb programmikoodide automaatsel genereerimisel, mis sisaldavad andmete kirjeldusi, nende töötlemise põhiloogikat, andmebaasiskeeme, liidese kirjeldusfaile jne. Koode täiendatakse ja täpsustatakse, kuid mõnel juhul ulatub automatiseerimine 90%-ni. Lisaks genereerib CASE tehnoloogia vajaliku projekti dokumentatsiooni kasutamiseks valmis.

Kasutades CASE-tehnoloogiat, pakutakse ühe projektibaasi tuge, s.t. kogu teave väljatöötatud AIS -i kohta paigutatakse automaatselt ühte projekti andmebaasi. See säilitab disainiandmete järjepidevuse, järjepidevuse, täielikkuse ja minimaalse ülearuse.

CASE-tehnoloogia pakub arendusmeeskondade meeskonnatööd, sest erinevatele spetsialistide rühmadele on tagatud piisavad tööriistad ning võimalus erinevate spetsialistide poolt reaalajas projekti järjekindlalt ja õigesti muuta.

CASE -tehnoloogiaid kasutatakse edukalt peaaegu igat tüüpi AIS -i ehitamiseks. CASE -d kasutatakse ka süsteemimudelite loomiseks, mis aitavad kommertsstruktuuridel lahendada strateegilise planeerimise, finantsjuhtimise, kindla poliitika kindlaksmääramise, personali koolituse jms probleeme.

CASE -l on järgmised peamised eelised:

Parandada loodud IS (IT) kvaliteeti automaatjuhtimise (esiteks projektijuhtimise) abil;

Luba lühikese aja jooksul luua tulevase IS -i (IT) prototüüp, mis võimaldab kiiresti, varases staadiumis hinnata oodatud tulemust;

Kiirendada süsteemi projekteerimis- ja arendusprotsessi;

Vabastage arendaja rutiinsest tööst, võimaldades tal keskenduda täielikult disaini loomingulisele osale;

Need toetavad juba toimiva IS arendamist ja säilitamist.

Praeguseks on tekkinud võimas CASE-tööstus, mis koondab sadu erineva suunitlusega ettevõtteid ja ettevõtteid. Nende hulgas paistavad silma:

Ettevõtted-IP ja IT analüüsi ja disaini tööriistade arendajad

Ettevõtted-spetsiaalsete tööriistade arendajad, kes keskenduvad kitsastele valdkondadele või IP elutsükli üksikutel etappidel;

Koolitusfirmad, kes korraldavad seminare ja koolitusi spetsialistidele;

Konsultatsioonifirmad, kes pakuvad praktilist abi CASE -pakettide kasutamisel konkreetsete IS -ide väljatöötamiseks;

Ettevõtted, mis on spetsialiseerunud perioodiliste väljaannete ja bülletäänide avaldamisele CASE tehnoloogiate kohta.

Nbsp; AIS -i elutsükli mudelid

AIS -i elutsükli mudel on struktuur, mis kirjeldab teostatavaid protsesse, toiminguid ja ülesandeid ning arendus-, toimimis- ja hoolduskäiku kogu süsteemi olelusringi vältel.

Elutsükli mudeli valik sõltub projekti eripärast, ulatusest, keerukusest ning tingimuste kogumist, milles AIS luuakse ja töötab.

AIS -i elutsükli mudel sisaldab järgmist:

Töötulemused igal etapil;

Põhisündmused või lõpuleviimise ja otsuste tegemise kohad.

Vastavalt tarkvara elutsükli tuntud mudelitele määratakse kindlaks AIS -i elutsükli mudelid - kaskaad, korduv, spiraal.

I. Joa mudel kirjeldab klassikalist lähenemist süsteemide arendamisele mis tahes teemavaldkonnas; kasutati laialdaselt 1970ndatel ja 1980ndatel.

Kose mudel näeb ette tööde järjestikuse korraldamise ning mudeli põhijooneks on kogu töö jagamine etappideks. Üleminek eelmiselt etapilt järgmisele toimub alles pärast eelmise töö kõigi tööde lõpetamist.

Eraldage viis stabiilsed arenguetapid, praktiliselt sõltumatud teemavaldkonnast (joonis 1.1).

Peal esimene Selles etapis viiakse läbi probleempiirkonna uuring, sõnastatakse kliendi nõuded. Selle etapi tulemuseks on kõigi huvitatud pooltega kokku lepitud lähteülesanne (arendusülesanne).

Ajal teine etapis, vastavalt tehnilise ülesande nõuetele töötatakse välja teatud disainilahendused. Selle tulemusena kuvatakse projektidokumentide komplekt.

Kolmandaks etapp - projekti elluviimine; sisuliselt tarkvaraarendus (kodeerimine) vastavalt eelmise etapi projekteerimisotsustele. Sel juhul ei ole rakendusmeetoditel põhimõttelist tähtsust. Selle etapi tulemus on valmis tarkvaratoode.

Peal neljas Selles etapis kontrollitakse vastuvõetud tarkvara vastavust lähteülesandes sätestatud nõuetele. Proovitoiming võimaldab teil tuvastada mitmesuguseid varjatud vigu, mis ilmnevad AIS -i tegelikes tingimustes.

Viimane etapp on alistumine valmis projekt, ja peamine on siin veenda klienti, et kõik tema nõuded on täielikult täidetud.

Joonis 1.1 Joa AIS elutsükli mudel

Kose mudeli raames tehtavaid tööetappe nimetatakse sageli AIS -i projektitsükli osadeks, kuna etapid koosnevad paljudest korduvatest protseduuridest süsteeminõuete ja projekteerimisvõimaluste selgitamiseks. AIS -i elutsükkel on palju keerulisem ja pikem: see võib sisaldada suvalist arvu selgitamistsükleid, muudatusi ja täiendusi juba vastuvõetud ja rakendatud disainilahendustes. Nendes tsüklites toimub AIS -i arendamine ja selle üksikute komponentide moderniseerimine.

Kaskaadmudeli eelised:

1) igal etapil moodustatakse täielik dokumentatsioon, mis vastab täielikkuse ja järjepidevuse kriteeriumidele. Viimases etapis töötatakse välja kasutaja dokumentatsioon, mis hõlmab igat tüüpi standardites pakutavat AIS -i tuge (organisatsiooniline, informatiivne, tarkvara, tehniline jne);

2) tööetappide järjestikune rakendamine võimaldab planeerida valmimise ajastust ja vastavaid kulusid.

Kose mudel on algselt välja töötatud mitmesuguste inseneriprobleemide lahendamiseks ja pole siiani kaotanud oma tähtsust rakendusliku valdkonna jaoks. Lisaks on juga lähenemine ideaalne AIS -i arendamiseks, kuna juba arendamise alguses on võimalik kõik nõuded piisava täpsusega sõnastada, et pakkuda arendajatele tehnilise teostuse vabadust. Sellised AIS-id hõlmavad eelkõige keerukaid arveldussüsteeme ja reaalajasüsteeme.

Kose mudeli puudused:

Märkimisväärne viivitus tulemuste saamisel;

Vead ja puudused ilmnevad reeglina järgmistes tööetappides, mis toob kaasa vajaduse naasta;

Projektiga paralleelselt tehtava töö keerukus;

Teabe liigne üleküllastumine iga etapi kohta;

Projektijuhtimise keerukus;

Kõrge riskitase ja ebausaldusväärsed investeeringud.

Tulemuste saamine viibib avaldub selles, et järjepidev lähenemine huvirühmadega tulemuste kokkuleppe väljatöötamisele viiakse ellu alles pärast järgmise tööetapi lõpetamist. Selle tulemusena võib selguda, et väljatöötatud AIS ei vasta nõuetele ja sellised vastuolud võivad tekkida igal arenguetapil; Lisaks võivad nii analüütilised disainerid kui ka programmeerijad tahtmatult vigu sisse viia, kuna nad ei pea olema hästi kursis valdkondadega, mille jaoks AIS -i arendatakse.

Naaske varasematesse etappidesse. See puudus on üks eelmise ilmingutest: samm-sammult järjestikune töö projekti kallal võib viia asjaolu, et varasemates etappides tehtud vead avastatakse alles järgnevatel etappidel. Selle tulemusena viiakse projekt tagasi eelmisesse etappi, töödeldakse ümber ja alles seejärel viiakse see järgmisesse töösse. See võib põhjustada ajakava häireid ja raskendada suhteid üksikute etappide läbiviivate arendusrühmade vahel.

Halvim variant on see, kui eelmise etapi puudused avastatakse mitte järgmisel etapil, vaid hiljem. Näiteks proovitöö etapis võivad ilmneda vead ainevaldkonna kirjelduses. See tähendab, et osa projektist tuleb tagasi viia töö algfaasi.

Paralleelse töö keerukus seotud vajadusega kooskõlastada projekti erinevaid osi Mida tugevam on üksikute projekti osade suhe, seda sagedamini ja põhjalikumalt tuleks sünkroonida, seda rohkem sõltuvad arendusmeeskonnad üksteisest. Selle tulemusel kaovad paralleeltöö eelised lihtsalt ära; paralleelsuse puudumine mõjutab negatiivselt kogu meeskonna töökorraldust.

Probleem teabe üleküllastumine tuleneb tugevast sõltuvusest erinevate arengugruppide vahel. Fakt on see, et projekti ühes osas muudatusi tehes on vaja teavitada neid arendajaid, kes seda oma töös kasutasid (võisid kasutada). Suure hulga omavahel ühendatud alamsüsteemide puhul muutub sisemise dokumentatsiooni sünkroonimine omaette kriitiliseks ülesandeks: arendajad peavad pidevalt muudatustega tutvuma ja hindama, kuidas need muudatused mõjutavad saadud tulemusi.

Projektijuhtimise keerukus peamiselt arenguetappide range järjestuse ja projekti erinevate osade vaheliste keeruliste suhete tõttu. Reguleeritud tööjärjestus toob kaasa asjaolu, et mõned arendusmeeskonnad peavad ootama teiste meeskondade töö tulemusi, seetõttu on administratiivse sekkumisega nõutav, et kokku leppida esitatud dokumentatsiooni ajastus ja koosseis.

Kui töös avastatakse vigu, on vaja naasta eelmistesse etappidesse; vea tegijate praegune töö katkeb. Selle tagajärjeks on tavaliselt viivitus nii parandatud kui ka uue projekti valmimisel.

Võimalik on lihtsustada arendajate omavahelist suhtlemist ja vähendada dokumentide ülekoormust, vähendades ühenduste arvu projekti üksikute osade vahel, kuid mitte kõiki AIS -e ei saa jagada lõdvalt seotud alamsüsteemideks.

Kõrge riskitase. Mida keerulisem on projekt, seda kauem kulub iga arenguetapp ja seda keerukamad on seosed projekti üksikute osade vahel, mille arv ka suureneb. Pealegi saab arendustulemusi tõepoolest näha ja hinnata alles katsetamisetapis, s.o pärast analüüsi, projekteerimise ja arendamise etappide lõpuleviimist, mille rakendamine nõuab märkimisväärselt aega ja raha.

Hiline hindamine tekitab tõsiseid probleeme vigade tuvastamisel analüüsimisel ja projekteerimisel - peate minema tagasi eelmistesse etappidesse ja korrata arendusprotsessi. Eelmistesse etappidesse naasmist võib aga seostada mitte ainult vigadega, vaid ka muutustega, mis on toimunud teemavaldkonnas või kliendi nõuetes arendamise käigus. Samas ei garanteeri keegi, et projekti järgmine versioon valmides ei muutuks teema uuesti. Tegelikult tähendab see, et on tõenäoline arendusprotsessi "loopimine": projekti kulud kasvavad pidevalt ja valmistoote kohaletoimetamise tähtajad lükkuvad pidevalt edasi.

II. Iteratiivne mudel koosneb planeerimise, elluviimise, uurimise, tegevuse lühikeste tsüklite (sammude) seeriast.

Kompleksse AIS -i loomine hõlmab üksikute ülesannete täitmisel saadud disainilahenduste heakskiitmist. Alt üles projekteerimise lähenemisviis nõuab selliseid tagastuste kordusi, kui üksikute ülesannete kujunduslahendused ühendatakse ühisteks süsteemseks. Samal ajal on vaja läbi vaadata varem moodustatud nõuded.

Eelis iteratiivne mudel seisneb selles, et etappidevahelised kohandused pakuvad võrreldes kose mudeliga vähem töömahukat arengut.

puudused iteratiivne mudel:

· Iga etapi eluiga pikeneb kogu tööperioodi vältel;

· Suure hulga iteratsioonide tõttu esineb disainilahenduste ja dokumentatsiooni rakendamisel vastuolusid;

· Arhitektuuri keerukus;

· Rakendusdokumentatsiooni kasutamise raskused rakendamise ja kasutamise etappidel nõuavad kogu süsteemi ümberkujundamist.

III. Spiraalne mudel, erinevalt kaskaadist, kuid sarnane eelmisega, hõlmab see iteratiivset AIS -i arendamise protsessi. Samal ajal suureneb esialgsete etappide, näiteks analüüsi ja projekteerimise tähtsus, mille käigus kontrollitakse tehniliste lahenduste teostatavust ja põhjendatakse seda prototüüpide loomisega.

Iga iteratsioon kujutab endast täielikku arendustsüklit, mille tulemuseks on toote sise- või välisversiooni (või lõpptoote alamhulga) vabastamine, mis paraneb iteratsioonist iteratsioonini, et saada terviklikuks süsteemiks (joonis 1.2).

Riis. 1.2. Elutsükli spiraalmudel AIS

Seega vastab iga spiraali pööre tarkvaratoote fragmendi või versiooni loomisele, sellel selgitatakse projekti eesmärke ja omadusi, määratakse selle kvaliteet, kavandatakse tööd järgmiseks spiraali pöördeks. Iga kordamine süvendab ja järjekindlalt täpsustab projekti üksikasju, mille tulemusel valitakse mõistlik variant lõplikuks teostuseks.

Spiraalmudeli kasutamine võimaldab teil liikuda projekti järgmisse etappi, ootamata praeguse lõpuleviimist - lõpetamata tööd saab lõpetada järgmisel iteratsioonil. peamine ülesanne iga kordus - looge võimalikult kiiresti toimiv toode, mida kasutajatele tutvustada. Seega on projektis muudatuste ja täienduste tegemise protsess oluliselt lihtsustatud.

Spiraalne lähenemine tarkvaraarendusele ületab enamiku kose mudeli puudustest, lisaks pakub see mitmeid lisavõimalusi, muutes arendusprotsessi paindlikumaks.

Eelised iteratiivne lähenemine:

Iteratiivne arendamine lihtsustab oluliselt projekti muutmist, kui kliendi nõuded muutuvad;

Spiraalmudeli kasutamisel integreeritakse AIS -i üksikud elemendid järk -järgult ühtseks tervikuks. Kuna integratsioon algab vähemate elementidega, on selle rakendamisel palju vähem probleeme;

Riskide taseme vähendamine (eelmise eelise tagajärg, kuna riske avastatakse täpselt integratsiooni käigus). Riskide tase on projekti arendamise alguses maksimaalne, arenduse edenedes see väheneb;

Iteratiivne arendus pakub projektijuhtimisel suuremat paindlikkust, võimaldades arendatava toote taktikalisi muudatusi. Seega saate arendusaega lühendada, vähendades süsteemi funktsionaalsust või kasutada seda sellisena komponendid kolmandate osapoolte ettevõtete tooted oma arendustegevuse asemel (asjakohane turumajanduses, kui on vaja konkurentide toodete reklaamimisele vastu seista);

Korduv lähenemisviis muudab komponentide korduvkasutamise lihtsamaks, sest projekti ühiseid osi on palju lihtsam tuvastada (tuvastada), kui need on juba osaliselt välja töötatud, kui proovida neid isoleerida projekti alguses. Projekti analüüs pärast mitut esialgset iteratsiooni näitab ühiseid korduvkasutatavaid komponente, mida järgnevates iteratsioonides täiustatakse;

Spiraalmudel võimaldab usaldusväärsemat ja stabiilsemat süsteemi. See on tingitud asjaolust, et süsteemi arenedes avastatakse ja parandatakse vigu ja nõrkusi igal kordamisel. Samal ajal reguleeritakse kriitilisi jõudlusparameetreid, mis kaskaadmudeli puhul on saadaval alles enne süsteemi juurutamist;

Korduv lähenemine parandab protsessi
arendus - iga iteratsiooni lõpus tehtud analüüsi tulemusena viiakse läbi arenduskorralduse muutuste hindamine; see paraneb järgmisel kordamisel.

Spiraaltsükli peamine probleem- raskus järgmisele etapile ülemineku hetke kindlaksmääramisel. Selle lahendamiseks on vaja kehtestada elutsükli iga etapi jaoks ajapiirangud. Vastasel juhul võib arendusprotsess muutuda juba tehtud lõputuks täiustamiseks.

Kasutajate kaasamine rakenduse kavandamis- ja kopeerimisprotsessi võimaldab teil otse rakenduse kujundamise käigus saada nõuetele kommentaare ja täiendusi, vähendades arendusaega. Klientide esindajad saavad võimaluse kontrollida süsteemi loomise protsessi ja mõjutada selle funktsionaalset sisu. Tulemuseks on süsteemi kasutuselevõtt, mis võtab arvesse enamikku klientide vajadusi.

Pakutakse kaasaegseid metoodikaid ja neid rakendavaid AIS -i disainitehnoloogiaid elektroonilisel kujul koos CASE-tööriistadega ja hõlmavad protsesside, mallide, meetodite, mudelite ja muude komponentide raamatukogusid, mis on ette nähtud selle klassi süsteemide tarkvara ehitamiseks, millele metoodika on suunatud. Elektroonilised metoodikad ja tehnoloogiad moodustavad kokkulepitud kogumi tuuma tööriistad AIS arendamine. Kaasaegsete AIS -i kujundamise metoodiliste lahenduste funktsioone ei saa rakendada ilma teatud projekteerimistehnoloogiateta, mis vastavad projekti ulatusele ja eripäradele.

AIS disainitehnoloogia on meetodite ja tööriistade kogum AIS -i kujundamiseks, samuti meetodid ja vahendid disaini korraldamiseks (AIS -projekti loomise ja kaasajastamise protsessi juhtimine).

TP disaini kohaselt on AIS järjestikku paralleelsete, ühendatud ja alluvate tegevusahelate kogum, millest igaühel võib olla oma teema. AIS-i projekteerimisel tehtavaid toiminguid võib määratleda kui jagamatuid tehnoloogilisi toiminguid või tehnoloogiliste toimingute alamprotsesse. Kõik toimingud võivad olla õiged disain, mis kujundavad või muudavad disainitulemusi ja hinnanguline, mis töötatakse välja vastavalt projekteerimistulemuste hindamise kehtestatud kriteeriumidele.

Seega seab projekteerimistehnoloogia kindlale meetodile tugineva projekti loomise käigus teostatud tehnoloogiliste toimingute reguleeritud jada.

Valitud projekteerimistehnoloogia teemaks peaks olema omavahel seotud projekteerimisprotsesside kajastamine AISi elutsükli kõigil etappidel.

Valitud projekteerimistehnoloogia peamised nõuded on järgmised:

· Selle tehnoloogia abil loodud projekt peab vastama kliendi nõudmistele;

· Tehnoloogia peaks võimalikult palju kajastama projekti elutsükli kõiki etappe;

· Tehnoloogia peaks tagama minimaalsed töö- ja kulud projekteerimisele ja projektitoele;

· Tehnoloogia peaks aitama kaasa disainerite tööviljakuse kasvule;

· Tehnoloogia peaks tagama projekti kavandamise ja toimimise usaldusväärsuse;

· Tehnoloogia peaks hõlbustama projekti dokumentatsiooni hõlpsat hooldamist.

AIS -i disainitehnoloogia rakendab spetsiifilist projekteerimismetoodikat. Kujundusmetoodika eeldab omakorda mõne kontseptsiooni, disainipõhimõtete olemasolu ja seda rakendatakse meetodite ja tööriistade komplektiga.

AIS -i projekteerimismeetodeid saab klassifitseerida vastavalt automatiseerimisvahendite kasutusastmele, tüüpilistele disainilahendustele, kohanemisvõimele eeldatavate muutustega.

Sõltuvalt automatiseerimise astmest eristatakse neid:

käsitsi disain, milles AIS -komponentide projekteerimine toimub ilma spetsiaalseid tarkvaratööriistu kasutamata; programmeerimine toimub algoritmilistes keeltes;

arvuti disain, kus disainilahenduste genereerimine või konfigureerimine (häälestamine) toimub spetsiaalsete tarkvaravahendite abil.

Tüüpiliste disainilahenduste kasutamise astme järgi eristatakse neid:

originaal (individuaalne) disain, kui disainilahendusi arendatakse "nullist" vastavalt AIS -i nõuetele;

tüüpiline disain, eeldades AIS-i konfiguratsiooni valmis standardsetest disainilahendustest (tarkvaramoodulitest).

Originaalne disain AIS võtab maksimaalselt arvesse automatiseeritud rajatise funktsioone.

Tüüpiline disain alusel tehtud valmislahendused ja see on üldistus varasemate seotud projektide loomisel saadud kogemustest.

Disainilahenduste kohanemisvõime astme järgi erinevad järgmised meetodid:

rekonstrueerimine- disainilahenduste kohandamine toimub vastavate komponentide töötlemise teel (tarkvaramoodulite ümberprogrammeerimine);

parameetrid- disainilahendusi kohandatakse vastavalt kindlaksmääratud ja muutuvatele parameetritele;

mudeli ümberkorraldamine- ainevaldkonna mudel muutub, mis toob kaasa disainilahenduste automaatse reformimise.

Kujundusmeetodite klassifitseerimise erinevate tunnuste kombinatsioon määrab kasutatava AIS -disainitehnoloogia olemuse. Disainitehnoloogial on kaks peamist klassi: kanooniline ja tööstuslik... Tööstusdisaini tehnoloogia on jagatud kahte alamklassi: automatiseeritud(CASE tehnoloogiate kasutamine) ja tüüpiline(parameetritele või mudelitele orienteeritud) disain.

Tabel 1.1.Disainitehnoloogia klasside tunnused

Kanooniline AIS -disain keskendub peamiselt AIS -i elutsükli jugamudeli kasutamisele.

Sõltuvalt automatiseerimisobjekti keerukusest ja konkreetse AIS -i loomisel lahendamist vajavatest ülesannete kogumist võivad tööetapid ja -etapid olla erineva töömahukusega. Projekti mis tahes etapis on lubatud kombineerida järjestikuseid etappe ja mõned neist välja jätta. Samuti on lubatud alustada järgmise etapi tööd enne eelmise etapi lõppu.

AIS -i loomise etapid ja etapid, mida viivad läbi osalevad organisatsioonid, on tööde teostamiseks ette nähtud lepingutes ja tehnilistes spetsifikatsioonides.

1. etapp. AIS -i nõuete vormistamine:

· Rajatise ülevaade ja AIS -i loomise vajaduse põhjendus;

· AIS -i kasutajanõuete kujundamine;

· Aruande koostamine tehtud töö kohta ning taktikaline ja tehniline ülesanne arendamiseks.

2. etapp. AIS -kontseptsiooni väljatöötamine:

· Automatiseerimise objekti uurimine;

· Vajaliku uurimistöö läbiviimine;

· Kasutajate nõudmistele vastavate AIS -i kontseptsiooni valikute väljatöötamine;

· Aruande koostamine ja kontseptsiooni kinnitamine.

3. etapp. Tehniline ülesanne:

AIS -i loomise tehniliste spetsifikatsioonide väljatöötamine ja kinnitamine.

4. etapp. Esialgne disain:

· Süsteemi ja selle osade eelprojekteerimislahenduste väljatöötamine;

· AIS -i ja selle osade ülddokumentatsiooni väljatöötamine.

5. etapp. Tehniline projekt:

· Süsteemi ja selle osade disainilahenduste väljatöötamine;

· AIS -i ja selle osade dokumentatsiooni väljatöötamine;

· Komponentide tarnimiseks vajaliku dokumentatsiooni väljatöötamine ja täitmine;

· Projekteerimisülesannete väljatöötamine projektiga seotud osades.

6. etapp. Töödokumentatsioon:

· AIS -i ja selle osade töödokumentatsiooni väljatöötamine;

· Programmide väljatöötamine ja kohandamine.

7. etapp. Kasutuselevõtt:

· Automatiseerimisobjekti ettevalmistamine; personali koolitus;

· AIS -i tarnitavate toodete täielik komplekt (tarkvara ja riistvara, tarkvara- ja riistvarakompleksid, teabetooted);

· Ehitus- ja paigaldustööd; tellimistööd;

· Eeltestide läbiviimine;

· Katseoperatsiooni läbiviimine;

· Vastuvõtukatsete läbiviimine.

8. etapp. AIS saatja:

· Tööde teostamine vastavalt garantiikohustustele;

· Garantiijärgne hooldus.

Uuring- uurib ja analüüsib ettevõtte organisatsioonilist struktuuri, selle tegevust ja olemasolevat süsteemi informatsiooni töötlemine.

Uuringu tulemusena saadud materjale kasutatakse:

Süsteemide väljatöötamise ja järkjärgulise rakendamise põhjendus;

Tehniliste spetsifikatsioonide koostamine süsteemide arendamiseks;

Süsteemide tehniliste ja tööprojektide väljatöötamine.

Uuringu etapis on soovitav eristada kahte komponenti: AIS -i rakendamisstrateegia määratlemine ja organisatsiooni tegevuse üksikasjalik analüüs.

Uuringu esimese etapi põhiülesanne on hinnata projekti tegelikku mahtu, selle eesmärke ja eesmärke, tuginedes kõrgetasemelise automatiseeritud objekti tuvastatud funktsioonidele ja teabeelementidele. Neid ülesandeid saab täita kas AIS -i klient iseseisvalt või konsulteerivate organisatsioonide kaasamisel. See etapp hõlmab tihedat suhtlemist süsteemi peamiste potentsiaalsete kasutajate ja äriekspertidega. Suhtlemise peamine ülesanne on saada täielik ja üheselt mõistetav teave kliendi nõudmistest. Tavaliselt saab vajaliku teabe kätte intervjuude, vestluste või töötubade kaudu juhtkonna, ekspertide ja kasutajatega.

Pärast küsitlusetapi lõppu on võimalik kindlaks teha süsteemi loomise tõenäolised tehnilised lähenemisviisid ja hinnata selle rakendamise kulusid (riistvara, ostetud tarkvara ja uue tarkvara arendamine).

Strateegia määratlemise etapi tulemuseks on dokument (teostatavusuuring - teostatavusuuring - projekt), kus on selgelt sõnastatud, mida klient saab, kui ta on nõus projekti rahastama, millal ta saab valmis toote (töögraafik) ja kuidas palju see maksab (suurte projektide puhul - see on rahastamise ajakava erinevatel tööetappidel). Soovitav on kajastada dokumendis mitte ainult kulusid, vaid ka projekti eeliseid, näiteks projekti tasuvusaeg, majanduslikku mõju(kui seda on võimalik hinnata).

Piirangud, riskid, kriitilised tegurid, mis võivad mõjutada projekti edukust;

Tingimuste kogum, mille kohaselt tulevast süsteemi kavatsetakse käitada - süsteemi arhitektuur, riist- ja tarkvararessursid, töötingimused, teeninduspersonal ja süsteemi kasutajad;

Üksikute etappide lõpuleviimise tingimused, töö vastuvõtmise / üleandmise vorm, kaasatud ressursid, meetmed teabe kaitsmiseks;

Süsteemi täidetavate funktsioonide kirjeldus;

Süsteemi arendamise ja kaasajastamise võimalused;

Liidesed ja funktsioonide jaotus inimese ja süsteemi vahel;

nõuded tarkvarale ja andmebaasihaldussüsteemidele (DBMS).

Organisatsiooni tegevuse üksikasjaliku analüüsi etapis uuritakse tegevusi, mis tagavad juhtimisfunktsioonide rakendamise, organisatsiooniline struktuur, personal ja ettevõtte juhtimisega seotud töö sisu, samuti kõrgemate juhtorganite alluvuse olemus. Siinkohal on vaja välja tuua juhendavad, metoodilised ja käskkirjalised materjalid, mille alusel määratakse kindlaks allsüsteemide koosseis ja ülesannete loetelu, samuti võimalus kasutada uusi probleemide lahendamise meetodeid.

Analüütikud koguvad ja salvestavad teavet kahel omavahel seotud kujul:

Funktsioonid - teave automatiseeritud organisatsioonis toimuvate sündmuste ja protsesside kohta;

Olemid - teave objektide klasside kohta, mis on organisatsiooni jaoks olulised ja mille kohta andmeid kogutakse.

Iga funktsionaalse juhtimisülesande uurimisel määratakse kindlaks:

Ülesande nimi; otsuse tegemise tingimused ja sagedus;

Probleemi vormistatavuse aste;

Probleemi lahendamiseks vajaliku teabe allikad;

Näitajad ja nende kvantitatiivsed omadused;

Teabe parandamise kord;

Käitusalgoritmid indikaatorite arvutamiseks ja võimalikud juhtimismeetodid;

Olemasolevad vahendid teabe kogumiseks, edastamiseks ja töötlemiseks;

Olemasolevad sidevahendid;

Probleemi lahenduse aktsepteeritud täpsus;

Probleemi lahendamise keerukus;

Olemasolevad lähteandmete esitamise vormid ja nende töötlemise tulemused dokumentide kujul;

Tarbijad saadud teabe kohta ülesande kohta.

Selle etapi üks töömahukamaid, kuigi hästi vormistatud ülesandeid on organisatsiooni töövoo kirjeldus. Töövoo uurimisel koostatakse dokumentide liikumistee skeem, mis peaks kajastama:

Dokumentide arv;

Dokumendinäitajate moodustamise koht;

Dokumentide suhe nende moodustamise ajal;

Dokumendi liikumise marsruut ja kestus;

Selle dokumendi kasutamise ja säilitamise koht;

Sisemine ja väline teabeside;

Dokumendi maht märkides.

Uuringu tulemuste põhjal koostatakse automatiseeritavate haldusülesannete loetelu I ja nende väljatöötamise järjekord.

Uuringu etapis tuleks planeeritud süsteemi funktsioonid klassifitseerida vastavalt nende tähtsusele. Üks võimalikke vorminguid sellise klassifikatsiooni esitamiseks on MuSCoW. See lühend tähistab järgmist: Must have - nõutavad funktsioonid; Peaks olema - soovitud funktsioonid; Võiks olla - I võimalikud funktsioonid; Puuduvad funktsioonid.

Esimese kategooria funktsioonid on minu jaoks kriitilised edukas töö süsteemide võimalused. Teise ja kolmanda kategooria funktsioonide rakendamist piirab ajaline ja finantsraamistik: vajalik, aga ka maksimaalne võimalik, prioriteetsuse järjekorras, teise ja kolmanda kategooria funktsioonide arv. Viimane funktsioonide kategooria on eriti oluline, kuna on vaja selgelt mõista projekti I piire ja funktsioonide komplekti, mis süsteemis puuduvad.

Organisatsiooni tegevusmudeleid on kahte tüüpi 1:

Mudel „nagu on” peegeldab organisatsioonis olemasolevaid äriprotsesse;

Mudel „olla” kajastab vajalikke muudatusi äriprotsessides, võttes arvesse AIS -i kasutuselevõttu. j

Juba analüüsi etapis on vaja kaasata testimisrühm töösse järgmiste ülesannete lahendamiseks:

Riistvaraplatvormide, operatsioonisüsteemide, DBMS -i jms võrdlevate omaduste saamine;

Tööplaani väljatöötamine AIS -i ja selle testimise usaldusväärsuse tagamiseks.

Testijate kaasamine arenduse algusesse on hea mõte iga projekti jaoks. Mida hilisemad vead disainilahendustes avastatakse, seda kallim on nende parandamine; halvim stsenaarium on nende avastamine rakendusetapis. Seega, mida varem hakkavad testimisrühmad AIS -is vigu tuvastama, seda väiksemad on süsteemi kallal töötamise kulud. Aega süsteemi testimiseks ja avastatud vigade parandamiseks tuleks anda mitte ainult arendus-, vaid ka projekteerimisetapis.

Spetsiaalsed vigade jälgimissüsteemid on loodud testimise hõlbustamiseks ja tõhususe suurendamiseks. Nende kasutamine võimaldab teil omada ühte vigade hoidlat, jälgida nende kordumist, kontrollida vigade parandamise kiirust ja tõhusust, näha kõige ebastabiilsemaid süsteemikomponente ning säilitada ka suhtlus arendusmeeskonna ja testimismeeskonna vahel.

Uuringu tulemused on objektiivne alus AIS -i tehniliste spetsifikatsioonide koostamiseks.

Tehniline ülesanne Kas dokument, mis määratleb eesmärgid, nõuded ja lähteandmed, mis on vajalikud automatiseeritud juhtimissüsteemi arendamiseks.

Tehnilise ülesande (TOR) väljatöötamisel on vaja lahendada järgmised ülesanded:

· Kehtestada AIS -i loomise üldine eesmärk;

· Kehtestada kavandatavale süsteemile üldnõuded;

· Töötada välja ja põhjendada nõudeid teabele, matemaatikale, tarkvarale, riistvarale ja tehnoloogilisele toele;

· Määrata alamsüsteemide koosseis ja funktsionaalsed ülesanded;

· Töötada välja ja põhjendada alamsüsteemidele esitatavaid nõudeid;

· Määrata kindlaks süsteemi loomise etapid ja nende rakendamise ajastus;

Tehke esialgne arvutus süsteemi loomise kulude kohta ja määrake tase majanduslikku efektiivsust rakendamine;

· Määrata esinejate koosseis.

Tüüpilised nõuded tehnilise ülesande koostisele ja sisule on toodud tabelis. 1.6.

Tablitsa 1.6. Tehnilise ülesande koostis ja sisu (GOST 34.602-89)

Eksklusiivne projekt näeb ette süsteemi ja selle osade eelprojekteerimislahenduste väljatöötamist. Eelprojekt ei ole rangelt kohustuslik etapp. Kui peamised projekteerimislahendused on varem määratletud või on konkreetse AIS -i ja automaatikaobjekti jaoks piisavalt ilmsed, siis saab selle etapi tööde üldisest järjestusest välja jätta.

AIS -funktsioonid;

Allsüsteemide funktsioonid, nende eesmärgid ja rakendamise eeldatav mõju;

Ülesannete ja üksikute ülesannete komplektide koosseis;

Teabebaasi kontseptsioon ja selle laiendatud struktuur;

Andmebaasihaldussüsteemi funktsioonid;

Arvutussüsteemi ja muude tehniliste vahendite koosseis;

Põhitarkvara funktsioonid ja parameetrid.

Tehtud töö tulemuste põhjal koostatakse dokumentatsioon, lepitakse kokku ja kinnitatakse koguses, mis on vajalik vastuvõetud projekteerimisotsuste täieliku kirjeldamiseks ja mis on piisavad süsteemi loomise edasiseks tööks.

Vastavalt GOST 19.102-77 sisaldab eelprojekti etapp kahte etappi: eelprojekti väljatöötamine; eskiisprojekti kinnitamine.

Arengu esimene etapp koosneb:

Sisend- ja väljundandmete struktuuri eelnev väljatöötamine;

Probleemi lahendamise meetodite täiustamine;

Probleemi lahendamise algoritmi üldise kirjelduse väljatöötamine;

Tasuvusuuringu väljatöötamine;

Seletuskirja koostamine.

Sel juhul on lubatud mõned teosed kombineerida ja välistada.

Allpool on dokumentide komplekt, mida tuleks ja saab eskiisikujunduse lõpus ette valmistada.

Kohustuslikud dokumendid:

1) projekteerimise ja arendamise ajakohastatud lähteülesanne
AIS -i töö;

2) AIS -i kvalifikatsiooninõuete täpsustamine;

3) funktsionaalsete tarkvarakomponentide ja andmekirjelduste nõuete spetsifikatsioonide kogum;

4) komponendi siseliidestele ja väliskeskkonnaga liidestele esitatavate nõuete täpsustamine;

5) andmebaasi haldussüsteemi kirjeldus, tarkvara ja infoobjektide struktuur ja levik andmebaasis;

6) suuniste eelnõud teabe kaitsmiseks ja AISi töökindluse tagamiseks;

7) AIS -i administraatori käsiraamatu esialgne versioon;

8) AISi kasutusjuhendi esialgne versioon;

9) muudetud kava projekti elluviimiseks;

10) täiustatud AIS -i kvaliteedi tagamise juhtimiskava;

11) AIS esialgse eelnõu seletuskiri;

12) muudetud leping (leping) kliendiga üksikasjade kohta
AIS uus disain.

Kliendiga kokkuleppel koostatud dokumendid:

1) AIS -i toimimise esialgne kirjeldus;

2) andmevoogude skeem AIS -i funktsionaalsete komponentide vahel;

3) AIS -arhitektuuri, tarkvara ja teabekomponentide koostoime, arvutusprotsessi korralduse ja ressursside eraldamise täpsustatud skeem;

4) komponentide kvaliteedinäitajate ja neile esitatavate nõuete kirjeldus AIS -i arendusetappide kaupa;

5) aruanne tehniliste ja majanduslike näitajate, projekti elluviimise ajakava, ressursside eraldamise ja eelarve kohta;

6) tabel spetsialistide jaotuse kohta komponentide ja tööetappide kaupa;

7) arendajate sertifikaadid tehnoloogia ja automatiseerimisvahendite kasutamise õiguse kohta AIS -i arendamiseks;

8) saadud dokumentide koostisele ja vormidele esitatavate nõuete kirjeldus tööetappide kaupa;

9) plaan tarkvarakomponentide silumiseks, pakkudes sellele katseautomaatika meetodeid ja tööriistu;

10) esialgne juhend üksikasjaliku disaini jaoks
vania, AIS -komponentide programmeerimine ja silumine;

11) müügi ja elluviimise esialgne kava;

12) andmekogu esialgse struktuuri kirjeldus.

Tehniline projekt süsteemid on tehniline dokumentatsioon, mis sisaldab kogu süsteemi hõlmavaid projekteerimislahendusi, probleemide lahendamise algoritme, aga ka AIS-i majandusliku efektiivsuse hindamist. Selles etapis viiakse läbi uurimis- ja katsetööde kompleks, et valida peamised disainilahendused ja arvutada süsteemi majanduslikku efektiivsust. Tehnilise projekti koosseis ja sisu on toodud tabelis. 1.7

Tabel 1.7. Tehnilise projekti sisu

Etapis "Töödokumentatsioon" luuakse tarkvaratoode ja töötatakse välja kogu sellega kaasnev dokumentatsioon. Dokumentatsioon peaks sisaldama kogu vajalikku ja piisavat teavet, et tagada AISi kasutuselevõtu ja selle toimimise töö, samuti säilitada süsteemi tööomaduste (kvaliteedi) tase. Väljatöötatud dokumentatsioon tuleb nõuetekohaselt koostada, kooskõlastada ja heaks kiita.

AIS -i kasutuselevõtmise etapis määratakse kindlaks järgmised peamised testitüübid: esialgsed testid, katse- ja vastuvõtukatsed. Vajadusel on lubatud täiendavalt läbi viia muud tüüpi süsteemi ja selle osade katseid.

Sõltuvalt AIS -i komponentide ja automaatikaobjekti vahekorrast võivad testid olla autonoomsed ja keerulised. Süsteemi komponendid on kaasatud autonoomsesse testimisse. Need viiakse läbi kohe, kui süsteemi osad on kasutuselevõtuks valmis. Keerulisi katseid tehakse omavahel ühendatud komponentide (alamsüsteemide) rühmade või kogu süsteemi jaoks.

Igat tüüpi testide läbiviimise kavandamiseks töötatakse välja dokument "Programm ja testimise metoodika". Dokumendi arendaja on kehtestatud lepingus või TK -s. Katsed või testjuhtumid saab lisada dokumendina manusena.

Silumine on kõige aeganõudvam disainiprotsess. Peidetud vead ilmnevad mõnikord pärast mitmeaastast süsteemi toimimist. Vigu on võimatu täielikult vältida, mis on tingitud süsteemi toimimise võimaluste astronoomilisest arvust. Lähitulevikus on peaaegu võimatu kontrollida nende kõigi toimimist.

Vigade tuvastamise ja kõrvaldamise kulud hilisemates projekteerimisetappides suurenevad ligikaudu eksponentsiaalselt (joonis 1.10).

Teadlased loevad 169 tüüpi vigu, mis on kokku võetud 19 suures klassis:

1) loogiline;

2) andmetöötlusvead;

3) I / O vead;

4) vead arvutustes;

Riis. 1.10.Ühe vea avastamise ja parandamise suhtelised kulud

5) vead kasutajaliideses;

6) vead operatsioonisüsteemis ja abiprogrammides;

7) paigutusvead;

8) vead programmeerimisliideste vahel;

9) vead liideses "Programm - süsteemitarkvara";

10) vead välisseadmete käsitsemisel;

11) andmebaasiga (DB) liidese vead;

12) andmebaasi initsialiseerimisvead;

13) vigu muudatuste tegemisel väljastpoolt;

14) globaalsete muutujatega seotud vead;

15) korduvad vead;

16) vead dokumentatsioonis;

17) tehniliste nõuete rikkumine;

18) tunnustamata vead;

19) operaatori vead.

Mitte kõik vead ei tule arendajalt. Erinevate teadlaste sõnul on 6–19% vigadest põhjustatud dokumentatsiooni vigadest.

AIS -i projekteerimise eri etappide arendamise ja testimise vaheline seos on näidatud joonisel fig. 1.11.

See ahel on ainult tinglikult "venitatud" jooneks. Selle sees on alati korduvad silmused. Vigade tuvastamiseks loovad arendajad spetsiaalsed testid ja viivad läbi silumisetapi. Kui vigu ei leita, ei tähenda see, et neid pole - võib -olla osutus test liiga nõrgaks.

Riis. 1.11. Arendamise ja testimise vaheline seos AIS -i kavandamise etappide kaupa

Silumistehnika võtab arvesse võimalike vigade sümptomeid:

Vale töötlemine (vale vastus, tulemus) - kuni 30%;

Kontrolli vale üleandmine - 16%;

Programmide kokkusobimatus kasutatud andmetega - 15%;

Programmide kokkusobimatus edastatud andmete jaoks - kuni 9%.

Silumisülesannete väljatöötamisel lahendatakse järgmised ülesanded:

Kirjutamistestid;

Kontrollpunktide, tsoonide ja marsruutide valik;

Kontrollitavate koguste loetelu kindlaksmääramine ja nende väärtuste kindlaksmääramise kord;

Testimise järjekorra määramine;

Silumise usaldusväärsuse ja keerukuse hindamine.

Silumisprogramm peab vähemalt korra läbi töötama algoritmi iga haru ja määrama samal ajal muutujatele väärtuste seeria, jäädvustades vahemiku piirid, mitu väärtust selle sees, nullväärtused ja ainsuse punktid (kui neid on). Spetsiaalsete süsteemide jaoks töötatakse välja spetsiaalsed silumiskeeled. Need võivad sisaldada suhteliselt väikest arvu käsklusi (20–30) koos täiendavate häälestusparameetritega järgmiste ülesannete lahendamiseks:

Tagasivõtmise kontroll;

Silumisprogrammi täitmisprotsessi modelleerimine;

Mälukomponentide oleku väljastamine programmi täitmise ajal;

Programmi täitmise protsessis teatud olekute saavutamise tingimuste kontrollimine;

Lähteandmete testväärtuste määramine;

Tingimuslike hüpete rakendamine testimisel, sõltuvalt teiste makrode või erinevate testide täitmise tulemustest;

Teenindustoimingute tegemine programmi testimiseks ettevalmistamiseks.

Silumisprotsessi ei saa liigitada täielikult ametlikuks, seetõttu on selle käitumiseks empiirilised soovitused, mis on toodud allpool.

1. Kasutage silumiseks semantilist, ettekavatsetud lähenemisviisi, planeerige silumisprotsessi ja kavandage hoolikalt testandmekogumid võimalikult lihtsatest valikutest, kõrvaldades kõige tõenäolisemad veaallikad.

2. Koguge ja analüüsige teavet, et testimisprotsessi sujuvamaks muuta.

Omadused ja vigade statistika;

Lähteandmete eripära ja programmi muutujate järjestuse ning nende vastastikuse mõju kohta;

Algoritmi ülesehituse ja selle tarkvara rakendamise tunnuste kohta.

3. Leidke korraga ainult üks viga.

Kasutage vigu puudutava teabe logimise ja kuvamise vahendeid, sealhulgas programmis spetsiaalset silumiskoodi muutujate näidisväärtuste printimiseks, teateid programmi üksikute osade lõpu, jälgimise, loogiliste tingimuste jms kohta.

5. Uurige saadud väljundit hoolikalt ja võrrelge seda oodatud, eelnevalt arvutatud tulemustega.

6. Pöörake tähelepanu andmetele, analüüsige hoolikalt programmi toimimist piirväärtuste kasutamisel ja valesti sisestamisel; juhtida andmetüüpe, vahemikke, väljade suurusi ja täpsust.

7. Kasutage andmevoo ja kontrollvoo analüüsi, et valideerida ja kehtestada andmete ulatused programmi erinevate täitmisradade jaoks.

8. Kasutage korraga mitut silumistööriista, ilma et peaksite mõtlema ühele võimalusele. Kasutage korraga automatiseeritud tööriistu ja käsitsi silumist ning katsetamist, kontrollides programmi koodi toimivust, võttes arvesse kõige tõenäolisemaid vigu.

9. Dokumenteerige leitud ja parandatud vead, nende erinevused, asukoht ja tüüp. See teave aitab vältida tulevasi vigu.

10. Mõõtke programmide keerukust. Suure keerukusega programmide puhul on suur tõenäosus spetsifikatsioonide ja kujundusvigade ning madala keerukusega, kodeerimis- ja kirjavigade osas.

11. Suurendada silumise kogemust ja praktikat paigutada programmidesse vead kunstlikult. Pärast teatud silumisperioodi peaks programmeerija juhtima tähelepanu allesjäänud vigadele, mida ta ei leidnud. Sellist "külvamist" kasutatakse laialdaselt avastamata vigade arvu hindamiseks (kui nii kunstlikke kui ka tegelikke vigu tuvastatakse ja parandatakse ühtlaselt, siis saab sisse viidud sisseviidud vigade ja tegelike vigade protsendi järgi ennustada, kui palju neist on alles).

Tehakse esialgseid katseid, et teha kindlaks süsteemi toimivus ja lahendada küsimus selle kasutuselevõtu võimalusest proovitööks. Eeltestid tuleks läbi viia pärast seda, kui arendaja on süsteemi tarnitud tarkvara ja riistvara silunud ja testinud ning esitanud asjakohased dokumendid nende valmisoleku kohta testimiseks, samuti pärast seda, kui AIS -i töötajad on tutvunud operatiivdokumentatsiooniga.

Süsteemi proovitööd tehakse selleks, et teha kindlaks süsteemi kvantitatiivsete ja kvalitatiivsete omaduste tegelikud väärtused ja personali valmisolek töötada selle toimimise tingimustes, samuti määrata kindlaks tegelik tõhusus ja kohandada vajadusel dokumentatsiooni.

Vastuvõtukatsed viiakse läbi, et teha kindlaks süsteemi vastavus tehnilistele spetsifikatsioonidele, hinnata proovitöö kvaliteeti ja lahendada küsimus süsteemi püsivaks kasutamiseks lubamise võimalusest.

Saada oma hea töö teadmistebaasi on lihtne. Kasutage allolevat vormi

Õpilased, kraadiõppurid, noored teadlased, kes kasutavad teadmistebaasi õpingutes ja töös, on teile väga tänulikud.

postitatud http://www.allbest.ru/

Haridus- ja Teadusministeerium Venemaa Föderatsioon

Föderaalne riigieelarve haridusasutus kõrgem erialane haridus

Peterburi Riiklik Tehnika- ja Disainiülikool

Kursuse töö

Eriala järgi: "Infosüsteemide arhitektuur"

Teemal: "Automatiseeritud infosüsteemide projekteerimine"

SISSEJUHATUS

Praegu on arvutitehnoloogia üha enam levinud nii tootmises kui ka ettevõtete töövoos ning sellega hõlmatud ülesannete loetelu muutub üha laiemaks. Töödeldava teabe maht ja keerukus kasvab pidevalt ning selle esitamist on vaja uut tüüpi.

Siin on vaid mõned arvutite kasutamise eelised organisatsiooni jaoks:

* Võimalus operatiivseks kontrollimiseks teabe täpsuse üle;

* Tuletatud andmete genereerimisel võimalike vigade arvu vähendamine;

* Võimalus kiiresti juurde pääseda mis tahes andmetele;

* Võimalus kiiresti aruandeid genereerida;

* Tööjõukulude ja teabe töötlemisele kuluva aja kokkuhoid.

Kõiki neid eeliseid hindavad praegu paljud organisatsioonid, seetõttu on täna automatiseeritud infosüsteemide kiire arendamise protsess ja nende rakendamine erinevate institutsioonide töös. Sellega seoses on minu valitud teema praegu väga asjakohane.

Erinevate ettevõtete ja asutuste automatiseerimissüsteemi valdkonna peamine omadus, mida iseloomustab lai valik sisendandmeid erinevate andmete töötlemise viisidega, on keerukuse kontsentreerimine nõuete analüüsi ja süsteemi spetsifikatsioonide kavandamise algfaasis. järgmiste etappide madal keerukus ja töömahukus. Tegelikult toimub siin arusaam sellest, mida tulevane süsteem teeb ja kuidas see sellele esitatavate nõuete täitmiseks toimib. Nimelt tekitavad süsteeminõuete ebamäärasus ja mittetäielikkus, lahendamata probleemid ja analüüsi- ning projekteerimisetapis tehtud vead keerulisi, sageli lahendamatuid probleeme järgmistes etappides ning viivad lõpuks kogu töö ebaõnnestumiseni. Isegi väga hea ettevõtte juhtimissüsteemi lihtne kopeerimine ei sobi kliendile kunagi täielikult, kuna see ei saa arvesse võtta selle eripära. Veelgi enam, sel juhul tekib probleem konkreetse ettevõtte jaoks kõige sobivama süsteemi valimisel. Ja seda probleemi muudab veelgi keerulisemaks asjaolu, et erinevaid infosüsteeme iseloomustavad märksõnad on praktiliselt samad:

* Ettevõtte ühtne infokeskkond;

* Reaalajas režiim;

* Sõltumatus seadusandlusest;

* Integreerimine teiste rakendustega (sh ettevõttes juba töötavad süsteemid);

* Järkjärguline rakendamine jne.

Tegelikult on keeruka automatiseerimise probleem muutunud iga ettevõtte jaoks aktuaalseks. Ja keeruka automatiseerimise tegemiseks vajate selles valdkonnas struktureeritud teadmisi.

Selle töö eesmärk: Tutvuda automatiseeritud infosüsteemide kontseptsiooniga, kaaluda projekteerimisprotsessi.

Eesmärgi saavutamiseks on vaja lahendada järgmised ülesanded:

§ sõnastada põhimõistete ja mõistete määratlused;

§ Kaaluge kavandi eesmärke ja eesmärke;

§ Tutvuge projekteerimise põhietappidega;

§ Tõstke esile automatiseeritud infosüsteemide arendusetapid;

§ Mõelge tehnilise ülesande ja tehnilise projekti koosseisu ja ülesehitusele.

1. KONTSEPTSIDE MÄÄRATLUS AUTOMATEERITUD INFOSÜSTEEM (AIS), INFOSÜSTEEM (IS), PROJEKT JA KUJUNDAMINE

Inimtegevuse valdkonna protsesside struktureerimisel kasutatakse erinevaid komponentide (alaprotsesside) eraldamise meetodeid ja saadakse erinevaid tulemusi, näiteks uurimis- ja arendustegevus, analüüs ja süntees jne.

Disain on üsna vastuvõetav, kui seda peetakse üldistava kontseptsioonina paljude intellektuaalsete ülesannete jaoks, mis on lahendatud mõtlemisprotsessis ja mida eristatakse erineval viisil.

Sõna disaini juur rõhutab seost sellise nimega protsessi ja selle protsessi peamiste tulemuste vahel järgmiselt:

a) projektsioon - mis saadakse keeruliste nähtuste analüüsimisel, et saada lihtsustatud esitusi, ja

b) projekt - see, mis saadakse lihtsamate piltide komplektist keerukate esituste sünteesimisel.

Ülaltoodud kaks põhjust olid põhjenduseks praegusele sõna disaini valikule kui terminile, mis tähistab arvutiteaduse põhitegevust.

Infosüsteemide projekteerimisel on infosüsteemid projekteerimisobjektid ja see on informaatika jaoks üsna loomulik (kuna IS peetakse selle peamisteks objektideks).

Nagu teate, on infosüsteemid võimelised kuvama iseenesest universumi kõige erinevamaid nähtusi ja seetõttu osutuvad kõik nähtused ka potentsiaalseteks disainiobjektideks.

Infosüsteemid osutuvad paljudel juhtudel disaini objektideks, s.t. need esinejad, kes viivad disainiprotsessi ise läbi. Projekteerimisprotsessi uurides tegeleme seega suuresti infosüsteemide uurimisega.

Süsteemi all mõistetakse mis tahes objekti, mida käsitletakse samaaegselt nii ühtse tervikuna kui ka seatud eesmärkide saavutamiseks kombineeritud heterogeensete elementide kogumina. Süsteemid erinevad üksteisest oluliselt nii koostise kui ka põhieesmärkide poolest.

Arvutiteaduses on süsteemi mõiste laialt levinud ja sellel on palju semantilisi tähendusi. Enamasti kasutatakse seda seoses riist- ja tarkvara komplektiga. Sõna infosüsteemi mõiste täiendus peegeldab selle loomise ja toimimise eesmärki. Infosüsteemid pakuvad mis tahes valdkonna probleemide kohta otsuste tegemisel vajaliku teabe kogumist, salvestamist, töötlemist, otsimist ja edastamist. Need aitavad probleeme analüüsida ja uusi tooteid luua.

Infosüsteem (IS) - omavahel ühendatud tööriistade, meetodite ja personali kogum, mida kasutatakse eesmärgi saavutamiseks teabe salvestamiseks, töötlemiseks ja väljastamiseks.

Kaasaegsed infotehnoloogiad pakuvad laia valikut võimalusi IP rakendamiseks, mille valikul lähtutakse kavandatud kasutajate nõuetest, mis reeglina arendusprotsessi käigus muutuvad.

Termini „automatiseeritud” lisamine „süsteemi” mõistele kajastab sellise süsteemi loomise ja toimimise viise.

Automatiseeritud süsteem(vastavalt GOST -ile) on süsteem, mis koosneb omavahel ühendatud organisatsiooniliste üksuste komplektist ja tegevuste automatiseerimise tööriistade komplektist, mis rakendab automatiseeritud funktsioone teatud tüübid tegevusi.

Automatiseeritud infosüsteem (AIS) on tarkvaraliste, tehniliste, informatiivsete, keeleliste, organisatsiooniliste ja tehnoloogiliste vahendite ning personali kompleks, mis on mõeldud kasutaja- ja teabeteenuste ning (või) teabetoe probleemide lahendamiseks.

Automatiseeritud infosüsteem on teabe, majanduslike ja matemaatiliste meetodite ja mudelite, tehniliste, tarkvara, tehnoloogiliste tööriistade ja spetsialistide kogum, mis on ette nähtud teabe töötlemiseks ja juhtimisotsuste tegemiseks.

Automatiseeritud infosüsteemide peamine eesmärk ei ole mitte ainult elektrooniliste teaberessursside kogumine ja salvestamine, vaid ka kasutajate juurdepääsu võimaldamine neile. AIS -i üks olulisemaid omadusi on andmete otsimise korraldamine nende teabemassiivides (andmebaasides).

Projekti AIS all peame silmas disaini- ja tehnoloogilist dokumentatsiooni, mis kirjeldab disainilahendusi IS loomiseks ja kasutamiseks konkreetses tarkvara- ja riistvarakeskkonnas.

Projekti kui juhtimisobjekti peamisi eristavaid jooni saab eristada:

· Piiratud lõppeesmärk;

· Piiratud kestus;

· Piiratud eelarve;

· Vajalikud piiratud ressursid;

· Uudsus ettevõtte jaoks, mille jaoks projekti rakendatakse;

· Keerukus;

· Juriidiline ja organisatsiooniline tugi.

Projekti planeerimist ja juhtimist silmas pidades on vaja selgelt mõista, et me räägime teatud dünaamilise objekti haldamisest. Seetõttu peab projektijuhtimissüsteem olema piisavalt paindlik, et seda oleks võimalik muuta ilma globaalsete muudatusteta tööprogramm... Tööde teostamise tagab vajalike ressursside olemasolu: materjalid; seadmed; inimressursid. Juhtimissüsteemide teooria seisukohast peab projekt kui juhtimisobjekt olema jälgitav ja kontrollitav, see tähendab, et esile tõstetakse mõned omadused, mille abil saab projekti kulgu pidevalt jälgida. Lisaks on vaja mehhanisme, et projekti edenemist õigeaegselt mõjutada.

AIS -i disaini all mõistetakse protsessi, mille käigus muudetakse objekti sisendteave, meetodid ja kogemused sarnase otstarbega objektide kavandamisel vastavalt GOST -le IS -projektiks.

Sellest vaatenurgast taandatakse AIS -i projekteerimine disainilahenduste järjestikuseks vormistamiseks AIS -i elutsükli erinevatel etappidel: nõuete kavandamine ja analüüs, AIS -i tehniline ja üksikasjalik kavandamine, rakendamine ja kasutamine.

Arendatavate süsteemide skaala määrab projekteerimisprotsessis osalejate koosseisu ja arvu. Suure mahu ja kitsaste tähtaegadega projekteerimistööde teostamiseks võivad süsteemi arendamises osaleda mitmed disainimeeskonnad (arendusorganisatsioonid). Sel juhul eraldatakse emaorganisatsioon, mis koordineerib kõigi kaastäitvate organisatsioonide tegevust.

AIS -i disainitehnoloogia on AIS -i metoodika ja disainivahendite kogum, samuti selle korraldamise meetodid ja vahendid (AIS -projekti loomise ja kaasajastamise protsessi juhtimine).

Projekteerimistehnoloogia põhineb tehnoloogilisel protsessil, mis määrab toimingud, nende järjestuse, esinejate nõutava koosseisu, vahendid ja ressursid.

AIS-i projekteerimise tehnoloogiline protsess on üldiselt jagatud järjestikku paralleelseteks, ühendatud ja alluvateks tegevusahelateks, millest igaühel võib olla oma teema. Seega on projekteerimistehnoloogia paika pandud ühe või teise meetodi alusel teostatud tehnoloogiliste toimingute reguleeritud jada, mille tulemusena selgub mitte ainult see, mida tuleks projekti loomiseks teha, vaid ka see, kuidas, kes, ja millises järjekorras.

Iga valitud projekteerimistehnoloogia teema peaks olema omavahel seotud projekteerimisprotsesside kajastamine AISi elutsükli kõikides etappides. Valitud projekteerimistehnoloogia peamised nõuded hõlmavad järgmist:

· Loodud projekt peab vastama kliendi nõuetele;

· Projekti elutsükli kõigi etappide maksimaalne kajastamine;

· Projekteerimise ja projektitoetuse minimaalsete töö- ja kulude tagamine;

· Tehnoloogia peaks olema disaini ja projektitoe vahelise suhtluse aluseks;

· Disaineri tootlikkuse kasv;

· Projekti kavandamise ja toimimise usaldusväärsus;

· Projekti dokumentatsiooni lihtne hooldus.

AIS -i disainitehnoloogia põhineb metoodikal, mis määratleb olemuse, peamised eristavad tehnoloogilised omadused.

Kujundusmetoodika eeldab teatud kontseptsiooni, disainipõhimõtete olemasolu, mis on rakendatud meetodite kogumiga, mida omakorda tuleb mingil viisil toetada.

Disaini korraldamine hõlmab disainerite ja kliendiga suhtlemise meetodite määratlemist AIS -projekti loomisel, mida saab toetada ka konkreetsete tööriistade komplektiga.

arvutipõhine projekteerimise infosüsteem

2. KUJUNDAMISE EESMÄRK JA EESMÄRGID

Infosüsteemide projekteerimine algab alati projekti eesmärgi määratlemisest. Kavandamise eesmärk on tehnilise valiku tegemine ja teabe kujundamine, matemaatiline, tarkvara ning organisatsiooniline ja juriidiline tugi.

Tehnilise toe valik peaks tagama teabe õigeaegse kogumise, registreerimise, edastamise, säilitamise, täitmise ja töötlemise.

Teabetugi peaks ette nägema süsteemi ühtse teabefondi loomise ja toimimise, mida esindavad mitmesugused teabemassiivid, andmekogum või andmebaas.

Süsteemide matemaatilise toe moodustamine hõlmab funktsionaalsete probleemide lahendamiseks täielikku meetodite ja algoritmide komplekti. Tarkvarasüsteemide väljatöötamisel pööratakse erilist tähelepanu programmide ja kasutajajuhendite komplekti loomisele ning tõhusate tarkvaratoodete valikule.

Iga eduka projekti peamine ülesanne on tagada, et süsteemi käivitamise ajal ja kogu selle toimimise ajal oleks võimalik tagada:

· Süsteemi nõutav funktsionaalsus ja selle toimimise muutuvate tingimustega kohanemise aste;

· Süsteemi nõutav läbilaskevõime;

· Süsteemi nõutud reageerimisaeg päringule;

· Süsteemi tõrgeteta toimimine nõutud režiimis, teisisõnu - süsteemi valmisolek ja kättesaadavus kasutajate päringute töötlemiseks;

· Süsteemi töö lihtsus ja tugi;

· Vajalik turvalisus.

Toimivus on süsteemi tõhususe peamine tegur. Hea disain on suure jõudlusega süsteemi alus.

Automatiseeritud infosüsteemide projekteerimine hõlmab kolme peamist valdkonda:

· Andmebaasis rakendatavate andmeobjektide kujundamine;

· Programmide, ekraanide, aruannete koostamine, mis tagavad andmete päringute täitmise;

· Võttes arvesse konkreetset keskkonda või tehnoloogiat, nimelt: võrgu topoloogiat, riistvara konfiguratsiooni, kasutatud arhitektuuri (failiserver või klient-server), paralleelset töötlemist, hajutatud andmetöötlust jne.

Reaalsetes tingimustes on disain süsteemide funktsionaalsuse nõuetele vastava meetodi otsimine olemasolevate tehnoloogiate abil, arvestades antud piiranguid.

Igale projektile seatakse mitmeid absoluutseid nõudeid, näiteks maksimaalne projekti väljatöötamise aeg, maksimaalsed rahalised investeeringud projekti jne. Üks projekteerimise raskusi on see, et see ei ole nii struktureeritud ülesanne nagu projektile esitatavate nõuete analüüsimine või konkreetse disainilahenduse rakendamine.

3. DISAINI ETAPID

AIS -i loomise protsess on jagatud mitmeks etapiks (etapiks), mis on piiratud teatud aja jooksul ja lõpeb konkreetse toote vabastamisega.

Iga projekt, olenemata selle elluviimiseks vajaliku töö keerukusest ja mahust, läbib oma arengus teatud olekuid. Alates olekust, kui „projekti pole veel olemas”, kuni olekuni, kui „projekti pole enam olemas”. Arenguetappide kogum alates idee tekkimisest kuni projekti täieliku lõpetamiseni on tavaliselt jagatud etappideks.

Organisatsiooni tegevuse analüüsimise etapis läbi viidud AIS -i loomise algetappide eesmärk on sõnastada AIS -ile nõuded, mis kajastavad õigesti ja täpselt kliendiorganisatsiooni eesmärke. Organisatsiooni vajadustele vastava AIS -i loomise protsessi täpsustamiseks on vaja välja selgitada ja selgelt sõnastada, millised need vajadused on. Selleks on vaja kindlaks määrata klientide nõuded AIS -ile ja kaardistada need mudelikeeles AIS -projekti arendamise nõuete hulka, et tagada organisatsiooni eesmärkide ja eesmärkide järgimine.

Eristada saab järgmisi automatiseeritud infosüsteemide väljatöötamise etappe:

3.1 Mõiste kujundamine. Kontseptuaalne faas

See sisaldab:

· Idee kujundamine;

· Võtmetähtsusega projektimeeskonna moodustamine;

· Kliendi ja teiste osalejate motivatsiooni ja nõuete uurimine;

· Lähteandmete kogumine ja olemasoleva seisundi analüüs;

· Põhinõuete ja piirangute, vajalike materiaalsete, rahaliste ja tööjõuressursside kindlaksmääramine;

· Alternatiivide võrdlev hindamine;

· Ettepanekute esitamine, nende läbivaatamine ja kinnitamine.

AIS -i nõuete koostamise ülesanne on üks olulisemaid, raskesti vormistatavaid ning vea korral kõige kulukam ja raskemini parandatav. Kaasaegsed tööriistad ja tarkvaratooted võimaldavad teil kiiresti luua AIS-i vastavalt valmisnõuetele. Kuid sageli ei rahulda need süsteemid kliente, vajavad mitmeid muudatusi, mis toob kaasa AIS -i tegelike kulude järsu tõusu. Sellise olukorra peamine põhjus on analüüsi etapis AIS -i nõuete vale, ebatäpne või mittetäielik määratlus.

3.2 Tehnilise ettepaneku koostamine

§ projekti põhistruktuuri põhisisu väljatöötamine;

§ tehniliste kirjelduste väljatöötamine ja kinnitamine;

§ planeerimine, projekti põhilise struktuurimudeli lagunemine;

§ projekti kalkulatsiooni ja eelarve koostamine;

§ areng kalendriplaanid ja laiendatud töögraafikud;

§ kliendiga lepingu sõlmimine;

§ projektis osalejate sidevahendite ja töö edenemise kontrollimise vahendite kasutuselevõtmine.

3.3 Disain

Projekteerimisetapis tehakse kindlaks allsüsteemid, nende omavahelised seosed ning valitakse välja kõige tõhusamad vahendite projekteerimise ja kasutamise viisid. Selle etapi tüüpilised tööd:

§ projekteerimise põhitööde teostamine;

§ privaatsete tehniliste spetsifikatsioonide väljatöötamine;

§ ideekavandi teostamine;

§ tehniliste kirjelduste ja juhiste koostamine;

§ kavandi väljatöötamise, läbivaatamise ja kinnitamise esitamine.

Projekteerimisetapis moodustatakse ennekõike andmemudelid. Disainerid saavad analüüsitulemusi sisendina. Loogiliste ja füüsiliste andmemudelite loomine on andmebaasi kujundamise oluline osa. Analüüsi käigus saadud infomudel muudetakse esmalt loogiliseks ja seejärel füüsiliseks andmemudeliks.

3.4 Areng

Arendusfaasis viiakse läbi projektitöö koordineerimine ja operatiivkontroll, toodetakse, kombineeritakse ja katsetatakse alamsüsteeme.

Pärast autonoomse testi edukat läbimist lisatakse moodul süsteemi väljatöötatud ossa ja loodud moodulite rühm läbib kommunikatsioonitestid, mis peaksid jälgima nende vastastikust mõju.

Lisaks kontrollitakse moodulite rühma töökindlust, see tähendab, et nad läbivad esiteks süsteemirikkeid simuleerivad testid ja teiseks rikete vahelise tööaja testid. Esimene testide rühm näitab, kui hästi süsteem taastub tarkvara riketest, riistvara riketest. Teine testide rühm määrab süsteemi stabiilsuse astme normaalse töö ajal ja võimaldab hinnata süsteemi tööaega. Stabiilsuskatsete komplekt peaks sisaldama teste, mis simuleerivad süsteemi tippkoormust.

Seejärel läbib kogu moodulite süsteem süsteemikontrolli - toote sisemise aktsepteerimistesti, mis näitab selle kvaliteedi taset. See hõlmab funktsionaalsuse teste ja süsteemi töökindluse teste.

Viimane automaatne test infosüsteem- vastuvõtukatsed. Selline test hõlmab infosüsteemi näitamist kliendile ja see peab sisaldama testide rühma, mis simuleerivad tegelikke äriprotsesse.

3.5 Süsteemi kasutuselevõtt

Süsteemi kasutuselevõtmise etapis tehakse katseid, süsteemi katsetatakse reaalsetes tingimustes, käivad läbirääkimised projekti tulemuste ja võimalike uute lepingute üle.

Peamised tööliigid:

§ keerukad testid;

§ personali koolitamine loodava süsteemi toimimiseks;

§ töödokumentatsiooni koostamine, süsteemi tarnimine kliendile ja selle kasutuselevõtt;

§ saatmine, tugi, teenindus;

§ projekti tulemuste hindamine ja lõppdokumentide koostamine.

4. TEHNILISE ÜLESANDE JA TEHNILISE KUJUNDAMISE KOOSTIS JA STRUKTUUR

1. Üldsätted

1.1. Lähteülesanne (TOR) on peamine dokument, mis määratleb infosüsteemi loomise (arendamise või moderniseerimise - edasise loomise) nõuded ja korra, mille kohaselt IS -i arendamine toimub ja selle aktsepteerimisel esitatakse töösse.

1.2. TK on välja töötatud kogu süsteemi jaoks, mis on loodud töötama iseseisvalt või teise süsteemi osana.

1.3. Käesoleva standardiga kehtestatud mahuga IS -le esitatavad nõuded saab lisada vastloodud informatsiooniobjekti projekteerimise ülesandesse. Sel juhul TK -d ei arendata.

1.4. TK -s sisalduvad nõuded peavad vastama praegusele arengutasemele infotehnoloogiaid ja ei allu sarnastele nõuetele parimate kaasaegsete kodu- ja välismaiste kolleegide jaoks. TK -s sätestatud nõuded ei tohiks piirata süsteemi arendajat kõige tõhusamate tehniliste, tehniliste, majanduslike ja muude lahenduste leidmisel ja rakendamisel.

1.5. TK sisaldab ainult neid nõudeid, mis täiendavad seda tüüpi süsteemidele esitatavaid nõudeid ja mille määravad konkreetse objekti eripärad, mille jaoks süsteem luuakse.

1.6. TK muudatused koostatakse kliendi ja arendaja poolt allkirjastatud täienduse või protokolliga. Täiendus või määratud protokoll on TK on IP lahutamatu osa. TK tiitellehel peaks olema kirje "Kehtiv alates ...".

2. Koostis ja sisu

2.1. TK sisaldab järgmisi jaotisi, mis võib jagada alajaotisteks:

1) üldteave;

2) süsteemi loomise (arendamise) eesmärk ja eesmärgid;

3) esemete omadused;

4) süsteeminõuded;

5) süsteemi loomisega seotud tööde koosseis ja sisu;

6) süsteemi kontrollimise ja vastuvõtmise kord;

7) nõuded arendusobjekti süsteemi kasutuselevõtuks ettevalmistamise tööde koosseisule ja sisule;

8) nõuded dokumentatsioonile;

9) arenguallikad.

TK võib sisaldada rakendusi.

2.2. Sõltuvalt projekti tüübist, eesmärgist, spetsiifilistest iseärasustest ja süsteemi toimimise tingimustest on lubatud vormistada TK paragrahvid taotluste vormis, tutvustada TK täiendavaid, välistavaid või kombineerida alajaotusi.

Süsteemi osade TK ei sisalda sektsioone, mis dubleerivad TK sektsioonide sisu tervikuna.

2.3. Jaotises „Üldteave” märkige:

1) süsteemi täielik nimi ja selle sümbol;

2) teema kood või lepingu kood (number);

3) süsteemi arendaja ja kliendi (kasutaja) ettevõtete nimed ja nende andmed;

4) loetelu dokumentidest, mille alusel süsteem luuakse, kes ja millal need dokumendid kinnitas;

5) süsteemi loomise kavandatud algus- ja lõppkuupäev;

6) teave töö rahastamise allikate ja korra kohta;

7) süsteemi (selle osade) loomise, üksikute vahendite (riistvara, tarkvara, teave) ning tarkvara ja riistvara (tarkvara ja metoodika) tootmise ja kohandamise töö tulemuste registreerimise ja kliendile esitamise kord ) süsteemi süsteemid.

2.4. Jaotis "Süsteemi loomise (arendamise) eesmärk ja eesmärgid" koosneb alajaotistest:

1) süsteemi eesmärk;

2) süsteemi loomise eesmärk.

2.4.1. Alajaotises "Süsteemi eesmärk" märkige süsteemi tegevuse liik (haldus, disain jne) ja loetelu informatiivsetest objektidest (objektid), millel seda eeldatavasti kasutatakse.

2.4.2. Alajaotises "Süsteemi loomise eesmärgid" on toodud informatsiooniobjekti tehniliste, tehnoloogiliste, tootmismajanduslike või muude näitajate nimed ja nõutavad väärtused, mis tuleb saavutada IS-i loomise tulemusena. , ja on märgitud kriteeriumid süsteemi loomise eesmärkide saavutamise hindamiseks.

2.5. Jaotises "Informatsioonilise objekti omadused" esitage:

1) lühiteave informatsiooniobjekti kohta või lingid seda teavet sisaldavatele dokumentidele;

2) teave automaatikaobjekti töötingimuste kohta.

2.6. Jaotis Süsteeminõuded koosneb järgmistest alajaotistest:

1) nõuded süsteemile tervikuna;

2) nõuded süsteemi täidetavatele funktsioonidele (ülesannetele);

3) nõuded tagatiseliikidele.

Süsteemile esitatavate nõuete koosseis, mis on kaasatud IS -i TK sellesse jaotisesse, määratakse sõltuvalt konkreetse süsteemi tüübist, eesmärgist, eripäradest ja toimimistingimustest.

2.6.1. Alamjaotises „Nõuded kogu süsteemile” märkige:

nõuded süsteemi ülesehitusele ja toimimisele;

nõuded süsteemi töötajate arvule ja kvalifikatsioonile ning nende töörežiimile;

sihtkoha näitajad;

töökindluse nõuded;

ohutusnõuded;

nõuded ergonoomikale ja tehnilisele esteetikale;

nõuded süsteemi komponentide käitamisele, hooldusele, remondile ja ladustamisele;

nõuded teabe kaitsmiseks volitamata juurdepääsu eest;

teabe ohutuse nõuded õnnetusjuhtumite korral;

nõuded kaitseks välismõjude mõju eest;

nõuded patendi puhtusele;

standardimise ja ühendamise nõuded;

Lisanõuded.

2.6.1.1. Nõuded süsteemi ülesehitusele ja toimimisele hõlmavad järgmist:

1) allsüsteemide loetelu, nende otstarve ja peamised omadused, nõuded hierarhiatasandite arvule ja süsteemi tsentraliseerimise astmele;

2) nõuded süsteemikomponentide vahelise teabevahetuse meetoditele ja sidevahenditele;

3) nõuded külgnevate süsteemidega loodava süsteemi ühenduste omadustele, nõuded selle ühilduvusele, sealhulgas juhised teabe vahetamiseks (automaatselt, dokumentide saatmisega, telefoni teel jne);

4) nõuded süsteemi töörežiimidele;

5) süsteemi diagnoosimise nõuded;

6) väljavaated arenguks, süsteemi kaasajastamiseks.

2.6.1.2. IS -töötajate arvu ja kvalifikatsiooni nõuded hõlmavad järgmist:

§ nõuded IS -i personali (kasutajate) arvule;

§ nõuded personali kvalifikatsioonile, nende väljaõppe kord ning teadmiste ja oskuste kontrollimine;

§ IS -i töötajate nõutav töörežiim.

2.6.1.3. IS -i eesmärgi näitajate nõuetes esitatakse nende parameetrite väärtused, mis iseloomustavad süsteemi selle eesmärgile vastavuse astet.

2.6.1.4. Usaldusväärsusnõuded hõlmavad järgmist:

1) süsteemi kui terviku või selle allsüsteemide töökindlusnäitajate koostis ja kvantitatiivsed väärtused;

2) loetelu eriolukordadest, mille puhul tuleb töökindluse nõudeid reguleerida, ja vastavate näitajate väärtused;

3) nõuded riist- ja tarkvara töökindlusele;

4) nõuded usaldusväärsuse näitajate hindamise ja jälgimise meetoditele süsteemi loomise eri etappides vastavalt kehtivatele regulatiivsetele ja tehnilistele dokumentidele.

2.6.1.5. Ohutusnõuded hõlmavad ohutusnõudeid süsteemi tarnimisel, kasutuselevõtmisel, kasutamisel ja hooldamisel.

2.6.1.6. Ergonoomikale ja tehnilisele esteetikale esitatavad nõuded hõlmavad IP-indikaatoreid, mis määravad inimese ja masina vahelise suhtluse nõutava kvaliteedi ja personali töötingimuste mugavuse.

2.6.1.7. Nõuded teabe kaitsmiseks volitamata juurdepääsu eest hõlmavad tööstuse ja kliendi infokeskkonna kehtestatud nõudeid.

2.6.1.8. Teabe ohutuse nõuetes on toodud sündmuste loetelu: õnnetused, tehniliste vahendite tõrked (sh voolukatkestus) jne, milles tuleb tagada teabe ohutus süsteemis.

2.6.1.9. Patendi puhtuse nõuded näitavad riikide loetelu, mille puhul tuleb tagada süsteemi ja selle osade patendipuhtus.

2.6.1.10. Lisanõuded hõlmavad erinõudeid süsteemi arendaja või kliendi äranägemisel.

2.6.2. Alamjaotises "Nõuded funktsioonidele (ülesannetele)", mida süsteem täidab, esitatakse järgmine:

§ iga alamsüsteemi puhul automatiseeritavate funktsioonide, ülesannete või nende komplekside loetelu (sh need, mis tagavad süsteemi osade koostoime);

§ süsteemi loomisel kahes või enamas järjekorras - funktsionaalsete alamsüsteemide, üksikute funktsioonide või ülesannete loend, mis võetakse kasutusele 1. ja järgnevates järjekordades;

§ iga funktsiooni, ülesande (või ülesannete komplekti) rakendamise ajakava;

§ nõuded iga funktsiooni (ülesande või ülesannete kompleksi) rakendamise kvaliteedile, väljundteabe esitamise vormile, nõutava täpsuse ja täitmisaja omadused, funktsioonide rühma samaaegse täitmise nõuded, usaldusväärsus tulemustest;

§ rikete loetelu ja kriteeriumid iga funktsiooni jaoks, millele on kehtestatud töökindluse nõuded.

2.6.3. Alajaotises "Toetuse liikide nõuded" on olenevalt süsteemi tüübist toodud nõuded matemaatilisele, informatiivsele, keelelisele, tarkvarale, tehnilisele, metroloogilisele, organisatsioonilisele, metoodilisele ja muudele süsteemitoele.

2.6.3.2. Süsteemi teavitamiseks esitatakse järgmised nõuded:

1) süsteemi andmete koostise, struktuuri ja korraldamise meetodite kohta;

2) infovahetus süsteemi komponentide vahel;

3) teabe ühilduvus seotud süsteemidega;

4) andmebaasihaldussüsteemide rakendamise kohta;

5) süsteemi andmete kogumise, töötlemise, edastamise ja andmete esitamise protsessi struktuurile;

6) andmekaitsele;

7) andmete kontroll, säilitamine, ajakohastamine ja taastamine;

2.6.3.3. Süsteemi keeleliseks toetamiseks esitatakse nõuded kõrgetasemeliste programmeerimiskeelte kasutamisele süsteemis, keeltele kasutajate ja süsteemi tehniliste vahendite vaheliseks suhtlemiseks, samuti nõuded andmete kodeerimiseks ja dekodeerimiseks. andmete sisend-väljundkeeled, andmetöötluskeeled, vahendid valdkonna kirjeldamiseks, dialoogi korraldamise meetodid.

2.6.3.4. Süsteemi tarkvara jaoks on esitatud ostetud tarkvara loend ja nõuded:

1) tarkvara sõltuvusest töökeskkonnast;

2) tarkvara kvaliteedile, samuti selle pakkumise ja kontrollimise meetoditele;

2.6.3.5. Süsteemi tehnilise toe jaoks esitatakse järgmised nõuded:

1) tehniliste vahendite tüüpide, sealhulgas tehniliste vahendite komplekside, tarkvara- ja riistvarakomplekside ning muude süsteemis kasutamiseks lubatud komponentide tüüpide suhtes;

2) süsteemi tehnilise toe funktsionaalsete, projekteerimis- ja tööomaduste kohta.

2.6.3.6. Metroloogilise toe nõuded hõlmavad järgmist:

1) mõõtekanalite esialgne loetelu;

2) nõuded parameetrite mõõtmiste täpsusele ja (või) mõõtekanalite metroloogilistele omadustele;

3) nõuded süsteemi tehniliste vahendite metroloogilisele ühilduvusele;

4) süsteemi juhtimis- ja arvutuskanalite loetelu, mille puhul on vaja hinnata täpsusomadusi;

5) nõuded süsteemi mõõtekanalitesse kuuluvate riist- ja tarkvara metroloogilisele toele, vahenditele, sisseehitatud juhtimisele, süsteemi seadistamisel ja testimisel kasutatavate mõõtekanalite ja mõõtevahendite metroloogilisele sobivusele;

6) metroloogilise sertifikaadi liik (riiklik või osakondlik) koos viitega selle rakendamise korrale ja sertifitseerimist teostavatele organisatsioonidele.

2.6.3.7. Organisatsioonitoe jaoks on esitatud järgmised nõuded:

1) süsteemi toimimises osalevate või toimimist pakkuvate allüksuste struktuuri ja funktsioonide kohta;

2) süsteemi toimimise korraldamiseks ja IS -i personali ning infobjekti personali vahelise suhtluse järjekorraks;

3) kaitsta süsteemi personali ekslike tegude eest.

2.7. Jaotis "Süsteemi loomise (arendamise) tööde koostis ja sisu" peab sisaldama süsteemi loomisega seotud tööetappide ja -etappide loetelu, nende rakendamise ajastust, organisatsioonide nimekirja - töö teostajad. , lingid dokumentidele, mis kinnitavad nende organisatsioonide nõusolekut osaleda süsteemi loomises, või kirje, mis tuvastab nende tööde tegemise eest vastutava isiku (tellija või arendaja).

See jaotis näeb ette ka järgmist:

1) vastavate tööetappide ja -etappide lõpus esitatud dokumentide loetelu;

2) tehnilise dokumentatsiooni uurimise liik ja kord (kontrollitud dokumentatsiooni etapp, etapp, maht, ekspertorganisatsioon);

3) tööprogramm, mille eesmärk on tagada arendatava süsteemi nõutav töökindlus (vajadusel);

4) metroloogilise toe tööde loetelu süsteemi loomise kõikides etappides, näidates ära nende tähtajad ja täideviivad organisatsioonid (vajadusel).

2.8. Jaotises "Süsteemi kontrollimise ja vastuvõtmise kord" märkige:

1) süsteemi ja selle komponentide tüübid, koostis, ulatus ja katsemeetodid;

2) tööde vastuvõtmise üldnõuded etappide kaupa, vastuvõtudokumentatsiooni kooskõlastamise ja kinnitamise kord;

2.9. Jaotises "Nõuded automatiseerimisobjekti süsteemi kasutuselevõtuks ettevalmistamise töö koostisele ja sisule" on vaja esitada nimekiri põhitegevustest ja nende tegijatest, mida tuleks projekti ettevalmistamisel läbi viia ISi kasutuselevõtmine.

Põhitegevuste loend sisaldab järgmist:

1) süsteemi siseneva teabe viimine (vastavalt teabe- ja keeletoe nõuetele);

2) tingimuste loomine projekti toimimiseks, mille alusel on tagatud loodud süsteemi vastavus TK -s sisalduvatele nõuetele;

3) süsteemi toimimiseks vajalike allüksuste ja teenuste loomine;

4) personali komplekteerimise ja koolituse ajastus ja kord.

2.10. Jaotises "Dokumentatsiooninõuded" on esitatud järgmine teave.

1) arendaja ja süsteemi tellija poolt väljatöötatavate dokumentide komplektide ja tüüpide loetelu;

2) masinmeedias väljastatud dokumentide loetelu;

3) kui puuduvad riiklikud standardid, mis määravad kindlaks süsteemi elementide dokumenteerimise nõuded, lisage täiendavalt nõuded selliste dokumentide koostisele ja sisule.

2.11. Jaotises "Arendusallikad" tuleks loetleda dokumendid ja infomaterjalid, mille alusel TK välja töötati ja mida tuleks süsteemi loomisel kasutada.

3. Disainireeglid.

3.1. TK jaod ja alajaotused tuleks paigutada paragrahvis kehtestatud järjekorras. Selle standardi 2.

3.2. Lehtede (lehtede) arv pannakse alla, alustades tiitellehele järgnevast esimesest lehest lehe ülemisse ossa (teksti kohal, keskel) pärast TK -koodi määramist IP -l.

3.3. Tiitelleht sisaldab tellija, arendaja ja heakskiitvate ettevõtete allkirju, mis on pitseeritud. Vajadusel koostatakse tiitelleht mitmele lehele. Viimasele lehele pannakse lepingus osalevate TK arendajate ja ametnike allkirjad ning TK eelnõu arutamine IP -l.

TK tiitellehe vorm on toodud lisas 2. TK viimase lehe vorm on toodud 3. lisas.

3.4. TK lisa lisa tiitelleht on koostatud samamoodi nagu tehnilise ülesande tiitelleht. Nime "Lähteülesanne" asemel kirjutavad nad "Täiendus nr ... TK jaoks AC ...".

3.5. Järgmistele TK täiendamise lehtedele pannakse muudatuse alus, muudatuse sisu ja lingid dokumentidele, mille kohaselt need muudatused tehakse.

3.6. TK-le lisateksti esitamisel tuleks märkida vastavate klauslite, alapunktide, TK põhitabelite jms numbrid ning sõnad „asendada“, „täiendada“, „välistada“, „ümber sõnastada“ "Tuleks kasutada.

IS jaoks TK väljatöötamise, koordineerimise ja heakskiitmise kord.

1. TK eelnõu töötab välja süsteemi organisatsioon-arendaja kliendi osavõtul tehniliste nõuete (rakendused, taktikalised ja tehnilised spetsifikatsioonid jne) alusel.

Konkurentsivõimelises töökorralduses kaalub TK eelnõu variante klient, kes kas valib eelistatud variandi või koostab võrdleva analüüsi põhjal TK lõpliku versiooni vahelduvvooluks, milles osaleb tulevane IS arendaja.

2. TK eelnõu kooskõlastamise vajaduse riiklike järelevalveasutuste ja teiste huvitatud organisatsioonidega määravad ühiselt süsteemi tellija ja IS -i eelnõu väljatöötaja,

TK eelnõu IC jaoks heakskiitmise tööd teevad ühiselt TK arendaja ja süsteemi klient, kumbki oma ministeeriumi (osakonna) organisatsioonides.

3. TK eelnõu kinnitamise tähtaeg igas organisatsioonis ei tohiks ületada 15 päeva alates selle kättesaamise kuupäevast. Soovitatav on saata TK eelnõu koopiad (koopiad) samaaegselt kõigile organisatsioonidele (osakondadele) kinnitamiseks.

4. Märkused traditsiooniliste omavahendite eelnõu kohta tuleks esitada koos tehnilise põhjendusega. Otsused kommentaaride kohta peaksid tegema TK eelnõu arendaja ja süsteemi klient enne TK heakskiitu IS -is.

5. Kui TK eelnõu kokkuleppimisel tekkisid arendaja ja tellija (või teiste huvitatud organisatsioonide) vahel erimeelsused, siis koostatakse erimeelsuste protokoll (meelevaldne vorm) ja tehakse konkreetne otsus aastal. kehtestatud korda.

6. TK eelnõu heakskiitmisel on lubatud koostada eraldi dokument (kiri). Sel juhul tehke pealkirja "Kokkulepitud" all link sellele dokumendile.

7. TK kinnitamise viivad läbi süsteemi arendaja ja tellija ettevõtete juhid.

8. Kinnitatud TK koopiad 10 päeva jooksul pärast kinnitamist saadab TK arendaja süsteemi loomisel osalejatele.

9. TK täienduste kooskõlastamine ja kinnitamine toimub IS -is TK -le ettenähtud viisil.

10. TK muudatusi ei tohi pärast süsteemi või selle vastuvõtukatsete järjekorda esitamist heaks kiita.

Süsteemi tehnilise projekti väljatöötamise aluseks on kliendi poolt kinnitatud tehniline ülesanne.

Süsteemi tehniline projekt on ettenähtud viisil kinnitatud tehniline dokumentatsioon, mis sisaldab kogu süsteemi hõlmavaid projekteerimislahendusi, probleemide lahendamise algoritmi, samuti hinnangut automatiseeritud juhtimissüsteemi majanduslikule tõhususele ja loetelu meetmetest, mis on ette nähtud rakendamise objekt.

Tehniline projekt on väljatöötamisel, et määrata kindlaks süsteemi loomise peamised disainilahendused. Selles etapis viiakse läbi parimate lahenduste valimiseks uurimis- ja katsetööde kompleks, viiakse läbi peamiste projekteerimislahenduste eksperimentaalne kontroll ja arvutatakse süsteemi majanduslik efektiivsus.

Tegelikult sisaldab tehniline projekt majanduslike, matemaatiliste ja algoritmiliste mudelite kompleksi.

Süsteemi tehnilise disaini täielik komplekt sisaldab 10 dokumenti:

1. Selgitav märkus.

2. Süsteemi funktsionaalne ja organisatsiooniline struktuur.

3. Probleemi avaldus ja lahenduse algoritm.

4. Teabebaasi korraldus.

5. Dokumentide vormide album.

6. Tarkvarasüsteem.

7. Tehniliste vahendite kompleksi ehitamise põhimõte.

8. Süsteemi majandusliku efektiivsuse arvutamine.

9. Meetmed rajatise ettevalmistamiseks süsteemi rakendamiseks.

10. Dokumentide loetelu.

Ülaltoodud loendist täidetakse iga EIS -is sisalduva ülesande jaoks dokument 3 "Ülesannete ja lahendamise algoritm", ülejäänud dokumendid on kogu süsteemi jaoks ühised. Lisaks saab üksikute allsüsteemide jaoks välja töötada dokumente 1, 2, 5, 8 ja 9.

Kõik loetletud dokumendid saab rühmitada ja esitada tehnilise projekti nelja põhiosa kujul: majanduslik ja korralduslik, informatiivne, matemaatiline ja tehniline.

Tehnilise projekti majanduslik ja korralduslik osa sisaldab süsteemi arendamist õigustavat selgitavat märkust, arendajate organisatsioonide loetelu, objekti lühikirjeldust, mis näitab selle toimimise peamisi tehnilisi ja majanduslikke näitajaid ning seoseid teiste objektidega, lühidalt teave süsteemi funktsionaalsete ja toetavate osade peamiste disainilahenduste kohta.

Tehnilise projekti osas, mis on pühendatud süsteemi organisatsioonilisele ja funktsionaalsele struktuurile, on toodud järgmised andmed: eraldatud alamsüsteemide põhjendus, nende loetelu ja eesmärk; igas alamsüsteemis lahendatavate ülesannete loetelu koos nende sisu lühikirjeldusega; alamsüsteemide ja iga alamsüsteemi ülesannete vaheliste teabelinkide skeem.

Iga prioriteetsete ülesannete komplekti kuuluva ülesande puhul tehakse selle avaldus ja selle lahendamise algoritm. See tehnilise projekti osa sisaldab:

§ probleemi organisatsiooniline ja majanduslik olemus (nimi, lahenduse eesmärk, kokkuvõte, meetod, probleemi lahendamise sagedus ja aeg, andmete kogumise ja edastamise meetodid, probleemi seostamine teiste ülesannetega, tulemuste kasutamise laad lahendus, milles neid kasutatakse);

§ probleemi majanduslik ja matemaatiline mudel (struktuurne ja üksikasjalik esitusviis);

§ operatiivteabe sisestamine (näitajate omadused, nende olulisus ja muutuste ulatus, esitlusvormid);

§ normatiivne viiteinformatsioon (NSI) - sisu ja esitusviisid;

§ teiste ülesannetega suhtlemiseks salvestatud teave;

§ selle probleemi edasiste lahenduste jaoks kogutud teave;

§ teave muudatuste tegemise kohta (muudatuste tegemise süsteem ja muudatuste objektiks oleva teabe loetelu);

§ ülesande lahendamise algoritm (arvutamise etappide jada, diagramm, arvutusvalemid);

§ testjuhtum (andmetega täidetud sisenddokumendivormide komplekt, kogunenud ja salvestatud teabega tingimuslikud dokumendid, majandusliku ja tehnilise probleemi lahendamise tulemuste põhjal täidetud väljunddokumendi vormid ja vastavalt väljatöötatud arvutusalgoritmile).

Dokument "Süsteemi majandusliku efektiivsuse arvutamine" sisaldab kokkuvõtvat hinnangut süsteemide toimimisega seotud kulude kohta, iga -aastase majandusliku efektiivsuse arvutamist, mille allikateks on majanduse tootmisstruktuuri optimeerimine ( ühing), juhtimisotsused.

Dokument "Meetmed rajatise ettevalmistamiseks süsteemi rakendamiseks" sisaldab loetelu organisatsioonilistest meetmetest olemasoleva juhtimisstruktuuri täiustamiseks, süsteemi rakendamise tööde loetelu, mis tuleb läbi viia üksikasjaliku kavandamise etapis, näidates ära ajastus ja vastutavad isikud.

Tehnilise projekti informatiivne osa ühendab dokumendid 4 ja 5. Dokument "Infobaasi korraldus" kajastab: teabeallikaid ja selle edastamise meetodeid funktsionaalsete ülesannete esmase kompleksi lahendamiseks; süsteemis kasutatavate näitajate komplekt; dokumentide koostis, nende vastuvõtmise tingimused ja sagedus; põhilised disainilahendused NSI fondi korraldamiseks; riikliku statistikaameti koosseis, sealhulgas rekvisiitide loetelu, nende määratlus, tähtsus, muutuste ulatus ja riiklike statistikaametite dokumentide loetelu; võrdlusandmete andmekogumite loetelu, nende maht, teabe parandamise järjekord ja sagedus; ettepanekud dokumentide ühtlustamiseks, katsejuhtum riikliku statistikaameti muutmiseks; riikliku statistika struktuuri vorm koos elementide vahelise seose kirjeldusega; nõuded fondi loomise ja pidamise tehnoloogiale; võrdlusandmete säilitamise, otsimise, muutmise ja juhtimise meetodid, mahtude ja teabevoogude määramine.

"Dokumentide vormide album" sisaldab viiteandmete vorme.

Tehnilise projekti matemaatiline osa sisaldab tarkvara ülesehituse põhjendust, programmeerimissüsteemi valiku põhjendust, sealhulgas standardprogrammide loetelu.

Tehnilise projekti tehniline osa sisaldab: tehnilise andmetöötluse protsessi skeemi kirjeldust ja põhjendust; mittestandardsete seadmete väljatöötamise nõuete põhjendus; tehniliste vahendite kompleksi ja selle funktsionaalrühmade struktuuri põhjendus ja valik; meetmete kogum tehniliste vahendite töökindluse tagamiseks.

KOKKUVÕTE

Infosüsteemi arendamine toimub reeglina üsna konkreetne ettevõte... Ettevõtte ainetegevuse eripära mõjutab muidugi infosüsteemi ülesehitust, kuid samas on erinevate ettevõtete struktuurid üldiselt üksteisega sarnased. Iga organisatsioon, olenemata oma tegevuse tüübist, koosneb mitmest osakonnast, mis viivad otseselt läbi üht või teist tüüpi ettevõtte tegevust, ja see olukord kehtib peaaegu kõigi organisatsioonide kohta, olenemata sellest, millist tüüpi tegevusega nad tegelevad.

Kaasaegsete infotehnoloogiate kasutuselevõtt võimaldab vähendada konkreetsete turundus- ja tootmisprojektide ettevalmistamiseks kuluvat aega, vähendada nende rakendamise ajal mittetootmiskulusid, välistada vigade tekkimise võimalus raamatupidamis-, tehnoloogiliste ja muud tüüpi dokumentide koostamisel , mis annab äriühingule otsese majandusliku efekti.

Muidugi, selleks, et paljastada kõik arvutite kasutamisega kaasnevad potentsiaalsed võimalused, on nende töös vaja kasutada komplekti ülesannetega kõige paremini sobivaid tarkvara- ja riistvaratööriistu. Seetõttu on praegu suur vajadus äriühingute järele arvutiprogrammid mis toetavad ettevõtte juhtkonna tööd, samuti teavet selle kohta, kuidas ettevõtte arvutitehnikat parimal viisil kasutada.

AIS -i disaini rakendamine hõlmab disainerite teatud disainitehnoloogia kasutamist, mis vastab väljatöötatava projekti ulatusele ja omadustele.

KASUTATUD KIRJANDUSE LOETELU

1. Juhised distsipliini "Automatiseeritud infosüsteemid" uurimiseks [Elektrooniline ressurss]. - Moskva, 2006. - Juurdepääsurežiim:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Pealkiri. ekraanilt.

2. Vikipeedia, vaba entsüklopeedia [Elektrooniline ressurss]/Artikkel "Infosüsteem" - Juurdepääsurežiim: http://ru.wikipedia.org/wiki/Information system.

3. Arvutipress: Interneti -ajakiri. - Elektron. Dan. - [B.m., 2001]. - Juurdepääsurežiim: http://compress.ru/article.aspx?id=12282.

4. Vendrov AM, "Majandusinfosüsteemide tarkvara projekteerimine" / А.М. Vendra. - M.: "Rahandus ja statistika", 2000. - 364 lk.

5. "Automaatse süsteemi loomise lähteülesanne" / - M.: GOST 34.602-89, 1990.

6. Grekul V.I. "Infosüsteemide projekteerimine" / V.I. Grekul, G.N. Denischenko, N.L. Korovkin. - M.: Interneti -infotehnoloogiaülikool, 2008.

Postitatud saidile Allbest.ru

Sarnased dokumendid

Infosüsteemide arendamine. Kaasaegne turg finants- ja majandustarkvara. Automatiseeritud infosüsteemide rakendamise eelised ja puudused. Automatiseeritud infosüsteemide projekteerimise meetodid.

lõputöö, lisatud 22.11.2015


Automatiseeritud infosüsteemide toe tüübid. Tehniliste spetsifikatsioonide koostamine, infosüsteemi väljatöötamine, programmi kasutusjuhendi koostamine. Programmeerimisvahendid hajutatud infotöötlussüsteemidele.

praktikaaruanne, lisatud 16.04.2017


Automatiseeritud infosüsteemide elutsükkel. CASE-tehnoloogial põhinevate automatiseeritud süsteemide projekteerimise metoodika alused. Automaatse süsteemi analüüsi ja planeerimise, ehitamise ja rakendamise etapp. Joa ja spiraali mudel.

kursusetöö lisatud 20.11.2010


Infosüsteemi mõiste, infosüsteemide tüübid. Automatiseeritud infosüsteemide arendamise tööriistade analüüs. Nõuded programmile ja tarkvaratootele. Graafilise liidese vormide ja andmebaaside väljatöötamine.

lõputöö, lisatud 23.06.2015


Põhimõtted, kuidas korraldada süsteem, mis koosneb personalist ja tööriistade komplektist nende tegevuse automatiseerimiseks. Ettevõtte automatiseeritud infosüsteemide projekteerimine. Struktuur, sisend- ja väljundvoogud, automatiseeritud süsteemide piirangud.

esitlus lisatud 14.10.2013


Infosüsteemi kontseptsioon. Infosüsteemide arendamise etapid. Protsessid infosüsteemis. Infosüsteem turuniššide leidmiseks, tootmiskulude vähendamiseks. Infosüsteemi ülesehitus. Tehniline abi.

abstraktne, lisatud 17.11.2011


Infosüsteemi korraldus, ülesehitus ja ülesehitus. Tema töö tulemuslikkuse näitajad. ACS analüüsi eesmärgid ja ülesanded. Automatiseeritud süsteemide komponendid. Teema kirjeldus, sisend- ja väljundandmed. Kasutusjuhtumi skeemi koostamine.

kursusetöö lisatud 11.04.2014


Automatiseeritud infosüsteemide (AIS) loomine ja korraldamine. AIS -i põhikomponendid ja tehnoloogilised protsessid. AIS -i loomise etapid ja etapid organisatsiooni juhtkonna positsioonilt. Automatiseeritud süsteemi disainilahenduste komplekside väljatöötamine.

abstraktne, lisatud 18.10.2012


Ettevõtte automatiseeritud infosüsteemide arengu ajalugu mõjutavad peamised tegurid. Nende üldised omadused ja klassifikatsioon. Integreeritud AIS -i koostis ja struktuur. ERP -süsteemid kui kaasaegne ettevõtte infosüsteem.

esitlus lisatud 14.10.2013


Ainevaldkonna analüüs, automatiseeritud infosüsteemide projekteerimise etapid. Tarkvaraarenduse tööriistade süsteemid. CASE tööriistade roll infomudeli kujundamisel. Kavandatud andmebaasi loogiline mudel.

1. detsembril 2015 toimus Venemaa tööstus- ja kaubandusministeeriumi korraldusel loodud automatiseeritud projektijuhtimise infosüsteemi (AIS PU) avatud kaitsmine. Kaitsmisel, mida juhtis Vene Föderatsiooni tööstus- ja kaubandusministri esimene asetäitja Gleb Nikitin, osalesid ministeeriumi osakondade juhid, majandusarengu ministeeriumi ja Vene Föderatsiooni kaitseministeeriumi esindajad.

Automatiseeritud projektijuhtimissüsteemi eesmärk on parandada Venemaa tööstus- ja kaubandusministeeriumi tõhusust projektide toetamise, hooldamise ja elluviimise osas, mis on muu hulgas suunatud impordi asendamisele, ekspordi suurendamisele, tootmise tehnoloogilisele arengule, loomisele ja suure jõudlusega töökohtade kaasajastamine ja tööstusliku infrastruktuuri arendamine (tööstuspargid, tehnoloogiapargid, tööstusdisaini ja -tehnika keskused).

Loodud süsteemi peamised kasutajad koos riiklike programmide ja föderaalsete sihtprogrammide elluviimise eest vastutava ministeeriumi juhtkonna ja töötajatega on tööstusettevõtted, kes viivad ellu oma investeerimisprojekte, föderaalsed täitevvõimud, kes pakuvad riiklikku tuge ettevõtetele, pankadele, institutsionaalsed investorid ja muud finantsasutused, kes osalevad tööstusettevõtete investeerimisprojektide ja tööstusinfrastruktuuri arendamise projektide rahastamises.

Süsteemi lõi Venemaa süsteemiintegraator "Inline-Technologies", kaasates kodumaise tarkvaraarendaja "LM-Soft". AIS PU töötati välja Venemaa 1C platvormi alusel, kasutades tasuta tarkvara ja patenteeritud tarkvara.

Süsteemi funktsionaalsuse uurimise tulemuste põhjal saadi positiivset tagasisidet nii tööstus- ja kaubandusministeeriumi juhtkonnalt ja töötajatelt kui ka majandusarengu ministeeriumilt, kes vastutab projektijuhtimismehhanismide rakendamise eest valitsuses. kehad. Lisaks andsid positiivset tagasisidet AIS PU võimaluste kohta tööstusettevõtted, kes esitasid süsteemi arendamise raames oma katseprojekte. Eelkõige andsid positiivset tagasisidet AIS PU katseoperatsiooni kohta Krylovi riikliku teaduskeskuse, JSC teadus- ja tootmiskorporatsiooni Uralvagonzavod ning föderaalse riigiettevõtte teadusliku uurimisinstituudi geodeesia esindajad. Samuti tuleb märkida, et kaitseministeeriumi jurisdiktsiooni alla kuuluva JSC Garrison esindajad ja mõnede riigi osalusega pankade esindajad näitasid üles suurt huvi süsteemi vastu ja huvi ühise koostöö vastu projektijuhtimise rakendamisel. .

„Loodud projektijuhtimissüsteem ei suurenda mitte ainult ministeeriumi töötajate tõhusust, vaid võimaldab korraldada ka tõhusat suhtlemist tööstusettevõtete, valitsusasutuste ja arendusasutuste ning finantsasutuste tööstusprojektides osalejatega. AIS PU töötab ühe akna põhimõttel, kasutades maksimaalselt elektroonilisi dokumendihaldustehnoloogiaid, ”kommenteeris tööstus- ja kaubandusministeeriumi infotehnoloogia ja avalike suhete osakonna direktor Sergei Valuev. süsteem.

„AIS PU kasutuselevõtu peamine eesmärk on parandada kontrolli ja hallatavuse kvaliteeti, hõlbustada suhtlemist ametiasutuste ja suuremahuliste projektide elluviijate vahel. Süsteemi väljatöötamisel võeti esmalt arvesse tööstusstandardeid, valitsuse määrusi ja korraldusi, presidendi seadlusi ja tööstus- ja kaubandusministri korraldusi, samuti parimaid sise- ja välispraktikaid. AIS PU jaoks on loodud üle 600 komponendi, üles on laaditud üle 20 000 teatmeteose, sõnaraamatu ja klassifikaatori. AIS PU arendamisega seotud edasise töö raames on kavas süsteem integreerida Venemaa tööstus- ja kaubandusministeeriumi poolt praegu loodava tööstuse riigi infosüsteemi ühe allsüsteemina, “ütles Sergei Valuev.

Projektijuhtimismeetodite kasutuselevõtt on määratletud kui üks peamisi vahendeid avaliku halduse kaasajastamiseks ja see on kirjas uues väljaandes „Vene Föderatsiooni valitsuse peamised tegevussuunad ajavahemikuks kuni 2018. aastani“, millele kirjutas alla peaminister Minister Dmitri Medvedev.