1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 6/e Part 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 6/e Part 1 copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 Software Crisis Why does it take so long to get software finished? Why does it take so long to get software finished? Why are development cost so high? Why are development cost so high? Why can’t we find all the errors before we give the software to customers? Why can’t we find all the errors before we give the software to customers? Why do we continue to have difficulty in measuring progress as software is being developed? Why do we continue to have difficulty in measuring progress as software is being developed?

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 What is Software?

5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Software’s Dual Role Software is a product Software is a product Delivers computing potential Delivers computing potential Produces, manages, acquires, modifies, displays, or transmits information Produces, manages, acquires, modifies, displays, or transmits information Software is a vehicle for delivering a product Software is a vehicle for delivering a product Supports or directly provides system functionality Supports or directly provides system functionality Controls other programs (e.g., an operating system) Controls other programs (e.g., an operating system) Effects communications (e.g., networking software) Effects communications (e.g., networking software) Helps build other software (e.g., software tools) Helps build other software (e.g., software tools)

6. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 What is Software? Software is a set of items or objects that form a “configuration” that includes programs documents data...

7. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 What is Software?  software is developed or engineered, not manufactured  software doesn’t wear out, but it does deteriorate  software is complex  software is a ‘differentiator’  software is like an ‘aging factory’

8. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 Failure Rate for Hardware

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Wear vs. Deterioration

10. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 Software Applications system software system software application software application software engineering/scientific software engineering/scientific software embedded software embedded software product-line software product-line software WebApps (Web applications) WebApps (Web applications) AI software AI software

11. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11 Software—New Categories Ubiquitous computing—wireless networks Ubiquitous computing—wireless networks Netsourcing—the Web as a computing engine Netsourcing—the Web as a computing engine Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) Also … (see Chapter 32) Also … (see Chapter 32) Data mining Data mining Grid computing Grid computing Cognitive machines Cognitive machines Software for nanotechnologies Software for nanotechnologies

12. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12 Legacy Software software must be adapted to meet the needs of new computing environments or technology. software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment software must be re-architected to make it viable within a network environment. Why must it change?

13. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13 Software Evolution The Law of Continuing Change (1974): E-type systems must be continually adapted else they become progressively less satisfactory. The Law of Continuing Change (1974): E-type systems must be continually adapted else they become progressively less satisfactory. The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless work is done to maintain or reduce it. The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless work is done to maintain or reduce it. The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with distribution of product and process measures close to normal. The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with distribution of product and process measures close to normal. The Law of Conservation of Organizational Stability (1980): The average effective global activity rate in an evolving E-type system is invariant over product lifetime. The Law of Conservation of Organizational Stability (1980): The average effective global activity rate in an evolving E-type system is invariant over product lifetime. The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution. The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution.

14. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14 Software Evolution The Law of Continuing Growth (1980): The functional content of E- type systems must be continually increased to maintain user satisfaction over their lifetime. The Law of Continuing Growth (1980): The functional content of E- type systems must be continually increased to maintain user satisfaction over their lifetime. The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes. The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes. The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. Source: Lehman, M., et al, “Metrics and Laws of Software Evolution—The Nineties View,” Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be downloaded from: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf

15. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 Management Myths  We already have a book that’s full of standards and procedures for building software.  My people have the newest computers.  If we get behind schedule, add more programmers.  Outsource the software project, and let the third party to worry about it.

16. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 Customer Myths A general statement of objectives is sufficient to begin writing programs, we can fill in the details later. A general statement of objectives is sufficient to begin writing programs, we can fill in the details later. Project requirements continually change, but change can be easily accommodated because software is flexible. Project requirements continually change, but change can be easily accommodated because software is flexible.

17. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 Practitioner Myths Once we write the program and get it to work, our job is done. Once we write the program and get it to work, our job is done. Until I get the program running, I have no way of accessing its quality. Until I get the program running, I have no way of accessing its quality. The only deliverable work product for a software project is the working program. The only deliverable work product for a software project is the working program. Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down. Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

18. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18 The Cost of Change Definition Development After release 1x1x 1.5-6x 60-100x

19. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19 Software Myths Affect managers, customers (and other non- technical stakeholders) and practitioners Affect managers, customers (and other non- technical stakeholders) and practitioners Are believable because they often have elements of truth, Are believable because they often have elements of truth, but … Invariably lead to bad decisions, Invariably lead to bad decisions, therefore … Insist on reality as you navigate your way through software engineering Insist on reality as you navigate your way through software engineering

20. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20 Software Poses Challenges How do we ensure the quality of the software that we produce? How do we ensure the quality of the software that we produce? How do we meet growing demand and still maintain budget control? How do we meet growing demand and still maintain budget control? How do we upgrade an aging "software plant?" How do we upgrade an aging "software plant?" How do we avoid disastrous time delays? How do we avoid disastrous time delays? How do we successfully institute new software technologies? How do we successfully institute new software technologies?