Pagina de copertă

Portofoliu de Lucru — Echipă

Completați datele echipei. Toate informațiile se salvează automat în browser-ul vostru.

PORTOFOLIU DE LUCRU

Program de formare IT&C · Ministerul Afacerilor Interne · 2026

Numele echipei

Membrii echipei (max. 5)

Data începerii cursului

Data completării portofoliului

Instrucțiuni generale

Scop: Portofoliul este o colecție progresivă de exerciții practice și rezultate ale muncii în echipă pe parcursul programului de formare de 5 zile. Se evaluează ca parte a examenului practic.

Cum lucrați:

Completați fiecare secțiune la finalul zilei corespunzătoare.
Toți membrii echipei contribuie activ.
Răspunsurile trebuie să refere materia de curs și principiile învățate.
Aplicați cunoștințele la contextul real al MAI.
La final, exportați portofoliul ca PDF (buton sus-dreapta) și salvați o copie .json pentru backup.

💡 Sfat: La sfârșit de zi, apăsați „Salvează copie (.json)" și păstrați fișierul undeva sigur (email, cloud, USB). Așa puteți continua a doua zi și pe alt dispozitiv dacă e nevoie.

Ziua 1 · Modul 1

Management Agil al Proiectelor

Exerciții pe MoSCoW și Sprint Planning pentru un proiect de digitalizare MAI.

Exercițiul 1 — Evaluare MoSCoW

Pentru un proiect de digitalizare a proceselor MAI, clasificați cele 8 cerințe utilizând metoda MoSCoW (Must / Should / Could / Won't).

10 puncte

MoSCoW — prioritizarea cerințelor

Metodă de prioritizare propusă de Dai Clegg (1994), folosită în Agile/DSDM. Clasifică cerințele în 4 categorii pentru a gestiona scope-ul când resursele sunt limitate.

Must have (M) — fără acestea proiectul eșuează. Minimum viable product.
Should have (S) — importante dar nu critice pentru lansare. Pot fi amânate 1-2 sprinturi.
Could have (C) — nice-to-have; adăugate dacă timpul permite.
Won't have this time (W) — nu sunt incluse în scope-ul actual; consemnate pentru viitor.

Exemplu MAI: „Autentificare cu card MAI" = Must; „Export PDF rapoarte" = Should; „Dark mode" = Could; „Integrare cu rețele sociale" = Won't.

Cerință	M/S/C/W	Justificare

Exercițiul 2 — Plan de Sprint

Proiectați un plan de Sprint de 2 săptămâni pentru proiectul de digitalizare MAI. Definiți user stories, estimări în puncte, responsabil și status.

10 puncte

Sprint Planning & Story Points

Un Sprint e o perioadă time-boxed (1-4 săptămâni) la finalul căreia echipa livrează increment funcțional. Story-urile sunt cerințe exprimate în formatul „Ca [rol], vreau [ce], pentru [de ce]".

Story Points estimează efortul relativ (nu ore). Scala Fibonacci: 1, 2, 3, 5, 8, 13, 21. Capacitatea echipei = velocity (ex. 30 SP/sprint).

Status: To Do · In Progress · In Review · Done
Fiecare story trebuie să fie INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable

Exemplu: „Ca ofițer, vreau să raportez incidente de pe mobil pentru a reduce timpul administrativ" · 8 SP · Alex P. · In Progress

User Story	Points	Responsabil	Status

Reflecția echipei — Ziua 1

Ce ați învățat despre Agile PM? Ce provocări ați întâmpinat în exerciții? Cum se aplică la proiectele reale din unitatea voastră?

Ziua 2 · Modul 2

Arhitecturi Informatice — TOGAF

Exerciții pe maparea BDAT și o fișă ADM pentru un proiect MAI.

Exercițiul 1 — Maparea BDAT

Mapați un sistem IT existent al MAI la cele 4 domenii de arhitectură TOGAF: Business, Data, Application, Technology.

8 puncte

BDAT — Cele 4 domenii ale arhitecturii TOGAF

Business (B) — strategia, guvernanța, organizarea, procesele cheie. Ce face organizația?
Data (D) — structura datelor logice și fizice, fluxuri, mastering, calitate. Cu ce informații lucrează?
Application (A) — aplicațiile, interfețele, integrările. Cu ce software?
Technology (T) — infrastructură, rețele, cloud, securitate tehnică. Pe ce rulează?

Exemplu MAI (sistem de amenzi auto):
• B: Proces de constatare & emitere amendă; rol agent, director DRPCIV
• D: Baza date amenzi, CNP, date auto, loc, timp, fotografii
• A: Aplicație mobilă agent, portal plăți, backend interconectat Fisc
• T: Servere STS, rețea MAI, terminale Android întărite, semnare digitală

Numele sistemului IT ales (pentru mapare)

Domeniu	Descriere	Procese / Sisteme existente	Oportunități de îmbunătățire

Exercițiul 2 — Fișă ADM

Alegeți o fază ADM și descrieți pentru un proiect MAI: input, activități, output, stakeholderi.

9 puncte

ADM — Architecture Development Method

Metoda iterativă TOGAF, structurată în 8 faze + fază preliminară + management cerințe central.

A — Architecture Vision: definirea viziunii, scope-ului și aprobarea inițiativei
B — Business Architecture: arhitectura business țintă vs. curentă
C — Information Systems Architectures: Data + Application
D — Technology Architecture: infrastructură țintă
E — Opportunities & Solutions: planificare roadmap, gap analysis
F — Migration Planning: plan detaliat de tranziție
G — Implementation Governance: supraveghere execuție
H — Architecture Change Management: gestionarea evoluției

Exemplu MAI, Faza B: Input = viziune aprobată; Activități = modelare procese As-Is și To-Be; Output = catalog capabilități business; Stakeholderi = Director DGIT, șefi structuri, DPO.

Faza ADM selectată

Proiect MAI de referință

Input	Activități	Output	Stakeholderi

Reflecția echipei — Ziua 2

Cum vă ajută TOGAF să structurați o arhitectură IT la MAI? Care sunt provocările de adoptare în context public?

Ziua 3 · Modul 3

Guvernanță IT — COBIT 2019

Auto-evaluare maturitate pe 5 procese COBIT și mapare la cerințe legale românești.

Exercițiul 1 — Auto-evaluare maturitate COBIT

Evaluați maturitatea pentru 5 procese COBIT cheie în instituția voastră (0 = Inexistent, 5 = Optimizat). Propuneți acțiuni pentru a trece la nivelul țintă.

10 puncte

Niveluri de maturitate (CMMI-like)

0 · Inexistent: procesul nu e recunoscut; nu există rezultate
1 · Ad-hoc/Inițial: proces executat neregulat, depinde de persoane
2 · Repetabil: planificat și urmărit la nivel de echipă
3 · Definit: standardizat & documentat enterprise-wide
4 · Gestionat cantitativ: măsurat cu metrici, previzibil
5 · Optimizat: îmbunătățire continuă bazată pe date

Tipic pentru administrația publică: majoritatea proceselor sunt la nivel 1-2; obiectivul realist 12 luni = nivel 3.

Proces	Descriere	Actual	Țintă	Acțiuni propuse

Exercițiul 2 — Mapare legală

Mapați 3 obiective COBIT la cerințele legale românești (Legea 362/2018 — securitatea rețelelor, HG 1269/2021 — Strategia digitală, GDPR, NIS2, OUG 39/2022).

8 puncte

Legislație aplicabilă IT&C în sectorul public RO

Legea 362/2018 — securitatea rețelelor și sistemelor informatice (transpune NIS1)
Directiva UE 2022/2555 (NIS2) — transpusă 2024, cerințe mai stricte cyber
GDPR + Legea 190/2018 — protecția datelor
HG 1269/2021 — Strategia Națională Digitalizare 2022-2027
OUG 39/2022 — cadrul de interoperabilitate
Legea 98/2016 — achiziții publice
Legea 229/2023 — accesibilitate produse/servicii digitale

Obiectiv COBIT	Cerință legală aplicabilă	Stare conformitate	Acțiuni de conformare

Reflecția echipei — Ziua 3

Ce ați aflat despre guvernanță IT? Cum se aliniază COBIT cu legislația românească?

Ziua 4 · Module 4-8

MySMIS 2021+

Fișa proiectului, checklist achiziții și analiză 5 Whys pentru erori.

Exercițiul 1 — Fișa proiectului IT

Completați fișa de sinteză a unui proiect IT ipotetic al MAI (obiective, indicatori SMART, buget, durată).

8 puncte

Indicatori SMART

Pentru a fi evaluabili de MFE, indicatorii trebuie să fie:

Specific — clar, fără ambiguitate
Measurable — măsurabil cu o sursă de date
Achievable — realist dat fiind resursele
Relevant — conectat cu obiectivul proiectului
Time-bound — cu termen clar

Rău: „Îmbunătățire servicii" · Bun: „500 de polițiști formați în cyber, cu rata certificare ≥ 80%, până la finalul T12"

Exercițiul 2 — Checklist dosar achiziție

Pentru o achiziție IT ficțională (sistem CRM cloud, 100.000 EUR), completați checklist-ul documentelor obligatorii.

5 puncte

Praguri achiziții publice — Legea 98/2016

Achiziție directă: < 140.000 RON (bunuri/servicii), < 300.000 RON (lucrări)
Cerere de oferte simplificată: între pragurile de sus și pragurile europene
Licitație deschisă: peste pragurile europene (actualizate periodic; ~540.000 EUR bunuri pentru autorități centrale în 2024)

100.000 EUR = ~497.000 RON → intră în cerere de oferte simplificată. Dosarul necesită: specificații, RFQ, evaluare, contract, publicare SEAP.

Document obligatoriu	Prezent (Da/Nu)	Observații

Exercițiul 3 — Analiza erorilor (5 Whys)

Identificați 3 erori potențiale într-un proiect IT și determinați cauza rădăcină folosind metoda 5 Whys.

5 puncte

5 Whys — de la simptom la cauză rădăcină

Tehnică simplă: întrebați „De ce?" de 5 ori consecutiv pentru a depăși simptomele superficiale și a ajunge la cauza rădăcină.

Simptom: Raportul lunar e livrat cu 5 zile întârziere
De ce 1? Datele sunt primite târziu de la 3 unități teritoriale
De ce 2? Acestea folosesc un format Excel vechi incompatibil
De ce 3? Nu au fost instruite pe noul format
De ce 4? Training-ul a fost anulat din motive de buget
De ce 5? Bugetul de formare nu e repartizat anual → CAUZĂ RĂDĂCINĂ

Eroare identificată	Cauza rădăcină (5 Whys)	Acțiune corectivă

Reflecția echipei — Ziua 4

Ce ați învățat din exercițiile MySMIS? Cum se aplică în practica MAI?

Ziua 5 · Modul 9

Principii Orizontale

Evaluare DNSH și checklist accesibilitate WCAG 2.1.

Exercițiul 1 — Evaluare DNSH

Pentru un proiect IT propus la MAI, evaluați impactul asupra celor 6 obiective de mediu. DNSH = Do No Significant Harm.

9 puncte

DNSH — Do No Significant Harm (Reg. UE 2020/852)

Toate investițiile finanțate PNRR și politica de coeziune trebuie să nu aducă prejudicii semnificative niciunuia din cele 6 obiective de mediu UE.

Atenuarea schimbărilor climatice
Adaptarea la schimbările climatice
Utilizarea durabilă și protecția apei și resurselor marine
Tranziția către economia circulară
Prevenirea și controlul poluării
Protecția și restaurarea biodiversității și ecosistemelor

Pentru IT: atenție la consum energetic data centers, e-waste, uzajul hârtiei în digitalizare.

Proiect MAI evaluat

Obiectiv de mediu	Impact (Poz/Neutru/Neg)	Măsuri de atenuare

Exercițiul 2 — Checklist accesibilitate WCAG 2.1

Evaluați un portal web ipotetic al MAI în funcție de criteriile WCAG 2.1.

8 puncte

WCAG 2.1 — Web Content Accessibility Guidelines

Standard internațional W3C, obligatoriu în UE prin Directiva 2016/2102 și Accessibility Act (Legea 229/2023).

4 principii POUR:

Perceivable — utilizatorii percep informația (alt text, contrast, subtitrări)
Operable — pot opera interfața (tastatură, timp suficient)
Understandable — înțeleg conținutul (limbaj simplu, consistență)
Robust — compatibil cu tehnologii asistive (screen readers)

Niveluri: A (minim) · AA (standard UE) · AAA (ideal, nu general obligatoriu)

Portal MAI evaluat

Criteriu WCAG 2.1	Nivel	Conform (Da/Nu)	Observații / Remediere

Reflecția echipei — Ziua 5

De ce sunt importanți principiile orizontale în proiectele IT la MAI? Cum se aplică concret?

Declarație

Declarație de originalitate

Parcurgeți declarația și completați semnăturile electronice.

Declarăm prin prezentul că:

Toată munca prezentată în acest portofoliu este rezultatul eforturilor originale ale echipei noastre;
Avem o înțelegere clară a tuturor exercițiilor și răspunsurilor;
Toți membrii echipei au contribuit în mod egal la prepararea și finalizarea portofoliului;
Orice material utilizat de la surse externe este citat și referențiat corespunzător;
Înțelegem că plagiarismul și copierea de la alți colegi sunt interzise și vor duce la consecințe disciplinare.

Semnături ale membrilor echipei

Fiecare membru introduce numele (drept confirmare) și data semnării. La tipărirea PDF, se poate semna olograf pe linia tipărită.

Informativ

Grila de evaluare (100 puncte)

Așa veți fi evaluați. Punctajele se aloca de formator la finalul cursului.

Praguri calificativ final:

≥ 90%: Excelent
75-89%: Foarte Bine
60-74%: Bine
50-59%: Suficient
< 50%: Insuficient