5.2.2 Rezumatul proceselor ciclului de viață

Există două diviziuni importante ale procesului în acest standard internațional. Clauza 6 oferă un context de sistem pentru lucrul cu un produs sau serviciu software autonom sau sistem software. Clauza 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 concomitentă a acestui standard internațional, procesele corespunzătoare din clauza 6 au aceleași denumiri de subsecțiuni.

În general, setul de procese prezentat în acest Standard Internațional este adaptat instrumentelor software sau intrărilor la rezultatele proceselor furnizate. Multe dintre 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 internațional, cât și ai acestui standard internațional trebuie să fie siguri că au în vedere 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ă un mijloc de a desfășura afaceri cu un furnizor de produse furnizate pentru utilizare într-un sistem funcțional, servicii de asistență pentru acel sistem sau elemente de sistem dezvoltate ca parte a unui proiect. Dacă este implementat un proces de livrare, acesta oferă mijloacele pentru a realiza un proiect în care rezultatul este un produs sau serviciu livrat achizitorului.

Astfel, procesele de acord prezentate în acest standard internațional sunt procese de acord orientate spre software de la .

Procesele de organizare a proiectului gestionează capacitatea organizațiilor de a achiziționa și furniza produse sau servicii prin inițierea, sprijinul și managementul proiectului. 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 organizației.

Procesele de suport organizațional al proiectului includ:

a) proces de management al modelului ciclu 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 management de proiect prevăzute în acest standard internațional sunt procese orientate spre software din setul corespunzător de procese din .

În acest standard internațional, 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 performanța reală și progresul față de obiective și pentru a gestiona progresul proiectului până la finalizare. Procese separate de management de proiect pot fi implicate în orice moment al ciclului de viață și la orice nivel al ierarhiei proiectului, în conformitate cu planurile de proiect sau cu 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 proiectelor.

Procesele de sprijinire a proiectelor formează un set specific de sarcini axate pe îndeplinirea unor obiective specifice de management. Toate aceste procese sunt evidente în managementul oricărei activități inițiate, extinzându-se de la organizație în ansamblu până la procesul individual ciclului de viață și obiectivele sale:

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;

f) procesul de măsurare.

În general, procesele de susținere a proiectelor prezentate în acest Standard internațional sunt identice cu procesele de sprijinire 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 asistență pentru proiecte.

Procesele tehnice sunt utilizate pentru a defini cerințele pentru sistem, pentru a transforma cerințele într-un produs utilizabil, 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 se retrage. produsul din circulatie daca nu este utilizat in prestarea serviciului.

Procesele tehnice definesc activitățile care permit implementarea funcțiilor organizaționale și de proiect pentru a optimiza beneficiile și a reduce riscurile rezultate din solutii tehniceși acțiune. Aceste activități permit produselor și serviciilor să aibă proprietăți precum promptitudinea și disponibilitatea, rentabilitatea, precum și funcționalitatea, fiabilitatea, mentenabilitatea, productivitatea, capacitatea de utilizare și alte calități cerute de organizațiile care achiziționează și sprijină. De asemenea, permite produselor și serviciilor să îndeplinească așteptările sau cerințele dreptului civil, inclusiv factorii de sănătate, siguranță, securitate și mediu.

Procesele tehnice constau din următoarele procese:

a) determinarea cerințelor titularilor de drepturi (un caz special al procesului de determinare a cerințelor titularilor de drepturi, dat la );

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 Clauza 7 a acestui Standard internațional ca proces de implementare a software-ului);

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

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

G) procesul de instalare a software-ului (un proces care contribuie la atingerea rezultatelor procesului de transfer în );

H) procesul de suport pentru acceptarea software-ului (un proces care contribuie la atingerea rezultatelor procesului de predare în );

i) proces de operare software (un caz special al procesului de operare dat î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 (un caz special al procesului de retragere și retragere în ).

În general, procesele tehnice prezentate în acest Standard Internațional sunt orientate spre software prin cazuri speciale 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 specific al sistemului (componenta) realizat sub forma unui instrument software. Aceste procese traduc comportamentele, interfețele și constrângerile de implementare specificate în acțiuni care au ca rezultat un element de sistem care satisface cerințele care decurg din cerințele sistemului.

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

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

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

B) procesul de proiectare a arhitecturii software;

c) procesul detaliat de proiectare a software-ului;

d) procesul de construire a software-ului;

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ă realizarea unei activități specializate proces software. Orice proces de suport asista procesul de implementare a software-ului ca un intreg cu un scop separat, 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) procesul de revizuire a software-ului;

g) proces de audit software;

H) procesul de rezolvare a problemelor 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 anume.

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 software-ului.

Standardul ISO/IEC 12207-95 definește strategia și ordinea generală în crearea și funcționarea software-ului, acoperă ciclul de viață al software-ului de la conceptualizarea ideilor până la finalizarea ciclului de viață (ciclul de viață).

Specificații standard

Standard nu prescrie un model specific de ciclu de viață sau metoda de dezvoltare software; Acesta definește că părțile implicate în utilizarea standardului sunt responsabile =

1. pentru alegerea unui model de ciclu de viață pentru un proiect software,
2. pentru adaptarea proceselor și sarcinilor standardului la acest model,
3. pentru alegerea și aplicarea metodelor de dezvoltare software,
4. pentru efectuarea de activități și sarcini adecvate proiectului software;

Standardul ISO/IEC 12207-95 este în egală măsură concentrată pe organizarea acțiunilor fiecăreia dintre cele două părți: furnizorul (dezvoltatorul) și cumpărătorul (utilizatorul); poate fi aplicat în mod egal atunci când ambele părți sunt din aceeași organizație.

Definiții standard

Sistem este combinația dintre unul sau mai multe procese, hardware, software, echipamente și oameni pentru a permite îndeplinirea anumitor nevoi sau scopuri.

Modelul ciclului de viață- o structură care conține procesele, activitățile și sarcinile care se desfășoară în timpul dezvoltării, exploatării și întreținerii unui produs software pe toată durata de viață a sistemului, de la definirea cerințelor până la finalizarea utilizării acestuia.

Cerințe de calificare- un set de criterii sau condiții ( cerințe de calificare ) care trebuie să fie satisfăcut pentru a califica un produs software ca îndeplinește specificațiile sale și fiind gata de utilizare în mediul țintă.

Standardul definește structura generală a ciclului de viață software sub forma unui model în 3 etape, constând din:

1. procese,
2. · Activități,
3. sarcini

Standardul nu definește valorile, care ar putea urmări progresul lucrărilor și eficacitatea acestora. Cele mai mari elemente sunt procesele ciclului de viață al software-ului. În total, au fost identificate 18 procese, care sunt combinate în 3 grupuri:

1. - procese de bază;
2. - sustinerea proceselor;
3. - procese organizatorice;
4. -procesul de adaptare.

Principalele procese ale ciclului de viață

1) Procesul de achiziție- sarcina sa este de a determina acțiunile întreprinderii-cumpărător, care achiziționează sistem automatizat, produs software sau serviciu software:

1. inițierea achiziției;
2. pregătirea unei cereri de propuneri;
3. intocmirea contractului;
4. analiza furnizorilor;
5. software de recepție.

2) Procesul de transfer(livrare) definește activitățile întreprinderii furnizor care furnizează cumpărătorului un sistem, produs software sau serviciu software.

3) Procesul de dezvoltare- sarcina sa este de a determina acțiunile întreprinderii dezvoltatoare care creează produsul software.
Include următoarele lucrări:

1. Implementarea procesului de dezvoltare;
2. analiza cerințelor sistemului;
3. Proiectarea (software și hardware) a sistemului în ansamblu;
4. analiza cerințelor software;
5. proiectarea arhitecturii software;
6. design detaliat;
7. codificare;
8. testare de depanare;
9. integrare software;
10. testarea de calificare a software-ului;
11. integrarea sistemului;
12. testarea de calificare a sistemului;
13. Implementarea (instalarea sau instalarea) de software.

4) Procesul de operare determină acțiunile întreprinderii operator, care asigură întreținerea sistemului în timpul funcționării acestuia în interesul utilizatorilor. Include lucrări precum:

1. consultarea utilizatorilor;
2. primind părere si etc.

5) Procesul de suport Software-ul determină acțiunile personalului de escortă, ceea ce asigură:

1. Instalarea și îndepărtarea unui produs software pe un sistem informatic;
2. analiza problemelor emergente;
3. · alterare;
4. examinarea și transferul de software modificat;
5. transfer de software de la o platformă la alta;
6. Scoaterea software-ului din serviciu.

Adnotare: Continuarea logică a prelegerii anterioare. Problema este analizată în detaliu aplicație practică GOST R ISO/IEC 12207 în organizații și proiecte. În acest sens, sunt studiate standardele GOST R ISO/IEC 15271 și GOST R ISO/IEC 16326.

Ar trebui să fie evident din prelegerea anterioară 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 dintre proiecte sunt realizate în conformitate cu acesta, iar altele nu? Această listă de întrebări poate continua.

Nu este o coincidență că, în conformitate cu GOST R ISO/IEC 12207, standardul GOST R ISO/IEC 15271-02 (GOST 15271, 2002), care se numește „Orientări pentru aplicarea GOST R ISO/IEC 12207”, a fost dezvoltat special. dedicat sarcinii implementării acestuia. Ne întoarcem acum la analiza sa.

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 către entitățile (persoane, organizații) care doresc să aplice GOST R ISO / IEC 12207 în implementarea contractelor, indiferent de volumul sau complexitatea proiectului, de către o organizație specifică pentru lucrări de autocontrol sau îmbunătățire. procesele ciclului de viață instrumente software.

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

Acest standard completează GOST R ISO / IEC 12207, care nu este numai document normativ, dar și un etalon pentru managementul de proiect real. (De exemplu, cel din urmă caz ​​apare atunci când GOST R ISO / IEC 12207 este un model pentru o parte a procesului de îmbunătățire). Acest standard internațional trebuie înțeles ca un întreg, dar se pot utiliza anumite secțiuni în cazuri individuale.”

Standardul GOST R ISO/IEC 15271 este format din 8 secțiuni și 4 anexe. Secțiunile de fond se numesc după cum urmează (numerotarea este preluată din text):

• 4. Concepte de bază pentru dezvoltarea GOST R ISO / IEC 12207.
• 5. Implementarea GOST R ISO/IEC 12207.
• 6. Aplicare în proiecte.
• 7. Aplicare în organizații.
• 8. Aplicații 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 organizare, distincția dintre conceptele de „software” și „sistem” și distincțiile rezultate între procese legate de software și sisteme. Conceptul este descris în detaliu administrare de calitate, 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 o notă educațională.

Clauza 5 prezintă o abordare generală a implementării, numită strategia de implementare GOST R ISO / IEC 12207. Strategia, conform standardului, este „o metodă tipică de implementare care ar trebui urmată atunci când se efectuează modificări în activitățile unei organizații sau unui proiect”. 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:

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

Dezvoltarea unui plan de implementare include definirea 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 (pot fi mai multe) . Este de la sine înțeles că atunci când se elaborează un plan de implementare, resursele necesare: financiar, uman, tehnic 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 idee simplificată de situația reală. Având în vedere că procesele unei organizații (și structura ei organizațională) sunt în continuă schimbare, consider că ar fi mai corect din punct de vedere metodologic să considerăm implementarea standardului ca un proces continuu, și nu ca un proiect limitat în timp. Acest proces urmărește modificările aduse proceselor organizației și începe 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 o schimbare în structura organizatorică a organizației; etc.

Abordarea implementării GOST R ISO / IEC 12207 ca proces, mai ales dacă ar trebui 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 menținerea proceselor implementate, care este, de asemenea, organizată în mod firesc ca proces.

Pentru mai multe informații despre aplicarea GOST R ISO / IEC 12207 în proiecte, consultați Secțiunea 6 „Aplicarea în proiecte”. Standardul propune clasificarea proiectelor și pentru aceasta introduce un nou concept - „ modelul ciclului de viață sistem" (o listă de modele generice este dată în Anexa C). Ce este un model nu este definit formal. 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ță un sistem specific" (următoarea este o listă de etape). În total, sunt luate în considerare trei astfel de modele: în cascadă, incremental, evolutiv. Sunt analizate avantajele și dezavantajele acestora, iar apoi procesele GOST R ISO / IEC 12207 sunt „suprapuse " asupra structurii modelelor. Ca urmare, aceste procese primesc proprietăți suplimentare, cum ar fi repetări multiple în ciclul de viață sau suprapunerea în timp cu alte procese. În plus, secțiunea conține o mulțime de recomandări grade diferite utilitate cu privire la anumite aspecte proiecte. 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 definească 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 funcționarea sistemului.

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

• interfețe intersistem și intrasistem;
• 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 pași poate să nu fie necesară.”

Aproximarea și vagitatea formulării din pasajul de mai sus sunt caracteristice întregului standard în ansamblu.

Următorul text servește ca parte centrală a secțiunii foarte scurte 7 „Aplicarea în organizații”.

„7.2. Posibilitati de aplicare

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

• test de perfecțiune metoda existenta. Acesta este, de obicei, cazul când metoda a fost dezvoltată de organizația însăși sau o metodă existentă a fost selectată și modificată de către organizație;
• uz practic aceasta metoda 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 noua organizare. Acestea pot include organizații create prin fuziune sau cooperare comercială. Acest lucru poate fi necesar pentru a susține unele modele ale proceselor de furnizare a muncii specifice;
• managementul implementării tehnologie nouă precum 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 controla excelența metodei respective înainte sau după o schimbare de tehnologie;
• 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 din care pot fi dezvoltate programe îmbunătățite, cum ar fi efectuarea unui audit în conformitate cu GOST R ISO / IEC 12207 și utilizarea procesului de îmbunătățire în sine.

Chiar și cu absența completă a obiecțiilor de fond, este încă imposibil să se considere acest text ca un standard. Cel mai mult amintește tutorialși în această calitate, probabil că va fi solicitat, 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 sfârșit, secțiunea 8 „Utilizare aplicată 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ță instrument software” şi încearcă să stabilească o corespondenţă între ele. Din moment ce definiții precise absent, este imposibil să judecăm rezultatele.

În general, standardul GOST R ISO / IEC 15271 dă impresia unui document pur auxiliar în raport cu GOST R ISO / IEC 12207, suferind de aproximare și abundență locuri comune. Este nepotrivit pentru managerii practici - prea mult raționament abstract și prea puțină specificitate. Pentru studenții și profesioniștii care studiază procesele de management IT, îi lipsește o viziune amplă a subiectului (la urma urmei, este limitat la GOST R ISO / IEC 12207) și este supraîncărcat cu detalii tehnice inutile. Cu toate acestea, familiaritatea cu GOST R ISO / IEC 15271 este utilă deoarece arată direcția de gândire a specialiștilor în domeniul managementului IT, demonstrează unde și cum se dezvoltă standardele moderne. L-aș considera un document de lucru interimar, deși sub forma unui standard, dar destinat mai degrabă discuției de către un public interesat de profesioniș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 GOST R ISO/IEC 16326 „Linii directoare pentru aplicarea GOST R ISO/IEC 12207 în managementul proiectelor” (GOST 16326, 2002). El demonstrează o încercare de a se uni procesele ciclului de viață de la GOST R ISO / IEC 12207 cu procese de management de proiect din popularul ghid metodologic PMBOK 1 PMBOK- management de proiect corpul de cunoștințe(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.

Cercul utilizatorilor standardului este definit destul de precis în secțiunea 1.1.

„1.1. Cercul de utilizatori

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, produse create, metodologia, domeniul sau complexitatea. 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 si imbunatatire continua procesele ciclului de viață instrumente software conform GOST R ISO/IEC 12207;
• administratorii responsabili de aplicație procesele ciclului de viață instrumente 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ții pentru persoane sunt date:

• implicat in proiecte software, dar nefiind AP ( Administratorii de proiect. - AB);
• care sunt administratori ai proiectelor non-software, dar legate de facilitati software”.

Textul relativ scurt (clauza 6 „Indrumare” ocupă doar 9 pagini dintr-un total de 35) este un comentariu consecvent asupra procesului 7.1 „Control” din GOST R ISO/IEC 12207 din punctul de vedere al PMBOK. Stilul comentariului este informal, raționamentul este î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”) de proiecte, dar nimic mai mult.

Anexa A este un tabel mare care arată relațiile dintre principalele procese GOST R ISO/IEC 12207 și activitățile procesului de control numit din acestea. Toate aceste referințe sunt conținute în corpul standardului GOST R ISO/IEC 12207; aducerea 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 de activitățile procesului de control din GOST R ISO/IEC 12207.

Un tabel similar care utilizează 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. Nu Informații suplimentare aceste tabele nu sunt purtate, demonstrând doar faptul că există legături între PMBOK și GOST R ISO / IEC 12207. Totuși, statutul ambelor anexe este „de referință”, deci este posibil să nu fi avut nicio valoare independentă.

Un alt tabel rezumativ este prezentat în Anexa D. Acesta arată legăturile dintre trei surse: GOST R ISO / IEC 12207, PMBOK și ISO 10006. Observ imediat că acesta din urmă a fost tradus în limba rusă abia în 2005; în consecință, terminologia utilizată în Anexa D din GOST R ISO/IEC 16326 2002 diferă de cea mai târziu. Ca și în cazurile precedente, sensul prezentării acestor relații într-o formă tabelară compactă nu este clar. Mai mult, volumul total Anexele A-D depășește de mai mult de două ori volumul secțiunii principale 6 „Orientări”.

În opinia mea, GOST R ISO / IEC 16326-2002 nu diferă ca formă și scop de GOST R ISO / IEC 15271-2002. Ambele suferă de un exces de „în general” corect și bazat doar pe raționament de bun simț. Aceste considerații sunt evidente pentru oricine are experienta practica management de proiect și este puțin probabil să arate rezonabil pentru cei care nu au o astfel de experiență. Spre deosebire de GOST R ISO/IEC 15271-2002, 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 în implementarea de proiecte complexe, inclusiv, împreună cu studiul practicilor de management IT, analiza management de proiectși administrare de calitate.

În plus față de GOST R ISO / IEC 12207 discutat mai sus, au luat viață o serie de standarde care detaliază procesele ciclului de viață. Acestea includ, de exemplu, GOST R ISO / IEC 15910-2002 „Proces de creare a documentației utilizatorului software” (GOST 15910, 2002) și GOST R ISO / IEC 14764-2002 „Întreținere software” (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.

1) Permite implementarea oricărui model de ciclu de viață- acest lucru este posibil, pentru că Standardul oferă o modalitate de a defini secvența 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 este redusă la excluderea proceselor, activităților și sarcinilor care nu sunt aplicate într-un anumit proiect.

3) Standardul practic nu conține o descriere a metodelor 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 extrem de puține descrieri privind proiectarea bazei de date- acest lucru este justificat, pentru că diferite IS-uri și diferite sisteme software nu pot folosi doar anumite tipuri de baze de date, dar pot să nu folosească 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 impune utilizarea unui anumit model de ciclu de viață sau a unei metode de dezvoltare, el specifică faptul că părțile din proiect sunt responsabile pentru următoarele:

selectarea modelului ciclului 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 diverse feluri și tot felul de componente ale acestora.

Standardele GOST prevăd etapele și etapele 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 automat este împărțită în următoarele etape și etape:

Etapa 1 formarea cerințelor pentru UA:

Etapa a: verificarea obiectului ș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 de progres și pregătirea unei propuneri de dezvoltare termeni de referinta.

Etapa 2 Dezvoltarea conceptului:

a: studiul obiectului;

b: efectuarea cercetării și dezvoltării necesare;

c: dezvoltarea de variante ale conceptului AU care să răspundă cerințelor clientului;

d: elaborarea unui raport de progres.

Etapa 3 elaborarea și aprobarea termenilor de referință pentru crearea centralelor nucleare.

Etapa 4 Elaborarea proiectării proiectului 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 unui proiect tehnic:

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

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

c: elaborarea și executarea documentației pentru furnizarea de produse pentru achiziția 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 sistemul din partea sa;

b: dezvoltare sau adaptare software.

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

a: pregătirea obiectului de automatizare pentru implementarea AS;

b: formarea personalului;

c: completarea AU cu software și hardware;

d: lucrari de instalare;

e: punerea în funcțiune;

e: teste preliminare;

g: operațiune de probă;

h: teste de acceptare.

Etapa 8 escorte:

a: efectuarea lucrărilor în conformitate cu garanția;

b: service post-garanție.

Rusia folosește în prezent standardul GOST R ISO/IEC 12207-2010 Procesele ciclului de viață al software-ului ( ISO/IEC 12207:2008 Ingineria sistemelor și a software-ului — Procese ale ciclului de viață al software-ului)

ISO/IEC 12207 - standard de bază procesele ciclului de viață al software-ului, concentrate pe diverse (orice!) tipuri de software și tipuri de proiecte AS, în care software-ul este inclus ca parte. Standardul definește strategia și ordinea generală în crearea și funcționarea software-ului, acoperă ciclul de viață al software-ului de la conceptualizarea ideilor până la finalizarea ciclului de viață.

Structura generală- convinge-te singur!

Particularitati:

Standardul ISO constă din procese generalizate foarte mari: „achiziție”, „livrare”, „dezvoltare”, etc. În linii mari, un astfel de proces este comparabil cu toate procesele CDM luate împreună. Fiecare proces este împărțit într-un set de acțiuni, fiecare acțiune în set de sarcini. O diferență foarte importantă între ISO: fiecare proces, acțiune sau sarcină este inițiată și executată de un alt proces după cum este necesar și nu există secvențe predeterminate (în mod firesc, păstrând în același timp logica relațiilor conform informațiilor inițiale ale sarcinilor etc.).

- Natura „dinamică” a standardului este determinată de modul în care este determinată succesiunea proceselor și sarcinilor, în care un proces, dacă este necesar, denumește un altul sau o parte din acesta. Acest caracter vă permite să implementați orice model de ciclu de viață.

Gradul de adaptabilitate: maxim. Multe procese și sarcini sunt proiectate astfel încât să poată fi adaptate în conformitate cu proiectele software. Procesul de adaptare este procesul de eliminare a proceselor, activităților și sarcinilor care nu sunt aplicabile unui anumit proiect.

Standardul în principiu nu conține metode specifice de acțiune, în special - pregătirea deciziilor sau documentație. Descrie arhitectura proceselor ciclului de viață al software-ului, dar nu specifică în detaliu cum să implementeze sau să execute serviciile și sarcinile incluse în procese și nu are scopul de a prescrie numele, formatul sau conținutul exact al documentației rezultate. Deciziile de acest tip se iau folosind standardul.

Specificul utilizării standardului este că acesta conține seturi de sarcini, caracteristici de calitate, criterii de evaluare etc., oferind o acoperire cuprinzătoare a situațiilor proiectului. Standardul nu prescrie un model specific de ciclu de viață sau o metodă de dezvoltare software, dar specifică că părțile care utilizează standardul sunt responsabile pentru alegerea unui model de ciclu de viață pentru un proiect software, pentru adaptarea proceselor și sarcinilor standardului la acest lucru. model, pentru alegerea și aplicarea metodelor de dezvoltare software, pentru realizarea acțiunilor și sarcinilor adecvate proiectului software.

Gradul de cerință: Odată ce o organizație decide să aplice ISO12207 ca o condiție a unei relații comerciale, este responsabilitatea sa să specifice setul minim de procese și sarcini necesare care constituie alinierea la acel standard.

MODEL SEI SW-CMM

Metodologie CMM proiectat și dezvoltat în SUA ca un instrument de selectare a celor mai buni producători PE pentru a îndeplini ordinele guvernamentale.

Pentru a face acest lucru, trebuia să creeze criterii pentru evaluarea maturității proceselor cheie ale companiei dezvoltatoare și să determine setul de acțiuni necesare pentru îmbunătățirea lor ulterioară. Ca urmare, metodologia s-a dovedit a fi extrem de utilă pentru majoritatea companiilor care doresc să se îmbunătățească calitativ procesele existente proiectarea, dezvoltarea, testarea instrumentelor software și reducerea managementului acestora la algoritmi și tehnologii ușor de înțeles și de implementat descrise într-un singur standard.

SMM este standardul de facto.

Baza creării CMM a fost poziția de bază conform căreia problema fundamentală a „crizei” procesului de dezvoltare a unui PE nu este în absența unor noi metode și instrumente de dezvoltare, ci în incapacitatea companiei de a se organiza procese tehnologice si gestioneaza-le.

Pentru a evalua gradul de pregătire a întreprinderii de a dezvolta o calitate software SMM prezintă concept cheie maturitatea organizatiei (Maturitate).

SMM definește 5 niveluri maturitatea tehnologică a companiei:

1. Nivelul 1, inițial - organizații care dezvoltă software, dar nu au un proces de dezvoltare conștient, nu își planifică și nu își evaluează capacitățile;

2. Nivelul 2, repetabil - în astfel de organizații se înregistrează costurile cu resursele și se monitorizează progresul proiectelor, se stabilesc reguli de management al proiectelor pe baza experienței existente;

3. Nivelul 3, definit - in astfel de organizatii exista un proces acceptat, pe deplin documentat, corespunzator starii reale de fapt si accesibil personalului, procesul de dezvoltare si intretinere a software-ului. Acest proces ar trebui să includă atât sub-procese manageriale, cât și tehnice, precum și instruirea angajaților pentru a lucra cu el;

4. Nivelul 4, gestionat - în aceste organizații, pe lângă procesul stabilit și descris, sunt utilizați indicatori măsurabili ai calității produselor și eficacității proceselor, care fac posibilă prezicerea cu exactitate a cantității de resurse (timp, bani, personal) necesare pentru a dezvolta un produs cu o anumită calitate);

5. Nivelul 5îmbunătățirea - în astfel de organizații, pe lângă procesele și metodele de evaluare a acestora, există metode de identificare a punctelor slabe, proceduri de căutare și evaluare a noilor metode și tehnici de dezvoltare, pregătirea personalului pentru a lucra cu acestea și includerea lor în proces general organizaţii în cazul creşterii eficienţei producţiei).

Fiecare nivel următor fara esec cuprinde toate caracteristicile cheie ale celor anterioare. Cu privire la certificare companiilor pe unul dintre niveluri presupune îndeplinirea necondiţionată a tuturor cerinţelor nivelurilor inferioare.