Vývoj informačného systému pre účtovanie práce stavebného podniku

2. Zadanie pre tvorbu informačného systému

2.1 Všeobecné informácie

Automatizovaný informačný systém "Stavebný podnik"

2.2 Ciele tvorby informačného systému

Na riešenie problémov riadenia a účtovania projekcie, výroby a predaja v tomto podniku je vytvorený automatizovaný informačný systém, ktorý je navrhnutý v prostredí ACCESS DBMS.

Informácie vo forme distribuovanej databázy sú uložené čiastočne na súborovom serveri a čiastočne na pracovných staniciach, ktoré sú súčasťou lokálnej siete obchodného oddelenia. Druhom automatizovanej činnosti je účtovníctvo.

Hlavným pracovným prostriedkom tejto spoločnosti sú budovy podniku CJSC UniStroy - NN, v ktorých sú umiestnené nástroje automatizácie riadenia (počítače - pracovné stanice, servery, ako aj ďalšie technické zariadenia).

Hlavné funkcie, ktoré IS rieši:

· Kontrola práce podniku;

· Účtovanie tržieb spoločnosti;

· Účtovanie výsledkov (príjmy a náklady podniku).

Systematizácia a automatická kontrola nad prácou podniku, predajom, objednávkami.

2.3 Charakteristika objektov automatizácie

Hlavnou činnosťou tohto podniku je organizácia dizajnu a predaja tovaru, čo znamená, že činnosť ekonomického oddelenia pre účtovníctvo bude hlavným predmetom automatizácie.

2.4 Systémové požiadavky

2.4.1 Požiadavky na vstupné, referenčné a výstupné informácie

Vstupné informácie oddelenia dizajnu a výroby a predaja zahŕňajú údaje potrebné na vyriešenie všetkých problémov riešených v tejto jednotke. V primárnej forme tieto údaje prichádzajú vo forme papierových dokumentov. Hlavné vstupné informácie zahŕňajú nasledujúce údaje:

· Doklady z plánovacieho a ekonomického oddelenia raz mesačne, ktoré obsahujú plánované úlohy na realizáciu projekcie a predaja;

· Údaje pochádzajúce z marketingového oddelenia, ktoré obsahujú žiadosti o dodávku tovaru a vykonávanie iných prác, informácie o stanovených cenách;

Výstupná informácia môže byť prezentovaná vo forme papierového dokumentu, vo forme informačnej správy alebo vo forme súboru (elektronického dokumentu) na magnetickom nosiči.

Tieto údaje sú prezentované vo forme databázovej tabuľky, vo forme dotazu, ako aj vo forme správy na obrazovke a na papieri.

Výstupné výsledky riešenia problematiky účtovania výsledkov činnosti podniku sú odvodené:

· Do tlačiarne a na pevný disk v oddelení dizajnu a výroby av oddelení predaja;

· Sú prenášané komunikačným kanálom do účtovného oddelenia a do plánovacieho a ekonomického oddelenia.

Vydávanie výstupných údajov sa vykonáva každý štvrťrok.

2.4.2 Návrhy na kódovanie a klasifikáciu informácií

Kódovanie vstupných informácií by sa malo vykonávať s prihliadnutím na tieto požiadavky:

· Zníženie časových a iných nákladov na riešenie problémov v riadiacom systéme;

· Zabezpečenie vysokej kvality informácií.

Informačný systém využíva radový spôsob kódovania vstupných informácií (Tabuľka. Účtovanie pre návrh a výrobu, pole - číslo záznamu, Účtovanie predaja - číslo záznamu).

Tieto údaje sú zakódované pomocou ordinálnej metódy. Jeho výhodou je jednoduchosť používania, nevýhodou pretečnosť kódov.

Klasifikácia informácií.

Existujú 2 spôsoby klasifikácie:

· Hierarchický - tento spôsob klasifikácie sa chápe ako metóda, pri ktorej sa daná množina postupne delí na podriadené podmnožiny, čím sa postupne konkretizuje predmet klasifikácie. V tomto prípade slúži ako základ pre rozdelenie niektorý vybraný prvok. Úhrn výsledných zoskupení tvorí hierarchickú stromovú štruktúru vo forme vetveného grafu, ktorého uzlami sú zoskupenia.

· Fazetový - tento spôsob klasifikácie predpokladá paralelné rozdelenie množiny objektov do nezávislých klasifikačných skupín. Zároveň sa nepredpokladá tuhá klasifikačná štruktúra a vopred vytvorené konečné zoskupenia. Klasifikačné zoskupenia sú tvorené kombináciou hodnôt prevzatých z príslušných faziet.

Kvalita informácií v riadiacich systémoch je súbor vlastností, ktoré určujú vhodnosť údajov pre potreby riadiaceho systému. Najdôležitejšie vlastnosti informácií používaných v manažérskych systémoch sú:

Ш Kumulatívnosť – úplnosť informácií;

Ш Spoľahlivosť - absencia skrytých chýb;

Ш Bezpečnosť - nemožnosť neoprávneného prístupu;

Ш Efektívnosť – včasnosť;

Ш Homomorfizmus - údaje musia byť prezentované v jednej forme;

Ш Identita - zhoda objektov v súčasnosti;

Ш Dôvernosť – mlčanlivosť.

Hlavnou softvérovou metódou na kontrolu kvality informácií používaných v systéme manažérstva je:

Logicko - sémantická kontrola, teda kontrola odchýlkami, podľa danej postupnosti záznamov

· Softvér.

V tomto dokumente sa kontrola kvality informácií vykonáva pomocou tlačidla „Kontrola spoľahlivosti“. Kontrolujú sa tabuľky: produkty, projekty a účtovníctvo predaja. Ak tabuľka obsahuje záporné hodnoty výrobných nákladov, predajnej ceny, konštrukčných nákladov a množstva, po stlačení tlačidla sa zistí chyba. V opačnom prípade sa nehlásia žiadne chyby.

2.4.4 Navrhované opatrenia na ochranu informácií pred neoprávneným prístupom

Neoprávnený prístup – získavanie informácií bez povolenia ich vlastníka.

Jeho typy:

1. Nepriame - odpočúvacie zariadenia, fotografovanie na diaľku, odpočúvanie rádia a pod.

2. Priama - priama krádež dátových nosičov, ktoré čítajú dáta z disku, prihlasovanie cudzím heslom, maskovanie požiadaviek za systémové požiadavky, napadnutie softvérovými vírusmi a pod.

Najzraniteľnejšia časť informácií je chránená nasledujúcimi metódami:

· Procesno - organizačno - technické opatrenia - identifikácia všetkých počítačov a používateľov, stanovenie pracovného poriadku, špecifických databáz a programov.

Softvér - ochrana databázy a aplikačných programov pred kopírovaním, antivírusové programy, šifrovanie, zálohovanie informácií

Informačný systém využíva softvérový spôsob ochrany (antivírusová kontrola).

Databáza bola vytvorená v systéme ACCESS DBMS, pretože je viac zameraná na bežného používateľa v porovnaní napríklad s FOXPRO DBMS, ktorý je zameraný na aplikačného programátora. Výber DBMS je určený úrovňou zložitosti riadiacich úloh riešených v rámci AIS. Preto je pre túto kurzovú prácu optimálna ACCESS DBMS.

2.4.5 Požiadavky na databázu (DB) a systém správy databáz

Systém správy databáz, ktorý sa bude používať v automatizovanom systéme, je ACCES DBMS, pretože je viac zameraný na bežného používateľa a FOXPRO DBMS je viac zameraný na programátora aplikácií.

2.4.6 Hardvérové ​​požiadavky

Odporúča sa používať PC s procesorom Pentium -IV, s minimálne 256 MB RAM, s minimálne 200 GB diskovej pamäte. To zabezpečí vysokovýkonnú prevádzku LAN s akoukoľvek topológiou a operačným systémom.

Požiadavky na príslušenstvo. Pre sieťovanie sú nainštalované 32-bitové sieťové adaptéry EtherNet s protokolom ISA alebo adaptéry TokenRing s protokolom MicroChannel, prípadne sieťové adaptéry ArcNet s protokolom ISA.

Sieťová tlačiareň musí spĺňať nasledujúce požiadavky:

· Majú vysoký výkon;

· Mať dostatočnú vyrovnávaciu pamäť;

· mať vysokú spoľahlivosť práce;

· Poskytovať vysokokvalitnú tlač;

· Je žiaduce mať možnosť kopírovať dokumenty.

Na základe toho sa používa laserová tlačiareň - HP LaserJet 1100.

Pre zvýšenie spoľahlivosti siete je potrebné inštalovať neprerušiteľné zdroje UPS, najmä pre súborový server.

3. Technický pracovný projekt (dizajnové riešenie)

Automatizácia procesu vyhľadávania plagiátov

Automatizácia používateľskej podpory

V súlade s GOST 34.601-90 sa táto norma vzťahuje na automatizované systémy (AS) používané v rôznych činnostiach (výskum, dizajn, riadenie atď.), vrátane ich kombinácií vytvorených v organizáciách ...

Automatizácia výpočtov miezd na príklade OAO "Nechkinskoe" Sarapulsky okres Udmurtskej republiky pomocou programu 1C: Enterprise 8.0

Automatizovaný informačný systém pre účtovanie spotreby vody

Všeobecné informácie Celý názov systému a jeho symbol Informačný systém pre účtovanie spotreby vody na príklade spoločnosti s ručením obmedzeným „Vodosnabzhenie“ (AIS URV „Vodosnabzhenie“)...

Automatizovaný informačný systém pre účtovanie skladovania a údržby prístrojovej techniky

Zadávacie podmienky boli vypracované v súlade s GOST 34.602-89 "Informačné technológie. Súbor noriem pre automatizované systémy. Zadávacie podmienky pre vytvorenie automatizovaného systému"...

Virtuálny dekanát

Na aktualizáciu stránky z pobočky sú poskytnuté nové informácie, fotografie a mediálne súbory, ktoré je potrebné nahradiť na ktorejkoľvek zo stránok. Výmena sa vykonáva pomocou návodu na strane 2 ...

Informačný systém "Klinnik"

1. Určenie účelu vyvinutého IS Zlepšiť kvalitu zákazníckych služieb pre organizáciu, urýchliť proces papierovania. 2...

Informačná podpora ATP

Výber technickej podpory sa vykonáva s prihliadnutím na organizačnú štruktúru čerpacej stanice...

Návrh informačnej siete

Cieľom kurzu bude vybudovanie informačnej siete v mestskej vzdelávacej inštitúcii telocvičňa č. 7, fyzicky umiestnenej v jednoposchodovej budove ...

Vývoj webovej stránky organizácie (na materiáloch Avtomir LLC, Gomel)

Zvážte úroveň technickej podpory v spoločnosti Avtomir LLC. V organizácii sú všetky pracoviská automatizované. Pracoviská sú vybavené osobnými počítačmi...

Vývoj a návrh informačného systému pre salón mobilnej komunikácie s využitím Microsoft Access v programovacom jazyku Visual Basic

Jednou z etáp návrhu automatizovaného informačného systému je vypracovanie a schválenie zadávacích podmienok pre tvorbu systému. Referenčné podmienky sú hlavným dokumentom...

Vývoj informačného systému pre správcu siete organizácie LLC "WestCall"

Vývoj účtovného systému pre výpočtovú a kancelársku techniku ​​a spotrebný materiál

1 Všeobecné informácie. 1.1 Úplný názov systému a jeho symbol „Bentec IT & Soft invent“ 2. Účel a účel systému. 2.1 Účel systému...

Vývoj zadávacích podmienok pre automatizáciu obchodu "Bukva"

Všeobecné informácie Názov systému automatizovaného účtovného systému pre činnosť obchodu "Bukva-Serov". Podnikový zákazník - OOO "Etalon"...

Vytvorte tímovú lokalitu

1) Typ produktu: Webová stránka dynamickej skupiny; 2) Účel: Vytvorenie skupinovej webovej stránky na uľahčenie informovania študentov skupiny počas mimoakademických a akademických hodín; 3) Cieľová skupina: Študenti skupiny a učitelia univerzity; 4) Požiadavky na stránku: 1) Pohodlné ...

TECHNICKÁ ÚLOHA

na vývoj informačného systému

1. Všeobecné informácie

4. Systémové požiadavky

6. Postup kontroly a preberania systému

1. Všeobecné informácie

V súlade so zmluvou č. MP23 medzi TechnoPlus LLC (ďalej len Developer) a OptoTrading LLC (ďalej len Zákazník) Developer navrhne databázu, vyvinie a uvedie do prevádzky informačný systém „Účtovníctvo obchodných operácií“

Dňom začatia tvorby návrhu BDB je deň nasledujúci po podpise týchto zadávacích podmienok

Ak počas procesu vývoja zákazník zmení požiadavky popísané v tomto dokumente, potom sú tieto spracované ako samostatný dokument a majú za následok zmenu alebo doplnenie zmluvy medzi zákazníkom a vývojárom databázy, pokiaľ ide o termín implementácie a platby. dohody

Objednávateľ platí za prácu Developera DB v zmysle zmluvy N XXX

2. Účel a ciele tvorby (vývoja) systému

IS "Účtovníctvo obchodných operácií" je určený na uchovávanie, spracovanie a analýzu informácií súvisiacich s hlavnými činnosťami Zákazníka.

Účelom vytvorenia IS „Účtovníctvo obchodných operácií“ je:

Ukladanie informácií o dokončených obchodných operáciách;

Premietnutie obchodných operácií do účtovníctva;

Analýza finančných výsledkov obchodných operácií;

Analýza obchodnej činnosti v kontexte nomenklatúry a protistrán.

3. Charakteristika objektov automatizácie

3.1. Hlavnou činnosťou Zákazníka je predaj nábytku a súvisiacich produktov bankovým prevodom.

3.2. Zákazník nie je platcom DPH

3.3. Zákazník počas dňa vykoná najviac 100 obchodných operácií na nákup a predaj tovaru.

3.4. Celkový sortiment tovaru nepresahuje 3000 kusov

3.5. Celkový počet dodávateľov - dodávateľov nie je väčší ako 100 jednotiek.

3.6. Počet protistrán – kupujúcich – nie je obmedzený. V čase podpisu zmluvy N XXX bolo 300 jednotiek.

3.7. Zákazník odpíše tovar zo skladu podľa metódy váženého priemeru nákladov.

3.9. Ako nákladové účty sa používajú iba účty triedy 9.

3.10. Finančné výsledky obchodnej činnosti podniku (peňažný tok a prevádzkový peňažný tok) sa vypočítavajú na základe maloobchodných príjmov 702 a 902.

3.11. Obchodné transakcie sú zaznamenané v primárnych dokladoch Došlá faktúra, Odoslaná faktúra, Bankový výpis.

Príbutkov nákladný list (PN) skontrolujte skutočnosť, že tovar bol doručený do skladu pіdpriєmstva a uveďte tieto informácie:

- izba;

- dátum;

– meno protistrany (firma – zamestnanec po skončení zamestnania);

– Meno Produktu;

- množstvo;

– cіnu jediný produkt;

- súčet.

Vidatkov nákladný list (VN) vіdobrazhuє fakt vіdvantazhennya tovar zі sklad pіdpriієmstva nákup a mіstit іnformacіyu, idem na informácie v PN (iba zástupca spoločnosti-poštový pracovník na objednávku spoločnosti-nákup).

Riadok bankového účtu potvrdzujúce skutočnosť, že / vibuttya koshtіv іz rozrahunkovy rahunka (r / r) je potrebné prijať a pomstiť nasledujúce informácie:

- dátum;

– znamenie príchodu / vitrati koshtiv;

– meno protistrany (koho ste dostali / komu boli peniaze vyplatené).

3.12. Primárny dokument kože є pіdstavoy pre zdіysnennya pevnih príspevky, yakі zdіysnyuyut zmіni snіh účtovníctvo rakhunkіv. Prevádzka živnostenského podniku vyžaduje takéto vyslanie (tabuľka 3.1)

Tabuľka 3.1 - Účtovanie používané v účtovníctve v podniku Zákazníka

Prevádzka	dokument	Debet z účtu	Úver na účet	Suma zaúčtovania
Uverejnenie	Nákupná faktúra			suma dokladu
Preprava tovaru	Faktúra			suma dokladu
				náklady na odoslaný tovar
Príjem peňazí na bežný účet	bankový výpis (potvrdenie)			suma dokladu
Prevod peňazí z bežného účtu	výpis z účtu (výdavok)			suma dokladu
Definícia finančných výsledkov				na sumu uzávierkových 902 účtov
				na sumu uzávierkových 702 účtov

de 281 - tovar na sklade;

311 - rozrahunkovy rahunok v mene krajiny;

361 - rozrahunki s nákupmi vіtchiznyanimi;

631 - rozrakhunki s votchiznyani post-zamestnancami;

702 - príjem z predaja tovaru;

902 - zber predaného tovaru (vitrati).

3.13. Z hľadiska účtovníctva zvіtnostі vykoristovuєtsya obrat-súvaha syntetického vzhľadu vyzerá v tabuľke 3.2.

Tabuľka 3.2 - Bilančná hodnota obratu syntetického vzhľadu

Číslo pozície	Cobova rovnováha	Vlkolak	Kіntseve rovnováha
spolu

4. Systémové požiadavky

IS "Účtovníctvo obchodných operácií" musí spĺňať nasledovné požiadavky:

4.1. Databáza pre IS "Účtovníctvo obchodných operácií" by mala zabezpečovať ukladanie, zobrazovanie a editáciu referenčných a prevádzkových informácií.

Referenčné informácie:

o popis tovaru:

Nomenklatúrne (produktové) číslo;

Meno Produktu;

Popis;

o kontraktori – dodávatelia;

číslo protistrany;

meno protistrany;

adresa protistrany;

Kontakty;

o protistrany – kupujúci;

číslo protistrany;

meno protistrany;

adresa protistrany;

Kontakty;

o účtovú osnovu, na ktorej sa účtuje o obchodných operáciách a analyzuje finančné výsledky;

o zoznam základných účtov pre zobrazenie obchodných operácií v účtovníctve, spôsobených prvotnými dokladmi, ktoré majú nasledujúcu podobu ako v tabuľke 3.1;

Operatívne informácie:

o Primárne doklady: Faktúra, Odoslaná faktúra, Bankový výpis (popis dokladov je uvedený v 3.11)

o Účtovné zápisy spôsobené prvotnými dokladmi (typ zápisov je uvedený v tabuľke 3.2)

o Informácie o tovare na sklade:

Číslo položky;

množstvo;

súčet;

Priemerná cena.

4.2. IS "Účtovanie obchodných operácií" by vám mal umožniť automatizovať nasledujúce akcie:

4.2.1 Zohľadniť skutočnosti zaúčtovania (prijatia) a expedície tovaru na sklade, a to prepočítať množstvo tovaru na sklade a jeho priemernú cenu.

4.2.2 Vytváranie účtovných zápisov podľa prvotných dokladov v automatickom režime.

4.2.3 Vyhľadajte nasledujúce informácie:

Primárne dokumenty určeného typu za určité obdobie;

Účtovanie pre určený typ dokladov k určitému dátumu;

Informácie o protistrane

Informácie o produkte

4.2.4 Vykonať analýzu obchodnej činnosti za uvedené obdobie v nasledujúcich častiach:

Finančné výsledky obchodných aktivít;

výsledky vyrovnaní pre každú protistranu;

Zvyšky tovaru na sklade pre každú položku;

náklady na transakcie pre každú protistranu;

Náklady a množstvo predaja pre každý druh tovaru

4.2.5 Generovanie správ za zadané obdobie:

Zariadenia, na ktorých je integrovaný obvod nainštalovaný, musia byť vybavené neprerušiteľným zdrojom napájania. V prípade výpadku prúdu by sa mal IC automaticky vypnúť bez straty dát.

IS musí zabezpečovať záložné mechanizmy, IS musí byť vybavený vhodným hardvérom a softvérom:

Kvantitatívne hodnoty ukazovateľov spoľahlivosti:

- čas automatického vypnutia by nemal byť dlhší ako 1 minúta;

- čas zotavenia po zlyhaní by nemal byť dlhší ako 30 minút;

- indikátor odolnosť proti chybám IS by mal byť 11/7, t.j. nepretržitá prevádzka IS 11 hodín denne, 7 dní v týždni.

Údržba IS by sa mala vykonávať bez prerušenia jeho prevádzky.

4.5 Požiadavky na metódy hodnotenia a sledovania ukazovateľov spoľahlivosti v štádiu skúšobnej prevádzky

Pre kontrolu ukazovateľov spoľahlivosti v etapách skúšobnej prevádzky IS musí personál údržby viesť denník porúch, ktorý musí obsahovať tieto informačné znaky:

Dátum výskytu chyby;

Celkový prevádzkový čas objektu od začiatku jeho prevádzky až do zistenia chyby;

Vonkajšie znaky a povaha chyby;

Typ práce, v ktorej bola chyba zistená.

4.6 Požiadavky na výkon IC

Systém musí podporovať schopnosť spracovať až 1000 dokumentov denne

Systém musí mať nasledujúci výkon:

80 % operácií by malo mať čas odozvy (čas prevádzky) kratší ako 1 sekunda;

15 % operácií - od 5 sek. až 10 sekúnd;

5% operácií - viac ako 10 sekúnd, ale nie viac ako 30 minút.

4.7 Požiadavky na objem (škálovateľnosť)

Systém musí podporovať prístup k údajom po dobu 10 rokov.

Odhadovaný nárast objemu databázy za jeden deň prevádzky je 20Mb.

4.8 Požiadavky na počet, funkcie a kvalifikáciu personálu IS a spôsob ich prevádzky

Práce s IS budú vykonávať nasledovní pracovníci objednávateľa:

správca:

Množstvo: 1;

Kvalifikácia: správca siete, správca databázy;

Funkcie: riadenie bezpečnosti systému, zálohovanie dát na začiatku každého pracovného dňa, archivácia dát raz ročne;

Pracovná doba: 1 hodina denne, 5 dní v týždni

Prevádzkovateľ (používateľ), ktorý fixuje skutočnosť obchodnej operácie a analyzuje výsledky obchodných aktivít:

Množstvo: 2;

Kvalifikácia: účtovník, používateľ PC;

Funkcie: zadávanie primárnych dokladov, udržiavanie aktuálneho stavu informácií o sklade, tvorba účtovných zápisov, analýza výsledkov obchodnej činnosti, zálohovanie dát na začiatku pracovného dňa, pripadajúce na sobotu a nedeľu.

Režim prevádzky: v smenách na zabezpečenie prevádzky systému 11 hodín denne, 7 dní v týždni;

Prístup k práci: 8-hodinový školiaci kurz;

Personál musí pred uvedením IS do prevádzky absolvovať 8-hodinové školenie, aby získal pracovné povolenie. Po absolvovaní kurzu sa robí test, pri ktorom sa hodnotí správnosť a rýchlosť riešenia praktických úloh, ako aj znalosť pracovných a technických pokynov.

Systém by mal poskytovať prístup k svojim funkciám len registrovaným užívateľom IS zadaním hesla.

4.10 Požiadavky na programové vybavenie a zloženie, štruktúru a spôsob organizácie IS DB

Údaje v Systéme musia byť uložené v relačnej DBMS MS SQL Server 2000.

- T-SQL (dialekt jazyka SQL);

OD #.

Softvér pozostáva zo všeobecného systémového softvéru zakúpeného na náklady Objednávateľa (zakúpený softvér) a špeciálneho softvéru vyvinutého v rámci prác na tvorbe IS.

Ako softvér pre celý systém sa musí použiť nasledujúci softvér:

Operačný systém;

Systém správy databáz MS SQL Server 2000;

Zálohovací softvér;

4.11 Hardvérové ​​požiadavky

Databázový server, 2 pracovné stanice.

Šírka pásma siete - 100 Mbps.

4.12 Požiadavky na perspektívy rozvoja, modernizácie IS

Modernizáciu a rozvoj IS by mal byť možný bez zapojenia Developera zo strany správcu IS na úrovni:

- pridávanie, zmena, vymazanie referenčných informácií IS;

- pripojenie/vymazanie nových používateľov IP;

- zmeny hesla;

- import/export údajov z/do externých zdrojov údajov.

Upgradovať a rozvíjať IS by malo byť možné s obmedzenou účasťou Developera (telefonické konzultácie) na úrovni aktualizácie starých reportov a vytvárania nových reportov. Možnosť a podmienky telefonického poradenstva Developera o modernizácii IP sú dojednané samostatne podpisom novej zmluvy.

5. Skladba a obsah práce na tvorbe systému

Práce na návrhu IS „Účtovníctvo obchodných operácií“ prebiehajú v troch etapách.

Prvá etapa zahŕňa:

Preverenie možnosti získať všetky informácie požadované Zákazníkom na základe prvotných údajov;

návrh IS DB;

Naplnenie vyvinutej databázy súborom testovacích údajov;

Vývoj dizajnu používateľského rozhrania;

Vypracovanie nízkoúrovňovej technickej špecifikácie pre vývoj IS "Účtovníctvo obchodných operácií"

Ukončenie I. etapy je potvrdené podpisom interného zákona o vykonaných prácach a schválením nízkoúrovňovej technickej špecifikácie rozvoja IS.

Druhou etapou je vývoj testovacej verzie IS „Účtovníctvo obchodných operácií“. Záverom tejto etapy je uvedenie testovacej verzie do skúšobnej prevádzky.

Treťou etapou je pilotná prevádzka IS „Účtovníctvo obchodných operácií“, ktorá zahŕňa odstraňovanie zistených chýb, nedostatkov a nezrovnalostí s týmto Zadávacím podmienkami. Záverom druhej etapy je uvedenie IS do komerčnej prevádzky.

Ukončenie každej druhej a tretej etapy potvrdia zmluvné strany podpisom Osvedčenia o prevode a prevzatí.

Trvanie prvej etapy je 10 dní. Za začiatok prvej etapy sa považuje deň nasledujúci po dni podpisu týchto Podmienok Zákazníkom a Vývojárom DB.

Trvanie druhej etapy je 20 dní. Začiatok druhej etapy je deň nasledujúci po dni schválenia nízkoúrovňovej technickej špecifikácie vývoja IS.

Trvanie tretej etapy je 20 dní. Za začiatok tretej etapy sa považuje deň nasledujúci po dni podpisu Objednávateľa a Vývojára DB Certifikátu o prevzatí a odovzdaní testovacej verzie IS do skúšobnej prevádzky.

Dátový súbor pre testovanie IS poskytuje Zákazník.

Po ukončení druhej etapy prác Vývojár DB nainštaluje testovací IS na testovací server Zákazníka a poskytne Zákazníkovi predbežnú používateľskú príručku obsahujúcu popis postupov potrebných pre prácu s IS Obchodné účtovníctvo. Popisy sú poskytované elektronicky.

Na konci tretej etapy práce vývojár DB poskytne zákazníkovi program na inštaláciu databázy na server, ako aj pokyny pre používateľa, programátora a pokyny na inštaláciu IS s popisom potrebných postupov. na prácu s IS „Účtovníctvo živnostenských operácií“.

6. Postup kontroly a akceptácie systému

Na konci prvej etapy je podpísaný interný zákon o vykonaných prácach a schválená technická špecifikácia nízkej úrovne pre vývoj IS.

Na konci druhej a tretej etapy projektovania Developer nainštaluje IS u Zákazníka, preukáže prevádzku IS v súlade s požiadavkami uvedenými v týchto podmienkach a podpíše Certifikát o prevode a prevzatí.

7. Požiadavky na skladbu a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky

Zákazník je povinný v deň začatia skúšobnej prevádzky poskytnúť Vývojárovi potrebný prístup na server, na ktorom bude nasadená testovacia verzia IS Účtovníctvo obchodných operácií.

Absencia servera pre inštaláciu databázy IS "Účtovníctvo živností" nemôže byť dôvodom na odmietnutie podpísania Potvrdenia o prevzatí a prevode IS "Účtovníctvo živnosti" na skúšobnú alebo komerčnú prevádzku.

Na konci druhej etapy vývoja IS „Účtovanie obchodných operácií“ absolvuje Developer 8-hodinové školenie s pracovníkmi objednávateľa o obsluhe IS. Na konci tohto kurzu je personál zákazníka preskúšaný.

8. Požiadavky na dokumentáciu

Na konci tretej etapy Vývojár IS „Účtovanie obchodných operácií“ odovzdá Zákazníkovi nasledujúcu dokumentáciu:

1. Pokyny programátora.

Príručka programátora popisuje postupy potrebné pre prácu s IS „Účtovanie obchodných operácií“. Opis postupov zahŕňa:

názov postupu;

Popis činností vykonaných postupom;

Pre parameter je definovaný popis vstupných parametrov s uvedením typu parametra, formátu jeho záznamu a prípadnej predvolenej hodnoty;

Popis výstupných parametrov a (alebo) vrátených sád záznamov s uvedením ich typov a formátov

Príklad volania procedúry a jej návratových hodnôt. Ak postup môže mať viacero možností volania, potom príklady pre každú možnosť.

2. Návod na inštaláciu IS „Účtovníctvo obchodných operácií“.

3. Pokyny pre používateľa IS „Účtovanie obchodných operácií“.

Iná dokumentácia sa Zákazníkovi neposkytuje. Pokyny sú poskytované v tlačenej aj elektronickej forme. Pokyny v tlačenej forme sú poskytované v jednom vyhotovení.

Odoslanie dobrej práce do databázy znalostí je jednoduché. Použite nižšie uvedený formulár

Študenti, postgraduálni študenti, mladí vedci, ktorí pri štúdiu a práci využívajú vedomostnú základňu, vám budú veľmi vďační.

Hostené na http://www.allbest.ru/

• Úvod
• 1. Referenčné podmienky
• 1.1 Všeobecné informácie
• 1.2 Základ pre rozvoj
• 1.3 Účel a ciele tvorby systému
• 1.4 Systémové požiadavky
• 1.4.1 Požiadavky na systém ako celok
• 1.4.2 Požiadavky na funkcie (úlohy) vykonávané systémom
• 1.4.3 Požiadavky na typy kolaterálu
• 1.5 Charakteristika objektov automatizácie
• 1.6 Požiadavky na dokumentáciu
• 1.7 Etapy a štádiá vývoja
• 1.7.1 Etapy vývoja
• 1.7.2 Etapy vývoja
• 1.7.3 Obsah práce po etapách
• 1.8 Postup kontroly a akceptácie systému
• 1.8.1 Typy, zloženie, rozsah a skúšobné metódy systému a jeho komponentov
• 1.8.2 Všeobecné požiadavky na preberanie prác po etapách
• 1.8.3 Postavenie akceptačnej komisie (štátna, medzirezortná, rezortná)
• 2. Technický projekt
• 2.1 Funkčná štruktúra
• 2.1.1 Popis predmetnej oblasti
• 2.1.2 Funkcie a organizačná štruktúra
• 2.1.3 Popis dátových tokov a obchodných procesov
• 2.2 Návrh IC systému
• 2.2.1 Vývoj koncepcie, architektúry výstavby a platformy pre implementáciu IS
• 2.2.2 Štruktúra informačného systému, skladba funkčných a podporných subsystémov
• 2.2.3 Technická podpora IS
• 2.3 Informačná podpora IP
• 2.3.1 Popis logickej štruktúry infobázy
• 2.3.2 Popis fyzickej implementácie databázy
• Záver
• Bibliografia

Úvod

Predmetová práca sa zaoberá tvorbou zadávacích podmienok pre vývoj informačného systému pre systém agentúry na predaj a rezerváciu leteniek. Cieľom práce je naštudovať si základné princípy a získať základné zručnosti pri príprave technických špecifikácií pre vývoj informačných systémov a ich programového vybavenia.

Práce na tvorbe informačného systému začínajú formovaním požiadaviek zákazníka na vytváraný systém a ich realizáciou formou technickej úlohy (TOR). TOR je hlavný dokument, ktorý definuje požiadavky a postup na vytvorenie automatizovaného systému, v súlade s ktorým je systém vyvinutý a akceptovaný pri uvedení do prevádzky. Okrem toho sa na základe TOR vykonáva výpočet práce, špecifikujú sa mzdové náklady.

TK pozostáva z troch fáz:

1. zdôvodnenie potreby rozvoja informačného systému - vyjadrenie problému, zber podkladov, výber a zdôvodnenie kritérií efektívnosti a kvality vyvinutého systému, zdôvodnenie potreby výskumu;

2. VaV - určenie štruktúry vstupných a výstupných údajov, predbežný výber metód riešenia problémov, zdôvodnenie realizovateľnosti použitia vyvinutého systému, stanovenie požiadaviek na technické prostriedky, zdôvodnenie zásadnej možnosti riešenia problému;

3. vývoj a schvaľovanie TOR - stanovenie požiadaviek na programy, vypracovanie štúdie realizovateľnosti systému, určenie etáp, etáp a termínov vývoja systému a dokumentácie k nemu, výber programovacích jazykov, určenie potreby pre výskum a vývoj v posledných fázach, koordinácia a schvaľovanie TOR.

TK vykonáva tieto funkcie:

Organizačná funkcia - pevná úloha pre Dodávateľa a konečné požiadavky od Objednávateľa.

Informačná funkcia - objednávka v procese dodávateľa a ohľaduplnosť prianí zo strany objednávateľa.

Komunikačná funkcia - vzájomná dohoda o "predmete projektu" s výnimkou reklamácií.

Právna funkcia - CK má rovnakú právnu silu ako "Zmluva".

Výsledok vypracovaného technického projektu do značnej miery závisí od úplnosti a presnosti prípravy technických špecifikácií.

1. Referenčné podmienky

1.1 Všeobecné informácie

Úplný názov systému a jeho symbol: „Automatizovaný informačný systém agentúry pre predaj a rezerváciu leteniek“. Stručný popis rozsahu

Systém je určený pre použitie v organizácii zákazníka, v našom prípade agentúry na predaj a rezerváciu leteniek.

Objednávka registrácie a prezentácie výsledkov prác na vytvorení systému (jeho častí), na výrobe a úprave jednotlivých nástrojov (hardvér, softvér, informácie) a softvérových a hardvérových (softvérových a metodických) systémov zákazníkovi. systému: AIS "Ticket" je dodávaný vo forme spustiteľných modulov podľa dokončenia celého rozsahu prác, technické prostriedky si objednávateľ kupuje samostatne. Registrácia výsledkov práce na vytvorení systému sa vykonáva podpísaním aktu o prijatí systému Zákazníkom v prípade neexistencie nárokov voči Vývojárovi. Zákon je vyhotovený v dvoch vyhotoveniach. Jedna kópia je u zákazníka, druhá u Vývojára.

1.2 Základ pre rozvoj

Podkladom pre vypracovanie zadávacích podmienok je úloha pre kurzovú prácu na predmete „Dizajn informačných systémov“.

Názov rozvojovej témy je „Vývoj informačného systému pre agentúru na predaj a rezerváciu leteniek“

Symbol témy vývoja (kód témy) - "IS APB"

1.3 Účel a ciele tvorby systému

Funkčný účel systému: AIS "Ticket" je určený na automatizáciu práce agentúry pre predaj a rezerváciu leteniek.

Prevádzkový účel systému: Systém musia obsluhovať zamestnanci organizácie.

Účel systému: Systém zrýchľuje proces objednávania leteniek a tým zjednodušuje prácu agentúry.

1.4 Systémové požiadavky

1.4.1 Požiadavky na systém ako celok

Požiadavky na štruktúru a fungovanie systému

Zoznam subsystémov, ich účel a hlavné charakteristiky, požiadavky na počet úrovní hierarchie a stupeň centralizácie systému

AIS "Ticket" zahŕňa nasledujúce podsystémy:

Prijatie objednávky;

Vydanie lístka;

Účtovníctvo so zákazníkom.

Na evidenciu objednávky leteniek je určený podsystém „Akceptácia objednávky“.

Subsystém „Vyrovnanie so zákazníkom“ poskytuje zákazníkovi rezervačné číslo spojené s údajmi z pasu (platba kartou).

Požiadavky na spôsoby a prostriedky komunikácie na výmenu informácií medzi komponentmi systému:

Výmena informácií sa uskutočňuje prostredníctvom lokálnej siete.

Požiadavky na prevádzkové režimy systému:

Systém musí podporovať režimy pre viacerých používateľov a offline. Používatelia pristupujú do systému cez internet alebo Call-centrum.

Požiadavky na počet a kvalifikáciu personálu systému

Požiadavky na kvalifikáciu personálu, postup pri jeho výcviku a kontrolu vedomostí a zručností:

Recepčný by mal ovládať prácu s PC na užívateľskej úrovni. Počet zamestnancov sa môže líšiť v závislosti od objemu objednávok.

Požiadavky na spoľahlivosť

Obnova systému v prípade chýb v prevádzke hardvéru (okrem dátových nosičov a programov) a chýb súvisiacich so softvérom (ovládače OS a zariadení), za obnovu zodpovedá OS.

V prípade porúch v napájacom systéme hardvéru, ktoré vedú k reštartu OS, by mal byť program obnovený po reštarte OS a spustení spustiteľného súboru systému.

Funkčnosť systému ako celku by mala byť zabezpečená aj v prípade porúch, havárií a porúch na jednotlivých pracoviskách. Na ochranu zariadenia pred napäťovými rázmi a rušením pri spínaní by sa mali používať sieťové filtre, a aby si používateľ mohol uložiť dáta v prípade výpadku napájania, odporúča sa použiť neprerušiteľné zdroje napájania.

Bezpečnostné požiadavky

Zákazník zabezpečuje, aby technické riešenia použité pri úprave a vývoji subsystému vyhovovali aktuálnym normám, bezpečnostným predpisom, požiarnej bezpečnosti a ochrane pred výbuchom a ochrane životného prostredia.

Požiadavky na prevádzku, údržbu, opravy a skladovanie komponentov systému

Prevádzkové podmienky, ako aj druhy a frekvencia údržby technických prostriedkov subsystému musia zodpovedať požiadavkám na prevádzku, údržbu, opravy a skladovanie stanoveným v dokumentácii výrobcu (výrobcu) k nim.

Požiadavky na ochranu informácií o• neoprávnený prístup

Na ochranu informácií pred neoprávneným prístupom musí systém poskytovať:

a) identifikácia a autentifikácia používateľa;

b) kontrola práv a obmedzení prístupu užívateľov na úrovni funkcií a dátových polí pri práci so systémom.

Požiadavky na bezpečnosť informácií v prípade nehôd

Je potrebné zabezpečiť možnosť zálohovania systémových dát pomocou softvéru dodávaného Vývojárom.

Požiadavky na štandardizáciu a unifikáciu

Pre tento systém by sa mal použiť kaskádový model životného cyklu softvéru.

Systém by mal používať (v prípade potreby) celoruské klasifikátory a jednotné klasifikátory a slovníky pre rôzne typy alfanumerických a textových informácií.

Rozhranie systému, súbory pomocníka a všetky textové informácie v programe musia byť v ruštine.

Obrazovkové formuláre by mali byť navrhnuté s ohľadom na požiadavky zjednotenia:

Všetky formy obrazovky používateľského rozhrania by mali byť vyhotovené v jednom grafickom dizajne s rovnakým usporiadaním hlavných ovládacích prvkov a navigácie.

1.4.2 Požiadavky na funkcie (úlohy) vykonávané systémom

Pre každý subsystém zoznam funkcií, úloh alebo ich komponentov (vrátane tých, ktoré zabezpečujú interakciu častí systému), ktoré podporujú automatizáciu

Informačný systém by mal poskytovať tieto funkcie:

subsystém prijímania objednávok,

Subsystém zúčtovania s klientom.

1.4.3 Požiadavky na typy kolaterálu

K informačnej podpore systému

Ku zloženiu, štruktúre a spôsobom usporiadania údajov v systéme

Systémové dáta sú uložené na jednom lokálnom počítači. Popis objednávky sa odošle na vstup systému, na výstupe musí byť faktúra a identifikačné číslo objednávateľa.

K štruktúre procesu zberu, spracovania, prenosu údajov v systéme a prezentácie údajov.

Údaje sa do systému zadávajú ručne, spracúvajú a vydávajú sa užívateľovi v požadovanej forme (elektronická, tlačená).

Na ochranu údajov pred zničením počas nehôd a výpadkov napájania systému

Súčasťou komplexu technických prostriedkov by mal byť neprerušiteľný zdroj energie. Práca tohto zdroja by mala byť aspoň pol hodiny na správne vypnutie systému.

Na ovládanie, ukladanie, aktualizáciu a obnovu údajov

Systém musí podporovať automatické denné zálohovanie.

Požiadavky na systémový softvér

Systém musí bežať na operačných systémoch Windows XP/Vista/7/8

Hardvérové ​​požiadavky systému

K typom technických prostriedkov vrátane typov komplexov technických prostriedkov, softvérových a hardvérových komplexov a iných komponentov, ktoré sú prijateľné na použitie v systéme.

Pracovné stanice;

Jednotka neprerušovaného napájania;

Médium na prenos údajov medzi pracovnými stanicami (napríklad krútená dvojlinka UTP 5e);

Tlačiareň.

Technické prostriedky si objednávateľ kupuje samostatne.

K funkčným, konštrukčným a prevádzkovým charakteristikám prostriedkov technickej podpory systému.

Procesor Intel Pentium IV 2 GHz alebo vyšší, RAM aspoň 2 GB, miesto na pevnom disku aspoň 500 GB.

telesné požiadavkysystémová izolácia

Pre organizačnú podporu sú stanovené tieto požiadavky:

K štruktúre a funkciám jednotiek zapojených do fungovania systému alebo zabezpečovania prevádzky.

Fungovanie systému zabezpečuje systémový inžinier, na prevádzke sú zapojení 4 pracovníci.

K organizácii fungovania systému a poriadku interakcie medzi personálom JE a personálom objektu automatizácie.

Organizačná podpora by mala postačovať na efektívne plnenie úloh, ktoré mu boli zverené pri implementácii funkcií systému.

Na ochranu pred chybnými činnosťami personálu systému.

Ochrana proti personálnym chybám spočíva v kontrole vypĺňania údajov v niektorých poliach, možnosti obnovenia pôvodných údajov a zrušení posledných zmien, vymedzení prístupu podľa funkcií a právomocí zamestnancov.

1.5 Charakteristika objektov automatizácie

Stručné informácie o objekte automatizácie alebo odkazy na dokumenty obsahujúce takéto informácie

Objekt automatizácie je proces spojený s objednávaním leteniek.

Informácie o prevádzkových podmienkach objektu automatizácie a charakteristikách prostredia

Tento systém bude inštalovaný v priemyselných a kancelárskych priestoroch.

1.6 Požiadavky na dokumentáciu

Pre systém v rôznych fázach tvorby by sa mali vydať tieto dokumenty:

Schéma organizačnej štruktúry;

Schéma funkčnej štruktúry;

Zoznam vstupných signálov a údajov;

Zoznam výstupných signálov (dokumentov);

Vysvetlivka k technickému projektu;

Popis automatizovaných funkcií;

Popis nastavenia úlohy (súboru úloh);

Popis organizácie informačnej základne;

Popis súboru informácií;

Popis softvéru;

Užívateľská príručka.

1.7 Etapy a štádiá vývoja

1.7.1 Etapy vývoja

Vývoj by sa mal uskutočniť v 6 etapách:

1. Vývoj zadávacích podmienok

2. Vypracovanie projektovej dokumentácie

3. Vytvorenie návrhu návrhu

4. Detailný dizajn

5. Uvedenie do prevádzky

6. Údržba a modernizácia

1.7.2 Etapy vývoja

Vo fáze vypracovania zadávacích podmienok musí byť dokončená fáza vypracovania, koordinácie a schválenia tohto zadania.

Vo fáze vypracovania projektovej dokumentácie by mala byť dokončená fáza spracovania projektovej dokumentácie.

Vo fáze vytvárania návrhu dizajnu musí byť dokončený návrh dizajnu na predbežné predloženie zákazníkovi.

Vo fáze podrobného návrhu by sa mali vykonať tieto etapy práce:

1) vývoj informačného systému;

2) vypracovanie dokumentácie.

Vo fáze implementácie je potrebné dokončiť prípravu a odovzdanie programu zákazníkovi.

V etape údržby a modernizácie by sa malo pracovať na zlepšení súčasnej verzie informačného systému.

Vo fáze vývoja zadávacích podmienok by sa mali vykonať tieto práce:

1) vyhlásenie o probléme;

2) definícia a špecifikácia požiadaviek na technické prostriedky;

3) stanovenie požiadaviek na informačný systém;

4) určenie etáp, etáp a termínov rozvoja informačného systému a dokumentácie k nemu;

5) odôvodnenie a výber nástrojov;

6) koordinácia a schvaľovanie zadávacích podmienok.

Vo fáze vypracovania projektovej dokumentácie by sa mali vykonať tieto práce:

1) definícia hlavných obchodných procesov (vo forme diagramov IDEF0);

2) určenie hlavných prípadov použitia Systému pre tri kategórie používateľov (Hosť, Autorizovaný používateľ, Administrátor) vo forme UML diagramov prípadov použitia;

3) návrh štruktúry databázy vo forme (ER diagram);

4) navrhovanie hlavných komponentov a algoritmov systému vo forme vhodných UML diagramov;

5) navrhovanie štruktúry používateľského rozhrania;

6) koordinácia a schvaľovanie projektovej dokumentácie.

Vo fáze vývoja by sa malo pracovať na vývoji informačného systému na základe projektovej dokumentácie, kódovania a ladenia.

Vo fáze tvorby dokumentácie by sa malo uskutočniť vypracovanie politických dokumentov v súlade s požiadavkami. "Predbežné zloženie programovej dokumentácie" tohto zadávacieho poriadku.

V štádiu prípravy a prenosu programu sa musí pracovať na príprave a odovzdaní programu a programovej dokumentácie do prevádzky.

Vo fáze vylepšovania aktuálnej verzie systému by sa malo pracovať na vytvorení nových verzií systému a pridaní nových funkcií do starej verzie.

1. Analýza požiadaviek na IP

2. Koordinácia požiadaviek so zákazníkom

3. Výber a vypracovanie variantu koncepcie systému

4. Vypracovanie zadania a projektu

5. Koordinácia a schvaľovanie zadávacích podmienok a projektu

6. Vypracovanie plánu práce

7. Príprava hardvéru

8. Vývoj softvéru

9. Skontrolujte kompatibilitu hardvéru a softvéru

10. Integrácia a testovanie softvéru a hardvéru

11. Vykonávanie zmien

12. Vypracovanie návodu na obsluhu IS

13. Registrácia kompletnej dokumentácie pre IP

14. Doručenie IP zákazníkovi

Tabuľka 1 - Počiatočné údaje pre výpočet

Úloha č.	Zoznam prác	Trvanie práce, dni
	1. Analýza požiadaviek na IP
	2. Koordinácia požiadaviek so zákazníkom
	3. Výber a vypracovanie variantu koncepcie systému
	4.Vypracovanie zadania a projektu
	5. Koordinácia a schvaľovanie zadávacích podmienok a projektu
	6. Vypracovanie plánu práce
	7. Príprava hardvéru
	8.Vývoj softvéru
	9. Kontrola kompatibility hardvéru a softvéru
	10.Integrácia a testovanie softvéru a hardvéru
	11. Vykonávanie zmien
	12.Vypracovanie návodu na obsluhu IS
	13. Registrácia kompletnej dokumentácie pre IP
	14. Doručenie IP zákazníkovi

Obrázok 1 – Stanovenie cieľov

Obrázok 2 - Ganttov diagram

Obrázok 3 - Sieťový harmonogram vykonávania prác

Kritická cesta siete bude: 0 1 2 3 4 5 6891011121314

Tabuľka 2 - Časové parametre udalostí

Číslo udalosti	Načasovanie udalosti	Rezervovať čas

Tabuľka 3 - Výpočet plných a voľných časových rezerv

	Trvanie, dni	Časové parametre práce, dni	Plná rezerva	Bezplatná rezerva
		skorý štart	skorý koniec	neskorý začiatok	neskorý koniec

1.8 Postup kontroly a akceptácie systému

1.8.1 Typy, zloženie, rozsah a skúšobné metódy systému a jeho komponentov

Systém sa testuje zadaním veľkého množstva údajov, zadaním rovnakých informácií, informácií iného typu údajov, údajov väčšieho rozsahu. Kontroluje sa súlad obrazovkových formulárov s popisom v používateľskej príručke (testovanie rozhrania).

1.8.2 Všeobecné požiadavky na preberanie prác po etapách

Dodanie a prevzatie je realizované komisiou, ktorej členmi sú zástupcovia objednávateľa a zhotoviteľa. Na základe výsledkov preberania je podpísaný akt preberacej komisie.

Všetky softvérové ​​produkty vytvorené v rámci tejto práce sú odovzdané objednávateľovi ako vo forme hotových modulov, tak aj vo forme zdrojových kódov prezentovaných v elektronickej podobe na štandardnom strojovom médiu (na CD).

1.8.3 Postavenie akceptačnej komisie (štátna, medzirezortná, rezortná)

Stav akceptačnej komisie určuje Zákazník pred testovaním.

2. Technický projekt

2.1 Funkčná štruktúra

2.1.1 Popis predmetnej oblasti

Predmetom činnosti je agentúra zaoberajúca sa predajom a rezerváciou leteniek.

Podnik má administratívne oddelenie (pozostáva z účtovníka a manažéra), oddelenie prevádzky pracovnej stanice (riadenie informačných technológií) (správca systému a technici) a operátorov.

Za kvalitu služieb zodpovedá administratívne oddelenie, ktoré pozostáva z účtovníka a manažéra.

2.1.2 Funkcie a organizačná štruktúra

Budovanie podnikovej štruktúry možno rozdeliť do troch krokov: vytvorenie organizačného modelu, vytvorenie funkčného modelu a vytvorenie informačného modelu.

Ticket Agency pozostáva z nasledujúcich oddelení:

riaditeľ;

Administratívne oddelenie;

Oddelenie prevádzky pracovných staníc;

Operátorské oddelenie.

Organizačná štruktúra podniku je znázornená na obrázku 4.

Obrázok 4 - Organizačný model

Riaditeľ vykonáva všeobecné riadenie výrobných, ekonomických a finančných a ekonomických činností podniku, ako aj organizuje interakciu všetkých jeho štrukturálnych divízií.

Výrobné oddelenie zabezpečuje vypracovanie projektu produktu, jeho následnú výrobu a montáž.

Za kvalitu poskytovania služieb zodpovedá administratívne oddelenie, ktoré pozostáva z účtovníka a manažéra.

Oddelenie prevádzky pracovnej stanice je zodpovedné za stav systému.

Za prijatie objednávky, zadanie údajov do databázy zodpovedajú prevádzkovatelia.

2.1.3 Popis dátových tokov a obchodných procesov

Modelovanie obchodných procesov

Podnikový proces je súbor vzájomne súvisiacich činností alebo úloh zameraných na vytvorenie konkrétneho produktu alebo služby pre spotrebiteľov. Kvôli prehľadnosti sú obchodné procesy vizualizované pomocou vývojového diagramu obchodných procesov. Modelovanie podnikových procesov je činnosťou formovania modelov organizácií vrátane popisu obchodných objektov (oddielov, pozícií, zdrojov, rolí, procesov, operácií, informačných systémov, nosičov informácií a pod.) a naznačenia vzťahov medzi nimi. Požiadavky na generované modely a ich príslušný obsah sú určené cieľmi modelovania. Podnikové modelovanie sa nazýva aj disciplína a samostatný podproces v procese vývoja softvéru, ktorý popisuje činnosť podniku a určuje požiadavky na systém – tie podprocesy a operácie, ktoré sú predmetom automatizácie v informačnom systéme vyvinuté.

Po analýze aktivít agentúry a vykonaní predprojektovej štúdie je možné rozlíšiť tri hlavné obchodné procesy AIS "Ticket":

1. Prijatie objednávky.

2. Vydanie identifikačného čísla.

3. Vysporiadanie so zákazníkom.

Funkčné modelovanie podnikových procesov predstavuje metodika IDEF0. Popisuje tie obchodné procesy, ktoré prebiehajú v objekte automatizácie. Metodológia IDEF0 je založená na grafickom jazyku na popis obchodných procesov. Model v IDEF0 predstavuje súbor hierarchicky usporiadaných a logicky súvisiacich diagramov. Každý diagram je umiestnený na samostatnom hárku. Existujú štyri typy grafov:

Kontextový diagram A-0 (každý model môže mať iba jeden kontextový diagram);

Dekompozičné diagramy (vrátane diagramu prvej úrovne rozkladu A 0, odhaľujúci kontextový diagram);

Diagramy stromu uzlov;

Grafy len s expozíciou (FEO).

Kontextový diagram je vrcholom stromovej štruktúry diagramov a predstavuje najvšeobecnejší popis systému a jeho interakcie s vonkajším prostredím (spravidla je tu popísaný hlavný účel modelovaného objektu). Po opísaní systému ako celku je rozdelený na veľké fragmenty. Tento proces sa nazýva funkčný rozklad a diagramy, ktoré opisujú každý fragment a interakciu fragmentov, sa nazývajú diagramy rozkladu. Po rozklade kontextového diagramu (t.j. získaní diagramu A0) sa každý blok diagramu As rozloží na menšie fragmenty atď., kým sa nedosiahne požadovaná úroveň detailov. Po každej dekompozičnej relácii sa konajú skúšobné stretnutia - odborníci na danú problematiku (zvyčajne sú to zamestnanci podnikov, s ktorými sa analytici pýtajú) indikujú zhodu skutočných obchodných procesov s vytvorenými diagramami. Nájdené nezrovnalosti sú opravené a až po absolvovaní skúšky bez komentárov môžete prejsť na ďalšiu rozkladovú reláciu. To zaisťuje, že model zodpovedá skutočným obchodným procesom na akejkoľvek úrovni modelu. Syntax na popis systému ako celku a každého jeho fragmentu je v celom modeli rovnaká.

Hlavnou obchodnou funkciou „AIS Ticket“ je predaj leteniek. Vstupom je objednávka lístka. Víkend - príjem. Nástrojmi na vykonávanie hlavnej obchodnej funkcie sú zamestnanci Bilet OJSC (účtovník, manažér, IT technici, operátori).

Diagram toku údajov

Požiadavky sú reprezentované ako hierarchia procesov spojených dátovými tokmi. Diagramy toku údajov ukazujú, ako každý proces transformuje svoje vstupy na výstupy a odhaľujú vzťahy medzi týmito procesmi. DFD diagramy sa úspešne používajú ako doplnok k modelu IDEF0 na popis pracovného toku a spracovania informácií. Podobne ako IDEF0, aj DFD predstavuje modelovaný systém ako sieť súvisiacich činností. Hlavnými komponentmi DFD (ako je uvedené vyššie) sú procesy alebo úlohy, externé entity, dátové toky, dátové úložiská (úložiská). Na rozdiel od šípok IDEF0, čo sú pevné vzťahy, šípky DFD ukazujú, ako sa objekty (vrátane údajov) presúvajú z jednej úlohy do druhej.

Na rozdiel od IDEF0, kde je systém vnímaný ako vzájomne súvisiace činnosti, DFD vníma systém ako kolekciu položiek. Kontextový diagram často obsahuje diela a externé odkazy. Diela sa zvyčajne označujú názvom systému, napríklad „Systém spracovania informácií“. Zahrnutím externých odkazov do kontextového diagramu sa nerušia požiadavky metodiky na jasné definovanie účelu, rozsahu a spoločného pohľadu na modelovaný systém.

V DFD sú činnosti (procesy) systémové funkcie, ktoré transformujú vstupy na výstupy. Hoci sú úlohy zobrazené ako zaoblené obdĺžniky, ich význam je rovnaký ako pri úlohách IDEF0 a IDEF3. Rovnako ako procesy IDEF3 majú vstupy a výstupy, ale nepodporujú ovládacie prvky a mechanizmy ako IDEF0.

Externé entity predstavujú vstupy do systému a/alebo výstupy zo systému. Externé entity sú nakreslené ako obdĺžnik s tieňom a zvyčajne sa nachádzajú na okrajoch diagramu. Jedna externá entita môže byť použitá viackrát v jednom alebo viacerých diagramoch. Zvyčajne sa táto technika používa, aby sa nekreslili príliš dlhé a mätúce šípky.

Pracovné postupy sú znázornené šípkami a popisujú pohyb objektov z jednej časti systému do druhej. Pretože každá strana úlohy nemá v DFD jasný účel, ako v IDEF0, šípky môžu ísť dovnútra a von z ktorejkoľvek strany obdĺžnika úlohy. DFD tiež používa obojstranné šípky na popis dialógov príkaz-reakcia medzi úlohami, medzi úlohou a externou entitou a medzi externými entitami.

Na rozdiel od šípok, ktoré opisujú objekty v pohybe, dátové úložiská zobrazujú objekty v pokoji.

2.2 Návrh IC systému

referenčné podmienky kalkulácie nákladov práce rezervácia

2.2.1 Vývoj koncepcie, architektúry výstavby a platformy pre implementáciu IS

Hlavnými aspektmi pri výbere architektúry na budovanie IS sú rýchlosť, spoľahlivosť, škálovateľnosť a bezpečnosť.

V súčasnosti sú najbežnejšie architektúry:

súborový server;

Klientsky server;

vrstvená architektúra.

Architektúra súborového servera znamená, že server preberá iba funkciu ukladania údajov a spracovanie sa vykonáva na klientskych počítačoch. To znamená, že údaje je potrebné prenášať cez sieť, čo má za následok veľkú sieťovú prevádzku. A to zase povedie k zníženiu výkonu s nárastom počtu používateľov. Pri implementácii architektúry súborového servera sa tiež problém integrity, konzistencie a súčasného prístupu k údajom rieši decentralizovaným spôsobom: údaje sú uložené na serveri a spracované na klientovi. V dôsledku toho sa znižuje spoľahlivosť aplikácie. Ďalšou nevýhodou sú vysoké náklady na upgrade a údržbu služieb obchodnej logiky na každej klientskej pracovnej stanici. Táto architektúra má však aj množstvo výhod, akými sú nízke náklady na vývoj, vysoká rýchlosť vývoja a nízke náklady na aktualizáciu a zmenu softvéru.

Architektúra klient-server nemá nevýhody vyššie uvedenej architektúry, pretože databázový server nielen poskytuje prístup k zdieľaným údajom, ale ich aj spracováva. Klient posiela požiadavky na server v jazyku „zrozumiteľnom“ pre server a ten následne spracuje požiadavku, pričom kontroluje integritu a konzistenciu údajov a vráti výsledok spracovanej požiadavky klientovi. Výsledkom je zníženie zaťaženia siete: klient už nemusí spracovávať prechodné dáta. Ukladanie a spracovanie sú centralizované, takže táto architektúra je spoľahlivejšia ako architektúra súborového servera. Medzi nevýhody architektúry klient-server patrí po prvé dostatočná náročnosť vývoja systému kvôli potrebe vykonávať obchodnú logiku a poskytovať používateľské rozhranie v jednom programe a vysoké nároky na pracovné stanice z rovnakého dôvodu.

Ďalším krokom vo vývoji architektúr IS sa stala viacúrovňová architektúra, v ktorej sa obchodná logika vykonáva na aplikačnom serveri. Vrstvená architektúra má nasledujúce výhody:

škálovateľnosť;

konfigurovateľnosť - vzájomná izolácia úrovní umožňuje rýchlo a jednoducho prekonfigurovať systém v prípade porúch alebo počas plánovanej údržby na jednej z úrovní;

vysoká bezpečnosť;

vysoká spoľahlivosť;

nízke požiadavky na rýchlosť kanála (siete) medzi terminálmi a aplikačným serverom;

nízke požiadavky na výkon a technické vlastnosti terminálov, v dôsledku čoho sa znížia ich náklady.

Napriek nepopierateľným výhodám však tento systém nebol distribuovaný z nasledujúcich dôvodov:

zložitosť vývoja systémov založených na viacúrovňovej architektúre, pretože je veľmi ťažké „spojiť“ rôzne moduly, najmä ak sú napísané rôznymi skupinami. A zmena v jednom module spravidla spôsobí lavínu zmien vo zvyšku a z tohto pohľadu bude aj jednoduchý systém založený na viacúrovňovej architektúre 2x náročnejší na implementáciu;

vysoké požiadavky na výkon aplikačných serverov a databázových serverov, a teda vysoké náklady na hardvér servera;

vysoké požiadavky na rýchlosť kanála (siete) medzi databázovým serverom a aplikačnými servermi;

vysoká náročnosť administrácie.

Po zvážení všetkých výhod a nevýhod každej z architektúr volíme pre implementáciu systému AIS Ticket architektúru klient-server. Táto architektúra vám umožňuje optimálne rozložiť prácu medzi klientskou a serverovou časťou systému: aplikácia spustená na pracovnej stanici nečíta databázové záznamy „priamo“, ale posiela požiadavky na server, kde sú spracované postupne a výsledky spracovania sú odoslané na pracovnú stanicu. A to výrazne znižuje informačné toky v LAN.

Schéma fungovania a konštrukcie informačného systému je znázornená na obrázku 5.

Obrázok 5 - Architektúra "klient-server"

2.2.2 Štruktúra informačného systému, skladba funkčných a podporných subsystémov

Funkčné subsystémy - komplex ekonomických úloh s vysokým stupňom výmeny informácií (väzieb) medzi úlohami (niektorý proces spracovania informácií s presne definovaným súborom vstupných a výstupných informácií. Funkčné subsystémy poskytujú informačnú službu pre určité druhy činností ekonomického sektora). systém (podnik), charakteristický svojimi štrukturálnymi členeniami a (alebo) riadiacimi funkciami Integrácia funkčných subsystémov do jedného systému sa dosahuje vytvorením a prevádzkou podporných subsystémov, ako sú:

Informačné;

technické;

Softvér;

matematické;

Jazykovedné.

Nosné subsystémy sú spoločné pre celý IS bez ohľadu na konkrétne funkčné subsystémy, v ktorých sa využívajú určité typy podpory. V práci sú podporné a organizačné subsystémy spojené do jedného podporného subsystému. Za odôvodnenie takéhoto rozhodnutia možno považovať to, že ich komponenty zabezpečujú realizáciu cieľov a funkcií systému.

Zloženie podporných subsystémov nezávisí od zvolenej tematickej oblasti a má:

funkčná štruktúra;

informačná podpora;

Matematický (algoritmický a softvérový) softvér;

Technická podpora;

organizačná podpora,

a vo fáze vývoja IS dodatočné ustanovenia:

právne;

lingvistické;

Technologické;

metodologické;

Rozhrania s externými IS.

Informačná podpora je súbor prostriedkov a metód na budovanie informačnej základne. Definuje spôsoby a formy zobrazenia stavu riadiaceho objektu vo forme údajov vo vnútri IS, dokumentov, grafov a signálov mimo IS.

Matematická podpora pozostáva z algoritmu a softvéru.

Organizačná podpora je súbor prostriedkov a metód na organizáciu výroby a jej riadenie v kontexte zavádzania IS.

Účelom organizačnej podpory je: výber a nastavenie úloh riadenia, analýza systému manažérstva a spôsobov jeho zlepšenia, vývoj riešení pre organizáciu interakcie medzi IS a personálom, implementácia úloh riadenia. Organizačná podpora zahŕňa spôsoby komunikácie s klientmi, požiadavky na papierovanie, popis práce a pod.

Algoritmická podpora je súbor matematických metód, modelov a algoritmov používaných v systéme na riešenie problémov a spracovanie informácií.

2.2.3 Technická podpora IS

Komplex technických prostriedkov by mal obsahovať tieto prvky:

Pracovné stanice;

Neprerušiteľné zdroje napájania;

Nástroje na budovanie LAN;

Databázový server;

Tlačiareň.

Požiadavky na server:

Pamäť 8 GB;

Procesor 2,2 GHz Intel Xeon 5500 minimálne;

Rýchlosť disku SATA 8 Gb/s;

Sieťový adaptér 10 Gb / s;

Operačný systém Windows Server 2008.

Požiadavky na pracovnú stanicu:

Procesor 2 GHz;

Pamäť 2 GB;

Pevný disk nie menej ako 500;

Operačný systém Windows 7;

Sieťový adaptér 100 Mbps.

Technické prostriedky IS sú popísané s prihliadnutím na požiadavky na fungovanie aplikovaného softvérového komplexu. Technické prostriedky by mali zabezpečiť:

Nepretržitá prevádzka komplexu technických prostriedkov a zariadení;

Garantované spustenie celého softvérového balíka v prípade poruchy alebo zlyhania časti zariadenia;

Ochrana údajov pred neoprávneným prístupom;

Servery a pracovné stanice musia byť prepojené lokálnou sieťou.

Obrázok 2.3 ukazuje topológiu lokálnej siete (LAN) pre OJSC "Bilet".

Obrázok ukazuje, že 5 pracovných staníc je pripojených k databázovému serveru a súborovému serveru cez prepínač. Topológia siete je hviezdicová.

Obrázok 6 - Logická schéma siete JSC "Zákazník"

2.3 Informačná podpora IP

2.3.1 Popis logickej štruktúry infobázy

Logický (datalogický) návrh je vytvorenie databázovej schémy založenej na špecifickom dátovom modeli, napríklad relačný dátový model. Pre relačný dátový model je datalogický model súbor schém vzťahov, zvyčajne označujúcich primárne kľúče, ako aj „prepojenia“ medzi vzťahmi, čo sú cudzie kľúče.

Transformácia konceptuálneho modelu na logický model sa spravidla uskutočňuje podľa formálnych pravidiel. Tento krok môže byť do značnej miery automatizovaný.

Normálna forma je vlastnosť vzťahu v modeli relačných údajov, ktorá ho charakterizuje z hľadiska redundancie, čo môže viesť k logicky chybným výsledkom vzorkovania alebo zmeny údajov. Normálna forma je definovaná ako súbor požiadaviek, ktoré musí vzťah spĺňať. Proces prevodu databázových (DB) vzťahov do formy zodpovedajúcej normálnym formám sa nazýva normalizácia. Normalizácia má priniesť štruktúru databázy do formy, ktorá poskytuje minimálnu logickú redundanciu a nie je určená na zníženie alebo zvýšenie výkonu, ani na zníženie alebo zvýšenie fyzického objemu databázy. Konečným cieľom normalizácie je znížiť potenciálnu nekonzistentnosť informácií uložených v databáze. Všeobecný účel normalizačného procesu je nasledujúci:

Vylúčenie niektorých typov redundancie;

Odstránenie niektorých anomálií aktualizácie;

Vývoj databázového projektu, ktorý je pomerne „kvalitnou“ reprezentáciou reálneho sveta, je intuitívny a môže slúžiť ako dobrý základ pre neskoršie rozširovanie;

Zjednodušte postup uplatňovania nevyhnutných obmedzení integrity.

Redundancia sa zvyčajne eliminuje rozkladom vzťahov takým spôsobom, že v každom vzťahu sú uložené iba primárne fakty (teda fakty, ktoré nie sú odvodené od iných uložených faktov).

Na logickej úrovni je normalizovaná databáza, ako aj prideľovanie kľúčov pre každú entitu. Logické vzťahy sú implementované prostredníctvom primárneho a cudzieho kľúča.

2.3.2 Popis fyzickej implementácie databázy

Fyzický dizajn – vytvorenie databázovej schémy pre konkrétny DBMS. Špecifiká konkrétneho DBMS môžu zahŕňať obmedzenia týkajúce sa pomenovania databázových objektov, obmedzenia podporovaných typov údajov atď. Okrem toho medzi špecifiká konkrétneho DBMS vo fyzickom dizajne patrí výber riešení súvisiacich s prostredím fyzického ukladania dát (výber spôsobov správy diskového úložiska, rozdelenie databázy na súbory a zariadenia, spôsoby prístupu k dátam), vytváranie indexov, vytváranie indexov, vytváranie indexov, vytváranie indexov, atď. atď.

Fyzický dátový model je vybudovaný na základe logického modelu a popisuje dáta pomocou špecifického DBMS. Vzťahy vyvinuté vo fáze logického modelovania sú prevedené na tabuľky, atribúty na stĺpce, domény na dátové typy akceptované vo vybranom špecifickom DBMS.

Tie. vo fyzikálnom modeli existuje vzájomná zhoda medzi parametrami objektu a modelom rovnakej fyzikálnej povahy. V tomto prípade je prvok systému spojený s fyzikálnymi ekvivalentmi, ktoré reprodukujú štruktúru, základné vlastnosti a vzťahy skúmaného objektu. Vo fyzikálnom modelovaní, ktoré je založené na teórii podobnosti, sa zachovávajú znaky vykonávania experimentu v prírode pri dodržaní optimálneho rozsahu zmien zodpovedajúcich fyzikálnych parametrov.

Záver

Výsledkom práce na kurze boli zadania pre vývoj informačného systému pre agentúru na predaj a rezerváciu leteniek a jej softvér.

Zadanie informačného systému je hlavným dokumentom, ktorý definuje požiadavky a postup tvorby informačného systému, v súlade s ktorými sa vyvíja a prijíma pri uvedení do prevádzky. Obsahuje základné požiadavky na funkčné vlastnosti, spoľahlivosť, prevádzkové podmienky a informačnú bezpečnosť informačného systému a popisuje aj postup pri vývoji systému.

V súlade s úlohami stanovenými v zadávacích podmienkach boli dokončené tieto etapy tvorby technického projektu:

- bola vykonaná analýza predmetnej oblasti;

- bola vyvinutá funkčná schéma AIS "Ticket";

- bol vypracovaný koncept, bola zvolená architektúra konštrukcie a platforma pre implementáciu systému;

1. Bol navrhnutý koncepčný model AIS „Ticket“;

2. Na základe konceptuálneho modelu bol navrhnutý logický model systému AIS „Ticket“;

3. Je definovaná fyzická štruktúra databázového servera.

Bibliografia

1. GOST 19.201-78 Jednotný systém programovej dokumentácie. Technická úloha. Požiadavky na obsah a dizajn

2. GOST 34.602-89 Informačné technológie. Súbor noriem pre automatizované systémy. Referenčné podmienky pre vytvorenie automatizovaného systému

3. RD 50-34.698-90 Automatizované systémy. Požiadavky na obsah dokumentov

4. V.P. Romanov, N.Z. Emelyanova, T.L. Partyka Návrh ekonomických informačných systémov. Metodiky a moderné technológie. - M: Skúška, 2005.- 256 s.;

5. Maklakov S.V. BPWin a ERWin CASE - vývojové nástroje pre informačné systémy / Maklakov S.V. - M: MEPhI DIALOGUE, 2001.-256s.;

6. Bojko V.V. Navrhovanie databáz informačných systémov / Bojko V.V., Savinkov V.M. - 2. vyd. - M.: Financie a štatistika, 1989. - 350 s.

Hostené na Allbest.ru

...

Podobné dokumenty

Referenčné podmienky pre vývoj automatizovaného systému a skladového účtovníctva pre riadenie univerzálnej obchodnej základne. Návrh informačného systému a výber prostredia pre tvorbu softvérového produktu. Vytvorenie rozhrania a používateľskej príručky.

práca, pridané 7.11.2015


Normatívno-právne akty Ruskej federácie v oblasti informačnej bezpečnosti. Poradie organizácie práce na ochrane informácií v informačných systémoch. Všeobecný prístup k vypracovaniu zadávacích podmienok pre rozvoj systému ochrany pre túto oblasť.

ročníková práca, pridaná 5.5.2015


Vytvorenie zadania pre vývoj informačného systému na objednávanie leteniek. Požiadavky na dokumentáciu. Poradie kontroly a prijatia systému. Vývoj koncepcie, architektúry konštrukcie a platformy pre implementáciu informačného systému.

ročníková práca, pridaná 13.05.2015


Vytvorenie informačného systému „Zlato“, ktorý automatizuje prácu Šperkárskej dielne. Modelovanie obchodných procesov pomocou diagramov IDEF0 a UML a dátových tokov DFD a sicuence. Vypracovanie technického projektu a úlohy na základe GOST 34.602-89.

ročníková práca, pridaná 2.10.2013


Zloženie expertného systému. Požiadavky na komplex technických prostriedkov. Štruktúra a organizácia technickej podpory automatického informačného systému. Technická dokumentácia pre vývoj softvérových nástrojov a ako ich používať.

abstrakt, pridaný 10.09.2014


Učenie sa programovacích jazykov PHP, SQL, C++, HTML. Preskúmanie pravidiel pre spustenie a používanie lokálneho servera Denwer. Príprava zadávacích podmienok pre vývoj softvérového produktu. Popis vytváranej mobilnej a webovej aplikácie.

semestrálna práca, pridané 04.07.2015


Vývoj automatizovaného informačného systému pre evidenciu a monitorovanie vykonávania opravárenských prác a poskytovanie služieb pri vývoji softvéru pre spoločnosť „MegionSoftOil“, vývoj algoritmov pre aplikácie softvérového systému a modulov.

práca, pridané 29.06.2012


Zdôvodnenie potreby rozvoja informačného systému. Analýza domény. Referenčné podmienky pre vytvorenie EIS. Právne postavenie a stručná ekonomická charakteristika podniku. Stav účtovnej a analytickej práce v podniku.

abstrakt, pridaný 01.09.2009


Vývoj a implementácia automatizovaného informačného systému (AIS) pre prácu s klientmi cestovnej kancelárie (príjem a spracovanie žiadostí). Štúdia realizovateľnosti cestovnej kancelárie, algoritmus a schéma jej softvérového rozhrania AIS.

práca, pridané 21.07.2011


Počítanie počtu funkčných bodov. Výpočet mzdových nákladov na vývoj softvéru a predpokladaný čas jeho vývoja, model životného cyklu. Vypracovanie technických špecifikácií na vytvorenie automatizovaného systému, požiadavky naň.