Standarde de calitate

Standardele de calitate sunt numeroase și au fost elaborate în timp, reflectând exact cerințele și posibilitățile informaticii de la acele vremuri.

Am identificat următoarele standarde:

ISO 9000 din 1987

ISO 9001 din 1997

ISO 9002 din 1987

ISO 9001 din 1987

ISO/IEC 9126 din 1991

ISO/IEC 2500

ISO/IEC 2501

ISO/IEC 2502

ISO/IEC 2503

ISO/IEC 2504

ISO/IEC 25010 din 2011

ISO/IEC 25012 din 2008

ISO/IEC 25050

ISO/IEC 25099

Textele acestor standarde sunt foarte complexe, iar IEEE a editat masivul volum Implementing the IEEE Software Engineering Standards, apărută la SAMS, avându-l autor pe Michael SCHMIDT, în anul 2000, iar lista standardelor IEEE este impresionantă, listă pe care o redau și eu aici. În vremurile de demult, mă refer la intervalul 1997-2003 am avut și eu un tom imens publicat la IEEE publications cu nenumăprate standarde, care erau așa de bune încât cine ar fi ieșit din litera lor, focurile Gheenei l-ar fi păscut iremediabil, ireversibil și pentru totdeauna.

IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology

IEEE Std. 1062, 1998 Edition, IEEE Recommended Practice for Software Acquisition

IEEE Std. 1220-1998, IEEE Standard for Application and Management of the Systems Engineering Process

IEEE Std. 1228-1994, IEEE Standard for Software Safety Plans

IEEE Std. 1233, 1998 Edition, IEEE Guide for Developing System Requirements

IEEE Std. 1362-1998, IEEE Guide-System Definition-Concept of Operations Document

IEEE Std. 12207.0-1996, IEEE/EIA Standard for Industry Implementation of International Standard ISO/IEC 12207:1995 (ISO/IEC 12207), Standard for Information Technology-Software life cycle processes

IEEE Std. 12207.1-1997, IEEE/EIA Guide-Industry Implementation of International Standard ISO/IEC 12207:1995 (ISO/IEC 12207), Standard for

Information Technology-Software life cycle processes-Life cycle data

IEEE Std. 12207.2-1997, IEEE/EIA Industry Implementation of International

Standard ISO/IEC 12207:1995 (ISO/IEC 12207), Standard for Information

Technology-Software life cycle processes-Implementation considerations

Process Standards these standards describe primary processes including acquisition, supply, development, maintenance, operations, and measurements.

IEEE Std. 730-1998, IEEE Standard for Software Quality Assurance Plans

IEEE Std. 730.1-1995, IEEE Guide for Software Quality Assurance Planning

IEEE Std. 828-1998, IEEE Standard for Software Configuration Management Plans

IEEE Std. 1008-1987 (R1993), IEEE Standard for Software Unit Testing

IEEE Std. 1012-1998, IEEE Standard for Software Verification and Validation

IEEE Std. 1012a-1998, Supplement to IEEE Standard for Software Verification and Validation-Content Map to IEEE/EIA 12207.1-1997

IEEE Std. 1028-1997, IEEE Standard for Software Reviews

IEEE Std. 1042-1987 (R1993), IEEE Guide to Software Configuration Management

IEEE Std. 1045-1992, IEEE Standard for Software Productivity Metrics

IEEE Std. 1058-1998, IEEE Standard for Software Management Plans

IEEE Std. 1059-1993, IEEE Guide for Software Verification and Validation Plans

IEEE Std. 1074-1997, IEEE Standard for Developing Software Life Cycle Processes

IEEE Std. 1219-1998, IEEE Standard for Software Maintenance

IEEE Std. 1490-1998, IEEE Guide to the Project Management Body of Knowledge

Product Standards

These standards explain the requirements for classes of software products[md]characteristics, measurements, evaluations, and specifications.

IEEE Std. 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software

IEEE Std. 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of

Measures to Produce Reliable Software

IEEE Std. 1061-1998, IEEE Standard for a Software Quality Metrics Methodology

IEEE Std. 1063-1987 (R1993), IEEE Standard for Software User Documentation

IEEE Std. 1465-1998, IEEE Standard Adoption of ISO/IEC 12119:1994(E),

Information Technology-Software packages-Quality requirements and testing

Resource and Technique Standards these standards recommend proper documentation for a well-managed software

program and its related processes.

IEEE Std. 829-1998, IEEE Standard for Software Test Documentation

IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements

Specifications

IEEE Std. 1016-1998, IEEE Recommended Practice for Software Design

Resource and Technique Standards

IEEE Std. 1044-1993, IEEE Standard Classification for Software Anomalies

IEEE Std. 1044.1-1995, IEEE Guide to Classification for Software Anomalies

IEEE Std. 1320.1-1998, IEEE Standard for Functional Modeling LanguageSyntax and Semantics for IDEFO

IEEE Std. 1320.2-1998, IEEE Standard for Conceptual Modeling LanguageSyntax and Semantics for IDEF1X97(IDEFobject)

IEEE Std. 1348-1995, IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools

IEEE Std. 1420.1-1995, IEEE Standard for Information Technology-Software

Reuse-Data Model for Reuse Library Interoperability: Basic Interoperability Data Model (BIDM)

IEEE Std. 1420.1a-1996, IEEE Guide for Information Technology-Software

Reuse-Data Model for Reuse Library Interoperability:Asset Certification Framework

IEEE Std. 1430-1996, IEEE Guide for Information Technology-Software ReuseConcept

of Operations for Interoperating Reuse Libraries

IEEE Std. 1462-1998, IEEE Standard Adoption of ISO/IEC 14102:1995-Guidelines for the Evaluation and Selection of CASE Tool.

Standardele spun multe numai celor care înțeleg litera dar și spiritul lor, fără a fi vorba de o utilizare mecanică, ci creativă astfel încât calitatea să rămână obiectivul esențial și nu teama de a nu respecta proceduri și fluxuri pe care standardele nu le impun în niciun fel, ci doar dau direcții de urmat, fiecare dintre noi având infinite libertăți de a ne încadra în cerințele lor, fără a dăuna obiectivului-calitate.

(08 decembrie 2017)

Managementul total

Managementul total al calității software este un deziderat ce nu va fi atins chiar așa de curînd la noi, în condițiile în care chiar în practică la noi managementul calității, adică banalul managementului calități are aspecte caricaturale. Acum mulți ani când m-am pus împreună cu prieteni mei Marius POPA, Gheorghe NOȘCA și Sergiu CAPISIZU să scriem cartea Managemntul calității aplicațiilor informatice, am făcut oferta unui nefericit de la o universitate din străinătate. De la respectivul am primit mesajul că i-ar conveni dacă noi am scrie despre Managemntul total al calității aplicațiilor informatice, ceea ce era cu totul altceva. M-am supărat, l-am expediat la origini și am pornit demersul nostru.

Cine vrea să vadă ce ste cu managementul toatl al calității software - TQMS să intre pe Internet și se va convinge că teoria este sublimă, dar o minimă decență ar trebui să ne rețină atât timp cât nu suntem nici perfecți și nici frumoși în ale managementului. TQMS presupune:

- continuitate;

- profunzime;

- rigoare;

- proceduri;

- măsurători;

- instrumente;

- specialiști;

- conștiință;

- profesionalism;

- industrie;

- reguli;

- standarde;

- respect.

În condițiile în care costurile pentru TQMS sunt cu mult mai mari decât în cazul SQM și când se înregistrează numeroase abateri de la proceduri și reguli, iar personalul din SQM nu este deloc independent, ba din contră este dependent de managementul de producție, evident, TQMS este un vis cam prea îndepărtat, așa cum robotizarea nu merge în secțiile cu strunguri realizate la 1950.
Managementul total în zona calității software este doar un deziderat, care mă duce la poemul eminescian La steauna.
Icoana stelei ce-a murit
Încet pe cer se suie;
Era pe când nu s-a zarit,
Azi o vedem, si nu e.
Mi se par mai natural să nu fim absurzi și acum în anul 2017 să facem măcar un management al calității software cinstit, cu proceduri, cu independența celor care fac acest management și cu dorința tuturor de a aloca eforturi și resurse spre a face calitate și nu de a o mima, căci acum aplicațiile online multiplică îngrozitor efectele negative, aducând în faliment pe dezvoltatorul neglijent.

în lucru acum

(08 decembrie 2017)

Calitatea procesului

Calitatea procesului de realizare a aplicațiilor informatice nu este nici pe departe o noutate. Este doar o translatare a studiului calității proceselor de producție din industrie, unde se analizează:

- echipamente;

- activități;

- executanți;

- consumuri;

- materiale;

- procedee;

- rețete;

- succesiuni;

- pregătiri;

- verificări;

- stocări;

- încercări.

Oricare dintre etapepe ciclului de realizare a unui produs software este analizată din punct de vedere cantitativ, dar și din punct de vedere calitativ. Din punct de vedere cantitativ analiza presupune a se da răspunsuri la întrebări precum:

- câți oameni lucrează la realizarea respectivei etape?

- din cîte operații este alcituită repseticva etapă?

- câte restricții de succesiune a operațiilor există?

- care sunt duratele operațiilor?

- câte resurse sunt necesare la fiecare etapă?

- care sunt riscurile care apar la fiecare operație?

- cât durează pregătirea unei operații?

- cât durează predarea produsului?

Aspectele de ordin calitativ sunt legate în mod adaptat de fiecare dintre etapele ciclului de realizare, căci fiecare operație se realizează bine, foarte bine sau prost, iar pentru fiecare calificativ există elemente clare de încadrare. Pentru ca un proces să fie bine bine derulat trebuie ca:

- toate operațiile să fie executate complet;

- toate procedurile necesare să fie cunoscute bine;

- procedurile să fie bine aplicate;

- executantul să fie conștiincios;

- executantul să fie mulțumit de ceea ce face;

- diferențele dintre planificat și realizat să fie minime;

- produsul obținut să fie catalogat ca bun. 

Pentru ca un proces să fie prost derulat este necesar ca doar un element care intră în componența sa să fie executat anapoda, o operație să fie sărită sau să nu i se acorde atenția corespunzătoare și totul se duce de râpă. La scrierea textului sursă trebuie executate activități precum:

- construirea listei complete de variabile;

- evitarea folosirii instrucțiunii GO TO;

- inițializarea tuturor variabilelor înainte de a fi utilizate;

- respectarea tuturor regulilor de sintaxă;

- punerea în corespondență a blocurilor din schema logică cu instrucțiunile programului.

Lista continuă cu alte și alte cerințe de care programatorul nu trebuie să fie străin. Noncalitatea produsului software este strict dependentă de măsura în care programatorul nu asigură calitatea procesului specific etapei în care el, programatorul intervine, adică etapa de scriere a programului. Dacă există o singură modalitate de a asigura calitatea procesului în scrierea programului, evident există o infinitate de modalități de a distruge calitatea procesului. Să ne uităm la pseudomeseriașii care mișună în economia românească și ne dăm seama cu precizie de  toată gama de improvizații și omisiuni ce au consecință distrugerea calității oricărui proces, ceea ce prin extensie se întâmplă și în activitatea de programare.
Lumea acordă destul de puțină atenție calității procesului. Disciplina din timpul activităților este esențială, mai ales că de nivelul de concentrare al programatorului depinde calitatea programului. Să nu-mi spună mie că un programator:
- hărțuit,
- stresat,
- timorat,
- agitat,
- sunat,
- chemat,
- verificat,
- urlat,
- subestimat,
- înjurat,
- bârfit,
- izolat,
- superficial,
- împrăștiat,
va avea acel randament care să-i permită să gândească și să scrie acele secvențe care să-l reprezinte și mai ales care să fie exact de nivelul și de potențialul pe care el îl dă în condiții propice scrierii de programe așa cum trebuie, când este respectat și lăsat să-și facă meseria. În vremurile de demult, când nu erau atât de mulți șefi și manageri ca azi, parcă programatorul era mai liber să gândească, mai creativ și cu mult mai eficient, iar programele sale parcă semănau mai mult a bijuterii și nu a tinichele ca azi, când doar poleiala contează

(08 decembrie 2017)

Controlul calității

Controlul calității în opinia mea trebuie făcut de cei care știu meserie și nu de unii care doar asta știu să facă, adică să controleze. Îmi face atâta scârbă când văd pe câte unul care nu a scris în viața lui un program că se uită la texte sursă și strâmbă din nas, căutând și găsind tot felul de cusururi, dintre care

unele sunt de-a dreptul exagerate.

Când am scris cartea programarea standard, referită prin: Ion Ivan - Programare  standard, Editura Litera, București, 1981, 123 pg. Acolo am scris că analiștii trebuie să fi fost cândva cei mai buni programatori. Numai așa ei vor ști să scrie specificații și să facă descrieri pe care programatorii să le înțeleagă perfect. În opinia mea, un rol esențial în alre autocontrolul calității. Adică, înainte ca altcineva să vadă cât de bine este scris un text sursă, cel mai bine este ca programatorul însuși să facă analiza și să facă corecții. Numai după ce el este convins că a epuizat tot ce știe să dea programul pe mâna altora. Cândva am avut ocazia să văd niște tipi absolut ignorați care făceau pe testerii, deși ei în viața lor nu scriseseră vreo instrucțiune. Erau extrem de duri. I-am lăsat să delireze, după care le-am arătat eu toate greșelile lor de testare, care erau greșeli elementare. Una dintre ele este că nimeni nu ară același set de date de test de două ori pentru a trage două concluzii absolut diferite, aberante, incomplete și mai ales de un subiectivism crunt care începe cu mi se pare că. În zona software orice se face are dreptul de a face obiectul controlului. Se controlează definirea problemei. Se controlează specificațiile. Se controlează textul sursă. Se controlează cum s-a făcut testarea. Se controlează implementarea. Se controlează modul cum se face exploatarea. Ideia este ca procesul de control să se facă fie în timp ce se derulează operațiunea, fie imediat ce operațiunea s-a încheiat. Dacă se găsesc hibe, acestea se vor corecta și nu se vor propaga etapelor ce urmează și abia în final să fie identificate și nu oricum, ci rostogolite, amplificate și costisitoare.

Am un respect imens față de toți cei care vin să facă control cu bune intenții și care dau șanse reale executanților de a face corecții, fără a lovi cu barda, necruțător, ireversibil și zgomotos.

Există ă literatură foarte bogată pe contro, căci plăcerea de a controla, de a face pe zmeul și de a-i umili pe cei din jur este cu atât mai crâncenă, cu cât cel ce controlează este mai ignorant și needucat.
Controlul calității este un lucru normal, care devine anormal când are dimensiuni și importanță disproporționate în raport cu efectele pe care le generează față de cei din jur. Am văzut controlori de calitate software care când au pierdut poziția, nici post de măturători în echipe de dezvoltare nu și-au găsit.

(08 decembrie 2017)

Realizarea calității

Realizarea calității este un nou mod de a înțelege calitatea. În opinia mea, calitatea este o construcție, asemeni unei care, care se construiește pas cu pas. Se pun temeliile calității-construcție prin:

- achiziționare de tehnică de calcul de ultimă generație;

- achiziționarea de licențe pentru cele mai noi instrumente;

- achiziționarea de licențe pentru cele mai noi medii de dezvoltare;

- achiziționarea de licențe pentru cele mai noi SGBD-uri;

- achiziționarea de facilități și resurse de a lucra în cloud;

- instruirea și certificarea  personalului existent;

- implementarea cerițelor de management al calității;

- implementarea de proceduri clare de scriere programe;

- definirea exactă a fluxurilor ciclului de realizare.

Construcția numită calitate, exact ca la realizarea unui zid unde se urmărește verticalitatea, caracterul drept și uniform al dispunerii cărămizilor, tot așa și la programe. La fiecare secvență programatorul însuși face analize proprii,. El nu așteaptă pe altcineva să vină să-i spună că programul lui nu e bun și să-i înșire tot felul de cauze.

Fiecare dintre cei ce lucrează în informatică trebuie să se gândească la echivalentul poziției lui în etapa de realizare a calității unei clădiri și după aceea să facă similitudini și va înțelege exact cum stau lucrurile la locul său de muncă cu procesul de a construi calitate software. Orice altă abordare este păguboasă și când spun asta, știu ce spun, pentru că am lucrat cu programatori care nu au înțeles chesria și am pătimit și eu și alții cu vârf și îndesat. Este infinit mai greu să corectezi decât să faci lucrul bun din start.

Istoria informaticii a consemnat nenumărate momente ale realizării calității pe principiile translatate din alte domenii pentru că programatorii proveneau ei înșiși din alte domenii și până să capete deprinderile de informaticieni, se manifestau cu obiceiurile de la vechile lor locuri de muncă. Am văzu persoane care veneau din contabilitate și care gestionau etichetele din programe exact ca în contabilitate cu debit pe cele care erau la instrucțiuni DO, IF(), GO TO și la credit pe cele de la instrucțiunile unde fie se delimita domeniul, fie trebuia să se ajungă la un moment dat. În acest fel ei nu se găseau niciodată în situația de a avea etichete necunoscute ca mesaj în compilare.

Am văzut matematicieni meticuloși care realizau schemele logice pe care le verificau și răsverificau. Ei realizau corespondență perfectă între blocurile din schema logică și liniile textului sursă. Chiar și etichetele erau în corespondență  cu conectorii din schemele logice. Totul era ca o interpretare după note a unuei melodii când aceștia scriau programele.

(08 decembrie 2017)

Calitatea software

Calitatea software a fost intuită dintotdeauna, de când a fost scris primul program.
Un program era bun dacă și numai dacă:
- prelua datele de intrare de pe suport sau de la consolă;
- și executa calculele pentru care a fost scris;
- și tipărea sau afișea rezultate corecte și complete;
- și se încadra într-o durată de execuție decentă;
- și era realizat în termenii impuși de beneficiar.
Un program nu era bun dacăcel mult una dintre cerințe nu era îndeplinită, căci nimeni nu avea nevoie de un program care:
- nu intra în execuție că avea greșeli de compilare sau de editare de legături;
- cu citea toate datele;
- nu efectua toate calculele și se întrerupea subit execuția;
- nu așișea toate rezultatele sau afișea rezultate incorecte;
- nu era realizat la termenul cerut de beneficiar ci mai târziu;
- avea durate de execuție mult prea mari comparativ cu altele;
- îl chinuiau pe beneficiar cu interpretarea de rezultate.
Făcând translatarea conceptului de calitate de la celelalte produse pe care industria le realiza, în cazul calității software se dau nenumărate definiții pentru calitatea software, dintre care mie mi-a plăcut cea care spune că: prin calitate software se înțelege totalitatea însușirilor tehnice, economice și sociale cu care trebuie înzestrat un produs program astfel încât să fie utilizat de către cei interesați.
În vremurile de demult lumea nu era interesată:
- nici de a măsura calitatea programelor,
- nici de a estima calitatea programelor;
- nici de a urmări calitatea programelor,
- nici de a impune calitatea programelor,
- nici de costurile generate de programe,
- nici de amortizarea calculatoarelor,
ci era interesată de a găsi metode empirice pentru:
- a crește calitatea programelor,
- a-l mulțumi cu programul pe beneficiar,
- a reutiliza în timp programele,
- a se scrie programe cât mai complexe,
- a testa cât mai complet programele,
- a folosi cât mai bine resursele disponibile.
Când se studiază acum calitatea software, cărțile dau definiții, enumeră caracteristici, dau modele de estimare a niveurilor caracteristicilor și fac unele considerații referitoare la corelațiile dintre caracteristici. Mai identifică și căi de creștere a calității, precum și dezvoltă elemente de costuri ale calității și se fac remarci legate de optimizare.
În vremurile de demult, programatorii erau cei care discutau despre artificiile care le permiteau să facă să se termine orice program scris de ei cu mesaje proprii ale programului, adică să arate ce era greșit în datele de intrare de nu se ducea prelucrarea până la capăt. Chestia cu validările de date era și atunci ca și acum esențială și mă mir acum cumm unele aplicații sofisticate nu validează numele de persoană care nu trebuie să conținp cifre sau caractere bizare. Sunt stupefiat să văd aplicații mobile care permit introducerea de numere negative la cantitate. Sunt șocat să văd cum vin dezvoltatori cu aplicații netestate, pentru a se face de cacao și pentru a se comprtomite deplin și definitiv.



(08 decembrie 2017)

Asigurarea calității

Asigurarea calității a fost un obiectiv subânțeles în lumea programatorilor datorită:

- mândriei;

- erorilor;

- duratelor;

- renumelui;

- depanării;

- zvonurilor;

- efectelor;

- termenelor;

- admirației.

Orice programator se asigura că știe destul de bine să scrie programe pentru că și atunci ca și acum se punea problema traversării etapelor de realizare de la analiză, la scriere de text sursă, la testare, la implementare și la utilizare, această ultimă etapă revenea în peste 80% tot ptogrematorului, beneficiarul fiind cel care aducea cu tiile cu cartele de date.

Nu exista în legătură cu asigurarea calității ceea ce există acum, mai ales că perfecționarea programatorilor nu presupunea certificări și meseria nu se învăța, se fura. Asigurarea calității o făceau șefii de sectoare din centrele de calcul, prin distribuirea de sarcini acelor programatori despre care ei aveau certitudinea că scriu bine programe. Pe ceilalți îi arondau unor echipe la și alții. Programatorii de elită asigurau calitatea studiind variante de soluții și alegând una dintre ele, pe care o considerau cea mai potrivită.

Ei scriau pe hârtie formule, făceau diagrame, făceau calcule, schițau liste de parametrii. Când se apucau de scris programe știau cu excatitate ce scriu, căci foile de programare nu se șterg așa cum se șterg liniile de text sursă de pe monitor, când procesorul de texte suportă orice. Existența schemelor logice de detaliu arată că programatorul are o imagine completă asupra a ceea ce are de făcut. Numai faptul că etichetele în programele FORTRAN erau termenii unei progresii aritmetice cu primul termen 10 și cu rație, de asemenea, 10, spune foarte multe.

Asigurarea calității era realizată prin testul de birou, în care programatorul verifica bloc cu bloc schema logică, după care verifica existența concordanței dintre blocuri și instrucțiunile din program. În acele vremuri nu existau metrici, nici indicatori, numai că se știau:

- numărul de linii sursă al programului;

- numărul de erori de compilare la fiecare rulare;

- numărul erorilor de execuție;

- instrucțiunile de scriere rezultate intermediare;

- urma programului solicitată sau generată;

- raportarea în raport cu termenul de predare;

- analiza rezultatului predării programului.

Acum asigurarea calității produselor software este capitol de Software engineering și există cărți despre așa ceva. Una dintre ele este Software Quality Assurance a lui Daniel GALIN, apărută în anul 2004 în Editura Edisson Wesley, new York, de 587 de pagini,

Al cărui cuprins îl redau aici:

Contents

Preface xvii 

Unique features of this text xviii 

The book’s audience xix Acknowledgements xx 

Publisher’s acknowledgements xxi 

About the author xxii 

Guides for special groups of readers xxiii 

Guide to readers interested in ISO 9000-3 requirements xxiii 

Guide to readers interested in ASQ’S CSQE body of knowledge xxiv 

Part I Introduction 1

Chapter 1 The software quality challenge 3

1.1 The uniqueness of software quality assurance 4 

1.2 The environments for which SQA methods are developed 7 

Summary 11 

Review questions 

12 Topics for discussion 12

Chapter 2 

What is software quality? 14

2.1 What is software? 15 

2.2 Software errors, faults and failures 16 

2.3 Classification of the causes of software errors 19 

2.4 Software quality – definition 24 

2.5 Software quality assurance – definition and objectives 25 

2.6 Software quality assurance and software engineering 30 

Summary 30 

Selected bibliography 32 

Review questions 32 

Topics for discussion 33

Chapter 3 

Software quality factors 35

3.1 The need for comprehensive software quality requirements 36 

3.2 Classifications of software requirements into software quality factors 37 

3.3 Product operation software quality factors 38 

3.4 Product revision software quality factors 41 

3.5 Product transition software quality factors 43 

3.6 Alternative models of software quality factors 44 

3.7 Who is interested in the definition of quality requirements? 47 

3.8 Software compliance with quality factors 49 

Summary 51 

Selected bibliography 52 

Review questions 52 

Topics for discussion 54

Chapter 4 

The components of the software quality assurance system – overview 56

4.1 The SQA system – an SQA architecture 57 

4.2 Pre-project components 60 

4.3 Software project life cycle components 61 

4.4 Infrastructure components for error prevention and improvement 65 

4.5 Management SQA components 68 

4.6 SQA standards, system certification, and assessment components 69 

4.7 Organizing for SQA – the human components 70 

4.8 Considerations guiding construction of an organization’s SQA system 72

Part II Pre-project software quality components 75

Chapter 5 

Contract review 77

5.1 Introduction: the CFV Project completion celebration 78 

5.2 The contract review process and its stages 79 

5.3 Contract review objectives 80 

5.4 Implementation of a contract review 82 

5.5 Contract review subjects 85 

5.6 Contract reviews for internal projects 85

Contents

Summary 87 

Selected bibliography 88 

Review questions 89 

Topics for discussion 89 

Appendix 5A: Proposal draft reviews – subjects checklist 92 

Appendix 5B: Contract draft review – subjects checklist 94

Chapter 6 

Development and quality plans 95

6.1 Development plan and quality plan objectives 97 

6.2 Elements of the development plan 97 

6.3 Elements of the quality plan 101 

6.4 Development and quality plans for small projects and for internal projects 103 

Summary 106 

Selected bibliography 108 

Review questions 109 

Topics for discussion 110 

Appendix 6A: Software development risks and software risk management 112

Part III SQA components in the project life cycle 119

Chapter 7 

Integrating quality activities in the project life cycle 121

7.1 Classic and other software development methodologies 122 

7.2 Factors affecting intensity of quality assurance activities in the development process 131 

7.3 Verification, validation and qualification 133 

7.4 A model for SQA defect removal effectiveness and cost 135 

Summary 

143 Selected bibliography 145 

Review questions 146 

Topics for discussion 147

Chapter 8 Reviews 149

8.1 Review objectives 150 

8.2 Formal design reviews (DRs) 152

8.3 Peer reviews 158 

8.4 A comparison of the team review methods 168 

8.5 Expert opinions 

170 Summary 171 

Selected bibliography 

172 Review questions 

172 Topics for discussion 

174 Appendix 8A: DR report form 175 

Appendix 8B: Inspection session findings report form 176 

Appendix 8C: Inspection session summary report 177

Chapter 9 Software testing – strategies 178

9.1 Definition and objectives 180 

9.2 Software testing strategies 182

9.3 Software test classifications 187 

9.4 White box testing 189 

9.5 Black box testing 197 

Summary 209 

Selected bibliography 211 

Review questions 212 

Topics for discussion 213

Chapter 10 Software testing – implementation 216

10.1 The testing process 217 

10.2 Test case design 232 

10.3 Automated testing 235 

10.4 Alpha and beta site testing programs 245 

Summary 247 

Selected bibliography 249 

Review questions 250 

Topics for discussion 251

Chapter 11 Assuring the quality of software maintenance components 254

11.1 Introduction 255 

11.2 The foundations of high quality 257 

11.3 Pre-maintenance software quality components 261 

11.4 Maintenance software quality assurance tools 264 

Summary 273 

Selected bibliography 275 

Review questions 275

Topics for discussion 277

Chapter 12 Assuring the quality of external participants’ contributions 279

12.1 Introduction: the HealthSoft case 280 

12.2 Types of external participants 282 

12.3 Risks and benefits of introducing external participants 283 

12.4 Assuring quality of external participants’ contributions: objectives 286 

12.5 SQA tools for assuring the quality of external participants’ contributions 287 

Summary 293 

Selected bibliography 295 

Review questions 295 

Topics for discussion 296

Chapter 13 CASE tools and their effect on software quality 298

13.1 What is a CASE tool? 299 

13.2 The contribution of CASE tools to software product quality 302 

13.3 The contribution of CASE tools to software maintenance quality 304 

13.4 The contribution of CASE tools to improved project management 304 

Summary 305 

Selected bibliography 306 

Review questions 306 

Topics for discussion 307

Part IV Software quality infrastructure components 309

Chapter 14 Procedures and workinstructions 311

14.1 The need for procedures and work instructions 312 

14.2 Procedures and procedures manuals 313 

14.3 Work instructions and work instruction manuals 316 

14.4 Procedures and work instructions: preparation, implementation and updating 317 

Summary 318 

Selected bibliography 319 

Review questions 319 

Topics for discussion 320 

Appendix 14A: Design review procedure 322

Chapter 15 Supporting quality devices 325

15.1 Templates 326 

15.2 Checklists 329 

Summary 332 

Selected bibliography 333 

Review questions 333 

Topics for discussion 334

Chapter 16 Staff training and certification 335

16.1 Introduction: Surprises for the “3S” development team 336 

16.2 The objectives of training and certification 337 

16.3 The training and certification process 338 

16.4 Determining professional knowledge requirements 338 

16.5 Determining training and updating needs 339 

16.6 Planning training and updating programs 340 

16.7 Defining positions requiring certification 340 

16.8 Planning the certification processes 341 

16.9 Delivery of training and certification programs 342 

16.10 Follow-up subsequent to training and certification 344 

Summary 345 

Selected bibliography 346 

Review questions 347 

Topics for discussion 347

Chapter 17 Corrective and preventive actions 349

17.1 Introduction: the “3S” development team revisited 350 

17.2 Corrective and preventive actions – definitions 351 

17.3 The corrective and preventive actions process 352 

17.4 Information collection 353 

17.5 Analysis of collected information 354 

17.6 Development of solutions and their implementation 356 

17.7 Follow-up of activities 359 

17.8 Organizing for preventive and corrective actions 360 

Summary 361 

Selected bibliography 362 

Review questions 362 

Topics for discussion 363

Chapter 18 Configuration management 365

18.1 Software configuration, its items and its management 367 

18.2 Software configuration management – tasks and organization 369 

18.3 Software change control 371 

18.4 Release of software configuration versions 373 

18.5 Provision of SCM information services 380 

18.6 Software configuration management audits 380 

18.7 Computerized tools for managing software configuration 381 

Summary 382 

Selected bibliography 383 

Review questions 384 

Topics for discussion 384

Chapter 19 Documentation control 387

19.1 Introduction: where is the documentation? 388 

19.2 Controlled documents and quality records 389 

19.3 The controlled documents list 392 

19.4 Controlled document preparation 393 

19.5 Issues of controlled document approval 393 

19.6 Issues of controlled document storage and retrieval 394 

Summary 395 

Selected bibliography 396 

Review questions 397 

Topics for discussion 397

Part VManagement components of software  quality 399

Chapter 20 Project progress control 401

20.1 The components of project progress control 402 

20.2 Progress control of internal projects and external participants. 404 

20.3 Implementation of project progress control regimes 405 

20.4 Computerized tools for software progress control 406 

Summary 408 

Selected bibliography 409 

Review questions 

410 Topic for discussion 411

Chapter 21 Software quality metrics 412

21.1 Objectives of quality measurement 414 

21.2 Classification of software quality metrics 415 

21.3 Process metrics 416 

21.4 Product metrics 420 

21.5 Implementation of software quality metrics 427 

21.6 Limitations of software metrics 432 

Summary 434 

Selected bibliography 436 

Review questions 438 

Topics for discussion 440 

Appendix 21A: The function point method 442

Chapter 22 Costs of software quality 449

22.1 Objectives of cost of software quality metrics 450 

22.2 The classic model of cost of software quality 451 

22.3 An extended model for cost of software quality 455 

22.4 Application of a cost of software quality system 458 

22.5 Problems in the application of cost of software quality metrics 462 

Summary 463 

Selected bibliography 465 

Review questions 465 

Topics for discussion 468

PartVI Standards, certification and assessment 471

Chapter 23 Quality management standards 475

23.1 The scope of quality management standards 476 

23.2 ISO 9001 and ISO 9000-3 477 

23.3 Certification according to ISO 9000-3 481 

23.4 Capability Maturity Models – CMM and CMMI assessment methodology 485 

23.5 The Bootstrap methodology 490 

23.6 The SPICE project and the ISO/IEC 15504 software process assessment standard 492 

Summary 497 

Selected bibliography 

499 Review questions 500 

Topics for discussion 501 

Appendix 23A: CMMI process areas 502 

Appendix 23B: ISO/IEC 15504 model processes 505

Chapter 24 SQA project process standards – IEEE software engineering standards 507

24.1 Structure and content of IEEE software engineering standards 509 

24.2 IEEE/EIA Std 12207 – software life cycle processes 510 

24.3 IEEE Std 1012 – verification and validation 514 

24.4 IEEE Std 1028 – reviews 519 

Summary 521 

Selected bibliography 

524 Review questions 524 

Topics for discussion 525 

Appendix 24A: IEEE Software Engineering Standards 526 

Appendix 24B: MIL-STD-498: list of Data Item Descriptions (DIDs) 528 

Appendix 24C: Task structure for a primary process according to IEEE/EIA Std 12207 – example 528

PartVII Organizing for quality assurance 539

Chapter 25 Management and its role in software quality assurance 543

25.1 Top management’s quality assurance activities 544 

25.2 Department management responsibilities for quality assurance 549 

25.3 Project management responsibilities for quality assurance 550 

Summary 551 

Selected bibliography 552 

Review questions 553 

Topics for discussion 554

Chapter 26 The SQA unit and other actors in the SQA system 555

26.1 The SQA unit 556 

26.2 SQA trustees and their tasks 563 

26.3 SQA committees and their tasks 563 

26.4 SQA forums – tasks and methods of operation 564 

Summary 565 

Review questions 568 

Topics for discussion 568

Epilogue The future ofSQA 570

Facing the future: SQA challenges 571

 Facing the future: SQA capabilities 574

Author index 577 

Subject index 580

Se observă cu ușurință că pentru a face asigurarea calității și programatorul și analistul și testerul și toți cei ce sunt într-o companie dezvoltatoare de software trebuie să știe:

- ce este aceea calitatea software;

- care sunt caracteristicile de calitate;

- câteva modele sau indicatori de măsurare a carateristicilor;

- cum se culeg datele de intrare în modele și indicatori;

- să folosească  niște software care calculează indicatorii;

- să interpreteze rezultatele;

- să corecteze module pentru a le face să fie de calitate.

Între teorie și practică este mare diferență, iar practica este cea care arată dacă se face sau nu asigurarea calității software, căci nu trebuie constatată nici calitatea, nici non-calitatea, ci trebuie făcuți acei pași care să ducă spre texte sursă care să dovedească un nivel de calitate ridicat.

în lucru acum

(08 decembrie 2017)

Planificarea calității

Planificarea calității unui produs software înseamnă:

- a stabili care sunt caracteristicile de calitate esențiale;

- a găsi produse similare sau din aceeași clasă de complexitate;

- a găsi elemente comune ale acestora cu viitorul produs;

- a găsi niveluri pentru caracteristici care sunt satisfăcătoare;

- a construi un sistem de niveluri de calitate acceptabil;

- a adopta acele niveluri ca fiind ideale pentru noul produs;

- a estima costurile pentru a realiza acea calitate;

- a corecta niveluri dacă sunt costuri prea mari;

- a decide cum trebuie să arate calitativ noul produs;

- a demonstra că nivelul de calitate este superior;

- a exista asigurărică există există resurse pentru realizare.

Ca orice proces de planificare și planificarea calității unui produs software pornește de la premisele că:

- produsul nu există;

- însușirile de construiesc;

- au loc comparații;

- se fac calcule;

- se aleg niveluri;

- se folosesc similitudini;

- nivelul planificat este orientativ;

- pe parcurs se fac corecții;

- se obține doar o imagine;

- textul creat e coerent;

- nivelurile din plan sunt etaloane;

- activitatea se orientează spre plan.

Dacă înainte de 1989 planul era o obsesie națională, acum prin activitatea de planificare a calității, se face un tabel în care pe o coloană se trec caracteristici de calitate și pe o altă coloană se trec niveluri minime cu care produsul software ce se realizează trebuie înzestrat. Acele niveluri sunt justificate prin modul de comportament al unor produse software existente în piață și mai ales pornind de la exigențele proprii care au menirea de  a asigura un nivel de competitivitate superior celor aflate în exploatare curentă acum. Și în cazul planificării calității, ca și în cazul planificării duratei de realizare a produsului, există formule de calcul, care țin seama de nivelul calității planificat și estimările de costuri, care dau caracter realist abordării atât timp cât costul produsului este suportabil, comparabil și frecventabil pe la instituțiile financiare de unde se obțin credite sau orice altă formă de finanțare.
Planificarea calității presupune cunoașterea pieței de software căci a realiza un nou produs software înseamnă a-l înzestra cu caracteristici de calitate care să-l facă apreciat în piață de către viitorii utilizatori. Acest lucru se face prin comparație. Înseamnă că planificatorii trebuie să cunoască piața, să cunoască nivelurile efective ale caracteristicilor de calitate ale produselor software din piață. Intrarea pe piață este posibilă pentru un nou produs dacă și numai dacă nivelul indicatorului său de calitate agregat este superior oricărui alt produs similar ca funcționalități.
Programatorii de altădată nu aveau în gând explicit să-și planifice calitatea. Ei doreau ca:
- programele să fie bune, deci mental planificau calitativ nivelul calității agregate;
- utilizatorul să fie mulțumit, deci planificau nivelul indicelui de satisfacție;
- procesul de testare să fie lin, iar ondulanța să fie finită, deci planificau calitatea procesului;
- timpul necesar și cheltuielile să fie rezonabile, deci optimizau costul calității.
În felul lor erau niște manageri de calitate softwate, dar erau manageri tăcuți ai calității, pentru că nu se exprimau nici științific și nici măsurători de indicatori ai calității nu făceau și nici calitatea nu o estimau cumva.
Ca programator din antichitatea programării calculatoarelor știu cu exactitate că nimeni nu se preocupa despre:
- fiabilitatea software, deși fiabilitatea centralelor nucleare se studia intens;
- complexitatea software, deși chestia cu dublarea utilajelor era un mod ce crestere a sa;
- portabilitate în sine, ci de portabilitatea de a trece a programelor de pe IBM pe FELIX C 256;
- reutilizare, căci ideia de originalitate 100% era obsesia fundamentală și neîncrederea era maximă;
- lucru în echipă pentru că programarea nu se desprinsese de poezie în Internet nu exista;
- a identifica o serie de căi de creștere a calității, mai ales că se lucra sub presiunea termenelor.
Deși totul se planifica înainte de 1989, în zona informaticii, ca o altă formă de manifestare a artei pe lângă cele șapte recunoscute, planificarea nu a pătruns până în adâncul viscerelor economiei sale pentru că era un domeniu inaccesibil profanilor, calculatorul fiind regele. De aceea a planifica calitatea era și ceva misterios și ceva de nepătruns, dar mai ales ceva fluid, abstract și lunecos.

(08 decembrie 2017)

Caratcteristici de calitate

Caratcteristicile de calitate software formează o listă destul de consistentă. Fiecare generație de software a venit cu caracteristicile sale. De aceea studiul caracteristicilor de calitate vine să completeze istoria dezvoltării software, căci pentru un produs software realizat empiric cu totul altfel se punea problema să se analizeze calitatea în comparație un un produs software dezvoltat după tehnica programării orientate obiect OOP. Dintre caracteristicile de calitate cu care se lucrează în prezent enumăr:
- funcționalitate
- fiabilitate
- utilizabilitate
- eficiență
- mentenabilitate
- portabilitate.
Fiecare dintre aceste caracteristici are la rândul ei o serie de subcaracteristici derivate conform ISO 9126.
Subcarcateristicile fiabilității sunt:
- recuperabilitatea
- toleranța la defecțiuni
- maturitatea,
Eficiența unui produs software se măsoară prin:
- comportamentul în timp
- comportamentul resurselor.
Mentenabilitatea este strâns legată de subcaracteristicile:
analizabilitate
substituibilitate
stabilitate
testabilitate.
Portabilitatea are subcaracteristicile:
- adaptabilitatea
- instabilitatea
- conformitatea
- înlocuirea
- interschimbabilitatea.
Utilizabilitatea are subcaracteristicile:
- ușurința de instruire
- operabilitatea.
Funcționalitatea are subcaracteristicile:
- potrivirea
- corectitudinea
- interoperabilitatea
- conformitatea
- securitatea.
În elaborarea de standarde toate caracteristicile dar și subcaracteristicile sunt definite riguros și se vede că niciuna dintre acestea nu se suprapune cu o alta. În studiul calității software există și nenumărate atribute de calitate, pe care le preiau așa cum sunt ele date în limba engleză:
accessibility
accountability
accuracy
adaptability
administrability
affordability
agility
auditability
autonomy
availability
compatibility
composability
configurability
correctness
credibility
customizability
debugability
degradability
determinability
demonstrability
dependability
deployability
discoverability
distributability
durability
effectiveness
efficiency
evolvability
extensibility
failure transparency
fault-tolerance
fidelity
flexibility
inspectability
installability
integrity
interchangeability
interoperability
learnability
maintainability
manageability
mobility
modifiability
modularity
operability
orthogonality
portability
precision
predictability
process capabilities
producibility
provability
recoverability
relevance
reliability
repeatability
reproducibility
resilience
responsiveness
reusability
robustness
safety
scalability
seamlessness
self-sustainability
serviceability
supportability
securability
simplicity
stability
standards compliance
survivability
sustainability
tailorability
testability
timeliness
traceability
transparency
ubiquity
understandability
upgradability
vulnerability
usability.

Există multe modalități de a face adaptări pentru a da sensul cu care vorbitorii de limbă română îl au pentru unii termeni, ceea ce mă face ca de cele mai multe ori să nu traduc chiar toate subcaracteristicile sau toate atributele, care ar conduce către lucruri forțate.

Conceptul de atribut este mult mai larg și nu se bazează pe raporturi de subordonare, care în final duc la dilema cu cine a fost mai înainte, oul sau găina. Oricând există posibilitatea de a veni cu argumente care să răstoarne structura unui graf al dependențelor pe care se bazează raportul clasă-subclasă.

În imaginea de deasupra sunt prezentate caracteristicile și subcaracteristicile regrupate, așa cum le văd Francisca Losavio, Ledis Chirinos, Nicole Lévy și  Amar Ramdane-Cherif în articolul Quality Characteristics for Software Architecture, publicat în JOURNAL OF OBJECT TECHNOLOGY, Vol. 2, No. 2, 2003, pg. 133 - 150.
Lucrurile se complică foarte mult în cazul aplicațiilor online și a celor mobile căci un rol special îl au interfețele și tehnicile de programare fac să treacă pe planuri secunde fiabilitatea și portabilitatea. Caratcteristicile de calitate sunt atât de numeroase și se combină în nenumărate moduri încât este imposibil de stabilit care sunt componentele sistemului caracteristicilor de calitate pentru un anumit produs software.

(08 decembrie 2017)

Managementul calității software

Calitatea software
Calitatea procesului
Caratcteristici de calitate
Planificarea calității
Realizarea calității
Asigurarea calității
Controlul calității
Metrici software
Căi de creștere a calității
Optimizarea calității
Managementul total
Standarde de calitate




(08 decembrie 2017)

Metrici software

Metricile software sunt o colecție de indicatori utilizați în măsurarea nivelurilor unor caracteristici de calitate pe care clienții sau dezvoltatorii le consideră esențiale în demersul pe care îl urmăresc.

Dacă se intră pe google vor fi găsite nenumărate caracteristici de calitate software care sunt complet tratate complet cu definiții, cu modele, cu corelații între caracteristici și cu indicații speciale pentru modul în care se culeg date, se interpretează rezultatele și despre riscurile care apar când se fac estimări.

La construirea unei metrici există libertatea de a alege indicatorii, dar ideia este de a face o astfel de alegere încât să se asigure operaționalitatea, în ideia ca efortul de culegere a datelor să nu facă imposibilă repetarea operației în timp.

Este rezonabil să se studeiese:

- caracteristici de calitate;

- diversitatea de modele;

- avantaje și dezavantaje;

- efortul de a asigura continuitatea;

- mod efectiv de utilizare a rezultatelor.

Consider că sunt operaționale metricile în care:

- numărul de indicatori pe caracteristică este de 1 la 1;

- complexitatea indicatorilor este redusă;

- culegerea de date nu ridică probleme;

- există software de calcul indicatori;

- indicatorii sunt normați;

- metrica este stabilă pentru comparabilitate;

- și alte produse sunat analizate tot cu ele.

În timp am avut preocupări pe acest subiect pentru că una se vorbește și cu totul altfel stau lucrurile în realitate, lumea preferând teoria și mai puțin practica, deși de fiecare dată când se vorbește de calitate, trebuie să fie prezentate valori numerice și trebuie stabilite ipotezele de lucru. Am scris materiale:

• Ion IVAN, Panagiotis SINIOROS, Mihai POPESCU, Felix SIMION – Metrici software, Editura INFOREC, Bucuresti, 119 pg., ISBN 973-97435-0-X, 1997
• Ion IVAN, Doru CAZAN – Metricile de calitate ale sistemelor informatice, Informatica Economica, vol. 8, nr. 3, 2004, pg. 123 – 128, ISSN 1453-1305, 2004
• Ion IVAN, Marius POPA – Tipuri de metrici ale textelor, Studii si cercetari de Calcul Economic si Cibernetica Economica, vol. 38, nr. 1, 2004, pg. 25 – 36, ISSN 0585-7511., 2004
• Ion IVAN, Constantin NICULAE, Paul POCATILU – Metrici pentru evaluarea coeziunii software orientat obiect, Studii si Cercetari de Calcul Economic si Cibernetica Economica, vol. 37, nr. 3, 2003, pg. 5 – 14, ISSN 0585-7511., 2003
• Ion IVAN, Paul POCATILU, Mihai AMITROAIE, Metrici ale societăţii informaţionale, revista Informatica Economică, vol. 5, nr. 4, 2001, pg. 33 – 40, ISSN 1453-1305, 2001
• Ion IVAN, Alexandra KARADIMOU, Adrian LICURICEANU, Gheorghe LUPU - Metrici de complexitate software bazate pe dependenţele instrucţiunilor, revista Informatica Economică, vol. 3, nr. 3, 1999, pg. 11 – 19, ISSN 1453-1305, 1999
• Ion IVAN, Gheorghe LUPU, Adrian LICURICEANU – Substituirea de metrici software, Studii si Cercetari de Calcul Economic si Cibernetica Economica, vol. 33, nr. 1/1999, pg.25 – 33. , 1999
• Alexandru BALOG, Ion IVAN, Extensii ale metricii Halstead pentru sisteme de programare, PC WORLD ROMANIA, an 5, nr.5, 1997, pag.86-87, 1997
• Ion IVAN, Daniel VERNIS, Petrisor OPREA - Metrici pentru compresia fişierelor, revista Informatica economica, vol1, nr. 2/ 1997, pg. 100 – 104, ISSN 1453-1305, 1997
• Ion IVAN, Felix SIMION, Emilia STANCIU, Alexandra KARADIMOU - Metrici ale re-ingineriei software, revista Informatica Economică, vol. 1, nr. 3/ 1997, pg. 27 – 34, ISSN 1453-1305, 1997
• Ion IVAN, Felix Simion, Viorel Nica - Gradul de interferenta al metricilor Halstead si McCabe, Revista Romana de Informatica si Automatica, vol. 7, nr. 3, 1997, pg. 23-28, ISSN 1220-1758. , 1997
• Ion Ivan, Popescu Mihai - Metrici software, BYTE România, vol. 2, nr. 5, mai 1996, pg. 73-82, ISSN 1223-9801. , 1996
• Ion IVAN, Adrian VISOIU - Rafinarea metricilor software, Economistul, nr. 1947 (2973), 29 august 2005, supliment Economie teoretica si practica, nr. 466
• Tudor BARON, Alexandru BALOG, Ion IVAN – Aspecte privind definirea metricilor pentru evaluarea calitatii produselor program, volumul Lucrarile celui de al III-lea Simpozion Modelarea Cibernetica a Proceselor de Productie, 22-23 Aprilie, 1982, Bucuresti, pg. 573-580.
• Ion IVAN, Gheorghe NOSCA, Andrei TUDOREL, Paul POCATILU, Razvan CACIULA – Metrici ale datelor care sunt intrari si iesiri pentru pachetele de programe aflate in uz curent la societatile de servicii informatice, studiu pentru contractul METODE SI INSTRUMENTE SOFTWARE DE EVALUARE A SOCIETATILOR DE SERVICII INFORMATICE, Act aditional nr. 821/98/III la contractul nr. 1253, 198/1996, Beneficiar: ANSTI 
• Ion IVAN, Gheorghe NOSCA, Ludovic TOVISSI, Valerie VOICA, Maria BODNAR Christina SUCIU, Catalion HUIDUMAC, Paul POCATILU – Definirea indicatorului agregat de evaluare a calitatii productiei conform ISO9000, studiu pentru contractul ASISTAREA INFORMATIZATA A ACTIVITATILOR DE ASIGURARE A CALITATII CONFORM ISO9000 PENTRU INTREPRINDERI MICI SI MIJLOCII, act aditional nr. 821/98/III la contractul nr. 1253, 198/1996, Beneficiar: MCT. 

Pentru a construi o metrică se procedează astfel:

- se stabilește obiectivul metricii

- se identifică acele caracteristici esențiale

- se stabilesc factorii de influență

- se ierarhizează factorii

- se construiește lista factorilor esențiali

- se culeg date reprezentative

- se construiesg grafice ale dependențelor

- se identifică exresii analitice

- se stabilește criteriul de selecție

- se fac estimări

- se ierarhizează indicatorii în raport cu criteriul

- se construiește metrica

- se validează metrica

- se analizează stabilitatea metricii.

Se asociază o diagramă, căci procesul de alcătuire a unei metrici este un proces iterativ, fără a pleca de la idei preconcepute. Este rezonabil ca metrica să conțină indicatori normați pe intervalul [0; 1] cu ipoteza că valorile apropiate de zero duc la concluzia că produsul software nu este înzestrat cu acea caracteristică, în timp ce dacă valoarea indicatorului se apropie de unu înseamnă că produsul software este înzestreat cu acea caracteristică.

în lucru acum

(08 decembrie 2017)

Optimizarea calității

Optimizarea calității este o problemă spinoasă. Toată lumea vrea calitate de nivel maxim, numai că acest deziderat ori costă foarte mult, ori este foarte greu de realizat.

Se știe din experiența proprie a fiecărui programator că atunci când dorește să crească nivelul unei caracteristici de calitate apar efecte adverse. Când se urmărește creșterea fiabilității înseamnă că se introduc tot felul de teste, ceea ce duce la creșterea complexității produsului. Dacă se face un desen, efortul de reducere a cazurilor de căderi accidentale ale unui produs software este însoțită de creșterea exponențială a costurilor de programare și de testare pentru a atinge acest deziderat.

unde:

nf - nivelul nonfiabilității

cost- cheltuieli de programare

o - punctul unde se află costul optim al calității

t - axa timpului

c - axa costurilor.

Societatea nuși permite să cheltuiasă oricât pentru a realiza un nivel maxim de calitate. Deci se acceptă un minim rezonabil al defectelor. În realitate se demonstrează că nu există niciun program perfect, mai ales dacă are un nivel de complexitate oarecare. 

În timp am avut astfel de preocupări de a studia optimizarea calității software și aici prezint unele materiale publicate care vor fi referite prin:

• Ion IVAN, Gheorghe NOSCA – Optimizarea costului calitatii sistemelor de programe, PC World, vol. 3, nr. 6, 1995, pg. 58-60
• Ion IVAN, Paula APREUTESEI, Gheorghe NOSCA – Optimizarea costului calitatii sistemelor de programe, A XXVI – a Sesiune de Comunicari Stiintifice cu participare Internationala, Academia Tehnica Militara, 16-17 Noiembrie, 1995, vol. 5 de Comunicari, Sectiunea Informatica si Automatizarea conducerii trupelor, pg. 44-51.
• Ion IVAN, Romulus ARHIRE, Alexandru BALOG - Modele ale estimării costurilor pentru produse-program, în volumul Conferinţei Naţionale de Cibernetică- Cibernetica in slujba dezvoltării economico-sociale a ţării, coordonatori Mihai FLORESCU, Eugeniu Niculescu MIZIL, Editura Academiei, Bucureşti, 1983, pg. 122-126

În 04.12.2003.. Gheorghe NOȘCA a susținut în ASE teza de doctorat intitulată Metode si tehnici de optimizare a costului calitatii produselor program, teză pe care am coordonat-o eu.
Optimizarea calității în zona de software este un concept puțin cam exagerat, căci mai corect este îmbunătățirea calității, întrucât creșterea calității se face pas cu pas, iterativ, prin încercări succesive. Se știe când începe procesul de îmbunătățire, iar stoparea este dată de mulți factori, inclusiv de identificarea momentului când tot umblând pe textul sursă, în loc să se îmbunătățească performanțele, acestea scad chiar surprinzător de dramatic.

în lucru acum

(08 decembrie 2017)

Căi de creștere a calității

Căile de creștere ale calității produselor program sunt nenumărate, dar dintre ele enumăr:

- nivelul de calificare; cu cât este mai ridicat, cu atât crește și calitatea;

- experiența acumulată pe tipologii de funcționalități;

- nivelul de exigență din companie;

- urmărirea stilului de programare unitar și selectat;

- patterns design;

- asigurarea unei transparențe maxime pentru codul scris;

- utilizarea de componente verificate din biblioteci;

- difernțierea programatorilor;

- gestionarea efectelor de ondulanță;

- normarea clară a duratelor pentru activități;

- utilizarea de tehnici și de instrumente performante;

- utilizarea de prototipuri de programe;

- reutilizarea de componente software;

- omogenizarea în sus a echipelor de programatori;

- folosirea de reguli stricte în scrierea de programe;

- testarea după reguli foarte exacte a programelor;

- măsurarea permanentă a calității software;

- existența unei echipe care analizează calitatea software.

Căile de creștere a calității depind de la companie la companie, dar știind că în dezvoltarea de software peste 90% din costuri sunt cu salariile, toate căile trebuie concentrate pe forța de muncă. Trebuie văzut ce se va face cu programatorii, cu analiștii și cu testerii ca ei să prin munca lor să ducă la creșterea calității produselor pe care le realizează.

(08 decembrie 2017)