• Responsabili & Autori: Valentin Gabriel Cărăuleanu , Alexandra Ghiorghiță, Cleopatra Popescu, Roberto-Giulio Pal , Andrei Ionescu], Roșca Cvintilian
• Consultanți & Revizori: Sorina-Anamaria Buf, Ștefan Cocioran, Florian-Luis Micu
• Data publicării BETA testing: 21.10.2025
• Deadline HARD BETA testing: 30.11.2025
• Data publicării oficiale: 30.11.2025
• Deadline HARD oficial: 18.01.2026
• Ultima modificare (cerință, schelet sau teste): 21.10.2025
• Schelet și teste: https://github.com/oop-pub/schelet-tema2-2025

• Familiarizarea cu Java și conceptele de bază ale POO.
• Aprofundarea conceptelor propuse pentru tema 1.
• Folosirea claselor speciale și a bibliotecii standard Java.
• Respectarea unui stil de codare și de comentare.
• Respectarea principiilor SOLID, DRY, KISS.
• Dezvoltarea aptitudinilor de depanare a problemelor în cod.
• Implementarea a cel puțin 4 design pattern-uri diferite.
• Familiarizarea cu Maven și a framework-urilor de testare.

După ce ați încercat, fără succes, să obțineți un job la startup-ul lui Gigelino, ați decis să vă lansați propria aplicație. Întâmplarea a făcut să atrageți atenția unor investitori dispuși să vă finanțeze, însă cu o condiție clară: produsul final trebuie să fie stabil, lipsit de bug-uri majore și să primească feedback pozitiv de la utilizatorii beta.

Pentru a răspunde acestei provocări, veți implementa un sistem de ticket tracking care să vă ajute să:

• înregistrați tichete noi.
• raportați problemele apărute.
• urmăriți progresul și să le rezolvați.

Dezvoltarea va fi împărțită în două etape principale:

1. testare și raportare tichete.
2. rezolvare acestora de către echipa de ingineri.
3. verificarea aplicației și a progresului de către manageri.

Obiectivul vostru este să asigurați o gestionare eficientă a bug-urilor, prioritizarea corectă a sarcinilor și o monitorizare constantă a progresului, astfel încât să prezentați investitorilor un produs final solid și de încredere.

Atenție! Timpul este limitat, iar investitorii nu sunt dispuși să aștepte la nesfârșit.

Dezvoltarea aplicației urmează un ciclu iterativ, alcătuit din următoarele etape:

1. Perioada de testare: reporterii deschid tichete pentru problemele identificate.
2. Perioada de dezvoltare: managerii creează milestone-uri, iar developerii preiau tichete și le rezolvă.
3. Verificarea stabilității aplicației: se generează un raport de stabilitate și se evaluează progresul.
   1. Dacă produsul este stabil, proiectul se încheie cu succes.
   2. Dacă nu, ciclul este reluat.

• La inițierea aplicației, perioada de testare începe automat.
• Utilizatorii pot raporta tichete noi, pe baza testării produsului și a feedback-ului primit de la clienți.
• Developerii nu pot rezolva tichete în această etapă, iar mannager-ii nu pot crea milestone-uri.
• Perioada de testare are o durată fixă de 15 zile.
• O nouă perioadă de testare poate fi inițiată dacă nu există milestone-uri active.

• După încheierea perioadei de testare, începe perioada de dezvoltare.
• Managerii creează milestone-uri și își coordonează echipa.
• Developerii își pot asocia tichete din milestone-uri și pot începe lucrul la acestea.

• Managerii pot genera rapoarte pentru monitorizarea progresului.
• Dacă raportul de stabilitate este satisfăcător, produsul este considerat stabil și pregătit pentru prezentarea către investitori.
• Dacă raportul indică probleme, ciclul continuă cu o nouă perioadă de testare și dezvoltare.
• Această etapă poate fi skipped, trecându-se direct la perioada de testare, dacă un manager execută comanda: startTestingPhase

Aplicația gestionează mai multe tipuri de tichete. Toate tipurile împărtășesc un set comun de atribute.

Un ticket de tip BUG reprezintă o problemă tehnică apărută în aplicație.

Un tichet de tip FEATURE_REQUEST propune o nouă funcționalitate sau extinderea uneia existente.

Un tichet de tip UI_FEEDBACK colectează sugestii privind experiența de utilizare.

O imagine valorează cât o mie de cuvinte.

Aplicația definește trei tipuri de utilizatori, fiecare cu roluri și atribute specifice. Datele de intrare pentru utilizatori se află în fișierul-schelet: input/database/users.json.

Un utilizator este definit prin:

Reporterul are rolul de a raporta tichete în perioadele de testare pe baza feedback-ului primit de la clienți și a testării interne. De asemenea, poate primi notificări legate de statusul tichetelor raportate.

[
  {
    "username": "reporter_one",
    "role": "REPORTER",
    "email": "reporter_one@gmail.com"
  },
  {
    "username": "reporter_two",
    "role": "REPORTER",
    "email": "reporter_two@gmail.com"
  }
]

Developerul se ocupă de rezolvarea tichetelor raportate și poate primi notificări legate de activitatea acestora.

Un developer este definit prin:

Acces la tichete în funcție de senioritate:

Mai mult! Fiecare developer are o specializare:

[
  {
    "username": "dev_three",
    "role": "DEVELOPER",
    "email": "dev_three@bugtracker.com", 
    "hireDate": "2022-07-22", 
    "seniority": "JUNIOR",
    "expertiseArea": "FRONTEND"
  },
  {
    "username": "dev_four",
    "role": "DEVELOPER",
    "email": "dev_four@bugtracker.com",
    "hireDate": "2019-11-05",
    "seniority": "MID",
    "expertiseArea": "FULLSTACK"
  }
]

Managerul coordonează propria echipa de developeri, creează și gestionează milestone-uri și menține o listă de subordonați reprezentată prin username-urile developerilor pe care îi are în echipă.

[
  {
    "username": "gabriel_manager",
    "role": "MANAGER",
    "email": "gabriel@bugtracker.com", 
    "hireDate": "2002-02-28", 
    "subordinates": ["dev_one", "dev_two", "dev_three"]
  },
  {
    "username": "cleopatra_manager",
    "role": "MANAGER",
    "email": "cleopatra@bugtracker.com",
    "hireDate": "2003-03-15",
    "subordinates": ["dev_four", "dev_five"]
  }
]

Un milestone reprezintă o etapă majoră în dezvoltarea proiectului. Acesta este stabilit de un manager la finalul unei perioade de testare și conține un set de tichete care trebuie rezolvate într-un interval de timp predefinit.

1. La fiecare 3 zile după crearea milestone-ului, prioritatea tichetelor din acel milestone crește automat cu o treaptă (ex: LOW → MEDIUM, MEDIUM → HIGH, CRITICAL → CRITICAL).

2. Cu o zi calendaristică înainte de dueDate:

1. toate tichetele rămase active capătă prioritatea CRITICAL.
2. toți developerii repartizați acelui milestone primesc o notificare.

3. Un milestone poate bloca alte milestone-uri. Dacă un milestone se află în starea de blocare:

1. bug-urile din milestone-ul blocat nu pot fi rezolvate sau preluate de un developer.
2. regulile de la punctele 1 și 2 nu se aplică (prioritatea tichetelor nu crește, iar acestea nu devin CRITICAL).

4. Dacă un milestone este deblocat cu o zi calendaristică înainte de dueDate, regula de la punctul 2 se aplică.

5. Dacă un milestone este deblocat după dueDate:

1. toate tichetele rămase devin automat CRITICAL.
2. se trimite o notificare specială developerilor repartizați acelui milestone.

LocalDate now = LocalDate.parse(nowString); // conversia dintr-un string într-un obiect LocalDate
LocalDate due = LocalDate.parse(dueString);

int daysBetween = (int) ChronoUnit.DAYS.between(now, due) + 1; // calculul daysBetween

Întreaga aplicație este bazată pe un sistem de notificări. Orice acțiune semnificativă (ex: adăugare comentariu, schimbare status tichet, creare milestone) va genera o notificare către utilizatorii vizați.

Pe lângă rapoartele de performanță, aplicația generează și rapoarte pe baza unor metrici specifice, calculate în funcție de tipul fiecărui tichet.

Cele 3 metrici cu care vom lucra sunt: Customer Impact, Resolution Efficiency, Ticket Risk.

frequency:
  RARE        = 1
  OCCASIONAL  = 2
  FREQUENT    = 3
  ALWAYS      = 4

businessPriority:
  LOW         = 1
  MEDIUM      = 2
  HIGH        = 3
  CRITICAL    = 4

severityFactor:
  MINOR       = 1
  MODERATE    = 2
  SEVERE      = 3

businessValue:
  S           = 1
  M           = 3
  L           = 6
  XL          = 10

customerDemand:
  LOW         = 1
  MEDIUM      = 3
  HIGH        = 6
  VERY_HIGH   = 10

1. Pentru fiecare tichet eligibil se calculează scorul brut (baseScore), în funcție de formula asociată.

2. Se normalizează rezultatul pe intervalul 0–100.

3. Se face media scorurilor pentru o categorie.

public double calculateImpactFinal(double baseScore, double maxValue) {
    return Math.min(100.0, (baseScore * 100.0) / maxValue);
}

public double calculateAverageImpact(List<Double> scores) {
    return scores.stream().mapToDouble(Double::doubleValue).average().orElse(0.0);
}

Mai multe detalii, veți găsi la comenzile specifice fiecărei metrici.

Pe parcursul execuției, va trebui să gestionați diverse erori.

Ordinea în care apar în enunț este și ordinea în care trebuie verificate. Astfel, excepția menționată prima va avea întotdeauna prioritate de tratare față de cele care apar mai jos. Următoarele excepții pot apărea la orice comandă.

{
  "command": "command_name",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "The user <user_name> does not exist."
}

{
  "command": "command_name",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "The user does not have permission to execute this command: required role <role_name1>, <role_name2>; user role <user_role>."
}

Acum putem trece la comenzile aplicatiei.

Disponibilă pentru: Manager

Descriere: Începem cu pesimism. Investitorii și-au pierdut răbdarea și au renunțat la finanțare. Aplicația se închide și nu mai sunt procesate comenzi după acest moment.

Comanda: lostInvestors

{
  "command": "lostInvestors",
  "username": "gabriel_manager",
  "timestamp": "2025-10-20"
}

Nu există output.

Disponibilă pentru: Manager

Descriere: Începe o nouă perioadă de testare, permițând reporterilor să creeze tichete noi.

Command: startTestingPhase

O nouă perioadă de testare poate începe doar dacă nu mai există milestone-uri active (cu tichete nerezolvate).

În cazul în care se încearcă începerea unei noi perioade de testare cu milestone-uri active, comanda este respinsă:

{
  "command": "startTestingPhase",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Cannot start a new testing phase."
}

Exemplu Input:

{
"command": "startTestingPhase",
"username": "gabriel_manager",
"timestamp": "2025-10-05"
} 

Nu există output.

Disponibilă pentru: Reporter

Descriere: Reportarea este permisă doar în perioada de testare. Pentru mai multe detalii, consultați secțiunea Perioada de Testare.

Comanda: reportTicket

Restricții:

1. Tichetele pot fi raportate doar in perioada de testare.

{
"command": "reportTicket",
"username": "user_name",
"timestamp": "YYYY-MM-DD",
"error": "Tickets can only be reported during testing phases."
} 

2. Raportarea anonimă:

• Tichetele anonime au automat LOW businessPriority.
• Doar tichetele de tip BUG pot fi anonime (reportedBy = ”“).

{
"command": "reportTicket",
"username": "user_name",
"timestamp": "YYYY-MM-DD",
"error": "Anonymous reports are only allowed for tickets of type BUG."
} 

Format Input:

{
"command": "reportTicket",
"timestamp": "2025-09-10",
"type": "BUG",
"username": "reporter_one",
"reportedBy": "cleopatra",
"params": {
"title": "Crash on settings page",
"description": "App crashes when accessing settings.",
"businessPriority": "HIGH",
"frequency": "FREQUENT",
"expertiseArea": "BACKEND",
"reportedBy": "cleopatra",
"expectedBehavior": "Settings page should load without crashing.",
"actualBehavior": "App crashes immediately.",
"environment": "Windows"
}
} 

Nu există output.

Disponibilă pentru: Developer, Manager, Reporter

Descriere: Afișează tichetele din sistem în funcție de rolul utilizatorului curent.

Comanda: viewTickets

1. Developer: vede toate tichetele cu status OPEN din milestone-urile la care este repartizat (indiferent dacă le poate prelua spre soluționare).

2. Manager: vede toate tichetele din sistem.

3. Reporter: vede doar tichetele introduse in sistem. (tichetele anonime sunt excluse).

Exemplu Input:

{
"command": "viewTickets",
"username": "manager_one",
"timestamp": "2025-09-25"
} 

Exemplu Output:

{
"command": "viewTickets",
"username": "dev_one",
"timestamp": "2025-09-25",
"tickets": [
{
"id": 0,
"type": "BUG",
"title": "Crash on settings page",
"businessPriority": "HIGH",
"status": "IN_PROGRESS",
"createdAt": "2025-09-10",
"solvedAt": "",
"assignedAt": "2025-09-21",
"assignedTo": "dev_one",
"reportedBy": "cleopatra",
"comments": [
{
"author": "dev_one",
"content": "I am looking into this issue.",
"createdAt": "2025-09-10"
},
{
"author": "manager_gabriel",
"content": "Please prioritize this bug.",
"createdAt": "2025-09-11"
}
]
}
]
} 

Disponibilă pentru: Reporter, Developer

Descriere: Adaugă un comentariu la un tichet.

Comanda: addComment

1. Dacă tichetul nu există (ID inexistent), comanda este ignorată.

2. Un tichet anonim nu poate primi comentarii. Dacă se încearcă adăugarea unui comentariu la un tichet anonim, comanda este respinsă:

{
  "command": "addComment",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Comments are not allowed on anonymous tickets."
}

3. Un Reporter nu poate comenta dacă tichetul are status CLOSED. În cazul în care se încearcă comentarea unui tichet cu status CLOSED, comanda este respinsă:

{
  "command": "addComment",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Reporters cannot comment on CLOSED tickets."
}

4. Conținutul comentariului trebuie să aibă minim 10 caractere. Dacă este mai mic, comanda este respinsă:

{
  "command": "addComment",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Comment must be at least 10 characters long."
}

5. Un Developer poate comenta doar pe tichetele pe care și le-a repartizat pentru soluționare. În caz contrar, comanda este respinsă:

{
  "command": "addComment",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Ticket <id> is not assigned to the developer <developer_name>."
}

6. Un Reporter poate comenta doar pe tichetele pe care le-a raportat. În caz contrar, comanda este respinsă:

{
  "command": "addComment",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Reporter <reporter_name> cannot comment on ticket <id>."
}

{
  "author": "username_of_commenter",
  "content": "string",
  "createdAt": "date_given_by_command_timestamp"
}

Exemplu Input:

{
"command": "addComment",
"username": "dev_one",
"ticketID": 0,
"comment": "I am looking into this issue.",
"timestamp": "2025-09-10"
} 

Nu există output.

Disponibilă pentru: Reporter, Developer

Descriere: Șterge ultimul comentariu adăugat de utilizator la un tichet.

Comanda: undoAddComment

1. Dacă tichetul nu există (ID inexistent) sau dacă utilizatorul nu are comentarii la tichetul respectiv comanda este ignorată.

2. Dacă se încearcă ștergerea unui comentariu de la un tichet anonim, comanda este respinsă:

{
  "command": "undoAddComment",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Comments are not allowed on anonymous tickets."
}

Exemplu Input:

{
"command": "undoAddComment",
"username": "dev_one",
"ticketID": 0,
"timestamp": "2025-09-10"
} 

Nu există output.

Disponibilă pentru: Manager

Descriere: Setează un nou milestone.

Comanda: createMilestone

• Un tichet poate aparține unui singur milestone la un moment dat. În cazul în care un tichet este deja atribuit unui alt milestone, comanda createMilestone este respinsă:

{
  "command": "createMilestone",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Tickets id already assigned to milestone <milestone_name>."
}

Exemplu Input:

{
"command": "createMilestone",
"username": "gabriel_manager",
"timestamp": "2025-09-15",
"name": "v1.0",
"dueDate": "2025-10-01",
"blockingFor": ["v2.0"],
"tickets": [0, 1, 2],
"assignedDevs": ["dev_one", "dev_two"]
} 

Nu există output.

Disponibilă pentru: Manager, Developer

Descriere: Afișează milestone-urile din sistem în funcție de rolul utilizatorului curent.

Comanda: viewMilestones

1. Manager: vede toate milestone-urile create de el.

2. Developer: vede toate milestone-urile la care este repartizat.

Exemplu Input:

{
"command": "viewMilestones",
"username": "username",
"timestamp": "2025-09-25"
} 

Exemplu Output:

{
"command": "viewMilestones",
"username": "pm_lead",
"timestamp": "2025-09-25",
"milestones": [
{
"name": "v1.0",
"blockingFor": ["v2.0"],
"dueDate": "2025-10-01",
"createdAt": "2025-09-15",
"tickets": [0, 1, 2],
"assignedDevs": ["dev_one", "dev_two"],
"createdBy": "gabriel_manager",
"status": "ACTIVE",
"isBlocked": false,
"daysUntilDue": 6,
"overdueBy": 0,
"openTickets": [0, 1, 2],
"closedTickets": [],
"completionPercentage": 0.00,
"repartition": [
{
"developer": "dev_one",
"assignedTickets": [1]
},
{
"developer": "dev_two",
"assignedTickets": [2]
},
{
"developer": "dev_three",
"assignedTickets": []
}
]
}
]
} 

Disponibilă pentru: Developer

Descriere: Un developer își poate atribui un tichet conform regulilor de expertiză, senioritate și milestone.

Comanda: assignTicket

1. Un Developer poate prelua tichete doar din aria lui de expertiză. În caz contrar, comanda este respinsă:

{
  "command": "assignTicket",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Developer <developer_name> cannot assign ticket <id> due to expertise area. Required: <required_area1>, <required_area2>; Current: <current_area>."
}

2. Un Developer poate prelua singur doar tichete accesibile nivelului său de senioritate. În caz contrar, comanda este respinsă:

{
  "command": "assignTicket",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Developer <developer_name> cannot assign ticket <id> due to seniority level. Required: <required_level>, <required_level>; Current: <current_level>."
}

3. Un tichet poate fi preluat doar dacă are statusul OPEN. În caz contrar, comanda este respinsă:

{
  "command": "assignTicket",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Only OPEN tickets can be assigned."
}

4. Dacă un developer încearcă să preia un tichet dintr-un milestone la care nu este repartizat, comanda este respinsă:

{
  "command": "assignTicket",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Developer <developer_name> is not assigned to milestone <milestone_name>."
}

5. Un developer nu poate prelua tichete dintr-un milestone blocat. În caz contrar, comanda este respinsă:

{
  "command": "assignTicket",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Cannot assign ticket <id> from blocked milestone <milestone_name>."
}

Exemplu Input:

{
"command": "assignTicket",
"username": "dev_one",
"ticketID": 0,
"timestamp": "2025-09-21"
} 

Nu există output.

Disponibilă pentru: Developer

Descriere: Developer-ul realizează că nu poate rezolva un tichet și decide să renunțe, pentru a fi preluat de altcineva.

Comanda: undoAssignTicket

1. Un tichet poate fi „de-asignat” doar dacă are statusul IN_PROGRESS. În cazul în care un developer încearcă să renunțe la un tichet cu alt status, comanda este respinsă:

{
  "command": "undoAssign",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Only IN_PROGRESS tickets can be unassigned."
}

Exemplu Input:

{
"command": "undoAssign",
"username": "dev_one",
"ticketID": 0,
"timestamp": "2025-09-22"
} 

Nu există output.

Disponibilă pentru: Developer

Descriere: Afișează toate tichetele repartizate unui developer.

Comanda: viewAssignedTickets

Exemplu Input:

{
"command": "viewAssignedTickets",
"username": "dev_one",
"timestamp": "2025-09-25"
} 

Exemplu Output:

{
"command": "viewAssignedTickets",
"username": "dev_one",
"timestamp": "2025-09-25",
"assignedTickets": [
{
"id": 0,
"type": "BUG",
"title": "Crash on settings page",
"businessPriority": "HIGH",
"status": "IN_PROGRESS",
"createdAt": "2025-09-10",
"assignedAt": "",
"reportedBy": "cleopatra",
"comments": [
{
"author": "dev_one",
"content": "I am looking into this issue.",
"createdAt": "2025-09-10"
},
{
"author": "reporter_one",
"content": "Please prioritize this bug.",
"createdAt": "2025-09-11"
}
]
},
{
"id": 2,
"type": "FEATURE_REQUEST",
"title": "Add dark mode",
"businessPriority": "MEDIUM",
"status": "RESOLVED",
"createdAt": "2025-09-12",
"assignedAt": "",
"reportedBy": "user123",
"comments": []
}
]
} 

Disponibilă pentru: Developer

Descriere: Permite unui developer să modifice statusul unui tichet preluat.

Comenzi: changeStatus, undoChangeStatus

1. Tichetul trebuie să fie repartizat developerului care execută comanda. În caz contrar, comanda este respinsă:

{
  "command": "changeStatus",
  "username": "user_name",
  "timestamp": "YYYY-MM-DD",
  "error": "Ticket <id> is not assigned to developer <developer_name>."
}

2. Daca tichetul are statusul IN_PROGRESS, comanda undoChangeStatus este ignorată.

3. Daca tichetul are statusul CLOSED, comanda changeStatus este ignorată.

Exemplu Input changeStatus/undoChangeStatus:

{
"command": "changeStatus",
"username": "dev_one",
"ticketID": 0,
"timestamp": "2025-09-23"
} 

Nu există output.

Disponibilă pentru: Developer, Manager

Descriere: Un user vede istoricul tichetelor.

Comanda: viewTicketHistory

1. Un Developer poate vedea istoricul tichetelor care i-au fost repartizate (inclusiv cele CLOSED) și pe cele la care a renunțat.

2. Un Manager poate vedea istoricul tichetelor care au fost în milestone-urile pe care le-a creat, pentru toți developerii implicați.

Exemplu Input:

{
"command": "viewTicketHistory",
"username": "dev_one",
"timestamp": "2025-09-25"
} 

Exemplu Output:

{
"command": "viewTicketHistory",
"username": "dev_one",
"timestamp": "2025-09-25",
"ticketHistory": [
{
"id": 0,
"title": "Ticket 1",
"status": "CLOSED",
"actions": [
{
"action": "ASSIGNED",
"by": "dev_one",
"timestamp": "2025-09-15"
},
{
"action": "STATUS_CHANGED",
"from": "OPEN",
"to": "IN_PROGRESS",
"by": "dev_one",
"timestamp": "2025-09-15"
},
{
"action": "STATUS_CHANGED",
"from": "IN_PROGRESS",
"to": "RESOLVED",
"by": "dev_one",
"timestamp": "2025-09-18"
},
{
"action": "STATUS_CHANGED",
"from": "RESOLVED",
"to": "CLOSED",
"by": "dev_one",
"timestamp": "2025-09-20"
}
],
"comments": [
{
"author": "dev_one",
"timestamp": "2025-09-20",
"message": "Fixed the issue."
}
]
},
{
"id": 1,
"title": "Ticket 2",
"status": "IN_PROGRESS",
"actions": [
{
"action": "ASSIGNED",
"by": "dev_one",
"timestamp": "2025-09-22"
},
{
"action": "STATUS_CHANGED",
"from": "OPEN",
"to": "IN_PROGRESS",
"by": "dev_one",
"timestamp": "2025-09-22"
},
{
"action": "DE-ASSIGNED",
"by": "dev_one",
"timestamp": "2025-09-23"
}
],
"comments": []
}
]
} 

Disponibilă pentru: Developer

Descriere: Afișează toate notificările primite de developer.

Comanda: viewNotifications

Exemplu Input:

{
"command": "viewNotifications",
"username": "user_name",
"timestamp": "2025-09-25"
} 

Exemplu Output:

{
"command": "viewNotifications",
"username": "user_name",
"timestamp": "2025-09-25",
"notifications": [
"<Notification 1>",
"<Notification 2>",
"<Notification 3>"
]
} 

Disponibilă pentru: Developer, Manager

Descriere: Permite căutarea avansată a tichetelor (sau a developerilor, în cazul managerilor) pe baza unor criterii de filtrare.

Comanda: search

1. Toate filtrele vor fi valide pentru rolul utilizatorului.

2. Dacă un filtru nu este specificat → nu se aplică filtrare pe acel câmp.

3. Dacă nu este specificat niciun filtru → comanda este echivalentă cu viewTickets.

4. Dacă nu există rezultate → se returnează o listă goală

• Poate căuta: doar tichete cu status OPEN din milestone-urile la care este repartizat
• Filtre disponibile:
  • businessPriority
  • type
  • createdAt
  • createdBefore
  • createdAfter
  • availableForAssignment

• Poate căuta: toate tichetele din sistem și developerii din subordine
• Filtre disponibile:
  • toate filtrele Developer
  • keywords
  • expertiseArea
  • seniority
  • performanceScoreAbove
  • performanceScoreBelow

Exemplu Input – Developer:

{
"command": "search",
"username": "dev_one",
"timestamp": "2025-09-26",
"filters": {
"searchType": "TICKET",
"businessPriority": "HIGH",
"type": "BUG",
"createdAfter": "2025-09-01",
"availableForAssignment": true
}
} 

Exemplu Output – Developer:

{
"command": "search",
"username": "dev_one",
"timestamp": "2025-09-26",
"searchType": "TICKET",
"results": [
{
"id": 0,
"type": "BUG",
"title": "Crash on settings page",
"businessPriority": "HIGH",
"status": "OPEN",
"createdAt": "2025-09-10",
"solvedAt": "",
"reportedBy": "cleopatra"
},
{
"id": 3,
"type": "BUG",
"title": "Data sync failure",
"businessPriority": "HIGH",
"status": "OPEN",
"createdAt": "2025-09-15",
"solvedAt": "",
"reportedBy": ""
}
]
} 

Exemplu Input – Manager (tickets):

{
"command": "search",
"username": "gabriel_manager",
"timestamp": "2025-09-26",
"filters": {
"searchType": "TICKET",
"keywords": ["pay", "bug"],
"businessPriority": "HIGH",
"type": "BUG",
"createdAfter": "2025-09-01"
}
} 

Exemplu Output – Manager (tickets):

{
"command": "search",
"username": "gabriel_manager",
"timestamp": "2025-09-26",
"searchType": "TICKET",
"results": [
{
"id": 5,
"type": "BUG",
"title": "Payment gateway error",
"businessPriority": "HIGH",
"status": "OPEN",
"createdAt": "2025-09-12",
"solvedAt": "",
"reportedBy": "user456",
"matchingWords": ["payment"]
}
]
} 

Exemplu Input – Manager (developers):

{
"command": "search",
"username": "gabriel_manager",
"timestamp": "2025-09-26",
"filters": {
"searchType": "DEVELOPER",
"expertiseArea": "BACKEND",
"seniority": "MID",
"performanceScoreAbove": number
}
} 

Exemplu Output – Manager (developers):

{
"command": "search",
"username": "gabriel_manager",
"timestamp": "2025-09-26",
"searchType": "DEVELOPER",
"results": [
{
"username": "dev_two",
"expertiseArea": "BACKEND",
"seniority": "MID",
"performanceScore": number,
"hireDate": "2024-05-10"
}
]
} 

Disponibilă pentru: Manager

Descriere: Generează raportul lunar de performanță pentru toți developerii din subordinea unui manager. În raport sunt incluse toate tichetele rezolvate (status CLOSED) din luna anterioară.

Comanda: generatePerformanceReport.

juniorPerformance = max(0, 0.5 * closedTickets - ticketDiversityFactor) + seniorityBonus

midPerformance = max(0, 0.5 * closedTickets + 0.7 * highPriorityTickets - 0.3 * averageResolutionTime) + seniorityBonus

seniorPerformance = max(0, 0.5 * closedTickets + 1.0 * highPriorityTickets - 0.5 * averageResolutionTime) + seniorityBonus

Puteți folosi următoarele metode pentru calculul numeric:

public static double averageResolvedTicketType(int bug, int feature, int ui) {
    return (bug + feature + ui) / 3.0;
}
 
public static double standardDeviation(int bug, int feature, int ui) {
    double mean = averageResolvedTicketType(bug, feature, ui);
    double variance = (Math.pow(bug - mean, 2) + Math.pow(feature - mean, 2) + Math.pow(ui - mean, 2)) / 3.0;
    return Math.sqrt(variance);
}
 
public static double ticketDiversityFactor(int bug, int feature, int ui) {
    double mean = averageResolvedTicketType(bug, feature, ui);
 
    // dacă nu există tichete, diversitatea este 0
    if (mean == 0.0) {
        return 0.0;
    }
 
    double std = standardDeviation(bug, feature, ui);
    return std / mean;
}

Exemplu Input:

{
  "command": "generatePerformanceReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-01"
}

Exemplu Output:

{
  "command": "generatePerformanceReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-01",
  "report": [
    {
      "username": "dev_one",
      "closedTickets": 5,
      "averageResolutionTime": 4.2,
      "performanceScore": 88.56,
      "seniority": "SENIOR"
    },
    {
      "username": "dev_two",
      "closedTickets": 3,
      "averageResolutionTime": 5.0,
      "performanceScore": 75.00,
      "seniority": "MID"
    }
  ]
}

Disponibilă pentru: Manager

Descriere: Generează un raport pe baza metricii ticket risk.

Comanda: generateTicketRiskReport

Calculare:

frequency = ALWAYS (4)  
severityFactor = SEVERE (3)

Risc brut = 4 × 3 = 12  
Risc final = (12 × 100) / 12 = 100.00

businessValue = XL (10)  
customerDemand = HIGH (6)

Risc brut = 10 + 6 = 16  
Risc final = (16 × 100) / 20 = 80.00

usabilityScore = 2  
businessValue = XL (10)

Risc brut = (11 − 2) × 10 = 90  
Risc final = (90 × 100) / 100 = 90.00

În urma raportului, fiecare categorie va avea un calificativ:

Exemplu Input:

{
"command": "generateTicketRiskReport",
"username": "gabriel_manager",
"timestamp": "2025-09-30"
} 

Exemplu Output:

{
"command": "generateTicketRiskReport",
"username": "gabriel_manager",
"timestamp": "2025-09-30",
"report": {
"totalTickets": 20,
"ticketsByType": {
"BUG": 10,
"FEATURE_REQUEST": 6,
"UI_FEEDBACK": 4
},
"ticketsByPriority": {
"LOW": 5,
"MEDIUM": 7,
"HIGH": 6,
"CRITICAL": 2
},
"riskByType": {
"BUG": "NEGLIGIBLE",
"FEATURE_REQUEST": "MODERATE",
"UI_FEEDBACK": "SIGNIFICANT"
}
}
} 

Disponibilă pentru: Manager

Descriere: Evaluează cât de eficientă este echipa în a rezolva tichete. Se vor considera doar tichete în stările RESOLVED și CLOSED.

Comanda: generateResolutionEfficiencyReport

Calculare:

frequency = FREQUENT (3)
severityFactor = MODERATE (2)
daysToResolve = 2

Scor eficiență = (3 + 2) × 10 / 2 = 25
Eficiență finală = (25 × 100) / 70 = 35.71

businessValue = L (6)
customerDemand = HIGH (6)
daysToResolve = 2

Scor eficiență = (6 + 6) / 2 = 6.00
Eficiență finală = (6 × 100) / 20 = 30.00

usabilityScore = 9
businessValue = XL (10)

Scor eficiență = (9 + 10) / 2 = 9.5
Eficiență finală = (9.5 × 100) / 20 = 47.50

Exemplu Input:

{
  "command": "generateResolutionEfficiencyReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-30"
}

Exemplu Output:

{
  "command": "generateResolutionEfficiencyReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-30",
  "report": {
    "totalTickets": 20,
    "ticketsByType": {
      "BUG": 10,
      "FEATURE_REQUEST": 6,
      "UI_FEEDBACK": 4
    },
    "ticketsByPriority": {
      "LOW": 5,
      "MEDIUM": 7,
      "HIGH": 6,
      "CRITICAL": 2
    },
    "efficiencyByType": {
      "BUG": 65.50,
      "FEATURE_REQUEST": 55.30,
      "UI_FEEDBACK": 40.25
    }
  }
}

Disponibilă pentru: Manager

Descriere: Estimează impactul asupra clienților al tichetelor.

Comanda: generateCustomerImpactReport

Calculare:

frequency = ALWAYS (4)  
businessPriority = CRITICAL (4)  
severityFactor = SEVERE (3)

Impact brut = 4 × 4 × 3 = 48  
Impact final = (48 × 100) / 48 = 100.00

businessValue = M (3)  
customerDemand = HIGH (6)

Impact brut = 3 × 6 = 18  
Impact final = (18 × 100) / 100 = 18.00

businessValue = L (6)  
usabilityScore = 9

Impact brut = 6 × 9 = 54  
Impact final = (54 × 100) / 100 = 54.00

Exemplu Input:

{
  "command": "generateCustomerImpactReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-30"
}

Exemplu Output:

{
  "command": "generateCustomerImpactReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-30",
  "report": {
    "totalTickets": 20,
    "ticketsByType": {
      "BUG": 10,
      "FEATURE_REQUEST": 6,
      "UI_FEEDBACK": 4
    },
    "ticketsByPriority": {
      "LOW": 5,
      "MEDIUM": 7,
      "HIGH": 6,
      "CRITICAL": 2
    },
    "customerImpactByType": {
      "BUG": 75.55,
      "FEATURE_REQUEST": 60.05,
      "UI_FEEDBACK": 45.02
    }
  }
}

Disponibilă pentru: Manager

Descriere: Generează un raport de stabilitate al aplicației, pe baza metricii Ticket Risk și a metricii Customer Impact.

Comanda: appStabilityReport

1. Dacă nu există tichete OPEN sau IN_PROGRESS, aplicația este considerată STABLE.

2. Dacă toate categoriile de risc sunt NEGLIGIBLE și impactul pentru clienți este sub 50 pentru toate tipurile de tichet, aplicația este considerată STABLE.

3. Dacă există cel puțin o categorie de risc SIGNIFICANT, aplicația este considerată UNSTABLE.

4. În celelalte cazuri, aplicația este considerată PARTIALLY STABLE.

5. Dacă aplicația este STABLE, aplicația își încheie execuția și nu mai sunt procesate alte comenzi.

Exemplu Input:

{
  "command": "appStabilityReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-30"
}

Exemplu Output: Exemplu Output:

{
  "command": "appStabilityReport",
  "username": "gabriel_manager",
  "timestamp": "2025-09-30",
  "report": {
    "totalOpenTickets": 15,
    "openTicketsByType": {
      "BUG": 8,
      "FEATURE_REQUEST": 5,
      "UI_FEEDBACK": 2
    },
    "openTicketsByPriority": {
      "LOW": 3,
      "MEDIUM": 6,
      "HIGH": 4,
      "CRITICAL": 2
    },
    "riskByType": {
      "BUG": "SIGNIFICANT",
      "FEATURE_REQUEST": "MODERATE",
      "UI_FEEDBACK": "NEGLIGIBLE"
    },
    "impactByType": {
      "BUG": 87.45,
      "FEATURE_REQUEST": 42.30,
      "UI_FEEDBACK": 5.75
    },
    "appStability": "UNSTABLE"
  }
}

În rezolvarea temei va fi nevoie de folosirea unor obiecte pentru stocarea și maparea datelor primite în format JSON. Scheletul temei vă oferă mai multe clase utile pentru citirea și rularea temei. Acestea se regăsesc în cadrul scheletului, astfel:

• Clasele de input din cadrul pachetului fileio: Acestea se vor folosi pentru parsarea datelor de input. Astfel, preluați toate informațiile necesare pentru a crea propriile clase pentru rezolvarea temei.
• Clasa Main care este punctul de intrare pentru logica de rezolvare a temei.

Pentru a rula checker-ul intrați în fișierul “src/test/java/TestRunner” și rulați clasa.

O să vi se deschidă un panou în IntelliJ de unde puteți vedea statusul tuturor testelor. De asemenea, vi se va afișa și eroarea sau diferența rezultatului pe care îl aveți pentru fiecare test în parte.

• Tema a fost concepută pentru a vă testa cunoștințele dobândite în urma parcurgerii laboratoarelor 1-6, aceasta putând fi rezolvată doar cu noțiunile invățate din acele laboratoare.
• Tema fiind o specificație destul de stufoasă recomandăm citirea de cel putin două ori a enunțului inainte de inceperea implementării.

Puteți folosi modele de limbaj (LLM-uri) pentru asistență în realizarea temei doar ca instrument suplimentar, de exemplu pentru clarificări, explicații sau verificarea ideilor.

Totuși, recomandarea noastră este să încercați să rezolvați tema pe cont propriu, fără a depinde de astfel de instrumente. Scopul exercițiului este să învățați și să vă dezvoltați abilitățile, iar progresul real vine doar prin înțelegere și practică personală.

Puteți folosi LLM-uri pentru:

• explicații teoretice.
• exemple suplimentare.
• verificarea codului sau a ideilor.
• clarificarea unor concepte.

NU este acceptat să:

• trimiteți soluții generate integral de un LLM.
• folosiți cod sau text pe care nu îl înțelegeți.
• copiați fără să puteți explica ce ați făcut în cod.
• generați README-ul folosind un LLM.

Punctajul constă din:

• 80p implementare - trecerea testelor
• 10p coding style (vezi checkstyle)
• 5p README.md clar, concis, explicații axate pe design (flow, interacțiuni)
• 5p folosire git pentru versionarea temei

Depunctările pentru temă sunt acoperite în barem, totuși pot apărea depunctări care nu se află în imaginile furnizate.

Bonusuri: La evaluare, putem oferi bonusuri pentru design foarte bun, cod bine documentat dar și pentru diverse elemente suplimentare.

Folosirea git pentru versionare va fi verificata din folderul .git pe care trebuie să îl includeți în arhiva temei. Punctajul se va acorda dacă ați făcut minim 3 commit-uri relevante și cu mesaj sugestiv. NU este permis să aveți repository-urile de git publice până la deadline-ul hard.

Unul din obiectivele temei este învățarea respectării code-style-ului limbajului pe care îl folosiți. Aceste convenții (de exemplu cum numiți fișierele, clasele, variabilele, cum indentați) sunt verificate pentru temă de către tool-ul checkstyle (care se află în pom.xml ca dependență).

Pe pagina de Recomandări cod găsiți câteva exemple de coding style.

Dacă numărul de erori depistate de checkstyle depășește 30, atunci punctele pentru coding-style nu vor fi acordate. Dacă punctajul este negativ, acesta se trunchiază la 0.

Exemple:

• punctaj_total = 100 și nr_erori = 200 ⇒ nota_finala = 90
• punctaj_total = 100 și nr_erori = 29 ⇒ nota_finala = 100
• punctaj_total = 80 și nr_erori = 30 ⇒ nota_finala = 80
• punctaj_total = 80 și nr_erori = 31 ⇒ nota_finala = 70

1. in_01_test_report.json
2. in_02_test_milestone.json
3. in_03_test_milestone_edge_case.json
4. in_04_test_assign.json
5. in_05_test_assign_edge_case.json
6. in_06_test_comment.json
7. in_07_test_comment_edge_case.json
8. in_08_test_status_change.json
9. in_09_test_status_undo_change.json
10. in_10_test_status_edge_case.json
11. in_11_test_search.json
12. in_12_test_notifications.json
13. in_13_test_metrics_customer_impact.json
14. in_14_test_metrics_ticket_risk.json
15. in_15_test_metrics_efficiency.json
16. in_16_test_stability.json
17. in_17_test_performance.json
18. in_18_test_complex.json
19. in_19_test_complex_edge_case.json

Arhiva o veţi urca pe Code Devmind, unde sunt si informații despre structura ei.

Q: Pot folosi biblioteca “X”?
A: Dacă doriți să folosiți o anumită bibliotecă vă recomandăm să întrebați pe forum, ca apoi să o validăm și să o includem și în pom-ul de pe Code Devmind.

Q: Pot folosi GSON în loc de Jackson?
A: Sigur, contează doar să aveți output-ul corect și să respectați convențiile de coding style și modularitate.

Q: Am descoperit edge case-ul “Y”, trebuie să îl tratez?
A: Nu. Toate datele necesare pentru soluționarea temei vă sunt date in cerință. Dacă totuși am omis ceva ne puteți contacta pe forum.

Q: Pot folosi clase de tip “Enum” pentru constante?
A: Da.

Q: Ce JDK recomandați?
A: 25

Q: Pot să fac în orice ordine testele?
A: Depinde. Testele au fost concepute sa fie cât mai decuplate și să testeze câte o funcționalitate în întregime. Cu toate astea, vă recomandăm să implementați mai întâi testele 01, 02, 03 deoarece reprezintă funcționalitățile de bază pentru rezolvarea următoarelor teste mai complexe.

• Schelet de cod
• Forum
• Indicații pentru teme
• Recomandări coding style & javadoc
• Tutorial Git