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

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
Failure Curve for Hardware
Software Applications
 system software
 application software
 engineering/scientific software
 embedded software
 WebApps (Web applications)
 AI software
 Mobile Apps
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
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.
The Unique Nature of Web Apps
 Network Intensiveness: A WebApp resides on a network
and must serve the needs of a diverse community of
clients. (Internet /Intranet)
 Concurrency: A large number of users may access the
WebApp at one time.
 Unpredictable load: The number of users of the WebApp
may vary by orders of magnitude from day to day.
 Performance: If a WebApp user must wait too long,
he/she may decide to go elsewhere.
 Availability: 24/7/365. Time Difference between Canada
and Pakistan.
 Data driven: Accessing Data (Text, Images, Sounds,
Movie Clips etc.
The Unique Nature of Web Apps (Cont..)
 Content Sensitive: Quality of Data is important.
 Continuous evolution: Minute-by-Minute Updation in
Data e.g, News portals, Score board portals etc.
 Immediacy: WebApps often exhibit a time-to-market that
can be a matter of a few days or weeks.
 Security: Multiple users and risk of breach in security e.g.
Hacking, Illegal Access to data.
 Aesthetics: An undeniable part of the appeal of a
WebApp is its look and feel.
1.3 Software Engineering
A few simple realities to be recognized to build a software:
 Understand the problem before you build a solution: Different
users of an application, so different requirements.
 Design is a pivotal software engineering activity: Good
/Appropriate Design, Goon Appropriate Solution.
 Both quality and maintainability are result of good design:
Crucial Situations and a failure may cause irreversible loss.
These simple realities lead to one conclusion: Software in all of its

forms and across all of its application domains should be engineered.
That is why “Software Engineering”

1.3 Software Engineering (Cont..)
Software Engineering Definitions:
 [Software engineering is] the establishment and use of sound
engineering principles in order to obtain economically, software that
is reliable and works efficiently on real machines. [Fritz Bauer]
 Software Engineering: (1) The application of a systematic,
disciplined, quantifiable approach to the development, operation,
and maintenance of software; that is, the application of engineering
to software. (2) The study of approaches as in (1). IEEE [IEE93a]
 KEY POINT: Software engineering encompasses (includes) a

process, methods for managing and engineering software, and
tools.
1.4 The Software Process
 Process: A process is a collection of activities, actions, and tasks
that are performed when some work product is to be created.
 Activity: An activity strives to achieve a broad objective and is
applied regardless of the application domain, size of the project,
complexity of the effort, or degree of rigor with which software
engineering is to be applied (e.g., communication with stakeholders).
 Action: An action (e.g., architectural design) encompasses a set of
tasks that produce a major work product (e.g., an architectural
design model).
 Task: A task focuses on a small, but well-defined objective (e.g.,
conducting a unit test) that produces a tangible outcome.
KEY POINT:: A process is not a rigid prescription rather you can pick
and choose the appropriate set of work actions and tasks.
1.4 The Software Process (Cont..)
 A software Process
is a framework of the activities, actions and tasks
that are required to build high quality software.
 A software process defines the approach that is taken as

software is engineered.
 It is a roadmap to create timely, high quality result.
 A Generic Model has five basic activities
- Communication
- Planning
- Modeling
- Construction
- Deployment
 Process Flow
- Each S/W process has a process flow.
- Describes how the framework activities and the actions
n tasks within each frame work are organized with
respect to sequence and time
Umbrella Activities:
- Software project tracking and control: allows the software team to
assess progress against the project plan and take any necessary action
to maintain the schedule
- Risk management: assesses risks that may affect the outcome of the
project or the quality of the product
- Software quality assurance: defines and conducts the activities
required to ensure software quality
- Technical reviews: assesses software engineering work products in
an effort to uncover and remove errors before they are propagated to
the next activity
- Measurement: defines and collects process, project, and product
measures that assist the team in delivering software that meets
stakeholders’ needs.
Umbrella Activities (Cont..):
- Software configuration management: manages the effects of
change throughout the software process.
- Reusability management: defines criteria for work product reuse
(including software components) and establishes mechanisms to
achieve reusable components.
- Work product preparation and production: encompasses the
activities required to create work products such as models, documents,
logs, forms, and lists.
Home Assignment: (Due Date: 21/10/2014)

Read and re-write in your own words: 1.5 Software Engineering
Practice.
1.5 Software Engineering Practice
The generic concepts and principles that apply to framework activities:
1.5.1 The Essence of Practice:
- A classic book, How to Solve It by George Polya [Pol45] outlined the
essence of problem solving (long before the Computers).
- Provided essence for Software Engineering Practice.
It gives us 4 generic Guideline for Problem Solving

a. Understand the Problem (Communication and Analysis)
b. Plan a Solution (Modelling and Software Design)
c. Carryout the Plan (Code Generation)
d. Examine the Result for accuracy (Testing and Quality Assurance)
1.5 Software Engineering Practice (Cont..)
a. Understand the Problem (Communication and Analysis)
 Who has a stake in the solution to the problem? That is, who are the
stakeholders?
 What are the unknowns? What data, functions, and features are
required to properly solve the problem?
 Can the problem be compartmentalized? Is it possible to represent
smaller problems that may be easier to understand?
 Can the problem be represented graphically? Can an analysis model
be created?
b. Plan a Solution (Modelling and Software Design)
 Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that
implements the data, functions, and features that are required?
 Has a similar problem been solved? If so, are elements of the
solution reusable?
 Can subproblems be defined? If so, are solutions readily apparent for
the subproblems?
 Can you represent a solution in a manner that leads to effective
implementation?
 Can a design model be created?
c. Carryout the Plan (Code Generation)
 Does the solution conform to the plan? Is source code traceable to the
design model?
 Is each component part of the solution provably correct? Have the
design and code been reviewed, or better, have correctness proofs
been applied to the algorithm?
d. Examine the Result for accuracy (Testing and Quality Assurance)

 Is it possible to test each component part of the solution? Has a reasonable
testing strategy been implemented?
 Does the solution produce results that conform to the data, functions, and
features that are required?
 Has the software been validated against all stakeholder requirements?
1.5.2 General Principles:
- The First Principle: The Reason It All Exists.

A software system exists for one reason: to provide value to its users.
- The Second Principle: KISS (Keep It Simple, Stupid).
All design should be as simple as possible, but no simpler. This facilitates
having a more easily understood and easily maintained system.
- The Third Principle: Maintain the Vision:
A clear vision is essential to the success of a software project
- The Fourth Principle: What you Produce, Others will consume:
Always specify, design, and implement knowing someone else will have
to understand what you are doing.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided 24
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
1.5.2 General Principles (Cont..):
- The Fifth Principle: Be Open to Future:

Never design yourself into a corner. Should be Long Lasting.
- The Sixth Principle: Plan Ahead for Reuse
Planning ahead for reuse reduces the cost and increases the value of
both the reusable components and the systems into which they are
incorporated.
- The Seventh Principle: THINK
Placing clear, complete thought before action almost always produces
better results.
Reading Assignment: How a Project Starts (Page 24)

Software Myths
 Erroneous beliefs about software and the process that is

used to build it
- Management Myths
- Customer Myths
- Practitioner’s Myths
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 (Cont..)
 Management Myths:
- Myth: If we get behind schedule, we can add more
programmers and catch up.
- Reality: Software Development is not a mechanistic
process like manufacturing.
- More time will be spent to educate new people.
- People can be added but only in a planned and well-
coordinated manner.
- Myth: 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?
- Reality: -Do we use book?
- S/W Engineer aware of it?
- It reflects Modern Practices?
- Is it Complete?
- Is it Adaptable?
- Provides Quality with Time-to-Delivery?
- Myth: If we get behind schedule, we can add more
programmers and catch up.
- Reality: Software Development is not a mechanistic
process like manufacturing.
- More time will be spent to educate new people.
- People can be added but only in a planned and well-
coordinated manner.
 Management Myths (Cont..):

- Myth: If I decide to outsource the software project to
a third party, I can just relax and let that firm build that.
- Reality: If an organization does not understand how
to manage and control software projects internally, it
will invariably struggle when it out-sources software
projects.
 Customer Myths:
- Myth: A general statement of objectives is sufficient
to begin writing programs-we can fill in the details later.
- Reality: -Ambiguous statement of objectives can be
dangerous.
- Effective and Continuous Communication can
produce Unambiguous Requirements.
 Customer Myths (Cont..):

- Myth: Software Requirements continuously change,
but change can be easily accommodated because
software is flexible.
- Reality: -Depends when you report the change
- Before Design
- Before Coding
- After Coding etc…
Have different cost impact.
 Practitioner’s Myths:
- Myth: Once we write the program and get it to work,
our job is done.
- Reality: - 60-80% percent of all effort expended on
software will be expended after it is delivered to the
customer for the first time.
- The sooner you begin writing code, the longer it will
take you to get done.
 Practitioner’s Myths (Cont..):

- Myth: Until I get the program running, I have no way
of assessing its quality.
- Reality: - Technical Reviews provide the effective
mechanism to assess the quality during different
phases.
35

- Myth: The Only deliverable work product for a
successful project is the working program.
- Reality: -Models, Documents, Plans etc.

- Myth: Software Engineering will make us create
voluminous and unnecessary documentation and will
invariably slow us down.
- Reality: - S/W engineering is not about creating
documents but creating a quality product.
- Reduced Rework.
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

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

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: Supplementary Slides For

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

These simple realities lead to one conclusion: Software in all of its

That is why “Software Engineering”

 KEY POINT: Software engineering encompasses (includes) a

 A software process defines the approach that is taken as

 It is a roadmap to create timely, high quality result.

Home Assignment: (Due Date: 21/10/2014)

It gives us 4 generic Guideline for Problem Solving

d. Examine the Result for accuracy (Testing and Quality Assurance)

- The First Principle: The Reason It All Exists.

- The Fifth Principle: Be Open to Future:

Reading Assignment: How a Project Starts (Page 24)

 Erroneous beliefs about software and the process that is

 Management Myths (Cont..):

 Customer Myths (Cont..):

 Practitioner’s Myths (Cont..):

 Practitioner’s Myths (Cont..):

 Practitioner’s Myths (Cont..):

You might also like