Software Engineering A Practitioners Approach 6e Chapter 1

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. 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

Software’s Dual Role n Software is a product n n n Delivers computing potential Produces, manages, acquires, modifies, displays, or transmits information Software is a vehicle for delivering a product n n Supports or directly provides system functionality Controls other programs (e. g. , an operating system) Effects communications (e. g. , networking software) Helps build other software (e. g. , software tools) 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

Persisting Problems n n n Hardware advances continue to outpace our ability to build software to tap hardware's potential. Ability to build new programs cannot keep pace with the demand for new programs, nor can we build programs rapidly enough to meet business and market needs. Society increasingly dependent on reliable operation of software. Struggle to build computer software that has high reliability and quality. Ability to support and enhance existing programs is threatened by poor design and inadequate resources.

The Cost of Change 60 -100 x 1. 5 -6 x 1 x Definition Development After release 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

An Industry Perspective n In the early days of computing n n Programming was viewed as an "art form. ' The programmer often learned his craft by trial and error Questions for almost two decades n n Why does it take so long to get programs finished? Why are costs so high? Why can't we find all errors before we give the software to our customers? Why do we have difficulty in measuring progress as software is being developed.

What is Software? Software is a set of items or objects that form a “configuration” that includes • programs • documents • data. . . 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? n Software is developed or engineered, it is not manufactured in the classical sense. n n n Software doesn't "wear out. " n n Costs are concentrated in engineering Software factory When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Most software is custom-built, rather than being assembled from existing components 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

Wear vs. Deterioration 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

Software Applications n n n n system software application software engineering/scientific software embedded software product-line software Web. Apps (Web applications) AI software 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

Software—New Categories n n Ubiquitous computing—wireless networks Netsourcing—the Web as a computing engine Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) Also … (see Chapter 32) n n Data mining Grid computing Cognitive machines Software for nanotechnologies 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

Legacy Software Why must it change? n software must be adapted to meet the needs of new computing environments or technology. n software must be enhanced to implement new business requirements. n software must be extended to make it interoperable with other more modern systems or databases. n software must be re-architected to make it viable within a network environment. 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 Evolution n n n n 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 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 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 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 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 4 th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be downloaded from: http: //www. ece. utexas. edu/~perry/work/papers/feast 1. pdf 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

Software Myths Affect managers, customers (and other non-technical stakeholders) and practitioners n Are believable because they often have elements of truth, but … n Invariably lead to bad decisions, therefore … n Insist on reality as you navigate your way through software engineering n 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

Management Myths n n Under pressure to maintain budgets, keep schedules from slipping, and improve quality Myth n n n We already have a book that's full of standards and procedures for building software. Won't that provide my people with everything they need to know? My people do have state-of-the-art software development tools. After all, we buy them the newest computers If we get behind schedule, we can add more programmers and catch up

Customer Myths n n Software responsible managers and practitioners do little to correct misinformation Myth: n n 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.

Practitioner's Myths n n n Myth: Once we write the program and get it to work, our job is done. Myth: Until I get the program "running, " I really have no way of assessing its quality Myth: The only deliverable for a successful project is the working program.

Software Poses Challenges 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