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

Vývoj technických špecifikácií je základom vytváraného automatizovaného systému. V akom štádiu implementácie EDMS by mal byť tento dokument vytvorený a čo by mal obsahovať? Prečítajte si odpovede na tieto základné a mnohé ďalšie dôležité otázky súvisiace s vývojom zadávacích podmienok v tomto článku.

Zadanie (ďalej len TOR) je výsledkom analýzy procesov organizácie a koncepčných návrhov na automatizáciu týchto procesov. Pred vytvorením TOR je potrebné vykonať informačný prieskum procesov, ktorý je vypracovaný vo forme správy o prieskume, a vyvinúť koncept automatizácie, ktorý obsahuje samotnú myšlienku automatizácie a odhaľuje ciele automatizácie a poskytuje aj základné návrhy architektúry a zloženia systému. Zároveň by mala byť správa o informačných procesoch a koncepcia vypracovaná v dvoch paradigmách: „ako je“ a „ako by malo byť“. Veľmi užitočným doplnkom týchto reportov bude grafické zobrazenie procesov (tzv. procesné modelovanie) v ľubovoľnej zvolenej metodike. Najbežnejšou metodikou v ruskej praxi sú dnes notácie ARIS* s rovnakým názvom súprava nástrojov a UML**. Vývoj EDMS je vždy projektovou činnosťou, ktorá má začiatok a koniec. Vývoj končí prechodom systému do komerčnej prevádzky a začiatkom procesu údržby EDMS.

Projektoví manažéri pre vývoj EDMS majú vždy na výber, ktorou metódou sa budú pri vytváraní systému riadiť: kaskádovým modelom alebo iteračným.

1. Kaskádový model.

Kaskádový alebo klasický vývojový model model vodopádu- vodopádový model) - model procesu vývoja softvéru, v ktorom proces vývoja vyzerá ako tok, ktorý postupne prechádza fázami analýzy požiadaviek, návrhu, implementácie, testovania, integrácie a podpory.

Vo vodopádovom modeli idú fázy vytvárania EDMS jedna za druhou, výsledky jednej fázy sa vyvinú do výsledkov ďalšej. Pri tomto modeli je návrat do predchádzajúcej fázy značne problematický a vyžaduje si revíziu a prehodnotenie mnohých postulátov projektu. Podľa tejto metodiky sú postavené ruské GOST.

2. Iteračný model.

Iteračný prístup iteráciu- opakovanie) - vykonávanie práce súbežne s priebežnou analýzou získaných výsledkov a úpravou predchádzajúcich etáp práce. Zároveň vývoj v každej fáze vývoja prechádza opakujúcim sa cyklom: plánovanie – implementácia – overovanie – hodnotenie.

Iteračný vývojový model je postupný vývoj v každej fáze, v ktorom prebieha kompletný proces vytvárania EDMS, avšak v obmedzenom množstve funkcionality. Proces vývoja pozostáva z takýchto iterácií s neustálym zvyšovaním funkčnosti.

Ktorý z týchto prístupov je správny, závisí od konkrétneho projektu (rozsahu projektových úloh) a od želaní zákazníka.

Napriek tomu, bez ohľadu na zvolený model vývoja, v každom z nich existuje fáza tvorby požiadaviek na vytvorený EDMS. Táto fáza a pravidlá vytvárania samotnej TK sú opísané v ruskej legislatíve, konkrétne v GOST 34. Základné dokumenty - GOST 34.602-89. Informačné technológie. Súbor noriem pre automatizované systémy. Referenčné podmienky pre vytvorenie automatizovaného systému a RD 50-34.698-90. Metodické pokyny. Informačné technológie. Súbor noriem a smerníc pre automatizované systémy. Automatizované systémy. Požiadavky na obsah dokumentu.

V iteračnom prístupe sa pri prvom vytváraní požiadaviek vytvorí TOR a s následným objasnením požiadaviek, súkromné ​​referenčné podmienky (ChTZ).

Zloženie zadávacích podmienok

Podľa GOST 34.602-89 sú hlavné časti TK:

1. Všeobecné informácie.

2. Účel a ciele tvorby (vývoja) systému.

3. Charakteristika objektov automatizácie.

4. Systémové požiadavky.

5. Skladba a obsah práce na tvorbe systému.

6. Poradie kontroly a akceptovania systému.

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

8. Požiadavky na dokumentáciu.

9. Zdroje rozvoja.

Všetky tieto oddiely sa dajú rozdeliť na pododdiely a môžu obsahovať prílohy, ktoré sú uvedené na konci dokumentu a sú vypracované ako prílohy k zadávacím podmienkam. CTZ má rovnaké zloženie, ktoré môže byť vytvorené iteratívnym prístupom vo veľkých projektoch na objasnenie požiadaviek. Vyhlásenie o práci pre EDMS musí byť vypracované na listoch formátu A4 v súlade s GOST 2.301-68 * bez rámu, hlavného nápisu a ďalších stĺpcov.

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

Titulná strana TK obsahuje tieto údaje:

Griffin "Schvaľujem";

Úplný názov EDMS;

Názov dokumentu (v našom prípade - "Podmienky referencie" a "Súkromné ​​referenčné podmienky");

Kód dokumentu;

Počet listov;

Umiestnenie dokumentu.

Schvaľovacie víza môžu byť nalepené aj na titulnej strane, alebo sú umiestnené na samostatnom schvaľovacom hárku. Ďalší za titulnou stranou je list s informáciami o tvorcoch dokumentu – autoroch, ktorí zostavili text dokumentu alebo urobili technické riešenia opísané v ZP. Schvaľovací hárok a informácie o vývojároch dokumentu je možné vypracovať na jednom hárku ZP - poslednom, v súlade s odporúčaniami GOST 34.602-89 (dodatok 3 k GOST).

Kód TK pre EDMS je označenie projektového dokumentu, ktoré prideľuje zákazník alebo vývojár dokumentu v súlade s GOST 2.201-80**. Kód sa skladá z nasledujúcich častí: prvé 4 znaky - kód vývojárskej organizácie, ďalších 6 znakov - kód klasifikačnej charakteristiky, ďalšie 3 číslice - sériové registračné číslo. Číslo TK môže vyzerať napríklad takto:

TsNTP. 425180,048.

Vlastnosti písania niektorých častí TK

kapitola" Všeobecné informácie» by mala obsahovať informácie o objednávateľovi a možnom realizátorovi diela, o spôsobe určenia zhotoviteľa, rozpočte, z ktorého je tvorba EDMS financovaná a približný časový harmonogram a etapy prác na tvorbe EDMS.

V tejto časti môže byť napríklad uvedené, že dodávateľ je určený uzavretím štátnej zmluvy.

kapitola" Účel a ciele tvorby (vývoja) systému» by mal obsahovať popis hlavného účelu vytvorenia systému a výsledkov, ktoré zákazník od implementácie systému očakáva. Tieto výsledky musia byť ekonomicky merateľné alebo môžu byť špecifikované spôsoby ich merania.

Účelom zavedenia EDMS môže byť napríklad skrátenie času na odsúhlasenie zmlúv na 1 pracovný deň pre všetky pobočky spoločnosti.

kapitola" Charakteristika objektov automatizácie» obsahuje popis procesov v organizácii, ktoré vyžadujú automatizáciu, a je výsledkom správy z informačného prieskumu, ktorá sa zostavuje pri prieskume procesov organizácie.

kapitola" Požiadavky na systém„je hlavnou časťou TOR. Tejto časti by sa mala venovať osobitná pozornosť, pretože je to on, kto reguluje a opravuje mnohé technické vlastnosti budúceho systému.

Táto časť by mala popisovať nasledujúce požiadavky:

1. Požiadavky na systém ako celok vrátane požiadaviek na architektúru systému, skladbu pracovísk, požiadavky na personál systému, požiadavky na spoľahlivosť, požiadavky na ergonómiu, požiadavky na zabezpečenie utajenia (ak sa v systéme spracúvajú dôverné dokumenty), požiadavky na ochranu informácií pred neoprávneným prístupom, požiadavky na škálovanie systému a iné.

2. Požiadavky na funkcie (úlohy) vykonávané systémom musia obsahovať popis funkčnosti podsystémov (modulov) EDMS.

3. Požiadavky na interakciu subsystémov (modulov) EDMS musia popisovať mechanizmy interakcie subsystémov (modulov).

4. Požiadavky organizácie na prepojenie so susednými systémami by mali popisovať, ktoré systémy susedia a ako môžu byť prepojené s ERMS.

Napríklad HR systém môže poskytovať zoznamy užívateľov pre ERMS. 5. Požiadavky na režim prevádzky EDMS by mali obsahovať popis režimu prevádzky (napríklad 24 hodín 7 dní v týždni) a postup vykonávania preventívnych prác na preinštalovanie systému alebo jeho aktualizáciu.

Napríklad aktualizácia systému by sa mala vykonať bez zastavenia fungovania systému.

6. Požiadavky na druhy podpory musia obsahovať: jazykovú podporu systému, požiadavky na vstupné a výstupné formy EDMS, požiadavky na databázy, požiadavky na organizačné zabezpečenie, požiadavky na informačnú, softvérovú a hardvérovú podporu systému.

7. Požiadavky na správu systému s popisom úloh a zodpovedností správcov systému.

Časť „Zloženie a obsah práce na vytvorení systému“ by sa mala vykonať vo forme tabuľky s názvami etáp práce na vytvorení EDMS, približné dátumy začiatku a konca etáp, ako aj výsledky dokončenia týchto etáp.

Časť „Postup kontroly a prevzatia systému“ by mala určiť, aké typy skúšok sa musia vykonať na akceptáciu systému, vrátane zoznamu dokumentácie požadovanej pre tieto skúšky.

Napríklad na uvedenie systému do prevádzky je možné vykonať oddelené testy v súlade s programom a metodikou testovania vyvinutou a schválenou zákazníkom.

kapitola" Požiadavky na skladbu a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky» popisuje zoznam činností pre školenie používateľov EDMS, pre vypracovanie manuálov a metodických materiálov, požiadavky na konverziu údajov alebo zadávanie prvotných údajov do EDMS, požiadavky na vytvorenie infraštruktúry pre fungovanie EDMS.

Časť Požiadavky na dokumentáciu popisuje všeobecné pravidlá pre zostavovanie pracovnej dokumentácie pre systém a môže odkazovať na podnikové normy alebo GOST.

kapitola" Zdroje rozvoja“je konečná a uvádza dokumenty, ktoré slúžili ako základ pre vývoj systému a prijatie určitých technických riešení.

Zároveň by mali byť v texte TOR uvedené odkazy na všetky zdroje rozvoja. Uvedenie jedného alebo druhého zdroja musí byť odôvodnené a potvrdené v texte ZP.

Dúfame, že po prečítaní tohto článku ste sa bližšie zoznámili s regulačným rámcom ZP, jeho zložením a obsahom a ste pripravení pracovať s týmto dokumentom.

* ARIS (angl. Architecture of Integrated Information Systems) – metodológia a replikovaný softvérový produkt, ktorý vlastní Software AG
pre modelovanie obchodných procesov organizácií.
** UML (angl. Unifi ed Modeling Language) - grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru; bola vytvorená s cieľom definovať, vizualizovať, navrhovať a dokumentovať prevažne softvérové ​​systémy.

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

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

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

GOST 34

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

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

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

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

GOST 19

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

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

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

IEEE STD 830-1998

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

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

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

1. Úvod

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

2. Všeobecný popis

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

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

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

4. Aplikácie
5. Abecedný register

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

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

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

Otázka „Je vôbec potrebné vypracovať technickú úlohu (TOR)? môže vzniknúť len pre tých, ktorí si výstavbu lokality v živote neobjednali, keďže jej potreba vzniká už po prvej komunikácii medzi objednávateľom a zhotoviteľom.

ToR je dokument, ktorý podrobne a úplne popisuje budúci projekt. Čím je detailnejší, tým presnejšie sa nápad zrealizuje a pri realizácii projektu vznikne menej konfliktov a sporov, pretože úplne čokoľvek sa dá robiť rôznymi spôsobmi. Môžete sa naň odvolať, ak sa niečo neurobí, urobí zle alebo sa vyskytli iné chyby. Zákazník zvyčajne pred začatím prác popíše budúci projekt formou diplomovej práce alebo vyplní brief a zhotoviteľ všetky tieto požiadavky a priania formalizuje, v prípade potreby navrhne úpravy. Zákazník sa zároveň musí uistiť, že všetky jeho „zoznamy prianí“ sú v týchto úlohách zafixované.

Ak je zmluva o vývoji stránky uzatvorená s webovým štúdiom alebo freelancerom, potom táto úloha zvyčajne prichádza ako príloha k nej. A v kontroverzných situáciách sa riadia tým, čo je tam napísané.

Z čoho je TK vyrobený?

Predpokladajme, že v rámci projektu je potrebné vypracovať technickú úlohu na vývoj webovej stránky copywritingového štúdia Pero. Aké položky by mal obsahovať?

Všeobecné informácie (popis)

Tu sú uvedené:

Informácie o spoločnosti. Všeobecné informácie o štúdiu, čo robí. Poskytnutie zoznamu poskytovaných služieb nebude zbytočné. Tu môžete pridať aj adresu budúcej stránky, kontaktné údaje.

Etapy a termíny realizácie projektu. Veľmi dôležitým bodom je spravidla kalendárny plán pre všetky fázy práce na samom konci. Táto časť poskytuje pochopenie toho, čo sa bude robiť a kedy. Napríklad (s dátumami):

• Prípravná fáza;
• Vývoj koncepcie webových stránok;
• Dizajn;
• Vytvorenie dizajnu;
• Vývoj dizajnu stránok;
• Rozloženie;
• Programovanie;
• Obsah náplne;
• SEO optimalizácia;
• Testovanie;
• Spustiť.

Nesmú existovať žiadne fázy, napríklad propagácia SEO. Závisí od cieľov a zámerov objednávateľa a kompetencií zhotoviteľa.

Účel a ciele

Tu je formulované, aké funkcie bude stránka plniť a pre koho je určená.

Účel stránky. Aké sú ciele pri vytváraní stránky? Na čo slúži, aké úlohy rieši?

• Reklama a prilákanie nových zákazníkov;
• Zákaznícka a partnerská podpora;
• Ukážka vykonanej práce;
• Oboznámenie sa so zoznamom služieb;
• Vytváranie a udržiavanie imidžu spoločnosti.

Možno by bolo potrebné podrobnejšie opísať niektoré body. Napríklad, ak je stránka postavená pred úlohu informovať návštevníkov, je lepšie vysvetliť, čo presne.

cieľové publikum. Kto bude stránku používať, pre koho je vytvorená?

• Webmasteri, blogeri;
• Majitelia internetových obchodov;
• Vlastníci informačných portálov;
• Reklamné štúdiá;
• Zástupcovia firiem a spoločností pôsobiacich v online priestore.

Požiadavky

Veľká a mimoriadne dôležitá sekcia, ktorá zohľadňuje čo najviac aspektov dizajnu a vývoja, pretože za funkcionalitu neuvedenú v TOR si zákazník bude musieť priplatiť.

Typ. Do ktorej kategórie patrí webový zdroj?

• Vstupná stránka;
• Stránka s vizitkami;
• Firemná webová stránka;
• Informačný portál;
• Internetový obchod.

Požiadavky na dizajn. Môžu mať nasledujúcu formu:

• Stránka by mala byť minimalistická a zároveň odrážať typ činnosti spoločnosti.
• Primárne farby: zelená a biela, podľa knihy značiek alebo podľa uváženia dizajnéra.
• V dizajne nie je možné použiť animáciu, vyskakovacie okná, Flash prvky, dizajnové excesy.
• Nemožno použiť pätkové fonty (možno použiť štandardné fonty: Verdana, Arial, Tahoma atď.). Veľkosť by mala poskytovať maximálnu čitateľnosť (12-16 bodov).

Pokiaľ ide o požiadavky na dizajn, možno použiť rôzne prístupy. Ak zákazník sám presne vie, čo chce dostať, potom podrobne opíše svoje želania, uvedie príklady stránok, ktoré sa mu páčia a uvedie ďalšie špecifiká. Niekedy sa ale stane, že ani on sám presne nevie, ako to má všetko vyzerať, v tomto prípade väčšinou vychádzajú z úloh, ktoré by mal návrh riešiť. Zhotoviteľ vypracuje koncepcie, navrhuje riešenia, obhajuje svoju predstavu a koriguje ju podľa pripomienok objednávateľa. Druhá možnosť je drahšia a vyžaduje si od dodávateľa väčšiu kvalifikáciu.

Jazykové požiadavky. Ktorý rodný jazyk bude môcť navštíviť zdroj? Aké jazykové verzie by mala stránka obsahovať?

• ruský;
• Angličtina;
• Esperanto.

Požiadavky na kompatibilitu. Z akých zariadení a akých prehliadačov sa stránka otvorí správne? V poslednej dobe je trend k adaptívnemu rozloženiu, kedy sa stránka správne zobrazí na akomkoľvek zariadení s ľubovoľným pomerom strán a rozlíšením obrazovky. Tu môžete uviesť zoznam prehliadačov, s ktorými musí byť zdroj jednoznačne kompatibilný. Vo všetkých moderných prehliadačoch sa stránky zvyčajne zobrazujú rovnako, problémy sú len so staršími verziami programu Internet Explorer.

Požiadavky na CMS. Možnosti správy lokality určujú, ktoré bloky je možné upravovať a konfigurovať prostredníctvom ovládacieho panela bez zásahu do kódu a bez priamej úpravy databázy, ale s použitím pohodlného vizuálneho rozhrania. Môžete to dať napríklad takto:

• Schopnosť meniť obsah na stránkach lokality;
• Schopnosť spravovať stránky (pridávanie, premenovanie, mazanie atď.);
• Schopnosť upravovať štruktúru stránky a položky ponuky;
• Funkcie pre automatické spracovanie grafiky (vytváranie náhľadov, transformácia na danú veľkosť atď.);
• Schopnosť predpísať jedinečné meta tagy;

Rovnako ako v iných podsekciách musíte opísať všetky požiadavky a želania.

Často už má zákazník skúsenosti s niektorým z populárnych CMS, vtedy je vhodné hľadať dodávateľov pre konkrétny motor. Taktiež pri výbere CMS je lepšie neuspokojiť sa s vlastnými riešeniami, pretože. V budúcnosti to bude závisieť od interpreta. Vlastnoručne napísané motory majú podľa mňa opodstatnenie len vo veľmi veľkých projektoch, kde je potrebná špecifická funkcionalita alebo optimalizácia veľkých záťaží.

Štruktúra a navigácia. Aké sekcie, podsekcie a jednotlivé stránky bude projekt obsahovať?

• Hlavná stránka
• Služby

• Copywriting
• Prepisovanie
• SEO copywriting
• korektúry
• prepis
• Obsahový management
• Obsahový marketing

• Portfólio
• O nás
• Kontakty

Urobte a stručne popíšte každú stránku, uveďte definície. Čo napríklad znamená stránka „Kontakt“? Má obsahovať adresu, telefón a e-mail ako obyčajný text? Alebo by mal existovať formulár spätnej väzby? Alebo možno potrebujete vložiť kód máp Yandex? Alebo by mala kontaktná stránka obsahovať všetko vyššie uvedené a dokonca aj odkazy na zastúpenia v sociálnych sieťach?

Pred začatím prác so zhotoviteľom je žiaduce pripraviť obsah, alebo aspoň jeho osnovu. To umožní efektívnejšiu komunikáciu.

Ďalšie požiadavky. Všetko, čo nie je zahrnuté v ostatných odsekoch sekcie.

Popis sekcií lokality

Tento odsek obsahuje podrobnosti. Zvyčajne je podpísaný obsah všetkých jedinečných stránok: aké prvky tam budú, ako s nimi bude používateľ interagovať.

Hlavná stránka. Formulácia problému môže byť v nasledujúcej forme.

Hlavná časť hlavnej stránky by mala byť vytvorená vo forme Landing Page . Mal by obsahovať nasledujúce prvky zhora nadol:

• Klobúk - logo, názov spoločnosti;
• navigačné menu;
• Informácie o akciách a zľavách;
• tlačidlo objednať;
• Reklamné texty;
• Blok s piatimi najlepšími prácami a odkazom na sekciu portfólia;

vývoj (nielen), praktická príprava technických špecifikácií. B o väčšia časť už pripravený k použitiu logické prvky TK sú uvedené na konci článku. Vydanie zo dňa 20.06.2018.

Ako napísať technickú úlohu?

Vytvorené dňa 2.5.2005 11:41:19

Tvoj svet je prázdny...

Kto bude zdieľať tvoj smútok?

Ako napísať technickú úlohu? - z pier tzv. nováčik „technický spisovateľ“, ďalej len techpis. Tu to je - strašná cena rozpadu Únie a prechodu ruského vysokého školstva na dvojstupňový vzdelávací systém.

Vráťme sa k otázke. Pri "rozložení" sa ukáže:

• prvá otázka je „prečo je to potrebné“;
• druhá otázka – aká by mala byť štruktúra sekcií „Zadávacie podmienky“;
• tretia otázka - aké sú spôsoby prípravy textov obsahu častí zadávacích podmienok?

Tretia je najťažšia. Odpovede na tieto otázky sa objavia v priebehu prezentácie.

Ciele a zámery článku

Účelom článku je uľahčiť život úplne začínajúcim technickým spisom.

Ciele článku:

• dať odpovede na otázky;
• preukázať nevyhnutné minimum praktickej prípravy textov technických špecifikácií;
• dať šancu začínajúcemu technikovi:
  • zvýšiť svoje vlastné hodnotenie;
  • alebo sa konečne ponorte do očí Veľkého šéfa.

Príbeh

Všetko, čo sa kedy vyrobilo, vyrába a bude vyrábať, sa delí (samozrejme podmienečne) na:

Prvým () produktom bola možno kamenná sekera. Alebo (umelo vytvorený) hlinený črep (), ktorý vám umožňuje nabrať trochu vody v potoku.

Prvý softvérový produkt implementovaný na „hardvér“ bol možno „jukebox“ s rotujúcim diskom posiatym kolíkmi. Kolíky v určitom čase narazia na určitú ladičku. Ukázalo sa teda, že melódia je naprogramovaná, „pripojená“ na kovovú - skutočný softvérový produkt, len nie, ale ručná práca. Tento nádherný zázrak môžete vidieť v Polytechnickom múzeu v Moskve.

Veterný mlyn mohol byť prvým automatizovaným systémom. Vytiahol zátku - „čepele“ sa otáčajú, mlynské kamene mlátia. "Stlačenie jedného tlačidla" - 100 percentná automatizácia.

Príbeh, ktorý mrazí na duši

A potom cár potrestal () - postaviť mlyn, a to taký, aby fungoval silou vetra, chladnejšie ako ten od anglického kráľa („Zoznam prianí“ zákazníka), a aby závisť všetkých buržoázne (zodpovedajúce modernému rozvoju vedy a nie nižšie ako podobné požiadavky, prezentované najlepším moderným domácim a zahraničným analógom).

Gardisti odvliekli poddaného panovníka, miestneho múdreho muža (), cára-otca hodili pod nohy. Remeselník bojoval čelom o kamennú podlahu – teda, samozrejme! Urobme to, Vaše Veličenstvo, všetko bezpodmienečne, presne, včas a naplno!

Nastal čas, kráľ prišiel do mlyna (diela). Pozerá a čuduje sa – krídla sa točia, mlynské kamene mlátia zhito, múka sa sama sype do vriec! (Úplný súlad s požiadavkami na funkcie (úlohy) vykonávané systémom). Áno, vezmite si to a strčte ruku do tašky ... (ktorá tiež nebola poskytnutá, alebo, keďže žiadne neboli).

Kráľ zfialovel - no, smrad, tento mlyn neslušne melie múku?! (Nekonzistentnosť vyrobených požiadaviek GOST 7045-90 Ražná múka na pečenie.). Strážcovia chytili roľníka a bili ho kamennou sekerou po jeho násilnej malej hlave. A Lefty ukončil svoj život za zvukov Mozartovho "Requiem" z jukeboxu ...

závery

V dávnych dobách vo vzťahoch medzi stranami, objednávateľom a zhotoviteľom (developerom) rovnosť nestačila. Niečo, samozrejme, vzťah bol regulovaný. Je možné, že sa pripravovali listy z brezovej kôry - prototypy moderných zmlúv. Je nepravdepodobné, že by takéto zmluvy mohli zohľadňovať všetko, dokonca aj kvalitu brúsenia. A neexistovali žiadne všeobecne uznávané, v širšom zmysle, všetky aspekty vzťahu medzi zákazníkom a dodávateľom.

Boli vydané dekréty, príkazy - „na Moskovskej univerzite musia študenti sedieť na slame, smrkať do päste, utierať si nos zväzkom slamy. A tí, ktorí porušujú pravidlá týchto prútov, aby nemilosrdne trhali "(alebo niečo také).

Ani teraz neexistuje rovnosť – kto platí, objednáva hudbu. A zákazník platí.

Poznámka zo dňa 5.10.2014 - Ale nie všetko je také smutné.Ak budete konať múdro, ľahko ohnete každého zákazníka, uvidíte a.

Aktuálny stav

A bolo vynájdené, že nádrž bola vyrobená ...

zo série "Armádne vtipy"

Unavení z „zákazníckeho“ bezprávia sa umelci (vývojári) zhromaždili (v poslednej štvrtine dvadsiateho storočia), zorganizovali „“ a vyrobili tank – na konštrukcii a (presnejšie) dokument s názvom „technické zadanie“ . Treba si uvedomiť, že autorské tímy sa skladali spravidla z ľudí technicky gramotných, rozmýšľajúcich a hľadiacich do ďalekej budúcnosti.

Možno bolo všetko inak, ale celkovo sa ukázalo, že tank je dobrý - čo potvrdzujú zástupcovia spoločnosti GOSTANDART aj recenzie skúsených vývojárov.

Zadávacie podmienky a ich účel

Pre Big Bossa, ktorý je v priamom kontakte so zákazníkom, umožňujú referenčné podmienky vyhnúť sa osudu remeselníka (to už bolo spomenuté viac ako raz).

Pre malý technický kus pracujúci pre Big Boss je vývoj technickej úlohy:

• prostriedok, ako si na seba zarobiť „stále jesť“;
• spôsob, ako ukázať, že techpis nie je chvejúci sa tvor, ale má právo ním byť – spôsob, ako rásť v očiach Veľkého šéfa.

Extrémne tvrdenie je trojsečný meč. Och, si šikovný, však? Takže stále máte čo robiť. Zvýšme plat. Raz.

V každom prípade je schopnosť kompetentne vypracovať technickú úlohu (najmä vlastníctvo) indikátorom vysokej kvalifikácie vývojára.

Domnievame sa, že prvá otázka (v prvej aproximácii) je uzavretá.

GOST pre technické špecifikácie

Krík je súbor vetiev vyrastajúcich z jedného bodu.

vojenská múdrosť

Po tvrdej práci (a utrpení) boli zverejnené najmenej štyri dokumenty, zodpovedajúce veľmi podmienenému rozdeleniu produktov ľudského života:

Poznámky:

1. Existujú aj iné domáce GOST, ktoré obsahujú požiadavky na obsah a dizajn dokumentu "Referenčné podmienky". Táto skutočnosť je spôsobená špecifikami. Uvedené štyri boli a zostávajú pre väčšinu tematických oblastí;
2. Zadávacie podmienky boli a zostávajú základným dokumentom, samotnou „oporou“, z ktorej všetko vyrastá.

Čo majú spoločné časti vyššie uvedených dokumentov? Akékoľvek zadávacie podmienky by mali obsahovať časti odzrkadľujúce informácie:

• čo treba urobiť;
• prečo, na aký účel je to potrebné urobiť;
• kde, v akej oblasti použitia, na akom objekte by mal rozhodnúťúlohy a splniť ich funkcie;
• aké požiadavky mu budú predložené;
• akú prácu bude potrebné vykonať, aby sa to podarilo;
• aký je postup pri realizácii a prevzatí-dodaní diela objednávateľovi;
• ako by sa mala práca vykonávať;
• a nakoniec, na základe akých regulačných a technických dokumentov by sa mala práca vykonávať?

Toto je všeobecná štruktúra častí zadávacích podmienok. Druhú otázku považujeme za uzavretú.

Pre produkt bolo potrebné vyvinúť technickú úlohu - používame GOST 2.114-95, pretože GOST 15.001 je krivka životnosti a časti technických špecifikácií (ako celok) zodpovedajú častiam technickej úlohy. Je to potrebné - otvárame GOST 34.602-89. Dňa - GOST 19.201-78.

Ukážeme nevyhnutné minimum praktických techník, ktoré umožňujú aj tým najnovším technickým špecifikáciám okamžite začať s vývojom obsahu sekcií zadávacích podmienok a dosiahnuť prijateľné výsledky (samostatné hotové konštrukčné prvky zadávacích podmienok podľa GOST 34.602- 89 nájdete v „suteréne“ tohto článku).

Praktické techniky

Praktické metódy na vypracovanie technických špecifikácií sa získavajú doslova utrpením na základe skúseností z interakcie so zákazníkom, samotným autorom aj jeho staršími súdruhmi, za čo sa im klaniame, česť a rešpekt (teraz a navždy, navždy a vždy. Amen).

Úplne prvým trikom je vytvorenie dokumentu so štruktúrou sekcií podľa GOST. Ak si šéf stanovil úlohu vyvinúť technickú úlohu, napríklad v automatizovanom systéme, GOST 34.602-89 sa stiahne vo forme súboru, potom sa jednoducho otvorí vo formáte Word a vo formáte bodky.

Elektronické verzie GOST uložené na webovej stránke vo všeobecnosti zodpovedajú oficiálnym verziám. Pochybné body sa dajú vždy skontrolovať porovnaním, ak nie lenivosť, samozrejme.

Poznámka z 25.12.2011 - Nie je to tak dávno, čo Rostekhregulirovaniya (protect.gost.ru) začala publikovať oficiálne verzie GOST, avšak zďaleka nie v upraviteľnom formáte...

Detailing

Detailing je jednou zo základných techník. Niektorí ľudia uprednostňujú vedecký termín požičaný od buržoázie - rozklad. Pôjde o spresnenie štruktúry sekcií GOST pre referenčné podmienky.

Spomeňme si na tú rodičovskú – „kým všetko nedáš na police, „nedarí sa ti to (mama)“ alebo „nedarí sa ti to (otec)“. Mama aj otec, samozrejme, mali a majú nekonečnú pravdu. Je nemožné vyriešiť jednoduchý problém vo fyzike, kým nie sú vektory sily rozptýlené pozdĺž osí. Trojitý integrál nie je možné vziať, kým sa integrály nad dx, dy a dz nezoberú postupne. Až na prípad, keď "integrál je taký jednoduchý, že sa dá zobrať aj bez dx".

Náhodne vybraný citát z GOST 34.602-89:

Pre systém sú uvedené požiadavky na použitie v systéme, jazyky interakcie a technické prostriedky systému, ako aj požiadavky na a dekódovanie pre jazyky -, prostriedky popisu (objektu automatizácie), pre organizačné metódy [z článku 2.6.3.3 GOST 34.602-89]

Zd o ruvo, čo? Budeme musieť vyčistiť toto smetisko. takže, explicitné drvenie vytvára ďalšie podpoložky technických špecifikácií (toto sa môže a malo by sa to urobiť).

4.3.2.1 Požiadavky na jazykovú podporu systému

4.3.2.1.1 Požiadavky na používanie vysokoúrovňových programovacích jazykov v systéme

(text požiadavky)

4.3.2.1.2 Požiadavky na jazyky interakcie medzi používateľmi a technickými prostriedkami systému

(text požiadavky)

4.3.2.1.3 Požiadavky na kódovanie údajov

(text požiadavky)

4.3.2.1.4 Požiadavky na dekódovanie údajov

(text požiadavky)

4.3.2.1.5 Jazykové požiadavky I/O

(text požiadavky)

4.3.2.1.6 Požiadavky na jazyky na manipuláciu s údajmi

(text požiadavky)

4.3.2.1.7 Požiadavky na prostriedky opisu predmetnej oblasti (objekt automatizácie)

(text požiadavky)

4.3.2.1.8 Požiadavky na spôsoby organizácie dialógu

(text požiadavky)

Zvýšil sa objem technických špecifikácií? Oplatí sa šetriť papierom? Existuje ešte jedna vojenská múdrosť, nech to znie akokoľvek neslušne a nejednoznačne: „viac papiera – čistejšie s@@@@tsa“. Vyjasnili sa požiadavky na jazykovú podporu?

Poznámka - Pojmy "zrozumiteľnosť", "" (zrozumiteľnosť) sa vyskytujú v niekoľkých GOST naraz. Tu je kvintesencia – „úplnosť niečoho, čo charakterizuje cenu ľudského úsilia pochopiť logickú koncepciu tohto niečoho“.

Po transformácii pevného textu na enumeráciu (, pododdiely, pododstavce) trvalo autorovi menej času (a úsilia), aby pochopil (aspoň zapamätal si) logickú štruktúru referenčných podmienok, pretože pododstavce sa stali jasne „viditeľnými“.

Detail, detail a ešte detail. Na prijateľnú (atómovú) úroveň.

Šablónová konštrukcia fráz

Mali by ste vziať do úvahy skutočnosť, že v každej otázke (správne položenej) je polovica odpovede. Predpokladajme, že je potrebné sformulovať text pododstavca „Požiadavky na použitie v systéme“. Takže:

4.3.2.1 Požiadavky na používanie vysokoúrovňových programovacích jazykov v systéme

V systéme musieť byť (presne musieť- to je všetko!) Používajú sa nasledujúce programovacie jazyky na vysokej úrovni:

• jazyk C++;
• jazyk Pascal;
• atď.

Pre tých, ktorí sa necítili, ako zostaviť frázu, vľavo je schéma jej konštrukcie.

4.1.2 Požiadavky na počet a kvalifikáciu personálu systému a spôsob jeho prevádzky

(upresňujeme - vytvárame pododstavce 4.1.2.1, 4.1.2.2 a 4.1.2.3)

(správne formulujte text pododstavca - odpovedzte na otázku, aké požiadavky má spĺňať počet zamestnancov)

Počet zamestnancov musieť spĺňať požiadavky :

• postačovať na implementáciu automatizovaných () systémov vo všetkých prevádzkových režimoch systému;

4.1.2.2 Požiadavky na kvalifikáciu personálu

Kvalifikácia personálu musieť poskytnúť efektívne fungovanie techniky a systému vo všetkých prevádzkových režimoch systému“

C, v rozhodnutiach o kvalifikácii zamestnancov bude možné spresniť, že na základe skúseností z viac ako stovky predtým vyvinutých podobných systémov musia mať zamestnanci vzdelanie aspoň troch tried farskej školy. Toto vyhlásenie zákazníka poteší. Bude možné využiť superlacnú pracovnú silu. Ale o tom v ďalších článkoch.

4.1.2.3 Požiadavky na spôsob práce personálu

Pracovný režim personálu je nepretržite trojzmenný.

V pododdiele sa uvádza aj postup na školenie personálu, monitorovanie vedomostí a zručností. O zložení - ani slovo. A je to správne. Zloženie personálu, jeho rozdelenie na prevádzkové (), opravárenské atď., sa určuje pri navrhovaní systému. Aj keď nikto nemôže zakázať doplniť do zadávacích podmienok požiadavky na zloženie personálu. Možno to nestojí za to.

Jednoduché, ale vkusné. Čistá prax, bez hlbokého ponorenia sa do jazykových jemností. Podrobnosti a špecifické požiadavky zadávacích podmienok.

Formalizácia pri príprave textu zadávacích podmienok

Možno dvesto možností

Jedna z dvoch stoviek možností na dekódovanie skratky "VDV"

Vráťme sa k príkladu z predchádzajúcej podsekcie článku.

4.1.2.1 Požiadavky na personál

Počet zamestnancov musí spĺňať tieto požiadavky:

• postačovať na implementáciu automatizovaných systémov vo všetkých režimoch prevádzky systému;
• zabezpečiť plnú zamestnanosť personálu pri implementácii funkcií automatizovaného systému a pod.

Rezance sú úplné, ale formálne je všetko správne. Odporúča sa použiť, ak nie je možné špecifikovať žiadnu položku zadávacích podmienok. Ak tam Big Boss nie je, môžete ho slušne požiadať, aby objasnil požiadavky zákazníka na túto položku, aby poskytol presnejšie informácie. Toto je právo na technické písanie, nie na priamy kontakt so zákazníkom.

Môžete pridať - "počet personálu je uvedený na "Technickom prevedení"". Big Boss bude ohromený znalosťami technikov (aj keď sa nevyzná) o stupňoch a automatizovaných systémoch. A ak verbálne vyzvete šéfa, aby (neskôr) do projektu pridal vetu – „na základe skúseností s viac ako stovkou predtým vyvinutých podobných systémov by počet zamestnancov mal byť 10 pracovných miest“ – šéf bude nadšený. miesto. Môžete bezpečne pripraviť príkaz na vymenovanie technika na pozíciu systémového analytika (čo tiež nie je v celoruskom klasifikátore). Alebo počkajte na prácu navyše, keďže je taký šikovný.

Poznámka zo dňa 17.04.2018 - V OKPDTR nie je ani pozícia technického platiteľa. A pozícia zakladača textu zostala zo starých čias

Pečiatky a zjednotenie pri príprave textu zadávacích podmienok

Vy ženy ste krásne

A ja - bez prikrášlenia

Ale aj tak, muži

Opúšťam ťa...

Y. Rybchinsky, "Dve sestry"

text zadávacích podmienok sa dosiahne použitím pečiatok. V prvom rade by ste sa mali dozvedieť jednoduchú pravdu – nikdy, v žiadnom dokumente nie nazývať veci pravými menami .

Predpokladajme, že sa vyvíja univerzálny konvertor energie na energiu ľudskej mysle (Existencia ľudskej mysle je pochybná. Je rozumné zavesiť si na krk prácu vytvorenia takéhoto konvertora? Ale reflexy objektívne existujú). Tento prevodník by mal okamžite v časti „Názov produktu“ nazvať produkt:

Názov produktu - menič energie slnečného žiarenia na energiu ľudskej mysle ( Ďalej podľa textu - Produkt ).

A v texte - Produkt, produkt, produkt ...

To isté platí pre softvérové ​​produkty a automatizované systémy. Názov AS - automatizovaný systém distribúcie objemového krmiva pre dobytok ( Ďalej podľa textu - Systém ).

A v texte - Systém, Systém, Systém ... Program, Program, Program ...

Výsledok - dohnali a naplnili dve muchy jednou ranou. Nebude potrebné odmietnuť-konjugovať celú hromadu slov a bude jednoduchšie čítať referenčné podmienky vytvorené týmto spôsobom.

Poznámka z 5. februára 2010 - Pri automatizovanom vývoji technickej dokumentácie s použitím jedného zdroja je prijateľná ako možnosť so všetkými druhmi deklinácií-konjugácií aj bez nich. Napríklad premennú môžete vytvoriť raz<ЗАО «Заказчик»>a vložiť do požadovaných tém knižnice dokumentov - to je niekedy pohodlnejšie.

Nižšie sú uvedené typické zoznamy pečiatok, ktoré sa dlhodobo úspešne používajú pri vývoji technických špecifikácií (podľa hlavných častí, zvýraznené tučným písmom):

• účel systému - systém zamýšľané pre riešenie nasledujúcich úloh:
  • úlohy taký a taký (prvý);
  • úlohy nejaký jeden (druhý);
  • a tak ďalej.
• ciele vytvorenia systému - Ciele vytvorenie systému sú :
  • zvýšiť rýchlosť...;
  • propagácia presnosť...;
  • znížiť náklady...;
  • pokles spotreba...;
  • zlepšenie ukazovatele...;
  • a tak ďalej.

Akýkoľvek cieľ vždy znamená pozitívne dynamika , zmeniť akékoľvek ukazovatele k lepšiemu. Cieľom je napríklad zlepšiť blahobyt celého sovietskeho ľudu (ale nie komunizmu: komunizmus je cieľom!). Cieľom je zvýšiť spokojnosť zákazníkov. Výnimkou je:

• vytváranie zisku (v kontexte zadávacích podmienok);
• podpisom zo strany zákazníka.

Také triky neexistujú. Príklad z praxe jedného z najctihodnejších techpisov (príklad, ktorý dal sám sebe bez akéhokoľvek nátlaku na jednom z fór techpis) - “ umožňuje... program vystupuje... program robí... ". Vážený pane, technický spisovateľ! Zatiaľ neexistuje žiadny program, ešte nie je vyvinutý, nemá, nemá, nebol, nebol odovzdaný zákazníkovi, preto stále nič neumožňuje, nerobí, nevykonáva. Aký neporaziteľný sovietsky zvyk zbožného želania?!

• požiadavky na funkcie (úlohy) vykonávané systémom - systémom musieť uvedené nižšie funkcie:
  • v rámec najprv úlohy- výkon funkcie taký a taký, taký a taký a nejaký iný;
  • v rámec druhý úlohy- výkon takej a takej funkcie a pod.

Ak funkcia (ako proces) je, potom je poskytnúť schopnosť vykonávať zadanú funkciu. Užívateľ môže odstrániť zátku - mlynček začne mlieť múku. Užívateľ však nesmie odstrániť zátku. AT špecifikované V tomto prípade bude mlyn (systém) v pohotovostnom (nečinnom) režime.

Ak funkcia (ako proces) je, potom by mal systém presne poskytnúť výkon funkcie. Automatickú funkciu spúšťa systémový softvér (bez účasti personálu) podľa určeného harmonogramu a zlučuje databázu.

V rámci rozsahu úloh. Úlohy sú vyriešené a funkcie vykonané. Komu rozhodnúťúlohu, ktorú potrebujete vykonať súbor funkcií, procedúr alebo operácií. Inými slovami, úloha je na rozdiel od výmyslov väčší konštrukčný prvok.

GOST 34.003-90 to dáva dopredu, úloha je akoby súčasťou funkcie. A to je zvláštne: aj v škole každý riešil problémy, kalkuloval hodnoty rôznych funkcií v sebe... A predstavte si, ako divoko by znelo vyhlásenie: „Cieľom strany a vlády je zlepšiť blahobyt. celého sovietskeho ľudu. Na dosiahnutie cieľa si strana stanoví sama seba funkciu poskytnúť každej rodine samostatný byt do roku 2xxx“... (Mimochodom, upratať domy a byty svojpomocne už teraz a najmä raz nie je v móde – na to sú upratovacie firmy). Funkcia je teda súčasťou úlohy a nie naopak. Aj keď je to v rozpore s posvätným GOST 34.003-90.

Takže príklad.

AT rámec úlohy (alebo pre riešenie problémov ) systémový softvér musieť presadiť uvedené nižšie funkcie:

• automatizované funkcie
• automatizovaná funkcia triedenia záznamov v databázových tabuľkách;
• funkcie automatické záloha databázy.

A z predchádzajúcej podkapitoly:

• musieť byť ...;
• musieť spĺňať požiadavky ..

V dôsledku používania pečiatok sa text zadávacích podmienok zjednocuje a formalizuje. žiadne skrášlenie . A zákazník mužský nikam nepôjde od vás, milé technické dievčatá, keďže požiadavky technickej úlohy budú pre neho transparentný.

Zoznamy a číslovanie sekcií

Zoznamy (zoznamy s odrážkami alebo číslované zoznamy) sú veľmi vhodné pri príprave textu zadávacích podmienok. Normálny človek je schopný vnímať (zapamätať si a presne reprodukovať) tri až deväť prvkov zoznamu. Viac ako deväť je znakom génia.

Možno by sa mal počet prvkov zoznamu znížiť. Z hľadiska referencie je to voliteľné. Malo by sa pamätať na to, že referenčné podmienky s mnohými ďalšími dokumentmi sa vyvinuli v rôznych fázach a fázach vytvárania systému (áno, čokoľvek).

Prípad jedna.

"AT rámec úlohy (alebo pre riešenie problémov musieť umožniť implementáciu uvedené nižšie funkcie:

• automatizované funkcie pridávanie záznamov do databázových tabuliek;
• automatizovaná funkcia vymazávania záznamov z databázových tabuliek;

Druhý prípad.

« 4.3.2.1 AT rámec úlohy (alebo pre riešenie problémov ) softvérové ​​nástroje systému správy databáz musieť umožniť implementáciu uvedené nižšie funkcie:

1. automatizované funkcie pridávanie záznamov do databázových tabuliek;
2. automatizovaná funkcia vymazávania záznamov z databázových tabuliek;
3. automatizovaná funkcia na triedenie záznamov v databázových tabuľkách...;"

Zdá sa, že rozdiely sú malé. Ale!

V prvom prípade budete musieť v dokumente "Programové a testovacie metódy" napísať "metódu kontroly výkonu automatizovanej funkcie pridávania záznamov do databázových tabuliek systémom."

V druhom prípade je to len „metóda na overenie splnenia bodu 4.3.2.1 (1) zadávacích podmienok“.

B, v prvom prípade - "sú splnené požiadavky zadávacích podmienok na implementáciu automatizovanej funkcie pridávania záznamov do databázových tabuliek." V druhom prípade - "sú splnené požiadavky ustanovenia 4.3.2.1 (1) zadávacích podmienok." je v tom rozdiel?

Čo sa týka viacúrovňového číslovania oddielov, pododdielov, odsekov a pododstavcov – v praxi sú tieto požiadavky v drvivej väčšine prípadov povinné.

Zoznamy by mali byť „číslované“ nie číslami, ale písmenami:

a) taká a taká funkcia;

Otázka je zásadná, keďže TK pre JE (dodatok k TK) musí byť pred predložením na schválenie skontrolovaná službou organizácie, ktorá TK vypracovala a v prípade potreby podliehať [od vety 8 ods. . 1 GOST 34.602-89]. Ak sú totiž zadávacie podmienky vypracované krivo (formou a podstatou), pokrivkávajú aj projektové a prevádzkové dokumenty.

Trochu o. Ak TOR obsahuje pododdiel „Metrologická podpora ...“, potom sa metrologická skúška musí vykonať v súlade s úplným programom. Ak uvedený pododdiel chýba, metrologické vyšetrenie sa zredukuje na kontrolné skratky v súlade s GOST 8.417. Ale len.

Kopa "všeobecných informácií, účelu a zloženia" v zadávacích podmienkach

Kopa „všeobecných informácií, účelu a zloženia“ sa výborne osvedčila nielen pri vývoji zadávacích podmienok. Odkaz je vhodný pre akékoľvek populárno-náučné popisné texty.

PRÍKLAD Požiadavky na počet úrovní a stupeň centralizácie systému. Tu je štvrtok o dá sa zapísať špecifikované podsekcia technických úloh?

Každá osoba si reflexne prezrie sekcie GOST pre referenčné podmienky a pokúsi sa nájsť aspoň nejakú stopu. Skúsený človek si hneď spomenie na p.

2.1 Účel systému

Súdruh, ktorý niečo priamo spájkuje, niečo upravuje, vždy bude vedieť povedať technikovi, prečo ten systém vzniká. V rámci jeho pôsobnosti, samozrejme. Viac povie systémový inžinier alebo šéf. Povedzme

Systém by mal poskytnúť riešenie (schopnosť riešiť) nasledujúce úlohy:

1. úlohy zhromažďovania údajov z niektorých, povedzme, senzorov;
2. úlohy spracovania, skladovania, vystavenia a pod. v zbernom stredisku.

To je všetko. Trochu fantázie a sekcia je pripravená:

Systém by mal mať hierarchickú štruktúru a mal by zahŕňať nasledujúce úrovne hierarchie:

1. 1. úroveň - úrovni zber dát ;
2. 2. úroveň - úrovni konsolidácia údajov (centralizované spracovanie, skladovanie atď.).

Opäť oba zajace – a na mieste. A sú uvedené úrovne hierarchie a stupeň centralizácie. Čo bude ďalej?

2.1.1 Úroveň zberu údajov

2.1.1.1 Všeobecné informácie

Niektoré všeobecné informácie. Môžete napríklad napísať, že úroveň je charakterizovaná územným rozložením - akákoľvek voda bude stačiť, ak približne zodpovedá.

2.1.2.2 Účel

Úroveň zberu údajov zamýšľané(ďalšia pečiatka):

1. preniesť údaje z niektorých snímačov na úroveň konsolidácie na žiadosť (iniciatívu) extrému (posledného);
2. na zaznamenávanie prenosu údajov do denníka udalostí (a ak podľa GOST, potom c);
3. pre niečo iné.

2.1.2.3 Zloženie

Zberná vrstva by mala obsahovať:

1. také a také senzory;
2. niektoré ďalšie senzory.

Aké je pohodlie používania odkazu „všeobecné informácie, účel a zloženie“? A nedobrovoľne sa získa dobre štruktúrovaná technická úloha - stromová a hierarchická.

2.2.2.3.1 Senzory také a podobné

2.2.2.3.1.1 Všeobecné informácie (o takých a takých snímačoch)

2.2.2.3.1.2 Účel (takýchto snímačov)

2.2.2.3.1.3 Zloženie (také a také snímače)

Hlavná vec je zastaviť sa včas.

POZOR

Počas vývoja a najväčšieho záujmu sú uvedené nižšie:

• predovšetkým -. Lebo taký je;
• , napríklad a;
• , napríklad;
• a napríklad;
• rad ďalších.

Nemali by ste sa nechať uniesť takými "tematickými" GOST, ktoré obsahujú veľmi špecifické požiadavky na. Typickou chybou pre začiatočníkov je "komunikačné kanály musia spĺňať požiadavky GOST také a také." Toto je fatálna chyba. Je známe, že prevzatiu a odovzdaniu práce na vytvorení systému, produktu, softvérového produktu vždy predchádza realizácia.

Predpokladajme, že Big Boss, ohromený hlbokými znalosťami technického písania, mu dôveroval, nič nečítal a na titulnú stranu zadávacích podmienok načmáral súhlasné stanovisko (pod položkou SCHVALUJEM, v pravom hornom rohu titulnej strany) . Zákazník s odporným úškrnom opatrne umiestnil svoje (pod SCHVÁLENIE, v ľavom hornom rohu). Všetko, zadávacie podmienky a prispievať k tomu alebo je to možné len po dodatočnej dohode so zákazníkom. Tu prišiel na rad techpis.

Je čas otestovať systém (program, produkt) z hľadiska zhody s požiadavkami technických špecifikácií. Zákazník bude samozrejme vyžadovať, aby preukázal, že komunikačné kanály sú v súlade s požiadavkami GOST takých a takých.

Čo robiť? Polovica problémov, ak bol zapojený do komunikačných kanálov, pripravený poskytnúť Big Boss. Šéf bude otmazyatsya pred zákazníkom a techpis bude žiť (až do ďalšej punkcie). Nepríjemná pachuť v duši Veľkého šéfa však zostane navždy. Nečakajte zvýšenie.

Je to skutočný problém, ak neexistujú žiadne certifikáty. Šéf bude musieť zaplatiť (nerozpočtované) peniaze telu, aby získal vytúžený certifikát, predložil ho zákazníkovi a ukončil prácu. Takáto chyba sa asi techpisovi neodpustí.

Stručne povedané, musíte napísať niečo také, rusky v bielom:

„Ako komunikačné kanály možno použiť:

1. kanály pripojenia -;
2. kanály mobilných operátorov;
3. kanály satelitných operátorov;
4. verejné komutované telefónne linky;
5. objekt zákazníka;
6. a tak ďalej"

V žiadnom prípade neuvádzate rýchlosť výmeny dát komunikačného kanála, t.j. špecifiká. Ak bude komunikačný kanál implementovaný na báze Ethernetu a v technických špecifikáciách bude výslovne uvedený výmenný kurz aspoň 1200 bps, má zákazník plné právo prinútiť dodávateľa, aby vykonal testy v plnom rozsahu. Aj v takejto zjavne absurdnej situácii.

Záver

Poďme si teda zrekapitulovať kľúčové body:

1. príprava zadávacích podmienok importovaním elektronickej verzie požadovanej GOST;
2. detailing - rozdelenie veľkých častí technických špecifikácií do krátkych jednoduchých podčastí;
3. šablónová konštrukcia viet v oddieloch (pododdieloch atď.) zadávacích podmienok tak, aby „polovica otázky bola v odpovedi“;
4. formalizácia obsahu tých častí, kde nie je možné (alebo) uviesť konkrétne údaje;
5. používanie pečiatok;
6. používanie zoznamov (zoznamy s odrážkami alebo číslované zoznamy);
7. použitie odkazu „všeobecné informácie, účel a zloženie“;
8. minimálne používanie "tematických" GOST.

Na záver možno poskytnúť niekoľko ďalších rád:

• nájsť „rybu“ zadávacích podmienok a po jej kritickom zvážení si požičať obsah príslušných častí (nie však zo známeho zdroja obstarávania.gov.ru – je to úplný nezmysel);
• používať dokumenty;
• kľudne sa pýtajte.

Technickú dokumentáciu LLC si môžete objednať e-mailom. mail admin @ tdocs . sú (bez medzier), tel. 8-910-468-09-28 alebo vo formulári.

Copyright © LLC „Technická dokumentácia“ 2018. Požičajte si naše materiály s brilantnosťou! Pri prehrávaní portálových materiálov je povinné nainštalovať aktívny hypertextový odkaz na zdroj - stránku s touto publikáciou na webe.

Mnoho spoločností nie je pripravených zapojiť dodávateľov do fázy písania zadávacích podmienok, pretože veria, že každý dodávateľ napíše dokument zrozumiteľný len pre svojich zamestnancov, čím si v skutočnosti zaručí privilegované postavenie v súťaži/tendri.

Čiastočne je to pravda, ale v mnohých prípadoch tento jav nesúvisí ani tak s obchodnými záujmami dodávateľov, ale s rozdielmi v prístupe k implementácii tohto dokumentu.

V definícii zadávacích podmienok na Wikipédii sa najmä uvádza, že ide o „dokument obsahujúci požiadavky objednávateľa na predmet obstarávania, definujúci podmienky a postup jeho realizácie pre potreby štátu alebo obce, v súlade s ktorými sa dodanie tovaru, vykonanie diela, poskytnutie služieb a ich prevzatie.

Okrem toho existuje niekoľko GOST, napríklad 19.201-78, ktoré upresňujú, čo a v akej forme by mal takýto dokument obsahovať.

Ako však ukazuje prax, vytúžená skratka „TK“ označuje dokumenty, ktoré sú vo svojej podstate, obsahu, prevedení a detailoch úplne odlišné. Žiaľ, mnohí zákazníci si sú istí, že po napísaní niekoľkých strán požiadaviek na budúci systém od nás dostanú presný odhad (s maximálnou deltou 10-20%) s harmonogramom prác. Ešte raz, keď mi príde mailom “TK, podľa ktorej do zajtra treba vyhodnotiť a poslať CP”, vždy sa psychicky pripravím na to, že uvidím ďalší výtvor v štýle “systém si musí vymeniť všetky potrebné informácie so stránkou“.

Kedysi sa na oddelení, kde som pracoval, prijalo toto rozdelenie: Zadanie bol dokument popisujúci požiadavky na systém v jazyku zrozumiteľnom pre podnikových používateľov a Technický návrh bol dokument vypracovaný na základe zadávacích podmienok, podrobnejšie, podrobne popisujúce všetky funkcie, ale už v jazyku zrozumiteľnom hlavne pre vývojárov.

Mne sa táto charakteristika, aj keď z formálneho hľadiska nie je správna, javí ako veľmi spravodlivá pre malé firmy, ktoré nemajú extra rozpočty, ale sú tam úlohy, ktoré si vyžadujú urgentné riešenia. Hlavná vec je pre nich zostavenie technických špecifikácií ich zamestnancami a ich distribúcia napríklad niekoľkým franšízovým firmám. A je prirodzené, že nikto nenapíše obrovský list obsahujúci neskutočné množstvo technických informácií.

Ako teda urobiť technickú špecifikáciu, podľa ktorej sa nakoniec ukáže presne to, čo stanovil jej autor (autori), a nie to, čo „dokáže typická konfiguračná funkcionalita“?

Nebudem popisovať základné požiadavky na štruktúru dokumentu, ako napríklad: ciele projektu by mali byť opísané v TOR, mali by obsahovať funkčné požiadavky, mal by tam byť zoznam skratiek a obsah, všetko by malo byť byť napísané najjednoduchšími a najkratšími frázami atď. Myslím, že to pozná každý, kto si aspoň párkrát prečítal technické špecifikácie.

Dokumenty, s ktorými som sa musel zaoberať a na základe ktorých boli dosiahnuté výsledky čo najbližšie k myšlienke, mali tieto vlastnosti:

1. TK ako pokyn. Dokument svojou štruktúrou pripomína používateľskú príručku, kde je krok za krokom napísané, v takom prípade, aké činnosti musí používateľ vykonať, aby dosiahol požadovaný výsledok. Tie. išlo o dokumenty bez súvislého zoznamu požadovaných funkcií, ale s logickým členením na samostatné procesy s popisom ich špecifík

2. Viac vizualizácie. Čím viac rozložení/snímok obrazovky/makiet/vývojových diagramov dokument obsahuje, tým je menej pravdepodobné, že získate systém, ktorý sa zdá vykonávať potrebné funkcie, ale má úplne inú logiku/dizajn/rozhranie.

3. použiteľnosť. Z dvoch predchádzajúcich bodov vyplýva jednoduchý dôsledok – jasná logika práce a maximálna vizualizácia budúceho systému nakoniec pomôže dať do TOR potrebný počet poznámok / bodov ohľadom použiteľnosti systému. Pre systémy, s ktorými pracujú nízkokvalifikovaní zamestnanci, to môže byť rozhodujúci faktor úspechu projektu (tento parameter je však mimoriadne dôležitý aj pre vrcholový manažment, ktorý sa „týmito účtovnými programami“ nechce zaoberať). Napríklad TOR pre maloobchodný systém nešpecifikoval, že vyhľadávanie článku by nemalo trvať dlhšie ako tri sekundy. Ak by bol systém implementovaný prostredníctvom typického hľadania konfigurácie, potom by to mohlo viesť ku kritickým situáciám v reálnej prevádzke, pretože pri zohľadnení počtu položiek trvalo toto vyhľadávanie až 30 sekúnd, čo je neprijateľné pri práci s maloobchodnými zákazníkmi, kde sa počíta každá sekunda.

4. Odkazy na populárne riešenia. Často pre každého, napríklad pre obchodných manažérov spoločnosti, fráza „transakčná funkčnosť“ znamená približne to isté, ale pre zamestnancov dodávateľa táto fráza neznamená absolútne nič. K tejto fráze však pridajte pár slov a z možnosti „rozdať kartu podobnú tej v Bitrix24 (alebo 1C: CRM)“ je už jasné, čo zákazník od tejto karty očakáva.

5. Primárna spätná väzba. Opakujem ešte raz - pre úspešnú implementáciu TK nie je potrebné písať ju v súlade s GOST. Nie je potrebné písať dokument určený len pre technických špecialistov. Zadanie by malo byť v prvom rade jasné kolegom jeho pôvodcu a potom tým, ktorí ho budú realizovať. Pred odoslaním dokumentu potenciálnym dodávateľom alebo internému vývoju je dôležité získať pozitívnu spätnú väzbu od ostatných obchodných používateľov. Dokument, ktorý je pre jedného človeka mimoriadne jasný, no ani pre najbližšie okolie nezrozumiteľný, nemá šancu na úspešnú realizáciu.

Samozrejme, existujú rôzne pohľady na požiadavky na prípravu TOR. Avšak pri absencii primeraného množstva času, zdrojov a kompetencií budú mať maximálne šance na úspešnú implementáciu práve referenčné podmienky napísané v jazyku, ktorý je pre podnikových používateľov najzrozumiteľnejším jazykom, ktorý má vyššie uvedené vlastnosti.