1 System Requirements ΥΠΕΥΘΥΝΟΣ: ΘΟΔΩΡΗΣ ΜΑΝΑΒΗΣ Introduction.

Παρουσίαση με θέμα: "1 System Requirements ΥΠΕΥΘΥΝΟΣ: ΘΟΔΩΡΗΣ ΜΑΝΑΒΗΣ Introduction."— Μεταγράφημα παρουσίασης:

1 1 System Requirements ΥΠΕΥΘΥΝΟΣ: ΘΟΔΩΡΗΣ ΜΑΝΑΒΗΣ tmanavis@ist.edu.gr Introduction

2 2 Requirements elicitation T Manavis

3 3 Programming vs. Software Engineering T Manavis Small project You Build what you want One product Few sequential changes Short-lived Cheap Small consequences Huge project Teams Build what they want Family of products Many parallel changes Long-lived Costly Large consequences ProgrammingEngineering

4 Τι είναι Τεχνολογία Λογισμικού; Κλάδος της Πληροφορικής που ασχολείται με τη μελέτη και ανάπτυξη τεχνικών για την παραγωγή λογισμικού που ικανοποιεί τις προδιαγραφές του, με την καλύτερη δυνατή ποιότητα, παραδίδεται μέσα σε προδιαγεγραμμένα χρονικά όρια και το κόστος ανάπτυξής του βρίσκεται μέσα σε προδιαγεγραμμένα όρια [IEEE]: "the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software« Περιγραφή του τρόπου υλοποίησης Λογισμικού

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

6 Χαρακτηριστικά της ανάπτυξης λογισµικού Το αποτέλεσµα δεν είναι «ορατό» - µόνο το αποτέλεσµα της χρήσης του Η ανάπτυξη λογισµικού αλλάζει συνεχώς στόχο Μεταβάλλονται οι απαιτήσεις των χρηστών, Το περιβάλλον ανάπτυξης, καθώς και το υλικό συνεχώς εξελίσσονται Το περιβάλλον λειτουργίας του λογισµικού µεταβάλλεται ραγδαία

7 Κριτήρια επιτυχούς Λογισμικού Κάνει αυτό που σχεδιάστηκε να κάνει (τίποτε παραπάνω, τίποτε παρακάτω!!!) Σε λογικό χρόνο Με λογικό κόστος Έχει ποιότητα (χρηστικότητα, δυνατότητα επέκτασης/ συντήρησης)

8 Κρίση Λογισμικού Κατά κανόνα, η ανάπτυξη μεγάλων έργων λογισμικού παρουσιάζει προβλήματα: υπερβάσεις στο χρονοδιάγραμμα υπερβάσεις στον προϋπολογισμό παραγόμενο προϊόν κακής ποιότητας πολυδάπανο στη συντήρησή του Από στοιχεία του 1979, από έργα 6.8 εκατομμυρίων δολαρίων: 47% πληρώθηκε αλλά δεν παραδόθηκε προς χρήση 29% παραδόθηκε αλλά δεν χρησιμοποιήθηκε 19% τροποποιήθηκε μετά την παράδοση 3% χρησιμοποιήθηκε με μικρές αλλαγές 2% χρησιμοποιήθηκε όπως παραδόθηκε

9 Κρίση Λογισμικού

10 Κρίση Λογισμικού - Λόγοι –ανεπαρκής προσδιορισμός απαιτήσεων -> προβληματική σχεδίαση –μη ρεαλιστικοί στόχοι του project –μη ακριβείς εκτιμήσεις απαιτούμενων πόρων –κακή αναφορά προόδου –ελλιπής χειρισμός ρίσκου –κακή επικοινωνία μεταξύ πελατών, προγρ/στών, χρηστών –έλλειψη εμπειρίας με τεχνολογία –αδυναμία χειρισμού πολυπλοκότητας

11 Απάντηση στη Κρίση ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ SOFTWARE ENGINEERING Επιστημονική Θεμελίωση του Λογισμικού (κύκλου ζωής, διαδικασίας παραγωγής, τρόπου περιγραφής – τεκμηρίωσης, διαδικασίας συντήρησης)

12 12 Software development lifecycle In the analysis phase we move from a vague description of the problem to be solved to a precise and unambiguous requirements specification. The requirements specification might be a precise, but informal description written in careful natural language text and diagrams. The requirements specification should be: complete, consistent, readable by application domain experts and software developers, independent of programming considerations. In the design phase, we move from a requirements specification to a design specification. The design specification gives the system structure. The design tasks are to: Break the programming task into manageable parts. Define the relationships among the parts. Incorporate any required or appropriate pre-existing components. Keep the design independent of implementation language and hardware details. In the implementation phase, we move from a design specification to a tested executable system. In the maintenance phase, we move from a complete "working" system to a modified system. The maintenance tasks are to: Repair any errors in analysis, design, or implementation that have been found. Adapt to the changes in requirements that have occurred. The cost of failure at different stages of the lifecycle T Manavis

13 13 What is UML UML: Unified Modeling Language (Booch, Rumbaugh, Jacobson) Used for specification, analysis, design and implementation of OOSD process (Object-oriented System Development) Aim of using UML: UML is a visual modeling tool (uses text and graphics). Communicates the ideas of a design with a notation more precise than natural language (e.g., English), and not as precise as an actual programming language. In this sense, it has the same purpose as a pseudo-code language. UML is NOT a programming language! UML is only a tool. Do not be fooled into thinking that knowing UML makes you a good designer!! T Manavis

14 14 Use Cases and Use Case modeling A Use Case is a definition of a meaningful interaction with a computer system. If you have used the internet to buy things, an example of a Use Case would be choosing something from an online catalogue, and another might be paying for the goods. Use Case diagrams say "what" a system does. The detailed analysis of Use Cases begins to say something of "how" the system behaves in an environment. However, it does not say "how" a system is structured internally to provide that behaviour. In computer system development you will frequently see this separation emphasised. Before you decide how a system works, you need to determine what it does first - a simple and obvious rule, but one so often forgotten to many people's ultimate regret. T Manavis

15 15 An online bookshop (a case study) The system gives the user the ability either to log on, or, if he/she is a new customer register for the first ime and then log on. The customer provides his/her username and password and if they are correct the system logs him/her on. He can view items and place them in his/her shopping cart. When he/she finishes, he/she can proceed to the checkout or log off the system. The system prompts the user to finalize his shopping cart (i.e. asks the customer if he/she wants to add or remove any other books). Then, the system provides the user with information on possible delivery dates for the books he selected (some books may take a long time to deliver, so the customer needs to be warned of that). If the customer agrees to the proposed delivery dates, he/she proceeds to the payment stage (by credit card only). The system validates the credit card and creates the order, updates the inventory and provides the customer with an "electronic receipt" via email. For the above system we are going to draw the activity diagram. See the following slide: T Manavis

16 An online bookshop, use case diagram T Manavis

17 17 An online bookshop (Activity diagram) T Manavis

18 Data Flow Diagrams are: Used to perform structured analysis to determine logical requirements (analysis stage) A graphical tool, useful for communicating with users, managers, and other IS personnel Useful for analyzing proposed systems Find inefficiencies in current system and re-engineer current system A relatively simple technique to learn and use T Manavis

19 Reading a DFD T Manavis