Mu na psaní VCR informačních systémů. Ukázka designu titulní strany pro VKR. Organizace realizace zprovoznění a sledování průběhu jeho přípravy

Odeslat svou dobrou práci do znalostní báze je jednoduché. Použijte níže uvedený formulář

Studenti, postgraduální studenti, mladí vědci, kteří využívají znalostní základnu ve svém studiu a práci, vám budou velmi vděční.

Zveřejněno na http://www.allbest.ru/

Ministerstvo školství a vědy Ruské federace

Katedra informačních technologií a automatizovaných systémů, Fakulta elektrotechnická

Směr: 230100,62

Hlava Katedra: doktor ekonomie, prof.

Faizrakhmanov R.A.

ABSOLVENTSKÁ KVALIFIKAČNÍ PRÁCE

Pro akademický bakalářský titul

Student ____________________________ (Peshkov K.A.)

Složení VKR:

1. Vysvětlivka na 107 stranách;

2. Grafický materiál na 12 listech;

3. Elektronická média s materiály vědeckého výzkumu.

Vedoucí výboru pro výzkum a vývoj: _________________________ (Podgornykh P.A.)

Poradce: ________________________________ (Chepeleva I.M.)

Inspektor norem: _____________________________ (Eliseeva E.N.)

Trvalá - 2012

Ministerstvo školství a vědy Ruské federace

Perm National Research Polytechnic University

Katedra informačních technologií a automatizovaných systémů

Fakulta elektrotechnická

"SCHVÁLENÝ"

Hlava oddělení (R.A. Faizrakhmanov)

"____"____________2010

dokončit bakalářskou práci

Příjmení, I.O. Peškov Kirill Alexandrovič

Fakulta ETF Skupina ASUzu-08-2

Zahájení práce 25.12.2011

Kontrolní termíny pro přezkoumání práce oddělením 10 .01.2012 , 20.01.2012, 2 4 .01.2012

Termíny pro odevzdání recenzí 2 4 .01.2012

Obhajoba práce na zasedání Státní zkušební komise 2 6 .01.2012

1. Název tématu „Vývoj automatizovaného řídicího systémupersonální management v podniku"

2. Výchozí data pro práci. Přísné reportovací dokumenty z HR oddělení IVC LLC

a) hlavní část: popis předmětné oblasti, studie funkcí pracovníků personálního oddělení, studie vstupní dokumentace

b) zvláštní část: sestavení modelu, implementace modelu

Seznam grafických materiálů: funkční model, databázový model, implementace systému

Hlavní literatura Maklakov S.V. Erwin ABPwin. POUZDRO- nástroje rozvoje informačních systémů, Vendrov A.M.POUZDROtechnologií. Moderní metody a nástroje pro navrhování informačních systémů

Vedoucí bakalářské závěrečné kvalifikační práce

odborný asistent oddělení ITAS (Podgornykh P.A.)

Konzultant vedoucí konstrukčního oddělení (Chepeleva I.M.)

Obdržel úkol 25.12.2011 (Peshkov K.A.)

KALENDÁŘPLÁNPOPRAVYPROMOCENTRUM VYSOKÉ ŠKOLYKVALIFIKACEFUNGUJE

	Objem fáze v %	Popravy	Poznámka
Analýza výchozích dat, výběr schématu a hlavních parametrů
Vývoj hlavní části
Vývoj grafické části
Vypracování vysvětlující poznámky k dopisu
Odevzdání práce k posouzení a přezkoumání vedoucím kvalifikační práce kvalifikační práce
Prezentace práce vedoucímu katedry
Obhajoba na zasedání Státní zkušební komise

vedoucí práce ( Podgornykh P.A.)

"____" 2011

Notace a zkratky

Úvod

1. Vyjádření problému

2. Analýza známých přístupů k řešení problému

2.1. Kontrola a výběr norem a profilů

3. Popis funkčního modelu obchodního procesu „AS-IS“.

3.1. Popis objektu automatizace a informačních toků

4. Vývoj funkčního modelu systému „TO-BE“.

4.1. Hlavní funkce systému

4.2. Očekávané výsledky implementace systému elektronické správy dokumentů

5. Vývoj informačního modelu systému

5.1. Vývoj infologického datového modelu

5.2. Vývoj datového logického datového modelu

6. Popis architektury systému

6.1. Úložný subsystém

6.2. Subsystém výměny dat

6.3. Aplikační subsystém

Závěr

Bibliografie

ABSTRAKTNÍ

Zpráva 91 stran, 3 obrázky, 1 tabulka, 8 zdrojů, 12 příloh

HR ODDĚLENÍ, PERSONÁLNÍ ÚČETNICTVÍ, TOK DOKUMENTŮ, VSTUPNÍ DOKUMENTY, VÝSTUPNÍ DOKUMENTY, AUTOMATIZOVANÝ SYSTÉM

Předmětem studie je tok dokumentů personálního oddělení podniku ICTs LLC.

Cílem práce je vyvinout automatizovaný systém řízení personálu v podniku.

V průběhu prací byly provedeny experimentální studie na jednotlivých složkách toku dokumentů HR oddělení.

Výsledkem práce byl vytvořen technický projekt, na jehož základě je vyvíjen systém personálního řízení v podniku.

Efektivita systému je dána snížením vlivu osobních kvalit personálu na provádění procesů zpracování dokumentů, zvýšením spolehlivosti ukládání dokumentů a také minimalizací času stráveného vyhledáváním a analýzou potřebných dokumentů.

OZNAČENÍ A ZKRATKY

	Automatizovaný systém
	Automatizovaný řídicí systém
	Databáze
	Závěrečná kvalifikační práce
	Vysokoškolská instituce
	Státní norma
	Jednotný tarifní plán
	Životní cyklus
	Informační systém
	Informační technologie a automatizované systémy
	Výzkumná práce
	Software
	Softwarový systém
	Systém pro správu databází
	Technický úkol
	Elektronický počítač
CASE (Computer Aided Software/ systémové inženýrství)	Automatizovaný vývoj softwaru
DFD (diagramy toku dat)	Diagramy toku dat
ERD (Entity-Relationship Diagrams)	Schémata vztahů entit
ERP (Enterprise Resource Planning)	Systémy řízení podniku
IDEF0 (definice Icam)	Metodika funkčního modelování
IDEF1X (Icam DEFINition1 Extended)	Metodika konstrukce relačních struktur
IEC (Mezinárodní elektrotechnická komise)	Mezinárodní komise pro elektrotechniku
ISO (Mezinárodní organizace pro normalizaci)	Mezinárodní organizace pro normalizaci
ODBC (Open Date Base Connect)	Otevřené technologie pro komunikaci s databází
RAD (Rapid Application Development)	Metodika rychlého vývoje aplikací
SADT (strukturovaná analýza a technika návrhu)	Metodika strukturální analýzy
SQL (Structured Query Language)	strukturovaný dotazovací jazyk

ÚVOD

V tržní ekonomice si mnoho podniků uvědomuje potřebu modernizovat své systémy správy dokumentů.

Hlavní předpoklady, které si vynucují implementaci systémů automatizace dokumentů:

· značné časové a mzdové náklady vznikající při práci zaměstnanců HR oddělení s dokumenty;

· potřeba splnit regulační požadavky ruského toku dokumentů;

· rozsáhlé možnosti automatizovaného systému pro zajištění personálního účetnictví a kontroly;

· univerzálnost automatizačního systému umožňující rychlý přístup a kontrolu práce HR oddělení.

Všechny tyto předpoklady jen naznačují, že pro každý podnik nebo organizaci jsou otázky optimalizace toku osobních dokumentů a řízení zpracování informací klíčové. Toto tvrzení lze potvrdit následujícími údaji. Podle předních poradenských společností v oblasti informačních technologií:

· Šéf tráví asi 80 % své pracovní doby prací s informacemi.

· přibližně 30 % pracovní doby zaměstnanců stráví vytvářením, vyhledáváním, schvalováním a odesíláním dokumentů,

· každý interní dokument je zkopírován v průměru až 20krát

· také se odhaduje, že až 40 % pracovních zdrojů a až 15 % firemních příjmů musí být vynaloženo na práci s dokumenty.

I bez pronikání do všech těchto čísel je zřejmé, že systém pro automatizaci práce s dokumenty zaměstnanců podniku výrazně zjednoduší práci zaměstnancům HR oddělení, sníží náklady na údržbu tohoto oddělení a vytvoří jednotný systém, který vám umožní utrácet mnohem méně času na školení nových zaměstnanců.

Také velké společnosti se složitou a vysoce rozvětvenou strukturou budou schopny získat rychlý přístup k jakýmkoli informacím v co nejkratším čase.

Efektivita řízení podniků a organizací závisí v neposlední řadě na správném řešení problémů rychlého a kvalitního generování elektronických dokumentů, kontroly jejich provádění a také promyšlené organizace jejich ukládání, vyhledávání a používání. ACS umožňuje urychlit tyto procesy a usnadnit práci personálu.

Softwarově-matematické metody a výpočetní technika jsou pouze prostředky ke zpracování informací a přípravě vhodných manažerských rozhodnutí.

Cílem této práce je vyvinout automatizovaný systém řízení lidských zdrojů v podniku. Objektem automatizace je tok dokumentů HR oddělení v podniku ICTs LLC.

Řízení toku dokumentů HR oddělení této struktury vyžaduje zohlednění mnoha faktorů. Vše bude podrobně popsáno v technických specifikacích. Systém správy dokumentů by měl být flexibilní, dynamický systém, který vám umožní efektivně a rychle přistupovat k osobním souborům zaměstnanců a rychle zohledňovat a přidávat všechny změny.

· analýza informačních toků souvisejících s činností HR oddělení, jejich systemizace a vývoj specifikací;

· vývoj „tak jak jsou“ modely činností, analýza nedostatků;

· vývoj modelů činnosti „jak má být“;

· vývoj informačního datového modelu;

· vývoj technických specifikací pro vývoj informačního systému.

Vyvíjený informační systém umožní:

· automatizovat proces evidence, účetnictví, zpracování dokumentů;

· optimalizovat ukládání dokumentů;

· šetřit prostředky vynaložené na přípravu nových dokumentů;

· zvýšení komfortu a snížení pracnosti při práci s dokumenty pro koncového uživatele.

· snížit čas manažerů a zaměstnanců rutinními operacemi s dokumenty (tvorba, vyhledávání, schvalování atd.)

· zabránit neoprávněnému přístupu k dokumentům;

Pro dokončení práce se očekává použití následujících standardů:

· IDEF0 bude použito k modelování obchodních procesů;

· IDEF3 se používá k modelování informačních toků;

· informační modely budou prezentovány v notaci IDEF1X;

· zadání bude vypracováno v souladu s GOST 34.602-89 „Technické specifikace pro vytvoření automatizovaného systému“

1. PZASTAVENÍ ÚKOLU

Každá právnická osoba, bez ohledu na organizační a právní formu, ve které je vytvořena, je v procesu uskutečňování ekonomických činností postavena před provádění prací na evidenci, vedení a uchovávání personální dokumentace. V prvním přiblížení je personální dokumentace soubor dokumentů, které zajišťují vnitřní podnikovou regulaci práce a související další vztahy mezi zaměstnavatelem a zaměstnancem. Je třeba poznamenat, že za širší pojem lze považovat tok personálních dokumentů, který zahrnuje nejen dokumenty, ale také postupy (například postup přivádění zaměstnanců ke disciplinární odpovědnosti). Každým rokem přibývá dokumentů (osobní karty zaměstnanců, pracovní výkazy, rozvrhy dovolených atd.) a je třeba je ukládat a aktualizovat. Vypracování harmonogramů obsazení, rozložení pracovních rozvrhů, příprava různých reportů atp. - veškerá tato práce je prováděna ručně a zabírá značnou část času personálu HR. V HR oddělení je tedy obrovské množství papírování. Dokument je hlavním nosičem obchodních informací, ale „papírové technologie“ pro zpracování dokumentů již dlouho nedokážou držet krok s rychlostí a přesností, kterou vyžadují moderní obchodní procesy, takže většina dokumentů a informací je pro efektivnější práci převáděna do elektronické podoby. .

Pro efektivní organizaci dokumentace HR oddělení je nutné mít centralizované úložiště informací a také k nim volný přístup. Významným problémem je rychlé a efektivní vyhledávání potřebných informací mezi obrovským množstvím dat. Použití elektronického řešení nám tedy umožňuje řešit výše uvedené problémy.

Účel tohototeze je vývoj automatizovaného systému řízení personálu v podniku "IVC" LLC "Personální účetnictví".

Systém musí poskytovat řešení pro následující úkoly:

1. zlepšení výkonové kázně a snížení vlivu osobních kvalit personálu na provádění procesů zpracování dokumentů;

2. snížení doby vývoje dokumentu;

3. zvýšení efektivity výměny informací mezi odděleními.

4. zvýšení spolehlivosti ukládání dokumentů, minimalizace času stráveného vyhledáváním a analýzou potřebných dokumentů.

Z hlediska implementace musí navržený systém splňovat následující požadavky:

· systematičnost a informační kompatibilita subsystémů a prvků subsystému, tzn. vytvoření propojeného souboru forem výměny informací v celém informačním systému;

· metodická jednota, tzn. vývoj různých subsystémů na společných principech a zajištění propojení různých subsystémů, které systém tvoří (ukazatele, formuláře dokumentů);

2. ANALÝZA ZNÁMÝCH PŘÍSTUPŮ K ŘEŠENÍ PROBLÉMU

Dnes existují dva hlavní přístupy k vývoji softwaru IS, z nichž jeden je tzv funkčně-modulární nebo strukturální. Je založen na principu funkční dekompozice, kdy je popsána struktura systému z hlediska hierarchie jeho funkcí a přenosu informací mezi jednotlivými funkčními prvky. Druhý, objektově orientovaný využívá rozklad objektů. Struktura systému je popsána z hlediska objektů a vztahů mezi nimi a chování systému z hlediska výměny zpráv mezi objekty. Každý systémový objekt má své vlastní chování, které modeluje chování objektu reálného světa.

Ve funkčních modelech (DFD diagramy datových toků, SADT diagramy) jsou hlavními strukturálními složkami funkce (operace, akce, úlohy), které jsou v diagramech vzájemně propojeny objektovými toky.

Nespornou výhodou funkčních modelů je implementace strukturálního přístupu k navrhování IS na principu „shora dolů“, kdy lze každý funkční blok rozložit na mnoho podfunkcí apod. a realizovat tak modulární návrh IS. Funkční modely se vyznačují procedurální náročností dekompozice IS a přehledností prezentace.

S funkčním přístupem jsou samostatně vyvíjeny objektové datové modely ve formě ER-diagramů „objekt - vlastnost - vztah“. Pro kontrolu správnosti modelování předmětné oblasti jsou mezi funkčními a objektovými modely vytvořeny vztahy jedna ku jedné.

Hlavní nevýhodou funkčních modelů je, že procesy a data existují odděleně od sebe – kromě funkčního rozkladu je zde datová struktura, která je na pozadí. Navíc nejsou jasné podmínky pro provádění procesů zpracování informací, které se mohou dynamicky měnit.

Uvedené nevýhody funkčních modelů jsou odstraněny u objektově orientovaných modelů, ve kterých je hlavní strukturotvornou složkou třída objektů se sadou funkcí, které mohou přistupovat k atributům této třídy.

Třídy objektů se vyznačují hierarchií zobecnění, která umožňuje dědění nejen atributů (vlastností) objektů z vyšší třídy objektů do třídy nižší, ale také funkcí (metod).

V případě dědičnosti funkcí můžete abstrahovat od konkrétní implementace procedur (abstraktních datových typů), které se pro určité podtřídy situací liší. To umožňuje odkazovat na podobné programové moduly běžnými názvy (polymorfismus) a znovu použít programový kód při úpravách softwaru. Adaptabilita objektově orientovaných systémů na změny v předmětné oblasti je tedy mnohem vyšší ve srovnání s funkčním přístupem.

S objektově orientovaným přístupem se mění i princip návrhu IS. Nejprve se identifikují třídy objektů a následně se v závislosti na možných stavech objektů (životní cyklus objektů) určí metody zpracování (funkční procedury), které zajistí nejlepší implementaci dynamického chování informačního systému.

Pro objektově orientovaný přístup byly vyvinuty grafické metody modelování předmětné oblasti zobecněné v jednotném modelovacím jazyce UML. Z hlediska jasnosti prezentace modelu zákazníkovi uživateli jsou však objektově orientované modely jednoznačně horší než funkční modely.

Při volbě metodiky modelování oborové oblasti se obvykle jako kritérium používá míra její dynamiky. Pro regulovanější úlohy jsou vhodnější funkční modely, pro adaptivnější business procesy (řízení workflow, implementace dynamických dotazů do informačních úložišť) objektově orientované modely. V rámci stejného IS však mohou různé třídy problémů vyžadovat různé typy modelů popisujících stejnou problémovou oblast. V tomto případě by měly být použity kombinované doménové modely.

V současnosti je v praxi počet CASE nástrojů, které podporují objektově orientovaný přístup, malý ve srovnání s těmi, které podporují strukturovaný přístup. Zejména diagramy, které odrážejí specifika objektově orientovaného přístupu (diagramy tříd, objektů atd.), jsou mnohem méně přehledné a špatně

srozumitelné i pro laiky. Příklady objektově orientovaných nástrojů CASE jsou: Rational Rose od Rational Software a Paradigm Plus od Computer Associates, navržené pro automatizaci fází analýzy a návrhu softwaru.

Moderní CASE nástroje, které podporují strukturovaný přístup, pokrývají širokou škálu podpory pro řadu technologií návrhu IS: od jednoduchých analytických a dokumentačních nástrojů až po plnohodnotné automatizační nástroje pokrývající celý životní cyklus softwaru. Dnes má ruský softwarový trh následující nejvíce

vyvinuté nástroje CASE: Vantage Team Builder (Westmount I-CASE); Designer/2000; Silverrun; ERwin+BPwin; S-Designor; CASE.Analytik.

ERwin je moderní nástroj pro návrh databází. Charakteristickým rysem ERwin/ERX je vysoký stupeň konzistence mezi nástroji pro vytváření databází a nástroji pro vývoj aplikací. ERwin podporuje všechny nejpopulárnější relační DBMS, včetně Oracle; Sybase; Informix; Microsoft SQL Server; FoxPro; InterBase; Paradox; Přístup atd. Stejný model lze použít k vytvoření několika databází nebo k přenosu aplikace z jedné platformy DBMS na druhou. ERwin lze použít ve spojení s mnoha populárními nástroji pro vývoj aplikací: Delphi, PowerBuilder, Visual Basic, Oracle Designer/2000 atd.

BPwin je výkonný CASE nástroj pro systémovou analýzu obchodní a výrobní činnosti, který umožňuje sledovat soulad obchodní struktury, toku dokumentů a finančních toků s přísnými a dynamickými požadavky moderní ekonomiky. Systém BPwin pomůže zvýšit konkurenceschopnost a optimalizovat procesy řízení.

BPwin má intuitivní grafické rozhraní, které vám pomůže rychle vytvářet a analyzovat modely pro optimalizaci obchodních a výrobních procesů. Pomocí sady grafických nástrojů umožňuje BPwin snadno sestavit procesní diagram, který zobrazuje počáteční data, výsledky operací, zdroje potřebné k jejich provedení, kontrolní akce a vzájemné vazby mezi jednotlivými činnostmi.

Pro modelování obchodních procesů HR oddělení byl zvolen CASE nástroj BPwin 4.0. Bylo rozhodnuto navrhnout databázi vytvořeného subsystému pomocí CASE nástroje ERwin 4.0, protože je poměrně jednoduché se naučit a používat.

personál správy informačního systému

2 .1 Kontrola a výběr norem a profilů

Životní cyklus JE podle GOST 34.003: soubor vzájemně souvisejících procesů vzniku a postupných změn stavu JE od vytvoření počátečních požadavků na ni až po ukončení provozu a likvidaci komplexu automatizačních zařízení JE. Koncept životního cyklu softwaru je jedním ze základních v softwarovém inženýrství. Hlavním regulačním dokumentem upravujícím složení procesů životního cyklu softwaru je mezinárodní norma ISO/IEC 12207:1995 „Information Technology - Software Life Cycle Processes“. Definuje strukturu životního cyklu obsahující procesy, činnosti a úkoly, které je nutné provést při tvorbě softwaru.

Mezi ruské normy upravující procesy vytváření automatizovaných systémů, které zahrnují software, lze uvést:

· GOST 34.601-90 „Informační technologie. Soubor standardů pro automatizované systémy. Automatizované systémy. Etapy tvorby";

· GOST 34.602-89 „Informační technologie. Soubor standardů pro automatizované systémy. Technické specifikace pro vytvoření automatizovaného systému“;

· GOST 34.603-92 „Informační technologie. Typy testování automatizovaných systémů."

Jednotný soubor norem pro řídicí dokumenty pro jaderné elektrárny by měl spolu s dalšími systémy a soubory norem tvořit kompletní regulační a technickou podporu procesů vzniku a provozu jaderných elektráren.

GOST 34.602-89 se vztahuje na automatizované systémy (AS) pro automatizaci různých typů činností (řízení, projektování, výzkum atd.), včetně jejich kombinací, a stanoví složení, obsah, pravidla pro vypracování dokumentu „Technické specifikace pro vytvoření (vývoj nebo modernizace) systému“ (dále jen technické specifikace JE).

Obecná ustanovení GOST 34.602-89:

· Technická specifikace pro jadernou elektrárnu je hlavním dokumentem, který definuje požadavky a postup pro vytvoření (vývoj nebo modernizaci - následně vytvoření) automatizovaného systému, v souladu s nímž je vývoj jaderné elektrárny uskutečňován a jeho akceptace při uvedení do provozu.

· Specifikace pro JE jsou vypracovány pro systém jako celek, určený k provozu samostatně nebo jako součást jiného systému.

· Dodatečně lze vypracovat technické specifikace pro části JE: pro subsystémy JE, komplexy úloh JE atd. v souladu s požadavky této normy; pro hardwarové komponenty a softwarové a hardwarové systémy v souladu s normami ESKD a SRPP; pro softwarové nástroje 1 v souladu se standardy ESPD; pro informační produkty v souladu s GOST 19.201 a NTD platnými v oddělení zákazníka AS.

· Požadavky obsažené v technických specifikacích pro jaderné elektrárny musí odpovídat současnému stupni rozvoje vědy a techniky a nesmí být nižší než obdobné požadavky na nejlepší moderní domácí i zahraniční analogy. Požadavky uvedené v technických specifikacích pro JE by neměly omezovat vývojáře systému při hledání a zavádění nejefektivnějších technických, technických, ekonomických a jiných řešení.

· Technické specifikace pro jaderné elektrárny jsou vypracovány na základě výchozích údajů, včetně údajů obsažených v závěrečné dokumentaci etapy „Výzkum a zdůvodnění výstavby jaderných elektráren“, stanovené GOST 24.601.

· Technické specifikace pro AS zahrnují pouze ty požadavky, které doplňují požadavky na systémy tohoto typu (ACS, CAD, ASNI atd.) obsažené v aktuální normativní a technické dokumentaci a jsou určeny specifiky konkrétního objektu pro který systém vytváří.

· Změny technických specifikací pro JE jsou dokumentovány jako dodatek nebo protokol podepsaný zákazníkem a developerem. Dodatek nebo stanovený protokol je nedílnou součástí technické specifikace JE. Na titulní straně technické specifikace reproduktoru by měla být položka „Platnost od...“.

Technická specifikace pro JE obsahuje následující části, které lze rozdělit do podkapitol:

1. obecné informace;

2. účel a cíle tvorby systému;

3. charakteristika objektů automatizace;

4. systémové požadavky;

5. skladba a obsah práce na vytvoření systému;

6. postup kontroly a akceptace systému;

7. požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu;

8. požadavky na dokumentaci;

9. vývojové zdroje. (GOST 34 602-89)

3. POPIS FUNKČNÍHO MODELU OBCHODNÍHO PROCESU “TAK JAKO- JE»

Funkční model je určen k popisu existujících podnikových procesů v podniku, tzv. „AS-IS“ model (tak jak je) a ideální stav věcí – o co bychom měli usilovat – model „TO-BE“.

Při své práci se HR oddělení řídí stávajícími zakázkami, firemními politikami a zákoníkem práce Ruské federace. Zaměstnanci oddělení musí plnit své povinnosti v souladu s vypracovanými pracovními náplněmi. Výsledkem práce oddělení v oblasti personálního účetnictví jsou tyto dokumenty:

· Objednávky do zaměstnání

· Převodní příkazy

· Příkazy k propuštění

· Servisní smlouva

· Zaměstnanecká smlouva

· Informace o datech jmenování bonusů za odslouženou dobu

· Osvědčení o zavedené praxi

· Příkazy o poskytování dovolené

· Účetní informace

· Osobní karta T2 (T2GS)

· Obecná informace

· Informace o změnách

· Informace o složení zaměstnanců

· Personální zajištění

3.1 Popis objektu automatizace a informačních toků

HR oddělení je samostatnou divizí společnosti. Jeho struktura je znázorněna na obrázku 1.

"Obrázek 1 - struktura HR oddělení"

V souladu s funkcemi a úkoly přidělenými oddělení plní oddělení (v rámci objektu automatizace) následující funkce:

· organizace výběru, náboru a najímání pracovníků s potřebnou kvalifikací a v požadovaném objemu;

· vytvoření efektivního personálního systému;

· rozvoj kariérních plánů zaměstnanců;

· rozvoj personálních technologií;

· organizace práce;

· školení, postup a rekvalifikace personálu;

· výzkum sociálně psychologického klimatu;

· materiální pobídky a motivace personálu;

· plánování a kariérní postup;

· standardizace práce, posuzování rezerv a certifikace;

· ochrana a bezpečnost práce.

Vstupní/výstupní dokumenty

Zdrojovými dokumenty pro činnost HR oddělení (v rámci automatizačního zařízení) jsou:

· Historie zaměstnání;

· Žádost zaměstnanců o propuštění z vlastní iniciativy;

· Plán dovolené;

· Pracovní výkazy a výpočet mezd;

· Věstník kontrolních činností;

Výstupní dokumenty:

· Příkazy k zaměstnání;

· Převodní příkazy;

· příkazy k propuštění;

· Servisní smlouva;

· Zaměstnanecká smlouva;

· Informace o datech jmenování bonusů za odslouženou dobu;

· Osvědčení o praxi;

· příkazy k poskytování dovolené;

· Informace pro účetní oddělení;

· Osobní karta T2 (T2GS);

· Obecná informace;

· Registrovat;

· Informace o změnách;

· Informace o složení zaměstnanců;

· Personální zajištění;

Aplikací metodiky IDEF0 získáme funkční model předmětné oblasti, který zobrazuje funkční strukturu objektu, tzn. akce, které provádí, a spojení mezi nimi.

Funkční model „AS-IS kontextový diagram A-0“ je uveden v [Příloha A]. Zahrnuje veškeré činnosti oddělení v oblasti personálního účetnictví. Model je prezentován ve formě černé skříňky. Podrobnosti o diagramu „A0“ jsou uvedeny v [Příloha B].

Funkce modelu AS-IS

Funkce A1

Název:

Algoritmus: Zadávání údajů o zaměstnancích do systému;

Vstupní data:

Výstup: Příkazy k pronájmu, Příkazy k převodu, Příkazy k propuštění, Servisní smlouva, Pracovní smlouva;

Řízení:

Mechanismus: Specialisté na nábor;

Funkce A2

Název: Řízení pracovního procesu;

Algoritmus: Organizace kontroly a podávání zpráv;

Vstupní data: Harmonogram dovolené, Výpočty pracovních výkazů a mezd, Objednávky náboru;

Výstup: Informace o datech přidělení odměn za odslouženou dobu, Potvrzení o zjištěné délce odsloužení, Příkazy k poskytnutí dovolené, Informace pro účetní oddělení;

Řízení:

Mechanismus: Specialisté na personální hodnocení;

Funkce A3

Název: Kancelářská práce;

Algoritmus: Provádění postupů pro aktualizaci informací o personálu;

Vstupní data: Kniha účtování pohybu pracovních knih a příloh k nim, Věstník účtování kontrolní činnosti, Návrh personální tabulky;

Výstup: Osobní karta T2 (T2GS), Obecné informace, Registr, Informace o změnách, Informace o složení zaměstnanců, Tabulka obsazení;

Řízení: Popis práce;

Mechanismus: Specialisté na řízení kanceláří;

Při studiu AS-IS modelu byly zjištěny následující nedostatky:

· nesystematické ukládání dokumentace;

· nedostatek příruček;

· dlouhé hledání zaměstnanecké karty v papírovém archivu;

Nedostatky nalezené v modelu AS-IS lze napravit při vytváření modelu TO-BE (jak se patří). Tento model integruje slibné návrhy od vedení a zaměstnanců podniku, expertů a systémových analytiků a umožňuje nám formulovat vizi nových racionálních technologií pro společnost.

4. VÝVOJ FUNKČNÍHO MODELU SYSTÉMU« NA- BÝT»

Metodikou IDEF0 vypracujeme funkční model předmětné oblasti, který odráží funkční strukturu objektu, tzn. akce, které provádí, a spojení mezi nimi.

Funkční model „Kontextový diagram TO-BE A-0“ je uveden v [Příloha B]. Zahrnuje veškeré činnosti oddělení v oblasti personálního účetnictví. Model je prezentován ve formě černé skříňky. Podrobnosti o diagramu „A0“ jsou uvedeny v [Příloha D].

Funkce modelu"NA- BÝT»

Funkce A1

Název: Organizace přijímání/propouštění zaměstnanců;

Algoritmus: Zadávání údajů o zaměstnanci na elektronickou kartu;

Vstupní data: Pracovní sešit, Žádost zaměstnance o propuštění z vlastní iniciativy;

Výstup: Příkazy k pronájmu, Příkazy k převodu, Příkazy k výpovědi, Servisní smlouva, Pracovní smlouva, Elektronická karta zaměstnance;

Řízení: Zákoník práce Ruské federace, Popis práce, Předpisy o odměňování pracovníků, Politika společnosti;

Mechanismus: Nábor specialistů, Informační systém;

Funkce A2

Název: Řízení systému;

Algoritmus: Organizace kontroly a práce se zaměstnaneckými kartami. Provádění postupů pro aktualizaci informací o personálu;

Vstupní data: Harmonogram dovolených, Časový rozvrh a výpočet mezd, Kontrolní deník, Elektronická karta zaměstnance;

Výstup: seznam zaměstnanců;

Řízení: Náplň práce, Politika společnosti, Vnitřní pracovní předpisy;

Mechanismus:

Funkce A3

Název: Hlášení;

Algoritmus: Vytiskněte a vytiskněte potřebné informace ve formě zpráv

Vstupní data: seznam zaměstnanců;

Výstup: Informace o datech přidělení bonusů za odslouženou dobu, Potvrzení o stanovené délce odsloužení, Objednávky na přiznání dovolené, Informace do účtárny, Osobní karta T2 (T2GS), Obecné informace, Registr, Informace o změnách, Informace o složení zaměstnanců, Pracovní stůl;

Mechanismus: Informační systém;

Abychom podrobněji ilustrovali rozdíly mezi modely „TO-BE“ a „AS-IS“, provedeme rozklad funkce „A2“ a představíme ji v [Příloha E].

Funkce modelu"NA- BÝTdetail grafuA2"

Funkce A21

Název: Práce s elektronickou kartou;

Algoritmus: Zahrnuje veškeré operace prováděné s osobními údaji zaměstnanců;

Vstupní data: Harmonogram dovolených, Časový rozvrh a výpočet mezd, Kontrolní deník, Elektronická karta zaměstnance, Odsloužená doba zaměstnance, Tabulka obsazení;

Výstup:

Řízení: Náplň práce, Politika společnosti, Vnitřní pracovní předpisy;

Mechanismus: Specialisté na personální hodnocení, specialisté na správu záznamů, informační systém;

Funkce A22

Název: Tvorba personálu;

Algoritmus: Formace se provádí na základě údajů o všech odděleních a zaměstnancích společnosti;

Vstupní data: Pracovní výkazy a výpočty mezd, Osobní údaje zaměstnanců;

Výstup: Pracovní stůl;

Řízení: Vnitřní pracovní předpisy;

Mechanismus: Specialisté na řízení kanceláře, Informační systém;

Funkce A23

Název: Automatický výpočet zkušeností;

Algoritmus: Výpočet se provádí během celé kariéry zaměstnance v tomto podniku;

Vstupní data: Osobní údaje zaměstnanců;

Výstup: Hodnota odpracované doby zaměstnance;

Řízení: Popis práce;

Mechanismus: Informační systém;

Funkce A24

Název: Filtrace;

Algoritmus: Vytvoření seznamu zaměstnanců splňujících zadané atributy;

Vstupní data: Osobní údaje zaměstnanců;

Výstup: seznam zaměstnanců;

Mechanismus: Informační systém;

4.1 Hlavní funkce systému

· Uchovávání strukturovaných informací o zaměstnanci ve formě karty s potřebnými údaji;

· Vedení adresářů podniků, typů pozic, regionů a různých adresářů služeb;

· Vyhledávání karet podle atributů;

· Filtrování karet podle detailů a textu (s atributem a fulltext);

· Automatický výpočet odpracované doby zaměstnance;

· Export potřebných informací do jiného běžného softwaru (Microsoft Excel);

· Výstup různých reportů.

Stručně lze princip fungování systému představit takto:

· Hlavními informačními objekty systému jsou Karty zaměstnanců, které uchovávají strukturované informace o příslušném objektu.

· Pomocné referenční informace jsou uloženy v systémových adresářích, které se používají při vyplňování kartových polí a pro další oficiální účely.

· Uživatel pracuje se systémem pomocí klientské aplikace, přes kterou získává v souladu se svými právy přístup ke svým systémovým objektům. Uživatel může vyhledávat, prohlížet, vytvářet a upravovat objekty, pro které má dostatečná práva k práci.

· Systém automaticky provádí akce poskytované obchodní logikou karet a obchodními procesy.

Hlavní směry při vytváření systému jsou následující:

· Spojuje mechanismy pro práci s papírovými a elektronickými dokumenty tak, aby bylo možné zajistit „plynulý“ tok dokumentů založený na pohodlném, snadno naučitelném a rychlém systému s jednoduchým a přívětivým uživatelským rozhraním.

· Maximální zjednodušení práce manažerů se systémem, navržené tak, aby výrazně ušetřilo čas, neboť právě manažer musí často pracovat s papírovou i elektronickou verzí dokumentu.

· Usnadnění procesu zadávání dokumentů do systému bez ohledu na způsob a formu, jakou do organizace dorazily (papír, fax, e-mail atd.).

· Zvýšení důvěry uživatelů v systém elektronické správy dokumentů, včetně zvýšení spolehlivosti ukládání dokumentů.

· Zjednodušte správu podnikových procesů pro úlohy zpracování dokumentů i jiných než dokumentů.

4. 2 Očekávané výsledky implementace systémuelektronickýtok dokumentů

· Snížení rizika ztráty informací a technologií při odchodu klíčových zaměstnanců.

· V elektronické správě dokumentů jsou potřebné dokumenty vždy po ruce: nízká závislost na osobnostech, efektivní vyhledávání dokumentů;

· Zlepšení efektivity řízení;

· Zvýšení produktivity práce;

· Zaměstnanci jsou poskytovány aktuální informace;

· Snížení rizika;

· Zajištění bezpečnosti úložiště komerčních informací.

5. VÝVOJ INFOLOGICKÉHO MODELU SYSTÉMU

5.1 Vývoj infoologického datového modelu

Informační datový model je popis vytvořený pomocí přirozeného jazyka, matematických vzorců, tabulek, grafů a dalších prostředků. Hlavními konstruktivními prvky informačních modelů jsou entity, souvislosti mezi nimi a jejich vlastnosti (atributy).

Při sestavování informačních modelů pomocí ER diagramů jsou entity zobrazeny jako obdélníky, asociace jako kosočtverce nebo šestiúhelníky, atributy jako ovály a spojení mezi nimi jako nesměrové hrany, nad nimiž je naznačen stupeň spojení a potřebné vysvětlení.

Na základě analýzy předmětné oblasti a požadavků na systém elektronické správy dokumentů byly identifikovány tyto subjekty:

· Zaměstnanec

· Vzdělání

·Další vzdělání

· Historie zaměstnání

· Lékařská politika

· Vojenský průkaz

· Ocenění

· Příbuzní

· Povolenky

· Výhody

· Přesunout cíle

· Služební cesty

· Odškodné

· Materiální pomoc

· Certifikace

· Prázdniny

· Nemocenská

· Podniky

· Druhy vzdělávání

Regiony

· Vzdělávací zařízení

· Typ pozice

· Typ zkušenosti

Komunikace "Vzdělávání" patří

Komunikace "Přidat. vzdělání" patří"Zaměstnanec" je vztah M:1;

Komunikace "Ocenění" patří"Zaměstnanec" je vztah M:1;

Spojení "Příbuzní" patří"Zaměstnanec" je vztah M:1;

Komunikace "Příspěvky" patří"Zaměstnanec" je vztah M:1;

Komunikace "Výhody" patří"Zaměstnanec" je vztah M:1;

Komunikace s přesunem destinací patří"Zaměstnanec" je vztah M:1;

Komunikace "služební cesty" patří"Zaměstnanec" je vztah M:1;

Komunikace "Odstupné" patří"Zaměstnanec" je vztah M:1;

Komunikace "Materialni pomoc" patří"Zaměstnanec" je vztah M:1;

Komunikace "Certifikace" patří"Zaměstnanec" je vztah M:1;

"Dovolená" spojení patří"Zaměstnanec" je vztah M:1;

Komunikace „Nemocenské“ patří"Zaměstnanec" je vztah M:1;

Komunikace "rezerva" patří

Vztah typu práce patří"Rezerva" je připojení 1:M;

Komunikace "pracovní sešit" patří"Zaměstnanec" je vztah 1:1;

Komunikace "Medical Poly" patří"Zaměstnanec" je vztah 1:1;

Komunikace "Vojenské ID" patří"Zaměstnanec" je vztah 1:1;

Podniková komunikace patří

Komunikace "Druhy vzdělávání" patří„Zaměstnanec“ je vztah 1:M;

Komunikace "zkušenosti" patří„Zaměstnanec“ je vztah M:M;

Vztah "Typ zkušeností" patří„Seniority“ je připojení typu 1:M;

5.2 Vývoj datového logického datového modelu

Informační model musí být mapován do počítačově orientovaného datově logického modelu. Datalogický model zajišťuje nezávislost dat na dvou úrovních – logické a fyzické.

Logická vrstva datového modelu je abstraktní pohled na data, kde jsou data reprezentována tak, jak vypadají v reálném světě, a jsou pojmenována tak, jak jsou nazývána v reálném světě. Logický datový model je vytvořen na základě diagramů entit a vztahů, který zahrnuje entity a vztahy mezi nimi. Každá entita je sada podobných jednotlivých objektů nazývaných instance. Každá kopie je individuální a odlišná od všech ostatních kopií. Entita má sadu atributů, z nichž každý vyjadřuje určitou vlastnost objektu.

Logický model systému je uveden v [Příloha L] a v [Grafický materiál 11].

Tabulky se dělí na tzv. referenční, pracovní a servisní. V adresářových tabulkách jsou uložena jména některých objektů, například názvy kategorií nebo typů zkušeností. Každému z nich je v rámci konkrétní tabulky přiřazen unikátní kód, podle kterého lze nalézt odpovídající název objektu v sadě obsažené v tabulce. V pracovních tabulkách jsou téměř všechny informace uloženy v kódech nebo klíčích záznamů, tabulky jsou vzájemně propojeny kódy (nebo klíči záznamů). V tabulkách služeb se provádějí operace pomocného typu, například se počítá délka služby.

6 . POPIS ARCHITEKTURY SYSTÉMU

Automatizovaný informační systém „Personální účetnictví“ využívá třívrstvou architekturu klient-server (obrázek 2).

"Obrázek 2 - Architektura systému personálního účetnictví"

Automatizovaný informační systém „Personální účetnictví“ je konvenčně rozdělen do tří podsystémů:

1. Subsystém ukládání dat.

2. Subsystém výměny dat.

3. Aplikační subsystém.

6 .1 Úložný subsystém

MS SQL DBMS funguje jako subsystém pro ukládání dat. DBMS pracuje s databází, ve které jsou strukturovaně uloženy veškeré osobní údaje zaměstnanců.

Tyto informace jsou během provozu využívány všemi subsystémy a během provozu si je efektivně vyměňují.

6 .2 Subsystém výměny dat

Subsystém výměny dat je webová služba, která je určena k výměně informací mezi klientskými aplikacemi (aplikačním subsystémem) a databází. Webová služba je vyvíjena pomocí technologie Windows Communication Foundation, jednotného programovacího modelu pro distribuované aplikace na platformě Microsoft. Zahrnuje předchozí technologie – ASMX, .NET Remoting, DCOM a MSMQ – a poskytuje rozšiřitelné API, které splňuje různorodé požadavky, které vznikají při budování distribuovaných systémů.

Webová služba si vyměňuje data s klientskými aplikacemi prostřednictvím protokolu HTTP a podporuje také duplexní výměnu dat (současnou výměnu v obou směrech).

6 .3 Aplikační subsystém

Aplikační engine je klientská aplikace, která komunikuje s webovou službou. Klientská aplikace je vyvíjena v integrovaném vývojovém prostředí Delphi.

Delphi je imperativní, strukturovaný, objektově orientovaný programovací jazyk, dialekt Object Pascal. Počínaje vývojovým prostředím Delphi 7.0 začal Borland používat název Delphi k označení jazyka Object Pascal v oficiálních dokumentech. Od roku 2007 začal jazyk Delphi (odvozený od objektu Pascal) žít svůj vlastní nezávislý život a podstoupil různé změny spojené s moderními trendy (například s vývojem platformy .NET) ve vývoji programovacích jazyků: třídní pomocníci, objevilo se přetížení operátora a další.

Popis funkcí aplikace

Uživatel systému pracuje přímo s klientskou aplikací. V hlavním okně aplikace [Příloha E] je zobrazen seznam všech zaměstnanců společnosti, který lze třídit a vyhledávat podle různých atributů. Abyste mohli do systému vložit nového zaměstnance, musíte si vytvořit „Individuální kartu“ [Příloha G] a vyplnit ji osobními údaji zaměstnance. Nejprve musíte vyplnit pole „Pence No“. je to klíčové.

Chcete-li přiřadit osobu na jakoukoli pozici, musíte přejít na kartu „Další informace“ [Příloha 3], ve které jsou vyplněny další atributy, včetně „Přiřazení a převody“. Při přidávání nové schůzky se otevře okno „Přijímání a převedení na jinou práci“ [Příloha I], kde je uvedeno vše o aktuální pozici zaměstnance. Po vyplnění všech atributů se automaticky začne počítat odpracovaná doba zaměstnance.

Při vyplňování elektronických karet pro všechny zaměstnance má smysl vytvořit personální tabulku.

Chcete-li filtrovat elektronické karty, použijte okno „Filtrování“ [Příloha K]. Určuje jeden nebo více atributů, podle kterých je třeba karty filtrovat. Výsledný seznam lze použít k úpravě dat nebo generování různých sestav pro jednoho nebo více zaměstnanců.

ZZÁVĚR

Tato práce je věnována automatizaci toku dokumentů v rámci HR oddělení společnosti IVTs LLC.

Cílem této práce je vytvoření projektu „Personální účetnictví“.

K dosažení tohoto cíle byly formulovány a řešeny následující úkoly:

· Byla provedena analýza informačních toků;

· Vyvinuté modely aktivit „jak by měly být“ využívající standard IDEF0;

· Vyvinuté informační datové modely v notaci IDEF1X;

· Technická specifikace informačního systému resortu byla vypracována na základě GOST 34/602-89, která je uvedena v [Příloha M].

SREFERENCE

1. GOST 34.602-89 „Informační technologie. Soubor standardů pro automatizované systémy. Technické specifikace pro vytvoření automatizovaného systému“;

2. GOST 34.602-89 „Pravidla pro přípravu technických specifikací“. - URL: http://url5.ru/hej (datum návštěvy 25.11.2011);

3. Zákoník práce Ruské federace. - Vydání 2011-2012

4. Vendrov A.M. „Návrh softwaru pro ekonomické informační systémy“: Finance a statistika. - 2002;

5. Kibanova A.Ya. “Organizační personální management”: INFRA-M. - 2005;

6. Maklakov S.V. „BPwin a Erwin. CASE-tools pro vývoj informačních systémů“: DIALOG-MEPhI. - 2000;

7. Maklakov S.V. „Modelování obchodních procesů s BPwin 4.0“: DIALOG-MEPhI. - 2002 - 224c.;

8. Kvalifikační příručka pro pozice manažerů, specialistů a zaměstnanců: INFRA-M. - 2003 - 96 s.

Publikováno na Allbest.ru

...

Podobné dokumenty

Odůvodnění potřeby vyvinout AOS „Bezpečnost informací“. Budování modelu činnosti „Jak je“ (AS-IS) a „Být“ (TO-BE). Analýza softwarových produktů. Vytvoření modelu domény. Vývoj informačního systému.

zpráva z praxe, přidáno 31.05.2015


Obecná charakteristika podniku a identifikace problémů v jeho činnosti, analýza známých přístupů k jejich řešení. Vývojové nástroje a analýza informačních toků. Vývoj a struktura modelu činnosti podniku „jak je“ a „jak by měl být“.

práce v kurzu, přidáno 20.12.2013


Koncept automatizovaného informačního systému. Konstrukce funkčně orientovaných modelů „jak je“ (jak je) a „jak má být“ (být). Popis databáze, vývoj aplikací, uživatelská příručka. Faktura, příkaz k úhradě.

práce, přidáno 23.04.2013


Analýza informačních toků souvisejících s činností pneuservisu. Vývoj informačního datového modelu. Popis technických specifikací pro vývoj webové služby. Vypracování plánů řízení konfigurace a kontroly kvality.

práce v kurzu, přidáno 25.12.2014


Studium stávající poštovní technologie. Vypracování modelu technologické operace ve formátu „tak jak je“. Vývoj modelu automatizovaného technologického provozu ve formátu „jak má“ (TO-BE). Vývoj technických specifikací pro automatizované pracovní stanice.

test, přidáno 20.12.2010


Přepis rozhovoru s vedoucí MBOU "Vzdělávací centrum v obci Markovo". Náplň práce, činnost oddělení služeb zákazníkům. Budování modelu činnosti „jak je“ a „jak by mělo být“. Vytvoření automatizovaného informačního systému.

práce v kurzu, přidáno 25.04.2013


Konstrukce modelů činností „jak je“ (AS–IS) a „jak by mělo být“ (TO–BE) pro zlepšení efektivity účtování zboží ve skladu TNT Trading LLC. Tvorba technických specifikací pro vytvoření automatizovaného informačního systému pro podnik.

práce v kurzu, přidáno 4.12.2012


Vývoj funkčního modelu procesu řízení prodejny. Vypracování specifikací případů užití ve formě tabulek. Vytvářejte diagramy tříd, posloupností, stavů a ​​aktivit. Prezentace databáze, popis obrazovkových formulářů a dotazů.

práce v kurzu, přidáno 15.07.2012


Komplexní studie objektu informatizace - UralPromSnab LLC. Vývoj modelu obchodních procesů AS-IS a analýza úzkých míst. Vývoj technických specifikací pro nákup a implementaci hotového automatizovaného účetního systému „Galaktika ERP 9.1“.

práce v kurzu, přidáno 12.12.2013


Stanovení bezpečnostní třídy reproduktorové soustavy. Vývoj modelu ohrožení. Výběr mechanismů a prostředků ochrany informačních zdrojů před neoprávněným přístupem. Vytvoření adresářové struktury pro daný počet uživatelů automatizovaného systému.

Studentovo jméno

Pracovní pozice

Dozorce

Fakulta

Program

Rok ochrany

Tento článek popisuje návrh a vývoj informačního systému, který umožňuje sběr statistických dat o počtu uživatelských vyhledávacích dotazů ve vyhledávačích od roku 2004 do data analýzy; automaticky strukturovat přijatá data; analyzovat statistiky a vypočítat předpokládaný počet vyhledávacích dotazů na příští měsíc pomocí statistických metod včetně časových řad a také pomocí technologií neuronových sítí Cílem práce je navrhnout a vyvinout analytický informační systém, který bude poskytovat možnost predikce konkrétních uživatelských vyhledávacích dotazů Cíle výzkumu zahrnují: - analýzu odborné literatury, sběr, systematizaci a syntézu; instruktážní a regulační materiály, analýza předmětné oblasti - analýza metodik sběru a analýzy dat - analýza informačních technologií pro vývoj systému - testování a ladění vyvíjeného informačního systému; Předmětem studie jsou uživatelské vyhledávací dotazy Předmětem studie jsou nástroje pro analýzu a prognózování změn v počtu vyhledávacích dotazů na internetu. Závěrečná kvalifikační práce obsahuje úvod, 3 kapitoly, závěr a 3 přílohy stručně popisuje relevanci závěrečné kvalifikační práce, popisuje cíle a cíle informačního systému a dále popisuje hlavní cílové skupiny uživatelů, pro které je vyvíjený informační systém určen. První kapitola poskytuje přehled předmětné oblasti, analýzu klíčových konceptů, analýzy podnikových procesů a analýzy stávajících řešení. Jsou identifikovány hlavní potřebné uživatelské funkce vyvíjeného informačního systému, stanovena kostra informačního systému a zdůvodněna přiměřenost použití prognostických metod pro zadané úkoly. Druhá kapitola popisuje zdůvodnění výběru informačního systému vývojové nástroje a popisuje proces vývoje a testování informačního systému pro predikci vyhledávacích dotazů. Je popsán proces návrhu a tvorby databáze, obrazovkových formulářů a provozní logika informačního systému. Třetí kapitola poskytuje ekonomické zdůvodnění, zdůvodňující efektivitu využití vyvinutého informačního systému pro cílové skupiny – uživatele vyvíjeného informačního systému. Závěr je věnován popisu výsledků získaných při dokončování závěrečné kvalifikační práce, a to souladu stanovených cílů a záměrů s výsledky, stručnému popisu závěrů a posouzení ohledně predikčních schopností vyvíjeného informačního systému Práce je určena všem, kteří se zajímají o metody prognózování, sledování změn v počtu dotazů určitých vyhledávačů na internetu.

Závěrečné kvalifikační práce (GQT) na Vyšší ekonomické škole Národní výzkumné univerzity absolvují všichni studenti v souladu s univerzitou a pravidly stanovenými každým vzdělávacím programem.

Abstrakty všech disertačních prací jsou nezbytně zveřejněny veřejně na firemním portálu HSE.

Plné znění práce je zveřejněno jako volné dílo na portálu HSE pouze se souhlasem studenta - autora (držitele autorských práv) díla nebo v případě týmu studentů se souhlasem všech spolupracovnic. -autoři (držitelé autorských práv) díla. Po zveřejnění na HSE portálu získává práce status elektronické publikace.

V případě použití VKR, včetně citací, je vyžadováno jméno autora a zdroj výpůjčky.

Navrhuje se následující obsah ideálního WRC:

směr "Informatika a informatika".

• 1. Abstrakt podle GOST 7-86-2004.
• 2. Úvod. Předmětná oblast.
• 2.1. Popis předmětné oblasti.
• 2.2. Aplikované metody výzkumu a systémové analýzy předmětné oblasti.
• 2.3. Kritérium kvality předmětu, na jehož základě se hledá existující problém.
• 2.4. Výsledek výzkumu a analýzy: objevený problém, jehož řešením je videorekordér.
• 2.5. Relevance a praktický význam řešení identifikovaného problému.
• 2.6. Existující prostředky řešení problému, hotové nástroje, systémy nebo softwarové produkty. Stručný popis současného stavu rozpracované problematiky v Rusku a v zahraničí.
• 2.7. Zdůvodnění nevhodnosti stávajících nástrojů a nutnost vytvoření (případně významných úprav, úprav, doplnění stávajícího) informačního systému (IS).
• 2.8. Ekonomické, environmentální, sociální nebo jiné posouzení proveditelnosti vytvoření duševního vlastnictví k vyřešení problému.
• 3. Informační systém.
• 3.1. Cíle, kterým čelí vytvořený IS.
• 3.2. Problémy, které je třeba vyřešit k dosažení cílů.
• 3.3. Stanovení požadavků IS a volba způsobu stanovení požadavků: uživatelsky řízený vývoj, uživatelsky řízený vývoj, uživatelsky nezávislý vývoj.
• 3.4. Vývoj specifikací kvality IP. Můžete použít kvalitní primitiva:
• 3.4.1. Úplnost.
• 3.4.2. Přesnost.
• 3.4.3. Autonomie (samostatnost).
• 3.4.4. Robustnost.
• 3.4.5. Obrana.
• 3.4.6. Dokumentace.
• 3.4.7. Odpovědnost.
• 3.4.8. Komunikativnost.
• 3.4.9. Časová efektivita.
• 3.4.10. Účinnost zdrojů.
• 3.4.11. Účinnost zařízení.
• 3.4.12. Srozumitelnost.
• 3.4.13. Strukturovanost.
• 3.4.14. Čitelnost.
• 3.4.15. Rozšiřitelnost.
• 3.4.16. Modifikovatelnost.
• 3.4.17. Modularita.
• 3.4.18. Nezávislost na zařízení.
• 3.4.19. Další kvalitní primitivové.
• 4. Funkční modelování předmětné oblasti.
• 4.1. Výběr typu modelu funkční domény (SADT, DFD, IDEF3) na každé úrovni.
• 4.2. Výběr funkčního nástroje pro modelování domén.
• 4.3. Vytvoření modelu AS IS.
• 4.4. Analýza modelu, detekce nedostatků.
• 4.5. Optimalizace a reengineering funkčního modelu předmětné oblasti. Aplikace metod matematického modelování nebo teorie rozhodování k optimalizaci předmětné oblasti.
• 4.6. Vytvoření modelu TO BE (výsledek optimalizace).
• 4.7. Analýza důsledků reengineeringu.
• 4.8. Výběr procesů, které mají být automatizovány.
• 4.9. Rozbor vnějších vazeb modelu, tzn. příchozí a odchozí datové toky a události.
• 5. Vypracování funkční specifikace IS.
• 5.1. Popis vnějšího informačního prostředí, na které mají být programy vyvíjeného IS aplikovány.
• 5.2. Formulace funkcí IS definovaných na množině stavů konkrétního informačního prostředí (externí funkce IS).
• 5.3. Popis nežádoucích (výjimečných) situací, které mohou nastat při spouštění programů IS, a reakce na tyto situace, které musí odpovídající programy zajistit.
• 6. Informační modelování oborové oblasti.
• 6.1. Výběr nástroje pro tvorbu informačního modelu.
• 6.2. Informační model domény (ERD).
• 6.3. Normalizace dat v ERD. Racionální denormalizace.
• 6.4. Navrhování indexů.
• 7. Návrh IC.
• 7.1. Výběr softwarové architektury IS.
• 7.1.1. Výběr a zdůvodnění hlavního architektonického přístupu.
• 7.1.1.1. Celý program;
• 7.1.1.2. Sada autonomně prováděných programů;
• 7.1.1.3. Vrstvený (víceúrovňový) softwarový systém;
• 7.1.1.4. Skupina paralelně běžících programů.
• 7.1.2. Výběr architektury serveru: souborový server, SQL, terminálový server atd.
• 7.1.3. Volba architektury klienta: monolitický PS, klient-server (dvouvrstvý) PS, třívrstvý PS (klient - aplikační server - databázový server) atd.
• 7.1.4. Volba architektury IS z pohledu rozdělení na automatizované pracovní stanice (AWS), na kterých jsou implementovány funkce IS.
• 7.2. Výběr architektury technických informačních systémů (komunikace a telekomunikace, hardwarová architektura atd.). Výpočty šířky pásma počítačové sítě, doby odezvy atd.
• 7.3. Výběr OS pro všechny části IS PS.
• 7.4. Výběr modelu životního cyklu softwaru (vodopádový přístup, průzkumné programování, prototypování, spirálový přístup nebo jiný model).
• 7.5. Zdůvodnění a výběr systému správy databází (DBMS).
• 7.6. Výběr softwaru pro implementaci částí softwaru (klientská část, serverová část, „tenký“ nebo „tlustý“ klient, WEB rozhraní atd.).
• 7.7. Výběr a zdůvodnění volby programovacích technologií používaných v rámci vybraných softwarových nástrojů pro implementaci IS.
• 7.8. Rozdělení softwaru na části (moduly).
• 7.9. Ergonomická analýza vytvořených PS dílů.
• 7.10. Vývoj softwaru nebo modulů. Je třeba věnovat pozornost (a zohlednit v poznámce) následujícím bodům:
• 7.10.1. Vlastnosti a jemnosti implementace PS.
• 7.10.2. Pokyny ke kompilaci.
• 7.10.3. Pokyny pro umístění souborů.
• 7.10.4. Výběr a použití nástrojů pro vytváření objektů atd.
• 8. Výběr technologie implementace IP a metod řízení vývoje.
• 9. Vypracování doporučení pro výběr hardwaru IC.
• 10. Rozvoj opatření k zajištění spolehlivosti informačních systémů (redundance, zrcadlení, archivace atd.).
• 11. Rozvoj opatření k ochraně informací při provozu informačních systémů.
• 11.1. Administrativní opatření.
• 11.2. Software.
• 11.3. Hardware.
• 12. Vývoj prostředků komunikace mezi informačními systémy a externími datovými úložišti nebo informačními zdroji (streamy).
• 13. IP testování.
• 14. Instalace IS u zákazníka. Postup, popis nastavení IS a prostředí.
• 15. Doporučení pro implementaci IS.
• 15.1. Akce k přípravě zákazníka na implementaci.
• 15.2. Postup implementace konkrétních pracovních stanic IS a komponent IS.
• 15.3. Postup a program pro školení uživatelů automatizovaných pracovních stanic.
• 15.4. Popis provozu IS souběžně se stávajícími IS.
• 16. Tvorba dokumentace pro IS.
• 16.1. Zjištění možnosti a perspektiv spojení některých funkcí uživatele, správce a programátora IS.
• 16.2. Postup pro akce uživatele při provádění funkcí IS (uživatelská příručka).
• 16.3. Pořadí a četnost administrátorských úkonů při údržbě SŘB, kontrole integrity tabulek, přiměřenosti indexů, bezpečnosti dat, nastavování komponent IS, optimalizaci prostředí pro zlepšení chodu IS atd. Seznam možných poruch a opatření k jejich odstranění (příručka správce).
• 16.4. Akce při upgradu IS např. při vývoji dalších obrazovkových a tištěných formulářů (příručka pro vývojáře).
• 16.5. Seznam možných dotazů a problémů uživatelů a odpovědí (upřesnění) či akcí správce (Frequency Asked Questions).
• 17. Možnosti dalšího upřesnění nebo rozvoje OŠ.
• 18. Závěry, závěr (včetně vědecké novosti, relevance, praktické hodnoty a osobního příspěvku vývojáře).
• 19. Seznam použitých zdrojů podle GOST 7-1-2003.
• 20. Aplikace. Podpůrné materiály by měly být součástí příloh tak, aby nezatěžovaly text vysvětlivky. Mohou to být středně pokročilé matematické výpočty a výpočty, protokoly o zkouškách, popisy přístrojů a výpočetních nástrojů, programové dokumenty, výtisky programových textů, obrazovkové formuláře vyvinutých programů atd.

Uvedený seznam je výrazně rozšířen podle

ve srovnání s hlasitostí typického videorekordéru. Předpokládá se, že v souladu s charakteristikou konkrétního vytvářeného IS si student vybere

mu pouze ty pozice, které jsou vhodné pro jeho úkol.

Úvod

Moderní metody automatizace řízení výchovně vzdělávacího procesu

1 Koncept „elektronického deníku“

2 Recenze moderního softwaru pro řešení problematiky vedení elektronického žurnálu

Formulace problému

1 Účel, cíle tvorby informačního systému

2 Požadavky na informační systém

Funkčně orientovaný návrh informačního systému

1 Základní prvky modelu

2 Sestavení kontextového diagramu

3 Konstrukce diagramů rozkladu IDEF0

Návrh systémových informací

1 Informační analýza předmětné oblasti a identifikace informačních objektů

2 Vytvoření logického datového modelu

Návrh relační databáze

1 Popis relačního modelu

2. Popis databázových tabulek

3 Výběr DBMS

Vývoj klient-server aplikace pro práci s databází

1 Technologie klient-server

2 Programovací nástroje pro vyvíjenou aplikaci

3 Softwarová implementace modulu „Učitel“.

4 Softwarová implementace modulu „Team Leader“.

5 Softwarová implementace modulu „Správce provozovny“.

6 Softwarová implementace modulu „Parent“.

7 Softwarová implementace modulu „Technický správce systému“.

Studie proveditelnosti projektu

1 Účel práce

2 Stanovení rozsahu práce

3 Stanovení pracovní náročnosti vývoje

4 Výpočet odhadovaných nákladů na modul

5 Posouzení kvality systému evidence zátěže učitele

Závěr

Seznam použitých zdrojů

Příloha A. Výsledky střednědobé kontroly

Příloha B. Záznam školení

Příloha B: Prezenční listina

Příloha D. Stanovení funkčních závislostí

Příloha D. Ekonomická část

ÚVOD

Moderní informační technologie se rychle prosazují do všech sfér lidské činnosti, včetně oblasti vzdělávání. Úroveň rozvoje informačních zdrojů a povaha jejich využívání významně ovlivňují blahobyt společnosti a efektivitu výkonu konkrétní odborné činnosti. Vedoucí postavení každé organizace je dáno především jejími schopnostmi kompetentně využívat pokročilé úspěchy v oblasti informačních technologií. Zvláštní roli v tomto ohledu hraje oblast vzdělávání, kde se formuje intelektuální potenciál země, spotřebovává a vytváří její informační zdroje.

Informatizace je soubor prací zaměřených na vývoj, implementaci, údržbu, rozvoj a nahrazování tradičních technologií ve všech oblastech činnosti efektivnějšími informačními a telekomunikačními technologiemi.

Implementace AIS je zaměřena na řešení problémů plánování, účetnictví, kontroly, výměny informací, evidence a ukládání dat, zvýšení efektivity kancelářské práce, snížení podílu toku papírových dokumentů a zvýšení přesnosti analytické práce.

Vývoj webových technologií dnes přináší nové výhody do návrhu a vývoje takových systémů. Moderní prostředky pro vytváření webových technologií jsou srovnatelné a nejsou horší v rychlosti a pohodlí s konvenčními desktopovými aplikacemi, přičemž jsou dostupné kdykoli a odkudkoli na světě, aniž by vyžadovaly specializovaný software a operační systém. Tyto výhody povzbuzují zákazníky a následně i vývojáře, aby vytvářeli aplikace s webovým rozhraním jako náhradu za desktopová řešení nebo lokální řešení.

Státní univerzita Vologda již řadu let aktivně a velmi úspěšně pracuje na informatizaci vzdělávacího procesu za účelem zkvalitnění vzdělávání.

Jedním ze systémů, který je často implementován kvůli potřebě jeho použití, je elektronická klasifikační kniha, která automatizuje proces sledování pokroku, duplikuje záznamy tradičního papírového časopisu, chrání jej před zkreslením, umožňuje řídit akumulaci známky z předmětů atd.

Účelem této práce je sestavení modelu informačního systému „Elektronický žurnál“ a vývoj webové aplikace pro automatizaci procesu vedení žurnálu o akademických výkonech a docházce.

Hlavní cíle projektu jsou:

Vývoj funkčního modelu systému;

Vývoj logického modelu systému;

Vývoj fyzického modelu systému;

Vývoj databází;

Vývoj aplikace pro práci s databází.

1. Moderní metody automatizace řízení výchovně vzdělávacího procesu

.1 Pojem „Elektronický žurnál“

Každá vzdělávací instituce se potýká s velkým tokem papírování. Učitelé denně provádějí desítky manipulací, aby vybrali potřebné informace a vyplnili třídní deník.

V dnešní době je úroveň informačních technologií poměrně vysoká a stále větší množství elektronické dokumentace nabývá oficiálního statusu a nahrazuje fyzické zdroje. Informační technologie tak umožňují zavést systém dodatečného sledování pokroku studentů a zároveň automatizovat tento proces ve vzdělávací instituci.

Elektronický časopis je pohodlný, výkonný nástroj pro vytváření jednotného informačního a vzdělávacího prostoru pro vzdělávací instituci a pro interakci vzdělávací instituce s rodiči studentů.

Vzhledem k tomu, že elektronický časopis je informační systém, stačí vyplnit všechny údaje o studentech a vzdělávacím procesu jednou a v budoucnu je pouze případně doplnit či opravit.

.2 Recenze moderního softwaru pro řešení problému vedení elektronického žurnálu

Na velké úrovni existují různé implementace podobných systémů. V jiných zemích je automatizace vzdělávacího procesu na ještě vyšší úrovni než v institucích u nás. Je to pravděpodobně způsobeno jak obecným zaostáváním naší země v informačních technologiích, tak i rozšířeným rozvojem dálkového vzdělávání v západních zemích. Ten podněcuje automatizaci akcí ve vzdělávání, zavádění webových rozhraní pro přístup k automatizačním nástrojům. Vysokoškolský student, který studuje dálkově, má někdy možnost ověřit si situaci pouze přes internet, proto je pro úspěšné zavedení dálkového vzdělávání nutný přístup k vlastnímu účtu přes World Wide Web.

V Rusku rozvoj distančního vzdělávání teprve začíná nabírat na síle. Počet těchto služeb tedy zatím není v takovém rozsahu jako v zahraničí. Kromě toho jsou téměř všechny instituce, které zavádějí distanční vzdělávání a služby zaměřené na výsledky studentů, považovány za pobočky zahraničních institutů a středních vzdělávacích institucí. K podobným implementacím v Rusku patří software pro sledování výkonu na středních školách, který je zaměřen na informování rodičů o stavu jejich dětí. Taková řešení vyvíjejí soukromé společnosti. Mnoho škol ve městě tak zavedlo systém elektronických žákovských diářů, s jejichž pomocí mají rodiče žáků všechny možnosti sledovat své vlastní děti. Téměř všechny tyto služby však neposkytují přístup k údajům o studijních výkonech dospívajících prostřednictvím internetu. Vznik takových „elektronických časopisů“ však přesto není špatným předpokladem pro větší rozvoj podobných systémů v mnohem větším měřítku.

Mezi plány podobnými tomu, které jsou vyvíjeny, bychom měli vyzdvihnout zdroj „Vzdělávací portál distančního vzdělávání“ Státní univerzity Vologda, postavený na platformě MOODLE, který je stále považován za dobrý příklad webové služby pro studenty pro vzdělávací účely. . Systém je zaměřen především na organizaci interakce mezi učitelem a studenty, ale je vhodný i pro pořádání pravidelných distančních kurzů a také asistenci při prezenční výuce. Zdroj mohou používat studenti po obdržení registračních údajů od učitele, který kurz zveřejnil.

Nejúspěšnější implementace systému elektronického žurnálu v Rusku jsou:

· www.antcol.ru/jur - Záznam o pokroku studentů Mezinárodní vysoké školy cestovního ruchu (obr. 1.2.1).

Rýže. 1.2.1 - Žurnál o pokroku studentů Mezinárodní vysoké školy cestovního ruchu

· www.emsy.org - Nezávislá online služba elektronických klasifikačních knih, zaměřená na vzdělávací instituce zemí SNS - školy, předškolní zařízení, lycea, vysoké školy, technické školy, instituty, certifikační centra a další. Hlavní funkcí služby je organizování a udržování klasifikačních časopisů na internetu (obr. 1.2.2).

· www.dnevnik.ru - Všeruská bezplatná školní vzdělávací síť (obr. 1.2.3).

Rýže. 1.2.2 - Nezávislá online služba elektronických časopisů www.emsy.org

Rýže. 1.2.3 - Všeruská bezplatná školní vzdělávací síť www.dnevnik.ru

Po prozkoumání dostupných řešení v souladu s tématem můžeme dojít k závěru, že předložený problém je považován za ne zcela vyřešený, což poskytuje velké příležitosti pro budoucí výzkum a zlepšování. Pravděpodobně je to zvláště důležité pro naši zemi obecně a zejména pro Vologdu. Implementace webových služeb pro elektronický časopis má pro studenty zásadní praktický význam, protože jim umožní sledovat jejich stav ve vzdělávací instituci kdykoli a z jakéhokoli místa s dostupností World Wide Web. Rodičům také usnadňuje kontrolu dětí (známky a docházku).

2. Vyjádření problému

.1 Účel, cíle tvorby informačního systému

Vyvíjený informační systém musí vést automatizovanou evidenci pokroku a docházky studentů.

Informační systém „Elektronický žurnál“ je určen pro komplexní informační a analytickou podporu procesů vzdělávací instituce v rámci plnění následujících funkcí:

zadávání a editace údajů o výkonu studentů;

zadávání a editace údajů o docházce studentů na výuku;

zadávání a editace seznamu studentů, seznamu skupin a seznamu odborností;

zadávání a editace kurikula;

výstup akademického výkonu podle zadaných parametrů;

výstup docházky.

Informační systém „Elektronický žurnál“ je určen pro použití ve vzdělávacích institucích, které plní výše popsané funkce.

Hlavní cíle tvorby informačního systému jsou:

zvýšení efektivity provádění výše uvedených procesů snížením neproduktivních a duplicitních operací, operací prováděných „ručně“, optimalizací informační interakce účastníků procesu;

zlepšení kvality rozhodování managementu díky rychlosti prezentace, úplnosti, spolehlivosti a pohodlí formátů zobrazování informací;

zvýšení informační otevřenosti a transparentnosti činnosti vzdělávací instituce;

zvýšení pohodlí a komfortu při získávání informací o službách poskytovaných spotřebiteli.

.2 Požadavky na informační systém

Klíčové požadavky na vytvořený systém jsou:

otevřenost, to znamená, že musí splňovat všechny moderní standardy, podporu webových technologií a také schopnost přidávat funkce jak od vývojářů třetích stran, tak od vývoje studentů;

škálovatelnost jako klíčový požadavek z hlediska úspor. Při zvyšování funkčnosti není nutné systém znovu přestavovat;

Multiplatformní, schopnost pracovat na různých zařízeních, operačních systémech, serverech;

přizpůsobivost, tedy schopnost snadno se přizpůsobit potřebám zákazníka;

rozšiřitelnost, to znamená schopnost zvýšit funkčnost systému bez změny dříve přijaté metody vývoje a základny,

lokalizace, to znamená podpora národních požadavků a standardů v oblasti toku dokumentů, organizace procesu učení, rysy ruského vzdělávacího systému.

Základní požadavky na vyvíjený informační systém ohledně funkčnosti jsou následující:

Systém musí zajistit důvěrnost informací tak, aby do osobních údajů studenta mohl nahlížet pouze on sám, jeho rodiče a pedagogický sbor technické školy a změny mohli provádět pouze příslušní učitelé;

Student je zařazen do jedné ze skupin a skupina je zase přiřazena k jedné ze specializací;

Každá disciplína je přiřazena jedné ze skupin a také jednomu z učitelů;

Kód studenta je jedinečný a neměnný;

Počty oborů, skupin a specializací jsou jedinečné a neměnné, ale jejich názvy se mohou změnit.

3. Funkčně orientovaný návrh informačního systému

.1 Hlavní prvky modelu

Tabulka 3.1.1 ukazuje hlavní prvky modelu informačního systému.

Tabulka 3.1.1

Základní prvky doménového modelu

Název projektu: Návrh informačního systému pro evidenci prospěchu a docházky studentů Cíl projektu: Připravit funkční model podnikového procesu vedení evidence prospěchu a docházky studentů Technologie modelování: Metoda funkčního modelování IDEF0 Nástroje: BPWin 4.0 software Seznam údajů: Seznam odborností; Seznam skupin; Seznam oborů; Seznam studentů; Studijní výsledky; Docházka Seznam funkcí: A0. Vedení elektronického časopisu o akademických výkonech a docházce A1. Zadávání a editace dat A1.1. Zadání odborností A1.2. Zadávání skupin A1.3. Zadání disciplín A1.4. Vstup studenta A1.5. Zadávání studijních výsledků A1.6. Zadání docházky A2. Zpracování požadavku uživatele A2.1. Výběr parametrů dotazu A2.2. Zpracování požadavku

Tabulka 3.1.2 uvádí popis funkčních bloků modelu domény.

Tabulka 3.1.2

Popis funkčních bloků

Název bloku Popis úloh k řešení A1. Zadávání a editace dat Tento blok zahrnuje všechny fáze zadávání a editace dat A2. Zpracování uživatelského požadavku Tento blok obsahuje všechny fáze zpracování uživatelského požadavku

.2 Sestavení kontextového diagramu

Nejvyšší diagram, ve kterém je objekt modelování reprezentován jedním blokem s hraničními šipkami. Tento diagram se nazývá A-0. Šipky v tomto diagramu představují vztahy mezi modelovaným objektem a jeho prostředím. Protože jeden blok představuje celý objekt, jeho název je společný pro celý projekt. Totéž platí pro všechny šipky v diagramu, protože představují kompletní sadu externích rozhraní objektu. Diagram A-0 určuje oblast modelování a její hranici.

Kontextový diagram A-0 by měl také obsahovat stručná prohlášení, která identifikují úhel pohledu osoby nebo oddělení, ze kterého je model vytvářen, a účel, pro který je vyvíjen. Tato prohlášení pomáhají řídit vývoj modelu a rámují proces. Úhel pohledu určuje, co a v jakém kontextu lze vidět v kontextu modelu. Změna úhlu pohledu vede k úvahám o dalších aspektech objektu. Aspekty, které jsou důležité z jednoho úhlu pohledu, se nemusí objevit v modelu vyvinutém z jiného úhlu pohledu na stejný objekt. Cílové prohlášení vyjadřuje důvod vytvoření modelu, tzn. obsahuje seznam otázek, na které musí model odpovědět, což do značné míry určuje jeho strukturu. Nejdůležitější vlastnosti objektu jsou obvykle identifikovány na nejvyšších úrovních hierarchie; Jak je funkce nejvyšší úrovně rozložena a rozdělena na podfunkce, jsou tyto vlastnosti zpřesňovány. Každá podfunkce je zase rozložena na prvky další úrovně, a to se děje, dokud není získána relevantní struktura, která umožňuje odpovědět na otázky formulované v cíli modelování. Každá podfunkce je modelována jako samostatný blok. Každý nadřazený blok je podrobně popsán podřízeným diagramem na nižší úrovni. Všechny podřízené diagramy musí být v oblasti kontextového diagramu nejvyšší úrovně.

Činnosti odkazují na pojmenované procesy, funkce nebo úkoly, které se vyskytují po určitou dobu a mají rozpoznatelné výsledky. Díla jsou zobrazena jako obdélníky. Všechna díla musí být pojmenována a definována. Název práce musí být vyjádřen slovním podstatným jménem označujícím akci (například „Vedení elektronického protokolu známek a docházky“). Práce „Vedení elektronického časopisu o akademických výkonech a docházce“ může mít např. následující definici: „Jedná se o model, který popisuje proces opakovaného zadávání a editace osobních údajů studentů a jejich následný výstup uživateli.“ Když vytvoříte nový model, automaticky se vytvoří kontextový diagram s jediným dílem zobrazujícím systém jako celek.

Interakce děl s vnějším světem a mezi sebou navzájem je popsána ve formě šipek. Šipky představují nějaké informace a nazývají se podstatná jména. Existují 4 typy šipek:

Vstup. Jsou umístěny na levé straně a popisují materiál nebo informace, které jsou v této práci transformovány;

Víkend. Jsou umístěny na pravé straně a popisují materiál nebo informace, které tato práce vytváří (musí být přítomna alespoň jedna šipka tohoto typu);

Management - pravidla, postupy nebo normy, předpisy, na základě kterých by tato práce měla být prováděna (musí být také přítomna alespoň jedna šipka);

Zdroje nebo mechanismy (materiál, práce, finanční zdroje).

Na Obr. 3.2.1 ukazuje kontextový diagram „Vedení elektronického deníku a docházky“.

Rýže. 3.2.1 - Kontextový diagram „Vedení elektronického časopisu o akademických výkonech a docházce“

.3 Konstrukce diagramů rozkladu IDEF0

Po popisu systému jako celku je rozdělen na velké fragmenty. Tento proces se nazývá funkční rozklad a diagramy, které načrtávají jakýkoli fragment a interakci fragmentů, se nazývají diagramy rozkladu. Po rozložení kontextového diagramu je každý velký fragment systému rozložen na nejmenší atd., dokud není dosaženo vhodné hodnoty pro detail popisu. Po každém rozkladovém sezení se provádějí zkušební sezení - odborníci na předmět ukazují vztah mezi skutečnými obchodními procesy a vytvořenými diagramy. Jakékoli zjištěné nesrovnalosti jsou opraveny a pouze po úspěšném absolvování zkoušky a v případě absence jakýchkoli připomínek je povoleno přistoupit k dalšímu rozkladu. To zajišťuje, že model odpovídá skutečným obchodním procesům na jakékoli úrovni modelu. Syntaxe pro popis systému jako celku a každého jeho fragmentu je podobná v celé konstrukci celého modelu.

Dekompoziční diagramy obsahují podobnou práci, tzn. podřízená zaměstnání, která mají zaměstnání jednoho rodiče. Při vytváření diagramu rozkladu musíte uvést zápis nového diagramu a počet prací na něm. Možný zlom v počtu prací - 2-8. Nemá smysl rozkládat práci do jedné úlohy: diagramy s více než 8 úlohami jsou příliš saturované a nejsou správně čitelné. Pro zajištění přehlednosti a lepšího pochopení simulovaných procesů se doporučuje použít 3 až 6 bloků na jednom diagramu. Pokud se ukáže, že počet prací nestačí, lze práci přidat do diagramu nejprve kliknutím na tlačítko na paletě nástrojů a poté na volné místo na diagramu.

Práce na rozpisových diagramech je tradičně umístěna diagonálně z levého horního rohu do pravého dolního rohu. Tento rozvrh se nazývá nejdůležitější práce, provedená jako první, v levém horním rohu. Dále vpravo jsou nejméně důležité práce nebo ty, které budou dokončeny později. Toto uspořádání zjednodušuje čtení diagramů, navíc z něj vychází koncepce pracovních vztahů (obr. 3.3.1).

Každá z úloh na diagramu rozkladu může být zase rozložena (obr. 3.3.2). V členění je práce číslována automaticky zleva doprava. Číslo zakázky je zobrazeno v pravém dolním rohu.

Rýže. 3.3.1 - Dekompozice první úrovně pro proces „Vedení elektronického časopisu o akademických výkonech a docházce“

Rozpisový diagram je navržen pro detail práce. Na rozdíl od modelů, které zobrazují strukturu organizace, není práce na diagramu nejvyšší úrovně v IDEF0 kontrolou nad prací pod ním. Práce nižší úrovně je stejná jako práce vyšší úrovně, ale podrobněji. V důsledku toho jsou hranice díla nejvyšší úrovně stejné jako hranice dekompozičního diagramu.

Při rozkladu díla se šipky vstupující do něj a opouštějící jej (kromě šipky volání) automaticky objeví na diagramu rozkladu (migrace šipek), ale díla se nedotýkají.

Chcete-li propojit šipky vstupu, ovládacího prvku nebo mechanismu, musíte přejít do režimu úpravy šipek, kliknout na šipku a poté na odpovídající pracovní segment. Chcete-li propojit šipku výstupu, musíte přejít do režimu úpravy šipky, kliknout na segment výstupu práce a poté na šipku.

Pro vzájemné propojení děl se používají vnitřní šipky, to znamená šipky, které se nedotýkají hranice schématu, začínají na jedné a končí na druhé.

Chcete-li nakreslit vnitřní šipku, musíte v režimu kreslení šipky kliknout na segment (například výstup) jednoho díla a poté na segment (například vstup) jiného díla. IDEF0 rozlišuje mezi následujícími typy pracovních vztahů.

Komunikace vstupem (výstup-vstup), kdy výstupní šipka práce vyšší úrovně směřuje na vstup práce nižší úrovně (např. na obr. 2 šipka „Účetní list výrobku“ spojuje práci „ Zadávání a editace výrobních dat“ a „Vyhledávání produktových dat“);

Řídící komunikace (output-control), kdy je výstup z vyšší úrovně odeslán k ovládání té nižší. Komunikace managementu ukazuje dominanci práce na vyšší úrovni. Data nebo výstupní objekty práce vyšší úrovně se v práci nižší úrovně nemění;

Zpětná vazba výstup-vstup, kdy je výstup úlohy nižší úrovně směrován na vstup úlohy vyšší úrovně. Takový vztah se obvykle používá k popisu cyklů;

Zpětná vazba výstupního řízení, kdy je výstup operace nižší úrovně odeslán do řízení vyšší úrovně.

Explicitní šipka má zdroj jedné a pouze jedné úlohy a cíl jedné a pouze jedné úlohy.

Větvení a slučování šipek. Stejná data nebo objekty generované jednou úlohou lze použít v několika dalších úlohách najednou. Na druhou stranu šipky generované v různých dílech mohou představovat stejná nebo homogenní data nebo objekty, které jsou dále používány nebo zpracovávány na jednom místě. K modelování takových situací používá IDEF0 větvení a slučovací šipky. Chcete-li šipku větvit, v režimu úpravy šipky klikněte na fragment šipky a na odpovídající pracovní segment. Chcete-li sloučit dvě šipky odchodu, v režimu úprav šipek nejprve klikněte na segment pracovního východu a poté na odpovídající fragment šipky.

Význam větvení a slučování šipek vyjadřuje pojmenování každé větve šipek. Pro pojmenování takových šipek platí určitá pravidla. Podívejme se na ně na příkladu rozvětvených šipek. Pokud je před větví pojmenována šipka, ale za větví nejsou pojmenovány žádné větve, předpokládá se, že každá větev modeluje stejná data nebo objekty jako větev před větví.

Pokud je před větví pojmenována šipka a za větví je také pojmenována některá z větví, pak se předpokládá, že tyto větve odpovídají pojmenování. Pokud některá větev zůstane po větvení bez názvu, pak se předpokládá, že modeluje stejná data nebo objekty jako větev před větvením.

Všechny modelové práce jsou číslovány. Číslo se skládá z předčíslí a čísla. Lze použít předponu libovolné délky, ale obvykle se používá předpona A Kontextová (kořenová) práce stromu je očíslována A0. Dekompoziční díla A0 mají čísla A1, A2, A3 atd. Rozkladové dílo nižší úrovně má číslo nadřazeného díla a další pořadové číslo, například rozkladové dílo A3 bude mít čísla A31, A32, AZZ, A34 atd. Úlohy tvoří hierarchii, kde každá úloha může mít jednu nadřazenou práci a několik podřízených úloh, které tvoří strom. Takový strom se nazývá uzlový strom a výše popsané číslování se nazývá číslování podle uzlů. Diagramy IDEF0 jsou číslovány dvakrát. Nejprve jsou diagramy očíslovány podle uzlu. Kontextový diagram má vždy číslo A-0, rozklad kontextového diagramu má číslo A0, zbývající rozkladové diagramy mají čísla pro odpovídající uzel (například A1, A2, A21, A213 atd.). BPwin automaticky podporuje číslování uzlů, tzn. Po provedení rozkladu se vytvoří nový diagram a automaticky se mu přiřadí odpovídající číslo. V důsledku zkoumání mohou být diagramy zpřesňovány a měněny, a proto lze vytvářet různé verze stejného (z hlediska jeho umístění ve stromu uzlů) dekompozičního diagramu. BPwin umožňuje mít v modelu v daném uzlu pouze jeden dekompoziční diagram.

4. Návrh systémové informační podpory

.1 Informační analýza předmětné oblasti a identifikace informačních objektů

Při navrhování informační podpory pro systém je studována předmětná oblast, analyzována data a stanoveny hlavní objekty předmětné oblasti.

Prvním krokem při navrhování informační podpory je identifikace složení dokumentů a jejich detailů na základě analýzy předmětné oblasti. V tomto kroku je také analyzována skladba formulářů dokumentů předmětné oblasti. Na základě analýzy oborové oblasti lze rozlišit následující vstupní dokumenty: seznam odborností, seznam skupin, seznam studentů, seznam oborů, časopisy s výkony a docházkou studentů.

Formy těchto oborových dokumentů jsou rozebrány v přílohách (viz přílohy A, B, C).

Dalším krokem při budování informačně-logického modelu je stanovení funkčních závislostí mezi detaily na základě analýzy předmětné oblasti a analýzy dokumentů v dané oblasti.

V tomto kroku se určí závislost jednoho detailu na druhém, a pokud taková závislost existuje, pak se mezi těmito detaily vytvoří spojení.

Informace získané během tohoto kroku uvádíme ve formě následující tabulky (viz Příloha D).

Dále je nutné rozdělit všechny detaily na popisné a klíčové a jako klíčový požadavek z hlediska úspory investic zajistit, aby s narůstajícím objemem zpracovávaných informací a zvyšováním funkčních závislostí nebylo nutné systém přestavovat. detailů.

Pro analýzu detailů vytvoříme tabulku (tab. 4.1.1).

Tabulka 4.1.1

Definování typů detailů

dokumentPopisné údajeKlíčové detailyKey typeName of information objectSeznam studentůjméno_student n_skupina heslon_zbookП, УStudentsSeznam učitelůjmeno_učitel přihlášení passwordn_teacherП, УUčiteléSeznam specialitname_speciality term_studium zkratkan_specialitySpecialitiesП, Уn skupina P, U Skupiny Seznam oborů n_název_skupiny_disciplína n_učitel sem_start sem_endn_disciplína P,U Disciplíny Milník výkonnosti markn_zbook n_disciplína po C, U Úspěchy Semestr výkon markn_zbook n_disciplína n_sem C, U Achievement Milník docházka no_reazon totaln_zbook po C, U Docházka Semestrální docházkano_reazon totaln_zbook n_semС, УDocházka

Dalším krokem při konstrukci informačně-logického modelu je popis informačních objektů, tzn. provádí se strukturování popisných detailů, které jsou stejně závislé na jednom nebo více klíčových detailech. V každé skupině uvedeme klíčové detaily společné pro tuto skupinu. Každá taková skupina se bude nazývat informační objekty.

Pro analýzu detailů vytvoříme tabulku (tab. 4.1.2).

Tabulka 4.1.2

Popis informačních objektů

Podrobnosti IO Klíčový atribut Název IOSemantika_zknihy jméno_studenta n_skupina hesloP, USstudentiInformace o studentechn_jmeno_ucitele_prihlasovaci heslo pro uciteleP, UUciteleInformace o ucitelin_specialita jmeno_specialita termin_studie zkratkaP, USspecialityInformace o specialitach, jmeno_skupiny_skupiny_skupina_skupina_Insp e n_group name_disciplína n_teacher sem_start sem_endP, UdisciplinesInformace o disciplínáchn_zbook, n_discipline, mon, markС, UProgressInformace o milníku studentů n_zbook, n_disciplína, n_sem známkaС, UProgressInformace o výsledcích studentů v semestrun_zbook, po bez_reazon, celkemС, УDocházkaInformace o milníku studentů docházka_zbook, n_sem no_reazonУ semestrální informaceA Informační objekty musí splňovat všechny požadavky na normalizaci:

Informační objekt musí obsahovat jedinečný identifikátor;

Všechny ostatní popisné detaily musí být vzájemně nezávislé;

Všechny podrobnosti obsažené ve složeném klíči musí být vzájemně nezávislé;

Každý popisný atribut musí funkčně plně záviset na klíči informačního objektu;

U složeného klíče musí popisné detaily zcela záviset na detailech, které tvoří klíč;

Každý popisný atribut nemůže přechodně záviset na klíči.

Podle požadavků normalizace jsou mezi informačními objekty povolena spojení 1:1 a 1:M. Určíme typ spojení mezi informačními objekty (tabulka 4.1.3).

Tabulka 4.1.3

Definování typů odkazů

Komunikační číslo vztahuHlavní IO Podřízený IOTyp vztahu1SpecialitySkupiny1:M2SkupinyStudenti1:M3UčiteléSkupiny1:14UčiteléDisciplíny1:M

Při sestavování informačně-logického modelu je třeba informační objekty seřadit podle úrovní (obr. 4.1.1).

Prezentovaný informačně-logický model posuzované předmětné oblasti je postaven v souladu s identifikovanými informačními objekty a vazbami mezi nimi.

Rýže. 4.1.1 - Úrovně informačních objektů

Informačně-logický model je prezentován v kanonické podobě a objekty v něm jsou uspořádány podle úrovní. Na nulové úrovni jsou objekty, které nejsou podřízeny žádným jiným objektům. Úroveň ostatních objektů je určena nejdelší cestou k objektu z nulové úrovně.

Toto uspořádání objektů dává představu o jejich hierarchické podřízenosti, činí model vizuálnějším a usnadňuje pochopení jedno- a vícehodnotových vztahů mezi objekty.

4.2 Sestavení logického datového modelu

Informačně-logický model zobrazuje data předmětné oblasti ve formě souboru informačních objektů a vazeb mezi nimi. Tento model představuje data, která mají být uložena v databázi.

Vytvoření relační databáze pomocí. ERwin začíná zavedením entit definovaných v logickém diagramu do diagramu. Po definování entit je nutné zadat atributy těchto entit do schématu. Každý z atributů je spojen s určitým typem dat. Zadáním atributů entity definujeme databázové tabulky odpovídající doménovým entitám. V poslední fázi určíme souvislosti mezi zadanými tabulkami.

Jakmile jsou všechny entity definovány, je nutné definovat vztahy mezi nimi. Vztah v ERwin je považován za funkční závislost mezi dvěma entitami. Pokud diagram považujeme za grafické znázornění oblasti předmětu, pak entity jsou podstatná jména a spojení jsou slovesa.

Rýže. 4.2.1 - Informační a logický model „Elektronická klasifikace“

Vztahy mezi objekty datového modelu jsou implementovány stejnými detaily - klíči připojení v odpovídajících tabulkách. V tomto případě je klíč vztahu typu 1:M vždy jedinečný klíč hlavní tabulky. Klíč vztahu v podtabulce je buď částí jedinečného klíče v ní, nebo polem, které není součástí primárního klíče. Klíč vztahu v podřízené tabulce se nazývá cizí klíč.

Všechny souvislosti ve výsledném informačně-logickém modelu předmětu „Elektronický žurnál“ jsou charakterizovány vztahem typu 1:M.

Na základě analýzy předmětné oblasti lze sestavit následující informační a logický model, znázorněný na Obr. 4.2.1.

5. Návrh relační databáze

.1 Popis relačního modelu

Relační systémy jsou založeny na relačním datovém modelu. Principy relačního modelu byly stanoveny v letech 1969-1970. Americký vědec E.F. Codd (E.F. Codd), poté pracující pro IBM Corporation. Vystudovaný matematik přinesl do oblasti správy databází přísné matematické principy a přesnost, kterou rané systémy postrádaly. Přestože se vztahový přístup neprosadil okamžitě, lze poznamenat, že téměř všechny vznikaly od konce 70. let. Databázové produkty jsou založeny speciálně na relačním přístupu. Naprostá většina vědeckého výzkumu v oblasti databází za posledních 35 let probíhala také tímto směrem.

Při zvažování a postupném objasňování základních pojmů relačního modelu budeme mít na paměti tři složky datového modelu:

· datové struktury,

· operace, které lze s daty provádět, a

· omezení související se zajištěním integrity dat.

Hlavní datovou strukturou v relačním modelu jsou tabulky, v relační teorii nazývané vztahy. Ve skutečnosti samotný název modelu pochází z pojmu vztah (v angličtině vztah) - relační.

.2 Popis databázových tabulek

Logická struktura relační databáze je adekvátním odrazem výsledného informačně-logického modelu předmětné oblasti. Kanonický model nevyžaduje žádné další transformace. Každý informační objekt datového modelu je reprezentován odpovídající relační tabulkou. Struktura relační tabulky je určena požadovaným složením odpovídající informační tabulky; objekt, kde každý sloupec (pole) odpovídá jednomu z detailů objektu. Klíčové detaily objektu tvoří jedinečný klíč relační tabulky. Pro každý sloupec tabulky (pole) je určen typ, velikost dat a další vlastnosti. Řádky (záznamy) tabulky odpovídají instancím objektu a jsou tvořeny při načítání tabulky.

Uvedené formy dokumentů s normativními, referenčními a provozními informacemi obsahují detaily, jejichž hodnoty by měly být uloženy v databázi informačního systému. Tyto hodnoty se zadávají z klávesnice počítače nebo se vybírají ze seznamů ve formulářích na obrazovce. Níže jsou uvedeny charakteristiky podrobností dokumentu z oblasti předmětu. Návrhář je může v případě potřeby změnit, stejně jako přidat další detaily.

Tabulka 5.2.1

Tabulka "Seznam studentů"

Atribut Klíčový atributField formatNameNameTypeLengthIdAutomatic fieldPrimaryNumeric (Long Integer)8name_studentCelé jméno studentaText (Text)250n_groupGroup numberNumeric (Long Integer)8passwordPasswordText (Text)32

Tabulka 5.2.2

Tabulka "Seznam učitelů"

Atribut Atribut klíče Formát poleJménoJménoTypDélka_učitelČíslo učitelePrimárníNumerické (Dlouhé celé číslo)8jméno_učitel Celé jméno učiteleText (Text)250loginUsernameText (Text)10hesloHesloText (Text)32 Tabulka 5.2.3

Tabulka "Seznam specialit"

Atribut Klíčový atributFormát poleJménoJménoTypDélka_specialityČíslo specializacePrimárníNumerický (Dlouhé celé číslo)8název_specialitaNázev specialityText (Text)250term_studyDoba školeníČíselný (Dlouhé celé číslo)8zkratkaZkratkaNíselné číslo)10

Tabulka 5.2.4

Tabulka "Seznam skupin"

Atribut Klíč Atribut Formát pole Jméno Jméno Typ Délka n_skupina Číslo skupiny Primární (Primární) Numerický (Dlouhé celé číslo) 8n_specialita Číslo speciality Numerický (Dlouhé celé číslo) 8 jméno_skupina Název skupiny Text (Text) 250n_teacher Třídní učitel Numerický (Dlouhé celé číslo) 8

Tabulka 5.2.5

Tabulka "Seznam oborů"

Atribut Klíčový atribut Formát pole Jméno Jméno Typ Délka n_obor Číslo oboru Primární (Primární) Číselné (Dlouhé celé číslo) 8n_skupina Číslo skupiny Číselné (Dlouhé celé číslo) 8název_disciplína Název oboru Text (Text) 250n_učitel Číslo učitele Číselné (Dlouhé celé číslo) 8sem_start Začátek semestru akademický rok. Numerical (Long Integer)2sem_endSemester ukončení studia.Numerical (Long Integer)2

Tabulka 5.2.6

Tabulka "Milník výkonu"

Atribut Klíčový atribut Formát pole Jméno Jméno Typ Délka n_zbook Číslo klasifikační knihy Numerický (Long Integer) 8n_disciplina Číslo disciplíny Numerický (Long Integer) 8měsíců Měsíc Numerický (Long Integer) 2 bod Skóre Numerický (Long Integer) 1

Tabulka 5.2.7

Tabulka "Výkon za semestr"

Atribut Atribut klíče Formát pole Jméno Jméno Typ Délka n_zbook Číslo klasifikační knihy Numerický (Long Integer) 8n_disciplína Číslo disciplíny Numerický (Long Integer) 8n_sem Semestr Numerický (Long Integer) 2 body Známka Numerický (Long Integer) 1

Tabulka 5.2.8

Tabulka "Účast na stříhání"

Atribut Atribut klíče Formát pole Jméno Jméno Typ Délka n_zbook Číslo klasifikační knihy Numerický (Long Integer) 8měsíc Měsíc Numerický (Long Integer) 2no_reazon Bez uv. důvodyNumeric (Long Integer)5totalTotalNumeric (Long Integer)5

Tabulka 5.2.9

Tabulka "Docházka za semestr"

Atribut Atribut klíče Formát pole Jméno Jméno Typ Délka n_zbook Číslo klasifikační knihy Numerický (Long Integer) 8n_sem Semestr Numerický (Long Integer) 2no_reazon Bez uv. důvodyNumeric (Long Integer)5totalTotalNumeric (Long Integer)5

.3 Výběr DBMS

Chcete-li se rozhodnout o výběru DBMS, můžete analyzovat ty nejoblíbenější: Postgre, MySQL a MSSQL Server. Tyto systémy budou analyzovány na základě řady charakteristik. Na základě analýzy výsledků bude rozhodnuto o prioritě každého konkrétního DBMS pro vybranou tematickou oblast.

Seznam požadavků na DBMS použitý při analýze konkrétního informačního systému se může lišit v závislosti na stanovených cílech.

Pro vysoce zatížené systémy se používá architektura klient-server, což znamená, že pro databáze je použit samostatný dedikovaný server.

Mnoho výrobců DBMS vyrábí nástroje pro vývoj aplikací pro své systémy, které vám umožňují doladit samotný server. Na základě toho se vyplatí vybrat DBMS, které lze nainstalovat bez speciálního softwaru.

MySQL, na rozdíl od Microsoft SQL Server a Postgre, nemá spouštěče a procedury, což je považováno za nevýhodu. Z tohoto důvodu musíte organizovat všechny úkoly v aplikaci a nepoužívat standardní nástroje, čímž komplikujete tvorbu aplikace.

Tabulka 5.3.1 ukazuje seznam operačních systémů, pod kterými může systém správy databáze pracovat.

Tabulka 5.3.2 ukazuje výhody a nevýhody DBMS

Tabulka 5.3.1

Podporované operační systémy

Operační systémy DBDOPostgreWindows, Linux, UnixMS SQL ServerWindowsMySQLLinux, Unix, Windows

Tabulka 5.3.2

Výhody a nevýhody DBMS

DBMS Klady Proti Postgre Vysoce funkční a bezplatný DBMS s open source, dobrá podpora ze strany vývojářské komunity Někdy nízký výkon při zpracování velkého objemu informací, nízká oblíbenost produktu MS SQL Vysoce funkční, pohodlné při používání prostředí Windows Placené, náročné na správu , není multiplatformní MySQL Free DBMS, open source, zabírá málo místa, snadná správa mysql se sadou všech potřebných funkcionalit, velká komunita vývojářů, funguje na mnoha platformách, nechráněno před ztrátou dat, podporuje pouze malé databáze

Zvažované DBMS tedy mají své výhody a nevýhody, po jejich srovnání bylo rozhodnuto ve prospěch MySQL.

databáze tohoto vzdělávacího elektronického časopisu

6. Vývoj klient-server aplikace pro práci s databází

.1 Technologie klient-server

Jak se vyvíjely představy o distribuovaných výpočetních procesech a procesech zpracování dat, vznikla teorie architektury „klient-server“ - zobecněný koncept interakce dvou složek informačních technologií ve výpočetních systémech a sítích, mezi které lze logicky, resp. fyzicky rozlišené: funkční stránka (jarní požadavky, zákazník); pasivní strana (server, poptávková služba, zdroj odpovědí):

aktivní strana;

pasivní strana.

Interakce klient-server v síti probíhá v souladu se specifickým protokolem.

Koncept klient-server znamená, že kromě ukládání centralizované databáze musí centrální stroj (databázový server) provádět většinu zpracování dat. Požadavek na data vydaný klientem spustí vyhledávání a načítání dat na serveru. Extrahovaná data jsou přenášena po síti ze serveru ke klientovi. Specifickým rysem architektury klient-server je použití dotazovacího jazyka SQL (Structured Query Language).

Databázový dotaz je iniciován klientem, ale spuštěn na serveru. Klientovi je po síti vrácen pouze výsledek. Tento proces se skládá ze šesti kroků:

Klient požaduje data.

Dotaz je přeložen do SQL.

SQL dotaz je přenášen přes síť na server.

Databázový server provede vyhledávání.

Požadované záznamy jsou vráceny klientovi.

Data jsou prezentována uživateli.

Technologie klient-server vytváří výkonné prostředí, které organizacím poskytuje mnoho skutečných výhod. Zejména dobře navržený systém klient-server poskytuje relativně levnou platformu, která má stále výpočetní schopnosti sálového počítače a lze ji snadno přizpůsobit pro provádění specifických úkolů. Kromě toho se během zpracování klient-server výrazně sníží síťový provoz, protože přes síť jsou odesílány pouze výsledky dotazů.

Břemeno operací se soubory dopadá především na serverový počítač, který je mnohem výkonnější než klienti, a proto je schopen lépe obsluhovat požadavky.

Síť klient-server snižuje požadavky na paměť klientských počítačů, protože veškerá práce se soubory probíhá na serveru. Servery v systémech klient-server jsou schopny ukládat velké množství dat. Tím se uvolní značné množství místa na disku na klientských počítačích.

Zálohování dat je také výrazně zjednodušeno.

A konečně, správa celého systému, včetně sledování jeho zabezpečení, je mnohem jednodušší, protože všechny soubory a data jsou centrálně umístěny na serveru nebo na malém počtu serverů.

.2 Programovací nástroje pro vyvíjenou aplikaci

Pro vytvoření aplikace byl hlavním vývojovým nástrojem programovací jazyk python 2.5.

Univerzální programovací jazyk na vysoké úrovni zaměřený na zlepšení produktivity vývojářů a čitelnosti kódu. Syntaxe jádra Pythonu je minimalistická. Standardní knihovna zároveň obsahuje velké množství užitečných funkcí a podporuje několik programovacích paradigmat, včetně strukturálních, objektově orientovaných, funkčních, imperativních a aspektově orientovaných. Hlavními architektonickými vlastnostmi jsou dynamické psaní, automatická správa paměti, úplná introspekce, mechanismus zpracování výjimek, podpora vícevláknových výpočtů a pohodlné datové struktury na vysoké úrovni. Kód v Pythonu je organizován do funkcí a tříd, které lze kombinovat do modulů (ty lze zase kombinovat do balíčků).

Jazyk a jeho interpret vyvíjí skupina nadšenců v rámci projektu s otevřeným zdrojovým kódem. Projekt není zdarma a je šířen pod vlastní licencí.

V oblasti webového programování je python jedním z nejoblíbenějších skriptovacích jazyků (společně s JSP, Perlem a jazyky používanými v ASP.NET) díky své jednoduchosti, rychlosti provádění, bohaté funkčnosti, multiplatformnímu a distribuci zdrojového kódu.

Popularita v oblasti tvorby webových stránek je dána přítomností velké sady vestavěných nástrojů pro vývoj webových aplikací. Ty hlavní:

Automatická extrakce parametrů POST a GET, stejně jako proměnných prostředí webového serveru do předdefinovaných polí;

Souborové funkce úspěšně zpracovávají místní i vzdálené soubory;

Automatické odesílání HTTP hlaviček;

Práce s cookies a relacemi;

Zpracování souborů nahraných na server;

Práce s XForms;

Práce se vzdálenými soubory a sokety.

V současné době python používají vývojáři pro projekty s vysokou zátěží. Podle hodnocení Tiobe, založeného na údajích z vyhledávačů, byl v prosinci 2009 python na 3. místě mezi programovacími jazyky (za Javou a C) a za rok vzrostl o dvě pozice.

V současné době existuje pouze jedna implementace pythonu, žádná společnost třetí strany nepodporuje jiné spustitelné soubory než oficiální sestavení. Tento stav věcí vám na jedné straně umožňuje rychle zavádět a šířit inovace mezi vývojářskou komunitou, na druhé straně vyvíjet programovací jazyk bez standardu, protože jej ve skutečnosti poskytuje jediná implementace. V takových podmínkách nabývá velký význam verze interpretu, která určuje aktuální funkcionalitu (zpětná kompatibilita mezi verzemi interpretu není striktně dodržována).

V roce 1994 vytvořil dánský programátor Rasmus Lerdorf sadu skriptů Perl/CGI pro zobrazení a počítání návštěvníků jeho online životopisu, přičemž zpracovával šablony dokumentů HTML. Lerdorf soubor nazval Personal Home Page. Brzy funkčnost a rychlost Perlu, interpretu skriptů, přestala stačit a Lerdorff vyvinul nový interpret PHP/FI šablon využívající jazyk C.

.3 Softwarová implementace modulu „Učitel“.

Pro práci s automatizovaným informačním systémem „Elektronický žurnál“ musíte zadat URL do adresního řádku vašeho prohlížeče. Po načtení dat se v okně prohlížeče objeví stránka, ze které začíná práce v informačním systému - jedná se o autentizační stránku uživatele v systému (obr. 6.3.1).

Rýže. 6.3.1 – Stránka pro ověření uživatele

Uprostřed obrazovky je formulář pro ověření uživatele, ale pokud uživatel ještě není zaregistrován v systému, níže je odkaz na registrační stránku.

Po úspěšné autentizaci se učitel dostane na stránku pro výběr zobrazení předmětu, který potřebuje, kde může hodnotit, známkovat docházku a upravovat téma hodiny a domácí úkoly (obr. 6.3.2).

Rýže. 6.3.2 - Stránka výběru zobrazení informací

Po celou dobu práce se systémem jsou zobrazovány osobní údaje o učiteli: jméno učitele, dostupné předměty a vedle těchto údajů je umístěn hypertextový odkaz pro odhlášení uživatele ze systému, na aplikaci technické podpory nebo odkaz k němu, stejně jako ke změně hesla.

Po kliknutí na datum může učitel vyplnit téma hodiny a domácí úkol (obr. 6.3.3).

Rýže. 6.3.3 - Stránka aktuálního pokroku studenta

Chcete-li označit, stačí vybrat buňku a dát tam značku nebo „H“, pokud student nebyl ve třídě.

.4 Softwarová implementace modulu „Team Leader“.

Práce se systémem pro vedoucího skupiny také začíná autentizační stránkou (obr. 6.4.1).

Rýže. 6.4.1 - Stránka ověření správce

Po úspěšném ověření je manažer přesměrován na stránku pro výběr požadované akce: Přidat nebo vyloučit studenty, zobrazit známky a docházku vaší skupiny, vytvořit zprávy o sociálních skupinách, zdravotních skupinách a známkách (obr. 6.4.2).

Rýže. 6.4.2 - Stránka zprávy o pokroku

Rýže. 6.4.3 - Stránka pro správu studentů

Manažer může upravovat spojení pro všechny obory vybrané skupiny pouze v případě, že je vedoucím této skupiny. Pokud není vedoucím vybrané skupiny, pak možnost editace spojení bude pouze pro ty obory, které se v této skupině vyučují.

Po provedení změn musí správce kliknout na tlačítko „Uložit“, aby se nová data zapsala do databáze, nebo přejít na jinou stránku a provedené změny zrušit.

Na Obr. Obrázek 6.4.5 ukazuje stránku pro úpravu odkazu.

Rýže. 6.4.5 - Stránka pro úpravu odkazů

6.5 Softwarová implementace modulu „Správce provozovny“.

Práce se systémem začíná podobně jako u předchozích modulů. Po úspěšné autorizaci se administrátorovi instituce zobrazí stránka, na které je nabídka pro výběr akcí: správa předmětů, správa skupin, správa učitelů, práce s rozvrhem, přidělování závěrečných období, přidělování předmětů učitelům, přiřazení vedoucího skupiny .

Rýže. 6.5.1 – Stránka Správa místa

Po výběru požadované položky nabídky se otevře příslušná stránka.

Obrázek 6.5.2 ukazuje řízení skupin vzdělávacích institucí

Vývoj automatizovaného informačního systému Elektronický žurnál

Rýže. 6.5.2 - Stránka pro správu skupiny

Řízení učitele je znázorněno na obrázku 6.5.3. Můžete také přidat roli učitele do dříve vytvořeného účtu nebo importovat ze souboru .csv, parametry importu se zobrazí, když přejdete na příslušnou stránku.

Rýže. 6.5.3 - Stránka pro správu učitelů

Obdobně jako v předchozím odstavci se provádí řízení předmětů vzdělávací instituce. (obr. 6.5.4)

Rýže. 6.5.4 - Stránka pro správu učitelů

Charakteristickým rysem tohoto modulu je práce s rozvrhem. Chcete-li to provést, musíte v položce nabídky vybrat „Rozvrh“, otevře se stránka správy rozvrhu, poté vybrat skupinu a uspořádat předměty podle plánu lekce a také označit místnosti, ve kterých se budou konat. (obr. 6.5.5)

Rýže. 6.5.5 - Stránka pro správu plánu

6.6 Softwarová implementace modulu „Rodič“.

Práce se systémem začíná podobně jako u předchozích modulů. Po úspěšné autorizaci se rodiči zobrazí stránka, na které je nabídka pro výběr akcí: zobrazení rozvrhu, předmětů podle semestru, sledování docházky a pokroku, připojení dítěte, zobrazení informací o skupině, zobrazení učitelů patřících do této skupiny.

Rýže. 6.6.1 - Hlavní stránka modulu „Rodič“.

Chcete-li připojit dítě, musíte následovat příslušný hypertextový odkaz, poté vybrat skupinu a zadat informace o studentovi. Pokud se takový student v databázi najde, bude žádost úspěšně odeslána a budete muset počkat na souhlas školitele. Oznámení o úspěšném schválení nebo zamítnutí bude zasláno na e-mailovou adresu uvedenou při registraci. Chcete-li zobrazit pokrok vašeho dítěte, budete muset vybrat položku nabídky „Předměty“ (obr. 6.6.2).

Chcete-li si obdržené známky zobrazit podrobněji, musíte kliknout na položku a otevřou se podrobné informace o předmětu a odpovídajících termínech. (obr. 6.6.3)

Rýže. 6.6.2 – Zobrazení pokroku vašeho dítěte

Rýže. 6.6.3 – Zobrazení pokroku vašeho dítěte

Je také možné zobrazit rozvrh na celý týden. A aktuální den je zvýrazněn jinou barvou. (obr. 6.6.4)

Studentský softwarový modul má všechny stejné funkce jako rodič, s výjimkou připojení dítěte.

Rýže. 6.6.4 – Zobrazení pokroku vašeho dítěte

.7 Softwarová implementace modulu „Technický správce systému“.

Práce se systémem začíná podobně jako u předchozích modulů. Po úspěšné autorizaci se rodiči zobrazí stránka s nabídkou pro výběr akcí: správa uživatelů a rolí, správa vzdělávacích institucí, přidávání poboček, nastavení parametrů systému, vytváření reportů o vytížení systému.

Tento modul má všechny stejné funkce jako správce instituce pro řízení konkrétní vzdělávací instituce, ale může také přidávat nové. (obr. 6.7.1)

Rýže. 6.7.1 - Řízení vzdělávacích institucí a přidávání poboček

Nastavení parametrů systému zahrnuje vyplnění několika polí, jako je odkaz na aplikaci technické podpory a systém ochrany proti botnetům. Po těchto manipulacích bude systém připraven k použití. (obr. 6.7.2)

Rýže. 6.7.2- Nastavení systému

Rýže. 6.7.3 - Správa uživatelů a rolí

Hlášení o obsazenosti systému se provádí přechodem na příslušnou položku nabídky. Dále vyberte provozovnu, pro kterou chcete zobrazit informace nebo naplnění systému jako celku.

Data jsou v tabulce uvedena v %, pro názornější příklad je nakreslen i koláčový graf (obr. 6.7.4)

Rýže. 6.7.4- Hlášení o naplnění systému

7. Studie proveditelnosti projektu

Organizačně-ekonomická část zkoumá problematiku organizace a plánování výroby webového systému vyvíjeného ve WKR a také studii proveditelnosti pro proveditelnost díla, která zahrnuje posouzení kvality projektu, kalkulaci celkových nákladů a ekonomické posouzení projektu.

Při navrhování a výrobě webových systémů by mělo být věnováno důležité místo otázkám standardizace práce vývojářů. Je to dáno specifickou povahou práce softwarových vývojářů, která zahrnuje velký prvek kreativity v práci, stejně jako obtížnost měření a hodnocení práce v procesu vývoje webového systému.

Při vývoji systému je nutné rozdělit pracovní zdroje tak, aby bylo dosaženo cílů projektu stanovených při projektování ve lhůtách stanovených pro realizaci. Chcete-li to provést, musíte určit mzdové náklady, přidělit výkonné umělce a zdroje tak, aby byl dodržen plán práce.

.1 Účel práce

Vypracování organizačně ekonomické části vývojových prací, sběr výchozích dat, stanovení pracnosti vývoje, kalkulace předpokládané ceny, posouzení kvality vyvíjeného systému.

.2 Stanovení rozsahu práce

Práce na vývoji softwarového produktu lze rozdělit do následujících fází:

Přípravná fáze;

Design;

Programování;

Fáze ladění a testování systému;

Vypracování dokumentace;

Technologie výzkumu a vývoje může být prezentována ve formě seznamů provedených prací v určitém pořadí.

.3 Stanovení pracovní náročnosti vývoje

Náročnost práce se týká množství pracovní doby potřebné k vypracování projektu. Všechny používané metody hodnocení pracovní náročnosti jsou redukovány na tři skupiny: expertní, experimentálně-statistické a analytické.

Náročnost zpracování diplomového projektu je vhodné spočítat metodou odborného posouzení.

K vyřešení problému jsou nastavena následující omezení:

Čas na dokončení úkolu - 4 měsíce.

Počet lidí pracujících na projektu jsou 2 osoby.

Vývojová náročnost práce se vypočítá pomocí vzorce (7.1).

kde t i - pracnost práce ve fázích projektování, - počet fází projektování.

Pomocí vlastních zkušeností a znalostí určíme maximální a minimální čas potřebný k vývoji každé položky a na jejich základě předpokládanou dobu. Očekávaná doba je určena vzorcem (7.2).

(7.2)

Čas strávený v každé fázi vývoje projektu je uveden v tabulce 7.1.

Tabulka 7.1

Čas strávený vývojovými fázemi projektu

Vývojová fáze tmin, osoby Daystmax, osob dnů Předpokládaný čas strávený, lidé. dnů Přípravná fáze 3108 Návrh 153028 Programování 305032 Fáze ladění a testování 5108 Příprava dokumentace 101511 Celkem: 6311578

Práci na dokončení úkolu rozdělíme mezi manažera (návrh, obecný management a práce se zákazníky) a programátora (technický vývoj a dokumentace). Rozdělení objemů práce je uvedeno v tabulce 7.2.

Tabulka 7.2

Rozdělení objemů práce

Etapy vývoje Náročnost práce osoboden Interpreti Podíl účasti, % Časový fond, dny Přípravné 8 Manažer 202 Programátor 806 Design 28 Manažer 5014 Programátor 5014 Programování 32 Programátor 10032 Ladění a testování etapa 8 Manažer 202 Programátor 806 Dokumentace 11 Manažer 7583 Celkem : 87 Celkový objem všech provedených prací je tedy 87 osob. dní

7.4 Výpočet předpokládaných nákladů na modul

Odhadované náklady na vývoj jsou součtem nákladů plánovaných na provedení práce odpovídající sestavenému seznamu. Práce na vývoji softwaru pro vytvoření modulu Účetnictví bude provádět skupina složená z projektového manažera a programátora. Odhad je vypočítán metodou odhadovaných kalkulací pro jednotlivé položky výdajů všech potřebných zdrojů. Odhad obsahuje následující výčet nákladů: materiál, mzdy zaměstnanců, sociální příspěvky, odpisy, režie a ostatní náklady. Spočítejme si všechny nákladové položky.

Stanovení materiálových nákladů

Materiálové náklady jsou stanoveny na základě kalkulací jejich spotřeby v průběhu vývoje. Náklady na dopravu a pořízení jsou akceptovány ve výši 10 % z ceny materiálu. Kalkulace materiálových nákladů jsou uvedeny v tabulce 7.3.

Tabulka 7.3

Kalkulace materiálových nákladů

Materiálové jednotky míry Množství Cena, rub. Papír A4 Pack 11701702. Plnicí pero ks 115153. Barva tiskárny ks 1350350 Celkem: 535

Příprava mezd

Náklady na základní mzdy pro zaměstnance jsou stanoveny na základě doby jejich práce a mzdových sazeb (7.3).

Plat = (7.3)

Kde je D r.měsíc . - průměrný počet pracovních dnů v měsíci = 22;

T pí - pracnost vykonávané práce;

Zp - průměrná měsíční mzda.

Pro manažera:

Plat = = 9090,81 rub.;

Pro programátora:

Plat = = 18272,73 rub.

Náklady na doplatky, příplatky, prémie činí 80 % mzdy (7.4).

Plat nadb = 0,8 Plat (7,4)

Pro manažera:

Plat nadb = = 7272,73 rub.;

Pro programátora:

Plat nadb = = 14618,18 rub.

Základní mzda se stanoví jako součet měsíční mzdy se zohledněním krajského koeficientu a nákladů na doplatky, příplatky a odměny (7.5).

Plat základní = (Plat + Plat nadb ) 1,15 (7.5)

Výsledky výpočtu jsou uvedeny v tabulce 7.4.

Tabulka 7.4

Výpočet základní mzdy

Personální kategorie Počet, osob Náročnost práce, osoba/den Plat, rub základní , třít. Projektový manažer1201000016363.64Programátor167600032890.91Celkem:28749254.55

Výpočet příspěvků na sociální potřeby

Příspěvky na sociální potřeby činí 30,2 % z celkového mzdového fondu (12,6). z nich:

% - do penzijního fondu;

1 % - na zdravotní pojištění;

9 % - na sociální pojištění;

2 % - na havarijní pojištění.

Z sociální =0,302 Plat základní (7.6)

Z sociální = 0,302 49254,55 = 14874,87 rublů.

Výpočet kapitálových investic

K výrobě jakéhokoli softwarového produktu je zapotřebí hardware a nástroje. Pro hardware si vezměme 1 pracovní stanici a 1 tiskárnu. Systém je vyvíjen pomocí webových vývojářských nástrojů: distribuce Apache XAMPP, program NotePad++, program Composer, prohlížeč Google Chrome.

Výpočet kapitálových investic Kv do zařízení a softwaru se provádí podle vzorce (7.7).

NA PROTI = K A + K Podle (7.7)

Kde K A - náklady na hardware;

NA Podle - náklady na software.

Tabulka 7.5 ukazuje výpočet kapitálových investic do hardwaru a nástrojů nezbytných pro vývoj softwarového projektu.

Tabulka 7.5

Kapitálové investice

MnožstvíCena za jednotku, rub.Náklady, rub.Hardware:Pracovní stanice (laptop)1 ks.1800018000Tiskárna1ks.25002500K A = 24000Software: Distribuce Apache XAMPP000NotePad++000Program pro skladatele000Prohlížeč Google Chrome000K Podle = 0Celkem:20500

Veškerý použitý software je tedy zdarma

NA PROTI = K A = 20 500 rublů.

Náklady na odpisy

Výše odpisů zařízení a softwaru je určena vzorcem (7.8).

Z A = (7.8)

kde K V - náklady na hardware a software,

t R - provozní doba (87 dní),

T R - počet dní v roce (365 dní),

N A - sazba srážek za odpisy.

Pro výpočetní techniku ​​a kancelářskou techniku ​​je roční odpisová sazba stanovena na 12 %, takže výše odpisů za rok bude:

Z A = = 586,36 rub.

Kalkulace režijních nákladů

Podle článku Režijní náklady zahrnují náklady, které nelze přímo zahrnout do nákladů projektu – náklady na údržbu zaměstnanců, kteří se nepodílejí na výrobě softwarových produktů, dále náklady na pronájem prostor, inženýrských sítí atd. Režijní náklady tvoří 30 % celkových mezd (12,9).

Z n = 0,3 Plat základní (7.9)

Z n = 0,3 49254,55 = 14776,36 rublů.

Kalkulace nákladů na ostatní výdaje

Článek jiné výdaje zahrnuje všechny ostatní náklady spojené s realizací projektu, které lze přímo přiřadit k nákladům projektu, ale pro které není v kalkulaci uvedena samostatná položka.

Náklady na ostatní výdaje jsou 3 % z částky všech předchozích výdajů (12.10).

Z atd. = 0,03(3 m + plat základní + Z sociální + Z A + Z n ) (7.10)

Z atd. = 0,03(535 + 49254,55+ 14874,87 + 586,36 + 14776,36) =

1954,57 rub.

8. Odhadovaná kalkulace

Odhadovaná kalkulace představuje plánované náklady na výrobu softwarového produktu a je sestavena na celý rozsah práce. Odhadované náklady na uvažovaný projekt jsou uvedeny v tabulce 7.6.

Tabulka 7.6

Kalkulace odhadovaných nákladů na tvorbu softwaru, účtování zdrojů v podniku

Nákladová položka Celkové náklady projektu, rub. Materiál 535 Mzdy 49 254,55 Sociální odvody 14 874,87 Náklady na odpisy 586,36 Režie 14 776,36 Ostatní náklady 1 954,57 Celkem 81 981,71

Odhadovaná cena produktu tedy bude 81 981,71 rublů.

7.5 Posouzení kvality systému evidence pracovní zátěže učitele

Hodnocení kvality vyvinutého modulu bylo provedeno společně s ředitelem diplomového projektu.

Ke zjištění kvality systému jsme použili metodu komplexních ukazatelů (charakteristiky), která spočívá v aplikaci konkrétního dokumentovaného hodnotícího kritéria na konkrétní softwarový modul, balík nebo produkt.

Kritérium hodnocení kvality softwaru je soubor definovaných a zdokumentovaných pravidel a podmínek, které se používají k rozhodnutí, zda je celková kvalita konkrétního softwarového produktu přijatelná. Kvalita je reprezentována souborem zavedených úrovní spojených se softwarovým produktem.

Jako metoda hodnocení byla použita metoda přidělování bodů za každou charakteristiku, načež bylo možné kvalitu vyvíjeného softwarového produktu posuzovat podle průměrného skóre. Pro určení úrovně žebříčku jsme použili 10bodový systém. To vše definuje GOST R ISO/IEC 9126-93 "Informační technologie. Hodnocení softwarového produktu. Charakteristiky kvality a pokyny pro jejich použití."

Tento webový systém jako software lze hodnotit podle následujících charakteristik:

Funkčnost

K hodnocení funkčnosti se používají následující parametry:

Vhodnost je softwarový atribut udávající dostupnost a vhodnost sady funkcí pro konkrétní úkoly. Vyvinutý systém splňuje požadavky, které byly stanoveny v technických specifikacích diplomového projektu. Hodnocení vhodnosti projektu - 10 bodů.

Správnost je atribut softwaru indikující, že výsledky nebo efekty jsou správně sladěny. Výsledky při spuštění programu nejsou o nic méně spolehlivé, než kdyby byla práce provedena předchozím způsobem. Správnost - 10 bodů.

Konzistence je atribut softwaru, který způsobuje, že program dodržuje příslušné normy nebo konvence, předpisy, zákony nebo podobné pokyny. Celkový vzhled a rozhraní odpovídají přijatým programovým standardům pro Windows. Konzistence - 10 bodů.

Zabezpečení je atribut softwaru související s jeho schopností zabránit neoprávněnému přístupu, náhodnému nebo úmyslnému, k programu a datům. Projekt zajišťuje ochranu dat používaných v programu před neoprávněným přístupem, bezpečnost budeme hodnotit 9 body.

Interoperabilita je atribut softwaru, který odkazuje na jeho schopnost interagovat s konkrétními systémy. Schopnost interakce - 5 bodů.

Spolehlivost

Zhodnoťme spolehlivost programu pomocí následujících kritérií.

Stabilita je softwarový atribut, který odkazuje na poruchovost chyb v softwaru. Během testování programu nebyly zjištěny žádné poruchy nebo chyby způsobené chybami ve vývoji systému, což umožňuje konstatovat, že software je stabilní. Stabilita - 6 bodů.

Tolerance chyb je atribut softwaru, který odkazuje na jeho schopnost udržovat určitou úroveň kvality provozu v případě chyb softwaru nebo narušení specifického rozhraní. Program zajišťuje kontrolu zadávaných informací. Hodnocení odolnosti proti chybám - 6.

Obnovitelnost je atribut softwaru, který se týká jeho schopnosti obnovit úroveň výkonu a obnovit data přímo poškozená v případě selhání, stejně jako čas a úsilí potřebné k tomu. Hodnocení obnovitelnosti - 10.

Praktičnost

Zhodnoťme praktičnost programu pomocí následujících kritérií.

Srozumitelnost je softwarový atribut, který odkazuje na snahu uživatele porozumět obecnému logickému konceptu a jeho použitelnosti. Bodové hodnocení srozumitelnosti – 10 bodů.

Naučitelnost je atribut softwaru, který souvisí se snahou uživatele naučit se jej používat – 8 bodů.

Snadné použití je softwarový atribut, který souvisí s úsilím uživatele při provozu a provozním řízení. Hodnocení snadného použití: 10 bodů.

Účinnost

K hodnocení účinnosti se používají následující parametry:

Časové chování je softwarový atribut, který souvisí s dobou odezvy a rychlostí, s jakou jsou její funkce vykonávány. Doba přípravy a výstupu informací, stejně jako doba zpracování vstupních dat, závisí na výpočetním výkonu serveru a osobního počítače klienta. Skóre – 8 bodů.

Vzor změny zdrojů je softwarový atribut, který se vztahuje k množství použitých zdrojů a době trvání takového použití při provádění funkcí. Posouzení charakteru změn zdrojů - 9 bodů.

Udržitelnost

Zhodnoťme udržovatelnost programu pomocí následujících kritérií.

Změnitelnost je softwarový atribut, který se týká úsilí potřebného k úpravě, opravě selhání nebo změně provozních podmínek. Chcete-li změnit program, musíte upravit zdrojové kódy. Skóre proměnlivosti – 8 bodů.

Robustnost je softwarový atribut, který odkazuje na riziko neočekávaných efektů modifikace. Program poskytuje kontrolu nad změnami, které uživatel provádí při práci. Stabilita - 9 bodů.

Analyzovatelnost je atribut softwaru, který se týká úsilí potřebného k diagnostice nedostatků nebo selhání nebo identifikaci komponent pro upgrade. Analyzovatelnost - 8 bodů.

Testovatelnost je atribut softwaru, který odkazuje na úsilí potřebné k testování upraveného softwaru. Testovatelnost - 10 bodů

Mobilita

Mobilitu vyhodnotíme pomocí následujících ukazatelů.

Adaptabilita je vlastnost softwaru, která souvisí se snadností jeho přizpůsobení různým specifickým provozním podmínkám bez použití jiných akcí nebo metod, než které jsou v daném softwaru k tomuto účelu určeny. Skóre adaptability – 9.

Snadnost implementace je atribut softwaru, který odkazuje na úsilí potřebné k implementaci softwaru v konkrétním prostředí. Softwarový balík je integrován do fungujícího systému, takže skóre za snadnost implementace je 7 bodů.

Zaměnitelnost je atribut softwaru, který souvisí se snadností a složitostí jeho použití namísto jiného specifického softwarového nástroje v prostředí tohoto nástroje. Přechod na používání vyvíjeného produktu místo dříve používaných programů není obtížný. Skóre – 10 bodů.

Soulad je softwarový atribut, který způsobuje, že systém vyhovuje standardům nebo konvencím souvisejícím s mobilitou. Systém používá standardní jazyky a řídí se konvencemi nadřazeného projektu. Splnění – 10 bodů.

Výsledky odborného posouzení jsou uvedeny v tabulce 7.7.

Tabulka 7.7

Hodnocení kvality softwaru

AtributSkóre Vhodnost10Správnost10Konzistence10Zabezpečení9Interoperabilita8Stabilita7Odolnost proti chybám5Obnovitelnost10Pochopitelnost10Učitelnost8Snadnost použití10Vzorec změny v čase9Vzor změny zdrojů8Variabilita7Odolnost8Nejlepší přizpůsbitelnost1Analyzovatelnost9TSchopnost skóre 8,9

ZÁVĚR

V našem diplomovém projektu jsme vybudovali model informačního systému „Elektronický žurnál“ a vyvinuli webovou aplikaci pro automatizaci procesu vedení žurnálu akademických výkonů a docházky.

V průběhu naší práce jsme analyzovali současný stav problematiky automatizace činnosti vzdělávacích institucí. Byla studována předmětná oblast automatizace a byla vyvinuta struktura systému.

Při vývoji informační podpory systému byla analyzována skladba a struktura informací, stanoveny funkční závislosti detailů a identifikovány informační objekty. Byly vytvořeny funkční, logické a fyzické modely systému.

Databáze je implementována v MySQL DBMS. Pro vývoj softwaru byl použit programovací jazyk Python a webový framework Django.

V ekonomické části diplomového projektu byly vyčísleny náklady na vyvinutý automatizovaný informační systém.

Vyvinutý informační systém je ve zkušebním provozu ve vzdělávacím oddělení Vologda Institute of Business.

SEZNAM POUŽITÝCH ZDROJŮ

1.Koterov D.V. Python 5 v originále - 2. vydání. / D.V. Koterov, A.F. Kostarev. - Petrohrad: BHV-Petersburg, 2011. - 1104 s.

2.Gagarina L.G. Vývoj a provoz automatizovaných informačních systémů / L.G. Gagarin, D.V. Kiselev, E.L. Fedotová; Ed. L.G. Gagarin. - M. : FORUM: INFRA-M, 2013. - 384 s.

3.Welling L. Vývoj webových aplikací pomocí PHP a MySQL - 3. vydání. / L. Welling, L. Thomson; upravil Yu.N. Artemenko; pruh z angličtiny - M.: Williams Publishing House, 2010. - 880 s.

4.Společnost MySQL AB. MySQL. Referenční kniha o jazyce / editoval Yu.N. Artemenko; pruh z angličtiny - M.: Williams Publishing House, 2005. - 432 s.

5.Emelyanova N.Z. Základy budování automatizovaných informačních systémů: učebnice. příspěvek / N.Z. Emeljanová, T.L. Partyka, I.I. Popov. - M.: FORUM: INFRA-M, 2005. - 416 s.

6.Digo S.M. Databáze: design a použití / S. Digo. - M.: Finance a statistika, 2005. - 592 s.

.Golitsyna O.L. Základy algoritmizace a programování/O.L. Golitsyna, I.I. Popov. - M.: FORUM: INFRA-M, 2005. - 432 s.

.Gvozdeva V.A. Úvod do specializace programátora / V.A. Gvozdeva. - M.: FORUM: INFRA-M, 2005. - 208 s.

9.Schlossnagle D. Profesionální programování v Pythonu / D. Schlossnagle; pruh z angličtiny - M.: Williams Publishing House, 2009 - 624 s.

10.Tanenbaum E.M. van Steena. Distribuované systémy. Principy a paradigmata / E.M. van Steena. Tanenbaum; pruh z angličtiny - M.: Nakladatelství "Peter", 2013. - 877 s.

11.Popova O.G. Pokyny pro absolvování diplomového projektu pro studenty prezenčního studia oboru 230103 „Automatizované systémy zpracování informací a řízení“ / O.G. Popová, A.A. Drozdová. - Vologda: VKT, 2008. - 28 s.

12.Skakun K.K. Směrnice pro realizaci ekonomické části diplomového projektu pro studenty oboru 230103-51 „Automatizované systémy zpracování a řízení informací“ / K.K. Kůň. - Vologda: NOU SPO VKT, 2007 - 36 s.

13.GOST R ISO/IEC 12207-99 Informační technologie. Procesy životního cyklu softwaru / Úvod. 07/01/2000

14.GOST 19.102-77 Jednotný systém programové dokumentace. Vývojové fáze.

15.GOST 19.105-78 Jednotný systém programové dokumentace. Obecné požadavky na programové dokumenty.

PŘÍLOHA A

Výsledky střednědobé kontroly

PŘÍLOHA B

Tréninkový deník

PŘÍLOHA B

Prezenční listina

PŘÍLOHA D

Stanovení funkčních závislostí

DocumentName of the requiredName of required Funkční závislostSeznam studentůČíslo kreditu. knihy Jméno studenta Číslo skupiny Heslon_zbook jméno_student n_skupina heslo Seznam učitelůČíslo učitele Celé jméno učitele Uživatelské jméno Heslon_jméno učitele_přihlašovací heslo učitele Seznam odbornostíPočet odbornosti Název. obory Doba studia Zkratka_specialita název_specialita termín_studium zkratka Seznam skupin Číslo skupiny Číslo odbornosti Název skupiny Třídní učitel_skupina n_specialita jméno_skupina n_učitel Seznam oborů Číslo disciplíny Číslo skupiny Název disciplíny Číslo učitele Semestrální zahájení školení. Konec semestru n_disciplína n_název skupiny_disciplína n_teacher sem_start sem_end Milník výkonu. knihy Číslo disciplíny Měsíc Stupeň n_zbook n_kázeň po zn Průběh semestru. knihy Číslo disciplíny Semestr Markn_zbook n_disciplína n_sem zn Milník docházky. knihy Měsíc bez uv. důvody Totaln_zbook mon no_reazon celkem PŘÍLOHA E

Ekonomická část

Chanty-Mansijský autonomní okruh - Ugra

METODICKÉ POKYNY

o registraci a ochraně promoce

kvalifikační práce

pro specialitu

230401 Informační systémy (podle odvětví)

hloubkové školení

Chanty-Mansijsk

2018

Vývojářská organizace:

AU "Khanty-Mansijsk

Vývojáři:

Zhelonkina M.V., učitelka Chanty-Mansijské autonomní instituce

Vysoká škola technická a pedagogická"

Koksharov S.V., učitel Chanty-Mansijské autonomní instituce

Vysoká škola technická a pedagogická"

Yarygina S.N., učitelka Chanty-Mansijské autonomní instituce

Vysoká škola technická a pedagogická"

Obsah

ÚVOD

V souladu s federálním státním vzdělávacím standardem pro specializaci 230401 Informační systémy (podle odvětví), odpovídajícím učebním plánem pro přípravu specialisty v této specializaci, studenti dokončí a obhájí závěrečnou kvalifikační práci (tezi), která je povinnou formou státní závěrečné certifikace. absolventů.

Na základě výsledků závěrečné certifikace absolventů Státní certifikační komise (SAC) rozhodne o udělení kvalifikace „Specialista informačních systémů“ v oboru 230401 Informační systémy (podle odvětví) ao vydání diplomu o středním odborném vzdělání.

Závěrečná kvalifikační práce je hotový výzkumný nebo vypracovaný projekt na zadané téma, zpracovaný pod vedením vyučujícího (vedoucího práce).

Tyto směrnice jsou zpracovány s přihlédnutím k požadavkům na práci jsou zde diskutovány obecné otázky realizace diplomové práce (formulovány požadavky a jsou uvedeny pokyny k jejímu objemu, struktuře, obsahu, k organizaci práce studenta v kursu; proces psaní práce) a odráží také postup přípravy a obhajoby kvalifikační práce.

Hlavním cílem směrnic je zvýšení úrovně organizace a kvality závěrečné fáze procesu profesní přípravy specialistů a zvýšení poptávky a konkurenceschopnosti absolventů vysokých škol na trhu práce z důvodu jejich lepší teoretické i praktické přípravy.

Pokyny jsou určeny pro studenty studující v oboru 230401 Informační systémy (podle odvětví) a také pro vedoucí absolventské práce. Lze je využít jak v procesu přímého psaní práce, tak při shromažďování, systematizaci a sumarizaci podkladů k diplomové práci.

1. CÍLE A CÍLE ABSOLVENTSKÉ PRÁCE

Závěrečná kvalifikační práce je samostatná práce studenta, jejímž hlavním cílem a obsahem je návrh informačního systému nebo jeho subsystému, vývoj technologických postupů pro zpracování informací a řešení organizačních otázek řízení výroby; určuje vědeckou erudici a hloubku praktických znalostí, které student získal za celou dobu studia na vysoké škole.

Účelem obhajoby kvalifikace absolventské práce je zjistit úroveň připravenosti absolventa k plnění odborných úkolů a soulad jeho přípravy s požadavky federálního státního vzdělávacího standardu, a to i z hlediska utváření obecných kompetencí.

WRC je navrženo tak, aby:

Přispívat k systematizaci a upevňování znalostí studentů v jejich oboru při řešení konkrétních odborných problémů;

Prokázat úroveň připravenosti absolventa na samostatnou práci;

Poskytnout komplexní posouzení připravenosti absolventa vykonávat druhy prací s využitím osvojených obecných a odborných kompetencí.

VKR úzce souvisí s pregraduální praxí. Na základě studia obecných teoretických a speciálních oborů, jakož i na základě konkrétních materiálů shromážděných v místě průmyslové a předdiplomové stáže, provádí postgraduální student analýzu a na základě získaných výsledků vyvíjí software informačního systému v souladu s tématem VKR.

Při zakládání a řešení v VKR konkrétní praktické úkoly, které student musí:

Uplatňovat teoretické principy humanitních, socioekonomických, přírodních věd, obecně odborných a speciálních disciplín;

Používat moderní metody statistické, sociologické, ekonomické, logické, psychologické a právní analýzy činností, elektronickou výpočetní techniku;

Používat racionální metody vyhledávání, výběru, zpracování a systematizace informací, práci s odbornou literaturou a právními akty;

Aplikovat pokrokové poznatky domácí i zahraniční vědy a praxe a zdůvodnit ekonomickou proveditelnost jejich využití.

Proces psaní WRC zahrnuje řešení následujících úkolů:

Zdůvodnit relevanci zvoleného tématu, jeho hodnotu, spojit to s místem pregraduální praxe;

Studovat teoretické principy, normativní a technickou dokumentaci, statistické materiály, referenční a vědeckou literaturu na zvolené téma;

Shromáždit nezbytný statistický materiál k provedení specifické analýzy;

Vyjádřete svůj názor na kontroverzní otázky související s tématem;

Analyzovat shromážděná data pomocí vhodných metod zpracování a analýzy informací;

Vyvodit závěry a na základě analýzy vyvinout softwarový produkt;

Požádejte o VKR v souladu s požadavky na takové materiály;

Dokončete všechny postupy předběžné ochrany a úspěšně chraňte VKR. VKR po jeho úspěšné obhajobě slouží jako podklad pro přiřazení autorovi odpovídající specializace nebo kvalifikace.

2. VÝBĚR TÉMATU ABSOLVENTSKÉ PRÁCE A JEJÍ SCHVÁLENÍ

Diplomová práce o PPSSZ je hotovým dokumentovaným produktem studentovy výzkumné nebo projektové činnosti.

Výzkumné a vývojové práce lze realizovat na žádost (přihlášku, objednávku) podniků a institucí v souladu s profilem zvládnutého OBOP.

Téma práce musí odpovídat obsahu jednoho nebo více odborných modulů a obsahovat prvky inovativního vyhledávání. Formulace tématu práce by měla odrážet aplikovaný charakter, povahu budoucích aktivit specialisty. Na jednání oborové komise učitelů informatiky a ICT bylo rozhodnuto, že absolventi oboru 230401 „Informační systémy (podle odvětví) budou vykonávat výzkumnou a vývojovou práci projektového typu, která zahrnuje analýzu konkrétní oblasti ( oblast) odborné činnosti a realizace návrhů projektů v činnosti podniků (institucí) .

Tématem výzkumné a vývojové práce může být vývoj informačního systému (subsystému) nebo automatizace účetních služeb, které poskytují řešení jednoho nebo více problémů v příslušné oblasti s využitím moderních počítačů a telekomunikací, jakož i moderních informací. technologií.

Přibližná témata diplomových prací zpracovává oborová komise (SCC) „Informatika“ a doporučuje je studentům.

Absolventi mají také právo volby tématu diplomové práce včetně návrhů vlastního tématu s nezbytným zdůvodněním proveditelnosti jeho zpracování pro praktickou aplikaci.

a) téma zohledňuje profil školení specialisty;

b) odpovídá znalostem, dovednostem a praktickým dovednostem absolventů;

c) zahrnuje hlavní oblasti, se kterými se bude muset absolvent, jakožto uznávaný specialista v oblasti výstavby a údržby informačních systémů, ve své odborné činnosti vypořádat;

d) téma je sestaveno s přihlédnutím k relevanci a poptávce v praxi dané vzdělávací instituce nebo ve vědě či samotnému interpretovi nebo je blízké tématu organizace, ve které student absolvuje předabsolvování praxe.

e) téma je vybráno s ohledem na čas vyhrazený pro jeho výzkum.

Přibližná témata WRC:

Automatizace účetnictví klientů cestovní kanceláře

Automatizace účetnictví pro HR oddělení malého podniku

Vývoj informačního systému pro evidenci práce s klienty;

Vývoj informačního systému pro webové studio.

Výčet témat navržených oborovou komisí učitelů informatiky a ICT do pozornosti studentů není vyčerpávající. Každý student může deklarovat téma dle vlastního uvážení s náležitým zdůvodněním potřeby a proveditelnosti jeho rozvoje.

Je vhodné, aby se zvolené téma diplomové práce stalo logickým rozvíjením ročníkové práce (projektů), které student již dříve absolvoval, a zahrnovalo využití informací shromážděných během praktické výuky.

Téma práce je individuální a nemůže být opakováno jinými studenty.

Vedoucím VKR může být:

a) specialista oborové komise učitelů informatiky a ICT;

b) pracovník organizace, kde bude absolvent absolvovat předdiplomovou praxi nebo na jejichž podkladech budou výzkumné a vývojové práce prováděny.

Školitele vybírá absolvent samostatně na základě osobních sympatií a dohody, řídí se schváleným seznamem doporučených školitelů absolventské práce v této specializaci pro aktuální období. Pokud si absolvent z nějakého důvodu nezvolí školitele, je tento jmenován předsedou oborové komise učitelů informatiky a ICT.

Témata diplomových prací a jména vedoucích schvaluje příkaz ředitele školy nejpozději dva týdny před zahájením pregraduální praxe. Změna tématu práce nebo výměna vedoucího z podnětu studenta není povolena.

3. STRUKTURA A OBJEM SCR. OBECNÉ POŽADAVKY NA NÁVRH

Struktura designového typu WRC se skládá z vysvětlivky a konstrukčních materiálů.

Struktura a obsah vysvětlivky jsou stanoveny s přihlédnutím k profilu oboru a tématu diplomové práce.

Vysvětlivka obsahuje následující oddíly:

Titulní strana (Příloha 1);

Zadání k závěrečné zkoušce (Příloha 2);

Úvod;

Teoretická část;

Praktická část;

Závěr

Seznam použitých zdrojů;

Aplikace

Prezentace k obhajobě

Zpětná vazba od manažera

Externí recenze

Struktura textové části Návrh musí být jasný a stručný a zároveň obsahovat všechny potřebné podklady. Výzkumná a vývojová práce musí být nezávislá, tzn. obsahují autorovy myšlenky, podané dobrým literárním jazykem. V průběhu prezentace je třeba se vyvarovat rozporů a kategorických výroků.

Nejsou povoleny dlouhé argumenty, opakování známých důkazů, rozsáhlé výňatky z učebnic, odborné literatury a jiných zdrojů. Citace a materiály převzaté z jiných zdrojů musí obsahovat odkazy s uvedením autora, názvu citovaného zdroje, roku vydání a stránky.

Všechny výpočty provedené při vývoji výzkumných a vývojových prací jsou uvedeny v textu s příslušným zdůvodněním a vysvětlením s uvedením významu a rozměru veličin obsažených ve vzorcích. Výsledky výpočtu jsou obvykle prezentovány ve formě tabulek. Text hlavní části by měl obsahovat závěrečné a nejdůležitější materiály. Původní výpočty musí být uvedeny v plném rozsahu a pro homogenní standardní výpočty se můžete omezit na tabulku konečných dat. Tabulky obsahující primární zdrojová data a konstantní podobné výpočty s jinými zdrojovými daty by měly být umístěny za seznamem literatury ve formě příloh s povinným odkazem na ně v textu.

Ilustrační materiál je umístěn podél textu bezprostředně za odkazem na něj, nebo na samostatných přílohách v souladu s pořadovým číslováním. Text musí obsahovat odkazy a vysvětlení k poskytnutému ilustračnímu materiálu.

V textu by se neměla používat zkrácená slova, kromě obecně uznávaných.

Sekce „Úvod“ obsahuje relevanci výběru tématu, účel a cíle projektu, právní rámec projektu a fáze projektu.

Část „Teoretická část“ obsahuje následující konstrukční prvky: technicko-ekonomickou charakteristiku předmětné oblasti; popis problému a navrhovaná řešení; analýza alternativních řešení; model vyvinutého systému; seznam systémových požadavků; vlastnosti softwarových a hardwarových vývojových nástrojů.

Část „Praktická část“ obsahuje následující konstrukční prvky: výsledky koncepčního, logického a fyzického návrhu databáze; aplikační algoritmus; uživatelská příručka; popis prostředků a metod ochrany a bezpečnosti dat.

Seznam použitých zdrojů musí obsahovat informace o zdrojích, na které se odkazuje v textu WRC. Informace o zdrojích jsou poskytovány v souladu s GOST 7.1-2003 „Bibliografický záznam. Bibliografický popis“. Seznam musí obsahovat minimálně 25 zdrojů včetně elektronických zdrojů.

V přílohách jsou uvedeny všechny materiály pomocného nebo doplňkového charakteru, které nejsou zásadní pro pochopení řešení problematiky diplomové práce.

Objem práce na projektu typu PPSSZ je minimálně 30 a maximálně 50 tištěných listů, nepočítaje v to objem části „Přílohy“.

Při přípravě textu dokumentu v textovém editoru MS Word se doporučuje nastavit následující nastavení:

Nastavení stránky:

Velikost papíru: A4 (210x297 mm);

Orientace - na výšku (pro hlavní test);

Okraje: horní a spodní - 2,0 cm, levý - 3,0 cm, pravý - 1,5 cm;

Možnosti písmo:

Písmo - Times New Roman;

Styl - pravidelný;

Velikost-14 bodů;

Možnosti odstavce:

Zarovnání - Šířka;

Odsazení vlevo a vpravo - 0 cm (tj. chybí);

První řádek (červený řádek) - 1,25 cm,

Mezery před a za odstavcem - 0 bodů (tj. chybí);

Řádkování - Jeden a půl (u stolů - jednoduché).

Stránky textu jsou číslovány arabskými číslicemi uprostřed spodní části listu, přičemž je třeba dodržet průběžné číslování v celém textu. Titulní strana je zahrnuta do celkového číslování stran textu. Na titulní straně není uvedeno číslo stránky.

Ilustrace a tabulky umístěné na samostatných listech jsou součástí celkového číslování stran.

Oddíly, pododdíly, odstavce, pododstavce textu jsou číslovány arabskými číslicemi s tečkou.

Například: 1, 1.1., 1.1.1. atd.

Úvod, hlavní části, závěr, seznam odkazů a přílohy by měly začínat na nové stránce a měly by mít nadpis, tištěný velkými písmeny, umístěný uprostřed řádku bez tečky na konci. Pododdíly, odstavce a pododstavce jsou seřazeny za sebou a jsou vytištěny malými písmeny.

Nadpisy strukturních prvků textu by měly být umístěny na střed řádku, bez tečky na konci, bez podtržení. Dělení slov v nadpisech není povoleno.

Nadpisy oddílů, pododdílů, článků a článků dokumentu jsou obvykle odděleny jedním řádkem od sebe navzájem a od hlavního textu. Pokud nadpis zabírá dva řádky, použije se mezi řádky nadpisu jednořádkové řádkování. Pokud se název skládá ze dvou vět, jsou odděleny tečkou.

Například: "... v části 1 jsme uvažovali...", "... podle 1.1", "... v souladu s tabulkou 1", (tabulka 1), "... na obrázku 1", (obr. 1 ), "... v seznamu (1)", "... v příloze A", (příloha A) atd.,

Pokud text obsahuje pouze jednu ilustraci, jednu tabulku, jednu přílohu, pak by měl odkaz uvádět „... na obrázku“, „... v tabulce“, „... ve výčtu“, „... v příloze“.

Odkazy na konkrétní část dokumentu se od předchozích liší povinným uvedením stránek zvažovaného nebo citovaného dokumentu. Odkazy na fragment dokumentu by měly být uvedeny v závorce ve formě pořadového čísla dokumentu podle seznamu odkazů, od něj oddělené čárkou, pořadové číslo stránky obsahující tento fragment, před kterým je uvedeno písmeno „c“ s tečkou.

Například: .

Pokud se fragment ve zdroji nachází na několika stránkách, jsou jejich čísla zapsána pomlčkou.

Například: .

3.1. Design titulní strany

Titulní strana je první strana dokumentu.

Titulní strana obsahuje následující informace:

název mateřské organizace (instituce, které je vzdělávací instituce podřízena);

název instituce;

název speciality;

název tématu práce;

informace o manažerovi;

informace o interpretovi (studentovi);

schválení regulačním inspektorem;

známka o přijetí k obhajobě;

rok napsání práce.

Příklad návrhu titulní stránky je uveden v příloze 1.

3.2. Zadání pro VKR

Zadání práce se vypisuje na standardním formuláři (Příloha 2) a umísťuje se za titulní stranu. Úkol není součástí číslování listů pracovních listů. Zadání je vypracováno a zadáno studentovi individuálně, v souladu s tématem práce.

Zadání absolventské práce je absolventovi vystaveno nejpozději 2 týdny před zahájením výrobní (předabsolvenční) praxe - poslední rok studia. Zadání diplomové práce se může shodovat s individuálním zadáním pro pregraduální praxi.

3.3. Obsah

V obsahu všechny nadpisy oddílů, pododdílů a příloh jsou uvedeny postupně s uvedením čísel stránek, na kterých jsou umístěny . Nadpisy obsahu by se měly přesně shodovat s nadpisy v textu. Názvy jednotlivých kapitol musí být v souladu s tématem práce a názvy odstavců musí být v souladu s názvy odpovídajících kapitol (avšak neshodovat se s nimi).

3.4. Úvod

Úvod – úvodní část WRC, ve které je nutné:

Zdůvodněte relevanci rozvíjeného tématu, jeho teoretický a praktický význam;

Určete hranice studia (objekt, předmět výzkumu)

Uveďte hlavní cíl a cíle práce;

Definujte teoretické základy a označte zvolenou výzkumnou metodu (nebo metody);

Popište očekávané výsledky a rozsah aplikace vyvinutého programového vybavení informačního systému.

Úvod by měl začít zdůvodněním relevance zvoleného tématu WRC. Pokrytí relevance by mělo být lakonické.

Povinným prvkem úvodu je formulace předmětu a předmětu studia. Objekt a předmět zkoumání jako kategorie vědeckého procesu spolu souvisí jako obecné a partikulární.

Předmět studia - je to proces nebo jev, který generuje problematickou situaci a je vybrán ke studiu, nositel uvažovaného problému.

Předmět studia - to je to, co je v mezích zvoleného předmětu studia. Jedná se o předmět, který zahrnuje ty aspekty a vlastnosti objektu, které nejúplněji vyjadřují zkoumaný problém (rozpory v něm skryté) a jsou předmětem studia.

Právě na předmět výzkumu je zaměřena hlavní pozornost absolventa, je to předmět, který určuje téma práce, které je uvedeno na titulní straně jako název.

cílová – ideální znázornění konečného výsledku, čeho je třeba nakonec dosáhnout.

Formulace cíle musí být v souladu s názvem práce.

K dosažení tohoto cíle, řada úkoly (asi 2-3). To se obvykle provádí ve formě výčtu s použitím řady standardních počátečních slov: studovat..., objasnit..., popsat..., zvážit..., stanovit..., identifikovat..., formulovat ..., konstruovat..., vyvíjet..., navrhovat... atd.

Seznam přidělených úkolů musí být v souladu s obsahem a strukturou WRC. Formulace problémů musí být provedena co nejpečlivěji, protože popis jejich řešení by měl tvořit obsah kapitol WRC.

Povinný prvek úvodu VKR je naznačení výzkumných metod, které slouží jako nástroj při získávání faktografického materiálu, jsou nezbytnou podmínkou pro dosažení cíle stanoveného v práci.

Objem podání by měl být2-3 stránky .

Je třeba připomenout, že podle obsahu a kvality psaní úvodu lze posoudit míru kompetence autora, jeho znalost řešeného problému a v mnoha ohledech si lze vytvořit názor na povahu díla jako Celý.

3.5. Hlavní část

Hlavní část WRC obsahuje kapitoly představující analytický a praktický výzkum. Každý oddíl musí obsahovat alespoň tři pododdíly a každý pododdíl může obsahovat několik odstavců. Vezměte prosím na vědomí, že každá kapitola musí končit závěry.

Doporučený obsah a struktura kapitol VKR může změnit absolvent společně se školitelem v souladu s tématem a zadanými úkoly.

První kapitola (analytická)

První kapitola obsahuje formulaci úkolu a potřebná vysvětlení k němu.

Navrhujeme přibližný obsah první kapitoly:

1. ANALÝZA PŘEDMĚTOVÉ DOMÉNY A MODELOVÁNÍ INFORMAČNÍHO SYSTÉMU (NEBO SUBSYSTÉMU) .... (NÁZEV SPOLEČNOSTI, ORGANIZACE, PODNIKU) ... FORMULACE PROJEKTOVÝCH ÚKOLŮ

1.1. Technická a ekonomická charakteristika předmětné oblasti…. (název firmy, organizace, podniku) jako objekt předmětné oblasti

Předmětem může být podnik (divize podniku), firma, organizace apod., ale i samostatný druh činnosti v něm se vyskytující, proto je na začátku této části nutné zohlednit tzv. účel podniku, jeho organizační struktura a hlavní parametry jeho fungování.

Organizační struktura podniku je soubor vazeb (strukturálních oddílů) a vazeb mezi nimi.

Různé organizace se vyznačují různé typy řídících struktur. Existuje několik univerzálních typů organizačních řídících struktur, jako jsou lineární, lineárně-personální, funkční, lineárně-funkční, maticové.

V tomto bodě WRC je nutné uvažovat o obecné organizační struktuře podnikového managementu, ale jelikož předmětem úvahy při vývoji autonomního úkolu může být jakákoli činnost samostatná divize podniku(například oddělení, dílna), jeho úsek nebo jednotlivý zaměstnanec, pak musíte uvést stručný popis této jednotky, ve které předmětná činnost je vykonávána, popis její struktury, výčet řídících funkcí vykonávaných v této divizi (stručný popis pracovních povinností zaměstnanců), její interakce s ostatními divizemi podniku nebo divizemi vnějšího prostředí.

Dále musí tento odstavec žádosti obsahovat informace o softwarovém a hardwarovém vybavení podniku – soubor softwaru a hardwaru určeného k zajištění provozu informačního systému.

1.2. Vyjádření problému a popis systému

V tomto okamžiku musíte:

Popište stávající (předmětově specifickou) technologii pro vykonávání řídící funkce (souboru funkcí) vybrané ke zvážení. Uveďte seznamy a zdroje použitých vstupních dokumentů, seznamy a příjemce výstupních dokumentů, metody a technické prostředky použité k jejich zpracování;

Proveďte rozklad řešení úlohy, tzn. zvýraznit fáze řešení problému a funkčně jednoduché operace, z nichž se tyto fáze skládají;

Identifikujte hlavní nedostatky stávajících postupů správy a zpracování informací. V tomto případě by měl být kladen důraz na ty nedostatky, které mají být v projektu odstraněny, např.: vysoká náročnost zpracování informací; nízká efektivita, snižující kvalitu facility managementu; nedokonalá organizace sběru a evidence prvotních informací; nedokonalost procesů pro shromažďování, přenos a ukládání informací a procesů pro dodávání výsledků koncovému uživateli atd.

Cílem řešení problému by mělo být odstranění těch nedostatků, které autor poznamenal v předchozím odstavci, tzn. je zaměřena na zlepšování hodnot ukazatelů kvality zpracování informací (například zkrácení doby zpracování a získávání provozních dat pro rozhodování managementu; zvýšení míry spolehlivosti zpracování informací, zvýšení míry automatizace při získávání primárních informací, atd.) nebo zlepšení řady ekonomických ukazatelů (například zvýšení výroby, zvýšení počtu obsluhovaných zákazníků, snížení prostojů o... počet hodin atd.).

Při popisu účelu řešení problému je třeba klást důraz na seznam řídících funkcí, které budou při realizaci navrhovaného projektu automatizovány.

Kromě toho je v tomto odstavci WRC nutné zveřejnit požadavky na budoucí projekt zodpovězením následujících otázek:

Změny ve funkcích útvaru související se sběrem, zpracováním a vydáváním informací;

Zdroje příjmu provozních a podmíněně provozních informací a četnost jejich příjmu;

Fáze řešení problému, posloupnost a časový harmonogram jejich realizace, proveditelnost automatizace fází a operací řešení problému;

Vyjmenujte a popište požadavky na uživatelské rozhraní (vstup, prohlížení, úprava dokumentů/adresářů; možnost kombinovat data z různých dokumentů), případný seznam používaných obrazovkových formulářů;

Stručný popis výsledků (názvy výsledkových dokumentů, obrazovkové formuláře pro vydávání výsledků, seznam výsledkových souborů, způsoby jejich zobrazení na obrazovce, tisk nebo v komunikačním kanálu, jakož i místo jejich použití);

Stručný popis systému pro údržbu souborů v databázi (seznam souborů s podmíněně trvalými a provozními informacemi, četnost jejich aktualizací, požadavky na ochranu integrity, důvěrnosti a dostupnosti);

Způsob řešení problému (dávkové, interaktivní, s využitím metod teleprocessingu nebo smíšené), frekvence řešení problému;

Interakce navrženého systému se softwarem nainstalovaným na tomto pracovišti;

Omezení přístupu k informacím v databázi, jejich pravomoci;

Účel a tvorba protokolu operací v databázi;

Metody organizace vyhledávání informací;

Nastavení aktualizace informací v databázi pro všechny uživatele;

Organizace integrity dat.

1.3. Analýza alternativních řešení

V této podsekci byste měli prozkoumat trh se softwarem pro řešení tohoto problému (použijte internet, pokud takový existuje, pak proveďte stručný popis a analýzu alespoň jednoho podobného vývoje s uvedením hlavních charakteristik a funkcí). Poté byste měli uvést, v čem se z hlediska implementace softwaru bude navržená technologie lišit od stávající.

1.4. Vytvoření modelu vyvíjeného systému

Model je uměle vytvořený obraz konkrétního objektu, procesu nebo jevu a nakonec jakéhokoli systému. Při sestavování modelu reflektují jednotlivé aspekty fungování systému, tzn. něco konkrétního, co je zaměřeno na řešení uvedeného cíle obecného problému systémové analýzy.

V tomto okamžiku by měla projekční práce poskytnout vizuální znázornění projektovaného problému pomocí nástroje CASE v grafickém zápisu IDEF 0 (provést alespoň 3 úrovně rozkladu).

1.5 Systémové požadavky

Informační systém, jako každý jiný nástroj, musí mít své vlastnosti a požadavky, podle kterých lze určit jeho funkčnost a efektivitu. Pro každý konkrétní podnik se samozřejmě budou požadavky na informační systém lišit, protože je třeba vzít v úvahu specifika každé organizace. Navzdory tomu lze identifikovat několik základních požadavků na systém, které lze ve WRC charakterizovat:

1. Požadavky na kvalifikaci uživatele

2. Požadavky na spolehlivost

3. Požadavky na ergonomii a technickou estetiku

4. Požadavky na ochranu informací před neoprávněným přístupem

5. Možnost konsolidace informací na podnikové úrovni (slučování informací z poboček, dceřiných společností apod.), na úrovni jednotlivých úkolů, na úrovni časových úseků.

1.6 Nástroje pro vývoj softwaru a hardwaru

Tento odstavec poskytuje odůvodnění pro výběr typu počítače a periferních zařízení. V rámci prací na výzkumných a vývojových pracích je nutné stanovit, jaké požadavky je třeba klást na hardware při provozování vyvíjeného softwarového produktu na něm. Požadavky by měly být předloženy ve formě, která je mezi vývojáři softwaru standardní. Kromě toho by měly být uvedeny spotřebitelské faktory, tj. rozšířenost produktu, záruční podmínky, dostupnost dokumentace a technická podpora, kompatibilita s nejběžnějšími operačními systémy. Odůvodnění lze doplnit popisem perspektiv použití vybraného modelu, uvedením předpokládané životnosti, popisem možnosti modernizace využití v budoucnu pro jiný účel atd.

Odůvodnění rozhodnutí o návrhu softwaru spočívá ve vytváření požadavků na systémový (obecný) a speciální aplikační software, jakož i ve výběru vhodných softwarových komponent na základě těchto požadavků. Je nutné formulovat požadavky na speciální software, které musí navržený software splňovat.

Druhá kapitola (praktická část)

Tato kapitola práce je věnována přímo vývoji a psaní softwarového produktu. Mělo by vycházet z informací uvedených v první kapitole.

2. DESIGNOVÁ ČÁST

2.1. Koncepční návrh databáze

Konceptuální model- to je odrazem oblasti, pro kterou je databáze vyvíjena.

Koncepční návrh databáze zahrnuje analýzu informačních potřeb uživatelů a identifikaci požadovaných datových prvků. Výsledkem konceptuálního návrhu je vytvoření konceptuálního databázového diagramu, který na logické úrovni popisuje všechna potřebná data a vztahy mezi nimi.

V tuto chvíli je nutné provést koncepční návrh databáze s popisem hlavních entit, které by v ní měly být přítomny, a také vazeb mezi nimi.

2.2. Návrh logické databáze

Logický model– grafické znázornění struktury databáze zohledňující převzatý datový model (hierarchický, síťový, relační atd.), nezávisle na konečné implementaci databáze a hardwarové platformě.

V tomto okamžiku je nutné poskytnout logický model databáze.

2.3. Fyzický návrh databáze

Fyzikální model– logický model databáze, vyjádřený pomocí konkrétního jazyka pro popis dat .

Při zahájení fyzického návrhu databáze musíte nejprve vybrat konkrétní cílový DBMS. Fyzický design je proto neoddělitelně spojen s konkrétním DBMS. Mezi logickým a fyzickým návrhem existuje neustálá zpětná vazba, protože rozhodnutí učiněná během fáze fyzického návrhu za účelem zlepšení výkonu systému mohou ovlivnit strukturu logického datového modelu.

V této fázi návrhu databáze je nutné vzít v úvahu následující body - implementace doménových omezení, návrh fyzické reprezentace databáze, transakční analýza, výběr struktury souborů, stanovení indexů, stanovení nároků na diskovou paměť.

2.4. Aplikační algoritmus

Aplikační algoritmus převádí vstupní data na výstupní data. Paměť potřebná pro činnost algoritmu obsahuje vstupní data, se kterými algoritmus začíná pracovat, mezilehlá data a výstupní data, která jsou výsledkem algoritmu. Paměť je diskrétní, tzn. skládající se z jednotlivých buněk. Pojmenované paměťové místo se nazývá proměnná. Algoritmus aplikace je sestaven z jednotlivých kroků (akce, operace, příkazy). Samozřejmě existuje mnoho kroků, které tvoří algoritmus. Algoritmus dokončí svou práci po konečném počtu kroků - je popsána jedna z hlavních vlastností algoritmů - účinnost.

Poskytněte algoritmus pro provoz aplikace, uveďte vstupní a výstupní data.

2.5. Uživatelská příručka

V tomto odstavci je nutné popsat sled akcí uživatele (obsluhy), který udává popis funkcí, formát a možné možnosti příkazů, pomocí kterých uživatel načítá a řídí provádění programu, jakož i reakce na tyto příkazy.

2.6. Ochrana dat a bezpečnost

Popište nástroje ochrany dat v aplikaci v závislosti na zvoleném DBMS.

3.6. Závěr

Závěrečná část práce obsahuje závěrečné závěry charakterizující výsledky práce absolventa při řešení úloh stanovených v úvodu jejich realizace a jsou zváženy dosažené výsledky; Je také nutné naznačit způsoby realizace projektu a formulovat slibné směry rozvoje tématu WRC. Závěry by měly být učiněny na základě srovnání technických a ekonomických ukazatelů stávajících a projektovaných zařízení.

Závěr by měl být krátký (ne více než 3 strany textu).

Pokud student při psaní práce z nějakého důvodu neučinil progresivní rozhodnutí, měl by na závěr uvést důvody, které vedly k volbě mezilehlé možnosti a charakterizovat vyhlídky dalšího rozvoje práce v této oblasti.

3.7. Seznam použitých zdrojů

„Seznam použitých zdrojů“ odráží seznam zdrojů, které byly použity při psaní práce, sestavený v tomto pořadí:

federální zákony (v pořadí od posledního roku přijetí po předchozí);

dekrety prezidenta Ruské federace (ve stejném pořadí);

usnesení vlády Ruské federace (ve stejném pořadí);

další regulační právní akty;

další oficiální materiály (usnesení-doporučení mezinárodních

organizace a konference, oficiální zprávy, oficiální zprávy atd.);

monografie, učebnice, učební pomůcky (v abecedním pořadí);

zahraniční literatura;

Internetové zdroje.

Do seznamu referencí Použité zdroje jsou zahrnuty, uspořádané v pořadí výskytu odkazů v textu poznámky nebo abecedně. Celkový počet zdrojů je minimálně 25, z toho 50 % bylo publikováno nejdříve před pěti lety a minimálně 5 zdrojů musí být označeno odkazem na internetové stránky (zápisy musí odpovídat skutečnosti). Upozorňujeme, že by měly být uvedeny nejen učebnice, ale také odborná literatura a časopisy.

3.8. Aplikace

Přihlášky jsou vypracovány jako pokračování tohoto dokumentu na dalších listech, číslování stránek práce nepokračuje. Text dokumentu musí obsahovat odkazy na všechny aplikace.

Přihlášky jsou seřazeny v pořadí odkazů na ně v textu dokumentu. Každá aplikace by měla začínat na nové stránce se slovem „Příloha“ uprostřed stránky nahoře. Přihláška musí mít nadpis, který se píše symetricky k textu s velkým písmenem na samostatném řádku. Aplikace jsou označeny velkými písmeny ruské abecedy počínaje A, s výjimkou písmen E, 3, I, O, CH, ь, ы, Ъ. Za slovem „Aplikace“ následuje písmeno označující její pořadí.

Například:

Příloha A

3.9. Prezentace k obhajobě

Počítačová prezentace jasně a přehledně odráží hlavní etapy vývoje WRC. Prezentace by měla doplňovat projev absolventa při obhajobě práce, nikoli jej nahrazovat. Tento materiál je také prezentován na disku a připojen k výzkumnému projektu.

Titulní snímek, kde je uvedeno téma WRC a jeho autor;

Oblast předmětu, stanovení cílů a záměrů;

zdůvodnění relevance cíle;

Software a programovací jazyky, technické prostředky.

Koncepční, logická a fyzická datová schémata (DB);

Struktura programového vybavení informačního systému (zde je vhodné znázornit graf podřízenosti modulů);

Blokové schéma interakce modulů;

Vstupní a výstupní data pro testovací případ;

Výsledek testu softwaru informačního systému;

Závěr.

Při přípravě prezentace byste měli dodržovat některá pravidla, která vám pomohou vyhnout se chybám:

Všechny snímky musí být navrženy ve stejném stylu – barvy, fonty atd.;

Použijte co největší písmo, aby prezentované informace byly viditelné pro všechny přítomné na obhajobě;

Umístěte na snímek minimální text. Chcete-li převést text na čitelný snímek, musíte: rozdělit jej na samostatné odstavce, zvýraznit klíčové prvky, odstranit spojovací výrazy, úvodní slova atd.;

Názvy snímků by měly odrážet hlavní myšlenku, kterou snímek demonstruje;

Kresby a diagramy musí být umístěny v maximální velikosti povolené diapozitivem, čitelné a jasné pro vizuální vnímání;

Číslování snímků je povinné, protože umožňuje kdykoli se v prezentaci vrátit k požadovanému snímku, obrázku nebo diagramu;

Neměli byste se nechat unést speciálními efekty a jasnými barvami, které „zdobí“ vaši prezentaci. Animaci lze použít pouze například k upozornění na jednotlivé prvky diagramu nebo k vysvětlení průběhu nějakého složitého procesu.

3.10. Zpětná vazba od vedoucího práce

Posudek vypracovává vedoucí komise pro výzkum a vývoj a obsahuje tyto prvky (příloha 3):

Závěr o souladu výzkumné a vývojové práce se zadáním a požadavky Spolkového státního vzdělávacího standardu;

Zdůvodnění úkolu zadaného studentovi, jeho aktuálnost, souvislost s problematikou podniku nebo organizace;

Posouzení praktického významu WRC;

Výsledky očekávané na WRC;

Analýza práce absolventa;

Charakteristika studenta jako budoucího specialisty;

Nevýhody WRC;

Závěr o možnosti přidělení příslušné kvalifikace studentovi.

3.11. Externí recenzeVKR

Posudek je nejdůležitější dokument, který určuje úplnost a kvalitu materiálů předložených k obhajobě.

Posudek práce je prováděn předními odborníky v této oblasti. Seznam oponentů schvaluje vysokoškolský řád. Oponent je povinen si práci pozorně přečíst a podrobně ji posoudit.

Recenze musí:

učinit závěr o souladu výzkumné a vývojové práce se zadáním a požadavky federálního státního vzdělávacího standardu;

Posoudit relevanci práce;

Uveďte shodu obsahu práce s jejím tématem;

Posoudit hlavní výsledky práce, její praktický význam a možnost uvedení výsledků práce do praxe;

Zdůrazněte nedostatky v projektu;

Analýza platnosti závěrů a návrhů;

Všímat si úrovně teoretické přípravy žáka, jeho schopnosti aplikovat znalosti při řešení praktického problému;

Uveďte kvalitu práce;

Pro absolventa je nutné formulovat otázky, na které musí odpovědět při obhajobě;

Udělejte závěr o možnosti přiřazení příslušné kvalifikace žákovi

Formulář recenze je v příloze 4.

4. ORGANIZACE JEJÍ REALIZACE A SLEDOVÁNÍ POKROKU JEJÍ PŘÍPRAVY

Před zahájením předdiplomového praktického vyučování vedoucí katedry s předsedou oborové komise učitelů informatiky a ICT sejde schůzku, na které se stanoví postup organizace realizace práce a základní požadavky na ni. se dostávají do pozornosti postgraduálních studentů. Finální zadání konkrétního tématu diplomové práce studentovi probíhá během prvního týdne předdiplomové praxe. Po schválení tématu práce se student dohodne s vedoucím práce na plánu, postupu, termínech dokončení a přípravy práce k obhajobě. Výsledkem dohody je zaevidování zadání na technické dílo.

Po obdržení zadání od vedoucího si student sestaví individuální harmonogram - plán práce (Příloha 5) včetně etap prací a termínů jejich dokončení. V rozvrhu si student musí po vyjádření vedoucího zajistit časovou rezervu na dokončení jednotlivých kapitol práce. Termín dokončení díla podle harmonogramu musí odpovídat termínu dokončení díla, který je stanoven zadáním úkolu k dokončení díla.

Předseda výboru pro výzkum a vývoj:

Hodnotí studentem navržený návrh pracovního plánu práce, členění do kapitol a odstavců, jejich přibližné objemy, termíny odevzdání v první verzi a v případě potřeby provádí úpravy;

Poskytuje pomoc při výběru metodologie výzkumu;

Kontroluje dostatek literárních pramenů a dalších dokumentů vybraných studentem, pomáhá vyzdvihnout nejdůležitější z nich; vede studenta k sestavení kompletní bibliografie k výzkumnému tématu apod.;

Na konzultačních dnech sleduje postup prací, kontroluje kvalitu jednotlivých částí práce i studie jako celku. Pokud kvalita předložené části neodpovídá požadavkům na výzkumnou a vývojovou práci, učiní školitel potřebné připomínky a vrátí výzkumný materiál k přepracování.

Závěrečná revize práce se zohledněním připomínek vedoucího práce a její příprava k prezentaci vedoucímu katedry by měla proběhnout 1 týden před zahájením práce Státní atestační komise o ochraně špičkového technologického výzkumu.

Absolvent by měl pravidelně (po vzájemné dohodě minimálně 1x týdně) informovat vedoucího práce o postupu přípravy práce, konzultovat záležitosti, které způsobují potíže či pochybnosti, a určitě informovat o případných odchylkách od schváleného harmonogramu práce. .

Absolvent by měl mít na paměti, že vedoucí práce není spoluautorem ani editorem práce a není tedy povinen opravovat všechny teoretické, metodické, statistické a jiné chyby v práci.

V první fázi přípravy práce vedoucí radí, jak začít uvažovat o tématu, upraví plán práce a dá doporučení k seznamu literatury, kterou je třeba použít. Vedoucí práce v průběhu další práce vystupuje jako oponent, který absolventa upozorňuje na nedostatky argumentace, kompozice, stylu apod. a radí, jak je nejlépe odstranit.

Absolvent musí kreativně vnímat doporučení a připomínky školitele. Může je vzít v úvahu nebo je odmítnout podle vlastního uvážení, protože odpovědnost za teoreticky a metodologicky správné rozpracování a pokrytí tématu, kvalita obsahu a zpracování práce je plně na absolventovi.

Vedoucí katedry společně s předsedou oborové komise učitelů informatiky a ICT vykonává obecnou kontrolu nad postupem akademické práce na základě konsolidovaného harmonogramu, který stanoví termíny pro periodickou zprávu z r. studentům o jeho realizaci. V určený čas se studenti hlásí vedoucímu práce, stupeň připravenosti práce je poznamenán v rozvrhu. O všech podstatných odchylkách od termínů dokončení prací informuje vedoucí pracovník předsedu KKS a vedoucího odboru.

5. POSTUP PRO OCHRANU WRC

5.1. Předběžná ochranaVKR

Dva týdny před stanoveným termínem obhajoby práce je organizována předběžná obhajoba práce. Předobrana se provádí za účelem zjištění stupně připravenosti VRC na nadcházející obranu. Je opraven výkon absolventa a jsou uvedena vhodná doporučení k odstranění připomínek a specifikovaných nedostatků práce. K předběžné obhajobě jsou připuštěni studenti, kteří práci dokončili včas a v plném rozsahu. Na základě výsledků předběžné obhajoby je vypracováno osvědčení, které je předáno zástupci ředitele pro organizaci vzdělávací činnosti.

5.2. Obecná ustanovení a práce NSS pro ochranuVKR

Obhajoba diplomové práce je umožněna studentům, kteří úspěšně dokončili úplné zvládnutí hlavního vzdělávacího programu v oboru střední odborné vzdělávání 230401 Informační systémy (podle odvětví).

K zajištění přijímání studentů do Státního zkušebního ústavu je z příkazu ředitele vysoké školy zřízena komise, jejíž rozhodnutí se protokoluje. Zasedání komise se koná nejméně jeden den před státní zkouškou. Na jednání komise podává vedoucí výzkumných a vývojových prací zprávu o připravenosti díla k obhajobě. Na základě tohoto protokolu je vydán příkaz ředitele vysoké školy o přijetí studentů ke státní závěrečné atestaci.

K provádění státní zkoušky je zřízena Státní zkušební komise (SAC), která je jmenována příkazem ředitele kolegia a tvoří ji 5 osob, kromě předsedy SAC. Předseda NSS je jmenován ministerstvem školství a mládeže Chanty-Mansijské autonomní oblasti Okrug-Ugra.

Rozpis státní zkoušky je na příkaz ředitele školy schválen a vyvěšen na informačních stáncích školy.

Obhajoba diplomové práce se provádí na veřejném zasedání Státní atestační komise za účasti alespoň dvou třetin jejích členů ve lhůtách stanovených učebním plánem oboru.

Provádění změn ve VKR po obdržení zpětné vazby a recenzí není povoleno. O připuštění práce k obhajobě rozhoduje zástupce ředitele pro organizaci vzdělávací činnosti, o čemž je uveden odpovídající záznam na titulní straně práce. Poté je předán tajemníkovi Státní atestační komise.

Před zahájením obhajoby práce studenta jsou Státní atestační komisi poskytnuty tyto dokumenty:

1. písemný dokument podepsaný zástupcem ředitele pro organizaci vzdělávací činnosti;

2. souhrnné vyúčtování studenta o absolvování hlavního odborného vzdělávacího programu;

3. žákovská knížka;

4. přezkoumání vedoucího práce;

5. Recenze recenzenta.

Obhajoba práce probíhá na otevřeném zasedání Státní atestační komise (to znamená, že se jí může zúčastnit vedoucí práce, recenzenti, studenti a kdokoli další).

Ochrana SRC probíhá v následujícím pořadí:

Tajemník Státní atestační komise oznámí jméno absolventa a přečte téma práce.

Čtení recenze a recenze.

Zazní hlášení absolventa (7-10 minut).

Dotazy členů komise - odpovědi studentů

Projev může přednést vedoucí závěrečné kvalifikační práce, jakož i oponent, je-li přítomen jednání komise pro státní zkoušky.

Obhajoba závěrečné kvalifikační práce se hodnotí bodově. Maximální celkový počet bodů je 60 bodů. Kritéria hodnocení jsou specifikována v závěrečném státním certifikačním programu.

Hodnocení výsledku obhajoby závěrečné kvalifikační práce se provádí diferencovaně: „výborný“, „dobrý“, „uspokojivý“, „neuspokojivý“:

"Výborně" (51 - 60 bodů).

„Dobrý“ (45 - 50 bodů).

„Uspokojivé“ (36 - 44 bodů).

„Neuspokojivé“ (méně než 36 bodů).

Další body (2 body) jsou možné, pokud má student osobní portfolio, stejně jako úspěchy v projektové a výzkumné činnosti.

V souladu s tím se po skončení veřejné obhajoby koná neveřejné zasedání NSS. Na této poradě je stanovena známka na základě výsledků obhajoby práce v závislosti na bodovém hodnocení absolventa.

Celkové hodnocení práce absolventa je stanoveno s přihlédnutím k jeho teoretické přípravě, kvalitě provedení, návrhu a obhajobě práce. Státní atestační komise si všímá také novosti a aktuálnosti tématu, stupně vědeckého zpracování, využití počítačů a praktického významu výsledků výzkumu a vývoje.

Po celou dobu jednání NSS musí být z jednání uchováván zápis.

Tentýž den, po sepsání zápisu z jednání, jsou studentům oznámeny výsledky obhajoby práce. Po obhajobě práce je předána do archivu se všemi materiály.

Udělení kvalifikace probíhá u státní zkušební komise a zapisuje se do protokolu.

5.3. Projev na obranu

K obhajobě práce musí být řeč připravena písemně nebo počítačovou prezentací v délce 7-10 minut.

Zpráva má odhalit podstatu, teoretický a praktický význam výsledků provedené práce. Vzhledem k tomu, že většina členů Státní atestační komise nemá možnost se s absolventskou prací podrobně seznámit, kompetentní prezentace jim pomáhá získat představu o úrovni absolventa, podstatě absolventské práce. , jeho hlavní výhody a formulovat relevantní otázky. Vystoupení při obhajobě dává absolventovi příležitost ukázat svou intelektuální úroveň a úroveň své odborné přípravy. Zpráva a grafické materiály umožňují obhájci zaměřit pozornost komise na omezený okruh problémů a vyhnout se tak nepohodlným otázkám členů komise.

Konkrétně ze strukturálního hlediska lze zprávu (prezentaci) rozdělit do tří logicky na sebe navazujících částí.

V první části je stručně charakterizována relevance tématu, účel, předmět, předmět výzkumu, ustanovení předkládaná k obhajobě.

V druhé části diplomant v logickém sledu provedeného výzkumu charakterizuje jednotlivé kapitoly práce. Zvláštní pozornost je v tomto případě věnována konečným výsledkům a osobnímu přínosu absolventa při řešení úkolu.

Závěrečná část vychází z textu závěru WRC. Zde je užitečné uvést obecné závěry a dát dohromady hlavní doporučení.

Zmenšení textu během projevu je dosaženo snížením počtu (nebo odstraněním) úvah, srovnávání, diskusí, zdůvodňování, popisů atd., jakož i prezentací grafických informací a letáků.

Příloha A

Ukázka návrhu titulní strany proVKR

Ministerstvo školství a politiky mládeže

Chanty-Mansijský autonomní okruh - Ugra

Autonomní instituce odborného vzdělávání

Chanty-Mansijský autonomní okruh - Ugra

ABSOLVENTSKÁ KVALIFIKAČNÍ PRÁCE

Na téma: Vývoj informačního systému pro práci s předplatiteli

Dokončeno:

Žák 5. ročníku skupiny

specialita 230401 „Informační systémy (podle odvětví)“

Délka školení: 4 roky 10 měsíců.

Ivanov Ivan Ivanovič

Dozorce:

Želonkina Marina Valerievna

Standardní ovládání:_______________

Celé jméno

Přijat k obhajobě: ____________

(zástupce ředitele pro OOD E.Yu. Smirnov)

Chanty-Mansijsk, 2018

Dodatek B

Ukázkový úkol k dokončeníVKR

Ministerstvo školství a politiky mládeže

Chanty-Mansijský autonomní okruh - Ugra

Autonomní instituce odborného vzdělávání

Chanty-Mansijský autonomní okruh - Ugra

Technická a pedagogická škola v Chanty-Mansijsku

Schválil jsem

Náměstek Ředitel OOD

E.Yu Smirnov

" ___ " ____________________ 201__

CVIČENÍ

Student(ci) 5. ročníku 233 skupina oboru 230401 „Informační systémy (podle odvětví)

Celé jméno__________________________________________________________________________

Dozorce _________________________________________________________________

termín dokončení WRC je od „__“_______201__. od "__"________201__

1. Místo předpromoční praxe __________________________________________________

_______________________________________________________________________________

2. Téma WRC_____________________ ________________________________________________________

______________________________________________________________________________________________________________________________________________________________

3. Seznam problémů, které mají být vypracovány ve WRC nebo shrnutí práce:

Úvod

I. ANALÝZA DOMÉN A MODELOVÁNÍ INFORMAČNÍCH SYSTÉMŮ

1.1 Technická a ekonomická charakteristika předmětné oblasti

1.2 Popis problému a popis systému

1.3 Analýza alternativních řešení

1.4 Sestavení modelu vyvíjeného systému

1.5 Systémové požadavky

1.6 Nástroje pro vývoj softwaru a hardwaru

II. DESIGNOVÁ ČÁST

2.1 Koncepční návrh databáze

2.2 Návrh logické databáze

2.3 Fyzický návrh databáze

2.4 Aplikační algoritmus

2.5 Uživatelská příručka

2.6 Ochrana a zabezpečení dat

Závěr

Seznam použitých zdrojů

Aplikace

Datum vydání úkolu: „__“ ____________ 2018

Student _________________ __________________________

Předseda výboru pro výzkum a vývoj ________________ __________________________

Dodatek B

Recenze naVKR

Ministerstvo školství a politiky mládeže

Chanty-Mansijský autonomní okruh - Ugra

Autonomní instituce odborného vzdělávání

Chanty-Mansijský autonomní okruh - Ugra

Technická a pedagogická škola v Chanty-Mansijsku

POSOUZENÍ

na závěrečná kvalifikační práce

Téma WRC ____________________________________________________

1. Závěr o souladu výzkumné a vývojové práce se zadáním a požadavky federálního státního vzdělávacího standardu _______________________________________________________________________________________________________________________________________ ____________________________________________________________________________

2. Posouzení relevance a praktického významu tématu

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8. Závěr o možnosti přidělení příslušné kvalifikace studentovi ___________________________________

stůl 1

Kritéria pro posouzení VKR pro PM.01 „Provoz informačních systémů“

Body

PC 1.1. Sbírat data pro analýzu využití a fungování informačního systému, podílet se na přípravě reportovací dokumentace, podílet se na zpracování projektové dokumentace pro úpravu informačního systému

PC 1.2. Spolupracujte se souvisejícími specialisty při vývoji metod, nástrojů a technologií pro použití předmětů profesionální činnosti.

PC 1.3. Upravujte jednotlivé moduly informačního systému v souladu se zadáním práce, najděte chyby v kódování ve vyvinutých modulech informačního systému a zdokumentujte provedenou práci.

PC 1.4. Zúčastněte se přijímacích zkoušek.

PC 1.5. Vypracovat fragmenty dokumentace pro obsluhu informačního systému a fragmenty metod školení uživatelů.

PC 1.6. Podílet se na hodnocení kvality a ekonomické efektivnosti informačního systému.

PC 1.7. Instalujte a konfigurujte informační systém ve své kompetenci, dokumentujte výsledky práce.

PC 1.8. Mít prezentační dovednosti.

PC 1.9. Dodržujte předpisy pro aktualizaci, technickou podporu a obnovu dat informačního systému, práci s technickou dokumentací.

PC 1.10. Zajistit organizaci přístupu pro uživatele informačního systému v jejich působnosti.

PC 1.11. Konzultujte, školte uživatele, testujte získané znalosti a dovednosti.

Celkový

tabulka 2

Hodnotící kritéria pro projekt PM.02 „Účast na rozvoji informačních systémů“

Body

Implementace PC do struktury VKR

PC 2.1. Podílet se na vývoji technických specifikací

PC 2.2. Program v souladu s požadavky technických specifikací

PC 2.3. Aplikujte testovací techniky pro vyvinuté aplikace

PC 2.4. Vytvářejte reportovací dokumentaci na základě výsledků práce

PC 2.5. Připravte dokumentaci k softwaru v souladu s přijatými standardy

PC 2.6. Používat kritéria pro hodnocení kvality a spolehlivosti fungování informačního systému

PC 2.7. Řídit proces vývoje pomocí nástrojů

Celkový

Dozorce _______________________ ___________________________________

"____"_______________201__

Dodatek 4 Recenze WRC

Ministerstvo školství a politiky mládeže

Chanty-Mansijský autonomní okruh - Ugra

Autonomní instituce odborného vzdělávání

KHANTY-MANSIYAN TECHNOLOGICKÁ A PEDAGOGICKÁ KOLEJ

Posouzení

pro závěrečnou kvalifikační práci

Studentovo jméno___________________________________________________________

Specialita ____________________________________________________________

Skupina_________________________________________________________________

Rozsah výzkumných a vývojových prací __________________________________________________

1. Závěr o souladu výzkumné a vývojové práce se zadáním a federálním státním vzdělávacím standardem ___________________________________________________________________________________________________________________________________________________ __________________________________________________________________

2. Posouzení relevance práce

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

3. Soulad obsahu WRC s jeho tématem

______________________________________________________________________________________________________________________________________________________________

4. Posouzení hlavních výsledků práce, její praktický význam

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

5. Úroveň teoretické a praktické přípravy absolventa

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

6. Analýza platnosti závěrů a návrhů

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

7. Nevýhody této práce

_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

8. Závěr o možnosti přiřazení příslušné kvalifikace žákovi

Recenzoval: _____________________ __________________________________

"_____"_________201__

Dodatek 5 Harmonogram implementace WRC

Ministerstvo školství a politiky mládeže

Chanty-Mansijský autonomní okruh - Ugra

Autonomní instituce odborného vzdělávání

KHANTY-MANSIYAN TECHNOLOGICKÁ A PEDAGOGICKÁ KOLEJ

Plán

provedení závěrečné kvalifikační práce

Studentovo jméno___________________________________________________________

Téma WRC__________________________________________________________

Specialita ____________________________________________________________

Skupina_ _________________________________________________________________

vyvíjený systém

Vyjádření problému a popis systému

Analýza alternativních řešení

Vytvoření modelu vyvíjeného systému

Tvorba systémových požadavků

Charakteristika softwarových a hardwarových vývojových nástrojů

Návrh databáze

Programování algoritmů

Uživatelská příručka, práce s rozhraním informačního systému

Ochrana dat a bezpečnost

Testování a ladění softwaru

Příprava a návrh obrazového (grafického) materiálu

Příprava a návrh textové části návrhu projektu

Závěr vedoucího předobrany:

______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

VKR je povolena pro ochranu:

Datum ____________ Podpis jednatele ___________________