Victor Beliu

Pavel Chirev
PROIECTARE SISTEME INFORMAIONALE
Suport de Curs

PSI PARTEA I
TEMA 1.
1.1. Noiuni generale. 1.2. Principii de baz la proiectarea sistemelor informaionale. 1.3.
Clasificare Sisteme Informaionale conform destinaiei. 1.4. Abordri arhitecturale n
realizarea sistemelor informaionale.
Coninutul cursului.
n acest curs se vor reflecta unele probleme legate de managementul proceselor de proiectare
a sistemelor informaionale, despre modul de alegere a variantei de proiect optim i modul de
ntocmire a unui proiect informaional.
Vor fi prezentate i studiate standardele i metodele de modelare i proiectare a sistemelor
informaionale
Se vor prezenta ciclul de via a prodiselor informatice, etapele de proiectare, fazele aferente
acestora i procesele etapelor de proiectare, nu se va insista la detalierea amnunit a
acestora, doar la nivelul cerut pentru a forma un analist de sistem.
Vor fi prezentate unele instrumente de modelare i proiectare a sistemelor informaionale
Obiectivele cursului:
familiarizarea studenilor cu metodele de analiz i modelare a sistemelor
tehnico-economice complexe i metodele de proiectare a Sistemelor
Informaionale, bazate pe standarde naionale i internaionale,
nsuirea principiilor construirii modelelor funcionale i informaionale,
modalitilor de analiz a rezultatelor obiinute,
utilizarea mijloacelor instrumentale de asistare n proiectarea Sistemelor
Informaionale.
Pregtirea inginerilor n domeniul Tehnologiei Informaiei i pregtirea
analiilor de sisteme informaionale
Baza tiinific - analiza de sistem i modelarea.

1.1. Noiuni generale

1.1.1. Noiune de Inginer i inginerie
 Un inginer este o persoan cu o pregtire tehnic - teoretic i practic, obinut ntr-
un institut de nvmnt superior n care se studiaz ingineria (aplicarea cunotinelor
tiinifice, matematice economice, sociale, practice asupra realitii materiale i/sau sociale n
vederea proiectrii, executrii, intreinerii, modificrii unor structuri i/sau ansamble care s
fie capabile s furnizeze/genereze rezultate, produse, procese i/sau efecte predefinite i/sau
conforme unor ateptri predictibile i/sau controlabile.
Spre deosebire de oamenii de tiin, care studiaz natura i fenomenele naturale
pentru a stabili principii, axiome i teoreme, inginerii aplic principiile teoretice din
matematic, fizic, chimie i alte tiine fundamentale pentru a crea un produs concret, ca de
exemplu un rulment sau o tastatur de calculator sau un sistem informaional.
Inginerul este persoana care practic o activitate de inginerie. Cuvntul inginerie
provine de la ingenious avnd diverse forme de definire. n [1.23] ingineria se definete :
..aplicaii ale tehnicii i matematicii n scopul i utilitatea populaiei ;
..proiectarea i fabricarea de produse complexe . n [1.24] se dau o serie de citate referitor
la aceast noiune dintre care prezentm doar unul : ingiineria este arta sau tiina de a face
util (Samuel C. Florman).
Ingineria acoper un domeniu foarte larg de activitate: de la agricultur la construcii navale,
de la microelectronic la transporturi. n fiecare zi o serie de aplicaii au un rol ingineresc. Nu
se poate vorbi despre o entitate fizic sau artificial n care s nu se nglobeze i o activitate
de inginerie.
n tabelul 1.1 se prezint funciile i coninutul activitilor de inginerie.

1.1.2. Conceptul de proiectare

Proiectarea reprezint o etapa care, dei este mai puin spectaculoas, transform o idee
geniala n realitate. Indiferent de domeniu, un concept rmne doar la nivelul de diamant n
stare brut dac nu intervine bijutierul - proiectantul pentru a finisa i lefui ct mai multe
faete, fcndu-l nepreuit.
Proiectarea pune la dispoziie manualul de utilizare pentru orice fantezie n domeniul
tehnic.
Ce inseamn sa fii proiectant?
Proiectantul trebuie perceput ca o persoana cu mintea deschisa si cu o capacitate deosebita de
a nelege lucruri, situaii, procese, posibiliti. Numai o asemenea persoana poate s
transpun in practica ceea ce uneori pare ceva science fiction.
Ce aptitudini trebuie sa ai pentru a deveni proiectant?
Proiectantul trebuie sa studieze permanent, sa fie perseverent, sa fie rbdtor, sa fie inventiv
si, nu in ultimul rnd, sa fie curajos si cu personalitate pentru ca astfel poate gsi soluii
optime pentru orice problema.

Fig. 1.1. Etapele procesului creativ

Fig. 1.2. Dimensiunile creativitii

1.1.3. Noiuni de baz ale sistemelor
Noiunea de Sistem, Sistem Informaional, Sistem Informatic,
Sistem Cibernetic.
Conceptul de sistem apare in forma embrionara nc din filozofia antic greac. Afirmnd c
ntregul este mai mult decat suma partilor, Aristotel da o prim definite noiunii de sistem,
care se va dezvolta i va evolua pentru a ajunge la forma actual de abia la inceputul secolului
XX.
Cel care pune bazele unei teorii inchegate privind teoria sistemele (este considerat fondatorul
teoriei generale a sistemelor) este biologul german Ludwig von Bertalanffy (1901-1972) care
intre anii 1928 si 1950 public o serie de lucrri reprezentnd nceputurile teoriei generale a
sistemelor i a sistemelor deschise. Astfel, el a dedus principiile universale care sunt valide
pentru sisteme in general. In acest sens L. von Bertalanffy a reformulat mai nti conceptul
clasic al sistemului i l-a determinat drept o categorie prin care se cunosc relaiile dintre
obiecte si fenomene.
Conceptul nou dat sistemului reprezint un set de componente interdependente, o entitate
complex n care spaiul-timp arat asemnrile structurale.
Ludowig Van Bertalanffy, este considerat printele teoriei sistemelor, el definete sistemul ca
un ansamblu de elemente aflate n interaciune.
n accepiunea teoriei matematice a sistemelor, informaia e considerat expresie a ordinei i
organizrii, ce este specific fiecrui subsistem n parte.
Putem demonstra c formula informaiei este identic cu formula entropiei descoperit de L.
Baltzmann, adic cu: H =- pklog2pk (N >1), unde pk este probabilitatea de realizare a unui
eveniment k din sistem sau subsistem.
O. Onicescu n 1979 arat c gradul de organizare a unui sistem poate fi msurat cu ajutorul
energiei informaionale, astfel: E = pj2(A) , unde pj este probabilitatea de apariie a
evenimentului A.
Informaia, copie a revoluiei tiinifice i tehnice contemporane, se poate considera
ca o noiune foarte veche, nelegerea acesteia depinde de semnificaia ce i se poate
atribui: ca suport al cunotinelor umane, ca bii i alte uniti de msur specifice
informaticii.
Teoria sistemelor arat c sistemele au urmtoarele principii: coordonabilitate,
incompatibilitate, optimalitate i incertitudine.
Coordonabilitatea ne arat ca reglarea centralizat a unui sistem complex, dac ea
este posibil, nu este avantajoas, datorit proceselor ce trebuie s fie reglate, a
contradiciilor i a neliniaritii lor.
Incompatibilitatea, arat cci cu ct complexitatea sistemului este mai mare, cu att
scade posibilitatea de a-l descrie n mod riguros.
Optimalitatea, arat c dac un subsistem al uni sistem complex nu este optimal n
relaiile sale cu celelalte subsisteme, atunci nici sistemul complex nu mai este optimal.
 Incertitudinea ne relev c ntr-un sistem complex, starea unui subsistem i
interaciunea sa cu celelalte subsisteme poate fi simultan determinat numai pn la un
anumit grad de acuratee.
Teoria sistemelor recunoate c dup mulimea elementelor i relaiile cu mediul, dup
factorul timp, dup coeficientul de complexitate i dup natura relaiilor dintre mrimile de
intrare i cele de ieire, sistemele pot s fie: finite sau infinite, nchise sau deschise, statice sau
dinamice, simple sau complexe, determinate sau probabilistice, liniare sau neliniare, etc.,
aceast clasificare a fost fcut de Grunberg n 1977.
Fiecare sistem poate fi un subsistem i fiecare subsistem poate face parte din mai
multe sisteme, devine necesar o abordare mult mai larg, deci una interdisciplinar.
Abordarea cibernetic a sistemelor
Aprecierea sistemelor cibernetice este n direcia nlturrii factorilor perturbatori ce
acioneaz asupra sistemelor.
Autoreglarea, const n existena unei bucle de reacie, deci un mecanism de reglare n
circuit nchis sau feed-back.
Deci, orice sistem are o intrare x, o ieire y, comparat cu o funcie obiectiv z.
Diferena y, feed-back-ul, dintre funcia obiectiv z i ieirea propriu-zis y acioneaz
ca element reglator asupra intrrii x, deci noua intrare devine x + y.
Principiul de integrare
Pe lng organizare, sistemele tind i spre o integrare din ce n ce mai complex.
Orice sistem este un subsistem al unui sistem mai mare, astfel: S1 < S2 < < Sn.
Fiecare sistem (S1, Sn) de la un anumit nivel de organizare, este format dintr-o
reuniune de subsiteme de ordin inferior, astfel: Si = S1 S2 Sn.
Integrarea este necesar, deoarece unele subsistemele nu pot fi concepute n afara sistemului.

Fig. 1.3. Sistem cibernetic

Tipuri de integrri
Integrarea genetic, care se bazeaz pe capacitatea sistemului, pe lng cea de organizare, s
aib i pe cea de autogenerare.
Integrarea prin constrngere, poate fi ntlnit la toate nivelurile de organizare a materiei,
inclusiv la cele economice.
 Integrarea prin dependen, se refer la elementele unui sistem care continu s rmn n
cadrul lui, pentru c depind, ntr-un fel sau altul de alte elemente.
Integrarea la alegerea, const n posibilitatea elementelor de a alege sistemul cruia s-i
aparin.
Integrarea la ntmplare, se refer la posibilitatea elementelor de a face parte dintr-un sistem
sau altul, pe baza unei ntmplri.
Tipuri de sisteme
In funcie de criteriul de clasificare utilizat, sistemele sunt de mai multe tipuri:
dup natura lor:
- sisteme naturale (organismele vii);
- sisteme elaborate (tehnice, economice, conceptuale aici se regasesc sistemele
informationale);
dup modul de functionare:
- deschise (iesirile nu influenteaza intrarile);
- inchise (intrarile sunt influentate de catre iesiri);
dup comportament:
- deterministe (se cunosc intrarile, iesirile, si regulile care leaga intrarile de iesiri);
- probabilistice (nondeterministe, incerte).

Sistemul informaional: concept i structur

Conceptul de sistem informaional i structura sa este pe deplin justificat prin cel puin
argumente ca:
- acest concept a fost definit n funcie de specializarea autorilor i de contextul
determinat de tipul lucrrilor elaborate;
- traducerea nu chiar exact, a unor concepte din literatura strin i de introducerea de
neologisme n limba romn ce nu corespund coninutului ce-l reprezint;
- abordarea nc firav a problematicii complexe referitoare la proiectarea i realizarea
sistemelor informatice.
V. Marinescu i I. Faur dau urmtoarea definiie: sistemul informaional este un
ansamblu organizat i integrat de date i informaii, precum i procedurile i mijloacele pentru
colectarea, prelucrarea i transmiterea acestora.
Alquier i Barthet definesc sistemul informaional astfel: ansamblu de informaii
manipulate ntr-o firm.
Lemoigne definete sistemul informaional astfel: un sistem de cuplaj ntre sistemul
operant i sistemul de pilotaj.
Sistemul informaional este un ansamblu organizat de resurse: materiale, de personal, date,
mijloace i proceduri de culegere, memorare, procesare i comunicare a informaiilor,
precum i circuitele informaionale utilizate.
Un sistem reprezint un ansamblu de elemente (componente) interdependente ntre
care se stabilete o interaciune dinamic, pe baza unor reguli prestabilite, cu scopul
 atingerii unui obiectiv . Conform teoriei sistemelor orice organism economic ( Unitate
Social Economic) este un sistem.
Unitate Social Economic ntreprindere, instituie, societate comercial, unitate
administrativ teritorial.
n orice Unitate Social Economic se disting 3 componente:
- sistemul de conducere sau de decizie
- sistemul informaional
- sistemul decizional
Orice Unitate Social Economic interacioneaz cu mediul exterior (alte organizaii
externe) primind informaii din exterior i furniznd informaii ctre lumea exterioar.

Fig. 1.4 Interaciunea Unitii Social Economic cu mediul exterior.

In cadrul unui organism social-economic complex, apar trei sisteme: sistemul de

conducere/decizional, sistemul condus/operational si sistemul informational. In continuare ne
vom axa pe cel de-al treilea sistem, cel informational.

Poziia Sistremului Informaional ntr-o Unitate Social-economoc

Fig. 1.5. Poziia Sistremului Informaional ntr-o Unitate Social-economoc

1.1.4. Sisteme informaionale i sisteme informatice
Sistemul informaional cuprinde ansamblul informaiilor interne i externe utilizate n
cadrul organizaiei precum i datele care au stat la baza obinerii lor, procedurilor i
 tehnicilor de obinere a informaiilor, precum i personalul implicat n culegerea,
transmiterea, stocarea i prelucrarea datelor.
Sistemul informaional are dou componente:
Componenta pentru stocare datelor;
Componenta pentru prelucrarea informaiilor.

Figura 1.6. Poziia sistemului informatic n cadrul sistemului informaional

Sistem informaional definiie.
Dintre cele mai corecte moduri de definire a sistemului informaional putem evidenia:
Sistemul informaional poate fi definit ca - ansamblul datelor, informaiilor, fluxurilor i
circuitelor informaionale, procedurilor i mijloacelor de tratare a informaiilor menite s
contribuie la stabilirea i realizarea obiectivelor instituiei, precum i personalul implicat n
culegerea, transmiterea, stocarea i prelucrarea datelor.
Sistemul informaional al unui organism (activitate) este - ansamblul informaiilor, surselor
de informaii i nivelurilor receptoare, canalelor de circulaie, procedurilor i mijloacelor de
tratare a informaiilor precum i personalul implicat n culegerea, transmiterea, stocarea i
prelucrarea datelor din respectivul organism.
Dac avem n vedere i resursele umane, respectiv specialitii n domeniul informaticii, o
definire mai complet ar fi aceea n care sistemul informaional este - un ansamblu
organizatoric format din totalitatea metodelor, procedeelor, mijloacelor i specialitilor care
asigur culegerea, prelucrarea, transmiterea i acumularea informaiilor cu privire la
fluxurile de bunuri materiale i informaionale ce au loc n cadrul sistemului Unitii
Social-economice.
n cadrul unui sistem informaional, majoritatea activitilor se pot desfura cu ajutorul
tehnicii de calcul. Se pot prelucra datele primare i apoi rezultatul poate fi transferat mai
departe, ctre alt compartiment spre prelucrare. Transferul se poate face i el pe cale
electronic prin intermediul unei reele de calculatoare.
Ansamblul de elemente implicate n tot acest proces de prelucrare i transmitere a datelor pe
cale electronic alctuiesc un sistem informaional
ntr-un sistem informaional pot intra: calculatoare, sisteme de transmisie a datelor,
componente hardware i software, datele prelucrate, personalul ce exploateaz tehnica de
calcul, teoriile ce stau la baza algoritmilor de prelucrare, etc.
Raportul sistem informaional-sistem informatic:
Sistemul informaional include n cadrul su sistemul informatic, acesta din urm fiind o
component esenial a primului. Trebuie reinut faptul c sistemul informaional nu trebuie
confundat sau suprapus complet cu sistemul informatic.
n general, sistemul informatic se interpune ntre sistemul decizional i cel operaional.
Sistemul informatic este un ansamblu structurat de proceduri i echipamente electronice care
permit prelucrarea automat a datelor i obinerea de informaii.
Sistem informatic.
Noiunea de Sistem Informatic este legat de informatizarea activitii unei Uniti Social
Economice, deci folosirea echipamentelor hardware i a produselor software pentru
organizarea i administrarea informaiilor. Utilizarea calculatoarelor n cadrul Sistemului
Informatic (SI) al unei Uniti Social Economice conduce la definirea componentei Sistem
Informatic Automatizat (SIA) care cuprinde numai lucrrile realizate cu ajutorul
calculatoarelor.
1.1.5. Funciile unui sistem informaional
Funciile unui sistem informaional sunt:
- s colecteze date din sistemele operaional i decizional precum i informaiile ce provin din
mediul extern;
- s memoreze aceste date precum i informaii rezultate din prelucrarea lor;
- s asigure accesul la memorie n vederea comunicrii informaiilor stocate;
- s prelucreze informaiile la cerea sistemului operaional i a sistemului de conducere

Componente ierarhizate ale SI

Practica de realizare a sistemelor informaionale i informatice a dovedit necesitatea
structurrii sistemului n elemente componente, ierarhizate dup anumite criterii.

Figura 1.7. Structura ierarhic a unui sistem informational corporative.

Sistemul trebuie s urmreasc realizarea obiectivelor generale ale organizaiei, fixate
pe o perioad mai lung de timp, ctre ndeplinirea acestora fiind orientat ansamblul
funciunilor de organizaie/unitate economic.
Subsistemul corespunde unor obiective derivate din cele generale, de exemplu:
aprovizionarea cu materii prime i materiale, cercetarea i proiectarea produselor i
tehnologiilor noi care ar conduce la creterea rentabilitii, etc.
Aplicaia, ca o component a subsistemului, se dezvolt la nivelul unor activiti i
compartimente din cadrul organizaiei (de exemplu: programarea, lansarea i
urmrirea produciei, planificarea cheltuielilor de producie).
1.2. Principii de baz la proiectarea sistemelor informaionale.
n majoritatea lucrrilor care se ocup cu realizarea sistemelor informaionale, se recomand
respectarea unor principii de baz:
a) Sistemul este pentru beneficiar, ceea ce implic participarea permanent a acestuia n
toate etapele de realizare a sistemului.
b) Problema cheie este cea a oamenilor, nu a echipamentelor i n special a analitilor-
proiectani de sisteme, specialiti care au o influen hotrtoare asupra modului de realizare a
sistemelor.
c) SI trebuie justificate cantitativ i calitativ, analistul de sistem stabilete cele mai corecte
criterii prin care se pot msura performanele i eficiena sistemului proiectat.
d) Realizarea sistemului este un proces iterativ, ceea ce nseamn c nti trebuie stabilit
numai cadrul general, detalierea fcndu-se treptat, n mai multe iteraii.
e) Procedurile manuale sunt la fel de importante ca programele, de corecta lor proiectare
depinznd pn la durata de implementare i modul de funcionare al sistemului.
f) Sistemul trebuie s aib o bun documentaie n toate fazele, fapt care ajut la
structurarea lucrrilor, exploatarea sistemului i la mprirea sarcinilor.

1.2.1. Gradualitatea implicrii participanilor la realizarea unui SI.

Gradul de participare al beneficiarului i al specialistului informatician n cursul etapelor de
realizare a sistemului la diferite etape de proiectare

Figura 1.8. Reprezentarea grafic a gradului de implicare.

Figura 1.9. Reprezentarea grafic a resurselor pee tape de realizare.

1.2.2. Evolutia sistemelor informationale

nceputurile n anii 1950 odat cu apariia primelor maini de calcul. La prima etap metoda
principal de proiectare a Sistemelor Informaionale era metoda de jos - n sus (bottom-up)
Urmtoarea etap - contientizarea, c exist necesitatea n mijloace relativ standardizate de
automatizare a activitii diferitor ntreprinderi i organizaii. De-a lungul timpului au existat
diverse tipuri de sisteme, odata cu trecerea timpului, crescand si numarul acestora. Categoriile
de sisteme sunt diferite, in functie de domeniile in care se aplica.1[10] In tabelul ce urmeaza,
este prezentata schematic, evolutia sistemelor informationale:
Tabelul nr. 1 Evolutia sistemelor informationale
Perioada Rolul Tipuri de sisteme informationale
1950-1960 Prelucrarea tranzactiilor Sisteme de procesare a datelor
Aplicatii ale contabilitatii generale
1960-1970 Informarea conducerii Sisteme de raportare pentru conducere
Sisteme de informare a conducerii
1970-1980 Sprijinirea procesului Sisteme de sprijinire a deciziilor
decizional Support interactive ad-hoc in procesul decizional
1980-1990 Sprijiniea utilizatorilor Aplicatii orientate catre utilizatorii finali
finali si a strategiei Sisteme informationale ale conducerii executive
Sistem expert
Sisteme bazate pe cunostinte
Sisteme informationale strategice
Dezvoltarea sistemelor informatice apare ca o evolutie de la simplu la complex, in care rolul
acestora a crescut permanent de-a lungul anilor, prin extinderea continua a functiilor sale. La
inceputul anilor 50, tehnologia informationala [11] se afla inca in prima faza a dezvoltarii
sale. Dar cu timpul, aceasta s-a remarcat printr-o serie de sisteme informationale, cele mai
cunoscute si utilizate fiind: sistemele de prelucrare a tranzactiilor, sistemele de informare a
conducerii, sistemele de sprijinire a procesului decizional si sistemele informationale pentru
conducerea superioara.
1.2.3. Etape de proictare.
Procesul crerii S.I. include crearea i transformarea succesiv a unui ir de modele
coordonate pe etapele ciclului de via a sistemului.
Modelele sunt create de ctre grupurile de lucru din cadrul echipei proiectului, sunt acumulate
i pstrate n depozitul (repozitoriul) proiectului.
Procesul de creare a unui S. I. include o serie de etape (stadii), determinate n timp i care au
drept finalitate crearea unui produs concret model, program, documentaie etc.
Crearea modelelor, verificarea i validarea lor, prezentarea pentru utilizare colectiv are loc
folosind instrumente program speciale mijloace CASE (Computer Aided Software
Engineering).
Principalele etape:
Planificarea sistemului
Analiza obiectului
formarea cerinelor fa de sistem,
Proiectarea sistemului,
Implementarea/realizarea i testarea sistemului,
Exploatarea i mentenana sistemului.

1[10] Luminita, Fanaru, Sisteme informationale si gestiunea financiara a intreprinderii, Ed.

Junimea, p.35
Ultimile dou etape sunt n afara prezentului curs.
Planificarea sistemului Etapa de nceput la care se determin are sau nu Unitatea Social
Economic nevoie de un nou S. I.
Analiza obiectului presupune:
modelarea proceselor business, care au loc n organizaie; Crearea Modelului organizaiei,
descris n termeni de procese i funcii business - permite formularea cerinelor principale;
Mulimea modelelor de descriere a cerinelor este transformat ntr-un sistem de modele, care
descriu proiectul conceptual al SI;
Sunt formate modelele arhitecturale ale SI;
Sunt determinate cerinele referitoare la asigurarea program i informaional.
Urmeaz formarea arhitecturii resurselor program i resurselor informaionale, determinarea
bazelor de date i identificarea modulelor program, formarea modelului de cerine fa de
programe i crearea acestora, testarea i integrarea.
Scopul etapei de analiz a activitii organizaiei, este determinarea cerinelor funcionale
ale sistemului.
Formarea i formularea cerinelor este una din sarcinile cele mai responsabile, dificil de
formalizat i extrem de complicate i costisitoare n cazul unor erori.
Rzultatul etapei: Caietul de Sarcini
Proiectarea sistemului - Crearea modelului logic i modelului fizic al datelor - partea
principal la proiectarea BD. Proiectarea proceselor pt obinerea specificaiilor modulelor SI.
Scopul principal al etapei de proiectare a proceselor const n transformarea funciilor,
identificate la etapa de analiz, n module ale SI
Rezultatele etapei de proiectare sunt:
schema bazei de date;
specificaiile modulelor sistemului.
elaborarea arhitecturii
Cutare rspunsuri la caracteristici ale arhitecturii:
tipul arhitecturii;
numrul de nivele;
tipul BD - centralizat sau distribuit;
omogenitatea BD;
paralelism
Rzultatul etapei: Proiectul Tehnic
Etapa de realizare (implementare) are loc crearea programelor, instalarea resurselor tenice,
elaborarea documentaiei de exploatare.
Etapa de testare este distribuit n timp.
La finalizarea lucrrilor de creare a unui modul al sistemului are loc testarea autonom (sau de
detaliu), care urmrete dou scopuri principale:
detectarea refuzurilor n funcionare a unui modul;
 stabilirea nivelului de corespundere specificaiilor.
Urmeaz testarea fiabilitii setului de module cnd:
sunt imitate situaiile de refuz n funcionare;
este determinat timpul mediu dintre dou cderi succesive (MTBF- Mean Time
Between Failures).
Ultima testare o reprezint testarea de acceptare.

Figura 1.10. Etape de creare a unui produs.

1.3. Clasificare Sisteme Informaionale conform destinaiei.
1.3.1. Aplicaiile informatice funcionale la nivelul unei uniti social -economice sunt
grefate pe cteva categorii structurale, destul de bine definite, n literatura de specialitate. Mai
jos sunt prezentate principalele categorii de sisteme informaionale i adresabilitatea acestora.
Sisteme pentru prelucrarea tranzaciilor (TPS - Transaction Processing Systems) permit
prelucrarea i stocarea datelor privind tranzaciile zilnice, caracterizate printrun grad ridicat de
repetabilitate. TPS este dedicat nivelului operaional al agentului.
Sisteme destinate activitii de birotic (OAS Office Automation System) se adreseaz
personalului angrenat n prelucrarea informaiei (data workers), contabililor, funcionarilor,
asistent-manager-ilor dar i conducerii operaionale.
Sisteme destinate cercetriidezvoltrii (KWS Knowledge Work System) reprezint
izvorul i integrarea noilor tehnologii obinute prin compartimentele de cercetare
dezvoltare.
Sisteme informatice destinate conducerii (MIS Management Information Systems) asigur
activitile de planificare, control i decizie, pe termen scurt urmrind obinerea rapoartelor de
rutin, periodice, sintetice, precum i informaiile care privesc perioada anterioar i curent
1.9 am reprezentat larga sfer de interes a sistemelor informatice destinate conducerii corelat
cu beneficiarii specifici.
Figura 1.11. Clasificarea sistemelor informatice
Sistemele suport de decizie (DSS Decision Support Systems) fructific informaiile
furnizate de TPS, MIS conectate cu influena mediului economic extern. DSS utilizeaz
modele de analiz complex i aprofundat asistnd managerii n elaborarea deciziilor.
Sistemele suport ale executivului (ESS-Executive Support Systems) sunt destinate elaborrii
unor decizii nestructurate adresate managementului strategic. Sistemele suport ale
executivului utilizeaz cele mai avansate produse software grafice i pot oferi imediat
managerului general sau consiliului de administraie diagrame i informaiile solicitate. Pot
concluziona c interdependena evident a tipurilor de sisteme informatice apare concretizat
prin faptul c informaiile (ieirile) oferite de unele dintre acestea sunt utilizate drept date de
intrare de ctre celelalte tipuri de sisteme.
1.3.2. Clasificare Sisteme Informaionale conform tipului de date.

Figura 1.12. Clasificare Sisteme Informaionale conform tipului de date

1.3.3. Clasificare Sisteme Informaionale a nivelul organizaiei.
Un alt criteriu de clasificare al sistemelor informatice este n funcie de nivelul ierarhic
ocupat de sistemul economic n structura organizatoric a organizaiei:
Sisteme informatice pentru conducerea activitii la nivelul organizaiilor
economice. Acestea pot fi descompuse n subsisteme informatice asociate funciunilor
organizaiilor economico-sociale sau chiar unor activiti.
Sisteme informatice pentru conducerea activitii la nivelul organizaiilor
economico-sociale cu structur de grup. Sunt incluse sistemele informatice la
nivelul regiilor
autonome.
Sisteme informatice teritoriale. Sunt constituite la nivelul unitilor
administrativ-teritoriale i servesc la fundamentarea deciziilor adoptate de ctre
organele locale
de conducere.
Sisteme informatice pentru conducerea ramurilor, subramurilor i
activitilor la nivelul economiei naionale. Se constituie la nivelul ramurilor,
subramurilor i
activitilor individualizate n virtutea diviziunii sociale a muncii i specificate n
clasificarea
ramurilor economiei naionale.
1.3.4. Clasificarea sistemelor informatice dup scopul urmrit:
Automatizarea activitilor de rutin;
Sprijinirea proceselor de comunicare;
Sprijinirea procesului decizional;
Sprijinirea top-managerilor;
1.3.5. Clasificarea sistemelor informatice dup elementul supus analizei:
Sisteme informaionale orientate spre funcii;
Sisteme informaionale orientate spre procese;
Sisteme informaionale orientate spre date;
Sisteme informaionale orientate spre obiecte;
Sisteme informaionale orientate spre mesaje /comunicri;
Sisteme informaionale orientate spre informaii tiinifice.
1.3.6. Clasificarea sistemelor informatice dup modul de organizare a datelor:
Sisteme bazate pe fiiere clasice;
Sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaional,
orientate-obiect, neuronale;
Sisteme mixte;
1.3.7. Clasificarea sistemelor informatice dup metoda folosit n analiza i proiectarea
sistemelor:
Sisteme dezvoltate dup metoda sistemelor;
Sisteme dezvoltate dup metoda clasic a ciclului de via a sistemelor;
Sisteme dezvoltate dup metoda structurat;
Sisteme dezvoltate dup metoda orientat obiect;
Sisteme dezvoltate dup metoda de realizare rapid (RAD Rapid Application
 Development);
Sisteme dezvoltate dup metoda echipelor mixte (JAD Join Application
Design);
Sisteme dezvoltate dup metoda participativ;
Sisteme dezvoltate dup metoda prototipurilor.

1.4. Abordri arhitecturale n realizarea sistemelor informaionale

n realizarea unui sistem informaional se poate opta pentru una din urmatoarele solutii:

- sistem informaional centralizat

- sistem informaional descentralizat

Sistemul informaional centralizat se caracterizeaz prin faptul c ntregul proces de stocare i

procesare a datelor precum i de dezvoltare a sistemului se realizeaz la nivelul unei singure
locaii n care se afl un singur sistem de calcul, de regula un mainframe, care stocheaz o baz
de date unic precum i ansamblul programelor de aplicaie. Utilizatorii interactioneaz cu
sistemul prin intermediul terminalelor

Avantajele centralizrii sunt reprezentate de:

- controlul efectiv asupra utilizrii i dezvoltrii software-ului;
- controlul asupra securitii i integritii datelor;
- partajarea resurselor hard, soft i a datelor ntre utilizatori;
- eliminarea riscului incompatibilitii hard i soft n cadrul sistemului;
- promovarea cu uurin a standardelor (tehnice, de proiectare, procedurale etc) la
nivelul ntregului sistem;
- asigurarea serviciilor solicitate de ctre utilizatori prin puterea de calcul a sistemului
central
Dezavantajele centralizarii sunt reprezentate de urmatoarele aspecte:
- "caderea" sistemului de calcul blocheaza toti utilizatorii;
- alterarea datelor si a programelor, voita sau accidentala, afecteaza toti utilizatorii;
- sistemul se poate dovedi lent si inflexibil la nevoile utilizatorilor, adesea fiind
insuficient adaptat nevoilor locale sau de grup ale utilizatorilor;
- poate realiza un timp mare de raspuns n cazul unor solicitari simultane ale mai multor
utilizatori.

Sistemul informatic descentralizat se caracterizeaza prin faptul ca datele, software-ul si puterea

de calcul sunt dispersate n diferite locatii (chiar dispersate geografic) ale organizatiei.
Prelucrarea se realizeaza pe calculatoare personale independente sau n cadrul unor retele
locale.

Avantajele descentralizarii:
- datele sunt stocate si prelucrate local;
- soft-ul este mai bine adaptat nevoilor locale;
- avariile hard, soft sau ale bazei de date la nivelul unei locatii nu afecteaza celelalte
locatii;
 - configuratia sistemului poate fi gndita n functie de nevoile diferitelor departamente
din cadrul organizatiei sau chiar a utilizatorilor locali;
- mai marea autonomie si motivare la nivelul utilizatorului local.
Dezavantajele descentralizarii:
- riscuri mari legate de incompatibilitati hard si soft ntre diferite locatii;
- aparitia inerenta a unor duplicari ale datelor si software-ului n diferite locatii;
- dificultatea realizarii unor proiecte complexe la nivel local;
- riscul de fragmentare a politicii TI;
- costuri mai mari n comparatie cu sistemul centralizat.
Tendinta actuala este net orientata catre descentralizare care trebuie sa se realizeze astfel nct:
. ntreaga responsabilitate si autoritate pentru functiile descentralizate ale SI sa apartina
managementului local;
. sa se asigure alinierea la standardele utilizate la nivelul SI global al organizatiei;
. la nivel central urmeaza sa se realizeze:
- elaborarea strategiei la nivelul ntregului SI al organizatiei;
- managementul comunicatiilor n cadrul retelei locale ale organizatiei;
- administrarea datelor;
- refacerea n caz de dezastre.

Astazi, arhitectura promovata n realizarea sistemelor descentralizate este arhitectura

clientserver caracterizata prin faptul ca aplicatiile si datele puse la dispozitia utilizatorilor sunt
dispersate pe diferitele componente hardware n functie de numarul utilizatorilor care trebuie
sa aiba acces si de puterea de calcul necesara.

Referine
[1.23] ***, engineering, http://www.m-w.com/dictionary/engineering+
[1.24] ***, inginerie, http://enciclopedie.citatepedia.ro/index.php?c=inginerie
1. Oprea D., Airinei D., Fotache M. Sisteme informationale pentru afaceri Editura
Polirom, 2002
2. Petersen J., Trad. Slavu O.V. Baze de date pentru incepatori, Editura All ,2002
3. Militaru Gh. Sisteme informatice pentru management, Editura All, 2003
4. Hernandez M. Proiectarea bazelor de date, Editura Teora,2003
5. Connolly Th., Begg C., Strachan A. Baze de date - proiectare, implementare,
gestionare, Editura Teora, 2002
6. Muller N.J. Enciclopedia Internet, Editura Tehnica, 2004
7. Levine J.R., Baroudi Carol, Levine Young M. Internet Editura Tehnica, 2001
8. Bajenescu T.I. Inteligenta distribuita si serviciile in retelele de telecomunicatii,
Editura Tehnica, 2002
9. Patic P.C. Tehnologii WAP, Editura Tehnica, 2003
10. Popescu I. Modelarea bazelor de date, Editura Tehnica, 2001
11. Karnyanszky T.M. Retele de calculatoare si comunicatii de date, Editura Augusta
Timisoara, 2001
12. Homorodean M.A., Iosupescu I. Internet si pagini web : manual pentru incepatori si
initiati, Editura Niculescu, 2001
 13. Hammuda H. Sisteme radio celulare, Editura Teora, 1999
14. Bajenescu T. Sisteme personale de comunicatii, Editura Teora, 2000
15. Buraga S. Aplicatii Web la cheie, Editura Polirom, 2003
16. Graham S., Simeonov S., Boubez T., Davis Doug, daniels G., Nakamura Y., Nezama
R. Servicii Web cu Java, XML, SOAP, WDSL si UDDI, Editura Teora, 2003
17. Norton P., Kearns D. Retele de calculatoare, Editura Teora, 2000
18. Ogletree T. Retele de calculatoare - depanare si modernizare, Editura Teora, 2000
19. Kilmer W. Retele de calculatoare si Internet pentru oameni de afaceri, Editura
Teora, 2003
20. ***, XtremPC, Nr. 53/2004

TEMA 2.
2.1. Ingineria programrii. Ciclu de via a Sistemelor Informaionale. Modele ale Ciclului
de via. Metode i Metodologii de dezvoltare Sisteme Informaionale. 2.2. Modele de
elaborare Sisteme Informaionale. 2.3. Instrumente CASE pentru dezvoltarea sistemelor
informatice

2.1. Ingineria programrii. Ciclu de via a Sistemelor Informaionale. Modele ale

Ciclului de via. Metode i Metodologii de dezvoltare Sisteme Informaionale.
Ingineria programrii (Software engineering) Se refer la metodologiile folosite n rezolvarea
proiectelor mari care sunt rezolvate de echipe de oameni. Folosirea principiilor inginereti n
analizarea, dezvoltarea, punerea n funciune, testarea, ntreinerea, retragerea produselor
software. Tot aici mai pot fi prinse: gestionarea resurselor, coordonarea echipelor, planificare,
buget.
Scop: obinerea de programe sigure i care funcioneaz eficient pe maini de calcul
concrete
Etapele dezvoltrii produselor soft:
Analiza cerinelor (Requirements analisys)
Proiectarea architectural (Arhitectural design)
Proiectarea detaliata (Detailed design)
Scrierea codului (Implementation)
Integrarea componentelor (Integration)
Validare (Validation)
Verificare (Verification)
ntreinere (Maintenance)

2.1.1. Ciclul de viata ca un ntreg.

Conceptul fundamental al ingineriei software l constituie Ciclul de Viat produselor
software.
Odat dezvoltat, produsul software intra ntr-un ciclu de utilizare i modificare (upgreat), care
continu pe toat durata sa de via.
Tiparul nu este specific numai produselor software, el putnd fi generalizat pentru majoritatea
produselor industriale, cu diferena c n cazul acestora din urma etapa de modificare se
numeste etapa de reparare sau de ntreinere (ciclul este utilizare - modificare, pe masura ce
componentele se uzeaza).
Figura 2.2. Tiparul general a ciclului de via a produselor.

Ciclul de Via a Sistemului Informaional - este succesiune de etape i procese, executate n

cadrul etapelor.
Pentru fiecare etap este determinat componena i succesiunea lucrrilor executate,
rezultatele la ieire, metodele i mijloacele necesare pentru ndeplinirea lucrrilor, rolurile i
responsabilitile participanilor.
Ciclul de via - ir de evenimente, care se produc n procesul crerii i exploatrii
sistemului.

2.1.2. Modele ale ciclului de via.

Modelul Ciclului de Via reflect diferite stri ale sistemului, pornind de la momentul
apariiei necesitii de elaborare pn la retragerea sistemului.
Modelul Ciclului de Via - poate fi privit ca structura, care include procesele, aciunile i
sarcinile realizate n timpul elaborrii, funcionrii i ntreinerii produsului program pe
ntreaga perioad de existen a sistemului, de la stabilirea cerinelor pn la retragerea din
utilizare.

2.1.3. Etape de proiectare Sisteme Informaionale

Etapa de analiz.
Aceast este etapa n care se constata c ar fi util o aplicaie informatic i se ia decizia
dezvoltrii unui sistem software. Fie c se constat existena unei piee pentru un produs de uz
general, fie c o anumit organizaie are nevoie de o aplicaie specializat, n mare masur
aceast prim etap presupune mai degrab luarea unor decizii de management i marketing
dect abordarea unor problem legate de studiul algoritmilor.
Dup luarea deciziei de dezvoltare a unui sistem informatic ncepe adevarata analiz, al
crei scop principal este identificarea necesitilor utilizatorului potenial al sistemului.
Etapa de proiectare
n faza de proiectare sunt dezvoltate detaliile tehnice ale sistemului. n aceast etap, sistemul
este decompus n componente mai uor de realizat i de controlat, numite module.
Implementarea sistemelor complexe devine posibil tocmai prin aceast descompunere
modular.
Altfel, mulimea detaliilor tehnice care trebuie luate n considerare ar fi imposibil de stapnit;
prin proiectarea modular, este suficient s avem n vedere pentru fiecare modul doar detaliile
corespunzatoare acestuia.
Pe de alt parte, proiectarea modular ajut i la ntreinerea sistemului.
O structur modular bine proiectat este important att pentru implementarea sistemului, ct
i pentru modificarea sa ulterioar. Acesta este unul dintre principalele motive pentru care
paradigma orientata spre obiecte cstiga teren: un sistem proiectat orientat spre obiecte este
prin definitie un sistem modular.
Etapa de implementare/testare.
Implementarea
Aceast faz se refer la scrierea efectiv a programelor, crearea fiierelor de date i
dezvoltarea bazelor de date.
Testarea
Aceast faz este strns legat de faza anterioar, deoarece n normal fiecare modul al
sistemului este testat n timpul implementarii, ntr-un sistem bine proiectat, fiecare modul
poate fi testat n mod independent, utilizndu-se versiuni simplificate ale celorlalte module
pentru a se simula interaciunile dintre modulul inta i restul sistemului. Desigur, pe masura
ce diferite module sunt analizate i combinate, testarea individual trebuie continuata cu
testarea generala a ntregului sistem.

2.1.4. Faze, ca elemente comune duiferitelor abordri:

1. Definirea cerinelor utilizatorilor: utilizatorii vor preciza obiectivele pe care urmeaz s le
ndeplineasc viitorul sistem informational, criteriile de eficien, securitate, performan pe
care acesta urmeaz s le asigure. Calitatea i performanele unui produs software depend de
abilitatea echipei de analiz n colectarea de specificaii ct mai complete de la viitorul
utilizator i de a-I face pe acestea vad funcionalitatea viitorului sistem informational.
2. Specificaia cerinelor sistemului: prezentarea detaliat a rezultatelor pe care sistemul
informational urmeaz s le asigure. Se va evidenia ce anume urmeaz s fac sistemul, fr
a se sugera n nici un fel cum va face acest lucru suistemul. Aceast faz este un rspuns la
specificaie cuprinznd cerinele utilizatorului i va fi utilizat n faza de proiectare a
sistemului.
3. Specificaia cerinelor software: evideniaz ce urmeaz s fac produsul software i
testriciile sub care funcionalitatea sa urmeaz s fie asigurat.
4. Proiectarea general, n cadrul creia se defines soluii cadru, conceptuale, privind
viitorul sistem informational.
5. Proiectarea de detaliu, care rafineaz soluia cadru , rezultat al proiectrii generale, avnd
ca finalitate definirea soluiei finale a sistemului informational.
6. Realizarea componentelor sistemului informaional, pe baza soluiilor oferite de
proiectarea de detaliu.
7. Testarea componentelor: verificarea modului de funcionare, modului de ndeplinire a
cerinelor i fiabilitatea n utilizare.
8. Integrarea componentelor i testarea final a sistemului: reunirea componentelor n
cadrul produsului final i verificarea funcionrii lui n ansamblu.
9. Implementarea i testarea produsului la beneficiar, urmate de acceptarea de ctre
beneficiar.
10. Expluatarea i mentenana sistemului: utilizarea curent a sistemului informational i
mentenana lui.
11. Dezvoltarea sistemului informational: realizarea i integrarea de noi componente care
s mbunteasc i/sau dezvolte funcionalitatea, i performanele sistemului.
n cadrul diferitelor modele, aceste faze (alturi de cele specific fiecrui model) sunt reunite
n cadrul unor etape i anume:
I. Analiza sistemului, care plec de la analiza sistemului existent i se conin n fazele 1-3;
II. Proiectarea general (faza 4)
III. Proiectarea de detaliu, (faza 5)
IV. Realizarea sistemului informaiona (fazele 6-8)
V. Instalarea sistemului informaiona pe sistemele de calcul ale beneficiarului (faza 9)
VI. Expluatarea i mentenana sistemului (faza 4)
VII. Dezvoltarea sistemului informational (faza 11).

2.2. Modele de elaborare Sisteme Informaionale.

Modelele elaborate au cunoscut mbuntiri permanente, ncercnduse adaptarea lor la noile
cerine ale modelrii orientate obiect, precum i inserarea unor etape specific managmentului
proiecrelor.
Criterii de selectare a unui model
Buget
Joaca un rol cheie
Dimensiunea echipei
Metodologii agile = echipe mici
Tehnologiile utilizate
Unelte si tehnici
Natura proiectului
Procese existente in companie

2.2.1. Modelul cascad.

Modelul cascad (Waterfall Model) a fost elaborate de W.W. Royce la inceputul anilor
70. Este un model de referin n literatura de specialitate, caracterizat prin parcurgerea
secvenial a fazelor ciclului de via, faze care , la rndul lor, sunt formate din activiti, iar
acestea din urm din subactiviti.
Modelul prezint urmtoarele faciliti:
Controlul total al fazelor, datorit modului de ordonare a acestora;
Uor de nsuit de ctre membrii echipelor de analiz i proiectare;
Fiecare faz se ncheie cu o verificare a soluiei oferite i asigur o documentaie
prezentnd soluia elaborate.
n timp au fost propuse variante mbuntite ale modelului:
Modelul cu revenire la pasul urmtor (Waterfall Model with back flow);
Modelul cu reluare de la faza initial (Da Capo Waterfall Model)
Figura 2.3. Ciclului de via n Model cascad cu control intermediar.

Figura 2.4. Ciclului de via n Model cascad cu control intermediar.

Rezultatul proiectrii n modelul cascad.
Setul de documente ce formeaz minimul ce ar trebui produs n fiecare proiect sunt:
Document de cerine
Planul proiectului
Document de design al sistemului
Document de design detaliat
Plan de test i raport de test
Cod final
Manuale software (manualul utilizatorului, manual de instalare etc)
Raporturi de evaluare.
Avantajele modelului cascad.
Uor de explicat utilizatorilor.
Etapele i activitile sunt bine definite.
Este util planificarea i programarea proiectului.
Verificarea n fiecare etap asigur detecia timpurie a erorilor/nenelegerilor.
Uor de manevrat datorit rigiditii modelului.
Etapele sunt procesate i completate pe rnd.
Funcioneaz bine pentru proiectele mai mici unde necesitile sunt foarte bine nelese
sau pentru automatizarea unor sisteme deja existente.

Dezavantaje ale modelului cascad

Ajustarea scopului n timpul ciclului de via poate omor un proiect.
Nu se introduce software funcional pn spre finalul ciclului de via.
Cantiti mari de risc i nesiguran.
Model slab pentru proiectele complexe i obiect-orientate.
Model slab pentru proiectele lungi i continue.
Model slab acolo unde necesitile au un risc moderat spre ridicat de a se schimba.

Modelul cascad presupune c toate cerinele unui sistem pot fi ngheate naintea nceperii
design-ului. Acest lucru este posibil pentru sistemele create s automatizeze un sistem manual
deja existent. Dar pentru un sistem absolut nou, determinarea cerinelor este dificil, din
moment ce nici chiar utilizatorul nu tie cerinele. Astfel, a avea cerine ce nu se schimb (sau
se schimbp doar puin) este nerealist pentru un asemenea proiect. nghearea cerinelor
necesit deseori alegerea hardware-ului (din moment ce formeaz o parte a specificaiilor
necesitilor).
Un proiect mare ar putea dura civa ani pn la finalizare. Dac hardware-ul este selectat
timpuriu, apoi datorit vitezei la care tehnologia hardware se schimb, este foarte probabil ca
software-ul final s necesite o tehnologie hardware ce este pe cale s devin nvechit. Acest
lucru este n mod clar nedorit pentru software att de costisitor.
Modelul cascad stipuleaz faptul c cerinele ar trebui specificate complet nainte ca restul
dezvoltrii s poat ncepe. n anumite situaii ar putea fi de dorit ca mai nti s se dezvolte o
parte a sistemului complet, iar apoi s se mbunteasc sistemul. Acest lucru este deseori
efectuat pentru produsele software ce sunt realizate nu neaprat pentru un client (unde clientul
joac un rol important n specificarea cerinelor), dar pentru piaa general, n care cerinele
sunt determinate cel mai probabil de ctre dezvoltatori.
Modelul cascad cu 7 etape.
Etape - Se poate considera un model cascad cu 7 etape ce se includ n cele patru faze ale
unui model SDLC (Software Development Life Cycle):
Faza de decizie- Faza de decizie a unui SDLC este atunci cnd se decide ce se dorete a se
implementa ca software. n aceast faz sunt 3 etape:
Situaia de afaceri ceea ce utilizatorul dorete s obin de la software.
Cerinele utilizatorilor - ceea ce software-ul trebuie s fac pentru afacere.
Specificaiile sistemului ceea ce software-ul trebuie s realizeze n termeni de
computare pentru a ndeplini cerinele clienilor.
Situaia de afaceri

Cerinele utilizatorilor Decizie

Specificaiile sistemului

Design-ul sistemului

Design
Design-ul componentelor

Construcia compoenentelor
Dezvoltare

Testare
Demonstrare

Figura 2.5. Modelul cascad cu 7 etape i patru faze.

Faza de decizie.
Situaia de afaceri.
Aceasta este justificarea pentru a construi sistemul software i trebuie s acopere un numr de
domenii, incluznd:
Care este situaia curent a afacerii i software-ului.
Care este oportunitatea de afaceri pe care software-ul o va rezolva.
Care sunt diversele strategii de soluii i fezabilitatea lor.
Care este strategia de soluie preferat.
Care este relaia costuri - beneficii.
Care sunt presupunerile, riscurile i constrngerile posibile.
Care este abordarea de implementare n linii mari.
O cantitate considerabil de munc trebuie s fie realizat de ctre utilizatori cu date de intrare
oferite de dezvoltatori pentru a produce o situaie de afaceri.
Beneficiile realizrii acestui lucru sunt oferirea tuturor din proiect a unei hri clare a locului
n care se ndreapt utilizatorii i de ce.
Cerinele utilizatorilor.
Urmtoarea etap este aceea de a defini un set de cerine ale utilizatorilor. Acestea definesc
pentru strategia preferat de soluii ceea ce sistemul software trebuie s obin pentru a
mplini oportunitatea de afaceri.
Domeniile ce trebuie incluse sunt:
Cerine funcionale ce trebuie s realizeze sistemul, de exemplu pentru a pstra
detalii ale arhivelor utilizatorilor.
Cerine non-funcionale sunt dou tipuri:
Constrngeri de performane ce performan este necesar din partea sistemului, de
exemplu dac va aduce la zi arhivele clienior peste noapte.
Contrngeri de dezvoltare ce restricii asupra dezvoltrii se vor aplica, de exemplu
dac sistemul trebuie s fie disponibil la un anumit moment.
Obiectivele de design care sunt cele mai importante caracteristici ce se aplic
sistemului.
Specificaiile sistemului.
Specificaiile sistemului au loc atunci cnd se trece de la concentrarea pe utilizatori la
sistemul n dezoltare. Este design-ul logic a sistemului software i modul de a-l realiza.
Acoper:
Procesele sistemului ce proces tehnic este necesar pentru a implementa fiecare
proces de afaceri.
Interfee externe ceea ce este necesar pentru sistem pentru a comunica n afar,
inclusiv:
Interfee tranzacionale ceea ce este necesar pentru a comunica cu utilizatorii (cum ar
fi monitoare).
Interfee de raport ce tipuri de rapoarte sunt necesare.
Interfee de aplicaii ce conexiuni sunt necesare pentru alte sisteme software.
Cerine non-funcionale care sunt constrngerile asupra sistemului.
Suprapunerea stadiilor.
Caracteristica distinctiv a tuturor celor trei etape n Decizie este faptul c se ocup de ceea ce
se dorete. Totui, graniele dintre ele se pot suprapune.
Utilizatorul dezvolt att situaia de afaceri ct i cerinele utilizatorului i probleme
din oricare pot trece la cealalt etap sau chiar s fie acoperite de ambele. Cheia este
de a asigura c ele sunt acoperite mcar ntr-un loc.
Grania dintre Cerinele utilizatorilor i Specificaiile sistemului poate avea o mare
suprapunere, n special din moment ce ambele au ca scop informarea dezvoltatorilor
Diferenele cheie dintre cele dou sunt:
Cerinele utilizatorilor sunt scrise de ctre utilizatori asistai de dezvoltatori, n timp ce
Specificaiile sistemului sunt scrise de dezvoltatori asistai de utilizatori.
Cerinele utilizatorilor exprim funcionalitatea necesar n termeni de ceea ce
afacerea dorete s obin, n timp ce Specificaiile sistemului exprim funcionalitatea
n termeni de ceea ce sistemele software ar putea realiza.
Faza de Design.
Faza de Design are loc atunci cnd diverse cerine sunt mapate la mediul software i au loc
deciziile de implementare. Aceast faz se concentreaz pe modul n care software-ul va fi
realizat. Aceast versiune a modelului cascad are dou etape:
Design-ul sistemului modul n care software-ul va fi structurat n componente.
Design-ul componentelor modul n care o component va fi structurat.
Design-ul sistemului - Etapa de design a sistemului ia Specificaiile sistemului i creeaz
arhitectura sistemului. Acest lucru este realizat prin definirea unei serii de componente
mpreun cu ceea ce realizeaz i cum interacioneaz cu alte componente. Aceste
componente pot fi alte sisteme, interfee, module de cod, ecrane, baze de date etc. ceea ce nu
este definit este detaliul cu privire la modul n care va funciona fiecare component.
Design-ul componentelor - Etapa de design al componentelor este design-ul detaliat a
modului n care o anumit component va funciona, i cum comunic rezultatele sale ctre
alte componente prin interfee. Nu este probabil s existe un document ce acoper design-ul
tuturor componentelor deoarece ele sunt create de persoane diferite. n multe cazuri, aceste
design-uri sunt realizate de ctre cei ce codeaz.
Faza de dezvoltare.
Faza de dezvoltare este etapa de Construcie a componentei n modelul cascad. Ea se ocup
cu construcia componentelor necesare pentru software. Componentele software vin n multe
forme i variaz de la software realizat pe comand dezvoltat n mod special pentru sistem,
pn la pachetul software ce este configurat pentru a satisface cerinele.
Exist dou principale tipuri de pachete software:
COTS (Commercial Off The Shelf) Acestea sunt pachete de aplicaii ce acoper
nevoi variate ale utilizatorilor ce sunt aduse i configurate de funrizori comerciali.
Open Source Acestea sunt pachete variate de aplicaii dar sunt ntreinute de o
comunitate de utilizatori.
Software-ul realizat pe comand va putea ndeplini necesitile exacte, dar este costisitoare
producia sa. n teorie, exist economii de pre utiliznd pachete software. n teorie, deoarece
costurile de instalare pot fi mai mici, dar costul rulrii pachetului pe parcursul vieii sale poate
fi mai mare.
Faza de demonstrare
Faza de demonstrare este etapa de test i implic faptul c sistemul software ndeplinete toate
etapele de design, specificaii i cerine din fazele de Decizie i Design.
Observaii
Aceste apte etape realizeaz modelul cascad aa cum este utilizat n mod tradiional, dar
flexibilitatea n modul n care este utilizat afecteaz ct de succes va avea. Exist un numr de
probleme cu modelul cascad, de aceea a evoluat n modelul n V.
Aplicare.
Modelul cascad poate fi utilizat cu succes atunci cnd necesitile sunt bine nelese de la
nceput i nu se ateapt s se schimbe sau evolueze pe parcursul vieii proiectului. Riscurile
proiectului ar trebui s fie relativ joase.

2.2.2. Ciclului de via Modelul n V.

A fost utilizat n Germania i SUA n anii 80
Partea stng analiza cerinelor i crearea specificaiilor sistemului
Partea dreapt integrarea prilor i validarea lor
V de la Verificare i Validare
Modelul n V este o variant a modelului cascad, care aduce elemente calitative noi
importante. Un element careacteristic al modelului este introducerea conceptelor de sistem i
componenta (subsistem), aplicnduse teste explicite pentru creterea controlului asupra
modelului n care se desfoar etapele. Fazele plasate n partea superior a modelului se
caracterizeaz prin implicarea direct a viitorului utilizator.
Figura 2.6. V Model de la SEF (Ould, 1990)

Figura 2.7. Modelul V cu planificare teste de acceptare.

Descrierera diagramei.
Braul stng al diagramei, parcurs descendent, reunete fazele n cadrul crora se realizeaz,
pas cu pas, proiectarea i realizarea sistemului informational. Detalierea activitilor de
proiectare, codificare i asamblare a componentelor se realizeaz gradual. Dealtfel, Ould,
creatorul modelului n forma sa consacrat, a prevzut doar latura din stnga, unde efortul
principal de proiectare se focalizeaz pe descompunerea sistemului pe component.
Braul drept al diagramei parcurs ascendent cuprinde reprezentarea fazelor asigurnd
asamblarea rogresiv a sisgtemului, 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 valdare.
Verificarea se refer la testarea sistemului la diferite stadia pe care le parcurge, iar validarera
urmrete s identifice n ce msur sistemul corespunde cerinelor iniiale, ceea ce constitue
un punct slab al modelului, datorit ntrzierii cu care se produce aceast validare. Tocmai din
aceast cauz, i se reproeaz c las validarea prea trziu, dup ce sistemul s-a construit,
ceea ce l face ineficient.

2.2.3. Ciclului de via Modelul n W.

Acest model reia ideia modelului V, pe care l dezvolt i perfecioneaz prin integrartea
acivitilor de validare la nivelul fazelor de proiectare.

Figura 2.8. Ciclul de via Modelul n W.

2.2.4. Ciclul de via Modelul evolutiv.

Modelul evolutiv pornete de la realizarea unui studiu iniial privind obiectivele viitorului
sistem informational, a crui arhitectur este definit ulterior. Fiecare component astfel
definit i va urma propriul su ciclu de via (definirtea cerinelor, analiza, proiectare,
testare, utilizare).
Un Sistem informational reprezint ansamblul unor component n interaciunea lor, fiind
rezultatul unei concepii bazate pe arhitecturi deschise i flexibile. O astfel de abordare etste
apropiat celei orientate obiect, caracterizate prin ncapsularea datelor i funcionalitii
obiectelor.
Reprezentarea grafic a modelului evolutiv este influenat de modelul circular, a crui
caracteristic o reprezint marcarea unui ciclu complet al sistemului informatics printr-un
cerc.
Figura 2.9. Reprezentarea grafic a modelului evolutiv.

2.2.5. Ciclul de via Modelul spiral.

Modelul spiral, elaborate de Barry Boehm, se bazeaz pe aceleai principii ca i modelul
evbolutiv. Modelul presupune construirea mai multor prototipuri successive, n condiiile unei
analize a riscului pe fiecare nivel.
Fazele de dezvoltare sunt reluate la fiecare iteraie, n aceiai siccesiune i presupun:
Analiza riscurilor;
Realizarea unui prototip;
Simularea i testarea prototipului;
Determinatea cerinelor n urma rezultetelor testrii;
Validarea cerinelor;
Planificarea ciclului urmtor.
n centrul spiralei este plasat cunoaterea cerine3lor i estimarea costurilor la nivel
preliminary. Evoluia sistemului informaional urmeaz desfurarea spiralei, nregistrnd
acumulri successive ale costurilor i este marcat de succesiunea prototipurilor. Fiercare
dintre acestea valorificnd acumulrile realizate la nivelul prototipului anterior. Interaciunea
dintre faze nu este reliefat direct, atta timp ct modelul prevede o sccesiune 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 informational.
n ingineria software, un prototip este folosit att pentru validarea ct i pentru identificarea
cererilor utilitzatorilor, pentru verificarea soluiei de proiectare i oferirea bazei dezvoltrii
ulterioare a proiectului de sistem informational. Apelarea la utilizarea prototipului este
consecina faptului c un model functional rste mai uor de nelws de ctre viitorul utilizator,
dect un set de diagrame, fie chiar, nsoite de documentaie. Un Prototip functional
presupune proiectarea sistemului, realizarea primului prototip functional,
verificarea msurii n care corespunde cerinelor formulate de utilizator i
rafinarea acestei prime soluii, prin dezvoltri viitoare care adaug noi funcionalitpi pn la
ovbinerea variantei finale a sistemului.
Figura 2.10. Reprezentarea grafic a modelului spiral.

Descrierea modelului spiral.

Evolutia spiralei consta in cele 4 cadrane.
Primul cadran determina obiectivele, alternativele si constrangerile.
Al doilea cadran evalueaza alternativele, identifica si rezolva riscurile.
Al treilea cadran dezvolta si verifica produsul de la urmatorul nivel.
Iar cadranul al patrulea planifica urmatoarele faze.
De altfel, spirala este orientat ctre dezvoltarea software, conceptul fiind egal aplicabil
sistemelor hardware.
Cadranul 1
Activitatile desfasurate in acest cadran sunt urmatoarele:
Stabileste un acord al sistemului sau a obiectivelor produsului: performanta,
functionalitate si abilitatea de adaptare la schimbari.
Investigheaza implementarile alternative: model, reutilizare, procurare si modificare.
Investigheaza constrangerile impuse cu privire la alternative: tehnologie, cost,
program, suport si riscuri.
O data ce toate acestea au fost stabilite, se trece la cadranul al doilea.
Cadranul 2
Activitatile ingineresti reprezentate in acest cadran selecteaza o abordare alternative ce
satisfice mai bine tehnologia, costul, programul, suportul si riscul constrangerilor. Aici se
pune accentul pe atenuarea riscului. Este analizata fiecare alternativa si este folosita in asa fel
incat sa reduca riscurile asociate dezvoltarii deciziilor. Boehm descrie aceste activitati
spunand ca pot implica prototipuri, simulari, benchmarking, chestionare de administrare,
modelare analitica si alte tehnici de rezolutie a riscului. Daca operatia critica si/sau
problemele tehnice precum riscul performantei sau al interoperabilitatii ramane, este posibila
adaugarea unor detalii in plus a prototipului inainte de trecerea la urmatorul cadran.
Cadranul 3
Daca se determina ca prototipul anterior are rezolvate operatiile critice/problemele tehnice,
activitatile de dezvoltare si verificare, se trece la urmatorul nivel. Ca rezultat, modul de baza
cascada poate fi utilizat(descrierea, conceptual operatiilor, dezvoltarea, integrarea si testarea
urmatorului sistem). Se poate utiliza si dezvoltarea incrementala.
Cadranul 4
Modelul de dezvoltare in spirala are o caracteristica comuna cu toate celelalte modele: nevoia
planificarii tehnice avansate si analize multidisciplinare la asteptarea critica. Fiecare ciclu al
modelului culmina cu o analiza tehnica ce evalueaza starea, progresul, maturitatea, meritele si
riscurile dezvoltarii.

Avantaje si dezavantaje modelului spiral.

Avantaje:
Analiza crescut a riscurilor
Ideal pentru proiecte mari
Software-ul este produs devreme n ciclul de via
Dezvoltare complet a modelului software la proiectele cu cereri neclare
Flexibilitate.
Dezavantaje
Model costisitor
Analiza riscurilor necesit expertiza specifica de nivel inalt
Succesul proiectului depinde puternic de faza de analiz a riscurilor
Nu este potrivit pentru proiecte mici
Este greu de inteles de catre utilizatorii fr pregatire tehnica.
Aplicabilitate.
Modelul spirala se foloseste:
Atunci cand crearea unui prototip este potrivita;
Atunci cnd costurile i evaluarea riscurilor este important;
Pentru proiecte de risc mediu sau crescut;
Pentru proiecte pe termen lung;
Atunci cnd utilizatorii nu sunt siguri de nevoile lor;
Atunci cnd cererile sunt complexe.

2.2.6. Ciclul de via n Modelul Fntn artezian.

Modelul fntn artezian i are izvoarele n modelul spiral (ierarhic) i modelul vrtej de
ap. Pornete de la cunoatertea lumii reale, a cerinelor i elaborarea studiului de fezabilitate.
Se parcurg apoi etapele de:
analiz,
proiectarea sistemului,
proiectarea component,
codificare,
testare component,
testare sistem,
utilizare,
ntreinere,
dezvoltare.
Figura 2.11. Ciclul de via n modelul Fntn artezian

2.2.7. Ciclul de bvia n Modelul tridimensional.

Modelul tridimensionalpromovat de metoda de proictare MERISE se caracterizeaz prin
reprezentarea grafic pe trei axe,
fiecare dintre aceatea corespunznd:
ciclului de via al sistemului,
ciclului de decizii i respective
ciclului abstractizrii.
Figura 2.12. Ciclul de via n Modelul tridimensional.

Ciclului abstractizrii se dezvolt pe tri nivele: conceptual, logic i fizic.

Nivelul conceptual se aplic independent datelor i prelucrrilor genernd modelul
conceptual al datelor i modelul conceptual al prelucrrilor. Se realizeaz succesiv modelul
logic al datelor i modelul fizic al datelor, modelul logic al prelucrrilor (organizaional),
modelul operational al prelucrrilor.
Ciclul de dcecizie cuprinde ansamblul deciziilor legate de proiectarea, realizarea i
exploatarea sistemului informaional:
Deciziile globale vizeaz problemele cadru privind obiactivele sistemului
informaional i funcionalitatea lui, domeniile de informatizat, prioritile,
planificarea lucrrilor, etc.
Deciziile de organizare vizeaz arhitectura i interaciunile dintre component,
strategia de gestiune a datelor, planificarea activitilor de proiectare general,
proiectare de detaliu i realizare a sistemului informational.
Deciziile tehnice vizeaz suportul hardware i de comunicaie, supotrul software i
mediul de exploatare a sistemului informational. etc.
Deciziile legate de exploatare i mentenan sunt decizii care asigur buna funcionare
a sistemului informational i aceste decizii aparin utilizatorului.
Etape al Ciclul de via presupune parcurgerea siccesiv urmtoarelor etape:
Schema directoare i studiul prealabil presupune: analiza sistemului informaional
existent, formularea cerinelor i obiectivelor sistemului informational, definitra
prioritilor n rtealizarea sistemului informational, realizarea de scenario globale
alternative pentru fiecare domeniu investigat i alegerea scenariului considerat optim.
 Studiul detaliat pleac de la soluia cadru definite pentru scenariul aleas, pe care o
dezvolt, abordnd problemele de la general la particular. Aceast etap asigur
modelarea conceptual i organizational a viitorului sistem informational.
Studiul tehnic, prin soluiile concrete pe care le definete, va asigura modelarea
logic i fizic. Codificarea corespunde etapei de scriere i testare a procedurilor, fiind
apoi urmat de integrarea acestora i de testare final a sistemului.
Implementarea i testarea sistemului n condiii reale de expluatare ale beneficiarului
vor fi urmate de acceptarea produsului, pe baza evalurii rezultatelor testrii.
Exploatarea i mentenana sistem informational au coninutul conoscut deja din
prezentrile anterioare.

2.2.8. Ciclul de via n Modelul RAD (Rapid Application Development).

RAD este un model aprut c rspuns la metod tradiional Waterfall, RAD se bazeaz pe
modificarea cerinelor pe baza informaiilor acumulate n urma dezvoltrii proiectului (se
bazeaz pe dezvoltarea iterativ). Este un concept ce promite o dezvoltare mai rapid i de
calitate superioar care se bazeaz pe:
- Obinerea de informaii n urma edinelor de stabilire a cerinelor proiectului i a celor de
brainstorming.
- Crearea de prototipuri (forme incomplete ale codului) i reconstruirea acestora n buci de
cod funcionale ce pot fi introduse n producie.
- Reutilizarea pe ct de mult posibil a codului.
- Formalitate sczut n comunicarea cu membrii echipei.

Business modeling se refer la analiza fluxului de informaii i distribuia informaiei ntre

diferite funcii ale produsului.
Data modeling se refer la transformarea informaiilor acumulate n prima etap n obiecte
de date i se construiesc relaiile ntre obiecte.
Process modeling se refer la crearea pe baza obiectelor construite anterior a unor fluxuri de
informaii astfel nct s se ating anumite obiective. Sunt detaliate procesele prin care se fac
operaii de adugare, editare sau tergere a obiectelor.
Application generation - se refer la etap de transformare (prin cod propriu-zis) a obiectelor
i relaiilor ntre ele n prototipuri.
 Fig.2.13. Schema modelului RAD
(http://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm)
Testing and turn-over Sunt testate att prototipurile ct i interfetele, dei prototipurile sunt
testate indirect i prin procesul iterativ interfetele au o testare ndelungat reducnd riscul de a
avea greeli majore.
Avantajele modelului RAD sunt:
-Timpul redus de dezvoltare a produsului.
-Se ncurajeaz reutilizarea poriunilor de cod.
-Este ncurajat opinia clienilor vizavi de proiect, modificri ulterioare putnd fi fcute rapid.
-Productivitatea este crescut datorit numrului relativ mic de membrii ai echipei.
Dei avem avantaje puternice modelul RAD, c multe dintre modelele de tip light, poate
prezena numeroase dezavantaje:
-Este dependent de o echipa puternic a cror cunotine n domeniu sunt foarte bune.
-Se poate aplic doar pentru sistemele ce pot fi modularizate.
-Nu poate fi aplicat pentru proiecte cu buget redus deoarece costurile pot varia, mai ales
atunci cnd este vorba de un numr mare de programatori pentru a crea interfetele.
Cnd se decide folosirea modelului RAD trebuie s ne asigurm c proiectul este de
dimensiuni ce permit predarea n 2-3 luni i c bugetul permite acest stil de lucru (costisitor
din punct de vedere al resurselor umane).
2.2.9. Modelul ciclului de via "Incremental".
Modelul ciclului de via "Incremental" este opus modelului in cascad.
El se bazeaz pe o idee foarte simpl:
Dac un sistem este prea complex pentru a fi neles, conceput sau realizat intr-o singur faz
este mai bine sa fie realizat n mai multe faze, prin evoluie.
Cum se aplica
Intr-o faza initiala:
Se studiaza scopul proiectului si fezabilitatea sa. In cazul deciziei de continuare a
proiectului:
 Se detaliaza cerintele utilizatorilor si se efectueaza o analiza de nivel inalt, pentru a se
determina cerintele software la un nivel general.
Se determina o arhitectura generala a sistemului.
Se impart cerintele in subseturi care pot fi implemenate in incremente separate. Se
stabileste planificarea in timp a incrementelor.
Fiecare increment implementeaza un subset de cazuri de utilizare de nivel inalt, care
exprima cerintele utilizatorilor. El este construit urmand abordarea cascada: analiza
detaliata a cerintelor din subset, proiectarea, implementarea si testarea. Rezultatul este un
produs care satisface un subset al cerintelor si este livrat utilizatorilor. Un produs tipic
consta din 10-50 incremente.
Se incepe cu o implementare simpla a unui subset al cerintelor software. Rezulta o prima
livrare.
Scopul primei implementari este de a crea un produs la care utilizatorul poate reactiona. El
trebuie sa puna in evidenta aspectele cheie ale problemei si sa furnizeze o solutie sufient
de simpla pentru a fi inteleasa si usor de implementat.
Fiecare noua iteratie include analiza ultimei versiuni si adaugarea de noi functionalitati,
ceea ce presupune reproiectarea, codificarea si testarea. Se urmareste ca proiectarea sa fie
directa, modulara, sa suporte reproiectarea.
Analiza unei iteratii se bazeaza pe feedback-ul utilizatorului si pe instrumentele de analiza
disponibile. Ea se refera la: modularitea produsului, cuplarea modulelor, utilizabilitatea,
fiabilitatea, eficienta si realizarea scopurilor.
Fiecare iteratie este o varianta imbunatatita a celei anterioare, de aceea metoda se mai
numeste imbunatatirea iterativa (iterative enhancement).

Fig.2.14. Schema modelul incremental.

Se utilizeaza masuri pentru evaluarea evolutiei sistemului. Masurile prin care se
evalueaza un software sunt dificil de inteles ca valori absolute, dar schimbarile
valorilor lor in evolutia unui sistem sunt o baza de comparatie. Astfel de masuri sunt:
numarul de defecte, efortul de actualizare, dimensiune, complexitatea, cuplarea
modulelor. Schimbarile diferitelor aspecte se pot monitoriza si se pot stabili limite
pentru anumite masuri, pentru a semnala probleme sau anomalii.
 Utilizarea analizei si a masuratorilor ca ghid in procesul iterativ este o diferenta
majora intre aceasta metoda si metodele de dezvoltare agila (agile software
development). Ele sunt suportul pentru determinarea eficientei procesului si a calitatii
produsului.
Fiecare iteraie a ciclului de via iterativ i incremental reproduce ciclul de via n
cascad la o scar mai mic. Obiectivele unei iteraii sunt stabilite pe baza evalurii
iteraiilor precedente.
Documentaia este construit treptat, n timpul fiecrei iteraii. La sfritul dezvoltrii,
documentele obinute au aceeai form cu cele obinute n maniera convenional.
Avantaje:
In fiecare etap este livrat un produs executabil, care satisface o parte din cerintele
utilizatorului. Opus modelului cascad in care se elaboreaz documente.
Prototipurile sunt livrate clientului/utilizatorilor.
Feedback-ul utilizatorilor este distribuit pe ntreg parcursul dezvoltrii.
In cazul apariiei unor schimbri n cerine acestea pot fi incoporate n urmatorul
prototip.
Ciclul de via iterativ se bazeaz pe evoluia prototipurilor executabile, msurabile i
deci pe evoluia elementelor concrete. El este opus din acest punct de vedere ciclului
de viata n cascad care se bazeaz pe elaborarea de documente. Livrrile foreaz
echipa s dea rezultate concrete n mod regulat.
Integrarea diferitelor componente ale programului este realizat ntr-o manier
progresiv n timpul construciei.
Progresele se msoar prin programe demonstrabile mai degrab dect prin
documente sau estimri, ca n ciclul de via n cascad;
In cursul dezvoltrii, clientul poate utiliza prototipurile. Demonstrarea prototipurilor
prezint numeroase avantaje.
utilizatorul este pus n faa situaiilor de utilizare concrete care-i permit s-i
defineasc mai bine dorinele i s le comunice echipei de dezvoltare;
utilizatorul devine partener al proiectului;
el si ia partea de responsabilitate n noul sistem i de fapt l accept mai uor;

Dezavantaje
Ciclul de via Incremental se bazeaz pe evoluia prototipurilor executabile. Din nefericire,
programele nu se preteaz n mod natural evoluiei, din contr, ele sunt deseori foarte
"fragile" la modificri. Efectul unei modificri locale se poate propaga n ansamblul aplicaiei.
Fiecare nou increment poate necesita reorganizarea structurii interne, degradnd arhitectura
iniiala a programului, facndu-l greu de verificat i de ntreinut. Erorile de proiectare sunt
mai greu de eliminat.
Abordarea obiect bazat pe modularitate i ncapsulare conduce la programe mai robuste i
mai rezistente fa de schimbri. Din acest punct de vedere, abordarea obiect furnizeaz un
cadru confortabil pentru dezvoltarea prin evoluie, ntr-o manier iterativ.
Clientul poate vedea ce se poate face i poate cere mai mult!
Abordarea incrementala se poate transforma usor intr-una codifica si
repara ( build and fix ).
Planificarea
Principalul risc in utilizarea unui model incremental este de a lucra intr-o manierea ad-hoc.
Determinarea unui plan de actiuni este de prima importanta pt succesul abordarii
incrementale. In faza de analiza preliminara se determina scopul proiectului si se incearca
determinarea riscurilor majore ale proiectului, se determina o lista o cerintelor si
constrangerilor mai importante, pt a construi un plan de dezvoltare. Se stabileste natura
fiecarui icrement si ordinea de construire a incrementelor.
Construirea in paralel a incrementelor: risc
Diferite incremente pot fi construite in paralel de diferite echipe.Dupa inceperea fazei de
proiectare a primului increment, echipa de specificare incepe specificarea celui de-al 2-le
increment. Riscul este ca cele 2 incremente sa nu se potriveasca. In mod norma, al 2-lea
trebuie sa-l includa pe primul. Fiecare increment are parti comune cu altele. Este necesara o
buna comunicare si coordonare intre echipele care construiesc in paralel incrementele care au
parti comune (privind implementarea partilor comune). Aceste probleme cresc exponential cu
numarul de incremente.

2.2.10. Ciclul de via n Modelul cu prototipuri.

Notiuni generale
Pentru sisteme noi, in mod special daca ele sunt mari i complexe este puin probabil s se
construiasc o specificaie complet, logic si valid inainte ca sistemul s fie construit i
utilizat. Acest fapt a condus la ideea prototiprii. Ideea este de a permite viitorilor utilizatori
s exerseze cu o prim versiune a sistemului, care poate fi obinuta rapid prin tehnici de
simulare i/sau de interpretare a specificaiilor. In acest ultim caz, limbajele logico-funcionale
sunt n mod sigur chemate s joace un rol important.
Prototipul este o schi a viitorului sistem: el nu are performanele i nu raspunde exigenelor
de calitate ale unui produs finit. Prototipul ofer utilizatorului functionaliti (nu n totalitate)
ale viitorului sistem i interfaa sa. El este dezvoltat ntr-o manier iterativ.
Cerintele sunt extrase si validate iterativ prin utilizarea prototipului. La fiecare iteraie
specificaia sistemului este modificat i detaliat pn cnd prototipul satisface necesitile
utilizatorilor. Un prototip care este utilizat pentru a desprinde cerinele viitorilor utilizatori,
este o "machet exploratoare".

Fig. 2.15. Ciclul de via n Modelul cu prototipuri.

Activitatea de prototipare poate interveni de asemenea in etapa de proiectare, pentru a
experimenta si compara diferite variante. Astfel de prototipuri se numesc "machete
experimentale".

Fig. 2.16. Prototipare in etapa de proiectare.

Aceasta este o versiune ciclic a modelului liniar.

Odat ce analiza cerinelor este ndeplinit i proiectarea este terminat, procesul de
dezvoltare este pornit.
Odat ce prototipul este creat, este dat consumatorului pentru evaluare.
Consumatorul ofer feedback dezvoltatorului care rafineaz produsul conform cu ateptrile
consumatorului.
Dup un numr finit de iteraii, pachetul final este dat consumatorului. n aceast
metodologie, software-ul evolueaz ca rezultat al schimbului periodic de informaii dintre
consumator i dezvoltator. Acesta este modelul cel mai popular din industria IT.
Majoritatea produselor software de succes au fost create folosind acest model, ntruct este
foarte dificil s nelegi toate cerinele utilizatorilor dintr-o singur ncercare. Exist multe
variante ale modelului, din cauza diverselor stilurilor manageriale ale companiilor. Versiuni
noi ale unui produs software apar ca rezultat al modelului cu prototipuri.
n general prototipul simuleaz numai cteva aspecte ale atributelor programului final i
poate fi complet diferit de implementarea final.
Scopul convenional al unui prototip este de a permite utilizatorilor de software s evalueze
propunerile dezvoltatorilor ncercndu-le practic i nu pe baza descrierilor. Utilizarea
prototipurilor poate fi util i end user-ilor pentru a descrie cerine pe care dezvoltatorii nu le-
au considerat, aadar controlarea prototipului poate fi un factor cheie n relaia comercial
dintre dezvoltatori i clieni. Folosirea prototipurilor are o serie de beneficii: proiectantul soft
i dezvoltatorul pot obine feedback de la utilizatori devreme n ciclul de via. Clientul i
contractorul pot vedea dac produsul software respect cerinele pe care se construiete
programul soft. De asemenea, ofer informaii inginerului soft legate de estimrile iniiale i
de acurateea lor, acesta putnd determina dac se pot respecta deadline-urile.

Limbaje folosite Pentru dezvoltarea prototipului.

Pentru dezvoltarea prototipului se folosesc limbaje de nivel foarte inalt: Smalltalk, PROLOG,
LISP, SETL si altele.
In prezent exista limbaje si medii de dezvoltare specializate pentru construirea prototipurilor.
Astfel de limbaje sunt limbajele de generatia a 4-a (4GL). Cu toate ca se poate folosi acelasi
limbaj de programare, atat pentru realizarea prototipului cat si pentru dezvoltarea aplicatiei, se
recomanda ca prototipul sa fie considerat un sistem "inchis", adica sa nu fie folosit ca baza
pentru Ddezvoltarea aplicatiei.
Deoarece:
prototipul a fost dezvoltat prin modificri succesive, de aceea arhitectura sa iniiala a
fost alterat, ceea ce ingreuneaz intreinerea;
prototipul trebuie s corespund cerinelor utilizatorilor numai din punct de vedere
functional. De aceea, in dezvoltarea sa sunt neglijate aspecte ca: eficienta,
adaptabilitatea, compatibilitatea si chiar fiabilitatea[1].

Categorii de utilizare a prototipurilor

Exist dou mari categorii de utilizare a prototipurilor:
Prototipuri cu aruncare
Prototipuri evolutive
Prototipuri cu aruncare:
Numite i prototipuri la captul apropiat. Prototipurile cu aruncare sau rapide se refer la
crearea unui model care va fi pn la urm aruncat n loc s devin o parte integrat a
software-ului final. Dup ce se termin adunarea cerinelor preliminare, un model funcional
simplu al sistemului este construit pentru a arta vizual utilizatorilor cum arat cerinele lor
aplicate ntr-un sistem finalizat. Prototipurile rapide implic crearea unui model al diferitelor
pri ale sistemului ntr-o faz incipient, dup o investigaie relativ scurt.
Metoda folosit la construirea modelului este de obicei informal, cel mai important factor
fiind viteza cu care modelul este pus la dispoziie. Modelul devine apoi punctul de nceput de
la care utilizatorii reexamineaz ateptrile i clarific cerinele. Apoi, modelul prototip este
aruncat i sistemul este dezvoltat din nou, bazat pe cerinele identificate.
Motivul cel mai evident pentru folosirea acestei abordri este c poate fi ndeplinit repede i
Dac utilizatorii primesc un feedback rapid al cerinelor lor, vor putea s le schimbe mai
devreme n procesul dezvoltrii produsului.
Dac un proiect este schimbat dup ce s-a efectuat o munc semnificativ, orice schimbare
minor poate cauza eforturi mari pentru a fi implementat, din moment ce sistemele software
pot avea dependene.
Viteza este crucial n implementarea unui prototip de aruncat, deoarece cu un buget limitat
de bani i timp se poate cheltui puin pe un prototip care nu va fi luat n considerare[1].
Un alt avantaj este abilitatea de a se construi interfee pe care utilizatorii le pot testa. Interfaa
cu utilizatorul este ceea ce acesta vede ca fiind sistemul i vzndu-l n faa sa, i este mult
mai uor s neleag cum va funciona.
Prototipurile pot fi clasificai n funcie de gradul n care seamn cu adevratul produs ca
aparen i interaciune.
O metod de a crea un prototip de aruncat cu fidelitate redus este prototiparea pe hrtie.
Prototipul este implementat cu creionul pe hrtie i mimeaz funcia adevratului produs. O
alt metod prin care se pot modela prototipuri de fidelitate crescut este de a folosi un GUI
(Graphic User Interface) n care se creaz un prototip care arat ca produsul dorit dar nu are
nicio funcionalitate[3].

Rezumatul acestui tip de prototipare este urmtorul:

a) scrierea cerinelor preliminare;
b) proiectarea prototipului;
c) utilizatorul folosete prototipul i specific noile cerine;
d) se repet paii b) i c) pn cnd cerinele nu se mai modific;
e) scrierea cerinelor finale;
f) dezvoltarea produselor reale;

Prototipuri evolutive.
Prototiparea evolutiv este diferit de cea cu aruncare, ntruct scopul principal este de a
construi un prototip foarte robust ntr-o manier structurat i de a-l rafina constant. Prototipul
evolutiv, atunci cnd este construit va forma inima noul sistem. Cnd se dezvolt un sistem
folosind aceast metod, acesta este constant rafinat i reconstruit. Tehnica permite echipei s
adauge trsturi, sau s fac schimbri care nu ar fi putut fi concepute n faza de cerine i
proiectare.
Pentru ca un sistem s fie folositor, trebuie s evolueze prin folosire n mediul pentru care
a fost proiectat. Un produs nu este niciodat terminat, el se maturizeaz constant pe msur ce
mediul de operare se modific. Prototiparea evolutiv are avantajul c toate prototipurile sunt
sisteme funcionale. Dei e posibil s nu aib toate funcionalitile pe care utilizatorii le-au
dorit, ele pot fi folosite ca o baz intermediar pn la livrarea sistemului final [1].
Dezvoltatorii se pot concentra pe dezvoltarea prilor sistemului pe care le neleg, n loc s
lucreze la dezvoltarea ntregului produs [2].
Ideea este de a permite viitorilor utilizatori s exerseze cu o prim versiune a
sistemului. Prototipul este o schi a viitorului sistem, ofer clientului functionaliti (nu n
totalitate) ale viitorului sistem i interfaa pentru utilizator.
Este dezvoltat ntr-o manier iterativ. n fiecare iteraie specificaia sistemului este
modificat i detaliat pn cnd prototipul satisface necesitile utilizatorilor.
Un prototip care este utilizat pentru a desprinde cerinele viitorilor utilizatori, este o "machet
exploratoare". Activitatea de prototipare poate interveni de asemenea n etapa de proiectare,
pentru a experimenta i compara diferite variante. Astfel de prototipuri se numesc "machete
experimentale".
Scopul Modelului Prototip este de a contracara limitrile modelului Waterfall, legate de
stabilirea cerinelor.

Avantaje prototipizare.
Utilizatorii sunt implicai direct n dezvoltare;
Susine tendina utilizatorilor de a-i modifica cerinele pe parcursul ciclului de
implementare;
Este lansat un model funcional al sistemului - utilizatorii pot inelege mai bine modul
de funcionare;
Erorile pot fi detectate mult mai devreme;
 Feedback-ul utilizatorului este mai rapid - obinerea de soluii mai bune;
Timpul i costurile sunt reduse.

2.2.11. Rational Unified Process (RUP)

Model iterativ folosit de IBM din 2003

Fig. 2.17. Model iterative RUP

RUP- Ingineria funcionalitii. Sunt sintetizate necesitile funcionale.
Are la baza 4 etape:
Inception: pentru validarea costurilor i bugetului, studiu de risc, nelegerea cerinelor
Elaboration: analiza domeniului problemei, arhitectura proiectului este stabilit
Construction: construcia sistemului, se obine prima versiune a sistemului
Transition: tranziia la sistemul din producie
RUP defineste 6 principii de urmat:
Dezvolta software-ul in mod iterative
Gestioneaza cerintele
Utilizeaza arhitecturi bazate pe component
Modeleaz in mod visual aplicatiile
Verific calitatea software-ului
Gestioneaz schimbrile in software
Ciclul de dezvoltare al aplicatiei este descompus in subcicluri, fiecare ciclu este cumpus din
faze.
Fazele sunt:
Initializare
Elaborare
Constructie
Tranzitie
RUP iniializare
Un document de viziune
Un model Use-case initial (10-20% complet)
Un plan de proiect cuprinzand fazele si iteratiile
O analiza a riscurilor
Un model de bussines daca e necesar
Unul sau mai multe prototipuri
RUP Elaborare
Cea mai critica faza a proiectului
Cele mai importante componente ale sistemului sunt dezvoltate acum
Un model use-case (80% complet)
Capturarea cerintelor suplimentare
Arhitectura generala a sistemului
Un prototip executabil
Modelul de bussinis si riscurile revizuite
Planul de realizare al proiectului
Un manual preliminar de utilizare (optional)
RUP Construcie
Restul componentelor nerealizate in faza anterioara constuite si integrate in produs
Toate componentele sunt testate
Rezultatul trebuie sa fie un produs pregatit pentru a fi livrat utilizatorului
Este realizat manualul de utilizare
RUP - Tranzitie
Produsul este instalat\livrat utiliatorului
Utilizatorul testeaza produsul
Defectele sunt raportate si fixate
Aceasta faza poate fi foarte simpla sau foarte complexa depinzand de tipul produsului (ex.
Aplicatie desktop, aplicatie pe mai multe niveluri)
RUP - Iteratii
Fiecare faza din RUP poate fi descompusa in iteratii
Avanatajele metodelor iterative
Riscurile sun gestionate mai bine
Schimbarile sunt mai usor de controlat
Calitate mai buna
RUP - Unelte
Rational RequisitePro--Keeps the entire development team updated and on track
throughout the application development process by making requirements easy to write,
communicate and change.
Rational ClearQuest--A Windows and Web-based change-request management product
that enables project teams to track and manage all change activities that occur throughout the
development lifecycle.
Rational Rose 98--The world's leading visual modeling tool for business process modeling,
requirements analysis, and component architecture design.
Rational SoDA--Automates the production of documentation for the entire software
development process, dramatically reducing documentation time and costs.
Rational Purify--A run-time error checking tool for application and component software
developers programming in C/C++; helps detect memory errors.
Rational Visual Quantify--An advanced performance profiling tool for application and
component software developers programming in C++, Visual Basic, and Java; helps eliminate
performance bottlenecks.
Rational Visual PureCoverage --Automatically pinpoints areas of code not exercised in
testing so developers can thoroughly, efficiently and effectively test their applications.
Rational TeamTest--Creates, maintains and executes automated functional tests, allowing
you to thoroughly test your code and determine if your software meets requirements and
performs as expected.
Rational PerformanceStudio--An easy-to-use, accurate and scalable tool that measures
and predicts the performance of client/server and Web systems.
Rational ClearCase--Market-leading software configuration management tool, giving
project managers the power to track the evolution of every software development project.

2.3. Instrumente CASE pentru dezvoltarea sistemelor informatice

Proiectarea Sistemelor/Programelor Asistat de Calculator sau cu Ajutorul Calculatorului
(CASE) provine de la urmtoarele expresii:
Computer Aided Software Engineering;
Computer Aided Systems Engineering;
Computer Assisted Software Engineering;
Computer Assisted Systems Engineering.
Toate cele patru construcii se regsesc n literatura de specialitate.
Ingineria asistat de calculator (CASE) instrumente de asisten a ciclulilor de dezvoltare
i evoluie software
Prin instrumente CASE nelegem aplicaiile software care-i sprijin/ ajut pe analiti,
proiectani, programatori, inclusiv personalul de testare i ntreinere, s analizeze, s
proiecteze, s implementeze (cel puin parial), s modifice (extind), respectiv s
construiasc teste pentru sistemele informatice.
Tendina ns este de a se ntrebuina mai mult systems n loc de software, din dorina
de a scoate n relief faptul c prin CASE se pot realiza lucruri de o mai mare complexitate.
La nceput s-a pornit de la ideea c i activitile de realizare a sistemelor informatice s se
desfoare dup o disciplin de tip inginerie", prin reunirea eforturilor specialitilor de
gsire a unor tehnici comune de dezvoltare a sistemelor/programelor, a unor metodologii
standard, a unor instrumente ce automatizeaz lucrul - similare celor din inginerie".
Problema CASE-ului a devenit foarte important la mijlocul anilor 1980, cnd hardul s-a
extins prin seria PC-urilor, iar reelele au devenit mai puternice, constituindu-se sistemele
distribuite.
Tehnologia CASE este un domeniu de integrare i sintez ce ncorporeaz elemente din
proiectarea asistat de calculator, ingineria programrii, proiectarea sistemelor
informatice, baze de date i alte domenii ale informaticii.
Au fost create astfel o serie de instrumente software pentru asistarea realizrii de produse
informatice n scopul uurrii activitilor de proiectare a SGBD-urilor.
Dup apariia CASE-ului, a intervenit un alt acronim pentru a descrie un semn al schimbrii,
el fiind - I-CASE, pentru Integrated CASE.
I-CASE se refer la toate aspectele integrrii, chiar dac sistemele sunt deschise sau nu.

Fig.2.19. Tehnologia CASE

Istoric
Evoluia instrumentelor CASE:
Programarea considerata o forma de arta anii 60
Metode structurate 1965
Tehnici de modelare a datelor 1970
Limbaje de generaia a patra 1975
Instrumente de proiectare a specificaiilor software 1980
Instrumente pentru prototipizarea interfeei utilizator 1985
Instrumente pentru generarea automat a codului 1990
CASE-uri integrate, CASE-uri orientate obiect 1995
Component Software (Java)1996

Prima generaie CASE

Un instrument pentru o anumita etapa a procesului software
planificarea strategic (la nivelul sistemelor complexe)
etapa de analiz
etapa de proiectare
generare de cod
Caracteristici:
ofer interfa grafic pentru utilizator
 instrumente de dimensiuni mici, volum mare de date
generare de cod se refer la definirea datelor (ecrane, rapoarte, definiii, fragmente de cod).

A doua generaie de produse CASE

Aceleai faciliti ca i din prima generaie i n general aceleai tipuri de instrumente +
Generarea de cod s se realizeze pe main-frame-uri pe care s existe un generator central de
cod i care s stocheze codul generat ntr-un depozit.
Permit lucrul n echip pentru elaborarea de proiecte de obicei complexe
Asigur faciliti de management de proiect.
Acestei generaii i aparin CASE-uri care ofer suport pentru ntreg ciclul de via
(integratedCASE sau I-CASE)
ofer suport pentru realizarea proiectelor folosind mai multe metode de analiz i proiectare

Generaia a treia de produse CASE

cuprinde CASE-urile ultimei perioade, numite i medii sau Workbench (colecie de
instrumente CASE i de alte componente integrate care asigur suportul pentru majoritatea
tipurilor de interaciuni ntre componentele
mediului i ntre utilizator i mediu)
Generaia a treia de CASE presupune utilizarea acestora n organizaii elaboratoare de
software i este generaia actual care ofer:
faciliti individuale pe PC
faciliti la nivel de proiect pe LAN
faciliti la nivel de organizai pe mainfram.

Fig. 2.20 Instrumente, medii de lucru, medii de dezvoltare

 Fig.2.21. Instrumente CASE i procesul software

Faciliti Instrumente CASE.

Instrumentele CASE trebuie s asigure, n principal, urmtoarele faciliti:
1. Suport pentru metodele i tehnicile de analiz i proiectare concretizat n editoarele de
diagrame i text;
2. Stocarea datelor ce descriu sistemul n dicionarul central de date, numit repository i
regsirea i vizualizarea lor prin intermediul browsere-lor;
3. Verificarea descrierii sistemului din punct de vedere al consistenei i completitudinii;
4. Suport pentru realizarea prototipurilor (limbaje de nivel nalt i generatoare de
aplicaii);
5. Suport pentru conducerea proiectului. Deosebit de utile sunt instrumentele de
planificare i estimare a timpului i resurselor necesare realizrii sistemului, precum i
gestiunea versiunilor proiectului;
6. Generarea documentaiei de realizare a sistemului
7. Acoperirea ntregului ciclu de realizare a sistemelor. Instrumentele CASE trebuie s
asigure nu numai suportul tehnic pentru o anumit etap, ci s faciliteze tranziia dintr-
o etap a ciclului de realizare n alta, n ambele direcii;
8. Generarea automat a codului de program pornind de la specificaiile de proiectare.
Codul de program poate fi generat total sau parial n unul sau mai multe limbaje;
 9. Inginerie inversat (Reverse Engineering). Permite revenirea din fazele realizrii
sistemelor informatice n fazele de nceput, opernd eventualele modificri care au
intervenit;
10. Adaptabilitate i extensibilitate. Utilizarea instrumentelor trebuie s poat fi adaptat
la cerinele specifice ale utilizatorilor i s permit extinderea cu noi rutine sau
instrumente.
Obiectivul principal al CASE.
Punerea n practic a produselor-program de proiectare i realizare a softului cu ajutorul
calculatorului.
Instrumentele oferite de CASE sunt utilizabile de la faza de definire a cerinelor pn la
ntreinerea fizic a produsului informatic.
Analiza i proiectarea, bazate pe conceptele i metodele structurale - sunt elementele forte ale
instrumentelor CASE,
n ultimii ani CASE a acordat atenie sporit analizei, proiectrii i programrii orientate pe
obiecte.
Obiectivele urmrite prin utilizarea instrumentelor CASE sunt:
Reducerea timpului i costului de realizare a sistemelor
Specificarea corect i complet a cerinelor sistemului.
Detectarea i corectarea la timp a erorilor i a deficienelor sistemului.
Elaborarea i actualizarea documentaiei de realizare a sistemului.

Caracteristicile CASE-urilor sunt:

CASE este vzut ca un set de instrumente folosite n procesul de realizare a softului. Se tie c
acest proces presupune parcurgerea unor faze strns legate ntre ele. Din cauza
particularitilor fiecreia dintre ele, i mijloacele de utilizare vor fi altele.
Marea varietate a modurilor de lucru ale utilizatorilor conduce la o multitudine de instrumente
CASE, dintre care unele pot fi pentru grafice, cu o mare diversitate de operaiuni specifice,
altele urmresc controlarea listelor multidimensionale, n timp ce o alt categorie ofer medii
de lucru diverse din care utilizatorul poate s aleag o variant anume.
Simbolurile grafice trebuie s aib o semnificaie predefinit. Uneori simpla legare a unui cerc
cu un dreptunghi are un cu totul alt neles dect desenul n sine.
In fiecare instrument CASE trebuie s existe un sistem de verificare i validare, altceva dect
simpla depistare a erorilor.
CASE, n totalitatea lui, trebuie s aib o derulare bidirecional. Nu este de ajuns s existe o
suit de instrumente necesare analizei, proiectrii, generrii de coduri ale programelor, toate
folosite ntr-o singur direcie. O etap important din ciclul de via al sistemelor o constituie
ntreinerea acestora, care necesit prelucrri n sens invers, de la codurile programelor la
reproiectarea sistemelor.
CASE-urile trebuie s fie deschise, oferindu-se astfel posibilitatea interconectrii
instrumentelor CASE ale diverilor furnizori i s permit condiii de lucru pentru mai muli
utilizatori n acelai timp.
Multe instrumente, ndeosebi cele ce lucreaz n mediu grafic, necesit unele tipuri de
faciliti de descompunere.
Instrumentele proiectrii conceptuale a bazelor de date i diagramele fluxurilor de date sunt
cele mai utile cnd se descriu prelucrrile la un nivel superior i obiectele implicate, cu o
descompunere a lor n mai muli pai, pn la nivelul cel mai de jos. n plus, descompunerile
elementare, superioare, cum sunt datele elementare ale unei diagrame a fluxului de date,
trebuie s fie evideniate pe nivelurile inferioare, fie automat, fie n timpul verificrii i
validrii.
Deplasarea trebuie s fie posibil, fie pentru trecerile de sus n jos, pe vertical, ale nivelurilor
de descompunere, fie ntre instrumentele de tip CASE, pe orizontal, pentru scoaterea n
eviden a integrrii perfecte a acestora.
Automatizarea poate s fie diferit de la un instrument CASE la altul sau de la o etap din
ciclul de via al sistemelor la alta.
Cele mai multe dintre fazele proceselor de realizare a sistemelor sunt semiautomate - cum ar
fi cerina ca utilizatorul s introduc ceva sau s ajute la normalizarea bazei de date.
Din aceast cauz CASE-ul este vzut n viitor mai mult ca un mijloc de cretere a
productivitii, dect ca un sistem automat fr programatori.

Avantaje utilizare CASE.

Folosirea sistemelor CASE este motivat n principal de urmtoarele avantaje:
Reducerea complexitii logicii de descriere a sistemului;
Posibilitatea de a alege dintre mai multe variante de proiectare;
Creterea vitezei de realizare a sistemelor;
Realizarea succesiv a componentelor unui sistem;
Creterea integrrii;
Consolidarea disciplinei de proiectare;
Oferirea unei interfee de integrare;
Folosirea depozitelor modularizate;
Automatizare activiti:
- Editoare grafice pentru dezvoltarea modelului sistemului;
- Dicionare de date pentru gestionarea entitilor proiectrii;
- Constructor GUI pentru construirea interfeei utilizator;
- Debugger-e pentru a sprijini gsirea erorilor n program;
- Traductoare (translator) automate pentru generare de noi versiuni de program.

Literasrura.
1. Instrumente CASE Ciprian Dobre ciprian.dobre@cs.pub.ro
Universitatea Politehnica Bucuresti - Facultatea de Automatica si Calculatoare.
http://andrei.clubcisco.ro/cursuri/f/f-sym/4idp/3_Intrumente_CASE.pdf
2. www.seap.usv.ro/ .../Instrume...tefan cel Mare University of Suceava.
Instrumente CASE. Curs nr. 7. Erwin data modeler
TEMA 3.
Procesele ciclului de via.
Proces conform standardului ISO/IEC 12207. Procese primare. Procesele organizaionale.
procese auxiliare. Procesele conform standardului ISO 15288

Fig. 3.1. Ce este process?

3.1. Noiunea de Proces conform cu standardul ISO/IEC 12207 - Consecutivitatea fixat a
evenimentelor, realizat printr-un grup de activiti legate logic, care utilizeaz resursele
organizaiei pentru obinerea rezultatului la realizarea scopurilor organizaiei.
n conformitate cu standardul ISO/IEC 12207: toate Procesele CV
Se mpart n 3 grupe:
5 procese principale (primare),
8 procese auxiliare, i
4 Procese organizaionale.
n conformitate cu standardul ISO/IEC 12207:
Procesele organizaionale includ patru procese realizate de ctre o organizaie, care
stabilete i pune n aplicare o structur de baz format din procesele asociate ciclului de
via i de personal i care are grij de mbuntirea continu a acestei structurii i a
proceselor.
Procese primare constau din cinci procese, care formeaz partea de baz a ciclului de via
a produselor program. Partea primar este cea care iniiaz i realizeaz dezvoltarea,
exploatarea sau meninerea produsului program. Componentele ei sunt achizitorul, furnizorul,
dezvoltatorul, exploatatorul i menintorul produsului program.
Procesele auxiliare includ opt procese, care susin executarea altor procese cu scopul
garantrii succesului i calitii finale. Un proces auxiliar este lansat n execuie la necesitate
de un alt proces.

3.1.1. Procese primare

achiziie definete activitile de achizitor, organizaia care achiziioneaz un
sistem, un PP sau un serviciu soft;
aprovizionare (livrare) definete activitile de furnizor, organizaie care
livreaz sistemul, PP sau presteaz serviciul solicitat de achizitor;
elaborare/dezvoltare - definete activitile de dezvoltator, organizaia care
definete i dezvolt produsul program;
exploatare - definete activitile operatorului organizaie, care ofer servicii
de operare a unui sistem informatic n mediul su pentru utilizatorii si;
ntreinere (mentena) - definete activitile de mentenan a organizaiei
care ofer serviciul de meninere a PP, de gestionare a modificrilor pentru a-l
menine actualizat i operaional. Acest proces include activitile de migrare i
de retragere din uz a PP.
 Procese organizaionale

Managmentul Creare infrastructu Perfecionarea

colarizare
proiectelor a proiectului CV

Procese primare
Fig. 3.2. Sstandardul ISO/IEC 12207:

Achiziia livrarea Elaborarea

Fi Exploatarea Mentenana
Fig. 3.1. Procesele n conformitate cu standardul ISO/IEC 12207

Procesele auxiliare

Documentarea Asigurarea Managementul Soluionarea

calitii configuraiei problemelor

Verificarea Validarea Revizuirea

produselor Auditul
produswlor comun

Coninutul proceselor primare. Tabelul 3.1

Proces
Aciuni Intrare Ieire
(executor)
Achiziie Pregtirea cererii de Decizia privind Studiu de fezbilitate privind
(achizitor) oferte (licitaie) lansarea lucrrilor de oportunitatea implementrii
Pregtirea i implementare a SI Sarcina tehnic pentru
actualizarea Rezultatele analizei crearea SI
contractului activitii Contract de furnizare/ creare
Monitorizarea achizitorului a SI
furnizorului Rezultatele analizei Actele de primire a etapelor
Acceptarea i pieei produselor lucrrilor
completarea program Actul testrilor de
Planul de primire/predare
furnizare/dezvoltare
Test complex al SI
Furnizare Iniierea Caietul de sarcini Decizia de participare
(dezvoltatorul/ Pregtirea Decizia conducerii de Oferta comercial/ cerere de
furnizorul)) rspunsului la participare participare la licitaie
cererea de oferte Rezultatele licitaiei Contract de furnizare/ creare
Pregtirea Sarcina tehnic a SI
contractului Planul de Planul de management al
Planificarea executrii management al proiectului
Executare i control proiectului Realizarea/corectarea
Verificare i evaluare SI elaborat i Actul testrilor de
Furnizarea SI documentat primire/predare

Dezvoltare Pregtirea ST pentru elaborarea Modelul utlizat al ciclului de

(dezvoltatorul) Analiza cerinelor
Proiectarea
arhitecturii
Analiza cerinelor
ctre software
Proiectarea
arhitecturii softului
Proiectarea de detaliu
a softului
Scrierea programelor
i testarea
Integrarea modulelor
Testarea de calificare
Integrarea de sistem
Testarea de sistem
Instalarea softului
Acceptarea meninerii
softului
sistemului via, stadardele de
ST pentru elaborarea dezvoltare
sistemului, modelul Planul lucrrilor
ciclului de via Coninutul subsistemelor,
Subsistemele SI componentele tehnice
Specificaiile Specificaiile cerinelor
componentelor soft referitor la componentele
Arhitectura program
produselor program Coninutul componentelor
Materialele program, interfeele BD,
proiectrii de planul de integrare
deataliu a produselor Proiectul BD, specificaiile
program interfeelor componentelor
Planul de integrare, program, cerinele pentru
testele teste
Arhitectura SI, Codul modulelor program,
produselor program, actele testrilor unitare
documentaia SI, Evaluarea coformitii setului
testele de programe cerinelor ST
Evaluarea coformitii
produsului program, BD,
echipamentelor tehnice i
setului de documente
cerinelor ST

3.1.2. Procesele auxiliare.

documentarea nregistrare a inf. produse de un CV;
managementul configuraiei - activitile de gestiune a configuraiei;
asigurarea calitii - activitile de asigurare obiectiv a conformitii
produselor program i proceselor cu specificaiile lor;
verificarea - activitile pentru verificarea produselor program;
validarea - definete activitile pentru atestarea PP;
revizuirea comun - activitile de evaluare a strii i produselor unei activiti;
auditarea - activitile pentru stabilirea conformitii cu cerinele, planurile i
clauzele contractuale;
soluionarea problemelor - analizarea i ndeprtarea problemelor.
Procesul Asigurarea calitii (quality assurance process) presupune garanii c sunt
respectate cerinele conform caietului de sarcini la elaborarea S.I.
Procese de documentare (documentation process) descrierea formalizat a informaiei
elaborat pe parcursul crerii SI
Configuration management process presupune aplicarea procedurilor administrative i
tehnice pe tot parcursul C.V. Soft pentru a controla starea componentelor, managmentul
modificrilor, descrierea i ntocmirea rapoartelor despre starea componentelor i solocitrilor
de modificare componente, asigurarea itegritii i copatibilitii componentelor soft,
managmenul pstrare i livrare soft.
Processe de verificare (verification process) const n determinarea faptului c produsul
program satisface n totalitate cerinelor sau condiiilor determinate de aciunea precedent
Procesul de validare (validation process) presupune constatarea c produsul corespunde n
totalitate cu cerinele naintate pentru a realiza un funcional concret.
(joint review process)
, ()
(audit process)
, .
(problem resolution process)
( )

3.1.3. Procesele conform ISO 15288

Procese contractuale
Procesele ntreprinderii
Procesele proiectului
Procesele tehnice
Procese speciale
Procese contractuale:
achiziie (soluii interne sau ale unui furnizor extern);
furnizare (soluii interne sau ale unui furnizor extern).
Procesele ntreprinderii:
managementul mediului extern;
management investiional;
managementul ciclului de via a produselor program;
managementul resurselor;
managementul calitii.
Procesele proiectului:
planificarea proiectului;
estimarea proiectului;
controlul proiectului;
administrarea riscurilor;
managementul configuraiei;
managementul fluxurilor informaionale;
adoptarea deciziilor.
Procesele tehnice:
identificarea cerinelor;
 analiza cerinelor;
elaborarea arhitecturii;
implementarea;
integrarea;
verificare;
transmiterea ctre beneficiar;
validarea (atestarea);
exploatarea;
meninerea;
retragerea din uz.
Procese speciale:
determinarea i realizarea legturilor reieind din sarcini i scopuri.

Tabelul 3.2. Etapele crerii sistemelor conform ISO/IEC 15288

Etap Descriere
crt
1 Elaborarea Analiza necesitilor, formularea concepiei i
concepiei alegerea soluiilor de proiect
2 Proiectarea Elaborarea proiectului tehnic al sistemului
3 Realizarea Construirea sistemulu
4 Exploatarea Lansarea n exploatare i utilizarea sistemului
5 Mentenana Asigurarea funcionrii sistemului
6 Retragerea din Terminarea utilizrii, demontarea, trecerea n
uz arhiv a sistemului

TEMA 4. Standarde pentru modelarea ntreprinderii

Principii Fundamentale. I. Standarde cadru. II. Metamodele/Concepte. III. Standarde
Proiectare, Limbaje, Metode. IV. Business Process Choreography. V. Formalismele
reprezentarii Software. IV. Canale de comunicare, Semantica mesajelor, Modele de
inregistrare, Dictionare conceptuale,

Principii Fundamentale Enterprise Models (EM).

Due to the complexity and multi-faceted nature of enterprise organizations and especially
industrial organizations, enterprise modeling frameworks should respect the following
principles:
 Principiul # 2
Mai multe Puncte Principiul # 3
Principiul # 1
de vedere la
modelare Trei tipuri
Natura pluralist a
fundamentale
modelelor
De fluxuri

Principii
fundamentale de
modelare a Principiul # 6
ntreprinderilor
Principiul # 4 Conceptul de
modelare pe
Procese versus niveluri
ageni Principiul # 5
Sincronizarea
proceselor de
afaceri (BP)

Fig.4.1. Principii fundamentale n modelarea ntreprinderilor.

Principle #1: Plural nature of enterprise models.

This means that there is no such thing as an enterprise model. There are enterprise models.
Indeed, any business entity, be it a manufacturing plant, a R&D department, a branch of a
company, a supply chain or a virtual enterprise, is so complex that it is impossible to represent
it by one single model expressed in one language. Several models will be necessary and,
indeed, the enterprise model is an assemblage of submodels, each depicting some specific
aspects.
Principle #2: Concept of modeling views.
The concept of modeling view or viewpoint is a mechanism that allows to focus on some
aspects of a system while discarding others to manage structural complexity. A modeling
framework will be powerful, complete and consistent if it provides a minimal set of non-
overlaping views to cover all essential aspects of the system.
 Figura 4.2. Principiile 1 i 2

Principle #3: Three fundamental types of flows.

There are three fundamental types of flows circulating within or across any type of enterprises
(excluding financial flows):
- Material flows (made of physical objects such as raw materials, semi-finished parts,
products, components, tools),
- Information flows (made of information and decision objects such as orders, documents,
data, computer files, emails, phone calls),
- Control flows (or workflow, i.e., logical execution sequences of tasks).
Principle #4: Processes versus agents.
At a macro-level, any enterprise can be viewed as a large collection of:
- Concurrent processes (called business processses) executed to achieve business goals and
competing for resources on one hand, and
- Interacting agents, or functional entities (i.e., human or technical resources), executing
processes on the other hand.
The art of management is to make sure that in fine the agents (i.e., the doers) execute the
processes in an efficient, effective and economic way to achieve business objectives.
Principle #5: Business process synchronization.
There are three fundamental types of business process synchronization:
1. Event-based synchronization: Events in the form of messages, requests, orders or timers
can be generated by one process and used to trigger other processes (e.g., EV2 in Figure 2).
2. Object-based synchronization: A step in a process control flow may need availability of
objects produced by one or more steps of different processes.
3. Resource-based synchronization: Execution of a step in a process may need availability of
some resource(s) that can also be needed by another step in another process (this is a resource
conflict that needs to be solved by means of priority rules or a conflict resolution mechanism).
Principle #6: The concept of modeling levels.
Enterprise models can be developed at three generic levels as proposed in CIMOSA, GERAM
and ISO 14258 (1998). These are:
- Requirements definition: Used to represent the voice of the users, i.e., what is needed,
expressed in a detailed and unambiguous way in a user-orientated or descriptive language.
- Design specification: Used to formally specify one or more solutions satisfying the set of
requirements, to analyze their properties and to select the best one. These models are
expressed by means of a formal and computer executable language (prone to model
validation, performance analysis or system simulation).
- Implementation description: Used to state in detail the implementation solution taking into
account physical technical constraints. Operational models are defined at this level.
Literatura ultimilor ani e inundat de articole orientate spre identificarea unui metamodel i
unificarea conceptelor general valabile pentru modelarea ntreprinderii. Iat doar cteva
iniiative:
Propuneri de unificare a modelelor ERP (PURDUE, BAAN, SAP) [Dalal, 2004]
construirea unei baze teoretice unice, necesitatea introducerii elementelor de QS
(Quality of Service), perspective multiple care s includ i perspectiva economc.
Object Process Metodology [Soderborg, 2003] - obiectele (ce?) i procesele (cum?)
sunt primitive de modelare cu importan egal, dar un proces nu poate exista dect
dac transform un anumit obiect. Metodologia introduce un nou formalism grafic.
 Levi&Arsanjani [Levi, 2002] ncearc definirea unei metodologii de armonizare a
arhitecturii afacerii cu cea software, pornind de la concepte organizaionale precum:
entiti de ntreprindere, obiective, procese, reguli economice.
Creu [Creu, 2005] n respectivul articol propune modelarea ntreprinderii pornind
de la o arhitectur SOA (Service Oriented Architecture) i un metamodel, ce extinde
UML, cu urmtoarele stereotipuri: resurse, produs, proces, operaii, reguli (i
mecanism de prioriti), roluri (actori), context (obiective i set de reguli).
Marshall [Marshall, 2000] definete un metamodel i extensii UML (stereotipuri)
pentru conceptele fundamentale: scop, proces, entitate, organizaie.
Eriksson i Penker [Eriksson, 2000] definesc un metamodel UML ce descrie relaii
ntre urmtoarele concepte de modelare: proces economic (activiti executate ntr-o
anumit ordine, dependente de anumite condiii i evenimente), activiti (pai ai
procesului), eveniment (activeaz un proces sau este generat de acesta), resurse, scop,
reguli economice.
Metamodelul olandez [Jokers, 2003] - o abordare ce const n definirea de concepte
general valabile pentru a descrie aspecte ale unui sistem, precum structura,
comportamentul i informaiile, pentru trei perspective de modelare preluate de la
standardul ISO 10746 (modelul economic, aplicaii, tehnologii).
Fr standarde nu vom obine interoperabilitate [Kosanke, Standardisation in
Interoperability IMS Workshop Zrich, November 15/16, 2007]. Astfel, activitatea de
standardizare, din ultimii ani, ce se adreseaz modelrii ntreprinderii, urmrete trei
direcii principale de aciune:
(1) Elaborarea de limbaje pentru descrierea i execuia proceselor economice;
(2) Elaborarea de dicionare e-business (Ontologia);
(3) Concepte i metamodele economice, ntr-o manier independent de un anumit limbaj.
 DA
F, M
ISO 14258
ISO 15704

GA
ISO19440

, TO
ISO15414

AF
BPDM,

, FE
Profile for EDOC

471
I. Concepte / Metamodele

E1
IEE
Limbaje
46, Metode
ISO 10303/11
uri

DFD
107

ISO 15909
r k-

IDEF
ISO

UEML, XML,
wo

UML
BPMN
me

07

ebXML-BPSS
122
Fra

II. Proiectare/ Modelare

ISO
V.
88,

UEML, ebXML, BPML

152

Coregrafie procese
BPEL&BPEL4WS
EC

XPDL, ISO 18629

O/I
S
9, I

III. Formalizme de Reprezemtare software

943
O1
, IS

Semantica mesajelor
AN

Registre modele Dicionare concepte

Comunicaia EDIFACT, ASICUDA,
HM

ROSETTANET edXML ROSETTANET

HTTP ISO 15531-MANDATE
C

UOOI ISO 18629-PSL

RMI
ZA

ISO 16668-BSR MOF-CWR OMG-SBVR

SOAP ISO 10303-STEP OMG-SBVR Mesagerie
CORBA-IOP

Figura 4.3. Piramida standardelor pentru modelarea ntreprinderii.

Preluat i actualizat din - Enterprise Engineering - A New Organizational Discipline. Liviu-Gabriel
CREU file:///C:/Users/User/Desktop/Cretu_Liviu_IE_Aug2006.pdf (1)

I. Standarde cadru (Framework-uri)

Framework - An essential supporting structure of a building, vehicle, or object.
Cuvntul englez framework definete, n termeni generali, un ansamblu standardizat de
concepte, practici i criterii pentru a se aplica asupra unui tip particular....

Cadrul Zachman:
n 1997, John A. Zachman, a propus o metod de conceptualizare a elementelor implicate n
construirea arhitecturii oricrui sistem informatic, metod care poart denumirea de cadru de
lucru Zachman (Zachman Framework). El a evideniat faptul c proiectarea unui sistem
informatic trebuie privit din mai multe puncte de vedere i realizat n mai multe etape,
pentru specificarea fiecreia dintre acestea fiind necesare diagrame i documentaie specific.
Cadrul Zachman este o ontologie a ntreprinderii i este o structur fundamental pentru
Enterprise Architecture, care ofer un mod formal i structurat de vizualizare i definirea unei
ntreprinderi.

Ontologia este o schem de clasificare de dou dimensiuni care reflect intersecia dintre dou
clasificri istorice. Primele sunt interogative primitive: Ce, Cum, Cnd, Cine, Unde, i Dece.
Cea de a doua este o derivat din conceptul filosofic de reificare, transformarea unei idei
abstracte n relaii dintre obiecte concrete (REIFICRE (dup fr. rification; de la lat. res lucru) s.
f. (FILOZ.) Proces n cursul cruia relaiile sociale mbrac forma unor relaii obiectuale, iar omul nsui
devine din subiect (agent contient) al proceselor sociale obiectul acestora, asemenea unui lucru. Conceptul a
fost formulat de G. Lukcs i mai ales de Th. Adorno.). Transformrile de reificare Zachman sunt:
Identificarea, definirea, Reprezentare, Specificatie, Configurare i Relaii.
Cadrul Zachman nu este o metodologie n care aceasta nu implic nicio metod specific sau
proces de colectare, gestionare, sau folosind informaiile pe care o descrie. Mai degrab, este
o ontologie prin care o schem de organizare a unor artefacte arhitecturale (cu alte cuvinte,
documente de proiectare, caietul de sarcini, i modele) este folosit pentru a lua n considerare
att obiectivele artefact (de exemplu, proprietar de afaceri i constructor) ct i anumite
probleme (de exemplu, date i funcionalitate).
Acest cadru este explicat ca, de exemplu:
un cadru de organizare si analiza a datelor
un cadru pentru arhitectura de ntreprindere
un sistem de clasificare, sau schema de clasificare
o matrice, de multe ori ntr-un format de matrice 6x6
un model bidimensional sau un model analitic.
o schem bidimensionala, folosit pentru a organiza reprezentrile detaliate ale ntreprinderii.

Fig. 4.5. Modelul Zchman (http://www.ia.ase.ro/Sie/SIE-4-2013.pdf)

Cadrul Zachman rezum o colecie de perspective implicate n construcia arhitecturii de
ntreprindere. Aceste perspective sunt reprezentate ntr-o matrice bidimensional, care
definete de-a lungul rndurilor tipul de pr interesate i de-a lungul coloanelor - aspectele
arhitecturii. Cadrul nu definete o metodologie pentru o arhitectura. Mai degrab, matricea
este un ablon care trebuie s fie completat de obiectivele / norme, procese, material, roluri,
locaii, i evenimentele solicitate n mod specific de ctre organizaie. Modelare n continuare
prin mapare ntre coloane n cadrul framework-ului identific lacunele n stare documentat a
organizaiei.
 Cadrul ISO 19439:2006
This standard was last reviewed and confirmed in 2015. Therefore this version remains current.
(SO 19439:2006 specifies a framework conforming to requirements of ISO 15704, which serves as a
common basis to identify and coordinate standards development for modelling of enterprises,
emphasising, but not restricted to, computer integrated manufacturing. ISO 19439:2006 also serves as the
basis for further standards for the development of models that will be computer-enactable and enable
business process model-based decision support leading to model-based operation, monitoring and
control.)

Cadru ISO 19439 dorete s ofere o "baz conceptual unificat pentru modelul bazat pe
ingineria ntreprinderii care permite coeren, convergena i interoperabilitatea diferitelor
metodologii de modelare i instrumente de sprijin. Cadrul nu cuprinde procese metodologice,
Este neutru n acest sens".

Fig. 4.6 Trei dimensiuni pentru modelare Intreprinderii Cadru ISO 19439.
Acest standard specific un cadru, care "servete ca o baz comun pentru a identifica i de a
coordona dezvoltarea standardelor pentru modelarea ntreprinderilor, dar nu se limiteaz la,
producie integrat cu procese de calcul. De asemenea, servete ca baz pentru standardele
suplimentare pentru dezvoltarea unor modele care vor fi suportate de calculator i permite
modelului bazat pe suport decizional de conducere i operare s fie baza pentru modelul de
monitorizare i control ".
ISO 19439 definete trei dimensiuni pentru modelare Intreprinderii:
 Faza de Modele entrepriz: "Fazele Modelului ntreprinderii se bazeaz pe ideea c
modelele de ntreprinderi au un ciclu de viata care este legat de ciclul de via al entitii
modelate. Fazele definite n standardul sunt: Identificarea domeniu, Definiie Concept,
Definirea Cerintelor, Specificaia de Proiectare, Descrierea Implementrii, Operaiunea de
domeniu, Dezafectarea Definiiei".
Dimensiunea punctelor de vedere: ". Se bazeaz pe ideea c att modelatori de companie i
utilizatorii pot filtra observaiile sale din lumea real prin vizualizri distincte. Punctele de
vedere predefinite sunt: Function View, Information View, Resource View, Organization
View/Decision View."
Dimensiunea generitilor: ". Aceasta definete dimensiunea de la concepte de modele
generale la particulare. Standardul definete trei niveluri de genericitate: Generic Level,
Partial Level, Particular Level"
Cadrul ISO/IEC 15288
ISO / IEC 15288 este un standard al sistemelor ingineresti care acoper procesele i etapele
ciclului de via. Planificarea iniial pentru standardul 15288 ISO / IEC: 2002 (E) a nceput
n 1994, atunci cnd necesitatea unui cadru comun pentru procese ale sistemelor ingineresti a
fost recunoscut. Standardul MIL acceptat anterior STD 499A (1969) a fost anulat, dup o
not de la SECDEF, care interzice utilizarea celor mai multe standarde militare ale Statelor
Unite ale Americii fr o derogare. Prima ediie a fost emisa la data de 1 noiembrie 2002.
Stuart Arnold a fost editor i Harold Lawson a fost arhitectul a standardului. n 2004 acest
standard a fost adoptat ca IEEE 15288.

Figura 4.7. Standard Life Cycle Processes View: Overview

https://buildsecurityin.us-cert.gov/swa/process-view/overview
Standardul definete procesele mprite n patru categorii:
1) Tehnic
2) Proiectul
3) Acordul
4) Intreprindere
Fiecare proces este definit printr-un scop, rezultate, i activiti. ISO 15288 cuprinde 25 de
procese care au 123 de rezultate obinute din 403 activiti. Exemple ale etapelor ciclului de
via, descrise n document sunt: concept, dezvoltare, producie, utilizare, suport, i de
pensionare.
Cerine prilor interesate de proces Definition (clauza 6.4.1)
Cerine de analiz de proces (clauza 6.4.2)
Procesul de proiectare de arhitectur (clauza 6.4.3)
Procesul de implementare (clauza 6.4.4)
Procesul de integrare (clauza 6.4.5)
Procesul de verificare (clauza 6.4.6)
Proces de tranziie (clauza 6.4.7)
Procesul de validare (clauza 6.4.8)
Procesul de operare (clauza 6.4.9)
Procesul de ntreinere (clauza 6.4.10)
Procesul de eliminare (clauza 6.4.11)
Cadrul ISO/IEC 10746-3:2009
Tehnologia informaiei - model de referin - prelucrare distribuit deschisa: Arhitectura
ISO / IEC 10746 ofer un cadru de coordonare pentru standardizarea procesrii distribuite
deschis (ODP - open distributed processing). Aceasta susine independena de distribuie, de
portabilitate, platform si tehnologie. Aceasta stabilete un cadru arhitectural de ntreprindere
pentru specificarea sistemelor ODP.
ISO / IEC 10746 definete noiunile eseniale necesare pentru a specifica sisteme de
prelucrare distribuite deschise din cinci puncte de vedere prescrise. Acesta ofer un cadru bine
dezvoltat pentru structurarea specificaiei pentru scar larg a sistemelor distribuite.
Cadrul de specificaie furnizat de ISO / IEC 10746 pentru sistem are patru elemente
fundamentale:
O abordare de modelare obiectuala pentru specificaia sistemului;
Specificarea unui sistem n ceea ce privete caietul de sarcini distincte, dar
interdependente de opinie;
Definirea unei infrastructuri de sistem, care ar asigura furnizarea transparent de
distribuie pentru aplicaii de sistem;
 Un cadru pentru evaluarea sistemului la conformitate.

Fig. 4.14. RM-ODP view model, which provides five generic and complementary
viewpoints on the system and its environment.
ISO / IEC 10746-3: 2009 precizeaz caracteristicile necesare care calific procesarea
distribuit ca fiind deschis, adic constrngerile la care trebuie s se conformeze standardele
de ODP. Acesta utilizeaz tehnici descriptive la ISO / IEC 10746-2 pentru a defini cinci
puncte de vedere ISO / IEC 10746. Aceste puncte de vedere sunt capitol componente ale
caietului de sarcini al unui ntreg sistem, creat pentru a reuni piese specifice de informaii
relevante pentru unele pri interesate sau domeniu de interes. ISO / IEC 10746-3: 2009
definete, de asemenea o taxonomie pentru funcii i structuri pentru a realiza transparenta de
distribuie.
Cadrul IEEE 1471
IEEE 1471 este un standard IEEE nlocuit, pentru a descrie arhitectura unui "sistem software
intensiv", de asemenea, cunoscut sub numele de arhitectura software.
A fost mult timp recunoscut faptul ca "arhitectura" are o puternic influen asupra ciclului de
via a unui sistem. Cu toate acestea, pn relativ recent, probleme de hardware au avut
tendina de a domina gndirea arhitecturala, i aspectele software, atunci cnd au fost luate in
consideratie, au fost adesea primele compromise sub presiunea de dezvoltare. IEEE 1471 a
fost creat pentru a oferi o baz pentru gndire despre arhitectura sistemelor software intensive.
Contribuiile IEEE 1471 pot fi rezumate dup cum urmeaz:
Acesta ofer definiii i un meta-model pentru descrierea arhitecturii.
Aceasta afirm c o arhitectura ar trebui s abordeze preocuprile prilor interesate dintr-un
sistem.
Se afirm c descrierile de arhitectura sunt n mod inerent multi-view, nu single-view,care
surprinde n mod adecvat toate preocuprile prilor interesate.
Acesta separ noiunea de view din viewpoint, n cazul n care un punct de vedere identific
setul de preocupri i reprezentri / tehnici de modelare, etc folosit pentru a descrie arhitectura
care abordeaza aceste preocupri i un view este rezultatul aplicrii unui viewpoint la un
anumit sistem.
Acesta stabilete cerinele de coninut pentru descrieri arhitectural i ideea c o descriere
arhitectural corecta are o coresponden 1-la-1 ntre puncte de vedere sale i opiniile sale.
Acesta ofer ndrumri pentru captarea rationala a arhitecturii i identificarea
neconcordanelor / problemelor nerezolvate ntre punctele de vedere n cadrul descrierii unei
arhitecturi
IEEE 1471 prevede anexe informative care se refer la conceptele sale ca fiind concepte de
arhitectura n alte standarde, inclusiv RM-ODP i IEEE 12207.
Conform IEEE 1471 o descriere arhitecturala poate fi utilizata pentru urmtoarele:
Exprimarea sistemului i evoluia sa
Comunicarea ntre prile interesate de sistem
Evaluarea i compararea arhitecturi n mod coerent
Planificarea, gestionarea i executarea activitilor de dezvoltare a sistemului
Exprimarea caracteristicilor persistente i principiile de susinere a unui sistem pentru a
ghida o schimbare acceptabila
Cadrul Federal enterprise architecture framework (FEAF)
O arhitectura de ntreprindere federala (FEA) este arhitectura de intreprindere a unui guvern
federal. Acesta ofer o abordare comun pentru integrarea strategic, afaceri i management
tehnologic, ca parte a structurii organizaionale i mbuntirea performanelor. Cea mai
familiara FEA este arhitectura de ntreprindere de guvernul federal al Statelor Unite, Statele
Unite "Federal Enterprise Architecture" (FEA) i SUA corespunztor "Cadrul Federal
Enterprise Architecture" (FEAF).

Fig. 4.16. Collaborative Planning Methodology (CPM)

(January 29, 2013. Federal Enterprise Architecture Framework. Version 2)
Modelul consolidat de referin al cadrului Arhitectural Enterprise (Federal FEAF) echipeaz
OMB i ageniile federale cu un limbaj comun i un cadru pentru a descrie i analiza
investiiilor. Acesta const dintr-un set de modele de referinta interdependente concepute
pentru a facilita analiza eco-ageniilor i identificarea investiiilor repetitive, lacunele i
oportuniti de colaborare n cadrul i ntre agenii. Colectiv, modelele de referin cuprind un
cadru pentru a descrie elemente importante ale operaiunilor unei agenii federale ntr-o
manier comun i coerent. Prin utilizarea FEAF i vocabularul ei, portofolii IT pot fi mai
bine gestionate i efectul de levier n cadrul Guvernului federal, consolidarea colaborrii i n
cele din urm transformarea guvernului federal.
n ntreprindere FEA, segmentul, i arhitectura soluie ofer diferite perspective de afaceri
prin varierea nivelului de detaliere i la abordarea preocuprilor legate, dar distincte. Aa cum
ntreprinderile s-au organizat ierarhic, astfel nct sunt puncte de vedere diferite oferite de
fiecare tip de arhitectur. Federal Enterprise Architecture Practice Guidance (2006) a definit
trei tipuri de arhitectura:
Arhitectura Enterprise
Arhitectura Segment
Arhitectura Soluiei

Fig. 4.17. Consolidated Reference Model

(January 29, 2013. Federal Enterprise Architecture Framework. Version 2)
FEA este construita folosind un set de modele de referin care dezvolta o taxonomie i
ontologie comun pentru a descrie resurse IT. Modele de referin FEA II inclus urmtoarele:
Performan de referin model (PRM)
Model de referin de afaceri (BRM)
Model de referin de date (DRM)
Model de referin de aplicare (ARM)
Infrastructura de referin model (IRM)
Securitate model de referin (SRM)

Fig. 4.18. Role of Architecture Principles. (Federal Enterprise Architecture. Chief Information
Officer Council. Version 1.0. February 2001) http://www.gao.gov/assets/590/588407.pdf
 The Open Group Architecture Framework(TOGAF)
Open Group Architecture Framework (TOGAF) este un cadru pentru arhitectura de
ntreprindere, care ofer o abordare pentru proiectarea, planificarea, implementarea, i
reglementeaz arhitectura tehnologiei informaiei ntreprinderii. TOGAF a fost o marc
nregistrat de The Open Group n Statele Unite i n alte ri din 2011.
TOGAF este o abordare la nivel nalt pentru a proiecta. Aceasta este de obicei modelat la
patru niveluri: de afaceri, aplicaii, date i tehnologie. Se bazeaz foarte mult pe modularizare,
standardizarea, tehnologii i produse deja existente.

Fig. 4.19. Phase Steps Example.

http://www.opengroup.org/public/member/proceedings/q312/togaf_intro_weisman.pdf
TOGAF reprezint un set de instrumente care pot fi utilizate pentru dezvoltarea unei game
largi de diferite arhitecturi. Este construit pentru a:
descrie o metod pentru definirea unui sistem de informare n ceea ce privete un set de
blocuri de construcie
arat cum blocurile se potrivesc
conine un set de instrumente
ofer un vocabular comun
include o list a standardelor recomandate
include o list de produse conforme, care poate fi folosit pentru a pune n aplicare blocul de
construcie
TOGAF se bazeaz pe patru domenii interdependente de specializare numit domenii
arhitectura:
arhitectura de afaceri care definete strategia de afaceri, guvernarea, organizarea, i
procesele cheie de business ale organizaiei
arhitectura aplicaiei, care prevede un plan pentru sistemele individuale care urmeaz s fie
desfurate, interaciunile dintre sistemele de aplicare, precum i relaiile lor cu procesele de
afaceri de baz ale organizaiei cu cadrele de servicii care urmeaz s fie expuse ca funcii de
afaceri de integrare
arhitectura de date care descrie structura activelor date logice i fizice ale unei organizaii i
a resurselor de gestionare a datelor asociate
arhitectura tehnic sau tehnologie arhitectura, care descrie hardware-ul, software-ul, i
infrastructurii de reea necesare pentru a sprijini implementarea de baz, aplicatii mission-
critical
Cadrul ISO/IEC/IEEE 15288:2015
Systems and software engineering System life cycle processes
ISO / IEC / IEEE 15288: 2015 stabilete un cadru comun de descrieri de proces pentru a
descrie ciclul de via al sistemelor create de om. Acesta definete un set de procese i
terminologia asociata din punct de vedere a ingineriei. Aceste procese pot fi aplicate la orice
nivel n ierarhia structurii unui sistem. Seturi selectate de aceste procese pot fi aplicate de-a
lungul ciclului de via pentru gestionarea i efectuarea etapelor ciclului de via a unui
sistem. Acest lucru este realizat prin implicarea tuturor prilor interesate, cu scopul final de a
obine satisfacia clienilor.

Fig. 4.20. Procesele conform ISO/IEC/IEEE 15288:15

(Transitioning to ISO / IEC / IEEE-15288:2015 Joseph P. Elm Vice Chair, NDIA System
Engineering Division jelm@sei.cmu.edu)
ISO / IEC / IEEE 15288: 2015 prevede, de asemenea, procese care susin definiia, controlul
i mbuntirea proceselor ciclului de via al sistemelor utilizate n cadrul unei organizaii
sau a unui proiect. Organizaiile i proiectele pot folosi aceste procese cnd achiziioneaz i
sisteme de alimentare.
ISO / IEC / IEEE 15288: 2015 se refer la acele sisteme care sunt dezvoltate de om i pot fi
configurate cu unul sau mai multe dintre elementele urmtoare de sistem: hardware, software,
date, oameni, procese (de exemplu, la procedee pentru furnizarea de servicii pentru
utilizatori), Procedurile (de exemplu, instruciunile operatorului), faciliti, materiale i entiti
n mod natural.
Cadrul Mechanics-Dynamics-Aesthetics (MDA)
n designul jocurilor, cadrul Mechanics-Dynamics-Aesthetics (MDA) este un instrument
folosit pentru analiz jocuri. Acesta formalizeaz consumul de jocuri divizindule n trei
componente - Mecanic, Dinamica si Estetica. Aceste trei cuvinte au fost folosite informal de
mai muli ani pentru a descrie diverse aspecte ale jocurilor, dar cadrul MDA prevede definiii
precise pentru aceti termeni i ncearc s explice modul n care acestea se refer unul la altul
i s influeneze experiena juctorului.

Fig. 4.21. Componentele de baz al unui joc.

Mecanica reprezinta componenta de baza al unui joc- normele sale, fiecare aciune de baz pe
care jucatorul o poate efectua n joc, algoritmi si structuri de date ntr-un motor de joc etc.
Dinamica este comportamentul run-time a mecanicii care acioneaz la intrarea juctorului i
"coopereaza" cu alte reguli ale mecanicii.
Estetica rprezintae rspunsurile emoionale evocate n player - bucurie, frustrare, fantezie,
prtie.

Fig.4.22. Cadrul Mechanics-Dynamics-Aesthetics (MDA)

Lucrarea urmrete s precizeze mai bine termeni precum "gameplay" i "distracie", i
extinde vocabularul de studii de joc, ceea ce sugereaz o taxonomie neexhaustiv de opt tipuri
diferite de joc. Cadrul utilizeaz aceste definiii pentru a demonstra stimularea i proprietilor
dinamicii in cele opt subcategoriile de utilizare a unui joc.
Din punctul de vedere al proiectantului - mecanica genereaza o dinamic care genereaz
estetica. Aceast relaie reprezint o provocare pentru un designer de joc ca el este apabil doar
de a influena mecanica i numai prin ea, designerul poate s produc dinamica semnificativa
i estetic pentru juctor. Perspectiva juctorului este invers. El triete jocul prin estetica,
care asigur dinamica de joc, care a rezultat de la mecanica.

II. Metamodele/Concepte:
ISO 14258:1998
Sisteme de automatizare industriale - Concepte i reguli pentru modele de ntreprindere
Obiectivul major al acestui standard internaional este de a defini concepte i reguli pentru
modelele de ntreprindere cu intenia de a ghida i constrnge alte standarde sau implementri
care exist sau vor exista pe aceast tem. Acest lucru este realizat prin definirea elementelor
pentru utilizare atunci cnd producerea unui model de ntreprindere, concepte pentru fazele
ciclului de via i modul n care aceste modele descriu ierarhia, structura, si comportamente.
Prezentul standard internaional furnizeaz orientri i constrngeri pentru modele de
ntreprindere pentru oricine ncearc s modeleze o ntreprindere sau procese.
 Utilizatorii acestui standard internaional sunt n primul rnd institutiile care produc
standarde mai detaliate despre o parte din domeniul integrrii i modelarii. Implementatorii
sistemelor pot gsi, de asemenea valoare in structura dezvoltat n aceste standarde
internaional, astfel c implementarile lor sunt paralele conceptelor prezentate in cadrul
standardelor. Dac design-ul implementrii actuale este facuta conform aceluiai domeniu
tehnologic i nomenclatur, sau sunt n msur de a le mapa usor, informaiile de la o
ntreprindere sau proces pote fi mai uor rspndite n comun cu informaii de la o alt
ntreprindere sau proces.
Motivul pentru acest standard internaional este c sunt necesare alte standarde bine
concepute n domeniul integrrii si modelarii ntreprinderii pentru a oferi un mediu cunoscut
pentru designeri de ntreprindere. Astfel, riscul de a investi n domenii disjuncte de integrare
poate fi redus n mod semnificativ. n cazul n care nu exist astfel de domenii, atunci aceste
standarde ajuta proiectantul pentru a crea transformarea necesara pentru a interaciona cu
mediul cunoscut. Un standard pentru modele de ntreprinderi ar trebui s sporeasc
interoperabilitatea prin stabilirea elementelor care trebuie s fie prezente ntr-un model de
ntreprindere. Aceste elemente vor intra n joc atunci cnd este nevoie de un proces pentru a
comunica cu un alt proces.

Scop: Prezentul standard internaional specific concepte i reguli pentru modelele uor de
neles pentru calculator, oferite de o ntreprindere de producie, pentru a permite o mai bun
cooperare a proceselor de ntreprindere. Acest standard internaional nu definete procesele
standard de companie, ntreprinderi standard, structuri organizatorice standard, sau de date
standard de ntreprindere. n plus, acest standard internaional nu specific procesul de
modelare a ntreprinderii, dar constituie baza prin care standardele de modelarea ntreprinderii
poate fi dezvoltat n cazul n care acestea sunt necesare.

ISO 15704:2000(en)
Sisteme de automatizare industriale - Cerine pentru intreprinderi de tip arhitectural i
metodologii.
Scop: Acest standard internaional definete cerinele pentru arhitecturi de intreprindere i a
metodologiilor, precum i cerinele pe care astfel de arhitecturi i metodologii trebuie s le
ndeplineasc pentru a fi considerate o arhitectur complet de ntreprindere i metodologii.
Domeniul de aplicare al acestor arhitecturi enterprise i a metodologiilor acoper aceste
elemente constitutive considerate necesare pentru efectuarea tuturor tipurilor de proiecte de
creare de ntreprinderi, precum i orice proiecte de schimbare suplimentare cerute de
ntreprindere pe parcursul ntregii viei a ntreprinderii, inclusiv:
Crearea de ntreprinderi,
Eforturi majore de restructurare ntreprindere, i
Modificri incrementale care afecteaz doar o parte a ciclului de via a intreprinderii.
ntreprinderile industriale creaz i modific operaiunile de fabricaie i de afaceri pentru a
mbunti performana pe pieele locale i globale. n faza de exploatare, ele implementeaza
o varietate de resurse, cum ar fi oameni, sisteme de informare, i maini automate. Individual
i colectiv aceste resurse ofer capacitile funcionale necesare pentru a accelera procesele de
afaceri i activitile lor constitutive. Interconectarea resurselor trebuie s fie organizate i
orientate pentru ndeplinirea misiunii. Acest lucru necesit reguli de afaceri adecvate i
structuri organizatorice pentru a permite ntreprinderii s furnizeze produse i servicii pentru
clienii si, n conformitate cu criteriile convenite.
Intreprinderile opereaz n condiii de pia i de mediu incerte pentru ca ingineria
ntreprinderii s poat fi n curs de desfurare. Rezult c personalul companiei au o varietate
de roluri pentru a juca n conceperea i dezvoltarea continu a misiunii, regulile de afaceri,
procesele de afaceri, structurile organizatorice, precum i resursele i serviciile de susinere a
proceselor. Din cauza nivelului ridicat de complexitate implicat n ingineria ntreprindereii,
invariabil este necesar pentru a implementa mijloacele de evaluare, structurare, coordonarea i
sprijinirea acestor activiti de inginerie.
Arhitecturi de tip intreprindere susinute de metodologii de referin ofera mijloace general
aplicabile de organizarea i coordonarea de proiecte de inginerie. Prin adoptarea, i adaptarea
necesar, o metodologie de referin i arhitectur, personalul de ntreprindere poate coopera
n progresul proiectelor ntreprinderii de inginerie, mbuntirea ntreprinderii i utilizarea
resurselor. Prin adoptarea unei metodologii de referin arhitectural, i a unui set de
instrumente de sprijin, devine practic pentru personal de a reutiliza modele de ntreprinderi
explicite i modele pentru a realiza o inginerie de ntreprindere pe o baz continu si pentru a
realiza mbuntiri suplimentare n funcie de ntreprindere. Prin urmare, o necesitate vital
este o baz de inginerie a ntreprinderii i referine de integrare pentru furnizarea
metodologiilor i sprijinirea tehnologii care pot trata realist problema integrrii intreprinderi.

Figura 4.4. Arhitectura modelrii.

Activitatea IFAC / IFIP (Federaia Internaional de Automatica / Federaia Internaional a
Prelucrrii Informaii) Task Force pe arhitecturi de integrare a Intreprinderii i de multe alte
organizaii similare din ntreaga lume si-au concentrat recent activitatea lor asupra acestei
probleme n sperana de realizare generica a soluiei necesare. Munca lor a aratat ca o astfel de
baz de referin poate fi conceput, i trebuie s se bazeze pe o ntreprindere de tip
arhitectural, care:
poate modela ntreaga istorie de via a unui proiect de ntreprindere-integrare de la
conceptul iniial, prin definiie, design funcional sau specificaii, al proiectrii
detaliate, implementarea fizic sau construcie, operare la defectare;
cuprinde oameni, procese, i echipamentele implicate n realizarea, gestionarea,
controlul i misiunea ntreprinderii.
Este important s reinei c intreprinderea de tip arhitectural are tangente cu
aranjamentul structural (organizare) din dezvoltarea i implementarea unui proiect sau
program, cum ar fi o integrare a intreprinderii sau alt program de dezvoltare a
intreprinderii. n contrast cu aceste intreprinderi de tip arhitecural, sistemul arhitecural
are de afacere cu aranjamentul structural (proiectare) a unui sistem; de exemplu, partea
de control a sistemului pe calculator a unui sistem de integrare a intreprinderii.
Principiile-cheie ale integrrii intreprinderi:
Aplicabilitatea la orice ntreprindere,
Identificarea intreprinderii i definirea misiunii
Separarea funciilor cu misiune de indeplinire de funciile cu misiune de control
Identificarea structurilor de proces
Identificarea coninutului de proces
Recunoaterea fazelor ciclului de via ale companiei
Abordare evolutiv a integrrii ntreprinderii
Modularitate
Scopul i beneficiile implementarii intreprinderii de tip arhitectural i metodologii:
O arhitectura de tip enterprise cu metodologia asociat i tehnologii de ntreprindere
inginereasca care ndeplinesc cerinele acestui standard, va nominaliza o echipa de antrepriz-
integrare-planificare pentru a determina i de a dezvolta un curs de aciune care este complet,
exact, orientat corect la o viitoare evoluie a afacerii, cu minimum de resurse, personal, i
capital. Adic, s:
Descrie sarcinile necesare;
Dfineasc cantitatea necesar de informaii;
Specifice relatiile dintre oameni, procese i echipamente n integrarea considerata;
Adreseze preocuparile legate de gestiune;
Adreseze factori economici, culturali, i tehnologici relevanti;
Detalieze gradul necesar de suport al calculatorului;
Suporte modelarea bazata pe proces, care poate descrie intreaga istorie a vietii intreprinderii

Beneficii ale acestui standard:

Arhitecturile de tip interprindere si cerintele metodologice n acest standard vor permite o
ntreprindere specifica de tip arhitectural cu metodologia care urmeaz s fie verificata pentru
asigurarea integralitii n ceea ce privete scopul su actual i viitor. Acest standard va ghida
dezvoltarea lor. Acest beneficiu va fi cel mai relevant pentru orice grup responsabil de
mbuntirea infrastructurii de ntreprindere sau procesele sale. Un astfel de grup va gsi c
este necesar fie sa creeze sau sa selecteze o arhitectura de tip enterprise, cu o terminologie
care se refer n mod specific la companie, industrie, cultur implicat. Acest standard va
ghida acea selecie sau elaborare.
ISO 19440:2007
Integrarea Enterprise - Constructii de modele a ntreprinderii
Introducere: Acest standard internaional definete conceptele generice care sunt necesare
pentru a permite crearea de modele de ntreprinderi pentru ntreprinderi industriale i de a
oferi sprijin pentru utilizarea cadrelor de ctre ntreprinderi industriale. Prezentul standard
internaional se bazeaz pe ISO 19439 prin definirea i detalierea unui set de construcii de
modelare a limbajului orientate spre utilizator, care ofer semantici comune i permit
unificarea modelor dezvoltate de diferitele pri interesate n diferite faze de dezvoltare a
modelului.
Astfel de modele sunt destinate suportului pe baz de model operational de luare a deciziilor
i pot fi folosite pentru modelul de monitorizare i control de funcionare.
Construciile de modelare a limbajului definite n prezentul standard internaional pot fi
specializate sau organizate n structuri pentru scopuri specifice, de exemplu, pentru un sector
industrial sau pentru un anumit tip de proiect de ntreprindere, cum ar fi de ntreinere. La
rndul su, astfel de structuri i construcii pentru modelarea generica a limbajului pot fi
folosite pentru dezvoltarea anumitor modele pentru o anumit ntreprindere.
Cerinele generale care determin caracteristicile de baz necesare pentru modelarea la
calculator sunt:
asigurarea unui model explicit de Business Processes, cu propria lor dinamic, funcii,
informaii, resurse, organizare i responsabiliti,
detalierea suficienta i calificarea componentelor ntreprinderii, pentru a permite crearea
unui model pentru o ntreprindere specific,
suport pentru managementul schimbrii, i
reprezentarea orientat spre utilizatorul final, pentru a permite utilizarea operaional.

Scop: Acest standard internaional specific caracteristicile construciilor de baz necesare

pentru modelarea suportat de calculator a ntreprinderilor conform ISO 19439. Acest
standard internaional se concentreaz asupra, dar nu se limiteaz la, integrarea calculatorului
asupra aspectelor de informare din procesul de fabricaie, inclusiv tehnologia de gestionare i
control, precum i sarcinile umane necesare. Aceasta nu specific modul n care aceste
construcii de baz pentru operaiunile bazate pe modele urmeaz a fi implementate i, n
special, nu include limba de control necesare pentru a specifica i a executa comportamentul
(intern) de activitate, nici cartografierea ntre operaiunile i capacitile funcionale.

ISO/IEC 15414:2015
Tehnologia informaiei - Procesarea deschisa distribuita - Model de referin - limbajul
Enterprise
Introducere:
Creterea rapid a prelucrrii distribuite a condus la adoptarea modelului de referin al
procesarii deschise distribuite (RM-ODP, Reference Model of Open Distributed Processing).
Acest model de referin ofer un cadru de coordonare pentru standardizarea prelucrrii
deschise distribuit (ODP). Aceasta creeaz o arhitectur n care suportul de distribuie, de
portabilitatea pot fi integrate. Aceast arhitectur ofer un cadru pentru specificarea
sistemelor ODP. Modelul de referin a procesrii deschise distribuite se bazeaz pe concepte
precise derivate din evoluiile actuale distribuite de prelucrare i, pe ct posibil, pe utilizarea
unor tehnici formale de descriere pentru specificarea arhitecturii. Prezenta recomandare
redefineste i extinde definiia modul n care sistemele ODP sunt specificate din punct de
vedere al ntreprinderii, i este destinat pentru dezvoltarea sau utilizarea specificaiilor ce vin
de la companii de sisteme de ODP.
Scop: Prezenta recomandare prevede:
un limbaj (limbaju Enterprise), care cuprinde concepte, structuri, i reguli pentru dezvoltare,
reprezentnd i raionamentul cu privire la o specificaie a unui sistem ODP din punct de
vedere al ntreprinderii
norme care stabilesc corespondene ntre limbajul de ntreprindere i celelalte limbaje de
opinie pentru a asigura coerena de ansamblu a unui caiet de sarcini.
Limbajul este specificat la un nivel de detaliu suficient pentru a permite determinarea
conformitii cu privire la orice limbaj de modelare pentru a prezenta o recomandare. Aceast
recomandare este destinata utilizrii n prepararea caietul de sarcini intr-o companie de
sisteme de ODP, i n dezvoltarea de notatii si instrumente pentru a sprijini astfel de
specificaii. Dup cum se specific la punctul 5 din Rec. X.903 ITU-T | ISO / IEC 10746-3, o
specificaie din punct de vedere al ntreprinderii definete politicile unui sistem ODP, scopul
si domeniul de aplicare.
Introducere: Acest Prestandard European (ENV) a fost aprobat de ctre CEN (Comitetul
European pentru Standardizare - the National Standardization Bodies of 33 European
countries) la data de 1995-12-14 ca standard prospectiv pentru aplicarea provizorie. Perioada
de valabilitate a prezentului ENV se limita iniial la trei ani. Dup doi ani membrilor CEN li
se va cere s i prezinte observaiile, n special cu privire la ntrebarea dac ENV poate fi
transformat ntr-un standard european (EN). Membrii CEN trebuie sa anune existena acestei
ENV n acelai mod ca i pentru un EN i pentru a face acest ENV disponibil imediat la nivel
naional ntr-o form adecvat. Este permis meninerea standardelor naionale contradictorii
n vigoare (n paralel cu ENV) pn la decizia final cu privire la posibila conversie am ENV-
ului ntr-o EN. Membrii CEN sunt instituiile naionale de standardizare din Austria, Belgia,
Danemarca, Finlanda, Frana, Germania, Grecia, Islanda, Irlanda, Italia, Luxemburg, rile de
Jos, Norvegia, Portugalia, Spania, Suedia, Elveia i Marea Britanie.
Scop: Constituie un Prestandard european privind Modelarea Constructiilor de Intreprindere,
sprijinind Views-urile definite n ENV 40003, a sistemelor de modelare CIM in cadru
arhitecturii. Acesta conine definiii i descrieri comune ale constructiilor necesare pentru
modelarea pe calculator a ntreprinderilor, concentrndu-se pe manufactura partiala discreta.
Modelele generate folosind constructii n conformitate cu acest cadru vor fi n cele din urm
procesabile pe calculator si vor permite operaiunile zilnice ale unei ntreprinderi pentru a fi
rulate i controlate de ctre astfel de modele.
Metamodelul Business Process Definition (BPDM)
Introducere: Metamodelul Business Process Definition (BPDM) este o definiie standard a
conceptelor utilizate pentru a exprima modele proceselor de afaceri (un metamodel), adoptate
de OMG (Object Management Group). Metamodele definesc concepte, relaii, i semantici
pentru schimbul de modele utilizate ntre diferite instrumente de modelare. Formatul de
schimb este definit de XSD (XML Schema) i XMI (XML pentru Metadata Interchange), o
specificaie pentru transformarea metamodelelor OMG la XML. BPDM ofer concepte
abstracte ca baz pentru interpretri coerente a conceptelor de specialitate folosite de
modelatorii proceselor de afaceri. De exemplu, ordonarea a mai multe elemente grafice ntr-o
(Business Process Modeling Notation) Diagrama BPMN este reprezentata prin sgei ntre
aceste elemente, dar elementele specifice pot avea o varietate de caracteristici.

Figure 4.5. Generic Meta-Model of a Business Process

http://publik.tuwien.ac.at/files/pub-inf_3845.pdf
Scop: Caietul de sarcini se adreseaz obiectivelor BPDM din RFP OMG pe care se bazeaz:
BPDM "va defini un set de elemente abstracte pentru specificarea proceselor de afaceri
executabile n cadrul unei ntreprinderi, i pot colabora ntre procesele de afaceri; n caz
contrar, acestea devin independente de executare n diferite uniti de afaceri sau
ntreprinderi."
Metamodel comun care s unifice diverse procese de afaceri care exist n industrie i care
s conin semantica compatibil cu notaiile pentru modelarea proceselor de afaceri.
Un metamodel care completeaz metamodele UML existente, astfel nct procesele de
afaceri a caietului de sarcini pot fi parte a sistemului de specificaii complete pentru a asigura
coerena i exhaustivitatea.
Capacitatea de a integra modele de proces pentru procese de management a fluxului de
lucru, procesele de business automatizate, si colaborari intre uniti de afaceri.
Sprijin pentru specificarea serviciilor web coregrafie, descriind colaborarea ntre entitile
participante i capacitatea de a reconcilia cu coregrafia de sprijin a proceselor de afaceri
interne.
Capacitatea de a face schimb intre specificaiile proceselor de afaceri si instrumente de
modelare, precum i ntre instrumentele i mediile de execuie, folosind XMI.
Cererea de ofert urmrete s "mbunteasc comunicarea dintre modelatori, inclusiv ntre
afaceri i software modelatori, ofer selecie flexibil de instrumente i medii de execuie, i
promoveaz dezvoltarea unor instrumente mai specializate pentru analiza i proiectare a
proceselor."
Pentru schimbul de modele a proceselor de afaceri, BPDM este o alternativ la formatul
existent pentru procesul de transfer XPDL (Process Definition Language XML).
Profilul UML pentru Enterprise Distributed Object Computing (EDOC)
Introducere: Necesitatea de a colabora i de a integra, a devenit de o importan strategic
pentru ntreprindere modern. Integrarea lanului de aprovizionare, de management al
clienilor, B2B i integrarea aplicaiilor ntreprinderii sunt toate manifestri ale acestei nevoi
de a mbunti i automatiza colaborare folosind sisteme de informaii de ntreprindere.
Caietul de sarcini eDoc din OMG ofer o modalitate standard de a modela colaborari de
afaceri cu UML i "drill down" la sistemele de executabile care folosesc middleware, cum ar
fi servicii web, XML, J2EE web, MQ-Series, NET i, desigur, Corba.

Fig. 4.6. Puncte de vedere la modelare.

Scop: EDoc face parte din viziunea OMG a unui "Model Driven Architecture", sau MDA
scurt. n viziunea MDA ciclul de via al aplicaiei este condus de la nivel nalt, modele UML
axate pe Bussiness care pot fi "mapate" pentru diverse tehnologii de implementare i execuie.
Cei care au folosit UML tiu c generarea de modele UML a fost dificil i, de obicei produce
cod care este "generic" pentru utilizarea practic. Din acest motiv, cele mai multe modele
UML sunt doar ghiduri la un proces subiectiv i manual de implementare a aplicaiei. MDA
abordeaz aceste probleme n dou domenii cheie; Modelele UML destinate pentru MDA
sunt produse n conformitate cu unele "Profiluri", un mod foarte specific de a utiliza UML
pentru un anumit scop. Ar putea exista profiluri pentru timp real, pentru modelarea datelor sau
pentru ntreprindere de calcul. EDoc este profilul standard de UML pentru calcul distribuit de
ntreprindere, unde departamentele si companiile trebuie s se integreze i s colaboreze. Ca
atare, eDoc devine cadrul de modelare utilizat la nivel de ntreprindere. Profilurile fac UML
suficient de bine structurat i precis de a fi utilizat pentru MDA i de a conduce etapele
ulterioare din ciclul de via pentru dezvoltare. Aceste modele precise la nivel nalt sunt
cunoscute ca "platforma Modele independente" (sau PIM) n limbajul de MDA.
III. Standarde Proiectare:
Limbaje
ISO 10303-11:2004

Sisteme industriale de automatizare i integrare - reprezentare a datelor de produs i de

schimb - Partea 11: Metode de Descriere: Manualul de referin a limbajului EXPRESS
Introducere: ISO 10303 - 11 a fost elaborat de Comitetul Tehnic ISO / TC 184, sisteme de
automatizare industriale si de integrare, Subcomisia SC 4, date industriale.
Aceast a doua ediie a ISO 10303-11 constituie o revizuire minor a primei ediii (ISO
10303-11: 1994), care este reinut cu titlu provizoriu n scopul de a sprijini utilizarea n
continuare i ntreinerea implementrii bazate pe prima ediie i pentru a satisface referinele
normative de alte pri ale ISO 10303. Aceast a doua ediie include, de asemenea, Rectificare
tehnic ISO 10303-11: 1994 / Corinteni 1: 1999 (E).

ISO 10303 este organizat ca o serie de piese de schimb, fiecare publicate separat. Structura
ISO 10303 este descris n ISO 10303-1. Fiecare parte a ISO 10303 este un membru al uneia
dintre urmtoarele serii: Metode de descriere,

Metode de implementare, de testare

Metodologie de conformitate si cadru,
Rresurse generice integrate,
Resurse integrate de aplicaii,
Protocoale de aplicare,
Pachete abstracte de testare,
Construcii interpretate, i
Aplicatii si module de aplicaii.

Aceast parte este componenta seriei de metode descriptive.

Scop: Aceast parte a ISO 10303 specific un limbaj prin care aspectele legate de date pot fi
definite. Limbajul este numit EXPRESS. Aceast parte a ISO 10303 specific, de asemenea o
reprezentare grafic pentru un subset de construcii n limbajul EXPRESS. Aceast
reprezentare grafic se numete EXPRESS-G. EXPRESS este un limbaj de specificare a
datelor astfel cum sunt definite n ISO 10303-1. Se compune din elemente de limbaj, care
permit o definiie lipsit de ambiguitate a datelor i specificarea constrngerilor asupra datelor
definite. Urmtoarele sunt n domeniul de aplicare al acestei pri a ISO 10303:
tipuri de date;
constrngeri asupra instane ale tipurilor de date.
Urmtoarele sunt n afara domeniului de aplicare al acestei pri a ISO 10303:
definirea formatelor de baze de date;
Definiia de formate de fiiere;
definirea formatelor de transfer;
control al procesului;
procesarea informatiei;
tratarea excepiilor.
Express nu este un limbaj de programare.

ISO/IEC 15909-2:2011(en)
Systems and software engineering High-level Petri nets Part 2: Transfer format
Introducere: ISO / IEC 15909 se refer la definirea unui limbaj de modelare i format de
transfer, cunoscut sub numele Petri Net-uri de nivel nalt. ISO / IEC 15909-1 prevede definiia
matematic a Petri Net-urilor de nivel inalt, numit modelul semantic, forma grafic a tehnicii,
cunoscut sub numele de grafic Petri net de nivel inalt (hlpngs), i maparea ei cu modelul
semantic. Acesta introduce, de asemenea i unele convenii de notaie comune pentru hlpngs.
Aceast parte a ISO / IEC 15909 definete un format de transfer pentru Petri Net-uri de nivel
nalt pentru a sprijini schimbul de Petri Net-uri la nivel inalt ntre diferite instrumente. Acest
format este numit Petri Net Markup Language (pnml). Exist mai multe versiuni diferite ale
reelelor Petri. Aditional, retelelor Petri net de nivel inalt, aceast parte a ISO / IEC 15909
definete conceptele de baz ale reelelor Petri, mpreun cu o sintax XML, care poate fi
folosit pentru schimbul de orice fel de Petri net.
Pe baza acestei pnml Core model, aceast parte a ISO / IEC 15909 definete, de
asemenea, sintaxa de transfer pentru cele trei versiuni ale reelelor Petri, care sunt definite n
ISO / IEC 15909-1: Locul / Transition Nets, simetric Nets1, i Petri net-uri de ordin inalt, n
cazul n care pot fi considerate Place / Transition net-uri, iar Symmetric Nets s fie
considerate versiuni limitate ale Petri nets de nivel inalt. Pentru Place/ Tranzition Nets,
aceast parte a ISO / IEC 15909 introduce dou formate diferite de transfer: unul este un
format reglat special pentru a Place/ Transition nets, cellalt este un format care reprezint
Place / Tranzition Nets ca o versiune restrns a Petri net-urilor de nivel inalt, astfel cum sunt
definite n ISO / IEC 15909-1.
Fig. 4.7. Petri net-uri de nivel inalt cum sunt definite n ISO / IEC 15909-1.

Scop: Aceast parte a ISO / IEC 15909 definete un format de transfer bazat pe XML pentru
reele Petri, care sunt definite conceptual i matematic n ISO / IEC 15909-1. Acest format de
transfer permite schimbul de reele Petri ntre diferite instrumente Petri net i ntre diferite
pri. Mai mult dect att, aceast parte a ISO / IEC 15909 definete unele concepte i sintax
bazata pe XML pentru definirea aspectul grafic detaliat al reelelor Petri.
Este punctul central al acestei pri a ISO / IEC 15909 privind formatul de transfer pentru
Place / Transition nets, la nivel nalt Petri Nets i Symmetric Nets.Prezentarea, cu toate
acestea, este structurata n aa fel nct este deschisa pentru extensii viitoare, astfel nct alte
versiuni ale reelelor Petri pot fi adugate mai trziu. Definiia exact a acestui mecanism
extensie, numit definitie de tip Petri net, nu este definit n aceast parte a ISO / IEC 15909;
Acesta va fi definit n ISO / IEC 15909-3.
Formatul de transfer va fi utilizat pentru a transfera specificaiile sistemelor dezvoltate n Petri
net-uri de rang inalt ntre instrumentele pentru a facilita dezvoltarea sistemelor n echipe.
Aceast parte a ISO / IEC 15909 este scrisa ca o referin pentru dezvoltatorii de instrumente
Petri net. n plus, va fi util pentru cercetatorii care definesc noile versiuni i variante de reele
Petri.
Unified Enterprise Modelling Language (UEML)
Introducere: Unified Enterprise Modelling Language (UML) este o ncercare n curs de
desfurare pentru a dezvolta teorii, tehnologii i instrumente pentru utilizarea integrat a
ntreprinderii i SI modele exprimate in limbi diferite. Prin aceasta ne referim la pstrarea
modelelor existente aa cum sunt i stabilim relaii ntre ele ntr-un mod explicit i uor de
utilizat, de sprijin, de exemplu, verificarea coerenei, modificare reflecie automat, transfer
de la model la model i la alte servicii dincolo de graniele limbajului de modelare.

Fig. 4.8. The main classes in the UEML representation meta-meta model.

Scop: UEML se dorete a fi un limbaj intermediar - sau un hub - prin care diferite limbi pot fi
conectate, facilitnd astfel o reea de limbi i a modelelor exprimate n aceste limbi. UEML
cuprinde n prezent:
o abordare structurat pentru a descrie ntreprindere i este modelarea limbi,
o ontologie comun pentru a descrie semantica construcii de modelare i, prin urmare,
interrelaioneaz construi descrieri la nivel semantic,
o abordare de analiz de coresponden pentru a determina corespondene ntre constructe,
un cadru de calitate pentru a defini i de a evalua calitatea de ntreprindere limbajelor de
modelare pentru a ajuta selectarea limbii,
un model de meta-meta a organiza i UEML
un set de instrumente pentru a ajuta utilizarea acestuia.

XML Metadata Interchange (XMI)

Introducere: XML Metadata Interchange (XMI) este un standard Object Management Group
(OMG) pentru schimbul de informaii metadate prin Extensible Markup Language (XML).
Cea mai comun utilizare a XMI este ca un format de schimb pentru modelele UML, dei
poate fi de asemenea utilizat pentru serializare a modelelor de alte limbi (metamodelului).
XMI integreaza patru standarde ale industriei:
XML - Extensible Markup Language, un standard W3C.
UML - Unified Modeling Language, un standard de modelare OMG.
MF - Meta Facilitatea obiect, un limbaj pentru specificarea OMG metamodel
MF - Mapping la XMI Integrarea acestor patru standarde n XMI permite dezvoltatorilor de
instrumente de sisteme distribuite de a mprti modele de obiecte i alte metadate.
 Fig.4.9. Utilizare XMI
Scop: Acest standard internaional sprijin Facilitatea Object Meta (MF) Core definita n ISO
/ IEC 19508. MF este tehnologia baz pentru a descrie metamodelele. Acesta acoper o gam
larg de domenii, i se bazeaz pe un subset constrns de UML. XML Metadata Interchange
(XMI) este un format XML de schimb utilizat pe scar larg. Definete urmtoarele aspecte
implicate n descrierea obiectelor n XML:
Reprezentarea obiectelor n ceea ce privete elementele XML i atribute.
Mecanismele standard de a lega obiecte n acelai fiier sau peste fiiere.
Validarea documentelor XMI folosind schemele XML.
identitatea obiect, care permite obiectelor s fie referite la alte obiecte n termeni de ID-uri i
UUID. XMI descrie soluii la problemele de mai sus, cu precizarea regulilor de producie
EBNF pentru a crea documente XML i schemele care obiectele de aciuni n mod constant.

Business Process Model and Notation

Introducere: Business Process Model and Notation (BPMN)

(file:///C:/Users/User/Downloads/formal-11-01-03.pdf ) este o reprezentare grafic pentru
specificarea proceselor de afaceri ntr-un model de proces de afaceri. Business Process
Management Initiative (BPMI) a dezvoltat BPMN, care a fost meninut de Object
Management Group, deoarece cele dou organizaii au fuzionat n 2005. Versiunea 2.0 a
BPMN a fost lansat n ianuarie 2011, moment n care numele a fost adaptat la Business
Process Model and Notation ca semantica de execuie alturi de elementele de notare i de
diagrame.
 Fig. 4.10. Business Process Model and Notation (BPMN)
Scop: Un BPMN standard v-a oferi ntreprinderilor capacitatea de a nelege procedurile lor
de afaceri interne intr-o notaie grafic i va oferi organizaiilor capacitatea de a comunica
aceste proceduri ntr-o manier standarda. n plus, notaia grafic va facilita nelegerea
colaborrilor de performan i tranzaciile de afaceri ntre organizaii. Acest lucru va asigura
faptul c ntreprinderile i participanii la afacerea lor vor nelege i vor permite organizaiilor
s se adapteze la noile circumstane de afaceri interne i B2B rapid.
ebXML Business Process Specification Schema
Introducere: EBusiness eXtensible Markup Language (ebXML) Procesul de afaceri
Specificaii Schema (BPSS) specificaie tehnic definete un limbaj standard prin care
sistemele de afaceri pot fi configurate pentru a sprijini executarea colaborrilor de afaceri
formate din tranzacii de afaceri (http://docs.oasis-open.org/ebxml-bp/2.0.4/OS/spec/ebxmlbp-
v2.0.4-Spec-os-en-html/ebxmlbp-v2.0.4-Spec-os-en.htm) . Ea se bazeaz pe ONU / CEFACT,
n special metamodelul din spatele ONU / CEFACT Modelare Metodologie (UMM) definite
n "/ CEFACT Modelare Metodologia ONU - Meta Modelul - Revizuirea 10. n viitor, atunci
cnd un ghid de referin devin disponibil versiuni ulterioare vor fi evaluate i alte cerine de
metadate - analizate. Acestea ar putea include cele dezvoltate n temeiul Centrul Naiunilor
Unite pentru Comer i Facilitation and Electronic Business (ONU / CEFACT), cum ar fi de
la acordurile de afaceri unitare i contracte (Ubac).
Specificaia tehnic ebBP sprijin caietul de sarcini a tranzaciilor comerciale i
coregrafia tranzaciilor comerciale n afaceri de colaborare. Toate tranzaciile de afaceri sunt
puse n aplicare folosind una dintre multe modele standard disponibile. Aceste modele sunt
definite n caietul de sarcini UMM. Un model nu este executabil; mai degrab se specific
tipul de schimb de mesaje (cerere, rspuns i semnale) care se aplic pentru o anumita
definiie a tranzaciei de afaceri. Este o modalitate de a defini clase de a defini o tranzacie de
afaceri. Aceste modele ar putea fi legate de diferite clase de tranzacii de comer electronic.
Versiunea actual a specificaiei tehnice ebBP adreseaz colaborari de afaceri ntre
orice numr de pri. Acesta permite, de asemenea, participanilor care sunt capabili de a
utiliza servicii Web sau tehnologii combinate (cum ar fi ebXML i servicii web), pentru a
participa la o colaborare de afaceri. Se anticipeaz c o versiune ulterioar a acestei
specificaii tehnice va aborda caracteristici suplimentare, cum ar fi semantica schimburilor
economice i a contractelor, i de coninut pe baza context, pe baza cerinelor de metadate
furnizate de organizaiile relevante.
 Fig. 4.11. EBusiness eXtensible Markup Language (ebXML) Procesul de afaceri.
Scop:
Definitiile ebBP descriu procesele de afaceri interoperabile care permit partenerilor de afaceri
de a colabora i de a atinge un obiectiv comercial determinat. Aceste definiii trebuie s fie
executate de componente software care colaboreaz n numele partenerilor de afaceri. Scopul
specificaiei tehnice ebBP este de a oferi o punte ntre modelarea proceselor eBusiness si
executie de componente software eBusiness. Specificaia tehnic ebBP prevede pentru setul
nominal de elemente necesare de a specifica o colaborare de afaceri ntre parteneri de afaceri,
i pentru a oferi parametrii de configurare pentru sisteme de rulare a partenerilor n scopul de
a executa o colaborare de afaceri ntre un set de componente software eBusiness si caietul de
sarcini.
Metode:
Data Flow Diagram
Introducere: O diagram de flux de date (DFD) este o reprezentare grafic a "fluxului" de
date prin intermediul unui sistem informatic, de modelare a aspectelor sale de proces. O DFD
este adesea utilizata ca o etap preliminar pentru a crea o imagine de ansamblu a sistemului,
care pot fi elaborate ulterior. [2] DFDS poate de asemenea fi utilizata pentru vizualizarea de
prelucrare a datelor (proiectare structurat). O DFD arat ce fel de informaii vor fi introduse
la i spre ieire din sistem, n cazul n care datele vor veni de la i vor pleca spre, i n cazul n
care datele vor fi stocate. Nu arat informaii despre calendarul de proces sau informaii
despre procesele ce se vor opera n ordine sau n paralel (care este prezentat pe o schem
logic).
Scop: Diagrame de flux de date pot fi utilizate pentru a oferi utilizatorului final o idee fizic
n cazul n care datele de intrare pe care le are n cele din urm au un efect asupra structurii
ntregului sistem de la scopul de a trimite si a raporta. Cum un sistem este dezvoltat poate fi
determinat printr-un model de diagrama de date. n cursul dezvoltrii unui set de diagramele
cu flux de date nivelat, analistul / designerul este obligat s se adreseze in modul n care
sistemul poate fi descompus n subsisteme componente, i de a identifica datele tranzaciei n
modelul de date. Diagrame de flux de date poate fi utilizata att n analiza i in faza de
proiectare a ciclului de via a sistemului dezvoltat.

IDEF
Introducere: IDEF se refer la o familie de limbi de modelare n domeniul sistemelor i
inginerie software. Acestea acoper o gam larg de utilizri, de la modelarea funcional la
date, simulare, analiz orientata pe obiect/ proiectare i dobndirea de cunotine.
Componentele din familia IDEF mai-larg recunoscute i folosite sunt IDEF0, o structure de
limbaj de modelare funcional pe SADT, i IDEF1X, care abordeaz modelele de informaii
i probleme de proiectare a bazei de date. Familia IDEF de metode:
IDEF0: pentru ndeplinirea funciei de modelare (scop: descriere)
IDEF1: pentru Information Modeling. (scop: descriere)
IDEF1x: pentru datele de modelare. (scop: de proiectare)
IDEF3: pentru Process Modeling. (scop: descriere)
IDEF 4: pentru Object-Oriented Design. (scop: de proiectare)
IDEF 5: pentru Ontology Description Capture. (scop: descriere)
Scop: IDEF este folosit pentru activiti necesare pentru a sprijini analiza de sistem,
proiectarea, mbuntirea sau integrarea de modelare. Iniial, IDEF a fost dezvoltat pentru a
mbunti comunicarea ntre oameni care ncearc s neleag sistemul. Acum, IDEF este
utilizat pentru documentare, nelegere, proiectare, analiza, planificare, i Integrare.
Unified Modeling Language
Introducere: Unified Modeling Language (UML) este un limbaj pentru scop general de
dezvoltare, limbaj de modelare n domeniul ingineriei software, care este destinat s furnizeze
o modalitate standard de a vizualiza proiectarea unui sistem. UML a fost proiectata iniial de
dorina de a standardiza sistemul de notaie disparate i abordrile de proiectare a software-
ului. Unified Modeling Language (UML) ofer o modalitate de a vizualiza planurile de
arhitectur a unui sistem ntr-o diagram, inclusiv elemente cum ar fi:
Orice activitate (locuri de munc)
Componentele individuale ale sistemului i modul n care acestea pot interaciona cu alte
componente software.
Cum sistemul va rula
Cum entitile vor interaciona cu celelalte (componente i interfee)
interfa de utilizator extern
 Dei iniial a fost destinata exclusiv pentru documentaia de proiectare orientata pe
obiect, Unified Modeling Language (UML) a fost extins pentru a acoperi un set mai mare de
documentaie de proiect i a fost gsit util n mai multe contexte.
Scop: Procesul de colectare i analiz a cerinelor unei aplicaii, i includerea acestora ntr-un
program de proiectare, este una complex i industria sprijin n prezent mai multe
metodologii care definesc proceduri formale care s precizeze modul de a merge spre asta. O
caracteristic a UML - n fapt, cea care permite susinerea industriei larg rspndit de care
limbajul se bucur - este faptul c aceasta este o metodologie independente. Indiferent de
metodologia pe care o utilizai pentru a efectua analiza i design-ul, avei posibilitatea s
utilizai UML pentru a exprima rezultatele. i, folosind XMI (XML Metadata Interchange, un
alt standard OMG), putei transfera modelul UML dintr-o unealt ntr-un fiier, sau n alt
instrument pentru rafinament sau urmtorul pas n procesul de dezvoltare aleas. Acestea sunt
beneficiile standardizrii!
IV. Business Process Choreography:

Unified Enterprise Modelling Language (UEML)

Unified Enterprise Modelling Language (UML) este o ncercare n curs de desfurare pentru
a dezvolta teorii, tehnologii i instrumente pentru utilizarea integrat a ntreprinderii i IS
modele exprimind limbi diferite. Prin aceasta ne referim la pstrarea modelelor existente aa
cum sunt i stabilim relaii ntre ele ntr-un mod explicit i uor de utilizat, de sprijin, de
exemplu, verificarea coerenei, modificarea refleciei automate, traducerea de la model la model
i alte servicii dincolo de graniele limbajului de modelare. UML poate fi privita ca o limb
intermediara - sau un hub - prin care diferite limbi pot fi conectate, facilitnd astfel o reea de
limbi i a modelelor exprimate n aceste limbi.
Acestea i alte posibile evoluii viitoare au fost organizate ntr-o foaie de parcurs UEML
cuprinznd mai multe direcii de cercetare, fiecare detaliat de aciuni specifice (Opdahl & Berio
2006). ntr-o anumit msur, n continuare dezvoltarea UEML n fiecare direcie poate
progresa n paralel, fr o coordonare strict. Cele zece direcii originale au fost:
limea Limba - include mai multe limbi;
adancime ontologic - Cutare comun ontologia;
claritate ontologic - elaborarea limba comun ontologie;
prezentarea - extinde suportul pentru probleme de prezentare;
formalitate matematic - s defineasc n mod oficial semantica UEML;
suport Tool - dezvolta instrument prototip cu GUI i sprijin validare;
model de management - s ofere sprijin pentru management modelul n plus fa de gestionare
a limbajului;
validarea - limba structurale i de comportament i de validare a modelului;
diseminarea - face UEML cunoscut n industrie i mediul academic i ca standard;
comunitatea - stabileasc i s menin o comunitate angajat i coezive pentru gestionarea i
evoluie UEML i abordarea sa.
 Business Process Modeling Language (BPML)
BPML fost un limbaj propus, dar acum BPMI a scazut din sprijinul pentru BPML n favoarea
BPEL4WS (Business Process Execution Language for Web Services). Ca si in 2008, BPML a
fost, de asemenea raportat ca fiind depasit in favoarea BPDM (Business Process Definition
Metamodel).
BPML, un superset al BPEL, a fost pus n aplicare de ctre furnizorii de stadiu incipient, cum
ar fi Intalio Inc., dar operatorilor tradiionali cum ar fi IBM i Microsoft nu au implementat
BPMLin metodele lor de lucru existente si in mediile de integrare (BizTalk, WebSphere etc.).
Prin urmare, au optat pentru o limb simpl, BPEL. Astzi, implementri open source de BPML
nc depesc capacitatea a acestor produse comerciale. Acest lucru a condus unii s spun c
BPML versus BPEL a fost un caz de SHV fa de Betamax. Analogia nu este destul de corecta.
In cazul VHS i Betamax amndoua v permit s urmrii video - chiar dac o implementare a
ctigat. Insa nu este cazul cu BPML i BPEL. BPML a fost conceput ca o limb complet
formala, posibilitatea de a modela orice proces, i, prin intermediul unui BPMS (sistem de
management al proceselor de afaceri), desfurat ca un proces de software executabil fr
generarea oricrui cod software. Acest lucru nu este posibil, cu BPEL, deoarece BPEL nu este
un limbaj complet orientat pe proces. Pentru a ilustra acest lucru, reinei c BPEL este adesea
folosit n combinaie cu Java pentru a umple n "lipsa" semanticii. n plus, BPEL este adesea
legat de implementri de proprietate de motoare broker workflow sau integrare, intruct, BPML
a fost proiectat, implementat i, ca un motor de procesare pur concurent i distribuit.
n mod ironic, cea mai complet versiune de BPEL implementata astzi, este BPMS-ul deschis
al Intalio, care completeaza, de asemenea, semantica prin ndeplinirea spiritului caietului de
sarcini BPML. Poate c n viitor BPML va fi vzut n alte implementri BPEL. Singura
diferen n viitor va fi sintaxa, semantica nu. n acest sens, BPML nu poate fi evitat, deoarece
a fost proiectat pentru a fi semantic complet n conformitate cu reprezentarea formal a
proceselor de calcul Pi-calculus.
Lupta dintre BPML i BPEL este in general considerata ca un exemplu al puterii IBM i
Microsoft in startup-uri in stadiu incipient de a finaliza o stiv tehnologia de baz n centrul
modelului lor de afaceri.
BPEL i BPML sunt exemple de o tendin de programare orientat spre proces. BPEL i BPML
au mostenit conceptul de BPMS ca o capacitate IT de gestionare a proceselor de afaceri, jucnd
un rol similar cu un RDBMS pentru datele de afaceri.
ebXML
Business electronic folosind eXtensible Markup Language, cunoscut sub numele de XML e-
business, sau ebXML cum este de obicei menionat, este o familie de standarde de baza XML
sponsorizate de OASIS i ONU / CEFACT a crui misiune este de a oferi o infrastructur
deschis, bazata pe XML care permite utilizarea la nivel mondial de informaii de afaceri
electronice ntr-un mod interoperabil, sigur, i consecvent de ctre toi partenerii comerciali.
Arhitectura ebXML este un set unic de concepte; partea teoretic i o parte pusa n
aplicare n activitatea standardelor ebXML existente. n timp ce standardele ebXML adoptate
de ISO i OASIS cauta sa ofere mecanisme formale, care pot fi implementat direct XML-ului,
arhitectura ebXML este pe concepte i metodologii care pot fi aplicate n sens mai larg, pentru
a permite practicanilor s pun n aplicare mai bine soluii de e-business.
O instan speciala este Core Components Specificatii tehnice (CCTs) activitatea care continu
n ONU / CEFACT, n timp ce partenerul sau - UBL - Universal Business Language - caietul
de sarcini este utilizat n OASIS care implementeaz operaiuni XML specifice prin aplicarea
principiilor de CCTs a lanului tipic de efectuare a tranzacilor, cum ar fi factura, comanda de
achiziie, o notificare a navelor i aa mai departe.
PSL (ISO 18629)
Process Specification Language (PSL) este un set de termeni logici folositi pentru a descrie
procese. Termenii logici sunt specificati ntr-o ontologie care ofer o descriere formal a
componentelor i relaiile lor, care alctuiesc un proces. Ontologia a fost dezvoltaat la Institutul
National de Standarde si Tehnologie (NIST), i a fost aprobat ca un standard internaional n
documentul ISO 18629.
Process Specification Language poate fi utilizat pentru reprezentarea de fabricaie, de
inginerie i procese de afaceri, inclusiv sistematizarea produciei, procesul de planificare,
managementul fluxului de lucru, proceselor de afaceri reengineering, simularea, realizarea
procesului, modelarea proceselor, i management de proiect. n domeniul de fabricaie,
obiectivul PSL este de a servi ca o reprezentare comun pentru integrarea mai multor aplicaii
legate de proces de-a lungul ciclului de via al procesului de fabricaie.
Aceasta ontologie ofer un vocabular de clase i relaii pentru concepte la nivelul de baza al
evenimentelor-instante, obiecte-instane, i momente de timp. La nivel superior PSL este
construit astfel:
Activitatea, o clas sau tip de aciune, cum ar fi o parte de instalare, care este clasa de aciuni
n care sunt instalate piese.
Activitatea-eveniment, un eveniment sau o aciune care are loc ntr-un loc i timp specific,
cum ar fi o instan specific pentru o parte de instalare care apare la un anumit moment de
timp.
Momentul de timp, un punct n timp
Obiect, ceva care nu este o moment de timp sau o activitate.
XPDL
Limbajul de proces XML Definition (XPDL) este un format standardizat de Workflow
Management Coalition (WfMC) pentru a interschimba definiii ale proceselor de afaceri ntre
diferite produse in dezvoltare, i anume ntre diferite instrumente de modelare i de
management. XPDL definete o schem XML pentru specificarea partii declarative a fluxului
de lucru / proceselor de afaceri.
XPDL este conceput pentru a redefini definiia de proces, att grafica si semantica unui
proces de afaceri aflat in dezvoltare. XPDL este in prezent cel mai bun format de fiier pentru
schimbul de diagrame BPMN; acesta a fost special conceput pentru a stoca toate aspectele
legate de o diagram BPMN. XPDL conine elemente care dein informaii grafice, cum ar fi
poziia X i Y a ganglionilor, precum i asupra aspectelor executabile care ar fi folosite pentru
a rula un proces. Aceasta distinge XPDL din BPEL care se concentreaz exclusiv pe aspectele
executabile ale procesului. BPEL nu conine elemente care s reprezinte aspectele grafice ale
unei diagrame de proces. Se poate spune c XPDL este serializarea XML al BPMN.
V. Mesagerie:
Canale de comunicare
HTTP Hypertext Transfer Protocol (HTTP) este un protocol de cerere pentru
sisteme distribuite, colaborative, informaii hipermedia. HTTP este fundamentul de
comunicaii de date pentru World Wide Web.
 Hypertext reprezinta textul structurat care utilizeaz legturi logice (hyperlink-uri) ntre
noduri ce conin text. HTTP este protocolul pentru a schimba sau de efectua un transfer
hipertext.
Funciile HTTP sunt protocoale de tip cerere-rspuns n modelul de calcul client-server. Un
browser web, de exemplu, ar putea fi clientul i o aplicaie care ruleaz pe un computer de
gazduire pe un site web poate fi server. Clientul depune un mesaj de cerere HTTP la server.
Serverul, care ofer resurse, cum ar fi fiiere HTML i alte tipuri de coninut, sau exercit alte
funcii n numele clientului, returneaz un mesaj de rspuns la client. Rspunsul conine
informaii de stare de finalizare cu privire la cererea i pot conine, de asemenea, coninutul
solicitat n corpul su mesaj. Un browser web este un exemplu de un agent utilizator (UA). Alte
tipuri de agent utilizator includ software-ul de indexare utilizat de ctre furnizori de cutare
(web crawlers), browsere vocale, aplicaii mobile, i alte software-ul care acceseaz, consum,
sau afieaz coninut web.
HTTP este conceput pentru a permite elemente intermediare de reea pentru a mbunti
sau a permite comunicarea ntre clieni i servere. Site-uri cu trafic mare de multe ori
beneficiaza de servere Web Cache cu livrare coninutului partiala pentru a mbunti timpul
de rspuns. Browsere Web Cache care au accesat anterior resurse web, le reutilizeaza atunci
cnd este posibil, pentru a reduce traficul n reea. Servere proxy HTTP la frontierele reelei
private pot facilita comunicarea pentru clienti fr o adres la nivel global rutabil, prin
retransmiterea cu servere externe.
HTTP este un protocol aplicaie stratificat, proiectat n cadrul Internet Protocol Suite.
Definiia sa presupune un protocol de transport de baz i de ncredere, unde Transmission
Control Protocol (TCP) este frecvent utilizat. Cu toate acestea, HTTP pot utiliza protocoale
nesigure precum User Datagram Protocol (UDP), de exemplu n serviciu Simple Discovery
Protocol (SSDP).
Resurse HTTP sunt identificate i situate pe reeaua de resurse uniforme (URL-uri), folosind
Uniform Resource Identifier (URI) schemele HTTP i HTTPS. URI-urile i hyperlink-uri n
documente Hypertext Markup Language (HTML) formeaz documentele interconectate
hipertext.
HTTP / 1.1 este o revizuire a HTTP original (HTTP / 1.0). n HTTP / 1.0 o conexiune
separat la acelai server se face pentru fiecare cerere de resurse. HTTP / 1.1 pot reutiliza o
conexiune de mai multe ori pentru a descrca imagini, script-uri, foi de stil, etc., dup ce pagina
a fost livrata. Prin urmare, comunicaiile HTTP / 1.1 suporta mai putina laten deoarece
stabilirea de conexiuni TCP prezint efort considerabil.
Metoda revocarii la distanta
Metoda Java de revocare la distanta (Java RMI) este un API Java care efectueaz echivalentul
de apeluri si de proceduri orientate pe obiect la distan (RPC), cu suport pentru transfer direct
de clase Java serializate i de colectare a resurselor uzate distribuite.
Implementarea original depinde de mecanismul de reprezentare a claselor Java Virtual
Machine (JVM), prin urmare, doar efectuarea apelurilor de la un JVM la alta. Protocolul care
st la baza acestei implementari Java este cunoscut sub numele de Java Remote Method
Protocol (JRMP).
 n scopul de a sprijini codul ce ruleaz ntr-un context non-JVM, o versiune CORBA a fost
dezvoltata ulterior.
Utilizarea termenului RMI poate nsemna doar interfaa de programare sau poate nsemna att
API i JRMP, IIOP, sau o alta implementare, n timp ce termenul de RMI-IIOP denot n mod
special delegarea interfaei RMI cu maxim de funcionalitate pentru suportul implementarii
CORBA.
Ideea de baz a Java RMI, protocolul colectarii resurselor uzate distribuite (DGC), i o mare
parte din arhitectura care st la baza punerii n aplicare pentru SUN, provin de la "obiecte de
reea", caracteristica Modula-3.
Programatorii de la RMI API au generalizat codul ca s sprijine diferite implementri, cum ar
fi transportul HTTP. n plus, capacitatea de a trece argumente "de valoare" a fost adaugat in
CORBA pentru a fi compatibil cu interfaa RMI. Totui, implementrile RMI-IIOP i JRMP nu
au interfee complet identice.
Common Object Request Broker Architecture (CORBA)
Common Object Request Broker Architecture (CORBA) este un standard definit de Object
Management Group (OMG) conceput pentru a facilita comunicarea de sisteme care sunt
dislocate pe diverse platforme. CORBA permite colaborarea dintre sistemele pe diferite sisteme
de operare, limbaje de programare, i hardware-ul de calcul. CORBA are multe din aceleai
obiective de design ca programarea orientata pe obiecte: ncapsulare i reutilizarea. CORBA
foloseste un model orientat pe obiect, dei sistemele care folosesc CORBA nu trebuie s fie
orientate pe obiect. CORBA este un exemplu de paradigma a obiectului distribuit.
CORBA permite comunicarea ntre software-uri scrise n diferite limbi i ruleaz pe computere
diferite. Detaliile de implementare de la sisteme de operare, limbaje specifice de programare i
platforme hardware sunt toate eliminate din responsabilitatea de dezvoltatori care folosesc
CORBA. CORBA normalizeaza semantica metodei de apel ntre obiecte aplicaie care lse afla
fie n aceeai adres de spaiul (cerere) sau adrese de spaii izolate (aceeai gazd, sau gazd de
la distan ntr-o reea). Versiunea 1.0 a fost lansat in octombrie 1991.
CORBA foloseste un limbaj de definiie a interfaei (IDL) pentru a specifica interfetele pe care
obiectele sunt prezentate n lumea exterioar. CORBA specifica apoi o mapare de la IDL la o
implementare n limbaje specifice, cum ar C ++ sau Java. Exist mapri standard pentru Ada,
C, C ++, C ++ 11, COBOL, Java, Lisp, PL / I, Python, Ruby i Smalltalk. Exist mapri non-
standard pentru C #, Erlang, Perl, Tcl i Visual Basic implementat de object request brokers
(ORBs) scrise pentru aceste limbi.
Caietul de sarcini CORBA dicteaz ca trebuie s existe un ORB, prin care o cerere ar
interactiona cu alte obiecte. Acesta este modul n care este implementata n practic:
1. Cererea pur i simplu initializeaza ORB, i acceseaz un adaptor de obiect intern, care
menine lucruri cum ar fi numararea referinelor, politici de instaniere a obiectului (i de
referin), i a politicilor ciclului de viata a obiectelor.
2. Adaptorul obiect este folosit pentru a nregistra instante a claselor generate. Clasele cu codul
generat sunt rezultatul compilrii codului de utilizator IDL, care se traduce n definiia de
interfa de nivel nalt ntr-un OS - i clasa bazata pe limbaj specific pentru utilizarea de ctre
aplicaia utilizator. Acest pas este necesar pentru a pune n aplicare semantica CORBA i s
ofere un procedeu de utilizare curat pentru interfaarea cu infrastructura CORBA.
SOAP
SOAP, iniial un acronim pentru Simple Object Access Protocol, este o specificaie de protocol
pentru schimbul de informaii structurate n punerea n aplicare de servicii web n reele de
calculatoare. Acesta utilizeaz setul de informatii XML pentru formatul mesajului, i se bazeaz
pe alte protocoale strat de aplicare, mai ales Hypertext Transfer Protocol (HTTP) sau Mail
Transfer Protocol Simple (SMTP), pentru mesajul de negociere i de transport.
SOAP poate forma stratul de fundaie al unei stive pentru protocol de servicii web, oferind un
cadru de mesaje de baz pentru servicii web. Acest protocol bazat pe XML este format din trei
pri:
un plic, care definete structura mesajului i cum s-l proceseze
un set de reguli de codare pentru exprimarea cazuri de tipuri de date definite de aplicaie
o convenie pentru reprezentarea procedur apeluri i rspunsuri
SOAP are trei caracteristici majore:
1. extensibilitate (securitate i WS-rutare sunt printre extensiile n curs de dezvoltare)
2. neutralitate (SOAP poate funciona pe orice protocol de transport, cum ar fi HTTP, SMTP,
TCP, UDP, sau JMS)
3. independena (SOAP permite orice model de programare)
Ca un exemplu de ceea ce pot face procedurile SOAP, o aplicatie poate trimite o cerere SOAP
la un server care are servicii web, cum ar fi o baza de date cu parametrii pentru o cutare.
Serverul returneaz apoi un rspuns SOAP (un document formatat-XML cu datele rezultate),
de exemplu, preuri, locaie, caracteristici. Avnd n vedere c datele generate vin ntr-un format
standardizat ce suporta prelucrarea de masina, aplicaia solicitanta poate apoi integra direct
raspunsul.
Arhitectura SOAP este formata din mai multe straturi ale caietulului de sarcini pentru:
format de mesaj
modele pentru schimbul de mesaje (MEP)
protocolate pentru legturi de transport
modele de prelucrare a mesajelor
protocol pentru extensibilitate
Semantica mesajelor
EDIFACT
United Nations/Electronic Data Interchange For Administration, Commerce and Transport
(UN/EDIFACT) este standardul EDI internaional elaborat n cadrul Organizaiei Naiunilor
Unite. n 1987, n urma convergena ONU i propunerile de sintax SUA / ANSI, / EDIFACT,
regulile de sintax ONU au fost aprobate ca standardul ISO ISO 9735 de ctre Organizaia
Internaional de Standardizare. Standardul EDIFACT prevede:
un set de reguli de sintax pentru a structura datele,
un protocol de schimb interactiv (I-EDI),
mesaje standard care permit schimburi multinaionale i multi-industriale.
Activitatea de ntreinere i dezvoltare ulterioar a acestui standard se face prin Centrul
Naiunilor Unite pentru facilitarea comerului i afacerilor electronice (ONU / CEFACT) sub
supravegherea Comisiei Economice a ONU pentru Europa, n grupul de lucru al domeniului de
Finane ONU CEFACT TBG5.
Universal Business Language (UBL)
UBL este o bibliotec de standarde XML electronice si documente de afaceri, cum ar fi ordinele
de cumprare i facturi. UBL a fost dezvoltat de un comitet tehnic OASIS cu participarea de
organizaii de standardizare dintr-o varietate mare din industrie. UBL este conceput pentru a
conecta direct n afaceri existente, legale, de audit, precum i practicile de administrare a
nregistrrilor. Acesta este conceput pentru a elimina re-keying de date n faxurile existente i
a corespondenei de afaceri, pe suport de hrtie i s ofere un punct de intrare n comerul
electronic pentru ntreprinderile mici i mijlocii.
UBL este detinuta de OASIS si este disponibila in prezent pentru toi, fr taxe de redeven.
Biblioteca UBL de documente de afaceri este un limbaj de marcare bine dezvoltat cu
validatoare, software de creaie, parsere i generatoare. UBL versiunea 2.0 a fost aprobat ca
standard OASIS n octombrie 2006, iar versiunea 2.1 a fost aprobat ca standard OASIS n
noiembrie 2013. Versiunea 2.1 este pe deplin compatibil cu versiunea 2.0, dar se adaug 34 de
noi scheme de documente, aducand totalul de tipuri de documente de afaceri definit de UBL la
65. UBL urmareste originile sale napoi la standardele EDI i alte standarde XML derivate.
OAGIS
Open Applications Group Integration Specification (OAGIS): OAGIS definete un model de
coninut comun i mesaje comune de comunicare ntre aplicaiile de afaceri. Aceasta include
integrarea aplicaie la aplicaie (A2A) i business-to-business (B2B). Organizaie: OAGis.
OAGIS este un proiect comun al marilor companii n primul rnd din industria IT pentru
integrarea aplicaiilor n cadrul unei ntreprinderi i dincolo de graniele corporative. OAGIS se
bazeaz pe limbajul de marcare XML. OAGIS este mprit n cinci seciuni:
1. O arhitectur de referin abstracta pentru sisteme de informaii de afaceri.
2. O descriere a "Componente Software Business" tipice.
3. "Diagramele scenariului" pentru a ilustra comunicarea ntre componente.
4. Ca elemente de baz, o list de interfee de programare aplicaii (API) a componentelor.
5. Directorul de date Dicionarul asociat (OAG99a).

RosettaNet
RosettaNet este un consoriu non-profit care vizeaz stabilirea unor procese standard pentru
schimbul de informaii de afaceri (B2B). RosettaNet este un consoriu de calculator major i
electronice de consum, Componente electronice, Semiconductor Manufacturing, companii de
telecomunicatii si logistica care lucreaz pentru a crea i a pune n aplicare, standardele pentru
proces deschis de e-business la nivel de industrie. Aceste standarde formeaz un limbaj comun
e-business, procese ntre partenerii din lanul de aprovizionare la nivel global.
RosettaNet este o filial a GS1 SUA, fostul Uniform Code Council, Inc. (UCC). Acesta
a fost format n principal prin eforturile depuse de Fadi Chehade, primul CEO. In cadrul
RosettaNet, 500 de membri provin de la companii din intreaga lume. Consoriul are o prezen
n Statele Unite ale Americii, Malaezia, Europa, Japonia, Taiwan, China, Singapore, Thailanda
i Australia.RosettaNet are mai multe grupuri de utilizatori locali. Utilizatorul din Grupul
european este numit EDIFICE.
Standardul RosettaNet se bazeaz pe XML i definete orientrile mesajelor, interfeelor pentru
procesele de afaceri, i cadrele de punere n aplicare pentru interaciunile dintre companii. Cel
mai mult adresata este zona lanului de aprovizionare, dar, de asemenea de fabricaie, produse
i materiale de date i procese de servicii care sunt n domeniul de aplicare.
Standardul este larg rspndit n industria de semiconductori la nivel mondial, dar, de
asemenea, n componente electronice de larg consum, telecomunicaii i logistic. RosettaNet
isi are originea n SUA i este utilizat pe scar larg acolo, dar este, de asemenea, bine acceptat
i chiar sprijinita de guvernele din Asia. Ca urmare a utilizrii pe scar larg a EDIFACT n
Europa, RosettaNet este folosit mai puin, dar este un standard in dezvolatre.The RosettaNet
Automated Enablement standard (RAE) utilizeaz standardul document XML Office Open.
Dicionarul Tehnic RosettaNet (RNTD) este modelul de referin pentru clasificarea i
caracterizarea produselor n lanurile de aprovizionare care utilizeaz RosettaNet pentru
interaciunile lor.
MANDATE
ISO 15531-1: 2004 ofer o prezentare general a ntregului standard IOS 15531. Acesta
specific domeniul de aplicare i ofer o serie de definiii de baz pe care ntregul standard este
construit n conformitate cu "Teoria Sistemului General" i conceptele definite n dicionarul
APICS. Anexele sale informative ofer o descriere a relaiilor dintre MANDATE i alte
standarde (n special standarde ISO / TC 184), precum i o clarificare a conceptelor de
"capabilitate i capacitatea" aa cum sunt utilizate n MANDATE i in alte standarde care se
refer n mod explicit sau implicit la teoria sistemului.
MANDATE abordeaza modelarea managementului fabricaiei de date , cum ar fi:
Managementul datelor resursa (Resource model);
caracteristici de timp (Time model);
date gestionate in fluxul de fabricaie (Flow management model).
MANDATE, n asociere cu STEP, PLIB i alte standarde SC 4 (sau non SC 4), pot fi utilizate
n orice aplicaie software care se adreseaz gestionarii informaiilor referitoare la datele de
management a resurselor, fluxul de date de management. Ca atare, standardul este destinat s
faciliteze schimbul de informaii ntre aplicaii software, cum ar fi ERP, software de
management de fabricaie, software de management de ntreinere, software-ul citat, etc.
MANDATE a fost scris n EXPRESS. n timpul fazelor de dezvoltare ale standardului
MANDATE, compatibilitatea standard cu 10,303 (STEP) standardul ISO a fost subiectul unei
analize aprofundate.
STEP (ISO 10301)
ISO 10303 este un standard ISO pentru reprezentarea interpretabila pe calculator i schimbul
de informaii despre produsul de fabricaie. Titlul su oficial este: sisteme de automatizare i
integrare - reprezentare a datelor de produs i de schimb. Este cunoscut informal drept "STEP",
care vine de la "standard pentru schimbul de date pentru model de produs". ISO 10303 poate
reprezenta obiecte 3D n proiectarea asistat de calculator (CAD) i a informaiilor relationate.
Obiectivul standardului international, este de a oferi un mecanism care este capabil de a descrie
date de produse de-a lungul ciclului de via al unui produs, independent de orice sistem
particular. Natura acestei descrieri l face potrivit nu numai pentru schimbul de fiiere neutre,
dar, de asemenea, ca baz pentru punerea n aplicare i schimbul de baze de date de produse si
arhivare.
De obicei STEP poate fi folosit pentru a face schimb de date ntre CAD, fabricaie asistat de
calculator, inginerie asistat de calculator, date produs de modelare a datelor de management /
ntreprinderi i alte sisteme CAX. STEP adreseaz date de produse de la proiectare mecanice i
electrice, dimensionarea geometric i toleranta, analiza de fabricaie, precum i informaii
suplimentare specifice diferitelor industrii, cum ar fi industria auto, industria aerospaial,
pentru constructii, nave, petrol i gaze, instalaii industriale i altele.
STEP este dezvoltat i meninut de ctre comitetul tehnic ISO TC 184, Sisteme de automatizare
i integrare, sub-comisia SC 4, date industriale. Ca i alte ISO i IEC standardul STEP are
dreptul de autor de la ISO i nu este disponibil gratuit. Cu toate acestea, 10303 schemele
Express sunt disponibile n mod liber, la fel ca i practicile recomandate pentru implementatori.
Modele de inregistrare
UDDI
Universal Description, Discovery and Integration (UDDI) este independent de platforma,
bazat pe registrul Extensible Markup Language (XML), prin care ntreprinderile din ntreaga
lume se pot afisa pe Internet, precum i un mecanism de a nregistra i localiza aplicaiile de
servicii web. UDDI este o iniiativ pentru industria deschisa, sponsorizata de Organizaia
pentru promovarea standardelor referitoare la informaia structurat (OASIS), pentru a permite
companiilor de a publica anunuri de servicii i de a se descoperi reciproc, i pentru a defini
modul n care serviciile sau aplicaiile software vor interaciona pe Internet.
UDDI a fost iniial propus ca un standard de serviciu Web de baz. Acesta este conceput
pentru a fi interogat de mesaje SOAP i pentru a oferi acces la documente Web Services
Description Language (WSDL), care descriu legturile de protocol i formatele de mesaje
necesare pentru a interaciona cu serviciile web enumerate n directorul su.
O nregistrare de afaceri UDDI este format din trei componente:
Paginile albe - adresa, contact, i date de identificare cunoscute;
Pagini Aurii - clasificarea industrial bazat pe taxonomii standard;
Pagini verzi - informaii tehnice despre serviciile expuse de afaceri.

Paginile albe
Paginile albe ofer informaii despre afaceri care furnizeaz serviciul. Aceasta include numele
de afaceri i o descriere a activitii - potenial n mai multe limbi. Folosind aceast informaie,
este posibil de a gsi un serviciu despre care unele informaii sunt deja cunoscute (de exemplu,
localizarea un serviciu bazat pe numele furnizorului). Date de contact pentru afaceri este
prevzut - de exemplu adresa ntreprinderii i numrul de telefon;
Paginile aurii
Pagini aurii ofer o clasificare a serviciului sau a afacerii, bazat pe taxonomii standard. Acestea
includ Clasificarea Standard industrial (SIC), Industria de Clasificare pentru Sistemul American
de Nord (NAICS), sau de United Nations Standard Products and Services Code (UNSPSC) i
taxonomiile geografice. Deoarece o singura afacere poate oferi o serie de servicii, pot exista
mai multe Pagini Aurii (fiecare descriind un serviciu) asociate cu o pagin alb (care ofer
informaii generale despre afaceri).
Paginile verzi
Paginile verzi sunt folosite pentru a descrie modul de a accesa un serviciu web, cu informaii
cu privire la legturile de servicii. O parte din informaiile sunt legate de serviciul Web - cum
ar fi adresa serviciului i parametrii, i trimiterile la specificaiile de interfee. Alte informaii
nu sunt direct legate de Serviciul Web - aceasta include e-mail, FTP, CORBA i detalii de
telefon pentru serviciul. Deoarece un Web Service poate avea mai multe legturi (aa cum este
definit n descrierea WSDL), un serviciu poate avea mai multe pagini verzi, deoarece fiecare
mapare obligatoriu va trebui s fie evaluat n mod diferit.
 Meta-Object Facility (MOF)
Facilitatea Meta-Object (MOF) este un grup de gestionare a standardelor pentru
inginerie bazate pe modelul de obiecte (OMG). Scopul su este de a oferi un sistem tipic pentru
entitile din arhitectura CORBA i un set de interfee prin care aceste tipuri pot fi create i
manipulate. Pagina oficial de referin pot fi gsite pe site-ul OMG lui.
MF a fost dezvoltat pentru a oferi un sistem tipic pentru utilizare n arhitectura CORBA,
un set de scheme prin care structura, semnificaia i comportamentul obiectelor ar putea fi
definit, i un set de interfee CORBA, prin care ar putea fi create aceste scheme, depozitate i
manipulate .
MF este conceput ca o arhitectura de patru straturi. Acesta ofer un model-meta de la
stratul de sus, numit stratul de M3. Acest M3 model este limbajul folosit de MF pentru a construi
metamodelele, numit M2-modele. Cel mai important exemplu de un model de Layer 2 MF este
metamodelului UML, modelul care descrie UML n sine. Aceste modele-M2 descriu elemente
ale stratului M1, i astfel M1-modele. Acestea ar fi, de exemplu, modelele scris n UML.
Ultimul strat este M0-strat sau stratul de date. Este folosit pentru a descrie obiecte din lumea
real.
Dincolo de M3-model, MF descrie mijloacele de a crea i manipula modele i
metamodele prin definirea interfeelor CORBA care descriu aceste operaiuni. Din cauza
asemnrilor dintre MOF M3-model i modele de structura UML, metamodelele MOF sunt de
obicei modelate ca diagrame de clase UML. Un standard de susinere a MF este XMI, care
definete un format de schimb bazat pe XML pentru modelele pe M3-, M2-, sau M1-Layer.
Metadata Registry (MDR)
ISO / IEC 11179 (cunoscut anterior ca 11179 Metadata Registry (MDR) standardul ISO / IEC)
este un standard internaional pentru reprezentarea metadatelor pentru o organizaie ntr-un
registru de metadate.
Organizaiile fac schimb de date ntre sistemele informatice utiliznd tehnologii pentru
integrarea aplicaiilor ntreprinderii. Tranzaciile finalizate sunt adesea transferate n sistemele
de depozitare a datelor i sisteme cu regule de business cu structuri concepute pentru a sprijini
datele pentru analiza. Un model de facto standard pentru platforme de integrare a datelor este
Common Warehouse Metamodel (CWM). Integrarea datelor este adesea rezolvat ca o
problem de date, mai degrab dect metadate, cu utilizarea aa-numitelor date de baz. ISO /
IEC 11179 susine c este un standard pentru schimbul de date bazat pe metadate ntr-un mediu
eterogen, pe baza definiiilor exacte ale datelor.
11179 Modelul ISO / IEC este un rezultat a dou principii ale teoriei semantice, combinate cu
principiile de baz de modelare a datelor.
Primul principiu de la teoria semantic este relaia de tip tezaur dintre concepte mai largi i mai
nguste (sau specifice), de exemplu, conceptul larg"venituri" are o relaie cu conceptul mai
ngust "venitul net".
Al doilea principiu de la teorie semantic este relaia dintre un concept i reprezentarea sa, de
exemplu, "cumpr" i "procura" sunt acelai concept, dei termeni diferii sunt used.Un
principiu de baz al modelrii datelor este o combinaie de clase de obiecte i o un caracteristic.
De exemplu, "persoana - culoarea prului".
Atunci cnd se aplic pentru modelarea datelor, ISO / IEC 11179 combina un "concept de"
lime, cu o "clas de obiecte", pentru a forma un "concept de element de date" mai specific.
De exemplu, la nivel nalt conceptul de "venituri" este combinat cu clase de obiecte "persoan",
pentru a forma conceptul element de date "venitul net de persoane". Reinei c "venitul net"
este mai specific dect "venituri".
Diferitele reprezentri posibile ale unui concept element de date sunt apoi descrise cu utilizarea
unuia sau mai multor elemente de date. Diferenele n reprezentare poate fi o urmare a utilizrii
de sinonime sau diferite domenii de valori n seturi de date diferite ntr-o exploataie de date.
Un domeniu valoare este gama permisa de valori pentru o caracteristic a unei clase de obiecte.
Un exemplu de domeniu valoare pentru "sex de persoan" este "M = Barbat, F = Femeie, U =
necunoscut". Literele M, F i U sunt apoi valorile permise pentru sexul unei persoanei dintr-un
anumit set de date.
Conceptul element de date "venit net lunar de persoan" poate avea, prin urmare, un element
de date numit "venit net lunar individual pentru grupri de 100 dolari" i unul numit "venit net
lunar individual din gama 0-1000 dolari", etc., n funcie de eterogenitatea de reprezentare care
exist n exploataiile de date care fac obiectul un registru ISO / IEC 11179. Reinei c aceste
dou exemple prezinta diferiti termeni de clase de obiecte (persoan / persoana) si seturi de
valoare diferite (interval 0-1000 dolari, spre deosebire de grupari individuale de 100 dolari).
Rezultatul este un catalog de elemente sortate, n care conceptele de elemente de date legate
sunt grupate pe un concept la nivel nalt i o clas obiect, iar elementele de date grupate - dup
un concept element de date comune. Strict vorbind, aceasta nu este o ierarhie, chiar dac
seamn cu una.
ISO / IEC 11179 nu descrie exactmetoda de stocare a datelor aa cumacestea sunt fapt stocate.
Aceasta nu se refer la descrierea fiierelor fizice, tabelor i coloanelor. Constructiile ISO / IEC
11179 sunt "semantice", spre deosebire de "fizice" sau "tehnice".
Standardul are dou scopuri principale: de definiie i de schimb. Obiectul de baz este
conceptul elementului de date, deoarece definete un concept i, n mod ideal, descrie date
independente de reprezentarea sa n oricare dintre sisteme, tabele, coloane sau organizaii.
Dictionare conceptuale
Object Management Group (OMG)
The Object Management Group (OMG) este un organism deschis internaional, consoriu
non-profit al standardelor tehnologice. Grupuri Operative OMG dezvolta standarde de integrare
ale companiei pentru o gam larg de tehnologii i industrii. Modelarea de standarde OMG
permite design vizual, executie si intretinere de software i a altor procese. Iniial vizeaz
standardizarea sistemelor orientate pe obiecte distribuite, compania se concentreaza acum pe
modelare (programe, sisteme i procese de afaceri) i a standardelor bazate pe modele.
OMG ofer numai caietul de sarcini, i nu ofer implementri. Dar, nainte ca o specificaie
sa fie acceptat ca un standard de OMG, membrii echipei castigatoare submise trebuie s
garanteze c acestea vor aduce un produs conform cu piata intr-un an. Aceasta este o ncercare
de a preveni standarde neimplementate.
Alte companii private sau grupuri open source sunt ncurajate pentru a dezvolta produse
conform OMG , iar acesta ncearc s dezvolte mecanisme pentru a pune n aplicare adevrat
interoperabilitate.
 OMG gzduiete patru ntlniri tehnice pentru membrii si i cei interesati sa devina
membri. ntlnirile tehnice ofere un forum neutru pentru a discuta, dezvolta i adopta standarde
care s permit interoperabilitatea software pentru o gam larg de industrii, inclusiv: finante,
fabricaie, asisten medical, robotica, bazat pe software de comunicaii, securitate, guvern,
spaiu i mai mult. n martie 2015, reuniunea a avut loc n TC Reston, VA; n luna iunie 2015,
n Berlin, Germania, n septembrie 2015, n Cambridge, MA; iar n decembrie 2015, la
reuniunea este La Jolla, CA.
Semantics of Business Vocabulary and Business Rules (SBVR)
Semantics of Business Vocabulary and Business Rules (SBVR) este un standard adoptat de
Object Management Group (OMG) destinat a fi baza pentru limba naturala declarativ formal
i detaliat a unei entiti complexe, cum ar fi o afacere. SBVR este destinat s oficializeze
reguli de conformitate complexe, cum ar fi normele de exploatare pentru o ntreprindere,
politica de securitate, respectarea standardelor, sau reguli de conformitate de reglementare.
Astfel de vocabulare formale i norme pot fi interpretate i utilizate de ctre sistemele
informatice. SBVR este o parte integrala din arhitectura bazata pe model OMG (MDA).
Standardul SBVR definete vocabularul i regulile pentru documentarea semantica de afaceri,
fapte de afaceri, precum i regulile de business; precum i o schem XMI pentru schimbul de
vocabulare de afaceri i reguli de afaceri ntre organizaiile i ntre instrumente software.
SBVR permite producerea de vocabulare i reguli de afaceri; vocabularul plus regulile
constituie un model de domeniu comun cu aceeai putere expresiv a limbilor ontologice
standard. SBVR permite dezvoltarea multilingv, deoarece se bazeaz pe separarea ntre
simboluri i semnificaia lor. SBVR permite regulilor de afaceri sa devina accesibile
instrumentelor software, inclusiv instrumente care susin experii de afaceri n crearea,
gsirea, validarea, i gestionarea regulilor de business, i instrumente care susin experii de
tehnologie a informaiei n transformarea normelor de afaceri n norme de punere n aplicare
pentru sistemele automate.
SBVR foloseste Meta-Object Facility (MF) al OMG-ului, pentru a oferi functionalitate de
schimb MF / XMI ale regulilor de mapare, permite generarea de modele MOF-conforme i s
defineasc o schem XML. SBVR propune limba englez structurata ca una dintre mai multe,
eventual, notaii, care pot mapa metamodelul SBVR.
SBVR i Knowledge Discovery Metamodell (KDM) sunt concepute ca dou pri ale unui
unic OMG Technology Stack de analiza software legate de sistemele de software existente.
KDM definete o ontologie legate de artefacte de software i, prin urmare, ofer o formalizare
iniial a informaiilor legate de un sistem software. SBVR pot fi utilizate n continuare pentru
a formaliza reguli complexe de conformitate referitoare la software-ul.
Regulile de afaceri reprezint principalul mijloc prin care o organizaie poate direciona
activitatea, definind modul operativ de a ajunge la obiectivele sale i de a efectua aciunile
sale.
O abordare bazat pe reguli pentru gestionarea de afaceri i informaiile utilizate de afaceri
este un mod de a identifica i articula normele care definesc structura i controleaz
funcionarea unei ntreprinderi. Acestea reprezint un nou mod de a gndi despre companie i
normele sale, n scopul de a permite o reprezentare complet de afaceri realizate de i pentru
oamenii de afaceri. Reguli de afaceri pot juca un rol important n definirea semantic de
afaceri: ei pot influena sau ghida comportamentul i politicile de sprijin, ca rspuns la situaii
i evenimente de mediu. SBVR este punerea n aplicare a abordrii OMG regulilor de afaceri.

Bibliografie:
1. Enterprise Engineering - A New Organizational Discipline. Liviu-Gabriel CREU Catedra
de Informatic Economic, Universitatea AL.I.Cuza Iai. Revista Informatica Economic,
nr.4 (40)/2006.
2. Business Rules Group - The Business Rules Manifesto,
http://www.businessrulesgroup.org/brmanifesto.htm, 2003
3. Dalal, P.N., et all Toward an Integrated Framework for modeling enterprise processes,
CACM, martie 2004, vol 47/3
4. Eriksson, H., Penker, M Business Modeling with UML, John Wiley&Sons, 2000
5. ISO TC184 SC5 WG1 - Modeling and Architecture Work program and key resources,
http://www.mel.nist.gov/sc5wg1/wg1-on-apage.pdf , 2000
6. ISO/IEC JTC1/SC21/WG7 - ISO 10746- ODPRM Architecture -
ftp://ftp.dstc.edu.au/pub/DSTC/arch/RMODP/PDFdocs/part3.pdf, 2002
7. ISO/IEC JTC1/SC21/WG7 - ISO 10746- ODPRM Foundations,
ftp://ftp.dstc.edu.au/pub/DSTC/arch/RMODP/PDFdocs/part2.is.pdf, 2002
8. ISO/IEC JTC1/SC21/WG7 - ISO 15414 ODPRM -6 Enterprise Language,
http://www.joaquin.net/ODP/DIS_15414_X.911. pdf, 2004
9. Jokers,H., et al - Towards a Language for Coherent Enterprise Architecture Descriptions,
Proceedings of the Seventh IEEE International EDOC Conference, 2003
10. K. Kosanke- Standards in Enterprise Interand Intra-Organisational Integration, CIMOSA
Asoc, http://www.eil.utoronto.ca/ ICEIMT04/kosanke.pdf, 2004
11. Kosanke K.- Overview on EM standardisation and international consensus activities,
CIMOSA Association, www.cimosa.de/ Standards/EMstand02.pdf, 2003
12. Levi, K., Arsanjani, A. A Goal Driven Approach to Enterprise component identification
and specification, CACM, oct 2002, vol. 45/10
13. Marshall, C. Enterprise modeling with UML, Addison-Wesley, 2000
14. Martin, R- ISO 19439&19440 -Framework and Constructs for enterprise modelling,
OMGBEIDTF, 2005
15. Nichi, . - Distributed, Cooperative and Collaborative support systems a general
framework, n vol. Innovative Applications of information technologies in business and
management, PIM, Iai, 2005
16. Nichi, ., Nichi, R. On the paradigm of collaborative support systems, n vol.
Collaborative support systems in business and education, RisoPrint, Cluj-Napoca, oct. 2005
17. OMG BPDM, http://www.bpmn.org/Documents/BPDM/OMGBPD-2004-01-12-
Revision.pdf, 2004
18. OMG Enterprise Collaboration Architecture Specification,
http://www.omg.org/docs/formal/04-02-01.pdf, 2004
19. OMG UML 2.0 Superstructure, www.omg.org/docs/formal/05-07-04.pdf, 2005
20. Ross, R - Principles of the Business Rule Approach, Adisson Wesley, 2003
21. Soderborg, N., Crawley, E.F, Dori, D. System function and architecture: OPM based
definitions and operational templates, CACM, oct 2003, vol 46/10
22 * * *, A survey of the real time economy, The Economist, 02
23. http://www.ia.ase.ro/Sie/SIE-4-2013.pdf. Sisteme informaionale Economice.
24. Rich Hilliard r.hilliard@computer.org. June 2007.
25. Federal Enterprise Architecture Framework. Version 2. January 29, 2013.
https://www.google.com/#q=federal+enterprise+architecture+framework+2012
26. Federal Enterprise Architecture. Chief Information Officer Council. Version 1.0
February 2001. http://www.gao.gov/assets/590/588407.pdf.
27. Robert Weisman. MSc, PEng, PMP, CD. CEO / Chief Enterprise Architect
robert.weisman@buildthevision.ca. 44 Montgomery Street, 1168 Ste Therese
Ottawa, Ontario, Canada, K1C2A6
28. Transitioning to ISO / IEC / IEEE-15288:2015 Joseph P. Elm Vice Chair, NDIA System
Engineering Division jelm@sei.cmu.edu.

TEMA 5
Conotaiile IDEF
IDEF0, DFD, IDEF1, IDEF3, IDEF4, IDEF9
Bazele Modelrii Sistemelor Informaionale

La etapa de proiectare se construiesc modele care redau arhitectura sistemului, alocarea

cerintelor pe subsisteme, distributia proceselor in sistem, sincronizarea lor, starile si tranzitiile
intre stari. Alte modele descriu realizarea fizica a sistemului, echipamentele din componenta
sa si repartitia componentelor program.
Fiecare vedere asupra unui sistem poate avea aspecte structurale si aspecte comportamentale.
In functie de natura sistemului, unele modele pot fi mai importante decat altele. De exemplu,
pentru unele sisteme sunt mai importante aspectele structurale si functionale, pentru altele
aspectele temporale.
Construirea modelelor este ghidata de metode. O metoda defineste o abordare reproductibila
care permite obtinerea de rezultate fiabile in mod repetat. Toate domeniile cunoasterii
utilizeaza metode mai mult sau mai putin sofisticate si mai mult sau mai putin formalizate. De
exemplu, bucatarii utilizeaza retete de bucatarie, arhitectii construiesc planuri, muzicienii
urmeaza reguli de compozitie.
Modelele sunt alcatuite din elemente de modelare care constituie concepte fundamentale
pentru reprezentarea sistemelor sau a fenomenelor. Elementele de modelare sunt adesea
notatii grafice. Ele constituie limbajul de modelare.
E de menionat c fa de limbajul de modelare, o metod definete reguli de aplicare care
descriu coordonarea diferitelor puncte de vedere, inlanuirea aciunilor, ordonarea sarcinilor i
repartizarea responsabilitilor.
Principalele scopuri ale modelarii sistemelor informatice sunt:
vizualizarea, ca mijloc de usurare a comunicarii si intelegerii;
specificarea, prin construirea de modele precise, neambigue si complete;
documentarea cerintelor, a solutiilor de proiectare si a modului de realizare.
Diverse metode sunt aplicate pentru modelare i proiectare sisteme care prezint
caracteristici ale ciclului de via dorite cum ar fi: flexibilitate, receptivitate,
scalabilitate, mentenabilitate, usurinta de utilizare, integrare, performan i pentru
angajarea echipelor de oameni n activiti critice de dezvoltare a ciclului de via al
sistemului.
 Un limbaj de modelare este orice limbaj artificial, care poate fi folosit pentru a
exprima informaii sau cunotine sau sisteme ntr-o structur care este definit de un
set consistent de reguli. Regulile sunt folosite pentru a interpreta rostul componentelor
n structura.
IDEF (Integration DEFinition) este o familie de limbaje de modelare n domeniul
sistemelor i ingineriei software. Acestea acoper o gam larg de utilizri, de la
modelarea funcional la date, simulare, analiza / proiectarea obiect-orientata i
achiziia de cunotine. Aceste "limbaje de definiie" au fost elaborate n conformitate
cu finanarea de la US Air Force i, dei nc cel mai frecvent folosite de acestea,
precum i alte agenii militare i Departamentul de Aparare (DoD), sunt n domeniul
public.
IDEF0: Modelare de funcii
IDEF1: Modelare de informaii,
IDEF1X: Modelare de date
DFD:
IDEF3: Captura descriere proces,
IDEF4: Design obiect-orientat
IDEF5: Captura descriere ontologie
IDEF9: Descoperirea constrangerilor de afaceri
IDEF0: Modelare de funcii - Metoda modelrii funcionale IDEF0 este destinat s
modeleze deciziile, aciunile, i activitile unei organizaii sau unui sistem. IDEF0 -
metodologie pentru simularea funcional. Cu intuitiv IDEF0 limb grafic este sistemul de
studiu la un set de funcii interdependente ( blocuri de funcii ). Ca o regul, instrumentul de
modelare IDEF0 este primul pas n analiza i studiul oricrui sistem;
IDEF1: Modelare de informaii - Metodologie pentru modelarea fluxurilor informaionale
n cadrul companiei sau a sistemului. V permite s afiai i s analizai structura fluxurilor
informaionale i relaiile lor;
IDEF1X: Modelare de date.- IDEF1X (IDEF1 extins) - metodologia de construcie a
structurilor relaionale. IDEF1X se refer la tipul de metodologii Esena relaiei, (ER -
entitate-relaie) i este utilizat de obicei pentru modelarea bazelor de date relaionale relevante
pentru acest sistem;
DFD: Modelarea Logic a datelor-
IDEF3: Captura descriere proces. - Metodologie pentru documentarea proceselor care au
loc n sistem. Cu IDEF3 se descriu scenariile i secvenele de operaii pentru fiecare proces.
IDEF3 este direct legat de metodologia IDEF0 - fiecare funcie (unitate funcional) poate fi
reprezentat prin intermediul IDEF3 ca un proces separat.
IDEF4: Modelare (Design) obiect-orientat. - IDEF4 - metodologie pentru construirea unor
sisteme orientate-obiect. Instrumentul IDEF4 permite vizualizarea structurii obiectelor i
principiile de interaciune a acestora, care permite analiza i optimizarea sistemelor orientate
pe obiecte complexe;
IDEF5: Captura descriere ontologie- IDEF5 - metodologie ontologic pentru cercetarea
sistemelor complexe. Cu ajutorul unui dicionar de termeni i norme permite pentru a descrie
i formaliza sistemul ontologic. IDEF5 sau Integrated Definition pentru Metodei de capturare
a descrierii ontologiei este o metod de inginerie software pentru a dezvolta si mentine
ontologii utilizabile, exacte. n domeniul ontologiilor informatice sunt utilizate pentru a
captura concepte i obiecte ntr-un domeniu specific, mpreun cu relaiile i semnificaiile
asociate. n plus, captarea ontologiei contribuie la coordonarea proiectelor prin standardizarea
terminologiei i creeaz oportuniti pentru reutilizarea informaiilor. Metoda de capturare a
ontologiei lDEF5 a fost dezvoltata pentru a construi fiabil ontologii ntr-un mod care reflect
strns nelegerea uman a domeniului specific. n metoda IDEF5, o ontologie este construit
prin captarea coninutul ale anumitor afirmaii despre obiectele din lumea reala, proprietile
lor, i relaiile lor i care reprezint acel coninut ntr-o form intuitiv si natural. Metoda
IDEF5 are trei componente principale: un limbaj grafic pentru a sprijini analiza ontologiei
conceptuale, un limbaj text structurat pentru caracterizarea ontologiei detaliate, precum i o
procedur sistematic, care ofer liniile directoare pentru a captura ontologia eficient.
IDEF9: Descoperirea constrangerilor de afaceri. - IDEF9 sau Integrated Definition pentru
descoperirea constrangerilor in mediul de afaceri este conceput pentru a ajuta la descoperirea
i analiza constrngerilor ntr-un sistem de afaceri. Motivaia principal pentru stimularea
dezvoltrii IDEF9 a fost o recunoatere a faptului c o colecie de constrngeri care fabrica un
sistem de ntreprindere este, n general, slab definita. Cunoatere a constrngerilor ce exist i
a modului n care interacioneaz aceste constrngeri este incomplet, disjunct, distribuit, i
de multe ori complet necunoscut. Aceast situaie nu este neaprat alarmant. La fel ca
organisme vii, nu trebuie s fie contieni de constrngerile genetice sau autonome care
guverneaz anumite comportamente, organizatiile pot (i cele mai multe o fac) s functioneze
bine fr a cunoate explicit care sunt structurile sistemului. Cu toate acestea, n cazul n care
exist dorina de a modifica afacerile ntr-un mod previzibil, cunoaterea acestor constrngeri
este la fel de critic ca i cunotinele de genetic pentru ingineria genetic
Semantica domeniului
Domeniul reprezint un set denumit i definit de mai multe valori i atribute pe care l
reprezint. Domeniile sunt definite separat de entiti i puncte de vedere, n scopul de a
permite reutilizarea i standardizarea lor n ntreaga antrepriz.
Un domeniu este considerat o clas pentru care exist o structur fix, i, eventual, set infinit
de cazuri
For example, State-Code would be considered a domain, where the set of allowable
values for the domain would satisfy the definition of a state-code (e.g. the unique
identifier of a state) and might consist of the two-letter abbreviations of the states.
Domeniile sunt considerate clase imuabile ale cror valori nu se modific n timp. Fiecare
instan domeniu are o valoare unic ntr-o reprezentare - adic, unic n acest domeniu.
 Exist dou tipuri de domenii, domeniu de baz i domeniu tastat (tip).
Unui domeniu de baz i poate fi atribuit un tip de date care poate fi unul dintre
urmtoarele: Caracter, numeric sau boolean. Pot fi utilizate i alte tipuri de date, cum
ar fi data, ora, binar, etc.
Domeniului de baz de regul i se atribuie:
o regul de domeniu.
Normele de domeniu
Normele de domeniu sunt folosite pentru a furniza valorile acceptabile ale unui domeniu. Cele
doua reguli de domeniu sunt comune pentru list de valori, precum i pentruregulile de
intervale.
Domeniile tip sunt sub-tipuri a domeniului de baz sau alte domenii tipizate, care pot
constrnge n continuare valorile acceptabile pentru domeniu. Un domeniu tip exist, n cazul
n care acesta este de tipul de date, i respect regulile de domeniu din domeniul su superior.
n acest fel, o ierarhie de domenii poate fi definit, cu reguli de domeniu din ce n ce mai
stricte mergnd n jos pe ierarhie. O ierarhie de domeniu este o ierarhie generalizat. Trebuie
de reinut c domeniile tip nu se exlud reciproc.

Diagrama de context (Context Diagram)

Diagrama de context: este un model al funciei din Domeniul (obiectul) la cel mai inalt nivel
de: intrari, control, mecanisme i ieiris
Intrari: elemente care declanseaza activitatea,
Control: ghideaza sau regleaza actrivitatea,
Mecanisme: sisteme, oameni, echipamente utilizate pentru a efectua activitatea,
Iesiri: rezultatele efectuarii activitatii.

Modelarea functiilor
Esena abordrii structurale, Principiile de baz la abordarea structural, Esena
metodologiei abordrii funcionale IDEF0, Noiuni principale a metodologiei IDEF0,
Reguli de construire modele n IDEF0, Exemple de modele funcionale n notaia IDEF0

Esena abordrii structurale

Subsistem Aplicaie 1
Funcional 1

SUBFUNCIA 1

SISTEMA Subsistem
Funcional 2 SUBFUNCIA 2 Aplicaie 2

Subsistem
Funcional n

SUBFUNCIA n Aplicaie n

Principiile de baz la abordarea structural

Principiul- divide i domin
Principiul- structurare ierarhic
Principiul- de abstracie
Principiul- eliminare conflicte
Principiul- structurare date
Modele ce se construesc la Abordaea Structural,
3 Tipuri de modele, sun utilizate n abordarea structural :
 1) Modele Funcionale ( F)
2) Modele Informaionale ( I)
3) Modele Dinamice ( D)
F SADT (IDEF0)-Modele Aplicaii BPWin, Design/IDEF
DFD- Modele Aplicaii BPWin

I ERD (IDEF1X) Aplicaii Design/IDEF, ERWin

D IDEF/CPN Aplicaii Design/IDEF

IDEF3 Aplicaii BPWin

IDEF0: Modelarea functiilor

IDEF0 modeleaza:
deciziile,
actiunile si
activitatile unei organizatii sau
activitatile unui sistem pentru a identifica perspectiva functional a sistemului.
Crearea Modelelor IDEF0 sunt una dintre primele sarcini in dezvoltarea unui sitem,
deoarece acestea :
- descriu functiile care sunt efectuate,
- descriu ce este necesar pentru a realiza aceste functii,
- descriu Sintaxa. (ontologia)
Diagrama de context

Boxes represent activities (verbs),

Arrows represent entities (things)
Each box is labelled, indexed and with arrows at each side representing:
Input: things transformed by the system
Output: what inputs are transformed to
Controls: constraints/rules of an activity
Mechanisms: resources/tools required to carry out the activity
Calls are a type of mechanism arrows that allow the sharing of information with other
models or sub sections of the model.
Decompoziia diagramei de Context (Decomposition Diagrama)
 0

:
-0
.:

1
2
3

31
32
33

3
Reguli de baz pentru construire diagrame
1. Pe o diagram se recomand de a interpreta ntre 3 i 6 blocuri. n caz contrar diagrama va
fi greu de interpretat.
2. Blocurile funcionale se poziioneaz de la stnga spre dreapta i de sus n jos n ordinea
(dominant) de subordonare.
3. Trebuie de evitat intersecii ecscesive ale arcurilor de interconecsiuni.

4. ieirea unui bloc poate fi o intrare pentru alt bloc din cadrul diagramei. Pot fi conexiuni
inverse spre intrare i ctre control

Conexiune pe control

Conexiune pe

5.Arcurile de conexiune pot fi contopite sau ramificate

Contopire
Ramificare
Ramificare
Arcuri marginale
Arcurile pe diagrama conextual servesc pentru a descrie interaciunea Sistemei cu mwediul
ambiant. Ele pot avea originea de la marginea diagramei i terminaia la blocul funcional i
invers n cazul ieiri. Aceste arcuri se numesc arcuri marginale. Arcuri marginale se
marcheaz cu ajutorul ICOM-semne (Input, Control, Output, Mechanism)

C1 I
C

I1 O1
I2 O2

I
C arcuri M1
Tunelare
n unele cazuri este necesar de a indica arcuri marginale, care sunt importante pentru nivelul
respectiv dar mai puin importante pentru diagrama paternal.
De exemplu - careva date se utilizeaz doar la acest nivel.
n aceste scopuri se aplic arcuri cu tunelare
Glosare i pagina FEO
Pentru fiecare element din diagrama IDEF0 trebuie s fie creat ontologia respectiv
noiuni, cuvinte cheie, denumiri funcii, denumiri operaii i altele ce caracterizeaz
obiectul (entitatea) reprezentat n diagram.
Aceast ontologie se numete glosariu, ce definete descrierea entitii reprezentate.
Diagrama - FEO (For Exposition Only) aceasta este o diagram ce descrie unele
aspecte speciale din diagrame.
Diagramele - FEO nu sunt limitate sintaxa notaiei IDEF0. Ele pot conine informaii n
format text, grafic, scheme, un alt punct de vedera asupra procesului dat i alte nsemnri,
aceste diagrame nu se utilizeaz pentru dezvoltarea modelului sunt numai pentru discuii.

Pagina MASTER (carcasa diagramei)

Este divizat n 3 cmpuri principale:
1) Cmpul informaiei de serviciu (pentru ghidarea duagramei n procesul de
modelare)
2) Cmpul mesajelor (cmpul unde se deseneaz diagrama)
3) Cmpul de identificare (identificarea diagramei i poziionarea ei n ierarhie)

Exemplul unui model.

1. Definirea contextului funcionrii obiectuljui ce va fi informatizat

n lucrarea noastr subiectul modelrii - este Compania i anume procesele ce se petrec n

interiorul Companiei. Scopul modelrii - construirea business-proceselor ce se vor petrece n
Companie (modelul TO-BY). Punctul de vedere -este viziunea directorului Companiei ca
persoan care cunoate n general toat structura Companiei.
Pentru a efectua modelarea funcional identificm contextul fucionrii Companiei. n acest
scop cercetm toate documentele ce reglementeaz actuvitate Companiei: Statutul Companiei,
Misiunea Companiei, Legislaia ce reglementeaz acest gen de activitate, Reulamentele interne
ale Companiei, Standardele pentru produsele Companiei, Nvormele interne, Fiele de post al
angajaiolr Companiei i alte documente ce reglamenteaz sactivitatea Companiei

Dac am definit contextul modelrii putem ncepe construirea diagramei de context

(cutia neagr). Unde se indic ce avem la intrare i ce avem la ieire fr a detalia
componentele sale (blocurile funcionale). Aceast diagram este constituit numai dintr-un
singur bloc care va reflecta ntreaga Companie (figura 2.1).

U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 03. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Modelare Bus ines Proces e R EV: 04. 02. 2016 D RAFT
R EC OMMEND ED
TOP
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION

reglamentri (control)

ntrri
iesiri
Ansamblare Calculatoare

0lei 0

mecanisme

N OD E: TITLE: N UMBER :
Ansamblare Calculatoare
A-0

Figura 2.1 - Diagrama de conrext a Companiei

ntrri aici se vor reflecta informaia sau materialele ce vor fi procesate de aceast lucrare
(bloc).
Ieire informaia sau materialele care sunt produse de aceast lucrare (bloc).
Reglementri (control) proceduri, reguli, strategii, standarde i norme de care se conduce
lucrarea (blocul).
Mecanisme resursele ce asigur executarea lucrrilor (angajaii, echipamente, baze de date i
altele.
Pentru Compania noastr vor fi:
Arcurile de intrare:
comenzile clienilor lista calculatoarelor i a notebook i completaia lor cerute
de clieni;
ansamble i subansamble de la furnizori;
informaii (propuneri comerciale) de la furnizori;
informaii despre cererea pieei.
Arcurile de ieire:
produsele finite calculatoarele i notebook-uri asamblate;
facturi pentru produsele ce vor fi livrate
 cereri pentru furnizori lista ansamblelor, subansamblelor i materialelor necesare
Companiei;
achitrile facturilor furnizorilor achitri pentru ansamble, subansamble i materiale
necesare Companiei;
materiale de marketing a produselor proprii - price-lista, publicitate.
Arcurile de control (reglementare):
cadrul legal diverse acte legislative ce reglementeaz activitatea Companiei;
reguli i proceduri - reguli i proceduri care reglementeaz procesele de producere
(reguli de asamblare, reguli de testare, norme de asamblare produse, standarde interne
a produselor asamblate, procedura relaiilor cu clienii, norme de protecie a muncii).
Arcurile mecanismelor:
resursele umane, (ingineri n IT, programatori, marketologi, economiti);
sistema de eviden contabil;
sistema de eviden a contratelor;
echipamente tehnice;
uniti de transport.

U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 03. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Modelare Bus ines Proces e R EV: 04. 02. 2016 D RAFT
R EC OMMEND ED
TOP
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION

carul legal
norme de asamblare
reguli de asamblare reguli de testare

procedura relatiilor cu clientii standade interne

Comenzile clientilor Cereri pentri furnizori

propuneri comerciale de la furnizori produse finite T

Ansamble si subansamble Ansamblare Calculatoare Achitriile facturilor furnizorilor

Informatii despre cererea pietii

0lei 0
Materiale de marketing
Resursele umane

Echipamente tehnice
evident contabil
T
T

unitti de transport
evident a contratelor

N OD E: TITLE: N UMBER :
Ansamblare Calculatoare
A-0

Figura 2.2- Diagrama de context rezultativ a Companiei

2. Decompoziia funcional de nivelul unu i doi n notaia IDEF0

Scopul: de a efectua decompoziia de nivelul unu n notaia IDEF0.
n sarcina precedent a fost determinat contextul funcionrii obiectului nostru i a fost
construit diagrama de context, constituit numai dintr-un bloc general care reflect activitatea
Companiei n general (la macro) fr devalizarea componentelor principale ale Companiei.
n acest capitol vom evidenia care sunt subdiviziunile principale ale Companiei ce asigur
funcionalitatea ei i vom construi efectua decompoziia de nivelul unu i doi prin costrucia
diagramelor de decompoziie n notaia IDEF0.
Decompoziia nseamn partajarea unui obiect complex n pri componente care
interacioneaz ntre ele.
 n acest scop identificm procedurile principale care asigur procesul de asamblare a
calculatoarelor i laptopuri.
Procesele principale ale companiei:
colaboratorii cerceteaza cerinele pieii n calculatoare i laptopuri;
vnztorii recepioneaz comenzi de la clieni;
colaboratorii selecteaz comenzile conform tipurile de calculatoare;
colaboratorii cerceteaz piaa furnizorilor de ansamble i subamsamble;
colaboratorii seciei de achiziii comand i procur ansamble i subansamble necesare
pentru asamblarea calculatoarelor;
colaboratorii planific producerea produselor pe termen scurt i pe termen lung;
colaboratorii efectueaz elaborare sinecostului i costul de livrare a produselor finite;
colaboratorii asambleaz i testeaz calculatoarele;
colaboratorii asigur deservirea pe garanii;
colaboratorii efectueaz evidena produselor finite la depozit, evidena vnzrilor,
evidena stocurilor de subansamble;
colaboratorii mpacheteaz produsele finite conform comenzilor primite de la clieni;
colaboratorii livreaz clientului comanda respectiv;
colaboratorii efectueaz evidena contabil i evidena muncii,
colaboratorii perfecteaz comanda, elibereaz conturi de plat, urmrete achitrile
conform conturilor.

Vom grupa aceste procese pentru a evidenia subdiviziunile principale ale Companiei
ce asigur funcionalitatea ei.
Management :
colaboratorii efectueaz evidena contabil i evidena muncii;
colaboratorii perfecteaz comanda, elibereaz conturi de plat, urmrete achitrile
conform conturilor;
colaboratorii efectueaz evidena produselor finite la depozit, evidena vnzrilor,
evidena stocurilor de subansamble;
colaboratorii efectueaz elaborarea sinecostului i costul de livrare a produselor finite;
colaboratorii planific producerea produselor pe termen scurt i pe termen lung.
Marketing i vnzri:
colaboratorii cerceteaza cerinele pieii n calculatoare i laptopuri;
colaboratorii cerceteaz piaa furnizorilor de ansamble i subamsamble;
vnztorii recepioneaz comenzi de la clieni.
Producer (Ansamblare i testare):
colaboratorii selecteaz comenzile conform tipurilor de calculatoare;
colaboratorii asambleaz i testeaz calculatoarele;
colaboratorii asigur deservirea pe garanii.
Achiziii i Livrri :
colaboratorii mpacheteaz produsele finite conform comenzilor primite de la clieni;
colaboratorii livreaz clientului comanda respectiv;
colaboratorii seciei de achiziii comand i procur ansamble i subansamble necesare
pentru asamblarea calculatoarelor.
n aa mod am evideniat 4 subdivizi principale ala Companiei ce asigur funcionalitatea ei i
n conformitate cu aceasta vom face prima decompoziie:
management;
marketing i vnzri;
producer (Ansamblare i testare);
achiziii i Livrri.
 Ca instrument de modelare vom utiliza aplicaia AllFusion ProcessModeller (V.7.9).
Pentru a efectua decompoziia lansm aplicaia i activm iconia Go to Child
Diagram i apoi butonm pe lucrarea care vrem s-i facem decompoziie. Se va afia o fereastr
Activity Box Count (figura. 2.3, figura 2.4) n care trebuie s alegem notaia modelului i
numrul de blocuri funcionale n care va fi efectuat decompoziia (numrul de diagrame
fiic).

Figura. 2.3 - Creare Decompoziie de nivelul unu

U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 05. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Modelare Bus ines Proces e R EV: 05. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A-0
C1 C2 C3 C4 C5 C6
U nnamed Arrow / 15 reguli de asamblare c arul legal reguli de t es tare norme de asamblare s tandade int erne

C om enzile c lient ilor U nnamed Arrow / 17

I1 0lei 1 O1

U nnamed Arrow / 18 C ereri pentri f urnizori

I2 O2
0lei 2

U nnamed Arrow / 19 U nnamed Arrow / 20

I3 O3

0lei 3

U nnamed Arrow / 21 Mat eriale de mark eting

I4 O4

0lei 4

U nnamed Arrow / 16 ev ident cont abil ev ident a contrat elor Ec hipament e t ehnic e unit ti de trans port

M1 M2 M3 M4 M5
N OD E: TITLE: N UMBER :
Ansamblare Calculatoare
A0

Figura 2.4 - Decompoziie de nivelul unu

n continuare atribuim denumiri pentru blocurile funcionale i conectm sgeile

marginale cu blocurile funcionale ( figura 2.5).
US ED AT: AUTHOR: Radu Basarabeanul DA TE: 05.02.2016 WORKING RE ADER DA TE CONTE XT:
PROJECT: Modelare Busines P rocese RE V: 05.02.2016 DRAFT
RE COMMENDED
NOTES : 1 2 3 4 5 6 7 8 9 10 PUBLICATION A-0
C1 C3 C2 C4 C5 C6
proceduri relatii cu clientii
carul legal

Comenzile clientilor reguli de testare norme de asamblare

I1
Mnagment cereri pentru furnizori
O1
0lei 1 reguli de asamblare standade interne

propuneri de la furnizori
I2 Marketing si Materiale de marketing
O4
informatii despre cerea pietii vnzri
I4
0lei 2

Ansamblare
ansamble si subansamble
I3 si testare
0lei 3
evident a contratelor

Achizitii produse finite

O2
si Livrri livrri
O3
0lei 4

evident contabil unitti de transport

Echipamente tehnice

resurse umane

M1 M2 M3 M4 M5
NODE: TITLE : NUMB ER:
Ansamblare Calculatoare

Figura 2.5 - Atribuim denumiri pentru blocuri i conectm sgeile marginale

n continuare interconectm blocurile funcionale pentru a asigura executarea proceselor

de producere i obinem diagrama final de nivelul unu ( figura 2.6).
U SED AT: AU TH OR: R adu Bas arabeanul D ATE: 24. 01. 2016 W OR KI NG R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 10. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A-0

r eguli r e lat ii cu clie ntii s tandar de r eguli de as am blar e

inte r ne r egulide te star e nor m e de as am blar e
Cadr ul Le gal
ce re i pe ntr u fur nizori
Infor m atii bancar e

ofer te f ur nizor i Em isie fact ur i

manage me ntul
com enzi de la clienti companie i
noi cer inte
achitri facturi
0 lei 1 plas ar e
m ate riale m ark e ting
com enzi
planuri
marke ting Inf. com e nz i plas ate
m ar ke ting piat
si vnzri
0 lei 2
inf.plas ar e produs e
com enzi finite
ans am ble/s ubansam ble ansamblare produs e s i
si te stare s er vicii
achizitii
0 lei 3
inf. pr odus e si livrare
as am blate s uplinir e
Achizitii e le m ente
s toc 0 lei 4 achzitionate
e le m ente produs e
finite

r es urs e um ane
contabilitat e
e vide nt e chipam ente te hnice unitti de
contracte tr ansport
N OD E: TITLE: N UMBER :
Asamblare PC, lptopuri si tablete
A0

Figura 2.6 - Blocuri Funcionale, diagrama decompoziie de nivelul unu

2.3 Decompoziie de nivelul doi n notaia IDEF0

Din diagrama de decompoziie de nivelul unu (figura 2.6) se vede c blocurile

funcionale Marketing i Vnzri i Asamblare i Testare au mai multe interconexiuni, asta
vorbete de faptul c n aceste blocuri se petrec mai mule procese, este necesar de a adnci
decompoziia la urmtor nivel - nivelul doi ( figura 2.7).

U SED AT: AU TH OR : R adu B as arabeanul D ATE : 24. 01. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05. 02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

s tandarde interne regili relat ii cu noi c erint e

c lient ii

planuri
M arke ting
ofer te f ur nizor i infor m atie pata
Piata e xtern e xte rn
0 lei 1

m ate riale m ark e ting

Analiza Pietii
0 lei 3

r ezultatul
analize i
m ar ke ting piat infor m atie
M arche ting piat a
Piata inte rn inte r n Elaborare
r ecom andri
com enzi de la clie nti 0 lei 2 Re comandri
0 lei 4

e vide nt
contabilitat e
contracte

N OD E: TITLE : N UMBER :
marketing si vnzri
A2

Figura 2.7 - Diagrama de decompozitie de nivelul doi Marketing i Vnzri

n procesul de analiz a proceselor ce se petrec la testarea pieii externe i interne sau

evideniat 4 blocuri funcionale vezi figura 2.8.

n acela mod efectum decompoziia pentru Blocul Funcional Asamblare i testare.

U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 05. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

regulide t est are reguli de asamblare s tandarde internenorme de asamblare

U nnamed Arrow / 32

rec om andri
0 lei 1
noi c erint e

produs e

0 lei 2

ans ambe/ subansamble

0 lei 3

s uplinire s t oc

0 lei 4

echipamente t ehnic e c ontabilitat e res urs e umane

N OD E: TITLE: N UMBER :
ansamblare si testare
A3

Figura 2.8 - Diagrama de decompozitie denivelul doi asamblare i testare

n procesul de analiz a proceselor ce se petrec la asamblarea produselor sau evideniat

4 blocuri funcionale vezi figura 2.9.
 U SED AT: AU TH OR : R adu Bas arabeanul D ATE: 05. 02. 2016 W OR KI N G R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 05. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A0

r eguli de s tandar de U nnamed Arrow / 32

as am blar e inte r ne

r egulide te star e
nor m e de
r ecom andri as am blar e
Asamblare
PC
0 lei 1

PC asam blate
ans am be /s ubans am ble
noi cer inte
Asamblare Te stare
laptopuri produse
0 lei 3
0 lei 2
produs e
finite
s uplinir e s toc
lapt opuri Elaborare conditii
as am blate
de garantie
0 lei 4
ce rt ificat
r ebut garantie

e chipam ente t ehnice contabilitat e r es urs e um ane

N OD E: TITLE: N UMBER :
ansamblare si testare
A3

Figura 2.9 - Diagrama de decompozitie de nivelul doi asamblare i testare

Modelarea proceselor. Standardul IDEF3

A good definition of a process describes it as a series of connected steps or actions to achieve
an outcome.
A process has the following characteristics:
a starting point and an end point. This is the scope
a purpose or aim for the outcome
rules governing the standard or quality of inputs throughout the process
it is usually linked to other processes.
it can be simple and short, or complex and long
Benefits of Process Modeling
- Document current processes for standardization.
- Provide guidelines for new process members to reduce the learning curve.
- Capture and analyze AS-IS processes.
Design / redesign process for TO-BE i scenarios.
Test the design of a new process before embarking on an expensive development project.
IDEF3 Overview
- Section 1: Basic Elements of the Process Diagram
- Section 2: Documenting the Process Flow
- Section 3: Enhancing the Process Description

Example Business Process Modelling Languages (Methods):

- Process Interchange Format (PIF)
- Process Specification Language (PSL)
- MIT Handbook of Organisational Processes
- IDEF0/ IDEF3
- UMLs Activity Diagram (state diagram)
- SAP R/3: EPC
- Petri Net
- Business Process Model, BSDM
- RAD, RACD
- Flow-Control, Data-Flow Diagram
Framework: Workflow Reference Model (WfMC)
Recently - SW version BPM: XPDL, OWL-S, BPML,
BPEL4WS, WSML.

Ce reflect modelul n IDEF3?

In general, un roces sunt aciuni consecutive ntr-o ordine respectiv.
Prin urmare, modelarea proceselor n IDEF3 permite:
Reflectarea consecutivitii proceselor
Evidenierea logicii interaciunilor elementelor sistemului.
Scopul IDEF3 de a le facilita munca Analitilor de a descrie situaia cnd procesele se
execut ntr-o ordine determinat precum i obiectele ce particip la aceste procese.

Elementele de baz la modelare dinamic n IDEF3

1) Uniti de lucru (UOW, Unit of Work);
2) Conexiuni;
3) Jonciuni (Intersecii);
4) Obiectele de referin.
Terminologies
Process schematics v.s. process models;
instantiation/activation of a process
Temporal constraints on processes:
Precedence links;
Dependency links;
Control links;
 Also sometimes referred as temporal ordering, or ordering between processes.

Activation of a process:
Process execution;
Process enactment.
Basic Junction Combinations & Temporal Constraints on Activations

Case 1: After the and-split junction is reached, an instance of B and C will be generated;
the and-join Junction is not through unless both instances of B and C finish their activations.
Case 2: After the or-split junction is reached, at least one instance of B or C is generated;
the or-join junction is not through unless at least one instance of B or C finishes its activations

Case 3: After the xor-split junction is reached, exactly one instance of B or C is generated; the
xor-join Junction is not through unless the generated instance of B or C finishes its activation.
Case 4: Although instances of B and C are generated after the activation of the and-split
junction. It is NOT necessary that both of those instances are completed before the activation
proceeds through the or-join-junction to the following process instance.

Other minor basic junction combinations

Junctions are special types of activities, with pre-determined semantics of process logic.
Such simple combinations allow the upheld of 1-to-many and many-to-1 modelling practice
for junctions; while allowing placing constraints on processes before and after them.
It is possible to short-hand these using a single junction, when it starts and finishes with the
same junction.

EXEMPLE MODELARE PROCESE IDEF3

Exemplul 1
Ci de execuie ale unui model de proces ntr-o main secvenial
Constngeri:
a exe(b, c, d), b exe(e, f), (e f) (c d) exe(g), (note that xor(e, f) and par(c, d) )
Given that: exe(List) List (a simplified operation)

Calcularea tuturor cilor de execuie:

a, par(b, c, d), xor(e, f), g (6x2 = 12 aths)
a, par(b, c), e, d, g 2 paths
a, par(b, c), f, d, g 2 paths
a, par(b, d), e, c, g 2 paths
a, par(b, d), f, c, g 2 paths
a, b, xor(e, f), par(c, d), g (2x2 =4 paths)
In total, there are 24 possible execution paths.

Exemplul 2
Costul de timp al proceselor ntr-o main paralel
Presupunnd c toate procesele sunt executate cu succes, astfel nct s nu existe o manipulare
excepional neateptat necesar pentru a face orice ntrziere;
i atunci cnd:
Nu exist timp de ateptare pentru a ncepe executarea unui proces de ndat ce sa atins n
modelul de proces. i cnd costul de timp al unui proces poate fi calculat precum este artat
mai jos:
- Procese paralele ale lui p1, pn: max (p1, ..pn).
- Procese secveniale ale lui p1, pn: sum (p1, ..pn).
- alegerea proceselor ntre p1, pn:
- min (p1, ..pn) - cel mai bun caz;
- max (p1, ..pn) - caz mai ru.
Studiu de caz: utilizai exemple de modele pentru a calcula costul de timp posibil.

Costul maxim i cel minim al unui model de proces

Care este costul maxim al timpului? Care este ruta de execuie?

Time cost: 3 + 18 + 12 = 33
Execution route: a, (b, c, d), e, g
Max(be, c, d) = 5+13 = 18
Care este costul minim al timpului? Care este ruta de execuie?
Time cost: 3 + 9 + 12 = 24
Execution route: a, (b, c, d), f, g
Max(bf, c, d) = 9

Exemplul 3
n acest exeplu o s modelm procesele Companiei de asamblare lptop-uri i PC-uri pentru
care am efectuat modelarea funcional n standardul IDEF0.

O s efectum studiul proceselor Asamblare i testare, blocul functional 3 (vezi

diagramele IDEF0).
Executatrea acestei lucrri se ncepe odat cu procesul plasare comenzi la asamblare.
Prima aciune se ncepe cu:
- verificarea dac sunt destule asamble i subansamble i
- se comand asamble i subansamble de la depozit (elementele ce lipsesc).
n continuare se pregtesc asamblele i subansamblele pentru asamblare (scoatere din cutii,
dcuparea capace de le fiele de inrare i ieire...). n continuare se ncepe procesul de
asamblare:
- Instalare plcii de baz n carcas i instalarea procesorului pe placa de baz,
Instalate (RAM) memorie opoerativ, Instalare Hard-Disk.
Aceste aciuni se efectueaz pentru fiecare PC i nu depind de configutaia calculatorului. n
continuare n dependen de comanda clientului pot fi instalate:
- DVD, TV- tuner, Card-ryder.
Cu aceasta se termin asamblarea calculatotului. La urmtoarea operaie:
- se instaleaz Sistemul de Operare,
- la solicitarea clientului pot fi instalate i alte aplicaii soft.
Ultima aciune la aceast etap este perfectarea raporturi Raport PC asamblate i Raport
rezultate asamblare.
Crearea diagramei de decompoziie n notaia IDEF3.
Pentru aceasta nserm pe diagrama A3 lucrarea Asamblare i testare butonm iconia
"Go to Child Diagram" selectm notaia IDEF3.
U SED AT: AU TH OR: R adu Bas arabeanul D ATE: 09. 02. 2016 W OR KI NG R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 09. 02. 2016 D RAFT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A3

0 lei

0 lei

0 lei

0 lei

N OD E: TITLE: N UMBER :
Asamblare PC
A31.1

Fig 3.3. Diagrama iniial n notaia IDEF3 nivelul unu.

n Diagrama de decompoziie fiic oricnd pot fi adugate noi lucrri, din aceast cauz
cnd alegem numrul lucrrilor putem indica un numr de lucrri arbitrar. La crearea
diagramei fiic aplicaia BPWin nu transfer sgeile marginale din diagrama matern, ele
trebuie nlocuite cu blocuri obiecte de referin:
plasare comenzi, asamble i subansamble, comanda asamble i subansamble
Raport PC asamblate i Raport rezultate asamblare.
pentru asta activm iconia R (Referent) de pe bara de instrumente i n ferestruica de
dialog indicm Arrow i alegem din lista denumirilor de sgei conexiunea necesar.

Fig 3.4. n ferestruica de dialog Referent.

n continuare construim lucrrile i conexiunile ntre lucrri n ordinea desfurrii proceselor

de asamblare i obinem diagrama final (imaginea 3.5)

U SED AT: AU TH OR: R adu Bas arabeanul D ATE : 09. 02. 2016 W OR KI NG R EAD ER D ATE C ON TEXT:
PR OJEC T: Proiec t are SI R EV: 10. 02. 2016 D RA FT
R EC OMMEND ED
N OTES: 1 2 3 4 5 6 7 8 9 10 PU BLIC ATION A3

plas ar e r eguli de
com enzi 0 lei as am blar e nor m e de
com anda as am blar e com ponente ce lipse s c
ans am be /s ubans am ble
la depozit
0 lei 2
Ve r ificar e
Ans am ble/ 0 lei 0 lei 0 lei
s ubans am ble X 0 lei
Ins talar e plc Ins talate
pre gtir e Ins talar e
1 asam blele / de baz (RAM ) Hard-Dis k
J1 subans am ble le s i proce sor
7 10
com ponente ne ce sar e 3 9

Rapor t PC
As am blate
0 lei 0 lei
Ins talar e Ins talar e
DVD Aplicatii
4 14 0 lei
0 lei Per fe ctar e
0 lei
O ins talar e Ins talar e
X X r apor t
TV- tune r O SO 15

J2
11 13
J8 J9
0 lei
J10 Rapor t
ins talar e as am blar e
Car d-ryde r nor m e de
12 r eguli de as am blar e
as am blar e

N OD E: TITLE : N UMBER :
Asamblare PC
A3.1.1

Fig 3.5. Diagrama de decompoziie IDEF3 nivelul unu.

S vedem care sunt particularitile principale a acestei diagrame.
Dup ce efectum lucrarea verific prezena Asabmbe/subansamble sunt posibile dou
aciuni - ori comandm la depozt elementele ce lupsesc ori, dac sunt toate elementele
necesare se execut lucrarea pregtire Ansamble/Subansabmle- din aceast cauz noi am
inclus jonciunea Sincron Sau (Synchronous OR). Lucrrile pregtire
Ansamble/Subansabmle i instalare placa de baz i procesor se interconecteaz cu
sgeata Fluxuri de obiecte . Asta indic c ntre lucrri se transmit obiecte.
Lucrrile ulterioare se interconecteaz cu sgeata conexiune predcesoar
(Precedence) deoarece ele arat conscutivitatea aciunilor asupra acelorai obiecte. Dup
instalarea Hard-Discului este posibil instalarea DVD, -tuner, Card-reader sau alte
componente. Pentru aceasta am utilizat jonciunea asincron sau (Asynchronous
OR). Aceiai jonciune construim i dup terminarea lucrrii. n continuare dup ce instalm
SO (Sistemul Operaional), la cererea clientului, pot fi instalate i alte Aplicaii soft, sau dac
nu, se perfecteaz Rapoartele. Pentru aceasta noi am utilizat jonciunea Exclusiv (exclude
sau) XOR (Exclusive OR), dup cum tim, dup jonciunea poate fi numai jonciunea
, din aceast cauz naintea lucrrii Perfectare Raport am utilizat aceiai jonciune.

Rezumat
Sunt preferate legturile (conexiunile)
-One-many and many-one relationships only
Diferena dintre jonciunile split (fan-out) i join (fan-in):
- Atunci cnd se ajunge la o jonciune divizat, aceasta plaseaz controlul logic a procesului la
procesele ce urmeaz acestuia - aceasta este o relaie 1-la-multe;
- Cnd se ajunge la o jonciune de asociere, se asigur c procesele nainte de a se ntlni cu
constrngerile de jonciune nainte de a trece la urmtorul nod - aceasta este o relaie multi-la-
unu.
Combinaii de jonciuni ilegale:
- De exemplu. combinrile i/xor i xor /i , oricare altele?
Sincronizri i tipuri de jonciuni.
IDEF3 ofer multe relaii fundamentale ntre dou procese.

Modelarea obiect orientat

Standardul DEF4
Dezvoltarea programrii orientate pe obiecte a facilitat n mod semnificativ procesul de
dezvoltare a produselor software. Cu toate acestea, dezvoltarea produselor software cu un
design bun, fiabilitate, modularitate i avnd un grad de utilizare nalt, este nc problematic.
Standardul IDEF4 a fost dezvoltat pentru utilizarea corect a tehnologiilor obiect-orientate.
Conform standardului IDEF4 , procesul orientat pe obiecte este reprezentat cu ajutorul unor
diagrame, care ne ajut s analizm acest proces i s descoperim punctele cheie.

Particularitate a standardului IDEF4 este posibilitatea de reprezentare a influenei ereditii

claselor , compoziiei obiectelor, descompunerii funcionale i polimorfismul pe proiectarea
obiectelor.
Procesul proiectrii obiect-orientate prin metoda IDEF4 este mprit n blocuri separate.
Fiecare subrulare are notaii, care indic ce decizie ar trebui s fie acceptat n timpul
procesului de proiectare i cum va influena alte subrulri.
Diagrama comun, care descrie ntregul proiect, nu este dezvoltat de standardul IDEF4.
Acest lucru ne permite evitarea confuziile i gsirea rapid a informaiiei necesare cu privire
la proiect.
Standardul IDEF4 permite planificatorului, gsirea uoar a compromisurilor ntre ereditatea
claselor, compoziia claselor, descompunerea funcional i polimorfismul n proiect.

Modelul IDEF4 este format din 2 submodele: modelul claseselor i modelul metodelor.
Aceste submodele sunt conectate ntre ele cu ajutorul unei scheme de distribuie i conin
toat informaia cu privire la proiect. Din motivul mrimii subrulrii claselor i metodelor,
planificatorul niciodat nu le folosete ca un ntreg, dare folosete un set de diagrame mai
simple i caietul de sarcini care conine o parte din informaii.

Fig. 5.

Un submodel de clase este format din urmtoarele tipuri de diagrame:

Diagrame de ereditate, ce definesc ereditatea claselor.
Diagrame de tipuri, ce definesc compoziia claselor.
Diagrame de protocoale care definesc protocoale a metodelor de apel.
Diagramele de creare a obiectelor (Instanierea), care descriu procesul de creare a
exemplarelor de presetare a obiectelor de clase.
Un submodel de metode este format din urmtoarele diagrame:
Diagrame a metodelor de sistematizare (Metoda taxonomiei), care clasific metodele
dup similitudinea comportamentului.
Diagrame de clieni, care reprezint clieni i operaiunile de furnizori, astfel nct s
se defineasc decopoziia funcional.

Diagrama de ereditate
Diagrama de ereditate reprezint legturile ereditare ntre clase. De exemplu, n imaginea de
mai jos este reprezentat structura de ereditate i comportamentul clasei Filled-Rectangle.
 Fig. 5.
Diagramele de protocoale.
Diagramele de protocoale definesc argumente de clase pentru protocoale de apel.
n imaginea de alturi este artat diagrama de protocol pentru Fill-closed-object.
Este evident din diagram c Fill-closed-object primete cereri de la obiectul Polygon
(argumentul primar) i Color object (argumentul secundar) i returneaz cererea spre
obiectul Polygon.

Fig.5.
Diagramele de creare a obiectelor
Diagramele de creare a obiectelor vine n diagrama de tipuri i descrie situaiile posibile la
compoziia legturilor dintre crearea obiectelor.

Fig. 5.
Diagrama de sistematizare a metodelor
Diagrama de sistematizare a metodelor descrie anumit tip de comportament al sistemului la
influena pe set de metode. Sgeile de pe diagram sunt ndreptate spre influenele
suplimentare , realizate la seturi de metode. Seturile de metode sunt grupate n mod
corespunztor pentru condiii suplimentare obligatorii.
n exemplul dat, un set de metode Print are o condiie obligatorie ca obiecul trebuie s fie
tiprit i setul de metode Print-Text c obiectul tiprit trebuie s fie text.

Fig.5.

Diagramele de clieni.
Diagramele de clieni reprezint clienii i operaiunile de furnizori. Sgeile duble pe
diagram sunt ndreptate de la operaia chemat spre operaia ce cheam.
n exemplul dat este prezentat o diagram de clieni. Pe aceast diagram operaia
Redisplay care aparine clasei Redisplayable-object solicit operaia clasei Erasable-
object i operaia Draw a clasei Drawable-object class

Fig.5.
Standardul IDEF4 presupune nu doar prezentarea grafic, dar i informaii suplimentare
despre diagrame de ereditate, metode de sistematizare i de tipuri care sunt cuprinse n caietul
de sarcini. Conform standardului IDEF4 exist caietul de sarcini a claselor invariante i
specificaiile condiiilor obligatorii.
Specificaiile claselor invariante sunt conectate cu diagrame de ereditate i definesc
influenele care formeaz proprieti ale fiecrei clase de obiecte. Pentru fiecare clas exist o
specificaie separat. De exemplu, proprietile Each square has four sides i All square
sides are equal sunt proprietile specificaiei clasei Square.
Specificaiile condiii obligatorii sunt conectate cu seturi de metode n schemele metodelor de
sistematizare i definesc condiiile obligatorii, care influeneaz asupra metodelor i ce
metode ar trebui satisfcute. Pentru fiecare set de metode exist o specificare a condiiilor
obligatorii. De exemplu, setul de metode "Pop", care terge valorile din stiv, ca o condiie
obligatorie va avea absena unor ncercri de a terge valoarea din stiv n cazul n care stiva
este goal.
Standardul IDEF 4 este dezvoltat de ctre proiectani profesioniti i programatori de la
Laboratorul Air Force Armstrong SUA i are scopul de a facilita utilizarea tehnologiilor
obiect-orientate la dezvoltarea de software.

Modelarea logic a Fluxurilor de Date n conotaia DFD

Flux de date?
Flux de Date - totalitatea informaiilor transmise, ntr-un interval de timp determinat,
de la o surs de informaie la un receptor, printr-o mulime de canale informaionale
mai multe: fluxuri informationale intr-un sistem
Conexiuni ce se stabilesc intre diferitele componente ale fluxurilor:
Pe Orizontal
Pe Vertical

Fig. 5. Conexiuni ce se stabilesc intre diferitele componente ale fluxurilor.

Indiferent de metodologiile folosite n realizarea unui sistem/aplicaie, toate apeleaz la

operaiunea de modelare logic a datelor i prelucrrilor sub form de diagrame, diferenele
constnd doar n folosirea mai pronunat a diagramelor pentru descrierea sistemului,
ncadrndu-le n diagrame de context, diagrame ale fluxurilor de date fizice i diagrame ale
fluxului de date logice. Altele apeleaz la combinaii de diagrame, tabele i forme descriptive.
Diagrama de context scoate n eviden aria de ntindere a sistemului analizat, prin
specificarea elementelor din interiorul organizaiei i a celor externe, sub denumirea de
entiti externe sistemului analizat.
Diagramele fluxurilor de date (DFD)
Diagrama fluxului de date ale nivelului logic curent, independent de tehnologie,
reliefeaz funciile de prelucrare a datelor executate de ctre sistemul informaional
curent.
Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,
structura lor i cerinele funcionale ale noului sistem.
Descrieri ale obiectelor DFD se regsesc n aa-zisele dicionare ale proiectelor sau
depozitele CASE (repository).
Diagramele fluxului de date DFD au ca obiectiv urmrirea modului de transfer al
datelor ntre procesele de prelucrare a lor, astfel de diagrame se mai numesc i
modele ale proceselor de prelucrare, iar operaiunea se numete modelarea proceselor.
DFD reprezint doar una din tehnicile de analiz structurat. Tehnica de redare a
proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a cptat noi
accepiuni prin ncorporarea ei n instrumentele de analiz i proiectare cu ajutorul
calculatorului, adic n instrumente CASE.
DFD Data Flow Diagrams Diagrama Fluxurilor de Date
Modelul DFD al Sistemului este prezentat ca o ierarhie a diagramelor a fluxurilor de
date, ce descriu procesele asincron de transformare a datelor de la intrare n sistem,
procesarea lor i livrare utilizatorului.
Scopul principal al acestei reprezentri l constitue de a identifica cum fiecare
proces transform datele de intrare n date de ieire i de a stabili relaiile dintre aceste
procese.
Remarc. Modelele DFD- n multe cazuri se utilizeaz ca complementare a modelelor
IDEF0 i IDEF3 pentru a relata circulaia documentelor n sistemele informaionale
corporative

Simboluri i notaii folosite n DFD

Dou sisteme comune de simboluri sunt denumite dup numele autorilor ce leau creat:
Yourdon and Coad
Yourdon and DeMarco
Gane and Sarson
O diferen major n simbolurile lor este faptul c Yourdon-Coad i Yourdon-DeMarco
folosesc cercuri pentru procese, n timp ce Gane i Sarson folosesc dreptunghiuri cu coluri
rotunjite, uneori numite comprimate (tablet). Exist i alte variaii ale simbolurilor, astfel
nct lucrurile importante pe care trebuie s le pstrai n minte trebuie s fie clare i coerente
n formele i notaiile pe care le utilizai pentru a comunica i a colabora cu alii.
Folosind regulile sau liniile directoare ale conveniei DFD, simbolurile descriu (reprezint)
cele patru componente ale diagramelor fluxului de date.
 DFD reguli i sugestii
Orice proces trebuie s posede cel puin o intrare i ieire.
Orice depozit de date trebuie posede cel puin .
Datele pstrate n sistem trbuie s treac prin procese.
Toate procesele in DFD intractionez cu un alt proces sau depozit de date.
 Proces
A. Nici un proces poate avea doar ieiri (un miracol)?
B. Nici un proces poate avea doar intrri (gaur neagr)?
C. Un proces are o etichet (verb, fraza)
Depozit de date
D. Datele nu pot fi mutate de la un Depozit la altul.
E. Datele nu se pot deplasa dintr-o surs extern la un Depozit de date
F. Datele nu se pot deplasa n mod direct de la un Depozit de date la o surs de date
G. depozit de date are o etichet ( substantiv)
Sursa
H. Datele nu se pot deplasa n mod direct de la o surs
I. O surs are o etichet substantive
Flux de date
J. Un flux de date are o singur direcie de traversare a datelor(flux) ntre simboluri.
K. Structura Fork ne arat c exact aceleai date provin dintr-o locaie comun i sunt
recepionate de dou sau mai multe procese, depozite de date sau surse
L. Structura Join ne arat c exact aceleai date provin de la oricare dou (sau mai
multe): procese, depozite de date sau surse acestea fiind diferite sosind ntr-o locaie
comun
M. Un flux de date nu poate merge direct napoi la acelai proces de la care a provenit
N. Un flux de date ntr-un depozit de date nseamn actualizare
O. Un flux de date dintr-un depozit de date nseamn a prelua sau de a folosi
P. Un flux de date are ca o etichet un substantiv.

Balansarea DFD-urilor.
Cnd discompunem o DFD trebuie s conservm intrrile i ieirile a procesului la nuvelul
urmtor de decompoziie. Aceasta se numete balansare. Noi putem mpri fluxul de date n
fluxuri de date mai mici separate tre ele n componena diagramei de nivel mai jos.
Patru Reguli Adiionale Avansate de Balansare a DFD-urilor
Q. Un flux de date compus un la nivel superior poate fi mprit n subfluxuri la nivelul
urmtor, dar nu pot fi adugate date noi i toate datele din fluxul cumpus trebuie s fie
lulate nconsideraie de unul sau mai multe subfluxuri.
R. Datele de intrare pentru un proces trebuie s fie suficient pentru a produce ieirile
(inclusiv i pentru datele deintrare) din proces. Astfel, toate ieirile pot fi produse, precum i
toate datele din intrri se pot muta undeva, fie la un alt proces sau la un depozit de date n
afara procesului pe o DFD mai detaliat, care indic o descompunere a acestui proces.
S. La cel mai sczut nivel al DFDS, noi fluxuri de date pot fi adugate pentru a reprezenta
datele care sunt transmise n condiii excepionale; aceste fluxuri de date de obicei reprezint
mesaje de eroare sau notificrile de confirmare.
T. Pentru a evita liniile fluxului de date ce se intersecteaz, putei repeta deposit de date
sau surs de date pe DFD

Reguli de desenare a DFD-urilor

 Nivele i straturi DFD
De la Diagrama de Context la pseudocod
O diagram a fluxului de date poate fi detalizat prin utilizarea nivelelor i straturilor.
Nivelele DFD sunt numerotate de la 0, 1 sau 2, i, ocazional, chiar nivelul 3 sau mui mult .
Nivelul necesar de detalizare depinde de domeniul de aplicare a ceea ce se ncearc s se
realizeze.
DFD de Nivelul 0 se mai numeste i diagram de Context . Acesta aste o shi a
ntregului sistem n ansamblu ce aste analizat sau modelat.Aceata ne prezint sistemul ca un
proces de nivel nalt cu relaii cu entiti externe. Ea e uor de lmurit la un public larg
precum: analiti de afaceri, analitii de date i dezvoltatori.
DFD de Nivelul 1 ofer o descompunere mai detaliat a parilor componente a diagramei
de context. Sunt atenionate principalele functii efectuate de sistemul n studiu mprind
procesul de nivel nalt a diagramei de context n subprocese.
DFD de nvelul 2, apoi merge cu un pas mai jos analiznd prile ale nivelului 1.Va fi
necesar demai mult text pentru a ajunge la nivelul necesar de detaliu cu privire la funcionarea
sistemului.
Progresnd la nivele 3, 4 i mai departe posibil, darutilizarea a mai mult de 3 nivele e mai
puin frecvent. Acest lucru poate crea o complexitate pe care o face dificil de a comunica,
compara sau modela eficient.
Cu ajutorul straturilor DFD, nivelele n cascad pot fi imbricate direct n diagram,
oferind un aspect mai curat, cu acces uor la nivele inferiore.
Cunoscnd bine DFD, dezvoltatorii i designerii l pot folosi pentru a scrie pseudocod,
care e o combinaie de limba englez i limbaje de programare. Pseudocodul faciliteaz
dezvoltarea codului real
Numerotarea nivelelor
nrtr-o diiagram DFD cu multe nivele e uor de uitat la ce nivel ne aflam ntrun
moment de timp .Deaceea fiecare nivel are o numerotare diferit pentu procesele din
diagram.Nivelul corespunde numrului de cifre zecimale penru a defini un proces
in acesta De exemplu:
Context Diagram Process labeled 0
Level 0 Processes labeled 1.0, 2.0, 3.0, .
Level 1 Processes labeled 1.1, 1.2, 1.3, .
Level 2 Processes labeled 1.11, 1.12,...
 Modelarea datelor. Standardul: IDEF1x
Aplicabilitatea IDEF1x
IDEF1x Este o tehnic de modelare a informaiei i este utilizat pentru a modela datele
ntr-un mod standard, consecvent, previzibil, n scopul de a gestiona resursa.
Utilizrea acestui standard este puternic recomandat pentru toate proiectele care necesit
un mijloc standard pentru definirea i analiza resurselor informaionale n cadrul unei
Companii.
Astfel de proiecte includ:
a. Incorporarea unei tehnici de modelare a datelor ntr-o metodologie;
b. Utilizarea tehnicii de modelare a datelor pentru managementul resursei informaionale;
c. Utilizarea tehnicii de modelare a datelor pentru integrarea sistemelor informaionale;
d. Utilizarea tehnicii de modelare a datelor pentru proiectarea bazelor de date.

Noiuni de baz
Diagramele (ERD) entitate relatii sunt cele mai raspindite instrument de modelare a
datelor. Cu ajutorul ERD sunt detalizate depozitele de date n diagramele DFD.
Sunt documentate aspectele informaionale ale sistemului, inclusiv:
Identificarea obiectelor importante pentru domeniul obiectiv - entitile ;
Identificarea proprietilor acestor obiecte - atribute i
Identificarea legturile cu alte obiecte - relaii.
Entitatea (Entity) este mulimea obiectelor reale sau abstracte, care posed aceleai atribute
sau caracteristici. Un obiect al sistemului poate fi reprezentat numai printr-o singur
entitate, identificat n mod unic. Numele entitii nu va fi legat de un exemplar (instan)
concret al obiectului. Fiecare entitate va poseda un identificator unic. Fiecare exemplar al
entitii va fi identificat n mod univoc. Fiecare entitate va poseda anumite proprieti:
nume unic;
unul sau cteva atribute;
O entitate poate avea un numr arbitrar de relaii cu alte entiti ale modelului.

Relaie i atribut
Relaia (Relationship) este o asociere (creia i-a fost atribuit un nume) ntre dou entiti,
relevant pentru domeniul obiectiv considerat.
Relaia este asocierea ntre entiti n care fiecare instan (exemplar) a unei entiti este
asociat cu un numr arbitrar (inclusiv zero) de instane (exemplare) ale celeilalte entiti, i
invers.
Atributul- este caracteristica entitii, relevant pentru domeniul obiectiv i utilizat la:
calificarea, identificarea, clasificarea i caracterizarea cantitativ sau exprimarea strii
entitii.
Atributul reprezint tipul de caracteristici sau proprieti, asociate cu o mulime de obiecte
reale sau abstracte (persoane, locuri, evenimente, stri, idei, obiecte etc.).
Modelarea datelor este un proces analitic impus nu numai de nevoia de extragerea
caracteristicilor obiectelor date ci deseori i de necesitatea de a genera date noi din datele
iniiale.
Extragerea caracteristicilor are ca finalitate estimarea vizual a informaiei cuprins n
structuri complexe de date. Generarea datelor noi are la baz modelarea matematic a
problemei pentru care au fost culese datele experimentale i are ca finalitate estimarea vizual
a informaiei, achiziia de noi cunotine.
 Un model de date reprezint o colecie integrat de concepte necesare descrierii datelor,
relaiilor dintre ele, precum i a constrngerilor asupra datelor (Connolly .a. 1998). Modelul
de date este utilizat la descrierea schemei bazei de date, definind structura datelor, legturile
dintre acestea, semantica lor, precum i constrngerile impuse, dei nu este obligatoriu ca
ntotdeauna acestea s fie regsite n orice model de date. Pe scurt, un model de date este
utilizat pentru a reprezenta date despre date.
Modelele de date ofer nelegerea descriptiv necesar definirii schemelor logice i
externe i sunt utile descrierii formale a schemei bazei de date.
Schema logic a unei baze de date reprezint o descriere abstract a unei poriuni din
realitatea modelat mpreun cu instanele bazei de date.

Destinaie IDEF1X
IDEF1X este o metodologie pentru eleborare Baze de Date Relaionale.
Pentru aceasta IDEF1X utilizeaz o sintax convenional elaborat special n acest scop
pentru a putea construi scheme conceptuale.
Schem conceptual o s numim Reprezentare general a datelor (informaiei) n cadrul
Companiei, care este independent de realizarea final i de platforma pe care va fi realizat
aceast Baz de Date.
Utilizarea metodologiei IDEF1X este raional pentru a construi structura logic a Bazei de
Date atunci, cnd sunt studiate toate resursele informaionale i decizia de a construi o Baz
de Date Relaional ca parte componemnt a Sistemului Informaional Corporatv a fost deja
adoptat.
Totoodat trebui de menionat c instrumentele de modelare IDEF1X a fost elaborast special
pentru a construi Sisteme Informaionale Relaionale i n caz ca este necesitatea de a construi
un alt S. I., de exemplu un sistem Obiect Orientat atunci ar fi mai bine s alegem o alt
metodologie de modelare.
Sunt cel puin dou motive pentru a nu utiliza IDEF1X n cazul cnd nu se construesc Sisteme
Informaionale relaionale.
n primul rnd, IDEF1X cere de la proiectani s determine atributele cheie, asta pentru a
putea diferenia entitile una de alta, pe cnd sistema Obiect Orientat nu cere determinarea
atributelor cheie pentru a putea identifica obiectele.
n al doilea rnd, n caz c exist mai multe atribute ce identific univoc entitatea, proiectantul
trebuie s desemneze unul din aceste atribute ca cheie primar, iar celelalte ca chei
secundare.
Bazele metodologiei IDEF1X
IDEF1X - este o abordare semantic la modelarea datelor,
IDEF1X este bazat pe conceptul Entitate Relaii; un instrument ce se utilizeaz la
analiza structurii informaionale a obiectelor.
Modelul informaional, construit n conotaia IDEF1X reprezint structura logic a
informaiei despre obiectele din componena sistemului. Poate fi interpretat ca structura
logic a Bazei de Date Modelul informaional este o suplinire a modelului funcional
(IDEF0), acest model detaliaz obiectele, care sunt manipulate de funciile sistemei.

Componentele principale ale standardului IDEF1x

Componentele principale ale acestui standard sunt: Entitate <-> Relaii <-> Atribute
1) oamenii, obiectele, fenomenele despre care se colecteaz i stocheaz informaia (n
continuare Entitate)
2) Interconexiunile ntre aceste entiti ((n continuare Relaii)
3) Caracreristicile ce descriu aceste elemente ((n continuare Atribute)
- Entitate mulimea obiectelor reale (oameni, obiecte, fenomene), ce au caracteristici i
atribute comune. Un obiect al sistemului poate fi reprezentat doar de o singur entitate, ce
trebuie s fie identificat n mod unic.
Exemplu, Entitatea Studeni. Un exemplar al aceste entiti Vasile BASARABEANUL.
Relaii interconexiunile ntre dou sau mai multe entiti. Denumirea relaiilor este
formulat in mod determinant.
Atribute caracteristica entitii.
Exemplu, Entitatea Student are ca atribut Numele i Prenumele.
Rezume - Entitatea - reprezint tipul informaie de baz ce se stocheaz i pstreaz n
Baza de Date, dar relaiile indic cum aceste date sunt interconectate ntre ele.

Reguli de baz a ENTITILOR

1. Entitate trebuie s aib o denumire unical i s fie substantiv la singular. Exemplu :
student, angajat, contract, carnet de note, buletin de identitate,
2. Entitate - poate avea unul sau mai multe atribute, care i aparin sau sunt motenite
prin relaii.
3. Entitate - poate avea unul sau mai multe atribute care identific univoc fiecare
exemplar al entitii i se numesc cheie.
4. Entitate - poate avea unul sau mai multe relaii cu alte entiti.
5. n caz c cheia extern este integral utilizat n cheia primar a Entitii atunci se
spune c Entitatea este dependent de identificator.
6. n notaia IDEF1X Entitatea este reprezentat n form de dreptunghi,

Reguli de baz pentru Atribut

Atributul unei Entiti are un nume unic.
O Entitate poate avea mai multe atribute.
Atributele sunt : proprii sau motenite.
Atributele proprii sunt unicale n cadeul acestui model
Atributele motenite se transmit de la Entitatea paternal odat cu determinarea conexiunii
de identificare.
Relaia (Relationship)
Relaia (Relationship) este o asociere (creia i-a fost atribuit un nume) ntre dou entiti,
relevant pentru domeniul obiectiv considerat.
Relaia este definit suplimentar prin cardinalul relaiei (numrul tuplurilor coninute n
relaia dat) sau numrul de instane ale entitii-descendent, care pot fi create de fiecare
instan a entitii-printe.
Relaii unitare
relaii one-to-one acest tip de relaie este destul de rar ntlnit.
Uneori astfel de relaii pot fi modelate transformnd una dintre entiti n atribut al celeilalte
entiti.

Relaii one-to-many sunt cele mai ntlnite tipuri de relaii, ns i aici cazurile c i d
prezentate n figur sunt mai puin uzuale.
S facem cteva observaii pe marginea exemplelor:
Cazul a este foarte des ntlnit.
La cazul b, am ales o relaie opional dinspre POEZIE spre POET deoarece poate fi
vorba de o poezie popular i n acest caz nu exist un poet cunoscut.
La cazul c, am considerat c o formaie nu poate exista fr a avea cel puin un
membru, ns un artist poate avea o carier solo, deci nu face parte din nici o formaie.
Varianta d modeleaz o colecie de filme memorate pe CD-uri. Pentru afacerea considerat,
un CD conine obligatoriu un film, dar unul singur, ns un film poate s nu ncap pe un
singur CD de aceea el poate fi memorat pe unul sau mai multe CD-uri.
Relaii many-to-many aceste tipuri de relaii apar n prima faz a
proiectrii bazei de date, ns ele trebuie s fie ulterior eliminate.
Figura de mai jos prezint cteva exemple de relaii many-to-many.
La punctul b am considerat c un curs poate aprea pe oferta de cursuri a unei
faculti, ns poate s nu fie aleas de nici un student de aceea un curs poate fi urmat
de unul sau mai muli studeni.
Invers, este posibil ca un student s fi terminat studiile i s se pregteasc pentru
susinerea examenului de licen i de aceea el nu mai frecventeaz nici un curs.
La punctul c, un profesor angajat al unei coli trebuie s predea cel puin o disciplin.
Iar o disciplin din planul de nvmnt trebuie s fie predat de cel puin un profesor.
Nontransferabilitatea relaiilor
Spunem c o relaie este nontransferabil dac o asociaie ntre dou instane ale celor dou
entiti, odat stabilit, nu mai poate fi modificat. Nontransferabilitatea unei relaii se reduce
la faptul c valorile cheii strine corespunztoare relaiei respective nu pot fi modificate.
Condiia de nontransferabilitate a unei relaii este asigurat prin program. De aceea trebuie s
documentm aceast restricie. n ERD o relaie nontransferabil se noteaz cu un romb pe
linia corespunztoare relaiei, nspre entitatea a crei cheie strin nu este permis s o
modificm (adic n partea cu many a unei relaii one-to-many).
n figura de mai jos este dat un exemplu de relaie nontransferabil. Este vorba despre notele
date elevilor. Este normal ca o not dat unui elev s nu poat fi apoi transferat unui alt elev.

Relaii binare
Relaii triple

Simbolica interconexiunilor
Cazuri posibile
Fiecrei entiti i se atrbuie un nume i un numr unic, separate prin "/" i plasate de asupra
blocului.
Relaia este definit suplimentar prin cardinalul relaiei (numrul tuplurilor coninute n
relaia dat) sau numrul de instane ale entitii-descendent, care pot fi create de fiecare
instan a entitii-printe.
n IDEF1X pot fi urmtoarele cazuri:
fiecare instan a entitii-printe poate fi legat de zero, unul sau mai multe instane ale
entitii-descendent;
fiecare instan a entitii-printe trebuie s fie legat de cel puin o instan a entitii-
descendent;
fiecare instan a entitii-printe trebuie s fie legat de cel mult o instan a entitii-
descendent;
fiecare instan a entitii-printe este legat de un numr fix de instane ale entitii-
descendent.
Legtur identificatoare
n cazul n care o instan de entitate-descendent este determinat n mod univoc prin
legtura sa cu entitatea-printe, relaia este numit identificatoare (Authenticator), n caz
contrar - neidentificatoare.
Legtura (relaia) este notat printr-o linie cu un punct bine pronunat la sfritul liniei la
entitatea-descendent.
Cardinalul relaiei poate lua valorile: N zero, unu sau mai multe, Z zero sau unu, P unu
sau mai multe.
Valoarea implicit este N.
Exemplu Relaie identificatoare

Fig. 5. Relaie identificatoare

Legtura neidentificatoare
O legtur neidentificatoare este reprezentat cu ajutorul unei linii punctate. Entitatea-
descendent ntr-o relaie neidentificatoare se numete independent de identificator, dac nu
este entitate-descendent ntr-o oarecare legtur identificatoare
Reguli de baz pentru Atribut
1. Atributul unei Entiti are un nume unic.
2. O Entitate poate avea mai multe atribute.
3. Atributele sunt : proprii sau motenite.
- Atributele proprii sunt unicale n cadrul acestui model
- Atributele motenite se transmit de la Entitatea paternal odat cu determinarea
conexiunii de identificare.

Baza IDEF1x - abordarea, propus de Peter Chen, care permite construirea unui model al
datelor echivalent modelului relaional n forma normal trei.
Perfecionarea metodei IDEF1 a condus la crearea versiunii IDEF1X, care a fost elaborat n
scopul sporirii simplitii i posibilitilor de automatizare.
Diagramele IDEF1X sunt utilizate ntr-o serie de instrumente CASE, cum ar fi: ERwin,
Design/IDEF.
Exist dou nivele de prezentare a modelelor logic i fizic.
n Modelul Logic datele sunt prezentate analogic cum exist n lumea real i pot fi numite tot
aa cum sunt numite n realitate, de exmplu Client, Departament sau Nume angajat.
Obiectele modelului sunt numite entiti i atribute.
Modelul logic al datelor este universal i sub nici o form nu este legat de realizarea concret
a SGBD.
n Modelul Fizic datelor depinde de SGBD. ntr-un model fizic este inclus informaia despre
toate obiectele BD. Unui model logic i pot corespunde cteva modele fizice diferite.
Dac ntr-un model logic nu import tipul de date al unui atribut, ntr-un model fizic este
important s fie descris toat informaia privind obiectele fizice concrete tabele, coloane,
indici, proceduri etc.
Interfaa Erwin
Fiecrui nivel de afiare a modelului i corespunde panoul instrumental propriu.
La nivel logic panoul de instrumente include:
butonul indicatorului de mouse;
pentru introducerea unei entiti;
butonul categoriei;
introducere a unui bloc de text;
pentru deplasarea atributelor;
butonul pentru crearea legturilor: identificatoare, muli-la-muli i neidentificatoare
La nivel fizic: n locul butonului categoriilor butonul pentru introducerea vederilor (view);
n locul butonului legturii muli-la-muli butonul pentru legarea vederilor.
Pentru crearea modelelor datelor pot fi utilizate dou notaii: IDEF1X i IE (Information
Engineering). n continuare vom utiliza notaia IDEF1X.
Pentru comutarea ntre ML i MF al datelor servete lista cu dou opiuni din parte central a
panoului de iinstrumente ERwin.
Dac la comutare MF nu exist nc, el va fi creat automat.
Nivele de afiare
n ERwin exist cteva nivele de afiare a diagramelor: (clik wiev- display level - nivelul
entitilor (entity), nivelul atributelor (atribute) , nivelul cheilor primare(primare key), nivelul
cheilor (keys) , nivelul definiiilor (definition), i nivelul pictogramelor (icon).
Nivelele modelului logic
n dependen de profunzimea prezentrii informaiei despre date exist trei nivele ale
modelului logic:
diagrama entitate-relaie (Entity Relationship Diagram, ERD);
modelul datelor, bazat pe chei (Key Based model, KB);
modelul atributiv complet (Fully Attributed model, FA).
Diagrama entitate-relaie reprezint modelul de nivel superior al datelor.
El include entitile i legturile reciproce, care reflect procesele business principale ale
domeniului obiectiv. Aceste diagrame nu sunt detaliate n profunzime, ele includ doar
entitile principale i legturile ntre ele, entiti care satisfac cerinele principale ale
sistemului informaional.

Modelul datelor, bazat pe chei,

permite prezentarea mai amnunit a datelor.
Include descrierea tuturor entitilor i a cheilor primare,
i este destinat prezentrii strutucrii de date i a cheilor, care corespund domeniului obiectiv

Modelul atributiv complet

Este cea mai detaliat prezentare a structurilor de date:
prezint datele n forma normal trei i include toate entitile, atributele i legturile.
SGBD susinute de ERWin
Modelul SGBD este generat n mod automat din modelul transformaional i reflect
exact catalogul de sistem al SGBD.
Nivelul fizic la care este prezentat modelul depinde de serverul selectat. ERwin susine
peste 20 de tipuri (relaionale i nu numai) de BD.
DB2 LUW 9.x, DB2 ZOS 9.x,
Informix 11.x, Oracle 11g,
MS SQL Server 2000,2005,2008,2012,
MySQL 5.x, SQL Azure
Sybase (ASE) 15.0, Sybase IQ 12.x,
Teradata v13, ODBC 3.x,
DB2 iSeries 5.x/6.x,
SAS, Progress 10.x,

Aceast aplicaie poate fi descrcat - http://download.freedownloadmanager.org/Windows-

PC/CA-ERwin-Data-Modeler/FREE-9.6.00.4430.html
Exemplu unui Sistem Informaional modelat n Standardul IDEF1x cu aplicaia Erwin Data
Modeler poate fi studiat -http://www.bsuir.by/m/12_100229_1_90142.pdf
TEMA 6. Metode de proiectare
6.1.Principii de abordare n proiectare Sisteme Informaionale. 6.2.Metode de proiectare.
6.2.1.Proiectarea canonic. 6.2.2.Proiectare tip.

6.1.Principii de abordare n proiectare S.I

Utilitatea S I

Eficien economic

Principii de abordare Economice i de

proiectare S I organizare Respectare standarde
tehnologice

Abordare sistemic

Principiu de
modelare sistem inegrare

Principiu modularitate Inovare

Decompoziie Sistem
Principiu de Informaional
adaptabilitate

Principiu de Decompoziie procese

Sistem deschis de proiectare

Principiu de
intelectualizare Participare utilizator

Principiu interfa
prietenoas Eficien a activitii
de proiectare

Principii economice i de organizare -10 principii:

- Principiul utilitatii,
- Principiul eficien economic a sistemului,
- Principiul respectare standarde
- Principiul abordare sistemic
- Principiul de integrare
- Principiul inovare
- Principiul de decompoziie a sistemului informaional
- Principiul de decompoziie a procesului de proiectare
- Principiul de participare utilizator
- Principiul de eficien a activitii de proiectare
Principiul utilitatii
Nu exist sisteme informaionale care s poate afirma c sunt ideale din punct
de vedere al utilitii oferite utilizatorilor. Cu toate acestea, produselor softwarw cu o
utilitate peceput mai bun sunt preferate cu regularitate de ctre cumprtori, iar utilitatea
perceput bun este de regul o expresie a unui process de concepie i execuie care a inut
seama cu consecven de nevoile publicului i n principiu, dac se dorete realizarea unui
system informatics cu o utilitate peceput ridicat, procesul de design trebuie s debuteze
prin stabilirea obiectivului primar al acelui produs software, identificarea publicului int i a
competitorilor existeni la nivelul publicului int, n specual a acelora care sunt la momentul
respective lideri de pia. n principiu, dac se dorete realizarea unui sistem
informatic cu o utilitate perceput ridicat, procesul de design trebuie s debuteze prin
stabilirea obiectivului primar al acelui produs software, identificarea publicului int i
a competitorilor existeni la nivelul publicului int, n special a acelora care sunt
la momentul respectiv lideri de pia.
Principiul eficien economic a sistemului - presupune c Sistemul nou creat va
asigurarea ndeplinirea tuturor cerinelor formulate de beneficiar fa de acest sistem.
Principiul respectare standarde - presupune aplicarea standardelor internaionale i
naionale precum i a recomandrilor ce reglementeaz etepele, fazele i aciunile la
proiectarea Sistemelor Informaionale, la codificarea informaiei, la elaborare i creare
documentaie. Aplicare proceduri standarde pentru schimb de informaie ntre componentele
sistemului i la elaborare interfa a utilizatorului etc.
Principiul abordare sistemic presupune determinarea i abordarea tuturor proceselor,
fenomenelor, conexiunile i interaciunile att ntre ele ct i cu mediul ambiant.
"ntregul este mai mult dect suma prilor componente". Ascest principiu cere aplicarea
ideologiei unice ctre prile componente al Sistemului partea funcional, selectarea
sistemului de programare, sistemului de codificare informaie structura bazei de date
asigurarea coompatibilitii i iteroperabilitii componentelor structura bazelor de date.
Principiul abordare sistemic presupune ordinea de proiectare de sus n jos adic de la
general spre particular adic la nceput se rezolv sarcinile generale ale sistemului i se
formuleaz cerinele funcionale care ulterior vor fi elaborate ntr-o consecutivitate. Abordare
sistemic presupune determidarea emergenei adic dterminarea a noi proprieti ale
sistemului ce nu au fost formulate anterior.
Principiul de integrare - presupune crearea Sistemelor Informaionale cu funcionalit
extinse. Adic subsistemele SI au o baz informaional comun. Acest principiu de obicei
duce spre integrarea subsistemelor intr-un Sistem cotrporativ
Principiul inovare - identificarea funciilor anterior nerezolvate i rezolvarea.
Principiul de decompoziie - duce la ridicarea calitii SI ptrin elaborarea a mai multor
subsisteme n special dac avem de construit un Sistem Informaional de amploare cu
participarea a mai multor grupuri de proiectani i programatori.
Principiul de participare utilizator n special la etapa elaborrii prototipurilor participarea
primelor persoane, participarea responsabililor de proces etc.
Principiul de eficien a activitii de proiectare presupune c sonecostul proiectrii
trebuie s fie ma mic de ct preurile pe pia i termenii de realizare s fie respectasi a
precum este stipulat de condiiile Contractului.
Principii tehnolofice 6 principii
Principiul de modelare sistem
Principiul de modularitate.
Principiul de adaptabilitate
Principiul de Sistem deschis
Principiul de intelectualizare
 Principiul de Sistem prietenos (friendliness)
Principiul de modelare sistem - Se determin relaiile dintre mrimile caracteristice, se
construiete un model simplificat, o imagine a procesului considerat. Modelarea sistemelor se
realizeaz n scopul obinerii unor informaii suplimentare sau a specializrii personalului
folosindu-se diferite instrumente i tehnici.
Modelul este o reprezentare simplificat, aproximativ a sistemului real. Nu e de regul nici
posibil, nici necesar s se realizeze o descriere amnunit a tuturor mecanismelor interne. E
suficient ca modelul s mimeze, s se comporte suficient de aproape de sistemul real.
Modelul trebuie s fie ntr-o form utilizabil (care nu este un scop n sine). El constituie o
baz pentru analiz, luarea deciziilor i n acest sens modelul trebuie s fie de o complexitate
suficient pentru a reflecta toate procesele.
Exist mai multe tipuri de modele i anume:
- modele fizice (empirice sau la scar redus de exemplu se elaboreaz o tehnologie n
domeniul chimiei, un micropilot, se ncearc procesul tehnologic pe acest model fizic
i se trag concluzii.),
- modele fenomenologice (conceptuale sistemele respective sunt descrise prin anumite
legi) modele funcionale (formale sistemul e reprezentat prin relaii funcionale,
scheme funcionale),
- modele matematice (analitice).
Principiul de modularitate
este procesul de partiionare a unui sistem n componente individuale (module) ceea ce
permite reducerea complexitii sistemului prin definirea unor granie bine stabilite i
documentate.
modularitatea const n partiionarea sistemului n module care pot fi elaborate separat, dar
care au conexiuni cu alte module ale sistemului.
modulele servesc ca i containere n care sunt declarate clasele i obiectele sistemului.
Principiul de adaptabilitate.- Adaptabilitate presupune corelarea formei de prezentare, a
gradului de prelucrare cu nivelul de pregatire, gradul de informare, pozitia ierarhica detinute
de catre receptor
Principiul de Sistem deschis - Caracterul deschis/parial deschis al sistemelor:
un sistem care are legturi cu mediul prin cel puin o ntrare i o ieire este considerat un
sistem deschis, n timp ce absena uneia din legturi (de ntrare sau de ieire) determin
caracterul parial-deschis al acestuia. n absena ambelor legturi cu mediul, sistemul este
izolat. Aceast proprietate caracteristic face o distincie clar ntre sistemele biologice i cele
economice care putndu-se organiza i sporesc ordinea interioar i prin urmare i micoreaz
entropia pe baza schimbului permanent de substan, energie, informaii cu mediul lor.
Caracterul antientropic al sistemelor cu structur cibernetic este legat n special de
posibilitatea perfecionrii conducerii i a reducerii gradului de dezorganizare intern a
sistemelor deschise prin ameliorarea proprietilor structurale i a celor
informaionaldecizionale precum i prin intensificarea schimbului de informaii i a
tranzaciilor cu mediul.
Principiul de intelectualizare ????????
Principiul de Sistem prietenos???????
6.2. Metode de proiectare
n dependen de nivelul de utilizare a soluiilor tip, metodele de proiectare a SI se mpart n:
proiectare canonic;
proiectare tip.
Proiectarea canonic presupune elaborarea sistemelor fr utilizarea unor soluii gata (de la
zero) sau mijloace instrumentale speciale dar dup careva reguli sau canon.
Proiectarea tip presupune crearea sistemului informaional din elemente tip existente.

Proiectare canonic.
Proiectarea canonic presupune elaborarea sistemelor fr utilizarea unor soluii gata (de la
zero) sau mijloace instrumentale speciale dar dup careva reguli sau canoane.
Proiectare tip.
Proiectarea tip presupune crearea sistemului informaional din elemente tip existente. Care
aplic:
Tehnologii de proiectare automatizat
Tehnologii de proiectare tip.
Tehnologii de proiectare tip pe parametri.
Tehnologii de proiectare tip pe modele.

6.2.1. Proiectarea canonic

Stadiile i etapele proiectrii canonice. Scopurile i obiectivele etapei preproiect.
Modelele activitii ntreprinderii (cum este i cum trebuie s fie). Componena
lucrrilor la etapa elaborrii proiectului tehnic. Documentaia de proiect. Proiectarea
generic. Noiune de proiect generic, premisele tipizrii. Obiectele tipizrii. Metodele de
proiectare generic. Estimarea eficienei utilizrii soluiilor tipizate. Soluie proiect tip.
Metode i mijloace de proiectare prototipizat a SI.
Organizarea proiectrii canonice este orientat spre utilizarea modelului cascad a ciclului de
via. Etapele sunt standardizate n ISO 12207.
n dependen de complexitatea obiectului automatizrii i problemele, care trebuie
soluionate prin crearea unui SI concret, etapele pot fi de complexitate diferit.
 Este permis de a combina etape succesive i chiar de a exclude unele etape la orice faz a
proiectului.
Mai mult, urmtoarea etap a lucrrilor poate ncepe pn la sfritul etapei precedente.
Etapele crerii SI, executate de organizaiile participante, sunt fixate n contracte i sarcini
tehnice de executare a lucrrilor.

Etapa 1. Studiul SI existent i definirea cerinelor noului sistem

cercetarea SI i motivarea necesitii crerii unui sistem nou;
formarea cerinelor fa de sistemul nou;
elaborarea raportului despre lucrrile ndeplinit.
Studiul sistemului existent cuprinde un grup de activiti care urmresc cunoaterea:
 - performanelor tehnico-funcionale ale sistemului informaional, att n ansamblul su,
ct i pentru elementele de structur ale acestuia,
- a cerinelor informaionale ale conducerii,
- cunoaterea lipsurilor i restriciilor pe care le prezint sistemul existent fa de aceste
cerine.
De modul de realizare a acestor activiti depinde ntregul proces de realizare a sistemului
informatic.
Studiul sistemului existent consta in:
1. definirea caracteristicilor generale ale (unitii de informatizare) obiectului social-
economic;
2. studiul activitilor de baz desfurate in sistemul obiectului social-economic;
3. studiul sistemului de conducere a obiectului;
4. studiul sistemului informaional existent;
5. identificarea metodelor i mijloacelor tehnice.
1. Definirea caracteristicilor generale ale obiectului de informatizare presupune:
cunoasterea profilului, obiectivelor agentului economic;
cunoasterea locului in sfera serviciilor si sfera productiei;
cunoasterea relatiilor de cooperare cu alti agenti economici;
cunoasterea specificului activitatii de baza ( productie, servicii);
cunoasterea nivelului tehnic;
cunoasterea principalilor indicatori economici si evolutia lor;
dezvoltarea, modernizarea etc.
2. Studiul activitatilor desfasurate in sistemul obiectului social-economic, modul de
realizare a funciunilor unitii economice se face:
a). Pe baza Statutului de funcionare a unitii social-economoce
i se studiaz:
activitile i sarcinile din cadrul acestor funciuni;
Atribuiile ce le revin subdiviziunilor unitii economice;
modul de realizare a activitilor funcionale din cadrul unitii economice.
b). In cazul activitii de producie se prezint:
fluxul de producie, amplasarea locurilor de munc, amplasarea depozitelor, regimul
funcionare etc.;
tipurile de produse, structura lor, ciclurile de realizare;
modul de organizare a produciei, micarea intern a produciei, controlul calitii
lucrrilor, stocarea produciei;
resursele existente;
Capacitai;
asigurarea tehnic / proiectarea de produse noi;
norme tehnice;
asigurarea cu materiale necesare;
sistemul existent de planificare a produciei.
3. Studiul sistemului de conducere se refer la:
identificarea caracteristicilor sistemului de conducere existent;
sistemul de indicatori cantitativi, valorici i calitativi;
structura organizrii conducerii;
caracteristicile rezultate din Statutul de functionare a societii, tipuri de decizii,
modul de realizare a deciziilor, controlul indeplinirii deciziilor....
4. Studiul sistemului informaional presupune:
elaborarea schemei fluxului informaional global (cu punerea n eviden a
principalelor activiti i a legturilor statice si dinamice dintre acestea);
estimarea cantitativa si calitativa a informatiilor de intrare-ieire, modul de culegeresi
prelucrare;
identificarea principalilor algoritmi, regulilor de calcul i a punctelor i regulilor de
control;
Cunoaterea principalelor restricii ale sistemului informaional;
Situtia raionalizrii fluxurilor i a documentelor din unitatea economic, studii
elaborate, stadiul lor de implementare;
sistemul de codificare utilizat, restricii;
Performanele i limitele sistemului informaional existent.
Identificarea metodelor i mijloacelor tehnice utilizate pentru prelucrarea datelor n
cadrul sistemului informaional existent se face evideniind:
mijloacele tehnice existente in dotarea unitii economice ( modul de utilizare,
cheltuielile de exploatare, personalul implicat, performante);
existenta unor aplicaii proiectate i/sau implementate.
Determinarea cerinelor sistemului - Determinarea cerinelor sistemului este activitate
esenial in aflarea situaiei existente i a ceea ce se dorete n viitor. Rezultatul activitii
de determinare a cerinelor sistemului se concretizeaz n diferite forme ale informaiilor
colectate, cum sunt:
copii ale interviurilor,
insemnari efectuate in timpul observrii i analizei documentelor,
interpretri ale raspunsurilor la chestionare,
seturi de formulare,
rapoarte,
descrieri ale posturilor de lucru s.a., precum si rezultate ale prelucrarilor efectuate de
calculator, cum ar fi prototipurile.

Rezultatele prezentate dup aceast activitate pot fi rezumate astfel:

1. Informatii obtinute in urma conversatiilor cu utilizatorii sau prin observarea activitatilor
prestate de acestia: copii sau sinteze ale interviurilor, raspunsurile la chestionare sau
interpretari ale acestora, insemnari si rezultate din observarea activitatilor, procese verbale ale
sedintelor ce au avut loc in acest scop;
2. Informaii scrise care exist n unitate: misiunea i strategia afacerii, exemplare ale
formularelor, rapoartelor i machetelor de ecrane, manuale ale procedurilor, descrieri ale
posturilor de lucru, manuale de instruire, scheme de sisteme i documentaia sistemului
existent, rapoartele consultanilor;
3. Informaii obinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD (Joint
application design), copii ale fiierelor sesiunilor grupului de sprijinire a sistemului,
coninutul depozitelor i rapoartele existente n CASE, ecrane i rapoarte rezultate din
prototipurile sistemului, s.a.

Analiza situaiei i identificarea cerinelor sistemului nou.

Cercetarea sistemului existent const n:
identificarea caracteristicilor generale ale obiectului automatizrii;
studiul activitilor de baz desfurate n sistem;
 studiul sistemului de conducere;
studiul sistemului informaional;
identificarea metodelor i mijloacelor tehnice.
Definirea caracteristicilor generale ale organizaiei pentru care va fi elaborat noul
sistem implic:
cunoaterea profilului, obiectivelor organizaiei;
cunoaterea specificului activitii de baz (producie, servicii);
cunoaterea locului n sfera serviciilor i/sau sfera produciei;
cunoaterea relaiilor de cooperare cu ali ageni economici;
cunoaterea nivelului tehnic;
cunoaterea principalilor indicatori de performan i evoluia lor;
dezvoltarea, modernizarea etc.
Studiul activitilor desfurate n sistemul economic, modul de realizare a funciunilor
unitii economice se face prin:
Pe baza statutului de funcionare a organizaiei se studiaz:
n cazul activitii de producie se prezint:
fluxul de producie, amplasarea locurilor de munc, depozitelor etc.;
tipurile de produse, structura lor, ciclurile de realizare;
modul de organizare a produciei, stocarea produciei, transporturile interne,
controlul de calitate;
resursele existente: capaciti; asigurarea tehnic; proiectarea de produse noi;
norme tehnice;
asigurarea cu materiale necesare;
sistemul existent de programare a produciei.

Studiul sistemului de conducere se refer la:

identificarea caracteristicilor SC existent;
sistemul de indicatori cantitativi i valorici;
organizarea conducerii;
caracteristicile rezultate din statutul de funcionare a societii, tipuri de decizii, modul
de lucru a deciziilor.

Studiul sistemului informaional presupune:

elaborarea schemei fluxului informaional global (cu punerea n eviden a
principalelor activiti i a legturilor statice i dinamice dintre acestea);
estimarea cantitativ i calitativ a informaiilor de intrare-ieire, modul de culegere i
prelucrare a datelor;
identificarea principalilor algoritmi, regulilor de calcul, a punctelor si regulilor de
control;
cunoaterea principalelor restricii ale sistemului informaional;
situaia raionalizrii fluxurilor i a documentelor din organizaie, studii elaborate,
stadiul lor de implementare;
sistemul de codificare utilizat, restricii;
performanele i limitele sistemului informaional existent.
Formarea cerinelor sistemului nou este activitate esenial n aflarea situaiei existente i a
ceea ce se dorete n viitor. Rezultatul activitii de determinare a cerinelor sistemului se
concretizeaz n diferite forme ale informaiilor colectate, cum sunt:
- copii ale interviurilor,
-nsemnri efectuate n timpul observrii i analizei documentelor,
- interpretri ale rspunsurilor la chestionare,
-seturi de formulare, rapoarte,
-descrieri ale posturilor de lucru .a.,
-precum i rezultate ale prelucrrilor efectuate de calculator, cum ar fi prototipurile.
Activitile enumerate pot fi executate total cu forele achizitorului sau prin contractarea unor
servicii din partea unei organizaii de consultan.

Rezultatele prezentate dup etapa 1:

Informaii scrise care exist n unitate: misiunea i strategia afacerii, exemplare ale
formularelor, rapoartelor i machetelor de ecrane, manuale ale procedurilor, descrieri
ale posturilor de lucru, manuale de instruire, scheme de sisteme i documentaia
sistemului existent, rapoartele consultanilor;
Informaii obinute n urma conversaiilor cu utilizatorii sau prin observarea
activitilor prestate de acetia: copii sau sinteze ale interviurilor, rspunsurile la
chestionare sau interpretri ale acestora, nsemnri i rezultate din observarea
activitilor, procese verbale ale edinelor ce au avut loc n acest scop;
Informaii obinute cu ajutorul calculatorului: copii ale fiierelor sesiunilor grupului de
sprijinire a sistemului, coninutul depozitelor i rapoartele existente n CASE, ecrane i
rapoarte rezultate din prototipurile sistemului, .a
Materialele, create vor fi folosite pentru:
motivarea necesitii elaborrii i implementrii graduale a sistemului nou;
elaborarea Sarcinii Tehnice pentru crearea sistemului;
perfectarea Proiectului Tehnic i Proiectului de lucru.
Un raport special studiul de fezabilitate a proiectului - poate fi parte component a acestor
rezultate. n acest raport vor fi clar definite beneficiile achizitorului, dac va decide finanarea
proiectului, termenul n care produsul finit va fi lansat n exploatare, costurile aferente,
modalitatea i graficul achitrilor, efectul economic i timpul de recuperare a cheltuielilor.

Studiul de fezabilitate
Acest document va include cel puin:
constrngerile, riscurile, factorii critici, care pot influena succesul;
condiiile de exploatare a viitorului sistem: arhitectura sistemului, resursele tehnice i
logice, condiiile de funcionare, personalul de exploatare i utlizatorii sistemului;
termenii de finalizare a etapelor, forma de primire-predare a lucrrilor, resursele
implicate, msurile de protecie a informaiei;
descrierea funciilor sistemului;
posibilitile de dezvoltare viitoare a sistemului;
obiectele informaionale ale sistemului;
interfeele i modalitatea de partajare a funciilor ntre om i sistem;
cerinele privind componentele program i informaionale, SGBD;
indicaii privind lucrrile, care nu vor fi realizate n cadrul proiectului dat.
Va fi stabilit lista activitilor, automatizarea crora este recomandat i ordinea n care
aceasta va avea loc.
Funciile planificate pot fi clasificate conform formatului MuSCoW: Must have funcii
obligatorii; Should have funcii dorite; Could have funcii posibile; Won't have funcii
lips.
Realizarea funciilor din categoria a doua i a treia este limitat de cadrul temporal i
financiar: va fi realizat tot ce este obligatoriu i la maximum ce este dorit i posibil n ordinea
prioritilor.
Este foarte important ultima categorie de funcii, deoarece este necesar s se stabileasc
graniele proiectului i s se concretizeze explicit funciile, care vor fi lips.
Analiza situaiei i identificarea cerinelor sistemului nou.
Modelele activitii organizaiei vor fi de dou categorii:
modelul cum este (as-is), care reflect procesele business existente n organizaie;
modelul cum va fi (to-be), care reflect modificrile necesare ale proceselor
business la introducerea SI.
Implicarea testerilor ncepnd cu etapa de analiz. Vor participa la:
soluionarea problemelor legate de obinerea caracteristicilor comparative ale
platformelor tehnice, ale sistemelor de operare, SGBD, alte medii de funcionare;
elaborarea compart. planului de lucru asociat fiabilitii i testrii SI.
Rezultatele primei etape servesc la elaborarea Concepiei (etapa 2) i Sarcinii Tehnice (etapa
3) a viitorului sistem informaional.

Etapa 2. Elaborarea Concepiei SI

E
t
Elaborarea aConcepiei SI
Studii i executarea lucrrilor de cercetare necesare;
Studierea obiectului automatizrii; p
Elaborarea versiunilor Concepiei, discutate n grupul de lucru, format din
reprezentanii beneficiarului i executorului;
a
perfectarea versiunii finale a Concepiei i aprobarea ei de Conducere

RT 38370656- 002:2006: Concepia este documentul iniial, elaborat la crearea sistemului,

care conine rezultatele ndeplinirii lucrrilor de cercetare tiinific i experimental i
servete drept baz pentru elaborarea ulterioar a documentaiei tehnice.
n dependen de scopurile propuse, Concepia de baz sau cadru. Concepia cadru se
elaboreaz n cazul, cnd sistemul descris const dintr-o multitudine de sisteme independente
sau interconectate, pentru care ulterior vor fi elaborate concepii de baz.
Concepia cadru se deosebete de cea de baz printr-o expunere rezumativ a materialului sau
prin lipsa capitolelor/ subcapitolelor separate, care sunt obligatorii pentru Concepia de baz.
Destinaia Concepiei const n prezentarea viziunii generale asupra sistemului,
funciilor ndeplinite de sistem, descrierii spaiului de drept i informaional i
interaciunii cu alte SI.
Concepia SI conine capitolele
1. Introducere;
2. Generaliti;
3. Spaiul juridico-normativ al funcionrii sistemului;
4. Spaiul funcional al sistemului;
5. Structura organizaional a sistemului;
6. Documentele sistemului;
7. Spaiul informaional al sistemului;
8. Spaiul tehnologic al sistemului;
9. Asigurarea securitii informaionale;
10. ncheiere.

Etapa 3. Sarcina tehnic

Etapa elaborrii Sarcinii tehnice (ST) include activiti de elaborare prin iteraii a
versiunilor ST, discutarea i perfectarea lor, coordonarea cu i aprobarea de Conducere.

E
t
RT 38370656- 002:2006, SarcinaSarcinaTehnic (etapaatehnic
3) este documentul, care determin scopurile
i obiectivele, cerinele i datele principale de intrare, necesare pentru elaborarea SI.
La elaborarea ST vor fi soluionate urmtoarele p probleme:
stabilirea scopului crerii SI, determinarea funciilor i a subsistemelor;
a subsistemele;
elaborarea i fundamentarea cerinelor privind
elaborarea i fundamentarea cerinelor privind baza informaional, resursele
matematice, program i tehnice (inclusiv, mijloacele de comunicaie i trasmitere a
datelor);
identificarea cerinelor generale ale sistemului proiectat;
determinarea listei lucrrilor de creare a sistemului i a executorilor;
determinarea etapelor crerii sistemului i termenilor de execuie a acestora;
calcularea preliminar a costurilor pentru crearea sistemului i determinarea nivelului
de eficien economic a implementrii lui.

Structura Caietului de sarcini.

1. Generaliti
2. Destinaia i scopurile crerii /modernizrii Sistemului Informaional
3. Descrierea obiectului automatizrii.
4. Cerine funcionale fa de sistem.
5. Componena i coninutul lucrrilor de creare a sistemului.
6. Modul de testare / verificare i predare / primire a sistemului.
7. . Cerine referitoare la componena i coninutul lucrrilor de pregtire a obiectului
automatizrii pentru lansarea n exploatare a SI.
8. Cerine privind documentaia.
9. Surse normatve i legale.
1. Generaliti
 denumirea complet a sistemului i abrevierea
codul (numrul) temei sau al contractului
denumirea organizaiei executoare i a beneficiarului, rechizitele lor
lista documentelor n baza crora este creat sistemul
Termeni (executare) de ncepere i finalizare a lucrrilor
informaii despre surse i modalitatea de finanare
ordinea de perfectare i prezentare a rezultatelor crerii: Sistemului Informaional, al
prilor sistemului sau a unor module separate
2. Destinaia i scopurile crerii /modernizrii Sistemului Informaional
categoria activitilor de automatizare,
lista obiectelor pentru care va fi utilizat sistemul,
denumirea i valorile solicitate ale indicatorilor:
tehnici,
tehnologici,
economici etc.,
care vor fi atini odat cu implementarea sistemului
3. Descrierea obiectului automatizrii.
informaii succinte despre obiectul automatizrii
informaii despre condiiile de exploatare i caracteristicile mediului ambiant
4. Cerine funcionale fa de sistem.
Cerine privind sistemul n totalitate:
cerine referitoare la structura i modul de funcionare a sistemului (lista
subsistemelor, nivelele ierarhice, gradul de centralizare, modul de schimb
informaional, regimurile de funcionare, interaciunea cu alte sisteme,
perspectivele de dezvoltare)
cerine privind personalul (roluri, calificarea, regimul de lucru, organizarea
instruirii, utilizatorii)
indicatori asociai destinaiei sistemului (adaptabilitatea la modificrile
sistemului de conducere i a valorilor parametrilor, scalabilitatea)
cerine privind fiabilitatea, securitatea, ergonomia, transportabilitatea,
exploatarea, deservirea tehnic i reparaia, protecia contra unor influene
externe, drepturi de autor, standardizare i unificare
Cerine referitoare la funcionaliti (pe subsisteme):
lista activitilor automatizate
cadrul temporal de realizare a fiecrei funcii
cerine privind calitatea realizrii fiecrei funcii, forma de prezentare a
ieirilor, exactitatea i autencitatea datelor
lista i criteriile de stabilire a cderilor (refuz serviciu)
Cerine referitoare la resurse:
matematice (componena i sfera utilizrii modelelor i metodelor matematice,
algoritmilor existeni i noi
informaionale (componena, structura i organizarea datelor, schimbul intern
de date, compatibilitatea informaional cu alte sisteme, clasificatoarele
utilizate, SGBD, controlul datelor i folosirea masivelor de date, procedurile de
conferire a valabilitii juridice documentelor la ieire)
lingvistice (limbajele de programare, limbile de interaciune a utilizatorilor cu
sistemul, sistemele de codare, limbajele pentru intrri/ieiri
 tehnice
metrologice
organizaionale (structura i funciile departamentelor de exploatare, protecia
contra unor aciuni eronate),
metodice (documentaia normativ-tehnic)
5. Componena i coninutul lucrrilor de creare a sistemului.
lista stadiilor i a etapelor
termeni de executare
lista orgaizaiilor executoare
modalitatea i ordinea expertizrii documentaiei tehnice
programul de asigurare a fiabilitii
programul de asigurare metrologic
6. Modul de testare / verificare i predare / primire a sistemului.
tipurile, componena, volumul i metodele de testare
cerine generale privind acceptarea lucrrilor pe etape
statutul comisiei de predare/primire
7. Cerine referitoare la componena i coninutul lucrrilor de pregtire a obiectului
automatizrii pentru lansarea n exploatare a SI.
transformarea informaiilor de intrare n form mainolizibil (digitizare)
modificrile ce trbuie introduse n structura obiectul automatizrii
termenii i modalitatea de selectare i instruire a personalului
8. Cerine privind documentaia.
lista documentelor elaborate
lista documentelor pe supori magnetici
9. Surse normatv i legale.
Legislaie, standarde, documente i materiale informaionale, n baza crora a fost elaborat
ST i Sistemul Informaional.

Etapa 4. Proiectul tehnic.

Este documentul, care include soliile generale sistemice de proiect, algoritmii de soluionare
a problemelor, estimarea eficienei economice a implementrii sistemului automatizat i lista
activitilor pentru pregtirea implementrii.
n cadrul acestei etape sunt executate lucrri experimentale i de cercetare pentru alegerea
final a soliiilor principale de proiect i calcularea eficienei economice a implementrii
sistemului
E
t
Proiectul tehnic - lucrri Proiectul a tehnic
elaborarea soluiilor de proiect pentru sistem i prile sistemului;
p
elaborarea documentaiei de proiect pentru sistem i prile lui;
perfectarea documentaiei de furnizare a componentelor;
a
elaborarea sarcinilor pentru proiectarea prilor conexe ale proiectului.
Structura Proiectului Tehnic.
1. Not explicativ. 4
2. Structura funcional i organizaional a sistemului.
3. Enunul problemei i algoritmii de soluionare
4. Organizarea bazei informaionale.
5. Albumul cu formele documentelor.
6. Resursele matematice.
7. Mijloace tehnice necesare.
8. Calculul eficienei economice a sistemului.
9. Msuri privind pregtirea obiectului pentru implementarea sistemului
10. Borderoul documentelor

1. Not explicativ.
cadrul justificativ pentru elaborarea sistemului,
lista organizaiilor executoare,
caracteristica succint a obiectului cu lista indicatorilor tehnico-economici principali
de funcionare i legtuarile cu alte obiecte,
informaii succinte privind soluiile principale de proiect
2. Structura funcional i organizaional a sistemului
justificarea subsistemelor, lista i destinaia lor
lista lucrrilor ndeplininte n cadrul fiiecrui subsistem, caracteristica succint i
coninutul lucrrilor
schema legturilor informaionale ntre subsisteme i lucrri n cadrul unui subsistem

3. Enunul problemei i algoritmii de soluionare.

metoda, periodicitate i timpul de rezolvare, metodele de culegere i transmitere a
datelor, relaia cu alte sarcini, natura utilizrii rezultatelor)
modelul economic i modelul matematic al problemei (prezentarea structural i
detaliat)
informaii normative (coninutul i forma de prezentare)
informaii privind interconexiunile cu alte sarcini i procese
informaii pentru decizii ulterioare referitoare la problema dat
informaii cu privire la efectuarea modificrilor (modul de introducere a schimbrilor
i lista informaiilor care fac obiectul modificrilor)
algoritmul de soluionare a problemei (modelul proceselor, secvene i paii, schema,
formule de calcul)
studiu de caz (set de formulare ale documentelor de intrare completate, documente
convenionale de ieire cu informaii acumulate i stocate, formulare ale documentelor
de ieire, completate cu rezultatele soluionrii problemei conform algoritmului
elaborat)
4. Organizarea resuselor informaionale
sursele de informaii externe i interne i modul de transfer de la proces la proces
setul de indicatori, utilizai de sistem
lista de documente, termenii i periodicitatea intrrii
soluiile principale de proiect privind organizarea fondului
componena bazei informaionale, inclusiv rechizitele, ontologia i taxonomia
informaiei, marja de valori a datelor i lista documentelor bazei informaionale
lista masivelor, volumul lor, modalitatea i frecvena corectrii informaiilor
structura fondului cu descrierea legturilor ntre elementele constitutive, cernie
referitoare la tehnologia crerii i operrii fondului
 metodele de pstrare, cutare, modificare i control
determinarea volumelor i fluxurilor informaionale
exemplu de control la introducerea unor modificri
propuneri privind unificarea documentaiei
5. Albumul cu formele documentelor.
6. Resursele matematice.
justificarea structurii resurselor matematice
justificarea alegerii mediului de programare (platforma de programare)
lista resuselor program de sistem (Sisteme de operare, SGBD-ul,)
7. Mijloace tehnice necesare.
descrierea i motivarea schemei procesului tehnologic de prelucrare a datelor
justificarea alegerii structurii complexului tehnic i grupurilior funcionale ale acestuia
motivarea cerinelor privind echipamentele speciale,
Motivare cerinelor privind reele de transport date,
setul de aciuni pentru asigurarea fiabilitii funcionrii echipamentelor

8. Calculul eficienei economice a sistemului.

devizul de cheltuieli pentru exploatarea sistemului
calculul eficienei economice anuale obinute din optimizarea structurii organizaiei,
diminuarea costurilor i a pierderilor,
mbuntirea deciziilor administrative
9. Msuri privind pregtirea obiectului pentru implementarea sistemului
lista msurilor organizaionale pentru perfecionarea proceselor business
lista lucrrilor pentru implementarea sistemului, care sunt necesare la etapa proiectrii
tehnice, cu indicarea termenilor i responsabililor.
10. Borderoul documentelor

Etapa 5. Proiectarea de detaliu

E
Proiectareat de detaliu
a
Proiectarea de detaliu
Activitile componente ale acestei etape sunt: p
elaborarea soluiilor de preproiect pentru sistem i prile componente
sistemului; a
scrierea codurilor de programe, testarea i corectarea lor
5 componente.
elaborarea documentaiei de detaliu pentru sisten i a prile

Etapa 6. Implementarea codului i perfectarea documentaiei

scrierea i testarea codului modulelor;
integrarea modulelor i testarea subsistemelor i a sistemului;
elaborarea documentaiei de lucru pentru sistem i prile lui.
Este creat PP i documentaia nsoitoare. Documentaia va include informaiile necesare i
suficiente pentru ndeplinirea lucrrilor de implementare a SI, ca i pentru meninerea
nivelului caracteristicilor funcionale.
Calitatea este identificat prin testare. Sunt stabilite urmtoarele tipuri de testri: preliminar,
de exploatare pilot i testarea final. La necesitate pot avea loc testri suplimentare att pentru
ntregul sistem, ct i pentru prile componente.
n dependen de legturile interne ale componentelor i obiectul automatizrii, testrile pot fi
autonome sau complexe. Testrile autonome (de detaliu) includ unele pri ale sistemului. Ele
sunt executate gradual, odat cu finalizarea unei pri pentru darea n exploatare
experimental (pilot). Testrile complexe sunt executate pentru grupuri de pri sau pentru
ntreg sistemul.
Pentru planificarea testrilor este creat documentul Programul i metodica testrilor.
Responsabilul de crearea documentului este fixat n Contract sau ST. Documentul poate
include teste sau exemple de control (n calitate de anexe).

Etapa 7. Lansarea n exploatare

pregtirea obiectului automatizrii;
instruirea personalului;
completarea sistemului cu toate componentele necesare;
executarea lucrrilor de construcie i montare;
lucrri de lansare i depanare;
testri preliminare;
exploatare pilot;
testare de primire-predare.
Etapa 8. Mentenana SI
ndeplinirea lucrrilor n conformitate cu obligaiunile de garanie;
deservirea postgaranie.

TEMA 6.2.2. Proiectare tip.

Proiectare tip - Sau ingineria softului bazat pe componente CBSE Component Based
Software Engineering.
CBSE - proiectarea sistemelor software utiliznd componente reutilizabile.
Crearea sistemului din elemente existente apriori.
Cerin: posibilitatea decompoziiei.
SPT - soluie de proiect tirajat.
Clase n dependen de nivelul decompoziiei:
SPT pe elemente;
SPT pe subsisteme;
SPT pe obiecte.
Abordarea orientat pe parametri, etape:
determinarea criteriilor de estimare a SPT pentru soluionarea problemelor n cauz;
analiza i evaluarea SPT accesibile conform criteriilor formulate;
selectarea i procurarea celei mai potrivite SPT;
acordarea (adaptarea) parametrilor SPT procurate.
O astfel de abordare SPT este vzut ca o cutie neagr
Flux Informaional (FI) - sunt datele primare, care sunt procesate i sunt necesare pentru a
obine rezultate.
Bloc funcional - proceseaz datele primare i formalizeaz rezultatul fucionrii pachetului.
Flux de Parametri (FP) - este informasia necesar pentru ajustarea pachetului la conduii
concrete de funcionare.
Blocul procesare parametri - setul de module ce interpreteaz parametrii.
Blocul de adaptare - interacioneaz cu blocul funcional i poate aduga module sau s le
modifice.
Criterii de estimare a SPT:
destinaia i posibilitile pachetului;
caracteristici i proprieti ale pachetului;
cerinele pentru hardware i software;
documentaia pachetului;
factori de ordin financiar;
caracteristici de instalare;
caracteristici de exploatare;
asistena furnizorului;
calitatea pachetului i experiena de utilizare;
perspectivele de dezvoltare a pachetului.
Etape din metodologia CASE*METHOD pentre realizarea sistemelor informatice.
Definirea strategiei de analiza-proiectare
Prima etapa din metodologia CASE*METHOD pentre realizarea sistemelor
informatice o reprezinta definirea strategiei Obiective
O proiectare cu succes a produselor software presupune o buna formulare si ntelegere a
problemei, evidentiind necesitatile informationale ale organizatiei. Aceasta ntelegere
poate conduce la o distinctie net ntre analiza ("ce trebue facut?") si proiectarea ("cum
trebuie facut?") de sistem.
Obiectivul etapei de strategie este de a elabora de analiza-proiectare.
un set de modele si recomandari pentru dezvoltarea sistemului informatic.
Analiza -proiectare
Aceasta etapa constituie o analiz detaliata, complet a organizatiei, reprezentnd baza
dezvoltrii ulterioare a sistemului informatic.
Distribuia subetapelor fazei strategiei trebuie s pun clar n evident obiectivele urmarite de
organizaie prin proiectarea noului sistem (figura 1).
Subetape
-Definirea direciilor de analiza: obiective, prioritati, limite, factori de influenta; - ntocmirea
diagramei entitate - relatie;
- Definirea ierarhiei de functii;
- Recomandari de proiectare;
- Problemele organizationale si tehnolo-gice;
- Definirea limitelor sistemului;
- Definirea unei posibile arhitecturi a sistemului;
- Aproximarea necesarului de resurse.
Abordarea orientat pe model.
Abordarea orientat pe model - presupune adaptarea componentelor i caracteristicilor SPT
conform obiectului automatizrii.
Depozitul cu metainformaii conine modelul obiectului automatizrii n baza cruia are loc
configurarea produsului program.
n consecin, abordarea model-orientat presupune construirea modelului obiectului
automatizrii utiliznd instrumente program speciale (Utilizarea instrumentelor CASE, SAP
Business Engineering Workbench (BEW), BAAN Enterprise Modeler).
Depozitul include modelul de baz (de referin) a SI, modele tip pentru diferite clase de SI,
modelele SI ale unor organizaii concrete.
Utilizarea instrumentelor CASE
Utilizarea instrumentelor CASE genereaz o serie de faciliti, i anume:
pot deveni suport pentru mai multe metode de analiz,
sprijin conducerea proiectului,
ajut la realizarea de prototipuri,
genereaz documentaia,
genereaz automat coduri.
Instrumentele CASE ofer sprijin utilizatorului prin metodologiile prestabilite, pe care acesta
le poate urma n cadrul proiectului de modelare/implementare a sistemului informatic dorit.
Instrumentele acestuia ofer sprijin n realizarea diagramelor pentru:
activitii, care reprezint comportamentul operaiilor ce utilizeaz seturi de aciuni;
clasele, care exprim structura static a unui sistem relativ la clase i relaiile dintre
ele;
colaborrile, care ilustreaz interaciunile dintre obiectele utilizate: structur spaial
ce reprezint domeniul fizic.
componentele, care descriu componentele software ale unei aplicaii n mediul de im-
plementare;
distribuire, care prezint locaiile componentelor software pe componente hardware;
obiecte, care exprim structura static a unui sistem n funcie de toate obiectele sale i
relaiile dintre ele;
secvene, care ilustreaz interaciunile dintre obiecte utiliznd o structur temporal de
reprezentare a proceselor;
tranziiile strilor, care reprezint comportamentul claselor utiliznd maini de stri;
cazurile de utilizare, care sunt reprezentri ale funcionalitii unui sistem, din punctul
de vedere al utilizatorilor si.
Componentele unui sistem CASE
Editorul de diagrame - este componenta obligatorie a oricrui produs de tip CASE i
permite construirea i modificarea tuturor tipurilor de diagrame utilizate de metodologia /
metodologiile implementate prin CASE. Introducerea informaiilor n editor poate fi fcut n
dou moduri:
de ctre utilizator, prin intermediul unei interfee,
din repository, atunci cnd acesta este actualizat prin reverse engineering.
Editorul de diagrame trebuie s satisfac urmtoarele condiii:
s permit introducerea i modificarea uoar a tuturor entitilor grafice descrise de
metoda de proiectare;
suprafaa grafic s fie de calitate, s permit operaii de zoom, de grupare i aliniere a
elementelor diagramei;
s permit tiprirea eficient a documentelor i paginarea lor precum i selectarea
informaiilor ce vor fi tiprite;
s dea posibilitatea de a decide entitile ce vor fi cuprinse ntr-o pagin fr a trunchia
informaiile;
s permit construirea automat a unor tipuri echivalente de diagrame.
Pentru realizarea acestor faciliti i deoarece opiunile i comenzile de editare a
diferitelor diagrame sunt foarte numeroase editorul de diagrame folosete n general
bare de comenzi, cutii de dialog sau meniuri senzitive de context.
Baza de informaii (repository) - este, de asemenea, o component obligatorie care are
drept rol acumularea i stocarea n maniera organizat a tuturor informaiilor introduse de
persoane diferite la momente diferite, eventual n locuri diferite.
Repository-ul este elementul central, inima unui CASE, care trebuie s memoreze toate
informaiile despre proiecte i s permit ca pornind de la acestea s se creeze informaie
nou care s fie la rndul ei plasat n repository.
 Pentru un proiect sunt verificate i corelate toate informaiile existente n repository cu
scopul de a asigura integritatea i consistena lor. Mai exact diferitele tipuri de diagrame
reprezint aceeai informaie privit din diferite puncte de vedere, deci trebuie s aib o
legtur logic ntre ele.
Datele introduse n anumite diagrame pot fi utilizate si n alte tipuri de diagrame si
depozitul de date este cel care asigura consistenta informaiei ntre diferitele diagrame.
Modificrile efectuate asupra unei entiti dintr-o diagrama sunt automat reflectate n
reprezentarea ulterioar a aceleiai entiti n orice alt diagram. Dintre
caracteristicile i n acelai timp avantajele oferite de acest instrument sunt
urmtoarele:
documentaia de realizare a oricrui proiect, n totalitatea ei, se gsete n repository,
de unde poate fi tiprit integral sau parial i la cerere,
documentaia final a produsului software este realizat pe baza informaiilor despre
proiect, coninute n repository,
creterea preciziei i a acurateei documentaiei fa de cazul n care aceasta este
realizat pe hrtie, deoarece sunt detectate erorile, inconsistenele i omisiunile, tiut
fiind c mai cu seam n cazul aplicaiilor i produselor software complexe elaborate
n cadrul unei echipe aceste aspecte sunt greu de controlat,
asigur lucrul n echip i n reea, pe de-o parte prin accesul controlat al membrilor echipei la
componente de diferite nivele ale proiectului, pe de alt parte prin gestionarea legturilor
dintre componentele ce formeaz arhitectura unei aplicaii, a unui proiect
Analizorul de structur - este componenta care are drept rol depistarea i eliminarea unor
erori dificil de localizat i tratat n fazele ulterioare celei de introducere a informaiilor.
Analizorul este n strns legtur cu editorul de diagrame i cu repository i funcia lui este
de a compara ultimele date introduse cu cele existente pe repository, i de a semnala:
introducerea n acelai domeniu de vizibilitate (diagram, dicionar de date, etc.) a
dou entiti de acelai tip, cu acelai nume,
verific dac toate entitile referite sunt definite,
semnaleaz relaii de motenire definite circular,
verific corectitudinea semantic i sintactic a adnotrilor formale.
Instrumente pentru reverse engineering (inginerie invers) au rolul de a reveni din fazele
de sfrit ale realizrii aplicaiei n fazele de nceput, adic actualizarea diagramelor n raport
cu modificrile efectuate n cod. Acest lucru permite dezvoltarea interactiv a unui produs
software prin bascularea ntre proiectare i implementare.
Generatorul de cod - permite transformarea n cod, ntr-un anumit limbaj de programare, a
diagramelor realizate n faza de proiectare.
Browser specializat - este instrumentul pentru vizualizarea informaiilor unei mulimi de
entiti cu structur complex, entiti ntre care exist o multitudine de relaii. El permite
accesul direct al utilizatorului la diagramele care descriu proiectele, coninute n repository i
pentru a facilita accesul la informaii dispune de opiuni de filtrare i cutare. Aceste
posibiliti fac posibil regsirea rapid a resurselor unui proiect i reutilizarea unor module n
cadrul diferitelor proiecte n curs de dezvoltare.
Generator de documentaie - conine modele de documente i ofer utilizatorului
posibilitatea de a-i concepe propriile documente n mod flexibil. Fiind legat de repository,
furnizeaz informaii la zi referitoare la proiect. Orice modificare a unei diagrame dintr-un
proiect induce modificarea automat a documentului asociat. Pot fi generate rapoarte standard
pentru monitorizarea unui proiect si pentru evaluarea informaiilor de dezvoltare, dar pot fi
realizate i rapoarte proprii ale utilizatorului.
Gestiunea configuraiei - configuraia nsemnnd proiectul aplicaiei, codul i documentaia,
toate putnd fi gestionate global. Acest lucru permite membrilor echipei de dezvoltare s
lucreze n paralel i n acelai timp s foloseasc informaia coninut n modelul global
pentru a dezvolta orice proiect nou.
Abordarea orientat pe model Etapele realizrii
Etapele realizrii
Modelul de baz al SI din depozit include descrierea funciilor, proceselor, obiectelor,
regulilor business, structurii organizaionale, pentru care pot fi utilizate modelele tip.
Modelele tip descriu configuraiile SI pentru ramuri sau tipuri de producie.
Modelul unei ntreprinderi concrete este construit sau prin alegerea unor fragmente ale
modelului de baz sau modelului tip conform particularitilor specifice ale ntreprinderii
(BAAN Enterprise Modeler), sau prin adaptarea automatizat a acestor modele ca rezultat al
unor sondaje expert (SAP Business Engineering Workbench).
Modelul construit al ntreprinderii este pstrat, sub forma unei metadescrieri, n depozit i
poate fi corectat la necesitate. n baza acestui model are loc configurarea automat i
acordarea parametrilor sistemului.
Modelul funciilor business - decompoziia ierarhic a activitii ntreprinderii.
Modelul proceselor business reflect ndeplinirea lucrrilor pentru funciile de la cel mai de
jos nivel. Pentru descrierea proceselor este utilizat modelul - Event-driven Process
Chain.
Modelele obiectelor business sunt utilizate pentru integrarea aplicaiilor, care realizeaz
diferite procese business.
Modelul structurii organizaionale a ntreprinderii - structur ierarhic, care include
departamentele i personalul.
Implementarea unui SI tip ncepe cu analiza cerinelor, care sunt stabilite la etapa de cercetare
preproiect.
Dup alegerea PP n baza modelelor de referin are loc construirea modelului preliminar al
SI, n care sunt reflectate toate particularitile realizrii SI pentru ntreprinderea dat.
Modelul preliminar servete ca baz pentru alegerea modelului tip al sistemului i
determinarea listei componentelor, care vor fi realizate utiliznd alte resurse program sau vor
solicita crearea folosind instrumentele prezente n cadrul SI tip (de exemplu, ABAP n SAP,
Tools n BAAN).
3. Proiectarea sistemului informatic
n faza de proiectare a sistemului informatic vor fi preluate specificatiile detaliate elaborate n
faza de analiz si se vor definitiva structura bazei de date, modulele si procedurile functionale,
formatele de intrare/iesire si ecranele aplicatiei.
Subetape
Arhitectura sistemului;
Proiectarea modulelor;
 Proiectarea fisierelor si a bazei de date;
Detalierea dimensiunilor sistemului;
Definirea modului de testare a sistemului;
ntocmirea documentatiei aproape de forma finala;
Revizuirea planului de dezvoltare a sistemului.
De asemenea, proiectarea este un proces predominant iterativ, cu posibilitatea revenirii pe
subetape cnd modul de finalizare a acestora nu este acceptat de catre echipa de analiza-
proiectare (figura 4).
SPT pe integrarea componentelor pot aprea probleme, generate de legarea
obiecte datorit unitii metodologice proiectului tip de un obiect concret, ceea ce
Proiecte i informaionale, poate conduce n unele cazuri la necesitatea
SI de compatibilitii tehnice i modificrii structurii organizaionale i
ramur logice economice a obiectului automatizrii
arhitectura deschis permite
utilizarea SPT pentru diferite
platforme tehnice i logice
scalabilitatea permite
configurarea SI pentru un
numr variabil de posturi
prin configurare este posibil
alegerea componentelor

Tabelul 3.3. Avantajele i dezavantajele SPT

Clasa SPT
Avantaje Dezavantaje
Realizarea SPT
SPT pe elemente abordre modular pentru cheltuieli mari de timp pentru
Biblioteci de proiectarea i documentarea SI racordarea elementelor eterogene
programe ca rezultat al incompatibilitii
orientate pe informaionale, logice sau tehnice
metode cheltuieli mari de timp pentru
revizuirea SPT pentru unele
elemente
SPT pe nivel nalt de integrare a adaptabilitate insuficient din
subsisteme elementelor punctul de vedere al ingineriei
Pachete de permite realizarea proiectrii continue a proceselor business
programe modulare, adaptarea parametric probleme n integrarea unor
aplicative a componentelor program pentru sisteme diferite, n special n cazul
diferite obiecte de gestiune utilizrii unor soluii de la
asigur diminuarea cheltuielilor productori diferii
documentare bun a proceselor
de prelucrare a informaiei

TEMA 7. Analiza i modelarea spaiului funcional al Sistemului Informaional.

7.1. Modelul busines complet. 7.2. Misiunea companiei. 7.3. Matricea responsabilitilor.
7.1.4. Modelele fluxurilor proceselor. 7.1.5. modelul structurilor de date.7.1.6. modelul
interaciunii cu mediul exterior. 7.4. abloane in modelarea companiei. 7.4.1. abloane
pentru elaborarea misiunii. 7.4.2. abloane pentru formarea afacerilor.

Ce este modelarea?- Modelarea este reprezentarea ntr-un mediu controlat, a proprietilor

i/sau fenomenelor i proceselor care caracterizeaz un obiect sau un sistem real.
 Cu alte cuvinte n modelare nu exist adevr absolut;
Modelarea presupune abstracie i aducerea n atenie numai a unor aspecte ale realitii
studiate i anume acele aspecte care prezint interes pentru modelator.
Unul din mediile controlate n care se poate reproduce realitatea, deci unul n care se
pot face modele, este calculatorul.
Modelul este o abstracie a unei entiti i aceast abstracie poate fi fcut fie pentru a crea
un model general (de referin) care s fie apoi folosit pentru a crea exemple concrete de
sisteme informatice (cazul arhitecturilor de referin), fie pentru a crea modelul informatic al
unei entiti anume, deci un model de transpunere. n cele ce urmeaz ne vom referi exclusiv
la modele de transpunere.
La crearea modelului intervine viziunea analistului despre realitatea pe care o studiaz, adic
paradigma.
Paradigma reprezint "ochelarii" prin care analistul vede sistemul informaional real, acela pe
care vrea s-l modeleze, trebuie de menionat c nu toate viziunile sau concepiile analitilor
ajung s fie considerate paradigme.

Fig. 7.1. Viziuni asupra modelrii

7.1. Modelul business complet

Construirea modelului business al companiei ncepe cu descrierea modelului interaciunii cu
mediul extern conform legii unitii i luptei contrariilor - cu definirea misiunii companiei.
Analiza organizaional conform metodei engineering - dup o schem bine determinat cu
utilizarea modelului business complet al companiei.
Compania - sistem socio-economic deschis, creat pentru atingerea anumitor obiective,
element al setului de super-sisteme externe, ierarhice deschise - piaa, instituiile statului etc.,
i subsisteme interne departamente, secii, hale, brigzi etc.
Posibilitile companiei sunt determinate de caracteristicile componentelor structurale i
modul lor de organizare.
 Fig. 7.2. Modelul business complet

Noiuni de baz din domeniul business modelrii organizaionale.

Misiunea companiei, arborele scopurilor i strategii de realizare.
Descrierea static a companiei: business-potenialul companiei, funcionalitile
companiei, zonele de responsabililate ale managementului.
Descrierea dinamic a companiei.
Modele fluxuri de procese.
Modelul business complet al companiei.
abloane ale business modelrii organizaionale.
Construirea structurii organizaionale funcionale a companiei.
Etapele elaborrii.
Cadrul normativ.
TI pentru modelarea organizaional.

7.1.1. Misiunea companiei.

Conform ISO-15704 misiunea companiei include:
Activitile desfurate de ctre organizaie n scopul ndeplinirii funciei
pentru care a fost nfiinat, oferind clienilor produse sau servicii;
Mecanismul prin care organizaia i realizeaz scopurile i obiectivele.
Misiunea - compromis ntre interesele pieei i companiei.
Este dezvoltat, pe de o parte, reieind din conjunctura pieei i poziionarea companiei n
raport cu ali membri ai mediului extern, iar pe de alt parte reieind din posibilitile
obiective ale companiei i valorile sale subiective, ateptrile proprii i principiile de care se
conduce.
Misiunea trebuie s dea un raspuns la cteva intrebri fundamentale:
Cu ce se ocup firma noastr?
Cine sunt clienii notri?
Cum va arta firma noastr n viitor?
 Cum ar trebui s fie ea in prezent?
Sunt intrebari simple in aparen, dar n realitate, sunt printre cele mai grele intrebri la care
trebuie s rspund o firm. Firmele care reuesc n afaceri i pun in permanen aceste
intrebri i caut cu foarte mare atenie raspunsuri complete la acestea.
cinci elemente distincte a misiunii.
Misiunea unei firme se defineste prin cinci elemente distincte.
Primul este istoria sa.
Cel de-al doilea element il reprezinta preferintele actuale ale proprietarilor firmei si ale
conducerii acesteia.
In al treilea rand, conjunctura pietei are o influenta importanta asupra misiunii firmei
In al patrulea rand, in functie de resursele organizatiei se hotareste care misiuni sunt
posibil de infaptuit si care nu.
In sfarsit, o organizatie trebuie sa-si stabileasca misiunea tinand cont de capacitatile
sale specifice.
Determinarea misiunii permite crearea
arborelului obiectivelor companiei - liste ierarhice de precizare si detalizare a
misiunii.
Arborelului strategiilor - liste ierarhice de precizare i detalizare a procedeelor de
atingere a obiectivelor.
La nivel corporativ - strategiile de cretere, integrare i investiii.
Blocul strategiilor business- determin strategiile de producere, de segmentare i
promovare.
Strategiile pentru resurse determin atragerea resurselor materiale, financiare, umane
i informaionale.
Strategiile funcionale stabilesc strategiile de organizare a managementului i a
etapelor ciclului de via a produciei. Tot aici sunt clarificate necesitile i obiectul
relaiilor de parteneriat (subcontractare, prestare servicii, promovare etc.).
7.1.2. Business potenialului companiei
Este Asigurarea clienilor cu produse i/sau servicii n cantiti solicitate, la locul potrivit, la
momentul de timp dorit, cu o anumit calitate i la costuri minime.
Business potenialului companiei set de activiti comerciale, direcionate spre satisfacerea
necesitilor unor segmente concrete ale pieei.
Reieind din particularitile canalelor de distribuie este format ideea iniial referitor la
structura organizatoric (sunt determinate centrele de responsabilitate comercial). Apare
nelegerea a ceea ce reprezint resursele de baz, necesare pentru reproducerea nomenclaturii
comerciale.
Potenialul business determin funciile companiei list de funcii business, funcii de
management i achiziii, necesare pentru meninerea la nivel adecvat a tuturor activitilor.
Suplimentar, mai sunt precizate resursele necesare (materiale, umane, informaionale) i
structura companiei.

7.1.3. Matricea responsabilitilor n companie

Matricea responsabilitilor n companie este un model reprezentat sub forma unui tabel
bidimensional, care stabilete sistemul de relaii ntre clasificatoare pentru toate combinaiile
lor. Construirea potenialului business i funcionalitilor companiei permite, prin utilizarea
matricei proieciilor, s fie stabilite zonele de responsabilitate a managementului
(responsabiliti comerciale, funcionale). Fixeaz responsabilitatea subdiviziunilor structurale
privind veniturile de la realizarea activitii comerciale.
Detalizarea ulterioar (prin stabilirea centrelor de responsabilitate financiar) asigur
construirea modelului financiar al companiei, care, la rndul su, permite implementarea
sistemului de management bugetar.
Pentru inceput, metoda RACI este un instrument usor de utilizat in identificarea rolurilor si
responsabilitatilor unui proces intr-o echipa.
Desi aceasta matrice ofera o imagine asupra responsabililor si responsabilitatilor, cei care le
pun in aplicare si de care depinde reusita sunt persoanele din echipa.
Este astfel util sa se descrie task-urile si responsabilul fiecaruia, pentru a nu exista
neintelegeri.

Fig.7.3. matricea responsabiliti

Matricea RACI mai poarta numele si de RASCI sau RASIC. Numele provine de la o
abreviere a termenilor din limba engleza: Responsible (Realizator), Accountable (Autoritate),
Supportive* (Sustinere), Consulted (Consultat) si Informed (Informat).
Responsible este cel care este responsabil de realizarea misiunii
Accountable cel care ii d acordul asupra proiectului si evolutiei sale, care are
autoritatea, A fiind superior lui R.
Supportive* nu este folosit mereu insa cand este nevoie, pune la dispozitie resursele
necesare si sustine implementarea.
Consulted urmeaza a fi consultat, detine informatii cu caracter de expert si
capacitatea de a ajuta la finalizarea proiectul.
Informed urmeaza a fi informat si notificat asupra rezultatelor fara a fi consultat.
Prin acest proces se pot evidentia activitatile de realizat, rolurile si se pot completa
eventualele goluri sau solutiona suprapunerile. Vertical se vor nota actiunile, sarcinile,
pe orizontal, vor fi notate entitatile sau persoanele din echipa. Apoi pentru fiecare
actiune, se va desemna un R, A, C, sau I.
Dupa cum se poate observa, A si R nu pot lipsi din nicio activitate, insa S, C si I sunt cu rol
optional. De asemenea, A si R pot fi aceeasi persoana.

Matricea Fixeaz responsabilitatea verigilor structurale pentru executarea funciilor business

la realizarea proceselor activitii
- aprovizionare,
- producere,
- realizare,
ca i a funciilor de management, asociate administrrii acestor procese
- - planificare,
- contabilitate,
- control,
- marketing,
- finane,
- management resurse umane, etc.
Detalizarea de mai departe a matricei (pn la nivelul de responsabilitate a angajailor) va
permite obinerea responsabilitilor funcionale ale personalului, care, mpreun cu o
descriere a drepturilor, obligaiunilor, i mputernicirilor va permite elaborarea pachetului de
instruciuni fie de post.
Motivele pentru care este indicata aceasta metoda sunt variate. Dintre acestea, putem
mentiona pe cele mai importante si anume:
1. Uor de utilizat. Nu necesita tehnologie speciala si costisitoare, astfel poate fi utilizata in
orice situatie, oriunde.
2. Reflecta profesionalism. Fiecare echipa sau membru al echipei are destinata o misiune,
ceva care ii scoate in evidenta calitatile, la ce are rezultate mai rapide si eficiente.
3. Imbuntire pepetu. Intotdeauna este loc de imbunatatire privind realizarea unui proiect
sau activitate si de aceea, fiecare membru trebuie sa stie unde e nevoie de aceasta.
4. Responsabilizarea echipelor i membrilor. Cteodat, membrii echipei, lucrnd cu
detalii, uita s priveasca imaginea de asamblu i i uit responsabilitile.
5. Imaginea de ansamblu. Prin aceast metod se creaz o imagine de ansamblu care poate fi
aliniat strategiilor i obiectivelor care conduc echipa.
Descrierea potenialului business, funcionalitilor i matricelor de responsabilitate
reprezint descrierea static a companiei.
n acest descriere procesle, care au loc n companie, sunt identificate, clasificate i
repartizate pe executori (viitorii stpni ai acestor procese) la un nivel general (sub form de
funcii). Este format setul de regulamente interne fundamentale i universal recunoscute ale
companiei:
Dispoziia de baz privind structura organizatorico-funcional;
Dispoziii privind activiti separate (financiar, de marketing, producere,
etc.);
Fiele de post.
Detalizarea ulterioar a modelului business are loc la etapa descrierii dinamice a
companiei la nivelul modelelor fluxurilor proceselor.

7.1.4. Modelele fluxurilor proceselor - modele, care descriu procesul de transformare

succesiv n timp a fluxurilor materiale i informaionale atunci cnd are loc realizarea unei
funcii business sau de management.
La nivelul de sus este descris logica interaciunii participanilor n proces,
La nivelul de jos tehnologia de lucru a specialitilor.

7.1.5. Modelul structurilor de date.

Determin lista i formatul documentelor, asociate proceselor companiei i stabilete
formatele de descriere a obiectelor mediului extern, a componentelor i regulamentelor
companiei.
Pentru aceasta este creat un sistem de dicionare (cataloage, clasificatoare) n baza crora sunt
elaborate seturile de documente i rapoartele necesare.
O astfel de abordare permite descrierea activitii unei companii folosind o mulime
universal de registre de management (obiectivelor, strategiilor, produselor, funciilor,
verigilor organizatorice etc.)
clasificatoare ierarhice.
 Fig. 7.4. matricea proieciilor
Este obinut prin reunirea clasificatoarelor n grupuri funcionale i fixarea elementelor
diferitor clasificatoare prin utilizarea matricei proieciilor - se produce descrierea scopuri-
procese a companiei - permite s fie obinute rspunsuri
la ntrebrile (modelul Zachman n dezvoltare)

7.4. abloane in elaborarea modelelor

7.4.1. abloane pentru elaborarea misiunii

O companie, cu mediul nconjurtor la nivel micro sau macro, reprezint o ierarhie de sisteme
deschise, subiect-orientate, imbricate reciproc. Compania este parte a pieei, pe de alt parte
i apr n lupt concurenial interesele proprii.
Misiunea este rezultatul poziionrii companiei printre participanii pieei. Din aceast cauz
nu este posibil descrierea misiunii prin analiza structurii interne a companiei. Pentru
descrierea modelului interaciunii companiei cu mediul exterior este necesar:
s fie identificat piaa (super-sistemul);
s fie determinate proprietile (necesitile) pieei;
s se determine destinaia companiei, reieind din rolul ei pe pia.
Fig. 7.5. Misiunea - compromisul ntre necesitile pieei i dorina companiei de a satisface
aceste necesiti. Cutarea compromisului poate fi organizat folosind ablonul de mai sus

Modele informaionale dependente reciproc.

Analiza organizaional - construirea unui set de modele informaionale dependente reciproc,
care include:
Modelul strategic de direcionare
Modelul funcional-organizaional
Modelul funcional-tehnologic
Modelul procesual-pe roluri
Modelul cantitativ
Modelul structurilor de date
 Fig. 7.6. Modele informaionale dependente reciproc

Recomandri la elaborarea modelului misiunii.

La elaborarea modelului misiunii companiei se recomand:
1. S se descrie baza competitivitii companiei set de caractersitici ale companiei ca sistem
social-economic.
De exemplu:
- pentru obiect originalitatea tehnologiilor i exclusivitatea resurselor (financiare,
materiale, informaionale etc.)
- pentru subiect cunotinele i aptitudinele personalului i experiena managerilor.
Aceasta determin unicitatea resurselor i aptitudinilor companiei i formeaz poziia pot.
 Baza competitivitii estimare relaiile cu Societii Civile
i structurilor guvernamentale

identificarea factorilor nsoitori

i compensatori pentru tipul misiunea
de activitate ales S se identifice
conjunctura pieei

evaluare cheltuieli i
estimare perspectivei
Estimare limitrile venituri posibile
dezvoltrii tehnologiei
legale, morale,etice
n sfera aleas

2. S se identifice conjunctura pieei (?exist cerere efectiv la bunurile i serviciile propuse i

nivelul de satisfacere a pieei de ctre concureni. Necesitile pieei, poziia trebuie).
3. S fie identificat prezena factorilor nsoitori i compensatori pentru tipul de activitate
ales din partea instituiilor statului.
4. S se estimeze perspectiva dezvoltrii tehnologiei n sfera aleas.
5. S se estimeze relaiile cu Societii Civile i structurilor guvernamentale (susinerea
posibil sau opoziia).
6. S fie estimate rezultatele acestor aciuni lund n consideraie limitrile legale,
morale,etice etc. din partea personalului (poziia vreau).
7. S fie evaluat nivelul cheltuielilor i veniturilor posibile.
Misiunea i relaiile cu mediul.

Fig.7.7. Relaii misiune mediu

S fie estimat posibilitatea realizrii unui compromis acceptabil pentru toate prile i s se
formuleze Misiunea companiei n conformitate cu ablonul de mai jos
Misiunea, n sens larg, reprezint concepia de baz a activitii companiei
 ce va obine clientul pentru satisfacerea necesitilor sale;
cine, pentru ce i cum poate fi partener al companiei;
care este baza construirii relaiilor cu concurenii (exist posibilitatea unor
compromisuri temporare?);
ce va obine proprietarul i acionarii;
ce vor obine managerii;
ce va obine personalul;
n ce const colaborarea cu Societatea Civil;
cum vor fi construite relaiile companiei cu statul.

7.4.2. abloane pentru formarea afacerilor.

n conformitate cu Misiunea companiei sunt determinate necesitile social relevante la
satisfacerea crora este direcionat businessul companiei.
n rezultat - piaa format i produsul de baz, detalizarea crora determin oferta companiei
pe partea consumatorilor

Fig.7.8. abloane pentru formarea afacerilor

Cu ajutorul matricei proieciilor (ablonul formrii afacerilor) este stabilit corespondena
ntre grupurile de produse i segmentele pieei i sunt determinate afacerile companiei (la
intersecia liniilor i coloanelor celeulele matricei).

7.4.3. abloane pentru formarea funciilor busines.

n baza listei afacerilor, cu ajutorul matricei proieciilor, este format clasificatorul funciilor
business al companiei
 Fig. 7.9. abloane pentru formarea funciilor busines.

7.4.4. abloane pentru formarea funcii administrare.

Pentru formarea funciilor de management principale sunt elaborate i aprobate
clasificatoarele Dispoziia privind componentele managementului i Dispoziia privind
etapele ciclului de management. Exemple

Fig. 7.10. abloane pentru formare funcii administrare

7.4.5. abloane pentru formarea direciilor strategice.

Zonele de responsabilitate
 Fig 7.11. abloane pentru formarea direciilor strategice

7.4.6. ablonul de descriere flux-proces.

Asigur nelegerea procesului de transformare succesiv a resurselor n produse ca rezultat al
eforturilor diferitor executori, care activeaz n baza regulamentelor.

Fig.7.12. ablonul pentru descriere flux-proces.

7.5. Abordarea organizaional-funcional.

n baza misiunii sunt formate obiectivele i strategiile companiei. Cu ajutorul lor este stabilit
setul necesar de produse i, ca i consecin resursele necesare.
Reproducerea produselor are loc datorit prelucrrii resurselor n ciclul de producie de baz.
Componentele sale formeaz business-funciile necesare pentru achiziia resurselor,
producerea i distribuirea produselor la locul de vnzare.
Pentru gestiunea procesului de reproducere este format setul de componente de management,
care genereaz o list de funcii de management.
Pentru a susine procesele de reproducere i de management sunt formate seturi de funcii de
sprijin aferente.
Aceast abordare ne permite de a descrie organizaia cu ajutorul unui set universal de
registre de management.

Modelul organizaional-funcional - Este construit n baza schemei funcionale a activitii

companiei

Fig. 7.13. Modelul organizaional-funcional

Pentru construirea modelului funcional-organizaional sunt utilizate dou tipuri de modele
elementare:
Modelele arborescente
Modelele matriceale

n baza misiunii sunt formate obiectivele i strategiile companiei. Cu ajutorul lor este
stabilit setul programat de produse i, ca i consecin resursele necesare.

MISIUNEA COMPANIEI
Domeniul de activitate
Obiectivele i strategiile
companiei
pentru acest domeniu
Setul stabilit
de produse
Resursele necesare
Pentr producere

Fig. 7.14. ciclul de producie de baz.

Producerea produselor are loc datorit prelucrrii resurselor n ciclul de producie de baz.
Componentele sale formeaz business-funciile necesare pentru achiziia resurselor,
producerea i distribuirea produselor la locul de vnzare.
Pentru gestiunea procesului de reproducere este format setul de componente de management,
care genereaz o list de funcii de management.
Pentru a susine procesele de producere i de management sunt formate seturi de funcii de
sprijin aferente.
Aceast abordare ne permite de a descrie organizaia cu ajutorul unui set universal de
registre de management.

Modelul organizaional-funcional este construit n baza schemei funcionale a activitii

companiei

Fig. 7.15. Schema funcional a activitii companiei.

Pentru construirea modelului funcional-organizaional sunt utilizate dou tipuri de modele

elementare:
Modelele arborescente
Modelele matriceale

Exemple de modele arboriscente

 Fig.8.3a. model arboriscent simplu.

Fig. 8.3b. model arboriscent desfurat.

Modelul arborescent este o list ierarhic exact ale obiectelor administrative evideniate:
- verigi organizaionale,
- funcii,
- resurse,
inclusiv mecanisme de execuie a proceselor business, documente i structura lor. Fiecare
element al unui clasificator poate fi caracterizat suplimentar cu ajutorul unor atribute: tipul,
scara utilizat, comentarii etc.
De facto, clasificatoarele reprezint un set de registre administrative, cu informaii de obicei
calitative, mulimea crora stabilete sistemul de coordonate pentru descrierea activitii
companiei.

Modele matriceale.
Modelul matriceal proiecii, care determin sisteme de relaii pentru oriice clasificatoar.
Legturile pot avea atribute suplimentare (direcie, denumire, indice, scal, greutate).
n modelul iniial (de nceput) sunt utilizate doar cteva clasificatoare ale domeniul obiectiv:
grupurile principale de produse i servicii ale companiei;
resursele de care are nevoie compania;
funciile (procesele) ndeplinite n companie;
verigile organizaionale ale companiei
Exemple Modele matriciale.

Fig. 8.4a. model simplu.

 Fig. 8.4b. model detaliat.

n clasificatorul funciilor de obicei sunt evideniate trei compartimente de baz:

funciile principale (primare) legate direct de procesul de transformare a
resurselor n produse i servicii;
funciile de management sau funciile de conducere cu ntreprinderea;
funciile de asigurare care asist activitile de producere, activiti
comercial, activiti de management, activiti de marcheting .

Funcia principal a companiei - livrarea produselor i/sau prestarea serviciilor. Din

aceast cauz mai nti are loc descrierea formal, coordonarea i aprobarea de ctre
conducerea ntreprinderii a listei afacerilor (direciilor activitii comerciale),
produselor i serviciilor. Din acest clasificator contragenilor externi trebuie s le fie
 clar prin ce este interesant compania pentru pia, iar pe plan intern cum este
motivat necesitatea unei funcii concrete.
n rezultatul acestor operaii are loc identificarea setului de funcii (funcionalul) i
este creat ontologia unitar de descriere a funciilor companiei, care va fi coordonat
cu toi managerii relevani.

7.6. Nivele de detalizare modele.

Practica uzual de construire a modelelor structurii organizaionale susine dou nivele de
detalizare:
modelul agregat;
modelul detalizat.
Modelul agregat - modelul structurii organizaionale n care registrele de eviden sunt
limitate la 2-3 nivele de detaliere.
Scopul construirii acestui model este punerea la dispoziia conducerii superioare a informaiei
despre structura organizaional pentru realizarea analizei strategice i analiza privind
corespunderea structurii date strategiei i mediului nconjurtor al companiei.
Modelul poate de asemenea fi pus la dispoziia utilizatorilor externi (de exemplu,
investitorilor poteniali sub form de ilustrare a planului business, clienilor mari .a.).
Modelul detalizat - modelul structurii organizaionale cu o detalizare mai adnc a registrelor
de eviden, dect n modelele agregate. Nivelul de detalizare este determinat de necesiti
concrete ale companiei.
Scopul: prezentarea informaiilor despre repartizarea obligaiunilor funcionale ntre
subdiviziunile companiei, ca i despre organizarea proceselor business n companie.
Permite crearea diferitor regulamente interne.
Fig.7.16. Detalizarea Compartimentelor de baz.

Dezavantajele abordrii funcionale

partiionarea tehnologiilor de executare a lucrului;
lipsa unei descrieri integre a tehnologiilor;
dificultatea reunirii celor mai simple sarcini;
lipsa responsabilitii executorilor de rezultatul final;
costuri mari pentru coordonare
lipsa orientrii spre client

7.7. Abordarea procesual.

Orice activitate sau set de activiti n care sunt utilizate resurse pentru transformarea
intrrilor n ieiri poate fi considerat proces. Definiie conform standadul ISO 9000:2000.
Pentru o funcionare rezultativ organizaiile trebuie s defineasc i s administreze
multiple procese interdependente i care interacioneaz ntre ele.
Ca regul (dar nu este obligator) ieirea unui proces formeaz intrarea altui proces.
Identificarea i managementul sistemic al proceselor utilizate n cadrul organizaiei
i, n special, interaciunile acestor procese poate fi considerat fiind abordare pe procese.
Instrumente (limbaje) utilizate pentru modelare n abordarea pe procese:
Business Process Modelling Languages (Methods):
- Process Interchange Format (PIF)
- Process Specification Language (PSL)
- MIT Handbook of Organisational Processes
- IDEF0 > IDEF3
- UMLs Activity Diagram (state diagram)
- SAP R/3: EPC
 - Petri Net
- Business Process Model, BSDM
- RAD, RACD
- Flow-Control, Data-Flow Diagram
Framework: Workflow Reference Model (WfMC)
Recently - SW version BPM: XPDL, OWL-S, BPML,
BPEL4WS, WSML

Modele de flux a proceselor

Descriu procesul de transformare succesiv a fluxurilor materiale i informaionale la
realizare a unei funcii business sau de management.
La nivelul superior este descris logica interaciunii participanilor la proces, la nivelul
inferior tehnologia de lucru a specialitilor la posturile lor de lucru.
Modelele de flux procesuale rspund la nrebrile cine-ce-cum-cui.
La moment - trecerea de la modelul funcional la modelul procesual.
Fiecare proces parcurge o serie de subdiviziuni, n ndeplinirea lui particip specialiti din
diferite secii ale companiei. Nimeni nu gestioneaz procesul propriu-zis, administrate sunt
doar subdiviziunile. Mai mult, structura companiei este construit fr a lua n consideraie
optimizarea proceselor business, care asigur funciile necesare.
Abordarea procesual deplaseaz accentele de la administrarea unor elemente structurale
separate la managementul proceselor business, care leag activitatea tuturor elementelor
structurale.
Abordarea procesual permite eliminarea fragmentrii activitilor, decalajelor
organizaionale i informaionale, dublarea, utilizarea neraional a resurselor financiare,
materiale i de personal.

Abordarea pe procese presupune:

delegarea larg a mputernicirilor i responsabilitilor utilizatorilor;
deciziile sunt luate la nivelurile de jos;
principiul managementului pe proces este combinat cu organizarea activitii n grup;
atenie sporit la asigurarea calitii;
automatizarea tehnologiilor de exectuare a proceselor business.

Principiul de baz al abordrii pe procese - Structurarea sistemului business conform

activitii i proceselor business ale organizaiei, i nu conform structurii organizaionale.
Procesele business, care asigur rezultat relevant pentru consumator, prezint valoare i
pentru specialitii, care proiecteaz SI.
Modelul procesual al companiei trebuie s fie elaborat n conformitate cu urmtoarele poziii:
Nivelul superior al modelului trebuie s reflecte doar contextul diagramei
interaciunea unicului proces contextual modelat al companiei cu lumea extern.
La nivelul 2 vor fi reflectate procesle business grupate tematic i legturile lor
reciproce.
Fiecare activitate trebuie detalizat pn la procese business.
Descrierea unei operaii business elementar are loc folosind minispecificaiile.

Abordarea pe procese Solicit:

Studierea complex a tuturor prilor vieii organzaiei bazele juridice i regulile de
activitate, structura organizaional, funciile i rezultatele executrii lor, interfeele,
asigurarea cu resurse, cultura organizaional. n rezultatul analizei este creat modelul cum
este. Cercetarea acestui model permite s se stabileasc ct de raionale sunt procesele
business, s se determine dac o operaie anume este orientat spre un produs final social
relevant sau este o procedur birocratic redundant.
La analiza P.B. sunt cercetate detaliat sferele de responsabilitate ale subdiviziunilor,
conductorilor i angajailor. Sunt stabilite coordonatele proprietarilor proceselor business,
sunt create condiii pentru dezvoltarea i implementarea sistemelor de stimulare i
responsabilitate pentru rezultatele finale, sunt determinate momentele i procedurile de
transferare a responsabilitii.
Realitatea.
O companie curat procesual este mai degrab ilustrarea organizrii corecte a activitilor.
n realitate, toate procesele business ale companiei au loc n cadrul structurii organizaionale a
ntreprinderii, care descrie competenele i relaiile funcionale.
Managementul activitilor curente are loc pe dou direcii managementul domeniilor
funcionale, i managementul proceselor business integrate.
Managementul domeniilor funcionale domeniilor, care susin mulimea proceselor business
unificate, i divizate pe operaii.
Obiectivul managementului proceselor business integrate este direcionarea i coordonarea
proceselor unificate pentru ndeplinirea comenzilor operative ale clienilor i proiectelor
proprii ale organzaiei.
Posesorii de procese.
Atunci cnd compania ncepe s se orienteze spre procese foarte important devine rolul
proprietarilor proceselor, care au tangene cu multe domenii funcionale.
Noua paradigm de activitate genereaz apariia unui numr mare de procese de management,
repartizate pe ntreaga companie (nu concentrate n uniti organizaionale specializate):
sistemul de calitate, buget, marketing .a.m.d.
Delegarea nputernicirilor, (a puterii! nu se refuz uor).
Simplificarea legturilor ntre subdiviziuni i diminuarea numrului de nivele verticale prin
care trec documentele - condiie necesar pentru realizarea reingineriei.

Elementele de baz ale abordrii procesuale.

La abordarea procesual - ntreprinderea este considerat ca un - sistem business sistem
care const dintr-o mulime de procese business legate, obiectivele finale ale crora este
producerea de bunuri sau servicii.
Procesul business - set de activiti sau lan de activiti, care creeaz rezultat cu valoare
pentru consumator, - un bun i/sau un serviciu.
Fiecare proces are Rolurile i limitele sale:
Roluri
Proprietarul procesului - persoana responsabil de mersul i rezultatele procesului n
totalitate.
Liderul echipei este - colaborator cu cunotine n domeniul procesului business.
Responsabil de executare (comunicatorul) - lucrtorul care instruiete echipa n metodele de
lucru.
Coordonatorul procesului lucrtorul responsabil cu lucrul de coordonat toate prile
afacerii.
Echipa este unul din elementele de baz ale abordrii procesuale. Exist cteva tipuri de
echipe procesuale:
Echipa situaional lucreaz de obicei n baz constant i execut un lucru periodic
repetabil.
Echipa virtual este creat pentru dezvoltarea unui produs sau serviciu nou.
Membrii echipei - specialiti de diferite nivele din ierarhie.
Manager situaional specialist, care poate ndeplini independent pn la 90% din volumul
de lucru dn proces.

Formarea echipelor procesuale. - O sarcin important a abordrii procesuale este

formarea i pregtirea echipelor procesuale i trebuie s conin:
cursuri de instruire specializate;
formare profesional (training) se nsuire a metodelor, metodicilor .a.;
testare compatibilitate psihologic a membrilor echipei;
testare aptitudini practice.
Testare aptitudinii de lucru n echip
Arborele obiectivelor - Atingerea unui set definit de obiective n rezultatul ndeplinirii
proceselor business se numete arbore al obiectivelor. Arborele obiectivelor are, de obicei,
form ierarhic.
Fiecare obiectiv are propria pondere (cantitativ sau calitativ) i propriul criteriu de
accesibilitate.
Arborele funciilor - Mulimea funciilor business reprezint decompoziia ierarhic a
activitii funcionale a ntreprinderii i se numete arbore al funciilor.
Procesele business realizeaz funciile business ale ntreprinderii. Prin funcie business
nelegem un tip de activitate a ntreprinderii.
Arborele indicatorilor - Indicatori de msurare a performanei proceselor care formeaz
arborele indicatorilor. Funciile business sunt orientate la atingerea unor indicatorii de
activitate a ntreprinderii, care formeaz arborele indicatorilor. n baza indicatorilor este
construit sistemul indicatorilor de estimare a eficacitii ndeplinirii proceslor. Proprietarii
proceselor controleaz procesele business proprii utiliznd acest sistem de indicatori.
Indicatori de msurare a performanei proceselor:
cantitatea produselor de o calitate prestabilit ntr-un anumit interval de timp;
cantitatea de resurse utilizate la poducerea acestor produse;
durata executrii operaiilor-tip,
sinecostul unei uniti de produs, .a. indicatori
Descrierea proceselor - Fiecare activitate a companiei este realizat ca proces, care are
consumatorul su: extern clientul sau inetrn colaboratorii sau subdiviziunile companiei,
care realizeaz alte procese.
La etapa descrierii sistemice a proceselor este determinat relevana fiecrui proces, inclusiv
are loc eliminarea activitilor neclare. La aceast etap sunt selectate procesele cheie.
Probleme care trebuie soluionate la descrierea proceselor:
Identificarea ntregului sistem de domenii funcionale i a proceselor
companiei, ca i legturile reciproce ntre procese.
Selectarea proceselor integrate cheie i descrierea lor la nivelul fluxurilor.
Tipuri de procese business.- Cele mai frecvente sunt urmtoarele patru tipuri de procese
business:
Procesele care creeaz cea mai mare plusvaloare;
Procesele care creeaz cea mai mare valoare pentru clieni;
Procesele cu cea mai intensiv interaciune ntre verigile de producie, care creeaz
costuri tranzacionale.
Procesele definite de standardele ISO 9000 ca fiind obligatorii pentru descrierea i
implementarea sistemului de management al calitii.
Sunt recomandate urmtoarele categorii de procese:
de baz (principale, primare);
de management;
de asigurare (auxiliare i de dezvoltare).

Fig. 7.17. Categorii de procese.

Procesele de baz. - Formeaz ciclul de via al produciei companiei. Criteriul de
eficacitate al acestor procese este calitatea, exactitatea i punctualitatea executrii fiecrei
comenzi. Procese din aceast categorie pot fi multe. Toate trebuie descrise pe lanuri
producere-comerciale:
interaciunea primar cu clientul i determinarea cerinelor acestuia
satisfacerea solicitrii (cererea pieii, comenzile clientului,contractului)
suport post-vnzare i monitorizarea satisfacerii necesitilor.
Decompoziia proceselor. pentru a reflecta ciclul de producere procesele de baz pot fi
decompuse, ca exemplu Procesul realizarea (solicitrii clientului) poate fi decompus n
urmtoarele subprocese procese de nivel mai jos:
 elaborarea (proiectarea) produciei;
achiziii (bunuri, materiale, componente);
transportarea (achiziiilor i a produciei );
descrcarea, primirea la depozit i pstrarea (achiziiilor);
producerea (conform ciclului tehnologic i logistica intern);
primirea la depozit i pstrarea (produciei finite);
start-up (lansare i ajustare);
prestare servicii (conform contractului sau individuale) .a.
Procesarea documentelor ce nsoesc procesele de producere.- La estimarea etapelor de
lucru cu un documentUtilizm analiza ciclului de via a documentului parcurs de un
specialist:
prezint datele iniiale;
pregtete, elaboreaz documentul;
completeaz;
corecteaz;
perfecteaz;
semneaz;
verific conformitatea cu cerinele stabilite;
vizeaz;
coordoneaz;
aprob;
accentueaz (referine);
pstreaz;
face o copie.
La procesare pot fi utilizate modelele de referin ale activitii unor companii analogice
procesele din firmele concurente, lider ai ramurii.
Procesele de management.- Sunt procesele, care acoper tot complexul de funcii de
management la nivelul fiecrui proces i sistemului n ntregime. Au drept obiectiv pregtirea
i adoptarea deciziei administrative.
Deciziile administrative pot fi luate pentru ntreaga organizaie, pentru un domeniu funcional
separat sau pentru procese separate, de exemplu:
management strategic;
proiectarea organizaional;
marketing;
administrare financiar-economic;
logistica i organizarea proceselor;
managementul calitii;
personalul.
O alt sistematizare posibil a proceselor de management -este legat de noiunea ciclu de
management i se bazeaz pe cinci funcii iniiale ale managementului:
planificare,
organizare,
administrare,
coordonare i
control.
ciclu de management - Orice activitate managerial se desfoar n conformitate cu ciclul
managerial care include:
colectarea informaiei;
elaborarea deciziei;
realizarea;
evidena;
controlul;
analiza;
reglarea.
Tipuri de management - n lanul resurse transformare resurse- produse i servicii - Pentru
procesul de management evideniem dou tipuri de procese asociate de management:
convenional notat
managementul resurselor
i
managementul organizrii.

Fig. 7.18. Tipuri de management n transformarea resurselor.

Executorii. - Fiecare din Tipuri de management de mai sus au executori caracteristici proprii
manageri, care pot fi divizai n trei categorii principale:
conductor (responsabil de adoptarea i organizarea ndeplinirii deciziilor);
specialist-analitic (responsabil de pregtirea deciziei i analiza devierilor);
executorii tehnici (colectarea informaiilor, evidena, comunicaiile).
La baza ciclului de management al resurselor sunt puse modelarea imitaional i controlul
calculelelor sau rezultatelor:
1. alegerea (sau receptarea de la un sistem de nivel superior) a criteriului obiectiv de
estimare a calitii deciziei;
2. colectarea informaiilor privind resursele ntreprinderii sau posibilitilor mediului;
3. calculul variantelor (pentru diferite ipoteze privind posibilele valor ale parametrilor);
4. alegerea variantei optimale adoptarea deciziei (= planului de resurse);
 5. Raportarea rezultatelor;
6. compararea cu criteriul adoptat de estimare (=controlul rezultatelor);
7. analiza cauzelor devierilor i reglarea lor (ntoarcere la 1, 2 sau 3).
La baza ciclului de management organizaional st modelarea structural sau procesual i
controlul procedural:
1. determinarea componenei lucrrilor;
2. selectarea executorilor;
3. proiectarea procedurilor;
4. coordonarea i aprobarea regulamentului de execuie;
5. raportarea despre executare;
6. controlul executrii;
7. analiza cauzelor devierilor i reglarea (ntoarcere la 1, 2 sau 3)
Procesele de asigurare- Sunt procesele destinate s asigure posibilitatea desfurrii
proceselor de baz i auxiliare i care sunt orientate spre susinerea mijloacelor universale ale
acestora. La nivelul superior de detaliere pot fi evideniate urmtoarele procese auxiliare
stadard:
asigurarea producerii;
asistena tehnic i reparaia;
asigurarea cu resurse energetice;
deservirea i reparaia cldirilor;
asigurarea tehnologic;
asigurarea metrologic;
securitatea muncii;
controlul ecologic;
asigurarea managementului;
asigurarea informaional;
asigurarea comunicaional;
asigurarea juridic;
asigurarea securitii...

7.7.1. Matricele-generatoare de procese

Pentru fiecare dintre subprocesele evideniate trebuie de asemenea s se determine, care
proces de baz sau de managemnt este consumatorul acestor servicii interne. Pentru aceasta
vor fi utilizate matricele-generatoare, care pot fi construite separat pentru procesele de baz i
procesele de management
Modele business de referin
Modele business de referin Este un model business procesual eficient, creat pentru
companii dintr-o ramur specific, pus n aplicare n practic i destinat utilizrii n
dezvoltarea / restructurarea proceselor de afaceri n alte ntreprinderi.
Scheme etalon de organizare a afacerilor, concepute pentru procese de afaceri specifice,
bazate pe experiena real de punere n aplicare n diverse companii din ntreaga lume.
Acestea includ proceduri i metode de organizare a managementului, verificate n practic.
Modele de referin permit companiilor s nceap dezvoltarea propriilor modele pe baza unui
set existent deja de funcii i procese

Modelul de referin al procesului de afaceri include un set de funcii legate logic.

Pentru fiecare funcie este specificat un executor, documentele de intrare i de ieire
sau obiectele informaionale.
Elementele (funciile i documentele) modelului de referin conin referine la
obiectele SI, precum i documente i alte informaii (manuale de utilizare,
 dezvoltatorii responsabili), situate n depozitul proiectului. De aici i numele - modelul
de referin (n englez, reference model).

Obiectivul proiectrii organizaionale

Obiectivul principal al proiectrii organizaionale este determinarea compromisului ntre
eficiena resurselor i eficacitatea proceselor.
Specializarea rigid a subdiviziunilor economisete resursele organizaiei, dar diminueaz
calitatea realizrii proceselor.
Crearea unor echipe procesuale cu specialiti proprii pentru operaiile cheie diminueaz
timpul necesar i sporete exactitatea execuiei procesului, dar cost scump.
Uneori organizaiile i pot permite alegerea acestei ci, n special n cazurile n care este
vorba despre procese cu valoare ridicat pentru care clientul este gata s plteasc.
Dar, de regul, este cutat un compromis folosind structurile matriceale procesuale.