Elaborarea și aprobarea specificațiilor tehnice. Termeni de referință: formare și coordonare. Etape de elaborare a specificațiilor tehnice

Pregatirea pentru munca de laborator

Pentru a face cunoștință cu materialul de curs pe tema „Modele de ciclu de viață software. Etapele ciclului de viață în conformitate cu GOST 19.102-77. Enunțarea problemei „disciplinei” Dezvoltarea și standardizarea sistemelor 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țele pentru un produs software, definește termenii și etapele de dezvoltare și reglementează procesul de testare de acceptare. La dezvoltarea sarcinii tehnice participă atât reprezentanți ai clientului, cât și reprezentanți ai antreprenorului. Acest document se bazează pe cerințele inițiale ale clientului, analiza progreselor tehnologice avansate, rezultatele muncii de cercetare, cercetări pre-proiectare, prognoză științifică etc.

Procedura de elaborare a specificațiilor tehnice

Elaborarea specificațiilor tehnice se realizează în următoarea secvență. În primul rând, se stabilește un set de funcții de îndeplinit, precum și o listă și caracteristici ale datelor inițiale. Apoi se stabilește o listă de rezultate, caracteristicile acestora și metodele de prezentare.

În plus, este specificat mediul de operare. software: configurație și parametri specifici mijloace tehnice, versiunea folosită sistem de operareși, eventual, versiunile și parametrii altor software instalați cu care viitorul produs software va interacționa.

În cazurile în care software-ul dezvoltat colectează și stochează unele informații sau este implicat în gestionarea oricărui proces tehnic, este, de asemenea, necesar să se reglementeze clar acțiunile programului în cazul apariției echipamentelor și a întreruperilor de curent.

1. Dispoziții generale

1.1. Termenii de referință sunt redactați în conformitate cu GOST 19.106-78 pe foi 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, deasupra textului.

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

1.3. Pentru a face modificări și completări la fundalul tehnic în etapele ulterioare ale dezvoltării unui program sau a unui produs software, este lansat un addendum la acesta. Coordonarea și aprobarea completării la caietul de sarcini se realizează în aceeași ordine care este stabilită pentru caietul de sarcini.

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

Introducere;

Denumirea și domeniul de aplicare;

Baza dezvoltării;

Scopul dezvoltării;

Cerinte tehnice la programul sau elementul software;

Indicatori tehnico-economici;

Etape și stadii de dezvoltare;

Procedura de control si acceptare;

Aplicații.

În funcție de caracteristicile programului sau produsului software, este permisă clarificarea conținutului secțiunilor, introducerea de noi secțiuni sau combinarea unora dintre ele. Dacă este necesar, este permisă includerea cererilor în termenii de referință.

2.1 Introducerea ar trebui să includă descriere scurta domenii de aplicare a programului sau produs software, precum și obiectul (de exemplu, un sistem) în care ar trebui să fie utilizate. Scopul principal al introducerii este de a demonstra relevanța acestei dezvoltări și de a arăta ce loc ocupă această dezvoltare între cele similare.

2.2 În secțiunea „Nume și domeniul de aplicare” indicați numele, o scurtă descriere a domeniului de aplicare al programului sau produsului software și obiectul în care este utilizat programul sau produsul software.

2.3 În secțiunea „Baze pentru dezvoltare”, trebuie să fie indicate următoarele:

Documentul (documentele) pe baza cărora se realizează elaborarea. Un astfel de document poate fi un plan, comandă, 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 un produs software” ar trebui să conțină următoarele subsecțiuni:

Cerințe pentru caracteristicile funcționale;

Cerințe de fiabilitate;

Conditii de operare;

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 componența funcțiilor îndeplinite, organizarea datelor de intrare și de ieșire, caracteristicile de timp etc.

2.5.2 Subsecțiunea „Cerințe pentru fiabilitate” va specifica cerințele pentru asigurarea funcționării fiabile (asigurarea funcționării stabile, controlul informațiilor de intrare și de ieșire, timpul de recuperare după defecțiune etc.).

2.5.3.La subsecțiunea „Condiții de funcționare” trebuie specificate condițiile de funcționare (temperatura mediului ambiant, umiditate relativă etc. pentru tipurile de suporturi de date selectate), sub care trebuie asigurate caracteristicile specificate, precum și tipul de serviciu, suma necesarăși calificarea personalului.

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

2.5.5 În subsecțiunea „Cerințe privind compatibilitatea informațiilor și software-ului”, trebuie indicate cerințele pentru structurile de informații la intrare și ieșire și metode de soluție, coduri sursă, limbaje de programare. Protecția informațiilor și a programelor ar trebui asigurată acolo unde este necesar.

2.5.6.În subsecțiunea „Cerințe pentru marcare și ambalare” în 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”, pentru produsul software trebuie specificate condițiile de transport, locațiile de depozitare, condițiile de depozitare, condițiile de depozitare, timpii de depozitare în diverse condiții.

2.5.8. În secțiunea „Indicatori tehnici și economici” trebuie indicați: aproximativ eficiență economică, cererea anuală estimată, avantajele economice ale dezvoltării în comparație cu cele mai bune probe interne și străine sau analogi.

2.6 În secțiunea „Etape și etape de dezvoltare” sunt stabilite etapele necesare de desfășurare, etapele și conținutul lucrării (o listă a documentelor programului care trebuie elaborate, agreate și aprobate), precum și, de regulă, momentul dezvoltării și determinați performanții.

2.7.În secțiunea „Procedura de control și recepție”, tipurile de încercări și Cerințe generale pentru acceptarea muncii.

2.8 În anexele la caietul de sarcini, dacă este necesar, menționați:

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

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

Alte surse de dezvoltare.

În cazurile în care clientul nu face nicio cerință stipulată în termenii de referință, este necesar să se indice în locul corespunzător „Cerințele nu sunt prezentate”.

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

Întrebări de control

1.Dați conceptul de model ciclu de viață PE.

2. Prezentați etapele dezvoltării software-ului.

3. Ce include enunțul problemei și cercetarea pre-proiect?

4. Listaț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 locuri de muncă

Lucrări de laborator Nr. 1-5 sunt efectuate pentru aceeași variantă.

1. Pentru a dezvolta un modul de program „Contabilitatea progresului elevilor”. Modulul software este conceput pentru contabilizarea operațională a progresului studenților în sesiune de către decanul, subdecanii și angajații decanatului. Informațiile despre progresul studenților trebuie păstrate pe întreaga perioadă de studiu și utilizate în pregătirea certificatelor despre cursurile urmate și suplimentele la diplomă.

2. Dezvoltați un modul software „Fișierele personale ale elevilor”. Modulul software este conceput pentru a obține informații despre studenți de către angajații decanatului, comitetului sindical și departamentului de personal. Informațiile trebuie păstrate pe întreaga durată a pregătirii studentului și utilizate în pregătirea certificatelor și rapoartelor.

3. Dezvoltarea unui modul software „Rezolvarea problemelor de optimizare combinatorie”. Modulul ar trebui să conțină algoritmi pentru găsirea unui ciclu de lungime minimă (problema vânzătorului ambulant), găsirea celei mai scurte căi și găsirea unui arbore de legătură minim.

4. Dezvoltați un modul de program „Procesare matrice”. Modulul ar trebui 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ție Windows"Organizator". Aplicația este concepută pentru a înregistra, stoca și căuta adrese și numere de telefon indiviziiși organizații, precum și programe, întâlniri etc. Aplicația este destinată oricărui utilizator de computer.

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

7. Elaborați un modul de program „Departament” care să conțină informații despre personalul departamentului (nume, funcție, grad academic, discipline, volum de muncă, munca sociala, job part-time etc.). Modulul este destinat utilizării de către angajații departamentului de personal și ai decanatului.

8. Dezvoltați un modul de program „Laborator” care să conțină informații despre personalul laboratorului (nume complet, sex, vârstă, starea civilă, prezența copiilor, funcție, grad 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ățătorie chimică”. La înregistrarea pentru serviciu, se completează o cerere, care indică numele proprietarului, descrierea produsului, tipul serviciului, data primirii comenzii și costul serviciului. După finalizarea lucrării, se tipărește o chitanță.

10. Dezvoltarea unui modul software „Contabilitatea încălcărilor regulilor trafic rutier". O listă de încălcări este stocată în baza de date pentru fiecare mașină (și proprietarul acesteia). 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. Dezvoltați un modul software „Autoshop Card File” destinat utilizării de către angajații 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 caută o opțiune potrivită. Dacă nu este cazul, clientul este introdus în baza de clienți și este notificat când apare o opțiune.

12. Dezvoltarea unui modul software „Card de abonat ATS”. Fișierul cardului conține informații despre telefoane și proprietarii acestora. Fixează restanțele la plată (abonat și în funcție de timp). Se crede că salariile de timp ale locale convorbiri telefonice deja introdus.

13. Dezvoltarea unui modul software „Autokassa”, care să conțină informații despre disponibilitatea locurilor gratuite pe rutele de autobuz. Baza de date ar trebui să conțină informații despre numărul zborului, rută, șofer, tipul de autobuz, data și ora plecării, precum și prețurile biletelor. La primirea unei cereri de bilete, programul caută un zbor potrivit.

14. Dezvoltați un modul software „Librărie” care să conțină informații despre cărți (autor, titlu, editura, anul apariției, preț). Cumpărătorul întocmește o cerere pentru cărțile de care are nevoie, dacă nu există, este introdus în baza de date și este anunțat când sosesc cărțile necesare la magazin.

Sunt adesea întrebat: „Cum să dezvolt corect o sarcină tehnică pentru un sistem automatizat?” Subiectul dezvoltării unei sarcini tehnice este discutat constant în diferite forumuri. Această întrebare este atât de largă încât este imposibil să răspunzi 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 ar funcționa să pun totul într-un singur articol, pentru că se va dovedi sub 50 de pagini și am decis să o împarți în 2 părți:

In prima parte" Elaborarea specificațiilor tehnice. Ce este, de ce este nevoie, de unde să încep ș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 cu privire la formularea cerințelor.
A doua parte " Elaborarea specificațiilor tehnice. Cum se formulează cerințe?" va fi dedicat în întregime 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 se dezvoltă o specificație tehnică?” Cert este că abordarea dezvoltării specificațiilor tehnice va depinde și de scopul pentru care se face acest lucru, precum și de către cine va fi utilizat. Despre ce optiuni vorbesc:

O organizație comercială a decis să implementeze un sistem automatizat. Nu are propriul serviciu IT și a decis să facă următoarele: Persoana interesată ar trebui să elaboreze Termenii de referință și să-i prezinte unei organizații terțe pentru dezvoltare;
O organizație comercială a decis să implementeze un sistem automatizat. Are propriul serviciu IT. Am decis să facem acest lucru: să dezvoltăm Termenii de referință, apoi să îi convinem între serviciul IT și părțile interesate și să-i implementăm pe cont propriu;
Agenția guvernamentală a decis să demareze un proiect IT. Totul este atât de noroi aici, o mulțime de formalități, kickback-uri, tăieturi etc. Nu voi lua în considerare această opțiune în acest articol.
O companie IT este angajată în servicii de dezvoltare și/sau implementare de sisteme automatizate. Acesta este cel mai dificil caz, deoarece trebuie să lucrați într-o varietate de condiții:
Clientul are proprii săi specialiști cu propriile puncte de vedere și fac cerințe specifice pentru Termenii de referință;
- Termenii de referință sunt dezvoltați pentru proprii noștri dezvoltatori (clientului nu îi pasă);
- Termenii de referință sunt dezvoltați pentru transferul către contractant (adică un grup de programatori situat în afara personalului companiei sau un specialist individual);
- Există o neînțelegere între companie și client cu privire la rezultatul obținut, iar compania își pune din nou și din nou întrebarea: „Cum ar trebui să fie elaborati Termenii de Referință?” Poate că acest din urmă 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? De unde le pot lua?
Cine ar trebui să elaboreze Termenii de referință? Ar trebui această persoană să aibă cunoștințe speciale?
Cum să înțelegeți dacă Termenii de referință sunt bine scrisi sau nu?
Pe cheltuiala cui ar trebui să fie dezvoltat și este necesar?

Lista poate fi nesfârșită. Vorbesc atât de încrezător pentru că sunt în dezvoltarea de software profesională de 15 ani, iar întrebarea Termenilor de referință apare în orice echipă de dezvoltare cu care trebuie să lucrez. Motivele pentru aceasta sunt diferite. Ridicând subiectul dezvoltării Termenilor de referință, sunt perfect conștient că nu o voi putea prezenta 100% pentru toți cei interesați de subiect. Dar, voi încerca, după cum se spune, „pune totul pe rafturi”. Cei care sunt deja familiarizați cu articolele mele știu că nu folosesc „copy-paste” ale lucrărilor altora, nu retipăr cărțile altora, nu citez standarde cu mai multe pagini și alte documente pe care le puteți găsi pe site-ul dvs. Internet, pretinzându-le drept gândurile mele strălucite. Este suficient să tastați în motorul de căutare „Cum să dezvoltați o misiune tehnică” și puteți citi multe lucruri interesante, dar, din păcate, de multe ori repetitive. De regulă, cei cărora le place să fie inteligenți pe forumuri (încearcă să caute la fel!) Nu au făcut niciodată ei înșiși un termen de referință sensibil și citează în mod continuu recomandările GOST pe această problemă... Și pentru cei care sunt cu adevărat serioși în privința problemei, de obicei nu există timp pentru a sta pe forumuri. Apropo, vom vorbi și despre GOST-uri. În diferiți ani ai muncii mele, a trebuit să văd multe opțiuni pentru documentația tehnică compilată atât de specialiști individuali, cât și de echipe eminente și firme de consultanta... Uneori mă angajez și în astfel de activități: îmi aloc timp pentru mine și caut informații despre un subiect de interes din surse neobișnuite (cum ar fi puțină inteligență). Ca urmare, a trebuit să văd documentația pentru astfel de 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 accesibile publicului sau din iresponsabilitatea consultanților (împrăștierea informațiilor pe Internet). Prin urmare, spun imediat: informații confidențiale care aparține altor companii nu este împărtășită, indiferent de sursa apariției (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, „Termeni de referință”.

Da, chiar există GOST-uri și standarde în care se încearcă reglementarea acestei părți a activității (dezvoltare software). Pe vremuri, toate aceste GOST-uri erau 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 lungi și sunt încă relevante. Alții spun că sunt iremediabil depășiți. Poate că cineva se gândește acum că adevărul este undeva la mijloc. Aș răspunde cu cuvintele lui Goethe: „Se spune că există adevăr între două opinii opuse. În niciun caz! Există o problemă între ei.” Deci, nu există adevăr între aceste opinii. Pentru că 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 în mod clar nu oferă nici măcar o definiție, ci doar spune: „Specificația tehnică pentru CNE este principalul document care definește cerințele și procedura pentru crearea (dezvoltarea sau modernizarea - crearea ulterioară) a unui sistem automatizat, în în conformitate cu care se realizează dezvoltarea UA și acceptarea acesteia la punerea în acțiune”.

Dacă cineva este interesat de ce GOST-uri vorbesc, atunci iată-le:

GOST 2.114-95 un singur sistem documentatia de proiectare. Conditii 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 automatizat.

O definiție mult mai bună este prezentată în Wikipedia (adevărată despre TK în general, și nu doar pentru software): „ Sarcina tehnică- acesta este documentul inițial de proiectare tehnic obiect. Sarcina tehnică stabilește scopul principal al obiectului dezvoltat, tehnic și tactic specificații, indicatorii de calitate și cerințele tehnice și economice, prescripțiile pentru realizarea etapelor necesare realizării documentației (proiectare, tehnologică, software etc.) și alcătuirea acesteia, precum și cerințe speciale. O sarcină ca document sursă pentru a crea ceva nou există în toate domeniile de activitate, care diferă î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 operă literară etc.) "

Și astfel, după cum reiese din definiție, scopul principal al Termenilor de referință este de a formula cerințele pentru obiectul în curs de dezvoltare, în cazul nostru pentru un sistem automatizat.

Tocmai cel principal, dar singurul. A sosit momentul să abordăm principalul lucru: să rezolvăm totul „pe rafturi”, așa cum am promis.

Ce trebuie să știți despre cerințe? Este necesar să înțelegem clar că toate cerințele trebuie împărțite pe tip și pe 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 acolo este un exemplu bun ce tipuri de cerințe ar trebui luate în considerare. De exemplu:

Cerințe de funcționalitate;
Cerințe pentru securitate și drepturi de acces;
Cerințe pentru calificarea personalului;
…. etc. Puteți citi despre ele în GOST menționat (și mai jos le voi lua în considerare și mai detaliat).

Cred că este evident pentru tine că factorul cheie pentru un Termeni de referință de succes este exact cerințele bine formulate pentru funcționalitate. Pentru aceste cerințe sunt dedicate majoritatea lucrărilor și tehnicilor despre care am vorbit. Cerințele pentru funcționalitate reprezintă 90% din complexitatea muncii privind dezvoltarea Termenilor de referință. Orice altceva este adesea „camuflajul” care este pus pe aceste cerințe. Dacă cerințele sunt prost formulate, atunci ce camuflaj frumos nu ar trebui să porți, proiect de succes nu va funcționa. Da, în mod oficial, toate cerințele vor fi îndeplinite (conform GOST J), TK-ul a fost elaborat, aprobat și semnat, banii au fost primiți pentru el. Și ce dacă? Și atunci va începe cel mai interesant lucru: ce să faci? Dacă acesta este un proiect privind Ordinul de stat, atunci nu există probleme - acolo bugetul este de așa natură încât nu va intra în niciun buzunar, în procesul de implementare (dacă există) totul va fi clarificat. Exact așa sunt tăiate majoritatea bugetelor proiectelor pentru Comenzile Statului (au dat foc „TZ”, au turnat zece milioane, dar proiectul nu a fost realizat. Toate formalitățile au fost respectate, nu există vinovați, o mașină nouă este aproape. casa.Frumuse!). Dar vorbim despre organizatii comerciale unde banii contează, 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 cum rămâne cu proprietățile? Dacă tipurile de cerințe pot fi diferite (în funcție de obiectivele proiectului), atunci cu proprietăți 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 de turnesol”. Dacă rezultatul îndeplinirii unei cerințe nu poate fi testat, atunci acesta fie nu este clar, fie nu este specific. Gandeste-te la asta. În posesia acestor trei proprietăți de cerințe se află îndemânarea și profesionalismul. De fapt, totul este foarte simplu. Când îți dai seama.

Pe aceasta, povestea a ceea ce ar putea fi completați Termenii de referință și treceți la principalul lucru: cum să formulați cerințele. Dar nu totul este atât de rapid. Mai este un punct extrem de important:

În ce limbă (din punct de vedere al complexității înțelegerii) sarcina tehnică ar trebui să fie scrisă?
Ar trebui descrise în ea specificarea diferitelor 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. De aceea apar adesea dispute cu privire la suficiența sau lipsa detalierii necesare a cerințelor, despre claritatea documentului de către Client și Antreprenori, despre redundanță, format de prezentare etc. Și unde este granița generală dintre Termenii de Referință și Proiectul Tehnic?

Sarcina tehnică este un document bazat pe cerințe formulate într-un limbaj ușor de înțeles (obișnuit, familiar) pentru Client. În același timp, terminologia din industrie care este pe înțelesul Clientului poate și ar trebui utilizată. Nu ar trebui să existe legături cu specificul implementării tehnice. Acestea. în stadiul TK, în principiu, nu contează pe ce platformă vor fi implementate aceste cerințe. Exista si exceptii. Dacă vorbim de implementarea unui sistem bazat pe un produs software existent, atunci o astfel de legare poate avea loc, dar numai la nivel de formulare de ecran, formulare de raport etc. analist de afaceri.Și cu siguranță nu un programator (cu excepția cazului în care combină aceste roluri în sine, asta se întâmplă). Acestea. această persoană ar trebui să vorbească cu Clientul în limba afacerii sale.

Proiect tehnic este un document care este destinat implementarii tehnice a cerintelor formulate in Termenii de Referinta. 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ă se aprofundeze în acest lucru (s-ar putea să nu înțeleagă astfel de termeni). Designul tehnic face Arhitect de sistem(Aici este destul de normal să combinați acest rol cu un programator). Mai precis, un grup de specialiști AO este condus de un arhitect. Cu cât proiectul este mai mare, 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 pentru aprobare de către Termenii de referință, care este plin de terminologie tehnică, descrieri ale tipurilor de date și valorile acestora, structura bazei de date etc. cerințe de afaceri. Este aceasta o situație familiară? Și cum se termină? De regulă, un astfel de TK este aprobat, apoi implementat, iar în 80% din cazuri nu corespunde deloc faptului muncii efectuate, deoarece au decis să se schimbe, să refacă multe lucruri, au înțeles greșit, au gândit greșit etc. etc. Și apoi începe seria despre livrarea lucrărilor. „Dar nu așa avem nevoie”, ci „acest lucru nu va funcționa pentru noi”, „acest lucru este prea dificil”, „acest lucru este incomod,” etc. Suna familiar? !! Asta îmi este familiar, a trebuit să umplu conurile la timp.

Deci, ce avem în practică? În practică, avem o graniță neclară între Termenii de referință și Proiectul tehnic. Ea plutește între TK și TP într-o varietate de forme. Și asta e rău. Și se dovedește așa pentru că cultura dezvoltării a devenit slabă. Acest lucru se datorează parțial competențelor specialiștilor, parțial dorinței de a reduce bugetele și termenele limită (la urma urmei, documentarea durează mult timp - acesta este un fapt). Mai este unul factor important afectând utilizarea Proiectului tehnic ca document separat: dezvoltarea rapidă a instrumentelor de dezvoltare rapidă, precum și metodologiile de dezvoltare. Dar aceasta este o poveste separată, chiar mai jos voi spune câteva cuvinte despre ea.

Un alt punct mic, dar important. Uneori, Termenii de referință sunt o mică parte de cerințe, simple ș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ă la raport etc. Această abordare este destul de justificată, de ce să vă complicați viața. Dar nu este folosit pentru proiecte mari, ci pentru îmbunătățiri minore. Aș spune că acest lucru este mai aproape de întreținerea unui produs software. În acest caz, un specific solutie tehnica implementarea cerinței. De exemplu, „Efectuați așa și așa o modificare în algoritmul așa și așa”, indicând o procedură specifică și o modificare specifică pentru programator. Acesta este cazul când granița dintre Caietul de sarcini și Proiectele tehnice este complet ștearsă, deoarece nu este fezabilitate economica umfla actele acolo unde nu este nevoie, dar document util este creat. Și este corect.

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

Sunt supraîncălzit? Este posibil, fără? Termeni de referinta? Imaginați-vă că este posibil (mai precis, se întâmplă), iar această abordare are mulți adepți, iar numărul acestora este în creștere. De regulă, după ce tinerii specialiști citesc cărți despre Scrum, Agile și alte tehnologii de dezvoltare rapidă. De fapt, acestea sunt tehnologii minunate și funcționează, doar că nu spun literal „nu trebuie să faceți specificații tehnice”. Se spune „un minim de hârtii”, mai ales inutile, mai aproape de Client, mai precis și mai rapid de rezultat. Dar nimeni nu a anulat fixarea cerințelor și este clar menționat acolo. Acolo sunt stabilite cerințele 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ă este posibil să simplificăm ceva, atunci să simplificăm absență completă... După cum spunea Einstein „ Fă-o cât mai simplu posibil, dar nu mai ușor.” ... Cuvintele de aur, la urma urmei, sunt potrivite pentru orice. Asa de Sarcina tehnică este necesar, altfel nu vei vedea un proiect de succes. O altă întrebare este cum să compun și ce să includă. Având în vedere metodologiile de dezvoltare rapidă, trebuie să vă concentrați doar pe cerințe, iar tot „camuflajul” poate fi renunțat. În principiu, sunt de acord cu asta.

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 activității de dezvoltare, de ex. 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. Ar trebui clientul să-l cunoască? Daca vrea, de ce nu, dar insista si afirma acest document nu este nevoie, doar va restrânge și interfera cu munca. Este aproape imposibil să proiectezi un sistem până la cel mai mic detaliu. În acest caz, va trebui să faceți în mod continuu modificări în Designul tehnic, ceea ce necesită mult timp. Și dacă organizația este foarte birocratică, atunci, în general, lăsați toți nervii acolo. Este vorba tocmai despre reducerea acestui tip de design despre care vorbim metodologii moderne dezvoltare rapidă, despre care am menționat mai sus. Apropo, toate se bazează pe abordarea clasică XP (programare extremă), care are deja aproximativ 20 de ani. Așadar, creați Termeni de referință de înaltă calitate, ușor de înțeles pentru client și utilizați Proiectul 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 subiectului (cum ar fi 1C și altele similare) presupun că proiectarea (adică procesul de documentare) este necesară doar în zonele cu adevărat complexe în care 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 formulate corect sunt suficiente. Acest lucru este dovedit de strategia de afaceri a acestei platforme în ceea ce privește formarea specialiștilor. Dacă te uiți la Biletul de examen specialist (așa se numește el, și nu „programator”), atunci vei vedea că există doar cerințe de business, iar modul de implementare a acestora într-un limbaj de programare este sarcina specialistului. Acestea. acea parte a sarcinii pe care Proiectul Tehnic este conceput să o rezolve, specialistul trebuie să o rezolve „în cap” (vorbim de sarcini de complexitate medie), iar aici și acum, urmând anumite standarde de dezvoltare și proiectare, care se formează din nou. de 1C pentru platforma sa. Astfel, din doi specialiști, rezultatul muncii cărora arată la fel, unul poate trece examenul, iar celălalt nu, deoarece standarde de dezvoltare grav încălcate. 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 studiul î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 specific despre formularea cerințelor pentru un sistem informațional, adică. presupunând că munca de dezvoltare a cerințelor de afaceri, formalizarea proceselor de afaceri și toate lucrările anterioare de consultanță a fost deja realizată. Bineînțeles că în această etapă pot fi efectuate unele rafinamente, dar tocmai perfecționări. Proiectul de automatizare în sine nu rezolvă problemele de afaceri - amintiți-vă acest lucru. Aceasta este o axiomă. Din anumite motive, unii manageri încearcă să o infirme, crezând că dacă vor cumpăra programul, atunci ordinea va veni într-o afacere haotică. Dar la urma urmei, axioma este, de asemenea, o axiomă că nu sunt necesare dovezi.

Ca și în cazul oricărei activități, formularea cerințelor poate (și ar trebui) să fie împărțită în etape. Toate la timpul lor. Aceasta este o muncă intelectuală grea. Și, dacă o tratează cu o atenție insuficientă, atunci rezultatul va fi pe măsură. Potrivit estimărilor experților, costul dezvoltării Termenilor de referință poate fi de 30-50%. sunt de aceeasi parere. Deși 50 este probabil prea mult. La urma urmei, Termenii de referință nu sunt ultimul document dezvoltat. La urma urmei, ar trebui să existe și un design 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 dezvoltarea într-un limbaj clasic precum C++, atunci nu se poate face fără proiectare 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, la dezvoltarea sistemului „de la zero”, acesta este proiectat conform schemei clasice) .

În ciuda faptului că declarația de cerințe este partea principală a Termeni de referinta, iar î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 întocmit în consecință. Unde sa încep? În primul rând, trebuie să începeți cu conținutul. Compuneți conținutul, apoi începeți să-l extindeți. Personal, fac asta: 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 (comparativ cu cerințele) și, în al doilea rând, în timp ce descrieți toate informațiile introductive, vă conectați la lucrul principal. Ei bine, asta e cum îți place. În timp, veți dezvolta propriul șablon al Termenilor de referință. Pentru început, vă recomand să luați ca conținut exact pe cel descris în GOST. Se potrivește perfect pentru conținut! Apoi luăm și începem să descriem fiecare secțiune, fără a uita de recomandările pentru respectarea a trei proprietăți: claritate, concretețe și testabilitate. De ce insist atât de mult cu asta? Mai multe despre asta în secțiunea următoare. Și acum îmi propun să trecem până la capăt prin punctele TK, care sunt recomandate în GOST.

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

În total, există 9 secțiuni, fiecare dintre acestea fiind, de asemenea, împărțită în subsecțiuni. Să le analizăm în ordine. Pentru comoditate, voi prezenta totul sub forma unui tabel pentru fiecare articol.

Sectiunea 1. informatii generale.

Recomandări conform GOST
numele complet al sistemului și simbolul acestuia;	Totul este clar aici: scriem cum se va numi sistemul, numele scurt
codul subiectului sau codul (numărul) contractului;	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) va lucra la proiect. De asemenea, puteți specifica rolurile lor. Puteți șterge această secțiune cu totul (mai degrabă formală).
o listă a documentelor 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 de început și de încheiere planificate pentru crearea sistemului;	Solicitări de termen limită. Uneori, ei scriu despre asta în TK, dar mai des astfel de lucruri sunt descrise în contractele de muncă
informatii despre sursele si procedura de finantare a lucrarii;	La fel, ca și în paragraful anterior despre calendar. Mai relevante pentru ordinele guvernamentale (pentru angajații de stat)
procedura de înregistrare și prezentare către client a rezultatelor lucrărilor privind crearea sistemului (părțile sale), privind fabricarea și reglarea mijloacelor individuale (hardware, software, informații) și complexe software și hardware (software și metodologice) a sistemului.	Nu văd necesitatea acestui punct, tk. cerințele pentru documentare sunt făcute separat și, în plus, există o întreagă secțiune separată „Procedura de control și acceptare” a sistemului.

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

Recomandări conform GOST	Ce să faci î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 stocurilor în compania X”, atunci puteți discuta rezultatul mult timp la finalizarea acestuia, chiar și indiferent de formularea bună a cerințelor. pentru că Clientul poate spune întotdeauna că a vrut să spună ceva diferit prin calitate. În general, vă puteți strica unii pe alții o mulțime de nervi, dar de ce? Este mai bine să scrieți imediat ceva de genul: „Sistemul este destinat întreținerii contabilitatea depozituluiîn compania X în conformitate cu cerințele stabilite în prezentul Termen 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 cu totul această secțiune. Un exemplu de obiectiv nereușit: „Oferiți documente rapide pentru manager”. Ce e rapid? Acest lucru poate fi apoi dovedit la nesfârșit. Dacă acest lucru este important, atunci este mai bine să reformulați acest obiectiv astfel: „Directorul de vânzări ar trebui să fie capabil să întocmească un document” Vânzări de mărfuri „de 100 de linii în 10 minute”. Un obiectiv similar poate apărea dacă, de exemplu, managerul petrece în prezent aproximativ o oră pe asta, ceea ce este prea mult pentru această companie și este important pentru ei. Într-o astfel de formulare, scopul se intersectează deja cu cerințele, ceea ce este destul de firesc, deoarece atunci când extindem arborele obiectivelor (adică le împărțim în obiective mai mici conexe), vom aborda oricum cerințele. Prin urmare, nu ar trebui să te lași dus de cap.

În general, capacitatea de a identifica obiective, 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 conform cerințelor, acest lucru este adesea practicat.

Secțiunea 3. Caracteristicile 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 privind numărul și calificările personalului din sistem și modul de lucru al acestora;
indicatori de destinație;
cerințe de fiabilitate;
cerințe de siguranță;
cerințe de ergonomie și estetică tehnică;
cerințe de transportabilitate pentru difuzoarele mobile;
cerințe de funcționare, întreținere, repararea și depozitarea componentelor sistemului;
cerințe pentru protecția informațiilor împotriva accesului neautorizat;
cerințe pentru siguranța informațiilor în caz de accidente;
cerințe de protecție împotriva influențelor externe;
cerințe pentru puritatea brevetului;
cerințe pentru standardizare și unificare;

În ciuda faptului că secțiunea principală va fi, fără îndoială, secțiunea cu cerințe specifice (funcționale), această secțiune poate fi și ea de mare importanță (și în majoritatea cazurilor o are). Ce poate fi important și util:

Cerințe de calificare... Poate că sistemul în curs de dezvoltare 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. Atenția insuficientă la această problemă se transformă adesea în probleme. Dacă calificările personalului existent sunt în mod clar insuficiente, este mai bine să prescrieți cerințele pentru organizarea formării, programului de formare, calendarului 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 acestea trebuie descrise separat, cât mai detaliat posibil, conform acelorași reguli ca și cerințele funcționale (claritate, concretețe, 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 furnizată o descriere a arhitecturii generale. Cel mai adesea, cerințele pentru integrare sunt, în general, evidențiate într-o secțiune separată sau chiar într-un termeni de referință separati. aceste cerințe pot fi destul de complexe.

Toate celelalte cerințe sunt mai puțin importante și nu trebuie descrise. După părerea mea, fac documentația mai grea și sunt de puțină utilitate practică. Și este foarte dificil să descrii cerințele pentru ergonomie sub formă de cerințe generale; este mai bine să le transferi la cele funcționale. De exemplu, se poate formula cerința „Obțineți informații despre prețul unui articol făcând clic pe un singur buton”. În opinia mea, aceasta este încă mai aproape de cerințele funcționale specifice, deși se referă la ergonomie.Cerințe pentru funcțiile (sarcinile) îndeplinite de sistem Aceasta este principala și punct-cheie care va determina succesul. Chiar dacă totul este făcut perfect, iar această secțiune este „3”, atunci rezultatul proiectului va fi în cel mai bun caz „3” sau chiar proiectul va eșua cu totul. De acestea ne vom ocupa mai detaliat în al doilea articol, care va fi inclus în numărul 5 al listei de corespondență. Până î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
Tehnic
Metrologic
organizatoric
Metodic
alte…

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

Nu au fost luate decizii cu privire la limba (sau ce platformă) va fi folosită pentru dezvoltare;
Sistemul are cerințe pentru o interfață multilingvă (de exemplu, rusă / engleză)
Pentru ca sistemul să funcționeze, trebuie creată o subdiviziune separată sau angajați noi angajați;
Pentru ca sistemul să funcționeze, Clientul trebuie să sufere modificări ale metodelor de lucru și aceste modificări trebuie specificate și planificate;
Se presupune integrarea cu orice echipament și îi sunt impuse cerințe (de exemplu, certificare, compatibilitate etc.)
Sunt posibile și alte situații, totul depinde de obiectivele specifice ale proiectului.

Secțiunea 5. Compoziția și conținutul lucrărilor privind 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; vă recomand cu tărie să vă asumați responsabilitatea pentru procedura de predare a lucrării și verificarea sistemului . Pentru asta 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 recepție și transfer al lucrărilor nu este clar definită. De exemplu, o capcană comună: sistemul este realizat, este pe deplin funcț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 spune: „Din moment ce nu lucrăm încă sistem nou, așa că nu putem fi siguri că funcționează.” Așa că învață să identifici corect etapele de lucru, modalități de a verifica rezultatele pentru aceste etape. Mai mult, astfel de metode ar trebui să fie clare pentru Client inițial. Dacă sunt fixați la nivelul Termenilor de referință, atunci îi puteți contacta oricând, dacă este necesar, și aduceți lucrarea cu transferul.

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

Pot exista și alte reguli de introducere a informațiilor acceptate în 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 cerut separat, data separat etc. Pot exista multe astfel de condiții. Unele dintre ele pot fi percepute cu rezistență din partea personalului, așa că este mai bine să înregistrați toate astfel de cazuri la nivelul cerințelor pentru procedura de introducere a datelor Modificări care trebuie făcute în obiectul de automatizare

Crearea condițiilor de funcționare a obiectului de automatizare, în care este garantată conformitatea sistemului creat cu cerințele cuprinse în TZ.Orice modificări care pot fi necesare. De exemplu, compania nu are reteaua locala, 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 se face, 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 după anumite reguli.

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

Timpul și procedura pentru personal și formarea personalului Am vorbit deja despre acest lucru mai devreme. Poate că sistemul este dezvoltat pentru o nouă structură sau 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, așa că este necesar să se facă referire la acestea.

Ignorarea cerințelor de documentare de foarte multe ori duce la cele mai neașteptate consecințe asupra proiectelor. De exemplu, totul este făcut și totul funcționează. Utilizatorii știu și cum să lucreze. Nu am fost de acord și nici nu am vorbit despre documentație. Și brusc, când lucrarea este predată, unul dintre managerii de vârf ai Clientului, care nici măcar nu a participat la proiect, dar participă la acceptarea lucrării, vă întreabă: „Unde sunt manualele de utilizare?” Și începe să vă convingă că nu a fost necesar să negociați disponibilitatea manualelor de utilizare, acest „de la sine” se presupune că este implicit. Și asta e tot, nu vrea să-ți ia slujba. Pe cheltuiala cui vei elabora ghiduri? Multe echipe au căzut deja pe acest cârlig.

Secțiunea 9. Surse de dezvoltare

Recomandări conform GOST	Ce să faci în practică
Trebuie enumerate documentele și materialele informative (studiu de fezabilitate, rapoarte privind lucrările de cercetare finalizate, materiale informative pentru sisteme analogice interne, străine etc.), pe baza cărora a fost elaborat TK și care ar trebui să fie utilizate la crearea sistemului.	Sincer să fiu, acesta este mai aproape de versuri. Mai ales când vorbesc despre efect economicși alte lucruri care sunt practic imposibil de numărat obiectiv. Acestea. se poate 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, cerințele persoanelor cheie.

Și astfel, am luat în considerare toate secțiunile care pot fi incluse în Termenii de referință. „May” și nu „Obligat” tocmai pentru că orice document trebuie elaborat pentru a obține un rezultat. Prin urmare, dacă este evident pentru dvs. că o secțiune separată nu vă va aduce mai aproape de rezultat, atunci nu aveți nevoie de el și nu trebuie să pierdeți timpul cu el.

Dar fără principalul lucru: cerințe funcționale, nici o sarcină tehnică nu este completă. Vreau să observ că în practică, astfel de Termeni de referință sunt întâlniți și cum! Există cifre care vor putea dilua apa în toate secțiunile, descriu cerințele generale in termeni generali, iar documentul se dovedește a fi foarte greu și există multe cuvinte inteligente în el și chiar și Clientului îi poate plăcea (adică îl va aproba). Dar lucrul la el s-ar putea să nu funcționeze, de exemplu. există puține beneficii practice din aceasta. În cele mai multe cazuri, astfel de documente se nasc atunci când trebuie să obțineți o mulțime de bani special pentru Termenii de Referință și 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țe din motive de claritate, specificitate și testabilitate.

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

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

Tipul de cerință

Formulare greșită

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

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

Creat la 18.05.2018 11:24:34

Din dicționarul explicativ

Dezvoltarea este construirea, crearea, aprobarea - acordarea unui document forță legală (legală). În cea actuală, aceasta este completarea TK structurale și obținerea unei semnături de aprobare pe pagina de titlu. Și ștampila sigiliului afirmativ.

Termeni și definiții

Aprobare - Se pune în aplicare un certificat oficial al unui funcționar autorizat sau cel dezvoltat. Certificatul poate fi fixat pe documentul aprobat prin direct sau prin trimitere 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țe ale standardelor

Pe pagina de titlu sunt plasate clientul, dezvoltatorul și organizațiile de aprobare, care sunt aplicate cu sigiliul oficial. Dacă este necesar, pagina de titlu este întocmită pe mai multe pagini. Semnăturile dezvoltatorilor de specificații tehnice pentru UA și oficiali participarea la aprobarea și examinarea proiectului de TK la CNE sunt plasate pe ultima foaie. Forma paginii de titlu a TK la UA este dată în. Forma 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 efectuează elaborarea și, dacă este cazul, specificațiile tehnice pentru părți ale centralei nucleare [din clauza 7 din Anexă. 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 automatizat

Acest text a fost creat doar de dragul existenței unei legături permanente, pe care autorul însuși și voi toți l-ați putea trimite în siguranță viitorilor săi clienți, colegi, rude și cunoștințe sub forma unui răspuns standardizat la întrebarea: „Am nevoie de cunoștințele tale și, în general, ce este asta?”

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 strecura prostii sub definiția „Termenilor de referință” devine abia acum. mai puternic de-a lungul anilor.

Problemă

Faptul 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 dumneavoastră briefs, prototipuri, chestionare, descrieri și doar aplicațiile primite din zbor arată, cel putin, neprofesionista. Prin urmare, începem cu definiția ș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 tehnice ale acestuia, indicatorii de calitate și cerințele tehnice și economice, instrucțiunile de realizare a etapelor necesare realizării documentației (proiectare, tehnologică, software etc.) și alcătuirea acestuia, precum și specificații speciale. cerințe. Termenii de referință sunt un document legal - ca anexă este inclusă în contractul dintre client și antreprenor pentru realizarea munca de proiectareși stă la baza acesteia: determină ordinea și condițiile de lucru, inclusiv scopul, obiectivele, principiile, rezultatele așteptate și termenele limită. Adică, trebuie să existe criterii obiective prin care să fie posibil să se determine dacă o anumită lucrare a fost realizată sau nu. Toate modificările, completările și clarificările referitoare la formularea TK trebuie să fie de acord cu clientul și aprobate de acesta. Acest lucru este necesar și pentru că în cazul în care în procesul de rezolvare a problemei de proiectare se constată inexactități sau inexactități ale datelor inițiale, devine necesar să se determine gradul de vinovăție al fiecăreia dintre părțile care participă la dezvoltare, distribuția pierderile suferite în acest sens. Termeni de referință ca termen în domeniu tehnologia Informatiei Este legal document semnificativ care conțin 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 într-un limbaj ușor de înțeles

1) Atribuire tehnică - stabilește o sarcină. Aceasta înseamnă că ar trebui să treacă înaintea proiectului de prototip, schiță, testare, proiectare, deoarece orice hartă mentală, diagramă de flux de date, arhitectură este deja îndeplinirea 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 declarație a problemei și nu o căutare frenetică a schițelor cu o duzină de opțiuni pentru rezolvarea acesteia.

2) De fapt, unul nou decurge logic din primul punct - textul TK-ului însuși trebuie să înceapă cu capitolul „Scopul și obiectivele”, care formulează clar ce obiective de afaceri sunt urmărite prin toată această încercare următoare de a crește entropia în lume. . O sarcină fără scop care nu rezolvă nicio problemă, nu realizează nimic și se face „din plictiseală” - nu este considerată oficial sarcină tehnică, iar din acel moment este în statutul de „coală obișnuită de hârtie”.

3) Cum înțelegeți dacă conceptul de design propus sau un prototip interactiv, sau chiar un site web gata de utilizare, rezolvă problema de afaceri de mai sus? Nu este nimic de făcut, va trebui să revenim din nou la definiția: „determină... rezultatele așteptate și termenul de implementare. Adică, trebuie să existe criterii obiective prin care să fie posibil să se determine dacă o anumită lucrare a fost finalizată sau nu.” Adică, nu poate exista TK fără indicatori clari măsurabili în ruble, secunde, tone-kilometri sau grade Celsius. O cutie scurtă, sau un prototip, sau orice altă bucată de hârtie absurdă, dar nu o Misiune Tehnică.

De aici concluzionăm că în acest TK trebuie neapărat să existe un capitol „Procedura de acceptare și evaluare”, când acești indicatori sunt luați, măsurați, iar părțile fie dau mâna, fie trimit proiectul spre reluare.

4) Misiunea tehnică trebuie în mod necesar să fie de acord cu plan general de afaceri client, cu strategia sa de dezvoltare a afacerii și analiza segmentului de piață. Toate acestea vă vor permite să stabiliți obiectivele potrivite, să obțineți metrici precise, conform cărora puteți conduce apoi în mod adecvat acceptarea produsului informativ finit. Lipsa unui plan de afaceri de către client garantează automat executarea neprofesională a Termenilor de referință.

Studioul externalizat cunoaște obiectivele de afaceri și performanța măsurabilă a afacerii mai bine decât proprietarul? Evident că nu, ceea ce înseamnă că TK-ul corect ar trebui scris de către reprezentanții Clientului, și nu de către angajații Antreprenorului. Este absurd când un interpret își stabilește o sarcină, apoi vine cu modalități de a o evalua și, în final, își acordă o notă finală pentru munca depusă. În mod ideal, o astfel de „inițiativă” nu ar trebui să fie, deși în practică asta este exact ceea ce se întâmplă peste tot, în urma căruia Misiunea tehnică nu prevede ajutorul de care ai nevoie proiect, fiind de prea multe ori un document fictiv. Nu faceți așa.

5) Fiecare modificare la TK finit ar trebui să coste bani. Este imposibil să editați „Constituția proiectului dumneavoastră” gratuit și la nesfârșit doar pentru că una dintre părți s-a răzgândit, nu a dormit suficient, a decis brusc să economisească și așa mai departe. Prețul fiecărei modificări a TK ar trebui, de asemenea, precizat în mod clar în prealabil în capitolul relevant.

Apropo, în teorie, fiecare modificare de design sau modificare a listei de pagini sau funcții ar trebui să aibă un preț clar, care se plătește în avans, înainte de începerea acestei modificări. Personal, îmi propun să estimez orice revizuire a TK-ului aprobat la 30% din bugetul total al proiectului, dar puteți face altfel.

Merită menționat că este pur și simplu necesar să se indice în prealabil calendarul și bugetul total pentru dezvoltare, precum și o listă a tuturor resurselor și restricțiilor 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 foaie de hârtie sunt „glonțul de argint” capabil să scoată până și cel mai eșuat proiect.

Întrebări de control

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

1) Deci, poate exista un GOST oficial pentru scrierea sarcinilor tehnice? - Da, chiar și câteva.

2) Ce, Misiunea tehnică nu include o descriere a paginilor solicitate, numărul de butoane, bibliotecile utilizate, ghiduri 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 mai sus de evaluare a rezultatului obținut. Postați cel puțin tot conținutul viitor, cel puțin o descriere a personajelor tipice - dar nu în locul unei enunțuri clare a problemei, ci după aceasta.

3) Deci poate nu am nevoie de el? - 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ă vrei să vezi unde mergi, să iei decizii în mod conștient și să evaluezi în mod independent rezultatele obținute, atunci nu te poți lipsi de TK.

4) Deci tu și Wikipedia scrieți că TK-ul este creat de client. Dar nu știu cum / nu am timp / pur și simplu nu vreau să o fac eu. Cum să fii? - Să predea dezvoltarea specificației tehnice unei terțe părți care este destul de familiarizată cu afacerea dvs., sarcinile acesteia, public țintăși nevoi, și în același timp foarte conștient de toate etapele dezvoltării web. Acest terț va deveni un fel de „notar web”, adică garantul că antreprenorul nu va subestima indicatorii de care aveți nevoie sau nu va întârzia, iar clientul va stabili metrici realizabile și la acceptarea finală nu va evalua subiectiv. produsul creat, modificând cerințele înregistrate anterior.

5) Și dacă TK este un document legal, atunci pot da în judecată externalizatorul, nu-l plătesc, îl pot obliga să refacă totul pentru a zecea oară? - Dacă documentul este întocmit corect, sunt indicate scopurile ș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 desigur că puteți. Dar cu brief-ul obișnuit, prototipuri, aspect artistic-creativ, Ofertă sigură pe FL - nu mai.

6) Mi se spune că munca se va desfășura conform unui fel de Scrum, sau Ajail; ceea ce înseamnă că nu mai am nevoie de TK arhaic. Asta este adevărat? - Judecă singur: îți spun un cuvânt de neînțeles, evident ceva deghizator, iar acum, pe baza unui termen necunoscut, îți oferă să renunți la un document competent din punct de vedere juridic, plin de obiective și metrici. Agile în sine nu poate stabili niciun obiectiv precum „să realizeze cel puțin 10.000 de vizite până la sfârșitul anului”, sau „să ajungă la peste 25 de comenzi de pe site într-o lună”, nu poate stabili, este doar o modalitate de a ține întâlniri și reorganizarea angajaţilor neglijenţi. Gândiți-vă de câteva ori: „Nu vă este stimulat?” De fapt, cunoștințele profesionale nu pot dăuna niciunui Scrum nou, dar ajutorul este o necesitate.

Sarcina tehnică (denumit în continuare TK) - acest document servește drept fundație, 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 conformitatea cu standardele GOST și multe altele pot fi specificate în TK.

TK este document legal, care face parte din contractul (de obicei ca anexă) dintre client și antreprenor pentru executarea anumitor lucrări, producție sau servicii. În termenii de referință, sarcinile, scopurile, principiile, termenii, procedura și rezultatele așteptate ale tuturor lucrărilor sunt descrise cel mai pe deplin. Ca urmare, TK este cel care servește drept document în funcție de care se evaluează conformitatea lucrărilor efectuate pentru fiecare articol.

Modificările la oricare dintre punctele sarcinii tehnice trebuie să treacă prin procesul de înțelegere cu clientul și să fie aprobate de acesta. Acest lucru este dictat de faptul că, dacă în timpul lucrării apar inexactități, abateri sau erori în datele inițiale, una sau alta parte poate suferi pierderi, iar TK este cel care va reglementa gradul de vinovăție al uneia sau alteia părți. .

Inițial, TK este pregătit și furnizat de către client, cu toate acestea, clientul transferă adesea această sarcină către antreprenor, oferind doar un număr de conditii tehniceși dorințe într-o limbă de consum, departe de limbajul profesional și terminologia subiectului. Este necesar să se evite ambiguitatea și interpretarea ambiguă a clauzelor TOR, acest lucru poate genera incertitudine în rândul tuturor participanților și nu va permite o evaluare obiectivă a calității muncii efectuate. De asemenea, antreprenorul trebuie să fie conștient de faptul că este posibil ca clientul să nu aibă o înțelegere și cunoaștere deplină a cerințelor speciale, ceea ce nu scutește în niciun fel antreprenorul de responsabilitatea și obligația de a respecta toate normele și cerințele autorităților de supraveghere, indiferent dacă acestea au fost în TOR sau nu. Astfel, atât clientul, cât și contractantul sunt responsabili de stabilirea sarcinilor în TOR și de calitatea rezultatului.

În orice caz, cu cât vor fi elaborate și convenite TOR mai minuțios și mai precis, cu atât mai puține grade de libertate și lacune vor rămâne pentru ca antreprenorul să-și îndeplinească munca cu rea-credință. În funcție de cât de competent vor fi întocmiți termenii de referință, va depinde calitatea și rapiditatea muncii, această declarație funcționează și în sens invers.

O specificație tehnică bine scrisă crește șansele de finalizare cu succes a unui viitor proiect cu 50%, iar timpul investit în elaborarea unei specificații tehnice este una dintre cele mai bune investiții pe care le poate face un client în perioada proiectului. Prin urmare, întocmirea specificației 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 specificației tehnice poate fi foarte costisitoare după încheierea contractului, iar în unele cazuri chiar pune încheierea 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 și-ar dori exact să obțină la ieșire, bazându-se pe resursele și capacitățile sale actuale;
Efectuează coordonarea internă a solicitărilor între diviziile structurale;
Monitorizează conformitatea lucrărilor efectuate de către antreprenor.

Pentru antreprenor:

Înțelegeți esența și detaliile sarcinii;
Faceți planuri pentru execuția lucrărilor;
Excludeți lucrări suplimentare care nu sunt descrise în termenii de referință sau solicitați finanțare suplimentară pentru aceasta.

Pentru toate părțile:

Înțelegeți esența și aspectul produsului sau serviciului final;
Verificați lucrările efectuate, efectuați testele de acceptare;
Minimizați numărul de erori și inexactități în procesul de schimbare.

Ar putea fi util să citiți: