lecture 1 - introduction and software process

Κεαφάλαιο 1 - Εισαγωγή - ∆ιαδικασία Λογισµικού ΤΗΜΜΥ - Α.Π.Θ.Τεχνολογία Λογισµικού

Περικλής Α. Μήτκας 1-1

Τεχνολογία Λογισµικού

Περικλής Α. Μήτκας - Ανδρέας ΣυµεωνίδηςΚαθηγητής Λέκτορας

Τοµέας Ηλεκτρονικής ΥπολογιστώνΤµήµα Ηλεκτρολόγων Μηχανικών

και Μηχανικών Υπολογιστών

8ο Εξάµηνο

20201212

ΑΠΘ

ΤΗΜΜΥ – 8ο εξάµηνο

Τεχνολογία Λογισµικού Περικλής Α. Μήτκας 2

Πού ανήκουµε

ΑΠΘ

ΤΗΜΜΥ

Τοµέας Ηλεκτρονικής Υπολογιστών

Εργαστήριο Επεξεργασίας Πληροφορίας και Υπολογισµών (ΕΠΥ)



Τι (µας αρέσει να) κάνουµε

Έρευνα Βάσεις ∆εδοµένων και ∆ιαχείριση Γνώσης

Εξόρυξη ∆εδοµένων (Data Mining)

Ευφυή Συστήµατα και Πράκτορες Λογισµικού (Software Agents)

Βιοπληροφορική (Bioinformatics)

Περιβαλλοντική Πληροφορική

Semantic Web



Τεχνολογία Λογισµικού - Εισαγωγή

Σχεδίαση, ανάπτυξη και συντήρηση

µεγάλων συστηµάτων λογισµικού

Ο όρος Software Engineering προτάθηκε

στα τέλη της δεκαετίας του ΄60

Τεχνολογία του Αφηρηµένου




Software Engineering


Mathematics PhysicsMaterialsScience

ElectricalEngineering

ComputerEngineering

ComputerScience

DiscreteMathematics

Software

Engineering


Software Engineering

Computer Engineering In general, it covers the design and construction

of computers and computer-based systems.

Software Engineering The application of engineering concepts, techniques, and

methods to the development of software systems.

Computer Science Draws on a strong theoretical foundation in mathematics,

statistics, and computing to develop new, cutting-edge

computing solutions.




Κλάδος της µηχανικής που πραγµατεύεται

τεχνικές, µεθοδολογίες, πρακτικές και

εργαλεία για την συστηµατική, µεθοδική και

ποσοτικοποιηµένη προδιαγραφή, σχεδίαση,

υλοποίηση, έλεγχο, και συντήρηση

συστηµάτων λογισµικού υψηλής ποιότητας και

εντός δεδοµένου προϋπολογισµού και χρόνου

εκτέλεσης

[IEEE Standard 610.12]




Πίνακας Περιεχοµένων Μαθήµατος

1. Εισαγωγή – ∆ιαδικασία Λογισµικού

2. ∆ιαχείριση Έργου

3. Απαιτήσεις Λογισµικού

4. Σχεδίαση Λογισµικού

5. Αξιοπιστία Λογισµικού

6. Εγκατάσταση Λογισµικού

7. Εξέλιξη και Συντήρηση Λογισµικού

8. Εργαλεία για την Ανάπτυξη Λογισµικού (CASE tools)

9. ∆ιασφάλιση Ποιότητας Λογισµικού

10. Πνευµατικά ∆ικαιώµατα Λογισµικού

11. Η ∆ιαδικασία Λογισµικού για Εφαρµογές Internet

12. Κώδικας ∆εοντολογίας Μηχανικών Λογισµικού





Εργασία Τεχνολογίας Λογισµικού

1. Σύστηµα Ηλεκτρονικών Εξετάσεων

2. Σύστηµα Ψηφιακής Γραµµατείας

3. Ψηφιακές Βιβλιοθήκες Μηχανικής και Τεχνολογίας

4. Σύστηµα Ηλεκτρονικής Έκδοσης Εισιτηρίων

• Οµαδική εργασία µε 3-4 παραδοτέα

• Ελάχιστος κώδικας

Τίτλοι θεµάτων 2001:



Θέµατα Εργασιών

1. Smart Car

2. ∆ιαχείριση αποθήκης

3. e-shop

4. ∆ιαχείριση στόλου οχηµάτων (Fleet Management)

5. Friends’ Place (διαδικτυακός τόπος παρέας)

Ενδεικτικά θέµατα 2008:


Θεµατολογία Εργασιών 2011


Το ΤΗΜΜΥ κόντρα στην κρίση

Serious social networking



Γιατί αγωνιζόµαστε

Για τη γνώση

Για το βαθµό

Για τα λεφτά

Για τη δόξα

DIFIOLOGUS

MAXIMUS




Οι νικητές του 2010 - Teleportation




Εισαγωγή - Περιεχόµενα

Προϊόντα λογισµικού

Η διαδικασία λογισµικού

Μοντέλα ανάπτυξης λογισµικού Το µοντέλο καταρράκτη

Το σπειροειδές µοντέλο του Boehm

Το µοντέλο πρωτοτυποποίησης (rapid prototyping)

Το µοντέλο λειτουργικής επαύξησης (incremental model)

Το ενοποιηµένο µοντέλο (unified model)

Παρατηρησιµότητα της διαδικασίας

Επαγγελµατική ευθύνη

Κώδικας ηθικής µηχανικών λογισµικού



Μεγάλα Έργα Λογισµικού

Οργάνωση Ολυµπιακών Αγώνων

Το σύστηµα TAXIS

Η αποστολή του Pathfinder στον Άρη

Microsoft Office

Εταιρεία κινητής τηλεφωνίας

Η τρίτη εργασία στο µάθηµα



Mars Pathfinder Mission

Ο Pathfinder προσεδαφίστηκε στον Άρη στις 4-7-1997





Το διάγραµµα της Μέδουσας



Το αρχικό διάγραµµα συστήµατος για το λογισµικό πτήσης

του Mars Pathfinder

Περικλής Α. Μήτκας 24

Medical data

Format: A

Level of detail: A

Medical data

Format: B

Level of detail: B

Medical data

Format: C

Level of detail: C


The second leading female cancer worldwide

< 9.4 < 17.2 < 23.6 < 33.7 < 82.6

GLOBOCAN2000

•Age standardise ed in cidence per 100,000 person years

28,548Europe

64,895Europe

230,000Worldwide

Deaths in 2000

470,600Worldwide

Incident cases in 2000

In Europe , 80 women die every day of cervical cancer

Cervical Cancer



Περικλής Α. Μήτκας 26CERTH/ITI 26

Medical data come in various forms

HPV Test +/-

Pap Test Class 1/2/3/4

MTHFR +/-

Colposcopy Normal/LCIN/HCIN

Diagnosis CIN 1/2/3, Ca

HPV Test +/-

Pap Test Class 1/2/3/4

MTHFR N/A

Colposcopy Normal/LCIN/HCIN


HPV Test +/-

Pap Test WNL, LCIN, HCIN, Ca

MTHFR +/-

Colposcopy N/A


Clinic 1

Clinic 2

Clinic 3

Common

Medical Data

Repository

Medical Inferencing


Medical

Expert

Developer

ASSIST Site

Doctor

Local

Administrator

Maintenance

Operator

ASSIST

platform

ASSIST Sites

Researchers

Helpdesk

Ethics Advisory

Board

ASSIST Environment





Programming is fun!

The joys of programming

1. The joy of building things

2. The pleasure of making things that

are useful to other people

3. Playing with complex puzzle-like

objects and see them work together

4. The joy of always learning. Every

program is different

5. The delight of working in such a

tractable medium

Not all is delight

1. You (the code) must be perfect

2. You are not the master. Other

people set the specs, control

resources and information

3. Dependability on other people’s

program

4. Designing grand concepts is fun;

finding little bugs isn’t

5. By the time you are done the

product may be obsolete

Not!




37

Προγραµµατισµός και Τεχνολογία Λογισµικού

• Περιορισμένου όγκου έργα

• Υλοποιημένα από μικρές ομάδες

• Με απλές λειτουργικές και μη

απαιτήσεις

• Για μια συγκεκριμένη εφαρμογή

• Με απλές αλλαγές

• Χρησιμοποιούνται για σχετικά

σύντομο διάστημα

• Έχουν μικρό σχετικά κόστος

• Έχουν μικρή σχετικά επιρροή

• Μεγάλου όγκου έργα

• Υλοποιημένα από πολλές ομάδες

• Με πολύπλοκες απαιτήσεις

• Οικογένειες εφαρμογών

• Με πολλές παράλληλες αλλαγές

• Χρησιμοποιούνται για πολλά

χρόνια

• Έχουν μεγάλο κόστος

• Έχουν μεγάλη επιρροή

Programming Engineering



Από το πρόγραµµα στο προϊόν

1

2

S1

S2

Πρόγραµµα

Προϊόν Λογισµικού

Γενικευµένη χρήση, Ελεγµένο,

Εγχειρίδιο χρήσης, Συντήρηση

Σύστηµα Λογισµικού

∆ιεπαφές.

Επικοινωνία µε το περιβάλλον

Τµήµα µεγαλύτερου συστήµατος.

Σχεδίαση και υλοποίηση εντός

περιορισµών κόστους, πόρων,

χρόνου.

Σύστηµα Λογισµικού

ως Προϊόν

x3 x3

x3x3

Κόστος



Οι οικονοµίες ΟΛΩΝ των ανεπτυγµένων χωρών

εξαρτώνται από το λογισµικό

Όλο και περισσότερα συστήµατα ελέγχονται από

λογισµικό

Η Τεχνολογία Λογισµικού ασχολείται µε θεωρίες,

µεθόδους και εργαλεία για την ποιοτική και

συστηµατική ανάπτυξη λογισµικού

Τα κονδύλια για τεχνολογία λογισµικού αποτελούν

ένα σηµαντικό ποσοστό του ΑΕΠ των προηγµένων

χωρών




Το κόστος του λογισµικού συχνά κυριαρχεί στο συνολικό κόστος του υπολογιστικού συστήµατος

Η συντήρηση και ενηµέρωση του λογισµικού κοστίζει περισσότερο από την ανάπτυξη. Για συστήµατα µε µεγάλη διάρκεια ζωής, το κόστος συντήρησης µπορεί να είναι πολλαπλάσιο του κόστους ανάπτυξης.

Ένας από τους στόχους της τεχνολογίας λογισµικού είναι και η οικονοµική ανάπτυξη λογισµικού

Κόστος λογισµικού

Συντήρηση

Λογισµικού

Ανάπτυξη ΛογισµικούΥλικό

1960 1980 2000

100%

50%

10%




41

Μέση Κατανοµή Κόστους

Object-Oriented and Classical Software Engineer 5th Edition, Schach (2002)



Προϊόντα Λογισµικού

Γενικής χρήσης Αυτόνοµα συστήµατα που παράγονται από µια εταιρεία και

πωλούνται στην αγορά για γενική χρήση

Ειδικής χρήσης (customized) Συστήµατα που παραγγέλλονται από συγκεκριµένο πελάτη και

αναπτύσσονται ειδικά γι’ αυτόν από κάποια εταιρεία

Τα προϊόντα γενικής χρήσης αποτελούν µεγαλύτερο

κοµµάτι του συνολικού κύκλου εργασιών αλλά

περισσότερη προσπάθεια αναλώνεται για την

ανάπτυξη προϊόντων ειδικής χρήσης



Επιθυµητές ιδιότητες λογισµικού

Ορθότητα Το λογισµικό πρέπει να λειτουργεί χωρίς λάθη και να κάνει αυτό για το οποίο

σχεδιάστηκε. No more, No less!

∆υνατότητα Συντήρησης Το λογισµικό πρέπει να µπορεί να εξελίσσεται και να προσαρµόζεται στις

νέες συνθήκες και απαιτήσεις των χρηστών

Αξιοπιστία Το λογισµικό δεν πρέπει να προκαλεί φυσική ή οικονοµική ζηµία σε

περίπτωση λάθους ή κατάρρευσης του συστήµατος

Απόδοση Το λογισµικό πρέπει να χρησιµοποιεί το υλικό του συστήµατος µε τον πιο

οικονοµικό και αποδοτικό τρόπο

Εύχρηστο και Φιλικό προς τον Χρήστη Το λογισµικό πρέπει να έχει το κατάλληλο περιβάλλον χρήστη (GUI)

και να συνοδεύεται από κατατοπιστικά και εύχρηστα εγχειρίδια χρήσης



Σηµασία των χαρακτηριστικών του προϊόντος

Η σχετική σηµασία αυτών των χαρακτηριστικών εξαρτάται από το προϊόν και το περιβάλλον στο οποίο θα λειτουργεί

Σε µερικές περιπτώσεις κάποιες ιδιότητες κυριαρχούν έναντι των υπολοίπων Π.χ., σε συστήµατα real-time όπου η ασφάλεια (ανθρώπων, δεδοµένων,

κλπ) προεξάρχει, τα πρωτεύοντα χαρακτηριστικά θα είναι η αξιοπιστία και η απόδοση

Το κόστος συνήθως αυξάνει εκθετικά όταν απαιτούνται πολύ υψηλά επίπεδα ενός ή και περισσοτέρων χαρακτηριστικών





Σχέση Κόστους-Απόδοσης

Κόστος

Απόδοση


Σύγκριση Προϊόντων

Τηλεόραση Computer Game

Κατασκευή –

Υλοποίηση

Υλικό, Υψηλό κόστος υλικών,

Απαιτείται εφοδιαστική αλυσίδα και

εργοστάσιο κατασκευής, απαιτείται

σχεδίαση, κάθε αντίγραφο έχει

κόστος, µικρές απαιτήσεις

εγκατάστασης και λειτουργίας

Άυλο, απαιτείται σχεδίαση, µικρότερο

κόστος κατασκευής

∆ιανοµή Φυσική, Απαιτείται πληρωµή Ηλεκτρονική/∆ιαδικτυακή, Μπορεί να

είναι δωρεάν

Χρήση Γενικός τρόπος χρήσης, παθητική

χρήση, δεν δηµιουργούνται

αντίγραφα

Εξατοµικευµένη χρήση, διαδραστικό,

αντιγράφεται εύκολα, εύκολη προστασία

από αντιγραφή

Εξέλιξη Όχι, µεγάλη διάρκεια ζωής,

χρονοβόρα εξέλιξη, ακριβότερη

επιδιόρθωση

Αναβάθµιση εύκολη, µικρότερη διάρκεια

ζωής, διαρκής εξέλιξη, εύκολη διόρθωση,

η εξέλιξη συνήθως κοστίζει




∆ιαδικασία λογισµικού (software process)

Γνωστή και ως Κύκλος Ζωής Λογισµικού

Ένα δοµηµένο σύνολο ενεργειών που απαιτούνται για την ανάπτυξη ενός συστήµατος λογισµικού

Ενδεικτικά περιλαµβάνει: Προδιαγραφές

Σχεδίαση

Υλοποίηση κώδικα Μικρό κοµµάτι της όλης διαδικασίας

Επικύρωση

Εγκατάσταση

Εξέλιξη

Οι δραστηριότητες ποικίλουν ανάλογα µε τον οργανισµό και τον τύπο του συστήµατος που υλοποιείται

Η διαδικασία πρέπει να ακολουθεί κάποιο συγκεκριµένο και σαφές µοντέλο για να µπορεί να ελέγχεται


50

Οι επί µέρους εργασίες στη ∆ιαδικασία

Λογισµικού κατά το ΙΕΕΕ Std 1074

∆ιαδικασία Λογισµικού (Software Process)





Χαρακτηριστικά της διαδικασίας

Κατανοήσιµη (Understandability) Είναι η διαδικασία σαφώς καθορισµένη και κατανοητή?

Παρατηρησιµότητα (Visibility) Είναι η πρόοδος της διαδικασίας εξωτερικά παρατηρήσιµη?

∆υνατότητα Υποστήριξης (Supportability) Μπορεί να υποστηριχθεί η διαδικασία µε εργαλεία CASE

(Computer-Aided Software Engineering) ?

Βαθµός Αποδοχής (Acceptability) Είναι η διαδικασία αποδεκτή από τους εµπλεκόµενους σε

αυτήν?



Χαρακτηριστικά της διαδικασίας

Αξιοπιστία (Reliability) Τα σφάλµατα στη διαδικασία γίνονται αντιληπτά πριν

να οδηγήσουν σε σφάλµατα στο προϊόν?

Ευρωστία (Robustness) Μπορεί να συνεχιστεί η διαδικασία αν εµφανιστούν απρόσµενα

προβλήµατα?

∆υνατότητα συντήρησης και εξέλιξης (Maintainability) Μπορεί να εξελιχθεί η διαδικασία για να ικανοποιήσει

τις νέες ανάγκες του οργανισµού?

Ταχύτητα (Rapidity)

Πόσο γρήγορα µπορεί να παραχθεί το προϊόν?



Μοντέλο διαδικασίας µηχανικού

Προδιαγραφή συστήµατος (Specification) Καθορισµός των απαιτήσεων και των περιορισµών του συστήµατος

Σχεδίαση (Design) Παράγεται ένα µοντέλο (µακέτα) του συστήµατος

Κατασκευή (Manufacture) Το σύστηµα υλοποιείται

Έλεγχος (Test) Ελέγχεται αν το σύστηµα ικανοποιεί τις προδιαγραφές

Εγκατάσταση ή Παράδοση (Installation) Το σύστηµα παραδίδεται στον πελάτη και επιδεικνύεται η σωστή

λειτουργία του

Συντήρηση (Maintenance) Τυχόν σφάλµατα του συστήµατος διορθώνονται



Μοντέλα διαδικασίας λογισµικού

Συνήθως οι προδιαγραφές είναι ελλιπείς

Τα όρια µεταξύ προδιαγραφής, σχεδίασης και κατασκευής είναι ασαφή

∆εν υπάρχει κάποια φυσική υλοποίηση του συστήµατος για τον έλεγχο καλής λειτουργίας

Το λογισµικό δεν φθείρεται ούτε σκουριάζει!Η συντήρηση δεν είναι τόσο απλή όσο η αντικατάσταση κάποιου ανταλλακτικού που χάλασε




55

Φάσεις Κύκλου Ζωής και τα µοντέλα τους

Υο-

συστήµατα

∆οµούνται µε

class...

class...

class...

ΠηγαίοςΚώδικας

Υλοποιούνται

από

ΑντικείµεναΠεδίουΛύσης

Πραγµατοποιούνται

µε

Αρχιτεκτονική

Συστήµατος

Σχεδίαση

ΣυστήµατοςΥλοποίηση Έλεγχος

Αντικείµενα

Πεδίου

Εφαρµογής

Εκφράζονται

από

ΠεριτώσειςΕλέγχου

?

Επαληθεύονται µε

class.... ?

Προδιαγραφές

Απαιτήσεων

ΜοντέλαΧρήσης

Ανάλυση


56

Μοντέλα Κύκλου Ζωής

Οι φάσεις του κύκλου ζωής είναι διαδικασίες

που εφαρµόζονται Είτε παράλληλα

Είτε µε κάποια συγκεκριµένη σειρά

Η εφαρµογή αυτών των διαδικασιών ορίζεται Από κάποιο συγκεκριµένο µοντέλο και από το πλαίσιο

(context) του έργου


57

∆ιαδικασία και Προϊόν

Μοντέλο

Κύκλου Ζωής

Έργο

Προϊόν

Μηχανικοί /

Χρήστες

Εργαλεία

Πρότυπο

Συµµετέχοντες

Αποτέλεσµα

Αυτοµατισµός


58

Μοντέλα Κύκλου Ζωής

Το µοντέλο του καταρράκτη (waterfall model)

Το µοντέλο πρωτοτυποποίησης

(rapid prototyping)

Το µοντέλο λειτουργικής επαύξησης

(incremental model)

Το σπειροειδές µοντέλο (spiral model)

Το ενοποιηµένο µοντέλο (unified model)





Γενικά µοντέλα για την διαδικασία λογισµικού

Μοντέλο καταρράκτη (waterfall model) Τα στάδια της προδιαγραφής και της σχεδίασης είναι ξεχωριστά

και διακριτά

Εξελικτική ανάπτυξη (evolutionary development) Η προδιαγραφή και η σχεδίαση αλληλοκαλύπτονται

Τυπικός µετασχηµατισµός (formal transformation) Από ένα µαθηµατικό µοντέλο οδηγούµαστε στην υλοποίηση του

συστήµατος

Ανάπτυξη µε βάση την ανακύκλωση λογισµικού Το σύστηµα συναρµολογείται από διαθέσιµα κοµµάτια



Μοντέλο καταρράκτη

Ορισµός

απαιτήσεων

Προδιαγραφές και

σχεδίαση λογισµικού

Υλοποίηση και

έλεγχος τµηµάτων

Ολοκλήρωση

και επικύρωση

Λειτουργία και

συντήρηση



Τα στάδια του καταρράκτη

Ανάλυση και ορισµός απαιτήσεων

Σχεδίαση συστήµατος και λογισµικού

Υλοποίηση και δοκιµές µονάδων

Ολοκλήρωση και δοκιµή συστήµατος

Λειτουργία και συντήρηση

Τα στάδια του καταρράκτη µπορούν να αυξοµειώνονται

ανάλογα µε το βαθµό διάσπασης της κάθε φάσης

Το µειονέκτηµα του µοντέλου είναι η δυσκολία

αλλαγών από τη στιγµή που θα ξεκινήσει η διαδικασία


62

Μοντέλο Καταρράκτη (Waterfall)

Χαρακτηρίζεται από

Σειριακά βήµατα (phases)

Ανάδραση ανάµεσα σε δύο γειτονικά βήµατα

Βασίζεται στην δηµιουργία προδιαγραφών σε κάθε βήµα

Προτερήµατα

Παραγωγή προδιαγραφών

∆ιευκολύνει την συντήρηση

Μειονεκτήµατα

Προδιαγραφές που δεν µπορούν να αλλάξουν στη πορεία δεν είναι ρεαλιστική παραδοχή

Ο Χρήστης συµµετέχει µόνο στην αρχή

Σειριακή και πλήρης ολοκλήρωση κάθε βήµατος δεν είναι πάντα ενδεδειγµένη

Η διαδικασία είναι δύσκολο να ελεγχθεί

Ό χρήστης βλέπει το προϊόν πολύ αργά στη διάρκεια της διαδικασίας




63

Μοντέλο Πρωτοτυποποίησης

Σχεδίαση πρωτότυπου ακολουθούµενου από το µοντέλο Καταρράκτη Το πρωτότυπο δεν είναι το προϊόν

Η Πρωτοτυποποίηση δεν πρέπει να είναι µέρος της σχεδίασης αλλά µόνο της συλλογής απαιτήσεων

Πλεονεκτήµατα Καλύτερη προδιαγραφή απαιτήσεων

Καλύτερη µελέτη σκοπιµότητας

Ο χρήστης συµµετέχει ενεργά στη διαδικασία συλλογής / µοντελοποίησης απαιτήσεων

Μειονεκτήµατα Περισσότερη εργασία απαιτείται για την

παραγωγή του πρωτότυπου

Λόγω χρονικών περιορισµών το πρωτότυπο γίνεται µέρος του συστήµατος



Μοντέλο εξελικτικής ανάπτυξης

Γνωστό και ως ∆ηµιουργία Πρωτοτύπου

(prototyping)

∆ηµιουργείται ένα πρωτότυπο του συστήµατος

και συνεχώς εξελίσσεται µέχρι να πάρει την

τελική του µορφή


65

Αυξητικό Μοντέλο

Σχεδίαση Υλοποίηση Έλεγχος Εγκατάσταση



Απ

αιτή

σεις

Έκδοση (Release) 1

Έκδοση 2

Έκδοση 3

Σε κάθε έκδοση προσθέτουµε και νέες λειτουργίες /

ποιοτικά χαρακτηριστικά από ένα προκαθορισµένο

σύνολο απαιτήσεων

• Πλεονεκτήµατα

- Σε κάθε έκδοση έχουµε ένα σύστηµα σε λειτουργία

- Καλύτερη διανοµή κόστους στο χρόνο

• Μειονεκτήµατα

- Οι απαιτήσεις δεν πρέπει να αλλάζουν


66

Εξελικτικό Μοντέλο

Design Coding Test DeploymentRequirements



Feedback

Έκδοση (Version) 1



Νέες εκδόσεις υλοποιούν νέες

απαιτήσεις που εξελίσσονται όσο το σύστηµα

υλοποιείται

• Πλεονεκτήµατα

- Συνεχής συµµετοχή του χρήστη

- Καλή διαχείριση κρίσης

• Μειονεκτήµατα

- Μπορεί να γίνει ράβε – ξήλωνε τύπος µοντέλου





Εξελικτική ανάπτυξη

Επικύρωση

Ανάπτυξη

Προδιαγραφή

Παράλληλες διεργασίες

Περιγραφή

σχήµατος

Αρχική έκδοση

Ενδιάµεσες

εκδόσεις

Τελική έκδοση




∆ύο µορφές

1. Exploratory prototyping

Η οµάδα εργασίας ξεκινά µε ένα σύνολο αρχικών προδιαγραφών

και συνεργάζεται µε τον πελάτη για την δηµιουργία του τελικού

συστήµατος. Συνήθως το αρχικό σύνολο περιλαµβάνει καλά

καθορισµένες προδιαγραφές.

2. Throw-away prototyping

"Πετάµε" ότι δεν δουλεύει

Ο στόχος είναι η κατανόηση των απαιτήσεων του συστήµατος.

Επιλέγεται όταν οι απαιτήσεις δεν είναι σαφείς και καθορισµένες

εκ των προτέρων.




Προβλήµατα Η διαδικασία δεν είναι καλά παρατηρήσιµη

Τα συστήµατα δεν είναι τόσο αυστηρά δοµηµένα

Συχνά απαιτούνται ειδικές γνώσεις

(π.χ. γλώσσες για rapid prototyping)

Εφαρµογή σε Μικρά και µεσαία διαδραστικά (interactive) συστήµατα

Τµήµατα µεγάλων συστηµάτων (π.χ. user interface)

Συστήµατα µε περιορισµένη διάρκεια ζωής



Μοντέλο τυπικού µετασχηµατισµού

Μαθηµατικοί µετασχηµατισµοί

Αποδείξεις ορθότητας των µαθηµατικών µετασχηµατισµών

Τυπική

περιγραφή

Τ1

Ρ1

R1

Τ2

Ρ2

R2 R3

Τ3

Ρ3

Τ3

Ρ4

Τελικό

σύστηµα

Μετάβαση από την περιγραφή στην υλοποίηση του

συστήµατος µέσα από διαδοχικούς µετασχηµατισµούς





∆ιαχείριση κινδύνου (Risk management)

Ίσως το κυριότερο καθήκον ενός διευθυντή είναι η

ελαχιστοποίηση του κινδύνου αποτυχίας

Ο ενδεχόµενος κίνδυνος µιας ενέργειας αποτελεί

και το µέτρο αβεβαιότητας του αποτελέσµατος αυτής

της ενέργειας

∆ραστηριότητες υψηλού κινδύνου (πχ ελληνικά οµόλογα)

προκαλούν υπερβάσεις κόστους αλλά και χρόνου

Ο κίνδυνος σχετίζεται άµεσα µε την ποσότητα και

ποιότητα της διαθέσιµης πληροφορίας.

Fact: Όσο λιγότερα στοιχεία (γνώση) έχουµε,

τόσο αυξάνει ο βαθµός επικινδυνότητας


Παράδειγµα εννοιών προστασίας

από εξωτερικούς κινδύνους

Όρος Περιγραφή

Πόρος Τα αρχεία κάθε ασθενούς που υποβάλλεται ή έχει υποβληθεί σε θεραπεία.

Έκθεση Ενδεχόμενα διαφυγόντα κέρδη από μελλοντικούς ασθενείς οι οποίοι

αποφεύγουν τη νοσηλεία διότι δεν εμπιστεύονται την κλινική στην

προστασία των δεδομένων τους. Οικονομικές απώλειες από πιθανή αγωγή

εκ μέρους του αθλητικού αστέρα. Απώλεια υπόληψης.

Ευπάθεια Ένα χαλαρό σύστημα κωδικών πρόσβασης που διευκολύνει τους χρήστες να

ορίζουν κωδικούς πρόσβασης οι οποίοι μπορούν να προβλεφθούν εύκολα.

Αναγνωριστικά χρηστών που είναι ίδια με τα ονόματά τους.

Επίθεση Πλαστοπροσωπία σε βάρος ενός εξουσιοδοτημένου χρήστη.

Απειλή Ένας μη εξουσιοδοτημένος χρήστης θα αποκτήσει πρόσβαση στο σύστημα

μαντεύοντας τα διαπιστευτήρια ενός εξουσιοδοτημένου χρήστη (όνομα

σύνδεσης και κωδικό πρόσβασης).

Μέτρο Ένα σύστημα ελέγχου κωδικών πρόσβασης το οποίο δεν θα επιτρέπει στους

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

οποίες περιλαμβάνονται σε κάποιο λεξικό.


Προκαταρκτική αξιολόγηση κινδύνων


Ανάλυση πόρων

Πόρος Αξία Βαθμός έκθεσης

Το

πληροφοριακό

σύστηµα

Υψηλή. Είναι απαραίτητο για την

υποστήριξη όλων των κλινικών

διαγνώσεων. Ενδεχοµένως κρίσιµο

από άποψη ασφάλειας.

Υψηλός. Οικονομικές απώλειες, καθώς

μπορεί να απαιτηθεί η διακοπή της

λειτουργίας κάποιων κλινικών. Κόστος για

την αποκατάσταση του συστήματος.

Πιθανή βλάβη για τους ασθενείς, αν κάποια

θεραπεία δεν μπορεί να συνταγογραφηθεί.

Η βάση

δεδοµένων των

ασθενών

Υψηλή. Είναι απαραίτητη για την

υποστήριξη όλων των κλινικών

διαγνώσεων. Ενδεχοµένως κρίσιµη

από άποψη ασφάλειας.

Υψηλός. Οικονομικές απώλειες, καθώς

μπορεί να απαιτηθεί η διακοπή της

λειτουργίας κάποιων κλινικών. Κόστος για

την αποκατάσταση του συστήματος.

Πιθανή βλάβη για τους ασθενείς, αν κάποια

θεραπεία δεν μπορεί να συνταγογραφηθεί.

Τα ατοµικά

ιστορικά των

ασθενών

Συνήθως χαµηλή, αν και µπορεί να

είναι υψηλή για συγκεκριµένους

ασθενείς υψηλού προφίλ.

Μικρές άμεσες απώλειες, αλλά πιθανή

απώλεια υπόληψης.




Ανάλυση απειλών

και µέτρων προστασίαςΑπειλή Πιθαν. Μέτρο προστασίας Επιτευξιμότητα

Μη εξουσιοδοτημένος

χρήστης αποκτά

πρόσβαση ως

διαχειριστής συστήματος

και καθιστά το σύστημα

μη διαθέσιμο

Χαμηλή Η χρήση του συστήματος με

διαχειριστικά προνόμια να

επιτρέπεται μόνο από

συγκεκριμένους χώρους οι

οποίοι διαθέτουν φυσική

προστασία.

Χαμηλό κόστος υλοποίησης,

αλλά πρέπει να ληφθεί

μέριμνα σχετικά με τη

διανομή των κλειδιών και να

διασφαλιστεί ότι τα κλειδιά

θα είναι διαθέσιμα σε

περίπτωση επείγουσας

ανάγκης.

Μη εξουσιοδοτημένος

χρήστης αποκτά

πρόσβαση ως χρήστης

συστήματος και

προσπελάζει

εμπιστευτικές

πληροφορίες

Υψηλή Πιστοποίηση ταυτότητας

όλων των χρηστών με τη

χρήση βιομετρικών

μηχανισμών.

Λύση τεχνικά εφικτή αλλά με

υψηλό κόστος. Πιθανή

αντίδραση των χρηστών.

Καταγραφή κάθε αλλαγής

που πραγματοποιείται σε

πληροφορίες ασθενούς, για

την παρακολούθηση της

χρήσης του συστήματος.

Απλή και διαφανής στην

υλοποίηση, και υποστηρίζει

επίσης τη δυνατότητα

ανάκτησης.



Προβλήµατα κινδύνου µε τα µοντέλα διαδικασίας

Καταρράκτης Υψηλός κίνδυνος για νέα συστήµατα εξ αιτίας προβληµάτων στις

φάσεις προδιαγραφής και σχεδίασης

Ο κίνδυνος είναι σηµαντικά χαµηλότερος κατά την ανάπτυξη

συστηµάτων που βασίζονται σε δοκιµασµένες τεχνικές

∆ηµιουργία Πρωτοτύπων Χαµηλού κινδύνου για νέες εφαρµογές γιατί η περιγραφή και η

υλοποίηση του συστήµατος συµβαδίζουν

Υψηλού κινδύνου γιατί δεν είναι εύκολα παρατηρήσιµη η διαδικασία

Μετασχηµατισµός Ο κίνδυνος είναι υψηλός γιατί απαιτεί χρήση προχωρηµένης

τεχνολογίας και ειδικές γνώσεις από το προσωπικό



Υβριδικά µοντέλα διαδικασίας

Τα µεγάλα συστήµατα συνήθως µπορούν να διασπαστούν σε µικρότερα υποσυστήµατα

∆εν είναι απαραίτητο να χρησιµοποιηθεί η ίδια διαδικασία σε όλα τα υποσυστήµατα

Εποµένως διαλέγουµε:

Το εξελικτικό µοντέλο για υψηλού κινδύνου προδιαγραφές

Το µοντέλο του καταρράκτη για υποσυστήµατα µε καλά κατανοητές από προηγούµενη ανάπτυξη απαιτήσεις



Το σπειροειδές µοντέλο της

διαδικασίας λογισµικού κατά Boehm

Μοντέλο που υλοποιεί µια επαναληπτική

διαδικασία

Επιβάλλει την ανάλυση του ενδεχόµενου

κινδύνου σε κάθε βήµα της διαδικασίας





Determine objectives,

alternatives and

constraints

Evaluate alternatives,

identify and resolve

risks

Develop, verify

next-level productPlan next phase

Risk

analysis

Risk

analysis

Risk

analysis

Risk

analysisProto-

type 1

Prototype

2

Prototype

3

Operational

Prototype

Simulations, models,

benchmarks

Product

design

S / W

Requirements

Requirement

validation

Design

V & V

Detailed

design

Code

REVIEW

Requirements plan

Life-cycle planConcept of

Operation

Unit test

Integration

testAcceptance

testService

Development

plan

Integration

and test plan

Το σπειροειδές µοντέλο της

διαδικασίας λογισµικού κατά Boehm


80

Spiral model

Ουσιαστικά είναι το µοντέλο πρωτοτυποποίησης όπου στο

τέλος κάθε βήµατος κάνουµε έλεγχο σκοπιµότητας και

ανάλυση ρίσκου.

Πρωτοτυποποίηση για εφαρµογές υψηλού ρίσκου

Εάν η ανάλυση ρίσκου αποτύχει, τότε το έργο διακόπτεται.

Το σπειροειδές µοντέλο είναι πιο κατάλληλο για µεγάλα

έργα λόγω του µεγαλύτερου κόστους διαχείρισης.

Αν το έργο έχει ήδη προχωρήσει πολύ, είναι δύσκολο να

τερµατιστεί ακόµη κι αν η ανάλυση ρίσκου αποτύχει.


Σπειροειδές Μοντέλο (Boehm 1988)

ΕΠΙΣΚΟ-

ΠΗΣΗ

Ανά-λυσηρίσκου

Ανάλυσηρίσκου



Αξιολόγηση Εναλλακτικών Λύσεων, Μείωση Κινδύνου

Πρω-τότυπο1



ΤελικόΠρω-τότυπο

Εξομοιώσεις, μοντέλα, μετρήσεις

Αρχική

ιδέα Απαιτήσειςαπό S/W Σχεδίαση

S/W ΛεπτομερήςΣχεδίαση

Πλάνο Κύκλου Ζωής

Πλάνο Ανάπτυξης

Πλάνο ολοκλήρωσηςκαι ελέγχου

Καθορισμός ΣτόχωνΕναλλακτικώνΠεριορισμών

ΣχεδιασμόςΕπόμενης φάσης

Ανάπτυξηκαι Επικύρωση

ΕπικύρωσηΑπαιτήσεων

Έλεγχος Κώδικας

Ελεγχος Μονάδας

Ελεγχοςσυστήματος

Απαιτήσεις

Προϋπολογισμός 1

Περ

ιορ

ισμ

οί 1



Φάσεις του σπειροειδούς µοντέλου

1. Καθορισµός στόχων (Objective setting) Καθορίζονται οι συγκεκριµένοι στόχοι της παρούσας φάσης

2. Ανάλυση και µείωση κινδύνου

(Risk assessment and reduction) Αναγνωρίζονται και αναλύονται οι βασικότεροι κίνδυνοι και συλλέγονται

πληροφορίες για την καλύτερη αντιµετώπισή τους

3. Ανάπτυξη και επικύρωση (Development and validation) Επιλέγεται το καταλληλότερο µοντέλο για την φάση της ανάπτυξης

4. Σχεδιασµός της επόµενης φάσης (Planning) Το έργο αναθεωρείται και σχεδιάζεται ο επόµενος γύρος της σπείρας





Φόρµα εισαγωγής στοιχείων

για µια σπειροειδή περιστροφή

Στόχοι (Objectives)

Περιορισµοί (Constraints)

Εναλλακτικές λύσεις (Alternatives)

Κίνδυνοι (Risks)

Αντιµετώπιση κινδύνων (Risk resolution)

Αποτελέσµατα (Results)

Σχέδια (Plans)

∆έσµευση (Commitment)



Παράδειγµα 1: Βελτίωση ποιότητας

Στόχος Σηµαντική βελτίωση της ποιότητας του λογισµικού

Περιορισµοί Σε τρία χρόνια

Χωρίς να απαιτηθεί άντληση µεγάλων κεφαλαίων

Χωρίς ριζικές αλλαγές στην τυποποίηση της εταιρείας

(company standards)

Εναλλακτικές λύσεις Ανακύκλωση του υπάρχοντος πιστοποιηµένου λογισµικού

Εισαγωγή αυστηρών προδιαγραφών και κανόνων επαλήθευσης

Βελτίωση του ελέγχου και της επικύρωσης του λογισµικού



Κίνδυνοι Μπορεί να µην υπάρχει οικονοµικά αποδοτική βελτίωση

Οι βελτιώσεις µπορεί να επιφέρουν υπέρογκη αύξηση κόστους

Η εφαρµογή νέων µεθόδων µπορεί να οδηγήσει σε παραιτήσεις

Αντιµετώπιση κινδύνων Έρευνα βιβλιογραφίας

Πιλοτικό πρόγραµµα

Αναζήτηση τµηµάτων λογισµικού που µπορούν να ξαναχρησιµοποιηθούν

Εκτίµηση υποστήριξης από διαθέσιµα εργαλεία

Σεµινάρια για επιµόρφωση προσωπικού




Αποτελέσµατα Η εµπειρία σε µαθηµατικές µεθόδους είναι περιορισµένη –

πολύ δύσκολα µπορούν να µετρηθούν οι βελτιώσεις

Η υποστήριξη εργαλείων είναι περιορισµένη για το τυπικό σύστηµα ανάπτυξης λογισµικού της εταιρείας

Υπάρχουν ανακυκλώσιµα τµήµατα αλλά η υποστήριξη µε εργαλεία ανακύκλωσης είναι ελάχιστη

Σχέδια Να διερευνηθεί η επιλογή ανακύκλωσης σε βάθος

Να αναπτυχθούν πρωτότυπα εργαλεία για υποστήριξη ανακύκλωσης

Να διερευνηθεί η δυνατότητα πιστοποίησης τµηµάτων λογισµικού

∆έσµευση Περαιτέρω χρηµατοδότηση 18-µηνης µελέτης






Παράδειγµα 2: Κατάλογος Λογισµικού

Στόχος ∆ηµιουργία ηλεκτρονικού καταλόγου εξαρτηµάτων λογισµικού

Περιορισµοί Σε ένα χρόνο

Τα υπάρχοντα εξαρτήµατα πρέπει να υποστηρίζονται

Συνολικό κόστος κάτω από €100.000

Εναλλακτικές λύσεις Αγορά υπάρχοντος λογισµικού για ανάκληση πληροφορίας

(information retrieval software)

Αγορά βάσης δεδοµένων και ανάπτυξη του καταλόγου σε αυτό το περιβάλλον

Ανάπτυξη καταλόγου ειδικής (δικής µας) χρήσης



Κίνδυνοι Μπορεί να είναι αδύνατη η ανάπτυξη εντός των περιορισµών

Η λειτουργικότητα του καταλόγου µπορεί να µην είναι η επιθυµητή

Αντιµετώπιση κινδύνων Ανάπτυξη πρωτοτύπου καταλόγου µε χρήση κάποιας γλώσσας

υψηλού επιπέδου και ενός διαθέσιµου συστήµατος διαχείρισης

βάσεων δεδοµένων (Σ∆Β∆) για να καθοριστούν οι απαιτήσεις του

συστήµατος

∆ιερεύνηση των δυνατοτήτων των υπαρχόντων συστηµάτων

ανάκλησης πληροφορίας

Χαλάρωση του χρονικού περιορισµού




Αποτελέσµατα Τα συστήµατα ανάκλησης πληροφορίας δε µπορούν να

ικανοποιήσουν τις ανάγκες του προϊόντος

Το πρωτότυπο µε χρήση Σ∆Β∆ µπορεί µε βελτιώσεις να οδηγήσει

σε ολοκληρωµένο σύστηµα

Η ανάπτυξη του δικού µας καταλόγου δεν είναι οικονοµικά

αποδοτική

Σχέδια Να αναπτυχθεί κατάλογος µε το υπάρχον Σ∆Β∆ βελτιώνοντας το

πρωτότυπο και το user interface

∆έσµευση Χρηµατοδότηση της ανάπτυξης για 12 µήνες




Πόσο παρατηρήσιµη είναι η διαδικασία;

Fact:Τα συστήµατα λογισµικού είναι άυλα και δυσνόητα.Γι αυτό οι διευθυντές χρειάζονται διάφορα έγγραφα για να κρίνουν την πρόοδο

Όµως ανακύπτουν κάποια προβλήµατα

Το χρονοδιάγραµµα των αναφορών προόδου µπορεί να διαφέρει από το πραγµατικό χρονοδιάγραµµα υλοποίησης

Η ανάγκη παραγωγής αναφορών µπορεί να περιορίσει τον αριθµό των επαναλήψεων της διαδικασίας

Ο χρόνος που καταναλώνεται για τον έλεγχο και την έγκριση των αναφορών είναι σηµαντικός

Fact:Το µοντέλο του καταρράκτη παραµένει το δηµοφιλέστερο από τα µοντέλα που παράγουν παραδοτέα σε τακτά χρονικά διαστήµατα





Απαιτούµενα έγγραφα στο µοντέλο του καταρράκτη

∆ιεργασία Παραγόµενα έγγραφα

Ανάλυση απαιτήσεων Μελέτη σκοπιµότητας, Σχέδιο απαιτήσεων

Ορισµός απαιτήσεων Έγγραφο απαιτήσεων

Προδιαγραφή συστήµατος Προδιαγραφές λειτουργίας, Σχέδιο ελέγχου αποδοχής,

Προσχέδιο εγχειριδίου χρήσης

Αρχιτεκτονική σχεδίαση Προδιαγραφές αρχιτεκτονικής, Σχέδιο ελέγχου συστήµατος

Σχεδίαση διεπαφής Προδιαγραφές διεπαφής, Σχέδιο ελέγχου ολοκλήρωσης

Λεπτοµερής σχεδίαση Προδιαγραφές σχεδίασης, Σχέδιο ελέγχου µονάδας

Συγγραφή κώδικα Κώδικας προγράµµατος

∆οκιµή µονάδας Αναφορά ελέγχου µονάδας

∆οκιµή υποσυνόλου µονάδων Αναφορά ελέγχου υποσυνόλου µονάδων

∆οκιµή ολοκλήρωσης Αναφορά ελέγχου ολοκλήρωσης, Τελικό εγχειρίδιο χρήσης

∆οκιµή συστήµατος Αναφορά ελέγχου συστήµατος

Έλεγχος τελικής αποδοχής Τελικό σύστηµα µαζί µε τα απαιτούµενα έγγραφα



Παρατηρησιµότητα µοντέλων διαδικασίας

Μοντέλο Παρατηρησιµότητα διαδικασίας

Καταρράκτης Καλή παρατηρησιµότητα

Kάθε διεργασία παράγει κάποια παραδοτέα

Εξελικτική Ανάπτυξη Χαµηλή παρατηρησιµότητα

H παραγωγή εγγράφων κατά την διάρκεια των

συχνών επαναλήψεων δεν είναι οικονοµικά

συµφέρουσα

Μετασχηµατισµοί Καλή παρατηρησιµότητα

Aπαραίτητη η παραγωγή εγγράφων σε κάθε φάση

για τη συνέχιση της διαδικασίας

Ανάπτυξη µε

ανακύκλωση

Μέση παρατηρησιµότητα

∆εν έχει πάντα νόηµα η παραγωγή εγγράφων που

περιγράφουν την ανακύκλωση και τα ανακυκλούµενα

τµήµατα

Σπειροειδές µοντέλο Καλή παρατηρησιµότητα. Κάθε τµήµα και κάθε

δακτύλιος της σπείρας πρέπει να παράγει έγγραφα


93

Εξελικτικά Μοντέλα του Σήµερα

Ενοποιηµένο Μοντέλο

Rational Unified Process (RUP)

Μοντέλο Extreme Programming (XP)


94

Κύρια Χαρακτηριστικά RUP

Εξελικτικό µοντέλο µε ανάδραση

Καθοδηγείται από σενάρια χρήσης (use cases)

Είναι αρχιτεκτονικο-κεντρικό µοντέλο (4+1 άποψεις – views)

Χρησιµοποιεί την UML σαν γλώσσα µοντελοποίησης

Πλούσιο πλαίσιο υποστήριξης της διαδικασίας




95

Ενοποιηµένο Μοντέλο RUP - Έννοιες

Εργαζόµενος(οι)

Ένα άτοµο ή µία οµάδα ατόµων µε συγκεκριµένο ρόλο στην

ανάπτυξη λογισµικού

∆ραστηριότητα (activity)

Μια συγκεκριµένη εργασία που εκτελείται κατά την ανάπτυξη

λογισµικού

Συστατικό στοιχείο λογισµικού (artifact)

Ένα αποτέλεσµα της εκτέλεσης µιας εργασίας

Ροή εργασιών (workflow)

Μια αλληλουχία δραστηριοτήτων


96

Ενοποιηµένο Μοντέλο RUP - Έννοιες

Βασικές ροές:

Μοντελοποίηση επιχειρησιακού περιβάλλοντος (Business Modeling)

Συγγραφή προδιαγραφών (Requirements)

Ανάλυση και σχεδίαση (Architecture and Design)

Υλοποίηση (Implementation)

Ελεγχος (Test)

Εγκατάσταση (Deployment)

Φάσεις:

Έναρξη (Inception)

Επεξεργασία (Elaboration)

Κατασκευή (Construction)

Μετάβαση (Transition)

Ροές υποστήριξης:

∆ιοίκηση σχηµατισµών λογισµικού (Configuration Management)

∆ιοίκηση έργου (Project Management)

∆ιαχείριση περιβάλλοντος ανάπτυξης (Development Environment Management)


97

Inception Elaboration Construction Transition

RUP Φάσεις

Tο µοντέλο RUP έχει τέσσερις φάσεις στο χρόνο:

1. Έναρξη (Inception) – Ορισµός του έργου και της έκτασής του

2. Επεξεργασία (Elaboration) – Κατάστρωση µεθόδου υλοποίησης του

έργου, µοντελοποίηση χαρακτηριστικών του έργου, ορισµός της

αρχιτεκτονικής του συστήµατος

3. Κατασκευή (Construction) – Υλοποίηση του έργου

4. Μετάβαση (Transition) – Ανάπτυξη του συστήµατος στο περιβάλλον

χρήσης του

time


98

RUP Overview

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 TransitionInception Construction

Workflows group

activities logically

In an iteration,

you walk through

all workflows




99

Σύνοψη του Μοντέλου XP

Βασικά Χαρακτηριστικά

Εξελικτική µέθοδος υλοποίησης

Εστιάζει σε κώδικα που είναι πάντα

λειτουργικός και υλοποιεί

συγκεκριµένες απαιτήσεις και

ανάγκες του χρήστη

Ο συνεχής έλεγχος του κώδικα είναι

σηµαντικό συστατικό της διαδικασίας

Εστιάζει στην ευελιξία και

λειτουργικότητα της διαδικασίας

Υλοποιείται συνήθως από µικρές

οµάδες (<10)

Κάθε ηµέρα

Κάθε 2-3

εβδοµάδες

Write tests

Planning

Test

Pair Programming

+ Refactoring

Integration

Release


100

Σύνοψη του Μοντέλου XP

Συλλογή από “12 Καλύτερες Πρακτικές”

Fine scale feedback

1. Pair programming

2. Planning Game

3. Test Driven Development

4. Whole team

Continuous process

5. Continuous Integration

6. Design Improvement

7. Small Releases

Shared understanding

8. Coding Standards

9. Collective Code Ownership

10. Simple Design

11. System Metaphor

Programmer welfare

12. Sustainable Pace Κάθε ηµέρα

Κάθε 2-3

εβδοµάδες

Write tests

Planning

Test

Pair Programming

+ Refactoring

Integration

Release


101

Άλλα Μοντέλα

Άλλα Μοντέλα που σχετίζονται µε τα Μοντέλα

Κύκλου Ζωής και την Αναµενόµενη Ποιότητα

Λογισµικού είναι:

ISO 9000

Aφορά στην διασφάλιση της ποιότητας προϊόντων και

υπηρεσιών.

Capability Maturity Model (CMM)

Αφορά στη σύνδεση της διαδικασίας µε την αναµενόµενη

ποιότητα του προϊόντος.


102

Μοντέλο Επιπέδων Ωριµότητας

Capability Maturity Model

1: Αρχικό (Initial)

2: Επαναλαµβανόµενο (Repeatable)

3: Καθορισµένο (Defined)

4: ∆ιαχειριζόµενο (Managed)

5: Βελτιούµενο (Optimizing)




103

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


Κώδικας δεοντολογίας ACM/IEEE

Οι µεγάλες επαγγελµατικές/επιστηµονικές ενώσεις των ΗΜΜΥ,

Association of Computing Machinery (ACM) και IEEE,

έχουν διαµορφώσει έναν κοινό κώδικα δεοντολογίας και

επαγγελµατικής πρακτικής.

Τα µέλη των οργανισµών αυτών αποδέχονται την υποχρέωση να

τηρούν τον αντίστοιχο κώδικα κατά την υποβολή της αίτησης

εγγραφής τους.

Ο Κώδικας περιλαµβάνει οκτώ Αρχές που (πρέπει να) διέπουν τη

συµπεριφορά και τις αποφάσεις των µηχανικών λογισµικού,

συµπεριλαµβανοµένων:

των επαγγελµατιών µηχανικών,

των διευθυντών, των εποπτών και των υπευθύνων χάραξης πολιτικής,

των εκπαιδευτών καθώς και των εκπαιδευόµενων και φοιτητών του

επαγγέλµατος.



Kώδικας ∆εοντολογίας και Άσκησης

Επαγγέλµατος για τους Μηχανικούς Λογισµικού

Πέρα από την αυτονόητη αφοσίωση στην υγεία, την ασφάλεια και την ευηµερία του κοινού, οι µηχανικοί λογισµικού (ΜΛ) θα εµµένουν στις εξής οκτώ αρχές :

1. ∆ηµόσιο Συµφέρον. Οι ΜΛ θα ενεργούν µε συνέπεια προς το δηµόσιο συµφέρον.

2. Πελάτης και Εργοδότης. Οι ΜΛ θα ενεργούν σύµφωνα µε το συµφέρον του πελάτη και του

εργοδότη, λαµβάνοντας υπ’ όψιν το δηµόσιο συµφέρον.

3. Προϊόν. Οι ΜΛ θα διασφαλίζουν ότι τα προϊόντα τους και οι σχετικές τροποποιήσεις τους

ικανοποιούν τα υψηλότερα δυνατά επαγγελµατικά πρότυπα.

4. Κρίση. Οι ΜΛ θα διατηρούν την ακεραιότητα και ανεξαρτησία της επαγγελµατικής τους

κρίσης.

5. ∆ιοίκηση. Τα διοικητικά στελέχη και οι διευθύνοντες ΜΛ θα υποστηρίζουν και θα προωθούν

µια ηθική προσέγγιση στη διαχείριση της ανάπτυξης και συντήρησης λογισµικού.

6. Επάγγελµα. Οι ΜΛ θα προάγουν την ακεραιότητα και τη φήµη του επαγγέλµατος,

λαµβάνοντας υπ’ όψιν το κοινό συµφέρον.

7. Συνάδελφοι. Οι ΜΛ θα είναι δίκαιοι και θα υποστηρίζουν τους συναδέλφους τους.

8. Εαυτός. Οι ΜΛ θα συµµετέχουν σε δια βίου εκπαίδευση και θα προωθούν µια ηθική

προσέγγιση στην άσκηση του επαγγέλµατος.



Επαγγελµατική ευθύνη

Οι µηχανικοί λογισµικού δεν πρέπει να περιορίζονται

µόνο στα τεχνικά ζητήµατα.

Έχουν ευρύτερες ηθικές, κοινωνικές και

επαγγελµατικές ευθύνες.

Σε πολλές περιπτώσεις δεν είναι ξεκάθαρα τα

πράγµατα

Αµυντικά (!!) συστήµατα

Whistleblowing

Το συµφέρον του επαγγέλµατος του µηχανικού λογισµικού





Ηθικά ζητήµατα

Εµπιστευτικότητα

Ικανότητα

Πνευµατικά δικαιώµατα

Κατάχρηση ή κακή χρήση υπολογιστών

∆ηµόσια ή ιδιωτικά δεδοµένα

Άλλα?


Παραδείγµατα Ηθικών ∆ιληµµάτων

Computer Associates

Απέλυσε 10 υπαλλήλους που έστελναν e-mail µε

σεξουαλικά υπονοούµενα

XEROX

Απέλυσε 40 υπαλλήλους γιατί χρησιµοποιούσαν το

WEB υπερβολικά

Tα ΥΠΕΡ και τα ΚΑΤΑ


Συγκεκριµένα Ζητήµατα Ηθικής

Ιατρικά δεδομένα: Επιτρέπονται οι εξ αποστάσεως εγχειρήσεις με τη βοήθεια

τεχνολογίας?

Ποιος έχει την τελική ευθύνη για ανακρίβειες που εμφανίζονται σε electronic

boards?

Τα ηλεκτρονικά δεδομένα μπορούν να χρησιμοποιηθούν ως πειστήρια σε

δικαστήρια?

Είναι επιτρεπτή η ηλεκτρονική αναπαραγωγή ή η παραλλαγή ενός έργου

τέχνης?

Πόσο επιτρεπτή είναι η πώληση δεδομένων προσωπικών στοιχείων σε τρίτους?

Ποιος είναι υπεύθυνος αν ψευδή οικονομικά στοιχεία διαδοθούν μέσω του

Δικτύου και προκαλέσουν ζημιές σε επενδυτές?

Είναι αποδεκτό να δεχθούμε “cookie” όταν επισκεπτόμαστε το διαδίκτυο?

Ποιος έχει την ευθύνη των πράξεων ενός πράκτορα λογισμικού στο διαδίκτυο?


Η ευρωπαϊκή οδηγία για την

προστασία των δεδοµένων

Πολύ πιο αυστηρή από αυτή των Ηνωμένων Πολιτειών

Επιβάλλει στις εταιρίες να πληροφορούν το κοινό όταν

συγκεντρώνουν προσωπικά δεδομένα και να ανακοινώνουν

τον τρόπο αποθήκευσης και χρήσης τους

Οι πελάτες πρέπει να συναινέσουν μετά από την ενημέρωση

Δεν επιτρέπεται η διαβίβαση προσωπικών δεδομένων σε

τρίτες χώρες, π.χ. ΗΠΑ, που δεν έχουν παρόμοιους

κανονισμούς (Το Υπουργείο Εμπορίου των ΗΠΑ ανάπτυξε τον

«ασφαλή λιμένα» για τις αμερικάνικες εταιρίες)

Η Ελλάδα εναρμονίστηκε με την οδηγία εισάγοντας τον Νόμο

2472/97 (με προσθήκες αργότερα για INTERNET)





Βασικά σηµεία Η τεχνολογία λογισµικού πραγµατεύεται τις θεωρίες, µεθόδους και

εργαλεία για την ανάπτυξη, διαχείριση και εξέλιξη συστηµάτων λογισµικού

Τα προϊόντα λογισµικού περιλαµβάνουν προγράµµατα και τεκµηρίωση.

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

Η διαδικασία λογισµικού περιλαµβάνει τις διεργασίες για την ανάπτυξη του λογισµικού

Το µοντέλο καταρράκτη θεωρεί κάθε διεργασία σαν ξεχωριστή φάση

Η εξελικτική ανάπτυξη θεωρεί παράλληλες διεργασίες

Η ανάγκη για παρατηρησιµότητα της διαδικασίας υπαγορεύει τη δηµιουργία παραδοτέων από διάφορες διεργασίες

Οι µηχανικοί λογισµικού έχουν ηθικές, κοινωνικές και επαγγελµατικές ευθύνες

lecture 1 - introduction and software process

Documents

medical data

software process

unified model

software engineering

cin 123

user interface

incremental

spiral model