Configuration Management Body of Knowledge

Table of Contents - 14 15 

Overview

{ Discuss how CM contributes and benefits project managers in resource planning, Estimating, budgeting, and cost controls. }

7.1 CM's CONTRIBUTIONS AND BENEFITS TO PROJECT MANAGEMENT

Address things like planning, estimating, metrics, budgeting, cost controls etc.

7.2 CM's CONTRIBUTIONS TO QUALITY

The Handbook of Software Quality Assurance's summary of Chapter 11 written by William Bryan, D.Sc and Stanley Siegel, Ph.D, best speaks to the contributions that CM has upon quality. It says that "Software Configuration Management offers the buyer, user and seller protection against the myriad problems that often beset software development and maintenance projects -- problems that, if left unaddressed, can easily spell project disaster. To address these problems, the four" CM "functions -- identification, control, auditing, and status accounting -- must be practiced in, and indeed integrated into, the software development process throughout the project life cyle."

Stanley and Bryan remind us that "Establishment of" a CM "program on a project of any size is practicable and economically justifiable. Management commitment to installing the checks and balances provided by SCM is of paramount importance. A" CM "program should be established gradually, molded to the organization and functions of the company and its projects and to available personnel. An early endeavor should be the establishment of a Configuration Control Board periodically meeting to maintain change control for the project. Other areas of importance for" CM "are the conduct of audits of the software products, particularly early in the life cycle, and of acceptance testing of the completed software code prior to its delivery to its users."

They finish the chapter by saying that with "the installation of such a program, a large measure of protection will be provided to a project through an increase in visibility and traceability, through the establishment of project control and change control, and through provision of a capability to monitor project events. The end result is an increased likelihood of developing ... systems that satisfy user needs and that are delivered on time and within budget." -- SmKershaw^? - 18 Feb 2003 {From Handbook Of Software Quality Assurance, Chapter 11}

Configuration Management should in essence be the safety valve, to use an engineering cliche, by which projects are watched, reviewed, audited, and reported. The metrics generated by CM efforts can be valuable to Quality Assurance efforts, as QA is charged with serving as the watchdog. When both the CM and QA are strong organizations the two being present and engaged on a project create an environment wherein quality products are achieved.-- SmKershaw^? - 18 Feb 2003

7.3 CM's CONTRIBUTIONS TO DEVELOPMENT EFFORTS

The contributions made by configuration management toward development efforts are surprisingly small in quantity, but huge in value. Developers are assured, through competent and confident configuration management that their efforts will not be 'lost' or 'scrambled'. That with a safe, and repeatable process, CM contributes to the sanity of developers in what seems often times to be an insane development arena. CM brings order in the chaos. CM brings peace of mind to the worried. CM simplifies and improves business patterns for the good of projects. CM adds value to the development effort, it isn't just a required overhead expense.

Through the identification efforts of CM, developers and managers alike, know what they are working on and where it is. It is through CM's efforts to control configurations that order is brought to the project. It is through CM's auditing efforts that the developers and managers alike are 'assured' that all is well. Lastly, it is through status accounting (reporting) that concerns, issues (positive and negative) are made known to all interested parties.

-- SmKershaw^? - 09 Mar 2003

7.3.1 Agile Development and CM

A fairly new term and technique is now being applied to configuration management in software development. It is known as "agile". The name "agile" is fairly recent in its use for describing a category of software development methods. The term "lightweight" was previously being used, but some felt that wasn't quite an accurate word, and since the term "organizational agility" was (and is) fairly popular, they felt it fit in this case as well. But that is neither here nor there.

It is important to note that "agile" isn't simply repacking of 100% old ideas. There are a few new elements thrown into the mix with all that older and more familiar stuff. Some of the methods classified as "agile" are old methods that have been around for awhile (like DSDM). And there is a big intersection of RAD and Agile, such as DSDM and RADical Software Development.

It is very true that many of the ideas that go into it have been around a very long time, such as iterative development, evolutionary delivery, and a spiral-like lifecycle.

One fundamental characteristic of agile methods is that not only are they iterative, but the iterations are typically very short: as little as one week, to possibly 14 weeks (but with a more typical range of 1-4 weeks).

Probably the key differentiating factor of "agile" methods has to do with the so-called "cost of change" curve. The usual thinking is that, the more lifecycle phases that pass between the introduction and correction of a fault, the cost of rework to fix it is about an order of magnitude more expensive for every phase it escaped. Agile methods turn this on its ear and challenge this thinking, and suggest that under certain circumstances, this "cost of change" need not be exponentially increasing, and in fact could be flattened somehow.

The best "succinct" description of it would be the article Retiring Lifecycle Dinosaurs from STQE magazine (Software Testing and Quality Engineering, July/Aug. 2000.)

Another good and concise introduction would be Martin Fowler's The New Methodology. Martin also has a short article The Agile Manifesto: where it came from and where it may go that does a good job of explaining its ideas and principles.

Another element of Agility (not just for software, but organizationally as well) is the concept of "emergence" and "self-organization" from the sciences of complex adaptive systems and complexity theory. Some of these elements are present in something like RAD, but it's not an intentional part of it the way it is for so called "Agile" methods (see Agile Software Development: The Business of Innovation)

Another element related to the complexity theory is the premise that software development should not be considered to be like Manufacturing in its models and processes (which is what CMM and others are premised upon - Crosby's writings and the Manufacturing Maturity Model (MMM)). The agile premise is instead that software is more like the scientific method of new discovery, due to rapid and volatile change, and a model of hypothesize-experiment-adapt/adjust is more appropriate.

This leads to a different mind-set that relies more heavily on feedback that is more frequent. Instead of focusing more on end-of-phase reviews to try and catch faults before going to the next phase, it's almost as if the mind-set is one of embracing constant change/adjustment rather than trying to prevent it.

Rather than laboring so hard during a phase or lifecycle to get spend a lot more time making sure I get it right after every phase, accept that I won't get it right the first time (or the second time), and instead, simply fail much sooner, more frequently, and learn from it and make corrective action much earlier and more frequently. Elements of this are also present in Boehm's risk-based spiral model, but its not quite so blatant there as it seems to be in the most popular agile methods.

Some of the agile methods are more blatant about this than others (e.g., Extreme Programming, SCRUM, Crystal, ASD) and tend to be the newer ones. Some of them are more moderate and its harder to see the difference between them versus highly iterative spiral model (FDD, Agile Modeling, DSDM).

Some of the more "flagrant" or "extreme" agile methods are that way in part due to a violent counter-response to the Software CMM and similar frameworks. This reaction isn't quite necessary. Running all the way to the other end of the spectrum is just as imbalanced as the (mis)application of CMM that is being rejected.

So while there is certainly a lot of "old stuff" and existing best-practices in "Agile" software methodologies - there are one or two (maybe even three) very different things which flagrantly challenge some of the prevailing wisdom that gave us Formal Inspections, SQC, and the CMM.

Other references for agile can be found at:

• The Agile Alliance's "Agile Articles" Index
• Agile Software Development, by Alistair Cockburn (pronounced "Coh-burn")
• Agile Software Development Ecosystem's, edited by Cockburn and Highsmith.
• Highsmith's book Adaptive Software Development

Agile is an important thing to understand, and not simply write-off as "what's old is new again". A lot of its current popularity is from the classic vicious cycle of bouncing back and forth between extremes. Before CMM, there was not enough emphasis on process. Then many started taking it too far in the other direction as people clamored for CMM-ratings (passing the test and having the appropriate docs & bureaucracy became more important than the process and its effectiveness for many shops that misapplied the CMM).

Now the swing is going back in the other direction, and "agile" is a big part of that. But there is something new underlying a lot of the old stuff making a "comeback". Configuration Management is going to be critical "fulcrum" in leveraging a balanced and effective set of processes and criteria. With such a large emphasis on "lean" and "lightweight", CM on agile projects will need to be less intrusive/invasive (what Grady Booch would call "low-friction") to allow agile projects to succeed while at the same time not being so non-existent (due to overreaction) as to contribute to their failure.

{ Brad Appleton^? from CMCrossRoads Community Forum on Agile Development, Repeated here with permission and with slight modification -- SmKershaw^? - 09 Mar 2003}

7.3.2 Rapid Development and CM

The web site, http://www.webopedia.com, defines Rapid Application Development as: “A programming system that enables programmers to quickly build working programs. In general, RAD systems provide a number of tools to help build graphical user interfaces that would normally take a large development effort. Two of the most popular RAD systems for Windows are Visual Basic and Delphi.“

“Historically, RAD systems have tended to emphasize reducing development time, sometimes at the expense of generating efficient executable code. Nowadays, though, many RAD systems produce extremely fast code. Conversely, many traditional programming environments now come with a number of visual tools to aid development. Therefore, the line between RAD systems and other development environments has become blurred."

{Copied from the www.webopedia.com site. -- SmKershaw^? - 08 May 2003 }

7.3.3 Extreme Programming

According to information found at http://www.xprogramming.com, “Extreme Programming, or XP, is a lightweight discipline of software development based on principles of simplicity, communication, feedback, and courage. XP is designed for use with small teams who need to develop software quickly in an environment of rapidly-changing requirements.”

“XP was developed by Kent Beck, who wrote the original book on the subject, Extreme Programming Explained. Two new books will reach the market by October, Extreme Programming Installed, by Ron Jeffries (your host), Ann Anderson, and Chet Hendrickson; and Planning Extreme Programming, by Kent Beck and Martin Fowler. Ultimately, any team's software development methodology needs to be customized to the team and their circumstances. No methodology is just a collection of rules to be performed in rote fashion, and XP - in spite of its famous rules - is no exception.”

For more information you should explore the web site listed above in this section.

{The above section was copied from the www.xprogramming.com web site. -- -- SmKershaw^? - 08 May 2003 }

7.3.4 SCRUM

According to the Web site, www.controlchaos.com, Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:

• Scrum is an agile process to manage and control development work.
• Scrum is a wrapper for existing engineering practices.
• Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
• Scrum is a process that controls the chaos of conflicting interests and needs.
• Scrum is a way to improve communications and maximize co-operation.
• Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
• Scrum is a way to maximize productivity.
• Scrum is scalable from single projects to entire organizations.
• Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
• Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Scrum naturally focuses an entire organization on building successful products. Without major changes -often within thirty days - teams are building useful, demonstrable product functionality. Scrum can be implemented at the beginning of a project or in the middle of a project or product development effort that is in trouble. Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototyes. Based in modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.

Scrum as applied to product development was first referred to in "The New New Product Development Game" (Harvard Business Review 86116:137-146, 1986) and later elaborated in "The Knowledge Creating Company" both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford University Press, 1995). Based on their ideas and research in process theory performed in collaboration with DuPont^? Advanced Research Facility, Scrum was first formulated and presented to the Object Management Group in 1995. The Scrum process is fully described in a recent book from Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Prentice Hall, 2001).

{The above is a complete quote taken directly from the www.controlchaos.com website.-- SmKershaw^? - 08 May 2003 }

7.3.5 CMM

The Capability Maturity Model, as described in The Capability Maturity Model by Carnegie Mellon University Software Engineering Institute, is defined as a "description of the stages through which software organizations evolve as they define, implement, measure, control, and improve their software processes. This model provides a guide for selecting process improvement strategies by facilitating the determination of current process capabiliites and the identification of the issues most critical to software quality and process improvement." CMM guidelines advocate and support configuration management fairly early as part of implementation of the model. As a result, organizations focused on following and implementing CMM guidance frequently are put in positions of supporting configuration management efforts better than before the effort. The reason for this is that without proper configuration management, CMM 'levels' of success cannot be achieved.

So in essence, both CMM efforts and CM efforts are mutually beneficial to each other.

-- SmKershaw^? - 27 Apr 2003

7.4 CM's CONTRIBUTIONS TO FUTURE PROJECTS

One of the benefits of a well defined and practiced CM effort, is the project's historical records or history library. One of the things practiced as part of Project Management is an evaluation at the conclusion of a project. One of the goals of this evaluation is to create a lessons learned document that can be used for future projects. Also, all the processes developed, if not made project specific, can easily port over to other projects. This reuse of CM processes and procedures has the added benefit of reducing new project start-up training and definition costs.

It takes a special organization to have the foresight to plan and require the reuse of processes and procedures which work. More often than not, projects are in the position of having to reinvent those items. As CM Professionals, we must act and do our part to bring all the experience into play for new projects.

-- SmKershaw^? - 20 Feb 2003

(split and edited) -- CarildaAThomas^? - 18 Feb 2003