Software Engineering:
A Practitioner's Approach, 6/e
Part 2
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 5
Practice: A Generic View
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
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 2
What is “Practice”?
Practice is a broad array of concepts, principles,
methods, and tools that you must consider as
software is planned and developed.
It represents the details — the technical
considerations and how to’s — that are below the
surface of the software process — the things that
you’ll need to actually build highquality computer
software.
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 3
The Essence of Practice
George Polya, in a book written in 1945 (!), describes
the essence of software engineering practice …
Understand the problem (communication and analysis).
Plan a solution (modeling and software design).
Carry out the plan (code generation).
Examine the result for accuracy (testing and quality assurance).
At its core, good practice is commonsense problem
solving
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 4
Understand ...
Who are the stakeholders?
What are the unknowns?
Can the problem be compartmentalized?
Can the problem be represented
graphically?
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 5
Plan ...
Have you seen similar problems before?
Has a similar problem been solved?
Can subproblems be defined?
Can you represent the solution in a way
leading to effective implementation?
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 6
Carry out the plan ...
Does the solution conform to the plan?
Is each component of the solution probably
correct?
Design and code reviewed?
Have correctness proofs been applied?
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 7
Examining the result ...
Is it possible to test separately each
component of the solution?
Does the solution produce results that
conform to the data, functions, features,
and behaviours required?
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 8
Core Software Engineering
Principles
Provide value to the customer and the user
KIS—keep it simple!
Maintain the product and project “vision”
What you produce, others will consume
Be open to the future (but do not go overboard!)
Plan ahead for reuse (although sometimes this
might be expensive!)
Think! (and learn!)
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 9
Software Engineering Practices
Consider the generic process framework
Communication
Planning
Modeling
Construction
Deployment
Here, we’ll identify
Underlying principles
How to initiate the practice
An abbreviated task set
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 10
Communication Practices
Principles:
Listen
Prepare before you communicate
Facilitate the communication
Facetoface is best
Take notes and document decisions
Collaborate with the customer
Stay focused (modularize your discussion)
Draw pictures when things are unclear
Move on … (when agreed, disagreed, or unclear)
Negotiation works best when both parties win.
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 11
Communication Practices
Initiation
The parties should be physically close to one another
Make sure communication is interactive
Create solid team “ecosystems”
Use the right team structure
An abbreviated task set
Identify who it is you need to speak with
Define the best mechanism for communication
Establish overall goals and objectives and define the scope
Get more detailed
Have stakeholders define scenarios for usage
Extract major functions/features
Review the results with all stakeholders
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 12
Planning Practices
Principles
Understand the project scope
Involve the customer (and other stakeholders): they define
project priorities and constraints
Recognize that planning is iterative (not engraved in stone)
Estimate (efforts, costs, duration) based on what you know
Consider risk (and plan for contingencies)
Be realistic (people cannot be 100% efficient each day! )
Adjust granularity (i.e. level of detail) as you plan
Define how quality will be achieved (plan reviews, pairs, …)
Define how you’ll accommodate changes (timing, impact, cost)
Track what you’ve planned (and make adjustments)
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 13
Planning Practices
Identify: project objectives, milestones and schedules,
responsibilities, managerial and technical approaches,
required resources:
Ask Boehm’s questions [Barry Boehm, 1996]:
Why is the system begin developed?
What will be done?
When will it be accomplished?
Who is responsible?
Where are they located (organizationally)?
How will the job be done technically and managerially?
How much of each resource is needed?
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 14
Planning Practices
An abbreviated task set
Reassess project scope
Assess risks
Evaluate functions/features
Consider infrastructure functions/features
Create a coarse granularity plan
Number of software increments
Overall schedule
Delivery dates for increments
Create fine granularity plan for first increment
Track progress
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 15
Modeling Practices
We create models to gain a better understanding of
the actual entity to be built
Analysis models represent the customer
requirements by depicting the software in three
different domains: the information domain, the
functional domain, and the behavioral domain.
Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
componentlevel detail.
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 16
Analysis Modeling Practices
Analysis modeling principles
Represent the information domain (flow from/to users,
other systems, devices)
Represent software functions
Represent software behavior
Partition these representations (as a hierarchy)
Move from essence toward implementation
Elements of the analysis model (Chapter 8)
Data model
Flow model
Class model
Behavior model
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 17
Design Modeling Practices
Principles
Design must be traceable to the analysis model
Always consider architecture (interfaces, data flow, program
behaviour)
Focus on the design of data
Interfaces (both user and internal) must be designed with care
Components should exhibit functional independence
Components should be loosely coupled
Design representation should be easily understood
The design model should be developed iteratively (to simplify it)
Elements of the design model
Data design
Architectural design
Component design
Interface design
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 18
Construction Practices
Preparation principles: Before you write one line of code, be
sure you:
Understand of the problem you’re solving (see communication and
modeling)
Understand basic design principles and concepts.
Pick a programming language that best meets the needs of the
software to be built and the environment in which it will operate.
Select a programming environment that provides tools that will
make your work easier.
Create a set of unit tests that will be applied once the component
you code is completed.
you code is completed
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 19
Construction Practices
Coding principles: As you begin writing code, be sure you:
Constrain your algorithms by following structured programming
[BOH00] practice.
Select data structures that will meet the needs of the design.
Understand the software architecture and create interfaces that are
consistent with it.
Keep conditional logic as simple as possible.
Create nested loops in a way that makes them easily testable.
Select meaningful variable names and follow other local coding
standards.
Write code that is selfdocumenting.
Create a visual layout (e.g., indentation and blank lines) that aids
understanding.
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 20
Construction Practices
Validation Principles: After you’ve completed your first
coding pass, be sure you:
Conduct a code walkthrough when appropriate.
Perform unit tests and correct errors you’ve uncovered.
Refactor the code (integrating it to the overall design
architecture)
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 21
Construction Practices
Testing Principles:
All tests should be traceable to requirements
Tests should be planned
The Pareto Principle applies to testing (Roughly 80% of
errors will be traceable to 20% of components isolate
suspect components for rigorous testing)
Testing begins “in the small” and moves toward
“in the large”
Exhaustive testing is not possible
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 22
Deployment Practices
Principles:
Manage customer expectations for each increment
A complete delivery package should be assembled and tested
A support regime should be established
Instructional materials must be provided to endusers
Buggy software should be fixed first, delivered later
Buggy software should be fixed first, delivered later
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 23