Pracovné stanice, ktoré sa majú automatizovať

Výkonové požiadavky

Zoznam vygenerovaných správ

4.4.2. Požiadavky na systém plánovania a kontroly výroby

Informačný systém by mal poskytovať plánovanie podnikových zdrojov a riadenie výroby na zákazku.

Požiadavky na funkčnosť IS:

1. Správa konfigurácie hotových výrobkov (FP):

Udržiavanie regulačných a referenčných informácií o zložení GP so schopnosťou označiť obdobie relevantnosti špecifikácie a s možnosťou výroby GP s niekoľkými rôznymi špecifikáciami;

Udržiavanie normatívnych a referenčných informácií o výrobnej technológii výrobkov, ktoré sú súčasťou GP, so schopnosťou označiť obdobie relevantnosti technológií a s možnosťou byť pri výrobe GP s niekoľkými rôznymi technológiami;

2. Riadenie predaja:

Prezeranie histórie vzťahov so zákazníkmi;

Registrácia / oprava žiadosti klienta s uvedením zoznamu všeobecných lekárov, objemov, dátumu odoslania, predajnej ceny a akýchkoľvek ďalších podmienok;

Prezeranie aktuálnych ekonomických ukazovateľov (odhadov nákladov) objednaného SOE;

3. Plánovanie výroby:

Vypracovanie harmonogramu dostupnosti zariadenia s uvedením počtu dostupných štandardných hodín pre každý deň plánovaného obdobia;

Zostavenie výrobného plánu s uvedením vyrobeného produktu, jeho množstva, použitého vybavenia, divízií pre každý deň plánovacieho obdobia;

Vypracovanie plánu výrobných požiadaviek na materiály a komponenty;

Kontrola a riadenie nakladania zariadení podľa vytvoreného výrobného plánu;

Vykonávanie úprav výrobného plánu počas jeho vykonávania;

Plánová analýza výrobného plánu;

4. Riadenie výroby:

Príprava pracovných zmien (objednávok) na výrobu výrobkov;

Pridelenie / preradenie príkazov umelcov a stanovenie ich vykonania s uvedením počtu vyrobených výrobkov, počtu chybných výrobkov a dôvodov manželstva;

Riadenie skladovania a pohybu skladových položiek (tovaru a materiálov) vo výrobe;

5. Riadenie dodávok:

Formácia na základe plánu potreby materiálov a komponentov nákupnej objednávky s uvedením dodávateľa, nomenklatúry tovaru a materiálov, množstva a dodacej lehoty;

Formovanie nákupných objednávok na základe jednorazových objednávok tovaru a materiálu z divízií;

Kontrola a sledovanie procesu dokončovania nákupných objednávok;

Prevádzková kontrola rezíduí;

Plánovaná analýza dodávok;

6. Riadenie nákladov:

Tvorba plánovaných (štandardných) nákladov na SOE;

Stanovenie skutočných výrobných nákladov;

Výpočet skutočných nákladov na SOE;

Analýza skutočných nákladov plánu.

Požiadavky na výpočet štandardných nákladov na objednávku

Štandardná cena produktu a celej objednávky sa počíta pomocou nasledujúcej metódy:

1. Priama materiálová zložka štandardných nákladov na produkt sa vytvára na základe informácií o štandardnom zložení tohto produktu (špecifikácia) a stanovených účtovných cien pre položky zásob zahrnuté v tejto špecifikácii. Pre účely špecifikácie je povolené použitie niekoľkých položiek nákladov na materiál.

2. Výška priamych miezd sa počíta na základe štandardného prevádzkového zloženia produktu. Nastavené sú nasledujúce položky: štandardné trvanie každej operácie, povolanie pracovníka požadované pre túto operáciu, ako aj platová trieda pracovníka. Systém taktiež zavádza peňažné sadzby štandardných hodín pre profesie pracovníkov a ich kategórie.

3. Štandardná hodnota nepriamych nákladov sa počíta ako percento zo stanoveného základu (výška priamych nákladov na uvedenú položku).

Na vykonanie tohto výpočtu musia byť v informačnom systéme k dispozícii nasledujúce údaje:

1. špecifikácia výroby produktu (ako aj špecifikácia výroby všetkých polotovarov vlastnej výroby zahrnutých v tomto produkte);

2. Výrobná technológia výrobku a do neho zahrnutých polotovarov: aké operácie by sa mali vykonávať a na aký čas. Okrem toho je pre každú operáciu uvedené povolanie a kategória pracovníka, ktoré sú potrebné na jej implementáciu (pre uvedenie tohto konkrétneho produktu);

3. Protokol o účtovaní cien použitého tovaru a materiálu;

4. Peňažné sadzby štandardných hodín pre profesie a hodnosti.

Požiadavky na výpočet skutočných nákladov na objednávku

Skutočné náklady na produkt a celú objednávku sa počítajú pomocou tejto metódy:

1. Priame náklady na materiál na výrobu výrobku sa počítajú na základe skutočných údajov o nákladoch na materiál v dielni na prerozdelenie výroby. V takom prípade sa najskôr vypočítajú náklady na všetky polotovary zahrnuté v tomto produkte. Celkové hodnotenie sa vykonáva podľa metodiky prijatej v roku 2006 Účtovná politika podniky.

2. Mzdy pracovníkov v priamej výrobe sa počítajú na základe údajov o uzavretí objednávok v obchode. V prípade, že objednávky nie sú evidované v IS, sú mzdy odkazované na priame náklady podliehajúce distribúcii, t.j. rozdelené medzi vyrobené výrobky podľa určitej základne.

3. Odpisy zariadení na priamu výrobu sú zahrnuté do priamych nákladov, ak je pri každom prerozdelení uvedené zariadenie (obrábací stroj) použité pri tomto prerozdelení.

4. Priame náklady, ktoré sa majú prideliť:

Základné materiály sa spotrebovávajú menej často ako pri každom ďalšom prerozdelení (napríklad chemikálie, ktorých rýchlosť na jednotku výroby je taká malá, že nemá zmysel brať do úvahy ich alternatívnu spotrebu ani pri tejto rýchlosti);

Mzdy pracovníkov pri absencii informácií o ich rozdelení podľa obratu;

Odpisy priameho vybavenia, ak je k dispozícii iba jeho celková mesačná suma, bez členenia podľa prerozdelenia.

Takéto náklady sa alokujú k vyrobeným položkám podľa zvolenej distribučnej základne (napríklad v pomere k priamym nákladom na materiál).

1. Všeobecné výrobné náklady (účet 25 BU): sú rozdelené na vyrobené výrobky v pomere k vybranej distribučnej základni. Podiel týchto výdavkov môže, ale nemusí zostať na nedokončenej produkcii podľa účtovných zásad prijatých v podniku.

2. Všeobecné prevádzkové náklady a náklady na predaj (účty 26 a 44) sa vykazujú ako náklady bežného obdobia a týkajú sa nákladov na predaj. Rozdelenie týchto nákladov na náklady na hotové výrobky je možné vidieť v osobitnej správe.

Požiadavky na výkon informačného systému

<Раздел должен содержать требования к производительности Информационной системы. Вводится в шаблон>.

Požiadavky na spoľahlivosť

<Раздел должен содержать требования к надежности Информационной системы. Например:>

Požiadavky na zabezpečenie spoľahlivého (stabilného) fungovania informačného systému

Spoľahlivé (stabilné) fungovanie informačného systému musí byť zabezpečené tým, že zákazník vykoná súbor organizačných a technických opatrení, ktorých zoznam je uvedený nižšie:

1. Organizácia neprerušiteľného napájania technické prostriedky;

2. používanie licencovaného softvéru;

3. Pravidelné vykonávanie odporúčaní Ministerstva práce a sociálneho rozvoja Ruskej federácie stanovených v rezolúcii z 23. júla 1998 „O schválení medziodvetvových štandardných časových štandardov pre práce na údržbe osobných počítačov a kancelárskeho vybavenia a softvérovej podpory“;

4. Pravidelné plnenie požiadaviek GOST 51188-98. „Ochrana informácií. Testovanie softvéru na prítomnosť počítačových vírusov “;

5. Pravidelné zálohovanie databáz informačného systému prostredníctvom samotného informačného systému alebo pomocou použitého systému správy databáz.

1. Relevantnosť a nevyhnutnosť výskumu

So vznikom novej formy správy nehnuteľností v Rusku v poslednej dobe vo forme združenia vlastníkov domov (HOA), združení majiteľov domov (HOA) a kondomínií (ďalej len „organizácie pre správu nehnuteľností“) majú nájomníci (vlastníci) bývania možnosť ovplyvňovať kvalitu údržby nehnuteľností, pre zlepšenie priľahlého územia a do istej miery aj pre náklady na verejné služby.

V súlade s článkom 161 Zákona o bývaní Ruskej federácie musí správa bytového domu zabezpečiť priaznivé a bezpečné životné podmienky pre občanov, riadnu údržbu spoločného majetku v bytovom dome, riešenie problémov s využívaním tohto majetku a poskytovanie verejných služieb občanom žijúcim v takejto budove.

b) vzdelávací proces

Vývoj vedeckých a vzdelávacích kurzov, ako aj populárno-vedeckých materiálov

	Názov kurzu/ materiál	Stručný popis kurzu/ materiál
Vedecké a vzdelávacie kurzy	Výukový program „Informačné systémy pre správu bytových domov“	Prezentujú sa funkčné možnosti informačných systémov pre správu nehnuteľností používaných v Ruskej federácii a v zahraničí. Porovnajú sa funkčné možnosti, sú uvedené odporúčania týkajúce sa výberu informačného systému. Je určený pre výučbu študentov v smeroch 080100.62 „Ekonomika“ a 080500.62 „Podniková informatika“
Laboratórna dielňa „Systém riadenia obchodných pravidiel organizácie pre správu MKD“	Poskytuje podrobné pokyny na zostavenie modulu správy obchodných pravidiel pomocou produktu IBM ILog. Je predstavený algoritmus pre správu obchodných pravidiel HOA. Určené pre výučbu študentov v smere 080500.62 "Podniková informatika"
Laboratórna dielňa „Multiagentové modelovanie organizácie pre správu nehnuteľností“	Poskytuje podrobné pokyny na vytvorenie agentov a vytvorenie modelu pre organizáciu správy nehnuteľností pomocou AnyLogic. Určené pre výučbu študentov v smere 080500.62 "Podniková informatika"
Výukový program „Vývoj databázy pre bytový dom pomocou MS Access 2010“	Poskytuje podrobné pokyny na vytváranie databázových tabuliek, nadväzovanie väzieb medzi nimi, vytváranie formulárov, dotazov, správ a makier pomocou funkcií MS Access 2010.
Laboratórna dielňa „Analýza obchodných procesov organizácie pre správu nehnuteľností“	Prezentované sú diagramy vyvinuté pomocou objektovo orientovaného modelovacieho jazyka UML. Je určený pre výučbu študentov v smeroch 080100.62 „Ekonomika“ a 080500.62 „Podniková informatika“
Populárne vedecké materiály	Monografia „Faktorová a klastrová analýza regionálnych organizácií v oblasti správy nehnuteľností“	Dávajú sa odporúčania pre faktoriálnu a klastrovú analýzu parametrov charakterizujúcich HOA vo vybranom regióne. Poskytuje informácie o organizáciách pre správu nehnuteľností s rovnakými súbormi obchodných procesov a identifikuje hlavné faktory ovplyvňujúce ich činnosti
Monografia „Algoritmy na výmenu informácií v organizáciách pre správu nehnuteľností“	Je uvedený všeobecný algoritmus fungovania IS, algoritmy pre prevádzku softvérových modulov IS, ktoré implementujú informačné služby pre predplatiteľov, a algoritmy pre interakciu softvérových modulov. Používateľské rozhrania informačného systému. Vlastnosti vývoja programového kódu modulov využívajúcich vývojové prostredie MS Visual 2010
Článok „Klasifikácia účastníkov a informačných systémov v organizáciách pre správu MKD“	Stanovujú sa zákonitosti výmeny informácií v rámci organizácie pre správu nehnuteľností, predpokladané zloženie a objem údajov počas výmeny informácií, očakávané transformácie údajov počas výmeny informácií a formy prezentácie vstupných a výstupných údajov.
Článok „Vývoj multiagentového simulačného modelu na modelovanie činností združení vlastníkov bytov“	Uvádzajú sa prístupy k tvorbe agentov pre danú oblasť, ako aj vývoj simulačného modelu. Prezentujú sa výsledky modelovania aktivít združení vlastníkov bytov s rôznymi súbormi počiatočných údajov.
Článok „Vytvorenie súboru obchodných pravidiel pre HOA“	Uvádzajú sa prístupy k vytvoreniu súboru obchodných pravidiel. Berú sa do úvahy možnosti implementácie systému riadenia obchodných pravidiel pomocou IBM ILog. Je uvedený príklad použitia obchodných pravidiel na rozhodovanie
Článok „Tvorba algoritmov pre informačný systém organizácie pre správu nehnuteľností“	Uvažuje sa o štruktúre algoritmu informačného systému, štruktúre algoritmov softvérových modulov, ktoré implementujú informačné služby a výmenu informácií s databázou organizácie.
	Článok „Aplikácia holistického prístupu na vytvorenie súboru kľúčových ukazovateľov výkonnosti činností HOA“	V článku sa uvažuje o uplatnení ustanovení holistického prístupu na vytvorenie súboru ukazovateľov, ktoré umožňujú vytvorenie systému na hodnotenie dosahovania strategických a taktických (prevádzkových) cieľov organizácie pre správu nehnuteľností, na hodnotenie stavu organizácie a na sledovanie podnikateľskej činnosti predplatiteľov informačného systému v reálnom čase.
Článok „Informačné služby pre správu bytových domov“	V článku sú uvažované informačné služby poskytované zahraničnými informačnými systémami vlastníkom (nájomcom) nehnuteľností v bytových domoch.
Článok „Vytvorenie databázy pre informačný systém HOA“	Uvažuje sa o dátových modeloch, technológii ukladania a spracovania údajov, zložení údajov, formátoch údajov určených na premietnutie do používateľských rozhraní a výstupných dokumentoch, dátových typoch, navrhovanom zložení tabuliek a schéme vzťahov medzi tabuľkami.
Článok „Organizačná analýza a model obchodného procesu HOA“	Uvažuje sa s vývojom súboru modelov: strategický model stanovovania cieľov, organizačno-funkčný model, funkčno-technologický model, model procesnej úlohy kvantitatívneho modelu, model dátovej štruktúry (v akej podobe sú opísané predpisy HOA a objekty externého prostredia), modely podnikových procesov

Odošlite svoju dobrú prácu do znalostnej bázy je jednoduché. Použite nasledujúci formulár

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

Zverejnené dňa http://www.allbest.ru/

Katedra automatizácie a informačných systémov

VYSVETLIVKA

k projektu kurzu

Téma: Návrh podnikového riadenia modulu IS

Disciplína: „Návrh IP“

Úvod

1 Informačná podpora komplexu úloh

1.1.1 Infologický alebo informačný model (dátová schéma) a jeho popis

1.2.1. Formalizácia výpočtov (algoritmy na výpočet a riešenie problémov)

2 Technologická podpora

2.1 Schéma technologického procesu zhromažďovania, prenosu, spracovania a vydávania informácií

3 Softvér pre komplex úloh

3.1 Všeobecne

Záver

Zoznam použitej literatúry

ÚVOD

V súčasnosti existuje rozsiahle vytváranie a implementácia automatizovaných informačných systémov (AIS) v podnikoch rôzneho typu. AIS sa osvedčil pri spracovaní informácií rôznych typov a štruktúr. Takéto systémy vykonávajú najbežnejšie procesy v čo najkratšom čase.

Za posledných dvadsať rokov sa významne zvýšil objem a obeh informácií vo všetkých sférach ľudského života: hospodárskej, finančnej, politickej, duchovnej. A proces zhromažďovania, spracovania a využívania znalostí sa neustále zrýchľuje. Vedci tvrdia, že každých desať rokov sa množstvo informácií zdvojnásobí. V tejto súvislosti je nevyhnutné používať automatické nástroje, ktoré umožňujú efektívne ukladanie, spracovanie a distribúciu nahromadených údajov. Napriek automatizácii veľkého počtu obchodných spoločností musia zamestnanci týchto inštitúcií vykonávať veľké množstvo rutinných prác v oblasti účtovníctva tovaru a zákazníkov a výmeny informácií medzi oddeleniami. Potreba implementácie informačného systému (IS), ktorý automatizuje hlavné funkcie vzdelávacieho procesu, je v súčasnosti nepochybná.

Existujú tri spôsoby, ako vytvoriť IP:

1 Budovanie IS na báze ERP systémov.

2 Vývoj vlastného IS.

Každá z týchto oblastí má silné aj slabé stránky. Nevýhodou prvého prístupu je okrem extrémne vysokých nákladov na licenciu pre systém ERP aj značná prácnosť nastavenia a prispôsobenia systému, čo nevyhnutne prináša potrebu konzultačnej podpory, údržby a implementácie IS, čo ďalej zvyšuje jeho náklady.

Modul IS "Enterprise Management" je určený na automatizáciu práce zamestnancov obchodných spoločností. Systém má databázu obsahujúcu informácie o dodávateľských spoločnostiach, zamestnancoch a zákazníkoch.

automatizovaný systém mimo stroj vo vnútri stroja

1 INFORMAČNÁ PODPORA KOMPLEXU ÚLOH

1.1 Podpora informácií mimo stroja

Na vytvorenie praktickej používateľskej aplikácie na počítači a prácu s ňou v určitej oblasti predmetu by sa údaje z vonkajšej strany stroja mali preniesť na strojové médium, kde tvoria informačnú základňu vnútri stroja.

Podpora informácií mimo stroja (obrázok 1) obsahuje informačnú základňu mimo stroja (IB) a prostriedky jej údržby.

Zverejnené dňa http://www.allbest.ru/

Obrázok 1 Podpora informácií mimo stroj

IS integruje aktuálne informácie o mimopracovných sférach predmetnej oblasti a na zabezpečenie práce s nimi sú určené prostriedky jeho organizácie a údržby. Informačnú základňu mimo stroj tvoria údaje obsiahnuté v dokumentoch.

Informačná základňa mimo stroj obsahuje normatívne a referenčné, plánované (tj. Podmienečne trvalé) informácie a prevádzkové (účtovné) informácie o určitej predmetnej oblasti. Približné typické zloženie informácií jedného a druhého typu je znázornené na obrázku 2.

Riešenia Infobase znamenajú stanovenie obsahu informácií potrebných na riešenie problémov používateľov. Okrem toho by mala byť identifikovaná logická štruktúra informácií, ktorá umožňuje prejsť do fázy formalizácie a modelovania údajov, ktorá je nevyhnutná pre automatizované spracovanie. Štruktúrovanie informácií v sfére mimo strojov sa odráža v ich prezentácii samostatnými štruktúrnymi jednotkami, ich zoskupení v dokumentoch a usporiadaní podľa klasifikačných kritérií.

Zverejnené dňa http://www.allbest.ru/

Obrázok 2 Zloženie informačnej základne mimo stroja

1.1.1 Infologický alebo informačný model (dátová schéma) a jeho popis.

Návrh databázy spočíva v zostavení komplexu vzájomne prepojených dátových modelov. Najdôležitejšou etapou pri návrhu databázy je vývoj infologického (informačno-logického) modelu domény, ktorá nie je zameraná na DBMS. V infologickom modeli odrážajú dátové štruktúry v integrovanej podobe zloženie a štruktúru údajov, ako aj informačné potreby.

Informačno-logický model predmetnej oblasti odráža predmetnú oblasť vo forme súboru informačné objekty a ich štrukturálne väzby.

Najskôr je zostavený infologický model domény. Vo fáze pred návrhom sa zostavuje predbežný infologický model, ktorý sa v ďalších fázach návrhu databázy vylepšuje. Potom sa na jeho základe zostavia koncepčné (logické), interné (fyzické) a externé modely.

Účelom infologického modelovania je poskytnúť človeku najprirodzenejšie spôsoby zhromažďovania a prezentovania informácií, ktoré sa majú ukladať v vytváranej databáze.

Návrh infologického modelovania spočíva v získaní sémantických modelov, ktoré odrážajú informačný obsah konkrétnej oblasti predmetu. V tejto fáze sa vykonáva abstrakcia, štúdium, vnímanie, popis a obmedzenie predmetnej oblasti. Získané vedomosti sa ďalej prezentujú vo forme matematických vzorcov, diagramov, spojení atď.

Cieľom normalizácie je vylúčenie logických chýb. Dôležitosť normalizácie spočíva v tom, že vám umožňuje narušiť veľké vzťahy, ktoré zvyčajne obsahujú veľkú nadbytočnosť informácií. Do menších logických jednotiek, ktoré zoskupujú iba údaje, kombinované iba „od prírody“. Každá tabuľka v relačnej databáze teda spĺňa podmienku, že na križovatke každého riadku a stĺpca v tabuľke je vždy jedna hodnota a nikdy nemôže existovať viac takýchto hodnôt.

V tomto kurze sa používajú vstupné dokumenty: databázy pracovníkov, tovaru a zákazníkov.

Výsledkom preštudovania vstupných dokumentov bol infologický dátový model (ILM), grafické znázornenie ILM v kanonickej podobe, ktoré zreteľne ukazuje hierarchické vzťahy podriadenosti informačných objektov (obrázok 3).

Zverejnené dňa http://www.allbest.ru/

Obrázok 3 Infologický model modulu IS „Enterprise Management“

1.1.2 Charakteristiky vstupných informácií

Vstupnými informáciami sa rozumejú všetky informácie potrebné na vyriešenie problému a umiestnené na rôznych médiách: primárne dokumenty, médiá stroja, v pamäti osobného počítača.

Efektívnosť a efektívnosť riadenia výrobného procesu závisí od racionálnej organizácie vstupných informácií výrobného podniku, metódach zhromažďovania, registrácie, prenosu, ukladania a spracovania informácií, ich zloženia a včasného prijatia.

Vstupné informácie pre vyvíjaný projekt kurzu automatizovaný systém je:

Informácie o druhu materiálu;

Informácie o farbe materiálu;

Informácie o textúre materiálu;

Informácie o výrobcovi;

Informácie o zamestnancoch podniku;

Informácie o polohe;

Informácie o množstve materiálu;

Informácie o cene materiálu;

Informácie o šírke webu;

Databáza pozostáva zo 7 tabuliek a 5 referenčných kníh. Tabuľka „Materiály“ (obrázok 4) sa používa na ukladanie údajov o materiáli. Informácie v tejto tabuľke sa zadávajú pri príchode tovaru do skladu.

Obrázok 4 Tabuľka „Materiály“

Tabuľka Klienti (Obrázok 5) slúži na ukladanie informácií o klientoch.

Obrázok 5 tabuľka „Klienti“

Tabuľka „Zamestnanci“ (obrázok 6) sa používa na ukladanie informácií o zamestnancoch daného podniku. Informácie do tabuľky „Zamestnanci“ sa zadávajú pri prijatí nového zamestnanca.

Obrázok 6 Tabuľka „Zamestnanci“

Tabuľka „Objednávky“ (obrázok 7) sa používa na ukladanie informácií o objednaných položkách na inštaláciu napínacích stropov.

Obrázok 7 tabuľka „Objednávky“

Tabuľka „Výrobca“ (obrázok 8) sa používa na ukladanie informácií o dodávateľoch materiálov.

Obrázok 8 Tabuľka „Výrobca“

Tabuľka „Príjem“ (obrázok 9) a tabuľka „Spotreba“ (obrázok 10) sa používajú na ukladanie informácií o príjme a spotrebe materiálu.

Obrázok 9 „Príchod“

Obrázok 10 „Spotreba“

Adresáre „Typ materiálu“ (Obrázok 11), „Farba“ (Obrázok 12), „Textúra“ (Obrázok 13), „Poloha“ (Obrázok 14), „Stav“ (Obrázok 15) slúžia na objasnenie údajov v tabuľkách uvedených v formu kódov.

Obrázok 11 Odkaz „Typ materiálu“

Obrázok 12 Referencia „Farba“

Obrázok 13 Odkaz „Faktura“

Obrázok 14 Adresár „Pozícia“

Obrázok 15 Odkaz „Stav“

1.1.3 Charakterizácia informácií o výsledku

Výstupnými informáciami počas prevádzky informačného systému budú údaje zobrazené na stránke stránky. Navrhnutý softvérový produkt poskytne možnosť pridávať, mazať, triediť, vyhľadávať informácie. Používateľ môže vypočítať náklady na inštaláciu strečového stropu a tiež vypočítať zostávajúci materiál s uvedením dátumu príchodu materiálu. Údaje o spotrebe materiálu za posledné obdobie sa zobrazia vo forme diagramu.

1.2 Vnútrostrojová implementácia komplexu úloh

Informácie, ktoré bude informačný systém prevádzkovať, sú organizované vo forme databázy vytvorenej pomocou MySQL (obrázok 16).

Obrázok 16 Schéma databázy vytvorenej pomocou MySQL

1 Formalizácia výpočtov (algoritmy na výpočet a riešenie problémov)

Na získanie výstupnej dokumentácie sa vstupné údaje transformujú podľa určitého algoritmu.

Pri výpočte nákladov na inštaláciu napínacieho stropu musíte vyplniť formulár „Náklady“, ktorý obsahuje 3 polia a zadanie údajov: šírka stropu, dĺžka stropu, textúra materiálu. Po vyplnení týchto polí program požaduje od tejto faktúry z databázy MySQL údaje o nákladoch na materiál. Náklady sa počítajú tak, že sa plocha stropnej krytiny vynásobí nákladmi na materiál za 1 m 2.

Keď vo formulári „Výdavky“ kliknete na tlačidlo „Zvyšky“, programový modul vypočíta množstvo materiálu, ktoré zostáva v sklade. Pri vypĺňaní dvoch polí vo formulári „Zostatok“: dátum prijatia materiálu, dátum spotreby materiálu, dopyt prevezme údaje z databázy MySQL o výške príjmu materiálu v tomto mesiaci a výške spotreby v tomto mesiaci. Zvyšok materiálu sa počíta z rozdielu medzi príjmom a spotrebou materiálu za konkrétne časové obdobie.

1.2.2 Bloková schéma využívania komplexu programov (dialógový strom)

Systémová ponuka - je hlavnou formou dialógu v aplikovaných systémoch spracovania údajov, ktorá obsahuje príkazy určené na vykonávanie konkrétnych úloh.

Vyvinutá aplikácia má intuitívne menu. Práca s databázovými tabuľkami modulu „Enterprise Management“ IS pozostáva z:

prezeranie a úprava formulárov;

formuláre na výpočet nákladov na strop;

formy prezentácie grafických informácií.

2 TECHNOLOGICKÁ PODPORA

Technologická podpora (TO) obsahuje popis organizácie technológie na zber, prenos, spracovanie a vydávanie informácií, TO odráža postupnosť operácií, počnúc metódou zhromažďovania primárnych informácií, ktorá obsahuje dva typy dokumentov (dokumenty, údaje, z ktorých sa používajú na opravu referenčných informácií a dokumentov, operačné informácie používané na výpočty) a končiace tvorbou výsledkových informácií. Poskytuje tiež schému technologického procesu zhromažďovania, prenosu, spracovania a vydávania informačných a inštruktážnych kariet hlavných operácií technologického procesu, odrážajúcu prevádzkový popis technológie.

3 SOFTVÉR SÚBORU ÚLOH

Softvér pre komplex úloh bol vykonaný v programovacom prostredí PHP. Voľba prostredia je daná širokými možnosťami tohto programovacieho jazyka pre vytváranie aplikácií určených na prácu s elektronickými archívmi (databázami).

Vďaka svojej kompaktnej veľkosti a úzkemu rozsahu úloh, ktoré je potrebné vyriešiť, neobsahuje projekt v tejto fáze návrhu inštalačný balík, a preto sa distribúcia softvérového produktu vykonáva priamym kopírovaním.

3.1 Všeobecne

Modul IS "Enterprise Management" je vyrobený na základe technológie založenej na jeho službách v systémoch Windows s prístupom k MySQL.

MySQL je v súčasnosti jedným z najpopulárnejších DBMS. Medzi dôvody tejto popularity treba poznamenať:

Vysoký stupeň všestrannosti a premyslenosti rozhrania, ktoré je určené na prácu s používateľmi rôznych kvalifikácií. Implementovaný je najmä systém na správu databázových objektov, ktorý umožňuje flexibilne a rýchlo prepnúť z návrhového režimu do režimu ich priamej činnosti;

Hlboko vyvinuté možnosti integrácie s inými softvérovými produktmi;

Je potrebné poznamenať, že dostupnosť tohto softvérového produktu je významným dôvodom tak rozsiahleho používania MySQL.

3.2 Popis softvérových modulov

Informačný systém obsahuje moduly, ktoré vykonávajú všetky potrebné operácie s údajmi. Tieto moduly obsahujú formuláre na pridávanie, mazanie, triedenie a vyhľadávanie informácií. Modul „Objednávky“ navyše počíta cenu za inštaláciu napínacieho stropu, zadáva iba jeho rozmery a v module „Výdavky“ môžete sledovať schému spotreby materiálu v závislosti od mesiaca.

Po otvorení stránky „Produkty“ sa dostaneme k formuláru, kde sa nachádza 6 hlavných modulov programu: „Objednávky“, „Materiály“, „Spotreba“, „Príchod“, „Klienti“, „Zamestnanci“.

Keď kliknete na tlačidlá „Objednávky“, „Materiály“, „Výdavky“, „Príchod“, „Klienti“, „Zamestnanci“, dostaneme sa do príslušného formulára, v ktorom môžete pridávať, mazať, triediť, vyhľadávať informácie v databáze. Keď kliknete na jedno z týchto tlačidiel, automaticky sa dostaneme do formulára s riadkami na vyplnenie informácií na vymazanie, zoradenie, pridanie alebo vyhľadávanie, po vyplnení ktorých sa zobrazia súhrnné informácie.

Vo formulári „Objednávky“ sa nachádza tlačidlo „Náklady“, po kliknutí naň prejdete do formulára, v ktorom je potrebné vyplniť pole dĺžky, šírky miestnosti a textúry materiálu, výsledkom budú náklady na inštaláciu strečového stropu.

Po kliknutí na tlačidlo „Plán výdavkov“ sa vo formulári „Výdavky“ zobrazí obrázok schémy s grafickými informáciami o výdavkoch za relatívne časové obdobie.

ZÁVER

Výsledkom napísania projektu kurzu je vytvorenie aplikácie pre zamestnancov obchodných spoločností. Vyvinutý program môže výrazne zvýšiť produktivitu práce a automatizovať ich prácu.

Použitie nástrojov PHP, HTML a MySQL na vytváranie aplikácií bežiacich na operačnom systéme Windows a najmä na databázové aplikácie umožnilo vytvoriť softvérový produkt, ktorý je maximálne zameraný na koncového používateľa.

Všetky potrebné práce na implementácii metód prístupu k informáciám uloženým v databáze, ich úpravách, udržiavaní databázy v celistvej podobe sú otvorené pre používateľa, aby bolo možné úspešne vyriešiť celú škálu vznikajúcich problémov spojených s využívaním informácií uložených v databáze. Softvérové \u200b\u200brozhranie navyše uľahčuje prácu s databázou čo najjednoduchšie.

Všetky funkcie vykonávané informačným systémom boli počas procesu vývoja dôkladne skontrolované a otestované.

BIBLIOGRAFIA

1. Welling L. Vývoj webových aplikácií s PHP a MySQL. Vydavateľstvo „Williams“, 2003. - 288 s.: Chor.

2. Odkazy na PHP a MySQL. http://www.php.su/books/.

3. Súbory pomocníka pre phpMySQL_Admin

4. http://www.php.ru

5. http://www.mysql.ru

Zverejnené na Allbest.ru

Podobné dokumenty

Zverejnenie pojmov „informácie“, „údaje“, „vedomosti“. Opis podpory informácií mimo stroja a vnútri stroja, systémov ukazovateľov, klasifikácie a kódovania. Štúdia zloženia informačnej podpory pre manažment na konkrétnom príklade.

seminárna práca pridaná 26. 9. 2012


Metódy organizácie procesu spracovania informácií; hlavné smery implementácie vnútropodnikovej informačnej podpory. Princípy budovania a efektívneho využívania databázových technológií a databáz ako hlavných zložiek automatizovaných systémov.

dizertačná práca, pridané 30. 5. 2013


Klasifikácia informačných systémov a technológií v organizačnom manažmente. Metódy a organizácia tvorby IS a IT. Zloženie, štruktúra, podpora informácií v stroji. Informačné technológie a postupy spracovania ekonomických informácií.

test, pridané 25. 7. 2012


Informačný model a jeho popis. Klasifikátory a kódovacie systémy. Softvérová a technologická podpora. Funkčný strom a dialógový skript. Interakcia softvérových modulov. Technologický proces prenosu, spracovania a vydávania informácií.

dizertačná práca, pridané 1. 3. 2012


Charakteristika organizácie automatizovaného spracovania. Dátová schéma a jej popis. Charakteristiky vstupných a výstupných informácií. Organizácia technologického procesu zhromažďovania, prenosu, spracovania a vydávania informácií. Formalizácia automatizovaných úloh.

semestrálna práca, pridané 22.11.2013


Vývoj technickej podpory. Základné požiadavky, použitie a charakteristika moderných technických prostriedkov automatizovaných informačných systémov. Integrované technológie na spracovanie a ukladanie informácií. Vytvorenie databázy účtovníctva a predaja.

semestrálna práca, pridané 1. 12. 2010


Vývoj informačných systémov. Moderný trh finančného a ekonomického aplikovaného softvéru. Výhody a nevýhody implementácie automatizovaných informačných systémov. Metódy navrhovania automatizovaných informačných systémov.

práca, pridané 22.11.2015


Technologický proces zhromažďovania, prenosu, spracovania a vydávania informácií. Účel softvérového produktu. Analýza ekonomických ukazovateľov implementácie automatizovaného pracoviska pre pokladníka. Organizácia pracoviska operátora počítača.

diplomová práca, pridané 12. 8. 2014


Právny základ prenájmu v Kazašskej republike. Recenzia existujúceho softvéru pre prácu realitných kancelárií. Výber a návrh modelu infologickej databázy. Organizácia technológie na zber, prenos, spracovanie a vydávanie informácií.

dizertačná práca, pridané 2. 2. 2015


Organizácia prepravy nákladov v spoločnosti "Pallada-Torg". Vlastnosti riadenia dopravy: organizačná štruktúra a funkcie oddelenia informačných systémov; hodnotenie úrovne automatizácie a informatizácie procesu spracovania a prenosu informácií.

Vytvorené z mnohých modulov informačný systém umožnilo automobilovému závodu „Čajka-servis“ v Nižnom Novgorode realizovať myšlienku výroby, ktorá plne zohľadňuje želania zákazníkov, ktorí v podniku zadali svoje objednávky

Informačný systém vytvorený z rôznych modulov umožnil automobilovému závodu „Čajka-servis“ v Nižnom Novgorode realizovať myšlienku výroby, ktorá plne zohľadňuje želania zákazníkov, ktorí v podniku zadali svoje objednávky.

Hlavnou výzvou pre IT oddelenie v spoločnosti podnikajúcej v týchto náročných časoch je zníženie nákladov na IT a zabezpečenie riadenia pomocou nástrojov, ktoré im pomôžu prekonať krízu. Toto je názor Alexeya Ganina, vedúceho oddelenia IT automobilového závodu v Nižnom Novgorode „Chaika-Service“, ktorý sa špecializuje na výrobu sériových a jedinečných vozidiel na špeciálne účely.

Podnik sa rýchlo rozrástol v roku 2006, keď sa získala časť starého závodu a začal sa rozvoj druhého územia. Prirodzene vznikla úloha spojiť obe územia do jedného informačného poľa. Začali sme s vytvorením siete VPN, ale s nárastom počtu používateľov začala byť šírka pásma kanálu nedostatočná. Potom bol medzi týmito dvoma územiami položený kábel z optických vlákien.

S nástupom krízy sa znížila potreba sieťových zdrojov, čo umožnilo znížiť nákup aktívneho vybavenia pre telekomunikačnú infraštruktúru spoločnosti. Ďalším významným zdrojom znižovania nákladov bolo upustenie od outsourcingu a interné vykonávanie úloh IT.

Spoločnosť navyše optimalizuje náklady na internet, analyzuje a obmedzuje spotrebu prevádzky. Spoločnosť má pobočky v Krasnodare a Moskve, všetky pobočky sú spojené do IP siete s jediným číslovaním. A práve táto interná sieť sa používa na volanie v rámci podniku, čo je oveľa ekonomickejšie ako volanie cez diaľkovú telefónnu komunikáciu.

Z nástrojov, ktoré sa v blízkej budúcnosti dostanú do správy, pomenoval Ganin v prvom rade systém výpočtu nákladov. Už bol vyvinutý a bude slúžiť celkovému globálnemu cieľu znižovania nákladov. Aktualizovaný výpočet nákladov na tovar sa plánuje vykonať na základe systému správy technických údajov. Takto získate podrobné a prevádzkové údaje o nákladovej cene (predtým boli vypočítané na základe účtovných údajov). Podnik vyrába pomerne zložité výrobky, iba finálne varianty automobilov s rôznymi úpravami sú asi jeden a pol tisíca. Časti, z ktorých sú zostavené, sú samozrejme o dva rády viac.

Od účtovníctva po výrobu

Prvým krokom na ceste k automatizácii bola akvizícia produktu 1C: Accounting 6.0 a systému Compass CAD od spoločnosti Ascon v roku 2002. Ďalším krokom bola automatizácia výrobných činností. Spoločnosť "Rarus NN" na základe príkazu podniku začala prispôsobovať ERP systém "1C: Manufacturing Enterprise Management 8" ("1C: UPP 8") potrebám a charakteristikám podniku. Cieľom projektu bolo vybudovať jednotnú databázu a implementovať riadenie všetkých podnikových procesov na základe jediného informačného systému. Rozhodujúcim faktorom úspešnosti jeho implementácie bola priama podpora vrcholového manažmentu podniku - generálneho riaditeľa, ktorý inicioval a podporoval projekt vo všetkých jeho etapách.

Pri automatizácii výrobných činností sa osobitná pozornosť venovala adekvátnosti zobrazenia v systéme výrobného procesu. Špecialisti implementačného tímu vyvinuli technickú úlohu s podrobným popisom toho, aké auto v akej konfigurácii by mal klient dostať a čo je potrebné pre to urobiť pre každú objednávku. Do dokumentu bol zadaný typ automobilu, jeho model, zoznam požadovaných technologických operácií, ich postupnosť, zoznam kontrolných operácií a pod. Tento prístup umožnil spoločnosti viac sa orientovať na zákazníka, keďže technické špecifikácie formovali manažéri obchodného oddelenia, ktorí sa snažili v maximálnej možnej miere zohľadniť želania klienta a až potom boli úlohy odoslané do výroby.

Špecialisti na oddelenie IT spolu s technológmi vyvinuli blok špecifikácií pre výrobné a technologické mapy. Na ich základe a na základe mesačného plánu výroby hotových výrobkov sa určila potreba materiálov na určité obdobie s prihliadnutím na bežné zostatky. To všetko umožnilo kompetentne naplánovať prácu dodávateľského oddelenia.

Zamestnanci oddelenia IT vyvinuli modul pre „1C: UPP 8“ na import „stromu“ produktu zo systému „Compass“, ktorý používajú dizajnéri podniku. Pracovný algoritmus dopadol nasledovne: dizajnérska kancelária vytvorí výkres pomocou „Compassu“ a vytvorí 3D model objektu, následne sa pomocou vyvinutého modulu naimportuje štruktúra produktu do ERP systému, na základe ktorého sa na základe importovaných údajov vytvorí špecifikácia produktu. Ak návrhári urobia zmeny v ktoromkoľvek uzle, potom sa tieto zmeny automaticky prejavia vo všetkých systémoch.

Najskôr, ako pripustil Ganin, chcel spolu so svojimi špecialistami vytvoriť systém správy technických dát sám, ale čoskoro zistil, že skupina spoločností Appius, partner spoločnosti 1C, vyvíja svoje vlastné replikovateľné riešenie PDM (volalo sa to 1C: PDM Engineering data management ").

Spätná väzba

Ďalšou úlohou bolo získať prevádzkovú spätnú väzbu z výroby, čo je dôležité, pretože technologický cyklus výroby produktu môže trvať jeden až dva týždne. Predtým sa stav objednávky zisťoval jednoducho telefonicky, teraz sa však príslušné informácie prijímajú prostredníctvom informačného systému.

Prvým krokom v tomto smere bol vývoj systému na sledovanie stavu technických špecifikácií. Zmenili sa niektoré výrobné procesy, najmä pracovníci oddelenia kontroly kvality boli povinní odovzdať operátorovi správy o prijatých prácach a ten o nich zadal údaje do systému ERP. Výsledkom bolo, že systém začal postupne zobrazovať priebeh výrobnej zákazky a označoval zodpovedné osoby. To umožňovalo manažérom poskytovať zákazníkom pravdivé informácie o tom, v akom štádiu sú ich objednávky a kedy budú pripravené.

Ďalším krokom bola implementácia modulu plánovania výroby. Predtým sa plánovanie uskutočňovalo pomocou nástrojov Excel, často sa vyskytli nezrovnalosti a chyby. Po spustení ERP modulu plánovania výroby dostali manažéri k dispozícii faktické údaje generované na základe prijatých technických špecifikácií. To umožnilo rýchlo sledovať zaťaženie každého úseku. Výsledkom je vyššia presnosť a efektívnosť plánovania výroby.

Čoskoro boli potrebné ďalšie operatívne informácie o stave výrobných procesov, najmä o prestojoch. Na vyriešenie tohto problému bol zavedený systém, ktorý umožňuje sledovať priebeh výrobných procesov na základe čiarových kódov: každej technologickej operácii, každej technickej úlohe a každému zamestnancovi bol pridelený čiarový kód a do výroby boli nainštalované terminály vybavené snímačom čiarových kódov.

Výrobný proces je teraz štruktúrovaný nasledovne. Pred začatím práce sa majster alebo pracovník priblíži k terminálu, prečíta svoj čiarový kód, čiarový kód technického zadania a technologickej operácie. Z hľadiska systému to znamená, že zamestnanec nastúpil do práce. Po jeho skončení zamestnanec opakuje svoje kroky s čiarovými kódmi.

"Je to univerzálne riešenie a nevyžaduje, aby boli pracovníci počítačovo zdatní," hovorí Ganin. - Automobil je hlavnou a najdrahšou súčasťou našej výroby, zníženie prestojov nám umožnilo dramaticky urýchliť vykonávanie objednávok. V podniku sa objavil pohodlný a jednoduchý nástroj na analýzu strát: systém automaticky generuje pracovné diagramy pre každé auto, čo vám umožňuje sledovať, kedy sa na danom automobile začalo pracovať, kedy sa skončilo, ako dlho auto len čakalo na ďalšiu operáciu. Pri prekročení prípustného času sa začína zisťovanie príčin a hľadanie vinníkov tak dlhej odstávky. Vďaka tomu sa zvýšila osobná zodpovednosť umelcov.

Na základe „1C: UPP 8“ špecialisti podniku implementovali plánovaciu jednotku pre prácu projekčnej kancelárie. Technické úlohy vytvorené v systéme dostanú hlavný dizajnér, ktorý ich analyzuje, distribuuje ich rozpracovanie medzi svojich konštruktérov a určuje čas pre každú úlohu. Táto organizácia práce dáva šéfdizajnérovi a manažérom, ktorí tvoria základ objednávky, schopnosť sledovať mieru pracovnej záťaže konštrukčnej kancelárie a to nám zase umožňuje porovnávať pracovné vyťaženie výroby a dizajnérov a racionálne distribuovať dostupné ľudské a výrobné zdroje.

Údaje o vykonanej práci získané pomocou čiarových kódov idú jednotke na výpočet platov výkonných umelcov. Systém zaznamenáva čas práce, čo uľahčuje výpočet víkendov a hodín nadčas. To všetko prispieva k rýchlemu a presnému výpočtu miezd.

Je dôležité zdôrazniť, že spoločnosť sa vydala cestou expanzie

Základná konfigurácia ERP systému s ďalšími blokmi bez zmeny jeho vnútornej štruktúry. Bolo predovšetkým možné vykonať jeho aktualizácie bez problémov.

Na správu archívu projektovej dokumentácie podnik implementoval systém 1C: PDM Engineering Data Management (vyvinutý spoločnosťou Appius Group of Companies) a integroval ho do systému 1C: UPP 8. Okrem práce na vývoji nových produktov sa plánuje aj systém správy technických údajov, ktorý sa použije na presnejší výpočet nákladov na výrobky.

Mnohostranná integrácia

Spoločnosť implementovala GPS navigáciu na sledovanie zásobovacích a nákladných vozidiel, ktoré cestujú na veľké vzdialenosti. To nám umožňuje optimalizovať trasy, znižovať náklady na palivo a presnejšie udržiavať disciplínu dodávok.

„Chaika-Service“ plánuje prepojiť všetky pobočky do jednej siete prostredníctvom videokonferenčného systému - dve v Nižnom Novgorode a po jednej v Moskve, Krasnodare a Naberežnom Čelnom. Zlepší sa tak efektívnosť rozhodovania vrcholového manažmentu a výrazne sa znížia finančné a časové náklady na služobné cesty.

„Plánujeme tiež implementovať riešenie založené na 1C: UPP 8 pre interakciu s dopravnou políciou, prípravu a tlač evidenčných čísel vozidiel a tranzitných čísel,“ poznamenáva Ganin. - Všetky údaje budú zoskupené na jednom mieste na ukladanie informácií - karta automobilu, kde budú zadané všetky jej identifikačné čísla, farba, číslo karosérie atď., Potom sa tieto údaje použijú z hľadiska zadania, pri tlači názvu vozidla, čísel, certifikátov, účtov „. Takáto integrácia umožní zákazníkom spoločnosti získať spolu s autom hotové evidenčné čísla vozidiel a tranzitné čísla, aby bolo možné rýchlo zaregistrovať automobily na dopravnej polícii.

Úvod

Predmetná práca bola vypracovaná na základe Doneckej továrne pre Doneck OJSC pre obchod Cleonelly.

Jednou z vedúcich činností Doneckej manufaktúry OJSC je výroba širokej škály odevov, hlavne županov, plachiet a uterákov. Okrem toho spoločnosť vyrába farbenú bavlnenú priadzu na tkanie a pletenie.

Vývoj automatizovaných informačných technológií ide ruka v ruke so vznikom nových druhov technických prostriedkov na spracovanie a prenos informácií, zlepšovaním organizačných foriem používania počítačov, saturáciou infraštruktúry novými komunikačnými prostriedkami. Rozvoj trhových vzťahov viedol k vzniku nových druhov podnikateľskej činnosti a v prvom rade k vytvoreniu firiem zaoberajúcich sa informačným podnikaním, rozvoju informačných technológií, ich zlepšeniu, rozšíreniu komponentov automatizovaných informačných technológií, najmä softvérových produktov, ktoré automatizujú informácie a výpočtové procesy. Zahŕňajú tiež výpočtovú techniku, komunikačné zariadenia, kancelársku techniku \u200b\u200ba špecifické typy služieb - informačné, technické a poradenské služby, školenia atď. To prispelo k rýchlemu šíreniu a efektívnemu využívaniu informačných technológií v riadiacich a výrobných procesoch, takmer k ich rozšírenému použitiu a veľkej rozmanitosti.

Podniky zaoberajúce sa návrhom a vývojom zariadení na rôzne účely v súčasnosti široko využívajú rôzne prostriedky počítačom podporovaného návrhu - CAD (CAD) a monitorovania výrobných procesov - ACS (SCADA / DCS). Pre zariadenia vlastnej konštrukcie je však potrebné vyvinúť vlastné prostriedky na monitorovanie ich výkonu a analýzu kvality produktu.

Technologický proces účtovania výrobkov v sklade v obchode Cleanelly zahŕňa etapu vedenia záznamov o predaných výrobkoch.

Účelom tohto diplomového projektu je implementácia automatizovanej pracovnej stanice (AWP), ktorá umožňuje účtovanie výrobkov v sklade.

Na dosiahnutie vyššie uvedeného cieľa je potrebné vyriešiť nasledujúce úlohy:

¾ analyzovať obchodné procesy obchodu;

¾ preskúmať informačné toky vznikajúce vo fáze dodania vyvíjaného produktu;

¾ vývoj koncepčných a logických dátových modelov;

¾ vývoj softvéru pre automatizované pracovné stanice pre účtovníctvo výrobkov

¾ posúdiť ekonomickú efektívnosť informačného systému.

1 Vývoj softvérových požiadaviek

1.1 Analýza existujúcich riešení

V súčasnosti existuje široká škála spoločností, ktoré kombinujú priamy vývoj produktov aj vývoj riadiacich systémov pre tieto produkty. Takéto systémy vyvíjajú také známe spoločnosti ako 1: C Enterprise a Zvezda. V týchto systémoch sa vykonáva kontrola a účtovníctvo materiálov a spracovanie prijatých informácií.

„1C: Enterprise“ je systém aplikovaných riešení postavený na rovnakých princípoch a na jednej technologickej platforme. Manažér si môže zvoliť riešenie, ktoré zodpovedá súčasným potrebám podniku, a bude sa ďalej rozvíjať s rastom podniku alebo rozširovaním úloh automatizácie.

Softvérový systém 1C: Enterprise je navrhnutý tak, aby riešil širokú škálu úloh automatizácie účtovníctva a správy, ktorým čelí dynamicky sa rozvíjajúci moderný podnik. Riešenie urgentných problémov účtovníctva a riadenia Skladba programov systému 1C: Enterprise je zameraná na skutočné potreby podnikov. Firma „1C“ vyrába sériové softvérové \u200b\u200briešenia určené na automatizáciu typických účtovníckych a riadiacich úloh v podnikoch. Charakteristickým znakom riešení edície 1C je dôkladné preštudovanie zloženia funkčnosti obsiahnutej v štandardných riešeniach. Firma "1C" analyzuje skúsenosti používateľov s používaním programov systému "1C: Enterprise" a sleduje zmeny ich potrieb.

Medzi hlavné výhody môjho systému Wholesale Base patria relatívne nízke náklady na implementáciu tohto systému a množstvo ďalších výhod:

¾ Spoľahlivosť vytvorených aplikácií. Softvérový balík (PC) musí byť odolný nielen voči chybám používateľov, ale aj proti poruchám v komunikačnom systéme.

¾ Ľahké používanie rozhrania;

¾ Vysoká úroveň bezpečnosti systému, ktorá znamená nielen kontrolu nad dostupnosťou určitých systémových zdrojov a informačnú bezpečnosť vo všetkých fázach prevádzky, ale aj sledovanie vykonaných akcií s vysokou mierou spoľahlivosti.

1.2 Analýza domén

Zvláštnosťou analýzy predmetnej oblasti je, že vám umožňuje zobraziť celý súbor operácií organizácie.

CASE je navrhnutý tak, aby analyzoval a reorganizoval obchodné procesy. – Všetky nástroje najvyššej úrovne Fusion Process Modeler (BPwin) podporujúce metodiky IDEF0 (funkčný model), DFD (Dataflow Diagram) a IDEF3 (Workflow Diagram). BPwin je výkonný softvérový produkt na vytváranie modelov na analýzu, dokumentovanie a plánovanie zmien v zložitých obchodných procesoch. BPwin ponúka nástroj na zhromažďovanie všetkých potrebných informácií o fungovaní podniku a na vytváranie grafov týchto informácií vo forme koherentného a konzistentného modelu.

Z hľadiska funkčnosti systému. V rámci metodológie IDEF0 (Integration Definition for Function Modeling) je obchodný proces predstavovaný ako sada pracovných prvkov, ktoré navzájom interagujú a sú zobrazené informácie, ľudské a výrobné zdroje spotrebované každou prácou. Funkčný model je navrhnutý tak, aby popisoval existujúce podnikové procesy v podniku (tzv. Model AS-IS) a ideálny stav vecí – o čo sa treba usilovať (model TO-BE). Metodika IDEF0 predpisuje konštrukciu hierarchického systému diagramov, t.j. jednotlivé opisy fragmentov systému. Najskôr sa vykoná popis systému ako celku a jeho interakcie s vonkajším svetom (kontextový diagram), po ktorom sa vykoná funkčný rozklad. – systém je rozdelený na subsystémy a každý systém je popísaný osobitne (rozkladové diagramy). Potom sa každý subsystém rozdelí na menšie a tak ďalej, aby sa dosiahla požadovaná úroveň podrobností.

Ak je v procese modelovania potrebné zdôrazniť konkrétne aspekty podnikovej technológie, BPwin vám umožní prejsť na ktorúkoľvek vetvu modelu na notáciu DFD alebo IDEF3. Diagramy dátových tokov (DFD) môžu dopĺňať to, čo sa už odráža v modeli IDEF3, pretože popisujú dátové toky a umožňujú vám sledovať, ako sa vymieňajú informácie medzi obchodnými funkciami v systéme. Diagramy DFD zároveň ignorujú interakcie medzi obchodnými funkciami.

Z hľadiska postupnosti vykonávaných prác. A ešte presnejší obraz je možné získať doplnením modelu o diagramy IDEF3. Táto metóda upozorňuje na poradie, v ktorom sa udalosti vykonávajú. Prvky logiky sú zahrnuté v IDEF3, ktorý umožňuje modelovať a analyzovať alternatívne scenáre vývoja obchodného procesu.

Na zváženie obchodných procesov prebiehajúcich v sklade obchodu je potrebné použiť iba dve metodiky IDEF0 a DFD. Proces modelovania systému v IDEF0 sa začína definovaním kontextu, t.j. najabstrahovanejšia úroveň popisu systému alebo obchodných procesov všeobecne.

Model IDEF0 ... Ak chcete študovať obchodné procesy „Vytvorenie objednávky dodávateľa“, „Príjem tovaru“, „Vydanie tovaru“, zvážte diagramy, ktoré sú prezentované vo forme diagramu IDEF0. Systém IDEF0 je prezentovaný ako kolekcia interaktívnych aktivít alebo funkcií.

Metodika IDEF0 je založená na štyroch hlavných konceptoch.

Prvým je koncept funkčný blok (Činnosť) ... Funkčný blok je graficky znázornený vo forme obdĺžnika a personifikuje určitú konkrétnu funkciu v rámci uvažovaného systému.

Každá zo štyroch strán funkčného bloku má svoj vlastný špecifický význam (úlohu), zatiaľ čo:

Horná strana je Control;

Ľavá strana je nastavená na „Vstup“;

Pravá strana je nastavená na Výstup;

Nevýhodou je „mechanizmus“.

Druhou „veľrybou“ metodiky IDEF0 je koncept oblúka rozhrania (Arrow). Grafické zobrazenie oblúka rozhrania je jednosmerná šípka. Každý oblúk rozhrania musí mať svoj vlastný názov (Arrow Label). Pomocou oblúkov rozhrania sa zobrazujú rôzne objekty, ktoré do istej miery určujú procesy prebiehajúce v systéme. V takom prípade sa šípky podľa toho, do ktorej strany pracovného obdĺžnika vstúpia alebo ktoré opustia, rozdelia na:

Vstupné šípky (zahrnuté v ľavej časti funkčného bloku) - predstavujú údaje alebo objekty, ktoré sa počas vykonávania práce zmenili;

Ovládacie šípky (obsiahnuté v hornej časti funkčného bloku) - znázorňujú pravidlá a obmedzenia, kvôli ktorým sa práca vykonáva;

Šípky výstupu (výstup z pravej strany funkčného bloku) - predstavujú údaje alebo objekty, ktoré sa objavujú ako výsledok práce;

Šípky mechanizmu (zahrnuté v dolnom okraji funkčného bloku) - predstavujú zdroje (napríklad vybavenie, ľudské zdroje).

Tretím základným konceptom štandardu IDEF0 je rozklad. Princíp rozkladu sa používa pri rozklade zložitého procesu na jeho základné funkcie.

Dekompozícia umožňuje postupne a štruktúrovane predstavovať systémový model vo forme hierarchickej štruktúry jednotlivých diagramov, čo ho robí menej preťaženým a ľahko stráviteľným.

Posledným z konceptov IDEF0 je Slovník. Pre každý z prvkov IDEF0: diagramy, funkčné bloky, oblúky rozhrania znamená existujúca norma vytvorenie a údržbu súboru vhodných definícií, kľúčových slov, naratívov atď., Ktoré charakterizujú objekt zobrazený týmto prvkom. Táto sada sa nazýva slovník a je popisom podstaty tohto prvku.

Zvážte diagramy obchodných procesov prebiehajúcich v sklade obchodu OJSC DMM „Cleonelly“

Pre všeobecnú viditeľnosť systému je potrebné vytvoriť kontext „Činnosť podnikového skladu“ (pozri obrázok 1.1).

Obrázok 1.1 - Diagram "Činnosť podnikového skladu"

Po nadviazaní kontextu sa uskutoční rozklad, t.j. zostavenie nasledujúcich diagramov v hierarchii.

Každý nasledujúci diagram predstavuje podrobnejší popis jednej z prác vo vyššom diagrame. Príklad rozkladu kontextovej práce je uvedený na obrázku 1.2. Celý systém je teda na požadovanú úroveň podrobností rozdelený na subsystémy; tento systém je rozdelený do troch úrovní.

Obrázok 1.2 - Schémy rozkladu prvej úrovne

Obrázok 1.3 - Schéma „Registrácia tovaru“

Obrázok 1.4 - Schéma „Vydanie tovaru“

Obrázok 1.5 - Schéma "Zaúčtovanie tovaru"

DFD. Táto metodika je založená na konštrukcii modelu analyzovaného IS - projektovaného alebo skutočne existujúceho. V súlade s metodikou je systémový model definovaný ako hierarchia diagramov toku údajov (DFD), ktorá popisuje asynchrónny proces transformácie informácií z ich vstupu do systému na ich výstup pre používateľa. Diagramy DFD sa zvyčajne vytvárajú na vizualizáciu aktuálnej práce systému pracovných tokov organizácie. Najčastejšie sa diagramy DFD používajú na doplnenie modelu obchodného procesu implementovaného v IDEF0.

Hlavné komponenty diagramu toku údajov sú:

Externé entity (graficky znázornené ako štvorec) - označujú hmotný objekt alebo jednotlivca, ktorý je zdrojom alebo prijímateľom informácií. Napríklad: zákazníci, pracovníci, dodávatelia, zákazníci, sklad;

Systémy / podsystémy (graficky vyzerá ako obdĺžnik so zaoblenými rohmi) - diela označujúce funkcie alebo procesy, ktoré spracúvajú a menia informácie;

Zariadenia na ukladanie údajov sú abstraktné zariadenia na ukladanie informácií, ktoré je možné kedykoľvek vložiť do úložného zariadenia, a po chvíli je možné ich vyhľadať, pričom existuje akýkoľvek spôsob ich umiestňovania a načítania. Úložisko dát je vo všeobecnosti prototypom budúcej databázy a popis údajov v ňom uložených by mal súvisieť s informačným modelom;

Dátové toky - definuje informácie prenášané určitým pripojením zo zdroja do umývadla. Tok údajov v diagrame predstavuje čiara zakončená šípkou, ktorá označuje smer toku.

Zvážte diagram toku údajov o problémoch (DFD), obrázok 1.6. Tento diagram zobrazuje pohyb dokumentov, keď do organizácie dorazí „požiadavka na produkt“.

Obrázok 1.6 - Schéma DFD „Vydanie tovaru“

Zvážte nasledujúci vývojový diagram údajov „Odbavenie produktu“ (pozri obrázok 1.7). Zobrazuje proces vykonávania práce a pohybu dokumentov počas „výdaja tovaru“.

Obrázok 1.7 - Tabuľka DFD „Preclenie tovaru“

V diagramoch toku údajov všetky použité symboly vytvárajú celkový obraz, ktorý poskytuje jasnú predstavu o tom, aké údaje sa používajú a aké funkcie vykonáva systém pracovných tokov. Zároveň sa často ukazuje, že existujúce informačné toky, ktoré sú dôležité pre činnosť spoločnosti, nie sú spoľahlivo implementované a je potrebné ich reorganizovať. *******

Organizačná štruktúra podniku predávajúceho froté výrobky sa považuje za príklad spoločnosti OJSC „Donetsk Manufactura M“ obchodu Cleonelly:

V smere vývoja kontrolných systémov a účtovníctva materiálov môžu úspešne vyriešiť problémy:

1. Jedná sa o kontrolu nad dodávaným a skladovaným tovarom.

2. Informácie o dodávateľoch a spotrebiteľoch

3. Obsahuje tiež informačné informácie a informácie o výrobku

4. Obsahuje denník správy o prepustenom tovare

5. Obsahuje adresár tovaru

6. Automatizácia skladových funkcií (príjem, výdaj, odpis, rezervácia tovaru)

7. Evidencia a uchovávanie faktúr za zakúpené a predané tovary a služby, ako aj fakturácia preddavkov, odložená platba a dodanie tovaru

8. Tvorba faktúr a účtovníctvo vydaného tovaru

9. Vykonanie inventúry skladov s vytvorením výkazu o zbere, dokladom o nedostatku a prebytku

10. Tvorba súprav tovaru

Ako už bolo uvedené, hlavnou oblasťou činnosti tohto podniku je predaj bavlnených výrobkov. Proces návrhu zahŕňa mnoho etáp starostlivo vypracovaných manažérskymi štruktúrami dizajnérskych podnikov počas celej životnosti podniku. Tento proces nemožno zmeniť naraz, pretože sa týka mnohých oddelení samotného podniku, externých subdodávateľov a klientov projektového podniku. Preto sú podniky opatrné pri zavádzaní informačných systémov týkajúcich sa procesov riadenia návrhu a vývoja. Ruské podniky spravidla využívajú svoj vlastný vývoj v tejto oblasti.

1.3 Požiadavky na zhromažďovanie

Pri návrhu informačného systému (IS) pre „Pracovisko veľkoobchodného skladu“ bolo potrebné zhromaždiť požiadavky, ktoré by pomohli vytvoriť rozhranie takým spôsobom, aby koncovému používateľovi (zamestnancovi obchodu) vyhovovala práca s vyvinutým IS.

Vývoj požiadaviek je proces, ktorý zahŕňa činnosti potrebné na vytvorenie a schválenie dokumentu obsahujúceho špecifikáciu. požiadavky na systém.

Na implementáciu procesu automatizácie účtovníctva a kontroly materiálov je potrebné, aby informačný systém bol schopný splniť tieto funkčné požiadavky:

¾ dokumentácia výsledkov.

¾ Informačný systém musí byť implementovaný ako program založený na integrovanom prostredí Visual Fox Pro.

Program pracuje v operačnom systéme Windows 2000 / NT / XP.

Proces vývoja požiadaviek obsahuje štyri hlavné etapy (obrázok 1.8):

Analýza technickej uskutočniteľnosti vytvorenia systému;

Tvorba a analýza požiadaviek;

Upresnenie požiadaviek a vytvorenie príslušnej dokumentácie;

Osvedčenie o požiadavkách.

Zbierka požiadaviek je dôležitou etapou v dizajne softvéru, pretože práve tu musia byť správne a správne formulované všetky požiadavky zákazníkov.

1.4 Špecifikácia požiadaviek

Určenie správnych požiadaviek je pravdepodobne najdôležitejším krokom v softvérovom projekte. Je veľmi dôležité, aby formát projektu zodpovedal požiadavkám na softvér zostavený vývojovým tímom, inak tieto požiadavky nemožno v softvérovom produkte podporovať a prezentovať. Softvérové \u200b\u200bpožiadavky na softvér (SRS) sú kľúčom ku všetkému životný cyklus vývoj softvérových produktov. Nie je to len odvodený dokument, ktorý definuje špecifikácie softvérového projektu, ale aj hlavný dokument používaný na účely vykonania kvalifikačných a preberacích skúšok. Atestácia je hodnotením kvality práce projektových manažérov. Určuje stupeň súladu softvérového produktu so stanovenými požiadavkami. Špecifikácia SRS slúži ako mechanizmus na zaznamenávanie systémových požiadaviek, ktoré sa používajú ako kritériá pre atestáciu.

Na základe SRS sa dosahuje dohoda medzi zákazníkmi a výrobcami softvérového produktu. Špecifikácia SRS plne popisuje funkcie, ktoré musí vyvíjaný softvérový produkt vykonávať. To umožňuje potenciálnym používateľom určiť mieru, do akej produkt zodpovedá ich potrebám, ako aj spôsoby úpravy produktu tak, aby bol čo najužitočnejší pri riešení ich problémov.

Skracuje čas potrebný na vývoj. Na príprave špecifikácie SRS sa podieľajú rôzne skupiny v rámci organizácie zákazníka. Dôsledne preskúmajú všetky požiadavky ešte predtým, ako sa začne samotný vývoj projektu. To znižuje pravdepodobnosť následného prepracovania, kódovania a testovania.

Starostlivé preskúmanie požiadaviek v špecifikácii SRS môže odhaliť prehliadky, nedorozumenia a nezrovnalosti na začiatku vývojového cyklu, keď sa problémy dajú vyriešiť oveľa ľahšie ako neskôr.

Špecifikácia SRS sa stáva základom pre odhad a plánovanie nákladov. Popis produktu je skutočným základom pre odhad nákladov na projekt. V prostredí, kde existuje koncept formálneho návrhu, sa SRS používa na validáciu odhadu návrhu alebo ceny.

Vďaka dobre navrhnutým špecifikáciám môžu systémy SRS na úrovni organizácie vytvoriť oveľa produktívnejšie plány certifikácie a auditu. V rámci zmluvy o vývoji poskytuje SRS referenčný bod pre hodnotenie súladu so špecifikáciami.

Špecifikácia SRS uľahčuje prenos softvérového produktu k novým používateľom a jeho inštaláciu na iné počítače. Zákazníkom sa tak stane ľahší prenos softvérového produktu do iných oddelení organizácie a vývojárom jeho prenos k iným zákazníkom.

Špecifikácia SRS slúži ako základ pre modernizáciu. Tento dokument sa zaoberá samotným produktom, nie procesom vývoja projektu, takže ho možno použiť na rozšírenie hotového produktu.

Po dokončení procesu definovania a špecifikácie požiadaviek je potrebné požiadavky validovať.

Špecifikácia požiadaviek na softvérový projekt by mala byť uvedená v prílohe A.

1.5 Potvrdenie požiadaviek

Overenie musí preukázať, že požiadavky skutočne definujú systém, ktorý chce mať zákazník. Overenie požiadaviek je dôležité, pretože chyba v špecifikácii požiadaviek môže viesť k prepracovaniu systému a vysokým nákladom, ak sa objavia počas procesu vývoja systému alebo po jeho uvedení do výroby.

Počas procesu atestácie požiadaviek by sa mali vykonať rôzne typy kontrol dokumentácie požiadaviek:

1. Kontrola správnosti požiadaviek.

2. Kontrola konzistencie.

3. Skontrolujte úplnosť.

4. Kontrola uskutočniteľnosti.

Existuje niekoľko metód osvedčovania požiadaviek, ktoré sa dajú použiť spoločne alebo každý zvlášť:

1. Preskúmanie požiadaviek.

2. Prototypovanie.

3. Generovanie testovacích skriptov.

4. Automatizovaná analýza konzistencie.

Prototypovanie je pre zákazníka systému najviditeľnejšie.

Pred spustením prototypov môžete vytvoriť vývojový diagram používateľského rozhrania. Tento diagram sa používa na štúdium vzťahov medzi hlavnými prvkami používateľského rozhrania.

Ďalším krokom pri overovaní požiadaviek je priame prototypovanie.

Softvérový prototyp je čiastočná alebo možná implementácia navrhovaného nového produktu. Prototypy vám umožňujú splniť tri hlavné úlohy: vyjasnenie a dokončenie procesu formulácie požiadaviek, preskúmanie alternatívnych riešení a vytvorenie konečného produktu.

Prototyp hlavnej ponuky tohto modulu je zobrazený na obrázku 1.9.

1.6 Výber metodiky návrhu informačného systému

Podstata štrukturálneho prístupu k vývoju IS spočíva v jeho rozklade (rozdelení) na automatizované funkcie: systém je rozdelený na funkčné subsystémy, ktoré sú zasa rozdelené na podfunkcie, ďalej rozdelené na úlohy atď. Proces rozdelenia pokračuje až po konkrétne postupy. Automatizovaný systém si zároveň zachováva holistický pohľad na všetky komponenty, ktoré sú navzájom prepojené.

Všetky najbežnejšie metodiky štrukturálneho prístupu sú založené na rade všeobecných zásad. Nasledujúce princípy sa používajú ako dva základné princípy:

Rozdeľuj a panuj - princíp riešenia zložitých problémov ich rozdelením na mnoho menších, nezávislých problémov, ktoré sú ľahko pochopiteľné a riešiteľné;

Princíp hierarchického usporiadania je princíp organizovania základných častí problému do hierarchických stromových štruktúr s pridaním nových detailov na každej úrovni.

V štrukturálnej analýze existujú hlavne dve skupiny nástrojov, ktoré ilustrujú funkcie vykonávané systémom a vzťahy medzi údajmi. Každá skupina fondov zodpovedá určitým typom modelov (diagramov), najbežnejším z nich sú:

Modely SADT (štruktúrovaná analýza a návrhová technika) a súvisiace funkčné diagramy;

Diagramy dátových tokov DFD (Data Flow Diagrams);

ERD (Entity-Relationship Diagrams) diagramy entitných vzťahov.

Vo fáze návrhu IS sa modely rozširujú, zdokonaľujú a dopĺňajú o diagramy, ktoré odrážajú štruktúru softvéru: architektúra softvéru, programové blokové diagramy a diagramy obrazoviek.

Uvedené modely poskytujú úplný popis adresy IP bez ohľadu na to, či existuje alebo je novo vyvinutá. Zloženie diagramov v každom konkrétnom prípade závisí od požadovanej úplnosti popisu systému.

2 NÁVRH INFORMAČNÉHO SYSTÉMU

2.1 Architektonický návrh

Pri vytváraní komplexného informačného systému je jeho architektúra kritickým aspektom, kde predstavuje koncepčnú víziu štruktúry budúcich funkčných procesov a technológií na systémovej úrovni a vo vzájomnom prepojení. Zložité informačné systémy organizácií sú zvyčajne koncipované ako zloženie komponentov na vysokej úrovni interagujúcich, ktoré môžu byť samy osebe systémy. Architektúra informačného systému organizácie uľahčuje porozumenie systému tým, že definuje jeho funkčnosť a štruktúru spôsobom, ktorý odhaľuje rozhodnutia o dizajne a umožňuje pozorovateľovi klásť otázky týkajúce sa splnenia požiadaviek na návrh, pridelenia funkčnosti a implementácie komponentov.

Architektúra informačného systému organizácie je modelom toho, ako informačné technológie podporia hlavné ciele a stratégiu vývoja automatizovaného objektu. Umožňuje vám kriticky uvažovať a formulovať víziu toho, ako by mali byť štruktúrované integrované súbory informačných systémov na dosiahnutie týchto cieľov. Architektúra informačného systému popisuje jednotné a jednotné fungovanie informačných systémov, aplikácií a ľudí v celej organizácii.

Architektúra informačného systému teda obsahuje všeobecne akceptovanú sadu komponentov, ktoré poskytujú „stavebné kamene“ informačného systému. Tieto „stavebné kamene“ a ich charakteristiky sú definované na príslušnej úrovni podrobností, aby vyhovovali potrebám plánovacích rozhodnutí.

Pri navrhovaní moderných informačných systémov organizácií by sa ich architektúra mala vyvíjať s prihliadnutím na mnoho zainteresovaných strán, mala by byť pre používateľov zrozumiteľná, umožniť vývojárom plánovať a plánovať systém, umožniť definovanie kľúčových rozhraní, funkcií a technológií a tiež umožniť odhad časového harmonogramu a rozpočtu projektu. To si vyžaduje zodpovednosť architektov moderných informačných systémov za vytvorenie uspokojivého a uskutočniteľného konceptu systému v najskoršej fáze jeho vývoja, za zachovanie celistvosti tohto konceptu počas celého vývoja a za určenie vhodnosti výsledného systému pre použitie klientom. Na druhej strane, architektúra informačného systému je proces podrobného opisu architektúr informačného systému, aby boli užitočnejšie pre návrh informačného systému.

Štúdia zahraničných skúseností ukazuje, že vo vyspelých krajinách musia byť pri vývoji architektúry informačného systému splnené tieto podmienky:

¾ zameranie na poslanie organizácie;

¾ zameranie na požiadavky;

¾ zameranie na rozvoj;

¾ schopnosť prispôsobiť sa;

¾ potreba flexibility.

Dodržiavanie všetkých týchto podmienok umožňuje rozvinúť architektúru informačného systému organizácie dokonalejšie a efektívnejšie.

Hlavné softvérové \u200b\u200barchitektúry, ktoré sa v súčasnosti implementujú, sú:

¾ súborový server;

¾ klient-server;

¾ viacúrovňové.

Súborový server ... Táto architektúra centralizovaných databáz s prístupom do siete zahŕňa označenie jedného z počítačov v sieti ako dedikovaného servera, ktorý bude ukladať súbory centralizovanej databázy. V súlade s požiadavkami používateľov sa súbory zo súborového servera prenášajú na pracovné stanice používateľov, kde sa vykonáva väčšina spracovania údajov. Centrálny server vykonáva hlavne iba úlohu ukladania súborov, nepodieľa sa na samotnom spracovaní údajov. Po dokončení práce používatelia skopírujú súbory so spracovanými údajmi späť na server, odkiaľ ich môžu vziať a spracovať ďalší používatelia. Táto organizácia údržby údajov má množstvo nevýhod, napríklad keď k rovnakým údajom súčasne pristupuje viac používateľov, pracovný výkon prudko klesá, pretože je potrebné počkať, kým používateľ pracujúci s údajmi dokončí svoju prácu. V opačnom prípade môžu byť zmeny vykonané niektorými používateľmi prepísané zmenami vykonanými inými používateľmi.

Klientsky server ... Tento koncept je založený na myšlienke, že okrem ukladania databázových súborov musí centrálny server vykonávať väčšinu spracovania údajov. Používatelia pristupujú k centrálnemu serveru pomocou špeciálneho jazyka Structured Query Language (SQL), ktorý popisuje zoznam úloh vykonávaných serverom. Požiadavky používateľov prijíma server a generujú v ňom procesy spracovania údajov. Ako odpoveď dostane užívateľ už spracovanú množinu údajov. Medzi klientom a serverom sa neprenáša celá sada údajov, ako je to v prípade technológie súborových serverov, ale iba údaje, ktoré klient potrebuje. Dotaz používateľa, ktorý je dlhý iba niekoľko riadkov, môže vygenerovať spracovanie údajov zahŕňajúce veľa tabuliek a milióny riadkov. Ako odpoveď môže klient dostať iba niekoľko čísel. Technológia klient-server zabráni prenosu veľkého množstva informácií v sieti presunom všetkého spracovania údajov na centrálny server. Uvažovaný prístup navyše umožňuje vyhnúť sa konfliktom zmien rovnakých údajov viacerými používateľmi, ktoré sú typické pre technológiu súborového servera. Technológia klient-server implementuje konzistentné úpravy údajov viacerými klientmi, čím zaisťuje automatickú integritu údajov. Vďaka týmto a niektorým ďalším výhodám sa technológia klient-server stala veľmi obľúbenou. Medzi nevýhody tejto technológie patria vysoké požiadavky na výkon centrálneho servera. Čím viac klientov vstúpi na server a čím väčšie množstvo spracovaných údajov, tým silnejší musí byť centrálny server.

Na základe týchto úvah sa pri návrhu architektúry AWS brala ako základ technológia klient-server. Schémy usporiadania zobrazujú fyzické vzťahy medzi softvérovými a hardvérovými komponentmi systému.)

2.2 Návrh rozhrania informačného systému

Používateľské rozhranie sa často chápe iba ako vzhľad programu. V skutočnosti však používateľ prostredníctvom neho vníma celý systém ako celok, čo znamená, že také jeho chápanie je príliš úzke. V skutočnosti užívateľské rozhranie obsahuje všetky aspekty dizajnu, ktoré ovplyvňujú interakciu medzi používateľom a systémom. Používateľ nevidí iba obrazovku. Používateľské rozhranie sa skladá z mnohých komponentov, napríklad:

súbor užívateľských úloh, ktoré rieši pomocou systému;

ovládacie prvky systému;

navigácia medzi systémovými blokmi;

vizuálny dizajn obrazoviek programov.

Tu sú niektoré z najvýznamnejších obchodných výhod dobrého používateľského rozhrania:

zníženie počtu užívateľských chýb;

zníženie nákladov na údržbu systému;

znižovanie straty produktivity zamestnancov počas implementácie systému a ďalšie rýchle uzdravenie stratená produktivita;

zlepšenie morálky zamestnancov;

zníženie nákladov na zmenu používateľského rozhrania na žiadosť používateľov;

dostupnosť funkčnosti systému pre maximálny počet používateľov.

Veľkoobchodná základňa AWP je vyvinutá ako aplikácia využívajúca technológiu klient-server.

2.2.1 Užívateľské rozhranie riadiaceho programu

Hlavným modulom „AWP Wholesale Base“ je modul Luck.exe, ktorý poskytuje implementáciu hlavnej funkčnosti diagramu prípadov použitia znázorneného na obrázku 1.9 v časti 1.4.

Pri vývoji informačného systému je jednou z hlavných úloh vytvorenie najjednoduchšieho a nenačítaného rozhrania. Je to rozhranie softvérového produktu, ktoré pomáha používateľom „komunikovať“ s informačným systémom a slúži ako dialóg medzi používateľom a systémom.

Programové rozhranie, administratívna časť:

1. začiatočná forma programu. Tento formulár sa spustí pri spustení softvérového produktu, čím sa vytvorí začiatok dialógu používateľa so systémom (obrázok 2.3);

2. admin formulár. V tejto podobe úplná kontrola informačný systém, t.j. pridávanie, mazanie, zmena údajov v databáze, ako aj v prípade potreby prezeranie a tlač správ (obrázok 2.4);

3. Formulár „Zákazníci“, vďaka tomuto formuláru môžete vidieť všetky informácie o zákazníkoch podniku (obrázok 2.7);

4. Formulár „Dodávatelia“, vďaka tomuto formuláru môžete vidieť úplné informácie o zákazníkoch podniku (obrázok 2.8).

Užívateľské rozhranie programu:

V okne príchodu tovaru sa tovar spracováva Pri výbere tejto karty formulára musí používateľ najskôr

V ponuke výdavkov sa nachádzajú operácie vykonané zamestnancom skladu pri výdaji a predaji tovaru.

V zostatkoch na menu sa počíta tovar, názvy položiek uložených v sklade.

V ponuke pokladníka sú tu uložené informácie o kreditných príkazoch a príkazoch na odtok hotovosti. (Screenshoty)

2.2.2 Používateľské rozhrania ovládacích komponentov

Obr 2.0 Hlavné menu programu

Hlavné okno programu je zobrazené na obr. 1.9. Ako je zrejmé z obrázku, okrem hlavnej ponuky, ktorá už bola popísaná vyššie, bude obsahovať aj ovládací panel (tlačidlá „Príjmy“, „Spotreba“, „Prístup“, „Zostatky“, „Pokladňa“, „Precenenie“, „Analytics“, „ Adresáre “,„ Služba “a„ Ukončiť program “).

Obrázok 2.1 Okno ponuky príjem alebo príjem na sklade.

Obrázok 2.2 Okno ponuky Spotreba

Obrázok 2.2 Okno ponuky regulujúce prístupové práva k programu.

Obrázok 2.3 Okno ponuky pre zvyšok tovaru.

Obrázok 2.4 Okno ponuky Pokladňa.

Obrázok 2.4 Okno ponuky precenenia.

2.3 Návrh databázy

Na návrh databázy bol použitý ERwin 4.0 od Computer Associates Int.

ERwin je výkonný a ľahko použiteľný nástroj na návrh databázy, ktorý si získal široké prijatie a popularitu. Poskytuje najvyššiu produktivitu pri vývoji a údržbe databázových aplikácií. Počas celého procesu - od logického modelovania informačných požiadaviek a obchodných pravidiel, ktoré definujú databázu, až po optimalizáciu fyzického modelu v súlade so zadanými charakteristikami - vám ERwin umožňuje vizuálne zobraziť štruktúru a základné prvky databázy.

ERwin je nielen najlepším nástrojom na návrh databázy, ale aj nástrojom na ich vytvorenie rýchla tvorba... ERwin optimalizuje model podľa fyzikálnych charakteristík cieľovej databázy. Na rozdiel od iných nástrojov, ERwin automaticky udržiava konzistenciu logických a fyzických schém a prevádza logické konštrukcie, ako sú vzťahy medzi mnohými, do fyzických implementácií. Uľahčuje návrh databázy. K tomu stačí vytvoriť grafiku Model E-R (vzťahový objekt), ktorý spĺňa všetky požiadavky na údaje, a zadaním obchodných pravidiel vytvorí logický model, ktorý zobrazí všetky prvky, atribúty, vzťahy a zoskupenia. Erwin má dve úrovne prezentácie modelov - logickú a fyzickú. Logická vrstva je abstraktný pohľad na dáta, na ktorom sú dáta prezentované tak, ako vyzerajú v reálnom svete, a je možné ich nazvať tak, ako sa v reálnom svete nazýva, napríklad „Loajálny zákazník“, „Oddelenie“ alebo „Priezvisko zamestnanca“. Modelové objekty, ktoré sú reprezentované na logickej úrovni, sa nazývajú entity a atribúty. Logická úroveň dátového modelu je univerzálna a nemá nič spoločné so špecifickou implementáciou DBMS. Existujú tri podúrovne logickej úrovne dátového modelu, ktoré sa líšia v hĺbke prezentácie informácií o dátach:

Diagram vzťahov medzi entitami (ERD);

Kľúčový model (KB);

Plne priradený model (FA).

Schéma entít - Vzťah zahŕňa entity a vzťahy, ktoré odrážajú základné obchodné pravidlá domény. Takýto diagram nie je príliš podrobný, obsahuje hlavné entity a vzťahy medzi nimi, ktoré vyhovujú základným požiadavkám. Schéma entít - Vzťah môže obsahovať vzťahy medzi mnohými a nebude obsahovať kľúčové popisy. ERD sa zvyčajne používa na prezentácie a diskusiu o dátových štruktúrach s odborníkmi na domény. Kľúčovým dátovým modelom je podrobnejší pohľad na dáta. Zahŕňa popis všetkých entít a primárnych kľúčov a má predstavovať dátovú štruktúru a kľúče, ktoré zodpovedajú predmetnej oblasti.

Logický model je najpodrobnejším znázornením dátovej štruktúry: predstavuje údaje v tretej normálnej forme a zahŕňa všetky entity, atribúty a vzťahy (pozri prílohu B).

Fyzický dátový model naopak, záleží to na konkrétnom DBMS, čo je v skutočnosti zobrazenie systémového katalógu. Fyzická vrstva modelu obsahuje informácie o všetkých objektoch v databáze. Pretože neexistujú žiadne štandardy pre databázové objekty (napríklad neexistuje štandard pre dátové typy), fyzická vrstva modelu závisí od konkrétnej implementácie DBMS. V dôsledku toho môže niekoľko rôznych fyzických úrovní rôznych modelov zodpovedať rovnakej logickej úrovni modelu. Ak na logickej úrovni modelu nezáleží viac na tom, aký konkrétny dátový typ atribútu (hoci sú podporované abstraktné dátové typy), potom je na fyzickej úrovni modelu dôležité popísať všetky informácie o konkrétnych fyzických objektoch - tabuľky, stĺpce, indexy, postupy atď. ... Rozdelenie dátového modelu na logickú a fyzickú úroveň vám umožňuje vyriešiť niekoľko dôležitých problémov.

Fyzický dátový model je uvedený v prílohe B.

2.4 Zdôvodnenie výberu platformy pre vytvorenie informačného systému

Visual FoxPro je vizuálne vývojové prostredie pre systémy správy relačných databáz, ktoré v súčasnosti poskytuje spoločnosť Microsoft. Najnovšia verzia je 9,0. Používa programovací jazyk FoxPro. Systémová verzia 7.0 môže bežať na jadre Windows 9x a NT, verzie 8.0 a 9.0 - iba na Windows XP, 2000, 2003.

FoxPro (Fox-pro?) Je jedným z dialektov programovacieho jazyka xBase. Používa sa hlavne na vývoj relačných DBMS, aj keď je možné ho použiť na vývoj ďalších tried programov. Ako bolo uvedené vyššie, jazyk VFP je výrazne rozšírený a rozšírený jazyk xBase. Vo Visual FoxPro, programovacom jazyku, to znamená, že základnou stavbou jazyka je koncept triedy. Pôvodná verzia xBase je najčistejší štruktúrovaný jazyk so základnou koncepciou postupov a funkcií. Moderný programovací jazyk Visual FoxPro vám teda umožňuje kombinovať „staromódne“ programovanie popisom množstva postupov a štýlom OOP a vytvárať tak komplexnú hierarchiu tried.

Tento programovací jazyk som si vybral, pretože obsahuje niekoľko nasledujúcich výhod:

¾ Známy formát databázovej tabuľky, ktorý umožňuje ľahkú organizáciu výmeny informácií s inými aplikáciami Microsoft Windows.

Moderná organizácia relačných databáz, ktorá umožňuje ukladať informácie o databázových tabuľkách, ich vlastnostiach, indexoch a vzťahoch, nastavovať podmienky referenčnej integrity, vytvárať lokálne a vzdialené pohľady, pripojenia k serverom, uložené procedúry vykonávané pri výskyte viac ako 50 rôznych druhov udalostí (VFP 7,0-9,0).

Vysoká rýchlosť práce s veľkými databázami.

Vysoká viditeľnosť práce s databázami: multifunkčné okno relácie údajov umožňuje zobraziť zoznam otvorených databázových tabuliek, ich vzťahov, filtrov, poradia indexov, režimov vyrovnávacej pamäte, prepnúť na režimy úprav štruktúr, pracovať s informáciami o tabuľke atď.

Vysoká rýchlosť vývoja aplikácií pomocou sprievodcov, návrhárov, staviteľov, režimu rád IntelliSense pri písaní programov, ladení a testovaní programov.

Schopnosť vyvíjať aplikácie typu klient-server s údajmi umiestnenými na databázových serveroch Oracle a Microsoft SQL Server a s inými aplikáciami systému Microsoft Windows pomocou ODBC a OLE

Systém VFP je určený na použitie profesionálnymi programátormi, takže nemá zmysel rusifikovať jeho ponuku a jazyk - pre každého programátora je anglická syntax algoritmického jazyka známejšia ako ruština.

2.5 Návrh modulov

Pozrime sa podrobnejšie na návrh jedného z programových modulov a zvážme na jeho príklade kroky potrebné na vytvorenie projektu.

Ako príklad zvážim návrh modulu, ktorý implementuje prípad použitia „Vydá žiadosť o prijatie“.

Najprv popíšeme toky udalostí, ktoré sa vyskytujú v tomto prípade použitia.

Predpokladom pre prípad použitia je prijatie žiadosti od klienta.

5. Prípad použitia sa začína, keď zákazník podá žiadosť.

6. Manažér otvorí formulár Príjem.

7. Správca nastaví dátum podania žiadosti.

8. Manažér uvedie názov produktu.

9. Manažér zadá množstvo prijatého tovaru.

10. Manažér zadá sumu aplikácie.

11. Manažér zavrie formulár.

12. Prípad použitia končí.

Podmienkou prípadu použitia je registrácia aplikácie v systéme a vzhľad nového klienta v denníku hlavného formulára.

Zvážte postupový diagram pre tento prípad použitia. Ako je zrejmé z tohto diagramu, manažér otvorením formulára Príchod spôsobí vykonanie niekoľkých akcií - automaticky (z pohľadu manažéra) sa vyplní dátum aplikácie. Zoznam klientov pri podávaní žiadosti je zo základne vyplnený primárnymi informáciami. Potom manažér zadá všetky potrebné údaje a stlačí tlačidlo „Prijať“. V takom prípade sa vykonajú nasledujúce akcie. Všetky údaje sa odovzdajú uloženej procedúre.

3 Implementácia a validácia informačného systému

3.1 Implementácia aplikácie

Implementácia aplikácie je vo svojej podstate jednou z namáhavých fáz pre vývojára informačného systému, pretože požiadavky, ktoré zákazník kladie, musia byť do systému jasne a správne integrované. Zatiaľ neexistujú také softvérové \u200b\u200bprodukty, ktoré by sa mohli „prispôsobiť“ požiadavkám takzvaného zákazníka a poskytnúť určitý súbor funkcií pre implementáciu systému, ktorý by tieto požiadavky spĺňal. Preto si každý vývojár musí zvoliť optimálne prostredie pre vývoj systému, treba si však uvedomiť, že pri implementácii aplikácie sa človek nezaobíde bez napísania programového kódu. Určité funkcie, ktoré musí systém vykonávať, sa implementujú pri písaní programového kódu. V závislosti na vybranom prostredí implementácie systému bude programový kód vyzerať inak, v takom prostredí ako Microsoft Visual FoxPro bude jeden programový kód, v jazyku Visual Basic ďalší atď.

V tomto prípade bola aplikácia implementovaná v programe Microsoft Visual FoxPro.

Hlavné funkcie systému budú popísané nižšie:

1. Štartovacia podoba systému. Tento formulár je tlačidlový a podľa toho každé tlačidlo plní svoju funkciu. Tlačidlo registrácie správcu je zobrazené na obrázku 3.1. Toto tlačidlo vykoná funkciu, ktorá otvorí panel správcu, ak má používateľ také práva k tomuto systému.

2. Príchod tlačidla ponuky. Toto tlačidlo umožňuje sledovať prichádzajúci tovar do skladu v obchode Obrázok 3.2.

3. V tlačidle ponuky sa výdajka vedie evidencia tovaru prepusteného zo skladu Obrázok 3.3.

4. V tlačidle ponuky prístupu sa upravujú práva na používanie tohto programu Obrázok 3.4.

5. Tlačidlo ponuky zostáva ukladať informácie o materiáloch uložených v sklade obchodu Obrázok 3.5.

6. Tlačidlo menu pokladne ukladá informácie o prijatých hotovostných príkazoch a odchádzajúcich hotovostných príkazoch Obrázok 3.6.

7. V precenení tlačidla ponuky sa vykonajú zmeny ceny pre novú cenu tovaru Obr.3.7.

Obrázok 3.1 - Formulár spustenia systému

Obrázok 3.2 - Forma účtovania o príjmoch tovaru do skladu.

Obrázok 3.3– Forma účtovania o prepustenom tovare.

Obrázok 3.4– Formulár upravujúci prístupové práva k programu.

Obrázok 3.5– Forma zvyškov tovaru v sklade.

Obrázok 3.5 - Formulár o príjmových dokladoch a pokladničných dokladoch.

Obrázok 3.6 - Forma operácií s tovarom.

Testovanie aplikácie

Testovanie je proces vykonávania programu na zisťovanie chýb. Testovanie poskytuje:

Detekcia chýb;

Preukázanie súladu funkcií programu s jeho účelom;

Ukážka implementácie požiadaviek na charakteristiku programu;

Zobrazenie spoľahlivosti ako ukazovateľa kvality programu.

Obrázok 3.2 zobrazuje informačné toky procesu testovania.

Pri vstupe do procesu testovania sú tri prúdy:

Text programu;

Počiatočné údaje pre spustenie programu;

Očakávané výsledky.

Vykonajú sa testy a vyhodnotia sa všetky získané výsledky. To znamená, že skutočné výsledky testov sa porovnajú s očakávanými výsledkami. Keď sa nájde nesúlad, zaznamená sa chyba a začne sa ladenie.

Po zhromaždení a vyhodnotení výsledkov testu sa začne zobrazovať kvalita a spoľahlivosť softvéru. Ak sa pravidelne vyskytujú vážne chyby, ktoré si vyžadujú zmeny v dizajne, je kvalita a spoľahlivosť softvéru podozrivá a je uvedená potreba posilniť testovanie.

Výsledky zhromaždené počas testovania možno hodnotiť formálnejším spôsobom. Na tento účel sa používajú modely spoľahlivosti softvéru, ktoré predpovedajú spoľahlivosť na základe reálnych údajov o chybovosti.

Existujú dva princípy testovania softvéru:

Funkčné testovanie (testovanie čiernej skrinky);

Štrukturálne testovanie (testovanie pomocou bielej skrinky).

Pri testovaní metódy „bielej skrinky“ je známa vnútorná štruktúra programu. Cieľom testovania tu nie je vonkajšie, ale vnútorné správanie programu. Kontroluje sa správnosť konštrukcie všetkých prvkov programu a správnosť ich vzájomnej interakcie.

Testovanie čiernej skrinky (funkčné testovanie) poskytuje kombinácie vstupov, ktoré poskytujú úplná kontrola všetky funkčné požiadavky na program //. Softvérový produkt sa tu považuje za „čiernu skrinku“, ktorej správanie je možné určiť iba preskúmaním jeho vstupov a zodpovedajúcich výstupov.

Princíp „čiernej skrinky“ nie je alternatívou k princípu „bielej skrinky“. Ide skôr o doplnkový prístup, ktorý zistí inú triedu chýb.

Testovanie čiernej skrinky vyhľadáva nasledujúce kategórie chýb:

Nesprávne alebo chýbajúce prvky;

Chyby rozhrania;

Chyby v externých údajových štruktúrach alebo v prístupe k externej databáze;

Charakteristické chyby (požadovaná kapacita pamäte atď.);

Chyby inicializácie a dokončenia.

Na rozdiel od testovania bielej skrinky, ktoré sa vykonáva na začiatku testovacieho procesu, sa testovanie čiernej skrinky používa v neskorších fázach testovania. Pri testovaní čiernej skrinky sa riadiaca štruktúra programu zanedbáva. Tu sa pozornosť zameriava na informačnú oblasť definície softvérový systém... Testovanie počas tejto fázy sa zameriava na vhodnosť riešenia pre živé produkčné prostredie. Dôraz je kladený na opravu chýb a identifikáciu ich závažnosti a prípravu produktu na vydanie.

Vo fáze testovania sú vyriešené dve hlavné úlohy:

Testovanie riešenia - Testovacie plány vytvorené vo fáze plánovania a rozšírené a testované vo fáze vývoja sa vykonajú;

Pilotná prevádzka - nasadenie riešenia v testovacom prostredí a testovanie so zapojením budúcich používateľov a implementácia reálnych scenárov používania systému. Táto úloha je dokončená pred začiatkom fázy nasadenia.

Účelom testovacej fázy je znížiť riziko, ktoré nastane pri uvedení roztoku do komerčnej prevádzky.

Aby bola testovacia fáza úspešná, je potrebné zmeniť prístup k projektu a vývojár prejsť od vývoja nových funkcií k zabezpečeniu správnej kvality riešenia.

V tejto fáze vývoja informačného systému by sa mali vykonať tieto typy testovania:

Základné testovanie je technické testovanie na nízkej úrovni. Vykonáva to samotný vývojár v procese písania programového kódu. Používa sa metóda „bielej skrinky“, vysoké riziko chýb.

Testovanie použiteľnosti - Testovanie na vysokej úrovni vykonané testerom a budúcimi používateľmi produktu. Uplatňuje sa metóda „čiernej skrinky“.

Alfa a beta testovanie - z hľadiska MSF je alfa v podstate všetko zdrojové textyvytvorený počas vývojovej fázy procesného modelu MSF a beta kód je kód, ktorý bol testovaný počas testovacej fázy. Alfa kód sa preto testuje počas vývojovej fázy procesného modelu MSF a beta kód sa testuje počas testovacej fázy.

Testovanie kompatibility - vyvíjané riešenie vyžaduje integráciu a interoperabilitu s existujúcimi systémami a softvérovými riešeniami. Táto forma testovania je zameraná na testovanie integrovateľnosti a schopnosti vyvinutého riešenia interagovať s existujúcimi systémami. V tomto konkrétnom prípade sa skontroluje správna činnosť aplikácie na zariadení používateľa a softvér používaný používateľom.

Testovanie výkonu - zamerané na kontrolu, či aplikácia spĺňa výkonové požiadavky a úroveň komfortu z hľadiska rýchlosti.

Dokumentácia a testovanie systému pomoci - testujú sa všetky vyvinuté podporné dokumenty a systémy pomoci.

Pilotná prevádzka testuje riešenie v priemyselnom prostredí. Hlavným cieľom pilotnej prevádzky je preukázať, že riešenie je schopné stabilnej prevádzky v priemyselných podmienkach a spĺňa obchodné požiadavky. Počas pilotnej prevádzky je riešenie testované v reálnych podmienkach. Pilotná prevádzka umožňuje používateľom poskytovať spätnú väzbu o výkone produktu. Na základe tohto stanoviska vývojár eliminuje všetky možné problémy alebo v prípade nepredvídaných okolností vytvorí akčný plán. Pilotná prevádzka nakoniec umožňuje prijať rozhodnutie, či zahájiť úplné nasadenie alebo odložiť, kým nebudú vyriešené problémy, ktoré by mohli narušiť nasadenie.

Plán procesu pilotnej prevádzky vyvinutého informačného systému je uvedený v tabuľke 3.2.

Tabuľka 3.2 - Pilotný operačný plán

Zák		Popis
1. Voľba kritérií úspechu		Vývojár a účastníci testu definujú kritériá úspechu a dohodnú sa na nich
2. Výber používateľov a umiestnenie inštalácie		Formuje sa tím účastníkov pilotného testovania zo strany používateľov a vývojárov. Určuje sa umiestnenie nasadenia pilotného procesu.
3. Príprava používateľov a miest inštalácie		Prebieha školenie používateľov - účastníkov pokusu. Miesto inštalácie sa pripravuje.
4. Nasadenie vývojovej verzie		Je nainštalovaná experimentálna verzia, ktorá je súčasťou práce.
5. Podpora a sledovanie vývojovej verzie		Monitorovanie práce používateľov a systému, poskytovanie pomoci pri prevádzke, zhromažďovanie informácií o prevádzke systému
6. Spätná väzba od používateľov a vyhodnotenie výsledkov		Používatelia vyjadrujú svoj názor na fungovanie systému, poukazujú na nedostatky a chyby.
7. Zavedenie zmien a doplnkov	Chyby sú opravené, sú urobené zmeny v dizajne alebo procese. Používateľom sú poskytnuté opravené výsledky, aby mohli pracovať a vyhodnocovať.
8. Rozhodnutia o nasadení	Ak výsledky pilotného testovania uspokoja používateľov, rozhodne sa o nasadení systému.

3.2 Metodika nasadenia aplikácie

V tejto fáze vývojár (alebo tím) nasadí technológie a komponenty potrebné na riešenie, projekt prejde do fázy údržby a podpory a zákazník to nakoniec schváli. Po nasadení tím vyhodnotí projekt a vykoná prieskum medzi používateľmi s cieľom zistiť ich spokojnosť.

Ciele fázy nasadenia:

¾  prenos riešenia do priemyselného prostredia;

¾  potvrdenie zákazníka o dokončení projektu.

Nasadenie komponentov špecifických pre dané miesto pozostáva z niekoľkých etáp: príprava, inštalácia, školenie a formálne schválenie.

Výsledkom fázy nasadenia systému sú systémy údržby a podpory, úložisko dokumentov, kde sa nachádzajú všetky verzie dokumentov a kódu vyvinutých počas projektu.

Na nasadenie vyvíjaného systému bol vypracovaný akčný plán, ktorý je uvedený v tabuľke 3.1.

Tabuľka 3.1 - Plán nasadenia aplikácie

Zák	Popis činnosti
1. Zálohovanie	Údaje používateľa sú zálohované s jeho účasťou a súhlasom prenosom informácií na vymeniteľné médium (CD, DVD)
2. Inštalácia základných komponentov riešenia	Využívanie technológií, ktoré zabezpečujú fungovanie riešenia. V tomto prípade inštalácia súčasti Visual FoxPro
3. Inštalácia klientskej aplikácie	Prenos do počítača používateľa a inštalácia finálnej verzie vyvinutého IS a databázy
4. Školenie	Používatelia sú vyškolení na prácu so systémom, vývojár je presvedčený o správnosti a pochopení práce protokolu IP zo strany klientov
5. Prenos znalostnej bázy projektu klientovi	Celá projektová dokumentácia sa odovzdáva zákazníkovi
6. Ukončenie projektu	Je vypracovaná správa o ukončení projektu. Zákazník podpíše preberací list.

Pre normálne fungovanie AWP, operačný systém Microsoft WindowsXP.

4 Informačný projektový manažment

4.1 Výber životného cyklu vývoja

Jeden z základné pojmy metodológia návrhu IS je koncept životného cyklu jeho softvéru (softvér životného cyklu). Životný cyklus softvéru je nepretržitý proces, ktorý začína okamihom, keď sa rozhodne o jeho potrebe vytvoriť, a končí sa okamihom úplného vyradenia zo služby.

Hlavným regulačným dokumentom regulujúcim životný cyklus softvéru je medzinárodná norma ISO / IEC 12207 (ISO - Medzinárodná organizácia pre normalizáciu - Medzinárodná organizácia pre normalizáciu, IEC - Medzinárodná elektrotechnická komisia - Medzinárodná komisia pre elektrotechniku). Definuje štruktúru životného cyklu, ktorá obsahuje procesy, akcie a úlohy, ktoré je potrebné vykonať pri tvorbe softvéru.

ISO / IEC 12207 neponúka konkrétny model životného cyklu a metódy vývoja softvéru. Model životného cyklu možno chápať ako štruktúru, ktorá určuje postupnosť vykonávania a vzájomného vzťahu procesov, akcií a úloh vykonávaných počas životného cyklu. Model životného cyklu závisí od špecifík IS a špecifík podmienok, v ktorých sa vytvára a funguje.

Dnes existuje veľa modelov životného cyklu softvéru, ale najobľúbenejšie a najrozšírenejšie sú dva modely:

Špirálový model (pozri obrázok 4.1);

Iteratívny model.

Obrázok 4.1 - Špirálový model životného cyklu softvéru

Na vytvorenie informačného systému, t.j. „Automatizované pracovisko veľkoobchodnej základne zamestnancov skladu“, bolo vybrané iteratívne. Charakteristickým rysom iteračného modelu je, že ide o formálnu metódu, skladá sa z nezávislých fáz, ktoré sa vykonávajú postupne, a je predmetom častého preskúmania (obrázok 4.2). Iteračný prístup sa osvedčil pri budovaní IS, pre ktoré môžu byť na samom začiatku vývoja všetky požiadavky formulované presne a úplne dostatočne, aby mali vývojári slobodu implementovať ich čo najlepšie z technického hľadiska.

Výhody iteračného modelu:

model je dobre známy spotrebiteľom, ktorí nie sú softvérom, a koncovým používateľom.

Pohodlie a jednoduché použitie, pretože všetky práce sa vykonávajú po etapách (podľa fáz modelu);

Stabilita požiadaviek;

Model je pochopiteľný;

Štruktúrou modelu sa môže riadiť aj zle vyškolený personál (neskúsený používateľ);

Model rieši zložitosť usporiadaným spôsobom a funguje dobre pre projekty, ktoré sú primerane zrozumiteľné;

Tento model umožňuje vykonávanie prísnej kontroly projektového riadenia;

Uľahčuje prácu projektového manažéra pri plánovaní a zostavovaní vývojového tímu.

Obrázok 4.2 - Iteračný model životného cyklu softvéru

Fázy modelu:

Vo fáze analýzy sú určené funkcie, ktoré by mal systém vykonávať, sú identifikované tie najdôležitejšie, ktoré si vyžadujú predovšetkým rozpracovanie, popisujú informačné potreby;

Vo fáze návrhu sú procesy systému zvažované podrobnejšie. Funkčný model sa analyzuje a v prípade potreby sa opraví. Budujú sa prototypy systémov;

Systém sa vyvíja vo fáze implementácie;

V štádiu implementácie je hotový výrobok zavedený do existujúceho systému organizácie. Prebieha školenie používateľov;

Vo fáze údržby je softvérový produkt servisovaný (akékoľvek doplnenie alebo zmena kvôli funkčnejšej funkcii produktu).

Výber modelu životného cyklu vývoja softvéru je dôležitý krok. Preto pre projekt možno výber modelu životného cyklu vývoja softvéru vykonať počas použitia nasledujúcich procesov.

Analýza rozlišovacích kategórií projektu uvedená v tabuľkách.

Odpovedzte na otázky pre jednotlivé kategórie a zvýraznite slová „áno“ a „nie“.

Usporiadajte podľa dôležitosti kategórie alebo otázky týkajúce sa každej kategórie vo vzťahu k projektu, pre ktorý sa vyberá prijateľný model.

Vývojový tím ... Na základe možností výber personálu pre vývojový tím prebieha ešte pred okamihom, keď je zvolený model životného cyklu vývoja softvéru. Charakteristika takéhoto tímu (pozri prílohu G, tabuľku G.1) hrá dôležitú úlohu v procese výberu modelu životného cyklu, čo znamená, že tím môže poskytnúť významnú pomoc pri výbere modelu životného cyklu softvérového produktu, pretože je zodpovedný za úspešnú implementáciu vyvinutého modelu životného cyklu. ...

Tím používateľov ... V počiatočných fázach projektu môžete získať kompletný obraz o tíme používateľov (pozri prílohu A tabuľku I.1), ktorí budú pracovať s vyvinutým softvérom, a o jeho budúcich vzťahoch s vývojovým tímom počas celého projektu. Takýto pohľad pomáha pri výbere vhodného modelu, pretože niektoré modely vyžadujú zvýšenú účasť používateľov na vývoji a štúdiu projektu, pretože používateľ môže počas procesu vývoja mierne zmeniť požiadavky, vývojár musí tieto zmeny poznať a ako tieto zmeny v softvéri predstavovať.

4.2 Určenie účelu a rozsahu softvérového projektu

Vyvinutý softvérový produkt na účtovanie tovaru v sklade automatizuje proces prijímania, štruktúrovania a ukladania údajov o tovare v sklade, ako aj zjednodušuje proces vydávania správ.

Ciele softvérového projektu budú - vytvorenie a nasadenie systému na účtovanie tovaru. Tento systém je určený na interné použitie zamestnancami spoločnosti Cleonelly, väčšinou zamestnancami skladu spoločnosti.

Na určenie rozsahu softvérového produktu bude nižšie popísané, čo by malo alebo nemalo byť softvérovým projektom.

Softvérový projekt musí byť:

Na interné použitie v organizácii;

Projekt implementácie prístupu viacerých používateľov;

Projekt, ktorý má schopnosť zadávať, meniť a ukladať informácie o produkte spoločnosti;

Projekt, ktorý má schopnosť zadávať, meniť a ukladať informácie o používateľoch systému;

Projekt, ktorý má schopnosť vkladať, meniť a uchovávať informácie o zákazníkoch a dodávateľoch organizácie, ktorí sú predmetom transakcií, ktoré sa majú uzavrieť;

Projekt, ktorý uskutoční formovanie externého výkazníctva.

4.3 Tvorba štruktúry podrobného zoznamu prác

Ak chcete vytvoriť jedinečný produkt alebo službu (výsledok projektu), musíte vykonať určitú postupnosť práce. Úlohou projektového plánovania je presne odhadnúť načasovanie a náklady na tieto práce. Čím presnejšie je hodnotenie, tým vyššia je kvalita projektového plánu. Ak chcete poskytnúť presné hodnotenie, musíte dobre rozumieť rozsahu projektu, to znamená vedieť, aký druh práce je potrebné vykonať, aby sa dosiahol jeho výsledok. Až po vypracovaní zoznamu projektových prác sa odhaduje doba ich trvania a pridelia sa zdroje potrebné na ich realizáciu. A až potom je možné odhadnúť náklady a načasovanie každej úlohy a v dôsledku pridania celkové náklady a trvanie projektu. Preto je definovanie rozsahu práce prvým krokom pri plánovaní projektu. Vymedzenie rozsahu projektových prác sa začína definíciou etáp (alebo fáz) projektu. Napríklad v projekte na vytvorenie systému „Účtovanie tovaru na sklade“ možno zvýrazniť tieto fázy:

Vývoj softvérových požiadaviek;

Dizajn informačného systému;

Implementácia a certifikácia informačného systému;

Implementácia systému.

Po určení zloženia fáz a ich výsledkov je potrebné určiť vzájomné poradie týchto fáz a termíny ich uskutočnenia. Potom musíte určiť, z čoho pozostávajú fázy, v akom poradí sa tieto práce vykonávajú a aké termíny musíte dodržať, keď sú dokončené.

Podrobný pracovný zoznam (obrázok 4.3) bol navrhnutý pomocou softvérového produktu, ako je MS Project 2003.

Obrázok 4.3 - Zoznam prác krok za krokom

4.4 Odhadovanie trvania a nákladov na vývoj softvéru

Odhad trvania. Stanovuje sa po zostavení podrobného zoznamu prác (obrázok 4.3, bod 4.3). Toto odhadované trvanie možno zistiť pomocou Ganttovho diagramu (príloha K).

Schémy sú grafickým prostriedkom na zobrazenie informácií obsiahnutých v súbore projektu. Z grafov môžete získať vizuálnu predstavu o postupnosti úloh, ich relatívnom trvaní a trvaní projektu ako celku.

Ganttov diagram je jedným z najpopulárnejších spôsobov grafického znázornenia plánu projektu a používa sa v mnohých programoch riadenia projektu.

V MS Project je Ganttov diagram hlavným vizualizačným nástrojom pre plán projektu. Tento graf je grafom s horizontálnou časovou osou a vertikálnym zoznamom úloh. V takom prípade je dĺžka segmentov označujúcich úlohy úmerná dĺžke trvania úloh.

Na Ganttovom grafe je možné vedľa pruhov zobraziť ďalšie informácie (vedľa úloh sa zobrazia názvy zdrojov, ktoré sú do nich zapojené, a ich načítanie po dokončení úlohy).

Odhad nákladov

Projekt pozostáva z: úlohy , teda činnosti zamerané na dosiahnutie určitého výsledku. Aby bolo možné úlohu dokončiť, zdrojov .

Dôležitou vlastnosťou zdrojov sú náklady (náklady) na ich použitie v projekte. V programe MS Project existujú dva typy nákladov na zdroje: časová miera a cena za použitie.

Časová sadzba (Rate) je vyjadrená v nákladoch na použitie zdroja za jednotku času, napríklad 100 rubľov za hodinu alebo 1 000 rubľov za deň. V takom prípade bude cenou účasti zdroja na projekte čas, počas ktorého pracuje v projekte, vynásobený hodinovou sadzbou.

V tomto prípade bola použitá časovo závislá sadzba (obrázok 4.4). Celkové náklady na použitie zdrojov sú uvedené na obrázku 4.5.

Obrázok 4.4 - Časová miera využívania zdrojov

Na tomto obrázku vidíte, že vývojár systému dostane pri realizácii projektu 50 rubľov za hodinu; obchodný analytik dostane 45 rubľov za hodinu, tester 38 rubľov za hodinu. Sadzby za prácu nadčas nie sú zahrnuté.

Obrázok 4.5 - Celkové náklady na využitie zdrojov projektu

4.5 Pridelenie zdrojov projektu

Fragment rozdelenia zdrojov pre systém „Inventúrne účtovníctvo“ je možné vidieť na obrázku 4.6

Obrázok 4.6 - Fragment rozdelenia zdrojov projektu

Pre každú prácu vykonanú v projekte je priradený zdroj, ktorý bude vykonávať táto práca... Obrázok zobrazuje celkové množstvo práce pre každý zdroj a konkrétny počet hodín strávených v konkrétny deň.

4.6 Posúdenie ekonomickej efektívnosti projektu

Výpočet ekonomickej efektívnosti projektu je dôležitým krokom. Tu sa bude počítať ekonomická efektívnosť projektu. Tento výpočet ukáže, aký výnosný je projekt alebo úplne nerentabilný projekt. Pri výpočte ekonomickej efektívnosti projektu bude potrebné vypočítať dobu návratnosti projektu. Doba návratnosti ukáže obdobie, za ktoré sa projekt vyplatí.

Vstupné Data.

Dodatočný zisk z realizácie projektu (DP) \u003d 38 000 rubľov. Odborníci spoločnosti predpovedali ďalší zisk.

Počiatočná investícia (IC) \u003d 39396,47 rubľov. Počiatočné investície zodpovedajú celkovým nákladom na použitie zdrojov projektu (obrázok 4.5, bod 4.6).

Diskontná sadzba (i) \u003d 12%.

Obdobie, na ktoré je projekt určený (n) \u003d 2 roky.

Dodatočný zisk z realizácie projektu (DP) \u003d 38 000 rubľov.

Ročné náklady na realizáciu projektu (Z 1) \u003d 15 000 rubľov.

Ročné náklady na realizáciu projektu (Z 2) \u003d 10 000 rubľov.

Ročné hotovostné príjmy (R 1) \u003d 23 000 rubľov.

Ročné hotovostné príjmy (R 2) \u003d 28 000 rubľov.

Pri hodnotení investičných projektov sa používa metóda výpočtu čistej súčasnej hodnoty, ktorá umožňuje diskontovanie peňažných tokov: všetky výnosy a náklady sa uvedú do jedného okamihu.

Centrálnym ukazovateľom v uvažovanej metóde je NPV (čistá súčasná hodnota) - súčasná hodnota peňažných tokov. Toto je zovšeobecnený konečný výsledok investičnej činnosti v absolútnom vyjadrení.

Dôležitým bodom je výber diskontnej sadzby, ktorá by mala odrážať očakávanú priemernú úrokovú sadzbu úverov na finančnom trhu.

Čistá súčasná hodnota (NPV) sa počíta pomocou vzorca 4.2

(4.2)

R k - ročné hotovostné príjmy za n rokov.

k - počet rokov, dokedy je projekt koncipovaný.

IC - počiatočná investícia.

i je diskontná sadzba.

Podľa výpočtov tohto vzorca NPV \u003d 3 460,67 RUB

NPV je absolútny nárast, pretože odhaduje, do akej miery sa súčasný príjem prekrýva so súčasnými nákladmi. Pretože NPV\u003e 0, projekt by mal byť prijatý.

Návratnosť investícií (ROI) sa počíta podľa vzorca 4.3

(4.3)

Vypočítané (ROI) \u003d 108,78%

Tabuľka 4.1  Pomocná tabuľka pre výpočet doby návratnosti projektu

= 1,84

Doba návratnosti n ok \u003d 1,84 roka (1 rok a 11 mesiacov)

Pretože ROI \u003d\u003e 100% (konkrétne \u003d 108,78%), projekt sa považuje za ziskový.

(4.4)

Index ziskovosti je teda (PI) \u003d 1,2