Sunteți pe pagina 1din 97

Proiectarea sistemelor informaionale

CONINUT
1. 1.1. INTRODUCERE ...................................................................................................................................................... 3 NOIUNI DE BAZ DIN PROIECTAREA SISTEMELOR INFORMAIONALE ........................... 3 OBIECTUL I METODELE CURSULUI ....................................................................................................................... 3 SISTEME INFORMAIONALE I SISTEME INFORMATICE ........................................................................................ 3 CLASIFICRI ........................................................................................................................................................... 5 SCURT ISTORIC ...................................................................................................................................................... 7

1.1.1. 1.1.2. 1.1.3. 1.1.4. 1.2.

ETAPELE PROCESULUI DE CREARE A SI ............................................................................................... 8 FORMAREA CERINELOR ......................................................................................................................................... 9 PROIECTAREA ......................................................................................................................................................... 9 REALIZAREA I TESTAREA.................................................................................................................................... 10

1.2.1. 1.2.2. 1.2.3. 1.3.

METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE ............................................... 11 CONINUTUL METODOLOGIILOR DE REALIZARE A SISTEMELOR INFORMATICE ................................................ 11 METODE I TEHNICI DE REALIZARE A SI............................................................................................................ 11 CARACTERISTICI ESENIALE ALE PRINCIPALELOR METODE ............................................................................... 12 INSTRUMENTE CASE ........................................................................................................................................... 12

1.3.1. 1.3.2. 1.3.3. 1.3.4. 2. 2.1.

CICLUL DE VIA A PRODUSELOR PROGRAM ..................................................................................... 13 MODELE ALE CICLULUI DE VIA ......................................................................................................... 14 MODELUL CASCAD .............................................................................................................................................. 14 MODELUL SPIRAL................................................................................................................................................ 15 ALTE MODELE ........................................................................................................................................................ 16

2.1.1. 2.1.2. 2.1.3. 2.2.

PROCESELE CICLULUI DE VIA ........................................................................................................... 18 PROCESELE CONFORM ISO/IEC 12207 ........................................................................................................... 18 CONINUTUL PROCESELOR PRIMARE ................................................................................................................... 19 PROCESELE CONFORM ISO/IEC 15288 ........................................................................................................... 20 ALTE STANDARDE I REGLEMENTRI .................................................................................................................. 21

2.2.1. 2.2.2. 2.2.3. 2.2.4. 3. 3.1.

ORGANIZAREA PROCESELOR DE DEZVOLTARE A SISTEMELOR INFORMAIONALE ......... 23 PROIECTAREA CANONIC A SI .............................................................................................................. 23 ETAPELE PROIECTRII CANONICE ........................................................................................................................ 23 ANALIZA SITUAIEI I IDENTIFICAREA CERINELOR SISTEMULUI NOU ............................................................ 24 ELABORAREA CONCEPIEI SI I SARCINII TEHNICE ........................................................................................ 27 PROIECTUL TEHNIC............................................................................................................................................... 29 DOCUMENTAIA .................................................................................................................................................... 31

3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5. 3.2.

PROIECTAREA TIP ........................................................................................................................................ 31 SOLUIA PROIECT TIP .......................................................................................................................................... 32 ETAPELE REALIZRII............................................................................................................................................. 33 MODELE DE COMPONENTE ................................................................................................................................... 34

3.2.1. 3.2.2. 3.2.3. 4. 4.1. 4.2.

ANALIZA I MODELAREA SPAIULUI FUNCIONAL AL IMPLEMENTRII SI ....................... 35 MODELUL BUSINESS COMPLET AL COMPANIEI ............................................................................. 35 ABLOANELE MODELRII BUSINESS ORGANIZAIO NALE ....................................................... 38 ABLONUL PENTRU ELABORAREA MISIUNII ........................................................................................................ 38

4.2.1.

4.2.2. 4.2.3. 4.3. 4.4. 5. 5.1. 5.2. 5.3.

ABLOANE PENTRU FORMAREA AFACERILOR ...................................................................................................... 40 ABLONUL DE DESCRIERE FLUX-PROCES............................................................................................................ 43

CONSTRUIREA MODELULUI ORGANIZAIONAL-FUNCIONAL AL COMPANIEI .............. 43 MIJLOACE INSTRUMENTALE PENTRU MODELAREA ORGANIZAIONAL .......................... 49 SPECIFICAREA CERINELOR FUNCIONALE........................................................................................ 50 MODELE DE FLUX PROCESUALE ............................................................................................................. 50 ELEMENTELE DE BAZ ALE ABORDRII PROCESUALE................................................................ 52 SELECTAREA I CLASIFICAREA PROCESELOR ................................................................................ 53 TIPURI DE PROCESE BUSINESS............................................................................................................................ 53 PROCESELE DE BAZ ............................................................................................................................................ 54 PROCESELE DE MANAGEMENT .............................................................................................................................. 55 PROCESELE DE ASIGURARE.................................................................................................................................. 57 MODELUL BUSINESS DE REFERIN .................................................................................................................... 58

5.3.1. 5.3.2. 5.3.3. 5.3.4. 5.3.5. 5.4. 5.5. 6. 6.1.

ANALIZA ACTIVITII NTREPRINDERII ......................................................................................... 58 REZULTATELE ETAPEI DE ANALIZ ...................................................................................................... 61 METODOLOGIA MODELRII DOMENIULUI OBIECTIV ..................................................................... 61 MODELUL STRUCTURAL AL DOMENIULUI OBIECTIV ................................................................... 62 STRUCTURA OBIECTUAL ..................................................................................................................................... 63 STRUCTURA FUNCIONAL .................................................................................................................................. 63 STRUCTURA MANAGEMENTULUI ........................................................................................................................... 64 STRUCTURA ORGANIZAIONAL .......................................................................................................................... 64 STRUCTURA TEHNIC ........................................................................................................................................... 64

6.1.1. 6.1.2. 6.1.3. 6.1.4. 6.1.5. 6.2.

METODOLOGII ORIENTATE PE FUNCII I ORIENTATE PE OBIECTE ................................. 65 METODOLOGIA IDEF0......................................................................................................................................... 66 METODA FLUXURILOR DE DATE ........................................................................................................................... 68 METODA OBIECT-ORIENTAT .............................................................................................................................. 70 COMPARAREA METODELOR ................................................................................................................................... 72

6.2.1. 6.2.2. 6.2.3. 6.2.4. 6.3. 7. 7.1. 7.2.

METODA SINTETIC ..................................................................................................................................... 73 MODELAREA PROCESELOR BUSINESS N BPWIN ............................................................................. 75 MEDIUL INSTRUMENTAL BPWIN ........................................................................................................... 75 CONSTRUIREA MODELULUI IDEF0 ....................................................................................................... 76 OBIECTIVUL MODELRII ....................................................................................................................................... 77 TIPURI DE DIAGRAME ........................................................................................................................................... 79 TIPURI DE SGEI ................................................................................................................................................ 82 CODURILE ICOM ................................................................................................................................................. 84 SGEILE LIBERE I LEGATE................................................................................................................................ 85 TUNELAREA SGEILOR ....................................................................................................................................... 90 NUMEROTAREA ACTIVITILOR I DIAGRAMELOR.............................................................................................. 91 DIAGRAMELE ARBORELUI NODURILOR I FEO................................................................................................... 92 CHENARUL DIAGRAMEI ......................................................................................................................................... 94

7.2.1. 7.2.2. 7.2.3. 7.2.4. 7.2.5. 7.2.6. 7.2.7. 7.2.8. 7.2.9. 7.3. 7.4.

REUNIREA I DESPRIREA MODELELOR ........................................................................................ 96 CREAREA RAPOARTELOR N BPWIN .................................................................................................... 97

1. Introducere
1.1. Noiuni de baz din proiectarea sistemelor informaionale

Obiectul i metodele cursului Proiectarea sistemelor informaionale. Noiune de sistem informaional i sistem informatic. Clase de sisteme informaionale. Particularitile principale ale proiectelor SI contemporane. Etapele crerii SI: formarea cerinelor, proiectarea conceptual, specificarea aplicaiilor, modelarea, integrarea i testarea. Metode de ingineri a software n proiectarea SI. 1.1.1. Obiectul i metodele cursului Suportul de curs este direcionat spre studierea metodelor moderne i mijloacelor de proiectare a sistemelor informaionale (SI), inclusiv instrumentele CASE. Vor fi studiate componena i structura claselor SI ca obiecte de proiectare, tehnologiile moderne de proiectare a SI i metodel e de motivare a eficienei utilizrii lor, lista i coninutul etapelor proiectrii SI, particularitile etapelor n dependen de tehnologia proiectrii, scopurile i obiectivele cercetrilor preproiect, netodele de modelare a proceselor informaionale, clasificri i caracteristici generale ale instrumentelor CASE moderne. Baza tiinific a cursului este format din metodologiile analizei de sistem i modelrii, care permit soluionarea urmtoarelor probleme: asigurarea funcionalitilor solicitate ale sistemului i adaptarea la condiiile variabile de funcionare; proiectarea obiectelor, realizate n sistem; realizarea programelor i interfeelor (forme de ecran, rapoarte), care vor asigura vizualizarea rezultatelor interpelrilor la bazele de date; luarea n consideraie a mediului i tehnologiei de realizare a proiectului, i anume: topologia reelei, configurarea resurselor tehnice, arhitectura folosit, procesare paralel, procesare distribuit a datelor .a.m.d. Disciplina are ca scop familiarizarea studenilor cu tehnologiile informaionale de analiz a sistemelor tehnice mari i metodele de proiectare a SI, bazate pe standarde internaionale, nvarea principiilor construirii modelelor funcionale i informaionale, modalitil or de analiz a rezultatelor obiinute, utilizarea mijloacelor instrumentale de asistare a proiectrii SI. 1.1.2. Sisteme informaionale i sisteme informatice Din perspectiva sistemic, structura unei organizaii include trei componente principale (fig. 1.1): Sistemul de conducere sau de decizie (S.D.), Sistemul informaional (S.I.), Sistemul condus sau operaional (S.O.).

Fig. 1.1. Structura unei organizaii

Sistemul informatic face legtura ntre sistemul condus (SO) i sistemul de conducere (SD), fiind subordonat acestuia. Sistemul informatic este un ansamblu structurat de elemente intercorelate funcional pentru automatizarea procesului de obinere a informaiilor i pentru fundamentarea deciziilor. Pentru ca o organizaie s-si satisfac necesarul de informaie, are nevoie de un sistem informaional. Sistemul informaional este un ansamblu om-main care n baza cunotinelor din domeniul de activitate al organizaiei achiziioneaz, stocheaz, proceseaz i prezint informaii la nivel intra i extra organizaional. Sistemul informatic este inclus n cadrul SI, presupunnd partea automatizat a acestuia. Sistemul informaional este ansamblul de oameni, echipamente, produse program, procese i date destinate s furnizeze informaii active sistemului decizional, informaii necesare n elaborarea de soluii pentru problemele cu care se confrunt organizaia. Sistemul informaional face legatura ntre sistemul de conducere i sistemul condus i este subordonat sistemului de conducere. Sistemul informaional cuprinde ansamblul informaiilor interne i externe utilizate n cadrul organizaiei, precum i datele care stau la baza obinerii lor, procedurile de obinere i de difuzare a informaiilor, personalul implicat n culegerea, transmiterea, stocarea i prelucrarea datelor. Sistemul informaional are dou componente: componenta pentru stocarea (memorarea) informaiilor; componenta pentru prelucrarea informaiilor. s colecteze informaii din sistemele operaional i decizional precum i informaiile ce provin din mediul extern; s prelucreze informaiile la cererea sistemelor operaional i decizional; s memoreze informaiile colectate precum i informaiile rezultate din prelucrare; s asigure accesul la memorie n vederea comunicrii informaiilor stocate.

Funciile unui sistem informaional sunt:

Sistemul operaional este compus din ansamblul procedurilor i persoanelor care ndeplinesc sarcinile ce se desfoar ntr-o organizatie. n cadrul acestui sistem are loc implementarea i realizarea strategiilor organizaiei. Sistemul informatic este acea parte a sistemului informaional, care cuprinde culegerea, prelucrarea i transmiterea automat a datelor i informaiilor din cadrul sistemului informaional. Prin implementarea unor modele matematice i utilizarea tehnicii electronice de calcul, sistemul informatic imprim valene sporite sistemului informaional sub aspect cantitativ i calitativ. Are loc creterea capacitii de calcul sub aspectul volumului datelor prelucrate i a operaiilor efectuate, nsoit de creterea exactitii informaiilor, sporirea operativitii i complexitii situaiilor de informare - raportare. Toate aceste aspecte determin o apropiere mai mare a decidentului de fenomenele i procesele economice pe care acesta le are n atenie, cu multitudinea aspectelor economice pozitive ce deriv din acestea. Sistemul informatic tinde spre a egala sistemul in formational, ns acest lucru nu va fi posibil datorit limitelor sistemului informatic. Tot timpul n cadrul sistemului informaional vor exista o serie de activiti ce nu vor putea fi automatizate. Ins (atenie!), dac acceptm includerea n sfera sistemului informatic a activitii de conducere a proceselor tehnologice cu ajutorul calculatoarelor de proces, putem asista la automatizarea complet a procesului decizional i a reglrii automate a procesului tehnologic. ntr-o astfel de situaie, sistemul informatic depete sfera sistemului informational. Caracteristicile sistemului informatic: orice sistem trebuie s conin ca element central o baz de date (BD), n care s fie stocate date intercorelate intre ele provenind de la surse interne i externe; informaiile furnizate de sistem trebuie obigatoriu s fie autentice, exacte, iar suportul de prezentare s varieze de la un nivel de conducere la altul;

sistemul trebuie s nglobeze o varietate de modele matematice, tehnico-economice (modele de optimizare, modele de simulare, modele de eficien), etc.; sistemul trebuie conceput ca un sistem om-main oferind astfel posibilitatea unei interaciuni imediate ntre utilizator i sistem; sistemul trebuie s prezinte un grad ct mai ridicat de integrare sub urmtoarele dou aspecte: integrare intern i integrare extern.

1.1.3. Clasificri Diversitatea problemelor rezolvate cu ajutorul SI a dus la apariia unor multiple tipuri de sisteme, diferena constnd n principiile de creare i modalitatea de prelucrare a informaiilor. Clasificarea de mai jos are la baz cele mai semnificative caracteristici care definesc posibilitile funcionale i particularitile de construire a sistemelor moderne. n funcie de tipul datelor, nivelul automatizrii, sfera utilizrii, mijloacele tehnice utilizate, modul de funcionare a organizaiei etc., sistemele informaionale pot fi mprite n mai multe grupuri sau clase (fig. 1.2).

Fig. 1.2. Clasificarea sistemelor informaionale Conform tipului de date pstrate, SI se mpart n factografice i de procesare a documentelor. Sistemele factografice sunt destinate pstrrii i procesrii datelor structurate de tip numeric i texte. Asupra acestor date pot fi executate diferite operaii. n SI de procesare a documentelor informaia este prezent sub form de documente, care constau din denumiri, descrieri, referate i texte. Cutarea n cadrul datelor nestructurate are loc cu utilizarea caracteristicilor semantice. Funciile principale ale unor asemenea sisteme constau n punerea la dispoziia utilizatorului a documentelor selectate, iar prelucrarea datelor are loc ntr-o msur nesemnificativ. n conformitate cu nivelul de automatizare a proceselor informaionale SI se mpart n sisteme cu prelucrare manual, automat i automatizat. n sistemele cu prelucrare manual mijloacele tehnice de procesare a informaiei sunt lips, iar toate operaiile sunt ndeplinite de oameni. n sistemele cu prelucrarea automat a informaiilor toate operaiile sunt executate fr participarea omului. Sistemele cu procesare automatizat presupun participarea i a omului, i a mijloacelor tehnice ,

rolul principal n execuia operaiilor de rutin aparinnd calculatorului. Observm, c aceast ultim categorie de sisteme corepsunde noiunii de sistem informaional. n dependen de caracterul prelucrrii informaiei SI se mpart n sisteme n care sunt preponderente operaiile de cutare i sisteme n care prevaleaz calculele. Primele realizeaz introducerea, sistematizarea, pstrarea, extragerea informaiei la solicitarea utilizatorului fr transformri prea complicate a datelor. Din aceast categorie sunt sistemele informaionale bibliotecare, sistemele de rezervare i vnzare a biletelor sau camerelor de hotel etc. n sistemele din categoria a doua, suplimentar, sunt prezente n mare msur operaiile aritmetice sau logice de prelucrare a informaiei. n dependen de modul de utilizare a informaiei la ieire SI se mpart n sisteme de gestiune i sisteme de asistare a procesului de luare a deciziilor. Informaia rezultant din sistemele de gestiune este transformat direct n aciuni ale omului sau chiar ale sistemului. Pentru aceste sisteme sunt caracteristice sarcini cu calcule numerice i prelucrarea unor cantiti mari de date . Ca exemplu, pot fi menionate SI de planificare a produciei sau a comenzilor, sistemele de eviden contabil. Sistemele de asistare a procesului de luare a deciziilor produc informaii, care sunt acceptate de om i pot fi luate n consideraie la formarea deciziilor, fr a iniia n mod obligator aciuni concrete. Din aceast clas fac parte sistemele, care imit procesele intelectuale de prelucrare a cunotinelor, de exemplu sistemele expert. n dependen de sfera de utilizare exist urmtoarele clase ale SI: SI de gestiune organizaional sunt destinate automatizrii funciilor personalului de conducere a ntreprinderilor industriale, dar i a obiectelor din sfera prestrii serviciilor (hoteluri, bnci, etc.). Funciile principale ale acestor sistem e sunt: controlul operativ i reglarea, evidena operativ i analiza, planificarea operativ i de perspectiv, evidena contabil, gestiunea vnzrilor sau/i achiziiilor i alte sarcini economice sau organizaionale. SI de gestiune a proceselor tehnologice automatizeaz funciile personalului responsabil de executarea operaiilor tehnologice. n aceste sisteme sunt prezente mijloace performante de msurare a parametrilor proceselor tehnologice (temperatura, presiunea, componena chimic etc.), proceduri de control al valorilor parametrilor i de reglare a proceslor tehnoloigce. SI de proiectare asistat de calculator (CAD Computer Aided Design) automatizeaz funciile inginerilor proiectani, constructorilor, arhitecilor, design er-ilor care creaz tehnologii sau dispozitive tehnice noi. Fuciile principale ale acestor sisteme sunt executarea calculelor inginereti, crearea documentaiei de proiect, incluisv documentaia grafic (scheme, desene, planuri), modelarea obiectelor proiectate. SI integrate (corporative, SIC) sunt utilizate pentru automatizarea tuturor funciilor unei companii i acoper ntreg ciclul de lucrri de la planificarea activitii pn la livrarea produciei. SIC includ o serie de module (subsisteme), care funcioneaz ntr-un spaiu informaional unitar i ndeplinesc funciile de susinere a direciilor de activitate. Sarcinile tipice realizate de modulele SIC sunt prezentate n tabelul 1.1. Tabelul 1.1. Destinaia funcional a modulelor SIC Subsistemul marketing
Cercetarea pieei i prognoza vnzrilor Gestiunea vnzrilor

Subsistemele producere
Planificarea volumelor de lucru i elaborarea planurilor calendaristice Controlul operativ i gestiunea produciei

Subsistemele eviden financiar


Administrarea portofoliului de comenzi Managementul politicii de creditare

Subsistemul evidena resurselor umane


Analiza i prognoza necesitilor n resurse umane Meninerea arhivei de personal

Alte subsisteme
Controlul activitii companiei Depistarea problemelor operative

Recomandri privind produsele noi

Analiza modului de funcionare a echipamentelor

Elaborarea planului financiar Analiza financiar i prognozarea Gestiunea bugetului, evidena contabil i calcularea salariului

Analiza i planificarea pregtirii cadrelor

Analiza situaiilor de gestiune operativ i strategic Asigurare elaborare soluii strategice

Analiza i stabilrea Participare la formarea preurilor comenzilor clienilor Evidena comenzilor Gestiunea stocurilor

Analiza situaiei curente a pieei sistemelor informaionale demonstreaz o tendin stabil de cretere a cererii n SI corporative. n special, se observ o cretere substanial la sisteme integrate, automatizarea unor funcii separate fiind considerat etap trecut de multe organizaii. n tabelul 1.2 este prezentat lista unor produse program populare, la moment sisteme informaionale de gestiune organizaional. Tabelul 1.2. Clasificarea pieei sistemelor informaionale Sisteme locale

Sisteme integrate mici


Concorde XAL Exact NS-2000 Platinum PRO/MIS Scala SunSystems - 1C-

Sisteme integrate medii


Microsoft-Business Solutions - Navision, Axapta J D Edwards (Robertson & Blums) MFG-Pro (QAD/BMS) SyteLine (COKA/SYMIX)

Sisteme integrate mari (corporative)


SAP/R3 (SAP AG) Baan (Baan) BPCS (ITS/SSA) OEBS (Oracle EBusiness Suite)

n dependen de nivelul la care sunt utilizate SI pot fi mprite n operaionale, pentru


specialiti, pentru management, de nivel strategic. SI de nivel operaional sprijin executorii procesnd date despre tranzacii i evenimente (conturi, facturi, salarii, credite, materii prime i materiale). Aceste sisteme realizeaz legtura ntre companie i mediul extern. La acest nivel sarcinile, obiectivele, sursele de informaii i algoritmii de procesare sunt cunoscui apriori i n mare msur sunt bine structurai. SI pentru specialiti sprijin prelucrarea datelor i cunotinelor, sporesc performana inginerilor i proiectanilor. Sarcina acestor sisteme este obinerea i integrarea informaiilor noi n organizaie i acordarea ajutorului n prelucrarea documentelor pe hrtie. SI pentru nivelul managementului sunt folosite de lucrtorii din veriga medie de conducere pentru monitorizare, control, adoptare a deciziilor i administrare. Funciile principale: compararea indicatorilor cureni cu cei istorici, elaborarea unor rapoarte periodice pentru anumite intervale de timp, asigurarea accesului la informaia din arhive etc. SI de nivel strategic susin procesul de luare a deciziilor pentru realizarea obiectivelor strategice de dezvoltare a organizaiei. SI de nivel strategic sprijin managementul superior n rezolvarea problemelor nestructurate, n planificarea pe termen lung. Sarcina principal a acestor sisteme este s asigure posibilitatea comparrii schimbrilor care au loc n mediul extern cu potenialul firmei, s asiste procesul de luare a deciziilor n situaii complicate. Din punctul de vedere al realizrii tehnice i logice pot fi evideniate cteva arhitecturi tip: arhitectura tradiional file-server sau servere ale BD (client-server), arhitectura SIC, bazat pe tehnologia Internet (aplicaii Intranet), arhitectura bazat pe depozite de date (Data Warehouse). 1.1.4. Scurt istoric

Industria sistemelor informaionale automatizate i are nceputurile n anii 1960, iar spre finele secolului XX a cptat forme bine conturate. La prima etap metoda principal de proiectare a SI era metoda de jos - n sus (bottom-up) conform creia sistemul era creat ca un set de aplicaii, importante la moment, pentru susinerea activitii ntreprinderii (automatizarea insular). Scopul principal al acestor proiecte nu era crearea unor produse reutilizabile (tirajate), ci satisfacerea necesitilor curente ale unei ntreprinderi concrete. Aceast abordare mai poate fi ntlnit, chiar dac mai rar, i astzi. n cadrul automatizrii insulare la un nivel relativ bun este asigurat susinerea unor funcii, ns practic lipsete strategia automatizrii complexe, iar combinarea unor subsisteme funcionale devine o problem separat, adesea foarte complicat. Prin crearea departamentelor de automatizare ntreprinderile au ncercat s rezolve problemele cu fore proprii. ns modificrile permanente ale proceselor tehnologice, procedurilor de lucru i a instruciunilor asociate, dificultile legate de modul de abordare a acelorai date de utilizatori diferii, conduceau la necesitatea perfecionrii continue a produselor program pentru satisfacerea solicitrilor beneficiarilor. n consecin, att lucrul programatorilor, ct i sistemele informaionale create generau nemulumirea conducerii i a utilizatorilor sistemului . Urmtoarea etap este legat de contientizarea faptului, c exist necesitatea n m ijloace relativ standardizate de automatizare a activitii diferitor ntreprinderi i organizaii. Din ntreg spectrul de probleme au fost evideniate cele mai vizibile: automatizarea evidenei contabile i a proceselor tehnologice. Sistemele au nceput a fi proiectate de sus-n jos (top-down), presupunnd c o aplicaie trebuie s satisfac necesitile mai multor utilizatori. Ideea utilizrii unui program universal introduce constrngeri substaniale privind posibilitile dezvoltatorilor de sisteme la formarea structurii bazei de date, formelor de ecran sau alegerea algoritmilor de calcul. Cerinele rigide, impuse de sus, diminueaz posibilitile de adaptare flexibil a unui sistem, realizat pentru o ntreprindere oarecare, la activitile specifice ale unei alte ntreprinderi cnd trebuie s se ia n consideraie particularitile evidenei analitice i tehnologice, procedurile proprii de prelucrare a datelor, individualizarea interfeei pentru fiecare post de lucru innd cont de funciile, tehnologiile i drepturile unui utilizator concret. La toate acestea se mai adaug faptul, c clienii naintau tot mai multe cerine, generate de necesitatea crerii unor sisteme integrate de management i de planificare a activitii ntreprinderii. Astfel a aprut necesitatea stringent de formare a unei metodologii noi n proiectarea sistemelor informaionale. Scopul acestei metodologii este de a reglementa procesu l de proiectare a SI i de a asiguara gestionarea acestui proces, pentru a garanta conformitatea cu cerinele referitoare att la sistem, precum i la caracteristicile procesului de dezvoltare. Principalele obiective , care trebuie atinse prin noua metodologie, sunt urmtoarele: s se asigure crearea de SI corporative, n concordan cu scopurile i obiectivele organizaiei, precum i cu cerinele pentru automatizarea proceselor business; s se garanteze crearea unui sistem cu calitatea solicitat, n intervalul de timp specificat i cu un buget de proiect stabilit; s fie facilitat procesul de mentenan, modificare i extindere a capacitilor sistemului; s fie asigurat continuitatea dezvoltrii, adic utilizarea n SI a infrastructurii informaionale existente.

Implementarea unei astfel de metodologii ar mai trebui s conduc la diminuarea nivelul ui de complexitate a procesului de creare a SI din contul descrierii mai complete i mai exacte a acestui proces, dar i utilizrii metodelor i tehnologiilor moderne de creare pe ntreg ciclul de via a SI de la concepere pn la exploatare.

1.2.

Etapele procesului de creare a SI

Proiectarea SI acoper trei domenii de baz: proiectarea obiectelor, care vor fi realizate n baza de date; proiectarea programelor, formelor de ecran, rapoartelor, care vor asigura vizualizarea rezultatelor interpelrilor la baza de date; luarea n consideraie a mediului concret sau tehnologiei, i anume: topologia reelei,

configuraia resurselor tehnice, arhitectura (file-server, client-server), procesarea paralel sau distribuit a datelor, etc. Proiectarea SI ncepe cu determinarea obiectivelor proiectului. La nivel general obiectivul proiectului poate fi soluionarea unui set de probleme interdependente, set care include la momentul lansrii sistemului i pe ntreaga perioad de exploatare urmtoarele: funcionalitatea dorit a sistemului i adaptabilitate la schimbarea condiiilor de funcionare; productivitate solicitat; timp de rspuns acceptabil; fiabilitate i lipsa cderilor; nivel suficient de securitate; simplitate n utilizare i ntreinere. Conform metodologiei moderne, procesul crerii SI include crearea i transformarea succesiv a unui ir de modele coordonate pe etapele ciclului de via a sistemului. La fiecare etap sunt create modele specifice etapei de organizare, referitoare la cerine ctre proiect, sistem sau aplicaii, etc. Modelele sunt create de ctre grupurile de lucru din cadrul echipei proiectului, sunt acumulate i pstrate n depozitul (repozitoriul) proiectului. Crearea modelelor, verificarea i validarea lor, prezentarea pentru utilizare colectiv are loc folosind instrumente program speciale mijloace CASE (Computer Aided Software Engineering). Procesul de creare a SI include o serie de etape (stadii), limitate n timp i care au drept finalitate crearea unui produs concret model, program, documentaie etc. Sunt evideniate urmtoarele etape de creare a SI: formarea cerinelor sistemului, proiectarea, realizarea, testarea, implementarea, exploatarea i mentenana. Ultimile dou etape sunt n afara prezentului curs. 1.2.1. Formarea cerinelor Etapa de nceput const n modelarea proceselor business, care au loc n organizaie i care realizeaz scopurile i obiectivele acesteia. Modelul organizaiei, descris n termeni de procese i funcii business, permite formularea cerinelor principale ctre sistem . Acest moment fundamental al metodologiei asigur obiectivitatea procesului de identificare a cerinelor. Mulimea modelelor de descriere a cerinelor este apoi transformat ntr-un sistem de modele, care descriu proiectul conceptual al SI. Sunt formate modelele arhitecturale ale SI, 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 etapelor de nceput, care au loc la faza de analiz a activitii organizaiei, este formarea cerinelor sistemului, care s reflecte corect i exact scopurile i obiectivele organizaiei-client. Pentru a specifica procesul de creare a SI, care satisface necesitile organizaiei, trebuie de clarificat i de formulat explicit aceste necesiti. n acest scop trebuie identificate cerinele clientului ctre SI i reflectarea lor n limbajul modelelor de elaborare a proiectului SI asigurnd conformitatea cu scopurile i obiectivele organizaiei. Formarea i formularea cerinelor este una din sarcinile cele mai responsabile, dificil de formalizat i extrem de complicate i costisitoare n cazul unor erori. Mijloacele instrumentale i produsele program contemporane permit crearea relativ rapid a SI dac cerinele sunt prezente. Dar adesea aceste sisteme nu satisfac clienii, solicit o mulime de perfecionri, ceea ce conduce la creterea brusc a cheltuielilor. Cauz princial a acestei situaii este identificarea incorect sau incomplet a cerinelor la etapa de analiz. 1.2.2. Proiectarea La etapa proiectrii sunt create, n primul rnd, modelele datelor. n calitate de informaii iniia le proiectanii folosesc rezultatele analizei. Crearea modelului logic i modelului fizic al datelor este partea principal la proiectarea bazei de date. Modelul informaional, obinut la etapa de analiz, este transformat mai nti n modelul logic, apoi n modelul fizic al datelor.

Paralel cu proiectarea schemei BD are loc proiectarea proceselor n scopul obinerii specificaiilor (descrierilor) tuturor modulelelor SI. Aceste dou procese de proiectare sunt strns legate, or o parte a logicii-business de obicei este realizat n cadrul bazei de date (constrngeri, triggere, proceduri ncorporate). Scopul principal al etapei de proiectare a proceselor const n transformarea funciilor, identificate la etapa de analiz, n module ale SI. n cadrul proiectrii modulelor sunt stabilite interfeele programelor: formatul meniului, forma ferestrelor, tastele fierbini i apelurile associate, etc. Ieirile etapei de proiectare sunt: schema bazei de date (prin utilizarea modelului entitate-relaie (ER), creat la etapa de analiz); specificaiile modulelor sistemului (construite n baza modelelor funciilor). Suplimentar, la etapa de proiectare are loc elaborarea arhitecturii SI, care include n acest caz alegerea platformei/platformelor i a sistemului/sistemelor de operare. ntr-un SI eterogen calculatoarele pot funciona pe diferite platforme hard i sub comand a diferitor sisteme de operare. Tot aici sunt cutate rspunsuri referitor la urmtoarele caracteristici ale arhitecturii: tipul arhitecturii (file server sau client server(?)); numrul de nivele (2 sau 3 nivele(?): clientul, serverul BD, serverul aplicaiilor); tipul BD - centralizat sau distribuit? n ultimul caz, vor fi alese mecanismele de coordonare i actualizare utilizate; omogenitatea BD: omogen - serverele BD de la acelai productor sau eterogen? n ultimul caz, care va fi modalitatea (produsele program) de asigurare a schimbului de date?; paralelism: vor fi sau nu utilizate servere BD paralele pentru sporirea productivitii ?, etc. Etapa de proiectare se incheie cu elaborarea proiectului tehnic al sistemului informaional. 1.2.3. Realizarea i testarea La 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 (cderi fatale); stabilirea nivelului de corespundere specificaiilor (dac sunt prezente toate funciile necesare, dac nu exist funcii redundante). Dac testarea autonom trece cu succes, modulul este inclus n componena prii finalizate a sistemului i grupul modulelor realizate sunt supuse testrii legturilor, care urmrete verificarea corectitudinii influenelor reciproce. Urmeaz testarea fiabilitii grupului de module cnd: sunt imitate situaiile de refuz n funcionare; este determinat timpul mediu dintre dou cderi succesive (MTBF- Mean Time Between Failures). Primul grup de teste stabilete ct de bine sistemul se restabilete dup cderile resurselor program sau tehnice. Al doilea grup determin gradul de stabilitate al sistemului n regim standard de lucru i permite determinarea valorii timpului mediu de bun funcionare. n setul de teste la stabilitate sunt incluse teste, care imit sarcina de vrf la care poate fi supus sistemul. Apoi ntreg setul de module este supus testelor de sistem testarea pentru acceptarea intern a produsului, care indic nivelul lui de calitate. Aici sunt incluse teste de funcionalitate i de fiabilitate. Ultima testare o reprezint testarea de acceptare (de primire-predare). Sistemul informaional este prezentat beneficiarului, iar testarea va include un grup de teste, care modeleaz procesele business reale, pentru a demonstra conformitatea produsului realizat cu cerinele tehnice. Necesitatea monitorizrii procesului de creare a sistemelor informaionale, garantrii realizrii

obiectivelor proiectului i respectarea diferitor constrngeri (bugetare, de timp, etc.) a condus la utilizarea larg a metodelor i mijloacelor ingineriei software: analiza structura l, modelarea obiect-orientat, instrumente CASE.

1.3.

Metodologii de realizare a sistemelor informatice

Realizarea sistemelor informatice reprezint o aciune complex, care mbin un numr mare de activiti: analiz, proiectare, implementare, exploatare [2]. n plus, reclam resurse umane, materiale i financiare nsemnate, pe o perioad considerabil de timp. Folosirea eficient a acestor resurse, n scopul obinerii unui sistem informatic performant a impus ordonarea acestui proces complex, ntr-o succesiune bine stabilit de etape i subetape i utilizarea unor metode i tehni ci adecvate. Acest lucru a dus la conturarea unor metodologii de realizare a sistemelor informatice. 1.3.1. Coninutul metodologiilor de realizare a sistemelor informatice Metodologiile de realizare a sistemelor informatice cuprind [2]: modalitatea de abordare a sistemelor pentru elucidarea raportului dintre variaiile sistemului i dinamismul su; regulile de formalizare a datelor i proceselor de prelucrare; instrumentele pentru concepia, realizarea i elaborarea documentaiei; modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul de viat); definirea modului de lucru, rolului analitilor i proiectanilor i a raportului dintre ei; modalitile de administrare a proiectului (planificare, programare, urmrire). Totodat, metodologiile au rolul de a indica modul de desfurare a acestui proces, stabilind [2]: componentele procesului de realizare a sistemului informatic (etape, subetape, activiti, operaii) i coninutul lor; fluxul parcurgerii (executrii) componentelor; metodele, tehnicile, procedeele, instrumentele, normele si standardele utilizate. n funcie de modul de abordare i domeniul de aplicabilitate, metodologiile utilizate sunt: metodologii din domeniul gestiunii: AXIAL (firma IBM), MERISE (Ministerul industrieiFranta), IE (James Martin), SSADM (Marea Britanie); metodologii orientate obiect: OMT (General Electric -SUA), OOD (Michael Jackson); metodologii pentru conducerea proiectelor de sisteme informatice: SDM / S, METHOD/ 1 Arthur Andersen, NAVIGATOR (Ernst & Young - James Martin). 1.3.2. Metode i tehnici de realizare a SI La realizarea SI se utilizeaz metode, tehnici, instrumente i procedee de lucru. Metodele utilizate n proiectarea SI reprezint modul unitar sau maniera comun n care analitii de sisteme, programatorii i alte categorii de persoane implicate, realizeaz procesele de analiz a sistemului informaional-decizional existent, de proiectare i de introducere a sistemului nou. Metoda are un caracter general, n cadrul ei aplicndu -se anumite tehnici de lucru [2]. Tehnicile de lucru utilizate n proiectarea SI reprezint felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea problemelor ce apar n procesul de proiectare. Prin aceste tehnici se mbin armonios cunotinele despre metode cu miestria personal a celor chemai s aplice metodele si s utilizeze instrumentele adecvate. Utilizarea metodelor, tehnicilor, instrumentelor i procedeelor de lucru n proiectarea SI se face n conformitate cu o serie de principii i n limita un ei metodologii de lucru, care se adopt n funcie de situaia real la care se refer. n abordrile incipiente se lucra cu probleme izolate. Ulterior s-a efectuat trecerea la abordarea sistemic, odat cu abordarea funcional sau, mai bine zis, cu analiza i decompoziia funcional (n fiecare modul exist cte o funcie) pn la abordarea orientat-obiect [2]. Pe parcurs s-au impus dou strategii de abordare i anume: strategia top down (de sus n jos); strategia bottom up evolutiv (de jos n sus).

n strategia top down abordarea general este divizat n uniti componente prin rafinri repetate, metoda de proiectare putnd fi descris sub forma unei diagrame ierarhice cu module de control pe nivele superioare i cu module detaliate pe nivelele inferioare. Structura organizatoric a unei uniti economico-sociale numit organigrama unitii poate fi reprezentat printr-o astfel de diagram ierarhic. n strategia bottom up evolutiv, se pornete de la o tratare minimal care se extinde treptat pe msura naintrii n realizarea sistemului. n practic, de cele mai multe ori se utilizeaz o combinare a celor dou strategii. Metodele de abordare a SI pot fi grupate prin prisma celor mai muli autori astfel [1]: metode orientate spre funcii, numite i metode ale descompunerii funcionale; metode orientate spre fluxuri de date sau orientate spre procese, deoarece diagramele fluxurilor de date se ntrebuineaz pentru descrierea proceselor; metode orientate spre informaie sau date, orientate-informaii, aprute ca urmare a popularizrii puternice a ingineriei informaiei a lui JAMES MARTIN, dar i a diagramelor entitate-relaie ale lui CHEN [3]; metode orientate-obiect. 1.3.3. Caracteristici eseniale ale principalelor metode Informaia este vzut de DeMarco n 1982, ca fiind posibil de abordat prin trei perspective specifice sistemelor informaionale sau prin trei dimensiuni: date, funcii, comportament. Datele sunt surprinse din prisma structurii lor sub form de atribute i nseamn de fapt, ceea ce are stocat i reflect structura static [1]. Funciile scot n eviden n mod limitat ceea ce face sistemul. El poate fi vzut i ca un proces, ntruct elementele sistemului despre care se pstreaz datele de rigoare sunt supuse unor transformrii funcionale, prin intermediul proceselor [1]. Comportamentul este invocat pentru a reda o alt modalitate de percepie a sistemului, influena evenimentelor i proprietilor sistemului, i sugereaz dinamica lui [1]. Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm pe civa cum ar fi DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Marco&Gowan, Warnier-Orr, Dahl. Descompunerea funcional este cea care anun apariia proiectrii i analizei structura le. Fiecare funcie este descompus n subfuncii, pn se obin structuri uor de transpus n instruciunile limbajelor de programare. Prin metoda fluxurilor de date (orientat-proces) analitii efectueaz reprezentarea lumii reale prin simboluri care reprezint fluxul datelor, transformrile datelor, stocarea datelor, entiti externe, etc. Metoda orientat-proces are un mare grad de asemnare cu descompunerea funcional. n cadrul metodei orientate spre informaii (orientate-date) dou realizri importante n domeniu au dat tonul unei orientri n abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaie, de ctre Peter P. Chen (1976) i ingineria informaiei, n viziunea lui James Martin. Metoda orientat-obiect constituie o categorie particular a metodelor de dezvoltare software, care privesc construirea sistemelor n care clasa reprezint unitatea arhitectural fundamental. Clasa este o grupare logic a obiectelor care au aceeai structur i un comportament similar. 1.3.4. Instrumente CASE Problema CASE-ului (Proiectarea Sistemelor/Programelor asistat de calculator sau cu Ajutorul Calculatorului Computer Aided Systems Engineering) a devenit foarte important la mijlocul anilor 1980, cnd resursele tehnice s-au extins prin seria PC-urilor, iar reelele au devenit mai puternice, constituindu-se sistemele distribuite. Obiectivul principal al CASE-ului l constituie 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, reprezint elementele forte ale instrumentelor CASE, chiar dac n ultimii ani CASE a acordat atenia cuvenit analizei, proiectrii i programrii orientate pe obiecte [1]. Majoritatea produselor soft au fost construite n mod artizanal, fr posibilitatea testrii complete a lor, fiind nsoite de o documentaie slab. Instrumentele CASE implic utilizarea calculatorului ca mijloc de susinere a activitilor de planificare, definire, proiectare i realizare a softului. Ele se bazeaz pe logica structural, pe descompunerea funcional i reprezentarea prin diagrame a fluxurilor de date ale aplicaiilor. Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a ncuraja abordarea logicii structurale i pentru folosirea calculatorului ca un mod de tezaurizare a lucrrilor i ca o planet de desen, pe care pot fi plasate reprez entrile structurate ale sistemelor sau aplicaiilor. Pe msura evoluiei lor, sistemele CASE au devenit mult mai complexe, permind ca procesele de proiectare i realizare a aplicaiilor s se desfoare ntr-un mediu informatic interactiv, oferind utilizatorilor un ntreg arsenal de instrumente i proceduri, prin care pot proiecta, realiza, testa, documenta, ntreine, actualiza i exploata sistemul. Utilizarea produselor de tip CASE a fost determinat de [1]: calitatea ndoielnic a aplicaiilor realizate n mod tradiional; frustrarea utilizatorilor n ncercarea lor de a participa la procesul de proiectare i realizare a aplicaiilor, datorit nivelului ridicat de cunotine informatice solicitate de metodele tradiionale; costuri deosebit de mari pe care le presupun ntreinerea i actualizarea softului funcional; imposibilitatea rezolvrii tuturor cerinelor utilizatorilor; limitarea posibilitii de reprezentare grafic a schemelor de realizare a noilor proiecte. Folosirea sistemelor CASE este motivat i 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 nivelului de integrare; consolidarea disciplinei de proiectare; oferirea unei interfee de proiectare; folosirea depozitelor modularizate; salvarea i refolosirea unor componente din diagramele realizate; simplificarea activitilor de proiectare i realizare a sistemelor/aplicaiilor. Utilizarea sistemelor CASE a nceput cu introducerea diagramelor fluxurilor de date, care fac posibil realizarea unui model al derulrii proceselor sistemului/aplicaiei care se proiecteaz. A urmat folosirea dicionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicaia. Au aprut ecranele predefinite pentru a prezenta ce poate s obin utilizatorul prin exploatarea sistemului. S-a apelat la facilitile grafice, care pot folosi simbolurile log icii structurale i care permit proiectantului s realizeze o diagram coerent a fluxurilor de date [1].

ntrebri de control
1. Care este tipul datelor prelucrate n SI factorafice?

2. Ciclul de via a produselor program


Noiune de ciclu de via. Procesele ciclului de via: principale, auxiliare, organizaionale. Coninutul i legturile reciproce ntre procesele ciclului de via. Modele ale ciclului de via: cascad, cu control intermediar, spiral. Stadiile ciclului de via. Standarde. Metodologia proiectrii sistemelor informaionale descrie procesul crerii i mentenanei sistemelor

prin intermediul ciclului de via a SI, prezentndu-l ca o succesiune de etape i procese, care sunt 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 .a.m.d. Aceast descriere formal a vieii SI permite planificarea i organizarea procesului de elaborare colectiv i asigur administrarea acestui proces. Ciclul de via poate fi privit ca un ir de evenimente, care se produc n procesul crerii i exploatrii sistemului.

2.1.

Modele ale ciclului de via

Modelul ciclului de via reflect diferite stri ale sistemului, pornind de la momentul apariiei necesitii de elaborare a sistemului dat pn la retragerea lui din exploatare. 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. Modelele ciclului de via pot fi mprite n modele cascad i modele iterative cu variante succesive. 2.1.1. Modelul cascad Modelul cascad (fig. 2.1) stabilete executarea consecitiv a fazelor proiectului ntr-o ordine strict. Include urmtoarele faze: Stabilirea cerinelor, Proiectarea, Realizarea/Implementarea i testarea modulelor, Integrarea i testarea de sistem, Exploatarea i mentenana. Trecerea la faza urmtoare semnific finalizarea complet a tuturor lucrrilor de la etapa precedent.

Fig. 2.1. Modelul Cascad n faza de Stabilire a cerinelor sunt identificate toate cerinele posibile ale sistemului ce se dorete implementat. Cerinele sunt culese de la utilizator prin consultarea acestuia, dup care este analizat posibilitatea de incorporare a lor n produsul dorit. La final este redactat un document cu aceste cerine (Sarcina Tehnic), ce va servi ca ghid pentru fazele urmtoare ale proiectului. n etapa de Proiectare sunt studiate cerinele de la prima etap i este elaborat design-ul sistemului. Aceast faz ajut n specificarea cerinelor de sistem i hardware, precum i n definirea arhitecturii de ansamblu. Rezultatul acestei etape se concretizeaz n redactarea unui document ce cuprinde specificaiile de proiectare (Proiectul Tehnic). Etapa Realizarea i testarea modulelor presupune divizarea sistemului n module i implementarea codului. Sistemul este dezvoltat mai nti n mici programe, numite uniti, module sau componente, care vor fi apoi integrate n faza urmtoare. Fiecare unitate este dezvoltat i testat (testare uniti, autonom), pentru a ne asigura c respect specificaiile. Componentele pot fi funcii, obiecte sau grupuri coerente de astfel de entiti. n faza de Integrare i testare de sistem, toate unitile dezvolate n faza anterioar sunt

integrate i apoi testate pentru a verifica dac se coordoneaz, iar sistemul, privit ca un ntreg, se comport conform cu specificaiile. Dup testarea cu succes, produsul este livrat la beneficiar etap la care are loc testarea de acceptare - testarea cu datele clientului pentru a verifica dac sistemul ndeplinete cerinele acestuia. Ultima faz Exploatarea i mentenana - este o faz pentru care termenul de finalizare coiincide cu retragerea din utilizare a sistemului. Problemele unui produs program (PP) apar dup ce el ncepe sa fie utilizat i vor fi rezolvate dup lansarea PP prin activiti de mentenan. Printre avantajele modelului cascad, se pot meniona: Documentaia i proiectarea structurii sunt un avantaj dac apar noi membri n echip; Este un model uor de utilizat i simplu; Fiecare faz are un rezultat ateptat, datorat rigiditii modelului; Etapele sunt ndeplinite individual, secvenial (uor de urmrit);

Este recomandat pentru proiectele mici, n care cerinele sunt foarte bine nelese. Printre dezavantajele acestui tip de model, se numr: Culegerea specificaiilor n etapa de Cerine este foarte important pentru a proiecta i implementa produsul corespunztor. Cu toate acestea, cerinele pot fi adugate i dup finalul acestei etape, fapt ce influeneaz n mod negativ dezvoltarea; Problemele din cadrul unei etape nu sunt niciodat rezolvate complet n cadrul aceleiai etape; Partiionarea n etape a proiectului nu este flexibil ; Clientul poate aduga noi cerine, care nu pot fi implementate n aceeai ediie a produsului. Va fi nevoie de costuri suplimentare pentru implementarea cerin elor nou adugate; Este dificil s se fac o estimare corect a timpului i costului alocat pentru fiecare etap; Un produs funcional finit este obtinut trziu, comparativ cu momentul de nceput al proiectului.

O perfecionare a modelului cascad este m odelul cu control intermediar sau cu reacie, n care au fost introduse iteraii cu conexiuni inverse ntre etape (fig. 2.2). Coreciile, introduse ntre etape, permit s se in cont de influenele reciproce ale rezultatelor la diferite etape; timpul de via a fiecrei etape se extinde peste ntreaga perioad de elaborare.

Fig. 2.2. Modelul cu control intermediar 2.1.2. Modelul spiral Acest model a fost definit plecnd de la slbiciunile modelului cascad, n special lipsa sa de flexibilitate la schimbri ale cerinelor. Este focalizat pe analiza riscurilor n mod incremental, repetnd modelul cascad ntr-o serie de cicluri, ca n figura 2.3.

Fig. 2.3. Modelul spiral 2. Dezvoltarea produsului: proiectarea de detaliu, testarea unitar, integrarea. La prima iteraie este construit un prim prototip al noului sistem din design-ul preliminar, care este de obicei un sistem la scar redus i reprezint o aproximare a caracteristicilor produsului final. 3. Planificarea urmtorului ciclu: evaluarea de ctre client, planificarea dezvoltrii i a livrrii ctre client. Urmtorul prototip este dezvoltat conform urmtorilor pai: Evaluarea prototipului precedent n termeni de puncte forte, puncte slabe i riscuri; Definirea cerinelor pentru urmtorul prototip; Planificarea i proiectarea urmtorului prototip; Construirea i testarea urmtorului prototip. Modelul spiral este o mbuntire a modelului cascad deoarece prevede mai multe livrri i mai multe posibiliti de implicare a clientului. Raza spiralei reprezint costul acumulat. O versune modificat este modelul spiral WinWin, care adaug la nceputul fiecrui ciclu activiti de identificare a prilor interesate n proiect (stakeholders) i condiiile lor de ctig (win conditions). La avantaje merit s fie subliniat atitudinea pro-activ asupra riscurilor cu o presupunere explicit a riscurilor i a rezolvrii lor. De asemenea un avantaj important este flexibilitatea modelului. La dezavantaje trebuie de menionat c este aproape imposibil de estimat de la nceput timpul de execuie a proiectului i costurile necesare. 2.1.3. Alte modele La categoria alte modele pot fi menionate Rational Unified Process (RUP), Model Driven Architecture (MDA), Modelul n V (V model), modelul ESA ( European Space Agency), Dezvoltarea Agile, Dezvoltare pe baz de prototip (Prototyping) etc. Modelul n V (fig. 2.4) este o variant a modelului cascad, care pune n eviden corelarea dintre

activitile de specificare i cele de testare, nlnuirea n timp a activitilor fiind aceeai.

Fig. 2.4. Modelul n V Partea din stnga reprezint lanul de specificare a sistemului, iar cea din dreapta lanul de testare. Partea de jos a V-ului reprezint implementarea. n acest model exist dou tipuri de dependene ntre etape: cele reprezentate prin liniile, care formeaz V-ul i corespund nlnuirii i eventualei iteraii din modelul cascad; etapele se deruleaz deci secvenial, urmnd V-ul de la stnga la dreapta; cele reprezentate prin linii orizontale, care indic faptul c o parte din rezultatele etapei din care pleac sgeata sunt utilizate direct n etapa int. De exemplu, la terminarea etapei de proiectare arhitectural , cazurile de teste de integrare trebuie s fie complet descrise.

n dezvoltarea pe baz de prototip ideea este de a permite viitorilor utilizatori s exerseze cu o prim versiune a sistemului, care poate fi obinut rapid prin tehnici de simulare i/sau de interpretare a specificaiilor. n 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 rspunde exigenelor de calitate ale unui produs finit. Prototipul ofer clientului functionaliti (nu n totalitate) ale viitorului sistem i interfaa pentru utilizator. El este dezvoltat ntr-o manier iterativ. Cerinele sunt extrase i validate iterativ prin utilizarea prototipului. n fiecare iteraie specificaia sistemului este modificat i detaliat pn cnd prototipul satisface necesitile utilizatorilor. Un prototip care este utilizat pentru a desprinde cerin ele 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. n loc de a stabili definitiv cerinele nainte de a putea ncepe cu proiectarea, este lansat un prototip pentru a nelege cerinele. Acesta este dezvoltat pe baza cerinelor cunoscute n prezent. Dezvoltarea prototipului conine fazele de proiectare, realizare i testare, dar acestea nu sunt foarte riguroase sau formale. Prin intermediul prototipului clientul nelege mai bine modul n care lucreaz produsul, ntruct interacioneaz cu acesta pe parcursul ntregului ciclu de

dezvoltare. Acest model este preferat in cadrul sistemelor mari si complicate, pentru care este dificil intelegerea cerintelor de la inceput. In astfel de situatii, accesul clientului la prototip furnizeaza un aport substantial in intelegerea si definirea specificatiilor. Avantajele acestui model sunt: Utilizatorii sunt implicai direct n dezvoltare; Susine tendina utilizatorilor de a-i modifica cerinele pe parcursul ciclului de implementare; ntruct 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, fapt ce duce la obinerea de soluii mai bune; Timpul i costurile sunt reduse. Poate crete complexitatea SI, care se poate extinde dincolo de limitele stabilite ini ial; Analiza insuficient a proiectului ca un ntreg; Programatorii pot deveni ataai de un prototip n a crui dezvoltare au investit mult timp i vor tinde s transforme prototipul ntr-un produs final chiar i atunci cnd arhitectura de baz nu este cea potrivit; Consumul excesiv de timp utilizat pentru implementarea unui prototip.

Printre dezavantaje, merit menionate:

2.2.

Procesele ciclului de via

Fiecare etap de creare a SI include executarea unor anumite lucrri procese al ciclului de via. Un proces este definit ca un set de activiti interdependente, care transform intrrile sistemului n ieiri. Descrierea unui proces include lista problemelor rezolvate, datele iniiale i rezultatele. 2.2.1. Procesele conform ISO/IEC 12207 n conformitate cu standardul ISO/IEC 12207 procesele ciclului de via se mpart n trei categorii: 1. 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. Cele cin ci procese primare sunt: o achiziie definete activitile de achizitor, organizaia care achiziioneaz un sistem, un PP sau un serviciu soft; o aprovizionare definete activitile de furnizor, organizaie care livreaz sistemul, PP sau presteaz serviciul solicitat de achizitor; o dezvoltare - definete activitile de dezvoltator, organizai a care definete i dezvolt produsul program; o exploatare - definete activitile operatorului organizaie, care ofer servicii de operare a unui sistem informatic n mediul su pentru utilizatorii si ; o ntreinere - 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. 2. 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. Procesele auxiliare sunt: o documentarea definete activitile de nregistrare a informaiei produse de un ciclu de via; o managementul configuraiei - definete activitile de gestiune a configuraiei; o asigurarea calitii - definete activitile de asigurare obiectiv a conformitii produselor program i proceselor cu specificaiile lor; o verificarea - definete activitile (pentru achizitor, furnizor, sau o persoan

o o o o

independent), pentru verificarea produselor program n profunzime, n funcie de proiect; validarea - definete activitile (pentru achizitor, furnizor, sau o o persoan independent), pentru validarea (atestarea) produselor program; revizuirea comun - definete activitile de evaluare a strii i produselor unei activiti; auditarea - definete activitile pentru stabilirea conformitii cu cerinele, planurile i clauzele contractuale; soluionarea problemelor - definete un proces de analizare i ndeprtare a problemelor, indiferent de natura lor sau surs, probleme descoperite n timpul dezvoltrii, funcionrii, ntreinerii etc.

3. 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. Procesele organizaionale sunt: o management - definete activitile de baz ale managementului, inclusiv managementul de proiect, n timpul unui proces al ciclului de via; o procesul de infrastructur - definete activitile de baz pentru stabilirea structurii unui proces al ciclului de via; o perfecionare - definete activitile de baz pe care o organizaie (achizitorul, furnizorul, dezvoltatorul, operatorul, menintorul sau managerul unui alt proces) le efectueaz pentru determinarea, msurarea, controlul, precum i mbuntirea procesului ciclului su de via; o instruire - definete activitile pentru furnizarea de personal instruit n mod adecvat . Pentru susinerea utilizrii practice a standardului ISO/IEC 12207 au fost elaborate o serie de documente tehnologice: Ghid pentru ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207) i Ghid de utilizare ISO/IEC 12207 la managementul proiectelor (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management). 2.2.2. Coninutul proceselor primare Standardul ISO/IEC 12207 stabilete coninutul proceselor primare, auxiliare i organizaionale. n tabelul 2.1 este prezentat situaia pentru procesele primare. Tabelul 2.1. Coninutul proceselor primare conform ISO/IEC 12207 Proces (executor) Achiziie (achizitor) Aciuni Iniierea Pregtirea cererii de oferte (licitaie) Pregtirea i actualizarea contractului Monitorizarea furnizorului Acceptarea i completarea Intrare Decizia privind lansarea lucrrilor de implementare a SI Rezultatele analizei activitii achizitorului Rezultatele analizei pieei produselor program Planul de furnizare/dezvoltare Test complex al SI Caietul de sarcini Decizia conducerii de participare Rezultatele licitaiei Sarcina tehnic Planul de Ieire Studiu de fezbilitate privind oportunitatea implementrii Sarcina tehnic pentru crearea SI Contract de furnizare/ creare a SI Actele de primire a etapelor lucrrilor Actul testrilor de primire/predare

Furnizare (dezvoltatorul/ furnizorul))

Iniierea Pregtirea rspunsului la cererea de oferte Pregtirea contractului

Decizia de participare Oferta comercial/ cerere de participare la licitaie Contract de furnizare/ creare a SI Planul de management al

Dezvoltare (dezvoltatorul)

Planificarea executrii management al Executare i control proiectului Verificare i evaluare SI elaborat i Furnizarea SI documentat ST pentru elaborarea sistemului ST pentru elaborarea sistemului, modelul ciclului de via Subsistemele SI Specificaiile componentelor soft Arhitectura produselor program Materialele proiectrii de deataliu a produselor program Planul de integrare, testele Arhitectura SI, produselor program, documentaia SI, testele

proiectului Realizarea/corectarea Actul testrilor de primire/predare Modelul utlizat al ciclului de via, stadardele de dezvoltare Planul lucrrilor Coninutul subsistemelor, componentele tehnice Specificaiile cerinelor referitor la componentele program Coninutul componentelor program, interfeele BD, planul de integrare Proiectul BD, specificaiile interfeelor componentelor program, cerinele pentru teste Codul modulelor program, actele testrilor unitare Evaluarea coformitii setului de programe cerinelor ST Evaluarea coformitii produsului program, BD, echipamentelor tehnice i setului de documente cerinelor ST

Pregtirea 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

2.2.3. Procesele conform ISO/IEC 15288 n anul 2002 a fost publicat standardul pentru procesele ciclului de via al sistemelor - ISO/IEC 15288 System life cycle processes. La elaborarea lui au participat specialiti din diferite domenii: ingineria sistemelor, programare, managementul calitii, managementul resurselor umane, securitate etc. A fost luat n consideraie experiena crerii sistemelor informaionale pentru instituiile statului, uniti comerciale, organizaii academice sau militare. Stadardul este gndit pentru un spectru larg de sisteme, dar destinaia principal este susinerea crerii sistemelor iinformaionale. n conformitate cu standardul ISO/IEC 15288 ciclul de via include urmtoarele grupuri de procese: 1. Procese contractuale: o achiziie (soluii interne sau ale unui furnizor extern); o furnizare (soluii interne sau ale unui furnizor extern). 2. Procesele ntreprinderii: o managementul mediului extern; o management investiional; o managementul ciclului de via a produselor program; o managementul resurselor; o managementul calitii. 3. Procesele proiectului: o planificarea proiectului; o estimarea proiectului; o controlul proiectului; o administrarea riscurilor; o managementul configuraiei;

o o

managementul fluxurilor informaionale; adoptarea deciziilor.

4. Procesele tehnice: o identificarea cerinelor; o analiza cerinelor; o elaborarea arhitecturii; o implementarea; o integrarea; o verificare; o transmiterea ctre beneficiar; o validarea (atestarea); o exploatarea; o meninerea; o retragerea din uz. 5. Procese speciale: o determinarea i realizarea legturilor reieind din sarcini i scopuri . Etapele de creare a unui sistem propuse de standardul ISO/IEC 15288 difer un pic de cele di n ISO/IEC 12207. n tabelul 2.2 sunt prezentate etapele i rezultatele principale, care trebuie s fi e atinse la momentul finalizrii etapelor conform standardului ISO/IEC 15288. Tabelul 2.2. Etapele crerii sistemelor conform ISO/IEC 15288 crt 1 2 3 4 5 6 Etap Elaborarea concepiei Proiectarea Realizarea Exploatarea Mentenana Retragerea din uz Descriere Analiza necesitilor, formularea concepiei i alegerea soluiilor de proiect Elaborarea proiectului tehnic al sistemului Construirea sistemulu Lansarea n exploatare i utilizarea sistemului Asigurarea funcionrii sistemului Terminarea utilizrii, demontarea, trecerea n arhiv a sistemului

2.2.4. Alte standarde i reglementri n afara celor dou standarde internaionale, adoptate i de Republica Moldova, exist un ir de standarde de fact (metodologii), care reglementeaz Ciclul de via a produselor program, iar n unele cazuri i procesul de dezvoltare. O contribuie semnificativ la teoria proiectrii i practica dezvoltrii sistemelor informaionale a adus compania IBM, oferind la mijlocul anilor 1970, metodologia BSP (Business System Planning metodologia de planificare organizaional). Metoda de structurare a informaiei utilznd matricele de intersecie a proceselor business, departamentelor funcionale, funciilor sistemelor de prelucrare a datelor, obiectelor informaionale, documentelor i bazelor de date, propus n BSP, este folosit astzi nu numai n proiectele IT, dar i n proiectele de reinginerie a proceselor business, de modificare a structurii organizaionale. Cei mai importani pai ai procesului BSP, consecutivitatea lor (obinerea susinerii conducerii de vrf, determinarea proceselor ntreprinderii, stabilirea claselor de date, desfurarea interviurilor, prelucrarea i organizarea datelor interviului), pot fi gsii n aproape toate metodele formale, precum i n proiectele realizate n practic. Printre cele mai cunoscute standarde pot fi evideniate urmtoarele: GOST 34.601-90 stabilete stadiile i etapele crearii sistemelor automatizate. Conine descrierea lucrrilor pentru fiecare etap. Corespunde modelului cascad.

Custom Development Method (metod Oracle) pentru elaborarea sistemelor informaionale aplicative material tehnologic, detaliat pn la nivelul formularelor de documente de proiect pentru utilizarea n proiectele Oracle. Rational Unified Process (RUP) propune un model iterativ de dezvoltare, care include 4 faze: lansarea, cercetarea, construirea i implementarea. Fiecare faz poate mprit n etape (iteraii), n rezultatul crora este produs versiunea pentru utilizare intern sau extern. Cele patru faze formeaz un ciclu de elaborare, fiecare ciclu se termin cu generarea unei versiuni a sistemului. Dac dup un ciclu ordinar lucrul nu se termin, continu dezvoltarea produsului obinut trecnd prin aceleai faze. Esena lucrului n cadrul RUP const n crearea i dezvoltarea modelelor n baza UML. Microsoft Solution Framework (MSF) are multe momente comune cu RUP. De asemenea are patru faze: analiza, proiectarea, realizarea i stabilizarea. Procesul este iterativ, presupune utilizarea modelrii obiect-orientate. n comparaie cu RUP, MSF ntr-o msur mai mare este destinat dezvoltrii aplicaiilor business. Extreme Programming (XP) - programarea extremal - cea mai nou metodologie, aprut n anul 1996. La baza metodologiei st lucrul n echip, comunicarea efectiv ntre client i executor pe ntreaga perioad de executare a proiectului. Dezvoltarea are loc prin utilizarea prototipurilor perfecionate succesiv.

Dezvoltatorii de produse program din Republica Moldova trebuie s cunoasc i Reglementarea Tehnic Procesele ciclului de via a software-ului RT 38370656- 002:2006. Aceast reglementare este obligatorie la crearea sistemelor informaionale automatizate de importan statal. Se orienteaz spre aplicarea tehnologiilor orientate pe obiecte i a mijloacelor contemporane de management al proiectelor, de elaborare i suport a versiunilor. Agenii economici, care furnizeaz/ procur software pentru sistemele informaionale automatizate nestatale, pot aplica prezenta reglementare tehnic n mod voluntar.

3. Organizarea proceselor de dezvoltare a sistemelor informaionale


Proiectarea canonic a SI. 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. n dependen de nivelul de utilizare a soluiilor tip, metodele de proiectare a sistemelor informaionale se mpart n: metode canonice; metode tip. Proiectarea canonic presupune elaborarea sistemelor fr utilizarea unor soluii gata (de la zero) sau mijloace instrumentale speciale, care s permit integrarea execuiei operaiilor elementare . Altfel spus, proiectarea canonic reflect particularitile proiectrii manuale (originale, individuale) i, de obicei, este recomandat pentru crearea unor sisteme de dimensiuni mici. Proiectarea tip presupune crearea sistemului informaional din elemente tip existente. Aceasta poate avea loc n cazul n care este posibil decompoziia sistemului proiectat n componente constitutive (subsisteme, seturi de lucrri, module programetc.). Pentru realizarea proiectrii tip exist dou abordri: proiectare orientat pe parametri i orientat pe modele. Conform modalitii de adaptare a soluiilor, metodele de proiectare se mpart n metode cu reprogramare, metode cu parametrizare i metode cu modificarea modelului. Metodele cu reprogramare presupun crearea unor module program modificabile noi. Metodele cu parametrizare permit configurarea soluiilor de proiectare prin modificarea setrilor din modulele de software. Ultima categorie este bazat pe introducerea unor modificri n modelul domeniului obiectiv cu generarea codului modulului modificat.

3.1.

Proiectarea canonic a SI

Organizarea proiectrii canonice a sistemelor informaionale este orientat n mare msur spre utilizarea modelului cascad a ciclului de via. Etapele sunt standardizate n GOST 34.601-90. n dependen de complexitatea obiectului automatizrii i probleme le, 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. 3.1.1. Etapele proiectrii canonice Etapa 1. Studiul SI existent i definirea cerinelor noului sistem Aceast etap include activitile: cercetarea SI existent i motivarea necesitii crerii unui sistem nou; formarea cerinelor sistemului nou; elaborarea raportului despre lucrul ndeplinit. Etapa 2. Elaborarea Concepiei SI La crearea Concepiei SI poate fi de folos anexa 3 a RT 38370656- 002:2006. Pentru elaborare vor fi ndeplinite urmtoarele activiti: studierea obiectului automatizrii; executarea lucrrilor de cercetare necesare; elaborarea versiunilor Concepiei, discutate de grupul de lucru, format din reprezentanii beneficiarului i executorului; perfectarea versiunii finale a Concepiei i aprobarea ei de Conducere.

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. Etapa 4. Proiectarea de detaliu Activitile componente ale acestei etape sunt: elaborarea soluiilor de preproiect pentru sistem i prile sistemului; elaborarea documentaiei de detaliu pentru sisten i prile lui. Etapa 5. Proiectul tehnic Include activitile: elaborarea soluiilor de proiect pentru sistem i prile sistemului; elaborarea documentaiei de proiect pentru sistem i prile lui; elaborarea i perfectarea documentaiei de furnizare a componentelor; elaborarea sarcinilor pentru proiectarea prilor conexe ale proiectului. Etapa 6. Implementarea codului i perfectarea documentaiei de lucru Const din: scrierea i testarea codului modulelor; integrarea modulelor i testarea subsistemelor i a sistemului n totalitate; elaborarea documentaiei de lucru pentru sistem i prile lui. Etapa 7. Lansarea n exploatare Include activitile: pregtirea obiectului automatizrii; instruirea personalului; completarea sistemului cu toate componentele necesare (resurse tehnice i resurse program); executarea lucrrilor de construcie i montare; lucrri de lansare i depanare; testri preliminare; exploatare pilot; testare de primire-predare. Etapa 8. Mentenana SI Presupune: ndeplinirea lucrrilor n conformitate cu obligaiunile de garanie; deservirea postgaranie. 3.1.2. Analiza situaiei i identificarea cerinelor sistemului nou Cercetarea sistemului informaional existent i motivarea necesitii crerii unui sistem nou include determinarea modului n care funcioneaz SI curent i identificarea a ceea ce ar dori utilizatorii s realizeze noul sistem. Studiul i analiza sistemului existent are ca obiectiv principal stabilirea cerinelor informaionale ale conducerii n vederea realizrii unui sistem informatic. Studiul sistemului existent cuprinde un grup de activiti , care urmresc cunoaterea performanelor tehnico-funcionale, 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 [2]. Cercetarea sistemului existent const n [2]: 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 locului n sfera serviciilor i/sau sfera produciei; cunoaterea relaiilor de cooperare cu ali ageni economici; cunoaterea specificului activitii de baz (producie, servicii); 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 [2]: Pe baza statutului de funcionare a organizaiei se studiaz: o activitile i sarcinile din cadrul acestor funciuni; o atribuiile ce revin compartimentelor; o modul de realizare a activitilor funcionale din cadrul unitii economice. n cazul activitii de producie se prezint: o fluxul de producie, amplasarea locurilor de munc, depozitelor etc.; o tipurile de produse, structura lor, ciclurile de realizare; o modul de organizare a produciei, stocarea produciei, transporturile interne, controlul de calitate; o resursele existente: capaciti; asigurarea tehnic; proiectarea de produse noi; norme tehnice; o asigurarea cu materiale necesare; o sistemul existent de programare a produciei.

Studiul sistemului de conducere se refer la [2]: identificarea caracteristicilor sistemului de conducere 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 [2]: 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 i 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. Identificarea metodelor i mijloacelor tehnice utilizate pentru prelucrarea datelor n cadrul sistemului informaional existent se face evideniind: mijloacele tehnice existente n dotarea unitii economice (modul de utilizare, cheltuielile de exploatare, personalul implicat, performane); existena unor aplicaii proiectate i/sau implementate [2]. 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 rspunsuril or la chestionare, seturi de

formulare, rapoarte, descrieri ale posturilor de lucru .a., precum i rezultate ale prelucrrilor efectuate de calculator, cum ar fi prototipurile [1]. Activitile enumerate pot fi executate total cu forele achizitorului sau prin contractarea unor servicii din partea unei organizaii de consultan. Odat cu finalizarea acestei etape apare posibilitatea de a determina abordrile tehnice posibile i de a evalua costurile de realizare (cheltuieli pentru procurarea resurselor tehnice, resursele program de sistem i produsele program noi). Rezultatele prezentate dup aceast etap pot fi rezumate astfel: 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 [1]. 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 (planul calendaristic de executare a lucrrilor), costurile aferente, inclusiv, modalitatea i graficul achitrilor, efectul economic prognozat i timpul de recuperare a cheltuielilor. Coninutul aproximativ al acestui document poate include: constrngerile, riscurile, factorii critici, care pot influena succesul proiectului; 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. De asemenea 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 [9], care se descifreaz astfel: 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. 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 sistemului informaional. Este preferabil implicarea testerilor ncepnd chiar cu etapa de analiz. Acetia vor participa la: soluionarea problemelor legate de obinerea caracteristicilor comparative ale platformelor tehnice, ale sistemelor de operare, SGBD, alte medii de funcionare; elaborarea compartimentului planului de lucru asociat fiabilitii i testrii SI. Implicarea testerilor n etapele iniiale ale proiectului este preferabil pentru orice tipuri de proiecte. Costurile eliminrii unor erori, generate la una din etapele iniiale, este prea mare, iar prezena testerilor poate salva situaia. Rezultatele primei etape servesc la elaborarea Concepiei (etapa 2) i Sarcinii Tehnice (etapa 3) a viitorului sistem informaional. 3.1.3. Elaborarea Concepiei SI i Sarcinii Tehnice Conform anexei 3, RT 38370656- 002:2006, Concepia este documentul iniial, elaborat la crearea sistemului, care conine rezultatele ndeplinirii lucrrilor de cercet are tiinific i experimental i servete drept baz pentru elaborarea ulterioar a documentaiei tehnice. n dependen de scopurile propuse, Concepia poate fi de baz sau cadru. Concepia cadru se elaboreaz n cazul, cnd sistemul descris const dintr-o multitudine de sisteme independente sau interconectate, pentru care ulteri or 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. Conform RT 38370656- 002:2006, Concepia trebuie s conin urmtoarele capitole: 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 a sistemului; 10. ncheiere. n conformitate cu anexa 4, RT 38370656- 002:2006, Sarcina Tehnic (etapa 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 probleme: stabilirea scopului crerii SI, determinarea subsistemelor i a funciilor; elaborarea i fundamentarea cerinelor privind subsistemele; 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. Cerinele-tip referitor la componena i coninutul ST sunt prezentate n tabelul 3.1.

Tabelul 3.1. Compnena i coninutul ST (GOST 34.602- 89) Nr crt Compartiment Coninut 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 data de ncepere i finalizare a lucrrilor informaii despre surse i modalitatea de finanare ordinea de perfectare i prezentare a rezultatelor crerii SI, prilor sistemului sau a unor module separate 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 informaii succinte despre obiectul automatizrii informaii despre condiiile de exploatare i caracteristicile mediului ambiant Cerine privind sistemul n totalitate: o 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) o cerine privind personalul (roluri, calificarea, regimul de lucru, organizarea instruirii, utilizatorii) o indicatori asociai destinaiei sistemului (adaptabilitatea la modificrile sistemului de conducere i a valorilor parametrilor, scalabilitatea) o 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 funcii (pe subsisteme): o lista activitilor automatizate o cadrul temporal de realizare a fiecrei funcii o cerine privind calitatea realizrii fiecrei funcii, forma de prezentare a ieirilor, exactitatea i autencitatea datelor o lista i criteriile de stabilire a cderilor (refuz serviciu) Cerine referitoare la resurse: o matematice (componena i sfera utilizrii modelelor i metodelor matematice, algoritmilor existeni i noi o 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) o lingvistice (limbajele de programare, limbile de interaciune a utilizatorilor cu sistemul, sistemele de codare, limbajele pentru intrri/ieiri

1 Generaliti

2 Destinaia i scopurile crerii (modernizrii) sistemului

3 Descrierea obiectului automatizrii 4 Cerine referitoare la sistem

o program (independena de platform, calitatea i metodele de control, utilizarea fondurilor de algoritmi i programe o tehnice o metrologice o organizaionale (structura i funciile departamentelor de exploatare, protecia contra unor aciuni eronate) o metodice (documentaia normativ-tehnic) 5 Componena i coninutul lucrrilor de creare a sistemului lista stadiilor i a etapelor termenii de execuie lista orgaizaiilor executoare modalitatea i ordinea expertizrii documentaiei tehnice programul de asigurare a fiabilitii programul de asigurare metrologic

6 Modul de testare, verificare i 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 informaionale

tipurile, componena, volumul i metodele de testare cerine generale privind acceptarea lucrrilor pe etape statutul comisiei de primire transformarea informaiilor de intrare n form mainolizibil modificrile introduse n obiectul automatizrii termenii i modalitatea de selectare i instruire a personalului lista documentelor elaborate lista documentelor pe supori magnetici documente i materiale informaionale, n baza crora a fost elaborat ST i sistemul

Proiectul de detaliu include elaborarea soluiilor de preproiect pentru ntregul sistem i prile componente. Acest etap nu este obligatorie. Dac soluiile principale de proiect au fost determinate anterior sau sunt suficient de evidente pentru un sistem concret, etapa proiectrii detaliate poate fi exclus din lista lucrrilor. De obicei, la etapa proiectrii de detaliu sunt stabilite: funciile SI; funciile subsistemelor, scopurile lor i efectul preconizat la implementare; lista grupurilor de lucrri i a unor lucrri separate; concepia i structura general a bazei informaionale; funciile SGBD; componentele sistemului de calcul i a celorlalte resurse tehnice; funciile i parametrii prncipalelor resurse program. La finalizarea acestor activiti este perfectat, coordonat i aprobat documentaia n volum necesar pentru descrierea setului total de sol uii proiect stabilite i suficient pentru continuarea lucrrilor de creare a sistemului. n baza Sarcinii Tehnice (i a proiectului de detaliu) este elaborat Proiectul Tehnic al SI (etapa 5). 3.1.4. Proiectul tehnic Proiectul Tehnic al sistemului informaional 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 implem entrii. 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. Componena i coninutul Proiectului Tehnic sunt prezentate n tabelul 3.2

Tabelul 3.2. Informaii referitoare la Proiectului Tehnic Nr crt Compartiment Coninut cadrul justificativ pentru elaborarea sistemului lista organizaiilor executoare caracteristica succint a obiectului cu lista indicatorilor tehnicoeconomici principali de funcionare i legtuarile cu alte obiecte informaii succinte privind soluiile principale de proiect 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 natur organizaional i economic a problemei (denumirea, scopul, rezumat, metoda, periodicitate i timpul de rezolvare, metodele de culegere i transmitere a datelor, relaia cu alte sarcini, natura utilizrii rezultatelor) modelul economic i matematic al problemei (prezentarea structural i detaliat) informaii normative (coninutul i forma de prezentare) informaii privind comunicarea cu alte sarcini informaii pentru decizii ulterioare referitoare la problema dat informaii cu privire la modificri (modul de introducere a schimbrilor i lista informaiilor care fac obiectul modificrilor) algoritmul de soluionare a problemei (secvena de pai, 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) 5 Albumul cu formele documentelor 6 Resursele matematice justificarea structurii resurselor matematice justificarea alegerii mediului de programare lista resuselor program de sistem descrierea i motivarea schemei procesului tehnologic de prelucrare a datelor sursele de informaii i modul de transfer 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, definirea lor, marja de valori i lista documentelor bazei 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

1 Not explicativ

2 Structura funcional i organizaional a sistemului

3 Enunul problemei i algoritmii de soluionare

4 Organizarea bazei informaionale

7 Complexul de mijloace tehnice

8 Calculul eficienei economice a sistemului

justificarea alegerii structurii complexului tehnic i grupurilior funcionale ale acestuia motivarea cerinelor privind echipamentele speciale setul de aciuni pentru asigurarea fiabilitii funcionrii echipamentelor devizul de cheltuieli pentru exploatarea sistemului calculul eficienei economice anuale obinute din optimizarea structurii organizaiei, diminuarea costurilor i a pierderilor, mbuntirea deciziilor administrative lista msurilor organizaionale pentru perfecionarea proceselor business lista lucrrilor pentru implementarea sistemului, care sunt necesare la etapa proiectrii tehnice, cu indicarea termenilor i responsabililor

9 Msuri privind pregtirea obiectului pentru implementarea sistemului 10 Borderoul documentelor 3.1.5. Documentaia

La finalizarea etapei proiectrii tehnice sunt documentate componentele, produse n serie necesare pentru crearea SI. De asemenea sunt determinate cerinele tehnice i este elaborat sarcina tehnic pentru producerea componentelor speciale. n cadrul etapei 6 Implementarea codului i perfectarea documentaiei de lucru este creat produsul program i toat documentaia nsoitoare. Documentaia va include informaiile necesare i suficiente pentru ndeplinirea lucrrilor de implementare a SI, ca i pentru meninerea ni velului caracteristicilor funcionale. Calitatea caracteristicilor funcionale este identificat prin testare. Sunt stabilite urmtoarele tipuri de testri (ncercri) ale SI: preliminare, de exploatare pilot i testarea final (de primire). La necesitate pot avea loc testri suplimentare att pentru ntregul sistem, ct i pentru prile componente. n dependen de legturile interne ale componentelor i obiectului automatizrii, testrile pot fi autonome sau complexe. Testrile autonome (de detaliu) includ unele prti 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). Testrile preliminare determin funcionalitatea sistemului i stabilirea posibilitii de primire n exploatare pilot. Testrile preliminare trebuie executate dup depanarea i testarea PP i a resurselor tehnice i prezentarea documentelor privind disponibilitatea lor pentru ncercri. De asemenea, personalul va fi instruit sau cel puin va face cunotin cu documentaia de exploatare. Exploatarea pilot are drept scop determinarea valorilor reale ale caracteristicilor cantitative i calitative ale sistemului, nivelului de pregtire a personalului pentru exploatarea sistemului i stabilirea eficacitii reale, ca i introducerea unor modificri (la necesitate). Testarea de primire este excutat pentru determinarea conformitii sistemului cu Sarcina Tehnic, estimarea calitii exploatrii pilot i stabilirea posibilitii de primire a sistemului i lansare n exploatare industrial.

3.2.

Proiectarea tip

Compartimentul dat include definiiile principale i sarcina de elaborare a unui proiect, folosind metoda proiectrii tip sau ingineria softului bazat pe componente (CBSE component based software engineering; studiul de caz Proiectarea sistemului informaional al unei ntreprinderi de comercializare en-gross a medicamentelor).

CBSE este procesul de dezvoltare de software care pune accent pe proiectarea i construirea sistemelor software utiliznd componente reutilizabile. Atfel spus, proiectarea tip presupune crearea sistemului din elemente tip existente apriori. Accentul trece de la programare de software la compunere de sisteme software, de la implementare la integrare. Cerina fundamental pentru aplicarea metodei proiectrii tip este posibilitatea decompoziiei sistemului proiectat n componente constitutive (subsisteme, seturi de lucrri, module program etc.). Pentru realizarea componentelor identificate la etapa decompoziiei sunt alese soluiile proiect tip, existente pe pia, care vor fi adaptate la particularitile concrete ale organizaiei. 3.2.1. Soluia proiect tip Soluia proiect tip (SPT) este o soluie tirajat (care poate fi utilizat de mai multe ori). n dependen de nivelul decompoziiei sistemului exist urmtoarele clase de SPT: SPT pe elemente soluii tip pentru o problem sau o categorie de resurse (informaionale, program, tehnice, matematice, organizaionale); SPT pe subsisteme rolul elementelor tipizate este ndeplinit de subsisteme separate, create lund n consideraie completitudinea funcional i minimizarea legturilor informaionale externe; SPT pe obiecte proiecte tip de ramur, care includ setul complet de subsisteme funcionale i resurse ale SI. n afara elementelor funcionale (logice i tehnice) propriu -zise fiecare soluie tip presupune existena documentaiei cu descrierea detaliat a SPT i procedurilor de adaptare n conformitate cu cerinele sistemului elaborat. Abordarea orientat pe parametri include urmtoarele etape: determinarea criteriilor de estimare a susceptibilitii SPT pentru soluionarea problemelor n cauz; analiza i evaluarea SPT accesibile conform criteriilor formulate; selectarea i procurarea celei mai potrivite SPT; acordarea (reglarea) parametrilor SPT procurate. Criteriile de estimare a SPT pot fi mprite n urmtoarele grupe: destinaia i posibilitile pachetului; caracteristici i proprieti ale pachetului; cerinele pentru hardware i software; documentaia pachetului; factori de ordin financiar; caracteristici de instalare a pachetului; caracteristici de exploatare a pachetului; asistena furnizorului pentru implementarea i meninerea pachetului; evaluarea calitii pachetului i experiena de utilizare a acestuia; perspectivele de dezvoltare a pachetului. Abordarea orientat pe model const n adaptarea componentelor i caracteristicilor SPT conform obiectului automatizrii. n acest caz tehnologia proiectrii trebuie s asigure aceleai mijloace de lucruatt cu cu modelul SI tip, ct i cu modelul orgnaizaiei concrete. n depozitul (repozitoriu) cu metainformaii SI tip conine modelul obiectului automatizrii n baza cruia are loc configurarea produsului program. n consecin, abordarea model -orientat presupune, nainte de toate, construirea modelului obiectului automatizrii utiliznd instrumente program speciale (de exemplu, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Este posibil, de asemenea, crearea sistemului n baza modelului tip al SI din repozitoriu, model livrat mpreun cu produsul program i dezvoltat odat cu acumularea experienei de proiectare a SI pentru diferite ramuri i tipuri de producie. Depozitul include modelul de baz (de referin) a SI, modele tip pentru diferite clase de SI, modelele SI ale unor organizaii concrete.

3.2.2. Etapele realizrii Modelul de baz al SI din depozit include descrierea funciilor bisiness, proceselor business, obiectlor business, regulilor business, structurii organizaionale, pentru care pot fi utilizate modulele SI tip. Modelele tip descriu configuraiile SI pentru ramuri sau tipuri de producie concrete. Modelul unei ntreprinderi concrete este construit sau prin alegerea unor fragmente ale modelului de baz sau modelului tip conform praticularitile 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. Regulile busines determin condiiile utilizrii corecte a componentelor SI i asigur men inerea integritii sistemului creat. Modelul funciilor business prezint decompoziia ierarhic a activitii ntreprinderii. Modelul proceselor business reflect ndeplinirea lucrrilor pentru funciile de la cel mai de jos nivel al modelului funciilor business. Pentru descrierea proceselor este utilizat modelul de control al evenimentelor ( - Event-driven Process Chain). Modelul proceselor business permite executarea acordrii (reglrii) modulelor program aplicaii ale sistemului informaional, conform cu particularitile concrete ale ntreprinderii. Modelele obiectelor business sunt utilizate pentru integrarea aplicaiilor, care realizeaz diferite procese buciness. Modelul structurii organizaionale a ntreprinderii este o structur ierarhic tradiional, care include departamentele i personalul. Implementarea unui SI tip ncepe cu analiza cerinelor, care sunt stabilite la etapa de cercetare preproiect. Pentru a estima conformitatea PP cu aceste cerine poate fi utlizat metoda de estimare a pachetelor program, descris mai sus. Dup alegerea PP n baza modelelor de referin are loc construirea modelului preliminar a SI, n care sunt reflectate toate particularitile realizrii SI pentru ntreprindere 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). Realizarea unui proiect tip presupune executarea urmtoarelor operaii: instalarea parametrilor globali ai sistemului; desemnarea structurii obiectului automatizrii; determinarea structurii datelor principale; desemnarea setului de funcii i procese realizate; descrierea interfeelor; descrierea rapoartelor; configurarea autorizrii accesului; configurarea sistemului de arhivare. n tabelul 3.3 sunt prezentate particularitile principale pentru diferite clase de SPT. Tabelul 3.3. Avantajele i dezavantajele SPT Clasa SPT Realizarea SPT SPT pe elemente Avantaje utilizarea abordrii modulare pentru proiectarea i Dezavantaje cheltuieli mari de timp pentru racordarea elementelor eterogene ca rezultat al

Biblioteci de programe orientate pe metode SPT pe subsisteme Pachete de programe aplicative

documentare SI nivel nalt de integrare a elementelor permite realizarea proiectrii modulare, adaptarea parametric a componentelor program pentru diferite obiecte de gestiune asigur diminuarea cheltuielilor documentare bun a proceselor de prelucrare a iinformaiei integrarea componentelor datorit unitii metodologice i informaionale, compatibilitii tehnice i logice 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

incompatibilitii informaionale, logice sau tehnice cheltuieli mari de timp pentru revizuirea SPT pentru unele elemente adaptabilitate insuficient din punctul de vedere al ingineriei continue a proceselor business probleme n integrarea unor sisteme diferite, n special n cazul utilizrii unor soluii de la productori diferii

SPT pe obiecte Proiecte SI de ramur

pot aprea probleme, generate de legarea proiectului tip de un obiect concret, ceea ce poate conduce n unele cazuri la necesitatea modificrii structurii organizaionale i economice a obiectului automatizrii

3.2.3. Modele de componente Modelul obiect definete un standard pentru interoperabilitatea componentelor, asigur interoperabilitatea componentelor dezvoltate n diferite limbaje de programare, aflate pe platforme diferite. Un model de componente este o definiie de standarde pentru implementarea, documentarea i repartizarea componentelor. Modelul de componente specific modul n care trebuie definite interfeele i elementele ce trebuie incluse n definiia unei interfee. O list de modele standard pentru componentele software urmeaz mai jos: 1. OMG / CORBA (Common Object Request Broker Architecture) www.corba.org. Un tutorialul poate fi gsit la http://java.sun.com/developer/onlineTraining/corba/corba.html. 2. Microsoft COM (Component Object Model) http://www.microsoft.com/com/default.mspx 3. Sun JavaBeans / EJB (Enterprise Java Beans) http://java.sun.com/javase/technologies/desktop/javabeans/index.jsp . Tutorial la http://java.sun.com/docs/books/tutorial/javabeans/index.html

4. Analiza i modelarea spaiului funcional al implementrii SI


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. Modelele fluxuri procese. Modele ale structurilor de date. Modelul business complet al companiei. abloane ale business modelrii organizaionale. Construirea structurii organizaionale funcionale a companiei. Etapele elaborrii. Cadrul normativ. Tehnologii informaionale pentru modelarea organizaional.

4.1.

Modelul business complet al companiei

Exist o serie de abordri n efectuarea analizei organizaionale, dar cea mai popular este metoda cunoscut sub numele ingineering. Analiza organizaional conform acestei metode are loc conform unei scheme bine determinate cu utilizarea modelului business complet al companiei. Compania este considerat sistem social economi c deschis, creat pentru atingerea anumitor obiective, element al setului de super-sisteme externe, ierarhice deschise (piaa, instituiile statului etc.) i subsisteme interne (secii, hale, brigzi etc.). Posibilitile companiei sunt determinate de carac teristicile componentelor structurale i modul lor de organizare. n figura 4.1 este prezentat schema generalizat a business modelrii organizaionale. Construirea modelului business al companiei ncepe cu descrierea modelului interaciunii cu mediul extern conform legii unitii i luptei contrariilor, adic cu definirea misiunii companiei.

Fig. 4.1. Schema generalizat a business modelrii organizaionale Conform standardului ISO-15704 misiunea companiei este: 1. Activitile desfurate de ctre societate n scopul ndeplini rii funciei pentru care a fost nfiinat, oferind clienilor produse sau servicii; 2. Mecanismul prin care societatea i realizeaz scopurile i obiectivele.

Misiunea companiei pentru satisfacerea necesitilor solcial-relevante ale pieei este definit ca un compromis ntre interesele pieei i companiei. n acest sens, misiunea ca atribut al unui sistem deschis 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 este o msur a aspiraiilor companiei i, n special, determin preteniile de pia ale acesteia (obiect al luptei concurente). Determinarea misiunii permite crearea arborelului obiectivelor companiei - liste ierarhice de precizare si detalizare a misiunii. n baza arborelui scopurilor este format arborele strategiilor - liste ierarhice de precizare si detalizare a procedeelor de atingere a scopurilor. La nivel corporativ sunt dezvoltate strategiile de cretere, integrare i investiii. Blocul strategiilor business determin strategiile de producere i strategice, 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.). Toate acestea permit asigurarea clienilor cu produse i/sau servicii n cantiti potrivite, la locul potrivit, la momentul de timp dorit, cu o anumit calitate i la costuri minime. n lanul de creare a valorilor compania va ocupa locul optimal din care posibilitile i potenialul ei vor fi exploatate n cel mai bun mod. Aceasta va da posibilitatea crerii business potenialului companiei set de activiti comerciale, direcionate spre satisfacerea necesitilor unor segmente concrete ale pieei. n continuare, reieind din particularitile canalelor de distribuire 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, la rndul su, determin funciile companiei list de funcii business, funcii de management i procurare, necesare pentru meninerea la nivel adecvat a tuturor activitilor. Suplimentar, mai sunt precizate resursele necesare (materiale, umane, informaionale) i structura companiei. Construirea potenialului business i funcionalitilor companiei permite, prin utilizarea matricei proieciilor, s fie stabilite zonele de responsabilitate a managementului. Matricea proieciilor este un model reprezentat sub forma unui tabel bidimensional, care stabilete sistemul de relaii ntre clasificatoare pentru toate combinaiile lor. Matricea responsabilitii comerciale 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. Matricea responsabilitii funcionale fixeaz responsabilitatea verigilor structurale (i a unor specialiti) pentru executarea funciilor business la realizarea proceselor activitii comerciale (aprovizionare, producere, realizare), ca i a funciil or 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, mputernicirilor va permite elaborarea pachetului de instruciuni fie de post. 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). La aceast etap a modelrii business este format setul de regulamente interne fundamentale i universal recunoscute ale companiei: Dispoziia de baz privind structura organizatorico-funcional a companiei;

Setul de Dispoziii privind activiti separate (financiar, de marketing etc.); Fiele de post.

Toate acestea fac activitatea companiei mai transparent prin delimitarea clar i fixarea documentat a zonelor de reponsabilitate a managerilor. Dezvoltarea (detalizarea) ulterioar a modelului business are loc la etapa descrierii dinamice a companiei la nivelul modelelor fluxurilor proceselor. Modelele fluxurilor de procese sunt 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. Mai nti (la nivelul de sus) este descris logica interaciunii participanilor n proces, apoi (la nivelul de jos) tehnologia de lucru a specialitilor la posturile lor. Modelarea business se ncheie cu elaborarea modelului structurilor de date, care 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 documentelor i rapoartelor necesare. O astfel de abordare permite descrierea activitii unei companii folosind o mulime universal de registre de management (scopuri, strategii, produse, funcii, verigi organizatorice etc.). Ca i structur, registrele de management reprezint clasificatoare ierarhice. Reunind clasificatoarele n grupuri funcionale i fixnd elementele diferitor clasificatoare prin utilizarea matricei proieciilor se obine modelul business complet (total) al companiei. n acest caz se produce descrierea scopuri-procese a companiei, care permite s fie obinute rspunsuri la ntrebrile: ce-de ce-unde-cum-cine-cnd-cui-ct-sub ce form (fig. 4.2).

Fig. 4.2. Etapele principale ale descrierii scopuri-procese a companiei Cu alte cuvinte, modelul busines complet al companiei este setul de modele informaionale funcional orientate, care asugir rspunsuri reciproc relaionate la ntrebrile de ce-ce-undecine-cum-cnd-cui-ct (fig. 4.3).

Fig. 4.3. Modelul business complet al companiei n concluzie: analiza organizaional presupune construirea unui set de modele informaionale dependente reciproc, care include: Modelul strategic de direcionare (rspunde la ntrebrile: de ce compania face anume acest tip de business, de ce presupune c va fi competitiv, care obiective i strategii trebuie de realizat); Modelul funcional-organizaional (rspunde la ntrebarea cine-ce face i de ce este responsabil); Modelul funcional-tehnologic (rspunde la ntrebarea ce-cum se face); Modelul procesual-pe roluri (rspunde la ntrebarea cine-ce-cum-cui); Modelul cantitativ (rspunde la ntrebarea cte resurse sunt necesare); Modelul structurilor de date (rspunde la ntrebarea care este forma de descriere a regulamentelor companiei i a obiectelor mediului nconjurtor ).

Setul prezentat de modele asigur completitudinea necesar i precizia descrierii companiei i permite elaborarea unor cerine clare privind sistemul informaional proiectat.

4.2.

abloanele modelrii business organizaionale

Tehnologia modelrii business organizaionale presupune utilizarea unor tehnici standardizate pentru descrierea companiei. 4.2.1. ablonul pentru elaborarea misiunii Precum a fost menionat mai sus, orice companie, cu mediul nconjurtor la nivel micro sau macro, reprezint o ierarhie de sisteme deschise, subiect-orientate, imbricate reciproc. Pe de o parte, compania este parte a pieei, iar 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 (definiia misiunii companiei pe pia) este necesar: s fie identificat piaa (super-sistemul), parte a creia este compania; s fie determinate proprietile (necesitile) pieei;

s se determine destinaia (misiunea) companiei, reieind din rolul ei pe pia.

Suplimentar, dup cum a fost subliniat mai sus, misiunea reprezint compromisul ntre necesitile pieei i dorina companiei de a satisface aceste nec esiti. Cutarea compromisului poate fi organizat folosind ablonul prezentat n figura 4.4.

Fig. 4.4. ablonul pentru elaborarea misunii (matricea proieciilor) 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: o pentru obiect originalitatea tehnologiilor i exclusivitatea resurselor (financiare, materiale, informaionale etc.) o pentru subiect cunotinele i aptitudinele personalului i experiena managerilor. Aceasta determin unicitatea resurselor i aptitudinilor companiei i formeaz poziia pot. 2. S se identifice conjunctura pieei, adic s se determine dac exist cerere efectiv la bunurile i serviciile propuse i nivelul de satisfacere a pieei de ctre concureni. Aceasta permite s fie nelese necesitile pieei i s fie format poziia trebuie. 3. S fie identificat prezena factorilor nsoitori i compensatorii pentru tipul de activitate ales din partea instituiilor statului n domeniul politicii i economiei. 4. S se estimeze perspectiva dezvoltrii tehnologiei n sfera aleas de activitate. 5. S se estimeze susinerea posibil sau opoziia organizaiilor nonguvernamentale i structurilor guvernamentale. 6. S fie estimate rezultatele acestor aciuni lund n consideraie limitril e legale, morale,etice etc. din partea personalului i s fie expus poziia vreau. 7. S fie evaluat nivelul cheltuielilor i veniturilor posibile. 8. S fie estimat posibilitatea realizrii unui compromis acceptabil pentru toate prile i s se formuleze Misiunea companiei n conformitate cu ablonul din figura 4.5.

Fig. 4.5. ablonul pentru elaborarea misiunii Misiunea, n sens larg, reprezint concepia de baz a activitii companiei, exprimat cu ajutorul a opt poziii, care stabilesc relaiile reciproce ale companiei cu alte subiecte: 1. ce va obine clientul pentru satisfacerea necesitilor sale; 2. cine, pentru ce i cum poate fi partener al companiei; 3. care este baza construirii relaiilor cu concurenii (dac exist posibilitatea unor c ompromise temporare); 4. ce va obine proprietarul i acionarii n rezultatul afacerii; 5. ce vor obine managerii n rezultatul afacerii; 6. ce va obine personalul n rezultatul afacerii; 7. n ce poate consta colaborarea cu organizaiile nonguvernamentale; 8. cum vor fi construite relaiile companiei cu statul (n particular, o posibil participare n susinerea programelor de stat). 4.2.2. abloane pentru formarea afacerilor n conformitate cu Misiunea companiei sunt determinate necesitile social relevante la satisfacerea crora este direcionat businessul companiei. Dezvoltarea potenialului business al companiei poate fi realizat folosind ablonul formrii businessurilor, prezentat n figura 4.6.

Fig. 4.6. ablonul formrii businessurilor

n rezultat este format piaa de baz i produsul de baz, detalizarea crora determin oferta companiei pe partea consumatorilor (grupurile de mrfuri i grupurile omogene (relativ la produsele companiei) de consumatori (segmentele pieei). Cu ajutorul matricei proieciilor (fig. 4.7) este stabilit corespondena ntregrupurile de produse i segmentele pieei i sunt determinate afacerile companiei (la intersecia liniilor i coloanelor celeulele matricei).

Fig. 4.7. ablonul formrii afacerilor (matricea proieciilor) n baza listei afacerilor, cu ajutorul matricei proieciilor este format clasificatorul funciilor business al companiei (fig. 4.8).

Fig. 4.8. ablonul formrii funciilor business de baz Pentru formarea funciilor de management principale mai nti sunt elaborate i aprobate dou clasificatoare de baz Dispoziia privind componentele managementului (lista instrumentelor /contururilor administrative) i Dispoziia privind etapele ciclului de management (lan tehnologic de operaii, realizate succesiv de manageri atunci cnd organizez activitile unui instrument/ contur administrativ). Analogic n continuare, folosind matricea proieciilor, este format lista funciilor principale ale managementului. n fig. 4.9 sunt prezentate exemple de clasificatoare n baza crora a fost construit matricea-generator al funciilor principale ale managementului.

Fig. 4.9. ablonul formrii funciilor administrative principale Proieciile matriceale din figurile 4.8 i 4.9 permit formarea funciilor cu orice nivel de detaliere prin descriere mai amnunit a liniilor sau/i coloanelor. Zonele de responsabilitate sunt formate cu ajutorul matricei proieciilor organizaionale folosind ablonul din figura 4.10.

Fig. 4.10. ablonul repartizrii funciilor pe verigile organizaionale Matricea proieciilor organizaionale este un tabel bidimensional cu titlurile liniilor formate din verigile executorii, iar titlurile coloanelor denumirile funciilor, executate n companie. Pentru

fiecare funcie este determinat veriga executorie, responsabil de aceast funcie. Procesul de completare a acestui tabel permite s se gseasc, pentru fiecare funcie, subdiviziunea executorie sau colaboratorul responsabil. Analiza tabelului completat permite s se determine golurile att pentru funcii, ct i pentru colaboratori, i s se rerepartizeze raional lucrrile pe colaboratori. Toate acestea vor fi fixate n Dispoziia privind structura organizaional a companiei document intern, n care sunt fixate: produsele i serviciile companiei, funciile ndeplinite, verigile executorii, funciile de producere, repartizarea funciilor pe responsabili. Tabelul proieciilor funciilor pentru o organizaie de mrime medie poate conine n jur de 500 elemente (de exemplu 20 verigi i 25 funcii). n cazul companiilor mari numrul elementelor poate fi de ordinul ctorva mii. n mod analogic are loc construirea matricei responsabilitii comerciale. 4.2.3. ablonul de descriere flux-proces ablonul de descriere flux-proces (fig. 4.11) asigur nelegerea procesului de transformare succesiv a resurselor n produse ca rezultat al eforturilor diferitor executori, care activeaz n baza regulamentelor.

Fig. 4.11. Modelul flux-proces Modalitile de construire a modelelor proceselor vor fi prezentate mai jos.

4.3.

Construirea modelului organizaional-funcional al companiei

Modelul organizaional- funcional companiei este construit n baza schemei funcionale a activitii companiei (fig. 4.12).

Fig. 4.12. Schema funcional a companiei 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 businessfunciile necesare furnizarea resurselor, producia i distribuia produselor n locul de vnzare. Pentru gestiunea procesului de reproducere este format colecia de componente de management, care genereaz un set de funcii de management. Pentru a menine procesele de reproducere i de management sunt formate seturi de funcii de sprijin aferente (de securitate, echipare tehnic, profilactic i reparaii, etc). Aceast abordare ne permite de a descrie organizaia, cu ajutorul unui set universal de registre de management (obiective, strategii, produse, funcii, uniti organizatorice, etc). Registrele administrative sunt clasificatoare ierarhice. Combinnd clasificatoarele n grupuri funcionale i fixnd reciproc elementele din diferite clasificatoare cu ajutorul proieciilor matriceale, poate fi obinut modelul structurii organizaionale a companiei. Pentru construirea modelului funcional-organizaional sunt utilizate dou tipuri de modele elementare. Modelele arborescente (clasificatoarele) liste ierarhice exacte al obiectelor administrative evideniate (verigi organizaionale, funcii, resurse, inclusiv mecanisme de execuie a proceselor business, documente i structura lor, .a.m.d.). Fiecare element al unui clasificator poate fi caracterizat suplimentar cu ajutorul unor atribute: tipul, scala 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. Cantitatea acestor liste-clasificatoare este determinat de scopurile construirii modelului. Modelele matriceale sunt proiecii, care determin un sistem de relaii pentru orice combinaii ale clasificatoarelor. Legturile pot avea atribute suplimentare (direcie, denumire, indice, scal i greutate). n modelul iniial (de nceput) sunt utilizate doar cteve clasificatoare ale domeniul obiectiv: grupurile principale de produse i servicii ale companiei; resursele de care are nevoie compania pentru producere; funciile (procesele) ndeplinite n companie; verigile organizaionale ale companiei. n clasificatorul funciilor de obicei sunt evideniate trei compartimente de baz: funciile de baz funciile legate direct de procesul de transformare a resurselor n produse i servicii; funciile de management sau funciile de conducere cu ntreprinderea;

funciile de aprovizionare care asist activitile de producere, comercial i de management.

Funcia principal a companiei este 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 funcie concrete. n rezultatul acestor operaii are loc identificarea setului de funcii (funcionalului) i este creat terminologia unitar de descriere a funciilor companiei, care va fi coordonat cu toi man agerii relevani. Este important ca nivelul de detalizare a funciilor s corespund nivelului de detalizare a verigilor n clasificatorul verigilor organizaionale. Dup formarea clasificatoarelor principale, cu ajutorul proieciilor matriceale are loc fixarea funciilor pe verigi organizaionale. Procesul formrii matricei proieciilor funciilor pe verigi organizaionale seamn cu jocul de tic-tac-toe (fig.4.10). Practica uzual de construire a modelelor structurii organizaional -structural susine dou nivele de detalizare: modelul agregat; modelul detalizat. Modelul agregat este 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 analizei privind corespunderea structurii date strategiei i mediului nconjurtor al companiei. Modelul poate de asemenea pus la dispoziia utilizatorilor externi (de exemplu, investitorilor poteniali sub form de ilustrare a planului business, clienilor mari .a.). Modelu detalizat este 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 (crearea unor regulamente organizaionale). Scopul construirii acestui model este prezentarea informaiilor despre repartizarea obligaiunilor funcionale ntre subdiviziunile companiei, ca i despre organizarea proceselor business n companie. Construirea modelului detalizat permite crearea diferitor regulamente interne, cum ar fi Dispoziia despre structura organizaional (fig. 4.13).

Fig. 4.13. Schema elaborrii Dispoziiei despre structura organizaional-funcional

Mai jos este prezentat un exemplu de descriere a unor fragmente ale modelului organizaional funcional a unei ntreprinderi (fig. 4.14) i a unei uniti comerciale (fig. 4.15) Matricele proiecii lor prezentate servesc drept baz pentru evidenierea proceselor business ale companiei i stabilirea posesorilor lor n cadrul urmtoarelor etape de creare a sistemului informaional.

Fig. 4.14. Repartizarea funciilor pe subdiviziuni (ntreprindere)

Fig. 4.15. Repartizarea funciilor pe subdiviziuni (unitate comercial) Funciile subdiviziunilor unei ntreprinderi productoare sunt prezentate pentru urmtoarele domenii funcionale: management corporativ; finane; personal; resurse materiale; comenzi; producere; elaborare produse; planificare; aprovizionare/achiziii; calitate; furnizare/vnzri. Pentru unitatea comercial au fost alese alte domenii funcionale (fig. 4.15). Henry Fayol, acreditat ca iniiatorul conceptului, a considerat c sunt cinci funcii principale, n cuvintele lui: "S conduci nseamn s prevezi, s planifici, s organizezi, s comanzi, s coordonezi i s controlezi". Desigur c ali cercettori au venit cu alte listri, dar o cercetare a literaturii de specialitate ne arat c funcii principale ale managementului sunt considerate urmtoarele: planificarea, organizarea, supravegherea (comanda), motivarea, direcionarea, coordonarea, controlul, comunicarea, investigarea, evaluarea, decizia, personal, reprezentarea i neg ocierea.

4.4.

Mijloace instrumentale pentru modelarea organizaional

Utilizarea tehnologiilor moderne pentru modelarea organizaional conduc la diminuarea substanial a timpului necesar pentru modelare. La nceputul anilor 1990 au aprut primele instrumente program dedicate problemelor de organizare a managementului ntreprinderilor. Orgware o nou clas de programe era orientat pe soluionarea problemelor de sistematizare, pstrare i prelucrare a informaiilor necantitative din business, care anterior nu aveau susinere adecvat de calculator. BIG-Master a fost primul produs rus, creat sub form de instrument de calculator pentru susinerea concepiei de management numit management regulat. Obiectivul principal al Orgware era trecerea la proceduri i regulamente strict documentate. La baza paradigmei computaionale a managementului regulat este pus abordarea: Trebuie de creat nu un sistem de documente legate reciproc, ci un sistem de modele informaionale intercorelate, care vor genera documentele necesare. Baza conceptual a BIG-Master este abordarea procesual a organizrii activitii ntreprinderii. La nivelul superior sistemul de procese este descris de arborele funciilor (pentru care adesea este folosit termenul funcional). Funciile la acest nivel sunt considerate procese comprimate. Toate procesele-funcii trebuie, minimum, definite (adic identificate ca tip de activitate cu obiectiv i rezultate) i clasificate pe tipuri (de baz, auxiliare, de management) . De asemenea, trebuie s fie repartizate responsabilitile i mputernicirile de administrare a proceselor n baza regulamentelor. Pentru descrierea companiei BIG-Master utilizeaz la acest nivel dou tipuri de modele: arborescente (clasificatoarele) i mariceale (proieciile). La nivelul inferior procesele evideniate (procesele cheie) pot fi descrise sub forma unei succesiuni de operaii tehnologice (obinerea rezultatelor). Pentru aceasta sunt utilizate modelele flux ale proceselor business, destinaia crora este descrierea relaiilor orizontale n cadrul ntreprinderii, care leag ntre ele obiectele descrise anterior, prin fluxuri informasionale i materiale. Pentru analiza structural i proiectarea proceselor, descrise de modelele de flux, BIG -Master utilizeaz tehnologia SADT (IDEF). Prezena mecanismului proieciilor matriceale permite determinarea i descrierea proceselor companiei sub forma unui sistem interconectat unitar. Deoarece clasificatoarele au o structur ierarhic modelul business include relaiile funcieexecutor pentru toate nivelele de detalizare, ceea ce permite cu ajutorul generatorului de rapoarte, configurarea pentru obinerea unor vederi asupra companiei referitor la o problem concret de management. Sistemul de proiecii permite reflectarea n raport a oricror caracteristici suplimentare pentru un obiect concret (de exemplu, cerine privind calificarea personalului implicat n proces). Suplimentar, vederea companiei poate fi legat cu orice coordonat , de exemplu, document sau colaborator care sunt procesele i cum sunt implicai. Clasificatoarele, proiecile i modelel flux ale proceselor business potfi vizualizate n diferite moduri. Pentru clasificatoare liste i arbori (grafuri orientate), pentru proiecii liste legate i matrice transpuse, iar pentru modelele de flux ale proceselor business diagrame IDEF0 (IDEF3) i descriere textual, ceea ce faciliteaz nelegerea problemelor de ctre participani. Construirea modelelor de flux are loc sub forme obinuite tabelare. n model este posibil formarea unui numr nelimitat de clasificatoare, proiecii i medele de flux, s ca rezultat, rapoarte i documente pentru descrierea i crearea regulamentelor de activitate. Prezena n BIG-Master a ctorva instrumente de modelare este foarte util. Modelele matriceale susin integrarea vertical descrierea sistem-obiectiv detaliat, conform ierarhiei i funciilor. n modelul procesual domin abordarea funcional-tehnologic integrarea orizontal a operaiilor business pe proceduri. Aceste posibiliti asigur simplitatea i comoditatea modelrii organizaionale folosind instrumentul BIG-Master.

5. Specificarea cerinelor funcionale


Modele procesuale de flux. Abordarea procesual a organizrii activitii organizaiei. Legtura dintre concepia abordrii procesuale i concepia organizrii matriceale. Elementele principale ale abordrii procesuale: graniele procesului, rolurile cheie, arborele obiectivelor, arborele funciilor, arborele indicatorilor. Evidenierea i clasificarea proceselor. Procesele de baz, procesele auxiliare, procesele de management. Modele de referin. Studiul preprpoiect a organizaiei. Anchetarea, sondajul, fotografia timpului de lucru al personalului. Rezultatele studiului preproiect.

5.1.

Modele de flux procesuale

Elaborare cerinelor sistemului proiectat are loc n baza descrierii statice i dinamice a companiei. Descrierea static, prezentat mai sus, se produce la nivelul modelelor funcionale i include potenialul business, funcionalul i matricele de responsabi litate. Dezvoltarea ulterioar (detalizarea) a modelului business are loc la etapa descrierii dinamice a companiei la nivelul modelelor de flux procesuale. Modelele de flux procesuale sunt modelele, care descriu procesul de transformare succesiv n timp a fluxurilor materiale i informaionale n cadrul realizrii 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 (fig. 4.3). Situaia economiei la moment este caracterizat de trecerea de la modelul funcional tradiional de activitate a companiei, construit pe principiile diviziunii mun cii, specializrii nguste i structurilor ierarhice rigide, la modelul procesual, bazat pe integrarea lucrrilor n jurul proceselor business. Dezavantajele principale al abordrii funcionale sunt: partiionarea tehnologiilor de executare a lucrului pe segmente separate, adesea independente ntre ele, executate de diferite subdiviziuni ; lipsa unei descrieri integre a tehnologiilor; dificultatea reunirii celor mai simple sarcini ntr-o tehnologie, care produce mrfuri sau servicii reale; lipsa responsabilitii executorilor de rezultatul final; costuri mari pentru coordonare, stabilirea interaciunilor, control .a.m.d.; lipsa orientrii spre client. Abordarea procesual deplaseaz accentele de la administrarea unor elemente structurale separate la managementul proceselor business, care leag activitatea tuturor elementelor structurale. Fiecare proces parcurge o serie de subdiviziuni, n ndeplinirea lui particip specialiti din diferite secii ale companiei. Frecvent poate fi observat situaia n care 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 permite eliminarea fragmentrii activitilor, decalajelor organizaionale i informaionale, dublarea, utilizarea neraional a resurselor financiare, materiale i de personal. Abordarea procesual a organizrii activitii intreprinderii presupune: delegarea larg a mputernicirilor i responsabilitilor utilizatorilor; diminuarea nivelelor de luare a deciziilor; combinarea principiului managementului pe obiecte cu organizarea lucrului b grup; atenie sporit la asigurarea calitii; automatizarea tehnologiilor de exectuare a proceselor business. n conformitate cu standardul ISO 9000:2000 (p. 2.4) noiunea "Abordare procesual" este defint astfel: "Orice activitate sau set de activiti n care sunt utilizate resurse pentru transformarea intrrilor n ieiri poate fi considerat proces. Pentru o funcionare rezultativ organizaiile trebui s defineasc i s administreze multiple procese interdependente i care

interacioneaz. Frecvent ieirea unui proces formeaz intrarea altui proces. Identificarea i managementul sistematic proceselor utilizate n cadrul organizaiei i, n special, interaciunii acestor procese poate fi considerat fiind abordare procesual. Principiul de baz al abordrii procesuale definete structurarea sistemului business conform activitii i procesele business ale organizaiei, i nu conform structurii organizaionale. Anume procesele business, care asigur rezultat relevant pentru consumator, prezint valoare i pentru specialitii, care proiecteaz sistemele informaionale. Modelul procesual al companiei trebuie s fie elaborat n conformitate cu urmtoarele poziii: 1. Nivelul superior al modelului trebuie s reflecte doar contextul diagramei interaciunea unicului proces contextual modelat al companiei cu lumea extern. 2. La nivelul 2 vor fi reflectate procesle business grupate tematic i legturile lor reciproce. 3. Fiecare activitate trebuie detalizat pn la procese business. 4. Descrierea unei operaii business elementar are loc folosind minispecificaiile. Abordarea procesual 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. Proelucrarea acestui model folosind diferite metode analitice permite s se verifice ct de raionale sunt procesele business, s se determine dac o operaie anume este orientat spre un produs final social relevant sau este o p rocedur birocratic redundant. n timpul analizei proceselor business sunt cercetate detaliat sferele de responsabilitate ale subdiviziunilor, conductorilor i angajailor. Sunt stabilite coordonatele propriectarilor proceselor business, n rezultat procesele nseteaz s fie orfani, sunt create condiii pentru dexvoltarea i implementarea sistemelor de stimulare i responsabilitate pentru rezultatele finale, sunt determinate momentele i procedurile de transferare a responsabilitii. Analiza i evaluare a proceselor business permite s abordm justificarea standardelor de performan a proceselor, riscurilor admisibile i un spaiu de libertate la luarea deciziilor, normative limit de cheltuieli de resurse pentru o unitate de efect. Totui, o companie curat procesual este mai degrab ilustrarea organizrii corecte a activitilor. n realitate, toate procrsele 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, care susin mulimea proceselor business unificate, divizate pe operaii, i managementul proceselor business integrate, obiectivul cruia este rutarea i coordonar ea proceselor unificate pentru ndeplinirea comenzilor operative ale clienilor i a proiectelor proprii ale organzaiei (fig. 5.1). Obiectivul principal al proiectrii organizaionale este determinarea compromisului optimal 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 toate 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. Atunci cnd compania ncepe s se orienteze spre procese foarte important devine rolul proprietarilor proceselor integrate interfuncionale, care au tangene cu multe domenii funcionale. n afar de aceasta, 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. Din aceast cauz prezentarea exerciiului bugetar drept problem organizaional (nu numai financiar) presupune delegarea mputernicirilor, adic a puterii (de care nu se refuz uor). Responsabilitatea adoptrii unor decizii financiare este delegat la nivele mai joase: ncheierea unui contract de plat, achiziii, reduceri de pre sau creditare .a.m.d. Aceasta permite simplificarea legturilor ntre subdiviziuni i diminuarea numrului de nivele verticale prin care trec documentele, adic este o

condiie necesar pentru realizarea schemei clasice de reinginerie.

Fig. 5.1. Schema managementului activitii companiei Ca i concluzie, orientarea pe procese implic modificarea structurii organizaionale, strutura devenind mai plat, ceea ce ilustreaz legtura strns ntre descrierea vertical a organizaiei (structur cu distribuirea responsabilitilor, mputernicirilor i relaiilor) i descrierea orizontal sistem de procese.

5.2.

Elementele de baz ale abordrii procesuale

n cadrul abordrii procesuale o ntreprindere este considerat sistem business sistem, care const dintr-o mulime de procese business legate, obiectivele finale ale crora este producerea de bunuri sau servicii. Procesul business este neles ca set de activiti de diferite tipuri, care creeaz rezultat cu valoare pentru consumator. Procesul business este un lan de lucrri (funcii) rezultatul cruia este un bun sau un serviciu oarecare. Fiecare proces business are graniele sale (v. p. 6 i 7) i roluri. Exist urmtoarele roluri cheie: Proprietarul procesului este persoana responsabil de mersul i rezultatele procesului n totalitate. El trebuie s cunoasc procesul business, s urmreasc ndeplinirea i s perfecioneze eficacitate lui. Proprietarul procesului business trebuie s fie comunicabil, cu entuziasm, s poat influena oamenii i s produc schimbri. Liderul echipei este un colaborator cu cunotine n domeniul procesului business i caliti personale pozitive. Comunicatorul este lucrtorul care instruiete echipa n metodele de lucru, mpreun cu liderul pregtete edinele echipei i analizeaz rezultatele lor. Coordonatorul procesului lucrtorul reponsabil cu lucrul coordonat al tuturor prilor afacerii i care asigur legtura cu alte procese business. Coordonatorul trebuie s posede capaciti administrative i s neleag obiectivele strategice ale ntreprinderii. Membrii echipei sunt specialiti de diferite nicele de ierarhie. Membrii echipei sunt susinui i asigurai metodic de consultant i comunicator; mpreun cu liderul modeleaz, analizeaz i estimeaz procesul business. 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. Manager situaional specialist de calificare nalt, care poate ndeplini independent pn la 90% din volumul de lucru. O sarcin important a abordrii procesuale este formare echipelor procesuale. Pregtirea i formarea echipei include: cursuri de instruire; formare practic (training) pentru asimilarea metodelor, metodicilor .a.; testare compatibilitate psihologic; testarea aptitudinilor practice. 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. Procesele business realizeaz funciile business ale ntreprinderii. Prin funcie business nelegem un tip de activitate a ntreprinderii. Mulimea funciilor business reprezint decompoziia ierarhic a activitii funcionale a ntreprinderii i se numete arbore al funciilor. Funciile business sunt legate de 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. Cei mai frecveni indicatori de msurare a performanei proceselor de afaceri sunt: cantitatea de produse de calitate stabilit ntr-un anumit interval de timp; cantitatea de produse utilizate; durata ndeplinirii operaiilor-tip .a.

5.3.

Selectarea i clasificarea proceselor

Minimum dou probleme trebuie soluionate la descrierea procesual: 1. Identificarea ntregului sistem de domenii funcionale i a proceselor companiei, ca i legturile reciproce ntre procese. 2. Selectare proceselor integrate cheie i descrierea lor la nivelul fluxurilor. 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 pentru descrierea fluxurilor, necesar, de exemplu, pentru crearea sistemului informaional al ntreprinderii. 5.3.1. Tipuri de procese business Cele mai frecvente sunt urmtoarele patru tipuri de procese busi ness: 1. Procesele care creeaz cea mai mare plusvaloare (valoarea economic, care este determinat prin contrapunerea cheltuielilor cu producia finit); 2. Procesele care creeaz cea mai mare valoare pentru clieni (valoarea de marketing din contul diferenierii produciei). 3. Procesele cu cea mai intensiv interaciune ntre verigi de producie, care creeaz costuri tranzacionale. 4. Procesele definite de standardele ISO 9000 ca fiind obligatorii pentru descrierea i implementarea sistemului de management al calitii. Un pas foarte important la structurarea unei companii este evidenierea i clasificarea proceselor

business. Sunt recomandate urmtoarele categorii de procese: de baz (principale); de management; de asigurare; auxiliare; de dezvoltare. Figura 5.2 prezint modelul activitii unei companii la descrierea creia sunt utilizate procesele de management, procesele business de baz i de asigurare.

Fig. 5.2. Modelul simplificat al activitii companiei Procesele business de baz sunt procesele orientate pe producerea mrfurilor i prestarea serviciilor, care reprezint valoare pentru clieni i asigur obinerea beneficiului. 5.3.2. Procesele de baz Procesele de baz formeaz ciclul de via al produciei companiei. Criteriul de efectivitate al acestor procese este calitatea, exactitatea i punctualitatea executrii fiecrei comenzi. Muli consumatori consider sporirea nivelului de calitate mai important dect diminuarea preului. Un vnztor iscusit poate obine, n condiii de concuren, comand pentru executarea unor lucrri, ns doar calitatea produsului sau serviciului va determina dac clientul va mai veni n viitor la acest vnztor. Procese din aceast categorie, ntr-o companie cu activitate susinut, pot fi multe. Toate trebuie descries pe lanuri producere-comerciale: interaciunea primar cu clientul i determinarea cerinelor acestuia realizarea solicitrii (cererii, comenzii, contractului) support post-vnzare i monitorizarea satisfacerii necesitilor. Procesul realizarea (solicitrii clientului) poate fi descompus n urmtoarele subprocese procese de nivel mai jos: elaborarea (proiectarea) produciei; achiziii (bunuri, materiale, componente); transportarea (achiziiilor); descrcarea, primirea la depozit i pstrarea (cumprturilor); 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. Aceste lanuri de asemenea sunt relativ standardizate (de exemplu, n standardul ISO redacia anului 1994 multe din aceste procese sunt obligatorii i trebuie certificate. Utiliznd proiecia fiecrui business, produs sau serviciu (dintre cele selectate) pe clasificatorul standard (de mai sus) al ciclului de via sau de producie putem verifica care lanuri business exist la ntreprindere. Pentru estimarea etapelor de lucru cu orice document putem utiliza de asemenea analiza ciclului de via a documentului, care poate fi dup cum urmeaz: prezint datele iniiale; pregtete, elaboreaz; completeaz; corecteaz; perfecteaz; semneaz;

verific conformitatea cu cerinele stabilite; vizeaz; coordoneaz; aprob; accentueaz (ia n consideraie, utilizeaz); pstreaz; face o copie.

Aici poate fi utilizat propria matrice-generator n calitate de instrument pentru verificarea completitudinii identificarea ciclului. Pot fi de asemenea utilizate modelele de referin ale activitii unor companii analogice pot fi comparate cu procesele din firmele concurente, lider ai ramurii, i perfectate. 5.3.3. Procesele de management Procese de management sunt procesele, care acoper tot complexul de funcii de management la nivelul fiecrui proces business i sistemului business n ntregime. Pr ocesele de management au drept obiectiv pregtirea i adoptarea deciziei administrative. Deciziile administrative pot fi luate referitor pentru ntrega organizaie, pentru un domeniu funcional separat sau pentru procese separate, de exemplu: management strategic; proiectarea organizaional (struturizarea); marketing; administrare financiar-economic; logistica i organizarea proceselor; managementul calitii; personalul. Alt sistematizare posibil a funciilor de management este legat de noiunea ciclu de management i se bazeaz pe cinci funcii iniiale ale managementului: planificare, organizare, administrare, coordonare i control. Cea mai frecvent greeal este amestecarea acestor principii. Pentru realizarea descrierii procesuale este extrem de i mportant, c orice activitate managerial se desfoar n conformitate ciclul managerial care include: colectarea informaiei; elaborarea deciziei; realizarea; evidena; controlul; analiza; reglarea. Cele mai frecvente variante de detalizare sunt: colectarea informaiei; determinarea coninutului informaiei colectate; stabilirea formelor de raportare; elaborarea soluiei; analiza alternativelor; pregtirea variantelor decizionale; adoptarea deciziei; elaborarea criteriilor de estimare; realizarea; planificarea; organizarea; motivarea; stimularea; coordonarea controlul ndeplinirii;

evidena rezultatelor; compararea conform criteriilor; analiza; analiza informaiilor suplimentare; diagnoza posibilelor cauze de deviere; reglare; reglare la nivelul realizrii (ntoarcere la p. 3); reglare la nivelul elaborrii deciziilor (ntoarcere la p. 1, 2).

Fiecare din etapele de mai sus are 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). Conform unor abordri recente, pentru procesul de managemeng sunt evideniate dou tipuri de procese, asociate respectiv de dou tipuri de management, convenional notate managementul resurselor i managementul organizrii, care difer prin obiectul administrat, modelele de baz i, ceea ce este important pentru descrierea proceselor ciclurile manageriale proprii. n aa mod, modelul activitii ntreprinderii este cu dou nivele (fig. 5.3).

Fig. 5.3. Modelul pe dou nivele al activitii ntreprinderii Din acest model rezult, c ciclurile de planificare a resurselor trebuie reglamentate, adic managementul resurselor poate fi efectuat doar utiliznd regulamente organizaionale special elaborate. La baza ciclului de management al resurselor sunt puse calculele sau modelarea imitaional i controlul rezultatelor: alegerea (sau receptarea de la un sistem de nivel superior) a criteriului obiectiv de estimare a calitii deciziei; colectarea informaiilor privind resursele ntreprinderii sau posibilitilor mediului exterior; calculul variantelor (pentru diferite ipoteze privind posibilele valor ale parametrilor); alegerea variantei optimale adoptarea deciziei (= planului de resurse); evidena rezultatelor (i raportarea); compararea cu criteriul adoptat de estimare (=controlul rezultatelor); analiza cauzelor devierilor i reglarea (ntoarcere la 1, 2 sau 3). La baza ciclului de management organizaional st modelarea structural sau procesual i controlul procedural: determinarea componenei lucrrilor (funciilor separate, operaiilor); selectarea executorilor (- distribuirea zonelor i nivelelor de responsabilitate); proiectarea procedurilor (succesiunea i ordinea de execuie); coordonarea i aprobarea regulamentului de execuie (- a procesului, planului de aciuni); raportarea despre executare;

controlul executrii (-control procedural); analiza cauzelor devierilor i reglarea (ntoarcere la 1, 2 sau 3)

Astfel, la anumii pai ai decompoziiei ntreprinderea trebuie s determine care sunt etapele ciclului de management ce vor fi realizate pentru fiecare din activitile de management selectate anterior. Aceasta poate fi verificat folosind matricea-generator, care repartizeaz componentele managementului pe etape ale ciclului managerial. 5.3.4. Procesele de asigurare Procese de asigurare sunt procesele destinate posibilitatea desfurrii proceselor de baz i auxiliare i care sunt orientate spre susinerea mijloacelor universale ale acestora. De exemplu, procesul de asigurare financiar, procesul de asigurare cu personal, procesul de asigurare juridic sunt procese secundare. Ele creeaz i menin condiiile necesare pentru ndeplinirea funciilor principale i funciilor de management. Clienii proceselor auxiliare se afl n interiorul companiei. La nivelul superior de detaliere pot fi evideniate urmtoarele procese auxiliare stadard: asigurarea producerii; asistena tehnic i reparaia echipamentelor; asigurarea cu resurse energetice i termice; deservirea i reparaia cldirilor i construciilor; asigurarea tehnologic; asigurarea metrologic; securitatea muncii; controlul ecologic; asigurarea managementului; asigurarea informaional; asigurarea circulaiei documentelor; asigurarea comunicaional; asigurarea juridic; asigurarea securitii; asigurarea tehnico-material a managementului; asigurarea gospodreasc; asigurarea cu servicii comunale; asigurarea cu transport etc. Pentru fiecare dintre subprocesele evideniate mai sus trebuie de asemenea s se determine, care proces de baz sau de managemnt este consumatorul acestor servicii interne. Pentru aceasta din nou vor fi utilizate matricele-generatoare, care pot fi construite separat pentru procesele de baz (fig. 5.4) i procesele de management (fig. 5.5).

Fig. 5.4. Matricea-generator simplificat a proceselor business auxiliare Divizarea acestor procese are loc pe lanuri tehnologice individuale. Multe procese auxiliare sunt de tip standard pentru toate companiile sau pentru anumite tipuri de activitate: industrie, comer, prestri servicii .a. ns, de obicei, aceast clas de funcii ntr-o msur mai mic poate fi descris prin fluxurile procesuale. Majoritatea poate fi reglementat cu ajutorul instruciunilor.

Fig. 5.5. Matricea-generator a funciilor business auxiliare 5.3.5. Modelul business de referin Ca i cadru de baz, care aduce mpreun i organizeaz toate cunotinele despre modelul de afaceri, poate fi folosit modelul de referin. Modelul 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. De fapt, modelele de referin sunt 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 este un set de funcii legate logic. Pentru fiecare funcie este specifica 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 responsabil i), situate n depozitul proiectului. De aici i numele - modelul de referin (n englez, reference model).

5.4.

Analiza activitii ntreprinderii

Studiul de analiz a activitii intreprinderii este o etap foarte important i determinant pentru proiectarea SI. Durata studiului este de 1-2 sptmni. n acest rstimp analistul va studia maximum 2-3 tipuri de activiti (serviciul de personal, contabilitatea, departamentul transporturi, marketing etc.). Culegerea informaiilor pentru construirea modelului business complet a organizaiei adesea se reduce la studierea fluxurilor informaionale i funciilor documentate ale subdiviziunilor, de asemenea poate fi utilizat interviul i sondajul. La lansarea studiului organizaia prezint, de obicei, un set de documente cu urmtoarea componen posibil: 1. Informaii sintetice despre activitatea ntreprinderii: Informaii privind activitatea de management, economico-financiar, de producere. Informaii privind politica de eviden i raportare. 2. Managementul documentelor: Registrul informaiilor de intrare (tab. 5.1). Registrul informaiilor interne (tab. 5.2). Registrul informaiilor de ieire (tab. 5.4). 3. Informaii privind infrastructura informaional. 4. Informaii privind persoanele responsabile.

Tabelul 5.1. Registrul informaiilor de intrare (Denumirea ntreprinderii) Nr. Denumirea i destinaia documentului (Denumirea subdiviiunii) Cine prelucreaz De la cine a venit Caracterul prelucrrii documentelor Complexitatea Periodicitatea, regulamentul Cum a fost obinut

Tabelul 5.2. Registrul informaiilor de interne (Denumirea ntreprinderii) (Denumirea subdiviziunii) Cui va fi transmis Caracterul prelucrrii documentelor Complexitatea Periodicitatea, regulamentul Cum a fost obinut Nr. Denumirea i destinaia Cine documentului prelucreaz (Denumirea ntreprinderii) Nr. Denumirea i destinaia documentului

Tabelul 5.3. Registrul informaiilor de ieire (Denumirea subdiviziunii) Caracterul prelucrrii documentelor Cine prelucreaz Destinatar Complexitatea Periodicitatea, Cum a fost regulamentul obinut

Listele cu ntrebri pentru interviuri i sondaje sunt alctuite pentru fiecare dapartament studiat i este aprobat de conductorul companiei. Aceasta se face cu scopul: prevenirii accesului la informaii confideniale; consolidrii nivelului de direcionare a studiului; minimizrii distragerii angajailor de la ndeplinirea sarcinilor de baz. Lista general a ntrebrilor (cu detalizarea ulterioar) include urmtoarele puncte: obiectivele principale ale subdiviziunii; informaia colectat i nregistrat; modul de raportare; interaciunea cu alte subdiviziuni. Anchetele pentru conductori i specialiti pot conine urmtoarele ntrebri: Care (din punctul de vedere al departamentului DVS) trebuie s fie obiectivele crerii sistemului informaional integrat? Structura organizaional a departamentului. Obirctivele departamentului. Succesivitatea aciunilor pentru ndeplinirea lucrrilor. Care sunt tipurile de organizaii externe (bnci, clieni, furnizori etc.) cu care interacioneaz departamentul i care subt achimburile de informaii? Care este materialul de referin folosit? Ct timp cheltuii (n minute) pentru executarea operaiilor de baz? Care sunt zilele cu ncrcare maxim (periodicitatea pentru o lun, semestru, an, etc.)? Asigurarea tehnic a departamentului (claculatoare, reea, modem, etc.). Produsele program pentru automatizarea proceselor business. Care sunt rapoartele i periodicitatea pregtirii lor pentru conducere? Specialitii cheie ai departamentului, care pot rspunde la orice ntrebare legat de procesele business. Caracteristicile obiectelor distribuite geografic. Managementul documentelor la locul de lucru. Datele colectate n aa mod, de obicei, nu acoper toate domeniile relevante de activitate organizaional i posed un nivel nalt de subiectivism. Dar cel mai important este faptul, c studiile de acest gen nu identific factorii stabili, legai de particularitile specifice ale ntreprinderii, care pot fi influenai excluisv prin metode de ajustare funcional a sistemului organizaional. Analiza sondajelor conductorilor organizaiilor studiate arat, c punctul lor de vedere referitor la structura organizaiei, obiectivele generale i locale ale funcionrii, obiectivele i funciile departamentelor, ierarhia lucrtorilor adesea au un caracter contradictoriu. n plus, aceste puncte de vedere difer adesea de la scopurile i normele declarate oficial sau contra vin activitilor efective. Structura fluxurilor informaional poate fi stabilit folosind formularele documentelor i configuraia

reelelor de calculatoare i a bazelor de date. ns structura microproceselor reale, executate de persoanl n contactele informaionale (n mare parte nedocumentate) rmne necunoscut. Rspunsuri la aceste ntrebri poate oferi o diagnosticare structural-funcional, bazat pe metodele de fotografiere continu (sau eantionat), a timpului de lucru a personalului. Scopul diagnosticrii const n obinerea unor cunotine de ncredere despre organizaie i relaiile organizaionale ale elementelor sale funcionale. n acest sens, cea mai important sarcin de diagnosticare funcional a structurilor organizatorice sunt: clasificarea subiecilor funcionrii (categorii i grupuri de lucrtori); clasificarea elementelor procesului de funcionare (aciuni, procedure); clasificarea direciilor (problemelor soluionate), obiectivelor funcionrii; clasificarea elementelor fluxurilor informaionale; cercetarea activitii personalului organizaiei; studierea repartizrii (n timp i frecven) a caracteristicilor organizaionale: proced ure, contacte, direcii de activitate, elemente ale fluxurilor informaionale individual i n combinaie pentru categorii de lucrtori, tipuri de procedure i direciile lor (conform rezultatelor i logicii studiului); identificare structurii reale a relaiilor funcionale, informaionale, ierarhice, temporale ntre conductori, colaboratori i departamente; stabilirea structurii repartizrii timpului de lucru al conductorilor i personalului conform funciilor, problemelor i obiectivelor organizaiei; identificarea tehnologiilor-cheie de funcionare (proceselor informaionale, inclusive i nedocumentate), stabilirea obiectivelor lor, n comparaie cu obiectivele declarate ale organizaiei; identificarea grupurilor omogene de lucrtori, conform specificului activitii, obiectivelor i subordonrii reale, formarea modelului real al structurii organizaionale i compararea cu structura declaratr; determinarea cauzelor de necoinciden a structurilor relaiilor organizaionale declarate i reale. O fotografiere continu a timpului de lucru se numete observarea permanent i nregistrarea caracteristicilor lucrtorilor n procesul fiuncionrii pe toat durata zile de lucru. Pe tot parcursul acestor activiti parametrii selectai sunt introdui nr -un tabel pregtit din timp. Prezentm mai jos forma tabelului de lucru al analistului de sistem.

Imediat dup finalizarea procedurii de cercetare tabelul este completat cu caracteristici suplimentare: ramura tehnologic, funcie de sistem, obiectul, aspectul, fonul emoional .a. O parte a indicatorilor (notai cu stelu) vor fi completai n procesului studiului, restul dup. Coninutul nregistrrilor va include: numrul de ordine; agentul (funcia lucrtorului studiat); timpul ct a durat procedura; procedura (denumirea setului de aciuni elementare, reunite prin obiectivul problemei particulare soluionate; coninutul (esena procedurii, care trebuie clasificat); informaia (direcia de transmitere a informaiei ntre agent i contrage nt); iniiativa (iniiatorul nceperii procedurii); contragent (funcia lucrtorului care se afl n contact cu agentul); relaia (de subordonare, forma de interaciune ntre agent i contragent) ; problema (caracteristica verbal a problemei soluionate).

5.5.

Rezultatele etapei de analiz

Rezultatul etapei de cercetare va fi documentul Raport despre studiul expres al activitii ntreprinderii, structura cruia este prezentat mai jos. 1. Descrierea succint schematic a proceselor business: managementul achiziiilor i a rezervelor; managementul producerii; managementul vnzrilor; managementul resurselor financiare. 2. Cerinele de baz i prioritile automatizrii. 3. Estimarea resurselor clientului, necesare pentru asigurarea proiectului. 4. Evaluarea posibilitii automatizrii, propuneri privind crearea sistemului automatizat cu estimarea aproximativ a termenilor i costurilor. Documentele, care fac parte din raport pot fi prezentate n form textual sau tabele, forma aproximativ a crora este adus mai jos.
Nr. crt Denumirea procesului business 1. 2. 3. 4. 5. 6. 7. Vnzri: n reea, engros Planul de achiziii Plasare comenzii de producere Producere proprie Achiziii de materii prime Pli Alte

Formular posbil pentru descrierea operaiilor procesului business:


Operaie Executor Frecvena Documente de intrare Document de ieire (document creat) (documente justificative)

Formular posbil pentru descrierea documentelor procesului business:


Document creat (document la Operaie Cine creeaz ieire) (executorul) Frecvena Documente justificative (documente la intrare)

Cercetare preproiect permite soluionarea urmtoarelor probleme: stabilirea prealabil a cerinelor sistemului nou; determinarea structurii organizaiei; identificarea listei funciilor-obiectiv; analiza distribuirii funciilor pe departamente i colaboratori; identificarea interaciunilor funcionale ntre departamente, fluxurilor informaionale n i ntre subdiviziuni, influenelor informaionale externe ; analiza mijloacelor de automatizare existente. Informaiile, obinute n rezultatul cercetrilor preproiect, vor fi analizate folosind metodele analizei structurale i/sau obiectuale i vor fi utilizate pentru construirea modelului activitii organizaiei. Modelul organizaiei presupune construirea a dou tipuri de modele: modelul cum este (as is), care reflect situaia existent n organizaie la momentul cercetrii, permite nelegerea modului de funcionare a organizaiei date, identificarea locurilor nguste cu formularea propunerilor privind perfecionrile posibile; modelul cum trebuie s fie (to be), care reflect modul de lucru cu utilizarea tehnologiilor noi. Fiecare din cele dou modele include modele funcional i informaional complete, ca i modelul care descrie dinamica comportamentului organizaiei (la necessitate).

6. Metodologia modelrii domeniului obiectiv

Metodologii pentru modelarea domeniului obiectiv. Modelul structural al domeniului obiectiv. Structura obiectual. Structura funcional. Structura conducerii. Structura organizaional. Metodologii orientate funcional i orientate obiect de descriere a domeniului obiectiv. Mtoda funcional IDEF. Metoda funcional a fluxurilor de date. Metoda obiect-orientat. Compararea metodelor existente. Metoda sintetic.

6.1.

Modelul structural al domeniului obiectiv

La baza proiectrii sistemelor informaionale st modelareaa domeniului obiectiv. Pentru a realiza un proiect al SI adecvat domeniului obiectiv (sub forma unor programe, care lucreaz corect) este necesar s avem o imagine integr, sistemic a modelului, care s reflecte toate aspectelefuncionrii noului sistem informaional. n acest caz, prin noiunea de model al domeniului obiectiv vor considera sistemul, care imit structura sau funcionarea domeniului obiectiv cercetat i care respect cerina de baz corespunde acestui domeniu. Modelarea prealabil a domeniului obiectiv permite s fie diminuate timpul i termenele efecturii lucrrilor de proiectare i s fie obinut un proiect mai efectiv i mai calitativ. Fr modelaria domeniului obiectiv este mare probabilitatea unui numr mare de erori la soluionarea problemelor strategice, care vor conduce la pierderi i cheltuieli suplimentare pentru lichidarea erorilor. Reieind din aceste considerente, toate tehnologiile de proiectare moderne sunt bazate pe tehnologia modelrii domeniului obiectiv. Modelele domeniului obiectiv vor respecta urmtoarele cerine: formalizarea, care asigur descrierea univoc a structurii domeniului obiectiv; comprehensibiltate pentru clieni i dezvoltatori bazat pe utilizarea unor instrumente grafice de vizualizare a modelului; realizabilitate, care presupune existena mijloacelor de realizare fizic a modelului n SI; asigurarea posibilitii de a evalua efectivitatea realizrii modelului domeniului obiectivn baza unor metode acceptate i indicatori calculabili.. Pentru realizarea acestor cerine, de regul, este construit un sistem de modele, care reflect aspectele structural i estimativ al funcionrii domeniului obiectiv. Aspectul structural presupune construirea: structurii obiectuale, care reflect componena obiectelor materiale i informaionale ale domeniului obiectiv, care interacioneaz n cadrul proceselor; structurii funcionale, care reflect legturile reciproce ale funciilor (aciunilor) atunci cnd obiectele sunt transformate; structurii managementului, care reflect interaciunea unitilor organizaionale ale ntreprinderii i a personalului; structurii tehnice, care descrie topologia plasrii componentelor fizice i modalitile de comunicare ntre ele. Pentru reflectarea aspectului structural al modelelor domeniului obiectiv sunt utilizate metode grafice, care trebuie s garanteze prezntarea informaiilor despre componentele sistemului. Cerina principal referitor la metodele grafice de documentare este simplitatea. Metodele grafice trebuie s asigure posibilitatea decompoziiei structurale a specificaiilor sistemului cu un grad maxim de detalizare i coordonarea descrierilor pentru nivele adiacente de decompoziie. Direct de modelare este asociat problema alegerii limbajului de prezentare a soluiilor de proiect, care s permit atragerea a unui numr ct mai mare de viitori utilzatori la elaborarea soluiei. Limbajul de modelare este notaia, de obicei grafic, care este utilizat pentru descrierea proiectului. Notaia este setul de obiecte grafice, utilizate n model. Notaia este sintaxa limbajului de modelare. Limbajul de modelare, pe de o parte trebuie s fac soluiile proiectanilor nelese utlizatorului, iar pe de alt parte, s pun la dispoziia proiectanilor mijloace pentru identificarea soluiilor de proiect suficient de formalizate i univoce, care vor fi realizate sub forma unor seturi de programe sistem integru de resurse program. Imaginile grefice reprezint forma cea mai Imaginea grafic este adesea forma cea mai cuprinztoare de prezentare. n acest caz, proiectanii

ar trebui s fie contieni de faptul c metodele grafice de documentare nu pot descompune n totalitate soluiile de proiect de la enunul problemei pn la programe de calculator. Dificulti apar la trecerea de la etapa de analiz a sistemului la faza de proiectare, i n special la programare. Criteriul principal de adecvan a modelului structural al domeniului obiectiv este completitudinea funcional a sistemului informaional elaborat. Aspectele estimative ale modelrii domeniului obiectiv sunt legate de indicatorii de eficien a proceselor automatizate, la care pot fi plasai: timpul de soluionare a problemelor; preurile de cost pentru procesare datelor; fiabilitatea proceselor; indicatori indireci de eficin, cum sunt volumul produciei, productivitatea muncii, rulajul capitalului, rentabiltatea etc. Pentru calcularea indicatorilor de eficien sunt utilizate, de obicei , metodele statice ale analizei funcii-cost i metodele modelrii imitaionale. La baza metodologiilor modelrii domeniului obiectiv al SI se afl principiile detalizrii succesive a categoriilor abstracte. De obicei, modelel sunt construite pe trei nivele: extern (determinarea cerinelor), conceptual (specificarea cerinelor) i intern (realizarea cerinelor). La nivelul extern modelul rspunde la ntrebarea ce trebuie s fac sistemul, adic este stabilit lista componentelor principale ale sistemului: obiecte, funcii, evenimente, untii organizaionale, mijloace tehnice. La nivelul conceptual modelul rspunde la ntrebarea cum trebuie s funcioneze sistemul? Cu alte cuvinte, la acest nivel este determinat caracterul interaciunii componentelor sistemu lui. La nivelul intern modelul rspunde la ntrebarea: care sunt mijloacele tehnice i logice necesare pentru realizarea cerinelor sistemului? De pe poziiile ciclului de via a sistemului informaional nivelele descrise ale modelului sunt construite respectiv la etapele de analiz a cerinelor, proiectrii logice (tehnice) i proiectrii fizice. Vom analiza particularitile construirii modelului domeniului obiectiv pentru cele trei nivele de detalizare. 6.1.1. Structura obiectual Obiectul este entitatea utili zat la executarea unei funcii sau operaii (transformare, procesare, formare etc.). Obiectele pot fi statice sau dinamice: obiectele dinamice sunt utilizate ntr-un singur ciclu de reproducere, de exemplu comenzile de produse, bonuri de plat, pli. Obi ectele statice sunt utilizate n mai multe cicluri de reproducere, de exemplu echipamentele, personalul, rezervele materiale. La nivelul extern de detalizare a modelului sunt evideniate tipurile principale de obiecte materiale (de exemplu, materia prim, semifabricatele, produsele finite, serviciile) i informaionale sau documente (de exemplu, comenzile, bonurile de trsur, conturile etc.). La nivelul conceptual este specificat componena claselor de obiecte, sunt determinate atributele i legturile lor; are loc crearea unei imagini generale a structurii domeniului obiectiv. La nivel intern modelul conceptual este reflectat sub form de fiiere ale bazei de date, documente de intrare i ieire ale sistemului. Obiectele dinamice vor fi reprezentate prin uniti de informaii variabile sau documente, iar obiectele statice prin uniti de informaii convenional constante sub form de liste, nomenclatoare, liste de preuri, dicionare, clasificatoare. Modelul bazei de date, n calitate de resurs informaional meninut constant, reflect pstrarea informaiilor convenional-constante i informaiilor variabile cumulate, utilizate n procesele informaionale repetitive. 6.1.2. Structura funcional Funcia (operaia) este un fel de convertor al intrrilor n ieiri. Secvena de funcii legate reciproc pe intrri i ieiri se numete proces business. O funcia a procesului business poate genera obiecte de orice natur (materiale, informaionale, financiare). Procesele business i procesele informaionale, de regul, sunt inseparabile, adic funciile unui proces material nu pot fi efectuate

fr suport informaional. De exemplu, recepia produciei finite are loc n baza documentului Ordin, care, la rndul su, genereaz documentul nsoitor Factur. Funcia poate fi prezentat printr-o singur aciune sau o secven de aciuni. n ultimul caz fiecrei funcii poate corespunde un proces oarecare, care poate avea subprocese, .a.m.d., pn la momentul n care fiecare subfuncie va reprezenta o secven nedecompozabil de aciuni. La nivelul extern al modelrii este determinat lista fubnciilor business principale sau tipurilor de procese business. De obicei funcii de acest tip sunt n jur de 15 20. La nivelul conceptual funciile selectate sunt descompuse i sunt construite ierarhii de funcii interdependente. La nivelul intern structura ptocesului informaional este reflectat n calculator: sunt stabilite structurile ierarhice ale modulelor program, care realizeaz funciile automatizate. 6.1.3. Structura managementului n setul de funcii ale procesului business sunt posibile secvene alternative sau ciclice n dependen de condiiile n care are loc procesul. Aceste condiii sunt legate de evenimentele, care au loc n mediul extern sau n interiorul proceselor, ca i de anumite stri ale obiectului (de exemplu, comanda a fost acceptat, refuzat, transmis pentru introducerea unor corectri). Evenimentele genereaz execuia funciilor, care, la rndul lor, modific starea obiectelor i genereaz noi evenimente, .a.m.d., pn a terminarea procesului business. n acest caz vom spune, c secvena de evenimente reprezint o realizare concret a procesului business. Fiecare eveniment este descris din dou puncte de vedere: informaional i procedural. Un eveniment informaional este prezent sub forma unui mesaj, care fixeaz faptul ndeplinirii unei funcii de modificare a strii sau apariia unei stri noi. Un eveniment procedural apeleaz execuia unei funcii noi, din aceast cauz pentru fiecare stare a obiectului trebuie s fie specificate aceste apeluri. n aa mod, evenimentele au rolul de legtura n execuia funciilor proceselor business. La nivelul extern este determinat lista evenimentelor externe, generate de interciunea ntreprinderii cu mediul extern (plata impozitelor, procentelor pentru credite, contractelor etc.), i lista indicaiilor-obiective (consecin a obiectivelor organizaiei), crora trebuie s corespund procesele business (regulamentul de ndeplinire a proceselor, meninerea nivelului neces ar al rezervelor materiale, nivelul calitii produciei etc.). La nivelul conceptual sunt stabilite regulile business, care determin condiiile de apelare a funciilor la producerea unui eveniment sau trecerea procesuluintr-o stare anume. La nivelul intern are loc formalizarea regulilor business sub form de triggere sau apelri ale modulelor program. 6.1.4. Structura organizaional Prezint un set de uniti organizaionale, de regul, legate prin relaii ierarhice i procesuale. Unitatea organizaional este subdiviziunea, care reprezint reuniunea de oameni (personal) pentru ndeplinirea inui set de funcii comune sau procese business. ntr-o structur organizaional funcional-orientat unitatea organizaional execut un set de funcii, care fac parte dintr-un singur tip de procese i care au atribuie pentru diferite funcii de managemnt. La nivelul extern este construit modelul structural al ntreprinderii sub form de ierarhie de subordonare a unitilor organizaionale sau liste de subdiviziuni care interacioneaz. La nivelul conceptual pentru fiecare subdiviziune este stabilit structura organizaional a statelor (funciilor, rolurilor personalului). La nivelul intern sunt stabilite cerinele referitoare la drepturile personalului de accesare a funciilor automatizate ale SI. 6.1.5. Structura tehnic Topologia determin plasarea teritorial a resurselor tehnice n cadrul subdiviziunilor ntreprinderii,

iar comunicaiile modul tehnice de realizare a interaciunii subdiviziunilor structurale. La nivelul extern al modelului sunt determinate categoriile mijloacelor tehnice de prelucrare a datelor i distribuirea lor pe subdiviziuni structurale. La nivelul conceptual sunt identificate modalitile de organizare a comunicaiilor ntre resursele tehnice ale subdiviziunilor structurale: deplasarea fizic a documentelor, suporilor de memorie, schimbul de informaii prin canale de comunicaii etc. La nivelul intern este construit modelul arhitecturii client-server al reelei de calculatoare. Modelele descrise ale domeniului obieciv sunt direcionate spre proiectarea unor componente separate ale SI: date, module program funcionale, module program de gestiune, interfee ale utilizatorilor, structuri ale complexului tehnic. Pentru o proiectare mai calitativ a acesto r componente este necesar s fie construite modele, care s integreze componentele. n cel mai simplu caz n calitate de asemenea modele de interaciune pot fi utilizate matricele referinelor ncruciate: obiecte-funcii, funcii-evenimente, uniti organizaionale-funcii, uniti organizaionale-obiecte, uniti organizaionale-mijloace tehnice .a.m.d. ns aceste matrice sunt greu de neles i nu reflect particularitile realizrii interaciunilor. Pentru o reflectare corect a interaciunilor componentelor SI este important realizarea modelrii concomitente a acestor componente, n special din punctul de vedere al obiectelor i funciilor. Metodologia analizei structurale de sistem ajut semnificativ n rezolvarea acestor probleme. Analiza structural este numit metoda de cercetare a sistemului, care ncepe cu o imagine de ansamblu, iar apoi are loc detalierea printr-o structur ierarhic cu un numr tot mai mare de niveluri. Pentru aceste metode este caracteristic: divizarea pe nivele de abstractizare cu un numr limitat de elemente (de la 3 la 7); un context limitat, care include doar detaliile eseniale ale fiecrui nivel; utilizarea unor reguli formale stricte de notare; apropiere succesive la rezultat. Analiza structural se bazeaz pe dou principii fundamentale - "dezbina si cucereste" i principiul ordonrii ierarhice. Soluionarea problemelor dificile prin divizarea lor n mai multe sarcini independente mici (aa-numitele "cutii negre") i organizarea acestor sarcini n struct uri arborescente ierarhice n mod semnificativ sporesc nivelul de nelegere a sistemelor complexe. Mai jos sunt prezentate definiiile unor noiuni -cheie din domeniul analizei structurale. Operaie aciune elementare (indivizibil), excutat la un singu r loc de lucru. Funcie set de operaii, gruoate n funcie de anumii indicatori. Proces business set de funcii legate, n cadrul execuiei cruia sunt utilizate anumite resurse i este creat un produs (obiect, serviciu, descoperire tiinific, idee), care prezint valoare pentru consumator. Subproces proces business element structural al unui oarecare proces business i care prezint valoare pentru consumator. Model business descriere grafic structurat a unei reele de procese i operaii, l egate de date, documente, uniti organizaionale i alte obiecte, care reflect activitatea existent sau presupus a companiei. Exist diferite metodologii de modelare structural a domeniului obiectiv, printre care trebuie de evideniat metodologiile orientate pe funcii i orientate pe obiecte.

6.2.

Metodologii orientate pe funcii i orientate pe obiecte

Procesul modelrii business poate fi realizat n cadrul unor metode, care difer n primul rnd prin modul de abordare a organizaiei modelate. n conformitate cu acest criteriu exist metode funcionale (structurale) i metode orientate pe obiect. n cadrul metodelor obiect-orientate organizaia modelat este considerat set de obiecte, care

interacioneaz uniti de producie. Obiectul este definit ca model informaional al unei entiti din lumea real, care are proprieti i comportament specific. Scopul utilizrii unei metode obiect orientate este identificarea obiectelor, care formeaz organizaia, i reaprtizarea ntre obiecte a responsabilitilor pentru aciunile executate n cadrul organizaiei. Metodele funcionale, dintre care cea mai cunoscut este metoda IDEF, consier organizaia ca set de funcii, care transform fluxul de informaii la intrare n flux de ieire. Procesul de transformare a informaiei consum anumite resurse. Diferena principal de la metoda orientat pe obiecte const n separarea distinct a funciilor (metodele de prelucrare a datelor) de datele propriu-zise. Din punctul de vedere al modelrii afacerii fiecare abordare a re avantajele sale. Abordarea obiectual permite construirea unor sisteme mai stabile la modificri, corespunde mai bine structurilor existente n organizaie. Modelarea funcional se manifest mai bine atunci cnd structura organizaional este n proces de modificare sau, n genere, este salb conturat. Abordarea care pleac de la funciile ndeplinite este la nivel intuitiv mai bine neleas de executori ceea ce faciliteaz procesul obinerii informaiilor necesare pentru analiz i stabilirea cerinel or. 6.2.1. Metodologia IDEF0 Poate fi considerat etapa urmtoare de dezvoltare a binecunoscutului limbaj grafic pentru descrierea sistemelor funcionale SADT (Structured Analysis and Design Technique). IDEF n calitate de standard a aprut n anul 1981 n cadrul unui program extins consacrat automatizrii ntreprinderilor industriale, numit ICAM (Integrated Computer Aided Manufacturing). Familia stadardelor IDEF a motenit denumirea chiar de la numele acestui program Icam DEFinition. Ultima redacie a fost publicat n decembrie 1993 de Institutul Naional pentru Standarde al SUA (NIST). Obiectivul metodei este constrirea schemei funcionale a sistemului cercetat, care descrie toate procesele relevante cu exactiatea suficient pentru modelarea univoc a activiti i sistemului. La baza metodologiei se afl patru noiuni funcdamentale: blocul funcional, arcul de interfa, decompoziia i glosarul. Blobul funcional (Activity Box) reprezint o funcie concret (oarecare) a sistemului cercetat. Comform cerinelor standardului denumirea fiecrui bloc funcional trebuie s fie formulat n form de verb (de exemplu, presteaz servicii. n cadrul unei diagrame blocul funcional este reprezentat printr-un dreptunghi (fig. 6.1). Fiecare din cele patru laturi ale dreptunghiului are un rol bine definit, inclusiv: latura orizontal de sus are valoarea Management (Gestiune, en. Control); latura vertical din stnga are valoarea Intrare (Input); latura vertical din dreapta are valoarea Ieire (Output); latura orizontal de jos are valoarea Mecanism (Mechanism).

Fig. 6.1. Blocul funcional Arcul de interfa (Arrow) indic elementul sistemului, care este prelucrat de ctre blocul funcional sau influeneaz funcia, reprezentat de acest bloc. Arcele de interfa sunt numite frecvent fluxuri sau sgei. Cu ajutorul arcelor de interfa sunt reprezentate diferite obiecte, care ntr-un mod sau altul determin procesele, ce au loc n sistem. Astfel de obiecte pot fi elementele lumii reale (detalii, vagoane, colaboratori tec.) sau fluxuril de date i informaii (documente, date, instruciuni etc.).

n dependen de latura blocului funcional la care vine arcul el se va numi de intrare, de ieire sau de control. Conforma standardului, orice bloc funcional trebuie s posede minimum un arc de control i un arc de ieire un proces are loc conform anumitor reguli (arcul de control) i trebuie s genereze obligator un rezultat (o ieire). n caz contrar blocul nu are sens. Prezena obligatorie a arcelor de control este ua din diferene principale ale standardului IDEF0 de alte metodologii din clasa DFD (Data Flow Diagram) i WFD (Work Flow Diagram). Decompoziia (Decomposition) este noiunea central (de baz) a standardului IDEF0. Principiul decompoziiei este utilizat la divizarea unui proces complex n funcii componente. Nivelul de detaliere este determinat de creatorul modelului. Decompoziia permite prezentarea gradual i structurat a modelului sistemului sub form de structur ierarhic a unor diagrame separate, ceea ce face diagrama mai puin ncrcat i mai uor de neles i de manipulat. Pentru fiecare element al IDEF0 diagrame, blocuri funcionale, arce de interfa standardul presupune crearea i ntreinerea unui set de definiii, cuvin te-cheie, rezumate narative etc., care caraterizeaz obiectul determinat de acest element. Acest set se numete glosar i descrie entitatea elementului dat. Glosarul completeaz armonios limbajul grafic, asistnd diagramele cu detalii suplimentare. Un model IDEF0 ncepe cu prezentarea sistemului ca un tot ntreg un bloc funcional cu arcele de interfa, care se extind dincolo de domeniul studiat. Aceast diagram cu un singur bloc funcional se numete diagrama de context. n textul explicativ al diagramei de context trebuie s fie indicat obiectivul (Purpose) construirii diagramei sub form de descriere succint i fixat punctul de vedere (Viewpoint). Determinarea i formalizarea obiectivului construirii modelului IDEF este un moment extrem de important. De facto, obiectivul stabilete domeniile sistemului studiat, asupra crora trebuie focalizat atenia n primul rnd. Punctul de vedere determin direciile principale de dezvoltare a modelului i nivelul necesar de detalizare. Fixarea clar a punctului de vedere permite descrcarea modelului, refuznd la detalizare i cercetarea unor elemente separate, care nu sunt necesare reieind din punctul de vedere ales. Alegerea corect a punctului de vedere diminueaz cheltuielile temporale pentru construirea modelului final. n procesul de decompoziie blocul funcional, care n diagrama de context reprezint sistemul ca un tot ntreg, va fi supus ntr-o alt diagram, detalizrii. Diagrama obinut, de nivelul 2, include blocurile funcionale, ce reflect subfunciile principale ale bolcului funcional din diagrama de context, i se numete diagram-fiu (Child Diagram) n relaia cu diagrama de context. Fiecare dintre blocurile funcionale, care aparin diagramei -fiu, se numete bloc-fiu Child Box, respectiv blocul funcional predecesor se numete bloc printe (Parent Box), iar diagrama la care acesta aparine diagram printe (Parent Diagram). Fiecare subfuncie a diagramei fiu poate fi n continuarea detalizat prin decompozii a analogic a blocul su. n fiecare caz de decompoziie a blocului funcional toate arcele de interfa (care intr i care ies) sunt fixate pe diagrama fiu. Prin aceasta se atinge integritatea structural a modelului IDEF0. n unele cazuri arcele de la un nivel superior nu are sens s fie luate n consideraie n diagramele de nivel inferior sau invers arce de la un nivel inferior pot s nu fie reflectate n diagramele de nivel mai nalt. Aceasta doar ar suprancrca diagramele i le-ar face mai complicate pentru percepie. Pentru soluionarea unor probleme de acest gen n standardul IDEF0 a fot introdus noiunea tunelare. Notaia tunel (Arrow Tunnel) sunb form de dou parateze rotunde n jurul nceputului arcului de intrefa semnific, c acest arc nu a fost motenit de la blocul funcional printesc i a aprut (din tunel) doar n aceast diagram. Aceeai notaie n jurul sfritului unui arc (sgeata) n imediata vecintate de blocul de recepie semnific faptul, c n digarama -fiu a acestui bloc acest arc nu va fi luat n consideraie (nu va fi prezent) Cel mai frecvent are loc

situaia n care unele obiecte i arcele respective ale lor nu sunt luate n consideraie la unele nivele intermediare. Se spune n aceste cazuri, c obiectele mai nti intr n tunel, iar apoi, la necesitate se ntorc din tunel. De obicei modelele IDEF0 conin informaii complexe i concentrate. Pentru a limita suprancrcarea lor i a pstra comoditatea folosirii, standardul include posibilitatea limitri complexitii. Se recomand ca o diagram s includ de la 3 pn la 6 blocuri funcionale, iar numrul de arce de intrare la un bloc funcional, ca i de ieire dintr-un bloc funcional, s nu depeasc 4. Standardul IDEF0 conine un set de proceduri, care permit elaborarea i coordonarea m odelului de grupuri mari de oameni, din diferite doemnii de activitate a sistemului modelat. Procesul de elaborare este iterativ i include urmtoarele etape: Crearea modelului de un grup de specialiti din diferite domenii de activitate a companiei. Ascest grup, n terminologia IDEF0, se numete autori (Authors). Construirea modelului de nceput este un proces dinamic n cadrul cruia autorii chestioneaz persoanele competente referitor la structura diferitor procese, elabornd modele ale activitii subdiviziunilor. n cadrul acestui proces vor fi cutate rspunsuri la urmtoarele ntrebri: Ce avem la intarea subdiviziunii? o Care sunt funciile i n ce ordine ele sunt executate n cadrul subdiviziunii? o Cine este reaponsabil de executare unei funcii anume? o Care este rezultatul activitii subdiviziunii (ieirea)? n baza documentelor existente i n rezultatul chestionrii este creat proiectul modelului (Model Draft) Difuzarea draftului modelului pentru informare, coordonare i comentare. La aceast etap are loc

discutarea proiectului modelului de ct mai multe persoane competente (n termeni IDEF0 cititori). Fiecare diagram este criticat i comentat n scris, dup care este ntoars autorului. Autorul, de asemenea n scris, accept sau nu critica, motivnd neacceptarea, i ntoarce cernovicul corectat pentru discuii ulterioare. Acest ciclu continu pn la momentul n care autorii i cititorii vor ajunge la consens.
Aprobarea oficial a modelului este responsabilitatea conductorului grupului de lucru i are loc la momentul atingerii consensului ntre autori i cititori. Modelul final reprezint o imagine coordonat privind ntreprinderea (sistemul) din punctul de vedere i obiectivul stabilit.

Simplitatea limbajului grafic IDEF0 fac lizibil modelul i pentru persoane fr o pragtire anterioar special i care nu au participat n elaborarea modelului. Instrumentele IDEF0 sunt utlie i pentru demonstraii i prezentri. n baza modelului elaborat pot fi organizate proiecte noi, focalizate pe modificare controlat a modelului. 6.2.2. Metoda fluxurilor de date Obiectivul acestei metode este construirea modelului sistemului studiat sub form de diagram a fluxurilor de date (Data Flow Diagram DFD), care asigur descrierea corect a ieirilor (reacia sistemului n form de date) pentru intrri cunoscute (semnale la intrare prin interefeele externe). Diagramele fluxurilor de date sunt instrumentul principal de modelare a cerinelor funcionale ale sistemului proiectat. La crearea diagramei fluxurilor de date sunt utuilizate trei noiuni principale: fluxuri de date, procese (lucrri) de transformare a fluxurilor de intrare n ieiri, entiti externe i depozite de date (repozitorii). Fluxurile de date sunt abstracii, utilizate pentru modelarea transferului de informaii (sau a componentelor fizice) dintr-o parte a sistemului n alta. Pe o diagram fluxurile sunt reprezentate de sgei, care au nume, iar orientarea lor indic direia de deplasare a informaiei. Destinaia procesului (lucrrii) const n producerea fluxurilor de ieire din fluxurile de intrare n

conformitate cu aciunea, indicat de numele procesului. Numele unui proces trebuie s fie un verb n forma indefinit urmat de un complement (de exemplu, recepionare documente de livrare a produciei). Fiecare proces are un numr unic pentru a putea fi referit n interiorul diagramei. Numrul poate fi utilizat mpreun cu numrul diagramei pentru a obine indicile uncal al procesului n cadrul ntregului model. Depozitul de date (repozitoriul) permite determinarea datelor pentru sectoarele indicate, care vor fi pstrate n memorie ntre procese. De facto, depozitul prezint seciuni temporale ale fluxurilor. Informaia care se conine n depozit poate fi utilizat la orice moment de timp dup culegere, datele pot fi luate din depozit n ordine arbitrar. Numele unui depozit trabuie s corespund coninutului lui i s fie un substantiv. Entitatea extern este un obiect material din afara contextului sistemului, care este surs pentru sau receptor al datelor sistemului. Numele entitii externe trebuie s conin un substantiv, de exemplu, depozit de mrfuri. Obiectele, reprezentate prin entiti externe, nu vor participa n prelucrri de date. n afara elementelor principale n DFD intr dicionarele de date i minispecifaciile procesrii. Dicionarele de date sunt cataloagele tuturor elementelor de date, prezente n DFD, inclusiv fluxurile de date de grup sau individuale, depozitele i procesele, ca i toate atributele lor. Minispecificaiile procesrii descriu procesele DFD de nivel inferior. De facto, minipecificaiile reprezint algoritmii de descriere a lucrrilor, ndeplinite de procese: mulimea tuturor minispecificaiilor este specificaia total a sistemului. Procesul de construire a DFD ncepe cu crearea diagramei principale de tip stea n care este prezentat procesul modelat i toate entitile externe, cu care procesul interacioneaz. Dac procesul principal este complicat el va fi prezentat din start descompus ntr-o serie de procese, care interacioneaz. Criterii de complexitate pot fi: existena unui numr mare de entiti externe, multifuncionalitatea sau caracterul distribuit al sistemului. Entitile externe vor fi evideniate pentru procesul principal. Pentru determinarea lor vor fi evideniai furnizorii i consumatorii procesului principal, adic toate obiectele care interaioneaz cu procesul principal. La aceast etap descrierea interaciunii const n alegerea unui verb, care s reprezinte modul n care entitatea extern utilizeaz pe sau este utilizate de procesul principal. De exemplu, pentru procesul principal evidena petiiilor cetenilor, entitatea extern cetean, descrierea interaciunii depune petiie i primete rspuns. Aceast etap este una important principial fiindc anume aici sunt stabilite graniele sistemului modelat. Pentru fiecare entitate extern este construit tabelul evenimentelor, care descrie interaciunea entitii cu procesul principal. Tabelul evenimentelor include denumire entitii exter ne, evenimentul, tipul lui (ordinar/tipic pentru sistem sai excepional, adic reaqlizat n condiii speciale) i reaia sistemului. La pasul urmtor are loc decompoziia procesului principal ntr-un set de procese care reciproc legate, care fac schim de fluxuri de date. Fluxurile nu sunt concretizate, este determinat doar caracterul interaciunii lor. Decompoziia este finalizat n momentul n care procesul devine simplu, adic: 1. procesul are dou-trei fluxuri de intrare i de ieire; 2. procesul poate fi descris sub form de transformare a intrrilor n ieiri; 3. procesul poate fi descris sub forma unui algoritm secvenial. Pentru procesele simple este elaborat minispecificaia descrierea formal a algoritmului de transformare a intrrilor n ieiri. Minispecificaiile vor rspunde urmtoarelor cerine: pentru fiecare proces este elaborat o singur specificaie; specificaia determin n mod univoc fluxurile de intrare i de ieire pentru procesul dat; specificaia nu determin modul de transformare a fluxurilor de intrare n fluxuri de ieire; specificaia face referin doar la elementele existente fr a introduce elemente noi; specificaia va utiliza n msura posibilitilor operaii i abordri standard.

Dup ce procesul principal a fost descompus va fi construite pentru fiecare subproces tabele analogice ale evenimentelor interne. La urmtorul pas, dup determinarea tabelului complet al evenimentelor, vor fi evideniate fluxurile de date cu care procesele fac schimb, i entitile externe. Cea maisimpl modalitate este analiza tabelului evenimentelor. Evenimentele sunt transformate n fluxuri de date de la iniiatorul evenimentului la procesul solicitat, iar reaciile n flux invers de evenimente. Dup construirea fluxurilor de intrare i ieire n mod analogic sunt construite fluxurile interne. Pentru evidenierea lor vor fi selectai furnizorii i consumatorii informaiilor pentru fiecare proces intern. Dac un furnizor sau un consumator de informaii este un proces de pstrare sau de solicitare de informaii, atunci va fi introdus depozitul de date, pentru care acest proces servete drept interfa. Dup construirea fluxurilor de date diagrama va fi verificat la completitudine i lipsa contradiciilor. Completitudinea unei diagrame este asigurat dac n sistem nu exist procese neutilizate n procesul de transformare a intrrilor n ieiri. Lipsa contradiciilor este asigurat prin ndeplinirea unui set de reguli formale privind tipurile posibile de procese: pe diagram nu poate fi un proces, care s lege dou entiti externe o astfel de interciune trebuie lichidat; nici o entitate nu poate direct primi din sau transmite informaii n depozit depozitul de date este un element pasiv, gestionat cu ajutorul procesului de interfaare; dou depozite de date nu pot s fac schimb direct de informaii astfel de depozite trebuie comasate n unul singur. n calitate de avantaje ale metodei DFD amintim: posbilitatea determinrii univoce a entitilor externe, analiznd fluxurile de informaii din sistem i din afara lui; posbilitatea proiectrii de sus n jos, prin aceasta simplificnd construirea modelului to be; prezena specificaiilor proceselor de nivel inferior, cea ce permite s se treac de nonfinalizarea logic a modelului funcional i s se constriasc specificaiia funcional complet a sistemului elaborat. La dezavantaje: necesitatea introducerii artificiale a proceselor administrative (de conducere, control sau gestiune), deoarece aciunile de conducere (fluxuri) i procesele de conducer e din punctul de veder al DFD nu se deosebesc prin nimic de cele obinuite; lipsa nuiunii de timp, adic lipsa analizei intervalelor de timp la transforamrea datelor (toate constrngerile temporale trebuie introduse n specificaiile proceselor). 6.2.3. Metoda obiect-orientat Diferena principial ntre abordarea funcional i cea obiectual const n mod alitatea de descompunere sistemului. n abordarea obiect-orientat este utilizat decompoziia obiectual n care structura static este descris n termeni de obiecte i legturi ntre ele, iar comportamentul sistemului n termeni de schimb de mesaje ntre obiecte. Scopul metodei este construirea modelului business al organizaiei, care permite trecerea de la modelul scenariilor de utilizare la modelul, ce determin obiectele separate participante n realizarea funciilor business. Baza conceptual a abordrii obiect-orientate este format de modelul obiectual, care este construit conform urmtoarelor principii: abstractizare; incapsulare; modularitate; ierarhi; tipizare; paralelism; stabilitate. Noiunile de baz ale abordrii obiect-orientate sunt obiectul i clasa. Un obiect nglobeaz date i operaii i reprezint o abstraciune a unei entiti din lumea real. Obiectul are un comportament bine definit, desemnat de strile n care se poate afla i de individualitatea proprie.

Clasa este o descriere a unei mulimi de obiecte caracterizate prin structur i comportament similare. Programele sunt organizate ca ansamble de obiecte ce coopereaz ntre ele, fiecare obiect reprezentnd instana unei clase; fiecare clas aparine unei ierarhii de clase n cadrul creia clasele sunt legate prin relaii de motenire. La baza abordrii obiect-orientate stau urmtoarele concepte: abstractizarea; incapsularea; modularitatea; ierarhizarea; motenirea; agregarea. O abstraciune exprim toate caracteristicile eseniale ale unui obiect, care fac ca acesta s se disting de alte obiecte; abstraciunea ofer o definire precis a granielor conceptuale ale obiectului, din perspectiva unui privitor extern. n procesul de abstractizare atenia este ndreptat exclusiv spre aspectul exterior al obiectului, adic spre comportarea lui, ignornd implementarea acestei comportri. Cu alte cuvinte abstractizarea ne ajut s delimitm ferm "CE face obiectul" de "CUM face obiectul ceea ce face". Incapsularea este conceptul complementar abstractizrii. Dac rezultatul operaiei de abstractizare pentru un anumit obiect este identificarea protocolului su, atunci incapsularea are de a face cu selectarea unei implementri i tratarea acesteia ca pe un secret al respectivei abstraciuni. Prin urmare, incapsularea este procesul n care are loc ascunderea implementrii unui obiect fa de majoritatea clienilor si. Altfel spus, incapsularea este procesul de compartimentare a elementelor care formeaz structura i comportamentul unei abstraciuni; incapsularea servete la separarea interfeei "contractuale" de implementarea acesteia. Din definiia de mai sus rezult c un obiect este format din dou pri distincte: interfaa (protocolul) implementarea interfeei. Abstractizarea este procesul prin care este definit interfaa obiectului, n timp ce incapsularea definete reprezentarea (structura) obiectului mpreun cu implementarea interfeei. Clasele i obiectele obinute n urma abstractizrii i incapsulrii trebuie grupate i apoi stocate ntr-o form fizic, denumit modul. Modulele pot fi privite ca un fel de containere fizice n care declarm clasele rezultate n urma proiectrii la nivel logic. Asadar, modulele formeaz arhitectura fizic a programului. Modularizarea const n divizarea programului ntr-un numr de subuniti care pot fi compilate separat, dar care sunt cuplate (conectate) ntre ele. Gradul de cuplaj ntre module trebuie s fie mic, pentru ca modificrile aduse unui modul s afecteze ct mai puine alte module. Incapsularea i modularizarea reprezint procese similare dar care se desfoar la nivele diferite: incapsularea se aplic la nivelul "microcosmosului" (obiectele), iar modularizarea la nivelul "macrocosmosului" (programele). Reguli utile de modularizare 1. Structura fiecrui modul trebuie s fie suficient de simpl pentru a putea fi complet neleas. 2. Implementarea unui modul trebuie s depind doar de interfeele altor module. Cu alte cuvinte trebuie s fie posibil modificarea implementrii unui modul fr a avea cunotine despre implementarea altor module i fr a afecta comportarea celorlalte module. 3. Acele detalii ale sistemului, care se presupune c se vor modifica independent vor fi plasate n module diferite. 4. Singurele legturi ntre module vor fi acelea a cror modificare este improbabil.

5. Orice structur de date este incapsulat ntr-un modul; ea poate fi accesat direct din interiorul modulului dar nu poate fi accesat din afara modulului dect prin intermediul obiectelor i claselor coninute n acel modul. Ierarhizarea reprezint o ordonare a abstraciunilor. Cele mai importante ierarhii n paradigma obiectual sunt: ierarhia de clase (relaie de tip "is a") ierarhia de obiecte (relaie de tip "part of") Motenirea (ierarhia de clase) definete o relaie ntre clase n care o clas mprtete structura i comportarea definit n una sau mai multe clase (dup caz vorbim de motenire simpl sau multipl). Relaia de motenire face diferena ntre programarea orientat pe obiecte i cea bazat pe obiecte. Semantic, motenirea indic o relaie de tip "is a" ("este un/o"). Prin urmare, mostenirea implica o ierarhie de tip generalizare/specializare, in care clasa derivata specializeaza structura si comportamentul mai general al clasei din care a fost derivata. Agregarea (ierarhia de obiecte) este relaia ntre dou obiecte n care unul dintre obiecte aparine celuilalt obiect. Agregarea red apartena unui obiect la un alt obiect. Semantic, agregarea indic o relaie de tip "part of" ("parte din"). O calitate important a abordrii obiectuale const n consistena modelelor activitii organizaiei i modelelor sistemului informaional proiectat de la etapa formulrii cerinelor pn la etapa implementrii. Prin intermediul modelelor obiectuale poate fi urmrit reflectarea entitilor reale ale domeniului obiectiv modelat (a organizaiei) n obiecte i clase ale sistemului informaional. Majoritatea metodelor existente de abordare obiectual includ limbajul de modelare i descrierea procesului de modelare. Prin proces se nelege descrierea pailor, care trebuie parcuri pentru realizarea proiectului. n calitate de limbaj de modelare este utilizat limbajul unificat UML, care include un set standard de diagrame pentru modelare. n cadrul UML-ului descoperim 9 tipuri de diagrame: diagrama cazurilor de utilizare, diagrama de secven, diagrama de colaborare, diagrama de clase (cea mai utilizat), diagrama de stri, diagrama de componente, diagrama de construcie, diagrama de obiecte, diagrama de activiti. Abordarea obiect-orientat are urmtoarele avantaje: Decompoziia obiectual permite crearea modelelor de dimensiuni mai micprin utilizarea unor mecanisme comune, care asigur economia necesar a mojloacelor de exprimare. Abordarea orientat obiect sporete semnificativ nivelul de unificare a procesului de elaborare i reutilizare a componentelor. Decompoziia obiectual permite s se evite crearea unor modele complicate, deoarece presupune dezvoltarea evoluional a modelului n baza unor subsisteme relativ mici. Modelul obiectual este unul firesc deoarece este bazat pe percepia uman a lumii. La dezavantaje trebuie de subliniat cheltuielile nalte de start. Este o abordare care nu ofer rezultate imediate. Eficacitatea apare dup realizarea a dou-trei proiecte i acumularea de componente reutilizabile. 6.2.4. Compararea metodelor Funciile (operaiile, actiunile, lucrrile), legate pe diagrame prin fluxuri de obiecte, sunt componentele structurale principale ale modelelor funcionale (diagramele DFD sau SADT). Un avantaj indiscutabil al modelelor funcionale este realizarea abordrii structurale pentru proiectarea SI conform principiului top-down, cnd fiecare bloc funcional poate fi descompus ntr-o mulime de subfuncii .a.m.d., realiznd proiectarea modular a SI. Pentru modelele funcionale sunt caracteristice rigurozitatea procedural a decompoziiei SI i prezentarea clar. Abordarea funcional presupune crearea separat a modelelor obiect sub form de diagrame ER obiect-proprietate-relaie. Pentru verificarea corectitudinii modelrii domeniului obiectiv ntre modelul funcional i cel obiectual sunt stabilite relaii biunivoce. Principalul dezavantaj al modelelor funcionale const n faptul, c procesele i datele exist

independent unele de altele n afara decompoziiei funcionale exist, ntr-un plan secundar, structura datelor.Mai mult, nu sunt clare condiiile de ndeplinire a proc eselor de prelucrare a informaiilor, care pot s se schimbe dinamic. Aceste dezavantaje sunt excluse n modelele obiect-orientate n care clasa de obiecte cu setul de funcii asociat este componenta structural principal. Pentru clasele de obiecte este caracteristic ierarhia generalizatoare, care permite motenirea nu doar a atributelor (proprietilor) obiectelor clasei de nivel mai nalt, dar i a funciilor (metodelor). n cazul motenirii funciilor se poate face abstracie de o realizare concret a procedurilor (tipuri abstracte de date), care difer pentru anumite subclase de situaii. Aceasta permite apelarea unor astfel de module program folosind nume comune (polimorfism) i este posibil utilizarea repetat a codului la modificarea resurselor program. n consecin, adaptabilitatea sistemelor obiect orientate este mult mai nalt dect n cazul abordrii funcionale. Chiar i principiul proectrii este modificat n abordarea obiect-orientat. Mai nti sunt stabilite clasele obiectelor, iar n continuare n dependen de strile posbile ale obiectelor (ciclului de via a obiectelor) sunt determinate metodele de procesare (procedurile funcionale), ceea ce asigur o mai bun realizare a comportamentului dinamic al sistemului informaional. Pentru abordarea obiect-orientat au fost elaborate metode i create instrumente de modelare ggrafic a domeniului obiectiv, generalizate n cadrul limbajului UML. Dar modelele UML cedeaz modelelor funcionale din punctul de vedere al claritii. Metoda modelrii domeniului obiectiv este aleas reieind din gradul de dinamism al domeniului. Pentru situaiile cu un nivel mai nalt de reglementare sunt recomandate modelele funcionale, iar pentru procese business cu un grad de adaptivitate mai nalt (gestiunea fl uxurilor de lucru, realizarea solicitrilor dinamice la depozite de date) modele obiect-orientate. n unele cazuri, n cadrul aceluiai sistem pentru diferite clase de problem pot fi necesare diferite tipuri de modele, care s descrie acelai domeniu obi ectiv. n acest caz vor fi utilizate modele mixte ale domeniului.

6.3.

Metoda sintetic

Cum a fost subliniat mai sus, fiecare din metode permite soluionarea problemei construirii descrierii formale a procedurilor de lucru ale sistemului cercetat. Toate metodele permit elaborarea modelului as is i to be. n acelai timp, fiecare metod are nejunsuri substaniale. ns neajunsurile utilizrii unei metode nu se afl n sfera descrierii proceselor reale, ci n incompletitudinea abordrii metodice. Metodele funcionale aduc o claritate mai mare referitor la funciile existente n organizaie, metodele de realizare a acestora, iar calitatea descrierii sistemului crete odat cu creterea nivelului de detalizare a obiectului studiat. Prin creterea calitii descrierii se are n vedere obinerea unor modele, care permit o prognozare mai bun a comportamentului sistemului real.La nivelul unor proceduri de lucru separate descrierea lor practic coiincide cu implementarea fizic. La nivelul general de descriere metodel e funcionale permit interpretri neunivoce referitor la alegerea interfeelor i mecanismelor sistemului, adic la stabilirea granielor sistemului. La acest nivel abordarea obiect-orientat vine cu soluii mai bune, bazate pe noiunea scenariul de utiliz are. Momentul cheie este reprezentat de noiunea de scenariu de utilizare sub form de ses iune de interaciune a utilizatorului cu sistemul, n rezultatul creia utilizatorul obine ceva ce prezint valoare. Utilizarea criteriului valorii permite utilizatorului s exclud detaliile secundare ale fluxului de lucru i s se concentreze asupra funciilor, care justific existena sistemului. Totui, i n acest caz problema determinrii granielor sistemului, evidenierea utilizatorilor externi este complicat . Tehnologia fluxurilor de date, care este istoric prima tehnologie, rezolv uor problema granielor, deoarece prin analiza fluxurilor informaionale permite s fie evideniate entitile externe i determinat procesul intern principal. ns, lipsa proceselor explicite de conducere, fluxurilor i orientrii pe evenimente impune cutarea unor tehnologii suplimentare complementare. Cea mai bun modalitate de eliminare a neajunsurilor menionate mai sus este formarea unei

metode sintetice, care s reuneasc avantajele metodelor studiate mai sus. Ideea metodei sintetice const n utilizarea succesiv a abordrilor funcionale i obiectuale innd n vizor posibilitaile de reinginerie a situaiei existente. Vom studia utilizarea metodei sintetice pe exmplul el aborrii unui regulament administrativ. n acest caz sunt evideniate urmtoarele etape: 1. Stabilirea granielor sistemului. La acest etap n rezultatul analizei fluxurilor de date sunt identificate entitile externe i sistemul modelat. 2. Determinarea scenariilor de utilizare a sistemului. Folosind criteriul de utilitate la aceast etap pentru fiecare entitate extern este construit setul de scenarii de utilizare a sistemului. 3. Adugarea scenariilor de utilizare de sistem. Aici sunt determinate scenariile n ecesare pentru realizarea obiectivelor sistemului, diferite de obiectivele utilizatorilor. 4. Construirea diagramei de activiti din scenariile de utilizare. Este construit setul de aciuni ale sistemului, care conduc la realizarea scenariilor de utilizare. 5. Decompoziia funcional a diagramelor de activiti sub forma diagramelor de context n metoda IDEF0. 6. Descrierea formal a activitilor funcionale separate sub forma regulamentului administrativ (utiliznd diferite notaii).

7. Modelarea proceselor business n BPwin


Instrumente CASE pentru modelarea proceselor business. Mediul instrumental BPwin. Principiile de construire a modelului IDEF0: diagrama de context, subiectul modelrii, obiectivul i punctul de vedere. Diagramele IDEF0: diagrama de con text, diagramele de decompoziie, diagramele arborelui nodurilor, diagramele de expunere (FEO) Activiti (Activity). Sgei (Arrow). Tunelarea sgeilor. Numerotarea activitilor i diagramelor. Carcasa diagramei. Agregarea i dezagregarea modelelor. Crearea rapoartelor.

Modelarea proceselor business, de regul, este realizat cu ajutorul mijloacelor CASE. Din aceast categorie fac parte BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) .a. Vom analiza n continuare posibilitile funcionale ale mijloacelor instrumentale de modelare structural a proceselor business pe exemplul mediului instrumental BPwin. BPwin susine trei metodologii de modelare: modelarea funcional (IDEF0), descrierea proceselor business (IDEF3) i digramele fluxurilor de date (DFD).

7.1.

Mediul instrumental BPwin

BPwin are o interfa a utilizatorului relativ simpl i intuitiv neleas. La lansarea BPwin este afiat panoul principal al instrumentelor, palitra instrumentelor (forma creia depinde de notaia selectat) i, n partea stng, navigatorul modelului Model Explorer (fig. 7.1).

Fig. 7.1. Mediul integrat de construire a modelului BPwin La construirea unui model nou va fi lansat un dialog n cadrul cruia trebuie de indicat dac va fi creat un model absolut nou sau modelul va fi deschis dintr-un fiier sau depozitul ModelMart. Va fi introdus numele modelului i aleas metodologia n care va fi construit modelul (fig. 7.2). Cum a fost menionat mai sus, BPwin susine trei metodologii IDEF0, IDEF3 i DFD, fiecare soluionnd probleme specifice. n BPwin pot fi construite modele mixte, adic pot fi prezente instantaneu diagrame IDEF0, IDEF3 i DFD. Componena palitrei instrumentelor se va schimba n mod automat la trecerea de la o notaie la alta.

Fig. 7.2. Dialogul de creare a modelului Un model BPwin este privit ca un set de activiti, fiecare din care opereaz cu un anumit set de date. Activitile sunt prezentate sub form de dreptughiuri, datele sub form de sgei. Dac se acioneaz butonul din stnga a mouse-ului pe un obiect al modelului va apare meniul de context, fiecare punct al cruia corespunde editorului unei proprieti a obiectului.

7.2.

Construirea modelului IDEF0

La etapele de debut ale crerii SI este necesar s nelegem cum funcioneaz organizaia, pentru care va fi implementat sistemul. Conductorul organizaiei cunoate lucrul la nivel general, dar nu este n stare s intre n detalii pentru fiecare colaborator. Un colaborator tie t ot ce este legat de locul su de lucru, dar poate s nu cunoasc ce fac colegii. Din aceast cauz pentru descrierea modului de activitate a organizaiei trebuie construit modelul adecvat domeniului obiectiv i care va include toate cunotinele participanilor n procesle business ale organizaiei. IDEF0 este un limbaj comod de modelare a proceselor business n care sistemul este reprezentat ca set de activiti sau funcii interdependente. Aceast orientare exclusiv funcional este principial funciile sistemului sunt analizate independent de obiectele cu care opereaz. Aceasta permite o modelare mai corect a logicii i interaciunii proceselor. Modelarea n IDEF0 ncepe prin crearea diagramei de context diagrama celui mai abstract nivel de descriere a sistemului n totalitate, care include definiia subiectului modelrii, obiectivele i punctul de vedere aspura modelului (viewpoint). Prin sibiect se nelege nsi sistemul i este necesar s se stabileasc exact din ce este format sistemul i ce se afl n afara lui. Cu alte cuvinte, s se determine care elemente vor fi considerate mai departe ca i componente ale sistemului, i care vor fi considerate drept aciuni externe. O influien seminifcativ asupra determinrii subiectului sistemului va avea poziia din care este abordat sistemul i obiectivele modelrii ntrebri la care trebuie s dea rspuns modelul construit. Altfes spus, n debut trebuie de stabilit domeniul modelrii. Descrierea domeniului - a sistemului n totalitate i a component elor sistemului reprezint baza construirii modelului. Chiar dac se permite ca n timpul modelrii domeniul poate fi corectat, el trebuie identificat din start, deoarece anume domeniul stabilete direcia modelrii. La determinarea domeniului se va ine cont de lrgimea i adncimea lui. Lrgimea presupune determinarea granielor modelului care vor fi componentele incluse n sistem i care vor rmne n afara lui. Adncimea stabilete nivelul de detaliere la care nivel de detaliere a componentelor se va considera modelul finalizat. La determinarea adncimii trebuie s se in cont de limitele de timp eforturile necesare cresc n progresie geometric cu creterea adncimii. Odat cu determinarea granielor sistemului se va considera c nu vor mai fi introduse obiecte noi n sistemul modelat.

7.2.1. Obiectivul modelrii Obiectivul modelrii este identificat din rspunsurile la urmtoarele ntrebri: Din care cauz acest proces trebuie modelat? Ce trebuie s afieze modelul? Ce poate obine clientul? Prin punct de vedere nelegem perspectiva din care a fost studiat sistemul la construirea modelului. Dei la construirea modelului se iau n consideraie prerile diferitor persoane, toi trebuie s aib un punct comun referitor la model. Punctul de vedere trebuie s corespund obiectivelor i granielor modelrii. De obicei, este ales punctul de vedere al persoanei responsabile de activitile de modelare n totalitate. Modelul IDEF0 presupune existena unui obiectiv formulat clar, a unui subiect unic al modelrii i a unui punct de vedere unic. Pentru introducerea domeniului, obiectivului i a punctului de vedere n modelul IDEF0 n BPwin se va selecta punctul din meniu Model/Model Properties, care apeleaz dialogul Model Properties (fig. 7.3). n pagina Purpose trebuie de introdus obiectivul i punctul de vedere, iar n pagina Definition definiia modelului i descrierea domeniului.

Fig. 7.3. Dialogul de desemnare a proprietilor modelului n pagina Status al aceluiai dialog poate fi descris statutul modelul ui (varianta maculator, de lucru, final, etc.), data crerii i a ultimii editri (urmrire automat dup data de sistem). n pagina Source sunt descrise sursele informaionale pentru construirea modelului (de exemplu, Chestionarea experilor domeniului obiectiv i analiza documentaiei). Pagina General servete pentru introducerea numelui proiectului i a modelului, numelui autorului i cadrului temporal al modelului AS-IS i TO-BE. De obicei la nceput este construit modelul cum are loc organizarea activitilor AS-IS (cum este). Analiza modelului funcional permite s se stabileasc locurile slabe, s se determine n ce va consta avantajele noilor procese business i ct de adnci vor fi modificrile propuse. Detalizarea proceselor business permite identificarea neajunsurilor organizaiei chiar acolo unde la prima vedere funcionalitatea pare evident. Neajunsurile identificate cu ajutorul modelului AS -IS pot fi corectate prin crearea modelului TO-BE (cum va fi) modelul de organizare nou a proceselor

business. Tehnologia proiectrii SI presupune mai nti crearea modelului AS -IS, analiza lui i perfecionarea proceselor business, adic crearea modelului TO -BE, i numai n baza modelului TO-BE va fi construit modelul datelor, prototipul i apoi varianta final a SI. Adesea modelul curent AS-IS i modelul viitor TO-BE se deosebesc foarte mult, n rezultat trecerea de la starea iniial la cea final nu este evident. n aceste cazuri este necesar un model intermediar, care va descrie prpocesul trecerii de la starea iniial la cea final, iar aceast trecere este la fel un proces business. Rezultatele descrierii modelului pot fi obinute n raportul Model Report. Dialogul de configurare a raportului conform modelului este apelat din punctul de meniu Tools/Reports/Model Report. n dialogul de configurare vor fi selectate cmpurile necesare, n acest timp n mod automat va fi afiat ordinea de extragere a informaiilor n raport (fig. 7.4).

Fig. 7.4. Fereastra de dialog pentru formarea raportului n figura 7.5 este prezentat un raport, creat conform cmpurilor bifate n figura 7.4.

Fig. 7.5. Afiarea prealabil a raportului Baza metodologiei IDEF0 este limbajul grafic de descriere a proceselor business. n noaia IDEF0 modelul const dintr-un set de diagrame interdependente ordonate ierarhic. Fiecare diagram este o unitate de descriere a sistemului i este plasat pe o pagin separat. 7.2.2. Tipuri de diagrame Modelul poate include patru tipuri de diagrame: diagrama de context (n fiecare model poate exista doar o singur diagram de context); diagramele de decompoziie; diagramele arborelui nodurilor; diagramele pentru expoziie (FEO). Diagrama de context este rdcina structurii arborescente a diagramelor i prezint descrierea general a sistemului i interaciunea lui cu mediul extern. Dup descrierea la nivel general are loc mprirea sistemului n fragmente mari. Acest proces se numete decompoziie funcional, iar diagramele, care descriu fiecare fragment i interaciunea fragmentelor, se numesc diagr ame ale decompoziiei. Dup decompoziia diagramei de context are loc decompoziia fiecrui fragment mare n fragmente mai mici i tot aa mai departe, pn la atingerea nivelului necesar de concretizare a descrierii. Dup fiecare ciclu de decompoziie au loc sesiuni de expertizare experii domeniului obiectiv identific corespondena proceselor business reale cu diagramele create. Abaterile depistate sunt corectate i doar la momentul lipsei observaiilor se va trece la urmtorul ciclu de decompoziie. Astfel este realizat corespondena dintre model i procesele business reale la fiecare nivel al modelului. Sintaxa descrierii sistemului n totalitate i a fiecrui fragment este aceeai pentru ntreg modelul. Diagrama arborelui nodurilor inic dependena ierarhic a activitilor, ns nu interdependena lor. Astfel de diagrame ntr-un model pot fi orict de multe, deoarece arborele poate fi construit la orice adncime i nu obligator nsepnd cu rdcina. Diagramele pentru expoziie (FEO) sunt construite pentru a ilustra fragmente separate ale modelului, puncte de vedere alternative sau n scopuri speciale. Activitile (Activity) semnific procese, funcii sau lucrri nominalizate, care au loc ntr -un

anumit interval de timp i produc rezultate descifrabi le. Activitile sunt notate prin dreptunghiuri. Toate activitile trebuie s fie denumite i definite. Numele unei activiti este o combinaie de cuvinte, care semnific aciune (de exemplu, Funcionare companie, Recepie comenzi .a.m.d.). Activitatea cu denumirea Funcionare companie poate avea, de exemplu, urmtoarea definiie: Acest model este un model de studiu, care descrie cum funcioneaz compania. La crearea modelului nou (opiunea meniului File/New) n mod automat este creat diagrama de context cu o singur activitate, care reprzint sistemul n totalitate (fig. 7.6).

Fig. 7.6. Exemplu de diagram de context Pentru introducerea numelui activitii se va aciona butonul din dreapta a mouse-ului, se va alege opiunea de meniu Name Editor i n fereastra de dialog se va introduce numele actvitii. Pentru descrierea altor proprieti ale activitii servete dialogul Activity Properties (fig. 7.7).

Fig. 7.7. Editorul proprietilor unei activiti Diagramele de decompoziie conin activiti care se afl n relaie de paternitate cu activitatea descompus, adic sunt activiti-fiice (au o activitate printe comun). Pentru crearea diagramei de decompoziie se va aciona butonul din panoul de instrumente.Va fi afiat fereastra de

dialog Activity Box Count (fig. 7.8) n care trebuie de indicat notaia diagramei noi i numrul de activiti din aceast diagram.

Fig. 7.8. Fereastra de dialogActivity Box Count Alegem aici notaia IDEF0 i acionm OK. Apare diagrama de decompoziie (fig . 7.9). Intervalul permis de activiti este de la 2 la 8. Nu are sens s descompunem o activitate ntr-o singur activitate. Diagramele mai mult de 8 activiti sunt suprasaturate i dificil de citit. Pentru claritate i o nelegere mai bun a proceselor modelate se recomand s utilizm de la 3 la 6 blocuri ntr-o diagram.

Fig. 7.9. Exemplu de diagram de decompoziie Dac numrul activitilor este insuficient, este posibil adugarea unei activiti ntr -o diagram, prin clik pe butonul palitrei instrumentelor, apoi ntr-un loc liber pe diagram. Activitile ntr-o diagram de decompoziie sunt plasate pe diagonale stnga -sus dreapta-jos.

Aceast ordine se numete ordine de dominare. Conform acestui principiu de plasare, n colul stnga-sus este plasat cea mai important activitate sau activitatea executat prima n timp. Relaia este recursiv pentru celelate activiti. Aceast plasare faciliteaz citirea diagramelor, plus c pe o astfel de plasare este bazat noiunea de interdependen a activitilor (v. mai jos). Fiecare activitate din diagrama de decompoziie poate fi la rndul su descompus. Pe diagrama de decompoziie activitile sunt numerotate n mod automat de la stnga la dreapta. Numrul activitii este afiat n colul dreapta-jos. n colul stnga-sus este afiat o mic linie diagonal, care indic c aceast activitate nu a fost descompus. Astfel, n figura 7.9 nu a fost descompus nc nici o activitate. Sgeile (Arrow) descriu interaciunile activitilor i reprezint anumite informaii, exprimate prin substantive (de exemplu, Reguli i proceduri, Sistem contabil", Adresri telefonice). 7.2.3. Tipuri de sgei n IDEF0 exist 5 tipuri de sgei: Intrare (Input) material sau informaie, care sunt utilizate sau transformate de activitate n scopul obinerii unui rezultat (ieire). Activitateai poate s nu aib nici o sgeat de intrare. Fiecare tip de sgeat este asociat unei laturi deteminate a dreptunghiului activitate (intr sau iese). Sgeata intrare este desenat intrnd n latura din stnga a activitii. La descrierea proceselor tehnologice (pentru ele a fost gndit IDEF0) nu apar probleme legate de determinare intrrilor. ntr-adevr, Adresri telefonice este ceva prelucrat de procesul " ". pentru obinerea rezultatului. ns n cazul n care sgeile nu sunt obiecte fizice, ci date, nu este totul att de evident. De exemplu, pentru activitatea Primirea pacientului cartela pacientului poate fi att la iintrare, ct i la ieire, iar calitatea acestor date nu se modific. Cu alte cuvinte, n exemplul nostru, pentru ca sgeile s ndrepteasc destinaia, trebuie s fie exact definite, adic s indice (pentru ieiri) c datele ntra-adevr au fost prelucrate (Cartela completat a pacientului). Frecvent este dificil de stabilit dac datele sunt intrri sau controluri. n acest caz poate fi util informaia dac datele sunt sau nu prelucrate/modificate de activitate. Dac da, atunci este mai probabil c avem intrri, n caz contrar- control. Control reguli, strategii, proceduri sau standarde, cu respectarea crora are loc activitatea. Fiecare activitate trebuie s posede minimum a sget control. Sgeata control este desenat intrnd n latuare orizontal de sus a dreptunghiului activitii. n figura 7.6 sgeata " " este control pentru " ". Controlul influieneaz activitatea dar nu este transformat de ea. Dac scopul sctivitii este de a modifica o procedur sau o strategie, atunci o astfel de procedur sau strategie va fi pentru activitate intrare. n cazul apariiei unor incertitudini legate de statutul sgeii (control sau intrare) se recomand s fie desenat sgeata control. Ieire (Output) material sau informaie, produse de activitate. Orice activitate trebuie s posede cel puin o sgeat ieire. O activitate fr rezultat nu are sens i nu trebuie modelat. Sgeata ieire este desenat ieind din latura vertical dreapta a activitii. n figura 7.6 sgeile " " i " " sunt ieiri pentru activitatea " ". Mecanism (Mechanism) resursele, care ndeplinesc activitatea, de exemplu personalul ntreprinderii, mainile unelte, dispozitivele etc. Sgeata mecanism este desenat intrnd n latura orizontal de jos a activitii. n figura 7.6 sgeata " " este mecanism pentru activitatea " ". Analistul de sistem poate s nu includ sgeile mecanism n model. Apel (Call) sgeat special, care face referire la al t model al activitii. Sgeata apel este desenat ieind din latura orizontal de jos a activitii. n figura 7.10 sgeata " " este apel pentru activitatea " ". Sgeata apel este utilizat pentru a indica, c activitate oarecare este ndeplinit n afara sistemului modelat. N BPwin sgeile apel sunt utilizate n mecanismul de agragare sau dezagregare a modelelor.

Fig. 7.10. Sgeata apel, care apare la dezagregarea modelului Sgei de grani. ntr-o diagram de context sgeile sunt utilizate pentru descrierea interaciunii sistemului cu mediul nconjurtor. Ele pot ncepe la grania diagramei i pot s se termine la activitate sau invers. Aceste sgei se numesc de grani. Pentru introducerea unei sgei de grani intrare se va proceda dup cum urmeaz: se va aciona butonul cu simbolul , n palitra de instrumente cursorul va fi deplasat spre partea stng a ecranului pn va aprea nceputul unei liniue de haurare; se va face clik simplu pe aceast liniu (de unde iese sgeata) i nc unul n partea stnga a activitii din partea intrrii (unde se va termina sgeata); ne ntoarcem n palitra instrumentelor i alegem opiunea editare sgeat cu butonul din dreapta a mouse-ului facem clik pe linia sgeii, n meniul pop-up alegem Name i adugm numele sgeii n pagina Name a dialogului IDEF0 Arrow Properties. Sgeile control, intrare, mecanism i ieire sunt introduse n mod analogic. Numele sgeilor noi (fig. 7.11) sunt introduse n mod automat n Arrow Dictionary.

Fig. 7.11. Fereastra de dialog IDEF0 Arrow Properties 7.2.4. Codurile ICOM Diagrama de decompoziie este destinat detalizrii activitii. Spre deosebire de modelele, care reflect structura organizaiei, activitatea ntr-o diagram de nivel siperior n IDEF0 nu este un element de control cu activitile de la nivele mai joase. Activitile de la nivele mai joase reprezint aceleai momente ca i activitile de nivel nalt, dar cu un grad mai mare de detaliere. n rezultat, graniele unei activiti de nivel superior reprezint acelai lucru ca i graniele diagramei de decompoziie. ICOM (abrevierea de la Input, Control, Output i Mechanism) sunt codurile destinate identificrii sgeilor de grani. Un cod ICOM conine prefixul, care corespunde tipului sgeii (I, C, O sau M) i numrul de ordine. BPwin introduce codurile n mod automat. Pentru afiarea codurilor ICOM trebuie actualizat opiunea ICOM codes a paginii Display a ferestrei de dialog Model Properties (meniul Model/Model Properties, fig. 7.12). Dicionarul sgeilor este editat folosind editorul special Arrow Dictionary Editor, n care are loc identificarea sgeii i este introdus comentariul asociat ei (fig. 7.13). Dicionarul sgeilor rezolv o problem foarte important. Analistul creeaz diagrame pentru a desfura sesiunea de expertizare, adic s discute diagrama cu un specialist din domeniul obiectiv. n orice domeniu obiectiv sunt create argouri (jargon) profesionale, frecvent expresiile jargon au un sens vag i sunt contientizate n mod diferit de experi diferii. n acelai timp analistul autorul diagramelor este obligat s utilizeze cele mai pe nelesul experilor expresii. Deoarece definiiile formale adesea sunt complicate pentru acceptate, analistul este nevoit s utilizeze n diagrame argoul profesional, iar pentru excluderea unor posibile tratri neunivoce, n dicionarul sgeilor fiecare noiune poate fi definit extins, la necesitate formal.

Fig. 7.12. Activarea opiunii ICOM codes pe pagina Display

Fig. 7.13. Editarea dicionarului sgeilor Coninutul dicionarului sgeilor poate fi imprimat sub form de raport (meniul Tools/ Report /Arrow Report...), vom obine n acest caz dicionarul explicativ al termenilor domeniului obiectiv, utilizai n model. 7.2.5. Sgeile libere i legate

Sgeile de grani nelegate (libere) (unconnected border arrow). La decompoziia activitii sgeile, care intr i care ies (cu excepia sgeii apel) apr in mod automat pe diagrama de decompoziie (migrarea sgeilor), dar nu ating activitile. Aceste sgei se numesc nelegate i sunt tratate de BPwin ca eroare sintactic.

n figura 7.14 este prezentat un fragment a diagramei de decompoziie cu sgei nelegate, generate de BPwin la decompoziia activitii " " (fig. 7.9). Pentru legarea sgeilor de intrare, control sau mecanism trebuie de trecut n regimul de editare a sgeilor, se face clik pe partea terminal a sgeii apoi pe segmentul respectiv al activitii. Pentru legarea sgeii de ieire trebuie de trecut n regimul de editare a sgeilor, se face clik pe segmentul de ieire al activitii apoi pe sgeat

Fig. 7.14. Exemplu de sgei nelegate Sgei interne. Pentru legarea reciproc a activitilor sunt utilizate sgei interne, adic sgei , care nu ating graniele diaggramei, pornind de la activitate i terminndu -se la alta. Pentru desenarea unei sgei interne n regim de editare a sgeilor se va face clik pe segmentul (de exemplu, ieirea) unei activiti apoi pe segmentul (de exemplu, intrarea) altei activiti. n IDEF0 exist cinci tipuri de legturi pentru lucrri. Legare de intrare (output-input), cnd sgeata de ieire a unei activiti superioare (n continuare simplu, ieire) este direcionat spre intrarea unei activiti inferioare (de exemplu, n fig. 7.15 sgeata " " leag activitile " " i " ").

Fig. 7.15. Legarea de intrare Legare de control (output-control), cnd ieirea unei activiti superioare este direcionat ctre controlul unei activiti inferioare. Legarea de control indic dominarea activitii superioare. Datele sau obiectele de la ieirea activitii superioare nu pot fi modificate n cadrul unei astfel de

activiti inferioare. n figura 7.16 sgeata " " leag activitile " " i " ".

Fig. 7.16. Legarea de control Conexiune invers la intrare (output-input feedback), cnd ieirea unei activiti inferioare este aplicat la intrarea unei activiti superioare. Aceast legtur, de obicei, este utilizat pentru descrierea ciclurilor. n figura 7.17 sgeata " " leag activitile " " i " ".

Fig. 7.17. Conexiune invers la intrare Conexiune invers la control (output-control feedback), cnd ieirea unei activiti inferioare este aplicat la controlul unei activiti superioare (sgeata " ", fig. 7.18). Conexiunea invers la control adesea subliniaz efecacitatea procesului business. n figura 7.18 volumul vnzrilor poate fi sporit prin raglarea direct a proceselor de asamblare i

testare a calculatoarelor (ieirea activitii " ").

Fig. 7.18. Conexiunea invers la control Legtura ieire-mecaninsm (output-mechanism), cnd ieirea unei activiti este aplicat la mecanismul altei activiti. Aceast legtur este utilizat mai rar i semnific faptul, c o activitate pregtete resurse, necesare pentru derularea altei activiti (fig. 7.19).

Fig. 7.19. Legtura ieire-mecanism Sgei evidente. O sget evident are drept surs o singur (i numai una) activitate i destinaie de asemenea o singur (i numai una) activitate. Sgei de ramificare i de adunare. Unele i aceleai date sau obiecte, generate de o singur activitate, pot fi utilizate instantaneu n alte cteva activiti. Pe de alt parte, sgeile generate de activiti diferite, pot reprezenta aceleai (sau omogene) date sau obiecte, care mai apoi sunt utilizate sau prelucrate n acelai loc. Pentru modelarea acestor situaii sunt utilizate sgei de ramificare i sgei de adunare. Pentru a ramifica o sgeat n regim de editare a sgeii se face clik pe fragmentul sgeii i pe segmentul respectiv al activitii. Pentru adunarea a dou sgei de ieire n regim de editare a sgeii se face mai nti clik pe segmentul ieirii activitii, apoi pe fragmentul respectiv al sgeii. Sensul sgeilor de ramificare i de adunare se transmite prin atribuirea unui nume pentru fiecare ramur de sgeat. Exist anumite reguli de atribuire a numelor. Ca exemplu vom lua sgeile de ramificare. Dac sgeata a fost numit pn la ramificare, iar dup ramificare ni ci una din ramuri nu a fost denumit, se consider c fiecare ramur modeleaz aceleai date sau obiecte, ca i pn

la ramificare (fig. 7.20).

Fig. 7.20. Exemplu de atribuire a numelui pentru sgei ramificate Dac sgeat avea denumire pn la ramificare, iar dup ramificare una din ramuri este de asemenea denumit, se consider c aceste ramuri corespund denumirii. Dac n acest caz una din ramuri a rmas fr nume, se consider c ea modeleaz aceleai date sau obiecte, ca i ramura pn la ramificare (fig. 7.21).

Fig. 7.21. Exemplu de denumire a sgeii ramificate Nu este admis situaia n care sgeata nu este denumit pn la ramificare, iar dup ramificare una din ramuri este fr nume. BPwin determin astfel de sgei ca eroare sintactic. Regulile de atribuire a numelor sgeilor de adunare sunt analogice eroare va fi considerat sgeata care dup adunare nu are nume, iar pn la adunare nu avea nume una din ramuri. Pentru denumirea unei ramuri separat e a sgeilor de ramificare i de adunare pe diagram va fi selectat doar o ramur, dup care va fi apelat editorul numelui i va fi atribuit un nume sgeii.

Acest nume va corespunde doar sgeii selectate. 7.2.6. Tunelarea sgeilor Sgeile de grani noi, introduse ntr-o diagram de decompoziie de nivel inferior sunt reprezentate n paranteze ptrate i nu vor apare n mod automat n diagramele de nivel mai nalt (fig. 7.22).

Fig. 7.22. Sgeat nerezolvat (unresolved) Pentru ridicarea lor se va face clik dreapta pe parantezele ptrate ale sgeii de grani i n meniul de context se va selecta opiunea Arrow Tunnel (fig. 7.23).

Fig. 7.23. Alegerea opiunii din meniul de context

Fig. 7.24. Fereastra de dialog Border Arrow Editor Va fi afiat fereastra de dialog Border Arrow Editor (fig. 7.24). Dac acionm butonul Resolve Border Arrow, sgeata va migra pe diagrama de nivel superior, iar dac butonul Change To Tunnel sgeat va fi tunelat i nu va ajunge pe alt diagram. O sgeat tunelat este reprezentat cu paranteze rotunde la capt (fig. 7.25)

Fig. 7.25. Tipuri de tunelare a sgeilor Tunelarea este utilizat pentru afiarea sgeilor puin importante. Dac ntr -o diagram de nivel inferior trebuie reprezentate date sau obiecte puin importante, care nu sunt prelucrate sau nu sunt utilizate de activiti la nivelul curent, ele trebuie expediate la nivelul superior (la diagrama printe). Dac aceste date nu sunt utilizate nici n diagrama printe, atunci vor fi expediate mai sus .a.m.d. n rezultat, o sgeat puin important va fi prezent la toate nivelele i va complica citirea tutror diagramelor. Ieirea const n tunelarea acestei sgei la cel mai inferior nivel . Aceast tunelare se numete nu-n-diagrama-printe. Un alt exemplu de tunelare poate fi situaia n care o sgeat de tip mecanism migreaz de la nivelul superior la nivelul inferior, i la nivelul inferior acest mecanism este utilizat n acelai mod pentru toate activitile fr excepie. (Se presupune, c bu trebuie de detalizat sgeata mecanismului, adic sgeata mecanismului pe activitatea-fiic a fost denumit pn la ramificare, iar dup ramificare remurile nu au nume proprii). n acest caz sgeata mecanismului la nivelul inferior poate fi eliminat, dup ce n daigrama printe ea poate fi tunelat, iar n come ntariul sgeii sau n dicionar putem indica, c mecanismul va fi utilizat n toate activitile diagramei -fiice de decompoziie. Aceast tunelare se numete nu-n-activitatea-fiic (fig. 7.25). 7.2.7. Numerotarea activitilor i diagramelor

Toate activitile sunt numerotate. Numrul const din prefix i un numr. Pot fi utilizate prefixe de lungime arbitrar, dar de obicei este utilizat prefixul A. Diagrama de context (rdcin) are numrul A0. ctivitile decompoziiei diagramei A0 au numrul A1, A2, A3 .a.m.d. Activitile decompoziiei unui nivel inferior au numrul activitii printe i numrul de ordine ordinar, de exemplu decompoziiile lui A3 vor ave numerele A31, A32, A33 .a.m.d. Activitile formeaz o ierarhie n care fiecare activitate poate avea o activitate printe i cteva activiti fiice, formnd un arbore. Acest arbore se numete arborele nodurilor, iar numerotarea de mai sus numerotare pe noduri. Diagramele IDEF0 au o numerotare dubl. Mai nti, diagramele au numr conform nodului. Diagrama de context are ntotdeauna numrul A-0, decompoziia diagramei de context numrul A0, restul diagramelor decompoziiei numere conform nodului (de exemplu, A1, A2, A21, A213 etc.). BPwin susine modul automat de numerotare pe noduri. n rezultatu l expertizelor diagramele por fi precizate i modificate, adic pot exista deiferite versiuni ale unei diagrame de decompoziie (din punctul de vedere al plasrii n arborele nodurilor ). BPwin permite existena n model a unei singure diagrame de decompozi ie n nodul dat. Versiunile precedente pot fi pstrate sub form de copii pe hrtie sau ca diagrame FEO. (Din pcate, la crearea diagramellor FEO lipsete posibilitatea roll-back, adic dintr-o diagram poate fi obinut decompoziia FEO, dar invers nu). n orice caz, trebuie s putem diferenia diferite versiuni ale aceleeai diagrame. Pentru aceasta exist un numr special C-number, care trebuie atribuit modelului n mod manual. C-number este o linie de simboluri oarecare, dar se recomand respectare a standardului n care numrul const dintr-un prefix (simboluri, iniialele autorului diagramei) i numrul de ordine (va fi urmrit n mod manual, de exemplu, BV00048). 7.2.8. Diagramele arborelui nodurilor i FEO Diagramele arborelui nodurilor reprezint ierarhia atcivitilor modelului i ofer o vedere asupra intregului model, dar nu conine legturile reciproce ntre activiti (fig. 7.26) Procesul crerii modelului activitilor este iterativ, ca rezultat activitile pot fi deplasate n cadul arborelui nodurilor. Pentru claritate i pentru a verifica corectitudinea decompoziiei este necesar ca dup fiecare modificare s fie creat diaggrama arborelui nodurilor. BPwin are un mecanism puternic de navigare prin model Model Explorer, care permite afiarea ierarhiei activitilor i a digramelor ntr-o form comod i compact.

Fig. 7.26. Diagrama arborelui nodurilor

Pentru crearea diagramei arborelui nodurilor n meniu va fi selectat opiunea Diagram/Add Node Tree (fig. 7.27). Va fi afiat fereastra de di alog pentru formarea diagramei arborelui nodurilor Node Tree Definition (fig. 7.28, 7.29).

Fig. 7.27. Alegerea opiunii pentru crearea diagramei arborelui nodurilor

Fig. 7.28. Fereastra de ajustare a diagramei arborelui nodurilor (pasul 1)

Fig. 7.29. Fereastra de ajustare a diagramei arborelui nodurilor (pasul 2)

n dialogul Node Tree Definition trebuie de indicat adncimea Number of Levels (valoarea implicit este 3) i rdcina arborelui (valoarea implicit este activitatea printe a diagramei curente). n mod implicit nivelul de jos al decompoziiei este afiat n form de list, restul activitilor n form de dreptunghiuri. Pentru afiarea ntregului arbore n form de dreptunghiuri trebuie de eliminat bifa opiunii Bullet Last Level. Atunci cnd este creat arborele nodurilor trebuie de indicat numele diagramei deoarece, dac n mai multe diagrame va fi utilizat una i aceeai activitate n calitate de rdcin tuturor aceste diagrame se va conferi unul i acelai numr (numrul nodului + sufixul N, de exemplu A0N) i n lista diagramelor deschise (opiunea meniului Window) deosebirea ntre ele va putea fi fcut doar dup nume. Diagramele numai pentru expunere (FEO) sunt utilizate adesea n model pentru a ilustra alte puncte de vedere, pentru reflectarea unor detalii separate, care nu sunt susinute de sintaxa IDEF0. Diagramele FEO permit s fie nclcat orice regul sintactic, deoarece n esen sunt doar simple tablouri copii ale diagramelor standard i nu particip la analiza sintaxei . Pentru crearea unei diagrame FEO va fi aleas opiunea meniului Diagram/Add FEO Diagram. Va fi afiat fereastra de dialog Add New FEO Diagram n care trebuie de indicat numele diagramei FEO i tipul diagramei printe (fig. 7.30).

Fig. 7.30. Fereastra de dialog pentru crearea unei diagrame FEO noi Numrul unei diagrame noi este generat n mod automat (numrul diagramei printe conform nodului + sufixul F, de exempplu A1F). 7.2.9. Chenarul diagramei n figura 7.31 este prezentat un exemplu tipic de diagram de decompoziie cu chenarul de grani, numit chenarul diagramei. Chenarul are un titlu (partea de sus a chenarului) i un subsol (partea de jos). Titlul chenarului este utilizat pentru urmrirea (referirea) diagramei n procesul de modelare. Partea de jos es te utilizat pentru identificare i poziionare n ierarhia diagramei. Sensul elementelor chenarului este prezentat n tabelele 7.1 i 7.2.
Tabelul 7.1. Cmpurile titlului chenarului (de la stnga la dreapta) Cmp Used At Autor, Date, Rev, Project Notes 123456789 10 Sens Este utilizat pentru a indica activitatea printe, dac n diagrama curent se fcea referin prin utilizarea sgeii apel Numele autorului diagramei, data crerii i numele proiectului, b cadrul cruia a fost creat diagrama. REV data ultimei revizuiri a diagramei Este utilizat pentru sesiunile de expertizare. Expertul va indica (pe copia pe hrtie a diagramei) numrul de observaii, tind cifra din list de fiecare dat cnd introduce o observaie nou

Status Working Draft Recommended Publication Reader Date Context

Statutul reflect etapa crerii diagramei, conform etapelor de publicare Diagram nou, diagram noit cardinal sau autor nou al diagramei Diagrama a trecut expertizarea primar i este gata pentru discuii ulterioare Diagrama i toate documentele asociate au trecut expertiza. Modificri noi nu sunt ateptate Diagrama este gata pentru imprimarea final i publicare Numele cititorului (expertului) Data citirii (expertizei) Schema plasrii activitilor n diagrama de nivel superior. Activitatea printe este prezentat printr-un dreptunghi nnegrit, restul de culoare deschis. Pe diagrama de context (A-0) va fi prezent inscripia TOP. n colul stnga jos este indicat numrul (conform nodului) al diagramei printe:

Tabelul 7.2. Cmpurile subsolului chenarului (de la dreapta la stnga) Cmp Node Title Page Sens Numrul nodului diagramei (numrul activitii printe) Numele diagramei. Implicit numele activitii printe Numrul paginii, poate fi utilizat ca numr de pagin la formarea mapei

Number C-Number, numr unic al versiunii diagramei

Fig. 7.31. Exemplu diagram de decompoziie cu chenar Valorile cmpurilor sunt atribuite n fereastra de dialog Diagram Properties (meniul Diagram /Diagram Properties) figura 7.32.

Fig. 7.32. Fereastra de dialog Diagram Properties

7.3.

Reunirea i desprirea modelelor

Posibilitatea reunirii i despririi modelelor permite lucrul colectiv n proiect. Managerul proiectului poate construi decompoziia nivelului superior i solicita analitii s continue descompunerea fiecrei ramuri al arborelui n form de modele separate. Dup finalizarea activitilor ramurilor separate toate submodelele pot fi reunite ntr-un model unitar. Pe de alt parte, o ramur separat a modelului poate fi extras pentru a fi utilizat n calitate de model independent, p entru perfecionare sau arhivare. Pentru reunirea i desprirea modelelor n BPwin sunt utilizate sgeile apel. Pentru reunire este necesar s fie ndeplinite urmtoarele condiii: Ambele modele reunite trebuie s fie deschise n BPwin. Numele modelului-surs, reunit cu modelul-scop, trebuie s coiincid cu numele sgeii de apelare a activitii n modelul-scop. Sgeata apel trebuie s plece dintr-o activitate nedescompus (activitatea trebuie s posede o liniu diagonal n colul stnga sus, fig. 7.33). Numele activitii de context a modelului -surs reunit i a activitii din modelul-scop, la care reunim modelul-surs, trebuie s coiincid. Modelul-surs trebuie s aib minimum o diagram de decompoziie.

Fig. 7.33. Sgeata de apelare a activitii " " a modelului-scop Pentru reunirea modelelor se va face clik dreapta cu mouse-ul pe activitatea cu sgeata apel n modelul-scop i n meniul pop-up se va selecta opiunea Merge Model. Este afiat o fereastr de dialog n care se va indica opiunea de reunire a modelului (fig. 7.34). La reunirea modelelor se vor reuni i dicionarele sgeilor i activitilor. n cazul n care definiiile coiincid este posibil rescrierea lor sau acceptarea definiiilor din modelul -surs. Acelai lucru este valabil i pentru numele sgeilor, depozitele de date i referinele externe. Depozitele de date i referinele externe obiecte ale diagramelor fluxurilor de date, DFD, vor fi studiate mai jos.

Fig. 7.34. Fereastra de dialog Continue with merge

Dup confirmarea reunirii (butonul OK) modelul-surs este adugat modelului -scop, sgeata apel dispare, iar activitatea de la care pleca sgeata apel, devine decompozabil la aceasta se va reuni diagrama de decompoziie a primului nivel al modelului -surs. Sgeile, asociate activitii din diagrama modelului-scop nu migreaz n mod automat n decompoziie, ci vor fi reflectate ca nerezolvabile. Ele trebuie tunelate manual. n procesul de reunire modelul-surs rmne neschimbat, iar n modelul-scop este inclus copia modelului-surs. Nu trebuie confundat reunirea modelelor cu sincronizarea lor. Dac modelul surs va fi modificat ulterior, schimbrile introduse nu vor nimeri automat n ramura respectiv a modelului-scop. Desprirea modelelor are loc n mod analogic. Pentru desprirea unei ramuri de la model se va face clik dreapta cu mouse-ul pe activitatea descompus (activitatea nu are liniu diagonal de haurare n colul stnga sus) i n meniul pop-up se va selecta opiunea Split Model. n fereastra de dialog afiat Split Options se va indica numele modelului creat. Dup confirmarea despririi modelului n modelul vechi activitatea respectiv va deveni nedescompus (liniua diagonal n colul stnga sus), va fi creat sgeata apel, numele ei va coiincide cu numele modelului nou, i, n final va fi creat modelul nou n care numele activitii de context va coiincide cu numele activitii de la care a fost rupt decompoziia.

7.4.

Crearea rapoartelor n BPwin

BPwin posed un instrument puternic de generare a rapoartelor. Rapoartele pentru un model concret sunt apelate din opiunea Report a meniului. Exist 7 tipuri de rapoarte: 1. Model Report. Include informaii despre contextul modelului numele modelului, punctul de veder, domeniul, scopul, numele autorului,data crerii .a. 2. Diagram Report. Raport pentru o diagram concret. Include lista obiectelor (activiti, sgei, depozite de date, referine externe .a.). 3. Diagram Object Report. Cel mai complet raport al modelului. Poate include lista complet a obiectelor modelului (activiti, sgei cu indicarea tipului lor etc.) i proprietile definite de utilizator. 4. Activity Cost Report. Raport cu rezultatele analizei costurilor. Va fi studiat mai jos. 5. Arrow Report. Raport despre sgei. Poate include informaii din dicionarul sgeilor, activitatea-surs, activitatea-destinaie a sgeii n informaii privind reunirea i desprirea sgeilor. 6. Data Usage Report. Raport despre rezultatele legrii modelului proceselor i modelului datelor (mai jos). 7. Model Consistency Report. Raport, care include lista erorilor sintactice ale modelului