New Year Tidy Up

Happy New Year.

I've started the year with a quick tidy-up:

• Deleted two old blogs that I created a few years back but never really used
• Posted a couple of old articles that I wrote in 2006, as on a re-read they looked like they could still be of some value to someone
• Deleted 17 "daily reflections" posts that didn't really have anything of value to the readers in them
• Deleted a further 2 posts that on re-reading were very specific to the time and not particularly informative
• Re-tagged all "daily rubbish" posts as "daily misc": there's something not quite right about the perception created by having a tag dedicated to "rubbish", so I thought a new name with a more neutral feel would be a good idea

Hope everyone had a fantastic Christmas and New Year break and here's looking forward to a great 2011.

Validation vs. Verification

Another article from 2006:

These two terms keep cropping up as a source of confusion at the moment, so here's my attempt at clarifying the situation.

The traditional definition

I can kind of see why people have trouble with these two terms, when you consider how often I've heard these as definitions:

• Verification = "Making sure we build it right";
• Validation = "Making sure we built the right thing".

Yes they are different, but if you're trying to explain this to people who were confused before, I can't see this helping much.

The simple non-definition

Here's the way I remember the difference:

• Verification - think "system test";
• Validation - think "User Acceptance Test" (UAT).

Note: these are not definitions, they are examples of types of verification and validation.

In other words...

Verification covers all the checks you do along the way to make sure you're building whatever you're building right e.g. peer reviews, unit tests, load tests etc. etc.

Validation is all the stuff to make sure you're meeting the requirements. So again, this could well be unit testing if it's testing directly against a particular requirement - but it's the stuff that makes sure you're making what the end user needs, as specified by the requirements.

A non-technical example

I find that looking at these things from more than one angle helps.

You can perform verification and validation on anything that you produce. And what you produce doesn't have to be "techie"; whatever you're working on, the same principles apply.

For example, say you're writing a document.

Verification looks at formatting, spelling, and the reviews by colleagues to make sure you're doing it right.

Validation is checking that you're actually answering the questions that need to be answered, and making sure that the person(s) you're writing for are happy enough with it to sign it off.

Yet another perspective

Ok, here's another one.

Verification is all about making sure whatever you're producing is high quality: it follows the standards you should be following, it is error free etc.

Validation is all about sign-off. You want to make sure the audience is happy with what you're doing, and if it's a client you're doing it for you want them to be happy enough to sign it off as complete.

Yes, there can be overlap

Of course, one of the main causes of confusion is that sometimes these activities are performed together. How and when validation and verification are performed is down to your organisation's processes (or your project's processes, or whatever) - the key is that they both happen, and that they're made to work for you.

Relationships between CMMI Specific Process Areas and Generic Goals

This is an article I wrote back in 2006, reposted here because it still has some points that someone might find useful...

One of the most common areas of confusion when looking at the CMMI is the relationship between the "Process Areas" and the "Generic Goals and Practices".

At a glance, people seem to think that in order to increase the "maturity level" (not to be confused with capability level) of your organisation, you concentrate on the process areas and specific practices for whatever maturity level you're aiming for - and that by focussing on those areas you will achieve the ML badge you've been striving for.

• If when you read the specific process areas you apply all generic practices for them as well as the specific ones, you may well be on the right track. But do you understand why?
• If you just focus on improving the engineering side of things, I can assure you that you are completely missing the point.

And so begins my attempt to explain why, without the use of diagrams or technical jargon...

Process Areas vs. Generic Goals

1. Process Areas are basically lists of the key things you need to do to make sure you do a specific thing properly, grouped under a title that describes the specific thing you're doing;
2. Generic Goals are the key things that you should really be doing whenever you doanything.

These structured lists of things were drawn up based on "industry best practice", so you're likely to find pretty much the same kinds of things in most half-decent management and engineering or development methodologies.

Process Area Example

One thing you'll notice is that some of the points (or "Specific Practices") that make up these Process Areas are, for want of a better expression, a bit noddy. They are totally and utterly obvious. Not only that, but if you are managing a project or developing a piece of software, you are most likely doing it already.

Example: RD, Requirements Development, SP 2.1-1 Collect Stakeholder Needs.

i.e. when capturing requirements (developing an understanding of requirements), you need to first work out what people want.

If you you're not doing this already, I would guess that you are either unemployed or nearing the end of your contract (whether you like it or not).

Generic Goals example

Generic Goals are again common sense.

Example: GP 2.5 Train People.

i.e. for a project to be truly successful, make sure that the people working on your project have the skills required to perform their jobs correctly - and if they don't, provide them with training to make sure that they do.

The big difference here is that Generic Goals should be applied to all Process Areas. Even so, this is still common sense when you think about it. The person responsible for gathering the stakeholder needs when developing requirements for the Process Area example above, really needs to know how to gather requirements to be any good at actually doing that. If they don't have a clue, they will need training, or will end up doing a bad job.

But wait, there's more...

That's the basic relationship between the two - but when you look at the CMMI more carefully you'll start to see that there's a huge amount of cross-referencing to help you work out how to use it.

In other words, some of the Process Areas actually tell you the things you need to do to implement the Generic Goals for all the other Process Areas!

I'm not talking about the explicit cross-referencing you find in the model when it says "refer to the XXX process area for information about XXX", I'm talking about implicit overlaps between Process Areas and Generic Goals.

Best demonstrated with some examples

I'm not going to go through every Generic Goal and map it back to a Process Area for you. You need to think about how you apply this to your organisation e.g. the guidelines of the CMMI's PP Project Planning process area may actually be performed across multiple processes in your organisation, in a way that means that you cannot define your own "Project Planning" process as such, but must instead document how a number of your processes work and demonstrate how you are performing all of the activities described in PP Project Planning. If I just map Process Areas to Generic Goals, there is a temptation to just take the CMMI "As-Is". All I can say is, I wouldn't recommend it.

However, I know that the best way to demonstrate the implicit relationships between Process Areas and Generic Goals is with some examples, so here are my favourite two:

GP2.5 Train People
OT Organizational Training defines the key things to consider for the central management of training for the entire organisation. If you manage training centrally and ensure that all projects consider training for everything they need to do, then you're going to satisfy this Generic Goal.

GP2.6 Manage Configurations
CM Configuration Management sets out the industry best practices for managing configurations. Document the way in which your organisation performs Configuration Management, and apply it to everything you do and you'll be performing GP2.6.

The point

The final comment I'd like to make is that the use of the CMMI requires a bit of thought. Don't just focus on specific Process Areas unless you've really thought about their impact on your organisation.

The CMMI emphasises central management, consistency, understanding and accountability. All good things in my books - but not things you can achieve by just by working down the list and doing "what it says". The CMMI provides a well-structured reference model, but it's not a how-to guide.

Look at your organisation's processes, look at those specified in the CMMI. Look at how working on Process Areas in the right way can move you towards satisfying the Generic Goals.

Repackaged Common Sense = The Next Big Thing

A theme you may notice in some of my posts is that a lot of ideas around "best practice" management, consulting, development or whatever are actually quite often existing ideas repackaged in new frameworks with new buzzwords etc.

That isn't a criticism, it's an observation. In fact, quite often the new presentation and structure of these ideas represents the evolution of better ways of doing things, even if some of these changes are very subtle, or simply provide a better understanding of the ideas rather than actually changing them.

Some of my posts are likely to be the same - a new view on old ideas. No matter how good something is, it can always be improved, or better understood, or better implemented. The Next Big Thing is the Last Big Thing, only that bit further down the line.