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

Unde se termină cerinţele clientului şi unde începe designul?

Urmărind capitolul anterior, probabil că fiecare dintre noi şi-a ridicat problema "unde se termină această descompunere?" sau "când se poate spune că detalierea este suficientă?". Acest lucru încerc să îl clarifica în capitolul de faţă.

Urmărind descompunerea, de sus în jos, putem observa că la orice nivel ne-am situa, pe nivelul imediat inferior avem o propunere de soluţie. Astfel, Cunoaşterea necesarului real (SP1) se poate rezolva prin Cunoaşterea vânzărilor din trecut (SP1.1), Cunoaşterea comenzilor curente de la clienţi (SP1.2) şi Cunoaşterea stocului actual(SP1.3). Prin urmare, nivelul inferior este răspunsul la întrebarea "CUM?" privitoare la nivelul curent. Dacă ne poziţionăm pe nivelul Cunoaşterea vânzărilor din trecut (SP1.1) şi ne punem întrebarea "cum rezolvăm această problemă?", răspunsul se găseşte pe nivelul inferior: prin Introducerea facturilor de vânzare (C1) şi Generare raport de vânzări (C2). Şi aşa mai departe.

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?" privitoare la nivelul curent (sau "ce se rezolvă prin..."). De pildă, Introducerea facturilor de vânzare (C1) este un element care ajută la Cunoaşterea vânzărilor din trecut (SP1.1).

Prin urmare, pornind de la problema iniţială, fiecare nivel de descompunere reprezintă o soluţie, dar în acelaşi timp o problemă. Totuşi, la un anumit nivel trebuie să se găsească soluţia finală.
Judecând lucrurile practic, ar fi o eroare să ne închipuim că putem să lungim lucrurile la nesfârşit. Undeva trebuie să se termine (aşa cum bugetul alocat proiectului se termină sigur undeva).


PROBLEMĂ vs. SOLUŢIE

Privind lucrurile din punctul de vedere al întregului proiect, soluţia ultimă a problemei clientului este desigur aplicaţia software în sine, programul executabil livrat clientului. Din punctul de vedere al analistului însă, programul executabil final este punerea în practică, întocmai, a unui model (a unei specificaţii), ceea ce conduce la ideea că, pentru analist, dar nu numai pentru el, soluţia ultimă a problemei clientului se găseşte într-o specificaţie, ce urmează a fi modelul pentru dezvoltarea executabilului – altfel spus, proiectul viitorului executabil.

Aşadar, putem împărţi spaţiul dintre problema iniţială a clientului şi soluţia, constând în modelul viitoarei aplicaţii software în două părţi distincte: PROBLEMA şi SOLUŢIA. În zona PROBLEMEI vom situa acele specificaţii care descriu problema clientului iar în zona SOLUŢIEI acele specificaţii care descriu modul de rezolvare a PROBLEMEI. Trebuie spus, din start că nu toate specificaţiile din zona SOLUŢIEI sunt de competenţa analistului. Dimpotrivă, cea mai mare parte a soluţiei este concepută şi descrisă de către arhitecţi software sau designeri de soluţii software.


De la cerinţele clientului la cod

Probabil că, în continuarea exemplului de la capitolul anterior, detalierea pe încă un nivel ar însemna descrierea modului de rezolvare a problemelor prin soft, detalierea funcţiilor pe care viitorul sistem le va avea:

Descompunerea problemei clientului pănă la funcţii software

Acest nou nivel de detaliere începe deja descrierea propriu-zisă a aplicaţiei software. La acest nivel, după descrierea pe sub-nivele a PROBLEMEI, începe descrierea SOLUŢIEI.


Nivelurile cerinţelor vs. documente de specificaţii

Pentru diversele etape, atât în privinţa evoluţiei în timp a cerinţelor cât şi în privinţa detalierii informaţiile şi documentele implicate sunt următoarele:



Pentru a elimina orice confuzie în legătură cu specificaţiile funcţionale, trebuie spus că acestea nu conţin detalierea a cum se dezvoltă acestea, nu conţin elemente de design ci sunt văzute ca funcţionalităţi pe care Sistemul software trebuie să le posede pentru a permite realizarea task-urilor utilizatorilor. Sistemul este văzut aici ca o cutie neagră – ştim ce funcţii trebuie să îndeplinească dar nu ştim cum.

Mai trebuie spus că de la o metodologie de lucru la alta tipurile, conţinutul documentelor sau chiar limitele dintre PROBLEMĂ şi SOLUŢIE pot să difere. În unele cazuri PROBLEMA se încheie cu specificarea use case-urilor (ceea ce înseamnă acoperirea task-urilor utilizatorilor), în altele odată cu Specificaţiile funcţionale.

Personal, deşi susţin cu tărie că analistul trebuie să se limiteze la zona de business vă recomand cu căldură să vă inspiraţi din metodologiile "clasice": RUP, MSF etc. sau din standardele existente (de pildă IEEE Std 830-1993: IEEE Recommended Practice for Software Requirements Specifications). Aceasta vă va ajuta să vă formaţi propria părere şi să înţelegeţi cum este mai bine să împărţiţi sarcinile în organizaţia dumneavoastră.


Problema clientului este legată întotdeauna de business

În principiu, treaba analistului se termină acolo unde încep să fie vizibile interacţiunile dintre utilizatori şi viitorul sistem informatic. Din acest punct începe treaba arhitectului software.

În fond, specificaţiile cerinţelor se termină, logic, acolo unde clientul nu poate sau nu trebuie să impună propriul punct de vedere.
De exemplu, structura bazei de date, variabile utilizate, componente software reutilizabile, împărţirea pe module nu sunt lucruri asupra cărora clientul trebuie să se pronunţe (cu rare şi nedorite excepţii).

Întotdeauna se va avea în vedere că documentul de specificaţii trebuie asumat şi semnat de către client în cunoştinţă de cauză, în deplină înţelegere a conţinutului său, motiv pentru care nu i se poate pretinde asumarea soluţiilor tehnice sau validarea unor detalii care depăşesc capacitatea tehnică a acestuia.

În concluzie, documentaţia care precede dezvoltarea propriu-zisă a codului unei anumite aplicaţii software descrie, pe de o parte PROBLEMA, pe de altă parte SOLUŢIA. Rolul Analizei este să descrie cât mai corect şi complet PROBLEMA, restrângând doar din punct de vedere al business-ului clientului spaţiul SOLUŢIILOR posibile, fără să introducă restricţii tehnologice.

În general, PROBLEMA clientului este o problemă de business nu o problemă de tehnologie.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Nivelurile cerinţelor
Articolul următor:  Riscuri legate de cerinţe



  


  Adauga un comentariuSpune-ti parerea despre acest articol!