TEAM Zarate Tarrani Notes From the Field

Knowledge Exchange, Knowledge Gained and Miscellaneous Gems.I've had an ongoing participation in a forum about my essay on the real war (see my entries from 21 February on). The essay has triggered comments and yielded insights from a number of people, and the resulting knowledge exchange, some in the form of debate, has proven valuable.

Exchange. Comments in the forum revealed the usual split between the process and anti-process camps, with both sides making compelling arguments to support their views. Most of the participants were articulate and persuasive, and I wish I had more time to spend on the forum, but I regretfully need to scale back my participation. Other commitments have a higher priority.

Knowledge Gained Among the points made during the discussion the following influenced me the most:

The notion that processes may be too heavy for many organizations, particularly the CMM. Indeed, they can be if improperly developed and implemented. I am not sure that most people understand the CMM, which accounts for the disconnect. However, understanding the CMM doesn't necessarily confer the wisdom to tailor it correctly to meet organizational goals.

The CMM is a maturity model. It was developed after extensive studies of successful organizations were performed with the goal of finding out what made them successful. During the course of the studies relationships between organizational maturity and process areas began to emerge. This led to a correlation between key process areas and an ability to predict how effective an organization would be using those processes to produce quality software in a cost-efficient manner. As the model was refined five organizational types emerged:

1. Initial (ad hoc or chaotic)
2. Repeatable
3. Defined
4. Managed
5. Optimizing

Each level has a set of minimum processes that must be employed. The increase in capability maturity is a function of the number of defined processes that are used by an organization. The CMM does not, however, define any of the key processes in specific terms. Each has certain characteristics, but the details are left to the organization itself.

When an organization has been assessed to be at a particular level of capability maturity it means that all of the processes prescribed for that level have been effectively implemented, that there is evidence of commitment to perform in accordance with the processes, as well as evidence that the processes are employed in the routine operations of the organization.

It's the job of the assessor(s) to assure that the forgoing conditions are met. Therefore, while they pass judgement on whether or not required processes are in place and are effectively employed, they do not judge the efficiency of the processes. It's not inconceivable for a CMM Level 3 or above organization to use processes that are inefficiently implemented and actually hamper the organization in some way(s).

I have two documents that discuss how to implement the CMM for small organizations and projects:

1. Capability Maturity Model for Extra Small Organizations by Terttu Orci (PDF format, 48 pages).
2. Using the Software CMM in Small Projects and Small Organizations by Mark C. Paulk (PowerPoint presentation in PDF format, 33 slides). More wisdom from Mr. Paulk comes in the form of another presentation titled Using the Software CMM with Good Judgement. Key points are common sense, small projects and agile methodologies.

However, the CMM isn't the only approach. In future entries I'll discuss SPICE (Software Process Improvement Capability dEtermination) and Bootstrap. If you want more information on these before I get around to discussing them the best source is Tantra's Informational Hotlist, which is updated quarterly.

Gain. I've been focusing on project management, security, best practices and process improvement in recent Postcards from the Revolution entries. There is some overlap and crossover between this weblog and Postcards from the Revolution. My latest topics were best practices, which fit within the real war thesis in that I feel that there is a dearth of them practiced.

One way to develop and document practices that work is to use patterns (discussed in numerous entries here and in Postcards from the Revolution). A book titled Framework Process Patterns: Lessons Learned Developing Application Frameworks is scheduled to released on 15 April, and from the table of contents I think this is going to be a valuable addition to the methods and frameworks body of knowledge. Until the book is available you may find Pattern Oriented Approach to Software Process Evolution to be an interesting prelude because it parallels some of the material in the book. This document is in PDF format and is a succinct five pages. Another document, in MS Word format and written by Suvajit Gupta is titled Software Development Patterns.

Gems. One of the gems on the web is Jack Harich's home page. Mr. Harich's collection of topics and papers is nothing short of amazing. Some examples include: Simple Unified Process, which is a sensible approach to implementing a scaled down version of the Rational Unified Process, and Optimizing Project Management, which is a collection of best practices and sage advice. Mr. Harich is also published in a number of magazines, and one of his articles in JavaWorld, The myth of code-centricity, shows that he's given software engineering processes and real-world applications of the processes a lot of thought.

Defining the Software Process is an online presentation that covers the basic processes that mature software engineering organizations employ. I also have a Zip archive containing four PowerPoint presentations on software project management that will complement my recent entries in Postcards from the Revolution and in earlier entries here.

End Notes. Reports of my death have been greatly exaggerated. If you've sent me e-mail during the past week and haven't received a response it's because I've been inundated. Tomorrow is e-mail catch up day. Please accept my apologies and bear with me.

I have one final document that I want to offer: Intrinsic Information Security, subtitled, Embedding security issues in the design process of Telematic Systems. This 352-page PDF document is valuable for a number of reasons, the foremost of which is the importance of basing an architecture on security goals. It also exposes best practices in architecture, software engineering and assurance.