Πώς υλοποιούμε την ανάλυση απαιτήσεων;

Πώς μοιάζει η διαδικασία σχεδιασμού;

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

1. A έργο όραμα που περιγράφει το τελικό προϊόν να δημιουργηθεί.
2. Ένα γενικό σχέδιο δράσης ή μια ιδέα που καθορίζει τι πρέπει να γίνει για την επίτευξη των στόχων μας.
3. Κατάλογος των βασικών εργασιών που καθορίζουν τα στάδια των εργασιών στο έργο.
4. Χρονικός προγραμματισμός, κατά τον οποίο καθορίζουμε τι και πότε πρέπει να παραδοθεί.
5. Λεπτομερής σχεδιασμός των επιμέρους εργασιών που δημιουργήθηκαν κατά το τρίτο στάδιο.

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

Όραμα του έργου

Σε αυτό το στάδιο, θα πρέπει να θέσουμε στον εαυτό μας ορισμένα βασικά ερωτήματα:

1. Τι θέλουμε να κάνουμε;

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

• Ποιο πρόβλημα πρέπει να λύσει το έργο αυτό;
• Ποιος θα είναι ο τελικός χρήστης του;
• Δημιουργούμε μια διεπαφή για τους χρήστες; Προβλέπεται η δημιουργία του στο μέλλον; Έχει καθοριστεί ο τύπος της διεπαφής που δημιουργούμε (desktop ή mobile); Μας ενδιαφέρει το RWD;
• Υπάρχουν παρόμοιες εφαρμογές; Ποια είναι τα πλεονεκτήματα και τα μειονεκτήματά τους;
• Έχουν δημιουργηθεί ήδη κάποια αρχικά σχέδια ή μακέτες για το έργο;
• Θα εξαρτηθεί το έργο από εξωτερικές εφαρμογές; Έχουν ή γνωρίζουμε τους περιορισμούς τους;
• Γνωρίζουμε τίποτα για τις αναμενόμενες επιδόσεις και το επίπεδο ασφάλειας;

2. Ποιες είναι οι απαιτήσεις;

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

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

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

3. Ποιος είναι ο τελικός στόχος;

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

4. Ποιες είναι οι προτεραιότητες;

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

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

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

Σχέδιο δράσης

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

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

Κύρια καθήκοντα

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

Περίληψη

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

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

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

Διαβάστε περισσότερα:

• Ποια είναι η καλύτερη προσέγγιση διαχείρισης έργων για την ανάπτυξη λογισμικού;
• Οι καλές πρακτικές της Codest για την κατασκευή λογισμικού. Η προσέγγισή μας στο ταξίδι του πελάτη
• Ένας γρήγορος οδηγός για τη δημιουργία και την ανάπτυξη της δικής σας αγοράς. Τι αξίζει να γνωρίζετε;