Mihai Dascălu

Integrarea informaţiilor la nivelul sistemului este procesul de integrare şi transformare a datelor şi a conţinutului pentru a livra informaţii autoritare, consistente, actualizate şi complete. Gradul de integrare al sub-sistemelor determină calitatea soluţiei informatice pe tot parcursul ciclului său de viaţă.

Printre aspectele fundamentale ale integrării se numără:

1. Conectare la informaţii - întrucât acestea sunt distribuite în mai multe baze de date apar probleme de acces propriu-zis, sincronizare şi consistenţă la nivelul tuturor surselor disponibile;
2. Înţelegerea şi asimilarea informaţiilor într-un grad cât mai mare automatizat după integrarea diverselor surse în vederea analizei ulterioare a acestora;
3. Curăţirea informaţiilor - îmbunătăţirea calităţii datelor de pentru a identifica, corecta, standardiza şi reconcilia date inexacte sau redundante;
4. Transformarea informaţiilor - prelucrările aferente datelor în vederea obţinerii de informaţii de orice complexitate, din orice şi oricâte surse, după un format prestabilit şi la momentul potrivit;
5. Livrarea informaţiilor – accesul la informaţii şi integrarea acestora din diversele surse de date şi conţinut pentru a oferi o interfaţă unitară utilizatorului din perspectiva căruia multitudinea de surse este percepută ca o singură resursă;
6. Replicarea datelor în vederea siguranţei acestora (backup) şi a sporirii vitezei de obţinere a informaţiilor necesare prin posibilitatea accesării concomitente a mai multor surse de informaţii. Astfel este minimizată şi perioada de nefuncţionare („downtime”) a sistemului, precum şi încărcarea cât mai echilibrată a echipamentelor disponibile în cadrul infrastructurii.

Prin integrarea mai multor soluţii existente trebuie asigurate în continuare funcţionalităţile la nivelul fiecărui sub-sistem în parte, precum şi la nivelul întregului sistem care agregă toate serviciile. De asemenea poate apărea necesitatea migrării anumitor aplicaţii datorită incompatibilităţilor care pot apărea sau din necesitatea de a mapa cât mai eficient infrastructura hardware existent pe noul sistem software.

Astfel trei caracteristici care trebuie urmărite în urma integrării în cadrul unei soluţii informatice a unor sisteme deja existente, eventual de la furnizori diferiţi şi/sau bazate pe tehnologii diferite:

1. Compatibilitatea între diversele sisteme şi între sursele de informaţii aferente
2. Interoperabilitatea în vederea asigurării unei perspective holistice asupra sistemului obţinut în urma integrării diverselor aplicaţii.
3. Extensibilitatea în vederea adăugării de noi funcţionalităţi şi module.

Integrarea se poate realiza şi prin intermediul unui nou sub-sistem la nivelul căruia să fie definiţi adaptori care să preia informaţiile din diverse surse, să realizeze prelucrarea acestora în vederea prezentării rezultatelor utilizatorilor sau în vederea interschimbului de date între sisteme.

În cadrul procesului de proiectare a unei astfel de soluţii, se pot lua în considerare 2 arhitecturi pe baza cărora să se realizeze facil integrarea ulterioară facilă de noi funcţionalităţi/aplicaţii. Abordările recomandate pentru proiectare sunt ascendentă, respectiv hibridă, deoarece se pleacă de la gruparea funcţionalităţilor fiecărui subsistem, şi, iterativ, se obţin serviciile agregate.

Arhitectura pe 3 nivele („three-tier architecture”)

Arhitectura pe 3 nivele este o arhitectură client-server în care interfaţa cu utilizatorul, logica de procesare ("business intelligence") şi stocarea, respectiv accesul la date şi de acces la date sunt dezvoltate şi întreţinute ca module independente, separate de cele mai multe ori pe platforme.

În afară de avantajele unui soluţii informatice modulare, arhitectura de faţă permite modernizarea sau înlocuirea oricărui nivel independent, în funcţie de cerinţe sau de evoluţia tehnologică.

Nivelurile specifice ale unei astfel de arhitecturi sunt:

1. Nivelul prezentare este cel mai ridicat nivel al aplicaţiei care se ocupă de afişarea informaţiilor, schimbarea datelor/rezultatelor cu nivelul inferior şi este reprezentat de interfaţa vizualizată prin intermediul unui browser Internet de către client în cazul unui sistem web-based
2. Nivelul aplicativ („Business Logic”) se ocupă de funcţionalităţile aplicaţiei prin efectuarea de prelucrări complexe asupra informaţiilor;
3. Nivelul de date constă din serverele de baze de date la nivelul cărora sunt stocate şi extrase informaţiile. Acest nivel păstrează datele neutru şi independent faţă de procesele de logică ale sistemului. De asemenea, prin separarea datelor la nivelul unui strat separat se asigură îmbunătăţirea scalabilităţii şi a performanţelor globale.

La prima vedere, arhitectura pe 3 nivele poate părea similară din punct de vedere conceptual cu MVC („Model View Controller”), deşi din punct de vedere topologic acestea sunt complet diferite.

O regulă fundamentală în arhitectura pe 3 nivele este că nu există comunicaţie directă între nivelul clientului şi nivelul de date – transferul informaţiilor se realizează obligatoriu prin intermediul nivelului aplicativ. Astfel, conceptual, arhitectura pe 3 nivele este una liniară.

Pe de altă parte, arhitectura MVC este triunghiulară: View trimite modificările la Controller, acesta le transmite la nivelul Modelului, dar actualizările sunt transmise la View direct, fără a mai trece din nou prin Controller.

SOA („Service Oriented Architecture”)

Al doilea model orientat pe agregarea şi integrare serviciilor este SOA care permite construirea de aplicaţii bazate pe servicii software. În contextul arhitecturii SOA, serviciile sunt grupate în unităţi slab legate după funcţionalităţi între care nu există apeluri reciproce. Fiecare serviciu implementează câte o acţiune, iar comunicarea între servicii se realizează prin protocoale definite.

O modalitate de publicare a serviciilor către exterior este prin intermediul serviciilor web care pot fi foarte utile în cazul aplicaţiilor web. Este recomandat ca serviciile WEB să fie expuse prin intermediul standardului WSDL, care prezintă contractul şi schema de realizare, şi nu clasele sau implementările acestora.

Pe lângă existenţa serviciilor, SOA presupune existenţa unei interfeţe cu utilizatorul, a unui repozitoriu de servicii disponibile şi a unui modul care să permită comunicarea între diversele servicii (Service Bus). Un serviciu include pe lângă partea de implementare propriu-zisă (date şi procesele de business – business logic) şi o interfaţă prin intermediul căreia sunt apelate funcţionalităţile modului.

Astfel arhitectura SOA unifică procesele de afaceri prin structurarea aplicaţiilor mari drept o colecţie de module mai mici, numite „servicii".

Avantajele arhitecturii SOA:

Interoperabilitatea intrinsecă între diferite sisteme şi limbaje de programare reprezintă baza pentru integrarea de diverse aplicaţii printr-un protocol de comunicare;

Agregarea datelor şi a serviciilor/funcţionalităţilor în scopul realizării şi întreţinerii fluxurilor de date între toate sistemele/aplicaţiile din cadrul soluţiei integrate.

Principiile arhitecturii SOA definesc atât reguli pentru proiectare, cât caracteristicile specifice unei astfel de arhitecturi:

• Abstractizarea, întrucât serviciile ascund logica de procesare şi sunt prezentate doar la nivel de interfeţe;
• Descoperirea serviciilor se realizează prin mecanisme facile, de exemplu prin intermediul unui repozitoriu de servicii;
• Cuplarea slabă între module şi encapsularea serviciilor, de exemplu prin servicii web;
• Granularitate fină până la un nivel relevant din perspectiva utilizatorului, modularitate şi interoperabilitate;
• Conformarea cu anumite standarde în vederea asigurării schimbului de informaţii între diverse servicii:
• Identificarea, categorisirea, livrarea şi monitorizarea serviciilor existente.

Performanţa soluţiei informatice

În vederea evaluării performanţelor unei soluţii informatice încă din momentul proiectării acesteia vor fi luate în considerare metrici specifice precum:

• Metrici şi reguli pentru soluţiile software proiectate folosind paradigma de programare orientată obiect printre care se numără: dimensiunea medie a unei metode, numărul mediu de metode/clasa, nivelul clasei in ierarhia de clase, numărul de relaţii subsistem/ subsistem, respectiv clasa/ clasa în fiecare subsistem;
• Complexitatea grafului fluxului de control al proceselor descrise în cadrul soluţiei informatice care indică gradul de dificultate al procesului de testare al modulelor, respectiv al fiabilităţii la nivel de modul. De asemenea se pot defini metrici de coeziune la nivelul fiecărui modul, prin intermediul căilor independente de date la nivelul fluxurilor globale de informaţii;
• Complexitatea întreţinerii aproximată prin numărul de module apelate şi a legăturilor dintre acestea. Relaţiile între module pot fi modelate şi prin intermediul cuplării la nivelul datelor.

Evaluarea performanţelor soluţiei informatice include şi factori precum: numărul maxim de cereri care pot fi deservite simultan, gradul de încărcare al echipamentelor fizice, timpul mediu de răspuns la un anumit serviciu, disponibilitatea totală a sistemului. În cadrul procesului de evaluare pot fi luate în considerare soluţii alternative în vederea unei proiectării cât mai eficiente a întregului sistem.

Riscuri

În cadrul procesului de proiectare vor fi luate în considerare riscurile unui proiect software în vederea asigurării unui management eficient al riscurilor. Printre acestea amintim:

• factori tehnologici: noutatea tehnologică, metodele de dezvoltare, instrumentele de dezvoltare;
• factori de design: design defectuos din punct de vedere al complexităţii, modularizării; depistare erori neprevăzute în specificarea iniţială a sistemului;
• factori externi: calitatea specificaţiei cerinţelor, stabilitatea cerinţelor şi numărul de modificări ale specificaţiilor, calitatea definirii, stabilitatea şi disponibilitatea interfeţelor externe;
• factori de management de proiect: Deficienţa de comunicare şi de coordonare a activităţilor, riscuri de planificare printre care: estimarea eronată a resurselor umane, a perioadelor de timp, definirea responsabilităţilor.

Studiu Fezabilitate

Scopul studiului de fezabilitate constă în fundamentarea deciziilor cu privire la toate elementele importante ale proiectului după ce au fost considerate toate alternativele disponibile. Pentru realizarea acestui scop este necesară prezentarea alternativelor, a datelor utilizate şi a rezultatelor studiilor-suport şi a eventualului studiu de prefezabilitate care justifică soluţiile propuse. Pentru utilizarea facilă a studiului de fezabilitate în analiza proiectului de investiţie, prezentarea acestuia trebuie să respecte de cele mai multe ori un format standard (de exemplu HG nr. 28/2008), iar datele şi studiile-suport realizate trebuie ataşate ca anexe.

Prezentarea studiului de fezabilitate depinde de dimensiunea proiectului şi de categoria din care face parte. Astfel, studiile de fezabilitate variază de la proiect la proiect în funcţie de gradul de detaliere şi importanţa acordată diferitelor aspecte, complexitatea informaţiei prezentate fiind direct proporţională cu amploarea şi caracterul proiectului. Totuşi, conţinutul studiului trebuie să acopere toate aspectele necesare evaluării fezabilităţii proiectului. Din această perspectivă, în cadrul SF-ului trebuie abordate cel puţin următoarele aspecte:

Descrierea proiectului

In cadrul acestei secţiuni se vor prezenta: iniţiatorul proiectului, obiectivele şi strategia proiectului, localizarea. Toate aceste informaţii sunt necesare pentru a susţine importanţa proiectului şi capacitatea Beneficiarului de a finaliza implementarea acestuia în faţa persoanelor care vor examina soluţia propusă.

Obiectivele proiectului se vor contura astfel încât să fie inteligibile şi să permită identificarea facilă a aspectelor care se doresc rezolvate prin intermediul acestui proiect. Pentru a fi viabile, obiectivele proiectului trebuie să fie de tip „SMART”(Specific, Măsurabil, Executabil, Realizabil, Realizabil din punctul de vedere al timpului).

Viabilitate din punctul de vedere al pieţii

Obiectivul acestei secţiuni este acela de a descrie natura şi potenţialul industriei, poziţionarea pe piaţă şi o cuantificarea a beneficiilor aduse raportat la situaţia existentă în piaţă.

Locaţia

În funcţie de natura proiectului, acesta poate fi localizat aproape de piaţa ţintă, aproape de furnizorii de materiale prime sau în cadrul spaţiului deja existent la nivelul Beneficiarului. Se va pune accent pe: impactul asupra mediului înconjurător, politicile sociale şi economice ce pot stimula sau impune constrângeri investiţiei, infrastructura existentă şi condiţiile de mediu. Locaţiile propuse trebuie prezentate prin prisma avantajelor şi dezavantajelor aduse, iar varianta optimă aleasă este justificată prin enumerarea aspectelor sale esenţiale favorabile implementării şi dezvoltării proiectului. În cadrul acestei etape se conturează amplasamentul şi beneficiarii direcţi şi indirecţi ai investiţiei.

Viabilitatea tehnică

Studiul de fezabilitate trebuie să descrie tehnologiile necesare proiectului (echipamente hardware, soluţii software, utilaje, instalaţii etc.), să analizeze alternativele de tehnologii (minim 2 scenarii tehnico-economice cu evidenţierea avantajelor / dezavantajelor, costurile aferente şi asigurarea de beneficii şi utilităţi la nivelul instituţiei şi a utilizatorilor) şi să o selecteze pe cea potrivită în urma unei recomandări care ulterior va fi aprobată de Beneficiar. Alegerea soluţiei trebuie să se bazeze pe o analiză a diferenţelor de tehnologie, inclusiv aspecte contractuale ale licenţelor tehnologice, dar nu în ultimul rând şi pe o analiză bazată pe costurile de achiziţie.

Bugetul proiectului sau devizul general a proiectului

În această secţiune se vor detalia costurile fiecărui echipament şi serviciu în parte.

Managementul şi organizarea

Aici vor fi prezentate calităţile şi raţiunea selectării membrilor echipei de conducere, profilul profesional. Tot în cadrul acestei secţiuni vor fi prezentaţi managerii cheie propuşi, precum şi ceilalţi experţi ai proiectului, fiecare cu următoarele caracteristici prezentate: responsabilităţi, experienţa relevantă şi costuri aferente.

Factori de risc

La acest nivel vor fi prezentate riscurile şi principalele variabile care pot constitui factori de risc. Printre acestea, în majoritatea proiectelor sunt identificate următoarele: preţurile produselor, durata de încasare a creanţelor, costul forţei de munca, rata dobânzii, fluctuaţiile cursului valutar. În cadrul analizei de senzitivitate vor fi identificate variabilele critice a căror impact va fi ulterior cuantificat în partea de analiză a riscurilor. Fiecărui risc îi vor fi atribuite câte o pereche , făcând astfel posibilă determinarea indexului specific, pe baza căruia se poate realiza o clasificare a riscurilor. În concluzie, acest capitol va trata orice factor de risc care poate pune în pericol fezabilitatea proiectul de investiţii.

Viabilitate financiară

În această parte vor fi prezentate criterii utilizate pentru evaluarea eficienţei financiare a proiectului de investiţii, precum şi diferite elemente financiare precum: investiţii totale, costul total de producţie, finanţarea proiectului sau evaluarea investiţiei.

Analiza cost-beneficiu presupune şi analiza opţiunilor, calcularea indicatorilor de performanţă financiară (fluxul cumulat, valoarea neta actualizată, rata interna de rentabilitate şi raportul cost-beneficiu), analiza economică cu o cuantificare a beneficiilor aduse prin implementarea sistemului.

Concluziile studiului

Concluziile studiului vor arăta dacă proiectul de investiţie este sau nu viabil din punct de vedere operaţional, financiar şi tehnologic, lucru care trebuie să reiasă clar din concluziile SF-ului. Trebuie prezentate principalele avantajele şi dezavantajele ale obiectului de investiţii precum şi impactul acestuia şi perspectivele ulterioare de dezvoltare.

Proiectul tehnic

În vederea fundamentării studiului de fezabilitate, în cazul majorităţii proiectelor este necesară realizarea unui proiect tehnic la nivelul căruia vor fi prezentate detaliat următoarele informaţii:

• Descrierea serviciilor şi funcţionalităţile pe care sistemul trebuie să le îndeplinească, descrierea acestora (analiza de sistem) şi gruparea acestora pe module funcţionale;
• Arhitectura logică şi fizică a sistemului, a fiecărui sub-sistem, şi a aplicaţiilor, inclusiv determinarea resurselor minime de performanţă pentru fiecare modul identificat;
• Schema de flux şi a proceselor (schema logică) la nivelul fiecărui modul şi la nivelul întregului sistem pentru a oferi o perspectivă atât în ansamblu, cât şi în detaliu asupra sistemului;
• Lista cerinţelor funcţionale şi operaţionale;
• Calcularea resurselor de comunicaţie, dimensionarea reţelelor şi determinarea politicilor de securitate necesare în cadrul infrastructurii de comunicaţii de date şi eventual de voce integrată;
• Descrierea cerinţelor de integrare a elementelor sistemului şi a cerinţelor de performanţă minime necesare;
• Descrierea tehnologiilor hardware necesare şi integrarea, respectiv maparea acestora pe aplicaţiile sistemului;
• Modul de integrare ale aplicaţiilor şi echipamentelor existente cu soluţiile propuse;
• Descrierea software-ului de bază şi aplicaţiile existente şi necesare;
• Platforma şi structura bazei de date (arhitectura, integrarea şi migrarea datelor din diverse aplicaţii);
• Organizarea şi managementul resurselor umane în cadrul proiectului;
• Graficul de realizare a soluţiei propuse (faze, etape, durate, corelaţii tehnice între subsisteme, condiţionări tehnice, funcţionale şi de performanta);