Chapter 5

Practice: A Generic View

Software Engineering: A Practitioner’s Approach, 6th edition

by Roger S. Pressman

1
 Contents
• What is a Practice?
• Software Engineering Practice
• Communication Practices
• Planning Practices
• Modeling Practices
• Construction Practices
• Deployment Practices
 What is “Practice”?
• Practice is a collection of
– concepts
– principles
– methods
– tools
that a software engineer calls upon a daily basis.
• It allows managers to manage software’s and software
engineers to build computer programs.
• Populates a software process model with the necessary
technical and management how to’s to get the job done.
• Transforms a random unfocused approach into something
that is more organized, more effective and more likely to
achieve success.
 Software Engineering Practice
• A generic software process model establish a
framework for software engineering practice.

• Generic framework activities (communication,

planning, modelling, construction, and
deployment) and umbrella activities are used to
establish a skeleton architecture for software
engineering work.
A Generic Process Framework
• Communication
• Planning
• Modeling
- Analysis Modeling
- Design Modeling
• Construction
- Coding
- Testing
• Deployment
 The Essence of Practice
In the classic book, How to Solve It, written before modern computers existed,
George Polya outlined the essence of problem solving
- 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)

Understand the problem

- 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?
 The Essence of Practice (Cont.)
Plan the solution
• 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 sub-problems be defined? If so, are solutions readily apparent for the sub-problems?
• Can you represent a solution in a manner that leads to effective implementation? Can a
design model be created?
Carry out the plan
• Does the solution conform to the plan? Is source code traceable to the design model?
• Is each component part of the solution provably correct? Has the design and code been
reviewed, or better, have correctness proofs been applied to the algorithm?
Examine the result
• 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?
 Core Principles
• Principle means “an important underlying law or
assumption required in a system of thought.”
• Helps you to establish a mind-set for solid software
engineering practice.
• Focus on software engineering as a whole, others
consider a specific generic framework activity (e.g.,
communication), and still others focus on software
engineering actions (e.g., architectural design) or
technical tasks (e.g., write a usage scenario).
 Core Principles (7 principles)
The First Principle: The reason it all exists
The Second Principle: KIS (Keep It Simple)
The Third Principle: Maintain the Vision
The Fourth Principle: What You Produce, Others Will
Consume
The Fifth Principle: Be Open to the Future
The Sixth Principle: Plan Ahead for Reuse
The Seventh Principle: Think (before You Do)
 Communication Practices
• Before customer requirements can be analyzed,
modeled, or specified they must be gathered
through the communication activity.
• Road from communication to understanding is
often full of ambiguities.
• Effective communication (among technical peers,
with the customer and other stakeholders, and
with project managers) is among the most
challenging activities that you will meet.
 Communication Practices(Cont.)
Principles
Principle #1: Listen
Principle #2: Prepare before you communicate
Principle #3: Someone should facilitate the activity
Principle #4: Face-to-face communication is best
Principle #5: Take notes and document decisions
Principle #6: Strive for collaboration
Principle #7: Stay focused, modularize your discussion
Principle #8: If something is unclear, draw a picture
Principle #9: (a) Once you agree to something, move on.
(b) If you can’t agree to something, move on.
(c) If a feature or function is unclear and
cannot be clarified at the moment, move on.
Principle #10: Negotiation is not a contest or a game
 Planning Practices
• Since communication activity helps you to define
your overall goals and objectives (subject, of
course, to change as time passes), but
understanding them is not the same as defining a
plan for getting there.
• Encompasses a set of management and technical
practices that enable the software team to
define a road map as it travels toward its
strategic goal and tactical objectives.
 Planning Practices(Cont.)
• Principles
Principle #1: Understand the project scope
Principle #2: Involve the customer in planning
Principle #3: Recognize that planning is iterative
Principle #4: Estimate based on what you know
Principle #5: Consider risk as you define the plan
Principle #6: Be realistic
Principle #7: Adjust granularity as you define the plan
Principle #8: Define how you intend to ensure quality
Principle #9: Describe how you intend to accommodate
changes
Principle #10:Track the plan frequently and make
necessary adjustments
 Planning Practices (Cont.)
• Boehm's W5HH Organizing Principle. Answers to the
following questions lead to the project plan:
– 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?
 Modeling Practices
• Objective is to represent the information that software
transforms into architecture and supporting functions, the
features that user’s desire, and the behavior of the system.
• Two classes of models can be created: requirements models
and design models.
• Requirements models (also called analysis models) represent
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 component-level details.
 Modeling Practices (Cont.)
Analysis modeling principles
Principle #1: The information domain of a problem must be
represented and understood
Principle #2: The functions that the software performs must be
defined
Principle #3: The behavior of the software ( as a consequence of
external events) must be represented
Principle #4: The models that depict information, function, and
behavior must be partitioned in a manner that uncovers
detail in a layered (or hierarchical) fashion.
Principle #5: The analysis task should move from essential information
toward implementation detail.
 Modeling Practices (Cont.)
Design Modeling Principles
Principle #1: Design should be traceable to the analysis model
Principle #2: Always consider the architecture of the system to be built.
Principle #3: Design of data is as important as design of processing
functions.
Principle #4: Interfaces (both internal and external) must be designed
with care.
Principle #5: User interface design should be tuned to the needs of the
end user
Principle #6: Component level design should be functionally independent
Principle #7: Components should be loosely coupled to one another and
to the external environment
Principle #8: Design representations (models) should be easily
understandable.
Principle #9: The design should be developed . With each iteration, the
designer should strive for great simplicity
 Construction Practices
• Encompasses a set of coding and testing tasks that lead to operational
software that is ready for delivery to the customer or end user.
• Coding may be (1) the direct creation of programming language source
code (e.g., Java), (2) the automatic generation of source code using
intermediate knowledge, or (3) the automatic generation of executable
code using a “fourth-generation programming language” (e.g., Visual
programming).
• The initial focus of testing is at the component level, often called unit
testing. Other levels of testing include (1) integration testing (conducted
as the system is constructed), validation testing that assesses whether
requirements have been met for the complete system (or software
increment), and (3) acceptance testing that is conducted by the
customer in an effort to exercise all required features and functions.
• Construction principles are divided into coding and testing principles.
Construction Practices - Coding Principles
Preparation principles : Before you write one line of code, be
sure you
- Understand of the problem you’re trying to solve.
- Understand basic design principles and concepts.
- Pick a programming language that 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.
Construction Practices - Coding principles(Cont.)
Coding Principles: As you begin writing code, be sure you
- Constrain your algorithms by following structured programming [Boh00]
practice.
- Consider the use of pair programming.
- 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 self-documenting.
- Create a visual layout (e.g., indentation and blank lines) that aids
understanding.
Construction Practices - Coding principles(Cont.)
Validation Principles: After you’ve completed the first pass,
be sure you

• Conduct a code walkthrough when appropriate.

• Perform unit tests and correct errors you’ve uncovered.
• Refactor the code.
Construction Practices - Testing Principles
Testing Objectives:
- Testing is a process of executing a program with the intent of
finding an error.
- A good test case is one that has a high probability of finding an
as-yet- undiscovered error.
- A successful test is one that uncovers an as-yet-undiscovered error.

Testing Principles:
Principle #1: All tests should be traceable to customer requirements
Principle #2: Tests should be planned long before testing begins
Principle #3: The Pareto Principle applies to software testing
Principle #4: Testing should begin “in the small” and progress toward
testing “in the large”
Principle #5: Exhaustive testing is not possible
 Deployment Principles
• Encompasses three actions such as delivery, support, and feedback.
• It happens not only once, but a number of times as software move
toward completion.
• Each delivery cycle provides the customer and end users with an
operational software increment that provides usable functions and
features.
• Each support cycle provides documentation and human assistance for all
functions and features introduced during all deployment cycles to date.
• Each feedback cycle provides the software team with important
guidance that the results in modifications to the functions, features, and
approach taken for the next increment.
• The delivery of a software increment represents an important milestone
for any software project
 Deployment Practices (Cont.)
Principles
Principle #1: Customer expectations for the software must be
managed
Principle #2: A complete delivery package should be assembled
and tested
Principle #3: A support regime must be established before the
software is delivered
Principle #4: Appropriate instructional materials must be
provided to end users
Principle #5: Buggy software should be fixed first, delivered
later.