1 Not just operating systems The basic issue 7 8 Developing - PDF document

1 2 Lecture 26: Introduction to Programming From Programming to Bertrand Meyer Software Engineering Last revised 2 February 2004 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Software engineering (1) Software engineering (2) 3 4 The processes, methods, techniques, tools The processes, methods, techniques, tools and languages for developing quality and languages for developing quality operational software. operational software that may need to � Be of large size � Be developed and used over a long period � Involve many developers � Undergo many changes and revisions Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Operating systems: source lines Not just Windows 5 6 Windows XP: > 45 M Windows XP: > 45 M Lines of code (millions) Lines of code (millions) 40 Windows 2000: 40 M 40 Windows 2000: 40 M Red Hat 7.1 30 M 30 30 20 20 Windows 98: 18 M Windows 98: 18 M Unix V7: Windows 95: 15 M Windows 95: 15 M Red Hat 6.2 10,000 Solaris 7: 12 Mio. 17 M 10 10 Windows NT: 4 M Windows NT: 4 M Windows 3.1: 3 M Windows 3.1: 3 M 2 2 1990 1990 1992 1995 1998 2000 Linux: 10,000 1995 1998 2000 1992 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 1

Not just operating systems The basic issue 7 8 Developing software systems that are � On time and within budget � Of high immediate quality � Possibly large and complex � Extendible Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 US Software industry, 1998 NIST report on testing (May 2002) 9 10 � Financial Standish Group: “Chaos” Report consequences, on developers and users, 250,000 Software projects, $275 billions of “insufficient testing infrastructure” � Project results: $ 59.5 B. � 28% abandoned (1994: 31% ) � 27% successful (1994: 16% ) (Finance $ 3.3 B, Car and aerospace $ 1.8 B. etc.) The rest: “challenged” � Smaller projects have higher chances of success Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Software quality factors Some internal factors 11 12 � External: of interest to customers � Modularity � Exam ples: Reliability, Extendibility � Observation of style rules � Consistency � Internal: of interest to customers � Structure � Exam ples: Modularity, Style � ... Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 2

External factors: reliability Reliability 13 14 Correctness Correctness Integrity Correctness Robustness Integrity Specification Errors Hostility Specification Errors Hostility � Correctness The system’s ability to perform its functions according to the specification, in cases covered by the specification � Robustness Reliability = Correctness + Robustness + Integrity The system’s ability to handle erroneous cases safely � Integrity The system’s ability to protect its users, its data and itself against hostile uses Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 External factors Software tasks 15 16 Product quality (immediate): � Requirements analysis � Reliability � Specification � Efficiency � Ease of use � Design � Ease of learning � Implementation Process quality: � Timeliness � Validation & Verification (V&V) � Cost-effectiveness � Management � Planning and estimating Product quality (long term): � Extendibility � Measurement � Reusability � Portability Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Validation & Verification Requirements analysis 17 18 � Verification: checking that you have built � Understanding user needs the system right � Understanding constraints on the system (followed all rules) � Validation: checking that you have built the right system (satisfied user needs) Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 3

Software lifecycle models The waterfall model (Royce, 1970) 19 20 Describe an overall distribution of the FEASIBILITY STUDY software construction into tasks, and the REQUIREMENTS ANALYSIS ordering of these tasks SPECIFICATION GLOBAL DESIGN They are models in two ways: � Provide an abstracted version of reality DETAILED DESIGN IMPLEMENTATION � Describe an ideal scheme, not always VALIDATION & followed in practice VERIFICATION DISTRIBUTION PROJECT PROGRESS Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Lifecycle: what not to achieve The waterfall model 21 22 FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN As Management requested it As the Project Leader defined it As Systems designed it DETAILED DESIGN IMPLEMENTATION VALIDATION & VERIFICATION DISTRIBUTION As Programming developed it As Operations installed it What the user wanted PROJECT PROGRESS (Pre-1970 cartoon; origin unknown) Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 A more realistic version The spiral model 23 24 � Apply a waterfall-like approach to successive prototypes FEASIBILITY STUDY REQUIREMENTS ACCEPTANCE ANALYSIS TESTING Iteration 3 GLOBAL DESIGN SYSTEM TESTING DETAILED DESIGN UNIT TESTING Iteration 1 IMPLEMENTATION Iteration 2 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 4

Seamless, incremental development The problem with prototyping 25 26 � Software development is hard because of The Eiffel view: the need to reconcile conflicting criteria, � Single set of notation, tools, concepts, principles e.g. portability and efficiency throughout � A prototype typically sacrifices some of � Eiffel is as m uch for analysis & design as for these criteria im plementation & maintenance � Continuous, incremental development � Risk of shipping the prototype � Keep model, im plementation and documentation consistent � Reversibility: can go back and forth Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Seamless development (1) Seamless development (2) 27 28 TRANSACTION, PLANE, TRANSACTION, PLANE, Specification Specification CUSTOMER, ENGINE... CUSTOMER, ENGINE... STATE, USER_COMMAND... Design Example classes Example classes Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Seamless development (3) Seamless development (4) 29 30 TRANSACTION, PLANE, TRANSACTION, PLANE, Specification Specification CUSTOMER, ENGINE... CUSTOMER, ENGINE... STATE, USER_COMMAND... STATE, USER_COMMAND... Design Design HASH_TABLE, HASH_TABLE, Implementation Implementation LINKED_LIST... LINKED_LIST... TEST_DRIVER, ... V & V Example classes Example classes Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 5

Seamless development (5) Generalization 31 32 � Prepare for reuse � For example: TRANSACTION, PLANE, � Remove built-in lim its Specification CUSTOMER, ENGINE... � Remove dependencies on specifics of project STATE, USER_COMMAND... Design HASH_TABLE, � Improve documentation, contracts... Implementation LINKED_LIST... TEST_DRIVER, ... V & V � Few companies have the guts to provide Genera- the budget for this AIRCRAFT, ... lization Example classes Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Seamless development Reversibility 33 34 S S TRANSACTION, PLANE, Specification CUSTOMER, ENGINE... D STATE, USER_COMMAND... Design HASH_TABLE, I Implementation LINKED_LIST... TEST_DRIVER, ... V & V V Genera- AIRCRAFT, ... lization G Example classes Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 The cluster model Agile methods and extreme programming 35 36 � De-emphasize process and reuse S Cluster 1 D Cluster 2 I � Emphasize the role of tests to guide the S V D G development Cluster n I S D S V I D G I V V G G Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 Chair of Softw are Engineering I ntroduction to Programming – Lecture 26 6