Ingineria programării Test 1 (notat cu 20p)
1. Ingineria software adoptă o abordare sistematică şi utilizează tehnici şi instrumente
diverse, adecvate pentru:
a. Soluţionarea unor probleme practice apărute
b. Soluţionarea aspectelor teoretice şi fundamentale din domeniul problemei
c. Constrângerile de dezvoltare
d. Resursele disponibile
2. Numărul zonelor de cunoştinţe cheie ale domeniului Inginerie Software, conform
„Software Engineering Body of Knowledge” ([Link] este de:
a. 7 b. 9 c. 10 d. 11
3. Costurile de menţinere/ evoluţie ale unui software le depăşesc pe cele de dezvoltare:
a. Doar pentru produsele software generice
b. Doar pentru produsele software customizate
c. În toate cazurile în care sistemul dezvoltat este de un tip particular
d. Dacă sistemului i se impun cerin e speciale (performanţă, siguran ă în
exploatare)
4. Ca pondere într-un proiect software, programarea reprezintă:
a. Sub 10% b. 10-30% c. 30-50% d. 60-75%
5. Ingineria cerinţelor este etapa în care:
a. Se stabileşte ce anume vrea clientul să facă programul
b. Se face înregistrarea cerinţelor într-o manieră clară şi detaliată, ce pp. analiza lor
c. Se derulează un proces de stabilire a serviciilor pe care le doreşte clientul de la
sistem, precum şi a constrângerilor de operare şi dezvoltare
d. Se face managementul calităţii pentru cerinţe
6. Prin cerinţe non-funcţionale înţelegem:
a. Descrieri ale serviciilor pe care trebuie să le ofere sistemul, cum trebuie să
reacţioneze şi să se comporte sistemul în situaţii particulare
b. Constrângeri asupra serviciilor/ funcţiilor-sistem, sau procesului de dezvoltare
c. Cerinţe ce provin din domeniul de aplicaţie al sistemului
d. Recomandări ce ajută la luarea deciziilor de proiectare când există opţiuni multiple
7. Primul pas în ingineria cerinţelor constă în:
a. Analiza cerinţelor
b. Extragerea/ clasificarea cerinţelor
c. Specificarea cerinţelor
d. Validarea cerinţelor
8. Modelele de procese de dezvoltare software ce folosesc prototipizarea sunt:
a. Cele mai indicate atunci când cerinţele sunt clare şi complet definite
b. Cele mai indicate când clientul nu poate defini clar cerinţele de la început
c. Foarte utile în cazul proiectelor a căror echipă de dezvoltare este mare
d. Abordări riscante, ce produc rareori un produs complet
9. Un model este o reprezentare simplificată a unui sistem, care însă NU permite:
a. Înţelegerea abordării problemelor complexe
b. Facilitarea deciziilor legate de oportunitatea implementării unui sistem
c. Analize teoretice şi experimente practice asupra unei posibile soluţii
d. Structurarea soluţiilor unor probleme complexe
10. Un model dataflow (de procesare a datelor) arată:
a. Modul în care sunt procesate datele in diferite etape de prelucrare
b. Contextul operaţional al datelor unui sistem
c. Modul cum răspunde sistemul la apariţia unor evenimente
d. Structura logica a datelor prelucrate in sistem
11. Un model compoziţional (de agregare) indică:
a. Principalele sub-sisteme ale unui sistem
b. Un mod de compunere si descompunere a entităţilor
c. Caracteristicile comune ale entităţilor
d. Modul de reacţie al sistemului la apariţia unor evenimente
12. Un exemplu ilustrativ de model semantic de date îl constituie clasa:
a. Modelelor contextuale
b. Dicţionarelor de date
c. Modelelor entitate-relaţie-atribut
d. Modelelor dataflow (de procesare date)
13. Modelul de proiectare NU este influenţat de:
a. Arhitectura pe care se va implementa sistemul
b. Sistemul de operare sau protocoalele de reţea
c. Mecanismele de structurare/modularizare ale limbajului de programare
d. Sistemul de gestiune a bazelor de date ale proiectului
14. Într-un proces de proiectare arhitecturală:
a. Se proiectează fiecare modul al aplicaţiei, în cele mai mici detalii
b. Este mai simplu ca programul să fie împărţit în module sau componente, care pot
fi abordate individual
c. Se asigură legătura intre procesele de specificare si procesele de implementare
d. Se identifică doar componentele majore de sistem, nu şi comunicaţia între acestea
15. Rolul arhitecturii unui sistem software ca mijloc de comunicare intre stakeholders,
constă în principal în:
a. Expunerea permanentă a modificărilor (de cerinţe sau arhitecturale)
b. Asigurarea unui limbaj comun ce permite găsirea strategiilor de a echilibra
caracteristici diferite si/sau contradictorii
c. Evaluarea şi comunicarea tuturor deciziilor de proiectare
d. Realizarea primelor artefacte ce permit analiza viitorului sistem în vederea
stabilirii calităţilor lui
16. Deciziile de proiectare arhitecturală:
a. Nu definesc toate constrângerile de implementare
b. Nu influenţează structura organizaţionala
c. Nu permit predicţia calităţilor unui sistem, înainte de realizarea sa efectivă
d. Nu permit estimarea costurilor şi termenelor de realizare
17. O arhitectură software se compune din vederi structurale multiple, fără a include:
a. Captura relaţiilor între modulele proiectului din faza de dezvoltare
b. Captura relaţiilor dintre elementele care apar in timpul execuţiei programului
c. Partea observabilă extern a comportamentului elementelor
d. Proprietăţi ce nu afectează utilizarea elementelor/ interacţiunile între acestea
18. Un avantaj important al arhitecturilor de sistem distribuite este:
a. Managementul mult mai facil
b. Predictabilitatea mult mai mare
c. Simplitatea
d. Toleranţa la defecte
19. Un dezavantaj important al arhitecturilor de sistem distribuite este:
a. Partajarea resurselor hard/ soft
b. Caracterul deschis
c. Securitatea mai scăzută
d. Lipsa de scalabilitate
20. Obiectele, ca reprezentări ale entităţilor unui sistem, pot comunica:
a. Doar prin schimb de mesaje
b. Prin date comune (partajate)
c. Doar în medii secvenţiale
d. Doar în medii concurente