Μενού

Μελέτη περίπτωσης: Πώς να εξαλείψετε τις ατέλειες των καταρρακτών και των ευέλικτων διαδικασιών ανάπτυξης χρησιμοποιώντας ένα υβριδικό μοντέλο

  • Κύριος
  • Ευέλικτη Δοκιμή
  • Μελέτη περίπτωσης: Πώς να εξαλείψετε τις ατέλειες των καταρρακτών και των ευέλικτων διαδικασιών ανάπτυξης χρησιμοποιώντας ένα υβριδικό μοντέλο

case study how eliminate flaws waterfall

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Ευκίνητο υβριδικό μοντέλο καταρράκτη

Το Waterfall Model ήταν η ιδανική επιλογή για ανάπτυξη λογισμικού. Σε αυτό το μοντέλο, μια ιδέα γίνεται χρησιμοποιήσιμο λογισμικό σε μια διαδοχική διαδικασία που διαπερνά τα στάδια της Έναρξης, Ανάλυσης, Εφαρμογής, Δοκιμών και Συντήρησης.

Αλλά το μοντέλο Waterfall έχει κάποια μειονεκτήματα.

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

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

Ευκίνητο υβριδικό μοντέλο καταρράκτη

Έτσι, μια νέα μεθοδολογία έχει εξελιχθεί, η οποία μπορεί να ονομαστεί «Hybrid», για να εξασφαλιστεί ένα ισχυρό τελικό προϊόν επιλέγοντας τα πλεονεκτήματα τόσο των μοντέλων Agile όσο και Waterfall.

Ας μάθουμε πρώτα για τα μοντέλα ανάπτυξης Waterfall και Agile και μετά προχωρήσουμε στο 'Agile Waterfall Hybrid Model' με πλεονεκτήματα και μειονεκτήματα του καθενός.

Τι θα μάθετε:

Μοντέλο καταρράκτη

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

Στο μοντέλο καταρράκτη, οι φάσεις δεν αλληλεπικαλύπτονται.

=> Διαβάστε περισσότερα για το Waterfall Model εδώ.

Το σχήμα 1 δείχνει το μοντέλο καταρράκτη:

Μοντέλο καταρράκτη

Πλεονεκτήματα του μοντέλου καταρράκτη:

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

Μειονεκτήματα του μοντέλου Waterfall:

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

Ευκίνητο μοντέλο

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

Το μοντέλο έχει τις δικές του αρχές που τείνουν να φέρνουν τις διαδικασίες στο πίσω κάθισμα.

=> Διαβάστε περισσότερα άρθρα σχετικά με τη μεθοδολογία Agile εδώ.

(Κάντε κλικ στην εικόνα για προβολή μεγεθυμένη)

Ευκίνητο μοντέλο

Πλεονεκτήματα του μοντέλου Agile:

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

Μειονεκτήματα του ευέλικτου μοντέλου:

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

Συνεργατικό (Υβριδικό) Μοντέλο

Το Collaborative Model στοχεύει να συνδυάσει και τα δύο μοντέλα - Waterfall και Agile. Η αξιοποίηση της προσέγγισης Waterfall και Agile διασφαλίζει την επιτυχία του έργου. Αφαιρεί τα μειονεκτήματα και των δύο μοντέλων. ενώ ταυτόχρονα συνδυάζει τα πλεονεκτήματα και των δύο.

Το Συνεργατικό Μοντέλο μπορεί να εφαρμοστεί σε ένα έργο εκτελώντας:

πώς να ανοίξετε το αρχείο .bin στα παράθυρα

Συνεργατικό (Υβριδικό) Μοντέλο

Έτσι το μοντέλο συνεργασίας μπορεί να αναπαρασταθεί διαγραμματικά όπως παρακάτω:

Συνεργατικό (Υβριδικό) Μοντέλο 2

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

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

Agile Waterfall Hybrid Model - Μάθετε με το παράδειγμα -Μελέτη περίπτωσης

Η εταιρεία λογισμικού «ABC Software Service» παρέχει υπηρεσίες σε έναν πελάτη, ένα Πανεπιστήμιο με το όνομα «Πανεπιστήμιο XYZ» για την ανάπτυξη, τη δοκιμή και τη συντήρηση του λογισμικού τους (ζωντανή υποστήριξη παραγωγής).

Τα κύρια χαρακτηριστικά του λογαριασμού είναι:

  1. Οι υπηρεσίες λογισμικού ABC πρέπει να αναβαθμίσουν τις εφαρμογές του XYZ University. Η βάση δεδομένων πρέπει να αναβαθμιστεί και όλες οι εφαρμογές πρέπει να αναπτυχθούν εκ νέου στην τελευταία τεχνολογία που διατίθεται στην αγορά.
  2. Μέχρι τώρα, όλα τα έργα που χειρίστηκε η ABC Software είχαν εκτελεστεί στο μοντέλο Waterfall.
  3. Δύο από τις εφαρμογές μεγάλης κυκλοφορίας και υψηλής προτεραιότητας είχαν προγραμματιστεί να αναπτυχθούν εκ νέου. Το πρώτο είναι «Online εγγραφές», το δεύτερο είναι «Online εξετάσεις».
  4. Το CYent XYZ University ήθελε τώρα να εφαρμοστούν αυτές οι εφαρμογές χρησιμοποιώντας το μοντέλο ανάπτυξης λογισμικού Agile.

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

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

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

Ας τα συζητήσουμε λεπτομερώς ένα προς ένα.

# 1. Χωρίς τεκμηρίωση:

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

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

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

Αυτό ήταν ένα μεγάλο μάθημα που αντλήθηκε και για το επόμενο έργο «διαδικτυακές εξετάσεις» έγιναν έγγραφα και μεταφέρθηκαν αποτελεσματικά.

=> Διαβάστε περισσότερα εδώ γιατί η τεκμηρίωση είναι σημαντική.

#δύο. Χωρίς δοκιμή UAT / End-to-end:

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

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

=> Τέλος σε τέλος δοκιμές σε ζωντανό έργο.

Αυτό έχει τα δικά του οφέλη:

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

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

Όταν ξεκίνησε το έργο online εξετάσεων, έγινε SIT (System Integration Testing) και ο κώδικας προωθήθηκε σε περιβάλλον UAT όπου έγινε ο δεύτερος κύκλος δοκιμών. Αποτέλεσμα: Καταγράφηκαν και επιλύθηκαν όλα τα ελαττώματα υψηλής προτεραιότητας. Η κατασκευή ήταν σταθερή πριν από την κυκλοφορία του live.

# 3. Χωρίς Master Scrum:

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

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

Ωστόσο, ένας ειδικός Scrum Master συμμετείχε στο έργο Online Examinations. Τα θέματα και οι προκλήσεις του έργου αντιμετωπίστηκαν από το Scrum Master. Οι εκθέσεις έργου / σπριντ ετοιμάστηκαν και η ομάδα μπορούσε να δει την πρόοδό τους.

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

# 4. Μετατροπή εγγράφων έργου σε καθυστέρηση προϊόντος:

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

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

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

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

# 5. Πίνακας ιχνηλασιμότητας:

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

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

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

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

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

Το υβριδικό μοντέλο που υιοθετείται μπορεί να αναπαρασταθεί ως εξής:

Συνεργατικό (Υβριδικό) Μοντέλο 3

Συμπέρασμα:

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

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

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

Το μανιφέστο Agile μας ζητά να εκτιμήσουμε:

  • Άτομα και αλληλεπιδράσεις πάνω από διαδικασίες και εργαλεία
  • Λογισμικό εργασίας σε περιεκτική τεκμηρίωση
  • Συνεργασία πελατών για διαπραγμάτευση συμβάσεων
  • Απαντώντας σε αλλαγή πέρα από ένα σχέδιο

Ενώ, το υβριδικό μοντέλο δεν τηρεί αυτό το 100%. Προτείνει ότι όλες οι πτυχές είναι εξίσου σημαντικές. Εναπόκειται στους πελάτες / διαχειριστές του έργου να αποφασίσουν ποιες πτυχές να εκτιμήσουν περισσότερο και ποιες πτυχές να αξίζουν.

Σχετικά με τον Συγγραφέα: Αυτό είναι ένα άρθρο επισκεπτών του Harshpal Singh. Διαθέτει 7+ χρόνια χειροκίνητης εμπειρίας, βάσης δεδομένων, αυτοματισμού και δοκιμών απόδοσης και εργάζεται ως επικεφαλής της ομάδας σε ένα κορυφαίο MNC. Έχει εργαστεί σε πολλά έργα QA ακολουθώντας τα μοντέλα Waterfall, Agile και hybrid development.

Διαθέτετε εμπειρία σε αυτό το υβριδικό μοντέλο ανάπτυξης και δοκιμών; Ας συζητήσουμε σε σχόλια.

Συνιστώμενη ανάγνωση

^