Software Development Lifecycle CM Process

CRF-RDTE-TR-20071011-01
2/2/2009
CORSELLO
RESEARCH SOFTWARE DEVELOPMENT LIFECYCLE
THE CONFIGURATION MANAGEMENT ROLE
FOUNDATION
Public Distribution| Michael Corsello

Corsello Research Foundation
Abstract
Software development is a cycle that follows a concept from the identification of a business need to
inception of a development project through to the release of a software application to market. This
cycle is iterative in that the release of a product to market completes a version of the application, at
which time the cycle begins again refining the product to capture new concepts and needs of the
customer(s).
Public Distribution CRF-RDTE-TR-20071011-01

Table of Contents
Abstract ......................................................................................................................................................... 2
Introduction .................................................................................................................................................. 4
Business Phase .......................................................................................................................................... 8
CM Role in the Business Phase ............................................................................................................. 9
Planning Phase .......................................................................................................................................... 9
CM Role in the Planning Phase ........................................................................................................... 10
Development Phase ................................................................................................................................ 11
CM Role in the Development Phase ................................................................................................... 12
Testing Phase .......................................................................................................................................... 12
CM Role in the Testing Phase.............................................................................................................. 13
Delivery Phase ......................................................................................................................................... 14
CM Role in the Delivery Phase ............................................................................................................ 14
Maintenance Phase................................................................................................................................. 15
CM Role in the Maintenance Phase .................................................................................................... 15
Groups and Meetings.................................................................................................................................. 16
Configuration Control Board (CCB) ......................................................................................................... 16
Design Review Board .............................................................................................................................. 17
Code Review Board ................................................................................................................................. 17
Project Management / Oversight Board ................................................................................................. 17
Meetings ................................................................................................................................................. 18
Conclusions ................................................................................................................................................. 18
Appendices.................................................................................................................................................. 19
References .............................................................................................................................................. 19

Introduction
Software development is a cycle that follows a concept from the identification of a business need to
inception of a development project through to the release of a software application to market. This
cycle is iterative in that the release of a product to market completes a version of the application, at
which time the cycle begins again refining the product to capture new concepts and needs of the
customer(s).
Throughout this cycle, it is important to manage the documentation and products produced. The
management of this content; documentation, code and other artifacts alike, is conducted as a
configuration management or content management process. This process has ramifications in
organizational, legal and contractual policy as well as serving as a point of reference for quality control
and process improvement.
According to Wikipedia, configuration management (CM) is defined as such:
In information technology and telecommunications, the term configuration

management or configuration control has the following meanings:
1. The management of security features and assurances through control of

changes made to hardware, software, firmware, documentation, test, test
fixtures and test documentation of an automated information system,
throughout the development and operational life of a system. Source Code
Management or revision control is part of this.
2. The control of changes--including the recording thereof--that are made to the
hardware, software, firmware, and documentation throughout the system
lifecycle.
3. The control and adaptation of the evolution of complex systems. It is the
discipline of keeping evolving software products under control, and thus
contributes to satisfying quality and delay constraints. Software configuration
management (or SCM) can be divided into two areas. The first (and older) area
of SCM concerns the storage of the entities produced during the software
development project, sometimes referred to as component repository
management. The second area concerns the activities performed for the
production and/or change of these entities; the term engineering support is
often used to refer to this second area.
4. After establishing a configuration, such as that of a telecommunications or
computer system, the evaluating and approving changes to the configuration
and to the interrelationships among system components.
The OpenGroup defines CM similarly as:
Configuration management (CM) services address four basic functions:
1. identification and specification of all component resources

2. control, or the ability to freeze configuration items, changing them only through
agreed processes
3. status accounting of each configuration item
4. verification through a series of reviews to ensure conformity between the actual
configuration item and the information recorded about it
Configuration management as a process serves 2 core purposes, management of information and input
to process improvement efforts. Both of these fundamental purposes are of great importance to the
organization, while the former is the most directly attributable to the business need for CM.
The software development process is fundamentally based on work efforts. These work efforts are
divisible into phases as in the Rational Unified Process, or more generically in the Software Development
Lifecycle (SDLC). A basic partitioning of the process will yield 6 primary phases:
1. Business Phase Definition of the business

problems and process related to these problems.
This is the critical and most overlooked phase
which determines whether a software solution is
merited or will even provide any gain as related
to the business issues which may be the actual
root cause of the problem to be solved. A well-
defined summary of this process should be a
requirement to entering the next phase.
2. Planning Phase In the planning phase, the
overall scope of the software to be developed is
generated and a vision of the ultimate goals of
the project is to be drafted. This phase will also
be ongoing as the design and documentation of
the application is built. This phase has a soft exit
requirement to begin development as enough
“fixed” interaction design to enable the initiation
of development.
3. Development Phase All actual production
development is performed in this phase. In
general prototyping is included as the initial
portion of this phase. This development must
also include unit testing of all code to include
any necessary test harnesses to be used in the
final testing. Exiting this phase has a hard requirement of all code passing all unit tests with full
unit-level code coverage.
4. Testing Phase Personnel on this phase must not be the same as the personnel in the
development phase. Breaking of this rule breaks the rules of objectivity which are imperative to
the sanctity of the testing. This phase is the final unit, integration and stress testing for the
entire system. All testing should be performed from the delivered source code baseline to
include full compilation and deployment onto test which is performed by testing staff utilizing
the deployment documentation and procedures from the development staff. The hard exit

requirement from this phase is that all tests are passed at 100% with full coverage of all code
and exceptions. Additionally, all deployment instructions must be acceptable to enable creation
of deployment procedures for full systems installation.
5. Delivery Phase In the delivery phase the personnel will generate the installation routines and
dependency packages for delivery to the customers. This phase should not include personnel
from the testing phase or development phase. Completion of this phase is indicated by
successful testing of resultant installation media and instructions from the testing phase of the
delivery phase.
6. Maintenance Phase This
is the long-term maintenance of an
application. This phase is the
lifecycle support for each version of a
production application including
patch development, testing,
packaging and deployment. As with
all other phases, this phase may
incorporate an entire lifecycle of its
own. This phase ends with the
discontinuation of support for the
targeted version of an application. In
general, each released and supported
version of an application has its own
distinct maintenance phase with
distinct support code bases and
infrastructure.
This partitioning relates well with the

RUP in terms of the software
lifecycle. In the RUP, all phases and
processes result in some artifacts
which are controlled in the CM
process. In this model of the software lifecycle, the CM process is involved throughout. In the pre-
development phases, the CM process is primarily involved in the maintenance of required and optional
artifacts. The CM process also ties directly to the definitions of the overall project lifecycle process
which separately defines the business rules for conducting a project, of which CM is a component.
In general, CM and project process are not the same. CM is the portion of the overall project process
that defines the rules, means and checks to ensure that the process is trackable, traceable and all
personnel and items are accountable. The CM process is most significantly involved in the definition of
the source code management (SCM) process for a software development project. It is important that
the distinction be made between the CM process and the larger encompassing software project process.

Formal process implementations should be lightweight and unobtrusive to all people involved in the
process. The CM process is no exception to this rule. The CM process should be no more complex or
cumbersome than is necessary to ensure compliance with
regulatory mandates and internal goals. It is further
important that internal goals are kept basic with emphasis
placed on asking “why” for every stated goal.
Each phase in the process will result in content that needs

to be managed. There will be some form of
documentation created in every phase, with additional
content formed in specific phases. It is important to not
only manage the resultant content, but also to manage
the revisions and thus the lifecycle of that content as well.
Since the primary goal of CM is to manage state, it is

important to realize the forms that state may take. There
are 3 primary concepts of state:
1. Current State - How things are now

2. Future State - What things will become
3. Change State - The state(s) involved in
transitioning from current state to future state
It should be obvious that the change state may be defined
as multi-state, where each atomic sub-state is itself a
current, future or change state. It is also important to
recognize that once a future state is realized, it is now the
current state, with all previous states collectively defined
as a change state to result in the current state. This is quite simplistic in concept, and neatly
encapsulates the concept of CM in terms of state management (as in SCM). Finally, it is important to
realize that the future state is a moving target that is often never fully realized. This concept is the
reality we are faced with in the ever changing business landscape.
The SDLC share common personnel teams that are actually involved in the work that is undertaken and
accomplished in each phase. Each personnel team plays a role in one or more of the phases of the SDLC
and serve a concrete role in the accomplishment of the goal for a given phase. While not all teams are
involved in every phase, some teams (i.e. management and CM) are involved in all phases of the SDLC.
A commonly overlooked team in the SDLC is the legal team which is of critical importance insuring that
the contracts between the organization and the customer are clear, concise and accurately represented
in the product phase delivery elements. It is the legal team that leverages the CM team preserved
information to ensure all accountability requirements are met to the letter of the law. It is also the legal
team that helps to ensure the letter of the contract is aligned with the spirit of the contract and within
scope of the management plan for delivery. Without the aid of a legal team a project may be in serious
“hot water” with regulatory and contractual compliance issues.

It is of great importance to remember that while there is a great deal of complexity in the phases and
teams of the SDLC; the processes in place should not
be elaborate. In general, the best strategy for
process structure is to be as small, light and simple
as possible while being as large, heavy and complex
as necessary to accomplish the stated goals.
Diving into the overall software project lifecycle, the

individual phases can be characterized by generic
workflows defining the overall process to progress
through the phases. Each phase workflow will have
one or more entry points with a workflow attached
to the entry point that defines the basic sequence of
events and checks that should be completed to
ensure a valid transition between phases. Also of
note is that the phases are not mutually exclusive,
even though the workflows do not directly indicate
parallel execution with other phases, each phases is
intended to run independently provided that
appropriate entry pre-conditions are met. This is
paramount to the flexibility and scalability of any
process.
Business Phase
The initial stage of the software lifecycle is the business phase. This phase is frequently reduced in
importance or ignored altogether even though it may often be the most critical phase to the success or
failure of the overall project. If there is no solid business definition that serves to support the
development of a software application, or if there is a lack of process in place to leverage the software
when developed, the project may already be doomed. There is additionally the potential for scope
creep due to a lack of direction in the business which often manifests itself in the software lifecycle as
the requirements begin to illustrate the business problems. While this is a general gain for the business,
the moving target for the software can result in failure of the project with public ridicule even though
the business may still reap benefits from the lessons learned during the process.
Even in these circumstances, the prior business analysis would result in greater gains for the business at
tremendous cost savings. It is important to realize that software is not always the best solution, and the
business may be “throwing technology at the problem” when the root cause of the problem is not truly
known. In this situation, as a software project suffers, the development team is blamed even though
the root of the problem may be the fault of the poor business direction. By requiring a strong business
phase a software team can ensure that there is a solidly defined need for software with defensible
documentation to ensure long-term support for the project. It is also possible that a decision to not
build a software solution is the final outcome of this phase. If no software is to be developed, the result

of this phase should translate into a fairly high ROI to the development team as little energy is expended
and no formal project is initiated.
Once the business phase is completed, and

a determination is made to begin a
software project, the project is kicked off
and the planning phase is begun.
CM Role in the Business Phase

Since at this phase there is no development
project, there is often no role for CM. If
however the software development
group(s) is involved in this process, or in the
case that there is a defined CM presence in
the business group, there may be
opportunity for CM in this phase.
The general role that CM may take in the

business phase is primarily that of
document management for all business
phase investigations. When the business
group also has an integrated CM role, there
is an added opportunity to track and
manage the existing business processes and
procedures. The level of complexity
involved in this CM process will be directly
related to the business management tools
and process controls used.
Planning Phase
The planning phase includes the definition of system vision, scope and ballpark cost. This phase
combines the inception and elaboration phases of the RUP and generally amounts to a significant
proportion of overall project timelines. It is at this point that the project staffing begins to increase.
In the initial portion of the planning phase a vision and scope is defined. This vision and scope are
generic, and should be fairly inflexible to ensure project budgets and timelines can be controlled. It is
also important to realize that there is no detailed scope defined at this point, simply a go/no-go
boundary for the beginning of the requirement gathering portion of this phase.
The overall processes (RUP, MSF, etc.) used in this and subsequent phases are not addressed in this
document, and as such, any detailed processes or methodologies may be employed. The workflows
defined here complement any methodology applied and serve as an overarching general concept to the
larger process. In general terms the CM processes employed function in the same manner.

It is important to note that in this phase, as the requirements gathering process proceeds, the project
may be cancelled at any time due to the discovery that the overall problem does not lend itself (at the
current time) to benefit from a software solution. Also, it is possible that the defined requirements will
be satisfactorily met by the purchase of an existing software solution (i.e. COTS/GOTS). In either case,
the project should be viewed as a tremendous success as there will be cost savings in both the
development process (short term) and software maintenance (long term). The overall purpose for any
project is to provide value to the user in terms of both productivity and costs.
In addition to the requirements gathering and refinement, this phase encompasses the entirety of the
design process. In design, all plans and constraints should be documented in artifacts. The use of
artifacts is exemplified by the Unified Modeling
Language (UML), but its use is neither required
nor specifically suggested. Any means of
design and modeling may be used if it suits the
needs and scale of the current project. It is
however of critical importance that all designs
are captured as artifacts and tied in some
manner to requirements or other artifacts. In
the final design, all artifacts should be linked
directly or indirectly to some requirement. Any
design elements that do not address a
requirement should not be developed as this is
superfluous cost to the customer.
CM Role in the Planning Phase

The planning phase marks the true beginning
of a software development project. This is the
point at which CM involvement truly begins.
During this phase the CM process should define
the means by which requirements are
captured, managed, revised, removed and
tracked for customer approval and code
acceptance crosswalk (RTM).
The management of requirements is a point of

critical importance in the software
development process and should be treated as
a primary point of responsibility for the CM
team. As requirements are gathered and
evolve, there must be a means of tracking
these requirements over time. This is the essence of change management (another related CM).
The role of CM in the requirements management process has several aspects:

 New Requirements Capture

 Requirement Removal
 Requirement Modification (tracked over time)
 Requirements traceability to code
 Customer acceptance of requirement (at each revision)
 Customer acceptance of requirements traceability (to ensure full coverage)
Each of these aspects requires an attention to detail, including ensuring legal compliance to all relevant
regulations and mitigation of risk associated with client disagreement at any phase. The legal issues to
be addressed in these CM controlled items may be handled by legal counsel assigned to the project (as
is often the case in industry), but the management of the artifacts supporting this process fall squarely
to the CM team.
As is true with every phase, any methodology or processes may be implemented in practice; all of these
issues must be addressed by any approach used.
Development Phase
Once the project is well-defined in terms of both requirements and design, the development phase
begins. In this phase the primary activity is
development of code in conformance to
the design artifacts produced in the
planning phase. The development of code
may include prototype code that serves as
a proof of concept for implementations.
These prototypes are generally used in the
planning phase for refinement of design
and to solidify the design decisions.
The development phase does not generally

proceed in isolation. Instead, the
development phase initiates as soon as
there is viable development work to be
done. At this same time the planning
phase is proceeding in parallel to the
development phase with continual
collaboration between the phases. It is
also not uncommon for personnel to be
working in the context of both phases
simultaneously. It is however important
that the development phase not start until
the planning phase has at least an initial set
of viable designs to be prototyped.

It is critical that all design artifacts are tied to a requirement in some measure. It is also critical that all
code is tied to some artifact or requirement. Any code that does not have a tie to a requirement will be
viewed by the customer as unnecessary and the cost of development of such code as a cost violation.
As development proceeds all code should be managed through some form of code repository or source
code management system (SCM). The requirements for placing code into the SCM and required update
intervals should be set either organizationally or per contract and enforced through the CM process.
CM Role in the Development Phase

The development phase is generally considered the “meat” of the software development cycle as all
code is generated here. It is generally the role of the CM team to ensure that all source code is properly
maintained in the SCM system and to validate that only compilable code is stored in the SCM. It is
generally also the CM team that collaborates with the build team to ensure nightly build processes are
documented and stored for project progress metric reporting.
As design and development progresses, the drift between planned mappings of design to requirements
and actual code to requirements for code identified to support a design artifact will vary. It is often the
job of the CM team to provide a metric as to requirement coverage and design coverage to ensure the
project is on track to meeting the customer needs. It is important that there is a minimal impact on the
design and development team with regards to both the CM process and the requirements
accountability. To ensure that the customer is being adequately served and not being charged for the
development of unneeded features, the crosswalk of code and design to requirement is critical.
Testing Phase
The testing phase is another largely overlooked part of the software lifecycle. It is important that all
code written be tested thoroughly and often. Each bug that is caught early (preferably in the planning
phase) will cost an order of magnitude less
to fix than a bug caught late in the process.
It is arguable that this change cost curve for
agile processes is flat, however if examined
in a micro scale (agile has a tight cycle), the
cost curve is comparable, just on a smaller
scale.
In any software development process, the

concept of an organized test cycle outside of
the development cycle is important to
ensure a validation of testing at the
developer level. This integrated testing
serves as a secondary test at the unit level, and is generally the first full integrated systems testing
performed (nightly builds are generally also periodically tested). This phase is entirely about testing the
system, from setup and deployment instructions to documentation to unit and load testing.

Upon completion of this phase, the software system should be ready for packaging and release to
market. This phase is the critical assessment phase that determines if the overall solution is adequate to
release. If any portion of the system fails, the
RTM is delayed. This very concept illustrates
the importance of unit testing early and
often. It is also important that nightly builds
are performed and that integrated builds are
performed as early as possible.
It is of critical importance that the testers in

this phase are not involved in any other phase
of this project. This ensures a defensible,
unbiased testing that may often involve the
customer’s technical representative to
oversee the testing process and in process
reports. While the testing phase officially
begins upon the conclusion of the
development phase, the testing of nightly
builds is often performed in conjunction with
the testing staff to ensure any integration
problems are caught early. This is especially
important for large-scale (500,000 lines of
code or more) and distributed systems
development efforts.
Upon conclusion of this phase, the system is

ready for release to market.
CM Role in the Testing Phase

In the testing phase, the code base is “locked
down” from the development phase. This is to say that a baseline is created in the source that defines
the completion mark of the development phase that serves as a metric collection reference to
determine the level of change required in the testing phase. As defects are recorded, the changes and
impacts can be measured relative to the baseline. This serves as feedback into the process to improve
the quality of the process for future projects.
In testing, all tests are documented and revised as they progress and is all captured through the CM
process. In the testing process each test is bound to some reference artifact; either a model (i.e. use
case) or a specific requirement(s). This serves to ensure the system as a whole is operating within
specification to the documented requirements.

The role of test begins to decline in this phase in terms of sheer volume, but this phase is the pivotal
point in the accountability and acceptance process.
Delivery Phase
The delivery phase is the shortest and least involved phase in the overall process. This is not however to
say it is the least important. This phase is
where all accountability is checked for
customer approval, all documentation must
have been completed and incorporated into
the system, and the setup packages are
created.
This is essentially the shrink wrap phase of

the process, where the final packaging for
the system is created, tested and sent to the
customer. Generally, all defects have
already been found in the system that will
be found in the process. The only testing in
this phase is that of the installation process
and packages generated in this phase.
Ancillary processes that often occur in this

phase include the customer walk-through,
marketing material creation, cosmetic
adjustments to documentation and most
significantly, the wrap-up of the initial
software cycle.
CM Role in the Delivery Phase

In the delivery phase, the CM team will
ensure all code bases and documentation is
baselined and archived for long-term
preservation. According to internal
procedures, any unneeded interim content can be scheduled for purging and general cleanup is
performed.
This is actually a time of increased activity for the CM team, as all committees, boards, groups, etc are
“retired” for this delivery cycle (and possibly reformed for the next release). It is important that at this
point in time all requirements have been signed off by the customer as being met and tested. It is here
where all legal issues need be addressed to ensure the final delivery of this version is bound and
concluded.

Maintenance Phase
The maintenance phase is the bug-fix, security patch and general support phase of the SDLC. This phase
includes the capture of bug reports and the tracking of their disposition to include the verification of
existence of the bug. Also, all feature enhancement requests may be captured to provide input to the
next versions.
The length of this phase is bounded by the support contract length for a specific version of the system.
If there are 3 concurrently supported versions of the system in the marketplace, then there are 3
concurrent maintenance phases running, most often supported by the same personnel.
As bugs are reported, the development of patches and propagation of that code to the baseline code for
future releases is the responsibility of the personnel staffing this team. Bugs that are discovered by the
developers on new versions also report the bugs to the maintenance teams to enable the patching of
deployed systems.
CM Role in the Maintenance Phase

The CM role for maintenance is the management of bugs, enhancement requests, patch development,
service pack creation and the crosswalk of these fixes across supported versions. There is a continual
interaction of the CM team with maintenance staffers, new version developers and customers. This

interaction must be documented and each facet of the process kept clearly isolated (if only logically) to
ensure accountability in the process.
As in every phase of the SDLC, the impact of these operations on the other groups involved must be
minimal while yielding value to the organization.
Groups and Meetings

In any software development project, there is an inevitable need for groups to address aspects of the
project, and for meetings in which these groups discuss those aspects. While most of us dislike
meetings, they do have merit and add value to the process if managed properly.
Each methodology for software development will specify some groups that should be used to track the
progress of the project. This paper will briefly cover a few of the more commonly used groups.
Configuration Control Board (CCB)

As taken from the Navy site at www.ntsc.navy.mil:
Configuration Control is defined as:
The systematic proposal, justification, evaluation, coordination, approval or disapproval

of proposed changes, and the implementation of all approved changes to the
configuration item (CI) after establishment of the configuration baseline(s) for that CI.
Configuration Item (CI) is defined as:
A configuration item is an aggregation of hardware and/or software that satisfies an

end use function and is designated by the Government for separate configuration
management.
A Configuration Control Board (CCB) is defined as:
A board composed of technical and administrative representatives who recommend

approval or disapproval of proposed engineering changes to a CI and its current
approved configuration documentation. The board also recommends approval or
disapproval of proposed waivers and deviations from a CI’s current approved
configuration documentation.
Based upon these definitions, a CCB serves to control the level of change permitted in the SDLC for a
given product. It is important to note that bugs are not addressed in this construct. A CCB is primarily
charged with dealing with changes from the requirements as originally defined in the early stages of the
planning phase. Any time a change from the existing plan is needed or desired; the CCB will either
approve or disapprove the change. It is common for the customer to be represented on this board in
addition to the project staff.

As an augmentation to the CCB, a local configuration change board (LCCB) may be formed to perform
CCB functions on a local level (generally on training systems). The LCCB can also be a vehicle for internal
change management for bug tracking and smaller internal changes that are not significant enough for
the CCB.
Design Review Board

The design of a system should be reviewed for consistency and for coverage of the requirements. This
review process is generally conducted by a standard design review board (DRB). This group will evaluate
the individual design artifacts and the aggregated artifacts for consistency, standards compliance and to
ensure the design accurately and completely cover the requirements as defined in the project design.
Code Review Board

All code that is written to support a development project may be reviewed for alignment with the
design artifacts used to construct the code. Code reviews also may be used to ensure compliance of
code to programming standards and coding conventions. All code reviews, if performed, are conducted
by members of a code review board (CRB).
Code reviews, like design reviews can reveal limitations in the overall system as evaluated in its
constituent parts. By discovering these problems early, a tremendous amount of time may be saved
from the testing phase. While code reviews are of greater importance as project size increases, they
may be beneficial to any development project.
Project Management / Oversight Board

All aspects of a project, software or otherwise must be managed, tracked and resources accounted for.
This is the nature of business, and like it or not, software development is a large dollar money making
business. Unfortunately, many technical people are quite business oriented, while many other technical
people are quite non-business oriented. This makes for a delicate mix of those who are easily managed,
those who want to be managers and those who do not want to be managed in any way.
Managing and overseeing a software development project is a balancing act of ensuring that resources
are adequately allocated and utilized while not intruding upon the creative process and its natural flow.
In general, management of software projects must be flexible, macro-scale and yet still maintain enough
insight at a granular level to detect and prevent problems in situ. This is a major challenge which is
often addressed through the use of project management (PM) or project oversight (PO) boards.
A PM/PO board is composed of managers and team leads from the various sub-projects and teams
within the overall software project. These managers report their statuses and their anticipated
needs/concerns with respect to the other teams. This provides a reduced personnel meeting focused on
the operational requirements for integration of the constituent components being designed and built.
The use of these teams is generally best realized for projects involving more than 5-10 developers.

Meetings
Each of the groups involved in a software project will need to meet to discuss their respective area of
concern. The schedule for such meetings should be regular to ensure consistency, but should be no
more frequent than is beneficial to the accomplishment of the goals of the group. In a small project, the
meeting frequency is generally less than that of larger projects.
Whenever a group meets, it should follow a set of standard meeting rules (such as Robert’s Rules of
Order / Parliamentary Procedure) to ensure consistency and fairness. It is also important to ensure a
non-inflammatory and impersonal conversational style. That is to say that there should be no “blaming”
or attribution of decision or effort to any individual(s). This keeps the meeting professional and
technical with a reduced likelihood of personal interests being addressed.
All meetings need to be controlled by a moderator. The moderator should ensure that the
conversations stick to the topic of the meeting and that the rules of the meeting are adhered to. It is
also the job of the moderator (and the rest of the audience) to ensure that the tone of the conversation
(non-inflammatory and non-attributional) is maintained with a no-tolerance policy given to violations.
Conclusions
The software development lifecycle is an extremely complex business undertaking with significant non-
technical ramifications. A well defined set of practices and processes are required to ensure activities
are repeatable with a high probability of success. Further, ensuring that all aspects of the processes are
accountable is the responsibility of the configuration management team.

Appendices
References
Addison Wesley SE http://www.awprofessional.com/articles/index.asp?st=42031&rl=1
Agile Manifesto http://agilemanifesto.org/
Agile Alliance http://www.agilealliance.org/
Architecture Journal http://architecturejournal.net
Booch, Grady http://www.booch.com/architecture/blog.jsp
Cetus-Links OOAD methods http://www.cetus-links.org/oo_ooa_ood_methods.html
CM Pros http://www.cmprofessionals.org/
CrossTalk http://www.stsc.hill.af.mil/CrossTalk
IBM Rational Technical Library http://www-128.ibm.com/developerworks/views/rational/library.jsp
Jacobson, Ivar http://www.ivarjacobson.com/html/index.html
Robert’s Rules of Order http://www.robertsrules.org
Scrum Alliance http://www.scrumalliance.org
I Six Sigma http://www.isixsigma.com
Software Engineering Institute http://www.sei.cmu.edu/
US Department of the Navy Acquisition Guide

http://www.ntsc.navy.mil/Resources/Library/Acqguide/acqguide.htm
Wikipedia http://en.wikipedia.org/wiki/Main_Page

Software Development Lifecycle CM Process

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Development Lifecycle CM Process

Uploaded by

Copyright:

Available Formats

CRF-RDTE-TR-20071011-01

Public Distribution| Michael Corsello

Public Distribution CRF-RDTE-TR-20071011-01

Public Distribution CRF-RDTE-TR-20071011-01

According to Wikipedia, configuration management (CM) is defined as such:

In information technology and telecommunications, the term configuration

1. The management of security features and assurances through control of

The OpenGroup defines CM similarly as:

Configuration management (CM) services address four basic functions:

1. identification and specification of all component resources

Public Distribution CRF-RDTE-TR-20071011-01

1. Business Phase Definition of the business

Public Distribution CRF-RDTE-TR-20071011-01

This partitioning relates well with the

Public Distribution CRF-RDTE-TR-20071011-01

Each phase in the process will result in content that needs

Since the primary goal of CM is to manage state, it is

1. Current State - How things are now

Public Distribution CRF-RDTE-TR-20071011-01

Diving into the overall software project lifecycle, the

Public Distribution CRF-RDTE-TR-20071011-01

Once the business phase is completed, and

CM Role in the Business Phase

The general role that CM may take in the

Public Distribution CRF-RDTE-TR-20071011-01

CM Role in the Planning Phase

The management of requirements is a point of

The role of CM in the requirements management process has several aspects:

Public Distribution CRF-RDTE-TR-20071011-01

 New Requirements Capture

The development phase does not generally

Public Distribution CRF-RDTE-TR-20071011-01

CM Role in the Development Phase

In any software development process, the

Public Distribution CRF-RDTE-TR-20071011-01

It is of critical importance that the testers in

Upon conclusion of this phase, the system is

CM Role in the Testing Phase

Public Distribution CRF-RDTE-TR-20071011-01

This is essentially the shrink wrap phase of

Ancillary processes that often occur in this

CM Role in the Delivery Phase

Public Distribution CRF-RDTE-TR-20071011-01

CM Role in the Maintenance Phase

Public Distribution CRF-RDTE-TR-20071011-01

Groups and Meetings

Configuration Control Board (CCB)

Configuration Control is defined as:

The systematic proposal, justification, evaluation, coordination, approval or disapproval

Configuration Item (CI) is defined as:

A configuration item is an aggregation of hardware and/or software that satisfies an

A Configuration Control Board (CCB) is defined as:

A board composed of technical and administrative representatives who recommend

Public Distribution CRF-RDTE-TR-20071011-01

Design Review Board

Code Review Board

Project Management / Oversight Board

Public Distribution CRF-RDTE-TR-20071011-01

Public Distribution CRF-RDTE-TR-20071011-01

Agile Manifesto http://agilemanifesto.org/

Agile Alliance http://www.agilealliance.org/

Architecture Journal http://architecturejournal.net

Booch, Grady http://www.booch.com/architecture/blog.jsp