Αρχική Διαβουλεύσεις Προδιαγραφών - ΓΓΠΣΤεχνική Διαβούλευση σχετικά με Οριζόντιες Απαιτήσεις Ανάπτυξης Λογισμικού για έργα της ΓΓΠΣΣχόλιο του χρήστη Γιάννης Κανελλόπουλος | 16 Φεβρουαρίου 2011, 20:40
  • Σχόλιο του χρήστη 'Γιάννης Κανελλόπουλος' | 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) ενός συστήματος λογισμικού καθώς κάποιος μπορεί να παράξει αυτόματα κώδικα μία φορά και στη συνέχεια να τον συντηρεί με το χέρι. • Επαναχρησιμοποιήσιμες λειτουργίες / Διαλειτουργικότητα: Δεν καθορίζεται πώς θα ελεγχθεί η συγκεκριμένη απαίτηση. • Διαδικασίες παράδοσης: Εδώ δεν θα έπρεπε να προβλέπεται και η εμπλοκή των τελικών χρηστών όσο πιο νωρίς στη διαδικασία; • Χρήση υποστηριζόμενων τεχνολογιών: Δεν είναι σαφές ποιές είναι οι στρατηγικές απαιτήσεις της ΓΓΠΣ. Υπάρχουν επίσης και προτεινόμενες τεχνολογίες από τη μεριά της ΓΓΠΣ;