• Σχόλιο του χρήστη 'Σακης Λαδόπουλος' | 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).