Documente Academic
Documente Profesional
Documente Cultură
Microsoft Word - Unitatea1
Microsoft Word - Unitatea1
Unitatea de nvare 1
Tipologia,arhitecturasi
proceselededezvoltare
asistemelor
informaticedegestiune
gestiune;
procedurile urmate;
resursele puse n lucru.
Figura Error! No text of specified style in document..3. Structura generic a SIG pentru
contabilitate
n realizarea unui sistem informatic, se poate opta pentru una din urmtoarele soluii
arhitecturale:
sistem informatic centralizat;
sistem informatic descentralizat.
introducerea sa. Deine, n ansamblul existenei sistemului, durata cea mai mare i ia sfrit
odat cu scoaterea definitiv din funciune i nlocuirea cu un alt sistem.
n cursul exploatrii curente apar situaii care solicit intervenii de meninere n
funciune a sistemului. Acestea sunt determinate de dou cauze principale:
erori nesesizate n procesul dezvoltrii, care trebuie eliminate;
schimbri survenite n timp, la care sistemul trebuie s se adapteze, cum sunt
cele produse de evoluia tehnologiilor folosite (echipamente i programe).
Definirea cerinelor
Cerinele descriu comportamentul dorit al viitorului sistem, prin specificarea serviciilor
pe care acesta urmeaz s le asigure i al condiiilor i restriciilor de funcionare.
Definirea cerinelor este procesul n care beneficiarii sistemului i echipa de dezvoltare
stabilesc mpreun i convin asupra produsului care urmeaz a fi realizat. Din perspectiva
beneficiarilor, se pot distinge dou categorii de cerine: de business i de utilizare.
Teoretic, proiectarea, construcia i testarea ar trebui s respecte n totalitate
specificaia definit i aprobat mpreun cu beneficiarul, pentru a obine software-ul i
sistemul dorite. Practic a demonstrat ns c aceast aseriune, n care specificaia este
complet i rmne valabil pn la obinerea i livrarea sistemului, este nerealist.
Principalele motive ale acestei stri de fapt sunt urmtoarele:
cererile se modific n timp ce are loc proiectarea, construcia i tastarea
sistemului, din cauza schimbrilor survenite n mediul socio-economic n care
opereaz organizaia, n obiectivele managementului, n legislaia n vigoare,
.a.m.d.;
cererile formulate iniial sunt incomplete sau nu reflect nevoile reale ale
utilizatorilor, deoarece acetia nu realizeaz, dect dup ce iau contact cu
viitorul sistem sau cu o parte a acestuia, noile condiii de funcionare,
posibilitile i oportunitile oferite;
cererile nu sunt corect interpretate i nelese din cauza dificultilor de
comunicare dintre utilizatori i echipa de dezvoltare: semnificaia precis a
termenilor i conceptelor de specialitate folosii de fiecare dintre pri poate s
scape celeilalte, din cauza formaiei i experienei lor profesionale diferite.
Constituind fundamentul viitorului sistem i confruntndu-se cu dificultile obiective
menionate, definirea cerinelor este considerat un proces critic pentru dezvoltarea
sistemelor informatice iar gestionarea sistematic, coordonat i controlat a dinamicii
cerinelor i ajustrii software-ului n curs de realizare la acestea contureaz un domeniu
distinct de preocupare managementul cerinelor.
Proiectarea
Proiectarea are menirea de a defini o soluie informatic care s rspund cerinelor
utilizatorilor. Aceasta nseamn transpunerea cerinelor ntr-un ansamblu de uniti de
program (sau de programe) i de date folosite de ctre acestea, care s fie executabile pe
tipul de platform i configuraia avute n vedere.
Definirea cerinelor este procesul prin care viitorul sistem informatic sau software-ul de
aplicaie este descris sub aspectul comportamentului pe care ar trebui s-l aib fa de
utilizatori i fa de restul sistemelor, de toate tipurile, pe care le va utiliza sau cu care va
Construirea
Construirea (numit de asemenea, implementare), pornete de la elementele definite
n cursul proiectrii i asigur crearea programelor de calculator i a procedurile informatice
necesare, pn la forma final, cea executabil.
Scrierea programelor este departe de a fi o munc mecanic. naintea formulrii n
structurile sintactice cerute de limbajul de programare folosit, orice situaie, orice aciune,
orice funcionalitate trebuie gndit, rafinat n cele mai mici detalii. Ceea ce la nivelul
proiectrii face obiectul unei fraze sau aseriuni, poate genera, la nivelul scrierii programului,
mai multe module, avnd fiecare zeci sau sute de linii de cod. Acest efort de detaliere, de
rafinare, de definire este, de asemenea, de natura proiectrii, dar pe un alt nivel i la o alt
scar.
Trecerea n forma executabil a textului de program surs este automatizat, fiind
efectuat de programe de calculator specializate i, n funcie de mediul informatic utilizat,
trebuie cerut explicit sau se poate realiza implicit, n total transparen pentru cel care
lucreaz.
Testarea
Testarea este cea care face validarea proiectrii i se afl, n consecin, n aceeai
situaie: pentru a fi realizat, trebuie conceput n prealabil, i aceasta n strict corelaie cu
modul n care s-a proiectat funcionarea sistemului, de la nivelul cel mai general pn la cel
mai detaliat.
Disfuncionaltile i erorile constatate la testare sunt nlturate prin modificarea
adecvat a programelor surs, dup care noile programe sunt aduse din nou n forma
executabil i verificate i acest ciclu se repet pn cnd se ajunge la funcionarea dorit.
Identificarea sursei erorilor i disfuncionalitilor i nlturarea lor presupune revenirea
la oricare dintre nivelele de proiectare, inclusiv la programele surs i implic un efort
creator, care conduce la ajustarea, la amelioarea proiectului.
Dup ce programele surs au fost testate i corectate (puse la punct), se genereaz
formatul executabil final, ce se livreaz alturi de documentaia de utilizare i de exploatare
a sistemului.
Cerinele formulate pentru viitorul sistem sunt reprezentate n modelul conceptual. Din
acesta deriv, prin transformare i detaliere, modelul logic al sistemului. Urmeaz adaptarea
modelului logic la particularitile platformei/platformelor adoptate pentru realizare i
execuie i dezvoltarea detaliilor necesare pentru construcia sistemului.
Definirea cerinelor este, din aceast perspectiv, procesul dedicat modelrii
conceptuale a viitorului sistem. Nivelele logic i fizic delimiteaz dou stadii succesive ale
proiectrii, numite, respectiv, proiectare general i proiectare de detaliu. Proiectarea
general mai este denumit "de ansamblu" iar proiectarea de detaliu mai este denumit
"tehnic".
1.3.6.2 Modelul n V
Modelul n V este o variant a modelului cascad care aduce elemente calitative noi
importante. Un element caracteristic al modelului este introducerea conceptelor de sistem i
component (subsisteme) aplicndu-se teste explicite pentru creterea controlului asupra
modului n care se desfoar etapele. Fazele plasate n partea superioar a modelului se
caracterizeaz prin implicarea direct a viitorului utilizator.
Braul stng al diagramei, parcurs descendent, reunete fazele n cadrul crora se
realizeaz, pas cu pas, proiectarea i realizarea sistemului informatic. Detalierea
activitilor de proiectare, codificare i asamblare a componentelor se realizeaz gradual.
Braul drept al diagramei cuprinde reprezentarea fazelor asigurnd asamblarea
progresiv a componentelor sistemului pe msura testrii lor individuale, pn la obinerea
sistemului global i acceptarea acestuia de ctre beneficiar.
n cadrul modelului se remarc realizarea distinciei dintre verificare i validare. Prima
se refer la testarea sistemului n diversele stadii pe care le parcurge, iar validarea
urmrete s identifice n ce msur sistemul corespunde cerinelor iniiale, ceea ce
constituie un punct slab al modelului datorit ntrzierii cu care se produce aceast
validare.
analiza riscurilor;
realizarea unui prototip;
simularea i testarea prototipului;
determinarea cerinelor n urma rezultatelor testrii;
5. validarea cerinelor;
6. planificarea ciclului urmtor.
Ultimul ciclu conduce la realizarea versiunii finale a sistemului informatic.
n centrul spiralei este plasat cunoaterea cerinelor i estimarea costurilor la nivel
preliminar. Evoluia SIG urmeaz desfurarea spiralei nregistrnd acumulri succesive ale
costurilor i este marcat de succesiunea prototipurilor, fiecare dintre acestea valorificnd
acumulrile realizate al nivelul prototipului anterior. Interaciunea dintre faze nu este
reliefat direct atta timp ct modelul prevede o succesiune continu a rafinrii legate de
decizii pe care riscurile proiectului le asociaz cu urmtoarea detaliere.
Modelul evideniaz atenia acordat planificrii, cutrii de soluii alternative,
evalurii riscurilor i validrii soluiilor pentru fiecare prototip, vzut ca un stadiu distinct n
realizarea sistemului informatic.
Prototipul este folosit att pentru identificarea ct i pentru validarea cererilor
utilizatorilor, pentru verificarea soluiei de proiectare i constituirea bazei dezvoltrii
ulterioare a proiectului de sistem informatic. Apelarea la prototip se explic prin aceea c un
model funcional este mai uor de neles de ctre viitorul utilizator dect un set de diagrame
nsoite de documentaie.
Prototipul funcional presupune proiectarea sistemului, realizarea primului prototip
funcional, verificarea msurii n care rspunde cererilor formulate de utilizator i rafinarea
acestei prime soluii, prin dezvoltri viitoare care adaug noi funcionaliti pn la obinerea
variantei finale a sistemului.
instalarea la utilizator.
n timp, s-au conturat mai multe curente de gndire care au promovat i dezvoltat
diverse metode de proiectare.
O clasificare bazat pe cronologie include:
metode timpurii, metode nestructurate specifice perioadei 50 60;
metode orientate spre ieiri (sfritul anilor 60) caracterizate prin faptul c
proiectarea sistemului informatic avea ca punct de plecare ieirile pe care
acesta trebuia s le asigure: rapoarte, grafice etc. Pe baza ieirilor
identificate se determinau apoi datele de intrare i prelucrrile;
metode orientate spre procese, utilizate n deceniul apte, prezentnd
drept caracteristic utilizarea diagramelor fluxurilor de date;
metode orientate spre date, specifice anilor 80, prezentnd ca element
caracteristic utilizarea diagramelor entitate-relaie;
metode orientate obiect promovate n anii 90 caracterizate prin
promovarea conceptului de obiect care ncapsuleaz date i metode.
O alt clasificare, bazat pe paradigma conform creia este perceput sistemul,
evideniaz:
metode ierarhice (generaia I a metodelor de proiectare);
metode sistemice (generaia a II-a);
metode obiectuale, numite i metode orientate obiect (generaia a III-a).
Metodele ierarhice au la baz analiza funcional a ntreprinderii. Astfel, sistemul
informatic cuprinde n arhitectura sa subsisteme definite la nivel de funcii ale ntreprinderii.
Cum fiecare funcie este subdivizat ierarhic n subfuncii, iar acestea la rndul lor, se
descompun succesiv pn la definirea unor componente elementare uor de programat,
arhitectura SI va urma aceast ierarhie, fiecare component a sa acoperind o subdiviziune
funcional.
Avantajele metodelor ierarhice constau n simplitate i o bun adaptare la cerinele
formulate de utilizator.
Dezavantajele pornesc de la concentrarea efortului de analiz i proiectare asupra
prelucrrilor n condiiile n care, tocmai acestea sunt cele mai expuse la modificri n timp.
Metodele sistemice se bazeaz pe aplicarea teoriei sistemelor n descrierea
funcionrii ntreprinderii. Sistemul informatic este abordat sub dou aspecte
complementare datele i prelucrrile analizate i modelate independent, reunirea celor
dou modele realizndu-se ct mai trziu cu putin.
Spre deosebire de metodele ierarhice, metodele sistemice acord prioritate datelor
fa de prelucrri i respect cele trei niveluri de abstractizare introduse de raportul
ANSI/SPARC: conceptual, logic, fizic.
Avantajele metodelor sistemice decurg din promovarea tehnologiei bazelor de date.
Dezavantajele sunt datorate deficienelor care pot aprea n modelarea prelucrrilor i a
riscului apariiei unor discordane ntre modelele datelor i prelucrrilor.
Metodele obiectuale sau bazate pe obiecte au fost formulate la nceputul anilor
80. Dup o perioad iniial, n cursul creia s-au propus mai multe metode diferite, s-a
ajuns la o selecie a celor mai bune practici, larg acceptat, pornind de la care s-a definit un
cadru unificat de modelare denumit UML Unified Modeling Language i un proces unificat
corespunztor.
Caracteristic acestor metode este faptul c SIG este conceptualizat ca un ansamblu
de obiecte autonome, care se organizeaz i coopereaz ntre ele. Pentru prima dat,
datele i prelucrrile (metodele) se gsesc n cadrul aceleiai structuri, denumite obiect.
Fiecrui obiect i este caracteristic un anumit comportament, definit prin ansamblul
operaiilor pe care le poate realiza. Datele i prelucrrile sunt ncapsulate n cadrul
obiectului.
Avantajele metodelor obiectuale decurg din posibilitatea reutilizrii componentelor
de program, n mod direct sau prin mecanisme mai mult sau mai puin evoluate de
motenire i din posibilitatea compunerii, simple i sigure, de obiecte complexe prin
asamblarea obiectelor existente.
Dezavantajele acestor metode decurg din faptul c nu ntotdeauna reprezentarea sub
form de obiecte este natural, adecvat sau avantajoas.
definirea necesitii/oportunitii;
obinerea;
introducerea n exploatare;
exploatarea curent;
meninerea n funciune.
definirea cerinelor;
proiectarea;
construirea;
testarea.
managementul proiectului;
managementul calitii;
verificarea i validarea;
gestiunea configuraiei;
documentarea.
modelul n cascad;
modelul n V;
modelul incremental;
modelul spiral;
dezvoltarea rapid RAD.
1.6 Bibliografie
Zaharie, D., Roca, I. (2002), Proiectarea obiectual a sistemelor informatice", ed. Dual
Tech, Bucureti
Anica-Popa, L.-E. (2005), Conducerea intreprinderii prin costuri: recursul la modelele
contabilitatii manageriale: cazul metodei ABC-Activity Based Costing, Editura Economica,
Bucureti
Rspunsuri grile:
1-c
2-e
3-b
4-d
5-e