Sunteți pe pagina 1din 15

Curs 3 ASSI (2005-2006)

3. TEHNOLOGIA DE REALIZARE A UNUI PRODUS INFORMATIC


3.1. Consideratii generale
Finalizarea unui produs informatic implica parcurgerea a doua activitati majore: o
activitate de conceptie sau concepere (sinonima, in parte, cu notiunea de proiectare) si o
activitate de realizare.
Inainte de a examina aspectele legate de continutul procesului de conceptie si
realizare a unui produs tehnic, in particular a unui produs informatic, vom face cateva
precizari absolut necesare legate de partea procedurala (formala) a produsului de concepere.
Inca din antichitate s-au centralizat doua modalitati logice de gandire, doua dialectici:
o dialectica ascendenta (modalitate bottom-up), prin care se formeaza conceptele, si o
dialectica descendenta (modalitate top-down) sau operatia de diviziune logica a conceptelor.
Unirea celor doua modalitati intr-un singur complex, complexul top-down-bottom-up, poate
fi reprezentat schematic in fig. 3.1.

Dialectica
descendenta

CONCEPT

SET DE OBIECTE
ABSTRACTE

Dialectica
ascendenta
SET DE OBIECTE
NATURALE

Fig. 3.1
Se poate constata ca intr-o prima etapa are loc un proces de abstractizare; punctul de
plecare este reprezentat de un set de obiecte naturale, punctul terminus fiind un obiect
abstract, conceptul. Urmeaza o a doua etapa in care pornindu-se de la concept, printr-un
proces de divizare se ajunge la identificarea unui set de obiecte abstracte care reprezinta
"oglinda" setului de obiecte naturale. Aceasta a doua etapa nu are o finalitate practica
imediata, fiind doar un proces de adincire a cunoasterii.
Aplicarea complexului top-down-bottom-up la obtinerea produselor informatice,
a produselor tehnice in general, este schitata in fig. 3.2, cu precizarea ca obiectul
abstract, conceptul, se considera ca existent apriori, nefacandu-se precizari asupra
modului in care s-a ajuns la obtinerea acestui obiect.
CONCEPT

SET DE OBIECTE
ARTIFICIALE

Fig. 3.2

Curs 3 ASSI (2005-2006)


Modul de identificare a setului de obiecte artificiale este un proces top-down, care in
situatia de fata nu mai este o etapa fara finalitate, un proces contemplativ, din contra, este un
proces activ prin care sunt create obiecte artificiale analoge cu cele naturale.
In capitolul anterior mentionam o etapizare care ne conducea de fapt de la concept la
produsul informatic, etapizare pe care o admiteam ca o ipoteza de lucru:
* tema de proiectare (realizare, determinarea utilizarii) careia ii corespunde in practica
curenta: studiul preliminar, studiul de fezabilitate, studiul tehnico-economic, etc.
* proiectarea logica de ansamblu si detaliu - proiectare logica - prin care se determina
cerintele si restrictiile logic-functionale globale, respectiv de detaliu, actiune finalizata in
modelul logic.
* proiectare tehnica de ansamblu si detaliu - proiectare tehnica sau de executie determina cerintele si restrictiile tehnice globale, respectiv de realizare de detaliu, finalizare
modelul tehnic.
* realizare produs.
Nu s-au retinut in contextul acestui capitol etapele de testare omologare, exploatare,
intretinere, etc.
Problema care se ridica intr-o analiza de sistem, in general in domeniul creativitatii
tehnice, consta in faptul ca desi literatura de specialitate consemneaza o serie de metode si
tehnici pentru obtinerea mai intii sub forma abstracta a modelului logic, apoi a modelului
tehnic si in cele din urma pentru realizarea fizica a acestui produs, totusi aceste metode si
tehnici nu pot fi general valabile. Ele sunt particularizate in functie de experienta dobandita
de catre analistul de sistem in functie de calitatile acestuia, cuma ar fi: puterea de analiza si
sinteza, spiritul de abstractizare, creativitatea, etc.
Avind in vedere afirmatiile de mai sus metodele si tehnicile, precum si etapizarile in
procesul de elaborare o unui produs informatic, le consideram orientative, proiectantul
urmand a le adopta in functia de complexitatea problemei abordate, de cerintele
beneficiarului, resursele disponibile, etc.
3.2 Modelarea sistemelor informatice sau a produselor program
O notiune esentiala in definirea unui produs informatic (sistem sau aplicatia
informatica, produs program) este notiunea de sistemul obiect. Pe acest sistem obiect se
grefeaza produsul informatic.
Sistemul obiect reprezinta o parte a realitatii care genereaza date si care poseda
calitati ce permit prelucrarea si atribuirea de semnificatie acestor date, transformindu-le in
acest fel in informatii.
Plecand de la aceasta notiune vom prezenta cateva aspecte legate de continutul
procesului de concepere, proces ce pune in evidenta citeva tipuri elementare de activitati de
modelare (fig 3.3.). Le vom prezenta in ordinea de abordare a lor in conformitate cu logica
procesului de cunoastere.
Modelul infologic este rezultatul obtinut prin modelarea structurii si dinamicii
sistemului obiect in scopul punerii in evidenta a corelatiei dintre obiectivele, cerintele
informationale si unor invarianti ai sistemului obiect.
Invariantii sistemului obiect au un rol deosebit in conceperea unui produs informatic
si provin din:
- partea informationala a procesului de productie (graful procesului, graful care
reprezinta structura produselor rezultate din proces).
- procesele decizionale (graful de structura organizatorica a unitatii de productie).
- activitatea de gestiune (relatiile furnizor-unitate sau unitate-beneficiari, relatiile
financiare plati-incasari).
2

Curs 3 ASSI (2005-2006)


In definitia modelului infologic termenul de dinamica are sensul de functionare a
sistemului ca un sens de evolutie in timp.
Modelarea infologica are drept obiectiv principal punerea in evidenta a cerintelor
informationale ale sistemului obiect, cerinte care trebuiesc indeplinite de viitorul produs
informatic. In felul acesta se pune in evidenta utilitatea produsului informatic.

Sistem
obiect

utilitate

Utilizator

Modelul infologic
cerinte informationale
ale SO

portabilitat

Modelul datalogic
posibilitati de realizare
a SI (optim tehnic)

fiabilitate

Modelul tehnic
Solutia tehnica concreta
de implementare a SI
(optim economic)

PERFORMANTE

SISTEM INFORMATIC
(SI)

Fig.3.3. Tipurile elementare de activitati de modelare


Modelarea datalogica reprezinta urmatorul pas firesc in logica procesului de
concepere a unui produs informatic, determinata de stabilirea unor mijloace adecvate, mai
performante, in raport cu cele existente, pentru satisfacerea cerintelor informationale ale
sistemului obiect.
Modelul datalogic este rezultatul obtinut prin modelarea structurii si dinamicii unui
sistem informatic sau produs program cu scopul atingerii, cu rezultate mai performante, a
cerintelor informationale ale sistemului obiect, fara a se lua in considerare insa mijloacele si
conditiile practice de construire a sistemului sau produs program.
Deci, la conceperea modelului datalogic, nu sunt luate in considerare tipurile de
echipamente, prelucrare si afisarea datelor, resursele financiare, umane si de timp, etc. Acest
model este insa necesar pentru a se crea posibilitatile de implementare a produsului
informatic pe diferite tipuri de echipamente, deci este o problema de portabilitate a
produsului realizat.
Avind in vedere evolutiile pe care le pot avea unele sisteme informatice sau produseprogram trebuie sa se asigure o portabilitate atat pentru sisteme informatice unicat sau
produse-program independente cat si pentru sisteme informatice tipizate sau produseprogram generalizabile.
Spre deosebire de modelul infologic care este orientat spre utilizator, modelul
datalogic este orientat spre o masina abstracta care sa satisfaca cerintele utilizatorului.
3

Curs 3 ASSI (2005-2006)


Modelul datalogic permite obtinerea unei imagini a sistemului informatic sau a
produsului program foarte apropiata de imaginea fizica.
Modelul tehnic (fizic) este rezultatul obtinut prin modelarea structurii si dinamicii
unui sistem informatic sau produs-program in scopul atingerii, cu rezultate mai performante,
a cerintelor informationale ale sistemului obiect, tinand seama de mijloacele si conditiile
practice de construire a sistemului informatic sau produsului program.
Se poate constata ca modelarea datalogica, in principiu, poate fi omisa, dar acest lucru
poate afecta portabilitatea. Acest procedeu se poate aplica, desi nu este recomandabil, pentru
produse-program simple, de tipul aplicatiilor independente, destinate unor cicluri de viata
scurta. In acest fel se poate reduce ciclul de realizare a unor astfel de produse-program.
Trebuie sa subliniem diferenta dintre modelul datologic si cel tehnic. Modelul
datalogic indica mijloacele potentiale de satisfacere optima a cerintelor utilizatorului, dand
contur imaginii unei masini abstracte. Modelul tehnic nominalizeaeza mijloacele concrete de
satisfacere a cerintelor utilizatorului, punand in evidenta masina reala.
Tipuri complexe de modelare
Combinarea tipurilor elementare de modelare cu abordarea top-down conduce la doua
tipuri complexe de modelare:de ansamblu si de detaliu.
De exemplu, pentru un sistem informatic cu complexitate apriorica data, apare
necesitatea de abordare conceptuala si practica pe subsisteme si esalonat. In acest fel in
cadrul modelarii de ansamblu se poate realiza secvential sau concurent o modelare pe tipuri
elementare de modele, urmand ca intr-o abordare de detaliu pentru fiecare subsistem
constituent, sa se realizeze de data aceasta in detaliu, modelele infologic, datalogic si tehnic.
In cazul produselor-program, data fiind complexitatea mai redusa a acestora in raport
cu sistemele informatice, se poate omite modelarea de ansamblu, trecandu-se direct la
modelarea de detaliu.
3.3. Generalitati privind aplicarea metodelor de realizare si obtinere a unui produs
informatic
In paragraful anterior se mentioneaza ca metodele top-down si bottom-up combinate
se pot aplica pentru obtinerea oricarui produs informatic. Realizarea practica a acestei
sugestii impune evidentierea unor caracteristici importante, de baza, a produselor informatice.
Sistemul total (STO) este un ansamblu constituit din urmatoarele subsisteme:
- sistemul procesual (SP) reprezinta procesul supus analizei de sistem in scopul
proiectarii si realizarii unui sistem informatic;
- sistemul de aprovizionare (SA) are rolul de a primi starea si furniza resursele
necesare functionarii SP;
- sistemul de transport (ST) asigura circulatia resurselor sau resurselor dinspre
exterior spre interiorul sistemului, respectiv dinspre interior spre exterior;
- sistemul suport (SS) asigura functionarea subsistemelor mentionate mai inainte, SP,
SA si ST;
- sistemul de mentinere (SM) asigura mentinerea in functiune a STO;
- sistemul de conducere (SC) coordoneaza functionarea tuturor celorlalte cinci
subsisteme mentionate anterior.
Un STO este caracterizat prin utilitate si prin performanta sa.
4

Curs 3 ASSI (2005-2006)


Utilitatea se concretizeaza prin ce realizeaza sistemul, iar performanta prin modul in
care utilitatea este indeplinita.
Pe un plan concret, utilitatea este un ansamblu de cerinte si restrictii impuse
functionarii sistemului de utilizator in scopul realizarii unor rezultate bine determinate. In
acelasi sens performanta este un ansamblu de cerinte si restrictii impuse de o functionare
optima a sistemului, in conditiile satisfacerii utilitatii.
Aceste doua aspecte, utilitate si performanta, pot fi corelate prin functia de eficientacost a unui STO, functie ce poate fi maximizata in anumite conditii concrete, de exemplu:
resurse limitate, resurse si costuri limitate, sistem suport impus sau limitat, etc. Aceasta
functie este un raport intre resursele exprimate valoric necesare pentru a realiza o utilitate si
performanta STO si respectiv, costurile totale ale STO (inclusiv cele de exploatareintretinere).
Este neindoielnic faptul ca un sistem informatic, datorita complexitatii sale este un
sistem total, care in cele mai multe cazuri are un caracter decizional. Acest lucru nu vine in
contradictie cu caracterul sau de entitate de sine statatoare, cu caracterul sau individual care
reflecta si este caracterizat de independenta in raport cu celelalte sisteme.
Individualitatea si independenta relativa a unui sistem informatic trebuie privita in
sensul cunoscut al individualitatii si independentei unui subsistem. In acest sens, considerarea
unui sistem informatic drept un sistem total, bine individualizat, este naturala, asa cum rezulta
din tabelul 3.1
Tabelul 3.1
TIP COMPONENTA
(STO)
SISTEM PROCESUAL
(SP)
SISTEM DE APROVIZIONARE
(SA)
SISTEM DE TRANSPORT
(ST)
SISTEM SUPORT
(SS)
SISTEM DE MENTINERE
(SM)
SISTEM DE CONDUCERE
(SC)

COMPONENTA ECHIVALENTA
(SI)
SISTEM SOFTWARE DE APLICATII
SISTEM DE GESTIUNE DE DATE
ANSAMBLU DE PROCEDURI MANUALE SI /
SAU MECANIZATE DE INTRARE-IESIRE
SISTEMUL HARDWARE SI O PARTE A
SISTEMULUI SOFTWARE DE BAZA
(SISTEMUL DE OPERARE)
ACTIVITATEA DE MENTINERE DE (SO)+(SA)
SI ACTIVITATEA SERVICE PENTRU (SS)
COMPONENTE ALE SISTEMULUI DE
OPERARE (MONITOR CENTRAL, MONITOR
DE INLANTUIRI,
PRECUM SI PROCEDURI DE PROIECTARE SI
REALIZARE PENTRU CONDUCEREA (SP)

In cadrul dualismului complex-individualitate sistemul informatic trebuie sa


indeplineasca anumite caracteristici, performante de baza:
- flexibilitatea definita prin capacitatea sistemului informatic de a se adapta la orice
modificare impusa de beneficiarul sistemului in sensul exploatarii acestuia;
- fiabilitatea este capacitatea sistemului informatic de a indeplini anumite functii sau
cereri fara erori;
- timpul de raspuns este definit ca intervalul de timp real, din momentul unei
excitatii exogene) si momentul realizarii complete a functiilor utilitare ale sistemului
informatic pentru setul respectiv de date; el poate fi echivalent, in majoritatea situatiilor, cu
durata regimului tranzitoriu;
5

Curs 3 ASSI (2005-2006)


- portabilitatea este o proprietate ce permite ca ansamblul SP+ SA+ ST+ SC+ SM sa
fie implementat pe diverse tipuri de SS.
* O problema deosebit de importanta in realizarea sistemelor informatice este cea a
integrarii acestora in sistemul obiect. Aceasta problema reflecta si se reduce, in ultima
instanta, la realizarea acesteia.
In paragraful anterior se facuse o delimitare clara intre utilitate si performanta. O
analiza mai fina ne arata ca aceasta delimitare trebuie sa fie nuantata.
Intr-adevar, vom intilni cel putin patru situatii in care un parametru ce defineste
performanta unui sistem informatic se transforma in utilitate:
a. Sistemele informatice destinate conducerii proceselor industriale trebuie sa lucreze
in timp real. Drept urmare, timpul de raspuns devine o cerinta utilitara.
b. Pentru anumite sisteme informatice cu destinatie speciala (din domeniul militar sau
cosmic, sisteme energetice nationale) se impune, pentru prevenirea avariilor ce conduc
implicat la catastrofe, o inalta fiabilitate. In felul acesta fiabilitatea este si o performanta si o
utilitate.
c. In cazul sistemelor informatice generalizate (sisteme cu aplicabilitate pentru o clasa
de sisteme) trebuie sa remarcam ca putem avea o gama larga de echipamente si, drept urmare,
portabilitatea in cazul acestor sisteme informatice e o conditie de utilitate si performanta.
d. Sistemele obiect mari necesita sisteme informatice mari deoarece acestea implica o
gama larga de prelucrari de date, avind in vedere evantaiul mare de cerinte si restrictii.
Realizarea acestui deziderat implica antrenarea unor importante resurse, deci investitii mari.
Este absolut necesar din punct de vedere economic ca aceste investitii sa fie recuperate
(amortizate in timp). Evident, acest lucru nu se poate face decit pe perioada de functionare,
deci pe durata de viata a sistemului respectiv. O analiza de sistem oricat de perfecta ar fi, nu
poate prevedea absolut intreaga problematica ce trebuie sa-i faca fata sistemul informatic
propus.
Este necesar ca sistemul informatic sa se adapteze la cerintele ce pot apare pe
parcursul duratei lui de functionare. Acest lucru face ca durata de viata a produsului
informatic, a sistemului informatic, sa se mareasca si sa creasca astfel posibilitatile de
recuperare a cheltuielilor ce s-au facut cu instalarea si punerea in functiune a lui. Acest lucru
presupune ca sistemul informatic dispune de o flexibilitate corespunzatoare. In astfel de
situatii flexibilitatea devine o cerinta utilitara.
* O problema interesanta este cea a integrarii interne a sistemului informatic.
Integrarea interna presupune determinarea unei structuri corespunzatoare pentru cele sase
componente ce constituie subsistemele unui sistem total. Dintre acestea, SP, SA si SC joaca
un rol principal deoarece conceperea, proiectarea si realizarea (sau alegerea) celorlalte trei:
ST, SM si SS. Este de retinut faptul ca daca ne referim la un produs program, in timp ce
structura datelor pentru SA poate fi privita relativ independent, structurile SP (software de
aplicatii) si SC (sistemul director) sunt intrepatrunse si formeaza un tot unitar.

3.4. Strategii de concepere si realizare a unui sistem informatic sau produs-program


Inainte de a se constitui o tehnologie de concepere sau realizare a unui produs
informatic concret este necesar sa se desfasoare o serie de activitati preliminarii:
- este necesar sa se delimiteze sistemul obiect, ceva ce creaza un cadru adecvat pentru
stabilirea problemelor de solutionat;
- se va face o identificare a caracteristicilor generale ale sistemului obiect pe care se
va "grefa" produsul informatic. In fond, produsul informatic este o actiune de informatizare a
6

Curs 3 ASSI (2005-2006)


unui domeniu de activitate sau a unor probleme sistem obiect. Pentru ca aceasta "grefa" sa nu
fie respinsa este necesar ca produsul informatic sa aiba caracteristici adecvate caracteristicilor
sistemului obiect. In tabelul 3.2 sunt date o serie de elemente relationale intre caracteristicile
sistemului obiect si caracteristicile produsului informatic.
Trebuie sa se evalueze personalul disponibil pentru realizarea produsului informatic
atat la cel ce elaboreaza acest produs, cat si la utilizator.
Realizarea sistemelor informatice presupune existenta si utilizarea unei tehnologii.
Tabelul 3.2.
RELATII INTRE CARACTERISTICI ALE SISTEMULUI OBIECT SI
CARACTERISTICI ALE PRODUSULUI INFORMATIC
Caracteristici sistem obiect

Caracteristici produs informatic


Originalitatea produsului informatic,
Noutatea domeniului problemelor supuse exprimata prin:
informatizarii in raport cu
- originalitatea solutiei
domenii / probleme deja informatizate
(arhitectura, algoritm)
- originalitatea facilitatilor oferite
Complexitatea produsului informatic:
Complexitatea domeniului / problemelor - aria functionala:
abordate
- complexitatea legaturilor logice intre
functiuni;
- gradul de integrare al componentelor;
- dimensiunea programelor
Caracterul restrictiv al
Caracterul critic al software-ului:
domeniului / problemelor
- performanta si calitate software;
- fiabilitate suport software
Tehnologia de realizare a unui sistem informatic este constituita dintr-un ansamblu
de procese (activitati), metode, tehnici si instrumente, ansamblu utilizat pentru obtinerea unui
astfel de sistem.
Principalele componente ale unei tehnologii de realizare sunt:
- procesul tehnologic cadru de realizare si intretinere este un ansamblu ordonat de
activitati/ subactivitati/ operatii, desfasurate in vederea obtinerii unui sistem
informatic.
- metoda de realizare este un ansamblu de concepte si reguli prin aplicarea carora se
poate realiza si conduce un sistem informatic.
- tehnologia de realizare este un ansamblu de reguli, compatibil cu una sau mai
multe metode care concura la desfasurarea unor activitati/ subactivitati/ operatii din
cadrul unui proces de realizare.
- instrumentul de realizare este un produs program constituit pe baza unei/ unor
metode si/ sau tehnici, prin intermediul careia unele activitati ale unui proces de
realizare pot fi asistate/ efectuate de calculator.
- principii de selectare si asamblare de elemente furnizate de cadrul tehnologic, intro tehnologie concreta.
Construirea unei tehnologii concrete de realizare presupune urmatoarele elemente:
- stabilirea unei strategii de realizare a produsului informatic;
- structurarea procesului tehnologic pe etape sau faze;
7

Curs 3 ASSI (2005-2006)


- definirea obligatorie la nivelul fiecarei etape a unor elemente esentiale: obiectul
etapei, conditiile de intrare in etapa, activitatile de conducere si executie, criteriile de
verificare, validare si testare, graful de inlantuire a activitatilor, produsele intermediare,
conditiile de iesire din etapa;
- stabilirea conditiilor de trecere de la o etapa la alta;
- evaluarea efortului de realizare pe etape;
- specificarea pe etape a metodelor, tehnicilor si instrumentului tehnologic utilizat.
Strategiile posibile de concepere, de proiectare a unui produs informatic au la baza
tipurile de modelare prezentate in paragraful anterior.
Practica curenta impune la stabilirea unei strategii adecvate luarea in considerare si a
altor factori decat cei prezentati inainte, factori ce sunt de natura practica.
3.4.1. Strategii de concepere a produselor informatice
Daca se priveste acest proces de concepere prin prisma celui care elaboreaza produsul
informatic, estimeaza si utilitatea sa, putem distinge urmatoarele tipuri de strategii de
concepere: strategia ameliorativa, strategia inovatoare si strategia adaptiva.
Strategia ameliorativa porneste de la premiza ca noul sistem informatic sau noul
produs-program nu introduce schimbari esentiale in structura si dinamica sistemului obiect (*
Prin dinamica sistemului obiect intelegem functionalitatea acestuia). Intrucat noul produs
informatic isi propune numai satisfacerea unor cerinte informationale imediate, el fiind mai
putin flexibil, el nu poate sa se adapteze unor eventuale schimbari in sistemul obiect,
devenind deci un produs perimat, uzat moral.
Datorita acestui fapt aceasta strategie poate fi adaptata doar pentru produse
informatice de complexitate redusa si utilizabile un timp scurt.
Utilitatea unor produse informatice realizate dupa aceasta strategie consta in
realizarea mai performanta a obiectivelor sistemului obiect, mai ales prin eliberarea de
activitati rutiniere a factorilor de decizie.
Din cele mentionate, rezulta ca ciclul de viata a produsului informatic este foarte
scurt. Este cazul unor aplicatii informatice sau produse-program independente.
Strategia ameliorativa presupune, in principiu, parcurgerea urmatoarelor etape:
- delimitarea sarcinilor om-masina, fapt ce se realizeaza prin cunoasterea
sistemului obiect, in special prin prisma proceselor decizionale si a activitatilor de
gestiune cu scopul de a se identifica functiile sau activitatile ce pot fi preluate
de sistemul informatic.
- proiectarea, construirea si implementarea noului produs informatic care sa preia
sarcinile stabilite in etapa anterioara.
- punerea in functiune, exploatarea si intretinerea produsului informatic.
Desi noul produs informatic nu produce schimbari structurale si dinamice in sistem,
grefarea acestui nou produs implica totusi o serie de modificari. Ele nu sint importante si cad,
in special, in sarcina utilizatorului.
Strategia ameliorativa prezinta o serie de avantaje cum ar fi:
- ciclu de realizare redus;
- cost scazut de realizare;
- o adaptare usoara a produsului informatic la sistemul obiect, dat fiind faptul ca
primul nu conduce la modificarea dinamicii sistemului obiect;
8

Curs 3 ASSI (2005-2006)


Dezavantajele acestei strategii le-am mentionat mai inainte: flexibilitate redusa
(neadaptari la schimbari ce pot apare in sistemul obiect) si deci o durata de viata redusa.

Strategia inovatoare
Aceasta strategie presupune ca introducerea unui nou sistem informatic sau produs
program conduce si la posibilitatea de aparitie a unor schimbari semnificative in sistemul
obiect, schimbari care pot fi atat structurale, cit si in dinamica acestuia.
Desi au o flexibilitate redusa, teoretic, aceste strategii sunt mai longevive deoarece
satisfac cerintele informationale si de perspectiva ale sistemului obiect, cerinte pe care de
altfel le si provoaca, in majoritatea cazurilor.
Aceste strategii pot fi etapizate in modul urmator:
- Cunoasterea sistemului obiect din punctul de vedere al proceselor informationale (in
sfera productiei si deciziei) si a obiectivelor sistemului obiect.
- Propunerea de variante imbunatatite de sistem obiect, operatie care trebuie inceputa
printr-o analiza critica a sistemului obiect existent, in scopul stabilirii deficientelor
acestuia.
- Proiectarea si construirea sistemului informatic sau a produsului program.
- Implementarea sistemului informatic sau a produsului program, concomitent cu
realizarea schimbarilor preconizate in sistemul obiect.
- Intretinerea si explotarea sistemului informatic sau a produsului program.
Aceasta strategie prezinta o serie de avantaje, cum ar fi: realizarea unei variante
imbunatatite de sistem obiect in care sistemul informatic sau produsul program se integreaza
perfect, aceste aplicatii informatice prezentand o longevitate ridicata.
Strategiile inovatoare prezinta si o serie de dezavantaje:
- necesita personal de inalta calificare si creativ, cu multa experienta;
- se prelungeste ciclul de realizare nepermis de mult;
- implica costuri de realizare mai mari;
- aplicatia informatica are o flexibilitate redusa;
- schimbarile in cadrul sistemului obiect intimpina obstacole serioase, mai ales de
natura psihologica.
Dezavantajele mentionate mai sus fac ca aceste strategii sa fie nerealiste.
Strategia adaptiva
Introducerea unui sistem informatic sau produs program nu trebuie sa introduca
perturbatii importante in cadrul sistemului obiect prin schimbari drastice: noua aplicatie
informatica trebuie sa raspunda atat cerintelor informationale actuale imediate, cat si celor de
perspectiva ale sistemului obiect, acest lucru realizandu-se printr-o adaptare flexibila.
Strategia adaptiva se caracterizeaza prin aceea ca noua aplicatie informatica trebuie sa
se adapteze foarte usor la schimbarile posibile, nefundamentale insa, ale sistemului obiect,
deci la cerintele informationale in evolutie. Ea s-a dezvoltat pe baza experientei cistigate in
aplicarea strategiei inovatoare, in special, pe baza esecurilor de aplicare a acestora din urma.
Daca strategia inovatoare urmareste sa produca, odata cu introducerea noii aplicatii
informatice, si modificari in sistemul obiect, strategia adaptiva isi propune sa faciliteze doar
anumite schimbari ale sistemului obiect, sa adapteze usor la aceste schimbari aplicatia
informatica, dar nu numai la acestea dar si la alte schimbari ce se pot ivi pe parcurs.
Aceasta strategie poate fi aplicata in urmatoarea etapizare:
- cunoasterea sistemului obiect in ansamblul sau pentru a se putea determina cerintele
informationale globale. In acest fel se poate structura aplicatia informatica pe un prim nivel,
9

Curs 3 ASSI (2005-2006)


punandu-se in evidenta interfata cu sistemul obiect (* Etapa aceasta permite sugerarea (nu
impunerea) unor schimbari la nivel global ce se pot realiza odata cu implementarea aplicatiei
informatice).
- prin detalierea cerintelor informationale ale sistemului obiect se poate trece si la o detaliere
succesiva ale componentelor de pe primul nivel ale aplicatiei informatice (sistem informatic
sau produs program) pana la punerea in evidenta a componentelor primitive. Acest lucru
permite o regandire a structurii primului nivel, reajustari minore, pentru a evita
incompatibilitatile ce ar rezulta la asamblarea componentelor realizate individual.
- construirea pe subsisteme a aplicatiei informatice, prioritate acordandu-se, ca si in cazul
precedent, bazei de date.
- exploatarea si intretinerea aplicatiei informatice, aplicatie ce poate intra in functiune
esalonat. Etapa aceasta dureaza pana la aparitia unor schimbari in sistemul obiect. De
remarcat este faptul ca aceste schimbari nu afecteaza substantial baza de date.
- modificari sau/si realizari de noi componente, diferite de baza de date, in functie de noile
cerinte informationale ale sistemului obiect.
Strategiile adaptive prezinta deci o serie de avantaje evidente, cum ar fi:
- realizarea de aplicatii informatice cu flexibilitate ridicata, deci cu longevitate mare,
fapt ce conduce la amortizarea integrala a investitiei si la obtinerea de beneficii;
- aplicatia informationala prezinta un grad ridicat de integrare interna prin date, ceea
ce conduce la performante ridicate in exploatare;
- nu necesita personal de inalta calificare, in special informaticieni cu bogata
experienta in explotarea unor sisteme obiect de tipul celui studiat;
- utilizatorul se familiarizeaza cu noua aplicatie informatica ca urmare a intrarii
esalonate in functiune a acestuia;
- integrarea si acceptarea usoara a aplicatiei in (si de catre) sistemul obiect.
Dintre putinele dezavantaje ale strategiei adaptive mentionam pe aceea care consta in
necesitatea ca baza de date a aplicatiei sa fie realizata de un grup restrins de specialisti cu
inalta clasa de profesionalism, cu capacitate mare de analiza si sinteza.
Strategiile adaptive isi dovedesc aplicabilitatea, in special, la conceperea unor sisteme
informatice.

3.4.2. Strategii de realizare a unui produs informatic


Pe baza identificarii si specificarii cerintelor informationale, de performanta si de
calitate ale produsului informatic si avand in vedere o posibila solutie tehnica de aplicat,
exista doua strategii de realizare a unui produs informatic:
- strategia clasica;
- strategia prototipizarii.
Selectarea strategiilor de realizare se poate face, orientativ, urmarind criteriile de
alegere din tabelul 3.3.
Strategia clasica
Realizarea produselor informatice conform acestei strategii impune respectarea
urmatoarelor principii:
- identificarea si specificarea tuturor cerintelor informatice, de performanta si de
calitate ale produsului informatic;
10

Curs 3 ASSI (2005-2006)


- delimitarea clara si precisa a domeniului de aplicabilitate a produsului informatic,
deci a problemelor ce pot fi solutionate;
- existenta unei experiente, din partea proiectantului in realizarea de produse informatice
similare atat in ceea ce priveste cunoasterea sistemului obiect, cat si a solutiilor tehnice
posibile de utilizat.

Tabelul 3.3
SELECTAREA STRATEGIILOR DE REALIZARE
Criterii pentru selectarea
unei strategii
1
Noutatea domeniului / problemelor supuse
informatizarii in raport cu domenii / probleme
deja informatizate
Gradul de previzibilitate a actiunilor / deciziilor
de identificat si / sau modelat
Complexitatea actiunilor / deciziilor de
identificat si / sau modelat
Gradul de integrare a componentelor (software /
hardware) ale produsului informatic
Gradul de familiarizare a utilizatorului final cu
folosirea tehnicii de calcul
Efortul pentru stabilirea solutiei
Gradul de familiarizare al echipei realizatoare
cu sistemul obiect
Experienta echipei in realizarea de produse
informatice similare
Existenta conditiilor de experimentare prototip
Gradul de fiabilitate, flexibilitate, eficacitate,
portabilitate a produsului informatic

Strategia
clasica
2

Strategia
prototipizarii
3

mica

mare

mare

mic

mica

mare

mare

mediu / mic

mare

mic

mic
mare

mare
mic

mare

mica

nu

da

inalt

scazut

Procesul tehnologic de realizare a produselor informatice este structurat, asa cum


aminteam, pe urmatoarele etape principale:
- elaborare tema de realizare;
- proiectare;
- elaborare programe;
- integrare si testare, unde etapa de proiectare poate fi privita ca o etapa unica sau ca
doua etape functie de complexitatea produsului informatic, si evident de tipul produsului
informatic: sistem (aplicatie) informatic sau produs program.
Fiecare etapa are ca obiect realizarea unui produs (tema de realizare, specificatie de
definitie, etc) cu o structura si continut bine definit. Etapele se termina cu o faza de control
care presupune verificarea si validarea produsului intermediar elaborat in cadrul fiecarei
etape.
De retinut este faptul ca, de regula, solutia obtinuta la nivelul unei etape prin produsul
acesteia este "inghetata", eventualele modificari ce pot fi solicitate la nivelul unei etape
11

Curs 3 ASSI (2005-2006)


netrebuind sa afecteze decat, cel mult, produsul (produsele) intermediar elaborat in etapa
anterioara.
In procesul de elaborare a unei aplicatii sau produs este de dorit sa fie implicat si
utilizatorul. Aceasta implicare nu se face in etapele de prioritate de detaliu, de elaborare
programe, de integrare si testare.
Utilizarea strategiei clasice permite realizarea produsului informatic in doua moduri
(fig. 3.4):
- integral si consta in identificarea si specificarea cerintelor informationale, a celor de
performanta si de calitate la nivelul produsului informatic, se proiecteaza arhitectura
produsului informatic si apoi toate componentele sale sint elaborate si testate in paralel, iar
integrarea lor se face intr-o singura etapa: de mentionat, ca etapele procesului tehnologic de
realizare sunt parcurse secvential, iar eventualele intoarceri se fac numai la etapa anterioara;
- prin incrementare functionala: totul decurge similar pana in faza in care
componentele sunt elaborate si testate, care aici se face gradat in timp, integrarea facandu-se
treptat, pe masura ce o noua componenta este finalizata: produsul informatic este realizat deci
printr-un proces tehnologic care presupune parcurgerea iterativa a etapelor de proiectare de
detaliu, realizarea de programe, integrare si testare, cu eventuale reintoarceri numai la etapa
anterioara.
Elaborare tema
de realizare
Control
Proiectare I
(produs informatic)
Control

Proiectare III
(componente)

Proiectare II
Componente 1

Control

Elaborare program

Proiectare II
Componente 2

Control

Realizare programe
componente 1

Control

Control

Realizare programe
componente 2

Control

Control

Integrare si testare
Componente 1+2

Integrare si testare
Control

Componente 3

Control

Integrare si testare
Componente 1+2+3
Control

realizare integrala
realizare prin incrementare functionala

12

Curs 3 ASSI (2005-2006)


Fig. 3.4
Utilizarea unuia dintre aceste doua moduri de realizare a produsului informatic se face pe
baza unor criterii specificate in tabelul 3.3
Strategia clasica prezinta o serie de avantaje:
- posibilitatea unei planificari si urmariri riguroase a activitatilor care vor fi executate
pe parcursul procesului de realizare;
- integrarea usoara a componentelor produsului informatic datorita unei proiectari
riguroase a interfetelor (atat interne, cat si catre utilizator) si a produsului propriu-zis.
Dintre dezavantajele strategiei clasice mentionam:
- utilizatorul nu poate evalua concret ce facilitati ofera noul produs informatic decat
dupa ce acesta este realizat si testat sau, eventual, treptat, pe masura ce acesta este
realizat (pe componente); ca urmare, si performantele si calitatile noului produs nu
pot fi determinate decat in fazele de testare.
- intrucit utilizatorul nu poate formula de la inceput toate cerintele, efortul de
intretinere a produsului informatic este foarte mare.
- daca costurile de realizare a produselor informatice nu sunt mari, cele de intretinere
sunt importante datorita dificultatilor in depistarea erorilor.
Strategia clasica impune un cadru ordonat si disciplinat de lucru pentru echipele de
analisti de sistem. Aceste echipe se recomanda a fi ordonate dupa metoda "programatorului
sef" sau dupa "metoda chirurgicala".
Tabelul 3.3
Criterii de stabilire a modului de
realizare a produsului informatic
(p.i.)
Complexitatea p.i.

Realizare integrala a
produsului informatic

Realizare p.i. prin


incrementare functionala

mica / medie

mare

Dimensiunea p.i.

mica / medie

mare

Numar personal de specialitate

mare / mediu

mediu / mic

da

nu / partial

mari

mici / medii

da

nu / in mica masura

Existenta / instalarea la utilizator a


tuturor echipamentelor din
configuratia specificata
Resursele umane ale utilizatorului
pentru a relua in exploatare p.i.
Existenta unor instrumente de
asistare a procesului de realizare
p.i.= produs informatic
Strategia prototipizarii

Este o strategie de structurare a procesului de realizare a unui produs informatic care


presupune respectarea urmatoarelor principii:
- desfasurarea procesului de realizare prin construirea uneia sau mai multor
prototipuri partiale, care sunt de fapt modele ale viitorului produs informatic, extinse
doar la un set semnificativ de functiuni/ facilitati ale acestuia: de obicei se iau in
13

Curs 3 ASSI (2005-2006)


consideratie functiuni/ facilitati critice (care se caracterizeaza prin aceea ca daca nu
sunt realizate corect afecteaza puternic functionalitatea intregului produs informatic);
-realizarea prototipului produsului final in urma experimentarii si/ sau dezvoltarii
prototipurilor partiale.
- definitivarea produsului informatic final in urma experimentarii prototipului sau.
Trebuie de mentionat de la bun inceput ca in functie de complexitatea produsului
informatic pot exista unul sau mai multe prototipuri partiale, disjuncte functional, pentru
acelasi produs informatic.
In general prototipul partial sau echipamentul (dispozitivul) pilot trebuie sa fie un
model al comportarii produsului final, produs care sa fie realizat rapid, fara cheltuieli mari
pentru a fi dat cat mai repede in exploatarea utilizatorului.
Exploatarea prototipului partial de catre utilizator permite precizarea cerintelor sau
stabilirea solutiilor reale si complete pentru produsul informatic final.
Utilizatorii prototipului partial pot fi:
- utilizatorii finali ai produsului informatic, care in acest fel isi pot preciza si
definitiva cerintele fata de produsul informatic.
- cei care elaboreaza produsul informatic pentru a alege solutiile cele mai eficiente
pentru realizarea acestuia.
Realizarea de prototopuri partiale se recomanda in urmatoarele doua situatii:
- pentru precizarea si definirea cerintelor fata de produsul informatic.
- pentru alegerea solutiei de elaborare a produsului informatic.
Dupa realizare, produsul informatic este pus in functiune (integral sau componenta cu
componenta), experimentat, iar dupa acceptare omologarea lui intra in exploatare/ utilizare
curenta.
Principalele obiective ale acestei strategii sunt:
- diminuarea numarului de modificari din categoria celor cauzate de proaste definiri
sau intelegeri a cerintelor sau solutiilor necesare de operat dupa livrarea produsului
informatic;
- folosirea prototipului partial pentru ca utilizatorul sa obtina experienta in folosirea
tehnicii de calcul si in stabilirea totodata a unor cerinte de utilizare mai elaborate (mai
rafinate).
Odata folosit ca experienta, prototipul partial poate fi abandonat sau convertit in
produsul informatic dorit sau in prototipul final.
O organigrama generala a strategiei prototipizarii este prezentata in fig. 3.5.

14

Curs 3 ASSI (2005-2006)


Elaborare tema
de realizare

Proiectare
Elaborare
Elaborareprograme
programe
(prototip partial)
Control
Testare
(prototip partial)
Control
"convertire"

"abandonare"

prototip partial

realizarea produselor
informatice prin
strategie clasica
Elaborare programe
Control
Integrare si testare
Control

Fig. 3.5

15