There is a place for formal Configuration Management and a
place for informal Configuration Management, however the basics are the same.
From a CM perspective, there is little reason for not controlling something. Being the pack rats we are, this is the
primary reason that deciding what constitutes a Controlled Item (CI) is
normally a Product Manager's role, not
a CM activity - even though CM should be involved in a consultancy capacity.
It turns out that regardless of the implementation
methodology, from classical Waterfall to Agile, there are similar roles to be
played. By determining what these roles are, we can then assign them to one or
more people. In the rest of this article I reprise a moderately formal list of
roles and responsibilities that I have used in the past. It has served me well
and continues to do so. Please note that the majority is copyright Weatherall,
Ltd. (1995 - 2007). Feel free to use the concepts, but if you publish or
reprint, please contact me via CMCrossroads email.
Basic
Job Functions and Responsibilities
The job functions described in this section do not
necessarily tie directly to individuals or job titles. They describe a
functional breakdown of work to be performed. On smaller projects, it is
perfectly reasonable to assign more than one job function to an individual. The
Work Breakdown Schedule (WBS) section of the Project Plan should identify how
the job functions are to be allocated.
Product
Manager
The Product Manager is responsible for maintaining the
vision and integrity of a product's identity, regardless of whether the product
springs from the mind of the Product Manager, or from a customer's Requirements
Specification. The Product Manager is the one who determines which features
will be implemented in each release and is the one that is supposed to insure
that each project is achievable. The primary activities performed are in the
areas of requirements gathering and management, and in risk management. The
Software Requirements Specification (SRS) used by everyone else is the
responsibility of the Product Manager.
Any documents produced by the Product Manager shall be
placed under SCM control, just like any other CI. At a minimum, they shall be
placed under control whenever they are published for review or distribution.
This includes any formal Peer or Customer Reviews. When referenced, these
documents should be referred to by either their external release level or by
their Revision Number within the SCM Repository, but not by both.
Project
Manager
Project Managers (PMs) are responsible for the overall
scheduling, staffing and implementation of a project. While not necessarily a
part of creating a Software Requirements Specification (SRS), they are responsible
for taking one and creating a deliverable product based upon it. It is also the
responsibility of a Project Manager to sign off on the Project Plan and any
other binding documents as well as seeing that they are adhered to and
maintained.
Any documents produced by the Project Manager shall be
placed under SCM control, just like any other CI. At a minimum, they shall be
placed under control whenever they are published for review or distribution.
This includes any formal Peer Reviews. When referenced, these documents should
be referred to by either their external release level or by their Revision
Number within the SCM Repository, but not by both.
Project
Architect
Project Architects are responsible for the actual
technology, algorithm development and software framework to be used in a
project. Much of a project's prototyping efforts are intended to validate the
theories and investigate the assumptions of the Project Architects before
committing to their incorporation into a Software Requirements Specification or
full development.
During the Test phase(s), Project Architects serve as
subject matter experts (SMEs) on the material being tested. They have the best
idea of the intent and expectations behind the SRS.
Software
Quality Assurance Engineer
Software Quality
Assurance (SQA) is the process of insuring that quality is built into an
application from the beginning and not just determined by testing near the end
of the project. The Software Quality Assurance Engineer (SQAE) makes sure this
happens by active participation in the entire project life cycle and validates
it by proper testing.
One of the
responsibilities of SQA is to conduct audits of both the code base itself and
of the data collected by SQC and SCM during a Release's lifecycle. In a formal
or regulated project, these audit results have a quasi-legal status, and thus
their distribution should be controlled. Audits are performed to validate that
the documented development and/or testing process(es) have been followed, to
identify areas of risk, and to insure an acceptable level of quality is present
in the audited release.
Software Test Plans
are also the responsibility of the SQAE. At a minimum, they shall be placed
under SCM control whenever they are published for review or distribution. This
includes any formal Peer Reviews. When referenced, these documents should be
referred to by either their external release level or by their Revision Number
within the SCM Repository, but not by both.
Software Quality Control
Engineer
Software Quality
Control (SQC) is the process of insuring that quality is present in a product
by testing or inspection, often near the end of the project or a project's iteration.
The Software Quality Control Engineer (SQCE) makes sure this happens by
exercising any Software Test Plans generated by the SQAE. Any test tools,
scripts, data, etc. developed by the SQCE shall be placed under SCM control and
identified with the same Version Labels or tags used to identify the
release/build level of the application being tested. Regression testing shall
be performed using SCM controlled test tools, scripts and/or data. Files
produced during testing shall be placed under SCM control and identified with
the same Version Labels or tags used to identify the release/build level of the
application being tested.
One of the tests
often performed by SQC is an inspection of the code base used to generate the
deliverables. This inspection is similar to an audit, but is often automated
and is looking for specific things such as comment-to-code ratios, function
points per module/object, adherence to coding standards or the cylclometric
complexity of each module/subsystem.
Any defects
identified during the execution of any Software Test Plans, etc. shall be
documented in a Defect, Issue and Enhancement Tracking (DIET) tool. A defect is
identified as any discrepancy between either a requirement or reasonable
expectations and the system under test/inspection.
Software Configuration
Management Administrator
Software
Configuration Management Administrators (SCMA) are responsible for insuring
that an SCM Plan exists as a separate document if it is required, that the SCM process and procedures are
documented and that the SCM process and procedures are followed during the life
of the project. They may or may not be the one to do the actual work, however
they have the responsibility to insure that the work is performed. Additional
SCMA responsibilities include, but may not be limited to:
- Performing
installations of, and updates to, the various SCM tools on all development
platforms;
- Coordinating
and administering the various SCM tool licenses and security features
- Performing
audits of both the SCM process and project repositories;
- Resolving
any SCM related problems which arise that the Project Administrators are not
able to handle; and
- Training
Project Administrators and Project Developers on how to use the SCM tools
to accomplish their daily tasks.
- Auditing
the Build Process
Build
Manager
A Build Manager's responsibilities include performing
incremental, baseline and release builds, as well as insuring that the build
process is valid. This does not imply any responsibility for testing to insure
code correctness, but rather the validation of the build process itself and
insuring that only the "correct" revisions of each module are used.
Additionally, the Build Manager is responsible for mentoring
developers who are creating and/or maintaining build scripts. Note that at the
discretion of the Project Manager, the Build Manager may be assigned the full
responsibility for all of the build script generation and maintenance as well
as their use.
If controlled builds are to be a part of the project
development cycle, then the Build Manager is responsible for insuring that the
build is performed properly and in the correct location(s). If the actual build
is delegated to someone else, the Build Manager is still responsible for
insuring the build's correctness.
Project
Leader or Lead Developer
The Project Leader,
or Lead Developer, is responsible for all of the Project Developers assigned to
him or her as well as the work they produce. Typically, a Project Leader is
responsible for one or more subsystems' technical development and is
accountable to the Project Manager. Technical responsibilities of the Project
Leader also include:
- Creation of the initial "clean" project
directory structure(s) to be placed under control.
- Determining which Project Developers
should be authorized access to the SCM repository (and to what level) and
informing the SCMA of such.
- Determining the development tools that
are to be used and where the tools are to place "derived" files.
- Deciding to what level make, build or
other third-party "enablement" tools will be used to augment the normal
development tools.
- Insuring (with the assistance of the
SCMA) that all Project Developers have compatible releases of SCM and
development tools installed/available from their systems
- Determining what audit reports need to
be created or customized.
- Determining whether or not SCM tools
need to be integrated into a development tool, IDE or workbench and, if
so, working with the SCMA to accomplish it.
- Selecting and/or verifying which of the
revisions of all controlled source modules are to be included in milestone
builds.
- Validating the Version Description
Document and any release notes corresponding to each controlled build.
From Maintenance
and Testing perspectives, Lead Developers are responsible for enduring that,
for any defect repaired or enhancement added, the appropriate entries in the DIET
System are updated.
Release Manager
A Release Manager
is responsible for insuring project deliverables are all at the correct
release/build level, are reproducible and are packaged so as to exclude all
non-deliverables. A release typically consists of files derived from controlled
source, however more may be included. Project specific manuals, initialization
and/or configuration files, Version Description Documents, Release Notes, etc.
may be required as well. It is the responsibility of the Release Manager to
either product or acquire these material and package them with the derived
files.
Package Manager
A Package Manager
is responsible for insuring project deliverables are acquired from the Release
Manager and packaged so as to exclude all non-deliverables. A package typically
consists of more that just derived components built by the Build Manager. It
may also include such things as an installation program and/or script,
third-party software, manuals, hardware security keys, serial numbers, license
keys, Version Description Documents and Release Notes. A package, as produced
by the Package Manager, is ready for deployment to end-users, regardless of
whether the release is internal to an organization or to external customers.
Project Developer
Project Developers are responsible for actually using SCM
tools to check the files out for modification and to check them back in after
modification. Defects and enhancements being tracked through the Diet System
are to be updated by Project Developers as they work on them.
If the Project Administrator allows, the Project Developer
may also add new files/object to the SCM Repository, modify Version Labels, and
promote/demote revisions through life cycle phases.
Change
Review/Control Board
Also known as the Configuration Control Board, it controls
changes to Configuration Items and Configuration Units, also called Controlled
Items or CIs.
The members of Change Review Boards and Change Control
Boards share many of the same responsibilities. They both are responsible for
checking all requests for change to a baseline release and to approve those
that should be made. The basic difference between them is that Change Review
Boards review and approve changes that should be made, but do not review the
changes after they have been completed and are ready for addition to the next
release. The Change Control Board does perform reviews at both ends of the
change cycle. Either physical or electronic signatures are required by one or
more members of these boards prior to any changes being made. Occasionally, in
exception or emergency situations, the development team may make any changes
they desire, but it takes the approval from a Change Review Board to allow the
changes to be migrated into a release.
Membership of these boards may vary during a project's life
cycle, however it should be based on a reasonable number of people who have a
stake in the success and stability of the product, have the authority to
approve changes or to place a hold on a release, and are generally available to
participate in the meetings. The meetings may be scheduled either on-demand, or
on a periodic schedule. The latter allows for easier overall project scheduling
since everyone knows when to be available, when changes will be announced, and
(hopefully) what will be under consideration.
DIET and Requirements tracking both belong under this role
and is normally a "staff" function. Prior to the official commencement of these
boards, this role reside under the control of the SCM Administrator since
individual projects are both too close to their own problems and have a vested
interest in insuring that they meet schedules, regardless of any problems
indicated.
What to Do with This
Information
Now that the roles are defined they can be pared down to
reflect the actual needs of a product or project. They can be made more or less
formal. They can be combined or functions performed by them may be reorganized
into other roles. What should be evident is that the roles do exist in the
majority of projects, even those that are staffed by a single person. It is
important to note that roles take on more or less importance depending on the
phase of a product's lifecycle. The
emphasis on product instead of project is intentional.
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed
