OSwebok(Software Engineering Body of Knowledge) este o iniț iativă a IEEE Computer

Societatea are scopul de a crea un consens asupra domeniilor de cunoș tinț e ale
ingineria software ș i domeniul său. A început ca o colaborare între IEEE CS, ACM
este Universitatea din Québec la Montréal ș i a inclus participarea internaț ională a industriei,
societăț i de profesioniș ti, academie ș i autori. Obiectivele Swebok sunt:

y Oferirea unei viziuni consistente asupra ingineriei software la nivel mondial

y Clarificarea limitele planificării software cu privire la alte discipline
ca ș tiinț ă a calculatoarelor, management de proiecte, matematică, printre altele
y Prover o bază pentru dezvoltarea curriculară ș i materialul de licenț ă individuală
O Swebok este împărț it în părț i pentru a facilita înț elegerea ș i a permite specializarea.
Fiecare parte se numeș teDomeniu de Cunoș tinț e. Domeniile de cunoș tinț e definite sunt:

y Cerinț e de software
y Proiect de software
y Implementarea software-ului
y Teste de Software
y Întreț inerea software-ului
y Gestionarea Configurării
y Gestionarea Ingineriei Software
y Procesul de Inginerie a Software-ului
y Métode ș i Unelte de Inginerie a Software-ului
y Calitatea software-ului

Domenii de cunoș tinț e conform SWEBOK

SWEBOK este un ghid de utilizare ș i aplicare a celor mai bune practici în inginerie.
Software, informat, ra ț ional ș i rezonabil. A fost dezvoltat cu cuno ș tinț e
recoltate în perioada a 4 decenii ș i revizuite de numeroș i profesioniș ti din diverse
ț ări implicate în Ingineria Software. Principalul său obiectiv a fost să stabilească un
un set adecvat de criterii ș i norme pentru practica profesională a Ingineriei de
Software. În acest ghid, Ingineria Software a fost împăr ț ită în 10 domenii de
cunoș tinț e, de asemenea cunoscute sub numele de KAs (Arii de Cunoaș tere), care vor fi descrise în
secvenț ă (SWEBOK, 2004).

1 Cerinț e de Software
Cerin ț ele exprimă necesită ț ile ș i restric ț iile impuse asupra produsului de
software care contribuie la soluț ionarea unor probleme din lumea reală. Această domeniu
învolve elicitatea, analiza, specificarea ș i validarea cerin ț elor de software
(SWEBOK, 2004).
Conform lui Breitman ș i Sayão (2005), cerin ț ele software-ului sunt clasificate în:
· Cerinț e funcț ionale: corespund funcț ionalităț ii software-ului ș i ceea ce face sistemul
trebuie să facă
· Cerinț e non-funcț ionale: exprimă restricț ii ș i caracteristici pe care software-ul trebuie să le îndeplinească
a ș teptare sau ter
· Cerin ț e inverse: definim stări ș i situa ț ii care nu pot apărea niciodată.
Pressman (2002) citează că "dacă nu analizezi, este extrem de probabil să construieș ti o
o solu ț ie software foarte elegantă care rezolvă problema gre ș ită.
atitudinea poate rezulta în pierdere de timp ș i bani, persoane frustrate ș i clien ț i
insatisfăcuț i.

2 Design de Software
Conform SWEBOK (2004), acest domeniu implica definirea arhitecturii, componentelor,
interfeț e ș i alte caracteristici ale unui sistem sau componentă. Vizualizat ca un
proces, această zonă este o etapă a ciclului de viaț ă al Ingineriei Software, unde
Cerinț ele sunt analizate pentru a produce o descriere a arhitecturii software-ului. Pentru
Pressman (2002), designul software-ului "este un proces iterativ prin care
cerin ț ele sunt traduse într-un document pentru construc ț ia software-ului.

3 Construcț ie de Software
Se referă la implementarea software-ului, verificarea, teste de unitate, teste de
integrare ș i depanare. Această zonă este implicată în toate domeniile de cunoș tinț e,
cu toate acestea, este strâns legată de domeniile Design ș i Testare de Software, deoarece procesul de
construc ț ia acoperă semnificativ aceste două domenii (SWEBOK, 2004). Domeniile
corelate cu construc ț ia de software, conform SWEBOK (2004) sunt:

· Fundamente: minimiza complexitatea, anticipează schimbările, construieș te pentru a verifica ș i

standarde de construcț ie;
· Gestionare da construção: modele, planificare e metrice;
· Consideraț ii practice: design, limbaje, codare, teste, reutilizare, calitate ș i
integrare.

Este important ca funcț ionalităț ile software-ului să fie testate pe parcursul întregului proces
de dezvoltare, fără a lăsa doar pentru a etapă de teste.

4 Teste de Software
Teste de software este o activitate realizată pentru a evalua calitatea produsului,
căutând să identifice defectele ș i problemele existente (SWEBOK, 2004).
Potrivit lui Pressman (2002), "testarea software-ului este un element critic al asigurării calităț ii"
de software e reprezintă revizia finală a specificaț iei, proiectului ș i generării de cod.
Al doilea Coelho (2005) sistem de operare
tipuri de teste sunt
Teste func ț ional: verifică regulile de afaceri, condi ț ii valide ș i invalide;
Teste de recuperare a defectelor: defectele sunt provocate de mai multe ori pentru a
verificare a eficien da ț ă recuperare;
Teste de performanț ă: verifică timpul de răspuns ș i procesare pentru configuraț ii
diferite;
Teste de securitate ș i control al accesului: verifică funcț ionalitatea mecanismelor de
protecț ie de acces e de date
Teste de interfe ț e cu utilizatorul: verifică navigarea, consisten ț a ș i modelele;
· Teste de volum: verifică până unde software o suporta.
Etapa de testare a software-ului este relevantă pentru ca erorile să poată fi găsite ș i
corectate înainte ce o software fie livrare ao clientă.

5 Întreț inere de Software

Această arie de cunoș tinț e este definită ca totalitatea activităț ilor necesare pentru
oferi suport cost-eficient pentru un sistem software, care poate avea loc înainte sau după
da entrega. Înainte de livrarea software-ului se desfăș oară activităț i de planificare ș i
apoi, modificările sunt făcute cu scopul de a corecta deficienț ele, de a îmbunătăț i performanț a
să le adaptezi la un mediu extern (SWEBOK, 2004). Tipurile de modificări în timpul
a fază de întreț inere al doilea Presar (2002) sunt
· Întreț inere corectivă: modifică o software pentru a corecta erori;
· Mentenanț ă adaptativă: modifică software-ul pentru a acomoda schimbările în mediul său
extern
· Între ț inere perfectivă: îmbunătă ț eș te o software (solicitações ale clientului);
· Întreț inere preventivă (reinginerie): modifică software-ul pentru a-l face mai uș or
de a fi corectate, adaptate îmbunătățe ite.
Aproximativ 60% din efortul depus de o organiza ț ie de dezvoltare este
referente à între ț de
inere software. Este procentual continuu
crescendo pe măsură ce mai multe programe sunt produse. Întreț inerea software-ului nu este
doar corecta erori. Doar 20% din munca de întreț inere se referă la corectarea
falhas ș i, ceilal ț i 80% se referă la adapta ț ii la mediu extern ș i îmbunătă ț iri
solicitate păr utilizatori (PRESSMAN, 2002).

6 Gestionare de Configurare de Software

Conform lui Cunha et al (2004), GCS (Gestionarea Configuraț iei Software) este un
procesul care oferă resurse pentru identificarea, controlul evoluț iei ș i auditarea celor
artefacte de software create în timpul dezvoltării proiectului. În linii mari, este
controlul versiunilor software. Scopul GCS este de a stabili ș i menț ine integritatea
două produse software pe parcursul întregului lor ciclu de via ț ă (SWEBOK, 2004):
· Identificare a configurare fă software em um dado moment
· Controla sistematic schimbările de configurare;
· Menț inerea integrităț ii ș i a trasabilităț ii configuraț iei pe parcursul ciclului de viaț ă al
software
· Controla ț i integritatea artefactelor compuse, având în vedere fiecare dintre
componente fă software
· Registrar e a controla o stat fă proces de modificare.

Cu toate acestea, aplicarea sa în companiile de dezvoltare software este complexă, ș i...

uneori ineficientizată de cheltuieli. O modalitate de a o ocoli este să dezvoltăm o
metodologia de gestionare a configura ț iei care ț ine cont doar de aspecte
relevante pentru realitatea companiei, eliminându-i pe cei care sunt mai puț in utilizaț i.

7 Gestionare de Inginerie de Software

Segundo SWEBOK (2004), Gerenciamento de Engenharia pode-se definir como a
aplicarea activită ț ilor de management: planificare, coordonare, măsurare,
monitorizare, control ș i documentaț ie, asigurând că dezvoltarea ș i managementul
software sejam sistematici disciplinati e calificaț i.
O Gestionare de Inginerie é tratat sob două aspecte:
Inginerie de Proces: se referă la activită ț ile desfă ș urate pentru generarea de
políticas, padrões obiective e organiza ț ionale coerente;
Ingineria de Măsurare: se referă la atribuirea de valori ș i etichete activită ț ilor
referin ț e à Inginerie de Software.

Gestionarea procesului ș i măsurarea sunt importante în toate domeniile

cuno ș tinț e, dar Managementul Ingineriei abordează aceste aspecte într-un mod
mai direct. Un mare aliat în acest domeniu de cuno ș tinț e este Managementul de
Proiecte, ce poate ser visto a urmează.

7.1 Gestionare de Proiecte de Software

Proiectul este o întreprindere temporară, de elaborare progresivă ș i cu scopul de
crea ț i un produs sau serviciu unic (PMBOK, 2004).
· Temporar: proiectul are un început ș i un sfârș it bine definite ș i poate fi de scurtă sau lungă durată.
durata. Proiectul se încheie când obiectivele sale sunt atinse;
· Elaborare progresivă: dezvoltarea are loc în etape ș i continuă prin
incremento
· Produs tu serviciu unic fiecare proiect é exclusiv

Potrivit PMBOK (2004), gestionarea proiectelor "este aplicarea cunoș tinț elor,
abilită ț i, instrumente ș i tehnici la activită ț ile proiectului pentru a
a îndeplini cerinț ele dumneavoastră". Se realizează prin cinci grupuri de procese: iniț ierea,
planificare execuț ie monitorizare e controle, e încheiere.
Conform lui Pressman (2002), gestionarea proiectului implică planificarea, monitorizarea ș i
controlul personalului, procesul ș i evenimentele care au loc pe măsură ce
software evoluează de la un concept preliminar la o implementare opera ț ională.
managementul proiectelor ajută organiza ț iilene vom ocupa a de
nevoile clienț ilor săi, standardizând sarcinile de zi cu zi ș i reducând numărul de
sarcini, care sunt adesea uitate (PMI-SC, 2006).
În final, gestionarea proiectelor înseamnă menț inerea echilibrului între domeniu, calitate, costuri, resurse
este timp (PMBOK, 2004). Este rolul managerului de proiect de a evalua riscurile ș i impacturile
asociaț i a orice schimbare em um robe factori.

8 Inginerie de Proces de Software

Ingineria procesului poate fi interpretată ca o viziune generală asupra problemelor
relacionate cu procesul de Inginerie a Software-ului, în principal activită ț ile
legate de defini ț ie, implementare, evaluare, măsurare, gestionare,
schimbări ș i îmbunătăț iri ale procesului de ciclu de viaț ă al software-ului (SWEBOK, 2004). O
Obiectivul Ingineriei Procesului de Software este de a implementa procese noi ș i
cei mai buni să fie nu escop individual de proiect tu organizational

9 Unelte e Metode de Software

Instrumentele de dezvoltare a software-ului sunt instrumente create pentru a ajuta la
ciclul de via ț ă al software-ului. Aceste unelte de obicei automatizează unele
activităț ile procesului de dezvoltare, făcând ca analistul să se concentreze pe
activită ț i care necesită un efort intelectual mai mare (SWEBOK, 2004). Metode de
Ingineria Software impune structură asupra activită ț ii de dezvoltare ș i
între ț inerea software-ului cu scopul de a o face sistematică ș i mai predispusă la
succes (SWEBOK, 2004). Această arie de cuno ș tinț e are ca obiectiv cercetarea
instrumente ș i metode care cresc productivitatea dezvoltatorilor în timp ce
reducem apari ț ia defectelor în dezvoltare (FERNANDES, 2003).

10 Calitate de Software
Calitatea software-ului nu poate fi înț eleasă ca perfecț iune. Calitatea este un concept
multidimensional, realizat de un set de atribute, reprezentând mai multe aspecte
relacionate cu produsul: dezvoltare, întreț inere ș i utilizare. Calitatea este ceva fezabil,
relativo, dinâmico e evolutivo, adequando-se ao nível dos objetivos a serem atingidos
(SIMÃO, 2002). Unul dintre principalele obiective ale Ingineriei Software este de a îmbunătă ț i
calitate
două produse de software, aceasta vizează stabilirea de metode ș i tehnologii pentru a construi
produtos de software de qualidade dentro dos limites de tempo e recursos disponíveis. A
calitatea software-ului este direct legată de calitatea procesului prin intermediul
ce software este dezvoltat, aș adar, pentru a avea calitate într-un produs software
este necesar să ai un proces de dezvoltare bine definit, care trebuie să fie
documentat e însoț it (SWEBOK, 2004).
Evaluarea calităț ii produselor software este de obicei realizată prin intermediul unor modele.
de evaluare a calită ț ii. Aceste modele descriu ș i organizează
proprietă ț i de calitate ale produsului în evaluare. Modelele de evaluare mai
accepturi e folosite nu piaț ă sunt
· CMMI (Capability Maturity Model Integration), proposto pelo CMM (Capability Maturity
Model);
· Norma ISO/IEC 9126, propusă de ISO (Organizaț ia Internaț ională de Standardizare).

Organiza ț iile dezvoltatoare ale acestor modele de calitate oferă sigilii de

calitate pentru companiile care se supun evaluărilor ș i sunt în cadrul
standarde propuse. Aceste sigilii sunt foarte apreciate de companiile care cumpără
software, ș i reprezintă un diferen ț iat competitiv pe pia ț ă. Cu toate acestea, nu toate ...
companiile au condiț ii financiare pentru a suporta costurile unei achiziț ii de un sigiliu de
calitate, deoarece implementarea unui proces de calitate într-o companie implică costuri
elevate. Cu toate acestea, este posibil să se implementeze bune practici ș i să se dezvolte un proces de
dezvoltare organizată adaptând modele de dezvoltare cunoscute,
cheltuind mai pu ț ine resurse ș i oferind un minim de sistematizare în
dezvoltarea software-ului, pentru a avea o calitate mai mare.