Elaborarea și aprobarea specificațiilor tehnice. Termeni de referință: formare și coordonare. Etapele dezvoltării specificațiilor tehnice

Pregătirea pentru lucrările de laborator

Pentru a lua cunoștință de materialul prelegerii pe tema „Modele de software pentru ciclul de viață. Etapele ciclului de viață în conformitate cu GOST 19.102-77. Afișarea problemei "disciplinei" Dezvoltarea și standardizarea software și IT ".

1. Studiați secțiunile relevante din publicații.

Partea teoretică. Elaborarea specificațiilor tehnice

Sarcina tehnicăeste un document care formulează principalele obiective de dezvoltare, cerințe pentru un produs software, definește termenii și etapele dezvoltării și reglementează procesul de testare a acceptării. Atât reprezentanții clientului, cât și reprezentanții contractantului participă la dezvoltarea sarcinii tehnice. Acest document se bazează pe cerințele inițiale ale clientului, analiza progreselor tehnologice avansate, rezultatele lucrărilor de cercetare, cercetarea pre-proiectare, prognoza științifică etc.

Procedura de elaborare a specificațiilor tehnice

Dezvoltarea specificațiilor tehnice se realizează în secvența următoare. În primul rând, este stabilit un set de funcții îndeplinite, precum și o listă și caracteristicile datelor inițiale. Apoi se determină o listă de rezultate, caracteristicile și metodele de prezentare ale acestora.

În plus, este specificat mediul de operare. software-ul: configurație și parametri specifici mijloace tehnice, versiunea sistemului de operare utilizat și, eventual, versiunile și parametrii altor programe instalate cu care va interacționa viitorul produs software.

În cazurile în care software-ul dezvoltat colectează și stochează anumite informații sau este implicat în gestionarea oricărui proces tehnic, este necesar, de asemenea, să reglăm în mod clar acțiunile programului în caz de pană de echipament și de alimentare.

1. Dispoziții generale

1.1. Termenii de referință sunt întocmiți în conformitate cu GOST 19.106-78 pe foile A4 și A3 în conformitate cu GOST 2.301-68, de regulă, fără a completa câmpurile foii. Numerele foii (paginii) sunt plasate în partea de sus a foii de deasupra textului.

1.2. Fișa de aprobare și pagina de titlu sunt întocmite în conformitate cu GOST 19.104-78. Partea informațională (adnotare și conținut), fișa de înregistrare a modificărilor este permisă să nu fie inclusă în document.

1.3. Pentru a face modificări și adăugări la fundalul tehnic în etapele ulterioare ale dezvoltării unui program sau produs software, o versiune suplimentară este lansată. Coordonarea și aprobarea adăugării la termenii de referință se realizează în aceeași ordine stabilită pentru termenii de referință.

1.4. Termenii de referință trebuie să conțină următoarele secțiuni:

Introducere;

Numele și domeniul de aplicare;

Bazele dezvoltării;

Scopul dezvoltării;

Cerinte tehnice la articolul sau programul;

Indicatori tehnici și economici;

Etapele și etapele dezvoltării;

Procedura de control și acceptare;

Aplicații.

În funcție de caracteristicile programului sau produsului software, este permis să clarificați conținutul secțiunilor, să introduceți noi secțiuni sau să combinați unele dintre ele. Dacă este necesar, este permisă includerea aplicațiilor în termenii de referință.

2.1 Introducerea ar trebui să includă o scurtă descriere a domeniului de aplicare a programului sau produsului software, precum și obiectul (de exemplu, un sistem) în care se presupune că va fi utilizat. Scopul principal al introducerii este de a demonstra relevanța acestei dezvoltări și de a arăta ce loc ocupă această dezvoltare în rândul celor similare.

2.2 În secțiunea „Nume și domeniu” se indică numele, descrierea succintă a domeniului de aplicare al programului sau produsului software și obiectul în care este utilizat programul sau produsul software.

2.3 În secțiunea „Bazele dezvoltării”, trebuie indicate următoarele:

Document (documente) pe baza căruia se realizează dezvoltarea. Un astfel de document poate fi un plan, ordine, contract, etc .;

Organizația care a aprobat acest document și data aprobării acestuia;

Nume și (sau) simbol subiecte de dezvoltare.

2.4. Secțiunea „Scopul dezvoltării” ar trebui să indice scopul funcțional și operațional al programului sau produsului software.

2.5. Secțiunea „Cerințe tehnice pentru un program sau produs software” trebuie să conțină următoarele subsecțiuni:

Cerințe pentru caracteristicile funcționale;

Cerințe de fiabilitate;

Termeni de utilizare;

Cerințe pentru compoziția și parametrii mijloacelor tehnice;

Cerințe pentru informații și compatibilitate software;

Cerințe pentru etichetare și ambalare;

Cerințe de transport și depozitare;

Cerinte speciale.

2.5.1 Subsecțiunea „Cerințe pentru caracteristicile funcționale” ar trebui să specifice cerințele pentru compoziția funcțiilor îndeplinite, organizarea datelor de intrare și ieșire, caracteristicile timpului etc.

2.5.2 Subsecțiunea „Cerințe de fiabilitate” trebuie să specifice cerințele pentru asigurarea funcționării fiabile (asigurarea funcționării stabile, monitorizarea informațiilor de intrare și ieșire, timpul de recuperare după eșec etc.).

2.5.3 Subsecțiunea „Condiții de exploatare” trebuie să indice condițiile de funcționare (temperatura ambientală, umiditatea relativă etc. pentru tipurile de purtători de date selectate), în baza cărora trebuie asigurate caracteristicile specificate, precum și tipul serviciului, suma necesară și calificările personalului.

2.5.4 În subsecțiunea „Cerințe pentru compoziția și parametrii mijloacelor tehnice” se indică compoziția necesară a mijloacelor tehnice, cu indicarea caracteristicilor tehnice ale acestora.

2.5.5. În subsecțiunea „Cerințe pentru compatibilitatea informațiilor și software-ului”, trebuie indicate cerințele pentru structurile informaționale la intrare și ieșire și metodele soluției, codurile sursă, limbajele de programare. Protecția informațiilor și programelor ar trebui să fie asigurată acolo unde este necesar.

2.5.6 În subsecțiunea "Cerințe pentru marcare și ambalare" din caz general indicați cerințele pentru etichetarea produsului software, opțiunile și metodele de ambalare.

2.5.7 În subsecțiunea "Cerințe pentru transport și depozitare", trebuie specificate condițiile de transport, locațiile de depozitare, condițiile de depozitare, condițiile de depozitare, timpii de depozitare în diferite condiții pentru produsul software.

2.5.8. Secțiunea „Indicatori tehnici și economici” ar trebui să indice: eficiență economică aproximativă, cerere anuală estimată, avantaje economice ale dezvoltării în comparație cu cele mai bune probe sau analogi interne și străine.

2.6 În secțiunea „Etapele și etapele dezvoltării”, se stabilesc etapele necesare de dezvoltare, etapele și conținutul lucrării (o listă de documente de program care trebuie elaborate, agreate și aprobate), precum și, de regulă, momentul dezvoltării și determinarea performanților.

2.7 În secțiunea "Procedură pentru control și acceptare", tipurile de teste și cerințe generale pentru acceptarea muncii.

2.8 În anexele la termenii de referință, dacă este necesar, indicați:

Lista lucrărilor de cercetare și a altor lucrări care justifică dezvoltarea;

Diagrame, tabele, descrieri, justificări, calcule și alte documente de algoritm care pot fi utilizate în dezvoltare;

Alte surse de dezvoltare.

În cazurile în care clientul nu prezintă cerințe stipulate de termenii de referință, este necesar să se indice la locul potrivit „Cerințele nu sunt prezentate”.

Exemple de elaborare a specificațiilor tehnice sunt prezentate în apendicele B și C.

testează întrebări

1. Oferiți conceptul de model de ciclu de viață software.

2. Oferiți etapele dezvoltării de software.

3. Ce include afirmația problemei și cercetarea pre-proiect?

4. Enumerați cerințele funcționale și de performanță pentru produsul software.

5. Enumerați regulile de elaborare a specificațiilor tehnice.

6. Care sunt secțiunile principale ale termenilor de referință.

Anexa A

Opțiuni de angajare

Lucrarea de laborator nr. 1-5 este realizată pentru aceeași opțiune.

1. Dezvoltarea unui modul de program "Contabilitate pentru progresul studentului." Modulul software este conceput pentru contabilitatea operațională a progreselor studenților în sesiune de către decanul, decanii adjuncți și angajații biroului decan. Informațiile despre progresul studenților ar trebui păstrate pe întreaga perioadă a studiului și utilizate în pregătirea certificatelor cursurilor și a suplimentelor de diplomă.

2. Dezvoltarea unui modul "Fișiere personale ale studenților". Modulul software este proiectat pentru a obține informații despre studenți de către angajații decanului, comitetului sindical și departamentului de personal. Informațiile trebuie păstrate pe întreaga durată a pregătirii studentului și folosite la pregătirea certificatelor și rapoartelor.

3. Dezvoltarea unui modul software „Soluția problemelor de optimizare combinatorie”. Modulul trebuie să conțină algoritmi pentru a găsi un ciclu de lungime minimă (problema vânzătorului care călătoresc), a găsi calea cea mai scurtă și a găsi un arbore de conectare minim.

4. Dezvoltați un modul de program „Procesare matricială”. Modulul trebuie să conțină algoritmi pentru găsirea sumelor și produselor elementelor matricei pe rânduri și coloane, precum și pentru calcularea valorilor medii, minime și maxime din matrice.

5. Dezvoltați aplicația Windows "Organizator". Aplicația este proiectată pentru a înregistra, stoca și căuta adrese și numere de telefon persoane fizice și organizații, precum și programări, întâlniri, etc. Aplicația este destinată oricărui utilizator de calculator.

6. Dezvoltați o aplicație Windows „Calculator”. Aplicația este destinată oricărui utilizator și trebuie să conțină toate operațiile aritmetice (cu respectarea priorităților) și de preferință (dar nu neapărat) mai multe funcții matematice.

7. Dezvoltați un modul de program "Departamentul" care conține informații despre personalul departamentului (nume, funcție, grad academic, disciplină, volum de muncă, muncă socială, locuri de muncă cu normă parțială, etc.). Modulul este destinat utilizării angajaților departamentului de personal și biroul decanului.

8. Dezvoltați un modul de program "Laborator" care conține informații despre personalul laboratorului (nume complet, sex, vârstă, starea civilă, prezența copiilor, poziția, gradul academic). Modulul este destinat utilizării de către angajații comitetului sindical și ai departamentului de personal.

9. Dezvoltați un modul de program „Curățare la uscat”. La înregistrarea serviciului, o cerere este completată, care indică numele proprietarului, descrierea produsului, tipul serviciului, data primirii comenzii și costul serviciului. După finalizarea lucrării, se imprimă o chitanță.

10. Dezvoltarea unui modul software „Contabilitate pentru încălcarea regulilor trafic rutier“. Pentru fiecare autoturism (și proprietarul acesteia) este înregistrată o listă de încălcări în baza de date. Pentru fiecare încălcare, se înregistrează data, ora, tipul încălcării și cuantumul amenzii. Când toate amenzile sunt plătite, mașina este scoasă din baza de date.

11. Dezvoltarea unui modul software "Fișier card de autoshop" destinat utilizării angajaților agenției. Baza de date conține informații despre mașini (marca, dimensiunea motorului, data lansării etc.). Când se primește o cerere de cumpărare, se face o căutare pentru o opțiune potrivită. Dacă nu este cazul, clientul este introdus în baza de clienți și este notificat atunci când apare o opțiune.

12. Pentru a dezvolta un modul software "fișier card de abonați ATS". Fișierul conține informații despre telefoane și proprietarii acestora. Fixează restanțele de plată (abonament și bazate pe timp). Se crede că salariile în timp ale localului conversații telefonice deja introduse.

13. Dezvoltarea unui modul software "Autokassa", care conține informații despre disponibilitatea locurilor libere pe rutele de autobuz. Baza de date trebuie să conțină informații despre numărul zborului, ruta, șoferul, tipul autobuzului, data și ora de plecare, precum și prețurile biletelor. La primirea unei cereri de bilete, programul caută un zbor adecvat.

14. Dezvoltați un modul software „Bookstore” care conține informații despre cărți (autor, titlu, editor, anul publicării, preț). Cumpărătorul întocmește o cerere pentru cărțile de care are nevoie, în cazul în care nu există, el este introdus în baza de date și este notificat atunci când cărțile necesare ajung la magazin.

Sunt deseori întrebat: „Cum să dezvoltăm corect o sarcină tehnică pentru un sistem automat?” Subiectul dezvoltării unei misiuni tehnice este discutat constant în diverse forumuri. Această întrebare este atât de largă încât este imposibil să răspundem pe scurt. Așa că am decis să scriu articol mare pe această temă. În procesul de lucru la articol, mi-am dat seama că nu va funcționa să pun totul într-un singur articol, deoarece va apărea sub 50 de pagini și a decis să o împartă în 2 părți:

În prima parte " Elaborarea specificațiilor tehnice. Ce este, de ce este nevoie, de unde să înceapă și cum ar trebui să arate? " Voi încerca să răspund în detaliu la întrebările subiectului, să iau în considerare structura și scopul Termenilor de referință și să dau câteva recomandări privind formularea cerințelor.
A doua parte " Elaborarea specificațiilor tehnice. Cum să formulezi cerințele? " va fi dedicat integral identificării și formulării cerințelor pentru sistemul informațional.

În primul rând, trebuie să vă dați seama ce întrebare îi interesează cu adevărat pe cei care întreabă „Cum să dezvolte o specificație tehnică?” Cert este că abordarea dezvoltării specificațiilor tehnice va depinde, de asemenea, foarte mult de scopul pentru care se realizează acest lucru, precum și de cine va fi folosit. Despre ce opțiuni vorbesc:

O organizație comercială a decis să implementeze un sistem automatizat. Nu are propriul său serviciu IT și a decis să facă următoarele: Persoana în cauză ar trebui să elaboreze Termenii de referință și să o prezinte unei organizații terțe pentru dezvoltare;
O organizație comercială a decis să implementeze un sistem automatizat. Are un serviciu IT propriu. Am decis să facem acest lucru: să dezvoltăm Termenii de referință, apoi să-l punem de acord între serviciul IT și părțile interesate și să îl implementăm pe cont propriu;
Agenția guvernamentală a decis să înceapă un proiect IT. Totul este atât de noroios aici, o mulțime de formalități, recuperări, reduceri etc. Nu voi lua în considerare această opțiune în acest articol.
O companie IT este angajată în servicii pentru dezvoltarea și / sau implementarea sistemelor automatizate. Acesta este cel mai dificil caz, deoarece trebuie să lucrați într-o varietate de condiții:
Clientul are specialiștii săi cu vederi proprii și își cer cerințe specifice pentru Termenii de referință;
- Termenii de referință sunt dezvoltați pentru proprii dezvoltatori (clientului nu îi pasă);
- Termenii de referință sunt dezvoltați pentru transferul către un contractant (adică un grup de programatori aflați în afara personalului companiei sau un specialist individual);
- Întreprinderea și clientul apar o neînțelegere cu privire la rezultatul obținut, iar compania pune din nou și din nou întrebarea: „Cum ar trebui să se dezvolte Termenii de referință?” Poate că ultimul caz pare un paradox, dar este adevărat.
- Sunt posibile și alte opțiuni mai puțin obișnuite;

Cred că acum cititorul ar trebui să aibă câteva întrebări:

De ce este imposibil să se dezvolte Termenii de Referință este întotdeauna același ?;
Există standarde, metode, recomandări? Unde le pot primi?
Cine ar trebui să dezvolte Termenii de referință? Această persoană ar trebui să aibă cunoștințe speciale?
Cum să înțelegeți dacă Termenii de referință sunt bine redactate sau nu?
În detrimentul căreia ar trebui dezvoltat și este deloc necesar?

Lista poate fi interminabilă. Vorbesc atât de încrezător pentru că sunt în dezvoltare profesională de software de 15 ani, iar întrebarea Termenilor de referință apare în orice echipă de dezvoltare cu care trebuie să lucrez. Motivele acestui lucru sunt diferite. Ridicând subiectul dezvoltării Termenilor de referință, sunt perfect conștient de faptul că nu îl voi putea prezenta 100% pentru toți cei interesați de acest subiect. Dar, voi încerca, așa cum spun ei, „să pun totul pe rafturi”. Cei care sunt deja familiarizați cu articolele mele știu că nu folosesc „copierea-lipirii” lucrărilor altor persoane, nu retipăr cărțile altor persoane, nu citez standarde cu mai multe pagini și alte documente pe care tu însuți le poți găsi pe internet, trecându-le ca strălucitoare gânduri. Este suficient să introduceți motorul de căutare „Cum să dezvoltați o misiune tehnică” și puteți citi o mulțime de lucruri interesante, dar, din păcate, de multe ori repetitive. De regulă, cei cărora le place să fie deștepți pe forumuri (încercați să le căutați la fel!) Nu au făcut niciodată ei înșiși un Termeni de referință sensibili și cită continuu recomandările GOST-urilor pe această problemă... Iar cei care sunt cu adevărat serioși în problemă, de obicei, nu au timp să stea pe forumuri. Apropo, vom vorbi și despre GOST. De-a lungul anilor activității mele, am văzut multe opțiuni de documentare tehnică, compilate atât de specialiști individuali, cât și de echipe eminente și companii de consultanță. Uneori, de asemenea, fac acest tip de activitate: îmi alocă timp pentru mine și caut informații despre un subiect de interes din surse neobișnuite (o astfel de inteligență mică). Drept urmare, a trebuit să văd documentația pentru monștri precum GazProm, Căile Ferate Ruse și multe alte companii interesante. Desigur, respect politica de confidențialitate, în ciuda faptului că aceste documente îmi vin din surse disponibile public sau din iresponsabilitatea consultanților (împrăștiere de informații pe Internet). Prin urmare, spun imediat: informații confidențialecare aparține altor companii nu este împărtășit, indiferent de sursa de apariție (etica profesională).

Care sunt termenii de referință?

Primul lucru pe care îl vom face acum este să ne dăm seama ce fel de fiară este aceasta, „Termenii de referință”.

Da, există cu adevărat GOST-uri și standarde în care se încearcă reglementarea acestei părți a activității (dezvoltarea de software). A fost odată, toate aceste GOST-uri au fost relevante și utilizate în mod activ. Acum există opinii diferite despre relevanța acestor documente. Unii susțin că GOST-urile au fost dezvoltate de oameni foarte vizionați și sunt încă relevante. Alții spun că sunt depășiți fără speranță. Poate că cineva a crezut acum că adevărul este undeva la mijloc. Aș răspunde cu cuvintele lui Goethe: „Ei spun că între două opinii opuse există adevăr. În niciun caz! Există o problemă între ei. " Deci, nu există adevăr între aceste opinii. Deoarece GOST-urile nu dezvăluie problemele practice ale dezvoltării moderne, iar cei care le critică nu oferă alternative (specifice și sistemice).

Rețineți că GOST nici măcar nu dă o definiție, ci spune doar: „Specificația tehnică pentru NPP este principalul document care definește cerințele și procedura pentru crearea (dezvoltarea sau modernizarea - crearea ulterioară) a unui sistem automat, în conformitate cu care dezvoltarea UA și acceptarea acestuia se realizează la punerea în funcțiune în acțiune ”.

Dacă cineva este interesat de GOST-uri despre care vorbesc, atunci iată:

GOST 2.114-95 Sistem unificat pentru documentația de proiectare. Condiții tehnice;
GOST 19.201-78 Sistem unificat de documentare a programului. Sarcina tehnică. Cerințe pentru conținut și design;
GOST 34.602-89 Tehnologia informației. Un set de standarde pentru sisteme automatizate... Termeni de referință pentru crearea unui sistem automat.

O definiție mult mai potrivită este prezentată în Wikipedia (adevărat despre TK în general, și nu doar pentru software): Sarcina tehnică - acesta este documentul de proiectare inițial tehnic obiect. Sarcina tehnică stabilește scopul principal al obiectului dezvoltat, tehnic și tactic specificații, indicatori de calitate și cerințe tehnice și economice, prescripții pentru implementarea etapelor necesare creării documentației (proiectare, tehnologie, software etc.) și compoziția acesteia, precum și cerințe speciale. O sarcină ca document sursă pentru crearea a ceva nou există în toate domeniile de activitate, diferind în nume, conținut, ordine de înregistrare etc. (de exemplu, o sarcină de proiectare în construcție, o misiune de luptă, teme pentru acasă, contract pentru o lucrare literară etc.) "

Și astfel, așa cum rezultă din definiție, scopul principal al Termenilor de referință este formularea cerințelor pentru obiectul dezvoltat, în cazul nostru pentru un sistem automat.

Precis de bază, dar unic. A sosit momentul să abordăm principalul lucru: să punem totul „pe rafturi”, așa cum a promis.

Ce trebuie să știți despre cerințe? Este necesar să înțelegeți clar că toate cerințele trebuie împărțite în funcție de tip și de proprietăți. Acum vom învăța cum să facem asta. GOST ne va ajuta să separăm cerințele după tip. Lista tipurilor de cerințe prezentate există un bun exemplu despre ce tipuri de cerințe trebuie luate în considerare. De exemplu:

Cerințe de funcționalitate;
Cerințe privind securitatea și drepturile de acces;
Cerințe de calificare a personalului;
.... Etc. Puteți citi despre ele în GOST-ul menționat (și mai jos le voi lua în considerare mai detaliat).

Cred că este evident pentru dvs. că factorul cheie pentru un termen de referință de succes este exact cerințele bine formulate pentru funcționalitate. Majoritatea lucrărilor și tehnicilor despre care am vorbit sunt dedicate acestor cerințe. Cerințele pentru funcționalitate reprezintă 90% din complexitatea lucrărilor la elaborarea Termenilor de referință. Restul este adesea „camuflajul” care este pus pe aceste cerințe. Dacă cerințele sunt slab formulate, atunci ce fel de camuflaj frumos nu ar trebui să fie pus, un proiect de succes nu va funcționa. Da, formal toate cerințele vor fi îndeplinite (conform GOST J), TK a fost dezvoltat, aprobat și semnat, banii au fost primiți pentru aceasta. Și ce dacă? Și atunci va începe cel mai interesant lucru: ce să faci? Dacă acesta este un proiect din ordinul de stat, atunci nu există probleme - acolo bugetul este astfel încât să nu încapă în niciun buzunar, în procesul de implementare (dacă există), totul va fi clarificat. Acesta este exact modul în care majoritatea bugetelor de proiect pentru ordinele de stat sunt tăiate (au tras "TZ", au turnat zece milioane, dar proiectul nu a fost făcut. Toate formalitățile au fost urmate, nu au existat părți vinovate, o mașină nouă în apropierea casei. Frumusețe!). Vorbim însă de organizații comerciale în care se numără bani, iar rezultatul este diferit. Prin urmare, să ne ocupăm de principalul lucru, cum să ne dezvoltăm termeni de referință utili și funcționali.

Am spus despre tipurile de cerințe, dar despre proprietăți? Dacă tipurile de cerințe pot fi diferite (în funcție de obiectivele proiectului), atunci cu proprietățile totul este mai simplu, există 3 dintre ele:

Cerința trebuie să fie de inteles;
Cerința trebuie să fie specific;
Cerința trebuie să fie testat;

Mai mult, ultima proprietate este imposibilă fără cele două anterioare, adică. este un fel de „test litmus”. Dacă rezultatul îndeplinirii cerinței nu poate fi testat, atunci acesta nu este clar sau nu este specific. Gandeste-te la asta. În posesia acestor trei proprietăți ale cerințelor se află abilitatea și profesionalismul. De fapt, totul este foarte simplu. Când îți dai seama.

În acest sens, povestea despre termenii de referință ar putea fi completată și trece la principalul lucru: modul de formulare a cerințelor. Dar nu totul este atât de rapid. Există un punct extrem de important:

În ce limbă (din punct de vedere al complexității înțelegerii) termenii de referință ar trebui să fie scrise?
Trebuie specificate în ea specificațiile pentru diverse funcții, algoritmi, tipuri de date și alte lucruri tehnice?
Și ce este designul tehnic, care, apropo, este menționat și în GOST-uri și cum este legat de Termenii de referință?

Există un lucru foarte insidios în răspunsurile la aceste întrebări. Acesta este motivul pentru care apar deseori dispute privind suficiența sau lipsa detalierii necesare a cerințelor, despre claritatea documentului de către Client și Contractori, despre redundanță, format de prezentare etc. Și unde este granița dintre Termenii de Referință și Proiectarea Tehnică?

Sarcina tehnică este un document bazat pe cerințe formulate într-un limbaj inteligibil (obișnuit, familiar) pentru Client. În același timp, poate fi și trebuie utilizată terminologia industriei care este inteligibilă pentru Client. Nu trebuie să existe legături la specificul implementării tehnice. Acestea. în stadiul TK, în principiu, nu contează pe ce platformă vor fi implementate aceste cerințe. Există însă și excepții. Dacă vorbim despre implementarea unui sistem bazat pe un produs software existent, atunci o astfel de legătură poate avea loc, dar numai la nivelul formularelor de ecran, a formularelor de raport etc. analist de afaceri.Și, cu siguranță, nu un programator (decât dacă combină aceste roluri în sine, acest lucru se întâmplă). Acestea. această persoană trebuie să vorbească cu Clientul în limba afacerii sale.

Proiect tehnic este un document care este destinat implementării tehnice a cerințelor formulate în Termenii de referință. Acest document descrie structuri de date, declanșatoare și proceduri stocate, algoritmi și alte lucruri care sunt necesare. tehnicieni ... Nu este deloc necesar ca clientul să apeleze la acest lucru (este posibil să nu înțeleagă astfel de termeni). Proiectarea tehnică face Arhitect de sistem(Aici este destul de normal să combini acest rol cu \u200b\u200bun programator). Pentru a fi mai precis, un grup de specialiști AO este condus de un arhitect. Cu cât este mai mare proiectul, cu atât mai mulți oameni lucrează la Termenii de referință.

Ce avem în practică? Este amuzant să urmărești când directorul este adus spre aprobare de Termenii de referință, care este completat cu terminologie tehnică, descrieri ale tipurilor de date și valorile acestora, structura bazei de date, etc. El, desigur, încearcă să se afle, întrucât este necesar să se afirme, încercând să găsească cuvinte familiare între linii și să nu piardă lanțul cerințe de afaceri. Este o situație familiară? Și cum se termină? De regulă, un astfel de TK este aprobat, apoi pus în aplicare și, în 80% din cazuri, atunci nu corespunde deloc cu lucrarea efectuată, deoarece au decis să se schimbe, să reîncadreze o mulțime de lucruri, au înțeles greșit, au gândit greșit etc. etc. Și apoi începe seria despre livrarea lucrărilor. „Dar nu este așa cum avem nevoie de noi”, ci „nu va funcționa pentru noi”, „este prea dificil”, „este incomod” etc. Suna familiar? !! Acest lucru este familiar pentru mine, a trebuit să umplu conurile la timp.

Deci, ce avem în practică? În practică, avem o graniță neclară între Termenii de Referință și Proiectarea Tehnică. Plutește între TK și TP sub diferite forme. Și acest lucru este rău. Și se pare că cultura de dezvoltare a devenit slabă. Acest lucru se datorează parțial competențelor specialiștilor, parțial din dorința de a reduce bugetele și termenele (până la urmă, documentația durează mult timp - acesta este un fapt). Mai există unul factor importantcare afectează utilizarea Proiectării tehnice ca document separat: dezvoltarea rapidă a instrumentelor de dezvoltare rapidă, precum și metodologii de dezvoltare. Dar aceasta este o poveste separată, voi spune câteva cuvinte despre acest lucru mai jos.

Un alt punct mic, dar important. Uneori, Termenii de referință reprezintă o bucată mică de cerințe, simplă și de înțeles. De exemplu, pentru a rafina căutarea unui obiect în funcție de anumite condiții, adăugați o coloană în raport etc. Această abordare este destul de justificată, de ce să complice viața. Dar este folosit nu pe proiecte mari, ci pe îmbunătățiri minore. Aș spune că aceasta este mai aproape de întreținerea unui produs software. În acest caz, un specific soluție tehnică implementarea cerinței. De exemplu, „Efectuați o astfel de modificare a algoritmului așa și așa”, indicând o procedură specifică și o modificare specifică pentru programator. Acesta este cazul când granița dintre Termenii de referință și proiectele tehnice este șters complet, deoarece nu este fezabilitate economica umflați hârtia acolo unde nu este nevoie și este creat un document util. Și este drept.

Ai nevoie de o sarcină tehnică? Dar proiectarea tehnică?

Sunt supraîncălzit? Este posibil, fără Termeni de referinta? Imaginează-ți că este posibil (mai exact, apare), iar această abordare are mulți adepți, iar numărul lor este în creștere. De regulă, după ce tinerii specialiști au citit cărți despre Scrum, Agile și alte tehnologii de dezvoltare rapidă. De fapt, acestea sunt tehnologii minunate și funcționează, numai că nu spun literalmente „nu este nevoie să faceți specificații tehnice”. Ei spun „un minim de documente”, în special inutile, mai aproape de Client, mai specifice și mai rapide de rezultat. Dar nimeni nu a anulat fixarea cerințelor și este menționat clar acolo. Acolo cerințele sunt fixate pe baza celor trei proprietăți remarcabile despre care am vorbit mai sus. Doar că unii oameni au o conștiință atât de structurată încât, dacă poți simplifica ceva, hai să o simplificăm absență completă... După cum spunea Einstein „ Faceți-l cât mai simplu, dar nu mai simplu. " ... Cuvintele de aur sunt potrivite pentru orice. Astfel încât Sarcina tehnică este necesar, altfel nu veți vedea un proiect de succes. O altă întrebare este cum să compunem și ce să includem acolo. Având în vedere metodologiile de dezvoltare rapidă, trebuie doar să vă concentrați asupra cerințelor și tot „camuflarea” poate fi abandonată. În principiu, sunt de acord cu acest lucru.

Dar proiectul tehnic? Acest document este foarte util și nu și-a pierdut relevanța. Mai mult decât atât, este adesea imposibil să faci fără ea. Mai ales când vine vorba de externalizarea lucrărilor de dezvoltare, adică. pe baza externalizării. Dacă nu se face acest lucru, există riscul de a învăța o mulțime de lucruri noi despre cum ar trebui să arate sistemul pe care l-ați conceput. Clientul trebuie să-l cunoască? Dacă vrea, de ce nu, dar insistă și afirmă acest document nu este nevoie, ci doar va limita și va interfera cu munca. Este aproape imposibil să proiectăm un sistem până la cele mai mici detalii. În acest caz, va trebui să efectuați continuu modificări ale Proiectării tehnice, care necesită mult timp. Și dacă organizația este puternic birocratizată, atunci, în general, lăsați toți nervii acolo. Tocmai despre reducerea acestui tip de design vorbim în metodologiile moderne de dezvoltare rapidă, despre care am menționat mai sus. Apropo, toate se bazează pe clasic XP (programare extremă) - o abordare care are deja aproximativ 20 de ani. Așa că faceți un Termeni de referință de înaltă calitate, înțelegători pentru Client și folosiți Designul Tehnic ca document intern pentru relația dintre arhitectul de sistem și programatori.

Un detaliu interesant despre proiectarea tehnică: unele instrumente de dezvoltare bazate pe principiul orientării pe teme (cum ar fi 1C și altele similare) presupun că proiectarea (însemnând procesul de documentare) este necesară doar în domenii cu adevărat complexe, unde este necesară interacțiunea între subsisteme întregi. În cel mai simplu caz, de exemplu, pentru a crea o carte de referință, un document, doar cerințele de afaceri corect formulate sunt suficiente. Acest lucru este demonstrat de strategia de afaceri a acestei platforme în ceea ce privește formarea specialiștilor. Dacă te uiți la biletul de examen al unui specialist (așa se numește și nu „programator”), atunci vei vedea că există doar cerințe de afaceri, iar modul de implementare a acestora într-un limbaj de programare este sarcina specialistului. Acestea. acea parte a sarcinii pe care Proiectul Tehnic este proiectat să o rezolve, specialistul trebuie să rezolve „în cap” (vorbim despre sarcini de complexitate medie), iar aici și acum, urmând anumite standarde de dezvoltare și proiectare, care sunt din nou formate de 1C pentru platforma sa. Astfel, din doi specialiști, al căror rezultat al lucrării arată același, unul poate trece examenul, iar celălalt nu poate, deoarece au încălcat grav standardele de dezvoltare. Adică, se presupune că specialiștii trebuie să aibă astfel de calificări încât să poată proiecta singuri sarcini tipice, fără a implica arhitecții de sistem. Și această abordare funcționează.

Să continuăm cercetarea întrebării: „Ce cerințe ar trebui incluse în Termenii de referință?”

Formularea cerințelor pentru sistemul informațional. Structura Termenilor de Referință

Să decidem imediat: vom vorbi în mod special despre formularea cerințelor pentru sistemul informațional, adică. presupunând că activitatea de dezvoltare a cerințelor de afaceri, formalizarea proceselor de afaceri și toate lucrările de consultanță anterioară au fost deja finalizate. Desigur, unele rafinări pot fi efectuate în acest stadiu, dar mai precis rafinări. Proiectul automatizării în sine nu rezolvă problemele de afaceri - amintiți-vă acest lucru. Acesta este un axiom. Din anumite motive, unii manageri încearcă să-l respingă, crezând că, dacă cumpără programul, atunci comanda va veni într-o afacere haotică. Dar axioma este, de asemenea, o axiomă care nu necesită dovezi.

Ca în orice activitate, formularea de cerințe poate (și ar trebui) să fie împărțită în etape. Toate la timpul lor. Aceasta este o muncă intelectuală grea. Și, dacă îl tratează cu atenție insuficientă, atunci rezultatul va fi adecvat. Conform estimărilor experților, costul dezvoltării Termenilor de referință poate fi de 30-50%. Sunt de aceeași părere. Cu toate că 50 este probabil prea mult. La urma urmei, Termenii de referință nu sunt ultimul document elaborat. La urma urmei, trebuie să existe și proiectare tehnică. Această răspândire se datorează diferitelor platforme de automatizare, abordări și tehnologii utilizate de echipele de proiect în timpul dezvoltării. De exemplu, dacă vorbim despre dezvoltare într-un limbaj clasic cum ar fi C ++, atunci nu se poate face fără un proiect tehnic detaliat. Dacă vorbim despre implementarea sistemului pe platforma 1C, atunci situația cu designul este oarecum diferită, așa cum am văzut mai sus (deși, atunci când dezvoltăm sistemul de la zero, este proiectat conform schemei clasice).

În ciuda faptului că declarația de cerințe este partea principală Termeni de referintași, în unele cazuri, devine singura secțiune a TK, ar trebui să acordați atenție faptului că acesta este un document important și ar trebui să fie întocmit în consecință. Unde sa încep? În primul rând, trebuie să începeți cu conținutul. Compuneți-vă conținutul, apoi începeți să-l extindeți. Personal, fac acest lucru: mai întâi schițez conținutul, descriu obiectivele, toate informațiile de fundal și apoi ajung la partea principală - formularea cerințelor. De ce nu invers? Nu știu, este mai convenabil pentru mine. În primul rând, aceasta este o parte mult mai mică a timpului (în comparație cu cerințele), iar în al doilea rând, în timp ce descrie toate informațiile introductive, sunteți în acord cu principalul lucru. Ei bine, acesta este așa cum îți place. În timp, vă veți dezvolta propriul șablon al Termenilor de referință. Pentru început, recomand să-l iei exact pe cel descris în GOST drept conținut. Se potrivește perfect pentru conținut! Apoi luăm și începem să descriem fiecare secțiune, fără să uităm de recomandările pentru următoarele trei proprietăți: claritate, concretitate și testabilitate. De ce sunt atât de insistent în acest sens? Mai multe detalii în secțiunea următoare. Și acum îmi propun să parcurgi până la capăt punctele TK care sunt recomandate în GOST.

informatii generale;
scopul și obiectivele creării (dezvoltării) sistemului;
caracteristicile obiectelor de automatizare;
cerințe de sistem;
compoziția și conținutul lucrărilor pentru crearea sistemului;
procedura de control și acceptare a sistemului;
cerințe pentru compoziția și conținutul lucrărilor la pregătirea obiectului de automatizare pentru punerea în funcțiune a sistemului;
cerințe de documentare;
surse de dezvoltare.

În total, există 9 secțiuni, fiecare fiind divizată și în subsecțiuni. Să le analizăm în ordine. Pentru comoditate, voi prezenta totul sub forma unui tabel pentru fiecare articol.

Secțiunea 1. informații generale.

Recomandări GOST
numele complet al sistemului și simbolul acestuia;	Totul este clar aici: scriem cum se va numi sistemul, numele său scurt
codul subiectului sau codul contractului (număr);	Acest lucru nu este relevant, dar puteți specifica dacă este necesar
numele întreprinderilor (asociațiilor) dezvoltatorului și clientului (utilizatorului) sistemului și detaliile acestora;	indicați cine (ce organizații) vor lucra la proiect. Puteți specifica și rolurile lor. Puteți șterge această secțiune cu totul (mai degrabă formală).
o listă de documente pe baza cărora este creat sistemul, de către cine și când au fost aprobate aceste documente;	Informatii utile. Aici merită să indicați documentația normativă și de referință care v-a fost furnizată pentru a vă familiariza cu o anumită parte a cerințelor
datele planificate de început și de încheiere pentru crearea sistemului;	Cereri la termen. Uneori scriu despre asta în TK, dar mai des astfel de lucruri sunt descrise în contractele de muncă
informații despre sursele și procedura de finanțare a lucrării;	La fel, ca și în paragraful precedent despre calendarul. Mai relevant pentru ordinele guvernamentale (pentru angajații statului)
procedura de înregistrare și prezentare către client a rezultatelor lucrărilor la crearea sistemului (părțile sale), la fabricarea și reglarea mijloacelor individuale (hardware, software, informații) și complexe software și hardware (software și metodologice) ale sistemului.	Nu văd nevoia acestui punct, pentru că cerințele pentru documentare sunt făcute separat și, în plus, există o secțiune completă separată "Procedura de control și acceptare" a sistemului.

Secțiunea 2. scopul și obiectivele creării (dezvoltării) sistemului.

Recomandări GOST	Ce să faci despre asta în practică
Scopul sistemului	Pe de o parte, totul este simplu cu programarea. Dar este de dorit să fie specific. Dacă scrieți ceva de genul „automatizați calitativ controlul inventarului în compania X”, atunci puteți discuta rezultatul pentru o lungă perioadă de timp la finalizarea acestuia, chiar și indiferent de formularea bună a cerințelor. pentru că Clientul poate spune întotdeauna că a însemnat ceva diferit prin calitate. În general, vă puteți strica reciproc o mulțime de nervi, dar de ce? Este mai bine să scrieți imediat așa ceva: „Sistemul este menit să mențină contabilitate depozit în compania X în conformitate cu cerințele prevăzute în prezentele Termeni de referință. "
Obiectivele sistemului	Obiectivele sunt cu siguranță o secțiune importantă. Dacă îl includeți cu adevărat, atunci trebuie să puteți formula aceste obiective. Dacă aveți dificultăți în formularea obiectivelor, atunci este mai bine să excludeți această secțiune cu totul. Un exemplu de obiectiv nereușit: „Furnizați documente rapide pentru manager”. Ce repede? Acest lucru poate fi apoi dovedit la nesfârșit. Dacă acest lucru este important, atunci este mai bine să reformulați acest obiectiv după cum urmează: "Directorul de vânzări ar trebui să poată întocmi un document„ Vânzări de mărfuri "de 100 de linii în 10 minute". Un obiectiv similar poate să apară dacă, de exemplu, managerul cheltuie în prezent aproximativ o oră, ceea ce este prea mult pentru această companie și este important pentru ei. Într-o astfel de formulare, obiectivul deja intersectează cu cerințele, care este destul de natural, deoarece atunci când extindem arborele obiectivelor (adică împărțirea lor în obiective mai mici legate), vom aborda oricum cerințele. Prin urmare, nu ar trebui să fii dus.

În general, capacitatea de a identifica obiectivele, de a le formula, de a construi un arbore de obiective este un subiect complet separat. Amintiți-vă principalul lucru: dacă știți cum - scrieți, nu sunteți sigur - nu scrieți deloc. Ce se va întâmpla dacă nu vă formulați obiective? Vei lucra în conformitate cu cerințele, acest lucru este practicat adesea.

Secțiunea 3. Descrierea obiectelor de automatizare.

Secțiunea 4. Cerințe de sistem

GOST descifrează lista de astfel de cerințe:

cerințe pentru structura și funcționarea sistemului;
cerințe pentru numărul și calificările personalului sistemului și modul lor de lucru;
indicatori de destinație;
cerințe de fiabilitate;
cerințe de siguranță;
cerințe pentru ergonomie și estetică tehnică;
cerințe de transport pentru boxele mobile;
cerințe de operare, întreținere, repararea și depozitarea componentelor sistemului;
cerințe pentru protecția informațiilor împotriva accesului neautorizat;
cerințe privind siguranța informațiilor în caz de accidente;
cerințe pentru protecția împotriva influenței influențelor externe;
cerințe pentru puritatea brevetului;
cerințe pentru standardizare și unificare;

În ciuda faptului că secțiunea principală va fi cu siguranță cu cerințe specifice (funcționale), această secțiune poate avea o importanță deosebită (și în majoritatea cazurilor o face). Ce poate fi important și util:

Cerințe de calificare... Poate că sistemul dezvoltat va necesita recalificarea specialiștilor. Aceștia pot fi atât utilizatori ai viitorului sistem, cât și specialiști IT care vor fi necesari pentru a-l susține. O atenție insuficientă asupra acestei probleme se dezvoltă adesea în probleme. Dacă calificările personalului existent sunt în mod clar insuficiente, este mai bine să se prescrie cerințele pentru organizarea pregătirii, programului de pregătire, calendarul etc.
Cerințe pentru protejarea informațiilor împotriva accesului neautorizat.Comentariile nu sunt necesare aici. Acestea sunt exact cerințele pentru diferențierea accesului la date. Dacă sunt planificate astfel de cerințe, atunci trebuie descrise separat, în detalii cât mai mari, în conformitate cu aceleași reguli ca cerințele funcționale (claritate, specificitate, testabilitate). Prin urmare, aceste cerințe pot fi incluse în secțiunea cu cerințe funcționale.
Cerințe pentru standardizare. Dacă există standarde de proiectare care sunt aplicabile proiectului, acestea pot fi incluse în cerințe. De regulă, astfel de cerințe sunt inițiate de serviciul IT al Clientului. De exemplu, compania 1C are cerințe pentru proiectarea codului programului, proiectarea interfeței etc .;
Cerințe pentru structura și funcționarea sistemului. Cerințele pentru integrarea sistemelor între ele pot fi descrise aici, este prezentată o descriere a arhitecturii generale. Mai des, cerințele pentru integrare sunt, în general, alocate într-o secțiune separată sau chiar într-un termen de referință separat. aceste cerințe pot fi destul de complexe.

Toate celelalte cerințe sunt mai puțin importante și nu trebuie descrise. În opinia mea, acestea fac doar documentația mai grea și sunt de folos practic. Și este foarte dificil să descrieți cerințele pentru ergonomie sub formă de cerințe generale, este mai bine să le transferați pe cele funcționale. De exemplu, cerința „Obțineți informații despre prețul unui articol făcând clic pe un singur buton” poate fi formulată. În opinia mea, acesta este totuși mai aproape de cerințele funcționale specifice, deși se referă la ergonomie. Cerințe pentru funcțiile (sarcinile) îndeplinite de sistem Acesta este foarte principal și punct-cheieasta va determina succesul. Chiar dacă toate celelalte sunt făcute perfect, iar această secțiune este „3”, rezultatul proiectului va fi „3” în cel mai bun caz, sau chiar proiectul va eșua cu totul. Vom trata acestea mai detaliat în cel de-al doilea articol, care va fi inclus în numărul 5 al listei de e-mailuri. În acest punct, „regula celor trei proprietăți ale creanțelor”, despre care am vorbit, cerințe pentru tipurile de garanții

GOST distinge următoarele tipuri:

Matematic
informație
Lingvistic
Software-ul
Tehnic
metrologică
organizatoric
Metodic
alte…

La prima vedere, s-ar putea părea că aceste cerințe nu sunt importante. În majoritatea proiectelor, acest lucru este adevărat. Dar nu in totdeauna. Când să descrieți aceste cerințe:

Nu se iau decizii despre ce limbă (sau ce platformă) va fi utilizată pentru dezvoltare;
Sistemul are cerințe pentru o interfață multilingvă (de exemplu, rusă / engleză)
Pentru ca sistemul să funcționeze, trebuie creată o divizie separată sau angajați noi angajați;
Pentru ca sistemul să funcționeze, Clientul trebuie să sufere modificări în metodele de lucru, iar aceste modificări trebuie specificate și planificate;
Se presupune integrarea cu orice echipament și i se impun cerințe (de exemplu, certificare, compatibilitate etc.)
Alte situații sunt posibile, totul depinde de obiectivele specifice ale proiectului.

Secțiunea 5. Compoziția și conținutul lucrărilor la crearea sistemului

Secțiunea 6. Procedura de control și acceptare a sistemului

Cerințe generale pentru acceptarea lucrărilor pe etape (lista întreprinderilor și organizațiilor participante, locul și calendarul), procedura de acordare și aprobare a documentației de acceptare; recomand cu tărie să vă asumați responsabilitatea procedurii de livrare a muncii și verificării sistemului. Pentru aceasta sunt cerințele testabile, dar chiar și prezența cerințelor testabile poate să nu fie suficientă atunci când sistemul este predat, dacă ordinea de acceptare și transfer a lucrărilor nu este clar definită. De exemplu, o capcană comună: sistemul este făcut, este complet operațional, dar Clientul din anumite motive nu este pregătit să lucreze în el. Aceste motive pot fi oricare: odată, obiectivele s-au schimbat, cineva a renunțat etc. Și el spune: „De vreme ce încă nu lucrăm sistem noudeci nu putem fi siguri că funcționează. " Așadar, învățați să identificați corect etapele de lucru, modalități de a verifica rezultatele pentru aceste etape. Mai mult, inițial aceste metode ar trebui să fie clare pentru client. Dacă sunt fixate la nivelul Termenilor de referință, puteți să le contactați întotdeauna dacă este necesar și să aduceți lucrările cu transferul.

Secțiunea 7. Cerințe privind compoziția și conținutul lucrărilor la pregătirea obiectului de automatizare pentru punerea în funcțiune a sistemului

Pot exista alte reguli pentru introducerea informațiilor adoptate de companie (sau planificate). De exemplu, informațiile despre contract au fost introduse anterior într-o linie de text într-o formă arbitrară, dar acum numărul este necesar separat, data separat etc. Pot exista multe astfel de condiții. Unele dintre ele pot fi percepute cu rezistență din partea personalului, deci este mai bine să înregistrați toate aceste cazuri la nivelul cerințelor procedurii de introducere a datelor Modificări care trebuie făcute în obiectul automatizării

Crearea condițiilor pentru funcționarea obiectului de automatizare, în baza căreia este garantată conformitatea sistemului creat cu cerințele cuprinse în TZ. Orice modificări care pot fi necesare. De exemplu, compania nu are rețeaua locală, o flotă învechită de computere pe care sistemul nu va funcționa.

Poate că unele informații necesare au fost procesate pe hârtie, iar acum trebuie introduse în sistem. Dacă acest lucru nu este realizat, atunci orice modul nu va funcționa etc.

Poate că ceva a fost simplificat, dar acum este necesar să se țină cont mai detaliat, respectiv, cineva trebuie să colecteze informații conform anumitor reguli.

Această listă poate fi lungă, priviți cazul specific al proiectului dvs. Crearea de unități și servicii necesare funcționării sistemului;

Momentul și procedura pentru formarea personalului și pregătirea personalului Am vorbit deja despre acest lucru mai devreme. Poate că sistemul este dezvoltat pentru o nouă structură sau un tip de activitate care nu exista înainte. Dacă nu există personal adecvat și chiar instruit, atunci sistemul nu va funcționa, indiferent cât de competent nu este construit.

Secțiunea 8. Cerințe de documentare

Luați în considerare modul în care vor fi prezentate manualele de utilizare.

Poate că Clientul a acceptat standardele corporative, de aceea este necesar să vă referiți la acestea.

Ignorarea cerințelor de documentare duce adesea la cele mai neașteptate consecințe asupra proiectelor. De exemplu, totul este făcut și totul funcționează. Utilizatorii știu, de asemenea, să funcționeze. Nu au fost deloc de acord și nu au vorbit despre documentație. Și deodată, la trimiterea lucrării, unul dintre cei mai buni manageri ai Clientului, care nici nu a participat la proiect, ci participă la acceptarea lucrării, vă întreabă: „Unde sunt manualele de utilizare?” Și el începe să vă convingă că nu a fost necesar să negociați disponibilitatea manualelor de utilizare, acest lucru este presupus implicit. Și asta este tot, nu vrea să-ți ia treaba. La cheltuiala căreia veți dezvolta linii directoare? Multe echipe au căzut deja pe acest cârlig.

Secțiunea 9. Surse de dezvoltare

Recomandări GOST	Ce să faci despre asta în practică
Trebuie menționate documente și materiale informaționale (studiu de fezabilitate, rapoarte privind lucrările de cercetare finalizate, materiale informaționale pentru sisteme interne, străine analogice etc.), pe baza cărora a fost elaborat TK și care ar trebui să fie utilizate la crearea sistemului.	Pentru a fi sincer, acest lucru este mai aproape de versuri. Mai ales când vorbesc efect economic și alte lucruri care sunt aproape imposibil de numărat obiectiv. Acestea. este posibil, desigur, atunci va fi mai degrabă pe hârtie, pur teoretic.

Prin urmare, este mai bine să vă referiți pur și simplu la raportul sondajului, la cerințele persoanelor cheie.

Și astfel, am avut în vedere toate secțiunile care pot fi incluse în Termenii de referință. „Mai”, nu „Obligat” tocmai pentru că orice document trebuie elaborat pentru a obține un rezultat. Prin urmare, dacă este evident pentru dvs. că o anumită secțiune separată nu vă va apropia de rezultat, atunci nu aveți nevoie și nu trebuie să pierdeți timp cu privire la aceasta.

Însă fără principalul lucru: cerințe funcționale, nu este completată o singură atribuție tehnică. Vreau să notez că, în practică, se întâlnesc acești termeni de referință și cum! Există cifre care vor putea dilua apa în toate secțiunile, descriu cerințele generale în termeni generali, iar documentul se dovedește a fi foarte greoi, și există multe cuvinte inteligente în el, și chiar și Clientului îi poate plăcea (adică el îl va aproba). Dar lucrul la acesta poate să nu funcționeze, adică. de la aceasta există prea puțin beneficii practice. În cele mai multe cazuri, astfel de documente se nasc atunci când trebuie să obțineți mulți bani special pentru Termenii de Referință, iar acesta trebuie făcut rapid și fără a intra în detalii. Și mai ales dacă se știe că lucrurile nu vor merge mai departe, sau o vor face oameni complet diferiți. În general, doar pentru dezvoltarea bugetului, în special a statului.

În al doilea articol, vom vorbi doar despre secțiunea 4 „Cerințe de sistem” și, în mod specific, vom formula cerințele din motive de claritate, specificitate și testabilitate.

De ce cerințele trebuie să fie clare, specifice și testabile.

Pentru că practica arată: la început, majoritatea specificațiilor tehnice dezvoltate de specialiști fie se dovedesc a nu fi la cerere (nu corespund realității), fie devin o problemă pentru cel care ar trebui să implementeze, deoarece Clientul începe să manipuleze termeni și cerințe nespecifice. Voi da câteva exemple despre ce fraze au fost întâlnite, ce a dus la acest lucru și apoi voi încerca să dau recomandări cu privire la modul de a evita astfel de probleme.

Tipul cerinței

Formulare greșită

Elaborarea și aprobarea specificațiilor tehnice pentru crearea unei etape AU a 3.1 a etapei specificațiilor tehnice. Ediția din 20.06.2018.

Elaborarea și aprobarea specificațiilor tehnice pentru crearea unei AU

Creat pe 18.05.2018 11:24:34

Din dicționarul explicativ

Dezvoltarea este construcția, crearea, aprobarea - oferind un document forță legală (legală). În cea actuală, aceasta completează TK structural și obține o semnătură de aprobare pe pagina sa de titlu. Și o amprentă sigilială afirmativă.

Termeni și definiții

Aprobare - Un certificat oficial al unui funcționar autorizat sau dezvoltat este intrat în vigoare. Certificatul poate fi fixat pe documentul aprobat direct sau prin referire la un alt document care conține decizia de aprobare (act, protocol, scrisoare etc.) [din clauza 1.4.74 R 50-605-80-93].

Cerințele standardelor

Pagina cu titlu conține organizațiile client, dezvoltator și omologare, care sunt aplicate cu sigiliul oficial. Dacă este necesar, pagina de titlu este întocmită pe mai multe pagini. Semnăturile dezvoltatorilor specificației tehnice pentru NPP și a oficialilor participanți la aprobarea și examinarea proiectului de specificații pentru PNP sunt plasate pe ultima foaie. Formularul paginii de titlu a TK la AU este prezentat în. Formula ultimei foi de TK pentru AU este dată în [din clauza 3.4 din GOST 34.602-89].

La 3.1 „Elaborarea și aprobarea specificațiilor tehnice pentru crearea centralei nucleare” se realizează dezvoltarea și, dacă este necesar, specificații tehnice pentru partea centralei nucleare [din clauza 7 din apendicele. 1 GOST 34.601-90].

Documente relatate

GOST 34.602-89 IT. Set de standarde pentru sisteme automate. Termeni de referință pentru crearea unui sistem automat

Acest text a fost creat doar în scopul existenței unei legături permanente, pe care autorul însuși și toate dvs. le-a putut trimite în siguranță viitorilor dvs. clienți, colegi, rude și prieteni sub forma unui răspuns standard la întrebarea: „Am nevoie de specificația dvs. tehnică și, în general, ce aceasta este?"

După cum se spune - „în loc de o mie de cuvinte”, pentru că de fiecare dată evanghelizarea timp de 4-5 ore pe Skype pe acest subiect devine deja obositoare, iar tendința globală de a aluneca prostii deschise sub definiția „Termeni de referință” devine din ce în ce mai puternică de-a lungul anilor.

Problemă

Cert este că, atunci când există un format specific, precum și o definiție clară și inteligibilă a unui termen, atunci toate manipulările și înlocuirile acestuia pentru propriile documente, prototipuri, chestionare, descrieri și aplicații primite în zbor, arată cel puțin, neprofesionist. Prin urmare, începem cu o definiție științifică a conceptului nostru:

Termeni de referință - un document inițial pentru proiectarea unui obiect tehnic (produs). TK stabilește scopul principal al obiectului dezvoltat, caracteristicile sale tehnice, indicatorii de calitate și cerințele tehnice și economice, instrucțiunile pentru efectuarea etapelor necesare creării documentației (proiectare, tehnologice, software etc.) și compoziția acestuia, precum și cerințele speciale. Termenii de referință sunt un document legal - întrucât o cerere este inclusă în contractul dintre client și contractant pentru lucrări de proiectare și este baza acesteia: determină procedura și condițiile de lucru, inclusiv obiectivul, obiectivele, principiile, rezultatele preconizate și termenele. Adică trebuie să existe criterii obiective după care este posibil să se stabilească dacă un anumit obiect de muncă a fost realizat sau nu. Toate modificările, completările și clarificările formulării TK trebuie să fie convenite cu clientul și aprobate de acesta. Acest lucru este necesar, de asemenea, în cazul în care în procesul de soluționare a problemei de proiectare, inexactități sau inexactități ale datelor inițiale, este necesar să se determine gradul de vinovăție al fiecăreia dintre părțile care participă la dezvoltare, distribuirea pierderilor suportate în această legătură. Termeni de referință ca termen în domeniu tehnologia Informatiei Este un document semnificativ din punct de vedere juridic care conține informații complete necesare pentru stabilirea sarcinilor executanților pentru dezvoltarea, implementarea sau integrarea unui produs software, sistem informatic, site web, portal sau alt serviciu IT.

Traducem în limbaj inteligibil

1) Atribuire tehnică - stabilește o sarcină. Aceasta înseamnă că ar trebui să meargă înaintea proiectului de prototip, schiță, test, proiect, deoarece orice mapă de minte, diagrama de flux de date, arhitectură este deja performanța unei anumite sarcini, acesta este răspunsul la o întrebare. Și înainte ca întrebarea în sine să nu fi fost încă pusă, formulată și semnată de toate părțile - orice răspuns va fi greșit a priori, nu? Deci, începutul oricărei lucrări la orice proiect este o afirmație a problemei, nu o căutare frenetică a schițelor a o duzină de opțiuni pentru rezolvarea lui.

2) De fapt, unul nou rezultă logic din primul punct - textul TK însuși trebuie să înceapă cu capitolul „Obiective și obiective”, care formulează clar ce obiective de afaceri sunt urmărite de această întreagă următoarea încercare de a crește entropia în lume. O sarcină inutilă care nu rezolvă nicio problemă, nu realizează nimic și se face „din plictiseală” - nu este considerată oficial o sarcină tehnică, iar din acel moment se află în statutul de „hârtie obișnuită”.

3) Cum înțelegeți dacă conceptul de proiect propus sau un prototip interactiv, sau chiar un site gata de utilizare, rezolvă problema de afaceri de mai sus? Nu este nimic de făcut, va trebui să revenim la definiția din nou: „determină ... rezultatele așteptate și intervalul de timp pentru implementare. Adică trebuie să existe criterii obiective după care este posibil să se stabilească dacă acest lucru sau acel element a fost finalizat sau nu. " Adică, nu poate exista TK fără indicatori clar măsurabili în ruble, secunde, tone-kilometri sau grade Celsius. O cutie scurtă, sau un prototip, sau orice altă hârtie absurdă, dar nu o sarcină tehnică.

Prin urmare, concluzionăm că în acest TK trebuie să existe în mod necesar un capitol „Procedura de acceptare și evaluare”, când acești aceiași indicatori sunt luați, măsurați, iar părțile strâng mâinile sau trimit proiectul pentru reeditare.

4) Termenii de referință trebuie să fie în mod necesar de acord plan general de afaceri client, cu strategia sa de dezvoltare a afacerii și analiza segmentului de piață. Toate acestea vă vor permite să setați obiectivele corecte, să deduceți valori exacte, conform cărora puteți apoi să acceptați în mod adecvat produsul informațional finalizat. Lipsa unui plan de afaceri a clientului garantează automat executarea neprofesională a Termenilor de referință.

Studiul externalizat cunoaște obiectivele de afaceri și performanțele măsurabile ale afacerii mai bine decât proprietarul? Evident, nu, ceea ce înseamnă că TK-ul corect ar trebui să fie scris de reprezentanții Clientului, și nu de angajații Antreprenorului. Este absurd când un executant își stabilește o sarcină pentru sine, apoi vine cu modalități de evaluare a acesteia și, în final, își dă o notă finală pentru munca depusă. În mod ideal, nu ar trebui să existe o astfel de „inițiativă”, deși în practică acest lucru este exact ceea ce se întâmplă peste tot, în urma căreia Atribuirea tehnică nu oferă nevoie de ajutor proiect, de multe ori fiind în esență un document fals. Nu face asta.

5) Fiecare modificare a TK-ului finalizat ar trebui să coste bani. Este imposibil să editați gratuit și fără încetare Constituția Proiectului dvs. doar pentru că una dintre părți s-a răzgândit, nu a dormit suficient, a decis dintr-o dată să economisească bani etc. Prețul fiecărei modificări a TK ar trebui să fie, de asemenea, indicat în avans în capitolul relevant.

Apropo, în teorie, fiecare modificare de design sau modificări ale listei de pagini sau funcții ar trebui să aibă un preț clar, care este plătit în avans, înainte de efectuarea modificării. Personal, îmi propun să estimați orice revizuire a TK aprobat la 30% din bugetul total al proiectului, dar puteți face altfel.

Merită menționat faptul că este pur și simplu necesar să indicați în avans calendarul și bugetul total pentru dezvoltare, precum și o listă a tuturor resurselor și limitărilor existente? - Nu, va fi prea evident.

Deci, ce facem? Pentru ce? Cum înțelegem ce am făcut? Cât costă fiecare pivot? - răspunsurile la toate aceste întrebări scrise pe o bucată de hârtie sunt un „glonț de argint” capabil să scoată chiar și cel mai eșuat proiect.

testează întrebări

Și aici voi enumera răspunsurile la cele mai frecvente întrebări din partea clienților:

1) Deci, poate exista un GOST oficial pentru redactarea misiunii tehnice? - Da, chiar și câțiva.

2) Ce, atribuirea tehnică nu include o descriere a paginilor necesare, numărul de butoane, bibliotecile utilizate, ghidurile etc. - Nu există TK în sine, dar puteți pune toate acestea în anexe, desigur, ajustând toate acestea cu obiectivele, restricțiile și modalitățile de a evalua în continuare rezultatul obținut. Postează cel puțin tot conținutul viitor, cel puțin o descriere a caracterelor tipice - dar nu în loc de o declarație clară a problemei, ci după aceasta.

3) Deci poate nu am nevoie? - Poate că astăzi mii de site-uri sunt făcute fără TK, la fel cum mii de oameni din lume trăiesc frumos, fiind orbi de la naștere. Dar dacă doriți să vedeți unde mergeți în general, luați decizii în mod conștient și independent, evaluați rezultatele obținute, atunci nu puteți face fără TK.

4) Deci tu și Wikipedia scrii că TK-ul este creat de client. Dar nu știu cum / nu am timp / pur și simplu nu vreau să fac singur. Cum să fii? - Predați specificația tehnică unui terț care este destul de familiarizat cu afacerea dvs., sarcinile sale, public țintă și nevoile și, în același timp, conștient de toate etapele dezvoltării web. Această terță parte va deveni un fel de „notar web”, adică un garant pe care contractantul nu va subestima indicatorii de care ai nevoie sau nu va întârzia, și că clientul va seta metrici realizabile, iar la acceptarea finală nu va evalua subiectiv produsul creat, schimbându-i pe cei înregistrați anterior din mers. cerințe.

5) Și dacă TK-ul este un document legal, atunci îl pot da în judecată pe contractor, nu îl plătesc, să-l oblig să refacă totul pentru a zecea oară? - Dacă documentul este întocmit corect, sunt indicate obiectivele și metodologia de evaluare a realizării acestora; dacă documentul este semnat de părți și este menționat în acord (specificația tehnică în sine nu este un acord), atunci puteți, desigur. Dar, cu obișnuitul scurt, prototipuri, aspect de creație artă, Safe deal on FL - nu mai este.

6) Mi se spune că lucrarea va fi realizată conform unui fel de Scrum sau Ajail; ceea ce înseamnă că nu mai am nevoie de TK arhaic. Asta este adevărat? - Judecă-te pentru tine: te numesc un cuvânt de neînțeles, în mod clar ceva deghizător, iar acum, pe baza unui termen necunoscut, sugerează să abandonezi un document legal competent, completat de obiective și metrici. Agile în sine nu poate stabili niciun scop de genul „realizarea a cel puțin 10.000 de vizite până la sfârșitul anului” sau „a ajunge la peste 25 de comenzi de pe site într-o lună”, nu poate stabili, acesta este doar un mod de a organiza întâlniri și de a reorganiza angajații neglijenți. Gândiți-vă de câteva ori: „Nu vă este stimulat?” De fapt, TK-ul profesional nu poate dăuna niciunui Scrum nou-născut, dar ajutorul este obligatoriu.

Sarcina tehnică (denumit în continuare TK) - acest document servește ca bază, punct de plecare pentru crearea oricărui proiect sau produs. TK indică principalele criterii, principii și scopul obiectului. Cerințele tehnice și software, indicatorii cantitativi și calitativi, cerințele de proiectare și respectarea GOST-urilor și multe altele pot fi specificate în TK.

TK este document legal, care face parte din contract (de obicei ca atașament) între client și contractant pentru efectuarea anumitor lucrări, producție sau servicii. Termenii de referință descriu cel mai complet sarcinile, obiectivele, principiile, termenii, procedura și rezultatele așteptate ale tuturor lucrărilor. Drept urmare, TK este cel care servește ca un document prin care se evaluează conformitatea lucrărilor efectuate pentru fiecare articol.

Modificările aduse oricărui punct al misiunii tehnice trebuie să parcurgă procesul de acord cu clientul și sunt aprobate de acesta. Acest lucru este dictat de faptul că, în timpul muncii, apar inexactități, abateri sau erori în datele inițiale, una sau alta parte poate suferi pierderi, iar TK va reglementa gradul de vinovăție al uneia sau alteia părți.

Inițial, TK este pregătit și furnizat de client, dar de multe ori clientul transferă această sarcină către antreprenor, oferind doar un număr de condiții tehnice și dorește în limbajul consumatorului, departe de limbajul profesional și terminologia subiectului. Este necesar să se evite ambiguitatea și interpretarea ambiguă a clauzelor TOR, acest lucru poate duce la incertitudine între toți participanții și nu va permite o evaluare obiectivă a calității muncii depuse. De asemenea, contractantul trebuie să fie conștient de faptul că este posibil ca clientul să nu aibă o înțelegere deplină și cunoaștere a cerințelor speciale, ceea ce nu îl înlătură în niciun fel pe contractant de responsabilitatea și obligația de a respecta toate normele și cerințele autorităților de supraveghere, indiferent dacă au fost sau nu în TOR. Astfel, atât clientul, cât și contractantul sunt responsabili pentru stabilirea sarcinilor în TOR și calitatea rezultatului.

În orice caz, cu cât TOR va fi întocmit și convenit cu mai multă atenție și cu cât va fi convenit, cu atât mai puține grade de libertate și lacune vor rămâne pentru contractant pentru a-și îndeplini activitatea pe nedrept. În funcție de competența tehnică care va fi elaborată, de calitatea și viteza lucrărilor vor depinde, această afirmație funcționează și în sens invers.

O specificație tehnică redactată în mod competent crește cu 50% șansele unei finalizări cu succes a unui viitor proiect, iar timpul investit în elaborarea unei specificații tehnice este una dintre cele mai bune investiții pe care un client le poate face în perioada proiectului. Prin urmare, pregătirea specificațiilor tehnice este încredințată celor mai experimentați și calificați specialiști, deoarece corectarea oricărei greșeli făcute în faza de proiectare a caietului de sarcini poate fi foarte scumpă după încheierea contractului, iar în unele cazuri chiar pune capăt proiectului în ansamblu.

Termenii de referință servesc ca o punte solidă de înțelegere între client și contractant, ajutând la înțelegerea:

Către client:

Ce anume ar dori să primească la ieșire, bazându-se pe resursele și capacitățile sale actuale;
Efectuează coordonarea internă a solicitărilor între unitățile structurale;
Monitorizați conformitatea lucrărilor executate de antreprenor.

Pentru contractant:

Înțelegeți esența și detaliile sarcinii;
Realizați planuri pentru executarea lucrărilor;
Excludeți lucrările suplimentare care nu sunt descrise în termeni de referință sau necesitați finanțare suplimentară pentru acest lucru.

Pentru toate părțile:

Înțelegeți esența și aspectul produsului sau serviciului final;
Verificați activitatea desfășurată, efectuați teste de acceptare;
Pentru a minimiza numărul de erori și inexactități în procesul de modificare.

Ar putea fi util să citiți: