Lecture 2 Scope of Software Engineering

1. Lecture 2Scope of Software Engineering CSCI – 3250 Software Engineering I Spring 2014 Bill Pine

2. Lecture Overview • Assigned Reading: Braude and Bernstein, Chapters 1, 2 • Introduction • Motivation for Studying Software Engineering • Engineering and Software Engineering • Software Development Lifecycle CSCI 3250

3. Introduction • Software project failures anecdotes • Safety critical systems • Therac 25 • A dual mode accelerator (x-ray and electron) medical linear accelerator • Six accidents involving massive overdoses to patients occurred between 1985 and 1987, resulted in 4 deaths • Military systems • WWMCCS • A test of the system broadcast an alert that was interpreted as a “real attack” • Patriot antimissile system • Due to extended up-time, system lost accuracy and did not perform as expected CSCI 3250

4. Introduction (continued) • Business systems • Customer has to write check for $0 to turn off collection agencies - Urban legend? • Scientific systems • Complete loss of a $236 million dollar Mars probe in 1999 CSCI 3250

5. Software Crisis • More than 30 years ago, the large number of spectacular failures in building software led to the coining of the phrase “software crisis” • Poor quality • Delivered late • Over budget • Today, we still produce software that is • Poor quality • Delivered late • Over budget CSCI 3250

6. Fractional Workflow Costs • 1976–1981 data Schach – Fig. 1.3 CSCI 3250

7. Cost To Detect and Correct Faults Schach – Fig. 1.6 CSCI 3250

8. Software Product Cost by Workflow Chart Implication Focus on methodologies, techniques that lead to reduced maintenance costs Cost to Find and Fix Fault Implication Easier (and cheaper) to find and fix faults early Implications for Developers CSCI 3250

9. The Need for Software Engineering • The Five Drivers of Software Engineering • Manage complexity of large programs • Reduce time and cost of development • Reduce maintenance cost • Address “Software crisis” • Produce quality software CSCI 3250

10. Software Development History • Prior to 1975 there was no defined process that was used to develop software • The software crisis led to the development of • Structured analysis • Structured design • Structured programming and testing • Time frame 1975 - 1985 CSCI 3250

11. Development History (continued) • Initially these techniques seemed promising, but • With the increasing complexity of software, driven by faster and larger hardware (costs dropped) • These techniques soon reached their limit • Primarily because structured techniques tended to be either • Focus on the data, or focus on the functions • Not both • Also structured methodologies did little to reduce the cost of maintenance • This set the stage for software engineering as a discipline CSCI 3250

12. What is Engineering? • The job of the engineer is to drive new technology into new areas • Combining past experience with present science, to create future products and innovations (Bob Colwell) • Engineering encompasses • Best practices => proven methods • Well-defined and well-documented processes • Reuse of components • Measurements of quality • Cost effective solutions • Process management CSCI 3250

13. Hardware versus Software • Software is a logical not a physical product • Software doesn’t wear out • Failure rate versus time for hardware • Failure rate versus time for software • Ideal • Actual Can the engineering paradigm be applied to software? CSCI 3250

14. Engineering vs. Craftsmanship • Two views of the nature of creating software • Craftsmanship • Traditionally three levels of craftsman • Apprentice, Journeyman, and Master • Engineering • Profession characterized by • Mastery of an esoteric body of knowledge • Autonomy in their work • Admission controlled by a professional organization CSCI 3250

15. Engineering vs. Craftsmanship • Issues for software development • Why is craftsmanship necessary? • Why is craftsmanship not sufficient? CSCI 3250

16. System Engineering • Determine the need for the system • Examine alternatives • Do nothing • COTs • Buy vertical market product • Build a system • Identify hardware • Cost estimates / benefits analysis • Risk analysis CSCI 3250

17. Four P’s of Software Engineering • Software Engineering (invoked when the decision is taken to build a system) consist of • People • Project Stakeholders • Product • Code + Supporting Documentation • Project • Activities Executed to Produce the Product • Process • Framework within which the team carries out the activities CSCI 3250

18. People • People of interest are the stakeholders • Stakeholder - Any individual or group that can affect or may be affected by the success or failure of the project • Customer • Developers • End users • Indirect users CSCI 3250

19. Product • Artifacts delivered to the customer • Project documentation • Documented source code • Executable code • Test suite with documentation • Customer documentation CSCI 3250

20. Project • Activities carried out (workflows) • Planning • Requirements elicitation • Requirements analysis and specification • Design • Implementation • Testing • Delivery and Maintenance CSCI 3250

21. Process • Framework under which the activities are carried out • Also called Lifecycle Model • There are numerous Lifecycle Models, each of which combines the activities in a variety of ways CSCI 3250

22. Software Development Lifecycle • Nomenclature Issue • Workflow versus phase • There is not a universal set of workflows over all models • Classic lifecycle decomposition contains the workflows as ordered in Slide 18 CSCI 3250

23. Planning • Develop Software Project Management Plan • Description of Project Deliverables • Estimate scope and cost of project • Identification of a lifecycle model • Risk Management and Mitigation effort • Staffing plan • Definition of Tools and Techniques • Develop Budget and Scheduling CSCI 3250

24. Requirements Elicitation • Get requirements from customer and users • A period of close interaction with the customer to discover • Customer needs • How the system will support the customer’s business • User requirements • How the system will enhance the user’s productivity CSCI 3250

25. Analysis / Specification • Analysis • Focus on solving the problem • Develop necessary models • Produce a precisely worded enumeration of the requirements CSCI 3250

26. Design • Focus on “how to meet the requirements” • High level design • Defines system architecture • Identify the components of the solution • The interfaces between the components • Decompose until you have subcomponents that perform a single well defined task • Document the interface and function of each subcomponent • Identify algorithms for each subcomponent CSCI 3250

27. Implementation • The “Construction Activity” • Transform the algorithms into code • Also called programming • Includes considerations for system delivery and maintenance CSCI 3250

28. Delivery and Maintenance • Product is delivered to the customer and installed • Change is inevitable • Categories of change • Corrective • Find and fix previously undetected errors • Perfective • After using the product, the customer may require new functionality that he could not anticipate • Customer requirements will change, driven by a changing marketplace • Adaptive • Conforming to eternally imposed changes to the system CSCI 3250

29. Delivery and Maintenance (cont) • Preventative • Changes to increase the maintainability of the system • The first three categories increase the complexity of the product • The goal of the fourth is to reduce complexity CSCI 3250

30. Testing • Testing is not an isolated activity • Testing is a function distributed over all project activities • Implementation testing occurs at • Unit (module) level, sub-system level, and system level • For a nontrivial application, testing can only reveal errors, it cannot show that a given unit is error free • A successful test is one that reveals problems • But programmers don’t want to believe there are errors CSCI 3250

31. Structured versus Object Oriented Designs CSCI 3250

32. Essential Principles • Abstraction • Modularity • Encapsulation CSCI 3250

33. Abstraction • Same meaning as in OOP • Extract only the relevant details of an object • What is relevant depends upon how the object is viewed • Example • A car from the point of view of • Automotive engineer • Driver • Mechanic CSCI 3250

34. Modularity • Dividing a complex object into smaller pieces • Goal: achieve loose coupling and high cohesion • Embodiment of the “divide and conquer” strategy • To successfully manage the development and maintenance of large complex system, we must have a modular decomposition CSCI 3250

35. Encapsulation • A bundling of the properties of an object with its methods • Allows the use of data and implementation hiding • The essential data is “hidden” within the object • Object interface defines access to the object • Access to the data is closely controlled • Allows underlying data representationto change without requiring changes calling module CSCI 3250

36. Classes • A class is a: • Blueprint, • Cookie Cutter, or • Pattern From which an object is created CSCI 3250

37. Classes (cont.) • A class consists of • The name of the class • Properties a class instance will have – attributes, data • Usually private • But may be public or protected • Methods will exist for an instance of the class - functions • Usually public, but may be private or protected CSCI 3250

38. Objects • Aspects of objects • Identity • Name of the object • State • The set of specific values for each of the properties of the class • Behavior • As defined by the class member functions CSCI 3250

39. Class Exercise • Under which of the seven basic workflows does Object Oriented Development impose a complication? • What is the complication? CSCI 3250

40. Key Concepts Summary • Historic background • Impetus for the focus on maintenance • Differing failure curves for hardware and software • Classic software development workflows • Object Oriented vs. Structured • Classes vs. Objects CSCI 3250