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

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

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

Η UML είναι μια γραφική γλώσσα για οπτικοποίηση, περιγραφή παραμέτρων, σχεδιασμό και τεκμηρίωση διαφόρων συστημάτων (κυρίως προγραμμάτων). Τα διαγράμματα δημιουργούνται χρησιμοποιώντας ειδικά εργαλεία CASE όπως το Rational Rose (http://www-01.ibm.com/software/rational/) και το Enterprise Architect (http://www.sparxsystems.com.au/). Βασισμένο στην τεχνολογία UML, ένα ενοποιημένο μοντέλο πληροφοριών. Τα παραπάνω εργαλεία CASE είναι ικανά να δημιουργούν κώδικα σε διάφορες αντικειμενοστρεφείς γλώσσες και έχουν επίσης πολύ χρήσιμο χαρακτηριστικόαντίστροφη μηχανική. (Η αντίστροφη μηχανική σάς επιτρέπει να δημιουργήσετε ένα γραφικό μοντέλο από τον υπάρχοντα κώδικα προγράμματος και σχόλια σε αυτόν.)

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

Χρησιμοποιήστε το διάγραμμα περίπτωσης

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

Διάγραμμα τάξης (διάγραμμα τάξης)

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

Διάγραμμα κατάστασης (διάγραμμα statechart)

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

Διάγραμμα ακολουθίας

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

Διάγραμμα συνεργασίας

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

Διάγραμμα συνιστωσών

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

Διάγραμμα ανάπτυξης

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

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

Είμαι πεπεισμένος ότι ένας προγραμματιστής είναι, πρώτα απ 'όλα, ένας κωδικοποιητής - ΔΕΝ πρέπει να επικοινωνεί με τον πελάτη, ΔΕΝ πρέπει να σκέφτεται την αρχιτεκτονική του συστήματος, δεν πρέπει να εφεύρει μια διεπαφή με το πρόγραμμα, πρέπει μόνο να κωδικοποιεί - να εφαρμόζει αλγόριθμους, λειτουργικότητα, εμφάνιση, χρηστικότητα, αλλά όχι περισσότερο…. Ο σχεδιαστής, ξεκινώντας από τα αφηρημένα διαγράμματα (που περιγράφουν τη θεματική περιοχή) έως τα διαγράμματα που αντιπροσωπεύουν τη δομή δεδομένων, τις τάξεις και τις διαδικασίες της αλληλεπίδρασής τους, πρέπει να περιγράψει τα πάντα βήμα προς βήμα λεπτομερώς. Δηλαδή, η πολυπλοκότητα της εργασίας και ο μισθός ενός σχεδιαστή θα πρέπει να είναι μια τάξη μεγέθους υψηλότερη από αυτή ενός προγραμματιστή == κωδικοποιητή. Συγγνώμη για την ατάκα....

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

1. "Μοντέλο καταρράκτη" (μοντέλο καταρράκτη ή "καταρράκτης")

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

Με τη βοήθεια του μοντέλου καταρράκτη, έχουμε δημιουργήσει πολλά έργα από την αρχή, συμπεριλαμβανομένης της ανάπτυξης μόνο τεχνικών προδιαγραφών. Έργα για τα οποία είναι γραμμένο στο Habré: medium - , small - .

Πότε να χρησιμοποιήσετε τη μεθοδολογία καταρράκτη;

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

2. "V-Model"

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

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

Πότε να χρησιμοποιήσετε το μοντέλο V;

• Εάν απαιτείται ενδελεχής δοκιμή προϊόντος, τότε το μοντέλο V θα δικαιολογήσει την υποκείμενη ιδέα: επικύρωση και επαλήθευση.
• Για μικρά και μεσαία έργα όπου οι απαιτήσεις είναι σαφώς καθορισμένες και καθορισμένες.
• Δεδομένης της διαθεσιμότητας μηχανικών με τα απαραίτητα προσόντα, ιδίως δοκιμαστών.

3. "Αυξητικό μοντέλο" (αυξητικό μοντέλο)

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

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

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

Πότε να χρησιμοποιήσετε ένα αυξητικό μοντέλο;

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

4. "Μοντέλο RAD" (μοντέλο ταχείας ανάπτυξης εφαρμογών ή ταχεία ανάπτυξη εφαρμογών)

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

Το μοντέλο ταχείας ανάπτυξης εφαρμογών περιλαμβάνει τις ακόλουθες φάσεις:

• Επιχειρηματική μοντελοποίηση: ορισμός λίστας ροών πληροφοριών μεταξύ διαφορετικών τμημάτων.
• Μοντελοποίηση δεδομένων: Οι πληροφορίες που συλλέγονται στο προηγούμενο βήμα χρησιμοποιούνται για τον καθορισμό των αντικειμένων και άλλων οντοτήτων που απαιτούνται για την κυκλοφορία των πληροφοριών.
• Μοντελοποίηση Διαδικασιών: Οι ροές πληροφοριών συνδέουν αντικείμενα για την επίτευξη στόχων σχεδιασμού.
• Δημιουργία εφαρμογής: Χρησιμοποιεί εργαλεία αυτόματης δημιουργίας για τη μετατροπή μοντέλων CAD σε κώδικα.
• Δοκιμή: δοκιμάζονται νέα στοιχεία και διεπαφές.

Πότε χρησιμοποιείται το μοντέλο RAD;

Μπορεί να χρησιμοποιηθεί μόνο με υψηλά καταρτισμένους και εξαιρετικά εξειδικευμένους αρχιτέκτονες. Ο προϋπολογισμός του έργου είναι αρκετά μεγάλος για να πληρώσει για αυτούς τους ειδικούς, μαζί με το κόστος των έτοιμων αυτοματοποιημένων εργαλείων συναρμολόγησης. Το μοντέλο RAD μπορεί να επιλεγεί εάν γνωρίζετε την επιχείρηση-στόχο με σιγουριά και πρέπει να παράγετε επειγόντως το σύστημα εντός 2-3 μηνών.

5. «Agile Model» (μεθοδολογία ευέλικτης ανάπτυξης)

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

Αυτός ο τύπος βασίζεται σε σύντομες καθημερινές συναντήσεις - "Scrum" και τακτικά επαναλαμβανόμενες συναντήσεις (μία φορά την εβδομάδα, μία φορά κάθε δύο εβδομάδες ή μία φορά το μήνα) που ονομάζονται "Sprint". Στις καθημερινές συναντήσεις, τα μέλη της ομάδας συζητούν:

• μια έκθεση για το έργο που έγινε από το τελευταίο Scrum·
• μια λίστα εργασιών που πρέπει να ολοκληρώσει ο εργαζόμενος πριν από την επόμενη συνάντηση·
• δυσκολίες που προέκυψαν κατά τη διάρκεια της εργασίας.

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

Πότε να χρησιμοποιήσετε το Agile;

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

6. "Επαναληπτικό μοντέλο" (επαναληπτικό ή επαναληπτικό μοντέλο)

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

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

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

Πότε είναι η καλύτερη στιγμή για να χρησιμοποιήσετε ένα επαναληπτικό μοντέλο;

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

7. "Spiral Model" (σπιράλ μοντέλο)

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

Το σπειροειδές μοντέλο υποθέτει 4 στάδια για κάθε στροφή:

1. σχεδίαση;
2. ανάλυση κινδύνου;
3. κατασκευή;
4. αξιολόγηση του αποτελέσματος και, εάν η ποιότητα είναι ικανοποιητική, η μετάβαση σε νέο γύρο.

Αυτό το μοντέλο δεν είναι κατάλληλο για μικρά έργα, είναι λογικό για πολύπλοκα και ακριβά, όπως η ανάπτυξη ενός συστήματος διαχείρισης εγγράφων για μια τράπεζα, όταν κάθε επόμενο βήμα απαιτεί περισσότερη ανάλυση για την αξιολόγηση των συνεπειών από τον προγραμματισμό. Στο έργο για την ανάπτυξη ενός EDMS για το ODU της Σιβηρίας SO UES, δύο συναντήσεις για την αλλαγή της κωδικοποίησης των τμημάτων ενός ηλεκτρονικού αρχείου χρειάζονται 10 φορές περισσότερο χρόνο από έναν προγραμματιστή που συνδυάζει δύο φακέλους. Τα κρατικά έργα στα οποία συμμετείχαμε ξεκίνησαν με την προετοιμασία από την κοινότητα των ειδικών ενός ακριβού concept, που σε καμία περίπτωση δεν είναι πάντα άχρηστο, αφού αποδίδει σε εθνική κλίμακα.

Ας συνοψίσουμε

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

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

Σχετικά με τις τεχνολογίες ανάπτυξης:
.
.
.
.

Ποιες μεθοδολογίες χρησιμοποιείτε;