Software Project

Management
Course Contents:
Unit 03: Techniques of Planning, Controlling and
Automating Software Process

3.1 Iterative Process Planning (Process Work

Breakdown Structure, Planning Guidelines, Cost
and Schedule Estimation Process, Iteration
Planning Process)
3.2 Project Organization and Responsibilities
3.3 Process Automation – Tools and Environment
3.4 Project Control and Process Automation
3.5 Process Customization
• Iterative Process Planning
➢ Work Breakdown Structures

➢ Planning Guidelines

➢ The Cost and Schedule Estimating Process

➢ The Iteration Planning Process

➢ Pragmatic Planning

• Project Organizations and Responsibilities

➢ Line-of-Business organizations

➢ Project Organizations

➢ Evolution Organizations

• Process Automation
➢ Tools: Automation Building Blocks

➢ The Project Environment

• Project Control and Process Instrumentation
➢ The Seven Core Metrics

➢ Management Indicators

➢ Quality Indicators

➢ Life-Cycle Expectations

➢ Pragmatic Software Metrics

➢ Metrics Automation

• Process Atomization
➢ Process Discriminants

➢ Example: Small-Scale Project Versus Large-

scale Project
• Iterative Process Planning
➢ Work Breakdown Structures

➢ Planning Guidelines

➢ The Cost and Schedule Estimating

Process
➢ The Iteration Planning Process

➢ Pragmatic Planning
work breakdown structure (WBS)
❑A work breakdown structure (WBS) is a key
project deliverable that organizes the team's
work into manageable sections.

❑The work breakdown structure visually defines

the scope into manageable chunks that a
project team can understand, as each level
of the work breakdown structure provides
further definition and detail.
❑The development of a work breakdown
structure is dependent on the project
management style, organizational culture,
customer preference, financial constraints
and several other hard-to-define
parameters.

❑A WBS is simply a hierarchy of elements

that decomposes the project plan into the
discrete work tasks.
❑A WBS provides the following information

➢ A delineation of all significant work

➢ A clear task decomposition for assignment

of responsibilities

➢ A framework for scheduling, budgeting,

and expenditure
tracking.
What is process breakdown structure?

• Product Breakdown Structure (BBS) is a

project management tool and important part
of the project planning.

• The product breakdown structure defines

subtasks or work packages and describes the
relationship between work packages.

• This process helps to organize the projects gut

and to define the project frameworks.
Why use a WBS in project management?
• Estimate the cost of a project.
• Establish dependencies.
• Determine a project timeline and develop a
schedule.
• Write a statement of work (or SOW, one of
your other acronyms).
• Assign responsibilities and clarify roles.
• Track the progress of a project.
• Identify risk.
How to Create a WBS: The High-Level View
• Determine and describe the project
statement.

• Highlight all the necessary phases of the

project.

• Create and list the deliverables (as well as

how success will be measured)

• Divide the deliverables into manageable

tasks.
Planning Guidelines
❑ Two simple planning guidelines should be
considered when a project plan is being
initiated or assessed.
DOM INCEP ELABORA CONSTRU TRANSI
AIN TION TION CTION TION
FIRST-LEVEL DEFAULT
WBS ELEMENT BUDGET Effort 5% 20% 65% 10%
Management 10%
Sche 10% 30% 50% 10%
Environment 10% dule
Requirements 10%
Design 15%
The second guideline prescribes
Implementation 25% the allocation of effort and
Assessment 25%
schedule across the life-cycle
Deployment 5%
Total 100% phases
The first guideline prescribes a default
allocation of costs among the first-level
WBS elements
• So, WBS will be help to our project's efficiency
and effectiveness, how do we go about it?
First, let's look at what all we need to get
started.
• There are several inputs you will need to get
you off on the right foot:
o The Project Scope Statement
o The Project Scope Management Plan
o Organizational Process Assets
o Approved Change Requests - (PMBOK Guide)
PMBOK stands for Project Management Body of Knowledge and it is
the entire collection of processes, best practices, terminologies, and
guidelines that are accepted as standards within the project management
industry.
• These above four inputs should give you all the
information you and your team needs to create
your WBS. Along with these inputs, you will use
certain tools as well:
o Work Breakdown Structure Templates
o Decomposition - (PMBOK Guide)
• Finally, using these inputs and tools you will create
the following outputs:
• Work Breakdown Structure
• WBS Dictionary
• Scope Baseline
• Project Scope Statement (updates)
• Project Scope Management Plan (updates)
• Requested Changes - (PMBOK Guide)
The Cost and Schedule Estimating Process
❑ Project plans need to be derived from two
perspectives.

➢ Forward-looking:
1.The software project manager develops a
characterization of the overall size,
process, environment, people, and quality
required for the project.

2.A macro-level estimate of the total effort

and schedule is developed using a software
cost estimation model.
3. The software project manager partitions
the estimate for the effort into a top-level
WBS, also partitions the schedule into
major milestone dates and partitions the
effort into a staffing profile

4. At this point, subproject managers are

given the responsibility for decomposing
each of the WBS elements into lower levels
using their top-level allocation, staffing
profile, and major milestone dates as
constraints.
➢ 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.

2.Estimates are combined and integrated into

higher level budgets and milestones.

3.Comparisons are made with the top-down

budgets and schedule milestones. Gross
differences are assessed and adjustments
are made in order to converge on agreement
between the top-down and the bottom-up
estimates.
 Iterative Process Planning (The Iteration
Planning Process)
Engineering Stage Production Stage
Inception Elaboration Construction Transition

Feasibility iterations Architecture iterations Usable iterations Product releases

Engineering stage planning emphasis:

➢ Macro-level task estimation for production-stage
artifacts
➢ Micro-level task estimation for engineering
artifacts
➢ Stakeholder concurrence
➢ Analysis of actual vs. planned expenditures
➢ Tuning the top-downconcurrence
➢ project-independent planning guidelines into
project-specific planning guidelines.
 Production stage Planning emphasis:
➢ Micro-level task estimation for production-
stage artifacts
➢ Macro-level task estimation for engineering
artifacts
➢ Stakeholder concurrence
➢ Fine-grained variance analysis of actual vs.
planned expenditures
Project Organizations and Responsibilities
[Line-of-Business Organizations]
Default roles in a software line-of-business organizations

Organization
Manager

Software Engineering Project Review

Process Authority Authority

• Process definition • Project compliance

• Process improvement • Periodic risk assessment

Software Engineering
Infrastructure
Environment Authority

• Process automation • Project administration

• Engineering skill centers
• Professional development

Project A Project B Project N

Manager Manager Manager
 Project Organizations and Responsibilities
Project Organizations
Software Management Team
❖ Systems Engineering
❖ Financial Administration
❖ Quality Assurance

Artifacts Responsibilities
➢ Business case ➢ Resource commitments
➢ Vision ➢ Personnel assignments
➢ Software development plan ➢ Plans, priorities,
➢ Work breakdown structure ➢ Stakeholder satisfaction
➢ Status assessments ➢ Scope definition
➢ Requirements set ➢ Risk management
➢ Project control

Life-Cycle Focus
Inception Elaboration Construction Transition
Elaboration phase planning Construction phase planning Transition phase planning Customer satisfaction
Team formulating Full staff recruitment Construction plan Contract closure
Contract base lining Risk resolution optimization Sales support
Architecture costs Product acceptance criteria Risk management Next-generation planning
Construction costs
Software Architecture Team:
• "A software architect is a software expert
who makes high-level design choices and
dictates technical standards, including
software coding standards, tools, and
platforms.”
• The most common understanding is that an
architect is a person who takes action and
dictates decisions.
• Designing, planning and developing are
integral tasks in an architect's daily routine
 Software Architecture Team
❖ Demonstrations
❖ Use-case modelers
❖ Design modelers
❖ Performance analysts

Artifacts Responsibilities
➢ Architecture description ➢ Requirements trade-offs
➢ Requirements set ➢ Design trade-offs
➢ Design set ➢ Component selection
➢ Release specifications ➢ Initial integration
➢ Technical risk solution

Life-Cycle Focus
Inception Elaboration Construction Transition

• Architecture • Architecture base • Architecture • Architecture

prototyping lining maintenance maintenance
• Make/buy trade-offs • Primary scenario • Multiple-component • Multiple-component
• Primary scenario demonstration issue resolution issue resolution
definition • Make/buy trade-offs • Performance tuning • Performance tuning
base lining • Quality improvements • Quality improvements
• Architecture
evaluation criteria
definition
Component Team:
• A team that focuses on the creation of one
or more components of a larger product
that a customer would purchase.
• Team that is cross-functional (multi-
disciplinary), single component focused.
Contrast with feature team.
• Component teams : to build, deploy, and
ultimately release.
• CT is capable of delivering end-to-end user
value
• Each team has all the skills necessary to
deliver a feature.
 Software Development Team

❖ Component teams

Artifacts Responsibilities
➢ Design set ➢ Component design
➢ Implementation set ➢ Component implementation
➢ Deployment set ➢ Component stand-alone test
➢ Component maintenance
➢ Component documentation

Life-Cycle Focus
Inception Elaboration Construction Transition

• Prototyping • Critical component • Component design • Component

support design • Component maintenance
• Make/buy trade- • Critical component implementation • Component
offs implementation Component stand- documentation
and test alone test
• Critical component • Component
base line maintenance
Software Assessment Team:
• Software process assessments are
performed in an open and collaborative
environment.
• They are for the use of the organization
to improve its software processes, and
the results are confidential to the
organization.
• The organization being assessed must
have members on the assessment team.
 Software Assessment Team
❖ Release testing
❖ Change management
❖ Deployment
❖ Environment support
Artifacts Responsibilities
➢ Deployment set ➢ Project infrastructure
➢ SCO database ➢ Independent testing
➢ User manual ➢ Requirements
➢ Environment verification
➢ Release specifications ➢ Metrics analysis
➢ Release descriptions ➢ Configuration control
➢ Deployment documents ➢ Change management
➢ User deployment

Life-Cycle Focus
Inception Elaboration Construction Transition

• Infrastructure • Infrastructure base • Infrastructure • Infrastructure

planning lining upgrades maintenance
• Primary scenario • Architecture release • Release testing • Release base lining
prototyping testing Change • Change management • Change
management • User manual base line management
• Initial user manual • Requirements • Deployment to users
verification • Requirements
verification
 Process Automation
[ Computer-aided software engineering]
• Computer-aided software engineering (CASE) is
software to support software development and
evolution processes.
• Activity automation
o Graphical editors for system model
development; Data dictionary to manage
design entities;
o Graphical UI builder for user interface
construction;
o Debuggers to support program fault finding;
o Automated translators to generate new
versions of a program.
 Computer-aided software engineering (CASE)
Technology

• Case technology has led to significant

improvements in the software process.
However, these are not the order of magnitude
improvements that were once predicted
o Software engineering requires creative
thought - this is not readily automated;
o Software engineering is a team activity and,
for large projects, much time is spent in team
interactions. CASE technology does not
really support these.
CASE Classification
• Classification helps us understand the different
types of CASE tools and their support for
process activities.
• Functional perspective
o Tools are classified according to their
specific function.
• Process perspective
o Tools are classified according to process
activities that are supported.
• Integration perspective
o Tools are classified according to their
organisation into integrated units.
CASE Integration
• Tools
o Support individual process tasks such as
design consistency checking, text editing,
etc.
• Workbenches
o Support a process phase such as
specification or design, Normally include a
number of integrated tools.
• Environments
o Support all or a substantial part of an entire
software process. Normally include several
integrated workbenches.
Tools, Workbenches, Environments
CASE
technolo g y

Tools Wor kbenches Environments

File Integ rated Process-centr ed

Editors Compilers
compar ators en vironments en vironments

Anal ysis and

Pro gramming Testing
design

Multi-method Single-method Gener al-purpose Langua ge-specific

workbenches workbenches workbenches workbenches
 Project Control and Process Instrumentation
The Core Metrics
METRIC PURPOSE PERSPECTIVES

Work and progress Iteration planning, plan vs. Source Lines Of Code, function
actuals, management indicator points, object points, scenarios,
test cases, Supply Chain
Operating System
Budget cost and expenditures Financial insight, plan vs. Cost per month, full-time staff
actuals, management indicator per month, percentage of
budget expended
Staffing and team dynamics Resource plan vs. actuals, People per month added,
hiring rate, attrition rate people per month leaving

Change traffic and stability Iteration planning, Software changes

management indicator of
schedule convergence
Breakage and modularity Convergence, software scrap, Reworked SLOC per change, by
quality indicator type, by release/
component/subsystem
Rework and adoptability Convergence, software rework, Average hours per change, by
quality indicator type, by release/
component/subsystem
Process Customization
❑ It is important to have visible milestones in
the life cycle , where various stakeholders
meet to discuss progress and planes.
❑ The purpose of this events is to:
➢ Synchronize stakeholder expectations and
achieve concurrence on the requirements,
the design, and the plan.
➢ Synchronize related artifacts into a
consistent and balanced state
➢ Identify the important risks, issues, and
out-of-rolerance conditions
➢ Perform a global assessment for the
whole life-cycle.
Thank you