Προς το περιεχόμενο

Rapid application development


Προτεινόμενες αναρτήσεις

Δημοσ.

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

Σχετικα αρθρα υπαρχουν απειρα στο νετ φυσικα

https://en.wikipedia.org/wiki/Rapid_application_development

https://blog.capterra.com/what-is-rapid-application-development/

 

 

Ο ένας φίλος μου, που είχα να τον δω καιρό, μου ειπε οτι πλεον δουλευει απο Ελλαδα, για μια τετοια εταιρια στην Αμερικη, φυσικα με παγκοσμια παρουσια. Μου εξηγουσε λοιπον τα συναρπαστικα της εν λογω τεχνολογιας. Ποσο γρηγορα μπορεις να αναπτυξεις κατι (πχ μέρες αντι για μηνες), σχετικα ευκολα (σχεδον on the fly), ποσο ευκολα γινονται τροποποιησεις ακομη και απο καποιο λιγο εκπαιδευμενο πανω σε αυτα (σε αντιθεση με κλασικα εμπορικα προγραμματα που δεν μπορεις να βαλεις χερι και περιμενεις ποτε θα ασχοληθει ο developer με το αιτημα σου... + το αναλογο κοστος της custom-ιας...), και αλλα πολλα θετικα. Μου ελεγε παραδειγματα κλασικων εφαρμογων που ηταν αρκετα μονολιθικα, δηλαδη αναγκαζαν τον πελατης να μπει στην λογικη τους, αντι να 'ραβεται' ενα προγραμμα -οπως με την RAD- στα μετρα του πελατη. κλπ. Επισης μου ανεφερε οτι πολλες RAD λυσεις, ειναι οικονομικα πιο συμφερουσες, απο κλασικες εφαρμογες software, τοσο κατα την αγορα-δημιουργια, οσο και για τη μετεπειτα συντηρηση τους. Κι ακομη, ειναι web based, και με εφαρμογες στο κινητο, ετοιμα σχεδον out of the box τα παντα ολα!  Λιγο να καταλαβει καποιος τη λογικη, μου ειπε οτι μπορει να κανει 'παπαδες' πανευκολα! Ή να κανει τα περισσοτερα μονος του , κι ισως χρειαστει ενα μικρο support στο τελος!!!!

Εφτασε δε να μου πει και δυο ενδεικτικα παραδειγματα:

1) ηταν σε meeting για να συζητησουν για την αναπτυξη της εφαρμογης, αυτος τους ακουγε τι ηθελαν σε μια ακρη της αιθουσας, και πριν τελειωσει το meeting, τους το ειχε σχεδον ετοιμο!!! (ελειπαν μονο οι τελευταιες πινελιες!) - !!!!!!!!!!!!!!!!!!!!!!!!!

2) οταν κατεθεταν προσφορες για συμμετοχη σε καποια προκηρυξη διαγωνισμο, αλλοι πηγαιναν με εντυπες προτασεις, κι αυτος με tablet με υλοποιημενη (σε πολυ μεγαλο ποσοστο!) την εφαρμογη που ζητουσε ο πελατης!!!!!!!!!!!!!!!!!!!

 

 

Ο άλλος φιλος μου, επισης ψαγμενος κομπιουτερας, βαλθηκε να μου απομυθοποιησει την RAD. Μου ελεγε λοιπον, οτι κυριως ενδεικνυται για σχετικα 'απλα πραγματα', κι εκει με τα πλεονεκτηματα της, οντως μπορει να ειναι η πιο συμφερουσα επιλογη να κανεις κατι. Αλλα ομως, εχει και πολλα αρνητικα. Πχ μου ελεγε, πολλα προγραμματα στην Ελλαδα, βασιζονται στην ελληνικη νομοθεσια. Πως θα κανεις με RAD, κατι που απαιτει να ειναι συνεχως εναρμονισμενο με ελληνικούς νομους, που αλλαζουν καθε μερα; Λογιστικα, οικονομικα, τεχνικά κλπ. Επειτα μου λεει, θες μια εταιρια να παιρνει την ευθυνη να κανει αμεσα ολες τις αλλαγες, οπως τις απαιτουν καθε λιγο οι εγκυκλιοι και οι νομοι των υπουργειων. Ποιος θα καθισει να τα κανει σε RAD ολα αυτα; Και ποιος μπορει να παρει και την ευθυνη (ακομη και αν θελει να μπει σε αυτο τον κυκεωνα αλλαγων), για να κανει τετοιες αλλαγες, που επηρεαζουν μισθοδοσιες, κρατησεις, οικονομικα θεματα κλπ. Με λιγα λογια, μου ειπε οτι η RAD δεν ειναι πανακεια για ολα, και μαλλον αξιζει να πας σε τετοια λυση, για απλες εφαρμογες, ή για εφαρμογες σχετικα 'αυτονομες' απο νομοθετικες ρυθμισεις.

Φυσικα, πολλα μπορει να εξετασεις κανεις, οπως συμβολαια συντηρησης, χρεωσεις για αλλαγες, ευκολια δομησης ενος περιβαλλοντος που οντως θα πλησιαζει αυτο που θελει ο πελατης και οχι να του πασαρεις κατι που ειναι για χιλιες μυριες χρησεις και ας βρει ο πελατης το δρομο του σε ενα generic προγραμμα (κι ας εχει σοβαρο support απο την εταιρια), οι μελλοντικες απαιτησεις για επεκτασιμοτητας κλπ

 

Θα ηθελα τις δικες σας αποψεις, εμπειριες, πανω στο θεμα. Αν εχετε καταληξει, ποτε ειναι συμφερουσα/καλυτερη μια υλοποιηση τυπου RAD, και ποτε η κλασικη προσεγγιση της αγορας προγραμματων.

 

 

 

  • 1 μήνα μετά...
Δημοσ.

Γρήγορα στάδια ανάπτυξης εφαρμογών
Η προσέγγιση της Martin στην ταχεία ανάπτυξη εφαρμογών αναγνωρίζει τέσσερα στάδια:

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

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

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

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

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

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

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

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

Διαβάστε εδώ για το rad model.

 

 

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
  • Δημιουργία νέου...