AIS upravljanje projektima. AIS “Upravljanje projektima. Osnovni koncepti AIS dizajna

Postoje mnoge metode i mogućnosti za razvoj AIS -a čija uporaba ovisi o različitim čimbenicima, na primjer, o veličini poduzeća i (ili) njihovom IS -u, ciljevima stvaranja IS -a, raspoloživim resursima itd. Metode i načela projektiranja IS se raspravlja u prethodnim poglavljima.

Životni ciklus softverskog projekta skup je faza i faza razvoja softvera, od analize sustava i razvoja početnih zahtjeva do njegove instalacije (instalacije) na računalo.

Iskustvo u razvoju i provedbi različitih klasa AIS -a pokazalo je visoku učinkovitost (uključujući i ekonomsku) njihove primjene, posebno u velikim poduzećima. Ogleda se u dobroj organizaciji rada i proizvodnje, povećanju točnosti planiranja i provedbe postavljenih zadataka, u osiguravanju ritma poduzeća, smanjenju udjela ručnog rada, učinkovitoj (uključujući i operativnoj) informacijskoj podršci raznim kategorije korisnika itd. Prosječno razdoblje povrata za takve sustave obično ne prelazi dvije godine.

Prilikom razvoja IS -a, u većini slučajeva prednost se daje standardnim dizajnerskim rješenjima, prilagođenim specifičnim uvjetima i mogućnostima Kupca. Pojedinačni projekti razvijaju se u nedostatku standardnih rješenja ili kada se osnovni parametri organizacije značajno razlikuju (za više od 10-15%) od standardnih rješenja. To se obično odnosi na velike i najveće organizacije.

Nijedna shema razvoja IC -a nije apsolutna. Moguće su različite mogućnosti, ovisno o, na primjer, početnim uvjetima u kojima se razvoj odvija: razvija se potpuno novi sustav; već je provedeno istraživanje poduzeća i postoji model njegove aktivnosti; poduzeće već ima IS koji se može koristiti kao početni prototip ili ga treba integrirati s razvijenim.

Detaljan razvoj projekta AIS pretpostavlja dostupnost cjelovitog seta organizacijske, projektne, tehnološke i operativne dokumentacije.

Dizajn bilo kojeg objekta izvodi se sa:

• a) određivanje njegove funkcionalne svrhe (zašto je potrebna, što i kako projektirani objekt radi),
• b) identificiranje logičkih veza (kako projektirani objekt ispunjava svoju funkcionalnu svrhu, koje se informacije obrađuju i kojim redoslijedom),
• c) izbor materijalnih sredstava za provedbu projektiranog objekta - funkcionalni, tehnološki i tehnički aspekt (mediji, alati za obradu podataka itd.),
• d) prostorno (teritorijalno) postavljanje materijalnih prodajnih sredstava na dodijeljena ili moguća za korištenje područja,
• e) formiranje organizacijske i upravljačke strukture projektiranog objekta (sastav odjela, ovlaštenja i funkcionalne odgovornosti radnici)

Nakon odabira metode projektiranja AIS -a potrebno je planirati skup radova za izradu sustava u skladu s tipičnim fazama njegova razvoja. Projekt pregledava i odobrava kupac. AIS dizajn uključuje provedbu određenih faza i faza.

Za uspješnu provedbu projekta potrebno je uspostaviti stvarne prekretnice s jasno označenim početkom i završetkom. Izrada detaljnog plana rada povezana je s opisom procesa i njihovim redoslijedom koji se izvode u svakoj fazi, stručnjacima, sredstvima i sredstvima potrebnim za to. Ovaj pristup pomaže u većoj mjeri izbjeći propuste i pogreške. To je potrebno za zaposlenike koji provode provedbu projekta automatizacije, a također ima pozitivan utjecaj na osobe koje ga financiraju.

Učinkovita fazna provedba projektantskih radova povezana je s potrebom izrade rasporeda njihove provedbe, uključujući resurse i vrijeme (faze) njihove provedbe (vidi prethodne grafikone i slike). Resursi uključuju potrebno osoblje, hardver, softver, financiranje i infrastrukturu. Istodobno, bolje je financirati zasebno za svaku vrstu posla (kupnja sredstava i softvera, instalacija, obuka, zasebne faze projektiranja itd.).

Za automatizaciju različiti tipovi aktivnosti (upravljanje, projektiranje, istraživanje itd.), uključujući njihove kombinacije, koriste odredbe GOST-a 34.601-90. On predviđa sljedeće faze i faze projektiranja (tablica 1).

tablica 2

Standard također navodi sljedeće:

• · Faze i faze koje izvode organizacije koje sudjeluju u stvaranju AU utvrđene su ugovorima i projektnim zadatkom na temelju ovog standarda.
• · Dopušteno je isključiti fazu “Nacrt projekta” i odvojene faze rada u svim fazama, kombinirati “Tehnički dizajn” i “Radna dokumentacija” u jednu fazu “Tehno-radni dizajn”. Ovisno o specifičnostima nuklearnih sustava koji se stvaraju i uvjetima za njihovo stvaranje, dopušteno je izvođenje pojedinih faza rada prije završetka prethodnih faza, paralelno u vremenu izvođenja faza rada, uključivanjem novih faza rada .

Tehnički projekt (idejni projekt) sadrži sheme kola i projektnu dokumentaciju razvojnog objekta i njegovih komponenti, popis odabranih gotovih softverskih alata i tehnička podrška(uključujući vrste računala, operacijske sustave, aplikacijske programe itd.), algoritme za rješavanje problema za razvoj novih softverskih alata).

Detaljno projektiranje - konačna faza projektiranja općenito, koja omogućuje pojašnjenje i pojedinosti rezultata prethodnih faza, stvaranje i ispitivanje prototipa objekta automatizacije, razvoj i testiranje softverskih proizvoda, tehnološke i operativne dokumentacije.

U suvremenoj praksi projektiranja automatiziranih informacijskih sustava (na primjer, AIPS, ASNTI, ACS itd.) To može biti početna faza njihove implementacije u rad organizacije ili službe Naručitelja projekta, odnosno voditelja jedna u nizu drugih automatiziranih organizacija, usluga itd.

Detaljan razvoj projekta sustava pretpostavlja dostupnost cjelovitog skupa organizacijske, projektne, tehnološke i operativne dokumentacije.

Državni standard GOST 19.102-77 utvrđuje sljedeće faze razvoja softverske dokumentacije:

• 1. Opis poslova;
• 2. Nacrt projekta;
• 3. Tehničko projektiranje;
• 4. Radni nacrt;
• 5. Provedba.

Imajte na umu da se za male projekte broj faza može smanjiti.

U sklopu provedbe prve faze "Formiranje zahtjeva za AU", vrši se izmjera objekta i potkrepljuje se potreba za stvaranjem AIS -a, uzimajući u obzir zahtjeve korisnika za projektirani AIS. Ovi prvi postupci u fazi projektiranja dio su studije prije projektiranja. To također može uključivati ​​postupke druge faze projektiranja - “Razvoj koncepta NEK”.

U procesu istraživanja prije projektiranja provodi se studija izvedivosti izvodljivosti stvaranja AIS-a; razvoj općih zahtjeva za razvoj AIS -a.

U procesu istraživanja prije projektiranja za izvođenje potrebnih projektnih radova identificiraju se sljedeće:

• · materijalna sredstva,
• · financijska sredstva,
• · ljudski resursi,
• · Privremeni izvori.

Trenutno svaka organizacija ima na raspolaganju neke materijalne resurse, u pravilu, heterogenog podrijetla. Kako bi se osigurala sigurnost ovih resursa, potrebno je voditi evidenciju i imenovati odgovorne osobe. Rješenje ovog problema može se provesti pomoću različitih aplikacija kao što su 1C: Enterprise, AVARD i mnoge druge. No ti su programi vrlo skupi, kako u kupnji tako i u održavanju. Zahtijeva posebno obrazovanje i obuku osoblja.

U izradi treba razumjeti proces stvaranja prototipa predloženog ili mogućeg objekta.

Suvremena tehnologija za stvaranje AIS -a kombinacija je učinkovitih alata i metoda projektiranja koji pojednostavljuju ovaj proces, smanjuju troškove, smanjuju kalendarsko vrijeme za projektiranje sustava i poboljšavaju kvalitetu razvoja zahvaljujući velikom izboru provjerenih naprednih dizajnerskih rješenja.

Do glavnog alati za projektiranje može pripisati:

Tipična dizajnerska rješenja (TPD) i aplikacijski paketi (PPP). TPR - skup algoritamskih i softverskih elemenata koji osiguravaju provedbu zadataka na računalu uz pomoć odgovarajućih tehničkih sredstava;

Računalno podržani sustavi projektiranja (CAD), koji uključuju korištenje računala u svim fazama stvaranja AIS-a.

Opći zahtjevi za alate za projektiranje:

Potpuna pokrivenost cijelog procesa stvaranja AIS -a;

Kompatibilnost, tj. dosljednost i u procesu stvaranja sustava i u procesu njegova funkcioniranja;

Svestranost, tj. mogućnost korištenja istih alata za različite objekte;

Pristupačnost u razvoju i jednostavnost (jednostavnost) u implementaciji;

Mogućnost organiziranja procesa projektiranja u načinu interaktivne interakcije između programera sustava, dizajnera i računala;

Prilagodljivost i isplativost.

Među metode projektiranja dodijeliti:

Originalni dizajn;

Tipičan dizajn i njegove vrste: elementarni, podsustavni, modularni, grupni;

Dizajn s računalnom podrškom.

Izvorna metoda projektiranja tradicionalna je i usmjerena na jedno određeno poduzeće. Karakteristična značajka Ova metoda je razvoj izvornih metoda pregleda objekata i izrada potrebne dokumentacije u obliku pojedinačnog projekta. Prednost ove metode je odraz specifičnih značajki objekta automatizacije u AIS projektu. Nedostaci uključuju relativno visok intenzitet rada i dugo vrijeme razvoja, nizak pokazatelj funkcionalne pouzdanosti i prilagodljivosti promjenjivim uvjetima. Međutim, projekti nastali izvornom metodom podliježu modernizaciji čisti oblik ova se metoda rijetko koristi. Danas se tijekom njegove provedbe koriste različiti alati za projektiranje, a samo za određene dijelove projekta potrebna su izvorna dizajnerska rješenja. To donekle ublažava njegove nedostatke. Međutim, ova metoda ostaje relevantna pri automatizaciji složenih, izvanrednih objekata.

V. modernim uvjetima AIS obično nije izgrađen od nule. Trenutno u gospodarstvu, na gotovo svim razinama upravljanja i u svim gospodarskim subjektima, djeluju automatizirani sustavi za obradu informacija. Povećana potreba za pravodobnim, kvalitetnim i operativnim informacijama zahtijeva stvaranje AIS-a na novoj tehničko-tehnološkoj osnovi.

Potraga za racionalnim načinima projektiranja ide u sljedećim smjerovima:

1. razvoj standardnih dizajnerskih rješenja implementiranih u primijenjene programske pakete (PPP) za rješavanje ekonomskih problema s naknadnim povezivanjem JPP -a sa specifičnim uvjetima provedbe i rada;

2. razvoj automatiziranih sustava projektiranja.

Prvi od načina je mogućnost korištenja standardnih dizajnerskih rješenja uključenih u pakete primijenjenih programa.

Tipičan dizajn- industrijska metoda za stvaranje AIS -a pomoću TPR -a i PPP -a. Ovu metodu karakterizira prisutnost provjerenih, standardnih organizacijsko-ekonomskih, tehničkih, informacijskih, matematičkih i softverskih alata za automatizaciju upravljanja. Primjena ove metode omogućuje smanjenje intenziteta rada, smanjenje troškova i skraćivanje vremena projektiranja te poboljšanje kvalitete dizajna. Tipičan proces projektiranja sastoji se u izboru i povezivanju podržanih podsustava u skladu sa zahtjevima određenog AIS -a. Tipičan dio AIS -a je kompleks informacija, softvera i hardvera. Tipična priroda informacijske podrške postiže se strogim pridržavanjem jedinstva strukture informacijske baze, sastava polja, oblika ulaznih i izlaznih dokumenata. Tipična priroda softvera postiže se korištenjem PPP -a, a tipična priroda tehničke podrške korištenjem računala istih ili kombiniranih tipova.

1. Varijacija tipične metode projektiranja je metoda elementarni dizajn, koji se temelji na TPR -u. Prilikom izrade projekta koristi se gotovo rješenje s manjim izmjenama, a novo se ne razvija.

2. Prilikom korištenja modularna metoda TPR nastaju na modularnoj osnovi, kada je svako dizajnersko rješenje podijeljeno na zasebne sastavne dijelove - module koji implementiraju određeni dio TPR -a. To vam omogućuje da kreirate projekt za novi automatizirani sustav kombiniranjem pojedinačnih standardnih modula.

3. Prilikom korištenja metoda projektiranja podsustava za svaki podsustav stvaraju se projekti rješenja i aplikacijski paketi - za cijeli sustav i funkcionalni. Raspodjela podsustava ovisi o predmetu ekonomskog i proizvodnog procesa. Za svaki od podsustava razvijeno je vlastito automatizirano dizajnersko rješenje i PPP, koji mogu biti sustavni ili funkcionalni. Sustavna javno-privatna partnerstva obuhvaćaju javno-privatna partnerstva za upravljanje podacima, javno-privatna partnerstva standardnih postupaka obrade podataka, metode matematičke statistike i diskretno programiranje itd. Funkcionalna javno-privatna partnerstva uključuju pakete namijenjene industrijskim poduzećima s diskretnom ili kontinuiranom prirodom proizvodnje, u neindustrijskoj sferi, i upravljanje sektorima.

Važan zahtjev za RFP je kompatibilnost, budući da pri projektiranju AIS -a preporučljivo je koristiti nekoliko paketa odjednom. Dizajn sustava koji koriste PPP zapravo se svodi na vezivanje paketa odabranih prema određenim parametrima za specifične uvjete objekta automatizacije. Pozitivne kvalitete Ovaj pristup projektiranju može se nazvati: manje radno intenzivan proces, smanjenje vremena projektiranja u usporedbi s izvornim projektom, implementacija naprednih metoda obrade podataka, pojednostavljenje projektne dokumentacije (budući da se koristi dokumentacija paketa), povećana pouzdanost projektiranog AIS-a.

4. Osim toga, postoje metoda grupnog dizajna... Njegova suština leži u preliminarnom odabiru grupe objekata iste vrste u smislu karakteristika. Među njima je odabran osnovni objekt za koji se projekt razvija te se mogu koristiti različite metode i metode projektiranja. Ovdje je najvažnije osigurati visoku prilagodljivost projekta. Glavno područje primjene ove metode su neindustrijski objekti (na primjer, skladišta).

Sljedeće se aktivnosti najučinkovitije podvrgavaju automatizaciji:

1. računovodstvo, uključujući upravljačko i financijsko. Najveći broj RFP -ova stvoren je za računovodstvo. Među njima su "1C: Računovodstvo", "Turbo-računovođa", "Info-računovođa", "Parus", "ABACUS", "Bambi +" itd .;

2. Usluga pomoći i informiranja ekonomska aktivnost... Zastupljeno sljedećim JPP -om: "GARANT" (porezi, računovodstvo, revizija, poduzetništvo, bankarstvo, valutna regulacija, carinska kontrola); "CONSULBTANT +" (porezi, računovodstvo, revizija, poduzetništvo, bankarstvo, valutna regulacija, carinska kontrola).

3.ekonomske i financijske aktivnosti... Zastupljeno sljedećim RFP -om:

a) "Ekonomska analiza i prognoza tvrtke, organizacije" (tvrtka "INEK"), koja provodi funkcije: ekonomska analiza djelatnosti poduzeća, poduzeća; izradu poslovnih planova; studija izvedivosti otplate kredita; analiza i odabir mogućnosti za aktivnosti; predviđanje stanja, novčanih tijekova i gotovih proizvoda.

b) Višekorisnički mrežni kompleks potpune automatizacije korporacije Galaktika (JSC Novy Atlant), koji uključuje planiranje, operativno upravljanje, računovodstvo i kontrolu, analiza, osim toga, omogućuje u okviru DSS-a osiguranje rješenja poslovnog planiranja problemi pri korištenju projekta JPP-stručnjak.

4. organizacija rada pročelnika;

5. automatizacija prometa dokumenata;

6. obuka.

U posljednje vrijeme poduzeća i tvrtke radije kupuju gotove pakete i tehnologije te im po potrebi dodaju vlastiti softver jer je razvoj vlastitog AIS-a povezan s visokim troškovima i rizicima. U pravilu se razvija i predlaže osnovni sustav koji se prilagođava prema željama pojedinih klijenata. Istodobno, korisnicima se pružaju konzultacije koje pomažu smanjiti vrijeme implementacije sustava i tehnologija, koristiti ih na najučinkovitiji način i poboljšati kvalifikacije osoblja.

Računalno podržani sustavi projektiranja - drugi, brzo razvijajući način izvođenja dizajnerskih radova.

Među računalnim metodama projektiranja posebno mjesto zauzimaju metode projektiranja modela. Stvaranje i uporaba CAD sustava osigurava dovoljno visoku razinu funkcionalne pouzdanosti, sveobuhvatno pokrivanje svih tehnoloških procesa, smanjenje intenziteta rada na projektima uz maksimalno uvažavanje interesa objekta automatizacije. Međutim, ova je metoda prilično skupa i zahtijeva visoko kvalificirane programere. Ključni zahtjev za CAD je sposobnost izgradnje i održavanja određenog globalnog ekonomskog informacijskog modela objekta automatizacije u sustavu projektiranja u odgovarajućem stanju. Model je eksplicitan prikaz informacijskih komponenti objekta automatizacije i odnosa među njima. Glavni cilj izgradnje modela je stvaranje AIS projekta koji odgovara ovom modelu, uzimajući u obzir i aktivno koristeći sve karakteristike objekta. Takav bi model trebao sadržavati u formaliziranom obliku opis skupova informacijskih komponenti i odnosa među njima, uključujući informacijske veze i algoritamsku interakciju. Metodom oblikovanja modela, sistemski pristup, koji određuje uporabu računala ne samo u svim fazama stvaranja sustava, već i u procesu analize rezultata njegovog industrijskog rada. Razvoj i primjena CAD -a predodredili su prijelaz na stvaranje individualni projekti, ali na znatno višoj razini od izvorne metode projektiranja.

Tijekom posljednjeg desetljeća pojavio se novi smjer u području automatizacije IC i IT dizajna - CASE računalno potpomognuta tehnologija razvoja softvera(SLUČAJ - Softver / Sistemsko inženjerstvo podržano računalom). Sve veća složenost informacijskih sustava, sve veći zahtjevi za njima doveli su do potrebe za industrijalizacijom tehnologija za njihovo stvaranje.

CASE tehnologija skup je metoda za analizu, projektiranje, razvoj i održavanje IS -a, podržanih skupom međusobno povezanih alata za automatizaciju. CASE je alat za analitičare sustava, programere i programere koji automatizira proces projektiranja i razvoja IC -a. CASE sustavi koriste se kao snažan alat za rješavanje istraživačkih i dizajnerskih problema, kao što su strukturna analiza predmetnog područja, provedba projekta korištenjem najnovije generacije programskih jezika, objavljivanje projektne dokumentacije, testiranje provedbe projekta, planiranje i kontrola razvoja, modeliranje poslovne aplikacije radi rješavanja operativnih problema. te strateško planiranje i upravljanje resursima itd.

Glavni cilj CASE -a je automatizirati razvoj i rad sustava što je više moguće.

Pri korištenju CASE-tehnologija mijenja se tehnologija rada u svim fazama životnog ciklusa automatiziranih sustava. U CASE sustavima dizajn se temelji na vizualnim vizualnim metodama razvoja, dok se grafikoni, dijagrami, tablice, dijagrami i tekstualna objašnjenja za njih koriste za opis modela projektiranog IS -a. Takve metodologije pružaju rigorozan i opisni opis sustava koji se projektira, koji počinje pregledom sustava, a zatim ide u više detalja, postajući hijerarhijska struktura sa sve većim brojem razina.

Automatizacija programiranja temelji se na automatskom generiranju programskih kodova koji sadrže opise podataka, glavnu logiku njihove obrade, sheme baze podataka, datoteke opisa sučelja itd. Kodovi se dodatno dorađuju i dorađuju, ali u nekim slučajevima automatizacija doseže 90%. Osim toga, tehnologija CASE generira potrebnu projektnu dokumentaciju spremnu za uporabu.

Prilikom korištenja CASE-tehnologije osigurava se podrška jedne projektne baze, tj. svi se podaci o razvijenom AIS -u automatski stavljaju u jedinstvenu bazu projekata. Time se održava dosljednost, dosljednost, potpunost i minimalna redundantnost podataka o projektu.

CASE-tehnologija omogućuje timski rad razvojnih timova, jer različite skupine stručnjaka imaju odgovarajuće alate, kao i mogućnost dosljednog i ispravnog mijenjanja projekta od strane različitih stručnjaka u stvarnom vremenu.

CASE tehnologije uspješno se koriste za izgradnju gotovo svih vrsta AIS -a. CASE se također koristi za stvaranje modela sustava koji komercijalnim strukturama pomažu riješiti probleme strateškog planiranja, financijskog upravljanja, utvrđivanja politike poduzeća, obuke osoblja itd.

CASE imaju sljedeće glavne prednosti:

Poboljšati kvalitetu stvorenog IS (IT) pomoću automatskog upravljanja (prije svega, kontrole projekta);

Dopustite u kratkom vremenu stvaranje prototipa budućeg IS -a (IT), koji vam omogućuje da brzo, u ranim fazama, procijenite očekivani rezultat;

Ubrzati proces projektiranja i razvoja sustava;

Oslobodite programera od rutinskog rada, dopuštajući mu da se u potpunosti koncentrira na kreativni dio dizajna;

Oni podržavaju razvoj i održavanje već funkcionalnog IS -a.

Do sada je formirana moćna CASE-industrija koja je ujedinila stotine tvrtki i tvrtki različitih usmjerenja. Među njima se ističu:

Tvrtke-programeri alata za analizu i dizajn IP i IT

Tvrtke-programeri posebnih alata s naglaskom na uska predmetna područja ili na pojedinačne faze životnog ciklusa IP-a;

Vježbeničke tvrtke koje organiziraju seminare i tečajeve za stručnjake;

Konzultantske tvrtke koje pružaju praktičnu pomoć u korištenju CASE paketa za razvoj specifičnih IS;

Tvrtke specijalizirane za izdavanje periodike i biltena o CASE tehnologijama.

Nbsp; Modeli životnog ciklusa AIS -a

Model životnog ciklusa AIS -a je struktura koja opisuje procese, radnje i zadatke koji se provode i tijekom razvoja, rada i održavanja tijekom cijelog životnog ciklusa sustava.

Odabir modela životnog ciklusa ovisi o specifičnostima, opsegu, složenosti projekta i skupu uvjeta u kojima se AIS stvara i djeluje.

Model životnog ciklusa AIS -a uključuje:

Rezultati rada u svakoj fazi;

Ključni događaji ili točke dovršetka i donošenja odluka.

U skladu s poznatim modelima životnog ciklusa softvera, određuju se modeli životnog ciklusa AIS -a - kaskadno, iterativno, spiralno.

I. Model slapa opisuje klasični pristup razvoju sustava u bilo kojem predmetnom području; naširoko se koristio 1970 -ih i 1980 -ih.

Model slapa predviđa sekvencijalnu organizaciju rada, a glavna značajka modela je podjela svih radova na faze. Prijelaz iz prethodne faze u sljedeću događa se tek nakon potpunog dovršetka svih radova prethodne.

Dodijeliti pet stabilne faze razvoja, praktički neovisne o predmetnom području (slika 1.1).

Na prvi U ovoj se fazi provodi proučavanje problematičnog područja, formuliraju se zahtjevi kupaca. Rezultat ove faze je projektni zadatak (razvojni zadatak), dogovoren sa svim zainteresiranim stranama.

Tijekom drugi pozornici, prema zahtjevima tehničkog zadatka, razvijaju se određena projektna rješenja. Kao rezultat toga, pojavljuje se skup projektne dokumentacije.

Treći faza - provedba projekta; u biti, razvoj softvera (kodiranje) u skladu s dizajnerskim odlukama prethodne faze. U ovom slučaju metode provedbe nisu od temeljne važnosti. Rezultat ove faze je gotov softverski proizvod.

Na četvrti U ovoj fazi se primljeni softver provjerava je li u skladu sa zahtjevima navedenim u projektnom zadatku. Probni rad omogućuje vam identificiranje različitih vrsta skrivenih nedostataka koji se pojavljuju u stvarnim uvjetima AIS -a.

Posljednja faza je predaja gotov projekt, a ovdje je najvažnije uvjeriti kupca da su svi njegovi zahtjevi u potpunosti ispunjeni.

Slika 1.1 Model životnog ciklusa AIS -a vodopada

Faze rada u okviru modela vodopada često se nazivaju dijelovima projektnog ciklusa AIS -a, budući da se faze sastoje od mnogih iterativnih postupaka za pojašnjenje zahtjeva sustava i mogućnosti projektiranja. Životni ciklus AIS -a mnogo je složeniji i duži: može uključivati ​​proizvoljan broj ciklusa pojašnjenja, izmjena i dopuna već usvojenih i implementiranih dizajnerskih rješenja. U tim se ciklusima odvija razvoj AIS -a i modernizacija njegovih pojedinih komponenti.

Prednosti kaskadnog modela:

1) u svakoj fazi formira se kompletan skup projektne dokumentacije koja zadovoljava kriterije potpunosti i dosljednosti. U posljednjim fazama razvija se korisnička dokumentacija koja pokriva sve vrste podrške AIS -a predviđene standardima (organizacijske, informacijske, softverske, tehničke itd.);

2) uzastopna provedba faza rada omogućuje vam planiranje vremena završetka i odgovarajućih troškova.

Model slapa izvorno je razvijen za rješavanje različitih vrsta inženjerskih problema i do sada nije izgubio značaj za primijenjeno područje. Osim toga, pristup vodopada idealan je za razvoj AIS -a, jer se već na samom početku razvoja svi zahtjevi mogu formulirati dovoljno točno kako bi se programerima omogućila sloboda tehničke implementacije. Takvi AIS-i osobito uključuju složene sustave poravnanja i sustave u stvarnom vremenu.

Nedostaci modela vodopada:

Značajno kašnjenje u dobivanju rezultata;

Pogreške i nedostaci u bilo kojoj fazi pojavljuju se, u pravilu, u sljedećim fazama rada, što dovodi do potrebe za povratkom;

Složenost paralelnog rada na projektu;

Prekomjerno zasićenje informacijama svake od faza;

Složenost upravljanja projektima;

Visoka razina rizika i nepouzdana ulaganja.

Kašnjenje u primanju rezultata očituje se u činjenici da se dosljedan pristup razvoju koordinacije rezultata s dionicima provodi tek nakon završetka sljedeće faze rada. Kao rezultat toga, može se ispostaviti da razvijeni AIS ne ispunjava zahtjeve, pa se takve nedosljednosti mogu pojaviti u bilo kojoj fazi razvoja; osim toga, greške mogu nenamjerno unijeti i dizajneri analitičara i programeri, budući da od njih nije potrebno dobro poznavanje predmetnih područja za koja se AIS razvija.

Vratite se na ranije faze. Ovaj nedostatak jedna je od manifestacija prethodne: korak po korak sekvencijalni rad na projektu može dovesti do činjenice da se pogreške učinjene u ranijim fazama otkrivaju tek u sljedećim fazama. Kao rezultat toga, projekt se vraća u prethodnu fazu, prerađuje i tek tada prenosi na sljedeći rad. To može dovesti do poremećaja u rasporedu i komplicirati odnos između razvojnih skupina koje izvode pojedine faze.

Najgora opcija je kada se nedostaci prethodne faze otkriju ne u sljedećoj fazi, već kasnije. Na primjer, u fazi probnog rada mogu se pojaviti pogreške u opisu predmetnog područja. To znači da se dio projekta mora vratiti u početnu fazu rada.

Složenost paralelnog rada povezano s potrebom koordinacije različitih dijelova projekta Što je jači odnos pojedinih dijelova projekta, to bi se sinkronizacija trebala provoditi češće i temeljitije, što su razvojni timovi međusobno ovisniji. Kao rezultat toga, prednosti paralelnog rada jednostavno se gube; nedostatak paralelizma negativno utječe na organizaciju rada cijelog tima.

Problem prezasićenost informacijama proizlazi iz snažne ovisnosti između različitih razvojnih skupina. Činjenica je da je prilikom izmjena jednog od dijelova projekta potrebno obavijestiti one programere koji su ga koristili (mogli koristiti) u svom radu. S velikim brojem međusobno povezanih podsustava, sinkronizacija interne dokumentacije postaje zaseban kritični zadatak: programeri se moraju stalno upoznavati s promjenama i procijeniti kako će te promjene utjecati na dobivene rezultate.

Složenost upravljanja projektima uglavnom zbog strogog slijeda razvojnih faza i prisutnosti složenih odnosa između različitih dijelova projekta. Uređeni slijed rada dovodi do činjenice da neki razvojni timovi moraju čekati rezultate rada drugih timova, stoga je potrebna administrativna intervencija radi dogovora o vremenu i sastavu dostavljene dokumentacije.

Ako se u radu otkriju pogreške, potrebno se vratiti na prethodne faze; dosadašnji rad onih koji su pogriješili je prekinut. Posljedica toga je obično kašnjenje u dovršenju kako ispravljenog tako i novog projekta.

Moguće je pojednostaviti interakciju među programerima i smanjiti preopterećenje dokumentacijom informacijama smanjenjem broja veza između pojedinih dijelova projekta, no ne može se svaki AIS podijeliti na labavo povezane podsustave.

Visoka razina rizika.Što je projekt složeniji, svaka faza razvoja traje duže i složenije su međusobne veze između pojedinih dijelova projekta, čiji se broj također povećava. Štoviše, razvojni se rezultati doista mogu vidjeti i ocijeniti tek u fazi ispitivanja, tj. Nakon završetka analize, projektiranja i razvoja - faze, za čiju provedbu je potrebno značajno vrijeme i novac.

Kasna evaluacija stvara ozbiljne probleme u identificiranju pogrešaka u analizi i dizajnu - morate se vratiti na prethodne faze i ponoviti razvojni proces. Međutim, povratak na prethodne faze može se povezati ne samo s pogreškama, već i s promjenama koje su se dogodile u predmetnom području ili u zahtjevima kupca tijekom razvoja. Istodobno, nitko ne jamči da se predmetna oblast neće ponovno promijeniti do trenutka kada sljedeća verzija projekta bude spremna. Zapravo, to znači da postoji vjerojatnost "petlje" razvojnog procesa: troškovi projekta stalno će rasti, a rokovi za isporuku gotovog proizvoda stalno se odgađaju.

II. Iteracijski model sastoji se u nizu kratkih ciklusa (koraka) planiranja, provedbe, proučavanja, djelovanja.

Izrada složenog AIS -a uključuje odobravanje projektnih rješenja dobivenih u provedbi pojedinih zadataka. Pristup dizajna odozdo prema gore zahtijeva takve iteracije povrata, kada se dizajnerska rješenja za pojedinačne zadatke kombiniraju u zajednička sustavna. Istodobno, postoji potreba za revizijom prethodno formiranih zahtjeva.

Prednost iterativni model je da međustupanjske prilagodbe omogućuju manje radno intenzivan razvoj u usporedbi s modelom vodopada.

nedostatke iterativni model:

· Vijek trajanja svake faze produljuje se za cijelo razdoblje rada;

· Zbog velikog broja ponavljanja postoje nedosljednosti u provedbi projektnih rješenja i dokumentacije;

· Zamršenost arhitekture;

· Poteškoće u korištenju projektne dokumentacije u fazama implementacije i rada zahtijevaju redizajn cijelog sustava.

III. Spiralni model, za razliku od kaskade, ali slično prethodnoj, uključuje iterativni proces razvoja AIS -a. Istodobno se povećava važnost početnih faza, poput analize i projektiranja, na kojima se provjerava i opravdava izvodljivost tehničkih rješenja stvaranjem prototipova.

Svaka iteracija predstavlja potpuni razvojni ciklus koji vodi do objavljivanja interne ili vanjske verzije proizvoda (ili podskupa konačnog proizvoda), koji se poboljšava od iteracije do iteracije kako bi postao cjelovit sustav (slika 1.2).

Riža. 1.2. Spiralni model životnog ciklusa AIS

Dakle, svaki zavoj spirale odgovara izradi fragmenta ili inačice softverskog proizvoda, na njemu se razjašnjavaju ciljevi i karakteristike projekta, utvrđuje njegova kvaliteta, planira se rad za sljedeći zavoj spirale. Svaka iteracija služi za produbljivanje i dosljednu konkretizaciju detalja projekta, zbog čega se odabire razumna opcija za konačnu provedbu.

Korištenje spiralnog modela omogućuje vam prelazak na sljedeću fazu projekta bez čekanja na potpuni završetak trenutne - nedovršeni radovi mogu se dovršiti na sljedećoj iteraciji. glavni zadatak svaka iteracija - stvorite radni proizvod za demonstraciju korisnicima što je prije moguće. Stoga je proces prilagodbi i dopuna projekta uvelike pojednostavljen.

Spiralni pristup razvoju softvera prevladava većinu nedostataka modela vodopada, osim toga, pruža niz dodatnih mogućnosti, čineći razvojni proces fleksibilnijim.

Prednosti iterativni pristup:

Ponavljajući razvoj uvelike pojednostavljuje unošenje promjena u projekt kada se promijene zahtjevi kupca;

Prilikom korištenja spiralnog modela, pojedini elementi AIS -a postupno se integriraju u jedinstvenu cjelinu. Budući da integracija počinje s manje elemenata, mnogo je manje problema u njezinoj provedbi;

Smanjenje razine rizika (posljedica prethodne prednosti, budući da se rizici otkrivaju upravo tijekom integracije). Razina rizika je maksimalna na početku razvoja projekta; kako razvoj napreduje, ona se smanjuje;

Iterativni razvoj pruža veću fleksibilnost u upravljanju projektima dopuštajući taktičke promjene proizvoda koji se razvija. Dakle, vrijeme razvoja možete skratiti smanjenjem funkcionalnosti sustava ili ga koristiti kao sastavni dijelovi proizvodi tvrtki trećih strana umjesto vlastitog razvoja (relevantni u tržišnom gospodarstvu, kada je potrebno oduprijeti se promicanju proizvoda konkurenata);

Iteracijski pristup olakšava ponovnu uporabu komponenti jer je puno lakše identificirati (identificirati) zajedničke dijelove projekta kada su već djelomično razvijeni nego ih pokušati izolirati na samom početku projekta. Analiza projekta nakon nekoliko početnih iteracija otkriva uobičajene komponente za višekratnu uporabu koje će se poboljšati u sljedećim iteracijama;

Spiralni model omogućuje pouzdaniji i stabilniji sustav. To je zbog činjenice da se tijekom evolucije sustava greške i slabosti otkrivaju i ispravljaju pri svakoj iteraciji. Istodobno se prilagođavaju kritični parametri izvedbe, koji su u slučaju modela vodopada dostupni samo prije implementacije sustava;

Ponavljajući pristup poboljšava proces
razvoj - kao rezultat analize na kraju svake iteracije provodi se procjena promjena u razvojnoj organizaciji; poboljšava se pri sljedećoj iteraciji.

Glavni problem spiralnog ciklusa- poteškoće pri određivanju trenutka prijelaza u sljedeću fazu. Da bi se to riješilo, potrebno je uvesti vremenska ograničenja za svaku fazu životnog ciklusa. U protivnom se razvojni proces može pretvoriti u beskrajno poboljšanje onoga što je već učinjeno.

Uključivanje korisnika u proces projektiranja i kopiranja aplikacije omogućuje vam primanje komentara i dopuna zahtjeva izravno u procesu projektiranja aplikacije, čime se skraćuje vrijeme razvoja. Predstavnici kupaca imaju priliku kontrolirati proces stvaranja sustava i utjecati na njegov funkcionalni sadržaj. Rezultat je puštanje u rad sustava koji uzima u obzir većinu potreba kupaca.

Dostavljene su suvremene metodologije i tehnologije projektiranja AIS -a koje ih primjenjuju u elektroničkom formatu zajedno s CASE-alatima i uključuju biblioteke procesa, predložaka, metoda, modela i drugih komponenti namijenjenih izgradnji softvera klase sustava na koju je metodologija usmjerena. Elektroničke metodologije i tehnologije čine jezgru niza dogovorenih alata razvoj AIS -a. Značajke suvremenih metodoloških rješenja za projektiranje AIS -a ne mogu se implementirati bez određenih tehnologija projektiranja koje odgovaraju opsegu i specifičnostima projekta.

AIS tehnologija projektiranja je skup metoda i alata za projektiranje AIS -a, kao i metoda i alata za organizaciju projektiranja (upravljanje procesom izrade i modernizacije AIS projekta).

Prema dizajnu TP-a, AIS je skup uzastopno-paralelnih, povezanih i podređenih lanaca djelovanja, od kojih svaki može imati svoj predmet. Radnje koje se izvode pri projektiranju AIS-a mogu se definirati kao nedjeljive tehnološke operacije ili kao podprocesi tehnoloških operacija. Sve radnje mogu biti ispravne oblikovati, oblikovati ili mijenjati rezultate dizajna, i procijenjeno, koji su razvijeni prema utvrđenim kriterijima za ocjenjivanje rezultata projektiranja.

Dakle, tehnologija projektiranja postavljena je reguliranim nizom tehnoloških operacija koje se izvode u procesu izrade projekta na temelju određene metode.

Predmet odabrane tehnologije projektiranja trebao bi biti odraz međusobno povezanih procesa projektiranja u svim fazama životnog ciklusa AIS -a.

Glavni zahtjevi za odabranu tehnologiju projektiranja su sljedeći:

· Projekt nastao uz pomoć ove tehnologije mora zadovoljiti zahtjeve kupca;

· Tehnologija bi trebala što je više moguće odražavati sve faze životnog ciklusa projekta;

· Tehnologija bi trebala osigurati minimalne troškove rada i troškove za projektiranje i podršku projektima;

· Tehnologija bi trebala pridonijeti rastu produktivnosti rada dizajnera;

· Tehnologija bi trebala osigurati pouzdanost dizajna i rada projekta;

· Tehnologija bi trebala olakšati jednostavno održavanje projektne dokumentacije.

AIS tehnologija projektiranja implementira posebnu metodologiju projektiranja. Zauzvrat, metodologija projektiranja pretpostavlja prisutnost nekog koncepta, načela projektiranja i provodi se skupom metoda i alata.

AIS metode projektiranja mogu se klasificirati prema stupnju korištenja alata za automatizaciju, tipičnim projektnim rješenjima, prilagodljivosti predviđenim promjenama.

Prema stupnju automatizacije razlikuju se:

ručni dizajn, u kojem se projektiranje AIS komponenti provodi bez upotrebe posebnih softverskih alata; programiranje se vrši na algoritamskim jezicima;

dizajn računala, u kojem se generiranje ili konfiguracija (ugađanje) dizajnerskih rješenja provodi pomoću posebnih softverskih alata.

Prema stupnju uporabe tipičnih dizajnerskih rješenja razlikuju se:

original (pojedinačno) dizajn, kada se dizajnerska rješenja razvijaju „od nule“ u skladu sa zahtjevima za AIS;

tipičan dizajn, pretpostavljajući konfiguraciju AIS-a iz gotovih standardnih dizajnerskih rješenja (softverski moduli).

Originalni dizajn AIS pretpostavlja maksimalno razmatranje značajki automatiziranog objekta.

Tipičan dizajn izvedena na temelju gotova rješenja i generalizacija je iskustva stečenog ranije u stvaranju povezanih projekata.

Po stupnju prilagodljivosti projektnih rješenja razlikuju se sljedeće metode:

rekonstrukcija- prilagodba projektnih rješenja provodi se obradom odgovarajućih komponenti (reprogramiranje programskih modula);

parametrizacija- projektna rješenja prilagođena su u skladu sa navedenim i promjenjivim parametrima;

restrukturiranje modela- mijenja se model predmetnog područja, što dovodi do automatske reforme dizajnerskih rješenja.

Kombinacija različitih značajki klasifikacije metoda projektiranja određuje prirodu korištene tehnologije projektiranja AIS -a. Postoje dvije glavne klase tehnologije dizajna: kanonski i industrijski... Tehnologija industrijskog dizajna podijeljena je u dvije potklase: automatizirano(korištenje CASE tehnologija) i tipično(parametarski ili model orijentirano) projektiranje.

Tablica 1.1.Karakteristike klasa tehnologije projektiranja

Kanonski AIS dizajn usredotočuje se na korištenje uglavnom modela vodopada u životnom ciklusu AIS -a.

Ovisno o složenosti objekta automatizacije i skupu zadataka koje je potrebno riješiti pri izradi određenog AIS -a, faze i faze rada mogu imati različit intenzitet rada. Dopušteno je kombinirati uzastopne faze i isključiti neke od njih u bilo kojoj fazi projekta. Također je dopušteno započeti rad sljedeće faze prije završetka prethodne.

Faze i faze stvaranja AIS -a, koje izvode organizacije sudionice, propisane su ugovorima i projektnim zadatkom za obavljanje posla.

Faza 1. Formiranje zahtjeva za AIS:

· Pregled objekta i opravdanost potrebe za stvaranjem AIS -a;

· Formiranje korisničkih zahtjeva za AIS;

· Priprema izvješća o obavljenom poslu i taktičko -tehničkog zadatka za razvoj.

Faza 2. Razvoj AIS koncepta:

· Proučavanje objekta automatizacije;

· Izvođenje potrebnog istraživačkog rada;

· Razvoj opcija za koncept AIS -a, koji zadovoljava zahtjeve korisnika;

· Priprema izvješća i odobravanje koncepta.

Faza 3. Tehnički zadatak:

Razvoj i odobrenje tehničkih specifikacija za izradu AIS -a.

Faza 4. Idejno rješenje:

· Izrada idejnih rješenja sustava i njegovih dijelova;

· Izrada okvirne dokumentacije za AIS i njegove dijelove.

Faza 5. Tehnički projekt:

· Razvoj dizajnerskih rješenja za sustav i njegove dijelove;

· Izrada dokumentacije za AIS i njegove dijelove;

· Izrada i izvršenje dokumentacije za opskrbu komponentama;

· Izrada projektnih zadataka u srodnim dijelovima projekta.

Faza 6. Radna dokumentacija:

· Izrada radne dokumentacije za AIS i njegove dijelove;

· Razvoj i prilagodba programa.

Faza 7. Puštanje u rad:

· Priprema objekta automatizacije; Obučavanje zaposlenika;

· Kompletan set proizvoda isporučenih AIS -om (softverski i hardverski, softverski i hardverski kompleksi, informacijski proizvodi);

· Građevinsko -instalacijski radovi; puštanje u rad;

· Provođenje preliminarnih ispitivanja;

· Provođenje probnog rada;

· Provođenje prijemnih testova.

Faza 8. AIS pratnja:

· Izvođenje radova u skladu s jamstvenim obvezama;

· Usluga nakon jamstva.

Pregled- je proučavanje i analiza organizacijske strukture poduzeća, njegovih aktivnosti i postojećeg sustava obrada informacija.

Materijali dobiveni rezultatom istraživanja koriste se za:

Obrazloženje za razvoj i postupnu provedbu sustava;

Izrada tehničkih specifikacija za razvoj sustava;

Razvoj tehničkih i radnih projekata sustava.

U fazi istraživanja preporučljivo je razlikovati dvije komponente: definiranje strategije provedbe AIS -a i detaljnu analizu aktivnosti organizacije.

Glavni zadatak prve faze istraživanja je procijeniti stvarni obujam projekta, njegove ciljeve na temelju identificiranih funkcija i informacijskih elemenata automatiziranog objekta na visokoj razini. Ove zadatke može izvršiti ili kupac AIS -a samostalno ili uz uključivanje konzultantskih organizacija. Ova faza uključuje blisku interakciju s glavnim potencijalnim korisnicima sustava i poslovnim stručnjacima. Glavni zadatak interakcije je potpuno i nedvosmisleno razumijevanje zahtjeva kupaca. U pravilu se potrebne informacije mogu dobiti putem intervjua, razgovora ili radionica s menadžmentom, stručnjacima i korisnicima.

Po završetku faze istraživanja postaje moguće utvrditi vjerojatne tehničke pristupe stvaranju sustava i procijeniti troškove njegove implementacije (za hardver, za kupljeni softver i za razvoj novog softvera).

Rezultat faze definiranja strategije je dokument (studija izvedivosti - studija izvedivosti - projekt), gdje je jasno formulirano što će kupac dobiti ako pristane financirati projekt, kada primi gotov proizvod (raspored rada) i kako mnogo će to koštati (za velike projekte - ovo je raspored financiranja u različitim fazama rada). Poželjno je u dokumentu odraziti ne samo troškove, već i prednosti projekta, na primjer, vrijeme povrata projekta, očekivano ekonomski učinak(ako se može ocijeniti).

Ograničenja, rizici, kritični čimbenici koji mogu utjecati na uspjeh projekta;

Skup uvjeta pod kojima bi budući sustav trebao funkcionirati - arhitektura sustava, hardverski i softverski resursi, radni uvjeti, uslužno osoblje i korisnici sustava;

Uvjeti završetka pojedinih faza, oblik prihvaćanja / isporuke rada, uključeni resursi, mjere za zaštitu informacija;

Opis funkcija koje sustav obavlja;

Prilike za razvoj i modernizaciju sustava;

Sučelja i raspodjela funkcija između osobe i sustava;

zahtjevi za softver i sustave za upravljanje bazama podataka (DBMS).

U fazi detaljne analize aktivnosti organizacije proučavaju se aktivnosti koje osiguravaju provedbu upravljačkih funkcija, organizacijska struktura, osoblje i sadržaj rada na upravljanju poduzećem, kao i prirodu podređenosti višim tijelima upravljanja. Ovdje je potrebno ocrtati poučno-metodološke i smjerničke materijale, na temelju kojih se utvrđuje sastav podsustava i popis zadataka, kao i mogućnost korištenja novih metoda rješavanja problema.

Analitičari prikupljaju i bilježe informacije u dva međusobno povezana oblika:

Funkcije - informacije o događajima i procesima koji se događaju u automatiziranoj organizaciji;

Entiteti - Podaci o klasama objekata koji su relevantni za organizaciju i o kojima se prikupljaju podaci.

Prilikom proučavanja svakog zadatka funkcionalne kontrole utvrđuje se sljedeće:

Naziv zadatka; uvjete i učestalost donošenja odluke;

Stupanj formalizacije problema;

Izvori informacija potrebni za rješavanje problema;

Pokazatelji i njihove kvantitativne karakteristike;

Postupak ispravljanja informacija;

Operativni algoritmi za izračunavanje pokazatelja i moguće metode upravljanja;

Postojeći načini prikupljanja, prijenosa i obrade informacija;

Postojeća sredstva komunikacije;

Prihvaćena točnost rješenja problema;

Složenost rješavanja problema;

Postojeći oblici predstavljanja početnih podataka i rezultata njihove obrade u obliku dokumenata;

Potrošači dobivenih informacija o zadatku.

Jedan od najtežih, iako dobro formaliziranih zadataka ove faze je opis tijeka rada organizacije. Prilikom ispitivanja tijeka rada sastavlja se dijagram puta kretanja dokumenata koji treba odražavati:

Broj dokumenata;

Mjesto formiranja pokazatelja dokumenata;

Odnos dokumenata tijekom njihovog formiranja;

Ruta i trajanje kretanja dokumenta;

Mjesto korištenja i skladištenja ovog dokumenta;

Interne i vanjske informacijske komunikacije;

Volumen dokumenta u znakovima.

Na temelju rezultata istraživanja utvrđuje se popis zadataka upravljanja I koje treba automatizirati i slijed njihova razvoja.

Tijekom faze istraživanja planirane funkcije sustava treba klasificirati prema njihovoj važnosti. Jedan od mogućih formata za predstavljanje takve klasifikacije je MuSCoW. Ova kratica znači: Mora imati - potrebne funkcije; Trebali bi imati - željene funkcije; Mogu imati - I moguće funkcije; Neće imati značajke koje nedostaju.

Funkcije prve kategorije pružaju kritične vrijednosti za I. uspješan rad mogućnosti sustava. Provedba funkcija druge i treće kategorije ograničena je vremenskim i financijskim okvirom: razvija se potreban, kao i maksimalno moguć, prema prioritetu, broj funkcija druge i treće kategorije. Posljednja kategorija funkcija posebno je važna jer je potrebno jasno razumjeti granice projekta I i skup funkcija koje će izostati u sustavu.

Modeli organizacijskih aktivnosti stvoreni su u dvije vrste 1:

Model “kakav jest” - odražava poslovne procese koji postoje u organizaciji;

Model “biti” odražava potrebne promjene u poslovnim procesima, uzimajući u obzir uvođenje AIS -a. j

Već u fazi analize potrebno je uključiti ispitnu skupinu u rad radi rješavanja sljedećih zadataka:

Dobivanje usporednih karakteristika hardverskih platformi, operativnih sustava, DBMS -a itd .;

Izrada plana rada kako bi se osigurala pouzdanost AIS -a i njegovo ispitivanje.

Angažiranje testera u ranoj fazi razvoja dobra je ideja za svaki projekt. Što se kasnije otkriju pogreške u dizajnerskim rješenjima, skuplje ih je popraviti; najgori scenarij je njihovo otkrivanje tijekom faze provedbe. Stoga, što prije timovi za testiranje počnu identificirati pogreške u AIS -u, niži su troškovi rada na sustavu. Vrijeme za testiranje sustava i ispravljanje otkrivenih pogrešaka treba osigurati ne samo u fazi razvoja, već i u fazi projektiranja.

Posebni sustavi za praćenje grešaka osmišljeni su kako bi olakšali i povećali učinkovitost testiranja. Njihova uporaba omogućuje vam da imate jedno spremište pogrešaka, pratite njihovo ponavljanje, kontrolirate brzinu i učinkovitost ispravljanja grešaka, vidite najnestabilnije komponente sustava, a također i održavate komunikaciju između razvojnog tima i tima za testiranje.

Rezultati istraživanja predstavljaju objektivnu osnovu za formiranje tehničkih specifikacija za AIS.

Tehnički zadatak Dokument je koji definira ciljeve, zahtjeve i osnovne početne podatke potrebne za razvoj automatiziranog sustava upravljanja.

Prilikom izrade tehničkog zadatka (TOR) potrebno je riješiti sljedeće zadatke:

· Uspostaviti opću svrhu stvaranja AIS -a;

· Uspostaviti opće zahtjeve za projektirani sustav;

· Razviti i potkrijepiti zahtjeve za informacijsku, matematičku, softversku, hardversku i tehnološku podršku;

· Odrediti sastav podsustava i funkcionalne zadatke;

· Razviti i opravdati zahtjeve za podsustave;

· Odrediti faze stvaranja sustava i vrijeme njihove implementacije;

Napravite preliminarni izračun troškova stvaranja sustava i odredite razinu ekonomsku učinkovitost provedba;

· Utvrditi sastav izvođača.

Tipični zahtjevi za sastav i sadržaj tehničkih specifikacija dati su u tablici. 1.6.

Tabblitsa 1.6. Sastav i sadržaj tehničkog zadatka (GOST 34.602-89)

Ekskluzivni projekt predviđa razvoj idejnih rješenja sustava i njegovih dijelova. Idejni projekt nije strogo obvezna faza. Ako su glavna projektna rješenja definirana ranije ili su dovoljno očita za određeni AIS i objekt automatizacije, tada se ova faza može isključiti iz općeg slijeda radova.

AIS funkcije;

Funkcije podsustava, njihovi ciljevi i očekivani učinak implementacije;

Sastavljanje skupova zadataka i pojedinačnih zadataka;

Koncept informacijske baze i njegova proširena struktura;

Funkcije sustava upravljanja bazom podataka;

Sastav računalnog sustava i drugih tehničkih sredstava;

Funkcije i parametri glavnog softvera.

Na temelju rezultata obavljenog posla izrađuje se, usuglašava i odobrava dokumentacija u količini potrebnoj za opisivanje cijelog niza usvojenih projektnih odluka i dovoljnoj za daljnji rad na stvaranju sustava.

U skladu s GOST 19.102-77, faza idejnog projektiranja sadrži dvije faze: razvoj idejnog projekta; odobrenje nacrta projekta.

Prva faza razvoja sastoji se od:

Preliminarni razvoj strukture ulaznih i izlaznih podataka;

Usavršavanje metoda za rješavanje problema;

Izrada općeg opisa algoritma za rješavanje problema;

Izrada studije izvedivosti;

Izrada objašnjenja.

U tom je slučaju dopušteno kombinirati i isključiti neka djela.

Dolje je skup dokumenata koje treba i može pripremiti na kraju nacrta skice.

Obavezni dokumenti:

1) ažurirani projektni zadatak za projektiranje i razvoj
rad AIS -a;

2) specifikaciju kvalifikacijskih zahtjeva za AIS;

3) skup specifikacija zahtjeva za funkcionalne softverske komponente i opise podataka;

4) specifikaciju zahtjeva za unutarnja sučelja komponente i sučelja s vanjskim okruženjem;

5) opis sustava za upravljanje bazom podataka, strukturu i distribuciju softvera i informacijskih objekata u bazi podataka;

6) nacrt smjernica za zaštitu informacija i osiguravanje pouzdanosti funkcioniranja AIS -a;

7) preliminarnu verziju priručnika za administratora AIS -a;

8) preliminarnu verziju korisničkog priručnika AIS -a;

9) revidirani plan provedbe projekta;

10) poboljšani plan upravljanja osiguranjem kvalitete AIS -a;

11) objašnjenje prednacrta AIS -a;

12) revidirani ugovor (sporazum) s kupcem za pojedinosti-
novi dizajn AIS -a.

Dokumenti sastavljeni u dogovoru s kupcem:

1) preliminarni opis funkcioniranja AIS -a;

2) dijagram protoka podataka između funkcionalnih komponenti AIS -a;

3) precizni dijagram AIS arhitekture, interakcija softvera i informacijskih komponenti, organizacija računalnog procesa i raspodjela resursa;

4) opis pokazatelja kvalitete komponenti i zahtjeva za njih po fazama razvoja AIS -a;

5) izvješće o tehničkim i ekonomskim pokazateljima, rasporedu provedbe projekta, raspodjeli sredstava i proračunu;

6) tablicu raspodjele stručnjaka po komponentama i fazama rada;

7) potvrde programera za pravo korištenja tehnologije i alata za automatizaciju za razvoj AIS -a;

8) opis zahtjeva za sastav i oblike nastalih dokumenata po fazama rada;

9) plan za otklanjanje pogrešaka programskih komponenti, pružajući mu metode i alate za automatizaciju ispitivanja;

10) preliminarne smjernice za izradu glavnog projekta
vaniya, programiranje i ispravljanje pogrešaka AIS komponenti;

11) preliminarni plan prodaje i provedbe;

12) opis preliminarne strukture baze podataka.

Tehnički projekt sustavi su tehnička dokumentacija koja sadrži cjelokupna projektna rješenja, algoritme za rješavanje problema, kao i procjenu ekonomske učinkovitosti AIS-a. U ovoj fazi provodi se kompleks istraživačkog i eksperimentalnog rada za odabir glavnih projektnih rješenja i izračun ekonomsku učinkovitost sustava. Sastav i sadržaj tehničkog projekta dati su u tablici. 1.7

Tablica 1.7. Sadržaj tehničkog projekta

U fazi "Radna dokumentacija" izrađuje se softverski proizvod i razvija sva prateća dokumentacija. Dokumentacija bi trebala sadržavati sve potrebne i dovoljne podatke kako bi se osiguralo obavljanje poslova pri puštanju u rad AIS -a i njezinog rada, kao i da bi se održala razina operativnih karakteristika (kvaliteta) sustava. Izrađena dokumentacija mora biti pravilno sastavljena, dogovorena i odobrena.

U fazi "Puštanje u rad" za AIS utvrđuju se sljedeće glavne vrste ispitivanja: preliminarna ispitivanja, probni rad i prijemni testovi. Ako je potrebno, dopušteno je dodatno provesti druge vrste ispitivanja sustava i njegovih dijelova.

Ovisno o odnosu između komponenti AIS -a i objekta automatizacije, testovi mogu biti autonomni i složeni. Komponente sustava uključene su u autonomno testiranje. Provode se čim dijelovi sustava budu spremni za puštanje u rad. Složena ispitivanja provode se za skupine međusobno povezanih komponenti (podsustava) ili za sustav u cjelini.

Za planiranje provođenja svih vrsta ispitivanja razvija se dokument "Program i metodologija ispitivanja". Proizvođač dokumenta utvrđen je ugovorom ili TK. Testovi ili testni slučajevi mogu se uključiti u dokument kao privitak.

Otklanjanje pogrešaka je proces dizajna koji oduzima najviše vremena. Skrivene greške ponekad se pojavljuju nakon mnogo godina rada sustava. Nemoguće je potpuno izbjeći pogreške, što je posljedica astronomskog broja mogućnosti rada sustava. Gotovo je nemoguće u dogledno vrijeme provjeriti ispravnost svih njih.

Cijena identificiranja i uklanjanja pogrešaka u kasnijim fazama projektiranja povećava se približno eksponencijalno (slika 1.10).

Istraživači broje 169 vrsta pogrešaka sažetih u 19 velikih klasa:

1) logično;

2) pogreške u manipulaciji podacima;

3) I / O pogreške;

4) pogreške u izračunima;

Riža. 1.10. Relativni trošak otkrivanja i ispravljanja jedne pogreške

5) pogreške u korisničkim sučeljima;

6) pogreške u operacijskom sustavu i pomoćnim programima;

7) pogreške u izgledu;

8) pogreške u međuprogramskim sučeljima;

9) pogreške u sučeljima "Program - softver sustava";

10) pogreške pri rukovanju vanjskim uređajima;

11) greške u povezivanju s bazom podataka (DB);

12) pogreške pri pokretanju baze podataka;

13) pogreške izmjena na zahtjev izvana;

14) pogreške povezane s globalnim varijablama;

15) greške koje se ponavljaju;

16) greške u dokumentaciji;

17) povreda tehničkih zahtjeva;

18) neprepoznate greške;

19) pogreške operatora.

Ne dolaze svi bugovi od razvojnog programera. Prema različitim istraživačima, od 6 do 19% pogrešaka uzrokovano je pogreškama u dokumentaciji.

Odnos između razvoja i testiranja u različitim fazama projektiranja AIS -a prikazan je na Sl. 1.11.

Taj je lanac samo uvjetno "rastegnut" u liniju. Unutar njega uvijek postoje ponavljajuće se petlje. Kako bi identificirali pogreške, programeri izrađuju posebne testove i provode fazu otklanjanja pogrešaka. Ako se ne pronađu pogreške, to ne znači da ih nema - možda se test pokazao preslabim.

Riža. 1.11. Korelacija između razvoja i testiranja po fazama projektiranja AIS -a

Tehnika otklanjanja pogrešaka uzima u obzir simptome mogućih pogrešaka:

Netočna obrada (pogrešan odgovor, rezultat) - do 30%;

Pogrešan prijenos kontrole - 16%;

Neusklađenost programa s korištenim podacima - 15%;

Nekompatibilnost programa za prijenos podataka - do 9%.

Prilikom razvoja zadataka za otklanjanje pogrešaka rješavaju se sljedeći zadaci:

Pisanje testova;

Odabir točaka, zona i kontrolnih ruta;

Određivanje popisa kontroliranih količina i postupak utvrđivanja njihovih vrijednosti;

Postavljanje redoslijeda testiranja;

Procjena pouzdanosti i složenosti otklanjanja pogrešaka.

Program na kojem se uklanja pogreške mora barem jednom proći kroz svaku granu algoritma i istovremeno dodijeliti niz vrijednosti varijablama, hvatajući granice raspona, nekoliko vrijednosti unutar njega, nulte vrijednosti i pojedinačne točke (ako ih ima). Za specijalizirane sustave razvijeni su posebni jezici za otklanjanje pogrešaka. Mogu sadržavati relativno mali broj naredbi (20-30) s dodatnim parametrima ugađanja za rješavanje sljedećih zadataka:

Kontrola povlačenja;

Modeliranje procesa izvođenja programa na kojem se otklanjaju pogreške;

Izdavanje stanja memorijskih komponenti tijekom izvođenja programa;

Provjera uvjeta za postizanje određenih stanja u procesu izvođenja programa;

Utvrđivanje testnih vrijednosti početnih podataka;

Provedba uvjetnih skokova u testiranju, ovisno o rezultatima izvršavanja drugih makronaredbi ili različitih testova;

Izvođenje uslužnih radnji za pripremu programa za testiranje.

Postupak otklanjanja pogrešaka ne može se klasificirati kao potpuno formaliziran, stoga postoje empirijske preporuke za njegovo provođenje, koje su navedene u nastavku.

1. Upotrijebite semantički, unaprijed osmišljen pristup otklanjanju pogrešaka, planirajte proces otklanjanja pogrešaka i pažljivo dizajnirajte skupove podataka za testiranje iz najjednostavnijih mogućih opcija, uklanjajući najvjerojatnije izvore pogrešaka.

2. Prikupiti i analizirati informacije radi pojednostavljenja procesa testiranja:

Značajke i statistika pogrešaka;

O specifičnostima početnih podataka i slijedu mijenjanja varijabli u programu te njihovom međusobnom utjecaju;

O strukturi algoritma i značajkama njegove programske implementacije.

3. Locirajte samo jednu pogrešku odjednom.

Upotrijebite sredstva zapisivanja i prikaza podataka o pogreškama, uključujući u program poseban kod za otklanjanje pogrešaka za ispis uzorkovanih vrijednosti varijabli, poruka o završetku pojedinih odjeljaka programa, praćenje, logičke uvjete itd.

5. Pažljivo proučite rezultirajući rezultat i usporedite ga s očekivanim, unaprijed izračunatim rezultatima.

6. Obratite pozornost na podatke, pažljivo analizirajte rad programa pri korištenju graničnih vrijednosti i pri pogrešnom unosu; upravljati vrstama podataka, rasponima, veličinama polja i preciznošću.

7. Upotrijebite analizu tijeka podataka i kontrole tijeka za provjeru valjanosti i utvrđivanje opsega podataka za različite putove izvođenja programa.

8. Upotrebljavajte razne alate za ispravljanje pogrešaka istovremeno, bez zadržavanja na jednoj mogućnosti. Upotrebljavajte automatizirane alate i ručno ispravljanje pogrešaka i testiranje istovremeno, provjeravajući izvedbu programskog koda, uzimajući u obzir najvjerojatnije pogreške.

9. Dokumentirajte sve pronađene i ispravljene greške, njihove razlike, mjesto i vrstu. Ove će informacije biti korisne za sprečavanje budućih pogrešaka.

10. Izmjerite složenost programa. U programima s velikom složenošću postoji velika vjerojatnost grešaka u specifikacijama i dizajnu, a s malom složenošću, kodiranja i greške u pisanju.

11. Za povećanje iskustva i prakse u ispravljanju pogrešaka umjetno postavljajte pogreške u programe. Nakon određenog razdoblja otklanjanja pogrešaka, programer bi trebao ukazati na sve preostale pogreške koje nije pronašao. Takvo se "zasijavanje" naširoko koristi za procjenu broja neotkrivenih pogrešaka (ako se umjetne i stvarne pogreške jednoliko otkriju i isprave, tada se postotak unesenih unesenih grešaka i stvarnih pogrešaka može koristiti za predviđanje koliko ih je ostalo).

Provode se prethodna ispitivanja radi utvrđivanja operativnosti sustava i rješavanja pitanja mogućnosti njegova prihvaćanja u probni rad. Preliminarna ispitivanja trebala bi se provesti nakon što je programer otklonio greške i testirao isporučeni softver i hardver sustava i dostavio relevantne dokumente o njihovoj spremnosti za testiranje, kao i nakon što se osoblje AIS -a upoznalo s operativnom dokumentacijom.

Probni rad sustava provodi se radi utvrđivanja stvarnih vrijednosti kvantitativnih i kvalitativnih karakteristika sustava i spremnosti osoblja za rad u uvjetima njegova funkcioniranja, kao i radi utvrđivanja stvarne učinkovitosti i prilagođavanja , ako je potrebno, dokumentaciju.

Ispitivanja prihvatljivosti provode se radi utvrđivanja sukladnosti sustava s tehničkim specifikacijama, procjene kvalitete probnog rada i rješavanja pitanja mogućnosti prihvaćanja sustava u stalni rad.

Pošaljite svoj dobar rad u bazu znanja je jednostavno. Koristite donji obrazac

Studenti, diplomirani studenti, mladi znanstvenici koji koriste bazu znanja u studiju i radu bit će vam zahvalni.

Objavljeno na http://www.allbest.ru/

Ministarstvo obrazovanja i znanosti Ruska Federacija

Savezni državni proračun obrazovna ustanova visoko stručno obrazovanje

Državno sveučilište za tehnologiju i dizajn u Sankt Peterburgu

Rad na predmetu

Po disciplinama: "Arhitektura informacijskih sustava"

Na temu: "Projektiranje automatiziranih informacijskih sustava"

UVOD

Trenutno je računalna tehnologija sve raširenija kako u proizvodnji tako i u tijeku rada poduzeća, a popis zadataka koji su njome obuhvaćeni postaje sve širi. Obujam i složenost informacija koje se obrađuju neprestano rastu, a potrebne su i nove vrste njihovog prezentiranja.

Evo samo nekoliko prednosti korištenja računalstva za organizaciju:

* Mogućnost operativne kontrole točnosti informacija;

* Smanjenje broja mogućih pogrešaka pri generiranju izvedenih podataka;

* Sposobnost brzog pristupa svim podacima;

* Sposobnost brzog generiranja izvješća;

* Ušteda troškova rada i vremena provedenog na obradi informacija.

Sve ove prednosti trenutno cijene mnoge organizacije, stoga danas postoji proces brzog razvoja automatiziranih informacijskih sustava i njihove implementacije u rad različitih institucija. S tim u vezi, tema koju sam odabrao trenutno je vrlo relevantna.

Glavna značajka industrije sustava za automatizaciju za različita poduzeća i ustanove, koju karakterizira širok raspon ulaznih podataka s različitim putevima za obradu tih podataka, je koncentracija složenosti u početnim fazama analize zahtjeva i projektiranja specifikacija sustava sa relativno niska složenost i intenzitet rada sljedećih faza. Zapravo, tu se događa razumijevanje onoga što će budući sustav učiniti i kako će funkcionirati kako bi zadovoljio zahtjeve koji se pred njega postavljaju. Naime, neodređenost i nedovršenost zahtjeva sustava, neriješena pitanja i pogreške učinjene u fazama analize i projektiranja rađaju teške, često nerješive probleme u sljedećim fazama i, u konačnici, dovode do neuspjeha čitavog djela u cjelini. Jednostavna replikacija čak i vrlo dobrog sustava upravljanja poduzećem nikada neće u potpunosti odgovarati kupcu jer ne može uzeti u obzir njegove specifičnosti. Štoviše, u ovom slučaju javlja se problem odabira upravo sustava koji je najprikladniji za određeno poduzeće. Ovaj problem dodatno komplicira činjenica da su ključne riječi koje karakteriziraju različite informacijske sustave praktički iste:

* Jedinstveno informacijsko okruženje poduzeća;

* Način rada u stvarnom vremenu;

* Nezavisnost od zakona;

* Integracija s drugim aplikacijama (uključujući sustave koji već rade u poduzeću);

* Postupna implementacija itd.

Zapravo, problem složene automatizacije postao je relevantan za svako poduzeće. A za kompleksnu automatizaciju potrebno vam je strukturirano znanje iz ovog područja.

Svrha ovog rada: Upoznati se s konceptom automatiziranih informacijskih sustava, razmotriti proces projektiranja.

Za postizanje cilja potrebno je riješiti sljedeće zadatke:

§ Formulirati definicije osnovnih pojmova i pojmova;

§ Uzmite u obzir ciljeve dizajna;

§ Upoznajte se s glavnim fazama projektiranja;

§ Istaknuti faze razvoja automatiziranih informacijskih sustava;

§ Uzmite u obzir sastav i strukturu tehničkog zadatka i tehničkog projekta.

1. DEFINICIJA POJMOVA AUTOMATIZIRANI INFORMACIJSKI SUSTAV (AIS), INFORMACIJSKI SUSTAV (IS), PROJEKT I DIZAJN

Prilikom strukturiranja procesa u području ljudske djelatnosti koriste se različite metode izdvajanja komponenti (podprocesa) i dobivaju se različiti rezultati, poput istraživanja i razvoja, analize i sinteze itd.

Dizajn je sasvim prihvatljivo smatrati generalizirajućim konceptom za mnoge intelektualne zadatke koji se rješavaju u procesu razmišljanja i razlikuju na različite načine.

Korijen riječi dizajn naglašava vezu između procesa koji ima takav naziv i glavnih rezultata ovog procesa, kako slijedi:

a) projekcija - ono što se dobiva analizom složenih pojava radi dobivanja pojednostavljenih prikaza, i

b) projekt - ono što se dobiva sintezom složenih prikaza iz skupa jednostavnijih slika.

Gore navedena dva razloga poslužila su kao obrazloženje za trenutni odabir riječi dizajn kao izraza koji označava bit glavne aktivnosti koja se provodi u informatici.

U projektiranju informacijskih sustava, informacijski sustavi su objekti dizajna, a to je za informatiku sasvim prirodno (budući da se IS smatraju njenim glavnim objektima).

Kao što znate, informacijski sustavi mogu prikazati u sebi najrazličitije pojave svemira, pa se stoga svi fenomeni također ispostavljaju kao potencijalni objekti dizajna.

Informacijski sustavi u mnogim slučajevima ispadaju predmetima projektiranja, tj. oni izvođači koji provode sam proces projektiranja. Proučavajući proces projektiranja time smo uvelike angažirani u istraživanju informacijskih sustava.

Sustav se shvaća kao svaki objekt koji se istovremeno razmatra i kao jedinstvena cjelina i kao skup heterogenih elemenata kombiniranih u interesu postizanja postavljenih ciljeva. Sustavi se međusobno značajno razlikuju i po sastavu i po svojim glavnim ciljevima.

U informatici je pojam sustava raširen i ima mnoga semantička značenja. Najčešće se koristi u odnosu na skup hardvera i softvera. Dodatak konceptu riječi informacijski sustav odražava svrhu njegova stvaranja i funkcioniranja. Informacijski sustavi omogućuju prikupljanje, pohranu, obradu, pretraživanje i dostavu informacija neophodnih u procesu donošenja odluka o problemima iz bilo kojeg područja. Pomažu u analizi problema i stvaranju novih proizvoda.

Informacijski sustav (IS) - međusobno povezan skup alata, metoda i osoblja koji se koristi za pohranu, obradu i izdavanje informacija radi postizanja cilja.

Suvremene informacijske tehnologije pružaju širok raspon metoda implementacije IP -a, čiji se izbor temelji na zahtjevima namjeravanih korisnika, koji se u pravilu mijenjaju tijekom procesa razvoja.

Dodavanje pojma "automatizirano" konceptu "sustava" odražava načine stvaranja i funkcioniranja takvog sustava.

Automatizirani sustav(prema GOST -u) sustav je koji se sastoji od međusobno povezanog skupa organizacijskih jedinica i niza alata za automatizaciju aktivnosti koji implementira automatizirane funkcije za određene vrste aktivnosti.

Automatizirani informacijski sustav (AIS) kompleks je softverskih, tehničkih, informacijskih, jezičnih, organizacijskih i tehnoloških sredstava i osoblja, osmišljenih za rješavanje problema referentnih i informacijskih usluga i (ili) informacijske podrške korisnicima.

Automatizirani informacijski sustav skup je informacija, ekonomskih i matematičkih metoda i modela, tehničkih, softverskih, tehnoloških alata i stručnjaka namijenjenih obradi informacija i donošenju upravljačkih odluka.

Glavna svrha automatiziranih informacijskih sustava nije samo prikupljanje i spremanje elektroničkih informacijskih izvora, već i pružanje korisnicima pristupa do njih. Jedna od najvažnijih značajki AIS -a je organizacija dohvata podataka u njihovim informacijskim nizovima (bazama podataka).

Pod AIS projektom podrazumijevamo projektnu i tehnološku dokumentaciju koja daje opis projektnih rješenja za stvaranje i rad IS u određenom softverskom i hardverskom okruženju.

Mogu se razlikovati sljedeće glavne značajke projekta kao objekta upravljanja:

· Ograničeni krajnji cilj;

· Ograničeno trajanje;

· Ograničeni proračun;

· Potrebna ograničena sredstva;

· Novost za poduzeće za koje se projekt provodi;

· Složenost;

· Pravna i organizacijska podrška.

S obzirom na planiranje i upravljanje projektima, potrebno je jasno shvatiti da govorimo o upravljanju određenim dinamičkim objektom. Stoga sustav upravljanja projektima mora biti dovoljno fleksibilan da dopušta izmjene bez globalnih promjena program rada... Izvođenje radova osigurano je dostupnošću potrebnih resursa: materijala; oprema; ljudski resursi. Sa stajališta teorije upravljačkih sustava, projekt kao upravljački objekt mora biti uočljiv i kontroliran, odnosno istaknute su neke karakteristike pomoću kojih se napredak projekta može stalno pratiti. Osim toga, potrebni su mehanizmi za pravodobno utjecanje na napredak projekta.

Dizajn AIS -a shvaća se kao proces pretvaranja ulaznih informacija o objektu, metodama i iskustvu u projektiranju objekata slične namjene u skladu s GOST -om u projekt IS.

S tog se gledišta dizajn AIS -a svodi na sekvencijalnu formalizaciju projektnih rješenja u različitim fazama životnog ciklusa AIS -a: planiranje i analiza zahtjeva, tehničko i detaljno projektiranje, implementacija i rad AIS -a.

Opseg sustava koji se razvija određuje sastav i broj sudionika u procesu projektiranja. S velikim obujmom i kratkim rokovima za provedbu projektantskih radova, nekoliko dizajnerskih timova (razvojnih organizacija) može sudjelovati u razvoju sustava. U tom slučaju dodjeljuje se matična organizacija koja koordinira aktivnosti svih suizvršiteljskih organizacija.

Tehnologija projektiranja AIS -a skup je metodologija i alata za projektiranje AIS -a, kao i metoda i sredstava njegove organizacije (upravljanje procesom stvaranja i modernizacije AIS projekta).

Tehnologija projektiranja temelji se na tehnološkom procesu koji određuje radnje, njihov slijed, potreban sastav izvođača, sredstva i sredstva.

Tehnološki proces projektiranja AIS-a općenito je podijeljen na skup uzastopno-paralelnih, povezanih i podređenih lanaca djelovanja, od kojih svaki može imati svoj predmet. Dakle, tehnologija projektiranja postavljena je reguliranim nizom tehnoloških operacija koje se izvode na temelju određene metode, zbog čega postaje jasno ne samo što bi trebalo učiniti za izradu projekta, već i kako, tko i u kojem slijedu.

Predmet svake odabrane tehnologije projektiranja trebao bi biti odraz međusobno povezanih procesa projektiranja u svim fazama životnog ciklusa AIS -a. Glavni zahtjevi za odabranu tehnologiju projektiranja uključuju sljedeće:

· Izrađeni projekt mora zadovoljiti zahtjeve kupca;

· Maksimalni odraz svih faza životnog ciklusa projekta;

· Osiguravanje minimalnih troškova rada i troškova za izradu i održavanje projekta;

· Tehnologija bi trebala biti temelj za komunikaciju između dizajna i projektne potpore;

· Povećanje produktivnosti dizajnera;

· Pouzdanost dizajna i rada projekta;

· Jednostavno održavanje projektne dokumentacije.

Tehnologija projektiranja AIS -a temelji se na metodologiji koja definira bit, glavne prepoznatljive tehnološke značajke.

Metodologija projektiranja pretpostavlja prisutnost nekog koncepta, principa dizajna, provedenih nizom metoda, koji se pak moraju potkrijepiti nekim sredstvima.

Organizacija dizajna uključuje definiranje metoda interakcije između dizajnera i s klijentom u procesu izrade AIS projekta, što također može biti podržano skupom posebnih alata.

računalni informacijski sustav za projektiranje

2. SVRHA I CILJEVI PROJEKTIRANJA

Dizajn informacijskih sustava uvijek počinje definiranjem cilja projekta. Svrha dizajna je odabir tehničke i formiranje informacijske, matematičke, softverske i organizacijske i pravne podrške.

Odabir tehničke podrške trebao bi biti takav da osigurava pravovremeno prikupljanje, registraciju, prijenos, pohranu, popunjavanje i obradu informacija.

Informacijska podrška trebala bi osigurati stvaranje i rad jedinstvenog informacijskog fonda sustava, predstavljenog različitim informacijskim nizovima, skupom podataka ili bazom podataka.

Formiranje matematičke podrške sustava obuhvaća cjelovit skup metoda i algoritama za rješavanje funkcionalnih problema. Prilikom razvoja softverskih sustava posebna se pozornost posvećuje stvaranju skupa programa i korisničkih uputa te izboru učinkovitih softverskih proizvoda.

Glavni zadatak svakog uspješnog projekta je osigurati da u vrijeme pokretanja sustava i tijekom njegova rada bude moguće osigurati:

· Potrebna funkcionalnost sustava i stupanj prilagođenosti promjenjivim uvjetima njegova funkcioniranja;

· Potrebna propusnost sustava;

· Traženo vrijeme odgovora sustava na zahtjev;

· Besprekoran rad sustava u traženom načinu rada, drugim riječima - spremnost i dostupnost sustava za obradu korisničkih zahtjeva;

· Jednostavnost rada i podrška sustavu;

· Nužna sigurnost.

Performanse su glavna odrednica učinkovitosti sustava. Dobar dizajn temelj je sustava visokih performansi.

Dizajn automatiziranih informacijskih sustava pokriva tri glavna područja:

· Dizajn objekata podataka koji će se implementirati u bazu podataka;

· Osmišljavanje programa, ekrana, izvješća koji će osigurati izvršavanje upita prema podacima;

· Uzimajući u obzir specifično okruženje ili tehnologiju, naime: topologiju mreže, konfiguraciju hardvera, korištenu arhitekturu (poslužitelj datoteka ili klijent-poslužitelj), paralelnu obradu, distribuiranu obradu podataka itd.

U stvarnim uvjetima projektiranje je traženje metode koja zadovoljava zahtjeve funkcionalnosti sustava pomoću dostupnih tehnologija, uzimajući u obzir zadana ograničenja.

Za svaki projekt nameću se brojni apsolutni zahtjevi, na primjer, maksimalno vrijeme razvoja projekta, maksimalno financijsko ulaganje u projekt itd. Jedna od poteškoća dizajna je ta što to nije tako strukturiran zadatak kao analiza zahtjeva za projekt ili implementacija određenog dizajnerskog rješenja.

3. FAZE DIZAJNA

Proces stvaranja AIS -a podijeljen je u nekoliko faza (faza), ograničenih nekim vremenskim okvirom i završavajući objavljivanjem određenog proizvoda.

Svaki projekt, bez obzira na složenost i opseg posla koji je potreban za njegovu provedbu, u svom razvoju prolazi kroz određena stanja. Od stanja kada "projekt još ne postoji" do stanja kada "projekta više nema". Skup razvojnih faza od nastanka ideje do potpunog završetka projekta obično je podijeljen u faze.

Svrha početnih faza stvaranja AIS -a, provedenih u fazi analize aktivnosti organizacije, je formuliranje zahtjeva za AIS koji ispravno i točno odražavaju ciljeve i zadaće organizacije korisnika. Kako bi se precizirao proces stvaranja AIS -a koji zadovoljava potrebe organizacije, potrebno je saznati i jasno artikulirati koje su to potrebe. Da biste to učinili, potrebno je odrediti zahtjeve kupaca za AIS i preslikati ih na jeziku modela u zahtjeve za razvoj projekta AIS kako bi se osigurala usklađenost s ciljevima i zadacima organizacije.

Mogu se razlikovati sljedeće faze razvoja automatiziranih informacijskih sustava:

3.1 Formiranje koncepta. Konceptualna faza

Ovo uključuje:

· Formiranje ideje;

· Formiranje ključnog projektnog tima;

· Proučavanje motivacije i zahtjeva kupaca i drugih sudionika;

· Prikupljanje početnih podataka i analiza postojećeg stanja;

· Određivanje osnovnih zahtjeva i ograničenja, potrebnih materijalnih, financijskih i radnih resursa;

· Usporedna procjena alternativa;

· Podnošenje prijedloga, njihovo ispitivanje i odobravanje.

Zadatak formiranja zahtjeva za AIS jedan je od najvažnijih, teško formalizirati i najskuplji te ga je teško ispraviti u slučaju pogreške. Suvremeni alati i softverski proizvodi omogućuju vam brzo stvaranje AIS-a prema gotovim zahtjevima. No često ti sustavi ne zadovoljavaju kupce, zahtijevaju brojne izmjene, što dovodi do naglog porasta troškova stvarnih troškova AIS -a. Glavni razlog ove situacije je netočna, netočna ili nepotpuna definicija zahtjeva za AIS u fazi analize.

3.2 Priprema tehničkog prijedloga

§ razvoj glavnog sadržaja osnovne strukture projekta;

§ razvoj i odobrenje tehničkih specifikacija;

§ planiranje, razlaganje osnovnog strukturnog modela projekta;

§ sastavljanje procjena i proračuna projekta;

§ razvoj kalendarski planovi i povećani radni raspored;

§ potpisivanje ugovora s kupcem;

§ stavljanje u funkciju sredstava komunikacije sudionika projekta i sredstava kontrole nad napredovanjem posla.

3.3 Dizajn

U fazi projektiranja identificiraju se podsustavi, njihovi međusobni odnosi i odabiru najučinkovitiji načini projektiranja i korištenja resursa. Tipični radovi ove faze:

§ izvođenje osnovnih projektnih radova;

§ razvoj privatnih tehničkih specifikacija;

§ provedba idejnog rješenja;

§ sastavljanje tehničkih specifikacija i uputa;

§ prezentacija razvoja projekta, ispitivanje i odobrenje.

U fazi projektiranja najprije se formiraju modeli podataka. Dizajneri dobivaju rezultate analize kao ulaz. Izgradnja logičkih i fizičkih modela podataka bitan je dio dizajna baze podataka. Informacijski model dobiven tijekom analize prvo se pretvara u logički, a zatim u fizički model podataka.

3.4 Razvoj

U fazi razvoja provodi se koordinacija i operativna kontrola rada na projektu, proizvodi se, kombinira i testira podsustav.

Nakon uspješno položenog autonomnog testa, modul se uključuje u razvijeni dio sustava, a grupa generiranih modula prolazi komunikacijske testove koji bi trebali pratiti njihov međusobni utjecaj.

Nadalje, skupina modula testira se na pouzdanost rada, odnosno prolazi, prvo, testove za simulaciju kvarova sustava, i drugo, testove radnog vremena između kvarova. Prva skupina testova pokazuje koliko se sustav oporavi od softverskih kvarova, hardverskih kvarova. Druga skupina testova određuje stupanj stabilnosti sustava tijekom normalnog rada i omogućuje vam da procijenite vrijeme rada sustava. Paket testova stabilnosti trebao bi uključivati ​​ispitivanja koja simuliraju vršno opterećenje sustava.

Tada cijeli skup modula prolazi sistemsko testiranje - interno ispitivanje prihvatljivosti proizvoda, koje pokazuje razinu njegove kvalitete. To uključuje testove funkcionalnosti i testove pouzdanosti sustava.

Posljednji automatizirani test informacijski sistem- prijemni testovi. Takav test uključuje pokazivanje informacijskog sustava kupcu i mora sadržavati skupinu testova koji simuliraju stvarne poslovne procese.

3.5 Puštanje sustava u rad

U fazi puštanja sustava u rad provode se ispitivanja, sustav se testira u stvarnim uvjetima, u tijeku su pregovori o rezultatima projekta i o mogućim novim ugovorima.

Glavne vrste radova:

§ složena ispitivanja;

§ osposobljavanje osoblja za rad sustava koji se stvara;

§ pripremu radne dokumentacije, isporuku sustava kupcu i puštanje u rad;

§ pratnja, podrška, usluga;

§ ocjenjivanje rezultata projekta i priprema završnih dokumenata.

4. SASTAV I STRUKTURA TEHNIČKOG PROJEKTA I TEHNIČKOG PROJEKTA

1. Opće odredbe

1.1. Projektni zadatak (TOR) glavni je dokument koji definira zahtjeve i postupak za stvaranje (razvoj ili modernizaciju - daljnje stvaranje) informacijskog sustava, u skladu s kojim se provodi razvoj IS -a i njegovo prihvaćanje nakon puštanja u rad .

1.2. TK je razvijen za sustav u cjelini, dizajniran za rad neovisno ili kao dio drugog sustava.

1.3. Zahtjevi za IS u opsegu utvrđenom ovim standardom mogu se uključiti u zadatak za projektiranje novostvorenog objekta informatizacije. U ovom slučaju TK nije razvijen.

1.4. Zahtjevi uključeni u TK moraju biti u skladu s trenutnom razinom razvoja informacijske tehnologije i ne podliježu sličnim zahtjevima za najbolje suvremene domaće i strane partnere. Zahtjevi postavljeni u TK ne bi trebali ograničavati programera sustava u pronalaženju i provedbi najučinkovitijih tehničkih, tehničkih, ekonomskih i drugih rješenja.

1.5. TK uključuje samo one zahtjeve koji nadopunjuju zahtjeve za sustave ovog tipa i određeni su specifičnostima određenog objekta za koji se sustav stvara.

1.6. Promjene u TK sastavljaju se dodatkom ili protokolom koji potpisuju kupac i programer. Dodatak ili navedeni protokol sastavni su dio TK na IP -u. Na naslovnoj stranici TK trebao bi biti unos "Vrijedi od ...".

2. Sastav i sadržaj

2.1. TK sadrži sljedeće odjeljke koji se mogu podijeliti u pododjeljke:

1) opći podaci;

2) svrha i ciljevi stvaranja (razvoja) sustava;

3) karakteristike objekata;

4) zahtjevi sustava;

5) sastav i sadržaj rada na stvaranju sustava;

6) postupak kontrole i prihvaćanja sustava;

7) zahtjeve za sastav i sadržaj rada na pripremi razvojnog objekta za puštanje sustava u rad;

8) zahtjevi za dokumentaciju;

9) razvojni izvori.

TK može uključivati ​​aplikacije.

2.2. Ovisno o vrsti, namjeni, specifičnim značajkama projekta i uvjetima za funkcioniranje sustava, dopušteno je formalizirati odjeljke TK -a u obliku aplikacija, uvesti dodatne, isključiti ili kombinirati pododjeljke TK -a.

TK za dijelove sustava ne uključuje odjeljke koji dupliciraju sadržaj odjeljaka TK u cjelini.

2.3. U odjeljku "Opći podaci" navedite:

1) puni naziv sustava i njegov simbol;

2) šifru teme ili šifru (broj) ugovora;

3) naziv tvrtki programera i kupca (korisnika) sustava i njihove pojedinosti;

4) popis dokumenata na temelju kojih se stvara sustav, od koga i kada su ti dokumenti odobreni;

5) planirani datum početka i završetka stvaranja sustava;

6) podatke o izvorima i postupku financiranja rada;

7) postupak registracije i prezentiranja kupcu rezultata rada na stvaranju sustava (njegovih dijelova), na izradi i prilagodbi pojedinih sredstava (hardver, softver, informacije) i softvera i hardvera (softver i metodologija ) sustavi sustava.

2.4. Odjeljak "Svrha i ciljevi stvaranja (razvoja) sustava" sastoji se od pododsjeka:

1) svrha sustava;

2) svrha stvaranja sustava.

2.4.1. U pododjeljku "Svrha sustava" navedite vrstu aktivnosti sustava (upravljanje, projektiranje itd.) I popis objekata informatizacije (objekata) na kojima bi se trebao koristiti.

2.4.2. U pododjeljku "Ciljevi stvaranja sustava" dati su nazivi i potrebne vrijednosti tehničkih, tehnoloških, proizvodno-ekonomskih ili drugih pokazatelja objekta informatizacije, koji se moraju postići kao rezultat stvaranja IS-a , a navedeni su i kriteriji za ocjenjivanje postizanja ciljeva stvaranja sustava.

2.5. U odjeljku "Karakteristike objekta informatizacije" navedite:

1) kratke informacije o objektu informatizacije ili poveznice na dokumente koji sadrže te podatke;

2) podatke o radnim uvjetima objekta automatizacije.

2.6. Odjeljak Sistemski zahtjevi sastoji se od sljedećih pododsjeka:

1) zahtjevi za sustav u cjelini;

2) zahtjevi za funkcije (zadatke) koje sustav obavlja;

3) zahtjevi za vrste osiguranja.

Sastav zahtjeva za sustav, uključenih u ovaj odjeljak TK za IS, utvrđuje se ovisno o vrsti, namjeni, specifičnim značajkama i uvjetima funkcioniranja određenog sustava.

2.6.1. U pododjeljku "Zahtjevi za sustav u cjelini" navedite:

zahtjevi za strukturu i funkcioniranje sustava;

zahtjeve za broj i kvalifikacije osoblja sustava i način njihovog rada;

pokazatelji odredišta;

zahtjevi pouzdanosti;

sigurnosni zahtjevi;

zahtjevi za ergonomiju i tehničku estetiku;

zahtjevi za rad, održavanje, popravak i skladištenje komponenti sustava;

zahtjevi za zaštitu informacija od neovlaštenog pristupa;

zahtjeve za sigurnost informacija u slučaju nesreća;

zahtjevi za zaštitu od utjecaja vanjskih utjecaja;

zahtjevi za čistoću patenta;

zahtjevi za standardizaciju i unifikaciju;

Dodatni zahtjevi.

2.6.1.1. Zahtjevi za strukturu i funkcioniranje sustava uključuju:

1) popis podsustava, njihovu namjenu i osnovne karakteristike, zahtjeve za broj razina hijerarhije i stupanj centralizacije sustava;

2) zahtjevi za metode i sredstva komunikacije za razmjenu informacija između komponenti sustava;

3) zahtjevi za karakteristike međusobnih veza sustava koji se stvara sa susjednim sustavima, zahtjevi za njegovu kompatibilnost, uključujući upute o načinu razmjene informacija (automatski, slanjem dokumenata, telefonom itd.);

4) zahtjevi za načine rada sustava;

5) zahtjevi za dijagnosticiranje sustava;

6) izgledi za razvoj, modernizaciju sustava.

2.6.1.2. Zahtjevi za broj i kvalifikacije osoblja IS -a uključuju:

§ zahtjevi za broj osoblja (korisnika) IS -a;

§ zahtjevi za kvalifikaciju osoblja, postupak njihove obuke i kontrola znanja i vještina;

§ potreban način rada osoblja IS -a.

2.6.1.3. U zahtjevima za pokazatelje namjene IS -a date su vrijednosti parametara koji karakteriziraju stupanj usklađenosti sustava sa njegovom namjenom.

2.6.1.4. Zahtjevi pouzdanosti uključuju:

1) sastav i kvantitativne vrijednosti pokazatelja pouzdanosti za sustav u cjelini ili njegove podsustave;

2) popis hitnih situacija za koje se moraju regulirati zahtjevi pouzdanosti i vrijednosti odgovarajućih pokazatelja;

3) zahtjevi za pouzdanost hardvera i softvera;

4) zahtjevi za metode procjene i praćenja pokazatelja pouzdanosti u različitim fazama stvaranja sustava u skladu s važećim regulatornim i tehničkim dokumentima.

2.6.1.5. Sigurnosni zahtjevi uključuju sigurnosne zahtjeve za isporuku, puštanje u rad, rad i održavanje sustava.

2.6.1.6. Zahtjevi za ergonomiju i tehničku estetiku uključuju IP pokazatelje koji postavljaju potrebnu kvalitetu interakcije čovjek-stroj i udobnost radnih uvjeta za osoblje.

2.6.1.7. Zahtjevi za zaštitu informacija od neovlaštenog pristupa uključuju zahtjeve koje postavlja industrija i informacijsko okruženje korisnika.

2.6.1.8. U zahtjevima za sigurnost informacija dat je popis događaja: nesreće, kvarovi tehničkih sredstava (uključujući gubitak snage) itd. U kojima se mora osigurati sigurnost informacija u sustavu.

2.6.1.9. Zahtjevi za čistoću patenta navode popis zemalja u odnosu na koje se mora osigurati čistoća patenta sustava i njegovih dijelova.

2.6.1.10. Dodatni zahtjevi uključuju posebne zahtjeve prema nahođenju programera ili kupca sustava.

2.6.2. U pododjeljku "Zahtjevi za funkcije (zadatke)" koje sustav izvodi, dano je sljedeće:

§ za svaki podsustav popis funkcija, zadataka ili njihovih kompleksa (uključujući one koji osiguravaju interakciju dijelova sustava) koje treba automatizirati;

§ pri stvaranju sustava u dva ili više redova - popis funkcionalnih podsustava, pojedinačnih funkcija ili zadataka koji se stavljaju u funkciju u 1. i narednim redovima;

§ vremenski raspored za provedbu svake funkcije, zadatka (ili skupa zadataka);

§ zahtjevi za kvalitetu provedbe svake funkcije (zadatak ili kompleks zadataka), za oblik prezentacije izlaznih informacija, karakteristike potrebne točnosti i vremena izvršavanja, zahtjevi za istodobno obavljanje skupine funkcija, pouzdanost rezultati;

§ popis i kriterije kvarova za svaku funkciju, za koje su postavljeni zahtjevi pouzdanosti.

2.6.3. U pododjeljku "Zahtjevi za vrste podrške", ovisno o vrsti sustava, dati su zahtjevi za matematičku, informacijsku, jezičnu, softversku, tehničku, mjeriteljsku, organizacijsku, metodološku i druge vrste podrške sustavu.

2.6.3.2. Za informacijsku podršku sustavu postavljeni su sljedeći zahtjevi:

1) na sastav, strukturu i metode organiziranja podataka u sustavu;

2) za razmjenu informacija između komponenti sustava;

3) kompatibilnost informacija sa povezanim sustavima;

4) o primjeni sustava upravljanja bazama podataka;

5) strukturi procesa prikupljanja, obrade, prijenosa podataka u sustavu i prezentiranja podataka;

6) radi zaštite podataka;

7) kontrolu, pohranu, ažuriranje i oporavak podataka;

2.6.3.3. Za jezičnu podršku sustavu dati su zahtjevi za uporabu programskih jezika na visokoj razini u sustavu, jezika za interakciju između korisnika i tehničkih sredstava sustava, kao i zahtjevi za kodiranje i dekodiranje podataka, za jezici za unos-izlaz podataka, jezici za manipulaciju podacima, sredstva za opisivanje predmetnog područja, za metode organiziranja dijaloga.

2.6.3.4. Za softver sustava dat je popis kupljenog softvera, kao i zahtjevi:

1) o ovisnosti softvera o radnom okruženju;

2) kvaliteti softvera, kao i načinima njegova pružanja i kontrole;

2.6.3.5. Za tehničku podršku sustava postavljeni su sljedeći zahtjevi:

1) na vrste tehničkih sredstava, uključujući vrste kompleksa tehničkih sredstava, softverske i hardverske komplekse i druge komponente dopuštene za uporabu u sustavu;

2) funkcionalnim, dizajnerskim i operativnim karakteristikama tehničke podrške sustava.

2.6.3.6. Zahtjevi za mjeriteljsku podršku uključuju:

1) preliminarni popis mjernih kanala;

2) zahtjevi za točnost mjerenja parametara i (ili) za mjeriteljske karakteristike mjernih kanala;

3) zahtjevi za mjeriteljsku kompatibilnost tehničkih sredstava sustava;

4) popis upravljačkih i računalnih kanala sustava za koje je potrebno ocijeniti karakteristike točnosti;

5) zahtjevi za mjeriteljsku podršku hardvera i softvera koji su dio mjernih kanala sustava, sredstava, ugrađene kontrole, mjeriteljske prikladnosti mjernih kanala i mjernih instrumenata koji se koriste pri postavljanju i ispitivanju sustava;

6) vrstu mjeriteljskog certificiranja (državnog ili resornog) s naznakom postupka za njegovu provedbu i organizacija koje provode certifikaciju.

2.6.3.7. Za organizacijsku podršku potrebni su sljedeći zahtjevi:

1) strukturi i funkcijama jedinica uključenih u funkcioniranje sustava ili osiguravanje rada;

2) organizaciji funkcioniranja sustava i redoslijedu interakcije između osoblja IS -a i osoblja objekta informatizacije;

3) radi zaštite od pogrešnih radnji osoblja sustava.

2.7. Odjeljak "Sastav i sadržaj rada na stvaranju (razvoju) sustava" mora sadržavati popis faza i faza rada na stvaranju sustava, rokove njihove provedbe, popis organizacija - izvršitelja posla , poveznice na dokumente koji potvrđuju pristanak ovih organizacija za sudjelovanje u stvaranju sustava ili zapis koji identificira osobu odgovornu (kupac ili programer) za izvođenje ovih radova.

Ovaj odjeljak također pruža:

1) popis dokumenata prezentiranih na kraju relevantnih faza i faza rada;

2) vrstu i postupak ispitivanja tehničke dokumentacije (faza, faza, opseg provjerene dokumentacije, stručna organizacija);

3) program rada usmjeren na osiguravanje potrebne razine pouzdanosti sustava u razvoju (ako je potrebno);

4) popis radova na mjeriteljskoj podršci u svim fazama stvaranja sustava, s naznakom njihovih rokova i izvršnih organizacija (ako je potrebno).

2.8. U odjeljku "Postupak kontrole i prihvaćanja sustava" navedite:

1) vrste, sastav, opseg i metode ispitivanja sustava i njegovih komponenti;

2) opće uvjete za prihvat radova po fazama, postupak koordinacije i odobravanja dokumentacije o prihvaćanju;

2.9. U odjeljku "Uvjeti za sastav i sadržaj radova na pripremi objekta automatizacije za puštanje sustava u rad" potrebno je navesti popis glavnih aktivnosti i njihovih izvođača, koje bi trebalo izvesti pri izradi projekta za puštanje u rad IS -a.

Popis glavnih aktivnosti uključuje:

1) dovođenje informacija koje ulaze u sustav (u skladu sa zahtjevima za informacijsku i jezičnu podršku);

2) stvaranje uvjeta za funkcioniranje projekta, pod kojima se jamči usklađenost stvorenog sustava sa zahtjevima sadržanim u TK;

3) stvaranje pododjela i službi potrebnih za funkcioniranje sustava;

4) vrijeme i postupak za osoblje i obuku osoblja.

2.10. U odjeljku "Zahtjevi za dokumentaciju" navedeno je sljedeće:

1) popis skupova i vrsta dokumenata koje treba izraditi, usaglašenih između programera i kupca sustava;

2) popis dokumenata izdanih na strojnim medijima;

3) u nedostatku državnih standarda koji određuju zahtjeve za dokumentiranje elemenata sustava, dodatno uključuju zahtjeve za sastav i sadržaj takvih dokumenata.

2.11. U odjeljku "Izvori razvoja" trebali bi se navesti dokumenti i informativni materijali na temelju kojih je razvijen TK i koji bi se trebali koristiti pri stvaranju sustava.

3. Pravila projektiranja.

3.1. Odjeljke i pododsjeke TK treba postaviti redoslijedom utvrđenim u odjeljku. 2 ovog standarda.

3.2. Brojevi listova (stranica) spuštaju se, počevši od prvog lista koji slijedi naslovnu stranicu, u gornji dio lista (iznad teksta, u sredini) nakon označavanja TK koda na IP -u.

3.3. Naslovna stranica sadrži potpise kupaca, programera i tvrtki koje odobravaju, a koje su zapečaćene. Ako je potrebno, naslovna stranica se sastavlja na nekoliko stranica. Potpisi programera TK -a i službenika koji sudjeluju u odobravanju i razmatranju nacrta TK -a o IP -u nalaze se na posljednjem listu.

Obrazac naslovne stranice TK -a dat je u Dodatku 2. Obrazac zadnje stranice TK -a dat je u Dodatku 3.

3.4. Naslovna stranica dodatka TK sastavljena je na isti način kao i naslovna stranica tehničkog zadatka. Umjesto naziva "Opis poslova" pišu "Dodatak br ... TK za AC ...".

3.5. Na naknadnim listovima dodatka TK stavljaju se osnova za promjenu, sadržaj promjene i poveznice na dokumente, u skladu s kojima se te izmjene vrše.

3.6. Prilikom prezentiranja teksta dopune TK treba navesti brojeve relevantnih klauzula, potklauzula, tablica glavnog TK itd., A riječi „zamijeniti“, „dopuniti“, „isključiti“, „preformulirati " trebalo bi se koristiti.

Postupak razvoja, koordinacije i odobrenja TK za IP.

1. Nacrt TK izrađuje organizacija-programer sustava uz sudjelovanje kupca na temelju tehničkih zahtjeva (aplikacije, taktičko-tehničke specifikacije itd.).

U natjecateljskoj organizaciji rada kupci razmatraju opcije nacrta TK -a, koji ili odabire željenu opciju, ili na temelju usporedne analize priprema konačnu verziju TK -a za AC uz sudjelovanje budući programer IS -a.

2. Potrebu za odobrenje nacrta TK -a s tijelima državnog nadzora i drugim zainteresiranim organizacijama zajednički utvrđuju kupac sustava i programer nacrta TK -a na IS -u,

Rad na odobravanju nacrta TK za IC zajednički provode programer TK i kupac sustava, svaki u organizacijama svog ministarstva (odjela).

3. Rok odobrenja nacrta tehničke dokumentacije u svakoj organizaciji ne smije biti duži od 15 dana od datuma njegova primitka. Preporučuje se slanje kopija nacrta TK (kopije) istovremeno svim organizacijama (odjelima) na odobrenje.

4. Komentare na nacrt projektnog zadatka potrebno je dostaviti uz tehničko obrazloženje. Odluke o komentarima trebali bi donijeti programer nacrta TK i kupac sustava prije odobrenja TK na IS -u.

5. Ako je prilikom dogovaranja o nacrtu TK došlo do nesuglasica između programera i kupca (ili drugih zainteresiranih organizacija), tada se sastavlja protokol neslaganja (proizvoljan obrazac) i donosi posebna odluka u uspostavljeni red.

6. Odobrenjem nacrta TK dopušteno je sastavljanje zasebnog dokumenta (dopisa). U tom slučaju, pod naslovom "Dogovoreno" napravite vezu do ovog dokumenta.

7. Odobrenje TK provode čelnici tvrtki programera i kupac sustava.

8. Kopije odobrenog TK -a u roku od 10 dana nakon odobrenja programer TK -a šalje sudionicima u stvaranju sustava.

9. Koordinacija i odobravanje dodataka TK -u provode se na način utvrđen za TK na IP -u.

10. Nije dopušteno odobriti promjene TK -a nakon podnošenja sustava ili njegovog reda za prijemne testove.

Temelj za razvoj tehničkog projekta sustava je tehnički zadatak koji je odobrio kupac.

Tehnički dizajn sustava tehnička je dokumentacija odobrena na propisani način, koja sadrži projektna rješenja za cijeli sustav, algoritam za rješavanje problema, kao i ocjenu ekonomske učinkovitosti automatiziranog upravljačkog sustava i popis mjera za izradu objekt za implementaciju.

Tehnički projekt razvija se radi utvrđivanja glavnih projektnih rješenja za stvaranje sustava. U ovoj fazi provodi se kompleks istraživačkog i eksperimentalnog rada za odabir najboljih rješenja, provodi se eksperimentalna provjera glavnih projektnih rješenja i izračun ekonomske učinkovitosti sustava.

Zapravo, tehnički projekt sadrži kompleks ekonomskih, matematičkih i algoritamskih modela.

Kompletan tehnički dizajn sustava uključuje 10 dokumenata:

1. Objašnjenje.

2. Funkcionalna i organizacijska struktura sustava.

3. Izjava problema i algoritam rješenja.

4. Organizacija informacijske baze.

5. Album obrazaca dokumenata.

6. Softverski sustav.

7. Načelo izgradnje kompleksa tehničkih sredstava.

8. Proračun ekonomske učinkovitosti sustava.

9. Mjere za pripremu objekta za implementaciju sustava.

10. Popis dokumenata.

S gornjeg popisa, dokument 3 "Izjava zadataka i algoritam za rješavanje" izvodi se za svaki pojedinačni zadatak uključen u EIS, ostali su dokumenti zajednički za cijeli sustav. Osim toga, dokumenti 1, 2, 5, 8 i 9 mogu se izraditi za pojedine podsustave.

Svi navedeni dokumenti mogu se grupirati i predstaviti u obliku četiri glavna dijela tehničkog projekta: ekonomskog i organizacijskog, informacijskog, matematičkog i tehničkog.

Ekonomski i organizacijski dio tehničkog projekta sadrži objašnjenje koje opravdava razvoj sustava, popis organizacija programera, kratak opis objekta s naznakom glavnih tehničko -ekonomskih pokazatelja njegova funkcioniranja i povezanosti s drugim objektima, kratki informacije o glavnim projektnim rješenjima za funkcionalne i prateće dijelove sustava.

U odjeljku tehničkog projekta, posvećenom organizacijskoj i funkcionalnoj strukturi sustava, dano je sljedeće: obrazloženje dodijeljenih podsustava, njihov popis i namjena; popis zadataka koje treba riješiti u svakom podsustavu s kratkim opisom njihovog sadržaja; dijagram informacijskih veza između podsustava i između zadataka unutar svakog podsustava.

Za svaki zadatak uključen u skup prioritetnih zadataka izvodi se njegov iskaz i algoritam za njegovo rješavanje. Ovaj odjeljak tehničkog dizajna uključuje:

§ organizacijsku i ekonomsku bit problema (naziv, svrha rješenja, sažetak, način, učestalost i vrijeme rješavanja problema, metode prikupljanja i prijenosa podataka, povezivanje problema s drugim problemima, priroda korištenja rezultata otopina u kojoj se koriste);

§ ekonomski i matematički model problema (strukturni i detaljni oblik izlaganja);

§ unos operativnih podataka (karakteristike pokazatelja, njihov značaj i raspon promjena, oblici prezentacije);

§ normativne referentne informacije (NSI) - sadržaj i oblici prezentacije;

§ informacije pohranjene za komunikaciju s drugim zadacima;

§ informacije prikupljene za kasnija rješenja ovog problema;

§ informacije o izmjenama (sustav za unošenje promjena i popis informacija podložnih promjenama);

§ algoritam za rješavanje problema (slijed faza proračuna, dijagram, računske formule);

§ testni slučaj (skup obrazaca ulaznih dokumenata ispunjenih podacima, uvjetni dokumenti s akumuliranim i pohranjenim podacima, obrasci izlaznih dokumenata ispunjeni na temelju rezultata rješavanja ekonomsko -tehničkog problema i u skladu s razvijenim algoritmom izračuna).

Dokument "Izračun ekonomske učinkovitosti sustava" sadrži konsolidiranu procjenu troškova povezanih s radom sustava, daje se izračun godišnje ekonomske učinkovitosti čiji su izvori optimizacija proizvodne strukture gospodarstva (udruga), smanjenje troškova proizvodnje zbog racionalnog korištenja proizvodnih resursa i smanjenje gubitaka, odluke uprave.

Dokument "Mjere za pripremu objekta za implementaciju sustava" sadrži popis organizacijskih mjera za poboljšanje postojeće strukture upravljanja, popis radova na implementaciji sustava koji se moraju izvesti u fazi glavnog projekta, s naznakom vrijeme i odgovorne osobe.

Informacijski dio tehničkog projekta objedinjuje dokumente 4 i 5. Dokument "Organizacija informacijske baze" odražava: izvore informacija i načine njihova prijenosa za rješavanje primarnog kompleksa funkcionalnih zadataka; skup pokazatelja koji se koriste u sustavu; sastav dokumenata, rokovi i učestalost njihovog primitka; osnovna dizajnerska rješenja za organizaciju fonda NSI; sastav NSI -ja, uključujući popis pojedinosti, njihovu definiciju, značaj, raspon promjena i popis dokumenata NSI -a; popis skupova podataka referentnih podataka, njihov obujam, redoslijed i učestalost ispravljanja informacija; prijedlozi za objedinjavanje dokumentacije, testni slučaj izmjene NSI -ja; strukturni oblik NSI -ja s opisom odnosa među elementima; zahtjevi za tehnologiju stvaranja i održavanja fonda; metode pohrane, pretraživanja, izmjene i kontrole, određivanje volumena i tokova informacija referentnih podataka.

"Album obrazaca dokumenata" sadrži oblike referentnih podataka.

Matematički dio tehničkog projekta sadrži obrazloženje za strukturu softvera, obrazloženje za izbor programskog sustava, uključujući popis standardnih programa.

Tehnički dio tehničkog projekta uključuje: opis i obrazloženje dijagrama procesa obrade tehničkih podataka; obrazloženje zahtjeva za razvoj nestandardne opreme; obrazloženje i izbor strukture kompleksa tehničkih sredstava i njegovih funkcionalnih skupina; skup mjera za osiguranje pouzdanosti funkcioniranja tehničkih sredstava.

ZAKLJUČAK

Razvoj informacijskog sustava, u pravilu, provodi se prilično dugo određeno poduzeće... Specifičnosti predmetne djelatnosti poduzeća, naravno, utječu na strukturu informacijskog sustava, no istodobno su strukture različitih poduzeća općenito slične. Svaka se organizacija, bez obzira na vrstu djelatnosti, sastoji od niza odjela koji izravno obavljaju jednu ili drugu vrstu djelatnosti tvrtke, a ova situacija vrijedi za gotovo sve organizacije, bez obzira na vrstu djelatnosti kojom se bave.

Uvođenje suvremenih informacijskih tehnologija omogućuje smanjenje vremena potrebnog za pripremu konkretnih marketinških i proizvodnih projekata, smanjenje neproizvodnih troškova tijekom njihove provedbe, uklanjanje mogućnosti pogrešaka u pripremi računovodstvene, tehnološke i drugih vrsta dokumentacije , što trgovačkom društvu daje izravan gospodarski učinak.

Naravno, kako bi se otkrile sve potencijalne mogućnosti koje korištenje računala podrazumijeva, potrebno je u njihovom radu koristiti skup softvera i hardvera koji najviše odgovara postavljenim zadacima. Stoga trenutno postoji velika potreba za trgovačkim društvima u računalni programi koji podržavaju rad uprave tvrtke, kao i informacije o tome kako najbolje iskoristiti računalnu opremu tvrtke.

Implementacija AIS dizajna uključuje uporabu određene tehnologije projektiranja od strane dizajnera, koja odgovara opsegu i karakteristikama projekta u razvoju.

POPIS KORIŠTENE KNJIŽEVNOSTI

1. Smjernice za proučavanje discipline "Automatizirani informacijski sustavi" [Elektronički izvor]. - Moskva, 2006. - Način pristupa:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Naslov. s ekrana.

2. Wikipedia, besplatna enciklopedija [Elektronički izvor]/Članak "Informacijski sustav" - Način pristupa: http://ru.wikipedia.org/wiki/Informacijski sustav.

3. Računarski tisak: Internet časopis. - Elektron. Dan. - [B.m., 2001]. - Način pristupa: http://compress.ru/article.aspx?id=12282.

4. Vendrov AM, "Projektiranje softvera za ekonomske informacijske sustave" / A.M. Vendra. - M.: "Financije i statistika", 2000. - 364 str.

5. "Opis poslova za stvaranje automatiziranog sustava" / - M.: GOST 34.602-89, 1990.

6. Grekul V.I. "Projektiranje informacijskih sustava" / V.I. Grekul, G.N. Denischenko, N.L. Korovkin. - M.: Internet Sveučilište informacijskih tehnologija, 2008 (zbornik).

Objavljeno na Allbest.ru

Slični dokumenti

Razvoj informacijskih sustava. Moderno tržište financijski i ekonomski primijenjeni softver. Prednosti i nedostaci implementacije automatiziranih informacijskih sustava. Metode projektiranja automatiziranih informacijskih sustava.

diplomski rad, dodan 22.11.2015


Vrste podrške automatiziranih informacijskih sustava. Priprema tehničkih specifikacija, razvoj informacijskog sustava, priprema korisničkog priručnika za program. Programski alati za distribuirane sustave za obradu informacija.

izvješće o praksi, dodano 16.04.2017


Životni ciklus automatiziranih informacijskih sustava. Osnove metodologije projektiranja automatiziranih sustava temeljenih na CASE-tehnologijama. Faza analize i planiranja, izgradnje i implementacije automatiziranog sustava. Model vodopada i spirale.

seminarski rad dodan 20.11.2010


Pojam informacijskog sustava, vrste informacijskih sustava. Analiza alata za razvoj automatiziranih informacijskih sustava. Zahtjevi za program i softverski proizvod. Razvoj oblika grafičkog sučelja i baza podataka.

diplomski rad, dodan 23.06.2015


Načela organiziranja sustava koji se sastoji od osoblja i skupa alata za automatizaciju njihovih aktivnosti. Projektiranje korporativnih automatiziranih informacijskih sustava. Struktura, ulazni i izlazni tokovi, ograničenja automatiziranih sustava.

prezentacija dodana 14.10.2013


Koncept informacijskog sustava. Faze razvoja informacijskih sustava. Procesi u informacijskom sustavu. Informacijski sustav za pronalaženje tržišnih niša, za smanjenje troškova proizvodnje. Struktura informacijskog sustava. Tehnička podrška.

sažetak, dodano 17.11.2011


Organizacija, arhitektura i struktura informacijskog sustava. Pokazatelji učinkovitosti njezina rada. Ciljevi i zadaci analize ACS -a. Sastavni dijelovi automatiziranih sustava. Opis predmetnog područja, ulazni i izlazni podaci. Izrada dijagrama slučaja uporabe.

seminarski rad, dodan 11.04.2014


Stvaranje i organizacija automatiziranih informacijskih sustava (AIS). Glavne komponente i tehnološki procesi AIS -a. Faze i faze stvaranja AIS -a s pozicije menadžmenta organizacije. Razvoj kompleksa dizajnerskih rješenja za automatizirani sustav.

sažetak, dodano 18.10.2012


Glavni čimbenici koji utječu na povijest razvoja korporativnih automatiziranih informacijskih sustava. Njihove opće karakteristike i klasifikacija. Sastav i struktura integriranog AIS -a. ERP sustavi kao suvremeni tip korporacijskog informacijskog sustava.

prezentacija dodana 14.10.2013


Analiza predmetnog područja, faze projektiranja automatiziranih informacijskih sustava. Sustavi alata za razvoj softvera. Uloga CASE alata u oblikovanju informacijskog modela. Logički model dizajnirane baze podataka.

1. prosinca 2015. održana je otvorena obrana Automatiziranog informacijskog sustava za upravljanje projektima (AIS PU) stvorenog po nalogu Ministarstva industrije i trgovine Rusije. Obrani, kojom je predsjedao prvi zamjenik ministra industrije i trgovine Ruske Federacije, Gleb Nikitin, prisustvovali su načelnici odjela ministarstva, predstavnici Ministarstva gospodarskog razvoja i Ministarstva obrane Ruske Federacije.

Automatizirani sustav upravljanja projektima osmišljen je kako bi povećao učinkovitost Ministarstva industrije i trgovine Rusije u smislu podrške, održavanja i provedbe projekata usmjerenih, između ostalog, na zamjenu uvoza, povećanje izvoza, tehnološki razvoj proizvodnje, stvaranje i modernizacija radnih mjesta visokih performansi i razvoj industrijske infrastrukture (industrijski parkovi, tehnološki parkovi, centri industrijskog dizajna i inženjeringa).

Glavni korisnici stvorenog sustava, zajedno s vodstvom i zaposlenicima ministarstva nadležnim za provedbu državnih programa i saveznih ciljnih programa, bit će industrijska poduzeća koja provode vlastite investicijske projekte, savezna izvršna tijela koja pružaju državnu potporu poduzećima, banke, institucionalni ulagači i druge financijske institucije koje sudjeluju u financiranju investicijskih projekata industrijskih poduzeća i projekata za razvoj industrijske infrastrukture.

Sustav je stvorio ruski integrator sustava "Inline-Technologies" uz sudjelovanje domaćeg programera softvera "LM-Soft". AIS PU razvijen je na temelju ruske 1C platforme koristeći besplatni softver i vlasnički softver.

Na temelju rezultata proučavanja funkcionalnosti sustava, dobivene su pozitivne povratne informacije kako od uprave i zaposlenika Ministarstva industrije i trgovine, tako i od Ministarstva za gospodarski razvoj, koje je odgovorno za implementaciju mehanizama upravljanja projektima u vladi tijela. Osim toga, pozitivne povratne informacije o mogućnostima PU AIS dale su industrijska poduzeća koja su predstavila svoje pilot projekte u sklopu razvoja sustava. Konkretno, predstavnici Državnog znanstvenog centra Krylov, Znanstveno -proizvodne korporacije JSC Uralvagonzavod i Federalnog državnog znanstveno -istraživačkog instituta za geodeziju dali su pozitivne povratne informacije o pilot radu PU AIS -a. Također treba napomenuti da su predstavnici tvrtke Garrison dd, koja je u nadležnosti Ministarstva obrane, kao i predstavnici nekih banaka s državnim sudjelovanjem, pokazali izražen interes za sustav i interes za zajedničku suradnju u provedbi upravljanja projektima .

„Stvoreni sustav upravljanja projektima ne samo da će povećati učinkovitost zaposlenika ministarstva, već će omogućiti i organiziranje učinkovite interakcije sa sudionicima u industrijskim projektima iz industrijskih poduzeća, državnih tijela i razvojnih institucija te financijskih institucija. AIS PU radi na principu „jedinstvenog prozora“ uz maksimalnu uporabu tehnologija za upravljanje elektroničkim dokumentima ”, komentirao je Sergey Valuev, direktor Odjela za informacijske tehnologije i odnose s javnošću Ministarstva industrije i trgovine, provedbu sustav.

“Glavni cilj uvođenja AIS PU-a je poboljšati kvalitetu kontrole i upravljivosti, olakšati interakciju između tijela i izvršilaca velikih projekata. Pri razvoju sustava uzeli su se u obzir prije svega industrijski standardi, uredbe i naredbe Vlade, ukazi predsjednika i naredbe ministra industrije i trgovine, kao i najbolja domaća i strana praksa. Za AIS PU projektirano je više od 600 komponenti, učitano je više od 20.000 priručnika, rječnika i klasifikatora. Kao dio daljnjeg rada na razvoju AIS PU -a, planira se integracija sustava kao jednog od podsustava Državnog informacijskog sustava industrije koji trenutno stvara Ministarstvo industrije i trgovine Rusije ”, rekao je Sergej Valuev.

Uvođenje metoda upravljanja projektima definirano je kao jedan od glavnih alata za modernizaciju javne uprave i sadržano je u novom izdanju "Glavnih pravaca aktivnosti Vlade Ruske Federacije za razdoblje do 2018.", koje je potpisao premijer Ministar Dmitrij Medvedev.