Facultatea de Informatic Universitatea Al I Cuza Iai

Facultatea de Informatică Universitatea “Al. I. Cuza” - Iaşi Tehnologii de Elaborare a Proiectelor – Cursul I Partea 3 – Adrian Iftene adiftene@info. uaic. ro

Recapitulare l Etapele dezvoltării programelor – – – Analiza cerinţelor Proiectarea Scrierea codului Testare Întreţinere Toate etapele dezvoltării programelor depind de analiza cerinţelor. 2

Începutul unui proiect l Un proiect poate începe: – – l Aceasta idee poate fi: – – l 3 cu o idee a clientului cu o idee a unei echipe de dezvoltare clara, bine definită vaga, prost definită Pentru a continua cu succes, este nevoie de ingineria cerinţelor.

Specificaţia bună l l l 4 Spune ce trebuie făcut, nu cum Este clara (ne-ambiguă) Este suficient de detaliata Este completa Exemplu (sau contra-exemplu? ): Scrieţi un program Pascal care oferă funcţionalitatea unei agende telefonice personale. Ar trebui sa implementeze funcţii pentru căutarea unui număr si pentru introducerea unui nou număr de telefon. Programul va oferi o interfaţa utilizator prietenoasa.

Detalii de implementare la analiză? l NU – – – l DA – – – 5 Clientul nu este competent in detalii tehnice Clientul nu poate fi de acord in cunoştinţă de cauza cu stipulările tehnice din specificaţii (Ştiu secretarele COM? Ştiu şoferii ciclul Carnot? ). E necesar sa restrângem mulţimea posibilelor soluţiile tehnice? Este nevoie sa integram intr-un sistem existent Timpul de dezvoltare depinde de implementare Întreţinerea (costul) depinde de implementare

Responsabilităţile Analistului să extragă şi să clarifice cerinţele clientului l să ajute la rezolvarea diferenţelor de opinie între clienţi şi utilizatori. l să sfătuiască clientul despre ce este tehnic posibil sau imposibil l să documenteze cerinţele l să negocieze şi să obţină o înţelegere cu clientul. l 6

Activităţile Analistului Ascultare: Înregistrează cerinţele clientului. l Reflectare: Traduce cerinţele in limbaj tehnic. Verifica pertinenţa. l Scriere: Se cade de acord asupra formulărilor. l Repetă până când se ajunge la o înţelegere cu clientul în ceea ce priveşte cerinţele. l 7

Probleme Potenţiale Procesul iterativ poate fi lung şi complicat l Negocieri (dure) l Diferenţa culturală dintre client şi analist l Diferenţe între cerinţele clientului şi ale utilizatorilor l Filmele SF văzute de client l Filmele SF văzute de programatori l 8

Rezultatul Analizei l l l Document de specificare a cerinţelor Acest document este folosit ca referinţa Provocări – Nivelul de detaliu l l – Audienta documentelor l – 2 versiuni: una pentru client, alta pentru dezvoltatori? Notaţia folosită l 9 Mare: mai precis, obţinut mai greu, munca inutila Mic: prea vag, nu poate ghida eficient dezvoltarea Informală, semi-formală, formală

Tipuri de Cerinţe l Cerinţe funcţionale – l Cerinţe privind datele – – l – Cerinţe de respectat ad-literam Influenţează direct implementarea Recomandări – 10 Formatul datelor la intrare/ieşire Formatul datelor din interiorul sistemului Constrângeri – l Ce trebuie sa facă sistemul Ajuta la luarea deciziilor de proiectare când sunt mai multe opţiuni

Exemple l Cerinţe funcţionale – – l Cerinţe privind datele – – l – Implementarea se va realiza folosind un limbaj orientat obiect. Metodologia de dezvoltare va fi SCRUM Recomandări – 11 Datele vor fi exportate in format XML Datele din tampoanele de intrare şi ieşire vor fi criptate Constrângeri – l Sistemul se va opri in maxim 5 secunde după ce temperatura procesorului atinge 80 grade Celsius. Sistemul va permite căutarea şi afişarea titlurilor cărţilor scrise de un anumit autor. Se va folosi cât mai puţină memorie

Scenarii de Utilizare l Prezintă sistemul din perspectiva utilizatorului înţelegem ce se cere l Extragerea cerinţelor, testare l Documentaţia utilizatorilor l Prezentarea sistemului utilizatorilor 12

Noţiuni de Bază l Actor – Reprezintă o entitate exterioara cu care sistemul interacţionează. Poate fi: l l l Scenariu de utilizare – – 13 un utilizator uman un alt sistem (hardware/software) O descriere a modului in care un actor interacţionează cu sistemul O descriere a modului in care sistemul trebuie să răspundă acestor interacţiuni O viziune independenta de implementare a modului in care se va comporta sistemul O secvenţa de acţiuni care un rezultat vizibil pentru un actor

Scenariu de utilizare: cum arată l text: diferite formate – – – l 14 Pe scurt: un paragraf care descrie scenariul principal de succes Cazual: mai multe paragrafe care acoperă mai multe scenarii şi-n caz de excepţie se alege o anumită alternativă Detaliat Total: cel mai elaborat; sunt detaliaţi toţi paşii şi toate variantele; sunt specificate pre-condiţiile si post-condiţiile grafic: diagrame UML

Exemplu: scenariu de utilizare pe scurt l 15 Un utilizator găseşte site-ul unei agenţii de turism care oferă pachete de vacanta. Agenţia ii cere utilizatorului sa completeze un formular cu datele vacantei si destinaţia dorita. Agenţia interoghează apoi serviciile web ale liniilor aeriene si ale companiilor hoteliere si-i prezintă utilizatorului o lista de opţiuni. Utilizatorul isi alege opţiunea favorita. Agenţia face rezervările si ii prezintă utilizatorului o lista cu modalităţile de plată. Utilizatorul alege o modalitate de plata si-i furnizează agenţiei informaţiile necesare. Agenţia confirma rezervările, solicita efectuarea plaţii si ii da utilizatorului toate informaţiile de care nevoie pentru a pleca in vacanta.

Exemplu: scenariu cauzal l l Scenariul principal de succes: (vezi slide-ul anterior) Scenarii alternative: – – 16 Dacă locul rezervat in avion nu mai este disponibil, utilizatorul va alege alt zbor Dacă nu mai este disponibila camera rezervata, utilizatorul va alege alta Dacă utilizatorul nu are suficienţi bani, agenţia va anula rezervările. . .

Scenariu total detaliat l Conţine: ID (nr), Nume (scurta fraza verbala) – Informaţii caracteristice (Descriere, Domeniu, Actori. . . ) – Principalul scenariu de succes – Extensii (situaţii de excepţie) – Alte informaţii – 17

Cum vom face noi? l 1. 2. 3. 18 NU vom face total detaliat (nu vom avea un nivel prea mare de detaliere): Vom prezenta contextele în care este dorită o anumită cerinţă Paşii necesari pentru ca această cerinţă să fie îndeplinită Extensiile (situaţiile de excepţie care pot apare)

Exemplu - Teatrul îşi creează un cont l Obiectiv/Context Teatrul obţine locaţia împreuna cu un cod unic de înregistrare via email sau telefon. Teatrul furnizează datele si ii este creat un cont. l Scenariu/Pasi 1. 2. 3. l 5. 1. 3 Extensii 1. 19 Teatrului ii este prezentat un formular pentru a fi completat cu scopul de a-si crea un cont pe care sa il folosească ulterior pentru a adăuga noi informaţii. Acest cont trebuie in mod obligatoriu creat la prima conectare, si este necesar celorlalte conectări. (se creează in mod obligatoriu si unic la prima conectare) Teatrul furnizează informaţiile necesare şi foloseşte codul primit pentru a justifica faptul ca are permisiunea de a-si crea un cont pentru teatre. Teatrului ii este realizat un cont şi are acum posibilitatea de a încărca piese. Daca nu este corect codul, teatrul este rugat să contacteze administratorul pentru a obţine un cod.

Etapa 1: Fişa Cerinţelor 1. 2. 3. 20 Stabiliţi tema proiectului pe care-l veţi realiza După modelul exemplelor de pe site realizaţi Fişa Cerinţelor necesară proiectului ales TERMEN LIMITĂ: 3 Noiembrie

Utile: l l 21 Pagina cursului: http: //thor. info. uaic. ro/~adiftene Adresa de e-mail: adiftene@info. uaic. ro Cabinet: Etajul 7, C 904 Telefon cabinet: 201531