Principalele capitole ale cursului1. Introducere: activitati in procesul de dezvoltare software. 2. Modele ale procesului de dezvoltare software.3. Modelarea sistemelor informatice: U(nified) M(odeling) L(anguage).4. Testarea programelor.5. Sabloane de proiectare OOP (Design Patterns)

Bibliografie1. Ian Sommerville SOFTWARE ENGINEERING2. Cursuri (cs.pub.ro, info.uaic.ro, etc).3. Tutoriale Internet.

Evaluare1.Tema de casa (2p)- documentatie software engineering pentru proiectul de diploma2. Tema intermediara (2p)2. Activitatea la laborator (2p)3. Examinare scrisa (4p)

Software Engineering??

Anii 1970 Criza software Metodele de dezvoltare existente inadecvate dezv. de programe mari.Efortul creste mai mult decat liniar in comparatie cu dimensiunea programului. Componentele hardware nu mai reprezinta factorul cel mai important. Un program nu este o entitate statica, ci el evolueaza in timp datorita schimbarii cerintelor si a mediului de utilizare. Trebuie sa poata fi usor de inteles si de adaptat de persoane diferite de cele care l-au dezvoltat. Dezvoltarea de software devine o industrie de sine statatoare

A devenit necesara o disciplina care sa furnizeze cadrul pentru construirea de software: Software EngineeringScopul: definirea de tehnici de fabricatie justificate de teorie sau de practica.

Software-ul se deosebeste de alte produse fabricate: - nu este un produs fizic este dezvoltat, nu fabricat; nu exista un proces de fabricatie software programele nu pot fi asamblate din componente nu imbatraneste

Software = cod sursa, cod executabil, biblioteci + documentatii (de realizare, de instalare, de utilizare)

Standardul IEEE 1993: Software Engineering este: Aplicarea unei abordari sistematice, disciplinate si masurabile in dezvoltarea, operarea si intretinerea software-ului, adica aplicarea ingineriei pentru software. De asemenea, studiul unor asemenea abordari.

Principalele activitati ale unui proiect software

Activitati tehnice:Definirea Cerintelor UtilizatorDefinirea Cerintelor SoftwareProiectarea arhitecturala Proiectarea detaliataImplementarea unitatilor program ( modulelor)IntegrareaTestarea de sistemTestarea de acceptare Intretinerea si operareaActivitati de asigurare a calitatiiActivitati de management al proiectului

Principalele activitati ale unui proiect software

Activitati tehnice:Definirea Cerintelor (Software Requirements)Definirea Cerintelor UtilizatorDefinirea Cerintelor SoftwareProiectarea (Software Design)Proiectarea arhitecturala Proiectarea detaliataImplementarea (Software Implementation)Implementarea unitatilor program ( modulelor)IntegrareaTestarea (Software Testing)Testarea de sistemTestarea de acceptare Intretinerea si operarea (Software Maintenance)

Activitati de asigurare a calitatiiActivitati de management al proiectului

Definirea cerintelor utilizator Aceste cerinte descriu punctul de vedere al utilizatorului: CE doreste viitorul utilizator de la viitorul produs. Sunt cerinte privind functionare a sistemului, de performanta, de securitate, de interfata utilizator, de interfata, etc. Cerintele sunt definite cat mai clar intr-un document: Documentul Cerintelor Utilizator (URD - User Requirements Document) sau Documentul Cerintelor de SistemActivitatea de definire a cerintelor utilizator poate include si specificarea testelor de acceptare.

Definirea cerintelor software Analiza cerintelor utilizator si definirea unui set de cerinte pe care viitorul produs software trebuie sa le indeplineasca astfel incat sa fie satisfacute cerintele utilizatorilor. Cerintele sunt descrise in cadrul unui document numit Documentul de Cerinte Software (SRD Software Requirements Document) sau Specificatia de sistem. Specificatia cerintelor software este independenta de implementareSRD sta la baza contractului dintre client si producator/ echipa de dezvoltareFurnizeaza o baza pentru estimarea costurilor si a planificarii

Definirea cerintelor software (cont.)Realizata (de regula !) de un analist de sistem (inginer de cerinte)Partea cea mai importanta (destul de complicata): relatia intre client si echipa de dezvoltareObiectivul: stabilirea unor cerinte precise !Multe programe nu se potrivesc cu ce vrea clientul din cauza unor cerinte gresite/insuficiente

Definirea cerintelor software (cont.)Cerinta software: ce si cum trebuie sa faca programul Cerinte functionale:Ce functionalitati trebuie sa aibe sistemulInteractiuni intre sistem si mediul in care evolueaza sistemulIndependente de tehnologii, metodologii, (etc.) de dezvoltareCerinte non-functionaleImpun diverse constrangeri (limitarea variantelor de constructie)Consideratii privind platformele de dezvoltare, tehnologii, metodologii, etc.

Caracteristici: corectitudinea, consistenta, completitudinea, realism, verificabilitatea, sa descrie exact ce vrea clientul, etc.

Definirea cerintelor software (cont.)Asa nu:Exemplu de cerinta vaga: sistemul trebuie sa fie prietenosExemplu de cerinta contradictorie: sistemul poate fi utilizat de maxim zece utilizatori la un moment dar, dar n anumite situaii pot exista douzeci de utilizatori conectaiExemplu de cerinta nerealista: toate datele se scriu pe disc iar timpul de rspuns trebuie s fie mai mic de o secund

Definirea cerintelor software (cont.) Factori de risc:1. cerine incomplete (13.1%)2. lipsa implicrii utilizatorilor (12.4%)3. lipsa resurselor (10.6%)4. ateptri nerealiste (9.9%)5. lipsa suportului executivului (9.3%)6. schimbarea cerinelor i a specificaiilor (8.7%)7. lipsa planificrii (8.1%)8. sistemele nu au mai fost cerute n ntregime (7.5%)

Definirea cerintelor software (cont.) Exist mai multe posibiliti de scriere a unui document de specificare a cerinelor. O structura posibil (conf. stand. IEEE Std. 830-1993) este prezentat mai jos:

Proiectarea arhitecturala Se stabileste arhitectura sistemului software care va implementa Cerintele formulate in documentul de Cerinte Software Se alege solutia de proiectare optima dintre alternativele posibile.Toate Cerintele Software trebuie sa fie acoperite de sistemul descris in Documentul de Proiectare Arhitecturala (ADD Architectural Design Document).Activitatea de proiectare arhitecturala poate include si specificarea testelor de integrare

Proiectarea de detaliuSubsistemele sunt descompuse succesiv pana se ajunge la nivel de componente direct implementabile prin unitati de program (care nu mai sunt descompuse). Se specifica functia/ functiile pe care trebuie sa le realizeze fiecare componenta, in Documentul de Proiectare de Detaliu (DDD Detalied Design Document). De asemenea, se pot defini testele unitare

Implementarea modulelor

Implementarea cuprinde codificarea si testarea separata a modulelor definite in etapa de proiectare de detaliu. Cea mai bine stapanita si cea mai bine utilata dintre toate activitatile ciclului de viata. Reprezinta circa 15-20% din efortul total de dezvoltare a unui program.

Specificarea si proiectarea reprezinta in jur de 40% (Requirements + Design)Testarea circa 40% din efortul total de dezvoltare (Testing)

IntegrareaModulele care au fost testate independent sunt integrate treptat in subsisteme, pana la nivel de sistem.Se verifica comunicarea si interactiunea intre componentele integrate (Integration testing)

Testarea de sistemSe verifica daca sistemul satisface cerintele specificate in documentul Cerintelor Software

Testarea de acceptareSe verifica daca sistemul satisface cerintele specificate in documentul Cerintelor UtilizatorSe efectueaza de o echipa de testare independenta care include si clientul/utilizatoriTestare alfa/beta

Intretinerea si operarea

Este efectuata de (alta) echipa de dezvoltare / clientActivitatile depind de tipul de softwarecorectarea defectelor, imbunatatirea unor caracteristici, adaptarea la cerinte noi

Asigurarea calitatiiScop: asigurarea cerintelor tehnice si a standardelor de calitate in procesul de dezvoltare si de catre produsul finalAlegerea metodelor si a standardelor de specificare, proiectare si implementareRevizii, pe tot parcursul procesului de dezvoltareDefinirea strategiilor de testareDefinirea metodelor de documentareDefinirea metricilor de evaluare a produselor si a instrumentelor de masurare

Activitati de management

Scrierea propunerii pentru obtinerea proiectuluiEtapizarea si planificarea in timp a activitatilorReviziiSelectia si evaluarea personaluluiScrierea si prezentarea de rapoarte

Riscurile unui proiect software

Sunt patru grupe de riscuri pentru un proiect software:

factori de experienta:experienta si calificarea managerului de proiectexperienta si calificarea echipeimaturitatea organizatiei care realizeaza proiectul: dezvoltarea de sisteme similare, utilizarea de standarde de Softw Eng., certificat de calitate ISO 9000

factori de planificare: estimarea incorecta a resurselor umane necesare in fiecare etapa a proiectuluiestimarea incorecta a perioadelor de timp necesare pentru diferite activitati, inclusiv pentru livrarea produsuluidefinirea responsabilitatilor

factori tehnologici: noutatea tehnologicaalegerea metodelor de dezvoltare (noi, nepotrivite)alegerea instrumentelor de dezvoltare (noi pentru echipa, ineficiente)

factori externi:calitatea specificarii si stabilitatea cerintelor utilizatorcalitatea definirii si stabilitatea interfetelor externecalitatea si disponibilitatea sistemelor externe

Ciclul de viata al unui program (Software life cycle)

O secventa de etape in existenta produsului softwareinclude toate activitatile necesare pentru dezvoltarea produsului si relatiile temporale dintre ele.Fiecare etapa din ciclul de viata este caracterizata prin activitati specifice si produsele rezultate din activitatile respective.Obs: include si intretinerea reluare activitati de dezvoltare

Modele ale ciclului de viata software => metodologii de dezvoltare software(Software development life cycle models / process models):

Modelul cascada (Waterfall model)Modelul in V ( Vmodel)Modelul ESA ( European Space Agency)Modelul incrementalDezvoltarea agila(Agile development)Dezvoltarea pe baza de prototip (Prototyping )Modelul in spirala (Spiral model)

MODELUL IN CASCADA (WATERFALL)Avantaje:Sistemul este bine documentatPermite un bun management al proiectului:planificarea resurselor umane pe etapeestimari de cost mai exacteDezavantaje:Un produs executabil, care sa demonstreze functionarea sistemului este disponibil destul de tarziu, dupa integrare. Pana atunci s-au produs numai documente !!Deoarece modelul este secvential, exista numai uhn feedback local, la tranzitiile intre faze.Multe erori sunt descoperite tarziu cost crescutToate riscurile sunt incluse intr-un singur ciclu de dezvoltare

Adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput si nu se modifica pe parcursul procesului de dezvoltare.Experienta ultimelor decenii a demonstrat ca modelul este valoros.Este utilizat in prezent de multe organizatii mari.

MODELUL IN CASCADA (WATERFALL)Limitarile modeluluiDetectarea erorilor se face destul de tarziu:in sau dupa faza de integrare = > la testarea concreta a programuluiAr fi potrivit in cazul in care:cerintele sunt bine intelese solutia usor de proiectatexista putin necunoscutIn realitate:neintelegerea cerintelor de cttre client sau analist;instabilitatea cerintelor;legeri tehnologice eronate; schimbri de personal.

Necesita reveniri la etapele anterioare => reflectarea realitatiiDaca sunt ocazionale => modelul este pertinentAltfel => modelul nu corespunde realitatii

Modelul INCREMENTAL

Modelul INCREMENTALModelul ciclului de via INCREMENTAL" este opus modelului IN CASCADA.

Se bazeaz pe o idee foarte simpl: dac un sistem este prea complex pentru a fi neles, conceput sau realizat intr-o singura iteratie este mai bine sa fie realizat n mai multe iteratii, prin evoluie.

Obs: un produs tipic consta din 10-50 iteratii

MODELUL INCREMENTALAvantaje:In fiecare etapa este livrat un produs executabil (satisface o parte din cerintele utilizator). Opus modelului cascada in care se elaboreaza documente

Prototipurile sunt livrate clientului/utilizatorilor

Feedback-ul utilizatorului este distribuit pe tot parcursul dezvoltarii => isi poate defini mai bine cerintele;

In cazul aparitiei unor schimbari in cerinte acestea pot fi incoporate in urmatorul prototip

Utilizatorul devine partener al proiectului

Dezavantaje:Erorile de proiectare sunt mai greu de eliminatEfectul unei modificari locale se poate propaga in ansamblul aplicatiei. Fiecare nou increment poate necesita reorganizarea structurii interne, degradand arhitectura initiala a programului, facandu-l greu de verificat si de intretinut Clientul poate poate cere mai mult ! Abordarea incrementala se poate transforma usor intr-una codifica si repara (build and fix)

MODELUL Agile[wikipedia]

MODELUL Agile

Cadru conceptual de dezvoltare software; defineste mai multe metode: Scrum, XP, etc.Model bazat pe modelul iterativ => fiecare iteratie este un proiect in miniatura => un nou produsSe lucreaza pe sloturi mici de timp (timebox -uri) => managementul risculuiComunicare directa intre participanti (dezvoltatori, testeri, proiectanti, manageri) => fara documentatiePrincipala masura a progresului => software functionalDezavantajul: foarte putina documentatie !Tema: citeste despre Scrum si XP

Definire Cerinte folosind Prototip

****************************