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

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.
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 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.
Software’s Dual Role
 Software is a product
 Delivers computing potential
 Produces, manages, acquires, modifies, displays, or transmits
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)
 Helps build other software (e.g., software tools)
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
What is Software?
 software is engineered
 software doesn’t wear out
 software is complex
Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate
change
actual curve
idealized curve
Time
Software Applications
 system software
 application software
 engineering/scientific software
 embedded software
 product-line software
 WebApps (Web applications)
 AI software
Software—New Categories
 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)
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies
 colloidal science, device physics, and supramolecular
chemistry
Legacy Software
Why must it change?
 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 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 Myths
 Affect managers, customers (and other non-technical
stakeholders) and practitioners
 Are believable because they often have elements of truth,
but …
 Invariably lead to bad decisions,
therefore …
 Insist on reality as you navigate your way through
software engineering
Software Myths
 Myth: It’s in the software. So, we can easily change it.

Reality: Requirements changes are a major cause of software
degradation.
 Myth: We can solve schedule problems by adding more programmers.
 Reality: Maybe. It increases coordination efforts and may slow

things down.
 Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code.
 Reality: Incomplete up-front definition is the major cause of

software project failures.
Software Myths
 Myth: Writing code is the major part of creating a software
product.
 Reality: Coding may be as little as 10% of the effort, and 50 -
70% may occur after delivery.
Software Myths
 Myth: I can’t tell you how well we are doing until I get
parts of it running.
 Reality: Formal reviews of various types both can give good
information and are critical to success in large projects.
 Myth: The only deliverable that matters is working code.
 Reality: Documentation, test history, and program configuration

are critical parts of the delivery.
 Myth: I am a (super) programmer. Let me program it, and I will get it done.
 Reality: A sign of immaturity. A formula for failure. Software projects are done
by teams, not individuals, and success requires much more than just coding.
Software Evolution
 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 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be
downloaded from: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf
CPSC 431 Software Engineering
 SE - the use of techniques, methods and processes to develop high
quality software, that is, software that is reliable, easy to
understand, useful, modular, efficient, modifiable, reusable and
delivered in a cost effective and timely manner. A good user
interface is paramount to a successful system. Must be well
documented.
permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
 Production systems: large scale, distributed, embedded,
real-time systems - daily operations
 Software chronic ailment - DoD $30 billion, US $150
billion, world-wide $225 billion
 user/customer can’t tell developer what they want
 need a medium for communication
 key words:
 communication
 context
 requirements capture
 conceptual model
 look at syllabus
Life Cycle Model - Software Process
Model Water Fall Model
 requirements
 specifications
 design
 implementation
 integrate/test
 install/operate
 maintain - 70% of cost
 frame of reference for us

Properties LC Model
 criteria for starting and stopping a phase/stage
 specifies tasks to be done during a phase/stage
 code driven, document driven, risk driven, requirement
driven life cycle models
 doesn’t describe how to perform task
 umbrella activities
Process
 describes how to perform the tasks of a phase/stage
 would like to be seamless
 would like to support Methodman document criteria for
embodying methodology
Teamwork
 working in teams on projects
 personal interactions
 what are people like, characteristics?
 what are major personal problems we struggle with
 what is weltanschauung?
The Triad
 be good for people
 do not be deceived
 use your mind to the best possible extent
Worldviews
 nihilism
 humanism
 secularism
 hedonism
 solipsism
 Mormonism
 Hinduism
 Buddhism
 Christianity
Interesting Quotes
 vanity of vanities
 I do not the good that I desire, but the evil I do not desire
I do
 examine yourself, who are you and how do you made
decisions?
 worldview has great impact
 The great theologian Paul laments,"The good that I
desire is not what I do, but the evil I do not desire is
what I do." (Romans 7:19)
• Voltaire, "I wish I had never been born."
• Lord Byron, "The worm, the canker and grief are alone mine."
• Jay Gould, "I suppose I am the most miserable man on earth."
• Maugham, "The only thing I know for sure is that I don't know
anything for sure."
• "My whole life has been one long series of disappointments. I can
scarely remember one thing that I have been successful in.", John
Quincy Adams.
• "I am a complete failure; now everything leaves on my tongue only
the taste of ashes.", Robert Oppenheimer.
Life
 life is all about relationship
 most people get a very poor grade on relationship
 do you care about other people?
 how well do you see yourself?
 find an approach to life that allows you do well in
accomplishing the Triad
LCAM - life cycle artifact manager
 has a graphical interface that facilitates the
management of software artifacts created throughout
the entire life cycle of the development of a software
system
 requirements, specifications, design, code, integrate
and test data; install, operation and maintenance
manuals, overviews, narratives, design rationale
 traceability
 configuration management
 open ended
 supports CORBA
 does not hinder the developer in the process of
producing software.
 enhances communications among all stakeholders
 interface then is key
 qualities of good interface
Seven Habits of Highly Effective
People
 be proactive - not reactive
we are free to choose
 began with the end in mind - goal setting - identify
personal goals and missions
 put first things first - prioritize
act on our priorities
 think win/win
look for alternatives that allow everyone to win
7 habits continues
 seek first to understand, then to be understood
both an attitude and skill of listening deeply for
complete understanding
 synergize - we discover a creativity that people can
experience when they explore their differences together
7 habits continues
 sharpen the saw - improvements in your life
simple daily activities that implant the principles of
effectiveness in our minds
 what is effectiveness?
 three person teaching - be taught and then teach
someone else
 paradigm shifting - different viewpoints, conceptual
blockbusting, critical thinking

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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

Supplementary Slides for

For University Use Only

This presentation, slides, or hardcopy may NOT be used for

For University Use Only

 Reality: Maybe. It increases coordination efforts and may slow

 Reality: Incomplete up-front definition is the major cause of

 Reality: Documentation, test history, and program configuration

 frame of reference for us

 use your mind to the best possible extent

You might also like