Procesele ingineriei cerin ţelor

1. Procesele ingineriei cerinţelor

2. Obiective • Descrierea principalelor activităţi ale ingineriei cerinţelor şi a relaţiilor între acestea • Introducerea tehnicilor pentru identificarea şi analiza cerinţelor • Validarea cerinţelor şi rolul revizuirii cerinţelor • Rolul managementului cerinţelor ca suport al altor procese ale ingineriei cerinţelor

3. Subiecte tratate • Studiul de fezabilitate • Identificarea şi analiza cerinţelor • Validarea cerinţelor • Managementul cerinţelor

4. Procesul ingineriei cerinţelor • Scop: crearea şi întreţinerea unui document al cerinţelor sistem. • Variază funcţie de: • domeniul aplicaţiei • persoanele implicate • organizaţia care dezvoltă cerinţele. • Activităţi generice comune tuturor variantelor procesului: • Identificarea cerinţelor; • Analiza cerinţelor; • Validarea cerinţelor; • Managementul cerinţelor.

5. Procesul ingineriei cerinţelor

6. Perspectivă alternativă asupra procesului ingineriei cerinţelor • Activităţile organizate sub forma unui proces iterativ în jurul unei spirale împărţiţă în trei zone. • Timpul şi efortul alocat fiecărei activităţi într-o iteraţie depinde de: • etapa din cadrul procesului • tipul sistemului dezvoltat.

7. Perspectivă alternativă asupra procesului ingineriei cerinţelor

8. Perspectivă alternativă asupra procesului ingineriei cerinţelor • În etapele iniţiale: înţelegerea • cerinţelor economice generale • cerinţelor non-funcţionale • cerinţelor utilizator. • În etapele ulterioare: • ingineria cerinţelor sistem • modelarea sistemului.

9. Perspectivă alternativă asupra procesului ingineriei cerinţelor • Potrivită abordărilor în care cerinţele sunt dezvoltate pe diferite nivele de detaliu. • Numărul de iteraţii în spirală poate varia => spiralapoate fi părăsită după ce au fost identificate o parte sau toate cerinţele utilizator. • Dacă activitatea de prototipare este extinsă pentru a include dezvoltare iterativă=> modelul permite ca cerinţele şi implementarea sistemului să fie dezvoltate în paralel.

10. Studiul de fezabilitate • Studiul de fezabilitate decide dacă sistemul propus merită sau nu a fi dezvoltat. • Este un studiu scurt şi concentrat care verifică dacă: • sistemul contribuie la obiectivele organizaţionale; • sistemulpoate fi realizat utilizând tehnologiile curente şi bugetul alocat; • sistemul poate fi integrat cu alte sisteme utilizate.

11. Implementarea studiului de fezabilitate • Intrări: • Cerinţe business preliminare; • Scurtă descriere a sistemului; • Schiţarea modului în care sistemul va sprijini procesele economice. • Rezultat: • Raport care recomandă continuarea sau renunţarea la dezvoltarea sistemului.

12. Implementarea studiului de fezabilitate • Bazat pe: • evaluarea informaţiilor despre ce se cere, • colectarea de informaţii, • scrierea unui raport. • Întrebări puse persoanelor din organizaţie: • Ce se întâmplă dacă sistemul nu ar fi implementat? • Care sunt problemele procesului curent? • Cum va ajuta sistemul propus? • Care vor fi problemele la integrarea cu alte sisteme? • Sunt necesare tehnologii noi? Ce calificări? • Ce facilităţi trebuie sprijinite de către noul sistem? Ce facilităţi NU e necesar a fi sprijinite de către noul sistem?

13. Identificarea şi analiza cerinţelor Numită şi extragerea sau descoperirea cerinţelor. Implică activităţi în comun ale personalului tehnic cu clienţii pentru a înţelege: • domeniul aplicaţiei; • serviciile pe care sistemul trebuie să le ofere; • constângerile operaţionale ale sistemului. Stakeholder-ii (părţile interesate, partenerii)=persoanele şi asociaţiile implicate. Exemple: • Utilizatori finali • Manageri • Ingineri implicaţi în întreţinere • Experţi ai domeniului • Sindicate, etc.

14. Analiza cerinţelor: problematică • Părţile interesate nu ştiu exact ce vor. • Părţile interesateexprimă cerinţele în termenii lor propri. • Diferite părţi interesate pot avea cerinţe contradictorii (conflictuale). • Factorii organizaţionali şi politici pot influenţa cerinţele sistemului. • Modificarea cerinţelor în timpul procesului de analiză: • Pot să apară noi părţi interesate. • Se poate schimba contextul economic.

15. Spirala cerinţelor

16. Activităţile procesului • Descoperirea cerinţelor • Interacţiune cu părţile interesate pentru a descoperi cerinţele acestora. În acest stadiu sunt descoperite cerinţele de domeniu.. • Clasificarea şi organizarea cerinţelor • Gruparea cerinţelor aflate în relaţie şi organizarea lor în cluster-e coerente. Metodă: Identificare cerinţe comune.Utilizarea unui model arhitectural al sistemului pentru a identifica subsistemele şi a asocia cerinţe fiecărui subsistem.. Prioritizare şi negociere • Prioritizareacerinţelor şi rezolvarea conflictelor între acestea. • Documentarea cerinţelor • Cerinţele sunt documentate şi constituie intrare în următoarea buclă a spiralei.

17. Descoperirea cerinţelor Def. Procesul de culegere de informaţii despre sistemele propuse şi cele existente şi distilarea cerinţelor utilizator şi sistem din aceste informaţii. • Surse de informaţii: • Documentaţii; • Părţile interesate în sistem (stakeholders); • Specificaţii ale unor sisteme similare.

18. Exemplu: Părţile interesate pentru sistemul ATM • Clienţii băncii • Representanţi ai altor bănci • Managerii băncii • Personalul contabil • Administratorii bazei de date • Managerii pentru securitate • Departmentul de vânzări (marketing) • Inginerii de la întreţinere hardware şi software • Reglementatorii bancari

19. Puncte de vedere Def. Punctele de vedere sunt un mod de a structura cerinţele astfel încât să reprezinte perspectivele diferitelor părţi interesate. Părţile interesate pot fi clasificate ca diferite puncte de vedere. Obs. Fiecare punct de vedere oferă o nouă perspectivă asupra sistemului; aceste perspective nu sunt complet independente – de obicei se suprapun propunând astfel cerinţe comune. Această analiză multi-perspectivă este importantă deoarece nu există un mod unic corect de a analiza cerinţele sistemului.

20. Tipuri de puncte de vedere • Puncte de vedere interactor Persoane sau alte sisteme care interacţionează direct cu sistemul. Exemplu: într-un sistem ATM, punctul de vedere ale clientului, punctul de vedere al bazei de date. • Puncte de vedere indirecte Părţile interesate care nu utilizează sistemul direct dar care influenţează cerinţele. Exemplu: într-un sistem ATM, punctul de vedere al managementului, punctul de vedere al personalului (staff). • Puncte de vedere de domeniu Caracteristicile şi constrângerile de domeniului care influenţează cerinţele. Exemplu: într-un sistem ATM, standarde pentru comunicare inter-bancară.

21. Identificarea punctelor de vedere • Identificarea utilizează: • Furnizorii şi beneficiarii serviciilor sistem; • Sistemele care interacţionează direct cu sistemul specificat; • Regulamenteşi standarde; • Suresle cerinţelor economice şi non-funcţionale; • Inginerii care trebuie să dezvolte şi să întreţină sistemul; • Marketing şi alte puncte de vedere economice.

22. Exemplu: Ierarhia punctelor de vedere la sistemul LIBSYS

23. Intervievare • În intervievare formalăsau informală, echipa pentru ingineria cerinţelor (RE team)pune întrebări părţilor interesate referitoare la sistemul pe care îl utilizează şi la cel care trebuie dezvoltat. • Există două tipuri de interviu: • Interviu închis: se caută răspunsuri la un set de întrebări predefinite. • Interviu deschis: nu există o agendă predefinităşi este explorat un domeniu (range) al problematicii împreună cu părţile interesate.

24. Interviuri în practică • Normal, o combinaţie de interviu închis şi deschis. • Interviurile sunt utile pentru a înţelege în general ceea ce fac părţile interesate şi a modul în care ar putea interacţiona cu sistemul. • Interviurile nu sunt bune pentru a înţelege cerinţele sistem • Inginerii de cerinţe nu pot înţelege terminologia specifică a domeniului; • Anumite cunoştinţe din domeniu sunt atât de familiare încât sunt persoanele din domeniul respectiv le exprimă cu dificultate în cuvinte sau consideră că nu trebuie exprimate explicit.

25. Intervieviatori eficienţi • Intervieviatorii trebuie să fiecu mintea deschisă, să dorească să asculte părţile interesateşi să nu aibă idei preconcepute despre cerinţe. • Trebuie să formuleze întrebări sau propuneri concrete şi să nu se aştepte pur şi simplu să li se răspundă la întrebarea ‘ce doriţi’.

26. Scenarii Def. Scenariile sunt exemple din viaţa reală referitoare la modul în care sistemul poate fi utilizat. • Trebuie să includă • O descrierea situaţiei iniţiale; • O descrierea fluxului normal de evenimente; • O descriere a ceea ce poate funcţiona greşit; • Informaţii despre alte activităţi concurente; • O descriere a stării la finalizarea scenariului.

27. Exemplu: scenariu în cadrul sistemului LIBSYS (1)

28. Exemplu: scenariu în cadrul sistemului LIBSYS (2)

29. Cazuri de utilizare • Cazurile de utilizare sunt tehnici UML bazate pe scenariu care identifică actorii implicaţi într-o iteracţiune şi care descriu interacţiunea însăşi. • Un set de cazuri de utilizare ar potea descrie toate interacţiunile posibile cu sistemul. • Pentru a adăuga detalii la cazurile de utilizare pot fi folosite diagrame de secvenţe care să arate secvenţa de procesare a evenimentului în sistem.

30. Cazul de utilizare: imprimare articol

31. Cazurile de utilizare ale sistemului LIBSYS

32. Secvenţa de imprimare articol

33. Factori socialişi organizaţionali • Sistemele software sunt utilizate într-un context social şi organizaţional. Aceasta poate influenţa sau chiar domina cerinţele sistem. • Factorii socialişi organizaţionalinu constituie un punct de vedere ci influenţează toate punctele de vedere. • Analiştii buni trebuie să fie sensibili la aceşti factori, fără a exista însă un mod sistematic de a aborda analiza lor.

34. Etnografie • Sociologii petrec un timp considerabil observând şi analizând modul în care oamenii lucrează. • Oamenii nu trebuie să explice sau să formuleze în cuvinte modul în care lucrează. • Se pot observa factori socialişi organizaţionaliimportanţi. • Studii etnograficearată că modul de lucru este de obicei mai bogat şi mai complex decât este sugerat prin simple modele ale sistemului.

35. Etnografie focalizată • Dezvoltată într-un proiect care studiază procesul de control al traficului aerian. • Combină etnografia cu prototiparea. • Ca rezultat la dezvoltarea prototipului apar întrebări fără răspuns care focalizează analiza etnografică. • Problemacu etnografia este ca aceasta studiază practicile existente, care pot avea unele baze istorice ce nu mai sunt relevante.

36. Etnografieşi prototipare

37. Domeniulde aplicare a etnografiei • Cerinţele care sunt derivate din modul în care oamenii lucrează în realitate şi nu din modul în care definiţiile procesului sugerează că ar trebui să lucreze. • Cerinţele care sunt derivatedin cooperarea cu şi conştientizarea activităţilor altor persoane.

38. Validarea cerinţelor • Se ocupă cu demonstrarea faptului că cerinţele definesc sistemul pe care clientul îl doreşte cu adevărat. • Costurile erorilor la nivelul cerinţelor este ridicat, deci validarea este foarte importantă • Eliminarea unei erori la nivelul cerinţelor după livrare ar putea ajunge până la 100 de ori costul eliminării unei erori de implementare. Obs. Validarea se suprapune cu analiza în sensul descoperirii unor probleme legate de cerinţe.

39. Verificarea cerinţelor • Validitate. Furnizează sistemul acele funcţii care oferă cel mai bun suport necesităţilor clientului? • Consistenţă. Există conflicte între cerinţe? • Completitudine. Sunt incluse toate funcţiile solicitate de client? • Realism. Cerinţele pot fi implementate cu bugetul şi tehnologiile disponibile ? • Verificabilitate. Cerinţele pot fi verificate?

40. Tehnici pentru validarea cerinţelor • Revizuiri ale cerinţelor • Analiză manuală sistematică a cerinţelor. • Prototipare • Utilizarea unui model executabil al sistemului pentru a cerifica cerinţele. • Generare de cazuri de testare • Dezvoltarea de teste ale cerinţelor pentru a verifica testabilitatea. Obs. Aceste tehnici pot fi utilizate în mod conjugat sau individual.

41. Revizuiri ale cerinţelor • Pe perioada formulării definiţiilor cerinţelor sunt necesare revizuiri regulate ale acestora. • În revizuiri trebuie implicat atât personalul de la client cât şi cel de la contractor. • Revizuirile pot fi formale (cu documete complete) sau informale. O comunicare bună între dezvoltatori, clienţi şi utilizatori poate rezolva probleme încă din stadii incipiente.

42. Verificări la revizuire • Verificabilitate. Este cerinţa testabilă în mod real? • Înţelegere. Este cerinţa înţeleasă corespunzător? • Posibilitate de urmărire. Este specificată clar originea cerinţei? • Adaptabilitate. Poate fi cerinţa modificată fără a genera un impact considerabil asupra altor cerinţe?

43. Managementul cerinţelor Def. Managementul cerinţelor este procesul de gestionare a cerinţelor în schimbare în timpul procesului de inginerie a cerinţelor şi a dezvoltării sistemului. • Cerinţele sunt în mod inevitabil incomplete şi inconsistente • Cerinţe noi apar în timpul procesului pe măsură ce necesităţile economice (business)se modifică şi se dezvoltă o mai bună înţelegere a sistemului; • Punte de vedere diferite pot avea cerinţe diferite iar acestea sunt deseori contradictorii.

44. Modificarea cerinţelor • Prioritateacerinţelor diferitelor puncte de vedere se modifică în timpul procesului de dezvoltare. • Clienţii sistemului pot specifica cerinţe dintr-o perspectivă economică, care pot fi în conflict cu cerinţele utilizatorilor finali. • Contextul economic şi tehnic se schimbă în timpul dezvoltării sistemului.

45. Evoluţia cerinţelor

46. Cerinţe durabile şi volatile • Cerinţe durabile. Cerinţe stabile derivate din activitatea de bază a organizaţiei clientului. Exemplu:un spital va avea întotdeauna doctori, asistente, etc. Pot fi derivate din modelele domeniului. • Cerinţe volatile. Cerinţe care se schimbă în timpul dezvoltării sau utilizării sistemului. Exemplu: Într-un spital, cerinţele derivate din politica de asigurare a sănătăţii.

47. Clasificarea cerinţelor

48. Planificarea managementului cerinţelor • În timpul procesului de inginerie a cerinţelor trebuie planificate: • Identificarea cerinţelor • Cum se identifică cerinţele in mod individual; • Un proces de management al schimbărilor • Procesul de urmat la analiza unei schimbări la cerinţe; • Politicile de urmărire • Cantitatea de informaţii referitoare la relaţiile între cerinţe păstrată; • Instrumentul CASE suport • Instrumentul suport necesar pentru a gestiona schimbarea cerinţelor;

49. Posibilitatea de urmărire • Posibilitatea de urmărire este legată de relaţiile dintre cerinţe, de sursele lor şi de proiectarea sistemului • Posibilitatea de urmărire a sursei • Legături de la cerinţe la părţile interesate care le-au propus; • Posibilitatea de urmărire a cerinţelor • Legături între cerinţe dependente; • Posibilitatea de urmărire a proiectării • Legături de la cerinţe la artefactele proiectării;

50. O matrice a posibilităţii de urmărire