Unit 3 SPPM

Workflow of the process

What is workflow?
 A workflow is a defined sequence of tasks,
actions, or processes through which work passes
from initiation to completion
SOFTWARE PROCESS WORKFLOWS
 Workflows are mapped to product artifacts. There
are seven top-level workflows:
 Management workflow
 Environment workflow
 Requirements workflow
 Design workflow
 Implementation workflow
 Assessment workflow
 Deployment workflow
Workflow activities
Management controlling the process and ensuring win
workflow conditions for all stakeholders

Environment automating the process and evolving the

workflow maintenance environment

Requirements analyzing the problem space and evolving

workflow the requirements artifacts

Design workflow modeling the solution and evolving the

architecture and design artifacts

Implementation programming the components and

workflow evolving the implementation and
deployment artifacts

Assessment workflow assessing the trends in process and

product quality

Deployment workflow transitioning the end products to the user

 Workflow artifacts Life cycle emphasis

Inception: prepare business case &vision

Business case, SDP, Elaboration: plan development
Managemen Construction: monitor and control
Status assessment, development
t workflow
vision, WBS Transport: monitor and control
deployment

Inception: define development

environment & change management
infrastructure
Environment, Elaboration: Install dev environment
Environment
software change &s/w change mang database
workflow Construction: maintain dev environ &
order database
change order database
Transport: transition maintenance
environ & s/w change order database

Inception: define operational concept

Requirement set Elaboration : define architecture
Requiremen objectives
Release specification,
ts workflow Construction: define iteration objectives
vision Transport: refine release objectives
 Workflow artifacts Life cycle emphasis

Inception: Formulate architecture

Design set concept
Design Elaboration: Achieve arch baseline
Architecture Construction: design components
workflow
Description Transport: refine architecture &
components
Inception: support architecture concept
Implementation set Elaboration: product architecture
Implementat baseline
Deployment set Construction: product complete
ion workflow
component
Transport: maintain components
Release
specification Inception: assess
plans,vision,prototypes
Assessment Release Description
Elaboration: Assess architecture
workflow User manual Construction: assess interim releases
Deployment set Transport: assess product releases

Inception: analyze user community

Elaboration: define user manual
Deployment
Deployment set Construction: prepare transition
workflow materials
Transport: transition product to user
 ITERATION WORKFLOWS
 Each iteration is defined in terms of a set of
allocated usage scenarios.
 Management : iteration planning to determine the
content of release and develop the detailed plan for the
iteration
 Environment : evolving software change order database
to reflect all new baselines
 Requirement: analyzing the baseline plan, architecture
and requirement artifacts set
 Design : base lining architecture & design set
 Implementation: acquiring new components, modifying
 Assessment : evaluating the results of iteration
 Deployment : transitioning the release either to an
external organization
 ITERATION WORKFLOWS
Each iteration is defined in terms of a set of allocated usage
scenarios.
 Checkpoints of the Process

Three types of joint management reviews are conducted

throughout the process
 Major milestones – Ensure visibility of system-wide
issues, align management and engineering
perspectives, and confirm the phase objectives are
met.
 Minor milestones – Iteration-specific events
conducted to thoroughly review the iteration's
content and approve further progress.
 Status assessments – periodic events provide
management with frequent and regular insight into
the progress being made.
 MAJOR MILESTONES

 The four major milestones typically

referenced in a lifecycle, such as the
Software Development Life Cycle (SDLC) or
systems engineering processes, are as
follows:
› Lifecycle Objectives (LCO) Milestone
› Lifecycle Architecture (LCA) Milestone
› Initial Operational Capability (IOC)
Milestone
› Product Release (PR) Milestone
 Key
Milestone Occurs at purpose
Deliverables

Lifecycle the end of the project's objectives, Business case, high-

Objectives (LCO) Inception scope, risks, level requirements,
Milestone Phase. & feasibility are well- & an initial risk
defined. assessment.

Confirms that the

System
Lifecycle the end of the system's architecture is
architecture, refined
Architecture Elaboration stable, risks are
requirements, and
(LCA) Milestone Phase. mitigated, and the
updated project
project is ready for full-
plans.
scale development.

Verifies that the system is

the end of the Working system,
Initial Operational sufficiently developed
Construction integration test
Capability (IOC) and tested to be
Phase. results, and
Milestone deployed in a production
deployment plans.
environment.

the end of Ensures the system is

Final system, user
Product Release the fully operational, meets
documentation, and
(PR) Milestone Transition user needs, and is ready
a post-deployment
Phase. for final release or
support plan.
widespread deployment
 Different stakeholders have very different
concerns
stakeholders concerns

Customers Schedule, budget, feasibility, risks, progress,

requirements clarity, product line compatibility.

Product line compatibility, requirement

Architects/Engineers changes, trade-offs, risk-quality balance,
consistency
Requirement detail, frameworks, risk resolution,
Developers: product line compatibility, development
environment adequacy

Documentation quality, understandability,

Maintainers:
interoperability, maintenance environment
readiness.

Regulatory agencies, investors, contractors, and

Others
marketing teams may have additional
perspectives.
 Life-Cycle Objectives Milestone
 The life-cycle objectives milestone occurs at
the end of the inception phase.
 The goal is to present to all stakeholders a
recommendation on how to proceed with
development, including a plan, estimated cost
and schedule, and expected benefits and cost
savings.
 A successfully completed life-cycle objectives
milestone will result in authorization from all
stakeholders to proceed with the elaboration
phase.
 Life-Cycle Architecture Milestone
 The life-cycle architecture milestone occurs at the end
of the elaboration phase.
 The primary goal is to demonstrate an executable
architecture to all stakeholders.
 The baseline architecture consists of both a human-
readable representation (the architecture
document) and a configuration-controlled set of
software components captured in the engineering
artifacts.
 A successfully completed life-cycle architecture
milestone will result in authorization from the
stakeholders to proceed with the construction phase.
 Initial Operational Capability
Milestone
 The initial operational capability milestone occurs
late in the construction phase.
 The goals are to assess the readiness of the
software to begin the transition into
customer/user sites and to authorize the start of
acceptance testing.
 Acceptance testing can be done incrementally
across multiple iterations or can be completed
entirely during the transition phase is not
necessarily the completion of the construction
phase.
 Product Release Milestone
 The product release milestone occurs at
the end of the transition phase.
 The goal is to assess the completion of
the software and its transition to the
support organization, if any.
 The results of acceptance testing are
reviewed, and all open issues are
addressed. Software quality metrics are
reviewed to determine whether quality is
sufficient for transition to the support
organization.
 MINOR MILESTONES

For most iterations, which have a one-month to six-month duration, only

two minor milestones are needed: the iteration readiness review and

the iteration assessment review.

 Iteration Readiness Review. This informal milestone is conducted

at the start of each iteration to review the detailed iteration plan and

the evaluation criteria that have been allocated to this iteration.

 Iteration Assessment Review. This informal milestone is

conducted at the end of each iteration to assess the degree to which

the iteration achieved its objectives and satisfied its evaluation

criteria, to review iteration results, to review qualification test results

(if part of the iteration), to determine the amount of rework to be

done, and to review the impact of the iteration results on the plan for

subsequent iterations.
 PERIODIC STATUS ASSESSMENTS
 Periodic status assessments serve as project snapshots.
While the period may vary, the recurring event forces the
project history to be captured and documented. Status
assessments provide the following:
› A mechanism for openly addressing, communicating,
and resolving management issues, technical
issues, and project risks
› Objective data derived directly from on-going activities
and evolving product configurations
› A mechanism for disseminating process, progress, quality
trends, practices, and experience information to and from
all stakeholders in an open forum
 Software Management Disciplines

Iterative Process Planning

› Work Breakdown Structures
› Planning Guidelines
› The Cost and Schedule Estimating
Process
› The Iteration Planning Process
› Pragmatic Planning
 Work Breakdown Structures
A work breakdown structure (WBS) is a visual tool
that helps project managers break down a
project into smaller, more manageable tasks.
 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.
 CONVENTIONAL WBS ISSUES

Conventional work breakdown structures (WBS) can have three

fundamental flaws:

Premature structure: The WBS is structured around the product

design too early.

Premature decomposition: The WBS is decomposed, planned, and

budgeted in too much or too little detail too early.

Project-specific: The WBS is specific to a project, making it

difficult or impossible to compare projects.
Other problems that can occur when a WBS isn't planned
carefully include:

 Excessive rework
 Delays in completion
 Confusion and uncoordinated efforts
 Unnecessary work
 Schedule and budget overruns
 Repeated project re-plans and extensions
 Unclear work assignments
 Scope creep
 Missed deadlines
 Unusable new products or delivered features
 EVOLUTIONARY BREAKDOWN STRUCTURE
An evolutionary WBS should organize the planning elements
around the process framework rather than the product framework.

First-level WBS elements are the workflows (management,

environment, requirements, design, implementation, assessment, and
deployment).

Second-level elements are defined for each phase of life cycle

(inception, elaboration, construction, and transition).

Third-level elements are defined for the focus of activities that produce
the artifacts of each phase.

A default WBS consistent with the process framework (phases,

workflows, and artifacts) is shown in Figure
 PLANNING GUIDELINES
 Software projects span a broad range of application
domains.

 It is valuable but risky to make specific planning

recommendations independent of project context.

 Project-independent planning advice is also risky.

 There is the risk that the guidelines may be adopted

blindly without being adapted to specific project
circumstance.
Two simple planning guidelines should be considered when a
project plan is being initiated or assessed

The below table prescribes a default allocation of costs among

the first-level WBS elements
The below table prescribes allocation of effort and
schedule across the lifecycle phases

Default Distributions of effort and schedule by

phase

INCEPTIO ELABORATI CONSTRUCTI TRANSITI

DOMAIN
N ON ON ON

Effort 5% 20% 65% 10%

Schedul
10% 30% 50% 10%
e
 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 an under standing of the general requirements
and constraints.

 It derives a macro-level budget and schedule, then decomposes

these elements into lower level budgets and intermediate
milestones.
From this(forward-looking) perspective, the following
planning sequence would occur:

 The software project manager (and others) develops a

characterization of the overall size, process, environment, people,
and quality required for the project.

 A macro-level estimate of the total effort and schedule is

developed using a software cost estimation model.

 The software project manager partitions the estimate for the effort
into top-level WBS using guidelines.
The second perspective is a backward-looking, bottom-up
approach.

This approach tends to define and populate the WBS from the lowest
levels upward. From this perspective, the following planning
sequence would occur:

 The lowest level WBS elements are elaborated into detailed tasks

 Estimates are combined and integrated into higher level budgets

and milestones.

 Comparisons are made with the top-down budgets and schedule

milestones.
 During the engineering stage top down
approach dominates bottom up approach.
During the production stage bottom
approach dominates top down approach.

During the engineering stage top down approach dominates bottom up approach.
During the production stage bottom approach dominates top down approach .
 THE ITERATION PLANNING PROCESS

 Iterative process planning is a cyclical, flexible, and team-based

process for improving a project by repeating cycles of work
 Planning is concerned with defining the actual sequence of
intermediate results.
 Iteration is used to mean a complete synchronization across the
project.

 Inception Iterations
 Elaboration Iteration
 Construction Iterations
 Transition Iterations
Inception Iterations:
The early prototyping activities integrate the foundation
components of candidate architecture and provide an executable
framework for elaborating the critical use cases of the system.

Elaboration Iteration:
These iterations result in architecture, including a complete
framework and infrastructure for execution. Upon completion of the
architecture iteration, a few critical use cases should be
demonstrable

(1) initializing the architecture

(2) injecting a scenario to drive the worst-case data processing flow
through the system
(3) injecting a scenario to drive the worst-case control flow through
the system (for example, orchestrating the fault-tolerance use cases).
Construction Iterations:
Most projects require at least two major construction
iterations: an alpha release and a beta release.

Transition Iterations:
Most projects use a single iteration to transition a
beta release into the final product.
The typical project would have the following six-
iteration profile:

One iteration in inception: an architecture prototype

Two iterations in elaboration: architecture prototype

and architecture baseline

Two iterations in construction: alpha and beta

releases

One iteration in transition: product release

 PRAGMATIC PLANNING
Pragmatic planning in software project management is a
practical and realistic approach that focuses on delivering a
functional product that meets the project's needs.