Pentru atingerea obiectivelor ţintă ale unei organizaţii în condiţii de eficienţă sporită, aceasta trebuie să beneficieze de un suport informatic care să acopere cerinţele funcţionale şi tehnologice pe care activităţile curente le ridică.

Este important de subliniat faptul că suportul informatic trebuie să susţină atât cerinţele de natură funcţională, cât şi cele de natură tehnică (disponibilitatea sistemelor, utilizarea eficientă a resurselor hardware şi software, accesibilitatea sistemului, securitatea datelor precum şi interoperabilitatea cu alte aplicaţii).

Diversitatea funcţionalităţilor din cadrul unei organizaţii generează necesitatea de a expune utilizatorilor componente software care să gestioneze într-o manieră cât mai eficientă activităţile. Din perspectiva multitudinii de aplicaţii devine impetuoasă integrarea diverselor componente în vederea asigurării unui mediu de lucru unitar, cu un flux corespunzător al informaţiilor între diferitele module, dar şi pentru a furniza un nivel al costurilor de mentenanţă şi operare redus, controlabil.

Pe lângă oferirea de suport, un sistem informatic urmăreşte să asigure respectarea unor caracteristici cum ar fi:

• Informatizarea şi eficientizarea departamentelor din cadrul organizaţiei;
• Suportul tehnologic necesar pentru asigurarea disponibilităţii sistemelor;
• Integrarea diverselor module ale sistemului informatic;
• Asigurarea informaţiilor şi funcţiilor minime în caz de dezastru;
• Acoperirea cerinţelor şi funcţionalităţilor identificate şi evidenţiate la nivelul Beneficiarului.

Proiectarea unei soluţii informatice face parte din cadrul procesului de „software engineering” care conform Standardului IEEE 1993 reprezintă „aplicarea şi studiul unei abordări sistematice, disciplinate şi măsurabile în dezvoltarea, operarea şi întreţinerea software-ului, adică aplicarea ingineriei pentru software.”

Principalele activităţi ale proiectării unei soluţii informatice cuprind:

1. Activităţi tehnice:

    Definirea cerinţelor utilizator: este descris punctul de vedere al utilizatorului necesarul de: funcţionalităţi ale sistemului, de performanţă, de securitate, caracteristicile definitorii ale interfeţei utilizator; de asemenea sunt specificate testele de acceptanţă;

    Definirea cerinţelor software: pornind de la cerinţele utilizator, este definit unui set de cerinţe pe care viitoare soluţie informatică trebuie să le îndeplinească astfel încât să fie satisfăcute cerinţele Beneficiarului; această specificare este independentă de implementare şi furnizează o bază pentru estimarea costurilor şi a planificării;

    Proiectarea arhitecturală: la acest nivel se stabileşte arhitectura sistemului software care va implementa cerinţele software, se alege soluţia de proiectare optimă dintre alternativele posibile, şi se pot include de asemenea şi specificaţiile pentru testele de integrare;

    Proiectarea detaliată: Subsistemele sunt descompuse succesiv până se ajunge la nivel de componente direct implementabile prin unităţi de program; se specifică funcţia/ funcţiile pe care trebuie să le realizeze fiecare componentă şi, de asemenea, se pot defini testele unitare.

1. Activităţi de asigurare a calităţii care au drept scop asigurarea cerinţelor tehnice şi a standardelor de calitate în cadrul procesul de proiectare şi ulterior de dezvoltare a produsului final. Din această perspectivă se vor alegere metodele şi standardele de specificare, proiectare şi implementare, vor fi definite reviziile, strategiile de testare, metrici de evaluare a produselor pentru ca în final calitatea soluţiei informatice să fie optimă;
2. Activităţi de management al proiectului care se axează în primul rând pe etapizarea şi planificarea în timp a activităţilor, de unde puternica corelare între componenta tehnică şi cea managerială.

Ciclul de viaţă al unui program

În cadrul proiectării unei soluţii informatice trebuie descris ciclul de viaţă al unui program („Software life cycle”) în vederea planificării ulterioare a activităţilor de implementare, testare şi integrare ale sistemului. Astfel, ciclul de viaţă al unui program reprezintă o secvenţă de etape în existenţa produsului software care include toate activităţile necesare pentru dezvoltarea produsului şi relaţiile temporale dintre ele. Fiecare etapă din ciclul de viaţă este caracterizată prin activităţi specifice şi produsele rezultate din activităţile respective.

Modelele ciclului de viaţă software („Software development life cycle models / process models”) luate în considerare sunt:

Modelul în cascadă („Waterfall model”) este adecvat pentru proiectele în care cerinţele sunt bine înţelese de la început şi nu se modifică pe parcursul procesului de dezvoltare. Astfel sistemul este bine documentat şi este permis un bun management al proiectului din prisma planificării resurselor umane pe etape, cât şi a unor estimări de cost cât mai exacte. Printre principalele dezavantaje se numără: obţinerea unui produs executabil, care să demonstreze funcţionarea sistemului, destul de târziu, după integrare; exista doar a unui feedback local, la tranziţiile între faze datorită secvenţialităţii acestora, şi toate riscurile sunt incluse într-un singur ciclu de dezvoltare;

Modelul in V („V model”) 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;

Modelul iterativ si incremental este opus modelului „în cascada”. Se porneşte de la premisa că dacă un sistem este prea complex pentru a fi înţeles, conceput sau realizat într-o singură fază, este mai bine să fie realizat în mai multe faze, prin evoluţie. Astfel, în fiecare etapă este livrat un produs care satisface o parte din cerinţele Beneficiarului iar feedback-ul este distribuit pe întreg parcursul proiectării/dezvoltării. Dezavantajul major al acestui model constă în faptul că efectul unei modificări locale se poate propaga în ansamblul aplicaţiei, apărând necesitatea reorganizării structurii interne, degradând arhitectura iniţială. Erorile posibile de proiectare sunt mai greu de eliminat, iar de asemenea pot apărea noi cerinţe din partea Beneficiarului pe măsura proiectării/dezvoltării soluţiei informatice;

Rational Unified Process este un proces de dezvoltare iterativ, cu următoarele particularităţi:

• Dirijat de cazurile de utilizare  care descriu complet funcţionalităţile sistemului; 
• Centrat pe arhitectură, aceasta fiind considerată aspectul cel mai important al sistemului; 
• Iterativ şi incremental, proiectul de dezvoltare software fiind divizat in mini-proiecte, fiecare reprezentând o iteraţie din care rezultă un increment.

Dezvoltarea “agilă”(„Agile development”) este un cadru conceptual pentru proiectele software care se axează pe minimizarea riscurilor de proiectare/dezvoltare dezvoltând soluţia informatică in intervale scurte de timp, numite „timeboxes”, constând din iteraţii de 1-4 săptămâni. Fiecare iteraţie este un proiect în miniatură şi include toate activităţile necesare livrării mini-incrementului în vederea asigurării de noi funcţionalităţi: planificare, analiza cerinţelor, proiectare, dezvoltare, documentare.

Dezvoltarea pe bază de prototip („Prototyping”): pentru sisteme noi, în mod special dacă ele sunt mari şi complexe este puţin probabil să se construiască o specificaţie completă, logică şi validă înainte ca sistemul să fie construit şi utilizat. Ideea de prototipare 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. Astfel se obţine un prototip care reprezintă o schiţă a viitorului sistem: el nu are performanţele şi nici nu răspunde exigenţelor de calitate ale unui produs finit, dar oferă Beneficiarului funcţionalităţile (nu în totalitate) ale viitorului sistem şi interfaţa sa utilizator. Prototipul este dezvoltat într-o manieră iterativă. În fiecare iteraţie specificaţia sistemului este modificată şi detaliată până când prototipul satisface toate necesităţile Beneficiarului. În concluzie, prototipul poate fi considerat o "machetă exploratoare", utilă şi în etapa de proiectare pentru a experimenta şi compara diferite variante. 

Comparaţie între diversele metode

În funcţie de specificul sistemului informatic, a soluţiilor deja existente pe piaţă şi a necesarului de particularizare şi implementare de noi module, în cadrul etapei de proiectare se selectează modelul care răspunde cel mai bine nevoilor proiectului.

Metodele de dezvoltare pot fi plasate pe o scară continuă de la cele adaptive la cele predictive, în condiţiile în care la extremităţi se regăsesc modelele „agile”, respectiv „în cascadă”.

Metodele adaptive sunt focalizate pe adaptarea rapidă la schimbări iar orizontul de timp este unul de scurtă durată, se poate raporta exact ce sarcini vor fi realizate săptămâna următoare şi ce este planificat pentru luna următoare.

Metodele predictive sunt focalizate pe planificarea în detaliu a activităţilor în timp, astfel fiind posibilă raportarea exactă a întregului proces. Dificultăţi apar în schimbarea direcţiei întrucât planul este optimizat pentru destinaţia originală iar modificările pot necesita renunţarea la rezultatele curente şi replanificarea activităţilor. Pentru a evita astfel de situaţii, numai schimbările considerate importante sunt luate în considerare.

Astfel în cadrul procesului de proiectare este identificat modelul de software engineering care să se mapeze cât mai bine pe necesităţile proiectului în funcţiei de soluţiile existente şi de gradul de customizare / dezvoltare şi implementare necesare.

Modelarea sistemelor informatice

Modelarea este parte esenţială în orice proiect software, în special în proiectele mari., iar modelele sunt reprezentări abstracte ale sistemului, create în etapele care preced implementarea propriu-zisă a sistemului şi anume în partea de analiza şi specificare a cerinţelor, de proiectarea arhitecturală, respectiv de proiectarea de detaliu. Modelele de proiectare redau arhitectura sistemului, alocarea cerinţelor Beneficiarului pe subsisteme sau module, distribuţia proceselor în sistem, sincronizarea lor, precum şi realizarea fizică a sistemului, echipamentele din componenta sa şi repartiţia componentelor software pe diferite componente hardware.

Sistemele Informatice Integrate sunt compuse in general din trei elemente de bază:

1. Elemente software: sisteme de operare, baze de date şi aplicaţii de tip business intelligence, cele din urma formând baza logică de stocare, procesare şi prezentare a informaţiilor din cadrul soluţiei informatice;
2. Infrastructura de reţea pentru comunicaţiile de date şi voce integrate care facilitează funcţionarea sistemului informatic în condiţii optime;
3. Echipamentele hardware formate din servere şi periferice necesare funcţionarii sistemului informatic.

Pentru realizarea unui sistem informatic eficient, trebuiesc avute în vedere unele reguli de bază care să asigure: funcţionarea în condiţii optime a soluţiei proiectate, legătura acesteia cu lumea exterioară din perspectiva posibilităţilor de comunicare cu alte sisteme, compatibilitatea cu sisteme de altă natură, posibilitatea includerii sistemului într-un sistem mai complex, capacitatea acestuia de a include la rândul său alte sisteme sau extinderea funcţionalităţilor prevăzute iniţial.

O constrângere puternică care trebuie luată în considerare în cadrul procesului de proiectare a unui sistem este cea de natură economică, mai exact disponibilitatea financiară în vederea realizării bugetului. Cu alte cuvinte, în momentul proiectării trebuie avut în vedere ca raportul dintre rezultatele directe sau indirecte obţinute prin implementarea şi folosirea sistemului şi totalitatea costurilor de proiectare, dezvoltare, operare şi întreţinere să fie cât mai mare. Cu alte cuvinte, soluţia propusă trebuie să fie rentabilă şi să justifice prin serviciile implementate şi/sau optimizate necesitatea şi oportunitatea implementării acesteia.

Proiectarea propriu-zisă a sistemului informatic, după definirea cerinţelor utilizator şi celor software se va realiza în două etape şi anume:

1.      Proiectarea de ansamblu

În cadrul acestei etape se va stabili arhitectura de ansamblu a întregii soluţii, modul de descompunere a cerinţelor clientului pe componente şi sub-sisteme, intrările şi ieşirile sistemului.

Modelul de proiectare arhitecturală este o structură ierarhică alcătuită din sub-sisteme interconectate, fiecare subsistem fiind alcătuit dintr-un set de module interconectate sau din alte subsisteme. Pentru fiecare modul al arhitecturii software se scrie o specificaţie rolul fiecărei componente, cerinţele care i-au fost alocate, cu intrările şi ieşirile, funcţionalităţile, prelucrările şi fluxul intern de date, precum şi interfaţa de comunicare cu celelalte componente ale sistemului.

Abordările posibile în vederea obţinerii modelului de proiectare arhitecturală sunt:

1. Abordare descendentă: se pleacă de la specificaţia cerinţelor software, se descompune setul de specificaţii în subseturi relativ independente, iar fiecare subset de cerinţe este alocat unui subsistem al arhitecturii;
2. Abordare ascendentă este centrată pe reutilizare: se pleacă de la un set de module sau aplicaţii existente şi se caută o descompunere a cerinţelor în subseturi care pot fi implementate folosind componentele existente;
3. Abordare hibridă: se pleacă de la setul de cerinţe software care se descompune iterativ, dar în procesul de descompunere se urmăreşte definirea de module care pot fi implementate folosind module existente.

Reguli de proiectare

• Modulele trebuie să fie simple şi cât mai independente unul de altul astfel încât o modificare a unuia să aibă o influenţă minimă asupra altor componente, iar schimbările specificaţiilor să nu se reflecte la nivelul întregii arhitecturii software;
• Minimizarea cuplării între module prin minimizarea numărului de elemente prin care comunică modulele – adoptarea unui arhitecturi de tip SOA („Service Oriented Architecture”);
• Maximizarea coeziunii interne a fiecărei componente astfel încât elementele din cadrul aceluiaşi modul să fie corelate, de exemplu să contribuie la aceeaşi prelucrare în cadrul fluxului informaţional;
• Maximizarea numărului de module care utilizează un acelaşi modul, astfel încurajând reutilizarea;
• Factorizarea funcţionalităţilor comune;
• Prevederea interfeţelor de comunicare cu alte sisteme informatice şi stabilirea unui standard al mesajelor interschimbate;
• În ceea ce priveşte securitatea sistemului, modulele vor trebui să ascundă modul de implementare a funcţiilor descrise de interfaţa lor, procesul devenind transparent şi intuitiv pentru utilizatorul final.

2.      Proiectarea de detaliu

Dacă în prima etapă s-au schiţat toate nevoile şi cerinţele unei organizaţii, în a doua etapă se va pune accent pe detalierea fiecărei funcţionalităţi, respectiv sub-sistem, astfel încât sistemul să ruleze eficient, fără erori sau necorelări între diferitele module ale soluţiei. Este etapa în care se construieşte modelul fizic, inclusiv arhitectura hardware a viitorului sistem, iar proiectarea diferitelor module poate avea loc în paralel.

Proiectarea hardware presupune maparea modulelor aplicative pe o infrastructură de echipamente. Pornind de la analiza specificaţiilor fiecărui modul, sunt determinate necesităţile la nivel de echipamente hardware în vederea dimensionării corespunzătoare a acestora. Este important aspectul de agregare a mai multor module în cadrul aceleaşi maşini fizice, sau posibilitatea virtualizării mai multor maşini pe aceeaşi maşină fizică, reducând astfel numărul total de echipamente.

Un alt element principal în cadrul proiectării hardware este infrastructura de comunicaţii care trebuie dimensionată corespunzător în vederea asigurării necesarului de trafic, a tuturor funcţionalităţilor pentru numărului prevăzut de utilizatori şi aplicarea politicilor de securitate pentru a păstra caracterul confidenţial al informaţiilor schimbate în cadrul sistemului.

Caracteristicile soluţiei informatice proiectate

Pornind de la modelul propus de IBM – CUPRIMDSO (capability/functionality, usability, performance, reliability, installability, maintainability, documentation /information, service and overall) au fost identificate următoarele caracteristici definitorii pentru o soluţie informatică performantă şi viabilă:

Asigurarea funcţionalităţilor dorite, centralizarea şi integrarea serviciilor;

Adaptabilitatea din perspectiva uşurinţei de modificare şi întreţinere;

Eficienţa din prisma utilizării eficiente (la minimum) a resursele disponibile;

Uşurinţa înţelegerii drept uşurinţa cu care sistemul este perceput de către utilizatorii finali;

Grad cât mai mare de satisfacţie al utilizatorilor care poate fi aproximat prin numărul de probleme raportate de aceştia în decursul unei luni;

Creşterea eficienţei şi competitivităţii ca rezultate finale asupra activităţilor Beneficiarului;

Fiabilitate din perspectiva probabilităţii ca soluţia propusă să asigure funcţionalităţile propuse pentru o perioadă de timp, în condiţiile specificate. Estimarea acestui indicator se poate realiza în perioada de testare prin metode statistice, astfel obţinând 2 metrici relevante: timpul mediu între 2 căderi succesive şi timpul mediu până la cădere;

Administrare eficientă şi posibilităţi extinse de raportare şi generare de statistici în urma utilizării, administrării sistemului, precum şi în urma gestionării şi prelucrării informaţiilor interne;

Disponibilitate - pentru o bună exploatare, sistemul trebuie să asigure un nivel înalt de performanţă şi disponibilitate, putând fi accesat 24 de ore din 24, 365 de zile pe an. Practic timpul de downtime trebuie sa fie cat mai mic, de la 0,1% în jos, în funcţie cât de critic este sistemul proiectat;

Accesibilitate – nu este suficient doar ca informaţiile să fie disponibile deoarece contează şi modul de prezentare/interpretare al acestora pentru a face cât mai facilă interacţiunea cu utilizatorul;

Modularitatea presupune descompunerea iterativă a sistemului în sub-sisteme, respectiv în module şi facilitează abilitatea de a adăuga, şterge, înlocui sau modifica componente cu un impact minim asupra operaţiilor, gestiunii şi securităţi sistemului;

Scalabilitate – sistemul trebuie să permită adăugarea de noi echipamente / staţii fără a degrada performanţele actuale în vederea creşterii numărului de utilizatori;

Extensibilitate – capacitatea sistemului de a integra noi servicii, funcţionalităţi sau echipamente şi reprezintă un principiu de design în cadrul căruia implementarea ia în considerare extinderi ulterioare. Astfel se poate cuantifica şi nivelul de efort pentru a implementa noi facilităţi şi mecanisme fără a avea un impact major asupra infrastructurii existente;

Interoperabilitate – majoritatea soluţiilor informatice comunică cu alte sisteme, astfel apărând necesitatea definirii unor metode unitare la nivel de module în vederea interschimbului de informaţii – de exemplu posibilitatea publicării informaţiilor şi a serviciilor din cadrul sistemului aplicativ prin intermediul unor servicii web;

Securitate – o componentă importantă în cadrul oricărei soluţii informatice care permite aplicarea politicilor de securitate specifice oricărei aplicaţii; la acest nivel sunt incluse liste de acces, drepturi si privilegii la nivel de utilizatori, administrarea profilelor, protecţia împotriva eventualelor atacuri informatice, garantarea confidenţialităţii, non-repudierii informaţiilor, aplicarea principiului AAA („Authentication, Authorization and Accounting”) la nivelul soluţiei propuse;

Durabilitatea soluţiei – presupune determinarea orizontului de timp în care se poate realiza o exploatare eficientă a sistemului; de asemenea trebuie prevăzute actualizări, operaţii de mentenanţă, în vederea asigurării unei durate cât mai mari de utilizare.