STUDIU DE FEZABILITATE

Studiu de Fezabilitate

Sistem Bazat pe Tehnologia Internet pentru

Administrarea Portofoliului de Asigurari si Analiza Riscului

Data crearii: Mai, 2, 2000

Ultima actualizare: Iunie, 15, 2000

Numar de Control: ICI/RELANSIN/FS/001

Versiune: Finala

Aprobari:

Inregistrarea schimbarilor

Revizori

Distributie

Introducere

Scop

1. Aspecte Preliminare 

1.1. Conditii de elaborare a proiectului 

1.2. Aria de cuprindere 

1.3. Cerinte functionale 

1.4. Metode de lucru

Vedere generala a produsului ORACLE DESIGNER 

2. Prezentarea situatiei existente

2.1. Functiunile si obiectivele sistemului existent

2.2. Restrictii functionale, organizationale si economice

2.3. Stadiul informatizarii Grup AS 

2.4. Evolutii preconizate pe termen scurt:

3. Prezentarea globala a viitorului sistem informatic

3.1. Obiectivele sistemului 

3.2. Arhitectura sistemului 

3.3. Componentele sistemului de asigurari 

3.3. Evaluarea fezabilitatii organizationale, tehnice si economice a

sistemului; conditionari 

4. Prototipul de sistem ( proiectul pilot functional)

4.1. Factori de Succes pentru Proiectul Pilot 

4.2. Cerintele prototipului de sistem de asigurari

5. Instruirea personalului Grup AS 

6. Abordarea chestiunilor de securitate

7. Planul de dezvoltare a sistemului de asigurari

Scop

Documentul Studiu de Fezabilitate isi propune sa analizeze diferitele aspecte legate de implementarea proiectului sistemului de asigurari in scopul de a furniza metode, orientari de dezvoltare, jaloane tehnice pentru abordarea unor chestiuni dificile din sistem, in vederea realizarii obiectivelor proiectului asa cum sunt ele specificate in Contractul de Colaborare dintre ICI-Grup AS si precizate in Termenii de Referinta - SOA.

Studiul de Fezabilitate este structurat pe urmatoarele directii principale:

Aspecte preliminare, conditii de elaborare a Proiectului, Responsabiltati parteneri, Cerinte Functionale;

Studiul sistemului existent, aspecte functionale, forme de intrare, rapoarte;

Componentele viitorului sistem;

Cerintele privind realizarea Prototipului de sistem;

Aspecte privind Instruirea personalului

Studiul de fezabilitate se refera la proiectul de Sistem de Asigurari ale carui coordonate sunt trecute in Caseta de mai jos:

1.1. Conditii de elaborare a proiectului

Sistemul este realizat in colaborare cu societatea de asigurari Grup AS SA care este de altfel si beneficiarul acestuia.

Obiectivul fundamental al colaborarii îl constituie realizarea si punerea în exploatare la Grup AS SA. a unui sistem care sa îndeplinesca urmatoarele functii principale:

sa permita administrarea portofoliului de asigurari;

sa ofere metode, tehnici si instrumente pentru analiza de risc specifica domeniului.

Sistemul realizat va trebui pus în exploatare în reteaua nationala a Grup AS care este compusa din 44 sucursale si cca. 60 agentii.

Echipa de proiectare este compusa din 5 experti ICI si 5 experti Grup AS care vor lucra la sediul Grup AS intr-o sala special ameanjata conform cerintelor proiectului (vezi, Termenii de Referinta - SOA).

Platforma software/hardaware este definita in Termenii de Referinta-SOA.

Sistemul trebuie sa faciliteze:

constituirea în timp si în cuantumul prevazut a fondului de asigurare;

acordarea operativa a despagubirilor si respectiv, a sumelor asigurate la care au dreptul asiguratii, atunci când se produc riscurile acoperite;

adaptarea continua a formelor de asigurare (facultative si obligatorii) de bunuri, persoane si raspundere civila la cerintele care apar pe piata de asigurari si reasigurari, interna si internationala;

Responsabilitati ICI:

Coordonare generala proiect:

a. Activitati de cercetare - dezvoltare (cercetare fundamentala, aplicativa si dezvoltare tehnologica):

va coordona desfasurarea lucrarilor pe intreg parcursul elaborarii fazelor sistemului propus.

va centraliza cerintele partenerului ca potential utilizator final in vederea elaborarii etapelor de cercetare fundamentala si aplicativa pentru definirea conceptelor generale, metodelor, procedurilor si solutiilor adecvate cat si a celor personalizate pentru ramura de activitate a partenerului

va pune la dispozitia partenerului rezultatele si know-how-ul acumulat in etapa de cercetare aplicativa respectiv a experimentarilor concrete, a documentatiilor de folosire a software-ului si manualelor elaborate privind utilizarea lucrului in cooperare asistat de calculator

va finaliza fazele cu documentatiile specifice (rapoarte de cercetare, de experimentare, manuale, specificatii pentru modelelele experimental si functional).

b. Activitati de transfer tehnologic si valorificare la partener si teti utilizatori potentiali (unitati organizationale):

diseminare a informatiilor,

transfer de cunostinte,

consultanta si asistenta tehnica,

demonstratii.

Responsabilitati partener de colaborare Grup AS:

a. Activitati de cercetare - dezvoltare (cercetare fundamentala, aplicativa si dezvoltare tehnologica):

definirea cerintelor specifice pentru activitatile de lucru in cooperare pentru managementul unitatii organizationale,

participarea la elaborarea caietului de sarcini pentru domeniul propriu de activitate,

punerea la dispozitie a unei platforme de experimentare pentru implementarea software-ului de baza si dezvoltarea si testarea unor aplicatii specifice,

participarea la dezvoltarea unor aplicatii specifice in urma transferului de cunostinte,

participarea la fazele de experimentare a aplicatiilor elaborate

implementarea si exploatarea aplicatiilor utilizator generale si specifice.

Expertiza oferita de ICI este circumscrisa urmatoarelor arii de cercetare-dezvoltare:

cercetare-dezvoltare, implementare de produse software care acopera o paleta larga de domenii atât de cercetare fundamentala si aplicativa, cât si de dezvoltare si transfer tehnologice.

metode, tehnici si instrumente de specificare, proiectare si asigurarea calitatii

produselor software;

sistemele de gestiune a bazelor de date bazate pe modele cum ar fi: client-server sau multi-partite;

tehnologii INTERNET de creare situri WEB, INTRANET-uri precum ti de conectare la surse externe de date;

tehnologii de comunicatii (retele LAN, WAN; telefonie mobila, etc.).

Grup AS SA va oferi expertiza specifica în domeniul asigurarilor-reasigurarilor, piata de asigurare, analiza tendintelor pe linii de asigurare , analiza riscului, etc.:

1.2. Aria de cuprindere

Datorita resurselor limitate aprobate de ANSTI pentru finantarea acestui proiect si care constituie cca jumatate din fondurile cerute initial , functiile sistemului initial prezentate in Documentatia Proiectului depusa la ANSTI nu vor putea fi implementate in intregime. De aceea, cu acordul clientului Grup AS s-a hotarat implementarea unui nucleu al sistemului care sa functioneze exclusiv pe INTERNET si care va fi compus din urmatoarele:

Detalierea componentelor (business functions)

Administrarea contractelor de asigurari;

Gestionarea politelor;

Administrarea registrului de asigurati;

Administrarea daunelor;

Statistici cu privire la activitatea de asigurari;

Transferul de date intre unitatile Grup AS;

Controlul integral al activitatii de asigurari;

Asistenta personalului de asigurari;

Asistenta clientilor;

Conversia datelor din sistemul existent;

Administrarea Bazei de date;

Aria de aplicare a acestui proiect este formata din mai multe zone. Pentru fiecare din aceste zone trebuie sa existe o strategie pentru incorporarea lor in intregul proiect.

Aplicatii In vederea incadrarii in resursele financiare al Proiectului se va implementa nucleul de sistem legat de INTERNET

Locatii Pentru implementare vor fi luate in considerare urmatoarele locatii:

Grup AS SA

Sucursalele Judetene Grup AS

Unitatile Operative Subordonate ( agentii, agenti individuali)

Sisteme existente Sistemul de Asigurari Softeh implementat in 1993 (Fox Pro 2.6)

Interfete In timpul proiectului vor fi luate in considerare interfetele cu diverse sisteme externe. Cerintele care vor rezulta in urma analizei se vor documenta si vor forma aria de cuprindere pentru urmatoarele proiecte. In cadrul acestui proiect se vor dezvolta interfete.

Architectura Arhitectura va fi descentralizata, cu baza de date pe server-ul local situat la unitatile operative. In timpul analizei se va solutiona si problema replicarii acestei baze de date pe serverele din nodurile superioare. Baza de date de la un nivel oarecare intermediar este suma bazelor de date de la nivelele subordonate.

Conversie Vor fi convertite datele existente in baza de date a Sistemului de Asigurari anterior.

1.3. Cerinte functionale

Sistemul de Asigurari integral implementat trebuie sa satisfaca urmatoarele cerinte:

sa permita administrarea portofoliului de asigurari.. Aceasta include:

adaugarea, modificarea, stergerea politelor de asigurare corespunzator tipurilor acestora;

introducerea produselor, subproduselor, limitelor de expunere, prima de asigurare, ratele, limitele de pierdere, perioada de asigurare, taxele, comisioanele si altele asemenea;

vizualizarea politelor de asigurare, inclusiv starea acestora si istoria schimbarilor;

regularizarea primelor de asigurare si editarea unei noi facturi;

anularea unei polite de asigurare la o anumita data;

facturarea automata a contractelor de asigurare la date predeterminate;

vizualizarea contractelor de asigurare;

administrarea daunelor - creare rapoarte de pierdere, urmarirea platii daunelor, etc.;

utilizarea diferitelor valute pentru fiecare contract de asigurare;

sa asigure rapoarte detaliate despre diferite aspecte ale portofoliului de asigurari:

productivitatea pe sucursale, agentii, agentii individuali;

rapoarte periodice asupra contractelor de asigurare;

rapoarte zilnice asupra primelor de asigurare de platit;

rapoarte zilnice asupra daunelor;

rapoarte zilnice asupra sumelor de asigurare pe praguri de risc;

etc.

sa asigure functii de administrare a sucursalelor, agentiilor si a agentilor individuali

sistemul de culegere de date trebuie sa fie structurat ierarhic: agentii individuali sunt conectati la agentii locale, agentiile sunt conectate la sucursale iar sucursalele sunt legate de centrala.

informatiile trebuie sincronizate de jos în sus, de la agenti individuali la centrala prin intermediul unei functii de replicare existenta în SGBD-ul suport;

schimbul de informatii dintre centrala, sucursale, agentii sa se faca pe INTERNET în conditii de securitate, utilizând legaturi dial-up;

sa permita culegerea de date prin intermediul telefoanelor celulare, palm computere, pagere, etc. si sincronizarea lor cu SGBD-ul central (este o tehnologie de tip ULTRA-LITE)

sa fie intefatat cu sistemul financiar-contabil existent

sa fie extensibil la nivel de interfata

sa permita fie introducerea facila de noi forme corespunzatoare unor noi linii de asigurari, fie modificarea unora existente;

sa permita introducerea, modificarea, stergerea de rapoarte conform cerintelor de moment ale utilizatorului.

sa ofere un tablou de bord pentru manageri, integrat în INTRANET-ul companiei;

sa asigure functii de analiza statistica a tendintelor portofoliului de asigurari pe tipuri de polite si regiuni;

sa ofere un pachet bogat de functii de analiza de risc: printre acestea

sa poata masura gradul de expunere a companiei în cazul aparitiei unui cutremur, inundatii, catastrofe umanitare, etc.

sa ofere instrumente de evaluare a riscurilor tehnice si investitionale;

sa ofere functii de calcul a primelor de asigurare pentru riscuri asigurate sau asigurabile;

sa fie usor de adaptat la reglementarile în continua schimbare ale pietei de asigurari.

1.4. Metode de lucru

Metodologia

Metodologia folosita pentru proeictarea sistemului de asigurarie este CDM (Custom Development Method) care este o metoda ORACLE care acopera intreg ciclu de viata a unui program. CDM face parte din Oracle Method, o metodologie ORACLE pentru definirea si implementarea sistemelor informatice.

CDM, versiunea 2, consta dintr-un set de procese de dezvoltare pe masura care pot fi adminstrate in diverite moduri. CDM nu este o metodologie "universala" care poate servi oricarui tip de sistem, ci permite combinarea diferitelor elemente in diverse abordari care satisfac cerintele multor tipuri de proiecte indiferent de complexitatea acestora.

CDM integreaza conceptele dezvoltarii pe masura intr-un cadru operational, bine definit. Sunt bine conturate conceptele de proces, faza, activitate, sarcina, livrabil si dependente. Combinand aceste concepte in diverse moduri, CDM poate fi aplicat multor tipuri de proiecte specifice.

CDM include 11 procese distincte pentru a gestiona activitatile standard de proiectare. Aceste procese pot fi incluse sau excluse dintr-un proiect, depinzand de cerintele si necesitatile abordari de dezvoltare alese:

Definirea Cerintelor. Acest proces defineste cerintele activitatii de informatizat si ale sistemului asociat.

Examinarea Sistemului Existent. Furnizeaza o intelegere formala a mediului informational curent in scopul de a anticipa gestionarea anticipata a schimbarilor.

Arhitectura Tehnica. Specifica elementele fundamentului tehnic al proiectului de realizare.

Proiectarea si Construirea Bazei de Date. Are drept rezultat proiectarea si implementarea bazei de date relationale, inclusiv a chestiunilor legate de indexarea eficienta si securitatea obiectelor bazei de date.

Proiectarea si Construirea Modulelor. Permite crearea aplicatiilor sistemului de realizat.

Conversia Datelor. Obiectivul acestui proces este de a migra, converti si testa toate datele necesare pentru functionarea noii aplicatii.

Documentarea. Acest proces se concentreaza pe producerea de livrabile cu o inalta calitate a imprimarii precum si a celor on-line. Sunt produse toate documentatiile necesare pentru utilizatorii finali si administratie precum si documentatia tehnica.

Testarea. Procesul de testare este o abordare integrata pentru testarea calitatii tuturor elementelor sistemului de realizat . Acest proces include atat testarea modulelor functionale cat si integrarea celor cu caracter specific aplicatiei, integrarea la nivel de sistem si testarea de acceptare.

Instruirea. Obiectivul este de a defini mediul de instruire atat pentru utilizatori cat si pentru administratorii de sistem cu privire la activitatile necesare pentru functionarea adecvata a sistemului.

Tranzitia. Include activitati de indeplinit implicate de strategia de tranzitie, cum ar fi Planul de Instalare, Mediul de Productie, etc.

Suportul Post-sistem. Obiectivele acestui proces sunt de a monitoriza si raspunde la problemele sistemului, de a actualiza aplicatia in scopul corectarii erorilor si chestiunilor de performanta, de a evalua sistemul in functiune precum si de a planifica extensiile.

Abordarile de Dezvoltare

Fundamentul CDM bazat pe procese permite definirea unei abordare de dezvoltare pe masura. Aceasta deoarece task-urle si livrabilele CDM sunt construite intr-o maniera ascendenta ("bottom-up") bazata pe dependente cunoscute intre task-uri si nu prin definirea de puncte artificiale in proiect ("faze").

Abordarile de dezvoltare sunt realizate si documentate prin intermediul fazelor. Fiecare faza include unele sau chiar toate procesele dintr-un set predeterminat.

Conceptul de faza este util si necesar pentru administrarea proiectelor. Totusi, daca pentru toate marimile si tipurile de proiecte ar exista numai un model de faze acest lucru va duce la depasiri de termene si la o inerenta ineficienta a proeictului.

CDM propun trei abordari de dezvoltare, si anume:

Clasica: pentru proiecte mediu spre mari in care controlul riscului de nerealizare este important;

Fast Track (CDMFT): pentru proiecte mici spre medii in care este posibila si dezirabila generarea de aplicatii. Aceasta abordare este iterative, strans conectata cu instrumentele ORACLE DESIGNER si bazata pe repozitoriu. CDMFT este o metoda RAD (Rapid Application Development) compatibila cu Metoda de Dezvoltare a Sistemelor Dinamice, standardul de facto in domeniu.

CDMFT implica concentrarea participarii utilizatorilor in Grupe de Lucru, care inlocuieste analiza traditionala bazata pe interviuri. Metoda este potrivita in cazurile in care cerintele functionale sunt clare cum este cazul Sistemului de Asigurari propus.

Lite: este metoda preferata pentru realizarea proiectelor mici. Metoda se bazeaza pe prototipizare rapida si este corespunzatoare dezvoltarii de aplicatii necritice.

Fazele CDMFT

Metoda CDMFT are trei faze, si anume:

Modelarea Cerintelor: Obiectivele sunt de a furniza informatii suficiente pentru construirea rapida a sistemului, pentru a obtine acordul clientului asupra functiilor sistemului intr-un timp minim;

Proiectarea si Generarea Sistemului: Scopul este de a construi rapid o aplicatie functionala utilizand generatoarele de cod bazate pe repozitoriu;

Tranzitia catre Productie: Are in vedere instalarea noul sistem, pregatirea personalului clientului si punerea in exploatare a sistemului. Apoi, monitorizarea aplicatiei, asigurarea unei exploatari fara probleme si planificarea viitoarelor extensii ale sistemului

Procesul de Control si Raportare

Acest proces gestioneaza intrega intindere a relatiei dintre client si proiect prin:

Controlul schimbarilor;

Gestionarea riscurilor si problemelor;

Raportarile de stare;

Evolutia efectiva a proiectului este controlata prin acceptul pas cu pas al clientului.

Managementul riscurilor si problemelor asigura catalogarea riscurilor, intelegerea acestora prin probabilitatea de a se produce si impactul lor precum si monitorizarea permanenta a acestora.

Monitorizarea starii proiectului si raportarile asigura ca progresul este vizibil tuturor membrilor echipei, clientului si consultantilor, prin indicarea responsabilitatilor de executie a diferitelor task-uri.

Documentul esential care defineste jaloanele dupa care sunt realizate chestiunile de mai sus este Planul de Calitate;

Setul de Instrumente: ORACLE DESIGNER 6.0

Setul de instrumente ORACLE DESIGNER constituie o solutie integrata pentru realizarea de aplicatii WEB si client/server printr-o interfata utilizator de tip RAD. ORACLE Designer acopera fiecare faza a ciclului de dezvoltare a unei aplicatii de la modelarea afacerii la punerea in exploatare si postexploatare. Versiunea curenta de utilizare va fi Oracle Designer 6.0.

Modelarea Proceselor

Oracle Designer ofera un numar de tehnicii de modelare a proceselor care sunt proiectate in scopul imbunatatirii comunicatiei dintre expertii in domeniul de informatizat si realizatorii de sistem. Aceste tehnici furnizeaza o cale de a defini scenarii in vederea construirii de puntii intre lumea specifica afacerii si cea a tehnologiei informatiei.

Modelarea Proiectului

Crearea de reprezentari vizuale a proiectului de sistem precum si exploatarea tehnologiilor de generare in concurenta cu cele de definire, produce aplicatii eficiente si robuste. Alternativa, codificarea manuala, este consumatoare de timp si producatoare de erori.

Repozitoriu multi-utilizator

Dezvoltarea de aplicatii complexe nu poate fi realizata de indivizi izolati ci de echipe de specialisti care trebuie sa coopereze pentru a raspunde provocarii implementarii aplicatiei. Un Repozitoriu multi-user este esential pentru a promova modelarea intreprinderii si generarea de aplicatii.

Generarea si Ingineria Inversa

Pentru a creste nivelul de productivitate si calitate in construirea unei aplicatii, este esential sa fie posibila generarea 100% a acesteia din modelele asociate. Generarea partiala care necesita modificarea postgenerare implica faptul ca definitia aplicatiei in repozitoriu difera de aplicatia care se executa. Aceasta face ca intretinerea si reproiectarea sa fie mult mai greu de realizat. Multe dintre noile sisteme trebuie sa coexiste sau sa exploateze aplicatii existente. De aceea, este la fel de important sa fie posibila 100% ingineria inversa a proiectului cat si 100% generarea de aplicatii.

Generarea in medii client/server si pentru Web

Definitiile din Repozitoriu sunt generate in aplicatii care sunt apoi puse in exploatare in medii client/server sau pe Web.

Capturarea Proiectarii

Modelul de Server (sau fizic), indiferent daca este ORACLE sau nu, poate fi capturat intr-un Repozitoriu prin intermediu unui set integrat de instrumente dedicate. Acest lucru permite o migrarea bazei de date din sistemele existente, documentarea sau intretinerea acestora precum si posibilitatea de a avea o vedere generala asupra tuturor datelor unei companii. Similar, aplicatiile construite in Visual Basic sau Developer, incluzand si cod scris intr-un limbaj de scripturi nativ, pot fi capturate prin setul de instrumente dedicat.

Reinginerie

Posibilitatea de a modifica o aplicatie in afara Oracle Designer, capturarea schimbarii si regenerarea, pastrand modificarile aplicatiei, se numeste reinginerie si este un element cheie al unui mediu de proiectare eficient.

Facilitati de administrare a Repozitoriului

Oracle Designer include un set cuprinzator de facilitati de gestionare a continutului Repozitoriului sau precum si acessului utilizatorilor la acesta. Acest set de administrare furnizeaza functii foarte eficiente si usor de utilizat care asigura o dezvoltare multiuser lina a sistemelor complexe maximizand beneficiul tuturor memebrilor echipei de utilizatori.

Instrumente puternice de transformare a bazei de date si a aplicatiilor

Placand de la un model Entitate Relatie validat, instrumentul Database Design Transformer poate produce automat o schema initiala a bazei de date , care apoi poate fi completata cu tabele, coloane, indecsi precum si referinte de integritate. Similar, instrumentul Application Design Transformer preia informatiile continute in modele Functional si de Flux de Date si creaza definitii complete ale modulelor de Ecran, rapoarte si menu-uri, gata pentru verificare si modificare aditionala a proiectarii inainte de generare de cod.

Vedere generala a produsului ORACLE DESIGNER

Modelatorul de Procese

Acesta suporta tehnici de modelare de proces care permit proiectantilor sa vizalizeze, inteleaga si sa imbunatateasca procele fundamentale din organizatia de modelat.

Instrumentele de analiza de sistem si modelare a cerintelor

Oracle Designer ofera instrumente care suporta tehnici de modelare standard, cum ar fi: Entitate-Relatrie, Ierarhie Functionala, Flux de Date si Orientare pe Obiecte. Intelegerea cerintelor informationale si functionale este cheia dezvoltarii de sisteme intrucat aceasta faciliteaza dezvoltarea rapida si administrarea eficienta bazate pe model si creeaza sisteme care indeplinesc cerintele clientului.

Editorul de Proiect

Oracle Designer infatiseaza un singur mediu de proiectare fizica, numit Design Editor, care are drept tinte faze de proiectare si generare. Acest mediu ofera o cale eficienta si convenabila de vizualizare si manipulare a definitiilor din repozitoriu in timpul proiectarii bazei de date si aplicatiilor.

Generatoarele ORACLE Designer

Oracle Developer

Apelate din Design Editor, generatoarele Oracle Designer produc aplicatii eficiente si standard ceea ce este un factor critic in dezvoltarea de sisteme. Generatoarele permit realizatorilor de sisteme sa beneficieze automat de eforturile facute in stadiile de dezvoltare timpurii pentru a asigura o implementare acurata si fara probleme. Atat Formele cat si Rapoartele Oracle pot fi in intregime specificate, generate, sau preluate prin inginerie inversa in Repozitoriu producand astfel crearea rapida de aplicatii pentru medii client/server sau Web.

Generatorul de WebServer

Utilizand aceeasi metoda a definitei de modul grafic ca petnru generarea de forme, sunt generate aplicatii pentru Web care pot fi executate prin browsere standard.

Generatorul Oracle Server

SQL DDL este creat pentru definitiile de tabele create cu Oracle Designer. Aceasta include table de baza impreuna cu validarile de pe server, cum ar fi, ale Cheilor Straine, Restrictiilor de Verificare si de Chei primare. In plus, se pot genera si "ingineri" invers baze de date ca: Oracle RDB, Oracle Lite, DB2/2, Microsoft SQL Server, Sybase, ANSI SQL DDL, precum si baze de date ODBC.

Sistemul de asigurari existent este implementat in Fox Prox 2.6 pe platforma Win 95/NT 4.0 Server.

2.1. Functiunile si obiectivele sistemului existent

Functiile sistemului:

Pot fi grupate in urmatoarele grupe functionale principale:

Adminstrarea Politelor: sunt editate/modificate urmatoarele tipuri de polite: Complexa, Incendiu, Furt-talharie, Vehicule-casco, Cargo, Leasing, Auto-conventie, Accidente, Aviatie, Transport Bani, Rca, Garantii, Angajati, Medicale Strainat, Buchet, Carte Verde ;

Gestionarea Borderourilor: sunt gestionate listele de polite incheiate, pe sucursale, agentii si agentii individuali;

Import/Export Centralizatoare : sunt oferite functii care permit importul si exportul bazelor de date de la nivelul sucursaleor si agentiilor;

Administrarea Daunelor : sunt puse la dispozitie functii care permit: Avizari, Plati, Incasari, Regrese de daune si Referate pentru compensare;

Nomenclatoare: sunt prezente urmatoarele nomenclatoare: Asigurati, Agenti,Activitati, Grupuri, Tipuiri de Daune, Tipuri de Scrisori, Marci Autovehicule, Categorii Autovehicule, Prime RCA, Persoane, Judete;

Editare rapoarte: exista o multime de rapoarte cu privire la Asigurati, Borderouri, Carnete de Polite, Daune, Polite, Situatii operative diverse, Reasigurare, Liste de Erori, etc.;

Valute: cuprinde Nomenclator de valute, Conversii valute individual sau in bloc, Modificari curs;

Utilitare : sunt functii de generare a Notelor contabile cu privire la prime si reasigurari, functii de import/export polite precum si functii de adminstrare drepturi utilizatori;

Administrare sistem: sunt functii de reindexare BD si modificare parola administrator;

Vizualizari: se refera la proceduri de cautare de Polite, Asigurati, Carte Verde si Numar de Inmatriculare

Caracteristici:

Produsul este implementat la toate sucursalel si agentiile Grup AS si fucntioneaza atat stand-alone, sub MS-DOS, cat si in retea NETBEUI sau TCP/IP, sub WIN NT 4.0 SERVER.

Functiile sistemului sunt acesate prin intermediul unui meniu din care sunt alese diversele optiuni corepunzatoare functiilor de sistem descrise anterior. Acest meniu trebuie utilizat numai de personal instruit anterior. Adminstrarea sistemului este foarte slaba containd in reindecari periodice ale Bazei de date FOXPRO.

Datele sunt deosebit de vulnerabile intrucat folderul ASIG (pe NT 4.0) ofera depturi totale de acces la program; in cazul in care dreptul de acces este READ-ONLY, programul genereaza o eroare fatala. (COULDN'T CREATE THE WORKSPACE).

Extinderea programului este la dispozitia exclusiva a celor din firma SOFTEH care a realizat sistemul si de aceea crearea de noi rapoarte utilizator este imposibila.

Sistemul nu mai functioneza in cazul in care numarul de polite depaste 100.000 pe an ceea ce s-a si inatmplat in anul 1999.

Utilizatorii sistemului

Produsul se adreseaza celor care lucreaza in asigurarile Grup AS, fie ei inspectori, agenti sau simpli operatori. Fiecare operator are un cod specific care se inregistreaza in fiecare instanta a unei polite completate de acesta.

Distribuirea produsului

La nivelul sucursalelor si al agentiilor, produsul a fost distribuit fara a se tine cont de cerintele specifice fiecarui tip de utilizator si fara un set de documentatie corespunzator.

2.2. Restrictii functionale, organizationale si economice

Datorita caracteristicilor speciale ale bazei de date FOXPRO nu sunt posibile, printre altele:

Modificarea formelor de intrare pentru a oglindi transformarile suferite de o polita pe o linie de asigurare;

Definirea de noi forme de polite corespunzatoare unor decizii operative cu privire la noi linii de asigurare;

Definirea de rapoarte conform legii (vezi. Raportul cu privire la Inceperea Activitatii, parg. 2.1);

Crearea de rapoarte ad-hoc;

Analiza statistica a datelor pin tehnici de tip data warehousing;

Alte restrictii majore ale aplicatiei existente se refera la lipsa procedurilor de backup precum si a procedurilor de asigurarea securitatii si confidentilitatii datelor.In consecinta, produsul existent nu respecta in foarte mare masura cerintele unui produs modern TI.

2.3. Stadiul informatizarii Grup AS

Actualmente, informatizarea Grup AS are urmatorii parametrii:

Y      In privinta dotarii Grup AS SA cu o platforma hard-soft care sa suporte exploatarea Sistemului de Asigurari s-au intocmit planuri de perspectiva care sunt descrise in Contractul de Colaborare ICI-Grup AS. Deja, au fost achizitionate o mare parte din licentele SQL Anywhere Studio 7.0 necesare si a fost restructurata reteaua de calculatoare pentru a putea conecta pana la 100 de sisteme.

Y      Se poarta tratative cu firma SOFTECH pentru a sprijini efortul de realizare a sistemului de asigurari si ca o extindere solida si semnificativa a vechiului sistem. Echipa RELANSIN se va concentra pe realizarea unei versiuni WWW a sistemului. Cheltuielile vor fi suporate de Grup AS.

Y      Personalul de specialitate este nesemnificativ dar conducerea Grup AS are in vedere rezolvarea acestei chestiuni in cursul anului 2000;

Y      Legaturile prin comunicatii software cu unitatile locale sunt inexistente. Este necesara gasirea unei solutii in aceasta problema, chiar prevederea ca Grup AS sa devina INTERNET provider pentru reteaua sa teritoriala. Fara rezolvarea acestei probleme fundamentale este imposibila crearea unei baze de date integrale a sistemului de asigurari.

2.4. Evolutii preconizate pe termen scurt:

Y      Din punct de vedere al cadrului legal sunt asteptate Normele Metodologice pentru Aplicarea Legii 32, care s-ar putea sa produca schimbari in abordarea sistemului de asigurari;

Y      De asemenea, este iminenta crearea Serviciului de Tehnologia Informatiei de Asigurari care va cuprinde personal specialzat atat in domeniul asigurarilor cat si in dezvoltarea de sisteme cu baze de date relationale;

Y      Sunt in curs analize asupra solutiei de comunicare ce trebuie alese pentru sistemul de asigurari, in conformitate cu cerintele tehnice exprimate in Termenii de Referinta - AOA.

3.1. Obiectivele sistemului

Obiectivele tehnice principale pe care trebuie sa le atinga sistemul sunt:

sa permita administrarea portofoliului de asigurari.

sa asigure rapoarte detaliate despre diferite aspecte ale portofoliului de asigurari:

sa asigure functii de administrare a sucursalelor, agentiilor si a agentilor individuali

sa fie intefatat cu sistemul financiar-contabil existent

sa fie extensibil la nivel de interfata adica, sa permita fie introducerea facila de noi forme corespunzatoare unor noi linii de asigurari, fie modificarea unora existente si sa permita introducerea, modificarea, stergerea de rapoarte conform cerintelor de moment ale utilizatorului.

sa ofere un tablou de bord pentru manageri, integrat în INTRANET-ul companiei;

sa asigure functii de analiza statistica a tendintelor portofoliului de asigurari pe tipuri de polite si regiuni;

sa ofere un pachet bogat de functii de analiza de risc: printre acestea: sa poata masura gradul de expunere a companiei în cazul aparitiei unui cutremur, inundatii, catastrofe umanitare, etc.;sa ofere instrumente de evaluare a riscurilor tehnice si investitionale; sa ofere functii de calcul a primelor de asigurare pentru riscuri asigurate sau asigurabile;

sa fie usor de adaptat la reglementarile în continua schimbare ale pietei de asigurari.

Obiectivele 4 si 8 nu vor fi abordate in acest proiect.

3.2. Arhitectura sistemului

Sistemul de Asigurari bazat pe INTERNET este compus din:

Y           Baza de Date SYBASE centrala, integrala situata la Sediul Central al companiei Grup AS (Adaptive Server Enterprise 11.9.2);

Y           Un server de aplicatii furnizat de PowerDynamo pentru intefata cu WEB SERVER-ul ales (CGI, WIN-CGI, ISAPI sau NSAPI)

Y           Bazele de date locale care sunt replicate pe Baza de Date Centrala;

Y           Situl de Asigurari care ofera functii de nucleu INTERNET care acopera obiectivele anteror descrise;

ORACLE DESIGNER va fi utilizat pentru generarea modelului fizic al bazei de date SYBASE; ulterior, pentru generarea sistemului vor fi utilizate atat instrumente specifice SYBASE, cum ar fi PowerDynamo, cat si editoare de sit-uri ca MS Front Page 2000 precum si NetObject Fusion 5.0 ( a carui licenta trebuie achizitionata).

3.3. Componentele sistemului de asigurari

Conform Termenilor de Referinta - AOA sistemul de asigurari va fi compus din urmatoarele subsisteme:

Contractul de asigurare este un contract prin care una din parti, numita Asigurator, se angajeaza sa plateasca o suma de bani în momentul producerii unui eveniment viitor si incert, în schimbul platii de catre cealalta parte, numita Asigurat, a unei sume determinate. Pentru a se incheia un Contract de Asigurari este necesara parcurgerea unui numar de pasi obligatorii, si anume:

a)      Completarea unei Cereri de asigurare. E un chestionar întocmit de Asigurator pentru uzul Asiguratului; acest chestionar se refera la descrierea riscului si la garantiile cerute.

b)      Scrisoarea de confirmare a cuprinderii în asigurare. E un document semnat de Asigurator si Asigurat, care acorda la data precizata în el, garantia asigurarii, înainte ca polita sa fi fost emisa. Are în general o durata limitata (cel mult 2 - 3 luni).

c)      Polita. E documentul care cuprinde conditiile generale si particulare ce guverneaza contractul de asigurare. Ea contine acordul celor doua parti contractante asupra elementelor constitutive ale contractului. Se poate spune ca polita e instrumentul obisnuit de proba. În general, data semnarii politei dovedeste momentul când a intrat în vigoare contractul. Dar se poate întâmpla ca o polita sa aiba pe lânga data semnarii contractului, o data diferita si anume pe cea a intrarii în vigoare a contractului. Polita contine prima de asigurare si transele de plata convenite.

d)      Anexa, clauza speciala - e un document care constata modificarile intervenite în contract sau derogarile de la conditiile generale de asigurare. Face corp comun cu polita si este un element indispensabil.

Un Contract de Asigurari poate fi intruna din urmatoarele stari:

In derulare;

Suspendat;

Terminat

Reziliat;

Functiile de administrare a Contractelor de Asigurari sunt:

Crearea, Modificarea, Stergerea, Arhivarea unui Contract, inclusiv proceduri batch;

Cautarea multi-criteriala a unui Contract (asigurat, periode de timp, zone geografice, agentii, riscuri asigurate, daune platite, valoare prima, valoare asigurata);

Diferite calcule statistice asupra unor submultimi de Contracte formate conform unor criterii prestabilite sau ad-hoc;

Politele sunt documente inseriate cu regim special care sunt gestionate centralizat la Centrala Grup AS. Fiecare sucursala , agentie sau agent de asigurari care depinde direct de Centrala, primeste un carnet de Polite avand asociat un domeniu de numere unic. Numarul unei polita incheiate de catre un agent va fi trecut intr-un borderou care va fi trimis catre nivelul imediat superior celui care a incheiat polita.

Functiile de gestionare a politelor sunt:

Crearea, modificarea,stergerea, arhivarea unui carnet de Polite (domeniu de numere unice ), inclusiv proceduri batch;

Cautarea multi-criteriala a unei Polite sau Carnet de Polite (pe sucursale, agentii, agenti individuali, zone geografice, etc.);

Asocierea intre un set de Boderouri si un set de Polite;

Asocierea dintre un Contract de Asigurare si o Polita;

Dauna este evenimentul prevazut în contract si susceptibil de a provoca prestatia societatii de asigurari. Asiguratul completeaza o declaratia de dauna, eventual completate cu o ancheta, sa se stabileasca daca acest eveniment si consecintele lui sunt garantate prin polita de asigurare. Daca da, se trece la realizarea prestatiei promise, dupa ce se determina valoarea daunelor printr-o constatare sau, daca este cazul, printr-o expertiza.

Functiile de adminsitrare a daunelor sunt:

Crearea, stergerea, modificarea si arhivarea Declaratiilor de Daune, inclusiv proceduri batch;

Crearea, stergerea, modificarea si arhivarea Rapoartelor de Ancheta, de Constatare sau de Expertiza corespunzatoare unor Declaratii de Daune;

Asocierea unui Contract de Asigurari cu o Dauna;

Calcule statistice referitoare la Daune ( pe riscuri produse, pe linii de asigurare, pe zone geografice, sucursale sau agentii);

Intre unitatile Grup As exista doua fluxuri de informatii:

De jos in sus, de la nivelele inferioare catre nivelele imediat superioare , circula mai ales Politele (incheiate sau anulate) si Borderourile;

De jos in sus, sunt replicate la nivelele superioare Bazele de Date de la nivele inferioare, astfel incat sa existe in orici moment (cu o intarziere de una-doua zile) o Baza de Date Integrala;

De sus in jos, circula Carnetele de Polite, Listele cu modificari de Constante de Asigurari precum si Documente Operative emise de Conducerea Grup AS;

O chestiune foarte importanta este cea securitatii si confidentialitatii datelor. In privinta securitatii datelor, chiar daca Replicarea SYBASE este suficient de "sigura" se va concepe o procedura de rezerva prin care datele vor fi containerizate si encripate printr-o algoritm de incriptare sigur si utilizabil fara licenta, cum ar fi Blowfish, si vor fi transmise utilizand posta electronica uzuala. De asemenea, confidentialitatea datelor unui client va putea fi "asigurata" prin utilizarea algoritimului Blowfish la incriptarea, spre exemplu, a Codului Fiscal sau a Codului Numeric Personal al clientului.

Functii de tranfer de date intre nivelele Grup AS

Creare, Modificare, Stergere si Arhivare Borderouri, inclusiv proceduri batch;

Import/export seturi de tabele din Baza de Date;

Creare, Modificare, Stergere si Arhivare Containere de Date (mai curand recipisele asociate, care arata mersul Containerelor prin reteaua Grup AS);

Incriptare/Decriptare Containere de Date sau Chei Primare;

Functii de control a securitatii (schimbari de chei de incriptare, regenerari, teste de securitate, etc.);

aasss

Asigurati, actuali sau potentiali, sunt inscrisi intr-un Registru de Asigurati care se afla la fiecare unitate operativa Grup AS. Catre asiguratii din Registru sunt trimise Oferte de Asigurari avand un continut dependent de "profilul" clientului.

Functiile de administrare sunt:

Crearea, Modificarea, Stergerea si Arhivarea unei intrari in Registru, inclusiv proceduri batch;

Crearea, Modificarea, Stergerea si Arhivarea unei Oferte de Asigurari asociate unui client sau "profil" de client;

Urmarirea unei Oferte de Asigurari, inclusiv corespondenta cu clientii;

Cautari multi-criteriale a Asiguratilor (pe profile de activitate, pe asigurari incheiate, riscuri asigurate, daune platite, oferte trimise, etc.)

Contrulul integral presupune atat verificarea permanenta a indicatorilor economico-financiari specifici activitatii de asigurare, cat si controlul activitatii personalului de asigurari.

In primul caz, sunt necesare cel putin urmatoarele rapoarte:

Centralizatorul asigurarilor facultative:

Centralizatorul asigurarilor RCA;

Situatia incasarilor si platilor aferente OSAAR;

Situatia profilului de risc pentru diferite linii de asigurari;

Structura portofoliului de asigurari si a rezervelor de prime;

Centralizatorul daunelor avizate pentru asigurari facultative;

Centralizatorul daunelor achitate;

Evidenta ofertelor de asigurari, politelor/tichetelor de tip CASCO

Politele cu limitele de competenta depasite ;

In mod sigur, aparitia Normelor Metodologice de Aplicare a Legii 32 va impune calculul si al altor indicatori de asigurari.

In cazul controlui activitatii personalului de asigurari se intreved cateva directii de atac, cum ar fi:

Acordarea de roluri tuturor actorilor din Sistem;

"Semnarea" fiecarei operatii cu codul asociat operatorului respectiv;

Jurnalizarea tuturor operatiilor efectuate asupra bazei de date;

Intocmirea de rapoarte cu privire la tipuiri de accese, tabele accesate, informatii modificate sau sterse, etc.

Principala grija care trebuie avuta in vedere este ca implementarea acestor controale sa nu impieteze asupra eficientei in utilizare a sistemului sau, in cazul in care cerintele de control sunt imperative, sa se pastreze un prag rezonabil de ineficienta.

Functia de control integral va fi implementata in cadrul INTRANETULUI companiei ca un tablou de bord pentru conducerea operativa si va cuprinde interfete grafice sugestive precum si legaturi cu suita MS OFFICE (Excel, Word, eventual Access);

In acest context trebuie concepute functii de help-desk prin care personalul de asigurari sa aiba acces la informatii cum ar fi:

Activitatea generala de asigurari (norme executive, documente operative, circulare, nomenclatoare, etc.);

Proceduri privind utilizarea sistemului, structurate pe roluri, subsisteme, functii de asigurari, s.a.;

Link-uri catre site-uri utile si intersante de asigurari;

Intrebari si Raspunsuri

Noutati in domeniu.

Functia de asistenta va fi implementata in cadrul Site-ului Grup AS.

Pentru asistenta clientilor va fi conceput un Portal special in cadrul site-ului de asigurari, prin intermediul caruia clientii Grup AS, actuali sau potentiali, care vor putea fi informatii cu privire la liniile de asigurare practicate de Grup AS, nivelul primelor, facilitati contractuale, etc.

Aceasta functie are drept scop importul bazei de date a sistemului existent si este aplicata o singura data in viata noului sistem de asigurari. Pentru implementarea acestei functii trebuie concepute proceduri SQL care sa importe, prin intermediul ODBC, datele "interesante" din baza de date existenta si sa le introduca in noua baza de date.

Functiile de administrare a bazei de date se refera cel putin conceperea de proceduri pentru :

salvarea/restaurarea a datelor;

refacerea din incident;

masurarea si controlul a starii a bazei de date;

"acordul fin" a performantelor bazei de date;

asigurarea a securitatii si confidentialitatii datelor;

3.3. Evaluarea fezabilitatii organizationale, tehnice si economice a sistemului; conditionari

Exista o serie de chestiuni care afecteaza direct fezabilitatea sistemului si care au fost adresate in Raportul privind Inceperea Activitatii, si anume:

Datorita aparitiei foarte recente a Legii 32/2000 privind societatile de asigurari si nepublicarii Normele Metodologice asociate, managementul portofoliului de asigurari nu este inca pe deplin clarificat la nivelul conducerii Grup AS.

In staff-ul Grup AS exista anumite rezerve cu privire la conceptia Sistemului de Asigurari, contrapunand acesteia sistemul Fox Pro existent. Intrucat aceaste rezerve provin mai mult de la personalul care lucreaza nemijlocit cu sistemul actual este necesara definirea unei strategii persusive care sa prevada anumite compromisuri intre sistemul exsistent si cel nou.

Membrii echipei de proiectare din Grup AS au si alte sarcini specifice legate de activitatea de asigurari si in unele perioade ale proiectului nu vor putea fi disponibili (de ex. in campaniile publicitare sau in perioadele in care sunt incheiate asigurarile obligatorii de raspundere civila). In aceste circumstante trebuie ca:

Sa existe o lista cu persoane de inlocuire disponibile avand aceeasi expertiza cu persoanele din echipa de baza;

Planificarea de proiect sa evite alocarea sarcinilor complexe in perioadele respective;

Lipsa unui Serviciu de Tehnologia Informatiei de Asigurari va pune probleme de intelegere a functionarii sistemului existent si a structurii bazei de date a acestuia;

Baza de date tinta trebuie sa fie Adaptive Server Enterprise 11.9.2 de la SYBASE.

Metodologia si instrumentele de proeictare trebuie sa fie CDM si, respectiv, ORACLE DESIGNER 6.0 pentru care ICI are licente de utilizare.

Nu este implementata inca o solutie de comunicatie intre Unitatile Organziatorice Grup AS.

Nu este inca semnat Acordul de Colaborare cu firma SOFTECH srl in vederea migrarii bazei de date a sistemului existent catre noul sistem;

Achizitia platformei hard-soft este partial finalizata.Totusi, cumpararea serverului de date si aplicatii nu este inca angajata.

Termenul de prototip de sistem sau proiect pilot, asa cum este utilizat in acest document, este definit ca orice cale prin care se poate demonstra corectitudinea abordarii alese de proiectare a sistemului. In multe cazuri este luata in considerare o implementare initiala, care are drept scop de a demonstra fezabilitatea abordarii proiectului. Aceasta se poate implementa in doua etape:

Etapa I consta in implementarea unei aplicatii demonstrative simple pentru uz intern si care va oferi o vizualizare timpurie a modului in care sistemul arata si opereaza.

Etapa II are in vedere o mplementare mai detaliata si care are drept scop o evaluare cuprinzatoare asupra aritecturii tehnice, trafcului de date intre nivele si reactia utilizatorului.

Prototipurile de sistem pot fi utilizate pentru a atinge o variatate de scopuri diferite, cum ar fi:

Testarea modificarilor majore ale unui sistem existent;

Explorarea utilizarii unor noi tehnologii pentru a indeplini sarcinile maim rapid si mai economic;

Cresterea rolului utilizatorului in definirea noilor cerinte ale sistemului;

Implicarea utilizatorului in dezvoltarea cerintelor de sistem care va duce in ultima instanta la servicii de maintenanta si exploatare de foarte buna calitate.

In contextul metodologiei ORACLE CDMFT procesul de testare este o abordarea integrata pentru testarea calitatii tuturor elementelor sistemului. El include atat testarea modulelor functionale, cat si integrarea modulelor orientate spre afacere precum si testarea de integrare a sistemului si cea de acceptare.

Tesarea orientata pe afacere este condusa prin intermediul Modelului de Proces in scopul de stabili o legatura inversa cu cerintele afacerii.

Obiectivele procesului de testare sunt:

Stabilirea unei abordari de testare care ghideaza in mod natural cerintele de testare in activitatile de proeictare asociate;

Introducerea timpurie a activitatiilor de testare in ciclul de viata a produsului;

Construirea si reutilizarea livrabilelor de testare in toate fazele procesului de testare;

Producerea de sisteme de buna calitate si corespunzator testate;

Initial, sunt identificate cerintele de testare care vor fi actualizate pana la sfarsitul proiectului. De exemplu, scenariile de functionare a afacerii de informatizat identificate in timpul modelarii de Proces vor contribui la testarea modulara, de integrare, de sistem si de integrare de sistem. Modelarea functionala procduce cerinte de testare specifice functiilor de sistem elementare. De asemenea,aceste cerinte vor contribui la planificarea testarii modulelor atunci cand functiilor de sistem elementare le sunt asociate module.

Standardele pentru Definirea Interfetei Utilizator produc a lista de verificare a testelor de interfatare care va fi validata in cursul testarii de module. Procesul de Examinare a Sistemului Existent contribuie la documentarea scenariilor afacerii, cerintelor de testare a interfetelor sistemului si la dezvoltarea de abordari de testare alternative. In sfarsit, procesul de Conversie a Datelor permit o evaluare a datelor existente si o apreciere "volumetrica" a acestora, lucruri foarte utile in procesul de testare a sistemului in conditii de exploatare.

Livrabilele cheie ale Procesului de Testare sunt:

Planul de Testare a Sistemului: care include toate informatiile necesare pentru a planifica, pregati si conduce procesul de testare a sistemului;

Planul de Testare de Integrare a Sistemului: care include toate informatiile necesare pentru a planifica, pregati si conduce testarea de integare a sistemului;

4.1. Factori de Succes pentru Proiectul Pilot

Implicarea utilizatorului in realizarea, implementarea si administrarea sistemului pilot este cruciala. Exploatarea sistemului pilot confera utilizatorilor o buna ocazie de a vedea sistemul la lucru si de a putea furniza realizatorilor intrari aditionale privind cerintele. Schimbarile si corectiile facute in timpul dezvoltarii proiectului pilot vor asigura sistemul final va respecta cat mai mult posibil cerintele utilizatorilor finali.

O data ce sistemul intra in faza de testare pilot, este esential sa se intretina un dialog permanent cu utilizatorul, ceea ce va indica programatorilor care sunt prioritatile importante ale acestuia. Periodic (de ex., lunar) utilizatorul este informat care un prioritatile curente si cand deficienta raporata va fi ridicata. De asemenea, utilizatorul va fi informat in legatura cu celelate deficiente care au fost rezolvate intre timp.

Problemele cu Instruirea trebuie identificate in mod corespunzator. Utilizatorii finali necesita o instruire adecvata pentru utilizarea corespunzatoare a noului sistem. In unele situatii este necesara o instruire interna inainte de completarea platformei hard/soft sau a realizarii aplicatiei.

Exploatarea sistemului va putea facilita identificarea unor cerinte de instruire neanticipate.

Respectarea planului de realizare asigura credibilitate din partea utilizatorilor, conducerii clientului si gestionarea efciace a bugetului de venituri si cheltuieli al organizatiei. In unele cazuri, evenimente neanticipate pot duce la intarzieri in graficul de executie si este recomandabil ca acestea sa fie aduse fara intarziere la cunostinta clientului. Dac este posibil este recomandabila utilizarea eficeienta a modelelor de management de proiect (in cazul de fata, ORACLE PJM) care ajuta in a prevedea impactul schimbarii unui element de proiect asupra graficului de realizare.

Este important sa fie anticipate problemele care pot aparea si care sunt in afara controlului grupului de lucru. De exmplu, o problema poate fi data de diferitele versiuni de sistem de operare (in cazul nostru, chiar diferite versiuni de Service Pack-uri ) utilizate. In aceste cazuri sunt necesare cicluri de testare aditionale pentru a asigura ca difertile versiuni de sisteme de operare nu afecteaza negativ aplicatia.

Alte probleme pot aparea din schimbarile din mediul de comunicatii. Adesea, este dificil de determinat daca problemele utilizatorului provin din softwareul de aplicatie sau din mediul hardware. Rezolvarea acestei dificultati poate avea un impact major asupra furnizarii de servicii adecvate de help-desk catre locatii departate ale retelei.

De asemenea, trebuie anticipat volumul de timp alocat activitatilor nelegate direct de sistem.

In planul de testare a proiectului pilot trebuie introdusa o metodologie de colectare a informatiilor necesare pentru masurarea obiectivelor stabilite

Un plan al proiectului care impune o abordare de testare integrata;

Conceperea planurilor de testare a modulelor care sunt componente integrante ale activitatilor de testare subsecvente;

Independenta Testarii modulelor de Testarea de acceptare pentru toate activiattile de testare implicate

4.2. Cerintele prototipului de sistem de asigurari

In conformitate cu Termenii de Referinta - AOA si Raportul privind Inceperea Activiatatii, prototipul de sistem va include stabilirea unei arhitecturi si a procedurilor de administrare a bazei de date, care sa permita obtinerea unor informatii cu privire la Polite de Asigurari, Clienti, Rata Primei, etc. precum si statistici esentiale referitoare la activitatea de asigurari.

Prototipul de sistem va fi proiectat si implementat impreuna cu personalul Grup AS, in concordanta cu cerintele legale si reglementarile privind activitatea de asigurare/reasigurare.

Proiectul pilot trebuie sa acopere in mod adecvat unitatile de la nivel local, astfel incat procedurile si aplicatiile necesare sa fie proiectate si testate pentru a asigura fluxul necesar si permanent de informatii intre baza de date centrala si unitatile locale . In

afara bazei de date centrale, prototipul de sistem trebuie sa acopere cel putin doua unitati teritoriale ale Grup AS SA. Aceste unitati locale vor fi stabilite de catre Grup AS intr-o faza ulterioara, si comunicate expertilor ICI in momentul stabilirii planului de actiune.

Prototipul de sistem trebuie, in mod necesar, sa acopere, de asemenea, aspecte TI specifice asigurarilor referitoare la unitatile teritoriale, cu scopul de a pregati in mod adecvat terenul pentru extinderea la nivelul intregii retele Grup AS pe plan national a proiectului pilot functional pentru Sistemul de Asigurari.

Prevederile capitolului 3.2 ("Amendamente la Termenii de referinta") si, de asemenea, rezultatul Studiului de fezabilitate, ar putea sa determine reconsiderarea activitatilor/sarcinilor mai-sus mentionate.

Ca rezultat al activitatii echipei mixte la momentul de la care incepe proiectul, structura bazei centrale de date ar putea fi deja extinsa si/sau optimizata, in scopul de a include, de o maniera consistenta:

Y           structuri de date suplimentare din sursele de date interne/ externe, identificate pe durata studiului de fezabilitate;

Y           cerintele de informatii specifice aplicatiilor care sunt dezvoltate in perioada dintre Studiul de fezabilitate si demararea prototipul de sistem.

Pentru a asigura succesul prototipul de sistem, structura bazei de date ar trebui "inghetata" la inceputul acestei activitati ca versiune initiala 0.1. Din acest moment, orice modificare ulterioara la aceasta structura va fi efectuata conforma procedurilor de management al controlului schimbarilor. Decizia privind implementarea acestora in prototipul de sistem se va baza pe o analiza atenta a impactului lor asupra resurselor de timp si umane necesare.

Testarea bazei de date pe durata proiectului ar trebui sa fie realizata utilizand mediul de lucru pentru una din aplicatiile de asigurari selectate, care ar trebui sa fie finalizata la momentul demararii prototipul de sistem.

In concordanta cu concluziile experimentarii prototipului de sistem va fi pregatit un raport, care va sintetiza concluziile proiectului si va face recomandari asupra posibilelor schimbari, inainte ca sistemul de asigurari sa fie extins la nivelul intregii retele nationale Grup AS.

Pe baza acestui raport, se va finaliza planul de extindere a sistemului de asigurari la nivelul intregii retele Grup AS si se vor definitiva urmatoarele activitati:

Y           proiectarea arhitecturii bazei de date

Y           proiectarea procedurilor automate

Y           amendamente la procedurile manuale proiectate anterior

Y           protocolul privind testele de acceptanta si testarea sistemului

Y           instalarea sistemului.

Pe baza necesarului de documentatie desprins din Studiul de fezabilitate, se va asigura, suplimentar:

Y           Realizarea si distribuirea manualelor tehnice detaliate pentru personalul TIA si din unitatile de la nivel local ale Grup AS SA.

Y           Realizarea si distribuirea, catre utilizatorii finali, a procedurilor si manualelor detaliate, precum si manuale pentru utilizarea bazei de date si a aplicatiilor incluse in sistemul de asigurari.

Ca suport principal pentru completarea obiectivului de transfer de tehnologie, activitatile de instruire ar trebui sa se adreseze tuturor topicilor legate de domeniul asigurarilor/reasigurarilor. Acestea includ:

Y           organizarea Portalului de Asigurari pentru asistenta clientilor si a personalului TIA;

Y           proceduri referitoare la administrarea portofoliului de asigurari;

Y           organizarea campaniei de informare, inclusiv suportul de web;

Y           administrarea bazei de date de asigurari;

Y           proceduri de salvare/restaurare;

Y           proceduri de control integral a activitatii de asigurari;

Y           proceduri de securitate si asigurarea confidentialitatii;

Luand in considerare resursele limitate ale proiectului, continutul acestor activitati va trebui sa fie stabilit in stransa relatie cu necesitatile identificate ale Grup AS, referitoare la personalul-tinta si necesitatile prioritare ale acestuia. De asemenea, instruirea personalului ar trebui sa fie orientata catre nucleul de baza, in fiecare domeniu, in concordanta cu abordarea tip "instruirea instructorilor".

Trebuie identidicate riscurile si defintie cerintele generale de securitate, definite politici de abodare a acestora precum si stabdarde de implementare a politicilor.

Succint, cerintele de securitate include:

Autorizarea modul in care se poate determina daca utilizatorii sunt ceea ce pretind ca sunt. Se implementeaza prin: ID utilzator si parole, certificate digitale si biometrici (amprente, retina,etc);

Protejarea activelor: modul in care datele confidentiale sunt protejate. Sunt incluse aici: asigurarea confidentialitatii si integritatii datelor precum si autentificare originii conexiunii. Se implementeaza prin utilizarea unor tehnologii de autentificare si incriptare bazate pe Chei Publice, cum ar fi: protocoale SSL, S/MIME, SET. In cazul nostru vor fi folosite intensiv resursele de securitate puse la dispozitie de Serverul SYBASE, Adaptive Server Enterprise 11.9.2.

Contabilizarea acceselor: modalitatea prin care se poate verifica impactul asupra sistemului al unui utilizator oarecare;

Administrarea: definirea se implementarea unor politici de securitate si asigurarea ca acestea sunt consistente dealungul tuturor aplicatiilor, sistemelor, platformelor si retelelor;

Increderea in sistem: modul prin care se asigura faptul ca sistemul respecta cerintele de securitate impuse. Se implementeaza prin: separarea fizica si logica de INTERNET a mediului intern, detectarea intrusilor, detecatarea virusilor

Disponibilitatea: felul in care se asigura functionarea neintrrupta a sistemului atat in cazuri unor atacuri distructive, cat si in cazul modificarilor necesare asupra aplicatiilor, hardware-ului, retelei. Se implementeaza prin: balansarea cererilor intre HTTP, FTP sau altele asemenea, replicarea pe WEB, proceduri de salvare/restaurare, recuperarea cheilor pierdute, furate, etc. de catre persoanele care le pot detine.

In cazul sistemului de asigurari bazat pe INTERNET au fost deocamdata identificate unele riscuri de securitate, cum ar fi:

Fluxul de informatii pe INTERNET, incluzind parolele si datele firmei, nu este sigur;

Politica: asigurarea unei legaturi sigure intre Grup AS si utilizatori;

Implementarea standard: tot traficul de retea dintre Grup AS si utilizator trebuie protejat prin utilziarea ce putin a protocolului SSLv3;

Persoane fara scrupule pot incerca sa acceseze datele Grup AS incercand combinatii ID/Parole pentru a impersona un utilizator existent;

Politica - asigurarea ca sistemul poate determina ca utilizatori sunt ceea ce pretind ca sunt;

Implementarea standard: realizarea unei autentificari mutuale tari utizand Chei Publice. Daca este posibil, furnizarare de smart cards cu certificat si cititoare de smart cards catre toti utilizatorii care sunt inscrisi in acest servici.

"Spargatorii" pot incerca sa atace si penetreze reteaua Grup AS, si infecta sistemul cu un virus, etc.

Politica - protejarea retelei Grup AS si, daca este posibil, utilizatorul, de o potentiala intruziune si atac.

Implementare standard: furnizarea unui software antivirus atat pe reteaua Grup As cat si la utilizatorii care semneaza pentru acest servici; instalarea software-lui antivirus si de detectare a intrusilor in Grup AS Provide antivirus software for end users who sign up for the service.

In plus, trebuie adresate cerinte de securitate specifice aplicatiilor utilizate. Proiectarea aplicatiilor pentru a respecta cerintele de securitate trebuie sa urmeze niste standarde, cum ar fi IBM Application Framework for e-business. In acest caz, proiectarea are urmatoarele caracteristici:

Utilizeaza modelul de aplicatii tri-partit (3-tier) cu un client HTML "subtire"

Utilizeaza JAVA ca o platforma de executie comuna pe retea;

Bazate pe aceasta arhitectura globala, deciziile de proiectare legate de securitate pot fi urmatoarele (sub rezerva aprobarii ulterioare de catre Grup AS):

Toate informatiile asupra utilizatorilor sunt stocate intr-un director centralizat, aflat pe INTRANET, in scopul de a micsora complexitatea si de a administra mai usor adaugarea si steergerea de utiliziatori.

Se utilizeaza un serviciu centralizat de autentificare pentru a facilita definirea si gestionarea politicilor de acces la programe, date si alte resurse. Acest serviciu rezida pe INTRANET;

Se utilizeaza o relatie de incredere intre sistemele folosite de catre aplicatie mai curand decat "inrolarea" utilizatorilor in sistemele existente;

Utilizatorului i se va cere sa se logeze in sistem o data si numai o data (single sign on).

Nu vor fi emise certificate de catre Grup As ci se va utiliza un partener care-o poate face;

Urmand IBM Policy Director Serviciul Central de Autentificare este configurat astfel:

Definirea setului de pagini WEB si a obiectelor pe care Directorul de Politici le va administra;

Inregistrarea utilizatorilor/grupurilor de utilizatori si a adminsitratroilor de sistem;

Definire politicilor de acces pentru paginile WE si obiecte

Adaugarea de asocierilor de credentiale cerute pentru implementarea politicii single sign on pe sistemele existente.

La sfarsitul proiectului, cand planul de extindere va fi fost realizat, va fi specificat planul final pentru dezvoltarea sistemului de asigurari. Acest plan va fi bazat pe experienta si progresele obtinute pe durata proiectului, si va necesita urmatoarele activitati:

Y        stabilirea diagnosticului in domeniile care ar trebui sa fie dezvoltate in viitor pentru cresterea eficientei sistemului de asigurari; aici, se pot avea in vedere metode de management al riscului bazate pe tehnici de data warehousing;

Y        selectarea optiunilor disponibile;

Y        analiza cost-beneficiu a fiecarei optiuni: evaluarea resurselor detaliate necesare pentru fiecare optiune, incluzand: buget/efort investitional, resursele financiare potential disponibile, necesitatile de resurse umane etc;

Y        prezentarea optiunilor disponibile catre pentru dezvoltarea viitoare a sistemului de asigurari, impreuna cu analiza cost-beneficiu a fiecarei optiuni.

O vedere mai detaliata a planului de dezvoltare a sistemului va deveni efectiva dupa faza de evaluare prototipului de sistem.