Τρέχω μια έρευνα για την διπλωματική εργασία μου, η οποία αφορά το επίπεδο μοντελοποίησης (UML, BPMN) σε πολύπλοκα συστήματα πληροφορικής.
Θα ήμουν ευγνώμων αν μπορείτε να αφιερώσετε λίγα λεπτά για να συμμετάσχετε: http://goo.gl/forms/F2YALVRufN

Σας ευχαριστώ όλους εκ των προτέρων,
Χρυσάνθ

Ολίγες ενστάσεις: modelling **δεν** είναι δουλειά των business/system analysts. Η UML και το BPMN **δεν** δημιουργήθηκαν από αυτούς που αυτοαποκαλούνται business analysts ενώ στην ουσία κάνουν first level requirements engineering. 
Δημιουργήθηκαν από Software Engineers, για να διευκολύνουν τη σχεδίαση. Αντιγράφηκαν από business consultants των οποίων τα καρτελάκια γράφουν business analysts. Υπάρχουν οι *ρόλοι* αυτοί, αλλά τα *άτομα* που τους καλύπτουν αλλάζουν σε ένα έργο.

Ένας business analyst δεν έχει (ίσως καθόλου) το θεωρητικό ή πρακτικό υπόβαθρο που απαιτούνται για να σχεδιάσει ένα σύστημα πληροφορικής (πολύπλοκο ή μη). Μπορεί να σχεδιάσει τον τρόπο εργασίας *της επιχείρισης*, δεν έχει ιδέα όμως πως αυτό θα σχεδιασθεί, υλοποιηθεί, συντηρηθεί. Γι αυτό και βλέπεις συχνά "απαιτήσεις έργου" μερικών σελίδων bullets, οι οποίες αλλάζουν εντελώς όταν ασχοληθεί με το θέμα ο architect.

Οι Requirements engineers εν τω μεταξύ χρησιμοποιούν διάφορες μεθοδολογίες, διαγράμματα αλλά και κείμενα, πρώτον για να βρουν και δεύτερον για να αναπαραστήσουν τις απαιτήσεις και τις διασυνδέσεις μεταξύ τους. Το οβάλ της UML μπορεί να είναι ένα πολυσέλιδο use case στο οποίο καταλήγει κανείς με αρκετό κόπο, χρησιμοποιώντας συνδυασμό μεθόδων όπως τη Unified Process (η οποία είναι κάτι πολύ διαφορετικό από τη UML).

Το ξέρω γιατί ήμουν στα βαφτίσια  

 Ένσταση #2 - η διαφοροποίηση μεταξύ γλωσσών προγραμματισμού και επεξεργασίας δεδομένων (C vs SQL) είναι εντελώς λάθος. Πολύ απλά, όλοι οι senior προγραμματιστές χρησιμοποιούν SQL. Δεν έχει νόημα να πεις "ποιά χρησιμοποιείς κυρίως" γιατί το 80% των εφαρμογών μιλάει με βάσεις δεδομένων.

#3 - Φυσικά και **όλα** τα project είναι πολύ περίπλοκα, και το δικό μου περισσότερο απ' όλα! Δεν υπάρχει προγραμματιστής που θα πει ότι το σύστημα του είναι "λίγο" περίπλοκο. Φυσικά και υπάρχουν και πιο περίπλοκα από το δικό του αλλά αυτά είναι "ειδικές περιπτώσεις" που δεν μετράνε, οπότε το δικό μου είναι πάντα το πιο περίπλοκο.

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

Πρόκειται για αυτόνομη εφαρμογή ή συνδυασμό συστημάτων? Σε ένα e-shop συνδυάζονται πάρα πολλά συστήματα μαζί, από το site στις πληρωμές, το ERP, το CRM κλπ.

Πόσα άτομα συμμετέχουν σε αυτό?  Άλλο αν όλη η δουλειά γίνεται από 1 άτομο, άλλο αν υπάρχουν 5 ομάδες των 4 ατόμων η κάθε μία (χώρια τους admins)

Σύνδεση με άλλα συστήματα? Το integration είναι μανίκι. Άλλο το app που μιλάει με το δικό του server, άλλο να μιλάς με 3 εξωτερικά συστήματα

 

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Καλησπέρα και πάλι,

Σε σχέση με την παραπάνω απάντηση, προσωπικά από την εμπειρία μου θα μου επιτρέψετε να έχω άλλη άποψη. Καταρχάς, το πως δημιουργήθηκε και γιατί δημιουργήθηκαν οι γλώσσες μοντελοποίησης δεν είναι αντικείμενο της έρευνας αυτής. Επίσης, μου φαίνεται λίγο άστοχη η σύνδεση των εννοιών όσον αφορά τους ρόλους "business analysts" και "first level requirements engineering". Οι αναλυτές (οι business analyst, system analyst όπου συνήθως καλύπτουν και το ρόλο του business architecture αναλόγως του backround και την εμπειρία τους) έχουν σαφώς το θεωρητικό υπόβαθρο και πολλές φορές και το πρακτικό υπόβαθρο για την σχεδίαση ενός συστήματος πληροφορικής. (Έχω συναντήσει πολλούς φυσικούς και χημικούς που με ένα μεταπτυχιακό γράφουν Java ή C++, και ηλεκτρολόγους μηχανικούς ή μηχανικούς Η/Υ να κάνουν την δουλειά αναλυτή και φυσικά πολλές άλλες και διαφορετικές περιπτώσεις). Έχω δουλέψει σε πολύ μεγάλες εταιρίες και τα περισσότερα project που έχω εμπλακεί απαιτούν από τους αναλυτές τους αρκετές τεχνικές γνώσεις, ενώ το documentation που παραδίδεται (στα ευρωπαικά project είναι απαραίτητη προυπόθεση πριν την υλοποίησή) δεν αποτελείται από μερικές σελίδες - ενώ στα οργανωμένα έργα υπάρχει σαφής αναφορά της μεθοδολογίας που θα πρέπει να ακολουθηθεί από τους αναλυτές αλλά και των εργαλείων που θα χρησιμοποιηθούν αναλόγως. Οι γλώσσες προγραμματισμού έχουν νόημα έτσι χωρισμένες αναλόγως με το ποια είναι η κύρια γλώσσα που χρησιμοποιεί κάθε προγραμματιστής στα εκάστοτε έργα, όχι αν τα έργα υποστηρίζονται από μια βάση δεδομένων, που επί το πλείστον υποστηρίζονται. Επίσης, όλα τα έργα έχουν την σημασία τους και την βαρύτητά τους. Όταν ένα έργο αποτελείται από πολλά διαφορετικά components και το κάθε ένα από αυτά υποστηρίζει πολλές και διαφορετικές λειτουργικότητες, τότε ο κάθε προγραμματιστής μπορεί να κρίνει αντικειμενικά τι είναι περίπλοκο και τι όχι. Ένα eshop για το φαρμακείο της γειτονιάς είναι φυσικά λιγότερο περίπλοκο από ένα τύπου amazon. Ο συνδιασμός και η σύνθεση των διαφορετικών λειτουργιών και συστημάτων, αλλά και της ομάδας που πρέπει να απαρτίζεται για την ολοκλήρωση τους είναι αρκετή μετρήσιμη για να αποτελεί μια αντικειμενική παράμετρο για την κρίση του καθενός με μικρή ή περισσότερη εμπειρία (όπου και η "εμπειρία" ενός προγραμματιστή είναι και αυτή ως ένα βαθμό υποκειμενική αναλόγως την φύση των έργων που έχω δουλέψει και τις αντίστοιχες τεχνολογικές απαιτήσεις του). Βλέπω ότι είχε πάρα πολλά views αυτό το post αλλά καμοιά απάντηση, αν μπορείτε να διαθέσετε λίγο χρόνο, θα με βοηθούσατε ειλικρινά να βγάλω πολύ χρήσιμα συμπεράσματα, τα οποία αν θέλετε, όταν ολοκληρώσω την έρευνά μου, μπορώ να τα παρουσιάσω αναλυτικά.

Ευχαριστώ πολύ,

Χρυσάνθη