ID intern unic: 316454
Версия на русском
Republica Moldova
din 01.06.2006
cu privire la aprobarea reglementării tehnice "Procesele ciclului
de viaţă al software-ului"RT 38370656 - 002:2006
de viaţă al software-ului"RT 38370656 - 002:2006
Î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-ulu i" 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".
MINISTRUL
DEZVOLTĂRII INFORMAŢIONALE Vladimir MOLOJEN
Chişinău, 1 iunie 2006.
Nr. 78.
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 trebuiesc î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 sunt 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 sunt î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:
3.PĂRŢILE CARE PARTICIPĂ LA CICLUL DE VIAŢĂ
AL SISTEMULUI SOFTWARE
AL SISTEMULUI SOFTWARE
În prezenta reglementare tehnică, termenii "organizaţie" şi "parte" sunt 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, sunt acelea, care iniţiază sau execută dezvoltarea, utilizarea sau mentenanţa produselor software.
Părţi de bază sunt:
b) achizitorul (beneficiarul);
c) furnizorul;
d) elaboratorul;
e) personalul de mentenanţă;
f) 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.
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.1 Etape
Sistemele software examinate în prezenta reglementare tehnică sunt 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.
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 sunt 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.1.1Etapa 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 sunt 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.1.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 sunt 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 sunt responsabile de realizarea etapelor ulterioare.
Elemente de ieşire ale etapei de elaborare sunt 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 sunt 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 sunt 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 sunt 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ţă sunt 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 sunt 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.
Î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.
Tabelul 1 Procesele ciclului de viaţă al sistemului software
| Grupul | Denumirea procesului |
| Procesele acordului | Procesul de achiziţie |
| Procesul de livrare | |
| Procesele întreprinderii | Procesul de management al mediului întreprinderii |
| Procesul de management al investiţiilor | |
| Procesul de management al proceselor ciclului de viaţă al sistemului software | |
| Procesul de management al resurselor | |
| Procesul de management al calităţii | |
| Procesele proiectului | Procesul de planificare a proiectului |
| Procesul de evaluare a proiectului | |
| Procesul de control al proiectului | |
| Procesul de luare a deciziilor | |
| Procesul de management al riscurilor | |
| Procesul de management al configuraţiei | |
| Procesul de management al informaţiei | |
| Procesele tehnice | Procesul de modelare conceptuală |
| Procesul de modelare aplicată | |
| Procesul de determinare a cerinţelor persoanei interesate | |
| Procesul de analiză a cerinţelor | |
| Procesul proiectării de structură | |
| Procesul de realizare | |
| Procesul de integrare | |
| Procesul de verificare | |
| Procesul de aprobare | |
| Procesul de trecere | |
| Procesul de exploatare | |
| Procesul de mentenanţă | |
| Procesul de retragere |
În prezenta reglementare tehnică sunt 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.
Î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 sunt:
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 sunt:
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 sunt:
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 sunt procese cheie ale oricărei activităţi practice de management al proiectului. Ele sunt 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, sunt 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 sunt 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.
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) sunt determinate scopul şi destinaţia SIA modelat;
b) este examinată baza juridico-normativă, structura organizaţională a managementului şi sunt elaborate propuneri privind actualizarea lor;
c) sunt 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.
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) sunt determinate şi coordonate scopurile, destinaţia şi funcţionalitatea de bază a sistemului software;
c) este elaborat dicţionarul unic de termeni;
d) sunt determinate părţile interesate, precum şi organizaţiile care cooperează şi SIA străine;
e) sunt 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) sunt 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.
4.10.2 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 sunt 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) sunt detaliate procesele-business, sunt determinate funcţiile-business ale proceselor şi este creat modelul artefactelor;
b) sunt specificate caracteristicile cerute ale sistemului software şi infrastructura utilizatorului, în care va fi utilizat;
c) sunt 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.
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) sunt aprobate modelul proceselor - business şi funcţionalitatea sistemului, precum şi sunt stabilite caracteristicile necesare ale sistemului software;
b) sunt 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) sunt determinate cerinţele faţă de mijloacele tehnice şi soluţiile de reţea;
g) sunt 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.
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, sunt 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.
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, sunt 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 sunt 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 sunt 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) sunt 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 sunt 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.
4.10.6 Procesul de integrare
4.10.6.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.6.2 Rezultatele procesului de integrare
Ca rezultat al realizării reuşite a procesului de integrare:
a) sunt 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.
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 sunt 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 sunt 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) sunt 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 sunt 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.
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) sunt înlăturate necorespunderile detectate;
c) este confirmată existenţa serviciilor software, cerute de persoanele interesate;
d) în darea de seamă sunt 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.
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.
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) sunt 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) sunt satisfăcute interesele utilizatorilor.
4.10.11.3 Activităţile procesului de exploatare
Activităţile procesului respectiv se prezintă în figura 16.
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) sunt 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.
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 sunt trimise înştiinţări despre intenţiile privind retragerea din exploatare;
c) sunt 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.
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.
Fazele de elaborare a sistemului software în cazul metodei iteraţionale de elaborare sunt:
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 sunt 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 sunt 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.
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 sunt 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." .
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.
Anexa 1
la RT 38370656 - 002:2006
LISTA ŞI CONŢINUTUL PE SCURT A DOCUMENTELOR
PROCESELOR TEHNICE ALE CICLULUI DE VIAŢĂ AL
SISTEMULUI SOFTWARE
PROCESELOR TEHNICE ALE CICLULUI DE VIAŢĂ AL
SISTEMULUI SOFTWARE
Tabelul 1
| Nr.crt | Codul documentului | Titlul documentului | Conţinutul pe scurt al documentului |
| 1 | P1 | Plan de management al proiectului | 1 Părţile care participă la elaborare şi reprezentanţii lor plenipotenţiari 2 Împuternicirea şi responsabilitatea părţilor, inclusiv organizaţiile externe 3 Conducătorii proiectului. Managementul elaborării şi implementării proiectului 4 Dirijarea cu subantreprenorul, dacă există* 5 Completarea cu cadre şi resurse materiale* 6 Determinarea proceselor de bază pe etape. Termenele de elaborare, implementare, începere a exploatării* 7 Componenţa proiectului şi determinarea complexităţii lui 8 Modul testării de calificare a sistemului software* 9 Sancţiunile, specificaţiile necesare, de proprietate, drepturile de garanţie şi de licenţă, baza juridică a proiectului* 10 Instruirea personalului* |
| 2 | P2 | Plan calendaristic de realizare a proiectului | Conform anexei 2. NOTĂ: - planul se coordonează cu beneficiarul şi se aprobă de către furnizor; - se poate de îndeplinit în Microsoft Project |
| 3 | C1 | Concepţia sistemului | Conform anexei 3 |
| 4 | PB | Propunerea-business | 1 Generalităţi, destinaţia şi scopurile creării sistemului software 2 Referinţe* 3 Terminologie şi abrevieri* 4 Descrierea domeniului de automatizare 5 Modelul-business al domeniului de automatizare 6 Posibilităţile funcţionale ale sistemului 7 Arhitectura sistemului şi interacţiunea cu sistemele externe* 8 Perspectivele dezvoltării sistemului |
| 5 | ST | Sarcina tehnică | Conform anexei 4 |
| 6 | PT | Proiect tehnic | 1 Introducere 2 Referinţe* 3 Terminologie şi abrevieri* 4 Descrierea tehnologiei şi metodelor de realizare 5 Descrierea arhitecturii sistemului software şi a elementelor lui 6 Descrierea modelului de interacţiune a elementelor 7 Descrierea structurilor datelor, claselor, interfeţelor, artefactelor 8 Descrierea algoritmilor de procesare a informaţiei* 9 Descrierea structurii interfeţei pentru utilizator* 10 Completarea informaţională a clasificatoarelor* |
| 7 | IE | Instrucţiune de exploatare (a produsului software sau a elementelor lui) | 1Destinaţia 2Terminologie şi abrevieri* 3 Descrierea formelor ecranului şi a ferestrelor de dialog* 4 Descrierea interpelărilor, documentelor de ieşire, rapoartelor şi graficelor formate* 5 Descrierea modului de lucru |
| 8 | IA | Instrucţiunea administratorului(a produsului software sau a elementelor lui) | 1 Introducere 2 Terminologie şi abrevieri* 3 Cerinţe faţă de hardware 4 Setul de livrare. Modulele suplimentare necesare, bibliotecile şi software-ul producătorilor străini, versiunile lor admisibile 5 Instrucţiune de instalare6 Descrierea ajustărilor* 7 Lista mesajelor de bază şi acţiunile referitoare la ele* |
| 9 | - | Proces-verbal de testare | 1 Tipul de testare 2 Data realizării testării 3 Locul realizării testării* 4 Denumirea produsului sau a elementului software 5 Componenţa testărilor efectuate sau referinţă la planul de testare* 6 Descrierea erorilor (problemelor) 7 Grupul erorii 8 Locul manifestării erorii 9 Bifare cu privire la rectificare* 10 Note* 11 Semnăturile persoanelor, care participă la testare |
| 10 | P4 | Plan calendaristic al testării de calificare | Conform anexei 2.NOTĂ: - planul se coordonează cu beneficiarul şi se aprobă de către furnizor; - poate fi îndeplinit în Microsoft Project |
| 11 | - | Act de predare în exploatare experimentală | Conform anexei 5.NOTĂ: - actul se elaborează de către furnizor şi se aprobă de către beneficiar sau conform obligaţiunilor contractuale |
| 12 | - | Act de finisare a elaborării | Conform anexei 6.NOTĂ: - actul se elaborează de către furnizor şi se aprobă de către beneficiar sau conform obligaţiunilor contractuale |
| 13 | P6 | Plan calendaristic al procesului de trecere | Conform anexei 2.NOTĂ: - planul se elaborează de către elaborator şi se aprobă de către beneficiar; - poate fi îndeplinit în Microsoft Project |
| 14 | - | Act de predare în exploatare | Conform anexei 7.NOTĂ: - actul se elaborează de către furnizor şi se aprobă de către beneficiar sau conform obligaţiunilor contractuale |
| 15 | - | Act de punere în exploatare | Se întocmeşte de către beneficiar sau de către utilizator conform cerinţelor interdepartamentale ale lucrărilor de secretariat |
| 16 | - | Propunere de modificare | În formă electronică - conform cerinţelor software-ului. În formă de hîrtie - în formă liberă cu setul de date suficiente pentru luarea deciziei şi întreprinderea acţiunilor concrete |
| 17 | - | Mesaj despre problemă | În formă electronică - conform cerinţelor software-ului. În formă de hîrtie - în formă liberă cu setul de date suficiente pentru luarea deciziei şi întreprinderea acţiunilor concrete |
| 18 | - | Jurnal de evidenţă a adresărilor | În formă electronică - conform cerinţelor software-ului. În formă de hîrtie: 1) numărul de înregistrare al adresării; 2) data şi timpul adresării; 3) locul, data şi timpul detectării problemei*; 4) descrierea pe scurt a problemei sau a propunerii de modificare; 5) funcţia şi numele celui care s-a adresat; 6) decizia luată; 7) cui a fost raportată sau redirecţionată problema; 8) menţiune privind soluţionarea problemei |
| 19 | C5 | Concepţia de mentenanţă | Conform anexei 8 |
| 20 | P7 | Plan de mentenanţă | Conform anexei 9 |
| 21 | P9 | Plan calendaristic al retragerii din exploatare | Conform anexei 2. NOTĂ: - planul este elaborat de către persoana de mentenanţă şi aprobat de către beneficiar; - poate fi îndeplinit în Microsoft Project |
| 22 | - | Act de trecere la pierderi | Se întocmeşte de către beneficiar sau de către utilizator conform cerinţelor interdepartamentale ale lucrărilor de secretariat |
| 23 | - | Lista funcţiilor sistemului software | Conform anexei 10. NOTĂ: - lista funcţiilor se pregăteşte de către elaborator şi se aprobă de către beneficiar |
| 24 | P3 | Plan calendaristic de realizare a versiunii | Conform anexei 2. NOTĂ: - planul se coordonează cu beneficiarul şi se aprobă de către elaborator; - poate fi îndeplinit în Microsoft Project |
________________________
* Existenţa punctelor depinde de componenţa şi complexitatea sistemului software, precum şi de funcţionalitatea sa
Anexa 2
la RT 38370656- 002:2006
FORMA PLANULUI CALENDARISTIC
APROB
__________________________
(funcţia, semnătura, NPP)
"____" _____________200__
Plan calendaristic
_____________________________________________
(denumirea etapei sau procesului)
__________________________________________________
(denumirea sistemului software)
| Nr. crt | Denumirea etapelor şi lucrărilor | Termenele de începere-finisare a lucrărilor | Cu ce se finisează fiecare etapă sau activitate (informaţia tehnică, raportul intermediar, schema principială, macheta, instalarea experimentală, raportul definitiv etc.) | Executantul |
| 1 | 2 | 3 | 4 | 5 |
Notă: ___________________________________________________________________
________________________________________________________________________
COORDONAT
__________________________
(funcţia, semnătura, NPP)
"____" ______________200__
Anexa 3
la RT 38370656- 002:2006
STRUCTURA CONCEPŢIEI SISTEMULUI
1. GENERALITĂŢI
Concepţia este document iniţial, elaborat la crearea sistemului, care conţine rezultatele îndeplinirii lucrărilor de cercetări ştiinţifice de anteproiect şi/sau experimentale şi serveşte drept bază pentru elaborarea ulterioară a documentaţiei tehnice.
În dependenţă de scopurile puse, concepţia poate fi prezentată beneficiarului ca fiind de bază sau cadru. Concepţia - cadru se elaborează în cazul, cînd sistemul descris constă dintr-o multitudine de sisteme independente sau interconectate, pentru care ulterior vor fi elaborate concepţii de bază. Concepţia - cadru se deosebeşte de cea de bază printr-o expunere rezumativă a materialului sau prin lipsa capitolelor sau subcapitolelor separate, care sînt obligatorii pentru concepţia de bază.
Destinaţia de bază a concepţiei constă în prezentarea beneficiarului a viziunii generale asupra sistemului, funcţiilor îndeplinite de el, descrierii spaţiului de drept şi informaţional şi interacţiunii cu alte sisteme informaţionale.
2. CERINŢE FAŢĂ DE STRUCTURA ŞI CONŢINUTUL
CONCEPŢIEI DE BAZĂ
CONCEPŢIEI DE BAZĂ
2.1 Structura concepţiei de bază
Concepţia de bază trebuie să conţină următoarele capitole obligatorii:
a) "Introducere";
b) "Generalităţi";
c) "Spaţiul juridico-normativ al funcţionării sistemului";
d) "Spaţiul funcţional al sistemului";
e) "Structura organizaţională a sistemului";
f) "Documentele sistemului";
g) "Spaţiul informaţional al sistemului";
h) "Spaţiul tehnologic al sistemului";
i) "Asigurarea securităţii informaţionale a sistemului";
j) "Încheiere".
La expunerea capitolelor concepţiei, se admite referinţa la concepţiile aprobate anterior.
2.2 Conţinutul pe scurt al capitolelor concepţiei de bază
2.2.1 Introducere
Introducerea trebuie să conţină informaţie despre domeniul de activitate în care va funcţiona sistemul, analiza nivelului de informatizare al domeniului respectiv, precum şi cauzele creării sau modificării sistemului.
2.2.2 Generalităţi
Conţinutul capitolului respectiv al concepţiei, trebuie să includă:
- denumirea sistemului (deplină, pe scurt, abrevierea);
- definiţia sistemului;
- locul sistemului în Spaţiul informaţional unic;
- noţiuni principale;
- destinaţia sistemului;
- scopurile creării sistemului;
- principiile de bază ale creării sistemului;
- sarcinile de bază, care trebuie să fie realizate la exploatarea sistemului.
2.2.3 Spaţiul juridico-normativ al funcţionării sistemului
Capitolul trebuie să conţină lista actelor juridico-normative de bază (legi, decrete ale Preşedintelui, hotărîri ale Guvernului etc.), care se referă la domeniul de activitate în care va funcţiona sistemul, precum şi actele juridico-normative, care reglementează activitatea şi relaţiile în domeniul informatizării.
În caz de necesitate, în capitol se prezintă propuneri pentru actualizarea bazei juridico-normative existente şi elaborarea actelor juridico-normative care lipsesc, necesare pentru crearea şi exploatarea sistemului.
În capitol trebuie să fie prezentată lista standardelor de bază, utilizate la elaborarea şi crearea sistemului, sau referinţe la alte documente, care conţin astfel de liste.
2.2.4 Spaţiul funcţional al sistemului
În capitol se descriu funcţiile pe care trebuie să le îndeplinească sistemul elaborat. În primul rînd trebuie să fie determinate:
- funcţiile de bază ale sistemului;
- contururile funcţionale de bază;
- interconexiunile, care apar la realizarea funcţiilor sistemului;
- rezultatele funcţionării sistemului.
În caz de necesitate poate fi prezentată caracteristica pe scurt a fiecărei funcţii.
Este raţional de ilustrat funcţionarea sistemului printr-o schemă funcţională, în care ar fi reprezentată grafic interacţiunea tuturor componentelor sistemului.
2.2.5 Structura organizaţională a sistemului
În capitolul respectiv se prezintă lista departamentelor şi a subdiviziunilor lor, implicate în formarea şi managementul resurselor informaţionale şi descrierea pe scurt a interacţiunii interdepartamentale. Pentru fiecare departament se indică funcţiile de bază, legate cu crearea şi exploatarea sistemului.
2.2.6 Documentele sistemului
În capitol trebuie să fie prezentată lista documentelor de bază, utilizate în sistem. Toate documentele trebuie să fie divizate în următoarele categorii:
- documente de intrare, care sînt temei pentru introducerea datelor în sistem (după posibilitate, trebuie de făcut referinţe la alte sisteme, în care ele sînt confecţionate);
- documente de ieşire, confecţionate ca rezultat al funcţionării sistemului;
- documente tehnologice (cereri, anchete, registre etc.).
Dacă la crearea sistemului se presupune introducerea unor documente noi sau modificarea modelelor celor existente, este de dorit prezentarea descrierii lor pe scurt şi a modelului.
2.2.7 Spaţiul informaţional al sistemului
Totalitatea obiectelor, a atributelor lor şi a scenariilor determină spaţiul informaţional al sistemului.
Acesta este capitolul cheie pentru definirea şi înţelegerea sistemului şi include următoarele subcapitole:
- lista obiectelor informaţionale, luate în consideraţie (controlate) în sistem;
- structura identificatorului pentru fiecare obiect informaţional;
- scenariul comportamentului fiecărui obiect luat în consideraţie în sistem;
- datele (sau atributele obiectelor), care se conţin în sistem;
- clasificatoarele;
- fluxurile informaţionale;
- integrarea cu alte sisteme informaţionale.
Determinarea componenţei obiectelor informaţionale, a identificării lor şi a scenariilor comportamentului fiecărui obiect, este sarcina de bază a elaboratorului concepţiei.
Obiectul informaţional trebuie să se caracterizeze prin trei particularităţi de bază:
- unicitate (unicitatea obiectului semnifică existenţa identificatorului unic, care deosebeşte obiectul respectiv de alte obiecte similare);
- stare (starea obiectului se descrie printr-un set de atribute, ce descriu proprietăţile variabile ale obiectului, luate în consideraţie în sistem);
- comportament (comportamentul obiectului este determinat de lista de evenimente, care se petrec cu obiectul şi care sînt luate în consideraţie în sistem).
Este necesar de determinat dacă obiectul este propriu (adică, el este iniţial luat în consideraţie şi identificat în sistemul dat) sau împrumutat (adică, este luat împreună cu identificatorul din alt sistem şi în acest caz nu se admite modificarea identificatorului, iar setul de atribute şi lista de evenimente pot fi împrumutate parţial şi/sau completate). Apoi se descrie structura identificatorului pentru fiecare obiect, atît pentru cel propriu, cît şi pentru cel împrumutat.
Componenţa obiectelor informaţionale trebuie să fie determinată de destinaţia sistemului. În continuare, se determină lista de evenimente luate în consideraţie în sistem pentru fiecare obiect, totodată, trebuie să fie acordată o atenţie deosebită descrierii punerii iniţiale la evidenţă şi condiţiilor în care se realizează identificarea obiectului creat din nou, precum şi scoaterii din evidenţă a obiectelor sistemului.
Următorul pas este determinarea listei de atribute ale obiectelor care sînt stocate în sistem şi care în ansamblu determină spaţiul informaţional al sistemului. Se admite indicarea blocurilor de date fără detalierea lor. După aceasta, trebuie să fie indicate clasificatoarele de bază utilizate în sistem, cu clasificare în internaţionale, naţionale şi intersistemice.
În partea de încheiere a capitolului respectiv al concepţiei se prezintă fluxurile informaţionale de bază care circulă în sistem, cu descrierea pe scurt a sistemelor informaţionale (atît a celor existente, cît şi a celor care se proiectează), care acordă informaţia necesară pentru asigurarea funcţionării sistemului şi, în special, pentru controlul calităţii informaţiei. Suplimentar pot fi indicate sistemele de bază, care utilizează informaţia sistemului respectiv.
2.2.8 Spaţiul tehnologic al sistemului
Spaţiul tehnologic determină alegerea şi realizarea soluţiilor tehnice de program pentru toate componentele sistemului, inclusiv problemele securităţii informaţionale şi asigurării calităţii.
În capitolul respectiv se descrie infrastructura sistemului. Capitolul include următoarele subcapitole:
- nivelele sistemului;
- reţeaua informaţională de telecomunicaţii;
- complexele tehnice de program (CTP) pentru fiecare nivel.
La descrierea nivelelor sistemului, trebuie să fie indicată cantitatea lor şi amplasarea fiecărui nivel (în capitală, centre raionale, comune etc.).
Descrierea reţelei informaţionale de telecomunicaţii include descrierea topologiei reţelei şi a proprietăţilor tehnice de bază sau referinţă la documentul, care conţine descrierile indicate.
La descrierea complexului tehnic de program trebuie să fie indicată amplasarea CTP (organizaţia), destinaţia lui, componenţa mijloacelor tehnice şi a produselor software de bază (sisteme operaţionale, sisteme de administrare a bazelor de date, servere de aplicaţii, mijloace ale elaboratorilor, aplicaţii pentru utilizatori).
2.2.9 Asigurarea securităţii informaţionale a sistemului
Securitatea informaţională a sistemului se obţine prin aplicarea setului corespunzător de mijloace de control, care pot fi politica, măsurile practice, procedurile, structurile organizatorice şi funcţiile de program. Este necesar de determinat aceste mijloace de control, pentru a asigura atingerea scopurilor specifice de organizare în domeniul securităţii.
Asigurarea securităţii informaţionale a sistemului este examinată de obicei conform următoarelor direcţii:
- cerinţele generale faţă de securitatea informaţională a sistemului;
- măsurile de bază privind asigurarea securităţii informaţionale a sistemului.
2.2.10 Încheiere
Încheierea conţine informaţie despre rezultatele planificate ale implementării sistemului şi despre măsurile primordiale privind crearea lui.
3. MODUL DE ELABORARE, ÎNTOCMIRE, COORDONARE
ŞI APROBARE A CONCEPŢIEI
ŞI APROBARE A CONCEPŢIEI
Elaborarea concepţiei include următoarele activităţi:
a) studierea cadrului juridico-normativ de funcţionare a domeniului de activitate respectiv al sistemului;
b) examinarea structurii organizaţionale, care realizează managementul domeniului respectiv;
c) determinarea pachetului de documente, care circulă în domeniul respectiv;
d) analiza nivelului de informatizare în domeniul respectiv;
e) determinarea funcţiilor sistemului;
f) determinarea componenţei obiectelor informaţionale, a identificatorilor lor, scenariilor şi atributelor;
g) determinarea fluxurilor informaţionale, a circulaţiei lor şi a problemelor integrării cu alte sisteme;
h) elaborarea propunerilor privind actualizarea cadrului juridico-normativ (în caz de necesitate - elaborarea proiectelor de acte juridico-normative noi), modificarea structurii organizaţionale şi/sau crearea noilor structuri organizaţionale, crearea noilor documente şi/sau modelelor noi de documente deja existente;
i) elaborarea propunerilor privind structura tehnologică a sistemului, precum şi privind problemele securităţii informaţionale;
j) întocmirea proiectului concepţiei şi pregătirea documentelor necesare pentru coordonarea ei.
Întocmirea, coordonarea şi aprobarea concepţiei se realizează în conformitate cu:
- 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;
- 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.
Anexa 4
la RT 37603221- 002:2006
STRUCTURA SARCINII TEHNICE
1. DISPOZIŢII GENERALE
Sarcina tehnică (ST) este document de bază, care determină cerinţele beneficiarului faţă de sistem, în conformitate cu care se realizează elaborarea produsului software.
ST poate fi elaborată pentru sistem în întregime şi/sau pentru părţile lui componente.
În ST pentru sistemul, care include grupul de subsisteme interconectate, trebuie de inclus numai cerinţele comune pentru grupul de subsisteme. Cerinţele specifice pentru subsistemul separat trebuie să fie reflectate în ST pentru subsistem.
2. STRUCTURA SARCINII TEHNICE
ST trebuie să conţină următoarele capitole şi subcapitole:
a) generalităţi;
b) referinţe;
c) terminologie şi abrevieri;
d) destinaţia sistemului;
e) modelul - business al obiectului automatizării:
- procesele de bază ale obiectului automatizat;
- roluri-business;
- servicii;
- scenariile de îndeplinire a serviciilor;
f) cerinţe funcţionale faţă de sistem:
- modelul funcţional al sistemului;
- cerinţe faţă de funcţiile - business ale sistemului;
g) cerinţe faţă de sistem în întregime:
- cerinţe privind securitatea şi protecţia;
- cerinţe privind integritatea informaţiei;
- cerinţe faţă de hardware şi canalele de comunicaţie;
- fiabilitatea sistemului;
- modul de testare şi primire;
- cerinţe faţă de documentaţie.
În dependenţă de tipul, destinaţia, particularităţile specifice şi condiţiile de funcţionare a obiectului automatizării, se admite introducerea capitolelor şi subcapitolelor suplimentare, excluderea sau unirea capitolelor şi subcapitolelor ST.
Schema structurală a ST se prezintă în figura 1.
Figura 1 - Schema structurală a ST
2.1 Capitolul "Generalităţi"
În capitolul "Generalităţi" se indică:
- denumirea deplină a sistemului;
- lista documentelor organizatorice şi de dispoziţie, în baza cărora a fost iniţiată elaborarea sistemului.
EXEMPLU
Subsistemul "Colectarea informaţiei" (în continuare - subsistemul "CI") este parte componentă a sistemului informaţional automatizat "Registrul de stat". Elaborarea subsistemului "CI" se realizează în baza ...(acordului, dispoziţiei etc.).
2.2 Capitolul "Referinţe"
În capitolul "Referinţe" trebuie să fie indicată lista documentelor normative, la care se fac referinţe în textul ST. Referinţele în text se perfectează conform exemplului:
EXEMPLU
Elaborarea subsistemului "CI" se realizează în conformitate cu cerinţele SF 00000001 - 001.
2.3 Capitolul "Terminologie şi abrevieri"
În capitolul "Terminologie şi abrevieri" se prezintă:
- lista de termeni şi definiţiile lor;
- lista abrevierilor şi a formelor lor depline.
2.4 Capitolul "Destinaţia sistemului"
În capitolul "Destinaţia sistemului" se indică:
- destinaţia sistemului elaborat;
- lista scopurilor creării sistemului.
EXEMPLU
Destinaţia de bază a sistemului "CI" este automatizarea procesului de colectare a informaţiei în subdiviziunile teritoriale.
Subsistemul "CI" se creează cu scopul urgentării şi optimizării proceselor de colectare şi procesare prealabilă a informaţiei, îmbunătăţirii calităţii şi sporirii autenticităţii datelor.
2.5 Capitolul "Modelul-business al obiectului automatizării"
În capitolul "Modelul-business al obiectului automatizării" se indică:
- procesele de bază ale obiectului automatizat;
- lista rolurilor - business;
- lista serviciilor, prestate de sistem;
- scenariile îndeplinirii serviciilor.
2.5.1 Procesele de bază ale obiectului automatizat
În descrierea proceselor de bază ale obiectului automatizat, se prezintă schema generală a circulaţiei fluxurilor informaţionale şi/sau schema stărilor obiectelor.
Schema generală a circulaţiei fluxurilor informaţionale se prezintă în formă de diagramă. Aspectul exterior al schemei circulaţiei fluxurilor informaţionale se prezintă în figura 2.
Figura 2 - Schema circulaţiei fluxurilor informaţionale
Stereotipurile grafice, utilizate pe diagrama schemei generale a circulaţiei fluxurilor informaţionale, se prezintă în tabelul 1.
Tabelul 1. Stereotipurile grafice
Pe diagramă se reprezintă obiectele automatizării, precum şi obiectele de bază, care interacţionează cu ele. Obiectele automatizării se reprezintă în interiorul stereotipului -UML "note". Obiectele care interacţionează, amplasate pe diagramă, se leagă prin săgeţi, care arată direcţia circulaţiei fluxurilor informaţionale. Utilizînd specificaţia, se admite indicarea pe săgeţi a tipului informaţiei transmise sau a artefactului transmis. Informaţia prezentată pe săgeţi se pune în paranteze pătrate.
Schema stărilor obiectelor se prezintă în formă de diagramă. Aspectul exterior al schemei stărilor obiectelor se prezintă în figura 3.
Figura 3 - Schema stărilor obiectului
Stereotipurile grafice, utilizate în schema stării obiectelor, se prezintă în tabelul 2.
Tabelul 2. Stereotipurile grafice
Pe diagramă se reprezintă stările cheie ale obiectului examinat. Perfectarea diagramei - în conformitate cu regulile de construire a diagramelor de tip "Statechart".
2.5.2 Lista rolurilor - business se prezintă în formă de tabel sau în formă de diagramă.
Lista rolurilor - business se prezintă în formă de tabel, în conformitate cu tabelul 3.
Tabelul 3. Lista rolurilor-business
Aspectul exterior al diagramei rolurilor-business se prezintă în figura 4.
Figura 4 - Diagrama rolurilor-business
Stereotipurile grafice, utilizate pe diagrama rolurilor-business, se prezintă în tabelul 4.
Tabelul 4. Stereotipurile grafice
Pe diagramă se reprezintă unităţile organizaţionale şi rolurile-business cheie, care intră în componenţa lor. La distribuirea obiectelor pe diagramă, unitatea organizaţională se amplasează în partea de sus, iar rolurile - business, care intră în componenţa sa, şi alte unităţi organizaţionale - în partea de jos. Aflarea rolului-business în interiorul unităţii organizaţionale se indică cu ajutorul săgeţilor. Direcţia săgeţilor trebuie să fie de la rolul - business spre unitatea organizaţională.
2.5.3 Servicii
Lista serviciilor prestate se prezintă în formă de tabel, în conformitate cu tabelul 5.
Tabelul 5. Lista serviciilor
La formarea comenzii se alege numai unul din serviciile de bază. Suplimentar la serviciul de bază ales, se poate de ales serviciile suplimentare care-i corespund.
2.5.4 Scenariile de îndeplinire a serviciilor
Pentru fiecare serviciu prestat se elaborează scenariul îndeplinirii lui. Pentru serviciile asemănătoare în ceea ce priveşte tehnologia de îndeplinire, se admite prezentarea scenariilor îndeplinirii lor în formă de diagramă unică. Activităţile identice pentru servicii diferite se prezintă în formă de stereotipuri identice "activity".
Scenariul îndeplinirii serviciului se prezintă în formă de diagramă a activităţii (Activity). Sînt posibile două tipuri de diagrame. Aspectul exterior al primului tip al diagramei scenariului de îndeplinire a serviciului se prezintă în figura 5.
Figura 5 - Scenariul îndeplinirii serviciului (varianta 1)
Stereotipurile grafice, aplicate în diagrama scenariului de îndeplinire a serviciului, se prezintă în tabelul 6.
Tabelul 6. Stereotipurile grafice
Pe diagramă se reprezintă rolurile-business cheie, care participă la îndeplinirea serviciului. Activităţile îndeplinite de rolurile-business se reprezintă în domeniile rezervate pentru fiecare din ele.
Dacă rolul-business îndeplineşte cîteva acţiuni consecutive, inseparabile în timp, ele trebuie să fie unificate într-o singură activitate şi să fie reprezentate pe diagramă cu ajutorul unui stereotip "activity".
Pe săgeţile care provin de la stereotipul "decision", utilizînd specificaţia lui, se reprezintă condiţiile circulaţiei pe fiecare direcţie. Stereotipurile amplasate pe diagramă se leagă cu săgeţi, care arată consecutivitatea îndeplinirii acţiunilor de către rolurile-business. Se recomandă de prezentat comentarii referitoare la obiectele amplasate pe diagramă.
Denumirea activităţii (semnificaţia stereotipului "activity") trebuie să înceapă cu verbul la timpul prezent, persoana a treia, fără menţionarea rolului-business, care îndeplineşte această activitate.
EXEMPLU
"Completează blancheta anchetei"
Versiunea a doua a aspectului exterior al diagramei scenariului de îndeplinire a serviciilor se prezintă în figura 6.
Figura 6 - Scenariul îndeplinirii serviciului (varianta 2)
Stereotipurile grafice, aplicate în diagrama scenariului de îndeplinire a serviciului, se prezintă în tabelul 7.
Tabelul 7. Stereotipurile grafice
Regulile de întocmire a diagramei sînt aceleaşi ca şi pentru prima variantă, dar cu următoarele completări: documentele de intrare de activitate sînt legate cu activitatea cu săgeata, care provine de la document. Documentele de ieşire sînt legate cu activitatea cu săgeata, care provine de la activitate.
2.6 Capitolul "Cerinţe funcţionale faţă de sistem"
Capitolul "Cerinţe funcţionale faţă de sistem" constă din subcapitolele:
- modelul funcţional al sistemului;
- cerinţe faţă de funcţiile-business ale sistemului.
2.6.1 Subcapitolul "Modelul funcţional al sistemului"
În subcapitolul "Modelul funcţional al sistemului" se prezintă una sau mai multe diagrame ale funcţiilor-business, care formează modelul funcţional.
Aspectul exterior al diagramei funcţiei - business se prezintă în figura 7.
Figura 7 - Aspectul exterior al diagramei funcţiilor-business
Pe diagrama funcţiilor - business se indică toate funcţiile - business îndeplinite de roluri concrete, funcţiile - business ale sistemului şi relaţiile între ele.
În tabelul 8 se prezintă stereotipurile, utilizate la crearea modelului funcţional.
Tabelul 8. Stereotipurile utilizate
Diagrama funcţiilor-business se construieşte în conformitate cu regulile standard de construire a diagramei Use Case (diagrama funcţiilor) în limbajul UML.
2.6.2 Subcapitolul "Cerinţe faţă de funcţiile-business ale sistemului"
Denumirea subcapitolului "Cerinţe faţă de funcţiile - business ale sistemului", trebuie să aibă aspectul: "Cerinţe faţă de funcţia-business (se prezintă denumirea ei)". Subcapitolul dat se repetă pentru descrierea cerinţelor faţă de fiecare funcţie-business a sistemului.
Subcapitolul "Cerinţe faţă de funcţia-business a sistemului" constă din următoarele puncte:
a) caracteristicile generale ale funcţiei-business;
b) scenariul realizării funcţiei-business;
c) documente de intrare;
d) documente interne;
e) documente de ieşire;
f) reguli-business;
g) cerinţe speciale;
h) variantele tehnologiilor şi datelor;
i) informaţie suplimentară.
În dependenţă de specificitatea funcţiei-business, se permite excluderea, adăugarea sau unificarea punctelor.
2.6.2.1 În punctul "Caracteristicile generale ale funcţiei-business" se indică următoarele caracteristici ale funcţiei-business:
- rezultatul îndeplinirii reuşite;
- rezultatul minim;
- condiţiile anterioare îndeplinirii funcţiei - business;
- condiţiile iniţializării funcţiei-business.
Caracteristicile generale ale funcţiei-business se indică în formă de tabel, conform tabelului 9, în care trebuie de completat rubrica "Semnificaţia". În dependenţă de specificitatea funcţiei - business, se permite excluderea anumitor caracteristici.
Tabelul 9. Caracteristicile generale ale funcţiei - business
| Caracteristica | Semnificaţia |
| Rezultatul îndeplinirii reuşite | |
| Rezultatul minim | |
| Condiţiile anterioare îndeplinirii funcţiei - business | |
| Condiţiile iniţializării funcţiei - business |
În rîndul "Rezultatul îndeplinirii reuşite" se indică ceea ce vor primi rolurile ca rezultat al finisării reuşite a funcţiei - business la terminarea scenariului reuşit principal sau a ramurii lui de alternativă.
În rîndul "Rezultatul minim" se indică rezultatul lucrului funcţiei - business în lipsa atingerii rezultatului final.
În rîndul "Condiţiile anterioare îndeplinirii funcţiei - business" se indică datele şi condiţiile, pe care sistemul trebuie să le verifice în ceea ce priveşte veridicitatea, înainte de a permite lansarea funcţiei-business.
În rîndul "Condiţiile iniţializării funcţiei - business" se indică evenimentul, survenirea căruia duce la lansarea funcţiei - business.
2.6.2.2 În punctul "Scenariul realizării funcţiei - business" se prezintă scenariul reuşit al lucrului funcţiei - business şi extinderile lui.
Scenariul reuşit se descrie cu ajutorul Activity diagram - diagrama activităţii. Aspectul exterior al diagramei scenariului reuşit se prezintă în figura 8.
Figura 8 - Aspectul exterior al diagramei scenariului reuşit
Diagrama activităţii se construieşte în conformitate cu regulile construirii diagramei Activity diagram (diagrama activităţii) în limbajul UML.
Numerotarea acţiunilor începe de la "1". Numărul acţiunii se indică înaintea denumirii ei şi se separă de denumire prin lacună.
Se permite detalierea acţiunii prin adăugarea acţiunilor elementare, îndeplinite la începutul acţiunii (On Entry), în procesul îndeplinirii acţiunii (Do) şi la finisarea acţiunii (On Exit).
Se admite includerea condiţiilor suplimentare sau a regulei-business în formă de comentarii.
Extinderile scenariului reuşit se prezintă în formă de tabel, conform tabelului 10.
Tabelul 10. Extinderile scenariului reuşit
| Scenariul reuşit | Condiţii | Acţiuni |
| \x01( | \x01( | \x01( |
În rubrica "Scenariul reuşit" se indică denumirea acţiunilor scenariului reuşit din diagrama activităţilor.
În rubrica "Condiţii", se indică condiţiile de încălcare a îndeplinirii normale a scenariului reuşit. Numerotarea condiţiilor se formează din numărul acţiunii scenariului reuşit la care se referă condiţia, şi numărul de ordine al condiţiei pentru acţiunea dată, despărţite prin punct.
În rubrica "Acţiuni" se indică acţiunile, care trebuie să fie îndeplinite la survenirea condiţiei. Numerotarea acestor acţiuni se formează din numărul condiţiei, în cazul căreia este necesar de îndeplinit acţiunea dată, şi numărul de ordine al acţiunii, despărţite prin punct.
În cazul cînd condiţia poate surveni în orice moment al îndeplinirii scenariului, ea trebuie scoasă în afara scenariului reuşit. Numerotarea unei astfel de condiţii începe întotdeauna de la 0. Condiţia dată trebuie să fie indicată în tabel înainte de descrierea extinderilor scenariului reuşit.
Se permite de a face referinţe la regulile-business, pre-zentate în punctul ST "Reguli-business", în orice rubrică a tabelului.
Exemplul de întocmire a extinderii scenariului reuşit se prezintă în tabelul 11.
Tabelul 11. Exemplu de întocmire a extinderii scenariului reuşit
| Scenariul reuşit | Condiţii | Acţiuni |
| 0.1 Lipsa electricităţii | 0.1.1 Încetarea procesului.0.1.2 Îndeplinirea acţiunilor prescrise în instrucţiune | |
| 0.2 Computerul operatorului s-a blocat | 0.2.1 Încetarea procesului.0.2.2 Îndeplinirea acţiunilor necesare pentru restartarea sistemului.0.2.3 Reînceperea procesului | |
| 1.Completează ancheta | ||
| 2. Imprimă ancheta | 2.1 Imprimanta a generat mesaj de eroare. | 2.1.1 Îndeplinirea acţiunilor prescrise în instrucţiunea de exploatare a imprimantei |
2.6.2.3. În punctul "Documente de intrare" se prezintă lista documentelor de intrare faţă de funcţia - business.
Lista documentelor de intrare se prezintă sub formă de tabel, în conformitate cu tabelul 12.
Tabelul 12. Documentele de intrare
| Documentul | Tipul | Aspectul exterior | Cerinţele |
| \x01( | \x01( | \x01( | \x01( |
În rubrica "Documentul" se indică denumirea documentului.
În rubrica "Tipul" se indică tipul documentului:
- de hîrtie;
- electronic;
- pe microcircuit electronic (cip);
- artefact.
În rubrica "Aspectul exterior" se face referinţă la anexa în care se prezintă aspectul exterior al documentului.
În rubrica "Cerinţele" se indică cerinţele faţă de conţinutul sau completarea documentului.
Se permite prezentarea cerinţelor faţă de conţinutul sau completarea documentului în regula-business sau în anexă. În acest caz, în rubrica "Cerinţele" se indică denumirea regulii-business sau a anexei în modul corespunzător.
Înlăturarea sau adăugarea coloanei în tabel se permite în dependenţă de structura informaţională sau particularităţile documentului.
2.6.2.4 În punctul "Documente interne" se prezintă lista documentelor interne ale funcţiei - business. Documentele interne se creează în procesul îndeplinirii funcţiei - business şi nu ies din cadrul ei.
Descrierea documentelor interne se realizează analogic descrierii documentelor de intrare (a se vedea p. 2.6.2.3).
2.6.2.5 În punctul "Documente de ieşire" se prezintă lista documentelor de ieşire ale funcţiei - business. Documentele de ieşire sînt reprezentarea informaţională a rezultatului unei anumite activităţi în procesul de îndeplinire a funcţiei - business.
NOTĂ - Dacă rezultatul îndeplinirii funcţiei - business este artefactul, atunci el este indicat în lista documentelor de ieşire cu indicarea tipului "artefact".
Descrierea documentelor de ieşire se realizează analogic descrierii documentelor de intrare (a se vedea p. 2.6.2.3).
2.6.2.6 În punctul "Reguli-business" se prezintă lista regulilor - business. Punctul "Reguli - business" trebuie să fie împărţit în subpuncte. Fiecare subpunct corespunde unei reguli-business. Denumirea subpunctului trebuie să corespundă denumirii regulii-business.
Regulile-business care se extind asupra cîtorva funcţii-business, pot fi prezentate în anexe, totodată denumirea anexei trebuie să corespundă denumirii regulii-business. În acest caz, în subpunct se indică numai referinţa la această anexă.
2.6.2.7 În punctul "Cerinţe speciale" se indică cerinţele speciale faţă de realizarea funcţiei-business, care nu pot fi indicate în alte puncte.
În punctul dat se prezintă cerinţele speciale privind securitatea şi protecţia, privind integritatea informaţiei, fiabilitatea sistemului, în cazul cînd ele sînt specifice cerinţelor prezentate în capitolul "Cerinţe faţă de sistem în întregime".
2.6.2.8 În punctul "Variantele tehnologiilor şi datelor" se prezintă lista diferitor metode de îndeplinire a acţiunilor scenariului funcţiei-business. Se îndeplinesc aceleaşi acţiuni, dar modul lor de îndeplinire se modifică.
Lista modurilor de îndeplinire a acţiunilor scenariului funcţiei-business se prezintă în formă de tabel, conform tabelului 13.
Tabelul 13. Variantele tehnologiilor şi datelor
| Acţiunea | Variantele |
| \x01( | \x01( |
În rubrica "Acţiunea" se introduce denumirea acţiunii din punctul "Scenariul realizării funcţiei-business", iar în rubrica "Variantele" se introduc variantele tehnologiei sau datelor.
Exemplul de completare se prezintă în tabelul 14.
Tabelul 14. Variantele tehnologiilor şi datelor
| Acţiunea | Variantele |
| 2 Imprimarea certificatului | Anticiparea posibilităţii de imprimare la imprimantă matricială şi laser |
2.6.2.9 În punctul "Informaţie suplimentară" se include orice informaţie suplimentară cu caracter general, care nu a fost inclusă în alt punct.
2.7 Capitolul "Cerinţe faţă de sistem în întregime"
Capitolul "Cerinţe faţă de sistem în întregime" constă din subcapitolele:
- cerinţe privind securitatea şi protecţia;
- cerinţe privind integritatea informaţiei;
- cerinţe faţă de fiabilitatea sistemului;
- modul de testare şi primire;
- cerinţe faţă de hardware şi canalele de comunicaţie;
- cerinţe faţă de documentaţie.
În subcapitolul "Cerinţe privind securitatea şi protecţia" se indică cerinţele privind protecţia informaţiei de la accesul nesancţionat.
În subcapitolul "Cerinţe faţă de integritatea informaţiei" se prezintă lista de cerinţe faţă de asigurarea integrităţii informaţiei în sistem, precum şi lista măsurilor şi/sau acţiunilor pentru asigurarea integrităţii informaţiei.
În subcapitolul "Cerinţe faţă de fiabilitatea sistemului" se indică cerinţele faţă de fiabilitatea sistemului software.
În subcapitolul "Modul de testare şi primire" se indică cerinţele faţă de modul de efectuare a testărilor şi faţă de modul de primire.
În subcapitolul "Cerinţe faţă de hardware şi canalele de comunicaţie" se indică cerinţele faţă de hardware şi canalele de comunicaţie. Cerinţele faţă de hardware şi canalele de comunicaţie se stabilesc în baza cerinţelor prezentate de software faţă de hardware şi canalele de comunicaţie.
În subcapitolul "Cerinţe faţă de documentaţie" se indică cerinţele faţă de componenţa documentaţiei elaborate.
Anexa 5
la RT 37603221- 002:2006
FORMA ACTULUI DE PREDARE ÎN EXPLOATARE
EXPERIMENTALĂ
EXPERIMENTALĂ
Anexa 6
la RT 38370656- 002:2006
FORMA ACTULUI DE FINISARE A ELABORĂRII SOFTWARE-ULUI
Anexa 7
la RT 38370656 - 002:2006
FORMA ACTULUI DE PREDARE ÎN EXPLOATARE
Anexa 8
la RT 38370656-002:2006
STRUCTURA CONCEPŢIEI DE MENTENANŢĂ
Concepţia de mentenanţă trebuie să fie elaborată imediat după finisarea exploatării experimentale a produsului software.
Concepţia de mentenanţă se elaborează de către persoana de mentenanţă pentru fiecare produs software primit spre mentenanţă, care apoi este aprobată de către beneficiar.
Concepţia de mentenanţă trebuie să conţină următoarele capitole:
- domeniul de mentenanţă a produsului software;
- aplicarea practică a procesului de mentenanţă;
- determinarea persoanelor responsabile de mentenanţă;
- evaluarea costului mentenanţei.
1. Domeniul de mentenanţă
Capitolul dat trebuie să determine obligaţiunile persoanei de mentenanţă, precum şi tipul de suport pe care trebuie să-l asigure produsului software. Domeniul de mentenanţă poate depinde de existenţa mijloacelor bugetare. În capitolul dat trebuie să fie descrise:
- tipurile de mentenanţă îndeplinită;
- modul de mentenanţă a documentaţiei de program;
- acţiunile persoanei de mentenanţă în cazul diferitor tipuri de mentenanţă;
- nivelul necesar de instruire a personalului de mentenanţă;
- organizarea serviciului de susţinere a clienţilor ("Hot line");
- modul de livrare a produsului software.
2. Aplicarea practică a procesului de mentenanţă
Concepţia de mentenanţă trebuie să reflecte sarcinile mentenanţei produsului software după livrarea lui. În capitolul dat trebuie de determinat toate organizaţiile (subdiviziunile), care participă la procesul de mentenanţă, rolurile lor şi sarcinile de bază. De asemenea este necesar de descris procesul de mentenanţă ales pentru acest produs software.
3. Determinarea persoanelor responsabile de mentenanţă
În capitolul dat trebuie de determinat organizaţiile (subdiviziunile) şi persoanele fizice concrete, responsabile de mentenanţa produsului software. Este necesară determinarea rolului persoanelor fizice şi precizarea obligaţiunilor lor.
Îndeplinirea mentenanţei conform acordului cu partea terţă, trebuie să se menţioneze în concepţia de mentenanţă.
4. Evaluarea costului mentenanţei
În acest capitol trebuie să se efectueze evaluarea costului mentenanţei. În cazul existenţei acordului de mentenanţă a produsului software pentru organizaţia externă, trebuie de luat în consideraţie:
- transportul pînă la amplasarea utilizatorului;
- instruirea atît a persoanelor de mentenanţă cît şi a utilizatorilor;
- suportul tehnic necesar al mijloacelor software şi hardware achiziţionate (standard);
- salariile şi premiile personalului.
La elaborarea concepţiei, costul se evaluează în baza datelor limitate. Acest cost poate fi precizat în procesul de mentenanţă.
În calitate de date iniţiale pot fi utilizate datele proiectelor analogice.
Anexa 9
la RT 38370656 - 002:2006
CONŢINUTUL PLANULUI DE MENTENANŢĂ
În dependenţă de volumul lucrărilor de mentenanţă, trebuie să fie luată decizia de introducere a anumitor capitole într-un plan concret de mentenanţă.
Capitolele, recomandate pentru a fi incluse în planul de mentenanţă:
1. PREAMBUL
1.1 Descrierea produsului software menţinut
1.2 Determinarea stărilor iniţiale ale produsului software
1.3 Descrierea nivelului de suport necesar
1.4 Determinarea organizaţiei (subdiviziunilor), care realizează mentenanţa
1.5 Descrierea condiţiilor (proceselor-verbale), coordonate între beneficiar şi furnizor
2. LUCRĂRILE ORGANIZATORICE ŞI LUCRĂRILE DE MENTENANŢĂ
2.1 Rolurile şi obligaţiunile persoanei de mentenanţă pînă la livrarea produsului software
2.1.1 Realizarea procesului de mentenanţă
2.1.2 Determinarea infrastructurii procesului de mentenanţă
2.1.3 Stabilirea procesului de instruire
2.1.4 Stabilirea procesului de mentenanţă
2.2 Rolurile şi obligaţiunile persoanei de mentenanţă după livrarea produsului software
2.2.1 Realizarea procesului de mentenanţă
2.2.2 Analizele problemelor şi modificărilor
2.2.3 Realizarea (introducerea) modificărilor
2.2.4 Examinarea şi primirea modificărilor
2.2.5 Transferul produsului software în condiţii noi
2.2.6 Retragerea produsului software din exploatare
2.2.7 Rezolvarea problemelor (inclusiv serviciul de susţinere a clienţilor)
2.2.8 În caz de necesitate - instruirea personalului (a persoanei de mentenanţă şi a utilizatorului)
2.2.9 Perfecţionarea procesului de mentenanţă
2.3 Rolul utilizatorului
2.3.1 Încercările de recepţie
2.3.2 Interconexiunea cu alte organizaţii
3. RESURSE
3.1 Personal
3.1.1 Componenţa personalului pentru proiectul concret
3.2 Mijloace de program
3.2.1 Determinarea mijloacelor de program, necesare pentru suportul exploatării sistemului (ţinînd cont de cerinţele de sistem)
3.3 Mijloace tehnice
3.3.1 Determinarea mijloacelor tehnice, necesare pentru suportul exploatării sistemului (ţinînd cont de cerinţele de sistem)
3.4 Utilaj (aparatură)
3.4.1 Determinarea cerinţelor faţă de utilajul (aparatura) sistemului (în afară de mijloacele tehnice ale tehnicii de calcul)
3.5 Documente
3.5.1 Planul de asigurare a calităţii
3.5.2 Planul de dirijare a configuraţiei (poate fi comun cu procesul de elaborare)
3.5.3 Documentele de elaborare (se transmit din procesul de elaborare)
3.5.4 Instrucţiunile de mentenanţă
3.5.5 Modul de realizare a verificării şi atestării produsului software
3.5.6 Procedurile de testare şi actele de testare
3.5.7 Planul de instruire
3.5.8 Instrucţiunile de exploatare a produselor software (se transmit din procesul de elaborare)
3.6 Resurse informaţionale
4. PROCESUL DE ÎNDEPLINIRE A ACTIVITĂŢII CONCRETE
4.1 Procesele îndeplinite de persoana de mentenanţă
5. INSTRUIRE
5.1 Determinarea nivelului de instruire, necesar persoanei de mentenanţă şi utilizatorului
6. PROCESELE-VERBALE ŞI RAPOARTELE CU PRIVIRE LA MENTENANŢĂ
6.1 Lista interpelărilor utilizatorului, privind prestarea serviciilor de mentenanţă, PM şi MP
6.2 Starea interpelărilor conform categoriilor
6.3 Priorităţile interpelărilor
6.4 Datele de control, colectate în timpul lucrărilor de mentenanţă
Anexa 10
la RT 38370656 - 002:2006
FORMA LISTEI FUNCŢIILOR PENTRU METODA
ITERAŢIONALĂ DE ELABORARE
ITERAŢIONALĂ DE ELABORARE