Unit-3: Techniques of Planning, Controlling and Automating Software Process

3.1.1 Work Breakdown Structures

KEY points:
I. Conventional WBS Issues:
Projects can under-plan and they can over-plan. Once
again, balance is paramount in the level of planning Conventional WBS frequently suffers from three
detail and the buy-in among stakeholders. fundamental flaws:

The Work break down structure is the “architecture” 1. Conventional WBS is prematurely structured
of the project plan. It must encapsulate change and around the product design:
evolve with the appropriate level of detail throughout
The figure following shows the typical conventional
the life cycle.
WBS that has been structured primarily around
Cost and schedule budgets should be estimated using subsystems of its product architecture, the further
macro analysis techniques (top-down project level) decomposed into the components of each subsystem.
and microanalysis technique (bottom-up task level) to
Once this structure is ingrained in the WBS and then
achieve predictable results. allocated to responsible managers with budgets,
schedules and expected deliverables, a concrete
3.1 Iterative Process Planning:
planning foundation has been set that is difficult and
3.1.1 Work Breakdown Structures expensive to change.

3.1.2 Planning Guidelines

3.1.3 The Cost and Schedule Estimating Process

3.1.4 The Iteration Planning Process

3.1.1 Work Breakdown Structures

Q. Define WBS and explain in detail?

A WBS is simply a hierarchy of elements that

decomposes the project plan into the discrete work
tasks. A WBS provides the following information
structure:

A delineation of all significant work

A clear task decomposition for assignment of

responsibilities

A framework for scheduling, budgeting, and

expenditure tracking.

Many parameters can drive the decomposition of

work into discrete tasks: Figure: Conventional work breakdown structure
▪ Product subsystem
▪ Components
▪ Functions
▪ Organizational unit and life-cycle phases

1|P ag e
Unit-3: Techniques of Planning, Controlling and Automating Software Process

2. Conventional WBS are prematurely decomposed,

planned, and budgeted in wither too much or too little The basic recommendation for the WBS is to organize
detail: the hierarchy as follows:

Large software projects tend to be over planned and First level WBS elements are the workflows
small projects tend to be under planned. The WBS (Management, environment, requirement, design,
shown in the above figure is overly simplistic for most implementation, assessment, and deployment)
large scale systems, where size or more levels of
WBS elements are commonplace. Second level elements are defined for each phase
of the life cycle (inceptions, elaboration, construction
3. Conventional WBS are project-specific, and cross- and transition)
project comparisons are usually difficult or
impossible: Third level elements are defined for the focus of
activities that produce the artifacts of each phase.

Most organizations allow individual projects to define A default WBS consistent with the process
their own project-specific structure tailored to the framework (phases, workflows, and artifacts) is
project manager’s style, the customer’s demands, or shown in the following figure:
other project-specific preferences.

It is extremely difficult to compare plans, financial

data, schedule data, organizational efficiencies, cost
trends, productivity tends, or quality tends across
multiple projects.

Some of the following simple questions, which are

critical to any organizational process improvement
program, cannot be answered by most project teams
that use conventional WBS.

▪ What is the ratio of productive activities to

overhead activities?
▪ What is the percentage of effort expanded in
rework activities?
▪ What is the percentage of cost expended in
software capital equipment
▪ What is the ration of productive testing versus
integration?
▪ What is the cost of release?

II. Evolutionary Work Breakdown Structures:

An evolutionary WBS should organize the planning Figure: Continued (next)

elements around the process framework rather than
the product framework.

2|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

components would have much more depth in the

requirements elements and a fairly shallow design and
implementation element.
Business context: contractual projects require much
more elaborate management and assessment elements.
Projects developing commercial products for delivery to
a board customer base may require much more elaborate
substructures for the deployment element.
Precedent experience: very few projects start with a
clean state. Most of them are developed as new
generations of a legacy system or in the context of
existing organizational standards. It is important to
accommodate these constraints to ensure that new
projects exploit the existing experience base and
benchmarks of project performance.
Another important attribute of a good WBS is that the
planning fidelity inherent in each element is
commensurate with the current life-cycle phase and
project state, as shown in figure
Figure: Default Work Breakdown Structure

The structure shown is intended to be merely a starting

point. It needs to be tailored to the specifics of a project
in many ways.
Scale: Larger projects will have more levels and
substructures.
Organizational structure: projects that include
subcontractors or span multiple organizational entities
may introduce constraints that necessitate different
WBS allocations.
Degree of custom development: depending on the
character of the project there can be very different Figure: Evolution of planning fidelity in the WBS over
emphases in the requirements, design, and Life Cycle
implementation workflows. A business process re-
engineering project based primarily on existing
3|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

3.1.2 Planning Guidelines these values are certain to vary across projects, this
Q. Write short notes on planning guidelines? allocation provides a good benchmark for assessing the
Software projects span a board range of application plan by understanding the rationale for deviations from
domains. It is valuable but risky to make specific these guidelines.
An important point here is that this is cost allocation,
planning recommendations independent of project not effort allocation. To avoid misinterpretation two
context. Project independent planning advice is also explanations are necessary
risky. There is the risk that the guidelines may be 1. The cost of different labor categories is inherent in
adopted blindly without being adapted to specific these numbers
project circumstances. There is also the risk of
misinterpretation. Two simple planning guidelines 2. The cost of hardware and software assets that support
the process automation and development teams is also
should be considered when a project plan is being
included in the environment element.
initiated or assessed.

▪ The first guideline prescribes a default

allocation of costs among the first-level WBS
elements.
▪ The second guideline prescribes the allocation
of effort and schedule across the life cycle
phases.

Given an initial estimate of total project cost and these The second guideline prescribes the allocation of
two tables, developing a staffing profile and allocation effort and schedule across the life-cycle phases
of staff resources to reams, a top-level project schedule, The above table provides guidelines for allocating
and an initial WBS with task budgets and schedules is effort and schedule across the life cycle phases.
relatively straightforward. Although these values can also vary widely depending
on the specific constraints of an application, they
Table: WBS Budgeting defaults
provide an average expectation across a spectrum of
application domains.

3.1.3 The Cost and Schedule Estimating Process

Q. Explain the cost and schedule estimating process?

Project plans need to be derived from two perspectives.

The first is a forward-looking top-down approach. It
starts with as understanding of the general requirements
and constraints, derives a macro –level budgets and
intermediate milestones.

Forward-looking:
The 1. The software project manager develops a
first guideline prescribes a default allocation of costs
characterization of the overall size, process,
among the first-level WBS elements
environment, people, and quality required for the
The above table provides default allocations for project
budgeted costs of each first-level WBS element. While

4|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

2. A macro-level estimate of the total effort and 3.1.4 The Iteration Planning Process
schedule is developed using a software cost estimation
model Till now, discussion has dealt only with the application-
independent aspects of budgeting and scheduling.
3. The software project manager partitions the estimate Another dimension of planning is concerned with
for the effort into a top-level WBS, also partitions the defining the actual sequence of intermediate result.
schedule into major milestone dates and partitions the
effort into a staffing profile By then, the top-down approach should be well tuned to
the project specific parameters, so is should be used
4. At this point, subproject managers are given the more as a global assessment technique. The following
responsibility for decomposing each of the WBS figure shows this life cycle planning balance.
elements into lower levels using their top-level
allocation, staffing profile, and major milestone dates as
constraints.

The second perspective is a backward-looking,

bottom-up approach. We start with the end in mind,
analyze the micro-level budgets and schedules, the sum
all these elements into the higher level budgets and
intermediate milestones.

Backward-looking:

1. The lowest level WBS elements are elaborated into

detailed tasks, for which budgets and schedules are
estimated by the responsible WBS element manager. Figure: Planning balance throughout the Life Cycle
2. Estimates are combined and integrated into higher 3.2 Project Organization and Responsibility
level budgets and milestones. Key points:
▪ Organizational structures form the architecture
3. Comparisons are made with the top-down budgets of the teams
and schedule milestones. Gross differences are assessed ▪ Organizations engaged in a software line of
and adjustments are made in order to converge on business need to support projects with the
agreement between the top-down and the bottom-up infrastructure necessary to use a common
estimates. process.
▪ Project organizations need to allocate artifacts
These two planning approaches should be used together, and responsibilities clearly across project teams
in balance, throughout the life cycle of the project. to ensure a balance of global (architecture) and
During the engineering stage, the top-down perspective local (component) concerns.
▪ The organization must evolve with the WBS and
will dominate. During the production stage, these
the life-cycle concerns.
should be enough precedent experience and planning
fidelity that the bottom up planning perspective will Introduction to lines-of business and project
dominate. teams:

▪ Software lines-of business and project teams

have different motivation.

5|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

▪ Software lines of business are motivated by Software Engineering Process Authority: The
return on investment, new business Software Engineering Process Authority (SEPA)
discrimination, market verification and facilitates the exchange of information and process
profitability. guidance both to and from project practitioners. The
▪ Project teams are motivated by cost, schedule SEPA must help initiate and periodically assess project
and quality of specific deliverable. process. The SEPA is necessary role in any
organization. The SEPA could be a single individual,
3.2.1 Line of Business Organizations: the general manager, or even a team of representatives.
Q. what are the types of responsibilities does the The SEBA must truly be an authority, competent and
project organizations have? powerful.

Map roles and responsibilities to a default line-of- Project Review Authority: The project review
business organization. This structure can be tailored to authority (PRA) is the single individual responsible for
specific circumstances. ensuring that a software project complies with all
organizational and business unit software policies,
The main features of the default organization are as practices, and standards. The PRA reviews both the
follows: project’s conformance to contractual obligations and the
▪ Responsibility for process definition and project’s organizational policy obligations. The
maintenance is specific to a cohesive line of customer monitors contract requirements, contract
business where process commonality makes milestones, contract deliverable, monthly management
sense. For example the process of developing reviews, progress, quality, cost, schedule and risk. The
avionics software is different from the process PRA reviews customer commitments as well as
used to develop office applications. adherence to organizational policies, organizational
deliverables, and financial performance and other risks
▪ Responsibility for process automation is an and accomplishments.
organizational role and it’s equal in importance
to the process definition role. Software Engineering Environment Authority:
The Software Engineering Environment Authority
▪ Organizational role may be fulfilled by a single (SEEA) is responsible for automating the organizations
individual or several different teams, depending process, maintaining the organizations standard
on the scale of the organization. environment, training project to use environment, and
maintain organization-wide reusable assets. The SEEA
rule is necessary to achieve significant return on
investment for a common process.

Infrastructure:
An organization infrastructure provides human resource
support, project-independent research and development,
and other capital software engineering assets.
The typical components of the organizational
infrastructure are as follows:

Project Administration:
Time accounting system; contract, pricing, terms and
condition; corporate information system integration.

Figure: Default roles in a software line-of-business

organization

Engineering Skill Centers:

6|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

Custom tools repository and maintenance, bid and

proposal support, ind3ependent research and
development.

Professional Development: Internal training boot

camp, personnel recruiting, personnel skills database
maintenance, literature and assets library, technical
publications.

3.2.2 Project Organizations

Q. Explain in detail about Project Organizations and
how it handles their teams?
A default project organization maps project-level roles
and responsibilities. The structure can be tailored to the
size and circumstances of the specific project
organization.
The main features of the default organization are as
follows:

The project management team is an active participant,

responsible for producing as well as managing.

The architecture team is responsible for real artifacts

and for the integration of components, not just for staff
function.

The development team owns the component

construction and maintenance activities.

Quality is everyone job, integrated into all activities Figure: Default Project Organization
and check points. Each team takes responsibility for a
different quality perspective. Software Management Team: Most projects are over
constrained. Schedules, cost, functionality and quality
expectations are highly inter related and require
continuous negotiation among multiple stake holders
who have different goals. The software management
team carries the burden of delivering with condition to
all stake holders. The software management team takes
ownership of all aspects of quality.

7|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

Figure: Software architecture team activities

Figure: Software management team activities Software development team: The software
development team is the most application specific
Software Architecture Team: group. In general, the software development team
The software architecture team is responsible for the comprises several sub teams dedicated to groups of
architecture. This responsibility encompasses the components that require a common skill set. The typical
engineering necessary to specify a complete bill of skill set include the following:
materials for the software and the engineering necessary
to make significant make/ buy trade-offs so that all Commercial component: Specialists with detail
custom components are elaborated to the extent that knowledge of commercial components central to a
construction/assembly costs are highly predictable. system’s architecture
In most projects, the inception and elaboration phases Database: specialists with experience in the
will be dominated by two distinct teams: the software organization, storage, and retrieval of data
management team and the software architecture team. Graphical user interfaces: specialists with experience
To succeed, the architecture must include a fairly broad
in the display organization, data presentation, and user
level of expertise, including the following: interaction.
Operating systems and networking: specialist with
▪ Domain experiences to produce an acceptable experience in the execution of multiple software objects
design view (architecturally significant elements on a network of hardware resources.
of the design model) and use case view Domain applications: specialists with experience in
(architecturally significant elements of the use the algorithms, application processing.
case model).

▪ Software technology experience to produce an

acceptable process view (concurrency and
control thread relationships among the design,
component, and deployment models),
component view (structure of the
implementation set), and deployment view
(structure of the deployment set).

Figure: Software Development team activities

8|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

The software development team is responsible for the ensure that the plans represent a consensus of all
quality of individual components, including all perspectives.
component development, testing, and maintenance.
Components tests should be built as self-documented.

Software Assessment Team: There are two reasons for

using an independent team for software assessment. It
has to do with ensuring an independent quality
perspective. A more important reason for using an
independent test team is to exploit the concurrency of
activities. A modern process should employ use-case-
oriented or capability –based testing (which may span
many components) organized as a sequence of builds
and mechanized via two artifacts:

Release specification (the plan and evaluation criteria

for a release) Figure: Software project team evolution after life cycle
Release description (the results of a release)
Elaboration team: an architecture focused
organization in which the driving forces of the project
reside in the software architecture team and are
supported by the software development software
assessment teams has necessary to achieve a stable
architecture baseline

Construction team: a fairly balanced organization in

which most of the activity resides in the software
development and software assessment teams

Figure: Software assessment team activities Transition team: customers focus organization in
which usage feedback drives the deployment activities.
3.2.3 Evolution of Organization
3.2 Process Automation
Q. Explain in detail about the evaluation of Computer-aided software engineering (CASE)
organizations? • Computer-aided software engineering (CASE) is
The project organization represents the architecture of software to support software development and
the team and needs to evolve consistent with the project evolution processes.
plan captured in the work breakdown structure. The
• Activity automation
following figure illustrates how the team’s centre of
gravity shifts over the life cycle, with about 50% of the – Graphical editors for system model
staff assigned to one set of activities in each phase A development;
different set of activities is emphasized in each phase, – Data dictionary to manage design entities;
as follows: – Graphical UI builder for user interface
construction;
Inception team: an organization focused on – Debuggers to support program fault
planning, with enough support from the other teams to
finding;

9|P ag e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

– Automated translators to generate new CASE Integration:

versions of a program. • Tools
• Case technology has led to significant – Support individual process tasks such as
design consistency checking, text
improvements in the software process. However,
editing, etc.
these are not the order of magnitude improvements • Workbenches
that were once predicted – Support a process phase such as
– Software engineering requires creative specification or design, Normally
thought - this is not readily automated; include a number of integrated tools.
– Software engineering is a team activity and, • Environments
for large projects, much time is spent in – Support all or a substantial part of an
entire software process. Normally
team interactions. CASE technology does
include several integrated workbenches.
not really support these.
Process Automation
CASE Classification: Tools, Workbenches, Environments:
• Classification helps us understand the different CASE
types of CASE tools and their support for techn olo g y

process activities.
• Functional perspective
– Tools are classified according to their Too ls Wor kben ch es Environ ments
specific function.
• Process perspective
– Tools are classified according to
File Integrated Process-centr ed
process activities that are supported. Editors Compilers
comp ar ators en viron ments en viron ments
• Integration perspective
– Tools are classified according to their
organisation into integrated units. Analysis and
Pro gramming Testin g
design
Functional Tool Classification:

Multi-method Single-metho d Gener al-purp ose Langua ge-specific

workben ch es workben ch es workben ch es workben ch es

3.3 Process Automation

Many software development organizations are
focused on evolving mature processes to improve
the predictability of software management and
performance of their software lines of business (in
terms of product quality, time to market, ROI,
productivity).
A significance level of process automation is also
required in order for modern software development
project to profitability.

10 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

3.3. Levels of Automation Many tools are available to automate the software
development process. Most of the core software
Meta-process development tools map closely to one of the process
workflows, as illustrated in the following figure.
– An organization’s policies, procedures, and
practices for the software intensive-line of Each of the process workflows has a distinct for
business automation support.
– The automation support for this level is called
an infrastructure.
– Where, an infrastructure, is an inventory of
preferred tools, artifact templates, guidelines,
project repositories, skill sets, library of
precedent example of past project plans and
result.
Macro-process
– Project’s policies, procedures and practices for
producing a complete software product within
certain cost, schedule and quality.
– The automation support for the project’s
process is called environment.
– An environment is a specific collection tools to
produce a specific set of artifacts as governed by Management: there are many opportunities for
specific project plan. automating the project planning and control
Micro-process activities of the management work flows. Software
cost estimating tools and WBS tools are usual for
– Project team’s policies and practices for generating the planning artifacts. Environment:
achieving an artifact of the process.
configuration management and version control are
– The automation support for generating an
artifact is generally called tool. essential in a modern interactive development
– Typically tool include; requirement process.
management, visual modeling, compiler,
editors, debuggers, document automation, test Environment:
automation etc… Configuration management and version control are
essential in a modern iterative development
3.3 Process Automation process.
3.3.1 Automation building blocks
3.3.2 The project environment Requirements: conventional approaches
– Round-trip engineering decomposed system requirements into subsystems
– Change management requirements, subsystem requirements into
– Infrastructures component requirement and component
– Stakeholder environments requirements into unit requirements. In a modern
project the system requirements are captured in the
vision statement. Lower levels of requirements are
3.3.1Tools: Automation Building Block driven the process organized by iteration rather than
Q. What are all the automation tools available by lower level component.
for building blocks in software process?
Design: the primary support required for the design
work flow is visual modeling, which is used for
11 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

capturing design models, presenting them in human Four Important Environment

readable format, and translating them into source Disciplines:
code. An architecture first and demonstration based • Integration of tools to support round-trip
process is enabled by existing architecture engineering for iterative development.
components and middle ware. • Change management automation to manage
multiple iterations AND change freedom.
Implementation: the implementation work flow • Organizational Infrastructure to enable
relies primarily on a programming environment but environments derived from a common base.
must also include substantial integration with the – Promotes inter-project consistency, reuse of
training, and reuse of lessons learned.
change management tools, visual modeling tools,
• Automation support for Stakeholder environment
and test automation tools to support productive
iteration. Assessment and deployment: the
– Provides support for paperless exchange of
information and effective review of
assessment workflows require all the tools just
engineering artifacts.
discussed as well as additional capabilities to
support test automation and test management.
Defect tracking is another important that supports 3.3.2.1 Round-trip Engineering
assessment. ▪ Software industry moves into maintaining different
information sets for the engineering artifacts, more
automation support is needed to ensure efficient and
3.3.2 The Project Environment: error-free transition of data from one artifact to
another.
The project environment artifacts evolve through three ▪ Round-trip engineering is the environment support
discrete states: necessary to maintain consistency.
• The Prototype Environment ▪ Figure (next) shows transition between information
• The Development Environment repositories.
• The Maintenance Environment -automation translation of design model to
source code
I. The Prototype Environment includes an - Automation translation of design model to
architecture testbed for prototyping project architecture process model
to evaluate during the inception and elaboration phase.
These capable of supporting following activity:
• Performance trade-offs
• Technical risk analysis
• Make/buy tradeoffs
• Fault tolerance trades
• Transitioning risks
• Test scenarios

II. The Development Environment should include

development tools to support
-Process workflow
- Round-trip engineering to maximum extent possible.

III. The Maintenance Environment

• Mature version of the development environment
• Subset of development environment delivered as
projects end product. Figure: Round-trip engineering

12 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

3.3.2.2 Change Management: ▪ Type 0: Critical Failure, which are defects that
In modern process-in which requirement, design and are nearly always fixed before any external
implementation set artifacts are captured in rigorous release.
notations early in life cycle and evolved through ▪ Type 1: A Bug or defect that either does not
multiple generations- change management has become impair the usefulness of system or be worked
fundamental to all phases and almost all activities. around.
▪ Type 2: A change that is an enhancement rather
Software Change Orders (SCO) than a response to a defect.
Software Change Orders (SCO) is used to create, ▪ Type 3: A change that is necessitated by an
modify, or obsolesce components within configuration update to the requirements(i.e. new features)
baseline. ▪ Type 4: Changes that are not accommodated by
Software Change Orders are used for partitioning, the other categories
allocating and scheduling software work against an
established software baseline and for assessing progress There are generally two classes of baselines: external
and quality. product release and internal testing releases .For
The example of SCO is shown in the figure, which is a example, the development organization may release a
good starting point describing a set of primitives. configuration baseline to test organization or even to
itself.

Release History:
Examples of Some release name histories for two
different situations.

Figure: The primitive components of software

Configuration Control:
Configuration Baseline: • Configuration Control Board
A configuration baseline is a named collection of – Manages releases
software components and supporting documentation – Makes change decisions
that is subject to change management and is upgraded, • Membership
maintained, tested. – Software manager(s), system engineer
Once software is placed in controlled baseline, all (sometimes), key software architect
changes are tracked. A distinction must be made for (sometimes), customer representatives.
cause of a change. • General comment
Change categories are: – It’s never dull! Can be the most fun and
exciting software management job of all.
13 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

3.3.2.3 Infrastructure: • On-line extension to stakeholder environment

From a process automation perspective, the enables hands-on evaluations, use of same tools
organization infrastructure provides the organization’s to manage and monitor the project, and
capital assets, including two key artifacts: minimizes customer travel and paper exchanges.
-A policy that captures the standards for project Some of the new opportunities for value added
software development process activities by external stakeholder.
-And an environment that captures an inventory of tools
Organizational Policy
• The organization policy is usually packaged as a
handbook that defines the life cycle and process
primitives (major milestones, intermediate
artifacts, engineering repositories, metrics, roles
and responsibilities)
The handbook provides a general framework for
answering the following questions.
– What gets done?, when does it get done?, who does
it?, how do we know that it is adequate (checkpoints,
metrics and standards of performance).
Organization Environment:
• The organization environment for automating
the default process will provide many of the Figure: Extending environments into Stakeholder
answer to how things get done as well as the Domain
tools and techniques to automate the process.
• Some of the typical components of an 3.4 Project control and process
organization’s automating building blocks are: instrumentation:
– Standardized tool selections (promote The primary themes of a modern software development
common workflow, higher ROI). process tackle the central management issues of
– Standard notations for artifacts (as UML for complex software:
all design). ▪ Getting the design right by focusing on the
– Tool adjuncts such as artifact templates architecture first
(architecture description, evaluation criteria, ▪ Managing risk through iterative development
release descriptions, status assessments ▪ Reducing the complexity with component based
– Activity templates (iteration planning, major techniques
milestones, configuration control boards. ▪ Making software progress and quality tangible
Additional components through instrumented change management
– Reference library for planning, etc. ▪ Automating the overhead and bookkeeping
– Existing case studies activities through the use of round-trip
– Project artifacts library engineering and integrated environment

3.3.2.4 Stakeholder Environment The quality of software products and the progress made
• The transition to a modern iterative development toward project goals must be measurable throughout the
process with supporting automation should not software development cycle. The goals of software
be restricted to the development team. metric are to provide the development team and the
• Many large scale contractual projects include management team with the following:
people in external organization that represent ▪ An accurate assessment of progress to date
other stakeholder. ▪ Insight into the quality of the evolving software
• These stakeholder representatives also need product
access to development environment resource so
that they can contribute value to overall effort.
14 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

▪ A basis for estimating the cost and schedule for Metrics Characteristics:
completing the product with increasing accuracy
over time • They are simple, objective, easy to collect, easy
to interpret, and hard to misinterpret.
3.4.1 Seven Core Metrics: • Collection can be automated and non-intrusive.
Many different metric may be of value in managing • Assessment is continuous and non-subjective.
modern process. • They are useful to both management and
engineering personnel for communicating
Management indicators: progress and quality in a consistent format.
▪ Work and progress(worked performed over • Their fidelity improves across the life cycle.
time) 3.4.1.1 Management Indicator
▪ Budget cost and expenditure(cost incurred over Three Basic Management Metrics:
time) • Technical progress
▪ Staffing and team dynamics(personnel change • Financial status
overtime) • Staffing progress
Quality Indicator:
▪ Change traffic and stability(change traffic over Financial and staffing metrics are easy. The real
time) problem is to measure technical progress with
▪ Breakage and modularity(average breakage per objectivity
change over time)
▪ Rework and adaptability(average rework per Q. How do you measure technical progress with
change over time) objectivity” Work and progress”.
▪ Mean time between failures(MTBF) and
maturity(defect rate overtime) 3.4.1.1.1 Work and progress
▪ The various activities of an iterative development
project can be measured by defining a planned
Overview of the seven core metric: estimate of the work in an objective measure, then
tracking progress (work completed over time)
Table describes the core software metrics. against that plan.
▪ Each major organizational team should have at least
one primary progress perspective that it is measured
against.

Figure: Expected progress for a typical project with

three major release

3.4.1.1.2 Budget Cost and Expenditures

Tracking financial progress usually takes on an
organizational format.
Each metric has two dimensions: A static value used
Modern software processes are amenable to financial
as an objective and the dynamic trend used to performance measurement through an earned value
manage the achievement of that objective. approach. The basic parameters of an earned value
15 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

system, usually expressed in units of dollars, are

follows:
Expenditure plan:
The planned spending profile for a project over its
planned schedule. For most software projects (and other
labor-intensive projects), this profile generally tracks
the staffing profile.

Actual progress:
The technical accomplishment relative to the planned
progress underlying the spending profile. In a healthy
project, the actual progress tracks planned progress
closely.
Actual cost:
The actual spending profile for a project over its actual
schedule. In a healthy project, this profile tracks the
planned profile closely.
Earned value: Figure: the basic parameters of an earned value
The value that represents the planned cost of the actual system
progress.
Cost variance:
The difference between the actual cost and the earned
value. Positive values corresponds to over-budget
situations, negative values correspond to under-budget 3.4.1.1.3 Staffing and Team Dynamics
situation. An iterative development should start with a small team
Schedule variance: until the risks in the requirements and architecture have
The difference between the planned cost and the earned been suitably resolved. Depending on the overlap of
value. Positive values correspond to behind-schedule iterations and other project-specific circumstances,
situations; negative values correspond to ahead-of- staffing can vary. For discrete, one-of-a-kind
schedule situation. development efforts, the staffing profile in figure would
be typical.
Figure provides a graphical perspective of these It is reasonable to expect the maintenance team to
parameters and shows a simple example of a project smaller than the development team for these short of
situation. development.

Tracking actual versus and planned staffing is a

necessary well-understood management metric.

Figure: Typical staffing profile

16 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

• Metric: For a healthy project, the trend expectation is

– Percent staffed. decreasing or stable
• Metric: staffing momentum
– Additions versus attrition.
• Glaring indicator of future trouble:
– Unplanned attrition. Usually due to
personnel dissatisfaction with
management, lack of teamwork, or high
probability of failure to meet objectives.

3.4.1.2 Quality Indicator:

The four quality indicators are based primarily on the
measurement of software change across evolving
baseline of engineering data (such as design model and Figure: Modularity expectation over a healthy project’s
source code). life cycle
3.4.1.2.3 Rework and Adaptability:
3.4.1.2.1 Change Traffic and Stability Rework: amount of effort needed to fix.
Provides insight into stability, convergence toward Adaptability: rework trend over time.
stability, predictability of completion
▪ Change traffic is defined as the number of For a healthy project, the trend expectation is
software change orders opened and closed over decreasing or stable
the life cycle.
▪ Stability is defined as the relationship between
opened versus closed SCOs.
▪ The change traffic relative to the release
schedule provides insight into schedule
predictability, which is the primary value of this
metric and an indicator of how well the process
is performed.
▪ The next three quality metrics focus on quality
of the product. Figure: Adaptability expectation over a healthy
project’s life cycle

3.4.1.2.4 MTBF and Maturity

▪ MTBF is the average time between software faults.
MTBF is computed by dividing the test hours by the
number of type 0 and type 1 SCOs
▪ Maturity is defined as the MTBF trend over time.

Early insight into maturity requires that an effective test

infrastructure be established.
Figure: stability expectation over a healthy project’s
life cycle

3.4.1.2.2 Breakage and Modularity

Breakage: extent of change needed (in SLOC, function
point).
Modularity: average breakage trend over time.

17 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

Table: The default pattern of life-cycle metrics

Figure: Maturity expectation over a healthy project’s

life cycle

Project Control and Process Instrumentation

The Core Metrics (overview)

3.4.3 Pragmatic Software Metric:

Because of the highly dynamic nature of software

projects, measuring must be available at any time,
tailor-able to various subsets of evolving product
(release, version, component, class) and maintained so
that trends can be assessed (first and second derivatives
with respect to time).

This situation has been achieved in practice only in

projects where the metrics were maintained on-line as
an automated by-product of the
3.4.2 Life-cycle expectation development/integration environment.
There is no mathematical or formal derivation for
using the seven core metrics. However, there were The basic characteristics of a good metric are as follows:
specific reasons for selecting them.
Quality Indicator Characteristics ▪ It is considered meaningful by the customer,
• They are derived from the evolving products, manager, and performer(customer is always
not other artifacts. right)
• They provide insight into waste. ▪ It demonstrates quantifiable correlation
• They are dynamic for an iterative process. between process perturbation and business
Focus is on trends and changes in time. performance (organization goal are financial).
• Combination of current value and trends provide ▪ It is objective and unambiguously defined
tangible indicators for effective management (numeric representation (number, percentage)
action. preferred than textual (good, excellent).
▪ It displays trend(understanding the change in
The actual values of these metrics can vary widely metric’s value with respect to time, subsequent
across projects, organization and domains. The relative projects and release).
trends across the project phases, however, should ▪ It is a natural by-product of the process(derived
from mainstream engineering and management
follow the general pattern shown in table.
workflow)

18 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

▪ It is supported by automation(successful metric • Actors: typically, the monitor and

are those that are collected by automated tools) administrator.
3.4.4 Metrics Automation
Metrics Classes
There are many opportunities to automate the project
control activities of a software project. For managing Metric can be displayed with or without control values.
against a plan, a software project control panel (SPCP) A control value is an existing expectation, either
that maintains an online version of the status of evolving absolute or relative, that is used for comparison with a
artifacts provides a key advantage. dynamically changing metric. For example, the plan for
a given progress metric is control value for comparing
The idea is to provide a display panel that integrates data the actual of that metric.
from multiple sources to show the current status of some
aspect of the project. For example, the software project Trends, comparisons, and progression are shown in
manager would want to see a display with overall Figure
projects values.

Metrics Automation – the Software Project Control

Panel (SPCP)

• On-line version of status of artifacts.

• Display panel that integrates data. A
“dashboard”.
• Display for –
– project manager (overall values)
– test manager (status of an upcoming
release)
– Configuration Manager (change traffic)
– etc.
To implement a complete SPCP, It is necessary to
define and develop the following:
• Metrics primitives: indicator, trends,
comparisons Figure: Example of thefundmental metric classes
• A graphical user interface: GUI support for a
software project manager role and flexibility to Figure given below illustrates a simple example of an
support other roles SPCP for a project. In this case, the software project
• Metrics collection agents: data extraction from manager role has defined a top level display with four
the environment tools that maintain the graphical objects.
engineering notations for the various artifacts
sets.
• Metrics data management server: data
management support for populating the metric
displays of the GUI and storing the data
extracted by the agents.
• Metrics definitions: actual metrics
presentations for requirements
progress(extracted from requirements set
artifacts), design progress(extracted from design
set artifacts),etc
19 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

In tailoring the management process to a specific

domain or project there are two dimensions of
discriminating factors:

▪ Technical Complexity
▪ Management complexity

The Figure given below illustrates the two dimensions

of the process variability and shows some example
project applications.

Figure: Example of SPCP display for top-level

project situation.

3.4 Tailoring the Process

Software management efforts span a broad range of
domain. While there are some universal themes and
techniques, it is always necessary to tailor the process to
specific needs of the project at hand. A commercial
software tool developer with complete control of its
investment profile will use a very different process from
that of a software integrator on contract to automate
security system for a nuclear power plant.
Figure: The two primary dimensions of process
Key points: variability
▪ The process framework must be configured to the
specific characteristics of the project
The figure given below summarizes the different
▪ The Scale of the project (Team size ) drives the
process configuration more than any other factor
priorities along the two dimensions
▪ Other key factors include Stakeholder
relationship, Process flexibility, Process maturity,
architectural risk & domain experience.
▪ While specific process implementations will vary
but the spirit underlying the process is the same
3.5.1 Process Discriminants:

20 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

From a process tailoring perspective the primary

measure of the scale is the size of the team. As the
headcount increases the importance of consistent
interpersonal communication becomes paramount

Projects are categorized into

• Trivial-sized projects( 1 people )requires almost
no management overhead
• Small projects ( 5 people )require very little
management overhead but team leadership
toward a common objective is crucial
• Moderate-sized projects( 25 people )require
moderate management overhead
• Large projects( 125 people ) require substantial
management overhead
• Huge projects( 625 people )require management
overhead

Figure: Priorities for tailoring the process framework Table: Process discriminators that result from difference
A Project framework is not a project-specific process in project size.
implementation with a well-defined recipe for success
Methods, techniques, culture, formality & organization
must be tailored to the specific domain to achieve a
process implementation that can be succeed.
The following discussion about major differences
among project process is organized around six process
parameters. These are some of the critical dimensions
that a software project manager must consider when
tailoring a process framework to create a practical
process implementation.
The six parameters are:
I. Scale
II. Stakeholder cohesion or contention
III. Process flexibility or rigor
IV. Process maturity
V. Architectural risk
VI. Domain experience

3.5.1.1 Scale 3.5.1.2 Stakeholder contention & contention

The single most important factor in tailoring a software The degree of cooperation & coordination among
process framework to the specific needs of a project is stakeholders can significantly drive the specifics of how
total scale of the software application a process is defined
The scale factor can be measured by This process parameter can range from cohesive to
◼ Source lines of code( SLOC ) adversarial
◼ Number of function points Cohesive teams have common goals, complementary
◼ Number of use cases skills & close communications
◼ Number of dollars Adversarial teams have conflicting goals, competing
of incomplete skills & less-than-open communications
21 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

Table: Process discriminators that result from

Table: process discriminators that result from differences in process flexibility
differences in stakeholder cohesion

3.5.1.4 Process maturity

3.5.1.3 Process flexibility or rigor
The process maturity level of the development
The degree of rigor formality & change freedom organization is another key driver of management
inherent in a specific project’s contract will have a complexity.
substantial impact on the implementation of the
project’s process. Managing a mature process (level 3 or higher) is far
simpler than managing an immature process (level1 &
For loose contracts such as building a commercial 2).
product within a business unit of a software company,
management complexity will be minimal Organizations with a mature process typically have a
high level of precedent experience in developing
On the other hand, for a very rigorous contract it could software & high level existing process collateral that
take months to authorize a change in a release schedule enables predictable planning & execution of the process

Table: Process discriminators that result from

differences in process maturity

22 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

Table: Process discriminators that result from

differences in architecture risk

3.5.1.5 Architectural Risk 3.5.1.6 Domain Experience

The degree of technical feasibility demonstrated before The development organization’s domain experience
commitment to full-scale-production is an important governs its ability to converge on an acceptable
dimension of defining a specific project’s process architecture in a minimum number of iterations.

There are many sources of architecture risk such as Generally a skilled software organization building its
first radar application may require 4 or 5 prototype
• System performance releases before converging on an adequate baseline.
• Robustness Table: Process discriminators that result from
differences in domain experience
• System reliability

The degree to which these risks can be eliminated before

construction begins can have dramatic ramifications in
the process tailoring

23 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

3.5.2 Example: Small-Scale project versus Large- Table: Differences in artifacts between small and
scale project large projects

An analysis of the differences between the phases, Artifacts Small Large,

workflows, and artifacts of two projects on opposite Commercial Complex
ends of the management complexity spectrum shows Project Project
how different two software project process be.
Work 1-page Financial
Table illustrates the differences in schedule distribution Breakdown spreadsheet management
for large and small projects across life cycle. Structure with 2 levels of system with 5 or
WBS elements 6 levels WBS
Table: Schedule distribution across phases for small
elements
and large projects
Business case Spreadsheet and 3-volume
short memo proposal
including
technical
volume, cost
volume, and
related
experience

Vision 10-page 200-page

statement concept paper subsystem
One key aspect of the differences between the two specification
projects is the leverage of the various process
components in the success or failure of the project. This Development 10-page plan 200-page
reflects the importance of staffing or the level of plan development
associated risk management. plan

Table: Lists the workflows in order of their Release 3-interim 8 to 10 interim

importance specifications release release
and number of specifications specification
releases

Architecture 5-critical use 25 critical use

description cases, 50 UML cases, 200
UML
diagrams,20 diagrams,100
pages of text, pages of text,
other graphics other graphics

Another key set of differences is the inherent in the Software 50,000 lines of 300,000 lines of
implementation of the various artifacts of the process. Visual Basic C++ code
code

24 | P a g e
 UNIT-3: Techniques of Planning, Controlling and Automating Software Process

Release 10-page release 100-page

description notes summery

Deployment User training Transition Plan

course
Installation
Sales rollout kit Plan

User manual On-line help 200-page user

and 100-page manual
user manual

Status Quarterly Monthly project

assessment project reviews management
reviews

25 | P a g e