Príprava na laboratórne práce

Prečítajte si prednáškový materiál na tému „Modely životného cyklu softvéru. Etapy životného cyklu v súlade s GOST 19.102-77. Vyjadrenie problému“ disciplíny „Vývoj a štandardizácia PS a IT“.

1. Preštudujte si príslušné časti v publikáciách.

Teoretická časť. rozvoj referenčné podmienky

Technická úloha je dokument, ktorý formuluje hlavné ciele vývoja, požiadavky na softvérový produkt, určuje termíny a fázy vývoja a upravuje proces akceptačných testov. Na vypracovaní zadávacích podmienok sa podieľajú zástupcovia objednávateľa aj zástupcovia zhotoviteľa. Tento dokument vychádza z počiatočných požiadaviek zákazníka, analýzy pokročilých technológií, výsledkov vedeckého výskumu, predprojektového výskumu, vedeckých prognóz atď.

Poradie vývoja technických špecifikácií

Vývoj technických špecifikácií sa vykonáva v nasledujúcom poradí. V prvom rade stanovujú súbor funkcií, ktoré sa majú vykonať, ako aj zoznam a charakteristiky počiatočných údajov. Potom sa určí zoznam výsledkov, ich charakteristiky a spôsoby prezentácie.

Ďalej špecifikujú prostredie pre fungovanie softvéru: konkrétnu konfiguráciu a parametre technické prostriedky, verziu používaného operačného systému a prípadne verzie a nastavenia iného nainštalovaného softvéru, s ktorým bude budúci softvérový produkt interagovať.

V prípadoch, keď vyvinutý softvér zhromažďuje a ukladá nejaké informácie alebo je zahrnutý do riadenia akéhokoľvek technického procesu, je tiež potrebné jasne regulovať činnosti programu v prípade výpadkov zariadení a napájania.

1. Všeobecné ustanovenia

1.1. Zadávacie podmienky sú vypracované v súlade s GOST 19.106-78 na listoch formátu A4 a A3 v súlade s GOST 2.301-68, spravidla bez vyplnenia polí listu. Čísla listov (strán) sú nalepené v hornej časti listu nad textom.

1.2. Schvaľovací list a titulná strana sú vyhotovené v súlade s GOST 19.104-78. Dokument nemusí obsahovať informačnú časť (abstrakt a obsah), hárok registrácie zmien.

1.3. 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 zadávacím podmienkam sa vykonáva rovnakým spôsobom, aký je stanovený pre zadávacie podmienky.

1.4. Referenčné podmienky by mali obsahovať tieto časti:

Úvod;

Názov a rozsah;

Základ pre rozvoj;

Účel rozvoja;

Technické požiadavky k programu alebo softvérovému produktu;

Technické a ekonomické ukazovatele;

Etapy a štádiá vývoja;

Postup kontroly a prijatia;

Aplikácie.

V závislosti od vlastností programu alebo softvérového produktu je povolené objasniť obsah sekcií, zaviesť nové sekcie alebo niektoré z nich kombinovať. V prípade potreby je povolené zahrnúť žiadosti do podmienok.

2.1.Úvod by mal obsahovať stručný popis rozsah programu alebo softvérového produktu, ako aj objekt (napríklad systém), v ktorom sa má používať. Hlavným cieľom úvodu je poukázať na relevantnosť tohto vývoja a ukázať, aké miesto tento vývoj zaujíma medzi podobnými.

2.2 V časti „Názov a rozsah“ uveďte názov, stručný popis rozsahu programu alebo softvérového produktu a objekt, v ktorom sa program alebo softvérový produkt používa.

2.3 V časti „Základy vývoja“ sa musí uviesť:

Dokument (dokumenty), na základe ktorých sa uskutočňuje vývoj. Takýmto dokumentom môže byť plán, objednávka, zmluva atď.;

organizácia, ktorá schválila tento dokument, a dátum jeho schválenia;

Meno a (alebo) symbol rozvojové témy.

2.4. Časť Účel vývoja by mala uvádzať funkčný a prevádzkový účel programu alebo softvérového produktu.

2.5. Časť „Technické požiadavky na program alebo softvérový produkt“ by mala obsahovať nasledujúce podsekcie:

požiadavky na výkon;

Požiadavky na spoľahlivosť;

prevádzkové podmienky;

Požiadavky na skladbu a parametre technických prostriedkov;

Požiadavky na informácie a kompatibilitu softvéru;

Požiadavky na označovanie a balenie;

Požiadavky na prepravu a skladovanie;

Špeciálne požiadavky.

2.5.1 Pododdiel "Požiadavky na funkčné charakteristiky" by mal uvádzať požiadavky na zloženie vykonávaných funkcií, organizáciu vstupných a výstupných údajov, časové charakteristiky atď.

2.5.2 V pododdiele "Požiadavky na spoľahlivosť" musia byť uvedené požiadavky na zabezpečenie spoľahlivej prevádzky (zabezpečenie stabilnej prevádzky, kontrola vstupných a výstupných informácií, čas obnovy po poruche atď.).

2.5.3 V podsekcii "Prevádzkové podmienky" musia byť uvedené prevádzkové podmienky (teplota okolitého vzduchu, relatívna vlhkosť a pod. pri vybraných typoch dátových nosičov), pri ktorých musia byť zabezpečené špecifikované vlastnosti, ako aj typ služba, požadované množstvo a kvalifikácia personálu.

2.5.4 V pododdiele "Požiadavky na zloženie a parametre technických prostriedkov" uveďte požadované zloženie technických prostriedkov s uvedením ich technické údaje.

2.5.5 V podkapitole „Požiadavky na informácie a kompatibilitu programu“ by mali byť uvedené požiadavky na informačné štruktúry na vstupe a výstupe a metódy riešenia, zdrojové kódy, programovacie jazyky. V prípade potreby by sa mali chrániť informácie a programy.

2.5.6 V pododdiele "Požiadavky na označovanie a balenie" sú vo všeobecnosti uvedené požiadavky na označovanie softvérového produktu, možnosti balenia a metódy.

2.5.7 V podkapitole „Požiadavky na prepravu a skladovanie“ pre softvérový produkt musia byť uvedené podmienky prepravy, miesta skladovania, podmienky skladovania, podmienky skladovania, doby skladovania za rôznych podmienok.

2.5.8. V časti "Technické a ekonomické ukazovatele" by sa malo uviesť: odhadovaná ekonomická efektívnosť, odhadovaná ročná potreba, ekonomické výhody vývoja v porovnaní s najlepšími domácimi a zahraničnými vzorkami alebo analógmi.

2.6. V časti „Etapy a etapy vývoja“ sú uvedené potrebné etapy vývoja, etapy a obsah prác (zoznam programových dokumentov, ktoré musia byť vypracované, odsúhlasené a schválené), ako aj spravidla vypracovanie časový rámec a určia sa exekútori.

2.7.V časti „Postup pri kontrole a preberaní“ druhy skúšok a Všeobecné požiadavky prijať prácu.

2.8 V prílohách k zadávacím podmienkam, ak je to potrebné, uveďte:

Zoznam výskumných a iných prác odôvodňujúcich vývoj;

Schémy algoritmov, tabuľky, popisy, zdôvodnenia, výpočty a iné dokumenty, ktoré možno použiť pri vývoji;

Iné zdroje rozvoja.

V prípadoch, keď zákazník nestanoví žiadne požiadavky stanovené v zadávacích podmienkach, na príslušnom mieste by malo byť uvedené „Nie sú uvedené žiadne požiadavky“.

Príklady vývoja zadávacích podmienok sú uvedené v prílohách B a C.

testovacie otázky

1.Uveďte koncept modelu životný cyklus ON.

2. Uveďte fázy vývoja softvéru.

3. Čo obsahuje vyhlásenie o probléme a predprojektový výskum?

4. Uveďte funkčné a prevádzkové požiadavky na softvérový produkt.

5. Uveďte pravidlá pre vypracovanie zadávacích podmienok.

6. Vymenujte hlavné časti zadávacích podmienok.

Príloha A

Pracovné možnosti

Laboratórne práce č. 1-5 sa vykonávajú pre rovnakú možnosť.

1. Vyvinúť softvérový modul „Účtovanie pokroku študentov“. Softvérový modul je navrhnutý tak, aby promptne zaznamenával pokroky študentov na zasadnutí dekana, zástupcov dekanov a zamestnancov dekana. Informácie o pokroku študentov by sa mali uchovávať počas celého obdobia ich štúdia a mali by sa používať pri príprave osvedčení o absolvovaných kurzoch a dodatkov k diplomu.

2. Vypracovať programový modul „Osobné spisy študentov“. Softvérový modul je určený na získavanie informácií o študentoch zamestnancami dekanátu, odborového výboru a personálneho oddelenia. Informácie je potrebné uchovávať počas celého obdobia vzdelávania žiakov a využívať ich pri príprave vysvedčení a správ.

3. Vyvinúť softvérový modul „Riešenie problémov kombinatorickej optimalizácie“. Modul by mal obsahovať algoritmy na nájdenie minimálnej dĺžky cyklu (problém obchodného cestujúceho), nájdenie najkratšej cesty a nájdenie minimálneho kostry.

4. Vyvinúť softvérový modul „Spracovanie matíc“. Modul by mal obsahovať algoritmy na vyhľadávanie súčtov a súčinov prvkov matice podľa riadkov a stĺpcov, ako aj na výpočet priemerných, minimálnych a maximálnych hodnôt v matici.

5. Vytvorte aplikáciu Windows „Organizer“. Aplikácia je určená na zaznamenávanie, ukladanie a vyhľadávanie adries a telefónnych čísel jednotlivcov a organizácie, ako aj plány, stretnutia atď. Aplikácia je určená pre každého používateľa počítača.

6. Vytvorte Windows aplikáciu „Kalkulačka“. Aplikácia je určená pre každého používateľa a mala by obsahovať všetky aritmetické operácie (s ohľadom na priority) a pokiaľ možno (nie je to potrebné) niekoľko matematických funkcií.

7. Vypracovať softvérový modul „Katedra“, obsahujúci informácie o pracovníkoch katedry (meno, funkcia, akademický titul, odbory, náplň práce, sociálna práca, brigády a pod.). Modul je určený pre zamestnancov personálneho oddelenia a dekanátu.

8. Vypracovať softvérový modul „Laboratórium“, ktorý obsahuje informácie o pracovníkoch laboratória (meno, pohlavie, vek, rodinný stav, prítomnosť detí, postavenie, akademický titul). Modul je určený pre zamestnancov odborového výboru a personálneho oddelenia.

9. Vyviňte programový modul „Čistenie na sucho“. Pri registrácii do služby sa vyplní žiadosť, v ktorej je uvedené celé meno majiteľa, popis produktu, typ služby, dátum prijatia objednávky a cena služby. Po dokončení práce sa vytlačí potvrdenie.

10.Vyviňte softvérový modul „Účtovanie porušení pravidiel premávky". Pre každé auto (a jeho majiteľa) je v databáze uložený zoznam priestupkov. Pri každom priestupku sa eviduje dátum, čas, druh priestupku a výška pokuty. Po zaplatení všetkých pokút je auto odstránené z databázy.

11. Vypracovať softvérový modul „Kartová kartotéka autopredajne“, určený pre agentúrnych zamestnancov. Databáza obsahuje informácie o autách (značka, objem motora, dátum vydania atď.). Po prijatí objednávky sa vykoná vyhľadávanie vhodná možnosť. Ak to tak nie je, klient je zaradený do klientskej základne a upozornený, keď sa objaví možnosť.

12. Vyvinúť softvérový modul „Karta predplatiteľov ATS“. Súbor karty obsahuje informácie o telefónoch a ich vlastníkoch. Opravuje nedoplatky platieb (podľa predplatiteľa a času). Predpokladá sa, že hodinová platba miestnych telefónnych hovorov už bola zavedená.

13. Vyvinúť softvérový modul „Avtokassa“ obsahujúci informácie o dostupnosti miest na autobusových linkách. Databáza by mala obsahovať informácie o čísle letu, trase, vodičovi, type autobusu, dátume a čase odchodu, ako aj ceny leteniek. Po prijatí žiadosti o letenky program vyhľadá vhodný let.

14. Vyvinúť softvérový modul „Kníhkupectvo“, obsahujúci informácie o knihách (autor, názov, vydavateľ, rok vydania, cena). Kupujúci vyplní žiadosť o knihy, ktoré potrebuje, ak žiadne nie sú, je zaradený do databázy a upozornený, keď potrebné knihy dorazí do predajne.

15. Vyvinúť softvérový modul „Parkovanie“. Program obsahuje informácie o značke auta, jeho majiteľovi, dátume a čase vjazdu, nákladoch na parkovanie, zľavách, nedoplatkoch atď.

16. Vypracujte programový modul „Personálna agentúra“, ktorý obsahuje informácie o voľných pracovných miestach a životopisoch. Softvérový modul je určený jednak na nájdenie zamestnanca, ktorý spĺňa požiadavky manažérov spoločnosti, ako aj na nájdenie vhodnej práce.

LAB #1

Etapy vývoja softvéru v štrukturálnom prístupe k programovaniu. Fáza "Podmienky referencie"

Cieľ: Oboznámte sa s pravidlami písania technických špecifikácií.

Príprava na laboratórnu prácu

Prečítajte si prednáškový materiál na tému „Modely životného cyklu softvéru. Etapy životného cyklu v súlade s GOST 19.102-77. Vyjadrenie problému“ disciplíny „Vývoj a štandardizácia PS a IT“.

Preštudujte si príslušné časti v publikáciách.

Teoretická časť. Vývoj technických špecifikácií

Technická úloha je dokument, ktorý formuluje hlavné ciele vývoja, požiadavky na softvérový produkt, určuje termíny a fázy vývoja a upravuje proces akceptačných testov. Na vypracovaní zadávacích podmienok sa podieľajú zástupcovia objednávateľa aj zástupcovia zhotoviteľa. Tento dokument vychádza z počiatočných požiadaviek zákazníka, analýzy pokročilých technológií, výsledkov vedeckého výskumu, predprojektového výskumu, vedeckých prognóz atď.

Poradie vývoja technických špecifikácií

Vývoj technických špecifikácií sa vykonáva v nasledujúcom poradí. V prvom rade stanovujú súbor funkcií, ktoré sa majú vykonať, ako aj zoznam a charakteristiky počiatočných údajov. Potom sa určí zoznam výsledkov, ich charakteristiky a spôsoby prezentácie. Ďalej je špecifikované prostredie prevádzky softvéru: konkrétna konfigurácia a parametre hardvéru, verzia použitého operačného systému, prípadne verzie a parametre ďalšieho nainštalovaného softvéru, s ktorým bude budúci softvérový produkt interagovať. V prípadoch, keď vyvinutý softvér zhromažďuje a ukladá nejaké informácie alebo je zahrnutý do riadenia akéhokoľvek technického procesu, je tiež potrebné jasne regulovať činnosti programu v prípade výpadkov zariadení a napájania. 1. Všeobecné ustanovenia

Zadávacie podmienky sú vypracované v súlade s GOST 19.106-78 na listoch formátu A4 a A3 v súlade s GOST 2.301-68, spravidla bez vyplnenia polí listu. Čísla listov (strán) sú nalepené v hornej časti listu nad textom. Schvaľovací list a titulná strana sú vyhotovené v súlade s GOST 19.104-78. Informačná časť (abstrakt a obsah), list evidencie zmien nemusí byť súčasťou dokumentu. 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 zadávacím podmienkam sa vykonáva rovnakým spôsobom, aký je stanovený pre zadávacie podmienky. Referenčné podmienky by mali obsahovať tieto časti:

úvod; názov a rozsah;

základ pre rozvoj; účel rozvoja; technické požiadavky na program alebo softvérový produkt; technické a ekonomické ukazovatele; etapy a etapy vývoja; postup kontroly a prijatia; aplikácie.

V závislosti od vlastností programu alebo softvérového produktu je povolené objasniť obsah sekcií, zaviesť nové sekcie alebo niektoré z nich kombinovať. V prípade potreby je povolené zahrnúť žiadosti do podmienok. 2. Obsah sekcií

Úvod by mal obsahovať stručný popis rozsahu programu alebo softvérového produktu, ako aj objektu (napríklad systému), v ktorom sa má používať. Hlavným cieľom úvodu je poukázať na relevantnosť tohto vývoja a ukázať, aké miesto tento vývoj zaujíma medzi podobnými. V časti „Názov a rozsah“ uveďte názov, stručný popis rozsahu programu alebo softvérového produktu a objekt, v ktorom sa program alebo softvérový produkt používa. V časti Základy rozvoja by sa malo uviesť:

dokument (dokumenty), na základe ktorých sa uskutočňuje voj. Takýmto dokumentom môže byť plán, objednávka, zmluva atď.; organizácia, ktorá schválila tento dokument, a dátum jeho schválenia; názov a (alebo) symbol rozvojovej témy. 2.4. Časť Účel vývoja by mala uvádzať funkčný a prevádzkový účel programu alebo softvérového produktu. 2.5. Časť „Technické požiadavky na program alebo softvérový produkt“ by mala obsahovať nasledujúce podsekcie:

požiadavky na výkon; požiadavky na spoľahlivosť; podmienky používania; požiadavky na skladbu a parametre technických prostriedkov;

požiadavky na informácie a kompatibilitu softvéru;

požiadavky na označovanie a balenie; požiadavky na prepravu a skladovanie; špeciálne požiadavky.

V podkapitole "Požiadavky na funkčné charakteristiky" by mali byť uvedené požiadavky na skladbu vykonávaných funkcií, organizáciu vstupných a výstupných údajov, časové charakteristiky a pod. V podkapitole "Požiadavky na spoľahlivosť" by mali byť uvedené požiadavky na zabezpečenie spoľahlivej prevádzky (zabezpečenie stabilná prevádzka, kontrola vstupných a výstupných informácií, čas obnovy po poruche a pod.). V podsekcii „Prevádzkové podmienky“ by mali byť uvedené prevádzkové podmienky (teplota okolitého vzduchu, relatívna vlhkosť vzduchu a pod. pri vybraných typoch dátových nosičov), za ktorých sa má špecifikovaná charakteristika poskytovať, ako aj druh služby, požadovaný počet resp. kvalifikácia personálu. V podsekcii „Požiadavky na zloženie a parametre technických prostriedkov“ uveďte požadované zloženie technických prostriedkov s uvedením ich technických vlastností. V podsekcii „Požiadavky na informácie a kompatibilitu programov“ by mali byť uvedené 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 by sa mali chrániť informácie a programy. V podkapitole „Požiadavky na označovanie a balenie“ sú vo všeobecnosti uvedené požiadavky na označovanie softvérového produktu, možnosti balenia a metódy. V podkapitole „Požiadavky na prepravu a skladovanie“ musia byť uvedené podmienky prepravy, miesta skladovania, podmienky skladovania, podmienky skladovania, doby skladovania za rôznych podmienok pre softvérový produkt.

2.5.8. V časti "Technické a ekonomické ukazovatele" by sa malo uviesť: odhadovaná ekonomická efektívnosť, odhadovaná ročná potreba, ekonomické výhody vývoja v porovnaní s najlepšími domácimi a zahraničnými vzorkami alebo analógmi.

V časti „Etapy a etapy vývoja“ sú uvedené potrebné etapy vývoja, etapy a obsah prác (zoznam programových dokumentov, ktoré musia byť vypracované, odsúhlasené a schválené), ako aj spravidla časový rámec vývoja a určiť, že sú ustanovení vykonávatelia. V časti „Postup kontroly a preberania“ by sa mali uviesť typy skúšok a všeobecné požiadavky na preberanie prác. V prílohách k zadávacím podmienkam v prípade potreby uveďte:

zoznam výskumných a iných prác odôvodňujúcich vývoj; schémy algoritmov, tabuľky, popisy, odôvodnenia, výpočty a iné dokumenty, ktoré možno použiť pri vývoji; iné zdroje rozvoja.

V prípadoch, keď zákazník nestanoví žiadne požiadavky stanovené v zadávacích podmienkach, malo by byť na príslušnom mieste uvedené „žiadne požiadavky“. Príklady vývoja zadávacích podmienok sú uvedené v prílohách B a C.

Zákazka

Vypracujte referenčné podmienky pre softvérový produkt podľa vašej verzie (pozri možnosti v prílohe A) Pripravte prácu v súlade s GOST 19.106-78. Na registráciu použite MS Office. Odovzdajte a chráňte svoju prácu.

Ochrana laboratórnych správ

Správa o laboratórnej práci by mala byť vypracovaná na základe STP a mala by pozostávať z týchto štrukturálnych prvkov:

titulná strana; textová časť; aplikácia: vyvinutá podľa referenčných podmienok pre softvérový produkt.

Textová časť správy by mala obsahovať tieto položky:

úloha; exekučný príkaz.

Spevnená správa o laboratórnej práci spočíva v predložení výsledkov učiteľovi vo forme súboru a preukázaní získaných zručností v odpovediach na otázky učiteľa.

testovacie otázky

Uveďte koncept modelu životného cyklu softvéru. Uveďte fázy vývoja softvéru. Čo obsahuje vyhlásenie o probléme a predprojektový výskum? Uveďte funkčné a prevádzkové požiadavky na softvérový produkt. Uveďte pravidlá pre vypracovanie technických špecifikácií. Vymenujte hlavné časti zadávacích podmienok.

Bibliografia

Bedrina S.L., Vývoj a štandardizácia softvéru. - Vladivostok: Vydavateľstvo VSUES, 2006. Blagodatskikh V.A., Volnin V.A., Poskakalov K.F. Štandardizácia vývoja softvéru. - M: Financie a štatistika, 2003. GOST 19.102-77 ESPD. Vývojové štádiá

Príloha A

Pracovné možnosti

Laboratórne práce č. 1-5 sa vykonávajú pre rovnakú možnosť.

Vyvinúť softvérový modul „Účtovanie pokroku študentov“. Softvérový modul je navrhnutý tak, aby promptne zaznamenával pokroky študentov na zasadnutí dekana, zástupcov dekanov a zamestnancov dekana. Informácie o pokroku študentov by sa mali uchovávať počas celého obdobia ich štúdia a mali by sa používať pri príprave osvedčení o absolvovaných kurzoch a dodatkov k diplomu. Vypracovať programový modul „Osobné spisy študentov“. Softvérový modul je určený na získavanie informácií o študentoch zamestnancami dekanátu, odborového výboru a personálneho oddelenia. Informácie je potrebné uchovávať počas celého obdobia vzdelávania žiakov a využívať ich pri príprave vysvedčení a správ. Vyvinúť softvérový modul „Riešenie problémov kombinatorickej optimalizácie“. Modul by mal obsahovať algoritmy na nájdenie minimálnej dĺžky cyklu (problém obchodného cestujúceho), nájdenie najkratšej cesty a nájdenie minimálneho kostry. Vyvinúť softvérový modul „Spracovanie matíc“. Modul by mal obsahovať algoritmy na vyhľadávanie súčtov a súčinov prvkov matice podľa riadkov a stĺpcov, ako aj na výpočet priemerných, minimálnych a maximálnych hodnôt v matici. Vytvorte aplikáciu Windows „Organizer“. Aplikácia je určená na zaznamenávanie, ukladanie a vyhľadávanie adries a telefónnych čísel jednotlivcov a organizácií, ako aj harmonogramov, stretnutí atď. Aplikácia je určená pre každého používateľa počítača. Vytvorte aplikáciu Windows Calculator. Aplikácia je určená pre každého používateľa a mala by obsahovať všetky aritmetické operácie (s ohľadom na priority) a pokiaľ možno (nie je to potrebné) niekoľko matematických funkcií. Vypracovať softvérový modul „Katedra“, obsahujúci informácie o pracovníkoch katedry (meno, funkcia, akademický titul, odbory, náplň práce, sociálna práca, brigády a pod.). Modul je určený pre zamestnancov personálneho oddelenia a dekanátu. Vyvinúť softvérový modul "Laboratórium" obsahujúci informácie o pracovníkoch laboratória (meno, pohlavie, vek, rodinný stav, prítomnosť detí, postavenie, akademický titul). Modul je určený pre zamestnancov odborového výboru a personálneho oddelenia. Vyviňte programový modul „Čistenie za sucha“. Pri registrácii do služby sa vyplní žiadosť, v ktorej je uvedené celé meno majiteľa, popis produktu, typ služby, dátum prijatia objednávky a cena služby. Po dokončení práce sa vytlačí potvrdenie. Vyvinúť softvérový modul „Účtovanie porušení pravidiel cestnej premávky“. Pre každé auto (a jeho majiteľa) je v databáze uložený zoznam priestupkov. Pri každom priestupku sa eviduje dátum, čas, druh priestupku a výška pokuty. Po zaplatení všetkých pokút je auto odstránené z databázy. Vyvinúť softvérový modul „Kartovnica autoshopu“, určený pre agentúrnych zamestnancov. Databáza obsahuje informácie o autách (značka, objem motora, dátum vydania atď.). Po prijatí požiadavky na nákup sa vyhľadá vhodná možnosť. Ak to tak nie je, klient je zaradený do klientskej základne a upozornený, keď sa objaví možnosť. Vyvinúť softvérový modul „Kartový súbor predplatiteľov ATS“. Súbor karty obsahuje informácie o telefónoch a ich vlastníkoch. Opravuje nedoplatky platieb (podľa predplatiteľa a času). Predpokladá sa, že hodinová platba miestnych telefónnych hovorov už bola zavedená. Vytvorte softvérový modul "Avtokassa", ktorý obsahuje informácie o dostupnosti miest na autobusových linkách. Databáza by mala obsahovať informácie o čísle letu, trase, vodičovi, type autobusu, dátume a čase odchodu, ako aj ceny leteniek. Po prijatí žiadosti o letenky program vyhľadá vhodný let. Vyvinúť softvérový modul "Kníhkupectvo", obsahujúci informácie o knihách (autor, názov, vydavateľ, rok vydania, cena). Kupujúci vyplní žiadosť o knihy, ktoré potrebuje, ak žiadne nie sú, je zaradený do databázy a upozornený, keď potrebné knihy dorazí do predajne. Vyvinúť softvérový modul „Parkovanie“. Program obsahuje informácie o značke auta, jeho majiteľovi, dátume a čase vstupu, nákladoch na parkovanie, zľavách, nedoplatkoch atď. Vytvorte softvérový modul Personálna agentúra s informáciami o voľných miestach a životopisy. Softvérový modul je určený jednak na nájdenie zamestnanca, ktorý spĺňa požiadavky manažérov spoločnosti, ako aj na nájdenie vhodnej práce.

Poznámka. Pri vývoji programu sa neobmedzujte len na funkcie uvedené vo variante, pridajte pár vlastných funkcií. Je povinné používať štrukturálne a modulárne prístupy k programovaniu.

Príloha B

Príklad 1 Vyvinúť referenčné podmienky pre softvérový produkt navrhnutý tak, aby školákom vizuálne demonštroval grafy funkcií jedného argumentu r= f(X). Vyvinutý program by mal vypočítať tabuľku hodnôt a zostaviť graf funkcií na danom segmente podľa daného vzorca a zmeniť krok argumentu a hranice segmentu. Okrem toho si program musí pamätať zadané vzorce.

1. Úvod

Tieto zadávacie podmienky sa vzťahujú na vývoj programu na triedenie jednorozmerného poľa pomocou metódy bublina, priamy výber, Shell a rýchleho triedenia určeného pre študentov stredných škôl pri štúdiu školského kurzu informatiky. 2. Nadácia pre rozvoj

Program je vypracovaný na základe učebných osnov Katedry informatiky a softvéru výpočtových systémov". Názov práce:

"Jednorozmerný program na triedenie polí".

Vykonávateľ: spoločnosť BcstSoft. Prispievatelia: ist.

3. Vymenovanie Program je určený pre školákov pri štúdiu témy „Spracovanie jednorozmerných polí“ v kurze „Informatika“. 4. Požiadavky na program alebo softvérový produkt 4.1. požiadavky na výkon 4.1.1. Program by mal poskytovať schopnosť vykonávať nasledujúce funkcie:

zadanie veľkosti poľa a samotného poľa; ukladanie polí a pamäte; výber spôsobu triedenia; zobrazenie textového popisu spôsobu triedenia; výstup výsledku triedenia.

4.1.2. Počiatočné údaje:

veľkosť poľa zadaná ako celé číslo; pole.

Organizácia vstupných a výstupných údajov.

Vstup prichádza z klávesnice. Výstup sa zobrazí na obrazovke a v prípade potreby sa vytlačí.

Požiadavky na spoľahlivosť

Poskytnite kontrolu nad vstupnými informáciami. Zabezpečte blokovanie nesprávnych akcií používateľa pri práci so systémom.

Požiadavky na skladbu a parametre technických prostriedkov.

Systém musí bežať na osobných počítačoch kompatibilných s IBM. Minimálna konfigurácia:

typ procesora Pentium alebo vyšší; množstvo pamäte s náhodným prístupom 32 MB alebo viac; množstvo voľného miesta na pevnom disku je 40 MB.

Odporúčaná konfigurácia:

typ procesora Pentium II 400; množstvo pamäte s náhodným prístupom 128 MB; množstvo voľného miesta na pevnom disku je 60 MB.

4.4. Požiadavky na kompatibilitu softvéru.
Program musí bežať pod operačnými systémami rodiny Win 32 (Windows 95/98/2000/ME/XP atď.).

Vyvinuté softvérové ​​moduly musia byť samodokumentačné, t.j. texty programu musia obsahovať všetky potrebné komentáre. Vypracovaný program by mal obsahovať základné informácie o fungovaní programu, popisoch spôsobov triedenia a tipoch pre žiakov. Sprievodná dokumentácia by mala obsahovať:

Vysvetľujúca poznámka na piatich listoch, obsahujúcich popis vývoja. Užívateľská príručka.

Príloha B

Príklad 2 Vypracovať zadávacie podmienky pre vývoj „Modulu pre automatizovaný systém prevádzkového dispečerského riadenia dodávky tepla do budov Moskovského inštitútu“.

1. Úvod

Práce sa realizujú v rámci projektu „Automatizovaný systém prevádzkového dispečerského riadenia elektrického zásobovania teplom budov Moskovského inštitútu“. 2. Nadácia pre rozvoj

Podkladom pre toto dielo je zmluva č.1234 zo dňa 10.3.2003.

Názov práce:

"Modul automatizovaného systému pre operatívne dispečerské riadenie zásobovania teplom budov Moskovského inštitútu".

Účinkujúci: OJSC "Laboratórium tvorby softvéru".

Spoločníci: nie.

3. Účel rozvoja Vytvorenie modulu na monitorovanie a rýchlu úpravu stavu hlavných parametrov poskytovania budov Moskovského inštitútu. 4. Technické požiadavky 4.1. požiadavky na výkon. 4.1.1. Zloženie vykonávaných funkcií. Vyvinutý softvér by mal poskytovať:

zber a analýza informácií o spotrebe tepla, tepla a studená voda podľa meračov tepla SA-94 na všetkých výstupoch tepla; zber a analýza informácií z riadiacich zariadení pre systémy ohrevu vzduchu a klimatizácie ako RT1 a RT2 (vývoj Katedry SMME a TC); predbežná analýza informácií s cieľom nájsť parametre v prijateľných medziach a signalizácia, keď parametre prekročia tolerančné hranice;

vydávanie odporúčaní na ďalšiu prácu;

zobrazenie aktuálneho stavu súborom parametrov - cyklicky neustále (nepretržitá prevádzka), pri zachovaní frekvencie sledovania ostatných parametrov; vizualizácia informácií o spotrebe chladiacej kvapaliny:

prúd, podobný údajom z meračov; s akumuláciou za posledný deň, týždeň, mesiac - vo forme hodinového grafu pre informácie za deň a týždeň; denná spotreba - pre informáciu za mesiac.

Pre zariadenia na ovládanie prívodného vetrania musia aktuálne informácie obsahovať číslo napájacieho systému a všetky parametre zobrazené na jeho vlastnom indikátore. Na požiadanie sa vykonajú vnútorné úpravy. Na konci vykazovaného obdobia musí systém údaje archivovať. 4.1.2. Organizácia vstupných a výstupných údajov. Prvotné dáta vstupujú do systému vo forme hodnôt zo snímačov inštalovaných v priestoroch ústavu. Títo hodnoty sú zobrazené na počítači dispečera. Po analýze prijatých informácií operátor velína nastaví potrebné parametre pre zariadenia, ktoré regulujú vykurovanie a vetranie v priestoroch. Je tiež možné automaticky nastaviť niektoré parametre pre ovládacie zariadenia. Hlavným režimom používania systému je každodenná práca. 4.2. požiadavky na spoľahlivosť. Na zabezpečenie spoľahlivosti je potrebné skontrolovať správnosť údajov prijatých zo snímačov. 4.3. Prevádzkové podmienky a požiadavky na skladbu a parametre technických prostriedkov. Na prevádzku systému musí byť pridelený zodpovedný prevádzkovateľ. Požiadavky na skladbu a parametre technických prostriedkov sú špecifikované v štádiu predbežného návrhu systému. 4.4. Požiadavky na informácie a kompatibilitu softvéru. Program musí bežať na platformách Windows 98/NT/2000.

4.5. Požiadavky na prepravu a skladovanie.

Program je dodávaný na laserovom dátovom nosiči. Programová dokumentácia je dodávaná v elektronickej aj tlačenej forme. 4.6. Špeciálne požiadavky:

softvér musí mať užívateľsky prívetivé rozhranie navrhnuté pre užívateľskú kvalifikáciu (z hľadiska počítačovej gramotnosti); vzhľadom na objem projektu sa predpokladá, že úlohy budú riešené po etapách, pričom softvérové ​​moduly vytvorené v rôznych časoch by mali poskytovať možnosť rozšírenia systému a byť navzájom kompatibilné, preto dokumentácia k prijatej prevádzke softvér by mal obsahovať úplné informácie potrebné, aby s ním programátori pracovali; programovací jazyk - podľa výberu dodávateľa by mal poskytovať možnosť integrácie softvéru s niektorými typmi periférnych zariadení (napríklad počítadlo SA-94 atď.).

5. Požiadavky na softvérovú dokumentáciu Hlavnými dokumentmi upravujúcimi vývoj budúcich programov by mali byť dokumenty Jednotného systému programovej dokumentácie (ESPD): užívateľská príručka, administrátorská príručka, popis aplikácie. 6. Technické a ekonomické ukazovatele Efektívnosť systému je určená jednoduchosťou používania systému na monitorovanie a riadenie hlavných parametrov dodávky tepla do priestorov Moskovského inštitútu, ako aj ekonomickými výhodami získanými z implementácie hardvérového a softvérového komplexu. 7. Postup pri kontrole a preberaní Potom, čo Dodávateľ odovzdá Objednávateľovi samostatný funkčný modul programu, má Objednávateľ právo modul do 7 dní otestovať. Po odskúšaní musí objednávateľ dielo pre túto etapu prevziať alebo písomne ​​uviesť dôvod odmietnutia prevzatia. V prípade odôvodneného odmietnutia sa Dodávateľ zaväzuje modul upraviť.

1. Zadávacie podmienky na dodávku zariadení pre rozvoj informačno-technologickej infraštruktúry hasičského zboru a záchrannej služby. Predmet štátnej zmluvy

   Technická úloha

   na dodávku zariadení pre rozvoj informačno-technologickej infraštruktúry hasičského útvaru a záchrannej služby.

2. Zadávacie podmienky pre komplex projektových a stavebných prác

   Technická úloha

   2.1. Za výkon prác podľa týchto zadávacích podmienok sa považuje vykonanie zo strany zhotoviteľa celého rozsahu prieskumu, projektovania a stavebné práce na rekonštrukciu (prevybavenie, sanáciu) objektu stavby na kľúč vr.

3. Zadania pre realizáciu prác na vytvorení stránky listov

   Technická úloha

   požiadavky RD 50-34.698-90 „Smernice. Informačné technológie. Súbor noriem a smerníc pre automatizované systémy.

4. Zadanie na vykonanie prieskumu technického stavu bytových domov na väčšie opravy. Slaboprúdový systém. Komunikácia, alarm, bezpečnosť

   Technická úloha

   Automatický systém požiarnej signalizácie, ako aj systém varovania a riadenia evakuácie je neoddeliteľnou súčasťou systémov podpory života budov.

5. Zadávacie podmienky Časť č. 1 Dodávka zahraničnej literatúry pre knižnicu SevKavgtu

   Technická úloha

   Postup pri stanovení ceny zákazky: cena zákazky musí zahŕňať všetky výdavky dodávateľa súvisiace s plnením zákazky, vrátane nákladov na doručenie, vyloženie literatúry do priestorov knižnice, zaplatenie DPH a úhradu

6. Zadacie podmienky pre dokumentáciu k otvorenej aukcii v elektronickej forme č. 624-ea pre právo na uzavretie

   Technická úloha

   2. Požiadavky na dobu a (alebo) rozsah poskytovania záruk za kvalitu produktu: záručná doba na dodaný produkt musí byť minimálne 24 mesiacov odo dňa uvedenia do prevádzky.

V tomto článku som sa pokúsil podrobne zvážiť problém vývoja referenčných podmienok. Téma je stará ako problém. Ale stále sa často rieši „ako to chodí“.
Ako povedal Henry Shaw: "Najviac nás znepokojujú maličkosti: je ľahšie vyhnúť sa slonovi ako muche."

Vývoj technických špecifikácií. Čo to je, prečo je to potrebné, kde začať a ako by to malo vyzerať?

O čom je tento článok?

Často dostávam otázku: „Ako vypracovať technickú úlohu pre automatizovaný systém?“. Podobná téma sa neustále diskutuje na rôznych fórach. Táto otázka je taká široká, že sa na ňu nedá v skratke odpovedať. Preto som sa rozhodol napísať na túto tému dlhý článok. V procese práce na článku som si uvedomil, že by nefungovalo dať všetko do jedného článku, pretože. vyjde to pod 50 strán a rozhodli sme sa to rozdeliť na 2 časti:

• V prvej časti" Vývoj technických špecifikácií. Čo to je, prečo je to potrebné, kde začať a ako by to malo vyzerať? Pokúsim sa podrobne odpovedať na otázky k téme, zvážiť štruktúru a účel zadávacích podmienok a poskytnúť niekoľko odporúčaní k formulácii požiadaviek.
• Druhá časť" Vývoj technických špecifikácií. Ako formulovať požiadavky? bude plne venovaná identifikácii a formulovaniu požiadaviek na informačný systém.

Najprv musíte zistiť, aká otázka skutočne zaujíma tých, ktorí sa pýtajú "Ako vypracovať technickú úlohu?" Faktom je, že prístup k vývoju technických špecifikácií bude do značnej miery závisieť od účelov, na ktoré sa to robí, a tiež od toho, kto ich bude používať. O akých možnostiach hovorím?

• 
  Komerčná organizácia sa rozhodla zaviesť automatizovaný systém. Nemá vlastnú IT službu a rozhodla sa urobiť toto: Záujemca musí vypracovať zadávacie podmienky a poskytnúť ich organizácii tretej strany na vývoj;
• Komerčná organizácia sa rozhodla zaviesť automatizovaný systém. Má vlastnú IT službu. Rozhodli sme sa urobiť toto: vypracovať referenčné podmienky, potom ich koordinovať medzi IT službami a zainteresovanými stranami a implementovať ich vlastnými silami;
• Štátna štruktúra sa rozhodla spustiť IT projekt. Všetko je tu také zablatené, veľa formalít, provízií, škrtov atď. V tomto článku sa touto možnosťou nebudem zaoberať.
• IT spoločnosť sa zaoberá službami pre vývoj a / alebo implementáciu automatizovaných systémov. Toto je najviac ťažký prípad, pretože musíte pracovať v rôznych podmienkach:
  • Klient má svojich špecialistov s vlastnými názormi, ktorí majú špecifické požiadavky na Zadanie;
  • Podmienky sú vypracované pre našich vlastných vývojárov (klientovi je to jedno);
  • Zadávacie podmienky sú vypracované na prenos na dodávateľa (t. j. skupinu programátorov, ktorí sú mimo zamestnancov spoločnosti, alebo jednotlivého špecialistu);
  • Medzi spoločnosťami a klientom dochádza k nedorozumeniu ohľadom dosiahnutého výsledku a spoločnosť si znova a znova kladie otázku: „Ako by sa mali vypracovať zadávacie podmienky?“. Posledný prípad sa môže zdať ako paradox, ale je to tak.
  • Možné sú aj iné, menej bežné možnosti;

Myslím, že teraz by mal mať čitateľ otázky:

• Prečo nemôžu byť referenčné podmienky vypracované vždy rovnakým spôsobom?
• Existujú nejaké normy, metódy, odporúčania? Kde ich zohnať?
• Kto by mal vypracovať zadávacie podmienky? Musí mať táto osoba nejaké špeciálne znalosti?
• Ako pochopiť, či sú referenčné podmienky dobre napísané alebo nie?
• Na koho náklady by sa to malo vyvíjať a je to vôbec potrebné?

Tento zoznam by mohol byť nekonečný. Hovorím tak sebavedomo z toho, že sa profesionálnemu vývoju softvéru venujem 15 rokov a otázka zadania sa objavuje v každom vývojárskom tíme, s ktorým musím spolupracovať. Dôvody sú rôzne. Nastoľujem tému vypracovania zadávacích podmienok, dobre si uvedomujem, že ju nebudem môcť prezentovať na 100% pre všetkých záujemcov o danú tému. Ale skúsim, ako sa hovorí, „všetko dať do regálov“. Tí, ktorí už poznajú moje články, vedia, že nepoužívam „copy-paste“ cudzích prác, nepretlačujem cudzie knihy, necitujem niekoľkostranové normy a iné dokumenty, ktoré si sami nájdete na internete, vydávať ich za svoje skvelé myšlienky. Stačí zadať do vyhľadávača „How to develop Terms of Reference“ a budete si môcť prečítať veľa zaujímavého, no, bohužiaľ, mnohokrát opakovaného. Tí, ktorí sú na fórach radi chytrí (skúste predsa hľadať!), Spravidla sami nerobili rozumné zadávacie podmienky a neustále citujú odporúčania GOST k tejto otázke. A tí, ktorí sa týmto problémom naozaj vážne zaoberajú, zvyčajne nemajú čas vysedávať na fórach. Mimochodom, budeme hovoriť aj o GOST. Za roky svojej práce som videl množstvo variantov technickej dokumentácie, ktoré zostavovali jednotliví odborníci, ale aj významné tímy a poradenské spoločnosti. Občas sa venujem aj takýmto činnostiam: vyhradím si čas pre seba a hľadám informácie na tému, ktorá ma zaujíma, z nezvyčajných zdrojov (také malé spravodajstvo). V dôsledku toho som musel vidieť dokumentáciu o takých monštrách ako Gazprom, Ruské železnice a mnoho ďalších zaujímavých spoločností. Samozrejme, dodržujem politiku mlčanlivosti, napriek tomu, že mi tieto dokumenty pochádzajú z verejných zdrojov alebo nezodpovednosťou konzultantov (rozhadzujú informácie po internete). Preto okamžite hovorím: Nezdieľam dôverné informácie, ktoré patria iným spoločnostiam, bez ohľadu na zdroje výskytu (profesionálna etika).

Čo je to technická úloha?

Prvá vec, ktorú teraz urobíme, je zistiť, o aký druh zvieraťa ide, „Referenčné podmienky“.

Áno, skutočne existujú GOST a normy, v ktorých sa pokúšajú regulovať túto časť činnosti (vývoj softvéru). Kedysi boli všetky tieto GOST relevantné a aktívne používané. Teraz existujú rôzne názory na relevantnosť týchto dokumentov. Niektorí tvrdia, že GOST boli vyvinuté veľmi prezieravými ľuďmi a sú stále relevantné. Iní hovoria, že sú beznádejne zastarané. Možno si teraz niekto myslel, že pravda je niekde uprostred. Odpovedal by som slovami Goetheho: „Hovorí sa, že medzi dvoma protichodnými názormi leží pravda. V žiadnom prípade! Medzi nimi je problém." Takže medzi týmito názormi nie je pravda. Pretože GOST neodhaľujú praktické problémy moderného vývoja a tí, ktorí ich kritizujú, neponúkajú alternatívy (špecifické a systémové).

Všimnite si, že GOST jasne neuvádza ani definíciu, len hovorí: „TOR pre JE je hlavný dokument, ktorý definuje požiadavky a postup na vytvorenie (vývoj alebo modernizácia - ďalšie vytváranie) automatizovaného systému v súlade s v ktorej sa realizuje vývoj JE a jej prevzatie pri uvedení do prevádzky.“

Ak niekoho zaujíma, o akých GOST hovorím, tak tu sú:

• GOST 2.114-95 jeden systém projektová dokumentácia. Technické údaje;
• GOST 19.201-78 Jednotný systém programovej dokumentácie. Technická úloha. Požiadavky na obsah a dizajn;
• GOST 34.602-89 Informačné technológie. Súbor noriem pre automatizované systémy. Referenčné podmienky pre vytvorenie automatizovaného systému.

Oveľa lepšia definícia je prezentovaná na Wikipédii (pravda o TK vo všeobecnosti a nielen pre softvér): “ Technická úloha je originálny projektový dokument technické objekt. Technická úloha ustanovuje hlavný účel rozostavaného objektu, jeho technicko-takticko-technické charakteristiky, kvalitatívne ukazovatele a technicko-ekonomické požiadavky, pokyny na dokončenie potrebných stupňov tvorby dokumentácie (projektovej, technologickej, programovej a pod.) a jej zloženie, ako napr. aj špeciálne požiadavky. Úloha ako východiskový dokument na vytvorenie niečoho nového existuje vo všetkých oblastiach činnosti, líšia sa názvom, obsahom, poradím vykonania a pod. (napríklad projektová úloha v stavebníctve, bojová úloha, domáca úloha, zmluva o literárne dielo atď.)"

A tak, ako vyplýva z definície, hlavným účelom zadávacích podmienok je formulovať požiadavky na vyvíjaný objekt, v našom prípade na automatizovaný systém.

Je to hlavné, ale jediné. Je čas vziať na seba to hlavné: dať všetko „na police“, ako som sľúbil.

Čo potrebujete vedieť o požiadavkách? Musí byť jasné, že všetky požiadavky musia byť rozdelené podľa typu a vlastností. Teraz sa naučíme, ako na to. Na oddelenie požiadaviek podľa typu nám pomôže GOST. Zoznam typov požiadaviek, ktorý je tam uvedený, je dobrým príkladom toho, aké typy požiadaviek by sa mali zvážiť. Napríklad:

• požiadavky na funkčnosť;
• Požiadavky na bezpečnosť a prístupové práva;
• Požiadavky na kvalifikáciu personálu;
• …. Atď. Môžete si o nich prečítať v spomínanom GOST (a nižšie ich budem tiež uvažovať trochu podrobnejšie).

Myslím, že je vám jasné, že dobre formulované požiadavky na funkčnosť sú kľúčom k úspešnému zadávaniu podmienok. Práve týmto požiadavkám sa venuje väčšina prác a metód, o ktorých som hovoril. Požiadavky na funkčnosť predstavujú 90 % zložitosti vypracovania zadávacích podmienok. Všetko ostatné je často „kamufláž“, ktorá je kladená na tieto požiadavky. Ak sú požiadavky zle formulované, potom bez ohľadu na to, akú krásnu kamufláž na ne dáte, úspešný projekt nebude fungovať. Áno, formálne budú splnené všetky požiadavky (podľa GOST J), TOR bol vypracovaný, schválený a podpísaný a boli naň prijaté peniaze. No a čo? A potom začína zábava: čo robiť? Ak ide o projekt na štátnu objednávku, potom nie sú žiadne problémy - existuje taký rozpočet, že sa nezmestí do žiadneho vrecka, všetko sa objasní v procese implementácie (ak existuje). Presne takto sa píli väčšina rozpočtov projektov na Štátne zákazky (vypálili „TK“, zlúčili desať miliónov, no projekt nezačali robiť. Všetky formality boli splnené, nikto nebol vinný, nové auto blízko dom. Krása!). Ale hovoríme o komerčné organizácie kde sa počítajú peniaze a je potrebný iný výsledok. Preto sa poďme zaoberať tým hlavným, ako sa rozvíjať užitočné a funkčné referenčné podmienky.

Povedal som o typoch požiadaviek, ale čo vlastnosti? Ak sa typy požiadaviek môžu líšiť (v závislosti od cieľov projektu), potom s vlastnosťami je všetko jednoduchšie, existujú 3 z nich:

1. Požiadavka musí byť pochopiteľné;
2. Požiadavka musí byť špecifické;
3. Požiadavka musí byť testované;

Navyše posledná vlastnosť je nemožná bez dvoch predchádzajúcich, t.j. je akýmsi „lakmusovým papierikom“. Ak výsledok požiadavky nemožno otestovať, potom buď nie je jasný, alebo nie je konkrétny. Zamyslite sa nad tým. Zručnosť a profesionalita spočíva v týchto troch vlastnostiach požiadaviek. V skutočnosti je všetko veľmi jednoduché. Keď na to prídeš.

Na tomto príbehu o tom, čo je referenčný rámec, by sa dalo dokončiť a prejsť k hlavnej veci: ako formulovať požiadavky. Ale nie je to všetko také rýchle. Je tu ešte jeden mimoriadne dôležitý bod:

• v akom jazyku (z hľadiska zložitosti porozumenia) by mali byť referenčné podmienky napísané?
• Má byť v ňom popísaná špecifikácia rôznych funkcií, algoritmov, dátových typov a iných technických vecí?
• A čo je technický dizajn, ktorý sa mimochodom spomína aj v GOST a ako súvisí s referenčnými podmienkami?

V odpovediach na tieto otázky je veľmi zákerná vec. Preto často vznikajú spory o dostatočnosti alebo absencii potrebného spresnenia požiadaviek, o zrozumiteľnosti dokumentu zo strany objednávateľa a zhotoviteľov, o nadbytočnosti, formáte prezentácie a pod. A kde je hranica medzi zadávacími podmienkami a technickým návrhom?

Technická úloha je dokument založený na požiadavkách formulovaný v jazyku, ktorý je Zákazníkovi zrozumiteľný (obvyklý, známy). V tomto prípade sa môže a mala by sa použiť odvetvová terminológia zrozumiteľná pre zákazníka. Nemali by existovať žiadne väzby na vlastnosti technickej implementácie. Tie. v štádiu TK je v zásade jedno, na ktorej platforme budú tieto požiadavky implementované. Aj keď existujú výnimky. Ak hovoríme o implementácii systému založeného na existujúcom softvérovom produkte, tak takáto väzba môže prebehnúť, ale len na úrovni obrazovkových formulárov, formulárov zostáv a pod. obchodný analytik. A už vôbec nie programátor (pokiaľ tieto úlohy nespojí, stáva sa to). Tie. táto osoba by mala hovoriť so zákazníkom v jazyku jeho podnikania.

Technický projekt- ide o dokument, ktorý je určený na technickú realizáciu požiadaviek formulovaných v zadávacích podmienkach. Práve tento dokument popisuje dátové štruktúry, spúšťače a uložené procedúry, algoritmy a ďalšie veci, ktoré budú potrebné technických špecialistov. Vôbec nie je potrebné, aby sa v tom zákazník vŕtal (možno takýmto pojmom nerozumie). Technický projekt áno Systémový architekt(Tu je kombinácia tejto role s programátorom celkom bežná). Alebo skôr skupina špecialistov vedená architektom. Čím väčší je projekt, tým viac ľudí pracuje na podmienkach.

Čo máme v praxi? Je smiešne sledovať, keď riaditeľa privedú na schválenie Zadanie, ktoré je plné odbornej terminológie, popisov dátových typov a ich hodnôt, štruktúry databázy atď. presadiť, snažiť sa nájsť známe slová medzi riadkami a nestratiť požiadavky reťazca biznisu. Čo, známa situácia? A ako to skončí? Takáto TOR sa spravidla schvaľuje, potom implementuje a v 80% prípadov potom vôbec nezodpovedá skutočnosti vykonanej práce, pretože veľa vecí sa rozhodli zmeniť, prerobiť, nepochopili, zle mysleli atď. atď. A potom začína séria odovzdávania. "Ale tu to nie je tak, ako to potrebujeme", ale "nebude nám to fungovať", "je to príliš komplikované", "je to nepohodlné" atď. Známy?! Takže viem, že som musel vyplniť hrbole v pravý čas.

Čo teda máme v praxi? V praxi však máme rozmazanú hranicu medzi zadávacími podmienkami a technickým návrhom. Pohybuje sa medzi TK a TP rôznymi spôsobmi. A to je zle. A ukazuje sa to preto, lebo kultúra rozvoja zoslabla. Je to čiastočne kvôli kompetencii špecialistov, čiastočne kvôli túžbe znížiť rozpočty a termíny (koniec koncov, dokumentácia trvá veľa času - to je fakt). Je tu ešte jeden dôležitý faktor, ktorý ovplyvňuje používanie Technického návrhu ako samostatného dokumentu: rýchly vývoj nástrojov rýchleho vývoja, ako aj metodík vývoja. Ale toto je samostatný príbeh, nižšie o ňom poviem pár slov.

Ďalší malý, ale dôležitý bod. Niekedy sa referenčné podmienky nazývajú malým kúskom požiadaviek, jednoduchým a zrozumiteľným. Napríklad spresniť vyhľadávanie objektu podľa nejakých podmienok, pridať stĺpec do zostavy atď. Tento prístup je celkom opodstatnený, načo si komplikovať život. Nepoužíva sa však pri veľkých projektoch, ale pri menších vylepšeniach. Povedal by som, že je to bližšie k údržbe softvérového produktu. V tomto prípade môže referenčný rámec popisovať aj konkrétne technické riešenie implementáciu požiadavky. Napríklad „Urobiť takú a takú zmenu v algoritme“, ktorá označuje konkrétny postup a konkrétnu zmenu pre programátora. To je prípad, keď je hranica medzi zadávacími podmienkami a technickými projektmi úplne vymazaná, pretože nie je ekonomicky možné nafúknuť papierovanie tam, kde to nie je potrebné, a vytvorí sa užitočný dokument. A je to správne.

Naozaj potrebujete technickú špecifikáciu? A čo inžiniersky projekt?

Som prehriaty? Je to vôbec možné bez referenčné podmienky? Predstavte si možno (presnejšie, vyskytuje sa) a tento prístup má veľa nasledovníkov a ich počet sa zvyšuje. Spravidla potom, čo mladí špecialisti čítajú knihy o Scrum, Agile a ďalších technológiách rýchleho rozvoja. V skutočnosti sú to úžasné technológie a fungujú, len doslova nehovoria „nie je potrebné robiť technické úlohy“. Hovorí sa „minimum papierovania“, najmä zbytočných, bližšie k zákazníkovi, viac špecifikácií a rýchlejšie výsledky. Ale fixovanie požiadaviek nikto nezrušil a je to tam jasne uvedené. Práve tam sú požiadavky stanovené na základe troch úžasných vlastností, o ktorých som hovoril vyššie. Len vedomie niektorých ľudí je usporiadané tak, že ak sa dá niečo zjednodušiť, tak to zjednodušíme do úplnej absencie. Ako povedal Einstein" Urobte to čo najjednoduchšie, ale nie jednoduchšie." . Zlaté slová sa hodia ku všetkému. Takže to Technická úloha potrebné, inak sa nedočkáte úspešného projektu. Ďalšou otázkou je, ako skladať a čo tam zaradiť. Vo svetle metodológií rýchleho vývoja sa musíte zamerať iba na požiadavky a všetku „kamufláž“ možno zahodiť. V podstate s týmto súhlasím.

A čo technický projekt? Tento dokument je veľmi užitočný a nestratil svoj význam. Navyše sa bez toho často jednoducho nedá robiť. Najmä pokiaľ ide o outsourcing vývojových prác, t.j. na báze outsourcingu. Ak to neurobíte, existuje riziko, že sa dozviete veľa o tom, ako by mal vyzerať systém, ktorý máte na mysli. Má ho zákazník spoznať? Ak chce prečo nie, ale trvať na tom a tvrdiť tento dokument netreba, bude len zdržovať a prekážať pri práci. Navrhnúť systém do najmenších detailov je takmer nemožné. V tomto prípade budete musieť priebežne vykonávať zmeny v technickom dizajne, čo si vyžaduje veľa času. A ak je organizácia silne byrokratizovaná, potom vo všeobecnosti nechajte všetky nervy tam. Práve o redukcii tohto druhu dizajnu sa hovorí v moderných metodológiách rýchleho vývoja, ktoré som spomenul vyššie. Mimochodom, všetky sú založené na klasickom XP (extreme programming) prístupe, ktorý je už asi 20 rokov starý. Vytvorte teda kvalitné zadávacie podmienky, zrozumiteľné pre zákazníka a použite technický návrh ako interný dokument pre vzťah medzi architektom systému a programátormi.

Zaujímavý detail o technickom dizajne: niektoré vývojové nástroje usporiadané podľa princípu zamerania predmetu (ako napr. 1C a podobne) naznačujú, že dizajn (rozumej proces dokumentácie) je potrebný len pre skutočne ťažké oblasti, kde je potrebná interakcia medzi celými subsystémami. V najjednoduchšom prípade, napríklad na vytvorenie referenčnej knihy, dokumentu, postačujú iba správne formulované obchodné požiadavky. Svedčí o tom obchodná stratégia tejto platformy z hľadiska vzdelávania špecialistov. Ak sa pozriete na skúšobný lístok špecialistu (tak sa tomu hovorí, a nie „programátora“), uvidíte, že existujú iba obchodné požiadavky a ako ich implementovať do programovacieho jazyka je úlohou špecialista. Tie. tú časť úlohy, ktorú má technický projekt vyriešiť, musí odborník vyriešiť „v hlave“ (hovoríme o úlohách strednej zložitosti) a tu a teraz, podľa určitých štandardov vývoja a dizajnu, ktoré sú opäť vytvorila spoločnosť 1C pre svoju platformu. Teda z dvoch špecialistov, ktorých výsledok práce vyzerá rovnako, môže jeden skúšku absolvovať a druhý nie, pretože. hrubo porušil vývojové štandardy. To znamená, že sa samozrejme predpokladá, že špecialisti musia mať takú kvalifikáciu, aby mohli sami navrhovať typické úlohy bez zapojenia systémových architektov. A tento prístup funguje.

Pokračujme v štúdiu otázky: "Aké požiadavky by mali byť zahrnuté v podmienkach zadania?"

Formulácia požiadaviek na informačný systém. Štruktúra mandátu

Hneď si to ujasnime: budeme hovoriť o formulácii požiadaviek na informačný systém, t.j. za predpokladu, že práca na vývoji obchodných požiadaviek, formalizácia obchodných procesov a všetky predchádzajúce konzultačné práce už boli dokončené. Samozrejme, v tejto fáze je možné vykonať určité vylepšenia, ale iba vylepšenia. Samotný projekt automatizácie nerieši obchodné problémy – majte to na pamäti. Toto je axióma. Niektorí manažéri sa to z nejakého dôvodu snažia vyvrátiť a veria, že ak si program kúpia, príde poriadok v chaotickom biznise. Ale koniec koncov, axióma je axióma, ktorá nevyžaduje dôkaz.

Ako pri každej činnosti, aj formuláciu požiadaviek možno (a treba) rozdeliť na etapy. Všetko má svoj čas. Toto je ťažká intelektuálna práca. A ak sa s ním bude zaobchádzať s nedostatočnou pozornosťou, výsledok bude primeraný. Podľa odborných odhadov môžu náklady na vypracovanie zadávacích podmienok predstavovať 30 – 50 %. som toho istého názoru. Aj keď 50 je možno priveľa. Napokon, zadávacie podmienky nie sú posledným dokumentom, ktorý sa má vypracovať. Nesmie chýbať ani technické prevedenie. Táto odchýlka je spôsobená rôznymi automatizačnými platformami, prístupmi a technológiami, ktoré projektové tímy používajú počas vývoja. Napríklad, ak hovoríme o vývoji v klasickom jazyku, akým je C++, potom je detailný technický návrh nevyhnutný. Ak hovoríme o implementácii systému na platforme 1C, potom je situácia s dizajnom trochu iná, ako sme videli vyššie (hoci pri vývoji systému od nuly je navrhnutý podľa klasickej schémy).

Napriek tomu, že vyhlásenie o požiadavkách je hlavnou súčasťou zadávacích podmienok a v niektorých prípadoch sa stáva jedinou časťou TOR, mali by ste venovať pozornosť skutočnosti, že ide o dôležitý dokument a mal by byť vypracovaný podľa toho. kde začať? Najprv musíte začať s obsahom. Zostavte obsah a potom ho začnite rozbaľovať. Ja osobne robím toto: najprv načrtnem obsah, opíšem ciele, všetky úvodné informácie a potom sa chopím hlavnej časti – formulácie požiadaviek. Prečo nie naopak? Neviem, je to pre mňa pohodlnejšie. Jednak ide o oveľa menšiu časť času (v porovnaní s požiadavkami), jednak sa pri popisovaní všetkých úvodných informácií naladíte na to hlavné. No kto má rád. Postupom času si vytvoríte vlastnú šablónu zadávacích podmienok. Na začiatok odporúčam brať ako obsah presne ten, ktorý je popísaný v GOST. Je to skvelé pre obsah! Potom vezmeme a začneme popisovať každú časť, pričom nezabudneme na odporúčania pre nasledujúce tri vlastnosti: zrozumiteľnosť, špecifickosť a testovateľnosť. Prečo na tom tak trvám? Viac o tom v ďalšej časti. A teraz navrhujem taktne prejsť tie body TK, ktoré sú odporúčané v GOST.

1. všeobecné informácie;
2. účel a ciele tvorby (vývoja) systému;
3. charakteristiky objektov automatizácie;
4. Požiadavky na systém;
5. zloženie a obsah práce na tvorbe systému;
6. postup kontroly a akceptácie systému;
7. požiadavky na skladbu a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky;
8. požiadavky na dokumentáciu;
9. rozvojové zdroje.

Celkom 9 sekcií, z ktorých každá je rozdelená na podsekcie. Zoberme si ich pekne po poriadku. Pre pohodlie uvediem všetko vo forme tabuľky pre každú položku.

Časť 1. všeobecné informácie.

	Čo s tým v praxi
úplný názov systému a jeho symbol;	Tu je všetko jasné: napíšeme, ako sa systém bude volať, jeho krátky názov
tematická šifra alebo šifra (číslo) zmluvy;	Toto nie je relevantné, ale v prípade potreby môžete špecifikovať.
názov podnikov (združení) vývojára a zákazníka (používateľa) systému a ich podrobnosti;	uveďte, kto (aké organizácie) bude na projekte pracovať. Môžete tiež určiť ich úlohy. Vo všeobecnosti môžete túto sekciu vymazať (skôr formálne).
zoznam dokumentov, na základe ktorých je systém vytvorený, kým a kedy boli tieto dokumenty schválené;	Užitočná informácia. Tu stojí za to uviesť regulačnú a referenčnú dokumentáciu, ktorú ste dostali, aby ste sa oboznámili s určitou časťou požiadaviek
plánované termíny začiatku a ukončenia prác na vytvorení systému;	Načasovanie si praje. Niekedy o tom píšu v TOR, ale častejšie sú takéto veci opísané v zmluvách o dielo
informácie o zdrojoch a postupe financovania diela;	Podobne ako v predchádzajúcom odseku o načasovaní. Relevantnejšie pre vládne nariadenia (pre štátnych zamestnancov)
postup pri formalizácii a prezentovaní výsledkov práce zákazníkovi na vytvorení systému (jeho častí), na výrobe a úprave jednotlivých prostriedkov (hardvér, softvér, informácie) a softvérových a hardvérových (softvérových a metodických) komplexov systém.	Nevidím potrebu tohto odseku, tk. požiadavky na dokumentáciu sa robia samostatne a okrem toho existuje celá samostatná časť „Postup kontroly a preberania“ systému.

Sekcia 2. účel a ciele vytvorenia (vývoja) systému.

	Čo s tým v praxi
Účel systému	Na jednej strane je vymenovanie jednoduché. Ale rád by som bol konkrétny. Ak napíšete niečo ako „kvalitná automatizácia riadenia zásob vo firme X“, tak o výsledku môžete po jeho dokončení dlho diskutovať, a to aj bez ohľadu na dobré znenie požiadaviek. Pretože Zákazník si vždy môže povedať, že kvalitou myslel niečo iné. Vo všeobecnosti sa nervy môžu navzájom veľmi pokaziť, ale prečo? Je lepšie okamžite napísať niečo také: "Systém je navrhnutý na vedenie skladovej evidencie v spoločnosti X v súlade s požiadavkami stanovenými v týchto podmienkach."
Ciele vytvorenia systému	Ciele – to je určite dôležitá časť. Ak to zapneme, tak tieto ciele musíme vedieť sformulovať. Ak máte problémy s formulovaním cieľov, je lepšie túto časť úplne vylúčiť. Príklad neúspešného cieľa: "Zabezpečiť rýchle papierovanie manažérom." čo je rýchle? To sa potom dá donekonečna dokazovať. Ak je to dôležité, potom je lepšie preformulovať tento cieľ takto: "Manažér predaja by mal byť schopný vystaviť doklad" Predaj tovaru "zo 100 riadkov za 10 minút." Takýto cieľ sa môže objaviť, ak sa tomu napríklad momentálne manažér venuje približne hodinu, čo je pre túto spoločnosť priveľa a je to pre nich dôležité. V tejto formulácii sa už cieľ prelína s požiadavkami, čo je celkom prirodzené, pretože. pri rozšírení stromu cieľov (t.j. ich rozdelení na menšie súvisiace ciele) sa tak či tak priblížime k požiadavkám. Preto by ste sa nemali nechať uniesť. Vo všeobecnosti je schopnosť identifikovať ciele, formulovať ich, zostavovať strom cieľov úplne samostatnou témou. Pamätajte na hlavnú vec: ak viete ako - píšte, ak si nie ste istí - nepíšte vôbec. Čo sa stane, ak si nestanovíte ciele? Budete pracovať podľa požiadaviek, to sa často praktizuje.

Časť 3. Charakteristika objektov automatizácie.

Časť 4 Systémové požiadavky

	Čo s tým v praxi
Všeobecné systémové požiadavky. GOST dešifruje zoznam takýchto požiadaviek: požiadavky na štruktúru a fungovanie systému; požiadavky na počet a kvalifikáciu personálu systému a spôsob jeho práce; ukazovatele destinácie; požiadavky na spoľahlivosť; bezpečnostné požiadavky; požiadavky na ergonómiu a technickú estetiku; požiadavky na prepravovateľnosť mobilných AS; prevádzkové požiadavky, údržbu, oprava a skladovanie komponentov systému; požiadavky na ochranu informácií pred neoprávneným prístupom; požiadavky na bezpečnosť informácií v prípade nehôd; požiadavky na ochranu pred vplyvom vonkajších vplyvov; požiadavky na čistotu patentov; požiadavky na štandardizáciu a unifikáciu;	Napriek tomu, že hlavná bude samozrejme sekcia so špecifickými požiadavkami (funkčná), môže mať aj táto sekcia veľký význam(a vo väčšine prípadov má). Čo môže byť dôležité a užitočné: Kvalifikačné požiadavky . Je možné, že vyvíjaný systém bude vyžadovať preškolenie špecialistov. Môže to byť ako používatelia budúci systém a IT špecialistov, ktorí budú potrební na jej podporu. Nedostatočná pozornosť venovaná tejto problematike sa často vyvinie do problémov. Ak je kvalifikácia existujúceho personálu jednoznačne nedostatočná, je lepšie predpísať požiadavky na organizáciu školenia, školiaci program, termíny atď. Požiadavky na ochranu informácií pred neoprávneným prístupom. Nie sú tu žiadne komentáre. Presne toto sú požiadavky na riadenie prístupu k údajom. Ak sú takéto požiadavky plánované, potom je potrebné ich napísať oddelene, čo najpodrobnejšie podľa rovnakých pravidiel ako funkčné požiadavky (zrozumiteľnosť, špecifickosť, testovateľnosť). Preto môžu byť tieto požiadavky zahrnuté do časti s funkčnými požiadavkami. Požiadavky na štandardizáciu. Ak existujú nejaké vývojové štandardy, ktoré sa vzťahujú na projekt, môžu byť zahrnuté do požiadaviek. Takéto požiadavky spravidla iniciuje IT služba Zákazníka. Napríklad spoločnosť 1C má požiadavky na návrh programového kódu, dizajn rozhrania atď.; Požiadavky na štruktúru a fungovanie systému. Tu možno opísať požiadavky na vzájomnú integráciu systémov, uvádza sa popis všeobecnej architektúry. Častejšie sú požiadavky na integráciu uvedené vo všeobecnosti v samostatnej časti alebo dokonca v samostatnom referenčnom rámci, pretože tieto požiadavky môžu byť dosť zložité. Všetky ostatné požiadavky sú menej dôležité a možno ich vynechať. Podľa mňa len zaťažujú dokumentáciu a sú málo praktické. A opísať požiadavky na ergonómiu formou všeobecných požiadaviek je veľmi ťažké, lepšie je preniesť ich na funkčné. Napríklad môže byť sformulovaná požiadavka „Získajte informácie o cene produktu stlačením jediného tlačidla“. Tá má podľa mňa stále bližšie k špecifickým funkčným požiadavkám, hoci sa to týka ergonómie.
Požiadavky na funkcie (úlohy) vykonávané systémom	Tu je to úplne hlavný a kľúčový bod, ktorý rozhodne o úspechu. Aj keď je všetko ostatné urobené perfektne a táto sekcia je na „3“, výsledok projektu bude prinajlepšom „3“, alebo dokonca projekt zlyhá. Práve tým sa budeme podrobnejšie zaoberať v druhom článku. V tomto bode platí „pravidlo troch vlastností požiadaviek“, o ktorom som hovoril.
Požiadavky na typy kolaterálu GOST rozlišuje tieto typy: Matematické informačný Jazykovedné softvér Technická Metrologické Organizačné metodický a ďalšie…	Na prvý pohľad sa môže zdať, že tieto požiadavky nie sú dôležité. To platí pre väčšinu projektov. Ale nie vždy. Kedy opísať tieto požiadavky: Nebolo prijaté žiadne rozhodnutie o tom, v akom jazyku (alebo platforme) bude vývoj prebiehať; Systém podlieha požiadavkám na viacjazyčné rozhranie (napríklad ruština / angličtina) Pre fungovanie systému je potrebné vytvoriť samostatný útvar alebo prijať nových zamestnancov; Aby systém fungoval, musí Zákazník prejsť zmenami pracovných metód a tieto zmeny musia byť špecifikované a naplánované; Predpokladá sa integrácia s akýmkoľvek zariadením a sú naň kladené požiadavky (napríklad certifikácia, kompatibilita atď.) Možné sú aj iné situácie, všetko závisí od konkrétnych cieľov projektu.

Sekcia 5. Zloženie a obsah práce na vytvorení systému

Časť 6. Postup kontroly a akceptácie systému

Čo s tým v praxi

Druhy, zloženie, rozsah a metódy skúšania systému a jeho komponentov (druhy skúšok podľa aktuálnych noriem platných pre vyvíjaný systém); Všeobecné požiadavky na preberanie diela po etapách (zoznam zúčastnených podnikov a organizácií, miesto a načasovanie), postup odsúhlasovania a schvaľovania akceptačnej dokumentácie;

Ale ani prítomnosť testovateľných požiadaviek nemusí pri dodaní systému stačiť, ak nie je jasne stanovený postup na prijatie a odovzdanie práce. Napríklad bežná pasca: systém je hotový, je plne funkčný, ale Zákazník z nejakého dôvodu nie je pripravený v ňom pracovať. Tieto dôvody môžu byť akékoľvek: raz sa zmenili ciele, niekto skončil atď. A hovorí: „Keďže ešte nepracujeme v nový systém, takže si nemôžeme byť istí, že to funguje. Naučte sa teda správne identifikovať fázy práce, spôsoby kontroly výsledkov týchto fáz. Okrem toho by takéto metódy mali byť zákazníkovi jasné od samého začiatku. Ak sú stanovené na úrovni zadávacích podmienok, potom ich môžete v prípade potreby kedykoľvek kontaktovať a dokončiť prácu s prevodom.

Časť 7. Požiadavky na skladbu a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky

	Čo s tým v praxi
Uvedenie informácií vstupujúcich do systému (v súlade s požiadavkami na informačnú a jazykovú podporu) do podoby vhodnej na spracovanie pomocou počítača;	Veľmi dôležitý bod. Napríklad, aby systém fungoval podľa plánu, môže byť potrebné použiť ľubovoľné priemyselné alebo celoruské adresáre a klasifikátory. Tieto adresáre sa musia nejakým spôsobom objaviť v systéme, musia byť aktualizované a správne používané. Môžu existovať akékoľvek iné pravidlá pre zadávanie informácií prijaté spoločnosťou (alebo plánované). Napríklad informácie o zmluve sa kedysi zadávali ako textový riadok v ľubovoľnej forme, no teraz sa vyžaduje samostatne číslo, zvlášť dátum atď. Takýchto stavov môže byť veľa. Niektoré z nich možno vnímať s odporom personálu, preto je lepšie všetky takéto prípady evidovať na úrovni požiadaviek na poradie zadávania údajov
Zmeny, ktoré sa majú vykonať v objekte automatizácie Vytvorenie podmienok pre fungovanie objektu automatizácie, za ktorých je zaručený súlad vytvoreného systému s požiadavkami obsiahnutými v TOR	Akékoľvek zmeny, ktoré môžu byť potrebné. Spoločnosť napríklad nemá lokálnej sieti, zastaraná flotila počítačov, na ktorých systém nebude fungovať. Možno niektoré potrebné informácie spracované na papieri a teraz ho treba zadať do systému. Ak sa tak nestane, niektorý modul nebude fungovať atď. Možno sa niečo zjednodušilo, ale teraz to treba vziať do úvahy podrobnejšie, takže niekto musí zbierať informácie podľa určitých pravidiel. Tento zoznam môže byť dlhý, pozrite sa na konkrétny prípad vášho projektu.
Vytvorenie pododdielov a služieb potrebných pre fungovanie systému; Načasovanie a postup pre personálne obsadenie a školenie personálu	Už sme o tom hovorili. Možno sa systém vyvíja pre novú štruktúru alebo typ činnosti, ktorá predtým neexistovala. Ak nie je vhodný personál a dokonca ani vyškolený, systém nebude fungovať, bez ohľadu na to, ako kompetentne nie je vybudovaný.

Časť 8 Požiadavky na dokumentáciu

Čo s tým v praxi

Zoznam sád a typov dokumentov, ktoré majú byť vyvinuté, odsúhlasený vývojárom systému a zákazníkom

Úplná dokumentácia je dôležitou súčasťou výsledku. Všetci vieme, že dokumentovať niečo je náročná práca. Preto je potrebné vopred prediskutovať so Zákazníkom, aké typy dokumentácie budú vypracované, ako budú vyzerať (obsah a najlepšie príklady). Zvážte, ako budú prezentované používateľské príručky. Možno, že zákazník prijal firemné štandardy, takže ho musíte kontaktovať. Ignorovanie požiadaviek na dokumentáciu veľmi často vedie k najneočakávanejším dôsledkom na projekty. Napríklad, všetko je hotové a všetko funguje. Používatelia tiež vedia, ako pracovať. Vôbec sme sa nedohodli na dokumentácii a nerozprávali. A zrazu pri odovzdávaní diela sa vás jeden z vrcholových manažérov objednávateľa, ktorý sa na projekte ani nezúčastnil, ale podieľa sa na preberaní diela, pýta: „Kde sú návody na použitie?“ A začne vás presviedčať, že nebolo potrebné súhlasiť s dostupnosťou používateľských manuálov, to sa údajne predpokladá „samo od seba“. A to je všetko, nechce ti vziať prácu. Na koho náklady vypracujete usmernenia? Tomuto háku prepadlo už veľa tímov.

Časť 9 Zdroje rozvoja

	Čo s tým v praxi
Je potrebné uviesť dokumenty a informačné materiály (štúdia uskutočniteľnosti, správy o ukončených výskumných prácach, informačné materiály o domácich, zahraničných analógových systémoch a pod.), na základe ktorých bol TOR vyvinutý a ktoré by sa mali použiť pri tvorbe systému.	Úprimne povedané, je to bližšie k textom. Najmä keď sa hovorí o ekonomickom efekte a iných veciach, ktoré sa takmer nedajú objektívne vypočítať. Tie. Ak je to možné, potom to bude skôr na papieri, čisto teoreticky. Preto je lepšie odkázať jednoducho na správu z prieskumu, požiadavky kľúčových osôb.

A tak sme zvážili všetky časti, ktoré môžu byť zahrnuté do podmienok. „Môžem“, nie „Musím“ práve preto, že na dosiahnutie výsledku musí byť vypracovaný akýkoľvek dokument. Ak je vám teda zrejmé, že nejaký samostatný úsek vás k výsledku nepriblíži, tak to nepotrebujete a nemusíte nad tým strácať čas.

Ale bez hlavnej veci: funkčných požiadaviek nie je úplný ani jeden kompetentný referenčný rámec. Chcem poznamenať, že v praxi sa s takýmito referenčnými podmienkami stretávame a ako! Existujú postavy, ktoré dokážu zriediť vody vo všetkých častiach, opísať všeobecné požiadavky vo všeobecnosti a dokument sa ukáže ako veľmi závažný a je v ňom veľa inteligentných slov a dokonca sa môže páčiť aj zákazníkovi to (t.j. schváli to). Ale na tom sa možno nedá pracovať, t.j. má malé praktické využitie. Vo väčšine prípadov sa takéto dokumenty rodia, keď potrebujete získať veľa peňazí špeciálne za referenčné podmienky a musíte to urobiť rýchlo a bez ponorenia sa do detailov. A hlavne ak je známe, že veci ďalej nepôjdu, alebo to urobia úplne iní ľudia. Vo všeobecnosti len pre vývoj rozpočtu, najmä štátu.

V druhom článku sa budeme baviť len o časti 4 „Systémové požiadavky“ a konkrétne sformulujeme požiadavky z dôvodu prehľadnosti, špecifickosti a testovateľnosti.

Prečo by požiadavky mali byť jasné, konkrétne a testovateľné.

Pretože prax ukazuje: na začiatku sa väčšina technických špecifikácií, ktoré vyvinuli špecialisti, buď ukáže ako nepotrebná (nezodpovedá realite), alebo sa stane problémom pre toho, kto by ich mal implementovať, pretože Zákazník začína manipulovať s nekonkrétnymi podmienkami a požiadavkami. Uvediem pár príkladov, s akými frázami som sa stretol, k čomu to viedlo a potom sa pokúsim dať odporúčania, ako sa takýmto problémom vyhnúť.

Typ požiadavky

Nesprávna formulácia