Specificații de proiectare ale funcționalităților suplimentare. Specificatii de proiectare...

Specificații de proiectare ale funcționalităților suplimentare

Asocierea S.C. Indaco Systems S.R.L și S.C. CCT S.R.L.

Unitatea Executivă pentru FinanŃarea ÎnvăŃământului Superior, Cercetării, Dezvoltării și Inovării (UEFISCDI)

28.10.2011

Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 2

Titlul Documentului: Specificații de proiectare ale funcționalităților suplimentare

Numărul Contractului: 30/25.05.2010

Data: 28.10.2011

Versiunea: 1.0

Statutul Documentului: forma finală

Număr de ieșire CCT: 1931 / 28.10.2011

Număr de înregistrare:

ELABORAT DE

Nume, FuncŃie Companie Dată Semnătura

Mihai Dascălu Coordonator implementare

CCT S.R.L. 28.10.2011

Ovidiu Iane

Coordonator tehnic

Indaco Systems S.R.L.

28.10.2011

PRIMIT DE

Nume, FuncŃie Companie Dată Semnătura

Gabriela Jitaru Manager de Proiect RMU

UEFISCDI ____________

Ion Gh. ROŞCA Coordonator Dezvoltare Sistem Informatic RMU

ASE București ____________

Gabriel Şutac Manager Proiect de dezvoltare aplicaŃie

ASE București ____________

Marius Nicolaescu Sef Serviciu Informatica UEFISCDI

UEFISCDI ____________


Cuprins

1 Introducere 5

2 Funcționarea în timp real a aplicației centrale RMU 5

2.1.1 Descriere generală 5

2.1.1.1 Replicarea în timp real 6

2.1.1.2 Logarea modificărilor la nivel local 7

2.1.1.3 Exportul semnat electronic 7

2.1.1.4 Cross-Validări 8

2.1.1.5 Gestiunea nomenclatoarelor 8

2.1.1.6 Update automat și centralizat al clientului de aplicație locală RMU 8

2.1.1.7 Gestiunea actualizărilor 9

2.1.1.8 Preluarea unor informații disponibile la nivel central direct în aplicația locală RMU 9

2.1.1.9 Aplicație locală RMU web-based 10

2.1.1.10 Comunicarea cu sistemele de gestiune a datelor privind studenții existente în universități10

2.1.2 Funcționalități asigurate 11

2.1.3 Arhitectura propusă 12

2.1.4 Etape implementare 13

3 Funcționalități suplimentare ale aplicației locale RMU 13

3.1 Gestiunea procesului de admitere în cadrul aplicației locale 13

3.1.1 Descriere 13


3.1.3 Flux informațional 14


3.2 Posibilitatea de a dezactiva anumite validări / constrângeri la nivel local 14

3.2.1 Descriere 14


3.2.3 Flux informațional 15


4 Modificări adiționale identificate în urma demarării operaționale 16

4.1 Modificarea structurii bazei de date RMU 16

4.1.1 Descriere 16


4.2 Tratarea excepțiilor constatate după demararea operațională 16


4.2.1 Descriere 16




Specificații de proiectare ale funcționalităților suplimentare

1 Introducere

Scopul acestui document este de a prezenta în detaliu specificațiile de proiectare aferente functionalitatilor suplimentare ale sistemului RMU solicitate în cadrul documentației descriptive anexate invitației de participare.

Astfel, urmatoarele facilitati, împreună cu arhitectura / fluxurile aferente, precum și etapele propriu-zise de implementare, sunt prezentate in cadrul prezentului livrabil:

- Funcționarea în timp real a aplicației centrale RMU

o Replicarea în timp real

o Logarea modificărilor la nivel local

o Exportul semnat electronic

o Cross-Validări

o Gestiunea nomenclatoarelor

o Update automat și centralizat al clientului de aplicație locală RMU

o Gestiunea actualizărilor

o Preluarea unor informații disponibile la nivel central direct în aplicația locală RMU

o Aplicație locală RMU web-based

o Comunicarea cu sistemele de gestiune a datelor privind studenții existente în

universități

- Funcționalități suplimentare ale aplicației locale RMU

o Gestiunea procesului de admitere în cadrul aplicației locale

o Posibilitatea de a dezactiva anumite validări / constrângeri la nivel local

- Modificări adiționale identificate în urma demarării operaționale

o Modificarea structurii bazei de date RMU

o Tratarea excepțiilor constatate după demararea operațională

2 Funcționarea în timp real a aplicației centrale RMU

2.1.1 Descriere generală

Scopul acestui serviciu este de a asigura că datele care au fost introduse în baza locală ajung într-un depozit central în timp real şi fără intervenția responsabilului cu exportul datelor de la nivelul fiecărei universități. Această funcționalitate va fi asigurată de o componentă care va fi instalată pe serverul local RMU şi care va asigura transferul informațiilor către serverul central RMU în mod automat.

Astfel, la nivel central trebuie construit un depozit central în timp real de date, care să mențină informațiile din anul curent de studii universitar.


Modul de lucru al universităților rămâne neschimbat. Informațiile introduse prin aplicațiile locale sunt stocate tot în baza de date locală, iar componenta de sincronizare online este responsabilă cu transferul automat al informațiilor către serverul central, fără a influența modul de lucru al operatorilor.

Datele sunt marcate pentru replicare în momentul în care sunt operate modificări, iar replicarea are loc periodic, exclusiv la nivelul datelor de tip ”dirty”. Avantajul acestui mod de transfer este faptul că utilizatorii care introduc date nu sunt influențați de conectivitatea prin Internet cu serverul central. Astfel, această conexiune poate să prezinte fluctuații în funcționare, dar transferul datelor nu este afectat de acest aspect; în momentul repunerii în funcțiune, toate modificările și datele aferente sunt replicate automat la nivel central.

Astfel, în contextul extinderii, depozitul de date în timp real este stocat într-un spațiu separat față de depozitul central RMU. Pe lângă aceasta, fiecare universitate are datele anului universitar curent replicate la nivel central, aspect care conferă un spor de siguranță în exploatare la nivelul întregului sistem RMU (văzut per ansamblu). Astfel, fiecare universitate are o imagine de backup a datelor locale la centru, aspect care sporește fiabilitatea sistemului.

La nivelul Portalului RMU, trebuie prezentată atât arhiva informațiilor din depozitul central RMU (din perspectivă istorică), cât și informațiile din depozitul în timp real, care reflectă situația actuală din sistem, fără a face parte integrată a unui export semnat și validat. Această agregare de informații este în primul rând relevantă la nivelul studenților care vor putea astfel să observe modificările în timp real la nivelul sistemului RMU.

În cazul în care o universitate nu dispune de infrastructura locală pentru o găzdui baza de date locală RMU, aceasta se poate conecta direct la nivel central, folosind clientul de aplicație locală RMU. Din perspectivă tehnică, la nivel central este instalat un sever Microsoft SQL Server 2008 pe o mașină cu Windows Server 2008 la care toate universitățile (care nu dispun de o bază de date locală) se vor conecta. Este în responsabilitatea fiecărei universități să asigure conectivitatea la Internet pe mașina pe care este instalat clientul RMU. Se recomandă ca transferul de date să fie realizat peste un tunel VNP pentru a asigura confidențialitatea datelor vehiculate. Toate mecanismele de replicare vor fi instalate și configurate pe această mașină, asigurând astfel funcționarea în timp real a clienților tuturor universităților conectați direct la baza central pusă la dispoziție de UEFISCDI.

Astfel, în vederea eficientizării lucrului și sincronizării aplicației centrale RMU cu instanțele locale, extinderea RMU presupune implementarea următoarelor funcționalități:

2.1.1.1 Replicarea în timp real

Din perspectivă tehnică, mecanismul de replicare este propriu aplicației RMU, facilitând trasabilitatea de la centru și reliefând istoricului de modificări. Toate modificările sunt marcate cu un flag de tip ”dirty” și un serviciu pornit automat pe serverul de baze de date local este responsabil cu transmiterea periodică a actualizărilor în depozitul central în timp real.

Astfel, un serviciu configurabil trebuie instalat pe serverul local cu baza de date RMU, responsabil cu transmiterea modificărilor la nivel central. Unul dintre parametrii acestui serviciu este periodicitatea cu care acesta transmite exclusiv modificările. Inițial, se pornește cu un interval de verificare de ordinul minutelor, acesta fiind redus treptat până la ordinul secundelor / aproape instantaneu. Pentru optimizarea acestui proces, trebuie alocată o perioadă de 1 lună, în care să fie ajustați parametrii și optimizată baza de date centrală pentru a asigura performanțe cât mai bune. Dezideratul vizavi de timpul de răspuns este de 10 secunde de la salvarea datelor în aplicația locală RMU până la finalizarea cross-validărilor și publicarea rezultatelor în aplicația locală. În funcție de performanțele sintetice obținute în perioada de fine-tuning, timpii admisibili de răspuns sunt definiți printr-un SLA.

Modificările transferate sunt la nivel de înregistrare / student. În urma validării înregistrării la nivel central, eventualele erori trebuie marcate corespunzător în aplicația locală, permițând astfel corectarea facilă a acestora de către operatorul din universitate.


În cazul în care se constată un timp excesiv de mare vizavi de răspunsul de la nivel central pentru cross-validări (de ordinul zeci de minute) sau dacă nu există conectivitate de la nivel local, utilizatorul are posibilitatea renunțării temporare la aceste validări, datele fiind replicate la nivel central imediat ce se restabilește conectivitatea și verificate apoi pentru conformitate. În cazul în care aceste date replicate ulterior contravin validărilor, ele sunt marcate în aplicația locală până la rezolvarea conflictului.

O componentă importantă la nivelul funcționării near real-time este cea de auditare a modificărilor, pentru care vor fi implementate rapoarte la nivel central utilizând Oracle BI pentru identificarea unor erori sau a unui comportament anormal.

Flux informațional:

2.1.1.2 Logarea modificărilor la nivel local

Un aspect important al funcționării real-time presupune asigurarea trasabilității modificărilor de la nivel local. Astfel, trebuie logate toate modificările înregistrate la nivel central prin replicarea automată a datelor de la nivel local.

Prin urmare, trebuie creată la nivel local o tabelă care memorează activitățile relevante ale utilizatorilor la nivel local minim sub forma (id_univ, id_user, id_student, operație_efectuată, timestamp), tabelă replicată la nivel central, în depozitul în timp real. De asemenea, prin intermediul componentei Oracle BI administratorul RMU sau managerii de universitate (strict la nivelul propriei instituții) pot realiza analize prin inspecția logurilor asupra comportamentului utilizatorilor locali.

2.1.1.3 Exportul semnat electronic

Asemănător funcționării actuale a sistemului, la nivelul exportului de date sunt folosite datele locale care sunt semnate folosind certificatul digital al fiecărei universități. Ținând cont că posibilele erori de validare au fost semnalate în prealabil, operația de export se realizează mult mai facil, nemaifiind necesare modificări care ar fi putut rezulta în urma validărilor de la centru. Înainte de exportul propriu-zis în depozitul de date, se certifică faptul că datele locale și cele replicate din zona în timp real sunt identice. Această verificare poate fi realizată facil întrucât concordanța dintre cele 2 baze de date este asigurată în momentul în care la nivel local nu mai există modificări care nu au fost transmise / replicate la nivel central.

În plus, în cadrul exportului, pe lângă datele curente, aferente anului universitar în curs, trebuie incluse și semnate electronic și logurile existente la nivel local. După realizarea cu succes a unui export, logurile locale sunt golite, reducând astfel semnificativ volumul de loguri de modificări cumulat în timp.

Flux informațional


2.1.1.4 Cross-Validări

Validările inter-universitare de la nivel central sunt rulate în timp real și erorile sunt semnalate direct în aplicațiile locale, în momentul salvării datelor. Prin acest mecanism se reduce considerabil timpul necesar corectării datelor, datorită semnalării timpurii, nu doar la export, a unor erori și inconsistențe. În plus, se poate asigura o monitorizare mult mai detaliată a traseului educațional al unui student, nu doar în momentele predefinite de export. Acest aspect permite identificarea unor posibile inadvertențe, imposibil de detectat prin raportarea exclusiv la momentele de realizare a exportului.

Flux informațional

2.1.1.5 Gestiunea nomenclatoarelor

Actualizarea nomenclatoarelor la nivel local trebuie să se realizeze automat și operația în sine să fie declanșată din aplicația locală RMU. Pentru autentificare sunt folosite credențialele de la nivel central, stocate în OAM.

Operația de actualizare a nomenclatoarelor este realizată automat la deschiderea aplicației și manual din meniul de administrare, de către Responsabilii de aplicație locală. Astfel, trebuie dezvoltat un serviciu de actualizare a aplicației locale RMU, care rulează local pe mașina pe care este instalat clientul aplicației.

În plus, la nivel central este creată o tabelă specială, în cadrul căreia sunt stocate toate modificările operate la nivelul nomenclatoarelor. În momentul publicării unei noi versiuni de nomenclatoare se generează automat un raport cu toate modificările întreprinse de la publicarea precedentă și tabela este golită.

2.1.1.6 Update automat și centralizat al clientului de aplicație locală RMU

Acest serviciu permite descărcarea automată, la nivel local, a noilor versiuni pentru aplicațiile locale.

La pornirea aplicațiilor locale de către operatori, este verificată existența unei noi versiuni a aplicației. În situația în care există versiuni noi, acestea sunt descărcate local.

În momentul raportării către depozitul central, pe lânga versiunea nomenclatoarelor, este verificată şi versiunea aplicației locale, care trebuie să fie ultima publicată la nivel central.

Pentru a putea schimba automat şi executabilul, este nevoie ca operatorul să aibă drepturi de scriere în folderul unde este instalată aplicația. Altfel, sistemul de operare refuză scrierea aplicației în folderul respectiv.

De asemenea, aplicația locală afișează un mesaj corespunzător de eroare în cazul în care operația de update a eșuat.


2.1.1.7 Gestiunea actualizărilor

Atât pentru actualizările aplicației locale RMU, cât și pentru nomenclatoare, la nivel central este disponibil un istoric al modificărilor versiunilor. La nivelul diverselor versiuni ale aplicației locale, textul cu privire la modificările întreprinse în noua versiune publicată este introdus manual într-o interfață dedicată, de către operatorul responsabil cu gestiunea și publicarea noilor versiuni. Istoricul nomenclatoarelor este constituit din raportul generat automat la publicarea unei noi versiuni de nomenclatoare, descris în capitolul 5.

Istoricul actualizărilor aplicației locale și ale nomenclatoarelor este disponibil direct din interfața aplicației locale RMU.

În momentul publicării unei noi versiuni (atât de nomenclatoare, cât și a aplicației locale), dacă utilizatorul este autentificat în aplicația locală, acesta trebuie înștiințat de apariția unei noi versiuni în interfața acesteia, printr-un mesaj de tipul ”O nouă versiune a aplicației locale RMU / de nomenclatoare a fost publicată”.

În plus, la nivel central sunt logate apelurile de actualizare la nivel de universitate pentru a avea un istoric al cererilor de actualizare și o evidență centralizată a actualității clienților RMU și a nomenclatoarelor. Asupra logurilor replicate la nivel central vor putea fi rulate rapoarte folosind Oracle BI.

2.1.1.8 Preluarea unor informații disponibile la nivel central direct în aplicația locală RMU

La nivel central trebuie creat un serviciu web care permite aplicației locale să verifice dacă un student există deja în sistem și, dacă da, să permită retragerea automată a datelor existente.

În primul rând, se permite utilizatorilor aplicației locale RMU să verifice, la cerere (prin acționarea unui buton din aplicație), dacă un student este sau nu deja introdus în sistemul RMU. În cazul în care el există deja în sistem, se întoarce numărul de ani de școlarizare la buget de care acesta a beneficiat pe fiecare nivel de studii (L, M, D). La nivel tehnic, verificarea se va face prin acțiunea explicită a utilizatorului, din aplicația locală RMU, după introducerea unui set minimal de date (ex. Nume, Prenume și/sau CNP).

În situația în care studentul a oferit în prealabil acces asupra datelor lui cu caracter personal prin intermediul Portalului RMU, utilizatorului din aplicația locală RMU i se oferă posibilitatea să importe automat, la nivel local, datele disponibile de la centru.

Selecția opțiunilor de import se realizează la nivel de instituție și studentului îi este permisă selecția individuală a instituțiilor pentru care dorește să facă vizibile informațiile.

Pe lângă datele personale existente în sistem și erorile generate prin rularea validărilor de la nivel central, aplicația centrală RMU publică la nivel local următoarele informații: apariția unei noi versiuni de nomenclatoare și existența unei perioade de raportare active. În acest context, față de versiunea


curentă, este modificată și aplicația locală RMU, pentru a interoga automat aceste noi servicii și pentru a transmite notificări corespunzătoare utilizatorului.

2.1.1.9 Aplicație locală RMU web-based

În vederea oferirii unei alternative viabile la clientul local RMU, care să nu necesite instalarea niciunei aplicații pe mașina utilizatorului din universitate, aplicația locală RMU trebuie să includă și o aplicație web dedicată, similară aplicației locale RMU, dezvoltată folosind tehnologia ActiveX. Aceasta este instalată pe serverul local RMU și este accesibilă prin intermediul unui browser (preferabil Internet Explorer, întrucât acesta trebuie să interpreteze corect controlul ActiveX). Serverul este configurat în conformitate cu politicile de securitate la nivelul rețelei din cadrul universității, astfel încât să existe flexibilitate la nivelul acessului la aplicația web. Astfel, aceasta poate să fie accesată exclusiv din Intranet, de la suită de IP-uri, sau liber din Internet, în funcție de configurarea serverului web la nivel de disponibilitate de acces din Internet sau din diverse locații.

Spre deosebire de aplicația windows-based locală RMU, aplicația web furnizează un set mai restrâns de funcționalități. Astfel, nu sunt incluse următoarele facilități de administrare:

- Administrare utilizatori; - Import din fișier XML; - Import din sistemul propriu; - Restaurează baza de date; - Export de date RMU.

Operațiile anterioare sunt asigurate prin intermediul unui client RMU instalat în cadrul universității.

2.1.1.10 Comunicarea cu sistemele de gestiune a datelor privind studenții existente în universități

Pe lângă asigurarea componentei real-time în cadrul sistemului RMU, între componenta locală și cea centrală, sistemul pune la dispoziție facilități de import / export de date care pot fi utilizate în aplicațiile de gestiune a datelor privind studenții existente în universități, în vederea funcționării near-real time a întregului sistem. În acest sens, universitățile trebuie să respecte anumite reguli și proceduri impuse de sistemul RMU (formatul fișierelor de import/export este impus și intervalul de import de date în RMU este de maxim X zile).

Astfel, în vederea importului în sistemul RMU sunt folosite fișiere XML generate fie din aplicațiile de gestiune a datelor privind studenților din universități, fie prin modulul de preluare a datelor implementat în aplicația locală RMU. Fișierele respective sunt importate prin aplicația locală RMU în sistem, urmând să fie replicate la nivel central. Prin importul fișierului XML sunt realizate operații de adăugare de noi înregistrări în sistemul RMU și de actualizare a informațiilor existente pe baza CNP-ului. Astfel, dacă un individ există deja în sistem, toate informațiile îi sunt actualizate automat cu cele importate din aplicația proprie de gestiune a datelor privind studenții a fiecărei universități.


În interacțiunea cu aplicațiile de gestiune a datelor privind studenții existente în universități (dacă universitatea dispune de un sistem informatic), se importă datele din aplicațiile existente, procedural folosind facilitatea de import din aplicație locală RMU. Ulterior, sunt reluați pașii interni RMU prezentați anterior.

La nivel de export de date, din RMU sunt oferite sub formă de fișier XML nomenclatoarele, precum și datele existente în aplicația locală RMU instalată în universitate.

Standardizarea la nivelul interacțiunii cu aplicațiile universităților de gestiune a datelor studenților este esențială, fiind determinată de multitudinea de sisteme existente în momentul de față. Aceasta este realizată prin intermediul fișierelor XML folosite pentru import/export.

2.1.2 Funcționalități asigurate

- Replicarea în timp real a modificărilor din aplicațiile locale RMU la nivel central; - Semnalarea, în timp real, a erorilor de validare de la nivel central direct în aplicația locală RMU și

facilitarea operării modificărilor necesare; - Asigurarea unui mecanism suplimentar de export la nivelul sistemului RMU (export din baza de date

locală RMU în baza de date a universității); - Actualizarea automată a nomenclatoarelor și a aplicației locale RMU cu ultimele versiuni publicate la

centru; - Posibilitatea unui student / absolvent de a publica pe Portal informațiile personale în vederea

preluării automate a acestora în aplicațiile locale RMU sau în sistemele proprii de gestiune a școlarității;

- Preluarea de către universitate, prin aplicația locală RMU, a unor date deja existente în depozitul central RMU, asigurând unicitatea în timp real a studenților;

- Furnizarea unei aplicații web-based similară cu clientul aplicației locale RMU; - Verificarea automată și informarea la nivelul aplicației locale RMU privind perioada de raportare

deschisă de la nivel central.


2.1.3 Arhitectura propusă


Primul caz reliefează situația în care o universitate are instalat serverul de baze de date pe serverul local. Complementar, în cazul al doilea, universitatea nu dispune de resursele locale și respectiva instanță a bazei de date locale RMU este instalată într-o zonă dedicată la nivel central, pe o mașină separată, cu Microsoft SQL Server instalată pe ea.

Pentru accesarea web-based a aplicației locale RMU, serverul web este configurat pe aceeași mașină pe care este instalat serverul de baze de date local al universității, indiferent dacă acesta este fizic la universitate sau în altă locație. În funcție de cerințele de accesibilitate și de constrângerile de securitate, trebuie configurate corespunzător politici de acces la respectivul server web, gestionate exclusiv de administratorul de rețea din universitate.

2.1.4 Etape implementare

- Definirea și implementarea depozitului în timp real RMU, inclusiv a mecanismelor de curățire automată;

- Implementarea mecanismului de replicare automată a bazelor de date locale la nivelul depozitului central în timp real;

- Modificarea interfeței Portalului în vederea includerii datelor replicate în timp real; - Adăugarea unei pagini la nivelul Portalului în care studentul își exprimă explicit acordul pentru a

furniza datele cu caracter personal în vederea preluării acestora de către alte universități; - Implementarea cross-validărilor la nivelul depozitului central în timp real; - Implementarea serviciilor web la nivel central pentru a permite preluarea informațiilor la nivel local; - Crearea, la nivel central, a serviciului de versionare și publicare versiune nouă a aplicației locale; - Includerea funcționalității de a permite preluarea datelor cu caracter personal direct din Portalul RMU; - Includerea erorilor semnalate de la nivel central în logica aplicației locale; - Adăugarea unui mecanism de actualizare automată a nomenclatoarelor; - Modificarea aplicației locale, astfel încât să permită actualizarea automată a acesteia cu ultima

versiune publicată; - Dezvoltarea aplicației web locale RMU care să reprezinte o alternativă viabilă la clientul windows-

based local; - Crearea metodelor de export din sistemul RMU.

3 Funcționalități suplimentare ale aplicației locale RMU

3.1 Gestiunea procesului de admitere în cadrul aplicației locale

3.1.1 Descriere

Întrucât în cadrul aplicației locale, odată cu începerea unui nou an universitar, este necesară introducerea în sistem a tuturor candidaților înmatriculați și există o multitudine de universități care nu dispun de o aplicație dedicată gestiunii procesului de admitere, această componentă este menită să ofere suport universităților în vederea administrării datelor candidaților, simplificând totodată procesul de introducere a studenților în anul I de studii.

Astfel, este asigurată posibilitatea de a gestiona procesul de admitere în cadrul fiecărei universități. În plus, prima raportare pentru studenții admiși și înmatriculați în sistem este simplificată, nefiind necesară introducerea acestora ulterior în sistem. În acest context, se asigură scăderea timpului necesar primei raportări, deoarece datele există deja în sistem.

Pe lângă informațiile memorate în mod curent pentru un student în sistemul RMU, la nivelul candidaților este stocată și media acestora de admitere. În urma extinderii, aplicația locală trebuie să permită marcarea candidaților care au fost înmatriculați în primul an, făcând mult mai facilă prima raportare a acestora.


La nivel de rapoarte vor fi incluse următoarele:

- Afișarea candidaților în ordine alfabetică; - Afișarea candidaților în ordine descrescătoare a mediei de admitere; - Afișarea candidaților într-un interval de medii; - Afișarea candidaților în funcție de un număr maxim de ordine (ex. primii X candidați); - Afișarea procentul de candidați înmatriculați raportat la numărul total de candidați.


- Introducerea separată a candidaților în aplicația locală RMU; - Importul facil al datelor cu privire la studenții înmatriculați, întrucât acestea sunt reținute pentru toți

candidații; lista finală se obține prin selecția manuală a studenților din lista de candidați înscriși; - Generarea de rapoarte cu privire la procesul de admitere la nivelul fiecărei universități, folosind Oracle

BI; - Generarea, la nivel național, a unor rapoarte care să centralizeze statisticile de la nivelul fiecărei

universități.

3.1.3 Flux informațional


- Definirea metodei de a adăuga candidați, listă care ulterior este filtrată în vederea generării listei finale de studenți înmatriculați în primul an; candidații nu sunt raportați la nivel central RMU;

- Gestiunea separată a candidaților și curățirea candidaților respinși.

3.2 Posibilitatea de a dezactiva anumite validări / constrângeri la nivel local

3.2.1 Descriere

În contextul unei raportări urgente, pentru care universitățile nu dețin toate informațiile sau nu le au introduse în cadrul aplicației locale RMU, este necesară includerea posibilității de a dezactiva pentru o perioadă limitată de timp anumite validări / constrângeri de la nivel central.


Înainte de a dezactiva respectivele validări, trebuie luate în considerare repercusiunile aferente introducerii unor date nevalidate. Această funcționalitate trebuie utilizată doar în caz de urgență, cu aprobarea explicită a managerului Structurii RMU.

Ca măsură suplimentară de menținere a integrității datelor, optiunea de dezactivare a unei validări este activă doar pentru o durată limitată.

Din perspectivă tehnică, în cadrul extinderii este construită o pagină în cadrul Portalului RMU, din care administratorul RMU poate selecta validările care să fie inactivate pentru o perioadă de timp.

Scopul acestei facilități este de a permite exportul. Pentru a nu genera inconsistențe cu repercusiuni majore asupra bunei funcționări a sistemului RMU, nicio constrângere de integritate de la nivel local nu poate fi dezactivată.

Această funcționalitate asigură astfel posibilitatea de a exporta date de la nivel local care nu satisfac cross-validările de la nivel central, putând astfel valida și date incomplete / incoerente de la nivel local. Toate validările care pot fi inactivate sunt definite la nivelul aplicației centrale RMU, în cadrul procedurilor de cross-validare, și nu la nivelul bazelor de date RMU (atât locale, cât și centrale). Printre validările incluse se numără:

- validări referitoare la CNP; - validări referitoare la situația școlară la sfârșit de an; - validări referitoare la ani buget; - validări referitoare la ani bursă; - validări legate de FORMA _FINANTARE; - validări legate de continuitate ani de studiu; - validări pe câmpuri obligatorii, condiții câmpuri, nomenclatoare; - validări pe zona PROGRAM_DE_STUDII; - validări pe zona absolvent; - validări referitoare la DIPLOMA DE LICEU.


– Posibilitatea de a dezactiva, dintr-o pagină dedicată, o validare de la nivel central, în vederea asigurării funcționalității de export din aplicațiile locale RMU, în condițiile în care datele sunt incomplete / inconsistente la rularea anumitor cross-validări.

3.2.3 Flux informațional


– Definirea, la nivel central, a unei structuri de date care să cuprindă toate validările aplicabile la nivel central;

– Crearea interfeței de gestionare a validărilor la nivel central.


4 Modificări adiționale identificate în urma demarării operaționale

4.1 Modificarea structurii bazei de date RMU

4.1.1 Descriere

În urma discuțiilor întreprinse cu echipa de management și cu reprezentanții universităților, sunt considerate oportune o serie de modificări ale structurii bazei de date RMU (atât la nivel local, cât și central):

1. Modificări în Anexa 1:

Secțiunea ”Date privind absolventul”

- Câmpul ”Data susținerii examenului” se transformă în ”Sesiunea examenului” și rămân afișate luna și anul;

- Se introduce și numărul documentului, alături de data eliberării diplomei.

Secțiunea ”Date privind pregătirea anterioră (absolvent instituție)”

- se introduce în secțiunea ”Date de identificare a actului de studii” numărul, alături de data emiterii diplomei.

2. Modificări nomenclatoare:

Sunt introduse coloane suplimentare la nivelul nomenclatoarelor (ex. cod SIRUTA, cod SIRUES, cod specializări).


- Schimbarea structurii anumitor nomenclatoare; - Modificarea Anexei 1, repercutate asupra aplicației locale și centrale RMU.

4.2 Tratarea excepțiilor constatate după demararea operațională

4.2.1 Descriere

În cadrul aplicației locale, trebuie inclusă o facilitate de generare a unui cod unic pentru studenții străini care nu au un CNP de rezident în România. Acest cod are în componența sa codul țării și numărul de identificare de pe cartea de identitate / pașaportul respectivei persoane și reprezintă o alternativă viabilă pentru CNP. Unicitatea la nivelul sistemului RMU asigură astfel o prelucrare similară cu a unei persoane deținătoare de CNP.

De asemenea, la nivel local RMU este introdusă în cadrul extinderii posibilitatea de a termina cu dublă specializare un program de studiu, în cadrul unei singure universități.

Aditional, două scenarii critice operării sistemului au fost analizate și rezoluțiile acestora sunt consemnate în continuare:

1. Subiectul respingerii persoanei in cazul in care nu sunt respectate criteriile de admisibilitate definite de UEFISCDI


Rezolutie:

Studentul va fi introdus in sistemul RMU (implicit va intra in depozitul în timp real), deoarece el nu există încă în sistem. În cazul în care studentul se duce la alta universitate și vrea să se înscrie:

- Dacă trece de criteriul de respingere (ex: acum este la cu taxa) elementul este marcat ca valid; - Dacă nu trece, se marcheaza studentul drept nevalidat si nu va putea fi exportat (în exportul

bloc – la raportare); 2. Subiectul acelasi CNP la doua persoane distincte

Rezolutie:

Primul student va fi introdus in sistemul RMU (implicit va intra in depozitul în timp real).

Pentru al doilea student trebuie schimbat CNP-ul pentru a putea fi introdus in sistemul RMU; nu sunt admise 2 persoane cu același CNP și prima înregistrare are prioritate.


– Generarea codului unic pentru studenții străini, drept alternativă viabilă a CNP-ului, la nivelul aplicației locale RMU;

– Posibilitatea de a selecta o a doua specializare, în cadrul aceleiași universități; – Tratarea scenariilor discutate.


– Definirea și implementarea metodei de generare a identificatorului unic pentru studenții străini care nu au un CNP de rezident asignat;

– Modificarea structurilor de date și a aplicației RMU astfel încât să fie permisă existența dublei specializări;

– Implementarea constrângerilor și a criteriilor de respingere a unui student în vederea operării corespunzătoare a sistemului.

Specificații de proiectare ale funcționalităților suplimentare. Specificatii de proiectare...

Documents

Transcript of Specificații de proiectare ale funcționalităților suplimentare. Specificatii de proiectare...