Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Defining moments

Written by Randy Wagner

Sunday, 15 August 2004 16:00

In my experience, defining the terms “defect” and “change request” (CRs) can be small potatoes but it can really contribute to making your process understandable to the average project member. It’s an opportunity to involve lifecycle stakeholders and provide core concepts to new team members. Good change control dictates a solid process for handling Configuration Items (CIs) throughout the lifecycle. Particularly for those of us in the smaller, less mature shops, it’s where an SCM earns his or her spurs. Defining these terms, in the context of the organization and processes, can help the organization as a whole focus on many aspects of the change control system in a meaningful way.

In my organization’s march toward CMMI maturity, I wrote up a process that I believe reflects the needs and methods here and closed some of the loopholes that were preventing maturity growth. I passed the process around the various functional areas for review. Many had good enough questions that I knew they’d read the document but they still had surprisingly little pushback. When I finished, I drew a snazzy chart and realized that I’d managed to do all that without actually defining either a defect or a change request. So I went looking for various examples. What I found was fairly surprising.

When I rushed to the Software Engineering Institute’s web pages for CMMI, I discovered those terms were not in their glossary. I started cruising the web but found that few places define it. Some pages mention them. Many sell products related to them. But very few actually define them. Apparently, we all ‘know’ what defects and change requests are. CM BOK did define “defect” and “engineering request” but not “change request”, as such. A handful of sites did have good material from which to work and I collated what I could. Outside of MIL, DOD, or IEEE standards, particularly for those of us with non-existent budgets, there’s not much to work with.

So, armed with a pile of options, I set about crafting something that would make sense for the process users here. I typed out a handful of options but they all came back to a singular difference between them: documentation change. So, in keeping it simple, I chose these two definitions:

Defect: Any instance in Testing where code does not match approved requirements or design documentation.

Change Request Any event requiring a change to a documentation CI.

This collectively handles every event within the SDLC that might impact the software product development. A defect is code only while a CR is documentation and potentially code. Defects can then follow an expedited path flowing directly back to development for analysis and, possibly, correction. CRs can follow the more formal path of a Change Control Board (CCB) review. If a CR results in a code change, the other functional areas will already be expecting it based on the documentation change. In the case of a defect that causes a documentation change, the defect is closed out and a CR is written, reviewed, and processed. And finally, by defining defect within the context of formal Testing (capital T), it removed the issue of handling defects within the unit-testing phase that stays within the development area.

My first pushback to the definitions from the community came from a process advisor who is thoroughly steeped in the requirements cup of tea. He promptly suggested that a requirement document could have a defect. His example was a typographic error, certainly not worthy of a full peer review. That’s quite true but code and documentation are very different. Code is the manifestation of the documents. Changing documentation means changing a CI on which other people rely for their own work and preparedness. The flip-side is not true. If a piece of code is changed because it did not match spec, the test case, scripts, etc are not changed as they are solely dependent on the documentation CIs. Users downstream in the project set their expectations by the requirements and design, not by what comes out of development. On the other hand, simple or not, some level of CCB should approve documentation changes to ensure impact is understood. The example given by the process advisor was that the state “Indiana” should have been “Illinois”. That may not mean much in one setting but if regulatory rules are involved, that could cause significant repercussions to requirements and design.

For this reason, I integrated a gatekeeper function, someone who can disposition low impact requests and recommend mid to high-level CRs to the full CCB. It works particularly well for smaller organizations where people are forced to wear multiple hats or projects are measured in days, not years. Of course, the gatekeeper’s decisions are always subject to review by the CCB. You really couldn’t do this set of definitions without a gatekeeper and still keep the other CCB members happy. This setup provides clear, solid structure along with the flexibility that other functional areas demand in a small organization.

The second pushback flowed directly from that gatekeeper concept. If your gatekeeper also happens to be the development manager, as is often the case, it’s possible for that person to write and approve a change without further review. That’s true. And you might consider that dereliction of duty for an SCM but look at the context. No small organization that I know can afford to do a line-by-line code review for every file. So if development really wanted to sneak something in, no one would know unless Test happened to catch it. You are therefore forced to extend a certain amount of trust (shiver!) in the professionalism of the development staff, and, to be fair, rarely is that trust violated at the managerial level. The argument can be made that as an approved CI change there is a more significant risk it wouldn’t be questioned but you still have to pass through requirements and test, at a minimum, who, in a small organization, would already know if Development was trying to pull a fast one. And you are effectively promulgating all approved CRs throughout the project community, right?! Further, anyone who feels the change was inappropriately approved can raise the issue to the full CCB.

As we all know, quality is really measured in risk. You build processes that minimize the risk but the last 5% of quality can be as expensive as the first 95%. As an SCM, I’m all for very strict guidelines and delineation of control. But because I work on the bleeding edge, I know I can’t afford to be hardcore with an organization that is just climbing into the ring. Despite “obvious” benefits, you can only sell what the customer is willing or can afford to buy. Maybe we will someday be mature enough to support a different set of definitions and processes but swallowing the elephant whole now will certainly cause severe indigestion. When a child learns to walk, we don’t start them out on an escalator, we keep it simple. There’s really no reason we can’t do that in terms of process and work our way up to a marathon.

The Test Lead came running when she read the definitions but by showing how the definitions pair directly with the process we agreed to, it made solid sense for her. She felt much better able to communicate that to her growing test staff. Development was happy because it forced even basic issues through some level of assessment, and frankly gave them a sense of control since the dev lead is often the gatekeeper.

Defining “defect” (or “Problem Report” for those of you with Sensitive Developer Syndrome) and Change Request, no matter what definition you chose, works well for all organizations. As long as you define it in the context of the organization, it reduces questions and errors. In terms of the definitions we use, the binary system means that expectations are more easily managed. It also means no gray areas lay in wait to cause problems. What’s more, the act of defining change requests and defects in an SEPG or process team setting, or even in your configuration management plan, challenges a lot of basic assumptions individuals have and forces them to justify their perspective. It digs straight to the root of how things should be done and results in (hopefully) better process. I wrote here about the pluses and minuses of the system we put in place. Unless your project teams can circumvent you entirely, you are certain of getting feedback on your whole process based on the definition of just those two terms.

The terms are simple. We’ve all worked with them. But like requirements and design, the devil is in the details. Especially for small or immature organizations, this can be useful. Having defined those terms, it caused us to answer many questions and now my team is more understanding of the process and the benefits.

Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at SR_71_98@yahoo.com.

Set as favorite

Bookmark

Email this