← Portfolio
ΟΠΑ · Ομάδα 13 · 2023–2024 → Solo Rebuild & Deployment · 2024
WorkPortal
HR Self-Service Portal
Η G4S Ελλάς είχε 2.400 φρουρούς ασφαλείας αποκομμένους από το HR. Ανέλυσα σε βάθος το πρόβλημα (μεθοδολογία SSM/CATWOE) και έφτιαξα μια live, αμφίδρομη πύλη HR.
🏛️ ΟΠΑ · 2023–2024
☕ Java 17 · Jakarta Servlets
🗄️ SQLite · Docker
🌐 Live · Koyeb
📋 SSM · CATWOE · UML
Σύνοψη — για recruiters
Builder & Systems Analyst · Ανάλυση & Σχεδιασμός ΠΣ · ΟΠΑ 2023–24 → Solo rebuild & deployment
Η G4S Ελλάς είχε δομικό πρόβλημα επικοινωνίας: 2.400 φρουροί περνούσαν από 3 επίπεδα ιεραρχίας για κάθε αίτημα προς το HR. Phase 1 (ομάδα 4 ατόμων): ανέλαβα το frontend και συνεισέφερα σε backend & βάση δεδομένων — παραδώσαμε λειτουργική εφαρμογή. Phase 2 (solo, δική μου πρωτοβουλία): production-ready rebuild — νέο backend, πλήρες redesign frontend, containerization & cloud deployment στο Koyeb.
ΑΝΤΙΚΤΥΠΟΣ
Πλήρης αμφίδρομη HR πύλη: παράπονα, άδειες, συναντήσεις — όλα απευθείας, χωρίς μεσολαβητή. 9/10 use cases υλοποιήθηκαν. Live deployment στο 0€/μήνα.
SSM · CATWOE · Use Cases
Java 17 · Servlets · JSP
Docker · Cloud Deploy
Ανάλυση Απαιτήσεων
Σχεδιασμός ΒΔ
Χρόνια δομική αδυναμία επικοινωνίας
01 — Το Πρόβλημα · G4S Ελλάς · ~2.400 φρουροί ασφαλείας · 3 επίπεδα ιεραρχίας
Κάθε αίτηση άδειας, παράπονο ή ραντεβού με το HR περνούσε από τρία επίπεδα ιεραρχίας — καθυστερήσεις ημερών, παραμόρφωση πληροφορίας, αίσθηση αδικίας.
Πριν — Μονόδρομη Επικοινωνία
Οδηγίες μόνο από πάνω προς τα κάτω
Αίτηση → επόπτης → προϊστάμενος → HR: καθυστέρηση ημερών
Τηλεφωνικές επικοινωνίες χωρίς καταγραφή ή ιστορικό
Επόπτες επιβαρύνονταν διοικητικά αντί να εποπτεύουν
Το HR δεν είχε πρόσβαση στην πρώτη γραμμή άμεσα
Μετά — Αμφίδρομη Πύλη
Κάθε εργαζόμενος έχει εταιρικό λογαριασμό
Άμεση υποβολή αιτημάτων — παρακάμπτεται η αλυσίδα
Δομημένες, παρακολουθήσιμες απαντήσεις HR
Πρόγραμμα εργασίας & ανακοινώσεις ορατά αμέσως
Ασφαλής αυθεντικοποίηση ανά ρόλο (Εργαζόμενος / HR)
Soft Systems Methodology & CATWOE
02 — Μεθοδολογία · Peter Checkland · 5 στάδια ανάλυσης → root definition
Το πρόβλημα ήταν κακώς δομημένο — φρουροί, επόπτες, HR και IT έβλεπαν το ίδιο ζήτημα διαφορετικά. Αντί να επιβάλω μια λύση, κατέγραψα κάθε οπτική μέσω SSM (μεθοδολογία που αναλύει προβλήματα μέσα από τις οπτικές των εμπλεκομένων, όχι μία "σωστή" αντικειμενική εικόνα) και την κατέληξα σε root definition με ανάλυση CATWOE (6 στοιχεία — πελάτες, δράστες, μετασχηματισμός, κοσμοθεωρία, ιδιοκτήτης, περιβάλλον — που ορίζουν καθαρά τον σκοπό ενός συστήματος).
1
Έκφραση Προβλήματος
Συνεντεύξεις με 4 στελέχη G4S — rich picture υφιστάμενης κατάστασης
2
Χαρτογράφηση Stakeholders
5 ομάδες με διαφορετικά συμφέροντα και κοσμοθεωρίες
3
Root Definitions / CATWOE
5 root definitions — μία για κάθε ομάδα stakeholders
4
Εννοιολογικό Μοντέλο
9 βασικές δραστηριότητες που πρέπει να υποστηρίζει το σύστημα
5
Σύγκριση & Αλλαγές
10 use cases που οδήγησαν απευθείας στο σχεδιασμό
CATWOE — Οπτική Φρουρών Ασφαλείας
C
Customers — Πελάτες
Φρουροί ασφαλείας που επωφελούνται από άμεση επικοινωνία με HR
A
Actors — Ενεργοί
IT και HR που βελτιστοποιούν την αλληλεπίδραση φρουρού-τμήματος
T
Transformation
Αποσπασματική, μονόδρομη επικοινωνία → άμεση, αμφίδρομη πρόσβαση
W
Worldview — Κοσμοθεωρία
Η άμεση επικοινωνία βελτιώνει εργασιακή ικανοποίηση & απόδοση
O
Owner — Ιδιοκτήτης
Διοίκηση G4S Ελλάς — εξουσιοδότηση και ευθύνη για το σύστημα
E
Environment — Περιβάλλον
Γεωγραφικά κατανεμημένο δυναμικό, GDPR, περιορισμοί ψηφιακής εμπειρίας
Use Cases
03 — Σχεδιασμός · 10 use cases · 9 υλοποιήθηκαν στο v1
| ID |
Use Case |
Χρήστες |
Κατάσταση |
| UC1 |
Διαχείριση Προφίλ |
ΕργαζόμενοςHRIT |
✓ Πλήρης |
| UC2 |
Υποβολή & Απάντηση Αιτήματος |
ΕργαζόμενοςHR |
✓ Πλήρης αμφίδρομη ροή |
| UC3 |
Έκδοση Μισθοδοτικής Απόδειξης |
ΕργαζόμενοςHR |
~ Μοντελοποιήθηκε · εκτός v1 |
| UC4 |
Υποβολή Παραπόνου |
Εργαζόμενος |
✓ Πλήρης ροή |
| UC5 |
Ορισμός Συνάντησης |
Εργαζόμενος |
✓ Με επιλογή συμμετεχόντων |
| UC6 |
Αίτημα Άδειας / Ρεπό |
Εργαζόμενος |
✓ Πλήρης ροή έγκρισης |
| UC7 |
Εταιρικές Ανακοινώσεις |
ΕργαζόμενοςIT |
✓ Αρχική σελίδα εργαζομένου |
| UC8 |
Δημοσίευση Προγράμματος |
HR |
✓ Μέσω αποδοχής αιτήματος |
| UC9 |
Τροποποίηση Προγράμματος |
HR |
~ Μόνο μέσω ροής έγκρισης |
| UC10 |
Εκπαίδευση Προσωπικού |
HRIT |
✗ Προγραμματισμένο για v2 |
Σχέσεις: UC2 «περιλαμβάνει» UC4, UC5, UC6 · UC8 «επεκτείνεται από» UC9
Αρχιτεκτονική & Κρίσιμα Patterns
04 — Engineering · Three-tier MVC · Thread-safety & transactional persistence
Κλασική τριεπίπεδη αρχιτεκτονική — παρουσίαση (JSP), λογική (Servlets/Services), δεδομένα (SQLite) — πλήρως διαχωρισμένη.
Παρουσίαση
JSP Views
employee/* JSP
hr/* JSP
login.jsp
escapeHtml.jsp
shared components
Λογική
Servlets / Services
AuthFilter (@WebFilter)
RequestServlet
AnswerService
MeetingService
LeaveService
Δεδομένα
SQLite + DAOs
employees
hr_users
requests / answers
meeting_participants
Auto-seeded schema
Κρίσιμα Patterns
private static volatile boolean initialized = false;
private static final Object LOCK = new Object();
public static Connection getConnection() throws SQLException {
Connection conn = DriverManager.getConnection(URL);
conn.createStatement().execute("PRAGMA journal_mode=WAL"); // βελτιώνει ταυτόχρονη ανάγνωση
conn.createStatement().execute("PRAGMA foreign_keys=ON");
if (!initialized) {
synchronized (LOCK) {
if (!initialized) { // double-check locking
initSchema(conn);
initialized = true;
}
}
}
return conn;
}
conn.setAutoCommit(false); // ξεκινά transaction
try {
// 1. Εισαγωγή απάντησης
PreparedStatement ins = conn.prepareStatement(
"INSERT INTO answers VALUES (?,?,?,?,?)");
// 2. Ενημέρωση κατάστασης αιτήματος
PreparedStatement upd = conn.prepareStatement(
"UPDATE requests SET status=? WHERE request_id=?");
conn.commit(); // και οι δύο ή κανένας
} catch (SQLException ex) {
conn.rollback();
throw ex;
}
Production Readiness
05 — Ασφάλεια & Deployment · 4 μηχανισμοί προστασίας · Docker → Koyeb · 0€/μήνα
Αυθεντικοποίηση Session
Session-based (Jakarta Servlet) · Employee_obj για εργαζόμενο, HR flag για HR · auto-expire μετά 30' αδράνειας.
Έλεγχος Πρόσβασης
AuthFilter (@WebFilter("/*")) ελέγχει κάθε URL για σωστό ρόλο πριν εκτελεστεί — κανένα endpoint χωρίς authentication.
SQL Injection Protection
Όλα τα queries χρησιμοποιούν αποκλειστικά PreparedStatements — μηδέν string concatenation σε SQL.
XSS Protection
Όλα τα JSP outputs περνούν από escapeHtml.jsp πριν αποδοθούν — δεν εκτελείται user input ως HTML (XSS = επίθεση όπου κακόβουλος κώδικας "τρέχει" μέσα σε μια σελίδα που εμπιστεύεσαι).
⚠️ Γνωστός Περιορισμός v1 — Κωδικοί σε Plaintext
Οι κωδικοί αποθηκεύονται χωρίς κατακερματισμό. Το v2 πρέπει να χρησιμοποιεί bcrypt ή Argon2 πριν από οποιοδήποτε production deployment. Τεκμηριωμένο στο roadmap.
Docker + Koyeb Cloud
Στάδιο 1 (Build)Maven 3.9 + JDK 17 Alpine
Στάδιο 2 (Runtime)Tomcat 10.1 + JRE 17
Αρχικό μέγεθος~600 MB
Τελικό μέγεθος~220 MB
ArtifactROOT.war
RegionFrankfurt (EU)
Πόροι512 MB RAM · 0.1 vCPU
ΑποθήκευσηKoyeb volume /data
JVM flags-Xmx180m · SerialGC
Κόστος0€ / μήνα
# Στάδιο 1: Build — Maven compiles → ROOT.war
FROM maven:3.9-eclipse-temurin-17-alpine AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -q
COPY src/ src/
RUN mvn package -q -DskipTests
# Στάδιο 2: Runtime — μόνο Tomcat + JRE, χωρίς Maven/JDK
FROM tomcat:10.1-jre17-temurin-jammy
RUN rm -rf /usr/local/tomcat/webapps/*
COPY --from=build /app/target/ROOT.war /usr/local/tomcat/webapps/ROOT.war
RUN mkdir -p /data && chmod 777 /data
EXPOSE 8080
ENV JAVA_OPTS="-Xms48m -Xmx180m -XX:+UseSerialGC -XX:MaxMetaspaceSize=80m"
CMD ["catalina.sh", "run"]
Τεχνολογίες — Γλωσσάρι
Σύντομες εξηγήσεις για όρους που εμφανίστηκαν παραπάνω
JVM · JDK · JRE
Το JVM (Java Virtual Machine) είναι το "μηχάνημα" που εκτελεί κώδικα Java. Το JRE (Java Runtime Environment) περιέχει το JVM ώστε να τρέχεις προγράμματα. Το JDK (Java Development Kit) προσθέτει και τα εργαλεία για να τα γράψεις/χτίσεις — γι' αυτό το build στάδιο του Docker χρειάζεται JDK, το runtime στάδιο μόνο JRE.
MVC (Model-View-Controller)
Μοτίβο αρχιτεκτονικής που χωρίζει μια εφαρμογή σε 3 ρόλους: δεδομένα (Model), οθόνη (View), λογική (Controller) — εδώ: SQLite, JSP, Servlets/Services αντίστοιχα.
WAL (Write-Ahead Logging)
Τρόπος λειτουργίας της βάσης όπου κάθε αλλαγή γράφεται πρώτα σε ένα log αρχείο πριν εφαρμοστεί στα δεδομένα — επιτρέπει ταυτόχρονη ανάγνωση/εγγραφή χωρίς να μπλοκάρουν η μία την άλλη.
Roadmap Ανάπτυξης
06 — Μέλλον · 6 φάσεις εξέλιξης για production-grade σύστημα
1
Ασφάλεια (Υψηλή Προτεραιότητα)
bcrypt/Argon2 hashing · CSRF tokens (εμποδίζουν κακόβουλες σελίδες να στέλνουν αιτήματα εν αγνοία σου) · υποχρεωτικό HTTPS · audit log για ευαίσθητες ενέργειες HR.
2
Βάση Δεδομένων
SQLite → PostgreSQL για κλίμακα παραγωγής — η αρχιτεκτονική ήδη υποστηρίζει concurrent writes σε μεγάλη κλίμακα.
3
Ελλείπουσες Λειτουργίες
Μισθοδοτική Απόδειξη (UC3) · Εκπαίδευση Προσωπικού (UC10) · UI διαχείρισης λογαριασμών για IT.
4
Ειδοποιήσεις
Email/push για αλλαγές κατάστασης αιτήματος — οι εργαζόμενοι δεν χρειάζεται να συνδέονται για να ελέγχουν.
5
Mobile Εφαρμογή
Native Android/iOS — οι φρουροί πεδίου χρησιμοποιούν κυρίως smartphone, όχι desktop.
6
Αναλυτικά HR
Reporting dashboard: χρόνοι απόκρισης, τάσεις αιτημάτων, ικανοποίηση εργαζομένων — μετρήσιμος αντίκτυπος.
Πηγές & Συνεντεύξεις
07 — Πλαίσιο · Ομάδα 13 · ΟΠΑ 2023–2024 · Ανάλυση & Σχεδιασμός ΠΣ
Το WorkPortal αναπτύχθηκε στο μάθημα Ανάλυση & Σχεδιασμός Πληροφοριακών Συστημάτων, βασισμένο σε πραγματικές συνεντεύξεις με στελέχη της G4S Ελλάς. Phase 1 (ομάδα 4 ατόμων): frontend + συνεισφορά σε backend & βάση δεδομένων. Phase 2 (solo, δική μου πρωτοβουλία): πλήρες production rebuild — νέο backend, redesign frontend, cloud deployment.
| Όνομα | Ρόλος |
| Χρήστος Ντίσκος | IT Director, Κεντρική & Νότια Ευρώπη |
| Ηλίας Χονδρός | Διευθυντής HR |
| Φοίβος Παππάς | IT Project Manager |
| Χριστίνα Καπού | On Call Rostering |
Το WorkPortal δείχνει πώς η σωστή μεθοδολογία (SSM/CATWOE) οδηγεί σε σχεδιαστικές αποφάσεις που λύνουν το πραγματικό πρόβλημα — όχι αυτό που υποθέτει κανείς εκ των προτέρων. Κάθε use case, πίνακας βάσης και servlet αντικατοπτρίζει μια root definition που προέκυψε από πραγματικές συνεντεύξεις.
Σπήλιος Δημακόπουλος · ΟΠΑ Ομάδα 13 · 2023–2024