SPPM Notes Unit 3 1 Jntuh
SPPM Notes Unit 3 1 Jntuh
UNIT - III
Workflows and Checkpoints of process, Software process workflows, Iteration workflows, Major
milestones, minor milestones, periodic status assessments.
Process Planning
Work breakdown structures, Planning guidelines, cost and schedule estimating process, iteration
planning process, Pragmatic planning.
INTRODUCTION TO WORKFLOW
Workflow is the definition, execution and automation of business processes where tasks,
information or documents are passed from one participant to another for action, according to a
set of procedural rules.
Organizations use workflows to coordinate tasks between people and synchronize data between
systems, with the ultimate goal of improving organizational efficiency, responsiveness and
profitability.
A fully functional digital workflow provides four key benefits to a company:
✓ Improved productivity
✓ Process transparency
✓ Faster business reaction time
✓ Improved accountability
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
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
Iteration Workflows
Department of IT CS734PE: SPPM
• 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.
• 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; updating any requirements set artifacts to reflect changes
necessitated by results of this iteration's engineering activities
• 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; updating design set artifacts to reflect changes
necessitated by the results of this iteration's engineering activities
• Assessment: evaluating the results of the iteration, including compliance with the allocated
evaluation criteria and the quality of the current baselines; identifying any rework required and
determining whether it should be performed before deployment of this release or allocated to
the next release; assessing results to improve the basis of the subsequent iteration's plan
As with any sequence of a software development workflow, many of the activities occur
concurrently. For example, requirements analysis is not done all in one continuous lump; it
intermingles with management, design, implementation, and so forth.
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.
These descriptions are pretty simplistic. In practice, the various sequences and overlaps among
iterations become more complex. The terms iteration and increment deal with some of the
pragmatic considerations. An iteration represents the state of the overall architecture and the
complete deliverable system. An increment represents the current work in progress that will be
combined with the preceding iteration to form the next iteration. Figure, an example of a simple
development life cycle, illustrates the difference between iterations and increments. This
example also illustrates a typical build sequence from the perspective of an abstract layered
architecture.
other major milestones or operate with fewer. For simpler projects, very few or no minor
milestones may be necessary to manage intermediate results, and the number of status
assessments may be infrequent.
Major Milestones:
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 different
concerns:
Users: consistency with requirements and usage scenarios, potential for accommodating
growth, quality attributes.
Architects and systems engineers: product line compatibility, requirements changes, trade-
off analyses, completeness and consistency, balance among risk, quality and usability.
Table 3-1. The general status of plans, requirements and products across the major milestones
Initial Operational Capability Milestone: These milestones occur 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.
• Product Release Milestone: Occur 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 and software quality
metrics are reviewed to determine whether quality is sufficient for transition to the support
organization.
Minor Milestones:
The number of iteration-specific, informal milestones needed depends on the content and length of the
iteration.
Iterations which have one-month to six-month duration have only two milestones are needed:
the
iteration readiness review and iteration assessment review. For longer iterations some other
intermediate review points are added.
All iterations are not created equal. An iteration take different forms and priorities, depending
on where the project is in the life cycle.
Early iterations focus on analysis and design. Later iterations focus on completeness,
Department of IT CS734PE: SPPM
consistency,
usability and change management.
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 to review iteration results, test
results, to determine amount of rework to be done, to review impact of the iteration results on the plan
for subsequent iterations.
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 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
Periodic status assessments are crucial for focusing continuous attention on the evolving health of the
project and its dynamic priorities. They force the software project manager to collect and review the
data periodically, force outside peer review, and encourage dissemination of best practices to and
from other stakeholders.
The default content of periodic status assessments should include the topics identified in
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 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 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. A WBS is the architecture for the financial plan.
Conventional work breakdown structures are prematurely decomposed, planned, and budgeted in
either too little or too much detail. Large software projects tend to be over planned and small
Department of IT CS734PE: SPPM
projects tend to be under planned. The basic problem with planning too much detail at the outset is
that the detail does not evolve with the level of fidelity in the plan.
Conventional work breakdown structures are project-specific, and cross-project comparisons are
usually difficult or impossible. With no standard WBS structure, it is extremely difficult to
compare plans, financial data, schedule data, organizational efficiencies, cost trends, productivity
trends, or quality trends across multiple projects.
Management
System requirement and design
Subsystem 1
Component 11
Requirements
Design Code Test
Documentation
Subsystem M Component M1
Requirements
Design Code Test
Documentation
…(similar structures for other components)
Component MN
Requirements
Design Code Test
Documentation
Integration and test
Test planning
Test procedure preparation
Testing
Test reports
Other support areas
Configuration control
Quality assurance
System administration
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. This recommended structure provides one example of how the elements of the process
framework can be integrated into a plan. It provides a framework for estimating the costs and
schedules of each element, allocating them across a project organization, and tracking expenditures.
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 emphases in the requirements, design, and implementation workflows.
Business context. Projects developing commercial products for delivery to a broad customer base may
require much more elaborate substructures for the deployment element.
Precedent experience. Very few projects start with a clean slate. Most of them are developed as new
generations of a legacy system (with a mature WBS) or in the context of existing organizational
standards (with preordained WBS expectations).
The WBS decomposes the character of the project and maps it to the life cycle, the budget, and the
personnel. Reviewing a WBS provides insight into the important attributes, priorities, and structure of
the project plan.
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. Figure 10-3 illustrates this idea. One
of the primary reasons for organizing the default WBS the way I have is to allow for planning
elements that range from planning packages (rough budgets that are maintained as an estimate for
future elaboration rather than being decomposed into detail) through fully planned activity networks
(with a well-defined budget and continuous assessment of actual versus planned expenditures).
Figure 3-8: Evolution of planning fidelity in the WBS over the life cycle
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 circumstances. Two simple planning guidelines should
be considered when a project plan is being initiated or assessed. The first guideline, detailed in
Table, prescribes a default allocation of costs among the first-level WBS elements. The second
guideline, detailed in Table, prescribes the allocation of effort and schedule across the lifecycle
phases.
Implementation 25%
Assessment 25%
Deployment 5%
Total 100%
The second perspective is a backward-looking, bottom-up approach. We start with the end in mind,
analyze the micro-level budgets and schedules, and then sum all these elements into the higher level
budgets and intermediate milestones. 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.
Milestone scheduling or budget allocation through top-down estimating tends to exaggerate the
project management biases and usually results in an overly optimistic plan. Bottom-up estimates
usually exaggerate the performer biases and result in an overly pessimistic plan.
These two planning approaches should be used together, in balance, throughout the life cycle of the
project. During the engineering stage, the top-down perspective will dominate because there is
usually not enough depth of understanding nor stability in the detailed task sequences to perform
credible bottom-up planning.
During the production stage, there should be enough precedent experience and planning
Department of IT CS734PE: SPPM
fidelity that the bottom-up planning perspective will dominate. Top-down approach should be
well tuned to the project-specific parameters, so it should be used more as a global
assessment technique. Figure illustrates this life-cycle planning balance.
Pragmatic Planning
Even though good planning is more dynamic in an iterative process, doing it accurately is far easier.
While executing iteration N of any phase, the software project manager must be monitoring and
controlling against a plan that was initiated in iteration N - 1 and must be planning iteration N + 1.
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. Aside from
bad architectures and misunderstood requirements, inadequate planning (and subsequent bad
management) is one of the most common reasons for project failures. Conversely, 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. Plans are not just for managers. The
more open and visible the planning process and results, the more ownership there is among the team
Department of IT CS734PE: SPPM
members who need to execute it. Bad, closely held plans cause attrition. Good, open plans can shape
cultures and encourage teamwork.