This topic provides a high-level overview of the ECP benefits,
features, and typical usage.
Within the ECP process are:
- Five phases: submission, analysis, resolution, evaluation, and
conclusion
- Extensible stages, both depth and breadth
- Optional interlocked requirements change management
- Change request resolution management
For an in-depth discussion about ECP, see the IBM® Rational® Enterprise Change
Process white paper, located at ftp://public.dhe.ibm.com/common/ssi/ecm/en/rad14094usen/RAD14094USEN.PDF.
Benefits and features
The following are
the benefits and features of ECP:
- Provides sign-off authority in critical phases.
- Helps with assessing and avoiding risks.
- Groups attributes on forms into collapsible sections for the phase
to which they apply.
- Automatically expands and collapses the phase sections, based
on the state of the CR. This feature provides fast access to the most
relevant details.
- Designed to scale to support change management needs for large
or small enterprises, for straight forward or complex change requests.
- Developed with industry best practices in mind. The process is
ready for immediate use for many enterprise teams.
- Allows you to view and create IBM Rational Synergy tasks.
- Ready for immediate use with the CCMI_MatrixReports package
to provide reports that support high maturity Capability Maturity
Model Integration (CMMI) and Six Sigma
- Phase Containment Effectiveness
- Phase Screening Effectiveness
- Weighted Matrix
- Configured to send email notifications at several points in the
lifecycle. These notifications include details that are relevant to
the current state of the CR.
- Encourages users to maintain actual and estimated effort per CR
as it transitions through the lifecycle.
- Supports parent-child relationships. The child CRs:
- Partition work among different owners or provide fine grained
tracking of particular CR phases.
- Support the same lifecycle as their parent CRs and can have children
themselves.
- Optionally supports requirements-driven development through creation
of change requests directly from requirements and requirements-related
documentation, using Rational DOORS®.
- Incorporates the IBM Rational DOORS lifecycle for optional, easy integration
with the IBM Rational Change for DOORS Interface.
- Provides additional privileges so that you have more control over
the CRs. For example:
- Users with the CRmgr privilege are super
users who can change almost any attribute and reassign CRs as needed.
- Users with the CRowner privilege have similar
abilities, but only for the CRs they own.
Typical usage
This usage scenario involves
several users. Based on their assigned privileges, users can perform
particular actions for CRs in given states.
In this example,
the Development team lead has the assigner privilege.
The review board members have CRmgr privileges,
so that they can update the CR at any point in the lifecycle.
- A quality engineer discovers a defect and submits a CR. The CR
begins its lifecycle in the submitted phase.
- A review board receives email notification and reviews the submitted
CR. The review board determines that the defect must be fixed and
transitions the CR into the analysis phase. The
CR is assigned to the Development team lead for review and analysis.
- The Development team lead receives email notification, reviews
the CR, and assesses the risk involved in fixing the defect.
- The Development team lead determines that the defect must be fixed,
documents the findings, and transitions the CR into the analyzed state.
- A manager reviews the CR to determine whether the risk and estimated
effort of fixing the defect fits into the current schedule. One option
is to postpone the fix for later release. However, in this case, the
risk, and estimated effort are acceptable, so the CR is transitioned
into the resolution phase. The Development team
lead is assigned as the CR resolver.
- Then, the developer assigned to the CR receives email notification.
In Rational Synergy, the
developer creates a task to fix the defect and associates the task
to the CR.
- The developer completes the work necessary to fix the defect,
and completes the task in Rational Synergy.
Then, in Rational Change,
the developer documents how the defect was fixed, transitions the
CR into the resolved state, and updates the actual
effort required.
- The development team lead reviews the CR, approves the work, and
transitions the CR into the evaluation phase for
testing.
- A quality engineer verifies the fix, documents how the tests were
performed, and marks the CR as evaluated.
- The team lead reviews the comments, determines that the testing
is sufficient, and transitions the CR into the concluded phase.