ch01.pdf

CP 317 Software Engineering Course Notes Chapter 1: Stephen R. Schach The Scope of Software Engineering Learning Objectives Defi ne what is meant by software engineering. Describe the classical software engineering life-cycle model. Explain why the object-oriented pa...

CP 317 Software Engineering Course Notes Chapter 1: Stephen R. Schach The Scope of Software Engineering Learning Objectives Defi ne what is meant by software engineering. Describe the classical software engineering life-cycle model. Explain why the object-oriented paradigm is now so widely accepted. Discuss the implications of the various aspects of software engineering. Distinguish between the classical and modern views of maintenance. Discuss the importance of continual planning, testing, and documentation. Appreciate the importance of adhering to a code of ethics. 2 Outline Historical aspects Economic aspects Maintenance aspects Requirements, analysis, and design aspects Team development aspects The object-oriented paradigm Terminology 3 1.1 Historical Aspects 1968 NATO Conference in Germany Aim: To solve the “software crisis”  Software products fail more often than other engineering products.  Software is delivered late, over budget, with residual faults NATO coined the term software engineering  They claimed that we can build software very similar to other engineering products. 4 Software Crises in 2000 Data on 280,000 projects completed in 2000, by Standish Group 5 Financial Implications 2002 survey of information technology organizations--- conducted by Cutter Consortium  78% have been involved in disputes ending in litigation For the organizations that entered into litigation:  In 67% of the disputes, the functionality of the information system did not meet its specifications. 6 1.2 Economic Aspects Coding method CMnew produces code in less than 90% of the time needed by the currently used method CMold. Should it be used? Common sense answer  Of course! Software Engineering answer  Consider the cost of training  Consider the impact of introducing a new tech  Consider the effect of CMnew on maintenance 7 1.3 Maintenance Aspects Maintenance is described in the context of software life cycle. Life-cycle model  The steps (phases) to follow when building software 8 Waterfall Life-Cycle Model Classical model (1970) 9 Typical Classical Phases Requirements phase  Explore the concept  Elicit the client’s requirements Analysis (specification) phase  Analyze the client’s requirements  Draw up the specification document  “What the product is supposed to do”  Draw up the software project management plan 10 Typical Classical Phases (contd) Design phase  Architectural design, followed by  Detailed design  “How the product does it” Implementation phase  Coding  Unit testing  Integration  Acceptance testing 11 Typical Classical Phases (contd) Postdelivery maintenance  Corrective maintenance Removal of residual faults  Perfective maintenance Adapting the s/w to new user requirements  Adaptive maintenance Adapting the s/w to new environment Retirement 12 Classical View of Maintenance Classical maintenance  Development-then-maintenance model Requirements phase Analysis phases Development Design phase Implementation phase Maintenance Postdelivery maintenance 13 Modern Maintenance Definition Maintenance is defined as  The process that occurs when a software artifact is modified regardless of whether this takes place before or after installation of the software product New definition given by ISO/IEC in 1995  ISO : Int’l Standards Organization  IEC : Int’l Electrotechnical Commission 14 Maintenance Terminology in The Textbook Postdelivery maintenance  Changes after delivery and installation [IEEE 1990] Modern maintenance (or just maintenance)  Corrective, perfective, or adaptive maintenance performed at any time [ISO/IEC 1995, IEEE/EIA 1998] The former is a subset of the latter 15 Cost of Postdelivery Maintenance (a) Between 1976 and 1981 (b) Between 1992 and 1998 16 The Costs of the Classical Phases Surprisingly, the costs of the classical “development” phases have hardly changed 17 Consequence of Relative Costs of Phases Return to CMold and CMnew Reducing the coding cost by 10% yields at most a 0.85% reduction in total costs 10%  34% (cod. cost)  25% (Dev. cost) = 0.85% Reducing postdelivery maintenance cost by 10% yields a 7.5% reduction in overall costs 10%  75% (Postdel. cost) = 7.5% 18 Requirements, Analysis, and Design Aspects The earlier we detect and correct a fault, the less it costs us 19 Requirements, Analysis, and Design Aspects (contd) The cost of detecting & correcting a fault at each phase Large projects Small projects 20 Requirements, Analysis, and Design Aspects (contd) To correct a fault early in the life cycle  Usually just a document needs to be changed To correct a fault late in the life cycle  Change the code and the documentation  Test the change itself  Perform regression testing  Reinstall the product on the client’s computers 21 Requirements, Analysis, and Design Aspects (contd) Between 60 and 70 percent of all faults in large-scale products are requirements, analysis, and design faults 22 Conclusion It is vital to improve our requirements, analysis, and design techniques  To find faults as early as possible  To reduce the overall number of faults (and, hence, the overall cost) 23 1.5 Team Programming Aspects Software is built by teams  Interfacing problems between modules  Communication problems among team members p (…) q (int r, double s, char t) { { … … q(double_var, int_var, … char_var); … { } 24 1.6 Why There Is No Planning Phase Why there is no separate planning phase, in the classical model? Planning activities are carried out throughout the life cycle We cannot plan at the beginning of the project—we do not yet know exactly what is to be built 25 Planning Activities of the Classical Paradigm Preliminary planning of the requirements and analysis phases at the start of the project The software project management plan (SPMP) is drawn up when the specifications have been signed off by the client  Budget  Staffing requirements  Detailed schedule 26  1.7 Why There Is No Testing Phase Why there is no testing phase after the product has been implemented? Because, it is far too late to test after development and before delivery There is no separate testing phase 27 Testing Activities of the Classical Paradigm Testing at phase boundaries comes in two flavors: Verification  Testing at the end of each phase  Test transition between subsequent phases Validation  Testing at the end of the project  Test to ensure user requirements fulfilled 28 Testing Software Quality This testing is the responsibility of  Every software professional, and  The Software Quality Assurance (SQA) group  SQA typically performs V&V testing The quality of software  is the extent to which it meets its specifications 29  1.8 Why There Is No Documentation Phase It is far too late to document after development and before delivery Documentation activities must be performed in parallel with all other development and maintenance activities 30 1.9 The Object-Oriented Paradigm Structured (classical) paradigm  Structured analysis techniques  Structured programming  Structured testing. Structured paradigm was successful initially  It started to fail with larger products Small-scale < 5000 LOCs Medium-scale < 50,000 LOCs Large-scale > 50,000 LOCs 31 The OO Paradigm (contd) Major reason for limited success of structured methods is  Action oriented (e.g., finite state machines, data flow diagrams); or  Data oriented (e.g., entity-relationship diagrams);  But not both press button MusicPlaying ProposeSelection do: play chosen selection State diagram for a jukebox 32 The OO Paradigm (contd) Both data and actions are equally important Object:  A software component that incorporates both data and the actions that are performed on that data Example: Bank account Data: account balance Actions: deposit, withdraw, determine balance 33 Information Hiding deposit withdraw message message account_ balance accountBalance determine_ determineBalance Classical balance OO version message In the object-oriented version  The solid line around accountBalance denotes that outside the object there is no knowledge of how accountBalance is implemented In the classical version  All the modules have details of the implementation of account_balance 34 Strengths of OO Paradigm With information hiding, postdelivery maintenance is safer  The chances of a regression fault are reduced Development is easier  Objects generally have physical counterparts  This simplifies modeling (a key aspect of the object-oriented paradigm) 35 Strengths of OO Paradigm (contd) Well-designed objects are independent units  Everything that relates to the real-world object being modeled is in the object — encapsulation  Implementation details are hidden from everything outside the object  Communication is by sending messages 36 Strengths of OO Paradigm (contd) A classical product conceptually consists of a single unit  The OO paradigm reduces complexity because the product consists of independent units The OO paradigm promotes reuse  Because objects are independent entities, they can be used in future products 37 Classical Phases vs Object-Oriented Workflows Terminological difference: phase vs. workflow Workflow: sequence of operations through which a piece of work is completed. 38 Analysis/Design “Hump” Structured paradigm:  There is a big difference between analysis (what) and design (how) Object-oriented paradigm:  Objects enter from the very beginning 39 Analysis/Design “Hump”(cont’d) In the classical paradigm  Classical analysis Determine what has to be done  Design Determine how to do it Architectural design — determine the modules Detailed design — design each module (data structures and algorithms) 40 Removing the “Hump” In the object-oriented paradigm  Object-oriented analysis Determine what has to be done Determine the objects (classes)  Object-oriented design Determine how to do it Design the objects The difference between the two paradigms is shown on the next slide 41 In More Detail Objects enter here; i.e, the architectural design is performed during the OO analysis 42 Object-Oriented Paradigm Modules (objects) are introduced as early as the object- oriented analysis workflow  This ensures a smooth transition from the analysis workflow to the design workflow The objects are then coded during the implementation workflow  Again, the transition is smooth 43 Terminology Client, developer, user Internal software Contract software Commercial off-the-shelf (COTS) software Open-source software 44 Terminology (contd) Program Software  Code plus all documentations System Product System is a related collection of programs. But nowadays it refers to both the software and the hardware. Product denotes a nontrivial piece of s/w. Methodology, paradigm Object-oriented paradigm Classical (traditional) paradigm 45 Terminology (contd) Mistake, fault, failure, error Defect When a programmer makes a mistake the consequence of that mistake is a fault in the code. Executing the s/w product then results in a failure. An error is the amount by which a result is incorrect. Defect is a generic term refers to a fault, failure, or error. 46 Object-Oriented Terminology Data component of an object  State variable  Instance variable (Java)  Field (C++)  Attribute (generic) Action component of an object  Member function (C++)  Method (generic) 47 1.12 Ethical Issues Major societies for software engineers  IEEE-CS  ACM (Association for Computing Machinery) IEEE-CS ACM Software Engineering Code of Ethics and Professional Practice http://www.acm.org/about/se-code#full 48