Στο πρώτο μέρος, επιλέξαμε να συγκρίνουμε μεθοδολογίες ανάπτυξης λογισμικού, όπως δείκτες όπως η αναλογία μεθοδολογίας προς την επαναληπτική ανάπτυξη και ο βαθμός τυπικότητας στο σχεδιασμό των υλικών εργασίας και γενικά στην ανάπτυξη. Σε αυτό το μέρος, χρησιμοποιούμε αυτές τις μετρήσεις για να συγκρίνουμε τις πιο γνωστές πρακτικές ανάπτυξης λογισμικού.
Θα δούμε πώς θα πάει…
Αλίμονο, αυτή είναι η πιο δύσκολη κατηγορία για να περιγραφεί - άλλωστε, περιλαμβάνει τόσο το προϊόν της σπασμωδικής ρίψης ενός αρχάριου που προσπαθεί να ολοκληρώσει το πρώτο του έργο με οποιοδήποτε κόστος, όσο και αρκετά ώριμες και καθιερωμένες μεθοδολογίες που έχουν απορροφήσει πολλά χρόνια διαφοροποιημένη εμπειρία από συγκεκριμένες ομάδες ανάπτυξης και ακόμη και περιγράφεται σε εσωτερικούς κανονισμούς. Δεδομένου ότι οι άνθρωποι που είναι σε θέση να αναπτύξουν τη δική τους μεθοδολογία, κατά κανόνα, μπορούν οι ίδιοι να την αξιολογήσουν ως προς την επανάληψη και την επισημοποίηση, θα εστιάσουμε στους αρχάριους. Δυστυχώς, τις περισσότερες φορές αυτό σημαίνει ότι οι κανόνες για τη διεξαγωγή της ανάπτυξης είτε δεν υπάρχουν καθόλου, είτε έχουν αναπτυχθεί και υιοθετηθεί, αλλά δεν εφαρμόζονται. Φυσικό σε τέτοιες συνθήκες είναι ένα εξαιρετικά χαμηλό επίπεδο αναπτυξιακού φορμαλισμού. Όλα αυτά λοιπόν είναι ξεκάθαρα.
Ανάπτυξη "Πώς λειτουργεί"
Τι θα λέγατε για μια επαναληπτική προσέγγιση; Δυστυχώς, κατά κανόνα, δεν χρησιμοποιείται σε τέτοια έργα. Πρώτα απ 'όλα, γιατί θα επέτρεπε ακόμη και στις πρώτες επαναλήψεις να αξιολογηθεί το έργο ως εξαιρετικά αμφίβολο και που απαιτεί επείγουσα παρέμβαση από την ανώτερη διοίκηση για την αποκατάσταση της τάξης. Άλλωστε, σε ένα επαναληπτικό έργο, η παραδοσιακή απάντηση του προγραμματιστή ότι τα πάντα είναι 90% έτοιμα για αυτόν διαρκεί μόνο μέχρι την ολοκλήρωση της πρώτης επανάληψης…
Δομικές Μεθοδολογίες
Δομικές Μεθοδολογίες
Οι δομικές μέθοδοι είναι μια ομάδα μεθοδολογιών που αναπτύχθηκαν, κατά κανόνα, ακόμη και πριν από την ευρεία χρήση αντικειμενοστρεφών γλωσσών. Όλα περιλαμβάνουν ανάπτυξη καταρράκτη. Αν και, όπως αποδείχθηκε, ακόμη και σε αυτό το άρθρο, το οποίο αναφέρεται συχνά ως η πρώτη παρουσίαση της προσέγγισης του καταρράκτη, ειπώθηκε ότι είναι επιθυμητό να ξεκινήσει το έργο με την ανάπτυξη ενός πρωτοτύπου, δηλαδή να εκτελεστεί τουλάχιστον δύο επαναλήψεις.
Ωστόσο, η βάση αυτών των μεθοδολογιών είναι η διαδοχική μετάβαση από την εργασία στην εργασία και η μεταφορά των αποτελεσμάτων (εγγράφων) του επόμενου σταδίου στους συμμετέχοντες του επόμενου.
Επίσης, όλες αυτές οι μεθοδολογίες προϋποθέτουν μια εξαιρετικά επισημοποιημένη προσέγγιση, αν και μπορούν να βρεθούν δηλώσεις σχετικά με εύλογη ποσότητα τεκμηρίωσης. Ένα από τα μη προφανή παραδείγματα του γεγονότος ότι οι μεθοδολογίες ανάπτυξης λογισμικού αναπτύχθηκαν όχι μόνο στη Δύση είναι ένα απόσπασμα από ένα βιβλίο που δημοσιεύτηκε στη χώρα μας στις αρχές της δεκαετίας του 1980, το οποίο αναφέρει ότι ο βαθμός επισημοποίησης μιας προγραμματιστικής εργασίας πρέπει να προσδιορίζεται με βάση για το πόσο καλά ο αναλυτής και ο προγραμματιστής. Και αυτό παρά το γεγονός ότι το θέμα του βιβλίου αφορούσε την ανάπτυξη αρκετά κρίσιμων, όπως ονομάζονται πλέον, συστημάτων, σφαλμάτων στα οποία οδηγούν σε σοβαρές απώλειες ή και καταστροφές.
Agile Methodologies
Οι ευέλικτες μεθοδολογίες βασίζονται σε δέκα αρχές, από τις οποίες θα ονομάσουμε μόνο αυτές που καθορίζουν την αξιολόγηση αυτών των μεθοδολογιών σύμφωνα με τις επιλεγμένες παραμέτρους:
- το κύριο πράγμα είναι να ικανοποιήσετε τον πελάτη και να του παρέχετε το προϊόν το συντομότερο δυνατό.
- νέες εκδόσεις του προϊόντος θα πρέπει να εμφανίζονται κάθε λίγες εβδομάδες, σε ακραίες περιπτώσεις - μήνες.
- πλέον αποτελεσματική μέθοδοςμεταφορά γνώσης στους συμμετέχοντες στην ανάπτυξη και μεταξύ τους - προσωπική επικοινωνία.
- ένα τρέχον πρόγραμμα είναι ο καλύτερος δείκτης της αναπτυξιακής προόδου.
Έτσι, αυτές οι μέθοδοι εστιάζονται σαφώς στην επαναληπτική ανάπτυξη λογισμικού και στην ελάχιστη επισημοποίηση της διαδικασίας. Ωστόσο, είναι απαραίτητο να κάνουμε μια επιφύλαξη σχετικά με το δεύτερο σημείο: αυτές οι μέθοδοι επικεντρώνονται στο ελάχιστο επίπεδο επισημοποίησης που είναι αποδεκτό για ένα δεδομένο έργο. Τουλάχιστον μία από τις μεθοδολογίες που περιλαμβάνονται στην ευέλικτη ομάδα - Crystal - έχει τροποποιήσεις που έχουν σχεδιαστεί για την εκτέλεση διεργασιών με διαφορετικό αριθμό συμμετεχόντων και διαφορετική κρισιμότητα του λογισμικού που αναπτύσσεται (η κρισιμότητα του λογισμικού καθορίζεται από τις πιθανές συνέπειες σφαλμάτων, τα οποία μπορεί να διαφέρουν από μικρές οικονομικές απώλειες για τη διόρθωση ενός σφάλματος σε ένα καταστροφικό). Για να μην είναι άσκοπη περαιτέρω σύγκριση με ευέλικτες μεθοδολογίες, θα δώσουμε σύντομες περιγραφές αρκετών από αυτές.
eXtreme Programming ή XP (extreme Programming)
Η μεθοδολογία XP, που αναπτύχθηκε από τους Kent Beck, Ward Cunningham και Ron Jeffries, είναι η πιο γνωστή από τις ευέλικτες μεθοδολογίες σήμερα. Μερικές φορές η ίδια η έννοια των «ευκίνητων μεθοδολογιών» ταυτίζεται ρητά ή σιωπηρά με το XP, το οποίο κηρύττει την κοινωνικότητα, την απλότητα, ανατροφοδότησηκαι κουράγιο. Περιγράφεται ως ένα σύνολο πρακτικών: το παιχνίδι προγραμματισμού, σύντομες εκδόσεις, μεταφορές, απλή σχεδίαση, ανακατασκευή κώδικα, ανάπτυξη δοκιμαστικών εκ των προτέρων, προγραμματισμός ζευγών, συλλογική ιδιοκτησία κώδικα, 40ωρη εβδομάδα εργασίας, παρουσία πελατών και πρότυπα κώδικα. Το ενδιαφέρον για τα XP αυξήθηκε από κάτω προς τα πάνω - από προγραμματιστές και δοκιμαστές, που βασανίζονται από επώδυνες διαδικασίες, τεκμηρίωση, μετρήσεις και άλλους φορμαλισμούς. Δεν απέρριψαν την πειθαρχία, αλλά ήταν απρόθυμοι να ακολουθήσουν τις τυπικές απαιτήσεις χωρίς νόημα και αναζήτησαν νέες γρήγορες και ευέλικτες προσεγγίσεις για την ανάπτυξη προγραμμάτων υψηλής ποιότητας.
Κατά τη χρήση XP, η προσεκτική προκαταρκτική σχεδίαση λογισμικού αντικαθίσταται, αφενός, από τη συνεχή παρουσία του πελάτη στην ομάδα, έτοιμο να απαντήσει σε οποιαδήποτε ερώτηση και να αξιολογήσει οποιοδήποτε πρωτότυπο, και, αφετέρου, από τακτικές αναθεωρήσεις κώδικα (τα λεγόμενα ανακατασκευή). Ο λεπτομερώς σχολιασμένος κώδικας θεωρείται η βάση της τεκμηρίωσης σχεδιασμού. Μεγάλη προσοχή στη μεθοδολογία δίνεται στις δοκιμές. Κατά κανόνα, για κάθε νέα μέθοδο, πρώτα γράφεται μια δοκιμή και στη συνέχεια αναπτύσσεται ο πραγματικός κώδικας της μεθόδου έως ότου η δοκιμή αρχίσει να εκτελείται με επιτυχία. Αυτές οι δοκιμές αποθηκεύονται σε σουίτες που εκτελούνται αυτόματα μετά από οποιαδήποτε αλλαγή κώδικα.
Ενώ ο προγραμματισμός ζευγών και η 40ωρη εβδομάδα εργασίας είναι ίσως τα πιο γνωστά χαρακτηριστικά του XP, εξακολουθούν να είναι βοηθητικά στη φύση τους και συμβάλλουν στην υψηλή παραγωγικότητα των προγραμματιστών και στη μείωση των σφαλμάτων ανάπτυξης.
Πεντακάθαρη
Το Crystal είναι μια οικογένεια μεθοδολογιών που καθορίζουν τον απαιτούμενο βαθμό επισημοποίησης της διαδικασίας ανάπτυξης, ανάλογα με τον αριθμό των συμμετεχόντων και την κρισιμότητα των εργασιών.
Η μεθοδολογία Crystal Clear είναι κατώτερη από τα XP όσον αφορά την απόδοση, αλλά είναι όσο το δυνατόν πιο εύκολη στη χρήση. Απαιτεί ελάχιστη προσπάθεια για την εφαρμογή του γιατί εστιάζει στις ανθρώπινες συνήθειες. Πιστεύεται ότι αυτή η μεθοδολογία περιγράφει τη φυσική σειρά ανάπτυξης λογισμικού, η οποία καθιερώνεται σε επαρκώς καταρτισμένες ομάδες, εάν δεν ασχολούνται με τη σκόπιμη εφαρμογή άλλης μεθοδολογίας.
Βασικά χαρακτηριστικά του Crystal Clear:
- επαναληπτική σταδιακή ανάπτυξη.
- αυτόματη δοκιμή παλινδρόμησης?
- οι χρήστες συμμετέχουν ενεργά στο έργο·
- η σύνθεση της τεκμηρίωσης καθορίζεται από τους συμμετέχοντες στο έργο·
- Κατά κανόνα, χρησιμοποιούνται εργαλεία ελέγχου έκδοσης κώδικα.
Εκτός από το Crystal Clear, υπάρχουν πολλές άλλες μεθοδολογίες στην οικογένεια Crystal που έχουν σχεδιαστεί για μεγαλύτερα ή πιο κρίσιμα έργα. Διαφέρουν ως προς τις ελαφρώς πιο αυστηρές απαιτήσεις για τον όγκο της τεκμηρίωσης και τις υποστηρικτικές διαδικασίες, όπως η αλλαγή και ο έλεγχος έκδοσης.
Ανάπτυξη με γνώμονα τα χαρακτηριστικά
Το Feature Driven Development (FDD) λειτουργεί με βάση ένα χαρακτηριστικό ή χαρακτηριστικό του συστήματος, το οποίο είναι αρκετά κοντά στην έννοια της περίπτωσης χρήσης RUP. Ίσως η πιο σημαντική διαφορά είναι ένας πρόσθετος περιορισμός: "κάθε συνάρτηση πρέπει να επιτρέπει την υλοποίηση σε όχι περισσότερο από δύο εβδομάδες." Δηλαδή, εάν η περίπτωση χρήσης είναι αρκετά μικρή, μπορεί να θεωρηθεί συνάρτηση και αν είναι μεγάλη, τότε θα πρέπει να αναλυθεί σε αρκετές σχετικά ανεξάρτητες συναρτήσεις.
Το FDD περιλαμβάνει πέντε διαδικασίες, με τις δύο τελευταίες να επαναλαμβάνονται για κάθε χαρακτηριστικό:
- ανάπτυξη ενός κοινού μοντέλου·
- σύνταξη λίστας απαραίτητων λειτουργιών του συστήματος.
- προγραμματισμός εργασιών για κάθε λειτουργία·
- Σχεδιασμός λειτουργίας?
- κατασκευή λειτουργίας.
Η εργασία στο έργο περιλαμβάνει συχνές κατασκευές και χωρίζεται σε επαναλήψεις, καθεμία από τις οποίες υλοποιείται χρησιμοποιώντας ένα συγκεκριμένο σύνολο χαρακτηριστικών.
Οι προγραμματιστές στο FDD χωρίζονται σε "μάστερ της τάξης" και "αρχηγούς προγραμματιστές". Οι κύριοι προγραμματιστές εμπλέκουν τους ιδιοκτήτες των εμπλεκόμενων τάξεων για να εργαστούν στο επόμενο ακίνητο. Για σύγκριση: στα XP δεν υπάρχουν προσωπικά υπεύθυνοι για κλάσεις ή μεθόδους.
Κοινά χαρακτηριστικά
Ο κατάλογος των ευέλικτων μεθοδολογιών είναι επί του παρόντος αρκετά ευρύς. Ωστόσο, οι μεθοδολογίες που περιγράψαμε δίνουν μια πολύ ολοκληρωμένη εικόνα ολόκληρης της οικογένειας.
Σχεδόν όλες οι ευέλικτες μεθοδολογίες χρησιμοποιούν μια επαναληπτική προσέγγιση, στην οποία μόνο ένας περιορισμένος όγκος εργασίας που σχετίζεται με την κυκλοφορία της επόμενης κυκλοφορίας σχεδιάζεται λεπτομερώς.
Σχεδόν όλες οι ευέλικτες μεθοδολογίες επικεντρώνονται στην πιο άτυπη προσέγγιση της ανάπτυξης. Εάν το πρόβλημα μπορεί να λυθεί κατά τη διάρκεια μιας κανονικής συνομιλίας, τότε είναι καλύτερο να κάνετε ακριβώς αυτό. Και να συντάξει απόφασησε χάρτινη μορφή ή ηλεκτρονικό έγγραφοαπαραίτητο μόνο όταν είναι αδύνατο να γίνει χωρίς αυτό.
Agile Methodologies
GOST
Οι GOST, όπως και οι απαιτήσεις CMM που περιγράφονται στην επόμενη ενότητα, δεν είναι μεθοδολογίες. Κατά κανόνα, δεν περιγράφουν τις ίδιες τις διαδικασίες ανάπτυξης λογισμικού, αλλά μόνο διατυπώνουν ορισμένες απαιτήσειςσε διαδικασίες στις οποίες αντιστοιχούν διαφορετικές μεθοδολογίες στον έναν ή τον άλλο βαθμό. Η σύγκριση των απαιτήσεων σύμφωνα με τα ίδια κριτήρια με τα οποία συγκρίνουμε τις μεθοδολογίες θα σας βοηθήσει να αποφασίσετε αμέσως ποιες μεθοδολογίες θα πρέπει να χρησιμοποιήσετε εάν πρέπει να αναπτύξετε σύμφωνα με το GOST.
Επί του παρόντος, ισχύουν στη Ρωσία παλιά GOST της 19ης και 34ης σειράς και άλλα νέο GOST R ISO IEC 122207. Οι GOST της 19ης και 34ης σειράς επικεντρώνονται αυστηρά στην προσέγγιση καταρράκτη στην ανάπτυξη λογισμικού. Η ανάπτυξη σύμφωνα με αυτά τα GOST πραγματοποιείται σε στάδια, καθένα από τα οποία περιλαμβάνει την εκτέλεση αυστηρά καθορισμένων εργασιών και τελειώνει με την απελευθέρωση επαρκώς ένας μεγάλος αριθμόςεξαιρετικά επισημοποιημένα και εκτενή έγγραφα. Έτσι, η άμεση αυστηρή τήρηση αυτών των προτύπων όχι μόνο οδηγεί σε μια προσέγγιση καταρράκτη, αλλά παρέχει επίσης μια πολύ υψηλό βαθμόεπισημοποίηση της ανάπτυξης.
Απαιτήσεις GOST
Το GOST 12207, σε αντίθεση με τα πρότυπα της 19ης και 34ης σειράς, περιγράφει την ανάπτυξη λογισμικού ως ένα σύνολο κύριων και βοηθητικών διαδικασιών που μπορούν να λειτουργήσουν από την αρχή έως το τέλος του έργου. Μοντέλο κύκλος ζωήςμπορούν να επιλεγούν με βάση τις ιδιαιτερότητες του έργου. Έτσι, αυτό το GOST δεν απαγορεύει ρητά τη χρήση μιας επαναληπτικής προσέγγισης, αλλά δεν συνιστά ρητά τη χρήση της. Το GOST 12207 είναι επίσης πιο ευέλικτο όσον αφορά τις απαιτήσεις για την τυπικότητα της διαδικασίας ανάπτυξης. Περιέχει μόνο ενδείξεις για την ανάγκη τεκμηρίωσης των κύριων αποτελεσμάτων όλων των διαδικασιών, αλλά δεν περιέχει λίστες απαιτούμενων εγγράφων και οδηγίες σχετικά με το περιεχόμενό τους.
Έτσι, το GOST 12207 επιτρέπει την επαναληπτική και λιγότερο επισημοποιημένη ανάπτυξη λογισμικού.
Μοντέλα ωριμότητας διαδικασίας ανάπτυξης (CMM, CMMI)
Εκτός από τα εθνικά και διεθνή πρότυπα, υπάρχουν διάφορες προσεγγίσεις για την πιστοποίηση της διαδικασίας ανάπτυξης. Τα πιο διάσημα από αυτά στη Ρωσία είναι, προφανώς, τα CMM και CMMI.
Το CMM (Capability Maturity Model) είναι ένα μοντέλο ωριμότητας διαδικασιών ανάπτυξης λογισμικού, το οποίο έχει σχεδιαστεί για να αξιολογεί το επίπεδο ωριμότητας της διαδικασίας ανάπτυξης σε μια συγκεκριμένη εταιρεία. Σύμφωνα με αυτό το μοντέλο, υπάρχουν πέντε επίπεδα ωριμότητας της διαδικασίας ανάπτυξης. Το πρώτο επίπεδο αντιστοιχεί στην ανάπτυξη «πώς πάει», όταν οι προγραμματιστές πηγαίνουν σε κάθε έργο ως κατόρθωμα. Το δεύτερο αντιστοιχεί σε λίγο πολύ καλά εδραιωμένες διαδικασίες, όταν είναι δυνατό με επαρκή εμπιστοσύνη να υπολογίζουμε σε ένα θετικό αποτέλεσμα του έργου. Το τρίτο αντιστοιχεί στην παρουσία αναπτυγμένων και καλά περιγραφόμενων διαδικασιών που χρησιμοποιούνται στην ανάπτυξη και το τέταρτο αντιστοιχεί στην ενεργή χρήση μετρήσεων στη διαδικασία διαχείρισης για τον καθορισμό στόχων και την παρακολούθηση της επίτευξής τους. Τέλος, το πέμπτο επίπεδο αναφέρεται στην ικανότητα της εταιρείας να βελτιστοποιεί τη διαδικασία όπως απαιτείται.
Απαιτήσεις CMM και CMMI
Μετά την εμφάνιση του CMM, άρχισαν να αναπτύσσονται εξειδικευμένα μοντέλα ωριμότητας για τη δημιουργία πληροφοριακά συστήματα, για τη διαδικασία επιλογής προμηθευτών και ορισμένων άλλων. Με βάση αυτά αναπτύχθηκε ένα ολοκληρωμένο μοντέλο CMMI (Capability Maturity Model Integration). Επιπλέον, έγινε μια προσπάθεια στο CMMI να ξεπεραστούν οι ελλείψεις του CMM που είχαν εμφανιστεί τότε - μια υπερβολή του ρόλου των επίσημων περιγραφών των διαδικασιών, όταν η παρουσία ορισμένων εγγράφων εκτιμήθηκε πολύ υψηλότερα από μια καθιερωμένη, αλλά δεν περιγράφεται διαδικασία. Ωστόσο, το CMMI επικεντρώνεται επίσης στη χρήση μιας εξαιρετικά επισημοποιημένης διαδικασίας.
Έτσι, η βάση των μοντέλων CMM και CMMI είναι η επισημοποίηση της διαδικασίας ανάπτυξης. Στοχεύουν στους προγραμματιστές στην εφαρμογή μιας διαδικασίας που περιγράφεται λεπτομερώς στους κανονισμούς και τις οδηγίες, η οποία, με τη σειρά της, δεν μπορεί παρά να απαιτεί την ανάπτυξη μεγάλου όγκου τεκμηρίωσης έργου για κατάλληλο έλεγχο και αναφορά.
Η σχέση του CMM και του CMMI με την επαναληπτική ανάπτυξη είναι πιο έμμεση. Επισήμως, κανένας από τους δύο δεν πρότεινε συγκεκριμένες απαιτήσεις για την τήρηση μιας προσέγγισης καταρράκτη ή επαναληπτικής προσέγγισης. Ωστόσο, σύμφωνα με ορισμένους ειδικούς, το CMM είναι πιο συμβατό με την προσέγγιση καταρράκτη, ενώ το CMMI επιτρέπει επίσης μια επαναληπτική προσέγγιση.
RUP
Φυσικά, το RUP είναι μια επαναληπτική μεθοδολογία. Αν και τυπικά η υποχρεωτική εκτέλεση όλων των φάσεων ή κάποιος ελάχιστος αριθμός επαναλήψεων δεν αναφέρεται πουθενά στο RUP, η όλη προσέγγιση επικεντρώνεται στο γεγονός ότι υπάρχουν πολλές από αυτές. Περιορισμένη ποσότηταΟι επαναλήψεις δεν σας επιτρέπουν να εκμεταλλευτείτε πλήρως το RUP. Ταυτόχρονα, το RUP μπορεί επίσης να χρησιμοποιηθεί σε σχεδόν διαδοχικά έργα, τα οποία στην πραγματικότητα περιλαμβάνουν μόνο μερικές επαναλήψεις: μία στη φάση Build και την άλλη στη φάση Μεταφοράς. Παρεμπιπτόντως, αυτός είναι ο αριθμός των επαναλήψεων που χρησιμοποιείται στην πραγματικότητα σε έργα καταρράκτη. Άλλωστε, η δοκιμή και η δοκιμαστική λειτουργία του συστήματος περιλαμβάνει διορθώσεις, οι οποίες μπορεί να περιλαμβάνουν ορισμένες ενέργειες που σχετίζονται με την ανάλυση, το σχεδιασμό και την ανάπτυξη, δηλαδή, στην πραγματικότητα, είναι ένα ακόμη πέρασμα από όλες τις φάσεις ανάπτυξης.
Μεθοδολογία RUP
Όσον αφορά την τυπικότητα της μεθοδολογίας, το RUP παρουσιάζει στον χρήστη ένα πολύ ευρύ φάσμα δυνατοτήτων. Εάν εκτελείτε όλες τις εργασίες και τις εργασίες, δημιουργήστε όλα τα τεχνουργήματα και επίσημα αρκετά (με έναν επίσημο κριτή, με την προετοιμασία μιας πλήρους κριτικής με τη μορφή ηλεκτρονικής ή έντυπο έγγραφοκ.λπ.) για τη διεξαγωγή όλων των αναθεωρήσεων, το RUP μπορεί να είναι μια πολύ επίσημη, επίπονη μεθοδολογία. Ταυτόχρονα, το RUP σάς επιτρέπει να αναπτύξετε μόνο εκείνα τα τεχνουργήματα και να εκτελέσετε μόνο εκείνα τα έργα και εργασίες που είναι απαραίτητες σε ένα συγκεκριμένο έργο. Και επιλεγμένα τεχνουργήματα μπορούν να εκτελεστούν και να αναθεωρηθούν με αυθαίρετο βαθμό επισημότητας. Είναι δυνατόν να απαιτείται λεπτομερής μελέτη και προσεκτική εκτέλεση κάθε εγγράφου, παροχή εξίσου προσεκτικά εκτελεσμένου και επισημοποιημένου ελέγχου, ακόμη και, σύμφωνα με την παλιά πρακτική, να εγκρίνεται κάθε τέτοια αναθεώρηση στο επιστημονικό και τεχνικό συμβούλιο της επιχείρησης. Ή μπορείτε να περιοριστείτε σε ένα email ή ένα σκίτσο σε χαρτί. Επιπλέον, υπάρχει πάντα μια ακόμη δυνατότητα: να σχηματίσετε ένα έγγραφο στο κεφάλι σας, δηλαδή να σκεφτείτε το σχετικό θέμα και να πάρετε μια εποικοδομητική απόφαση. Και αν αυτή η απόφαση αφορά μόνο εσάς, τότε περιοριστείτε, για παράδειγμα, σε ένα σχόλιο στον κώδικα του προγράμματος.
Έτσι, το RUP είναι μια επαναληπτική μεθοδολογία με πολύ ευρύ φάσμα ΠΙΘΑΝΕΣ ΛΥΣΕΙΣόσον αφορά την επισημοποίηση της αναπτυξιακής διαδικασίας.
Ας συνοψίσουμε το δεύτερο μέρος του άρθρου. Το RUP, σε αντίθεση με τις περισσότερες άλλες μεθοδολογίες, σας επιτρέπει να επιλέξετε τον βαθμό επισημοποίησης και επανάληψης της διαδικασίας ανάπτυξης σε ένα ευρύ φάσμα, ανάλογα με τα χαρακτηριστικά των έργων και του αναπτυσσόμενου οργανισμού.
Και γιατί αυτό είναι τόσο σημαντικό - θα το συζητήσουμε στο επόμενο μέρος.
1. Cascade (αγγλικός καταρράκτης) - πρότυπο μοντέλο ανάπτυξης
Μοντέλο ανάπτυξης Cascade - ένα μοντέλο στο οποίο όλα τα στάδια ανάπτυξης εκτελούνται διαδοχικά - το επόμενο στάδιο ξεκινά μετά την ολοκλήρωση του προηγούμενου.
Αυτό το μοντέλο περιλαμβάνει τα ακόλουθα βήματα στη διαδικασία ανάπτυξης λογισμικού:
Πρώτα από όλα, καθορίζεται τεχνικές προδιαγραφέςμελλοντικό πρόγραμμα, ως αποτέλεσμα, εγκρίνεται μια λίστα απαιτήσεων λογισμικού. Ακολουθεί η μετάβαση στο σχεδιασμό, κατά την οποία δημιουργείται τεκμηρίωση που περιγράφει για τους προγραμματιστές ένα σχέδιο και έναν τρόπο υλοποίησης των απαιτήσεων.
Αφού ολοκληρωθεί ο σχεδιασμός, οι προγραμματιστές υλοποιούν (κατασκευάζουν) το έργο. Στο στάδιο της υλοποίησης, όλα τα στοιχεία του έργου ενσωματώνονται. Μόνο μετά την πλήρη ολοκλήρωση αυτών των σταδίων γίνεται ο έλεγχος και ο εντοπισμός σφαλμάτων του τελικού προϊόντος. Επιπλέον, το προϊόν λογισμικού μπορεί να υλοποιηθεί και, μετά την εφαρμογή, να παρέχει υποστήριξη - να εισάγει νέες λειτουργίες και να εξαλείφει σφάλματα.
Τα κύρια πλεονεκτήματα της ανάπτυξης καταρράκτη:
2. Ευέλικτη μεθοδολογία ανάπτυξης λογισμικού
Μια σειρά από μεθοδολογίες ανάπτυξης λογισμικό, το οποίο προβλέπει την κοινή εργασία εκπροσώπων του πελάτη και προγραμματιστών. Η μέθοδος ευέλικτης ανάπτυξης βασίζεται σε μια επαναληπτική προσέγγιση, τη δυναμική διαμόρφωση των απαιτήσεων και την εφαρμογή τους σε σύντομα στάδια.
Το αποτέλεσμα κάθε τέτοιου σταδίου, συμπεριλαμβανομένου ενός κύκλου επαναλήψεων, είναι ένα μικροσκοπικό έργο λογισμικού,
Υπάρχουν αρκετές ευέλικτες μέθοδοι ανάπτυξης, οι πιο γνωστές είναι οι Scrum, Extreme Programming, DSDM.
Τα κύρια πλεονεκτήματα της ευέλικτης ανάπτυξης:
| ελαχιστοποίηση κινδύνου· σταδιακή αύξηση της λειτουργικότητας του προϊόντος λογισμικού. μια μικρή ποσότητα γραπτής τεκμηρίωσης· εκκίνηση της βασικής έκδοσης του προγράμματος το συντομότερο δυνατό. | |||
Υπάρχουν επίσης μειονεκτήματα: |
|||
| η αδυναμία ακριβούς προσδιορισμού του προϋπολογισμού του έργου. την αδυναμία προσδιορισμού του ακριβούς χρόνου ετοιμότητας του έργου· δεν είναι κατάλληλο για κρατικούς και δημοσιονομικούς οργανισμούς. απαιτεί κίνητρα από υπεύθυνους εκπροσώπους του πελάτη. | |||
Μανιφέστο ανάπτυξης λογισμικού AgileΑνακαλύπτουμε συνεχώς καλύτερους τρόπους ανάπτυξης λογισμικού αναπτύσσοντας άμεσα και βοηθώντας άλλους. Χάρη στη δουλειά που έγινε, καταφέραμε να συνειδητοποιήσουμε ότι: Άνθρωποι και αλληλεπίδρασηπιο σημαντικό από διαδικασίες και εργαλεία Προϊόν εργασίαςπιο σημαντικό από την πλήρη τεκμηρίωση Συνεργασία με τον πελάτηπιο σημαντικό από τη διαπραγμάτευση των όρων της σύμβασης Η ετοιμότητα για αλλαγή είναι πιο σημαντικήακολουθώντας το αρχικό σχέδιο Δηλαδή, χωρίς να αρνούμαστε τη σημασία αυτού που βρίσκεται στα δεξιά, εξακολουθούμε να εκτιμούμε περισσότερο αυτό που βρίσκεται στα αριστερά. |
Αρχές ευέλικτης ανάπτυξης:
|
Ικανοποίηση πελατών λόγω γρήγορης και αδιάλειπτης παράδοσης του απαραίτητου λογισμικού. |
Μοντέλα ανάπτυξης λογισμικού Waterfall Cascade model Spiral Ακραίος προγραμματισμόςΜεθοδολογία MSF Prototyping UI Incremental W-Model Testing Unified Software Development Process (USDP) MSF
Μοντέλο καταρράκτη Ανάλυση απαιτήσεων Γράψτε προδιαγραφές προϊόντος Σχεδιασμός Γράψτε αρχιτεκτονική προϊόντος Υλοποίηση Ανάπτυξη πηγαίου κώδικα Ενσωμάτωση ξεχωριστών τμημάτων πηγαίου κώδικα Δοκιμή και διόρθωση ελαττωμάτων
Extreme Programming Αρχικές Ανάλυση Απαιτήσεων Σχεδιασμός Ενσωμάτωση Δοκιμή Εφαρμογής Νέες Απαιτήσεις Αναθεώρηση/Έγκριση/Τροποποίηση Σχεδίου Ανάπτυξης Έκδοση προϊόντος
UI Prototyping Έκδοση προϊόντος Ανάπτυξη λογισμικού με αλλαγές Διευκρίνιση απαιτήσεων και προδιαγραφών Τροποποίηση πρωτοτύπου και βελτίωση ορισμένων λειτουργιών Βασική λειτουργικότητα Πρωτότυπο διεπαφής Προκαταρκτική προδιαγραφή
Επανάληψη σταδιακής ανάπτυξης 1 Επανάληψη 2 …. Ανάλυση Απαιτήσεων Σχεδιασμός Εφαρμογή Δοκιμή Στοιχείων Ενσωμάτωση Δοκιμή Ολόκληρης Ολόκληρης Επανάληψης Ν
Ενοποιημένη Διαδικασία Ανάπτυξης Λογισμικού (USDP) Ø Το μοντέλο περίπτωσης χρήσης, περιγράφει τις περιπτώσεις στις οποίες θα χρησιμοποιηθεί η εφαρμογή. Ø Το αναλυτικό μοντέλο περιγράφει τις βασικές κλάσεις για την εφαρμογή. Ø Το μοντέλο σχεδίασης περιγράφει τις συνδέσεις και τις σχέσεις μεταξύ κλάσεων και επιλεγμένων αντικειμένων Ø Το μοντέλο ανάπτυξης περιγράφει την κατανομή του λογισμικού στους υπολογιστές. Ø Το μοντέλο υλοποίησης περιγράφει εσωτερική οργάνωση κώδικα προγράμματος. Ø Το μοντέλο δοκιμής αποτελείται από εξαρτήματα δοκιμής, διαδικασίες δοκιμής και διαφορετικές περιπτώσεις δοκιμής
Συλλογή απαιτήσεων Ενοποιημένης Διαδικασίας Ανάπτυξης Λογισμικού (USDP) Iter 1…. Iter N Σχεδιασμός Iter 1…. Iter N Εφαρμογή του Iter 1…. Iter N Σχεδιασμός Iter 1…. Iter N Δοκιμή Iter 1…. Ίτερ Ν
Τυπικά στοιχεία αρχιτεκτονικής προϊόντος λογισμικού και τυπικές απαιτήσεις λογισμικού Ø Ø Ø Ø Οργάνωση προγράμματος Βασικές τάξεις συστήματος Οργάνωση δεδομένων Επιχειρηματικοί κανόνες Διεπαφή χρήστη Διαχείριση πόρων Ασφάλεια Απόδοση Επεκτασιμότητα Αλληλεπίδραση με άλλα συστήματα (ολοκλήρωση) Διεθνοποίηση, τοπική προσαρμογή Δεδομένα εισόδου-εξόδου Διαχείριση σφαλμάτων
Τυπική Αρχιτεκτονική Προϊόντος Λογισμικού Στοιχεία και Τυπικές Απαιτήσεις Λογισμικού Η ανοχή σε σφάλματα είναι ένα σύνολο ιδιοτήτων συστήματος που ενισχύουν την αξιοπιστία του συστήματος ανιχνεύοντας σφάλματα, ανακτώντας και απομονώνοντας κακές συνέπειες για το σύστημα. Κατά το σχεδιασμό οποιουδήποτε πραγματικού συστήματος για τη διασφάλιση της ανοχής σφαλμάτων, είναι απαραίτητο να προβλεφθούν όλες οι πιθανές καταστάσεις που μπορούν να οδηγήσουν σε αστοχία συστήματος και να αναπτυχθούν μηχανισμοί για την αντιμετώπιση αστοχιών. Η αξιοπιστία είναι η ικανότητα ενός συστήματος να αντέχει σε διάφορες αστοχίες και αστοχίες. Αποτυχία είναι η μετάβαση του συστήματος ως αποτέλεσμα σφάλματος σε κατάσταση εντελώς ακατάλληλη. Αστοχία είναι ένα σφάλμα στη λειτουργία του συστήματος που δεν οδηγεί σε αστοχία του συστήματος. Όσο λιγότερες αστοχίες και αστοχίες για ένα ορισμένο χρονικό διάστημα, τόσο πιο αξιόπιστο θεωρείται το σύστημα.
Τυπικά στοιχεία αρχιτεκτονικής προϊόντος λογισμικού και τυπικές απαιτήσεις λογισμικού Καμπύλη αξιοπιστίας N t 1 t Όσο πιο μακριά, τόσο πιο δύσκολο θα είναι να βρείτε ένα σφάλμα. Όσο πιο περίπλοκο είναι το σύστημα, τόσο μεγαλύτερη είναι η πιθανότητα αστοχιών και αστοχιών.
Τυπικά στοιχεία της αρχιτεκτονικής προϊόντων λογισμικού και τυπικές απαιτήσεις λογισμικού Ø Δυνατότητες υλοποίησης της ανεπτυγμένης αρχιτεκτονικής. Ø Υπερβολική λειτουργικότητα. Ø Λήψη απόφασης αγοράς έτοιμων εξαρτημάτων λογισμικού. Ø Αλλαγή στρατηγικής.
Μια λίστα ελέγχου ερωτήσεων που σας επιτρέπει να βγάλετε ένα συμπέρασμα σχετικά με την ποιότητα της αρχιτεκτονικής: Ø Περιγράφεται με σαφήνεια η συνολική οργάνωση του προγράμματος; Ø Ø Ø Εάν η προδιαγραφή περιλαμβάνει μια επισκόπηση της αρχιτεκτονικής και του σκεπτικού της. Είναι επαρκώς καθορισμένα τα κύρια στοιχεία του προγράμματος, οι τομείς ευθύνης τους και η αλληλεπίδρασή τους με άλλα στοιχεία. Εάν όλες οι λειτουργίες που καθορίζονται στην προδιαγραφή απαιτήσεων υλοποιούνται από έναν εύλογο αριθμό στοιχείων του συστήματος. Είναι οι πιο σημαντικές τάξεις που περιγράφονται και δικαιολογούνται. Εάν δίνεται περιγραφή της οργάνωσης της βάσης δεδομένων. Έχουν καθοριστεί όλοι οι επιχειρηματικοί κανόνες; Περιγράφεται ο αντίκτυπός τους στο σύστημα;
Μια λίστα ελέγχου ερωτήσεων που σας επιτρέπει να βγάλετε ένα συμπέρασμα σχετικά με την ποιότητα της αρχιτεκτονικής: Ø Περιγράφεται η στρατηγική σχεδιασμού της διεπαφής χρήστη. Ø Έγινε διεπαφή χρήστηαρθρωτό ώστε οι αλλαγές του να μην επηρεάζουν το υπόλοιπο σύστημα. ØΕάν δίνεται η περιγραφή της στρατηγικής εισαγωγής/εξόδου δεδομένων. Ø Εάν έχει πραγματοποιηθεί η ανάλυση απόδοσης του συστήματος που θα υλοποιηθεί χρησιμοποιώντας αυτήν την αρχιτεκτονική. Ø Εάν έχει πραγματοποιηθεί η ανάλυση αξιοπιστίας του σχεδιασμένου συστήματος. Ø Εάν έχει πραγματοποιηθεί η ανάλυση θεμάτων επεκτασιμότητας και επεκτασιμότητας του συστήματος.
Ανακατασκευή λογισμικού Η αναδιαμόρφωση περιλαμβάνει την προσαρμογή του λογισμικού σε ένα νέο σκεύη, εξαρτήματακαι σε νέα λειτουργικά συστήματα, νέα εργαλεία ανάπτυξης, νέες απαιτήσεις και αρχιτεκτονική και λειτουργικότητα λογισμικού. Αυτή είναι μια αλλαγή στην εσωτερική δομή του λογισμικού χωρίς να την αλλάξει. εξωτερική συμπεριφοράέχει σχεδιαστεί για να παρέχει τροποποίηση λογισμικού. Λόγοι για την ανακατασκευή: Ο κώδικας είναι επαναλαμβανόμενος. Η υλοποίηση της μεθόδου είναι πολύ μεγάλη. υπερβολική ένθεση βρόχων ή ο ίδιος ο βρόχος είναι πολύ μεγάλος. η κλάση έχει κακή συνδεσιμότητα (οι ιδιότητες και οι μέθοδοι της κλάσης πρέπει να περιγράφουν μόνο 1 αντικείμενο). μια διεπαφή κλάσης δεν σχηματίζει μια συνεπή αφαίρεση. η μέθοδος παίρνει πάρα πολλές παραμέτρους. Θα πρέπει να προσπαθήσετε να διατηρήσετε τον αριθμό των παραμέτρων σε ένα λογικό ελάχιστο. μεμονωμένα μέρη της τάξης αλλάζουν ανεξάρτητα από άλλα μέρη της τάξης.
Η ανακατασκευή λογισμικού κατά την αλλαγή του προγράμματος απαιτεί παράλληλη αλλαγή πολλών κλάσεων. Εάν προκύψει μια τέτοια κατάσταση, είναι απαραίτητο να αναδιοργανωθούν οι τάξεις προκειμένου να ελαχιστοποιηθούν οι θέσεις πιθανών αλλαγών στο μέλλον. πρέπει να αλλάξουν πολλές ιεραρχίες κληρονομικότητας παράλληλα. πρέπει να αλλάξετε πολλά μπλοκ υπόθεσης. Είναι απαραίτητο να τροποποιήσετε το πρόγραμμα με τέτοιο τρόπο ώστε να πραγματοποιηθεί η υλοποίηση του μπλοκ υπόθεσης και να ονομαστεί ο απαιτούμενος αριθμός φορών στο πρόγραμμα. Τα σχετικά μέλη δεδομένων που χρησιμοποιούνται μαζί δεν είναι οργανωμένα σε κλάσεις. Εάν χρησιμοποιείτε επανειλημμένα το ίδιο σύνολο στοιχείων δεδομένων, τότε είναι σκόπιμο να εξετάσετε το ενδεχόμενο να συνδυάσετε αυτά τα δεδομένα και να τοποθετήσετε τις λειτουργίες που εκτελούνται σε αυτά σε ξεχωριστή κλάση.
Μια μέθοδος ανακατασκευής λογισμικού χρησιμοποιεί περισσότερα στοιχεία μιας άλλης κλάσης από τη δική της. Αυτό σημαίνει ότι η μέθοδος πρέπει να μετακινηθεί σε άλλη κλάση και να κληθεί από την παλιά. ο βασικός τύπος δεδομένων είναι υπερφορτωμένος. Για να περιγράψετε την ουσία του πραγματικού κόσμου, είναι προτιμότερο να χρησιμοποιήσετε οποιαδήποτε τάξη παρά να υπερφορτώσετε οποιαδήποτε υπάρχον τύποδεδομένα; η τάξη έχει πολύ περιορισμένη λειτουργικότητα. Είναι καλύτερα να απαλλαγείτε από αυτήν την κατηγορία μεταφέροντας τη λειτουργικότητά της σε άλλη κατηγορία. Τα "αδέσποτα" δεδομένα διαβιβάζονται κατά μήκος της αλυσίδας των μεθόδων. Τα δεδομένα που διαβιβάζονται σε μια μέθοδο μόνο για να διαβιβαστούν σε άλλη μέθοδο ονομάζονται αδέσποτα δεδομένα. Όταν προκύπτουν τέτοιες καταστάσεις, προσπαθήστε να αλλάξετε την αρχιτεκτονική των κλάσεων και τις μεθόδους για να απαλλαγείτε από αυτές.
Η ανακατασκευή του αντικειμένου πολυμέσων δεν κάνει τίποτα. Εάν ο ρόλος μιας κλάσης είναι να ανακατευθύνει τις κλήσεις μεθόδων σε άλλες κλάσεις, τότε είναι καλύτερο να καταργήσετε αυτόν τον διακομιστή μεσολάβησης και να πραγματοποιήσετε κλήσεις απευθείας σε άλλες κλάσεις. μια τάξη γνωρίζει πάρα πολλά για μια άλλη τάξη. Σε αυτήν την περίπτωση, είναι απαραίτητο να γίνει η ενθυλάκωση πιο αυστηρή για να διασφαλιστεί ότι ο κληρονόμος έχει ελάχιστη γνώση του γονέα του. η μέθοδος έχει ένα ατυχές όνομα. τα μέλη δεδομένων είναι δημόσια. Αυτό θολώνει τη γραμμή μεταξύ διεπαφής και υλοποίησης, σπάει αναπόφευκτα την ενθυλάκωση και περιορίζει την ευελιξία του προγράμματος. δημοσιεύστε σχόλια σε πηγαίος κώδικας;
Μια υποκατηγορία ανακατασκευής λογισμικού χρησιμοποιεί μόνο ένα μικρό κλάσμα των μεθόδων των προγόνων της. Αυτή η κατάσταση παρουσιάζεται όταν μια νέα κλάση δημιουργείται μόνο για να κληρονομήσει μερικές μεθόδους από τη βασική κλάση και όχι για να περιγράψει κάποια νέα οντότητα. Για να αποφευχθεί αυτό, είναι απαραίτητο να μετασχηματιστεί η βασική κλάση με τέτοιο τρόπο ώστε να δίνει πρόσβαση στη νέα κλάση μόνο στις μεθόδους που χρειάζεται. ο κώδικας περιέχει καθολικές μεταβλητές. Μόνο οι μεταβλητές που χρησιμοποιούνται πραγματικά από ολόκληρο το πρόγραμμα θα πρέπει να είναι καθολικές. Όλες οι άλλες μεταβλητές πρέπει είτε να είναι τοπικές είτε να γίνουν ιδιότητες κάποιου αντικειμένου. το πρόγραμμα περιέχει κώδικα που μπορεί να χρειαστεί κάποια μέρα. Κατά την ανάπτυξη ενός συστήματος, είναι σκόπιμο να προβλεφθούν μέρη όπου ο πηγαίος κώδικας μπορεί να προστεθεί στο μέλλον.
Έτσι, η ουσία της δομικής προσέγγισης για την ανάπτυξη λογισμικού EIS έγκειται στην αποσύνθεσή του (διαμερισμός) σε αυτοματοποιημένες λειτουργίες: το σύστημα χωρίζεται σε λειτουργικά υποσυστήματα, τα οποία, με τη σειρά τους, χωρίζονται σε υποσυναρτήσεις, εκείνα σε εργασίες κ.λπ. μέχρι συγκεκριμένες διαδικασίες. Ταυτόχρονα, το σύστημα διατηρεί μια ολιστική άποψη στην οποία όλα τα συστατικά στοιχεία συνδέονται μεταξύ τους. Κατά την ανάπτυξη ενός συστήματος «από κάτω προς τα πάνω», από μεμονωμένες εργασίες σε ολόκληρο το σύστημα, χάνεται η ακεραιότητα, προκύπτουν προβλήματα κατά την περιγραφή της αλληλεπίδρασης πληροφοριών μεμονωμένων στοιχείων.
Όλες οι πιο κοινές μέθοδοι της δομικής προσέγγισης βασίζονται σε μια σειρά από γενικές αρχές:
1. Η αρχή του «διαίρει και βασίλευε».
2. Η αρχή της ιεραρχικής διάταξης - η αρχή της οργάνωσης των συστατικών μερών του συστήματος σε ιεραρχικές δεντροδομές με την προσθήκη νέων λεπτομερειών σε κάθε επίπεδο.
Επιλογή δύο βασικές αρχέςδεν σημαίνει ότι οι υπόλοιπες αρχές είναι δευτερεύουσες, γιατί Η παράβλεψη οποιουδήποτε από αυτά μπορεί να οδηγήσει σε απρόβλεπτες συνέπειες (συμπεριλαμβανομένης της αποτυχίας ολόκληρου του έργου»). Οι κύριες από αυτές τις αρχές είναι:
1. Η αρχή της αφαίρεσης - ανάδειξη των ουσιαστικών πτυχών του συστήματος και απόσπαση της προσοχής από τα μη ουσιώδη.
2. Η αρχή της συνέπειας, εγκυρότητας και συνέπειας των στοιχείων του συστήματος.
3. Αρχή δόμησης δεδομένα - δεδομέναπρέπει να είναι δομημένο και ιεραρχικά οργανωμένο.
Στη δομική προσέγγιση, υπάρχουν βασικά δύο ομάδες εργαλείων που περιγράφουν τη λειτουργική δομή του συστήματος και τις σχέσεις μεταξύ των δεδομένων. Κάθε ομάδα εργαλείων αντιστοιχεί σε συγκεκριμένους τύπους μοντέλων (διαγράμματα), τα πιο κοινά μεταξύ αυτών είναι:
· DFD (Διαγράμματα ροής δεδομένων) - διαγράμματα ροών δεδομένων.
SADT (Structured Analysis and Design Technique - μεθοδολογία δομικής ανάλυσης και σχεδίασης) - μοντέλα και αντίστοιχα λειτουργικά διαγράμματα: σημειώσεις IDEF0 (λειτουργική μοντελοποίηση συστημάτων), IDEF1x (εννοιολογική μοντελοποίηση βάσεων δεδομένων), IDEF3x (δομικά συστήματα για την αξιολόγηση της ποιότητας ενός αντικειμένου γραφική περιγραφή των διεργασιών ροής, της αλληλεπίδρασης των διεργασιών και των αντικειμένων που αλλάζουν από αυτές τις διεργασίες).
· ERD (Entity - Relationship Diagrams) - διαγράμματα «οντότητα-σχέσεις».
Σε όλες σχεδόν τις μεθόδους της δομικής προσέγγισης (δομική ανάλυση), χρησιμοποιούνται δύο ομάδες εργαλείων μοντελοποίησης στο στάδιο του σχηματισμού των απαιτήσεων λογισμικού:
1. Διαγράμματα που απεικονίζουν τις λειτουργίες που πρέπει να εκτελεί το σύστημα και τις σχέσεις μεταξύ αυτών των λειτουργιών - DFD ή SADT (IDEF0).
2. Διαγράμματα μοντελοποίησης δεδομένων και των σχέσεών τους (ERD).
Η συγκεκριμένη μορφή των διαγραμμάτων που παρατίθενται και η ερμηνεία των κατασκευών τους εξαρτώνται από το στάδιο του κύκλου ζωής του λογισμικού.
Στο στάδιο του σχηματισμού απαιτήσεων για λογισμικό, τα μοντέλα SADT και DFD χρησιμοποιούνται για την κατασκευή του μοντέλου «AS-IS» και του μοντέλου «TO-BE», αντικατοπτρίζοντας έτσι την υπάρχουσα και προτεινόμενη δομή των επιχειρηματικών διαδικασιών του οργανισμού και την αλληλεπίδραση μεταξύ (χρησιμοποιώντας μοντέλα SADT όπως συνήθως περιορίζονται μόνο σε αυτό το στάδιο, καθώς δεν προορίζονταν αρχικά για σχεδιασμό λογισμικού). Με τη βοήθεια του ERD πραγματοποιείται η περιγραφή των δεδομένων που χρησιμοποιούνται στον οργανισμό σε εννοιολογικό επίπεδο, ανεξάρτητα από τα μέσα υλοποίησης της βάσης δεδομένων (DBMS).
Σχόλιο: Μια ευέλικτη προσέγγιση στην ανάπτυξη λογισμικού, εξετάζονται οι βασικές αρχές της ευέλικτης ανάπτυξης. Παρέχεται ένας κατάλογος τεχνικών που, σε κάποιο βαθμό, ανταποκρίνονται στις αρχές της ευέλικτης ανάπτυξης λογισμικού. Αναλύονται οι βασικές αξίες και αρχές της ευέλικτης ανάπτυξης.
Μπορείτε να κατεβάσετε την παρουσίαση για αυτή τη διάλεξη.
Σκοπός της διάλεξης:
Αποκτήστε κατανόηση του σκοπού και των βασικών αρχών της ευέλικτης ανάπτυξης λογισμικού.
Εισαγωγή
Ευέλικτη μεθοδολογία ανάπτυξης λογισμικούεπικεντρώθηκε στη χρήση μιας επαναληπτικής προσέγγισης, στην οποία λογισμικόδημιουργείται σταδιακά, με μικρά βήματα, συμπεριλαμβανομένης της εφαρμογής ενός συγκεκριμένου συνόλου απαιτήσεων. Υποτίθεται ότι οι απαιτήσεις ενδέχεται να αλλάξουν. Οι ομάδες που χρησιμοποιούν ευέλικτες μεθοδολογίες σχηματίζονται από ευέλικτους προγραμματιστές που εκτελούν διάφορες εργασίες στη διαδικασία δημιουργίας ενός προϊόντος λογισμικού.
Όταν χρησιμοποιούνται ευέλικτες μεθοδολογίες, η ελαχιστοποίηση του κινδύνου πραγματοποιείται μειώνοντας την ανάπτυξη σε μια σειρά σύντομων κύκλων που ονομάζονται επαναλήψεις, διάρκειας 2-3 εβδομάδων. Η επανάληψη είναι ένα σύνολο εργασιών που έχουν προγραμματιστεί να εκτελεστούν σε συγκεκριμένη περίοδοςχρόνος. Σε κάθε επανάληψη, δημιουργείται μια λειτουργική έκδοση του συστήματος λογισμικού, στην οποία η μεγαλύτερη προτεραιότητα (για αυτήν την επανάληψη) απαιτήσεις πελατών. Κάθε επανάληψη εκτελεί όλες τις απαραίτητες εργασίες για τη δημιουργία λειτουργικού λογισμικού: σχεδιασμός, ανάλυση απαιτήσεων, σχεδιασμός, κωδικοποίηση, δοκιμή και τεκμηρίωση. Ενώ μια μεμονωμένη επανάληψη γενικά δεν είναι αρκετή για να κυκλοφορήσει νέα έκδοσηπροϊόν, εννοείται ότι το τρέχον λογισμικόέτοιμο για κυκλοφορία στο τέλος κάθε επανάληψης. Στο τέλος κάθε επανάληψης, η ομάδα ιεραρχεί εκ νέου τις απαιτήσεις για το προϊόν λογισμικού, κάνοντας ενδεχομένως προσαρμογές στην ανάπτυξη του συστήματος.
Αρχές και νόημα της ευέλικτης ανάπτυξης
Για τη μεθοδολογία ευέλικτης ανάπτυξης, δηλώνονται βασικά αξιώματα που επιτρέπουν στις ομάδες να επιτύχουν υψηλή απόδοση:
- οι άνθρωποι και η αλληλεπίδρασή τους·
- παράδοση λογισμικού εργασίας·
- συνεργασία με τον πελάτη·
- απάντηση στην αλλαγή.
Άνθρωποι και αλληλεπίδραση.Οι άνθρωποι είναι οι πιο σημαντικοί συστατικόεπιτυχία. Τα μεμονωμένα μέλη της ομάδας και η καλή επικοινωνία είναι απαραίτητα για ομάδες με υψηλές επιδόσεις. Για να διευκολυνθεί η επικοινωνία, οι ευέλικτες πρακτικές περιλαμβάνουν συχνές συζητήσεις για τα αποτελέσματα της εργασίας και αλλαγές στις αποφάσεις. Συζητήσεις μπορούν να γίνονται καθημερινά για λίγα λεπτά και στο τέλος κάθε επανάληψης με ανάλυση των αποτελεσμάτων της εργασίας και αναδρομή. Για αποτελεσματική επικοινωνία κατά τη διάρκεια των συναντήσεων, τα μέλη της ομάδας πρέπει να τηρούν τα ακόλουθα βασικούς κανόνεςσυμπεριφορές:
- σεβασμός στη γνώμη κάθε μέλους της ομάδας·
- Να είστε ειλικρινείς σε οποιαδήποτε επικοινωνία.
- διαφάνεια όλων των δεδομένων, ενεργειών και αποφάσεων·
- σιγουριά ότι κάθε συμμετέχων θα υποστηρίξει την ομάδα·
- αφοσίωση στην ομάδα και τους στόχους της.
Εκτός από μια αποτελεσματική ομάδα και την καλή επικοινωνία, χρειάζονται τέλεια εργαλεία λογισμικού για τη δημιουργία ομάδων υψηλής απόδοσης σε ευέλικτες μεθοδολογίες.
Το λογισμικό εργασίας είναι πιο σημαντικό από την ολοκληρωμένη τεκμηρίωση.Όλες οι ευέλικτες μεθοδολογίες υπογραμμίζουν την ανάγκη παράδοσης μικρών κομματιών λειτουργικού λογισμικού στον πελάτη σε προκαθορισμένα χρονικά διαστήματα. Λογισμικό, κατά κανόνα, πρέπει να περάσει το επίπεδο δοκιμής μονάδας, δοκιμών σε επίπεδο συστήματος. Ο όγκος των εγγράφων θα πρέπει να περιορίζεται στο ελάχιστο. Κατά τη διαδικασία σχεδιασμού, η ομάδα θα πρέπει να διατηρεί ενημερωμένο ένα σύντομο έγγραφο που περιέχει το σκεπτικό της απόφασης και μια περιγραφή της δομής.
Η συνεργασία με τον πελάτη είναι πιο σημαντική από τις επίσημες συμφωνίες βάσει της σύμβασης.Για την επιτυχή ολοκλήρωση του έργου είναι απαραίτητη η τακτική και συχνή επικοινωνία με τον πελάτη. Ο πελάτης πρέπει να συμμετέχει τακτικά στη συζήτηση των αποφάσεων που λαμβάνονται για το λογισμικό, να εκφράζει τις επιθυμίες και τα σχόλιά του. Η συμμετοχή του πελάτη στη διαδικασία ανάπτυξης λογισμικού είναι απαραίτητη για τη δημιουργία ενός ποιοτικού προϊόντος.
Το να ανταποκρίνεστε γρήγορα στην αλλαγή είναι πιο σημαντικό από το να ακολουθείτε ένα σχέδιο.Η ικανότητα ανταπόκρισης στην αλλαγή καθορίζει σε μεγάλο βαθμό την επιτυχία ενός έργου λογισμικού. Κατά τη διαδικασία δημιουργίας ενός προϊόντος λογισμικού, συχνά αλλάζουν απαιτήσεις πελατών. Οι πελάτες συχνά δεν ξέρουν ακριβώς τι θέλουν μέχρι να το δουν να λειτουργεί. λογισμικό. Οι ευέλικτες μεθοδολογίες αναζητούν σχόλια από πελάτες στη διαδικασία δημιουργίας ενός προϊόντος λογισμικού. Η ανταπόκριση στην αλλαγή είναι απαραίτητη για τη δημιουργία ενός προϊόντος που προσφέρει ικανοποίηση πελατών και επιχειρηματική αξία.
Οι αρχές της ευέλικτης ανάπτυξης υποστηρίζονται από 12 αρχές. Οι ευέλικτες μεθοδολογίες ορίζουν διαδικασίες και κανόνες που συμμορφώνονται λίγο πολύ με αυτές τις αρχές. Οι ευέλικτες μεθοδολογίες για τη δημιουργία προϊόντων λογισμικού βασίζονται στις ακόλουθες αρχές:
- Η ύψιστη προτεραιότητα είναι η ικανοποίηση των επιθυμιών του πελάτη μέσω της παράδοσης χρήσιμου λογισμικού σε σύντομο χρονικό διάστημα με την επακόλουθη συνεχής ενημέρωση. Οι ευέλικτες πρακτικές περιλαμβάνουν γρήγορη αρχική έκδοση και συχνές ενημερώσεις. Ο στόχος της ομάδας είναι να παραδώσει μια λειτουργική έκδοση μέσα σε λίγες εβδομάδες από την έναρξη του έργου. Περαιτέρω συστήματα λογισμικούμε σταδιακή επέκταση της λειτουργικότητας θα πρέπει να αποστέλλεται κάθε λίγες εβδομάδες. Ο πελάτης μπορεί να ξεκινήσει εμπορική λειτουργίασύστημα, αν το θεωρεί αρκετά λειτουργικό. Επίσης, ο πελάτης μπορεί απλά να διαβάσει τρέχουσα έκδοσηλογισμικό, παρέχετε τα σχόλιά σας με σχόλια.
- Μην αγνοείτε τις μεταβαλλόμενες απαιτήσεις, ακόμη και αργά στην ανάπτυξη. Οι ευέλικτες διαδικασίες επιτρέπουν την προσαρμογή των αλλαγών για τη διασφάλιση ανταγωνιστικό πλεονέκτημαπελάτης. Οι ομάδες που χρησιμοποιούν ευέλικτες μεθοδολογίες προσπαθούν να κάνουν τη δομή του προγράμματος υψηλής ποιότητας, με ελάχιστο αντίκτυπο των αλλαγών στο σύστημα ως σύνολο.
- Παραδίδετε νέες εκδόσεις του λογισμικού συχνά, σε διαστήματα από μία εβδομάδα έως δύο μήνες, με προτίμηση για μικρότερες προθεσμίες. Ταυτόχρονα, στόχος είναι η παράδοση ενός προγράμματος που να καλύπτει τις ανάγκες του χρήστη, με ελάχιστη συνοδευτική τεκμηρίωση.
- Οι πελάτες και οι προγραμματιστές πρέπει να συνεργάζονται καθ' όλη τη διάρκεια του έργου. Πιστεύεται ότι για ένα επιτυχημένο έργο, οι πελάτες, οι προγραμματιστές και όλοι οι ενδιαφερόμενοι πρέπει να επικοινωνούν συχνά και με πολλούς τρόπους για να βελτιώσουν σκόπιμα το προϊόν λογισμικού.
- Τα έργα πρέπει να υλοποιούνται από άτομα με κίνητρα. Δώστε στην ομάδα του έργου ένα υγιές εργασιακό περιβάλλον, παρέχετε την υποστήριξη που χρειάζονται και εμπιστευτείτε ότι τα μέλη της ομάδας θα ολοκληρώσουν τη δουλειά.
- Η πιο αποτελεσματική και παραγωγική μέθοδος μετάδοσης πληροφοριών στην ομάδα ανάπτυξης και ανταλλαγής απόψεων μέσα σε αυτήν είναι μια συνομιλία πρόσωπο με πρόσωπο. Στα ευέλικτα έργα, ο κύριος τρόπος επικοινωνίας είναι η απλή ανθρώπινη αλληλεπίδραση. Τα γραπτά έγγραφα δημιουργούνται και ενημερώνονται σταδιακά καθώς αναπτύσσεται το λογισμικό και μόνο όταν είναι απαραίτητο.
- Ένα πρόγραμμα εργασίας είναι ο κύριος δείκτης προόδου του έργου. Η προσέγγιση ενός ευέλικτου έργου προς την ολοκλήρωση κρίνεται από το πόσα είναι διαθέσιμα αυτή τη στιγμήτο πρόγραμμα ανταποκρίνεται στις απαιτήσεις του πελάτη.
- Οι ευέλικτες διαδικασίες ενθαρρύνουν τη μακροπρόθεσμη ανάπτυξη. Οι πελάτες, οι προγραμματιστές και οι χρήστες πρέπει να μπορούν να διατηρούν σταθερό ρυθμό επ' αόριστον.
- Η αδιάκοπη εστίαση στην αριστεία μηχανικής και στον ποιοτικό σχεδιασμό ενισχύει τις αποδόσεις των ευέλικτων τεχνολογιών. Τα μέλη της ευέλικτης ομάδας προσπαθούν να δημιουργήσουν ποιοτικό κώδικα με τακτική ανακατασκευή.
- Η απλότητα είναι η τέχνη του να πετυχαίνεις περισσότερα κάνοντας λιγότερα. Τα μέλη της ομάδας επιλύουν τις τρέχουσες εργασίες όσο το δυνατόν πιο απλά και αποτελεσματικά. Εάν παρουσιαστεί κάποιο πρόβλημα στο μέλλον, τότε είναι δυνατή η πραγματοποίηση αλλαγών στον κωδικό ποιότητας χωρίς μεγάλο κόστος.
- Οι καλύτερες αρχιτεκτονικές, απαιτήσεις και σχέδια προέρχονται από αυτοοργανωτικές ομάδες. Στις ευέλικτες ομάδες, τα καθήκοντα δεν ανατίθενται σε μεμονωμένα μέλη, αλλά στην ομάδα ως σύνολο. Η ίδια η ομάδα αποφασίζει πώς θα εφαρμόσει καλύτερα τις απαιτήσεις του πελάτη. Τα μέλη της ομάδας εργάζονται συλλογικά σε όλες τις πτυχές του έργου. Κάθε συμμετέχων επιτρέπεται να συνεισφέρει στον κοινό σκοπό. Κανένα μέλος της ομάδας δεν είναι αποκλειστικά υπεύθυνο για την αρχιτεκτονική, τις απαιτήσεις ή τις δοκιμές.
- Η ομάδα θα πρέπει να σκέφτεται τακτικά πώς να γίνει ακόμα πιο αποτελεσματική και στη συνέχεια να προσαρμόζει και να προσαρμόζει ανάλογα τη συμπεριφορά της. Μια ευέλικτη ομάδα προσαρμόζει συνεχώς την οργάνωση, τους κανόνες, τις συμφωνίες και τις σχέσεις της.
Οι παραπάνω αρχές, ως ένα βαθμό, αντιστοιχούν σε μια σειρά από μεθοδολογίες ανάπτυξης λογισμικού:
| Agile Modeling | ένα σύνολο εννοιών, αρχών και τεχνικών (πρακτικών) που σας επιτρέπουν να εκτελείτε γρήγορα και εύκολα μοντελοποίηση και τεκμηρίωση σε έργα ανάπτυξης λογισμικού. |
| Agile Unified Process (AUP) | μια απλοποιημένη έκδοση του IBM RationalUnifiedProcess (RUP), η οποία περιγράφει μια απλή και κατανοητή προσέγγιση (μοντέλο) για τη δημιουργία λογισμικού για επιχειρηματικές εφαρμογές. |
| Ανοίγω | είναι μια επαναληπτική-αυξητική μέθοδος ανάπτυξης λογισμικού. Τοποθετείται ως μια ελαφριά και ευέλικτη επιλογή RUP. |
| AgileDataMethod | μια ομάδα επαναληπτικών μεθόδων ανάπτυξης λογισμικού στις οποίες οι απαιτήσεις και οι λύσεις επιτυγχάνονται μέσω της συνεργασίας διαφορετικών διαλειτουργικών ομάδων· |
| DSDM | μια μεθοδολογία για την ανάπτυξη δυναμικών συστημάτων που βασίζεται στην έννοια της ταχείας ανάπτυξης εφαρμογών (RapidApplicationDevelopment, RAD). Αντιπροσωπεύει μια επαναληπτική και σταδιακή προσέγγιση που δίνει έμφαση στη συνεχή συμμετοχή των χρηστών/καταναλωτών στη διαδικασία. |
| Ακραίος προγραμματισμός (XP) | ακραίος προγραμματισμός? |
| Προσαρμοστική ανάπτυξη λογισμικού (ADD) | προσαρμοστική ανάπτυξη λογισμικού? |
| Ανάπτυξη με γνώμονα τα χαρακτηριστικά (FDD) | ανάπτυξη εστιασμένη στη σταδιακή προσθήκη λειτουργικότητας. |
| Να πάρει το πραγματικό | μια επαναληπτική προσέγγιση χωρίς λειτουργικές προδιαγραφές που χρησιμοποιείται για διαδικτυακές εφαρμογές. |
| MSFfogAgileSoftwareDevelopment | Ευέλικτη μεθοδολογία ανάπτυξης λογισμικού από τη Microsoft. |
| Scrum | θεσπίζει κανόνες για τη διαχείριση της διαδικασίας ανάπτυξης και σας επιτρέπει να χρησιμοποιείτε υπάρχουσες πρακτικές κωδικοποίησης προσαρμόζοντας τις απαιτήσεις ή κάνοντας αλλαγές τακτικής [ |