Návrh informačných systémov je viacstupňový proces ich tvorby a/alebo modernizácie pomocou usporiadaného súboru metodík a nástrojov. Dizajn (na rozdiel od modelovania) zahŕňa prácu s neexistujúcim objektom a je zameraný na vytvorenie informačného systému v oblasti:
- spracovanie objektov budúcej databázy,
- písanie programov (vrátane reportovacích a obrazovkových formulárov), ktoré zabezpečujú vykonávanie dotazov na údaje,
- s prihliadnutím na fungovanie špecifického prostredia (technológie).
Ak fázu navrhovania informačných systémov identifikujeme ako samostatnú fázu, potom ju možno zaradiť medzi fázy analýzy a vývoja. V praxi je však jasné rozdelenie na etapy zvyčajne ťažké alebo nemožné, pretože návrh formálne začína definíciou ciele projektu, často pokračuje cez fázy testovania a implementácie.
Cieľ návrhu informačného systému a súvisiace pojmy
Moderní manažéri verejných a súkromných organizácií si uvedomujú, že rýchlosť spracovania informácií, ktorá sa neustále mení a narastá, je otázkou prežitia firmy na trhu a konkurenčná výhoda. Vo všeobecnosti ciele projektov na vytváranie informačných systémov spočívajú v zabezpečení podmienok, ktoré umožňujú prijímať, spracovávať a používať tieto informácie vytvorením funkčného systému bezpečného pri poruche s dostatočným množstvom:
- úroveň adaptability na meniace sa podmienky,
- priepustnosť,
- čas odozvy systému na požiadavku,
- úroveň bezpečnosti,
- stupeň jednoduchosti použitia.
Informačný systém (IS) je súbor informácií obsiahnutých v databáze a technológií (a tiež technických nástrojov), ktoré umožňujú spracovanie informácií. V tomto prípade technológie zahŕňajú metódy na detekciu, zhromažďovanie, spracovanie, ukladanie, distribúciu informácií a metódy, ktoré umožňujú implementáciu týchto metód. Informačný manažment Ide o využitie týchto metód na riadenie procesov plánovania, návrhu, prevádzky a analýzy IS. Technológia návrhu je založená na metodike zvolenej pre konkrétnu úlohu ako súbor princípov vyjadrených v jedinom definovanom koncepte.
Organizácia návrhu IP
Organizácia dizajnu IC sa zvyčajne delí na 2 typy:
- Kanonický dizajn odráža technologické vlastnosti pôvodného (individuálneho) procesu.
- Štandardné prevedenie, ktoré sa vyznačuje štandardným konštrukčným riešením (TDS), je replikované a vhodné na opakované použitie.
Kanonický dizajn sa vyznačuje odrazom technológie manuálneho dizajnu, implementáciou na úrovni interpretov a použitím univerzálnych nástrojov počítačovej podpory.
Canonical design sa používa hlavne pre lokálne a relatívne malé IC s minimálnym využitím štandardných riešení. K úprave konštrukčných riešení dochádza len preprogramovaním softvérových modulov. 
Kanonický dizajn je organizovaný pomocou kaskádového modelu životného cyklu. To zahŕňa rozdelenie procesu do nasledujúcich etáp a etáp:
- Predprojektová fáza. Technické špecifikácie sú vypracované a vypracované. To znamená, že sa sformulujú požiadavky na informačný systém, vypracuje sa jeho koncepcia, vypracuje sa štúdia realizovateľnosti a napíšu sa technické špecifikácie.
- Fáza návrhu zahŕňa prípravu predbežných a technických návrhov, vypracovanie pracovnej dokumentácie.
- Poprojektová fáza odštartuje aktivity na implementáciu IS, školenie personálu a analýzu výsledkov testov. Súčasťou tejto etapy je udržiavanie IP a odstraňovanie zistených nedostatkov.
Etapy, ak je to potrebné, môžu byť zväčšené alebo detailné - kombinujte po sebe nasledujúce etapy, odstráňte „zbytočné“ a začnite ďalšiu etapu pred dokončením predchádzajúcej.
Štandardná metóda návrhu sa vyznačuje možnosťou rozloženia navrhnutého IS na komponenty, ktoré zahŕňajú softvérové moduly, subsystémy, sady úloh a pod. Na implementáciu komponentov môžete použiť štandardné riešenia ktoré už na trhu existujú, a prispôsobiť ich potrebám konkrétnej organizácie. V tomto prípade štandardný dizajn vyžaduje povinnú dostupnosť dokumentácie podrobne popisujúcej TPR a konfiguračné postupy.
Dekompozícia môže mať niekoľko úrovní, čo umožňuje rozlíšiť triedy TPR:
- elementárny – pre samostatnú úlohu (prvok),
- subsystém - pre jednotlivé subsystémy,
- objektovo štandardné konštrukčné riešenia obsahujúce celú sadu subsystémov.
Schopnosť implementovať modulárny prístup sa považuje za výhodu elementárnych TPR. Ak sú však rôzne prvky nekompatibilné, proces ich kombinovania vedie k zvýšeným nákladom. Subsystém TPR, okrem implementácie modulárneho prístupu, umožňuje vykonávať parametrickú konfiguráciu pre objekty na rôznych úrovniach riadenia. Problémy s konsolidáciou vznikajú, ak ide o produkt niekoľkých rôznych výrobcov softvéru. Okrem toho sa adaptabilita TPR z hľadiska neustáleho reinžinieringu procesov považuje za nedostatočnú. Objektové TPR majú v porovnaní s predchádzajúcimi triedami veľké množstvo výhod:
- škálovateľnosť, ktorá umožňuje použiť konfigurácie IS pre rôzny počet pracovných staníc,
- metodická jednota komponentov,
- kompatibilita komponentov IC,
- otvorenosť architektúry – schopnosť nasadzovať dizajnové riešenia na platformách rôznych typov,
- konfigurovateľnosť – schopnosť využívať požadovanú podmnožinu komponentov IS.
Pri implementácii štandardného návrhu sa využívajú parametricky orientované a modelovo orientované prístupy.
Základné metodiky návrhu IC
Špecifické vlastnosti procesu navrhovania umožňujú rozlíšiť metodiky založené na rozdielne princípy. Medzi hlavné moderné metodológie návrhu IC patria:
- SADT. Metodika funkčného modelovania práce, ktorá je založená na štruktúrnej analýze a grafické znázornenie organizácia ako systém funkcií. Tu rozlišujeme funkčné, informačné a dynamické modely. Metodológia je v súčasnosti známa ako notácia IDEF0 (štandard). Analyzovaný proces je graficky znázornený vo forme štvoruholníka, kde sú hore zobrazené regulačné a riadiace vplyvy, dole riadiace objekty, vľavo vstupné dáta a vpravo výstupné dáta.
- RAD. Metodológia rýchleho vývoja aplikácií. RAD umožňuje rýchly vývoj aplikácií pomocou dizajnu založeného na komponentoch. Metodika sa používa pri projektoch s obmedzeným rozpočtom, nejasnými požiadavkami na IP a krátkymi termínmi implementácie. Používa sa, ak je možné užívateľské rozhranie demonštrovať na prototype a projekt je možné rozdeliť na funkčné prvky.
- RUP. Metodológia RUP implementuje iteračné a inkrementálne prístupy. Systém je postavený na architektúre informačného systému a plánovanie a riadenie projektov vychádzajú z funkčných požiadaviek na informačný systém. Vývoj všeobecného informačného systému prebieha v iteráciách, ako komplex jednotlivých malých projektov s vlastnými plánmi a úlohami. Iteračný cyklus je charakterizovaný periodickou spätnou väzbou a prispôsobovaním sa jadru IS.
Existuje niekoľko klasifikácií metodík: pre použitie TPR, pre použitie automatizačných nástrojov atď. Napríklad podľa stupňa adaptability, rekonštrukcie (keď sa moduly preprogramujú), parametrizácia (keď zmena parametrov so sebou nesie generovanie konštrukčné riešenie), reštrukturalizácia (pri zmene modelu problémovej oblasti) sprevádzaná automatickým generovaním konštrukčného riešenia).
Servisné centrum je organizácia zaoberajúca sa poskytovaním služieb pre servisnú podporu a údržbu strojov, zariadení a iných produktov. Činnosť servisných stredísk zahŕňa predpredajné, záručné a popredajné opravy.
Enterprise IP Mikhailov A.O. vykonáva opravy a údržbu domáce prístroje a elektroniky, ako aj počítačov, telefónov a tabletov, ktoré si klienti prinesú do kancelárie, ako aj dopĺňanie kaziet a inštalovanie sietí a kancelárskych ústrední. Ak nie je možné vybavenie dodať, klient sám navštívi miesto a v prípade potreby ho doručí nasilu. servisné stredisko. Keď klient kontaktuje servisné stredisko, dispečer vyplní žiadosť o prijatie objednávky. Vykoná sa analýza objektu, na základe ktorej sa zistí, či bude zariadenie opravené alebo nie. Inžiniersky úsek vypracúva cenník opráv a údržby zariadení, nakoľko spolupracuje s dodávateľmi náhradných dielov a prístrojov na opravu zariadení. Vykonávajú sa opravy špeciálne vybavenie dodržiavanie bezpečnostných pravidiel. Spoločnosť tiež predáva periférne zariadenia pre telefóny, tablety a počítače. Spoločnosť nakupuje použité a pokazené zariadenia.
Práca v podniku kvalifikovaných špecialistov s dlhoročnými skúsenosťami. Riaditeľ riadi celý chod podniku.
Adresa firmy:
Permská oblasť, Kungur, sv. Lenina 66
Prevádzkový režim:
Po-Pia: 10 - 19 bez obeda
Slnko: zatvorené.
Štruktúrovaním zoznamu služieb môže podnik zvýšiť svoje zisky, rozšíriť hranice podniku alebo otvoriť ďalšie servisné stredisko na inom mieste, môže sa tiež zlepšiť kvalita poskytovaných služieb a zvýšiť počet klientov.
Analýza predmetnej oblasti poskytuje úplný opis predmetnej oblasti podniku IP Mikhailov A.O. vytvoriť funkčný informačný systém pre tento podnik. Je uvedený popis práce servisného strediska s uvedením práce technického oddelenia. Vytvorila sa aj organizačná štruktúra podniku, ktorá ukazuje interakciu medzi riaditeľom a podriadenými.
Tvorba základných dokumentov pre riadenie projektu informačného systému
Projekt je súbor úloh alebo činností spojených s dosiahnutím plánovaného cieľa, ktorý má spravidla jedinečný a neopakovateľný charakter.
Projektový manažment je využitie znalostí, zručností, metód, nástrojov a technológií pri realizácii projektu s cieľom dosiahnuť alebo prekročiť očakávania účastníkov projektu.
Pre správne riadenie projektu informačného systému je potrebné vytvoriť základné dokumenty projektového manažmentu. Základnými dokumentmi budú Charta a Plán riadenia projektu.
Projektová charta
Charta projektu je nástroj, ktorý formálne schvaľuje projekt a je spojovacím článkom, ktorý spája pripravovaný projekt aktuálna práca organizácií.
Charta projektu dokumentuje počiatočné požiadavky na projekt, aby splnil potreby a očakávania zainteresovaných strán.
Existuje charta projektu.
Tento dokument zvyčajne odzrkadľuje situáciu na strane zákazníckej organizácie, vydáva ho manažér mimo projektu a menuje projektového manažéra, ktorý mu dáva oprávnenie využívať zdroje organizácie v projekte.
Charta projektu musí obsahovať tieto informácie:
Požiadavky na projekt a produkt projektu v pomerne všeobecnej forme;
Cieľ projektu;
Informácie o pridelenom projektovom manažérovi a jeho úrovni právomocí;
Plán míľnikov;
Vzťahy medzi účastníkmi projektu;
Funkčné organizácie a ich účasť;
Predpoklady o organizácii a prostredí, ako aj vonkajšie predpoklady;
Obmedzenia týkajúce sa organizácie a prostredia, ako aj vonkajšie obmedzenia;
Skutočná obchodná situácia, ktorá slúži ako zdôvodnenie projektu s údajmi o návratnosti investícií;
Rozpočet projektu.
Charta projektu zvyšuje pravdepodobnosť úspešného dokončenia projektu. Dokumentuje zámery účastníkov projektu na samom začiatku projektu a môže slúžiť ako základný bod riešenia sporov medzi členmi projektového tímu a realizujúcou organizáciou.
Pri zostavovaní projektovej charty sa uskutočnilo stanovenie charty pravidiel pre organizáciu práce na projekte s použitím dokumentácie, stratégií, cieľov, metodiky projektového riadenia, funkcií rolí a pravidiel projektu potrebných na dosiahnutie obchodných cieľov projektu. Boli identifikovaní tí, ktorí sú zodpovední za riadenie a implementáciu.
Vypracovanie charty si vyžaduje značný čas. Pri vytváraní ďalšieho projektu môže byť vypracovaná charta použitá ako vzor, takže vypracovanie charty zaberie menej času. Projektová charta pomáha pri riadení projektu, pretože niektoré informácie sú potrebné na prácu v MS Project.
Plán riadenia projektu
Plán riadenia projektu - balík schválených formálnych dokumentov, ktoré uvádzajú, ako sa bude projekt realizovať a ako sa bude projekt monitorovať a riadiť. Plán môže byť súhrnný alebo podrobný a môže zahŕňať jeden alebo viac podporných plánov manažmentu a iných plánovacích dokumentov.
Proces vypracovania plánu projektového manažmentu je proces dokumentovania činností potrebných na identifikáciu, prípravu, integráciu a koordináciu všetkých podporných plánov. Správne napísaný plán riadenia projektu je primárnym zdrojom informácií o tom, ako bude projekt naplánovaný, meraný, kontrolovaný a uzavretý. Plán riadenia projektu sa aktualizuje a upravuje ako súčasť integrovaného procesu riadenia zmien projektu.
1 Podporné plány projektového manažmentu, ktoré zahŕňajú:
plán riadenia rozsahu projektu;
Plán riadenia harmonogramu projektu;
Plán riadenia nákladov na projekt;
Plán riadenia kvality projektu;
Plán riadenia ľudských zdrojov;
Plán riadenia projektovej komunikácie;
plán riadenia rizík projektu;
Plán riadenia konfigurácie.
2 Základný plán projektu pozostáva z:
Základný harmonogram projektu;
Základný plán v cene;
Základný plán kvality;
Základný konfiguračný plán;
Register rizík.
3 Výsledky analýzy, ktorú vykonal projektový tím, pokiaľ ide o obsah, rozsah a načasovanie projektu.
Pre projekt informačného systému „Účtovanie poskytnutých služieb“ je vytvorený plán riadenia projektu. (príloha B)
Prvý odsek plánu riadenia projektu uvádza názov projektu. Názov projektu nie je možné zmeniť počas celého životného cyklu projektu.
Druhý odsek definuje ciele a zámery projektu. Ciele sú tvorené na základe požiadaviek zákazníkov, ktoré pozostávajú z automatizácie hlavných obchodných procesov podniku. Boli stanovené ciele ako prilákanie zákazníkov a zvýšenie zisku, zlepšenie kvality poskytovaných služieb.
Tretí bod definuje požiadavky na konštrukčné riešenie a výsledky projektu. Táto časť je súčasťou základného obsahu projektu. Na zabezpečenie prepojenia medzi požiadavkami zákazníka a výsledkami projektu sa odporúča použiť funkciu kvality.
Štvrtý bod vymedzuje hranice projektu. Toto je základný prvok obsahu projektu. Rozsah projektu popisuje, čo je súčasťou projektu, aby sa zabezpečilo, že účastník projektu omylom nepovažuje produkt, službu alebo výsledok za zahrnuté do projektu.
Piaty bod definuje nástroje a technológie na implementáciu projektového manažmentu.
Šiesty bod obsahuje hierarchickú štruktúru práce – model, ktorý odhaľuje úroveň projektu po úrovni do takej podrobnosti, ktorá je potrebná pre efektívne plánovanie a kontrolu projektu.
Siedmy bod popisuje potrebu zdrojov. Je určená pracovnou náročnosťou práce, ktorá sa odráža v predtým vyvinutom WBS.
Ôsmy bod plánu ukazuje zväčšený kalendárny plán. Vyvíja sa na základe míľnikov, informácií z projektovej charty a informácií z použitej metodiky projektového manažmentu.
Deviatym bodom sú kritické faktory úspechu. Popisuje podmienky, ktorých zabezpečenie na projekte môže byť kľúčom k úspechu.
Desiaty a jedenásty bod odrážajú predpoklady a obmedzenia zo strany interpreta. Počas realizácie projektu sa môžu obmedzenia meniť.
Dvanásty bod pôvodne formuloval riziká. Uvádzajú sa už známe riziká a hlavné kategórie potenciálnych rizík.
Riadenie rizík sú procesy spojené s identifikáciou, analýzou rizík a rozhodovaním, ktoré zahŕňajú maximalizáciu pozitívnych a minimalizáciu negatívnych dôsledkov rizikových udalostí.
Plánovanie riadenia rizík je proces rozhodovania o aplikácii a plánovaní riadenia rizík pre konkrétny projekt. Tento proces môže zahŕňať rozhodnutia o organizácii, personálne obsadenie postupov riadenia rizík projektu, výber preferovanej metodiky, zdroje údajov na identifikáciu rizík a časový interval pre situačnú analýzu.
Plánovanie riadenia rizík - výber prístupov a plánovanie aktivít riadenia rizík projektu.
1 Identifikácia rizík – identifikácia rizík, ktoré by mohli ovplyvniť projekt a zdokumentovanie ich charakteristík.
2 Kvalitatívne hodnotenie rizík - kvalitatívna analýza rizík a podmienok ich výskytu s cieľom určiť ich vplyv na úspešnosť projektu.
3 Kvantitatívne hodnotenie - kvantitatívna analýza pravdepodobnosť výskytu a dopad následkov rizika na projekt.
4 Plánovanie reakcie na riziko – identifikácia postupov a metód na zmiernenie negatívnych dôsledkov rizikových udalostí a využitie možných výhod.
5 Monitorovanie a kontrola rizík – monitorovanie rizík, identifikácia zostávajúcich rizík, realizácia plánu riadenia rizík projektu a hodnotenie účinnosti opatrení na zmiernenie rizík.
Bol predložený plán riadenia rizík. (príloha B)
Plán riadenia projektu pre informačný systém „Vyúčtovanie poskytnutých služieb“ umožnil vytvárať dokumenty a popisovať charakteristiky a hranice projektu, súvisiace služby, ako aj spôsoby akceptácie a správu obsahu. Vyhlásenie o rozsahu umožnilo posúdiť požadovaný výsledok a slúžilo ako základ pre vytvorenie základnej línie rozsahu, ktorá sa mala dodržiavať pri všetkých projektových prácach.
Vypracovanie základnej dokumentácie pre projektové riadenie informačného systému „Vyúčtovanie poskytnutých služieb“ umožnilo popísať časť podkladov pre kvalitnú a úspešnú implementáciu projektového riadenia v MS Project. Kľúčom k úspechu je pochopenie potreby týchto dokumentov v procese riadenia projektu. Výsledkom tejto práce bolo vypracovanie projektovej charty a plánu riadenia projektu, ktoré budú použité v ďalšej práci.
Výsledkom prvej časti bolo štruktúrovanie projektu IS „Účtovanie poskytovaných služieb“ pre podnik IP Mikhailov A.O., bola vypracovaná aj projektová charta a plán projektového riadenia, ktoré boli využité pri ďalšej práci na riadení projektov. Proces tvorby základných dokumentov je najdôležitejšou súčasťou projektového riadenia, nakoľko ovplyvňuje kvalitu, trvanie a úspešnosť projektu.
Úvod
Záver
Literatúra
Úvod
rozvoj rôznych odboroch ľudská aktivita v súčasnej fáze to nie je možné bez širokého používania počítačová technológia a vytváranie informačných systémov rôznych smerov. Spracovanie informácií v takýchto systémoch sa stalo samostatnou vedeckou a technickou oblasťou.
Po fáze výstavby informačný model začína návrh systému. V tejto fáze sa uskutoční výber technologické riešenia, na základe ktorej bude informačný systém vybudovaný.
Informácie v modernom svete sa stal jedným z najdôležitejších zdrojov a informačné systémy (IS) sa stali potrebný nástroj takmer vo všetkých oblastiach činnosti.
V reálnych podmienkach je dizajn hľadaním metódy, ktorá spĺňa požiadavky na funkčnosť systému s využitím dostupných technológií s prihliadnutím na dané obmedzenia.
Rôznorodosť problémov riešených pomocou informačných systémov viedla k vzniku mnohých rôznych typov systémov, líšiacich sa princípmi konštrukcie a pravidlami spracovania informácií v nich zabudovaných.
Účel skúšobná práca je zvážiť krok za krokom proces tvorby informačných systémov.
Cieľom tejto práce je zistiť hlavný účel dizajnu, ako aj účel tvorby informačných systémov.
1. Návrh informačných systémov
Návrh informačných systémov vždy začína definovaním účelu projektu. Hlavnou úlohou každého úspešný projekt je zabezpečiť, aby v čase spustenia systému a počas celej doby jeho prevádzky:
· požadovanú funkčnosť systému a mieru prispôsobenia meniacim sa podmienkam jeho prevádzky;
· požadovaná kapacita systému;
· požadovaný čas odozvy systému na požiadavku;
· bezproblémová prevádzka systému v požadovanom režime, inými slovami pripravenosť a dostupnosť systému na spracovanie požiadaviek užívateľov;
· jednoduchosť ovládania a podpory systému;
· potrebné zabezpečenie.
Výkon je hlavným faktorom, ktorý určuje efektívnosť systému. Dobrý dizajn je základom vysokovýkonného systému.
Návrh informačných systémov pokrýva tri hlavné oblasti:
· navrhovanie dátových objektov, ktoré budú implementované do databázy;
· navrhovanie programov, obrazovkových formulárov, zostáv, ktoré zabezpečia vykonávanie dátových dopytov;
· zohľadnenie špecifického prostredia alebo technológie, a to: topológie siete, hardvérovej konfigurácie, použitej architektúry (súborový server alebo klient-server), paralelného spracovania, distribuovaného spracovania dát a pod.
Proces tvorby IS je podľa modernej metodiky procesom konštrukcie a postupnej transformácie množstva koordinovaných modelov vo všetkých fázach životného cyklu IS (LC). V každej fáze životného cyklu sa vytvárajú modely pre ňu špecifické – organizácia, požiadavky na IS, projekt IS, požiadavky na aplikáciu atď. Modely sú tvorené pracovnými skupinami projektového tímu, ukladané a akumulované v projektovom úložisku. Tvorba modelov, ich kontrola, transformácia a poskytovanie na kolektívne použitie sa uskutočňuje pomocou špeciálnych softvérových nástrojov - CASE nástrojov.
Proces vytvárania IP je rozdelený do niekoľkých etáp (etáp), ohraničených určitým časovým rámcom a končiacich vydaním konkrétneho produktu (modely, softvérové produkty, dokumentácia atď.).
Typicky sa rozlišujú tieto etapy tvorby IS: tvorba systémových požiadaviek, návrh, implementácia, testovanie, uvedenie do prevádzky, prevádzka a údržba.
Počiatočnou fázou procesu tvorby IS je modelovanie obchodných procesov prebiehajúcich v organizácii a realizujúcich jej ciele a zámery. Organizačný model, popísaný z hľadiska podnikových procesov a podnikových funkcií, nám umožňuje formulovať základné požiadavky na IS. Táto základná pozícia metodiky zabezpečuje objektivitu pri vývoji požiadaviek na návrh systému. Súbor modelov pre popis požiadaviek IS je následne transformovaný do systému modelov, ktoré popisujú koncepčný návrh IS. Modely architektúry IS, požiadavky na softvér a informačnú podporu(A O TOM). Následne sa tvorí softvérová a informačná architektúra, identifikujú sa podnikové databázy a jednotlivé aplikácie, formujú sa modely požiadaviek na aplikácie a vykonáva sa ich vývoj, testovanie a integrácia.
Cieľom počiatočných fáz vytvárania IS, realizovaných vo fáze analýzy činností organizácie, je formulovať požiadavky na IS, ktoré správne a presne odrážajú ciele a zámery zákazníckej organizácie. Pre špecifikáciu procesu tvorby informačného systému, ktorý zodpovedá potrebám organizácie, je potrebné zistiť a jasne formulovať, o aké potreby ide. K tomu je potrebné určiť požiadavky zákazníkov na IS a zmapovať ich v modelovom jazyku do požiadaviek na vypracovanie projektu IS tak, aby bol zabezpečený súlad s cieľmi a zámermi organizácie.
Úloha formovania požiadaviek na informačné systémy je jednou z najdôležitejších, ťažko formalizovateľná a najdrahšia a ťažko opraviteľná v prípade chyby. Moderné nástroje a softvérové produkty umožňujú rýchlo vytvárať IP podľa hotových požiadaviek. Tieto systémy však často neuspokojujú zákazníkov a vyžadujú početné úpravy, čo vedie k prudkému zvýšeniu skutočných nákladov na IP. Hlavnou príčinou tohto stavu je nesprávna, nepresná alebo neúplná definícia požiadaviek na IS v štádiu analýzy.
Vo fáze návrhu sa najskôr vytvoria dátové modely. Dizajnéri dostanú výsledky analýzy ako počiatočnú informáciu. Vytváranie logických a fyzických dátových modelov je základnou súčasťou návrhu databázy. Informačný model získaný počas procesu analýzy sa najskôr prevedie na logický a potom na fyzický dátový model.
Paralelne s návrhom databázovej schémy prebieha procesný návrh na získanie špecifikácií (popisov) všetkých modulov IS. Oba tieto procesy návrhu spolu úzko súvisia, pretože časť obchodnej logiky je zvyčajne implementovaná v databáze (obmedzenia, spúšťače, uložené procedúry). Hlavným cieľom návrhu procesov je zmapovať funkcie získané vo fáze analýzy do modulov informačného systému. Pri navrhovaní modulov sa určujú rozhrania programu: rozloženie ponuky, vzhľad okna, klávesové skratky a súvisiace volania.
Konečné produkty fázy návrhu sú:
· databázový diagram (založený na modeli ER vyvinutom v štádiu analýzy);
· súbor špecifikácií systémových modulov (sú postavené na základe funkčných modelov).
Okrem toho sa vo fáze návrhu vykonáva aj vývoj architektúry IS vrátane výberu platformy (platforiem) a operačného systému ( operačné systémy). V heterogénnom IS môže niekoľko počítačov bežať na rôznych hardvérových platformách a na rôznych operačných systémoch. Okrem výberu platformy sa vo fáze návrhu určujú aj nasledujúce charakteristiky architektúry:
· či pôjde o architektúru „file-server“ alebo „client-server“;
· bude to 3-vrstvová architektúra s nasledujúcimi vrstvami: server, middleware (aplikačný server), klientsky softvér;
· či bude databáza centralizovaná alebo distribuovaná. Ak je databáza distribuovaná, aké mechanizmy sa použijú na udržanie konzistentnosti a relevantnosti údajov;
· či bude databáza homogénna, teda či budú všetky databázové servery produktmi rovnakého výrobcu (napríklad všetky servery sú len Oracle alebo všetky servery sú len DB2 UDB). Ak databáza nie je homogénna, aký softvér sa použije na výmenu údajov medzi DBMS od rôznych výrobcov (už existujúcimi alebo špeciálne vyvinutými v rámci projektu);
· či sa na dosiahnutie správneho výkonu použijú paralelné databázové servery (napríklad Oracle Parallel Server, DB2 UDB).
Fáza návrhu končí vypracovaním technického návrhu IP. Vo fáze implementácie sa vykonáva tvorba softvér prevádzková dokumentácia.
Po dokončení vývoja jednotlivého modulu systému sa vykoná samostatný test, ktorý má dva hlavné ciele:
· detekcia porúch modulov (tvrdé poruchy);
· súlad modulu so špecifikáciou (prítomnosť všetkých potrebných funkcií, absencia nepotrebných funkcií).
Po úspešnom absolvovaní autonómneho testu je modul zaradený do vyvíjanej časti systému a skupina vygenerovaných modulov prejde testami spojenia, ktoré by mali sledovať ich vzájomné ovplyvňovanie.
Ďalej sa skupina modulov testuje na prevádzkovú spoľahlivosť, to znamená, že sa podrobia po prvé testom simulujúcim poruchy systému a po druhé testom stredného času medzi poruchami. Prvá skupina testov ukazuje, ako dobre sa systém zotavuje po zlyhaniach softvéru a hardvéru. Druhá skupina testov určuje stupeň stability systému počas bežnej prevádzky a umožňuje odhadnúť dobu prevádzky systému. Súbor testov robustnosti by mal zahŕňať testy, ktoré simulujú špičkové zaťaženie systému.
Potom celá zostava modulov prechádza systémovým testom – interným akceptačným testom produktu, ktorý ukazuje úroveň jeho kvality. To zahŕňa testy funkčnosti a testy spoľahlivosti systému.
Posledným testom informačného systému je akceptačné testovanie. Takýto test zahŕňa ukážku informačného systému zákazníkovi a musí obsahovať skupinu testov simulujúcich reálne podnikové procesy, aby preukázal súlad implementácie s požiadavkami zákazníka.
1Článok je venovaný problematike budovania informačného systému určeného na analýzu investičných projektov, ktoré sa predkladajú administratívnym štruktúram za účelom získania finančnej podpory. Štruktúra takéhoto systému je informačný komplex pozostávajúci z externého modulu a hlavného systému. Externý modul je určený na prípravu prvotných informácií o projekte a nachádza sa v podniku, ktorý sa zúčastňuje súťaže. Hlavný systém vykonáva analýzu projektov a nachádza sa v administratívnom riadiacom orgáne. Štruktúra hlavného systému je zameraná na implementáciu prvkov analýzy investičných projektov. V práci sú tiež navrhnuté základné princípy a metodika hodnotenia investičných projektov. Na vyhodnotenie projektu sú mnohé počiatočné ukazovatele rozdelené do skupín, ktoré charakterizujú jednotlivé strany finančný stav organizácií. Zahrnuté sú aj doplnkové ukazovatele dôležité pre sociálny, kultúrny a iný rozvoj územia. V tomto smere predložená metodika umožňuje v procese rozhodovania o pridelení úverov hodnotiť investičné projekty nielen podľa finančné ukazovatele, ale zohľadňujú aj priority administratívy Organizačná štruktúra, ktoré priamo nesúvisia s finančnou kondíciou organizácie zúčastňujúcej sa súťaže.
Informačný systém
štruktúru
metodiky
investičný projekt
administratívna štruktúra
1. Brykin I.M., Beklemišev A.V. Hodnotenie, výber a analýza investičných projektov. – M.: International Media Group LLC, 2011. – 47 s.
2. Bailey D.W., Sharp W.F., Alexander G.D. Investície. – M.: INFRA-M, 2012. – 1028 s.
3. Vilensky P.L., Livshits V.N., Smolyak S.A. Hodnotenie efektívnosti investičných projektov. Teória a prax: Učebnica. úžitok. – M.: Delo, 2008. – 888 s.
4. Kravchenko T.K., Presnyakov V.F. Infokomunikačné technológie pre riadenie podniku - M.: Štátna vysoká škola ekonomická, 2003. - 272 s.
5. Lipsits I.V., Kossov V.V. Investičná analýza. Príprava a hodnotenie investícií do reálnych aktív. – M.: INFRA-M, 2014. – 320 s.
6. Svetlov N.M., Svetlová G.N. Informačné technológie projektový manažment - M.: INFRA-M, 2012. - 144 s.
7. Shuremov E. Počítačová analýza podnikania. // Svet PC. – 1998. – Číslo 1. – S. 80–83.
Účinnosť adopcie manažérske rozhodnutia poskytovanie investícií v oblasti malého podnikania v trhových podmienkach do značnej miery závisí od nástrojov používaných na analýzu finančných a ekonomických aktivít podnikov. Výber analytických nástrojov je dôležitý najmä pre administratívne organizačné štruktúry, kedy by rozhodnutie o financovaní projektu malo byť ovplyvnené nielen finančnými ukazovateľmi podniku, ale aj prioritami administratívneho subjektu pod kontrolou tejto organizačnej štruktúry.
Problémy, ktorým je článok venovaný, súvisia s vývojom systémov analýzy podnikových aktivít externých organizácií a riadiacich a kontrolných orgánov. Účelom systémov je nielen zhodnotiť finančnú a ekonomickú kondíciu podniku, ale aj možnosti a vyhliadky na interakciu alebo spoločnú prácu s podnikom. Informačnú bázu analýzy tvoria ukazovatele získané tak či onak zo štandardného účtovníctva, štatistické vykazovanie a otvorených zdrojov.
Spomedzi existujúcich systémov finančnej analýzy možno vyzdvihnúť vývoj spoločností ako Expert Systems, Galaktika, INEC, Alt-Invest, avšak ich efektívne využitie bez úprav administratívnymi organizačnými štruktúrami je problematické, keďže tieto systémy neriešia problémy hodnotenia projektu. v súvislosti s prioritou parametrov pre administratívna štruktúra, ale nie finančného charakteru.
Štruktúra informačného systému
Potreba a relevantnosť kvalitatívnej analýzy toku investičných projektov a existujúce rozdiely v záujmoch bežného investora a investora v podobe administratívnej organizačnej štruktúry presúvajú problém výberu nástroja do roviny jeho rozvoja. V tomto prípade je vhodné priradiť vyvinutému systému riešenie nasledujúcich úloh:
Analýza finančnej situácie podniku vrátane dynamiky;
Analýza finančnej časti podnikateľského plánu projektu;
Analýza vplyvu pôžičky na finančnú situáciu podniku;
Zohľadnenie priorít mesta počas procesu analýzy projektu;
Porovnávacia analýza projektov viacerých podnikov;
Prognóza rozvoja podnikania a splácania úverov.
Na základe vlastností a charakteru úloh bola vyvinutá bloková schéma analytického systému, znázornená na obrázku.
Externý modul systému je autonómny program, ktorý je určený na prípravu prvotných informácií potrebných pre rozhodnutie o pridelení úveru na financovanie navrhovaného projektu:
Súvaha a ďalšie doklady k súvahe;
Finančná časť podnikateľského plánu projektu;
Ďalšie informácie potrebné na zohľadnenie priorít správneho orgánu.
Modul umožňuje ako priame zadávanie informácií pomocou klávesnice, tak aj obsluhu v režime importu dát z iných systémov. Externý modul zároveň kontroluje správnosť zadávania informácií, aby sa eliminovali neúmyselné chyby.
Štruktúra hlavnej časti systému je zameraná na implementáciu prvkov analýzy investičných projektov.
Kľúčovú úlohu zohráva „Modul pre nastavenie pracovného prostredia a expertného systému“. Tento modul vyrába rôzne scenáre analýza, definícia dodatočné pravidlá a kritériá, ktoré odrážajú záujmy mesta a správy, stanovujú kritické hodnoty finančných ukazovateľov.
„Modul na výpočet finančných ukazovateľov“ počíta finančné pomerové ukazovatele.
Bloková schéma informačného systému pre analýzu investičných projektov
Modul „Projektová analýza a vizualizácia výsledkov“ prezentuje výsledky analýzy analytickým, grafickým a tabuľkovým spôsobom.
"Modul generovania správ" je spojený so štandardom softvér a je určený na prípravu spravodajských materiálov.
Expertný systém je navrhnutý tak, aby pomáhal pri analýze získaných výsledkov.
Metodika analýzy investičných projektov
Metodika analýzy investičných projektov pozostáva z komplexnej analýzy finančnej situácie podniku spolu s hodnotením samotného investičného projektu a stanovením hodnotenia projektu pre ďalšie rozhodovanie o pridelení úverov.
Existuje mnoho počiatočných ukazovateľov, ktoré sú rozdelené do skupín, ktoré charakterizujú jednotlivé aspekty finančnej kondície organizácie. Tieto skupiny ukazovateľov sú sústredené v samostatných dokumentoch, napríklad účtovná správa a pod.
Existujú teda L-skupiny počiatočných ukazovateľov, kde a L-skupiny relatívnych ukazovateľov, kde l je číslo skupiny a kl je poradové číslo ukazovateľa v skupine.
Na základe primárnych ukazovateľov sa vytvárajú Q-skupiny sekundárnych ukazovateľov, kde q = 1, Q, , a mq je poradové číslo ukazovateľa v q-tej skupine. Tieto ukazovatele budeme nazývať koeficienty.
Na základe ukazovateľov sa vytvárajú ukazovatele dynamiky ich zmeny v absolútnych a relatívnych jednotkách formulára
kde j - charakterizuje počet meraní ukazovateľa alebo koeficientu.
Každý ukazovateľ a koeficient sa zaznamenáva v niekoľkých časových bodoch. Získané hodnoty umožňujú identifikovať dynamiku zmien ukazovateľov a koeficientov v čase:
Potom I = J + 1.
Pre koeficienty boli stanovené podmienky. Súlad koeficientov s podmienkami ukazuje, že stav všeobecnej charakteristiky finančnej situácie podniku, ktorá je určená týmto koeficientom, je normálny.
V procese analýzy podnikateľského projektu sa riešia aspoň tri základné úlohy:
a) posúdenie možnosti splatenia úveru príslušným podnikom, a teda rozhodnutie zaradiť ho do zoznamu potenciálne vhodných na poskytnutie úveru;
b) posúdenie možnosti pôžičiek na základe priorít správy;
Tieto problémy sú riešené v rámci viacúrovňovej analýzy koeficientov a ukazovateľov.
Analýza sa vykonáva výpočtom koeficientov a hodnotením podmienok. Koeficienty sú rozdelené v rámci skupín do podskupín viac a menej dôležitých. Prvá úroveň analýzy je spojená s hodnotením splnenia podmienok pre vybrané podskupiny koeficientov a rieši najmä problém
a) Na druhej a ďalších úrovniach sa analyzujú ďalšie koeficienty a ukazovatele, ako aj dynamika ich zmien.
Výsledky analýzy sú prezentované vo forme samostatných dokumentov, ktoré poskytujú charakteristiku rôznych aspektov činnosti podniku a navrhovaného projektu.
V ďalšej fáze sa vytvorí hodnotenie projektu podľa položky
b) Na zohľadnenie záujmov správy sa zavádza ďalšia skupina ukazovateľov (fh) a podmienok (χh), kde h = 1,H. Tieto ukazovatele môže podnik vypočítať alebo vykázať. Ak spoločnosť nespĺňa kritériá, je vylúčená zo skupiny potenciálnych veriteľov.
a) vytvárajú sa možnosti určovania ratingu investičných projektov zameraných na hodnotenie v určitej oblasti, napríklad v oblasti výroby produkty na jedenie atď. Hlavné rozdiely medzi možnosťami, alebo ich nazvime scenármi, sú tieto:
V skupinách relatívnych ukazovateľov a koeficientov sú identifikované jednotlivé prvky, ktoré sa budú brať do úvahy pri určovaní hodnotenia projektu v danom scenári, t.j.
kde ζ je číslo scenára;
Pre vybrané ukazovatele a koeficienty sú stanovené váhy, ktoré charakterizujú vplyv tohto ukazovateľa na rating v tejto skupine, t.j. resp
Váhy sa určujú aj pre skupiny ukazovateľov a koeficientov podieľajúcich sa na hodnotení, t.j. , kde d ζ je číslo skupiny a D ζ je celkový počet skupín zúčastňujúcich sa hodnotenia;
Hmotnosti sú menšie ako 1, súčet hmotností každej sady v celej vzorke sa rovná 1.
b) pre skupinu hodnotených projektov sa vytvorí verzia najlepšieho podniku. Najlepšia podniková verzia je súborom predtým identifikovaných ukazovateľov s najlepšími hodnotami v celom súbore, t.j. hodnoty týchto ukazovateľov môžu patriť rôznym podnikom. Táto verzia nie je spojená so skutočným objektom a používa sa na účely hodnotenia. Všetky ďalšie vzťahy pre posúdenie ratingu sú uvedené len pri koeficientoch. Podobné vzorce sú konštruované pre parametre a fh.
Vzniká tak množina ukazovateľov, kde , ak čím vyššie , tým lepšie a inak. Tu s je číslo podniku na zozname a je to hodnota koeficientu pre tento podnik.
kde, ak rast koeficientu charakterizuje zlepšenie finančnej situácie podniku a
e) čím vyššie R ζ s, tým vyššie hodnotenie daného podniku v ζtom scenári hodnotenia.
Normalizáciou (R ζ s) podľa , môžete usporiadať podniky vo vzostupnom alebo zostupnom poradí ich hodnotenia. Hodnotenie pomocou indikátorov a fh je možné vykonať samostatne.
Záver
Predložená metodika umožňuje v procese rozhodovania o pridelení úverov zoradiť investičné projekty nielen podľa finančných ukazovateľov, ale zohľadňovať aj priority administratívnej organizačnej štruktúry, ktoré priamo nesúvisia s finančným stav organizácie, ktorá sa zúčastňuje súťaže.
Informačný systém tak po implementácii bude silným nástrojom, ktorý obsahuje účinné mechanizmy na podporu rozhodovania v oblasti investičných aktivít a je zameraný na poskytovanie analýzy tak finančnej situácie podnikov, ako aj investičných projektov predkladaných do súťaž.
Bibliografický odkaz
Klevtsov S.I., Klevtsova A.B. MODEL INFORMAČNÉHO SYSTÉMU PRE ANALÝZU INVESTIČNÝCH PROJEKTOV PRE ADMINISTRATÍVNE ŠTRUKTÚRY // Základný výskum. – 2016. – č.12-1. – S. 58-61;URL: http://fundamental-research.ru/ru/article/view?id=41046 (dátum prístupu: 26.04.2019). Dávame do pozornosti časopisy vydávané vydavateľstvom „Akadémia prírodných vied“
Návrh informačných systémov
Časť 1. Etapy vývoja projektu: stratégia a analýza
Úvod "Vodopád" - diagram vývoja projektu Stratégia Analýza ER diagramy Oblúky Normalizácia Diagramy toku údajov Niektoré zásady pre kontrolu kvality a úplnosti informačného modelu Kvalita entity Priraďte kvalitu Kvalita pripojenia Systémové funkcie Objasnenie stratégie
Úvod
Návrh informačných systémov vždy začína definovaním účelu projektu. Hlavnou úlohou každého úspešného projektu je zabezpečiť, aby v čase spustenia systému a počas celej jeho prevádzky bolo možné zabezpečiť:
požadovaná funkčnosť systému a stupeň prispôsobenia meniacim sa podmienkam jeho prevádzky;
požadovaná kapacita systému;
požadovaný čas odozvy systému na požiadavku;
bezproblémová prevádzka systému v požadovanom režime, inými slovami pripravenosť a dostupnosť systému na spracovanie požiadaviek používateľov;
jednoduchosť prevádzky a podpora systému;
potrebné zabezpečenie.
Výkon je hlavným faktorom, ktorý určuje efektívnosť systému. Dobrý dizajn je základom vysokovýkonného systému.
Návrh informačných systémov pokrýva tri hlavné oblasti:
navrhovanie dátových objektov, ktoré budú implementované v databáze;
navrhovanie programov, obrazovkových formulárov, zostáv, ktoré zabezpečia vykonávanie dátových dotazov;
s prihliadnutím na konkrétne prostredie alebo technológiu, a to: topológiu siete, hardvérovú konfiguráciu, použitú architektúru (file-server alebo klient-server), paralelné spracovanie, distribuované spracovanie dát a pod.
V reálnych podmienkach je dizajn hľadaním metódy, ktorá spĺňa požiadavky na funkčnosť systému s využitím dostupných technológií s prihliadnutím na dané obmedzenia.
Každý projekt podlieha množstvu absolútnych požiadaviek, napríklad maximálny čas vývoja projektu, maximálne peňažné investície do projektu atď. Jednou z ťažkostí dizajnu je, že nejde o tak štruktúrovanú úlohu, ako je analýza požiadaviek projektu alebo implementácia konkrétneho konštrukčného riešenia.
Predpokladá sa, že komplexný systém v zásade nemožno opísať. Týka sa to najmä systémov riadenia podnikov. Jedným z hlavných argumentov je zmena prevádzkových podmienok systému, napríklad direktívna zmena niektorých informačných tokov novým vedením. Ďalším argumentom je objem technických špecifikácií, ktoré môžu byť pri veľkom projekte stovky strán, pričom technický projekt môže obsahovať chyby. Vynára sa otázka: možno je lepšie nerobiť prieskumy vôbec a nerobiť žiadny technický projekt, ale napísať systém „od nuly“ v nádeji, že dôjde k nejakej zázračnej zhode želaní zákazníka s tým, čo napísali programátori, a tiež, že toto všetko bude fungovať stabilne?
Keď sa na to pozriete, je vývoj systému naozaj taký nepredvídateľný a je naozaj nemožné získať o ňom informácie? Predstavu o systéme ako celku a spôsoboch jeho rozvoja navrhovaných (manažmentom) možno získať pravdepodobne prostredníctvom seminárov. Potom rozložte komplexný systém na jednoduchšie komponenty, zjednodušte prepojenia medzi komponentmi, zabezpečte nezávislosť komponentov a popíšte rozhrania medzi nimi (tak, aby zmena jedného komponentu neznamenala automaticky významnú zmenu komponentu iného), pretože ako aj možnosť rozšírenia systému a „stubov“ pre nerealizovateľné v tej či onej verzii funkčného systému. Na základe takýchto elementárnych úvah sa už popis toho, čo sa má v informačnom systéme implementovať, nezdá až taký nereálny. Môžete sa držať klasických prístupov k vývoju informačných systémov, z ktorých jedným je schéma „vodopád“ ( ryža. 1) - popísané nižšie. Stručne budú diskutované aj niektoré ďalšie prístupy k vývoju informačných systémov, kde je akceptovateľné aj použitie prvkov popísaných v „vodopádovom“ diagrame. Ktorý z nižšie popísaných prístupov nasledovať (a či má zmysel vymýšľať si vlastný prístup) je do istej miery vecou vkusu a okolností.
Ryža. 1. Schéma vodopádu
Životný cyklus softvéru je vzorom jeho tvorby a používania. Model odzrkadľuje jeho rôzne stavy, počnúc okamihom, keď vznikne potreba tohto softvéru, a končiac okamihom, keď je úplne mimo používania pre všetkých používateľov. Sú známe nasledujúce modely životného cyklu:
Kaskádový model. Prechod do ďalšej fázy znamená úplné dokončenie práce v predchádzajúcej fáze.
Krokový model so stredným ovládaním. Vývoj softvéru prebieha v iteráciách s cyklami spätná väzba medzi etapami. Medzietapové úpravy umožňujú znížiť náročnosť vývojového procesu v porovnaní s vodopádovým modelom; Životnosť každého štádia trvá počas celého vývojového obdobia.
Špirálový model. Osobitná pozornosť sa venuje počiatočným fázam vývoja - vývoju stratégie, analýze a návrhu, kde sa testuje a zdôvodňuje realizovateľnosť určitých technických riešení prostredníctvom vytvárania prototypov (layout). Každé otočenie špirály zahŕňa vytvorenie určitej verzie produktu alebo niektorého z jeho komponentov, pričom sa objasňujú vlastnosti a ciele projektu, určuje sa jeho kvalita a plánuje sa práca na ďalšom otočení špirály.
Nižšie sa pozrieme na niektoré schémy vývoja projektov.
Na začiatok
"Vodopád" - diagram vývoja projektu
Dizajn sa veľmi často popisuje ako samostatná fáza vývoja projektu medzi analýzou a vývojom. V skutočnosti však neexistuje jasné rozdelenie fáz vývoja projektu - návrh spravidla nemá jasne definovaný začiatok a koniec a často pokračuje vo fáze testovania a implementácie. Pokiaľ ide o štádium testovania, treba tiež poznamenať, že fáza analýzy aj fáza návrhu obsahujú prvky práce testerov, napríklad na získanie experimentálneho zdôvodnenia výberu konkrétneho riešenia, ako aj na vyhodnotenie kvalitatívne kritériá výsledného systému. V prevádzkovej fáze je vhodné hovoriť o údržbe systému.
Nižšie sa pozrieme na každú z fáz, pričom sa podrobnejšie zameriame na fázu návrhu.
Na začiatok
Stratégia
Definovanie stratégie zahŕňa preskúmanie systému. Hlavným cieľom prieskumu je posúdiť skutočný rozsah projektu, jeho ciele a zámery, ako aj získať definície entít a funkcií na vysokej úrovni.
V tejto fáze sú priťahovaní vysokokvalifikovaní obchodní analytici, ktorí majú neustály prístup k vedeniu spoločnosti; Táto fáza zahŕňa úzku interakciu s hlavnými používateľmi systému a obchodnými expertmi. Hlavnou úlohou interakcie je získať čo najúplnejšie informácie o systéme (úplné a jednoznačné pochopenie požiadaviek zákazníka) a odovzdať tieto informácie vo formalizovanej forme systémovým analytikom pre následnú fázu analýzy. Informácie o systéme možno zvyčajne získať prostredníctvom rozhovorov alebo seminárov s vedením, odborníkmi a používateľmi. Týmto spôsobom sa určuje podstata podnikania, perspektívy jeho rozvoja a požiadavky na systém.
Po dokončení hlavnej fázy prieskumu systému technici sformulujú prijateľné technické prístupy a odhadnú náklady na hardvér, zakúpený softvér a vývoj nového softvéru (čo je to, čo projekt v skutočnosti zahŕňa).
Výsledkom fázy definovania stratégie je dokument, ktorý jasne uvádza, čo zákazník dostane, ak bude súhlasiť s financovaním projektu; kedy dostane hotový výrobok (rozvrh práce); koľko to bude stáť (pri veľkých projektoch by sa mal plán financovania zostaviť v rôznych fázach prác). Dokument by mal odrážať nielen náklady, ale aj prínosy, napríklad dobu návratnosti projektu, očakávaný ekonomický efekt (ak sa dá odhadnúť).
Dokument musí popisovať:
obmedzenia, riziká, kritické faktory ovplyvňujúce úspech projektu, napríklad čas odozvy systému na požiadavku je daným obmedzením, a nie žiadúcim faktorom;
súbor podmienok, za ktorých sa očakáva fungovanie budúceho systému: architektúra systému, hardvér a softvérové prostriedky poskytované systému, vonkajšie podmienky jeho fungovania, zloženie ľudí a prác, ktoré zabezpečujú nerušené fungovanie systému;
termíny ukončenia jednotlivých etáp, forma dodania diela, zdroje zapojené do procesu tvorby projektu, opatrenia na ochranu informácií;
popis funkcií vykonávaných systémom;
budúce požiadavky na systém, ak sa rozvinie napríklad schopnosť používateľa pracovať so systémom pomocou internetu a pod.;
entity potrebné na vykonávanie systémových funkcií;
rozhrania a rozdelenie funkcií medzi osobou a systémom;
požiadavky na softvérové a informačné komponenty softvéru, požiadavky na DBMS (ak sa má projekt realizovať pre viacero DBMS, potom požiadavky na každú z nich, príp. Všeobecné požiadavky na abstraktný DBMS a zoznam odporúčaných pre tohto projektu DBMS, ktoré spĺňajú špecifikované podmienky);
ktoré sa v rámci projektu nebudú realizovať.
Dokončené dňa v tomto štádiu Práca nám umožňuje odpovedať na otázku, či sa oplatí v tomto projekte pokračovať a aké požiadavky zákazníkov je možné za určitých podmienok uspokojiť. Môže sa ukázať, že v projekte nemá zmysel pokračovať napríklad z dôvodu, že niektoré požiadavky nie je možné z nejakých objektívnych dôvodov uspokojiť. Ak sa rozhodne pokračovať v projekte, pre ďalšiu fázu analýzy už existuje predstava o rozsahu projektu a odhadoch nákladov.
Je potrebné poznamenať, že vo fáze výberu stratégie, vo fáze analýzy a počas návrhu, bez ohľadu na metódu použitú pri vývoji projektu, by sa plánované funkcie systému mali vždy klasifikovať podľa stupňa dôležitosti. Jeden možný formát na prezentáciu takejto klasifikácie, MoSCoW, je navrhnutý v Clegg, Dai a Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994.
Táto skratka znamená: Must have - potrebné funkcie; Mal by mať - žiaduce funkcie; Mohol mať - možné funkcie; Nebude mať - chýbajúce funkcie.
Implementácia funkcií druhej a tretej kategórie je limitovaná časovým a finančným rámcom: vyvinieme, čo je potrebné, ako aj maximálny možný počet funkcií druhej a tretej kategórie v poradí podľa priorít.
Na začiatok
Analýza
Fáza analýzy zahŕňa detailnú štúdiu podnikových procesov (funkcie definované vo fáze výberu stratégie) a informácií potrebných na ich implementáciu (subjekty, ich atribúty a prepojenia (vzťahy)). V tejto fáze sa vytvorí informačný model a v ďalšej fáze návrhu sa vytvorí dátový model.
Všetky informácie o systéme zhromaždené vo fáze definovania stratégie sú formalizované a objasnené vo fáze analýzy. Osobitná pozornosť by sa mala venovať úplnosti prenášaných informácií, analýze informácií, aby nedošlo k rozporom, ako aj vyhľadávaniu nepoužitých alebo duplicitných informácií. Zákazník spravidla neformuluje hneď požiadavky na systém ako celok, ale formuluje požiadavky na jeho jednotlivé komponenty. Venujte pozornosť konzistencii týchto komponentov.
Analytici zhromažďujú a zaznamenávajú informácie v dvoch vzájomne súvisiacich formách:
funkcie - informácie o udalostiach a procesoch, ktoré sa vyskytujú v podnikaní;
entity – informácie o veciach, ktoré sú pre organizáciu dôležité a o ktorých sa niečo vie.
Dva klasické výsledky analýzy sú:
hierarchia funkcií, ktorá rozkladá proces spracovania na jednotlivé časti (čo sa robí a z čoho pozostáva);
Vstupný model vzťahov (ER model), ktorý popisuje entity, ich atribúty a prepojenia (vzťahy) medzi nimi.
Tieto výsledky sú potrebné, ale nie dostatočné. Dostatočné výsledky zahŕňajú diagramy toku údajov a životné cykly subjektov. Pomerne často dochádza k chybám analýzy pri pokuse zobraziť životný cyklus entity v ER diagrame.
Nižšie sa pozrieme na tri najčastejšie používané metodológie štrukturálnej analýzy:
Entity-Relationship Diagrams (ERD), ktoré slúžia na formalizáciu informácií o subjektoch a ich vzťahoch;
Diagramy toku údajov (DFD), ktoré slúžia na formalizáciu reprezentácie systémových funkcií;
Stavové prechodové diagramy (STD), ktoré odrážajú časovo závislé správanie systému; Diagramy životného cyklu entít patria do tejto triedy diagramov.
Na začiatok
ER diagramy
ER diagramy ( ryža. 2) sa používajú na dátové inžinierstvo a predstavujú štandardný spôsob definovania dát a vzťahov medzi nimi. Vykonáva sa tak detailovanie dátových skladov. ER diagram obsahuje informácie o entitách systému a spôsobe ich interakcie, vrátane identifikácie objektov dôležitých pre predmetnú oblasť (entít), vlastností týchto objektov (atribútov) a ich vzťahov s inými objektmi (odkazy). V mnohých prípadoch je informačný model veľmi zložitý a obsahuje veľa objektov.
Ryža. 2. Príklad ER diagramu
Entita je znázornená ako obdĺžnik s názvom entity v hornej časti (napríklad TITLES). Obdĺžnik môže uvádzať atribúty entity; Atribúty ER diagramu napísané tučným písmom sú kľúčové (napríklad Identita názvu je kľúčovým atribútom entity TITLES, ostatné atribúty nie sú kľúčové).
Vzťah je reprezentovaný čiarou medzi dvoma entitami (modré čiary na obrázku).
Jeden riadok vpravo ( ryža. 3) znamená "jeden", "vtáčia noha", vľavo - "veľa" a vzťah sa číta pozdĺž riadku, napríklad "jeden k mnohým". Zvislá čiara znamená „povinné“, kruh znamená „nepovinné“, napríklad pre každú publikáciu v TITLE musí byť uvedený vydavateľ v PUBLISHERS a jeden vydavateľ v PUBLISHERS môže vydať niekoľko titulov publikácií v TITLES. Treba si uvedomiť, že spoje sú vždy komentované (nápis na riadku znázorňujúci spoj).
Ryža. 3. Prvok ER diagramu
Uveďme aj príklad ( ryža. 4) obrazy reflexívneho vzťahu „zamestnanec“, kde jeden zamestnanec môže riadiť niekoľko podriadených a tak ďalej v hierarchii pozícií.
Ryža. 4. ER diagram reflexného postoja
Treba si uvedomiť, že takýto vzťah je vždy voliteľný, inak pôjde o nekonečnú hierarchiu.
Atribúty entity môžu byť kľúčové – sú zvýraznené tučným písmom; povinné - predchádza im znak „*“, to znamená, že ich hodnota je vždy známa, nepovinné (nepovinné) - predchádza im O, to znamená, že hodnoty tohto atribútu môžu v niektorých prípadoch chýbať alebo nie sú isté momenty.
Na začiatok
Oblúky
Ak má entita súbor vzájomne sa vylučujúcich vzťahov s inými entitami, hovorí sa, že takéto vzťahy sú v oblúku. Napríklad bankový účet môže byť vydaný buď pre právnickú osobu alebo pre individuálne. Fragment ER diagramu pre tento typ vzťahu je zobrazený v ryža. 5.
Ryža. 5. Oblúk
V tomto prípade má atribút VLASTNÍK entity ÚČET pre túto entitu osobitný význam - entita je rozdelená do typov podľa kategórií: „pre fyzickú osobu“ a „pre právnická osoba". Výsledné entity sa nazývajú podtypy a pôvodná entita sa stáva nadtypom. Aby sme pochopili, či je nadtyp potrebný alebo nie, je potrebné zistiť, koľko rovnakých vlastností majú rôzne podtypy. Treba poznamenať, že zneužívanie podtypov a supertypy sú pomerne častou chybou. Sú znázornené nasledovne: ako je uvedené v ryža. 6.
Ryža. 6. Podtypy (vpravo) a nadtypy (vľavo)
Na začiatok
Normalizácia
Aby sa predišlo anomáliám počas spracovania údajov, používa sa normalizácia. Princípy normalizácie pre objekty informačného modelu sú úplne rovnaké ako pre dátové modely.
Prijateľné typy spojení. Bližší pohľad na vzťah jeden k jednému ( ryža. 7) takmer vždy sa ukáže, že A a B sú v skutočnosti rôzne podmnožiny tej istej veci alebo rôzne pohľady na ňu, len majú rôzne názvy a rôzne opísané vzťahy a atribúty.
Ryža. 7. Jednostranné spojenia
Mnoho-jednotné vzťahy sú prezentované v ryža. 8.
Ryža. 8. Mnohostranné vzťahy
I je pomerne silný konštrukt, ktorý znamená, že výskyt entity B nemožno vytvoriť bez súčasného vytvorenia aspoň jedného súvisiaceho výskytu entity A.
II je najbežnejšia forma komunikácie. Predpokladá, že každý jeden výskyt entity A môže existovať iba v kontexte jedného (a iba jedného) výskytu entity B. Výskyty B môžu existovať buď s výskytom A, alebo bez neho.
III - málo používané. A aj B môžu existovať bez akéhokoľvek spojenia medzi nimi.
Vzťahy veľa k mnohým sú prezentované v ryža. 9.
Ryža. 9. Vzťahy veľa k mnohým
I – táto konštrukcia sa často vyskytuje na začiatku fázy analýzy a znamená vzťah – buď nie úplne pochopený a vyžadujúci si dodatočné riešenie, alebo odrážajúci jednoduchý kolektívny vzťah – obojsmerný zoznam.
II - málo používané. Takéto spojenia sú vždy predmetom ďalších podrobností.
Uvažujme teraz o rekurzívnych spojeniach ( ryža. 10).
Ryža. 10. Rekurzívne spojenia
I - zriedkavé, ale vyskytuje sa. Odráža pripojenia alternatívneho typu.
II - pomerne často sa používa na popis hierarchií s ľubovoľným počtom úrovní.
III - vyskytuje sa v počiatočných štádiách. Často odráža štruktúru „rozpisky materiálov“ (vzájomné vkladanie komponentov). Príklad: Každý KOMPONENT môže pozostávať z jedného alebo viacerých (iných) KOMPONENTOV a každý KOMPONENT môže byť použitý v jednom alebo viacerých (iných) KOMPONENTOCH.
Neplatné typy pripojenia. Medzi neplatné typy vzťahu patria: povinný vzťah mnoho k mnohým ( ryža. jedenásť) a množstvo rekurzívnych spojení ( ryža. 12).
Ryža. 11. Neplatné vzťahy typu many-to-many
Ryža. 12. Neplatné rekurzívne vzťahy
Povinný vzťah typu many-to-many je v zásade nemožný. Takýto vzťah by znamenal, že žiadny výskyt A nemôže existovať bez B a naopak. V skutočnosti sa každá takáto konštrukcia vždy ukáže ako chybná.
Na začiatok
Diagramy toku údajov
Logické DFD ( ryža. 13) zobrazuje zdroje a záchytné miesta (príjemcov) údajov mimo systému, identifikuje logické funkcie (procesy) a skupiny dátových prvkov, ktoré spájajú jednu funkciu s druhou (toky), a tiež identifikuje dátové úložiská (jednotky), ku ktorým sa pristupuje. Štruktúry toku údajov a definície ich komponentov sú uložené a analyzované v dátovom slovníku. Každá logická funkcia (proces) môže byť podrobne popísaná pomocou DFD nižšej úrovne; keď ďalšie podrobnosti už nie sú užitočné, prejdite na vyjadrenie logiky funkcie pomocou špecifikácie procesu (minišpecifikácia). Obsah každého úložiska je tiež uložený v dátovom slovníku a dátový model úložiska je odhalený pomocou ER diagramov.
Ryža. 13. Príklad DFD
DFD najmä neukazuje procesy, ktoré riadia skutočný tok údajov a nerozlišuje medzi platnými a neplatnými cestami. DFD obsahujú množstvo užitočných informácií a okrem toho:
umožňujú predstaviť si systém z dátového hľadiska;
ilustrovať externé mechanizmy doručovania údajov, ktoré si budú vyžadovať špeciálne rozhrania;
umožňujú prezentovať automatizované aj manuálne systémové procesy;
vykonávať dátovo-centrické rozdelenie celého systému.
Dátové toky sa používajú na modelovanie prenosu informácií (alebo dokonca fyzických komponentov) z jednej časti systému do druhej. Toky v diagramoch sú reprezentované pomenovanými šípkami; šípky označujú smer, ktorým informácie prúdia. Niekedy sa informácie môžu pohybovať jedným smerom, spracovať sa a vrátiť sa k svojmu zdroju. Táto situácia môže byť modelovaná buď dvoma rôznymi tokmi, alebo jedným obojsmerným.
Proces konvertuje vstupný dátový tok na výstupný tok podľa akcie špecifikovanej názvom procesu. Každý proces musí mať jedinečné číslo pre referenciu v rámci diagramu. Toto číslo možno použiť v spojení s číslom diagramu na poskytnutie jedinečného indexu procesu pre celý model.
Ukladanie údajov umožňuje definovať údaje v množstve oblastí, ktoré sa budú ukladať do pamäte medzi procesmi. V skutočnosti sklad predstavuje „výrezy“ dátových tokov v priebehu času. Informácie, ktoré obsahuje, je možné použiť kedykoľvek po ich určení a údaje je možné vyberať v ľubovoľnom poradí. Názov úložiska musí identifikovať jeho obsah. V prípade, že dátový tok vstupuje (vystupuje) zo skladu a jeho štruktúra sa zhoduje so štruktúrou skladu, musí mať rovnaký názov, ktorý sa nemusí prejaviť v diagrame.
Externá entita (terminátor) predstavuje entitu mimo kontextu systému, ktorá je zdrojom alebo príjemcom systémových údajov. Jej meno musí obsahovať podstatné meno, napríklad „Klient“. Neočakáva sa, že objekty reprezentované takýmito uzlami sa budú podieľať na akomkoľvek spracovaní.
Na začiatok
Diagramy prechodu stavu STD
Životný cyklus entity patrí do triedy STD diagramov ( ryža. 14). Tento diagram ukazuje zmenu stavu objektu v priebehu času. Zvážte napríklad stav produktu v sklade: produkt možno objednať od dodávateľa, prijať na sklad, uskladniť v sklade, prejsť kontrolou kvality, predať, odmietnuť alebo vrátiť dodávateľovi. Šípky na diagrame označujú prijateľné zmeny stavu.
Obr. 14. Príklad DFD
Existuje niekoľko rôznych možností na zobrazenie takýchto diagramov, obrázok zobrazuje iba jednu z nich.
Na začiatok
Niektoré princípy kontroly kvality a úplnosti informačného modelu (zdroj - Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)
Ak chcete vytvoriť kvalitný model, budete sa musieť uchýliť k pomoci analytikov, ktorí ovládajú technológiu CASE. To však neznamená, že do budovania a monitorovania informačného modelu by mali byť zapojení iba analytici. Veľmi užitočná môže byť aj pomoc od kolegov. Zapojte ich do kontroly stanoveného cieľa a do podrobného štúdia zostrojeného modelu ako z hľadiska logiky, tak aj z hľadiska zohľadnenia aspektov predmetnej oblasti. Pre väčšinu ľudí je ľahšie nájsť chyby v práci niekoho iného.
Pravidelne odosielajte svoj informačný model alebo jeho časti, ktoré vás znepokojujú, na schválenie používateľom. Venujte zvláštnu pozornosť výnimkám a obmedzeniam.
Na začiatok
Kvalita entity
Hlavnou zárukou kvality entity je odpoveď na otázku, či je objekt skutočne entitou, teda dôležitým objektom alebo javom, o ktorom by mala byť informácia uložená v databáze.
Zoznam overovacích otázok pre entitu:
Odráža názov entity podstatu tohto objektu?
Existuje nejaký presah s inými subjektmi?
Existujú aspoň dva atribúty?
Celkovo nie je viac ako osem atribútov?
Existujú nejaké synonymá/homonymá pre túto entitu?
Je entita úplne definovaná?
Existuje jedinečný identifikátor?
Existuje aspoň jedno spojenie?
Existuje aspoň jedna funkcia na vytváranie, vyhľadávanie, úpravu, odstraňovanie, archiváciu a používanie hodnoty entity?
Existuje história zmien?
Dodržiavajú sa zásady normalizácie údajov?
Existuje rovnaká entita v inom aplikačnom systéme, možno pod iným názvom?
Je podstata príliš všeobecná?
Je miera zovšeobecnenia v ňom obsiahnutá dostatočná?
Zoznam skríningových otázok pre podtyp:
Existuje nejaké prekrývanie s inými podtypmi?
Má podtyp nejaké atribúty a/alebo vzťahy?
Majú všetci svoje vlastné jedinečné identifikátory alebo dedia jeden pre všetkých od nadtypu?
Existuje komplexný súbor podtypov?
Nie je podtyp príkladom výskytu entity?
Poznáte nejaké atribúty, vzťahy alebo podmienky, ktoré odlišujú tento podtyp od ostatných?
Na začiatok
Priraďte kvalitu
Je potrebné zistiť, či ide skutočne o atribúty, teda či túto entitu tak alebo onak vystihujú.
Zoznam otázok na overenie atribútov:
Je názov atribútu podstatné meno v jednotnom čísle, ktoré odráža podstatu vlastnosti označenej atribútom?
Nezahŕňa názov atribútu názov entity (nemal by)?
Má atribút vždy iba jednu hodnotu?
Existujú nejaké duplicitné hodnoty (alebo skupiny)?
Je popísaný formát, dĺžka, prijateľné hodnoty, algoritmus získavania atď.?
Môže byť tento atribút chýbajúcou entitou, ktorá by bola užitočná pre iný aplikačný systém (existujúci alebo navrhovaný)?
Môže to byť zmeškané spojenie?
Je potrebná história zmien?
Závisí jeho význam iba od tejto entity?
Ak je hodnota atribútu povinná, je vždy známa?
Je potrebné vytvoriť doménu pre tento a podobné atribúty?
Závisí jeho hodnota iba od nejakej časti jedinečného identifikátora?
Závisí jeho hodnota od hodnôt niektorých atribútov, ktoré nie sú zahrnuté v jedinečnom identifikátore?
