QM TI NoteCurs P-u Examen

1

1. Abordări moderne ale problemei calităţii Actuala perioadă pe care o parcurge societatea românească este caracterizată, în principal, prin

adoptarea şi statuarea unor noi modele organizaţionale în domeniile social, politic şi economic.

Un loc important în cadrul acestor mutaţii îl ocupă încercările prin care diverşi factori cu pondere

economică şi socială - o parte a corpului managerial, învăţământul şi chiar o parte a clasei politice în formare

-încearcă să-şi însuşească, să adapteze şi să se adapteze, să cunoască şi să impună o nouă cultură a calităţii.

Acest lucru se înscrie în tendinţa generală a societăţii româneşti de a se alinia, cel puţin în formă, valorilor ce

caracterizează societatea occidentală, societate ce, în urmă cu peste patru decenii, sesiza importanţa

economică a calităţii şi dezvolta primele tehnici, teorii şi modele ce aveau să pună bazele unui nou tip de

cultură - cultura calităţii.

În domeniul economic, creşterea importanţei calităţii a fost determinată de diversificarea şi

înnoirea/reînnoirea rapidă a ofertei de bunuri şi servicii, mondializarea pieţelor - facilitată de progresele din

telecomunicaţii şi din domeniul reţelelor de calculatoare - creşterea exigenţelor clienţilor şi ale societăţii,

creşterea complexităţii produselor şi serviciilor. Acest lucru a făcut ca, pe lângă anumiţi parametrii "clasici"

ai caracteristicilor de calitate ale diferitelor produse, să apară şi alţii noi, cum ar fi caracterul nepoluant sau

nepericulozitatea, astfel că, în prezent, calitatea a devenit un factor determinant al complexităţii unei entităţi.

Încă de la sfârşitul anilor '80, organizaţia internaţională pentru standarde, I.S.O., cu sediul la Geneva -

Elveţia, începe să publice primele standarde referitoare la calitate. Standardul ISO-8402 - "Managementul şi

asigurarea calităţii - Vocabular" [ISO3], defineşte calitatea ca

ansamblul caracteristicilor unei entităţi, care îi conferă aptitudinea de

a satisface nevoile exprimate sau implicite. Calitatea în sine se

exprimă printr-un sistem de caracteristici, nu este de sine-stătătoare,

ci se defineşte în relaţia cu anumite persoane (figura 1.2) - clienţi,

producători, furnizori, comercianţi, etc. - este o variabilă continuă şi

nu una discretă - deşi metricile prin care se exprimă unele

caracteristici de calitate, au un caracter discret - şi presupune

satisfacerea nu numai a nevoilor exprimate, dar şi a celor implicite.

Mergând un pas mai departe faţă de standardul ISO-8402,

specialiştii japonezi în calitate, au elaborat metoda "Quality Function

Deployment" [ZUL1], conform căreia, printre altele, nevoile

exprimate în cerinţe ale beneficiarilor, pot fi:

- normale sau explicite, ce apar în specificaţii şi reies din

discuţiile cu clientul, fiind satisfăcute în raport direct cu prezenţa lor

în entitatea respectivă;

- implicite, considerate elementare, şi de aceea de cele mai

multe ori nici nu se mai menţionează, prezenţa lor în entitatea livrată

nu dă un spor de satisfacţie, în schimb absenţa lor poate fi total

nesatisfăcătoare;

- deosebite, cele mai dificil de îndeplinit, fiind peste aşteptările

clienţilor. Absenţa lor nu produce insatisfacţii, deoarece sunt

neaşteptate, dar prezenţa produce o satisfacţie deosebită, aducând totodată producătorului importante

avantaje pe piaţă.

Universalitatea calităţii este reliefată şi prin definirea noţiunii de entitate, ce apare în definiţia calităţii

din standardul ISO 8402. Astfel, o entitate poate fi o activitate, un produs sau un proces, o persoană sau un

grup de persoane, o organizaţie, un sistem sau o combinaţie între toate acestea.

Noua cultură a calităţii a determinat şi apariţia unor modele de management corespunzătoare.

Managementul calităţii este parte componentă atât a ştiinţei managementului cât şi a managementului practic

al firmelor şi organizaţiilor.

Introducerea în practică a tehnicilor managementului calităţii produce modificări în cadrul

organizaţiilor, atât în ceea ce priveşte organizarea procesuală şi structurală (compartimentele de asigurare a

calităţii - "Quality Assurance" - ce au apărut pe lângă controlul tehnic de calitate - C.T.C., cercurile calităţii,

servicii de audit şi controlling, echipe transfuncţionale) cât şi în ceea ce priveşte mentalităţile managerilor şi

executanţilor, poziţia clienţilor, poziţia proceselor unul faţă de altul, etc. Calitatea nu mai trebuie doar

verificată, ci produsă.

Concepţia modernă despre calitate priveşte acest concept dinamic şi leagă calitatea produsului sau

serviciului de alte două elemente: calitatea concepţiei (proiectului) şi calitatea fabricaţiei.

CalitateaCalitatea

Client

Producător

Furnizor

Comercianţi

Alţii

Figura 1.2. Categoriile de persoane,

care influenţează definirea

caracteristicilor calităţii

2

Conform standardelor ISO, calitatea fabricaţiei reprezintă gradul de conformitate a produsului cu

documentaţia tehnică, iar calitatea proiectului exprimă măsura în care proiectul produsului asigură

satisfacerea cerinţelor beneficiarilor şi posibilitatea de folosire, la fabricaţia produsului respectiv, a unor

procedee tehnologice raţionale şi optime din punct de vedere economic (figura 1.3), unde:

A = cerinţele beneficiarului;

B = caracteristicile calităţii prevăzute în documentaţia

tehnică;

C = caracteristicile produsului;

1 = calitatea concepţiei;

2 = calitatea fabricaţiei;

3 = calitatea produsului (sau serviciului).

La aceste noţiuni se adaugă şi conceptul de calitate livrată. Calitatea livrată se referă la nivelul real al

calităţii produsului sau serviciului, în momentul achiziţionării de către beneficiar.

2. Calitatea produselor software - particularităţi Dacă societatea contemporană este o societate a calităţii, atunci ea este în aceeaşi măsură o societate a

informaţiei şi a tehnologiei informaţiei.

în industria de software, întâlnim aceeaşi concentrare pe produs a concepţiei, execuţiei, asigurării şi

verificării calităţii, ca în faza preindustrială, dar, pe de altă parte, datorită complexităţii produsului rezultat,

există grupul de executanţi, împărţit în colective sau indivizi specializaţi, care acţionează pe parcursul unor

înlănţuiri de faze (ciclu de viaţă). Modelul de producţie în industria software este un model de "producţie a

proiectelor". Particularitatea producţiei de software rezidă în faptul că activităţile desfăşurate pot fi specifice

unei anumite faze a ciclului de viaţă, sau pot fi independente de fazele ciclului de viaţă.

Importanţa calităţii produselor software rezidă în cel puţin trei aspecte:

erorile din programele de aplicaţie pot fi fatale în anumite domenii unde vieţile oamenilor depind de

acestea; aceste erori pot provoca pierderi financiare, materiale şi tot felul de alte tipuri de insatisfacţii sau

pierderi;

dacă în domeniul produselor hardware costurile au o tendinţă generală de scădere, în domeniul

dezvoltării de software, deşi productivitatea a crescut substanţial, nu se înregistrează şi o scădere a costurilor

care să ducă la aceeaşi tendinţă.

Acest ultim aspect se datorează particularităţilor prin care calitatea se manifestă în domeniul produselor

software, aşa cum sunt ele relevate în [BAR01]:

- comportamentul instrucţiunilor nu se deteriorează în timp;

- erorile sunt provocate de folosirea sau combinarea incorectă a componentelor elementare, şi nu de

aceste componente în sine;

- interacţiunile dintre componentele unui program sunt, mai complexe, mai ales dacă acestea

rulează în cadrul unor aplicaţii complexe;

- erorile există deja în program, ele sunt eliminate cu timpul, prin depanare, deci programul se

îmbunătăţeşte prin trecerea timpului;

- eliminarea unei erori nu dă siguranţa că a diminuat numărul total de erori cu o unitate;

- non-calitatea programelor poate fi atribuită în întregime greşelilor umane, de proiectare, concepţie,

B = caracteristicile calităţii

prevăzute în documentaţia

tehnică

C = caracteristicile

produsului

calitatea concepţiei3 = calitatea produsului

(sau serviciului).

Calitatea fabricaţiei

Figura 1.3. Elementele conceptului calităţii

3

programare, documentare.

Un manager preocupat de calitatea produselor software trebuie să posede, conform [WEI2], anumite

abilităţi speciale şi chiar calităţi native, cum ar fi: să observe ce se întâmplă şi să înţeleagă semnificaţia

propriilor observaţii; să se poată comporta şi să poată acţiona congruent în situaţii interpersonale dificile,

chiar şi când este derutat, supărat sau speriat; să poată înţelege situaţiile complexe. Această ultimă abilitate

permite să se poată planifica un proiect şi apoi să se observe şi să se acţioneze astfel încât proiectul să

decurgă conform planului sau să poată fi modificat conform cerinţelor şi schimbărilor apărute pe parcurs.

Calitatea produselor software este definită în [BAR03] ca măsura în care acestea satisfac cerinţele

utilizatorilor prin caracteristici tehnice, economice şi psiho-sociale. Această definiţie se bazează pe două

concepte care, puse în legătură, dau măsura calităţii unui produs software, şi anume cerinţele utilizatorilor şi

caracteristicile produsului.

O importanţă deosebită în procesul de dezvoltare software o are dependenţa dintre specificul şi

calitatea procesului generator, calitatea proiectului şi calitatea produsului. Ca urmare, putem deosebi de la

început doi factori esenţiali pentru calitatea produsului software, şi anume modelul specificat (proiectul) şi

conformanţa faţă de proiect (fidelitatea reproducerii). Definirea problemei la beneficiar şi clarificarea şi

detalierea acesteia de către beneficiar şi producător prin elaborarea unor specificaţii, are un impact deosebit

atât asupra calităţii proiectului şi, ulterior, a produsului, dar şi asupra întregului ciclu de viaţă al produsului

software.

3. Managementul calităţii - componentă a managementului firmei Calitatea a devenit o problemă majoră pentru managementul actual al firmei. In unele lucrări de

specialitate privitoare la teoria şi practica managementului se pune chiar problema existenţei, pe lângă

funcţiunile tradiţionale ale firmei, şi a "funcţiunii de calitate". Ca urmare, managementul de vârf al firmelor,

trebuie să se preocupe de elaborarea strategiilor şi politicilor firmei în domeniul calităţii.

Integrate în strategia şi politica generală a firmei, strategiile şi politicile de calitate asigură exprimarea

orientărilor privind mărimea performanţelor viitoare ale firmei, posibilităţile de asigurare a unui management

concurenţial şi determinarea procedurilor de comportament pe diferite pieţe şi faţă de diferite produse.

Conform [NICI], abordarea calităţii prezintă, în cadrul firmei, două aspecte: asigurarea calităţii şi

gestiunea calităţii.

Asigurarea calităţii reprezintă un ansamblu de mijloace, prestabilite şi sistematizate, întreprinse de

firmă, în toate compartimentele implicate în activităţi ce pot influenţa calitatea produselor şi serviciilor

executate, astfel încât să exprime certitudinea realizării cerinţelor de calitate specificate.

Obiectivele gestiunii calităţii constau în identificarea, analiza şi interpretarea tuturor anomaliilor

apărute în timpul desfăşurării producţiei, precum şi în definirea acţiunilor corective sau de orientare a calităţii

în toate etapele de realizare a produsului şi/sau de prestare a serviciului, inclusiv prin prisma costurilor

calităţii.

Unul din obiectivele fundamentale ale managementului calităţii îl constituie construirea, manevrarea şi

îmbunătăţirea unui sistem al calităţii în cadrul organizaţiei. Reciproc, managementul calităţii nu poate avea

coerenţă în organizaţii unde nu există definit un sistem manevrabil al calităţii, proceduri pentru menţinerea,

actualizarea şi îmbunătăţirea acestuia. Astfel, având în vedere modelul Maturitate/Capabilitate - CMM/SEI,

[PFL1], elaborat în S.U.A. la Software Engineering Institute, se apreciază că, deşi gestiunea calităţii poate

apare la o organizaţie producătoare de software situată la nivelul doi de maturitate - procesele sunt repetabile

- totuşi aceasta nu poate fi efectivă decât la organizaţii aflate cel puţin la nivelul trei de maturitate, unde

procesele sunt definite şi instituţionalizate. Acest nivel de maturitate presupune că produsele intermediare ale

etapelor dezvoltării, precum şi etapele în sine, sunt bine definite şi "vizibile", permiţând măsurarea

caracteristicilor produselor şi proceselor intermediare.

Pentru exercitarea unui management al calităţii eficient, sistemul calităţii existent în organizaţie trebuie

să asigure realizarea premiselor pentru un suport corect al activităţii decizionale (Tabelul 1.1.).

Tabelul 1.1.

Premise pentru definirea acţiunilor corective, de orientare a calităţii în toate

etapele de realizare, a produsului software existenţa unei baze de date referitoare la proiecte anterioare, actualizată cu datele proiectului

curent, inclusiv în ceea ce priveşte costurile;

actualizarea continuă, pe baza unor contacte permanente cu managementul de nivel

înalt şi cu compartimentele de marketing, a direcţiilor de acţiune viabile de urmat în ceea ce

priveşte calitatea produsului, precum şi a tendinţelor apărute pe piaţă;

4

analiza şi sistematizarea neconformităţilor apărute, a momentelor, proceselor şi cauzelor

apariţiei acestora, precum şi a costurilor aferente;

stabilirea de scenarii corective şi elaborarea de diagrame de tip cauză-efect pentru fiecare tip

sistematic de neconformitate sau defecţiune, apărute la nivelul produsului şi la nivelul

sistemului (proceselor) prin care acesta este dezvoltat, cu luarea în considerare şi a cauzelor

externe proceselor, precum şi elaborarea de diagrame cauză-efect în studierea unor scenarii ale

schimbării de tip "what if ?";

punerea de acord, din punct de vedere practic, a tendinţelor generale ale pieţei produsului, a

tendinţelor generale în ceea ce priveşte calitatea, cu posibilităţile concrete de care dispune

organizaţia (firma) producătoare, de a produce o anumită calitate;

propuneri de actualizare, pe baza rezultatelor concrete obţinute, a strategiei şi politicii firmei cu

privire la calitate.

Lucrarea de faţă apare în cadrul programului de perfecţionare a învăţământului superior de informatică

economică, ce include "Şcoala doctorală de managementul calităţii software", sub egida Consiliului Naţional

al Cercetării Ştiinţifice Universitare, pe baza contractului 39687-146/1998.

4. Abordarea managerială orientată pe produs. Sistemul caracteristicilor de

calitate ale produselor software După cum se arată şi în definiţia dată calităţii (standardul ISO 8402, [ISO3]), aceasta este prezentă în

fapt printr-un set de caracteristici. Aceste caracteristici pot fi împărţite în:

a) caracteristici economice, exprimate prin costuri (de proiectare, elaborare, implementare, utilizare),

economii (de resurse materiale, umane, financiare), creşteri de randament şi productivitate, privite în legătură

cu costurile şi economiile şi analizate împreună în vederea stabilirii oportunităţii realizării

produsului;

b) caracteristici sociale şi psiho-senzoriale, care constau în potenţarea elementelor creatoare,

eliminarea rutinei şi stereotipiei, instruirea asistată a operatorilor. Asupra acestor caracteristici s-au făcut

studii comparative. S-a constatat, de pildă, că rutina şi nemulţumirea utilizatorilor datorate lucrului, timp

îndelungat, cu anumite produse, este mult mai mică în cazul utilizării interfeţelor utilizator grafice (Microsoft

Windows, X-Windows, Macintosh), decât în cazul utilizării unor interfeţe în mod text;

c) caracteristici tehnice şi de utilizare (de utilitate generală). Aceste caracteristici sunt tratate "in

extenso" în literatura de specialitate, iar organizaţia internaţională pentru standardizare a elaborat un

model concretizat în standardul ISO 9126 din 1991 [ISO1].

Între caracteristicile de calitate, indiferent din ce perspectivă ar fi privite sau grupate, există multiple

relaţii de interdependenţă, subordonare, ierarhizare, decompoziţie sau agregare. Complexitatea acestor relaţii

determină ca ansamblul caracteristicilor de calitate să alcătuiască un sistem.

Pentru ca acest sistem de caracteristici de calitate să poată fi operaţional, în sensul ca să se poată

selecta un set de caracteristici pe baza căruia să se construiască un sistem de metrici cu care calitatea unuia

sau mai multor produse software să fie evaluată, setul selectat trebuie să aibă următoarele proprietăţi:

- să fie apreciat complet de către evaluatori, în sensul de a putea surprinde toate aspectele calităţii în

care evaluatorii sunt interesaţi (prin evaluatori se înţeleg persoanele autorizate şi în cunoştinţă de cauză,

interesate în evaluarea calitativă a produsului, a organizaţiei producătoare sau a sistemului calităţii, respectiv

producători, beneficiari, auditori);

- să fie ierarhizabii, în sensul ca principalele caracteristici să poată fi descompuse în factori ce pot

cuantificaţi cu ajutorul metricilor;

- să fie necontradictoriu - caracterul contradictoriu al unor caracteristici nu poate fi eliminat

în totalitate, fiind practic imposibil să se dezvolte un set de caracteristici perfect consistent. Astfel,

complexitatea vine în contradicţie cu fiabilitatea, portabilitatea cu eficienţa, etc. Ca urmare, pentru elaborarea

unor specificaţii pe baza unui set de caracteristici de calitate ce presupun aspecte contradictorii, fie se pot

stabili anumite nivele pentru anumite caracteristici, celelalte păstrându-se în limite acceptabile sau lăsându-se

la dispoziţia priceperii proiectanţilor şi programatorilor, fie se stabileşte un sistem de priorităţi specificate

explicit. De exemplu, în cadrul unui produs software, anumite programe/module trebuie să se execute mai

rapid, iar altele să fie prevăzute cu proceduri suplimentare de verificare şi testare a corectitudinii datelor,

chiar dacă aceasta duce la încetinirea duratei de execuţie.

La nivel general, sistemul trebuie să se bazeze, conform [BRĂ1], pe următoarele considerente

elementare:

5

1. conexiunea elementelor interne ale sistemului să fie mai puternică decât legăturile sistemului cu

mediul. Aceasta se realizează prin selectarea pe anumite criterii (specificaţiile beneficiarilor, urmărirea de

către producător a unor anumite caracteristici specifice clasei din care face parte produsul software respectiv,

etc), a caracteristicilor de calitate incluse;

2. orice sistem, indiferent de complexitatea sa este un subsistem al unui sistem mai cuprinzător. în

toate situaţiile, sistemul caracteristicilor de calitate ce urmează a fi construit este doar un subsistem al calităţii

software;

3. unitatea şi complexitatea unui sistem presupune o anumită ordine în aşezarea şi funcţionarea

elementelor sale;

4. orice sistem este caracterizat printr-o anumită structură, care poate fi privită ca atare, adică sub

forma exactă de reunire a tuturor subsistemelor sau prin urmărirea diferitelor structuri componente;

5. orice subsistem poate avea o multitudine de bucle de reacţie care se închid pe anumite porţiuni de

proces, pe anumite porţiuni de sistem sau chiar la nivelul întregului sistem. Acest lucru se traduce la nivelul

sistemului caracteristicilor de calitate prin interdependenţele şi contradicţiile existente între caracteristici. Cea

mai dificilă problemă a sistemului calităţii software este cercetarea mecanismului specific al interacţiunii

dintre diferitele caracteristici de calitate ale sistemului, problemă posibil de soluţionat doar prin

managamentul calităţii.

Obţinerea unui sistem operaţional de caracteristici - modelul calităţii - pe baza căruia să se poată

realiza managementul şi gestiunea calităţii, presupune parcurgerea unor etape anterioare obligatorii, astfel:

a) definirea problemei - în care se stabilesc caracteristicile şi factorii de calitate ce vor fi luaţi în

considerare;

b) construirea modelului calităţii - analiza şi modelarea relaţiilor dintre componente, a modului de

interacţiune, a interdependenţelor, precum şi alegerea unui criteriu de performanţă. Această alegere este

parţial determinată de felul în care este precizată problema;

c) stabilirea soluţiei - o soluţie este obţinută când se apreciază că răspunsul obţinut la un moment dat

este cel mai bun în comparaţie cu criteriile stabilite;

d) omologarea soluţiei - omologarea soluţiei obţinute pe baza modelului - rezultat al procesului de

optimizare. Se poate face prin:

A. compararea cu performanţele precendete sau ale altor produse concurente pe piaţă - superioritatea

noii soluţii poate fi considerată ca o verificare a valabilităţii ei. Inconvenientul acestei metode constă în aceea

că în evaluarea calităţii oricărui produs pe o perioadă trecută toate intrările sunt cunoscute şi elemente

importante ale luării deciziei (variaţiile probabilistice ale pieţei, obişnuinţele utilizatorilor, etc.) sunt astfel

eliminate.

B. compararea cu performanţele viitoare - constă în compararea soluţiilor supuse la seturi de date de

intrare externe identice, faţă de una din ele. Inconvenientele sunt în principal legate de timp şi cost ridicat

pentru alcătuirea seturilor respective de date, elaborarea sau luarea în calcul a unor variante diferite ale

produsului, obţinerea şi analiza rezultatelor sumare comparative. în plus, oricât de exhaustiv ar fi elaborate

seturile de date de test, în cazul produselor complexe, acestea nu pot fi atotcuprinzătoare, neputându-se trage

concluzii privind alte seturi de date de intrare.

C. comparaţia prin simulare - experimentările repetate satisfac caracteristicile unor încercări în

condiţiile unor date de intrare externe diferite şi alese la întâmplare. Dar, aşa cum se arată în [BRĂ1], şi

această metodă generează probleme specifice care pot reduce contribuţia sa la rezolvarea problemei.

5. Definirea caracteristicilor de calitate. Modele ale sistemelor caracteristicilor de

calitate software În literatura de specialitate, atât din ţară cât şi străină, se găsesc numeroase definiri şi ierarhizări ale

caracteristicilor de calitate [ISO1], [STU1], [B0E1], [TAT1], [THA1], [BARO1], [BARO2], [BARO3],

[MCC1]. Unii autori folosesc doar termenul de caracteristici de calitate, alţii le grupează în caracteristici şi

atribute, caracteristici şi factori sau caracteristici şi subcaracteristici.

Se vor trata în continuare câteva caracteristici de calitate, pe baza definirilor făcute în [ISO1], [BAR01]

şi [BAR03].

Funcţionalitatea este definită în standardul ISO/IEC 9126, [ISO1], ca un set de atribute bazate pe

existenţa unui set de funcţii şi pe proprietăţile lor specificate. Funcţiile satisfac necesităţile stabilite sau

implicate. Acest set de atribute ce defineşte funcţionalitatea, arată "ce face" produsul software pentru a

îndeplini cerinţele, pe când alte seturi răspund la întrebările "când" şi "cum" corespunde nevoilor produsul

respectiv. Referirea la nevoile stabilite sau implicate se face pe baza definiţiei calităţii din standardul ISO

8402 [ISO3]: "totalitatea trăsăturilor şi caracteristicilor unui produs sau serviciu care se bazează pe abilitatea

6

sa de a satisface nevoile stabilite sau implicate". într-un context contractual nevoile sunt stabilite, specificate,

pe când în alt context nevoile implicate trebuie identificate şi definite.,

Fiabilitatea este privită în [BARO1] ca măsura încrederii pe care o avem în concepţia şi în capacitatea

unui program de a funcţiona corect în toate condiţiile avute în vedere de la început. Această definiţie se

referă mai mult la fiabilitatea procesului decât la cea a programului, fiind legată de probabilitatea ca o eroare

din program să fie activată de un set specific de intrări. Fiabilitatea produselor software este caracteristica ce

exprimă poate cel mai bine particularităţile acestei industrii, dacă abordăm problema în comparaţie cu

fiabilitatea produselor hardware. Există abordări cantitative ale fiabilităţii, exprimate prin probabilitatea ca un

produs software să-şi îndeplinească funcţiunile cu anumite performanţe şi fără erori într-un interval de timp

şi în condiţii de exploatare date, precum şi abordări calitative ce privesc fiabilitatea ca o capacitate a

produsului software. Standardul ISO/IEC 9126 [ISO1], defineşte fiabilitatea ca un set de atribute care se

bazează pe capabilitatea produsului software de a-şi menţine nivelul de performanţă în condiţii şi pe o

perioadă de timp stabilite. Limitele fiabilităţii unui produs software se datorează erorilor din etapele de

formulare a cerinţelor, proiectare şi implementare. Căderile datorate acestor erori depind de modul şi

condiţiile în care este utilizat produsul. Corespunzător ciclului de viaţă al produsului software, putem

distinge o fiabilitate previzională sau proiectată, o fiabilitate experimentală şi o fiabilitate operaţională (la

beneficiar).

Utilizabilitatea este definită în [ISO1] ca un set de atribute bazate pe efortul necesar pentru a utiliza

produsul software şi pe evaluarea individuală a utilizării produsului, de către un grup stabilit sau implicat de

utilizatori. Standardul dă termenului de utilizatori un înţeles foarte larg, incluzând operatori, utilizatori finali

şi indirecţi, precum şi toate categoriile de persoane care îşi desfăşoară activitatea dependent sau sub influenţa

utilizării produsului software respectiv.

Eficienţa produselor software este definită în [BAR03] ca o corelaţie optimă între consumul de resurse

al produsului şi complexitatea problemei de rezolvat. Tot în acest material se arată că eficienţa poate fi

exprimată prin introducerea noţiunii de output al produsului software, definită ca o relaţie între complexitatea

datelor iniţiale şi a rezultatelor finale. Standardul ISO/IEC 9126 [ISO1], defineşte eficienţa tot ca pe o

corelaţie, dar nu între consumul de resurse şi complexitatea problemei, ci ca un set de atribute bazate pe

relaţia dintre nivelul de performanţă al produsului software şi cantitatea de resurse utilizate, în anumite

condiţii stabilite. Spre deosebire de [BAR01], standardul [ISO1] lărgeşte mult categoria resurse consumate,

incluzând atât memoria, timpul de execuţie, precizia cât şi cantitatea de hârtie utilizată, serviciile de operare,

mentenanţă sau suport de personal.

Mentenabilitatea este definită în [ISO1] ca un set de atribute bazate pe efortul necesar pentru a face

modificările specificate în produsul software respectiv. Modificările includ corecţii, îmbunătăţiri sau

adaptări la modificări ale platformelor (de dezvoltare, ţintă, etc), modificări în cerinţe şi specificaţii

funcţionale. Conform [BAR03], un produs software este mentenabil în măsura în care permite o rapidă şi

uşoară actualizare astfel încât să poată fi utilizat în continuare în bune condiţii. Actualizările din această

definiţie sunt privite în sens mult mai restrâns. Ele referindu-se numai la operaţii la nivelul produsului

software, al modulelor, secvenţelor de instrucţiuni şi instrucţiunilor. Nivelul mentenabilităţii se poate stabili

pe baza datelor obţinute în etapele de proiectare, testare şi utilizare curentă. Evaluarea acestei caracteristici se

bazează pe datele obţinute indirect prin examinarea influenţei modificărilor asupra celorlalte caracteristici

de calitate, cum ar fi complexitatea, testabilitatea, modularitatea, etc. Un factor care determină obţinerea unei

mentenabilităţi corespunzătoare este corelarea strictă a nivelului de complexitate cu funcţia de procesare

îndeplinită de fiecare modul.

Portabilitatea este definită în [ISO1] ca un set de atribute bazate pe facilitatea pe care trebuie să o ofere

produsele software în direcţia transferării dintr-un mediu în altul. înţelegând prin mediu nu numai contextul

hardware şi/sau software, ci şi cadrul organizaţional, standardul ISO/IEC 9126 - [ISO1] - extinde

considerabil limitele cerinţelor impuse portabilitatăţii. Restrângând mult limitele, în [BARO3] portabilitatea

se defineşte ca o caracteristică de ordin calitativ a programelor ce pot fi rulate pe mai multe tipuri de

calculatoare. Programele sunt considerate portabile nu numai dacă pot fi implementate pe mai multe tipuri de

calculatoare direct, fără alte modificări ci şi dacă execuţia pe alte tipuri de sisteme de calcul necesită

modificări de mică anvergură şi un efort de programare mult mai mic decât cel cerut de rescrierea acestor

programe. Un aspect deosebit al acestei caracteristici este legat de portabilitatea compilatoarelor, de diferitele

facilităţi video şi audio oferite de sistemele de calcul şi folosite în programele de aplicaţie. Abordarea diferită

a acestei caracteristici de calitate, la sfârşitul anilor '90, este relevată şi de preocupările pentru crearea de

sisteme ieftine, care pot deveni staţii de lucru în mai multe tipuri de reţele, rulând programe dezvoltate pe

platforme ţintă diferite - UNIX, Windows, DOS, VMS - având în spate puterea reţelei globale - Internet.

7

Interoperabilitatea considerată de mai mulţi autori un atribut al calităţii, reprezintă, conform

[BARO3], capacitatea produsului software de cuplare cu alte produse. Acest atribut permite reutilizarea unor

programe pentru construirea unor aplicaţii complexe. Cuplarea se poate asigura direct sau folosind interfeţe.

Problema interfeţelor şi a bibliotecilor de funcţii prin care pot fi cuplate aplicaţii, a stat la baza dezvoltării

unor concepte, programe şi specificaţii deosebit de complexe. Exemple elocvente sunt specificaţiile Open

Database Connectivity, utilizate în aplicaţiile de baze de date, API-urile dezvoltate de Microsoft odată cu

sistemul Windows sau Object Linking and Embedding - încapsularea şi înlănţiurea obiectelor - set construit

folosind tehnica obiectelor, prin care obiecte construite de unele aplicaţii sunt accesibile şi altor aplicaţii.

Complexitatea este probabil atributul sau caracteristica de calitate pentru care s-au dezvoltat cele mai

multe sisteme de metrici şi care a fost studiată în corelaţie cu mai multe caracteristici, în special cu

fiabilitatea, mentenabilitatea, stabilitatea, etc. Acest atribut a fost abordat fie studiind codul sursă al

programelor, fie prin intermediul grafurilor asociate programelor, grafuri în care nodurile corespund

structurilor de control iar arcele arată fluxul execuţiei. Din prima categorie de abordări fac parte sistemele de

metrici Halstead şi combinaţii ale acestora - [BAR02], [TEO1] - iar din a doua categorie, metrica cea mai

reprezentativă este complexitatea ciclomatică, dezvoltată de T.McCabbe [MCC1]. în [MUN1] şi [RADI] se

propun noi metrici pentru măsurarea complexităţii, obţinute prin combinarea celor două categorii amintite,

utilizând metoda statistică a analizei factorilor. Elaborarea unor modele pertinente pentru studierea şi

predicţia complexităţii produselor software este importantă pentru programarea resurselor umane, materiale,

financiare şi de timp, necesare proiectării şi implementării programelor de complexităţi diferite. De

asemenea, complexitatea influenţează şi cheltuielile ulterioare punerii în funcţiune a produsului (post-

vânzare, service, asistenţă tehnică), precum şi eforturile de a dezvolta noi versiuni sau de a rescrie produsul şi

pe/pentru alte platforme.

Modele ale sistemelor caracteristicilor de calitate software Modelele cunoscute, ce apar în literatura de specialitate, valorifică experienţa câştigată în elaborarea

unor proiecte, şi, plecându-se de la anumite necesităţi practice ale aplicaţiilor şi de la un set iniţial de

caracteristici, prin rafinare, ordonare şi diminuarea redundanţelor, se ajunge la construirea unei arborescente

a caracteristicilor. Arborele respectiv are cel puţin două nivele, deosebindu-se o structură de nivel înalt care

înglobează caracteristici generale agregate şi o structură de nivel scăzut (elementar), care cuprinde

caracteristicile "primitive" (subcaracteristici, factori). Se porneşte de la ideea simplificatoare că toate

caracteristicile de nivel înalt se obţin prin agregarea caracteristicilor primitive. Descompunerea

caracteristicilor generale în caracteristici de nivel inferior (pentru care se mai folosesc şi alţi termeni: factori,

primitive, etc), este necesară deoarece astfel se pot urmări/cuantifica în procesul de elaborare, respectivele

caracteristici de calitate.

Caracteristicile de pe nivelele superioare se constituie în modelul calităţii, prin care se reflectă

scopurile urmărite în construirea calităţii produsului software şi la evaluarea generală a acestuia, iar cele de

pe nivelurile inferioare asigură fundamentarea controlului măsurii în care produsul posedă caracteristicile de

calitate respective şi punctul de plecare în elaborarea, adoptarea sau adecvarea sistemelor de metrici.

Pentru identificarea legăturilor se construiesc diagrame în care, prin arcele incidente, este reprezentată

relaţia "dependentă de", iar prin arcele descendente relaţia "determină pe". De exemplu, pentru fiabilitate, se

pot reprezenta relaţiile din figura 2.1. de mai jos.

8

Figura 2.1. Model al sistemului de caracteristici ale

calităţii

Independenţă hardware

Completitudine

Acurateţe

Consistenţă

Eficienţă hardware

Accesibilitate

Comunicativ

Structuralitate

Autodescriere

Conciziune

Claritate

Extensibilitate

Portabilitate

Utilitate

Utilitate

generală

Mentenabilitate

Fiabilitate

Eficienţă

Factori umani

Testabilitate

Uşor de înţeles

Modificabilitate

Comunicativ

În exemplul de mai sus, s-au luat în considerare un număr destul de mare de caracteristici de calitate

care vin în relaţie cu fiabilitatea şi, cu toate acestea, mai puteau fi găsite şi altele, cum ar fi recuperabilitatea

sau structuralitatea. Acest gen de abordare conduce însă la un model inaplicabil.

Maturitate

Acurateţe

Toleranţa la erori

Consistenţă

Complexitate

Corectitudine

Stabilitate

Integritate

Fiabilitate

Maturitate

Utilitate

9

De fapt, graful se construieşte din setul iniţial, limitat, de caracteristici - alese în funcţie de specificul

problemei, al prelucrării şi al specificaţiilor beneficiarilor - şi pe baza relaţiilor de precedenţă şi de

descendenţă, apoi se rafinează succesiv până se ajunge la un model coerent, exhaustiv şi necontradictoriu şi,

ceea ce este mai important, un model aplicabil în continuare.

în Anexa 1 se prezintă patru modele de sisteme de caracteristici, dezvoltate în străinătate şi în ţară, şi

anume modelul Boehm (Anexa IA), modelul McCall (Anexa 1B), un model românesc elaborat la I.C.I.

Bucureşti (Anexa IC) şi modelul ISO/IEC statuat de standardul ISO 9126 (Anexa 1D), având unii parametrii

prezentaţi în tabelul de mai jos (tabelul 2.1).

Tabelul 2.1.

Modelul

Boehm

Modelul

McCall

Modelul

I.C.I.

Modelul

ISO 9126

Număr de caracteristici de

nivel înalt 10 11 6 6

Număr de caracteristici de

nivel scăzut 12 22 19 21

Număr total de caracterisitici 22 33 25 27

Număr de nivele în arbore 4 2 2 2

Caracteristicile de nivel scăzut

determină mai mult de o

caracteristică de nivel înalt ?

Da Da Nu Nu

La primele două modele (Boehm şi McCall), există mai multe caracteristici primitive, care determină

mai multe caracteristici de nivel înalt. De exemplu, în cazul modelului Boehm, completitudinea determină

atât portabilitatea cât şi fiabilitatea iar în cazul modelului McCall consistenţa determină corectitudinea,

fiabilitatea şi mentenabilitatea. In aceste cazuri, decompoziţia caracteristicilor de nivel superior în

caracteristici primitive, determină deplasarea interdependenţelor şi redundanţelor dintre caracteristicile

structurii de nivel înalt către structura de nivel inferior. Modelul McCall explicitează relaţiile dintre cele 11

caracteristici principale luate în considerare, într-un tabel anexă.

Celelalte două modele (I.C.I. şi ISO) sunt mai coerente din acest punct de vedere, pentru că, deşi nu se

poate spune că nu există interdependenţe "încrucişate" între caracteristici, acestea nu sunt integrate în model.

De fapt, pentru modelul ISO/IEC 9126 - [ISO1] - structura de nivel inferior a modelului nu face parte din

standard ci este doar o propunere a ISO şi International Electrotechnical Commission.

6. Metrici şi sisteme de metrici ale caracteristicilor de calitate software. Scalare,

clasificare şi evaluare conform standardului ISO/IEC 9126 Deşi modelul calităţii încorporează recunoaşterea obiectivelor relevante şi, implicit, a caracteristicilor

de calitate aferente, din toate perspectivele relevante (utilizator, inginer software, manager, vânzător, etc),

construirea unui sistem particularizat al caracteristicilor de calitate, nu reprezintă decât puntea către reala

măsurare şi evaluare, procese de egală importanţă în obţinerea calităţii dorite.

Conform [TRI3], pe baza unei corecte definiri a obiectivelor operaţionale ale părţilor implicate, trebuie

determinate metricile necesare pentru fiecare caracteristică sau factor (metrici "obiective", "consacrate", sau

cu caracter subiectiv). în [BAK1] se arată că pentru ca rezultatele să fie semnificative, măsurarea calităţii

produselor software cu ajutorul metricilor, trebuie să fie fundamentată din punct de vedere teoretic, iar

rezultatele empirice trebuie să fie obţinute printr-o bună proiectare a experimentării.

Teoria măsurătorilor prevede un cadru pentru caracterizarea numerică a proprietăţilor sau atributelor

intuitive ale obiectelor sau evenimentelor. Aplicarea criteriilor teoriei măsurătorilor la măsurarea calităţii

produselor software necesită identificarea şi/sau definirea:

− caracteisticilor, atributelor, produselor sau proceselor software;

− modelele formale sau abstracţiunile ce captează sau structurează aceste caracteristici sau

atribute;

− relaţiile importante, ordonările, ierarhizările existente între obiectele modelate, determinate de

atributele modelelor;

− maparea pe sisteme numerice, prezervând relaţiile de ordine. Această ultimă idee constituie

baza teoriei reprezentaţionale a măsurătorilor. Dacă toate criteriile de mai sus sunt satisfăcute,

autorii [BAK1] definesc rezultatul final al acestei mapări ca o măsură software. O mapare

arbitrara care nu satisface în mod necesar primele trei criterii, este definită ca o metrică.

10

Pentru a putea folosi măsurile software în predicţii şi planificări ale calităţii software, este necesar să

existe sau să fie definite:

− două sau mai multe măsuri ale caracteristicilor sau atributelor;

− o idee, o supoziţie sau chiar o teorie care pune în relaţie măsurile respective, necesară pentru

confirmarea sau infirmarea cauzalităţii;

− o demonstraţie empirică a teoriei respective.

În încercarea de structurare a măsurilor şi metricilor software din [BAK1], acestea sunt referite ca două

concepte separate: măsurile definite asupra unor caracteristici sau obiecte pe care le caracterizează numeric şi

sistemele de predicţie ce implică un model matematic şi anumite proceduri.

Pentru a putea fi operaţionalizate, metricile şi măsurile trebuiesc validate. Validarea măsurilor se

defineşte ca fiind procesul prin care se asigură că măsura reprezintă o caracterizare numerică adecvată şi

fidelă a unui anumit atribut. Prin validare se dovedeşte că măsura sau metrica respectivă este bine definită şi

consistentă. Validarea măsurilor (numită şi validare internă), vizează, luarea în considerare a modelelor

formale utilizate în captarea atributelor şi caracteristicilor.

Validarea sistemelor de predicţie reprezintă procesul empiric prin care se stabileşte acurateţea

sistemului respectiv într-un mediu dat, prin mijloace empirice (de exemplu comparând performanţele unui

model cu date punctuale brute, cunoscute dintr-un anumit mediu). Atât timp cât nu există o anumită ipoteză

despre capabilităţile predictive ale unor asemenea măsuri, ele nu pot fi validate în totalitate prin corelarea cu

anumite date disponibile la un moment dat. Pentru o validare completă este necesară şi validarea externă,

prin corelarea consistentă a măsurii cu seturi de date, prin formule determinate iniţial, pe baza unei analize de

regresie. Validarea externă se distinge astfel de validarea internă efectuată iniţial pentru a arăta că măsura

respectivă măsoară efectiv un anumit atribut. Validarea externă a măsurii m este deci procesul prin care se

stabileşte o relaţie consistentă între m şi seturi de date empirice presupuse a măsura un anumit atribut.

Autorii articolului [BAK1] arată că, dată fiind slaba înţelegere (încă) a relaţiilor dintre produsele

software şi procese, validarea externă pare a fi extrem de ne-fiabilă. Cu toate acestea, specialiştii în domeniu

sunt gata să accepte această abordare a validării, atât timp cât măsurile propuse reuşesc să capteze înţelegerea

şi concepţiile intuitive asupra atributelor respective. Măsurile corecte pot fi dezvoltate când caracteristicile

sau atributele respective sunt definite ne-ambiguu, modelate corect şi inteligibile.

în [PFL1] se pune în legătură modelul maturitate/capabilitate elaborat la Software Engineering Institute

(S.E.I.), în S.U.A., cu utilizarea unor anumite tipuri de măsuri şi metrici. Astfel, modelul amintit, care descrie

un set de nivele de maturitate în care se încadrează procesele de dezvoltare software dintr-o organizaţie, este

folosit drept cadru de plasare a metricilor şi măsurilor software, pornindu-se de la ideea că numai când

procesul de dezvoltare este suficient de bine structurat şi procedural are sens culegerea anumitor tipuri de

date (a se vedea tabelul 2.8).

Tabelul 2.8.

Nivel Caracteristici Metrici

5. Optimizat Îmbunătăţirea procesului

prin feed-back

Referitoare la proces + feed-back pentru

modificarea procesului

4. Condus şi

controlat

Proces măsurat (cantitativ) Referitoare la proces + feed-back pentru

controlul procesului

3. Definit Proces definit,

instituţionalizat

Referitoare la produs

2. Repetabil Proces dependent de

individualităţi

Referitoare la proiect

1. Iniţial Abordare ad-hoc a

procesului de dezvoltare

Măsuri elementare

Pentru nivelul 1 se pot face măsurători elementare referitoare la dimensiunea produsului, efortul de

dezvoltare, pentru a determina un nivel estimativ al productivităţii. în nivelul 2 de maturitate nu sunt

disponibile măsurării activităţile care realizează transformarea intrărilor în ieşiri, astfel că, pe acest nivel pot

fi aplicate numai metrici referitoare la proiect. La un proces repetabil se poate măsura efortul necesar pentru

dezvoltarea unui sistem, durata unui proiect, dimensiunea cerinţelor, costul total al proiectului, etc. De

exemplu, se pot utiliza metricile:

numărul de linii de cod;

numărul de obiecte şi metode (în cazul POO);

luni-persoană de efort;

volumul schimbărilor în definirea cerinţelor;

11

anii de experienţă în domeniu, într-un anumit tip de aplicaţii, arhitecturi sau metode.

Al treilea nivel de maturitate a proceselor dintr-o organizaţie producătoare de software se numeşte

definit, deoarece activităţile sunt clar definite, cu puncte şi condiţii de intrare şi ieşire. Aceasta înseamnă că

se pot examina intrările şi ieşirile fiecărei activităţi funcţionale definite şi executate în timpul dezvoltării

produsului software. Această caracteristică permite măsurarea produselor intermediare.

Metricile recomandate în [PFL1] pentru această etapă sunt:

complexitatea cerinţelor, măsurată prin numărul de acţiuni şi obiecte distincte referite în

cerinţe;

complexitatea proiectării, măsurată prin numărul de module proiectate, complexitatea

proiectării McCabe;

complexitatea testării măsurată prin numărul de căi de test, numărul de obiecte de

interfaţă testate;

numărul de defecte descoperite, numărul de defecte descoperite per unitate, modul, etapă,

activitate (densitatea defectelor), densitatea defectelor pentru fiecare produs intermediar;

numărul de pagini de documentaţie intermediară, numărul de pagini de documentaţie

pentru produsul final.

Procesul condus şi controlat ("managed process") de pe nivelul patru de maturitate oferă posibilitatea

utilizării unor informaţii din activităţi ale dezvoltării anterioare procesului curent (de exemplu problemele

descoperite în etapa de proiectare, testare, etc) ca feed-back pentru îmbunătăţirea activităţilor din aval. De

fapt, într-un asemenea tip de proces feed-back-ul determină modificarea desfăşurării resurselor, activităţile de

bază rămânând neschimbate. Pe acest nivel de maturitate al procesului pot fi colectate şi analizate date

referitoare la întregul proces. în [PFL1] se recomandă la acest nivel culegerea următoarelor tipuri de date:

date referitoare la modelul de proces (de tip cascadă, prototipizare);

volumul obiectelor proiectate şi realizate pentru a fi reutilizate, în ce măsură produsul este

proiectat pentru reutilizare (cerinţe, proiecte de module, planuri de test, cod);

volumul reutilizării la producere, în ce măsură proiectul reutilizează componente

de la alte proiecte;

identificarea defectelor, cum şi unde sunt descoperite defectele (în timpul revizuirii

cerinţelor, proiectelor, inspecţiilor pe cod, în fazele de testare);

utilizarea managementului configuraţiei: este impusă procesului de dezvoltare o

schemă de management al configuraţiei? Managementul configuraţiei şi controlul

muncii de modificare permit managementului de proiect exercitarea unui control mai

eficace al procesului de dezvoltare? Managementul configuraţiei determină şi o evaluare a

impactului alterărilor şi modificărilor în activităţi şi/sau produse?;

rata de realizare a modulelor: timpul mediu în care modulele sunt identificate, proiectate,

codificate, testate şi integrate, reflectă gradul în care procesul şi mediul de dezvoltare

facilitează implementarea şi testarea?

Determinarea unor relaţii clare dintre caracteristicile produsului şi variabilele ce caracterizează

procesul de dezvoltare ajută la evaluarea măsurii în care procesul sau activităţile acestuia corespund

obiectivelor de calitate şi productivitate ale organizaţiei.

Un proces optimizat este ultimul nivel de maturitate din cadrul modelului. în acest stadiu, măsurile şi

metricile sunt utilizate pentru modificarea şi îmbunătăţirea procesului. Modificările procesului pot afecta atât

organizaţia cât şi procesul în desfăşurare. De exemplu, în cadrul acestui tip de proces, dacă metricile indică,

în timpul activităţilor de definire şi proiectare a cerinţelor, un grad ridicat de incertitudine, tipul de proces

poate fi modificat din cascadă în prototipizare, pe baza acestor informaţii. Astfel, un proces optimizat ar oferi

maximum de flexibilitate dezvoltării software. Metricile s-ar comporta ca senzori iar procesul nu ar fi numai

sub control ci şi dinamic. Conform studiilor S.E.I., acest nivel de maturitate nu a fost încă atins de nici o

organizaţie producătoare de software.

Metricile sunt folositoare în condiţiile în care sunt implementate într-o secvenţă bine fundamentată de

activităţi. Paşii de urmat în utilizatea metricilor, conform [PFL1], sunt:

1 - evaluarea procesului;

2 - determinarea metricilor şi a datelor ce trebuie colectate;

3 - determinarea celor mai potrivite tehnici şi instrumente pentru a fi utilizate în cadrul proiectului;

4 - estimarea costului şi programului proiectului;

5 - determinarea nivelului metricilor;

6 - construirea unei baze de date a proiectului;

12

7 - evaluarea costului şi a programului proiectului;

8 - evaluarea productivităţii şi a calităţii;

9 - formarea unei baze pentru estimări viitoare.

Scalare, clasificare şi evaluare conform standardului ISO/IEC 9126 După cum se autodefineşte, standardul ISO 9126 [ISO1], este aplicabil în definirea cerinţelor de

calitate ale produselor software şi în evaluarea calităţii produselor software, ceea ce include:

− definirea cerinţelor de calitate ale produsului software;

− evaluarea specificaţiilor pentru a asigura îndeplinirea cerinţelor de calitate în timpul procesului

dezvoltării produsului software;

− descrierea facilităţilor şi atributelor produselor software (de exemplu în manuale ale

utilizatorilor);

− evaluarea, înainte de livrare, a produselor software dezvoltate;

− evaluarea produselor software înainte de acceptare.

în anexa B a standardului, în mod edificator, se prezintă şi cerinţele care au dus la alegerea

caracteristicilor descrise în acest standard, şi anume:

− să acopere împreună toate aspectele calităţii software, aşa cum rezultă din definirea calităţii în

standardul [ISO3];

− să descrie calitatea produsului cu un minim de suprapunere;

− să fie cât mai aproape de terminologia stabilită - consacrată;

− să formeze un set de şase până la opt caracteristici din raţiuni de claritate şi uşurinţă în lucrul cu

modelul;

− să poată fi identificate zone de atribute ale calităţii produselor software pentru rafinări viitoare.

Rafinarea şi dezvoltarea în continuare a celor şase caracteristici de bază oferite de standard se face în

funcţie de tipul produsului software. Deşi nu există o clasificare unanim acceptată a acestora, standardul

împarte produsele software în. trei clase: sisteme software cu misiuni critice (pentru care fiabilitatea este

esenţială); sisteme software cu criticitate în timp real (pentru care eficienţa este cea mai importantă

caracteristică) şi sisteme software interactive orientate către utilizatori (pentru care utilizabilitatea este cea

mai importantă).

În Anexa 2 se prezintă modelul procesului de evaluare propus de standardul ISO 9126 [ISO1], proces

ce presupune trei etape: definirea cerinţelor de calitate, pregătirea evaluării şi procedura de evaluare. Etapa

de pregătire a evaluării cuprinde activităţile de selecţie a metricilor, definirea nivelelor de clasificare şi

definirea criteriilor de evaluare, iar etapa de evaluare cuprinde activităţile de măsurare, de clasificare şi de

evaluare.

Conform standardului, acest proces poate fi aplicat în fiecare fază a ciclului de viaţă, pentru fiecare

componentă a produsului software.

Standardul ISO/IEC 9126 consacră în cadrul modelului general al procesului de evaluare, o etapă

distinctă metricilor şi măsurătorilor. Atât acest standard cât şi standardul ISO 9000-3 statuează că,

deocamdată, nu există metrici universal acceptate. Astfel, modelul de proces de evaluare oferă un cadru

extrem de larg şi general pentru scalare şi clasificare.

Maniera în care se definesc caracteristicile de calitate - atât în general cât şi în standardul analizat - nu

permite măsurarea lor directă. De aici apare necesitatea decompoziţiei acestora în caracteristici de nivel mai

scăzut (subcaracteristici, atribute, factori), cărora li se pot asocia metrici care să le reflecte cât mai fidel

nivelul.

Metrica este definită în cadrul standardului ISO/IEC 9126 [ISO1] ca fiind orice proprietate

cuantificabilă a produselor software sau orice interacţiune cuantificabilă a produsului software cu mediul,

care poate fi corelată cu o caracteristică de calitate - direct sau printr-o subcaracteristică/factor/atribut.

Metricile diferă în funcţie de mediu şi de faza procesului de dezvoltare software în care sunt utilizate.

Standardul recomandă ca metricile utilizate să fie corelate cu punctul de vedere al utilizatorului, acesta fiind

crucial.

13

Figura 2.2. Scala de valori ale metricilor, divizată în regiuni corespunzătoare diferitelor grade de

satisfacţie

Rezultatul măsurătorilor, respectiv valorile măsurate ale metricilor, sunt mapate pe o scală. Valoarea în

sine nu arată un anumit nivel de satisfacţie, aspectul cantitativ trebuind să fie proiectat în continuare într-o

clasificare de ordin calitativ. Ca atare, scala de valori este divizată în regiuni corespunzătoare diferitelor

grade de satisfacţie (a se vedea figura 2.2).

Atât timp cât calitatea vizează nevoi date, concrete şi particulare, nu este posibil să fie stabilite nivele

generale de clasificare, acestea trebuind să fie definite pentru fiecare evaluare specifică.

Pentru o evaluare coerentă a calităţii unui produs software, rezultatele evaluării diferitelor caracteristici

trebuie să fie agregate, pe baza unor criterii de evaluare. Evaluatorul trebuie să pregătească o procedură,

utilizând de exemplu, tabele de decizie sau medii ponderate (metoda punctajului) [NICI]. Metoda punctajului

acordă un număr de puncte caracteristicilor de calitate. Calitatea produsului este superioară când numărul de

puncte acordat este mare. Coeficientul de apreciere prin punctaj (Kp) se determină astfel:

100

pqK p

unde q este ponderea fiecărei caracteristici de calitate iar p numărul de puncte acordat caracteristicii

respective.

Procedura mai include, de obicei, pe lângă valorile măsurate ale metricilor, şi alte aspecte cum ar fi

durata sau costul, care contribuie la evaluarea calităţii unui produs software într-un mediu particular.

Nivelul calităţii exprimat agregat stă la baza unor decizii manageriale, fundamentate pe criterii de ordin

managerial.

Un exemplu de evaluare a calitatii a doua variante de TI vezi tabelele urmatoare

Suficient

Insuficient

Bun

Excelent

valori

măsurate nivel de

clasificare

Satisfăcător

Nesatisfăcător

Nivelul calitatii pentru varianta 1 a TI (indicii particulari)


14


15

Ponderea fiecărei caracteristici de calitate

Coeficientul de apreciere a calitatii generale a TI pentru variantele 1 şi 2 ale TI

16

7. Abordarea orientată pe produs şi controlul dezvoltării software Considerarea calităţii ca o mărime ce poate fi măsurată exact, este principala caracteristică a abordării

bazate pe produs. Rezultă de aici o definire a calităţii ca un ansamblu de caracteristici, diferenţele d intre

caracteristicile de calitate ale produselor constituindu-se în diferenţe de ordin calitativ între acestea. Conform

[OLA1], o asemenea abordare se regăseşte, în special, în lucrările de teorie economică şi de calimetrie:

stabilirea unei corelaţii stricte între variaţia caracteristicilor şi nivelul calităţii produselor, a favorizat

introducerea modelării matematice pentru estimarea acestui nivel. Sistemele calităţii construite pe baza

abordării calităţii orientate pe produs, denumite şi sisteme de calitate tradiţionale, determină concentrarea

eforturilor organizaţiilor producătoare de software asupra minimizării insatisfacţiei utilizatorului. Aceste

sisteme se focalizează asupra detectării şi corectării defectelor, utilizând intensiv testările, auditurile şi

inspecţiile. Datele rezultate din măsurări statistice, metrici, testări, audituri şi inspecţii sunt înregistrate şi

analizate în vederea îmbunătăţirilor ulterioare. Cu toate acestea, dezvoltarea de software în sistem tradiţional

rămâne lipsită de coerenţă, datorită, în principal, specificului acestei industrii.

"Un sistem stabil este un sistem a cărui performanţă este previzibilă. Un sistem stabil se atinge prin

eliminarea, una câte una, a cauzelor ce produc disfuncţiile, detectate cel mai bine prin semnalele indicatorilor

statistici" - W. Edwards Deming. Adesea, abordarea problemei calităţii prin prisma produsului se confundă

prea mult cu abordarea pur statistică a problemei calităţii. Atât concepţiile lui P. Crosby cât şi cele ale lui E.

Deming sunt derivate din experienţa acestora în studiul calităţii în industria manufacturieră. Dezvoltarea de

software nu este o industrie de tip manufacturier şi de aceea "semnalele indicatorilor statistici" ale lui

Deming, deşi necesare, nu sunt suficiente pentru control, deoarece nu există suficientă repetiţie (deci

stabilitate) în procesul de dezvoltare de software, pentru ca indicatorii statistici comuni să poată fi

semnificativi. Cu alte cuvinte, în industria de software, fenomenele de masă sunt aproape inexistente. De

aceea, pentru caracterizarea reală a calităţii produsului software, este necesară îmbinarea ideilor şi practicilor

din statistică cu cele din ingineria şi managementul proiectelor.

Prin natura sa produsul software nu este vizibil în sensul obişnuit al cuvântului (nu poate fi perceput

vizual, auditiv, kinestetic, olfactiv, gustativ, etc), de aceea există un mare număr de instrumente proiectate

pentru a face software-ul vizibil. Aceste instrumente şi proceduri sunt utilizate pentru a face vizibile:

logica software - listinguri ale codului sursă, scheme logice şi o mare varietate de diagrame;

calitatea software - se reprezintă sau se calculează valorile unor metrici ce exprimă nivele ale unor

caracteristici de calitate, sau ale calităţii globale (de exemplu graficul erorilor pe module, complexitatea

ciclomatică a modulelor, etc);

utilizarea unor modalităţi de facilitare a comunicaţiei -reprezentarea informaţiilor despre logica

software sau calitatea software se face în mod particular pentru fiecare tip de actor participant la realizarea

produsului. Astfel, informaţiile despre software vor fi mai bine înţelese de programatori dacă se vor

exprima sub forma schemelor logice, iar aceleaşi informaţii vor fi mai bine asimilate de manageri dacă vor

fi prezentate sub formă de diagrame;

controlul distorsiunilor şi redundanţei.

În ingineria software, indicatori statistici precum numărul mediu de erori per modul reprezintă numai

primul pas al procesului de eliminare a cauzelor disfuncţiilor. în acest caz, managerii nu pot înţelege exact

semnificaţia indicatorilor statistici fără consultarea personalului care cunoaşte structura codului programelor,

aşa cum simpli programatori, care lucrează la anumite părţi ale produsului, nu pot percepe în totalitate

implicaţia erorilor din cod, fără informaţii despre consecinţele acestor erori asupra întregului produs

software. De exemplu, alte reprezentări (mai apropiate de viziunea managerială) ale graficului numărului

mediu de erori per modul, pot fi: costul remedierii erorilor per modul sau timpul consumat pentru remedierea

erorilor per modul. Deci, managementul calităţii nu poate fi eficient decât dacă informaţiile despre software

sunt comunicate şi urmărite atât în dinamica lor cât şi sub diferitele aspecte (caracteristici) sub care se

abordează calitatea software. Aşa cum la construcţia unei case sunt necesare mai multe planuri - planul de

structură, planul instalaţiei electrice, planul instalaţiei de apă şi canalizare, planul de încadrare în zonă, etc. -

la construirea produsului software, şi, în mod particular a calităţii acestuia, sunt necesare informaţii despre

fiecare element implicat: logica programelor, schema fluxului de date, schema bazei de date, rezultatele

testării, etc. nu atât la un moment dat, ci aşa cum au evoluat ele, în dinamica procesului de dezvoltare. Orice

element care duce la distorsionarea, indisponibilitatea, neconsemnarea sau la nereprezentarea adecvată a

acestor informaţii împiedică organizaţia producătoare de software să atingă un nivel superior de maturitate şi,

implicit, un nivel superior de productivitate şi calitate a produselor sale. E. Deming observă că oamenii care

nu-şi pot reprezenta şi vizualiza produsul, proiectul sau activitatea la care lucrează, nu pot avea contribuţii

reale la îmbunătăţirea calităţii.

17

8. Abordarea managerială orientată pe proces. Ciclu de viaţă - modele şi

structuri După cum s-a prezentat şi în capitolul anterior, la Software Engineering Institute - S.U.A., a fost

dezvoltat un model ce descrie tipuri esenţiale de procese de dezvoltare software, clasificând organizaţiile

producătoare în funcţie de caracteristicile particulare ale procesului lor de producţie/dezvoltare. In [WEI2],

G. Weinberg arată că, pentru industria de software, nivelele de maturitate prezentate în modelul CMM/SEI,

reprezintă modele socio-culturale ale acestei ramuri de activitate.

G. Weinberg adaugă la modelele cuprinse în CMM/SEI şi nivelul, sau modelul, "0". Acest model nu

este un model profesional (industrial). Este caracterizat în [WEI2] prin lipsa separaţiei dintre producătorul şi

utilizatorul de software ("economia naturală"). Nu există client, manager sau procese specificate, iar cei ce

dezvoltă software în acest model nu sunt conştienţi că execută şi participă la un proces. Motivaţia lor este

aceea că nimeni nu poate să le ofere ceea ce doresc sau să le înţeleagă cerinţele. Actorii acestui model'sunt

programatorii aflaţi în postura magică a unui creator divin, omniscient şi omnipotent. Cu toate că acest model

are meritul de a garanta satisfacţia utilizatorului (deoarece este identic cu producătorul), nu poate fi luat în

considerare, deoarece nu înseamnă "industrie" software.

Industria de software înseamnă proiectarea unor aplicaţii de complexitate şi dimensiuni mari,

dezvoltate în cadrul unor echipe şi, de cele mai multe ori, în organizaţii specializate, urmând etape bine

stabilite [SPI1]. Conform [SPI1], aceste etape se referă la specificarea cerinţelor utilizatorului, analizarea

acestora, proiectarea de detaliu, implementarea, testarea şi întreţinerea/îmbunătăţirea produsului creat, până

la scoaterea sa din utilizare (figura 3.1)- Această succesiune de procese defineşte ciclul de viaţă al software şi

constituie obiectul ingineriei programării" [SPI1].

Software se crează ca răspuns dat unui set de nevoi la un moment dat, şi odată cu evoluţia acestui set

de nevoi şi produsul software se maturizează, atât în perioada de dezvoltare cât şi în perioadele de

operare/mentenanţă [BRY1]. Figura 3.2. ilustrează un alt model al ciclului de viaţă al software, propus în

[BRY1].

În stadiul de concept, viitorul produs software poate fi vag perceput. După realizarea proiectului

preliminar produsul începe să capete contur, iar după realizarea proiectului de detaliu produsul software este

complet conturat. În etapele următoare produsul software există sub formă de cod şi sub formă de

documentaţie. În aceste ultime stadii produsul este în formă executabilă trebuind să îndeplinească funcţiile

specificate în cerinţe.

Specificare

cerinţe

Analiză

cerinţe

Implementare

Testare

Instalarea

Întreţinerea

Figura 3.1. Ciclul de viaţă al software (modelul 1)

18

Ciclul de viaţă al software

Analiză

cerinţe

ConceptProiectare

Preliminară

de detaliuImplementare

Testare

Instalare

Întreţinere

Specificare

cerinţe

În stadiul de concept, viitorul produs software poate fi vag perceput. După realizarea

proiectului preliminar produsul începe să capete contur, iar după realizarea proiectului

de detaliu produsul software este complet conturat. În etapele următoare produsul

software există sub formă de cod şi sub formă de documentaţie.

Software se crează ca răspuns

dat unui set de nevoi la un

moment dat, şi odată cu evoluţia

acestui set de nevoi şi produsul

software se maturizează, atât în

perioada de dezvoltare cât şi în

perioadele de operare/

mentenanţă

Figura 3.2. Etapele ciclului de viaţă al software

CERINŢE

PENTRU

SOFTWARE

CONCEPT

PROIECTARE

PRELIMINARĂ

PROIECTARE

DETALIATĂ

PROTOTIP

(PRIMA

FORMĂ)

PRODUS

SOFTWARE

OPERAŢIONAL

Figura 3.3. Ciclul de viaţă (modelul 2)

Desigur; modelele prezentate sunt modele ideale. În realitate, produsul software nu trece fără opriri şi

revizuiri de la o etapă la alta (datorită unor evenimente de natură variată - modificarea cerinţelor,

descoperirea unor erori de proiectare, etc.). Ca urmare, activitatea de mentenanţă se aplică în toate stadiile

modelului.

Problema cea mai importantă de rezolvat în aceste situaţii o reprezintă controlabilitatea proceselor

implicate de ciclul de viaţă, având în vedere restricţiile impuse acestuia (timp, resurse). Chiar şi în cazul celor

mai clare modele ce posedă un înalt nivel de acurateţe, controlarea proceselor nu poate fi făcută cu succes,

datorită perturbaţiilor aleatoare produse de intrările proiectului (resurse, date, situaţii, poziţii ale actorilor

implicaţi şi chiar stări de spirit, etc.). În plus, faţă de modelul de dezvoltare, controlabilitatea proceselor

presupune existenţa unor modele predictive asupra modului în care diferitele intervenţii manageriale pot

afecta sistemul sub control. După părerea lui G.Weinberg [WEI2], cel mai mare câştig adus în industria de

software de modelul 2 (nivelul de maturitate caracterizat în CMM/SEI prin "repetabilitate, rutină") sunt

planurile de dezvoltare a produsului software ale organizaţiilor producătoare. Aceste organizaţii au făcut

eforturi majore pentru a-şi construi standarde interne, a prescrie şi documenta secvenţe de

Acţiuni menite să controleze dezvoltarea de software. Metodele tipice prescriu o serie de paşi ideali de

urmat, începând, de obicei, cu un studiu de fezabilitate, specificarea cerinţelor şi proiectarea de nivel înalt,

urmate apoi de proiectarea de detaliu, codificare, testarea pe unităţi, testarea întregului sistem, testarea "beta"

şi versiunea finală ("product release"). În Figura 3.4. se redă modelul de procese în cascadă din [WEI2], din

19

clasa cărora fac parte şi modelele prezentate mai sus. Modelul original se traduce printr-un plan strict

secvenţial, având reprezentate săgeţi unidirecţionale între noduri.

Cerinţe

de sistem

Specificaţii

cerinţe

Analiză

Proiectarea

programelor

Codificare

Testare

Operaţionalizare

Figura 3.4. Modelul de procese în cascadă

În spiritul acestui tip de modele, s-au elaborat metodologii, cum este cea dezvoltată în ţara noastră, la

I.C.I. Bucureşti, în 1982, şi preluată în [D0D1]. Etapele acestei metodologii sunt prezentate, pe scurt, în

Anexa 4.

În scurt timp, au început să apară modificări ale modelului proceselor în cascadă, constând în bucle de

feedback, modificări ce reprezintă recunoaşterea faptului că un model pur liniar este o descriere inadecvată a

ceea ce se întâmplă în realitate în dezvoltarea de software. Modificările iniţiale apărute sunt prezentate în

Figura 3.5.

Specificaţii

cerinţe

Analiză

Proiectarea

programelor

Codificare

Testare

Operaţionalizare

Cerinţe

de sistem

Modelul proceselor în cascadă, constâ în bucle

de feedback, modificări ce reprezintă

recunoaşterea faptului că un model pur liniar

este o descriere inadecvată a ceea ce se

întâmplă în realitate.

Bucle de feedback în două zone: de la

proiectarea programelor la specificarea

cerinţelor şi de la testare la proiectarea

programelor.

Figura 3.5. Bucle de feedback în modelul proceselor în cascadă.

Asumpţiile implicite sau explicite luate în calcul la realizarea metodologiilor liniare sunt:

− nu vor fi făcute greşeli;

− dacă se vor face greşeli, acestea nu vor fi de amploare;

− părţile responsabile vor şti, cu certitudine, cum să corecteze micile greşeli.

Pe această bază, în [WEI2], metodologiile secvenţiale se definesc ca modelând procese lineare,

suplimentate prin feedback-uri implicite. Odată cu creşterea dimensiunii şi complexităţii proiectelor

efectuarea micilor corecţii instinctive nu mai poate fi suficientă.

Modificările modelului, surprinse în Figura 3.5, vizează introducerea unor bucle de feedback în două

zone: de la proiectarea programelor la specificarea cerinţelor şi de la testare la proiectarea programelor. Dar

reexaminarea, modificarea sau chiar refacerea specificaţiilor sau a proiectelor programelor, pe lângă faptul că

este costisitoare, presupune perturbarea şi mai puternică a întregului eşafodaj al realităţii proceselor de

20

producţie, ceea ce face ca şi acest model să fie inaplicabil. în plus, metodologia nu prevede în nici un sens ce

informaţii vor trebui să circule pe buclele de feedback de la o etapă la alta. în esenţă, din modelul modificat

reiese concluzia: "Fie faci totul bine de prima dată, fie refaci totul de Ia început".

Pornind de la ideea că, dând atenţia cuvenită micilor deviaţii care apar în procesul de dezvoltare, de la

o etapă la alta, se acţionează mai devreme şi deci mai puţin, Humphrey Watts introduce ideea celulelor

unitare de bază (basic unit cells) din care se compune un proces mai mare. Fiecare din aceste celule este

prevăzut cu buclă de flux de feedback ce provine de la celulele ulterioare şi merge la celulele anterioare.

Minimizând aceste celule, nonlinearitatea este ideal minimizată (Figura 3.6).

Input Entry

N

Task Exit

Output

Out

In

Figura 3.6. Celulele unitare de bază în procesul de dezvoltare

În conjuncţie cu celulele de bază ale lui W. Humphrey, se utilizează "Ciclul evolutiv de livrare" al lui

Gilb. Conform acestui model, munca se desfăşoară în micro-proiecte, buclele de feedback neputând creşte

prea mult. Maximul admis al buclei este de la un micro-proiect la altul (Figura 3.7)

Feedback

Feedback

Micro-proiect

Figura 3.7. Maximul admis al buclei de feedback

Atât celulele de bază cât şi micro-proiectele, încearcă să rezolve problema legăturilor inverse, dar se

focalizează numai asupra produsului care este în curs de dezvoltare. Pe legătura inversă circulă numai

informaţii despre produs (rezultate ale unor metrici, ale inspecţiilor asupra produsului sau ale auditurilor pe

produs), şi nici un fel de informaţii despre proces, în general. Pentru o conducere efectivă şi eficientă, un

manager trebuie să aibă mult mai multe informaţii şi mult mai devreme în timp, informaţii pe care, singur

produsul, nu le poate furniza. O viziune mai completă asupra îmbunătăţirii calităţii software şi a

productivităţii, o oferă abordarea procesuală (Deming). Un program de îmbunătăţire ideal combină orientarea

bazată pe proces cu ideea îmbunătăţirilor mici dar continue, pentru a produce cu succes modificări,

menţinând instabilitatea la un nivel minim.

În vederea eliminării bulversărilor ciclului de dezvoltare, generate îndeosebi de modificări, clarificări

sau revizuiri ale cerinţelor beneficiarilor de software, s-a dezvoltat un nou model al proceselor, bazat pe

proprietăţile noilor instrumente şi platforme de dezvoltare, care permit dezvoltarea relativ rapidă a "faţadei"

Evaluarea rezultatelor

Livrarea către un utilizator real

Construirea etapei planificate

Ingineria etapei curente

(atribute, soluţii, sub-etape)

Schiţă de plan de evoluţie

Arhitectura globală deschisă

Stabilirea obiectivelor de perspectivă

21

unei aplicaţii incomplete (interfaţa), asupra căreia beneficiarul proiectului este chemat să-şi exprime punctele

de vedere. Prototipizarea, bazată pe un schelet de aplicaţie (prototip), deşi este eficientă pentru aplicaţii de

gestiune de date (sisteme de gestiune de baze de date, subsisteme "front office" pentru culegere de date, etc),

poate fi mai puţin eficientă în cazul aplicaţiilor de dimensiuni şi complexitate mare. Aceasta fie datorită

costurilor considerabile ale dezvoltării unor asemenea prototipuri, care vor influenţa costurile totale ale

proiectului, fie datorită complexităţii construirii şi testării prototipului însuşi. Prototipizarea rămâne totuşi o

metodă eficientă de aplicat în cazul etapelor procesului de dezvoltare. Astfel, pentru fiecare produs software

rezultat în urma fiecărei etape din cadrul procesului de dezvoltare (specificaţii, documentaţii, cod), în funcţie

de instrumentele automate de care se dispune şi de eficienţa economică, se poate elabora mai întâi o variantă

prototip, urmând ca, în cadrul etapei, aceasta să fie rafinată şi completată iterativ.

Atât timp cât aceste modele ale ciclului de viaţă sunt aproximări, nici unul nu poate fi perfect, dar

trebuie să aibe cel puţin calitatea de a fi credibile. Aşa cum se arată şi în [WEI2], problema principală a

modelelor, ciclului de viaţă rămâne neliniaritatea, şi, uneori, chiar iterativitatea (conexiunile inverse, repetate

sau nu). O altă soluţie oferită acestei probleme este aceea de a corecta şi completa modelul ciclului de viaţă

cu un alt tip de modele - modelele intervenţiilor. Aceste modele pot ajuta atât la înţelegerea a ceea ce nu se

poate controla, cât şi la formarea unei imagini corecte asupra efectelor unor intervenţii efective în fluxul

proceselor. De fapt, procedeul constă în a "altera" modelul ciclului de viaţă (indiferent ce formă ar avea

acesta) cu diagrame de tip cauză-efect.

Exemplul simplu prin care în [WEI2] se ilustrează această tehnică de lucru este edificator. Astfel, dacă

luăm în considerare modelul ciclului de viaţă tip cascadă (Figura 3.1.3), se poate face următoarea afirmaţie:

Dacă s-a terminat etapa proiectării programelor, şi am executat etapa de codificare, următoarea

etapă va fi testarea, etapă ce va duce produsul software mai aproape de stadiul operaţional.

Având în vedere modelul (concretizat într-o metodologie internă de lucru), se poate spune că, dacă

"apar probleme" în etapa de codificare, produsul software ar putea fi mai departe de stadiul operaţional, şi

anume:

1. fie să fie trimis în stadiul "Verificare cerinţe" (de fapt reverificare cerinţe), aşa cum sugerează

modelul (şi, probabil, metodologia de lucru);

2. fie să fie într-un stadiu nemenţionat în model (şi în nici o metodologie), într-un stadiu mai

mult sau mai puţin formal, în care:

a) numărul şi complexitatea dificultăţilor apărute în etapa de codificare este foarte mare (de

nedepăşit);

b) participanţii la proiect manifestă o încredere nejustificată în capacitatea echipelor lor de

dezvoltare de a soluţiona problemele apărute;

c) conducerea organizaţiei crede, în mod eronat, că proiectul este foarte aproape de

terminare;

d) unul sau mai mulţi programatori de bază sunt epuizaţi din cauza muncii suplimentare,

sau pur şi simplu au părăsit organizaţia, sau manifestă un puternic sentiment de frustrare,

din cauze diferite (familie, nemulţumiri de ordin profesional, salariale, eţc), fapt ce ce

afectează serios munca;

e) un programator şi un şef au devenit inamici de neîmpăcat.

În general, personalul implicat în dezvoltarea de software, (oameni cu pregătire de tip exact), şi în

special conducerea, sunt poate prea obişnuiţi cu metodologiile, nefiind capabili să prezică, să înţeleagă şi să

depăşească cu succes, pentru toţi actorii participanţi, efecte negative care nu sunt bazate în mod direct pe

metodologiile elaborate de ei.

Continuând exemplul de mai sus, erorile incluse în program în etapa de codificare vor fi descoperite în

etapa de testare. Cauzele efectului erori grave în etapa de testare pot sau (de cele mai multe ori), nu pot fi

asociate cu etape din cadrul modelului/metodologiei. în [WEI2] se prezintă un model de diagramă cauză-

efect în cazul în care cauza erorilor apărute poate fi intensitatea frustrărilor (Figura 3.8).

Figura 3.8. Model de diagramă “cauză-efect”

Specificaţii

cerinţe

Analiză

Proiectarea

programelor

Codificare

Testare

Operaţionalizare

Cerinţe

de sistem

Erori în cod

Intensitatea

frustrărilor

Erori în etapa

de testare

Erorile incluse în program în etapa de codificare vor

fi descoperite în etapa de testare. Cauzele efectului

erori grave în etapa de testare pot sau nu pot fi

asociate cu etape din cadrul modelului/metodologiei.

În schemă un model de diagramă cauză-efect în

cazul în care cauza erorilor apărute poate fi

intensitatea frustrărilor

22

Efecte precum erori în cod pot avea originea în oricare din etapele modelului/metodologiei, precum şi

alte cauze nemenţionate (un programator care lucrează la alt proiect corupe, din greşeală, codul sursă). De

asemenea, variabile precum intensitatea frustrărilor pot fi influenţate de nenumăraţi factori şi, cu toate că

acest tip de variabile nu apar în metodologii, acestea afectează procesele de dezvoltare de software. Cu alte

cuvinte, variabilele ce trebuie să fie utilizate de controlorii/managerii procesului de dezvoltare pot fi direct

derivate din produs, din proces, sau pot face parte din categoria "produselor secundare" rezultate în urma

procesului (de exemplu primele acordate programatorilor pentru încadrarea în timp sau pentru calitatea

muncii, experienţa căpătată de membrii echipei de dezvoltare, relaţiile umane şi profesionale dintre membri

echipei, precum şi cele dintre acestea şi conducătorii proiectului, experienţa personală căpătată de fiecare şi

de echipă în ansamblu, încrederea în manageri, etc). Cele mai multe metodologii sunt focalizate asupra

produsului, astfel încât nu menţionează nici un alt produs al procesului care nu este direct legat de calitatea

produsului software final rezultat, de costul sau programul proiectului.

9. Gestiunea construirii calităţii software

Pentru gestiunea construirii calităţii software, sunt utilizate ca instrumente de lucru diagramele de

proiect, diagrame ce punctează fiecare proces parcurs, în curs, în întârziere, în impas, furnizând imagini de

stadiu sau de ansamblu pertinente asupra sistemului de dezvoltare de software. Aceste diagrame se realizează

cu ajutorul schemelor PERT, Gantt sau PPPP (Public Project Progress Poster). în [WEI1], G.Weinberg

punctează dezavantajele primelor două metode (PERT şi Gantt) când sunt aplicate în gestiunea proiectelor de

dezvoltare de software. Astfel, aceste tipuri de diagrame arată numai procesele, omiţând două lucruri:

1. condiţiile esenţiale care trebuie să fie îndeplinite pentru ca un proces să fie parcurs cu succes, cum ar

fi:

cerinţele documentate, care reprezintă un standard de măsurare pentru revizii şi inspecţii;

resursele umane implicate în proces, pregătirea şi experienţa lor;

activităţile obligatorii care trebuie îndeplinite în procesele anterioare, fără de care procesul

prezent nu poate fi dus la îndeplinire;

resursele software şi hardware de care depinde procesul;

adecvarea spaţiului de lucru;

fondurile prevăzute în buget pentru procesul prezent.

2. reviziile şi inspecţiile, care servesc la măsurarea calităţii produsului software rezultat în

urma procesului.

În diagramele PPPP, fiecare proces este reprezentat printr-un dreptunghi împărţit în trei părţi: condiţiile

necesare, procesul în sine şi revizia (Figura 3.1) în rubricile din cadrul dreptungiului poate fi cuprinsă

descrierea succintă sau amănunţită a fiecăreia.

Condiţii necesare

procesului N Procesul N

Revizia (inspecţia)

procesului N

Figura 3.11. Diagramele PPPP (Public Project Progress Poster)

Fără reprezentarea reviziilor şi inspecţiilor aferente procesului, actorii implicaţi uită adesea că produsul

software (intermediar sau final) rezultat în urma procesului nu este de fapt un produs, ci un produs candidat,

care devine produs doar după completarea reviziei prin care măsurătorile făcute sunt comparate favorabil cu

cerinţele documentate, parte a condiţiilor necesare desfăşurării procesului. Acest mod de reprezentare

determină simplificarea diagramei, prin faptul că nu mai este necesar să fie reprezentate absolut toate

legăturile inverse (legăturile inverse dintre proces şi revizia sau inspectarea sa fiind implicite). Dacă produsul

software rezultat în urma procesului a trecut cu succes de revizie, rubrica reviziei este colorată cu verde

(Figura 3.12.a), dacă în urma reviziei sunt de efectuat modificări minore, rubrica reviziei este colorată cu

galben şi se adaugă o nouă rubrică pentru proiect (Figura 3.12,b). în situaţia în care se constată, în urma

reviziei, că produsului trebuie să-i fie făcute modificări majore, rubrica reviziei se colorează în roşu şi se

adaugă o nouă rubrică pentru produs şi pentru revizie (Figura 3.12,c). Dacă, în urma reviziei se constată că

produsul trebuie refăcut în întregime, rubrica reviziei se colorează în negru, iar dreptunghiul se completează

cu o rubrică pentru condiţiile necesare, una pentru proces şi una pentru revizie (Figura 3.12, d)

23

Diagrama PPPP va fi actualizată cel puţin săptămânal. Fiecare dreptunghi corespunzător unui proces va

fi aranjat pe o scală a timpului, corespunzător programului proiectului, pentru a se putea urmări şi încadrarea

în timpul programat. În figura 3.13 se prezintă un exemplu pentru două procese: elaborarea planurilor de

testare şi elaborarea testelor pentru un produs software.

Pe scala timpului sunt reprezentate datele limită de terminare a proceselor respective. După cum se

poate observa

din exemplul

de mai sus,

procesul de

elaborare a

planurilor de

testare s-a

realizat la

timp, pe când

procesul de

elaborare a

testelor este în

întârziere.

Procesele care nu au început să fie executate la data stabilită în grafic sunt reprezentate în diagrama

PPPP lăsând o urmă neagră în urmă ("dâră"), în figura 3.14. se prezintă un exemplu, conform căruia scrierea

codului programelor pentru modului 21 nu a început la data fixată, anterioară datei de 19.01, datorită unor

revizii majore pe care au trebuit să le suporte proiectele modulului. Punerea în operă a diagramelor PPPP

(sau P4), produce modificări însemnate în organizaţia producătoare de software, din mai multe motive. în

primul rând, prin crearea şi actualizarea unei asemenea diagrame, nici o neregulă în sistemul de dezvoltare al

produsului software nu mai poate fi ascunsă. Uşurinţa cu care poate fi interpretată o diagramă PPPP face

vizibilă evoluţia procesului, astfel încât pot fi identificate repede procesele ce cauzează întârzierea. De

asemenea, seriozitatea cu care managementul de proiect urmăreşte realizarea şi actualizarea diagramei PPPP

transmite un mesaj clar echipei asupra seriozităţii şi rigurozităţii conducerii.

Procesul NCondiţii necesare

procesului NProcesul N

Revizia (inspecţia)

procesului N

Procesul

N

Condiţii necesare

procesului N

Procesul

N

Revizia 1

proces N

Revizia 2

proces N

Proces

N

Condiţii

necesare

proces N

Proces

NRevizia 1

proces N

Revizia 2

proces N

Condiţii

necesare

proces N

Procesul NCondiţii necesare

procesului NRevizia (inspecţia)

procesului NProcesul

N+1Condiţiile

procesului N+1

Revizia

procesului

N+1

Figura 3.12,a. Diagrama, când produsul software a trecut cu succes de revizie

Figura 3.12,b. Diagrama, când în urma reviziei sunt de efectuat modificări minore

Figura 3.12.c. Diagrama, când în urma reviziei sunt de efectuat modificări majore

Figura 3.12.d. Diagrama, când În urma reviziei este necesară refacerea produsului

Elaborare

planuri de

testare

Planuri de

testare

complete

Elaborare

teste

Cerinţe

Documentate,

Proiecte,

Standarde

de testare

Teste complete

Figura 3.13. Elaborarea planurilor de testare şi elaborarea testelor pentru un produs

software.

Scriere programe

Modul 21

Proiectarea

Modulului 21

Proiectarea

Modulului 21

19.0119.01

CerinCerinţţee

documentatedocumentateDocumentele

Proiectului

Modulului 21

Figura 3.14. Diagrame ce indică incadrarea în timpul programat

24

În unele variante ale diagramelor PPPP, dreptunghiurile aferente proceselor mai includ o rubrică,

actualizată, de asemenea, săptămânal, şi anume cât s-a cheltuit din bugetul alocat procesului respectiv.

Managementul calităţii software se realizează şi în mod asistat, cu ajutorul unor sisteme automate. în

[WAL1] se prezintă arhitectura unui asemenea sistem, dezvoltat în cadrul programului universitar ESPRIT

REQUEST, în Marea Britanie, la Centrul pentru fiabilitate software din cadrul City University - Londra.

Scopul acestui sistem automat este de a asista un manager de proiect de-a lungul ciclului de viaţă al unui

produs software, printr-o interfaţă, ce însumează informaţii din subsisteme ca: iniţierea proiectului,

monitorizarea proiectului sau evaluarea proiectului. Acest produs software reprezintă o variantă constructivă

a modelului COQUAMO (Constructive QUAlity MOdelling System) dezvoltat tot în cadrul programului

ESPRIT. Conform acestui model, activităţile privind calitatea software se cuprind în trei grupe, şi anume:

asigurarea calităţii (QA) - activităţile planificate sau sistematice necesare pentru ca un

produs/serviciu să satisfacă nevoile date;

controlul calităţii (QC) - prevede modalităţile concrete prin care este construită calitatea

produsului;

managementul calităţii (QM) - ansamblu de activităţi în cadrul funcţiilor generale ale

managementului, prin care se determină şi implementează calitatea produsului.

Instrumentele automate pentru susţinerea acestor activităţi trebuie să asigure şi pregătirea personalului

în utilizarea standardelor, precum şi modalităţi de susţinere a activităţilor de auditare a conformanţei cu

standardele. Sistemul automat de management al calităţii prezentat în [WAL1] are la bază trei standarde

NATO şi un standard britanic: AQAP-1-"NATO requirements for an industrial quality control system",

AQAP-13-"NATO software quality control system requirements", AQAP-14-"Guide for the evaluation of a

contractor's software quality control system for compliance with AQAP-13" şi BS5750 - "British Standard

on Quality

Systems". Structura sistemului cuprinde trei instrumente software, care acoperă activităţile mai multor

subsisteme- tabelul 3.2.

Aşa cum se arată în [WAL1], în timpul testării întregului produs software şi al primei perioade de

utilizare efectivă a acestuia, comportamentul produsului poate fi observat direct. Atunci este posibilă

verificarea exactă a conformanţei calităţii operaţionale cu calitatea ce reiese din specificaţiile pe baza cărora

a fost construit produsul. Pentru această perioadă, s-a construit un instrument separat de evaluare a

produsului software, deoarece metricile şi modelele pe baza cărora se efectuează verificarea nivelelor finale

ale caracteristicilor de calitate software sunt de obicei diferite de cele utilizate în timpul monitorizării

proiectului.

Printre avantajele pe care autorii sistemului - denumit în final IPSE (Integrated Project Support

Environments) - le evidenţiază, sunt: asigurarea conformanţei cu standardele prin înglobarea standardelor

direct în produsul CASE IPSE, (într-un instrument care asistă producerea documentaţiilor) şi simplificarea

auditării conformanţei cu standardele, care poate fi demonstrată prin simpla verificare a utilizării

instrumentelor CASE conformante cu standardele. în acest mod se reunesc constructiv activităţile de învăţare

a standardelor, de învăţare a producerii unui produs software şi de învăţare a executării unei activităţi în

conformitate cu un standard ce descrie un sistem al calităţii.

Tabelul 3.2

Structura QMS - Quality Management System Instrumente Subsisteme Activităţi software

1.

Planificarea şi

iniţierea

Asistarea

planificării

Creare planuri calitate, verificare, validare planuri, proiectului strategii

de testare, identificare metrici utilizate la monitorizarea proiectului,

Crearea

specificaţiilor

cerinţelor calităţii

Stabilire nivele măsurabile ale factorilor de calitate (subcaracteristici),

analiza viabilităţii acestor nivele şi a modalităţilor utilizate pentru

atingerea lor

Analiza

fezabilităţii şi

prognozarea

calităţii

Utilizare elemente critice pentru succesul proiectului pentru a

previziona calitatea produsului final în termenii specificaţiilor

cerinţelor calităţii.

2.

Monitorizarea

proiectului

Utilizare date metrici selecţionate pt. elaborare de rapoarte şi analize de

stadiu privind proiectul, în termenii de calitate stabiliţi.

25

3.

Evaluarea

proiectului

Utilizare date obţinute pentru realizare rapoarte privind nivelul calităţii

produsului software obţinut şi prognoze cu privire la activitatea de

mentenanţă şi suport tehnic.

10. Inspectarea calităţii software. Auditul calităţii software Metoda cea mai naturală şi cea mai ieftină de a verifica corectitudinea produselor realizate sau a

proceselor ce au avut loc, este examinarea acestora. Conform [KNI1], Babbage şi von Neumann solicitau cu

regularitate colegilor lor să-şi examineze programele. Deşi metodele de inspectare diferă prin modul de

organizare şi de acoperire a codului, structura, componenţa şi dimensiunile echipei de revizie, în esenţă

acestea realizează în fapt acelaşi lucru: inspectarea produsului software şi organizarea unor discuţii avizate şi

constructive în legătură cu acesta.

În timp, odată cu creşterea dimensiunii şi complexităţii proiectelor, a exigenţelor beneficiarilor,

industria de software a dezvoltat multe metode de testare a produselor software, unele dintre acestea fiind

automatizate cu ajutorul altor instrumente software. Cu toate acestea, testarea este un proces scump, mare

consumator de resurse, neoferind, în acelaşi timp şi garanţia suficienţei. Deci, alături de testare, inspecţia şi

examinarea codului, indiferent de metoda utilizată, rămâne un proces şi o metodă viabilă atât din punct de

vedere al rezultatelor cât şi din punct de vedere al costurilor. Studii empirice, bazate pe rezultate practice

obţinute de mai mulţi manageri de proiecte software (D.P. Freedman, G.M. Weiberg, M.E. Fagan, G.W.

Russel), referite în [KNI1], arată că reviziile şi inspecţiile pot reduce numărul de erori conţinute în

programele ajunse în faza de testare cu aproximativ 10%, ceea ce determină reducerea costurilor de testare cu

50% până la 80%.

Din rezultatele sistematizate de Russell (IEEE Software, Vol.8 No.l, Jan 1991, p.25-31) şi interpretate

de Fagan şi Knight (Achieving Ouality Software - Proceedings of a National Debate, Society for Software

Quality, San Diego, California, Jan. 1991), rezultă că 65% până la 85% din defectele operaţionale sunt

detectate prin inspecţii, la un cost cu 1/4 până la 2/3 mai redus faţă de testare, şi sunt remediate cu un cost ce

ajunge la 1/7 până la 1/2 faţă de costul remedierii lor în faza de testare. Defectele operaţionale sunt definite în

acest context ca mici greşeli de logică, utilizări incorecte ale unor operatori, utilizarea unor construcţii de o

ineficientă inacceptabilă şi alte defecte ce determină programele să nu execute sau să execute incorect

anumite operaţiuni, având uneori, prin propagare, efecte dezastruoase asupra funcţionării de ansamblu a

produsului.

În [TEO5] se prezintă câteva tipuri de metode de revizie şi inspecţie a codului, aşa cum sunt ele

enumerate în literatura de specialitate [KNI1], [WEI1]. Aceste metode s-au sistematizat în funcţie de scopul

urmărit, astfel:

inspecţii şi revizii care urmăresc depistarea erorilor sau obiective limitate:

− revizia formală - autorul produsului, sau unul din revizorii familiarizaţi cu munca la produs

prezintă produsul celorlalţi revizori. Fluxul inspecţiei este condus de prezentarea făcută şi de

problemele ridicate pe parcurs de revizori;

− revizia activă a proiectării (sau metoda Parnas şi Weiss) - constă în efectuarea unor scurte

revizii, fiecare fiind focalizată pe o anumită parte a produsului (de obicei segmente ale

documentaţiei de proiectare). Participanţii la aceste revizii sunt ghidaţi de întrebările puse de

autorii proiectării, asftel încât să încurajeze o examinare cât mai amănunţită;

− metoda camerei curate - este mai mult decât o simplă metodă, deşi revizuirea produsului de

către producător este .componenta sa majoră. Această metodă cere autorilor să execute variate

revizii asupra produsului şi nu le permite acestora ca o anumită parte a produsului (un modul

sau o parte din documentaţie) să fie executat, pus în aplicare sau examinat de cel care 1-a scris.

în unele cazuri, nici compilarea modulelor nu este făcută de autorii lor. Acesta metodă vizează

încurajarea executării unor verificării riguroase din partea factorului uman, dar şi structurarea

produselor software astfel încât acestea să se preteze testării pe unităţi sau module.

inspecţii şi revizii care urmăresc testarea conformanţei:

− parcurgeri ale codului (walkthroughs) - sunt utilizate pentru examinarea codului sursă în

relaţie cu documentele de proiectare şi cu specificaţiile. Participanţii execută o simulare pas cu

pas, linie cu linie a codului şi a documentaţiei. Autorii programelor sunt prezenţi pentru a

răspunde eventualelor întrebări ale participanţilor;

- inspecţii - într-o inspecţie, se stabileşte o listă de criterii cu care produsul trebuie să fie conformant,

iar această listă determină fluxul reviziei. Inspecţiile sunt utilizate şi pentru evaluarea unor caracteristici de

26

calitate, cum ar fi portabilitatea sau conformanţa cu standardele. Inspectorul trebuie să stăpânească bine lista

de criterii, sau să fie bine informat asupra nivelului dorit al caracteristicilor de calitate ce urmează a fi

inspectate;

- metoda celor N inspecţii - este o tehnică adaptată analizei conformanţei cu cerinţele şi specificaţiile

utilizatorului, materializate în documentaţii. în cadrul acestei metode sunt efectuate câteva inspecţii, în

paralel, conduse de un singur moderator. Aceasta deoarece s-a constatat că rezultatele inspecţiilor paralele nu

sunt, de obicei, convergente.

inspecţii şi revizii etapizate, care urmăresc scopuri complexe:

- inspecţiile Fagan - sunt o combinaţie între reviziile formale, parcurgerile de cod şi inspecţii. Aceste

inspecţii presupun parcurgerea a cinci paşi: (1) evaluarea generală, în care autorii explică conţinutul

programelor inspectorilor. De exemplu, pentru o inspecţie pe codul sursă, în această etapă se vor examina şi

explica documentaţia de proiectare a programelor, precum şi logica generală a acestora; (2) pregătirea, în

timpul căreia inspectorii studiază produsul şi documentaţia asociată; (3) inspecţia -întâlnire controlată de un

moderator care, la rândul său, desemnează o persoană ce va ghida inspectorii într-o examinare detaliată, linie

cu linie a produsului, pentru căutarea erorilor; (4) corectarea erorilor sesizate la inspecţie. în urma parcurgerii

pasului anterior inspectorii vor elabora un raport cu erorile depistate, ce va fi înmânat autorului în vederea

efectuării corecţiilor; (5) revizia finală, în care se verifică modul de corectare a erorilor semnalate în raport.

- inspecţia fazată, sau pe faze - este proiectată astfel încât să asigure rigurozitatea, elasticitatea şi

eficienţa metodei în utilizarea resurselor precum şi posibilitatea de a fi automatizată. Metoda presupune

efectuarea unei serii de inspecţii parţiale coordonate, numite faze. Fiecare fază trebuie să asigure că produsul

inspectat posedă fie o anumită caracteristică specifică sau particularizată, fie un mic set (subsistem) de

caracteristici înrudite. Caracteristicile examinate sunt ordonate astfel încât fiecare fază să poată prezuma

existenţa caracteristicilor verificate în fazele anterioare. La rândul lor fazele pot fi efectuate de un singur

inspector sau de mai mulţi inspectori. Fazele efectuate de un singur inspector reprezintă procese riguroase şi

rigide, ce constau în verificarea unor liste de cerinţe definite fără ambiguitate (check lists).

Produsul nu poate trece de această fază a inspectării până nu îndeplineşte toate cerinţele menţionate în

listele respective. în fazele care sunt efectuate de mai mulţi inspectori se inspectează şi se verifică acele

caracteristici şi proprietăţi ale unui produs software care nu pot fi surprinse de seturi de întrebări precise, cu

răspunsuri de tip da/nu, independente de aplicaţie.

Într-o astfel de situaţie inspectorii din echipă examinează produsul în mod independent, conform unor

proceduri structurate clar şi apoi are loc întâlnirea acestora, în care se compară rezultatele individuale. Acest

tip de fază este în esenţă un proces Delphi. Inspectorilor nu li se furnizează alte informaţii legate de produs şi

de realizarea acestuia, în afara celor disponibile în documentaţii.

Listele de cerinţe (check lists) utilizate pot fi specifice aplicaţiei (în cazul fazelor executate de un

inspector), specifice domeniului aplicaţiei şi liste cu cerinţe de ambele tipuri (în cazul fazelor efectuate de

mai mulţi inspectori). Listele de cerinţe specifice domeniului îndreaptă eforturile inspectorului către zonele

mai dificile ale domeniului respectiv, pe c|nd listele specifice aplicaţiei sunt proiectate să forţeze o examinare

exhaustivă a produsului de către inspector. De exemplu, într-o inspecţie a codului sursă, în lista de cerinţe se

pot genera periodic întrebări de tipul: "La ce foloseşte această instrucţiune?" sau "Pentru ce este utilizată

această structură de date?", cu o rată fixă, stabilită la mia de linii de cod sursă. Modul cum se răspunde la

aceste întrebări ne arată dacă inspectorul a verificat porţiunea de cod respectivă şi a înţeles suficient de bine

produsul. Răspunsuri incorecte repetate la aceste tipuri de întrebări pot conduce şi la concluzia că produsul

software nu este suficient de bine documentat, programele nu sunt eficient comentate sau sunt scrise neclar.

Acest tip de informaţie este esenţial pentru a asigura mentenabilitatea produsului.

Inspecţia pe faze, prezentată în [KNI1], elimină un important neajuns al celorlalte metode. Astfel, deşi

metodele de inspecţie şi revizie amintite sunt benefice în sens statistic, aplicarea nici uneia dintre acestea nu

poate evalua mulţumitor măsura sau nivelul unei caracteristici sau unui subsistem de caracteristici de calitate

ale unui produs software. Deşi managerii de proiect sunt în unanimitate de acord că aplicarea inspecţiilor şi

reviziilor îmbunătăţeşte nivelul general de calitate al produselor organizaţiilor producătoare, aceştia ar dori

ca, pe baza rezultatelor inspecţiilor, să poată fi în măsură să facă predicţii asupra nivelului de calitate al

produsului software inspectat.

Potrivit [KNI1], pentru ca o metodă de inspectare a unui produs software să aibă o productivitate mare,

este necesar ca aceasta să îndeplinească următoarele condiţii:

1. să existe garanţia că metoda de inspectare se poate aplica riguros, astfel încât rezultatele să fie

specifice fiecărui produs particular şi, în acelaşi timp, repetabile la nivelul aceluiaşi produs;

2. să fie flexibilă, să poată servi unor scopuri complexe (nu numai unei simple detectări a erorilor

înainte de faza de testare);

27

3. să fie concepută astfel încât o mare parte a muncii să poată fi făcută automat, resursele umane să fie

utilizate numai atunci când este imperios necesar;

4. să fie eficientă, astfel încât, cu un anumit volum de resurse, să se poată obţine rezultate maximale.

Cu toate acestea, oricât de fiabilă sau riguroasă ar fi inspecţia calităţii, dacă nu este eficientă din punct

de vedere al costurilor, metoda nu va fi aplicată. Aşa cum se recunoaşte în [KNI1], disponibilitatea metodei

din punctul de vedere al costurilor este imposibil de modelat analitic într-un mod convingător. Acest lucru

poate fi obţinut numai prin experimentări la scara produselor software industriale, operând în mediul

industrial, efectuând experimente multiple de aceeaşi natură, pentru a permite estimarea variaţiei statistice şi

comparaţii la scara de 1/1 cu alte medode. Aceste experimente sunt imposibile fără investirea unor resurse

substanţiale, de-a lungul mai multor ani. în acest context, este puţin probabil ca o organizaţie producătoare de

software de nivel industrial să susţină o asemenea investiţie, atât timp cât nu există suficiente dovezi că

metoda este fezabilă nu numai într-un mediu academic. Dar, deşi experimentele academice izolate nu pot

produce rezultate semnificative şi concluzive, pot oferi indicaţii empirice bune asupra utilităţii relative a

inspecţiilor calităţii.

În [WEI1] G. Weinberg dă câteva sfaturi demne de luat în seamă, pentru cei care conduc

inspecţii ale calităţii produselor software. Aceştia sunt sfătuiţi:

- să ia cele mai radicale (pesimiste) decizii - fapt care va determina managementul organizaţiei să ia în

calcul cu seriozitate argumentele pesimiste ale inspectorilor;

- să asculte cu atenţie diferenţele de opinii - dacă un singur inspector nu reuşeşte să înţeleagă în

întregime produsul, atunci trebuie reconsiderată problema dacă producătorul a creat un produs

inspectabil (vizibil, inteligibil, stabil) cu implicaţiile de rigoare asupra mentenabilităţii sale;

- să observe cu atenţie reacţia inspectorilor la semnarea listelor de control sau a celorlalte documente

ale inspecţiei - fiecare inspector poartă responsabilitatea a ceea ce a făcut, eventualele ezitări pot ridica

întrebări asupra calităţii muncii inspectorului, sau asupra rezervelor pe care acesta le poate avea faţă de

produsul inspectat;

- să remarce problemele care se redeschid mereu (subiectul discuţiilor care nu se mai termină) - dacă

inspectorii fac încercări să redeschidă discuţia asupra unor probleme clasate, sau asupra cărora s-a luat deja o

decizie, acest lucru indică faptul că există rezerve.

Deşi inspecţiile sunt metode de gestiune şi management al calităţii orientate către produs, faptul că toţi

participanţii la inspecţii îşi îmbunătăţesc, în timp, într-un mod sau altul, abilităţile personale (profesionale, de

comunicare, de conducere) efectul major al acestora se va reflecta, pe termen mai lung, asupra calităţii

proceselor.

Auditul calităţii software Cererea din ce în ce mai mare de produse software performante şi cu preţuri accesibile, a determinat ca

acest tip de industrie să înflorească nu numai în ţările dezvoltate, dar şi în ţările slab dezvoltate (India,

Pakistan, China etc). în dezvoltarea proiectelor mari se includ adesea produse preluate de la subcontractori,

sunt implicate echipe de dezvoltare aflate în locaţii geografice diferite, astfel că, în toate cazurile,

complexitatea produselor se reflectă şi în complexitatea proceselor de dezvoltare. Acest lucru a generat

nevoia ca producătorii şi beneficiarii de software să dorească o confirmare, de la o entitate independentă, că

produsul dezvoltat este congruent cu cerinţele, posedă nivelul dorit de calitate şi este improbabil să aibă un

comportament aberant. Ca urmare, s-a dezvoltat auditul calităţii, ca tehnică prin care o entitate independentă

examinează fie produsul software (auditul produsului), fie procesul generator (auditul proceselor).

Aşa cum se arată în [BRY1] auditul software are câte ceva de oferit fiecărui participant: utilizatorul

este asigurat că produsul îndeplineşte nevoile sale operaţionale şi de performanţă, cumpărătorul este asigurat

că produsul va fi livrat la timp şi în limitele bugetului alocat, iar producătorul este asigurat că produsul s-a

dezvoltat într-o manieră trasabilă, fiind deci mentenabil, şi va fi acceptat de utilizator şi cumpărător. Costul

auditului este preţul pe care utilizatorul, cumpărătorul şi producătorul trebuie să-1 plătească pentru a-şi

reduce riscurile.

Indiferent de modelul de ciclu de viaţă al procesului de dezvoltare software, la sfârşitul fiecărui proces,

stadiu sau etapă, există un interval de timp (o platformă) în care "se trage linia", procedându-se la o scurtă

evaluare de stadiu. Aceste "platforme" sunt vizate de auditul software.

În esenţă, auditul implică două procese fundamentale - verificarea şi validarea. Verificarea este

procesul ce constă în stabilirea dacă, la sfârşitul fiecărui proces, stadiu sau etapă de dezvoltare software,

obiectivele propuse la început s-au atins, şi în ce măsură. Verificările succesive desfăşurate de-a lungul

procesului de dezvoltare trasează maturizarea produsului software de la o etapă la alta. Validarea este

procesul ce constă în stabilirea dacă produsul software rezultat după un stadiu (etapă, proces) de dezvoltare

28

îndeplineşte obiectivele specificate în cerinţe. Pentru a fi efectivă şi a putea preveni disfuncţiile generate de

modificarea cerinţelor de la o etapă la alta, validarea trebuie efectuată la sfârşitul fiecărei etape. Astfel,

validările succesive trasează conformanţa între produsul software rezultat după fiecare stadiu de dezvoltare şi

elementele conţinute în cerinţe care trebuie îndeplinite în stadiile respective.

Verificarea şi validarea, combinate şi repetate, alcătuiesc modele de proceduri pentru auditarea

software. Oricare ar fi modelul de procedură adoptat, scopurile auditării sunt creşterea vizibilităţii produselor

sau proceselor software şi stabilirea trasabilităţii de-a lungul ciclului de viaţă. De asemenea, auditul face

vizibil pentru manageri, stadiul curent şi nivelul de calitate al produsului software, permiţând evaluarea

integrităţii acestuia.

Pentru ca auditul să-şi atingă scopurile (vizibilitate şi trasabilitate), este necesar ca, în fiecare stadiu al

procesului de dezvoltare, produsul software să poată fi identificat. Prin identificare, în [BRY1] se înţelege:

determinarea clară a părţilor constitutive ale produsului software;

determinarea clară a relaţiilor dintre aceste părţi;

atribuirea unei etichete sau unui nume unic şi sugestiv fiecărei părţi constitutive;

descrierea grafică sau tabelară a părţilor şi relaţiilor dintre ele.

Părţile constitutive al unui produs software, în orice stadiu de dezvoltare s-ar afla, sunt elementele de

configuraţie software.

Identificarea constituie şi o premiză importantă a comunicaţiei informaţiei privind trasabilitatea. Astfel,

ca rezultat al verificării şi validării, se poate construi un tabel sau o matrice a trasabilităţii care să indice

corespondenţa dintre un element de configuraţie dintr-un anumit stadiu şi elementele de configuraţie

corespondente din celelalte stadii de dezvoltare, sau dintre acesta şi "reflectarea" sa în specificaţii.

În tabelul 3.3 se prezintă o succesiune de paşi, constituiţi într-un model de auditare de software, într-un

anumit stadiu din ciclul de viaţă, în viziunea autorilor [BRY1 ].

Tabelul 3.3.

1. Examinarea

specificaţiilor cerinţelor

faţă de produs

Motivaţia parcurgerii acestui pas: deseori, cumpărătorul/utilizatorul nu îşi

cunoaşte decât vag nevoile vis-a-vis de un produs software şi nu este capabil,

de prima dată, să articuleze complet, necontradictoriu şi fără ambiguităţi

aceste nevoi în scris. Examinarea specificaţiilor scoate în evidenţă omisiunile

şi ambiguităţile. Chiar dacă aceste probleme nu sunt rezolvate pe loc,

examinarea preliminară face vizibile lucrurile care se pot transforma în

probleme cheie.

2. Verificarea

asigurării calităţii.

În sens restrâns, asigurarea calităţii poate fi privită ca asigurarea

conformanţei produsului, în format, conţinut şi metodologie cu standardele

prescrise. Acest pas constă în verificarea conformităţii produsului cu

standarde specificate (guvernamentale, industriale, interne, comerciale,

profesionale, etc), prescrise de managerii proiectului sau de utilizator.

3. Identificarea

produsului

Determinarea elementelor de configuraţie, a relaţiilor dintre ele, asignarea

de denumiri şi etichete elementelor de configuraţie ce constituie produsul,

descrierea sugestivă a acestora, aşa cum s-a arătat mai sus.

4. Examinarea

clarităţii,

completitudinii,

consistenţei interne si

testabilitătii.

Se execută comparând conţinutul textual şi grafic al unor secţiuni, cu

conţinutul altor secţiuni ale documentaţiei. Sunt înregistrate inconsistenţe,

ambiguităţi, omisiuni, adăugări sau modificări nepotrivite ale scopurilor sau

nivelelor de detaliere.

29

5. Produsul este

verificat prin

comparaţie cu etapa

anterioară din ciclul

său deviată.

Dacă nu există o etapă anterioară, acest pas nu este executat. Corelarea

elementelor de configuraţie identificate în stadiul prezent cu elementele din

care au evoluat. Compararea elementelor de configuraţie corelate se face în

vederea verificării dacă scopurile şi sarcinile etapei anterioare au fost atinse

în produs. Discrepanţele sunt comparate cu cele identificate în audituri

anterioare, cu alte comentarii conexe (ale utilizatorilor, cumpărătorilor sau

cu cele apărute în diferinte şedinţe de analiză ale producătorului), cu cele

reieşite din rapoartele de stadiu ale configuraţiei. Sunt identificate

discrepanţele nou apărute, faţă de cele cunoscute. Se mai examinează în acest

pas şi rezoluţiile puse pentru soluţionarea discrepanţelor identificate deja.

6. Elaborarea

rapoartelor de stadiu al

configuraţiei

Se execută când software-ul auditat este o actualizare a unui produs software

auditat anterior. Procesul constă în compararea elementelor de configuraţie

identificate în stadiul prezent cu cele identificate în acelaşi stadiu al produsului

anterior, pentru a determina ce elemente de configuraţie au fost modificate,

şterse sau adăugate. Aceste modificări, ştergeri şi adăugări sunt comparate cu

lista modificărilor aprobate în acelaşi stadiu al produsului anterior, şi

sunt înregistrate diferenţele. Alcătuirea listei modificărilor este

obligaţia managementului configuraţiei. Lista de modificări este aprobată în

procesul controlului configuraţiei.

7. Validarea

conformanţei cu

specificaţiile de cerinţe

identificate

Elementele de configuraţie ale produsului auditat sunt corelate cu elementele

de configuraţie identificate în specificaţii. Acesta este un pas din procesul de

creare a matricei trasabilităţii. Elementele de configuraţie corelate sunt

comparate pentru a verifica modul în care au fost satisfăcute cerinţele prevăzute

în specificaţii.

8. Evaluarea identificate

şi elaborarea raportului

final

Evaluarea se bazează pe cele observate şi înregistrate şi neconcordanţelor

trebuie să fie obiectivă. în baza experienţei lor, auditorii formulează concluzii

bazate pe tipul, numărul, natura şi complexitatea discrepanţelor identificate.

În Anexa 3 A se prezintă un model de structură al raportului de audit, aşa cum a fost propus în [BRY1].

Aceşti paşi sunt aplicabili în toate etapele pe care le parcurge un produs de-a lungul ciclului său de viaţă.

Auditul este executat în două situaţii: în procesul de dezvoltare care conduce la crearea unui nou produs

software, şi când produsul software este modificat. Auditarea software este parte a unui proces complex, şi

anume procesul de control al configuraţiei (al cărui model propus în [BRY1] este prezentat în Anexa 3B).

Controlul procesului este un element al managementului configuraţiei. Relaţiile dintre auditul software,

procesul de control al configuraţiei şi managementul configuraţiei, sunt cele din figura 3.15.

Auditul este o activitate profesionistă şi independentă, deci, din echipa de audit fac parte persoane cu

pregătire şi experienţă de înalt nivel, membri ai unor organizaţii independente şi profesioniste (firme de

audit, institute de cercetare, agenţii guvernamentale sau neguvernamentale specializate, etc). Echipa de

auditori, prin poziţia sa independentă, oferă o garanţie suplimentară asupra obiectivitătii auditului. Din

componenţa echipei de audit pot face parte şi manageri ai firmei, manageri ai proiectului şi persoane din

comisia de control al configuraţiei. Aceste persoane îşi pot aduce contribuţia la proces, fără a realiza

auditarea.

Figura 3.15.

Managementul configuraţiei Control configuraţie vers.

1

Audit

Control configuraţie vers.

2

Audit versiunea

Control configuraţie vers.

n

Audit versiunea

Resursele alocate auditării trebuie să fie proporţionale cu dimensiunea şi complexitatea efortului de

dezvoltare. în evaluarea complexităţii software, se au în vedere numărul de componente ce interacţionează,

complexitatea logică a acestora, numărul şi experienţa persoanelor implicate în proiectare şi dezvoltare, dar şi

30

alte elemente mai "delicate", precum numărul estimat de iteraţii la un stadiu de dezvoltare sau numărul

anticipat de modificări ale proiectelor.

12. Costul calităţii software - definire, conţinut şi propunere de clasificaţie Conform [BAR04], costul calităţii, ca parte a costului de elaborare a produsului software, reprezintă

expresia bănească a consumurilor de resurse, determinate de realizarea unui anumit nivel al caracteristicilor

de calitate, sau de îmbunătăţire a acestora.

Câteva condiţii necesare, dar nu şi suficiente, pentru a garanta atingerea unui nivel de calitate dorit

(cerut, previzionat), sunt:

- existenţa şi funcţionarea unui sistem al calităţii cu proceduri standardizate, cunoscute şi verificate în

timp;

- o cunoaştere şi evaluare realistă a cerinţelor beneficiarilor, a posibilităţilor şi resurselor

producătorului astfel încât să se proiecteze pentru produsul software un nivel de calitate care să îndeplinească

cumulativ două cerinţe: să asigure acceptarea fără rezerve a produsului de către beneficiar şi să poată fi atins

respectivul nivel de calitate, cu încadrarea în resursele planificate ale proiectului, în condiţii de eficienţă

economică şi cu posibilitatea asigurării managementului calităţii.

Prin resursele producătorului se înţelege îndeobşte:

- resursele financiare alocate, proprii sau atrase, având, o anumită calitate (de exemplu disponibilitatea

sumelor de bani, operativitatea şi siguranţa deschiderii unor acreditive, a unor linii de credit, etc);

- cantitatea, calitatea şi modul de structurare a resurselor umane (proiectanţi şi programatori cu o

anumită experienţă şi deci cu un anumit nivel de salarizare, dimensiunea echipelor de testare şi experienţa în

domeniu, calitatea şi numărul personalului echipelor de QA, modul de distribuire între procese sau produse -

module de produs, documentaţie - a personalului mai mult sau mai puţin experimentat);

- bugetul (portofoliul) de timp şi structurarea acestuia între procese şi produse (cât şi modul de alocare

a timpului pentru proiectare, codificare, inspecţii ale codului, testare).

La acest tip de resurse, care sunt caracterizate prin vizibilitate şi măsurabilitate imediată, se mai pot

adăuga şi alte categorii de resurse, care, deşi mai puţin vizibile şi măsurabile, pot afecta în aceeaşi măsură

managementul calităţii: disponibilitatea beneficiarului de a se implica în realizarea proiectului, precum şi

experienţa acestuia în utilizarea unor sisteme informatice, nivelul general al frustrărilor de diferite naturi ce

se pot manifesta la nivelul actorilor implicaţi, atitudinea managementului, poziţia activităţii de informatică în

obiectivele organizaţiei, etc.

Producătorii de software cu un anumit nivel de maturitate, care au definite procesele şi procedurile de

dezvoltare, estimează costurile de dezvoltare, inclusiv costurile unui anumit nivel sau a unor variante

alternative de calitate, pe baza unor audituri sau a unor modele de evaluare.

Deşi modelele ce se vor prezenta în subcapitolul 4.3. au la bază elemente ale activităţii cu ajutorul

cărora se poate comensura costul efectiv al calităţii pe procese sau faze de dezvoltare, datele ce se culeg din

contabilitate inspiră cea mai mare încredere pentru managementul organizaţiei producătoare de software.

Dificultatea evidenţierii costului calităţii constă în faptul că munca de cuantificare a acestor costuri este

dificilă. Din această cauză, separarea acestor costuri şi ţinerea unei evideţe analitice separate (sub aspectul

evidenţei contabile, pe conturi analitice) este o problemă de apreciere colectivă, a compartimentelor de

contabilitate, asigurarea calităţii, a compartimentelor de dezvoltare, testare, precum şi a managementului. Cu

toate acestea, datele privind costurile calităţii nu se pot

extrage în totalitate direct din contabilitate, ele putând fi determinate pe trei căi: colectarea din

documente primare, înscrierea sumelor în conturi analitice, calcule simple, utilizându-se chei de repartizare.

Aşa cum se arată în [0LA1], pentru a sugera că, în general, o mare parte a cheltuielilor cu calitatea sunt

evitabile, în literatura de specialitate se propune utilizarea termenului de "costuri referitoare la calitate", în

locul termenului de "costurile calităţii".

Deşi, aşa cum s-a arătat, există diferenţe între industriile manufacturiere şi proiectele de dezvoltare de

software, în ceea ce priveşte costurile, este relevantă recomandarea de clasificaţi? conţinută în standardul ISO

9004-3, [ISO4], pentru cazul produselor rezultate din procese continue (figura 4.1).

31

În standardul menţionat, costurile de realizare a calităţii reprezentintă costurile implicate de realizarea

şi menţinerea nivelului specificat al calităţii, iar costurile de asigurare externă a calităţii cuprind costurile

demonstraţiilor şi probelor cerute de clienţi ca dovezi obiective ale calităţii, ale clauzelor speciale şi

suplimentare de asigurare a calităţii, procedurilor, datelor, încercărilor pentru demonstrare şi evaluare..

Costurile privind calitatea produselor software referă un ansamblu de activităţi care generează

cheltuieli ce pot fi grupate în următoarele categorii: (a) de prevenire, (b) de evaluare, (c) de identificare şi

remediere pe parcursul dezvoltării, (d) de remediere a defectelor (ale non-calităţii). în tabelul 4.1 se prezintă

o propunere de grupare a acestor costuri.

Tabelul 4.1

A. Costuri de

prevenire a

defectelor

- costuri determinate de implementarea, funcţionarea şi îmbunătăţirea

sistemului calităţii (stabilirea şi actualizarea standardelor interne şi a

procedurilor de calitate);

- costuri determinate de audituri ale calităţii, de verificarea calităţii

proiectelor de ansamblu şi de detaliu, a documentaţiilor intermediare;

- costuri legate de constituirea fluxului de control şi dirijare a proceselor

şi produselor în vederea asigurării calităţii;

- costuri de evaluare a subcontractanţilor, costuri de remediere a unor

programe, documentaţii, primite de la eventuali subcontractanţi;

- costuri determinate de ridicarea calificării personalului, de motivarea

acestuia, de angajarea unor experţi din exterior sau de personal cu

calificare superioară;

B. Costuri de

evaluare

- costul unor procese suplimentare de verificare, de exemplu costul

inspecţiilor pe codul sursă, ale auditării produselor software intermediare

şi finale;

- timpul suplimentar consumat pentru procesele de analiză a erorilor

sistematice, în vederea stabilirii cauzelor.

C. Costuri de

identificare şi

remediere, a

defectelor, pe

parcursul

dezvoltării

- costuri legate de achiziţionarea, testarea, învăţarea, exploatarea

produselor utilizate în procesul dezvoltării;

- costuri suplimentare apărute în procesul dezvoltării datorate

identificării şi remedierii unor erori la produsele intermediare (erori în

proiectare, în codificare, în elaborarea documentaţiilor), evidenţiate, la

intrarea şi ieşirea fiecărui proces, atât de compartimentele de QA, cât şi de

personalul de la dezvoltare software.

D. Costurile

remedierii

defectelor

a. Costuri la producător

- costuri suplimentare la finalul procesului de dezvoltare, determinate de

remedierea unor erori apărute după testarea şi inspecţia de calitate finală

(consumuri suplimentare de

Costurile referitoare la calitate

Costurile realizării calităţii Costurile de asigurare externa a cântaţi

Costuri de investi Costuri de defectare (pierderi)

Costuri de prevenire Costuri de evaluare Costurile defectărilor interne Costurile defectărilor externe

Figura 4.1. Costurile referitoare la calitate

32

Cauzele defectelor:

1 – cauze datorate

produselor suport şi a

produselor primite de

la subcontractanţi; 2 – cauze hardware;

3 – cauze umane;

4 – cauze

metodologice

(proceduri, tehnologii

inadecvate);

5 – cauze datorate unui

control defectuos;

6 – cauze datorate

mediului de desfăşurare a

procesului de

dezvoltare;

7 – cauze manageriale;

8 – mentenabilitate

redusă;

9 – marketing

defectuos.

timp, curent electric, hârtie, consumabile, trafic suplimentar pe liniile de

comunicaţie închiriate, etc.);

- costuri suplimentare determinate de repetarea unor teste şi verificări;

- costuri determinate de nerespectarea eventualelor obligaţii contractuale;

- costuri privind stingerea reclamaţiilor făcute de beneficiari;

- costuri suplimentare privind service-ul comercial;

- costuri suplimentare determinate de re-pregătirea produsului pentru

livrare,

b. Costuri la beneficiar

- costuri privind remedierea erorilor la produsele reclamate de beneficiari

ca necorespunzătoare s"au refuzate, în cazul m care recepţia se face la

aceştia (module de program, capitole de documentaţie, suporţi magnetici,

etc);

- costuri determinate de înlocuirea produselor menţionate la aliniatul

anterior;

- costuri privind testările, controalele, expertize la produsul ajuns la

destinaţie şi reclamat de beneficiar;

- costuri privind activitatea de mentenanţă în perioada de garanţie;

- costuri privind stingerea reclamaţiilor pentru calitate necorespunzătoare

făcute de beneficiari, în cazul în care recepţia are loc la beneficiar;

- costuri determinate de daunele provocate activităţii beneficiarului şi

reclamate de acesta, datorită calităţii necorespunzătoare a produsului

software livrat.

13. Raportul cost calitate - cost total Pe baza modalitatăţii de clasificaţie a costurilor calităţii software se poate evalua atât raportul dintre

costul calităţii şi costul total (parte - întreg), cât şi efectul costurilor referitoare la calitate asupra

performanţelor organizaţiei producătoare de software. Conform analizei prezentate în [0LA1] şi ţinând cont

de specificul industriei software şi de clasificaţia din subcapitolul 4.1., costurile de prevenire şi de evaluare

sunt considerate costuri de investiţii, iar celelalte intră în categoria costurilor de producţie sau a cheltuielilor

de exploatare.

Dacă efectul costurilor de investiţii este dificil de evaluat imediat, în cazul costurilor de identificare şi

remediere a erorilor în timpul procesului de dezvoltare sau al unor costuri de remediere la producător sau

beneficiar, scăderea lor va determina direct scăderea costurilor de producţie sau exploatare, reflectându-se

direct în creşterea profitului. în ceea ce priveşte relaţia imediată dintre costul total şi costurile de prevenire,

creşterea acestora va determina cu certitudine creşterea costurilor totale, chiar dacă este posibil ca, pe termen

mai lung, investiţiile respective (în sistemul calităţii), să conducă la creşterea vânzărilor şi deci, la

maximizarea profitului. Deci, evaluarea efectului lor asupra performanţelor» financiare ale organizaţiei este

îngreunată de faptul că acest efect poate fi pus în evidenţă doar în perioade ulterioare celei corespunzătoare

exerciţiului financiar curent [0LA1].

Cuantumul costurilor de evaluare poate avea un impact dublu. Astfel, pe de o parte, creşterea

cheltuielilor cu inspecţiile şi auditurile intermediare se reflectă în scăderea cheltuielilor de testare şi, în

general, a costurilor de identificare şi remediere a erorilor în timpul procesului de dezvoltare, astfel că efectul

lor asupra costurilor referitoare la calitate poate fi nul sau chiar de reducere a acestora. Pe de altă parte,

impactul creşterii acestor costuri asupra costului total nu poate determina o creştere direct proporţională, ci

dimpotrivă, poate avea ca efect scăderea costului total.

În plus, unele costuri referitoare la calitate sunt necuantificabile (acestea, de fapt, nici nu au fost prinse

în propunerea de clasificaţie prezentată). De exemplu, costul aferent pierderii unui contract, a unui client sau

a pieţei, ca urmare a vânzării unui produs necorespunzător calitativ, sau reducerea vânzărilor datorită faptului

că, prin calitatea necorespunzătoare a produselor, alţi producători realizează produse similare sau

substituenţi. De asemenea, în propunerea de clasificaţie prezentată, nu au fost incluse costurile de asigurare

externă a calităţii, aşa cum sunt ele prevăzute în standardul [ISO4]. Sub aspect conceptual, aceste costuri pot

include şi cheltuielile generate de participarea la târguri şi expoziţii, precum şi cheltuielile de reclamă şi

publicitate. Din punct de vedere contabil, aceste cheltuieli pot fi repartizate asupra produsului, fie prin

includerea lor la stabilirea unui preţ de cost, fie prin repartizarea pe bază de chei de repartiţie. Fie

următoarele notaţii:

33

Cp = costuri de prevenire

Ce = costuri de evaluare

Cd = costurile de identificare şi remediere a erorilor în timpul procesului de dezvoltare +

costurile de remediere la producător şi beneficiar (costurile totale de identificare şi

remediere a erorilor).

Aşa cum se arată în [COZI] şi [0LA1], potrivit abordării tradiţionale a analizei costurilor, referitor la

corelaţia cost-calitate, pe măsura creşterii costurilor de prevenire Cp şi a costurilor de evaluare Ce, se

produce scăderea costurilor Cd (figura 4.1).

Curba costurilor totale referitoare la calitate admite un minim, iar nivelul calităţii corespunzătoare

zonei haşurate (AB) este considerat optim. Se remarcă faptul că în zona respectivă Cd ≈ Cp+Ce. Zonele de

pe grafic din afara zonei optime, reprezintă "zona îmbunătăţirilor", respectiv "zona supracalităţii" (figura

4.2).

Co

stu

ri

Cp+Ce

Cd

Cost total minim

Cp+Ce+Cd

AA BB

Nivelul calităţii

Cd

≈C

p+

Ce

Figura 4.1. Corelaţia cost - calitate

Conform estimărilor din [COZI] şi [OLA1], precum şi a lucrărilor lui Juran şi Gryna, în zona

Co

stu

ri

Cp+Ce

Cd

Cost total minim

Cp+Ce+Cd

AA BB

Nivelul calităţii

Cd

≈C

p+

Ce

Figura 4.2. Corelaţia cost - calitate

Zona îmbunătăţirilor

Cd>70%

Cp+Ce<30%

Zona optimă

Curba costurilor totale Zona supracalităţii

Cd < 40%

Cp+ Ce > 60%

34

îmbunătăţirilor, Cd au o pondere mai mare de 70% în totalul costurilor referitoare la calitate, iar cele de

prevenire şi evaluare sub 30%. în această zonă, printr-o creştere relativ mică a costurilor de prevenire şi

evaluare (a investiţiilor), se poate obţine o reducere semnificativă a Cd. în zona supracalităţii Cd < 40%, iar

costurile de prevenire şi evaluare au o pondere mai mare de 60%. în această zonă, conform abordărilor

clasice amintite, reducerea Cd presupune costuri din ce în ce mai mari de prevenire şi evaluare.

În contradicţie cu abordarea clasică prezentată mai sus, strategia îmbunătăţirii continue (Kaizen), pe

lângă faptul că nu implică investiţii mari, determină obţinerea a două avantaje: 1. se poate obţine creşterea

nivelului calităţii fără eforturi prea mari; 2. aplicând principiul paşilor mici, se asigură o mai mare stabilitate

şi controlabilitate a proceselor.

În figura 4.3. se prezintă evoluţia costurilor totale minime, conform concepţiei îmbunătăţirii continue,

iar în figura 4. 4. se prezintă efectele îmbunătăţirii prin simplificare (sursa [0LA1]).

Figura 4.3.

Figura 4.4.

Costuri

0 100 % Nivelul calităţii

Cp+Ce

Cd Costuri

totale

Costul

total

minim

Costuri

0 100 % Nivelul calităţii

Cp+Ce

Cd Costuri

totale

Costul

total

minim

35

14. MANAGEMENTUL CALITĂŢII – PUNTE DE TRECERE DE LA

MANAGEMENTUL INFORMAŢIONAL LA CEL AL CUNOŞTINŢELOR Accesul managerilor şi specialiştilor la informaţii multidimensionale şi cunoştinţe despre toate

activităţile întreprinderii şi a mediului de afaceri este una dintre cele mai importante condiţii pentru

asigurarea competitivităţii în economia globală modernă. Generalizarea experienţei acumulate în domeniul

informatizării arată că tehnologiile informaţionale, sistemele informatice sunt necesare, dar nu şi suficiente

pentru asigurarea garantată a succesului activităţii de bază a organizaţiilor.

În ultimii ani soluţiile problemei în cauză sunt examinate în cadrul unor astfel de domenii ştiinţifice şi

practice cum ar fi: managementul informaţional (MI), managementul cunoştinţelor (MC) şi managementul

calităţii (MQ). Deşi aceste tipuri de management s-au dezvoltat ca direcţii ştiinţifice şi practice aparte, şi nu

se mai pune la îndoială importanţa fiecărui din ele în parte, ca condiţii necesare pentru asigurarea

competitivităţii unei întreprinderi, în ultima perioadă de timp au apărut unele publicaţii, în care se

menţionează anumite interdependenţe între ele. Aceasta reiese chiar şi din faptul că aceste tipuri de

management sunt examinate în acelaşi context ca condiţii de asigurare a competitivităţii întreprinderilor. Dar,

apar şi publicaţii care confirmă existenţa unor legături mai strânse decât cele menţionate. Chiar şi

interdependenţele unilaterale dintre oricare două tipuri de management dintre cele enumerate anterior,

studiate în literatura de specialitate, arată că realizarea lor în cadrul aceluiaşi sistem de management al

afacerilor (MA) asigură condiţii de sporire a eficienţei fiecărui tip de management în parte.

Scopul de bază al acestui articol este analiza interdependenţelor reciproce active dintre

managementul informaţional, managementul cunoştinţelor şi managementul calităţii în cadrul

managementului general al aceleiaşi întreprinderi, formând un model structural integrat al sistemului de

management al afacerilor, in care sunt prezente toate aceste tipuri de management. O atenţie deosebită va fi

acordată verificării ipotezei conform căreia MQ joacă un rol important în realizarea interdependenţelor dintre

MI şi MC, care ar avea un efect sinergetic din integrarea lor reciprocă.

Definiţiile noţiunilor de bază Fără a pretinde la o definire a noţiunilor informaţie, cunoştinţe, MI, MC şi MQ mai profundă, decât

mulţimea de definiţii diverse cunoscute în mediul de specialitate, vom accentua doar acele aspecte în

definiţiile existente, care le evidenţiază specificul în compararea reciprocă şi care ar putea influenţa formele

respective de management. În acest context, cele mai caracteristice aspecte ale noţiunilor de bază sunt

următoarele: informaţia este rezultatul procesări datelor; când informaţia se îmbină cu contextul şi

experienţa, ea se transformă în cunoştinţe. Noţiunea de „cunoştinţe” este mai superioară decât informaţia şi

documentele care o conţin. Cunoştinţele presupun un nivel de implicare umană [1], ele sunt informaţia

absorbită şi înţeleasă de persoană concretă. Sunt situaţii în care ceea ce pentru o persoană reprezintă o

informaţie pentru alta, cu o altă capacitate sau un alt rol, constituie o cunoştinţă.

Diferenţa dintre informaţie şi cunoştinţe, ne permite să diferenţiem diferite niveluri de generalizare a

informaţiei cuprinse în diapazonul între informaţie pur şi simplu ca date procesate şi informaţie, care

corespunde tuturor cerinţelor utilizatorului, fiind absorbită şi înţeleasă de persoane concrete în conformitate

cu necesităţile informaţionale reale, în contextul experienţei personale [2].

În articolul de faţă vom folosi una din cele mai cuprinzătoare definiţii ale MI, care include practic

toate tipurile de activitate informaţională ce corespund întregului diapazon de interpretări cunoscute ale MI

[3]: “managementul informaţional este planificarea, finanţarea, organizarea, încadrarea cu personal,

managementul, instruirea în domeniu şi controlul informaţiei. MI include managementul resurselor

informaţionale variate, cum ar fi:

suporturile informaţionale (documente sau medii electronice);

departamente care oferă servicii informaţionale;

sisteme informaţionale, atât computerizate, cât şi tradiţionale”.

Managementul informaţional poate fi uşor interpretat ca un termen “umbrelă”, ce include aşa

domenii ca ştiinţa computaţională (ce dezvoltă instrumentarul de realizare a funcţiilor), managementul

dosarelor, arhivelor şi bibliotecilor, precum şi managementul resurselor informaţionale. MI poate de

asemenea să includă telecomunicaţiile, managementul datelor, managementul documentelor şi

informatica în general.

Managementul cunoştinţelor este orice activitate structurată ce duce la sporirea capacităţii

organizaţiei de a dobândi, distribui şi utiliza cunoştinţe pentru supravieţuirea şi succesul său. MC este definit

ca “administrarea profesionistă a sumei sau a domeniului a tot ce a fost perceput, descoperit sau studiat în

întreprindere prin colectarea, integrarea, organizarea, analiza şi distribuirea cunoştinţelor de afaceri în aşa

36

mod ca să fie utilizate efectiv de către întreprindere pentru a efectua acţiuni efective şi a realiza scopurile

sale” [4] .

În [3] este subliniat scopul şi terenul comun al tuturor tipurilor de management: al datelor,

informaţiei, cunoştinţelor, înregistrărilor şi documentelor - ele toate au acelaşi obiectiv. În particular, ele tind

să gestioneze informaţia într-un mod, care ar asigura integritatea ei şi utilizarea în conformitate cu varietatea

scopurilor.

Ca proces managementul cunoştinţelor este îndreptat la managementul nu al documentelor propriu

zise, ci al conţinutului lor. În acest context autorii [3] menţionează că “managementul cunoştinţelor înseamnă

căpătarea (colectarea, procurarea, generarea), organizarea (clasificarea, indexarea, trasarea), recuperarea

(căutarea, accesarea), distribuirea (împărţirea, mişcarea) şi menţinerea (curăţirea, creşterea, sporirea,

îngrijirea) a conţinutului depozitului de date”

Obiectivele managementului calităţii tehnologiilor informaţionale şi a serviciilor informaţionale

(MQ) constau în identificarea, analiza şi interpretarea tuturor anomaliilor şi în definirea acţiunilor corective

sau de orientare a calităţii în toate etapele de realizare a TI şi/sau de prestare a serviciilor informaţionale.

Interdependenţe dintre MI, MC şi QM Pentru a înţelege rolul fiecărui din tipurile de management în cauză faţă de celelalte este necesar de

studiat interdependenţele dintre ele. Generalizând rezultatele relevante (deşi reprezentând interdependenţe

unilaterale) din literatura de specialitate, se poate admite ipoteza existenţei unor interdependenţe reciproce

dintre toate tipurile de management menţionate în cadrul aceluiaşi sistem de management al afacerilor, care

ar avea un efect sinergetic din integrarea lor reciprocă.

Printre cele mai reprezentative interdependenţe pot fi evidenţiate următoarele:

1) Interdependenţa reciprocă dinte MI şi MC (MI ↔ MC)

Tot mai frecvent sunt cercetate unele aspecte care confirmă dependenţa managementului cunoaşterii

de managementul informaţional (MI) [2, 5, 6] şi de managementul resurselor informaţionale [4], precum şi

de unele subsisteme aparte ale MI [1]. În [6] MI integrat, realizat în baza principiilor sistemice de integrare a

diferitor tipuri de management specializat (managementul datelor, managementul documentelor,

managementul înregistrărilor, managementul resurselor informaţionale, etc.) este prezentat ca o temelie

pentru dezvoltarea MC. Succint putem prezenta această dependenţă a MC de MI în felul următor: MC←MI.

Pe de altă parte, având în vedere că cunoştinţele sunt nişte informaţii cu proprietăţi deosebit de

importante pentru organizaţie, conştientizarea tipurilor de cunoştinţe şi a rolului lor în organizaţie poate fi

utilizată pentru concretizarea mai profundă a scopurilor şi formelor de realizare a MI. O astfel de abordare

este o condiţie necesară pentru eficientizarea activităţilor ce ţin de MI. Adică, în acest sens există şi o

dependenţă inversă dintre MC şi MI (MI ← MC).

2) Interdependenţa reciprocă dinte MI şi MQ (MI ↔ MQ)

Există relaţii reciproce foarte puternice între TI şi servicii informaţionale şi managementul total al

calităţii (MTQ), care au fost cercetate nu numai teoretic, dar şi practic [9]. IM este un factor foarte esenţial

de suport al implementării unui astfel de sistem ca MTQ, care necesită volume mari de informaţii. Deci,

eficienţa MQ depinde în mare măsură de nivelul de organizare a MI în organizaţia dată (MQ ← MI).

Pe de altă parte, implementarea MTQ în activităţile de bază a unei organizaţii presupune răspândirea

principiilor de MTQ asupra tuturor activităţilor, care suportă activităţile de bază, inclusiv şi asupra MI.

Totodată, o activitate multidimensională ca MI poate fi eficient organizată doar în condiţii de utilizare a

elementelor de MQ, care poate fi un mecanism de îmbunătăţire permanentă a calităţii datelor, soft-ului şi

informaţiilor (MI ← MQ).

3) Interdependenţa reciprocă dintre MQ şi MC (MQ ↔ MC)

De exemplu, în [7, 9] se menţionează că, odată ce strategia orientată la calitate depinde de capacitatea

capitalului intelectual al organizaţiilor de a menţine competitivitatea produselor şi a serviciilor, iar angajaţii

în astfel de organizaţii trebuie să efectueze activităţi bazate pe utilizarea cunoştinţelor, managementul

cunoaşterii devine un factor critic pentru succesul activităţii companiilor, care utilizează sistemul MQ. Deci,

în acest context, MQ depinde în mare măsură de MC (MQ ← MC).

Pe de altă parte, sunt menţionate şi dependenţe inverse dintre MQ şi MC. De exemplu, în [8, 5, 6]

este analizată influenţa pozitivă a utilizării mecanismelor de control al calităţii asupra proceselor de bază ale

managementului cunoştinţelor.

Reieşind din definiţia noţiunii de cunoştinţe (ca informaţie, care corespunde tuturor cerinţelor

utilizatorului, fiind absorbită şi înţeleasă de persoane concrete în conformitate cu necesităţile informaţionale

reale, în contextul experienţei personale, adică acele informaţii, care corespund anumitor cerinţe faţă de

calitate), informaţiile rezultative în sistemul informatic pot fi îmbunătăţite permanent în baza unui feedback

activ (conexiune inversă) susţinut de sistemul de management al calităţii produselor şi serviciilor

37

informaţionale. Cu alte cuvinte, utilizarea principiilor de management al calităţii faţă de MI este o condiţie

necesară pentru extragerea cunoştinţelor din fluxurile de informaţii asigurate de MI.

Deci, MC poate fi în mare măsură asigurat de utilizarea MQ faţă de procesele de MI în firma dată,

ceea ce înseamnă că MC depinde de MQ (MC←MQ).

Astfel, pe deoparte, în firma dată managementul calităţii produselor şi serviciilor de bază poate fi

eficient doar pe baza cunoştinţelor necesare din domeniu (obţinute ca rezultat al unui management al

cunoaşterii). Pe de altă parte, managementul cunoştinţelor poate fi mai efectiv, dacă este organizat pe baza

utilizării principiilor de management al calităţii, folosite faţă de MI. Aceasta mărturiseşte despre

interdependenţa reciprocă strânsă dintre aceste două tipuri de management.

În baza generalizării celor menţionate, putem conclude că există interdependenţe reciproce între toate

cele trei tipuri de management (MI, MQ şi MC). Relaţiile dintre fiecare din aceste tipuri de management şi

managementul general, al afacerilor (MA) reies din înseşi definiţiile lor. Schema generală, care reprezintă

interdependenţele reciproce în cauză, este prezentată în figura 7.1.

Un rol deosebit în această interdependenţă îl joacă MQ, care serveşte în calitate de punte de trecere

dintre MI şi MC. Folosirea managementului calităţii în procesele managementului informaţional poate

transforma MI în temelie sigură pentru managementul cunoştinţelor.

Odată ce fiecare din tipurile enumerate de management contribuie la eficientizarea celorlalte tipuri,

putem conclude că un efect maximal al influenţei lor la eficienţa managementului afacerilor poate fi obţinut

doar prin realizarea lor în paralel ca subsisteme, care interacţionează în cadrul aceluiaşi sistem de

management al afacerilor.

Concluzii Deşi mai multe forme de management (informaţional, al cunoaşterii, al calităţii tehnologiilor şi

serviciilor informaţionale etc.) se dezvoltă în literatura de specialitate ca direcţii aparte, la ora actuală sunt

observate unele elemente de convergenţă dintre ele. Prin urmare, este necesară studierea mai profundă a

interdependenţelor dintre aceste direcţii, cu atât mai mult că ele se intersectează din punct de vedere a

scopului şi terenului comun al tipurilor respective de management.

Interdependenţele reciproce dintre formele de management în cauză, discutate în articolul de faţă,

sunt generalizate şi prezentate ca subsisteme ale sistemului de management al afacerilor.

Generalizând cele menţionate în lucrare, putem conclude că un sistem de management al afacerilor,

bazat pe o strategie integrată, orientată la MTQ, poate fi eficient cu adevărat doar în condiţiile dacă

realizează toate dimensiunile de management (cel informaţional, al cunoaşterii şi al calităţii) conjugate ca

subsisteme ale unui singur sistem de management al afacerilor cu un scop final comun (figura 7.2). O astfel

Managementul

cunoştinţelor

(MC)

Managementul

informaţional (MI)

Sistemul informaţional

managerial (SIM)

Managementul calităţii

(MQ)

TI şi serviciilor

informaţionale

Figura 7.1. Schema interdependenţelor dintre diferite forme de management: MA, MC, MI (SIM) şi MQ

Managementul afacerilor

(MA)

38

de abordare a problemei contribuie la sporirea nu numai a eficienţei fiecărui tip de management aparte, dar şi

a efectului sinergetic cauzat de interacţiunea lor reciprocă în cadrul sistemului de management al firmei.

15. Abordarea sistemică a problemei pregătirii cadrelor în domeniul managementului informaţional

Informatica este unul din cele mai dinamice domenii ale ştiinţei şi practicii moderne. Dezvoltarea

continuă a informaticii condiţionează modificări respective şi în activităţile profesioniştilor informaticieni.

Deşi, în linii mari specialiştii, care practică diferite activităţi cu datele, informaţia, cunoştinţele, înregistrările

şi documentele au aceleaşi obiective (în particular, ei caută să gestioneze informaţia într-un mod, care ar

asigura integritatea si folosirea la o varietate de scopuri), dezvoltarea accelerată a tehnologiilor

informaţionale (TI) schimbă permanent hotarele dintre multe profesii specifice şi chiar natura (sensul) lor.

Un rol aparte în acest context îl au unele probleme de convergenţă a tehnologiilor informaţionale,

care după cum a fost observat în [1], contribuie la apariţia noilor profesii, în special ale celor de manageri

informaţionali. Convergenţa în mediul când totul devine digital, ştergând distincţiile dintre documentele

tipărite, vizuale, audio- şi multimedia, duce la confluenţa disciplinelor şi a activităţilor profesionale

respective. Din toate acestea rezultă că problemele de pregătire a specialiştilor în domeniul informaticii, care

ar corespunde cerinţelor moderne ale societăţii, trebuie să fie permanent în atenţia instituţiilor abilitate în

domeniu.

Scopul comunicării de faţă constă în formularea unor probleme ce ţin de abordarea sistemică a

dezvoltării programelor de studii şi de pregătire a specialiştilor în domeniul managementului informaţional

(MI) în conformitate cu necesităţile societăţii informaţionale.

Crearea unui spaţiu informaţional unic al societăţii prezintă o problemă foarte complexă, care nu

poate fi soluţionată eficient fără un management informaţional bine organizat la toate nivelurile de ierarhie

supuse informatizării (întreprindere, asociaţii, subramuri, ramuri ale economiei naţionale, societate). Nu

întâmplător managementul informaţional a devenit una din cele mai frecvente noţiuni utilizate în mediul

informaticii. În acelaşi timp, se observă o mare varietate de abordări ale acestei probleme la nivel naţional

(inclusiv nivelul micro şi macro al societăţii), internaţional şi global [1,2]. Această situaţie este reflectată de

Figura 7.2. Model structural - funcţional al sistemului de management al afacerilor,

în care în calitate de subsisteme sunt realizate MI, MC şi MQ

Consumatorii

de produse

şi servicii

Parteneri

în schimb

de date

Utilizatori

externi

ai SIM, TI

Organizaţia (întreprinderea)

Sisteme informatice

manageriale (SIM),

Tehnologii

informaţionale (TI)

în managementul

afacerilor

Managementul afacerilor

(MA)

Procesul de producere

şi prestare servicii

Sistemul informatic

al managementului

total al calităţii

Managementul

informaţional

(MI)

Managementul

calităţii TI şi SIM

Managementul

cunoaşterii (MC)Managementul

total al calităţii

produselor şi

serviciilor

(MTQ)

39

diversitatea interpretărilor termenului conceptual “managementul informaţional”: de la înţelegerea lui în cel

mai îngust sens al cuvântului (ca sinonim al tehnologiei informaţionale, uneori însemnând doar organizarea

datelor în memoria computerului -“managementul datelor”), până la cel mai larg sens al MI, care cuprinde

practic toate tipurile de activitate informaţională.

O astfel de varietate de interpretări ale noţiunii MI influenţează în mod direct şi formele de realizare a

MI, reflectându-se inclusiv şi asupra pregătirii specialiştilor în domeniul managementului informaţional,

unde se observă cam aceeaşi diversitate de abordări. Simţind necesitatea societăţii, mai multe instituţii de

învăţământ superior, au început să pregătească cadre în domeniul managementului informaţional, dar

neştiind prea clar, cum ar trebui să fie aceşti specialişti şi ce ar trebui să cunoască. În unele universităţi sunt

predate discipline noi sub denumirea de Management informaţional, iar în altele a apărut chiar

specializarea în acest domeniu. Dar în majoritatea cazurilor accentul în programele de învăţământ e pus pe

unele aspecte foarte înguste ale MI, neglijând în majoritatea cazurilor competenţe importante care trebuie să

fie formate la respectivii specialişti.

În acest context, sunt necesare noi cercetări în teoria şi practica mondială în acest domeniu: în

pregătirea specialiştilor informaticieni, în general, şi în pregătirea managerilor informaţionali, în particular.

Tendinţele de bază în dezvoltarea MI ca factori de influenţă în formarea

specialităţii „Managementul informaţional” Managementul informaţional a devenit o problemă odată cu apariţia societăţii şi a fluxurilor esenţiale

de informaţii. Dar ca domeniu important al ştiinţei şi practicii a început să se dezvolte accelerat doar în

ultimele 2 decenii în rezultatul dezvoltării rapide a tehnologiilor informaţionale şi a modificării continue şi

semnificative a profesiilor informaţionale respective. Analiza experienţei acumulate în domeniu [3,4] ne

permite să facem concluzi că pentru asigurarea unui MI eficient este necesară în primul rând o structurare

mai strictă a mediului de aplicare, o formulare exactă a conceptelor de bază şi a corelării lor reciproce în

cadrul sistemului. Cu atât mai mult acestea sunt necesare în cazul pregătirii cadrelor în acest domeniu de MI,

având ca scop asigurarea plenitudinii funcţionale a sistemului de management informaţional, pe deoparte, şi

reducerea redundanţei nejustificate, pe de altă parte.

În [5-7] în baza generalizării experienţei acumulate în domeniul informatizării societăţii au fost

evidenţiate următoarele direcţii de bază ale dezvoltării MI, care reprezintă ambele extreme reprezentative ale

diapazonului de interpretări ale acestei noţiuni:

MI în sensul tehnologic, condiţionat de şcoala informatică, când centrul de greutate în sensul

MI îl au tehnologiile informaţionale şi sistemele informatice ca instrumentar de soluţionare a

multor probleme ce ţin de organizarea fluxurilor informaţionale;

MI în sensul tradiţional al noţiunii de management, când resursele informaţionale sunt tratate

ca toate celelalte resurse materiale, energetice, umane etc., iar MI este interpretat din punct de

vedere al funcţiilor de dirijare: planificare, evidenţă, organizare, etc.

În direcţia tehnologică a managementului informaţional sunt evidenţiate numeroase subdirecţii,

principalele dintre ele fiind următoarele:

Managementul datelor, care include proiectarea, crearea, implementarea şi administrarea

bazelor de date;

Proiectarea, crearea, implementarea şi administrarea sistemelor informatice în procesul

exploatării lor;

Managementul documentelor, care cuprinde etapele de proiectare, elaborare, exploatare şi

administrare a sistemelor informatice documentare;

Managementul înregistrărilor, orientat la proiectarea, elaborarea şi exploatarea sistemelor

informatice de organizare şi procesare a documentelor care reflectă tranzacţii economice;

Managementul cunoştinţelor, care include identificarea, acumularea, organizarea şi utilizarea

cunoştinţelor în procesele de dirijare.

Aria de influenţă a acestui tip de management informaţional în sens tehnologic este prezentată

într-un şir de lucrări de un model structural – funcţional integrat (figura 8.1)

Tratarea tradiţională a MI este mai mult sau mai puţin fără contradicţii în literatura de specialitate.

Anume în acest context este mai clară interpretarea MI ca parte componentă a managementului general al

proceselor, ce au loc în unităţile social-economice (USE) de diferite niveluri de ierarhie, ca subsistem care

trebuie să creeze condiţii optime pentru a contribui la realizarea scopului şi produsului final al USE.

În [6,7] este argumentată necesitatea creării unui spaţiu informaţional integrat, care reflectă adecvat

toate procesele ce au loc în sistemul real, şi poate asigura condiţii pentru extragerea cunoştinţelor necesare

pentru managementul efectiv al USE-

40

Pot fi evidenţiate două grupe de probleme, care devin actuale în contextul temei abordate:

1) probleme de integrare în cadrul fiecărui tip de management. Aici orientarea trebuie să fie la

abordarea sistemică, în primul rând la cuprinderea ciclului întreg de viaţă a resurselor informaţionale

(care include toate etapele de la apariţia lor până la trecerea în stare pasivă după utilizare, de exemplu,

în arhive), atât în forma electronică, cât şi pe suporţi tradiţionali;

2) probleme de integrare între nivelurile şi tipurile de management referitor la date, informaţii,

cunoştinţe, documente, arhive (figura 8.1). În ultima perioadă de dezvoltare a managementului

informaţional au început să ia amploare unele direcţii noi de MI, bazate pe integrarea tipurilor de MI

deja existente, cum ar fi: managementul datelor cu managementul documentelor, managementul

documentelor cu managementul înregistrărilor.

În ultimii 10 ani a început să se dezvolte un nou tip de management (managementul calităţii

tehnologiilor şi serviciilor informaţionale), care se intersectează esenţial cu soluţionarea problemelor MI în

sensul larg al cuvântului. Managementul calităţii în acest domeniu reprezintă un exemplu de convergenţă a

Managementul Informaţional

Managementul Cunoştinţelor

Fig. 8.1. Modelul structural al managementului informaţional

41

diferitor tipuri de MI, care este bazat pe îmbinarea aspectelor caracteristice pentru ambele extreme de

interpretare a MI: manageriale şi tehnologice.

În aceleaşi lucrări [6,7] este argumentată concluzia că integrarea tuturor formelor de MI bazată pe

utilizarea managementului calităţii tehnologiilor şi serviciilor informaţionale este condiţia fundamentală a

dezvoltării celei mai moderne forme de management informaţional: managementul cunoştinţelor . În mod

generalizat cele menţionate despre tipurile şi direcţiile de dezvoltare a MI pot fi prezentate în figura 8.2, care

reprezintă o structurare a domeniului integrat de MI şi totodată un cadru de orientare pentru cercetare-

dezvoltare a MI, dar mai ales, pentru pregătirea cadrelor în domeniul MI.

Necesitatea unui cadru de formare profesională în domeniul MI Din cele menţionate mai sus referitor la multidimensionalitatea MI, convergenţa continuă a diferitor

tipuri de MI (în sensul tehnologic şi tradiţional al noţiunii) putem conclude că pregătirea cadrelor în acest

domeniu este o problemă complexă şi cere o atenţie permanentă din partea instituţiilor de învăţământ

superior. În primul rând, este necesar un cadru general de orientare pentru programele de învăţământ în

domeniu. Totodată programele de formare profesională în MI trebuie să fie bine coordonate cu programele

de specializare în toate celelalte subdomenii ale informaticii în vederea excluderii redundanţei nejustificate.

Managerii informaţionali trebuie să aibă o viziune largă, bazându-se pe o abordare sistemică a

problemelor complexe[3]. Ei trebuie să aibă un spectru mai larg de cunoştinţe care să le permită să cuprindă

mai multe aspecte ale tehnologiilor informaţionale, pe de o parte, ale managementului informaţional (inclusiv

managementul cunoştinţelor), managementul calităţii în sisteme informatice şi managementului general (al

afacerilor), pe de altă parte.

A devenit o problemă majoră pregătirea specialiştilor de sistem de înaltă calificare, capabili să

îndeplinească individual lucrări complexe vizând elaborarea noilor tehnologii informaţionale, a sistemelor

informatice ce ţin de infrastructura informaţională de baza a societăţii. Cel mai acut aspect al acestei

Managementul general al USE

Managementul informaţional în sensul îngust, condi ţionat de şcoala informatică

Managementul informa ţional

Managementul calităţ ii în sisteme informatice

Managementul cunoştinţelor

Managementul informaţional în sensul condiţionat de şcoala de management

Tehnologiile informaţionale ca instrumentar de soluţionare a problemelor ce ţin de organizarea fluxurilor informaţionale

Planificarea, finanţarea, organizarea, încadrarea cu personal, managementul,

instruirea în domeniu şi controlul informaţiei

Managementul datelor,Managementul documentelor,Managementul informa ţional,Managementul cunoştinţelor

Managementul resurselor informaţionale:•supor ţii informaţionali (documente, medii

electronice);•departamente, care ofer ă servicii informa ţionale;

•sisteme informaţionale computerizate şi tradi ţionale, etc.

Fig. 8.2. Structura conceptuală a managementului informaţional şi al cunoştinţelor

42

probleme este pregătirea managerilor de proiect, de sistem si, în general, a specialiştilor în domeniul MI.

Activitatea specialiştilor informaticieni se desfăşoară într-un mediu foarte dinamic sub influenţa

multiplilor factori care se schimbă în permanenţă. Toate acestea condiţionează un şir de cerinţe faţă de

informaticieni (în special pentru specialiştii de sistem) şi, respectiv, faţă de sistemul de formare a lor.

În Academia de Studii Economice a fost acumulată anumită experienţă în pregătirea cadrelor în

domeniul Managementul informaţional în cadrul ciclului 1 (licenţă) şi a ciclului 2 (masterat). Având în

vedere necesitatea acoperirii integrale a dimensiunilor menţionate anterior ale domeniul de MI, programul de

specializare în MI (ciclul 2-masterat) prevede o orientare a studiilor nu atât la acumularea de cunoştinţe

concrete (care în mod accelerat se învechesc), cât la dezvoltarea capacităţilor de gândire sistemică şi

actualizarea permanentă a acestora în procesul activităţii practice, conform evoluţiei progresului tehnico-

ştiinţific în domeniu.

Din acest motiv, programul de studii include pe lângă disciplinele privind aspectele concrete ale

tehnologiilor informaţionale (care presupun însuşirea mijloacelor şi instrumentarului: afaceri electronice,

proiectarea sistemelor informatice, baze de date, reţele informatice, tehnologii de procesare, etc., studiate în

mare parte la ciclul 1), şi discipline orientate la o pregătire teoretică fundamentală, la formarea unei culturi

profesionale adecvate si a gândirii sistemice, discipline necesare pentru rezolvarea optimă a problemelor de

informatizare complexe (managementul cunoştinţelor, managementul calităţii produselor şi serviciilor

informaţionale, gestiunea proiectelor informatice etc.), care apar permanent intr-un mediu dinamic (figura

8.3). În acest context, în programul de studii sunt prezente şi aşa discipline opţionale ca: analiza sistemică,

cibernetica proceselor economice, inteligenţa artificială, sisteme suport pentru decizii, etc.

Analizând primele rezultate a celor 2 ani de pregătire a specialiştilor în MI, considerăm că programul

de studii al ASEM ar putea fi pus la baza creării unui cadru general de orientare pentru programele de

învăţământ în domeniu pentru alte universităţi din Moldova

43

Concluzii Din cercetările efectuate [3-7] şi din experienţa acumulată în Academia de Studii Economice din

Moldova pot fi extrase unele concluzii, principalele dintre care sunt următoarele:

1) Programele de învăţământ orientate la formarea specialiştilor în domeniul managementului

informaţional trebuie să aibă la temelie o abordare sistemică a problemei. La baza trebuie să fie

sistematizarea activităţilor informaţionale la toate nivelurile de ierarhie în societate şi generalizarea celor mai

moderne teorii şi experienţe acumulate în informatică;

2) Este necesară elaborarea unui cadru naţional de formare profesională a specialiştilor în

managementul informaţional, în care ar fi determinat conceptul de management informaţional, dată

descrierea specialităţii şi reglementate disciplinele (unităţile de cursuri) obligatorii în programele respective

de studii;

3) Având în vedere dinamismul accelerat al informaticii, pentru perfecţionarea sistemului de pregătire

a specialiştilor în domeniu sunt necesare:

efectuarea permanentă a cercetărilor impactului schimbărilor în domeniul tehnologiilor

informaţionale asupra specialităţilor informatice;

perfecţionarea curriculum-urilor specialităţilor informaţionale (şi nu numai) în contextul

dezvoltării Societăţii Informaţionale.

MI aspecte tehnologice:

•Sisteme informatice financiar-contabile

•Afaceri electronice

•Îndeplinirea şi susţinerea tezei de masterat, etc.

MI aspecte traditionale şi mixte:

•Gestiunea proiectelor informatice

•Economia serviciilor informatice

•Gestiunea securităţii informatice

MI de nivel superior

•Managementul cunoştinţelor

•Managementul calităţii

produselor şi serviciilor informatice

(supuse managementului informaţional)

Grupa de discipline opţionale:

Teoria sistemelor, Programarea ERP, Cibernetica proceselor economice,

Limbaje de modelare, Inteligenţă artificială,

Sisteme suport pentru decizii, Integrarea aplicaţiilor Windows,

Fiabilitatea sistemelor informatice, etc.

Instrumentare de realizare a MI şi MC:

•Tehnologii avansate de reţea

•Tehnologii de programare

•Procesarea limbajului natural,

•etc.

MI aspecte tehnologice concrete,

insusite la ciclul1:

Proiectarea sistemelor informatice,

Baze de date, Retele informatice,

Tehnologii de procesare a informatiei

Programarea calculatoarelor,

Sisteme de operare, etc.

Managementul informaţional

Figura 8.3. Structura programului de formare profesională în domeniul MI

QM TI NoteCurs P-u Examen

Documents

Transcript of QM TI NoteCurs P-u Examen