Teorie (2-3 subiecte de cate 1/2 pag. fiecare): 1. Fazele de dezvoltare ale unui sistem software.Scurta descriere a fiecareia.

Raspuns: - Analiza cerintelor: determinarea cerintelor, specificarea cerintelor, CASE, documentatia de specificare a cerintelor, asigurarea calitatii software-ului - Proiectarea sistemului: descrierea structurii sistemului de implementat, datele care sun prelucrate in sistem, interfetele intre componentele sistemului, algoritmii folositi. In practica distinctia intre analiza si proiectare nu este foarte clara. Proiectarea detaliata adauga detalii modelului rezultat din analiza cerintelor, proiectare arhitecturala, gestiunea relationarii partilor aflate in diverse stadii de dezvoltare Traceability management. - Implementarea: in mare parte programare, generare de cod, testare si depanare. - Instalarea si integrarea: integrarea - se asambleaza aplicatia din setul de componente implementate si testate in prealabil. Instalarea inmanarea sistemului functional beneficiarilor pentru utilizarea in productie (instalarea softului, training pt. beneficiar) - Operarea si mentenanta: - Operarea inlocuirea sistemului precedent in munca de zi-cu-zi. - Mentenanta corectiva, adaptiva, perfectiva; Sisteme mostenite (legacy systems). - Testarea: - stub: o piesa de cod care simuleaza rolul unei componente neimplementate inca. - driver- o piesa de cod care conduce integrarea a.i. versiunea increment(build) poate primi datele si contextul care ar fi furnizate de componentele neimplementate inca(in testarea bottom up). - teste de suport (test harness) : teste care utilizeaza stubs si drivers (utile doar in timpul integrarii). Faze independente, aplicate pe toate nivelele: - Testarea si validarea - Mangementul 2. Modele de dezvoltare in cascada.Prezentare, avantaje, dezavantaje. Raspuns: Cascada cu reactie (feedback) si cascada cu suprapuneri (reactie, suprapuneri si prototipuri) Avantaje: Simplu de utilizat, usor de gestionat datorita rigiditatii, fazele si procesele sunt terminate pe rand(usor de urmarit), bun pentru proiecte mici unde cerintele se inteleg usor

Dezavantaje: modificarea cerintelor este greu de gestionat, nu sprijina dezvoltarea OO, nu se produc prototipuri executabile decat foarte tarziu. 3. Modele iterative. Schema de principiu, avantaje, dezavantaje. Raspuns: Iteratia in IS este o repetitie a unui proces cu scopul de a adauga functionalitati unui produs software. Ciclul de viata iterativ presupune cresteri succesive (increments), versiuni imbunatatite la sfarsitul fiecarei iteratii, presupune versiuni succesive (builds) sub forma de cod executabil dupa fiecare iteratie. Dezavantaj : faze rigide care nu se suprapun. Presupune iteratii scurte intre intervale succesive (zile, sapt). Spirala, IBM Rational Unified Process, Model Driven Architecture, Agil lifecycle with short cycles. 4. Tipuri de cerinte software. Utilitatea fiecarui tip. Raspuns: - Cerinte utilizator : Afirmatii in limbaj natural si diagrame a serviciilor oferite de sistem laolalta cu constrangerile operationale, Scrise pentru clienti. Se adreseaza: managerilor clientului, utilizatorilor finali, inginerilor clientului, managerilor de contracte, proiectantilor de sistem. - Cerintele sistemului : un document structurat stabilind descrierea detaliata a functiilor sistemului, serviciile oferite si constrangerile operationale, poate fi parte a contractului cu clientul. Se adreseaza : utilizatorilor finali, inginerilor clientului, proiectantilor de sistem, programatorilor. 5. Definiti termenii de cerinte functionale, non-functionale si de domeniu. Raspuns: - Cerinte functionale: afirmatii despre servicii pe care sistemul trebuie sa le contina, cum raspunde unor intrari si cum reactioneaza in anumite situatii. Descriu functionalitatea sistemului si serviciile oferite; depind de tipul softului, de utilizatorii avuti in vedere si de tipul sistemului pe care e folosit softul. Cerintele functionale ale utilizatorilor pot fi descrieri de ansamblu, dar cele ale sistemului trebuie sa descrie in detaliu serviciile oferite. - Cerinte non-functionale: Constrangeri ale serviciilor si functiilor oferite de sistem cum ar fi constrangeri de timp, constrangeri ale procesului de dezvoltare, standarde etc. Definesc proprietati si constrangeri ale sistemului (fiabilitate, timp de raspuns etc). La intocmirea lor se va tine cont de un anumit program CASE, limbaj de programare sau metoda de dezvoltare. Pot fi mai critice decat cele functionale, daca nu sunt indeplinite, sistemul nu va fi util scopului pentru care a fost dezvoltat.

- Cerinte de domeniu: Cerinte impuse de domeniul aplicatiei care reflecta caracteristicile acestuia. Derivate din domeniul aplicatiei, descriu caracteristici si facilitati legate de domeniu. Pot fi cerinte functionale noi, constrangeri sau cerinte deja existente. Daca nu sunt indeplinite, sistemul va fi nefunctional. 6. Tipuri de diagrame UML. Scurta prezentare a fiecareia. Raspuns: - Class Diagram: exprima in mod static structura modelelor (numita si model de stare). Vizualizeaza clase (si interfete), structura lor interna si relatiile cu alte clase. A Class is a descriptor for a set of objects with similar structure, behaviour and relationships. Atributul este o caracteristica (tipizata) structurala a unei clase. Operatia este o caracteristica comportamentala a unei clase. - Use Case Diagram : Principala tehnica UML de modelare la nivel de analiza a comportamentului. Puterea lor sta in specificatiile textuale asociate reprezentarii grafice. Repr. O piesa importanta in definirea functionalitatii sistemului. Un Actor este un rol pe care cineva sau ceva il joaca relativ la un Use Case. El comunica cu un caz de utilizare (communicate) si asteapta o reactie de la acesta (o val. sau alt rezultat observabil). - Interaction Diagram: Repr. principala tehnica de modelare la nivel de proiectare a comportamentului. Sunt 2 tipuri : Sequence si Collaboration. Sequence sunt reprezentari grafice a secventei mesajelor dintre obiecte. Obiectul care receptioneaza va activa metoda corespunzatoare acestuia. Timpul in care fluxul de control ajunge la un obiect se numeste activare. - Statechart Diagram : nu sunt specifice modelarii OO. Surprind starea unui obiect si actiunile care conduc la schimbarea acesteia. Starea unui obiect se schimba cand se modifica valoarea unor atribute ale sale. Starea are o anumita durata care corespunde cu intervalul de timp dintre doua tranzitii. - Activity Diagram : sunt automate cu stari care reprezinta un calcul, actiunile executate si tranzitiile rezultate din efectuarea tranzitiilor. In mod normal o diagrama Activity este atasata unei implementari de operatii sau unui caz de utilizare. Action states sunt actiuni care nu trebuie intrerupte de evenimente externe, nu trebuie sa aiba nicio tranzitie bazata pe evenimente explicite. Tranzitiile de iesire dintr-o actiune de stare sunt rezultatul incheierii activitatilor din acea stare. - Implementation Diagram : Sunt modele pentru implementarea fizica a sistemului. Evidentiaza componentele sistemului, structura lor si dependentele. Sunt de 2 tipuri : Component (arata structura componentelor, inclusiv interfetele lor si implementarea dependentelor) si Deployment (arata instalarea pentru rulare pe calculatoarele din retea)

7. Definiti caracteristicile unui system, luate in considerare la proiectare. Raspuns: Performanta: localizarea operatiilor critice si minimizarea comunicatiilor. Se recomanda utilizarea componentelor cu o granularitate mare. Securitatea: Utilizarea unei arhitecturi stratificate cu plasarea secventelor critice pe nivelele interne. Siguranta: Localizarea detaliilor critice dpdv al sigurantei intr-un nr. mic de subsisteme. Disponibilitatea: Include componente redundante si mecanisme tolerante la erori Mentenabilitatea: utilizarea unor componente fine, usor de intretinut. 8. Modele de arhitecturi. Raspuns: Structurale (statice): scot in evidenta componentele majore ale sistemului. De proces (dinamice): arata structura proceselor sistemului De interfete: definesc interfetele diverselor sub-sisteme De relatii (ex: module de fluxuri de date): indica relatiile intre sub-sisteme De distributie: arata cum sunt distribuite sub-sistemele pe diversele sisteme de calcul.

9. Principiile metodelor de dezvoltare "Agile". Raspuns: Implicarea clientului: clientul trebuie sa fie implicat activ in procesul de dezvoltare. Rolul sau este acela de a furniza si prioritiza cerintele, resp. de a evalua iteratiile sistemului. Livrare incrementala: Software-ul este livrat in variante incrementale Accent pe oameni nu pe proces: Abilitatile echipei de dezvoltare trebuie recunoscute si exploatate. Echipa trebuie lasata sa isi stabileasca propria cale de a lucra la proiect.

Includerea schimbarilor: Sistemul trebuie proiectat a.i. sa permita schimbarea cerintelor. Mentinerea simplitatii: Simplitatea trebuie urmarita atat in cazul produsului, cat si in cazul procesului de dezvoltare. 10. Practici Extreme Programming. Raspuns: Planificarea incrementala: Cerintele sunt inregistrate pe story cards si determinarea scenariului care sa fie inclus intr-o varianta functie de timpul avut la dispozitie si de prioritati. Dezvoltatorii despart aceste scenarii in sarcini. Variante mici: Setul minimal de functionalitati esentiale pentru afacere este dezvoltat primul. Variantele sistemului sunt frecvente si adauga functionalitati in mod incremental. Proiectare simpla: proiectarea se limiteaza la suportul cerintelor curente. Testare de la inceput: O unitate cadru automata de testare va fi utilizata pentru scrierea testelor pentru fiecare functionalitate noua, inainte de implementarea acesteia. Refactorizare: Codul va fi refactorizat continuu cand se intrevad posibile imbunatatiri. Astfel codul va fi usor de intretinut. Programare in perechi: Isi vor verifica reciproc munca si se ajuta pentru a obtine rezultate cat mai bune. Proprietate comuna: Proprietatea asupra codului este comuna celor 2. Altcineva nu poate interveni pentru a modifica codul. Integrarea continua: Imediat ce o sarcina este completata, rezultatul este integrat in sistem. Dupa integrare trebuie trecute toate unitatile de test ale sistemului. 11. Explicati diferentele intre validarea si verificarea unui sistem software. Raspuns: Verificare: Softul trebuie sa fie conform cu specificatiile. Validare: Softul trebuie sa faca ceea ce utilizatorul are nevoie. Ambele se petrec pe intreaga durata de viata a sistemului.

12. Definiti verificarea statica si verificarea dinamica. Raspuns: Verificarea statica: Verificarea codului. Consta in analiza statica a reprezentarii sistemului pentru descoperirea eventualelor probleme. Verificarea dinamica: Testarea software. Se preocupa de observarea comportamentului produsului la rulare. 13. Care sunt principalele activitati de management la dezvoltarea unui produs software. Raspuns: - Managementul proiectului. Unelte de management specifice. Se refera la distributia si controlul bugetului, timpului si personalului. - Managementul personalului (influentat de consistenta, respect, includere si onestitate). Managementul echipelor implicate in dezvoltarea unui proiect software - Estimatea costurilor. Estimarea de preturi, costuri si productivitati ale procesului de dezvoltare software - Managementul calitatii (asigurarea atingerii unui anumit nivel de calitate al produsului software). Standarde, masuratori si metrici referitoare la calitatea produsului software. 14. Factorii importanti la selectia personalului pentru un proiect software. Raspuns: Experienta in domeniul aplicatiei Experienta in utilizarea platformei Experienta in limbajul de programare Abilitatea de rezolvare a problemelor Educatia Abilitati comunicationale Adaptabilitatea Atitudinea si personalitatea

Pentru partea de PROBLEME o sa primiti o problema care va cere sa proiectati o arhitectura folosind UML pentru un sistem dat, aplicand principiul open-close (care sa permita adaugarea facila a unor noi facilitati).