Σχόλια Διαβούλευσης για το σύστημα ηλεκτρονικού πρωτοκόλλου και διαχείρισης υποθέσεων

Από: Γιάννης Μερκούρης [30/09]

Ανταποκρινόμενος στην πρόσκλησή σας για υποβολή παρατηρήσεων στις προδιαγραφές του έργου “Σύστημα ηλεκτρονικού πρωτοκόλλου και διαχείρισης υποθέσεων”, προτείνω τον εμπλουτισμό του με τα παρακάτω χαρακτηριστικά: α. Δυνατότητα αναζητήσεων - τόσο σε queries, βάσει π.χ. κανονικοποιημένων tokens στη Β.Δ., όσο και εντός των εγγράφων (αναζήτηση σε πλήρες κείμενο) βάσει μεταdάτα και συνωνύμων (κανονικοποιημένων για πληρέστερα αποτελέσματα)

β. Δημιουργία εγγράφων από πρότυπα “templates” (σχεδίου) που θα επικοινωνούν με τη Β.Δ. (π.χ. μέσω office automation) και η δημιουργία ακριβών αντιγράφων από αυτά.

γ. Ηλεκτρονική υπογραφή, ένα υποσύστημα που θα εξυπηρετεί το [β] ανωτέρω.

δ. State Model, το οποίο μπορεί να υποστηρίξει και την πορεία των εγγράφων αλλά και των εργασιών της κάθε π.χ. διεύθυνσης/τμήματος/υπαλλήλου Σύνδεση με τα υποσυστήματα που αφορούν τις επιμέρους εργασίες των τμημάτων:

ε. Σύνδεση του συστήματος ηλ/κου πρωτ., που είναι ένα σύστημα ‘γενικού σκοπού’ μέσα σε μία δημόσια υπηρεσία, με τα ‘ιδιαίτερα’ συστήματά της υπηρεσίας αυτής.

στ. Σαν συμπλήρωμα της προδιαγραφής “Αναφορές και Στατιστικά Κίνησης Εγγράφων " του υποσυστήματος αναθέσεων και παρακολούθησης υπόθεσης: προβλέψεις για το μέλλον σε επίπεδο προσωπικού ή εργασιών. Τέλος, ένα σχόλιο επάνω στην επισύναψη/συσχέτιση, που αναφέρεται στις προδιαγραφές 4 και 11 του υποσυστήματος αναθέσεων και παρακολούθησης υπόθεσης : ζ. Το έγγραφο, τα σχόλια ή άλλα (συμπληρωματικά) έγγραφα ίσως πρέπει να επισυνάπτονται στο στάδιο στο οποίο βρίσκεται η υπόθεση και να συνδέονται και με μέλη των συνόλων “τμημάτων, θέσεων εργασίας, υπαλλήλων, των αποστολέων, παραληπτών, πινάκων αποδεκτών, φακέλων αρχείου, θεμάτων” Κάποια από αυτά τα χαρακτηριστικά έχουν ήδη υλοποιηθεί για το σύστημα “Τρικούπης 2009”, μέρη του οποίου περιγράφονται στο http://trikoupis.110mb.com, το οποίο, αν και δεν αναπτύχθηκε με τη βοήθεια εργαλείων ανοικτού λογισμικού, έχει σαν στόχο την ενθάρρυνση της αυτόνομης ανάπτυξης λογισμικού από τα ίδια τα τμήματα των Υπηρεσιών.

Από: Διονύσης Κοζάκης [30/09]

Σχόλια

Από: Θεόδωρος Ξυδέας [30/09]

1.Να υποστηρίζει την λειτουργία πολλών διαφορετικών βιβλίων πρωτοκόλλου σε ένα φορέα

2.Να διαχειρίζεται ροές εργασιών που αφορούν την διακίνηση εγγράφων και την διεκπεραίωσή τους. Οι ροές εργασιών να ορίζονται παραμετρικά (βήματα, κανόνες) και με τη χρήση γραφικού εργαλείου

3.Να υποστηρίζει πολλαπλές φόρμες αρχειοθέτησης των εγγράφων (με metadata), έτσι ώστε να είναι δυνατή η τήρηση πληροφοριών για ένα έγγραφο με βάση το είδος του. Οι φόρμες αρχειοθέτησης να ορίζονται παραμετρικά

4.Να ψηφιοποιεί μαζικά εισερχόμενα πολυσέλιδα έγγραφα (σε χαρτί) με την χρήση scanner, που θα εισάγονται στην βάση δεδομένων και θα συνδέονται αυτόματα με τον αριθμό πρωτοκόλλου, ως εξής:

Α) Να εκδίδει αποδεικτικό πρωτοκόλλησης εισερχομένου εγγράφου με χρήση αυτοκόλλητης ετικέτας στην οποία θα εκτυπώνεται barcode η οποία θα επικολλείται στην 1η σελίδα του εγγράφου (θα αποτυπώνεται ο αριθμός πρωτοκόλλου, η ημερομηνία πρωτοκόλλησης και το βιβλίο πρωτοκόλλου φορέα)

Β) Να ψηφιοποιεί μαζικά στοίβα εγγράφων με χρήση scanner. Κάθε έγγραφο μπορεί να είναι πολυσέλιδο και φέρει μόνο στην 1η σελίδα του την αυτοκόλλητη ετικέτα barcode (βήμα Α). Η εφαρμογή θα διαχωρίζει αυτόματα τα διαφορετικά έγγραφα

Γ) Να εισάγει αυτόματα κάθε ψηφιοποιημένο έγγραφο (βήμα Β) στην Βάση Δεδομένων και να το συνδέει με την ήδη καταχωρημένη εγγραφή (record) του που περιέχει τον σχετικό αριθμό πρωτοκόλλου Να παρέχει πλήρη διαχείριση σε περιπτώσεις σφαλμάτων (πρόσθεση/αφαίρεση σελίδας σε έγγραφο, αφαίρεση ψηφιοποιημένου εγγράφου από αριθμό πρωτοκόλλου)

Από: Κοντογιάννης Παναγιώτης [30/09]

Σχόλια

Από: Στέφανος Κουζώφ [30/09]

Δύο Ενδεικτικά Σχόλια:

1. Κάντε μια ανάλυση των απαιτήσεων, και φαντάζομαι πολλές από τις υφιστάμενες θα εξαφανιστούν (πχ Υποστήριξη πολλαπλών σαρωτών ανά θέση εργασίας - αυτό δεν είναι δουλειά του λειτουργικού συστήματος;)

2. Όλα αυτά (λεξικά, OCR, IMAP κλπ κλπ) θέλουν παραμετροποίηση, ΠΟΙΟΣ θα είναι σε θέση να γνωρίζει τόσο καλά την εφαρμογή για να τα στήσει;

Με τέτοιες προδιαγραφές θα είναι πάλι ένα γιγάντιο project που δε θα τελειώσει ποτέ.

Πρόταση:

Οι προδιαγραφές του συστήματος έτσι όπως είναι δημοσιευμένες αποκλείουν κάθε έτοιμη λύση, και προφανώς δυσκολεύουν την υλοποίηση. Αν μιλάμε για ένα software stack, τότε προτείνω ως λύση την ανάπτυξη μιας εξειδικευμένης ΔΙΑΝΟΜΗΣ (πχ κάτι σαν αυτή της MAGENTA) που να τα έχει όλα αυτά ΠΡΟ-Παραμετροποιημένα.

Ειδάλλως, προτείνω η εφαρμογή να ξεκινήσει όσο το δυνατόν ΑΠΛΟΥΣΤΕΡΗ με τις ΕΛΑΧΙΣΤΕΣ ΑΠΑΙΤΟΥΜΕΝΕΣ ΛΕΙΤΟΥΡΓΙΕΣ ώστε η εφαρμογή να είναι ΓΡΗΓΟΡΗ και ΦΤΗΝΗ στην ανάπτυξη.

Αυτή είναι και η μέθοδος ανάπτυξης του ανοικτού λογισμικού. Δεινόσαυρους (όπως οι προδιαγραφές αυτού) μόνο σε κλειστό λογισμικό και σε Δημόσιο βρίσκεις.

Από: Βλάσης Μανθογιάννης [28/09]

Θέλοντας να συμμετάσχω στην παρούσα Δημόσια διαβούλευση καταθέτω τα παρακάτω σχόλια:

Στο Ελληνικό Δημόσιο κάθε υπηρεσία έχει και ένα ηλεκτρονικό πρωτόκολλο, που κατά κύριο λόγο δεν χρησιμοποιεί, γιατί με αυτό τον τρόπο θα απαξιωθούν οι θέσεις εργασίας πρωτοκόλλου (οι οποίες είναι πολλές) και οι υπάλληλοι που τις στελεχώνουν θα πρέπει να αναζητήσουν άλλες θέσεις για να βολευτούν.

Υπάρχουν μάλιστα φορείς που έχουν παραπάνω από ένα πρωτόκολλο, για παράδειγμα το το Υπ. Εσωτερικών – Προεδρίας – Δημόσια Διοίκησης κ.λ.π, το οποίο έχει καμιά 50αριά σχετικές εφαρμογές στις διάφορες υπηρεσίες του, με αποτέλεσμα να χρειάζεται ένα σύστημα πρωτοκόλλου για τις διαφορετικές εφαρμογές πρωτοκόλλου, που χρησιμοποιεί.

Σε αυτή την διαβούλευση επιχειρείτε να γίνει μία ακόμα εφαρμογή πρωτοκόλλου, που θα προστεθεί σε όλες τις άλλες, χωρίς να έχει κατ’ ουσίας να προσφέρει κάτι παραπάνω.

Ζητείται αυτή η εφαρμογή να εγκαθίσταται με το πάτημα ενός κουμπιού και να καλύπτει ως δια μαγείας όλες τις ανάγκες και όλες τις ιδιαιτερότητες της υπηρεσίας, που εγκαθίσταται. Πχ να εντοπίζει τους χρήστες και τις αρμοδιότητές τους, να εντοπίζει τις διαδικασίες και να δημιουργεί τις ροές, να είναι WEB based αλλά και να δουλεύει off-line με τοπικά έγγραφα, κ.λ.π.

Όλα αυτά θα γίνουν σχεδόν από την αρχή και η απαίτηση φυσικά είναι το σύστημα που θα φτιαχτεί να είναι καλύτερο και πιο αποτελεσματικό από τα αντίστοιχα Ελληνικά ή Διεθνή λογισμικά στα οποία έχουν επενδυθεί χρόνια και χρόνια για ανάπτυξη από εξειδικευμένους στο αντικείμενο (DMS, WFM) μηχανικούς (πράγματι υπάρχουν εξαιρετικές εφαρμογές σε αυτό τον τομέα).

Θα μπορούσα να γράφω ώρες σε αυτό το ύφος σχολιάζοντας την πρωτοβουλία αυτή, ο σκοπός μου όμως (αν και ενδεχομένως αυτό δεν φαίνεται από τα γραφόμενά μου) είναι να βοηθήσω στην προσπάθεια που γίνεται και στην αγωνία, που αυτή εκφράζει. Την αγωνία αυτή εγώ την περιγράφω ως εξής:

“ΕΧΟΥΜΕ ΠΛΗΡΩΣΕΙ ΕΚΑΤΟΜΜΥΡΙΑ ΕΥΡΩ ΓΙΑ ΕΦΑΡΜΟΓΕΣ ΠΡΩΤΟΚΟΛΛΟΥ ΚΑΙ ΕΝΑ ΠΡΩΤΟΚΟΛΛΟ ΔΕΝ ΕΧΟΥΜΕ”

Ωραία λοιπόν ας θέσουμε τις λειτουργικές προδιαγραφές και ας αφήσουμε απέξω για την ώρα θέματα υλοποίησης και τεχνολογίας! Να μερικές ερωτήσεις που πρέπει να απευθύνουμε:

1. Χρειαζόμαστε μια εφαρμογή για όλο το Δημόσιο τομέα; (Το ΝΑΙ σημαίνει ότι γίνεται εύκολη η συνένωση ή ο διαχωρισμός υπηρεσιών, το ΟΧΙ ότι η κάθε υπηρεσία διαλέγει τη δική της εφαρμογή οπότε ποιος ο λόγος δημιουργίας μίας ακόμη;)

2. Θα καταργηθούν οι θέσεις πρωτοκόλλου στις υπηρεσίες. Με άλλα λόγια θα υπάρχουν χειριστές που θα φροντίζουν για την σωστή ενημέρωση της εφαρμογής; (Με το ΝΑΙ ελαχιστοποιείται η εσωτερική αντίδραση από τους χρήστες, με το ΟΧΙ αυξάνεται η ευελιξία στην πρωτοκόλληση με ότι σημαίνει αυτό)

3. Στην εφαρμογή του πρωτοκόλλου μπορεί να προσδιοριστεί ένα κοινά αποδεκτό minimum απαιτήσεων για όλους τους φορείς του Δημοσίου; (Άποψή μου είναι πως για το ΠΡΩΤΟΚΟΛΛΟ αυτό είναι δυνατό, για το Document Management & Workflow αυτό είναι απίθανο)

4. Στα έγγραφα που θα πρωτοκολλούνται μπορεί να προσδιοριστεί ένα κοινά αποδεκτό minimum χαρακτηριστικών που θα καταγράφονται; (Λίγα μεν αλλά υπάρχουν: αποστολέας, παραλήπτης, θέμα, ημερομηνίες κ.λ.π. )

5. Σε ποιο επίπεδο της Δημόσιας Διοίκησης θα λειτουργεί η εφαρμογή και ποιο επίπεδο θα δεσμεύει ; (Σε επίπεδο τοπικής υπηρεσίας, επίπεδο περιφέρειας, επίπεδο υπουργείου, επίπεδο κράτους κ.λ.π.)

Αυτές θεωρώ πως είναι μερικές από τις βασικές ερωτήσεις που θα πρέπει να απαντηθούν σε επιχειρησιακό επίπεδο πριν αποτολμηθεί οτιδήποτε σχετικό με την ανάπτυξη του λογισμικού.

Υ.Σ. : Να σας θυμίζω μια από τις βασικές αρχές στην δημιουργία επιχειρησιακού λογισμικού, την αρχή KISS (keep it simple stupid).

Από: Ξενοφών Τιμόλογος [28/09]

σχετικά με την παραπάνω δημόσια διαβούλευση και επειδή με έχει απασχολήσει το θέμα θα ήθελα να προτείνω μερικές λειτουργικές προδιαγραφές.

1) Δυνατότητα δημιουργίας πρότυπων υποθέσεων με προκαθορισμένες ενέργειες και προκαθορισμένη ανάθεση σε τμήματα του οργανισμού (π.χ.απόσυρση εγκατειλημένου οχήματος, άδειες απουσίας προσωπικού κλπ)

2) Δυνατότητα καταχώρησης ημ/νίας ισχύος από..έως στα τμήματα του οργανισμού για τις περιπτώσεις που αλλάζει η οργανωτική δομή του οργανισμού.

Από: Μανωλάτος Τηλέμαχος [28/09]

Θα πρότεινα μια μικρή αναδιατύπωση στο σημείο 14 όπου αναφέρεστε σε λογισμικό / εργαλεία ανάπτυξης open source θέτοντας για παράδειγμα την PHP.

Πιο συγκεκριμένα θα πρέπει κατά την άποψή μου να μην αποκλείουμε την ανάπτυξη σε Java / JavaEE μιας και τα Sun/Oracle JRE/JDK αν και δεν είναι ανοικτού κώδικα χρησιμοποιούνται κατά κόρον σε open source έργα. Πιθανότατα open source εκδοχές τους όπως το OpenJDK δεν είναι production ready ή αυξάνουν την πιθανότητα παρουσίασης προβλημάτων λόγω της μικρότερης ηλικίας τους / ωριμότητας.

Επίσης ενώ είναι κατανοητό ότι οι εφαρμογές πρέπει να είναι 100% web προκύπτουν κάποια ζητήματα στα σημεία ολοκλήρωσης με scanners κλπ όπου είτε απαιτείται κάποιο thick client κομμάτι ή κάποιο signed java applet πάνω στην σελίδα – άλλος ένας λόγος για να επιτραπεί η χρήση τεχνολογίας Java.

Από: Χρήστος Στάθης [27/09]

Παραθέτω κάποια σχόλια και ερωτήσεις μου ανά σημείο:

Λειτουργικές προδιαγραφές Υποσύστημα πρωτοκόλλου

1. Για να είναι δυνατή η πλήρης και αναλυτική παραμετροποίηση του συστήματος για κάθε υπηρεσία που θα το εγκαταστήσει, θα πρέπει να καθοριστούν κάποιες έννοιες με κοινό τρόπο π.χ. τμήματα, θέσεις εργασίας, ρόλοι κλπ ώστε να σημαίνουν τα ίδια πράγματα για όλες τις υπηρεσίες - χρήστες.

2. Η συνεργασία με εκτυπωτές-σαρωτές-φαξ σε επίπεδο θέσης εργασίας, απαιτεί είτε την ανάπτυξη κάποιου desktop application (διότι σε επίπεδο browser δεν είναι εύκολη ή δεν γίνεται καθόλου), είτε τη χρήση άλλων εξωτερικών εργαλείων σε συνδυασμό με την εφαρμογή. Και στις δύο περιπτώσεις δεν μιλάμε πια για αμιγώς web-based application, οπότε χάνεται και το πλεονέκτημα της ανεξαρτησίας από το λειτουργικό σύστημα.

4. Η δυνατότητα OCR θα πρέπει να επιτευχθεί με χρήση εξωτερικών εργαλείων οπότε έχουμε τα θέματα που αναφέρω στο 2.

17. Η δυνατότητα πολυγλωσσικής υποστήριξης αφορά στο user interface ή και στις δυνατότητες OCR, indexing/searching που αναφέρονται νωρίτερα;

Υποσύστημα αναθέσεων

10. Για τη δημιουργία καταλόγων χρηστών και διευθύνσεων θα πρέπει πρώτα να καθοριστεί ένα κοινό πλαίσιο εννοιών όπως αναφέρω στο 1 για το υποσύστημα πρωτοκόλλου.

Τεχνικές προδιαγραφές

2. Η δυνατότητα λειτουργίας σε local intranet θα είναι αυτόνομη ή σε συγχρονισμό με κάποιο cloud service? Π.χ. ένας οργανισμός μπορεί να χρησιμοποιεί την cloud-hosted υπηρεσία αλλά όταν χάνει τη σύνδεσή του με το διαδύκτιο θα έχει την local εγκατάσταση έτοιμη να αναπληρώσει.

3. Για να είναι τα πάντα σε web περιβάλλον θα πρέπει να αναθεωρηθούν κάποιες απαιτήσεις (βλ. 2 και 4 στο υποσύστημα προτωκόλλου).

5. Η έναρξη της χρήσης της εφαρμογής από μια δημόσια υπηρεσία “με το πάτημα ένος κουμπιού” προϋποθέτει ότι κάποιος θα έχει κάνει ήδη την παραμετροποίηση (ορισμός ρόλων, δικαιωμάτων, θέσεων κλπ)

8. Η δυνατότητα λειτουργείας offline (σε συνδυασμό με το ερώτημα που θέτω στο 2) αφορά σε θέση εργασίας ή στο σύνολο του οργανισμού; Θέλουμε δηλαδή local storage σε επίπεδο client (browser) ή σε επίπεδο οργανισμού (βλ. 2)

Σχετικά με τον προϋπολογισμό του έργου, αν υποθέσουμε ότι η cloud υποδομή υπάρχει ήδη, άρα δεν περιλαμβάνεται στο έργο και θεωρώντας ότι αφού όλα θα βασίζονται σε ΕΛΛΑΚ, δεν έχουμε κόστη για άδειες χρήσης, στην ουσιά μιλάμε για καθαρό κόστος ανάπτυξης της εφαρμογής. Με βάση την εμπειρία μου από την ανάπτυξη ανάλογων υπηρεσίων, εκτιμώ πως αν υλοποιηθούν πλήρως όλες οι απαιτήσεις το κόστος μπορεί να κινηθεί άνετα στην περιοχή των 100000 ευρώ (χωρίς ΦΠΑ), ενδεχομένως και παραπάνω. Εξαρτάται φυσικά και από το βαθμό παραμετροποίησης που θα απαιτηθεί και από το αν θα υλοποιηθεί σαν ενιαίο σύστημα ή θα σπάσει σε μικρότερα έργα.

Από: Κώστας Φλώκος [27/09]

Ένα χαρακτηριστικό των εφαρμογών Πρωτοκόλλου είναι η δυνατότητα διατήρησης των εγγραφών για όσα χρόνια είναι νομικά υποχρεωμένος ο οργανισμός να διατηρεί τα αντίστοιχα αρχεία. Η συγκεκριμένη ανάγκη δεν εμφανίζεται στη λίστα που έχετε αναρτήσει στο διαδίκτυο. Δεν πιστεύω οτι η τεχνική προδιαγραφή για τα αντίγραφα ασφαλείας καλύπτει τη συγκεκριμένη ανάγκη.

Αυτό σημαίνει οτι ο οργανισμός που θα χρησιμοποιήσει την εφαρμογή θα είναι υποχρεωμένος να διατηρεί το ίδιο αρχείο σε χαρτί – πιθανά απλές εκτυπώσεις των εγγραφών;

Σχετικά με τη δυνατότητα αυτόματης αρχειοθέτησης ηλεκτρονικών μηνυμάτων νομίζω οτι το ιδανικό είναι η διασύνδεση να γίνεται όχι με τους διακομιστές αλληλογραφίας, αλλά με τις εφαρμογές διαχείρισης μηνυμάτων, όπως Outlook, Thunderbird, κλπ. Μόνο τότε ο χρήστης θα μπορεί με το πάτημα ενός πλήκτρου να πραγματοποιεί την αυτόματη αρχειοθέτηση ενός ηλεκτρονικού μηνύματος.

Εχοντας εργαστεί στο παρελθόν με το σύστημα αρχειοθέτησης της Ευρωπαικής Επιτροπής, θα σας πρότεινα να επικοινωνήσετε με την αντίστοιχη υπηρεσία της Επιτροπής τόσο για το νομικό πλαίσιο (http://ec.europa.eu/transparency/edoc_management/index_en.htm) όσο και την τεχνική υλοποίηση. Θα χαρώ να σας φέρω σε επαφή, εφόσον το επιθυμείτε.

Από: Εμμανουήλ Μπάτσης [26/09]

Σε απάντηση της ανοικτής σας πρόσκλησης, παραθέτω σχόλια που αφορούν την δημόσια διαβούλευση “Προδιαγραφές ανάπτυξης συστήματος ηλεκτρονικού πρωτοκόλλου και διαχείρισης υποθέσεων”.

Σχόλια επί των λειτουργικών προδιαγραφών Υποσυστήματος Πρωτοκόλλου

Απαίτηση 2: “Να συνεργάζεται με οποιοδήποτε σαρωτή για την αρχειοθέτηση των εγγράφων. Θα πρέπει να υποστηρίζονται πολλαπλοί σαρωτές σε οποιαδήποτε θέση εργασίας. Επίσης θα πρέπει να υποστηρίζεται λειτουργία fax to edoc (δηλαδή αποστολή εγγράφου σε fax για ψηφιοποίηση).”

Θα πρέπει να γίνει σαφές ότι δεν υφίσταται αντικείμενο προς υλοποίηση όσον αφορά την συνεργασία της εφαρμογής με προϊόντα υλισμικού (σαρωτές κτλ) καθώς η λειτουργικότητα αυτή ανήκει καταρχάς σε επίπεδο λειτουργικού συστήματος ή/και οδηγών (drivers) και κατά συνέχεια στο λογισμικό που τα συνοδεύει.

Οι χρήστες της εφαρμογής και των υποσυστημάτων μπορούν να χρησιμοποιούν το λογισμικό που συνοδεύει τους σαρωτές για ψηφιοποίηση εγγράφων και OCR. Τα υποσυστήματα της εφαρμογής θα πρέπει απλά να επιτρέπουν την φόρτωση (upload) των ψηφιοποιημένων εγγράφων η/και επικόλληση του κειμένου που προκύπτει από το OCR.

Σε αντίθετη περίπτωση το έργο κινδυνεύει να αποκλίνει από τον στόχο του και να κατασπαταλήσει τον προϋπολογισμό του διατελώντας καθήκοντα ορισμού των υποστηριζόμενων προϊόντων υλισμικού για τους φορείς που το χρησιμοποιούν, επιδιώκοντας (με σίγουρα φτωχά αποτελέσματα) να υλοποιήσει λειτουργικότητα που προσφέρεται ήδη δωρεάν μαζί με τους σαρωτές που κυκλοφορούν στην αγορά.

Σχόλια επί των Τεχνικών Προδιαγραφών

Απαίτηση 8: “Δυνατότητα λειτουργίας offline (σε περιπτώσεις βλάβης της σύνδεσης με το διαδίκτυο).”

Θα πρέπει να αποσαφηνιστεί ότι αφορά τις εγκαταστάσεις που χαρακτηρίζονται τοπικές (LAN/intranet).

Απαίτηση 10: “Τήρηση τοπικού αντιγράφου ασφαλείας.”

Δεν δίνεται καμία επεξήγηση στην έννοια του “τοπικού” ή το εύρος των δεδομένων που περιλαμβάνονται στο αντίγραφο, καθώς και γενικότερα το τι απαιτείται ως προστιθέμενο της απαίτησης 9.

Σχόλια επί της Άδειας χρήσης

Η επιλογή συγκεκριμένης άδειας χρήσης και ειδικότερα της EUPL εισάγει αρκετά προβλήματα στο έργο καθώς δεν διαδεδομένη, ενώ εμποδίζει την κατάθεση προτάσεων που μπορεί να εκμεταλλεύονται υπάρχον λογισμικό που διανέμεται με άλλες άδειες ΕΛ/ΛΑΚ. Προτείνεται η προδιαγραφή να αλλάξει σε άδειες “OSI Approved” έτσι ώστε να μπορούν να συμμετάσχουν εταιρίες που έχουν επενδύσει ήδη σε υλοποίηση ανοικτού λογισμικού, ρίχνοντας έτσι το κόστος και μειώνοντας τα ρίσκα του έργου χωρίς περιττούς περιορισμούς που δεν συνεισφέρουν σε αυτό.

Από: Δημήτρης Καλογεράς [25/09]

Το πληροφοριακό σύστημα θα λειτουργεί ενιαία με ενοποιημένα τα δύο υποσυστήματα. Ακολουθούν οι βασικές τεχνικές προδιαγραφές:

1. Λειτουργία σε περιβάλλον virtual computing σε απομακρυσμένο data center.

οι επιλογές είναι παρ πολλες σε αυτήν προδιαγραφή μπορει να είναι Paas (python, java) ή και ολοκληρη μηχανή (π.χ ΑΜι ) αλλα αυτό ειναι λίστη Αmazon only..

2. Δυνατότητα λειτουργίας σε local intranet. Τι σημαίνει αυτό πρακτικά ? οτι δεν υπάρχει root dns service ?

3. Περιβάλλον εργασίας στο web (μέσω browser). Όλες οι οθόνες, χειριστών, στελεχών, διαχειριστή θα είναι σε web περιβάλλον.

4. Υποστήριξη internet explorer, firefox, safari και chrome. (νομίζω οτι αναφορα με τον internet explorer και το firefox πρεπει να μπουν οριοσμένοι περιορισμοί, π.χ αυτοι που υποστηριζονται απο την microsoft με fix-updates...ή κατι σχετικό

5. Εγκατάσταση στο virtual περιβάλλον με το πάτημα ενός κουμπιού και άμεση έναρξη λειτουργίας. Το πατημα του κουμπιου είναι σχετικό με την εγκαταστη π.χ απο την εγκατασταση του “player”

6. Μεμονωμένη εγκατάσταση virtual μηχανής για κάθε υπηρεσία ή μονάδα.

7. Δυνατότητα για λειτουργία τοπικής cache μνήμης για γρήγορη αποθήκευση και ανάκτηση εγγράφων και συγχρονισμό με την κεντρική βάση στο cloud. Θα έλεγα εν προκειμένου οτι χρειάζεται δυνατότητα συγχρονισμού με την κεντρική βάση του cloud.. (SQL, dns klp) αλλα και πάλι τι σημαίνει κεντρική βάση του cloud δεν είναι προφανές. Και επειπλέον χρειάζεται να αναφερθεί τι σημαίνει συγχρονισμός ειδικότερα για το παράθυρο του χρόνου (checksum klp)

8. Δυνατότητα λειτουργίας offline (σε περιπτώσεις βλάβης της σύνδεσης με το διαδίκτυο). Εδώ θα ήταν χρήσιμο να πουμε με ποια τεχνολογία ? θα ήταν καλύτερο να περιορισουμε την χρήση π.χ με google gear η το νεοτερο Local server API. δεν ξέρω εάν υπάρχει κάποια άλλη ανοιχτη λύση που να εξυπηρετεί ολους τους browsers...ενδεικτικά η λύση της google δεν λειτουργεί με chrome se ubuntu !!

9. Αυτόματη τήρηση αντιγράφων ασφαλείας σε ωριαία, ημερήσια, εβδομαδιαία και μηνιαία βάση.

10. Τήρηση τοπικού αντιγράφου ασφαλείας. μάλλον τοπικό αντίγραφο εφεδρείας... διαφορετικά το ασφάλειας θα έπρεπε να λέει σε τι κινδύνους αναφερόμαστε...

11. Αυξημένες προδιαγραφές ασφαλείας. Χρήση SSL για τη σύνδεση των χρηστών. Κρυπτογράφηση της βάσης καθώς και των αρχείων. Αναφορές πρόσβασης. Επιτρεπτές ip διευθύνσεις. Σύνδεση με VPN.

12. Δυνατότητα παραμετροποίησης για τον χώρο πρόσβασης (π.χ. μόνο εντός υπηρεσίας, και εκτός υπηρεσίας κοκ).

13. Παραγωγή και διατήρηση πλήρους log file με καταγραφή όλων των κινήσεων και χειρισμών. θα έλεγα ασφαλούς log file με υπογραφή..

14. Ανάπτυξη με εργαλεία ανοιχτού λογισμικού (πχ php), χρήση βάσης δεδομένων ανοιχτού λογισμικού, χρήση λογισμικού εξυπηρετητή ανοιχτού λογισμικού.

15. Διαχείριση ηλεκτρονικής υπογραφής.

16. Δημιουργία ξεχωριστού site για το project είτε στο .gr είτε στο .org

17. Δημιουργία repository για τον πηγαίο κώδικα του έργου με χρήση κάποιου εργαλείου Distributed Version Control (π.χ. Git, Mercurial).

18. Καταχώρηση του έργου στο osor.eu repository.

19. Δημιουργία wiki για τεκμηρίωση του έργου.

20. Δημιουργία ticketing system για την καταγραφή προβλημάτων και bugs από χρήστες και developers.

21. Δυνατότητα εισαγωγής modules στο έργο, ώστε να αποκεντρωθεί η ανάπτυξη επιπλέον λειτουργιών στην κοινότητα ΕΛ/ΛΑΚ.