Software Project Management

(SPM)
Unit-III Syllabus
 Workflows of the process: Software process workflows, Iteration workflows.
 Check points of the process: Major milestones, Minor Milestones, Periodic
status assessments.
 Iterative Process Planning: Work break down structures, planning
guidelines, cost and schedule estimating, Iteration planning process,
Pragmatic planning.
Workflows of the process
Software Process Workflows
 The term Workflows is used to mean a thread of cohesive
and mostly sequential activities. Workflows are mapped to
product artifacts. There are seven top-level workflows:
1. Management workflow: controlling the process and ensuring win conditions
for all stakeholders
2. Environment workflow: automating the process and evolving the
maintenance environment
3. Requirements workflow: analyzing the problem space and evolving the
requirements artifacts
4. Design workflow: modeling the solution and evolving the architecture and
design artifacts
5. Implementation workflow: programming the components and evolving the
implementation and deployment artifacts
6. Assessment workflow: assessing the trends in process and product quality
7. Deployment workflow: transitioning the end products to the user
Figure 8-1 illustrates the relative levels of effort expected
across the phases in each of the top-level workflows.
Table 8-1 shows the allocation of artifacts and the emphasis of each workflow in
each of the life-cycle phases of inception, elaboration, construction, and transition.
 Iteration Workflows
 Iteration consists of a loosely sequential set of activities in
various proportions, depending on where the iteration is
located in the development cycle.
 Each iteration is defined in terms of a set of allocated usage
scenarios. An individual iteration's workflow, illustrated in
Figure 8-2, generally includes the following sequence:
• Management: iteration planning to determine the content
of the release and develop the detailed plan for the
iteration; assignment of work packages, or tasks, to the
development team
• Environment: evolving the software change order database
to reflect all new baselines and changes to existing
baselines for all product, test, and environment components
Iteration Workflows
• Requirements: analyzing the baseline plan, the baseline
architecture, and the baseline requirements set artifacts
to fully elaborate the use cases to be demonstrated at the
end of this iteration and their evaluation criteria.
• Design: evolving the baseline architecture and the
baseline design set artifacts to elaborate fully the design
model and test model components necessary to
demonstrate against the evaluation criteria allocated to
this iteration.
• Implementation: developing or acquiring any new
components, and enhancing or modifying any existing
components, to demonstrate the evaluation criteria
allocated to this iteration.
Iteration Workflows
 Assessment: evaluating the results of the iteration,
including compliance with the allocated evaluation
criteria and the quality of the current baselines.
assessing results to improve the basis of the subsequent
iteration's plan.
 Deployment: transitioning the release either to an
external organization (such as a user, independent
verification and validation contractor, or regulatory
agency) or to internal closure by conducting a post-
mortem so that lessons learned can be captured and
reflected in the next iteration.
Iteration Workflows
 Iterations in the inception and elaboration phases focus
on management, requirements, and design activities.
Iterations in the construction phase focus on design,
implementation, and assessment. Iterations in the
transition phase focus on assessment and deployment.
 Figure 8-3 shows the emphasis on different activities
across the life cycle. An iteration represents the state of
the overall architecture and the complete deliverable
system.
 An increment represents the current progress that will
be combined with the preceding iteration to from the
next iteration.
Checkpoints of the process
Checkpoints of the process
 It is always important to have visible milestones in the life
cycle where various stakeholders meet, face to face, to
discuss progress and plans.
 The purpose of these events is not only to demonstrate how
well a project is performing but also to achieve the
following:
 Synchronize stakeholder expectations and achieve concurrence on
three evolving perspectives: the requirements, the design, and the
plan
 Synchronize related artifacts into a consistent and balanced state
 Identify the important risks,issues, and out-of-tolerance conditions
 Perform a global assessment for the whole life cycle, not just the
current situation of an individual perspective.
Checkpoints of the process
 Three types of joint management reviews are conducted
throughout the process:
1. Major milestones. These system wide events are held
at the end of each development phase. They provide
visibility to system wide issues, synchronize the
management and engineering perspectives, and verify
that the aims of the phase have been achieved.
2. Minor milestones. These iteration-focused events are
conducted to review the content of an iteration in detail
and to authorize continued work.
3. Status assessments. These periodic events provide
management with frequent and regular insight into the
progress being made.
Checkpoints of the process
 Each of the four phases-inception, elaboration,
construction, and transition consists of one or more
iterations and concludes with a major milestone when a
planned technical capability is produced in demonstrable
form.
 An iteration represents a cycle of activities for which
there is a well-defined intermediate result-a minor
milestone-captured with two artifacts: a release
specification (the evaluation criteria and plan) and a
release description (the results).
 Major milestones at the end of each phase use formal,
stakeholder-approved evaluation criteria and release
descriptions; minor milestones use informal,
development-team-controlled versions of these artifacts.
Figure 9-1 illustrates a typical sequence of project
checkpoints for a relatively large project.
Major Milestones
 The four major milestones occur at the transition points between life-
cycle phases. They can be used in many different process models,
including the conventional waterfall model.
 In an iterative model, the major milestones are used to achieve
concurrence among all stakeholders on the current state of the
project.
 Different stakeholders have very different concerns:
• Customers: schedule and budget estimates, feasibility, risk
assessment, requirements understanding, progress, product line
compatibility
• Users: consistency with requirements and usage scenarios, potential
for accommodating growth, quality attributes
Major Milestones
• Architects and systems engineers: product line compatibility,
requirements changes, trade-off analyses, completeness and
consistency, balance among risk, quality, and usability
• Developers: sufficiency of requirements detail and usage scenario
descriptions, frameworks for component selection or development,
resolution of development risk, product line compatibility, sufficiency of
the development environment
• Maintainers: sufficiency of product and documentation artifacts,
understandability, interoperability with existing systems, sufficiency of
maintenance environment
• Others: possibly many other perspectives by stakeholders such as
regulatory agencies, independent verification and validation
contractors, venture capital investors, subcontractors, associate
contractors, and sales and marketing teams
Table 9-1 summarizes the balance of information across the major
milestones.
Major Milestones
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.
Major Milestones
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.
The technical data listed in Figure 9-2 should have
been reviewed by the time of the lifecycle
architecture milestone.
Figure 9-3 provides default agendas for this milestone.
Major Milestones
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.
Major Milestones
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.
Figure 9-4 identifies the various minor milestones to be
considered when a project is being planned.
Periodic Status Assessments
 Periodic status assessments are management reviews
conducted at regular intervals (monthly, quarterly) to
address progress and quality indicators, ensure
continuous attention to project dynamics, and maintain
open communications among all stakeholders.
 Periodic 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
The default content of periodic status assessments should
include the topics identified in Table 9-2.
Iterative process planning
Work Breakdown Structures
 A good work breakdown structure and its
synchronization with the process framework are critical
factors in software project success.
 Development of a work breakdown structure dependent
on the project management style, organizational culture,
customer preference, financial constraints, and several
other hard-to-define, project-specific parameters.
 A WBS is simply a hierarchy of elements that
decomposes the project plan into the discrete work
tasks.
Work Breakdown Structures
 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: product subsystems, components,
functions, organizational units, life-cycle phases, even
geographies. Most systems have a first-level
decomposition by subsystem. Subsystems are then
decomposed into their components, one of which is
typically the software.
Conventional WBS Issues
 Conventional work breakdown structures frequently
suffer from three fundamental flaws.
1. They are prematurely structured around the product
design.
2. They are prematurely decomposed, planned, and
budgeted in either too much or too little detail.
3. They are project-specific, and cross-project comparisons
are usually difficult or impossible.
 Conventional work breakdown structures are
prematurely structured around the product design.
Figure 10-1 shows a typical conventional WBS that has been
structured primarily around the subsystems of its product
architecture, then further decomposed into the components of
each subsystem.
Evolutionary Work Breakdown
Structures
 An evolutionary WBS should organize the planning
elements around the process framework rather than the
product framework.
 The basic recommendation for the WBS is to organize
the hierarchy as follows:
• First-level WBS elements are the workflows (management,
environment, requirements, design, implementation,
assessment, and deployment).
• Second-level elements are defined for each phase of the 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 10-2.
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.
 There is the risk that the guidelines may pe adopted blindly
without being adapted to specific project circumstances.
Two simple planning guidelines should be considered when
a project plan is being initiated or assessed.
 The first guideline, detailed in Table 10-1, prescribes a
default allocation of costs among the first-level WBS
elements.
 The second guideline, detailed in Table 10-2, prescribes the
allocation of effort and schedule across the lifecycle phases.
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 understanding of the general
requirements and constraints, derives a macro-level
budget and schedule, then decomposes these elements
into lower level budgets and intermediate milestones.
 From this perspective, the following planning sequence
would occur:
1. The software project manager (and others) 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.
The Cost And Schedule
Estimating Process
3. The software project manager partitions the estimate for
the effort into a top-level WBS using guidelines such as
those in Table 10-1.
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.
 The second perspective is a backward-looking, bottom-
up approach. We start with the end in mind, analyze the
micro-level budgets and schedules, then sum all these
elements into the higher level budgets and intermediate
milestones.
The Cost And Schedule
Estimating Process
 This approach tends to define and populate the WBS
from the lowest levels upward. From this perspective,
the following planning sequence would occur:
1. The lowest level WBS elements are elaborated into
detailed tasks
2. Estimates are combined and integrated into higher level
budgets and milestones.
3. Comparisons are made with the top-down budgets and
schedule milestones.
 These two planning approaches should be used together,
in balance, throughout the life cycle of the project.
 Figure 10-4 illustrates this life- cycle planning balance.
The Iteration Planning Process
 Iteration is used to mean a complete synchronization
across the project, with a well-orchestrated global
assessment of the entire project baseline.
• Inception iterations. The early prototyping activities
integrate the foundation components of a candidate
architecture and provide an executable framework for
elaborating the critical use cases of the system.
• Elaboration iterations. 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 and (3) injecting a scenario to drive the worst-case
control flow through the system.
The Iteration Planning Process
• 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 general guideline is that most projects will use
between four and nine iterations. 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
 The art of good project· management is to make trade-offs
in the current iteration plan and the next iteration plan
based on objective results in the current iteration and
previous iterations.
 The success of every successful project can be attributed in
part to good planning.
 A project's plan is a definition of how the project
requirements will be transformed into' a product within the
business constraints.
 It must be realistic, it must be current, it must be a team
product, it must be understood by the stakeholders, and it
must be used.
 Good, open plans can shape cultures and encourage
teamwork.