Γενικές αρχές και προσεγγίσεις για την ανάπτυξη λογισμικού. Τεχνολογίες ευέλικτης ανάπτυξης σχετικά με τις αρχές και τη σημασία της ευέλικτης ανάπτυξης

Μοντέλα Ανάπτυξης Λογισμικού 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 αντικείμενο). μια διεπαφή κλάσης δεν σχηματίζει μια συνεπή αφαίρεση. Η μέθοδος παίρνει πάρα πολλές παραμέτρους. Είναι απαραίτητο να προσπαθήσετε να διατηρήσετε τον αριθμό των παραμέτρων σχετικά ελάχιστο. μεμονωμένα μέρη της τάξης αλλάζουν ανεξάρτητα από άλλα μέρη της τάξης.

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

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

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

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

Υπάρχουν μοντέλα ανάπτυξης λογισμικού. Και υπάρχουν μεθοδολογίες. Υπάρχουν πολλές αντικρουόμενες πληροφορίες στο Διαδίκτυο σχετικά με το τι είναι και πώς να τα διακρίνουμε. Μπορεί να είναι δύσκολο για έναν αρχάριο ειδικό να το καταλάβει αυτό. Σε αυτό το άρθρο θα σημαδέψουμε όλα τα i.

Στάδια κύκλου ζωής λογισμικού

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

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

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

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

Δημιουργία.Ο Ιβάν συνήψε συμφωνία με τους προγραμματιστές. Άρχισαν να γράφουν κώδικα, να σχεδιάζουν σχέδια και να συντάσσουν τεκμηρίωση.

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

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

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

Βασικά μοντέλα ανάπτυξης λογισμικού

• Κώδικας και επιδιόρθωση - ένα μοντέλο κωδικοποίησης και εξάλειψης σφαλμάτων.
• Μοντέλο Καταρράκτη - μοντέλο καταρράκτη ή "καταρράκτης".
• V-model - μοντέλο σε σχήμα V, ανάπτυξη βάσει δοκιμής.
• Αυξητικό μοντέλο - αυξητικό μοντέλο;
• Επαναληπτικό μοντέλο - επαναληπτικό (ή επαναληπτικό) μοντέλο.
• Spiral Model - σπειροειδές μοντέλο;
• Μοντέλο χάους - μοντέλο χάους;
• Prototype Model - πρωτότυπο μοντέλο.

Από αυτά τα μοντέλα, τα πέντε κύρια είναι τα πιο δημοφιλή: καταρράκτη, σε σχήμα V, σταδιακά, επαναληπτικά και σπειροειδή. Ας τα δούμε πιο αναλυτικά.

Καταρράκτης (μοντέλο καταρράκτη ή «καταρράκτης»)

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

Τα πλεονεκτήματα ενός "καταρράκτη"

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

Μειονεκτήματα του μοντέλου καταρράκτη

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

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

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

V-model (ανάπτυξη βάσει δοκιμής)

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

Πλεονεκτήματα του μοντέλου σε σχήμα V

Ο αριθμός των σφαλμάτων στην αρχιτεκτονική λογισμικού μειώνεται στο ελάχιστο.

Μειονεκτήματα του μοντέλου σε σχήμα V

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

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

Αυξητικό μοντέλο

Αυτό το μοντέλο ανάπτυξης σε μέρη (increment in translation from English - increment) έχει τις ρίζες του στη δεκαετία του 1930. Ας το δούμε χρησιμοποιώντας το παράδειγμα της δημιουργίας ενός κοινωνικού δικτύου.

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

Οφέλη του αυξητικού μοντέλου

• Δεν χρειάζεται να επενδύσετε πολλά χρήματα στο αρχικό στάδιο.Ο πελάτης πληρώνει για τη δημιουργία βασικών λειτουργιών, παραλαμβάνει το προϊόν, το «κυκλοφορεί» στην αγορά - και με βάση τα σχόλια, αποφασίζει αν θα συνεχίσει την ανάπτυξη.
• Μπορείτε να λαμβάνετε γρήγορα σχόλια από τους χρήστες και να ενημερώνετε αμέσως τις τεχνικές προδιαγραφές.Αυτό μειώνει τον κίνδυνο δημιουργίας ενός προϊόντος που κανείς δεν χρειάζεται.
• Ένα λάθος είναι φθηνότερο.Εάν έγινε κάποιο λάθος κατά την ανάπτυξη της αρχιτεκτονικής, τότε η επισκευή του δεν θα κοστίσει τόσο όσο στο μοντέλο "καταρράκτη" ή σε σχήμα V.

Μειονεκτήματα του αυξητικού μοντέλου

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

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

Επαναληπτικό μοντέλο

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

Ας δούμε το παράδειγμα της δημιουργίας ενός messenger για να δούμε πώς λειτουργεί αυτό το μοντέλο.

1. Ο πελάτης αποφάσισε ότι ήθελε να δημιουργήσει έναν αγγελιοφόρο. Οι προγραμματιστές έχουν δημιουργήσει μια εφαρμογή όπου μπορείτε να προσθέσετε έναν φίλο και να ξεκινήσετε μια συνομιλία για δύο.
2. Το messenger "κυκλοφόρησε" στο κατάστημα εφαρμογών, οι χρήστες άρχισαν να το κατεβάζουν και να το χρησιμοποιούν ενεργά. Ο πελάτης συνειδητοποίησε ότι το προϊόν ήταν δημοφιλές και αποφάσισε να το βελτιώσει.
3. Οι προγραμματιστές πρόσθεσαν τη δυνατότητα παρακολούθησης βίντεο, αποστολής φωτογραφιών και εγγραφής ηχητικών μηνυμάτων στο messenger. Βελτιώνουν σταδιακά τη λειτουργικότητα της εφαρμογής και την προσαρμόζουν στις απαιτήσεις της αγοράς.

Οφέλη του Επαναληπτικού Μοντέλου

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

Μειονεκτήματα του επαναληπτικού μοντέλου

• Αρχική χρήση βάσεων δεδομένων ή διακομιστών- τα πρώτα είναι δύσκολο να κλιμακωθούν και τα δεύτερα δεν αντέχουν το φορτίο. Ίσως χρειαστεί να ξαναγράψετε το μεγαλύτερο μέρος της εφαρμογής.
• Χωρίς σταθερό προϋπολογισμό ή προθεσμίες.Ο πελάτης δεν γνωρίζει πώς φαίνεται ο τελικός στόχος ή πότε θα τελειώσει η ανάπτυξη.

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

Spiral μοντέλο

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

Ας δούμε πώς λειτουργεί αυτό το μοντέλο, χρησιμοποιώντας το παράδειγμα της ανάπτυξης ενός συστήματος Smart Home.

1. Ο πελάτης αποφάσισε ότι ήθελε να φτιάξει ένα τέτοιο σύστημα και διέταξε τους προγραμματιστές να εφαρμόσουν τον έλεγχο του βραστήρα από το τηλέφωνο. Άρχισαν να ενεργούν σύμφωνα με το μοντέλο του «καταρράκτη»: άκουσαν την ιδέα, ανέλυσαν προσφορές στην αγορά, συζήτησαν την αρχιτεκτονική του συστήματος με τον πελάτη, αποφάσισαν πώς θα το εφαρμόσουν, ανέπτυξαν, δοκίμασαν και «κυκλοφόρησαν» τελικό προϊόν.
2. Ο πελάτης αξιολόγησε το αποτέλεσμα και τους κινδύνους: πόσο χρειάζονται οι χρήστες την επόμενη έκδοση του προϊόντος - αυτή τη φορά με έλεγχο τηλεόρασης. Υπολογίστηκε το χρονικό πλαίσιο, ο προϋπολογισμός και διέταξε την ανάπτυξη. Οι προγραμματιστές ενήργησαν σύμφωνα με το μοντέλο καταρράκτη και παρουσίασαν στον πελάτη ένα πιο σύνθετο προϊόν που αναπτύχθηκε με βάση το πρώτο.
3. Ο πελάτης σκέφτηκε ότι ήρθε η ώρα να δημιουργήσει λειτουργικότητα για τον έλεγχο του ψυγείου από το τηλέφωνο. Αλλά, αναλύοντας τους κινδύνους, συνειδητοποίησα ότι είναι δύσκολο να ενσωματωθεί μια μονάδα Wi-Fi σε ένα ψυγείο και οι κατασκευαστές δεν ενδιαφέρονται για συνεργασία σε αυτό το θέμα. Επομένως, οι κίνδυνοι υπερτερούν των πιθανών οφελών. Με βάση τα δεδομένα που έλαβε, ο πελάτης αποφάσισε να σταματήσει την ανάπτυξη και να βελτιώσει την υπάρχουσα λειτουργικότητα, προκειμένου να κατανοήσει με την πάροδο του χρόνου πώς να αναπτύξει το σύστημα Smart Home.

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

Πλεονεκτήματα του σπειροειδούς μοντέλου

Δίνεται μεγάλη προσοχή στην αντιμετώπιση των κινδύνων.

Μειονεκτήματα του σπειροειδούς μοντέλου

• Υπάρχει κίνδυνος να κολλήσετε στο αρχικό στάδιο- Βελτιώστε ατελείωτα την πρώτη έκδοση του προϊόντος και μην προχωρήσετε στις επόμενες.
• Η ανάπτυξη διαρκεί πολύ και είναι ακριβή.

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

Τι είναι το Agile;

Το Agile ("ευκίνητο") μεταφράζεται από τα αγγλικά ως "ευέλικτο". Περιλαμβάνει πρακτικές, προσεγγίσεις και μεθοδολογίες που βοηθούν στη δημιουργία ενός προϊόντος πιο αποτελεσματικά:

• ακραίος προγραμματισμός (Extreme Programming, XP);
• λιτή ανάπτυξη λογισμικού (Lean);
• Πλαίσιο διαχείρισης έργου Scrum;
• ανάπτυξη με γνώμονα τα χαρακτηριστικά (FDD);
• ανάπτυξη βάσει δοκιμής (TDD);
• Μεθοδολογία «καθαρού δωματίου» (Cleanroom Software Engineering).
• επαναληπτική-αυξητική μέθοδος ανάπτυξης (OpenUP);
• Μεθοδολογία ανάπτυξης του Microsoft Solutions Framework (MSF).
• μέθοδος ανάπτυξης δυναμικών συστημάτων (DSDM);
• Μέθοδος διαχείρισης ανάπτυξης Kanban.

Συνοψίσαμε τις διαφορές μεταξύ του Agile και της παραδοσιακής προσέγγισης ανάπτυξης στον πίνακα:

Δεν είναι όλα όσα αναφέρονται ως μεθοδολογία. Για παράδειγμα, το Scrum συχνά ονομάζεται όχι μεθοδολογία, αλλά πλαίσιο. Ποια είναι η διαφορά; Ένα πλαίσιο είναι μια πιο διαμορφωμένη μεθοδολογία με αυστηρούς κανόνες. Στο Scrum, όλοι οι ρόλοι και οι διαδικασίες είναι σαφώς καθορισμένοι. Εκτός από το Scrum, το Kanban χρησιμοποιείται συχνά.

Kanban

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

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

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

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

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

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

την αρχή του «διαίρει και βασίλευε» (βλ. υποενότητα 2.1.1).

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

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

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

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

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

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

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

SADT (Structured Analysis and Design Technique - μέθοδος δομικής ανάλυσης και σχεδιασμού) - μοντέλα και αντίστοιχα λειτουργικά διαγράμματα.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.Κωδικοποίηση

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

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

Κατά την κωδικοποίηση, πρέπει να ακολουθήσετε το πρότυπο για την επιλεγμένη γλώσσα, για παράδειγμα, για τη γλώσσα C είναι ANSI C και για C++ είναι το ISO/IEC 14882 "Standard for the C++ ProgrammingLanguage".

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

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

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

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

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

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

2.Πλήρης κάλυψη κωδικού. Ο προγραμματιστής μπορεί πάντα να προσδιορίσει ποια τμήματα κώδικα λειτουργούν σε κάθε δοκιμή. Βλέπει ποιοι άλλοι κλάδοι του κώδικα παραμένουν μη δοκιμασμένοι και μπορεί να επιλέξει τις συνθήκες υπό τις οποίες θα δοκιμαστούν. Παρακάτω περιγράφουμε τον τρόπο παρακολούθησης του βαθμού κάλυψης κώδικα των δοκιμών που πραγματοποιήθηκαν.

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

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

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

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

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

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

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

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

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

3. Ανάπτυξη συστήματος βοήθειας για το προϊόν λογισμικού. Δημιουργία τεκμηρίωσης χρήστη

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

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

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

Ένα καλά τεκμηριωμένο PP έχει τα ακόλουθα πλεονεκτήματα.

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

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

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

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