Software

Engineering
practice
-Srini

Agenda

Process Assessment
CMM
Software engineering practice
Communication practices
Planning practices
Analysis modeling practices
Design modeling practices
Construction practices
Deployment practices

Software process
improvement
Much

of the discussions on software

process improvement (SPI) during the
1990s have focused on software process
assessment and "best practice" models
such as the Capability Maturity Model
(CMM) for software

Process Assessment
What

is Process assessment ?
Why Process assessment ?

Process Improvement
An

increasingly popular way of starting

a SPI program is to do an assessment in
order to determine

the state of the organisations current

software processes
to determine high-priority issues
to obtain organisational commitment for
SPI.

Why process assessment ?

To understand and determine the organisations

current software engineering practices, and to
learn how the organisation works.
To identify strengths, major weaknesses and key
areas for software process improvement.
To facilitate the initiation of process improvement
activities, and enrol opinion leaders in the change
process.
To provide a framework for process improvement
actions.
To help obtain sponsorship and support for action
through following a participative approach to the
assessment.

Ways of assessing software

process
a

software organisation can make an

assessment of its development
practices: Benchmark against other
organisations.
Benchmark against "best practice"
models.
Assessment guided by the individual
goals and needs of the organisation

Traditional method
The

first way of doing an assessment is

a traditional benchmark exercise used to
gain an outside perspective on practices
and to borrow or "steal" ideas from bestin-class companies.
This type of benchmarking is "an
ongoing investigation and learning
experience that ensures that best
practices are uncovered, analysed,
adopted, and implemented."

Model based approach

The

second way of performing an

assessment is to benchmark the
company against one or more of the
"best practice" models on the market.
Over the years, several assessment
models have emerged in the software
industry, and there is a range of
possible assessment models that one
can choose from

Bench marking

Benchmarking is a time-consuming and

disciplined process that involves
(1) a thorough search to identify best
practice companies
(2) a careful study of ones own practices
and performance
(3) systematic site visits and interviews
(4) analysis of results
(5) development of recommendations, and
finally, (6) implementation

Model based approach

The

models focus on different aspects of

the software processes and the
organisation, and they are all associated
with specific strengths and weaknesses.
However, they share a common set of
problems
Besides, they are associated with both
statistical and methodological problems

Participative approach
During

the 1990s, "software process

assessment" has become synonymous
with the model-based approach.
Now we also proceed to a tailor made
and participative approach focusing on
what is unique to each company and
how this uniqueness can be exploited to
gain competitive advantage

Participative approach
The

process involved researchers and

practitioner acting together in a
participative approach to diagnose
problems in software development using
the basic principles of survey feedback
which is a specialised form of action
research

Capability Maturity Model

CMM:

Capability Maturity Model

Developed by the Software Engineering
Institute
Framework that describes the key
elements of an effective software
process.

What is CMM ?
Describes

an evolutionary improvement
path for software organizations from an
ad hoc, immature process to a mature,
disciplined one.
Provides guidance on how to gain
control of processes for developing and
maintaining software and how to evolve
toward a culture of software engineering
and management excellence

Process Maturity Concepts

Software

set of activities, methods, practices, and

transformations that people use to develop
and maintain software and the associated
products (e.g., project plans, design
documents, code, test cases, user manuals)

Software

Process

Process Capability

describes the range of expected results that

can be achieved by following a software
process
means of predicting the most likely outcomes
to be expected from the next software project
the organization undertakes

Process Maturity Concepts

Software

actual results achieved by following a

software process

Software

Process Performance
Process Maturity

extent to which a specific process is

explicitly defined, managed, measured,
controlled and effective
implies potential growth in capability
indicates richness of process and
consistency with which it is applied in
projects throughout the organization

CMM levels
Maturity level indicates level of process
capability:
Initial
Repeatable
Defined
Managed
Optimizing

CMM levels

Initial

Initial : The software process is

characterized as ad hoc, and occasionally
even chaotic. Few processes are defined,
and success depends on individual effort.

At this level, frequently have difficulty making

commitments that the staff can meet with an
orderly process
Products developed are often over budget and
schedule
Wide variations in cost, schedule, functionality
and quality targets
Capability is a characteristic of the individuals,
not of the organization

Repeatable
Basic

process management processes

are established to track cost, schedule,
and functionality. The necessary process
discipline is in place to repeat earlier
successes on projects with similar
applications.

Realistic project commitments based on results

observed on previous projects
Software project standards are defined and
faithfully followed
Processes may differ between projects
Process is disciplined
earlier successes can be repeated

Defined
The software process for both
management and engineering activities
is documented, standardized, and
integrated into a standard software
process for the organization. All projects
use an approved, tailored version of the
organizations standard software
process for developing an maintaining
software.

Managed
Detailed

measures of the software

process and product quality are
collected. Both the software process and
products are quantitatively understood
and controlled.

Narrowing the variation in process

performance to fall within acceptable
quantitative bounds
When known limits are exceeded, corrective
action can be taken
Quantifiable and predictable

predict trends in process and product quality

Optimizing
Continuous

process improvement is
enabled by quantitative feedback
from the process and from piloting
innovative ideas and technologies.
Goal is to prevent the occurrence of
defects

Causal analysis

Data

on process effectiveness used

for cost benefit analysis of new
technologies and proposed process
changes

Structure of CMM

Except for level 1, each level is decomposed

into key process areas (KPA)
Each KPA identifies a cluster of related
activities that, when performed collectively,
achieve a set of goals considered important
for enhancing software capability.

commitment
ability
activity
measurement
verification

Process area by maturity

level

SEI Core measures

Unit of Measure
Physical source lines of code
Logical source lines of code
Staff hours
Calendar dates for process
milestones
Calendar dates for deliverables
Problems and defects

Characteristics Addressed
Size, reuse, rework
Effort, cost, resource allocations
Schedule, progress
Quality, improvement trends,
rework, readiness for delivery

Examples of measurements
for size of work products
Estimated

number of requirements
Actual number of requirements
Estimated source lines of code (SLOC)
Actual SLOC
Estimated number of test cases
Actual number of test cases

Example of measurements of
effort
Estimated

man-hours to design/code a
given module
Actual man-hours expended for
designing/coding the module
Estimated number of hours to run builds
for a given release
Actual number of hours spent running
builds for the release

Examples of measurements
of quality of the work product
Number

of
inspection
Number of
Number of
Number of
inspection
Number of
testing

issues raised at requirements

requirements issues open
requirements issues closed
issues raised during code
defects opened during unit

Examples of measurements
of quality of the work product
Number

of defects
system testing
Number of defects
Number of defects
Number of defects
Defect age

opened during
opened during UAT
still open
closed

Examples of measurements
of quality of the work product
Total

number
Total number
release
Total number
accepted
Total number
rejected

of build failures
of defects fixed for a given
of defects verified and
of defects verified and

Software Engineering
Practice

Consists of a collection of concepts, principles,

methods, and tools that a software engineer
calls upon on a daily basis
Equips managers to manage software projects
and software engineers to build computer
programs
Provides necessary technical and management
how tos in getting the job done
Transforms a haphazard unfocused approach
into something that is more organized, more
effective, and more likely to achieve success

The Essence of Problem Solving

Understand the problem (communication and analysis)

1)

Who has a stake in the solution to the problem?

What are the unknowns (data, function, behavior)?
Can the problem be compartmentalized?
Can the problem be represented graphically?

Plan a solution (planning, modeling and software

design)

2)

Have you seen similar problems like this before?

Has a similar problem been solved and is the solution
reusable?
Can subproblems be defined and are solutions available
for the subproblems?

The Essence of Problem Solving

(continued)
Carry out the plan (construction; code generation)

3)

Does the solution conform to the plan? Is the source

code traceable back to the design?
Is each component of the solution correct? Has the
design and code been reviewed?

Examine the results for accuracy (testing and quality

assurance)

4)

Is it possible to test each component of the solution?

Does the solution produce results that conform to the
data, function, and behavior that are required?

Seven Core Principles for

Software Engineering
1)

Remember the reason that the software exists

2)

Keep it simple, stupid (KISS)

3)

Maintain the vision of the project

4)

Others will consume what you produce

5)

Be open to the future

6)

Plan ahead for software reuse

7)

Think, then act

The software should provide value to its users and satisfy the
requirements

All design and implementation should be as simple as possible

A clear vision is essential to the projects success

Always specify, design, and implement knowing that someone else

will later have to understand and modify what you did

Never design yourself into a corner; build software that can be

easily changed and adapted
Reuse of software reduces the long-term cost and increases the
value of the program and the reusable components
Placing clear, complete thought before action will almost always
produce better results

Communication Practices
(Requirements Elicitation)
Communication
Project initiation
Requirements
gathering Planning
Estimating
Scheduling
Tracking

Modeling
Analysis
Construction
Design
Code
Test

Deployment
Delivery
Support
Feedback
38

Communication Principles
1)
2)
3)
4)
5)
6)
7)
8)
9)

10)

Listen to the speaker and concentrate on what is being said

Prepare before you meet by researching and understanding
the problem
Someone should facility the meeting and have an agenda
Face-to-face communication is best, but also have a
document or presentation to focus the discussion
Take notes and document decisions
Strive for collaboration and consensus
Stay focused on a topic; modularize your discussion
If something is unclear, draw a picture
Move on to the next topic a) after you agree to something,
b) if you cannot agree to something, or c) if a feature or
function is unclear and cannot be clarified at the moment
Negotiation is not a contest or a game; it works best when
both parties win

Planning Practices
(Defining a Road Map)
Communication
Project initiation
Requirements
gathering Planning
Estimating
Scheduling
Tracking

Modeling
Analysis
Construction
Design
Code
Test

Deployment
Delivery
Support
Feedback40

Planning Principles
Understand the scope of the project
2) Involve the customer in the planning activity
3) Recognize that planning is iterative; things will change
4) Estimate based only on what you know
5) Consider risk as you define the plan
6) Be realistic on how much can be done each day by each
person and how well
7) Adjust granularity as you define the plan
8) Define how you intend to ensure quality
9) Describe how you intend to accommodate change
10) Track the plan frequently and make adjustments as
required
1)

Barry Boehms W5HH

Principle

Why is the system being developed?

What will be done?
When will it be accomplished?
Who is responsible for each function?
Where are they organizationally located?
How will the job be done technically and
managerially?
How much of each resource is needed?
The answers to these questions lead to a definition of key
project characteristics and the resultant project plan

Modeling Practices
(Analysis and Design)
Communication
Project initiation
Requirements
gathering Planning
Estimating
Scheduling
Tracking

Modeling
Analysis
Design

Construction
Code
Deployment
Test
Delivery
Support
Feedback43

1)

2)
3)
4)

5)

Analysis Modeling
Principles
The information domain of a problem (the data that flows

in and out of a system) must be represented and

understood
The functions that the software performs must be defined
The behavior of the software (as a consequence of
external events) must be represented
The models that depict information, function, and
behavior must be partitioned in a manner that uncovers
detail in a layered (or hierarchical) fashion
The analysis task should move from essential information
toward implementation detail

Design Modeling Principles

The design should be traceable to the analysis model
Always consider the software architecture of the system to be
built
3) Design of data is as important as design of processing functions
4) Interfaces (both internal and external) must be designed with
care
5) User interface design should be tuned to the needs of the enduser and should stress ease of use
6) Component-level design should be functionally independent
(high cohesion)
7) Components should be loosely coupled to one another and to
the external environment
8) Design representations (models) should be easily
understandable
9) The design should be developed iteratively; with each iteration,
the designer
should strive
greater that
simplicity
External
quality factors:
those for
properties
can be readily
1)
2)

observed
Internal quality factors: those properties that lead to a high-quality
design from a technical perspective

Construction Practices
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking

Modeling
Analysis
Design

Construction
Code
Deployment
Test
Delivery
Support
Feedback
46

Coding Principles
(Preparation before coding)

1)
2)
3)

4)
5)

Understand the problem you are 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

Coding Principles
(As you begin coding)

1)
2)
3)
4)
5)
6)
7)
8)

Constrain your algorithms by following structured

programming practices
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 code understanding

Coding Principles
(After completing the first round of code)

1)
2)
3)

Conduct a code walkthrough

Perform unit tests (black-box and white-box)
and correct errors you have uncovered
Refactor the code

Testing Principles

1)
2)
3)

All tests should be traceable to the software

requirements
Tests should be planned long before testing
begins
The Pareto principle applies to software testing

4)

Testing should begin in the small and

progress toward testing in the large

5)

80% of the uncovered errors are in 20% of the

code
Unit testing --> integration testing --> validation
testing --> system testing

Exhaustive testing is not possible

Test Objectives

1)
2)

3)

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 asyet undiscovered error

Deployment Practices
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking

Modeling
Analysis
Construction
Design
Code
Deployment
Test
Delivery
Support
Feedback

Deployment Principles
1)

Customer expectations for the software must be

managed

2)
3)
4)
5)

Be careful not to promise too much or to mislead the user

A complete delivery package should be assembled and

tested
A support regime must be established before the
software is delivered
Appropriate instructional materials must be provided to
end users
Buggy software should be fixed first, delivered later