Μεθοδολογίες και Εργαλεία Ανάλυσης και Σχεδιασμού Π.Σ.

Παρουσίαση με θέμα: "Μεθοδολογίες και Εργαλεία Ανάλυσης και Σχεδιασμού Π.Σ."— Μεταγράφημα παρουσίασης:

1 Μεθοδολογίες και Εργαλεία Ανάλυσης και Σχεδιασμού Π.Σ.
Σπύρος Κοκολάκης ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ ΤΜΗΜΑ ΜΗΧΑΝΙΚΩΝ ΠΛΗΡΟΦΟΡΙΑΚΩΝ ΚΑΙ ΕΠΙΚΟΙΝΩΝΙΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ Διάλεξη 10 Ε’ Εξάμηνο

2 Multiview methodology
Μεθοδολογία πολλαπλής θεώρησης. Συνδυάζει ETHICS, SSM, κ.ά. Τέσσερα στάδια: Οργανωσιακή ανάλυση (εξετάζει το Σύστημα Ανθρώπινης Δραστηριότητας) Κοινωνικο-τεχνική ανάλυση και σχεδίαση (εξετάζει το σύστημα εργασίας) Τεχνικό σχεδιασμό και κατασκευή Πληροφοριακή ανάλυση και μοντελοποίηση (ολοκληρώνει τα προηγούμενα στάδια).

3 Σύγχρονες μεθοδολογίες ανάπτυξης εφαρμογών
Σύγχρονες τάσεις: Ευέλικτες μέθοδοι (agile) Rapid Application Development Dynamic System Development Method eXtreme Programming Feature Driven Development Οι τάσεις αλλάζουν συχνά

4 Νέες μέθοδοι, γιατί; Το περιβάλλον αλλάζει, το ίδιο και οι επιχειρήσεις. Η ταχύτητα είναι πολύ σημαντική. Η ευελιξία ακόμη περισσότερο. Οι παραδοσιακές προσεγγίσεις είναι αργοκίνητες και «γραφειοκρατικές».

5 Utah, 2001. Βασικές διαπιστώσεις
Agile Methods Utah, Βασικές διαπιστώσεις Να εστιάσουμε σε μεθοδολογίες που είναι προσαρμόσιμες, ευέλικτες και όχι άκαμπτες και από πριν καθορισμένες Να εστιάσουμε στους ίδιους τους ανθρώπους και όχι σε παραδοσιακούς ρόλους Να εστιάσουμε σε «αυτοπροσαρμοζόμενες διαδικασίες»

6 Agile Methods Αποδεχόμαστε ότι οι απαιτήσεις αλλάζουν και δεν προσπαθούμε να τις «παγώσουμε» Εκμεταλλευόμαστε τα εργαλεία (CASE) που έχουμε. Ρόλοι: Αναλυτής, προγραμματιστής, ειδικός στον έλεγχο λογισμικού, διευθυντής έργου. Νέα προσέγγιση: ομάδες όπου οι ρόλοι δεν είναι προδιαγεγραμμένοι αλλά αναπτύσσονται αναλόγως της ομάδας και του έργου Η προσαρμογή των διαδικασιών ανάπτυξης δεν θα πρέπει να γίνει εξωτερικά, αλλά να γίνεται στη διάρκεια της ανάπτυξης

7 The Manifest for Agile Software Development
Εμείς οι δεκαεπτά αναρχικοί συμφωνούμε στα εξής: Ανακαλύπτουμε καλύτερους τρόπους ανάπτυξης λογισμικού, κάνοντάς το και βοηθώντας τους άλλους να το κάνουν. Μέσω αυτής της προσπάθειας έχουμε έλθει να αποτιμήσουμε: Άτομα και αλληλεπιδράσεις, πάνω από τις διαδικασίες και τα εργαλεία Λογισμικό που λειτουργεί, πάνω από τη λεπτομερειακή τεκμηρίωση Συνεργασία με τους πελάτες, πάνω από τη διαπραγμάτευση και το συμβόλαιο Απόκριση στην αλλαγή, πάνω από την υιοθέτηση του σχεδίου

8 Βασικές αρχές Υψηλότερη προτεραιότητα στην κατανόηση του πελάτη, με σύντομη και συνεχή παράδοση λογισμικού Οι μεταβαλλόμενες απαιτήσεις είναι ευπρόσδεκτες. Παραδίδουμε λογισμικό που λειτουργεί, σε τακτά χρονικά διαστήματα, μερικών εβδομάδων ή μερικών μηνών. Οι άνθρωποι της επιχείρησης και οι υπεύθυνοι για την ανάπτυξη δουλεύουν μαζί καθ’ όλη τη διάρκεια. Τα έργα αναπτύσσονται με άτομα που έχουν κίνητρο. Τους δίνουμε το περιβάλλον, την εμπιστοσύνη και την υποστήριξη που χρειάζονται. Η αποδοτικότερη και αποτελεσματικότερη μέθοδος μεταβίβασης της πληροφορίας είναι η κατά πρόσωπο συνομιλία. Το λογισμικό που λειτουργεί είναι το πρωταρχικό μέτρο αξιολόγησης της προόδου του έργου.

9 Βασικές αρχές Οι ευέλικτες διαδικασίες προωθούν την αποδεκτή ανάπτυξη λογισμικού. Οι ιδιοκτήτες, οι υπεύθυνοι της ανάπτυξης και οι χρήστες πρέπει να είναι σε θέση να διατηρούν ένα σταθερό ρυθμό προόδου, επ’ άπειρον. Η συνεχής προσοχή στην τεχνική αρτιότητα και στον καλό σχεδιασμό ενισχύουν την ευελιξία. Η απλότητα είναι σημαντική Οι καλύτερες αρχιτεκτονικές απαιτήσεις και σχεδιάσεις προκύπτουν από τις αυτο-οργανωμένες ομάδες ανάπτυξης Σε τακτά χρονικά διαστήματα, η ομάδα εξετάζει πώς μπορεί να γίνει αποτελεσματικότερη, συντονίζει και ρυθμίζει τη συμπεριφορά της ανάλογα.

10 Τέσσερις παράμετροι Ποιότητα του προϊόντος Χρόνος υλοποίησης
Κόστος (πόροι που απαιτούνται) Λειτουργικότητα Συμπιέζοντας το χρόνο, θυσιάζεις τις άλλες τρεις παραμέτρους. Αυτό μπορεί να είναι αποδεκτό, εάν είναι υπολογισμένο και μετρήσιμο.

11 Σύγκριση ευέλικτων μεθόδων και παραδοσιακών
Ευέλικτη Ταιριάζει καλά για μικρές εφαρμογές και μικρές ομάδες ανάπτυξης Παραδοσιακή Για μεγάλες εφαρμογές και ομάδες Ακατάλληλη για προϊόντα κρίσιμης εφαρμογής Κατάλληλη για κρίσιμες εφαρμογές. Μη απαραίτητη «δυσκαμψία» για μη-κρίσιμες εφαρμογές

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

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

14 Ο δυϊσμός των μεθοδολογιών
Τέσσερις παράμετροι: Διοικητικά και οργανωτικά ζητήματα. Η μετατώπιση της εξουσίας προς τις ομάδες ανάπτυξης δεν γίνεται εύκολα Ανθρώπινα θέματα. Συνεργατικότητα, ισότιμη συμμετοχή και αμοιβαία εμπιστοσύνη. Σε ορισμένους ανθρώπους ταιριάζουν, σε άλλους όχι. Υψηλής ποιότητας ανθρώπινο δυναμικό Super-users, δεν βρίσκονται εύκολα

15 Ο δυϊσμός των μεθοδολογιών
Τέσσερις παράμετροι: Διαδικαστικά ζητήματα. Εστίαση σε διαδικασίες => Εστίαση σε ανθρώπους. Μεγάλη αλλαγή που θέλει χρόνο για να γίνει. Αβεβαιότητα, καθώς δεν έχουμε αυστηρές μετρικές ποιότητα και προόδου εργασιών Τεχνολογικά θέματα. Απαιτούνται εργαλεία

16 Rapid Application Development (RAD)
Χρήση εργαλείων για γρήγορη ανάπτυξη Κατασκευή προτύπου Αντικειμενοστραφείς προσεγγίσεις με επαναχρησιμοποίηση κώδικα Τέσσερις φάσεις: Προγραμματισμός απαιτήσεων Σχεδίαση από τους χρήστες Κατασκευή Μετάπτωση

17 Προγραμματισμός απαιτήσεων
Joint Requirements Planning Βασίζεται σε συναντήσεις εργασίας (workshops) Συμμετέχουν ανώτερα στελέχη της επιχείρησης Χρειάζεται ικανούς αναλυτές – συντονιστές Με την ολοκλήρωση της πρώτης φάσης έχουμε: Το μοντέλο του συστήματος Απαιτήσεις για το πρώτο πρότυπο Απαιτήσεις σε δεδομένα Απαιτήσεις σε εκπαίδευση χρηστών

18 Σχεδίαση από τους χρήστες
Joint Application Development Απαιτεί την ουσιαστική συμμετοχή των χρηστών Πρότυπο Repository Διεπαφές, διάλογοι, αναφορές

19 Σημαντικά σημεία της 2ης φάσης
Προσωπικό ειδικά εκπαιδευμένο στην κοινή σχεδίαση εφαρμογών Ένας (τουλάχιστον) τελικός χρήστης αναλαμβάνει την επιτάχυνση των διαδικασιών Να συμμετέχουν οι κατάλληλοι τελικοί χρήστες Η σχεδίαση να γίνεται με κατάλληλα εργαλεία. Να τηρείται αποθετήριο (repository) Οι συμμετέχοντες θα πρέπει να είναι πλήρους απασχόλησης.

20 Σημαντικά σημεία της 2ης φάσης
Οι πληροφορίες που χρησιμοποιούνται πρέπει να αντλούνται από το repository Καμία διακοπή (π.χ. τηλέφωνα) στη συνάντηση εργασίας (5-6 ημέρες) Όλοι οι συμμετέχοντες θεωρούνται ισότιμοι Οι υπεύθυνοι της συνάντησης θα πρέπει να έχουν κάνει καλή προετοιμασία Αν απαιτηθεί η συνάντηση της σχεδίασης μπορεί να προηγηθεί της συνάντησης για τις απαιτήσεις Ότι έχει παραχθεί από τη συνάντηση θεωρείται «πρόταση» Να αποφεύγεται η χρήση τεχνικής ορολογίας

21 Κατασκευή και μετάπτωση
Δεν χρησιμοποιούμε εξειδικευμένους προγραμματιστές. Με τα κατάλληλα εργαλεία, μικρές ομάδες αναλυτών και χρηστών κάνουν την κατασκευή Η μετάπτωση περιλαμβάνει: Εγκατάσταση, δοκιμές ελέγχου, υλοποίηση διεπαφών με άλλα συστήματα, εκπαίδευση χρηστών.

22 RAD – Πότε χρησιμοποιείται;
Όταν έχουμε ομάδα ανάπτυξης εξοικειωμένη με αυτή τη μέθοδο και με τα κατάλληλα αυτοματοποιημένα εργαλεία ανάπτυξης λογισμικού Όταν η επιχείρηση έχει λόγους να επιθυμεί γρήγορη ανάπτυξη, αναλαμβάνοντας το κόστος και το ρίσκο Για εφαρμογές διαδικτύου Όταν οι τελικοί χρήστες είναι έμπειροι και εξοικειωμένοι με την τεχνολογία

23 RAD – Πλεονεκτήματα Μείωση του χρόνου ανάπτυξης Μείωση του κόστους Η συμμετοχή των χρηστών είναι ουσιαστική Αντιμετώπιση αλλαγών, νωρίς στην ανάπτυξη του συστήματος Όταν ο χρόνος είναι σημαντικός, μπορεί να δώσει μία λύση.

24 DSDM – 5 φάσεις Μελέτη σκοπιμότητας Επιχειρηματική μελέτη
Επανάληψη λειτουργικού μοντέλου Επανάληψη σχεδιασμού και κατασκευής Υλοποίηση

25 DSDM

26 Μελέτη σκοπιμότητας Επιλέγουμε DSDM όταν το λογισμικό που θέλουμε να αναπτύξουμε: Είναι διαλογικό, με τη λειτουργικότητα εμφανή στις διεπαφές του χρήστη Όλες οι κατηγορίες χρηστών μπορούν να προσδιοριστούν άμεσα Μπορεί να αποδομηθεί σε ενότητες Είναι εφικτό να περιορισθεί χρονικά η ανάπτυξή του Οι απαιτήσεις χρηστών μπορούν να ιεραρχηθούν Το έργο μπορεί να χωριστεί σε τμήματα

27 Business study Εργαζόμαστε σε ομάδες εργασίας (workshops)
Καθορισμός επιχειρηματικής περιοχής Καθορισμός της αρχιτεκτονικής του συστήματος Περίγραμμα σχεδίου ανάπτυξης προτύπων (outline prototype plan) Σχέδιο διαχείρισης διαμόρφωσης συστήματος (system configuration plan)

28 Functional model iteration
Κύκλοι: Προσδιόρισε τι κάνεις στον κύκλο Συμφώνησε πώς πρόκειται να προχωρήσεις Πραγματοποίησέ το Έλεγξέ το

29 Λειτουργικό μοντέλο Περιλαμβάνει: Κώδικα προτύπου
Μοντέλα ανάλυσης (σχεδιαγράμματα κ.λπ.) Ταξινομημένες κατά προτεραιότητα λειτουργίες Έγγραφα αξιολόγησης λειτουργιών προτύπου Μη-λειτουργικές απαιτήσεις Ανάλυση της επικινδυνότητας

30 Design and Build Iteration - Implementation
Ελεγμένο σύστημα Εγχειρίδιο χρήσης Project review report

31 Χρονοπλαίσια Κάθε επανάληψη έχει ένα αυστηρό χρονοπλαίσιο, μερικών ημερών ή εβδομάδων Οι προτεραιότητες υλοποίησης ταξινομούνται βάσει MoSCoW: Must Should Could Will not have this time

32 Feature Driven Development
Φάσεις: Η ανάπτυξη ενός συνολικού μοντέλου Η δημιουργία λίστας γνωρισμάτων Ο προγραμματισμός (planning) ανά γνώρισμα Ο σχεδιασμός ανά γνώρισμα Η υλοποίηση ανά γνώρισμα Γνώρισμα = Κάτι μικρό, που έχει αξία για τον πελάτη. Μικρό σημαίνει: 1-10 ημέρες υλοποίησης

33 eXtreme Programming Πέντε αξίες: Επικοινωνία χρηστών-αναλυτών Απλότητα
Ανατροφοδότηση Θάρρος (...για αλλαγές) Σεβασμός

34 eXtreme Programming Δώδεκα πρακτικές:
Το παιχνίδι του προγραμματισμού (planning game) Διερευνητική φάση. Γράφουμε ένα σενάριο σε μία κάρτα Φάση δέσμευσης. Ιεραρχούμε τις ιστορίες Φάση διεύθυνσης. Παρακολούθηση (ανά τρεις εβδομάδες) της προόδου Μικρές εκδόσεις λογισμικού. Η πρώτη έκδοση μέσα σε 2-3 μήνες 40 ώρες την εβδομάδα Metaphor (μεταφορά). Καθοδηγεί το έργο Απλός σχεδιασμός

35 eXtreme Programming Δώδεκα πρακτικές:
Έλεγχος. Σχέδιο ελέγχου πριν την υλοποίηση. Λειτουργικός έλεγχος από τους χρήστες. Refactoring (επαναπαραμετροποίηση) Pair programming Συλλογική ιδιοκτησία του κώδικα Συνεχής ολοκλήρωση. Ο πελάτης είναι πάντα δίπλα Πρότυπα κωδικοποίησης

36 Σύνοψη Νέες μεθοδολογίες Ερωτήματα …