Documentatie tehnica. Documentatie tehnica Efectuarea probelor de receptie

Adnotare: O continuare logică a prelegerii anterioare. Problema aplicării practice a GOST R ISO/IEC 12207 în organizații și proiecte este discutată în detaliu. În acest sens, sunt studiate standardele GOST R ISO/IEC 15271 și GOST R ISO/IEC 16326.

Din prelegerea anterioară ar trebui să fie evident că implementarea GOST R ISO/IEC 12207 este o sarcină foarte dificilă. În primul rând, nu este clar ce înseamnă „implementarea GOST R ISO/IEC 12207”? Poate fi considerat implementat dacă unele dintre procesele organizației coincid cu procesele standardului, iar altele nu? Un standard poate fi considerat implementat dacă unele proiecte sunt realizate în conformitate cu acesta, iar altele nu? Această listă de întrebări poate continua.

Nu este o coincidență că, în urma GOST R ISO/IEC 12207, standardul GOST R ISO/IEC 15271-02 (GOST 15271, 2002) a fost dezvoltat special dedicat sarcinii implementării sale, care se numește „Orientări pentru aplicarea GOST”. R ISO/IEC 12207”. Vom trece acum să o luăm în considerare.

Standard GOST R ISO/IEC 15271

Semnificația standardului este dezvăluită în secțiunea introductivă.

„1.2. Utilizatorii standardului.

Acest standard poate fi utilizat de subiecții (persoane fizice, organizații) care doresc să aplice GOST R ISO/IEC 12207 la implementarea contractelor, indiferent de volumul sau complexitatea proiectului, de către o organizație specifică pentru lucrări de auto-monitorizare sau îmbunătățire. procesele ciclului de viață instrumente software.

Acest standard specifică modul în care GOST R ISO/IEC 12207 poate fi utilizat în legătură cu diferite tipuri de software și ce procese sunt adecvate pentru fiecare caz.

Acest standard completează GOST R ISO/IEC 12207, care nu este doar un document normativ, ci și un standard pentru gestionarea unui proiect real. (De exemplu, ultimul caz apare atunci când GOST R ISO/IEC 12207 este un model pentru realizarea unei părți a activității procesului de îmbunătățire). Acest standard ar trebui citit ca un întreg, dar secțiunile specifice pot fi utilizate în cazuri individuale.”

Standardul GOST R ISO/IEC 15271 este format din 8 secțiuni și 4 anexe. Secțiunile de conținut sunt numite după cum urmează (numerotarea luată din text):

• 4. Concepte de bază ale dezvoltării GOST R ISO/IEC 12207.
• 5. Implementarea GOST R ISO/IEC 12207.
• 6. Aplicare în proiecte.
• 7. Aplicare în organizații.
• 8. Aplicare modele de ciclu de viață sisteme.

Secțiunea 4 este scrisă în stilul comentariilor și clarificărilor la textul GOST R ISO/IEC 12207. Cele mai importante clarificări se referă la interacțiunea GOST R ISO/IEC 12207 cu standardele corporative ale organizației, distincția dintre conceptele de „ software” și „sistem” și distincțiile rezultate între procese legate de software și sisteme. Conceptul este descris în detaliu managementul calitatii, implementat în GOST R ISO/IEC 12207. În general, secțiunea oferă impresia unei scurte prezentari conceptuale a GOST R ISO/IEC 12207, care amintește de un manual.

Secțiunea 5 prezintă o abordare generală a implementării, numită strategie de implementare GOST R ISO/IEC 12207. O strategie, conform standardului, este „o metodă tipică de implementare care ar trebui urmată atunci când se efectuează modificări în activitățile sau proiectul unei organizații”. Strategia este implementată ca un proiect constând din pași obligatorii, descriși informal și fără nicio legătură cu procesele organizației. Acești pași sunt după cum urmează:

• a) elaborarea unui plan de implementare;
• b) aplicarea practică a GOST R ISO/IEC 12207;
• c) acordarea de sprijin proiect pilot(s);
• d) formalizarea modului de implementare;
• e) aprobarea modului de implementare.

Dezvoltarea unui plan de implementare include determinarea domeniului de aplicare a GOST R ISO/IEC 12207. Domeniul de aplicare poate fi, de exemplu, un grup de departamente sau proiecte ale unei organizații. De asemenea, puteți defini domeniul de aplicare ca un set de procese cheie pentru organizație, care vor fi înlocuite cu procese din GOST R ISO/IEC 12207. Planul de implementare în sine determină componența proiectelor realizate în timpul implementării (poate exista mai multe dintre ele). Este de la sine înțeles că la elaborarea unui plan de implementare se determină resursele necesare: financiare, umane, tehnice etc.

În aplicarea practică, așa cum era de așteptat, se propune utilizarea procesului de adaptare descris în GOST R ISO/IEC 12207 însuși.

Strategia în sine nu ridică întrebări - o astfel de secvență de pași poate fi destul de eficientă în condiții specifice, dar merită remarcat faptul că abordarea oficială a proiectului pentru implementarea GOST R ISO/IEC 12207 se bazează pe o înțelegere simplificată a realității. situaţie. Ținând cont de faptul că procesele unei organizații (precum și structura organizatorică a acesteia) sunt în continuă schimbare, consider că ar fi mai corect din punct de vedere metodologic să considerăm implementarea unui standard ca un proces continuu, mai degrabă decât ca un proiect limitat în timp. Acest proces monitorizează modificările aduse proceselor organizației și inițiază proiecte individuale, de exemplu:

• proiecte pentru aplicarea GOST R ISO/IEC 12207;
• un proiect de instruire a tuturor noilor angajați în procesele GOST R ISO/IEC 12207;
• un proiect pentru introducerea de modificări în procesele implementate în legătură cu schimbările în structura organizatorică a organizației; etc.

Abordarea implementării GOST R ISO/IEC 12207 ca proces, mai ales dacă se intenționează să înceapă cu aplicarea sa în proiecte sau departamente individuale ale organizației, va permite concentrarea responsabilității pentru rezultatul general în mâinile proprietarului procesului. , va face posibilă stabilirea monitorizării generale a rezultatelor etc. Evident, implementarea ar trebui să fie urmată de sprijinirea proceselor implementate, care este de asemenea organizată în mod firesc ca proces.

Mai multe detalii despre utilizarea GOST R ISO/IEC 12207 în proiecte sunt descrise în secțiunea 6 „Aplicarea în proiecte”. Standardul propune clasificarea proiectelor și în acest scop introduce un nou concept - „ modelul ciclului de viață sisteme" (o listă de modele tipice este dată în Anexa C). Ce este un model nu este definit formal. Mai târziu, Secțiunea 8 afirmă că „general modelul ciclului de viață sistemele sunt împărțite în etape (etape) cu adaptarea ulterioară a fiecăreia dintre ele la modele de ciclu de viață sistem specific" (următoarea este o listă de etape). În total, sunt luate în considerare trei astfel de modele: în cascadă, incrementală, evolutivă. Avantajele și dezavantajele acestora sunt analizate, iar apoi procesele GOST R ISO/IEC 12207 sunt „suprapuse” Ca urmare, aceste procese primesc proprietăți suplimentare, de exemplu, repetarea repetată în ciclul de viață sau suprapunerea în timp cu alte procese. În plus, secțiunea conține o mulțime de recomandări de diferite grade de utilitate aspecte ale proiectelor. Iată un exemplu tipic.

„6.1.3. Caracteristicile sistemului

Subsistemele și elementele de configurare a sistemului trebuie definite la nivelul adecvat de detaliu. Este necesar să se determine caracteristicile sistemului, în special cele legate de software. Atunci când se determină aceste caracteristici, este necesar să se noteze care dintre ele sunt critice în timpul funcționării sistemului.

O listă orientativă a caracteristicilor la nivel de sistem (legate de software și care trebuie luate în considerare) include:

• interfețe inter-sistem și intra-sistem;
• interfețe cu utilizatorul;
• impactul erorilor software asupra protecției și securitatea sistemului;
• evaluarea puterii de calcul și a constrângerilor de timp;
• disponibilitatea programelor implementate prin mijloace tehnice;
• Disponibilitatea calculatoarelor adecvate.

Dacă un sistem include multe subsisteme sau elemente de configurare, acestea trebuie să fie acoperite complet de munca la nivel de sistem din procesul de dezvoltare. Trebuie luate în considerare toate cerințele pentru interfețe și asamblarea (integrarea) sistemelor. Pentru un sistem mic, o astfel de secvență strictă de acțiuni poate să nu fie necesară.”

Formularea aproximativă și vagă din pasajul de mai sus este caracteristică întregului standard în ansamblu.

Partea centrală a secțiunii foarte scurte 7 „Aplicarea în organizații” este următorul text.

„7.2. Posibilitati de aplicare

Motivele pentru care GOST R ISO/IEC 12207 este implementat în organizații pot fi următoarele:

• verificarea perfecţiunii unei metode existente. Acesta este de obicei cazul când metoda a fost dezvoltată de organizația însăși sau aceasta a selectat și a modificat o metodă existentă;
• aplicarea practică a acestei metode pentru a preveni riscul asociat cu intrarea în noi sectoare de piață cu cerințe mai stricte asociate cu riscul potențial;
• dezvoltarea unei noi metode, de exemplu pentru a satisface nevoile unei noi organizații. Organizațiile create printr-o fuziune sau o colaborare comercială pot fi acoperite. Acest lucru poate fi necesar pentru a sprijini unele modele de proces pentru furnizarea de lucrări specifice;
• Gestionarea implementării noii tehnologii, cum ar fi automatizarea proceselor manuale sau schimbarea metodelor utilizate pentru implementarea unui produs software. GOST R ISO/IEC 12207 stabilește criterii care pot fi utilizate pentru a monitoriza excelența metodei relevante înainte sau după o schimbare a tehnologiei;
• evaluarea capacităților interne ale părții în ceea ce privește îndeplinirea criteriilor contractului, de exemplu, ca parte care participă la procesul competitiv (de licitație);
• identificarea reperelor care pot duce la dezvoltarea unor programe mai avansate, cum ar fi auditarea în conformitate cu GOST R ISO/IEC 12207 și utilizarea procesului de îmbunătățire în sine.”

Chiar și în absența completă a obiecțiilor de fond, este încă imposibil să se considere acest text ca standard. Mai presus de toate, seamănă cu un manual de instruire și probabil va fi solicitat ca atare, dar un astfel de text nu poate fi folosit ca ghid de acțiune atunci când se implementează GOST R ISO/IEC 12207 într-o organizație.

În cele din urmă, secțiunea 8 „Aplicație modele de ciclu de viață sisteme „conține definiții destul de vagi” modele de ciclu de viață sisteme" și " modele de ciclu de viață software" și încearcă să stabilească o corespondență între ele. Deoarece nu există definiții precise, este imposibil să se judece rezultatele.

În general, standardul GOST R ISO/IEC 15271 dă impresia de a fi un document pur auxiliar în raport cu GOST R ISO/IEC 12207, suferind de aproximație și abundență de locuri comune. Este nepotrivit pentru managerii practici - există prea mult raționament abstract și prea puțină specificitate. Pentru studenții și specialiștii care studiază procesele de management IT, îi lipsește o viziune amplă a subiectului (la urma urmei, este limitat de GOST R ISO/IEC 12207) și este supraîncărcat cu detalii tehnice inutile. Cu toate acestea, familiarizarea cu GOST R ISO/IEC 15271 este utilă, deoarece arată direcția de gândire a specialiștilor în domeniul managementului IT și demonstrează unde și cum se dezvoltă standardele moderne. L-aș privi ca pe un document de lucru interimar, deși sub forma unui standard, dar destinat mai mult pentru discuții în rândul unui public interesat de specialiști în managementul IT.

Standard GOST R ISO/IEC 16326

O altă încercare de a oficializa procesul de aplicare a GOST R ISO/IEC 12207 a fost făcută în standardul GOST R ISO/IEC 16326 „Linii directoare pentru utilizarea GOST R ISO/IEC 12207 în managementul proiectelor” (GOST 16326, 2002). Demonstrează o încercare de unire procesele ciclului de viață din GOST R ISO/IEC 12207 cu procese de management de proiect din populara carte de referință metodologică PMBOK 1 PMBOK - Corpul de cunoștințe privind managementul proiectelor(PMBOK, 2009) și standardul ISO 10006 (versiunea rusă a standardului este conținută în (GOST 10006, 2005)). Acest lucru este prezentat schematic în Fig.

4.1 dat în standard.

Orez. 4.1.

Gama de utilizatori ai standardului este definită destul de precis în secțiunea 1.1.

Acest standard este destinat entităților care utilizează sau intenționează să utilizeze GOST R ISO/IEC 12207 în proiecte software, indiferent de domeniul lor, produsele create, metodologia, volumul sau complexitatea acestora. Standardul este destinat în primul rând administratorilor de proiect responsabili de conformitatea proceselor de management cu GOST R ISO/IEC 12207:

• administratori responsabili de organizare și îmbunătățire continuă procesele ciclului de viață software conform GOST R ISO/IEC 12207;
• administratorii responsabili de aplicație procesele ciclului de viață software conform GOST R ISO/IEC/12207 la nivel de proiectare;
• organizații sau persoane care sunt subcontractanți în implementarea SCP ( Management de proiect software. - AB).

Considerațiile pentru indivizi includ:

• implicat în proiecte software, dar nu AP ( Administratorii de proiect. - AB);
• care sunt administratori ai proiectelor non-software, dar asociate cu software-ul AP”.

Textul principal relativ scurt (secțiunea 6 „Ghid” ocupă doar 9 pagini dintr-un total de 35) este un comentariu secvenţial asupra procesului 7.1 „Management” din GOST R ISO/IEC 12207 din punct de vedere PMBOK. Stilul de comentariu este informal, discuțiile sunt în mare parte de natură consultativă. Comentariul nu depășește bunul simț obișnuit și nu conține nimic nou. În general, aceasta este o lectură utilă pentru managerii de proiect (în terminologia traducătorilor, „administratori”), dar nimic mai mult.

Anexa A este un tabel mare care demonstrează conexiunile dintre principalele procese ale GOST R ISO/IEC 12207 și activitățile procesului de „Management” numit din acestea. Toate aceste legături sunt conținute în corpul standardului GOST R ISO/IEC 12207; combinarea lor într-un singur tabel nu adaugă nicio informație nouă.

Anexa B este exact același tabel care leagă zonele de proces și procesele individuale din PMBOK cu activitățile procesului de „Management” din GOST R ISO/IEC 12207.

Un tabel similar, în care sunt folosite grupuri de procese în sensul PMBOK în loc de zone, este dat în Anexa C. Anexele B și C rezumă de fapt tot ceea ce s-a spus în secțiunea 6 a standardului. De ce a fost necesar să se prezinte acest lucru sub formă de tabele nu este clar. Aceste tabele nu oferă informații suplimentare, demonstrând doar faptul că există conexiuni între PMBOK și GOST R ISO/IEC 12207. Totuși, statutul ambelor anexe este „de referință”, așa că este posibil să nu fi avut nicio valoare independentă.

Un alt tabel rezumativ este prezentat în Anexa D. Acesta arată relațiile dintre trei surse: GOST R ISO/IEC 12207, PMBOK și standardul ISO 10006 Voi observa imediat că acesta din urmă a fost tradus în limba rusă abia în 2005; în consecință, terminologia utilizată în anexa D la standardul GOST R ISO/IEC 16326 2002 diferă de cea ulterioară. Ca și în cazurile anterioare, sensul prezentării acestor relații în formă tabelară compactă este neclar. În plus, volumul total al anexelor A-D depășește de mai mult de două ori volumul secțiunii principale 6 „Manual”.

În opinia mea, GOST R ISO/IEC 16326-2002 nu diferă ca formă și scop de GOST R ISO/IEC 15271-2002. Ambii suferă de un exces de raționament corect „în general” și bazat doar pe bun simț. Aceste argumente sunt evidente pentru oricine are experiență practică în managementul proiectelor și nu par rezonabile celor care nu au o astfel de experiență. Spre deosebire de GOST R ISO/IEC 15271-2002, standardul GOST R ISO/IEC 16326-2002 este mai formal, dar sensul practic al formalismului propus nu este clar.

Din punct de vedere al aplicării practice în proiectarea proceselor de afaceri legate de IT, ambele standarde sunt în mare măsură inutile. Pe de altă parte, aceștia pot fi solicitați atunci când implementează proiecte complexe care includ, împreună cu cercetarea practicilor de management IT, analiza managementului de proiect și managementul calitatii.

Pe lângă cele discutate mai sus, GOST R ISO/IEC 12207 a dat naștere unui număr de standarde care le detaliază pe cele conținute în acesta. procesele ciclului de viață. Acestea includ, de exemplu, GOST R ISO/IEC 15910-2002 „Procesul de creare a documentației utilizator pentru software” (GOST 15910, 2002) și GOST R ISO/IEC 14764-2002 „Întreținerea software-ului” (GOST 14764, 2002) . Unele standarde ISO similare nu au fost încă traduse în rusă; Este probabil ca în viitor să crească numărul de standarde GOST R ISO în limba rusă direct legate de GOST R ISO/IEC 12207.

Linia de referință conform GOST R ISO/IEC 12207-2010

sau, care au fost revizuite oficial și care ulterior servesc drept bază pentru dezvoltarea ulterioară și care pot fi modificate numai prin modificări oficiale și controlate [din clauza 4.6 din GOST R ISO/IEC 12207-2010]

Validare conform GOST R ISO/IEC 12207-2010

Confirmarea (pe baza prezentării unor dovezi obiective) că scopul sau aplicarea preconizată a fost realizată. Notă - Validarea în context este un set de acțiuni care garantează și oferă încredere că este capabilă să își realizeze scopul, actual și viitor [din clauza 4.54 din GOST R ISO/IEC 12207-2010]

Verificare conform GOST R ISO/IEC 12207-2010

Confirmarea (pe baza furnizării de dovezi obiective) că cerințele specificate au fost pe deplin îndeplinite. NOTĂ Verificarea în context este un set de acțiuni care compară un rezultat al ciclului de viață cu caracteristicile necesare pentru acel rezultat. Rezultatele ciclului de viață pot fi (dar nu se limitează la) cerințe specificate, descriere și direct [din clauza 4.55 din GOST R ISO/IEC 12207-2010]

Asigurarea calității conform GOST R ISO/IEC 12207-2010

Toate activitățile planificate și sistematice efectuate în cadrul și demonstrate într-o manieră adecvată pentru a oferi o încredere adecvată că clientul este pe deplin mulțumit.

1. Există garanții de calitate atât interne, cât și externe:
   1. asigurarea internă a calității: în limite, asigurarea calității oferă încredere;
   2. Asigurarea externă a calității: În situații contractuale, asigurarea calității oferă încredere sau altora.
2. Unele activități de asigurare și asigurare a calității sunt interdependente.
3. Cu excepția cazului în care cerințele de calitate satisfac pe deplin nevoile, asigurarea calității nu poate oferi asigurarea necesară.

[din clauza 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Rezumatul proceselor ciclului de viață

Există două diviziuni importante de proces în acest standard. Secțiunea 6 oferă contextul sistemului pentru operarea unui produs sau serviciu software autonom sau a unui sistem software. Secțiunea 7 conține procese software specifice pentru utilizare în implementarea unui produs sau serviciu software care este un element al unui sistem mai mare.

Pentru a ajuta la utilizarea simultană a acestui standard internațional, proceselor corespunzătoare din Clauza 6 li se acordă aceleași denumiri de subclauză.

În general, setul de procese prezentat în acest standard este adaptat software-ului sau intrărilor la rezultatele proceselor prevăzute. Multe procese sunt similare cu implementările de procese specifice software-ului, dar păstrează diferențe importante bazate pe obiective, rezultate și audiențe. Utilizatorii atât ai acestui standard, cât și ai acestui standard ar trebui să fie siguri că revizuiesc explicațiile și notele în fiecare astfel de proces specific.

Procesele de acord definesc activitățile necesare pentru a dezvolta acorduri între două organizații. Dacă este implementat un proces de achiziție, acesta oferă mijloacele de a desfășura afaceri cu furnizorul produselor furnizate pentru utilizare în sistemul de operare, serviciile de asistență ale sistemului sau elementele de sistem dezvoltate ca parte a proiectului. Dacă este implementat un proces de livrare, acesta oferă mijloacele pentru a realiza un proiect în care rezultatul este un produs sau serviciu livrat părții care achiziționează.

Astfel, procesele de acord prezentate în acest standard vizează procesele de acord software din .

Procesele organizaționale de asistență pentru proiecte gestionează capacitatea organizațiilor de a achiziționa și furniza produse sau servicii prin inițierea, suportul și managementul proiectelor. Aceste procese oferă resursele și infrastructura necesare pentru a sprijini proiectele și pentru a asigura îndeplinirea obiectivelor organizaționale și a acordurilor stabilite. Ele nu pretind a fi un set complet de procese de afaceri care implementează managementul activităților de afaceri ale unei organizații.

Procesele de suport organizațional al proiectului includ:

a) procesul de management al modelului ciclului de viață;

B) procesul de management al infrastructurii;

c) procesul de management al portofoliului de proiecte;

d) procesul de management al resurselor umane;

e) procesul de management al calitatii.

În general, procesele de suport organizațional al proiectului prevăzute de acest standard sunt procese axate pe software din setul corespunzător de procese din .

În acest standard, proiectul este ales ca bază pentru descrierea proceselor legate de planificare, evaluare și control. Principiile asociate acestor procese pot fi aplicate în orice domeniu al managementului organizațional.

Există două categorii de procese de proiect. Procesele de management de proiect sunt utilizate pentru a planifica, executa, evalua și gestiona progresul unui proiect. Procesele de sprijinire a proiectelor asigură îndeplinirea obiectivelor de management specializat. Ambele categorii de procese ale proiectului sunt descrise mai jos.

Procesele de management de proiect sunt utilizate pentru a crea și dezvolta planuri de proiect, pentru a evalua progresul real și progresul față de planuri și pentru a gestiona progresul proiectului până la finalizare. Procesele individuale de management de proiect pot fi invocate în orice moment al ciclului de viață și la orice nivel al ierarhiei proiectului ca răspuns la planurile de proiect sau la apariția unor evenimente neprevăzute. Procesele de management de proiect sunt aplicate la un nivel de rigoare și formalizare în funcție de riscul și complexitatea proiectului:

a) procesul de planificare a proiectului;

b) procesul de management și evaluare a proiectului.

Procesele de sprijinire a proiectelor formează un set specific de sarcini care vizează atingerea unor obiective specifice de management. Toate aceste procese sunt evidente la implementarea managementului oricărei activități inițiate, situată descendentă din organizația în ansamblu, până la un proces separat de ciclu de viață și sarcinile acestuia:

a) procesul de management al deciziei;

b) procesul de management al riscului;

c) procesul de management al configurației;

d) procesul de management al informaţiei;

e) procesul de măsurare.

În general, procesele de susținere a proiectelor prezentate în acest standard sunt identice cu procesele de susținere a proiectelor prezentate în , cu excepția unor diferențe în forma de prezentare a acestora. În unele cazuri, procesele de asistență software pot avea relații cu procesele de suport de proiect.

Procesele tehnice sunt utilizate pentru a defini cerințele de sistem, pentru a transforma cerințele într-un produs util, pentru a permite copierea continuă a produsului (dacă este necesar), pentru a aplica produsul, pentru a furniza serviciile necesare, pentru a menține furnizarea acelor servicii și pentru a scoate produsul din circulație atunci când nu este utilizat în furnizarea serviciului.

Procesele tehnice definesc activitățile care permit implementarea funcțiilor organizaționale și de proiectare pentru a optimiza beneficiile și a reduce riscurile rezultate din deciziile și acțiunile tehnice. Aceste activități permit produselor și serviciilor să aibă caracteristicile de promptitudine și disponibilitate, rentabilitate, funcționalitate, fiabilitate, mentenanță, productivitate, adaptabilitate și alte caracteristici de calitate cerute de organizațiile care achiziționează și sprijină. De asemenea, permite produselor și serviciilor să îndeplinească așteptările sau cerințele legii civile, inclusiv factorii de sănătate, siguranță, securitate și mediu.

Procesele tehnice constau din următoarele procese:

a) determinarea cerințelor deținătorilor de drepturi (un caz special al procesului de determinare a cerințelor deținătorilor de drepturi menționat în);

b) analiza cerințelor sistemului (un caz special al procesului de analiză a cerințelor);

C) proiectarea arhitecturii sistemului (un caz special al procesului de proiectare a arhitecturii prezentat în);

D) procesul de implementare (un caz special al procesului de implementare a elementului de sistem, prezentat și dezvoltat în continuare în Secțiunea 7 a acestui standard ca proces de implementare a software-ului);

e) procesul de integrare a sistemului (un caz special al procesului de integrare prezentat în);

f) procesul de testare a calificării sistemului (un proces care contribuie la obținerea rezultatelor procesului de verificare prevăzut la );

G) procesul de instalare a software-ului (procesul care contribuie la obținerea rezultatelor procesului de transfer descris în);

H) procesul de suport pentru acceptarea software-ului (procesul care contribuie la atingerea rezultatelor procesului de transfer descris la );

i) procesul de funcționare a software-ului (un caz special al procesului de funcționare prezentat în);

j) procesul de întreținere a software-ului (un caz special al procesului de întreținere dat în );

k) procesul de retragere a software-ului din circulație (un caz special al procesului de retragere și radiere prezentat în).

În general, procesele tehnice prezentate în acest standard sunt cazuri speciale orientate spre software sau contribuții la rezultatele proceselor tehnice prezentate în . Cele mai multe dintre ele sunt similare cu procesele de implementare a software-ului, dar păstrează diferențe importante, de exemplu, analiza cerințelor de sistem și analiza cerințelor software pornesc din puncte de plecare diferite și au scopuri diferite.

Procesele de implementare software sunt folosite pentru a crea un element (component) de sistem specific realizat sub forma unui instrument software. Aceste procese transformă comportamentele, interfețele și constrângerile de implementare specificate în acțiuni care au ca rezultat un element de sistem care satisface cerințele derivate din cerințele sistemului.

Un proces special este procesul de implementare a software-ului, care exprimă o caracteristică specifică software a procesului de implementare prezentat în.

Procesul de implementare a software-ului include mai multe procese speciale de nivel inferior:

a) procesul de analiză a cerințelor software;

B) procesul de proiectare a arhitecturii software;

c) procesul detaliat de proiectare a software-ului;

d) procesul de proiectare software;

e) procesul de integrare software;

f) procesul de testare a calificării software-ului.

Procesele de suport software oferă un set specific de activități care vizează executarea unui proces software specializat. Orice proces de suport asista procesul de implementare a software-ului ca un intreg cu un scop distinct, contribuind la succesul si calitatea proiectului software. Există opt astfel de procese:

a) procesul de gestionare a documentației software;

b) procesul de management al configurației software;

c) procesul de asigurare a calității software-ului;

d) procesul de verificare software;

e) procesul de validare software;

f) proces de audit software;

g) proces de audit software;

H) procesul de rezolvare a problemelor în software.

Grupul de procese de reutilizare a software-ului constă din trei procese care sprijină capacitatea unei organizații de a reutiliza componentele software dincolo de granițele proiectului. Aceste procese sunt unice deoarece, prin natura lor, sunt utilizate în afara granițelor oricărui proiect specific.

Procesele de reutilizare a software-ului sunt:

a) procesul de proiectare a domeniului;

b) procesul de management al reutilizarii activelor;

C) procesul de gestionare a reutilizarii programului.

1) Vă permite să implementați orice model de ciclu de viață- acest lucru este posibil, pentru că Standardul oferă o modalitate de a defini ordinea de execuție a proceselor și sarcinilor, în care un proces poate apela un alt proces sau părți ale acestuia.

2) Oferă flexibilitate maximă– multe procese și sarcini sunt concepute astfel încât să poată fi adaptate în conformitate cu proiecte specifice IS. Adaptarea se reduce la eliminarea proceselor, activităților și sarcinilor care nu sunt aplicabile unui anumit proiect.

3) Standardul nu conține în mod fundamental o descriere a unor metode specifice de acțiune, în special, spații, soluții sau documentație, descrie doar arhitectura proceselor ciclului de viață al software-ului, dar nu specifică în detaliu modul de realizare sau implementare a sarcinilor incluse în procese.

4) Standardul conține foarte puține descrieri privind proiectarea bazei de date- acest lucru este justificat, pentru că diferite IS și diferite sisteme software nu pot utiliza numai tipuri specifice de baze de date, dar nici nu pot folosi bazele de date deloc.

5) Valoarea standardului este că acesta conţine seturi de sarcini, caracteristici de calitate, criterii de evaluare etc., oferind o acoperire cuprinzătoare a soluțiilor de proiectare.

6) Deși standardul nu prescrie utilizarea unui model specific de ciclu de viață sau a unei metode de dezvoltare, el stabilește că părțile din proiect sunt responsabile pentru următoarele:

selectarea unui model de ciclu de viață pentru proiectul în curs de dezvoltare;

adaptarea proceselor și sarcinilor standardului la modelul selectat;

selectarea și aplicarea metodelor de dezvoltare software;

Efectuarea de activități și sarcini adecvate unui proiect software dat.

GOST 34 standarde complexe.

A fost conceput ca un set cuprinzător de documente intersectoriale interconectate.

Obiecte de standardizare: sisteme automate de diferite tipuri și toate tipurile de componente ale acestora.

Standardele GOST prevăd etapele și fazele de lucru pentru a crea un sistem automatizat, dar nu prevăd în mod explicit procese end-to-end care au loc în timpul implementării ciclului de viață.

Potrivit GOST, dezvoltarea unui sistem automatizat este împărțită în următorii pași și etape:

Etapa 1 formarea cerinţelor pentru vorbitori:

Etapa a: inspecția instalației și justificarea necesității dezvoltării unui sistem automatizat;

Etapa b: formarea cerințelor clienților pentru un sistem automatizat;

Etapa c: elaborarea unui raport privind munca depusă și pregătirea unei cereri pentru elaborarea specificațiilor tehnice.

Etapa 2 dezvoltarea conceptului:

a: studiul obiectului;

b: efectuarea cercetărilor necesare;

c: dezvoltarea de opțiuni pentru conceptul CNE care să răspundă cerințelor clienților;

d: elaborarea unui raport asupra muncii depuse.

Etapa 3 elaborarea și aprobarea specificațiilor tehnice pentru realizarea centralelor nucleare.

Etapa 4 elaborarea unui proiect preliminar al CNE:

a: dezvoltarea de soluții preliminare de proiectare pentru întregul sistem în ansamblu și pentru componentele sale individuale;

b: elaborarea documentaţiei.

Etapa 5 dezvoltarea proiectului tehnic:

a: dezvoltarea soluțiilor de proiectare pentru întregul sistem și părțile sale;

b: elaborarea documentației pentru sistemul automatizat și subsistemele incluse în acesta;

c: elaborarea și executarea documentației pentru furnizarea produselor pentru finalizarea centralelor nucleare sau elaborarea și executarea cerințelor tehnice pentru dezvoltarea acestor produse.

Etapa 6 elaborarea documentatiei tehnice:

a: elaborarea documentației de lucru pentru partea de sistem;

b: dezvoltare sau adaptare software.

Etapa 7punerea în funcţiune a sistemului dezvoltat:

a: pregătirea obiectului de automatizare pentru implementarea sistemelor automatizate;

b: instruirea personalului;

c: dotarea boxelor cu software și hardware;

d: lucrari de instalare;

d: punerea în funcțiune;

e: teste preliminare;

g: operațiune de probă;

h: teste de acceptare.

Etapa 8 escorta:

a: efectuarea lucrărilor în conformitate cu obligațiile de garanție;

b: service post-garanție.