Good CM Practices:
Once the system/software requirements have been identified and approved with
customer, those requirements should go under CM control in the form of a
requirements document (and a RTM database capture if using a tool such as QSS
Doors). Changes to a requirement after that point in time, must be approved via
a Change Request/Configuration Control Board (or similiar board controlling the
costs/scheduling/change control).
Design and coding are derived from the baselined system software requirements.
The software used to start code and unit testing phase are under version control
within the Configuration Management System (Developmental CM process). A file
upon first use must be created/added to version control system.
After code and unit test, at the start of initial integration testing, all
developmental activities are under developmental CM control (under version
control). Usually there will not be problem reports/discrepancy reports until
the first format test (i.e., 1.0 release). However, PR's are sometimes
generated by a test team starting with Integration testing phase. All changes
as a result of a problem report/change request should be tracked under the CM
tools (version control and problem tracking, change requests). It's easier and
more cost effective to have the files/version changes tracked against some sort
of requirement item if not a problem report/change request early on, rather than
engineers trying to remember what change(s) were done and what version was used
to address the item later.
Remember that Version Control Systems (VCS) are not a comprehensive CM system,
and have no real "change management" unless there is change request/problem
tracking done, or embedded in the comment field(s) or in a revision history
section of the code header. These are great for helping with build management.
Recommend identifying the system software requirements into change requests
within CM problem tracking tool (i.e., Clearquest) as soon as the baseline is
allocated (start of design). Any and all changes (documentation, software)
placed under version control should be tracked to the specific Change Request so
that CM & Quality know when a requirement has been met later, and testing can be
verified. If a formal Functional Configuration Audit is required, the tracking
in SCM is done almost automatic. The change requests (associated problem
reports) are promoted at the formal CM/QA time. If a requirement/change request
was promoted, but was not completed, a new problem report/change request should
be created and the promoted (resolved) closed out because it's better to move
forward (make a fix), rather than backing out a change or set of changes (PR) -
requiring REWORK/REBUILD/RETEST.
"Couball, James" wrote:
> Hello,
>
> I work for a company that develops software for others. There seems to be
> some issue here about when we should start using a change management process
> on projects. We follow Rational Unified Process (roughly). One manager
> here has argued that a project should not use change management until the
> beginning of the construction phase (most analysis and design finished).
> Prior to more formal change control, all artifacts would be in our version
> control repository. The idea is that change should be encouraged (and
> loosely tracked in the version control system) in the beginning phases of a
> project and controlled when those changes start having an adverse impact to
> budget and schedule.
>
> I was wondering what others had to say about this.
>
> Sincerely,
> James Couball
> Cotelligent
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:26:48 EDT