Συστηματική προσέγγιση στην ανάπτυξη λογισμικού. Χρονικές και «χωρικές» πτυχές της συστημικής προσέγγισης. Μοντέλο κύκλου ζωής λογισμικού Cascade. Γενικές αρχές και προσεγγίσεις για την ανάπτυξη λογισμικού. Μοντέλα ανάπτυξης λογισμικού Λογισμικό Waterfall Cascade Model Spiral Extreme

Μοντέλα Ανάπτυξης Λογισμικού Waterfall Waterfall Model Spiral Extreme Programming UI Prototyping Αυξητική δοκιμή μοντέλου W Ενιαία Διαδικασία Ανάπτυξης Λογισμικού (USDP) Μεθοδολογία MSF

Μοντέλο καταρράκτη Ανάλυση απαιτήσεων Ανάπτυξη προδιαγραφών προϊόντος Σχεδιασμός Ανάπτυξη αρχιτεκτονικής προϊόντος Εφαρμογή Ανάπτυξη πηγαίου κώδικα Ενσωμάτωση μεμονωμένων τμημάτων πηγαίου κώδικα Δοκιμή και εξάλειψη ελαττωμάτων

Extreme Programming Ανάλυση αρχικών απαιτήσεων Ενσωμάτωση σχεδίασης Δοκιμή υλοποίησης Νέες απαιτήσεις Ανάλυση/Έγκριση/τροποποίηση σχεδίου ανάπτυξης Κυκλοφορία προϊόντος

UI Prototyping Έκδοση προϊόντος Ανάπτυξη λογισμικού λαμβάνοντας υπόψη τις αλλαγές Διευκρίνιση απαιτήσεων και προδιαγραφών Αλλαγή του πρωτοτύπου και οριστικοποίηση ορισμένων λειτουργιών Βασική λειτουργικότητα Πρωτότυπο διεπαφής Προκαταρκτική προδιαγραφή

Σταδιακή ανάπτυξη Επανάληψη 1 Επανάληψη 2…. Ανάλυση απαιτήσεων Σχεδιασμός Εφαρμογή Δοκιμή εξαρτημάτων Έλεγχος ολοκλήρωσης ολόκληρου του Iteration N

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

Συλλογή απαιτήσεων Ενοποιημένης Διαδικασίας Ανάπτυξης Λογισμικού (USDP) Iter 1…. Iter N Design Iter 1…. Iter N Εφαρμογή Iter 1…. Iter N Κατασκευή Iter 1…. Iter N Δοκιμή Iter 1…. Ίτερ Ν

Τυπικά στοιχεία αρχιτεκτονικής προϊόντος λογισμικού και τυπικές απαιτήσεις λογισμικού Ø Ø Ø Ø Οργάνωση προγράμματος Βασικές τάξεις συστήματος Οργάνωση δεδομένων Επιχειρηματικοί κανόνες Διεπαφή χρήστη Διαχείριση πόρων Ασφάλεια Απόδοση Επεκτασιμότητα Αλληλεπίδραση με άλλα συστήματα (ολοκλήρωση) Διεθνοποίηση, τοπική προσαρμογή Είσοδος-έξοδος δεδομένων Διαχείριση σφαλμάτων

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

Τυπικά στοιχεία αρχιτεκτονικής προϊόντος λογισμικού και τυπικές απαιτήσεις λογισμικού Καμπύλη αξιοπιστίας N t 1 t Όσο πιο μακριά προχωράτε, τόσο πιο δύσκολο θα είναι να βρείτε ένα σφάλμα. Όσο πιο περίπλοκο είναι το σύστημα, τόσο μεγαλύτερη είναι η πιθανότητα αστοχιών και αστοχιών.

Τυπικά στοιχεία αρχιτεκτονικής προϊόντος λογισμικού και τυπικές απαιτήσεις λογισμικού Ø Δυνατότητα υλοποίησης της ανεπτυγμένης αρχιτεκτονικής. Ø Περιττή λειτουργικότητα. Ø Λήψη απόφασης αγοράς έτοιμων εξαρτημάτων λογισμικού. Ø Αλλαγή στρατηγικής.

Μια λίστα ελέγχου ερωτήσεων που σας επιτρέπει να βγάλετε ένα συμπέρασμα σχετικά με την ποιότητα της αρχιτεκτονικής: Ø Περιγράφεται με σαφήνεια η συνολική οργάνωση του προγράμματος; Ø Ø Ø Περιλαμβάνει η προδιαγραφή επισκόπηση της αρχιτεκτονικής και του σκεπτικού της; Τα κύρια στοιχεία του προγράμματος, οι αρμοδιότητες και οι αλληλεπιδράσεις τους με άλλα στοιχεία έχουν καθοριστεί επαρκώς; Εάν όλες οι λειτουργίες που καθορίζονται στην προδιαγραφή απαιτήσεων υλοποιούνται από έναν εύλογο αριθμό στοιχείων του συστήματος. Υπάρχει περιγραφή των πιο σημαντικών τάξεων και του σκεπτικού τους; Παρέχεται περιγραφή της οργάνωσης της βάσης δεδομένων; Έχουν καθοριστεί όλοι οι επιχειρηματικοί κανόνες; Περιγράφεται ο αντίκτυπός τους στο σύστημα;

Μια λίστα ελέγχου ερωτήσεων που σας επιτρέπει να βγάλετε ένα συμπέρασμα σχετικά με την ποιότητα της αρχιτεκτονικής: Ø Περιγράφεται η στρατηγική σχεδιασμού της διεπαφής χρήστη; ØΗ διεπαφή χρήστη είναι αρθρωτή έτσι ώστε οι αλλαγές σε αυτήν να μην επηρεάζουν το υπόλοιπο σύστημα. Ø Υπάρχει περιγραφή της στρατηγικής εισαγωγής/εξόδου δεδομένων; ØΈχει πραγματοποιηθεί ανάλυση απόδοσης του συστήματος που θα υλοποιηθεί χρησιμοποιώντας αυτήν την αρχιτεκτονική; ØΈχει πραγματοποιηθεί ανάλυση αξιοπιστίας του σχεδιασμένου συστήματος; ØΈχει γίνει ανάλυση των θεμάτων επεκτασιμότητας και επεκτασιμότητας του συστήματος;

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

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

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

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

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

Μοντέλο καταρράκτη Ανάλυση απαιτήσεων Σχεδιασμός Υλοποίηση Έλεγχος ενσωμάτωσης Δημιουργία προδιαγραφών προϊόντος Δημιουργία αρχιτεκτονικής προϊόντος Ανάπτυξη πηγαίου κώδικα Ενσωμάτωση μεμονωμένων τμημάτων του πηγαίου κώδικα Δοκιμή και εξάλειψη ελαττωμάτων

Το Μοντέλο Περίπτωσης Χρήσης Ενοποιημένης Διαδικασίας Ανάπτυξης Λογισμικού (USDP) περιγράφει τις περιπτώσεις στις οποίες θα χρησιμοποιηθεί η εφαρμογή. Το αναλυτικό μοντέλο περιγράφει τις βασικές κατηγορίες για την εφαρμογή. Το μοντέλο σχεδίασης περιγράφει τις συνδέσεις και τις σχέσεις μεταξύ κλάσεων και αποκλειστικών αντικειμένων Το μοντέλο ανάπτυξης περιγράφει την κατανομή του λογισμικού στους υπολογιστές. Το μοντέλο υλοποίησης περιγράφει την εσωτερική οργάνωση του κώδικα προγράμματος. Ένα μοντέλο δοκιμής αποτελείται από εξαρτήματα δοκιμής, διαδικασίες δοκιμής και διάφορες περιπτώσεις δοκιμών.

Τυπικά στοιχεία αρχιτεκτονικής προϊόντος λογισμικού και τυπικές απαιτήσεις λογισμικού Οργάνωση προγράμματος Βασικές τάξεις συστήματος Οργάνωση δεδομένων Επιχειρηματικοί κανόνες Διεπαφή χρήστη Διαχείριση πόρων Ασφάλεια Απόδοση Επεκτασιμότητα Αλληλεπίδραση με άλλα συστήματα (ολοκλήρωση) Διεθνοποίηση, τοπική προσαρμογή Εισαγωγή/έξοδος δεδομένων Διαχείριση σφαλμάτων

Τυπικά στοιχεία αρχιτεκτονικής προϊόντος λογισμικού και τυπικές απαιτήσεις λογισμικού για την υλοποίηση της ανεπτυγμένης αρχιτεκτονικής. Δυνατότητα υλοποίησης της ανεπτυγμένης αρχιτεκτονικής. Περιττή λειτουργικότητα. Περιττή λειτουργικότητα. Λήψη απόφασης αγοράς έτοιμων εξαρτημάτων λογισμικού. Λήψη απόφασης αγοράς έτοιμων εξαρτημάτων λογισμικού. Αλλαγή στρατηγικής. Αλλαγή στρατηγικής.

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

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

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

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

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

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

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

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

Σύμφωνα με το διεθνές πρότυπο ISO/IEC 12207 «Τεχνολογία πληροφοριών - Διαδικασίες κύκλου ζωής λογισμικού», η διαδικασία ανάπτυξης λογισμικού περιλαμβάνει τα ακόλουθα στάδια του κύκλου ζωής του λογισμικού:

1) ανάλυση των απαιτήσεων του συστήματος και του πεδίου εφαρμογής.

2) Σχεδιασμός αρχιτεκτονικής συστήματος.

3) ανάλυση των απαιτήσεων λογισμικού (προδιαγραφές, εξωτερικές διεπαφές).

4) σχεδιασμός αρχιτεκτονικής λογισμικού.

5) λεπτομερής σχεδιασμός κάθε μονάδας λογισμικού.

6) Κωδικοποίηση λογισμικού (προγραμματισμός)

7) δοκιμή μονάδων λογισμικού.

8) ενοποίηση (συνδυασμός λογισμικού) και δοκιμή ενός συνόλου μονάδων λογισμικού.

9) δοκιμές πιστοποίησης λογισμικού (ολοκληρωτικές δοκιμές).

10) Οι μονάδες δομής λογισμικού ενοποίησης συστήματος πρέπει να είναι ενσωματωμένες με μονάδες υλικού.

11) δοκιμές πιστοποίησης συστήματος.

12) εγκατάσταση λογισμικού.

Έτσι, η διαδικασία ανάπτυξης λογισμικού ξεκινά από το σύστημα όπου θα χρησιμοποιηθεί το λογισμικό και καταλήγει ξανά στο σύστημα.

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

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

Σπειροειδές μοντέλο κύκλου ζωής λογισμικού. «Βαριές και ελαφριές» (γρήγορες) τεχνολογίες ανάπτυξης λογισμικού

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

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

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

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

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

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

Υπάρχει μια κατεύθυνση των «Γρήγορων Τεχνολογιών» ανάπτυξης λογισμικού (Agile Software Development), η οποία παρέχει ιδεολογική αιτιολόγηση για τις απόψεις που σχετίζονται με το σπειροειδές μοντέλο του κύκλου ζωής. Αυτές οι τεχνολογίες βασίζονται σε τέσσερις ιδέες:

Η διαδραστική αλληλεπίδραση των ατόμων είναι πιο σημαντική από τις επίσημες διαδικασίες και τα εργαλεία,

Το λογισμικό εργασίας είναι πιο σημαντικό από την τεκμηρίωση για αυτό,

Η συνεργασία με τον πελάτη είναι πιο σημαντική από τις επίσημες συμβάσεις,

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

Ρύζι. 8.2 - Σχέδιο λογισμικού κύκλου ζωής σπειροειδών

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

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

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

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

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

«Βαριές και ελαφριές» τεχνολογίες ανάπτυξης λογισμικού . Οι προγραμματιστές πολλών τύπων λογισμικού θεωρούν ότι το μοντέλο του κύκλου ζωής του καταρράκτη είναι υπερβολικά ρυθμισμένο, πολύ τεκμηριωμένο και βαρύ και επομένως παράλογο. Υπάρχει μια κατεύθυνση «Fast Technologies» (ελαφρές τεχνολογίες) ανάπτυξης λογισμικού (Agile Software Development), η οποία παρέχει ιδεολογική αιτιολόγηση για αυτές τις απόψεις. Αυτές οι τεχνολογίες βασίζονται σε τέσσερις ιδέες:

1. Η διαδραστική αλληλεπίδραση των ατόμων είναι πιο σημαντική από τις επίσημες διαδικασίες και εργαλεία,

2. Το λογισμικό που λειτουργεί είναι πιο σημαντικό από την τεκμηρίωση για αυτό,

3. Η συνεργασία με τον πελάτη είναι πιο σημαντική από τις επίσημες συμβάσεις μαζί του,

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

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

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

Ένα παράδειγμα τεχνολογιών Agile είναι ο Extreme Programming (XP). Οι επαναλήψεις στα XP είναι πολύ σύντομες και αποτελούνται από τέσσερις λειτουργίες: κωδικοποίηση, δοκιμή, ακρόαση του πελάτη, σχεδιασμός. Οι αρχές των XP - μινιμαλισμός, απλότητα, συμμετοχή των πελατών, σύντομος κύκλος, στενή αλληλεπίδραση μεταξύ προγραμματιστών - θα πρέπει να κάθονται στο ίδιο δωμάτιο, οι καθημερινές επιχειρησιακές συναντήσεις με τον πελάτη φαίνονται λογικές και έχουν χρησιμοποιηθεί από καιρό όχι μόνο σε γρήγορες τεχνολογίες, αλλά και σε XP οδηγούνται σε ακραίες αξίες.

Μια ανάλυση πολλών έργων λογισμικού έδειξε ότι οι ελαφριές τεχνολογίες που κηρύττουν τις αρχές της αυτοοργάνωσης, δίνοντας έμφαση στη χρήση ατομικών ικανοτήτων προγραμματιστών, σύντομες επαναλήψεις ανάπτυξης σε ένα σπειροειδές μοντέλο, XP, SCRUM είναι κοινές και συχνά οδηγούν σε επιτυχία, κάνοντας τα περισσότερα από τα χαρακτηριστικά της εργασίας σε μικρές ομάδες.

Όπου η εσφαλμένη λειτουργία λογισμικού οδηγεί σε απειλή για ανθρώπινη ζωή ή σε μεγάλες υλικές απώλειες, θα πρέπει να χρησιμοποιούνται τακτικές, πλήρως μελετημένες και προβλέψιμες επίσημες «βαριές» τεχνολογίες, διασφαλίζοντας την αξιοπιστία του προϊόντος λογισμικού ακόμη και στην περίπτωση προγραμματιστών μεσαίας ειδίκευσης Με την αύξηση της κλίμακας του έργου λογισμικού, αύξηση του αριθμού των συμμετεχόντων Σε αυτόν τον τομέα, αυξάνεται η ανάγκη για μια άκαμπτη και επίσημη τεχνολογία ανάπτυξης που καθορίζει την ευθύνη κάθε συμμετέχοντος στην ανάπτυξη που αποτελεί τον κύκλο ζωής του λογισμικού καταρράκτη. . Δεν είναι τυχαίο ότι το μοντέλο κύκλου ζωής καταρράκτη περιλαμβάνεται στα πρότυπα ανάπτυξης λογισμικού.

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

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

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

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

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

Όλες οι πιο κοινές μέθοδοι της δομικής προσέγγισης βασίζονται σε μια σειρά από γενικές αρχές:

1. Η αρχή του «διαίρει και βασίλευε».

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

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

1. Η αρχή της αφαίρεσης - ανάδειξη των ουσιαστικών πτυχών του συστήματος και αφαίρεση από το ασήμαντο.

2. Η αρχή της συνέπειας, της εγκυρότητας και της συνέπειας των στοιχείων του συστήματος.

3. Αρχή της δόμησης δεδομένων - τα δεδομένα πρέπει να είναι δομημένα και ιεραρχικά οργανωμένα.

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

· DFD (Διαγράμματα ροής δεδομένων) - διαγράμματα ροής δεδομένων.

· SADT (Structured Analysis and Design Technique - μεθοδολογία δομικής ανάλυσης και σχεδίασης) - μοντέλα και αντίστοιχα λειτουργικά διαγράμματα: σημειώσεις IDEF0 (λειτουργική μοντελοποίηση συστημάτων), IDEF1х (εννοιολογική μοντελοποίηση βάσεων δεδομένων), IDEF3х (κατασκευή συστημάτων για την αξιολόγηση της ποιότητας την εργασία ενός αντικειμένου γραφική περιγραφή των διεργασιών ροής, αλληλεπίδραση διαδικασιών και αντικειμένων που αλλάζουν από αυτές τις διεργασίες·

· ERD (Entity - Relationship Diagrams) - διαγράμματα οντοτήτων-σχέσεων.

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

1. Διαγράμματα που απεικονίζουν τις λειτουργίες που πρέπει να εκτελεί το σύστημα και τις σχέσεις μεταξύ αυτών των λειτουργιών - DFD ή SADT (IDEF0).

2. Διαγράμματα που μοντελοποιούν δεδομένα και τις σχέσεις τους (ERD).

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

Στο στάδιο της διαμόρφωσης απαιτήσεων λογισμικού, τα μοντέλα SADT και DFD χρησιμοποιούνται για την κατασκευή του μοντέλου «AS-IS» και του μοντέλου «TO-BE», αντικατοπτρίζοντας έτσι την υπάρχουσα και προτεινόμενη δομή των επιχειρηματικών διαδικασιών του οργανισμού και την αλληλεπίδραση μεταξύ τους. η χρήση μοντέλων SADT όπως συνήθως περιορίζεται μόνο σε αυτό το στάδιο, καθώς δεν προορίζονταν αρχικά για σχεδιασμό λογισμικού). Με τη βοήθεια του ERD, πραγματοποιείται περιγραφή των δεδομένων που χρησιμοποιούνται στον οργανισμό σε εννοιολογικό επίπεδο, ανεξάρτητα από τα εργαλεία υλοποίησης της βάσης δεδομένων (DBMS).

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

Μπορείτε να κατεβάσετε την παρουσίαση για αυτή τη διάλεξη.

Σκοπός της διάλεξης:

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

Εισαγωγή

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

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

Αρχές και νόημα της ευέλικτης ανάπτυξης

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

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

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

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

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

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

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

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

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

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

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

AgileModeling	ένα σύνολο εννοιών, αρχών και τεχνικών (πρακτικών) που σας επιτρέπουν να εκτελείτε γρήγορα και εύκολα μοντελοποίηση και τεκμηρίωση σε έργα ανάπτυξης λογισμικού.
AgileUnifiedProcess (AUP)	μια απλοποιημένη έκδοση του IBM RationalUnifiedProcess (RUP), η οποία περιγράφει μια απλή και κατανοητή προσέγγιση (μοντέλο) για τη δημιουργία λογισμικού για επιχειρηματικές εφαρμογές.
OpenUP	Είναι μια επαναληπτική-αυξητική μέθοδος ανάπτυξης λογισμικού. Τοποθετείται ως μια ελαφριά και ευέλικτη έκδοση του RUP.
AgileDataMethod	μια ομάδα επαναληπτικών μεθόδων ανάπτυξης λογισμικού στις οποίες οι απαιτήσεις και οι λύσεις επιτυγχάνονται μέσω της συνεργασίας διαφορετικών διαλειτουργικών ομάδων·
DSDM	μια μεθοδολογία για την ανάπτυξη δυναμικών συστημάτων που βασίζεται στην έννοια της ταχείας ανάπτυξης εφαρμογών (RapidApplicationDevelopment, RAD). Είναι μια επαναληπτική και σταδιακή προσέγγιση που δίνει έμφαση στη συνεχή συμμετοχή των χρηστών/καταναλωτών στη διαδικασία.
Ακραίος προγραμματισμός (XP)	ακραίος προγραμματισμός?
Προσαρμοστική ανάπτυξη λογισμικού (ADD)	προσαρμοστική ανάπτυξη λογισμικού?
Ανάπτυξη με γνώμονα τα χαρακτηριστικά (FDD)	ανάπτυξη επικεντρώθηκε στη σταδιακή προσθήκη λειτουργικότητας.
GettingReal	μια επαναληπτική προσέγγιση χωρίς λειτουργικές προδιαγραφές που χρησιμοποιείται για διαδικτυακές εφαρμογές.
MSFfogAgileSoftwareDevelopment	Η ευέλικτη μεθοδολογία ανάπτυξης λογισμικού της Microsoft.
Scrum	θεσπίζει κανόνες για τη διαχείριση της διαδικασίας ανάπτυξης και σας επιτρέπει να χρησιμοποιείτε υπάρχουσες πρακτικές κωδικοποίησης, να προσαρμόζετε τις απαιτήσεις ή να κάνετε αλλαγές τακτικής [