Software Engineering: A Practitioner's Approach, 6/e

8/14/2019 SoftwareEngineering: APractitioner'sApproach,6/e

1/11

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

Supplementary Slides forSupplementary Slides for

Software Engineering:Software Engineering:A Practitioner's Approach, 6/eA Practitioner's Approach, 6/e

Part 1Part 1

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 ApproachAny other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used forshort courses, industry seminars, or consulting purposes.


2/11


Software Engineering: A Practitioners Approach, 6/eSoftware Engineering: A Practitioners Approach, 6/e

Chapter 1Chapter 1

Software and SoftwareSoftware and Software

EngineeringEngineeringcopyright 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university levelwhen used in conjunction with Software Engineering: A Practitioner's Approach.

Any other reproduction or use is expressly prohibited.


3/11


Softwares Dual RoleSoftwares Dual Role

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

informationinformation

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)


4/11


What is Software?What is Software?

Software is a set of items or objectsthat form a configuration thatincludes

programs

documents data ...


5/11


What is Software?What is Software?

software is engineeredsoftware is engineered software doesnt wear outsoftware doesnt wear out software is complexsoftware is complex


6/11


Wear vs. DeteriorationWear vs. Deterioration

idealized curve

change

actual curve

Failurerate

Time

increased failure

rate due to side effects


7/11


Software ApplicationsSoftware Applications

system softwaresystem software application softwareapplication software engineering/scientific softwareengineering/scientific software embedded softwareembedded software

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


8/11


SoftwareNew CategoriesSoftwareNew Categories

Ubiquitous computingUbiquitous computingwireless networkswireless networks NetsourcingNetsourcingthe Web as a computing enginethe Web as a computing engine Open sourceOpen sourcefree source code open to the computingfree source code open to the computing

community (a blessing, but also a potential curse!)community (a blessing, but also a potential curse!) Also (see Chapter 32)Also (see Chapter 32)

Data miningData mining Grid computingGrid computing Cognitive machinesCognitive machines Software for nanotechnologiesSoftware for nanotechnologies


9/11


Legacy SoftwareLegacy Software

software must besoftware must be adaptedadapted to meet the needs of newto meet the needs of newcomputing environments or technology.computing environments or technology.

software must besoftware must be enhancedenhanced to implement newto implement newbusiness requirements.business requirements.

software must besoftware must be extended to make it interoperableextended to make it interoperablewith other more modern systems or databases.with other more modern systems or databases.

software must besoftware must be re-architectedre-architected to make it viableto make it viablewithin a network environmentwithin a network environment.

Why must it change?


10/11

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1

Software EvolutionSoftware Evolution The Law of Continuing Change (1974):The Law of Continuing Change (1974): E-type systems must be continually adapted else theyE-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 increasesAs 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 withThe 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 activityThe average effective global activityrate in an evolving E-type system is invariant over product lifetime.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 it,As an E-type system evolves all associated with it,developers, sales personnel, users, for example, must maintain mastery of its content anddevelopers, 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 beThe 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 decliningThe quality of E-type systems will appear to be decliningunless 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 improvementmulti-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 EvolutionThe Nineties View,Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can bedownloaded from: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf
http://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdfhttp://www.ece.utexas.edu/~perry/work/papers/feast1.pdf


11/11

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1

Software MythsSoftware Myths

Affect managers, customers (and other non-technicalAffect managers, customers (and other non-technicalstakeholders) and practitionersstakeholders) and practitioners

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

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

therefore therefore

Insist on reality as you navigate your way throughInsist on reality as you navigate your way throughsoftware engineeringsoftware engineering

Software Engineering: A Practitioner's Approach, 6/e

Documents

Transcript of Software Engineering: A Practitioner's Approach, 6/e