software development lifecycle cm process

8/9/2019 Software Development Lifecycle CM Process

1/19

CRF-RDTE-TR-20071011-01

2/2/2009

Public Distribution| Michael Corsello

CORSELLO

RESEARCH

FOUNDATION

SOFTWARE DEVELOPMENT LIFECYCLETHE CONFIGURATION MANAGEMENT ROLE


2/19

Corsello Research Foundation

Public Distribution CRF-RDTE-TR-20071011-01

AbstractSoftware 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).


3/19



Table of ContentsAbstract ......................................................................................................................................................... 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


4/19



IntroductionSoftware 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:

Ininformation technologyandtelecommunications, the term configuration

management or configuration control has the following meanings:

1. The management ofsecurityfeatures and assurances through control ofchanges made tohardware,software,firmware,documentation, test, test

fixtures and test documentation of anautomated information system,

throughout the development and operational life of a system. Source Code

Management orrevision controlis part of this.

2. The control of changes--including the recording thereof--that are made to thehardware, software, firmware, and documentation throughout thesystem

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 ascomponent repository

management. The second area concerns the activities performed for the

production and/or change of these entities; the termengineering supportis

often used to refer to this second area.

4. After establishing aconfiguration, such as that of a telecommunications orcomputer system, the evaluating and approvingchangesto 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
http://en.wikipedia.org/wiki/Information_technologyhttp://en.wikipedia.org/wiki/Information_technologyhttp://en.wikipedia.org/wiki/Information_technologyhttp://en.wikipedia.org/wiki/Telecommunicationshttp://en.wikipedia.org/wiki/Telecommunicationshttp://en.wikipedia.org/wiki/Telecommunicationshttp://en.wikipedia.org/wiki/Securityhttp://en.wikipedia.org/wiki/Securityhttp://en.wikipedia.org/wiki/Securityhttp://en.wikipedia.org/wiki/Hardwarehttp://en.wikipedia.org/wiki/Hardwarehttp://en.wikipedia.org/wiki/Hardwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Firmwarehttp://en.wikipedia.org/wiki/Firmwarehttp://en.wikipedia.org/wiki/Firmwarehttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Automated_information_systemhttp://en.wikipedia.org/wiki/Automated_information_systemhttp://en.wikipedia.org/wiki/Automated_information_systemhttp://en.wikipedia.org/wiki/Revision_controlhttp://en.wikipedia.org/wiki/Revision_controlhttp://en.wikipedia.org/wiki/Revision_controlhttp://en.wikipedia.org/wiki/System_lifecyclehttp://en.wikipedia.org/wiki/System_lifecyclehttp://en.wikipedia.org/wiki/System_lifecyclehttp://en.wikipedia.org/wiki/System_lifecyclehttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Component_repository_managementhttp://en.wikipedia.org/wiki/Component_repository_managementhttp://en.wikipedia.org/wiki/Component_repository_managementhttp://en.wikipedia.org/wiki/Component_repository_managementhttp://en.wikipedia.org/wiki/Engineering_supporthttp://en.wikipedia.org/wiki/Engineering_supporthttp://en.wikipedia.org/wiki/Engineering_supporthttp://en.wikipedia.org/wiki/Computer_configurationhttp://en.wikipedia.org/wiki/Computer_configurationhttp://en.wikipedia.org/wiki/Computer_configurationhttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Change_requesthttp://en.wikipedia.org/wiki/Change_requesthttp://en.wikipedia.org/wiki/Change_requesthttp://en.wikipedia.org/wiki/Change_requesthttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Computer_configurationhttp://en.wikipedia.org/wiki/Engineering_supporthttp://en.wikipedia.org/wiki/Component_repository_managementhttp://en.wikipedia.org/wiki/Component_repository_managementhttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/System_lifecyclehttp://en.wikipedia.org/wiki/System_lifecyclehttp://en.wikipedia.org/wiki/Revision_controlhttp://en.wikipedia.org/wiki/Automated_information_systemhttp://en.wikipedia.org/wiki/Documenthttp://en.wikipedia.org/wiki/Firmwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Hardwarehttp://en.wikipedia.org/wiki/Securityhttp://en.wikipedia.org/wiki/Telecommunicationshttp://en.wikipedia.org/wiki/Information_technology


5/19



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 ofthe 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 fullunit-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


6/19



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 thediscontinuation 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 softwarelifecycle. 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.


7/19



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 definedas 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.


8/19



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 orfailure 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


9/19



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 offand 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-goboundary 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.


10/19



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 designsare 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 beginningof 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:


11/19



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 designand 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 isalso 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.


12/19



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 allcode 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.


13/19



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 illustratesthe 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

customers 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.


14/19



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 iswhere 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 havealready 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 areretired 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.


15/19



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


16/19



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 MeetingsIn 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 atwww.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 configurationmanagement.

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 CIs current approved

configuration documentation.

Based upon these definitions, a CCB serves to control the level of change permitted in the SDLC for agiven 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.
http://www.google.com/url?sa=X&start=5&oi=define&q=http://www.ntsc.navy.mil/Resources/Library/Acqguide/appacm.htmhttp://www.google.com/url?sa=X&start=5&oi=define&q=http://www.ntsc.navy.mil/Resources/Library/Acqguide/appacm.htmhttp://www.google.com/url?sa=X&start=5&oi=define&q=http://www.ntsc.navy.mil/Resources/Library/Acqguide/appacm.htmhttp://www.google.com/url?sa=X&start=5&oi=define&q=http://www.ntsc.navy.mil/Resources/Library/Acqguide/appacm.htm


17/19



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 BoardThe 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 anticipatedneeds/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.


18/19



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 Roberts 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.

ConclusionsThe 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.


19/19


Public Distribution CRF RDTE TR 20071011 01

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

Roberts Rules of Orderhttp://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
http://www.awprofessional.com/articles/index.asp?st=42031&rl=1http://www.awprofessional.com/articles/index.asp?st=42031&rl=1http://agilemanifesto.org/http://agilemanifesto.org/http://www.agilealliance.org/http://www.agilealliance.org/http://architecturejournal.net/http://architecturejournal.net/http://www.booch.com/architecture/blog.jsphttp://www.booch.com/architecture/blog.jsphttp://www.cetus-links.org/oo_ooa_ood_methods.htmlhttp://www.cetus-links.org/oo_ooa_ood_methods.htmlhttp://www.cmprofessionals.org/http://www.cmprofessionals.org/http://www.stsc.hill.af.mil/CrossTalkhttp://www.stsc.hill.af.mil/CrossTalkhttp://www-128.ibm.com/developerworks/views/rational/library.jsphttp://www-128.ibm.com/developerworks/views/rational/library.jsphttp://www.ivarjacobson.com/html/index.htmlhttp://www.ivarjacobson.com/html/index.htmlhttp://www.robertsrules.org/http://www.robertsrules.org/http://www.robertsrules.org/http://www.scrumalliance.org/http://www.scrumalliance.org/http://www.isixsigma.com/http://www.isixsigma.com/http://www.sei.cmu.edu/http://www.sei.cmu.edu/http://www.ntsc.navy.mil/Resources/Library/Acqguide/acqguide.htmhttp://www.ntsc.navy.mil/Resources/Library/Acqguide/acqguide.htmhttp://en.wikipedia.org/wiki/Main_Pagehttp://en.wikipedia.org/wiki/Main_Pagehttp://en.wikipedia.org/wiki/Main_Pagehttp://www.ntsc.navy.mil/Resources/Library/Acqguide/acqguide.htmhttp://www.sei.cmu.edu/http://www.isixsigma.com/http://www.scrumalliance.org/http://www.robertsrules.org/http://www.ivarjacobson.com/html/index.htmlhttp://www-128.ibm.com/developerworks/views/rational/library.jsphttp://www.stsc.hill.af.mil/CrossTalkhttp://www.cmprofessionals.org/http://www.cetus-links.org/oo_ooa_ood_methods.htmlhttp://www.booch.com/architecture/blog.jsphttp://architecturejournal.net/http://www.agilealliance.org/http://agilemanifesto.org/http://www.awprofessional.com/articles/index.asp?st=42031&rl=1

software development lifecycle cm process

Documents