Proiectarea sistemelor informaționale CONȚINUT 1. INTRODUCERE ...................................................................................................................................................... 1.1. NOȚIUNI DE BAZĂ DIN PROIECTAREA SISTEMELOR INFORMAȚIONALE ........................... 1.1.1. OBIECTUL ȘI METODELE CURSULUI ....................................................................................................................... 1.1.2. SISTEME INFORMAȚIONALE ȘI SISTEME INFORMATICE........................................................................................ 1.1.3. CLASIFICĂRI ........................................................................................................................................................... 1.1.4. SCURT ISTORIC ...................................................................................................................................................... 1.2. ETAPELE PROCESULUI DE CREARE A SI............................................................................................... 1.2.1. FORMAREA CERINȚELOR......................................................................................................................................... 1.2.2. PROIECTAREA ......................................................................................................................................................... 1.2.3. REALIZAREA ȘI TESTAREA.................................................................................................................................... 1 1.3. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE ............................................... 1 1.3.1. CONŢINUTUL METODOLOGIILOR DE REALIZARE A SISTEMELOR INFORMATICE ................................................ 1 1.3.2. METODE ŞI TEHNICI DE REALIZARE A SI............................................................................................................ 1 1.3.3. CARACTERISTICI ESENŢIALE ALE PRINCIPALELOR METODE ............................................................................... 1 1.3.4. INSTRUMENTE CASE ........................................................................................................................................... 1 2. CICLUL DE VIAȚĂ A PRODUSELOR PROGRAM ..................................................................................... 1 2.1. MODELE ALE CICLULUI DE VIAȚĂ ......................................................................................................... 1 2.1.1. MODELUL CASCADĂ .............................................................................................................................................. 1 2.1.2. MODELUL SPIRALĂ................................................................................................................................................ 1 2.1.3. ALTE MODELE........................................................................................................................................................ 1 2.2. PROCESELE CICLULUI DE VIAȚĂ ........................................................................................................... 1 2.2.1. PROCESELE CONFORM ISO/IEC 12207 ........................................................................................................... 1 2.2.2. CONȚINUTUL PROCESELOR PRIMARE................................................................................................................... 1 2.2.3. PROCESELE CONFORM ISO/IEC 15288 ........................................................................................................... 2 2.2.4. ALTE STANDARDE ȘI REGLEMENTĂRI .................................................................................................................. 2 3. ORGANIZAREA PROCESELOR DE DEZVOLTARE A SISTEMELOR INFORMAȚIONALE......... 2 3.1. PROIECTAREA CANONICĂ A SI .............................................................................................................. 2 3.1.1. ETAPELE PROIECTĂRII CANONICE........................................................................................................................ 2 3.1.2. ANALIZA SITUAȚIEI ȘI IDENTIFICAREA CERINȚELOR SISTEMULUI NOU ............................................................ 2 3.1.3. ELABORAREA CONCEPȚIEI SI ȘI SARCINII TEHNICE ........................................................................................ 2 3.1.4. PROIECTUL TEHNIC............................................................................................................................................... 2 3.1.5. DOCUMENTAȚIA .................................................................................................................................................... 3 3.2. PROIECTAREA TIP ........................................................................................................................................ 3 3.2.1. SOLUȚIA PROIECT TIP .......................................................................................................................................... 3 3.2.2. ETAPELE REALIZĂRII............................................................................................................................................. 3 3.2.3. MODELE DE COMPONENTE ................................................................................................................................... 3 4. ANALIZA ȘI MODELAREA SPAȚIULUI FUNCȚIONAL AL IMPLEMENTĂRII SI ....................... 3 4.1. MODELUL BUSINESS COMPLET AL COMPANIEI ............................................................................. 3 4.2. ȘABLOANELE MODELĂRII BUSINESS ORGANIZAȚIONALE....................................................... 3 4.2.1. ȘABLONUL PENTRU ELABORAREA MISIUNII ........................................................................................................ 3
1.3. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE ............................................... 11
1.3.1. CONŢINUTUL METODOLOGIILOR DE REALIZARE A SISTEMELOR INFORMATICE ................................................ 11 1.3.2. METODE ŞI TEHNICI DE REALIZARE A SI............................................................................................................ 11 1.3.3. CARACTERISTICI ESENŢIALE ALE PRINCIPALELOR METODE ............................................................................... 12 1.3.4. INSTRUMENTE CASE ........................................................................................................................................... 12
2. CICLUL DE VIAȚĂ A PRODUSELOR PROGRAM ..................................................................................... 13
2.1. MODELE ALE CICLULUI DE VIAȚĂ ......................................................................................................... 14
2.2. PROCESELE CICLULUI DE VIAȚĂ ........................................................................................................... 18
2.2.1. PROCESELE CONFORM ISO/IEC 12207 ........................................................................................................... 18 2.2.2. CONȚINUTUL PROCESELOR PRIMARE ................................................................................................................... 19 2.2.3. PROCESELE CONFORM ISO/IEC 15288 ........................................................................................................... 20 2.2.4. ALTE STANDARDE ȘI REGLEMENTĂRI .................................................................................................................. 21
3. ORGANIZAREA PROCESELOR DE DEZVOLTARE A SISTEMELOR INFORMAȚIONALE ......... 23
3.1. PROIECTAREA CANONICĂ A SI .............................................................................................................. 23
3.1.1. ETAPELE PROIECTĂRII CANONICE ........................................................................................................................ 23 3.1.2. ANALIZA SITUAȚIEI ȘI IDENTIFICAREA CERINȚELOR SISTEMULUI NOU ............................................................ 24 3.1.3. ELABORAREA CONCEPȚIEI SI ȘI SARCINII TEHNICE ........................................................................................ 27 3.1.4. PROIECTUL TEHNIC ............................................................................................................................................... 29 3.1.5. DOCUMENTAȚIA .................................................................................................................................................... 31
3.2. PROIECTAREA TIP ........................................................................................................................................ 31
3.2.1. SOLUȚIA PROIECT TIP .......................................................................................................................................... 32 3.2.2. ETAPELE REALIZĂRII............................................................................................................................................. 33 3.2.3. MODELE DE COMPONENTE ................................................................................................................................... 34
4. ANALIZA ȘI MODELAREA SPAȚIULUI FUNCȚIONAL AL IMPLEMENTĂRII SI ....................... 35
4.1. MODELUL BUSINESS COMPLET AL COMPANIEI ............................................................................. 35
4.2. ȘABLOANELE MODELĂRII BUSINESS ORGANIZAȚIONALE ....................................................... 38
4.2.1. ȘABLONUL PENTRU ELABORAREA MISIUNII ........................................................................................................ 38
4.2.2. ȘABLOANE PENTRU FORMAREA AFACERILOR ...................................................................................................... 40 4.2.3. ȘABLONUL DE DESCRIERE FLUX-PROCES............................................................................................................ 43
4.3. CONSTRUIREA MODELULUI ORGANIZAȚIONAL-FUNCȚIONAL AL COMPANIEI .............. 43
4.4. MIJLOACE INSTRUMENTALE PENTRU MODELAREA ORGANIZAȚIONALĂ .......................... 49
5.1. MODELE DE FLUX PROCESUALE ............................................................................................................. 50
5.2. ELEMENTELE DE BAZĂ ALE ABORDĂRII PROCESUALE................................................................ 52
5.3. SELECTAREA ȘI CLASIFICAREA PROCESELOR ................................................................................ 53
5.3.1. TIPURI DE PROCESE BUSINESS ............................................................................................................................ 53 5.3.2. PROCESELE DE BAZĂ ............................................................................................................................................ 54 5.3.3. PROCESELE DE MANAGEMENT .............................................................................................................................. 55 5.3.4. PROCESELE DE ASIGURARE .................................................................................................................................. 57 5.3.5. MODELUL BUSINESS DE REFERINȚĂ .................................................................................................................... 58
6.2. METODOLOGII ORIENTATE PE FUNCȚII ȘI ORIENTATE PE OBIECTE ................................. 65
6.2.1. METODOLOGIA IDEF0......................................................................................................................................... 66 6.2.2. METODA FLUXURILOR DE DATE ........................................................................................................................... 68 6.2.3. METODA OBIECT-ORIENTATĂ .............................................................................................................................. 70 6.2.4. COMPARAREA METODELOR ................................................................................................................................... 72
6.3. METODA SINTETICĂ ..................................................................................................................................... 73
7. MODELAREA PROCESELOR BUSINESS ÎN BPWIN ............................................................................. 75
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 analiştii
de sisteme, programatorii şi alte categorii de persoane implicate, realizează procesele de analiză a
sistemului informaţional-decizional existent, de proiectare şi de introducere a sistemului nou.
Metoda are un caracter general, în cadrul ei aplicându-se anumite tehnici de lucru [2].
Tehnicile de lucru utilizate în proiectarea SI reprezintă felul în care se acţionează eficient şi rapid,
în cadrul unei metode, pentru soluţionarea problemelor ce apar în procesul de proiectare. Prin
aceste tehnici se îmbină armonios cunoştinţele despre metode cu măiestria personală a celor
chemaţi 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 unei metodologii de lucru, care se adoptă în funcţie
de situaţia reală la care se referă.
În abordările incipiente se lucra cu probleme izolate. Ulterior s-a efectuat trecerea la abordarea
sistemică, odată cu abordarea funcţională sau, mai bine zis, cu analiza şi decompoziția funcţională
(în fiecare modul există câte o funcţie) până 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 unităţi componente prin rafinări
repetate, metoda de proiectare putând 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 unităţi economico-sociale numită organigrama unităţii poate fi reprezentată printr-o astfel de
diagramă ierarhică.
În strategia bottom – up evolutivă, se porneşte de la o tratare minimală care se extinde treptat pe
măsura înaintării î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 mulţi autori astfel [1]:
metode orientate spre funcţii, numite şi metode ale descompunerii funcţionale;
metode orientate spre fluxuri de date sau orientate spre procese, deoarece diagramele
fluxurilor de date se întrebuinţează pentru descrierea proceselor;
metode orientate spre informaţie sau date, orientate-informaţii, apărute ca urmare a
popularizării puternice a ingineriei informaţiei a lui JAMES MARTIN, dar şi a diagramelor
entitate-relaţie ale lui CHEN [3];
metode orientate-obiect.
1.3.3. Caracteristici esenţiale ale principalelor metode
Informaţia este văzută de DeMarco în 1982, ca fiind posibil de abordat prin trei perspective
specifice sistemelor informaţionale sau prin trei dimensiuni: date, funcţii, 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].
Funcţiile scot în evidenţă în mod limitat ceea ce face sistemul. El poate fi văzut şi ca un proces,
întrucât elementele sistemului despre care se păstrează datele de rigoare sunt supuse unor
transformării funcţionale, prin intermediul proceselor [1].
Comportamentul este invocat pentru a reda o altă modalitate de percepţie a sistemului, influenţa
evenimentelor şi proprietăţilor sistemului, şi sugerează dinamica lui [1].
Dintre autorii remarcabili care au abordat descompunerea funcţională îi enumerăm pe câţiva
cum ar fi DeMarco, Yourdon şi Constantine, Jackson, Page-Jones, Marco&Gowan, Warnier-Orr,
Dahl. Descompunerea funcţională este cea care anunţă apariţia proiectării şi analizei structurale.
Fiecare funcţie este descompusă în subfuncţii, până se obţin structuri uşor de transpus în
instrucţiunile limbajelor de programare.
Prin metoda fluxurilor de date (orientată-proces) analiştii efectuează reprezentarea lumii reale prin
simboluri care reprezintă fluxul datelor, transformările datelor, stocarea datelor, entităţi externe,
etc. Metoda orientată-proces are un mare grad de asemănare cu descompunerea funcţională.
În cadrul metodei orientate spre informaţii (orientate-date) două realizări importante în domeniu
au dat tonul unei orientări în abordarea sistemelor: modelarea datelor cu ajutorul diagramelor
entitate-relaţie, de către Peter P. Chen (1976) şi ingineria informaţiei, î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 aceeaşi 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, când resursele tehnice s-au extins prin seria PC-urilor, iar reţelele 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 cerinţelor până
la întreţinerea 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 atenţia cuvenită analizei, proiectării şi programării orientate pe obiecte [1].
Majoritatea produselor soft au fost construite în mod artizanal, fără posibilitatea testării complete a
lor, fiind însoţite de o documentaţie slabă. Instrumentele CASE implică utilizarea calculatorului ca
mijloc de susţinere a activităţilor de planificare, definire, proiectare şi realizare a softului. Ele se
bazează pe logica structurală, pe descompunerea funcţională şi reprezentarea prin diagrame a
fluxurilor de date ale aplicaţiilor.
Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a încuraja abordarea logicii
structurale şi pentru folosirea calculatorului ca un mod de tezaurizare a lucrărilor şi ca o planşetă
de desen, pe care pot fi plasate reprezentările structurate ale sistemelor sau aplicaţiilor. Pe măsura
evoluţiei lor, sistemele CASE au devenit mult mai complexe, permiţând ca procesele de proiectare
şi realizare a aplicaţiilor să se desfăşoare într-un mediu informatic interactiv, oferind utilizatorilor
un întreg arsenal de instrumente şi proceduri, prin care pot proiecta, realiza, testa, documenta,
întreţine, actualiza şi exploata sistemul.
Utilizarea produselor de tip CASE a fost determinată de [1]:
calitatea îndoielnică a aplicaţiilor realizate în mod tradiţional;
frustrarea utilizatorilor în încercarea lor de a participa la procesul de proiectare şi realizare a
aplicaţiilor, datorită nivelului ridicat de cunoştinţe informatice solicitate de metodele
tradiţionale;
costuri deosebit de mari pe care le presupun întreţinerea şi actualizarea softului funcţional;
imposibilitatea rezolvării tuturor cerinţelor utilizatorilor;
limitarea posibilităţii de reprezentare grafică a schemelor de realizare a noilor proiecte.
Folosirea sistemelor CASE este motivată şi de următoarele avantaje:
reducerea complexităţii logicii de descriere a sistemului;
posibilitatea de a alege dintre mai multe variante de proiectare;
creşterea vitezei de realizare a sistemelor;
realizarea succesivă a componentelor unui sistem;
creşterea nivelului de integrare;
consolidarea disciplinei de proiectare;
oferirea unei interfeţe de proiectare;
folosirea depozitelor modularizate;
salvarea şi refolosirea unor componente din diagramele realizate;
simplificarea activităţilor de proiectare şi realizare a sistemelor/aplicaţiilor.
Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de date, care fac
posibilă realizarea unui model al derulării proceselor sistemului/aplicaţiei care se proiectează. A
urmat folosirea dicţionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicaţia.
Au apărut ecranele predefinite pentru a prezenta ce poate să obţină utilizatorul prin exploatarea
sistemului. S-a apelat la facilităţile grafice, care pot folosi simbolurile logicii structurale şi care
permit proiectantului să realizeze o diagramă coerentă a fluxurilor de date [1].
Întrebări de control
1. Care este tipul datelor prelucrate în SI factorafice?
2. Ciclul de viață a produselor program
Noțiune de ciclu de viață. Procesele ciclului de viață: principale, auxiliare, organizaționale.
Conținutul și legăturile reciproce între procesele ciclului de viață. Modele ale ciclului de viață:
cascadă, cu control intermediar, spirală. Stadiile ciclului de viață. Standarde.
Metodologia proiectării sistemelor informaționale descrie procesul creării și mentenanței sistemelor
prin intermediul ciclului de viață a SI, prezentându-l ca o succesiune de etape și procese, care sunt
executate în cadrul etapelor. Pentru fiecare etapă este determinată componența și succesiunea
lucrărilor executate, rezultatele la ieșire, metodele și mijloacele necesare pentru îndeplinirea
lucrărilor, rolurile și responsabilitățile participanților ș.a.m.d. Această descriere formală a “vieții” 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 creării și
exploatării sistemului.
2.1. Modele ale ciclului de viață
Modelul ciclului de viață reflectă diferite stări ale sistemului, pornind de la momentul apariției
necesității de elaborare a sistemului dat până la retragerea lui din exploatare. Modelul ciclului de
viață poate fi privit ca structura, care include procesele, acțiunile și sarcinile realizate în timpul
elaborării, funcționării și întreținerii produsului program pe întreaga perioadă de existență a
sistemului, de la stabilirea cerințelor până la retragerea din utilizare.
Modelele ciclului de viață pot fi împărțite în modele cascadă și modele iterative cu variante
succesive.
2.1.1. Modelul cascadă
Modelul cascadă (fig. 2.1) stabilește executarea consecitivă a fazelor proiectului într-o ordine strictă.
Include următoarele faze: Stabilirea cerințelor, Proiectarea, Realizarea/Implementarea și testarea
modulelor, Integrarea și testarea de sistem, Exploatarea și mentenanța. Trecerea la faza următoare
semnifică finalizarea completă a tuturor lucrărilor de la etapa precedentă.
Fig. 2.1. Modelul Cascadă
În faza de Stabilire a cerințelor sunt identificate toate cerințele posibile ale sistemului ce se
dorește implementat. Cerințele 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 cerințe (Sarcina Tehnică), ce va servi ca ghid pentru fazele următoare ale proiectului.
În etapa de Proiectare sunt studiate cerințele de la prima etapă și este elaborat design-ul
sistemului. Această fază ajută în specificarea cerințelor de sistem și hardware, precum și în definirea
arhitecturii de ansamblu. Rezultatul acestei etape se concretizează în redactarea unui document ce
cuprinde specificațiile de proiectare (Proiectul Tehnic).
Etapa Realizarea și testarea modulelor presupune divizarea sistemului în module și
implementarea codului. Sistemul este dezvoltat mai întâi în mici programe, numite “unități”,
“module” sau “componente”, care vor fi apoi integrate în faza următoare. Fiecare unitate este
dezvoltată și testată (testare unități, autonomă), pentru a ne asigura că respectă specificațiile.
Componentele pot fi funcţii, obiecte sau grupuri coerente de astfel de entităţi.
În faza de Integrare și testare de sistem, toate unitățile 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 specificațiile. 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
îndeplineşte cerinţele acestuia.
Ultima fază – Exploatarea și mentenanța - 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 activități de mentenanță.
Printre avantajele modelului cascadă, se pot menționa:
Documentația și proiectarea structurii sunt un avantaj dacă apar noi membri în echipă;
Este un model ușor de utilizat și simplu;
Fiecare fază are un rezultat așteptat, datorat rigidității modelului;
Etapele sunt îndeplinite individual, secvențial (ușor de urmărit);
Este recomandat pentru proiectele mici, în care cerințele sunt foarte bine înțelese.
Printre dezavantajele acestui tip de model, se numără:
Culegerea specificațiilor în etapa de Cerințe este foarte importantă pentru a proiecta și
implementa produsul corespunzător. Cu toate acestea, cerințele pot fi adăugate și după
finalul acestei etape, fapt ce influențează în mod negativ dezvoltarea;
Problemele din cadrul unei etape nu sunt niciodată rezolvate complet în cadrul aceleiași
etape;
Partiționarea în etape a proiectului nu este flexibilă;
Clientul poate adăuga noi cerințe, care nu pot fi implementate în aceeași ediție a produsului.
Va fi nevoie de costuri suplimentare pentru implementarea cerințelor nou adăugate;
Este dificil să se facă o estimare corectă a timpului și costului alocat pentru fiecare etapă;
Un produs funcțional finit este obtinut târziu, comparativ cu momentul de început al
proiectului.
O perfecționare a modelului cascadă este modelul cu control intermediar sau cu reacție, în care au
fost introduse iterații cu conexiuni inverse între etape (fig. 2.2). Corecțiile, introduse între etape,
permit să se țină cont de influențele reciproce ale rezultatelor la diferite etape; timpul de viață a
fiecărei 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 plecând de la slăbiciunile modelului cascadă, în special lipsa sa de
flexibilitate la schimbări ale cerințelor. Este focalizat pe analiza riscurilor în mod incremental,
repetând 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
iterație 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 următorului ciclu: evaluarea de către client, planificarea dezvoltării și a
livrării către client. Următorul prototip este dezvoltat conform următorilor pași:
Evaluarea prototipului precedent în termeni de puncte forte, puncte slabe și riscuri;
Definirea cerințelor pentru următorul prototip;
Planificarea și proiectarea următorului prototip;
Construirea și testarea următorului prototip.
Modelul spirală este o îmbunătățire a modelului cascadă deoarece prevede mai multe livrări și mai
multe posibilități de implicare a clientului. Raza spiralei reprezintă costul acumulat.
O versune modificată este modelul spirală WinWin, care adaugă la începutul fiecărui ciclu activități
de identificare a părților interesate în proiect (“stakeholders”) și condițiile lor de câștig (“win
conditions”).
La avantaje merită să fie subliniată atitudinea pro-activă asupra riscurilor cu o presupunere explicită
a riscurilor și a rezolvării lor. De asemenea un avantaj important este flexibilitatea modelului.
La dezavantaje trebuie de menționat că este aproape imposibil de estimat de la început timpul de
execuție a proiectului și costurile necesare.
2.1.3. Alte modele
La categoria alte modele pot fi menționate 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
activitățile de specificare și cele de testare, înlănțuirea în timp a activităților fiind aceeași.
Fig. 2.4. Modelul în V
Partea din stânga reprezintă lanțul de specificare a sistemului, iar cea din dreapta – lanțul de
testare. Partea de jos a V-ului reprezintă implementarea.
În acest model există două tipuri de dependențe între etape:
cele reprezentate prin liniile, care formează V-ul și corespund înlănțuirii și eventualei iteraţii din modelul cascadă; etapele se derulează deci secvenţial, urmând V-ul de la
stânga la dreapta;
cele reprezentate prin linii orizontale, care indică faptul că o parte din rezultatele etapei din care pleacă săgeata 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 obținută rapid prin tehnici de simulare și/sau de interpretare a specificaţiilor. În acest ultim caz, limbajele logico-funcționale sunt în mod sigur
chemate să joace un rol important.
Prototipul este o schiță a viitorului sistem: el nu are performanțele și nu răspunde exigențelor de
calitate ale unui produs finit. Prototipul oferă clientului functionalități (nu în totalitate) ale viitorului
sistem și interfața pentru utilizator. El este dezvoltat într-o manieră iterativă. Cerințele sunt extrase
și validate iterativ prin utilizarea prototipului. În fiecare iterație specificația sistemului este
modificată și detaliată până când prototipul satisface necesitățile 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 limitările modelului Waterfall, legate de stabilirea
cerințelor. În loc de a stabili definitiv cerințele înainte de a putea începe cu proiectarea, este lansat
un prototip pentru a înțelege cerințele. Acesta este dezvoltat pe baza cerințelor cunoscute în
prezent. Dezvoltarea prototipului conține fazele de proiectare, realizare și testare, dar acestea nu
sunt foarte riguroase sau formale. Prin intermediul prototipului clientul înțelege mai bine modul în
care lucrează produsul, întrucât interacționează 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 implicați direct în dezvoltare;
Susține tendința utilizatorilor de a-și modifica cerințele pe parcursul ciclului de
implementare;
Întrucât este lansat un model funcțional al sistemului, utilizatorii pot ințelege mai bine
modul de funcționare;
Erorile pot fi detectate mult mai devreme;
Feedback-ul utilizatorului este mai rapid, fapt ce duce la obținerea de soluții mai bune;
Timpul și costurile sunt reduse.
Printre dezavantaje, merită menționate:
Poate crește complexitatea SI, care se poate extinde dincolo de limitele stabilite inițial;
Analiza insuficientă a proiectului ca un întreg;
Programatorii pot deveni atașați de un prototip în a cărui dezvoltare au investit mult
timp și vor tinde să transforme prototipul într-un produs final chiar și atunci când
arhitectura de bază nu este cea potrivită;
Consumul excesiv de timp utilizat pentru implementarea unui prototip.
2.2. Procesele ciclului de viață
Fiecare etapă de creare a SI include executarea unor anumite lucrări – procese al ciclului de viață.
Un proces este definit ca un set de activități interdependente, care transformă intrările sistemului în
ieșiri. Descrierea unui proces include lista problemelor rezolvate, datele inițiale ș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 inițiază și realizează dezvoltarea,
exploatarea sau menținerea produsului program. Componentele ei sunt achizitorul,
furnizorul, dezvoltatorul, exploatatorul și menținătorul produsului program. Cele cinci procese
primare sunt:
o achiziție – definește activitățile de achizitor, organizaţia care achiziţionează un sistem,
un PP sau un serviciu soft;
o aprovizionare – defineşte activităţile de furnizor, organizaţie care livrează sistemul, PP
sau prestează serviciul solicitat de achizitor;
o dezvoltare - defineşte activităţile de dezvoltator, organizaţia care defineşte şi dezvoltă
produsul program;
o exploatare - defineşte activităţile operatorului – organizaţie, care oferă servicii de
operare a unui sistem informatic în mediul său pentru utilizatorii săi;
o întreţinere - defineşte activităţile de mentenanţă a organizaţiei care oferă serviciul de
menţinere a PP, de gestionare a modificărilor pentru a-l menţine actualizat şi
operaţional. Acest proces include activitățile de migrare şi de retragere din uz a PP.
2. Procesele auxiliare – includ opt procese, care susțin executarea altor procese cu scopul
garantării succesului și calității finale. Un proces auxiliar este lansat în execuție la necesitate
de un alt proces. Procesele auxiliare sunt:
o documentarea – definește activitățile de înregistrare a informației produse de un ciclu
de viață;
o managementul configurației - definește activitățile de gestiune a configurației;
o asigurarea calității - definește activitățile de asigurare obiectivă a conformității
produselor program și proceselor cu specificațiile lor;
o verificarea - definește activitățile (pentru achizitor, furnizor, sau o persoană
independentă), pentru verificarea produselor program în profunzime, în funcţie de
proiect;
o validarea - defineşte activităţile (pentru achizitor, furnizor, sau o o persoană
independentă), pentru validarea (atestarea) produselor program;
o revizuirea comună - defineşte activităţile de evaluare a stării şi produselor unei
activități;
o auditarea - defineşte activităţile pentru stabilirea conformităţii cu cerinţele, planurile
şi clauzele contractuale;
o soluționarea problemelor - defineşte un proces de analizare şi îndepărtare a
problemelor, indiferent de natura lor sau sursă, probleme descoperite în timpul
dezvoltării, funcţionării, întreţinerii etc.
3. Procesele organizaționale – includ patru procese realizate de către o organizaţie, care
stabilește şi pune în aplicare o structură de bază formată din procesele asociate ciclului de
viaţă şi de personal şi care are grijă de îmbunătăţirea continuă a acestei structurii şi a
proceselor. Procesele organizaţionale sunt:
o management - defineşte activităţile de bază ale managementului, inclusiv
managementul de proiect, în timpul unui proces al ciclului de viaţă;
o procesul de infrastructură - defineşte activităţile de bază pentru stabilirea structurii
unui proces al ciclului de viaţă;
o perfecționare - defineşte activităţile de bază pe care o organizaţie (achizitorul,
furnizorul, dezvoltatorul, operatorul, menținătorul sau managerul unui alt proces) le
efectuează pentru determinarea, măsurarea, controlul, precum şi îmbunătățirea
procesului ciclului său de viaţă;
o instruire - defineşte activităţile pentru furnizarea de personal instruit în mod adecvat.
Pentru susținerea utilizării 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. Conținutul proceselor primare
Standardul ISO/IEC 12207 stabilește conținutul proceselor primare, auxiliare și organizaționale. În
tabelul 2.1 este prezentată situația pentru procesele primare.
Tabelul 2.1. Conținutul proceselor primare conform ISO/IEC 12207
Proces
(executor) Acțiuni Intrare Ieșire
Achiziție
(achizitor)
Inițierea
Pregătirea cererii de
oferte (licitație)
Pregătirea și
actualizarea
contractului
Monitorizarea
furnizorului
Acceptarea și
completarea
Decizia privind
lansarea lucrărilor de
implementare a SI
Rezultatele analizei
activității
achizitorului
Rezultatele analizei
pieței produselor
program
Planul de
furnizare/dezvoltare
Test complex al SI
Studiu de fezbilitate privind
oportunitatea implementării
Sarcina tehnică pentru
crearea SI
Contract de furnizare/ creare
a SI
Actele de primire a etapelor
lucrărilor
Actul testărilor de
primire/predare
Furnizare
(dezvoltatorul/
furnizorul))
Inițierea
Pregătirea
răspunsului la
cererea de oferte
Pregătirea
contractului
Caietul de sarcini
Decizia conducerii de
participare
Rezultatele licitației
Sarcina tehnică
Planul de
Decizia de participare
Oferta comercială/ cerere de
participare la licitație
Contract de furnizare/ creare
a SI
Planul de management al
Planificarea executării
Executare și control
Verificare și evaluare
Furnizarea SI
management al
proiectului
SI elaborat și
documentat
proiectului
Realizarea/corectarea
Actul testărilor de
primire/predare
Dezvoltare
(dezvoltatorul)
Pregătirea
Analiza cerințelor
Proiectarea
arhitecturii
Analiza cerințelor
către 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 menținerii softului
ST pentru elaborarea
sistemului
ST pentru elaborarea
sistemului, modelul
ciclului de viață
Subsistemele SI
Specificațiile
componentelor soft
Arhitectura
produselor program
Materialele
proiectării de
deataliu a produselor
program
Planul de integrare,
testele
Arhitectura SI,
produselor program,
documentația SI,
testele
Modelul utlizat al ciclului de
viață, stadardele de
dezvoltare
Planul lucrărilor
Conținutul subsistemelor,
componentele tehnice
Specificațiile cerințelor
referitor la componentele
program
Conținutul componentelor
program, interfețele BD,
planul de integrare
Proiectul BD, specificațiile
interfețelor componentelor
program, cerințele pentru
teste
Codul modulelor program,
actele testărilor unitare
Evaluarea coformității setului
de programe cerințelor ST
Evaluarea coformității
produsului program, BD,
echipamentelor tehnice și
setului de documente
cerințelor ST
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 specialiști din diferite domenii:
În baza listei afacerilor, cu ajutorul matricei proiecțiilor este format clasificatorul funcțiilor business
al companiei (fig. 4.8).
Fig. 4.8. Șablonul formării funcțiilor business de bază
Pentru formarea funcțiilor de management principale mai întâi sunt elaborate și aprobate două
clasificatoare de bază – “Dispoziția privind componentele managementului” (lista instrumentelor
/contururilor administrative) și “Dispoziția privind etapele ciclului de management” (lanț tehnologic
de operații, realizate succesiv de manageri atunci când organizeză activitățile unui instrument/
contur administrativ). Analogic în continuare, folosind matricea proiecțiilor, este formată lista
funcțiilor principale ale managementului. În fig. 4.9 sunt prezentate exemple de clasificatoare în
baza cărora a fost construită matricea-generator al funcțiilor principale ale managementului.
Fig. 4.9. Șablonul formării funcțiilor administrative principale
Proiecțiile matriceale din figurile 4.8 și 4.9 permit formarea funcțiilor cu orice nivel de detaliere prin
descriere mai amănunțită a liniilor sau/și coloanelor.
Zonele de responsabilitate sunt formate cu ajutorul matricei proiecțiilor organizaționale folosind
șablonul din figura 4.10.
Fig. 4.10. Șablonul repartizării funcțiilor pe verigile organizaționale
Matricea proiecțiilor organizaționale este un tabel bidimensional cu titlurile liniilor formate din
verigile executorii, iar titlurile coloanelor – denumirile funcțiilor, executate în companie. Pentru
fiecare funcție este determinată veriga executorie, responsabilă de această funcție.
Procesul de completare a acestui tabel permite să se găsească, pentru fiecare funcție, subdiviziunea
executorie sau colaboratorul responsabil. Analiza tabelului completat permite să se determine
“golurile” atât pentru funcții, cât și pentru colaboratori, și să se rerepartizeze rațional lucrările pe
colaboratori. Toate acestea vor fi fixate în “Dispoziția privind structura organizațională a companiei”
– document intern, în care sunt fixate: produsele și serviciile companiei, funcțiile îndeplinite, verigile
executorii, funcțiile de producere, repartizarea funcțiilor pe responsabili.
Tabelul proiecțiilor funcțiilor pentru o organizație de mărime medie poate conține în jur de 500
elemente (de exemplu 20 verigi și 25 funcții). În cazul companiilor mari numărul elementelor poate
fi de ordinul câtorva mii.
În mod analogic are loc construirea matricei responsabilității comerciale.
4.2.3. Șablonul de descriere flux-proces
Șablonul de descriere flux-proces (fig. 4.11) asigură înțelegerea 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
Modalitățile de construire a modelelor proceselor vor fi prezentate mai jos.
4.3. Construirea modelului organizațional-funcțional al companiei
Modelul organizațional- funcțional companiei este construit în baza schemei funcționale a activității
companiei (fig. 4.12).
Fig. 4.12. Schema funcțională 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ă prelucrării resurselor în ciclul de producție de bază. Componentele sale formează business-
funcțiile necesare furnizarea resurselor, producția și distribuția produselor în locul de vânzare.
Pentru gestiunea procesului de reproducere este format colecția de componente de management,
care generează un set de funcții de management. Pentru a menține procesele de reproducere și de
management sunt formate seturi de funcții de sprijin aferente (de securitate, echipare tehnică,
profilactică și reparații, etc). Această abordare ne permite de a descrie organizația, cu ajutorul unui
set universal de registre de management (obiective, strategii, produse, funcții, unități
organizatorice, etc). Registrele administrative sunt clasificatoare ierarhice. Combinând
clasificatoarele în grupuri funcționale și fixând reciproc elementele din diferite clasificatoare cu
ajutorul proiecțiilor matriceale, poate fi obținut modelul structurii organizaționale a companiei.
Pentru construirea modelului funcțional-organizațional sunt utilizate două tipuri de modele
elementare.
Modelele arborescente (clasificatoarele) – liste ierarhice exacte al obiectelor administrative
evidențiate (verigi organizaționale, funcții, resurse, inclusiv mecanisme de execuție 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 informații de obicei calitative,
mulțimea cărora stabilește sistemul de coordonate pentru descrierea activității companiei.
Cantitatea acestor liste-clasificatoare este determinată de scopurile construirii modelului.
Modelele matriceale – sunt proiecții, care determină un sistem de relații pentru orice combinații
ale clasificatoarelor. Legăturile pot avea atribute suplimentare (direcție, denumire, indice, scală și
greutate).
În modelul inițial (de început) sunt utilizate doar câteve clasificatoare ale domeniul obiectiv:
grupurile principale de produse și servicii ale companiei;
resursele de care are nevoie compania pentru producere;
funcțiile (procesele) îndeplinite în companie;
verigile organizaționale ale companiei.
În clasificatorul funcțiilor de obicei sunt evidențiate trei compartimente de bază:
funcțiile de bază – funcțiile legate direct de procesul de transformare a resurselor în produse și servicii; funcțiile de management – sau funcțiile de conducere cu întreprinderea;
funcțiile de aprovizionare – care asistă activitățile de producere, comercială și de management.
Funcția principală a companiei este livrarea produselor și/sau prestarea serviciilor. Din această
cauză mai întâi are loc descrierea formală, coordonarea și aprobarea de către conducerea
întreprinderii a listei afacerilor (direcțiilor activității comerciale), produselor și serviciilor. Din acest
clasificator contragenților externi trebuie să le fie clar prin ce este interesantă compania pentru
piață, iar pe plan intern – cum este motivată necesitatea unei funcție concrete.
În rezultatul acestor operații are loc identificarea setului de funcții (funcționalului) și este creată
terminologia unitară de descriere a funcțiilor companiei, care va fi coordonată cu toți managerii
relevanți. Este important ca nivelul de detalizare a funcțiilor să corespundă nivelului de detalizare a
verigilor în clasificatorul verigilor organizaționale. După formarea clasificatoarelor principale, cu
ajutorul proiecțiilor matriceale are loc fixarea funcțiilor pe verigi organizaționale. Procesul formării
matricei proiecțiilor funcțiilor pe verigi organizaționale seamănă cu jocul de tic-tac-toe (fig.4.10).
Practica uzuală de construire a modelelor structurii organizațional-structurală susține două nivele de
detalizare:
modelul agregat;
modelul detalizat.
Modelul agregat este modelul structurii organizaționale în care registrele de evidență sunt limitate
la 2-3 nivele de detaliere.
Scopul construirii acestui model este punerea la dispoziția conducerii superioare a informației despre
structura organizațională pentru realizarea analizei strategice și analizei privind corespunderea
structurii date strategiei și mediului înconjurător al companiei. Modelul poate de asemenea pus la
dispoziția utilizatorilor externi (de exemplu, investitorilor potențiali sub formă de ilustrare a planului
business, clienților mari ș.a.).
Modelu detalizat este modelul structurii organizaționale cu o detalizare mai adâncă a registrelor de
evidență, decât în modelele agregate. Nivelul de detalizare este determinat de necesități concrete
ale companiei (crearea unor regulamente organizaționale).
Scopul construirii acestui model este prezentarea informațiilor despre repartizarea obligațiunilor
funcționale între subdiviziunile companiei, ca și despre organizarea proceselor business în companie.
Construirea modelului detalizat permite crearea diferitor regulamente interne, cum ar fi Dispoziția
despre structura organizațională (fig. 4.13).
Fig. 4.13. Schema elaborării Dispoziției despre structura organizațional-funcțională
Mai jos este prezentat un exemplu de descriere a unor fragmente ale modelului organizațional-
funcțional a unei întreprinderi (fig. 4.14) și a unei unități comerciale (fig. 4.15) Matricele proiecțiilor
prezentate servesc drept bază pentru evidențierea proceselor business ale companiei și stabilirea
posesorilor lor în cadrul următoarelor etape de creare a sistemului informațional.
Fig. 4.14. Repartizarea funcțiilor pe subdiviziuni (întreprindere)
Fig. 4.15. Repartizarea funcțiilor pe subdiviziuni (unitate comercială)
Funcțiile subdiviziunilor unei întreprinderi producătoare sunt prezentate pentru următoarele domenii
funcționale:
management corporativ;
finanțe;
personal;
resurse materiale;
comenzi;
producere;
elaborare produse;
planificare;
aprovizionare/achiziții;
calitate;
furnizare/vânzări.
Pentru unitatea comercială au fost alese alte domenii funcționale (fig. 4.15).
Henry Fayol, acreditat ca inițiatorul conceptului, a considerat că sunt cinci funcții principale, în
cuvintele lui: "Să conduci înseamnă să prevezi, să planifici, să organizezi, să comanzi, să coordonezi
şi să controlezi". Desigur că alți cercetători au venit cu alte listări, dar o cercetare a literaturii de
specialitate ne arată că funcții principale ale managementului sunt considerate următoarele:
funcțional și orientate obiect de descriere a domeniului obiectiv. Mtoda funcțională IDEF. Metoda funcțională a fluxurilor de date. Metoda obiect-orientată. Compararea metodelor existente. Metoda sintetică.
6.1. Modelul structural al domeniului obiectiv
La baza proiectării sistemelor informaționale 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
aspectelefuncționării noului sistem informațional. În acest caz, prin noțiunea de model al
domeniului obiectiv vor considera sistemul, care imită structura sau funcționarea domeniului
obiectiv cercetat și care respectă cerința de bază – corespunde acestui domeniu.
Modelarea prealabilă a domeniului obiectiv permite să fie diminuate timpul și termenele efectuării
lucrărilor de proiectare și să fie obținut un proiect mai efectiv și mai calitativ. Fără modelaria
domeniului obiectiv este mare probabilitatea unui număr mare de erori la soluționarea problemelor
strategice, care vor conduce la pierderi și cheltuieli suplimentare pentru lichidarea erorilor.
Reieșind din aceste considerente, toate tehnologiile de proiectare moderne sunt bazate ăpe
tehnologia modelării domeniului obiectiv.
Modelele domeniului obiectiv vor respecta următoarele cerințe:
formalizarea, care asigură descrierea univocă a structurii domeniului obiectiv;
comprehensibiltate pentru clienți și dezvoltatori bazată pe utilizarea unor instrumente
grafice de vizualizare a modelului;
realizabilitate, care presupune existența mijloacelor de realizare fizică a modelului în SI;
asigurarea posibilității de a evalua efectivitatea realizării modelului domeniului obiectivîn
baza unor metode acceptate și indicatori calculabili..
Pentru realizarea acestor cerințe, de regulă, este construit un sistem de modele, care reflectă
aspectele structural și estimativ al funcționării domeniului obiectiv.
Aspectul structural presupune construirea:
structurii obiectuale, care reflectă componența obiectelor materiale și informaționale ale
domeniului obiectiv, care interacționează în cadrul proceselor;
structurii funcționale, care reflectă legăturile reciproce ale funcțiilor (acțiunilor) atunci cînd
obiectele sunt transformate;
structurii managementului, care reflectă interacțiunea unităților organizaționale ale
întreprinderii și a personalului;
structurii tehnice, care descrie topologia plasării componentelor fizice și modalitățile de
comunicare între ele.
Pentru reflectarea aspectului structural al modelelor domeniului obiectiv sunt utilizate metode
grafice, care trebuie să garanteze prezntarea informațiilor despre componentele sistemului. Cerința
principală referitor la metodele grafice de documentare este simplitatea. Metodele grafice trebuie
să asigure posibilitatea decompoziției structurale a specificațiilor sistemului cu un grad maxim de
detalizare și coordonarea descrierilor pentru nivele adiacente de decompoziție.
Direct de modelare este asociată problema alegerii limbajului de prezentare a soluțiilor de proiect,
care să permită atragerea a unui număr cât mai mare de viitori utilzatori la elaborarea soluției.
Limbajul de modelare este notația, de obicei grafică, care este utilizată pentru descrierea
proiectului. Notația este setul de obiecte grafice, utilizate în model. Notația este sintaxa
limbajului de modelare. Limbajul de modelare, pe de o parte trebuie să facă soluțiile proiectanților
înțelese utlizatorului, iar pe de altă parte, să pună la dispoziția proiectanților mijloace pentru
identificarea soluțiilor 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 cuprinzătoare de prezentare. În acest caz, proiectanții
ar trebui să fie conștienți de faptul că metodele grafice de documentare nu pot descompune în
totalitate soluțiile de proiect de la enunțul problemei până la programe de calculator. Dificultăți
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 funcțională a sistemului informațional elaborat.
Aspectele estimative ale modelării domeniului obiectiv sunt legate de indicatorii de eficiență a
proceselor automatizate, la care pot fi plasați:
timpul de soluționare a problemelor;
prețurile de cost pentru procesare datelor;
fiabilitatea proceselor;
indicatori indirecți de eficință, cum sunt volumul producției, productivitatea muncii, rulajul
capitalului, rentabiltatea etc.
Pentru calcularea indicatorilor de eficiență sunt utilizate, de obicei, metodele statice ale analizei
funcții-cost și metodele modelării imitaționale.
La baza metodologiilor modelării domeniului obiectiv al SI se află principiile detalizării succesive a
categoriilor abstracte. De obicei, modelel sunt construite pe trei nivele: extern (determinarea
cerințelor), conceptual (specificarea cerințelor) și intern (realizarea cerințelor). La nivelul extern
modelul răspunde la întrebarea ce trebuie să facă sistemul, adică este stabilită lista componentelor
principale ale sistemului: obiecte, funcții, evenimente, untiăți organizaționale, mijloace tehnice. La
nivelul conceptual modelul răspunde la întrebarea cum trebuie să funcționeze sistemul? Cu alte
cuvinte, la acest nivel este determinat caracterul interacțiunii componentelor sistemului. La nivelul
intern modelul răspunde la întrebarea: care sunt mijloacele tehnice și logice necesare pentru
realizarea cerințelor sistemului? De pe pozițiile ciclului de viață a sistemului informațional nivelele
descrise ale modelului sunt construite respectiv la etapele de analiză a cerințelor, proiectării logice
(tehnice) și proiectării fizice. Vom analiza particularitățile construirii modelului domeniului obiectiv
pentru cele trei nivele de detalizare.
6.1.1. Structura obiectuală
Obiectul este entitatea utilizată la executarea unei funcții sau operații (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ă, plăți. Obiectele statice
sunt utilizate în mai multe cicluri de reproducere, de exemplu echipamentele, personalul, rezervele
materiale.
La nivelul extern de detalizare a modelului sunt evidențiate tipurile principale de obiecte materiale
(de exemplu, materia primă, semifabricatele, produsele finite, serviciile) și informaționale sau
documente (de exemplu, comenzile, bonurile de trăsură, conturile etc.).
La nivelul conceptual este specificată componența claselor de obiecte, sunt determinate atributele
și legăturile lor; are loc crearea unei imagini generale a structurii domeniului obiectiv.
La nivel intern modelul conceptual este reflectat sub formă de fișiere ale bazei de date, documente
de intrare și ieșire ale sistemului. Obiectele dinamice vor fi reprezentate prin unități de informații
variabile sau documente, iar obiectele statice – prin unități de informații convențional constante
sub formă de liste, nomenclatoare, liste de prețuri, dicționare, clasificatoare. Modelul bazei de
date, în calitate de resursă informațională menținută constant, reflectă păstrarea informațiilor
convențional-constante și informațiilor variabile cumulate, utilizate în procesele informaționale
repetitive.
6.1.2. Structura funcțională
Funcția (operația) este un fel de convertor al intrărilor în ieșiri. Secvența de funcții legate reciproc
pe intrări și ieșiri se numește proces business. O funcția a procesului business poate genera
obiecte de orice natură (materiale, informaționale, financiare). Procesele business și procesele
informaționale, de regulă, sunt inseparabile, adică funcțiile unui proces material nu pot fi efectuate
fără suport informațional. De exemplu, recepția producției finite are loc în baza documentului
“Ordin”, care, la rândul său, generează documentul însoțitor “Factură”.
Funcția poate fi prezentată printr-o singură acțiune sau o secvență de acțiuni. În ultimul caz
fiecărei funcții poate corespunde un proces oarecare, care poate avea subprocese, ș.a.m.d., până
la momentul în care fiecare subfuncție va reprezenta o secvență nedecompozabilă de acțiuni.
La nivelul extern al modelării este determinată lista fubncțiilor business principale sau tipurilor de
procese business. De obicei funcții de acest tip sunt în jur de 15 – 20.
La nivelul conceptual funcțiile selectate sunt descompuse și sunt construite ierarhii de funcții
interdependente.
La nivelul intern structura ptocesului informațional este reflectată în calculator: sunt stabilite
structurile ierarhice ale modulelor program, care realizează funcțiile automatizate.
6.1.3. Structura managementului
În setul de funcții ale procesului business sunt posibile secvențe alternative sau ciclice în
dependență de condițiile în care are loc procesul. Aceste condiții sunt legate de evenimentele, care
au loc în mediul extern sau în interiorul proceselor, ca și de anumite stări ale obiectului (de
exemplu, comanda a fost acceptată, refuzată, transmisă pentru introducerea unor corectări).
Evenimentele generează execuția funcțiilor, care, la rândul lor, modifică starea obiectelor și
generează noi evenimente, ș.a.m.d., până șa terminarea procesului business. În acest caz vom
spune, că secvența de evenimente reprezintă o realizare concretă a procesului business.
Fiecare eveniment este descris din două puncte de vedere: informațional și procedural. Un
eveniment informațional este prezent sub forma unui mesaj, care fixează faptul îndeplinirii unei
funcții de modificare a stării sau apariția unei stări noi. Un eveniment procedural apelează execuția
unei funcții noi, din această cauză pentru fiecare stare a obiectului trebuie să fie specificate aceste
apeluri. În așa mod, evenimentele au rolul de legătura în execuția funcțiilor proceselor business.
La nivelul extern este determinată lista evenimentelor externe, generate de intercțiunea
întreprinderii cu mediul extern (plata impozitelor, procentelor pentru credite, contractelor etc.), și
lista indicațiilor-obiective (consecință a obiectivelor organizației), cărora trebuie să corespundă
procesele business (regulamentul de îndeplinire a proceselor, menținerea nivelului necesar al
rezervelor materiale, nivelul calității producției etc.).
La nivelul conceptual sunt stabilite regulile business, care determină condițiile de apelare a
funcțiilor la producerea unui eveniment sau trecerea procesuluiîntr-o stare anume.
La nivelul intern are loc formalizarea regulilor business sub formă de triggere sau apelări ale
modulelor program.
6.1.4. Structura organizațională
Prezintă un set de unități organizaționale, de regulă, legate prin relații ierarhice și procesuale.
Unitatea organizațională este subdiviziunea, care reprezintă reuniunea de oameni (personal)
pentru îndeplinirea inui set de funcții comune sau procese business. Într-o structură
organizațională funcțional-orientată unitatea organizațională execută un set de funcții, care fac
parte dintr-un singur tip de procese și care au atribuție pentru diferite funcții de managemnt.
La nivelul extern este construit modelul structural al întreprinderii sub formă de ierarhie de
subordonare a unităților organizaționale sau liste de subdiviziuni care interacționează.
La nivelul conceptual pentru fiecare subdiviziune este stabilită structura organizațională a
statelor (funcțiilor, rolurilor personalului).
La nivelul intern sunt stabilite cerințele referitoare la drepturile personalului de accesare a
funcțiilor automatizate ale SI.
6.1.5. Structura tehnică
Topologia determină plasarea teritorială a resurselor tehnice în cadrul subdiviziunilor întreprinderii,
iar comunicațiile – modul tehnice de realizare a interacțiunii 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 modalitățile de organizare a comunicațiilor între resursele
tehnice ale subdiviziunilor structurale: deplasarea fizică a documentelor, suporților de memorie,
schimbul de informații prin canale de comunicații etc.
La nivelul intern este construit modelul arhitecturii “client-server” al rețelei de calculatoare.
Modelele descrise ale domeniului obieciv sunt direcționate spre proiectarea unor componente
separate ale SI: date, module program funcționale, module program de gestiune, interfețe ale
utilizatorilor, structuri ale complexului tehnic. Pentru o proiectare mai calitativă a acestor
componente este necesar să fie construite modele, care să integreze componentele. În cel mai
simplu caz în calitate de asemenea modele de interacțiune pot fi utilizate matricele referințelor
încrucișate: “obiecte-funcții”, “funcții-evenimente”, “unități organizaționale-funcții”, “ unități
organizaționale-obiecte”, “ unități organizaționale-mijloace tehnice” ș.a.m.d. Însă aceste matrice
sunt greu de înțeles și nu reflectă particularitățile realizării interacțiunilor.
Pentru o reflectare corectă a interacțiunilor componentelor SI este importantă realizarea modelării
concomitente a acestor componente, în special din punctul de vedere al obiectelor și funcțiilor.
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 număr tot mai mare de
niveluri. Pentru aceste metode este caracteristic:
divizarea pe nivele de abstractizare cu un număr limitat de elemente (de la 3 la 7);
un context limitat, care include doar detaliile esențiale ale fiecărui 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
ordonării ierarhice. Soluționarea problemelor dificile prin divizarea lor în mai multe sarcini
independente mici (așa-numitele "cutii negre") și organizarea acestor sarcini în structuri
arborescente ierarhice în mod semnificativ sporesc nivelul de înțelegere a sistemelor complexe. Mai
jos sunt prezentate definițiile unor noțiuni-cheie din domeniul analizei structurale.
Operație – acțiune elementare (indivizibilă), excutată la un singur loc de lucru.
Funcție – set de operații, gruoate în funcție de anumiți indicatori.
Proces business – set de funcții legate, în cadrul execuției căruia sunt utilizate anumite resurse și
este creat un produs (obiect, serviciu, descoperire științifică, 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 rețele de procese și operații, legate de date,
documente, unități organizaționale și alte obiecte, care reflectă activitatea existentă sau presupusă
a companiei.
Există diferite metodologii de modelare structurală a domeniului obiectiv, printre care trebuie de
evidențiat metodologiile orientate pe funcții și orientate pe obiecte.
6.2. Metodologii orientate pe funcții și orientate pe obiecte
Procesul modelării business poate fi realizat în cadrul unor metode, care diferă în primul rând prin
modul de abordare a organizației modelate. În conformitate cu acest criteriu există metode
funcționale (structurale) și metode orientate pe obiect.
În cadrul metodelor obiect-orientate organizația modelată este considerată set de obiecte, care
interacționează – unități de producție. Obiectul este definit ca model informaţional al unei entităţi
din lumea reală, care are proprietăţi şi comportament specific. Scopul utilizării unei metode obiect
orientate este identificarea obiectelor, care formează organizația, și reaprtizarea între obiecte a
responsabilităților pentru acțiunile executate în cadrul organizației.
Metodele funcționale, dintre care cea mai cunoscută este metoda IDEF, consieră organizația ca set
de funcții, care transformă fluxul de informații la intrare în flux de ieșire. Procesul de transformare
a informației consumă anumite resurse. Diferența principală de la metoda orientată pe obiecte
constă în separarea distinctă a funcțiilor (metodele de prelucrare a datelor) de datele propriu-zise.
Din punctul de vedere al modelării afacerii fiecare abordare are avantajele sale. Abordarea
obiectuală permite construirea unor sisteme mai stabile la modificări, corespunde mai bine
structurilor existente în organizație. Modelarea funcțională se manifestă mai bine atunci când
structura organizațională este în proces de modificare sau, în genere, este salb conturată.
Abordarea care pleacă de la funcțiile îndeplinite este la nivel intuitiv mai bine înțeleasă de executori
ceea ce facilitează procesul obținerii informațiilor necesare pentru analiză și stabilirea cerințelor.
6.2.1. Metodologia IDEF0
Poate fi considerată etapa următoare de dezvoltare a binecunoscutului limbaj grafic pentru
descrierea sistemelor funcționale SADT (Structured Analysis and Design Technique). IDEF în
calitate de standard a apărut în anul 1981 în cadrul unui program extins consacrat automatizării
întreprinderilor industriale, numit ICAM (Integrated Computer Aided Manufacturing). Familia
stadardelor IDEF a moștenit denumirea chiar de la numele acestui program Icam DEFinition.
Ultima redacție a fost publicată în decembrie 1993 de Institutul Național pentru Standarde al SUA
(NIST).
Obiectivul metodei este constrirea schemei funcționale a sistemului cercetat, care descrie toate
procesele relevante cu exactiatea suficientă pentru modelarea univocă a activității sistemului.
La baza metodologiei se află patru noțiuni funcdamentale: blocul funcțional, arcul de interfață,
decompoziția și glosarul.
Blobul funcțional (Activity Box) reprezintă o funcție concretă (oarecare) a sistemului cercetat.
Comform cerințelor standardului denumirea fiecărui bloc funcțional trebuie să fie formulată în
formă de verb (de exemplu, “prestează servicii”. În cadrul unei diagrame blocul funcțional 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 stânga are valoarea “Intrare” (Input);
latura verticală din dreapta are valoarea “Ieșire” (Output);
latura orizontală de jos are valoarea “Mecanism” (Mechanism).
Fig. 6.1. Blocul funcțional
Arcul de interfață (Arrow) indică elementul sistemului, care este prelucrat de către blocul
funcțional sau influențează funcția, reprezentată de acest bloc. Arcele de interfață sunt numite
frecvent fluxuri sau săgeți.
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 informații (documente, date, instrucțiuni etc.).
În dependență de latura blocului funcțional la care vine arcul el se va numi “de intrare”, “de ieșire”
sau “de control”.
Conforma standardului, orice bloc funcțional trebuie să posede minimum un arc de control și un arc
de ieșire – un proces are loc conform anumitor reguli (arcul de control) și trebuie să genereze
obligator un rezultat (o ieșire). În caz contrar blocul nu are sens.
Prezența obligatorie a arcelor de control este ua din diferențe principale ale standardului IDEF0 de
alte metodologii din clasa DFD (Data Flow Diagram) și WFD (Work Flow Diagram).
Decompoziția (Decomposition) este noțiunea centrală (de bază) a standardului IDEF0. Principiul
decompoziției este utilizat la divizarea unui proces complex în funcții componente. Nivelul de
detaliere este determinat de creatorul modelului.
Decompoziția permite prezentarea graduală și structurată a modelului sistemului sub formă de
structură ierarhică a unor diagrame separate, ceea ce face diagrama mai puțin încărcată și mai
ușor de înțeles și de manipulat.
Pentru fiecare element al IDEF0 – diagrame, blocuri funcționale, arce de interfață – standardul
presupune crearea și întreținerea unui set de definiții, cuvinte-cheie, rezumate narative etc., care
caraterizează obiectul determinat de acest element. Acest set se numește glosar și descrie
Un model IDEF0 începe cu prezentarea sistemului ca un tot întreg – un bloc funcțional cu arcele de
interfață, care se extind dincolo de domeniul studiat. Această diagramă cu un singur bloc funcțional
se numește 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 stabilește domeniile sistemului studiat, asupra cărora trebuie
focalizată atenția în primul rând.
Punctul de vedere determină direcțiile principale de dezvoltare a modelului și nivelul
necesar de detalizare. Fixarea clară a punctului de vedere permite descărcarea modelului,
refuzând la detalizare și cercetarea unor elemente separate, care nu sunt necesare reieșind din
punctul de vedere ales. Alegerea corectă a punctului de vedere diminuează cheltuielile temporale
pentru construirea modelului final.
În procesul de decompoziție blocul funcțional, care în diagrama de context reprezintă sistemul ca
un tot întreg, va fi supus într-o altă diagramă, detalizării. Diagrama obținută, de nivelul 2, include
blocurile funcționale, ce reflectă subfuncțiile principale ale bolcului funcțional din diagrama de
context, și se numește diagramă-fiu (Child Diagram) în relația cu diagrama de context. Fiecare
dintre blocurile funcționale, care aparțin diagramei-fiu, se numește bloc-fiu Child Box, respectiv –
blocul funcțional predecesor se numește bloc părinte (Parent Box), iar diagrama la care acesta
aparține – diagramă părinte (Parent Diagram). Fiecare subfuncție a diagramei fiu poate fi în
continuarea detalizată prin decompoziția analogică a blocul său. În fiecare caz de decompoziție a
blocului funcțional 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 considerație î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 supraîncărca diagramele și le-ar face mai complicate pentru
percepție. Pentru soluționarea unor probleme de acest gen în standardul IDEF0 a fot introdusă
noțiunea tunelare. Notația “tunel” (Arrow Tunnel) sunb formă de două parateze rotunde în jurul
începutului arcului de intrefață semnifică, că acest arc nu a fost moștenit de la blocul funcțional
părintesc și a apărut (din “tunel”) doar în această diagramă. Aceeași notație în jurul sfârșitului unui
arc (săgeata) în imediata vecinătate de blocul de recepție semnifică faptul, că în digarama-fiu a
acestui bloc acest arc nu va fi luat în considerație (nu va fi prezent) Cel mai frecvent are loc
situația în care unele obiecte și arcele respective ale lor nu sunt luate în considerație la unele
nivele intermediare. Se spune în aceste cazuri, că obiectele mai întâi “intră în tunel”, iar apoi, la
necesitate “se întorc din tunel”.
De obicei modelele IDEF0 conțin informații complexe și concentrate. Pentru a limita
supraîncărcarea lor și a păstra comoditatea folosirii, standardul include posibilitatea limitări
comăplexității.
Se recomandă ca o diagramă să includă de la 3 pînă la 6 blocuri funcționale, iar numărul de arce
de intrare la un bloc funcțional, ca și de ieșire dintr-un bloc funcțional, să nu depășească 4.
Standardul IDEF0 conține un set de proceduri, care permit elaborarea și coordonarea modelului de
grupuri mari de oameni, din diferite doemnii de activitate a sistemului modelat. Procesul de
elaborare este iterativ și include următoarele etape:
Crearea modelului de un grup de specialiști din diferite domenii de activitate a companiei.
Ascest grup, în terminologia IDEF0, se numește autori (Authors). Construirea modelului de
început este un proces dinamic în cadrul căruia autorii chestionează persoanele competente
referitor la structura diferitor procese, elaborând modele ale activității subdiviziunilor. În
cadrul acestui proces vor fi căutate răspunsuri la următoarele întrebări:
Ce avem la intarea subdiviziunii?
o Care sunt funcțiile și în ce ordine ele sunt executate în cadrul subdiviziunii?
o Cine este reaponsabil de executare unei funcții anume?
o Care este rezultatul activității subdiviziunii (ieșirea)?
În baza documentelor existente și în rezultatul chestionării este creat proiectul modelului
(Model Draft)
Difuzarea draftului modelului pentru informare, coordonare și comentare. La această etapă are loc discutarea proiectului modelului de cât 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, motivând neacceptarea, și întoarce cernovicul corectat pentru discuții ulterioare. Acest ciclu continuă până la momentul în care autorii și cititorii vor ajunge la consens.
Aprobarea oficială a modelului este responsabilitatea conducătorului 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 fără o pragătire anterioară
specială și care nu au participat în elaborarea modelului. Instrumentele IDEF0 sunt utlie și pentru
demonstrații și prezentări. Î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 ieșirilor (reacția
sistemului în formă de date) pentru intrări cunoscute (semnale la intrare prin interefețele externe).
Diagramele fluxurilor de date sunt instrumentul principal de modelare a cerințelor funcționale ale
sistemului proiectat.
La crearea diagramei fluxurilor de date sunt utuilizate trei noțiuni principale: fluxuri de date,
procese (lucrări) de transformare a fluxurilor de intrare în ieșiri, entități externe și
depozite de date (repozitorii).
Fluxurile de date sunt abstracții, utilizate pentru modelarea transferului de informații (sau a
componentelor fizice) dintr-o parte a sistemului în alta. Pe o diagramă fluxurile sunt reprezentate
de săgeți, care au nume, iar orientarea lor indică direția de deplasare a informației.
Destinația procesului (lucrării) constă în producerea fluxurilor de ieșire din fluxurile de intrare în
conformitate cu acțiunea, indicată de numele procesului. Numele unui proces trebuie să fie un verb
în forma indefinită urmat de un complement (de exemplu, “recepționare documente de livrare a
producției”). Fiecare proces are un număr unic pentru a putea fi referit în interiorul diagramei.
Numărul poate fi utilizat împreună cu numărul diagramei pentru a obține indicile uncal al
procesului în cadrul întregului model.
Depozitul de date (repozitoriul) permite determinarea datelor pentru sectoarele indicate, care vor fi
păstrate în memorie între procese. De facto, depozitul prezintă “secțiuni” temporale ale fluxurilor.
Informația care se conține î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ă
conținutului 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 entității externe trebuie să conțină un substantiv, de
exemplu, “depozit de mărfuri”. Obiectele, reprezentate prin entități externe, nu vor participa în
prelucrări de date.
În afara elementelor principale în DFD intră dicționarele de date și minispecifacțiile procesării.
Dicționarele 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.
Minispecificațiile procesării descriu procesele DFD de nivel inferior. De facto, minipecificațiile
reprezintă algoritmii de descriere a lucrărilor, îndeplinite de procese: mulțimea tuturor
minispecificațiilor este specificația totală a sistemului.
Procesul de construire a DFD începe cu crearea diagramei principale de tip “stea” în care este
prezentat procesul modelat și toate entitățile externe, cu care procesul interacționează. Dacă
procesul principal este complicat el va fi prezentat din start descompus într-o serie de procese,
care interacționează. Criterii de complexitate pot fi: existența unui număr mare de entități externe,
multifuncționalitatea sau caracterul distribuit al sistemului. Entitățile externe vor fi evidențiate
pentru procesul principal. Pentru determinarea lor vor fi evidențiați furnizorii și consumatorii
procesului principal, adică toate obiectele care interaționează cu procesul principal. La această
etapă descrierea interacțiunii 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 “evidența petițiilor cetățenilor”, entitatea externă – “cetățean”, descrierea interacțiunii
“depune petiție și primește răspuns”. Această etapă este una importantă principial fiindcă anume
aici sunt stabilite granițele sistemului modelat.
Pentru fiecare entitate externă este construit tabelul evenimentelor, care descrie interacțiunea
entității cu procesul principal. Tabelul evenimentelor include denumire entității externe,
evenimentul, tipul lui (ordinar/tipic pentru sistem sai excepțional, adică reaqlizat în condiții
speciale) și reația sistemului.
La pasul următor are loc decompoziția 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 interacțiunii lor. Decompoziția este finalizată în momentul în care procesul devine
simplu, adică:
1. procesul are două-trei fluxuri de intrare și de ieșire;
2. procesul poate fi descris sub formă de transformare a intrărilor în ieșiri;
3. procesul poate fi descris sub forma unui algoritm secvențial.
Pentru procesele simple este elaborată minispecificația – descrierea formală a algoritmului de
transformare a intrărilor în ieșiri.
Minispecificațiile vor răspunde următoarelor cerințe: pentru fiecare proces este elaborată o singură
specificație; specificația determină în mod univoc fluxurile de intrare și de ieșire pentru procesul
dat; specificația nu determină modul de transformare a fluxurilor de intrare în fluxuri de ieșire;
specificația face referință doar la elementele existente fără a introduce elemente noi; specificația
va utiliza în măsura posibilităților operații și abordări standard.
După ce procesul principal a fost descompus va fi construite pentru fiecare subproces tabele
analogice ale evenimentelor interne.
La următorul pas, după determinarea tabelului complet al evenimentelor, vor fi evidențiate
fluxurile de date cu care procesele fac schimb, și entitățile externe. Cea maisimplă modalitate
este analiza tabelului evenimentelor. Evenimentele sunt transformate în fluxuri de date de la
inițiatorul evenimentului la procesul solicitat, iar reacțiile – în flux invers de evenimente. După
construirea fluxurilor de intrare și ieșire în mod analogic sunt construite fluxurile interne. Pentru
evidențierea lor vor fi selectați furnizorii și consumatorii informațiilor pentru fiecare proces intern.
Dacă un furnizor sau un consumator de informații este un proces de păstrare sau de solicitare de
informații, atunci va fi introdus depozitul de date, pentru care acest proces servește drept
interfață.
După construirea fluxurilor de date diagrama va fi verificată la completitudine și lipsa
contradicțiilor. Completitudinea unei diagrame este asigurată dacă în sistem nu există procese
neutilizate în procesul de transformare a intrărilor în ieșiri. Lipsa contradicțiilor 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ă entități externe – o astfel de intercțiune trebuie lichidată; nici o
entitate nu poate direct primi din sau transmite informații în depozit – depozitul de date este un
element pasiv, gestionat cu ajutorul procesului de interfațare; două depozite de date nu pot să
facă schimb direct de informații – astfel de depozite trebuie comasate în unul singur.
În calitate de avantaje ale metodei DFD amintim:
posbilitatea determinării univoce a entităților externe, analizând fluxurile de informații din
sistem și din afara lui;
posbilitatea proiectării de sus în jos, prin aceasta simplificând construirea modelului “to be”;
prezența specificațiilor proceselor de nivel inferior, cea ce permite să se treacă de
nonfinalizarea logică a modelului funcțional și să se constriască specificațiia funcțională
completă a sistemului elaborat.
La dezavantaje: necesitatea introducerii artificiale a proceselor administrative (de conducere,
control sau gestiune), deoarece acțiunile de conducere (fluxuri) și procesele de conducere din
punctul de veder al DFD nu se deosebesc prin nimic de cele obișnuite; lipsa nuțiunii de timp, adică
lipsa analizei intervalelor de timp la transforamrea datelor (toate constrângerile temporale trebuie
introduse în specificațiile proceselor).
6.2.3. Metoda obiect-orientată
Diferența principială între abordarea funcțională și cea obiectuală constă în modalitatea de
descompunere sistemului. În abordarea obiect-orientată este utilizată decompoziția obiectuală în
care structura statică este descrisă în termeni de obiecte și legături între ele, iar comportamentul
sistemului – în termeni de schimb de mesaje între obiecte. Scopul metodei este construirea
modelului business al organizației, care permite trecerea de la modelul scenariilor de utilizare la
modelul, ce determină obiectele separate participante în realizarea funcțiilor business.
Baza conceptuală a abordării obiect-orientate este formată de modelul obiectual, care este
construit conform următoarelor principii:
abstractizare;
incapsulare;
modularitate;
ierarhi;
tipizare;
paralelism;
stabilitate.
Noțiunile de bază ale abordării obiect-orientate sunt obiectul și clasa.
Un obiect înglobează date și operații și reprezintă o abstracțiune a unei entități din lumea reală.
Obiectul are un comportament bine definit, desemnat de stările în care se poate afla și de
individualitatea proprie.
Clasa este o descriere a unei mulțimi de obiecte caracterizate prin structură și comportament
similare. Programele sunt organizate ca ansamble de obiecte ce cooperează între ele, fiecare obiect
reprezentând instanța unei clase; fiecare clasă aparține unei ierarhii de clase în cadrul căreia
clasele sunt legate prin relații de moștenire.
La baza abordării obiect-orientate stau următoarele concepte:
abstractizarea;
incapsularea;
modularitatea;
ierarhizarea;
moștenirea;
agregarea.
O abstracțiune exprimă toate caracteristicile esențiale ale unui obiect, care fac ca acesta să se
distingă de alte obiecte; abstracțiunea oferă o definire precisă a granițelor conceptuale ale
obiectului, din perspectiva unui privitor extern. În procesul de abstractizare atenția este îndreptată
exclusiv spre aspectul exterior al obiectului, adică spre comportarea lui, ignorând implementarea
acestei comportări. Cu alte cuvinte abstractizarea ne ajută să delimităm ferm "CE face obiectul" de
"CUM face obiectul ceea ce face".
Incapsularea este conceptul complementar abstractizării. Dacă rezultatul operației de
abstractizare pentru un anumit obiect este identificarea protocolului său, atunci incapsularea are
de a face cu selectarea unei implementări și tratarea acesteia ca pe un secret al respectivei
abstracțiuni. Prin urmare, incapsularea este procesul în care are loc ascunderea implementării unui
obiect față de majoritatea clienților săi.
Altfel spus, incapsularea este procesul de compartimentare a elementelor care formează structura
și comportamentul unei abstracțiuni; incapsularea servește la separarea interfeței "contractuale"
de implementarea acesteia.
Din definiția de mai sus rezultă că un obiect este format din două părți distincte:
interfața (protocolul)
implementarea interfeței.
Abstractizarea este procesul prin care este definită interfața obiectului, în timp ce incapsularea
definește reprezentarea (structura) obiectului împreună cu implementarea interfeței.
Clasele și obiectele obținute în urma abstractizării și incapsulării trebuie grupate și apoi stocate
într-o formă fizică, denumită modul. Modulele pot fi privite ca un fel de containere fizice în care
declarăm clasele rezultate în urma proiectării la nivel logic. Asadar, modulele formează arhitectura
fizică a programului.
Modularizarea constă în divizarea programului într-un număr de subunități care pot fi compilate
separat, dar care sunt cuplate (conectate) între ele. Gradul de cuplaj între module trebuie să fie
mic, pentru ca modificările aduse unui modul să afecteze cât mai puține alte module.
Incapsularea și modularizarea reprezintă procese similare dar care se desfășoară la nivele diferite:
incapsularea se aplică la nivelul "microcosmosului" (obiectele), iar modularizarea la nivelul
"macrocosmosului" (programele).
Reguli utile de modularizare
1. Structura fiecărui modul trebuie să fie suficient de simplă pentru a putea fi complet
înțeleasă.
2. Implementarea unui modul trebuie să depindă doar de interfețele altor module. Cu alte
cuvinte trebuie să fie posibilă modificarea implementării unui modul fără a avea cunoștințe
despre implementarea altor module și fără 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 legături între module vor fi acelea a căror 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 decât prin intermediul
obiectelor și claselor conținute în acel modul.
Ierarhizarea reprezintă o ordonare a abstracțiunilor. Cele mai importante ierarhii în paradigma
obiectuală sunt:
ierarhia de clase (relație de tip "is a")
ierarhia de obiecte (relație de tip "part of")
Moștenirea (ierarhia de clase) definește o relație între clase în care o clasă împărtășește structura
și comportarea definită în una sau mai multe clase (după caz vorbim de moștenire simplă sau
multiplă). Relația de moștenire face diferența între programarea orientată pe obiecte și cea bazată
pe obiecte. Semantic, moștenirea indică o relație 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 relația între două obiecte în care unul dintre obiecte aparține
celuilalt obiect. Agregarea redă apartența unui obiect la un alt obiect. Semantic, agregarea indică o
relație de tip "part of" ("parte din").
O calitate importantă a abordării obiectuale constă în consistența modelelor activității organizației
și modelelor sistemului informațional proiectat de la etapa formulării cerințelor până la etapa
implementării. Prin intermediul modelelor obiectuale poate fi urmărită reflectarea entităților reale
ale domeniului obiectiv modelat (a organizației) în obiecte și clase ale sistemului informațional.
Majoritatea metodelor existente de abordare obiectuală includ limbajul de modelare și descrierea
procesului de modelare. Prin proces se înțelege descrierea pașilor, care trebuie parcurși 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 stări,
diagrama de componente, diagrama de construcție, diagrama de obiecte, diagrama de activități.
Abordarea obiect-orientată are următoarele avantaje:
Decompoziția obiectuală permite crearea modelelor de dimensiuni mai micprin utilizarea
unor mecanisme comune, care asigură economia necesară a mojloacelor de exprimare.
Abordarea orientată obiect sporește semnificativ nivelul de unificare a procesului de
elaborare și reutilizare a componentelor.
Decompoziția obiectuală permite să se evite crearea unor modele complicate, deoarece
presupune dezvoltarea evoluțională a modelului în baza unor subsisteme relativ mici.
Modelul obiectual este unul firesc deoarece este bazat pe percepția 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
Funcțiile (operațiile, actțiunile, lucrările), legate pe diagrame prin fluxuri de obiecte, sunt
componentele structurale principale ale modelelor funcționale (diagramele DFD sau SADT).
Un avantaj indiscutabil al modelelor funcționale este realizarea abordării structurale pentru
proiectarea SI conform principiului “top-down”, când fiecare bloc funcțional poate fi descompus
într-o mulțime de subfuncții ș.a.m.d., realizând proiectarea modulară a SI. Pentru modelele
funcționale sunt caracteristice rigurozitatea procedurală a decompoziției SI și prezentarea clară.
Abordarea funcțională presupune crearea separată a modelelor obiect sub formă de diagrame ER
“obiect-proprietate-relație”. Pentru verificarea corectitudinii modelării domeniului obiectiv între
modelul funcțional și cel obiectual sunt stabilite relații biunivoce.
Principalul dezavantaj al modelelor funcționale constă în faptul, că procesele și datele există
independent unele de altele – în afara decompoziției funcționale există, într-un plan secundar,
structura datelor.Mai mult, nu sunt clare condițiile de îndeplinire a proceselor de prelucrare a
informațiilor, care pot să se schimbe dinamic.
Aceste dezavantaje sunt excluse în modelele obiect-orientate în care clasa de obiecte cu setul de
funcții asociat este componenta structurală principală.
Pentru clasele de obiecte este caracteristică ierarhia generalizatoare, care permite moștenirea nu
doar a atributelor (proprietăților) obiectelor clasei de nivel mai înalt, dar și a funcțiilor (metodelor).
În cazul moștenirii funcțiilor se poate face abstracție de o realizare concretă a procedurilor (tipuri
abstracte de date), care diferă pentru anumite subclase de situații. 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ă decât în cazul abordării funcționale.
Chiar și principiul proectării este modificat în abordarea obiect-orientată. Mai întâi sunt stabilite
clasele obiectelor, iar în continuare în dependență de stările posbile ale obiectelor (ciclului de viață
a obiectelor) sunt determinate metodele de procesare (procedurile funcționale), ceea ce asigură o
mai bună realizare a comportamentului dinamic al sistemului informațional.
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 funcționale din punctul de vedere al clarității.
Metoda modelării domeniului obiectiv este aleasă reieșind din gradul de dinamism al domeniului.
Pentru situațiile cu un nivel mai înalt de reglementare sunt recomandate modelele funcționale, iar
pentru procese business cu un grad de adaptivitate mai înalt (gestiunea fluxurilor de lucru,
realizarea solicitărilor dinamice la depozite de date) – modele obiect-orientate. În unele cazuri, în
cadrul aceluiași sistem pentru diferite clase de problem pot fi necesare diferite tipuri de modele,
care să descrie același domeniu obiectiv. În acest caz vor fi utilizate modele mixte ale domeniului.
6.3. Metoda sintetică
Cum a fost subliniat mai sus, fiecare din metode permite soluționarea problemei construirii
descrierii formale a procedurilor de lucru ale sistemului cercetat. Toate metodele permit elaborarea
modelului “as is” și “to be”. În același timp, fiecare metodă are nejunsuri substanțiale. Însă
neajunsurile utilizării unei metode nu se află în sfera descrierii proceselor reale, ci în
incompletitudinea abordării metodice.
Metodele funcționale aduc o claritate mai mare referitor la funcțiile existente în organizație,
metodele de realizare a acestora, iar calitatea descrierii sistemului crește odată cu creșterea
nivelului de detalizare a obiectului studiat. Prin creșterea calității descrierii se are în vedere
obținerea 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 metodele funcționale permit interpretări neunivoce referitor la
alegerea interfețelor și mecanismelor sistemului, adică la stabilirea granițelor sistemului. La acest
nivel abordarea obiect-orientată vine cu soluții mai bune, bazate pe noțiunea scenariul de utilizare.
Momentul cheie este reprezentat de noțiunea de scenariu de utilizare sub formă de sesiune de
interacțiune a utilizatorului cu sistemul, în rezultatul căreia utilizatorul obține ceva ce prezintă
valoare. Utilizarea criteriului valorii permite utilizatorului să excludă detaliile secundare ale fluxului
de lucru și să se concentreze asupra funcțiilor, care justifică existența sistemului. Totuși, și în acest
caz problema determinării granițelor sistemului, evidențierea utilizatorilor externi este complicată.
Tehnologia fluxurilor de date, care este istoric prima tehnologie, rezolvă ușor problema granițelor,
deoarece prin analiza fluxurilor informaționale permite să fie evidențiate entitățile externe și
determinat procesul intern principal. Însă, lipsa proceselor explicite de conducere, fluxurilor și
orientării pe evenimente impune căutarea unor tehnologii suplimentare complementare.
Cea mai bună modalitate de eliminare a neajunsurilor menționate mai sus este formarea unei
metode sintetice, care să reunească avantajele metodelor studiate mai sus.
Ideea metodei sintetice constă în utilizarea succesivă a abordărilor funcționale și obiectuale ținând
în vizor posibilitațile de reinginerie a situației existente.
Vom studia utilizarea metodei sintetice pe exmplul elaborării unui regulament administrativ. În
acest caz sunt evidențiate următoarele etape:
1. Stabilirea granițelor sistemului. La acestă etapă în rezultatul analizei fluxurilor de date sunt
identificate entitățile 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. Adăugarea scenariilor de utilizare de sistem. Aici sunt determinate scenariile necesare
pentru realizarea obiectivelor sistemului, diferite de obiectivele utilizatorilor.
4. Construirea diagramei de activități din scenariile de utilizare. Este construit setul de acțiuni
ale sistemului, care conduc la realizarea scenariilor de utilizare.
5. Decompoziția funcțională a diagramelor de activități sub forma diagramelor de context în
metoda IDEF0.
6. Descrierea formală a activităților funcționale separate sub forma regulamentului
administrativ (utilizând diferite notații).
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 modelării, obiectivul și punctul de vedere. Diagramele IDEF0: diagrama de context, diagramele de decompoziție, diagramele arborelui nodurilor, diagramele de expunere (FEO) Activități (Activity). Săgeți (Arrow). Tunelarea săgeților. Numerotarea activităților ș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 posibilitățile
funcționale ale mijloacelor instrumentale de modelare structurală a proceselor business pe
exemplul mediului instrumental BPwin.
BPwin susține trei metodologii de modelare: modelarea funcțională (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 înțeleasă. La lansarea BPwin este
afișat panoul principal al instrumentelor, palitra instrumentelor (forma căreia depinde de notația
selectată) și, în partea stângă, 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 căruia trebuie de indicat dacă va fi
creat un model absolut nou sau modelul va fi deschis dintr-un fișier sau depozitul ModelMart. Va fi
introdus numele modelului și aleasă metodologia în care va fi construit modelul (fig. 7.2).
Cum a fost menționat mai sus, BPwin susține trei metodologii – IDEF0, IDEF3 și DFD, fiecare
soluționând probleme specifice. În BPwin pot fi construite modele mixte, adică pot fi prezente
instantaneu diagrame IDEF0, IDEF3 și DFD. Componența palitrei instrumentelor se va schimba în
mod automat la trecerea de la o notație la alta.
Fig. 7.2. Dialogul de creare a modelului
Un model BPwin este privit ca un set de activități, fiecare din care operează cu un anumit set de
date. Activitățile sunt prezentate sub formă de dreptughiuri, datele – sub formă de săgeți. Dacă se
acționează butonul din stânga a mouse-ului pe un obiect al modelului va apare meniul de context,
fiecare punct al căruia corespunde editorului unei proprietăți a obiectului.
7.2. Construirea modelului IDEF0
La etapele de debut ale creării SI este necesar să înțelegem cum funcționează organizația, pentru
care va fi implementat sistemul. Conducătorul organizației cunoaște lucrul la nivel general, dar nu
este în stare să intre în detalii pentru fiecare colaborator. Un colaborator știe tot ce este legat de
locul său de lucru, dar poate să nu cunoască ce fac colegii. Din această cauză pentru descrierea
modului de activitate a organizației trebuie construit modelul adecvat domeniului obiectiv și care
va include toate cunoștințele participanților în procesle business ale organizației.
IDEF0 este un limbaj comod de modelare a proceselor business în care sistemul este reprezentat
ca set de activități sau funcții interdependente. Această orientare exclusiv funcțională este
principială – funcțiile sistemului sunt analizate independent de obiectele cu care operează. Aceasta
permite o modelare mai corectă a logicii și interacțiunii proceselor.
Modelarea în IDEF0 începe prin crearea diagramei de context – diagrama celui mai abstract nivel
de descriere a sistemului în totalitate, care include definiția subiectului modelării, obiectivele și
punctul de vedere aspura modelului (viewpoint).
Prin sibiect se înțelege însăși 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 acțiuni externe. O
influiență seminifcativă asupra determinării subiectului sistemului va avea poziția din care este
abordat sistemul și obiectivele modelării – întrebări la care trebuie să dea răspuns modelul
construit. Altfes spus, în debut trebuie de stabilit domeniul modelării. Descrierea domeniului - a
sistemului în totalitate și a componentelor sistemului – reprezintă baza construirii modelului. Chiar
dacă se permite ca în timpul modelării domeniul poate fi corectat, el trebuie identificat din start,
deoarece anume domeniul stabilește direcția modelării. La determinarea domeniului se va ține cont
de lărgimea și adâncimea lui. Lărgimea presupune determinarea granițelor modelului – care vor fi
componentele incluse în sistem și care vor rămâne în afara lui. Adâncimea stabilește nivelul de
detaliere – la care nivel de detaliere a componentelor se va considera modelul finalizat. La
determinarea adâncimii trebuie să se țină cont de limitele de timp – eforturile necesare cresc în
progresie geometrică cu creșterea adâncimii. Odată cu determinarea granițelor sistemului se va
considera că nu vor mai fi introduse obiecte noi în sistemul modelat.
7.2.1. Obiectivul modelării
Obiectivul modelării este identificat din răspunsurile la următoarele întrebări:
Din care cauză acest proces trebuie modelat?
Ce trebuie să afișeze modelul?
Ce poate obține clientul?
Prin punct de vedere înțelegem perspectiva din care a fost studiat sistemul la construirea
modelului. Deși la construirea modelului se iau în considerație părerile diferitor persoane, toți
trebuie să aibă un punct comun referitor la model. Punctul de vedere trebuie să corespundă
obiectivelor și granițelor modelării. De obicei, este ales punctul de vedere al persoanei responsabile
de activitățile de modelare în totalitate.
Modelul IDEF0 presupune existența unui obiectiv formulat clar, a unui subiect unic al modelării ș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 – definiția modelului și descrierea domeniului.
Fig. 7.3. Dialogul de desemnare a proprietăților modelului
În pagina Status al aceluiași dialog poate fi descris statutul modelului (varianta maculator, de
lucru, final, etc.), data creării și a ultimii editări (urmărire automată după data de sistem). În
pagina Source sunt descrise sursele informaționale pentru construirea modelului (de exemplu,
“Chestionarea experților domeniului obiectiv și analiza documentației”). Pagina General servește
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 activităților AS-IS (cum este).
Analiza modelului funcțional permite să se stabilească locurile slabe, să se determine în ce va
consta avantajele noilor procese business și cât de adânci vor fi modificările propuse. Detalizarea
proceselor business permite identificarea neajunsurilor organizației chiar acolo unde la prima
vedere funcționalitatea 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 proiectării SI presupune mai întâi crearea modelului AS-IS, analiza lui și perfecționarea
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 inițială la cea finală nu este evidentă. În aceste cazuri este necesar un model
intermediar, care va descrie prpocesul trecerii de la starea inițială la cea finală, iar această trecere
este la fel un proces business.
Rezultatele descrierii modelului pot fi obținute î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 câmpurile necesare, în acest timp în mod automat va fi
afișată ordinea de extragere a informațiilor în raport (fig. 7.4).
Fig. 7.4. Fereastra de dialog pentru formarea raportului
În figura 7.5 este prezentat un raport, creat conform câmpurilor bifate în figura 7.4.
Fig. 7.5. Afișarea prealabilă a raportului
Baza metodologiei IDEF0 este limbajul grafic de descriere a proceselor business. În noația 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 decompoziție;
diagramele arborelui nodurilor;
diagramele pentru expoziție (FEO).
Diagrama de context este rădăcina structurii arborescente a diagramelor și prezintă descrierea
generală a sistemului și interacțiunea lui cu mediul extern. După descrierea la nivel general are loc
împărțirea sistemului în fragmente mari. Acest proces se numește decompoziție funcțională, iar
diagramele, care descriu fiecare fragment și interacțiunea fragmentelor, se numesc diagrame ale
decompoziției. După decompoziția diagramei de context are loc decompoziția fiecărui fragment
mare în fragmente mai mici și tot așa mai departe, pănă la atingerea nivelului necesar de
concretizare a descrierii. După fiecare ciclu de decompoziție au loc sesiuni de expertizare – experții
domeniului obiectiv identifică corespondența proceselor business reale cu diagramele create.
Abaterile depistate sunt corectate și doar la momentul lipsei observațiilor se va trece la următorul
ciclu de decompoziție. Astfel este realizată corespondența dintre model și procesele business reale
la fiecare nivel al modelului. Sintaxa descrierii sistemului în totalitate și a fiecărui fragment este
aceeași pentru întreg modelul.
Diagrama arborelui nodurilor inică dependența ierarhică a activităților, însă nu interdependența lor.
Astfel de diagrame într-un model pot fi oricât de multe, deoarece arborele poate fi construit la
orice adâncime și nu obligator însepând cu rădăcina.
Diagramele pentru expoziție (FEO) sunt construite pentru a ilustra fragmente separate ale
modelului, puncte de vedere alternative sau în scopuri speciale.
Activitățile (Activity) semnifică procese, funcții sau lucrări nominalizate, care au loc într-un
anumit interval de timp și produc rezultate descifrabile. Activitățile sunt notate prin dreptunghiuri.
Toate activitățile trebuie să fie denumite și definite. Numele unei activități este o combinație de
cuvinte, care semnifică acțiune (de exemplu, “Funcționare companie”, “Recepție comenzi”
ș.a.m.d.). Activitatea cu denumirea “Funcționare companie” poate avea, de exemplu, următoarea
definiție: “Acest model este un model de studiu, care descrie cum funcționează compania”. La
crearea modelului nou (opțiunea 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 activității se va acționa butonul din dreapta a mouse-ului, se va alege
opțiunea de meniu Name Editor și în fereastra de dialog se va introduce numele actvității. Pentru
descrierea altor proprietăți ale activității servește dialogul Activity Properties (fig. 7.7).
Fig. 7.7. Editorul proprietăților unei activități
Diagramele de decompoziție conțin activități care se află în relație de paternitate cu activitatea
descompusă, adică sunt activități-fiice (au o activitate părinte comună). Pentru crearea diagramei
de decompoziție se va acționa butonul din panoul de instrumente.Va fi afișată fereastra de
dialog Activity Box Count (fig. 7.8) în care trebuie de indicat notația diagramei noi și numărul de
activități din această diagramă.
Fig. 7.8. Fereastra de dialogActivity Box Count
Alegem aici notația IDEF0 și acționăm OK. Apare diagrama de decompoziție (fig. 7.9). Intervalul
permis de activități este de la 2 la 8. Nu are sens să descompunem o activitate într-o singură
activitate. Diagramele mai mult de 8 activități sunt suprasaturate și dificil de citit. Pentru claritate
și o înțelegere mai bună a proceselor modelate se recomandă să utilizăm de la 3 la 6 blocuri într-o
diagramă.
Fig. 7.9. Exemplu de diagramă de decompoziție
Dacă numărul activităților este insuficient, este posibilă adăugarea unei activități într-o diagramă,
prin clik pe butonul palitrei instrumentelor, apoi într-un loc liber pe diagramă.
Activitățile într-o diagramă de decompoziție sunt plasate pe diagonale stânga-sus dreapta-jos.
Această ordine se numește ordine de dominare. Conform acestui principiu de plasare, în colțul
stânga-sus este plasată cea mai importantă activitate sau activitatea executată prima în timp.
Relația este recursivă pentru celelate activități. Această plasare facilitează citirea diagramelor, plus
că pe o astfel de plasare este bazată noțiunea de interdependență a activităților (v. mai jos).
Fiecare activitate din diagrama de decompoziție poate fi la rândul său descompusă. Pe diagrama de
decompoziție activitățile sunt numerotate în mod automat de la stânga la dreapta. Numărul
activității este afișat în colțul dreapta-jos. În colțul stânga-sus este afișată 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.
Săgețile (Arrow) descriu interacțiunile activităților și reprezintă anumite informații, exprimate prin
substantive (de exemplu, “Reguli și proceduri”, “Sistem contabil", “Adresări telefonice”).
7.2.3. Tipuri de săgeți
În IDEF0 există 5 tipuri de săgeți:
Intrare (Input) – material sau informație, care sunt utilizate sau transformate de activitate în
scopul obținerii unui rezultat (ieșire). Activitateai poate să nu aibă nici o săgeată de intrare. Fiecare
tip de săgeată este asociat unei laturi deteminate a dreptunghiului activitate (intră sau iese).
Săgeata intrare este desenată intrând în latura din stânga a activității. La descrierea proceselor
tehnologice (pentru ele a fost gândit IDEF0) nu apar probleme legate de determinare intrărilor.
Într-adevăr, “Adresări telefonice” este ceva prelucrat de procesul "Деятельность компании".
pentru obținerea rezultatului. Însă în cazul în care săgețile nu sunt obiecte fizice, ci date, nu este
totul atât de evident. De exemplu, pentru activitatea “Primirea pacientului” cartela pacientului
poate fi atât la iintrare, cât și la ieșire, iar calitatea acestor date nu se modifică. Cu alte cuvinte, în
exemplul nostru, pentru ca săgețile să îndreptățească destinația, trebuie să fie exact definite, adică
să indice (pentru ieșiri) că datele întra-adevăr au fost prelucrate (“Cartela completată a
pacientului”). Frecvent este dificil de stabilit dacă datele sunt intrări sau controluri. În acest caz
poate fi utilă informația dacă datele sunt sau nu prelucrate/modificate de activitate. Dacă da,
atunci este mai probabil că avem intrări, în caz contrar- control.
Control – reguli, strategii, proceduri sau standarde, cu respectarea cărora are loc activitatea.
Fiecare activitate trebuie să posede minimum a săgetă control. Săgeata control este desenată
intrând în latuare orizontală de sus a dreptunghiului activității. În figura 7.6 săgeata "Правила и
процедуры" este control pentru "Деятельность компании". Controlul influiențează activitatea dar
nu este transformat de ea. Dacă scopul sctivității este de a modifica o procedură sau o strategie,
atunci o astfel de procedură sau strategie va fi pentru activitate intrare. În cazul apariției unor
incertitudini legate de statutul săgeții (control sau intrare) se recomandă să fie desenată săgeata
control.
Ieșire (Output) – material sau informație, produse de activitate. Orice activitate trebuie să
posede cel puțin o săgeată ieșire. O activitate fără rezultat nu are sens și nu trebuie modelată.
Săgeata ieșire este desenată ieșind din latura verticală dreapta a activității. În figura 7.6 săgețile
"Маркетинговые материалы" și "Проданные продукты" sunt ieșiri pentru activitatea
"Деятельность компании".
Mecanism (Mechanism) — resursele, care îndeplinesc activitatea, de exemplu personalul
întreprinderii, mașinile unelte, dispozitivele etc. Săgeata mecanism este desenată intrând în latura
orizontală de jos a activității. În figura 7.6 săgeata "Бухгалтерская система" este mecanism
pentru activitatea "Деятельность компании". Analistul de sistem poate să nu includă săgețile
mecanism în model.
Apel (Call) – săgeată specială, care face referire la alt model al activității. Săgeata apel este
desenată ieșind din latura orizontală de jos a activității. În figura 7.10 săgeata "Другая модель
работы" este apel pentru activitatea "Изготовление изделия". Săgeata apel este utilizată pentru a
indica, că activitate oarecare este îndeplinită în afara sistemului modelat. ÎN BPwin săgețile apel
sunt utilizate în mecanismul de agragare sau dezagregare a modelelor.
Fig. 7.10. Săgeata apel, care apare la dezagregarea modelului
Săgeți de graniță. Într-o diagramă de context săgețile sunt utilizate pentru descrierea
interacțiunii sistemului cu mediul înconjurător. Ele pot începe la granița diagramei și pot să se
termine la activitate sau invers. Aceste săgeți se numesc de graniță. Pentru introducerea unei
săgeți de graniță intrare se va proceda după cum urmează:
se va acționa butonul cu simbolul ,
în palitra de instrumente cursorul va fi deplasat spre partea stângă a ecranului până va
apărea începutul unei liniuțe de hașurare;
se va face clik simplu pe această liniuță (de unde iese săgeata) și încă unul în partea stânga
a activității din partea intrării (unde se va termina săgeata);
ne întoarcem în palitra instrumentelor și alegem opțiunea editare săgeată
cu butonul din dreapta a mouse-ului facem clik pe linia săgeții, în meniul pop-up alegem
Name și adăugăm numele săgeții în pagina Name a dialogului IDEF0 Arrow Properties.
Săgețile control, intrare, mecanism și ieșire sunt introduse în mod analogic. Numele săgeților 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 decompoziție este destinată detalizării activității. Spre deosebire de modelele, care
reflectă structura organizației, activitatea într-o diagramă de nivel siperior în IDEF0 nu este un
element de control cu activitățile de la nivele mai joase. Activitățile de la nivele mai joase
reprezintă aceleași momente ca și activitățile de nivel înalt, dar cu un grad mai mare de detaliere.
În rezultat, granițele unei activități de nivel superior reprezintă același lucru ca și granițele
diagramei de decompoziție. ICOM (abrevierea de la Input, Control, Output și Mechanism) sunt
codurile destinate identificării săgeților de graniță. Un cod ICOM conține prefixul, care corespunde
tipului săgeții (I, C, O sau M) și numărul de ordine.
BPwin introduce codurile în mod automat. Pentru afișarea codurilor ICOM trebuie actualizată
opțiunea ICOM codes a paginii Display a ferestrei de dialog Model Properties (meniul Model/Model
Properties, fig. 7.12).
Dicționarul săgeților este editat folosind editorul special Arrow Dictionary Editor, în care are loc
identificarea săgeții și este introdus comentariul asociat ei (fig. 7.13). Dicționarul săgeților rezolvă
o problemă foarte importantă. Analistul creează diagrame pentru a desfășura 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
conștientizate în mod diferit de experți diferiți. În același timp analistul – autorul diagramelor este
obligat să utilizeze cele mai pe înțelesul experților expresii. Deoarece definițiile formale adesea
sunt complicate pentru acceptate, analistul este nevoit să utilizeze în diagrame argoul profesional,
iar pentru excluderea unor posibile tratări neunivoce, în dicționarul săgeților fiecare noțiune poate
fi definită extins, la necesitate – formal.
Fig. 7.12. Activarea opțiunii ICOM codes pe pagina Display
Fig. 7.13. Editarea dicționarului săgeților
Conținutul dicționarului săgeților poate fi imprimat sub formă de raport (meniul Tools/ Report
/Arrow Report...), vom obține în acest caz dicționarul explicativ al termenilor domeniului obiectiv,
utilizați în model.
7.2.5. Săgețile libere și legate
Săgețile de graniță nelegate (libere) (unconnected border arrow). La decompoziția activității
săgețile, care intră ți care ies (cu excepția săgeții apel) apr in mod automat pe diagrama de
decompoziție (migrarea săgeților), dar nu ating activitățile. Aceste săgeți se numesc
nelegate și sunt tratate de BPwin ca eroare sintactică.
În figura 7.14 este prezentat un fragment a diagramei de decompoziție cu săgeți nelegate,
generate de BPwin la decompoziția activității "Сборка настольных компьютеров" (fig. 7.9).
Pentru legarea săgeților de intrare, control sau mecanism trebuie de trecut în regimul de editare a
săgeților, se face clik pe partea terminală a săgeții apoi pe segmentul respectiv al activității. Pentru
legarea săgeții de ieșire trebuie de trecut în regimul de editare a săgeților, se face clik pe
segmentul de ieșire al activității apoi pe săgeată
Fig. 7.14. Exemplu de săgeți nelegate
Săgeți interne. Pentru legarea reciprocă a activităților sunt utilizate săgeți interne, adică săgeți,
care nu ating granițele diaggramei, pornind de la activitate și terminându-se la alta.
Pentru desenarea unei săgeți interne în regim de editare a săgeților se va face clik pe segmentul
(de exemplu, ieșirea) unei activități apoi pe segmentul (de exemplu, intrarea) altei activități. În
IDEF0 există cinci tipuri de legături pentru lucrări.
Legare de intrare (output-input), când săgeata de ieșire a unei activități superioare (în
continuare simplu, ieșire) este direcționată spre intrarea unei activități inferioare (de exemplu, în
fig. 7.15 săgeata "Собранные компьютеры" leagă activitățile "Сборка и тестирование
компьютеров" și "Отгрузка и получение").
Fig. 7.15. Legarea de intrare
Legare de control (output-control), când ieșirea unei activități superioare este direcționată
către controlul unei activități inferioare. Legarea de control indică dominarea activității superioare.
Datele sau obiectele de la ieșirea activității superioare nu pot fi modificate în cadrul unei astfel de
activități inferioare. În figura 7.16 săgeata "Заказы клиентов" leagă activitățile "Продажи и
маркетинг" și "Сборка и тестирование компьютеров".
Fig. 7.16. Legarea de control
Conexiune inversă la intrare (output-input feedback), când ieșirea unei activități inferioare
este aplicată la intrarea unei activități superioare. Această legătură, de obicei, este utilizată pentru
descrierea ciclurilor. În figura 7.17 săgeata "Результаты тестирования" leagă activitățile
"Тестирование компьютеров" și "Отслеживание расписания и управление сборкой и
тестированием".
Fig. 7.17. Conexiune inversă la intrare
Conexiune inversă la control (output-control feedback), când ieșirea unei activități inferioare
este aplicată la controlul unei activități superioare (săgeata "Результаты сборки и тестирования",
fig. 7.18). Conexiunea inversă la control adesea subliniază efecacitatea procesului business. În
figura 7.18 volumul vânzărilor poate fi sporit prin raglarea directă a proceselor de asamblare și
testare a calculatoarelor (ieșirea activității "Сборки и тестирование компьютеров").
Fig. 7.18. Conexiunea inversă la control
Legătura ieșire-mecaninsm (output-mechanism), când ieșirea unei activități este aplicată la
mecanismul altei activități. Această legătură este utilizată mai rar și semnifică faptul, că o
activitate pregătește resurse, necesare pentru derularea altei activități (fig. 7.19).
Fig. 7.19. Legătura ieșire-mecanism
Săgeți evidente. O săgetă evidentă are drept sursă o singură (și numai una) activitate și
destinație de asemenea o singură (și numai una) activitate.
Săgeți de ramificare și de adunare. Unele și aceleași date sau obiecte, generate de o singură
activitate, pot fi utilizate instantaneu în alte câteva activități. Pe de altă parte, săgețile generate de
activități diferite, pot reprezenta aceleași (sau omogene) date sau obiecte, care mai apoi sunt
utilizate sau prelucrate în același loc. Pentru modelarea acestor situații sunt utilizate săgeți de
ramificare și săgeți de adunare. Pentru a ramifica o săgeată în regim de editare a săgeții se face
clik pe fragmentul săgeții și pe segmentul respectiv al activității. Pentru adunarea a două săgeți de
ieșire în regim de editare a săgeții se face mai întâi clik pe segmentul ieșirii activității, apoi pe
fragmentul respectiv al săgeții.
Sensul săgeților de ramificare și de adunare se transmite prin atribuirea unui nume pentru fiecare
ramură de săgeată. Există anumite reguli de atribuire a numelor. Ca exemplu vom lua săgețile de
ramificare. Dacă săgeata a fost numită până la ramificare, iar după ramificare nici una din ramuri
nu a fost denumită, se consideră că fiecare ramură modelează aceleași date sau obiecte, ca și până
la ramificare (fig. 7.20).
Fig. 7.20. Exemplu de atribuire a numelui pentru săgeți ramificate
Dacă săgeată avea denumire până 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 rămas fără nume, se consideră că ea modelează aceleași date sau obiecte, ca și ramura
până la ramificare (fig. 7.21).
Fig. 7.21. Exemplu de denumire a săgeții ramificate
Nu este admisă situația în care săgeata nu este denumită pînă la ramificare, iar după ramificare
una din ramuri este fără nume. BPwin determină astfel de săgeți ca eroare sintactică.
Regulile de atribuire a numelor săgeților de adunare sunt analogice – eroare va fi considerată
săgeata care după adunare nu are nume, iar până la adunare nu avea nume una din ramuri.
Pentru denumirea unei ramuri separate a săgeților 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 săgeții.
Acest nume va corespunde doar săgeții selectate.
7.2.6. Tunelarea săgeților
Săgețile de graniță noi, introduse într-o diagramă de decompoziție de nivel inferior sunt
reprezentate în paranteze pătrate și nu vor apare în mod automat în diagramele de nivel mai înalt
(fig. 7.22).
Fig. 7.22. Săgeată nerezolvată (unresolved)
Pentru “ridicarea” lor se va face clik dreapta pe parantezele pătrate ale săgeții de graniță și în
meniul de context se va selecta opțiunea Arrow Tunnel (fig. 7.23).
Fig. 7.23. Alegerea opțiunii din meniul de context
Fig. 7.24. Fereastra de dialog Border Arrow Editor
Va fi afișată fereastra de dialog Border Arrow Editor (fig. 7.24). Dacă acționăm butonul Resolve
Border Arrow, săgeata va migra pe diagrama de nivel superior, iar dacă butonul Change To Tunnel
– săgeată va fi tunelată și nu va ajunge pe altă diagramă. O săgeată tunelată este reprezentată cu
paranteze rotunde la capăt (fig. 7.25)
Fig. 7.25. Tipuri de tunelare a săgeților
Tunelarea este utilizată pentru afișarea săgeților puțin importante. Dacă într-o diagramă de nivel
inferior trebuie reprezentate date sau obiecte puțin importante, care nu sunt prelucrate sau nu
sunt utilizate de activități la nivelul curent, ele trebuie expediate la nivelul superior (la diagrama
părinte). Dacă aceste date nu sunt utilizate nici în diagrama părinte, atunci vor fi expediate mai
sus ș.a.m.d. În rezultat, o săgeată puțin importantă va fi prezentă la toate nivelele și va complica
citirea tutror diagramelor. Ieșirea constă în tunelarea acestei săgeți la cel mai inferior nivel.
Această tunelare se numește “nu-în-diagrama-părinte”.
Un alt exemplu de tunelare poate fi situația în care o săgeată de tip mecanism migrează de la
nivelul superior la nivelul inferior, și la nivelul inferior acest mecanism este utilizat în același mod
pentru toate activitățile fără excepție. (Se presupune, că bu trebuie de detalizat săgeata
mecanismului, adică săgeata mecanismului pe activitatea-fiică a fost denumită până la ramificare,
iar după ramificare remurile nu au nume proprii). În acest caz săgeata mecanismului la nivelul
inferior poate fi eliminată, după ce în daigrama părinte ea poate fi tunelată, iar în comentariul
săgeții sau în dicționar putem indica, că mecanismul va fi utilizat în toate activitățile diagramei-fiice
de decompoziție. Această tunelare se numește “nu-în-activitatea-fiică” (fig. 7.25).
7.2.7. Numerotarea activităților și diagramelor
Toate activitățile sunt numerotate. Numărul constă din prefix și un număr. Pot fi utilizate prefixe de
lungime arbitrară, dar de obicei este utilizat prefixul A. Diagrama de context (rădăcină) are
numărul A0. Аctivitățile decompoziției diagramei A0 au numărul A1, A2, A3 ș.a.m.d. Activitățile
decompoziției unui nivel inferior au numărul activității părinte și numărul de ordine ordinar, de
exemplu decompozițiile lui A3 vor ave numerele A31, A32, A33 ș.a.m.d. Activitățile formează o
ierarhie în care fiecare activitate poate avea o activitate părinte și câteva activități fiice, formând
un arbore. Acest arbore se numește arborele nodurilor, iar numerotarea de mai sus – numerotare
pe noduri. Diagramele IDEF0 au o numerotare dublă. Mai întâi, diagramele au număr conform
nodului. Diagrama de context are întotdeauna numărul A-0, decompoziția diagramei de context –
numărul A0, restul diagramelor decompoziției – numere conform nodului (de exemplu, A1, A2,
A21, A213 etc.). BPwin susține modul automat de numerotare pe noduri. În rezultatul expertizelor
diagramele por fi precizate și modificate, adică pot exista deiferite versiuni ale unei diagrame de
decompoziție (din punctul de vedere al plasării în arborele nodurilor). BPwin permite existența în
model a unei singure diagrame de decompoziție în nodul dat. Versiunile precedente pot fi păstrate
sub formă de copii pe hârtie sau ca diagrame FEO. (Din păcate, la crearea diagramellor FEO
lipsește posibilitatea roll-back, adică dintr-o diagramă poate fi obținută decompoziția FEO, dar
invers – nu). În orice caz, trebuie să putem diferenția diferite versiuni ale aceleeași diagrame.
Pentru aceasta există un număr special – C-number, care trebuie atribuit modelului în mod
manual. C-number este o linie de simboluri oarecare, dar se recomandă respectarea standardului
în care numărul constă dintr-un prefix (simboluri, inițialele autorului diagramei) și numărul de
ordine (va fi urmărit în mod manual, de exemplu, BV00048).
7.2.8. Diagramele arborelui nodurilor și FEO
Diagramele arborelui nodurilor reprezintă ierarhia atcivităților modelului și oferă o vedere
asupra intregului model, dar nu conține legăturile reciproce între activități (fig. 7.26) Procesul
creării modelului activităților este iterativ, ca rezultat activitățile pot fi deplasate în cadul arborelui
nodurilor. Pentru claritate și pentru a verifica corectitudinea decompoziției 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 afișarea ierarhiei activităților ș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ă opțiunea Diagram/Add Node
Tree (fig. 7.27). Va fi afișată fereastra de dialog pentru formarea diagramei arborelui nodurilor
Node Tree Definition (fig. 7.28, 7.29).
Fig. 7.27. Alegerea opțiunii 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 adâncimea — Number of Levels (valoarea
implicită este 3) și rădăcina arborelui (valoarea implicită este activitatea părinte a diagramei
curente). În mod implicit nivelul de jos al decompoziției este afișat în formă de listă, restul
activităților – în formă de dreptunghiuri. Pentru afișarea întregului arbore în formă de
dreptunghiuri trebuie de eliminat bifa opțiunii Bullet Last Level. Atunci când este creat arborele
nodurilor trebuie de indicat numele diagramei deoarece, dacă în mai multe diagrame va fi utilizată
una și aceeași activitate în calitate de rădăcină tuturor aceste diagrame se va conferi unul și același
număr (numărul nodului + sufixul N, de exemplu A0N) și în lista diagramelor deschise (opțiunea
meniului Window) deosebirea între ele va putea fi făcută 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 susținute de sintaxa
IDEF0. Diagramele FEO permit să fie încălcată 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ă opțiunea meniului Diagram/Add FEO Diagram. Va fi afișată
fereastra de dialog Add New FEO Diagram în care trebuie de indicat numele diagramei FEO și tipul
diagramei părinte (fig. 7.30).
Fig. 7.30. Fereastra de dialog pentru crearea unei diagrame FEO noi
Numărul unei diagrame noi este generat în mod automat (numărul diagramei părinte conform
nodului + sufixul F, de exempplu A1F).
7.2.9. Chenarul diagramei
În figura 7.31 este prezentat un exemplu tipic de diagramă de decompoziție 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 urmărirea (referirea) diagramei în procesul de modelare. Partea de jos este
utilizată pentru identificare și poziționare în ierarhia diagramei.
Sensul elementelor chenarului este prezentat în tabelele 7.1 și 7.2.
Tabelul 7.1. Câmpurile titlului chenarului (de la stânga la dreapta)
Câmp Sens
Used At Este utilizat pentru a indica activitatea părinte, dacă în diagrama curentă se făcea referință prin utilizarea săgeții apel
Autor, Date, Rev, Project
Numele autorului diagramei, data creării și numele proiectului, îb cadrul căruia a fost creată diagrama. REV – data ultimei revizuiri a diagramei
Notes 123456789 10
Este utilizat pentru sesiunile de expertizare. Expertul va indica (pe copia pe hârtie a diagramei) numărul de observații, tăind cifra din listă de fiecare dată când introduce o observație nouă
Status Statutul reflectă etapa creării diagramei, conform etapelor de publicare
Working Diagramă nouă, diagramă înoită cardinal sau autor nou al diagramei
Draft Diagrama a trecut expertizarea primară și este gata pentru discuții ulterioare
Recommended Diagrama și toate documentele asociate au trecut expertiza. Modificări noi nu sunt așteptate
Publication Diagrama este gata pentru imprimarea finală și publicare
Reader Numele cititorului (expertului)
Date Data citirii (expertizei)
Context Schema plasării activităților în diagrama de nivel superior. Activitatea părinte este prezentată printr-un dreptunghi înnegrit, restul – de culoare deschisă. Pe diagrama de context (A-0) va fi prezentă inscripția TOP. În colțul stânga jos este indicat numărul (conform nodului) al diagramei părinte:
Tabelul 7.2. Câmpurile subsolului chenarului (de la dreapta la stânga)
Câmp Sens
Node Numărul nodului diagramei (numărul activității părinte)
Title Numele diagramei. Implicit — numele activității părinte
Number C-Number, număr unic al versiunii diagramei
Page Numărul paginii, poate fi utilizat ca număr de pagină la formarea mapei
Fig. 7.31. Exemplu diagramă de decompoziție cu chenar
Valorile câmpurilor 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 despărțirea modelelor
Posibilitatea reunirii și despărțirii modelelor permite lucrul colectiv în proiect. Managerul proiectului
poate construi decompoziția nivelului superior și solicita analiștii să continue descompunerea
fiecărei ramuri al arborelui în formă de modele separate. După finalizarea activităților 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, pentru
perfecționare sau arhivare.
Pentru reunirea și despărțirea modelelor în BPwin sunt utilizate săgețile apel. Pentru reunire este
necesar să fie îndeplinite următoarele condiții:
Ambele modele reunite trebuie să fie deschise în BPwin.
Numele modelului-sursă, reunit cu modelul-scop, trebuie să coiincidă cu numele săgeții de
apelare a activității în modelul-scop.
Săgeata apel trebuie să plece dintr-o activitate nedescompusă (activitatea trebuie să
posede o liniuță diagonală în colțul stânga sus, fig. 7.33).
Numele activității de context a modelului-sursă reunit și a activității din modelul-scop, la
care reunim modelul-sursă, trebuie să coiincidă.
Modelul-sursă trebuie să aibă minimum o diagramă de decompoziție.
Fig. 7.33. Săgeata de apelare a activității "Сборка и тестирование компьютеров" a
modelului-scop
Pentru reunirea modelelor se va face clik dreapta cu mouse-ul pe activitatea cu săgeata apel în
modelul-scop și în meniul pop-up se va selecta opțiunea Merge Model.
Este afișată o fereastră de dialog în care se va indica opțiunea de reunire a modelului (fig. 7.34).
La reunirea modelelor se vor reuni și dicționarele săgeților și activităților. În cazul în care definițiile
coiincid este posibilă rescrierea lor sau acceptarea definițiilor din modelul-sursă. Același lucru este
valabil și pentru numele săgeților, depozitele de date și referințele externe. Depozitele de date și
referințele 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 adăugat modelului-scop, săgeata apel
dispare, iar activitatea de la care pleca săgeata apel, devine decompozabilă – la aceasta se va
reuni diagrama de decompoziție a primului nivel al modelului-sursă. Săgețile, asociate activității
din diagrama modelului-scop nu migrează în mod automat în decompoziție, ci vor fi reflectate ca
nerezolvabile. Ele trebuie tunelate manual.
În procesul de reunire modelul-sursă rămâne 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, schimbările introduse nu vor nimeri automat în ramura respectivă a
modelului-scop.
Despărțirea modelelor are loc în mod analogic. Pentru despărțirea unei ramuri de la model se va
face clik dreapta cu mouse-ul pe activitatea descompusă (activitatea nu are liniuță diagonală de
hașurare în colțul stânga sus) și în meniul pop-up se va selecta opțiunea Split Model. În fereastra
de dialog afișată Split Options se va indica numele modelului creat. După confirmarea despărțirii
modelului în modelul vechi activitatea respectivă va deveni nedescompusă (liniuța diagonală în
colțul stânga sus), va fi creată săgeata apel, numele ei va coiincide cu numele modelului nou, și, în
final va fi creat modelul nou în care numele activității de context va coiincide cu numele activității
de la care a fost “ruptă” decompoziția.
7.4. Crearea rapoartelor în BPwin
BPwin posedă un instrument puternic de generare a rapoartelor. Rapoartele pentru un model
concret sunt apelate din opțiunea Report a meniului. Există 7 tipuri de rapoarte:
1. Model Report. Include informații despre contextul modelului – numele modelului, punctul de
veder, domeniul, scopul, numele autorului,data creării ș.a.
2. Diagram Report. Raport pentru o diagramă concretă. Include lista obiectelor (activități,
săgeți, depozite de date, referințe externe ș.a.).
3. Diagram Object Report. Cel mai complet raport al modelului. Poate include lista completă a
obiectelor modelului (activități, săgeți cu indicarea tipului lor etc.) și proprietățile definite de
utilizator.
4. Activity Cost Report. Raport cu rezultatele analizei costurilor. Va fi studiat mai jos.
5. Arrow Report. Raport despre săgeți. Poate include informații din dicționarul săgeților,
activitatea-sursă, activitatea-destinație a săgeții în informații privind reunirea și despărțirea
săgeților.
6. Data Usage Report. Raport despre rezultatele legării modelului proceselor și modelului
datelor (mai jos).
7. Model Consistency Report. Raport, care include lista erorilor sintactice ale modelului
