HMMY Τεχνολογία Λογισμικού Διδάσκων Κώστας Κοντογιάννης Αναπλ

Παρουσίαση με θέμα: "HMMY Τεχνολογία Λογισμικού Διδάσκων Κώστας Κοντογιάννης Αναπλ"— Μεταγράφημα παρουσίασης:

1 HMMY Τεχνολογία Λογισμικού Διδάσκων Κώστας Κοντογιάννης Αναπλ

2 Εισαγωγή – Καλωσόρισμα
Σας εύχομαι Καλή αρχή στο μάθημα Τεχνολογία Λογισμικού και Καλή επιτυχία Η Τεχνολογία Λογισμικού είναι ένα μάθημα που θέλει δουλειά, αλλά παράλληλα προσφέρει πολλές και πρακτικές γνώσεις σε μια περιοχή που στην εποχή μας έχει μεγάλη επίδραση σε πολλούς τομείς της καθημερινής ζωής μας Ο σκοπός του μαθήματος είναι Να κατανοήσουμε τις βασικές αρχές προδιαγραφής, σχεδίασης, υλοποίησης, ελέγχου, και συντήρησης συστημάτων λογισμικού Να εφαρμόσουμε αυτές τις αρχές μέσα από εργαστηριακές ασκήσεις

3 Στοιχεία Επικοινωνίας
Κώστας Κοντογιάννης Ηλ. Ταχυδρ: Tηλ. (210) Ωρες Γραφείου: Τετάρτη 10:00π.μ – 12:00μμ

4 Σύγγραμμα “Λογισμική Μηχανική (Software Engineering)”
Εμμανουήλ Στ. Σκορδαλάκη Αθήνα 2006

5 Κεντρική Ιστοσελίδα του Μαθήματος
Εκεί θα βρείτε συνδέσμους προς: το περιβάλλον ηλεκτρονικής μάθησης Moodle ( περιφερειακές σελίδες με τις διαλέξεις σε ηλεκτρονική μορφή την περιγραφή των εργαστηριακών ασκήσεων ιστοσελίδες σχετικές με θέματα τεχνολογίας λογισμικού από τον παγκόσμιο ιστό

6 Εργαστηριακή Άσκηση Σχεδίαση και υλοποίηση μιας VoIP τηλεφωνικής εφαρμογής που βασιζεται στο πρωτόκολλο SIP Ομάδες των 4 ατόμων 30% του τελικού βαθμού Τρία παραδοτέα: Προδιαγραφές Απαιτήσεων Χρήστη Προδιαγραφές Σχεδίασης Υλοποίηση

7 Τα Επόμενα Βήματα Γραφτείτε στο Moodle
Επισκεφθείτε την ιστοσελίδα του μαθήματος (από την Παρασκευή και μετά) Γραφτείτε στην Εργαστηριακή Άσκηση

8 Δομή της Ύλης του Μαθήματος
Ενότητα 1: Βασικές Αρχές Τεχνολογίας Λογισμικού Ενότητα 2: Διαδικαστικά Μοντέλα και Κύκλος Ζωής Λογισμικού Ενότητα 3: Ενοποιημένη Γλώσσα Μοντελοποίησης (UML) Ενότητα 4: Στοιχεία Αρχιτεκτονικής Συστημάτων Λογισμικού Ενότητα 5: Σχεδιαστικά Πρότυπα Ενότητα 6: Έλεγχος και Αξιοπιστία Συστημάτων Λογισμικού Ενότητα 7: Αρχές Οργάνωσης και Διαχείρισης Έργων Λογισμικού

9 Τι Είναι Τεχνολογία Λογισμικού ?
Τομέας που πραγματεύεται τεχνικές, μεθοδολογίες, πρακτικές και εργαλεία για την συστηματική, μεθοδική και ποσοτικοποιημένη προδιαγραφή, σχεδίαση, υλοποίηση, έλεγχο, και συντήρηση συστημάτων λογισμικού υψηλής ποιότητας και εντός δεδομένου προϋπολογισμού και χρόνου εκτέλεσης [IEEE Standard ]

10 Τεχνική – Μεθοδολογία – Εργαλεία
Τεχνική – Μεθοδολογία – Εργαλεία Τεχνική (methods): Φορμαλιστικές διαδικασίες για την επίλυση προβλημάτων με τη χρήση καλώς ορισμένων συστημάτων παρουσίασης και κωδικοποίησης Μεθοδολογία: Συλλογή από τεχνικές που εφαρμόζονται επιλεκτικά κατά την διάρκεια όλων των φάσεων ενός έργου και συνδυάζονται σύμφωνα με κάποια γενική πρακτική και πλάνο Εργαλεία: Αυτοματοποιημένα συστήματα που διεκπεραιώνουν μια τεχνική

11 Διακριτοί και Συμπληρωματικοί Ρόλοι
Επιστήμων Υπολογιστών Έχει σαν σκοπό την απόδειξη θεωρημάτων και χαρακτηριστικών αλγορίθμων, την σχεδίαση νέων γλωσσών προγραμματισμού, να ορίσει νέες τεχνικές και σχήματα παρουσίασης πληροφοριών κλπ. Έχει συνήθως απεριόριστο χρόνο στη διάθεση του/της… Μηχανικός Σχεδιάζει μια λύση για κάποιο συγκεκριμένο πρόβλημα και περιοχή εφαρμογής Χρησιμοποιεί υπολογιστές, γλώσσες, τεχνικές, μεθοδολογίες και, εργαλεία Μηχανικός Λογισμικού Συνήθως δουλεύει για την σχεδίαση λύσεων σε διαφορετικές περιοχές εφαρμογής Έχει στη διάθεσή του/της 3 μήνες για την σχεδίαση της λύσης ... …ενώ παράλληλα οι απαιτήσεις του χρήστη και η διαθέσιμη τεχνολογία συνεχώς αλλάζουν A computer scientist assumes that techniques, methodologies and tools are to be developed. They investigate in designs for each of these weapons, and prove theorems that specify they do what they are intended to do. They also design languages that allow us to express techniques. To do all this, a computer scientist has available an infinite amount of time. A software engineering views these issues as solved. The only question for the software engineer is how these tools, techniques and methodologies can be used to solve the problem at hand. What they have to worry about is how to do it under the time pressure of a deadline. In addition they have to worry about a budget that might constrain the solution, and often, the use of tools. Good software engineering tools can cost up to a couple of $10,000 Dollars (Galaxy, Oracle 7, StP/OMT) Object modeling is difficult. As we will see, good object modeling involves mastering complex concepts, terminology and conventions. It also requires considerable and sometimes subjective expertise in a strongly experience-based process. Beware of the false belief that technology can substitute for skill, and that skill is a replacement for thinking. offers this advise [cit Tillmann]. Many organizations are frustrated with a lack of quality from their tool-based systems. However, the cause of this problem is often the false belief that a tool can be a substitute for knowledge and experience in understanding and using development techniques. Although CASE tools such as StP/OMT or Objectory and similar tools have the potential to change how people design applications, it is a mistake to think they can replace the skills needed to understand and apply underlying techniques such as object, functional or dynamic modeling. You cannot substitute hardware and software for grayware (brain power) [cit Tillmann]: Buying a tool does not make a poor object modeler a good object modeler. Designers need just as much skill in applying techniques with CASE tools as they did with pen and paper. Another problem, that is often associated with tool-based analysis is that it is often insufficient or incomplete. Why is that? To a certain extent this problem has always existed. Systems developers are much better at collecting and documenting data than they are at interpreting what these data mean. This in unfortunate, because the major contribution an analysist can bring to system development is the thought process itself. But just as a tool is not a substitute for technique, knowledge and experience, technique skills cannot replace good analysis - people are still needed to think through the problem. So our message is: Being able to use a tool does not mean you understand the underlying techniques, and understanding the techniques does not mean you understand the problem. In the final analysis, organizations and practitioners must recognize, that methodologies, tools and techniques do not represent the added values of the object modeling process. Rather, the real value that is added, is the thought and insight that only the analyst can provide.

12 Διαδρομές Κατασκευής Λογισμικού
επιστήμων ανάγκες/ εύρεση δεδομενικό κομμάτι πρόβλημα θεωρητικής θεωρητικής λύσης λύσης εύρεση εύρεση υβριδικής τεχνολογικής λύσης λύσης λογισμικός λογισμικός μηχανικός μηχανικός λογισμικό σύστημα

13 Προγραμματισμός σε Σχέση με την Τεχνολογία Λογισμικού
Προγραμματισμός σε Σχέση με την Τεχνολογία Λογισμικού Περιορισμένου όγκου έργα Υλοποιημένα από μικρές ομάδες Με απλές λειτουργικές και μη απαιτήσεις Για μια συγκεκριμένη εφαρμογή Με απλές αλλαγές Χρησιμοποιούνται για σχετικά σύντομο διάστημα Έχουν μικρό σχετικά κόστος Έχουν μικρό σχετικά αντίκτυπο Μεγάλου όγκου έργα Υλοποιημένα από πολλές ομάδες Με πολύπλοκες απαιτήσεις Οικογένειες εφαρμογών Με πολλές παράλληλες αλλαγές Χρησιμοποιούνται για πολλά χρόνια Έχουν μεγάλο κόστος Έχουν μεγάλο αντίκτυπο Programming Engineering

14 Τεχνολογία Λογισμικού
Δι-επιστηµονική περιοχή Επιστήμης υπολογιστών (προγραμματισμός, αλγόριθμοί) Υλικού (hardware) Τεχνολογίες διαχείρισης πληροφοριών (βάσεις δεδομένων, οργάνωση προσπέλασης και χρήση δεδομένων) Περιβάλλοντα δι-επαφής με τον χρήστη (user interfaces, εργονομία) Κανονισμοί λειτουργίας, νομικές διαστάσεις Πεδίο επιχειρηµατικής δραστηριότητας Ανταγωνισµός Κόστος παραγωγής Τεχνογνωσία

15 Κατηγοριοποίηση Λογισμικού
Λογισμικό (software) λογισμικό υποδομής (infrastructure λογισμικά εργαλεία λογισμικό εφαρμογής software) (software tools) (application software) βασισμικό μεσισμικό (baseware) (middleware)

16 Οι Λογισμικές εργασίες κατά το ΙΕΕΕ Std 1074

17 Κύκλος Ζωής Λογισμικού
Φάση Προδιαγραφής Λειτουργικών και Μη-Λειτουργικών Απαιτήσεων Φάση Ανάλυσης Φάση Σχεδίασης Φάση Υλοποίησης Φάση Ελέγχου και Πιστοποίησης Φάση Ενοποίησης και Εγκατάστασης Φάση Συντήρησης Φάση Αποχώρησης

18 Μέση Κατανομή Κόστους Object-Oriented and Classical Software Engineer 5th Edition, Schach (2002)

19 Φάσεις Κύκλου Ζωής ...και τα Μοντέλα τους Προδιαγραφές Απαιτήσεων
Ανάλυση Αρχιτεκτονική Συστήματος Σχεδίαση Συστήματος Υλοποίηση Έλεγχος Μοντέλα Χρήσης Περιπτώσεις Ελέγχου ? Επαληθεύονται με class.... class... Πηγαίος Κώδικας Υλοποιούνται από Αντικείμενα Πεδίου Λύσης Πραγματοποιούνται με Υπο- συστήματα Δομούνται με Αντικείμενα Πεδίου Εφαρμογής Εκφράζονται από

20 Μοντέλα Κύκλου Ζωής Οι φάσεις του κύκλου ζωής είναι διαδικασίες που εφαρμόζονται Είτε παράλληλα Είτε με κάποια συγκεκριμένη σειρά Η εφαρμογή αυτών των διαδικασιών ορίζεται Από κάποιο συγκεκριμένο μοντέλο και από το πλαίσιο (context) του έργου

21 Διαδικασία και Προϊόν Μοντέλο Εργαλεία Κ. Ζ Μηχανικοί / Έργο Χρήστες
Αυτοματισμός Εργαλεία Πρότυπο Συμμετέχοντες Μηχανικοί / Χρήστες Έργο Αποτέλεσμα Προϊόν

22 Μοντέλα Κύκλου Ζωής Το µοντέλο του καταρράκτη (waterfall model)
Το µοντέλο πρωτοτυποποίησης (rapid prototyping) Το µοντέλο λειτουργικής επαύξησης (incremental model) Το σπειροειδές µοντέλο (spiral model) Το ενοποιημένο μοντέλο (unified model)

23 Ένα Απλό Σειριακό Μοντέλο Κύκλου Ζωής

24 Μοντέλο Καταρράκτη (Waterfall)
Χαρακτηρίζεται από Σειριακά βήματα (phases) Ανάδραση ανάμεσα σε δύο γειτονικά βήματα Βασίζεται στην δημιουργία προδιαγραφών σε κάθε βήμα Προτερήματα Παραγωγή προδιαγραφών Διευκολύνει την συντήρηση Μειονεκτήματα Προδιαγραφές που δεν μπορούν να αλλάξουν στη πορεία δεν είναι ρεαλιστική παραδοχή Ο Χρήστης συμμετέχει μόνο στην αρχή Σειριακή και πλήρης ολοκλήρωση κάθε βήματος δεν είναι πάντα ενδεδειγμένη Η διαδικασία είναι δύσκολο να ελεγχθεί Ό χρήστης βλέπει το προϊόν πολύ αργά στη διάρκεια της διαδικασίας

25 Μοντέλο Πρωτοτυποποίησης
Σχεδίαση πρωτότυπου ακολουθούμενου από το μοντέλο Καταρράκτη Το πρωτότυπο δεν είναι το προϊόν Η Πρωτοτυποποίηση δεν πρέπει να είναι μέρος της σχεδίασης αλλά μόνο της συλλογής απαιτήσεων Προτερήματα Καλύτερη προδιαγραφή απαιτήσεων Καλύτερη μελέτη σκοπιμότητας Ο χρήστης συμμετέχει ενεργά στη διαδικασία συλλογής / μοντελοποίησης απαιτήσεων Μειονεκτήματα Περισσότερη εργασία απαιτείται για την παραγωγή του πρωτότυπου Λόγω χρονικών περιορισμών το πρωτότυπο γίνεται μέρος του συστήματος

26 Αυξητικό Μοντέλο Προτερήματα
Σε κάθε έκδοση προσθέτουμε και νέες λειτουργίες / ποιοτικά χαρακτηριστικά από ένα προκαθορισμένο σύνολο απαιτήσεων Έκδοση (Release) 1 Σχεδίαση Υλοποίηση Έλεγχος Εγκατάσταση Έκδοση 2 Απαιτήσεις Σχεδίαση Υλοποίηση Έλεγχος Εγκατάσταση Έκδοση 3 Σχεδίαση Υλοποίηση Έλεγχος Εγκατάσταση Προτερήματα Σε κάθε έκδοση έχουμε ένα σύστημα σε λειτουργία Καλύτερη διανομή κόστους στο χρόνο Μειονεκτήματα - Οι απαιτήσεις δεν πρέπει να αλλάζουν

27 Εξελικτικό Μοντέλο Προτερήματα Συνεχής συμμετοχή του χρήστη
Νέες εκδόσεις υλοποιούν νέες απαιτήσεις που εξελίσσονται όσο το σύστημα υλοποιείται Έκδοση (Version) 1 Design Coding Test Deployment Requirements Έκδοση (Version) 2 Design Coding Test Deployment Requirements Έκδοση (Version) 3 Feedback Design Coding Test Deployment Requirements Προτερήματα Συνεχής συμμετοχή του χρήστη Καλή διαχείριση κρίσης Μειονεκτήματα - Μπορεί να γίνει ράβε – ξήλωνε τύπος μοντέλου

28 Spiral model Ουσιαστικά είναι το μοντέλο πρωτοτυποποίησης όπου στο τέλος κάθε βήματος κάνουμε έλεγχο σκοπιμότητας και ανάλυση ρίσκου Πρωτοτυποποίηση για εφαρμογές υψηλού ρίσκου Εάν η ανάλυση ρίσκου αποτύχει τότε το έργο διακόπτεται Το σπειροειδές μοντέλο είναι πιο κατάλληλο για μεγάλα έργα λόγω του μεγαλύτερου κόστους διαχείρισης Αν το έργο έχει ήδη προχωρήσει πολύ είναι δύσκολο να τερματιστεί ακόμη και αν η ανάλυση ρίσκου αποτύχει

29 Σπειροειδές Μοντέλο

30 Γενικά Σχόλια για Μοντέλα Κύκλου Ζωής
Μοντέλο Καταρράκτη Υψηλού ρίσκου για νέα συστήματα λόγω της δυσκολίας συγκέντρωσης νέων και άγνωστων μέχρι τώρα απαιτήσεων και σχεδιαστικών προβλημάτων Χαμηλού ρίσκου μοντέλο για έργα που χρησιμοποιούν γνωστές τεχνολογίες και έργα που έχουν κατανοηθεί καλά (ή παρόμοιά τους έχουν υλοποιηθεί στο παρελθόν) Μοντέλο Προτωτυποποίησης Χαμηλού ρίσκου για νέες και σχετικά άγνωστες εφαρμογές διότι οι συλλογή των απαιτήσεων και η διαδικασία προτοτυποποίησης συμβαδίζουν Υψηλού ρίσκου διότι απαιτεί ξεχωριστούς πόρους για τη σχεδίαση των πρωτότυπων Εξελικτικό και Σπειροειδές Μέση λύση ανάμεσα στο μοντέλο καταρράκτη και πρωτοτυποίησης

31 Εξελικτικά Μοντέλα του Σήμερα
Ενοποιημένο Μοντέλο Rational Unified Process (RUP) Μοντέλο Extreme Programming (XP)

32 Κύρια Χαρακτηριστικά RUP
Εξελικτικό μοντέλο με ανάδραση Καθοδηγείται από μελέτες χρήσης (use cases) Είναι αρχιτεκτονικο-κεντρικό μοντέλο (4+1 άποψεις – views) Χρησιμοποιεί την UML σαν γλώσσα μοντελοποίησης Πλούσιο πλαίσιο υποστήριξης της διαδικασίας

33 Ενοποιημένο Μοντέλο RUP - Έννοιες
Worker (κατασκευαστής) Ενα άτοµο ή µία οµάδαατόµων µε συγκεκριµένο ρόλο στην ανάπτυξη λογισµικού Δραστηριότητα(activity) Μια συγκεκριµένη εργασία που εκτελείται κατά την ανάπτυξη λογισµικού Συστατικό στοιχείο λογισµικού (artifact) Ενα αποτέλεσµα της εκτέλεσης µιας εργασίας Ροή εργασιών (workflow) Μια αλληλουχία δραστηριοτήτων

34 Ενοποιημένο Μοντέλο RUP Έννοιες
Βασικές ροές: Μοντελοποίηση επιχειρησιακού περιβάλλοντος (Business Modeling) Συγγραφή προδιαγραφών (Requirements) Ανάλυση και σχεδίαση (Architecture and Design) Υλοποίηση (Implementation) Ελεγχος (Test) Εγκατάσταση (Deployment) Φάσεις: Έναρξη (Inception) Επεξεργασία (Elaboration) Κατασκευή (Construction) Μετάβαση (Transition) Ροές υποστήριξης: Διοίκηση σχηµατισµών λογισµικού (Configuration Management) Διοίκηση έργου (Project Management) Διαχείριση περιβάλλοντος ανάπτυξης (Development Environment Management)

35 RUP Φάσεις Tο μοντέλο RUP έχει τέσσερις φάσεις στο χρόνο:
The student notes are quite extensive. There is no need to go into that much detail in class. The important thing is to understand how the RUP uses phases to organize the life cycle. You can also mention that we deliberately chose names that do not match the waterfall names (analysis, design, implementation, and test) to emphasize that they are NOT the same as the waterfall phases. Some ways of describing the phases in common terminology: Inception - bid and proposal Elaboration - Building blueprints Construction - I think I’m done Transition - how do users react? Inception Elaboration Construction Transition time Tο μοντέλο RUP έχει τέσσερις φάσεις στο χρόνο: Έναρξη (Inception) – Ορισμός του έργου και της έκτασής του Επεξεργασία (Elaboration) – Κατάστρωση μεθόδου υλοποίησης του έργου, μοντελοποίηση χαρακτηριστικών του έργου, ορισμός της αρχιτεκτονικής του συστήματος Κατασκευή (Construction) – Υλοποίηση του έργου Μετάβαση (Transition) – Ανάπτυξη του συστήματος στο περιβάλλον χρήσης του During Inception, we define the scope of the project, what is included, and what is not. This is done by identifying all the actors and use cases, and by drafting the most essential use cases (usually approximately 20% of the complete model). A business plan is developed to determine whether resources should be committed to the project. During Elaboration, we focus on two things: get a good grasp of the requirements (90% complete) and establish an architectural baseline. If we have a good grasp of the requirements and the architecture, we can eliminate a lot of the risks and will have a good idea what amount of work remains to be done. Detailed cost/resource estimations can be made at the end of Elaboration. During Construction, we build the product in several iterations up to a beta release. During Transition, we transition the product to the end user and focus on end user training, installation, and support. The amount of time spent in each phase varies. For a very complex project with a lot of technical unknowns and unclear requirements, Elaboration may include 3-5 iterations. For a very simple project where requirements are known and the architecture is simple, Elaboration may include only a single iteration.

36 Workflows group activities logically
RUP Overview Can iterations overlap? No. Our model is to show no overlap among iterations. In a large project, several teams may work in parallel on their portions of the iteration, but we do not consider these to be separate iterations. How many iterations should you have? It depends on many factors. Err on the side of too many iterations. Animation note: The callouts and black rectangle appear 2 seconds after the slide. Management Environment Business Modeling Implementation Test Architecture & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements Elaboration Transition Inception Construction Workflows group activities logically In an iteration, you walk through all workflows This graphic illustrates how phases and iterations, or the time dimension, relates to the development activities performed, or the workflow dimension. The relative size of the color area indicates how much of the activity is performed in each phase/iteration. Each iteration involves activities from all workflows. The relative amount of work related to the workflows changes between iterations. For instance, during late Construction, the main work is related to Implementation and Test and very little work on Requirements is done. Note that requirements are not necessarily complete by the end of Elaboration. It is acceptable to delay the analysis and design of well- understood portions of the system until Construction because they are low in risk.

37 Σύνοψη του Μοντέλου XP Χαρακτηριστικά Εξελικτική μέθοδος υλοποίησης
Συλλογή από “12 Καλύτερες Πρακτικές“ Εστιάζει σε κώδικα που είναι πάντα λειτουργικός και υλοποιεί συγκεκριμένες απαιτήσεις και ανάγκες του χρήστη Ο συνεχής έλεγχος του κώδικα είναι σημαντικό συστατικό της διαδικασίας Εστιάζει στην ευλυγισία και λειτουργικότητα της διαδικασίας Υλοποιείται συνήθως από μικρές ομάδες (<10) Planning Κάθε 2-3 εβδομάδες Write tests Pair Programming + Refactoring Release Test Κάθε ημέρα Integration

38 Άλλα Μοντέλα Άλλα Μοντέλα που σχετίζονται με τα Μοντέλα Κύκλου Ζωής και την Αναμενόμενη Ποιότητα Λογισμικού είναι: ISO 9000: Aαφορά στην εξασφάλιση της ποιότητας προϊόντων και υπηρεσιών. Capability Maturity Model: Αφορά στη σύνδεση της διαδικασίας με την αναμενόμενη ποιότητα του προϊόντος

39 Μοντέλο Επίπεδων Ωριμότητας Capability Maturity Model

40 Πρότυπα (Standards) Λογισμικού