Întrebare importantă SEN

Capitolul 1

1) Descrie abordarea tehnologică stratificată a Ingineriei Software.

O concentrare pe calitate:

Ingineria software este o tehnologie stratificată. Referindu-ne la figura, orice inginerie

abordarea (inclusiv ingineria software) trebuie să se bazeze pe un angajament organizaț ional de
calitate. Baza care susț ine ingineria software este un accent pe calitate.
Proces:
Fundaț ia pentru ingineria software-ului este stratul procesului. Ingineria software-ului
procesul este lipiciul care ț ine împreună straturile de tehnologie ș i permite raț ional ș i la timp
dezvoltarea software-ului de calculator. Procesul defineș te un cadru care trebuie stabilit
pentru livrarea eficientă a tehnologiei ingineriei software.
Procesul software formează baza pentru controlul managementului proiectelor software ș i
stabileș te contextul în care sunt aplicate metodele tehnice, produsele de lucru (modele,
documente, date, raporturi, formulare, etc.) sunt produse, reperele sunt stabilite, calitatea este
asigurat, iar schimbarea este gestionată corect.
Metode:
Metodele de inginerie software oferă instruc ț iunile tehnice pentru construirea software-ului.
Metodele cuprind o gamă largă de sarcini care includ comunicarea, cerin ț ele
analiză, modelare de design, construcț ia programelor, testare ș i suport. Inginerie software
metodele se bazează pe un set de principii de bază care guvernează fiecare domeniu al tehnologiei ș i includ
activităț i de modelare ș i alte tehnici descriptive.
Unelte:
Instrumentele de inginerie software oferă suport automatizat sau semi-automatizat pentru proces.
ș i metodele. Când instrumentele sunt integrate astfel încât informaț iile create de un instrument să poată fi
folosit de altcineva, un sistem pentru susț inerea dezvoltării software-ului, numit asistenț ă computerizată
ingineria software-ului este stabilită.
 2) Explicaț i activităț ile de bază ale cadrului procesului
Un cadru de proces stabileș te baza pentru un complet
procesul software prin identificarea unui număr mic de cadre
activităț i care sunt aplicabile tuturor proiectelor software, indiferent de
dimensiunea sau complexitatea lor.
În fig, fiecare activitate a cadrului este populată de un set de software.
acț iuni de inginerie. O colecț ie de sarcini legate care produce o
produs major de inginerie software.
Fiecare acț iune din cadrul procesului este populată cu muncă individuală
sarcini care îndeplinesc o parte din munca implicată de acț iune.
1. Communication:
Activitatea cadrului de comunicare implică un efort mare
comunicare ș i colaborare cu clientul,
inclusiv colectarea cerinț elor, colectarea datelor ș i altele
activităț i conexe.
2. Planificare:
Activitatea de planificare stabileș te un plan pentru munca de inginerie software
care urmează. Planificarea descrie sarcinile tehnice care trebuie să fie
realizate, resursele care vor fi necesare, programul, ș i
riscuri care sunt probabile în produsele de lucru care urmează să fie produse.
3. Modelare:
Activitatea de modelare cuprinde crearea de modele care permit
dezvoltatorul ș i clientul pentru a înț elege mai bine software-ul
specificaț iile cerinț elor ș i designul care vor atinge acestea
cerinț e.
Există două tipuri de modelare, adică modelarea analitică ș i modelarea de design
modeling.
4. Construcț ie:
Activitatea de construcț ie combină generarea de cod ș i testarea.
5. Implementare:
Software-ul este livrat clienț ilor care evaluează
produs livrat ș i oferă feedback pe baza evaluării.
3) Explicaț i modelul în cascadă

Modelul cascadei, uneori denumit ciclul de via ț ă clasic, sugerează un proces sistematic,
abordare sequentială6 la dezvoltarea software-ului care începe cu specificaț ia clientului de
cerinț e ș i progrese prin planificare, modelare, construcț ie ș i implementare,
culminând cu suportul continuu al software-ului finalizat.

Fig: Modelul Cascadă

Situaț ia în care modelul cu apă curgătoare este aplicabil:
Există momente când cerinț ele pentru o problemă sunt bine înț elese—când munca
curge din comunicare prin desfăș urare într-un mod rezonabil liniar. Acest
situaț ia este uneori întâlnită când adaptările sau îmbunătăț irile bine definite la
un sistem existent trebuie să fie creat.
Activităț ile implicate în cadrul cadru:
Comunicare:
Implica o comunicare intensă cu clientul (sau părț ile interesate) ș i cuprinde
colectarea cerinț elor ș i activităț ile aferente.
Planificare:
În această activitate, efortul necesar, costul/bugetul, analiza riscurilor, durata timpului sunt estimate din nou.
(planul de proiect este realizat)
Modelare:
Această activitate creează modele de analiză ș i design care ajută atât dezvoltatorii, cât ș i clienț ii să înț eleagă mai bine.
înț elege cerinț ele. Structura de date, arhitectura software ș i alte detalii sunt
făcut.
Construction:
Această activitate efectuează generarea de cod ș i testarea pentru a asigura dacă cerinț ele sunt îndeplinite
împlinit.
Generarea codului se face mai întâi, iar apoi testarea este efectuată.
Implementare:
Odată ce produsul este complet dezvoltat, este livrat clientului. Clientul evaluează
produs ș i oferă feedback.
Advantages:
Este cel mai simplu model de proces software.
Uș or de înț eles
Fazele sunt completate una câte una
Funcț ionează bine pentru proiecte mai mici
Disadvantages:
Proiectele reale rareori urmează fluxul secvenț ial pe care modelul îl propune. Deș i
modelul liniar poate acomoda iteraț ia, o face indirect. Ca urmare, modificările pot
creează confuzie pe măsură ce echipa de proiect avansează.
Este adesea dificil pentru client să îș i exprime toate cerinț ele în mod explicit. Modelul în cascadă
modelul necesită acest lucru ș i are dificultăț i în a se adapta la incertitudinea naturală care există
la începutul multor proiecte.
 Clientul trebuie să aibă răbdare. O versiune funcț ională a programului(elor) nu va fi
disponibil până târziu în intervalul de timp al proiectului. O eroare majoră, dacă rămâne nedetectată până la
un program de lucru este revizuit, poate fi catastrofal.

4) Explicaț i Modelul Spiral.

Fig: Modelul spiral

Modelul spiral este un model evolutiv de proces software care combină natura iterativă
de prototipare cu aspectele controlate ș i sistematice ale modelului de tip cascade. Oferă
potenț ialul pentru dezvoltarea rapidă a unor versiuni de software din ce în ce mai complete.
Folosind modelul spiral, software-ul este dezvoltat într-o serie de versiuni evolutive. În timpul
în itera ț iile timpurii, lansarea ar putea fi un model sau un prototip. În itera ț iile ulterioare,
versiuni din ce în ce mai complete ale sistemului ingineresc sunt produse.
Un model spiral este împăr ț it într-un set de activită ț i cadru definite de software
echipa de inginerie. Fiecare dintre activităț ile cadrul reprezintă un segment al căii spirale
ilustrat în Figură. Pe măsură ce acest proces evolutiv începe, echipa de software efectuează
activităț i care sunt implicate de un circuit în jurul spiralei într-o direcț ie cu sensul acelor de ceasornic, începând
la centru.
Riscul este considerat cu fiecare revolutionare efectuată.
Primul circuit în jurul spiralei ar putea duce la dezvoltarea unui produs
specificaț ie; trecerile ulterioare în jurul spiralei ar putea fi folosite pentru a dezvolta un prototip
ș i apoi versiuni progresiv mai sofisticate ale software-ului.
Fiecare trecere prin regiunea de planificare rezultă în ajustări ale planului de proiect.
Costul ș i programul sunt ajustate pe baza comentariilor primite de la client după
livrare. În plus, managerul de proiect ajustează numărul planificat de iteraț ii
necesar pentru a finaliza software-ul.
Avantaje:
Modelul spiral este o abordare realistă pentru dezvoltarea sistemelor la scară largă ș i
software.
O cantitate mare de analiză a riscurilor, prin urmare, evitarea riscurilor este îmbunătăț ită.
Dezavantaje:
Ar putea fi dificil să convingi clienț ii (în special în situaț ii de contract) că
abordarea evolutivă este controlabilă.
Necesară o expertiză considerabilă în evaluarea riscurilor ș i se bazează pe această expertiză pentru succes.
Dacă un risc major nu este descoperit ș i gestionat, problemele vor apărea cu siguranț ă.

5) Explicaț i modelul incremental

Fig: Model Incremental

Modelul incremental combină elemente ale fluxurilor de proces liniar și paralel.
Referitor la figură, modelul incremental aplică secvențe liniare într-un mod în trepte.
moda pe măsură ce timpul calendaristic progresează. Fiecare secvență liniară produce livrabile
"incrementuri" ale software-ului.

Situaț ia în care modelul incremental este aplicabil:

Există multe situații în care cerințele inițiale de software sunt rezonabile
bine definit, dar domeniul general al efortului de dezvoltare exclude un pur
proces liniar.
În plus, poate exista o nevoie imperioasă de a oferi un set limitat de software.
funcționalitate pentru utilizatori rapid și apoi a rafina și extinde acea funcționalitate în
versiuni software ulterioare.
Când se folosește un model incremental, primul increment este adesea un produs de bază.
Adică, cerințele de bază sunt abordate, dar multe caracteristici suplimentare (unele
cunoscut, altele necunoscute) rămân neduse.
Produsul principal este folosit de client (sau trece printr-o evaluare detaliată). Ca un
rezultatul utilizării și/sau evaluării, se dezvolta un plan pentru următorul increment.
 Planul abordează modificarea produsului de bază pentru a răspunde mai bine nevoilor
clientul și livrarea de caracteristici și funcționalități suplimentare. Acest proces
se repetă după livrarea fiecărui increment, până la finalizarea produsului complet
produs.
Modelul de proces incremental se concentrează pe livrarea unui produs operațional
cu fiecare increment. Incrementurile timpurii sunt versiuni simplificate ale versiunii finale
produs, dar oferă capacitatea care servește utilizatorul și, de asemenea, oferă o
platformă pentru evaluarea de către utilizator.
Exemplu:
Software-ul de procesare a textelor dezvoltat folosind paradigma incrementală ar putea oferi
basic file management, editing, and document production functions in the first
increment; capabilități de editare și producție de documente mai sofisticate în
al doilea increment; verificarea ortografiei și gramaticii în al treilea increment; și
capacitatea avansată de aranjare a paginilor în al patrulea increment. Trebuie menționat că
fluxul de proces pentru orice increment poate incorpora paradigma prototipării.
Advantages:
Util atunci când personalul nu este disponibil
Mai puț in costisitor să schimbi domeniul de aplicare al proiectului

Clientul poate răspunde la fiecare construcț ie.

Disadvantages:
Costul este mai mare decât modelul waterfall.
Necesită planificare ș i design bun

6) Enumera ț i orice patru atribute ale unui software bun.

1. Funcț ionalitate:
Se referă la gradul de performanț ă al software-ului în raport cu scopul său destinat.
2. Fiabilitate:
Se referă la capacitatea software-ului de a oferi funcț ionalitatea dorită în condiț iile date.
condiț ii.
3. Utilizabilitate:
Se referă la măsura în care software-ul poate fi utilizat cu uș urinț ă ș i simplitate.
4. Menț inere:
Software-ul trebuie să evolueze pentru a răspunde nevoilor în schimbare.

5. Fiabilitate:
Software-ul trebuie să fie de încredere.
6. Eficienț ă:
Software-ul nu ar trebui să irosească resursele sistemului.
7. Acceptabilitate
Software-ul trebuie să fie acceptat de utilizatorii pentru care a fost conceput.
8. Portabilitate:
Se referă la uș urinț a cu care dezvoltatorii de software pot transfera software-ul de la unul
platformă la alta, fără modificări.
9. Integritate:
Se referă la gradul în care accesul neautorizat la software poate fi prevenit.
 10. Robustete:
Se referă la gradul în care software-ul poate continua să funcț ioneze în ciuda faptului că este
furnizat cu date invalide

7) Activităț i ale cadrului PSP ș i TSP

Activităț ile Framework-ului PSP includ: -
Modelul PSP defineș te cinci activităț i de cadru:
Planificare: Această activitate izolează cerinț ele ș i dezvoltă atât estimări de dimensiune, cât ș i estimări de resurse.
În
În plus, se face o estimare a defectelor (numărul de defecte proiectate pentru muncă). Toate
metrice
sunt înregistrate pe fiș e de lucru sau ș abloane. În cele din urmă, sarcinile de dezvoltare sunt identificate ș i o
proiect
programul este creat.
Proiectare la nivel înalt: Specificaț ii externe pentru fiecare componentă care urmează să fie construită sunt
dezvoltat
and a component design is created. Prototypes are built when uncertainty exists. All issues
sunt
înregistrat ș i urmărit.
Revizuirea designului la un nivel înalt: Metodele de verificare formală (Capitolul 21) sunt aplicate pentru a descoperi
erori în design. Metricii sunt menț inuț i pentru toate sarcinile importante ș i rezultatele muncii.
Dezvoltare: Designul la nivel de componentă este rafinat ș i revizuit. Codul este generat.
revizuit,
compilat ș i testat. Metricile sunt menț inute pentru toate sarcinile importante ș i rezultatele muncii.
Postmortem: Folosind măsurile ș i metricile colectate (aceasta este o cantitate substanț ială de date
că
ar trebui să fie analizată statistic), eficienț a procesului este determinată. Măsuri ș i
metricile ar trebui să ofere îndrumare pentru modificarea procesului pentru a-i îmbunătăț i eficienț a.

Activităț ile Cadru TSP includ:-

TSP defineș te următoarele activităț i de cadru: lansarea proiectului, designul de înalt nivel,
implementare, integrare ș i testare, ș i post-mortem.
Lansarea Proiectului: Revizuieș te obiectivul principal ș i descrie structura ș i conț inutul TSP.
atribuie
termeni ș i roluri pentru dezvoltatori ș i descrie declaraț ia nevoilor clientului. De asemenea, stabileș te
echipă
ș i obiectivele individuale.
Proiectare la nivel înalt: Creează un design la nivel înalt, specifică designul ș i inspectează designul
dezvoltă un plan de testare a integrării.
Implementare: Implementarea foloseș te TSP pentru a implementa module/unitate, creează un detaliat
proiectarea modulelor/unităț ilor, revizuieș te proiectul, traduce proiectul în cod, revizuieș te codul
compilează ș i testează modulele/unităț ile ș i analizează calitatea modulelor/unităț ilor.
Integrare ș i Testare: Testarea compilează ș i integrează aceste build-uri într-un sistem. Aceasta conduce un
test de sistem ș i producerea documentaț iei pentru utilizatori.
Postmortem: Efectuează o analiză postverbală, scrie un raport de ciclu ș i produce feedback din partea colegilor.
evaluări ale echipei.
 8) Explica ț i Modelul RAD

Abordarea modelului RAD este aplicabilă, dacă cerin ț ele aplica ț iei de afaceri sunt
modularizat ca o funcț ie care să fie completată de echipele individuale ș i, în cele din urmă, să fie integrată într-un
sistem complet.
Astfel, comparativ cu modelul cascada, echipa va fi de o dimensiune mai mare pentru a funcț iona corect.
coordonare.
Dezvoltarea rapidă a aplicaț iilor (RAD) este un model modern de proces software care subliniază
un ciclu scurt de dezvoltare. Modelul RAD este o adaptare "rapidă" a modelului în cascadă
model, în care dezvoltarea rapidă este realizată prin utilizarea unei construcț ii bazate pe componente
abordare.
Dacă cerinț ele sunt bine înț elese ș i domeniul de aplicare al proiectului este considerat, procesul RAD
permite unei echipe de dezvoltare să creeze un Sistem Complet Funcț ional într-o perioadă foarte scurtă
de timp (de exemplu, 60 până la 90 de zile). Una dintre caracteristicile distincte ale modelului RAD este posibilitatea de
activităț i transversale ale ciclului de viaț ă care vor fi atribuite echipelor, echipa #1 până la echipa #n conducând la
fiecare modul fiind dezvoltat aproape simultan.
Advantages:
1. Cerin ț ele schimbătoare pot fi acceptate ș i progresul poate fi măsurat.
2. Instrumentele RAD puternice pot reduce timpul de dezvoltare.
3. Productivitate cu o echipă mică în timp scurt de dezvoltare ș i revizuiri rapide controlul riscurilor
creș te reutilizabilitatea componentelor, calitate mai bună.
4. Riscul noului abordări sunt recomandate doar sistemele modularizate prin RAD.
5. Potrivit pentru sisteme scalabile bazate pe componente.
Limitări:
Succesul modelului RAD depinde de expertiza ș i abilităț ile unei echipe tehnice puternice.
2. Dezvoltatori foarte bine pregătiț i necesari, cu abilităț i de modelare.
3. Implicarea utilizatorului pe parcursul ciclului de viaț ă. Dacă dezvoltatorii ș i clienț ii nu sunt angajaț i în
activităț ile rapide necesare pentru a finaliza Sistemul într-un timp mult mai scurt
cadru, proiectele RAD vor eș ua.
4. Poate să nu fie adecvat pentru sisteme de foarte mare amploare în care riscurile tehnice sunt ridicate.

9) Tipuri de software

Software de sistem
Este o colecț ie de programe scrise pentru a deservi alte programe. Unele software de sistem (de exemplu,
compilatoare,
editori ș i utilitare pentru gestionarea fiș ierelor) procesează informaț ii complexe, dar determinate
structuri.
Aplicaț ii pentru alte sisteme (de exemplu, componente ale sistemului de operare, drivere, reț elistică)
software
procesoarele de telecomunicaț ii) procesează date în mare parte indeterminate.
Software de aplicaț ie
 rograme independente care rezolvă o nevoie specifică de afaceri.
P
 plicaț iile din acest domeniu procesează date de afaceri sau tehnice într-un mod care facilitează afacerea
A
operaț iuni
sau luarea deciziilor de management/tehnice
Software de inginerie/ș tiinț ific
 plicaț iile variază de la astronomie la vulcanologie, de la analiza stresului în automobil la
A
navetă spaț ială
dinamica orbitală, ș i de la biologia moleculară la fabricaț ia automatizată
De exemplu: software CAD.
Software încorporat
Se află într-un produs sau sistem ș i este folosit pentru a implementa ș i controla funcț ii ș i
funcț ii pentru
utilizator final ș i pentru sistemul în sine.
Software-ul încorporat poate efectua funcț ii limitate (de exemplu, controlul tastaturii pentru un microunde)
cuptor) sau
oferiț i funcț ii semnificative ș i capacităț i de control (de exemplu, funcț ii digitale într-o automobil)
cum ar fi combustibil

control, afiș aje de control, ș i sisteme de frânare).

 e exemplu, butoanele de control ale maș inii de spălat.
D
Software de linie de produs
Proiectat pentru a oferi o capacitate specifică pentru a fi utilizată de mulț i clienț i diferiț i.
Software-ul de linie de produse poate să se concentreze pe o piaț ă limitată (de exemplu, produse pentru controlul inventarului)
sau adresă
pieț e de consum în masă (de exemplu, procesare de text, foi de calcul, grafica computerizată, multimedia,
divertisment, gestionarea bazelor de date ș i aplicaț ii financiare personale ș i de afaceri).
Aplicaț ii web
Numit „WebApps”, această categorie de software centrată pe reț ea acoperă o gamă largă de
aplicaț ii.
În forma lor cea mai simplă, WebApps pot fi doar un set de fiș iere hipertext legate între ele care
prezent
informaț ii folosind text ș i grafice limitate.
software de inteligenț ă artificială
Foloseș te algoritmi non-numerici pentru a rezolva probleme complexe care nu sunt susceptibile de a fi
calcul sau analiză simplă.
Aplicaț iile din acest domeniu includ robotică, sisteme expert, recunoaș terea modelelor (imagine
ș i voce)
reț ele neuronale artificiale, demonstarea teoremelor ș i jocurile
 10) Curba de eș ec pentru software

Definiț ia software-ului
Software este:
[Link]ț iuni (programe de calculator) care, atunci când sunt executate, oferă caracteristici ș i funcț ii dorite,
ș i performanț ă;
[Link] de date care permit programelor să manipuleze informaț iile în mod adecvat, ș i
[Link]ț ii descriptive (documente) atât în formă tipărită, cât ș i în formă virtuală care descrie
operaț ia ș i
utilizarea programelor.
Caracteristici ale software-ului
Software-ul este dezvoltat sau conceput; nu este fabricat în sensul clasic.
Cele două activităț i (dezvoltarea de software ș i fabricarea de hardware) sunt fundamental
diferit. În ambele activităț i, calitatea ridicată este realizată printr-un bun design, dar
faza de fabricaț ie pentru hardware
poate introduce probleme de calitate.
Software-ul nu se "uzateș te." Dar se deteriorază!
Software-ul nu este susceptibil la bolile de mediu care cauzează uzura hardware-ului.
teorie
prin urmare, curba ratei de eș ec pentru software ar trebui să aibă forma „curbei idealizate”
afiș at în Figură
Această aparentă contradicț ie poate fi explicată cel mai bine luând în considerare curba reală din Figura
1.2. În timpul său
viaț a, software-ul va suferi modificări. Pe măsură ce se fac modificări, este probabil ca erori să apară.
introduse, cauzând
curba ratei de eș ec pentru a creș te aș a cum este arătat în „curba reală”. Înainte ca curba să poată reveni la
originalul
rata de eș ec în regim stabil, se solicită o altă modificare, determinând din nou curba să crească.
Încet,
nivelul minim al ratei de eș ec începe să crească - software-ul se deteriorează din cauza schimbării.
Deș i industria se îndreaptă spre construcț ia bazată pe componente, majoritatea software-ului
continuă să
fi construit pe comandă.Definiț ia Software-ului
Software este:
[Link]ț iuni (programe de calculator) care, atunci când sunt executate, oferă caracteristici ș i funcț ii dorite.
ș i performanț ă;
[Link] de date care permit programelor să manipuleze informaț iile în mod adecvat, ș i
[Link]ț ii descriptive (documente) în format fizic ș i virtual care descriu
operaț iunea ș i
utilizarea programelor.
Caracteristicile software-ului
Software-ul este dezvoltat sau inginerizat; nu este fabricat în sensul clasic.
Cele două activităț i (dezvoltarea de software ș i fabricaț ia de hardware) sunt fundamental
diferit. În
both activities, high quality is achieved through good design, but the manufacturing phase for
hardware
poate introduce probleme de calitate.
Software-ul nu se "erozează". Dar se deteriorează!
Software-ul nu este supus maladiilor de mediu care cauzează uzura hardware-ului. În
teorie
prin urmare, curba ratei de eș ec pentru software ar trebui să aibă forma „curbei idealizate”
afiș at în Figură
Această aparentă contradicț ie poate fi explicată cel mai bine prin luarea în considerare a curbei reale din Figura
1.2. În timpul său
viaț a, software-ul va suferi modificări. Pe măsură ce se fac schimbări, este probabil ca erori să apară.
introdus, cauzând
curba ratei de eș ecului pentru a creș te aș a cum este arătat în „curba actuală”. Înainte ca curba să poată reveni la
originalul
rata de eș ec în stare de echilibru, se solicită o altă modificare, provocând din nou o creș tere a curbei.
Încet,
nivelul ratei minime de eș ec începe să crească—software-ul se deteriorează din cauza schimbării.
Deș i industria se îndreaptă spre construcț ia bazată pe componente, majoritatea software-ului
continuă să
fi construit la comandă.
 Capitolul 2
1) Explicaț i principiile de bază ale ingineriei software în detaliu
Primul Principiu: Motivul pentru care totul există
Un sistem software există pentru un singur motiv: a oferi valoare utilizatorilor săi. Toate deciziile ar trebui să
să fie făcut cu acest lucru în minte.
Înainte de a specifica un cerin ț ele sistemului, func ț ionalitatea sistemului, înainte de a determina
platformele hardware, mai întâi determină dacă adaugă valoare sistemului.
Al Doilea Principiu: KISS (Menț ine-l Simplu, Prostule!)
Tot designul ar trebui să fie cât mai simplu posibil, dar nu mai simplu. Acest lucru facilitează obț inerea unei mai...
sistem uș or de înț eles ș i uș or de întreț inut.
Nu înseamnă că caracteristicile ar trebui să fie abandonate în numele simplităț ii.
Simplu nu înseamnă nici „rapid ș i murdar”. De fapt, adesea necesită multă gândire ș i muncă.
pe parcursul mai multor iteraț ii pentru a simplifica.
Al Treilea Principiu: Menț ine Viziunea
O viziune clară este esenț ială pentru succesul unui proiect software.
Dacă faci compromisuri în viziunea arhitecturală a unui sistem software, acesta se va slăbi ș i
în cele din urmă vor echilibra sistemele bine concepute.
A avea un arhitect puternic care poate susț ine viziunea ajută la asigurarea unui succes foarte mare
proiect software.
Al Patrulea Principiu: Ce Produci, Alț ii Vor Consuma
Întotdeauna specificaț i, proiectaț i ș i implementaț i având în vedere că altcineva va trebui să
înț elege ce faci.
Publicul pentru orice produs de dezvoltare software este potenț ial mare.
Proiectează (fă design), având în vedere implementatorii (programatorii). Codifică (programează)
cu preocupare pentru cei care vor menț ine ș i extinde sistemul.
Cineva ar putea fi nevoit să depaneze codul pe care îl scrii, iar asta îi face utilizatori ai codului tău.
Principiul Cincilea: Fii Deschis către Viitor
Un sistem cu o durată de viaț ă lungă are mai multă valoare.
True “industrial-strength” software systems must last for longer.
Pentru a reuș i în acest sens, aceste sisteme trebuie să fie pregătite să se adapteze schimbărilor.
Întreabă-te mereu „ce-ar fi dacă” ș i pregăteș te-te pentru toate răspunsurile posibile prin crearea de sisteme care rezolvă
problemă generală.
Principiul Ș ase: Planifică Înaintede pentru Reutilizare
Refolosirea economiseș te timp ș i efort.
Reutilizarea codului ș i a designurilor are un beneficiu major în utilizarea tehnologiilor orientate pe obiect.
Planificarea în avans pentru reutilizare reduce costul ș i creș te valoarea atât a celor reutilizabile
componentele ș i sistemele în care sunt incorporate.
Al ș aptelea principiu: Gândeș te!
Plasarea unei gândiri clare ș i complete înainte de acț iune produce aproape întotdeauna rezultate mai bune.
Când te gândeș ti la ceva, eș ti mai predispus să faci bine. De asemenea, câș tigi cunoș tinț e.
despre cum să o facem bine din nou.
Dacă te gândeș ti la ceva ș i totuș i o faci greș it, devine o experienț ă valoroasă.
 2) Principiul Comunicaț iei
Principle 1 Listen:
Încercaț i să vă concentraț i asupra cuvintelor vorbitorului, mai degrabă decât să vă formulaț i răspunsul la acestea.
cuvinte.
Cere clarificări dacă ceva nu este clar, dar evită întreruperile constante.
Nu deveni niciodată contentious în cuvintele sau acț iunile tale (de exemplu, răsucind din ochi sau clătinând din cap)
your head) as a person is talking.
Principiul 2 Pregăteș te-te înainte de a comunica:
Petreceț i timp pentru a înț elege problema înainte de a vă întâlni cu alț ii. Dacă este necesar,
efectuează unele cercetări pentru a înț elege domeniul de afaceri.
Dacă aveț i responsabilitatea de a conduce o întâlnire, pregătiț i un program în avans.
întâlnire.
Principiul 3: cineva ar trebui să faciliteze activitatea:
Fiecare întâlnire de comunicare ar trebui să aibă un lider (un facilitator)
(1) Pentru a menț ine conversaț ia într-o direcț ie productivă,
(2) A media orice conflict care apare ș i
(3) Pentru a asigura respectarea altor principii.
Principiul 4 Comunicare faț ă în faț ă este cea mai bună:
De obicei funcț ionează mai bine când există o altă reprezentare a informaț iilor relevante.
prezent.
De exemplu, un participant poate crea un desen/document care să servească drept focalizare pentru
discuț ie.
Principiul 5 Notează ș i documentează deciziile:
Cineva care participă la comunicare ar trebui să acț ioneze ca un înregistrator ș i să noteze
toate punctele ș i deciziile importante.
Principiul 6: Străduiț i-vă pentru colaborare:
Colaborarea are loc atunci când cunoș tinț ele colective ale membrilor echipei sunt folosite pentru a
descrie funcț iile sau caracteristicile produsului sau sistemului.
Fiecare mică colaborare construieș te încredere între membrii echipei ș i creează un obiectiv comun
pentru echipă.
Principiul 7 Rămâneț i concentrat; modularizaț i discuț ia dvs.:
The more people involved in any communication, the more likely that discussion will
sar de la un subiect la altul.
Facilitatorul ar trebui să menț ină conversaț ia modulară; părăsind un subiect doar după ce a fost
a fost rezolvat.
Principiul 8 dacă ceva nu este clar, desenează o imagine:
Comunicaț ia verbală are limitele ei.
Un schiț ă sau o desen poate oferi adesea claritate când cuvintele nu reuș esc să-ș i facă treaba.
Principiul 9
(a) Odată ce eș ti de acord cu ceva, mergi mai departe.
(b) Dacă nu poț i să te înț elegi cu ceva, mergi mai departe.
(c) Dacă o caracteristică sau o funcț ie nu este clară ș i nu poate fi clarificată în acest moment, mutaț i
on.
 Persoanele care participă la comunicare ar trebui să recunoască că multe subiecte necesită
discuț ia ș i că avansarea este uneori cea mai bună modalitate de a obț ine agilitate în comunicare.
Principiul 10 Negocierea nu este o competiț ie sau un joc: Funcț ionează cel mai bine când ambele părț i câș tigă.
Există multe ocazii în care tu ș i alț i factori interesaț i trebuie să negociaț i funcț ii
ș i caracteristici, priorităț i ș i date de livrare.
Dacă echipa a colaborat bine, toate părț ile au un obiectiv comun. Totuș i, negocierile vor
cere compromis din partea tuturor părț ilor.

3) Principiul de construcț ie

Activitatea de construcț ie cuprinde un set de sarcini de codare ș i testare care conduc la

software operaț ional care este gata pentru livrare către client sau utilizator final.
Principii de programare
În munca modernă de inginerie software, codificarea poate fi
(1) Crearea directă a codului sursă al limbajului de programare (de exemplu, Java),
(2) Generarea automată a codului sursă utilizând o reprezentare intermediară asemănătoare cu un design
componenta care urmează să fie construită (de exemplu, interfaț a Microsoft unde codul este generat automat), sau
(3) Generarea automată de cod executabil folosind un „program de generare de a patra generaț ie
limbaj” (de exemplu, Visual C++).

Principiile de pregătire: Înainte de a scrie o singură linie de cod, asigură-te că

Înț elege problema pe care încerci să o rezolvi.
Înț elegeț i principiile ș i conceptele de bază ale designului.
Alege un limbaj de programare care să răspundă nevoilor software-ului care urmează să fie construit ș i
mediu în care va opera.
Alegeț i un mediu de programare care oferă instrumente care vor face munca dumneavoastră mai uș oară.
(De exemplu, TC, JRE etc.).

Creează un set de teste unitare care vor fi aplicate odată ce componenta pe care o codifici este finalizată.

Principiile programării: Pe măsură ce începi să scrii cod, asigură-te că

Limitaț i algoritmii dvs. respectând practica de programare structurată.
Consideraț i utilizarea programării în pereche.
Selectaț i structurile de date care vor îndeplini cerinț ele designului.
Înț elege arhitectura software-ului ș i creează interfeț e care sunt consistente cu aceasta.
Păstraț i logica condiț ională cât mai simplă posibil.
Creează bucle imbricate într-un mod care le face uș or de testat.
Alegeț i nume semnificative pentru variabile ș i respectaț i celelalte standarde locale de programare

Scrie cod care se documentează singur. (de exemplu, comentarii)

Creează un aranjament vizual (de exemplu, indentaț ii ș i linii goale) care să ajute la înț elegere.

Principiile de validare: După ce ai finalizat prima ta trecere de codare, asigură-te că

Realizaț i o examinare a codului atunci când este potrivit.
Perform unit tests and correct errors you’ve uncovered.
Refactorizaț i codul.
 4) Principiul de implementare

Principiul 1: Aș teptările clienț ilor pentru software trebuie gestionate.

Inginerul software trebuie să fie atent la trimiterea mesajelor contradictorii către client (de exemplu,
promiț ând mai mult decât poț i livra în mod rezonabil în cadrul timpului oferit sau livrând
mai mult decât promiț i pentru un increment de software ș i apoi mai puț in decât promisiunea pentru
următorul).
Principiul 2: Un pachet complet de livrare ar trebui să fie asamblat ș i testat.
Un CD-ROM sau alte medii (inclusiv descărcări de pe internet) care conț in toate executabilele
software, fiș iere de date de suport, documente de suport ș i alte informaț ii relevante ar trebui să fie
asamblat ș i testat temeinic beta cu utilizatori reali.
Toate scripturile de instalare ș i celelalte funcț ii operaț ionale ar trebui să fie testate temeinic.
Principiul 3: Un regim de suport trebuie stabilit înainte ca software-ul să fie livrat.
Când apare o problemă sau o întrebare din partea utilizatorului final, acesta/aceasta se aș teaptă la o reacț ie rapidă ș i
informa ț ii precise. Dacă suportul este ad-hoc sau inexistent, clientul va deveni
nesatisfăcut imediat. Sprijinul ar trebui să fie planificat, materialele de suport ar trebui să fie
pregătit, iar mecanismele adecvate de păstrare a documentelor ar trebui să fie stabilite astfel încât să
echipa de software poate efectua o evaluare a tipurilor de suport solicitate.
Principiul 4: Materialele didactice adecvate trebuie să fie furnizate utilizatorilor finali.
Echipa de software livraza mai mult decat software-ul in sine.
Aidele de formare adecvate (dacă este necesar) ar trebui să fie dezvoltate; ghiduri de soluț ionare a problemelor
ar trebui să fie furnizat
Principiul 5: Software-ul cu erori ar trebui să fie reparat mai întâi, livrat mai târziu.
Sub presiunea timpului, unele organizaț ii software livră incrementări de calitate scăzută cu o
avertisment către client că bug-urile "vor fi reparate în următoarea versiune." Clientul primeș te
dezamăgit de aceasta.
Prin urmare, este necesar să remediem bug-ul înainte ca produsul să fie livrat clientului.
 5) Sarcină de inginerie a cerinț elor

(i) Inceperea si
(ii) Elicitare
[Link] ț ie
Cele mai multe proiecte încep atunci când se identifică o nevoie de afaceri sau un nou potenț ial de piaț ă sau serviciu.
descoperit.
Părț ile interesate din comunitatea de afaceri (de exemplu, manageri de afaceri, oameni de marketing ș i
managerii de produs) definesc un caz de afacere pentru idee, încearcă să identifice amploarea ș i adâncimea
piaț a, efectuaț i o analiză preliminară de fezabilitate ș i identificaț i o descriere a proiectului care funcț ionează
domeniu.
La începutul proiectului, stabileș ti o înț elegere de bază a problemei, a oamenilor care vor
o soluț ie, natura soluț iei dorite ș i eficacitatea preliminară
comunicare ș i colaborare între client ș i echipa de software.
[Link] ț ie
Elicitarea înseamnă a defini ce este necesar.
Inginerul de cerinț e întreabă clientul, utilizatorul ș i alț ii:
care sunt obiectivele pentru sistem sau produs
2. ce trebuie realizat
3. cum se potrivesc sistemul sau produsul nevoilor afacerii,
4. cum se va utiliza sistemul sau produsul pe o bază zilnică
Elicitatea cerinț elor este dificilă deoarece se întâmpină numeroase probleme:
Probleme de domeniu:
Limita sistemului este prost definită sau clienț ii/utilizatorii specifică cerinț e inutile
detaliu tehnic care poate confunda, mai degrabă decât a clarifica, obiectivele generale ale sistemului.
Probleme de înț elegere:
Clienț ii/utilizatorii:
nu sunt complet sigur de ceea ce este necesar
au o în ț elegere slabă a capacită ț ilor ș i limitărilor computerului lor
environment,
nu am o în ț elegere completă a domeniului problemei,
am dificultă ț i în a comunica nevoile către inginerul de sistem,
omite informa ț iile care se consideră „evidente”,
oSpecifica ț i cerin ț e care sunt în conflict cu nevoile altor clien ț i/utilizatori, sau specifica ț i
cerinț e care sunt ambigue (neclari) sau netestabile.
Probleme de volatilitate:
Cerinț ele se schimbă în timp.
 6) SRS ș i importanț a sa
O specificaț ie a cerinț elor software (SRS) este un document care este creat atunci când o detaliere
descrierea tuturor aspectelor software-ului care trebuie construite ș i care trebuie specificate înainte de proiect
este să înceapă.
Este un document principal pentru dezvoltarea software-ului.
Este scris de Analiș ti de Afaceri care interacț ionează cu clienț ii ș i colectează cerinț ele pentru
construieș te software-ul.

Necesitatea/Importanț a SRS:
Stabileș te baza pentru acordul între clienț i ș i furnizori cu privire la ceea ce
produsul software este de făcut.
Descrierea completă a funcț iilor efectuate de software-ul specificat în SRS va
asistaț i utilizatorii să determine dacă software-ul îndeplineș te nevoile lor.
Reduce efortul de dezvoltare.
Pregătirea SRS-ului îi obligă pe grupurile implicate să ia în considerare toate cerinț ele înainte de
designul începe ș i reduce ulterior redesenarea, recodificarea ș i retestarea.
Furnizaț i o bază pentru estimarea costurilor ș i programelor.
Descrierea produsului care urmează să fie dezvoltată dată în SRS este o bază realistă pentru estimare
costurile ș i preț urile proiectului.

Oferiț i o bază pentru verificare ș i validare.

Organizaț iile îș i pot dezvolta planurile de validare ș i verificare mult mai productiv dintr-o
SRS bun.
Facilitaț i Transferul.
SRS-ul facilitează transferul produsului software către utilizatori noi sau către maș ini noi.
Serve as basis for enhancement.
Pentru că SRS discută despre produs, dar nu doar despre proiectul care este dezvoltat, SRS serveș te
ca bază pentru îmbunătăț irea ulterioară a produsului finisat.
 Capitolul 3

1) Descrierea analizei ș i modelării designului

2) Ce este analiza domeniului
3) Ce este modelarea datelor? Explicaț i cardinalitatea ș i modalitatea, obiectul ș i
atribute
4) Explicaț i DFD-ul de nivel 0 ș i DFD-ul de nivel 1 cu un exemplu
5) Desenaț i DFD-ul de nivel 0 ș i nivel 1 pentru sistemul de gestionare a bibliotecii.
6) Desenaț i DFD de nivel 0 ș i nivel 1 pentru problemele de publicare a cărț ilor
7) Desenaț i un diagramă de cazuri de utilizare pentru sistemul de muzică

8) Desenaț i un diagramă de cazuri de utilizare pentru sistemul de management al băncii

9) Descrie
i) Modularitate
ii) Independen ț ă func ț ională
iii) Refactorizare
iv) Ascunderea informa ț iilor
 10) Elemente ale modelului de analiză

[Link] bazate pe scenarii

Sistemul este descris din perspectiva utilizatorului folosind această abordare. Aceasta este adesea
first part of analysis model that is developed to serve as input for the creation of other
elemente de modelare.
[Link] bazate pe clase
Fiecare scenariu de utilizare implică un set de obiecte care sunt manipulate pe măsură ce un actor interacț ionează cu
sistemul. Aceste obiecte sunt împărț ite în clase - o colecț ie de lucruri care au
atribute similare ș i comportamente comune.
[Link] comportamentale
Comportamentul sistemului poate avea un efect profund asupra designului ales.
modelul de analiză trebuie să ofere elemente de modelare care să ilustreze comportamentul. Diagrama de stare
este una dintre metodele de reprezentare a comportamentului unui sistem.
[Link] orientate pe flux
Informaț ia este transformată pe măsură ce circulă prin sistemul bazat pe computer. Sistemul
acceptă intrări sub diverse forme, aplică funcț ii pentru a le transforma; ș i produce ieș iri în
forme diferite. Transformările pot cuprinde o singură comparaț ie logică, o complexă
algoritm numeric sau un sistem expert. Elementele fluxului de informaț ii sunt incluse
aici.

11) Explicaț i traducerea modelului de analiză în modelul de design

Designul software-ului stă la miezul tehnic al ingineriei software ș i este aplicat

indiferent de modelul de proces software care este utilizat. Începând odată ce software-ul
cerinț ele au fost analizate ș i specificate, proiectarea software-ului este prima dintre cele trei
activităț i tehnice—design, generare de cod ș i testare—care sunt necesare pentru a construi ș i
verifică software-ul. Fiecare activitate transformă informaț ia într-un mod care, în cele din urmă
rezultate în software de calculator validat. Fiecare dintre elementele modelului de analiză
oferă informaț ii care sunt necesare pentru a crea cele patru modele de design necesare pentru un
specificaț ie completă a designului.
Fluxul de informaț ii în timpul proiectării software-ului este ilustrat în figura de mai sus. Software
cerinț ele, manifestate prin modele de date, funcț ionale ș i comportamentale, hrănesc designul
Sarcină. Folosind una dintre numeroasele metode de design, sarcina de design produce un design de date, un
design arhitectural, un design de interfaț ă ș i un design de componentă.
Designul datelor transformă modelul domeniului informaț ional creat în timpul analizei în
structuri de date care vor fi necesare pentru a implementa software-ul. Obiectele de date ș i
relaț iile definite în diagrama de relaț ii între entităț i ș i conț inutul detaliat al datelor
ilustrat în dicț ionarul de date oferă baza pentru activitatea de proiectare a datelor. Parte a datelor
designul poate avea loc împreună cu proiectarea arhitecturii software. Mai detaliat
proiectarea datelor are loc pe măsură ce fiecare componentă software este proiectată. Proiectarea arhitecturală
defineș te relaț ia dintre elementele structurale majore ale software-ului, designul
modele‖ care pot fi utilizate pentru a îndeplini cerinț ele care au fost definite pentru
sistem ș i constrângerile care afectează modul în care tiparele de design arhitectural pot fi
fi aplicată Reprezentarea designului arhitectural cadrul unei baze de date pe computer
sistemul - poate fi derivat din specificaț ia sistemului, modelul de analiză, ș i
interacț iunea subunitaț ilor definite în cadrul modelului de analiză. Proiectarea interfeț ei
descrie cum software-ul comunică în interiorul său, cu sistemele care interoperează cu
o interfaț ă implică un flux de informaț ii (de exemplu, date
ș i/sau control) ș i un tip specific de comportament. Prin urmare, diagramele de date ș i flux de control
oferă o mare parte din informaț ia necesară pentru designul interfeț ei. Nivelul componentei
designul transformă elementele structurale ale arhitecturii software într-o procedură
descrierea componentelor software. Informaț ii obț inute din PSPEC, CSPEC ș i
STD serveș te ca bază pentru designul componentelor.
 Capitolul 4

1) Definiț ia testării software-ului

 estarea este un proces de executare a unui program cu intenț ia de a găsi o eroare.
T
T estarea este un set de activităț i care pot fi planificate în avans ș i desfăș urate sistematic. Pentru aceasta
un ș ablon pentru testarea software-ului—un set de paș i în care poț i plasa un caz specific de testare
tehnici de design ș i metode de testare.

2) Diferenț a dintre verificare ș i validare

 3) Explicaț i testarea unităț ilor cu un diagramă clară

(a) Testarea unităț ii este un nivel al procesului de testare a software-ului în care unităț ile/componentele individuale ale
software/sistemele sunt testate.
(b) Scopul este de a valida că fiecare unitate a software-ului funcț ionează conform proiectării.

Figura: Testare Unitară

(c) A unit is the smallest testable part of software.
(d) De obicei are una sau câteva intrări ș i de obicei o singură ieș ire.
(e) În programarea procedurală, o unitate poate fi un program individual, funcț ie, procedură etc.
(f) În programarea orientată pe obiect, cea mai mică unitate este o metodă, care poate aparț ine unei
clasa de bază/clasa superioară, clasă abstractă sau clasă derivată/clasă copil.
Avantaje
Testarea unitară creș te încrederea în modificarea/întreț inerea codului.
(b) Dacă sunt scrise teste unitare bune ș i dacă sunt rulate de fiecare dată când se schimbă codul, probabilitatea
probabilitatea ca orice defecte cauzate de schimbare să fie detectate rapid este foarte mare.
(c) Dacă testarea unitară nu este în vigoare, cel mai mult ce se poate face este să speri la ce e mai bine ș i să aș tepț i până la test.
rezultatele la niveluri mai înalte de testare sunt disponibile.

(d) Dacă codurile sunt deja făcute mai puț in interdependente pentru a face testarea unităț ilor posibilă, rezultatul neintenț ionat
impactul modificărilor asupra oricărui cod este mai mic.

(e)Codurile sunt mai reutilizabile. Pentru a face testarea unităț ilor posibilă, codurile trebuie să fie modulare.
Aceasta înseamnă că codurile sunt mai uș or de reutilizat.
(f) Costul reparării unui defect detectat în timpul testării unităț ii este mai mic în comparaț ie cu cel al defectelor
detectat la niveluri mai ridicate.
(g)Compară costul (timp, efort, distrugere, umilinț ă) al unui defect detectat în timpul
teste de acceptare sau spune când software-ul este activ.
(h)Găsirea erorilor este uș oară. Când un test eș uează, doar modificările recente trebuie să fie verificate.
testare la niveluri mai înalte, modificările efectuate pe parcursul mai multor zile/săptămâni/luni trebuie să fie
debugat.
 4) Explicaț i testarea de integrare de sus în jos

Testarea integrării de sus în jos este o abordare incrementală pentru construcț ia

arhitectură software.
Modulele sunt integrate prin coborârea în ierarhia de control,
începând cu modulul de control principal (programul principal). Module subordonate
(ș i în cele din urmă subordonate) modulului principal de control sunt incorporate în
structura într-un mod profund sau pe lăț ime.

Procesul de integrare se desfăș oară într-o serie de cinci paș i:

1. Modulul principal de control este folosit ca un driver de test ș i stuburile sunt înlocuite pentru
toate componentele subordonate direct modulului de control principal.
2. În funcț ie de abordarea de integrare aleasă (adică, adâncime sau lăț ime întâi),
stuburile subordinate sunt înlocuite unul câte unul cu componente reale.
3. Testele sunt efectuate pe măsură ce fiecare componentă este integrată.

4. La finalizarea fiecărui set de teste, un alt stub este înlocuit cu cel real
componentă.
5. Testarea regresivă (discutată mai târziu în această secț iune) poate fi efectuată pentru a
asiguraț i-vă că nu au fost introduse erori noi.
 5) Explicaț i testarea de integrare de tip bottom-up
Testarea integrării de jos în sus, aș a cum sugerează numele său, începe construcț ia
ș i testarea cu module atomice (adică, componente la cele mai joase niveluri în
structura programului).
Deoarece componentele sunt integrate de jos în sus, funcț ionalitatea
furnizate de componente subordonate unui anumit nivel sunt întotdeauna disponibile
ș i nevoia de stub-uri este eliminată.

O strategie de integrare de jos în sus poate fi implementată cu următorii paș i:

1. Componentele de nivel inferior sunt combinate în clustere (uneori numite construcț ii)
care îndeplinesc o subfuncț ie software specifică.
2. Un driver (un program de control pentru testare) este scris pentru a coordona cazurile de testare.
input and output.
Clusterul este testat.
Conducătorii sunt îndepărtaț i ș i clusterele sunt combinate, deplasându-se în sus în
structura programului.
 6) Explicaț i testarea sistemului cu tipurile sale (Recuperare, securitate, stres)
performanț ă

Testarea recuperării:
 ste un test de sistem care forț ează software-ul să eș ueze în diverse moduri ș i verifică faptul că recuperarea este
E
efectuat corespunzător.
 acă recuperarea este automată, mecanismele de reiniț ializare, punctele de verificare / recuperarea datelor ș i repornirea sunt
D
evaluat pentru corectitudine.
D acă recuperarea necesită intervenț ia umană, timpul mediu de reparare este evaluat pentru a determina
dacă este
este în limite acceptabile
Testare de securitate:
 erifică că mecanismele de protecț ie integrate într-un sistem îl vor proteja de fapt împotriva adecvată.
V
penetratie.
Testare de stres:
 xecuț ia unui sistem într-un mod care necesită resurse într-o cantitate anormală frecvenț ă de
E
volum.
Testarea performanț ei:
Este conceput pentru a testa performanț a în timp de execuț ie a software-ului în contextul unei
sistem integrat.

7) Diferen ț a dintre testarea alfa ș i testarea beta

 8) Diferen ț a între testarea cu cutie albă ș i testarea cu cutie neagră

9) Explicaț i strategiile de depanare

Trei strategii de depanare sunt

Forț ă Brute
2. Întoarcerea
3. Eliminarea cauzelor
Forț ă Brută
 ategoria de depanare prin forț ă brută este probabil cea mai
C
metodă comună ș i cea mai puț in eficientă
pentru izolarea cauzei unei erori software.
 plicaț i metode de depanare prin forț ă brută atunci când nu mai rămâne nimic altceva de făcut. Folosind
A
lasă computerul să găsească
eroare" filosofie, dumi de memorie sunt luate, urme de execuț ie sunt
invocat, iar programul este
încărcat cu declaraț ii de ieș ire.
 S
 peri că undeva în mocirla de informaț ii care este
vei găsi o indiciu că
poate duce la cauza unei erori.
D eș i masa de informaț ii produse poate duce în cele din urmă la
succes, este mai frecvent
duce la eforturi ș i timp pierdut. Gândirea trebuie să fie folosită mai întâi!
2. Întoarcerea
B  acktracking este o abordare de depanare destul de comună care poate fi
utilizat cu succes în mic
programe.
Î ncepând de la locaț ia unde a fost descoperit un simptom,
codul sursă este urmărit
înapoi (manual) până când cauza este găsită.
D  in păcate, pe măsură ce numărul liniilor sursă creș te, numărul
al potenț ialului invers
căile pot deveni imposibil de gestionat.
3. Eliminarea cauzelor
 treia abordare pentru depanare este eliminarea cauzelor.
A
manifestat prin inducț ie sau
deducț ie ș i introduce conceptul de partiț ionare binară.
D atele legate de apariț ia erorii sunt organizate pentru a izola
cauze potenț iale. O "cauză
hipoteza" este concepută ș i datele menț ionate anterior sunt folosite pentru
prove or disprove the
hipoteză.
Alternativ, se dezvoltă o listă cu toate cauzele posibile ș i se efectuează teste.
efectuat pentru a elimina
fiecare. Dacă teste iniț iale indică faptul că o ipoteză de cauză particulară arată
promisiune, datele sunt
rafinate într-o încercare de a izola bug-ul.
 Capitolul 5
1) De ce eș uează proiectele software? Oferiț i motive.

Oamenii de software nu înț eleg nevoile clienț ilor lor

• Domeniul de aplicare al produsului este slab definit

• Schimbările sunt gestionate prost

• Tehnologia aleasă se schimbă
• Nevoile de afaceri se schimbă (sau sunt prost definite)
Termenele limită sunt nerealiste
• Utilizatorii sunt rezistenț i
• Sponsorizarea este pierdută (sau nu a fost obț inută corespunzător niciodată)

Echipa de proiect nu are oameni cu abilităț i adecvate

• Managerii (ș i practicienii) evită cele mai bune practici ș i lecț iile învăț ate.

2) Ce este programarea proiectului? Explica principiul său

Planificarea proiectelor software este o activitate care distribuie efortul estimat pe parcursul
planificat
durata proiectului prin alocarea efortului către sarcini specifice de inginerie software. Este
este important de menț ionat, totuș i, că programul evoluează în timp. În etapele timpurii ale
planificarea proiectului, un
Se dezvoltă un program macroscopic. Acest tip de program identifică toate software-urile majore.
activităț ile de inginerie ș i funcț iile produsului la care sunt aplicate. Pe măsură ce proiectul
primeș te
În curs de desfăș urare, fiecare intrare pe programul macroscopic este rafinată într-un program detaliat.
Aici,
sarcinile software specifice (necesare pentru îndeplinirea unei activităț i) sunt identificate ș i programate.

Principiile de bază ale programării proiectelor software:

I. Compartimentare: Proiectul trebuie să fie compartimentat într-o
numărul de activităț i ș i sarcini gestionabile. Pentru a realiza
compartimentarea, atât produsul cât ș i procesul sunt descompuse.
II. Interdependenț ă: Interdependenț a fiecărei activităț i compartimentate
sarcina noastră trebuie să fie determinată. Unele sarcini trebuie să aibă loc în secvenț ă, în timp ce altele
poate avea loc în paralel. Unele activităț i nu pot începe până când produsul de lucru
produs de altul este disponibil. Alte activităț i pot avea loc independent.
[Link] timpului: Fiecare sarcină care trebuie programată trebuie să fie alocată unui anumit număr
de unităț i de lucru (de exemplu, zile-person de efort). În plus, fiecare sarcină trebuie să fie
a atribuit o dată de început ș i o dată de finalizare care sunt o funcț ie a
interdependenț ele ș i dacă munca va fi desfăș urată cu normă întreagă sau parț ială
bază de timp.
[Link] efortului: Fiecare proiect are un număr definit de membri ai echipei. Ca
alocarea timpului are loc, managerul de proiect trebuie să se asigure că nu mai mult decât
numărul alocat de persoane a fost programat la un moment dat.
V. Responsabilităț i definite: Fiecare sarcină care este programată ar trebui să fie atribuită
un membru specific al echipei.
VI. Rezultate definite: Fiecare sarcină programată ar trebui să aibă un rezultat definit.
outcome.
VII. Mile stone definite: Fiecare sarcină sau grup de sarcini ar trebui să fie asociat
cu un obiectiv de proiect.

3) Enumeraț i patru motive pentru care termenele limită ale proiectului nu pot fi respectate.

o dată limită nerealistă stabilită de cineva din afara software-ului

grup de dezvoltare ș i impus managerilor ș i practicienilor din cadrul grupului.
ii. Schimbarea cerinț elor clienț ilor care nu sunt reflectate în modificările programului.
iii. O subestimare sinceră a cantităț ii de efort ș i/sau a numărului de
resursele care vor fi necesare pentru a face munca.
iv. Riscuri previzibile ș i/sau imprevizibile care nu au fost luate în considerare când a fost
proiectul a început.
v. Dificultăț i tehnice care nu ar fi putut fi prevăzute în avans.
dificultăț i umane care nu ar fi putut fi prevăzute in avans.
vii. Comunicare incorectă între personalul proiectului care duce la întârzieri.
viii. O eș ec al managementului proiectului de a recunoaș te că
proiectul este întârziat ș i există o lipsă de acț iune pentru a corecta problema.

4) Tipuri de risc?

Riscul software implică întotdeauna două caracteristici:

[Link] - riscul poate sau nu poate avea loc; adică, nu există 100 la sută
riscuri probabile.
[Link]—dacă riscul devine realitate, vor apărea consecinț e sau pierderi nedorite.
Când riscurile sunt analizate, este important să se cuantifice nivelul de incertitudine ș i gradul
al
pierdere asociată cu fiecare risc.
Pentru a realiza acest lucru, sunt considerate diferite categorii de riscuri.
 Riscurile proiectului ameninț ă planul de proiect. Asta înseamnă că, dacă riscurile proiectului devin reale, este foarte probabil că
programul proiectului se va întârzia ș i costurile vor creș te. Riscurile proiectului identifică potenț ialul
bugetar, program, personal (angajare ș i organizare), resursă, părț ile interesate, ș i
problemele de cerinț e ș i impactul acestora asupra unui proiect software.
Riscurile tehnice ameninț ă calitatea ș i punctualitatea software-ului care trebuie produs.
 iscurile tehnice identifică potenț iale probleme de proiectare, implementare, interfaț ă, verificare ș i
R
probleme de întreț inere. În plus, ambiguitatea specificaț iilor, incertitudinea tehnică,
obsolescenț a tehnică ș i tehnologia de vârf sunt, de asemenea, factori de risc. Tehnic
riscurile apar deoarece problema este mai greu de rezolvat decât ai crezut că va fi.
Riscurile de afaceri ameninț ă viabilitatea software-ului care urmează să fie construit ș i adesea pun în pericol
proiectul sau produsul.
Candidaț ii pentru primele cinci riscuri de afaceri sunt
(1) construirea unui produs sau sistem excellent pe care nimeni nu-l vrea cu adevărat (riscul de piaț ă)
(2) construirea unui produs care nu mai se încadrează în strategia generală de afaceri pentru
companie (riscuri strategice)
construind un produs pe care echipa de vânzări nu înț elege cum să-l vândă
riscul)
(4) pierderea sprijinului conducerii superioare din cauza unei schimbări de focalizare sau a unei schimbări
în oameni (managementul riscurilor), ș i
(5) pierderea angajamentului bugetar sau al personalului (riscuri bugetare).
 iscurile cunoscute sunt cele care pot fi descoperite după o evaluare atentă a proiectului
R
planul, mediul de afaceri ș i tehnic în care proiectul este dezvoltat,
ș i alte surse de informaț ii fiabile (de exemplu, dată de livrare nerealistă, lipsă de
cerinț e documentate sau domeniu de software, mediu de dezvoltare slab).
Riscurile previzibile sunt extrapolate din experienț a anterioară a proiectului (de exemplu, fluctuaț ia personalului,
comunicare slabă cu clienț ii, diluarea efortului personalului ca urmare a întreț inerei continue
solicitanț ele sunt onorate).
Riscurile imprevizibile sunt jokerul din pachet.

5) Rafinatea riscurilor

În etapele timpurii ale planificării proiectului, un risc poate fi formulat destul de general. Pe măsură ce timpul trece
și
pe măsură ce se învaț ă mai multe despre proiect ș i riscul asociat, poate fi posibil să se rafineze riscul într-un set
al
riscuri mai detaliate, fiecare oarecum mai uș or de atenuat, monitorizat ș i gestionat. O modalitate de
fă asta
este de a reprezenta riscul în format condiț ie-tranziț ie-consecinț ă (CTC). Adică, riscul este
declarat
având în vedere că <condiț ie>, atunci există îngrijorarea că (posibil)
<consecinț ă>. Folosind formatul CTC pentru riscul de reutilizare s-ar putea scrie:
Având în vedere că toate componentele software reutilizabile trebuie să respecte standarde de design specifice ș i
că
uni nu se conformează, apoi există îngrijorarea că (posibil) doar 70 la sută din planificat
modulele reutilizabile pot fi de fapt integrate în sistemul realizat, rezultând în necesitatea
către
proiectaț i personalizat restul de 30 la sută din componente. Această condiț ie generală poate fi
rafinat
în următorul mod:

Sub-condiț ia 1: Anumite componente reutilizabile au fost dezvoltate de o terț ă parte fără

cunoș tinț e despre standardele de design intern.
Sub-condiț ie 2: Standardul de design pentru interfeț ele componentelor nu a fost solidificat ș i
mai
nu conform anumitor componente reutilizabile existente.
Sub-condiț ia 3: Anumite componente reutilizabile au fost implementate într-o limbă care este
nu
susț inut pe mediul ț intă. Consecinț ele asociate cu aceste rafinate
subcondiț ii
rămâne acelaș i (adică, 30 la sută dintre componentele software trebuie să fie personalizate
inginerie), dar rafinamentul ajută la izolarea riscurilor subiacente ș i ar putea conduce la
easier
analiză ș i răspuns.

6) Descrie în detaliu strategia RMMM.

Plan de reducere a riscurilor, monitorizare ș i gestionare (RMMM).
O strategie de gestionare a riscurilor poate fi inclusă în planul proiectului software sau în riscul
paș ii de management pot fi organizaț i într-o separată Mitigare a Riscurilor, Monitorizare ș i
Plan de Management.
Planul RMMM documentează toată munca efectuată ca parte a analizei riscurilor ș i este utilizat de către
manager de proiect ca parte a planului general de proiect.
 dată ce RMMM a fost documentat ș i proiectul a început, mitigarea riscurilor ș i
O
monitorizare
paș ii încep.
Mitigarea riscurilor este o activitate de evitarea problemelor.
 onitorizarea riscurilor este o activitate de urmărire a proiectelor cu trei obiective principale:
M
(1) Pentru a evalua dacă riscurile prevăzute apar, de fapt;
(2) Pentru a asigura că paș ii de evitare a riscurilor definiț i pentru risc sunt aplicaț i corespunzător;
(3) Pentru a colecta informaț ii care pot fi utilizate pentru analiza riscurilor viitoare.
 altă sarcină a monitorizării riscurilor este de a încerca să aloce originea (ce riscuri au cauzat care
O
probleme pe parcursul proiectului).
O strategie eficientă trebuie să ia în considerare trei probleme:
Evitarea riscurilor
monitorizarea riscurilor
Managementul riscurilor ș i planificarea măsurilor de urgenț ă

Dacă o echipă de software adoptă o abordare proactivă faț ă de risc, evitarea este întotdeauna cea mai bună.
strategia.
Acest lucru se realizează prin dezvoltarea unui plan pentru mitigarea riscurilor. Pentru a diminua acest risc, proiectul
management must develop a strategy for reducing turnover.
 rintre paș ii posibili care pot fi urmaț i se numără
P
Întâlniț i personalul actual pentru a determina cauzele fluctuaț iei de personal (de exemplu, condiț ii de muncă proaste)

condiț ii, salarii mici ș i o piaț ă a muncii competitivă).

Mitigaț i cauzele care sunt sub controlul nostru înainte de a începe proiectul.
Odată ce proiectul începe, presupuneț i că vor avea loc venituri ș i dezvoltaț i.
tehnici pentru a asigura continuitatea atunci când oamenii pleacă.
Organizaț i echipele de proiect astfel încât informaț iile despre fiecare activitate de dezvoltare să fie
dispersat pe scară largă.
Definiț i standardele de documentare ș i stabiliț i mecanisme pentru a vă asigura că
documents are developed in a timely manner.
Efectuează revizuiri între colegi pentru toată munca (astfel încât mai mult de o persoană să fie 'la curent').
Atribuiț i un membru al personalului de rezervă pentru fiecare tehnologist critic.
 e măsură ce proiectul avansează, activităț ile de monitorizare a riscurilor începe. Managerul de proiect
P
monitoare
factori care pot oferi o indicaț ie dacă riscul devine mai probabil sau mai puț in probabil.
În cazul unui turnover ridicat al personalului, următorii factori pot fi monitorizaț i:
Atitudinea generală a membrilor echipei bazată pe presiunea proiectului.
Gradul în care echipa s-a unit.
Relaț iile interumane între membrii echipei.
posibile probleme cu compensaț iile ș i beneficiile.
Disponibilitatea locurilor de muncă atât în cadrul companiei, cât ș i în afara acesteia.

7) Enumeraț i caracteristicile SCM.

Versionare: Pe măsură ce un proiect avansează, vor exista multe versiuni ale produselor individuale de lucru.
creat.
Repozitoriul trebuie să fie capabil să salveze toate aceste versiuni pentru a permite o gestionare eficientă a
lansări de produse ș i pentru a permite dezvoltatorilor să revină la versiunile anterioare în timpul testării ș i
debuscare.
Urmărirea dependenț elor ș i managementul schimbărilor: Repositorul gestionează o gamă largă de
relaț iile dintre elementele de date stocate în acesta. Acestea includ relaț ii între
entităț i ș i procese de întreprindere, printre părț ile unei arhitecturi de aplicaț ie, între design
componentele ș i arhitectura informaț ională a întreprinderii, între elementele de design ș i
livrabile ș i aș a mai departe.
Trasarea cerinț elor: Această funcț ie specială depinde de gestionarea linkurilor ș i oferă
capacitatea de a urmări toate componentele de design ș i construcț ie ș i livrabilele care rezultă dintr-o
specificaț ia cerinț elor specifice (urmarirea în avans). În plus, oferă capacitatea de a
identifică care cerinț ă a generat un anumit produs de lucru (urmărire inversă).
Gestionarea configuraț iei: O facilitate de gestionare a configuraț iei urmăreș te o serie de
configurations representing specific project milestones or production releases.
Trail-uri de audit: Un trail de audit stabileș te informaț ii suplimentare despre când, de ce ș i de către
cui
schimbările sunt făcute. Informaț iile despre sursa modificărilor pot fi introduse ca atribute ale
obiecte specifice în depozit.
 8) Activităț ile SCM
Activităț ile de gestionare a configuraț iei software sunt: Identificarea modificării pentru a controla
ș i gestionaț i elementele de configurare, fiecare trebuie să fie numit ș i gestionat folosind un model orientat pe obiect
abordare
.Obiectele de bază sunt create de inginerii software în timpul analizei, proiectării, codării sau testării
.Obiectele agregate sunt colecț ii de obiecte de bază ș i alte obiecte agregate
.Un diagramă entitate-relaț ie (E-R) poate fi utilizat pentru a arăta interrelaț iile dintre
obiectele

Controlul versiunilor
.Combină proceduri ș i instrumente pentru a gestiona diferitele versiuni ale obiectelor de configurare
creat în timpul procesului software
.O entitate este compusă din obiecte la acelaș i nivel de revizuire
.O variantă este un set diferit de obiecte la acelaș i nivel de revizie ș i coexista cu altele.
variante
.O nouă versiune este definită atunci când au fost aduse modificări majore unuia sau mai multor obiecte.

Controlul modificărilor
.Cererea de schimbare a fost trimisă ș i evaluată pentru a evalua meritele tehnice ș i impactul asupra
alte obiecte de configurare ș i buget
.Raportul de schimbare conț ine rezultatele evaluării
.Autoritatea de control al modificărilor (CCA) ia decizia finală cu privire la statutul ș i prioritatea
schimbare pe baza raportului de schimbare.

Auditoriu de Configurare Software

.O auditare a configuraț iei software completează revizuirea tehnică formală prin evaluarea unui
obiect de configurare pentru caracteristici care, în general, nu sunt luate în considerare în timpul revizuirii. The
auditul pune întrebările ș i oferă răspunsuri la întrebările cum ar fi:

.A fost realizată modificarea specificată în ECO? Au fost făcute modificări suplimentare?
încorporat?
.A fost efectuat un control tehnic formal pentru a evalua corectitudinea tehnică?

Raportarea stării Configurarea raportării stării (uneori numită contabilitate a stării) este
o sarcină SCM care răspunde la următoarele întrebări:
Ce s-a întâmplat?
2. Cine a făcut-o?
3. Când s-a întâmplat?
4. Ce altceva va fi afectat?
 9) Descrie factorul uman în spectrul managementului software.

Oamenii
Factorul uman este atât de important încât Institutul de Inginerie a Software-ului a dezvoltat o
modelul de maturitate a capacităț ilor de gestionare a resurselor umane (PM-CMM), pentru a îmbunătăț i pregătirea
organizaț ii software pentru a întreprinde aplicaț ii din ce în ce mai complexe prin ajutorul atragerii,
creș te, motivează, implementează ș i păstrează talentul necesar pentru a-ș i îmbunătăț i dezvoltarea software
capabilitate. Modelul de maturitate în managementul oamenilor defineș te următoarele domenii cheie de practică
pentru persoanele din software: recrutare, selecț ie, managementul performanț ei, formare, compensaț ie
dezvoltarea carierei, organizarea ș i proiectarea muncii, ș i dezvoltarea echipei/culturii.
Organizaț iile care obț in niveluri ridicate de maturitate în domeniul managementului resurselor umane au o
probabilitate mai mare de implementare a unor practici eficiente de inginerie software. PM-CMM
este un companion pentru modelul de maturitate a capacităț ii software care ghidează organizaț iile în
crearea unui proces software matur.
Următoarele sunt diferitele categorii de persoane asociate cu proiectul.
 ărț ile interesate: - Acestea includ managerii seniori, managerii de proiect (tehnici),
P
Practicieni,
Customers, End user
L eaderi de echipă: - Lideri ai diverselor echipe asociate cu proiectul
T  he Software Team: - Entire software team
E  chipe Agile: - Echipe temporare asociate cu software
P  robleme de coordonare ș i comunicare
 Capitolul 6
1) Ce sunt activită ț ile SQA

Activităț i SQA
Aceste activităț i sunt efectuate (sau facilitate) de un grup SQA independent care:
1. Pregăteș te un plan SQA pentru un proiect.
Planul identifică evaluările care trebuie efectuate, auditurile ș i revizuirile care trebuie realizate,
standarde care
sunt aplicabile proiectului, proceduri pentru raportarea ș i urmărirea erorilor, produse de muncă care
sunt
produse de grupul SQA ș i feedbackul care va fi oferit echipei de software.
[Link]ă la dezvoltarea descrierii procesului de software al proiectului.
Echipa de software alege un proces pentru munca ce urmează a fi efectuată. Grupul SQA revizuieș te
the
descrierea procesului pentru conformitatea cu politica organizaț ională, standardele interne ale software-ului
extern
standarde impuse
3. Examinează activităț ile de inginerie software pentru a verifica conformitatea cu cele definite
procesul software.
Grupul SQA identifică, documentează ș i urmăreș te abaterile de la proces ș i verifică
că
corecț iile au fost făcute.
4. Auditurile produselor software desemnate pentru a verifica conformitatea cu cele definite ca
parte din
procesul software.
Grupul SQA revizuieș te produsele de lucru selectate; identifică, documentează ș i urmăreș te abaterile;
verifică
că au fost făcute corecturi; ș i periodic raportează rezultatele muncii sale proiectului
manager.
5. Asigură că abaterile în activitatea software ș i produsele de lucru sunt documentate ș i
manipulat
conform unei proceduri documentate.
Deviations pot fi întâlnite în planul de proiect, descrierea procesului, standardele aplicabile,
sau
produse de lucru în ingineria software.
6. Înregistrează orice nerespectare ș i raportează conducerii superioare.
Articolele de neconformitate sunt urmărite până când sunt rezolvate.
 2)Explain DMAIC and DMADV of six sigma strategy.

DMAIC
Metodologia de proiect DMAIC are cinci etape:
Definiț i sistemul, vocea clientului ș i cerinț ele acestora, precum ș i obiectivele proiectului.
în mod specific.
Măsuraț i aspectele cheie ale procesului actual ș i colectaț i date relevante.
Analizaț i datele pentru a investiga ș i verifica relaț iile cauză-efect. Stabiliț i ce
relaț iile sunt ș i se încearcă să se asigure că toț i factorii au fost luaț i în considerare. Cautaț i
cauza principală a defectului aflat în anchetă.
Îmbunătăț iț i sau optimizaț i procesul actual pe baza analizei de date folosind tehnici precum
designul experimentelor sau prevenirea erorilor ș i munca standard pentru a crea un nou stat viitor
proces. Configuraț i runde pilot pentru a stabili capacitatea procesului. Controlaț i procesul viitor pentru a
asiguraț i-vă că orice abateri de la ț intă sunt corectate înainte de a duce la defecte.
Implementaț i sisteme de control, cum ar fi controlul statistic al proceselor, tablouri de producț ie, vizual
locuri de muncă ș i monitorizaț i continuu procesul.
Unele organizaț ii adaugă un pas de Recunoaș tere la început, care este de a recunoaș te dreptul
problemă de rezolvat, oferind astfel o metodologie RDMAIC.

DMADV sau DFSS

Metodologia proiectului DMADV, cunoscută sub numele de DFSS („Design For Six Sigma”), se caracterizează prin
cinci etape:
Definiț i obiectivele de design care sunt consistente cu cerinț ele clienț ilor ș i strategia întreprinderii.
Măsuraț i ș i identificaț i CTQ-uri (caracteristici esenț iale pentru calitate), produs
capabilităț i, capacitatea procesului de producț ie ș i riscuri.
Analiza pentru a dezvolta ș i a proiecta alternative
Proiectaț i o alternativă îmbunătăț ită, cea mai potrivită în funcț ie de analiza din pasul anterior.
Verificaț i designul, configuraț i runde pilot, implementaț i procesul de producț ie ș i predati-l
proprietarul(-ii) procesului.

3) Care sunt beneficiile ISO 9000.

Procedurile bine definite ș i documentate îmbunătăț esc consistenț a rezultatelor

Calitatea este măsurată constant
Procedurile asigură că se iau măsuri corective de fiecare dată când apar defecte
Rata defectelor scade
Defectele sunt identificate mai devreme ș i sunt corectate la un cost mai mic
Definirea procedurilor identifică practicile actuale care sunt depăș ite sau ineficiente
Procedurile documentate sunt mai uș or de urmat pentru noii angajaț i
Organizaț iile îș i menț in sau îș i cresc cota de piaț ă, sporind vânzările sau veniturile
Îmbunătăț irea fiabilităț ii produsului
Control ș i flux mai bun al procesului
Documentaț ie mai bună a proceselor
Conș tientizare mai mare a calităț ii angajaț ilor
Reduceri în deș eurile de produse, recompense ș i respingeri.
 4) Explica ț i factorii de calitate McCall. (6M)

Factorii de calitate a software-ului McCall, arătaț i în figura de mai sus, se concentrează pe trei aspecte importante.
al unui
software product:
caracteristicile operaț ionale ale oits,
capacitatea sa de a suferi schimbări,
adaptabilitatea sa la noi medii.
Factorii/atributele includ:
Corectitudine: Măsura în care un program îndeplineș te specificaț ia sa ș i satisfice
clientului
obiectivele misiunii.
O fiabilitate: Măsura în care un program poate fi aș teptat să îndeplinească scopul său destinat
funcț ie cu
precizia necesară
Eficienț ă: Cantitatea de resurse de calcul ș i cod necesare de un program pentru a
perform its
funcț ie.
Integritate: Gradul în care accesul la software sau date de către persoane neautorizate poate fi
controlat.
usabilitate: efortul necesar pentru a învăț a, a opera, a pregăti inputul ș i a interpreta
Mentenabilitate: Efortul necesar pentru a localiza ș i a corecta o eroare într-un program.
Flexibilitate: Efortul necesar pentru a modifica un program operaț ional.
Testabilitate: Efortul necesar pentru a testa un program pentru a se asigura că îndeplineș te scopul său
funcț ie.
oPortabilitate: Efortul necesar pentru a transfera programul de pe un hardware ș i/sau software.
sistem
mediu în altul.
oReusability:Extent to which a program [or parts of a program] can be reused in other
aplicaț ii - legate de ambalare ș i domeniul funcț iilor pe care programul le îndeplineș te.
oInteroperabilitate: Efortul necesar pentru a cupla un sistem la altul.
 5) Explica ț i CMMI cu un diagramă clară

 odelul de Maturitate a Capacităț ii Integrat (CMMI) este o abordare de îmbunătăț ire a proceselor care ajută
M
organizaț iile îș i îmbunătăț esc performanț a.
C MMI (Modelul de Integritate a Maturităț ii Capacităț ii) este un cadru industrial dovedit pentru a îmbunătăț i produsul
calitate ș i eficienț ă în dezvoltare atât pentru hardware cât ș i pentru software
O
 biectivele CMMI:
O
 biective specifice
a. Establish Estimates
b. Dezvoltă un plan de proiect
c. Obț ineț i angajamentul faț ă de plan
O
 biective Generice:
a. Realizarea unor obiective specifice
b. Instituț ionalizaț i un proces gestionat
c. Instituț ionalizaț i un proces definit
d. Institutionalizaț i un proces gestionat cantitativ
e. Instituț ionalizaț i un proces de optimizare
CMMI maturity levels:
N
 ivel 1: Iniț ial. Procesul software este caracterizat ca fiind ad-hoc ș i ocazional chiar
haotic. Puț ine procese sunt definite, iar succesul depinde de efortul individual.
N ivelul 2: Repetabil. Procesele de bază ale managementului proiectelor sunt stabilite pentru a urmări costurile.
programare ș i funcț ionalitate. Disciplina procesului necesar este în vigoare pentru a repeta etapele anterioare
succese în proiecte cu aplicaț ii similare.
 ivel 3: Definit. Procesul software pentru atât activităț ile de gestionare, cât ș i cele de inginerie este
N
documentat, standardizat ș i integrat într-un proces software la nivelul întregii organizaț ii. Toate
proiectele utilizează o versiune documentată ș i aprobată a procesului organizaț iei pentru dezvoltare
ș i software de suport. Acest nivel include toate caracteristicile definite pentru nivelul
 ivel 4: Gestionat. Măsuri detaliate ale procesului software ș i calităț ii produsului sunt
N
colectate. Atât procesul software, cât ș i produsele sunt înț elese ș i controlate cantitativ
utilizând măsuri detaliate. Acest nivel include toate caracteristicile definite pentru nivelul
 ivel 5: Optimizare. Îmbunătăț irea continuă a procesului este posibilă prin feedback cantitativ.
N
din proces ș i din testarea ideilor ș i tehnologiilor inovatoare. Acest nivel include tot
caracteristici definite pentru nivelul 4.