+ All Categories
Home > Documents > 1 Fundamente

1 Fundamente

Date post: 21-Dec-2015
Category:
Upload: daniel-sere
View: 290 times
Download: 4 times
Share this document with a friend
Description:
ingineria programarii
67
Ingineria programării Ingineria programării Curs Curs - - 28 ore 28 ore Aplica Aplica ț ț ii ii 28 ore 28 ore Mihaela Vida Mihaela Vida Norbert Norbert Gal Gal IP IP - - Vasile Vasile Stoicu Stoicu - - Tivadar Tivadar
Transcript
Page 1: 1 Fundamente

Ingineria programăriiIngineria programării

Curs Curs -- 28 ore28 oreAplicaAplicațțiiii –– 28 ore28 ore

Mihaela VidaMihaela Vida

NorbertNorbert GalGal

IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

Page 2: 1 Fundamente

22 / / 5353

�� ÎÎnsunsuşşireairea principalelorprincipalelor concepteconcepte care care opereazăoperează îînn cadrulcadrulactivităactivităŃŃiiii de de proiectareproiectare software, software, respectivrespectiv îînsunsuşşireaireacunocunoşştintinŃŃelorelor şşii deprinderilordeprinderilor practice practice necesarenecesare lucruluilucrului

îîntrntr--oo echipăechipă de de proiectareproiectare software. software.

�� DobândireaDobândirea unorunor cunocunoşştintinŃŃee pentrupentru abordareaabordarea cu cu successucces

a a proiectelorproiectelor software software complexecomplexe cu cu exempleexemple din din domeniuldomeniul sistemelorsistemelorindustrialeindustriale//îîncorporatencorporate..

ObiectiveObiective

IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

Page 3: 1 Fundamente

33 / / 5353

IMPORTANłA CURSULUICURSUL – de importanŃă crucială pentru cei care vor lucra în organizaŃii de dezvoltare software

subliniată de directori şi şefi de divizii sau departamente de la toŃi angajatorii importanŃi de profil din Timişoara (CONTINENTAL, HELLA, OCE, SAGUARO, VISMA, etc.) la toate întâlnirile cu mediul academic (mergeŃi şi vizitaŃi companiile şi convingeŃi-vă, dar nu ca şi simpli angajaŃi într-un post cu atribuŃii limitate – codificare sau testare, ci cu gândul la evoluŃia profesională ulterioară; întrebaŃi de la colegii mai mari, care lucrează de câŃiva ani şi veŃi vedea că aşa e !)

Cine nu doreşte să rămână toată viaŃa simplu programatorsimplu programator, trebuie să ştie Ingineria ProgramăriiIngineria Programării ! Nu poŃi conduce proiecte dacă nu ai cunoştinŃe serioase din acest domeniu.

AngajaŃii, după câŃiva ani de practică, ne povestescpovestesc despre ce bine e că au învăŃat la Ingineria Programării !

Page 4: 1 Fundamente

44 / / 5353

�� Test grilă Test grilă ((îîntrebări din ntrebări din conconțținutulinutul cursului)+ test grcursului)+ test grilă ilă ““problematizatproblematizat””((îîntrebări referitoare la proiectul ce rezultă ntrebări referitoare la proiectul ce rezultă din din descrieredescrierea unei a unei aplicaaplicațțiiii))

�� NotaNota::�� INT (0,66 *nota test+0,34 * nota INT (0,66 *nota test+0,34 * nota aplicaaplicațțieie+0,5)+0,5)

Examinare finalăExaminare finală

IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

Page 5: 1 Fundamente

55 / / 5353

�� FundamenteFundamente.. Ciclul de Ciclul de viaviațțăă al programelor, al programelor, diverse modelediverse modele

�� ComplementeComplemente ((modelemodele de de proiectareproiectare, , modelemodele de de arhitecturiarhitecturi).).

�� AnalizaAnaliza softwaresoftware�� Proiectarea softwareProiectarea software�� Testarea Testarea softwaresoftware�� Gestiunea Gestiunea configuraconfigurațțiiloriilor�� Sisteme informatice Sisteme informatice pentru conducere de procespentru conducere de proces�� SiguranSiguranțțaa îîn n funcfuncțționareionare�� UML UML îîn timp real. n timp real. ȘȘabloaneabloane de proiectarede proiectare

ConConțținutulinutul cursuluicursului

IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

Page 6: 1 Fundamente

66 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

ObiectiveleObiectivelepentrupentru capitolulcapitolul I I -- FundamenteFundamente

ObiectiveleObiectivele șși i principiileprincipiileinginerieiingineriei software. software. CiclulCiclulde viade viațțăă. .

•Câțiva termeni•Misiunea inginerilor software

•Abordări specifice

•Obiective

•Principii

•Produse pentru dezvoltare software, procese

si resurse

•Modele ale procesului de dezvoltare

software

•Standarde

Page 7: 1 Fundamente

77 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

CCââțțivaiva termenitermeniSistemeSisteme de de conducereconducere cu cu calculatorulcalculatorul a a

proceselorproceselor ((tehnologicetehnologice) ) ((computerscomputers in in (industrial) process control)(industrial) process control)

Proceduri de Proceduri de operareoperare

ProcesProces

EchipamentEchipament

InterfeInterfețțeede de procesproces

SoftwareSoftware

Operator Operator umanuman

Sistem de calcul utilizat pentru conducerea unorpărŃi sau în totalitate unor p ărŃi sau în totalitate a unui proces în sens larg (sau numai procestehnologic) cu scopul realiz ării şi men Ńinerii unorperforman Ńe tehnice şi economice şi care prezint ă anumite cerin Ńe specifice obligatorii(răspuns rapid, siguran Ńă în func Ńionare).

Page 8: 1 Fundamente

88 / / 5353IPIP-- Vasile Vasile StoicuStoicu--TivadarTivadar

Sisteme Sisteme îîn timp realn timp real

Def.: un sistem on-line (legat de proces) caracterizat printr-o valoare prescris ă a timpului de r ăspuns (de cele mai multe ori de ordinul secundelor sau frac Ńiuni de secund ă) fiind capabil s ă urmărească şi să răspund ă în timp util la solicit ările din exterior.

Este vorba de acele sisteme la care o abatere de la limita maxim ă a timpului de r ăspuns s ă însemne incidente grave în mediul controlat.

CCââțțivaiva termenitermeni

Page 9: 1 Fundamente

99 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

Stil de programareStil de programare modul de aplicare a tehnicilor de programare, mod de documentare a programului, de a şezare în pagin ă a textului surs ă, în general totalitatea atributelor care confer ă unui program o anumit ă personalitate urm ărind realizarea unor anumite performan Ńe.

CCââțțivaiva termenitermeni

Page 10: 1 Fundamente

1010 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

Demn de Demn de atenatențțieie !!

Programarea nu este o artă ci o activitate inginereasc ă preten Ńioasă:

•nu poate fi realizat ă decât în echip ă•programele ob Ńinute trebuie s ă fie user-friendly şi nu pentru speciali şti•trebuie s ă poat ă fi în Ńelese si modificate de către alte persoane decât proiectan ții

Page 11: 1 Fundamente

1111 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

Ingineria programăriiIngineria programării

((Software Software EngineeringEngineering))

Domeniu al informaticii ce se ocup ă cu determinarea celor mai adecvate solu Ńii, procedee şi instrumente care s ă conduc ă în condi Ńii optime la elaborarea unui produs program astfel ca acesta s ă satisfac ă toate cerin Ńele impuse de specifica Ńiile de definire.

Proiectarea și dezvoltarea aplicațiilor software

CCââțțivaiva termenitermeni

Page 12: 1 Fundamente

1212 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

CE ESTE de fapt Ingineria ProgramăriiCE ESTE de fapt Ingineria Programării? ?

Ca Ca șșii Inginer SoftwareInginer Software, , ne folosim ne folosim cunocunoșștintințțeleele despre calculatoare, prelucrarea despre calculatoare, prelucrarea informainformațțiiloriilor șșii altele pentru a ajuta la altele pentru a ajuta la rezolvarea problemelorrezolvarea problemelor..

Câteodat ă problema e din domeniul calculatoarelor dar de multe ori e din alte domenii – este esn țial să înșelegem întâi natura problemei, apoi vom folosi tehnologia ca o unealt ă pentru a implementa solu ția.

Page 13: 1 Fundamente

1313 / / 5353IPIP-- Vasile Vasile StoicuStoicu--TivadarTivadar

Rezolvarea problemelor Rezolvarea problemelor (anal(analizăiză))

Problemele sunt mari Problemele sunt mari --> > trebuie să trebuie să îîncepem prin a ncepem prin a investiga, prin investiga, prin analanalizăiză,,adică prin adică prin îîmpărmpărțțireaireaproblemei problemei îîn n bucăbucățții pe care pe care le putem le putem îînnțțelegeelege șșii trata.trata.

Important: rela țiile sunt la fel de esen țiale ca șisubproblemele în șile

.

Page 14: 1 Fundamente

1414 / / 5353

După ce am analizat problemaDupă ce am analizat problema, , trebuie să construim trebuie să construim solusoluțțiaia din componente care rezolvă din componente care rezolvă aspecte diferite ale aspecte diferite ale problemei problemei --> >

SintezăSinteză-- pupunemnem îîmpreună mpreună o o structurpstructurp mare din blocuri mare din blocuri constructive mai miciconstructive mai mici

Important: Compunerea unor solu ții individuale poate să fie la fel de provocatoare ca și găsirea solu ției înse și.

(a se vedea scrierea unui roman: dic ționarul cuprinde toate cuvintele care vor fi folosite în roman, dar partea dificilă a

scrisului const ă în a decide cum s ă fie compus ă și organizată cartea întreag ă)

Rezolvarea problemelor Rezolvarea problemelor ((sintezăsinteză))

Page 15: 1 Fundamente

1515 / / 5353

DE CE calitatea produselor DE CE calitatea produselor software este importantă software este importantă ??

Sunt utilizatorii mulțumiți cu calitatea produselor software

DADA șșii NUNU

Cum era înainte de a exista procesoarele de text, po șta electronică, , INTERNET etc. ?

Deseori sistemele nu func ționează așa cum am dori și ne-am a ștepta:

codul con ține erori dar este suficient de bun pentru a demostra viabilitatea unei abord ări

Exemple punctuale pentru lipsa calit ății:

1. United States’ Internal Revenue Service – sistemul federal de calcul al taxelor “un fiasco de 4 miliar de” din cauza proastei planific ări

2. Un sistem SDI (Initiavtiav de Aparare Strategica –Razboiul Stelelor) ar necesita cel pu țin 10 miloanelinii de cod (unii estimează chiar 00 mil.) -> testarea unui asemenea volum de cod este aproape imposibilă

3. Software-ul pentru Therac 25 X-ray machine - > utilizarea neașteptată , neobișnuită a tastelor săgeți -> a omorât câțiva pacienți

Creșterea nepermis ă a costurilor

Probleme de testare

Pericolîn

utilizareExist ă câteva tehnici de a cre ște calitatea software (testare cu date de test, revizia colegial ă -peer review etc.)

Page 16: 1 Fundamente

1616 / / 5353IPIP-- Vasile Vasile StoicuStoicu--TivadarTivadar

CE este un software BUN?CE este un software BUN?Contextul determinăContextul determină

răspunsulrăspunsul

•Erori tolerate la

procesoarele de text pot

să nu fie acceptabile în

sisteme safety-critical

Calitatea produsului

Calitatea procesului care conduce la produs

Calitatea produsului în contextul mediului (ca afacere-business) în care produsul va fi utilizat

Următorul

Page 17: 1 Fundamente

1717 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

Calitatea produsului software Calitatea produsului software

Înapoi

• Software-ul poate fi evaluat de utilizarori de exemplu dup ă numărul și tipul căderilor (minore, majore, catastrofice), dac ă realizeaz ă ce doresc, dac ă este ușor de înv ățat, ușor de folosit etc.

•Software-ul poate fi evaluat de asemenea de c ătre proiectan ți(caracteristicii interne: num ărul șitipul erorilor ca și măsur ă a calit ățiiprodusului)

Model care leagă perspectiva proiectantului (perspectiva intern ă) de cea a utilizatorului (perspectiva extern ă)

Modelul de calitate al lui McCall

Page 18: 1 Fundamente

1818 / / 5353

Calitatea procesului softwareCalitatea procesului softwareMulte activități afectează calitatea produsului.

E demn de atenție răspunsul la întrebări precum:

•Unde și când găsim mai degrabă un anume tip de erori ?

•Cum să găsim erorile, cât mai degreme în cadrul procesului de dezvoltare software ?

•Cum să realizăm sisteme tolerante la defectare astfel încât să minimizăm posibilitatea ca o eroare să devină o cădere ?

•Există posibilități alternative care să ducă la un proces mai eficient în asigurarea calității ?

Putem îmbunătăți calitatea unui produs prin utilizarea unor metodologii și standarde de calitate precum Capability Maturity Model (CMM) sau varianta mai modernă CMM Integrated(CMMI), ISO 9000 și variantele sale adaptate la neceesitățile dezvoltării software , SoftwareProcess Improvement and dEtermination (SPICE)

Înapoi

Page 19: 1 Fundamente

1919 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

Calitatea produsului Calitatea produsului îîn contextul afaceriin contextul afacerii

Calitatea este privită din punctul de vedere al produselor șiserviciilor furnizate de “afacerea” în care software-ul este înglobat

Înapoi

Returnarea investi ției (RI)

Return on investment (ROI)

Efort

(companiile suintinteresate în a economisi timp sau a în utiliza cât mai pu țin personal):

instruire productivitate

programare proces

risc clien ți

calitate costuri

“afacere” (rentabilitate)

RI include aspecte precum:

Page 20: 1 Fundamente

2020 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

Cine practică Cine practică Ingineria Programării Ingineria Programării ??Un element cheie al dezvoltării software este comunicarea dintreUn element cheie al dezvoltării software este comunicarea dintre client client șșii dezvoltatordezvoltator..

Participan ții în procesul de dezvoltare software

Situa ții:

- clientul nu este utilizator

- utilizatorul , clientul șidezvoltatorul sunt acea și entitate

- clientul poate decide să achizi ționeze software comercial ( commercial off-the-shelf software -COTS ) pentru a fi încorporat în produsul final

- utilizarea unor dezvoltatorisuplimentari (subcontractori) care vor elabora subsisteme

- ca și solu ții “la cheie”

- pot s ă necesite un proces separat de integrare

Page 21: 1 Fundamente

2121 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

ABORDAREA SISTEMICĂABORDAREA SISTEMICĂOftenOften, , thethe hardware hardware andand software software wewe put put toghethertoghether must must interactinteract withwithusersusers, , withwith otherother software software taskstasks, , withwith otherother piecespieces ooff hardware, hardware, withwithexistingexisting databasesdatabases, , withwith otherother computer computer systemssystems --> > withwith thetheboundariesboundaries of of thethe projectproject..

WhereWhere doesdoes thethe projectproject beginbeginandand endend ? ? TheThe same same questionquestion --> > appliesapplies toto anyany systemsystem

A A systemsystem - a collection of objects and activitiesplus a description of the relationships that tie theobjectives and activities together. Typically: for eachactivity, a list of inputs required, actions taken, outputs produced.

Any collection of component elementsthat work together to perform a task. Examples are a hardware systemconsisting of a microprocessor, its alliedchips and circuitry, input and output devices, and peripheral devices; an operating system consisting of a set of programs and data files; or a databasemanagement system used to processspecific kinds of information

Example: a program for printing paychecks for the empl oyees; we must know whether the program simply reads hours worked from ano ther systemand calculate the results or also calculate taxes, pens ions etc.

Page 22: 1 Fundamente

2222 / / 5353IPIP-- Vasile Vasile StoicuStoicu--TivadarTivadar

ELEMENTELE UNUI SISTEMELEMENTELE UNUI SISTEM

Descriem un sistem enumerDescriem un sistem enumerândând părpărțțileile sale sale șșii identificând modul identificând modul îîn care se n care se manifestă manifestă relarelațțiileiile dintre componente. Acesta este primul pas dintre componente. Acesta este primul pas îîn analiza unei n analiza unei probleme.probleme.

Elemente:Elemente:

Activit ăActivit ățții șșii obiecteobiecteactivitate activitate – ceva ce ce întâmplă în sistem(de regulă descris ca un eveniment inițiat de un trigger – transformă ceva în altceva schmibându-i caracteristicile – prin translatare, schimbare, combinare etc. )obiect sau entitate obiect sau entitate – elementele implicate în activități – uzual relaționate cumva (tabele, matrici, înregistrări etc. sau văzute independent, având asociată o listă de caracteristici – ex. Abordarea Orientată pe Obiecte)

RelaRelațțiiii șșii marginile sistemului marginile sistemului -unele elemente traversează marginile pentru a intra în sistem, altele sunt produse ale sistemului și îl părăsesc pentru a fi utilizate de alt sistem etc.

intr ări

ieșiri

Page 23: 1 Fundamente

2323 / / 5353

Putem pune în eviden țăpărțile componente ale

Sistemului Sistemului Respirator:Respirator:

••marginimargini

••entit ăentit ățții

••activit ăactivit ățții

șșii pentru un sistem pentru salariipentru un sistem pentru salarii

ELEMENTELE UNUI SISTEM ELEMENTELE UNUI SISTEM -- EXEMPLEEXEMPLE

Page 24: 1 Fundamente

2424 / / 5353

ABORDAREA INGINEREASCĂABORDAREA INGINEREASCĂÎÎndată ce am ndată ce am îînnțțeleseles natura unui sistem natura unui sistem, p, putem să utem să îîl construim. Aici, partea l construim. Aici, partea ““inginereascinginereascăă”” a a inginerieiingineriei programprogramăriiării devine mai importantă devine mai importantă..

Proiectele software avanseaz ă Proiectele software avanseaz ă îîntrntr --un mod similar cu un mod similar cu procesulprocesul de de construireconstruire a unei a unei casecase ::

aanalizanaliza șșii definirea definirea cerincerin țțelorelor

proiectarea sistemului proiectarea sistemului (descrie doar (descrie doar aparenaparențțeleele –– poate fi revizuit de client)poate fi revizuit de client)

proiectarea programuluiproiectarea programului

implementarea programului (scrierea programului)implementarea programului (scrierea programului)

testele de modultestele de modul

testele de integraretestele de integrare

testele de sistemtestele de sistem

livrarea sistemului livrarea sistemului

îîntrentre țținereainerea

ÎÎn realitate, n realitate, mulmul țții din din aceaceșștiti papașșii se repetă se repetă (de (de exemplu, revizuexemplu, revizuind proiectarea sistemului, ind proiectarea sistemului, pot să apară noi pot să apară noi cerincerințțee).).

Definim un proces de dezvoltare software ca orice d escriere a deDefinim un proces de dezvoltare software ca orice d escriere a de zvolt ării software care zvolt ării software care concon țțineine unele din unele din activit ăactivit ățțileile de mai sus, organizate astfel de mai sus, organizate astfel îîncât ncât îîmpreun ă să produc ă mpreun ă să produc ă cod testat. cod testat.

Page 25: 1 Fundamente

2525 / / 5353

MEMBRII ECHIPEI DE DEZVOLTARE MEMBRII ECHIPEI DE DEZVOLTARE SOFTWARESOFTWARE

DezvoltatoriiDezvoltatorii unei unei aplicaaplicațțiiii software sunt ingineri software (sau informaticieni) software sunt ingineri software (sau informaticieni) dar fiecare poate fi specializat dar fiecare poate fi specializat îîn unele din aspectele particulare ale dezvoltăriin unele din aspectele particulare ale dezvoltării, , conform conform papașșilorilor din procesul de dezvoltare software:din procesul de dezvoltare software:

analianali șștiti (de (de cerincerin țțee) ) –– generează o generează o descriere la nivel descriere la nivel sistem sistem îîmpreună cu mpreună cu proiectanproiectanțțiiii

proiecanproiecan țții -- descriu descriu sistemul astfel sistemul astfel îîncât ncât programatorii să programatorii să poată scrie linii de poată scrie linii de cod care să cod care să implementeze implementeze cerincerințțeleele

programatoriprogramatori

testoritestori

instructori instructori –– pentru pentru clientclient

echipa de echipa de îîntrentre țținereinere

bibliotecari bibliotecari (pentru întreținerea bibliotecile de module de program)

echipa de gestiune a echipa de gestiune a configuraconfigura țțiiloriilor implicată în întreținereaunei corespondențe între cerințe, prioiectare, implementare șitestare

Page 26: 1 Fundamente

2626 / / 5353IP IP -- Vasile Vasile StoicuStoicu--TivadarTivadar

Aspecte eticeAspecte eticeÎn activitatea de dezvoltare soft trebuie urm ărite şi aspectele

etice şi sociale ale consecin Ńelor utiliz ării produselor proiectate. De aceea, în activitatea de proiectare trebuie s ă dea de gândit urm ătoareleaspecte:

a) înlocuirea rezolv ării de probleme ale clien ților prin alteprobleme (adic ă le creăm acestora noi probleme)

Ex: cuplu pervers: masina de tuns iarba, bicicleta ergo nomic ă.

Un reprezentant al clasei de mijloc î și cumpără mașină de tuns iarba (scump ă) pentru a între ține gazonul; deoarece folosind această mașină nu depune efortt, este sedentar deoarece î și risipe ște unica posibilitate de a depune efort, neavând tim p în afar ă de tunsul ierbii și își cumpără în consecin ță și o bicicletă ergonomică (scump ă) pentru a- și men ține sănătatea, în loc s ă își cumpere o coasă (ieftin ă) pentru a rezolva ambele probleme.

b. să nu cre ăm false necesit ăți (exemplu: aparat videoprogramabil cu prea multe și prea complicate posibilit ăți care nu vor fi

aproape niciodat ă exploatate );c) din punct de vedere strategic s ă orientam corect resursele

disponibile;d) să nu se uite nici un moment c ă produsul este realizat pentru a

fi utilizat de oameni.

Page 27: 1 Fundamente

2727 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

INGINERIA SOFTWAREINGINERIA SOFTWARE, , obiectiveobiective sisi

principiiprincipii

Producerea si intretinerea aplicatiilor software, in sp ecial cea a sistemelor in timpreal, reprezinta un efort important din punct de veder e:

�tehnic�al managementului�financiar

Sunt foarte multe cereinte antagonisce spre rezolvare. Ac esta este un motivpentru care s-a nascut ingineriaingineria software (software ( incainca din 1968 din 1968 -- la la conferintaconferinta NATO)NATO)IngineriaIngineria softwaresoftware intentioneaza sa:• stabileasca ciclul de viata al programleor si continutul etapelor acestora• elaboreze metode potrivite si tehnici pentru usurarea proi ectarii soft conform unor diferite cicluri de viata• elaboreze metode pentru activitatile de concepere si admi nistrare

IngineriaIngineria software software intentioneaza sa treaca de la arta programarii la o activitate sistematica care poate permite performante si gure.

IngineriaIngineria softwaresoftware presupune folosirea in mod sistematic a unelte lorsoftware, in conformitate cu principiile si obiectivele de baza.

Page 28: 1 Fundamente

2828 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

OBIECTIVE ALE INGINERIEI SOFTWAREOBIECTIVE ALE INGINERIEI SOFTWARE((uneleunele dintredintre eleele))

Obiectivele sunt deziderate pe care proiectanObiectivele sunt deziderate pe care proiectan țții software le ii software le au au îîn vedere tot timpul ciclului de vian vedere tot timpul ciclului de via țțăăal programeloral programelor : : FlexibilitateaFlexibilitatea – posibilitatea de adaptare (mai usoara)la noile cerinte. Motivele pentru noile cerinte :• schimbarile la nivel fizic• noile functii aparute• extensiiile (volumele de date )

Exemplul 1

Exemplul 2Implementarea prin:

•parametrizari

•Structuri de date potrivite,

•Tehnici speciale de programare,

•Scrierea codului pentrurefolosire etc.

Page 29: 1 Fundamente

2929 / / 5353

OBIECTIVE ALE INGINERIEI SOFTWARE OBIECTIVE ALE INGINERIEI SOFTWARE ((continuarecontinuare 1)1)EficientaEficienta – este un indice calitativ cu doua intelesuri :• ca performanta a softului insusi (eficienta ca viteza de calcul,

memorie ocupata, etc.) – asociata cu calitatea software• ca si cost de producere (productivitate) – asociata cu p unctul de vedereal afacerilor (presiunea pietei)Producatorii trebuie sa obtina un soft mai bun (prin as igurarea unui standard de calitate) si cat mai rapid posibil (cereri antagonice) .Tehnicile ingineriei software ajuta la rezolvarea acestora.

FiabilitateaFiabilitatea – se refera la evitarea, gasirea si repararea greselil or cat de repedepermite procesul de proiectare, si restabilirea functi onarii corecte daca apar eroride functionare. Nu putem impune aceasta prin adaugarea, mai tarziu, de componente speciale pentru a creste siguranta;

- este foarte important pentru procesul de control soft ware

Exista cateva tehnici pentru a creste siguranta (redunda nta statica si dinamica, etc.).

Eficienta si siguranta sunt puternic influentate de catre tehnicile inginerieisoftware folosite. Statisticile arata ca 60% din erori apartin etapei de analiza sidoar 40% apar in conceperea propriu-zisa (adica de fapt nu s-a inteles bine cetrebuie facut)

Page 30: 1 Fundamente

3030 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

OBIECTIVE ALE INGINERIEI SOFTWARE OBIECTIVE ALE INGINERIEI SOFTWARE ((continuarecontinuare 2)2)

PerceptibilitateaPerceptibilitatea ((readabilityreadability ))- proprietate a programelor de a fi intelesede catre alti programatori, altii decat autorii (sau chia r de catre autori, la un timpdupa realizarea unor programe)

Acest atribut creste fiabilitatea dar si adaptabilitatea.

De asemenea, gestionarea unui proiect soft este posibil a doar dacainginerii soft din cadrul echipei de programare asigura o forma standard usoraccesibila a produsului lor.

O proiectare soft buna, care tine cont de toate aces te obiective, esteinfluentata puternic de catre metode, tehnici si unelte d escrise si impuse de catreinginerul soft.

Obiectivele pot fi atinse prin imprimarea in practica cur enta a principiiloringineriei soft.

Page 31: 1 Fundamente

3131 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

PRINCIPII ALE INGINERIEI SOFTPRINCIPII ALE INGINERIEI SOFT

1. . ModularitateaModularitatea - presupune dividereaprogramului in entitati diferite cu intrari si iesiribine delimitate, numite module program si structurarea programului in module pentru o mai usoara obtinere a unor obiective sigure.

Un modul este cu atat mai independent de hardware cu cat este mai sus in ierarhiamodulelor -> urmariti diferenta dintreobiective ale modulelor din ierarhie

Nivelsuperior

in ierarhie

Nivelscazut in ierarhie

Obiective(comenzi)

rapoarte

2. 2. AbstractizareaAbstractizarea -- identificare a proprietatiloresentiale ale unor entitati aparent diferite

Nivelstrategic

Niveltactic

Procesareacontrolata a semnalelorproceselorindustriale

Starea semnalelor Semnalizare avarie MasuratoriEste de altfel redataierarhic.

Page 32: 1 Fundamente

3232 / / 5353

PRINCIPII ALE INGINERIEI SOFTPRINCIPII ALE INGINERIEI SOFT

continuarecontinuare3. LocalizareaLocalizarea – punerea in vecinatatea fizica a elementelor cu unelelegaturi intre ele

Examplu: functiile unei biblioteci (calcule matematice, interfete grafice,etc.), functii langa structurile de date folosite, etc.

4. 4. AscundereaAscunderea – accentuarea elementelor esentiale si ascunderea detaliilorcare nu afecteaza alte componente ale sistemului

Exemplu: abordarea orientata pe obiecte - incapsulareaObservatie: diferenta dintre abstractizare si ascundere: amandoua

accentueaza aspecte esentiale dar ascunderea defineste restrictiile de acces.

5. UniformiUniformi tateatatea - asigura consistenta programelor, este specifica fiecar uiinginer in programare

Examplu: conventiile proprii ale fiecarui programator in notatii

6. 6. CompletitudineaCompletitudinea – asigura ca nici una din elementele esentiale nu suntomise.

Examplu: - notatiile trebuie sa exprime tot ce este necesar (referitor si la

uniformitate)

7. 7. ConfirmabilitateaConfirmabilitatea – informatiile cerute de catre procesul de testare sa

fie formulate explicit si de asemenea disponibile .Exemplu : necesitatea procedurilor de testare (ca document)

Page 33: 1 Fundamente

3333 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

INSEMNATATEA PROCESULUIINSEMNATATEA PROCESULUIAm Am vazutvazut dejadeja ca ca procesulprocesul de de proiectareproiectare are are cativacativa pasipasi..

O serie de sarcini cerute:O serie de pasi implicandactivitati, constrangeri, resurse care produc un produs dorit.

Orice proces are urmatoarele caracteristici :

•Descrie toate activitatile majore ale procesului

•Foloseste resurse, fiind supus unor serii de constrangeri si produce o serie de produseintrermediare si finale

•Pot fi formate din subprocese (fiecare are propriul model de proces)

•Fiecare activitate a procesului are criterii de intrare si iesire

•Activitatiile sunt organizate in secvente

•Fiecare proces are un set de principii de ghidare care explica obiectivele fiecarei activitati

•Constrangerile pot fi aplicate unei activitati, resurse sau produs (exemplu: bugetul sauprogramarile pot constrange timpul uneiactivitati)

Cand procesul implica creareaunui anume produs, ne referim la proces ca la un ciclu de viata. . Totusi, procesul de dezvoltare soft este numit ciclu de viata soft, deoarece descrie viata unui produssoft de la conceptie la implementare, livrare, folosire siintretinere.

Page 34: 1 Fundamente

3434 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELELEMODELELE PROCESULUIPROCESULUI SOFTSOFTMulte modele ale proceselor sunt descrise in literatura i ngineriei

soft. Construirea unui model si discutarea subprocesel or ajuta echipa sa distanta dintre ceea ce ar trebui sa fie si cee a ce este.

Motive pentru modelarea unui proces :

•Cand un grup scrie o descriere a procesului saude dezvoltare, formeaza o intelegere comuna a activitatilor, resurselor si constrangerilor

•Ajuta la gasirea discordantelor si a omisiunilor

•Modelul trebuie sa reflecte scopurile dezvoltarii(calitate ridicata, gasirea de erori, incadrarea in buget); pe masura ce aplicatia este finalizata, echipa evalueaza cerintele necesare pentru o apropiere de obiectivului propus

•Fiecare proces trebuie creat pentru situatiaspeciala in care va fi folosit; crearea unui model al procesului ajuta echipa de programatori sainteleaga unde este folosita aplicatia lor.

Fiecare proces de dezvoltare a modelului soft include cerintelesistemului ca intrare si livrareaprodusului ca iesire.

Multe asemenea modele au fostpropuse de-a lungul anilor.

Page 35: 1 Fundamente

3535 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL CASCADA (WATERFALL)MODELUL CASCADA (WATERFALL)

�� UnulUnul dindin primeleprimelemodelemodele

� Pasii sunt descrisiin cascada unuldupa altul

� Un stagiu de dezvoltare trebuieterminat inainte de-a incepe urmatorul

� Prezinta un nivelmare de vizualizarea ceea ce se intampla in timpuldezvoltarii

� Sugereazaprogramatorilorsecventaevenimentelor pecare ei ar trebui sa se astepte sa le intalneasca

Page 36: 1 Fundamente

3636 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL CASCADA (WATERFALL)MODELUL CASCADA (WATERFALL)

Programele trebuie proiectate, testate, implementate Programele trebuie proiectate, testate, implementate şşi exploatate. i exploatate. ÎÎn general se n general se consideră că fazele prin care trece un program suntconsideră că fazele prin care trece un program sunt::

�� Analiza cerinAnaliza cerinŃŃelorelor -- faza colaborării dintre beneficiar faza colaborării dintre beneficiar şşi echipa de elaborare i echipa de elaborare pentru a se stabili definipentru a se stabili definiŃŃia exactă a problemei ia exactă a problemei (cerin(cerinŃŃe e şşi restrici restricŃŃii) rezultând ii) rezultând îîn n general o temă de proiectaregeneral o temă de proiectare

�� Elaborarea specificaElaborarea specificaŃŃiiloriilor -- faza faza îîn care se elaborează un set de specifican care se elaborează un set de specificaŃŃii ii formale (descrieri abstracte) pentru programe cuprinzând o descformale (descrieri abstracte) pentru programe cuprinzând o descriere detaliată riere detaliată pentru toate entităpentru toate entităŃŃile funcile funcŃŃionale precum ionale precum şşi pentru toate restrici pentru toate restricŃŃiile.iile.

�� Proiectarea programelorProiectarea programelor -- se stabilese stabileşşte structura pe module, raporturile dintre te structura pe module, raporturile dintre ele, modul de comunicare, parametrii de intrareele, modul de comunicare, parametrii de intrare--ieieşşire, tipuri de date etc..ire, tipuri de date etc..

�� Implementarea programuluiImplementarea programului -- programarea conform celor stabilite la punctele programarea conform celor stabilite la punctele anterioare. Se foloseanterioare. Se foloseşşte un limbaj adecvat pe un calculator gazdă te un limbaj adecvat pe un calculator gazdă ((hosthostcomputercomputer))

�� Instalarea Instalarea şşi verificareai verificarea –– pe calculatorul pe calculatorul ŃŃintăintă, al beneficiarului, , al beneficiarului, îîn condin condiŃŃii de ii de exploatare exploatare

�� ÎÎntrentreŃŃinerea programuluiinerea programului -- asigură eliminarea erorilor ce se manifestă după asigură eliminarea erorilor ce se manifestă după pornirea aplicapornirea aplicaŃŃieiiei

Page 37: 1 Fundamente

3737 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL CASCADA (WATERFALL)MODELUL CASCADA (WATERFALL)

�� In In economiaeconomia uneiunei lucrlucrăăriri, , îînn cadrulcadrul primelorprimelor 3 3 etapeetape 40% 40% reprezintăreprezintă analizaanaliza, , elaborareaelaborarea specificareaspecificarea şşii proiectareaproiectarea, , 20% 20% implementareaimplementarea şşii 40% 40% testareatestarea..

�� Codificarea reprezintă de regulă Codificarea reprezintă de regulă îîntre 16ntre 16--20 %20 %

�� ÎÎntrentreŃŃinereainerea poatepoate ssă reprezinte până la ă reprezinte până la 60% d60% din costul total. in costul total. De aceea trebuie acordată o atenDe aceea trebuie acordată o atenŃŃie deosebită minimizării ie deosebită minimizării numărului de erori prinnumărului de erori prin: utilizarea unor metode de elaborare : utilizarea unor metode de elaborare şşi testare care să asigure un număr minim de erori i testare care să asigure un număr minim de erori şşi i structurarea programelor astfel structurarea programelor astfel îîncât acestea să permită ncât acestea să permită modificarea cât mai umodificarea cât mai uşşor.or.

Page 38: 1 Fundamente

3838 / / 5353

MODELUL CASCADA MODELUL CASCADA -- continuarecontinuare

�� PoatePoate fi fi foartefoarte folositorfolositor pentrupentru programatoriprogramatori in a in a produceproduce ceeaceea ce ce dorescdoresc

�� SimplitateaSimplitatea lui il face mai lui il face mai usorusor de de explicatexplicat clientilorclientilor

�� MulteMulte modelemodele complexe complexe suntsunt derivatederivate dindin modelulmodelulcascadacascada

�� ModelulModelul nu nu asiguraasigura ghidareaghidarea sefilorsefilor de de proiecteproiecte referitorreferitor la cum sa la cum sa facafaca fatafataschimbarilorschimbarilor si si activitatiloractivitatilor care care probabilprobabil vor vor apareaaparea neasteptatneasteptat in in timpultimpulimplementariiimplementarii (nu ne (nu ne pregatestepregateste pentrupentru«« surprizesurprize »»))

�� LipsaLipsa tratariitratarii soft a ,,soft a ,, procesuluiprocesului de de rezolvarerezolvare a a problemelorproblemelor ’’’’ ((producereaproducereasoftuluisoftului nu este o nu este o rutinarutina ci un ci un procesproces de de creatiecreatie ))

dardar ((inconvenienteinconveniente ))�� nu nu reflectareflecta intotdeaunaintotdeauna modulmodul in care in care este este implementeatimplementeat codulcodul

Page 39: 1 Fundamente

3939 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

PROTOTIPURILEPROTOTIPURILE

ProcesulProcesul de de implementareimplementare soft soft poatepoate ajuta ajuta pentrupentru a a controlacontrola ‘’‘’ caderilecaderile ’’’’ prinprinincludereaincluderea de de activitatiactivitati si si subactivitatisubactivitaticare care sporescsporesc intelegereaintelegerea ; ; prototipulprototipul este este un un asemeneaasemenea subprocessubproces

Un Un prototipprototip este un este un produsprodus partial partial finalizatfinalizatcare face care face posibilaposibila o o examinareexaminare a a unorunoraspecte ale aspecte ale sistemuluisistemului propuspropus de de catrecatrecumparatorcumparator si si producatorproducator pentrupentru a a decidedecide dacadaca este este convenabilconvenabil sausau se se apropieapropie de de produsulprodusul final.final.

AdeseaAdesea , , interfatainterfata cucu utilizatorulutilizatorul este este construitaconstruita si si testatatestata ca un ca un prototipprototip , de , de aceeaaceea utilizatorulutilizatorul intelegeintelege cum va cum va arataaratanoulnoul sistemsistem si si designeriidesignerii au o imagine au o imagine mai mai claraclara despredespre cum cum dorestedoreste utilizatorulutilizatorulsa sa interactionezeinteractioneze cucu sistemulsistemul ..

Prototipul este folositor pentruverificare si validare.

Asigura ca sistemul are implementate toate cerintele

Asigura ca fiecare functiefunctioneaza corect

Page 40: 1 Fundamente

4040 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL VMODELUL V

Este o variatie a modelului Cascada care demonstreaza cum activitatile de testaresunt legate de analiza si proiectare

(Ministerul de Aparare German, 1992)

Forma ciclului de viata dupa modelul V este cu analiza si proiectarea in stanga, iartestarea si intretinerea in dreapta.

Sugereaza ca testele de integrare vor fi folosite de asemenea pentru a verificacontinutul programului --> in timpultestelor, programatorii si echipa de testare trebuie sa se asigure ca toateaspectele conceperii programului au fostimplementate corect cu ajutorul codului. De asemenea, testarea sistemuluitrebuie sa verifice proiectareasistemului.

Testul de acceptanta, care este efectuat mai degraba de client decat de programator(i), valideaza cerintele prinasocierea unor pasi de testare cufiecare element din lista de cerinte(inainte ca sistemul sa fie acceptat sauplatit).

Partea dreapta a modelului V poate fi reexecutatapentru a repara si imbunatati cerintele, designul sicodul inainte ca pasii de testare din partea dreaptasa fie finalizati .

Focus -> documente & produse (Waterfall)

-> activitati & corectitudine (V Model)

Page 41: 1 Fundamente

4141 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL DE PROTOTIPIZAREMODELUL DE PROTOTIPIZARE

Prototipizarea poate fi ea insasi baza pentru un model efectiv.

Prototipizarea permite partilor sistemului sa poata fi construite repede pentru a intelege sau clarifica problemeleaparute. Cerinta de repetare a investigatiilor asigura ca programatorul, utilizatorul si clientul ajung la un acord comun atat in ceea ce este necesar cat si in ceea ce este propus.

Una sau mai multe bucle pentru cerintele prototipului, designului sau sistemului pot fi eliminate, astadepinzand de cerintele prototipului. Oricum, toate cerintele raman aceleasi: reducerea riscului si incertitudinea in programare

Page 42: 1 Fundamente

4242 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

PROTOTIPIZAREA PROTOTIPIZAREA -- continuarecontinuare

AvantajeAvantaje ::

•• PutemPutem evitaevita risculriscul unuiunui model model cascadacascada –– identificandidentificandneintelegerileneintelegerile despredespre cerintecerinte, , dintredintre programatorprogramator sisi client client

•• ImbunatatireaImbunatatirea dialoguluidialogului cu cu clientulclientul

DezavantajeDezavantaje ::

•• ClientulClientul credecrede ca ca aplicatiaaplicatia finalafinala nu nu esteestedepartedeparte de de prototipprototip deoarecedeoarece acestaacesta nu nu stiestie deaspredeaspre partilepartile ascunseascunse ale ale aplicatieiaplicatiei

•• ProgramatorulProgramatorul are are tendintatendinta sasa neglijezeneglijezesausau sasa uiteuite partiparti ale ale aplicatieiaplicatiei care care lipsesclipsesc in in prototipprototip

Sunt posibile iteratiile printre cerinte si proiectare.

Caile:

�Prototipul facut pe hartie (schite, desene, tabele, rapoarte)

�Construirea unui prototip functional (exemplu: interfete construite in Visual Basic – doar acestea, fara prelucrari)

�Folosirea altor programe existente ca modele de referinta

Page 43: 1 Fundamente

4343 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

SPECIFICARILE OPERATIONALESPECIFICARILE OPERATIONALEPentru multe sisteme, nesiguranta in

privinta cerintelor duce la schimbãri si probleme mai tarziu în aplicatia respectiva.

Aceasta abordare( Zave, 1984) permite programatorilor si clientilor sa examineze cerintelesi implicãrile lor în dezvoltare, unde ei pot sã discute si sa rezolve unele dintre probleme.

Cerintele sunt evaluate într-un modcare demonstreazã comportareasistemului - se poate incepeevaluarea folosind un pachet de soft, astfel incat implicarea lor sãpoata fi evaluata înainteaînceperii proiectului (dar se foloseste un alt mediu si limbajdecat cel de implementare).

Exemplu: Dacã specificatia cereca sistemul propus sa poata fi manipulat de catre 20 utilizatori, o forma executabila a specificatieipoate sã ajute analistii pentru a determina dacã acest numãr de utilizatori solicita prea multsistemul.

Acest tip este foarte diferit de modelele traditionale. Modelul cascada desparte functionalitatea sistemului de proiectare( ''ce'' este separat de ''cum''), intentionând sãpãstreze clientii departe de implementare. Specificatiaoperationalã permite ca functionalitatea si proiectarea safie unite.Specificatia operationalã este asemãnãtoare cu

prototipul. Procesul permite utilizatorului siprogramatorului sa examineze cerintele mai devreme.

Page 44: 1 Fundamente

4444 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL TRANSFORMATIONALMODELUL TRANSFORMATIONAL

Încearcã sã reducã posibilitatile de eroare eliminând câtiva pasi de dezvoltare majori (Balzer, 1981).

Folosind suportul de automatizare, procesul transformational aplica o serie de transformãri pentru a schimba o specificatie într-un sistem gata de livrare.

Exemple de transformãri:

- Schimbând reprezentarea de date selectând algoritmii

- optimizând

- compilând.

Un dezavantaj major este nevoiapentru o specificatie formalarealizata cu precizie.

Page 45: 1 Fundamente

4545 / / 5353SESE-- VasileVasile StoicuStoicu--TivadarTivadar

DEZVOLTAREA BAZATA PE FAZEDEZVOLTAREA BAZATA PE FAZEIntervalul de timp dintre cerintele aplicatiei si livrarea sistemului se numeste '‘durata de ciclu'' .Un mod pentru a reduce acest interval este dezvoltarea bayata pe faze: sistemul este proiectat ca el sa

poata fi livrat în bucãti (sau versiuni), permitandu-le utilizatorilor o parte functionala în timp ce restul este dezvoltat. Astfel, existã douã sisteme ce functioneaza în paralel - sistemul in exploatare (folosit de client) si sistemul in dezvoltare.Sistemul in dezvoltare este versiunea urmãtoare care este pregãtitã sã înlocuiascã sistemul in exploatare

curenta.

Page 46: 1 Fundamente

4646 / / 5353

IncrementariIncrementari si si iteratiiiteratiiAbordari :

DezvoltareaDezvoltarea incrementalaincrementala -Sistemul este impartit însubsisteme dupa functionalitateiar varianta finala este la începutdintr-un subsistem de micidimensiuni, si dupã aceea cufiecare noua imbunatatire i se adauga functionalitatati noi.

Dezvoltarea iterativã - livreazã un sistem intreg la început si dupãaceea schimbã functionalitateafiecarui subsistem cu fiecarevarianta nouã (o imbunatateste)

Exemplu: Un program de procesare de text, cu trei tip uri de functionalitate (creare de text, organizare - taie & lipeste, formare fonturile).

Pentru incrementarea programului, 'varianta 1' contine doar functiile de crearea textului apoi crearea si organizarea, apoi toate functi ile.

Pentru dezvoltarea iterativã, 'varianta 1' contine toat e functiile într-o forma primitiva ( exemplu taie & lipeste este lenta), pe cand 'v arianta 2' sporestecalitatea functiilor etc. Fiecare noua versiune îmbunãtã teste una anterioaraîntr-un anume fel.

Page 47: 1 Fundamente

4747 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

IncrementariIncrementari si si iteratiiiteratii -- continuarecontinuare

În realitate, multe companii folosesc o combinatie de dezvoltare iterativã si incrementala. O varianta nouã poate sã includã o functionalitate nouã, dar se poate si ca o functionalitatea existenta sa fie imbunatatita.

Motive pentru aceasta abordare:

� Instruirea utilizatorilor poate incepe la primele versiuni ale programului, chiar daca unele functii lipsesc; acest proces permite urmarirea in exploatare si imbunatatirea programului

� Piata poate fi creata inainte ca produsul sa fie aparut

� Frecvent produsele permit programatorilor remedierea problemelorneanticipate repede, pe mãsura ce ei sunt avertizati de la activitatea de mentenanta.

� Echipa de dezvoltare se poate concentra pe domenii diferite de expertizã cudiferite versiuni

Exemplu: un produs imbunatateste interfata, celalalt, performanta.

Page 48: 1 Fundamente

4848 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL SPIRALAMODELUL SPIRALA

Combinã activitatea de dezvoltare cu managementul de risc pentru a minimiza si controla riscul (Boehm, 1988). Modelul acesta este într-un fel asemeneadezvoltarii iterative.

� Începând cu o schitã initialã, procesul insereazã un pas pentru a evaluariscul si o alternativa de prototip înaintea ca un document de ''concept al operatiilor'' sa fie creat pentru a descrie la un nivel înalt cum ar trebui sãfunctioneze procesul de dezvoltare al sistemul.

� Apoi, cu fiecare iteratie, analiza riscurilor cantareste diferitele alternative dinpunct de vedere al cerintelor si constrangerilor, iar prototipizarea verificafezabilitatea inainte ca o anumita alternativa sa fie aleasa.

� Când riscurile sunt identificate, managerii de proiect trebuie sã se hotãrascãcum sa-l elimine sau sa-l minimizeze.

Exemplu: Proiectantii nu pot sã fie siguri dacã utilizatorii vor prefera un tip de interfatã sau altul; pentru a minimaliza riscul, ei pot produce o interfatapentru fiecare prototip si sa efectueze testele pentru a vedea care este ceapreferata.

Page 49: 1 Fundamente

4949 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

MODELUL SPIRALA MODELUL SPIRALA –– continuarecontinuare 11

Page 50: 1 Fundamente

5050 / / 5353

MODELUL SPIRALAMODELUL SPIRALA–– continuarecontinuare 22

AcestAcest model este model este folositfolosit pentrupentru proiecteproiecte la la scarascara mare, care mare, care implicaimplicaun un riscrisc deosebitdeosebit ((adicaadica resurseresurse financiarefinanciare mari).mari).

(sau altareprezentaresimplificata)

Page 51: 1 Fundamente

5151 / / 5353

Dezvoltare AGILDezvoltare AGILĂĂ

�� Accent pe cod mai degrabă decât pe un Accent pe cod mai degrabă decât pe un proiect proiect predefinitpredefinit

�� Dezvoltare iterativăDezvoltare iterativă�� Livrare rapidă Livrare rapidă șșii flexibilitate pentru a flexibilitate pentru a

îîndeplini ndeplini cerincerințțee îîn schimbaren schimbareManifestoManifesto AGILEAGILE

�� Mai degrabă indivizi Mai degrabă indivizi șșii interacinteracțțiuniiuni decât procese decât procese șșii unelteunelte�� Software care Software care funcfuncțționeazăionează mai degrabă decât o bună mai degrabă decât o bună documentadocumentațțieie�� Colaborare cu clientul mai degrabă decât negociere contractualăColaborare cu clientul mai degrabă decât negociere contractuală�� Răspuns la schimbări mai degrabă decât urmărirea unui planRăspuns la schimbări mai degrabă decât urmărirea unui plan

Page 52: 1 Fundamente

5252 / / 5353

Dezvoltare AGILĂDezvoltare AGILĂ–– continuarecontinuare

�� PRINCIPIIPRINCIPII�� SatisfacereaSatisfacerea nevoilornevoilor clientuluiclientului prinprin livralivrarrea ea continucontinuă ă șșii rapidă rapidă de software utilde software util

�� SoftwareSoftware--ul este livrat frecvent (ul este livrat frecvent (săptămânisăptămâni))�� SoftwareSoftware--ul care lucrează este principala măsură a progresuluiul care lucrează este principala măsură a progresului�� Chiar Chiar șșii schimbări târzii sunt acceptate schimbări târzii sunt acceptate�� Cooperare apropiată Cooperare apropiată (zilni(zilnicăcă) ) îîntre ntre dezvoltatoridezvoltatori șșii cei cei implicaimplicațțiiîîn businessn business

�� ConversaConversațțiaia fafațțăă îîn n fafațțăă –– forma de comunicare dorită forma de comunicare dorită�� ÎÎncrederea trebuie construită ncrederea trebuie construită îîn n permanenpermanențță ă îîntre indivizi ntre indivizi motivamotivațți i

�� AtenAtențțieie continuă la buna proiectare continuă la buna proiectare șșii calitatea din punct de calitatea din punct de vedere tehnicvedere tehnic

�� SimplitateSimplitate�� Echipe care se autoEchipe care se auto--organizeazăorganizează

Page 53: 1 Fundamente

5353 / / 5353

Exemple de dezvoltare AGILĂSCRUM- 1

1. SCRUMTeoria Scrum � Scrum este bazat pe o teorie empirică de control a proceselor, sau

empirism. Empirismul afirmă faptul că sursa cunoștințelor este experiența, și luarea deciziilor se bazează pe ceea ce este știut. Scrum folosește o abordare iterativă, incrementală cu scopul de a optimiza predictibilitatea șide a controla riscul.

Trei piloni susțin orice implementare a controlului procesului empiric: transparența, inspecția și adaptarea.

Transparența Aspecte semnificative ale procesului trebuie să fie vizibile celor responsabili de rezultate. Transparența necesită ca aceste aspecte să fie definite de un standard comun astfel încât observatorii să împărtășească puncte de vedere comune asupra a ceea ce văd.

De exemplu: � Un limbaj comun referitor la proces trebuie să fie împărtășit de către toți

participanții; și, � O definiție comună a statusului “Finalizat” trebuie împărtășită de către cei

care efectuează munca și cei care acceptă munca rezultată.

Page 54: 1 Fundamente

5454 / / 5353

Exemple de dezvoltare AGILĂSCRUM - 2

Inspecția Utilizatorii Scrum trebuie să inspecteze în mod firesc progresul făcut către îndeplinirea obiectivului, astfel încât să detecteze abaterile nedorite. Inspecția lor nu trebuie să fie atât de frecventă încât să afecteze modul de lucru. Inspecțiile sunt cele mai benefice atunci când sunt efectuate în mod sârguincios la locul de muncă.

Adaptarea Dacă un inspector stabilește că unul sau mai multe aspecte ale procesului deviază în afara unor limite acceptabile, și că produsul rezultat va fi inacceptabil, procesul sau materialul procesat trebuie să fie ajustat.

Scrum recomandă patru oportunități formale pentru inspecție șiadaptare

� Ședința de Planificare a Sprint-ului � Ședința Scrum Zilnică � Ședința de Revizuire a Sprint-ului � Retrospectiva Sprint-ului

Page 55: 1 Fundamente

5555 / / 5353

� Sprint-ul (The Sprint) Inima Scrum-ului este un Sprint, cu o durată de maxim o lună, în timpul căruia este creat un Increment al produsului, cu statusul "Finalizat" ("Done"), utilizabil și potențial livrabil. Sprint-urile au durate consistente pe toată durata efortului de dezvoltare. Un Sprint nou începe imediat după aflarea concluziilor Sprint-ului anterior.

Sprint-urile conŃin şi constau din Ședința de Planificare a Sprint-ului (Sprint PlanningMeeting), Ședința Scrum Zilnică (Daily Scrums), activitatea de dezvoltare, Ședința de Revizuire a Sprint-ului (Sprint Review Meeting) și Retrospectiva Sprint-ului (Sprint Retrospective).

� În timpul Sprint-ului: � Nu se aduc modificări care ar putea afecta ținta Sprint-ului; � ComponenŃa echipei de dezvoltare şi obiectivele de calitate rămân constante; şi, � Posibilitățile (scope) pot fi clarificate şi re-negociate între Product Owner şi echipa

de Dezvoltare (Development Team) pe masură ce se progresează.

Fiecare Sprint poate fi considerat un proiect cu un orizont de timp nu mai mare de o lună. La fel ca și proiectele, Sprint-urile sunt folosite pentru a realiza ceva. Fiecare Sprint are o definiŃie a ceea ce urmează să fie construit, un design și un plan flexibil, care îl vor ghida în procesul de realizare cât și în produsul rezultat.

Exemple de dezvoltare AGILĂSCRUM - 3

Page 56: 1 Fundamente

5656 / / 5353

� Numele “cleanroom” vine de la procesul de fabricare a semiconductorilor (“camera curată”)

� Filosofia este mai degrabă evitarea defectelor decât înlăturarea lor

• Metodă de dezvoltare software bazată pe metode formale

• Verifică specificaŃiile de proiectare folosind demonstrarea corectitudinii, cu metode matematice (v. cap. Testare)

• Se bazează puternic pe metode de testare statistice pentru a descoperi erorile de impact major

• În general se bazează pe metode de dezvoltare incrementale

Exemple de dezvoltare AGILĂ –CLEANROOM - 1

Page 57: 1 Fundamente

5757 / / 5353

ETAPE�� CerinCerinŃŃe e – se defineşte, pentru fiecare increment, o descriere a

cerinŃelor la nivelul clientului�� Specificarea structurii de Specificarea structurii de cutiecutie (box)(box) – descriu specificaŃiile

funcŃionale�� Proiectarea FormalăProiectarea Formală – specificaŃiile (“cutii negre”) sunt rafinate

iterativ (cu un increment, astfel ca să devină analoge cu proiectarea arhitecturală şi cea procedurală (“cutii de stare”, respectiv “cutiitransparente”)

� Verificarea corectitudinii – prin chestionare, de către echipă�� Testare STestare Statistictatisticăă – un eşantion al tuturor cazurilor de test

posibile este mai degrabă utilizat decât testarea exhaustivă�� CertificaCertificarearea – după ce verificarea, inspecŃia şi testele de uzanŃă

sunt terminate şi toate defectele înlăturate, incementul este certificat şi gata pentru integrare

Exemple de dezvoltare AGILĂ –CLEANROOM - 2

Page 58: 1 Fundamente

5858 / / 5353

Exemple de dezvoltare AGILĂ –CLEANROOM - 3

Constructstructuredprogram

Definesoftware

increments

Formallyverifycode

Integrateincrement

Formallyspecifysystem

Developoperational

profileDesign

statisticaltests

Testintegrated

system

Error rework

Page 59: 1 Fundamente

5959 / / 5353

STANDARDE STANDARDE ÎÎN DEZVOLTAREA N DEZVOLTAREA SOFTWARESOFTWARE

Page 60: 1 Fundamente

6060 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

DODDOD--STDSTD--2167 un standard2167 un standard

ExistãExistã multemulte standardestandarde pentrupentru dezvoltareadezvoltarea software, dar software, dar multemulte dindin acesteaacestea suntsunt neoficialeneoficialesausau specificespecifice companiilorcompaniilor respective. respective.

UnulUnul dindin primeleprimele este este standardulstandardul DODDOD--STDSTD--2167 A 2167 A sausau MILMIL--STDSTD--2167 de la US 2167 de la US DeptDept. of . of DefenseDefense ((DodDod).).

Specificã un model ca si cel ‘’cascadã’’:

• Analiza/proiectarea cerintelor de sistem

• Analiza cerintelor

• Proiectarea preliminara

• Codarea si testarea (CSU)

• Computer Software Component

(CSC) integrare si testare

• Computer Software Configuration

Item (CSCI) testare

• Integrarea si testarea de sistem

Standardul este permis de asemenea pentru 8 verificari sau treceri în revistã si 17 tipuri de rapoarte oficiale si documentaþie.

Lista de verificari:

• inspectia cerintelor soft

• inspectia proiectarii soft

• inspectia specificatiilor soft

• inspectia proiectarii preliminare

• inspectia proiectarii finale

• revizuirea configuratiei functionale

• revizuirea configuratiei fizice

• inspectia variantei oficiale

Page 61: 1 Fundamente

6161 / / 5353

DODDOD--STDSTD--2167 un standard 2167 un standard --continuarecontinuare 11

Dezvoltarea sistemului

Page 62: 1 Fundamente

6262 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

DODDOD--STDSTD--2167 un standard 2167 un standard --continuarecontinuare 22

In USA multe aplicatii dificilesunt dezvoltate folosind 2167 A, dar multe sisteme suntimplementate folosind un subset mult mai mic al modelului.

Acest standard a fost partial depasit de catre standardulIEEE 839 si ISO 9000.

Lista rapoartelor si documentatiei:•continutul documentului sistem/segment •plan de dezvoltare soft•specificatiile cerintelor soft •specificatia cerintelor interfetei•documentul de concepere a interfetei•Specificatiile de producere soft•Documentul de descriere a versiunii•Planul de testare a soft-ului•Planul de descriere a soft-ului•Raportul de testare soft•Manualul operatorului•Manualul programatorului•Manualul suportului tehnic•Propunerea de eventuale schimbari•Notificarea specificatiilor de schimbare

Page 63: 1 Fundamente

6363 / / 5353SESE-- VasileVasile StoicuStoicu--TivadarTivadar

DODDOD--STDSTD--2167 un standard 2167 un standard --continuarecontinuare 33

Predarea rapoartelor si documentatiilor formale :

Page 64: 1 Fundamente

6464 / / 5353

ISO 9000ISO 9000ISO 9000 (International Standard Organisation), est e un standard international pentruimbunatatirea calitatii, care a fost adoptat in Europa , SUA, Asia.

Standardul a fost conceput pentru aplicarea sa pentru o larga varietate de producatori. ISO 9001 -9003 se aplica intreprinderilor, in conformitate cu scopul activitatilor lor. Familia ISO 9004 si ISO 9000-X suntdocumente care asigura indrumarea pentru aplicatiile specifice anumitor domenii.

Pentru dezvoltarea soft ISO 9000-3 este documentul de interes.

ISO 9000 este mai bine situata decat 2167 A pentru dezvoltare produselor comerciale. Chiarunele unitati ingineresti soft de aparare au trecut la ISO 9000 in echivalent militar, MIL-STD-498.

Standardele ISO sunt orientate pe proces, ele ajutand companiile sa-si creeze un mediu care sa garanteze o anumita calitatea produselor sale.Principalele campuri ale calitatii care

intereseaza:•responsibilitatea managementului•Calitatea sistemului•Revizia contractelor•controlul proiectarii•Controlul documentelor si datelor•Identificarea si trasabilitatea produselor•Controlul proceselor

•Inspectie si testare•Controlul inspectiei, masurarea si testareaechipamentelor•Inspectia si nivelul testarii•Controlul non-conformitatii produselor•Actiuni de corectare si prevenire•manipulare, stocare, impachetare, pastrare si livrare•Controlul inregistrarilor de calitate•calitatea interna a contabilitatii•instruire•Service (intretinere)•tehnici statistice

Pentru a obtine certificarea ISO standard, este cerut un volum semnificativ de documente. Pentru a implementa intr-o companie acest sta ndard, este necesara in prealabil o analiza a beneficiilor, pentru a nu cheltu i mai mult decat poate fi obtinut.

Page 65: 1 Fundamente

6565 / / 5353

IEEE 830IEEE 830IEEE 830-1993 contine recomandarile practice pentru So ftware Design Descriptions (SDDs).

Ghidul este descris ca si o “coperta” a activitatilor de-a lungul proiectarii. Aspectul recomandat al continutului proiectului include combinatii de decompozitii, dependenta, interfata, si descriere a detaliilor.

Descrierea decompozitiei este folosita pentru a incadra entitatile de proiectare in sistem. Fiecareentitate de acest fel este descrisa de catreidentificarea sa, tip, scop, functie si subordonare.

Sectiunea ’’dependentelor’’ este o descriere a relatiilordintre entitati si resurse sistem. Atributele entitatii includidentificare, tip, scop, dependente si resurse (structuri, diagrame de date, etc)

Descrierea interfetei asigura o lista cu tot ceea ceproiectantul trebuie sa stie despre folosirea entitatilor(fiecare inregistrare cu identificare, functie sau interfete-dictionare de date, liste cu parametri, etc.)

Descrierea detaliata este folosita pentru a arata detaliileinterne ale fiecarei entitati a sistemului ale caror atributeinclud identificarea, descrierea procesarilor si descriereadetaliata a datele

Standardul este incomplet (el specifica doar cererile legate de proiectare si descriere. Sunt necesare informatii suplimentare.

Page 66: 1 Fundamente

6666 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

CE MODEL DE PROCES FOLOSIM ?CE MODEL DE PROCES FOLOSIM ?

� Modelele prezentate sunt doar cateva din celefolosite

� Alte modele ale proceselor pot fi definite siconcepute pentru nevoile utilizatorilor, clientuluisi proiectantilor. Ar trebui sa percepem procesulde dezvoltare software ca o colectie a modelelorproceselor, mai degraba decat a unui singurmodel.

� Indiferent de modelul procesului folosit, multeactivitati sunt similare.

� Adesea, modelul procesului este impus de catreorganizatiile soft (in functie de “cultura” interna, uneltele software disponibile, instruire etc).

Page 67: 1 Fundamente

6767 / / 5353IPIP-- VasileVasile StoicuStoicu--TivadarTivadar

Care Care suntsunt concluziileconcluziile acestuiacestui capitolcapitol

PutetiPuteti folosifolosi concepteconcepte ale ale acestuiacestui capitol in capitol in felulfelul urmatorurmator ::

individual individual --

•• pentrupentru ghidareaghidarea comportamentuluicomportamentului candcand lucratilucrati in in echipaechipa

•• vava ajutaajuta sasa invatatiinvatati cum cum sasa colaboraticolaborati sisi sasa vava coordonaticoordonati cu cu colegiicolegii

•• vava putetiputeti concentraconcentra asupraasupra aspecteloraspectelor procesuluiprocesului de de dezvoltaredezvoltare pentrupentru a a vavaimbunatatiimbunatati cunstintelecunstintele (functional, (functional, comportamentalcomportamental sisi a a altoraltorperspective)perspective)

ca ca echipechip ăă ––

•• un model bun un model bun arataarata fiecaruifiecarui membrumembru al al echipeiechipei cece activitatiactivitati aparapar intrintr --un un proiectproiectpentrupentru a a sisi le le puteaputea impartiimparti

•• managerulmanagerul proiectuluiproiectului poatepoate folosifolosi tehniciletehnicile specificespecifice procesuluiprocesului pentrupentru aa

imbunatatiimbunatati procesulprocesul , , simulandsimuland activitatiactivitati sisi urmarindurmarind resurseresurse pentrupentru

determinareadeterminarea echipeiechipei optimeoptime sisi activitatileactivitatile pentrupentru a se a se incadraincadra in in bugetulbugetul sisi

termeneletermenele stabilitestabilite


Recommended