Jak napsat specifikaci. Popište, co bude na každé stránce. Cenu vyplníme technickou specifikací

Od autora: Jak psát zadávacích podmínek (TOR) pro rozvoj webu? Téma je poměrně obsáhlé a v rámci jedné poznámky je těžké ho na 100% (pokud je to vůbec možné) rozebrat. Ale obecná ustanovení, o tom, co je třeba vzít v úvahu a na co si dát při sestavování webu pozor, se pokusím uvést dostatečně podrobně.

Tedy zadání pro vývoj webu

Zadávací podmínky jsou vypracovány pro vývojáře. Na CK je nutné odkázat při uzavírání smlouvy mezi objednatelem a zhotovitelem. Měla by být stanovena odpovědnost za nesplnění nebo nesprávné plnění bodů a termínů na obou stranách. Ale to nejdůležitější (podle mě), pro co je technický úkol vytvořen, je pro urychlení procesu vývoje projektu.

Pojďme analyzovat tento příklad:

Předpokládejme, že potřebujete kalendář někde na straně vašeho webu. Vypadalo to jako maličkost. Čím více ale popíšete jeho funkčnost, tím rychleji získáte výsledek.

Tady to trochu vysvětlím. Existuje kalendář, který jednoduše zobrazuje čísla dnů v týdnu aktuálního měsíce. A je zde možnost procházet měsíce. K dispozici je kalendář s možností listování v měsících a letech.

Řekněme, že chcete nejnovější verzi (s možností procházet měsíce a roky) se zvýrazněným aktuálním datem. V podmínkách zadání jste uvedli: "je potřeba kalendář v postranním panelu." Udělají vám první možnost (jednoduše zobrazí čísla pro dny v týdnu aktuálního měsíce).

Co máme. Zhotovitel splnil položku TK, ale vy jste chtěli něco úplně jiného. Zdá se, že vše je v souladu, nikdo za to nemůže, nedošlo ke konfliktu, ale to nejdůležitější je ztraceno čas a peníze.

Toto je příklad pouze banálního kalendáře.

A kdybyste museli předělat něco vážnějšího, jehož vyřízení zabere více než půl dne, jako je tomu u kalendáře? Dodavatel si s vámi hraje, kdy by mohl dokončit váš projekt a začít nový.

Proto, než více popíšete funkčnost každého modulu, tím rychleji získáte výsledek. To by mělo zajímat obě strany.

Jaké položky se obvykle skládají z technického úkolu?

Představme si, že jste majitelem nějaké společnosti nebo firmy. Vaše společnost se zabývá výrobou jakéhokoli produktu a jeho realizací. Máte kupce. Spolupracujete s prodejci (obchody a internetové obchody), servisními středisky, spotřebiteli produktů. Nebo děláte zdroj pro takovou společnost a potřebujete napsat technický úkol.

Bez ohledu na to, v jaké roli jste, první věc, kterou musíte udělat před kompilací podmínky zadání vytvořit design webových stránek znamená studovat strukturu organizace, co dělá, nomenklaturu, vlastnosti a obecně vše, co souvisí s produkty a společností. Od toho, jak hluboko se zákazník ponoří do podstaty toho, co se děje v podniku, závisí na tom, co se stane na zdroji. Úkol je zde tedy vzájemný: zákazník by měl o podniku vyprávět co nejpodrobněji a umělec by měl důkladně porozumět podstatě toho, co se děje.

I když sami napíšete zadání pro firmu, která bude váš projekt dělat, není špatné si to vše spočítat na kus papíru.

Pojďme k bodům.

Popis

Zde můžete napsat pár větami o společnosti, co dělá. Udělejte něco jako úvod.

Pro koho je cílová skupina:

potenciální kupce

prodejci produktů (obchody, internetové obchody)

servisní střediska

partneři (firmy)

spotřebitelé produktu (ti, kteří již koupili)

Proč potřebujete web:

Pro posílení image společnosti

Pro zvýšení prodeje

Pro pohodlí zákazníka

Firemní

Webové stránky - vizitka

Internetový obchod

Jazykové verze:

Angličtina

Stránka musí vyřešit nějaké problémy. V souladu s tím se posouváme dále podél cílů a cílů.

Záměry a cíle

V této části zadání procházíme celou cílovou skupinu a popisujeme okruh úkolů, které by pro ně měl web řešit.

Potenciální kupci produktů.

Cílová: přilákat více kupujících a přesvědčit je k prvnímu nákupu, pomoci při výběru.

Úkoly k řešení:

Poskytujte vysoce kvalitní a komplexní informace o produktech, Doplňkové služby, záruka, servis, způsoby výběru.

Odešlete informace o prodejnách

Odešlete informace o maloobchodě

Poskytněte příležitost položit otázku prostřednictvím organizace online konzultací potenciálních kupujících specialisty podniku o výběru, nákupu produktů.

Procházíme tak celou cílovou skupinu. Dále popisujeme cíle a záměry pro prodejce produktů (obchody, internetové obchody), servisní střediska, partnery (firmy), spotřebitele produktů. Tedy to, co by měl web dělat konkrétně pro každý z nich.

Nyní si uvedeme seznam modulů.

Funkčnost webu

Chcete-li uvést funkce, musíte se rozhodnout, co potřebuje:

Je nutná registrace

Potřebuji uzavřenou sekci (pouze pro registrované uživatele)

Potřebujete formulář zpětná vazba

Atd. a tak dále.

Moderní trendy a přístupy ve vývoji webu

Naučte se algoritmus pro rychlý růst od nuly při vytváření webových stránek

Po tom všem, co bylo popsáno, se dostáváme k tomu nejdůležitějšímu a nejzajímavějšímu. Všechna ta výše odvedená práce je samozřejmě velmi důležitá, ale teď je to ještě „žhavější“.

Popis funkčnosti

Na tento moment víme, pro koho je web určen, jaké cíle a úkoly by měl plnit, jeho doplňkové funkčnost.

Nastal čas, kdy je potřeba přenést všechny shromážděné informace do systému a krásně je dát. Chcete-li si tento úkol usnadnit a nevynalézat znovu kolo, můžete se podívat na zdroje na podobná témata. Naučte se od nich něco, prohlédněte si a otestujte jejich funkčnost a pokuste se vylepšit to, co se vám na vašem projektu zdálo nepohodlné. V zásadě se můžete na stránky podobných předmětů (a pokud nemáte zkušenosti, pak dokonce musíte) podívat na samém začátku přípravy zadání.

Doporučuji začít s položkami menu. Potřebuje zobrazit hlavní stránky a zajistit, aby si každý z návštěvníků rychle našel informace pro sebe. A návštěvníci jsou naši cílové publikum. Nabídka bude obsahovat mnoho položek, bude tedy ve formě rozevíracího seznamu.

Nejprve musíte říct o společnosti. Mohou zde být stránky o společnosti, historii společnosti, kontakty, recenze.

Samozřejmostí by měla být položka nabídky „produkty“ s podpoložkami „katalog produktů“, „vydání“, „recenze produktu“.

Obecně doufám, že je jasné, jak malovat. Uvedu finální verzi možného menu:

O společnosti

historie společnosti

kontakty

produkty

Produktový katalog

recenze produktů

servisní oddělení

záruční servis

pozáruční servis

spotřebitel

nákup a doručení

použití

o službě

obchody a internetové obchody

fotografie produktů

FAQ

servisní střediska

Jak se stát servisní středisko

FAQ

partnery

pozvání ke spolupráci

FAQ

Nějak jsme vymysleli menu. Nyní je potřeba popsat, co bude na každé stránce a jak to celé funguje jako celek. Plus poskytnout hrubé rozložení. Může být nakreslen na kus papíru tužkou, naskenován a připojen k zadání. Jediné, co řeknu, je, že nekladou meze fantazii designéra, skicu v samotném obecný pohled.

Tato část se mění v závislosti na tom, jak chcete, aby vaše stránka vypadala. Možná nepotřebujete tolik bannerů nahoře, možná budete muset uvést kontakty nahoře (adresa, telefon, fax), třeba ve formě ikon „mapa webu“, „domů“, „kontakty“. Možná nepotřebujete novinky na levé straně, ale na levé straně zobrazíte „propagace a vydání“.

Hlavní je nyní popsat logiku práce.

Operační logika

Popíšu na základě obrázku výše.

Nejlepší část(záhlaví) zůstává na každé stránce stejné. Newsfeed je viditelný pouze na domovská stránka. Na vedlejších stránkách vlevo zobrazujeme podpoložky nabídky položky, ve které se právě nacházíme (pokud jsme například na stránce „servis“, pak zobrazujeme odkazy na „záruční servis“, „příspěvek“ -záruční servis"). V souladu s tím vedou přechody na těchto odkazech na odpovídající stránky. Zde pod podpoložkami vlevo zobrazujeme údaje pro kontaktování online konzultantů (Skype, ICQ). Blokovat propagační akce a verze zůstávají na každé stránce. Zápatí (zápatí) je na každé stránce zobrazeno stejně.

Přibližně tak je popsána obecná logika práce.

Nyní v naší TK pro vývoj webu podrobně popisujeme každý určený blok webu. Například „Zprávy“.

"Zprávy" z 10 poslední zprávy. Každá novinka by měla obsahovat název zprávy, datum vydání, stručný začátek zprávy (4-5 řádků) a odkaz „přečíst celé“. Kliknutím na odkaz „číst celé“ se dostaneme na stránku novinek. Namísto hlavního obsahu se zobrazí zpráva, která byla zasažena. Obsahuje také název novinky, datum vydání. Zobrazí se také vlevo zpravodajský kanál. Novinky z předchozích měsíců a let jsou archivovány. Tedy pod novinkami pro aktuální měsíc zobrazit "archiv pro (takový a takový měsíc nebo rok)". Když kliknete na odkaz "archiv za (takový měsíc nebo rok)" dolů, vypadne seznam novinek za příslušný měsíc/rok.

Takto popisujeme činnost každého bloku. Nezapomeňme na pouzdro s kalendářem. A hlavně je potřeba namalovat dílo katalogu produktů. Zde vám dávám úkol: zkuste se zamyslet a popsat, jak bude katalog fungovat. Zašlete své možnosti e-mailem. Nejlepší zveřejníme.

Co jiného by mělo být? Bylo by hezké uvést kompatibilitu.

Kompatibilita

V tomto odstavci našich podmínek pro vytvoření webu uvádíme, na kterých operační systémy a ve kterých prohlížečích by měl web vypadat stejně dobře. V jaké verzi, v jakém jazyce by měl být napsán. Jaký CMS se používá. Stojí za to upozornit, pokud opravdu rozumíte tomu, o čem mluvíte.

Pokud tyto otázky nevlastníte, pak jednoduše označte prohlížeče, ve kterých by se měl web správně zobrazovat. Ve zbytku počítejte se svědomím interpreta.

Závěr

V tomto článku jsem se nesnažil ukázat, že takto se sestavuje TK a nic jiného. Udělejte to a nebudete mít žádné problémy. Sestavte kvalitu podmínky pro vývoj webových stránek je spíše otázka Zkušenosti. V prvním páru nebude každý schopen vypracovat kompetentní technický úkol.

V tomto článku jsem chtěl ukázat příklad a zásady, podle kterých je sestaven vzor zadání pro vývoj designu a logiky webu, a také hlavní body, kterým byste měli věnovat pozornost. Do jaké míry se mi to podařilo, doufám, že se poučím z vašich komentářů.

A nezapomeňte na výzvu!

G O S U D A R S T V E N Y S T A N D A R T S O YU Z A S S R

Výnos Státního výboru pro normy SSSR ze dne 18. prosince 1978 č. 3351 stanovil lhůtu pro zavedení

od 01.01. 1980

Tato norma stanoví postup pro konstrukci a provádění technických specifikací pro vývoj programu nebo softwarového produktu pro počítače, komplexy a systémy bez ohledu na jejich účel a rozsah.

Norma plně vyhovuje ST SEV 1627-79.

1. OBECNÁ USTANOVENÍ

1.1. Zadávací podmínky jsou vypracovány v souladu s GOST 19.106-78 na listech formátu 11 a 12 v souladu s GOST 2.301-68, zpravidla bez vyplňování polí listu. Počty listů (stránek) jsou uvedeny v horní části listu nad textem.

1.2. Schvalovací list a titulní strana vypracovat v souladu s GOST 19.104-78.

Informační část (výtah a obsah), list evidence změn nemusí být součástí dokumentu.

1.3. Pro provedení změn nebo dodatků k referenčním podmínkám v následujících fázích vývoje programu nebo softwarového produktu je k nim vydán dodatek. Koordinace a schvalování dodatku k zadání se provádí stejným způsobem, jaký je stanoven pro zadání.

1.4. Zadávací podmínky by měly obsahovat následující oddíly:

• úvod;
• důvody pro rozvoj;
• účel vývoje;
• požadavky na program nebo softwarový produkt;
• požadavky na dokumentaci softwaru;
• technické a ekonomické ukazatele;
• etapy a etapy vývoje;
• postup kontroly a akceptace;
• je povoleno zahrnout aplikace do zadání.

V závislosti na vlastnostech programu nebo softwarového produktu je povoleno upřesnit obsah sekcí, zavést nové sekce nebo některé z nich kombinovat.

2.1. V části „Úvod“ uveďte název, stručný popis rozsah programu nebo softwarového produktu a zařízení, ve kterém se program nebo softwarový produkt používá.

(Změněné vydání, Rev. č. 1)

2.2. Část Základ pro rozvoj by měla obsahovat:

• dokument (dokumenty), na jehož základě je vývoj prováděn;
• organizaci, která tento dokument schválila, a datum jeho schválení;
• jméno a (nebo) symbol rozvojová témata.

(Změněné vydání, Rev. č. 1)

2.3. V části Účel vývoje by měl být uveden funkční a provozní účel programu nebo softwarového produktu.

2.4. Sekce "Požadavky na program nebo softwarový produkt" by měla obsahovat následující podsekce:

• požadavky na výkon;
• požadavky na spolehlivost;
• podmínky použití;
• požadavky na skladbu a parametry technických prostředků;
• požadavky na informace a kompatibilitu softwaru;
• požadavky na označování a balení;
• požadavky na přepravu a skladování;
• speciální požadavky.

(Změněné vydání, Rev. č. 1)

2.4.1. V podčásti „Požadavky na funkční charakteristiky“ by měly být uvedeny požadavky na skladbu vykonávaných funkcí, organizaci vstupních a výstupních dat, časové charakteristiky atd.

2.4.2. V podkapitole „Požadavky na spolehlivost“ by měly být uvedeny požadavky na zajištění spolehlivého provozu (zajištění stabilního provozu, řízení vstupních a výstupních informací, doba zotavení po poruše atd.).

2.4.3. V podčásti "Provozní podmínky" by měly být uvedeny provozní podmínky (teplota okolního vzduchu, relativní vlhkost atd. u vybraných typů datových nosičů), za kterých mají být uvedené charakteristiky poskytovány, dále typ služby, požadovaný počet a kvalifikace personálu.

2.4.4. V pododdílu „Požadavky na složení a parametry technických prostředků“ uveďte požadované složení technických prostředků s uvedením jejich hlavních technických vlastností.

2.4.5. V podčásti „Požadavky na informace a kompatibilitu softwaru“ jsou požadavky na informační struktury na vstupu a výstupu a metody řešení, zdrojové kódy, programovací jazyky a softwarových nástrojů používaný programem.

V případě potřeby by měly být informace a programy chráněny.

(Změněné vydání, Rev. č. 1)

2.4.6. V podkapitole „Požadavky na označování a balení“ jsou v obecném případě uvedeny požadavky na označování softwarových produktů, možnosti balení a metody.

2.4.7. V podsekci "Požadavky na přepravu a skladování" musí být uvedeny podmínky pro přepravu, místa skladování, podmínky skladování, podmínky skladování, doby skladování v různých podmínkách pro softwarový produkt.

2.5a. V části „Požadavky na dokumentaci k softwaru“ by mělo být uvedeno předběžné složení dokumentace k softwaru a případně zvláštní požadavky na ni.

(Uvedeno dodatečně, Rev. č. 1).

2.5. V části "Technické a ekonomické ukazatele" by měly být uvedeny: odhadovaná ekonomická efektivnost, odhadovaná roční potřeba, ekonomické výhody vývoje ve srovnání s nejlepšími domácími a zahraničními vzorky nebo analogy.

2.6. V části „Etapy a fáze vývoje“ jsou uvedeny nezbytné fáze vývoje, fáze a obsah prací (seznam programových dokumentů, které je nutné vypracovat, odsouhlasit a schválit), a také zpravidla časový rámec vývoje a určit, že jsou ustanoveni exekutoři.

2.7. V části "Postup kontroly a přejímky" by měly být uvedeny druhy zkoušek a obecné požadavky na přejímku díla.

2.8. V přílohách k zadání v případě potřeby uveďte:

• seznam výzkumných a jiných prací odůvodňujících vývoj;
• schémata algoritmů, tabulky, popisy, zdůvodnění, výpočty a další dokumenty, které lze použít při vývoji;
• další zdroje rozvoje.

Opětovné vydání (listopad 1987) s dodatkem č. 1 schváleným v červenci 1981 (IUS 7-81)

Zadávací podmínky, zkráceně TK, tedy slouží již poměrně dlouho jako formální popis toho, co vlastně chceme v finální produkt. TK pro vývoj webového zdroje není výjimkou. Ve svém jádru je základem pro rozvoj webu. Označuje všechna ustanovení přímo či nepřímo související s webem.

TK je zpravidla připojena k hlavní smlouvě o vytvoření webového zdroje, protože obsahuje úplný seznam všech prací pro povinné provedení, aby se vyloučily možné spory mezi klientem a dodavatelem, které, jak víte , stále se čas od času objevují.

Existuje názor některých lidí „obitých“ zkušenostmi, že TK by měla být psána tak, že s ní budete u soudu a budete ji používat jako obhajobu. To může být extrémní, ale přesto - příležitost k opětovnému zamyšlení o důležitosti dobře napsaného a podrobného TOR .

Svým rozsahem může být TOR poměrně rozsáhlý dokument. Webové společnosti často nabízejí pomoc při přípravě technických specifikací jako samostatnou službu, obvykle 10-20 % nákladů na celý vývoj webu.

Přípravu technických specifikací obvykle provádí projektový manažer nebo přímo programátor za účasti zákazníka, který poskytuje základní informace.

Jak podrobnější TK (samozřejmě v rozumných mezích), tím lépe pro obě strany – jak pro zadavatele, tak pro zhotovitele díla. Oba vyhrávají, abych tak řekl:
– klient bude mít jistotu, že vše, co si v projektu vymyslel, je jasně vysvětleno a musí být realizováno v souladu s TOR.
- interpret - je pojištěn proti mnoha malým či velkým úpravám a vylepšením, opět se spoléhá na stejnou TK.

Existuje názor, že se bez TK obejdete. Jedním z argumentů je například to, že úkol je příliš kreativní na to, aby se vešel do rámce TOR. Za tímto názorem se nejspíš skrývá nedostatek zkušeností a profesionality v této oblasti. Tento názor považuji za mylný, jelikož téměř vše v tvorbě webových stránek mohou být formalizovány a prezentovány v TOR a skládat to je spíše otázkou zkušeností.

• Jednoduchou pravdou je, že čím složitější projekt, tím podrobnější by měl být TOR.
• Mezi možnosti lze nazvat TK, která popisuje hlavní stránky rozhraní s celou sadou prvků a popisem jejich chování. Nebo to může být stručný popis několika stránek pro web vizitek atd.
• TOR pro programátora by neměl zmiňovat návrh prvků nebo vytvářet přání ohledně návrhu. Úkol je stále pro programátora ..
• Popisy úkolů v jednotlivých částech TOR by měly být hraniční. Co to znamená? Je nutné jasně označit konec konkrétní položky úkolu. TOR by neměl obsahovat abstraktní fráze jako „měla by být snadná navigace“. To vše jsou subjektivní znaky – pro někoho to vyhovuje, pro jiného nevyhovující a může být obtížné pochopit, zda byla tato položka dokončena kvůli vágnosti ustanovení podmínek podmínek. To znamená, že se to musí kontrolovat.
• U jednoduchých webů, kde potřebujete popsat nějaký funkční modul, abyste znovu nevynalezli kolo, musíte analyzovat weby s podobnou funkčností, abych tak řekl, analyzovat konkurenty; uložit hypertextové odkazy na stránky s požadovanými prvky rozhraní a funkcemi a zahrnout je do TOR s rozšířeným vysvětlením toho, co přesně dělat. Je také nutné v bez chyby pořizovat snímky obrazovky požadované stránky v případě, že se stránka po nějaké době stane nedostupnou. Zároveň si můžete na obrázky dávat své vlastní značky (naštěstí je na to nyní spousta prostředků - Clip2net, Joxi, Awesome Screenshot a další).
• Pokud pro stránky neexistuje design nebo to není tak důležité v rámci projektu, řekněme, zákazník se rozhodl ušetřit na designu administračního panelu webu, v tomto případě může programátor použít prototypy.

Odkaz

Prototyp je grafické rozvržení prvků rozhraní. Zhruba řečeno, vtažený speciální program stránka se všemi prvky.

K dispozici je mnoho prototypového softwaru, včetně aplikací pro stolní počítače a online služeb, stejně jako skromnějších rozšíření prohlížeče. Měkký jako s bezplatnou licenci stejně jako zaplacené.

Mezi oblíbené patří:
- Mezi bezplatné: iPlotz, MockFlow, Mockup Builder, Cacoo;
- mezi placenými: Creately, ProtoShare, Adobe Fireworks, Axure . Obecně existuje mnoho příležitostí - vybrat, zvládnout, nakreslit ...

Obecná struktura TK. Od abstrakce ke konkrétnosti

Jedna z možných struktur webu, zdůrazňuji ty možné, by mohla vypadat nějak takto:

1. obecná informace O webu.
2. Funkční účel webu.
3. Pojmy a termíny
4. Popis modulů místa
5. Funkční charakteristiky
6. Popis stránek.
7. redundance a spolehlivost.
8. Hosting webových stránek.

1. Obecné informace o webu
Zde postačí pár vět, abyste byli informováni o tom, jaký druh webu nebo modulu bude vyvíjen a jeho účel obecně. Psáno volným stylem.

2. Funkční účel webu
Zde je krátký seznam toho, jaké technické prostředky nebo nástroje by web měl mít na základě celkového cíle. Dovolte mi to vysvětlit na příkladu. Pro web vizitek to může být banální, formulář zpětné vazby, seznam hlavních stránek, například s „o společnosti“, „kontakty“ a dalšími.

3. Pojmy a termíny
Tato část by měla zajistit, aby obě strany porozuměly konkrétnímu předmětová oblast koncepty, které jsou důležité pro pochopení a rozvoj webu. Mohou vstoupit obě strany.

4. Popis modulů webu
Tato sekce obsahuje seznam modulů, které se na webu používají. Může to být výše zmíněný formulář zpětné vazby (FOS). Ale, což je velmi důležité, nemůžete jen napsat „FOS musí být přítomen“. Každá entita vyžaduje definici svých atributů! V tento případ atributy mohou být takto:

• Pole "Vaše jméno";
• Pole "Váš e-mail";
• Pole "Vaše otázka";
• Vstupní pole captcha pro ochranu před spamovými roboty.

A to vše by mělo být jasně vysvětleno, aby později nebyly žádné otázky: « ... a kde je seznam výběru kategorií otázek?» Nebo něco takového.

5. Funkční charakteristiky
To může zahrnovat například seznam prohlížečů, kde by se měl web zobrazovat a správně fungovat. Někteří zákazníci mohou například vyžadovat, aby jejich stránky fungovaly správně a v notoricky známém prostředí internet Explorer 6, abychom nepřišli ani o malý, ale o podíl potenciálních návštěvníků.
Pokud plánujete vytvořit vysoce zatížený web, mělo by to být také uvedeno. Vysoce zatížený web vyžaduje jiný přístup při vývoji a konfiguraci serveru.

Mezi funkční charakteristiky je také zahrnuta přítomnost nebo nepřítomnost mobilní verze stránky, ale to zpravidla buď jde do samostatné části této TK, nebo se obecně píše samostatně.

6. Popis stránek webu
Jedná se o poměrně rozsáhlý bod, kde jsou zakresleny všechny stránky webu a psány komentáře k jejich práci.
Může být také podán obecná struktura stránky webu. Takzvané "high-level" prototypy. Například pro jednoduchý adresářový web to může být:

Pro každou konkrétní stránku lze nakreslit prototypy s podrobnými komentáři ke každému z prvků rozhraní s jejich chováním.
Stránky používané pro administrátorský panel jsou obvykle uvedeny odděleně od veřejných stránek. Tyto dvě sekce lze zase seskupit do samostatných podsekcí. Zde stojí za to se ujistit, že prototypy nejsou v rozporu s jejich popisem a neexistují žádné rozpory. Příkladem prototypu pro konkrétní stránku webu může být:

Další stránky

Posledními dvěma oddíly TOR se nebudeme podrobně zabývat, stručně řeknu, že jedním z požadavků na spolehlivost může být nastavení záloh databáze.

Požadavky na hostování mohou zahrnovat dostupné fyzická paměť pro web, šířku pásma kanálu, podporu použité databáze a řadu dalších požadavků na správné fungování místo.

Na konci TOR je povinné uvést informaci, že všechny práce, které nejsou popsány v tomto TOR, provádí podle uvážení programátora ze zřejmých důvodů. Toto je naše „malá záruka“ proti možným vylepšením a změnám, které přesahují rámec TOR.

Závěry: Musím říci, že takováto struktura sekcí TOR si nečiní nárok na úplnost (alespoň u velkých strategických projektů), přesto pokrývá hlavní body.

Je třeba zdůraznit, že vše výše uvedené jsou pouze doporučení založená na zkušenostech lidí pracujících v oblasti stavby staveniště a nejsou v žádném případě striktním požadavkem na psaní technických specifikací.

Hodně štěstí s vašimi projekty a lidským porozuměním!

Často dostávám otázku: „Jak vyvinout technický úkol pro automatizovaný systém?“. Téma vývoje technických specifikací je neustále diskutováno na různých fórech. Tato otázka je tak široká, že na ni nelze ve zkratce odpovědět. Tak jsem se rozhodl napsat skvělý článek na toto téma. V procesu práce na článku jsem si uvědomil, že by nefungovalo dát vše do jednoho článku, protože. vyjde to pod 50 stran a rozhodli jsme se to rozdělit na 2 části:

• V první části" Vývoj technických specifikací. Co to je, proč je to potřeba, kde začít a jak by to mělo vypadat? Pokusím se podrobně zodpovědět otázky k tématu, zvážit strukturu a účel zadání a uvést některá doporučení k formulaci požadavků.
• Druhá část " Vývoj technických specifikací. Jak formulovat požadavky? bude zcela věnována identifikaci a formulaci požadavků na informační systém.

Nejprve musíte zjistit, jaká otázka skutečně zajímá ty, kteří se ptají "Jak vyvinout technický úkol?" Faktem je, že přístup k vývoji technických specifikací bude do značné míry záviset na účelech, pro které se to dělá, a také na tom, kdo to bude používat. O jakých možnostech mluvím?

• Komerční organizace se rozhodla implementovat automatizovaný systém. Nemá vlastní IT službu a rozhodla se udělat toto: Zájemce musí vypracovat podmínky zadání a předat je organizaci třetí strany k vývoji;
• Komerční organizace se rozhodla implementovat automatizovaný systém. Má vlastní IT službu. Rozhodli jsme se udělat toto: vytvořit podmínky zadání, poté je koordinovat mezi IT službou a zainteresovanými stranami a implementovat je vlastními silami;
• Státní struktura se rozhodla zahájit IT projekt. Všechno je tu takové zablácené, spousta formalit, provizí, škrtů atd. Tuto možnost v tomto článku nebudu zvažovat.
• IT společnost se zabývá službami pro vývoj a/nebo implementaci automatizovaných systémů. Tohle je nejvíc těžký případ, protože musíte pracovat v různých podmínkách:

  Klient má své specialisty s vlastními názory a mají specifické požadavky na Zadání;

  • Podmínky jsou vyvíjeny pro naše vlastní vývojáře (klientovi je to jedno);
  • Zadávací podmínky jsou vypracovány pro předání dodavateli (tj. skupině programátorů, kteří jsou mimo zaměstnance společnosti, nebo jednotlivému specialistovi);
  • Mezi společnostmi a klientem dochází k nedorozumění ohledně dosaženého výsledku a společnost si znovu a znovu klade otázku: „Jak by měly být vypracovány podmínky zadání?“. Poslední případ se může zdát jako paradox, ale je to tak.
  • Jiné, méně obvyklé možnosti jsou také možné;

Myslím, že čtenář by nyní měl mít otázky:

• Proč nemohou být podmínky zadání vždy vypracovány stejným způsobem?;
• Existují nějaké normy, metody, doporučení? Kde je získat?
• Kdo by měl vypracovat zadání? Musí mít tato osoba nějaké speciální znalosti?
• Jak porozumět tomu, zda jsou podmínky zadání dobře napsané nebo ne?
• Na čí náklady by se to mělo rozvíjet a je to vůbec potřeba?

Tento seznam by mohl být nekonečný. Mluvím tak sebejistě ze skutečnosti, že 15 let v profesním rozvoji software a v každém vývojovém týmu, se kterým musíte spolupracovat, se objeví otázka podmínek reference. Důvody pro to jsou různé. Vzhledem k tomu, že jsem nastolil téma vývoje zadání, jsem si dobře vědom toho, že jej nebudu moci prezentovat na 100 % všem zájemcům o toto téma. Ale pokusím se, jak se říká, „všechno dát do polic“. Ti, kteří již mé články znají, vědí, že nepoužívám „copy-paste“ cizích prací, nepřetiskuji cizí knihy, necituji vícestránkové normy a další dokumenty, které si sami můžete najít na internetu, vydávat je za své skvělé myšlenky. Stačí zadat do vyhledávače „How to develop Terms of Reference“ a budete si moci přečíst mnoho zajímavého, bohužel však mnohokrát opakovaného. Ti, kteří jsou rádi chytří na fórech (zkuste přece hledat!), zpravidla sami neudělali rozumné podmínky zadání a neustále citují doporučení GOST k tomuto problému. A ti, kteří se touto problematikou opravdu vážně zabývají, většinou nemají čas sedět na fórech. Mimochodem, budeme také mluvit o GOST. Za léta své práce jsem viděl mnoho variant technické dokumentace sestavené jak jednotlivými specialisty, tak významnými týmy a poradenskými společnostmi. Občas dělám i takové aktivity: vyčleňuji si čas pro sebe a hledám informace na téma, které mě zajímá, z neobvyklých zdrojů (taková trocha inteligence). V důsledku toho jsem musel vidět dokumentaci o takových monstrech, jako je Gazprom, Ruské dráhy a mnoho dalších zajímavých společností. Zásadu mlčenlivosti samozřejmě dodržuji, a to i přesto, že mi tyto dokumenty pocházejí z veřejných zdrojů nebo nezodpovědností konzultantů (rozhazují informace po internetu). Proto okamžitě říkám: Nesdílím důvěrné informace, které patří jiným společnostem, bez ohledu na zdroje výskytu (profesní etika).

Co je to technický úkol?

První věc, kterou nyní uděláme, je zjistit, o jaký druh zvířete se jedná, „referenční podmínky“.

Ano, skutečně existují GOST a normy, ve kterých se pokouší regulovat tuto část činnosti (vývoj softwaru). Kdysi byly všechny tyto GOST relevantní a aktivně používané. Nyní existují různé názory na relevanci těchto dokumentů. Někteří tvrdí, že GOST byly vyvinuty velmi prozíravými lidmi a jsou stále relevantní. Jiní říkají, že jsou beznadějně zastaralí. Možná si teď někdo myslel, že pravda je někde uprostřed. Odpověděl bych slovy Goetha: „Říkají, že mezi dvěma protichůdnými názory leží pravda. V žádném případě! Mezi nimi je problém." Takže mezi těmito názory není pravda. Protože GOST neodhalují praktické problémy moderní design a ti, kdo je kritizují, nenabízejí alternativy (konkrétní a systémové).

Všimněte si, že GOST zjevně ani neuvádí definici, pouze říká: „TOR pro JE je hlavním dokumentem, který definuje požadavky a postup pro vytvoření (vývoj nebo modernizace - další tvorba) automatizovaného systému v souladu s kterým se provádí vývoj JE a její převzetí při uvedení do provozu. do akce.“

Pokud někoho zajímá, o jakých GOST mluvím, tak tady jsou:

• GOST 2.114-95 Jednotný systém pro projektovou dokumentaci. Specifikace;
• GOST 19.201-78 Jednotný systém programové dokumentace. Technický úkol. Požadavky na obsah a design;
• GOST 34.602-89 Informační technologie. Soubor norem pro automatizované systémy. Zadání pro vytvoření automatizovaného systému.

Mnohem lepší definice je uvedena na Wikipedii (pravda o TK obecně, a nejen pro software): “ Technický úkol je originálním projektovým dokumentem technický objekt. Technický úkol stanoví hlavní účel rozvíjeného objektu, jeho technicko-takticko-technické charakteristiky, ukazatele kvality a technicko-ekonomické požadavky, pokyny pro dokončení nezbytných stupňů tvorby dokumentace (projekční, technologická, programová atd.) a její složení, jako i speciální požadavky. Úkol jako zdrojový dokument pro vytvoření něčeho nového existuje ve všech oblastech činnosti, lišících se názvem, obsahem, pořadím provedení atd. (například konstrukční úkol ve výstavbě, bojová mise, domácí práce, smlouva o literárním díle apod.)“

A tak, jak vyplývá z definice, hlavním účelem zadání je formulovat požadavky na vyvíjený objekt, v našem případě na automatizovaný systém.

Je to hlavní, ale jediné. Je čas vzít si to hlavní: dát vše "na police", jak bylo slíbeno.

Co potřebujete vědět o požadavcích? Je třeba jasně chápat, že všechny požadavky musí být rozděleny podle typu a podle vlastností. Nyní se naučíme, jak na to. K oddělení požadavků podle typu nám GOST pomůže. Seznam typů požadavků, který je zde uveden, je dobrým příkladem toho, jaké typy požadavků je třeba vzít v úvahu. Například:

• požadavky na funkčnost;
• Požadavky na bezpečnost a přístupová práva;
• Požadavky na kvalifikaci personálu;
• …. Atd. Dočtete se o nich ve zmíněném GOST (a níže je také trochu podrobněji zvážím).

Myslím, že je vám jasné, že dobře formulované požadavky na funkčnost jsou klíčem k úspěšnému zadání. Právě těmto požadavkům je věnována většina prací a metod, o kterých jsem hovořil. Požadavky na funkčnost tvoří 90 % složitosti vývoje podmínek zadání. Vše ostatní je často „kamufláž“, která je na tyto požadavky kladena. Pokud jsou požadavky formulovány špatně, pak bez ohledu na to, jakou krásnou kamufláž na ně dáte, úspěšný projekt nebude fungovat. Ano, formálně budou splněny všechny požadavky (podle GOST J), TOR byl vyvinut, schválen a podepsán a byly na něj přijaty peníze. a co? A pak začíná zábava: co dělat? Pokud se jedná o projekt na státní zakázku, pak nejsou žádné problémy - existuje takový rozpočet, že se nevejde do žádné kapsy, vše bude vyjasněno v procesu implementace (pokud existuje). Právě tímto způsobem je řezána většina rozpočtů projektů na státní zakázky (vypálili „TK“, sloučili desítky milionů, ale projekt nezačali dělat. Všechny formality byly splněny, nikdo nebyl vinen, nové auto u domu. Krása!). Ale bavíme se o komerčních organizacích, kde se počítají peníze, a výsledek je jiný. Proto se pojďme zabývat tím hlavním, jak se rozvíjet užitečné a funkční podmínky.

Řekl jsem o typech požadavků, ale co vlastnosti? Pokud se typy požadavků mohou lišit (v závislosti na cílech projektu), pak s vlastnostmi je vše jednodušší, existují 3 z nich:

1. Požadavek musí být srozumitelný;
2. Požadavek musí být beton;
3. Požadavek musí být testováno;

A poslední nemovitost nemožné bez předchozích dvou, tzn. je jakýmsi „lakmusovým papírkem“. Pokud výsledek požadavku nelze otestovat, pak buď není jasný, nebo není konkrétní. Přemýšlejte o tom. Právě ve vlastnictví těchto tří vlastností požadavků spočívá dovednost a profesionalita. Ve skutečnosti je vše velmi jednoduché. Když na to přijdeš.

Na tomto příběhu o tom, co jsou podmínky zadání, by se dalo dokončit a přejít k hlavní věci: jak formulovat požadavky. Ale není to všechno tak rychlé. Existuje další extrémně důležitý bod:

• v jakém jazyce (z hlediska složitosti porozumění) by měly být zadávací podmínky napsány?
• Měla by v něm být popsána specifikace různých funkcí, algoritmů, datových typů a dalších technických věcí?
• A co je technický design, který je mimochodem také zmíněn v GOST, a jak souvisí s podmínkami zadání?

V odpovědích na tyto otázky je velmi zákeřná věc. Proto často vznikají spory o dostatečnosti či absenci potřebného upřesnění požadavků, o srozumitelnosti dokumentu ze strany objednatele a zhotovitelů, o nadbytečnosti, formátu prezentace apod. A kde je hranice mezi zadáním a technickým návrhem?

Technický úkol je dokument založený na požadavcích formulovaný v jazyce, který je Zákazníkovi srozumitelný (obvyklý, známý). V tomto případě může a měla by být použita oborová terminologie srozumitelná zákazníkovi. Neměly by existovat žádné vazby na vlastnosti technické implementace. Tito. ve fázi TK je v zásadě jedno, na jaké platformě budou tyto požadavky implementovány. I když existují výjimky. Pokud jde o implementaci systému založeného na existujícím softwarový produkt, pak k takové vazbě může dojít, ale pouze na úrovni obrazovkových formulářů, formulářů zpráv apod. Vyjasnění a formulace požadavků, jakož i vypracování Zadání by mělo být Obchodní analytik. A rozhodně ne programátor (pokud tyto role nespojí, tak se to stává). Tito. tato osoba by měla mluvit se zákazníkem v jazyce jeho podnikání.

Technický projekt - jedná se o dokument, který je určen k technické realizaci požadavků formulovaných v zadání. Právě tento dokument popisuje datové struktury, spouštěče a uložené procedury, algoritmy a další věci, které budou vyžadovány technických specialistů. Není vůbec nutné, aby se v tom zákazník vrtal (možná takovým pojmům nerozumí). Technický projekt ano Systémový architekt(Tady je kombinace této role s programátorem zcela normální). Přesněji řečeno skupina AO specialistů v čele s architektem. Čím větší projekt, tím více více lidí práce na zadání.

Co máme v praxi? Je legrační sledovat, když je ředitel přiveden ke schválení Zadáním, které je plné odborné terminologie, popisů datových typů a jejich hodnot, struktury databáze atd. Samozřejmě se snaží pochopit, protože je nutné prosadit se, snažit se najít známá slova mezi řádky a neztratit požadavky řetězového podnikání. Cože, známá situace? A jak to skončí? Takový TOR je zpravidla schválen, následně implementován a v 80 % případů pak vůbec neodpovídá skutečnosti provedené práce, protože spoustu věcí se rozhodli změnit, předělat, špatně pochopili, mysleli špatně atd. a tak dále. A pak začíná předávací série. „Ale tady to není tak, jak to potřebujeme“, ale „nebude nám to fungovat“, „je to příliš složité“, „je to nepohodlné“ atd. Známý?! Takže vím, že jsem musel včas vyplnit hrboly.

Co tedy máme v praxi? Ale v praxi máme rozmazanou hranici mezi zadáním a technickým návrhem. Pohybuje se mezi TK a TP různými způsoby. A to je špatně. A ukazuje se to proto, že kultura rozvoje zeslábla. Částečně je to kvůli kompetentnosti specialistů, částečně kvůli touze snížit rozpočty a termíny (koneckonců, dokumentace zabere spoustu času - to je fakt). Existuje další důležitý faktor ovlivňující použití technického návrhu jako samostatného dokumentu: rychlý vývoj nástroje rychlého rozvoje a také vývojové metodiky. Ale to je samostatný příběh, níže o něm řeknu pár slov.

Další malý, ale důležitý bod. Někdy se zadávacím podmínkám říká malý kousek požadavků, jednoduchý a srozumitelný. Například zpřesnit hledání objektu podle nějakých podmínek, přidat sloupec do sestavy atd. Tento přístup je celkem oprávněný, proč si komplikovat život. Nepoužívá se však u velkých projektů, ale u menších vylepšení. Řekl bych, že se to blíží údržbě softwarového produktu. V tomto případě může Zadání také popisovat konkrétní technické řešení pro realizaci požadavku. Například „Provést takovou a takovou změnu v algoritmu“, která označuje konkrétní postup a konkrétní změnu pro programátora. To je případ, kdy je hranice mezi zadáním a technickými projekty zcela smazána, protože není ekonomická proveditelnost nafouknout papírování tam, kde to není potřeba, a vznikne užitečný dokument. A je to správné.

Opravdu potřebujete technickou specifikaci? A co inženýrský projekt?

Jsem přehřátý? Je to vůbec možné bez podmínky zadání? Představte si možná (přesněji řečeno se vyskytuje), a tento přístup má mnoho následovníků a jejich počet se zvyšuje. Zpravidla poté, co mladí odborníci čtou knihy o Scrum, Agile a dalších technologiích rychlého rozvoje. Ve skutečnosti jsou to úžasné technologie a fungují, jen doslova neříkají „není třeba dělat technické úkoly“. Říká se „minimum papírování“, zejména zbytečného, ​​blíže k zákazníkovi, více specifik a rychlejší výsledky. Fixování požadavků ale nikdo nezrušil a je to tam jasně řečeno. Právě tam jsou požadavky stanoveny na základě tří úžasných vlastností, o kterých jsem mluvil výše. Prostě vědomí některých lidí je uspořádáno tak, že když lze něco zjednodušit, zjednodušme to do úplné absence. Jak řekl Einstein" Udělejte to co nejjednodušší, ale ne jednodušší." . Zlatá slova se hodí ke všemu. Tak Technický úkol nutné, jinak se nedočkáte úspěšného projektu. Další otázkou je, jak skládat a co tam zařadit. Ve světle metod rychlého vývoje se musíte soustředit pouze na požadavky a všechny „kamufláže“ lze odhodit. V zásadě s tím souhlasím.

A co technický projekt? Tento dokument je velmi užitečný a neztratil svou relevanci. Navíc se bez něj často prostě nelze obejít. Zejména pokud jde o outsourcing vývojových prací, tzn. na bázi outsourcingu. Pokud to neuděláte, existuje riziko, že se dozvíte hodně o tom, jak by měl systém, který máte na mysli, vypadat. Má ho zákazník poznat? Pokud chce, proč ne, ale trvat na tom a prosadit se tento dokument není potřeba, jen se bude zdržovat a překážet při práci. Navrhnout systém do nejmenších detailů je téměř nemožné. V tomto případě budete muset průběžně provádět změny v technickém návrhu, což zabere spoustu času. A pokud je organizace silně byrokratizovaná, pak obecně všechny nervy nechte tam. Právě o tomto druhu redukce designu se diskutuje v moderních metodologiích rychlého vývoje, o kterých jsem se zmínil výše. Mimochodem, všechny jsou založeny na klasickém XP (extreme programming) přístupu, který je již asi 20 let starý. Vytvořte tedy kvalitní zadání, srozumitelné pro zákazníka a použijte technický návrh jako interní dokument pro vztah mezi architektem systému a programátory.

Zajímavý detail o technické provedení: některé vývojové nástroje uspořádané podle principu předmětové orientace (např. 1C a podobně) naznačují, že návrh (myšleno proces dokumentace) je vyžadován pouze ve skutečně složitých oblastech, kde je vyžadována interakce mezi celými subsystémy. V nejjednodušším případě, například k vytvoření referenční knihy, dokumentu, stačí pouze správně formulované obchodní požadavky. Svědčí o tom obchodní strategie této platformy z hlediska školení specialistů. Pokud se podíváte na zkušební lístek specialisty (tak se tomu říká, a ne „programátora“), uvidíte, že tam jsou pouze obchodní požadavky a jak je implementovat v programovacím jazyce je úkolem specialista. Tito. tu část úkolu, kterou má Technický návrh řešit, musí specialista vyřešit „v hlavě“ (hovoříme o úkolech střední složitosti) a tady a teď, při dodržení určitých standardů vývoje a designu, které jsou opět vytvořila společnost 1C pro svou platformu. Tedy ze dvou specialistů, jejichž výsledek práce vypadá stejně, jeden může zkoušku složit a druhý ne, protože. hrubě porušil vývojové standardy. To znamená, že se zjevně předpokládá, že specialisté musí mít takovou kvalifikaci, aby mohli sami navrhovat typické úkoly, bez zapojení systémových architektů. A tento přístup funguje.

Pokračujme ve studiu otázky: "Jaké požadavky by měly být součástí zadání?"

Formulace požadavků na informační systém. Struktura zadání

Udělejme si to hned jasno: budeme hovořit o formulaci požadavků na informační systém, tzn. za předpokladu, že práce na vývoji obchodních požadavků, formalizaci obchodních procesů a veškeré předchozí konzultační práce již byly dokončeny. V této fázi lze samozřejmě provést některá upřesnění, ale pouze upřesnění. Samotný projekt automatizace neřeší obchodní problémy – mějte to na paměti. Toto je axiom. Někteří manažeři se to z nějakého důvodu snaží vyvrátit a věří, že pokud si program koupí, přijde řád v chaotickém byznysu. Ale konec konců axiom je axiom, který nevyžaduje důkaz.

Jako u každé činnosti lze (a mělo by) formulování požadavků rozdělit do etap. Vše má svůj čas. To je těžká intelektuální práce. A pokud se s ním zachází s nedostatečnou pozorností, bude výsledek odpovídající. Podle odborných odhadů mohou náklady na vytvoření zadání činit 30–50 %. Jsem stejného názoru. I když 50 je možná moc. Koneckonců, zadání ještě není nejnovější dokument, který se má rozvíjet. Nesmí chybět ani technické provedení. Tato variace je způsobena různými automatizačními platformami, přístupy a technologiemi, které používají projektové týmy během vývoje. Například, pokud mluvíme o vývoji v klasickém jazyce, jako je C++, pak je nepostradatelný detailní technický návrh. Pokud mluvíme o implementaci systému na platformě 1C, pak je situace s designem poněkud odlišná, jak jsme viděli výše (i když při vývoji systému od nuly je navržen podle klasického schématu).

I když formulace požadavků je hlavní částí podmínky zadání, a v některých případech se stává jedinou částí ToR, měli byste věnovat pozornost skutečnosti, že se jedná o důležitý dokument, a měl by být podle toho vypracován. kde začít? Nejprve musíte začít s obsahem. Vytvořte obsah a poté jej začněte rozbalovat. Osobně dělám toto: nejprve nastíním obsah, popíšu cíle, všechny úvodní informace a poté se ujímám hlavní části – formulace požadavků. Proč ne naopak? Nevím, je to pro mě pohodlnější. Za prvé se jedná o mnohem menší část času (v porovnání s požadavky) a za druhé se při popisu všech úvodních informací naladíte na to hlavní. No kdo to má rád. Postupem času si vytvoříte vlastní šablonu podmínek zadání. Pro začátek doporučuji vzít jako obsah přesně ten, který je popsán v GOST. Je to skvělé pro obsah! Poté vezmeme a začneme popisovat každou sekci, přičemž nezapomeneme na doporučení pro následující tři vlastnosti: srozumitelnost, specifičnost a testovatelnost. Proč na tom tolik trvám? Více o tom v další části. A nyní navrhuji taktně projít těmi body TK, které jsou doporučeny v GOST.

1. obecná informace;
2. účel a cíle tvorby (vývoje) systému;
3. charakteristiky objektů automatizace;
4. Požadavky na systém;
5. skladba a obsah práce na tvorbě systému;
6. postup pro kontrolu a akceptaci systému;
7. požadavky na skladbu a obsah prací na přípravě objektu automatizace pro uvedení systému do provozu;
8. požadavky na dokumentaci;
9. vývojové zdroje.

Celkem 9 sekcí, z nichž každá je také rozdělena na podsekce. Vezměme je popořadě. Pro usnadnění uvedu vše ve formě tabulky u každé položky.

Oddíl 1. obecné informace.

Sekce 2. účel a cíle tvorby (vývoje) systému.

Obecně platí, že schopnost identifikovat cíle, formulovat je, budovat strom cílů je zcela samostatné téma. Pamatujte na hlavní věc: pokud víte jak - pište, pokud si nejste jisti - nepište vůbec. Co se stane, když si nestanovíte cíle? Budete pracovat podle požadavků, to se často praktikuje.

Sekce 3. Charakteristika objektů automatizace.

Část 4 Systémové požadavky

GOST dešifruje seznam těchto požadavků:

• požadavky na strukturu a fungování systému;
• požadavky na počet a kvalifikaci personálu systému a způsob jeho práce;
• ukazatele destinace;
• požadavky na spolehlivost;
• bezpečnostní požadavky;
• požadavky na ergonomii a technickou estetiku;
• požadavky na přepravitelnost pro mobilní AS;
• požadavky na provoz, údržbu, opravy a skladování součástí systému;
• požadavky na ochranu informací před neoprávněným přístupem;
• požadavky na bezpečnost informací v případě nehod;
• požadavky na ochranu před vlivem vnějších vlivů;
• požadavky na čistotu patentu;
• požadavky na standardizaci a unifikaci;

I když hlavní bude jistě sekce se specifickými požadavky (funkční), i tato sekce může mít velký význam (a ve většině případů tomu tak je). Co může být důležité a užitečné:

• Kvalifikační požadavky. Je možné, že vyvíjený systém bude vyžadovat rekvalifikaci specialistů. Mohou to být jak uživatelé budoucího systému, tak IT specialisté, kteří budou potřeba k jeho podpoře. Nedostatečná pozornost této problematice se často vyvine v problémy. Pokud je kvalifikace stávajícího personálu zjevně nedostatečná, je lepší předepsat požadavky na organizaci školení, vzdělávací program, termíny atd.
• Požadavky na ochranu informací před neoprávněným přístupem. Nejsou zde žádné komentáře. To jsou právě požadavky na řízení přístupu k datům. Pokud jsou takové požadavky plánovány, pak je třeba je napsat samostatně, co nejpodrobněji podle stejných pravidel jako funkční požadavky (srozumitelnost, specifičnost, testovatelnost). Proto lze tyto požadavky zařadit do části s funkčními požadavky.
• požadavky na standardizaci. Pokud existují nějaké vývojové standardy, které jsou použitelné pro projekt, mohou být zahrnuty do požadavků. Tyto požadavky jsou zpravidla iniciovány IT službou Zákazníka. Například společnost 1C má požadavky na design programový kód, design rozhraní atd.;
• Požadavky na strukturu a fungování systému. Zde lze popsat požadavky na integraci systémů mezi sebou, je uveden popis obecná architektura. Častěji jsou požadavky na integraci vyčleněny obecně v samostatné části nebo dokonce v samostatném zadání, protože tyto požadavky mohou být poměrně složité.

Všechny ostatní požadavky jsou méně důležité a lze je vynechat. Podle mě jen zatěžují dokumentaci a praktické využití nést trochu. A popsat požadavky na ergonomii formou obecných požadavků je velmi obtížné, je lepší je přenést na funkční. Lze formulovat například požadavek „Získat informaci o ceně produktu stisknutím jediného tlačítka“. Dle mého názoru se to stále blíží konkrétním funkčním požadavkům, i když se to týká ergonomie Požadavky na funkce (úkoly) prováděné systémem Zde je to úplně hlavní a klíčový bod, který rozhodne o úspěchu. I když je vše ostatní provedeno perfektně a tato sekce je na „3“, výsledek projektu bude in nejlepší případ na "3", nebo dokonce projekt selže. Právě těm se budeme podrobněji věnovat v druhém článku, který bude zařazen do 5. vydání mailing listu. V tomto bodě platí „pravidlo tří vlastností požadavků“, o kterém jsem hovořil. Požadavky na typy zabezpečení

GOST rozlišuje následující typy:

• Matematický
• informační
• Lingvistické
• Software
• Technický
• Metrologické
• Organizační
• metodický
• a další…

Na první pohled se může zdát, že tyto požadavky nejsou důležité. To platí pro většinu projektů. Ale ne vždy. Kdy popsat tyto požadavky:

• Nebylo učiněno žádné rozhodnutí o tom, v jakém jazyce (nebo platformě) bude vývoj probíhat;
• Systém podléhá požadavkům na vícejazyčné rozhraní (například ruština / angličtina)
• Pro fungování systému je nutné vytvořit samostatnou jednotku nebo přijmout nové zaměstnance;
• Aby systém fungoval, musí zákazník projít změnami pracovních metod a tyto změny musí být specifikovány a naplánovány;
• Předpokládá se integrace s některým zařízením a jsou na něj kladeny požadavky (například certifikace, kompatibilita atd.)
• Jiné situace jsou možné, vše závisí na konkrétních cílech projektu.

Sekce 5. Složení a obsah práce na vytvoření systému

Oddíl 6. Postup pro kontrolu a převzetí systému

Obecné požadavky na přejímku díla po etapách (seznam zúčastněných podniků a organizací, místo a načasování), postup odsouhlasení a schvalování přejímací dokumentace, důrazně doporučuji převzít odpovědnost za postup předání díla a kontrolu systému. K tomu slouží testovatelné požadavky, ale ani přítomnost testovatelných požadavků nemusí být při dodání systému dostačující, pokud není jasně stanoven postup pro převzetí a předání díla. Například běžná past: systém je hotový, je plně funkční, ale Zákazník z nějakého důvodu není připraven v něm pracovat. Tyto důvody mohou být jakékoli: jednou se změnily cíle, někdo skončil atd. A říká: „Protože ještě nepracujeme v nový systém, takže si nemůžeme být jisti, že to funguje. Naučte se tedy správně identifikovat fáze práce, způsoby kontroly výsledků těchto fází. Tyto metody by navíc měly být zákazníkovi jasné od samého začátku. Pokud jsou fixní na úrovni podmínek zadání, pak je můžete v případě potřeby vždy kontaktovat a dokončit práci s převodem.

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

Mohou existovat jiná pravidla pro zadávání informací přijatá společností (nebo plánovaná). Například informace o smlouvě se dříve zadávaly jako textový řádek v libovolném tvaru, ale nyní je vyžadováno samostatně číslo, zvlášť datum atd. Takových podmínek může být mnoho. Některé z nich lze vnímat s odporem obsluhy, proto je lepší všechny takové případy evidovat na úrovni požadavků na pořadí zadávání dat Změny, které je potřeba provést v objektu automatizace

Vytvoření podmínek pro fungování objektu automatizace, za kterých je zaručena shoda vytvořeného systému s požadavky obsaženými v TOR Případné změny. Společnost např. nemá místní síti, zastaralá flotila počítačů, na kterých systém nebude fungovat.

Možná některé nezbytné informace zpracovány na papíře a nyní musí být vloženy do systému. Pokud se tak nestane, nebude některý modul fungovat atd.

Možná se něco zjednodušilo, ale teď je to třeba vzít v úvahu podrobněji, takže někdo musí sbírat informace podle určitých pravidel.

Tento seznam může být dlouhý, viz konkrétní případ vlastní projekt Vytvoření jednotek a služeb nezbytných pro fungování systému;

Termíny a postupy pro personální obsazení a školení personálu Již jsme o tom hovořili dříve. Možná je systém vyvíjen pro novou strukturu nebo typ činnosti, která dříve neexistovala. Pokud není k dispozici vhodný personál, a dokonce ani vyškolený, systém nebude fungovat, bez ohledu na to, jak kvalifikovaně není postaven.

Část 8 Požadavky na dokumentaci

Zvažte, jak budou prezentovány uživatelské příručky.

Zákazník možná přijal podnikové standardy, takže je třeba ho kontaktovat.

Ignorování požadavků na dokumentaci velmi často vede k nejneočekávanějším důsledkům na projekty. Například vše je hotovo a vše funguje. Uživatelé také vědí, jak pracovat. Vůbec jsme se nedohodli na dokumentaci a nemluvili. A najednou se vás při předání díla jeden z vrcholových manažerů Zákazníka, který se projektu ani neúčastnil, ale podílí se na přejímce díla, ptá: „Kde jsou uživatelské manuály?“ A začne vás přesvědčovat, že nebylo nutné se dohodnout na dostupnosti uživatelských příruček, to je prý naznačeno „samo“. A je to, nechce ti vzít práci. Na čí náklady vypracujete pokyny? Mnoho týmů už tomuto háku propadlo.

Oddíl 9 Zdroje rozvoje

Proto je lepší jednoduše odkázat na zprávu o průzkumu, požadavky klíčových osob.

A tak jsme zvážili všechny části, které lze zahrnout do podmínek zadání. „Může“, nikoli „Musí“ právě proto, že k dosažení výsledku musí být vytvořen jakýkoli dokument. Pokud je vám tedy zřejmé, že nějaká samostatná sekce vás k výsledku nepřiblíží, tak ji nepotřebujete a nemusíte s ní ztrácet čas.

Ale bez toho hlavního: funkčních požadavků není ani jeden kompetentní zadání úplný. Chci poznamenat, že v praxi se s takovými referenčními podmínkami setkáváme a jak! Existují postavy, které dokážou rozředit vody ve všech částech, popsat obecné požadavky obecně a dokument se ukáže jako velmi závažný a je v něm spousta chytrých slov a dokonce se může líbit i zákazníkovi to (tj. schválí to). Ale možná se na tom nedá pracovat, tzn. má malé praktické využití. Ve většině případů se takové dokumenty rodí, když potřebujete získat hodně peněz speciálně za podmínky zadání, a musíte to udělat rychle a bez ponoření do detailů. A hlavně pokud se ví, že to dál nepůjde, nebo to budou dělat úplně jiní lidé. Obecně jen pro vývoj rozpočtu, zejména státu.

Ve druhém článku budeme hovořit pouze o části 4 „Systémové požadavky“ a konkrétně požadavky formulujeme z důvodu srozumitelnosti, specifičnosti a testovatelnosti.

Proč by požadavky měly být jasné, konkrétní a testovatelné.

Protože praxe ukazuje: na začátku se většina technických specifikací, které vyvíjejí specialisté, buď ukáže, že není poptávaná (neodpovídá realitě), nebo se stane problémem pro toho, kdo by je měl implementovat, protože Zákazník začíná manipulovat s nekonkrétními podmínkami a požadavky. Uvedu pár příkladů, s jakými frázemi jsem se setkal, k čemu to vedlo, a poté se pokusím dát doporučení, jak se takovým problémům vyhnout.

Před zahájením jakéhokoli návrhu musí být mezi Zákazníkem projektu a jeho Developerem stanoven účel a rozsah navrženého zařízení a musí být plně odsouhlaseny všechny jeho technické (taktické a technické) vlastnosti. Za tímto účelem se připravuje speciální dokument - Technický úkol pro návrh tohoto zařízení nebo systému.

V budoucnu jsou pro vývojáře základním, základním dokumentem, který řídí všechny fáze vývoje projektu, podmínky.

Vypracování podmínek zadání je velmi důležitý a odpovědný proces. Chyby v této fázi vývoje mohou vést k velmi vážným následkům.

Vypracování Zadání zpravidla provádějí společně zástupci Zákazníka a Projektanta. Zadávací podmínky vyžadují velkou erudici a zkušenosti od vývojářů. Proto jsou zadání sestavována předními, nejkvalifikovanějšími specialisty s významnými zkušenostmi v této oblasti.

Zadávací podmínky definují hlavní směry vývoje - návrh a princip fungování budoucího produktu (zařízení, systému).

Podmínky zadání jsou počáteční fáze funguje a je sestaven pro veškerý vývoj a typy prací nezbytných k vytvoření nového produktu. Zadávací podmínky mohou také zahrnovat jako jednu z částí dirigování

Výzkumná práce,

experimentální designové práce,

Vývoj automatizačních nástrojů, jednotlivých komponent a systémů, technologie, měřicích nástrojů, kontrolních nástrojů, bezpečnostních opatření atd.

Povinností zákazníka je poskytnout vývojáři spolehlivá počáteční data pro vývoj produktu. Zákazník odpovídá za požadavky na nový produkt a výchozí údaje a plně odpovídá za správnost poskytnutých informací.

Zadávací podmínky by měly obsahovat tři hlavní části:

1. technické a ekonomické požadavky na výrobky, které určují jejich spotřebitelské vlastnosti a efektivitu použití,

2. seznam dokumentů vyžadujících společné posouzení Zákazníkem a Developerem,

3. postup předávání a přijímání výsledků vývoje.

V případě potřeby může zadání obsahovat i požadavky na přípravu a vývoj výroby.

Konkrétní obsah zadávacích podmínek určuje Zákazník a Vývojář, v případě iniciativního vývoje pak Vývojář.

Pokud má Zákazník individuální požadavky na vyvíjené výrobky, které se liší od požadavků norem, ale nesnižují účinnost použití výrobků za stanovených podmínek, měl by získat závěr ze Státní normy Ruské federace o možnost vývoje a výroby těchto produktů.

Do zadání není dovoleno uvádět požadavky, které jsou v rozporu s požadavky norem a regulačních dokumentů orgánů vykonávajících dozor nad bezpečností, zdravím a ochranou přírody.

Zadávací podmínky by měly obsahovat co nejvíce informací, aby se usnadnila práce projektanta a zkrátila se doba vývoje.

Kvalita zadání je zajištěna objemem a úplností sbírky materiálů nezbytných pro vývoj. Při vývoji se používají následující materiály:

vědecké a technické informace,

patentové informace,

Charakteristika prodejního trhu,

Charakteristika výroby, kde bude výrobek vyráběn (technologické vybavení, kvalifikace personálu, úroveň organizace práce atd.).

V rámci zadání jsou zpravidla stanoveny následující ukazatele vyvíjeného produktu:

Předpokládané ukazatele technická úroveň a kvalitu

hlavní účel,

Charakteristika prodejního trhu,

Technické a výkonové vlastnosti,

úroveň standardizace a sjednocení,

Technické a ekonomické ukazatele

patentové a právní ukazatele,

Zvláštní požadavky na produkt atd.

Podmínky jsou vyvíjeny a schvalovány způsobem stanoveným zákazníkem a vývojářem.

Obecný postup pro vývoj a schvalování podmínek je stanoven státní normou Ruska GOST 15.001-88

Zadání stanoví fáze vývoje a načasování každé fáze a vývoje jako celku.

Zadávací podmínky jsou vypracovány v souladu s obecnými požadavky na textové designové dokumenty v souladu se státní normou GOST 2.105-95.

stůl 1