Úvod

Uvažovaná 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 s nástupom 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 predovšetkým 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é \u200b\u200bproduktyktoré automatizujú informačné a výpočtové procesy. Zahŕňajú tiež výpočtové zariadenia, komunikácie, kancelárske vybavenie a š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 obchodu.

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ícke produkty

¾ 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. Takéto systémy kontrolujú a zodpovedajú za materiály a spracúvajú prijaté informácie.

„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 bezpečnosť informácií 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 modelovanie, ktorý vám umožňuje analyzovať, dokumentovať a plánovať zmeny 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), potom 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 atď., 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ý vám 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 tomto prípade sú šípky rozdelené podľa toho, do ktorej strany pracovného obdĺžnika vstupujú alebo do ktorej odchádzajú, 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é vybudovať kontext „Skladové činnosti podniku“ (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 rozdelený na podsystémy na požadovanú úroveň podrobností, 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 ich možno načítať, 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 byť prepojený 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 toky informácií, 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 je uvažovaná na príklade Doneckej manufaktúry 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 zhromaždení, nedostatkom a prebytkom

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 riadiacimi štruktúrami dizajnérskych podnikov počas celej životnosti podniku. Tento proces nie je možné 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 implementácii 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 so špecifikáciou systémových požiadaviek.

Na implementáciu procesu automatizácie účtovníctva a kontroly materiálov je to nevyhnutné informačný systém môže spĺňať 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;

Špecifikácia požiadaviek a tvorba 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ť. Špecifikácia softvérových požiadaviek (SRS) je ústrednou súčasťou celého životného cyklu vývoja softvéru. 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 mieru 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 skutočný vývoj projektu. To znižuje pravdepodobnosť následného opätovného návrhu, 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 na schválenie odhadu návrhu alebo ceny používa SRS.

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é vykonať validáciu požiadaviek.

Š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 prevádzky.

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 validácii 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 rozvoju 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 disku pokračuje na konkrétne postupy. Automatizovaný systém 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ľ a panuj - princíp riešenia ťažké problémy ich rozdelením na mnoho menších nezávislých problémov, ktorým je ľahké porozumieť a vyriešiť ich;

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.

Štrukturálna analýza využíva hlavne dve skupiny nástrojov na ilustráciu funkcií vykonávaných systémom a vzťahov 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ú diagrammi, ktoré odrážajú štruktúru softvéru: softvérová architektúra, štrukturálne diagramy programy a diagramy formulárov na obrazovke.

Uvedené modely spolu dávajú celý popis 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 pochopenie systému definovaním jeho funkčnosti a štruktúry 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, ako informačné systémy, aplikácie a ľudia pracujú v celej organizácii jednotným a jednotným spôsobom.

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é prvky“ 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ť odhadnúť harmonogram a rozpočet projektu. To si vyžaduje zodpovednosť architektov moderných informačných systémov za vytvorenie uspokojivého a funkč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 dostatočne 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ď veľa používateľov pristupuje k rovnakým údajom súčasne, pracovný výkon prudko klesá, pretože je potrebné počkať, kým užívateľ pracujúci s údajmi nedokončí 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 zabrániť 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 populárnou. 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;

zníženie straty produktivity zamestnancov počas implementácie systému a rýchlejšie zotavenie zo straty produktivity;

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 sa vykonáva kompletná správa informačného systému, 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ť úplné 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 pre príchod tovaru prebieha registrácia tovaru 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íjmu alebo príjmu do skladu.

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 veľkú obľubu 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ť grafický model E-R (objektový vzťah), ktorý spĺňa všetky požiadavky na údaje, a zadať obchodné pravidlá, aby ste vytvorili logický model, ktorý zobrazuje 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 dané oblasti. 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, v skutočnosti ide o displej systémový adresár... 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 na fyzickej úrovni modelu je 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 na 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é ich 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é zobrazenia (Views), pripojenia k serveru, uložené procedúry vykonávané pri viac ako 50 odlišné typy udalosti (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 založené na technológii „klient-server“ s údajmi umiestnenými na databázových serveroch Oracle a Microsoft SQL Server a ďalších aplikácie spoločnosti Microsoft Windows pomocou ODBC a OLE

Systém VFP je určený na použitie profesionálnymi programátormi, preto nemá zmysel v rusifikácii jeho ponuky a jazyka - 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. Konateľ 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, správca po otvorení formulára Príchod spôsobí vykonanie niekoľkých akcií - automaticky (z pohľadu manažéra) sa vyplní dátum žiadosti. Pri umiestňovaní aplikácie sa zoznam klientov vyplňuje zo základne 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 zreteľne a správne integrované. Zatiaľ neexistujú žiadne 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. V tlačidle ponuky „zvyšky“ sú uložené informácie o materiáloch uložených v sklade skladu.

6. Tlačidlo menu pokladne ukladá informácie o prichádzajúcich 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 prepusteného tovaru.

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.

Na vstupe do testovacieho procesu 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 testov sa začína 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) vám umožňuje získať kombinácie vstupných údajov, ktoré poskytujú úplnú kontrolu všetkých funkčných požiadaviek 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 kód v podstate všetok zdrojový kód vytvorený 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 bude skontrolovaná 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.

Testovanie dokumentácie a 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.

Pilotný operačný plán 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 experimentálneho 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, pomoc 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 databázy znalostí o projekte 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 je potrebný operačný systém Microsoft WindowsXP.

4 Informačný projektový manažment

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

Jedným zo základných konceptov metodiky 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, ktorý reguluje ž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 (vo fázach 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 sa hotový výrobok zavádza 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 každú kategóriu zvýraznením 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 skôr, ako sa vyberie model životného cyklu vývoja softvéru. Charakteristika takého 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, potom musí vývojár poznať tieto zmeny a spôsob, ako tieto zmeny v softvéri predstaviť.

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

Vyvinutý softvérový produkt na účtovanie tovaru v sklade automatizuje proces príjmu, štruktúrovania a ukladania údajov o tovare v sklade, ako aj zjednoduší 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 Vytvorenie štruktúry pre operatívny pracovný zoznam

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 môžete 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. Určenie rozsahu projektových prác sa začína definovaním etáp (alebo fáz) projektu. Napríklad v projekte vytvorenia systému „Účtovanie tovaru na sklade“ možno rozlíšiť 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 v akých termínoch musíte byť dodržaní, 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 programe MS Project je Ganttov diagram hlavný vizualizačný nástroj pre plán projektu. Tento graf je grafom s horizontálnou časovou osou a vertikálnym zoznamom úloh. Ďalej je dĺžka segmentov označujúcich úlohy úmerná dĺžke trvania úloh.

Na Ganttovom grafe sa môžu zobraziť ďalšie pruhy Ďalšie informácie (vedľa úloh sú zobrazené názvy zdrojov, ktoré sa na nich podieľajú, 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á časová miera (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

Ku každej práci vykonanej v projekte je priradený zdroj, ktorý bude túto prácu vykonávať. 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, počas ktorého 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 časového bodu.

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 - diskontná sadzba.

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

NPV je absolútny prírastok, 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

Obrázok: 6.2.

(Podnikový informačný systém)

Outsourcing podnikových informačných systémov

Outsourcing výrobných funkcií a podnikových procesov založený na podnikových informačných systémoch umožňuje využívať najnovšie výdobytky a „najlepšie postupy“ moderného riadenia. Implementácia podnikových informačných systémov je jadrom reinžinieringu obchodných procesov (Obchodný proces...
(Outsourcing a outstaffing: technológie vysokého riadenia)

Integračné vzorce podnikových informačných systémov

Vzory integrácie informačných systémov predstavujú najvyššiu úroveň klasifikácie návrhových vzorov. Podobne ako pri vzoroch nižších stupňov klasifikácie, aj medzi štruktúrnymi vzormi integrácie sa rozlišuje skupina štrukturálnych vzorov. Štrukturálne vzory popisujú hlavné zložky jediného integrovaného ...
(Úvod do softvérovej architektúry)

FUNKČNÉ ÚLOHY INFORMAČNÉHO SYSTÉMU PODNIKU A ZÁKLADNÉ MODULY MODERNÝCH INFORMAČNÝCH SYSTÉMOV PODNIKU. INTEGRÁCIA MODULOV

Zmysluplný význam konceptu modulu predpokladá porovnanie funkčných subsystémov, funkčných úloh v prístupe orientovanom na funkčnosť a úlohu s hlavnými modulmi moderných Obrázok: 6.2. Porovnanie funkčných úloh s hlavnými modulmi moderných informačných systémov ICISP podniku, ...
(Podnikový informačný systém)

KONCEPCIA, HISTÓRIA ROZVOJA A KLASIFIKÁCIA INFORMAČNÝCH SYSTÉMOV PODNIKU. INTEGROVANÉ FIREMNÉ INFORMAČNÉ SYSTÉMY PODNIKU

Koncept a klasifikácia informačných systémov sa v priebehu ich historického vývoja menia. Cieľ však zostáva nemenný a súvisí s dosiahnutím efektívnosti riadenia podniku. Efektívnosť riadenia podniku závisí od vzájomného pôsobenia mnohých faktorov, medzi ktoré patria: filozofické, historické, ...
(Podnikový informačný systém)

VLASTNOSTI MODERNÝCH INFORMAČNÝCH TECHNOLÓGIÍ V INFORMAČNÝCH SYSTÉMOCH PODNIKU

MODERNÉ TECHNOLÓGIE PRE ORGANIZÁCIU VSTUPU ÚDAJOV DO FIREMNÝCH INFORMAČNÝCH SYSTÉMOV Informácie o obchodných transakciách by sa mali do operačnej databázy vkladať včas z akýchkoľvek zdrojov ich pôvodu. Takto sa efektívne zorganizuje ďalšie spracovanie údajov v informáciách ...
(Podnikový informačný systém)

Úvod

1. Analytická časť

1.1 Organizačná štruktúra spoločnosti

2 Analýza softvéru a hardvéru oddelenia zákazníckych služieb a pracovného oddelenia

Projektová časť

2.1 Popis predmetnej oblasti

2 Štúdia uskutočniteľnosti návrhov a metód implementácie

3 Návrh databázy

4 Koncepčný dátový model v štandarde Chen

5 ER diagram v prostredí ERwin

6 Analýza modelu

7 Fáza fyzického návrhu

8 Implementácia základných požiadaviek

Záver

Zoznam informačných zdrojov

Úvod

Mnoho firiem a podnikov vyžaduje služby upratovacích spoločností.

Upratovacia spoločnosť je spoločnosť, ktorá poskytuje komplexné upratovacie služby. Súbor činností určených na čistenie a udržiavanie čistoty v bytových, obchodných a priemyselných priestoroch vrátane činností na čistenie fasád, výkladov umývacích zariadení a iných vonkajších povrchov budov je veľmi zložitý proces, ktorý pozostáva z mnohých rôznych etáp, do ktorých je zapojený veľký počet účastníkov. Účinnosť upratovacej organizácie si vyžaduje jasnú koordináciu činností vo vzťahu k všetkým jej zamestnancom.

Výhodu špecializovaných spoločností určujú nasledujúce faktory:

· Vysoká kvalita služieb;

· Náklady na služby nie sú vyššie ako náklady na údržbu vašej vlastnej upratovacej služby;

· Výdavky na služby upratovacích spoločností sa odpočítavajú od zdaniteľného zisku;

· Špecialisti na čistiace spoločnosti vykonávajú exkluzívne a zložité špecializované práce (napríklad - kryštalizácia mramorových náterov);

· Efektívnosť - čistenie sa vykonáva v čase, keď je to pre zákazníka výhodné.

Čistenie je dnes jedným z najdynamickejšie sa rozvíjajúcich a najstabilnejších obchodných odvetví v Rusku. Čoraz viac spoločností má záujem o kúpu kvalitných a spoľahlivých upratovacích služieb, čo kladie vysoké nároky na kompetentnú a vyváženú prácu s klientmi.

Všetky vyššie uvedené výhody si vyžadujú použitie moderných informačných technológií v práci upratovacích spoločností, ako sú špecializované informačné systémy, napríklad CRM systémy.

Systém riadenia vzťahov so zákazníkmi (CRM, CRM-systém, skratka pre Customer Relationship Management) je aplikačný softvér pre organizácie určený na automatizáciu stratégií interakcie so zákazníkmi (klientmi), najmä na zvýšenie predaja, optimalizáciu marketingu a zlepšenie zákaznícky servis ukladaním informácií o zákazníkoch a histórie vzťahov s nimi, vytváraním a zlepšovaním obchodných procesov a následnou analýzou výsledkov. CRM systém je použiteľný v každom podnikaní, kde je klient personifikovaný, kde existuje vysoká konkurencia a úspech závisí od poskytnutia čo najpriaznivejších podmienok pre klienta - model interakcie, ktorý verí, že centrom celej obchodnej filozofie je klient, a hlavnými oblasťami činnosti sú opatrenia na podporu efektívneho marketingu, predaj a zákaznícky servis. Podpora týchto obchodných cieľov zahŕňa zhromažďovanie, ukladanie a analýzu informácií o zákazníkoch, dodávateľoch, partneroch, ako aj o interných procesoch spoločnosti. Medzi funkcie na podporu týchto obchodných cieľov patrí predaj, marketing, podpora zákazníkov.

„Srdcom“ každého systému CRM je databáza jednotlivcov aj právnických osôb, ktoré interagujú s vašou spoločnosťou v rámci podniku. Nie sú to len zákazníci, ale aj pobočky spoločnosti, partneri, dodávatelia, konkurenti. Databáza zákazníkov je sama o sebe cenným majetkom a inteligentná správa údajov v systéme CRM vám umožňuje využívať informácie pri svojej práci s maximálnou efektivitou. Zákaznícka základňa je konsolidovaná, organizácia dostáva úplné informácie o svojich zákazníkoch a ich preferenciách a na základe týchto informácií buduje komunikačnú stratégiu.

Jednotná databáza zákazníkov a úplná história vzťahov s nimi, kombinovaná s výkonnými analytickými nástrojmi CRM, vám umožňuje udržať a rozvíjať existujúcich zákazníkov, identifikovať tých najcennejších a prilákať nových zákazníkov.

Hlavnou funkciou systému CRM je pomáhať manažérom plánovať predaj, organizovať transparentné riadenie obchodov a optimalizovať predajné kanály. Systém ukladá kompletnú históriu komunikácie so zákazníkmi, ktorá pomáha obchodným oddeleniam analyzovať správanie zákazníkov, formulovať ponuky, ktoré sú pre nich vhodné, a získať lojalitu. Zvyšok schopností systémov CRM je uvedený nižšie:

· Plánovanie a koordinácia kontaktov s klientmi;

· Zhromažďovanie a písanie všetkých možných informácií o zákazníkoch;

· Kontrola nad dlhodobými alebo zložitými transakciami;

· Analýza každej etapy implementácie projektu alebo uzavretia transakcií;

· Formalizácia všetkých procesov zameraných na interakciu so zákazníkmi.

Tento typ softvéru je najvhodnejší pre tie organizácie, ktoré realizujú dlhodobé a viacstupňové projekty, ktoré zahŕňajú veľký počet zamestnancov alebo niekoľko oddelení. Keďže počet uzavretých zmlúv za časovú jednotku je malý, každá transakcia trvá mnoho dní, ba až mesiacov. To znamená, že každý projekt si vyžaduje výlučne individuálny prístup. Za takýchto podmienok je potrebné dbať na lojalitu zákazníkov. K tomu je potrebné nielen zabezpečiť individuálny prístup, ale aj dôsledne dodržiavať stanovené termíny, podmienky zmluvy, ako aj koordinovanú prácu a dochvíľnosť všetkých zúčastnených zamestnancov.

1. Analytická časť

Skupina spoločností "MAKS" bola založená v roku 2000. Hlavnou činnosťou je multidisciplinárny komplexný sektor služieb. Od založenia skupiny spoločností MAKS sa rozsah ponúkaných služieb neustále rozširuje. Skupina spoločností MAKS dnes ponúka tieto typy služieb (obr. 1):

· Bezpečnosť objektov, tímy rýchlej reakcie, bezpečnosť velína, súkromné \u200b\u200bdetektívne služby;

· Zaistenie čo najefektívnejšej a nepretržitej prevádzky spravovaných nehnuteľností;

· Predbežná analýza existujúcich bezpečnostných systémov;

· Komplexné čistenie priestorov.

Obrázok: 1. Oblasti služieb skupiny MAKS

„MAX OCHRANA“ vyvinutá spolu so sférou neštátnej bezpečnosti. Zabezpečenie objektov, tímy rýchlej reakcie, bezpečnosť velínu, súkromné \u200b\u200bdetektívne služby, to všetko je súčasťou štandardného balíka služieb. Oddelenie zamestnáva špecialistov na IT infraštruktúru, ktorí sa podieľajú na núdzovej pomoci cudzincom a poznajú všetky nuansy sprevádzania tovaru a cenných vecí.

Prax ukazuje, že bezpečnosť nie sú len strážcovia v uniformách, ale celá škála opatrení zameraných na prevenciu a prevenciu pred potenciálnymi hrozbami. Tieto opatrenia sú súčasťou integrovaného bezpečnostného systému „MAX PROTECTION“, ktorý vyvinuli odborníci s dlhoročnými skúsenosťami.

Pre zákazníkov znamená integrovaný prístup k bezpečnosti komunikáciu so všetkými bezpečnostnými službami prostredníctvom jedného dodávateľa. Spoločnosť odstraňuje potrebu, aby zákazníci koordinovali prácu niekoľkých neprepojených organizácií. Prítomnosť jediného operačného strediska vám umožňuje okamžite a efektívne reagovať na akékoľvek núdzové situácie.

Spoločnosť „MAKS PROKHRANA“ neustále zdokonaľuje a vyvíja nové koncepty bezpečnosti. Do našej práce zavádzame pokrokové zahraničné technológie a vyvíjame vlastné riešenia pre konkrétne úlohy. Avšak ani tie najpokročilejšie automatizované bezpečnostné systémy nemôžu človeka úplne nahradiť. Preto sa osobitná pozornosť venuje zvyšovaniu profesionality pracovníkov „MAX OCHRANY“. Špecialisti pravidelne navštevujú udržiavacie kurzy a ich úroveň školenia sa testuje počas interných auditov. Prísny výber personálu umožňuje minimalizovať vplyv ľudského faktora na služby „MAX OCHRANY“.

Tím manažmentu spoločnosti „MAX PROTECTION“ je zameraný na individuálny prístup ku klientom. Odborníci vykonávajú viacúrovňovú analýzu a na základe jej výsledkov ponúkajú najefektívnejšie riešenia na zaistenie bezpečnosti klienta. Rozsah činnosti „MAX OCHRANY“ sa zároveň neobmedzuje na súkromných klientov. Zamestnanci sú oboznámení s ochranou verejných zariadení a v tejto oblasti sa osvedčili.

Prístup divízie k integrovaným bezpečnostným službám nemá obdoby a zaručuje maximálnu efektivitu v každej situácii.

Divízia MAKS Ekspluatatsiya pôsobí na trhu už viac ako desať rokov. Hlavnou úlohou je zabezpečiť čo najefektívnejšiu a neprerušovanú prevádzku obsluhovaných nehnuteľností. Zároveň nehrá rolu premlčacia doba uvedenia zariadenia do prevádzky a význam úrovne zložitosti zariadenia.

Komplexná služba ponúkaná spoločnosťou MAKS OPERATION zahŕňa technickú podporu pre zariadenia a inžinierske systémy, ako aj bezpečnostné návrhy. Tento zoznam obsahuje údržbu a ďalšie plánované a neplánované práce; návrh a inštalácia požiarnych poplachových a kamerových systémov, ako aj celý rad opravárenských a stavebných služieb. Klienti „MAKS EKSPLUATATSIYA“ dostávajú kompletný balík služieb od jedného dodávateľa, čo môže výrazne znížiť náklady a uľahčiť interakciu medzi službami.

Špecialisti tohto oddelenia sú vždy pripravení ponúknuť niekoľko možností práce s objektom v závislosti od jeho špecifík a želaní klienta. Individuálny prístup umožňuje zákazníkovi rátať s úplným vzájomným porozumením so zhotoviteľom a vo výsledku dosiahnuť výsledok najvyššej kvality.

V modernom svete je vybavenie a vybavenie moderných budov čoraz rozmanitejšie a zložitejšie. Hlavným cieľom tejto divízie je poskytovať komplexné služby správy budov. Všetci zamestnanci chápu najmodernejšie výdobytky vedy a techniky a používajú ich v súlade s odporúčaniami a normami výrobcov. To je jediný spôsob, ako zabezpečiť, aby sa výkon a bezpečnosť objektu akejkoľvek zložitosti udržiavala na správnej úrovni.

Divízia MAX CONSULTING sa už viac ako 10 rokov venuje poradenstvu a auditu v oblasti bezpečnosti. Hlavnou úlohou oddelenia je komplexná analýza situácie, ako aj nesprávny výpočet vyhliadok na rozvoj s prihliadnutím na existujúce problémy spoločnosti, ako aj na individuálne charakteristiky podnikania.

Zamestnanci spoločnosti „MAX CONSULTING“ vykonávajú predbežnú analýzu existujúcich bezpečnostných systémov. Prirodzene, tieto práce sa vykonávajú v úzkej spolupráci so zamestnancami zákazníka, ktorí ich budú aktualizovať a pomôžu zohľadniť všetky funkcie.

Audit aktivít spoločnosti vykonávajú vysoko kvalifikovaní odborníci, ktorí nielenže dokážu identifikovať kritické body v už používanom systéme, ale aj ponúknuť spôsoby ich eliminácie. Všetci konzultanti naraz pôsobili v orgánoch činných v trestnom konaní a majú významné skúsenosti v Rusku aj v zahraničí.

Špecialisti spoločnosti „MAX CONSULTING“ tiež poskytujú pomoc pri odstraňovaní krízových situácií, zvyšovaní efektívnosti obchodných procesov a efektívnom riadení informačných systémov a IT rizík spoločnosti.

Konzultanti oddelenia si dali za úlohu budovať obojstranne výhodné vzťahy, aby bolo možné s klientom dlhodobo spolupracovať. „MAX CONSULTING“ ponúka svojim klientom audítorské služby, právne služby v oblasti trestného, \u200b\u200bpracovného, \u200b\u200bdaňového a iných druhov práva.

Rozsahom služieb poskytovaných spoločnosťou MAX CLEANING je čistenie priestorov. V Rusku boli prvé čistiace spoločnosti založené v rokoch 1992-1994. spolu so vznikom prvých spoločných podnikov, ktoré boli v tom čase jedinými spotrebiteľmi ich služieb. V priebehu roku 2012 predstavoval nárast objemu trhu s upratovacími službami v Rusku v peňažnom vyjadrení asi 9 miliárd rubľov - v roku 2011 to bol objem 45 miliárd rubľov a do konca roku 2012 ich trh s čistením odhadli na 54 miliárd rubľov. Počas minulého roka 2014 sa objem ruského trhu s upratovacími službami podľa analytikov zvýšil o približne 10 - 11 miliárd rubľov a na konci minulého roka dosiahol zhruba 65 miliárd rubľov.

Medzi najväčšie regióny na poskytovanie upratovacích služieb patria Moskva, Krasnojarské územie, Ťumeňský kraj, Baškirská republika, Petrohrad, autonómny okruh Chanty-Mansij. Moskva predstavuje 100 - 150 miliónov dolárov na domácom trhu s upratovaním.

Podľa odborníkov pôsobí na kapitálovom trhu viac ako 300 čistiacich spoločností. Podľa veľkosti podniku ich možno zhruba rozdeliť do 4 veľkých kategórií.

· Najväčší operátori (viac ako 500 zamestnancov) ~ 67%;

· Veľkí operátori (počet zamestnancov do 500 osôb) ~ 15%;

· Strední operátori (počet zamestnancov do 200 osôb) ~ 7%;

· Malí operátori (počet zamestnancov do 50 osôb) ~ 11%.

Rozsah štandardných služieb, ktoré poskytujú takmer všetci hráči na trhu, zahŕňa každodenné komplexné čistenie a umývanie zvislých povrchov. Ďalej asi 93% všetkých upratovacích spoločností ponúka služby na brúsenie a leštenie žuly, mramoru, porcelánového kameniny a keramických dlaždíc, ako aj čistenie okolia a špecializované upratovacie služby po stavebných prácach a požiaroch. Asi 87% spoločností zúčastňujúcich sa na štúdii poskytuje ďalšie služby a personál, napríklad baliarne, nakladače a ďalšie, a 80% účastníkov trhu s upratovacími službami poskytuje svojim klientom služby ekologizácie pre priľahlé a vnútorné územia, odvoz odpadu a snehu. Hlavnými klientmi upratovacích spoločností sú supermarkety a nákupné centrá, výrobné podniky, dopravné a skladové spoločnosti, lekárske a športové inštitúcie, kancelárske a obchodné centrá, veľké medzinárodné a ruské spoločnosti, banky, vládne agentúry, hotelové komplexy, zábavné zariadenia (kiná, kluby) , kasíno), vlakové stanice a letiská.

Obrázok: 2. Segmentácia spotrebiteľov upratovacích služieb

Podľa mnohých štúdií je najviac zaostávajúcim segmentom trhu čistenie v zdravotníckych zariadeniach. Tento stav sa vysvetľuje zavedenými zvykmi, prísnejšími normami, ktoré v takýchto organizáciách existujú, a osobitnými požiadavkami, ktoré používajú na čistenie vykonávané zamestnancami upratovacej spoločnosti.

Kritériá pre výber upratovacej spoločnosti sú: autorita na trhu, náklady a rozsah poskytovaných služieb, úroveň vybavenia, technológií a chemikálií použitých pri práci, kvalifikácia personálu a systém kontroly čistenia.

Upratovanie priestorov je v modernom obchodnom svete priemyselnou nevyhnutnosťou. Denné upratovanie na základe zmluvy je pomerne rozvinutou oblasťou tejto spoločnosti. Schopnosť objednať si jednorazové upratovanie a vypracovať zmluvu na upratovanie priestorov s pevnou frekvenciou a s pohodlným harmonogramom práce pre klienta je dnes veľmi častá činnosť, ktorá si vyžaduje veľké množstvo údajov a je najvhodnejšia pre príklad návrhu informačného systému. Zamestnanci spoločnosti venujú veľkú pozornosť kontrole a kvalite vykonávaného čistenia. Otvorenosť je tiež dôležitou súčasťou práce spoločnosti. Klient má právo vedieť, čo, ako a pomocou toho, čo táto spoločnosť „MAX CLEANING“ robí. Všetky chemické výrobky majú hygienické certifikáty, partneri a zákazníci môžu navštíviť výrobnú základňu a zoznámiť sa s technologickými možnosťami a organizáciou práce v podniku.

Upratovanie je moderná a veľmi žiadaná služba poskytovaná rôznymi spoločnosťami špecializujúcimi sa na upratovanie priestorov. Toto čistenie vykonávajú špeciálne vyškolení zamestnanci a je hodnotené podľa vysokých európskych štandardov.

Čistenie sa v Rusku objavilo na začiatku 90. rokov a v prvom rade sa stalo dopytom medzi veľkými západnými spoločnosťami zvyknutými na profesionálne čistenie vo svojej domovine. Táto služba kombinuje celú škálu aktivít určených na čistenie a udržiavanie čistoty v bytových, obchodných a priemyselných priestoroch vrátane aktivít na čistenie fasád, umývanie výkladov a iných vonkajších povrchov budov. Zoznam služieb zvyčajne zahŕňa aj odvoz odpadkov a snehu zo striech a priľahlých území.

V súčasnosti všetky služby vykonáva kvalifikovaný personál s využitím moderných čistiacich technológií s využitím najnovších nástrojov špeciálne vybraných pre každý povrch zvlášť, s prihliadnutím na jeho fyzikálne, chemické a technické vlastnosti. Ruský trh s čistením sa výrazne rozšíril a má veľké vyhliadky na ďalší vývoj. Po pár desaťročiach ľudia zabudnú, čo je samočistenie, a obrátia sa na spoločnosť, ktorá tieto služby poskytuje. Na čistote miestnosti skutočne záleží nielen samotný vzhľad, ale aj zdravie majiteľa.

Manažéri mnohých veľkých i malých spoločností sa už dokázali ubezpečiť, že čistenie ponúkané špecializovanými spoločnosťami je oveľa kvalitnejšie ako čistenie v obvyklom zmysle. Profesionálne čistenie zahŕňa uvedenie priestorov do bezchybného stavu. Takéto čistenie vám v konečnom dôsledku umožní ušetriť čas, zvýšiť životnosť dokončovacích materiálov a zvýšiť prestíž spoločnosti.

Zamestnanci a manažéri spoločnosti pracujú ako jediný mechanizmus, vysoko oceňujú nielen vysokú kvalitu ponúkaných služieb, ale tiež analyzujú objednané služby, predpovedajú situáciu na trhu služieb a vo výsledku ponúkajú konštruktívne riešenia mimoriadnych situácií a najefektívnejšie riešenia potrieb klienta.

V roku 2003 sa za účelom zlepšenia kvality služieb zákazníkom rozhodlo o otvorení novej divízie, ktorá bude poskytovať ďalšie profesionálne upratovacie služby. Spoločnosť MAKS CLEANING urobila prvé kroky v Moskve. Skúsenosti získané v hlavnom meste sa využili na vstup do regiónov. Aj keď spočiatku bolo problémov dosť, spoločnosť dokázala zvládnuť všetky ťažkosti. V roku 2005 spoločnosť podpísala zmluvu s reťazcom supermarketov METRO a stala sa jednou z prvých spoločností poskytujúcich upratovacie služby pre supermarkety a hypermarkety. Do roku 2010 mala spoločnosť viac ako 400 zamestnancov. Zamestnanci pracujú v zariadeniach v celej Moskve. Do roku 2012 vstupuje MAX CLEANING do oblastí Ruska. Prvé pobočky boli otvorené v Krasnojarsku a Kazani. Kvalita profesionálneho upratovania kancelárií a nákupných centier prevyšuje očakávania regionálnych klientov. Spoločnosť už dosiahla 10. výročie a má 700 zamestnancov. Všetky ďalšie skúsenosti poskytli jedinečné vedomosti v oblasti čistenia.

Reputácia spoločnosti „MAX CLEANING“, ktorá bola založená v posledných rokoch, má veľký význam. Vyžaduje si to zohľadniť prístup každého zo zamestnancov k svojej práci.

Interakcia a komunikácia so zákazníkmi sú základnými ingredienciami úspechu. Je veľmi dôležité viesť evidenciu zmlúv so zákazníkmi, všetkých objednávok zákazníkov, ktoré odrážajú ich potreby.

Flexibilná cenová politika, profesionálna úroveň školení zamestnancov, používanie najrôznejších zariadení a chemikálií nám umožňuje zaujať popredné miesto v tejto oblasti služieb.

Čistiaca spoločnosť poskytuje svoje služby po celej Ruskej federácii. Hlavnou časťou oblasti služieb je centrálna časť Ruskej federácie. Spoločnosť spolupracuje s mnohými veľkými právnickými osobami, ako je to znázornené na obrázku nižšie:

Obrázok: 3. Spoločnosti - klienti spoločnosti „MAX-CLEANING“

.1 Organizačná štruktúra spoločnosti

Spoločnosť MAX CLEANING sa skladá z rôznych divízií, ktoré vykonávajú rôzne funkcie a úlohy, organizačná štruktúra spoločnosti MAX CLEANING je znázornená na obrázku 4.

Obrázok: 4. Organizačná štruktúra

Generálny riaditeľ a jeho zástupca sú zodpovední za spoločnosť MAKS-CLEANING, ktorá sa skladá z mnohých oddelení, vrátane:

· Oddelenie práce s klientmi;

· Katedra prác.

Oddelenie služieb zákazníkom

Rozsah práce s klientmi spoločnosti „MAX-CLEANING“ je rozsiahly: jej hlavnou úlohou je dlhodobá spolupráca a servis právnických osôb, analýza ich potrieb, úrovne a zamerania. Rokovania s klientskými spoločnosťami, oboznámenie sa s podmienkami predaja služieb poskytovaných MAKS-CLEANING, kontrola nad výkonom práce - to všetko je neoddeliteľnou súčasťou práce tohto oddelenia.

Klientská spoločnosť môže kontaktovať spoločnosť „MAX-CLEANING“ a využiť služby komplexného upratovania priestorov. Manažér spoločnosti vám pomôže uzavrieť dohodu o dlhodobej spolupráci alebo zadať jednorazovú objednávku. Je tiež povinný zistiť si od klienta všetky potrebné informácie, a to:

Informácie o spoločnosti, ktorú zastupuje;

Údaje o majetku (objektoch), ktorý vyžaduje komplexné čistenie;

Túžba klienta zvoliť si triedu upratovania;

Podmienky služby;

Špeciálne pripomienky k práci v areáli (Všetky prijaté informácie spracováva manažér a sú prísne dôverné).

V prípade úspešného uzavretia zmluvy alebo objednávky bude výkon služby smerovať na pracovné oddelenie, ktorého funkciou je včasné a kvalitné zabezpečenie (výkon) upratovacích služieb.

Pracovné oddelenie

Toto oddelenie sa skladá z vedúceho majstra a školníkov, ktorí tvoria samostatné tímy. Po prevode zmluvy (objednávky) konateľom spoločnosti na vedúceho majstra nasleduje etapa rozdelenia prác na upratovaní priestorov medzi vedúcich upratovacieho tímu.

Upratovanie priestorov klienta sa vykonáva v stanovených časových rámcoch stanovených v predtým vyhotovenej zmluve (objednávke). Správa o výkone služby sa poskytuje vedúcemu majstrovi, ktorý hodnotí prácu každého upratovača, ktorý je v tíme, ktorý toto čistenie vykonával. Vedúci pracovník sa ďalej zaväzuje informovať správcu účtu o stave tejto objednávky.

Potom si kvalitu práce skontroluje sám klient. V prípade neuspokojivého hodnotenia informuje manažér vedenie spoločnosti o prijatí vhodných rozhodnutí.

V priebehu analýzy aktivít vyššie popísaných oddelení spoločnosti MAKS-CLEANING bol zostavený diagram obchodného procesu, ktorý je uvedený nižšie na obrázku 5.

Obrázok: 5. Obchodný proces „MAX-ČISTENIE“

Obe oddelenia potrebujú rýchly zákaznícky servis a transakcie prostredníctvom automatizácie toku dokumentov, ako aj rýchleho príjmu údajov z prehľadov a analytických informácií, aby mohli poskytovať včasné a kvalitné služby.

1.2 Analýza softvéru a hardvéru oddelenia zákazníckych služieb a pracovného oddelenia

Každý správca účtov má osobný počítač, telefón a rôzne periférne zariadenia na spracovanie potrebných informácií. Spoločnosť má prístup na internet, ku ktorému majú prístup všetci zamestnanci spoločnosti „MAKS-CLEANING“. Všetky počítače majú operačný systém Windows 7, požadovaný balík Microsoft Office, ktorý zahŕňa Access, ako aj ovládače pre prácu s mnohými periférnymi zariadeniami HP DesktJet. Softvér a hardvér oddelenia zákazníckych služieb a pracovného oddelenia je znázornené na obrázku 6.

Obrázok: 6. Softvér spoločnosť "MAX-CLEANING"

Spoločnosť používa sieť založenú na koncepcii klient-server. Pre moderné DBMS sa architektúra klient-server stala de facto štandardom.

Základným princípom technológie klient-server je rozdelenie funkcií štandardnej interaktívnej aplikácie do štyroch skupín:

· Funkcie zadávania a zobrazovania údajov;

· Aplikačné funkcie špecifické pre predmetnú oblasť;

· Základné funkcie ukladania a správy zdrojov (databáz);

· Servisné funkcie.

Výhody tohto systému:

· Zákaz duplikovania programového kódu servera klientskými programami.

· Pretože sa všetky výpočty vykonávajú na serveri, znižujú sa požiadavky na počítače, na ktorých je nainštalovaný klient.

· Všetky údaje sú uložené na serveri, ktorý je spravidla chránený oveľa lepšie ako väčšina klientov. Je jednoduchšie organizovať kontrolu autorizácie na serveri tak, aby k údajom mali prístup iba klienti s príslušnými prístupovými právami.

Klient poskytuje informácie vedúcemu spoločnosti, ktorý ich pomocou softvéru zaznamená na svojom PC Microsoft Word 2010, vytlačí zmluvu (objednávku) a dokument uloží v papierovej podobe. Existuje teda riziko straty všetkých potrebných informácií, vzniká problém ďalšieho hľadania informácií o klientovi, jeho priestoroch a kontaktoch. Manažér navyše nemá možnosť automaticky vypočítať nielen náklady na upratovanie v závislosti od jeho triedy, veľkosti miestnosti a doby služby v zmluve, ale ani počet tímov potrebných na včasné a kvalitné čistenie miestnosti.

Základnou myšlienkou je rozdeliť sieťovú aplikáciu na niekoľko komponentov, z ktorých každý implementuje konkrétnu sadu služieb. Súčasti takejto aplikácie môžu bežať ďalej rôzne počítačevykonávaním funkcií servera a / alebo klienta. To zvyšuje spoľahlivosť, zabezpečenie a výkon sieťových aplikácií a siete ako celku. Modul mnou vyvinutého informačného systému pre spoločnosť MAKS-CLEANING pomôže zvýšiť ziskovosť podniku prostredníctvom hĺbkovej analýzy informácií o jeho zákazníkoch, predajných systémoch, umožní vedeniu spoločnosti sledovať kľúčové ukazovatele kvality práce vykonávanej na základe zmluvy, ktorá je nevyhnutná pre strategicky dôležité obchodné rozhodnutia a efektívne hodnotenie práce každého zamestnanca.

Účelom mojej záverečnej klasifikačnej práce je vyvinúť modul informačného systému pre účtovanie komplexného upratovania rôznych priestorov.

Na dosiahnutie tohto cieľa musíte splniť nasledujúce úlohy:

Analyzovať činnosti spoločnosti "MAKS" na čistenie priestorov;

Vytvorte zoznam požiadaviek na vývoj databázy;

Vyvinúť databázu pomocou metódy ER-diagramov a nástrojov Erwin CASE;

Implementujte dotazy na manipuláciu s údajmi v databáze.

Vyvinutý modul informačného systému musí spĺňať nasledujúce požiadavky:

· Vytvárať a ukladať údaje o zmluvách s automatickým výpočtom nákladov na služby po dobu platnosti zmluvy;

· Vytvárať a ukladať údaje o objednávkach s automatickým výpočtom nákladov na upratovanie v závislosti od veľkosti miestnosti a triedy upratovania;

· Zaznamenajte údaje o každom čistení;

· Ukladať informácie o kvalite upratovania každého zamestnanca brigády;

· Vypočítajte hodnotenie brigády pre konateľa spoločnosti;

· Automatický výpočet počtu tímov potrebných na čistenie priestorov.

Predpokladám, že zavedenie takéhoto systému zvýši rýchlosť registrácie všetkých požadované dokumenty za služby upratovacej spoločnosti a tiež zníži počet chýb pri práci s klientmi.

Na riešenie zadaných úloh v záverečnej klasifikačnej práci sa používajú:

· Metóda návrhu databázy - modelovanie ER. Jedná sa o grafický popis predmetnej oblasti z hľadiska „objektu - vlastnosti - vzťahu“. Využitie ER-modelovania má veľa výhod: robí analýzu predmetnej oblasti zameranejšou a konkrétnejšou; umožňuje vám navrhnúť AIS bez odkazu na konkrétny cieľový DBMS a kedykoľvek ho zvoliť; pri zmene použitého DBMS nemusíte znova realizovať návrh, stačí urobiť krok k prenosu ER-modelu do cieľového (ak je vami vybraný cieľový DBMS podporovaný týmto CASE-nástrojom, potom sa takýto prechod uskutoční automaticky);

· PRÍPAD - nástroj Erwin. Výhodou je možnosť vytvárať diagramy štruktúry databázy, ktoré automaticky riešia problémy spojené so zachovaním jej integrity, ako aj nezávislosť logického modelu od použitého DBMS, čo umožňuje využívať univerzálne metódy na jeho export do konkrétneho DBMS.

· MS Access DBMS je vybraný ako cieľový DBMS. Access je systém správy relačných databáz, ktorý obsahuje všetky potrebné nástroje na vytvorenie lokálnej databázy, zdieľanej databázy v systéme Windows lokálna sieť so súborovým serverom alebo databázou na serveri SQL, ako aj na vytváranie užívateľských aplikácií pracujúcich s týmito databázami. Access DBMS obsahuje celý rad relatívne samostatných softvérových nástrojov na vytváranie databázových objektov a užívateľských aplikácií. Grafický dizajnér umožňuje užívateľovi vytvárať databázové objekty a aplikačné objekty pomocou mnohých grafických prvkov bez potreby programovania.

2. Dizajnová časť

.1 Popis predmetnej oblasti

Spoločnosť má v Moskve vlastný vozový park, ktorý zahŕňa 5 vozidiel VOLVO, ako aj vodičov priradených ku každému vozidlu 6 osobami. Tímy (3), ktoré vykonávajú komplexné upratovanie priestorov, každý v počte 3 osoby.

Služby spoločnosti:

· Komplexné čistenie priestorov (obchodných, priemyselných, skladových a priemyselných);

Klient, ktorý môže byť iba právnickou osobou, sa uchádza o zamestnanca spoločnosti MAKS na pozícii vedúceho objednávky. Spoločnosť poskytuje svoje služby, a to ako na žiadosť samotného klienta, tak aj dlhodobo (od 7 dní a viac).

Klient diskutuje s manažérom objednávky:

Klient poskytuje údaje o objektoch, ktoré potrebujú servis (typ priestorov, oblasť, umiestnenie);

Cena, meraná v rubľoch, je stanovená v zmluve (100% záloha):

Ø Na žiadosť klienta (jednorazovo) - závisí od oblasti miestnosti, typu upratovania a počtu zapojených tímov.

Ø Dlhodobo - závisí od doby prevádzky, frekvencie a oblasti miestnosti.

Osobné údaje klienta

Údaje o miestnosti

Podmienka služby

Počet zapojených tímov

Kvalitu služieb bude kontrolovať klient a zamestnanec spoločnosti, ktorí kontrolujú výsledok práce tímu. V prípade párovania, neuspokojivého hodnotenia klienta a zamestnanca bude pracovná skupina pokarhaná až do ukončenia.

Výber automobilov dostupných do vozového parku spoločnosti uskutoční špecialista na výber dopravy. Posúdi potrebný počet posádok potrebných na obsluhu priestorov a vozidiel potrebných na prepravu pracovnej skupiny na miesto určenia. Výber strojov sa vykonáva bezprostredne po poskytnutí údajov o priestoroch klientom pred uzavretím zmluvy.

.2 Štúdia uskutočniteľnosti metód návrhu a implementácie

Pri návrhu databázy servisného strediska bolo rozhodnuté použiť metódu ER - diagram. Tento spôsob návrhu som zvolil na základe nasledujúcich faktorov:

Metódu ER diagramov sme sa naučili v disciplíne Databáza.

Metóda návrhu pomocou ER - diagramov má množstvo výhod, a to - prehľadnosť; schopnosť navrhnúť databázu s veľkým počtom objektov a atribútov;

Schémy ER umožňujú konkrétnejšie analyzovať predmetnú oblasť;

Požiadavky na znalosť jazyka SQL sú znížené.

Model ER je založený na troch prvkoch:

Esencia

Atribút

Vybral som si ERwin Data Modeler ako počítačový systém pre návrh databázy.

Ako DBMS bol zvolený Microsoft Access. Tento systém DBMS som vybral ja na základe nasledujúcich faktorov:

Microsoft Access ma naučili počas štúdia;

Access vám umožňuje rýchlo a ľahko vytvárať dotazy na tabuľky;

Pri spracovaní údajov používa Access dotazovací jazyk SQL, ktorý ma naučili aj v disciplíne Databázy.

.3 Návrh databázy

Fáza koncepčného návrhu

Opis subjektov.

Zvýraznenie entít.

Opis odkazov.

Podstatou		Podstatou
Priestory	Za predpokladu
	Podávame	Zamestnanci
	Potreba (v cene)
	Vystavený
	Konzultuje	Zamestnanci
	Známky
	Hodnotí
Zamestnanci	Rozoznať
	súhlasiť
	Hrať
	Ovládanie
	Hrať
	Umožňuje

2.4 Koncepčný dátový model v štandarde Chen

2.5 Schéma ER v prostredí ERwin

.6 Analýza modelu

Zložený atribút: - č

Viachodnotový atribút: Telefón (spoločnosť, zástupca)

Odvodený atribút:

Objednávka - náklady \u003d Typ upratovania (náklady) * Priestory (plocha)

Zmluva - cena \u003d Zmluva (termín / frekvencia služby) * Priestory (plocha)

Rekurzívne odkazy: - č

Odkaz 1: 1: Objednávka vyžaduje čistenie

Redundantné spojenia: áno

Subjekt zástupcu spoločnosti sa objavuje:

Klient konzultuje so zamestnancom

Zákaznícke sadzby Čistenie

· Klient podpíše Zmluvu

Klient zadá objednávku

Priestory sú obsluhované zamestnancami

Priestory sa čistia

Zamestnanci vykonajú Objednávku

Zamestnanci dohliadajú na čistenie

Zmluva zaväzuje upratovanie

Odkaz m: n: áno

Zamestnanci upratujú

Obrázok: 8. Finálny model v Erwinovi

7 Fáza fyzického návrhu

Dátová schéma v prostredí zvoleného DBMS

Obrázok: 9. Schéma dát DB

2.8 Realizácia základných požiadaviek

čistenie databázy manipulácia

Obrázok: 9. Realizácia základných požiadaviek

· Zobrazenie zoznamu zmlúv manažérov spoločnosti

Táto žiadosť vám umožní zobraziť podľa personálneho čísla manažéra, ktorý zadá používateľa, zoznam zmlúv, ktoré vydal. Takáto žiadosť vám umožní rýchlo zobraziť informácie o práci konkrétneho manažéra spoločnosti.

Zamestnanci.Tab_Number, Zamestnanci.Plné meno, Zamestnanci.Phone, Zamestnanci.Pozícia, Zamestnanci.Department_Number, Zmluva.Contract_Number OD Zamestnancov VNÚTORNE PRIPOJIŤ Zmluvu NA Zamestnanci.Tab_Number \u003d Zmluva.Tab_Number WHERE (((Zamestnanci.Tab_Number) \u003d [Zadať správcu :]));

Prezrite si hodnotenie práce správcov

Táto žiadosť bude smerovaná na kontrolu výkonu výkonných majstrov. Podľa posúdenia klienta a konateľa spoločnosti je možné predložiť pripomienky a opatrenia na zabránenie ďalším chybám v práci upratovačiek.

VYBERTE Zamestnanci.Plné meno, Zamestnanci.Pozícia, Čistenie.Client_Hodnotenie, Čistenie.Manager_Hodnotenie, Zamestnanci.Brigade_Number Z Čistenia VNÚTORNÉ PRIPOJENIE (Zamestnanci VNÚTORNÉ PRIPOJENIE Deb_Cotr NA Zamestnanci.Tab_Number \u003d Deleted_Working_Tab_Number. Cleaning.Cleaning_Nom) \u003d [Zadajte číslo čistenia]));

· Zobrazenie zoznamu objednávok pre zadaný typ čistenia

Táto požiadavka vám umožní zobraziť údaje o objednávke vykonané klientom.

VYBERTE [Typ čistenia]. [Trieda čistenia], [Typ čistenia]. Cena, Objednávka.Číslo objednávky Z [Typ čistenia] VNÚTORNÉ SPOJENIE Objednávka ZAPNUTÁ [Typ čistenia]. [Trieda čistenia] \u003d Objednávka. [Trieda čistenia] KDE (([ Typ čistenia]. [Trieda čistenia]) \u003d [Zadajte triedu čistenia:]);

Vyhľadajte spoločnosť - klient podľa databázy

Táto požiadavka umožní zamestnancovi zadať názov spoločnosti klienta a zobraziť zoznam predtým vykonaných zmlúv a objednávok, ak existujú. Vďaka takejto žiadosti bude možné zabrániť opätovnému zadávaniu informácií o spoločnosti klienta.

Vyberte klienta. [Názov spoločnosti], Client.Your_address, Client.Company_telephone, [zástupca spoločnosti]. Celé meno, [zástupca spoločnosti]. E-mail OD klienta INNER JOIN [zástupca spoločnosti] ON Client.CL \u003d [zástupca spoločnosti] .CL WHERE ( ((Klient. [Názov spoločnosti]) \u003d [Zadajte názov spoločnosti:]));

Vyhľadajte nedokončené / dokončené objednávky

Táto požiadavka vám umožní zobraziť zoznam dokončených a nevybavených objednávok podľa stavu zadaného používateľom.

VYBERTE Order.Order_Number, Order.Status, Order.Reception_Date, Order. [Trieda čistenia], Order.Fill_Date FROM Order WHERE (((Order.Status) \u003d [Zadajte stav objednávky:]));

Zoznam priestorov podľa typu

Táto požiadavka vám umožní zobraziť zoznam priestorov pre zadané

používateľom do typu priestorov.

VYBERTE Rooms.Address, Rooms.Area, Rooms.Type, Rooms.CL FROM Rooms WHERE ((((Rooms.Type) \u003d [Zadajte typ miestnosti:]));

Zoznam zmlúv s dobou služby viac ako 30 dní

Táto žiadosť vám umožní zobraziť zoznam zmlúv, ktorých doba služby presahuje 30 dní.

VYBERTE Zmluvu.Nom_kontakt, Zmluvu.Order_Date, Zmluvu.Address, Zmluvu. [Doba poskytovania služby (Dni)] ZO Zmluvy WHERE (((Zmluva.

Výpočet hodnoty objednávok

Táto požiadavka vám umožní zobraziť náklady na objednávku podľa čísla zadaného používateľom. Vďaka takejto požiadavke bude možné vyhnúť sa chybám pri výpočte hodnoty objednávok.

VYBERTE Order.Order_number, ([Typ čistenia]. [Náklady] + [Typ čistenia]. [Počet brigád na jednotku plochy]) * [Priestory]. [Plocha] AS Hodnota_objednávky, Objednávka. [Trieda čistenia], Stav objednávky FROM Izby VNÚTORNÉ PRIPOJENIE ([Typ čistenia] VNÚTORNÉ PRIPOJENIE Objednávka ZAPNUTÉ [Typ upratovania]. [Trieda upratovania] \u003d Objednávka. [Trieda upratovania]) ZAPNUTÉ Rooms.Address \u003d Objednávka.Address KDE ((((Objednávka.Číslo objednávky) \u003d [Zadajte číslo objednávky) :]));

Na základe účelu vyvíjaného informačného systému ďalej navrhneme modulárnu štruktúru aplikácie. Na definovanie modulárnej štruktúry použijeme diagram komponentov notácie UML 2.0 (obrázok 3.4).

Obrázok: 3.4

Informačný systém sa skladá z troch zložiek:

• 1. Rozhranie. Implementácia interakcie používateľa s informačným systémom. Obsahuje nasledujúce moduly:
  • · Vstup / výstup - organizácia vstupu a výstupu informácií pri práci s IS;
  • · Reporting - organizácia reportingu v súlade so zavedenými formami dokumentácie pre rôzne oblasti personálnej agentúry;
  • · Vyhľadávanie - organizácia hľadania kandidátov a voľných pracovných miest podľa zadaných parametrov;
• 2. Spracovanie údajov. Implementácia funkcií spracovania informácií: vyhľadávanie údajov v databáze, matematický model pre účely primárnej analýzy dokumentov atď.;
• 3. DB. Implementácia dátového skladu, ktorý obsahuje informácie o zákazníkovi.

Návrh štruktúry databázy

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

• · Definícia subjektov; definovanie závislostí medzi entitami;
• · Priradenie primárnych a alternatívnych kľúčov;
• · Definícia atribútov subjektov;
• · Uvedenie modelu na požadovanú úroveň normálnej formy;
• · Prechod na fyzický popis modelu: priradenie korešpondencie názov entity - názov tabuľky, atribút entity - atribút tabuľky;
• · Priradenie spúšťacích mechanizmov, postupov a obmedzení;
• · Generovanie databázy.

Schéma vzťahov medzi entitami popisujúca databázu z hľadiska IDEF1.x je zostavená z troch hlavných blokov - entít, atribútov a vzťahov. Ak považujeme diagram za grafické znázornenie doménových pravidiel, potom sú entitami a atribútmi podstatné mená a vzťahy sú slovesá.

Pretože budúci IS pre túto databázu bude prehľadávať, ako hlavné atribúty dokumentu boli vybrané nasledujúce:

• - názov dokumentu;
• - dátum prijatia dokumentu v archíve (právnické firmy, ktoré poskytujú archívne služby, sledujú dobu uchovávania dokumentácie. Každý dokument má svoju trvanlivosť. Mnoho cenných papierov stráca v priebehu času svoj význam a ich hodnota sa zníži na nulu. Takéto dokumenty by mali byť zničené. Včasný výber takýchto dokumentov a likvidácia dokumentov je súčasťou balíka archívnych služieb poskytovaných právnickými kanceláriami. Pri prijímaní na uloženie je každý dokument po osobitnom preskúmaní určený dobou uloženia. Po uplynutí tejto doby je dokument odovzdaný na zničenie);
• - totožnosť (typ) dokumentu (pretože všetky dokumenty boli rozdelené do 7 typov, pre ktoré bolo poradie urobené podľa dôležitosti);
• -číslo stĺpca;
• - číslo police;
• - číslo sánky (tieto 3 parametre sú potrebné na určenie umiestnenia dokumentu v archíve);
• - prítomnosť dokumentu v jeho bunke (potrebujete vedieť, či je dokument v archíve, alebo bol vydaný žiadateľovi).

Výsledok dotazu na výber všetkých dokumentov patriacich jednému klientovi by mal vyzerať takto, pozri obrázok 3.5. V predloženom príklade bol počet dokumentov zámerne obmedzený na 20.

Teraz sa pozrime podrobnejšie na logický dátový model vyvíjaného informačného systému, ktorý je znázornený na obrázku 3.6.

Obrázok: 3.5

Obrázok: 3.6

Z predloženého dátového modelu vidno, že obsahuje tri entity, každá s vlastnou sadou atribútov, z ktorých dva sú závislé a jeden nie.

Subjekt „Zamestnanec“, ktorý je nezávislým subjektom, má nasledujúce atribúty:

• · Identifikačné číslo zamestnanca - je primárnym kľúčom tohto subjektu;
• · Celé meno zamestnanca;
• · Oblasť špecializácie;
• · Hodnotenie;
• · Ďalšie informácie.

Entita Customer je závislá entita od entity Employee, čo znamená, že každý zamestnanec môže slúžiť mnohým zákazníkom. Entita klienta má atribúty:

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

Entita „Dokument“ je závislá entita od entity „Klient“, čo znamená, že každý klient môže do archívu uložiť veľa rôznych dokumentov. Entita dokumentu má atribúty:

• · Identifikátor dokumentu - je primárnym kľúčom tejto entity;
• · Séria a číslo pasu - je sekundárny kľúč tohto subjektu;
• · Názov dokumentu;
• · Dátum prijatia;
• · Príslušnosť k skupine;
• · Číslo stĺpca;
• · Číslo police;
• · Číslo saní;
• · Prítomnosť dokumentu v bunke.

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ť kvalita údržby nehnuteľností, zlepšenie priľahlého územia a do istej miery aj 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“	Sú dané funkčnosť informačné systémy pre správu nehnuteľností používané 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 bytového domu 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í“	Prezentujú sa 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 predstavený 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 pomocou vývojového prostredia MS Visual 2010
Článok „Klasifikácia účastníkov a informačných systémov v organizáciách spravujúcich 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. Uvádzame 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 aktivít HOA“	V článku sa uvažuje o aplikácii 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“	Do úvahy sa berú 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, údajových typoch, navrhovanom zložení tabuliek, ako aj 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