13
1 Software Engineering: A Practitioner’s Approach, Software Engineering: A Practitioner’s Approach, 6/e 6/e Chapter 1 Chapter 1 Software and Software Software and Software Engineering 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.

1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

Embed Size (px)

Citation preview

Page 1: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

1

Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 1Chapter 1Software and Software Software and Software

EngineeringEngineering

copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay 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.

Page 2: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

2

What is What is Software?Software?

software is engineeredsoftware is engineered software doesn’t wear outsoftware doesn’t wear out software is complexsoftware is complex

Software is a general term for the various kinds of programs used to operate computers and related devices. (The term hardware describes the physical aspects of computers and related devices.)

Page 3: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

3

Software’s Dual RoleSoftware’s Dual Role

Software is a productSoftware is a product Delivers computing potentialDelivers computing potential Produces, manages, acquires, modifies, displays, or Produces, manages, acquires, modifies, displays, or

transmits informationtransmits information Software is a vehicle for delivering a productSoftware is a vehicle for delivering a product

Supports or directly provides system functionalitySupports 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)

Page 4: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

4

What is What is Software?Software?

Software is a set of items or objects that form a “configuration” that includes • programs • documents • data ...

Page 5: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

5

Hardware Failure Hardware Failure CurveCurve

Infant Infant mortalitymortality

Wear Wear outout

Page 6: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

6

Wear vs. Wear vs. DeteriorationDeterioration

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects

Page 7: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

7

Robustness Failure Robustness Failure RatesRates

Page 8: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

8

Software Software ApplicationsApplications system softwaresystem software

application softwareapplication software engineering/scientific engineering/scientific

software software embedded software embedded software product-line softwareproduct-line software WebApps (Web applications)WebApps (Web applications) AI softwareAI software

Page 9: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

9

Software—New CategoriesSoftware—New Categories Ubiquitous computingUbiquitous computing—wireless networks—wireless networks NetsourcingNetsourcing—the Web as a computing engine—the Web as a computing engine Open sourceOpen source—”free” source code open to the —”free” source code open to the

computing community (a blessing, but also a computing community (a blessing, but also a potential curse!)potential curse!)

Also … (see Chapter 32)Also … (see Chapter 32) Data miningData mining Grid computingGrid computing Cognitive machinesCognitive machines Software for nanotechnologiesSoftware for nanotechnologies

Page 10: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

10

Legacy SoftwareLegacy Software

Legacy applications (software) and data Legacy applications (software) and data are those that have been inherited from are those that have been inherited from languages, platforms, and techniques languages, platforms, and techniques earlier than current technology. earlier than current technology.

Most enterprises who use computers have Most enterprises who use computers have legacy applications and databases that legacy applications and databases that serve critical business needs. Typically, serve critical business needs. Typically, the challenge is to keep the legacy the challenge is to keep the legacy application running while converting it to application running while converting it to newer, more efficient code that makes use newer, more efficient code that makes use of new technology and programmer skills.of new technology and programmer skills.

What is it?

Page 11: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

11

Legacy SoftwareLegacy Software

software must be software must be adaptedadapted to meet the to meet the needs of new computing environments or needs of new computing environments or technology.technology.

software must be software must be enhancedenhanced to implement to implement new business requirements.new business requirements.

software must be software must be extended to make it extended to make it interoperableinteroperable with other more modern with other more modern systems or databases.systems or databases.

software must be software must be re-architectedre-architected to make it to make it viable within a network environmentviable within a network environment.

Why must it change?

Page 12: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

12

Software EvolutionSoftware Evolution The Law of Continuing Change (1974):The Law of Continuing Change (1974): E-type systems must be continually adapted else they E-type systems must be continually adapted else they

become progressively less satisfactory.become progressively less satisfactory. The Law of Increasing Complexity (1974):The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases As an E-type system evolves its complexity increases

unless work is done to maintain or reduce it.unless work is done to maintain or reduce it. The Law of Self Regulation (1974):The Law of Self Regulation (1974): The E-type system evolution process is self-regulating with The E-type system evolution process is self-regulating with

distribution of product and process measures close to normal.distribution of product and process measures close to normal. The Law of Conservation of Organizational Stability (1980):The Law of Conservation of Organizational Stability (1980): The average effective global The average effective global

activity rate in an evolving E-type system is invariant over product lifetime.activity rate in an evolving E-type system is invariant over product lifetime. The Law of Conservation of Familiarity (1980):The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with As an E-type system evolves all associated with

it, developers, sales personnel, users, for example, must maintain mastery of its content and it, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution. behavior to achieve satisfactory evolution.

The Law of Continuing Growth (1980):The Law of Continuing Growth (1980): The functional content of E-type systems must be The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.continually increased to maintain user satisfaction over their lifetime.

The Law of Declining Quality (1996):The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.unless they are rigorously maintained and adapted to operational environment changes.

The Feedback System Law (1996):The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.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

Page 13: 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6/e

13

Software MythsSoftware Myths

Affect managers, customers (and other non-Affect managers, customers (and other non-technical stakeholders) and practitionerstechnical stakeholders) and practitioners

Are believable because they often have elements Are believable because they often have elements of truth, of truth,

but …but … Invariably lead to bad decisions, Invariably lead to bad decisions,

therefore …therefore … Insist on reality as you navigate your way Insist on reality as you navigate your way

through software engineeringthrough software engineering