Modele Ale Ciclului de Viata Al Sistemului Informatic [PDF]

Zitiervorschau

Tema 8. Modele ale ciclului de viaţă al sistemului informatic. 1. Noţiuni generale. În ultima perioadă de timp, datorită apariţiei unei noi concepţii în abordarea sistemelor informatice: orientarea-obiect, s-au înregistrat câteva fenomene îngrijorătoare. Două dintre ele fiind cele mai semnificative: 1. Neglijarea sau sfidarea multor realizări anterioare pe plan procedural şi/sau ştiinţific; 2. Supralicitarea (supraoferta) tuturor teoriilor lansate în anii ′90 , în jurul noului concept. Din acest motiv, în continuare, va fi analizată esenţa activităţii de analiză şi proiectare a SI, adică a Ciclului de viaţă al dezvoltării sistemelor informatice (CVDSI) sau Ciclul dezvoltării (CDSI). Motivaţia acestei analize este datorată şi unor păreri total eronate privind conceptul menţionat anterior. De exemplu, CVDSI este confundat, de unii specialişti, cu metodele de abordare a SI (acest aspect a fost abordat în tema precedentă), considerându-l ca o treaptă incipientă (iniţială) în acţiunea de abordare a activităţilor specifice SI. Alţi specialişti (care sfidează toate lucrurile din trecutul ştiinţelor), apreciază, că este chiar o blasfemie (batjocoră, defăimare) adusă obiectelor, dacă sunt asociate cu învechitul concept de CVDSI. Prin urmare, se impune efortul de lămurire a lucrurilor (nu de altceva, dar parafrazând o cunoscută zicală, am putea spune că „cine nu cunoaşte istoria, riscă să o ...denigreze”). Din start, trebuie menţionat că, indiferent de etapa istorică sau metodologică, SI sunt abordate prin prisma ciclului de viaţă. Ele apar, se dezvoltă, descresc şi pier sau, printr-un nou ciclu, se perfecţionează, dând naştere unei alte versiuni sau chiar unui nou SI. Prin urmare, nu prezenţa CVDSI trebuie discutată, ci formele de regăsire a acestuia în timp, în funcţie de cadrul în care se realizează sistemul. Mutaţiile din domeniul TI şi al metodelor de abordare a SI s-au reflectat şi în CVDSI, fie prin schimbarea etapelor acestuia, fie prim modificare succesiunii de parcurgere a lor. În continuare, se va face o referinţă, doar la câteva dintre modelele concrete în care se poate regăsi CVDSI, nu înainte de a face următoarele precizări: • CVDSI este o „metodologie comună de dezvoltare a sistemelor din unităţile social-economice (USE), caracterizată prin câteva etape (faze) care marchează evoluţia eforturilor de analiză şi proiectare a SI”; • Etapele (fazele) ciclului de viaţă sunt greu de prezentat, nu numai ca denumire, ci şi ca număr, ultimul variind de la 3 (de exemplu, analiză, proiectare, implementare), la peste 20. În acelaşi context, de menţionat că, indiferent de numărul şi denumirea etapelor, CVDSI rămâne o problemă destul de importantă în special, succesiunea şi felul în care se parcurg etapele respective, ceea ce în literatura de specialitate se tratează sub numele de modele ale CVDSI, ca de exemplu: Cascadă, V, X, Incremental, Spirală, Evolutiv, Tridimensional, Minge de baseball (sau de oină), Fântână arteziană, Piramidă, Pinball (bila magică), etc. De remarcat că, multe dintre aceste modele sunt asociate ciclului de viaţă al obiectelor, sau ciclului de viaţă al dezvoltării obiectelor, ceea ce este cu totul altceva, deşi din experienţa multor specialişti, ele s-ar putea aplica şi unor sisteme. 2. Modelul „Cascada”. Modelul „Cascada” constă într-o divizare a ciclului de viaţă în faze secvenţiale. La rândul lor, fazele sunt structurate pe activităţi şi subactivităţi. Trecerea de la o etapă la alta se realizează după ce precedenta este parcursă în întregime. Modelul se aplică la nivel de sistem şi poate fi reprezentat ca în Figura 1. Printre avantajele modelului pot fi enumerate: • Un control total asupra etapelor (fazelor), în sensul că ele sunt ordonate şi, deci sunt previzibile, prin evidenţierea clară a ariei de cuprindere a fiecărei etape sau subetape; • Este uşor de însuşit de către membrii echipelor de analiză şi proiectare, inclusiv de cei noi, cu o experienţă mai mică; • Fiecare etapă este însoţită de o documentaţie perfect structurată (controlată). Dezavantajele modelului : • Sistemul se predă doar după parcurgerea etapelor anterioare, ceea ce înseamnă o lungă perioadă de timp, suficient ca beneficiarul să-şi schimbe pretenţiile; • Nu reprezintă o abordare dinamică a sistemelor; • Nu este deschis schimbărilor ce pot interveni pe parcurs. De asemenea, trebuie menţionat că, modelul este folosit şi în proiectarea orientată-obiect. Ideea de bază a modelului este regăsită şi în alte modele, cum ar fi: în „V”, în „X”, fântână arteziană sau cel incremental.

Definirea cerinţelor

Analiza

Proiectarea

Implementarea

Testarea

Utilizarea şi întreţinerea

Figura 1. Modelul cascadă 3. Modelul „V” Aşa cum s-a menţionat anterior, modelul „V” reprezintă o variantă a modelului „Cascadă”, prin care se introduc conceptele de sistem şi componente (subsisteme), aplicându-se teste explicite la un sistem ierarhic pentru sporirea controlului asupra modului în care se desfăşoară etapele. Anume această înlesnire constituie o latură a literei V. Prima este latura din stânga, parcursă descendent şi conţine etapele propriu-zise, iar cea dea doua latură, din dreapta, se parcurge ascendent, pe ea realizându-se verificările şi validările elementelor create anterior. Modelul poate fi reprezentat ca in Figura 2. Modelul scoate în evidenţă cu mai multă claritate separările dintre ceea ce implică participarea utilizatorului, modelul arhitectural şi pe cel al implementării. Astfel, utilizatorul este implicat doar în fazele din partea superioară a V-ului. Arhitectura sistemului este surprinsă în partea din mijloc a literei. Faza de implementare se referă la partea inferioară a literei şi poate reprezenta fie asamblarea componentelor soft, fie codificarea unor componente. Modelul se potriveşte şi în mediul orientat-obiect, deoarece stimulează prototipizarea şi reutilizarea unor structuri superioare. Prin structurile ierarhice şi modulare pe care le promovează, el oferă un control puternic asupra sistemului în curs de realizare. Aceasta îl face utilizabil şi în sistemele complexe. Modelul presupune abordarea şi dezvoltarea pe componente a sistemului adică abordarea pe părţi şi integrarea lejeră a lor. El devine şi mai puternic dacă promovează iteraţia, adică reluarea unor faze, activităţi sau subactivităţi. De asemenea modelul face distincţie evidentă între verificare şi validare. Prima se referă la testarea sistemului, în diverse stadii ale lui, dacă s-a construit corect din punct de vedere logic, în timp ce validarea va scoate în evidenţă faptul că sistemul, în forma lui finală, răspunde sau nu cerinţelor iniţiale. Anume acest aspect este considerat un dezavantaj al modelului pentru că validarea se realizează prea târziu. Filosofia modelului V este regăsită şi în alte modele, inclusiv în modelul X.

Definirea cerinţelor

Validare

Proiectare sistem

Testare sistem

Proiectare Subsistem (componentă)

Testare Subsistem (componentă)

Codificare / asamblare componente Figura 2. Modelul V

4.

Modelul incremental

Modelul incremental este o altă formă a modelului cascadă. De altfel, în modul de descriere a etapelor primare nici nu există diferenţă faţă de modelul cascadă, deoarece atât definea cerinţelor, cât şi analiza se efectuează la nivelul întregului sistem. După acestea se efectuează divizarea proiectului în subproiecte, ele fiind urmărite pe activităţi care vor concura la obţinerea componentelor necesare sistemului final. Aceasta este, de fapt, filosofia de bază a modelului. Faţă de modelul V, modelul incremental oferă posibilitatea atingerii scopului final în 2 variante: 1. Sistem global livrat la sfârşit; 2. Componente livrate distinct. Modelul incremental poate fi reprezentat ca în Figura 3.

Avantajele modelului incremental: • Se încadrează în principiul arhicunoscut „Împarte şi vei stăpâni”, prin posibilitatea abordării unor părţi ale întregului; • Sistemul poate fi livrat şi pe componente realizate la perioade scurte de timp; • Proiectul sau sistemul final poate fi realizat de mai multe echipe sau persoane datorită modularizării lui. Printre dezavantajele modelului pot fi enumerate: • Imposibilitatea aplicării lui în toate cazurile, uneori neexistând elementele necesare divizării întregului; • Componentele pot fi realizate numai după ce întregului sistem i se defineşte arhitectura, totul derulându-se după strategia descendentă, ceea ce înseamnă încă o condiţie dură: cunoaşterea şi formularea cerinţelor din etapa primară de abordare a sistemului; • Fiind posibil de realizat pe părţi, eforturile de integrare a acestora în întreg sunt destul de mari, vorbindu-se chiar de o aşa-zisă testare multiplă de sisteme, cu trimitere la faptul că, de fiecare dată când se adaugă o nouă componentă, sistemul poate fi considerat ca unul nou.

Definirea cerinţelor

Proiectare componentă-1

Implementare componentă-1

Analiză

Arhitectura sistemului

Instalare componentă-1

...

Întreţinere componentă-1

...

Proiectare componentă-n

Implementare componentă-n

Instalare componentă-n

Întreţinere componentă-n

Figura 3. Modelul incremental 5. Modelul spirală. Apariţia acestui model este cauzată de 2 factori: 1. Natura iterativă a dezvoltării şi nevoia de planificare şi evaluare a riscurilor fiecărei iteraţii; 2. Deficienţa înregistrată la modelul „V”, în care validarea se efectuează prea târziu. Anume aceasta face ca modelul să propună realizarea validării cât mai devreme posibil, de cât mai multe ori, prin construirea prototipurilor, conform modelului simplificat din figura 4. Deşi modelul este descris ca o spirală, el este de fapt o reprezentare liniară în care unele activităţi pot fi reluate. Conform acestui model, echipa de dezvoltare şi utilizatorii se angajează treptat în proiect, diminuând riscurile la nivel de prototip. De asemenea, un element pozitiv este valorificarea experienţei anterioare în planificarea activităţilor din prototipul următor. De remarcat că în fiecare iteraţie se regăseşte modelul cascadă. Adică după cunoaşterea cerinţelor şi efectuarea studiilor de fezabilitate, se realizează sistemul, se integrează şi se instalează printr-o singură livrare, în varianta modelului cascadă. Printre avantajele modelului pot fi menţionate: • Posibilitatea evaluării riscurilor în diferite momente; • Simplificarea operaţiunilor de evaluare a ceea ce este necesar în etapa (prototipul) următoare, inclusiv prin prisma costurilor. Elementele ce condiţionează folosirea modelului spirală sunt: • Profesionalismul echipei de dezvoltare; • Flexibilitate în acţiune, inclusiv în alocarea de fonduri precum şi în definirea activităţilor de întreprins.

Prototip-1 Prototip-2 Prototip-3 Prototip-4

Figura 4. Modelul Spirală 6.Modelul evolutiv Prin esenţă, modelul evolutiv constă în efectuarea unei investigaţii iniţiale, elaborarea unei strategii pentru divizarea proiectului în părţi/segmente, fiecare cu o valoare deosebită pentru client. Ele sunt realizate şi livrate în mod iterativ şi contribuie la sporirea treptată a performanţelor sistemului. Formele obţinute pentru părţile componente nu sunt foarte puternic detaliate, lăsându-se loc pentru adaptări şi modificări ulterioare. Oricare dintre segmentele/părţile luate în studiu trece prin toate etapele (fazele) de dezvoltare a sistemelor: definirea cerinţelor, analiză, proiectare, implementare, testare, utilizare. Clientul intră în posesia unei forme aproape finisate (cvasi-finite) la terminarea fiecărui segment. Soluţia întregului sistem înseamnă, de fapt, segmentarea ei conform modelului evolutiv, care este identică modului în care orientarea-obiect încapsulează atributele şi funcţionalitatea în obiecte bine definite. Schema generală a modelului evolutiv poate fi reprezentată ca in Figura 5. Modelul evolutiv are un puternic impact în mediul utilizatorilor deoarece este orientat către aceştia. de asemenea, procesul de dezvoltare a sistemelor se efectuează sub un control permanent, inclusiv din partea clienţilor. Principalul avantaj al acestui model constă în crearea unei arhitecturi deschise, flexibile, elaborată prin participarea tuturor părţilor interesate, inclusiv a utilizatorilor, dar şi a unor specialişti profesionişti. Modelul este absolut diferit de modelele tradiţionale şi de aceea de multe ori este întâmpinat cu ostilitate.

Studiul iniţial Divizarea în segmente

Integrare segmente

Componentă (Segment) 1 Definire cerinţe Analiză Proiectare Implementare Testare Utilizare

...

Componentă (Segment) n Definire cerinţe Analiză Proiectare Implementare Testare Utilizare

Figura 5. Modelul evolutiv

7.

Modelul tridimensional

Modelul tridimensional surprinde dezvoltarea sistemelor printr-o redare grafică bazată pe trei axe. Astfel, este descris ciclul de viaţă al sistemului, ciclul de viaţă al proiectului şi ciclul de viaţă al abstractizării. Modelul poate fi reprezentat ca în Figura 6. Aşa după cum rezultă din schemă, ciclul de viaţă al sistemului informatic surprinde timpul vieţii sistemului şi perioadele principale după care se efectuează schimbări majore cum ar fi: • Creşteri ale sarcinii de prelucrare (ca volum al datelor sau al tranzacţiilor înregistrate); • Schimbări tehnologice (hard şi/sau soft); • Schimbări structurale (de la sisteme centralizate la arhitecturi distribuite). Toate acestea determină acţiunile de întreprins în timpul realizării sau întreţinerii sistemului. Ciclul abstractizării tratează nivelurile succesive ale specificaţiilor, pornind de la cea mai pură formă conceptuală, independentă de tehnologie, până la una care depinde vizibil de mediul tehnologic, adică nivelul fizic. Ciclul de viaţă al proiectului (denumit şi ciclul deciziei) este echivalent cu modelul cascadă. El defineşte secvenţa fazelor prin care trece proiectul pentru a fi realizat. În concluzie, proiectarea unui sistem conform acestui model înseamnă orientarea continuă şi simultană pe cele trei axe. Originalitatea modelului constă în axele ciclului de viaţă al sistemului şi ciclului abstractizării. Primul permite o planificare a evoluţiei sistemului şi a schimbărilor de efectuat, în timp ce al doilea ciclu permite oferirea soluţiei conceptuale pentru problema dată, independent de tehnica implementată. Aceasta oferă posibilitatea extinderii sistemului în viitor. 8.

Modelul X

Modelul X reprezintă o extindere a performanţelor obţinute prin modelele cascadă şi V, ambele fiind considerate ca exemple de modele ale procesului de dezvoltare, care la rândul lui ar fi parte integrantă a unui proces mai larg al livrării sistemelor. Prin introducerea noţiunii de model al livrării se oferă posibilitatea urmăririi fiecărui proces al dezvoltării ca o iteraţie, sau evoluţie spre soluţia acceptată. Specificul modelelor iterative este accentul pus pe minimizarea resurselor de utilizat pentru asigurarea următorului increment (adaos, spor) de produs, cu menţinerea legăturii cu obiectivele proiectului global (general). Fiecare produs livrat succesiv are o funcţionalitate parţială. Modelul X poate fi reprezentat ca în Figura 7. Partea superioară a X-ului este o variantă modificată a modelului V, exprimând modul în care specificaţiile tehnice devin sisteme livrate. Ca şi la dezvoltările tradiţionale, există specificaţii ale sistemului, proiectul arhitectural, proiectarea de detaliu, codificarea, testarea pe componente, integrarea si testarea sistemului. Partea inferioară a X-ului este un V întors, pentru a sugera noţiunea de gestiune patrimonială a depozitelor reutilizabile, fie la nivel de componentă, de structură, domeniu, sau chiar la nivel de aplicaţie. Modelul X exprimă două mari categorii de cicluri de activităţi: una derulată înainte, care sintetizează sistemul nou (sau modificat), şi o activitate derulată înapoi, pentru dobândirea sistemelor şi a componentelor acestuia, pentru catalogarea diverselor modele, arhitecturi şi componente ale activităţii finalizate pentru o posibilă reutilizare. Ingineria preventivă de la nivelul fiecărui stadiu al procesului încearcă sa reutilizeze (prin selecţie, adaptare, rafinare) acumulările anterioare care se găsesc în bibliotecile sistemelor. Din punct de vedere economic, dezvoltarea softului în ciclul derulat înainte reprezintă responsabilităţile curente pe linie de soft, iar ciclul derulat înapoi - componentele fizice soft. În cazul orientării-obiect, modelul X este utilizat corespunzător domeniului nou de studiu. Atunci când intră în discuţie o nouă aplicaţie, echipa de realizare a ei se va ocupa un timp anume de aflarea modelelor existente în acel domeniu, în vederea determinării gradului în care ele pot servi noua aplicaţie. Astfel, preocuparea esenţială va fi axată pe „ce poate fi luat” în procesul de analiză. Modelul X de dezvoltare a softului ia în considerare existenţa diferitelor cicluri de viaţă concurente (paralele) pentru componente, aplicaţii şi proiecte abstracte. Conţinutul bibliotecilor componentelor fizice se află într-un continuu proces de rafinare. În concluzie, ca şi modelul anterior, nici modelul X nu va ocupa un loc de seamă în categoria modelelor ciclului de viaţă prin simplul fapt că nu aduce elemente noi, ci doar surprinde în detaliu prin V-ul întors, ceea ce în realitate se efectuează şi la alte modele.

Ciclul abstractizării

Sistem generaţia 1

Nivel conceptual

Sistem generaţia 2 Nivel logic

Sistem generaţia 3

Nivel fizic

Studiu preliminar Studiu detaliat

Ciclul de viaţă al sistemului T1

Studiu tehnic Implementare Întreţinere

Ciclul proiectului

Figura 6. Modelul tridimensional

T2

T3