1

Ilie Costa, doctor habilitat, profesor univerisitar

Managementul calitii tehnologiilor i sistemelor informaionale

(notie de curs)

ASEM, Chiinu, 2012

Academia de Studii Economice din Moldova Catedra Cibernetic i Informatic Economic

Ilie Costa, doctor habilitat, profesor universitar. Managementul calitii tehnologiilor i sistemelor informaionale (notie de curs)
Manualul n form electronic este destinat masteranzilor care se specializeaz n domeniul Managementului informaional. n baza acestui curs a fost folosit manualul Dr. L. TEODORESCU, Dr. I.IVAN. MANAGEMENTUL CALITATII SOFTWARE. BUCURESTI, 2001. ns au fost adugate i compartimente noi, extinznd noiunea de management al calitii software pn la o noiune mai larg managementul calitii tehnologiilor i sistemelor informaionale i avnd n vedere toate etapele ciclului de via a TI i SI. Totodat, o atenie deosebit a fost acordat analizei sistemice a rolului managementului calitii n dezvoltarea managementului informaional i, n special, a managementului cunoaterii.

CUPRINS
1. Introducere 1.1. Abordri moderne ale problemei calitii 1.2. Calitatea produselor software - particulariti 1.3. Managementul calitii-component a managementului firmei. calitii TI n organizaiile specializate n TI 2. Abordarea managerial orientat pe produs 2.1. Sistemul caracteristicilor de calitate ale produselor software 2.2. Definirea caracteristicilor de calitate 2.3. Modele ale sistemelor caracteristicilor de calitate software 2.4. Caracteristici de calitate particularizate pentru clase de aplicaii software specifice 2.5. Metrici i sisteme de metrici ale caracteristicilor de calitate software 2.6. Scalare, clasificare i evaluare conform standardului ISO/IEC 9126 2.7. Abordarea orientat pe produs i controlul dezvoltrii software 3. Abordarea managerial orientat pe proces 3.1. Ciclu de via - modele i structuri 3.2. Principii de proiectare a proceselor de dezvoltare software 3.3. Gestiunea construirii calitii software 3.4. Inspectarea calitii software 3.6. Auditul calitii software 4. Abordarea managerial orientat pe raportul cost-calitate 4.1. Costul calitii software - definire, coninut i propunere de clasificaie 4.2. Raportul cost calitate - cost total 4.3. Modele de evaluare a costului calitii software 4.4. Managementul calitii pe baz de costuri 5. Abordarea managerial orientat spre utilizator 5.1. Conceptul de software corespunztor pentru utilizare 5.2. Sistem de metrici din perspectiva utilizatorului de software 6. Restructurri i tendine n dezvoltarea de software cu implicaii n managementul calitii 6.1. Calitatea software i protecia consumatorilor 6.2. Politica produselor software "destul de bune" 6.3. Noile standarde i produse ale reelei globale MANAGEMENTUL CALITII PUNTE DE TRECERE DE MANAGEMENTUL INFORMAIONAL LA CEL AL CUNOTINELOR
7.
8.

4 4 7 Managementul 9 12 12 15 20 23 35 41 45 48 48 58 66 73 80 86 86 90 95 98 105 105 107 115 115 122 125 LA

ABORDAREA SISTEMIC A PROBLEMEI PREGTIRII CADRELOR N DOMENIUL MANAGEMENTULUI INFORMAIONAL

9. Concluzii Bibliografie Anexe

3

135 138

1. Introducere
1.1. Actualitatea: Din cursul Managementul cunotinelor cunoatem rolul managementului calitii (QM) n realizarea managementului cunotinelor (MC): QM aplicat n realizarea managementului informaional (MI) creeaz condiiile fundamentale pentru dezvoltarea MC (figura 1.1). n acest context, actualitatea managementului calitii tehnologiilor i a sistemelor informaionale este foarte convingtoare. Totui, managementul calitii TI i SI are cel mai evident i nemijlocit impact n primul rnd asupra managementului informaional. Asigurarea calitii tehnologiilor i sistemelor

Managementul afacerilor

Managementul cuno cunotin tinelor

MI integrat aliniat la MA prin intermediul TQM n SI

Managementul informaional n sens tradiional MI n sens tehnologic

Managementul calitii n SI

Figura 1.1. Utilizarea managementului calitii fa de managementul informaional condiie de baz a dezvoltrii managementului cunotinelor

informaionale devine tot mai important. Pot fi analizate numeroase exemple despre rolul calitii n acest domeniu. Un exemplu convingtor ar fi urmtorul.

Ziua deschiderii aeroportului internaional din Denver (AID) n 1995, planificat ca cel mai mare aeroport din SUA , a fost o srbtoare pentru cetenii din Colorado, dar i sfritul unei perioade traumatice pentru industria TI. AID a fost planificat pentru a deservi anual 110 000 000 de pasageri, pentru asigurarea zilnic a 1750 de zboruri prin 200 de pori i 12 piste de aterizare i decolare. Darea n exploatare a aeroportului a fost amnat cu 16 luni, n primul rnd, din cauza eecului tehnologiilor informaionale, care trebuiau s asigure gestionarea sistemului de distribuire a bagajelor. Aceast ntrziere a cauzat pierderi enorme, estimate la 2 miliarde de dolari. Chiar i sistemul TI dat n exploatare a cauzat mai multe deficiene. Toate aceste mpreun au fost foarte traumatice pentru profesia TI, din cauza pierderii interesului i atitudinii publice fa de domeniu. Profesionitii n asigurarea calitii soft-ului consider c dac n proiectul respectiv din start era folosit un sistem de asigurare a calitii soft-ului , pierderile puteau fi excluse, sau cel puin reduse esenial. Este foarte important ca nainte de a ncepe un proiect complex i costisitor de soft s fim siguri c acest proiect va fi realizat n timp i c vor fi realizate cerinele fa de calitate. Pentru aceasta nu e suficient s convingem proiectanii c ei trebuie s lucreze calitativ. Sunt necesare anumite metode i instrumente i, n special proceduri de management al riscurilor la toate etapele ciclului de via al soft-ului, ncepnd cu primele etape ale proiectului. Anume managementul calitii software ca sistem poate asigura aceste cerine.

1.1. Abordri moderne ale problemei calitii

Actuala perioad pe care o parcurge societatea romneasc este caracterizat, n principal, prin adoptarea i statuarea unor noi modele organizaionale n domeniile social, politic i economic. Un loc important n cadrul acestor mutaii l ocup ncercrile prin care diveri factori cu pondere economic i social - o parte a corpului managerial, nvmntul i chiar o parte a clasei politice n formare -ncearc s-i nsueasc, s adapteze i s se adapteze, s cunoasc i s impun o nou cultur a calitii. Acest lucru se nscrie n tendina general a societii romneti de a se alinia, cel puin n form, valorilor ce caracterizeaz societatea occidental, societate ce, n urm cu peste patru decenii, sesiza importana economic a calitii i dezvolta primele tehnici, teorii i modele ce aveau s pun bazele unui nou tip de cultur - cultura calitii. n domeniul economic, creterea importanei calitii a fost determinat de diversificarea i nnoirea/rennoirea rapid a ofertei de bunuri i servicii, mondializarea pieelor - facilitat de progresele din telecomunicaii i din domeniul reelelor de calculatoare - creterea exigenelor

clienilor i ale societii, creterea complexitii produselor i serviciilor. Acest lucru a fcut ca, pe lng anumii parametrii "clasici" ai caracteristicilor de calitate ale diferitelor produse, s apar i alii noi, cum ar fi caracterul nepoluant sau nepericulozitatea, astfel c, n prezent, calitatea a devenit un factor determinant al complexitii unei entiti. nc de la sfritul anilor '80, organizaia internaional pentru standarde, I.S.O., cu sediul la Geneva - Elveia, ncepe s publice primele standarde referitoare la calitate. Standardul ISO-8402 "Managementul i asigurarea calitii - Vocabular" [ISO3], definete calitatea ca ansamblul caracteristicilor unei entiti, 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-stttoare, ci se definete n relaia cu anumite persoane (figura 1.2) - clieni, productori, furnizori, comerciani, etc. - este o variabil continu i nu una discret - dei metricile prin care se exprim unele caracteristici de calitate, au un caracter discret - i presupune satisfacerea nu numai a Client Productor Furnizor Comerciani Alii
Figura 1.2. Categoriile de persoane, care influeneaz definirea caracteristicilor calitii

Calitatea Calitatea

nevoilor exprimate, dar i a celor implicite. Mergnd un pas mai departe fa de standardul ISO-8402, specialitii japonezi n calitate, au elaborat metoda "Quality Function Deployment" [ZUL1], conform creia, printre altele, nevoile exprimate n cerine ale beneficiarilor, pot fi: normale sau explicite, ce apar n specificaii i reies din discuiile cu clientul, fiind satisfcute n raport direct cu prezena lor n entitatea respectiv; - implicite, considerate elementare, i de

aceea de cele mai multe ori nici nu se mai menioneaz, prezena lor n entitatea livrat nu d un spor de satisfacie, n schimb absena lor poate fi total nesatisfctoare; - deosebite, cele mai dificil de ndeplinit, fiind peste ateptrile clienilor. Absena lor nu produce insatisfacii, deoarece sunt neateptate, dar prezena produce o satisfacie deosebit, aducnd totodat productorului importante avantaje pe pia. Universalitatea calitii este reliefat i prin definirea noiunii de entitate, ce apare n definiia calitii din standardul ISO 8402. Astfel, o entitate poate fi o activitate, un produs sau un proces, o persoan sau un grup de persoane, o organizaie, un sistem sau o combinaie ntre toate acestea.

Noua cultur a calitii a determinat i apariia unor modele de management corespunztoare. Managementul calitii este parte component att a tiinei managementului ct i a managementului practic al firmelor i organizaiilor. Introducerea n practic a tehnicilor managementului calitii produce modificri n cadrul organizaiilor, att n ceea ce privete organizarea procesual i structural (compartimentele de asigurare a calitii - "Quality Assurance" - ce au aprut pe lng controlul tehnic de calitate C.T.C., cercurile calitii, servicii de audit i controlling, echipe transfuncionale) ct i n ceea ce privete mentalitile managerilor i executanilor, poziia clienilor, poziia proceselor unul fa de altul, etc. Calitatea nu mai trebuie doar verificat, ci produs. Concepia modern despre calitate privete acest concept dinamic i leag calitatea produsului sau serviciului de alte dou elemente: calitatea concepiei (proiectului) i calitatea fabricaiei. Conform standardelor ISO, calitatea fabricaiei reprezint gradul de conformitate a produsului cu documentaia tehnic, iar calitatea proiectului exprim msura n care proiectul produsului asigur satisfacerea cerinelor beneficiarilor i posibilitatea de folosire, la fabricaia produsului respectiv, a unor procedee tehnologice raionale i optime din punct de vedere economic (figura 1.3), unde: A = cerinele beneficiarului; B = caracteristicile calitii prevzute n documentaia tehnic; C = caracteristicile produsului; 1 = calitatea concepiei; 2 = calitatea fabricaiei; 3 = calitatea produsului (sau serviciului).

3 = calitatea produsului (sau serviciului). Calitatea fabricaiei

calitatea concepiei

B = caracteristicile calitii prevzute n documentaia tehnic

C = caracteristicile produsului

Figura 1.3. Elementele conceptului calitii

La aceste noiuni se adaug i conceptul de calitate livrat. Calitatea livrat se refer la nivelul real al calitii produsului sau serviciului, n momentul achiziionrii de ctre beneficiar.

1.2. Calitatea produselor software - particulariti

Dac societatea contemporan este o societate a calitii, atunci ea este n aceeai msur o societate a informaiei i a tehnologiei informaiei. n industria de software, ntlnim aceeai concentrare pe produs a concepiei, execuiei, asigurrii i verificrii calitii, ca n faza preindustrial, dar, pe de alt parte, datorit complexitii produsului rezultat, exist grupul de executani, mprit n colective sau indivizi specializai, care acioneaz pe parcursul unor nlnuiri de faze (ciclu de via). Modelul de producie n industria software este un model de "producie a proiectelor". Particularitatea produciei de software rezid n faptul c activitile desfurate pot fi specifice unei anumite faze a ciclului de via, sau pot fi independente de fazele ciclului de via. Importana calitii produselor software rezid n cel puin trei aspecte: erorile din programele de aplicaie pot fi fatale n anumite domenii unde vieile oamenilor depind de acestea; aceste erori pot provoca pierderi financiare, materiale i tot felul de alte tipuri de insatisfacii sau pierderi; dac n domeniul produselor hardware costurile au o tendin general de scdere, n domeniul dezvoltrii de software, dei productivitatea a crescut substanial, nu se nregistreaz i o scdere a costurilor care s duc la aceeai tendin. Acest ultim aspect se datoreaz particularitilor prin care calitatea se manifest n domeniul produselor software, aa cum sunt ele relevate n [BAR01]: - comportamentul instruciunilor nu se deterioreaz n timp; - erorile sunt provocate de folosirea sau combinarea incorect a componentelor elementare, i nu de aceste componente n sine; - interaciunile dintre componentele unui program sunt, mai complexe, mai ales dac acestea ruleaz n cadrul unor aplicaii complexe; - erorile exist deja n program, ele sunt eliminate cu timpul, prin depanare, deci programul se mbuntete prin trecerea timpului; - eliminarea unei erori nu d sigurana c a diminuat numrul total de erori cu o unitate; - non-calitatea programelor poate fi atribuit n ntregime greelilor umane, de proiectare, concepie, programare, documentare. Un manager preocupat de calitatea produselor software trebuie s posede, conform [WEI2], anumite abiliti speciale i chiar caliti native, cum ar fi: s observe ce se ntmpl i s neleag

10

semnificaia propriilor observaii; s se poat comporta i s poat aciona congruent n situaii interpersonale dificile, chiar i cnd este derutat, suprat sau speriat; s poat nelege situaiile complexe. Aceast ultim abilitate permite s se poat planifica un proiect i apoi s se observe i s se acioneze astfel nct proiectul s decurg conform planului sau s poat fi modificat conform cerinelor i schimbrilor aprute pe parcurs. Calitatea produselor software este definit n [BAR03] ca msura n care acestea satisfac cerinele utilizatorilor prin caracteristici tehnice, economice i psiho-sociale. Aceast definiie se bazeaz pe dou concepte care, puse n legtur, dau msura calitii unui produs software, i anume cerinele utilizatorilor i caracteristicile produsului. O importan deosebit n procesul de dezvoltare software o are dependena dintre specificul i calitatea procesului generator, calitatea proiectului i calitatea produsului. Ca urmare, putem deosebi de la nceput doi factori eseniali pentru calitatea produsului software, i anume modelul specificat (proiectul) i conformana fa de proiect (fidelitatea reproducerii). Definirea problemei la beneficiar i clarificarea i detalierea acesteia de ctre beneficiar i productor prin elaborarea unor specificaii, are un impact deosebit att asupra calitii proiectului i, ulterior, a produsului, dar i asupra ntregului ciclu de via al produsului software.

1.3. Managementul calitii - component a managementului firmei

Calitatea a devenit o problem major pentru managementul actual al firmei. In unele lucrri de specialitate privitoare la teoria i practica managementului se pune chiar problema existenei, pe lng funciunile tradiionale ale firmei, i a "funciunii de calitate". Ca urmare, managementul de vrf al firmelor, trebuie s se preocupe de elaborarea strategiilor i politicilor firmei n domeniul calitii. Integrate n strategia i politica general a firmei, strategiile i politicile de calitate asigur exprimarea orientrilor privind mrimea performanelor viitoare ale firmei, posibilitile de asigurare a unui management concurenial i determinarea procedurilor de comportament pe diferite piee i fa de diferite produse. Conform [NICI], abordarea calitii prezint, n cadrul firmei, dou aspecte: asigurarea calitii i gestiunea calitii. Asigurarea calitii reprezint un ansamblu de mijloace, prestabilite i sistematizate, ntreprinse de firm, n toate compartimentele implicate n activiti ce pot influena calitatea produselor i serviciilor executate, astfel nct s exprime certitudinea realizrii cerinelor de calitate specificate.

11

Obiectivele gestiunii calitii constau n identificarea, analiza i interpretarea tuturor anomaliilor aprute n timpul desfurrii produciei, precum i n definirea aciunilor corective sau de orientare a calitii n toate etapele de realizare a produsului i/sau de prestare a serviciului, inclusiv prin prisma costurilor calitii. Unul din obiectivele fundamentale ale managementului calitii l constituie construirea, manevrarea i mbuntirea unui sistem al calitii n cadrul organizaiei. Reciproc, managementul calitii nu poate avea coeren n organizaii unde nu exist definit un sistem manevrabil al calitii, proceduri pentru meninerea, actualizarea i mbuntirea acestuia. Astfel, avnd n vedere modelul Maturitate/Capabilitate - CMM/SEI, [PFL1], elaborat n S.U.A. la Software Engineering Institute, se apreciaz c, dei gestiunea calitii poate apare la o organizaie productoare de software situat la nivelul doi de maturitate - procesele sunt repetabile - totui aceasta nu poate fi efectiv dect la organizaii aflate cel puin la nivelul trei de maturitate, unde procesele sunt definite i instituionalizate. Acest nivel de maturitate presupune c produsele intermediare ale etapelor dezvoltrii, precum i etapele n sine, sunt bine definite i "vizibile", permind msurarea caracteristicilor produselor i proceselor intermediare. Pentru exercitarea unui management al calitii eficient, sistemul calitii existent n organizaie trebuie s asigure realizarea premiselor pentru un suport corect al activitii decizionale (Tabelul 1.1.). Tabelul 1.1.

Premise pentru definirea aciunilor corective, de orientare a calitii n toate etapele de realizare, a produsului software
existena unei baze de date referitoare la proiecte anterioare, actualizat cu datele proiectului curent, inclusiv n ceea ce privete costurile; actualizarea continu, pe baza unor contacte permanente cu managementul de nivel nalt i cu compartimentele de marketing, a direciilor de aciune viabile de urmat n ceea ce privete calitatea produsului, precum i a tendinelor aprute pe pia; analiza i sistematizarea neconformitilor aprute, a momentelor, proceselor i cauzelor apariiei 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 defeciune, aprute 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 schimbrii de tip "what if ?"; punerea de acord, din punct de vedere practic, a tendinelor generale ale pieei produsului, a tendinelor generale n ceea ce privete calitatea, cu posibilitile concrete de care dispune organizaia (firma) productoare, de a produce o anumit calitate;

12

propuneri de actualizare, pe baza rezultatelor concrete obinute, a strategiei i politicii firmei cu privire la calitate. Lucrarea de fa apare n cadrul programului de perfecionare a nvmntului superior de informatic economic, ce include "coala doctoral de managementul calitii software", sub egida Consiliului Naional al Cercetrii tiinifice Universitare, pe baza contractului 39687-146/1998.

1.4. Managementul calitii TI n organizaiile specializate n TI

n trecut accentul se punea pe satisfacerea beneficiarului (clientului) intern al organizaiei: SIE de gestiune, aplicatii informatice etc. Odat ce TI poate fi utilizat pentru sporirea valorii la produse i servicii, n rezultatul implantrii TI n produse i servicii, consumatorul final devine utilizator al sistemelor organizaiei, adic client extern al SI (fgura 1.4, 1,5, 1.6) Alt categorie de utilizatori externi este reprezentat de partenerii comerciali, care folosesc sisteme interorganizaionale (cum ar fi partenerii de schimb reciproc de date EDI). Aceasta poate fi folosit pentru a evidenia sursele de informaii interne i externe fa de firm pentru a determina calitatea informaiilor i serviciilor informaionale pentru asigurarea funcionrii eficiente a sistemului TQM n SI i TI. Odat ce calitatea produselor i serviciilor prestate de USE, este condiionat de calitatea TI, SI, percepia consumatorilor externi referitor la calitatea produselor USE, poate fi utilizat ca surs indirect de informaii despre calitatea TI i SI.

13

Firma
Managementul general
Sisteme informatice manageriale, Tehnologii informaionale n managementul general

Utilizatori externi ai SI,TI Parteneri n schimb de date

Managemen tul calitii produselor i serviciilor

Manageme ntul calitii SI (TI)

Sistemul informatic al TQM

Procesul de producere (produse) i prestare servicii

Consumatorii de produse i servicii

Fig.1.5. Legturile reciproce dintre diferite forme de management: general, managementul calitii proceselor i serviciilor, managementul calitii SI i TI firmei

Firma
Utilizatori interni ai SI,TI

Managerii

Speciali tii

Sisteme informatice , Tehnologii informa ionale

Utilizatori externi ai SI,TI

Parteneri n schimb de date

Procesul de producere i prestare servicii

Consumatorii de produse i servicii

Fig.1.4. Utilizatorii direc i i indirec i ai SI i TI ale firmei

14

2. Abordarea managerial orientat pe produs

2.1. Sistemul caracteristicilor de calitate ale produselor software
Dup cum se arat i n definiia dat calitii (standardul ISO 8402, [ISO3]), aceasta este prezent n fapt printr-un set de caracteristici. Aceste caracteristici pot fi mprite n: a) caracteristici economice, exprimate prin costuri (de proiectare, elaborare, implementare, utilizare), economii (de resurse materiale, umane, financiare), creteri de randament i productivitate, privite n legtur cu costurile i economiile care i analizate mpreun n vederea stabilirii oportunitii realizrii produsului; b) caracteristici sociale i psiho-senzoriale, constau n potenarea elementelor Asupra acestor creatoare, eliminarea rutinei i stereotipiei, instruirea asistat a operatorilor.

caracteristici s-au fcut studii comparative. S-a constatat, de pild, c rutina i nemulumirea utilizatorilor datorate lucrului, timp ndelungat, cu anumite produse, este mult mai mic n cazul utilizrii interfeelor utilizator grafice (Microsoft Windows, X-Windows, Macintosh), dect n cazul utilizrii unor interfee n mod text; c) caracteristici tehnice i de utilizare (de utilitate general) . Aceste caracteristici sunt tratate "in extenso" n literatura de specialitate, iar organizaia internaional 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 relaii de interdependen, subordonare, ierarhizare, decompoziie sau agregare. Complexitatea acestor relaii determin ca ansamblul caracteristicilor de calitate s alctuiasc un sistem. Pentru ca acest sistem de caracteristici de calitate s poat fi operaional, n sensul ca s se poat selecta un set de caracteristici pe baza cruia s se construiasc un sistem de metrici cu care calitatea unuia sau mai multor produse software s fie evaluat, setul selectat trebuie s aib urmtoarele proprieti: - s fie apreciat complet de ctre evaluatori, n sensul de a putea surprinde toate aspectele calitii n care evaluatorii sunt interesai (prin evaluatori se neleg persoanele autorizate i n cunotin de cauz, interesate n evaluarea calitativ a produsului, a organizaiei productoare sau a sistemului calitii, respectiv productori, beneficiari, auditori); - s fie ierarhizabii, n sensul ca principalele caracteristici s poat fi descompuse n factori ce pot cuantificai 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 contradicie cu fiabilitatea, portabilitatea cu eficiena, etc. Ca urmare,

15

pentru elaborarea unor specificaii pe baza unui set de caracteristici de calitate ce presupun aspecte contradictorii, fie se pot stabili anumite nivele pentru anumite caracteristici, celelalte pstrndu-se n limite acceptabile sau lsndu-se la dispoziia priceperii proiectanilor i programatorilor, fie se stabilete un sistem de prioriti specificate explicit. De exemplu, n cadrul unui produs software, anumite programe/module trebuie s se execute mai rapid, iar altele s fie prevzute cu proceduri suplimentare de verificare i testare a corectitudinii datelor, chiar dac aceasta duce la ncetinirea duratei de execuie. La nivel general, sistemul trebuie s se bazeze, conform [BR1], pe urmtoarele considerente elementare: 1. conexiunea elementelor interne ale sistemului s fie mai puternic dect legturile sistemului cu mediul. Aceasta se realizeaz prin selectarea pe anumite criterii (specificaiile beneficiarilor, urmrirea de ctre productor 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 cuprinztor. n toate situaiile, sistemul caracteristicilor de calitate ce urmeaz a fi construit este doar un subsistem al calitii software; 3. unitatea i complexitatea unui sistem presupune o anumit ordine n aezarea i funcionarea 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 urmrirea diferitelor structuri componente; 5. orice subsistem poate avea o multitudine de bucle de reacie care se nchid pe anumite poriuni de proces, pe anumite poriuni de sistem sau chiar la nivelul ntregului sistem. Acest lucru se traduce la nivelul sistemului caracteristicilor de calitate prin interdependenele i contradiciile existente ntre caracteristici. Cea mai dificil problem a sistemului calitii software cercetarea mecanismului specific al interaciunii sistemului, problem posibil de soluionat doar prin managamentul calitii. Obinerea unui sistem operaional de caracteristici - modelul calitii - pe baza cruia s se poat realiza managementul i gestiunea calitii, presupune parcurgerea unor etape anterioare obligatorii, astfel: a) definirea problemei - n care se stabilesc caracteristicile i factorii de calitate ce vor fi luai n considerare; b) construirea modelului calitii - analiza i modelarea relaiilor dintre componente, a modului de interaciune, a interdependenelor, precum i alegerea unui criteriu de performan. Aceast alegere este parial determinat de felul n care este precizat problema; este dintre diferitele caracteristici de calitate ale

16

c) stabilirea soluiei d)

o soluie este obinut cnd se apreciaz c rspunsul obinut la un

moment dat este cel mai bun n comparaie cu criteriile stabilite; omologarea soluiei - omologarea soluiei obinute pe baza modelului - rezultat al procesului de optimizare. Se poate face prin: A. compararea cu performanele precendete sau ale altor produse concurente pe pia superioritatea noii soluii poate fi considerat ca o verificare a valabilitii ei. Inconvenientul acestei metode const n aceea c n evaluarea calitii oricrui produs pe o perioad trecut toate intrrile sunt cunoscute i elemente importante ale lurii deciziei (variaiile probabilistice ale pieei, obinuinele utilizatorilor, etc.) sunt astfel eliminate. B. compararea cu performanele viitoare - const n compararea soluiilor 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 alctuirea seturilor respective de date, elaborarea sau luarea n calcul a unor variante diferite ale produsului, obinerea i analiza rezultatelor sumare comparative. n plus, orict de exhaustiv ar fi elaborate seturile de date de test, n cazul produselor complexe, acestea nu pot fi atotcuprinztoare, neputndu-se trage concluzii privind alte seturi de date de intrare. C. comparaia prin simulare - experimentrile repetate satisfac caracteristicile unor ncercri n condiiile unor date de intrare externe diferite i alese la ntmplare. Dar, aa cum se arat n [BR1], i aceast metod genereaz probleme specifice care pot reduce contribuia sa la rezolvarea problemei.

2.2. Definirea caracteristicilor de calitate

n literatura de specialitate, att din ar ct i strin, se gsesc numeroase definiri i ierarhizri ale caracteristicilor de calitate [ISO1], [STU1], [B0E1], [TAT1], [THA1], [BARO1], [BARO2], [BARO3], [MCC1]. Unii autori folosesc doar termenul de caracteristici de calitate, alii le grupeaz n caracteristici i atribute, caracteristici i factori sau caracteristici i subcaracteristici. Se vor trata n continuare cteva caracteristici de calitate, pe baza definirilor fcute n [ISO1], [BAR01] i [BAR03]. Funcionalitatea este definit n standardul ISO/IEC 9126, [ISO1], ca un set de atribute bazate pe existena unui set de funcii i pe proprietile lor specificate. Funciile satisfac necesitile stabilite sau implicate. Acest set de atribute ce definete funcionalitatea, arat "ce face" produsul software pentru a ndeplini cerinele, pe cnd alte seturi rspund la ntrebrile "cnd" i "cum" corespunde nevoilor produsul respectiv. Referirea la nevoile stabilite sau implicate se face pe baza definiiei calitii din standardul ISO 8402 [ISO3]: "totalitatea trsturilor i caracteristicilor unui produs sau serviciu care se bazeaz pe abilitatea sa de a satisface nevoile stabilite sau

17

implicate". ntr-un context contractual nevoile sunt stabilite, specificate, pe cnd n alt context nevoile implicate trebuie identificate i definite., Fiabilitatea este privit n [BARO1] ca msura ncrederii pe care o avem n concepia i n capacitatea unui program de a funciona corect n toate condiiile avute n vedere de la nceput. Aceast definiie se refer mai mult la fiabilitatea procesului dect la cea a programului, fiind legat de probabilitatea ca o eroare din program s fie activat de un set specific de intrri. Fiabilitatea produselor software este caracteristica ce exprim poate cel mai bine particularitile acestei industrii, dac abordm problema n comparaie cu fiabilitatea produselor hardware. Exist abordri cantitative ale fiabilitii, exprimate prin probabilitatea ca un produs software s-i ndeplineasc funciunile cu anumite performane i fr erori ntr-un interval de timp i n condiii de exploatare date, precum i abordri calitative ce privesc fiabilitatea ca o capacitate a produsului software. Standardul ISO/IEC 9126 [ISO1], definete fiabilitatea ca un set de atribute care se bazeaz pe capabilitatea produsului software de a-i menine nivelul de performan n condiii i pe o perioad de timp stabilite. Limitele fiabilitii unui produs software se datoreaz erorilor din etapele de formulare a cerinelor, proiectare i implementare. Cderile datorate acestor erori depind de modul i condiiile n care este utilizat produsul. Corespunztor ciclului de via al produsului software, putem distinge o fiabilitate previzional sau proiectat, o fiabilitate experimental i o fiabilitate operaional (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 utilizrii produsului, de ctre un grup stabilit sau implicat de utilizatori. Standardul d termenului de utilizatori un neles foarte larg, incluznd operatori, utilizatori finali i indireci, precum i toate categoriile de persoane care i desfoar activitatea dependent sau sub influena utilizrii produsului software respectiv. Eficiena produselor software este definit n [BAR03] ca o corelaie optim ntre consumul de resurse al produsului i complexitatea problemei de rezolvat. Tot n acest material se arat c eficiena poate fi exprimat prin introducerea noiunii de output al produsului software, definit ca o relaie ntre complexitatea datelor iniiale i a rezultatelor finale. Standardul ISO/IEC 9126 [ISO1], definete eficiena tot ca pe o corelaie, dar nu ntre consumul de resurse i complexitatea problemei, ci ca un set de atribute bazate pe relaia dintre nivelul de performan al produsului software i cantitatea de resurse utilizate, n anumite condiii stabilite. Spre deosebire de [BAR01], standardul [ISO1] lrgete mult categoria resurse consumate, incluznd att memoria, timpul de execuie, precizia ct i cantitatea de hrtie 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 modificrile specificate n produsul software respectiv. Modificrile includ corecii,

18

mbuntiri sau adaptri la modificri ale platformelor (de dezvoltare, int, etc), modificri n cerine i specificaii funcionale. Conform [BAR03], un produs software este mentenabil n msura n care permite o rapid i uoar actualizare astfel nct s poat fi utilizat n continuare n bune condiii. Actualizrile din aceast definiie sunt privite n sens mult mai restrns. Ele referindu-se numai la operaii la nivelul produsului software, al modulelor, secvenelor de instruciuni i instruciunilor. Nivelul mentenabilitii se poate stabili pe baza datelor obinute n etapele de proiectare, testare i utilizare curent. Evaluarea acestei caracteristici se bazeaz pe datele obinute indirect prin examinarea influenei modificrilor asupra celorlalte caracteristici de calitate, cum ar fi complexitatea, testabilitatea, modularitatea, etc. Un factor care determin obinerea unei mentenabiliti corespunztoare este corelarea strict a nivelului de complexitate cu funcia 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 direcia transferrii dintr-un mediu n altul. nelegnd prin mediu nu numai contextul hardware i/sau software, ci i cadrul organizaional, standardul ISO/IEC 9126 [ISO1] - extinde considerabil limitele cerinelor impuse portabilitatii. Restrngnd mult limitele, n [BARO3] portabilitatea se definete 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, fr alte modificri ci i dac execuia pe alte tipuri de sisteme de calcul necesit modificri de mic anvergur i un efort de programare mult mai mic dect cel cerut de rescrierea acestor programe. Un aspect deosebit al acestei caracteristici este legat de portabilitatea compilatoarelor, de diferitele faciliti video i audio oferite de sistemele de calcul i folosite n programele de aplicaie. Abordarea diferit a acestei caracteristici de calitate, la sfritul anilor '90, este relevat i de preocuprile pentru crearea de sisteme ieftine, care pot deveni staii de lucru n mai multe tipuri de reele, rulnd programe dezvoltate pe platforme int diferite - UNIX, Windows, DOS, VMS - avnd n spate puterea reelei globale - Internet. Interoperabilitatea considerat de mai muli autori un atribut al calitii, reprezint, conform [BARO3], capacitatea produsului software de cuplare cu alte produse. Acest atribut permite reutilizarea unor programe pentru construirea unor aplicaii complexe. Cuplarea se poate asigura direct sau folosind interfee. Problema interfeelor i a bibliotecilor de funcii prin care pot fi cuplate aplicaii, a stat la baza dezvoltrii unor concepte, programe i specificaii deosebit de complexe. Exemple elocvente sunt specificaiile Open Database Connectivity, utilizate n aplicaiile de baze de date, API-urile dezvoltate de Microsoft odat cu sistemul Windows sau Object Linking and Embedding - ncapsularea i nlniurea obiectelor - set construit folosind tehnica obiectelor, prin care obiecte construite de unele aplicaii sunt accesibile i altor aplicaii.

19

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 corelaie 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 execuiei. Din prima categorie de abordri fac parte sistemele de metrici Halstead i combinaii 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 msurarea complexitii, obinute prin combinarea celor dou categorii amintite, utiliznd metoda statistic a analizei factorilor. Elaborarea unor modele pertinente pentru studierea i predicia complexitii produselor software este important pentru programarea resurselor umane, materiale, financiare i de timp, necesare proiectrii i implementrii programelor de complexiti diferite. De asemenea, complexitatea influeneaz i cheltuielile ulterioare punerii n funciune a produsului (post-vnzare, service, asisten tehnic), precum i eforturile de a dezvolta noi versiuni sau de a rescrie produsul i pe/pentru alte platforme.

2.3. Modele ale sistemelor caracteristicilor de calitate software

Modelele cunoscute, ce apar n literatura de specialitate, valorific experiena ctigat n elaborarea unor proiecte, i, plecndu-se de la anumite necesiti practice ale aplicaiilor i de la un set iniial de caracteristici, prin rafinare, ordonare i diminuarea redundanelor, se ajunge la construirea unei arborescente a caracteristicilor. Arborele respectiv are cel puin dou nivele, deosebindu-se o structur de nivel nalt care nglobeaz caracteristici generale agregate i o structur de nivel sczut (elementar), care cuprinde caracteristicile "primitive" (subcaracteristici, factori). Se pornete de la ideea simplificatoare c toate caracteristicile de nivel nalt se obin prin agregarea caracteristicilor primitive. Descompunerea caracteristicilor generale n caracteristici de nivel inferior (pentru care se mai folosesc i ali termeni: factori, primitive, etc), este necesar deoarece astfel se pot urmri/cuantifica n procesul de elaborare, respectivele caracteristici de calitate. Caracteristicile de pe nivelele superioare se constituie n modelul calitii, prin care se reflect scopurile urmrite n construirea calitii produsului software i la evaluarea general a acestuia, iar cele de pe nivelurile inferioare asigur fundamentarea controlului msurii n care produsul posed caracteristicile de calitate respective i punctul de plecare n elaborarea, adoptarea sau adecvarea sistemelor de metrici.

20

Pentru identificarea legturilor se construiesc diagrame n care, prin arcele incidente, este reprezentat relaia "dependent de", iar prin arcele descendente relaia "determin pe". De exemplu, pentru fiabilitate, se pot reprezenta relaiile din figura 2.1. de mai jos.

21
Independen hardware Portabilitate Completitudine

Utilitate

Fiabilitate

Acuratee Consisten

Utilitate general

Eficien

Eficien hardware Accesibilitate Comunicativ

Factori umani

Mentenabilitate

Testabilitate

Structuralitate Autodescriere

Uor de neles

Conciziune Claritate Extensibilitate

Modificabilitate

Figura 2.1. Model al sistemului de caracteristici ale calitii

Maturitate

Maturitate Acuratee Fiabilitate Tolerana la erori Consisten

Utilitate Complexitate Corectitudine Stabilitate Integritate

22

n exemplul de mai sus, s-au luat n considerare un numr destul de mare de caracteristici de calitate care vin n relaie cu fiabilitatea i, cu toate acestea, mai puteau fi gsite i altele, cum ar fi recuperabilitatea sau structuralitatea. Acest gen de abordare conduce ns la un model inaplicabil. De fapt, graful se construiete din setul iniial, limitat, de caracteristici - alese n funcie de specificul problemei, al prelucrrii i al specificaiilor beneficiarilor - i pe baza relaiilor de preceden i de descenden, apoi se rafineaz succesiv pn 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 strintate i n ar, i anume modelul Boehm (Anexa IA), modelul McCall (Anexa 1B), un model romnesc elaborat la I.C.I. Bucureti (Anexa IC) i modelul ISO/IEC statuat de standardul ISO 9126 (Anexa 1D), avnd unii parametrii prezentai n tabelul de mai jos (tabelul 2.1). Tabelul 2.1. Modelul Boehm Numr de caracteristici de nivel nalt Numr de caracteristici de nivel sczut Numr total de caracterisitici Numr de nivele n arbore Caracteristicile de nivel sczut determin mai mult de o caracteristic de nivel nalt ? 10 12 22 4 Da Modelul McCall 11 22 33 2 Da Modelul I.C.I. 6 19 25 2 Nu Modelul ISO 9126 6 21 27 2 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 att portabilitatea ct i fiabilitatea iar n cazul modelului McCall consistena determin corectitudinea, fiabilitatea i mentenabilitatea. In aceste cazuri, decompoziia caracteristicilor de nivel superior n caracteristici primitive, determin deplasarea interdependenelor i redundanelor dintre caracteristicile structurii de nivel nalt ctre structura de nivel inferior. Modelul McCall expliciteaz relaiile 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, dei nu se poate spune c nu exist interdependene "ncruciate" 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.

23

2.4 Caracteristici de calitate particularizate pentru clase de aplicaii software specifice

Avnd n vedere varietatea claselor de aplicaii software, fiecare cu un anumit specific i particulariti, subsistemul caracteristicilor de calitate poate fi mprit n caracteristici de tip general i caracteristici particulare (de exemplu, sincronizarea, pentru produsele software de acces la distan, sau integrarea, pentru sistemele de operare n reele). La rndul lor, caracteristicile de tip general, dei i pstreaz coninutul noional, capt puternice accente de particularitate, n funcie de particularitatea fiecrei clase de aplicaii. De exemplu, fiabilitatea sistemelor de operare difer, ca modalitate de abordare, de fiabilitatea aplicaiilor de baze de date distribuite, sau fiabilitatea unei aplicaii ce ruleaz pe INTERNET fa de fiabilitatea unei aplicaii utilizate ntr-o reea local. Selecia caracteristicilor particulare ale unei anumite clase de produse software, este de o importan deosebit, deoarece asupra acestor caracteristici care i confer "personalitate" clasei respective, se concentreaz de obicei atenia cumprtorului/beneficiarului, politica de marketing a concurenei, precum i gestiunea calitii. Se vor trece n revist pe scurt asemenea tipuri de caracteristici sau particularizri ale caracteristicilor generale, pentru trei clase de produse software. A. Caracteristici de calitate pentru sistemele de operare n reele Sistemele de operare sunt aplicaii software specifice, care exploateaz hardware-ul pentru care au fost scrise. Anii '90 au dus, pe plan mondial, la apariia unei mari varieti de soluii pentru informatizarea activitii, la diferite nivele: ntreprindere, corporaie, organizaii guvernamentale i neguvernamentale, etc. Soluia cea mai rspndit este deocamdat reeaua de calculatoare. Constituit din calculatoare mari (main frame), minicalculatoare, calculatoare personale, omogene sau de diferite tipuri, pe care ruleaz sisteme de operare i protocoale din ce n ce mai performante, cuplul reea-sistem de operare, determin hotrtor modalitatea de comunicaie, tipurile de aplicaii, securitatea i, n final productivitatea organizaiei respective. n ceea ce privete reelele de calculatoare personale, o concuren acerb se deruleaz pe piaa serverelor departamentale, i, legat strns de aceasta, pe piaa sistemelor de operare (Novell Netware, UNIX, Windows NT, IBM OS/2, SCO Unix, Banyan Vines). n continuare se vor aborda caracteristici de calitate particulare, care dau msura calitii unor astfel de produse software, sunt utilizate n evaluri i aprecieri, att n literatura de specialitate ct i de corporaiile care doresc s investeasc n informatizarea activitii, i, nu n ultimul rnd, sunt utilizate direct n activitatea de gestiune a calitii acestor produse. n [HALI] sunt prezentate comparativ sistemele de operare UNIX i Windows NT. Ca i caracteristicile de mare generalitate, prinse n modelele clasice de evaluare (Boehm, McCall, ISO

24

9126, etc.) i aceste caracteristici se descompun n subcaracteristici sau factori, msurabili direct sau prin intermediul metricilor, listelor de valori, chestionarelor. a) Integrarea este caracteristica de calitate a sistemelor de operare ce d msura n care acestea pot fi instalate i configurate cu uurin pe arhitecturile hardware ale reelelor, precum i conectivitatea i conlucrarea sistemului de operare cu un alt hardware sau software. Aceast caracteristic este mai complex dect instalabilitatea, deoarece include i aspecte privind unele faciliti strict necesare unui astfel de tip de produs software (interoperabilitate, suport pentru comunicaii sau alt tip de software sau hardware, diferite tipuri de interfee). Factorii n care poate fi descompus integrarea sunt prezentai n tabelul 2.2. Tabelul 2.2 INTEGRARE - Dispune de instalare standard pentru aplicaii (n reea i n local) - Detectare automat a configuraiei hardware - Protocoale multiple de reea - Partajare fiiere Windows SMB - Partajare fiiere Macintosh - Partajare fiiere NFS - Suportul pentru drivere - Suport pentru tehnologii de integrare a aplicaiilor (RAD - Rapid Application. Development, sau Neo - Network Objects, utiliznd obiecte CORBA sau OLE, applet-uri Java, etc). b) Securitatea este caracteristica de calitate a sistemelor de operare care reglementeaz drepturile de acces ale utilizatorilor n reea, drepturile de acces la aplicaii i date, precum i administrarea sigur i uoar a acestora, de la consol sau de la distan. Avnd n vedere c, de regul, astfel de reelele de calculatoare funcioneaz n diferite tipuri de organizaii, avnd utilizatorii (angajaii), departajai n diferite grupuri de lucru, cu diferite nevoi de comunicaii i diferite poziii n organizaie (ceea ce le confer drepturi diferite de a dispune de datele aflate pe reea i de resursele reelei), securitatea sistemelor de operare devine o caracteristic deosebit de important. Pentru astfel de sisteme, s-au dezvoltat standarde de securitate, iar firmele productoare de sisteme de operare, i refer aceast caracteristic la aceste standarde. De exemplu firmele NOVELL i Microsoft afirm c sistemele lor de operare Netware 4.X i respectiv Windows NT fac parte din clasa de securitate C2, iar sistemul de operare MVS pentru main-frame-urile IBM ES9000, se afirm c face parte din clasa de securitate B1. Factorii n care poate fi descompus securitatea sunt prezentai n tabelul 2.3.

25

Tabelul 2.3. SECURIT A TE - Necesitatea logrii utilizatorului - Permisiuni de acces la nivel de fiier - Liste de control al accesului pe fiiere - Contabilizarea securitii - Acces bazat pe rol - Interfa simpl de administrare a securitii (inclusiv la distan) c) Uurina de utilizare este caracteristica de calitate a sistemelor de operare n reele care permite exploatarea i administrarea din punct de vedere hardware (adugarea de calculatoare sau elemente de conectic) i software (organizare i administrare volume, utilizatori, cozi de listare, etc) n mod facil, sigur i rapid, a unei reele de calculatoare. Factorii n care poate fi descompus uurina de utilizare sunt prezentai n tabelul 2.4. Tabelul 2.4. UURINA DE UTILIZARE - Utilitare de management al reelei (n mod text sau grafic) - Administrarea la distan i diagnosticarea - Managementul grafic al volumelor - DHCP (permite adugarea unui nou calculator ntr-un LAN la fel de uoar ca i conectarea unui cablu) d) Scalabilitaea este caracteristica de calitate a sistemelor de operare n reea care se refer la capacitatea acestora de a rula pe mai multe configuraii hardware, de a oferi suport pentru o gam ct mai larg de tipuri de aplicaii. Alturi de securitate i fiabilitate, scalabilitatea este caracteristica de calitate pentru care, pe piaa acestor produse software, se d o btlie aprig. De exemplu, pentru a nu pierde piaa produselor DOS i Windows, care necesit procesoare Intel, muli productori de sisteme UNIX, emuleaz software procesoarele Intel. De asemenea, odat cu apariia servererelor multiprocesor, noile versiuni de sisteme de operare UNIX, Netware, Windows NT, ofer posibilitatea adugrii mai multor procesoare de acelai tip sau nlocuirea procesorului cu unul mai rapid. Din punctul de vedere al acestui factor al scalabilitii, se pare c sistemele UNIX sunt cele mai puternice. Astfel UNIX Solaris, produs de firma Sunsoft permite o scalabilitate liniar de pn la 64 de procesoare, cu baze de date mai mari de 5 teraoctei, i conectarea simultan a mii de utilizatori, pe cnd

26

Windows NT (principalul concurent) ofer suport pentru pn la 32 de procesoare. Scalabilitatea se poate descompune conform tabelului 2.5. Tabelul 2.5 SCALABILITATE - Suport multiplatform - Suport multiprocesor - Variant doar client - Suport pentru aplicaii MS DOS - Suport pentru aplicaii Windows pe 16 bii - Suport pentru aplicaii Windows pe 32 de bii - Suport pentru aplicaii Posix - Suport pentru aplicaii X Windows e) Fiabilitatea este caracteristica de calitate a sistemelor de operare n reea care vizeaz capacitatea acestor aplicaii de a gestiona, partaja i administra fr erori resursele unei reele de sisteme de calcul (calculatoare, imprimante, aplicaii). Msura fiabilitii sistemelor de operare difer chiar n cazul aceluiai sistem, n funcie de tipul de aplicaii ce se ruleaz (aplicaii de baze de date, aplicaii grafice n reea, comunicaii, ATM, case de marcat, etc). n analiza fiabilitii sistemelor de operare n reea se iau n calcul facilitile constructive oferite de acestea, n vederea reducerii cderilor sau erorilor, aa cum se prezint n tabelul 2.6. Tabelul 2.6 FIABILITATEA - Protejarea memoriei per proces - Sistem de fiiere recuperabil - Diagnostic la distan - Managementul volumului de date - Disk mirroring i striping - Toleran la erori B. Caracteristici de calitate pentru software de acces la distana Creterea, n ultimii ani, a interconectivitii sistemelor de calcul (prin procesul de globalizare a reelelor de calculatoare i comunicaii), determinat de globalizarea sistemelor informaionale, a dus la apariia unor aplicaii informatice specializate n asigurarea accesului la distan, att pentru calculatoare personale desktop ct i pentru calculatoare mobile. Tot mai multe sisteme de operare

27

includ faciliti de comunicaie (Windows, unele variante de UNIX), dar, aceste faciliti sunt mai puin performante fa de cele oferite de programele specializate de acces la distan (LapLink, al firmei Traveling Software, Norton pcAnywhere al firmei Symantec, Remotely Possible/32 al firmei Avalan Technologies, NetRemote al firmei McAfee, Carbon Copy al firmei Microcom, ReachOut al firmei Stac Electronics, CoSession al firmei Artisoft, etc). n [BAR1] sunt prezentate comparativ aceste produse program, cu focalizare asupra celor scrise pentru maini Intel x86, pe 32 de bii. Caracteristicile de calitate care confer specificitate acestor produse software, i care sunt luate n considerare de utilizatori la achiziionarea lor ct i de firmele productoare n procesul de optimizare a performanelor i calitii acestora, sunt sincronizarea, securitatea i programabilitatea. a) Sincronizarea este caracteristica de calitate a programelor de acces la distan care const n capacitatea de a transfera, actualiza i revizui automat date ntre sisteme de calcul. Unele produse (de exemplu Briefcase), n cazul n care are loc modificarea parial a fiierelor, copiaz ntreg fiierul. Sincronizarea inteligent inclus n produsele menionate, permite sincronizarea numai a prii care s-a modificat. Aceasta determin creterea vitezei de transfer i scderea traficului. Tabelul 2.7. CARACTERISTICA FACTORI (faciliti) Copiere rapid de fiiere Mapare dispozitive Funcie chat SINCRONIZARE Remote clipboard copy/print Callback automatic Cache Emulare terminal Suport protocol reea Necesit parol SECURITATE Limiteaz activitile Blank screen Criptare date Cutare virui

28

Limbaj de scripting Macrokeys PROGRAMABILITATE Definire macrouri Apeluri programate b) Securitatea este caracteristica de calitate a programelor de acces la distan care le confer facilitatea de a oferi o cale sigur ctre reeaua de baz. Prin aceste tipuri de produse software este posibil utilizarea parolelor i restricionarea accesului utilizatorilor la oricte activiti este considerat necesar. Alte faciliti pe care trebuie s le ofere produsele software pentru acces la distan, pentru a poseda caracteristica de securitate, sunt: ntreruperea, la cererea utilizatorului, a afirii imaginii pe ecranul display-ului n timpul unei sesiuni la distan; controlul numrului de tentative de login; limitarea timpului alocat sesiunilor de lucru; opiuni de criptare a datelor n timpul sesiunilor de transfer de fiiere. c) Programabilitatea este caracteristica de calitate a programelor de acces la distan, care confer posibilitatea utilizatorilor de a automatiza task-uri i proceduri de login, construirea de macrouri sau utilizarea unor comenzi de programare. Unii subfactori de calitate, pentru caracteristicile particulare de mai sus, sunt prezentate n tabelul 2.4.6. C. Caracteristici de calitate pentru servere Se vor face referiri numai la o anumit clas de servere (produse software), i anume la serverele de INTERNET (WEB) specializate n accesarea bazelor de date. Organizaiile cu mari baze de date, care resimt nevoia de a oferi aceste informaii unei audiene mult mai largi, pe WEB, au la dispoziie un nou tip de aplicaii de baze de date care permit oricui are o conexiune la ; INTERNET i un navigator WEB s vizualizeze i s insereze nregistrri, \ s interogheze sau s genereze rapoarte. Aceste aplicaii ofer faciliti \ pentru interogarea bazelor de date i ncorporarea rezultatelor n pagini WEB, precum i faciliti pentru actualizarea bazelor de date pe baza intrrilor utilizator. n [HET1] se prezint comparativ caracteristicile de calitate ale unor asemenea aplicaii, i anume Microsoft Internet Information Server 1.0, Oracle WebServer 2.0, WebSite Professional 1.0 (O'Reilly & Associates Inc.) i Live Wire Professional 1.0 (Netscape Communications Corp.). Sistemele de gestiune a bazelor de date utilizate de server-ele menionate mai sus sunt Microsoft SQL Server i Oracle 7 Server. n cadrul server-erelor menionate, diferenele semnificative sunt determinate de componentele software utilizate pentru accesul la bazele de date. Astfel, putem deosebi dou modaliti principale de conectare:

29

a.

utilizarea specificaiilor Open Database Connectivity (ODBC) crora li se paseaz

informaiile de conectare fie prin dou fiiere (la Microsoft Information Server exist Internet Database Connector-IDC, care utilizeaz pentru conectare un URL-Uniform Resource Locator, i un fiier de control IDC), fie printr-un singur fiier (WebSite Professional utilizeaz pentru conectare un produs numit Cold Fussion, care integreaz specificaiile ODBC i comenzile SQL direct n ablonul HTML); b. utilizarea unor produse proprietar. Produsele integrate n suita Oracle lucreaz numai ntre ele (urmare, probabil, a unor trsturi motenite de la main-frame-uri). Componenta software a server-ului Oracle care manipuleaz cererile din baza de date se numete WebAgent. Server-ul Oracle lucreaz oarecum diferit: n loc s specifice comenzi SQL i formatri via fiiere text, acesta stocheaz informaiile n baza de date Utiliznd un limbaj proprietar -PL/SQL - limbajul Oracle pentru procedurile de baze de date, a crui logic procedural, subrutine i utilizare de cursori imbricai ofer o mare flexibilitate la ncorporarea datelor n pagini Web. Instrumentele de proiectare care se instaleaz la configurarea WebAgentului constau din proceduri i funcii PL/SQL predefinite (package-uri), care ofer posibiliti de formatare HTML; c. utilizarea ambelor modaliti de conectare la baze de date, att ODBC ct i conectarea nativ. Acesta este cazul produsului Live Wire Professional al firmei Netscape, care suport att ODBC ct i conectarea nativ pentru bazele de date Informix, Sybase i Oracle. Spre deosebire de produsele anterioare, Live Wire face uz de limbajul Java pentru a accesa bazele de date, oferind ntreaga for a unui limbaj de programare complet, la execuie aplicaiile apelnd scripturi Java, ceea ce duce la evitarea ncorporrii ntregului cod ntr-un fiier HTML. Din prezentarea sus-menionat, se pot trage unele concluzii cu privire la specificitatea unor caracteristici de calitate pentru aceast clas de produse software, astfel: 1. Flexibilitatea - n cazul server-erelor INTERNET pentru baze de date este dat de capacitatea de a ncorpora datele din bazele de date accesate, n pagini WEB. Astfel, se poate afirma c produsele care beneficiaz de fora unui limbaj de programare au o flexibilitate mult mai mare. Din aceast grup fac parte produsele Oracle Web Server (cu limbajul su PL/SQL) i Live Wire Professional (care folosete limbajul Java), n timp ce celelalte produse prezentate au o flexibilitate redus. Dintre factorii flexibilitii, specifici acestor produse, se menioneaz: ncorporeaz datele din baze de date n documente; afieaz imagini din baza de date; ncorporeaz datele furnizate de o alt pagin HTML; pagini generate dinamic n timpul accesului; un singur URL poate iniia mai multe comenzi SQL; rezultatele mai multor interogri ntr-o singur pagin HTML;

30

seturi de rezultate imbricate; afiarea condiional; tranzacii (begin, commit, rollback, etc). de date. Din exemplele

2. Interoperabilitatea - n cazul server-erelor INTERNET pentru baze de date este dat de capacitatea de a accesa un numr ct mai mare de tipuri de baze prezentate rezult c interoperabilitatea este mai mare n cazul produselor care folosesc extensia ODBC (atingnd cotele cele mai ridicate n cazul produsului firmei Netscape care utilizeaz att ODBC ct i conectarea nativ) i cea mai sczut n cazul produsului firmei Oracle, care poate accesa numai baze de date Oracle. 3. Securitatea - este o caracteristic de calitate prezent n cazul acestei clase de produse i printr-o serie de factori specifici, dintre care, n [HET1] se menioneaz: suport criptografie SSL; permisiuni scriere/citire la nivel de director; permite/nu permite navigarea directorului; accesul administratorului din navigator WEB protejat de parol; monitorizarea dinamic a ncrcrii; instrumente de analiz a logrii.

4. Uurina n administrare - este o caracteristic de calitate specific produselor software din clasa server-elor. n cazul server-elor de INTERNET aceast caracteristic de calitate are i o serie de factori specifici, cum ar fi: administare prin navigator WEB; manipularea serverelor virtuale multiple; administrarea mai multor servere din acelai loc; logare automat la baza de date; pornire/oprire a bazei de date utiliznd navigatorul WEB; manipularea datelor din baze de date situate pe un alt computer dect server-ul INTERNET.

2.5. Metrici i sisteme de metrici ale caracteristicilor de calitate software

Dei modelul calitii ncorporeaz recunoaterea obiectivelor relevante i, implicit, a caracteristicilor de calitate aferente, din toate perspectivele relevante (utilizator, inginer software, manager, vnztor, etc), construirea unui sistem particularizat al caracteristicilor de calitate, nu

31

reprezint dect puntea ctre reala msurare i evaluare, procese de egal importan n obinerea calitii dorite. Conform [TRI3], pe baza unei corecte definiri a obiectivelor operaionale ale prilor 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, msurarea calitii produselor software cu ajutorul metricilor, trebuie s fie fundamentat din punct de vedere teoretic, iar rezultatele empirice trebuie s fie obinute printr-o bun proiectare a experimentrii. Teoria msurtorilor prevede un cadru pentru caracterizarea numeric a proprietilor sau atributelor intuitive ale obiectelor sau evenimentelor. Aplicarea criteriilor teoriei msurtorilor la msurarea calitii produselor software necesit identificarea i/sau definirea: caracteisticilor, atributelor, produselor sau proceselor software; modelele formale sau abstraciunile ce capteaz sau structureaz aceste caracteristici sau atribute; relaiile importante, ordonrile, ierarhizrile existente ntre obiectele modelate, determinate de atributele modelelor; maparea pe sisteme numerice, prezervnd relaiile de ordine. Aceast ultim idee constituie baza teoriei reprezentaionale a msurtorilor. Dac toate criteriile de mai sus sunt satisfcute, autorii [BAK1] definesc rezultatul final al acestei mapri ca o msur software. O mapare arbitrara care nu satisface n mod necesar primele trei criterii, este definit ca o metric. Pentru a putea folosi msurile software n predicii i planificri ale calitii software, este necesar s existe sau s fie definite: dou sau mai multe msuri ale caracteristicilor sau atributelor; o idee, o supoziie sau chiar o teorie care pune n relaie msurile respective, necesar pentru confirmarea sau infirmarea cauzalitii; o demonstraie empiric a teoriei respective. n ncercarea de structurare a msurilor i metricilor software din [BAK1], acestea sunt referite ca dou concepte separate: msurile definite asupra unor caracteristici sau obiecte pe care le caracterizeaz numeric i sistemele de predicie ce implic un model matematic i anumite proceduri. Pentru a putea fi operaionalizate, metricile i msurile trebuiesc validate. Validarea msurilor se definete ca fiind procesul prin care se asigur c msura reprezint o caracterizare numeric adecvat i fidel a unui anumit atribut. Prin validare se dovedete c msura sau metrica respectiv

32

este bine definit i consistent. Validarea msurilor (numit i validare intern), vizeaz, luarea n considerare a modelelor formale utilizate n captarea atributelor i caracteristicilor. Validarea sistemelor de predicie reprezint procesul empiric prin care se stabilete acurateea sistemului respectiv ntr-un mediu dat, prin mijloace empirice (de exemplu comparnd performanele unui model cu date punctuale brute, cunoscute dintr-un anumit mediu). Att timp ct nu exist o anumit ipotez despre capabilitile predictive ale unor asemenea msuri, 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 msurii cu seturi de date, prin formule determinate iniial, pe baza unei analize de regresie. Validarea extern se distinge astfel de validarea intern efectuat iniial pentru a arta c msura respectiv msoar efectiv un anumit atribut. Validarea extern a msurii m este deci procesul prin care se stabilete o relaie consistent ntre m i seturi de date empirice presupuse a msura un anumit atribut. Autorii articolului [BAK1] arat c, dat fiind slaba nelegere (nc) a relaiilor dintre produsele software i procese, validarea extern pare a fi extrem de ne-fiabil. Cu toate acestea, specialitii n domeniu sunt gata s accepte aceast abordare a validrii, att timp ct msurile propuse reuesc s capteze nelegerea i concepiile intuitive asupra atributelor respective. Msurile corecte pot fi dezvoltate cnd caracteristicile sau atributele respective sunt definite ne-ambiguu, modelate corect i inteligibile. n [PFL1] se pune n legtur modelul maturitate/capabilitate elaborat la Software Engineering Institute (S.E.I.), n S.U.A., cu utilizarea unor anumite tipuri de msuri i metrici. Astfel, modelul amintit, care descrie un set de nivele de maturitate n care se ncadreaz procesele de dezvoltare software dintr-o organizaie, este folosit drept cadru de plasare a metricilor i msurilor software, pornindu-se de la ideea c numai cnd 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 5. Optimizat 4. Condus i controlat 3. Definit 2. Repetabil 1. Iniial Caracteristici mbuntirea procesului prin feed-back Proces msurat (cantitativ) Proces definit, instituionalizat Proces dependent de individualiti Abordare ad-hoc a procesului de dezvoltare Metrici Referitoare la proces + feed-back pentru modificarea procesului Referitoare la proces + feed-back pentru controlul procesului Referitoare la produs Referitoare la proiect Msuri elementare

33

Pentru nivelul 1 se pot face msurtori elementare referitoare la dimensiunea produsului, efortul de dezvoltare, pentru a determina un nivel estimativ al productivitii. n nivelul 2 de maturitate nu sunt disponibile msurrii activitile care realizeaz transformarea intrrilor n ieiri, astfel c, pe acest nivel pot fi aplicate numai metrici referitoare la proiect. La un proces repetabil se poate msura efortul necesar pentru dezvoltarea unui sistem, durata unui proiect, dimensiunea cerinelor, costul total al proiectului, etc. De exemplu, se pot utiliza metricile: numrul de linii de cod; numrul de obiecte i metode (n cazul POO); luni-persoan de efort; volumul schimbrilor n definirea cerinelor; anii de experien n domeniu, ntr-un anumit tip de aplicaii, arhitecturi sau metode. Al treilea nivel de maturitate a proceselor dintr-o organizaie productoare de software se numete definit, deoarece activitile sunt clar definite, cu puncte i condiii de intrare i ieire. Aceasta nseamn c se pot examina intrrile i ieirile fiecrei activiti funcionale definite i executate n timpul dezvoltrii produsului software. Aceast caracteristic permite msurarea produselor intermediare. Metricile recomandate n [PFL1] pentru aceast etap sunt: complexitatea cerinelor, msurat prin numrul de aciuni i obiecte distincte referite n cerine; complexitatea proiectrii, msurat prin numrul de module proiectate, complexitatea proiectrii McCabe; complexitatea testrii msurat prin numrul de ci de test, numrul de obiecte de interfa testate; numrul de defecte descoperite, numrul de defecte descoperite per unitate, modul, etap, activitate (densitatea defectelor), densitatea defectelor pentru fiecare produs intermediar; numrul de pagini de documentaie intermediar, numrul de pagini de documentaie pentru produsul final. Procesul condus i controlat ("managed process") de pe nivelul patru de maturitate ofer posibilitatea utilizrii unor informaii din activiti ale dezvoltrii anterioare procesului curent (de exemplu problemele descoperite n etapa de proiectare, testare, etc) ca feed-back pentru mbuntirea activitilor din aval. De fapt, ntr-un asemenea tip de proces feed-back-ul determin modificarea desfurrii resurselor, activitile de baz rmnnd neschimbate. Pe acest nivel de

34

maturitate al procesului pot fi colectate i analizate date referitoare la ntregul proces. n [PFL1] se recomand la acest nivel culegerea urmtoarelor tipuri de date: date referitoare la modelul de proces (de tip cascad, prototipizare); volumul obiectelor proiectate i realizate pentru a fi reutilizate, n ce msur produsul este proiectat pentru reutilizare (cerine, proiecte de module, planuri de test, cod); volumul reutilizrii la producere, n ce msur proiectul reutilizeaz

componente de la alte proiecte; identificarea defectelor, cum i unde sunt descoperite defectele (n timpul revizuirii cerinelor, proiectelor, inspeciilor pe cod, n fazele de testare); utilizarea managementului configuraiei: este impus procesului de dezvoltare o schem de management al configuraiei? Managementul configuraiei i controlul muncii de modificare permit managementului de proiect exercitarea unui control mai eficace al procesului de dezvoltare? Managementul configuraiei determin i o evaluare a impactului alterrilor i modificrilor n activiti 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 relaii clare dintre caracteristicile produsului i variabilele ce caracterizeaz procesul de dezvoltare ajut la evaluarea msurii n care procesul sau activitile acestuia corespund obiectivelor de calitate i productivitate ale organizaiei. Un proces optimizat este ultimul nivel de maturitate din cadrul modelului. n acest stadiu, msurile i metricile sunt utilizate pentru modificarea i mbuntirea procesului. Modificrile procesului pot afecta att organizaia ct i procesul n desfurare. De exemplu, n cadrul acestui tip de proces, dac metricile indic, n timpul activitilor de definire i proiectare a cerinelor, un grad ridicat de incertitudine, tipul de proces poate fi modificat din cascad n prototipizare, pe baza acestor informaii. Astfel, un proces optimizat ar oferi maximum de flexibilitate dezvoltrii 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 organizaie productoare de software. Metricile sunt folositoare n condiiile n care sunt implementate ntr-o secven bine fundamentat de activiti. Paii de urmat n utilizatea metricilor, conform [PFL1], sunt: 1 - evaluarea procesului;

35

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; 7 - evaluarea costului i a programului proiectului; 8 - evaluarea productivitii i a calitii; 9 - formarea unei baze pentru estimri viitoare.

2.6. Scalare, clasificare i evaluare conform standardului ISO/IEC 9126

Dup cum se autodefinete, standardul ISO 9126 [ISO1], este aplicabil n definirea cerinelor de calitate ale produselor software i n evaluarea calitii produselor software, ceea ce include: definirea cerinelor de calitate ale produsului software; evaluarea specificaiilor pentru a asigura ndeplinirea cerinelor de calitate n timpul procesului dezvoltrii produsului software; descrierea facilitilor 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 cerinele care au dus la alegerea caracteristicilor descrise n acest standard, i anume: s acopere mpreun toate aspectele calitii software, aa cum rezult din definirea calitii n standardul [ISO3]; s descrie calitatea produsului cu un minim de suprapunere; s fie ct mai aproape de terminologia stabilit - consacrat; s formeze un set de ase pn la opt caracteristici din raiuni de claritate i uurin n lucrul cu modelul; s poat fi identificate zone de atribute ale calitii produselor software pentru rafinri viitoare. Rafinarea i dezvoltarea n continuare a celor ase caracteristici de baz oferite de standard se face n funcie de tipul produsului software. Dei nu exist o clasificare unanim acceptat a acestora, standardul mparte produsele software n. trei clase: sisteme software cu misiuni critice

36

(pentru care fiabilitatea este esenial); sisteme software cu criticitate n timp real (pentru care eficiena este cea mai important caracteristic) i sisteme software interactive orientate ctre 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 cerinelor de calitate, pregtirea evalurii i procedura de evaluare. Etapa de pregtire a evalurii cuprinde activitile de selecie a metricilor, definirea nivelelor de clasificare i definirea criteriilor de evaluare, iar etapa de evaluare cuprinde activitile de msurare, 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 msurtorilor. Att acest standard ct 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 - att n general ct i n standardul analizat - nu permite msurarea lor direct. De aici apare necesitatea decompoziiei acestora n caracteristici de nivel mai sczut (subcaracteristici, atribute, factori), crora li se pot asocia metrici care s le reflecte ct mai fidel nivelul. Metrica este definit n cadrul standardului ISO/IEC 9126 [ISO1] ca fiind orice proprietate cuantificabil a produselor software sau orice interaciune 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 funcie 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.

Excelent valori msurate Bun Suficient Insuficient nivel de clasificare Satisfctor

Nesatisfctor

37

Figura 2.2. Scala de valori ale metricilor, divizat n regiuni corespunztoare diferitelor grade de satisfacie Rezultatul msurtorilor, respectiv valorile msurate ale metricilor, sunt mapate pe o scal. Valoarea n sine nu arat un anumit nivel de satisfacie, aspectul cantitativ trebuind s fie proiectat n continuare ntr-o clasificare de ordin calitativ. Ca atare, scala de valori este divizat n regiuni corespunztoare diferitelor grade de satisfacie (a se vedea figura 2.2). Att timp ct 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 calitii unui produs software, rezultatele evalurii diferitelor caracteristici trebuie s fie agregate, pe baza unor criterii de evaluare. Evaluatorul trebuie s pregteasc o procedur, utiliznd de exemplu, tabele de decizie sau medii ponderate (metoda punctajului) [NICI]. Metoda punctajului acord un numr de puncte caracteristicilor de calitate. Calitatea produsului este superioar cnd numrul de puncte acordat este mare. Coeficientul de apreciere prin punctaj (Kp) se determin astfel:
Kp =

( q p)
100

unde q este ponderea fiecrei caracteristici de calitate iar p numrul de puncte acordat caracteristicii respective. Procedura mai include, de obicei, pe lng valorile msurate ale metricilor, i alte aspecte cum ar fi durata sau costul, care contribuie la evaluarea calitii unui produs software ntr-un mediu particular. Nivelul calitii exprimat agregat st la baza unor decizii manageriale, fundamentate pe criterii de ordin managerial.

2.7. Abordarea orientat pe produs i controlul dezvoltrii software

Considerarea calitii ca o mrime ce poate fi msurat exact, este principala caracteristic a abordrii bazate pe produs. Rezult de aici o definire a calitii ca un ansamblu de caracteristici, diferenele dintre caracteristicile de calitate ale produselor constituindu-se n diferene de ordin calitativ ntre acestea. Conform [OLA1], o asemenea abordare se regsete, n special, n lucrrile de teorie economic i de calimetrie: stabilirea unei corelaii stricte ntre variaia caracteristicilor i nivelul calitii produselor, a favorizat introducerea modelrii matematice pentru estimarea acestui nivel. Sistemele calitii construite pe baza abordrii calitii orientate pe produs, denumite i sisteme de calitate tradiionale, determin concentrarea eforturilor organizaiilor productoare de

38

software asupra minimizrii insatisfaciei utilizatorului. Aceste sisteme se focalizeaz asupra detectrii i corectrii defectelor, utiliznd intensiv testrile, auditurile i inspeciile. Datele rezultate din msurri statistice, metrici, testri, audituri i inspecii sunt nregistrate i analizate n vederea mbuntirilor ulterioare. Cu toate acestea, dezvoltarea de software n sistem tradiional rmne lipsit de coeren, datorit, n principal, specificului acestei industrii. "Un sistem stabil este un sistem a crui performan este previzibil. Un sistem stabil se atinge prin eliminarea, una cte una, a cauzelor ce produc disfunciile, detectate cel mai bine prin semnalele indicatorilor statistici" - W. Edwards Deming. Adesea, abordarea problemei calitii prin prisma produsului se confund prea mult cu abordarea pur statistic a problemei calitii. Att concepiile lui P. Crosby ct i cele ale lui E. Deming sunt derivate din experiena acestora n studiul calitii n industria manufacturier. Dezvoltarea de software nu este o industrie de tip manufacturier i de aceea "semnalele indicatorilor statistici" ale lui Deming, dei necesare, nu sunt suficiente pentru control, deoarece nu exist suficient repetiie (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 calitii 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 obinuit al cuvntului (nu poate fi perceput vizual, auditiv, kinestetic, olfactiv, gustativ, etc), de aceea exist un mare numr 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 calitii globale (de exemplu graficul erorilor pe module, complexitatea ciclomatic a modulelor, etc); utilizarea unor modaliti de facilitare a comunicaiei - reprezentarea

informaiilor despre logica software sau calitatea software se face n mod particular pentru fiecare tip de actor participant la realizarea produsului. Astfel, informaiile despre software vor fi mai bine nelese de programatori dac se vor exprima sub forma schemelor logice, iar aceleai informaii vor fi mai bine asimilate de manageri dac vor fi prezentate sub form de diagrame; controlul distorsiunilor i redundanei.

39

n ingineria software, indicatori statistici precum numrul mediu de erori per modul reprezint numai primul pas al procesului de eliminare a cauzelor disfunciilor. n acest caz, managerii nu pot nelege exact semnificaia indicatorilor statistici fr consultarea personalului care cunoate structura codului programelor, aa cum simpli programatori, care lucreaz la anumite pri ale produsului, nu pot percepe n totalitate implicaia erorilor din cod, fr informaii despre consecinele acestor erori asupra ntregului produs software. De exemplu, alte reprezentri (mai apropiate de viziunea managerial) ale graficului numrului mediu de erori per modul, pot fi: costul remedierii erorilor per modul sau timpul consumat pentru remedierea erorilor per modul. Deci, managementul calitii nu poate fi eficient dect dac informaiile despre software sunt comunicate i urmrite att n dinamica lor ct i sub diferitele aspecte (caracteristici) sub care se abordeaz calitatea software. Aa cum la construcia unei case sunt necesare mai multe planuri - planul de structur, planul instalaiei electrice, planul instalaiei de ap i canalizare, planul de ncadrare n zon, etc. - la construirea produsului software, i, n mod particular a calitii acestuia, sunt necesare informaii despre fiecare element implicat: logica programelor, schema fluxului de date, schema bazei de date, rezultatele testrii, etc. nu att la un moment dat, ci aa cum au evoluat ele, n dinamica procesului de dezvoltare. Orice element care duce la distorsionarea, indisponibilitatea, neconsemnarea sau la nereprezentarea adecvat a acestor informaii mpiedic organizaia productoare 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 contribuii reale la mbuntirea calitii.

40

3. Abordarea managerial orientat pe proces (Partea 2)

3.1. 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 eseniale de procese de dezvoltare software, clasificnd organizaiile productoare n funcie de caracteristicile particulare ale procesului lor de producie/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 separaiei dintre productorul i utilizatorul de software ("economia natural"). Nu exist client, manager sau procese specificate, iar cei ce dezvolt software n acest model nu sunt contieni c execut i particip la un proces. Motivaia lor este aceea c nimeni nu poate s le ofere ceea ce doresc sau s le neleag cerinele. Actorii acestui model'sunt programatorii aflai n postura magic a unui creator divin, omniscient i omnipotent. Cu toate c acest model are meritul de a garanta satisfacia utilizatorului (deoarece este identic cu productorul), nu poate fi luat n considerare, deoarece nu nseamn "industrie" software. Industria de software nseamn proiectarea unor aplicaii de complexitate i dimensiuni mari, dezvoltate n cadrul unor echipe i, de cele mai multe ori, n organizaii specializate, urmnd etape bine stabilite [SPI1]. Conform [SPI1], aceste etape se refer la specificarea cerinelor utilizatorului, analizarea acestora, proiectarea de detaliu, implementarea, testarea i ntreinerea/mbuntirea produsului creat, pn la scoaterea sa din utilizare (figura 3.1)- Aceast succesiune de procese definete ciclul de via al software i constituie obiectul ingineriei programrii" [SPI1]. Software se creaz ca rspuns dat unui set de nevoi la un moment dat, i odat cu evoluia acestui set de nevoi i produsul software se maturizeaz, att n perioada de dezvoltare ct 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 urmtoare produsul software exist sub form de cod i sub form de documentaie. n aceste ultime stadii produsul este n form executabil trebuind s ndeplineasc funciile specificate n cerine.

41

Specificare cerine Analiz cerine Implementare Testare Instalarea ntreinerea

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

Ciclul de via al software

Specificare cerine
Analiz cerine Concept Proiectare Preliminar de detaliu
Implementare Software se creaz ca rspuns dat unui set de nevoi la un moment dat, i odat cu evoluia acestui set de nevoi i produsul software se maturizeaz, att n perioada de dezvoltare ct i n perioadele de operare/ mentenan

Testare Instalare ntreinere

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 urmtoare produsul software exist sub form de cod i sub form de documentaie.

Figura 3.2. Etapele ciclului de via al software

42

CERINE PENTRU SOFTWARE

CONCEPT PROIECTARE PRELIMINAR

PROIECTARE DETALIAT PROTOTIP (PRIMA FORM) PRODUS SOFTWARE OPERAIONAL

Figura 3.3. Ciclul de via (modelul 2) Desigur; modelele prezentate sunt modele ideale. n realitate, produsul software nu trece fr opriri i revizuiri de la o etap la alta (datorit unor evenimente de natur variat - modificarea cerinelor, 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 situaii o reprezint controlabilitatea proceselor implicate de ciclul de via, avnd n vedere restriciile impuse acestuia (timp, resurse). Chiar i n cazul celor mai clare modele ce posed un nalt nivel de acuratee, controlarea proceselor nu poate fi fcut cu succes, datorit perturbaiilor aleatoare produse de intrrile proiectului (resurse, date, situaii, poziii ale actorilor implicai i chiar stri de spirit, etc.). n plus, fa de modelul de dezvoltare, controlabilitatea proceselor presupune existena unor modele predictive asupra modului n care diferitele intervenii manageriale pot afecta sistemul sub control. Dup prerea lui G.Weinberg [WEI2], cel mai mare ctig 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 organizaiilor productoare. Aceste organizaii au fcut eforturi majore pentru a-i construi standarde interne, a prescrie i documenta secvene de Aciuni menite s controleze dezvoltarea de software. Metodele tipice prescriu o serie de pai ideali de urmat, ncepnd, de obicei, cu un studiu de fezabilitate, specificarea cerinelor i proiectarea de nivel nalt, urmate apoi de proiectarea de detaliu, codificare, testarea pe uniti, testarea ntregului sistem, testarea "beta" i versiunea final ("product release"). n Figura 3.4. se red modelul de procese n cascad din [WEI2], din clasa crora fac parte i modelele prezentate mai sus. Modelul original se traduce printr-un plan strict secvenial, avnd reprezentate sgei unidirecionale ntre noduri.

43

Cerine de sistem

Specificaii cerine Analiz Proiectarea programelor Codificare Testare Operaionalizare

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. Bucureti, n 1982, i preluat n [D0D1]. Etapele acestei metodologii sunt prezentate, pe scurt, n Anexa 4. n scurt timp, au nceput s apar modificri ale modelului proceselor n cascad, constnd n bucle de feedback, modificri ce reprezint recunoaterea faptului c un model pur liniar este o descriere inadecvat a ceea ce se ntmpl n realitate n dezvoltarea de software. Modificrile iniiale aprute sunt prezentate n Figura 3.5.

Cerine de sistem Specificaii cerine Analiz

Modelul proceselor n cascad, const n bucle de feedback, modificri ce reprezint recunoaterea faptului c un model pur liniar este o descriere inadecvat a ceea ce se ntmpl n realitate. Bucle de feedback n dou zone: de la proiectarea programelor la specificarea cerinelor i de la testare la proiectarea programelor.

Proiectarea programelor Codificare Testare Operaionalizare

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

44

Asumpiile implicite sau explicite luate n calcul la realizarea metodologiilor liniare sunt: nu vor fi fcute greeli; dac se vor face greeli, acestea nu vor fi de amploare; prile responsabile vor ti, cu certitudine, cum s corecteze micile greeli. Pe aceast baz, n [WEI2], metodologiile secveniale se definesc ca modelnd procese lineare, suplimentate prin feedback-uri implicite. Odat cu creterea dimensiunii i complexitii proiectelor efectuarea micilor corecii instinctive nu mai poate fi suficient. Modificrile modelului, surprinse n Figura 3.5, vizeaz introducerea unor bucle de feedback n dou zone: de la proiectarea programelor la specificarea cerinelor i de la testare la proiectarea programelor. Dar reexaminarea, modificarea sau chiar refacerea specificaiilor sau a proiectelor programelor, pe lng faptul c este costisitoare, presupune perturbarea i mai puternic a ntregului eafodaj al realitii proceselor de producie, ceea ce face ca i acest model s fie inaplicabil. n plus, metodologia nu prevede n nici un sens ce informaii 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, dnd atenia cuvenit micilor deviaii care apar n procesul de dezvoltare, de la o etap la alta, se acioneaz mai devreme i deci mai puin, Humphrey Watts introduce ideea celulelor unitare de baz (basic unit cells) din care se compune un proces mai mare. Fiecare din aceste celule este prevzut cu bucl de flux de feedback ce provine de la celulele ulterioare i merge la celulele anterioare. Minimiznd 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 conjuncie cu celulele de baz ale lui W. Humphrey, se utilizeaz "Ciclul evolutiv de livrare" al lui Gilb. Conform acestui model, munca se desfoar n micro-proiecte, buclele de feedback neputnd crete prea mult. Maximul admis al buclei este de la un micro-proiect la altul (Figura 3.7)

45

Stabilirea obiectivelor de perspectiv Arhitectura global deschis Schi de plan de evoluie

Feedback

Feedback

Ingineria etapei curente (atribute, soluii, sub-etape) Construirea etapei planificate Livrarea ctre un utilizator real Evaluarea rezultatelor

Micro-proiect
Figura 3.7. Maximul admis al buclei de feedback Att celulele de baz ct i micro-proiectele, ncearc s rezolve problema legturilor inverse, dar se focalizeaz numai asupra produsului care este n curs de dezvoltare. Pe legtura invers circul numai informaii despre produs (rezultate ale unor metrici, ale inspeciilor asupra produsului sau ale auditurilor pe produs), i nici un fel de informaii despre proces, n general. Pentru o conducere efectiv i eficient, un manager trebuie s aib mult mai multe informaii i mult mai devreme n timp, informaii pe care, singur produsul, nu le poate furniza. O viziune mai complet asupra mbuntirii calitii software i a productivitii, o ofer abordarea procesual (Deming). Un program de mbuntire ideal combin orientarea bazat pe proces cu ideea mbuntirilor mici dar continue, pentru a produce cu succes modificri, meninnd instabilitatea la un nivel minim. n vederea eliminrii bulversrilor ciclului de dezvoltare, generate ndeosebi de modificri, clarificri sau revizuiri ale cerinelor beneficiarilor de software, s-a dezvoltat un nou model al proceselor, bazat pe proprietile noilor instrumente i platforme de dezvoltare, care permit

46

dezvoltarea relativ rapid a "faadei" unei aplicaii incomplete (interfaa), asupra creia beneficiarul proiectului este chemat s-i exprime punctele de vedere. Prototipizarea, bazat pe un schelet de aplicaie (prototip), dei este eficient pentru aplicaii de gestiune de date (sisteme de gestiune de baze de date, subsisteme "front office" pentru culegere de date, etc), poate fi mai puin eficient n cazul aplicaiilor de dimensiuni i complexitate mare. Aceasta fie datorit costurilor considerabile ale dezvoltrii unor asemenea prototipuri, care vor influena costurile totale ale proiectului, fie datorit complexitii construirii i testrii prototipului nsui. Prototipizarea rmne totui o metod eficient de aplicat n cazul etapelor procesului de dezvoltare. Astfel, pentru fiecare produs software rezultat n urma fiecrei etape din cadrul procesului de dezvoltare (specificaii, documentaii, cod), n funcie de instrumentele automate de care se dispune i de eficiena economic, se poate elabora mai nti o variant prototip, urmnd ca, n cadrul etapei, aceasta s fie rafinat i completat iterativ. Att timp ct aceste modele ale ciclului de via sunt aproximri, nici unul nu poate fi perfect, dar trebuie s aibe cel puin calitatea de a fi credibile. Aa cum se arat i n [WEI2], problema principal a modelelor, ciclului de via rmne neliniaritatea, i, uneori, chiar iterativitatea (conexiunile inverse, repetate sau nu). O alt soluie oferit acestei probleme este aceea de a corecta i completa modelul ciclului de via cu un alt tip de modele - modelele interveniilor. Aceste modele pot ajuta att la nelegerea a ceea ce nu se poate controla, ct i la formarea unei imagini corecte asupra efectelor unor intervenii 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 cauzefect. Exemplul simplu prin care n [WEI2] se ilustreaz aceast tehnic de lucru este edificator. Astfel, dac lum n considerare modelul ciclului de via tip cascad (Figura 3.1.3), se poate face urmtoarea afirmaie: Dac s-a terminat etapa proiectrii programelor, i am executat etapa de codificare, urmtoarea etap va fi testarea, etap ce va duce produsul software mai aproape de stadiul operaional. Avnd 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 operaional, i anume: 1. fie s fie trimis n stadiul "Verificare cerine" (de fapt reverificare cerine), aa cum sugereaz modelul (i, probabil, metodologia de lucru); 2. fie s fie ntr-un stadiu nemenionat n model (i n nici o metodologie), ntr-un stadiu mai mult sau mai puin formal, n care:

47

a) numrul i complexitatea dificultilor aprute n etapa de codificare este foarte mare (de nedepit); b) participanii la proiect manifest o ncredere nejustificat n capacitatea echipelor lor de dezvoltare de a soluiona problemele aprute; c) conducerea organizaiei crede, n mod eronat, c proiectul este foarte aproape de terminare; d) unul sau mai muli programatori de baz sunt epuizai din cauza muncii suplimentare, sau pur i simplu au prsit organizaia, sau manifest un puternic sentiment de frustrare, din cauze diferite (familie, nemulumiri de ordin profesional, salariale, ec), fapt ce ce afecteaz serios munca; e) un programator i un ef au devenit inamici de nempcat. n general, personalul implicat n dezvoltarea de software, (oameni cu pregtire de tip exact), i n special conducerea, sunt poate prea obinuii cu metodologiile, nefiind capabili s prezic, s neleag i s depeasc cu succes, pentru toi actorii participani, efecte negative care nu sunt bazate n mod direct pe metodologiile elaborate de ei. Continund 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 aprute poate fi intensitatea frustrrilor (Figura 3.8).
Cerine de sistem Specificaii cerine Analiz 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 aprute poate fi intensitatea frustrrilor

Proiectarea programelor Codificare Testare Intensitatea frustrrilor Operaionalizare

Erori n cod

Erori n etapa de testare

Figura 3.8. Model de diagram cauz-efect

48

Efecte precum erori n cod pot avea originea n oricare din etapele modelului/metodologiei, precum i alte cauze nemenionate (un programator care lucreaz la alt proiect corupe, din greeal, codul surs). De asemenea, variabile precum intensitatea frustrrilor pot fi influenate de nenumrai 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, experiena cptat de membrii echipei de dezvoltare, relaiile umane i profesionale dintre membri echipei, precum i cele dintre acestea i conductorii proiectului, experiena personal cptat de fiecare i de echip n ansamblu, ncrederea n manageri, etc). Cele mai multe metodologii sunt focalizate asupra produsului, astfel nct nu menioneaz nici un alt produs al procesului care nu este direct legat de calitatea produsului software final rezultat, de costul sau programul proiectului.

3.2. Principii de proiectare a proceselor de dezvoltare software

Msura fundamental a oricrui proces cu feedback controlat este posibilitatea de a compara ceea ce a fost planificat a se realiza, cu ceea ce s-a realizat n fapt. Proiectarea proceselor de dezvoltare software are la baz dou activiti: A. analiza riguroas a cerinelor i specificaiilor, fr de care nu se poate face nici o evaluare asupra dimensiunilor, efortului de realizare i a obiectivelor privind calitatea produsului; B. planificarea msurabilitii proceselor i produselor (software dar i a altor produse rezultate), intermediare i finale, fr de care nu se poate asigura nici gestiunea i nici managementul operaional al calitii. n esen, dei pot exista mai multe variante de proceduri pentru rafinarea cerinelor, toate trebuie s aib acelai scop: eliminarea ambiguitilor i a elementelor vagi. Dei evoluiile lumii reale determin modificarea continu a cerinelor chiar i n timpul procesului de realizare a proiectului, ceea ce conduce, pe aceast baz, la un dialog permanent ntre productorul de software i viitorul beneficiar, procesul iterativ de aproximare a cerinelor trebuie s ngusteze aceast tendin i s o ndrepte ctre ceva ce se poate finaliza i pune n oper. De fapt, procesul de dezvoltare software i procesele prin care se genereaz noi cerine sunt procese care se controleaz mutual prin bucle de feedback. Pentru a ine sub control generarea de cerine, care ar putea conduce la dereglarea procesului de dezvoltare de software, G. Weinberg propune n [WEI1] semnarea, la nceputul fiecrui proces din sistemul dezvoltrii produsului software, a unui Raport de acceptare a nceperii procesului

49

(Startup Task Acceptance Report - STARt). Semnarea acestui raport de ctre toate prile implicate are avantajul c, pe lng responsabilitatea semnturii, certific faptul c a avut lor un proces preliminar de negociere. Modelul acestui raport se prezint n Anexa 5. Aa cum se arat n [ZUL1], clienii cumpr sau accept produsele software att timp ct: 1. i ajut n rezolvarea problemelor; 2. i ajut n sesizarea oportunitilor de mbuntire a propriei activiti; 3. le ofer o imagine bun pe pia, n faa clienilor lor cei mai semnificativi; 4. le uureaz munca i contribuie la mbuntirea confortului acesteia. Aceste elemente constituie motive puternice pentru focalizarea ateniei echipei de dezvoltare software n direcia sesizrii corecte a problemelor i oportunitilor clientului. n cadrul managementului calitii totale, n vederea livrrii ctre clieni a unor produse de valoare, s-a dezvoltat n Japonia, metodologia desfurrii (explicitrii) funciei calitii - Quality Function Deployment - QFD - ca o structur sofisticat, cu mai multe subsisteme. Instrumentele i tehnicile acestei metodologii sunt aplicate n prezent n proiectele de dezvoltare de hardware, servicii i software. Metodologia utilizeaz apte instrumente de planificare, descrise pe scurt n tabelul 31. Tabelul 3.1 apte instrumente de planificare i gestiune pentru QFD 1. Diagrama de afinitate - dezvoltat de antropologul japonez Jiro Kawakita i cunoscut i sub denumirea de "metoda KJ"; - se utilizeaz pentru redarea structurii nevoilor clientului; - prin extragerea direct a structurii cognitive pe care clienii o utilizeaz n momentul n care se gndesc la propriile nevoi, se obine o ierarhie natural a cerinelor. 2. Diagrama de relaii - mai sunt denumite i digrafuri inter-relaii; - n mod sintetic (descriptiv), sunt utilizate pentru documentarea cerinelor explicite ale clienilor; - n mod analitic, sunt utilizate pentru a descoperi cerinele implicite i deosebite ale clienilor. - sunt utilizate ca modalitate de prezentare a analizei statistice multivariaionale; 3. Matricea analizei - cuprinde rezultatele aplicrii unor tehnici statistice cum ar fi: analiza componentei principale, analiza cluster, analiza factorial, regresia multipl, datelor etc; - se utilizeaz pentru segmentarea clienilor sau a cerinelor, atunci cnd exist un volum suficient de mare de date. Datorit complexitii matematice i a volumului de date necesare, se utilizeaz mai rar.

50

4. Diagrama ierarhiilor

- se mai cunoate sub numele de diagram arbore sau diagram sistematic; - se utilizeaz pentru organizarea n ierarhii a caracteristicilor cheie ale proiectelor: fiabilitate, cost, nevoi ale beneficiarilor; - ierarhia construit cuprinde nivelul primar, secundar i teriar; - un nod fiu poate avea mai multe noduri printe; - sunt utilizate pentru clieni, a cerinelor, etc. analiza funcional i decompoziia masei de i

5. Matrici i tabele

- utilizate n mod dinamic pentru a desfura i explicita valoarea prioritile de-a lungul ntregului proces de dezvoltare software;

- matricile desfoar simultan relaiile dintre dou sau mai multe caracteristici cheie ale calitii sau ale proiectului; apte instrumente de planificare i gestiune pentru QFD - tabele sunt utilizate pentru ajustarea prioritilor, stabilirea nivelelor de performan de atins, documentarea detaliilor pentru procese i decizii. 6. Schema deciziilor - instrument utilizat n ingineria fiabilitii; privind procesele - se utilizeaz n conjuncie cu arborele erorilor i analiza efectelor eecurilor (cderilor de sistem). 7. Diagrama de - este o variant mai nou a reelei de activiti i a diagramelor sgei; preceden - sunt utilizate pentru analiza reducerii termenelor n conjuncie cu diagrame PERT probabiliste.

Metodologia QFD cuprinde trei clase majore de desfurri: a) Desfurri fundamentale desfurarea clienilor - cuprinde determinarea tipurilor de clieni pentru care echipa de dezvoltare software ncearc s realizeze proiectul. Precede determinarea cerinelor; desfurarea calitii - const n explorarea, cu ajutorul instrumentelor i tehnicilor menionate, a ierarhiei cerinelor clienilor, precum i segmentarea acestora. Odat stabilite cerinele clienilor, pe fiecare segment, acestea sunt translatate i desfurate sub forma cerinelor tehnice (sau capabilitilor), concretizate n obiecte, entiti, date, procese, evenimente, etc. n acest mod, proiectarea de ansamblu i de detaliu sunt focalizate asupra valorii privite din perspectiva clienilor; b) Desfurri orizontale - concretizeaz modul de funcionare al produsului desfurarea funciilor produsului - const n explicitarea funciilor de prelucrare, a mecanismelor acestora (detalii funcionale) i a componentelor care realizeaz aceste funcii; desfurarea informaiilor - cuprinde modul de organizare a datelor cu care opereaz produsul software (structuri de fiiere, scheme de baze de date, etc);

51

desfurarea

activitilor

urmrete

identificarea

i creterea

vizibilitii

activitilor cheie ale procesului de dezvoltare software; c) Desfurri verticale - concretizeaz modul de proiectare i dezvoltare al proiectului desfurarea desfurarea tehnologiilor raportului identificarea celor mai adecvate modaliti de proiectare i dezvoltare a produsului software; cost/program expliciteaz termenele i costul fiecrei activiti cuprinse n programul proiectului. Pentru proiectele de dezvoltare de software, elementul cel mai important al costului este numrul de ore-om utilizate; desfurarea fiabilitii - expliciteaz nivelul planificat al fiabilitii n condiiile date, tipurile de erori, activitile de prevenire i ameliorare a efectelor cderilor de sistem. Sunt integrate n procesul de proiectare i dezvoltare instrumente i tehnici referitoare la fiabilitate; desfurarea altor elemente - cuprinde explicitarea unor caracteristici i elemente de interes particular pentru client, proiect, produs sau organizaie. De exemplu, pentru produsele software la care memoria de lucru este un element critic, se poate proceda la explicitarea utilizrii memoriei i a tehnicilor utilizate. Planificarea msurabilitii i a ceea ce se va msura pentru gestiunea calitii este un element esenial al proiectrii gestiunii calitii, n cadrul oricrui proiect de dezvoltare de software. Aceasta presupune desfurarea unui set minimal de activiti care s pun bazele unui management de calitate i ale producerii de software de calitate. Premisele realizrii unui proiect msurabil sunt, dup opinia exprimat n [WEI1]: compunerea proiectului din procese msurabile; un sistem de creare i ntreinere a unei vederi globale publice (rapoarte, scheme, reprezentri grafice) asupra progresului realizat n domeniul calitii proiectului; un sistem de cerine bine ntocmite, care documenteaz tot ceea ce furnizorul i beneficiarul neleg - de comun acord - prin calitatea produsului software; un sistem consistent de revizii i inspecii care s msoare orice evoluie a calitii proiectului. Realizarea oricrui proiect presupune mutaia unui sistem dintr-o stare A (starea iniial), ntr-o stare B (starea final dorit). O asemenea transformare nu poate fi fcut fr perceperea exact a strii A, cunoaterea complet a cerinelor pentru starea final dorit B i cunoaterea realitilor strilor A i B. G.Weinberg recomand n [WEI1] urmtorii pai de parcurs pentru proiectarea general a unui sistem de procese care s duc la realizarea cu succes a unui proiect msurabil de dezvoltare de software i s permit totodat gestiunea strict a calitii:

52

a) Pregtirea pentru o succesiune de procese iterative. Definirea proiectului este adesea pasul cel mai greu. Odat cu definirea complet, fr ambiguiti i corect a proiectului, orice manager trebuie s fie pregtit psihologic pentru viitoarele (numeroase) rafinri i redefiniri, unele din acestea aprnd chiar foarte aproape de terminarea acestuia; b) Identificarea clienilor i valorizarea opiunilor acestora. Una dintre primele sarcini ale managerului de proiect este de a decide persoanele ale cror cerine trebuie neaprat satisfcute clienii. ncepnd proiectul cu clienii i valorizndu-le corespunztor opiunile i cerinele, aceasta presupune deja plasarea problemei calitii pe "creasta valului"; c) Selectarea obiectivelor posibile de atins. Formularea obiectivelor trebuie s fie clar i, pe ct posibil, exprimat n termeni nenegativi. De exemplu, n locul formulei: "Proiectul nu va putea s depeasc bugetul alocat", se poate opta pentru formula: "Proiectul va avea un buget i un set de cerine stabilite, de comun acord, de managerii organizaiei i de managerii proiectului, nainte de nceperea acestuia. Proiectul se va executa n condiiile ndeplinirii setului de cerine i n limita bugetului aprobat". d) Stabilirea obiectivelor ntr-o manier msurabil, concret. Stabilirea n acest mod a obiectivelor presupune existena unui rspuns clar la orice ntrebare de genul: "Cum se poate dovedi c obiectivul X a fost atins?". De aceea, n formularea obiectivelor trebuie evitate fraze cu un neles vag precum: "Se va aciona n direcia creterii calitii i productivitii". e) Stabilirea obiectivelor trebuie fcut cu constrngeri minime asupra proiectului. De exemplu, se recomand evitarea formulrii unor obiective de genul: "Testarea produsului software se va face pe 100 staii de lucru IBM, care vor fi instalate pn la data de 20 martie". O alternativ care duce la minimizarea presiunilor asupra proiectului poate fi: "Produsul software va fi testat pe 80 pn la 100 staii de lucru. Toate staiile de lucru vor fi identice, dar configuraia aleas trebuie s fie cea recomandat de furnizorii urmtoarelor programe i produse software ....". f) Verificarea posibilelor obstacole. Trebuie s se alctuiasc o list care s cuprind ct mai multe posibile obstacole ce pot sta n calea realizrii obiectivelor. Ulterior, fiecare posibil obstacol va fi analizat i se va stabili dac poate fi ntr-adevr un obstacol, precum i posibile ci de depire a acestuia (Figura 3.9). OBSTACOL Lipsete o anumit experien vis-a-vis de rezolvarea unor aspecte tehnice ce se prognozeaz c vor apare n programe. CI POSIBILE DE REZOLVARE 1. Angajarea unor colaboratori sau consultani externi 2. Crearea unui program rapid i intensiv de pregtire 3. Reproiectarea complexitii produsului n vederea reducerii

4. Transferarea unor programatori experimentai care lucreaz la alt proiect

Figura 3.9. Obstacolele i cile de depire

53

g) Verificarea resurselor. Acesta este un pas peste care muli manageri de proiect trec cu uurin, avnd n vedere faptul c, n general, resursele umane, financiare i materiale, sunt cuprinse n planurile proiectului. O asemenea viziune ngust asupra resurselor poate pune un manager, n cursul derulrii proiectului, n posturi cel puin delicate. De exemplu, dac clientul face urmtoarea afirmaie: "Doresc o interfa utilizator foarte prietenoas, care s faciliteze n cel mai nalt grad operarea", dar la ntrebarea productorului "Ct timp putei aloca pentru a defini exact cerinele dumneavoastr n ceea ce privete aceast interfa prietenoas", clientul rspunde: "Sunt prea ocupat pentru a face acest lucru. Voi facei interfaa i apoi voi fi mai explicit cnd voi vedea rezultatul", acest rspuns relev cel puin dou aspecte: pe de o parte interesul clientului n realizarea interfeei respective nu este prea "arztor", iar, pe de alt parte, clientul nu poate fi luat n considerare ca o resurs pentru proiect (ceea ce este mai grav). h) Planificarea invers. Pentru a putea planifica invers, este necesar ca, mai nti, s existe o imagine clar a strii B (starea final dorit). Pornind napoi ctre starea iniial A, se identific o stare intermediar C, din care starea B este cel mai probabil de atins, i aa mai departe: A E D C B. Desigur c nici un plan real nu poate fi liniar. De exemplu, un plan simplu poate avea o structur de graf de forma (figura 3.10):

H A I G
Figura 3.10. Structura de graf a planului

D C B

unde C = pregtirea instalrii i testrii la beneficiar, D = testarea final la productor, E = activiti de corecie i revizuire dup testare, F = plan de revizuire i completare a sistemului calitii, G = testarea pe faze, H = realizarea proiectelor i a programelor, I = stabilirea responsabilitilor i autoritilor, alocarea resurselor umane i materiale. Fiecare stare intermediar poate fi descompus, la rndul ei, n sub-grafuri. Planificarea invers poate fi eficient n condiiile n care: lungimea grafului este suficient de mic, astfel nct elementele de incertitudine s fie diminuate;

54

planificarea trebuie s fie incremental, n pai realiti, astfel nct, dac sistemul nu a atins exact starea intermediar dorit, s poat fi uor corectat sau redresat n cadrul pasului urmtor.

3.3. Gestiunea construirii calitii software

Pentru gestiunea construirii calitii software, sunt utilizate ca instrumente de lucru diagramele de proiect, diagrame ce puncteaz fiecare proces parcurs, n curs, n ntrziere, n impas, furniznd 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) cnd sunt aplicate n gestiunea proiectelor de dezvoltare de software. Astfel, aceste tipuri de diagrame arat numai procesele, omind dou lucruri: 1. condiiile eseniale care trebuie s fie ndeplinite pentru ca un proces s fie parcurs cu succes, cum ar fi: cerinele documentate, care reprezint un standard de msurare pentru revizii i inspecii; resursele umane implicate n proces, pregtirea i experiena lor; activitile obligatorii care trebuie ndeplinite n procesele anterioare, fr de care procesul prezent nu poate fi dus la ndeplinire; resursele software i hardware de care depinde procesul; adecvarea spaiului de lucru; fondurile prevzute n buget pentru procesul prezent. i inspeciile, care servesc la msurarea calitii produsului software

2. reviziile

rezultat n urma procesului. n diagramele PPPP, fiecare proces este reprezentat printr-un dreptunghi mprit n trei pri: condiiile necesare, procesul n sine i revizia (Figura 3.1) n rubricile din cadrul dreptungiului poate fi cuprins descrierea succint sau amnunit a fiecreia.

Condiii necesare procesului N

Procesul N

Revizia (inspecia) procesului N

Figura 3.11. Diagramele PPPP (Public Project Progress Poster)

55

Fr reprezentarea reviziilor i inspeciilor aferente procesului, actorii implicai 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 msurtorile fcute sunt comparate favorabil cu cerinele documentate, parte a condiiilor necesare desfurrii procesului. Acest mod de reprezentare determin simplificarea diagramei, prin faptul c nu mai este necesar s fie reprezentate absolut toate legturile inverse (legturile 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 modificri minore, rubrica reviziei este colorat cu galben i se adaug o nou rubric pentru proiect (Figura 3.12,b). n situaia n care se constat, n urma reviziei, c produsului trebuie s-i fie fcute modificri majore, rubrica reviziei se coloreaz n rou i se adaug o nou rubric pentru produs i pentru revizie ( Figura 3.12,c). Dac, n urma reviziei se constat c produsul trebuie refcut n ntregime, rubrica reviziei se coloreaz n negru, iar dreptunghiul se completeaz cu o rubric pentru condiiile necesare, una pentru proces i una pentru revizie (Figura 3.12, d)

Condiii necesare procesului N

Procesul N

Revizia (inspecia) procesului N

Condiiile procesului N+1

Procesul N+1

Revizia procesului N+1

Figura 3.12,a. Diagrama, cnd produsul software a trecut cu succes de revizie

Condiii necesare procesului N

Procesul N

Revizia (inspecia) procesului N

Procesul N

Figura 3.12,b. Diagrama, cnd n urma reviziei sunt de efectuat modificri minore

Condiii necesare procesului N

Procesul N

Revizia 1 proces N

Procesul N

Revizia 2 proces N

Figura 3.12.c. Diagrama, cnd n urma reviziei sunt de efectuat modificri majore

Condiii necesare proces N

Proces N

Revizia 1 proces N

Condiii necesare proces N

Proces N

Revizia 2 proces N

Figura 3.12.d. Diagrama, cnd n urma reviziei este necesar refacerea produsului

56

Diagrama PPPP va fi actualizat cel puin sptmnal. Fiecare dreptunghi corespunztor unui proces va fi aranjat pe o scal a timpului, corespunztor programului proiectului, pentru a se putea urmri 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.

Cerine Documentate, Proiecte, Standarde de testare

Elaborare planuri de testare

Planuri de testare complete

Elaborare teste

Teste complete

Figura 3.13. 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 cnd procesul de elaborare a testelor este n ntrziere. Procesele care nu au nceput s fie executate la data stabilit n grafic sunt reprezentate n diagrama PPPP lsnd o urm neagr n urm ("dr"), n figura 3.14. se prezint un exemplu, conform cruia 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 modificri nsemnate n organizaia productoare de software, din mai multe motive. n primul rnd, prin crearea i actualizarea unei asemenea diagrame, nici o neregul n sistemul de dezvoltare al produsului software nu mai poate fi ascuns. Uurina cu care poate fi interpretat o diagram PPPP face vizibil evoluia procesului,

Cerin Cerine documentate

Proiectarea Modulului 21 Proiectarea Modulului 21

Scriere programe Modul 21

Documentele Proiectului Modulului 21

19.01
Figura 3.14. Diagrame ce indic incadrarea n timpul programat

57

astfel nct pot fi identificate repede procesele ce cauzeaz ntrzierea. De asemenea, seriozitatea cu care managementul de proiect urmrete realizarea i actualizarea diagramei PPPP transmite un mesaj clar echipei asupra seriozitii i rigurozitii conducerii. n unele variante ale diagramelor PPPP, dreptunghiurile aferente proceselor mai includ o rubric, actualizat, de asemenea, sptmnal, i anume ct s-a cheltuit din bugetul alocat procesului respectiv. Managementul calitii 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 informaii din subsisteme ca: iniierea 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, activitile privind calitatea software se cuprind n trei grupe, i anume: asigurarea calitii (QA) - activitile planificate sau sistematice necesare pentru ca un produs/serviciu s satisfac nevoile date; controlul calitii (QC) - prevede modalitile concrete prin care este construit calitatea produsului; managementul calitii (QM) - ansamblu de activiti n cadrul funciilor generale ale managementului, prin care se determin i implementeaz calitatea produsului. Instrumentele automate pentru susinerea acestor activiti trebuie s asigure i pregtirea personalului n utilizarea standardelor, precum i modaliti de susinere a activitilor de auditare a conformanei cu standardele. Sistemul automat de management al calitii 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 activitile mai multor subsisteme- tabelul 3.2. Aa cum se arat n [WAL1], n timpul testrii ntregului produs software i al primei perioade de utilizare efectiv a acestuia, comportamentul produsului poate fi observat direct. Atunci este posibil verificarea exact a conformanei calitii operaionale cu calitatea ce reiese din specificaiile pe baza crora a fost construit produsul. Pentru aceast perioad, s-a construit un

58

instrument separat de evaluare a produsului software, deoarece metricile i modelele pe baza crora se efectueaz verificarea nivelelor finale ale caracteristicilor de calitate software sunt de obicei diferite de cele utilizate n timpul monitorizrii proiectului. Printre avantajele pe care autorii sistemului - denumit n final IPSE (Integrated Project Support Environments) - le evideniaz, sunt: asigurarea conformanei cu standardele prin nglobarea standardelor direct n produsul CASE IPSE, (ntr-un instrument care asist producerea documentaiilor) i simplificarea auditrii conformanei cu standardele, care poate fi demonstrat prin simpla verificare a utilizrii instrumentelor CASE conformante cu standardele. n acest mod se reunesc constructiv activitile de nvare a standardelor, de nvare a producerii unui produs software i de nvare a executrii unei activiti n conformitate cu un standard ce descrie un sistem al calitii. Tabelul 3.2

Structura QMS - Quality Management System

Instrumente
1. Planificarea i iniierea

Subsisteme
Asistarea planificrii Crearea specificaiilor cerinelor calitii Analiza fezabilitii i prognozarea calitii

Activiti software
Creare planuri calitate, verificare, validare planuri, proiectului strategii de testare, identificare metrici utilizate la monitorizarea proiectului, Stabilire nivele msurabile ale factorilor de calitate (subcaracteristici), analiza viabilitii acestor nivele i a modalitilor utilizate pentru atingerea lor Utilizare elemente critice pentru succesul proiectului pentru a previziona calitatea produsului final n termenii specificaiilor cerinelor calitii. Utilizare date metrici selecionate pt. elaborare de rapoarte i analize de stadiu privind proiectul, n termenii de calitate stabilii. Utilizare date obinute pentru realizare rapoarte privind nivelul calitii produsului software obinut i prognoze cu privire la activitatea de mentenan i suport tehnic.

2. Monitorizarea proiectului 3. Evaluarea proiectului

3.4. Inspectarea calitii 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. Dei metodele de inspectare difer prin modul de organizare i de acoperire a codului, structura, componena i dimensiunile echipei de revizie, n esen acestea realizeaz n fapt acelai lucru: inspectarea produsului software i organizarea unor discuii avizate i constructive n legtur cu acesta.

59

n timp, odat cu creterea dimensiunii i complexitii proiectelor, a exigenelor 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 acelai timp i garania suficienei. Deci, alturi de testare, inspecia i examinarea codului, indiferent de metoda utilizat, rmne un proces i o metod viabil att din punct de vedere al rezultatelor ct i din punct de vedere al costurilor. Studii empirice, bazate pe rezultate practice obinute de mai muli manageri de proiecte software (D.P. Freedman, G.M. Weiberg, M.E. Fagan, G.W. Russel), referite n [KNI1], arat c reviziile i inspeciile pot reduce numrul de erori coninute n programele ajunse n faza de testare cu aproximativ 10%, ceea ce determin reducerea costurilor de testare cu 50% pn 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% pn la 85% din defectele operaionale sunt detectate prin inspecii, la un cost cu 1/4 pn la 2/3 mai redus fa de testare, i sunt remediate cu un cost ce ajunge la 1/7 pn la 1/2 fa de costul remedierii lor n faza de testare. Defectele operaionale sunt definite n acest context ca mici greeli de logic, utilizri incorecte ale unor operatori, utilizarea unor construcii de o ineficient inacceptabil i alte defecte ce determin programele s nu execute sau s execute incorect anumite operaiuni, avnd uneori, prin propagare, efecte dezastruoase asupra funcionrii de ansamblu a produsului. n [TEO5] se prezint cteva tipuri de metode de revizie i inspecie a codului, aa cum sunt ele enumerate n literatura de specialitate [KNI1], [WEI1]. Aceste metode s-au sistematizat n funcie de scopul urmrit, astfel: inspecii i revizii care urmresc depistarea erorilor sau obiective limitate:

revizia formal - autorul produsului, sau unul din revizorii familiarizai cu munca la produs prezint produsul celorlali revizori. Fluxul inspeciei este condus de prezentarea fcut i de problemele ridicate pe parcurs de revizori; revizia activ a proiectrii (sau metoda Parnas i Weiss) - const n efectuarea unor scurte revizii, fiecare fiind focalizat pe o anumit parte a produsului segmente ale documentaiei de (de obicei proiectare). Participanii la aceste revizii sunt

ghidai de ntrebrile puse de autorii proiectrii, asftel nct s ncurajeze o examinare ct mai amnunit; metoda camerei curate - este mai mult dect o simpl metod, dei revizuirea produsului de ctre productor 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 documentaie) s fie executat,

60

pus n aplicare sau examinat de cel care 1-a scris. n unele cazuri, nici compilarea modulelor nu este fcut de autorii lor. Acesta metod vizeaz ncurajarea executrii unor verificrii riguroase din partea factorului uman, dar i structurarea produselor software astfel nct acestea s se preteze testrii pe uniti sau module. inspecii i revizii care urmresc testarea conformanei:

parcurgeri ale codului (walkthroughs) - sunt utilizate pentru examinarea codului surs n relaie cu documentele de proiectare i cu specificaiile. Participanii execut o simulare pas cu pas, linie cu linie a codului i a documentaiei. Autorii programelor sunt prezeni pentru a rspunde eventualelor ntrebri ale participanilor;

- inspecii - ntr-o inspecie, se stabilete o list de criterii cu care produsul trebuie s fie conformant, iar aceast list determin fluxul reviziei. Inspeciile sunt utilizate i pentru evaluarea unor caracteristici de calitate, cum ar fi portabilitatea sau conformana cu standardele. Inspectorul trebuie s stpneasc bine lista de criterii, sau s fie bine informat asupra nivelului dorit al caracteristicilor de calitate ce urmeaz a fi inspectate; - metoda celor N inspecii - este o tehnic adaptat analizei conformanei cu cerinele i specificaiile utilizatorului, materializate n documentaii. n cadrul acestei metode sunt efectuate cteva inspecii, n paralel, conduse de un singur moderator. Aceasta deoarece s-a constatat c rezultatele inspeciilor paralele nu sunt, de obicei, convergente. inspecii i revizii etapizate, care urmresc scopuri complexe: - inspeciile Fagan - sunt o combinaie ntre reviziile formale, parcurgerile de cod i inspecii. Aceste inspecii presupun parcurgerea a cinci pai: (1) evaluarea general, n care autorii explic coninutul programelor inspectorilor. De exemplu, pentru o inspecie pe codul surs, n aceast etap se vor examina i explica documentaia de proiectare a programelor, precum i logica general a acestora; (2) pregtirea, n timpul creia inspectorii studiaz produsul i documentaia asociat; (3) inspecia -ntlnire controlat de un moderator care, la rndul su, desemneaz o persoan ce va ghida inspectorii ntr-o examinare detaliat, linie cu linie a produsului, pentru cutarea erorilor; (4) corectarea erorilor sesizate la inspecie. n urma parcurgerii pasului anterior inspectorii vor elabora un raport cu erorile depistate, ce va fi nmnat autorului n vederea efecturii coreciilor; (5) revizia final, n care se verific modul de corectare a erorilor semnalate n raport. - inspecia fazat, sau pe faze - este proiectat astfel nct s asigure rigurozitatea, elasticitatea i eficiena metodei n utilizarea resurselor precum i posibilitatea de a fi automatizat. Metoda presupune efectuarea unei serii de inspecii pariale 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 nct fiecare faz s poat prezuma existena caracteristicilor verificate n fazele anterioare. La rndul lor

61

fazele pot fi efectuate de un singur inspector sau de mai muli inspectori. Fazele efectuate de un singur inspector reprezint procese riguroase i rigide, ce constau n verificarea unor liste de cerine definite fr ambiguitate (check lists). Produsul nu poate trece de aceast faz a inspectrii pn nu ndeplinete toate cerinele menionate n listele respective. n fazele care sunt efectuate de mai muli inspectori se inspecteaz i se verific acele caracteristici i proprieti ale unui produs software care nu pot fi surprinse de seturi de ntrebri precise, cu rspunsuri de tip da/nu, independente de aplicaie. ntr-o astfel de situaie inspectorii din echip examineaz produsul n mod independent, conform unor proceduri structurate clar i apoi are loc ntlnirea acestora, n care se compar rezultatele individuale. Acest tip de faz este n esen un proces Delphi. Inspectorilor nu li se furnizeaz alte informaii legate de produs i de realizarea acestuia, n afara celor disponibile n documentaii. Listele de cerine (check lists) utilizate pot fi specifice aplicaiei (n cazul fazelor executate de un inspector), specifice domeniului aplicaiei i liste cu cerine de ambele tipuri (n cazul fazelor efectuate de mai muli inspectori). Listele de cerine specifice domeniului ndreapt eforturile inspectorului ctre zonele mai dificile ale domeniului respectiv, pe c|nd listele specifice aplicaiei sunt proiectate s foreze o examinare exhaustiv a produsului de ctre inspector. De exemplu, ntro inspecie a codului surs, n lista de cerine se pot genera periodic ntrebri de tipul: "La ce folosete aceast instruciune?" sau "Pentru ce este utilizat aceast structur de date?", cu o rat fix, stabilit la mia de linii de cod surs. Modul cum se rspunde la aceste ntrebri ne arat dac inspectorul a verificat poriunea de cod respectiv i a neles suficient de bine produsul. Rspunsuri incorecte repetate la aceste tipuri de ntrebri 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 informaie este esenial pentru a asigura mentenabilitatea produsului. Inspecia pe faze, prezentat n [KNI1], elimin un important neajuns al celorlalte metode. Astfel, dei metodele de inspecie i revizie amintite sunt benefice n sens statistic, aplicarea nici uneia dintre acestea nu poate evalua mulumitor msura sau nivelul unei caracteristici sau unui subsistem de caracteristici de calitate ale unui produs software. Dei managerii de proiect sunt n unanimitate de acord c aplicarea inspeciilor i reviziilor mbuntete nivelul general de calitate al produselor organizaiilor productoare, acetia ar dori ca, pe baza rezultatelor inspeciilor, s poat fi n msur s fac predicii 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 urmtoarele condiii:

62

1. s existe garania c metoda de inspectare se poate aplica riguros, astfel nct rezultatele s fie specifice fiecrui produs particular i, n acelai timp, repetabile la nivelul aceluiai produs; 2. s fie flexibil, s poat servi unor scopuri complexe (nu numai unei simple detectri a erorilor nainte de faza de testare); 3. s fie conceput astfel nct o mare parte a muncii s poat fi fcut automat, resursele umane s fie utilizate numai atunci cnd este imperios necesar; 4. s fie eficient, astfel nct, cu un anumit volum de resurse, s se poat obine rezultate maximale. Cu toate acestea, orict de fiabil sau riguroas ar fi inspecia calitii, dac nu este eficient din punct de vedere al costurilor, metoda nu va fi aplicat. Aa cum se recunoate n [KNI1], disponibilitatea metodei din punctul de vedere al costurilor este imposibil de modelat analitic ntrun mod convingtor. Acest lucru poate fi obinut numai prin experimentri la scara produselor software industriale, opernd n mediul industrial, efectund experimente multiple de aceeai natur, pentru a permite estimarea variaiei statistice i comparaii la scara de 1/1 cu alte medode. Aceste experimente sunt imposibile fr investirea unor resurse substaniale, de-a lungul mai multor ani. n acest context, este puin probabil ca o organizaie productoare de software de nivel industrial s susin o asemenea investiie, att timp ct nu exist suficiente dovezi c metoda este fezabil nu numai ntr-un mediu academic. Dar, dei experimentele academice izolate nu pot produce rezultate semnificative i concluzive, pot oferi indicaii empirice bune asupra utilitii relative a inspeciilor calitii. n [WEI1] G. Weinberg d cteva sfaturi demne de luat n seam, pentru cei care conduc inspecii ale calitii produselor software. Acetia sunt sftuii: - s ia cele mai radicale (pesimiste) decizii - fapt care va determina managementul organizaiei s ia n calcul cu seriozitate argumentele pesimiste ale inspectorilor; - s asculte cu atenie diferenele de opinii - dac un singur inspector nu reuete s neleag n ntregime produsul, atunci trebuie reconsiderat problema dac productorul produs sale; - s observe cu atenie reacia inspectorilor la semnarea listelor de control sau a celorlalte documente ale inspeciei - fiecare inspector poart responsabilitatea a ceea ce a fcut, eventualele ezitri pot ridica ntrebri asupra calitii muncii inspectorului, sau asupra rezervelor pe care acesta le poate avea fa de produsul inspectat; a creat un inspectabil (vizibil, inteligibil, stabil) cu implicaiile de rigoare asupra mentenabilitii

63

- s remarce problemele care se redeschid mereu (subiectul discuiilor care nu se mai termin) - dac inspectorii fac ncercri s redeschid discuia asupra unor probleme clasate, sau asupra crora s-a luat deja o decizie, acest lucru indic faptul c exist rezerve. Dei inspeciile sunt metode de gestiune i management al calitii orientate ctre produs, faptul c toi participanii la inspecii i mbuntesc, n timp, ntr-un mod sau altul, abilitile personale (profesionale, de comunicare, de conducere) efectul major al acestora se va reflecta, pe termen mai lung, asupra calitii proceselor.

3.6. Auditul calitii software

Cererea din ce n ce mai mare de produse software performante i cu preuri 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 locaii geografice diferite, astfel c, n toate cazurile, complexitatea produselor se reflect i n complexitatea proceselor de dezvoltare. Acest lucru a generat nevoia ca productorii i beneficiarii de software s doreasc o confirmare, de la o entitate independent, c produsul dezvoltat este congruent cu cerinele, posed nivelul dorit de calitate i este improbabil s aib un comportament aberant. Ca urmare, s-a dezvoltat auditul calitii, ca tehnic prin care o entitate independent examineaz fie produsul software (auditul produsului), fie procesul generator (auditul proceselor). Aa cum se arat n [BRY1] auditul software are cte ceva de oferit fiecrui participant: utilizatorul este asigurat c produsul ndeplinete nevoile sale operaionale i de performan, cumprtorul este asigurat c produsul va fi livrat la timp i n limitele bugetului alocat, iar productorul este asigurat c produsul s-a dezvoltat ntr-o manier trasabil, fiind deci mentenabil, i va fi acceptat de utilizator i cumprtor. Costul auditului este preul pe care utilizatorul, cumprtorul i productorul trebuie s-1 plteasc pentru a-i reduce riscurile. Indiferent de modelul de ciclu de via al procesului de dezvoltare software, la sfritul fiecrui proces, stadiu sau etap, exist un interval de timp (o platform) n care "se trage linia", procedndu-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 sfritul fiecrui proces, stadiu sau etap de dezvoltare software, obiectivele propuse la nceput s-au atins, i n ce msur. Verificrile succesive desfurate 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 ndeplinete obiectivele specificate n cerine. Pentru a fi

64

efectiv i a putea preveni disfunciile generate de modificarea cerinelor de la o etap la alta, validarea trebuie efectuat la sfritul fiecrei etape. Astfel, validrile succesive traseaz conformana ntre produsul software rezultat dup fiecare stadiu de dezvoltare i elementele coninute n cerine care trebuie ndeplinite n stadiile respective. Verificarea i validarea, combinate i repetate, alctuiesc modele de proceduri pentru auditarea software. Oricare ar fi modelul de procedur adoptat, scopurile auditrii sunt creterea vizibilitii produselor sau proceselor software i stabilirea trasabilitii de-a lungul ciclului de via. De asemenea, auditul face vizibil pentru manageri, stadiul curent i nivelul de calitate al produsului software, permind evaluarea integritii 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 nelege: determinarea clar a prilor constitutive ale produsului software; determinarea clar a relaiilor dintre aceste pri; atribuirea unei etichete sau unui nume unic i sugestiv fiecrei pri constitutive; descrierea grafic sau tabelar a prilor i relaiilor dintre ele.

Prile constitutive al unui produs software, n orice stadiu de dezvoltare s-ar afla, sunt elementele de configuraie software. Identificarea constituie i o premiz important a comunicaiei informaiei privind trasabilitatea. Astfel, ca rezultat al verificrii i validrii, se poate construi un tabel sau o matrice a trasabilitii care s indice corespondena dintre un element de configuraie dintr-un anumit stadiu i elementele de configuraie corespondente din celelalte stadii de dezvoltare, sau dintre acesta i "reflectarea" sa n specificaii. n tabelul 3.3 se prezint o succesiune de pai, constituii ntr-un model de auditare de software, ntr-un anumit stadiu din ciclul de via, n viziunea autorilor [BRY1 ]. Tabelul 3.3. 1. Examinarea Motivaia parcurgerii acestui pas: deseori, cumprtorul/utilizatorul nu specificaiilor cerinelor i cunoate dect vag nevoile vis-a-vis de un produs software i nu este fa de produs capabil, de prima dat, s articuleze complet, necontradictoriu i fr ambiguiti aceste nevoi n scris. Examinarea specificaiilor scoate n eviden omisiunile i ambiguitile. Chiar dac aceste probleme nu sunt rezolvate pe loc, examinarea preliminar face vizibile lucrurile care se pot transforma n probleme cheie.

65

2. Verificarea asigurrii calitii.

n sens restrns, asigurarea calitii poate fi privit ca asigurarea conformanei produsului, n format, coninut i metodologie cu standardele prescrise. Acest pas const n verificarea conformitii produsului cu standarde specificate (guvernamentale, industriale, interne, comerciale, profesionale, etc), prescrise de managerii proiectului sau de utilizator. Determinarea elementelor de configuraie, a relaiilor dintre ele, asignarea de denumiri i etichete elementelor de configuraie ce constituie produsul, descrierea sugestiv a acestora, aa cum s-a artat mai sus. Se execut comparnd coninutul textual i grafic al unor seciuni, cu coninutul altor seciuni ale documentaiei. Sunt nregistrate inconsistene, ambiguiti, omisiuni, adugri sau modificri nepotrivite ale scopurilor sau nivelelor de detaliere.

3. Identificarea produsului

4. Examinarea claritii, completitudinii, consistenei interne si testabilittii.

Dac nu exist o etap anterioar, acest pas nu este executat. Corelarea 5. Produsul este elementelor de configuraie identificate n stadiul prezent cu elementele verificat prin din care au evoluat. Compararea elementelor de configuraie corelate se comparaie cu etapa face n vederea verificrii dac scopurile i sarcinile etapei anterioare au anterioar din ciclul fost atinse n produs. Discrepanele sunt comparate cu cele identificate su deviat. n audituri anterioare, cu alte comentarii conexe (ale utilizatorilor, cumprtorilor sau cu cele aprute n diferinte edine de analiz ale productorului), cu cele reieite din rapoartele de stadiu ale configuraiei. Sunt identificate discrepanele nou aprute, fa de cele cunoscute. Se mai examineaz n acest pas i rezoluiile puse pentru soluionarea discrepanelor identificate deja. 6. Elaborarea Se execut cnd software-ul auditat este o actualizare a unui produs rapoartelor de stadiu al software auditat anterior. Procesul const n compararea elementelor de configuraiei configuraie identificate n stadiul prezent cu cele identificate n acelai stadiu al produsului anterior, pentru a determina ce elemente de configuraie au fost modificate, terse sau adugate. Aceste modificri, tergeri i adugri sunt comparate cu lista modificrilor aprobate n acelai stadiu al produsului anterior, i sunt nregistrate diferenele. Alctuirea listei modificrilor este obligaia managementului configuraiei. Lista de modificri este aprobat n procesul controlului configuraiei. 7. Validarea Elementele de configuraie ale produsului auditat sunt corelate cu conformanei cu elementele de configuraie identificate n specificaii. Acesta este un pas specificaiile de cerine din procesul de creare a matricei trasabilitii. Elementele de configuraie identificate corelate sunt comparate pentru a verifica modul n care au fost satisfcute cerinele prevzute n specificaii. 8. Evaluarea identificate Evaluarea se bazeaz pe cele observate i nregistrate i neconcordanelor i elaborarea raportului trebuie s fie obiectiv. n baza experienei lor, auditorii formuleaz final concluzii bazate pe tipul, numrul, natura i complexitatea discrepanelor identificate.

66

n Anexa 3 A se prezint un model de structur al raportului de audit, aa cum a fost propus n [BRY1]. Aceti pai sunt aplicabili n toate etapele pe care le parcurge un produs de-a lungul ciclului su de via. Auditul este executat n dou situaii: n procesul de dezvoltare care conduce la crearea unui nou produs software, i cnd produsul software este modificat. Auditarea software este parte a unui proces complex, i anume procesul de control al configuraiei (al crui model propus n [BRY1] este prezentat n Anexa 3B). Controlul procesului este un element al managementului configuraiei. Relaiile dintre auditul software, procesul de control al configuraiei i managementul configuraiei, sunt cele din figura 3.15. Auditul este o activitate profesionist i independent, deci, din echipa de audit fac parte persoane cu pregtire i experien de nalt nivel, membri ai unor organizaii independente i profesioniste (firme de audit, institute de cercetare, agenii guvernamentale sau neguvernamentale specializate, etc). Echipa de auditori, prin poziia sa independent, ofer o garanie suplimentar asupra obiectivittii auditului. Din componena echipei de audit pot face parte i manageri ai firmei, manageri ai proiectului i persoane din comisia de control al configuraiei. Aceste persoane i pot aduce contribuia la proces, fr a realiza auditarea. Figura 3.15.

Managementul configuraiei
Control configuraie vers. 1 Audit Control configuraie vers. 2 Audit versiunea Control configuraie vers. n Audit versiunea

Resursele alocate auditrii trebuie s fie proporionale cu dimensiunea i complexitatea efortului de dezvoltare. n evaluarea complexitii software, se au n vedere numrul de componente ce interacioneaz, complexitatea logic a acestora, numrul i experiena persoanelor implicate n proiectare i dezvoltare, dar i alte elemente mai "delicate", precum numrul estimat de iteraii la un stadiu de dezvoltare sau numrul anticipat de modificri ale proiectelor.

67

4. Abordarea managerial orientat pe raportul cost - calitate

4.1. Costul calitii software - definire, coninut i propunere de clasificaie
Conform [BAR04], costul calitii, ca parte a costului de elaborare a produsului software, reprezint expresia bneasc a consumurilor de resurse, determinate de realizarea unui anumit nivel al caracteristicilor de calitate, sau de mbuntire a acestora. Cteva condiii necesare, dar nu i suficiente, pentru a garanta atingerea unui nivel de calitate dorit (cerut, previzionat), sunt: - existena i funcionarea unui sistem al calitii cu proceduri standardizate, cunoscute i verificate n timp; - o cunoatere i evaluare realist a cerinelor beneficiarilor, a posibilitilor i resurselor productorului astfel nct s se proiecteze pentru produsul software un nivel de calitate care s ndeplineasc cumulativ dou cerine: s asigure acceptarea fr rezerve a produsului de ctre beneficiar i s poat fi atins respectivul nivel de calitate, cu ncadrarea n resursele planificate ale proiectului, n condiii de eficien economic i cu posibilitatea asigurrii managementului calitii. Prin resursele productorului se nelege ndeobte: - resursele financiare alocate, proprii sau atrase, avnd, o anumit calitate (de exemplu disponibilitatea sumelor de bani, operativitatea i sigurana deschiderii unor acreditive, a unor linii de credit, etc); - cantitatea, calitatea i modul de structurare a resurselor umane (proiectani i programatori cu o anumit experien i deci cu un anumit nivel de salarizare, dimensiunea echipelor de testare i experiena n domeniu, calitatea i numrul personalului echipelor de QA, modul de distribuire ntre procese sau produse - module de produs, documentaie - a personalului mai mult sau mai puin experimentat); - bugetul (portofoliul) de timp i structurarea acestuia ntre procese i produse (ct i modul de alocare a timpului pentru proiectare, codificare, inspecii ale codului, testare). La acest tip de resurse, care sunt caracterizate prin vizibilitate i msurabilitate imediat, se mai pot aduga i alte categorii de resurse, care, dei mai puin vizibile i msurabile, pot afecta n aceeai msur managementul calitii: disponibilitatea beneficiarului de a se implica n realizarea proiectului, precum i experiena acestuia n utilizarea unor sisteme informatice, nivelul general al frustrrilor de diferite naturi ce se pot manifesta la nivelul actorilor implicai, atitudinea managementului, poziia activitii de informatic n obiectivele organizaiei, etc.

68

Productorii 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. Dei modelele ce se vor prezenta n subcapitolul 4.3. au la baz elemente ale activitii cu ajutorul crora se poate comensura costul efectiv al calitii pe procese sau faze de dezvoltare, datele ce se culeg din contabilitate inspir cea mai mare ncredere pentru managementul organizaiei productoare de software. Dificultatea evidenierii costului calitii const n faptul c munca de cuantificare a acestor costuri este dificil. Din aceast cauz, separarea acestor costuri i inerea unei evidee analitice separate (sub aspectul evidenei contabile, pe conturi analitice) este o problem de apreciere colectiv, a compartimentelor de contabilitate, asigurarea calitii, a compartimentelor de dezvoltare, testare, precum i a managementului. Cu toate acestea, datele privind costurile calitii nu se pot extrage n totalitate direct din contabilitate, ele putnd fi determinate pe trei ci: colectarea din documente primare, nscrierea sumelor n conturi analitice, calcule simple, utilizndu-se chei de repartizare. Aa 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 calitii". Dei, aa cum s-a artat, exist diferene ntre industriile manufacturiere i proiectele de dezvoltare de software, n ceea ce privete costurile, este relevant recomandarea de clasificai? coninut n standardul ISO 9004-3, [ISO4], pentru cazul produselor rezultate din procese continue (figura 4.1).

Costurile referitoare la calitate

Costurile realizrii calitii

Costurile de asigurare externa a cntai

Costuri de investi

Costuri de defectare (pierderi)

Costuri de prevenire

Costuri de evaluare

Costurile defectrilor interne

Costurile defectrilor externe

Figura 4.1. Costurile referitoare la calitate

69

n standardul menionat, costurile de realizare a calitii reprezentint costurile implicate de realizarea i meninerea nivelului specificat al calitii, iar costurile de asigurare extern a calitii cuprind costurile demonstraiilor i probelor cerute de clieni ca dovezi obiective ale calitii, ale clauzelor speciale i suplimentare de asigurare a calitii, procedurilor, datelor, ncercrilor pentru demonstrare i evaluare.. Costurile privind calitatea produselor software refer un ansamblu de activiti care genereaz cheltuieli ce pot fi grupate n urmtoarele categorii: (a) de prevenire, (b) de evaluare, (c) de identificare i remediere pe parcursul dezvoltrii, (d) de remediere a defectelor (ale non-calitii). 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, funcionarea i mbuntirea sistemului calitii (stabilirea i actualizarea standardelor interne i a procedurilor de calitate); - costuri determinate de audituri ale calitii, de verificarea calitii proiectelor de ansamblu i de detaliu, a documentaiilor intermediare; - costuri legate de constituirea fluxului de control i dirijare a proceselor i produselor n vederea asigurrii calitii; - costuri de evaluare a subcontractanilor, costuri de remediere a unor programe, documentaii, primite de la eventuali subcontractani; - costuri determinate de ridicarea calificrii personalului, de motivarea acestuia, de angajarea unor experi din exterior sau de personal cu calificare superioar; B. Costuri de evaluare - costul unor procese suplimentare de verificare, de exemplu costul inspeciilor pe codul surs, ale auditrii 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 dezvoltrii D. Costurile remedierii defectelor - costuri legate de achiziionarea, testarea, nvarea, exploatarea produselor utilizate n procesul dezvoltrii; - costuri suplimentare aprute n procesul dezvoltrii datorate identificrii i remedierii unor erori la produsele intermediare (erori n proiectare, n codificare, n elaborarea documentaiilor), evideniate, la intrarea i ieirea fiecrui proces, att de compartimentele de QA, ct i de personalul de la dezvoltare software. a. Costuri la productor - costuri suplimentare la finalul procesului de dezvoltare, determinate de remedierea unor erori aprute dup testarea i inspecia de calitate final (consumuri suplimentare de

70

Cauzele defectelor: 1 cauze datorate produselor suport i a produselor primite de la subcontractani; 2 cauze hardware; 3 cauze umane; 4 cauze metodologice (proceduri, tehnologii inadecvate); 5 cauze datorate unui control defectuos; 6 cauze datorate mediului de desfurare a procesului de dezvoltare; 7 cauze manageriale; 8 mentenabilitate redus; 9 marketing defectuos.

timp, curent electric, hrtie, consumabile, trafic suplimentar pe liniile de comunicaie nchiriate, etc.); - costuri suplimentare determinate de repetarea unor teste i verificri; - costuri determinate de nerespectarea eventualelor obligaii contractuale; - costuri privind stingerea reclamaiilor fcute de beneficiari; - costuri suplimentare privind service-ul comercial; - costuri suplimentare determinate de re-pregtirea produsului pentru livrare, b. Costuri la beneficiar - costuri privind remedierea erorilor la produsele reclamate de beneficiari ca necorespunztoare s"au refuzate, n cazul m care recepia se face la acetia (module de program, capitole de documentaie, supori magnetici, etc); - costuri determinate de nlocuirea produselor menionate la aliniatul anterior; - costuri privind testrile, controalele, expertize la produsul ajuns la destinaie i reclamat de beneficiar; - costuri privind activitatea de mentenan n perioada de garanie; - costuri privind stingerea reclamaiilor pentru calitate necorespunztoare fcute de beneficiari, n cazul n care recepia are loc la beneficiar; - costuri determinate de daunele provocate activitii beneficiarului i reclamate de acesta, datorit calitii necorespunztoare a produsului software livrat.

4.2. Raportul cost calitate - cost total

Pe baza modalitatii de clasificaie a costurilor calitii software se poate evalua att raportul dintre costul calitii i costul total (parte - ntreg), ct i efectul costurilor referitoare la calitate asupra performanelor organizaiei productoare de software. Conform analizei prezentate n [0LA1] i innd cont de specificul industriei software i de clasificaia din subcapitolul 4.1., costurile de prevenire i de evaluare sunt considerate costuri de investiii, iar celelalte intr n categoria costurilor de producie sau a cheltuielilor de exploatare. Dac efectul costurilor de investiii 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 productor sau beneficiar, scderea lor va determina direct scderea costurilor de producie sau exploatare, reflectndu-se direct n creterea profitului. n ceea ce privete relaia imediat dintre costul total i costurile de prevenire, creterea acestora va determina cu certitudine creterea costurilor totale, chiar dac este posibil ca, pe termen mai lung, investiiile respective (n sistemul calitii), s conduc la creterea vnzrilor i deci, la maximizarea profitului. Deci, evaluarea efectului lor asupra performanelor financiare ale organizaiei este ngreunat de faptul

71

c acest efect poate fi pus n eviden doar n perioade ulterioare celei corespunztoare exerciiului financiar curent [0LA1]. Cuantumul costurilor de evaluare poate avea un impact dublu. Astfel, pe de o parte, creterea cheltuielilor cu inspeciile i auditurile intermediare se reflect n scderea 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 creterii acestor costuri asupra costului total nu poate determina o cretere direct proporional, ci dimpotriv, poate avea ca efect scderea costului total. n plus, unele costuri referitoare la calitate sunt necuantificabile (acestea, de fapt, nici nu au fost prinse n propunerea de clasificaie prezentat). De exemplu, costul aferent pierderii unui contract, a unui client sau a pieei, ca urmare a vnzrii unui produs necorespunztor calitativ, sau reducerea vnzrilor datorit faptului c, prin calitatea necorespunztoare a produselor, ali productori realizeaz produse similare sau substitueni. De asemenea, n propunerea de clasificaie prezentat, nu au fost incluse costurile de asigurare extern a calitii, aa cum sunt ele prevzute n standardul [ISO4]. Sub aspect conceptual, aceste costuri pot include i cheltuielile generate de participarea la trguri i expoziii, 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 repartiie. Fie urmtoarele notaii: 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 productor i beneficiar (costurile totale de identificare i remediere a erorilor). Aa cum se arat n [COZI] i [0LA1], potrivit abordrii tradiionale a analizei costurilor, referitor la corelaia cost-calitate, pe msura creterii costurilor de prevenire Cp i a costurilor de evaluare Ce, se produce scderea costurilor Cd (figura 4.1). Curba costurilor totale referitoare la calitate admite un minim, iar nivelul calitii corespunztoare zonei haurate (AB) este considerat optim. Se remarc faptul c n zona respectiv Cd Cp+Ce. Zonele de pe grafic din afara zonei optime, reprezint "zona mbuntirilor", respectiv "zona supracalitii" (figura 4.2).

72

Cd

Cp+Ce+Cd

Costuri

Cp+Ce

Cd Cp + Ce

Cost total minim

Nivelul calitii

Figura 4.1. Corelaia cost - calitate

Conform estimrilor din [COZI] i [OLA1], precum i a lucrrilor lui Juran i Gryna, n zona mbuntirilor, 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 cretere relativ mic a costurilor de prevenire i evaluare (a investiiilor), se poate obine o reducere semnificativ a Cd. n zona supracalitii Cd < 40%, iar costurile de prevenire i evaluare au o pondere mai mare de 60%. n aceast zon, conform abordrilor clasice amintite, reducerea Cd presupune costuri din ce n ce mai mari de prevenire i evaluare.

Cd
Curba costurilor totale

Cp+Ce+Cd
Cd Cp + Ce

Zona supracalitii Cd < 40% Cp+ Ce > 60%

Costuri

Zona optim
Zona mbuntirilor Cd>70% Cp+Ce<30%

Cost total minim

Cp+Ce

Nivelul calitii

Figura 4.2. Corelaia cost - calitate

73

n contradicie cu abordarea clasic prezentat mai sus, strategia mbuntirii continue (Kaizen), pe lng faptul c nu implic investiii mari, determin obinerea a dou avantaje: 1. se poate obine creterea nivelului calitii fr eforturi prea mari; 2. aplicnd principiul pailor mici, se asigur o mai mare stabilitate i controlabilitate a proceselor. n figura 4.3. se prezint evoluia costurilor totale minime, conform concepiei mbuntirii continue, iar n figura 4. 4. se prezint efectele mbuntirii prin simplificare (sursa [0LA1]).

Costuri Cd Costuri totale Costul total minim Cp+Ce

Nivelul calitii

100

Figura 4.3.

Costuri Cd Costuri totale Costul total minim Cp+Ce

Nivelul calitii

100

Figura 4.4.

74

4.3. Modele de evaluare a costului calitii software

Pentru evaluarea costului unui produs s-au dezvoltat pn n prezent trei clase de modele: pe baza experienei unor specialiti (audituri, scoruri, evaluri subiective), pe baza modelelor ce folosesc metrica "numr de linii de cod (LOC)" i au forma general: E=A + B x (KLOC)C unde E = efortul estimat n om-luni, A, B i C sunt constante, KLOC = numrul estimat de mii de linii de cod al produsului final. Particularizarea acestor modele const n determinri diferite ale celor trei constante i a unor condiii i restricii. De exemplu, pentru modelul Watson - Felix, A = 5,2, B = 1, C = 0,91, pentru modelul mediu al lui Boehm A = 3, B = 1, C= 1,12, iar pentru modelul Doty, sub condiia KLOC > 9, s-au estimat A = 5,288, B = 1, C = 1,047. O a treia clas de modele utilizeaz n estimarea costurilor analiza pe baza funciilor punctuale. n [MATS1] se prezint modelul Albrecht i Gaffney i modelul Kemerer. Component a costului global (evaluat anterior sau stabilit ulterior), costul calitii ridic numeroase probleme, n special din punctul de vedere al stabilirii elementelor sale de calculaie. n [BARO4] sunt prezentate cinci modele ale costului calitii, fiecare avnd la baz mai multe perspective din care sunt abordate elementele de calculaie. A. Modelul global al costului calitii, care este dat de relaia: CT = C P CE + C D + C A + C F unde Cp reprezint costul prevenirii erorilor, CE reprezint costul identificrii i eliminrii erorilor, CD este costul pentru deservirea tehnic la beneficiar, CA este costul absenei calitii (reprezint cheltuielile de depanare la utilizator, i care provoac pierderi amplificate proporional cu numrul beneficiarilor produsului software afectat de lipsa de calitate), iar C F reprezint cheltuielile suplimentare determinate de ridicarea calificrii personalului, sau utilizarea de personal superior calificat, ceea ce necesit cheltuieli mai mari cu fora de munc. B. Model pentru costul calitii cu luarea n considerare a structurii produsului software. n ipoteza n care variaia componentei j din costul total al calitii pentru modulul i din produs depinde de nivelul complexitii i atunci Cij (t) = ij e
ij ij

, cu i variind de la 1 la N (N = numrul

de module) i j {P, E, F, D, A}, avnd semnificaia de la modelul de mai sus, unde ij i ij sunt parametrii ce se determin prin metoda celor mai mici ptrate. n aceste condiii, costul total al calitii unui produs software avnd n structur N module este:
CT =
N

i+ 1,i P , E , F , D , A

e { }
ij

ij i

75

C. Model probabilistic pentru costul calitii produselor software. Lund n considerare probabilitatea Hk de funcionare a produsului la nivelul planificat U k al caracteristicii de calitate k (k=l, 2, 3, ... , M), unde M reprezint numrul de caracteristici de calitate luate n studiu i CI costul prognozat al ntregului produs software, costul calitii este dat de relaia: CT = CI (1 H k )
k =1 M

unde k sunt coeficieni de elasticitate ai costului iniial,

n funcie de nivelul caracteristicilor de calitate considerate. D. Model de tip continuu asociat costului calitii. Costului calitii i pot fi asociate funcii continue de forma C = f (X 1 X2, ... , Xk), unde k reprezint numrul de caracteristici de calitate considerate, Xk reprezint nivelul caracteristicii de calitate k, iar f este o funcie definit pe D 1 X D2 X... X Dk, cu valori n R+ , Dk, k{l,2, ... , k} fiind domeniul specific metricilor sau msurilor caracteristicii de calitate k. Astfel de abordare permite calcularea unor indicatori ce pun n eviden variaia costului n funcie de variaia fiecrei caracteristici de calitate, indicatori de elasticitate i rate de substituire. Calitatea rezultatelor acestei metode depinde de identificarea ct mai corect a funciei f. E. Model al costului calitii cu ponderi de importan. Pentru un produs software P, destinat unui beneficiar, se contruiete un subsistem de caracteristici de calitate, ordonat pe nivele ierarhice i, folosind un algoritm adecvat, se stabilesc coeficienii de importan ai caracteristicilor. Prin agregare se determin un indicator care exprim nivelul de calitate al produsului P, dup relaia:

Q( P ) = pi ( P ) i ( N iP )
i =1

n( P )

unde n(P) reprezint numrul caracteristicilor de calitate luate n considerare pentru produsul P, pi(P) este coeficientul de importan al caracteristicii i, pentru produsul P, rezultat din structura
P ierarhic, N i este nivelul estimat al caracteristicii de calitate i pentru programul P i i este

funcia prin care se atribuie fiecrui nivel x al caracteristicii de calitate i un punctaj, definit astfel: i(x) : [ ai, bi ] [ d, e ], unde i=1,2,..., n(P) iar a, b, e, d R+ . Definirea corect a limitelor [d, e], ca i actualizarea permanent a limitei standardelor [a j, bj] permit exprimarea fidel sub form valoric a eforturilor fcute n direcia sporirii calitii i dimensionarea acestor eforturi n limitele economicitii.

76

4.4. Managementul calitii pe baz de costuri

Orientarea managerial spre strategia axat pe costurile calitii exprim, conform [NICI], intenia firmei de accepta alocarea de resurse financiare activitilor implicate n realizarea calitii ct i de a controla nivelul de reducere a profitului datorat cheltuielilor cauzate de nlturarea defectelor. n cadrul acestei strategii se vor cuprinde: structura costurilor calitii, nivelul cheltuielilor pe fiecare categorie de cost, raportul dintre costurile calitii i indicatorii de exprimare a eficienei economice. Prin strategia axat pe costurile calitii, firma are posibilitatea de: - a determina msurile de mbuntire n domeniul calitii, pornind de la structura cheltuielilor componente ale costurilor calitii; - a crea cadrul informaional necesar analizei calitii, pornind de la nivelul cheltuielilor legate de calitate; - a ncadra cheltuielile din structura costurilor calitii n zona optim a mbuntirilor, astfel nct raportul dintre efect i efort s exprime orientarea firmei spre pstrarea sau creterea nivelului calitii software; - a considera modelul economic al activitii de asigurare a calitii (QA) ca rezultat al modificrilot structurii costurilor calitii. n lucrarea sa "Quality is free", Philip Crosby, vicepreedinte i director pentru calitate al I.T.T. - S.U.A. i iniiatorul conceptului "zero defecte", afirm c motivaia mbuntirii calitii debuteaz ntotdeauna cu un studiu asupra "costurilor calitii". Dac gestiunea calitii pe baza costurilor presupune ca activitate principal compararea valoric a costurilor cu efectele economico-financiare ale calitii sau mbuntirii sale, concretizate de obicei prin creterea vnzrilor produsului, prelungirea contractelor post-garanie, noi comenzi, etc, esena managementului calitii pe baz de costuri cost de fapt n realizarea echilibrului esenial ntre costuri i valoare. n [WEI1], se arat c orice organizaie n criz, trebuie s se decid dac i va orienta eforturile n direcia costurilor sau a valorii produselor sale. Dac organizaia se orienteaz, sub presiune, ctre msurarea i analiza costurilor, aceasta este o dovad de "lips de curaj", de nencredere n valoarea produselor sale. Dac, n schimb, organizaia i va ndrepta analiza asupra valorii produselor (msurnd satistacia clienilor sau valoarea afacerilor), este un semn c organizaia este focalizat asupra perspectivei sale iar membri acesteia sunt ncreztori n valoarea lor i a produselor lor. n consecin, msurarea i analiza costurilor nu poate duce dect la reducerea costurilor sau la modificarea structurii acestora, pe cnd msurarea i analiza valorii conduce la creterea valorii. Costurile se ncadreaz n limite fixe, comensurate n elemente contabile, bugete, etc, pe cnd creterea valorii este nelimitat.

77

Valoarea produselor difer n funcie de persoanele care o percep. Elementul primordial n nelegerea valorii const n identificarea celor interesai n percepia acesteia: grupuri de persoane "luate n consideraie" atunci cnd se realizeaz proiectul software. Aceste grupuri includ i persoanele pentru care organizaia dorete ca ridicarea nivelului valoric al produselor sale s aib valoare negativ: firmele i organizaiile concurente. Pot exista un mare numr de cauze pentru care o organizaie eueaz sub aspectul calitii. De la un moment dat, toate aceste cauze interacioneaz ntr-o manier care nu mai permite ierarhizarea lor n cauze majore sau minore ale eecului. Cu alte cuvinte, eecul calitii este o problem de sistem. Trebuie avut deci n vedere gsirea echilibrului ntre costuri i valoare, echilibru ce trebuie asigurat referindu-se la fiecare caracteristic a calitii, nu la calitate la modul general. Dei, aa cum s-a mai artat n aceast lucrare, dac factorii calitii se pot determina cu precizie, factorii care influeneaz valoarea calitii sunt mai greu de sesizat i, mai ales, de comensurat [SOA1]. Astfel, dei se recunoate faptul c unii factori, cum sunt reputaia calitii sau bunvoina clientului, au o importan mare, metodele actuale pentru evaluarea acestora sunt primitive. Managementul i gestiunea calitii software pe baza costurilor i, mai ales, a costurilor privind calitatea, are ca premize necesare: determinarea costurilor tuturor activitilor, iar pentru costurile calitii, determinarea ntreinerea, costurilor costurilor funcionarea externe pe care le incumb implementarea, i mbuntirea sistemului calitii, precum i a

privind asigurarea calitii (reclam, publicitate,

demonstraii, participri la trguri i expoziii, etc); identificarea posibilitilor de mbuntire, a "pailor mici", privind costurile referitoare la calitate; elaborarea unei baze de date precum i a unui grafic de urmrire sau tablou de bord al evoluiei tendinelor pe care le nregistreaz costurile privind calitatea. Ca instrumente principale n realizarea gestiunii i managementului calitii pe baza costurilor referitoare la calitate, sunt analiza costurilor i bilanul calitii. Analiza costurilor referitoare la calitatea software, poate fi abordat pe baza unor algoritmi particularizai, n funcie de tipul organizaiei productoare de software, a tipului de software pe care l produce, a modului cum i-a organizat modelul ciclului de via i sistemul calitii [TRI1], [TRI2], [TRI3]. n tabele 4.2 i 4.3 de mai jos, se prezint dou modaliti de abordare a analizei costurilor.

78

Tabelul 4.2

ETAP

CONINUT

I. Calculul costurilor "evitabile" Calculul costurilor privind remedierea erorilor n timpul privind calitatea procesului de dezvoltare, a costurilor privind remedierea erorilor la productor i beneficiar, precum i partea din costurile de evaluare care provin din cheltuielile suplimentare ocazionate de remedierea pe loc a unor erori.

II. Se analizeaz posibile varinate a) exist o problem major privind mbuntirea decizionale calitii referitoare la proiect ? b) amploarea programului de mbuntiri, sau stabilirea, n mare, a "pailor mruni" c) stabilirea prioritilor n atacarea problemelor III. Activiti finale Se calculeaz indicatori, se nregistreaz rezultatele obinute, se actualizeaz baza de date a calitii. Tabelul 4.3

O alt modalitate de abordare a analizei costurilor poate fi:.

ETAPE
I. Calculul cheltuielilor pentru diagnosticare

CONINUT
Cheltuielile de diagnosticare includ cheltuielile cu personalul care face investigaia (angajai, colaboratori, auditori, inspectori), cheltuielile privind participarea conducerii organizaiei la diagnosticare, pregtire documentaii, listri de materiale, ore-calculator suplimentare, alte lucrri suplimentare impuse. Include costul achiziionrii de noi instrumente software suport, implementarea de noi metode, modificarea unor procese, upgrade-uri ale sistemelor de calcul, cheltuieli n ore-om pentru remedieri, etc. Cheltuielile fcute i cele implicate de modificarea proiectelor i documentaiilor de ansamblu, de detaliu, de programare, etc. CONINUT Cheltuielile implicate de re-inspectri i re- auditri. prevzut Eficiena investiiei sau a programului de remediere se calculeaz ca un raport ntre economiile realizate, preconizate sau beneficiile estimate i costul programului de remediere.

II. Calculul costurilor remedierilor

III. Calculul cheltuielilor datorate modificrilor n proiecte i documentaii ETAPE IV. Cheltuieli necesare meninerii noului nivel V. Se calculeaz eficiena investiiilor fcute

Anumite costuri se pot calcula direct, pe baza unor documente justificative (state de plat, facturi, etc), iar alte trebuie estimate, utiliznd preri ale actorilor implicai, sau tehnici de grup (brainstorming, Delphi). Un instrument util n gestionarea calitii, dei controversat sub aspect conceptual, este bilanul calitii [COZI]. Aceast form de bilan nu trebuie s fie confundat cu bilanul contabil

79

propriu-zis. Bilanul calitii este un bilan care se ntocmete pe baza culegerii, repartizrii sau chiar estimrii unor date, rezultate n urma calculrii unor indicatori sau culese din anumite conturi, pe cnd bilanul contabil se ntocmete pe baza rulajelor i soldurilor rezultate din conturi i reflectate n balana de verificare, constituind o oglind a ntregii situaii patrimoniale. Activul bilanului contabil reflect situaia patrimonial sub forma sa concret (cheltuieli, mijloace fixe, mrfuri, etc), iar pasivul reflect acelai patrimoniu sub forma surselor de provenien (capitaluri, credite). Pasivul bilanului calitii reflect ansamblul cheltuielilor determinate de deficienele produselor la beneficiari (costurile lipsei de calitate), iar activul reflect cheltuielile efectuate pentru obinerea unei caliti superioare (costurile calitii), diminuate cu economiile realizabile prin eliminarea deficienelor calitative. Cnd pasivul bilanului calitii este mai mare, atunci diferena se cuprinde n activ sub denumirea de depiri ale costurilor privind lipsa de calitate, iar cnd pasivul este mai mic, diferena reprezint reducerea costurilor privind lipsa de calitate. Avnd n vedere realizarea unui asemenea instrument, se pot calcula o serie de indici utili pentru managementul proiectului, n special pentru gestiunea calitii acestuia, astfel: indicele costului prevenirii defectelor: Costul prevenirii defectelor Valoarea veniturilor din vnzri indicele costului identificrii i remedierii defectelor n etapa de dezvoltare: I C I R D = indicele costului remedierii defectelor la productor: I C R D P = indicele costului remedierii defectelor la beneficiar: I C Costul remedierii defectelor la beneficiar Costul remedierii defectelor la productor Valoarea veniturilor din vnzri Costul identificrii si remedierii defectelor Valoarea veniturilor din vnzri

80

R D B =

Valoarea veniturilor din vnzri

n mod normal, ICIRD = ICRDP + ICRDB, iar o bun gestiune a calitii presupune ca ICRDP > ICRDB, aspect reflectat i n reducerea costurilor de mentenan. indicele costului total al calitii: I C T C = Costul total al calitii Valoarea veniturilor din vnzri

Modificarea structurii costurilor calitii, implic, n final, schimbri la toate nivelele: personal, retribuire, pregtire, metode, proceduri. Aceste schimbri pot fi benefice, inutile, sau chiar pot nruti situaia organizaiei. n managementul modern exist metode de aproximare a impactului schimbrilor asupra valorii i costurilor, cum ar fi metoda examinrii detaliate a cazului (Detailed Impact Case Method), sau metoda celui mai mare beneficiu unic (Single Greatest Benefit Method), prezentate n [WEI1]. Aceste metode se bazeaz pe tehnici de grup (brainstorming, Delphi).

81

5. Abordarea managerial orientat spre utilizator

5.1. Conceptul de software corespunztor pentru utilizare
Potrivit abordrii calitii prin prisma intereselor utilizatorului, calitatea produsului reprezint aptitudinea de a fi corespunztor pentru utilizare. Conceptul "fitness for use", a fost dezvoltat de profesorul american de origine romn J.M. Juran nc de la nceputul anilor '50, cnd iniiaz i coordoneaz cursurile de perfecionare a lucrtorilor din industria japonez, sub deviza "calitatea este o problem a tuturor" [OLA1]. Fiecare client are preferine individuale, care pot fi satisfcute prin caracteristici de calitate diferite. Aceast relaie se reflect din ce n ce mai puternic n industria de software. Astfel, alturi de unii factori ai caracteristicii de flexibilitate, se afirm tot mai mult posibilitatea de personalizare a produselor software, ca o caracteristic de calitate tot mai apreciat. Pentru satisfacerea cerinelor, este important ca relaia calitate-cumprtor s fie mai puternic reflectat nu numai n definirea calitii, dar i n managementul i gestiunea acesteia, deoarece cumprtorul hotrte, n final, ce este calitatea. Astfel, specificaiile, ca reflectri ale cerinelor identificate i definite ale beneficiarilor, nu reprezint criterii de calitate absolute, ci numai mijloace necesare pentru satisfacerea ateptrilor. n cazul managementului total al calitii, relaia client-furnizor este generalizat prin internalizarea ei n cadrul. Trecerea de la un proces la altul, de la o etap la alta, este abordat conform principiului "next process is your customer" - "urmtorul proces este clientul". Cele trei componente ale managementului calitii totale sunt mbuntirea continu; satisfacerea utilizatorilor i avansul organizaiei. Tehnicile manageriale pentru realizarea lor sunt controlul statistic al proceselor (Statistical Process Control-SPC), desfurarea funciilor calitii (Quality Function Deployment-QFD) i explicitarea politicii (Policy Deployment- PD). n tabelul 5.1 se redau elementele acestora, aa cum au fost ele sintetizate n [ZUL1]:

Tabelul 5.1

82

SPC

QFD

PD

Ce ? nume controlul desfurarea desfurarea politicii statistic al funciilor calitii proceselor alias mbuntirea inginerie planificare strategic calitii concurent/ proceselor simultan focalizare optimizare integrare aliniere vertical orizontal tip management management management strategic zilnic funcional De ce ? rezolvare satisfacerea ndeplinirea probleme i clienilor (a obiectivelor Sesizare nvinge strategice (asigurarea oportuniti de concurena, a supravieuirii pe mbuntire avea slujb) termen lung Cnd ? zilnic, continuu n timpul n timpul planificrii dezvoltrii i strategice i de-a mentenanei lungul anului fiscal Unde ? n tot ceea ce se n ntregul proiect n ntreaga ntreprinde organizaie Cine ? indivizi, echipe echipe de proiect toi managerii i CTC, QA, multi-funcionale, subordonaii lor cercuri calitate, software echipe proiect engineering Cum ? instrumente diagrame diagrame de diagrame de afiniti, de baz Pareto, grafice, afiniti, de relaii, de relaii, ierarhice, histograme, ierarhice, de de preceden, diagrame cauzpreceden, matrici, scheme de efect, diagrame matrici, scheme decizie control de decizie concepte variaie, orientare valoare, orientare viziune, orientat ctre ctre proces, ctre client, luarea sistem, diagnoz, implicarea tuturor, n considerare a cascada obiectivelor stratificare, tuturor celor .tnphcai, calitate ^ i intelor, focalizarea standard.zare ,i prioritilor, prevenire, ateptata, normala i ; -L focalizarea asupra supra-calitate, sistematic, vizibil i prioritilor, focalizarea asupra bazat pe fapte sistematic, vizibil prioritilor, i bazat pe fapte sistematic, vizibil i bazat pe fapte

106

83

5.2. Sistem de metrici din perspectiva utilizatorului de software

Din perspectiva utilizatorului, un nivel sczut al calitii este asociat direct cu anumite pierderi (bani, productivitate, timp, sau alte resurse). Pierderile sunt legate, implicit sau explicit, cu metricile de calitate software. Abordarea pornete de la principiul c nivelul necorespunztor al calitii i costurile, sunt legate organic. Pentru utilizatorii obinuii, care nu sunt implicai n procesele de dezvoltare software (proiectare, codificare, testare, mentenan, etc), nivelul calitii se apreciaz pe baza costurilor de nvare, de documentare i de executare corect a diferitelor sarcini i operaii. Din punctul de vedere al marketingului, distincia dintre caracteristicile de calitate (respectiv metricile) abordate de productorul de software i cele luate n considerare de utilizator, are o importan capital. Astfel, consumul de resurse al productorului, fcut pentru a ngloba n cadrul produsului noi faciliti, n cazul n care nu a fost suficient de bine fundamentat, nu va duce n mod necesar la o primire mai bun a produsului pe pia. De exemplu, un produs software poate apare pe pia ntr-o variant considerat de productor mbuntit prin aceea c poate rula pe dou configuraii hardware A i B, i ca atare, produsul poate avea un pre mai mare. Aceast nou facilitate nu aduce un plus de calitate pentru utilizatorul unei configuraii hardware de tip A, deoarece, faptul c versiunile anterioare ale produsului nu rulau pe configuraia B nu reprezenta un cost adiional pentru el. Aceast nou facilitate (portabilitate mbuntit) are semnificaie numai pentru productor deoarece, aparent, lrgete piaa produsului adugndu-i nc un segment, respectiv utilizatorii de configuraii hardware B. Lrgirea pieei poate fi doar aparent, deoarece, printr-o eventual cretere de pre s-ar putea nregistra scderi ale vnzrilor pe piaa configuraiei A. Astfel, ceea ce, virtual, se poate ctiga pe un segment de pia (B), se poate pierde pe altul (A). Pentru managerul de proiect responsabil cu mentenana sau cu dezvoltarea de noi versiuni care s sporeasc funcionalitatea sau portabilitatea unui produs software, modularitatea codului surs este mai important dect calitatea manualelor de prezentare i utilizare, dar pentru utilizatorul obinuit acest raport se inverseaz. n definirea metricilor i msurilor este important s se aib n permanen n vedere populaia int, respectiv clienii produsului software n cauz. n [KH01] se prezint un model intuitiv de metric, potrivit percepiei utilizatorilor obinuii. Modelul a fost mbuntit n acest material prin includerea unor noi ipoteze. nelegem prin utilizatori obinuii clienii ce cumpr produse software de pe pia, fr a fi implicai n procesul de dezvoltare. Se consider un produs software care poate executa I funcii de prelucrare. Se presupune c produsul nu conine erori. Fie L costurile de nvare-familiarizare a utilizatorului cu produsul

84

respectiv. L se va compune din L = Li , unde Li este costul nvrii funciei de prelucrare i.

i =1

Cheltuielile de nvare includ costurile unor cursuri i/sau cheltuiala de timp necesar pentru a aduce utilizatorul n stadiul de a fi gata s utilizeze produsul. n acest stadiu acesta nu mai are nevoie de o instrucie susinut ci, numai ocazional, va apela singur la manualele de utilizare. Fie ri timpul mediu pe care utilizatorul l mai dedic studierii manualelor produsului n stadiul n care este gata s utilizeze produsul, pentru executarea funciei de prelucrare i. Dac mai considerm ti timpul de execuie a funciei i wi valoarea unitii de timp (salariul orar sau pe minut), costurile datorate referirii manualelor i executrii funciei de prelucrare vor fi (r i + ti)*wi. Pentru multe din funciile de prelucrare r i = 0, deoarece acestea se vor utiliza att de des nct vor deveni automatisme. De asemenea, pentru executarea funciei i mai apar cheltuielile cu utilizarea resurselor de calcul. Fie aceste cheltuieli pentru executarea funciei de prelucrare i, hi. Dac adugm i costurile de nvare pentru aceast funcie de prelucrare, atunci obinem Li + (ri + ti)*wi + hi, care reprezint costul asociat unei singure rulri a funciei de prelucrare i. Costul total al executrii funciei de prelucrare va depinde de frecvena cu care este executat aceasta. Fie aceast frecven rij. Atunci costurile asociate unei funcii de prelucrare de-a lungul vieii produsului software, vor fi: Ci = Li + [(ri + ti)*wi + hi] *ni
I I I

(5.2.1.)

Pentru ntregul produs software, aceste costuri vor fi:

Ci = Li + [ ( ri + ti ) wi + hi ] ni
i =1 i =1 i =1

Dac notm cu L0 costurile achiziionrii produsului, precum i cele necesare unor eventuale modificri ale configuraiei sistemelor de calcul n vederea rulrii acestuia, vom avea costul total (5.2.2.): C = L0 + Li + [ ( ri + t i ) wi + hi ] ni = Li + [ ( ri + t i ) wi + hi ] ni (5.2.2.)
i =1 i =1 i=0 i =1 I I I I

Dac renunm acum la ipoteza c produsul nu are erori sau bug-uri, atunci domeniul funciilor de prelucrare poate fi mprit n trei partiii: 1. domeniul i1 grupeaz funciile de prelucrare ce se execut fr erori; 2. domeniul i2 grupeaz funciile de prelucrare ce nu pot fi executate direct de produs, dar pentru care exist ci "alternative", ocolitoare, n cadrul sau n afara produsului (evident mai "costisitoare"), prin care funciile respective pot fi totui executate; 3. domeniul i3 ce grupeaz funciile de prelucrare ce nu pot fi executate deloc, din cauz c, fie nu au fost prevzute la proiectarea produsului (erori la definirea cerinelor sau la

85

proiectare), fie codul respectiv conine erori sau bug-uri (erori la codificare ce nu au fost rezolvate n fazele de inspecie pe cod sau testare). n aceast ipotez, noul domeniu al funciilor de prelucrare va deveni I I, iar I= i1+i2. Costurile pentru executarea funciilor de prelucrare din subdomeniile i 1 i i2 se pot calcula folosind ecuaia 5.2.1. n cazul subdomeniului i2 semnificaia variabilelor nu se mai pstreaz n totalitate. Astfel, r; va avea o accepiune mai larg, incluznd i alte referine (nu numai manualele produsului), cum ar fi manualele sistemului de operare, spre exemplu. De asemenea, L ; nu va mai putea include numai costurile de nvare ale produsului respectiv, ci i costurile necesare nsuirii unor cunotine suplimentare pentru a putea rezolva funciile de prelucrare din domeniul i 2 (cunotine de sisteme de operare, reele, programare, etc). Este posibil ca existena i dimensiunea subdomeniului i2 s duc la limitarea tipurilor de utilizatori ce pot utiliza produsul n totalitatea sa. n ceea ce privete evaluarea costurilor la utilizator induse de inexistena unor funcii de prelucrare grupate n subdomeniul i3, aceasta nu mai poate fi fcut pe baza relaiei 5.2.1. Problemele importante apar la delimitarea subdomeniului, care nu poate fi fcut dect subiectiv, prin analizarea produselor similare de pe pia, a cerinelor utilizatorilor produsului respectiv care nu-i gsesc reflectarea n acesta, precum i pe baza evalurii utilizatorilor mai experimentai. Unele funcii din subdomeniu care sunt strict necesare, probabil vor fi executate manual, sau prin tot felul de modaliti (programe adiionale), executate de cele mai multe ori "artizanal" i disponibile sub diferite forme (de exemplu programe shareware disponibile pe INTERNET). Dup delimitarea i3, pentru fiecare funcie de prelucrare de aici se va stabili un cost subiectiv, reflectnd insatisfacia utilizatorului sau cheltuielile fcute pentru a realiza totui unele din aceste funcii. Aceste costuri (ale insatisfaciei) vor penaliza costul total al produsului. Oricum, dimensiunea domeniilor i2 i i3 este determinant pentru succesul produsului pe pia. Modelul prezentat mai sus poate fi utilizat att pentru testare ct i pentru orientarea activitii de mbuntire a produsului. Pentru faza de testare, pe baza costurilor determinate ale fiecrei funcii de prelucrare, a frecvenelor de utilizare estimate ale fiecrei funcii i a unor coeficieni de importan asociai fiecrei funcii de prelucrare, se poate aprecia viabilitatea produsului. Astfel, cu ct importana i frecvena de utilizare a unei funcii este mai mare, cu att productorul de software trebuie s-i concentreze eforturile n direcia reducerii costului acesteia. Pe aceast baz pot fi orientate i planurile de testare.

86

n ceea ce privete activitile de mbuntire a produsului, trebuie efectuat o analiz a costului utilizrii produsului, pe elemente sale componente:
I

L 0,

Li ,
i =1

t
i =1

* wi * ni ,

rii * wi * ni , i
i =1

h * n
i =1 i

De exemplu, o valoare mare pentru

r
i =1

ii

* wi * ni indic faptul c documentaia produsului

nu este scris adecvat, sau, o valoare mare a rularea produsului sunt prea costisitoare.

h * n
i =1 i

indic faptul c cerinele hardware pentru

Modelul de mai sus se bazeaz strict pe considerente economice (un limbaj bine neles de orice fel de manager) i poate fi utilizat n etape diferite ale ciclului de via al produsului software. Schimbnd perspectiva din care sunt privii utilizatorii prin fixarea ntr-un mediu contractual, un produs software de calitate nseamn ca acesta s ndeplineasc toate cerinele specificate ale utilizatorului, s ruleze ntr-o manier fiabil, s fie livrat la timp i s se ncadreze n limitele bugetului alocat de client. Dac ne referim la proiecte mari, critice pentru utilizator, (acesta fiind interesat n realizarea produsului), se constat c acest gen de clieni (agenii guvernamentale, armat, mari companii, bnci, etc.) se implic, cu eforturi substaniale, n asistarea productorilor de software, n identificarea i ncercrile de a controla riscurile ce pot determina nerealizarea, sau realizarea n condiii necorespunztoare a proiectului. Conform [H0N1], n S.U.A., unde la nceputurile anilor '90 numai Departamentul Aprrii cheltuia aproximativ 15 milioane $/an pentru achiziionarea de software de pe pia, iar cheltuielile generale cu produsele software creteau cu o rat de 12% pe an, a aprut, la clienii importani, un ansamblu de metode i tehnici focalizate pe managementul achiziionrii de software sau asigurrii calitii la cumprtor. Programele menionate sunt ndreptate de regul n direcia asigurrii transparenei i controlului asupra procesului de dezvoltare software. Tot n aceast idee au aprut o serie de standarde departamentale, naionale sau internaionale. Departamentul Aprrii al S.U.A. a dezvoltat standardele DOD 2167/2168, s-au dezvoltat numeroase standarde de firm, naionale i ale unor organizaii internaionale (standardele NATO), I.S.O. a dezvoltat standardele din seria 9000, iar cu referire direct la software - ISO 9000-3, ISO/IEC 9126. Dedicat produciei de software, standardul ISO 9000-3 [IS02J, descrie, la modul cel mai general, ntr-un virtual mediu contractual, o serie de cerine pentru crearea unui sistem al calitii,

87

structurate n dou mari grupe de activiti: activiti de-a lungul ciclului de via i activiti suport, prezentate n tabelul 5.2.

Tabelul 5.2. Activiti de-a lungul ciclului de via revizuirea contractului; specificaia cerinelor beneficiarului planificarea dezvoltrii; planificarera calitii; proiectarea i implementarea; testarea i validarea; acceptarea; multiplicarea, livrarea i instalarea; mentenana Activiti suport managementul configuraiei; controlul documentelor; nregistrrile calitii; msurtorile regulile, practicile i conveniile; instrumente i tehnici; controlul subcontractanilor; evaluarea software inclus, de la subcontractani; pregtirea personalului.

Esena unui asemenea sistem al calitii const n faptul c, la nivelul organizaiei, trebuie stabilite scopuri i responsabiliti concrete referitoare la calitate; pentru fiecare activitate desfurat trebuie s existe definite i documentate proceduri; tot ceea ce se execut trebuie s aib o reflectare n documentaie i nregistrri; toi angajaii trebuie s cunoasc sistemul calitii, s-i cunoasc obligaiile i procedurile la care particip. n urma apariiei acestor standarde, au aprut i s-au diversificat organizaiile de certificare conform standardelor ISO 9000 [TEO3]. Aceast certificare vizeaz asigurarea clienilor c la productorul respectiv exist i fiincioneaz efectiv un sistem al calitii. Certificarea nu asigur clientul c produsele software livrate sunt de o anumit calitate. Pentru asigurarea unei transparene a procesului de dezvoltare software, s-au creat metrici ca "timpul n care o etap atinge stadiul de a-i livra produsul intermediar urmtoarei etape", "numrul de cereri de aciuni corective", "gradul de acoperire prin inspecii", .a., metrici ce identific i traseaz msura n care principiile asigurrii calitii sunt aplicate produselor software livrate. Existena i certificarea unui sistem al calitii, dei nu ofer garaniile de calitate necesare, tinde s devin tot mai mult un avantaj concurenial pe pia. n opoziie cu modelul descris n prima parte a acestui subcapitol, pentru anumite categorii de produse software i anumite categorii de beneficiari, cumprtorii i asigur monitorizarea productorilor, dezvoltarea n comun de metrici i sisteme de metrici, solicit existena unei certificri a sistemului calitii la productori, pentru a se asigura c acetia sunt angajai n minimizarea numrului i severitii defectelor din procesul de dezvoltare, n mbuntirea

88

performanelor operaionale i a suportului acordat produselor precum i n respectarea condiiilor de calitate, a termenelor de livrare i a sumelor prevzute n contracte.

89

6. Restructurri i tendine n dezvoltarea de software, cu implicaii n managementul calitii

6.1. Calitatea software i protecia consumatorilor
ntr-un articol recent aprut n revista Byte, Harrison Forbes, preedinte al companiilor T&C Consulting i VP Operations for Piranha Business Systems se ntreba de ce Departamentul Justiiei Statelor Unite este, n prezent, n proces cu firma Microsoft i de ce utilizatorii nu au pornit de la bun nceput procese dup procese pentru proasta calitate a unora dintre produsele acestei firme. ntradevr, ce poate spune orice firm productoare de software despre calitatea produselor proprii, cnd pe pachetele celei mai mari firme de software din lume se afl inscripionat: "din momentul deschiderii cutiei v asumai ntreaga responsabilitate pentru acest produs i nu vei putea intenta proces fabricantului dac produsul nu corespunde scopului pentru care l-ai cumprat". Deja este ndeobte cunoscut faptul c, pe piaa de software, nimeni, cu o brum de raiune, n-ar trebui s cumpere nici o versiune 1.0 de produs, dac se ateapt la performane decente din partea produsului. Aa cum realitatea o dovedete, n S.U.A., unde piaa de software are o cu totul alt dimensiune, varietate i maturitate, fa de piaa european, n ciuda avertismentului aberant c produsul software poate s nu corespund scopului pentru care a fost realizat, beneficiarii au nceput s se sature i o mulime de furnizori de software i ofertani de servicii au fost dai n judecat pentru violare de contract. Comunitatea beneficiarilor americani de produse software a reacionat prompt cnd, n 1996, la Denver, la o ntlnire a unui comitet de juriti, sponsorizat de Conferina Naional a Reprezentanilor asupra Uniformizrii Legilor Statale (NCCUSL - National Conference of Commissioners on Uniform State Laws) i American Law Institute (ALT), s-a prezentat proiectul unui nou articol (2B), care urma s fie adugat Codului comercial federal american (Uniform Commercial Code - UCC). Dup adoptarea sa, acest articol devine reglementarea legal principal n materie de calitate software n S.U.A. Proiectul arat c analiza costurilor este un instrument cheie n efortul de mbuntire a calitii. Specialitii calitii (quality engineers) acioneaz n direcia minimizrii costurilor totale ale calitii, deoarece este mai ieftin s se previn, s se identifice i s se rezolve problemele aprute, dect s se fac fa consecinelor contractuale i juridice ale livrrii unui produs cu deficiene calitative. Proiectul articolului 2B coninea unele elemente de protecie a clientului, dar modifica balana drepturilor pe care textul original al Codului comercial american uniformizat (federal) o prevedea

90

ntre vnztor i cumprtor, prin reducerea substanial a expunerii la repercusiuni legale a vnztorului de software cu probleme calitative. Acest fapt a condus, inevitabil, la modificarea raportului cost-calitate. Companiile americane vor cheltui mai puini bani dect cheltuiesc n prezent pentru prevenirea, identificarea i remedierea erorilor, deoarece costul livrrii de software cu deficiene calitative (prin suportarea consecinelor legale), s-a redus. Elementele adiionale referitoare la calitatea software din Articolul 2B, favorabile clienilor, se concretizeaz n detalierea i clarificarea situaiei contractuale a: tranzaciilor comerciale electronice (vnzrile fcute prin Internet): se stabilete un set de reguli pentru contractele de servicii on line, comenzi, livrare, furnizare informaii, autentificarea comenzilor de livrare electronice i tranzacii prin intermediul unor ageni electronici. Acest set de reguli nu dicteaz detalii tehnologice dar stabilete principiile pe baza crora se poate decide legalitatea contractului ncheiat; un cadru general unificat pentru licenierea informaiilor: stabilete clar obiectul licenierii informaiilor, ca fiind toate tipurile de informaii, indiferent de modul de memorare, de la discurile laser pn la materialele tradiionale tiprite; licena de pia (mass-market license): prin licena de pia se nelege dreptul cumprtorului de a utiliza software sau alte informaii. O licen de pia este o licen standard, nenegociabil, de care beneficiaz, de exemplu, cumprtorul unui produs software. Licena de pia nu face diferena ntre bunurile de consum, cumprate pentru uz personal i cele utilizate n cadrul unei afaceri (de exemplu un editor de texte), tratnd orice cumprtor de software ca beneficiar al licenei de pia. Problemele care apar pentru cumprtorul de software sunt, de obicei legate de garania productorului. Conform legii americane, n orice vnzare de bunuri, inclusiv produse software, trebuie s existe o garanie expres (explicit) a vnztorului. Garania expres const n afirmaiile productorului despre produs, care sunt incluse n procesul de negociere a vnzrii. Prin legea american, n orice vnzare de bunuri, exist i garania implicit (mercantil). Aceast garanie const n obligaia implicit a vnztorului ca produsul s fie utilizabil pentru scopurile generale pentru care produsele din genul respectiv sunt produse i vndute pe pia, i s fie conform cu afirmaiile productorului inscripionate pe cutie. Din punctul de vedere al productorului sau vnztorului, deosebirea ntre garania expres i cea implicit const n faptul c dac garania expres nu poate fi repudiat sau tgduit de productor, garania implicit beneficiaz, din punct de vedere legal, de clauza repudierii evidente (Conspicuous Disclaimer). Astfel, un productor

91

sau vnztor poate evita orice garanie implicit afirmnd, la vnzare, c produsul se ofer "aa cum este" (AS IS -NO WARRANTY), fr garania implicit. Repudierea evident a garaniei implicite este legal doar dac cumprtorul sau beneficiarul produsului ia cunotin de ea, nainte s aib loc vnzarea. Dificultile cumprtorilor sau beneficiarilor de software constau n faptul c, n general, dac reclamaiile asupra produsului, fcute dup consumarea actului vnzrii, nu sunt cuprinse n garania expres i n garania implicit (aceasta din urm fiind destul de greu de definit), ele sunt interpretate ca propuneri de modificare a contractelor de vnzare-cumprare. n general, mai toi productorii de software repudiaz garania implicit (n modul n care s-a artat mai sus), astfel nct cumprtorii s-au obinuit cu acest lucru. Concret, productorul afirm c unbanal procesor de texte pe care l vinde, este posibil s nu ndeplineasc cele mai elementare operaiuni ale procesrii de text, iar acesta nu este responsabil. n termenii analizei proteciei consumatorului, acest lucru nseamn c beneficiarul sau cumprtorul este pe deplin informat asupra termenilor vnzrii i, dac nu este satisfcut, i poate ndrepta atenia asupra altor produse de pe pia, mai convenabile din punctul de vedere al garaniilor oferite. Acest element juridic se interpreteaz ca o ncurajare a competiiei pe pia i a responsabilitii productorilor. Din pcate, realitatea dovedete c lucrurile nu stau chiar aa. Pe pieele nedezvoltate nc, sau n curs de dezvoltare, cum este piaa romneasc de software, aceste probleme nc nici nu s-au ridicat. Pe piaa american, datorit dezvoltrii comerului electronic, unde problema repudierii evidente a garaniei implicite nu a fost nc clarificat din punct de vedere juridic, se fac presiuni deosebite pentru eliminarea acestei cerine, i propunerile pentru Articolul 2B dovedesc n fapt acest lucru. Despgubirea este o alt problem a produselor software care nu ndeplinesc condiiile de calitate stabilite prin clauze contractuale, garanii sau licen de pia. Legea american stabilete c: "daunele pot fi stabilite n mod liber, cu condiia ca, prin administrarea lor, partea vtmat s aib o poziie la fel de bun ca aceea pe care ar fi avut-o dac cealalt parte i-ar fi ndeplinit n totalitate obligaiile". Pentru produsele software, se pot deosebi trei tipuri de despgubiri, aa cum sunt prezentate n tabelul 6.1. Tabelul 6.1. 1. Beneficiul negocierii Vnztorul sau productorul trebuie s plteasc beneficiarului diferena dintre preul de vnzare i preul real al produsului cu deficiene calitative. 2. Despgubiri pentru Vnztorul sau productorul trebuie s plteasc defecte incidentale beneficiarului costul ndeprtrii tuturor efectelor negative ale incidentului datorat lipsei de calitate a produsului. Aceste sume includ costul convorbirilor telefonice cu productorul (pentru anunarea i descrierea incidentului), expedierea produsului ctre vnztor n vederea unei eventuale nlocuiri cu o versiune mai nou, n care au fost

92

eliminate erorile i eventualele diferene de pre. 3. Despgubiri pentru Vnztorul sau productorul trebuie s pltesc beneficiarului sume efecte pe cale de care s acopere pierderile cauzate de erori software (costurile consecin rencrcrii datelor pierdute, orice diminuri ale profitului). Legea american (Articolul 2B din Codul comercial uniformizat), stabilete condiii mult mai uoare pentru productorii de software, n comparaie cu alte tipuri de productori (de autoturisme, de exemplu). Astfel, productorului nu-i este cerut s livreze un program perfect, ci doar unul care, n mod substanial, face ceea ce productorul a promis. Seciunea 2B-620, oblig productorul s elimine neconformitile, doar dac efortul i costul eliminrii acestora nu este disproporionat de mare n comparaie cu efectele neconformitilor la beneficiar i, ri plus, aceast clauz nu se aplic de loc n cazul licenelor de pia. n ceea ce privete garaniile implicite acestea pot fi foarte uor repudiate, astfel c, pentru cea mai mare parte a productorilor, ele sunt inexistente. Repudierea evident a fost rezolvat astfel: cumprtorul cumpr i pltete produsul software i n momentul n care ncepe instalarea, i se afieaz pe ecran o fereastr de "License Agreement" prin care productorul afirm lipsa garaniilor exprese sau implicite pentru produs, i exclude plata oricror daune incidentale sau pe cale de consecin ("incidental or consequential"), oferind cumprtorului dou posibiliti: s accepte termenii nelegerii ("I accept this terms") sau s solicite daune (beneficiul negocierii). n cazul n care cumprtorul solicit daune ("I want a refund"), instalarea produsului se oprete, cumprtorul duce produsul napoi la magazin, unde i se napoiaz preul pltit. n fapt, sunt puini cumprtori care mai duc produsul napoi la magazin, odat ce au nceput instalarea acestuia. n plus acetia nu pot cunoate, din simpla citire a anunului, calitatea sau noncalitatea produsului pe care l-au cumprat. Astfel, se nlocuiete o modalitate de protecie a cumprtorului, puternic i opozabil injustiie, cu o formalitate fr sens. n ceea ce privete asistena tehnic, toate firmele productoare de software ofer linii telefonice la care clienii pot raporta problemele aprute. Dar, sunt cazuri frecvente n care costul acestor convorbiri telefonice poate depi preul produsului, iar dac se ia n calcul c liniile telefonice respective, nchiriate pe baz de contract, sunt taxate suplimentar, productorul nu numai c nu pltete daune pentru lipsa de calitate a produsului su, dar realizeaz i profit din efectuarea convorbirii telefonice. O alt caren legal, remarcat de asociaiile consumatorilor, este excluderea total a despgubirilor pentru efecte pe cale de consecin n cazul licenelor de pia i admiterea acestora n cazul produselor software produse pe baz de contract, doar dac acestea sunt prevzute expres n contract. Un al doilea efect al excluderii acestor despgubiri este c va, determina scderea interesului utilizatorilor pentru nregistrarea i comensurarea acestor efecte, concretizate n pierderi.

93

Dac, nainte de apariia Articolului 2B, un productor de software american trebuia s se gndeasc deosebit de serios la costurile poteniale ale lansrii pe pia a unui produs insuficient testat sau cu deficiene calitative, n condiiile n care clienii puteau s-i opun n justiie toate costurile suplimentare colectate, pe cale de consecin, situaia s-a schimbat esenial n prezent. Prin eliminarea imputabilitii costurilor efectelor pe cale de consecin, un productor poate lansa pe pia, n deplin siguran, produse software cu serioase deficiene calitative. i totui, dac firmele productoare de software nu vor plti daunele provocate, pe cale de consecin, ca efect al livrrii de software cu deficiene calitative, unde se vor acumula aceste costuri? La clieni, desigur, concretizndu-se n pierderi de date, scderi ale vnzrilor, pierderi. Deci, la nivelul economiei americane, unde tehnologia informaiei "face s se mite totul pe pia" companiile productoare de software sunt vital interesate n eliminarea plii acestor tipuri de daune, deoarece, avnd n vedere cuantumul la care se pot ridica, plata acestora le poate duce la faliment.

6.2. Politica produselor software "destul de bune"

Dezvoltate n special prin tehnicile i metodele cercetrii operaionale [BOLI], cutrile unor soluii optime la problemele practice, n special din domeniul economic, fac obiectul, ncepnd cu anii '70, unor critici din ce n ce mai severe din partea specialitilor. Acetia contest conceptul de soluie optim din perspectiv teoretic i practic. Astzi este din ce n ce mai rspndit opinia conform creia metodele cercetrii operaionale, mpreun cu informatica, analiza de sistem i managementul tiinific, ofer soluii bune, avantajoase, incontestabil mai eficiente dect cele obinute prin metode tradiionale. Conceptul de optim ns este folosit cu din ce n ce mai mult pruden [BOLI]. Aa cum se arat n [YOU1], a scrie software de nalt calitate este o provocare, mai ales n prezent, cnd o aplicaie (produs) software, nseamn, de cele mai multe ori o aplicaie client/server, mai multe platforme hardware, mai multe sisteme de operare, etc. n primul rnd, pentru a putea trece la realizarea unui asemenea produs software, trebuie s obinem specificaii realiste, s se dezvolte planuri realiste pentru procesul de dezvoltare, astfel nct s poat fi promovat calitatea software, iar testarea i verificarea s fie riguroase, sensibile i continue. Aceasta n condiiile n care specificaiile complexe se vor metamorfoza n timp, prin influenele exercitate de utilizator, care "i mai aduce aminte de ceva" sau n timpul proiectrii "se trezete la realitate i i d seama ce dorete de fapt", dar i prin influenele exercitate de platform asupra a ceea ce este sau nu este posibil.

94

Pentru suportul activitilor de dezvoltare, n lumea informaticii au aprut n ultima perioad o serie de concepte i unelte, care ncearc s fac viaa mai uoar dezvoltatorilor: middleware (care netezete asperitile lucrului n platforme eterogene), produse de management al configuraiei (care urmresc i ndrum bucile componente, precum i diferitele versiuni), testerele automate (examinatori care pot s simuleze nenumrai utilizatori "mcelrind fr mil" aplicaiile). Aa cum specifica i E. Yourdon n [Y0U1], presiunea pe care munca o exercit asupra potenialilor utilizatori finali ai softului, i determin s pun cerine tot mai stringente proiectanilor de software -chiar dac tiu c resursele limitate puse la dispoziie echipei de dezvoltare nu-i va permite acesteia niciodat s furnizeze ntreaga funcionalitate cerut, la nivelul de calitate specificat, n limitele prevzute de resurse. Pe de alt parte, dezvoltatorii lucreaz nchipuindu-i c utilizatorii vor putea cu adevrat s aib totul, i c problema este doar de a gsi instrumentele i metodele ideale pentru a atinge optimul n analiz, proiectare i programare. Dac nu i se poate oferi utilizatorului final optimul - relativ i controversat - i se poate oferi n schimb o alternativ pragmatic: software-destul-de-bun, adic un compromis realist ntre elementele care formeaz definiia tradiional a calitii software: zero defecte, costuri n limita bugetului, finalizare la termen i satisfacerea preteniilor utilizatorilor n ceea ce privete funcionalitatea. Aceast orientare aprut printre dezvoltatorii de software a intervenit nu numai datorit controversei din jurul a ceea ce nseamn "soluie optim" i "optim", dar i datorit faptului c, la rndul ei, definiia tradiional a calitii software, enunat mai sus, descrie de fapt foarte puine sisteme concrete. Apropierea de cerinele utilizatorului este realizat de noile dezvoltri ale tehnologiei informaiei. Astfel, apariia mediilor de dezvoltare vizuale de nalt productivitate RAD (Rapid Application Development), au fcut posibil aplicarea pe scar larg a metodelor de prototipizare, care dau posibilitatea dezvoltrii rapide de interfee utilizator i prototipuri de aplicaii, ce pot fi rafinate iterativ, pn cnd satisfac cerinele utilizatorilor. Dei prototipizarea este compatibil cu dezvoltarea de software n condiiile actuale, deoarece relaiile dintre defecte, timp, cost i funcionalitate sunt neliniare i aproape inverse, este imposibil pentru echipele de proiectani s prevad intuitiv care este, de exemplu, impactul unei ntrzieri asupra costurilor, defectelor i funcionalitii. Att proiectantul ct i utilizatorul trebuie s se angajeze ntr-o reevaluare dinamic a specificaiilor, deoarece de la o zi la alta se poate constata c: hard-ul se schimb, productorii de instrumente se schimb, reglementrile guvernamentale se schimb, economia se schimb i riscurile afacerii se schimb. n mod obiectiv, sistemele proiectate vor intra n exploatare att cu erori cunoscute, pe care echipa de dezvoltare nu a putut s le elimine, ct i cu erori latente de care dezvoltatorii nu sunt contieni. Un obiectiv realist pentru proiectele

95

complexe, dezvoltate ntr-un mediu dinamic, este s se poat alege n mod contient ce defecte vor fi n produsul final. Chiar mai important, n fazele de nceput ale proiectului, este conceptul de triaj. E. Yourdon specifica: "Douzeci de ani de ntrzieri i depiri de buget ar trebui s ne nvee c preteniile clienilor notrii depesc limitele rezonabilului i c nu le putem ndeplini pe toate. Dect s ateptm pn n ziua dinaintea predrii pentru a decide care pri ale proiectului funcioneaz i care nu, mai bine s tranm aceast problem chiar de la nceput". Clientului trebuie s i se pun de la nceput ntrebrile: Care dintre cerine sunt eseniale (adic fr de care sistemul este inutilizabil)? Care dintre cerine sunt importante (adic fr ele sistemul va fi dificil de utilizat)? Care dintre cerine sunt opionale (fac sistemul amuzant i interesant, dar nu reprezint cerine eseniale sau importante) ? Ca urmare, o activitate plasat naintea analizei detaliate i a modelrii, trebuie s fie administrarea cerinelor. Cum atributele se schimb n mod dinamic pe parcursul proiectului, instrumentele de administrare a cerinelor dau asigurarea c echipa rmne concentrat pe cerinele obligatorii, tar a fi distras de caracteristicile care nu sunt eseniale, ce trebuie sacrificate, pentru a putea furniza ceva destul-de-bun. Dei inginerii software tradiionaliti resping conceptul de "software-aestul-de-bun" ca fiind o apologie a mediocritii, n realitate, ntr-o lume dinamic i cu resurse finite, toate metodele ingineriei software impun compromisuri raionale explicite.

6.3. Noile standarde i produse ale reelei globale

a) Internaionalizare i localizare Aproape tot ce se ntmpl acum n lumea produselor software este legat de Internet, pentru Internet sau accesibil din Internet. n consecin, Java s-a transformat dintr-un limbaj de programare ntr-o coleciie de tehnologii pentru Internet. Pn i firme cu puternice influene ale sistemelor proprietar, motenite de la mainframe-uri, cum este Oracle, adopt standarde deschise. Astfel, versiunea de administrare a bazelor de date Oracle8I ofer dezvoltatorilor de aplicaii posibilitatea de a folosi att limbajul propriu Oracle (PL/SQL), ct i Java. Tehnologia Java mbogete sistemul dezvoltrii de produse software, cu dou noi procese, specifice: internaionalizarea i localizarea [LAS2]. Internaionalizarea este procesul de proiectare a unei aplicaii astfel nct s poat fi adaptat diferitelor limbi i regiuni geografice, fr a fi nevoie de intervenia programatorului. Calitatea procesului de internaionalizare depinde de tehnicile utilizate n structurarea programului i de utilizarea facilitilor oferite de bibliotecile de funcii.

96

Un produs software internaionalizat trebuie s aib caracteristicile prevzute n tabelul 6.2.

Tabelul 6.2. textele afiate de program sunt n limba dorit de utilizator elementele de tip text, cum sunt etichetele componentelor grafice, mesajele, nu sunt ascunse n program. Acestea se pstreaz n afara programului i sunt citite n mod dinamic. acelai cod executabil ruleaz peste tot, trebuie adugate doar informaiile specifice zonei. suportul pentru o nou limb nu necesit recompilarea programului. informaiile pentru o nou zon geografic (data calendaristic, ora exact, moneda), vor aprea n forma corespunztoare regiunii i limbii utilizatorului.

Localizarea este procesul de adaptare a unui program la o anumit regiune sau limb, prin adugarea componentelor specifice locului i traducerea textelor. Textele sunt pstrate n afara codului i vor fi citite la momentul execuiei, n funcie de locul execuiei. Tipurile de date dependente de regiunea geografic sunt prezentate n tabelul 6.3. Tabelul 6.3. texte numere moneda data i ora se gsesc, pentru a comunica cu utilizatorul, pe butoane, n fiiere de "help", meniuri. Traducerea textelor reprezint partea cea mai costisitoare a localizrii afiarea numerelor difer de la ar la ar. De exemplu, forma punctului zecimal (virgul sau punct). difer att ca simbol ct i ca modalitate de afiare (nainte sau dup numr). difer ca modalitate de afiare i coninut.

imaginile i au semnificaii deosebite n funcie de ri. De exemplu culoarea doliului este n unele ri negru, n altele albul. culorile sunetele dac aplicaia este multimedia, atunci trebuie s "vorbeasc" limba utilizatorului.

126

97

n Java, localizarea se face prin referirea la un obiect de tip Locale, care este un identificator pentru limb, regiune i cultur. Clasele care i modific proprietile conform obiectului Locale, se numesc local-dependente. Identificatorii de limb i ar, care trebuie precizai la crearea unui obiect de acest tip sunt specificai n standardele ISO-639 i ISO-3166. De exemplu, crearea unui asemenea obiect pentru Romnia se face astfel: Locale identificator Joc = new Locale("ro ", "RO "); iar cutarea dinamic a resurselor, pstrate n seturi de resurse ce memoreaz informaiile local-dependente, se face folosind metodele clasei ResourceBundle, astfel: ResourceBundle res ResourceBundle.getBundle("Resurse", identificator Joc); Dei Java arat asemntor cu C++, vzut superficial, limbajul a fost destinat unei utilizri diferite. Acest fapt, aa cum s-a artat n [TEO5], a determinat ca unele caracteristici de calitate i practici ale bunei programri utilizate n limbajele de programare convenionale s fie chiar contraproductive n Java. b) Sisteme deschise, orientare obiect, middleware i arhitectura universal a aplicaiilor Noile arhitecturi ale aplicaiilor trebuie s furnizeze servicii multiplatform, distribuite, cu acces global la resurse, indiferent c acestea se afl n intranet, extranet sau Internet, o arhitectur universal a aplicaiilor, care s asigure deschiderea ctre tendinele viitoare - "future-proof'. Sub aspectul calitii, orientarea ctre "Internet computing" a adus la apariia unui nou concept, ca o parafraz a conceptului "zero defecte": "zero effort networking", concretizat n proiectarea i construirea produselor software astfel nct s poat fi asigurat administrarea centralizat i eficient a aplicaiilor care ruleaz pe reele. Ca urmare, a aprut un nou tip de produs software, denumit n literatura de specialitate middleware. Middleware reprezint software care mediaz ntre o aplicaie i reea, gestionnd interaciunile dintre aplicaii disparate, n platforme eterogene. Cele mai cunoscute astfel de produse software sunt ORB - Object Request Broker, care faciliteaz comunicaia dintre obiecte, sau Distributed COM (anterior cunoscut ca Network OLE), care realizeaz acelai lucru n mediul Windows. Conceptul "Object Oriented", aprut n toate domeniile tehnologiei informaiei (programare, baze de date, proiectare, reele, etc), coroborat cu imperativul ingineriei software de a asigura msurarea i analiza calitii software, precum i de a ncorpora noile valene ale reutilizrii de software aduse de orientarea obiectual, a determinat apariia conceptului de clas i la nivelul metricilor software. Paradigma 00 a produs noi modaliti de abordare a caracteristicilor de calitate. n [BAR2] se prezint rezultatele experimentrii unui limbaj al calitii orientat obiect - Quality Object Oriented Language (QOOL). De exemplu, se poate studia n ce mod funcionalitatea unei subclase afecteaz

98

complexitatea programului. Reliefnd aspectul multidimensional al problemei, se calculeaz, utiliznd metrici specifice, complexitatea claselor i, utiliznd alte metrici, complexitatea metodelor coninute. La nceput, analizarea nivelelor metricilor pentru clase se face separat de analiza metricilor pentru metode. Utiliznd metoda analizei factoriale, se genereaz matricea de trecere n spaiul factorilor (SCOR). Cu ajutorul coeficienilor de scor se vor putea proiecta observaiile n spaiul factorilor, cu dimensiuni mai puine i cu importan relativ cunoscut [TE02]. Creterea complexitii produselor software, ca urmare a adaptrii la tendinele actuale ale pieelor de software (arhitecturi multiple, sisteme deschise, "multi-tier", "multi-threded", interoperabilitate mult crescut), este compensat, ntr-o oarecare msur, prin creterea productivitii i orientarea ctre dezvoltarea de aplicaii de calitate a mediilor de dezvoltare. Astfel, tot mai multe medii de dezvoltare poart specificaii RAP/RAD (Rapid Application Prototyping/Rapid Application Development), specificaii care denot apariia unei clase specifice de caracteristici de calitate, pentru aceste tipuri aparte de produse software. Firmele productoare de software ofer astzi pe pia produse care, din punctul de vedere al calitii, posed caracteristici strategice, cum ar fi: buy, build, both (cumpr, construiete sau amndou), aceasta nsemnnd fie c, clientul poate cumpra o aplicaie "de-a gata", fie cumpr instrumentele de dezvoltare pentru a-i construi singur aplicaia, pentru cerinele proprii; imunitate la timp, ceea ce nseamn c grija fa de parteneri i clieni se concretizeaz n faptul c aplicaiile nu i pierd valoarea n timp. Altfel spus, disponibilitatea firmelor de a asigura suportul, a oferi soluii alternative n vederea asigurrii investiiilor bazate pe tehnologia productorilor respectivi; adaptabilitate la noile tendine (Internet, Java, CORBA, ActiveX), prin fie combin cele dou variante, produsul software oferindu-i posibilitatea de a particulariza aplicaia,

oferirea de soluii de migrare a aplicaiilor ctre o arhitectur universal (UAA Universal Architecture for Applications), o propunere de standard arhitectural deschis, validat deja de specialitii i analitii ctorva firme prestigioase de consultan i analiz de specialitate (Dataquest, IDG, Hurwitz Group, SGP Analyist Services). c) Ecosistemul aplicaiilor ntreprinderii Pentru finalul anilor '90, trstura principal a produselor software cu profil economic este ncadrarea acestora ntr-un ecosistem informatic, condus de pachetele de programe pentru planificarea resurselor ntreprinderii - ERP - Enterprise Resource Planning, sisteme cu influen asupra deciziilor de afaceri i tehnologice, cu rol cheie n reproiectarea proceselor, a alianelor

99

pentru liniile de aprovizionare, restructurarea managementului i iniiative strategice. Alegerea fcut de o organizaie pentru un ERP oarecare, se repercuteaz asupra dezvoltrii aplicaiilor, infrastructurii de reea, a bazelor de date, a suportului informatic pentru luarea deciziilor, precum i a altor decizii tehnologice. Explicaia acestei situaii const n extinderea produselor software ERP din punctele forte deinute n fabricaie i finane la toate aspectele unei firme sau corporaii: resurse umane, vnzri, marketing, asisten pentru beneficiari [SWE1]. Sistemele ERP au evoluat rapid. Dac la nceput companiile americane i vest-europene au implementat sisteme ERP pentru a scpa de dezvoltri proprii, n prezent facilitile oferite de acestea au crescut, astfel c muli utilizatori construiesc acum funcionaliti proprii bazate pe aceste sisteme. Majoritatea aplicaiilor ERP (cele mai cunoscute fiind cele ale firmelor SAP, Oracle, PeopleSoft sau J.D.Edwards) au propriul middleware, unelte de dezvoltare, arhitectur de componente i interfee utilizator. Pentru managementul calitii, asigurarea compatibilitii aplicaiilor software cu profil economic cu unul sau mai multe sisteme ERP, dei poate determina creterea complexitii i a efortului de dezvoltare, devine o decizie strategic, avnd n vedere faptul c aceast nou facilitate determin de multe ori alegerea produselor de ctre cei mai importani beneficiari. Mai mult, pentru realizarea unui transfer de date ct se poate de lin, precum i a unei comuniuni strategice, unele companii americane cer, sau favorizeaz, furnizorii care utilizeaz aceeai tehnologie ERP. d) Open Source Software OSS n jurul zilei de 1 noiembrie 1998, cnd americanii srbtoresc Halloween, pe Internet apare un articol al unui manager de proiect de la firma Microsoft (Vinod Valloppillil http://www.tuxedo.org/~esr/ halloween.html) scris, n mod evident, spre evaluarea celor ce au de luat decizii. Dei firma Microsoft i recunoate autenticitatea, neag faptul c documentul ar reprezenta n vreun fel poziia oficial a firmei n ceea ce privete strategia de urmat [FETI]. Articolul dezbate un concept mai vechi de dezvoltare software ("free software"), prezentat sub o alt denumire (OSS - "open source software"), i mult mai bine definit sub aspect teoretic i practic, i anume ideea surselor deschise i gratuite. Ideea de baz a OSS este foarte simpl. Cnd programatorii pe Internet pot citi, redistribui i modifica codul surs al unui produs software, acesta evolueaz. Utilizatorii l mbuntesc, utilizatorii l adapteaz, utilizatorii elimin erorile. Avnd n vedere rspndirea Internet-ului i numrul de programatori care l acceseaz, acest proces de evoluie poate avea o vitez pe care nu o va atinge niciodat un proces n sistemul tradiional de dezvoltare de software. Comunitatea virtual OSS a nvat c acest proces evolutiv rapid d natere la produse software mai bune dect cele obinute n sistemele nchise tradiionale, cnd doar civa programatori pot vedea sursele i restul lumii trebuie s priveasc un bloc opac de bii.

100

Dincolo de ctigurile n ceea ce privete calitatea, OSS are un avantaj important pentru un client sau beneficiar de software: acesta nu mai este prizonierul unui sistem nchis pentru el. Avnd acces la surse, clientul, dac are capacitatea necesar, poate supravieui colapsului productorului i, n plus, nu mai este la dispoziia fiecrei decizii de modificare a strategiei de dezvoltare a acestuia. Dac suportul post-vnzare al productorului ncepe s devin exorbitant, avnd sursele, clientul poate cumpra suport software mai convenabil de la orice alt firm specializat. Ideea OSS poate fi benefic i pentru organizaii care i dezvolt intern produsele software pentru necesitile proprii, produse software care nu sunt destinate pieei. n astfel de cazuri organizaia depinde de echipa care a dezvoltat produsul, i problema care se pune este ce se ntmpl atunci cnd aceste persoane prsesc organizaia? "Azvrlirea" surselor acestor tipuri de produse software pe Internet i trezirea unui interes minim pentru acestea, n rndul comunitii virtuale, poate oferi organizaiei att soluii, ct i o rezerv de personal familiarizat cu produsul. Firme precum Netscape, au luat deja decizii ndrznee, prin care produse comerciale ale acestora, au devenit produse cu surse fcute publice -OSS. Exist deja produse cu surse publice care sunt mult mai fiabile dect echivalentele lor comerciale - TCP/IP, DNS, send mail, Perl, Apache. Modelul OSS are multe de oferit chiar lumii afacerilor. Aa cum afirma Eric S. Raymond, (http://www.tuxedo.org/~esr/writings/cathedral-bazaar), aceasta poate fi o cale de a produce standarde deschise, conform nivelului i tendinelor software actuale, i nu documente de hrtie, fr valoare practic. Este, totodat, o modalitate de a aduce la colaborare multe firme productoare i programatori individuali, n vederea dezvoltrii de produse software pe care nici unul dintre ei, luai individual, nu le pot produce; este modul cel mai rapid de a rezolva erorile i de a face modificrile cerute de utilizatori. De asemenea, modelul OSS asigur o securitate sporit, deoarece codul este la vederea publicului i va fi expus unor multiple "scotociri", problemele fiind gsite i rezolvate on line, n locul ascunderii acestora, pn cnd persoana nepotrivit le va descoperi i va profita de ele. Dar dintre toate avantajele OSS, cel mai important este creterea fiabilitii. Un produs software nchis, proprietar, nu poate atinge niciodat fiabilitatea unui produs cu surse deschise, care a ajuns la maturitate. Exemplul cel mai edificator este nsi infrastructura Internet-ului, alctuit din produse software cu surse deschise care au demonstrat un nivel de fiabilitate i robustee considerabil, meninut sub presiunea unor schimbri rapide, inclusiv creterea rapid i uria a dimensiunilor Internet-ului. Eris S. Raymond, ilustrnd exemplul Netscape, descrie un nou stil de management pentru dezvoltarea de software - stilul bazar - bazat pe cod surs public (OSS), stil managerial care determin obinerea de produse software superioare din punct de vedere calitativ i al fiabilitii. n definitiv, nu poate exista inspecie sau auditare mai bun dect expunerea codului produsului pe

101

Internet: cu ct mai muli avizai vd codul, cu att mai bine. Acest mod de a mbunti calitatea "colecteaz" mai multe idei dect i poate permite orice firm, indiferent de dimensiune. Tabelul 6.3. Avantajele dezvoltatorilor Creterea vitezei de dezvoltare Creterea fiabilitii Creterea securitii Mai aproape de cerinele Creterea dimensiunii pieei n prezent exist cel puin patru modaliti de a obine profit de pe urma existenei produselor "open source software", a se vedea tabelul 6. 4. Tabelul 6.4. 1. Suport acordat vnztorilor 2. Metoda sacrificrii poziiei de leader 3."Lustruirea mofturilor" firma productoare ofer sursele deschis, dar vinde distribuia, marca i serviciile post-vnzri. pentru produsele software pe care firma nu mai continu dezvoltarea, se ofer sursele liber. pentru o companie productoare de hardware (semiconductoare, plci pentru periferie - video, sunet - etc), produsele software nu sunt elemente de venit ci de costuri, deoarece produsele lor trebuie s aib drivere i elemente de interfa. n consecin, aceste firme fie "culeg" din OSS produsele de care au nevoie, fie ofer, sub form de OSS, drivere i instrumente de interfa, neperfecionate, pentru a evolua Kbe? i apoi pentru a le ngloba, perfecionate, produselor hardware manufacturate. cri, hardware compatibil, sisteme complete cu software cu surse deschise pre-instalat. Avantaje antreprenoriale Cunoaterea informaiilor cu privire la interesul fa de anumite produse. Un concept nou, chiar dac este genial, nu va produce bani dac piaa nu utilizatorilor i de clieni este interesat

4. Vnzarea de accesorii

Cu privire la definirea ct mai exact a OSS: Bruce Perens, de la firma Debian, productorii sistemului de operare Debian/GNU Linux, scrie, n 1997, un document ce conine Contractul pe care firma Debian l propune comunitii i Regulile Debian cu privire la "free software" - produse software cu codul surs distribuit liber - Anexa 6. n decursul anilor 1997 i 1998, acest document a fost de mai multe ori modificat, n special la sugestia dezvoltatorilor de la Debian, i, ulterior, a stat la baza definirii produselor software cu surse deschise - Open Source Software - OSS.

102

7. MANAGEMENTUL CALITII PUNTE DE TRECERE DE LA MANAGEMENTUL INFORMAIONAL LA CEL AL CUNOTINELOR

Ilie Costa, profesor universitar, doctor habilitat, ASEM

Introducere
Accesul managerilor i specialitilor la informaii multidimensionale i cunotine despre toate activitile ntreprinderii i a mediului de afaceri este una dintre cele mai importante condiii pentru asigurarea competitivitii n economia global modern. Generalizarea experienei acumulate n domeniul informatizrii arat c tehnologiile informaionale, sistemele informatice sunt necesare, dar nu i suficiente pentru asigurarea garantat a succesului activitii de baz a organizaiilor. n ultimii ani soluiile problemei n cauz sunt examinate n cadrul unor astfel de domenii tiinifice i practice cum ar fi: managementul informaional (MI), managementul cunotinelor (MC) i managementul calitii (MQ). Dei aceste tipuri de management s-au dezvoltat ca direcii tiinifice i practice aparte, i nu se mai pune la ndoial importana fiecrui din ele n parte, ca condiii necesare pentru asigurarea competitivitii unei ntreprinderi, n ultima perioad de timp au aprut unele publicaii, n care se menioneaz anumite interdependene ntre ele. Aceasta reiese chiar i din faptul c aceste tipuri de management sunt examinate n acelai context ca condiii de asigurare a competitivitii ntreprinderilor. Dar, apar i publicaii care confirm existena unor legturi mai strnse dect cele menionate. Chiar i interdependenele unilaterale dintre oricare dou tipuri de management dintre cele enumerate anterior, studiate n literatura de specialitate, arat c realizarea lor n cadrul aceluiai sistem de management al afacerilor (MA) asigur condiii de sporire a eficienei fiecrui tip de management n parte. Scopul de baz al acestui articol este analiza interdependenelor reciproce active dintre managementul informaional, managementul cunotinelor i managementul calitii n cadrul managementului general al aceleiai ntreprinderi, formnd un model structural integrat al sistemului de management al afacerilor, in care sunt prezente toate aceste tipuri de management. O atenie deosebit va fi acordat verificrii ipotezei conform creia MQ joac un rol important n realizarea interdependenelor dintre MI i MC, care ar avea un efect sinergetic din integrarea lor reciproc.

103

Definiiile noiunilor de baz

Fr a pretinde la o definire a noiunilor informaie, cunotine, MI, MC i MQ mai profund, dect mulimea de definiii diverse cunoscute n mediul de specialitate, vom accentua doar acele aspecte n definiiile existente, care le evideniaz specificul n compararea reciproc i care ar putea influena formele respective de management. n acest context, cele mai caracteristice aspecte ale noiunilor de baz sunt urmtoarele: informaia este rezultatul procesri datelor; cnd informaia se mbin cu contextul i experiena, ea se transform n cunotine. Noiunea de cunotine este mai superioar dect informaia i documentele care o conin. Cunotinele presupun un nivel de implicare uman [1], ele sunt informaia absorbit i neleas de persoan concret. Sunt situaii n care ceea ce pentru o persoan reprezint o informaie pentru alta, cu o alt capacitate sau un alt rol, constituie o cunotin. Diferena dintre informaie i cunotine, ne permite s difereniem diferite niveluri de generalizare a informaiei cuprinse n diapazonul ntre informaie pur i simplu ca date procesate i informaie, care corespunde tuturor cerinelor utilizatorului, fiind absorbit i neleas de persoane concrete n conformitate cu necesitile informaionale reale, n contextul experienei personale [2]. n articolul de fa vom folosi una din cele mai cuprinztoare definiii ale MI, care include practic toate tipurile de activitate informaional ce corespund ntregului diapazon de interpretri cunoscute ale MI [3]: managementul informaional este planificarea, finanarea, organizarea, ncadrarea cu personal, managementul, instruirea n domeniu i controlul informaiei. MI include managementul resurselor informaionale variate, cum ar fi: suporturile informaionale (documente sau medii electronice); departamente care ofer servicii informaionale; sisteme informaionale, att computerizate, ct i tradiionale. Managementul informaional poate fi uor interpretat ca un termen umbrel, ce include aa domenii ca tiina computaional (ce dezvolt instrumentarul de realizare a funciilor), managementul dosarelor, arhivelor i bibliotecilor, precum i managementul resurselor informaionale. MI poate de asemenea s includ telecomunicaiile, managementul datelor, managementul documentelor i informatica n general. Managementul cunotinelor este orice activitate structurat ce duce la sporirea capacitii organizaiei de a dobndi, distribui i utiliza cunotine pentru supravieuirea i succesul su. 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 cunotinelor de afaceri n aa mod ca s fie utilizate efectiv de ctre ntreprindere pentru a efectua aciuni efective i a realiza scopurile sale [4] .

104

n [3] este subliniat scopul i terenul comun al tuturor tipurilor de management: al datelor, informaiei, cunotinelor, nregistrrilor i documentelor - ele toate au acelai obiectiv. n particular, ele tind s gestioneze informaia ntr-un mod, care ar asigura integritatea ei i utilizarea n conformitate cu varietatea scopurilor. Ca proces managementul cunotinelor este ndreptat la managementul nu al documentelor propriu zise, ci al coninutului lor. n acest context autorii [3] menioneaz c managementul cunotinelor nseamn cptarea (colectarea, procurarea, generarea), organizarea (clasificarea, indexarea, trasarea), recuperarea (cutarea, accesarea), distribuirea (mprirea, micarea) i meninerea (curirea, creterea, sporirea, ngrijirea) a coninutului depozitului de date Obiectivele managementului calitii tehnologiilor informaionale i a serviciilor informaionale (MQ) constau n identificarea, analiza i interpretarea tuturor anomaliilor i n definirea aciunilor corective sau de orientare a calitii n toate etapele de realizare a TI i/sau de prestare a serviciilor informaionale.

Interdependene dintre MI, MC i QM

Pentru a nelege rolul fiecrui din tipurile de management n cauz fa de celelalte este necesar de studiat interdependenele dintre ele. Generaliznd rezultatele relevante (dei reprezentnd interdependene unilaterale) din literatura de specialitate, se poate admite ipoteza existenei unor interdependene reciproce dintre toate tipurile de management menionate n cadrul aceluiai sistem de management al afacerilor, care ar avea un efect sinergetic din integrarea lor reciproc. Printre cele mai reprezentative interdependene pot fi evideniate urmtoarele: 1) Interdependena reciproc dinte MI i MC (MI MC) Tot mai frecvent sunt cercetate unele aspecte care confirm dependena managementului cunoaterii de managementul informaional (MI) [2, 5, 6] i de managementul resurselor informaionale [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 nregistrrilor, managementul resurselor informaionale, etc.) este prezentat ca o temelie pentru dezvoltarea MC. Succint putem prezenta aceast dependen a MC de MI n felul urmtor: MCMI. Pe de alt parte, avnd n vedere c cunotinele sunt nite informaii cu proprieti deosebit de importante pentru organizaie, contientizarea tipurilor de cunotine i a rolului lor n organizaie poate fi utilizat pentru concretizarea mai profund a scopurilor i formelor de realizare a MI. O astfel de abordare este o condiie necesar pentru eficientizarea activitilor ce in de MI. Adic, n acest sens exist i o dependen invers dintre MC i MI (MI MC).

105

2) Interdependena reciproc dinte MI i MQ (MI MQ) Exist relaii reciproce foarte puternice ntre TI i servicii informaionale i managementul total al calitii (MTQ), care au fost cercetate nu numai teoretic, dar i practic [9]. IM este un factor foarte esenial de suport al implementrii unui astfel de sistem ca MTQ, care necesit volume mari de informaii. Deci, eficiena MQ depinde n mare msur de nivelul de organizare a MI n organizaia dat (MQ MI). Pe de alt parte, implementarea MTQ n activitile de baz a unei organizaii presupune rspndirea principiilor de MTQ asupra tuturor activitilor, care suport activitile de baz, inclusiv i asupra MI. Totodat, o activitate multidimensional ca MI poate fi eficient organizat doar n condiii de utilizare a elementelor de MQ, care poate fi un mecanism de mbuntire permanent a calitii datelor, soft-ului i informaiilor (MI MQ). 3) Interdependena reciproc dintre MQ i MC (MQ MC) De exemplu, n [7, 9] se menioneaz c, odat ce strategia orientat la calitate depinde de capacitatea capitalului intelectual al organizaiilor de a menine competitivitatea produselor i a serviciilor, iar angajaii n astfel de organizaii trebuie s efectueze activiti bazate pe utilizarea cunotinelor, managementul cunoaterii devine un factor critic pentru succesul activitii companiilor, care utilizeaz sistemul MQ. Deci, n acest context, MQ depinde n mare msur de MC (MQ MC). Pe de alt parte, sunt menionate i dependene inverse dintre MQ i MC. De exemplu, n [8, 5, 6] este analizat influena pozitiv a utilizrii mecanismelor de control al calitii asupra proceselor de baz ale managementului cunotinelor. Reieind din definiia noiunii de cunotine (ca informaie, care corespunde tuturor cerinelor utilizatorului, fiind absorbit i neleas de persoane concrete n conformitate cu necesitile informaionale reale, n contextul experienei personale, adic acele informaii, care corespund anumitor cerine fa de calitate), informaiile rezultative n sistemul informatic pot fi mbuntite permanent n baza unui feedback activ (conexiune invers) susinut de sistemul de management al calitii produselor i serviciilor informaionale. Cu alte cuvinte, utilizarea principiilor de management al calitii fa de MI este o condiie necesar pentru extragerea cunotinelor din fluxurile de informaii asigurate de MI. Deci, MC poate fi n mare msur asigurat de utilizarea MQ fa de procesele de MI n firma dat, ceea ce nseamn c MC depinde de MQ (MCMQ). Astfel, pe deoparte, n firma dat managementul calitii produselor i serviciilor de baz poate fi eficient doar pe baza cunotinelor necesare din domeniu (obinute ca rezultat al unui management al cunoaterii). Pe de alt parte, managementul cunotinelor poate fi mai efectiv, dac este organizat pe baza utilizrii principiilor de management al calitii, folosite fa de MI. Aceasta

106

mrturisete despre interdependena reciproc strns dintre aceste dou tipuri de management. n baza generalizrii celor menionate, putem conclude c exist interdependene reciproce ntre toate cele trei tipuri de management (MI, MQ i MC). Relaiile dintre fiecare din aceste tipuri de management i managementul general, al afacerilor (MA) reies din nsei definiiile lor. Schema general, care reprezint interdependenele reciproce n cauz, este prezentat n figura 7.1. Un rol deosebit n aceast interdependen l joac MQ, care servete n calitate de punte de trecere dintre MI i MC. Folosirea managementului calitii n procesele managementului

Managementul afacerilor (MA)

Managementul cunotinelor (MC)

Managementul informaional (MI) Sistemul informaional managerial (SIM)

Managementul calitii (MQ) TI i serviciilor informaionale

F ig ura 7.1. S chem a interdependenelor dintre diferite form e de m anag em ent: MA, MC , MI (S IM) i MQ
informaional poate transforma MI n temelie sigur pentru managementul cunotinelor. Odat ce fiecare din tipurile enumerate de management contribuie la eficientizarea celorlalte tipuri, putem conclude c un efect maximal al influenei lor la eficiena managementului afacerilor poate fi obinut doar prin realizarea lor n paralel ca subsisteme, care interacioneaz n cadrul aceluiai sistem de management al afacerilor.

107

Concluzii
Dei mai multe forme de management (informaional, al cunoaterii, al calitii tehnologiilor i serviciilor informaionale etc.) se dezvolt n literatura de specialitate ca direcii aparte, la ora actual sunt observate unele elemente de convergen dintre ele. Prin urmare, este necesar studierea mai profund a interdependenelor dintre aceste direcii, cu att mai mult c ele se intersecteaz din punct de vedere a scopului i terenului comun al tipurilor respective de management. Interdependenele reciproce dintre formele de management n cauz, discutate n articolul de fa, sunt generalizate i prezentate ca subsisteme ale sistemului de management al afacerilor. Generaliznd cele menionate n lucrare, putem conclude c un sistem de management al afacerilor, bazat pe o strategie integrat, orientat la MTQ, poate fi eficient cu adevrat doar n condiiile dac realizeaz toate dimensiunile de management (cel informaional, al cunoaterii i al calitii) conjugate ca subsisteme ale unui singur sistem de management al afacerilor cu un scop final comun (figura 7.2). O astfel de abordare a problemei contribuie la sporirea nu numai a eficienei fiecrui tip de management aparte, dar i a efectului sinergetic cauzat de interaciunea lor reciproc n cadrul sistemului de management al firmei.

Organizaia (ntreprinderea)
Managementul afacerilor (MA)
Managementul cunoaterii (MC) Managementul informaional (MI) Managementul calitii TI i SIM

Sisteme informatice manageriale (SIM), Tehnologii informaionale (TI) n managementul afacerilor

Utilizatori externi ai SIM, TI

Managementul total al calitii produselor i serviciilor (MTQ)

Parteneri n schimb de date

Sistemul informatic al managementului total al calitii

Procesul de producere i prestare servicii

Consumatorii de produse i servicii

Figura 7.2. Model structural - funcional al sistemului de management al afacerilor, n care n calitate de subsisteme sunt realizate MI, MC i MQ

108

Bibliografie
1. John T. Phillips. Will KM Alter Information Managers' Roles? Information Management Journal, July 2000, v.34, i.3, p.58 2. Ilie Costa. Managementul informaional: unele tendine ale dezvoltrii. Trends and the Development of the Information and Communication Technologies in Education and Management. International Conference. March 20-21,2003. Chisinau, ASEM, 2003, pp. 14-24 3. Sue Myburgh. The Convergence of Information Technology & Information Management. Information Management Journal, April 2000,v34 i2 p.4. 4. John van den Hoven et al. Information Resource Management: Foundation for Knowledge Management. Information Systems Management, Spring2001, Vol. 18 Issue 2, p80, 4p: 5. Ilie Costa. Managementul informaional integrat temelie pentru managementul cunotinelor. Simpozionul Internaional Integrarea European i competitivitatea Rconomic, 23-24 septembrie, ASEM, 2004. 6. Ilie Costas. Integrated Information Management: Foundation for Knowledge Management. The 30th Annual Congress of the American Romanian Academy of Arts and Sciences (ARA), The Academy of Economic Studies of Moldova, Proceedings. July 5-10, 2005, Central Publishing House, Chisinau, 2005, pp.127-130 7. Kwang K. Lim, Pervaiz K. Ahmed and Mohamed Zairi. Managing for quality through knowledge management. Total Quality Management, July 1999. 8. Carl Gustav Johannsen. Total Quality Management in a Knowledge Management Perspective. Journal of Documentation. Vol.1, January 2000, pp.42-54 9. Khalil Matta, Houn-Gee Chen and Joseph Tama. The information requirements of total quality management. InfoTrac Web: Expanded Academic ASAP. Total Quality Management, August 1998. v.9, i6,p.445.

109

8. ABORDAREA SISTEMIC A PROBLEMEI PREGTIRII CADRELOR N DOMENIUL MANAGEMENTULUI INFORMAIONAL

Ilie Costa, doctor habilitat, profesor universitar

Introducere
Informatica este unul din cele mai dinamice domenii ale tiinei i practicii moderne. Dezvoltarea continu a informaticii condiioneaz modificri respective i n activitile profesionitilor informaticieni. Dei, n linii mari specialitii, care practic diferite activiti cu datele, informaia, cunotinele, nregistrrile i documentele au aceleai obiective (n particular, ei caut s gestioneze informaia ntr-un mod, care ar asigura integritatea si folosirea la o varietate de scopuri), dezvoltarea accelerat a tehnologiilor informaionale (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 informaionale, care dup cum a fost observat n [1], contribuie la apariia noilor profesii, n special ale celor de manageri informaionali. Convergena n mediul cnd totul devine digital, tergnd distinciile dintre documentele tiprite, vizuale, audio- i multimedia, duce la confluena disciplinelor i a activitilor profesionale respective. Din toate acestea rezult c problemele de pregtire a specialitilor n domeniul informaticii, care ar corespunde cerinelor moderne ale societii, trebuie s fie permanent n atenia instituiilor abilitate n domeniu. Scopul comunicrii de fa const n formularea unor probleme ce in de abordarea sistemic a dezvoltrii programelor de studii i de pregtire a specialitilor n domeniul managementului informaional (MI) n conformitate cu necesitile societii informaionale. Crearea unui spaiu informaional unic al societii prezint o problem foarte complex, care nu poate fi soluionat eficient fr un management informaional bine organizat la toate nivelurile de ierarhie supuse informatizrii (ntreprindere, asociaii, subramuri, ramuri ale economiei naionale, societate). Nu ntmpltor managementul informaional a devenit una din cele mai frecvente noiuni utilizate n mediul informaticii. n acelai timp, se observ o mare varietate de abordri ale acestei probleme la nivel naional (inclusiv nivelul micro i macro al societii), internaional i global [1,2]. Aceast situaie este reflectat de diversitatea interpretrilor termenului conceptual managementul informaional: de la nelegerea lui n cel mai ngust sens al cuvntului (ca sinonim al tehnologiei informaionale, uneori nsemnnd doar organizarea datelor n memoria computerului -managementul datelor), pn la cel mai larg sens al MI, care cuprinde practic toate tipurile de activitate informaional. O astfel de varietate de interpretri ale noiunii MI influeneaz n mod direct i formele de realizare a MI, reflectndu-se inclusiv i asupra pregtirii specialitilor n domeniul managementului informaional, unde se observ cam aceeai diversitate de abordri. Simind necesitatea societii, mai multe instituii de nvmnt superior, au nceput s pregteasc cadre n domeniul managementului informaional, dar netiind prea clar, cum ar trebui s fie aceti specialiti i ce ar trebui s cunoasc. n unele universiti sunt predate discipline noi sub denumirea de Management informaional, iar n altele a aprut chiar specializarea n acest domeniu. Dar n majoritatea cazurilor accentul n programele de nvmnt e pus pe unele aspecte foarte nguste ale MI, neglijnd n majoritatea cazurilor competene importante care trebuie s fie formate la respectivii specialiti.

110

n acest context, sunt necesare noi cercetri n teoria i practica mondial n acest domeniu: n pregtirea specialitilor informaticieni, n general, i n pregtirea managerilor informaionali, n particular.

Tendinele de baz n dezvoltarea MI ca factori de influen n formarea specialitii Managementul informaional

Managementul informaional a devenit o problem odat cu apariia societii i a fluxurilor eseniale de informaii. Dar ca domeniu important al tiinei i practicii a nceput s se dezvolte accelerat doar n ultimele 2 decenii n rezultatul dezvoltrii rapide a tehnologiilor informaionale i a modificrii continue i semnificative a profesiilor informaionale respective. Analiza experienei acumulate n domeniu [3,4] ne permite s facem concluzi c pentru asigurarea unui MI eficient este necesar n primul rnd o structurare mai strict a mediului de aplicare, o formulare exact a conceptelor de baz i a corelrii lor reciproce n cadrul sistemului. Cu att mai mult acestea sunt necesare n cazul pregtirii cadrelor n acest domeniu de MI, avnd ca scop asigurarea plenitudinii funcionale a sistemului de management informaional, pe deoparte, i reducerea redundanei nejustificate, pe de alt parte. n [5-7] n baza generalizrii experienei acumulate n domeniul informatizrii societii au fost evideniate urmtoarele direcii de baz ale dezvoltrii MI, care reprezint ambele extreme reprezentative ale diapazonului de interpretri ale acestei noiuni: MI n sensul tehnologic, condiionat de coala informatic, cnd centrul de greutate n sensul MI l au tehnologiile informaionale i sistemele informatice ca instrumentar de soluionare a multor probleme ce in de organizarea fluxurilor informaionale; MI n sensul tradiional al noiunii de management, cnd resursele informaionale sunt tratate ca toate celelalte resurse materiale, energetice, umane etc., iar MI este interpretat din punct de vedere al funciilor de dirijare: planificare, eviden, organizare, etc. n direcia tehnologic a managementului informaional sunt evideniate numeroase subdirecii, principalele dintre ele fiind urmtoarele: Managementul datelor, care include proiectarea, crearea, implementarea i administrarea bazelor de date; Proiectarea, crearea, implementarea i administrarea sistemelor informatice n procesul exploatrii lor; Managementul documentelor, care cuprinde etapele de proiectare, elaborare, exploatare i administrare a sistemelor informatice documentare; Managementul nregistrrilor, orientat la proiectarea, elaborarea i exploatarea sistemelor informatice de organizare i procesare a documentelor care reflect tranzacii economice; Managementul cunotinelor, care include identificarea, acumularea, organizarea i utilizarea cunotinelor n procesele de dirijare. Aria de influen a acestui tip de management informaional n sens tehnologic este prezentat ntr-un ir de lucrri de un model structural funcional integrat (figura 8.1) Tratarea tradiional a MI este mai mult sau mai puin fr contradicii 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 unitile social-economice (USE) de diferite niveluri de ierarhie, ca subsistem care trebuie s creeze condiii optime pentru a contribui la realizarea scopului i produsului final al USE.

111

Managementul Cunotinelor

Managementul Informaional

Fig. 8.1. Modelul structural al managementului informaional

n [6,7] este argumentat necesitatea crerii unui spaiu informaional integrat, care reflect adecvat toate procesele ce au loc n sistemul real, i poate asigura condiii pentru extragerea cunotinelor necesare pentru managementul efectiv al USEPot fi evideniate dou grupe de probleme, care devin actuale n contextul temei abordate:

112

1) probleme de integrare n cadrul fiecrui tip de management. Aici orientarea trebuie s fie la abordarea sistemic, n primul rnd la cuprinderea ciclului ntreg de via a resurselor informaionale (care include toate etapele de la apariia lor pn la trecerea n stare pasiv dup utilizare, de exemplu, n arhive), att n forma electronic, ct i pe supori tradiionali; 2) probleme de integrare ntre nivelurile i tipurile de management referitor la date, informaii, cunotine, documente, arhive (figura 8.1). n ultima perioad de dezvoltare a managementului informaional au nceput s ia amploare unele direcii noi de MI, bazate pe integrarea tipurilor de MI deja existente, cum ar fi: managementul datelor cu managementul documentelor, managementul documentelor cu managementul nregistrrilor. n ultimii 10 ani a nceput s se dezvolte un nou tip de management ( managementul calitii tehnologiilor i serviciilor informaionale ), care se intersecteaz esenial cu soluionarea problemelor MI n sensul larg al cuvntului. Managementul calitii n acest domeniu reprezint un exemplu de convergen a diferitor tipuri de MI, care este bazat pe mbinarea aspectelor caracteristice pentru ambele extreme de interpretare a MI: manageriale i tehnologice.

113

n aceleai lucrri [6,7] este argumentat concluzia c integrarea tuturor formelor de MI bazat pe utilizarea managementului calitii tehnologiilor i serviciilor informaionale este condiia fundamental a dezvoltrii celei mai moderne forme de management informaional: managementul cunotinelor . n mod generalizat cele menionate despre tipurile i direciile 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 pregtirea cadrelor n domeniul MI.

Necesitatea unui cadru de formare profesional n domeniul MI

Din cele menionate mai sus referitor la multidimensionalitatea MI, convergena continu a diferitor tipuri de MI (n sensul tehnologic i tradiional al noiunii) putem conclude c pregtirea cadrelor n acest domeniu este o problem complex i cere o atenie permanent din partea instituiilor de nvmnt superior. n primul rnd, este necesar un cadru general de orientare pentru programele de nvmnt 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 redundanei nejustificate. Managerii informaionali trebuie s aib o viziune larg, bazndu-se pe o abordare sistemic a problemelor complexe[3]. Ei trebuie s aib un spectru mai larg de cunotine care s le permit

Managementul general al USE

Managementul cunotinelor

Managementul informa ional

Managementul informaional n sensul ngust, condi ionat de coala informatic

Managementul informaional n sensul condiionat de coala de management

Tehnologiile informaionale ca instrumentar de soluionare a problemelor ce in de organizarea fluxurilor informaionale

Planificarea, finanarea, organizarea, ncadrarea cu personal, managementul, instruirea n domeniu i controlul informaiei

Managementul datelor, Managementul documentelor, Managementul informaional, Managementul cunotinelor

supor ii informaionali (docum ente, medii electronice); departamente, care ofer servicii informa ionale; sisteme informaionale computerizate i tradi ionale, etc.

Managementul resurselor informaionale:

Managementul calitii n sisteme informatice

Fig. 8.2. Structura conceptual a managementului informaional i al cunotinelor

114

s cuprind mai multe aspecte ale tehnologiilor informaionale, pe de o parte, ale managementului informaional (inclusiv managementul cunotinelor), managementul calitii n sisteme informatice i managementului general (al afacerilor), pe de alt parte. A devenit o problem major pregtirea specialitilor de sistem de nalt calificare, capabili s ndeplineasc individual lucrri complexe viznd elaborarea noilor tehnologii informaionale, a sistemelor informatice ce in de infrastructura informaional de baza a societii. Cel mai acut aspect al acestei probleme este pregtirea managerilor de proiect, de sistem si, n general, a specialitilor n domeniul MI. Activitatea specialitilor informaticieni se desfoar ntr-un mediu foarte dinamic sub influena multiplilor factori care se schimb n permanen. Toate acestea condiioneaz un ir de cerine fa de informaticieni (n special pentru specialitii de sistem) i, respectiv, fa de sistemul de formare a lor. n Academia de Studii Economice a fost acumulat anumit experien n pregtirea cadrelor n domeniul Managementul informaional n cadrul ciclului 1 (licen) i a ciclului 2 (masterat). Avnd n vedere necesitatea acoperirii integrale a dimensiunilor menionate anterior ale domeniul de MI, programul de specializare n MI (ciclul 2-masterat) prevede o orientare a studiilor nu att la acumularea de cunotine concrete (care n mod accelerat se nvechesc), ct la dezvoltarea capacitilor de gndire sistemic i actualizarea permanent a acestora n procesul activitii practice, conform evoluiei progresului tehnico-tiinific n domeniu. Din acest motiv, programul de studii include pe lng disciplinele privind aspectele concrete ale tehnologiilor informaionale (care presupun nsuirea mijloacelor i instrumentarului: afaceri electronice, proiectarea sistemelor informatice, baze de date, reele informatice, tehnologii de procesare, etc., studiate n mare parte la ciclul 1), i discipline orientate la o pregtire teoretic fundamental, la formarea unei culturi profesionale adecvate si a gndirii sistemice, discipline necesare pentru rezolvarea optim a problemelor de informatizare complexe (managementul cunotinelor, managementul calitii produselor i serviciilor informaionale, gestiunea proiectelor informatice etc.), care apar permanent intr-un mediu dinamic (figura 8.3). n acest context, n programul de studii sunt prezente i aa discipline opionale ca: analiza sistemic, cibernetica proceselor economice, inteligena artificial, sisteme suport pentru decizii, etc. Analiznd primele rezultate a celor 2 ani de pregtire a specialitilor n MI, considerm c programul de studii al ASEM ar putea fi pus la baza crerii unui cadru general de orientare pentru programele de nvmnt n domeniu pentru alte universiti din Moldova

115

MI de nivel superior Managementul cunotinelor Managementul calitii produselor i serviciilor informatice (supuse managementului informaional)

Managementul informaional
MI aspecte traditionale i mixte: Gestiunea proiectelor informatice Economia serviciilor informatice Gestiunea securitii informatice MI aspecte tehnologice: Sisteme informatice financiar-contabile Afaceri electronice ndeplinirea i susinerea tezei de masterat, etc.

Instrumentare de realizare a MI i MC: Tehnologii avansate de reea 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.

Grupa de discipline opionale: Teoria sistemelor, Programarea ERP, Cibernetica proceselor economice, Limbaje de modelare, Inteligen artificial, Sisteme suport pentru decizii, Integrarea aplicaiilor Windows, Fiabilitatea sistemelor informatice, etc.

Figura 8.3. Structura programului de formare profesional n domeniul MI

Concluzii
Din cercetrile efectuate [3-7] i din experiena acumulat n Academia de Studii Economice din Moldova pot fi extrase unele concluzii, principalele dintre care sunt urmtoarele: 1) Programele de nvmnt orientate la formarea specialitilor n domeniul managementului informaional trebuie s aib la temelie o abordare sistemic a problemei. La baza trebuie s fie sistematizarea activitilor informaionale la toate nivelurile de ierarhie n societate i generalizarea celor mai moderne teorii i experiene acumulate n informatic; 2) Este necesar elaborarea unui cadru naional de formare profesional a specialitilor n managementul informaional, n care ar fi determinat conceptul de management informaional, dat descrierea specialitii i reglementate disciplinele (unitile de cursuri) obligatorii n programele respective de studii; 3) Avnd n vedere dinamismul accelerat al informaticii, pentru perfecionarea sistemului de pregtire a specialitilor n domeniu sunt necesare: efectuarea permanent a cercetrilor impactului schimbrilor n domeniul tehnologiilor informaionale asupra specialitilor informatice;

116

perfecionarea curriculum-urilor specialitilor informaionale (i nu numai) n contextul dezvoltrii Societii Informaionale.

Bibliografie 1. Sue Myburgh. The Convergence of Information Technology & Information Management Journal, April 2000,v34 i2 p4 Information Management.

2. Brent Gallupe; Felix B. Tan. A Research Manifesto for Global Information Management. Journal of Global Information Management, July-Sept 1999 v7 i3 p5. R. 3. Ilie Costas. Convergena diferitor tipuri de management informaional i unele probleme ale sistemului de educaie n domeniul informaticii. tiina, Businessul, Societatea: Evoluii i intercorelri n condiiile integrrii n spaiul economic european / Conferin Internaional, 12-14 februarie, 2004, vol.1, Chiinau, 2004, pp.14-19. 4. Ilie Costas, Pavel Chirev, Tamara Zacon. Infrastructura informaional n Republica Moldova. Chiinu, FEP Tipografia Central, 2001, -208 p. 5. Ilie Costa. Managementul informaional: unele tendine ale dezvoltrii. Trends and the Development of the Information and Communication Technologies in Education and Management. International Conference. March 20-21,2003. Chisinau, ASEM, 2003, pp. 14-24 6. Ilie Costas. Managementul informaional integrat - temelie pentru managementul cunotinelor. Simpozionul Internaional Integrarea European i competitivitatea Economic, 23-24 septembrie, ASEM, 2004 7. Ilie Costas. Management: Foundation for Knowledge Management. American Romanian Academy of Arts and Sciences (ARA), The Academy of Economic Studies of Moldova, Proceedings. July 5-10, 2005, Central Publishing House, Chisinau, 2005.

117

9. Concluzii
n pofida timpului scurt scurs de la naterea industriei de software, se apreciaz c fiecare ablon al acestei culturi organizaionale evolutive, descrise prin nivelele de maturitate ale modelului CMM/SEI, a avut propria contribuie la dezvoltarea industriei software - de la a face calculatoarele mai puin nspimnttoare pentru publicul larg, pn la a oferi modaliti de dezvoltare i inere sub control a unor proiecte de dimensiuni mari. Dincolo de modelele oferite de literatura de specialitate, de diferite institute i organizaii (ISO, SEI, IEC), c managementul calitii este principalul factor care contribuie la statuarea metamodelului calitii software, aplicabil nu att la nivelul organizaiilor productoare de software, ct la nivelul ntregii industrii. Acest meta-model al calitii software nu reprezint doar mbuntirile incrementale ce apar de la lun la lun sau de la an la an n domeniul analizat, ci const n acumularea solid a micilor pai ce construiesc drumul mbuntirii calitii, de-a lungul generaiilor. Dei exist o bogat activitate practic i teoretic n domeniu (literatur de specialitate, standarde, tehnici i metode), managementul calitii nu are o definire larg recunoscut. Astfel, Juran definete managementul calitii prin trilogia planificare, inere sub control i mbuntire, pe cnd ali autori definesc simplu managementul calitii, sau asigurarea calitii n sens larg ca fiind " totalitatea activitilor desfurate pentru obinerea calitii" [0LA1]. Indiferent de definirea managementul calitii, aa cum se afirm n [BAL1], "producia de software i furnizarea de servicii informatice asociate depind n mare msur de managementul efectiv al efortului intelectual", i "nici o naiune nu-i poate permite s aib o industrie de software care s produc altceva dect software de calitate". Drumul pn la furnizarea de soluii n ceea ce privete calitatea software ncepe de la identificarea cauzelor anomaliilor, iar procesul de identificare pornete de la sistemul calitii, existent la nivelul organizaiei. Aceasta presupune urmrirea unui sistem (explicit sau implicit) al caracteristicilor de calitate, msurarea nivelului acestora, scalarea msurtorilor, analiza datelor i analiza factorilor de influen. Multe din cauzele anomaliilor nu rezid i nu se reflect direct n caracteristici de calitate legate de produs, ci n lipsuri i disfuncii ale proceselor din cadrul sistemului dezvoltrii de software. Dar, pentru c limbajul pe care l nelege cel mai bine orice manager, este limbajul costurilor, n realizarea managementului calitii software se folosesc modaliti concrete de evaluare a costurilor calitii, precum i de clasificare a acestor costuri. n baza evalurii i apoi a identificrii concrete, managementul are la dispoziie prghii decizionale de orientare a activitii. n acest context, este esenial pentru personalul implicat n managementul calitii produselor software, s direcioneze practica managerial spre raportul cost - valoare.

118

Dezvoltarea tot mai accentuat a Internet-ului, produce modificri de substan i n ceea ce privete problema produselor software cu surse libere, care, sub o nou hain - "Open Source Software" - ncearc s revoluioneze cutumele organizaionale i comerciale n domeniu, pornind tocmai de la considerente legate de calitate i managementul calitii. Prezena rapoartelor de evaluare de stadiu n ceea ce privete OSS, chiar la gigani ai industriei informatice americane (Microsoft), pune problema viabilitii viitoare a tuturor modelelor de dezvoltare de software, dar i a remodelrii corespunztoare a abloanelor organizaionale de tipul Capability Maturity Model dezvoltat de Software Engineering Institute. Politica produselor software "destul de bune", n condiiile n care se afirm ca o concepie susinut de nume rsuntoare din lumea specialitilor tehnologiei informaiei (E. Yourdon) i, mai ales, printre managerii responsabili cu calitatea, poate deveni o arm teoretic redutabil n lupta marilor corporaii productoare de software, cu concepte precum OSS, calitate total sau protecia consumatorului. Acest lucru nu nseamn c o asemenea concepie asupra calitii i a managementului calitii nu este viabil, mai ales ntr-un mediu de afaceri unde beneficiarii nu au nici experiena i nici resursele necesare pentru a-i planifica asemenea proiecte, precum este mediul de afaceri i instituional din Romnia. Concepte precum triajul i administrarea cerinelor, aplicate de productorii de software, pot ajuta beneficiarii n a-i cunoate i a-i defini coerent poziia fa de produsele software i sistemele informatice ce le sunt necesare. Managementul calitii nu poate fi efectiv i eficient att timp ct, indiferent de modelul i cile de a dezvolta un produs software, nu este prezent la nivelul tuturor proceselor i activitilor implicate. Aa cum se afirm n [BAL1], ncepnd cu anul 1998, evaluarea i certificarea produselor software va beneficia de dou serii de noi standarde, - ISO 9126 i ISO 14598 - astfel:

ISO/IEC 9126 - Caracteristici i metrici ale calitii software ISO 9126-1 ISO 9126-2 ISO 9126-3 ISO 14598-1 ISO 14598-2 ISO 14598-3 ISO 14598-4 ISO 14598-5 ISO 14598-6 Caracteristici i subcaracteristici de calitate Metrici externe Metrici interne ISO/IEC 14598 - Evaluarea produselor software Generaliti Planificare i management Proces pentru dezvoltatori Proces pentru achizitori Proces pentru evaluatori Documentaia pentru modulele de evaluare

119

Lucrarea de fa, fr a avea pretenia exhaustivitii i a definitivului, ncearc s delimiteze i s clarifice noiunea de gestiune a calitii, importana, oportunitatea i instrumentele utilizate, precum i raporturile acesteia cu managementul calitii.

Anexa 3A Propunere de structurare a unui raport de auditare

Seciunea 1. Introducere
1.1. Scopul auditului Paragraful trebuie s prezinte scopul raportului, i anume prezentarea rezultatelor auditrii unui anume produs software sau proiect. 1.2. Identificarea obiectului auditului Paragraful trebuie s conin identificarea obiectului auditului (produsul sau proiectul auditat), localizarea sa n timp i spaiu, perioada cnd a fost efectuat auditul, numele auditorilor. 1.3. Referine despre proiect Paragraful trebuie s conin un sumar al referinelor (documentelor i documentaiilor) cu privire la istoria i dezvoltarea proiectului n cadrul cruia a fost executat auditul. 1.4. Sumarul raportului de audit Paragraful trebuie s conin o scurt descriere a coninutului raportului de audit.

Seciunea 2. Referine
Aceast seciune conine o list complet a documentelor pe care se bazeaz raportul de audit.

Seciunea 3. Procedura de audit

n aceast seciune se va descrie procedura utilizat n conducerea auditului, cu referire la documentele specifice sau alte entiti utilizate n cadrul procesului.

Seciunea 4. Constatri
4.1. Conformana cu standardele Paragraful trebuie s conin constatrile fcute cu ocazia verificrii asigurrii calitii, n ceea ce privete structura, formatul, coninutul i metodologia. Standardele aplicabile pot fi externe (guvernamentale, internaionale, departamentale, impuse prin contracte) sau interne (de corporaie, sau ale managementului de proiect). 4.2. Identificarea configuraiei Paragraful trebuie s conin rezultatele identificrii configuraiei software, precum i o reprezentare grafic a configuraiei (cuprins n paragraf sau ntr-o anex la acesta). Tot n acest paragraf vor fi menionate i dificultile ntmpinate n procesul de deducere a elementelor de configuraie. 4.3. Rezultatele evalurii cerinelor Paragraful trebuie s conin o list a discrepanelor observate n evaluarea documentaiei n care sunt cuprinse cerinele (specificaiile cerinelor). Poate fi cuprins la acest paragraf sau ntr-un apendix i o reprezentare a cerinelor identificate.

120

Anexa 3A (continuare)
4.4. Matricea trasabilitii Paragraful reprezint trasabilitatea dintre specificaiile cerinelor i produsul software. De asemenea, aici se detaliaz discrepanele dintre specificaiile cerinelor i produsul software, precum i dintre rezultatele stadiului precedent i produsul software prezent. 4.5. Rezultatele verificrii Paragraful trebuie s prezinte discrepanele observate, ca rezultat al procesului de verificare al produsului software. 4.6. Rezultatele validrii Paragraful trebuie s prezinte o list a discrepanelor observate, ca rezultat al procesului de validare al produsului software. 4.7. Raportul de stadiu al configuraiei Paragraful trebuie s conin o list a elementelor de configuraie care au fost modificate, ca urmare a actualizrii produsului software, precum i a modificrilor fcute.

Seciunea 5. Concluzii
Seciunea prezint concluziile formulate de auditori, n baza rezultatelor auditului. Aici trebuie s se menioneze c aceste concluzii reprezint concluziile proprii (i, eventual, subiective) ale autorilor, n comparaie, cu rezultatele obiective ale auditului, rezultate din observare i prezentate n seciunea 4.

Seciunea 6. Recomandri
Seciunea conine recomandrile auditorilor, rezultate n urma auditului. Ca i seciunea anterioar, i aceast seciune conine judeci i concluzii proprii ale auditorilor (deci se menioneaz i aici eventuala rezerv de subiectivitate).

121

Anexa 4 Indicaii metodologice privind realizarea sistemelor informatice si a produselor program - I.C.I. Bucureti, 1982 -[Extras] A. Elaborarea temei de realizare a) Studiul sistemului informaional existent b) Evaluarea sistemului existent c) Evaluarea gradului de utilizare a echipamentelor d) Formularea cerinelor i restruciilor pentru realizarea sistemului informatic Documentaia elaborat: TEMA DE REALIZARE A SISTEMULUI INFORMATIC B. Elaborarea concepiei sistemului informatic a) Definirea sistemului informatic b) Adoptarea soluiilor pentru codificarea datelor i conversia unor fiiere c) Proiectarea de principiu a noului flux informaional d) Stabilirea necesarului de echipamente e) Stabilirea necesarului de programe i evaluarea disponibilului de software f) Structurarea sistemului informatic pe componente g) Elaborarea graficului de ealonare a proiectrii i implementrii h) Evaluarea implicaiilor i stabilirea msurilor pregtitoare i) Estimarea eficienei economice Documentaia elaborat: PROIECTUL DE ANSAMBLU C. Proiectarea tehnic a sistemului informatic a) Proiectarea funcional detaliat a componentelor i legturilor b) Stabilirea cerinelor i a condiiilor tehnice de realizare a programelor c) Stabilirea resurselor necesare la proiectant i beneficiar pentru etapele urmtoare Documentaia elaborat: PROIECTUL LOGIC DE DETALIU PROIECTUL TEHNIC DE DETALIU Anexa 4 (continuare) D. Elaborarea programelor a) Elaborarea programelor pentru toate tipurile de echipamente utilizate b) Testarea de ansamblu a componentei realizate i integrarea acesteia n sistem c) Definitivarea documentaiei rezultate Documentaia elaborat: MANUALUL DE PREZENTARE MANUALUL DE UTILIZARE MANUALUL DE EXPLOATARE DOCUMENTAIA DE REALIZARE E. Implementarea i experimentarea Documentaia elaborat: RAPORTUL DE IMPLEMENTARE

122 Anexa 6 Contractul social Debian Firma Debian, productorii sistemului Debian GNU/Linux, au creat Contractul Social Debian, iniial proiectat ca un set minim de obligaii asumate de prile implicate. n timp, acest contract a fost adoptat de comunitatea "free software" ca baz a definirii software cu surse deschise - Open Source Software (OSS). "Contract Social" cu comunitatea 1. Software-ulprodus de Debian va rmne 100% "Free Software" Ne angajm s pstrm distribuia produsului Debian GNU/Linux n ntregime liber. Avnd n vedere c exist multe definiii ale "free software", includem mai jos elementele utilizate pentru a determina dac un produs face parte din categoria "free software". Vom oferi suportul necesar utilizatorilor notrii care dezvolt i ruleaz software comercial folosind ca suport Debian GNU/Linux, dar nu vom face niciodat acest sistem dependent de software comercial. 2. Vom returna orice component comunitii Cnd vom scrie noi componente ale sistemului Debian GNU/Linux, le vom nregistra (licenia) ca "free software". Vom ncerca s producem un sistem bun, astfel nct acesta s poat fi distribuit i utilizat pe o scar ct mai larg. Vom ngloba n produs rezolvarea erorilor, mbuntirile, cerinele utilizatorilor, etc. incluznd autorii lor n prezentarea sistemului. 3.Nu vom ascunde nici o problem Vom crea, menine i actualiza baza de date cu privire la erorile produsului, deschis consultrilor publice n orice moment. Raportrile cu privire la erori, semnalate de utilizatori on-line, vor fi imediat fcute publice. 4. Prioritile noastre sunt utilizatorii i "Free Software" Strategia noastr de aciune va fi dictat de nevoile utilizatorilor notrii i de cerinele comunitii. Interesele acestora vor fi prioritare pentru noi. Vom asigura sprijinul necesar utilizatorilor notrii pentru operarea n medii computaionale i pe platforme diferite. Nu vom avea niciodat obiecii cu privire la produsele software comerciale care se vor dezvolta pe platforma Debian GNU/Linux i vom permite altor organizaii sau persoane s efectueze distribuii comerciale, coninnd att Debian GNU/Linux ct i software comercial, fr plat. Pentru a susine acest obiectiv, vom distribui un sistem integrat Debian GNU/Linux, de calitate superioar, 100% "free software", fr restricii legale. 5. Cu privire la produsele care nu ndeplinesc standardele noastre de "free software" Suntem de acord c pentru unii din utilizatori este necesar s utilizeze produse software care nu se conformeaz cu Regulile Debian privitoare la "free software". Pentru aceasta am creat directoarele "contrib" i "non-free" n arhiva dvs. FTP. Produsele software din aceste directoare nu sunt componente ale sistemului Debian GNU/Linux, dei au fost configurate s lucreze cu acesta. ncurajm productorii de CD-uri s citeasc licenele pachetelor software din aceste directoare i s afle dac pot distribui acest software pe CD-urile lor. Astfel, dei produse software comerciale nu sunt parte a sistemului Debian GNU/Linux, sprijinim utilizarea lor, i construim infrastructura necesar (cum ar fi sistemul de trasare a erorilor sau listele de pot electronic), pentru produsele software comerciale. Anexa 6 (continuare) Regulile Debian ca privire la "free software" 1. Redistribuire gratuit Licena unei componente a sistemului Debian GNU/Linux nu restricioneaz nici o ter parte de a vinde sau a distribui acest software ca o component a unui produs software agregat, coninnd programe din mai multe surse diferite. Licena nu va necesita nici o tax pentru asemenea vnzri. 2. Codul surs Produsul software trebuie s includ codul surs i trebuie s fie permis distribuia codului surs precum i a formei compilate. 3. Produse derivate Licena trebuie s permit modificri i revizuiri derivate, i trebuie s permit distribuirea acestora sub aceeai termeni legali ca i licena pentru produsul software original. 4. Integritatea codului surs al autorului Licena poate restriciona distribuirea liber a codului surs n forme modificate, doar dac licena permite distribuirea fiierelor "patch" cu cod surs. Altfel, licena trebuie s permit n mod explicit distribuirea de software din surse modificate. Licena trebuie s prevad pentru produsele software construite din surse libere modificate, obligativitatea de a avea alt nume i alt versiune fa de produsul software original. 5. Lipsa oricrei discriminri ntre persoane sau grupuri Licena nu trebuie s conduc la discriminri ntre persoane sau grupuri. 6. Lipsa oricror discriminri ntre domenii Licena trebuie s nu restricioneze pe nimeni n a utiliza programul ntr-un domeniu specific. De exemplu, nu trebuie restricionat utilizarea produsului n domeniul afacerilor sau n cercetarea genetic. 7. Distribuirea licenei Drepturile ataate programului trebuie s fie opozabile tuturor persoanelor, grupurilor sau organizaiilor crora li se redistribuie, fr o licen adiional din partea acestora. 8. Licena nu trebuie s fie specific firmei Debian

123 Drepturile ataate unui program nu trebuie s fie dependente de apartenena acestuia la sistemul Debian GNU/Linux. Dac programul este parte a Debian GNU/Linux i este utilizat sau distribuit fr Debian GNU/Linux, dar se respect termenii licenei, toi terii crora li se redistribuie au aceleai drepturi ca cele garantate n conjuncie cu Debian GNU/Linux. 9. Licena nu trebuie s contamineze alt software Licena nu trebuie s stabileasc restricii asupra altor produse software care sunt distribuite odat cu produsul liceniat. De exemplu, licena nu trebuie s oblige ca toate celelalte programe distribuite sub acelai mediu (Debian GNU/Linux), s fie "free software". 10. Exemple de licene gratuite Licenele "GPL", "BSD", i "Artistic" sunt considerate de noi exemple de licene libere.