More white papers:
Find out more ...
|
|
Neuma White Paper:
CM: THE NEXT GENERATION of Integrated CM/PM
One of the
problems with Configuration Management (CM) and Project Management (PM)
is that the tools and the data repositories for each are separate. As a
result the processes are quite separate. The Project Manager takes a
set of requirements and decomposes them into tasks, which are then
prioritized, scheduled and assigned. The CM team creates Configuration
Items and tries to tie the CIs back to the requirements so that they
can be properly audited. When CM and PM work together they tend to
enhance each others function, and eliminate potential overlap in the
processes.
I'll keep it short this month and stick to this single message.
Project Management
Project
Management deals with execution. A project is a series of tasks aimed
at accomplishing a specific goal or set of objectives. In software
development, a project typically transforms one release of a software
system into another release. This is done through a series of
operations as outlined below:
- Tranforms Release Requirements into Working Product
- Transformation done through Work Breakdown Structure (WBS) detailing tasks
- Tasks are defined, prioritized, and assigned
- Efforts are estimated and rolled up to give both a schedule and a plan of completion
- Critical path analysis identifies potential risk areas
- Work effort is tracked for each task, typically using timesheets
- Timesheet effort is rolled up to identify actual effort
- Revised efforts are used for risk identification and schedule adjustment
- Complex tasks are reviewed for risk and monitored
- Resources are managed to ensure timely completion of tasks and adequate risk support.
In
an agile project, scheduling is less stringent with prioritization
typically sufficient to ensure that each iteration addresses the
appropriate content. Risk is dealt with through daily feedback and
resources/content moved if necessary. Tasks are generally kept to a
reasonably small size so that the tasks can be completed in a single
iteration when possible. The result is that we might see a finer level
of decomposition in the WBS, and a corresponding improved level of
traceability.
Configuration Management
Configuration
Management deals with tracking the artifacts produced by the process,
and ensuring that a consistent set of baselines march forward toward
project completion. The focus is then on auditing the output of the
process to ensure that is satisfies the input. Configuration
Management works hand-in-hand with Change Management as follows:
- Requirements
are translated from customer/market to product requirements (i.e
functional spec), and then to system design requirements (possibly
additional levels)
- Design requirements are addressed by changes/updates which modify files
- File revisions are traced back (through the changes) to the requirements
- Changes are implemented by the development team and "unit tested" prior to check-in
- Changes are reviewed and approved for integration
- Change promotion is used to create new baselines
- Builds are created based on a baseline plus additional changes to be applied against the baseline.
- Builds are tracked to clearly identify the exact software/system content of the deliverables
- CM tools trace contents of builds back to the requirements addressed by each build so that they may be audited
- Verification
is performed using the appropriate set of test cases that apply to the
specified build. This typically verifies the functional spec.
This is not an exhaustive description of CM, but just a rapid end-to-end overview of the process.
If
you look closely, you will see a good level of overlap between Project
Management and Configuration Management. Each has to transform the
initial requirements into more detailed design goals. Traceability has
to be maintained. Both converge on the developers desktop.
Convergence
Typically
in a PM tool, tasks are identified, scheduled and tracked. In a CM
tool, changes are created, requirements/documents/source code modified
and checked in. The PM tool gives a task management/progress view,
while the CM view identifies modified revisions. Trying to relate the
two can be a lot of work.
However, consider an approach where
the WBS doesn't simply contain tasks, but identifies task containers
with the contents attached. So a Design Task might have a Design
document attached to it. It might decompose into 3 Changes each with
it's own set of files attached. The Design Task might also have a
White Box Test Plan Task attached for testing the design. Higher up
the tree, the Design Task may have as its parent a Feature
Specification which is a portion of the Functional Spec for the project
and which is attached to the FS Task which created the FS Document.
Along side the Design Task might be a couple of other tasks under the
FS Task: A Test Plan for the Feature, and a User Guide snippet for the
feature (assuming this is different than the Functional Spec).
Now
put in a CM tool that works on this WBS. Instead of the WBS being a
planning and tracking it is now a living organism. Traverse the WBS
and it becomes the total content of the project. The tasks, the
feature specifications, the changes, build records, and so forth. As
well, the changes made to the requirements, documents, source code, and
test cases are part of the WBS.
Now a project is typically used
to transform a product from one (possibly empty) release to another.
So: Product.rel1 + Project.rel2 => Product.rel2. The idea is that
each WBS can capture everything, from changes in requirements through
to source code and test case changes. On the CM side, intermediate
steps collect changes to create baselines along the way, whether for
requirements, documentation, source code or test cases. Build records
are used to record intermediate builds in terms of a baseline plus a
set of changes, as the WBS continues to grow, until finally the project
is done.
In this integrated view, not only do we see full
traceability enhanced through the WBS, but we also see progress
measured by the actual completion of tasks - check in of changes for
requirements, documents, software and test cases. And furthermore,
these changes are promoted as they move through the verification tasks.
One
of the major benefits here is that the visibility of the WBS across the
team allows the visibility of the entire set of project data. As the
WBS grows, clarity is provided for each of the team members. And as the
WBS grows, a visible measure of progress is provided.
Mitel - The First Test Bed
The
first time I implemented this architecture for an integrated CM/PM tool
and process was in the mid-1980s at Mitel (a PBX manufacturer in
Ottawa, ON). Even though we were at the time restricted to
command-line user interfaces (which didn't appear widely until the
'90s), the success of the approach was widely evident to all, including
upper management. Product Managers and VPs would regularly access the
system to identify an up-to-date state of each project. Risk
management was simplified as all of the data was integrated into the
same repository and accessed through the same tool.
The entire
team, used the same tool and even the marketing people wanted to go
into the CM database both to provide product input and to identify the
status and contents of each release. A quick by-product was to
generate and circulate regular documents so that the less technical
minded did not have to learn a command line interface to the tool.
Initially deployed on the SX-2000 project, the approach continued
through at least 2 decades.
We made an effort to continue to use
integrated CM and PM ever since at Neuma (using CM+). We've reaped the
benefits of rapid development and better communication - the result: a
more agile, higher quality development environment.
The bottom
line: Don't treat Project Management as an add on function to your
development; and don't treat CM as an add-on function to your
development. Integrate them and reap the benefits.
Joe Farah is the President and CEO of Neuma Technology . Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe by email at farah@neuma.com
|
