Analiza cerinţelor software 
  techIT.ro Do we have a problem? Let's tech it!    












Daca ai impresia ca educatia e scumpa,
atunci încearca sa vezi cum e ignoranta.
Andy McIntyre









Home  |  Dictionar IT  |  Download  |  Forum  |  Despre noi  |  Contact

Analiza cerinţelor software

1. Analiza cerinţelor software. Introducere
Această serie de articole este destinată tuturor persoanelor implicate în proiecte de dezvoltare de software: şefi de departament, project manageri, analişti (în primul rând lor), arhitecţi software, programatori sau specialişti în asigurarea calităţii....


2. Despre Analiza cerinţelor
Analiza cerinţelor software (pe care o vom numi în continuare Analiza Software) este aceea dintre disciplinele existente în domeniul Software care determină ce trebuie făcut, preluând problema clientului şi exprimând-o într-un inteligibil de către dezvoltator...


3. Axiome ale dezvoltării de software
În continuarea răspunsului la întrebarea „De ce este nevoie de Analiză Software?” am să prezint o serie de lucruri pe care practica le susţine ca fiind, fără dubiu, nişte adevăruri şi care, aşa cum vom vedea susţin necesitatea existenţei Analizei software...


4. Ciclul de dezvoltare al produsului software (SDLC)
Ciclul de dezvoltare al produsului software este un model al apariţiei produsului software, pornind de la problema originară şi ajungând la un produs concret, care să răspundă acelei probleme...


5. Ciclul de dezvoltare iterativ (în spirală)
Asumarea realităţii că întotdeauna, în decursul proiectului, cerinţele se vor schimba a condus la apariţia unui model de dezvoltare realist, care să fie adaptat acestei realităţi şi care să permită înglobarea schimbării în cel mai bun mod cu putinţă...


6. Locul Analizei în proiectul de dezvoltare software
Să luăm ca exemplu un proiect, pe care îl vom numi în continuare proiectul ALPHA, cu o echipă mare, cu un termen de livrare de cel puţin un an, cu o echipă de dezvoltare de 20 de persoane şi cu un client adesea indecis, care îşi schimbă cerinţele de la o lună la alta...


7. Modele teoretice de abordare a problemelor. Decompoziţia
Directorul companiei XYZ se plânge că nu îşi poate planifica corect aprovizionarea şi că pierde foarte mulţi bani din cauză că nu are întotdeauna suficientă marfă atunci când apar oportunităţi de vânzare sau, invers, pierde bani pentru că i se alterează cantităţi însemnate de marfă în stoc din cauză că s-a achiziţionat mai mult decât era necesar. Pentru a rezolva o asemenea problemă...


8. Modele teoretice de abordare a problemelor. Sinteza
Pentru a limpezi utilitatea acestui procedeu, să ne închipuim că medicul ar proceda cam ca echipa proiectului ALPHA din exemplul din articolul Locul Analizei în proiectul software, tratând fiecare simptom în parte, dar fără să determine boala în sine: pentru febra ar administra antitermice iar pentru durerea de cap, antinevralgice. Cu siguranţă infecţia care produce simptomele ar rămâne neatinsă sau chiar s-ar agrava din cauza tratamentului neadecvat, iar simptomele ar reveni în forme şi mai dure...


9. Modele teoretice de abordare a problemelor. Determinarea unui trunchi de bază
De foarte multe ori, în viaţa reală, o problemă nu poate fi punctată decât cu un efort substanţial sau chiar deloc. Pur şi simplu, obţinerea unui model mintal al unei realităţi foarte complexe este imposibil sau prea riscant...


10. Definiţia cerinţei software
În literatura de specialitate există o mulţime de definiţii ale cerinţei. 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...


11. Modele teoretice de abordare a problemelor. Abordarea iterativă
Metoda iterativă presupune rezolvarea unei probleme cunoscute printr-o abordare iterativă, la fiecare iteraţie făcând un pas către rezolvarea problemei (ceea ce nu înseamnă neapărat rezolvarea integrală a unei sub-probleme, aşa cum vedem la descompunere)...


12. Nivelurile cerinţelor
Cerinţele pot fi: A. Cerinţe de business, B. Cerinţe utilizator, C. Cerinţe funcţionale...


13. Unde se termină cerinţele clientului şi unde începe designul?
Dacă ne situăm pe un nivel oarecare şi privim de jos în sus putem vedea problema pentru care nivelul respectiv reprezintă o soluţie. Nivelul superior este răspunsul la întrebarea "CE?"...


14. Riscuri legate de cerinţe
Proiectul real porneşte întotdeauna cu un buget limitat şi evoluează întotdeauna în direcţia adăugării de cerinţe cât pentru trei bugete (axioma întâia), dar se termină de cele mai multe ori la un nivel de calitate mult sub cel dorit...


15. Riscuri legate de cerinţe, partea a II-a
...oricare dintre variante poate conduce la următoarele efecte negative:
- dezvoltarea unor funcţionalităţi inutile;
- dezvoltarea unor funcţionalităţi utile dar în afara domeniului problemei, care ridică probleme de buget;
- omiterea unor funcţionalităţi necesare sau chiar esenţiale...


16. Cerinţele nefuncţionale
În primul rând, determinarea acestor cerinţe este un lucru dificil, pentru că, în general utilizatorii nu sunt interesaţi, şi nici puşi în temă, în legătură cu costurile cerinţelor lor şi au tendinţa să exagereze: „sistemul trebuie să lucreze 24 de ore din 24”, „timpul de răspuns?... păi sistemul trebuie să răspundă instantaneu la orice comandă”, „nu se admite nici un bug în funcţionarea sistemului”...


17. Caracteristicile cerinţelor software
Caracteristicile esenţale ale cerinţei software: ncesară, corectă, completă, consistentă, clară, trasabilă......


18. Dezvoltarea şi Managementul cerinţelor
În general, rezolvarea unei probleme noi presupune cel puţin două faze, absolut legitime: informarea la nivel macro (despre ce este vorba?) şi detalierea...


19. Realizarea interviurilor la client
"o şedinţă cu clientul, de la care te întorci fără a avea clară raţiunea cerinţei (raţiunile cerinţelor) ci doar cu cerinţa, fără a mai vorbi de soluţiile propuse de client, este o şedinţă ratată şi contraproductivă"...


20. Tipuri de informaţii primite de la client
Să menţii controlului asupra derulării şedinţei înseamnă, nu numai să ai abilităţi de moderator, dar şi să ştii unde te afli în orice moment şi încotro vrei să îndrepţi lucrurile......


21. Semnarea specificaţiilor software
Semnarea specificaţiilor software nu înseamnă îngheţarea acestora ci reprezintă momentul trecerii proiectului într-o nouă etapă, în care baza o reprezintă specificaţia software, aşa cum este ea în momentul semnării, iar schimbările se fac printr-un proces mult mai strict şi pot fi însoţite de renegocieri ale bugetelor...


Va urma!