Software

Software

De la Wikipedia, enciclopedia liberă

OpenOffice.org Writer

Prin software (/’sʌf ‘ tué:r/), soft sau rareori și „logicial” [1][2] se înțelege un sistem de programe pentru calculatoare incluzând procedurile lor de aplicare, sistem furnizat o dată cu calculatorul respectiv sau creat ulterior de către utilizator sau și cumpărat din comerț de-a gata. Prin contrast, cuvântul hardware desemnează partea fizică a calculatorului sau a sistemului informatic respectiv. În general, pentru a funcționa, un sistem informatic are nevoie de ambele componente, în plus și de datele care trebuiesc prelucrate. Uneori și aceste date sunt considerate a face parte din software.

Componenta software poate include toată gama de produse de programare, uzual formată din sistem de operare, drivere și programe de aplicație. În anumite cazuri speciale părți din software se înglobează din construcție în hardware – prin folosirea de circuite integrate preprogramate.

În unele domenii, prin software se înțeleg în primul rând datele cu care lucrează aparatele sau calculatoarele, cum ar fi imaginile digitalizate, sunete și piese muzicale, jocurile pentru calculator, filme digitalizate, clipuri video și multe alte date asemănătoare. În caz extrem, până și purtătorii fizici de date sau “mediile” sunt considerate a fi “software”, ca de exemplu discurile optice de tip CD și DVD, casetele video VHS și miniDV, casetele audio ș.a.

Un termeni înrudit dar distinct este firmware-ul, numit și microprogram sau microcod.

Pirateria de software

Pirateria de software se referă la copierea programelor de calculator fără respectarea drepturilor de autor. În România, pirateria software a scăzut în ultimii ani, de la 74% în 2004, la 68% în 2008[3]. Doar valoarea licențelor ilegale de sisteme de operare Windows din România este de peste 150 milioane dolari (decembrie 2008)[3].

Definiţia cerinţei software

Elementul central în Analiză este, cu siguranţă, cerinţa software. În jurul cerinţelor se desfăşoară totul: cerinţele trebuie culese de la clienţi, cerinţele trebuie documentate, trebuie gestionate, dezvoltate, testate. În fond, modelul creat prin specificaţiile software este un model compus din cerinţe care trebuie să se transforme în produsul final.
Din acest motiv, vom insista asupra definiţiilor date cerinţelor software, poate chiar mai mult decât asupra definiţiilor Analizei software în sine.

În literatura de specialitate există o mulţime de definiţii. Toate încearcă însă să cuprindă următoarele elemente esenţiale: cerinţele sunt descrieri (specificaţii), într-un limbaj accesibil tuturor celor implicaţi a ceea ce un sistem informatic trebuie să poată acoperi, atât prin comportamente (behaviour) cât şi prin atribute ale sale.

Cea mai completă (şi, desigur, cea mai recunoscută) definiţie a cerinţei este dată de Institute of Electrical and Electronics Engineers (IEEE). Conform acestei organizaţii, prin standardul 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology, cerinţa software este definită astfel:

Cerinţa softwareeste:1. o condiţie sau capabilitate necesar a fi îndeplinită de către un sistem, pentru ca un utilizator să poată rezolva o anumită problemă sau să atingă un anumit obiectiv;2. o condiţie sau capabilitate pe care un sistem trebuie să o realizeze sau să o posede pentru a satisface un contract, standard, specificaţie sau alt documentformal impus;3. un document – reprezentarea unei condiţii sau capabilităţi, aşa cum este descrisă la punctele 1 şi 2 de mai sus.

Mai înainte de a analiza această definiţie vom clarifica termenul “capabilitate” utilizat aici. Capabilităţile desemnează ceva ce un sistem software furnizează utilizatorilor, fie un anumit comportament fie un anumit atribut. Deşi termenul provine din englezescul “capability”, limba română are aici privilegiul de a avea pentru capabilitate o descriere intuitivă: ea desemnează ceva ce un sistem este capabil să facă, ceva ce sistemul poate.

Printr-o capabilitate a unui sistem putem desemna fie un comportament fie un atribut. De pildă, o funcţionalitate de genul „sistemul validează formatul datei atunci când utilizatorul înregistrează factura în sistem” este un comportament al sistemului, în timp ce „poziţia unui buton pe ecran” este un atribut.
(Mai pe româneşte, în final, un câmp dintr-o bază de date sau o proprietate a unui obiect poate corespunde unui atribut al unei entităţi, în timp ce o metodă a unui obiect înseamnă comportament.)

Revenind la definiţia cerinţei, vom detalia pe scurt cele trei părţi ale definiţiei.

Prima parte, reprezintă punctul de vedere al utilizatorului. Centrul atenţiei este, la acest punct, utilizatorul care are nevoie ce ceva pentru a rezolva o problemă sau pentru a atinge un obiectiv. Această parte a definiţiei ne spune clar că dacă problema/obiectivul utilizatorului nu poate fi specificat, atunci cerinţa nu există. O cerinţă există atâta timp cât ea reprezintă soluţia pentru o problemă a utilizatorului.

A doua parte a definiţiei reprezintă punctul de vedere al dezvoltatorului. Aici “o condiţie sau capabilitate pe care un sistem trebuie să o realizeze” este ceea ce dezvoltatorul trebuie să realizeze. Aşa cum se poate vedea din definiţie, pentru el referinţa este un “document formal impus”. Vom vedea în capitolele următoare că aici nu este vorba despre o descriere a funcţiilor aşa cum se dezvoltă ele în limbaj de programare ci sunt capabilităţi care pot fi înţelese, au o logică şi pot fi validate şi de către utilizatorul sistemului, fără ca acesta să ştie programare.

Partea a treia a definiţiei exprimă un punct de vedere comun, sau un punct de vedere general, o regulă de bază: primele două puncte de vedere nu pot exista dacă nu există documentul pe care ambele părţi să îl poată folosi ca referinţă. Dacă documentul nu există, cele două puncte de vedere, precum şi evoluţia lor în timp nu au un element comun palpabil şi fără echivoc, o referinţă acceptabilă.
Aşadar, conform punctului 3 din definiţia cerinţei, o cerinţă care nu este documentată nu există.

Observăm, din definiţia de mai sus, că cerinţa, privită din partea utilizatorului sistemului este ceva util pentru rezolvarea unei probleme, în timp ce, pentru dezvoltator cerinţa este ceva ce el trebuie să dezvolte, conform specificaţiei. Ca urmare, cerinţa trebuie exprimată în aşa fel încât să poată fi interpretată fără dubii de ambele părţi, pentru că ea este destinată în egală măsură ambelor părţi.
Pe de o parte, pentru utilizator este importantă rezolvarea propriilor probleme, fără ca detaliile tehnice ce ţin de rezolvarea lor să fie relevante. De cealaltă parte, dezvoltatorul are nevoie de o referinţă pentru a şti ce să dezvolte, în timp ce problemele utilizatorului au relevanţă mai scăzută. Aici, la mijloc între cei doi se situează Analistul software şi produsul munci sale: cerinţa software – un document care arată utilizatorului soluţia problemei lui iar dezvoltatorului ce trebuie să dezvolte.

Cerinţele software, între PROBLEMĂ şi SOLUŢIE

Aşa cum se vede în figura de mai sus, în cadrul evoluţiei de la Problemă la Soluţie, specificarea cerinţei este pasul intermediar: ea este, pentru utilizator, soluţia vizată a problemei lui, iar pentru dezvoltator este problema pe care o are de rezolvat.

După cum vom vedea şi în continuare, cerinţele exprimate în limbaj inteligibil, sub forma documentelor de specificaţii software, agreate de către client şi de către echipa de dezvoltare, constituie referinţa de bază pentru toţi cei implicaţi în proiectele software: pentru project manageri, în determinarea şi urmărirea task-urilor sau pentru inginerii de testare, în realizarea testelor.

techit.ro

Lasă un răspuns