Ordin nr.78 din 01.06.2006 cu privire la aprobarea reglementării tehnice "Procesele ciclului de viaţă al software-ului" RT 38370656 - 002:2006

MINISTERUL TEHNOLOGIEI INFORMAŢIEI
ŞI COMUNICAŢIILOR

O R D I N

cu privire la aprobarea reglementării tehnice

"Procesele ciclului de viaţă al software-ului"

RT 38370656 - 002:2006

nr.  78  din  01.06.2006

 (în vigoare 23.07.2006) 

Monitorul Oficial nr. 95-97 art.335 din 23.06.2006

* * *

Notă: Vezi Legea nr.21-XVIII din 18.09.2009 pentru modificarea Legii nr.64-XII din 31 mai 1990 cu privire la Guvern (se reorganizează Ministerului Dezvoltării Informaţionale în Ministerul Tehnologiilor Informaţionale şi Comunicaţiilor)

Întru executarea Hotărîrii Guvernului Republicii Moldova nr.873 din 30.07.2004 "Cu privire la aprobarea Programului naţional de elaborare a reglementărilor tehnice",

ORDON:

1. A aproba reglementarea tehnică "Procesele ciclului de viaţă al software-ului" RT 38370656 - 002:2006 (se anexează).

2. Prezenta reglementare tehnică va intra în vigoare în termen de 30 de zile de la data publicării în "Monitorul Oficial al Republicii Moldova".

Anexă

la ordinul ministrului dezvoltării

informaţionale

nr._____din "__"_______2006

REGLEMENTARE TEHNICĂ

"Procesele ciclului de viaţă al software-ului"

RT 38370656- 002:2006

1. OBIECT ŞI DOMENIU DE APLICARE

Prezenta reglementare tehnică se referă la procesele ciclului de viaţă al software-ului şi este obligatorie la crearea tuturor sistemelor informaţionale automatizate de importanţă statală.

 Reglementarea tehnică se orientează spre aplicarea tehnologiilor orientate pe obiecte şi a mijloacelor contemporane de management al proiectelor, de elaborare şi suport a versiunilor.

 Agenţii economici, care furnizează/procură software pentru sistemele informaţionale automatizate nestatale, pot aplica prezenta reglementare tehnică în mod voluntar.

2. TERMINOLOGIE ŞI SEMNE CONVENŢIONALE

 2.1 Noţiunile utilizate în prezenta reglementare tehnică au următoarele semnificaţii:

Abordare incrementală (în contextul elaborării sistemului software): Procesul dezvoltării neîntrerupte a arhitecturii sistemului, atunci cînd fiecare versiune nouă conţine ameliorări comparativ cu cea precedentă.

Achizitor: Organizaţia care procură sau obţine un produs software sau servicii software de la furnizor.

Activitate: Îndeplinirea prelungită a unei acţiuni de către un careva rol.

Notă:

Activitatea este îndeplinită de una sau de cîteva funcţii ale sistemului, descrise din punctul de vedere al interacţiunii lucrătorilor-business, conform structurii logice a întreprinderii.

Actor-business: Obiect, care activează în afara limitelor sistemului, dar care interacţionează cu el.

Arhitectură: Totalitatea soluţiilor esenţiale privind organizarea sistemului software, precum şi setul de elemente şi interfeţe structurale din care constă sistemul, împreună cu comportamentul descris în termenii cooperării acestor elemente.

Notă:

La arhitectura sistemului software se referă de asemenea utilizarea, funcţionalitatea, productivitatea, flexibilitatea, aplicarea repetată, claritatea, restricţiile şi compromisele economice şi tehnologice, precum şi aspectele estetice.

Artefact: Element al informaţiei, utilizat sau generat în procesul de elaborare a sistemului software sau de exploatare a produsului software.

Bază de date: Totalitatea datelor combinate, organizate conform anumitor reguli, care prevăd principii generale de descriere, stocare şi procesare a datelor.

Cerinţă: Funcţionalitatea, particularitatea sau comportamentul dorit al obiectului (sistemului).

Comentariu: Adnotaţie adiţionată la element sau la multitudinea de elemente.

Comportament: Efectul observat al evenimentului, inclusiv rezultatele lui.

Domeniu de materie: Domeniu specific de cunoştinţe sau de activitate, caracterizat prin concepţii şi termeni specifici.

Elaborator: Organizaţia care execută activităţi de elaborare (inclusiv analiza cerinţelor, proiectarea, realizarea produsului software, pînă la testarea de calificare) în timpul procesului ciclului de viaţă al software-ului.

Etapă: Lista proceselor, care trebuie îndeplinite în intervalul de timp dintre două repere de bază în ciclul de viaţă al sistemului software, în decursul căruia trebuie să fie atinse scopurile trasate din timp şi bine determinate, artefactele trebuie să fie aduse pînă la disponibilitate şi trebuie să fie luată decizia cu privire la finisarea acestei etape sau trecerea la următoarea etapă.

Funcţie-business: Ansamblu de acţiuni la îndeplinirea procesului-business, care oferă rezultat util actorului-business concret.

Notă:

Funcţia-business conţine toate scenariile de lucru de bază şi de alternativă, pentru primirea rezultatului final.

Furnizor: Organizaţia care furnizează achizitorului produs sau servicii software, în conformitate cu condiţiile contractului sau documentului de dispoziţie.

Identificatorul obiectului: Atribut al datelor, semnificaţia căruia determină univoc obiectul informaţional.

Infrastructura procesului de mentenanţă: Structura organizaţională, obligaţiunile, procedurile, procesele şi resursele utilizate la îndeplinirea mentenanţei.

Iteraţie: Listă conturată de lucrări, pentru care sînt determinate scopul final şi criteriul de apreciere. Ca rezultat al cîtorva iteraţii, trebuie să fie lansată versiunea sistemului software.

Mentenanţă adaptivă: Modificarea produsului software, care asigură capacitatea sa de funcţionare în condiţii (mediu) modificate sau care se modifică.

Mentenanţă de avertizare: Modificarea produsului software după livrare, în scopul detectării şi corectării erorilor ascunse în el, pentru a preveni manifestarea evidentă a acestor erori la exploatarea produsului dat.

Mentenanţă de corecţie: Modificarea reactivă a produsului software, îndeplinită după livrarea lui, pentru corectarea problemelor detectate (necorespunderilor, erorilor).

Notă:

Astfel de modificări corectează produsul software, pentru a-l aduce în corespundere cu cerinţele stabilite.

Mentenanţă totală: Modificarea produsului software după livrare, pentru îmbunătăţirea caracteristicilor sale de funcţionare, adăugarea funcţionalităţii sau îmbunătăţirea mentenabilităţii.

Notă:

Mentenanţa totală asigură modernizarea (perfecţionarea) produsului software în interesele utilizatorului, specificarea documentelor de program corespunzătoare şi reprogramarea lui, pentru îmbunătăţirea caracteristicilor de funcţionare şi a altor atribute ale produsului software.

Mesaj despre problemă (MP): Termen utilizat pentru determinarea şi descrierea problemelor detectate în produsul software la etapa de mentenanţă.

Metodă iteraţională (în contextul elaborării sistemului software): Metodă de elaborare a sistemului software, în cazul căreia se realizează procesul de dirijare a fluxului de versiuni executabile.

Model al ciclului de viaţă: Structura care include procesele, acţiunile şi sarcinile, implicate în elaborarea, exploatarea şi mentenanţa produsului software, şi care cuprinde toată durata vieţii sistemului software de la determinarea cerinţelor sale tehnice pînă la finisarea utilizării.

Obiect: Reflectarea virtuală a entităţilor existente real, atît a celor materiale cît şi a celor nemateriale, în care sînt încapsulate starea şi comportamentul.

Personal de mentenanţă: Organizaţia care execută activităţi de mentenanţă.

Proces-business: Consecutivitatea fixată a evenimentelor, realizată printr-un grup de activităţi legate logic, care utilizează resursele organizaţiei pentru obţinerea rezultatului la realizarea scopurilor organizaţiei.

Notă:

Procesul-business se descrie cu ajutorul funcţiilor-business, care prezintă comportamentul aşteptat al sistemului.

Produs software: Sistem software, care are valoare comercială, gata pentru utilizare sau deja exploatat.

Proiect: Proces unic, care constă dintr-un set de genuri de activitate coordonate şi dirijate, cu datele de început şi de sfîrşit, întreprinse pentru atingerea scopului în conformitate cu cerinţele stabilite, inclusiv limitările privind termenele, cheltuielile şi resursele.

Propunere de modificare (PM): Termen general, utilizat pentru determinarea modificărilor presupuse în produsul menţinut.

Notă:

Propunerea concretă de modificare poate fi clasificată în continuare drept corecţie sau modernizare şi poate fi determinată ca tip de mentenanţă de corecţie, de avertizare, adaptivă sau totală.

Regulă-business: Descrierea unei anumite reguli sau serviciu, care trebuie de îndeplinit în cadrul sistemului.

Reorganizare: Metode, care permit micşorarea dificultăţilor de scurtă durată, legate cu refacerea proiectului, fără a modifica funcţionalitatea software-ului, dar se modifică structura lui, care devine mai inteligibilă şi modificabilă.

Riscuri: Influenţarea internă şi externă asupra sistemului, care poate să influenţeze în mod negativ asupra domeniului proiectului sau poate să ducă la eşuarea lui.

Rol (în contextul ciclului de viaţă al sistemului software): Anumit comportament şi obligaţiuni ale persoanei sau ale indivizilor, care lucrează în echipă (grup de lucru).

Rol-business (în contextul descrierii proceselor-business): Comportamentul specific menţionat al entităţii în situaţie concretă.

Notă:

Rolul-business poate fi static (de exemplu, poate fi unul din participanţii legăturii asociative) sau dinamic (de exemplu, rolul care colaborează cu cineva).

Sarcină: Element software, care este gata pentru integrarea în sistemul comun, realizabil în termene minime.

Scenariu: Prezentarea cunoştinţelor, care utilizează consecutivitatea fixată a evenimentelor, pentru determinarea rezultatelor interacţiunii între elementele cunoscute.

Serviciu de sistem: Serviciu prestat utilizatorului de sistemul software sau de produsul software.

Serviciu: Îndeplinirea acţiunilor direcţionate spre satisfacerea necesităţilor clientului sau a celor prevăzute de documentele normative, rezultatul cărora se reflectă în sistemul informaţional şi se poate exprima în formă materială sau nematerială.

Sistem informaţional automatizat (SIA): Totalitatea mijloacelor software şi hardware, destinate pentru procesarea informaţiei, resurselor informaţionale şi infrastructurii utilizatorului.

Sisteme informaţionale automatizate de importanţă statală: Sistemele informaţionale automatizate care funcţionează în autorităţile administraţiei publice şi puterii de stat.

Sistem software: Multitudine de elemente ale software-ului, organizate pentru atingerea unui scop concret, uneori despărţite în cîteva subsisteme şi descrise de un set de modele, posibil, din diferite puncte de vedere.

Software: Totalitatea programelor sistemului de procesare a informaţiei şi a documentelor de program, necesare pentru exploatarea acestor programe.

Stare: Situaţie în ciclul de viaţă al obiectului, în timpul căreia el satisface o anumită condiţie, îndeplineşte o anumită activitate sau aşteaptă un anumit eveniment.

Stereotip: Extinderea limbajului UML (Unified Modeling Language), care permite crearea noilor tipuri de blocuri de construcţie derivate de la cele existente, dar specifice pentru descrierea unei sarcini concrete.

Notă:

Stereotipurile pot fi textuale şi grafice.

Testare de calificare: Testare realizată de către elaborator şi atestată de către beneficiar, cu scopul de a demonstra corespunderea produsului software cu sarcina tehnică aprobată şi disponibilitatea utilizării lui în scopuri de serviciu.

Utilizator: Persoana sau organizaţia separată, care exploatează produsul software, utilizează serviciile software.

Versiune: Set de artefacte relativ complet şi autocoordonat, destinat utilizării interne sau externe.

2.2  Semne convenţionale

În prezenta reglementare tehnică se aplică următoarele semne convenţionale:

- rol (în contextul ciclului de viaţă al sistemului software);

- activitate, îndeplinită de către rol la realizarea proceselor concrete.

3. PĂRŢILE CARE PARTICIPĂ LA CICLUL DE VIAŢĂ

AL SISTEMULUI SOFTWARE

În prezenta reglementare tehnică, termenii "organizaţie" şi "parte" sînt sinonime. Atunci cînd organizaţia sau partea ei participă la un anumit proces al ciclului de viaţă al sistemului software, atunci ea devine "parte". Părţile pot fi din una şi aceiaşi organizaţie sau din diferite organizaţii.

Organizaţia sau partea primeşte denumirea sa în dependenţă de procesul pe care-l realizează: de exemplu, ea se numeşte "elaborator" atunci cînd realizează procesul de elaborare.

Părţile de bază, care participă la procesele ciclului de viaţă sistemului software, sînt acelea, care iniţiază sau execută dezvoltarea, utilizarea sau mentenanţa produselor software.

 Părţi de bază sînt:

a) achizitorul (beneficiarul);

b) furnizorul;

c) elaboratorul;

d) personalul de mentenanţă;

e) utilizatorul.

Notă:

Se admite unificarea cîtorva părţi într-o singură persoană, de exemplu: beneficiarul şi utilizatorul, furnizorul şi elaboratorul.

În cazul cînd utilizatorul nu este beneficiar, el poate participa la acelaşi nivel cu beneficiarul la toate etapele ciclului de viaţă al sistemului software, în particular, în cadrul celor stipulate în acordul (contractul) cu beneficiarul.

De acţiunile şi sarcinile în cadrul procesului de bază al ciclului de viaţă al sistemului software este responsabilă partea (sau părţile), care a început şi care realizează etapa dată.

4. ELEMENTELE CICLULUI DE VIAŢĂ AL SISTEMULUI SOFTWARE

4.1  Proiecte

Pentru a îndeplini acţiunile/transformările necesare asupra sistemului software pe parcursul ciclului său de viaţă, organizaţia creează şi controlează proiecte.

Proiectele au anumite limite, termene şi scop. Limitele pot include acţiuni atît la toate etapele ciclului de viaţă al sistemului software sau submultitudinea de etape, cît şi în unul sau cîteva procese determinate, sau anumite activităţi în cadrul procesului. Diapazonul temporal se poate modifica conform duratei.

Scopul proiectului este legat cu scopul sistemului software în întregime, sau cu părţile sale componente.

Orice sistem software se poate diviza în sisteme mai mici şi în acelaşi timp poate fi parte a altui sistem software de proporţii mai mari.

Astfel, interacţiunea sistemelor software capătă forma unei structuri ierarhice, precum se prezintă în figura 1.

Fig.1 - Structura ierarhică a sistemelor software şi proiectelor

Prezenta reglementare tehnică se aplică la toate nivelele ierarhiei, care se referă la sistemul software. Deoarece sistemul software se poate diviza recursiv în elemente de sistem, procesele prezentei reglementări tehnice pot fi aplicate repetat fiecărui element de sistem, adică fiecare element de sistem are ciclu de viaţă propriu.

În structura ierarhică, fiecare sistem software poate fi obiectul responsabilităţii unui proiect separat. Astfel, există o legătură strînsă între nivelele detalierii în arhitectura sistemelor software şi nivelele de responsabilitate în ierarhia proiectelor. Fiecare proiect este responsabil de primirea şi utilizarea nivelelor în componenţa sistemului software mai jos decît el şi de crearea şi punerea la un nivel mai înalt decît el.

4.2  Etape

Sistemele software examinate în prezenta reglementare tehnică sînt artificiale, create şi utilizate pentru prestarea serviciilor în anumite condiţii, pentru beneficiul utilizatorilor şi al altor persoane interesate.

Ciclul de viaţă al sistemului software constă dintr-un şir de etape la care sistemul software este planificat, creat, implementat, exploatat, menţinut şi anulat. Aceasta se ilustrează prin modelul-tip al ciclului de viaţă al sistemului software, prezentat în figura 2.

 Fig.2 - Modelul ciclului de viaţă al sistemului software

Etapele ciclului de viaţă se unesc în şiruri, care se pot suprapune şi/sau repeta în conformitate cu limitele, dimensiunile, complexitatea, necesităţile care se modifică şi posibilităţile de realizare a sistemului software. Ele sînt iteraţionale şi se realizează prin acţiuni pas cu pas.

Modelul-tip al ciclului de viaţă al sistemului software constă din şase etape:

a) lucrările de anteproiect;

b) elaborarea sistemului software;

c) implementarea sistemului software;

d) exploatarea sistemului software;

e) mentenanţa sistemului software;

f) utilizarea sistemului software.

Furnizorul, în comun cu beneficiarul, trebuie să creeze modelul ciclului de viaţă al sistemului software concret, utilizînd etapele şi procesele indicate.

Cu fiecare etapă se atinge un scop clar şi se aduce contribuţie la ciclul de viaţă al sistemului software în întregime. Fiecare etapă se ia în consideraţie la planificarea şi îndeplinirea ciclului de viaţă al sistemului software.

Pentru realizarea fiecărei etape, organizaţia trebuie să dispună de infrastructură corespunzătoare, buget, complex tehnic de program, instrumente, proceduri aprobate şi resurse umane competente. Toate componentele indicate se planifică pînă la începerea realizării etapei, dar se creează şi/sau se achiziţionează pe măsura necesităţii.

Începutul şi sfîrşitul fiecărei etape şi proces, trebuie să fie perfectate documentar în modul stabilit în organizaţie. 

4.2.1 Etapa lucrărilor de anteproiect

Etapa lucrărilor de anteproiect începe de la conştientizarea iniţială a necesităţii de a crea un nou sistem informaţional automatizat sau de a modifica sistemul informaţional automatizat existent (SIA) (grupul de SIA), sau de a modifica căile de automatizare a activităţii şi proceselor. Etapa dată este perioada examinării iniţiale, colectării faptelor şi analizei, studierii legislaţiei în vigoare şi a structurii organizatorice existente, examinării SIA analogice existente. Pentru elaborarea documentelor de ieşire ale etapei date, elaboratorul necesită legătura inversă cu utilizatorii.

Cu ajutorul analizei, determinării realizabilităţii, evaluării cheltuielilor, marketingului, posibilităţilor intelectuale şi asigurării tehnico-materiale, examinării alternativelor, precum şi elaborării experimentale, se elaborează una sau cîteva soluţii de alternativă pentru a satisface necesitatea beneficiarului sau pentru a realiza concepţia. Totodată, la această etapă se determină necesitatea de unul sau mai multe subsisteme, pentru realizarea sistemului software.

Elemente de ieşire ale etapei lucrărilor de anteproiect sînt următoarele artefacte de bază:

- concepţia sistemului;

- propunerea-business.

La această etapă se iau deciziile: de a continua realizarea sistemului software sau de a înceta lucrul ulterior.

 4.2.2 Etapa de elaborare

 Etapa de elaborare începe cu precizarea detaliată a cerinţelor beneficiarului şi a soluţiei de proiect şi le transformă în unul sau cîteva produse software viabile, care asigură lucrul pe parcursul etapei de exploatare. La această etapă sistemul software poate fi prototip.

Se stabilesc, se analizează, se elaborează, se creează, se testează şi, în caz de necesitate, se evaluează mecanismele de interacţiune a elementelor software şi structurilor organizaţionale, precum şi se determină cerinţele faţă de hardware, infrastructura utilizatorului, instruire şi mentenanţă.

Rezultatul îndeplinirii etapei este elaborarea produsului software, capacitatea de funcţionare şi funcţionalitatea căruia sînt confirmate prin testări pentru calificare, documentaţie necesară, precum şi efectuarea altor elaborări necesare.

La această etapă, prin atragerea tuturor părţilor interesate, se asigură includerea în proiect a aspectelor etapelor ulterioare, precum şi a cerinţelor şi posibilităţilor sistemelor de asigurare corespunzătoare. Totodată este necesară legătura inversă cu persoanele interesate, care sînt responsabile de realizarea etapelor ulterioare.

Elemente de ieşire ale etapei de elaborare sînt următoarele artefacte de bază:

- sarcina tehnică;

- proiectul tehnic;

- versiunea sistemului software;

- documentaţia tehnică;

- procesul-verbal de testare de calificare;

- actul de predare în exploatare experimentală.

În cazul anunţării tender-ului pentru elaborarea sistemului software, sarcina tehnică trebuie să fie parte integrantă a ofertei tender.

Planificarea etapei de elaborare începe la etapa precedentă, pentru a asigura existenţa sau posibilitatea creării în organizaţie a infrastructurii sistemelor de asigurare a elaborării, care constă din metode, mijloace tehnice, instrumente şi resurse umane competente pentru a efectua analiza proceselor, modelarea, crearea prototipurilor, proiectarea, integrarea, testarea şi documentarea. Aceste elemente se elaborează sau se achiziţionează pe măsura necesităţii, pentru suportul etapei de elaborare.

4.2.3 Etapa de implementare

Etapa de implementare începe cu permisiunea de a instala produsul software la locurile funcţionării lui. În anumite cazuri, sistemul software poate fi produs individual, asamblat, integrat şi testat sau poate fi produs în masă. La această etapă se realizează pregătirea infrastructurii utilizatorului şi utilarea încăperilor în care va funcţiona produsul software, verificarea capacităţii de funcţionare a produsului software în condiţii reale de exploatare, precum şi se organizează instruirea personalului privind lucrul cu produsul software sau cu componenţii lui.

Planificarea etapei de implementare începe la etapa precedentă (etapa de elaborare). Tirajarea produsului software poate continua pe parcursul întregului ciclu de viaţă al sistemului software.

Elementele de ieşire ale etapei de implementare sînt următoarele artefacte de bază:

- actul de finisare a elaborării;

- actul de predare în exploatare.

Partea de bază a etapei se finisează cu punerea în exploatare a produsului software.

4.2.4 Etapa de exploatare

Etapa de exploatare începe cu instalarea şi confirmarea documentară a începerii utilizării produsului software. Utilizarea produsului software se efectuează în scopul primirii serviciilor software cerute, cu eficacitate funcţională şi valorică continuă. Această etapă continuă pînă la începerea etapei de utilizare.

Planificarea etapei de exploatare începe la etapele precedente. Etapa respectivă include procesele, care sînt legate cu utilizarea produselor software pentru prestarea serviciilor, precum şi controlul funcţionării, detectării şi documentării problemelor apărute.

Acţiunile (sau lipsa anumitor acţiuni întreprinse) cu privire la problemele detectate pot fi următoarele:

- aprobarea actului de punere în exploatare;

- mentenanţa produsului software;

- iniţierea acţiunilor de mentenanţă în cazul modificărilor nesemnificative;

- iniţierea suplimentară a etapei de elaborare, în cazul modificărilor de proporţii mari;

- iniţierea etapei de anulare.

În timpul etapei de exploatare, produsul software sau părţile lui separate se pot modifica şi dezvolta, ducînd la formarea diferitor configuraţii. Elaboratorul modificărilor trebuie să asigure dirijarea versiunilor elementelor software.

Elemente de ieşire ale etapei de exploatare sînt următoarele artefacte de bază:

- actul de dare în exploatare;

- propunerea de modificare;

- mesajele despre probleme.

4.2.5 Etapa de mentenaţă

Etapa de mentenanţă poate fi activată de procesul de exploatare, prin prezentarea propunerii de modificare sau mesajului despre problemă. Procesul de mentenanţă se aplică pentru modificarea produsului software, păstrînd capacitatea sa de funcţionare şi integritatea datelor. Prin acest proces se controlează funcţionarea produsului software, se înregistrează problemele pentru analiză, se întreprind acţiuni de avertizare şi de corecţie, precum şi acţiuni de adaptare şi perfecţionare a produsului software.

Se aplică următoarele tipuri de mentenanţă de bază:

- mentenanţa de corecţie;

- mentenanţa de avertizare;

- mentenanţa adaptivă;

- mentenanţa totală.

Planificarea etapei de mentenaţă începe la etapele precedente. Elemente de ieşire ale etapei de mentenanţă sînt următoarele artefacte de bază:

- concepţia mentenanţei;

- planul de mentenanţă;

- varianta coordonată a modificărilor;

- produsul software modificat şi documentaţia;

- actul de predare în exploatare a produsului software modificat.

Etapa respectivă se finisează concomitent cu finisarea etapei de exploatare. În caz de necesitate, la etapa de mentenanţă se realizează instruirea şi perfecţionarea personalului.

4.2.6 Etapa de utilizare

Etapa de utilizare prevede retragerea din exploatare a produsului software şi a subsistemelor software legate cu el, şi a proceselor software auxiliare. Toate subsistemele, documentele şi datele legate cu produsul software precedent, trebuie să fie stocate în arhive. Datele trebuie să fie protejate şi accesibile pentru verificarea de audit.

Planificarea etapei de utilizare începe la etapele precedente.

Elemente de ieşire ale etapei de utilizare sînt următoarele artefacte de bază:

- produsul software retras din exploatare;

- arhiva artefactelor retrase.

Etapa de utilizare începe atunci cînd produsul software este retras din exploatare şi se prelungeşte pe parcursul utilizării active a celorlalte elemente ale sistemului software.

4.3 Rolurile ciclului de viaţă al sistemului software

La îndeplinirea proceselor ciclului de viaţă al sistemului software se determină următoarele roluri de bază:

- managerul proiectului;

- reprezentantul beneficiarului;

- consultantul juridic;

- analistul proceselor-business;

- managerul elaborării sistemului software;

- proiectantul-business;

- analistul de sistem;

- arhitectul sistemului software;

- proiectantul sistemului software;

- proiectantul interfeţei pentru utilizator;

- programatorul;

- integratorul;

- persoana de testare;

- elaboratorul testelor;

- scriitorul tehnic;

- managerul implementării produsului software;

- tehnologul proceselor-business;

- administratorul de sistem;

- administratorul bazelor de date;

- managerul exploatării;

- utilizatorul produsului software;

- managerul mentenanţei produsului software;

- specialistul dirijării configuraţiei;

- analistul serviciului de mentenanţă;

- persoana de testare a serviciului de mentenanţă.

La realizarea proiectelor concrete, se admite completarea componenţei rolurilor, predeterminate de prezenta reglementare tehnică, precum şi îndeplinirea a cîtorva roluri de către un singur executant.

4.4 Procesele ciclului de viaţă al sistemului software

Procesele ciclului de viaţă al sistemului software, determinate în prezenta reglementare tehnică, pot fi utilizate de orice organizaţie (subdiviziune), care achiziţionează şi utilizează, şi/sau creează şi furnizează sistemul software. Procesele pot fi aplicate la orice nivel în ierarhia sistemului software şi la orice etapă a ciclului de viaţă al sistemului software.

Procesele ciclului de viaţă al sistemului software se bazează pe principiile modularităţii (conexiunea maximă a funcţiilor procesului şi legătura minimă între procese) şi responsabilităţii (procesul se asociază cu responsabilitatea pentru realizarea sa). Funcţiile îndeplinite de aceste procese se determină de scopurile specifice, rezultatele cerute şi seturile de activităţi, care alcătuiesc acest proces.

Orice proces aplicabil în ciclul de viaţă al sistemului software este de lungă durată. Structural, el poate fi alcătuit din trei faze, precum se prezintă în figura 3.

Fig.3 - Structura îndeplinirii proceselor

În timpul fazei de pregătire poate avea loc familiarizarea cu domeniul de obiect, examinarea rezultatelor proceselor îndeplinite anterior, îndeplinirea planificării şi calculelor prealabile.

În timpul fazei active are loc îndeplinirea nemijlocită a procesului. În prezenta reglementare tehnică, la descrierea proceselor se evidenţiază doar acţiunile fazei active.

În timpul fazei de finisare se pot îndeplini acţiunile de analiză a rezultatelor, se pot finisa activităţile începute în timpul fazei active, pot continua lucrările nelimitate de termenul de finisare.

Organizaţia (partea) realizează selectiv procesele ciclului de viaţă al sistemului software, pentru atingerea scopului şi rezultatelor etapelor ciclului de viaţă al sistemului. Procesele descrise în prezentele reglementări tehnice pot fi completate cu acele procese, pe care organizaţia, în dependenţă de proiect, le va considera necesare pentru atingerea eficacităţii maximale a sistemului.

Pentru fiecare proces se determină scopurile şi rezultatele, precum şi activităţile necesare pentru atingerea lor.

Fiecare proces trebuie să fie documentat.

4.5  Lista proceselor

Procesele ciclului de viaţă al sistemului software se unesc în patru grupe, conform tabelului 1.

În prezenta reglementare tehnică sînt examinate prevederile generale ale proceselor contractului, întreprinderii, proiectului şi detaliat procesele tehnice.

4.6 Utilizarea proceselor

Utilizarea tip a proceselor este prezentată în figura 4.

 Fig.4 - Utilizarea tip a proceselor

În cadrul proiectului poate fi realizată utilizarea paralelă a proceselor, de exemplu, atunci cînd acţiunile de proiect şi acţiunile de pregătire pentru crearea sistemului software se îndeplinesc în acelaşi timp, precum şi între proiecte, de exemplu, atunci cînd elementele software se elaborează concomitent, cu responsabilitate diferită a proiectului.

Utilizarea repetată a proceselor este importantă pentru precizarea progresivă a rezultatelor procesului. De exemplu, interacţiunea între acţiunile de verificare consecutive şi acţiunile de integrare, poate consolida treptat certitudinea în corespunderea produsului software cu cerinţele beneficiarului.

Utilizarea recursivă a proceselor la fiecare nivel al detalierii în ciclul de viaţă al sistemului software este aspectul cheie la aplicarea prezentei reglementări tehnice. Rezultatele proceselor la orice nivel, fie structură, elemente software sau servicii software, pot fi elemente de intrare pentru aceleaşi procese utilizate la un nivel mai înalt sau mai jos.

4.7. Procesele acordului

Procesele acordului determină cerinţele pentru încheierea acordurilor cu unităţile organizaţionale, externe şi interne pentru organizaţie.

Notă:

Sub noţiunea de acord se subînţelege documentul care determină relaţiile între părţi şi însuşi obiectul acordului. Astfel de document poate fi acordul, ordinul, dispoziţia, etc.

Procesele acordului sînt:

a) procesul achiziţionării;

b) procesul furnizării.

Procesele acordului determină activităţile între două părţi - achizitor şi furnizor. Furnizorul aplică procesul de furnizare pentru organizarea proiectului, rezultat al căruia va fi furnizarea achizitorului produsului sau serviciului software. Achizitorul utilizează procesul achiziţionării pentru organizarea lucrărilor cu furnizorul, cu scopul obţinerii sistemului software sau a elementelor sale, suportului sistemului sau a altor servicii software.

4.7.1 Procesul achiziţionării

4.7.1.1 Scopul procesului achiziţionării

Scopul procesului achiziţionării constă în obţinerea produsului software sau a serviciului software în conformitate cu cerinţele achizitorului (beneficiarului).

4.7.1.2 Rezultatele procesului de achiziţionare

În rezultatul realizării reuşite a procesului de achiziţionare:

a) se determină strategia de achiziţionare;

b) se selectează (numeşte) furnizorul;

c) se determină legătura reciprocă cu furnizorul;

d) se încheie acord sau se adoptă un alt document pentru achiziţionarea produsului sau serviciului software;

e) se primeşte produsul software în conformitate cu acordul sau cerinţele faţă de sistem;

f) se oferă plata sau se îndeplineşte altă acţiune pentru finisarea procesului. 

4.7.2 Procesul furnizării

4.7.2.1 Scopul procesului furnizării

Scopul procesului furnizării constă în asigurarea achizitorului (beneficiarului) cu produs sau serviciu software în conformitate cu cerinţele aprobate.

4.7.2.2 Rezultatele procesului furnizării

a) se determină achizitorul (beneficiarul produsului sau serviciului software) concret;

b) se întocmeşte răspuns la interpelarea achizitorului;

c) se încheie acord sau se adoptă un alt document pentru furnizarea produsului sau serviciului software în conformitate cu criteriile de primire;

d) în conformitate cu condiţiile şi procedurile coordonate de furnizare, se furnizează produsul software, care corespunde acordului sau cerinţelor aprobate;

e) se transmite achizitorului responsabilitatea pentru produsul sau serviciul software achiziţionat;

f) se primeşte plata sau se îndeplineşte altă acţiune pentru finisarea procesului.

4.8 Procesele întreprinderii

Procesele întreprinderii dirijează capacitatea organizaţiei de a achiziţiona sau de a furniza produse sau servicii software prin iniţierea, mentenanţa şi managementul proiectelor. Aceste procese asigură resursele şi infrastructura, necesare pentru mentenanţa proiectelor şi executarea acordurilor încheiate.

Procesele întreprinderii sînt:

a) procesul de management al mediului întreprinderii;

b) procesul de management al investiţiilor;

c) procesul de management al proceselor ciclului de viaţă al sistemului software;

d) procesul de management al resurselor;

e) procesul de management al calităţii.

4.8.1 Procesul de management al mediului întreprinderii

4.8.1.1 Scopul procesului de management al mediului întreprinderii

Scopul procesului de management al mediului întreprinderii constă în determinarea şi susţinerea politicii şi procedurilor necesare pentru activitatea organizaţiei, conform prezentei reglementări tehnice.

4.8.1.2 Rezultatele procesului de management al mediului întreprinderii

Ca rezultat al realizării reuşite a procesului de management al mediului întreprinderii:

a) se formează politica şi procedurile de management al ciclului de viaţă al sistemului software, conform scopurilor întreprinderii;

b) se determină politica de adaptare a proceselor ciclului de viaţă al sistemului software, pentru satisfacerea necesităţilor şi cerinţelor acestui sistem;

c) se determină regulile de aplicare a proceselor ciclului de viaţă al sistemului software, precum şi metodologia de elaborare a sistemelor software;

d) se determină responsabilitatea şi împuternicirile la managementul ciclului de viaţă al sistemului software;

e) se determină politica şi procedurile de management al calităţii;

f) se formează politica de perfecţionare a proceselor ciclului de viaţă al sistemului software.

4.8.2  Procesul de management al investiţiilor 

4.8.2.1 Scopul procesului de management al investiţiilor

Scopul procesului de management al investiţiilor constă în iniţierea şi susţinerea proiectelor de investiţie, care asigură atingerea scopurilor sistemului software. Prin acest proces se realizează investirea fondurilor şi resurselor corespunzătoare ale organizaţiei şi se sancţionează organele necesare pentru instituirea proiectelor de investiţie alese. Prin acest proces se realizează controlul neîntrerupt asupra proiectelor, pentru motivarea investiţiilor.

4.8.2.2 Rezultatele procesului de management al investiţiilor

Ca rezultat al realizării reuşite a procesului de management al investiţiilor:

a) se determină şi se aleg posibilităţile sau necesităţile de investiţie;

b) se determină şi se distribuie resursele şi bugetele;

c) se determină responsabilitatea şi împuternicirile pentru managementul proiectelor de investiţii;

d) se întocmesc planurile de realizare a proiectelor;

e) se menţin proiectele, care corespund cerinţelor acordului persoanei sau organizaţiei interesate;

f) proiectele, care nu corespund cerinţelor acordului persoanei sau organizaţiei interesate, se întrerup sau se modifică.

4.8.3 Procesul de management al proceselor ciclului de viaţă al sistemului software

4.8.3.1 Scopul procesului de management al proceselor ciclului de viaţă al sistemului software

Scopul procesului de management al proceselor ciclului de viaţă al sistemului software constă în asigurarea existenţei proceselor eficiente ale ciclului de viaţă al sistemului software, pe care le utilizează organizaţia. Acest proces asigură realizarea proceselor ciclului de viaţă al sistemului software, care trebuie să corespundă scopurilor şi politicii organizaţiei. Procesele se determină, se adaptează şi se menţin în modul necesar, utilizînd metode şi instrumente eficiente şi verificate.

4.8.3.2 Rezultatele procesului de management al proceselor ciclului de viaţă al sistemului

Ca rezultat al realizării reuşite a procesului de management al ciclului de viaţă al sistemului:

a) se determină procesele ciclului de viaţă al sistemului, care trebuie să fie utilizate de organizaţie;

b) se determină metodologia de elaborare a sistemelor software;

c) se determină politica de aplicare a proceselor ciclului de viaţă al sistemului software, de adaptare la particularităţile proiectelor individuale;

d) se determină criteriile de evaluare a aplicării proceselor ciclului de viaţă al sistemului software.

4.8.4 Procesul de management al resurselor

4.8.4.1 Scopul procesului de management al resurselor

Scopul procesului de management al resurselor constă în asigurarea proiectelor cu resurse. Acest proces asigură resurse, materiale şi servicii concrete, sigure şi care se reînnoiesc, pentru mentenanţa proiectelor şi proceselor pe parcursul întregului ciclu de viaţă al sistemului software. Procesul include de asemenea oferirea personalului instruit, calificat şi cu experienţă, pentru îndeplinirea proceselor ciclului de viaţă.

Prin acest proces se asigură coordonarea eficientă şi utilizarea în comun a resurselor, informaţiei şi tehnologiilor.

4.8.4.2 Rezultatul procesului de management al resurselor

Ca rezultat al realizării reuşite a procesului de management al resurselor:

a) proiectele se asigură cu mijloace, materiale şi servicii necesare;

b) se rezolvă conflictele în punctele de joncţiune a cîtorva proiecte.

4.8.5 Procesul de management al calităţii

4.8.5.1 Scopul procesului de management al calităţii

Scopul procesului de management al calităţii constă în asigurarea corespunderii produsului software, serviciului şi utilizării proceselor ciclului de viaţă al sistemului software cu acordurile, planurile de proiect aprobate şi cerinţele beneficiarului.

4.8.5.2 Rezultatele procesului de management al calităţii

Ca rezultat al realizării reuşite a procesului de management al calităţii:

a) în cadrul organizaţiei, se creează sistemul calităţii, care asigură atingerea nivelelor calităţii de proiect necesare;

b) se oferă informaţie despre starea calităţii fiecărui proiect;

c) organizaţia (subdiviziunile) planifică şi îndeplineşte activităţile de management al sistemului calităţii pentru fiecare proiect, conform cerinţelor standardelor internaţionale ISO seria 9000.

4.9 Procesele proiectului

Procesele proiectului se utilizează pentru elaborarea şi dezvoltarea planificării proiectului, evaluarea realizărilor reale, controlul asupra îndeplinirii proiectului pînă la finisarea lui. Procesele separate ale proiectului pot fi utilizate oricînd pe parcursul ciclului de viaţă al sistemului software şi la orice nivel de ierarhie a proiectelor în conformitate cu cerinţele planurilor de proiect sau cu evenimente neprevăzute. Aplicarea proceselor proiectului poate depinde de riscurile şi complexitatea proiectului.

Procesele proiectului sînt:

a) procesul de planificare a proiectului;

b) procesul de evaluare a proiectului;

c) procesul de control al proiectului;

d) procesul de luare a deciziilor;

e) procesul de management al riscurilor;

f) procesul de management al configuraţiei;

g) procesul de management al informaţiei.

Notă:

Planificarea, evaluarea şi controlul sînt procese cheie ale oricărei activităţi practice de management al proiectului. Ele sînt prevăzute la administrarea oricărei întreprinderi, începînd de la organizaţie în întregime şi finisînd cu procesul separat al ciclului de viaţă al sistemului software şi cu activităţile lui.

4.9.1 Procesul de planificare a proiectului

4.9.1.1 Scopul procesului de planificare a proiectului

Scopul procesului de planificare a proiectului constă în crearea unui plan de proiect eficient şi capabil de funcţionare. În acest proces se determină cadrul activităţilor şi complexelor de lucrări, se stabilesc graficele desfăşurării acestor lucrări, inclusiv planurile calendaristice, precum şi se distribuie resursele pentru îndeplinirea complexului de lucrări.

Procesul de planificare a proiectului se realizează la toate etapele ciclului de viaţă al sistemului software şi se aplică tuturor proceselor. Planurile elaborate iniţial se concretizează la fiecare trecere la următoarea etapă sau proces, pînă la executarea lor completă sau pînă la întreruperea proiectului.

Conform obligaţiilor contractuale, partea responsabilă (organizaţia) trebuie să elaboreze planul de management al proiectului conform anexei 1 şi planul calendaristic de realizare a proiectului conform anexei 2. Ea trebuie să examineze şi să analizeze cerinţele sarcinii tehnice privind elaborarea sistemului software, pentru determinarea cadrului în care se realizează managementul şi asigurarea proiectului, precum şi gradul de implicare a beneficiarului. În caz de necesitate, se admite elaborarea altor planuri de proiect, aplicabile proceselor separate ale ciclului de viaţă al sistemului software.  

În caz de necesitate, în baza planului de management al proiectului, furnizorul poate încheia contract (acord) cu organizaţii externe (subantreprenori).

4.9.1.2 Rezultatele procesului de planificare a proiectului

Ca rezultat al realizării reuşite a procesului de planificare a proiectului:

a) se determină rolurile, responsabilitatea şi împuternicirile părţilor;

b) se elaborează şi se aprobă planul de management al proiectului;

c) se elaborează şi se aprobă planul calendaristic de realizare şi alte planuri de proiect necesare;

d) se interpelează formal resursele şi serviciile, necesare pentru îndeplinirea proiectului;

e) se determină criteriile pentru indicii realizării proiectului;

f) personalul proiectului trece instruirea (instructajul), în conformitate cu planul proiectului.

4.9.2 Procesul de evaluare a proiectului

4.9.2.1 Scopul procesului de evaluare a proiectului

Scopul procesului de evaluare a proiectului constă în determinarea stării proiectului. Prin acest proces se evaluează periodic progresul îndeplinirii planului de management al proiectului, planurilor tehnice şi scopurilor generale de antreprenor, determinate în alte planuri ale proiectului. La detectarea abaterilor substanţiale, informaţia despre ele se aduce la cunoştinţa părţilor interesate şi se întreprind acţiuni administrative.

4.9.2.2 Rezultatele procesului de evaluare a proiectului

Ca rezultat al realizării reuşite a procesului de evaluare a proiectului:

a) se acordă date despre executarea proiectului sau rezultatele evaluării lui;

b) se evaluează caracterul adecvat al rolurilor, drepturilor şi obligaţiunilor participanţilor la proiect;

c) se evaluează caracterul adecvat al resurselor şi serviciilor, necesare pentru îndeplinirea proiectului;

d) se analizează abaterile în indicii executării proiectului;

e) se informează părţile implicate despre starea proiectului.

4.9.3 Procesul de control al proiectului

4.9.3.1 Scopul procesului de control al proiectului

Scopul procesului de control al proiectului constă în managementul realizării proiectului în cadrul mijloacelor bugetare ale proiectului şi în satisfacerea cerinţelor lui tehnice. În anumite cazuri, acest proces poate modifica activităţile proiectului, pentru rectificarea abaterilor detectate la managementul proiectului sau în procesele tehnice. În caz de necesitate, modificările pot include planificarea repetată.

4.9.3.2 Rezultatele procesului de control al proiectului

Ca rezultat al realizării reuşite a procesului de control al proiectului:

a) se determină şi se direcţionează acţiunea de corecţie, dacă realizările proiectului nu corespund scopurilor planificate;

b) se iniţiază planificarea repetată a proiectului, dacă s-au modificat scopurile şi limitările proiectului sau ipotezele planificate s-au dovedit a fi nevalabile;

c) se sancţionează (sau nu) acţiunea de trecere a proiectului de la o etapă planificată la alta;

d) se ating scopurile proiectului.

4.9.4 Procesul de luare a deciziilor

4.9.4.1 Scopul procesului de luare a deciziilor

Scopul procesului de luare a deciziilor constă în alegerea unei căi mai avantajoase de dezvoltare a proiectului, dacă există alternative. Acest proces necesită luarea deciziei pentru atingerea rezultatelor stabilite, dorite sau optimizate, pe parcursul ciclului de viaţă al sistemului software. Se analizează acţiunile de alternativă, precum şi se alege şi se direcţionează cursul acestor acţiuni. Deciziile şi temeiul lor trebuie să fie înregistrate.

4.9.4.2 Rezultatele procesului de luare a deciziilor

Ca rezultat al realizării reuşite a procesului de luare a deciziilor:

a) se determină circumstanţele şi necesitatea luării deciziei;

b) se determină căile de alternativă pentru realizarea acţiunilor;

c) se alege desfăşurarea preferabilă a acţiunilor;

d) deciziile, temeiurile lor şi premisele se stochează şi se reprezintă în rapoarte.

4.9.5 Procesul de management al riscurilor

4.9.5.1 Scopul procesului de management al riscurilor

Scopul procesului de management al riscurilor constă în minimizarea influenţei evenimentelor nedeterminate posibile. Astfel de evenimente pot duce la majorarea costului sistemului software, întreruperea planurilor de proiect şi/sau înrăutăţirea caracteristicilor tehnice.

Procesul determină, evaluează şi efectuează managementul tuturor riscurilor pe parcursul întregului ciclu de viaţă al sistemului software, inclusiv riscurile care influenţează succesul proiectului, precum şi riscurile care apar în timpul utilizării produsului software.

Furnizorul este obligat să determine şi să analizeze riscurile specifice proiectului dat, să reducă la minimum influenţa lor şi să ia în consideraţie influenţele lor posibile în procesul de planificare a proiectului.

Riscurile, care influenţează proiectul se împart în patru categorii:

a) riscurile, legate cu cerinţele faţă de sistemul software, sînt cele mai periculoase şi constau în faptul că sistemul poate să nu corespundă cerinţelor beneficiarului;

b) riscurile tehnologice, legate cu capacitatea de funcţionare a elementelor sistemului, decizia de arhitectură şi colectarea componentelor variate într-un sistem unic;

c) riscurile, legate cu calificarea personalului, se determină prin experienţa şi profesionalismul colaboratorilor, implicaţi în proiect;

d) riscurile politice sînt legate cu politica corporativă a părţilor care interacţionează, precum şi cu particularităţile organizaţiilor şi activitatea subdiviziunilor componente.

4.9.5.2 Rezultatele procesului de management al riscurilor

Ca rezultat al realizării reuşite a procesului de management al riscurilor:

a) evaluarea riscurilor se realizează pe parcursul întregului ciclu de viaţă al sistemului software;

b) se determină şi se clasifică riscurile;

c) se determină cantitativ influenţa nefastă a riscurilor;

d) se determină măsurile de prevenire a riscurilor;

e) se determină strategia de management al fiecărui risc detectat;

f) se întreprind măsuri în ceea ce priveşte riscurile, care constituie problema;

g) se ţine evidenţa riscurilor şi a stării lor.

4.9.6 Procesul de management al configuraţiei

4.9.6.1 Scopul procesului de management al configuraţiei

Scopul procesului de management al configuraţiei constă în instalarea şi menţinerea actualităţii şi integrităţii tuturor produselor şi elementelor proiectului sau ale procesului.

4.9.6.2 Rezultatele procesului de management al configuraţiei

Ca rezultat al realizării reuşite a procesului de management al configuraţiei:

a) se determină strategia de management al configuraţiei;

b) se determină elementele, care necesită managementul configuraţiei;

c) se stabilesc bazele configuraţiei;

d) se urmăresc modificările în elementele configuraţiei;

e) se controlează emiterea elementelor configuraţiei;

f) informaţia despre statutul elementelor dirijate ale configuraţiei se asigură pe parcursul ciclului de viaţă al sistemului software.

4.9.7 Procesul de management al informaţiei

4.9.7.1 Scopul procesului de management al informaţiei

Scopul procesului de management al informaţiei constă în asigurarea părţilor implicate cu informaţie oportună, completă, autentică, confidenţială (dacă este necesar) pe parcursul ciclului de viaţă al sistemului software, şi în cazurile corespunzătoare - după el. Prin acest proces se creează, se colectează, se procesează, se stochează, se extrage, se răspîndeşte şi se utilizează informaţia, care se referă la produsul software. Acest proces gestionează toată informaţia, inclusiv informaţia tehnică şi de proiect, informaţia întreprinderii, acordurilor şi a utilizatorului.

4.9.7.2 Rezultatele procesului de management al informaţiei

Ca rezultat al realizării reuşite a procesului de management al informaţiei:

a) se determină toată informaţia supusă managementului;

b) se colectează, se stochează şi se urmăresc artefactele şi datele, primite ca rezultat al lucrărilor;

c) se determină formele de prezentare a informaţiei;

d) se înregistrează statutul informaţiei;

e) se menţine actualitatea, plenitudinea şi autenticitatea informaţiei;

f) informaţia se acordă părţilor implicate.

4.10 Procesele tehnice

Procesele tehnice se utilizează pentru determinarea necesităţii sistemului software, transformarea acestei necesităţi într-un produs software eficient, asigurarea reproducerii stabile a produsului software, atunci cînd este necesar, utilizarea produsului software cu scopul prestării serviciilor necesare, suportul prestării acestor servicii şi, atunci cînd produsul software este retras din serviciu, utilizarea acestui produs.

Procesele tehnice determină activităţile, care permit funcţiilor întreprinderii şi proiectului să optimizeze priorităţile sistemului software şi să micşoreze riscurile, care apar ca rezultat al soluţiilor şi acţiunilor tehnice. Aceste activităţi asigură atribuirea produselor şi serviciilor software a astfel de calităţi ca existenţa, oportunitatea, eficacitatea de cheltuială, funcţionalitatea, fiabilitatea, uşurinţa privind repararea, etalonarea, utilitatea şi un număr de alte calităţi, pe care le cer organizaţiile care achiziţionează şi livrează. De asemenea, ele asigură corespunderea produselor şi serviciilor software cu cerinţele legislative ale societăţii, inclusiv ocrotirea sănătăţii, securitatea, protecţia personalului şi factorii mediului înconjurător.

Procesele tehnice şi activităţile de bază, care finisează cu crearea artefactelor, se distribuie conform etapelor ciclului de viaţă al sistemului software, precum se indică în figura 5.

Fig.5 - Procesele tehnice ale ciclului de viaţă al sistemului software

4.10.1 Procesul de modelare conceptuală

4.10.1.1 Scopul procesului de modelare conceptuală

Scopul procesului de modelare conceptuală constă în acordarea părţilor interesate a modelului (viziunii generale) sistemului software (sau a unui grup de sisteme interconectate), a funcţiilor îndeplinite de el, descrierii spaţiului informaţional şi interacţiunile cu alte SIA externe.

Prin acest proces are loc examinarea domeniului de activitate în care va funcţiona sistemul software, analiza nivelului de informatizare a domeniului respectiv, se clarifică necesitatea şi scopurile creării sau modificării sistemului. La fel se examinează spaţiul juridico-normativ şi structura organizaţională, care realizează dirijarea domeniului respectiv. În caz de necesitate, se elaborează propuneri pentru actualizarea lor. În baza cunoştinţelor primite se alcătuieşte modelul de funcţionare a SIA.

Procesul dat poate fi iniţiat la indicaţia Preşedintelui şi a Guvernului, emiterea documentelor juridico-normative sau cerinţa beneficiarului SIA.

Furnizorul este responsabil pentru acţiunile din cadrul acestui proces. El trebuie să întocmească proiectul concepţiei şi să pregătească documentele necesare pentru coordonarea ei. Structura concepţiei sistemului - conform anexei 3.

Întocmirea, coordonarea şi aprobarea concepţiei se realizează în conformitate cu:

a) Legea Republicii Moldova privind actele normative ale Guvernului şi ale altor autorităţi ale administraţiei publice centrale şi locale nr.317-XV din 18.07.2003, "Monitorul oficial al Republicii Moldova" nr.208-210/783 din 03.10.2003

b) Hotărîrea Guvernului Republicii Moldova cu privire la modul de efectuare a expertizei juridice şi înregistrării de stat a actelor normative departamentale nr.1104 din 28.11.1997 "Monitorul Oficial al Republicii Moldova" nr.6-7/10 din 21.01.1998.

 4.10.1.2 Rezultatele procesului de modelare conceptuală

 Ca rezultat al realizării reuşite a procesului de modelare conceptuală:

a) sînt determinate scopul şi destinaţia SIA modelat;

b) este examinată baza juridico-normativă, structura organizaţională a managementului şi sînt elaborate propuneri privind actualizarea lor;

c) sînt determinate funcţionalitatea, obiectele şi fluxurile informaţionale, căile de integrare cu alte sisteme;

d) concepţia este întocmită, coordonată şi aprobată de către beneficiar.

4.10.1.3 Activităţile procesului de modelare conceptuală

Activităţile procesului respectiv se prezintă în figura 6.

  Fig.6 - Activităţile procesului de modelare conceptuală

4.10.2 Procesul de modelare aplicată

4.10.2.1 Scopul procesului de modelare aplicată

Scopul procesului de modelare aplicată constă în elucidarea destinaţiei sistemului software, nivelului de automatizare a acţiunilor beneficiarului sau ale SIA, procedeelor şi metodelor de primire, procesare şi stocare a informaţiei şi/sau îndeplinire a serviciilor software. Prin acest proces se creează descrierea versiunii produsului software propuse de furnizor, se indică modificările posibile ale infrastructurii utilizatorului, care asigură îndeplinirea proceselor - business necesare, în caz de necesitate se efectuează calculul preliminar al costului lui sau al cheltuielilor pentru realizare şi exploatare.

Furnizorul propune beneficiarului varianta descrisă a produsului software sub formă de propunere - business, conţinutul pe scurt al căreia este determinat în anexa 1.

Beneficiarul analizează varianta propusă a produsului software, aprobă propunerea-business şi o transmite furnizorului pentru lucrul ulterior de colectare a cerinţelor şi de analiză.

4.10.2.2 Rezultatele procesului de modelare aplicată

Ca rezultat al realizării reuşite a procesului de modelare aplicată:

a) este examinat domeniul de materii;

b) sînt determinate şi coordonate scopurile, destinaţia şi funcţionalitatea de bază a sistemului software;

c) este elaborat dicţionarul unic de termeni;

d) sînt determinate părţile interesate, precum şi organizaţiile care cooperează şi SIA străine;

e) sînt determinate procesele-business şi rolurile-business ale sistemului software;

f) este elaborată arhitectura prealabilă a sistemului software şi schema de circulaţie a informaţiei;

g) sînt aprobate artefactele şi transmise pentru lucrul ulterior.

4.10.2.3 Activităţile procesului de modelare aplicată

Activităţile procesului respectiv se prezintă în figura 7.

  Fig.7 - Activităţile procesului de modelare aplicată

4.10.3 Procesul de determinare a cerinţelor persoanei interesate

4.10.3.1 Scopul procesului de determinare a cerinţelor persoanei interesate

Scopul procesului de determinare a cerinţelor persoanei interesate constă în determinarea cerinţelor faţă de sistemul software, care trebuie să presteze serviciile cerute de beneficiar.

Prin acest proces se determină cerinţele beneficiarului, care se analizează şi se transformă în cerinţe acceptabile faţă de sistemul software. Cerinţele beneficiarului trebuie să includă necesităţile şi dorinţele tuturor părţilor, interesate în ciclul de viaţă al sistemului software. Cerinţele beneficiarului exprimă interacţiunea presupusă a sistemului software cu persoanele interesate şi sînt etalonul conform căruia se verifică funcţionalitatea produsului software şi capacitatea sa de a presta servicii.

În aceste scopuri, beneficiarul selectează reprezentantul său plenipotenţiar în proiect şi îl însărcinează cu funcţiile de luare a deciziei. Nivelul de participare a beneficiarului la elaborare poate fi stipulat în acord sau în planul de management al proiectului.

Prin acest proces se precizează, de asemenea, persoanele interesate sau grupurile de persoane interesate, implicate în sistemul software pe parcursul ciclului său de viaţă, şi se exprimă necesităţile, dorinţele şi aşteptările persoanelor interesate, împreună cu limitările aplicate de către aceste persoane şi de condiţiile de exploatare.

4.10.3.2 Rezultatele procesului de determinare a cerinţelor persoanei interesate

Ca rezultat al realizării reuşite a procesului de determinare a cerinţelor persoanei interesate:

a) sînt detaliate procesele-business, sînt determinate funcţiile-business ale proceselor şi este creat modelul artefactelor;

b) sînt specificate caracteristicile cerute ale sistemului software şi infrastructura utilizatorului, în care va fi utilizat;

c) sînt determinate limitările sistemului software şi ale elementelor lui;

d) s-a parvenit la observarea permanentă a cerinţelor persoanei interesate;

e) este determinată baza pentru analiza cerinţelor faţă de sistemul software;

f) este asigurată baza pentru negocierea şi coordonarea prestării serviciilor sau produsului.

4.10.3.3 Activităţile procesului de determinare a cerinţelor persoanei interesate

Activităţile procesului respectiv se prezintă în figura 8.

Fig.8 - Activităţile procesului de determinare a cerinţelor persoanei interesate

4.10.4 Procesul de analiză a cerinţelor

4.10.4.1 Scopul procesului de analiză a cerinţelor

Scopul procesului de analiză a cerinţelor faţă de software constă în transformarea cerinţelor persoanei interesate în viziunea tehnică asupra software-ului solicitat. Prin acest proces se creează ideea despre viitorul sistem software, care trebuie să satisfacă cerinţele persoanei interesate fără descrierea unei realizări concrete.

În cerinţele faţă de sistemul software sau faţă de servicii, se stabileşte ceea ce trebuie să facă sistemul software (serviciul) din punctul de vedere al elaboratorului, pentru a satisface cerinţele persoanei interesate. Aceste cerinţe pot fi funcţionale, cantitative sau calitative.

În baza analizei cerinţelor persoanei interesate, elaboratorul împreună cu beneficiarul elaborează sarcina tehnică.

Elaboratorul este obligat să indice în sarcina tehnică cerinţele stabilite faţă de sistemul software elaborat, inclusiv specificaţiile caracteristicilor calitative. Cerinţele definite în sarcina tehnică nu trebuie să limiteze elaboratorul în căutarea şi realizarea soluţiilor mai eficiente, dar pot stabili tehnologiile aplicabile şi metodologiile de elaborare. Structura sarcinii tehnice este indicată în anexa 4.

Sarcina tehnică se coordonează cu conducătorii organizaţiilor (subdiviziunilor), care participă la elaborare şi se aprobă de către beneficiar.

Beneficiarul este obligat să ia măsuri pentru adaptarea infrastructurii utilizatorului şi să adapteze activitatea lui la sistemul software elaborat, adică să ia decizie privind procesele - business supuse automatizării şi rolurile - business, care participă la proces. Aceste acţiuni la fel pot include adaptarea structurii scriptice, elaborarea documentaţiei organizatorice şi de dispoziţie, organizarea încăperilor necesare, achiziţionarea utilajului, organizarea instruirii colaboratorilor etc.

4.10.4.2 Rezultatele procesului de analiză a cerinţelor

Ca rezultat al realizării reuşite a procesului de analiză a cerinţelor:

a) sînt aprobate modelul proceselor - business şi funcţionalitatea sistemului, precum şi sînt stabilite caracteristicile necesare ale sistemului software;

b) sînt determinate limitările de proiect şi cerinţele de calificare faţă de sistemul software, precum şi cerinţele faţă de realizarea proiectului;

c) este stabilită baza pentru controlul permanent al realizării cerinţelor persoanei interesate;

d) este implementat sistemul de management al modificărilor;

e) este asigurată baza pentru adaptarea infrastructurii utilizatorului la cerinţele sistemului software;

f) sînt determinate cerinţele faţă de mijloacele tehnice şi soluţiile de reţea;

g) sînt aprobate artefactele şi transmise pentru lucrul ulterior.

4.10.4.3 Activităţile procesului de analiză a cerinţelor

Activităţile procesului respectiv se prezintă în figura 9.

Fig.9 - Activităţile procesului de analiză a cerinţelor

4.10.5 Procesul proiectării de structură

4.10.5.1 Scopul procesului proiectării de structură

Scopul procesului proiectării de structură constă în elaborarea soluţiei tehnice, care satisface cerinţele faţă de sistemul software.

Soluţiile proiectării de structură determină setul complet al elementelor de sistem viabile din punct de vedere tehnic şi comercial, din care se configurează sistemul software. Aceasta este baza pentru verificarea corespunderii sistemului software realizat, precum şi pentru planificarea şi elaborarea strategiei de asamblare şi testare.

Acest proces cuprinde acţiunile şi sarcinile elaboratorului. Elaboratorul dirijează acest proces la nivel de proiect, creează infrastructura procesului şi îl adaptează la cerinţele proiectului.

Soluţiile acestui proces se perfectează în proiectul tehnic. Proiectul tehnic este necesar pentru transformarea cerinţelor sarcinii tehnice în descrierea realizării modulelor concrete sau a elementelor sistemului software. Proiectul tehnic serveşte drept mijloc de comunicare între persoanele care participă la proiectarea şi realizarea sistemului software.

În baza proceselor-business şi modelelor elaborate descrise în sarcina tehnică, elaboratorul trebuie să creeze proiectul tehnic, care descrie structurile unui nivel mai inferior faţă de componentele sistemului software. Este necesar de elaborat arhitectura sistemului software şi schema lui structurală cu asocierile între elemente, de determinat interfeţele externe faţă de sistem şi între componentele sistemului însuşi. Conţinutul pe scurt al proiectului tehnic - în conformitate cu anexa 1.

Proiectul tehnic se coordonează cu managerul elaborării şi se aprobă de către conducătorul persoanelor responsabile, care participă la elaborarea proiectului tehnic.

În baza rezultatelor procesului respectiv, se determină strategia de realizare a sistemului software, care detaliază planul de elaborare.

4.10.5.2 Rezultatele procesului proiectării de structură

Ca rezultat al realizării reuşite a procesului proiectării de structură:

a) este determinată arhitectura sistemului software şi a elementelor lui;

b) pentru elementul de sistem proiectat, sînt stabilite metodele şi tehnologia de realizare în formă de descriere a specificaţilor, diagramelor, schemelor, procedurilor etc., care satisfac cerinţele specificate ale beneficiarului;

c) decizia de proiect este prezentată în conformitate cu sistemele software şi elementele sistemelor care interacţionează;

d) este determinată baza pentru verificarea corespunderii (testării) elementelor software;

e) este determinată baza pentru achiziţionarea sau asamblarea şi integrarea elementelor software;

f) este determinată consecutivitatea realizării funcţiilor sistemului software;

g) este aprobat proiectul tehnic.

4.10.5.3 Activităţile procesului proiectării de structură

Activităţile procesului respectiv se prezintă în figura 10.

Fig.10 - Activităţile procesului de proiectare de structură

4.10.6 Procesul de realizare

4.10.6.1 Scopul procesului de realizare

Scopul procesului de realizare constă în crearea sistemului software specificat. Prin acest proces, soluţia de proiect se transformă, în conformitate cu cerinţele beneficiarului, în acţiuni de creare, în rezultatul cărora, conform metodologiei alese de elaborare şi tehnologiilor de realizare, se creează produsul software. Sarcinile sistemului software, primit ca rezultat al creării sau adaptării, sînt satisfacerea pe deplin a cerinţelor proiectului de structură.

Procesul de realizare include acţiunile elaboratorului, privind crearea şi testarea sistemului software.

Elaboratorul trebuie să creeze (programeze) codul elementelor de program, gata pentru combinare în sistemul de lucru. Tehnologia şi metodologia de elaborare trebuie să fie coordonate cu furnizorul, iar metodele de programare - să corespundă limitărilor unanim acceptate. Elaboratorul este obligat să asigure textele elementelor software, scrise în limbajul de programare, cu comentarii suficiente pentru a înţelege tehnicile de realizare.

În procesul de programare, elaboratorul poate actualiza, modifica sau completa documentaţia proiectării tehnice, dacă aceasta nu contrazice sarcina tehnică.

Pe lîngă sistemul software, elaboratorul trebuie să elaboreze documentele stipulate în contract (acord) pentru utilizatorul final:

a) instrucţiunea de exploatare (a sistemului software sau a elementelor lui);

b) instrucţiunea administratorului (a sistemului software sau a elementelor lui);

Conţinutul pe scurt al documentelor - în conformitate cu anexa 1.

În procesul de realizare, trebuie să fie îndeplinită în mod obligatoriu activitatea de testare a elementelor software.

Elaboratorul trebuie să testeze fiecare element software, pentru a se convinge de capacitatea lor de funcţionare, funcţionalitatea deplină şi corespunderea cu sarcina tehnică. Acest tip de testare se realizează cu efortul elaboratorului şi se numeşte testare internă.

Activitatea privind testarea internă trebuie să fie neîntreruptă. Testele pentru verificarea elementelor software trebuie să fie create imediat, îndată ce aceste elemente sînt realizate în cod. Testul care a fost scris iniţial, trebuie să fie utilizat de multiple ori.

Rezultatul îndeplinirii testelor trebuie să fie lista de erori, care se introduce în procesul-verbal al testării. Conţinutul procesului-verbal al testării - în conformitate cu anexa 1.

Eficacitatea testării interne se asigură prin aplicarea a două metode de testare: testarea elementelor sistemului software de către elaboratorii nemijlociţi  şi testarea sistemului software prin teste realizate de persoane terţe.

Toate testele create în procesul de realizare a versiunii următoare se păstrează şi sînt aplicate la testarea versiunilor ulterioare.

4.10.6.2 Rezultatele procesului de realizare

Ca rezultat al îndeplinirii reuşite a procesului de realizare:

a) este determinată strategia de realizare şi metodologia de realizare;

b) sînt achiziţionate sau confecţionate elementele sistemului software;

c) este efectuată testarea elementelor şi a sistemului software în întregime;

d) în caz de necesitate, este asigurată certificarea produsului software sau sînt primite datele despre verificarea lui;

e) este pregătită documentaţia specificată;

f)sistemul software este livrat sau pus la păstrare, în conformitate cu contractul de livrare.

4.10.6.3 Activităţile procesului de realizare

Activităţile procesului respectiv se prezintă în figura 11.

Fig.11 - Activităţile procesului de realizare

4.10.7 Procesul de integrare

4.10.7.1 Scopul procesului de integrare

Scopul procesului de integrare constă în asamblarea sistemului software, în conformitate cu structura proiectului. Prin acest proces, elementele software se asamblează într-un sistem capabil de funcţionare cu configuraţie parţială sau completă, cu scopul creării produsului software prevăzut de cerinţele beneficiarului.

Configuraţia creată se înregistrează şi se prezintă beneficiarului pentru verificarea şi primirea ulterioară. În procesul ciclului de viaţă al sistemului software, procesul de integrare se poate petrece de multiple ori, la fiecare iteraţie, pînă la corespunderea completă cu cerinţele sarcinii tehnice.

4.10.7.2 Rezultatele procesului de integrare

Ca rezultat al realizării reuşite a procesului de integrare:

a) sînt determinate metodele de integrare a sistemului;

b) este asamblat şi integrat sistemul software, care poate fi verificat conform cerinţelor de proiect specificate şi aprobat conform aşteptărilor persoanei interesate;

c) este înregistrată versiunea sistemului software.

4.10.7.3 Activităţile procesului de integrare

Activităţile procesului respectiv se prezentă în figura 12.

Fig.12 - Activităţile procesului de integrare

4.10.8 Procesul de verificare

4.10.8.1 Scopul procesului de verificare

Scopul procesului de verificare constă în demonstrarea corespunderii caracteristicilor şi funcţionalităţii produsului software cu cerinţele specificate faţă de sistemul software, conform cărora a fost realizat produsul. Acest proces prezintă informaţia analitică necesară pentru realizarea acţiunilor de corecţie. Astfel de acţiuni sînt orientate spre corecţia necorespunderilor în sistemul/elementul software realizat sau în procesele care le influenţează.

Procesul de verificare începe după finisarea elaborării şi integrării sistemului software şi constă în planificarea şi efectuarea testării de calificare. Conţinutul planului calendaristic al testării de calificare - conform anexei 1. Elaboratorul este responsabil pentru acţiunile acestui proces.

În timpul testării de calificare se efectuează următoarele verificări:

a) testarea funcţională a produsului software privind corespunderea cu cerinţele sarcinii tehnice;

b) testarea sub sarcină, care imită sarcina asupra produsului software mai mari decît valorile maxime ale procesului de exploatare;

c) verificările valorilor de limită ale datelor de intrare, în cazul cărora sistemul software îşi modifică comportamentul;

d) comoditatea utilizării produsului software şi aspectul prietenos al interfeţei pentru utilizator;

e) analiza tehnologiilor aplicate, a algoritmilor şi a codului de program;

f) verificarea documentaţiei privind existenţa, conţinutul şi calitatea executării, precum şi corespunderea cerinţelor circularelor.

Conform rezultatelor testării de calificare, se întocmeşte procesul-verbal de testare. Conţinutul procesului-verbal de testare - în conformitate cu anexa 1.

Erorile şi observaţiile detectate în timpul testării de calificare se analizează de către furnizor şi elaborator în comun cu beneficiarul şi se clasează în trei grupe:

a) erori critice - erori, care au cauzat stoparea procesului tehnologic sau deranjament în funcţionarea programului;

b) erori moderate - erori, care cauzează incomoditate în lucru sau care au influenţă negativă asupra productivităţii sau securităţii sistemului, precum şi limitează funcţionalitatea sistemului (fără întreruperea procesului tehnologic) în cadrul sarcinii tehnice;

c) erorile procesului de proiectare - erorile sau observaţiile, care necesită extinderea sau modificarea funcţionalităţii sistemului software, care ies din limitele sarcinii tehnice.

După analiza problemelor sînt posibile următoarele decizii:

a) erorile primei grupe se înlătură pînă la predarea în exploatare experimentală, fapt pentru care se acordă timp suplimentar şi se corectează planul calendaristic. După înlăturarea erorilor primei grupe, produsul software trece repetat testarea de calificare;

b) erorile grupei a doua se înlătură în timpul exploatării experimentale;

c) observaţiile şi erorile grupei a treia se analizează de către furnizor şi elaborator în comun cu beneficiarul. Conform fiecărui punct al acestei grupe, se ia o decizie separată, care se perfectează printr-un proces-verbal comun al şedinţei. În baza deciziei comune, se încheie un nou acord (contract) sau se completează cel existent. Modificările sistemului software în cadrul noului acord (noii completări), trebuie să parcurgă ciclul de viaţă complet, conform prezentei reglementări tehnice.

În cazul lipsei erorilor critice şi observaţiilor, care nu permit începerea etapei de implementare, elaboratorul transmite sistemul software beneficiarului, pentru realizarea exploatării experimentale. Totodată, se întocmeşte act de predare în exploatare experimentală. Forma actului se prezintă în anexa 5.

4.10.8.2 Rezultatele procesului de verificare

Ca rezultat al realizării reuşite a procesului de verificare:

a) este realizată planificarea verificării;

b) sînt elaborate cerinţele de verificare, condiţiile de testare şi testele;

c) este realizată verificarea;

d) este prezentată informaţia analitică despre necorespunderi, pentru realizarea acţiunilor de corecţie;

e) este încheiat un nou acord sau sînt prezentate dovezi privind corespunderea produsului cu cerinţele de sistem;

f) este perfectată predarea produsului software la etapa de implementare.

4.10.8.3 Activităţile procesului de verificare

Activităţile procesului respectiv se prezintă în figura 13.

Fig.13 - Activităţile procesului de verificare

4.10.9  Procesul de aprobare

4.10.9.1 Scopul procesului de aprobare

Scopul procesului de aprobare constă în prezentarea dovezii obiective despre faptul că serviciile prestate de produsul software elaborat sau de orice element software, corespund cerinţelor aprobate faţă de sistemul software şi necesităţilor persoanelor interesate.

Activităţile procesului de aprobare iniţiază de obicei realizarea exploatării experimentale. Exploatarea experimentală a produsului software acordă informaţie despre comportamentul sistemului în mediul real de exploatare, cu utilizarea datelor reale. Exploatarea experimentală este necesară pentru familiarizarea utilizatorului cu produsul software implementat şi detectarea devierilor în funcţionarea lui.

În procesul de aprobare se efectuează evaluarea comparativă şi se confirmă că au fost realizate corect cerinţele persoanelor interesate faţă de sistemul software. La detectarea devierilor, ele se înregistrează şi se realizează acţiunile de corecţie.

Toate devierile în funcţionare şi observaţiile (în cadrul sarcinii tehnice), detectate în timpul exploatării experimentale, se înlătură de către elaborator pînă la finisarea exploatării experimentale. În caz de necesitate, se corectează planul calendaristic.

Aprobarea produsului software se confirmă de către persoanele interesate prin semnarea actului de finisare a elaborării. Forma actului-conform anexei 6. Aprobarea actului trebuie să fie realizată de către părţi conform proceselor contractuale. În baza actului de finisare a elaborării începe activitatea de instalare a produsului software la locurile funcţionării lui.

4.10.9.2 Rezultatele procesului de aprobare

Ca rezultat al realizării reuşite a procesului de aprobare:

a) este elaborat planul de realizare a exploatării experimentale;

b) sînt înlăturate necorespunderile detectate;

c) este confirmată existenţa serviciilor software, cerute de persoanele interesate;

d) în darea de seamă sînt reflectate rezultatele procesului de aprobare;

e) produsul software este transmis pentru instalare sau expediat pentru definitivare.

4.10.9.3 Activităţile procesului de aprobare

Activităţile procesului respectiv se prezintă în figura 14.

Fig.14 - Activităţile procesului de aprobare

4.10.10 Procesul de trecere

4.10.10.1 Scopul procesului de trecere

Scopul procesului de trecere constă în asigurarea capacităţii produsului software de a presta serviciile prevăzute de cerinţele beneficiarului. Prin acest proces se realizează instalarea produsului software aprobat la locurile funcţionării lui şi lansarea SIA în cadrul celor stipulate în acord (contract). Planul calendaristic al procesului de trecere se elaborează de către părţile interesate şi se aprobă de către beneficiar. Forma planului se prezintă în anexa 2. Lucrările etapei de trecere pot fi stipulate într-un acord (contract) separat.

Este posibilă instalarea pe etape a produsului software. De exemplu, în locurile limitate ale funcţionării lui, pentru realizarea exploatării experimentale sau pe măsura dezvoltării SIA în subdiviziunile teritoriale.

În timpul procesului de trecere este posibilă funcţionarea simultană a sistemului software existent şi a celui implementat. În acest caz, este necesar de asigurat trecerea la noul produs software şi, la cererea beneficiarului, de realizat trecerea datelor conform acordului (planului lucrărilor), asigurînd totodată integritatea lor.

Procesul de trecere se finisează cu îndeplinirea obligaţiunilor contractuale de către elaborator, dar instalarea poate continua pe tot parcursul exploatării produsului software. Finisarea procesului de trecere se confirmă prin actul de predare în exploatare a produsului software. Aprobarea actului trebuie să fie realizată conform obligaţiunilor contractuale. Forma actului - conform anexei 7.

4.10.10.2 Rezultatele procesului de trecere

Ca rezultat al realizării reuşite a procesului de trecere:

a) este elaborat planul calendaristic al procesului de trecere;

b) produsul software este instalat la locurile funcţionării lui;

c) sistemul software este aprobat în conformitate cu cerinţele beneficiarului;

d) este înregistrată configuraţia sistemului instalat;

e) este realizată convertirea sau transferul datelor;

f) finisarea procesului este confirmată prin actul de predare în exploatare.

4.10.10.3 Activităţile procesului de trecere

Activităţile procesului respectiv se prezintă în figura 15.

Fig.15 - Activităţile procesului de trecere

4.10.11 Procesul de exploatare

4.10.11.1 Scopul procesului de exploatare

Scopul procesului de exploatare constă în utilizarea produsului software pentru primirea serviciilor şi acordarea suportului operaţional utilizatorilor. Începutul exploatării se stabileşte de către utilizator în baza actului de punere în exploatare. Forma actului - conform anexei 1. Utilizatorul este responsabil pentru acţiunile din cadrul procesului respectiv.

Utilizatorul dirijează procesul de exploatare la nivel de proiect, creează infrastructura acestui proces, o adaptează la cerinţele proiectului.

Prin procesul de exploatare, utilizatorul controlează primirea serviciilor de la produsul software, evaluează interacţiunea dintre utilizatorii nemijlociţi şi sistemul software, precum şi acordă consultaţii utilizatorilor nemijlociţi şi pregăteşte cadrele. Pentru menţinerea procesului de primire a serviciilor software, problemele detectate în timpul exploatării trebuie să fie înregistrate şi analizate. După analiză, utilizatorul expediază interpelările utilizatorului nemijlocit către persoana de mentenanţă a produsului software. Propunerile şi interpelările se perfectează în formă de propuneri de modificare sau mesaje despre problemă. Forma acestor documente - conform anexei 1. Toate interpelările trebuie să fie observate pînă la finisarea lor. Interacţiunea dintre utilizator şi persoana de mentenaţă trebuie să fie determinată de procesele acordului.

4.10.11.2 Rezultatele procesului de exploatare

Ca rezultat al realizării reuşite a procesului de exploatare:

a) sînt determinate şi aplicate procedurile de exploatare;

b) se prestează servicii software, care corespund necesităţilor persoanei interesate;

c) se îndeplinesc cu succes interpelările pentru realizarea acţiunilor de corecţie aprobate;

d) sînt satisfăcute interesele utilizatorilor.

4.10.11.3 Activităţile procesului de exploatare

Activităţile procesului respectiv se prezintă în figura 16.

  Fig.16 - Activităţile procesului de exploatare

4.10.12 Procesul de mentenanţă

4.10.12.1 Scopul procesului de mentenanţă

Scopul procesului de mentenanţă constă în menţinerea capacităţii sistemului software de a presta servicii, precum şi modificarea produsului software, păstrînd integritatea lui. Prin acest proces se controlează funcţionarea produsului software, se înregistrează problemele pentru analiză în jurnalul de evidenţă a adresărilor, se întreprind acţiuni de prevenire şi de corecţie, precum şi acţiuni de adaptare şi perfecţionare a produsului software. Lista rubricilor jurnalului-conform anexei 1.

Procesul de mentenanţă constă în modificarea textului sau ajustărilor programului şi a documentelor corespunzătoare, ca urmare a problemelor detectate (necorespunderilor) sau a necesităţii de a perfecţiona sistemul software.

Procesul de mentenanţă este dirijat de către persoana de mentenanţă a produsului software la nivel de proiect. El trebuie să organizeze dirijarea procesului, să creeze infrastructura procesului şi să adapteze procesul la cerinţele proiectului concret în cadrul relaţiilor contractuale.

Procesul dat include următoarele acţiuni:

- pregătirea procesului de mentenanţă;

- analiza problemelor şi modificărilor;

- introducerea modificărilor;

- verificarea şi primirea pentru mentenanţă;

- trecerea (transferul).

4.10.12.2 Rezultatele procesului de mentenanţă

Ca rezultat al realizării reuşite a procesului de mentenanţă:

a) se elaborează concepţia şi planul de mentenanţă;

b) sînt determinate limitările de deservire, care influenţează asupra mentenanţei;

c) se achiziţionează elemente de sistem de schimb;

d) se menţin serviciile, care satisfac cerinţele persoanei interesate;

e) se realizează analiza problemei şi se ia decizie;

f) se realizează modificarea produsului software, cu testarea şi punerea în exploatare ulterioară.

Structura concepţiei mentenanţei produsului software-conform anexei 8. Structura planului de mentenanţă-conform anexei 9.

4.10.12.3 Activităţile procesului de mentenanţă

Activităţile procesului respectiv se prezintă în figura 17.

Fig.17 - Activităţile procesului de mentenanţă

4.10.13 Procesul de retragere

4.10.13.1 Scopul procesului de retragere

Scopul procesului de retragere constă în încetarea existenţei sistemului software. Prin acest proces se realizează scoaterea sistemului software din exploatare, elaborarea şi înlăturarea sistemului software şi a elementelor lui. Retragerea produsului software din exploatare poate la fel să fie iniţiată de expirarea termenului licenţei pentru exploatarea produsului dat sau de rugămintea beneficiarului. Persoana de mentenanţă este responsabilă de activităţile procesului de retragere.

Dacă retragerea este iniţiată de posesor, atunci este necesară realizarea analizei, care confirmă decizia privind retragerea produsului software din exploatare. Ca regulă, o astfel de decizie trebuie să fie justificată economic.

Persoana de mentenanţă, care realizează retragerea produsului software din exploatare, trebuie să rezolve următoarele probleme: elaborarea planului calendaristic de retragere din exploatare, înştiinţarea utilizatorilor şi a tuturor subiecţilor interesaţi despre retragerea produsului software din exploatare şi arhivarea datelor corespunzătoare. Forma planului calendaristic de retragere - în conformitate cu anexa 2.

Posesorul determină modul şi locul stocării elementelor şi datelor software scoase din exploatare.

Procesul de retragere se finisează cu întocmirea actului de trecere la pierderi a produsului software, conform anexei 1.

4.10.13.2 Rezultatele procesului de retragere

Ca rezultat al realizării reuşite a procesului de retragere:

a) este elaborat planul calendaristic al retragerii din exploatare;

b) părţilor interesate le sînt trimise înştiinţări despre intenţiile privind retragerea din exploatare;

c) sînt nimicite sau stocate elementele software;

d) este salvată informaţia primită ca rezultat al creării şi exploatării sistemului;

e) retragerea este confirmată de actul de trecere la pierderi.

4.10.13.3 Activităţile procesului de retragere

Activităţile procesului respectiv se prezintă în figura 18.

Fig.18 - Activităţile procesului de retragere

5. METODELE DE ELABORARE A SISTEMULUI SOFTWARE

Elaboratorul alege metoda de elaborare în dependenţă de complexitatea sistemului software, nivelele de participare a beneficiarului şi termenele stabilite de realizare a proiectului. Metoda de bază de elaborare a sistemului software este cea iteraţională, structura căreia se prezintă în figura 19.

Metoda iteraţională de elaborare a sistemului software este metoda, în cazul căreia determinarea cerinţelor, analiza, proiectarea, programarea, integrarea şi verificarea se realizează treptat, în timpul elaborării sistemului software. Metoda iteraţională presupune colaborarea strînsă a beneficiarului cu elaboratorul, în timpul creării sistemului software. Metoda iteraţională se caracterizează prin punerea rapidă în exploatare a produsului software cu posibilităţile limitate (de bază), pe care le determină însăşi beneficiarul, cu adăugarea treptată a celorlalte funcţii, fără a întrerupe exploatarea produsului software. Metoda iteraţională trebuie să fie metoda de bază a elaborării sistemelor software.

Fig.19 - Structura metodei iteraţionale de elaborare a sistemului software

Fazele de elaborare a sistemului software în cazul metodei iteraţionale de elaborare sînt:

a) analiza;

b) versiunea;

c) iteraţia;

d) exploatarea.

Fazele se repetă la fiecare etapă de elaborare a sistemului software.

5.1  Analiza

Elaboratorul, în comun cu beneficiarul, analizează sistemul software elaborat, determină ce posibilităţi şi funcţii trebuie el să posede pe măsura realizării lui.

În baza analizei efectuate, elaboratorul creează modelul de realizare în formă de "Lista funcţiilor" cu descrierea lor pe scurt, în conformitate cu anexa 10. Lista poate fi completată şi precizată pe măsura realizării sistemului software.

Fiecare element al listei trebuie să fie definit ca funcţie (element) finisată şi independentă, care poate fi testată şi poate fi evaluată capacitatea sa de funcţionare. În baza evaluărilor generale se determină timpul necesar pentru elaborarea, testarea şi lansarea în exploatare a funcţiei descrise. 

5.2 Versiunea

La abordarea incrementală, beneficiarul alege din lista de funcţii una sau cîteva funcţii primordiale, posibil, legate logic între ele, care se elaborează şi se lansează în exploatare în primul rînd. Acest grup de funcţii se uneşte în versiune. Celelalte funcţii se realizează mai tîrziu, în următoarele versiuni.

Beneficiarul determină următoarea versiune incrementală a sistemului software, alegînd cele mai valoroase funcţii din punctul său de vedere. Valoarea funcţiilor se determină prin riscuri, cheltuieli materiale sau temporale pentru realizarea lor.

În baza alegerii făcute de beneficiar se distribuie lucrările între executanţii concreţi şi se întocmeşte planul calendaristic de realizare a versiunii, conform anexei 1, sau se completează planul calendaristic de realizare.

5.3 Iteraţia

Scopul fiecărei iteraţii este lansarea în exploatare a unei sau a cîtorva funcţii noi testate şi gata pentru utilizare.

Iteraţiile sînt incrementale în conformitate cu acea funcţie pe care o îndeplinesc. Fiecare iteraţie adaugă construcţii următoare la posibilităţile sistemului software, realizate în timpul iteraţiilor precedente.

La fiecare iteraţie, o anumită parte a codului existent poate fi creată din nou, cu scopul de a-l face mai flexibil. Totodată poate apărea necesitatea de a realiza reorganizarea.

Reorganizarea trebuie îndeplinită în următoarele cazuri:

a) dacă la extinderea funcţionalităţii sistemului software sînt detectate probleme cu codul existent sau cu metoda de realizare;

b) dacă codul sau structura sistemului software devin greu de înţeles.

În timpul iteraţiei, beneficiarul elaborează criteriile testelor pentru funcţia realizată. În baza acestui fapt, elaboratorul realizează testele în formă de module finite  şi creează condiţiile necesare pentru testare. La finele iteraţiei, testele trebuie să funcţioneze.

Iteraţia se finisează cu exploatarea experimentală a sistemului software, care poate fi realizată la toate locurile de muncă sau la un număr limitat de locuri de muncă ale utilizatorilor. La îndeplinirea exploatării experimentale se utilizează date reale. Informaţia primită şi prelucrată la etapa exploatării experimentale poate fi eliminată sau utilizată ulterior la decizia beneficiarului.

5.3.1 Sarcina

Elaboratorul clasifică funcţiile în sarcini - elemente software, realizate în termene minime. Sarcinile se distribuie între elaboratori concreţi. În dependenţă de complexitatea sarcinilor, timpul pentru elaborarea lor poate fi redistribuit între executanţi.

Pe măsura finisării sarcinilor, codul lor se integrează în funcţia finisată şi se testează de către elaborator. În caz de rezultat negativ al testului, funcţia se împarte din nou în sarcini şi se verifică realizarea lor.

Dacă testarea funcţiei separate a reuşit, codul se integrează în sistemul general şi se testează în baza testelor sau condiţiilor de testare descrise de către beneficiar. În cazul cînd testarea nu a reuşit, codul se trimite la definitivare. La testarea întregului sistem software, trebuie să funcţioneze toate testele, elaborate anterior pentru alte iteraţii.

Realizarea sarcinilor se îndeplineşte în procesul iteraţiei, în conformitate cu figura 20. Concomitent pot fi elaborate cîteva sarcini. Scopul la îndeplinirea sarcinii este concentrarea la detalii şi realizarea problemei concrete.

După precizarea obiectului şi metodelor de realizare, sarcina se realizează în cod şi paralel se creează testele sau condiţiile de testare a sarcinii.

Sarcina finită se testează de către elaboratori cu ajutorul testelor sau condiţiilor de testare create.

Fig.20 - Structura realizării sarcinii

5.4  Exploatarea

În cazul metodei iteraţionale de elaborare, produsul software se poate afla în exploatare imediat după finisarea realizării primii versiuni a produsului software.

Fiecare versiune ulterioară completează funcţionalitatea produsului software, pînă la realizarea completă a cerinţelor beneficiarului. După aceasta, elaborarea se finisează şi începe exploatarea complet funcţională a produsului software.

6. DOCUMENTAŢIE

În procesul ciclului de viaţă al sistemului software, cu fiecare proces sînt legate artefacte, care se prezintă la intrarea sau se primesc la ieşirea procesului dat. Artefactele primite se utilizează ca date iniţiale pentru activitatea ulterioară. Ele conţin date informative despre proiect sau se prezintă în rol de componente furnizate prin contract.

Unul din tipurile de bază de artefacte este documentaţia proiectului.

Documentaţia este rezultatul înregistrării informaţiei primite pe parcursul acţiunilor sau proceselor ciclului de viaţă al sistemului software.

Conţinutul documentelor elaborate trebuie să corespundă anexelor prezentelor reglementări tehnice.

Indicativele documentelor se atribuie în conformitate cu figura 21.

Perfectarea documentelor trebuie să corespundă cerinţelor SM 1-5:2005 "Principiile şi metodologia standardizării. Structura, redactarea şi conţinutul standardelor moldovene.".

Fig.21 - Structura indicativului documentelor

Explicaţii la figura 21:

a) identificatorii SIA şi subsistemului se atribuie de către Ministerul Dezvoltării Informaţionale şi reprezintă numărul lor de evidenţă în Registrul de stat al resurselor şi sistemelor informaţionale;

b) numărul elementului în sistemul software se atribuie de către elaborator.

c) codul documentului se atribuie conform anexei 1;

d) numărul părţii documentului se atribuie de către elaborator;

e) versiunea redactării documentului se atribuie de către elaborator;

f) numărul completării se atribuie de către elaborator.

Documentele pot fi puse la dispoziţie sau difuzate pe hîrtie sau în formă electronică.

Lista documentelor necesare produsului software se determină la etapa de elaborare, în procesul determinării şi analizei cerinţelor beneficiarului.

7. DISPOZIŢII FINALE ŞI TRANZITORII

Prezenta reglementare tehnică se aplică la elaborarea sistemelor informaţionale automatizate noi şi reengineering-ul celor active. După implementarea prezentei reglementări tehnice, vor fi revizuite standardele naţionale în domeniul tehnologiilor informaţionale.

Prezenta reglementare tehnică intră în vigoare după 30 de zile din data publicării.

Pînă la intrarea în vigoare a prezentei reglementări tehnice, cerinţele standardelor naţionale pentru procesele ciclului de viaţă al software-ului îşi păstrează caracterul obligatoriu.

Fig.1 - Schema structurală a ST

Fig.2 - Schema circulaţiei fluxurilor informaţionale

   Fig.3 - Schema stărilor obiectului

Fig.4 - Diagrama rolurilor-business

  Fig.5 - Scenariul îndeplinirii serviciului (varianta 1)

  Fig.6 - Scenariul îndeplinirii serviciului (varianta 2)

Fig.7 - Aspectul exterior al diagramei funcţiilor-business

Fig.8 - Aspectul exterior al diagramei scenariului reuşit