Podľa GOST táto norma (znovu vydaná v novembri 1987) stanovuje postup konštrukcie a prípravy technických špecifikácií pre vývoj programu alebo softvérového produktu pre počítače, komplexy a systémy bez ohľadu na ich účel a rozsah.
Pri jej vytváraní musíte byť mimoriadne opatrní a opatrní, pretože... O úspechu celého diela často rozhoduje zručne (a kompetentne) vypracovaná technická špecifikácia. Práve technické špecifikácie sú dohodnuté so zákazníkom, ktorý sa zvyčajne snaží zaviesť čo najviac protichodných a nafúknutých požiadaviek. Úlohou Exekútora je, naopak, uľahčiť mu život. Ale potom, čo boli podpisy umiestnené na oboch stranách, je príliš neskoro na to, aby ste niečo prehrali.
Všeobecné ustanovenia
Zadávacie podmienky sa vypracúvajú na hárkoch formátu A4 a/alebo A3 spravidla bez vypĺňania polí hárku. Čísla hárkov (strán) sú umiestnené v hornej časti hárku nad textom.Na vykonanie zmien a doplnení technického zázemia v ďalších fázach vývoja programu alebo softvérového produktu sa vydáva dodatok k nemu. Koordinácia a schvaľovanie dodatku k technické špecifikácie vykonávané v rovnakom poradí, ako je stanovené pre technické špecifikácie.
Zadávacie podmienky musia obsahovať tieto oddiely:
- názov a rozsah aplikácie;
- základ pre rozvoj;
- účel rozvoja;
- technické požiadavky na program alebo softvérový produkt;
- technické a ekonomické ukazovatele;
- etapy a etapy vývoja;
- kontrolný a akceptačný postup;
- aplikácie.
Sekcia: Názov a rozsah
V sekcii Názov a rozsah uviesť názov, stručný popis rozsahu použitia programu alebo softvérového produktu a predmet, v ktorom sa program alebo softvérový produkt používa.V časti Základ pre rozvoj je potrebné uviesť:
- dokument(y), na základe ktorých sa vývoj vykonáva;
- organizácia, ktorá schválila tento dokument, a dátum jeho schválenia;
- meno a (alebo) symbol rozvojové témy.
Sekcia: Účel rozvoja
V sekcii Účel rozvoja Musí byť uvedený funkčný a prevádzkový účel programu alebo softvérového produktu. Tu sa môžete obmedziť na jednu alebo dve frázy. Hlavná vec je jasne definovať, na čo je tento program určený.Napríklad: Program je jadrom automatizovanej pracovnej stanice (AWS) pre vývojára kontinuálneho lineárne systémy automatické ovládanie(ACS), čo umožňuje užívateľovi riešiť problémy analýzy jednoduchých modelov.
kapitola: Technické požiadavky na program alebo softvérový produkt
Táto časť by mala obsahovať nasledujúce podsekcie: - požiadavky na funkčné charakteristiky;
- požiadavky na spoľahlivosť;
- podmienky používania;
- požiadavky na zloženie a parametre technické prostriedky;
- požiadavky na informácie a softvérová kompatibilita;
- požiadavky na označovanie a balenie;
- požiadavky na prepravu a skladovanie;
- špeciálne požiadavky.
Časť: Požiadavky na funkčné charakteristiky.
Tu by sa mali uviesť požiadavky na skladbu vykonávaných funkcií, organizáciu vstupných a výstupných údajov, charakteristiky časovania atď.Napríklad : Program by mal umožňovať ... vypočítať ... postaviť ... vytvoriť ...
Vstupné údaje: textový súbor s daným...
Výstupné dáta: grafické a textové informácie - výsledky analýzy systému...; textové súbory - hlásenia o ... diagnostike stavu systému a hlásenia o všetkých chybách, ktoré sa vyskytli.
Požiadavky na spoľahlivosť. Musia byť špecifikované požiadavky na zabezpečenie spoľahlivej prevádzky (zabezpečenie stabilnej prevádzky, sledovanie vstupných a výstupných informácií, doba obnovy po poruche a pod.).
Tu je ťažké niečo „uhádnuť“. IN najlepší možný scenár Môže existovať možnosť, v ktorej váš program pracuje iba s úplne správnymi údajmi. Zákazník s tým zvyčajne nesúhlasí, ale môžete to skúsiť.
Napríklad: Program musí pracovať s danou rozšírenou maticou incidentov študovaného grafu v súlade s operačným algoritmom, generovať chybové hlásenia, keď sú počiatočné údaje nesprávne špecifikované, a podporovať interaktívny režim v rámci možností poskytnutých používateľovi.
Podmienky používania. Musia byť uvedené prevádzkové podmienky (teplota okolia, relatívnej vlhkosti atď. pre vybrané typy pamäťových médií), ktoré musia zabezpečiť uvedené vlastnosti, ako aj typ služby, požadované množstvo a kvalifikáciu personálu.
S týmto bodom zvyčajne nie sú žiadne ťažkosti. Žiaľ, klauzula o profesionalite užívateľa zo strany zákazníka je nevyhnutne implicitná. To je, samozrejme, ďalší dôvod, prečo nájsť chybu vo svojom programe. Tu sa však môžeme obmedziť na frázy ako „Prevádzkové podmienky programu sa zhodujú s prevádzkovými podmienkami IBM PC a PC s nimi kompatibilných“, „Program by mal byť navrhnutý pre neprofesionálneho používateľa.“ atď.
Požiadavky na zloženie a parametre technických prostriedkov. naznačiť požadované zloženie technické prostriedky označujúce ich technické vlastnosti.
Tu ide hlavne o to, aby na jednu stranu nič nezabudli a všetko zabezpečili (inak tam vkĺzli nejaké IBM PC/XT s monochromatickým displejom a bez myši) a na druhej strane nezabudli. preháňať to so zvýšenými požiadavkami, inak si Objednávateľ nájde flexibilnejšieho Dodávateľa.
Napríklad: Musíte mať PC kompatibilné s IBM PC s grafickým adaptérom EGA (VGA). Požadované miesto na disku je minimálne 600 KB, teda množstvo voľného miesta RAM- minimálne 400 kB. Je žiaduce mať ovládač EMS a manipulátor typu myši.
Požiadavky na informácie a kompatibilitu softvéru. Funkcie sú rovnaké ako v predchádzajúcom odseku. Tu by sa mali špecifikovať požiadavky na informačné štruktúry na vstupe a výstupe a metódy riešenia, zdrojové kódy a programovacie jazyky. V prípade potreby sa musí zabezpečiť ochrana informácií a programov.
Napríklad: Program musí pracovať autonómne pod OS MS DOS verzie nie nižšej ako 3.3. Základným programovacím jazykom je Turbo Pascal 6.0.
Požiadavky na označovanie a balenie a požiadavky na prepravu a skladovanie sú dosť exotické. IN všeobecný prípad tu uveďte požiadavky na označovanie softvérového produktu, možnosti balenia a metódy. A požiadavky na prepravu a skladovanie musia pre softvérový produkt uvádzať prepravné podmienky, miesta skladovania, podmienky skladovania, skladovacie podmienky, doby skladovania v rôznych podmienkach.
Špeciálne požiadavky sú veľmi dôležitá vec. Ak je to možné, je lepšie sa im vyhnúť. A hneď to deklaruj.
Napríklad: Neexistujú žiadne špeciálne požiadavky na časové charakteristiky programu. Neexistujú žiadne špeciálne požiadavky na kapacitné charakteristiky programu.
Technické a ekonomické ukazovatele. Tento najťažší bod pre programátora nie je vždy prítomný. Je potrebný predovšetkým vtedy, keď je vaším cieľom ospravedlniť obrovskú efektivitu a dôležitosť vykonávanej práce. Táto položka zvyčajne funguje pre zákazníka veľmi dobre. Toto je prinajmenšom najlepšie zdôvodnenie načasovania a peňažných čiastok vývoja.
Táto časť by mala uvádzať: približné ekonomická efektívnosť, odhadovaná ročná potreba (napríklad: odhadovaný počet hovorov do komplexu ako celku za rok - 365 pracovných stretnutí), ekonomické výhody vývoja v porovnaní s najlepšími domácimi a zahraničnými vzorkami alebo analógmi.
Okrem toho sa odporúča poskytnúť definíciu odhadovaných nákladov na vývoj programu a definíciu zložitosti programovania.
Etapy a fázy vývoja (o tom bude podrobnejšie popísané nižšie) stanovujú potrebné etapy vývoja, etapy a obsah práce (zoznam programových dokumentov, ktoré musia byť vypracované, odsúhlasené a schválené), ako aj napr. pravidlá, termíny vývoja a určiť interpretov.
Štandardné kroky sú popísané tu. Hlavná vec je správne určiť načasovanie. Ak je to možné, snažte sa rovnomerne rozdeliť fázy medzi termíny (a sumy). Pamätajte, že nie všetky projekty prežijú posledná etapa. A pre každú fázu by mali byť správy. Pamätajte tiež, že pracovný projekt zaberie najviac času. Ak nedokončíte dokumentáciu včas, objednávateľ má plné právo dielo vôbec neprijať so všetkými z toho vyplývajúcimi dôsledkami.
Hlavnými a nevyhnutnými fázami a krokmi sú samotné zadávacie podmienky, predbežný návrh, technické a pracovné projekty.
Návrh návrhu. V tejto fáze sa podrobne rozpracúvajú štruktúry vstupných a výstupných údajov a určuje sa forma ich prezentácie. Vo vývoji všeobecný popis algoritmus, samotný algoritmus, štruktúra programu. Pripravuje sa akčný plán rozvoja a implementácie programu.
Technický projekt. Obsahuje vyvinutý algoritmus na riešenie problému, ako aj metódy sledovania počiatočných informácií. Tu sa vyvíjajú nástroje na spracovanie chýb a vydávanie diagnostických správ, určujú sa formuláre na prezentáciu prvotných údajov a konfigurácia technického vybavenia.
Pracovný návrh. V tejto fáze sa vykonáva programovanie a ladenie programu, vývoj programových dokumentov, programov a testovacích metód. Príklady testovania a ladenia sa pripravujú. Dokončuje sa dokumentácia a grafický materiál. Zvyčajne sa uvádza, že počas vývoja programu by sa mala pripraviť nasledujúca dokumentácia:
Text programu;
Popis programu;
Testovací program a metodika;
Popis aplikácie;
užívateľský manuál.
Toto sú štandardné požiadavky. Ak zákazník súhlasí s tým, že nie je možné predložiť celý tento zoznam, znamená to, že jeho zámery týkajúce sa vás a vášho produktu nie sú vážne.
Nemusí tam byť žiadny grafický materiál. Najmä vtedy, keď sa nechystáte podávať správy o výsledkoch svojej práce. Ale pre vážne projekty je táto položka potrebná.
Napríklad: Počas vývoja programu by mal byť pripravený nasledujúci grafický materiál:
Technické a ekonomické ukazovatele;
Štruktúra programu;
Formát na prezentáciu vstupných údajov programu;
Schéma všeobecného algoritmu (2 listy);
obasic výpočtové algoritmy;
Príklad fungovania programu.
V časti Postup kontroly a akceptácie musia byť uvedené typy testov a všeobecné požiadavky za prijatie prac. Ak je to možné, potom v tomto odseku uveďte, že „kontrola a akceptácia vývoja sa vykonáva pomocou vybavenia poskytnutého zákazníkom“, inak sa od vás môže vyžadovať, aby ste si toto vybavenie priniesli so sebou.
Napríklad: Kontrola a akceptácia vývoja sa vykonáva na základe testovacích testov a príkladov ladenia. Tým sa skontroluje vykonávanie všetkých funkcií programu.
V dodatkoch k technickým špecifikáciám je v prípade potreby uvedené:
zoznam výskumných a iných prác odôvodňujúcich vývoj;
Algoritmové diagramy, tabuľky, popisy, zdôvodnenia, výpočty a iné dokumenty, ktoré možno použiť pri vývoji;
Ďalšie zdroje rozvoja.
Podsekcia „Požiadavky na informácie a kompatibilitu softvéru“ musí uvádzať požiadavky na informačné štruktúry na vstupe a výstupe a metódy riešenia, zdrojové kódy, programovacie jazyky a softvér používaný programom. V prípade potreby sa musí zabezpečiť ochrana informácií a programov.
Príklad. V počítači musí byť spustený operačný systém nie nižší ako Windows 98/NT 4.0. Požiadavka kompatibilita informácií by mala byť zabezpečená prácou so súbormi geometrických informácií určitej štruktúry ako vstupnými a výstupnými informáciami.
Koniec práce -
Táto téma patrí do sekcie:
Technológia vývoja softvéru
Na webovej stránke si prečítajte: „Technológia vývoja softvéru“...
Ak potrebujete doplnkový materiál k tejto téme, alebo ste nenašli to, čo ste hľadali, odporúčame použiť vyhľadávanie v našej databáze prác:
Čo urobíme s prijatým materiálom:
Ak bol tento materiál pre vás užitočný, môžete si ho uložiť na svoju stránku v sociálnych sieťach:
| Tweetujte |
Všetky témy v tejto sekcii:
Funkčné požiadavky
V pododdiele „Požiadavky na funkčné charakteristiky“ musia byť uvedené požiadavky na skladbu vykonávaných funkcií, organizáciu vstupných a výstupných údajov a časové charakteristiky.
Dohoda o požiadavkách
Vypracovanie dohody o požiadavkách je cieľom druhej časti prvého laboratória. Druhou časťou práce v kurze je aj dohoda o požiadavkách.
Nižšie je op.
Stručný popis produktu Stručne popísané a všeobecné pojmy
hlavné funkčné vlastnosti výrobku. Ak je softvérový produkt rozšírením existujúceho, charakterizujú sa iba jeho nové funkcie.
Výsledné komponenty produktu
Táto časť poskytuje tabuľku podobnú alebo ekvivalentnú tabuľke 2.1. V tomto prípade sa používa vopred pripravený tlačený formulár, ktorý skracuje čas na prípravu informácií.
Zamietnuté aplikácie Ak je cieľom prepracovať alebo vylepšiť produkt, alebo nahradiť produkt so známymi chybami, mali by sa vypracovať plány na opravu chýb nájdených na produkte. momentálne
čas. Preto v tomto bode
Vylúčené položky plánu
Ak existujú nejaké pokyny na plánovanie, ktoré vyžadujú špeciálne softvérové funkcie a schopnosti, ktoré nemožno poskytnúť, ak je produkt vyvinutý v súlade s inými požiadavkami
Ak je potreba vytvorenia produktu odôvodnená dokumentom, ako je plán vydania produktu, plán vydania série alebo popis úlohy, potom sa cituje buď konkrétna pasáž z každého dokumentu, resp.
Zoznam požiadaviek používateľov
Zákazníci produktu sú uvedení a je im vysvetlené, prečo ho potrebujú. V tejto časti sa uvádza aj predpokladaná doba používania produktu. Zvyčajne to bude životnosť zariadenia
Zvažované alternatívy
Stručne sú opísané alternatívy k tomuto dizajnu, ktoré boli zvážené a zamietnuté, ako aj dôvody zamietnutia. Ak je potrebné programy zakúpiť, je vysvetlené, prečo nie sú
Návratnosť investície
Zisk, ktorý vytvorenie produktu prinesie, je určený v termínoch zodpovedajúcich zamýšľaný účel organizácií.
Príklad. ABC Services očakáva predaj vo Fínsku
Systémový softvér Systémové softvér - toto je všetok ostatný softvér vrátane operačných systémov, kompilátorov, pomôcok, balíkov aplikačné programy
atď. Je to softvér
Všeobecné vlastnosti
Celý produkt je potrebné považovať za jeden funkčný modul, aby bol počet podsekcií malý. Ak nie je možné produkt adekvátne popísať bez rozdelenia na samostatné funkčné
Vonkajšie obmedzenia
Uvádzajú sa všetky obmedzenia, ktorých rozsah je širší ako rozsah ST; Patria sem napríklad obmedzenia priemyslu alebo produktovej rady. Môže byť povolené
Obmedzenia kompatibility
Vždy by sa malo zvážiť niekoľko aspektov kompatibility: zdrojový jazyk, strojový jazyk, formáty údajov a správ, formáty správ, formáty výpisov a formáty jazyka ovládania úloh (JL).
Softvérové obmedzenia
V prípade potreby uveďte operačný systém, s ktorým by mal navrhovaný softvérový produkt fungovať, ako aj ďalší softvér, s ktorým by mal byť v procese prepojený.
Hardvérové obmedzenia
Poskytuje sa tabuľka zariadení používaných pri prevádzke softvérového produktu. Pre každé zariadenie je uvedený minimálny, nominálny a maximálny požadovaný počet. Nominálna je optimálna
Výsledky práce
Všetky výstupné dáta softvérového produktu alebo funkčného modulu sú popísané z hľadiska ich obsahu a účelu – zostavy, súbory, záznamy, dátové polia, správy, tabuľky, checkboxy. Mal by
Popisuje operácie vykonávané softvérovým produktom, ktorý sa ako celok alebo funkčné moduly považuje za čiernu skrinku (alebo súbor čiernych skriniek). Minimálne po inštalácii
Spoľahlivosť
Spoľahlivosť softvéru sa vzťahuje na schopnosť obnovy normálna prevádzka v prípade chýb a porúch zariadenia. Ochrana údajov používateľov je mimoriadne dôležitá. Sl
Reštartujte
Uvádzajú sa schopnosti na zabezpečenie uloženia údajov a ich použitia pri obnovení práce po núdzovom prerušení, napríklad pri reštarte z kontrolného bodu.
Príklad 1. Program
Splnenie požiadaviek zákazníka
Sú špecifikované vlastnosti, ktoré umožňujú softvérovému produktu alebo jeho výstupu splniť špecifické požiadavky. Uvádza, ak je to možné, moduly, ktoré nemusia spĺňať požiadavky.
Výkonnostné charakteristiky
Je daná hlavná premenná alebo základný princíp, podľa ktorého by sa mala merať účinnosť programu; určuje vhodnú hodnotu alebo rozsah hodnôt pre túto premennú. Gl
Jednoduché použitie
Sú opísané vlastnosti, vďaka ktorým je interakcia „človek-stroj“ vhodná pre ľudí. Príkladmi sú voľný vstupný formát, dialógový režim, syntaktická kompatibilita, možná
Jednoduchosť údržby
Opatrenia sú opísané, aby sa zabezpečilo, že moduly budú identifikovateľné, ak tento problém nie je riešený normou.
Príklad 1. Každý zdrojový a objektový modul bude dodaný so softvérovou šifrou
Reštartovanie používateľského rozhrania
Príklad. Stav systému pre všetkých aktívnych používateľov (vrátane tých, ktorí sú odpojení, ale stále sú obsluhovaní) sa pravidelne ukladá na disk (v intervale špecifikovanom v rámci definície časov
Funkcie používateľského rozhrania
Príklad. Za predpokladu, že sa na počítači vykoná iba ASK a že parameter obnovy je charakterizovaný jedným kontrolným bodom za minútu, každý príkaz musí byť vykonaný resp.
Rozsah používateľského rozhrania
Príklad. V typickej relácii s ASK sa používateľ bez skúseností s programovaním pripojí k systému pomocou terminálu a vstúpi do dialógu, v ktorom definuje:
V prípade potreby uveďte operačný systém, s ktorým by mal navrhovaný softvérový produkt fungovať, ako aj ďalší softvér, s ktorým by mal byť v procese prepojený.
Príklad. Okrem zariadení potrebných pre VSOS ILSAM (pozri článok 2.4.1, b a c) bude korekčný procesor potrebovať zariadenia uvedené v tabuľke 2.3.
Tabuľka 2.3 - Zariadenia
Vnútorné obmedzenia
Je dôležité určiť nielen to, aký produkt bude, ale aj to, čo to nebude. Obmedzenie je vlastnosť (alebo schopnosť), ktorú by používateľ logicky očakával, ale ktorá
Referenčné dokumenty
Každý plánovací alebo technický dokument uvedený v ST je označený samostatne. Každý takýto dokument musí skutočne existovať (a nesmie byť implicitný v budúcnosti) a
Zdroje na podporu implementácie
Určujú sa zdroje potrebné na inštaláciu systému spolu so zdrojmi popísanými v časti 2.5.3 (tu máme na mysli strojový čas, mzdové náklady a potrebnú kvalifikáciu).
Pamäťové médium
Typ pamäťových zariadení je určený pre všetky distribuované komponenty softvérového produktu (napríklad magnetická páska, charakterizovaná počtom stôp a hustotou záznamu
Požadované vzťahy Požiadavky kladené týmto softvérovým produktom na iné projekty alebo funkcie sú určené. Dané stručný popis
každú požiadavku a označuje štádium, v ktorom ju možno stanoviť
Podporované prepojenia
Táto časť má podobnú štruktúru ako predchádzajúca, obsahuje však požiadavky kladené inými produktmi na tento produkt. Každá požiadavka v oddiele 2.6.1.2 musí byť splnená požiadavkou
Komisia technickej kontroly
Každý ST by mal odporučiť vytvorenie komisie technického auditu (TRC) s uvedením miesta výkonu práce každého člena komisie a jeho mena, ak je to možné, ako aj vymenovania
Testovacie úrovne
Testovanie programov môže byť organizované v troch etapách, vykonávané v troch režimoch a má desať kategórií (pozri časť 5 „Testovanie“). Tieto informácie sú prezentované vo forme tabuľky. Pre ka
Normy na porovnanie
Stanovia sa referenčné systémy, s ktorými sa má porovnávať. Charakteristiky tohto systému sú uvedené v relatívnych jednotkách. Ak neexistuje štandard na porovnanie
Oznámenie o zmene kalendárnych dátumov
Príklad. Názov projektu: ASK product development Kód projektu: C013. Kód produktu: L301A.
Názov produktu: ASK
Špecifikácie písania
Fáza testovania zvyčajne predstavuje polovicu finančných nákladov na vytvorenie systému. Zle naplánované testovanie vedie k výraznému predĺženiu času vývoja.
Organizácia testovania softvérových produktov
Testovanie neznamená ladenie, ktorého cieľom je zistiť, prečo sa v programe vyskytuje konkrétna chyba a odstrániť jej príčiny, ale proces zisťovania samotnej skutočnosti o prítomnosti chýb.
Typy testovania softvérových produktov. Testovacie štádiá
Vo všeobecnosti sa testy vykonávajú v niekoľkých etapách oddelených časom.
Prvá fáza zahŕňa testy triedy A, ktoré sa vykonávajú na konci fázy programovania.
Naprogramujte testovacie režimy
Testy sa líšia v závislosti od toho, kto ich vykonáva. Hlavnou myšlienkou je nezávislosť testovacej funkcie od vývojovej funkcie.
Testovací režim I znamená dokončený
Kategórie testovania softvérových produktov
Fázy testu označujú, kedy sa testy vykonávajú, a režimy určujú, kto testy vykonáva. Kategórie skúšok určujú povahu a účel skúšok. Premyslené delenie a
Technológia testovania, triedy ekvivalencie
Jedným zo spôsobov, ako preskúmať túto otázku, je preskúmať testovaciu stratégiu nazývanú testovanie čiernej skrinky, testovanie na základe údajov alebo testo.
Stavebné skúšky
Proces vytvárania testu zahŕňa: 1) priradenie jedinečného čísla každej triede ekvivalencie;
2) navrhovanie nových testov, z ktorých každý pokrýva
Všeobecné ustanovenia 1.1. Štruktúra a formát dokumentu sú stanovené v súlade s GOST 19.105-78. 1.2. Príručka systémového programátora by mala obsahovať nasledujúce časti: –
Štruktúra programu
Program "Automatizovaný pracoviskočítačka“ pozostáva z nasledujúcich komponentov: 1) zcon – aplikácia, ktorá implementuje funkcie klienta Z39.50; 2) zgate -CGI- Inštalácia programu
Tento dokument používa na pomenovanie súborov syntax definovanú v ISO/IEC 9945-1. V tých
operačných systémov
, ktoré nepodporujú
špecifikovaný spôsob pomenovanie súborov v aplikáciách Kontrola programu Program sa kontroluje podľa spôsobu jeho vykonania. Vzhľadom na to, že špecifické podmienky používania programu (adresy serverov Z39.50, názvy databáz, podporované body
Správy systémovému programátorovi
Tabuľka 5.1 zobrazuje správy, ktoré je možné prijímať systémový programátor počas konfigurácie, testovania programu, ako aj používateľa počas vykonávania programu.
Softvérový systém musí poskytovať ochranu údajov pred náhodným vymazaním a úpravou. Prístup k údajom by mal mať iba autorizovaný správca databázy alebo člen fakulty, ktorý je prihlásený na databázový server a má príslušné roly.
Aby bol vzdelávací systém spoľahlivý, musí spĺňať nasledujúce požiadavky:
vyvinutý program musí mať prostriedky na ochranu pred chybným konaním používateľa;
všetky chyby by mali byť zobrazené s komentármi alebo tipmi na ich odstránenie;
zaručujú bezpečnosť údajov v prípade porúch v prevádzke externých zariadení.
Na zvýšenie spoľahlivosti je potrebné prijať nasledujúce opatrenia:
konfigurovať hardvér a softvér v súlade s technickými požiadavkami;
pravidelne zálohovať informácie;
pravidelne kontrolovať integritu databázy;
Udržujte stav sieťových zariadení.
Požiadavky na zloženie a parametre technických prostriedkov
Minimálna hardvérová konfigurácia systému na zabezpečenie normálneho fungovania školiaceho systému nesmie byť nižšia ako:
RAM 128 MB alebo viac.
Minimálne 150 MB voľného miesta na pevnom disku.
Požiadavky na počítač používaný na vývoj konfigurácií:
Procesor AMD Athlon 900 MHz alebo vyšší.
RAM 256 MB alebo viac.
Aspoň 250 MB voľného miesta na pevnom disku.
Pri používaní automatizovaného systému v lokálnej sieti musí byť server Firebird1.5.3 s predinštalovanou databázou nainštalovaný a spustený na jednom z počítačov. Na iných strojoch musíte nainštalovať klientsku aplikáciu systému účtovania zariadení.
Požiadavky na informácie a kompatibilitu softvéru
Na prevádzku softvérového produktu musíte mať nasledujúce komponenty:
Operačný systém rodiny Microsoft®Windows® (aspoň 2000).
Nainštalované a nakonfigurované softvérové produkty MicrosoftSQLServer, IBExpert2004, Borland®C++Builder™ 6.0, Microsoft.NETFrameworkSDKv2.0.
podmienky používania
Program musí byť spustený na fungujúcom hardvéri. Požiadavky na prevádzkové podmienky PC a ostatných zariadení používaných v areáli sú uvedené v technickej dokumentácii, ktorá je súčasťou dodávky zariadení.
Požiadavky na softvérovú dokumentáciu
Dokumentácia programu by mala obsahovať nasledujúce dokumenty.
Príručka správcu systému.
Príručka pre učiteľa.
Príručka pre študentov.
Príručka správcu systému by mala obsahovať popisy konfiguračných funkcií tohto systému.
Softvérový systém musí obsahovať kompletnú príručku inštruktora s popisom scenárov práce inštruktora.
Softvérový systém musí obsahovať kompletnú príručku pre študenta, ktorá popisuje pracovné scenáre študenta.
Etapy vývoja softvérového systému
Vývoj softvérového systému by sa mal organizovať v nasledujúcich etapách.
vypracovanie plánu implementácie;
vypracovanie plánu testovania;
vypracovanie plánu implementácie.
Dizajn:
logický návrh architektúry softvérového systému;
vývoj databázovej štruktúry;
dizajn používateľského rozhrania.
Implementácia:
implementácia vyvinutého používateľského rozhrania;
implementácia hlavných funkcií softvérového systému.
Testovanie systému:
štrukturálne testovanie;
funkčné testovanie;
opravy chýb a vylepšenia.
Implementácia systému:
kontrola dostupnosti potrebného vybavenia;
inštalácia systému;
školenia personálu.
Údržba systému.
Na prianie zákazníka je tento softvér vyvinutý pre platformu Windows. Program musí fungovať pod hlavnými verziami tejto platformy: Windows98, Windows 2000, Windows XP. Serverová časť programu pre verzie WinNT by navyše mala fungovať ako služba (práca na pozadí).
Je potrebné zabezpečiť možnosť ďalšieho rozširovania funkcií systému (otvorenosť pre rozvoj a metódy prepájania nových úloh).
Požiadavky na prepravu a skladovanie
Vyvíjaný riadiaci systém bude dodaný ako súprava pri predaji radiča RAID. Musí byť nahraný na samostatnom CD, ktoré bude obsahovať systémové ovládače a potrebnú dokumentáciu k predávanému ovládaču. Aby ste to dosiahli, mali by ste zabezpečiť, aby veľkosť inštalačných súborov nebola väčšia ako približne 2/3 štandardného disku CD (700 MB).
Špeciálne požiadavky
Serverová časť programu, ktorá analyzuje činnosť RAID, musí byť vždy spustená na počítači so systémom RAID. Ak je tento modul zastavený, potom sa bez neho nebude možné pripojiť k systému RAID a nebude možné monitorovať činnosť RAID (odosielať upozornenia o poruchách a udržiavať súbory histórie prevádzky RAID).
Bloková schéma programu
Celý softvérový projekt je založený na dvoch nezávislých moduloch. Ako už bolo spomenuté, jeden z nich beží samostatne na počítači so systémom RAID a druhý na počítači správcu. Pre stručnosť nazveme prvý modul agent a druhý - manažér.
manažér– používateľská strana programu, ktorá obsahuje rozhranie programu, sprievodcu úvodnou inštaláciou a časť pomocníka. manažér bude spravovať systém RAID cez agent.
agent slúži hlavne na prenos príkazov z manažér RAID systém a naopak. Tiež agent bude monitorovať RAID (udržiavať log súbor) a upozorniť administrátora na chyby.
Net
Ryža. 1.2. Základná štruktúra programu GUIRAIDManager
Základná štruktúra práce ako celku je uvedená na obr. 1.2. Zobrazuje rôzne možnosti fungovania týchto dvoch modulov. agent A manažér:
agent(C3 ) sa spustí na počítači a analyzuje činnosť poľa RAID R2 ;
manažér s vzdialený počítač (C2 alebo C4) je možné pripojiť cez sieť k A gentom(C3) na ovládanie činnosti poľa RAID R2 ;
manažér A agent spustený na jednom počítači C1 na riadenie činnosti poľa RAID R2 . Pri tejto možnosti nie je potrebné žiadne sieťové pripojenie.
Štruktúra vstupných a výstupných údajov
Hlavná výmena údajov v systéme ako celku prebieha cez dva kanály:
medzi manažér A agent cez sieť pomocou protokolu TCP/IP (príkazy manažér a odpovede agent);
medzi agent a radič RAID cez rozhranie RS-232 (výzva radiča a odpovede z neho).
Všeobecná schéma výmeny dát v projekte je znázornená na obr. 1.3.
Ryža. 1.3. Výmena dát v programe GUIRAIDManager
Formát údajov medzi manažér A agent, a tiež medzi agent a radič RAID je popísaný v odseku „Formát údajov modulu agent» tejto časti.
Mojou úlohou v tomto projekte je vyvinúť modul agent. Pozrime sa preto bližšie na výmenu údajov v module agent medzi manažér a radič RAID. Modulárna štruktúra agent znázornené na obr. 1.4
Ryža. 1.4. Výmena dát v module Agent
Tento diagram ukazuje, že údaje medzi manažér A agent prejsť cez modul na príjem a prenos dát cez sieť. Ak chcete skontrolovať pripojenie manažér tento modul používa autorizačný blok. Všetky prijaté dáta sú analyzované v bloku príkazového procesora manažér. V závislosti od typu príkazu sa informácie dostanú buď do bloku nastavení, do bloku súboru histórie alebo do modulu dotazovania stavu RAID. Ten slúži na odosielanie príkazov do radiča RAID a prijímanie odpovedí z neho. Ak sa počas požiadavky vyskytne chyba alebo odpoveď kontroléra obsahuje kritickú správu, notifikačný modul na túto chybu upozorní administrátora.