Τεχνική Διαβούλευση σχετικά με Οριζόντιες Απαιτήσεις Ανάπτυξης Λογισμικού για έργα της ΓΓΠΣ

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

– Διαχείριση εκδόσεων (version control)
Όλο το λογισμικό για το οποίο η ΓΓΠΣ μπορεί δικαιωματικά να έχει πρόσβαση στον πηγαίο κώδικά του αποθηκεύεται σε σύστημα διαχείρισης εκδόσεων. Το σύστημα το παρέχει η ΓΓΠΣ και ο ακριβής τρόπος και το πρωτόκολλο πρόσβασης καθώς και αντίστοιχα δικαιώματα και ρόλοι δίνονται από την ΓΓΠΣ. Η πρόσβαση είναι πάντα εξατομικευμένη, σε εναρμόνιση με τον κανονισμό ασφαλείας της ΓΓΠΣ. Οι λογαριασμοί πρόσβασης έχουν ισχύ που απορρέει από τη διάρκεια των διαφόρων δράσεων λογισμικού και τη φάση ανάπτυξης. Η ισχύς της διάρκειας προσδιορίζεται και ελέγχεται από τον υπεύθυνο της δράσης.

– Διαχείριση θεμάτων (issue tracking)
Όλες οι δράσεις παρακολουθούνται σε σύστημα διαχείρισης θεμάτων. Το σύστημα το παρέχει η ΓΓΠΣ και τα περί πρόσβασης και ισχύος διάρκειας σε αυτό ορίζονται όπως και παραπάνω για τη διαχείριση εκδόσεων.

– Χρήση αδειών ΕΛ/ΛΑΚ
Όταν κρίνεται από την υπηρεσία σκόπιμο (π.χ. ότι προάγεται το δημόσιο και γενικότερο συμφέρον από την υιοθέτηση αδειών χρήσης ΕΛ/ΛΑΚ), το παραδιδόμενο λογισμικό θα πρέπει να συνοδεύεται από αντίστοιχη άδεια χρήσης ΕΛ/ΛΑΚ. Το ίδιο ισχύει και για σχετική τεκμηρίωση, με αντίστοιχη άδεια.

– Unit Testing
Το λογισμικό θα πρέπει να περιλαμβάνει για τις βασικές λειτουργικές του μονάδες αυτοματοποιημένα σενάρια ελέγχου ορθότητας της κάθε μιας (unit testing). Ο βαθμός πληρότητας των σεναρίων ελέγχεται ως παραδοτέο.

– Integration Testing
Το λογισμικό θα πρέπει να περιλαμβάνει αυτοματοποιημένα σενάρια που ελέγχουν την ορθότητα επικοινωνίας μεταξύ των λειτουργικών μονάδων του (integration testing). Ο βαθμός πληρότητας των σεναρίων ελέγχεται ως παραδοτέο.

– System testing
Το λογισμικό θα πρέπει να περιλαμβάνει σενάρια ελέγχου του όλου συστήματος σε μεγαλύτερη κλίμακα (system testing). Ο βαθμός πληρότητας των σεναρίων ελέγχεται ως παραδοτέο.

– Αυτοματοποίηση ανάπτυξης
Οι διάφορες διαδικασίες που αφορούν στην ανάπτυξη σε όλο το φάσμα της (π.χ. μετάφραση του πηγαίου κώδικα σε εκτελέσιμη μορφή (compilation/build), παραγωγή τεκμηρίωσης κώδικα, εγκατάσταση εφαρμογής σε περιβάλλον εκτέλεσης (deployment)) γίνονται με μηχανικό/αυτοματοποιημένο τρόπο, που ελέγχεται ως παραδοτέο.

– Επαναχρησιμοποιήσιμες λειτουργίες / Διαλειτουργικότητα
Αν μια δράση λογισμικού παρέχει λειτουργικότητα με εν δυνάμει επαναχρησιμοποιήσιμο χαρακτήρα (π.χ. single sign on), η λειτουργικότητα αυτή τεκμηριώνεται επαρκώς και αυτόνομα, ώστε να μπορεί να επαναχρησιμοποιηθεί σε άλλες δράσεις λογισμικού. Δίνουμε ιδιαίτερη έμφαση στην επαναχρησιμοποίηση λογισμικού/υπηρεσιών ως συστατικά (components) και στον εμπλουτισμό υπαρχόντων και αποθαρρύνουμε πολλαπλά υλοποιημένες λειτουργικότητες παρόμοιου/ίδιου χαρακτήρα. Ακολουθούμε αυτές τις αρχές ιδιαίτερα όσον αφορά τη διαλειτουργικότητα συστημάτων και κατ’ επέκταση φορέων.

– Ενσωμάτωση στο υπάρχον περιβάλλον
Λαμβάνουμε πάντα υπόψη τις υφιστάμενες δομές, τη γενικότερη αρχιτεκτονική/τοπολογία συστημάτων. Ως παραδοτέο ελέγχεται η τεκμηρίωση εγκατάστασης λογισμικού σε υπάρχουσα ή όχι υποδομή, και οι οποιεςσδήποτες αλληλεξαρτήσεις σε όλα τα επίπεδα (δικτυακό, συστεμικό, εφαρμογών). Τα παραδιδόμενα συστήματα (υλικό, λογισμικό κλπ) οδηγούν στην ενημέρωση των αντίστοιχων «αρχιτεκτονικών χαρτών» της υπηρεσίας, που δείχνουν ανά πάσα στιγμή την οργάνωση σε διάφορα επίπεδα.

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

– Τεκμηρίωση
Υπάρχει τεκμηρίωση για όλες τις συμφωνημένες φάσεις και όλα λειτουργικά παραδοτέα και τις προδιαγραφές/απαιτήσεις τους. Ιδιαίτερα, απαιτείται κατά περίπτωση τεκμηρίωση που αφορά είτε σε νέες διοικητικές/υπηρεσιακές διαδικασίες που εισάγει το νέο λογισμικό/υπηρεσία είτε σε εμπλουτισμό υπαρχουσών διαδικασιών. Αναφέρουμε ενδεικτικά διαδικασίες υποστήριξης call center.

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

Σας καλούμε για τις παρατηρήσεις και τα σχόλιά σας μέχρι (νέα προθεσμία) Δευτέρα 28/02/2011 ώστε να βελτιώσουμε / τροποποιήσουμε τις απαιτήσεις αυτές.

  • Η ασφάλεια θα πρέπει να ενσωματωθεί σε όλο το φάσμα των διαδικασιών ανάπτυξης λογισμικού. Πολύ περισσότερο όταν πρόκειται για έργα της ΓΓΠΣ τα οποία διαχειρίζονται ευαίσθητα δεδομένα.
    Για την υλοποίηση του στόχου αυτού μπορούν να χρησιμοποιηθούν ανοικτά πρότυπα και μεθοδολογίες και ειδικότερα:
    Το OWASP Application Security Verification Standard (ASVS – http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) το οποίο χρησιμοποιείται ευρύτατα κατά την προμήθεια αλλά και εσωτερική ανάπτυξη λογισμικού για τον έλεγχο και την επαλήθευση θεμάτων ασφάλειας σε όλο το φάσμα μιας εφαρμογής. Το ASVS ορίζει συνολικά 4 κλιμακούμενα επίπεδα επαλήθευσης ασφάλειας και περιγράφει αναλυτικές διαδικασίες και απαιτήσεις για την επίτευξή τους.
    Το OWASP έχει δημοσιεύσει επίσης αναλυτικές μεθοδολογίες για τον έλεγχο (OWASP Testing Guide – http://www.owasp.org/index.php/OWASP_Testing_Project) και την επαλήθευση του κώδικα (OWASP Code Review Guide – http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project) εφαρμογών.
    Αντίστοιχα, το OWASP OpenSAMM (Security Assurance and Maturity Model) μπορεί να χρησιμοποιθεί για τη μέτριση της ωριμότητας των πρακτικών ανάπτυξης λογισμικού ως προς την ωριμότητά του. Μπορεί να χρησιμοποιηθεί είτε εσωτερικά από τη ΓΓΠΣ είτε από τους προμηθευτές της.

    Συνεπώς, προτείνεται η εισαγωγή μιας νέας πρότασης που αφορά τον έλεγχο και την επαλήθευση της ασφάλειας των εφαρμογών με χρήση ανοικτών προτύπων και μεθοδολογιών και η ένταξή τους σε κάποιο από τα επίπεδα που περιγράφει το ASVS. Το επίπεδο μπορεί να ορίζεται στις προδιαγραφές του έργου ανάλογα με τις επιμέρους ανάγκες και απαιτήσεις του έργου.
    Συνολικά θα μπορούσαν να τροποποιηθούν κατάλληλα και να υιοθετηθούν οι προδιαγραφές που περιγράφονται στο OWASP Secure Software Contract Annex (http://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex).

  • 27 Φεβρουαρίου 2011, 18:31 | Πέτρος Γαβαλάκης

    Έχω να παρατηρήσω ότι είναι πολύ ενδιαφέρουσα η πρωτοβουλία της ΓΓΠΣ αλλά αρκετά τα εύστοχα σχόλια/προτάσεις που έχουν προκύψει και που μπορούν να δώσουν τροφή για περαιτέρω προβληματισμό.

    Χωρίς να έχω να προσθέσω κάτι επί των τεχνικών θεμάτων, θα με ενδιέφεραν
    α) στοιχεία για το πώς τα παραπάνω μπορεί να επηρεάσουν το κόστος/προϋπολογισμό ενός έργου
    β) πώς θα μπορούσαν να γενικευτούν οι προδιαγραφές ώστε -δεδομένης των πρωτοποριακών πρωτοβουλιών της ΓΓΠΣ για το δημόσιο τομέα- να μπορούν να υιοθετηθούν και από άλλους φορείς με μπόλικη ετερογένεια στις υποδομές και τις διαδικασίες τους

  • 17 Φεβρουαρίου 2011, 14:02 | Σακης Λαδόπουλος

    Οι προτάσεις/ ζητήματα που τίθενται προς διαβούλευση αποτελούν επιμέρους υπο-διεργασίες ή/και εργαλεία ή/και ενέργειες τα οποία είναι μέρος του συνολικού project lifecycle management και software lifecycle management. Ως προς τον τρόπο διοίκησης έργου αλλά και ως προς την μεθοδολογία ανάπτυξης λογισμικού υπάρχουν πολλά μοντέλα τα οποία υποστηρίζουν συνολικές λύσεις για τα ανωτέρω ζητήματα. Άρα μία συνολική απάντηση για αυτά, εξαρτάται από το συνολικότερο μοντέλο τυποποίησης που προκειται να χρησιμοποιηθεί καθώς επίσης και από τις τεχνολογίες που χρησιμοποιούνται και απαιτούνται από το εργό και το παραγόμενο προιόν αυτού.
    Η RUP (Rational Unified Process) ως μία «μεση λύση» μεταξή waterfall και agile μεθοδολογιών υποστηρίζει τμηματική παραδοση αλλά και συνολικό έλεγχο (system testing) του τελικού παραδοτέου. Είναι ευρέως διαδεδομένη με επιτυχημενη εφαρμογή σε μεσαία – μεγαλα έργα όπως αυτά δημοσίων οργανισμών και αποτελεί τυπικό προαπαιτούμενο σε πολλές αντίστοιχες ευρωπαικές υπηρεσίες. Έχοντας ως βάση την RUP, πολλές επιμερους λύσεις θα μπορούσαν να δωθούν στα αντιστοιχα θέματα:

    Διαχείριση θεματων (issue tracking)
    Η χρήση ενός εργαλείου/ πλατφόρμας που διατήρει σε βάση δεδομένων όλα τα θέματα (issues) είναι ίσως η μόνη λύση για την πλήρη καταγραφή (recording), επεξεργασία (processing), επίβλεψη (monitoring & controling) και εξαγωγή αποτελεσμάτων (reporting) των θεμάτων (issues). Ίσως η πιο διαδεδομένη εφαρμογή για τα θέματα κατα την αναπτυξη μιας εφαρμογής είναι αυτη τη στιγμή το JIRA ενώ για τα θεματα (issues) κατα την φάση της υποστήριξης του πελάτη το REMEDY.

    Unit/ Integration/ System Testing.
    Η συνολική λειτουργία του testing και η φάσεις στις οποίες πρόκειται να διαχωριστεί αποτελεί αυτόνομη υπολειτουργία κατα την διάρκεια ενός έργου, ξεκινώντας από τα αρχικά στάδια της επεξεργασίας των προδιαγραφών (requirements) από τα οποια θα παραχθούν τα αντίστοιχα σεναρια ελέγχου (test cases, test scenarios) μέχρι φυσικά των τελικό έλεγχο του τελικού παραδοτεου στον πελάτη και ενδεχομένως συνεχίζοντας με υποστήριξη κατα την διαρκεια των ελεγχων στο περιβαλλον του πελάτη (UATs).
    Η διαδικασία του testing πρέπει να είναι τεκμηριωμένη ακολουθώντας καταγεγραμένα σενάρια που έχουν υλοποιηθεί από τους Μηχανικούς Ελέγχου (test engineers) και έχουν επιθεωρηθεί από τους μηχανικούς σχεδίασης (Business Analysts – Specifications). Τα εγγραφα αυτά αποτελούν παραδοτεό προς επιθεώρηση στον πελατη (SfR – Submited for Review) με προκαθορισμένο χρονικό περιθώριο για λήψη σχολίων και προσάρτηση αυτών (SfA – Submited for Acceptance).

    Παραδοτέο επίσης είναι και το αποτελεσμα των tests σέ ολους τους κύκλους εκτέλεσής τους (Test Runs). Για την εξαγωγή του παραδοτέου αυτού αλλά και για την γενικότερη οργανωση και παρακολούθηση της εκτελεσης των tests είναι επιβεβλημένη η χρήση ενός εργαλείου διαχείρισης των tests (test management tool). Το SPIRA TEST είναι μία επιλογή για τον σκοπό αυτό, προσφέροντας μάλιστα χρηστική διεπαφή με το JIRA αλλά και άλλα εργαλεία.

    Οι διακριτές φάσεις του test (module/ component/ unit testing, integration testing, system testing) αποτελούν κυρίως θέμα ορισμού και καθορισμού του περιεχομένου και συνήθως ακολουθούν -κατα το μοντέλο – «V»- ένα προς ένα αναλογία με τις διακριτές φάσεις/ επιπεδα ανάλυσης. Γενική αρχή όμως πρέπει να αποτελεί ο διαχωρισμός του testing που πραγματοποιείται από τους μηχανικούς υλοποιησης (developers) και από τρίτη όμαδα (3rd party) ειδικευμένων για το σκοπό αυτό μηχανικών (testers). Επίσης σε τελικό επίπεδο, έλεγχος πραγματοποιείται μετά την παραδοση -και πριν την ολοκλήρωση του έργου- στις εγκαταστάσεις και στο περιβάλλον του πελάτη (on-site) ωστε να επιτευχθεί η τελική αποδοχή του παραδοτέου (Site Acceptance Testing – User Acceptance Testing). Και πάλι, εξωτερική όμαδα εξειδικευμένων μηχανικών μπορούν να αναλάβουν αυτη την φάση ή να λειτουργήσουν συμβουλευτικά (consulting).

  • Τεχνική Διαβούλευση σχετικά με Οριζόντιες Απαιτήσεις Ανάπτυξης Λογισμικού για έργα της ΓΓΠΣ.

    Σύστημα Αυτοματοποιημένης Υποβολής & Διαχείρισης Προτάσεων Υλοποίησης Εργων.

    1. Εισαγωγή

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

    Η λύση μπορεί να υλοποιηθεί με χρήση BPM suite, για να παρέχονται όλα τα πλεονεκτήματα που απορρέουν από την χρήση μιας τέτοιας σουίτας. Με τον κατάλληλο σχεδιασμό της διαδικασίας και των ροών εργασιών θα μπορεί να γίνει πλήρης διαχείριση ενός έργου πληροφορικής (και όχι μόνον) από την δημιουργία της σχετικής ανάγκης, μέχρι την οριστική παραλαβή.

    2. Περιγραφή του Προτεινόμενου Συστήματος

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

    Γενικά, η διαδικασία, περιγράφεται ως εξής:

    o Καταχωρείται «νέο εργο» προς υλοποίηση (Σχετική φόρμα με στοιχειώδης προδιαγραφές, πιθανόν από ή κατά αίτηση από το αρμόδιο τμήμα ή διεύθυνση)
    o Ορίζονται οι υποψήφιοι προμηθευτές (συσχέτιση με το νέο έργο προς υλοποίηση) στο σύστημα (Από τη δ/νση Πληροφορικής, όσον αφορά στα έργα πληροφορικής)
    o Όταν οριστικοποιηθούν οι υποψήφιοι προμηθευτές, το σύστημα στέλνει email σε κάθε προμηθευτή όπου ανακοινώνεται επίσημα η πρόσκληση. Το e-mail, περιλαμβάνει και τα στοιχεία του λογαριασμού (κωδικό χρήστη και συνθηματικό) που δίνει δυνατότηα υποβολής προσφοράς

    2.1 Δικαίωμα Χρήσης του Συστήματος

    Κάθε προμηθευτής που καλείται για να υποβάλει πρόταση υλοποίησης έργου θα λαμβάνει, από τον υπεύθυνο διαχειριστή του συστήματος/υπάλληλο της ΓΓΠΣ κωδικό χρήστη και συνθηματικό με τα οποία θα γίνεται χρήστης στο Σύστημα Υλοποίησης Εργων της Γραμματείας.

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

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

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

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

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

    2.2 Συμπλήρωση Ηλεκτρονικού Εντύπου – 1ος Κόμβος Εργασίας

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

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

    Η συμπλήρωσή της από τον προμηθευτή θα αποτελεί και τις εργασίες που γίνονται στον πρώτο κόμβο εργασίας. Τα η-έγγραφα δεν θα μπορούν να «αποσταλούν» στον επόμενο κόμβο αν δεν έχουν συμπληρωθεί με όλα τα στοιχεία και πληροφορίες που έχουν προβλεφθεί και συμφωνηθεί κατά την ανάλυση και τεθούν στο σύστημα. Η αποστολή της θα γίνεται με την εντολή π.χ. Υποβολή/Submit.

    2.3 Λήψη Προσφοράς – 2ος Κόμβος Εργασίας

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

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

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

    2.4 Εκδοση Κωδικού Αιτήματος – 3ος Κόμβος Εργασίας

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

    2.5 Διαδικασία Διαχείρισης της Ανάθεσης

    Η ανάθεση στον προμηθευτή πραγματοποιείται και σύμφωνα με τυχόν υφιστάμενο κανονισμό προμηθειών, εφόσον έχουν ολοκληρωθεί τα παρακάτω βήματα:

    ► Βήμα 1

    Καταχώρηση αιτήματος χρήστη ή παραπομπή από το Τμήμα Υποστήριξης, σε HELP DESK.

    ► Βήμα 2

    • Ανάλυση Απαιτήσεων Χρήστη
    • Χρονοδιάγραμμα Υλοποίησης Έργου
    • Προσδιορισμός απαιτούμενων ανθρωποημερών
    • Προϋπολογισμός έργου

    ► Βήμα 3

    • Διαδικασία έγκρισης Δαπάνης (από Διεύθυνση Πληροφορικής)

    • Ανάλυσης επιχειρησιακού οφέλους (Κέρδος – Κόστους) της απαίτησης

    ► Βήμα 4

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

    ► Βήμα 5

    Ανάθεση έργου σε προμηθευτή σύμφωνα με τον ισχύοντα κανονισμό προμηθειών.

    2.6 Διοίκηση του Εργου – 4ος και 5ος Κόμβος Εργασίας

    Για την διοίκηση του έργου απαιτούνται τουλάχιστον υπεύθυνοι διαχείρισης έργου ή και project managers (στην περίπτωση σύνθετων έργων) τόσο από την πλευρά του αναδόχου υλοποίησης όσο και από την πλευρά του αναθέτη. Κατά συνέπεια, ο 4ος και 5ος κόμβος εργασίας (ροής εργασιών) αφορά σε κόμβο υπευθύνου διαχείρισης εκ μέρους της ΓΓΠΣ και σε κόμβο υπευθύνου διαχείρισης από πλευράς του αναδόχου.

    Η ανάδειξη υπευθύνων διαχείρισης (project managers) των έργων μπορεί να γίνεται είτε απ’ ευθείας εκτός συστήματος ή με την βοήθεια Διαδικασίας Ανάδειξης Υπευθύνου Εκτέλεσης Εργου που θα υποστηρίζεται από το σύστημα.

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

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

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

    Η διαδικασία Υλοποίησης και Παραλαβής σε φάσεις περιλαμβάνει παραδοτέα που παρδίδονται και γίνονται αποδεκτα κατά τις φάσεις αυτές. Τα παραδοτέα αυτά προβλέπονται από τον αντίστοιχο κανονισμό της ΓΓΠΣ και από τυχόν ιδιαιτερότητες των έργων και μεταξύ άλλων περιλαμβάνουν:

    Βήμα 1

    • Ανάπτυξη και υλοποίηση των εγκεκριμένων κατά τη μελέτη σκοπιμότητας

    • Αποδοχή τεχνικής λύσης από:

    • Διεύθυνση Πληροφορικής

    • Αρμόδιο χρήστη

    ► Βήμα 2

    • Εκτέλεση δοκιμαστικών ελέγχων από αρμόδιο τεχνικό (CAT)

    • Εκτέλεση δοκιμαστικών ελέγχων από αρμόδιο χρήστη (UAT)

    ► Βήμα 3

    Παραλαβή έργου

    Για την παραλαβή του έργου απαιτούνται πέραν της ολοκλήρωσης του βήματος 2 και τα ακόλουθα παραδοτέα από τον προμηθευτή:

    1. Design Document
    2. Testing scenario
    3. User documentation

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

    ► Βήμα 9

    • Έναρξη παραγωγικής λειτουργίας

    Το σύστημα θα υποστηρίζει ημερολογιακή αντιστοίχιση των φάσεων, αρχής γενομένης του kick off meeting που σηματοδοτεί την έναρξη υλοποίησης του έργου.

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

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

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

    3. Σύνδεση Συστήματος Υλοποίησης Εργων με Σύστημα Διαχείρισης Πληρωμών Προμηθευτών

    Το Σύστημα Υλοποίησης Εργων μπορεί να συνδεθεί με υπάρχον σύστημα Διαχείρισης Πληρωμών Προμηθευτών, ή, με την βοήθεια της ΒΡΜ σουίτας, να υλοποιηθεί νέο.

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

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

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

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

  • 17 Φεβρουαρίου 2011, 10:55 | Alexandros Apostolidis

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

  • 17 Φεβρουαρίου 2011, 09:52 | Harris Georgiou

    Δεν καταλαβαίνω ποια είναι ακριβώς η πρόταση της ΓΓΠΣ και πως ακριβώς τα παραπάνω υλοποιούνται στην πράξη.

    Όσα αναφέρονται παραπάνω αποτελούν τυπικές γενικές κατευθύνσεις εδώ και πάρα πολλά χρόνια στο software engineering, ενώ τα περισσότερα έχουν ήδη τυποποιηθεί στα πλαίσια διεθνών προτύπων ποιότητας (ISO, IDEAL, SPICE, κτλ)

    Επίσης, λείπει εντελώς το αντίστοιχο κομμάτι ελέγχου και διασφάλισης ποιότητας σε επίπεδο διαχείρισης του κάθε έργου, δηλαδή στον τομέα του software project management (π.χ. PRINCE2 για Agile κτλ).

    Καλό θα είναι οι εκάστοτε διαβουλεύσεις της ΓΓΠΣ σε τόσο σημαντικά θέματα να είναι πολύ πιο συγκεκριμένες και εμπεριστατωμένες, ώστε να μην είναι απλώς συζήτηση για γνωστά θέματα.

  • 17 Φεβρουαρίου 2011, 07:14 | gousiosg

    Κάποια γενικά σχόλια:

    -Διαχείριση εκδόσεων: Για να αποφευχθεί το φαινόμενο του 1 συγκεντρωτικού commit την εβδομάδα, μπορεί να ακολουθηθεί κάποια από τις πολιτικές commit που ισχύουν σε έργα ανοιχτού λογισμικού, πχ

    http://techbase.kde.org/Policies/SVN_Commit_Policy

    -Παρακολούθηση προόδου: Θα ήταν χρήσιμο να προβλεφθεί η εγκατάσταση κάποιου συστήματος συγκεντρωτικής παρακολούθησης προόδου (πχ redmine, trac ή κάποιο ALM).

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

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

  • 16 Φεβρουαρίου 2011, 20:40 | Γιάννης Κανελλόπουλος

    Είναι θετικό το γεγονός ότι η ΓΓΠΣ έχει τη θέληση να τυποποιήσει τις διαδικασίες ανάπτυξης του λογισμικού της. Οι απαιτήσεις οι οποίες τίθενται πρός συζήτηση
    είναι γενικά πρός τη σωστή κατεύθυνση. Παρ’όλα αυτά όμως χρειάζεται να προσεχθούν τα παρακάτω:
    • Δεν είναι σαφές πότε θα γίνεται ο έλεγχος των παραδοτέων καθώς και με ποια περιοδικότητα. Όσο πιο νωρίς ξεκινάνε οι έλεγχοι της ανάπτυξης ενός συστήματος λογισμικού, τόσο περισσότερο ενδεχόμενα προβλήματα μπορούν να αντιμετωπιστούν.
    • Δεν είναι επίσης σαφές ποιός θα ελέχει αν οι απαιτήσεις της ΓΓΠΣ ακολουθούνται. Η ίδια η ΓΓΠΣ, ο ανάδοχος (ή στην περίπτωση της εσωτερικής ανάπτυξης η ίδια η ομάδα), ένας ανεξάρτητος φορέας;
    • Σε κάποιες από τις απαιτήσεις ο έλεγχος είναι γραφειοκρατικής φύσης και χρονοβόρος, ενώ μπορεί να αυτοματοποιηθεί. Τέτοια παραδείγματα είναι το unit και το integration testing.
    • Σε κάποιες από τις απαιτήσεις δεν καθορίζεται πώς θα ελέγχονται ενώ κάποιες είναι ασαφείς.
    • Ο έλεγχος τέλος θα αφορά όλα τα συστήματα ανεξαρτήτως μεγέθους και κρισιμότητας;

    Οι απαιτήσεις επίσης που παρουσίαζονται δεν καλύπτουν τα παρακάτω :
    • Την ποιότητα του κώδικα που παραδίδεται στη ΓΓΠΣ. Ένα σύστημα κακής ποιότητας , και πιο δαπανηρό είναι να συντηρηθεί στο μέλλον και πιο δύσκολο να ανταποκριθεί στις μεταβαλλόμενες ανάγκες ενός οργανισμού όπως η ΓΓΠΣ. Υπάρχουν πρότυπα όπως το ISO/IEC-9126 και το ISO/IEC-25010 βάση των οποίων ο κώδικας ενός συστήματος λογισμικού μπορεί αυτοματοποιημένα να ελεγχθεί και ενδεχόμενα να πιστοποιηθεί με ποσοτικοποιημένες μεθόδους.
    • Τη μεθοδολογία που θα χρησιμοποιηθεί τόσο για την ανάπτυξη του λογισμικού όσο και για τη συνολική διαχείριση του έργου. Υπάρχουν μεθοδολογίες όπως η SCRUM, η Prince2 και η PMI (οι 2 τελευταίες περισσότερο για διαχείριση έργων) οι οποίες μπορούν να ακολουθηθούν καθώς και να δοθούν πιστοποιήσεις σχετικές με αυτές.

    Πιο συγκεκριμένα τώρα και όσον αφορά τις επιμέρους απαιτήσεις:
    • Unit-Testing: Αυτή η λειτουργία μπορεί να αυτοματοποιηθεί αντί να ελέγχεται η πληρότητα των παραδιδόμενων σεναρίων. Πρός τη ΓΓΠΣ μπορεί να παραδίδεται μία αναφορά με τα ποσοστά κάλυψης των βασικών λειτουργικών μονάδων του λογισμικού.
    • Integration Testing: Η αυτοματοποίηση ισχύει και εδώ (π.χ. χρησιμοποιώντας το Hudson).
    • System testing: Παρόμοια και εδώ (π.χ. χρησιμοποιώντας το Selenium).
    • Αυτοματοποίηση ανάπτυξης: Με την αυτοματοποίηση ανάπτυξης εννοούμε και την αυτόματη παραγωγή κώδικα (code generation); Συνήθως τέτοιου είδους κώδικας δεν είναι καλής ποιότητας. Κάτι τέτοιο εγκυμονεί κινδύνους όσον αφορά τη συντηρησιμότητα (maintainability) ενός συστήματος λογισμικού καθώς κάποιος μπορεί να παράξει αυτόματα κώδικα μία φορά και στη συνέχεια να τον συντηρεί με το χέρι.
    • Επαναχρησιμοποιήσιμες λειτουργίες / Διαλειτουργικότητα: Δεν καθορίζεται πώς θα ελεγχθεί η συγκεκριμένη απαίτηση.
    • Διαδικασίες παράδοσης: Εδώ δεν θα έπρεπε να προβλέπεται και η εμπλοκή των τελικών χρηστών όσο πιο νωρίς στη διαδικασία;
    • Χρήση υποστηριζόμενων τεχνολογιών: Δεν είναι σαφές ποιές είναι οι στρατηγικές απαιτήσεις της ΓΓΠΣ. Υπάρχουν επίσης και προτεινόμενες τεχνολογίες από τη μεριά της ΓΓΠΣ;

  • 16 Φεβρουαρίου 2011, 20:33 | Θεοφάνης Γιώτης

    Προτείνω να υλοποιηθεί συγκεκριμένος κύκλος ανάπτυξης του S/W (Project Life Cycle). Επίσης, στα πλαίσια του Project Life Cycle, πρέπει να καθορισθούν τα milestones και τα παραδοτέα (deliverables) στο τέλος της κάθε φάσης.

    Επομένως προτείνω τυποποίηση των φάσεων του κάθε SW Project με crystal clear παραδοτέα και συγκεκριμένα quality controls.

    Θεοφάνης Γιώτης
    Πρόεδρος Δ.Σ. Ελληνικού Ινστιτούτου Διοίκησης Έργων (PMI-GREECE
    http://www.pmi-greece.org

  • 16 Φεβρουαρίου 2011, 17:54 | Δημήτρης Γλέζος

    Καλό θα ήταν να υπάρξει λεπτομερής πρόβλεψη για υποστήριξη και διάθεση πολλαπλών γλωσσών. Αυτό αφορά στην ίδια την ανάπτυξη του έργου (code internationalization) όσο και στη διαδικασία μεταφράσεων (integration με μεταφραστικά εργαλεία).

    [Σημείωση για πλήρη διαφάνεια (full disclosure): Εργάζομαι στην Indifex, η οποία αναπτύσσει και διαθέτει εργαλεία ελεύθερου λογισμικού τα οποία διαχειρίζονται software and content localization όπως το Transifex.net.]

  • Πρέπει να προστεθεί αρχιτεκτονική απαίτηση για την χρήση διεθνών προτύπων, ειδικά όσον αφορά στην διαλειτουργικότητα. Η απαίτηση δεν πρέπει να περιορίζεται σε τεχνολογίες (π.χ. γενικά XML) αλλά να επεκτείνεται σε συγκεκριμένα πρότυπα διαλειτουργικότητας που έχουν θεσμοθετηθεί ανά πεδίο ηλεκτρονικής διακυβέρνησης (πχ. υγεία HL7, στατιστικά δεδομένα και μεταδεδομένα SDMX/ML, οικονομικές-λογιστικές καταστάσεις XBRL, κοκ)

    Έτσι θα αποφευχθεί ο προφανής και σοβαρός κίνδυνος ad hoc υλοποιήσεων.

  • 14 Φεβρουαρίου 2011, 15:15 | babisr

    – Διαχείριση εκδόσεων
    Το σύστημα διαχείρισης εκδόσεων πρέπει να είναι αποκεντρικοοποιημένο, όπως συμβαίνει πλέον στα μεγάλα και πολύπλοκα projects (λχ Linux Kernel, OpenJDK κοκ), όπου υπάρχει συνεισφορά από πολλά μέρη. Το Git ή το Mercurial θα ήταν ιδανικά. Το μοντέλο κεντρικοποιημένης διαχείρισης εκδόσεων, που περιγράφεται είναι ξεπερασμένο.

    – Αυτοματοποίηση εκδόσεων
    Η διαχείριση εκδόσεων, πέρα από το πηγαίο κώδικα θα πρέπει να αφορά και το εκτελέσιμο. Για τη διαχείριση αυτή υπάρχουν repositories εκτελέσιμου κώδικα, όπου θα δημοσιοποιούνται οι εκδόσεις των διάφορων εφαρμογών (όχι ως πηγαίος κώδικας). Τέτοιο εργαλείο για παράδειγμα είναι το Artifactory

    – Testing
    To testing δε μπορεί να είναι παραδοτέο μιας και αφορά, τουλάχιστον το integration και system testing, μια διαρκή δράση. Επίσης, δεν είναι θεμιτό να ορίζεται και να εκτελείται από εκείνον που παράγει το λογισμικό αλλά από εκείνον που το παραγγέλνει.