Úvod

Posudzovaný titul je napísaný na základe Doneck Donetk Manufaktúra pre Cleonelly Store.

Jedna z popredných aktivít OAO Doneck Manufaktúru vyrába šijacie výrobky v širokom rozsahu, väčšinou županobes, listy a uteráky. Okrem toho spoločnosť vyrába maľovanú bavlnenú priadzu na tkanie a pletenú výrobu.

Rozvoj automatizovaných informačných technológií je súbežne s vznikom nových typov technických prostriedkov spracovania a prenosu informácií, zlepšenie organizačných foriem používania počítača, sýtosť infraštruktúry s novými komunikačnými prostriedkami. Rozvoj trhových vzťahov viedol k vzniku nových typov podnikania a predovšetkým na vytvorenie firiem zapojených do informačného podnikania, rozvoj informačných technológií, ich zlepšenie, šírenie komponentov automatizovaných informačných technológií, najmä softvéru Produkty, ktoré automatizujú informačné a výpočtové procesy. Zahŕňajú aj výpočtové vybavenie, komunikáciu, kancelárske vybavenie a špecifické druhy služieb - Informačné, technické a konzultačné služby, školenia atď. To prispelo k rýchlemu šíreniu a efektívnemu využívaniu informačných technológií v manažérskych a priemyselných procesoch, prakticky rozšírených aplikáciách a veľkého množstva.

Podniky zaoberajúce sa dizajnom a vývojom zariadení na rôzne účely, v súčasnosti používajú rôzne prostriedky automatizovaného dizajnu - CAPR (CAD) a monitorovacie výrobné procesy - ASUTP (SCADA / DCS). Avšak, pre vlastné rozvojové zariadenia, je potrebné vytvoriť si vlastné prostriedky na kontrolu ich výkonnosti a analýzy kvality výrobkov.

Technologický proces berúc do úvahy výrobky v sklade v čistom obchode zahŕňa štádium dodržiavania predaného tovaru.

Účelom súčasného promócie projektu je implementácia automatizovaného pracoviska (AWA), ktorá umožňuje účtovanie výrobku v skladovom skladu.

Na dosiahnutie vyššie uvedeného cieľa sa musia vyriešiť tieto úlohy: \\ t

¾ vykonať analýzu obchodných procesov obchodu;

¾ Preskúmajte informačné toky vznikajúce vo fáze vyvinutého produktu vyvinutého výrobku;

¾ Vytvorte koncepčný a logický dátový model;

¾ Rozvíjať softvér na podporu produktov

¾ Vykonajte hodnotenie ekonomickej efektívnosti informačného systému.

1 Vývoj požiadaviek na softvér

1.1 Analýza existujúcich riešení

V súčasnosti existuje široká škála spoločností, ktoré kombinujú priamy vývoj produktov, takže rozvoj systémov na riadenie týchto produktov. Takéto systémy sú vyvinuté ako také značne známe spoločnosti ako 1: s podnikom a "hviezdou". V takýchto systémoch sa monitorujú monitorovacie materiály a spracovanie získaných informácií.

"1c: Enterprise" je systém aplikovaných riešení postavených podľa jednotných princípov a na jednej technologickej platforme. Hlava si môže vybrať riešenie, ktoré spĺňa aktuálne potreby podniku a bude sa naďalej rozvíjať ako podnik alebo rozšírenie úlohy automatizácie.

Program "1C: Enterprise" program je určený na riešenie širokej škály účtovných a riadenia automatizácie úloh, ktorým čelí dynamicky rozvíjať moderné podniky. Riešenie aktuálnych účtovných a riadiacich úloh Zloženie programu "1c: Enterprise" je zameraná na súčasné potreby podnikov. Spoločnosť "1C" vytvára obehové softvérové \u200b\u200briešenia určené na automatizáciu typických účtovných a riadiacich úloh v podnikoch. Charakteristickým znakom cirkulačných riešení spoločnosti "1c" je starostlivé štúdium zloženia funkčnosti zahrnutých v typických riešeniach. Spoločnosť "1C" analyzuje skúsenosti používateľov používajúcich program "1c: Enterprise" a sleduje zmenu svojich potrieb.

Hlavné výhody môjho systému, veľkoobchodná základňa možno pripísať relatívne nízkym nákladom na zavedenie tohto systému, ako aj rad výhod:

¾ Spoľahlivosť vytvorených aplikácií. Softvérový balík (PC) musí byť stabilný nielen k chybám používateľa, ale aj zlyhania v systéme komunikácie.

¾ Jednoduché použitie rozhrania;

¾ Vysoká úroveň zabezpečenia systému, ktorá znamená nielen kontrola dostupnosti určitých systémových zdrojov a bezpečnosť informácií vo všetkých fázach prevádzky, ale aj sledovanie akcií s vysokým stupňom spoľahlivosti.

1.2 Analýza predmetu oblasti

Zvláštnosťou analýzy oblasti predmetu je, že vám umožní vidieť celý súbor operácií organizácie.

Na analýzu a reorganizáciu obchodných procesov je prípad určený – Nástroj na najvyššej úrovni Všetky modeler procesu Fusion (BPWIN), podpora metodík IDEF0 (funkčný model), DFD (Dátový diagram údajov) a IDEF3 (pracovný tokový diagram). BPWIN je výkonný softvérový produkt na vytvorenie modelov, ktoré vám umožnia analyzovať, dokumentu a plánovať zmeny v komplexných obchodných procesoch. BPWIN ponúka nástroj na zhromažďovanie všetkých potrebných informácií o práci podniku a grafický obraz týchto informácií vo forme holistického a konzistentného modelu.

Z hľadiska funkčnosti systému. Ako súčasť metodiky IDEF0 (definícia integrácie pre modelovanie funkcií), obchodný proces je prezentovaný vo forme súboru prvkov-diel, ktoré navzájom spolupracujú, a tiež ukazuje informácie, ľudské a výrobné zdroje spotrebované každou prácou. Funkčný model je navrhnutý tak, aby opísal existujúce obchodné procesy v podniku (tzv. As-is model) a ideálnu pozíciu vecí – Čo potrebujete na to, aby ste sa mohli usilovať o (model to-be). Metodika IDEF0 predpisuje stavbu hierarchického diagramu systému, t.j. Jednorazové popisy systémových fragmentov. Po prvé, systém opisuje systém ako celok a jeho interakciu s vonkajším svetom (kontextový diagram), po ktorom sa koná funkčný rozklad – Systém je rozdelený na subsystémy a každý systém je opísaný samostatne (diagramy rozkladu). Potom je každý subsystém rozdelený na menšie a tak ďalej, aby sa dosiahlo požadované detaily stupňa.

Ak je v procese modelovania je potrebné osvetliť konkrétne strany podnikovej technológie, BPWIN vám umožňuje prepínať na akúkoľvek pobočku modelu modelu DFD alebo IDEF3. DFD diagramy (diagram toku dát) môžu pridať niečo, čo sa už odráža v modeli IDEF3, pretože opisujú dátové toky, čo vám umožní vysledovať, ako sa informácie vymieňajú medzi obchodnými funkciami vo vnútri systému. Súčasne sa DFD diagram nezohľadňuje interakciu medzi obchodnými funkciami.

Z hľadiska sledovaného postupu práce. A ešte presnejší obraz možno získať pridaním modelu pomocou IDEF3 diagrams. Táto metóda upozorňuje na poradie udalostí. IDEF3 zahŕňa logické prvky, čo vám umožňuje simulovať a analyzovať alternatívne scenáre vývoja obchodných procesov.

Ak chcete zvážiť obchodné procesy spustené v obchode Store, je potrebné použiť iba dve metodiky IDEF0 a DFD. Proces modelovania akéhokoľvek systému v IDEF0 začína definíciou kontextu, t.j. Najviac abstraktnou úrovňou opisu systému alebo obchodných procesov všeobecne.

IDEF0 model . Preskúmať obchodné procesy "Tvorba objednávky dodávateľa", "Získanie tovaru", "dovolenka tovaru", zvážte grafy, ktoré sú prezentované vo forme diagramu IDEF0. IDEF0 Systém je reprezentovaný ako súbor interakcií alebo funkcií.

Metodika IDEF0 je založená na štyroch základných pojmoch.

Prvým z nich je koncept funkčný blok (Kolónka aktivity) . Funkčný blok je graficky zobrazený ako obdĺžnik a personifikuje určitú špecifickú funkciu v rámci posudzovaného systému.

Každá zo štyroch strán funkčného bloku má svoju vlastnú určitú hodnotu (úlohu), zatiaľ čo:

Horná strana má hodnotu "Control";

Ľavá strana je "vstup" (vstup);

Pravá strana má "výstup" (výstup);

Dolná strana má hodnotu "mechanizmus".

Druhá metodika "Whale" IDEF0 je koncepcia rozhrania ARC (šípka). Grafické zobrazenie rozhrania ARC je jednosmerná šípka. Každé rozhranie ARC musí mať svoj názov (šípka štítok). Používanie rozhrania oblúkov, rôzne objekty displej, do jedného stupňa alebo iného, \u200b\u200bvymedzujúce procesy vyskytujúce sa v systéme. Zároveň šípky, v závislosti na tom, ktoré hrana obdĺžnika práce, ktoré vstupujú, alebo z ktorých hrany vydávajú, sú rozdelené do:

Vstupné šípky (zahrnuté v ľavej strane funkčného bloku) - dáta alebo objekty premenlivé počas prevádzky;

Riadna šípka (zahrnuté v hornej aspekte funkčného bloku) - zobrazujú pravidlá a obmedzenia, vďaka ktorej sa vykonáva práca;

Výstupné šípky (vyjdú z pravej strany funkčného bloku) - zobrazujú údaje alebo objekty, ktoré sa objavujú v dôsledku práce;

Šípka mechanizmu (súčasťou spodnej strany funkčného bloku) - zobrazuje zdroje (napríklad zariadenia, ľudské zdroje).

Tretia základná koncepcia IDEF0 je rozklad (rozklad). Princíp rozkladu sa používa pri rozdeľovaní komplexného procesu na zložky jeho funkcie.

Rozklad vám umožňuje postupne a štruktúrovaný, aby reprezentoval systémový model vo forme hierarchickej štruktúry jednotlivých diagramov, čo je menej preťažené a ľahko absorbované.

Posledné koncepty IDEF0 je glosár (slovník). Pre každý z prvkov IDEF0: diagramy, funkčné bloky, rozhrania ARCS existujúci štandard zahŕňa vytváranie a udržiavanie množiny vhodných definícií, kľúčových slov, naratívnych prezentácií atď., Ktoré charakterizujú objekt zobrazený týmto prvkom. Táto sada sa nazýva glosár a je popisom podstaty tejto položky.

Zvážte graf podnikových procesov prúdiacich v obchode obchodu DMM, Cleonelly:

V prípade všeobecnej viditeľnosti systému je potrebné vybudovať kontext "Činnosti podnikového skladu" (pozri obrázok 1.1).

Obrázok 1.1 - Diagram "Skladové aktivity"

Po inštalácii kontextu sa vykonáva rozklad, t.j. Budovanie nasledujúcich grafov v hierarchii.

Každý nasledujúci diagram je podrobnejší popis jednej z prác na vyššej tabuľke. Príklad rozkladu kontextovej práce je znázornený na obrázku 1.2. Celý systém je teda rozdelený na podsystémy na požadovanú úroveň detailov, tento systém je rozdelený na tri úrovne.

Obrázok 1.2 - Graf rozkladu prvého stupňa

Obrázok 1.3 - Diagram "Design produktu"

Obrázok 1.4 - Diagram "dovolenka tovaru"

Obrázok 1.5 - Diagram "Calling Tovar"

DFD. Základom tejto metodiky je výstavba modelu analyzovaného IC - predpokladaného alebo skutočne existujúceho. V súlade s metodikou je systémový model definovaný ako hierarchia diagramov dátového toku (DFD), popisuje asynchrónny proces konverzie informácií z jeho vstupu do systému pred vydaním používateľa. DFD diagramy sú zvyčajne postavené pre vizuálny obraz aktuálnej práce systému správy dokumentov organizácie. Najčastejšie sa diagram DFD používa ako doplnok k modelu obchodných procesov vyrobených v IDEF0.

Hlavnými komponentmi diagramov dátového toku sú:

Externé entity (graficky zobrazené štvorcovým) - uveďte materiálový predmet alebo jednotlivec, ktorý je zdrojom alebo prijímačom informácií. Napríklad: zákazníci, zamestnanci, dodávatelia, zákazníci, sklad;

Systémy / Subsystémy (graficky vyzerá ako obdĺžnik so zaoblenými rohmi) - práca indikuje funkcie alebo procesy, ktoré spracúvajú a zmenia informácie;

Dátové disky - sú abstraktné zariadenie na ukladanie informácií, ktoré môžu byť umiestnené kedykoľvek v pohone a po určitom čase extrahovať, a spôsoby miestnosti a extrakcie môžu byť akékoľvek. Zariadenie na ukladanie údajov vo všeobecnosti je prototyp budúcej databázy a opis údajov uložených v ňom musí byť spojený s informačným modelom;

Dátové toky - Určuje informácie prenášané po pripojení zo zdroja k prijímaču. Dátový prúd na diagrame je znázornený čiarou šípky konca, ktorá zobrazuje smer prúdenia.

Zvážte schému dátového toku (DFD) "Dovolenka tovaru" Obrázok 1.6. Tento diagram zobrazuje pohyb dokumentov pri vstupe do organizácie "Žiadosti o tovar".

Obrázok 1.6 - DFD Diagram "Dovolenka tovaru"

Zvážte nasledujúci diagram dátových tokov "dizajn produktu" (pozri obrázok 1.7). Tu je zobrazený proces vykonávania práce a pohybu dokumentov na "vydávaní tovaru".

Obrázok 1.7 - DFD DIAGRAM "Registrácia produktu"

V diagramoch dátového toku sú všetky použité znaky zložené do spoločného obrazu, čo dáva jasnú predstavu o tom, ktoré údaje sa používajú, a aké funkcie vykonáva systém správy dokumentov. Často sa zistí, že existujúce informačné toky, dôležité pre aktivity spoločnosti, sú realizované nespoľahlivé a je potrebné reorganizovať. *******

Organizačná štruktúra podniku, ktorá sa zaoberá predajom produktov Terryho, sa považuje za príklad spoločnosti "Doneck Maines M" Cleonelly Store:

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

1. Ide o kontrolu nad dodaným tovarom a skladom skladom.

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

3. Obsahuje aj informácie a operácie informácií pre produkt.

4. Obsahuje protokol správ uvoľneného tovaru.

5. Osvedčenie o tovare

6. Automatizácia skladových funkcií (príchod, spotreba, odpísanie, rezervácia produktov)

7. Registrácia a ukladanie účtov zakúpených a predaných tovarov a služieb, ako aj výpis pre účty preddavky, s oneskorením platby a dodania tovaru

8. Vytvorenie režijných a účtovníctva vydaného tovaru

9. Vedenie zásob skladov s vytvorením vedľajšej vody, akt nedostatku nedostatku a prebytku

10. Vytvorenie súborov tovaru

Ako je uvedené v hlavnej oblasti činnosti tohto podniku, je predaj bavlnených produktov. Dizajnový proces zahŕňa mnoho krokov starostlivo vypracovaných riadiacimi štruktúrami projektových podnikov počas celého života tohto podniku. Tento proces sa nedá zmeniť zároveň, pretože ide o mnoho divízií samotného podniku, externých subdodávateľov a zákazníkov projektovej spoločnosti. Podniky s opatrnosťou sa preto týkajú implementácie informačných systémov týkajúcich sa procesov riadenia dizajnu a rozvoja. Ruské podniky spravidla používajú svoj vlastný vývoj v tejto oblasti.

1.3 Zber požiadaviek

Pri navrhovaní informačného systému (IP) "Arts veľkoobchodný obchod", bolo potrebné zbierať požiadavky, ktoré by pomohli vytvoriť rozhranie takým spôsobom, že koncový užívateľ (zamestnanec obchodu) bol vhodný na prácu s rozvinutou IP.

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

Na realizáciu procesu účtovných a monitorovacích materiálov je potrebné, aby informačný systém mohol vykonávať 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 sa vykonáva v operačnom systéme Windows 2000 / NT / XP.

Existujú štyri hlavné etapy procesu vývoja požiadaviek (obrázok 1.8):

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

Tvorba a analýza požiadaviek;

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

Certifikácia požiadaviek.

Požiadavky na zhromažďovanie je dôležitým krokom v dizajne dizajnu, pretože je tu, že všetky požiadavky zákazníka musia byť správne a sú správne formulované.

1.4 Špecifikácia požiadaviek

Definícia správnych požiadaviek je pravdepodobne najviac zodpovednou fázou softvérového projektu. Je veľmi dôležité, aby bol formát projektu v súlade s požiadavkami na softvér zozbieraný vývojárskym tímom, inak tieto požiadavky nebude môcť byť podporované a prezentované v softvérovom produkte. Požiadavky na softvérové \u200b\u200bpožiadavky Softvérové \u200b\u200bpožiadavky Špecifikácie (SRS) je kľúčom k životnému cyklu rozvoja softvéru. Toto nie je len derivátový dokument, v ktorom špecifikácie programového projektu, ale aj hlavný dokument uplatňovaný na vykonanie certifikačných a prijateľných testov. Certifikácia je posúdením kvality práce projektových manažérov. Určuje stupeň súladu so stanovenými požiadavkami softvérového produktu. Špecifikácia SRS pôsobí ako druh mechanizmu na upevnenie systémových požiadaviek, ktoré sa používajú ako kritériá pre certifikáciu.

Na základe SRS sa dosiahne súhlas medzi zákazníkmi a výrobcami softvéru. Špecifikácia SRS plne popisuje funkcie, ktoré bol vyvinutý softvérový produkt. To umožňuje potenciálnym používateľom určiť stupeň dodržiavania výrobkov s ich potrebami, ako aj ciele modifikácie produktu, aby bolo čo najviac v riešení ich úloh.

Vývoj nákladov na dočasné rozvoja. Príprava špecifikácií SRS zahŕňali rôzne skupiny v organizácii zákazníka. Opatrne preskúmajú všetky požiadavky ešte predtým, ako začína priamy vývoj projektu. To znižuje pravdepodobnosť následného opätovného vývoja projektu, kódovania a testovania.

S dôkladnou štúdiou o požiadavkách uvedených v špecifikácii SRS je možné zistiť nadkladanie, nedorozumenia a rozpory v počiatočných štádiách vývoja cyklu, keď sú problémy oveľa jednoduchšie ako v neskorších štádiách.

Špecifikácia SRS sa stáva základom pre odhad nákladov a prípravy pracovného harmonogramu. Popis produktu je reálnym základom pre odhad nákladov projektu. V prostredí, kde je koncepcia formálneho návrhu, SRS sa používa na schválenie posúdenia ponuky alebo ceny.

S pomocou navrhovaných špecifikácií SRS na úrovni organizácie, organizácia môže vyvinúť oveľa produktívnejšie plány certifikácie a inšpekcií. Súčasťou zmluvy o vývoji SRS poskytuje referenčný bod na posúdenie súladu so špecifikáciami.

Vďaka špecifikácii SRS je programový produkt uľahčený novými užívateľmi, ako aj jeho inštaláciu na iných počítačoch. Preto je pre zákazníkov jednoduchšie preniesť softvérový produkt na iné jednotky organizácie a pre vývojárov, aby prenášali ostatným zákazníkom.

Špecifikácia SRS slúži ako základ pre modernizáciu. Tento dokument sa zaoberá samotným výrobkom, a nie proces vývoja projektu, preto je možné vyplniť vyplnený výrobok na svojom základe.

Po ukončení procesu definovania a špecifikácií je potrebné vykonať certifikáciu požiadaviek.

Špecifikácia požiadaviek na softvérový projekt musí byť prezentovaný v dodatku A.

1.5 Certifikácia požiadaviek

Certifikácia by mala preukázať, že požiadavky skutočne definujú systém, ktorý chce zákazník mať. Kontrola požiadaviek je dôležitá, pretože chyba v špecifikácii požiadaviek môže viesť k zmenám systému a vysoké náklady, ak sú zistené počas systému rozvoja systému alebo po jeho uvedenie do prevádzky.

Počas procesu certifikácie sa musia vykonať rôzne typy kontrol dokumentov:

1. Skontrolujte správnosť požiadaviek.

2. Skontrolujte konzistenciu.

3. Skontrolujte úplnosť.

4. Skontrolujte uskutočniteľnosť.

Existuje niekoľko certifikačných metód podľa požiadaviek, ktoré môžu byť použité spolu alebo každý samostatne:

1. Preskúmanie požiadaviek.

2. Prototypovanie.

3. Generovanie testovacích scenárov.

4. Automatizovaná analýza konzistencie.

Najviac vizuálne pre zákaznícky systém je prototypovanie.

Pred začatím vytvárania prototypov môžete vytvoriť diagram potrieb používateľského rozhrania. Tento diagram sa používa na preskúmanie vzťahu medzi hlavnými prvkami používateľského rozhrania.

Ďalším krokom certifikácie požiadaviek je priame vytváranie prototypov.

Prototyp softvéru je čiastočná alebo možná realizácia navrhovaného nového produktu. Prototypy vám umožňujú vyriešiť tri hlavné úlohy: objasnenie a ukončenie formulácie požiadaviek, výskumu alternatívnych riešení a vytvorenie konečného výrobku.

Prototyp hlavného menu tohto modulu je znázornený na obrázku 1.9.

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

Podstatou štrukturálneho prístupu k rozvoju IP je jeho rozklad (oddiel) na automatizovaných funkciách: Systém je rozdelený na funkčné subsystémy, ktoré sú zase rozdelené na subfunkcie rozdelené na úlohy a tak ďalej. Proces rozdelenia pokračuje v špecifických postupoch. Pi Tento automatizovaný systém si zachováva holistickú reprezentáciu, v ktorej sú všetky komponenty prepojené.

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

Princíp "rozdeliť a dobyť" je princíp riešenia komplexných problémov rozdelením mnohých menších nezávislých úloh, ľahko sa porozumieť a rieši;

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

V štrukturálnej analýze existujú najmä dve skupiny finančných prostriedkov ilustrujúcich funkcie vykonávané systémom a vzťahom medzi údajmi. Každá skupina finančných prostriedkov zodpovedá určitým typom modelov (diagramy), najbežnejšie, medzi ktoré sú: \\ t

SADT (štruktúrna analýza a konštrukčná technika) modely a zodpovedajúce funkčné diagramy;

DFD (diagramy toku dát) Diagramy toku údajov;

ERD (Diagramy entity-vzťahové diagramy) Chart "Essence-Communication".

V štádiu dizajnu modelu IC model rozširuje, regeneruje a doplnené diagramami, ktoré odrážajú softvérovú štruktúru: architektúra softvéru, konštrukčné schémy programov a na obrazovke diagramy.

Uvedené modely v agregáte poskytujú úplný opis IC bez ohľadu na to, či existuje alebo novo vyvinuté. Zloženie grafov v každom konkrétnom prípade závisí od požadovanej úplnosti opisu systému.

2 Projektový informačný systém

2.1 Architektonický dizajn

Pri vytváraní akéhokoľvek komplexného informačného systému je kritickým aspektom svojej architektúry, kde je koncepčná vízia štruktúry budúcich funkčných procesov a technológií na úrovni systému a vo vzťahoch. Zvyčajne sú komplexné informačné systémy organizácií navrhnuté ako zloženie komponentov, ktoré interagujú na vysokej úrovni, čo môže byť samotné systémy. Architektúra informačného systému organizácie uľahčuje pochopenie systému tým, že definuje jeho funkčnosť a štruktúru spôsobom, ktorý odhaľuje riešenia dizajnu a umožňuje prehliadač klásť otázky týkajúce sa spokojnosti požiadaviek na návrh, distribúciu funkčnosti a implementácie komponentov.

Architektúra informačného systému organizácie je model, ako budú informačné technológie podporovať hlavné ciele a stratégia pre rozvoj automatizovaného objektu. To vám umožní kriticky myslieť a jasne vyjadriť pohľad na to, ako by mali byť integrované súbory informačných systémov štruktúrované na realizáciu týchto cieľov. Architektúra informačného systému opisuje, ako informačné systémy, aplikácie a ľudia pracujú v celej organizácii jednotným jednotným spôsobom.

Architektúra informačného systému teda obsahuje všeobecne akceptovaný súbor komponentov, ktoré poskytujú "stavebné bloky" informačného systému. Tieto "stavebné bloky" a ich charakteristiky sú definované na príslušnej úrovni podrobností, aby spĺňali potreby vykonávané plánovacími riešeniami.

Pri navrhovaní moderných informačných systémov organizácií, ich architektúra by mala byť vyvinutá s prihliadnutím na mnohé zainteresované strany, musí byť pochopiteľné pre užívateľov, aby sa vývojári urobili plán a grafy systému, umožnili vám určiť kľúčové rozhrania, funkcie a technológie A tiež vám umožní vyhodnotiť plán a rozpočet realizácie projektu. Zároveň architekti moderných informačných systémov si vyžadujú zodpovednosť za vytvorenie uspokojivého a implementačného systému systému v najskoršom štádiu jej vývoja, podpory integrity tohto konceptu v rámci rozvoja a určenia výsledného výsledného systému na použitie klient. Na druhej strane rozvoj architektúry informačného systému je proces opisovania architektúr informačných systémov v dostatočnom detaile, aby boli užitočné pre rozvoj informačných systémov.

Štúdium zahraničných skúseností ukazuje, že vo vyspelých krajinách pri vypracúvaní architektúry informačného systému si vyžaduje dodržiavanie týchto podmienok: \\ t

¾ Zamerajte sa na poslanie organizácie;

¾ Zamerajte sa na požiadavky;

¾ Zamerajte sa na rozvoj;

¾ schopnosť prispôsobiť sa;

¾ Potreba flexibility.

Dodržiavanie všetkých týchto podmienok vám umožňuje rozvíjať architektúru informačného systému organizácie je dokonalejšia a efektívna.

V súčasnosti implementované hlavné architektúry softvéru sú:

¾ File-Server;

¾ klient-server;

¾ Multi-Level.

Súborový server. . Táto architektúra centralizovaných databáz s prístupom k sieti zahŕňa pridelenie jedného zo sieťových počítačov ako dedikovaný server, na ktorom budú uložené centrálne databázové súbory. V súlade s užívateľskými požiadavkami sa súbory zo súboru servera prenášajú do užívateľských pracovných staníc, kde sa vykonáva hlavná časť spracovania údajov. Centrálny server vykonáva hlavne úlohu archívu súboru, bez toho, aby sa zúčastnilo spracovania samotných údajov. Po dokončení používateľov, používatelia kopírujte súbory s spracovanými údajmi späť na server, odkiaľ môžu mať a spracovávať iných používateľov. Takáto organizácia údajov má rad nevýhod, napríklad pri súčasnom zaobchádzaní s súborom užívateľov na jeden a tie isté údaje, výkon práce má ostro, pretože je potrebné čakať, kým sa používateľ, ktorý bude pracovať s údajmi práca. V opačnom prípade je možné posilniť opravy vykonané jedným používateľom, zmeny 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 vykonať hlavnú časť spracovania údajov. Používatelia sa vzťahujú na centrálny server pomocou špeciálneho jazyka štruktúrovaných dotazov (SQL, štruktúrovaný jazyk dotazovania), ktorý popisuje zoznam úloh vykonávaných serverom. Používateľské požiadavky sú akceptované serverom a vytvárajú procesy spracovania údajov. V reakcii na odpoveď prijíma už spracovaný súbor údajov. Nie je prenos údajov medzi klientom a serverom, ako je to technológia súborov a servera, ale iba údaje, ktoré je klient potrebný. Užívateľská požiadavka v dĺžke len niekoľkých riadkov je schopná generovať proces spracovania údajov ovplyvňujúcim viaceré tabuľky a milióny riadkov. V reakcii na odpoveď môže získať len niekoľko čísel. Technológia klient-server vám umožní vyhnúť sa prenosu cez sieť obrovských množstiev informácií posunutím všetkých spracovaní údajov na centrálnom serveri. Okrem toho, príslušný prístup vám umožňuje vyhnúť sa konfliktu zmien v rovnakých údajoch mnohými používateľmi, ktorí sú charakteristické pre technológiu súborov. Technológia Client-Server implementuje konzistentnú zmenu údajov vo viacerých klientoch, ktoré poskytujú automatické dodržiavanie integrity údajov. Tieto a niektoré ďalšie výhody robili technológiu klient-server veľmi populárna. Nevýhody tejto technológie zahŕňajú vysoké požiadavky na výkon centrálneho servera. Čím viac zákazníkov nájdete na serveri a tým viac, čím viac spracovávania údajov, čím silnejší by mal byť centrálny server.

Na základe týchto odôvodnení pri navrhovaní architektúry AWP ako základu bola prijatá technológia klient-server. Tabuľky umiestnenia odrážajú fyzikálne vzťahy medzi softvérovými a hardvérovými komponentmi systému).

2.2 Navrhovanie rozhrania informačného systému

Pod užívateľským rozhraním sa často rozumie len vzhľad programu. V skutočnosti však užívateľ vníma celý systém ako celok, čo znamená, že jeho porozumenie je príliš úzke. V skutočnosti, užívateľské rozhranie zahŕňa všetky aspekty dizajnu, ktoré ovplyvňujú interakciu a systém používateľa. Toto nie je len obrazovka, ktorú používateľ vidí. Užívateľské rozhranie sa skladá z rôznych komponentov, ako napríklad:

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

Prvky riadenia systému;

navigácia medzi systémovými blokmi;

Vizuálny dizajn programov.

Zdôrazňujeme niektoré z najvýznamnejších výhod dobrého používateľského rozhrania z hľadiska podnikania:

Zníženie počtu chýb používateľa;

Zníženie nákladov na podporu systému;

zníženie straty produktivity pracovníkov pri vykonávaní systému a rýchlejšie vymáhanie stratenej produktivity;

zlepšenie morálneho stavu zamestnancov;

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

Prístupnosť systémovej funkcie pre maximálny počet používateľov.

AWP veľkoobchodná základňa je vyvinutá ako aplikácia pomocou technológie klient-server.

2.2.1 Program riadenia používateľského rozhrania

Hlavný modul "Arts veľkoobchodná základňa" je luck.exe modul, ktorý zabezpečuje implementáciu hlavnej funkčnosti schémy možností použitia zobrazeného na obrázku 1.9 oddielu 1.4.

Pri vývoji informačného systému jedného z hlavných úloh je vytvorenie najjednoduchšieho a nevyloženého rozhrania. Je to programové rozhranie, ktoré pomáha "komunikovať" s informačným systémom, ktorý hovorí ako dialógové okno a systém používateľa.

Programové rozhranie, administrátor:

1. Štart forma programu. Tento formulár spustí, keď sa softvér začal tvoriť, teda začiatok dialógového okna používateľa so systémom (obrázok 2.3);

2. Tvar administrátora. V tomto formulári je informačný systém plne kontrolovaný, t.j. Pridávanie, vymazanie, zmena údajov v databáze, ako aj v prípade potreby, zobrazenie a tlačových hlásení (obrázok 2.4);

3. Formulár "zákazníci", vďaka tomuto formuláru môžete vidieť kompletné informácie o zákazníkov podniku (obrázok 2.7);

4. Formulár "dodávateľov", vďaka tomuto formuláru môžete vidieť kompletné informácie o zákazníkov podniku (obrázok 2.8).

Programové rozhranie Vlastná časť:

V okne je príchod tovaru návrh tovaru. Po výbere tejto karty musí užívateľ najprv

V ponuke Spotreba existujú operácie pracovného skladu na dovolenke a predaji tovaru.

V ponuke zvyškov sa produkt počíta, názov uloženého v sklade.

V ponuke Cashier sa uložia informácie o farských zákazkách a prepustených hotovostných príkazoch. (Screenshots)

2.2.2 Kontrolné komponenty používateľských rozhraní

Obrázok 2.0 Hlavné menu programu

Hlavné okno programu je znázornené na obr. 1.9. Ako je možné zrejmé z obrázku, okrem hlavného menu, už opísanej vyššie, bude tiež obsahovať ovládací panel ("Arrival", "spotreba", "prístup", "zostáva", "pokladník", "precenenie "," Analytics "," referencie "," Service "a" Exit z programu ").

Obrázok 2.1 Okno prichádzajúceho menu alebo vstup do skladu.

Obrázok 2.2 Okno Priechodné menu

Obrázok 2.2 Okno menu Nastavenie prístupových práv na program.

Obrázok 2.3 Zvýšenie menu okna tovaru.

Obrázok 2.4 Okno Cash Menu.

Obrázok 2.4 Prehodnotenie okna.

2.3 Design databázy

Erwin 4.0 z počítačových asociátov Int sa použil na navrhovanie databázy.

Erwin je výkonný a ľahko použiteľný nástroj databázového dizajnu, ktorý získal rozšírené rozpoznávanie a popularitu. Poskytuje najvyššiu produktivitu práce pri vývoji a údržbe aplikácií pomocou databáz. Počas celého procesu, od logických požiadaviek modelovania informácií a obchodných pravidiel, ktoré určujú databázu, pred optimalizáciou fyzického modelu v súlade so špecifikovanými vlastnosťami - Erwin umožňuje vizuálne zobraziť štruktúru a základné prvky databázy.

Erwin nie je len najlepším nástrojom na navrhovanie databáz, ale aj pre rýchle vytvorenie. Erwin optimalizuje model v súlade s fyzikálnymi vlastnosťami cieľovej databázy. Na rozdiel od iných nástrojov ERWIN automaticky udržiava koherenciu logických a fyzikálnych schém a transformuje logické štruktúry, ako sú vzťahy mnohými mnohými, pri ich realizácii na fyzickej úrovni. Uľahčuje dizajnové databázy. Aby ste to urobili, stačí vytvoriť grafický model E-R (objekt-postoj), ktorý spĺňa všetky požiadavky na údaje a zadajte obchodné pravidlá na vytvorenie logického modelu, ktorý zobrazuje všetky prvky, atribúty, postoje a zoskupenia. Erwin má dve úrovne modelovej prezentácie - logické a fyzické. Logická úroveň je abstraktným pohľadom na údaje, je na ňom prezentované, pretože sa pozerajú do reálneho sveta, a môžu byť volaní, ako sa nazývajú v reálnom svete, napríklad "trvalý klient", "oddelenie" alebo "Rodina zamestnanca". Objekty modelu predstavovaného na logickej úrovni sa nazývajú entity a atribúty. Logická úroveň dátového modelu je univerzálna av žiadnom prípade spojená so špecifickou implementáciou DBMS. Existujú tri zostupy logickej úrovne dátového modelu, sa líšia v hĺbke prezentácie informácií o údajoch:

Diagramový subjekt - komunikácia (diagram vzťahov so subjektmi (ERD));

Kľúčový dátový model (model založený na kľúč (KB));

Kompletný model (FA).

Diagram Essence - Komunikácia zahŕňa subjekty a vzťahy odrážajúce základné obchodné oblasti oblasti. Tento diagram nie je príliš podrobný, zahŕňa hlavné subjekty a vzťahy medzi nimi, ktoré spĺňajú základné požiadavky. Essencia diagramu - Komunikácia môže zahŕňať "Mnoho k mnohým" komunikáciám a nezahŕňajú kľúčové popisy. ERR sa spravidla používa na prezentácie a diskutovať o štruktúre údajov s odborníkmi z oblasti. Kľúčový dátový model je podrobnejší pohľad na údaje. Obsahuje opis všetkých subjektov a primárnych tlačidiel a je určený na reprezentáciu dátovej štruktúry a tlačidiel, ktoré zodpovedajú oblasti predmetu.

Logickým modelom je najpodrobnejšie znázornenie dátovej štruktúry: predstavuje údaje v tretej normálnej forme a zahŕňa všetky subjekty, atribúty a komunikácie (pozri dodatok B).

Model fyzického dát Naopak, záleží na konkrétnych DBMS, v skutočnosti je zobrazenie systému systémového adresára. Fyzická úroveň modelu obsahuje informácie o všetkých objektoch databázy. Keďže neexistujú žiadne normy pre databázové objekty (napríklad neexistuje žiadny štandard pre typy údajov), fyzická úroveň modelu závisí od konkrétnej implementácie DBMS. V dôsledku toho môže tá istá logická úroveň modelu zodpovedať niekoľkým rôznym fyzickým úrovniam rôznych modelov. Ak model nemá väčšiu hodnotu na logickej úrovni, ktorá špecificky typ údajov v atribúte (hoci sú podporované abstraktné typy údajov), je dôležité opísať všetky informácie o špecifických fyzických objektoch - tabuľky, stĺpce, indexy postupy atď. Oddelenie dátového modelu na logické a fyzické úrovne vám umožní vyriešiť niekoľko dôležitých úloh.

Model fyzického dát je uvedený v dodatku V.

2.4 Odôvodnenie výberu platformy tvorby informačného systému

Visual FoxPro je vizuálne prostredie pre rozvoj systémov správy relačného databázy v súčasnosti produkované spoločnosťou Microsoft Corporation. Posledná verzia je 9,0. Používa programovací jazyk FOXPRO. Verzia systému 7.0 môže pracovať v operačných systémoch Windows 9x a NT Kernel, verzia 8.0 a 9.0 - len v systéme Windows XP, 2000, 2003.

FOXPRO (FOX-PRO?) Je jedným z dialektov programovania XBASE. Používa sa hlavne na rozvoj relačných DBMS, hoci je možné požiadať o vývoj a iné triedy programov. Ako už bolo uvedené vyššie, jazyk VFP je silne udelený a pokročilý jazyk XBASE. V Visual FoxPro je programovací jazyk, to znamená, že základným dizajnom jazyka je koncept triedy. Pôvodná verzia XBASE je najčistejšou štruktúrou so základným konceptom postupov a funkcií. Moderný programovací jazyk Visual FoxPro teda umožňuje kombinovať oba programovanie "starým spôsobom", ktorý opisuje hmotnosť procedúr av štýle OOP, vytvára komplexnú hierarchiu tried.

Vybral som si toto jazykové programovanie, pretože obsahuje niekoľko nasledujúcich výhod:

¾ Široko známy formát databázových tabuliek, čo uľahčuje usporiadanie zdieľania informácií s inými aplikáciami Microsoft Windows.

Moderná organizácia relačných databáz, ktorá vám umožňuje ukladať informácie o tabuľkách základne, ich vlastností, indexov a odkazov, stanovujú podmienky pre dodržiavanie referenčnej integrity, vytvárajú miestne a vzdialené zobrazenia (zobrazenie), komunikácie so servermi, uložené procedúry spustiteľné pri výskyte viac ako 50 rôznych typov udalostí. (VFP 7,0-9,0).

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

Vysoké obete s databázami: Multifunkčné okno s reláciou dát vám umožňuje zobraziť zoznam otvorených databázových tabuliek, ich odkazy, filtre, postup pre indexy, režimy pufrovania, presunúť na režimy úpravy modifikácií, pracovať s informáciami o tabuľke atď.

Vysoká rýchlosť vývoja aplikácií pomocou MASTERS (Sprievodca), dizajnéri, stavitelia (Builder), Režim Tipy Intellisense Tipy pri písaní textu textu, ladenia a testovacích systémov programu.

Schopnosť vyvinúť aplikácie pomocou technológie klient-server s údajmi uverejnenými na serveroch Oracle a Microsoft SQL Server Server a s inými aplikáciami Microsoft Windows pomocou ODBC a OLE

Systém VFP je určený na použitie profesionálnymi programátormi, preto neexistuje žiadny bod v Rushipifikácii svojho menu a jazyka - pre každý programátor, anglická syntax algoritmického jazyka je zvyčajná ako ruština.

2.5 Projektovanie modulov

Dajte nám prebývať na konštrukcii jedného z programových modulov a zvážte kroky na vytvorenie projektu vo svojom príklade.

Ako príklad, budem zvážiť návrh modulu, ktorý implementuje možnosť použitia "podáva žiadosť o prijatie."

Ak chcete začať, opisujeme prúdy udalostí, ktoré sa vyskytujú v tomto uskutočnení.

PrePLALA používať aplikáciu od klienta.

5. Možnosť použitia začína, keď klient odosiela aplikáciu.

6. Manažér otvára formu príchodu.

7. Manažér dátum žiadosti.

8. Manažér položí názov tovaru.

9. Manažér prispieva množstvo obchodného tovaru.

10. Manažér prispieva výšku žiadosti.

11. Manažér zavrie formulár.

12. Možnosť použitia končí.

Platba za použitie je návrhom aplikácie v systéme a vznik nového klienta v časopise hlavného formulára.

Zvážte sekvenčnú schému tohto použitia. Ako môžete vidieť z tohto diagramu, manažér, otvorenie formulára, spôsobuje niekoľko akcií - automaticky (z hľadiska manažéra) sa vyplní dátum žiadosti. Zoznam zákazníkov Pri výrobe aplikácie je vyplnený zo základne s primárnymi informáciami. Potom manažér prispieva všetkým potrebným údajom a klikne na tlačidlo "Accept". Vykonávajú sa tieto opatrenia. Všetky údaje sa prenášajú do uloženého procesu.

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

3.1 Implementácia aplikácií

Implementácia aplikácie je vo svojej podstate jedným z časovo náročných etáp pre vývojára informačného systému, pretože požiadavky, ktoré zákazník uvádza, by mali byť jasne a správne integrované do systému. Doteraz neexistujú žiadne takéto softvérové \u200b\u200bprodukty, ktoré by mohli "prispôsobiť" v požiadavkách takzvaného zákazníka a poskytnúť určitý súbor funkcií na implementáciu systému, ktorý spĺňa tieto požiadavky. Preto by mal každý vývojár vybrať pre seba optimálne prostredie pre rozvoj systému, ale treba poznamenať, že pri implementácii aplikácie nerobí bez písania programového poriadku. Pri písaní programu program, ktorý bude implementovaný niektorými funkciami, ktoré musí systém vykonať. V závislosti od zvoleného prostredia implementácie systému sa programový kód zobrazí inak, v takomto médiu, keď Microsoft Visual FoxPro bude jedným kódom programu, v jazyku Visual Basic inou atď.

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

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

1. Začnite formu systému. Tento formulár je tvar tlačidla a podľa toho každé tlačidlo vykonáva svoju funkciu. Tlačidlo Registrácia administrátora je zobrazené na obrázku 3.1. Tlačidlo vykoná funkciu, ktorá otvára panel administrácie, ak má užívateľ takéto práva na tento systém

2. Tlačidlo MENU. Čerpadlo vám umožňuje zaznamenať prichádzajúci tovar do skladu Obrázok 3.2.

3. V tlačidle menu sa spotreba vyrába zo zverejneného tovaru zo skladu Obrázok 3.3.

4. Tlačidlo Menu Access upravuje práva na používanie tohto programu Obrázok 3.4.

5. Zostatkové tlačidlo zostávajúceho menu uchováva informácie o uložených materiáloch v obchode Store Obrázok 3.5.

6. Tlačidlo Menu Casso ukladá informácie o príchode hotovostných registrov a výdavkov hotovosti. 3.6.

7. V tlačidle menu prebiehajú zmeny precenenia cenu novej ceny tovaru obr.3.7.

Obrázok 3.1 - Systém štartovania

Obrázok 3.2 - forma účtovníctva pre materiálové príjmy do skladu.

Obrázok 3.3- Forma účtovania uvoľneného tovaru.

Obrázok 3.4- Formulár na úpravu prístupových práv na program.

Obrázok 3.5- Forma výrobkov na sklade.

Obrázok 3.5-Formulár o ziskových pokladniach a prepustených peňažných predpisoch.

Obrázok 3,6-forma operácií tovar.

Testovacie aplikácie

Testovanie je proces vykonávania programu, aby sa zistili chyby. Testovanie poskytuje:

Detekcia chýb;

Preukázanie zhody programových funkcií jej účelu;

Preukázanie vykonávania požiadaviek na charakteristiky programu;

Zobrazuje spoľahlivosť ako indikátor kvality programu.

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

Pri prijímacom procese testovania troch prúdov:

Textový text;

Zdrojové údaje na začatie programu;

Očakávané výsledky.

Skúšky sa vykonávajú, všetky získané výsledky sa odhadujú. To znamená, že skutočné výsledky testov sa porovnávajú s očakávanými výsledkami. Keď sa zistí nesúlad, chyba je fixná - začína ladenie.

Po zbere a hodnotení výsledkov testov začína kvalita a spoľahlivosť softvéru. Ak existujú vážne chyby, ktoré vyžadujú zmeny dizajnu, kvalita a spoľahlivosť sú podozrivé, je uvedené, že je potrebné získať testovanie.

Výsledky nahromadené počas testovania sa môžu odhadnúť a formálne. To používa modely spoľahlivosti softvéru, ktoré vykonávajú prognózu spoľahlivosti reálnych dát v intenzite chýb.

Existujú 2 Princípy testovania programu:

Funkčné testovanie (testovanie "čierna skrinka");

Konštrukčné testovanie (testovanie "bieleho boxu").

Pri testovaní pomocou metódy "bieleho boxu" je známa vnútorná štruktúra programu. Cieľom testovania tu nie je externé, ale vnútorné správanie programu. Správnosť budovania všetkých prvkov programu a správnosť ich interakcie s navzájom sa skontroluje.

Testovanie "čierneho boxu" (funkčné testovanie) vám umožňuje získať kombinácie vstupných dát, ktoré poskytujú úplnú kontrolu všetkých funkčných požiadaviek na program //. Softvérový produkt nájdete ako "čierna skrinka", ktorého správanie možno určiť len štúdiom svojich vstupov a vhodných výstupov.

Princíp "čierneho boxu" nie je alternatívou k princípu "bieleho boxu". Je to skôr komplementárny prístup, ktorý detekuje ďalšiu triedu chýb.

Testovanie "čierneho boxu" poskytuje vyhľadávanie nasledujúcich kategórií chýb:

Nesprávne alebo chýbajúce funkcie;

Chyby rozhrania;

Chyby v externých dátových štruktúrach alebo prístup k externej databáze;

Chyby charakteristík (povinná kapacita pamäte atď.);

Chyby inicializácie a dokončenia.

Na rozdiel od testovania "bieleho boxu", ktorý sa vykonáva v počiatočnom štádiu skúšobného procesu, testovanie "čiernej skrinky" sa používa v neskorších štádiách testovania. Pri testovaní "čiernej skrinky" zanedbaná kontrolná štruktúra programu. Tu je pozornosť zameraná na informačné pole definície softvérového systému. Pri testovaní v tomto štádiu sa uvádza zameranie vhodnosti riešenia na prácu v životných podmienkach. Zameriava sa na opravu chýb a definíciu ich dôležitosti, ako aj prípravu výrobku na vydanie.

V skúšobnom štádiu sa riešia dva hlavné úlohy:

Testovacie riešenia - testovacie plány vytvorené v štádiu plánovania a rozšírené a testované počas fázy vývoja;

Bodová operácia - nasadenie riešenia v testovacom prostredí a testovanie s zapojením budúcich užívateľov a implementáciu scenárov použitia reálneho systému. Táto úloha sa vykonáva pred začiatkom etapy nasadenia.

Účelom testovacieho stupňa je zníženie rizika, ku ktorému dochádza pri vstupe do roztoku do priemyselnej prevádzky.

Pre úspech testovacieho stupňa je potrebné, aby sa vzťah došlo k projektu a vývojár sa zmenil z vývoja nových funkcií, aby sa zabezpečilo riadne riešenia kvality.

V tomto štádiu informačného systému sa musia vykonať tieto druhy testovania: \\ t

Základné testovanie - nízkoúrovňové technické testovanie. Vykonáva sa vývojár sám v procese písania programu Program. Používa sa metóda bielej zásuvky, vysoké riziko chýb.

Testovanie vhodnosti na použitie - testovanie na vysokej úrovni, vykonané testerom a budúcimi užívateľmi produktov. Používa sa metóda "Black Box".

Alpha a beta testovanie - v termínoch MSF Alfa-Code - to je v podstate všetky zdrojové texty vytvorené vo fáze vyvíjania MSF procesu modelu a beta kód je kód, ktorý bol testovaný počas testovacej fázy. Preto sa vo fáze vývoja modelu MSF modelu testuje, a v skúšobnom stupni - beta kód.

Testovanie kompatibility - Z rozvinutého riešenia je potrebná schopnosť integrovať a schopnosť spolupracovať s existujúcimi systémami a softvérovými riešeniami. Táto forma testovania je zameraná na kontrolu integrácie a schopnosti vyvinutého riešenia komunikovať s existujúcimi systémami. V tomto prípade sa skontroluje správnosť operácie aplikácie na užívateľskom zariadení a používateľovi používanom používateľovi.

Testovanie výkonu - orientované na kontrolu, či aplikácia spĺňa požiadavky na výkon a úroveň rýchlosti rýchlosti.

Testovacia dokumentácia a referenčný systém - všetky vyvinuté sprievodné dokumenty a referenčné systémy sú testované.

Pilotná operácia je testovanie riešení v priemyselnom prostredí. Hlavnou úlohou pilotnej operácie je preukázať, že riešenie je schopné pracovať stabilne pracovať priemyselné vykorisťovanie a spĺňa požiadavky podniku. V procese pilotnej prevádzky sa roztok testuje v reálnych podmienkach. Point operácia umožňuje používateľom vyjadriť svoj názor na prácu produktu. Týmto stanoviskom, vývojárom eliminuje všetky možné problémy alebo v prípade nepredvídaných okolností je vytvorený akčný plán. Nakoniec, pilotná operácia vám umožňuje rozhodnúť, či spustíte spustenie nasadenia plného rozsahu alebo odložiť pred odstraňovaním problémov s narušením nasadenia.

PLOKOVÝ PROSTREDNÍKOVÝ PLÁNOVÝ PLÁNOVÝ PROSTREDIE POTREBUJÚCEHO POTREBUJÚCEHO SYSTÉMU.

Tabuľka 3.2 - PLÁNOVANIE PLÁNOV

Konať		Popis
1. Výber kritérií úspechu		Vývojár a účastníci skúseného testovania určujú kritériá úspechu a ich koordinujú
2. Výber užívateľov a inštalačných miest		Vytvorí sa tím účastníkov skúsených testov od užívateľov a vývojárov. Stanoví sa umiestnenie pilotného procesu.
3. Príprava užívateľov a inštalácie		Užívateľský tréning sa vykonáva - účastníci testu. Umiestnenie inštalácie je pripravené.
4. nasadenie skúsenej verzie		Nainštaluje sa skúsená verzia a je súčasťou práce.
5. Podpora a monitorovanie skúsenej verzie		Kontrola práce používateľov a systém, pomoc pri prevádzke, zhromažďovanie informácií o prevádzke systému
6. Spätná väzba s užívateľmi a hodnotenie výsledkov		Užívatelia vyjadrujú svoj názor na prevádzku systému, uveďte nedostatky a chyby.
7. Pozmeňujúce a doplňujúce návrhy a doplnky	Zistené chyby sú opravené, zmeny sa uskutočňujú v dizajne alebo procese. Pevné výsledky sú poskytnuté pre prácu a hodnotiť používateľov.
8. Rozhodnutia o nasadení	V prípade, že výsledky práce skúsených testov uspokojí užívateľov, rozhodnutím o nasadení systému.

3.2 Metóda nasadenia aplikácií

V tomto štádiu, vývojár (alebo tím) nasadzuje technológie a komponenty potrebné na riešenie riešenia, projekt ide do fázy sprievodu a podpory a zákazník ho konečne schvaľuje. Po nasadení, príkaz vyhodnocuje projekt a prieskum používateľa, aby zistil stupeň ich spokojnosti.

Ciele etapy nasadenia:

¾  Preneste riešenie priemyselného prostredia;

¾  Uznanie skutočnosti zákazníka na dokončenie projektu.

Nasadenie komponentov charakteristických pre konkrétne miesto inštalácie sa skladá z niekoľkých stupňov: príprava, inštalácia, školenie a formálne schválenie.

Výsledky fázy nasadenia systému sú eskortné a podporné systémy, archív dokumentov, kde sú umiestnené všetky verzie dokumentov a kódov vyvinuté počas projektu.

Na nasadenie rozvinuté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ácií

Konať	Opis činnosti
1. zálohovanie	Zálohovanie užívateľských dát sa vykonáva s jeho účasťou a koordináciou prenosom informácií na vymeniteľné médiá (CD, DVD)
2. Nastavenie základných zložiek riešenia	Aplikácia technológií, ktoré zabezpečujú prevádzku riešenia. V tomto prípade inštaláciu komponentu Visual FoxPro
3. Inštalácia aplikácie klienta	Preneste do počítača používateľa a nastavenie konečnej verzie vyvinutého a databázy
4. školenie	Užívateľský tréning je vyrobený na spoluprácu so systémom, vývojár je presvedčený o správnosti a pochopení práce IP zákazníkom
5. Prevod vedomostnej základne klienta projektu	Zákazník sa prenáša všetky projektové dokumentácie
6. Zatvorenie projektu	Vypracuje sa správa o uzavretí projektu. Zákazník podpíše akt prijatia.

Pre normálne fungovanie AWS vyžaduje operačný systém Microsoft WindowsXP.

4 Informačné riadenie projektov

4.1 Výber životného cyklu rozvoja

Jedným zo základných pojmov metodiky IP dizajnu je koncepcia životného cyklu jeho softvéru (LCC softvér). LCC je nepretržitý proces, ktorý začína momentom rozhodnutia o potrebe vytvoriť ho a končí v čase jeho úplného zabavenia.

Hlavným regulačným dokumentom regulačným softvérom LCH je Medzinárodná norma ISO / IEC 12207 (ISO - Medzinárodná organizácia normalizácie - Medzinárodná organizácia pre normalizáciu, IEC - Medzinárodná elektrotechnická komisia - Medzinárodná komisia pre elektrotechniku). Definuje štruktúru ELC obsahujúcu procesy, činnosti a úlohy, ktoré sa musia vykonávať počas vytvárania softvéru.

Norma ISO / IEC 12207 neposkytuje špecifický model LC modelu a vývoj softvéru. Pod modelom ZHC môžete pochopiť štruktúru, ktorá definuje postupnosť implementácie a prepojenia procesov, akcií a úloh vykonaných počas LCC. LCD model závisí od špecifík IC a špecifiká podmienok, v ktorých je vytvorená a funguje.

K dnešnému dňu existuje mnoho modelov životného cyklu softvéru, ale najobľúbenejšie sú dva modely:

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

Iteratívny model.

Obrázok 4.1 - špirálový model LC

Vytvoriť informačný systém, t.j. "Automatizované pracovisko zamestnanca skladu veľkoobchodu", bolo vybrané iteratívne. Charakteristickým znakom iteratívneho modelu môže byť nazývaný to, čo je formálnym spôsobom, pozostáva z nezávislých fáz vykonávaných v sériách a podlieha častému preskúmaniu (obrázok 4.2). Iteračný prístup sa ukázal ako v konštrukcii OP, pre ktorý na samom začiatku vývoja je možné určite a plne formulovať všetky požiadavky, aby poskytli vývojárom slobodu realizovať čo najviac z technického bodu vyhliadka.

Výhody iteratívneho modelu:

model je dobre známy spotrebiteľom, ktorí nesúvisia s vývojom softvéru a koncovým užívateľom.

Pohodlie a jednoduchosť používania, pretože Všetky práce sa vykonávajú v etapách (fázami modelu);

Stabilita požiadaviek;

Model je k dispozícii na porozumenie;

Štruktúra modelu sa môže riadiť aj slabo pripraveným personálom (neskúseným používateľom);

Model si môže riadiť s ťažkosťami a funguje dobre pre tie projekty, ktoré sú dosť zrozumiteľné;

Model prispieva k realizácii prísnu kontrolu riadenia projektov;

Uľahčuje prácu projektového manažéra na prípravu plánu a konfigurácie tímu Developer.

Obrázok 4.2 - Iteratívny model ZHC

Fázový model:

V štádiu analýzy fungujú funkcie, ktoré systém musí vykonávať, identifikujú najviac priorít, ktoré si vyžadujú vypracovanie predovšetkým popisovať informačné potreby;

V štádiu návrhu sa systémové procesy považujú za podrobnejšie. Analyzované av prípade potreby je funkčný model nastavený. Sú postavené prototypy;

V etape implementácie existuje vývojový rozvoj;

V etape implementácie je hotový výrobok zavedený do už súčasného organizačného systému. Používatelia sú vyškolení;

V etape sprievodu je softvérový produkt udržiavaný (akékoľvek pridávanie alebo zmena, pre funkčnejšiu prevádzku produktu).

Výber modelu životného cyklu rozvoja softvéru je dôležitým krokom. Preto môže byť pre projekt výber modelu vývoja softvéru počas používania nasledujúcich procesov vykonať.

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

Odpovedzte na otázky uvedené pre každú kategóriu zdôraznením slov "áno" a "nie".

Nájdite kategóriu kategórie alebo otázky týkajúce sa každej kategórie vzhľadom na projekt, pre ktorý je vybraný prijateľný model.

Tím pre vývojárov . Na základe možností, výber pracovníkov v tíme Developer prechádza pred okamihom, keď bude zvolený model životného cyklu rozvoja softvéru. Charakteristika takéhoto tímu (pozri prílohu W Tabuľka W.1) Hrajte 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éru, pretože Zodpovedá za úspešnú implementáciu rozvinutého modelu životného cyklu.

Tímový tím . V počiatočných fázach projektu môžete získať úplný obraz tímu užívateľov (pozri prílohu a tabuľku a.1), ktorá bude fungovať s vyvinutým softvérom a jej budúcim vzťahom s vývojárskym tímom v celom projekte. Takáto prezentácia pomáha pri výbere vhodného modelu, pretože niektoré modely vyžadujú zvýšenú účasť používateľa v procese rozvoja a štúdium projektu, pretože požiadavky môžu mierne zmeniť užívateľa počas procesu vývoja, vývojár musí poznať tieto zmeny a ako Tieto zmeny sú v softvéri.

4.2 Definícia účelu a oblasti programu Program

Programový produkt je vyvinutý na tovar na sklade, umožní vám automatizovať proces prijímania, štruktúrovania a skladovania údajov o výrobkoch, ako aj zjednodušiť proces vydávania správ.

Ciele programu Program bude vytvárať a nasadenie systému účtovníctva produktu. Tento systém je určený pre interné použitie pracovníkom "Cleonelly", vo väčšine pracovníkov zamestnancov podnikového skladu.

Ak chcete určiť rozsah softvérového produktu, bude popísané nižšie, čo by nemalo byť softvérovým projektom.

Programový projekt by mal byť:

Pre vnútorné použitie v organizácii;

Projekt na realizáciu prístupu multiplayerov;

Projekt, ktorý má schopnosť zväčšiť, zmeniť a ukladať informácie o produkte podniku;

Projekt, ktorý má možnosť povoliť, zmeniť a ukladať informácie o používateľoch systému;

Projekt, ktorý má schopnosť umožniť, zmeniť a ukladať informácie o zákazníkov a dodávateľoch organizácií, ktoré sú predmetom uzavretých transakcií;

Projekt, ktorý zavedie formovanie externého vykazovania.

4.3 Vytvorenie štruktúry operačného zoznamu prác

Ak chcete vytvoriť jedinečný produkt alebo službu (výsledok projektu), je potrebné vykonať určitý postup práce. Úlohou plánovania projektu je presne presná doba realizácie a náklady na tieto práce. Presnejšie povedané, posúdenie je uvedené, tým vyššia je kvalita plánu projektu. Ak chcete poskytnúť presné hodnotenie, musíte prezentovať zloženie práce projektu, to znamená, že je potrebné splniť aký druh práce. Až po vypracovaní zoznamu projektovej práce sa odhaduje trvanie každej z nich a zdroje potrebné na ich vykonávanie sú pridelené. A až potom môžete odhadnúť náklady a načasovanie vykonávania každej úlohy a v dôsledku dodatku, celkové náklady a obdobie projektu. Preto je definícia zloženia práce prvým krokom pri plánovaní projektu. Definícia projektovej práce začína definíciou etab (alebo fáz) projektu. Napríklad v projekte je možné zvýrazniť vytvorenie systému "účtovníctva na sklade":

Vývoj požiadaviek na softvér;

Informačný systém dizajnu;

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

Implementácia systému.

Po zložení fáz a ich výsledkov je definovaná, je potrebné určiť postupnosť týchto fáz voči sebe navzájom a lehotu na ich vykonanie. Potom musíte určiť, ktoré súbory budú pozostávať z fázy, v ktorej sekvencie sa tieto práce vykonávajú a v akom čase je potrebné splniť, keď sú vykonané.

Úvodný zoznam diel (obrázok 4.3) bol navrhnutý s použitím softvérového produktu, ako je MS Project 2003.

Obrázok 4.3 - Odporúčaný zoznam diel

4.4 Hodnotenie trvania a nákladov na rozvoj

Hodnotenie trvania. Stanoví sa po konštrukcii úvodného zoznamu diel (obrázok 4.3, bod 4.3). Tento odhad trvania možno vidieť pomocou grafu GANTA (aplikácia k).

Grafy sú grafické zobrazenie informácií obsiahnutých v súbore projektu. Z grafov môžete získať vizuálnu predstavu o postupnosti úloh, ich relatívnej dĺžky trvania a trvanie projektu ako celku.

Gantt graf je jednou z najobľúbenejších metód grafickej prezentácie projektového plánu, ktorý sa používa v mnohých programoch projektového riadenia.

V projekte MS je Ganttový diagram hlavným prostriedkom vizualizácie projektu. Tento diagram je graf, na ktorom je časová stupnica umiestnená horizontálne, a úloha sa nachádza vertikálne. V tomto prípade je dĺžka segmentov, ktoré naznačujú úlohy, je úmerná dĺžke úloh.

Na Ganta Diagram vedľa segmentov sa môžu zobraziť ďalšie informácie (mená zdrojov, ktoré sa im týkajú a ich sťahovanie sa zobrazia počas úlohy).

Odhad nákladov

Projekt sa skladá z úlohy , To znamená, že aktivity zamerané na dosiahnutie určitého výsledku. Aby sa na ňom mohla vykonať úloha prostriedky .

Dôležitou vlastnosťou zdrojov je náklady (náklady (náklady)) ich používania v projekte. V MS projektu existujú dva typy nákladov na zdroje: časovo založená sadzba a náklady na použitie.

Časová sadzba (sadzba) je vyjadrená v nákladoch na používanie zdroja na jednotku času, napríklad 100 rubľov za hodinu alebo 1000 rubľov denne. V tomto prípade budú náklady na účasť zdrojov na projekte čas, počas ktorého funguje v projekte vynásobenej hodinovej sadzbe.

V tomto prípade sa použila časová sadzba (obrázok 4.4) Celkové náklady na používanie zdrojov môžu byť na obrázku 4.5.

Obrázok 4.4 - Časová sadzba pri používaní zdroja

Na tomto obrázku môžete vidieť, že vývojár systému pri vykonávaní projektu dostáva 50 rubľov za hodinu; Obchodný analytik prijíma 45 rubľov za hodinu, tester je 38 rubľov za hodinu. Rýchlosť nadčasov sa neberie do úvahy.

Obrázok 4.5 - Všeobecné náklady na používanie zdrojov projektu

4.5 Rozdelenie projektových zdrojov

Fragment distribúcie zdrojov pre systém "účtovníctva skladom" možno vidieť na obrázku 4.6

Obrázok 4.6 - Fragment distribúcie zdrojov projektu

Pre každú prácu vykonanú v projekte sa porovnáva zdroj s vykonaním tejto práce. Obrázok ukazuje celkový počet pracovných nákladov každý zo zdrojov a konkrétny počet hodín strávených v konkrétnom dni.

4.6 Hodnotenie ekonomickej efektívnosti projektu

Výpočet ekonomickej efektívnosti projektu je dôležitým krokom. Je tu vypočítaná ekonomická efektívnosť projektu. Tento výpočet ukáže, koľko je projekt prospešný alebo projekt je úplne strata. Pri výpočte ekonomickej efektívnosti projektu bude potrebné vypočítať obdobie návratnosti projektu. Doba návratnosti ukáže obdobie, pre ktoré bude projekt vyplatiť.

Vstupné Data.

Dodatočné zisky z realizácie projektu (DP) \u003d 38000 rubľov. Enterprise experti predpovedal ďalší zisk.

Začiatočné investície (IC) \u003d 39396,47 rubľov. Začiatočné investície sú v súlade s celkovými nákladmi na používanie zdrojov projektu (Obrázok 4.5 bodu 4.6)

Diskontná sadzba (i) \u003d 12%.

Termín, na ktorý sa projekt vypočíta (n) \u003d 2 roky.

Dodatočné zisky z realizácie projektu (DP) \u003d 38000 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é peňažné príjmy (R 1) \u003d 23000 rubľov.

Ročné peňažné príjmy (R 2) \u003d 28 000 rubľov.

Pri hodnotení investičných projektov sa používa metóda výpočtu čistého výnosu, ktorá zahŕňa diskontovanie peňažných tokov: všetky príjmy a náklady sa dajú raz.

Ústredným ukazovateľom v posudzovanej metóde je NPV (čistá súčasná hodnota) - aktuálna hodnota peňažných tokov. Ide o generalizovaný konečný výsledok investičných činností v absolútnom meraní.

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

Čistý znížený príjem (NPV) sa vypočíta podľa vzorca 4.2

(4.2)

R K - Ročné peňažné príjmy počas n rokov.

k - Počet rokov, ako je projekt vypočíta.

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

i - diskontná sadzba.

Podľa výpočtov tohto vzorca NPV \u003d. 3460,67 rubľov.

Ukazovateľ NPV je absolútnym nárastom, pretože hodnotí, koľko príjmov prekrýva náklady. Od NPV\u003e 0 by sa mal projekt prijať.

Pomer investičného návratu (ROI) sa vypočíta podľa vzorca 4.3

(4.3)

O výpočtoch (ROI) \u003d 108,78%

Tabuľka 4.1  Pomocná tabuľka Výpočet návrhu obdobia návratnosti

= 1,84

Doba návratnosti N OK \u003d 1,84 Roky (1 rok a 11 mesiacov)

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

(4.4)

Teda index ziskovosti sa rovná (PI) \u003d 1.2

Automatizované pracovné miesta

Požiadavky na funkčné charakteristiky

Zoznam generovaných správ

4.4.2. Požiadavky na systém plánovania a riadenia

Informačný systém by mal zabezpečiť plánovanie podnikových zdrojov a riadenie bypass výroby.

Požiadavky na funkčnosť IP:

1. Riadenie konfigurácie hotového výrobku (GP):

Udržiavanie regulačných informácií o zložení GP s možnosťou špecifikovania obdobia relevantnosti špecifikácie as možnosťou zistenia pri výrobe GP s niekoľkými rôznymi špecifikáciami;

Udržiavanie regulačných informácií o technológii výrobných výrobkov zahrnutých v GP s možnosťou špecifikovania obdobia významu technológií as možnosťou zistenia 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 / úprava aplikácie klienta s uvedením zoznamu GP, objemov, dátum odoslania, predajná cena a akékoľvek ďalšie podmienky;

Zobraziť aktuálne ekonomické ukazovatele (výpočet) objednaného GP;

3. Plánovanie výroby:

Vytvorenie harmonogramu dostupnosti vybavenia označujúci počet dostupných hodín pre každý deň plánovaného obdobia;

Tvorba výrobného plánu s uvedením vyrábaného výrobku, jej počet, použité vybavenie, divízie pre každý deň plánovaného obdobia;

Tvorba plánu na potrebu výroby materiálov a komponentov;

Monitorovanie a riadenie nakladacích zariadení pre generovaný výrobný plán;

Vykonať úpravy výrobného plánu počas jej implementácie;

Továreň analýza výrobného plánu;

4. Riadenie výroby:

Vytvorenie vymeniteľných úloh (oblečenie) na výrobu výrobkov;

Účel / preradenie odevov výkonných umelcov a fixáciu vykonávania odevov, ktoré označujú počet vydaných výrobkov, počet chybných výrobkov a príčiny manželstva;

Riadenie skladovania a pohybu komoditných hodnôt (TMC) vo výrobe;

5. Správa dodávok:

Tvorba na základe plánu potreby materiálov a komponentov žiadostí o kúpu s označením Dodávateľa, nomenklatúru TMC, počet a termínov ponuky;

Vytvorenie žiadostí o nákup na základe jednorazových objednávok pre TMC z divízií;

Monitorovanie a sledovanie implementácie nákupných aplikácií;

Prevádzková kontrola rezíduí;

Plán-faktová analýza dodávok;

6. Riadenie nákladov:

Tvorba plánovaných (regulačných) nákladov GP;

Fixáciu skutočných výrobných nákladov;

Výpočet skutočných nákladov GP;

Analýza nákladov na plánovanie.

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

Regulačné náklady výrobku a celá objednávka sa vypočítajú podľa nasledujúceho postupu: \\ t

1. Priama materiálová zložka regulačných nákladov na výrobok je vytvorená na základe informácií o regulačnom rámci tohto výrobku (špecifikácií) a zavedených účtovných cien pre TMC zahrnuté do tejto špecifikácie. Pre špecifikáciu je povolené použitie niekoľkých výrobkov z nákladov materiálu.

2. Hodnota priamych miezd sa vypočíta na základe regulačného výkonu výrobku. Nastaviť: Regulačné trvanie každej prevádzky, povolanie pracovníka potrebného na túto operáciu, ako aj vypúšťanie pracovníka. Systém je tiež zavedený s hotovostnými sadzbami Normo hodín profesiou pracovníkov a ich vypúšťania.

3. Regulačná hodnota nepriamych nákladov sa vypočíta ako percento špecifikovanej základne (hodnoty priamych nákladov podľa tohto článku).

Na realizáciu tohto výpočtu musíte mať v informačnom systéme tieto údaje:

1. Špecifikácia výroby výrobku (ako aj špecifikácie výroby všetkých partnerov polotovarov zahrnutých do tohto výrobku);

2. Technológia výroby výrobkov a polotovary zahrnuté v ňom: Aké činnosti musia byť dokončené a na aký čas. Okrem toho každá operácia poskytuje povolanie a plnenie pracovníkov potrebných na jeho vykonanie (na prepustenie tohto konkrétneho výrobku);

3. Protokol o účtovných cenách používaných TMC;

4. Cash Sadzby Normo Hodiny pre profesie a vypúšťanie.

Požiadavky na výpočet nákladov na skutočné objednávky

Skutočné náklady na výrobok a celú objednávku sa vypočítajú podľa nasledujúceho postupu:

1. Priame materiálové náklady na výrobu výrobkov sa vypočítajú na základe skutočných údajov o výdavkoch dielni materiálov na konverziu výroby. Zároveň sa vypočíta hodnota všetkých polotovarov zahrnutých v tomto produkte. Odhad sčítania sa vykonáva podľa metodiky prijatej v účtovnej politike spoločnosti.

2. Maliarstvo priamych výrobných pracovníkov sa vypočíta na základe údajov o uzavretí workshopov. V prípade, že účtovníctvo odevov v OP nie je vykonané, plat sa vzťahuje na priame náklady, ktoré sa majú distribuovať, t.j. Je distribuovaný do vydaných produktov podľa niektorých databázy.

3. Odpisy priamych výrobných zariadení je zahrnuté v zložení priamych výdavkov, ak je zariadenie (stroj) používané na tejto hranici špecifikované pre každý konvertor.

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

Hlavné materiály spotrebované menej často ako každá konverzia (napríklad chemikálie, ktorých norma na jednotku výroby je taká malá, že má zmysel zohľadniť ich tesnenie aj pre túto normu);

Mzdy pracovníkov v neprítomnosti informácií o jeho distribúcii kempe

Odpisy priameho vybavenia v prípade iba jeho celkovej mesačnej sumy bez porušenia redistribúcie.

Takéto výdavky sú rozdelené na vyrábaných výrobkoch podľa zvolenej distribučnej základne (napríklad v pomere k priamym nákladom na materiál).

1. Ochranné náklady (25 ÚČTU BU): sú distribuované výrobkom úmerným pre vybranú distribučnú základňu. Podiel týchto výdavkov môže zostať alebo nie v zložení neúplnej výroby podľa účtovnej politiky prijatej v podniku.

2. Všeobecné náklady a náklady na predaj (26 a 44 účty BU) sú vykázané nákladmi na súčasné obdobie a súvisia s výdavkami na vykonávanie. Distribúcia takýchto výdavkov na náklady hotových výrobkov možno vidieť pomocou špeciálnej správy.

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

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

Požiadavky na spoľahlivosť

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

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

Spoľahlivý (udržateľný) fungovanie informačného systému by mal zabezpečiť zákazník skupiny organizačných a technických opatrení, ktorých zoznam je uvedený nižšie:

1. Organizácia nepretržitého napájania;

2. Používanie licenčného softvéru;

3. Pravidelné plnenie odporúčaní ministerstva práce a sociálneho rozvoja Ruskej federácie, stanovené v rozhodnutí 23. júla 1998. "o schválení rozvetvových modelových štandardov času na prácu na údržbe služieb PEVM a kancelárskych zariadení a podporný softvér ";

4. Pravidelné plnenie požiadaviek GOST 51188-98. "Ochrana informácií. Testovací softvér pre počítačové vírusy ";

5. Pravidelná rezervácia databázy informačného systému prostredníctvom samotného informačného systému alebo prostriedkov používaného systému správy databázy.

1. Relevantnosť a potreba výskumu

S výskytom nedávno v Ruskej federácii nového manažmentu nehnuteľností vo forme majiteľa bývania (HOA), Asociácia majiteľov bývania (HOA - majitelia domov) a kondominiums (neskôr - organizácie manažérstva nehnuteľností) (vlastníci) bývania sa objavili možnosť ovplyvniť nájomcov (vlastníkov) kvalitu zachovania nehnuteľností na zlepšenie priľahlého územia a do určitej miery na náklady na nástroje.

V súlade s článkom 161 kódexu bývania Ruskej federácie by mal riadenie bytového domu zabezpečiť priaznivé a bezpečné životné podmienky občanov, riadnu údržbu spoločného majetku v bytovom dome, riešenie problémov používania špecifikovaného majetku, Rovnako ako poskytovanie verejných služieb občanom žijúcim v takomto dome.

b) vzdelávací proces

Rozvoj vedeckých a vzdelávacích kurzov, ako aj vedecké a populárne materiály

	Názov kurzu/ materiál	Rýchly opis/ materiál
Vedecké a vzdelávacie kurzy	Návod "Informačné systémy správy bytových domov"	Funkčnosť informačných systémov v oblasti nehnuteľností používaných v Ruskej federácii av zahraničí. Funkčné funkcie sa porovnávajú s odporúčaniami pre výber informačného systému. Navrhnuté na školenie študentov v oblastiach 080100.62 "ekonómia" a 080500.62 "Business-Informatika"
Laboratórny dielňa "Systém riadenia obchodných pravidiel správy Manažérskej organizácie MKD"	Krok za krokom pokyny pre generovanie modulu správy obchodných pravidiel pomocou IBM ILOG. Uvádza sa algoritmus pre riadenie obchodných pravidiel HOA. Navrhnuté na vyškoliť študentov v smere 080500.62 "Business Informatika"
Laboratórny dielňa "Multi-agent Modelovanie organizačných aktivít v oblasti správy nehnuteľností"	Krok za krokom pokyny pre tvorbu činidiel a tvorba modelu organizácie riadenia nehnuteľností pomocou anylogických. Navrhnuté na vyškoliť študentov v smere 080500.62 "Business Informatika"
Návod "Vývoj základnej databázy bytového domu pomocou MS Access 2010 DBMS"	Existujú krok za krokom pokyny pre vytvorenie databázových tabuliek, ktorým sa zriaďujú prepojenia medzi nimi, stavebnými formami, požiadavkami, správami a makrámi pomocou možností MS Access 2010 DBMS.
Laboratórny dielňa "Analýza obchodných procesov organizácie pre riadenie nehnuteľností"	Diagramy navrhnuté pomocou objektovo orientovaného modelovacieho jazyka UML sú uvedené. Navrhnuté na školenie študentov v oblastiach 080100.62 "ekonómia" a 080500.62 "Business-Informatika"
Vedecké populárne materiály	Monografie "Továreň a klastrová analýza organizácií regiónu v oblasti riadenia nehnuteľností"	Odporúčania o faktor a klastrovú analýzu parametrov charakterizujúcich zvolený región HOA. Informácie o organizáciách manažmentu nehnuteľností s rovnakými súbormi podnikových procesov a určenie hlavných faktorov ovplyvňujúcich ich činnosť
Monografie "Algoritmy výmeny informácií v organizácii manažmentu nehnuteľností"	Všeobecný algoritmus práce OP, algoritmy fungovania softvérových modulov implementačných informačných služieb pre účastníkov, algoritmy pre interakciu softvérových modulov sú uvedené. Užívateľské rozhranie informačného systému. Vlastnosti vývoja modulov softvérového kódu pomocou rozvoja životného prostredia MS Visual 2010
Článok "Klasifikácia predplatiteľov a informačných systémov v manažérskych organizáciách MKD"	Vzory výmeny informácií v rámci organizácie riadenia nehnuteľností, odhadované zloženie a objem údajov počas výmeny informácií, údajná transformácia údajov počas výmeny informácií, formy podania vstupných a výstupných údajov
Článok "Vývoj multi-vekového modelu pre modelovanie aktivít HOA"	Prístupy k tvorbe agentov pre oblasť predmetu, ako aj vývoj simulačného modelu. Výsledky modelovacích aktivít HOA s rôznymi súbormi zdrojových údajov sú uvedené.
Článok "Forming súbor obchodných pravidiel pre HOA"	Prístupy k vytvoreniu stanovených obchodných pravidiel. Zohľadňujú sa možnosti vykonávania systému riadenia obchodných pravidiel pomocou ILOG ILOG. Príklad použitia obchodných pravidiel na prijatie rozhodnutia.
Článok "Formácia algoritmov pre informačný systém organizácie pre riadenie nehnuteľností"	Štruktúra algoritmu informačného systému, štruktúra algoritmov softvérových modulov, implementačných informačných služieb a výmeny informácií s databázou organizácie.
	Článok "Aplikácia holistického prístupu tvoria komplexné kľúčové ukazovatele výkonnosti činností HOA"	Uplatňovanie ustanovení holistického prístupu k vzniku komplexu ukazovateľov, čo umožňuje vytvorenie hodnotiaceho systému na dosiahnutie strategických a taktických (prevádzkových) cieľov pre organizáciu riadenia nehnuteľností, posudzovanie stavu organizácie a kontroly podnikateľskej činnosti účastníkov informačného systému v reálnom čase.
Článok "Informačné služby pre správu bytových domov"	Zohľadňujú sa informačné služby poskytované zahraničnými informačnými systémami (nájomníci) nehnuteľností v bytových domoch.
Článok "Tvorba databázy pre informačný systém HOA"	Dátové modely, skladovanie a spracovanie údajov, zloženie dát, formáty dát na odrážanie v užívateľských rozhraniach a výstupných dokumentoch, typoch údajov, určených zložení tabuliek, ako aj spojov obvodov medzi tabuľkami
Článok "Organizačná analýza a model obchodných procesov HOA"	Rozvoj komplexu modelov je posudzovaný: strategický model cieľového modelu, organizačného a funkčného modelu, funkčného technologického modelu, modelu procesu kvantitatívneho modelu, model dátovej štruktúry (v čom formulár HOA a objekty vonkajšieho prostredia sú popísané), obchodné procesy

Na základe priradenia informačného systému, ktorý sa vyvíja, navrhneme ďalej modulárnu štruktúru aplikácie. Na určenie modulárnej štruktúry používame diagram komponentov notácií UML 2.0 (Obr. 3.4).

Obr. 3.4.

Informačný systém pozostáva z troch zložiek:

• 1. Rozhranie. Implementácia interakcie používateľa s informačným systémom. Obsahuje nasledujúce moduly:
  • · Úvod / výstup - organizácia vstupu a odobratie informácií pri práci s IP;
  • · Podávanie správ je organizácia podávania správ v súlade so zavedenými formami dokumentácie v rôznych oblastiach personálnej agentúry;
  • · Vyhľadávanie - Organizácia vyhľadávania kandidátov a voľných pracovných miest pre zadané parametre;
• 2. Spracovanie údajov. Implementácia funkcií spracovania informácií: hľadanie údajov v databáze, matematický model pre úlohu primárnej analýzy dokumentov atď.;
• 3. DB. Implementácia dátového skladu obsahujúceho informácie o zákazníkoch.

Vývoj štruktúry databázy

Ako už bolo uvedené, v informačnom systéme sú všetky informácie uložené v jednej databáze. Na simuláciu logickej štruktúry databázy bola použitá metodika IDEF1X. Podľa tejto metodiky proces budovania informačného modelu pozostáva z nasledujúcich krokov:

• · Definícia subjektov; Stanovenie medzi subjektmi medzi subjektmi;
• · Nastavenie primárnych a alternatívnych kľúčov;
• · Stanovenie atribútov subjektov;
• · Určenie modelu na požadovanú úroveň normálnej formy;
• · Prechod na fyzický opis modelu: Účel korešpondencie Názov účtovnej jednotky je názov tabuľky, atribút subjektu - atribút tabuľky;
• · Nastavenie spúšťačov, postupov a obmedzení;
• · Generovanie databázy.

Diagram Essence-Bond opisujúci databázu v termínoch IDEF1.x je postavený z troch hlavných blokov - entít, atribútov a pripojení. Ak zvážime graf ako grafické zastúpenie ustanovení oblasti predmetu, subjekty a atribúty sú podstatné mená a odkazy sú slovesá.

Keďže budúcnosť ICS v tejto databáze budú vyhľadávať, ako hlavné atribúty pre dokument sa vyberie nasledovné:

• - názov dokumentu;
• - Dátum prijatia dokumentu do archívu (advokátske kancelárie, ktoré vykonávajú archívne služby, nasledujú doby skladovania dokumentácie. Každý dokument má svoj vlastný sklad. Mnohé cenné papiere strácajú svoj význam časom a ich hodnota sa znižuje na nulu. Takéto dokumenty by mali byť zničené. Včasný výber takýchto dokumentov a zničenie dokumentov je zahrnutý v balíku archívnych služieb poskytovaných advokátskou kanceláriou. Pri ukladaní každého dokumentu po vykonaní osobitného vyšetrenia, skladovateľnosti je určený. Po tomto období sa dokument podáva na zničenie);
• - príslušenstvo (typ) dokumentu (pretože všetky dokumenty boli rozdelené do 7 druhov, pre ktoré je dôležitý poradie);
• - stĺpec;
• - číslo pluk;
• - číslo Salazki (tieto 3 parametre sú potrebné na určenie umiestnenia dokumentu v archíve);
• - Prítomnosť dokumentu vo svojej bunke (potrebujete poznať dokument v archíve, alebo je vydaný priateľovi).

Výsledok žiadosti o výber všetkých dokumentov patriacich jednému klientovi by mali vyzerať takto. Obrázok 3.5. V predloženom príklade bol počet dokumentov určený na 20.

Teraz podrobnejšie zvážte logický dátový model vyvinutého informačného systému zobrazeného na obrázku 3.6.

Obr. 3.5

Obr. 3.6.

Z uvedeného dátového modelu je zrejmé, že obsahuje tri subjekty s jeho súborom atribútov, a dvaja z nich sú závislé, a jeden nie je.

Zamestnanecká podstata, ktorá je nezávislým subjektom, má atribúty:

• · Identifikačné číslo zamestnanca - je hlavným kľúčom tohto subjektu;
• · CELÉ MENO;
• · Oblasť špecializácie;
• · Hodnotenie;
• · Ďalšie informácie.

Podstatou "klienta" je závislá podstata od subjektu "zamestnanca", ktorá naznačuje, že každý zamestnanec môže slúžiť veľa zákazníkov. Podstata klienta má atribúty:

• · Séria a číslo pasu - je primárnym kľúčom tohto subjektu;
• · Identifikačné číslo zamestnancov - je sekundárnym kľúčom tohto subjektu;
• · CELÉ MENO;
• · Oblasť špecializácie;
• · Hodnotenie;
• · Ďalšie informácie.

Účtovná jednotka "Dokument" je závislá podstata z účtovnej jednotky "Klient", ktorá označuje, že každý klient môže v archíve ukladať mnoho rôznych dokumentov. Dokument Essence má atribúty:

• · Identifikátor dokumentu je primárnym kľúčom tohto subjektu;
• · Séria a číslo pasu - je sekundárnym kľúčom tohto subjektu;
• · Názov dokumentu;
• · Dátum prijatia;
• · Patrí do skupiny;
• · Číslo stĺpca;
• · Číslo police;
• · Číslo návratnosti;
• · Prítomnosť dokumentu v bunke.

Vytvorené z rôznych modulov informačný systém Umožnil Nižný Novgorod Automobile Plant "Chaika-Service" realizovať myšlienku výroby, čo je najviac plne zohľadní želania zákazníkov, ktorí umiestnili svoje objednávky v podniku

Informačný systém vytvorený z rôznych modulov umožnil Nižný Novgorod Automobile Plant "Chaika-Service" realizovať myšlienku výroby, čo je najviac plne zohľadní želania zákazníkov, ktorí vložili svoje objednávky v podniku

Hlavnou úlohou IT služby spoločnosti, vedúceho podnikania v aktuálnom ťažkom čase, je znížiť náklady na IT a poskytnúť nástroje vodcovstva, ktoré pomôžu úspešne prekonať skúšku krízy. Takže Alexey Gharan, vedúci IT oddelenia Nižný Nižný Novgorod Automobile Plant "Chaika-Service", ktorá sa špecializuje na výrobu sériových a jedinečných autofechnikov.

Spoločnosť Burly v roku 2006, keď sa získal vlastníctvo starého závodu a začal sa rozvoj druhého územia. Samozrejme, úlohou kombinácie oboch území na jedno informačné pole. Začali sme s vytvorením siete VPN, ale keď sa počet užívateľov zvýšil, šírka pásma kanála nebola zmeškaná. Potom bol medzi týmito dvoma územiami položený optický kábel.

S nástupom krízy sa znížila potreba sieťových zdrojov, čo umožnilo znížiť obstarávanie aktívnych zariadení pre telekomunikačnú infraštruktúru podniku. Ďalším významným zdrojom znižovania nákladov bolo odmietnutie outsourcingu a implementácie IT úlohy na vlastných silách.

Okrem toho spoločnosť optimalizuje internetové náklady, analýzy a obmedzuje prietok dopravy. Spoločnosť má pobočky v Krasnodar a Moskve, všetky stránky sú kombinované do IP siete s jedným číslom. A teraz to je táto interná sieť pre hovory v rámci podniku, čo je výrazne ekonomickejšie ako hovory telefonickou komunikáciou na diaľku.

Z nástrojov, ktoré sa čoskoro poskytnú vedúcemu postaveniu, Ganin zvaný predovšetkým systém na výpočet nákladov. Už bola vyvinutá a bude slúžiť ako všeobecný globálny cieľ - zníženie nákladov. Rafinovaný výpočet nákladov na výrobky sa plánuje na základe systému inžinierskych dát. To poskytne podrobné a prevádzkové informácie o nákladoch (predtým boli vypočítané na základe účtovných údajov). Spoločnosť vyrába dostatočne zložité výrobky, len konečné verzie vozidiel s rôznymi modifikáciami sú asi jeden a pol tisíc. Samozrejme, podrobnosti, z ktorých ide, dva rády väčšie.

Z účtovníctva - na výrobu

Prvým krokom na ceste automatizácie bola akvizícia v roku 2002 produktu "1c: účtovníctvo 6.0" a CAPR systém "Compass" ASKON. Ďalším krokom bola automatizácia výrobných činností. Spoločnosť "RARUS NN" na žiadosť podniku začala adaptáciu ERP systému "1C: Riadenie výrobného podniku 8" ("1c: UPP 8") na potreby a zvláštnosti podniku. Účelom projektu bolo vybudovať jednu databázu a implementáciu riadenia všetkých obchodných procesov na základe jednotného informačného systému. Rozhodujúcim faktorom úspechu v jeho realizácii bol okamžitá podpora Najvyššieho vedenia podniku - generálneho riaditeľa, ktorý začal a podporoval projekt vo všetkých jej etapách.

Pri automatizácii výrobných činností sa osobitná pozornosť venovala primeranosti displeja v systéme výrobného procesu. Špecialisti implementačného tímu vyvinuli technickú úlohu s podrobným popisom, ktorý by mal klient dostať a čo je potrebné pre každú objednávku. Dokument bol uzavretý do typu vozidla, jeho modelu, zoznam požadovaných technologických operácií, ich poradie, zoznam riadiacich operácií atď. Tento prístup umožnil, aby spoločnosť viac orientovaná na zákazníka, pretože technické úlohy boli tvorené manažérmi obchodného oddelenia, ktoré sa snažili maximalizovať želania Klienta, a potom sa úlohy prišli do výroby.

IT oddelení špecialisti spolu s technológmi vyvinuli blok špecifikácií priemyselných a technologických máp. Na ich základe a na základe mesačného plánu na výrobu hotových výrobkov bola potreba materiálov určená na určité obdobie, pričom zohľadnili súčasné zvyšky. To všetko umožnené kompetentne plánovať prácu oddelenia dodávok.

Zamestnanci IT oddelenia vyvinuli modul pre "1c: UPP 8" na importovanie "dreva" výrobkov z kompasu systému, ktoré používajú podnikový dizajnéri. Pracovný algoritmus sa ukázal na nasledujúce: Dizajnová kancelária "Compass" vyvíja výkres a vytvorí 3D model objektu, potom sa štruktúra produktu pomocou vyvinutého modulu dováža do systému ERP, po ktorom špecifikácia produktu je založený na importovaných údajoch. Ak dizajnéri vykonajú zmeny v ľubovoľnom uzle, tieto zmeny sa automaticky zobrazia vo všetkých systémoch.

Spočiatku, keďže Ganin priznal, on a jeho špecialisti chceli vytvoriť systém inžinierskych dát na vlastnú päsť, ale čoskoro zistili, že skupina spoločnosti ApPIUS, partner "1c", vyvíja svoje vlastné replikovateľné riešenie PDM (IT Názov "1c: PDM Management Inžinierske údaje").

Spätná väzba

Ďalšou úlohou bolo získať prevádzkovú spätnú väzbu z výroby, je dôležité, pretože výrobný cyklus výrobku môže zaberať jeden alebo dva týždne. Predtým bol stav objednávky viditeľný jednoducho telefonicky, teraz sa príslušné informácie získajú prostredníctvom informačného systému.

Prvým krokom v tomto smere bol vývoj systému na monitorovanie stavu technického zadania. Niektoré výrobné procesy boli zmenené, najmä dôstojníci SC povinní absolvovať správy o práci, ktorú prijal prevádzkovateľ, a vstúpil do údajov o nich v systéme ERP. Výsledkom je, že systém začal prejavovať priechod výrobnej objednávky v etapách s uvedením zodpovedných osôb, čo umožnilo manažérom poskytovať zákazníkom skutočné informácie o tom, akú etapu sú a kedy sú pripravené.

Ďalším krokom bolo zavedenie modulu plánovania výroby. Predtým sa plánovanie uskutočnilo pomocou programu Excel, nepríjemné, často sa vyskytli chyby. Po získaní ERP-Module plánovania výroby majú manažéri k dispozícii skutočné údaje vytvorené na základe prijatých technických úloh. To umožnilo rýchlo monitorovať nakladanie každej stránky. V dôsledku toho sa zvýšila presnosť a efektívnosť plánovania výroby.

Čoskoro došlo k potrebe operačných informácií o stave výrobných procesov, najmä o prestojoch. Ak chcete vyriešiť tento problém, implementoval som systém, ktorý vám umožní sledovať priebeh výrobných procesov založených na čiarových kódovaní: Každá technologická prevádzka, každá technická úloha a každý zamestnanec pridelil svoj čiarový kód, nainštalované terminály vybavené skenerom čiarového kódu.

Výrobný proces je teraz postavený nasledovne. Pred začatím práce sa brigadier alebo pracovník približuje k terminálu, číta jej čiarový kód, čiarový kód technickej úlohy a technologickej prevádzky. Z hľadiska systému to znamená, že zamestnanec začal pracovať. Po jeho dokončení, zamestnanec opakuje svoje akcie s čiarovým kódom.

"Toto je univerzálne riešenie, okrem toho nevyžaduje prácu počítačovej gramotnosti, - Ganin poznámky. "Auto je hlavnou a najdrahšou zložkou našej produkcie, zníženie prestojov umožnilo prudko urýchliť vykonanie objednávok." Spoločnosť má pohodlnú a jednoduchú stratu analýzu nástroj: Systémové práce sú automaticky generované v systéme pre každé vozidlo, čo umožňuje sledovať, keď sa práca začala na tomto aute, keď skončila, koľko času sa vozidlo stačí čakať na inú operáciu. Ak je prekročený povolený čas, príčiny príčiny a vyhľadávanie páchateľov takýchto dlhých prestojov. V dôsledku toho sa zlepšila osobná zodpovednosť výkonných umelcov.

Na základe "1c: UPP 8" Enterprise špecialisti implementovali jednotku blokovania blokov pre konštrukčnú kanceláriu. Technické úlohy vytvorené v systéme prichádzajú do hlavného dizajnéra, analyzuje ich, rozdeľuje ich ich dizajnérom prostredníctvom svojich dizajnérov a určujú čas pre každú úlohu. Takáto organizácia práce dáva hlavnému dizajnérovi a manažérom, ktorí tvoria základ objednávok, schopnosť sledovať stupeň pracovného zaťaženia dizajnu predsedníctva, a to zase, vám umožní porovnať výrobu výroby a dizajnérov a racionálne prideliť existujúce ľudské a výrobné zdroje.

Údaje o vykonanej práci, získané čiarovými kódmi, zadajte výpočtovú jednotku platu exekútorov. Systém zaznamenáva čas práce, uľahčuje výpočet výstupu a nadčas. To všetko prispieva k rýchlej a presnej mzde.

Je dôležité zdôrazniť, že spoločnosť šla po trase expanznej dráhy

Základná konfigurácia systému ERP s ďalšími blokmi bez zmeny svojej vnútornej štruktúry. To bolo možné najmä vykonávať svoje aktualizácie bez problémov.

Ak chcete riadiť archív dizajnovej dokumentácie v podniku zaviedol systém "1c: PDM inžinierske údaje" (vývoj APPIUS GK) a integrovalo ho s "1C: UPP 8". Okrem vytvárania nových produktov sa plánuje systém inžinierstva dát, ktorý je potrebné použiť na presnejšie výpočet nákladov na výrobky.

Viacnásobná integrácia

Podnik zaviedol GPS navigáciu na dodávku dodávok a úžitkových vozidiel, ktoré sa pohybujú na dlhé vzdialenosti. To vám umožní optimalizovať trasy, znížiť náklady na palivo, jasnejšie odolať disciplíne dodávok.

"Chaika-Service" plánuje priradiť na videokonferenčnom systéme v jednej sieti všetky pobočky - dva v Nižnom Novgorode a jednej v Moskve, Krasnodar a Naberezhnye Chelny. Zlepšuje sa teda efektívnosť rozhodovania top riadenia a finančné a dočasné obchodné náklady výrazne znížia.

"Plánujeme tiež zaviesť rozhodnutie založené na" 1c: UKP 8 ", aby ste spolupracovali s dopravnou políciou, príprava a tlačou TCP, TRANSITOVÝCH ČÍSLA, - GANINOVÉ POZNÁMKY. - Všetky údaje budú zoskupené v jednom úložnom mieste informácií - kartou kariet, kde budú zadané všetky svoje identifikačné čísla, farby, číslo tela atď, potom budú tieto údaje použité v technickej úlohe, pri tlači PTS, Čísla, certifikáty, účty " Takáto integrácia poskytne zákazníkom podniku príležitosť, aby sa pripravil tcp a tranzitné čísla spolu s autom, vďaka čomu bude možné zvýšiť autá do úvahy v dopravnej polícii.