Štandardy a šablóny pre TK pre vývoj softvéru. Tvorba technických špecifikácií pre informačný systém

29.07.2019

Originalita IP ako produktu na priemyselné účely, vyjadrená v jeho zložitosti, pri absencii noriem pre väčšinu typov postupov a prác, robí proces ich plánovania a navrhovania veľmi zložitým a náročným. Keď podnik komunikuje s vývojárom IS na akýkoľvek účel, na začatie práce sú potrebné dva hlavné dokumenty: dohoda a technická úloha (TOR). Kompilácia TOR je samostatná úloha. Samotné zadávacie podmienky sú v skutočnosti dokumentom, ktorý odráža všetky želania zákazníka, mal by byť vypracovaný čo najpodrobnejšie a uvádzať všetky podrobnosti a víziu výsledku. Až na jeho základe sa určí, čo sú vývojári povinní urobiť, preto by mali byť zadávacie podmienky vypracované čo najpodrobnejšie.

Pri návrhu akýchkoľvek informačných systémov je potrebný ich podrobný popis. Na tieto účely môžete použiť rôzne metódy a metódy, ale najefektívnejším riešením je vypracovanie technickej úlohy (TOR), ktorá popisuje ciele, ciele, rozhranie a ďalšie požiadavky na vyvíjaný objekt.

Zadanie je dokument, ktorý definuje ciele, požiadavky a základné vstupné údaje potrebné pre vývoj IS. ToR for IP je hlavný dokument, ktorý definuje požiadavky a postup na vytvorenie, rozvoj alebo modernizáciu IP, v súlade s ktorými sa vykonáva jeho vývoj, uvedenie do prevádzky a akceptácia.

Úspech pri implementácii IS spočíva v správnosti zadania úlohy zadanej zákazníkom. Ak sú splnené všetky potrebné podmienky na napísanie dobrej TK, potom sa výsledok zmení z očakávaného na realizovateľný.

samotným zákazníkom;

dodávateľom, ale v tomto prípade budú jeho povinnosti zahŕňať návrh a testovanie;

konkurenčných vykonávateľov, ktorých povinnosti zahŕňajú iba spísanie TOR;

tretími stranami.

Pre tie TK, ktoré napíše dodávateľ, existuje niekoľko regulačných dokumentov:

GOST 21.408-93 "Pravidlá implementácie pracovnej dokumentácie pre automatizáciu technologických procesov";

GOST 34.201-89 "Typy, úplnosť a označovanie dokumentov pri vytváraní automatizovaných systémov";

GOST 24.703-85 „Typické konštrukčné riešenia v automatizovaných riadiacich systémoch. Základné ustanovenia“;

GOST 34.003-90 „Automatizované systémy. Pojmy a definície";

GOST 34.601-90 „Automatizované systémy. Etapy tvorby“;

GOST 34.602-90 "Referenčné podmienky pre vytvorenie automatizovaného systému";

GOST 19.201-78 Jednotný systém programovej dokumentácie;

GOST 2.114-95 Jednotný systém pre projektovú dokumentáciu.

TK pre DV je zoznam hlavných prevádzkových, technologických, technických, organizačných, softvérových, informačno-logických a jazykových, ekonomických a iných požiadaviek, ktoré musí DV spĺňať vo všetkých fázach svojej existencie.

TK je textový dokument vypracovaný v akejkoľvek forme. Potrebné výkresy, schémy a veľké tabuľky sa odporúča vyhotoviť vo forme príloh. V závislosti od typu, účelu a špecifických vlastností objektu automatizácie a prevádzkových podmienok systému je možné zostaviť časti TOR vo forme aplikácií, zaviesť ďalšie, vylúčiť alebo kombinovať jeho podsekcie.

Neexistujú žiadne konkrétne odporúčania, čo má CK obsahovať, to znamená, že oddiely a pododdiely musia byť vypracované a umiestnené spôsobom stanoveným zhotoviteľom. Existujú len všeobecné charakteristiky sekcií a podsekcií. Vývojár môže nezávisle meniť, pridávať a upravovať ich meno a číslo.

Čísla hárkov (strán) sa uvádzajú od prvého hárku po titulnej strane v hornej časti hárku (nad textom, v strede) za označením kódu TK na IP.

Na titulnej strane sú umiestnené podpisy objednávateľa, developera a koordinačnej spoločnosti, ktoré sú zapečatené. Ak je to potrebné, titulná strana je zostavená na niekoľkých stranách. Podpisy spracovateľov TK a úradníkov podieľajúcich sa na schvaľovaní a posudzovaní návrhu TK na IP sú umiestnené na poslednej strane.

Titulná strana Dodatku k TOR je vyhotovená rovnakým spôsobom ako titulná strana zadávacích podmienok. Namiesto názvu „Terms of Reference“ píšu „Dodatok č. ... k TOR pre AC ... “

Na nasledujúcich listoch dodatku k ZZ je uvedený dôvod zmeny, obsah zmeny a odkazy na dokumenty, v súlade s ktorými sa tieto zmeny vykonávajú.

Pri predkladaní textu dodatku k ZD treba uviesť čísla príslušných odsekov, pododsekov, tabuliek hlavného ZD a pod. a slová „nahradiť“, „doplniť“, „vypustiť“, „uviesť v by sa malo použiť nové vydanie“.

V počiatočnej fáze vývoja TOR vytvorí dodávateľ približný obsahový plán.

Všeobecné informácie;

Účel a účel vytvorenia systému;

Charakteristika objektu automatizácie;

Požiadavky na systém;

Prevádzkové podmienky;

Požiadavky na softvérovú dokumentáciu;

Technické a ekonomické ukazovatele;

Etapy a štádiá vývoja;

Postup kontroly a prijatia.

Tieto sekcie možno rozdeliť na podsekcie. TOR môže tiež zahŕňať aplikácie, ktoré sú opísané podľa zavedených štandardov. Zhotoviteľ môže v prípade potreby potrebné úseky doplniť, vymazať, všetky tieto faktory je potrebné dohodnúť s objednávateľom. Dodržiavaním stanoveného plánu môže umelec kvalitatívne a v krátkom čase vypracovať technické špecifikácie.

V prípade potreby zhotoviteľ vytvorí zoznam akceptovaných skratiek a slovník pojmov.

Zadania pre vývoj IS zdravotníckeho zariadenia sú uvedené v prílohe B.

Nedávno ma oslovili, aby som poradil štandardy pre písanie referenčných podmienok (TOR) pre vývoj automatizovaných systémov (AS) a softvéru (SW). Takže si myslím, že teraz pôjdem na Yandex, nájdem vhodný článok a pošlem ho. Ale to tam nebolo! Nenašiel som jeden článok s uvedením štandardov pre TK vrátane šablón a príkladov hotových dokumentov. Musím si spraviť vlastný článok...

A tak hlavné štandardy, metodiky a kódexy znalostí, kde sa spomína TK alebo SRS (Software (alebo System) Requirements Specification):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK atď.

GOST 34

GOST 34.602-89 Referenčné podmienky pre vytvorenie automatizovaného systému upravuje štruktúru TOR pre vytvorenie SYSTÉMU, ktorý zahŕňa softvér, hardvér, ľudí, ktorí pracujú so softvérom, a automatizované procesy.

Podľa GOST 34 by referenčné podmienky mali obsahovať tieto oddiely:

1. Všeobecné informácie
2. Účel a ciele tvorby (vývoja) systému
3. Charakteristika objektov automatizácie
4. Systémové požiadavky
5. Skladba a obsah práce na tvorbe systému
6. Postup kontroly a preberania systému
7. Požiadavky na skladbu a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky
8. Požiadavky na dokumentáciu
9. Zdroje rozvoja

Pri vývoji technických špecifikácií pre vládne projekty zákazníci spravidla vyžadujú dodržiavanie tejto konkrétnej normy.

GOST 19

“GOST 19.xxx Unified System for Program Documentation (ESPD)” je súbor štátnych noriem, ktoré stanovujú vzájomne prepojené pravidlá pre vývoj, dizajn a obeh programov (alebo softvéru) a programovej dokumentácie. Tie. Táto norma platí špeciálne pre vývoj softvéru.
Podľa zadávacích podmienok GOST 19.201-78 by požiadavky na obsah a dizajn zadávacích podmienok mali zahŕňať tieto oddiely:

1. Úvod;
2. Dôvody rozvoja;
3. Účel rozvoja;
4. Požiadavky na program alebo softvérový produkt;
5. Požiadavky na softvérovú dokumentáciu;
6. Technické a ekonomické ukazovatele;
7. Štádiá a štádiá vývoja;
8. Poradie kontroly a prijatia;
9. Aplikácie.

Prirodzene, GOST 34 (a 19) sú už zastarané a nerád ich používam, ale so správnou interpretáciou noriem môžete získať dobrú TK, pozri Záver.

IEEE STD 830-1998

Pomerne dobrá definícia štandardu 830-1998 – odporúčaná prax IEEE pre špecifikácie softvérových požiadaviek je uvedená v jeho samotnom popise:

Opisuje sa obsah a kvalitatívne charakteristiky dobre napísanej špecifikácie softvérových požiadaviek (SRS) a poskytuje sa niekoľko šablón SRS. Tento odporúčaný postup je určený na stanovenie požiadaviek na vyvíjaný softvér, ale môže sa použiť aj na pomoc pri výbere proprietárnych a komerčných softvérových produktov.

Podľa normy by referenčné podmienky mali obsahovať tieto časti:

1. Úvod

1. Vymenovanie
2. Rozsah pôsobnosti
3. Definície, akronymy a skratky
4. Odkazy
5. Prehľad

2. Všeobecný popis

1. Interakcia produktu (s inými produktmi a komponentmi)
2. Vlastnosti produktu (stručný popis)
3. Užívateľské vlastnosti
4. Obmedzenia
5. Predpoklady a závislosti

3. Podrobné požiadavky (môžu byť organizované rôznymi spôsobmi, napr.

1. Požiadavky na externé rozhrania
- 1. Používateľské rozhrania
- 2. Hardvérové rozhrania
- 3. Softvérové rozhrania
- 4. Interakčné rozhrania
2. Funkčné požiadavky
3. Požiadavky na výkon
4. Obmedzenia návrhu (a odkazy na normy)
5. Nefunkčné požiadavky (spoľahlivosť, dostupnosť, bezpečnosť atď.)
6. Iné požiadavky

4. Aplikácie
5. Abecedný register

V skutočnosti je pre začiatočníka dosť ťažké pochopiť, čo by malo byť obsiahnuté v týchto častiach podľa vyššie uvedenej štruktúry (ako v prípade GOST), takže si musíte prečítať samotnú normu, ktorá. , však v angličtine. Jazyk.

No pre tých, ktorí to dočítali až do konca, je tu bonus: príklad TK, ktorý som napísal pred mnohými rokmi (teraz už dávno nepracujem ako analytik a ďalšie úspešnejšie príklady sú zakázané sprístupní verejnosti NDA).

Prezentácia Yuryho Buluya Klasifikácia softvérových požiadaviek a jej reprezentácia v štandardoch a metodikách.
Analýza požiadaviek na automatizované informačné systémy. Prednáška 11: Požiadavky na dokumentáciu.
Pravidlá pre zostavovanie špecifikácií softvérových požiadaviek (čítajte s komentármi)
Príklady TOR a inej dokumentácie pre vývoj AS pre Ministerstvo hospodárskeho rozvoja
GOST-ovsky štýl riadenia. Gapertonov článok o správnej práci s TK podľa GOST
Šablóny dokumentov pre obchodných analytikov z

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

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

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

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

Úvod

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

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

TK pozostáva z troch fáz:

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

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

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

TK vykonáva tieto funkcie:

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

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

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

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

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

1. Referenčné podmienky

1.1 Všeobecné informácie

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

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

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

1.2 Základ pre rozvoj

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

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

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

1.3 Účel a ciele tvorby systému

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

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

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

1.4 Systémové požiadavky

1.4.1 Požiadavky na systém ako celok

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

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

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

Prijatie objednávky;

Vydanie lístka;

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

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

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

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

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

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

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

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

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

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

Požiadavky na spoľahlivosť

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

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

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

Bezpečnostné požiadavky

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

subsystém prijímania objednávok,

Subsystém zúčtovania s klientom.

1.4.3 Požiadavky na typy kolaterálu

K informačnej podpore systému

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

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

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

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

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

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

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

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

Požiadavky na systémový softvér

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

Hardvérové požiadavky systému

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

Pracovné stanice;

Jednotka neprerušovaného napájania;

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

Tlačiareň.

Technické prostriedky si objednávateľ kupuje samostatne.

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

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

telesné požiadavkysystémová izolácia

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

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

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

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

Organizačná podpora by mala byť dostatočná na to, aby pracovníci mohli efektívne plniť úlohy, ktoré im boli pridelené pri implementácii funkcií systému.

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

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

1.5 Charakteristika objektov automatizácie

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

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

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

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

1.6 Požiadavky na dokumentáciu

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

Schéma organizačnej štruktúry;

Schéma funkčnej štruktúry;

Zoznam vstupných signálov a údajov;

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

Vysvetlivka k technickému projektu;

Popis automatizovaných funkcií;

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

Popis organizácie informačnej základne;

Popis súboru informácií;

Popis softvéru;

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

1.7 Etapy a štádiá vývoja

1.7.1 Etapy vývoja

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

1. Vývoj zadávacích podmienok

2. Vypracovanie projektovej dokumentácie

3. Vytvorenie návrhu návrhu

4. Detailný dizajn

5. Uvedenie do prevádzky

6. Údržba a modernizácia

1.7.2 Etapy vývoja

V štádiu vypracovania zadávacích podmienok musí byť ukončené štádium vypracovania, koordinácie a schválenia tohto zadania.

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

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

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

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

2) vypracovanie dokumentácie.

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

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

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

1) vyhlásenie o probléme;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Analýza požiadaviek na IP

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

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

4. Vypracovanie zadania a projektu

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

6. Vypracovanie plánu práce

7. Príprava hardvéru

8. Vývoj softvéru

9. Skontrolujte kompatibilitu hardvéru a softvéru

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

11. Vykonávanie zmien

12. Vypracovanie návodu na obsluhu IS

13. Registrácia kompletnej dokumentácie pre IP

14. Doručenie IP zákazníkovi

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

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

Obrázok 1 – Stanovenie cieľov

Obrázok 2 - Ganttov diagram

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

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

Tabuľka 2 - Časové parametre udalostí

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

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

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

1.8 Postup kontroly a akceptácie systému

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

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

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

Dodanie a prevzatie je realizované komisiou, ktorej členmi sú zástupcovia objednávateľa a zhotoviteľa. Na základe výsledkov akceptácie sa podpisuje akt akceptačnej komisie.

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

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

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

2. Technický projekt

2.1 Funkčná štruktúra

2.1.1 Popis predmetnej oblasti

Predmetnou oblasťou je agentúra predávajúca a rezervujúca letenky.

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

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

2.1.2 Funkcie a organizačná štruktúra

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

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

riaditeľ;

Administratívne oddelenie;

Oddelenie prevádzky pracovných staníc;

Operátorské oddelenie.

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

Obrázok 4 - Organizačný model

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

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

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

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

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

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

Modelovanie obchodných procesov

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

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

1. Prijatie objednávky.

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

3. Vysporiadanie so zákazníkom.

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

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

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

Diagramy stromu uzlov;

Grafy len s expozíciou (FEO).

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

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

Diagram toku údajov

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

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

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

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

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

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

2.2 Návrh IC systému

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

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

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

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

súborový server;

Klientsky server;

vrstvená architektúra.

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

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

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

škálovateľnosť;

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

vysoká bezpečnosť;

vysoká spoľahlivosť;

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

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

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

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

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

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

vysoká zložitosť administrácie.

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

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

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

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

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

Informačné;

Technické;

Softvér;

matematické;

Jazykovedné.

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

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

funkčná štruktúra;

informačná podpora;

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

Technická podpora;

organizačná podpora,

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

právne;

lingvistické;

Technologické;

metodologické;

Rozhrania s externým IS.

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

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

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

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

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

2.2.3 Technická podpora IS

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

Pracovné stanice;

Neprerušiteľné zdroje napájania;

Nástroje na budovanie LAN;

Databázový server;

Tlačiareň.

Požiadavky na server:

Pamäť 8 GB;

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

Rýchlosť disku SATA 8 Gb/s;

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

Operačný systém Windows Server 2008.

Požiadavky na pracovnú stanicu:

Procesor 2 GHz;

Pamäť 2 GB;

Pevný disk nie menej ako 500;

Operačný systém Windows 7;

Sieťový adaptér 100 Mbps.

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

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

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

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

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

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

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

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

2.3 Informačná podpora IP

2.3.1 Popis logickej štruktúry infobázy

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

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

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

Vylúčenie niektorých typov redundancie;

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

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

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

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

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

2.3.2 Popis fyzickej implementácie databázy

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

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

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

Záver

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

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

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

- bola vykonaná analýza predmetnej oblasti;

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

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

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

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

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

Bibliografia

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

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

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

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

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

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

Hostené na Allbest.ru

...

Podobné dokumenty

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

práca, pridané 7.11.2015

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

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

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

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

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

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

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

abstrakt, pridaný 10.09.2014

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

semestrálna práca, pridaná 4.7.2015

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

práca, pridané 29.06.2012

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

abstrakt, pridaný 01.09.2009

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

práca, pridané 21.07.2011

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