100% found this document useful (1 vote)
3K views26 pages

Milestones in Software Project Management

The document describes three types of project checkpoints used throughout a project lifecycle: major milestones, minor milestones, and status assessments. Major milestones occur at the end of phases and involve formal evaluations, while minor milestones occur within iterations and use informal evaluations. Status assessments provide regular updates on project progress. Key milestones include the Lifecycle Objectives Milestone after inception and the Lifecycle Architecture Milestone after elaboration.

Uploaded by

bhuvaneshwari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
3K views26 pages

Milestones in Software Project Management

The document describes three types of project checkpoints used throughout a project lifecycle: major milestones, minor milestones, and status assessments. Major milestones occur at the end of phases and involve formal evaluations, while minor milestones occur within iterations and use informal evaluations. Status assessments provide regular updates on project progress. Key milestones include the Lifecycle Objectives Milestone after inception and the Lifecycle Architecture Milestone after elaboration.

Uploaded by

bhuvaneshwari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 26

CHECKPOINTS OF THE PROCESS

Three sequences of project checkpoints are used to synchronize


stakeholder expectations throughout the lifecycle:
1)Major milestones,
2)Minor milestones, and
3)Status assessments.
 The most important major milestone is usually
the event that transitions the project from the
elaboration phase into the construction phase.
 The format and content of minor milestones are
highly dependent on the project and the
organizational culture.
 Periodic status assessments are crucial for
focusing continuous attention on the evolving
health of the project and its dynamic priorities.
The purpose of these milestones 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 lifecycle,
not just the current situation of an individual perspective or
intermediate product.
Milestones must have well-defined expectations and provide
tangible results.
Three types of joint management reviews are conducted
throughout the process:
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.
Minor Milestones: these iteration-focused
events are conducted to review the content of
an iteration in detail and to authorize
continued work.

Status Assessments: these periodic events


provide management with frequent and
regular insight into the progress being made.
 Each of the four phases consists of one or more
iterations and concludes with a major milestone when
planned technical capability is produced in
demonstrable form.
 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.
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 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.
Architects and system engineers: product line
compatibility, requirements changes, trade-off analyses,
completeness and consistency, balance among risk,
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, and sales and marketing teams.
The essence of each major milestone is to ensure that the
requirements understanding, the life-cycle plans, and the
product’s form, function, and quality are evolving in balanced
levels of detail, and to ensure consistency among the various
artifacts.
The general status of plans, requirements, and products across
the major milestones
Milestones Plans Understanding of Understanding
problem space of solution
(Req.) space (product.)
Life-cycle Definition of stake holder Baseline vision, Demonstration of at
objectives responsibilities, low- including growth least one feasible
fidelity life-cycle plan, vectors, quality architecture.
high-fidelity elaboration attributes, and priorities, Make/buy/ reuse trade-
phase plan use case model offs, initial design
model.
Milestones Plans Understanding of Understanding of
problem space solution space
(Req.) (product.)
Life-cycle High-fidelity Stable vision and use Stable design set,
architecture construction phase case model, evaluation make/buy/reuse
plan (bill of materials, criteria for construction decisions, critical
releases, initial component prototypes
labor allocation), low-
operational capability,
fidelity transition draft user manual.
phase plan
Initial operational High-fidelity transition Acceptance criteria for Stable
capability phase plan product release, releasable implementation set,
user manual critical features and
core capabilities,
objective insight into
product qualities

Product release Next-generation product Final user manual


Stable deployment
plan
set, full features,
complaint quality
Lifecycle Objectives Milestone

At the end of the inception phase is the first major


project milestone or Lifecycle Objectives Milestone.
At this point, you examine the lifecycle objectives
of the project, and decide either to proceed with
the project or to cancel it.
Evaluation Criteria

 Stakeholder concurrence on scope definition and


cost/schedule estimates
 Agreement that the right set of requirements have
been captured and that there is a shared
understanding of these requirements.
 Agreement that the cost/schedule estimates,
priorities, risks, and development process are
appropriate.
 All risks have been identified and a mitigation
strategy exists for each.
Lifecycle Architecture Milestone

Milestone: Lifecycle Architecture


At the end of the elaboration phase is the second
important project milestone, the Lifecycle
Architecture Milestone.
At this point, you examine the detailed system
objectives and scope, the choice of architecture,
and the resolution of the major risks.
Evaluation Criteria

 The product Vision and requirements are stable.


 The architecture is stable.
 The key approaches to be used in test and evaluation
are proven.
 Test and evaluation of executable prototypes have
demonstrated that the major risk elements have been
addressed and have been credibly resolved.
 The iteration plans for the construction phase are of
sufficient detail and fidelity to allow the work to
proceed.
 The iteration plans for the construction phase are
supported by credible estimates.
 All stakeholders agree that the current vision can
be met if the current plan is executed to develop
the complete system, in the context of the current
architecture.
 Actual resource expenditure versus planned
expenditure is acceptable.
Artifacts

• Prototypes.
• Risk List
• Development Process
• Development Infrastructure
• Software Architecture Document
Initial Operational Capability Milestone

At the Initial Operational Capability Milestone, the


product is ready to be handed over to the
Transition Team. All functionality has been
developed and all alpha testing (if any) has been
completed. In addition to the software, a user
manual has been developed, and there is a
description of the current release.
Evaluation Criteria

The evaluation criteria for the construction phase


involve the answers to these questions:
 Is this product release stable and mature enough to
be deployed in the user community?
 Are all the stakeholders ready for the transition into
the user community?
 Are actual resource expenditures versus planned
still acceptable?
Artifacts

 "The System" The executable system itself, ready to


begin "beta" testing.
 Deployment Plan.
 Implementation Model (and all constituent artifacts,
including Components)
 Test Model
 Training Materials
MINOR MILESTONES (2 per iteration)
The number of iteration-specific, informal milestones
needed depends on the content and length of the iteration.
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, 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
Objective: To ensure that the expectations of all
stakeholders are synchronized and consistent.
Status assessments provide the following:
I.A mechanism for openly addressing, communicating, and
resolving management issues, technical issues, and project
risks.
II.Objective data derived directly from on-going activities
and evolving product configurations.
III.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
encouragement dissemination of best practices to and from
other stakeholders.
By standardizing the format and the metrics that are
reviewed, an organization can also enable project-to-
project comparisons and dissemination of best practices far
more efficiently.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy