Part I 1ntroduction Software to Engineering

copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use May be reproduced ONLY for student use at the university Only when used in conjunction with Software Engineering: A Practitioner's level Any other reproduction or use is expressly Approach. prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

5/29/12

Softwares Dual Role Software is a

product Delivers computing

potential Produces, manages, acquires, modifies, displays, ortransmits information Software is a vehicle for delivering a product Supports or directly provides system functionality Controls other programs (e.g., an operating system) Effects communications (e.g., networking software)
2

5/29/12

What is Software?

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

5/29/12

What is Software? software is

engineereddoesnt wear software out software is complex

5/29/12

Wear vs. Deterioration

Failu re r at e

increased rate due failure to side effects

chan ge

actual curve idealized curve Ti me

5

5/29/12

Software Applications System

software Application software Engineering/scientific software Embedded software WebApps (Web applications) Product-line software AI software
6

5/29/12

SoftwareNew Categories
Ubiquitous computingwireless networks Netsourcingthe Web as a computing engine
Open sourcefree source code open to the computing community (a blessing, but also Software for a nanotechnologies 5/29/12

potential curse!)

Legacy Software Software must be adapted to meet the needs of

computing environments or new technology. Software must be enhanced to implement new requirement business s. Software must be extended to make it with other more modern systems or interoperable databases. Software must be re-architected to make it viable a network within environment. Why must it change?
8

5/29/12

E-Type Systems E-Type

Software Systems: that has been implemented in a realworld computing context and will therefore evolve over time

5/29/12

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

progressively less satisfactory. The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless workLaw of Self maintain or(1974): it. E-type system evolution process is self-regulating The is done to Regulation reduce The with distribution of product and process measures close to normal. average effective global activity rate The Law of Conservation of Organizational Stability (1980): The in an evolving Conservation of Familiarity over product lifetime. system evolves all associated with it, The Law of E-type system is invariant (1980): As an E-type developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution. (1980): The functional content of E-type systems must be The Law of Continuing Growth continually increasedof Declining Quality (1996): The quality of E-type systems will appear to be declining unless The Law to maintain user satisfaction over their lifetime. they are rigorously maintained and adapted to operational environment changes. The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multiagent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.
1 0

5/29/12

Software Myths managers, customers (and other Affect

technical stakeholders) and nonpractitioners Are believable because they often have elements of truth, Invariably lead to bad but decisions, Insist on reality as you navigate your way therefore software through engineering
5/29/12

1 1

Management Myths We already have a book of standards

procedures for building software. It does provide and my people with everything the need to know If my project is behind they schedule, I always add can more programmers to it and catch up (a.k.a. The Mongolian Horde concept) If I decide to outsource the software project to a third party, I can just relax: Let them build it, and I will just pocket my profits
1 2

5/29/12

Customer Myths 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 easily be accommodated this because software is flexible

1 3

5/29/12

Practitioners Lets start coding ASAP, because once we write Myths

p the rogram and get it to work, our job is done Until I get the program running, I have no way of its quality assessing The only deliverable work product for a successful is the project working program Software engineering is baloney. It makes us create of tons paperwork, only to slow us down
5/29/12

1 4