IT Directions« Bomb-proof your software development | Main | Dealing with change during software development »
May 07, 2007Quality is a moving target This is the seventh in a blog series on the Future of Programming. Last time I discussed the high-level document outputs required from a software development project (of any kind) - including the often-neglected but vital Quality Plan. In this post I will say more about Quality Planning.
Here is a typical description of a Quality Plan, selected at random from the Web:
Quality Plan Description
The Quality Plan describes how a developer's overall quality process guidelines will be applied to a project. It defines what is meant by the various quality-related tasks in the Project Plan.
For example, a developer's quality manual may describe a review process for ensuring that delivered software meets requirements. The Quality Plan for the project tailors this general definition to the project at hand, specifying items such as who generates the requirements, what form these will take, who reviews them, etc. Thus, when a task in the Project Plan reads "Review and update requirements," the Quality Plan defines what will be done, and who will be responsible.
Quality Plan Contents
The Quality Plan outlines how you will build quality into the software and documentation. The dates assigned to key tasks in the Quality Plan are entered into the project plan.
The Quality Plan describes:
- How you control changes.
- How you ensure that the product meets the requirements (validation).
- How you ensure that the product works properly (verification).
- How you track multiple development builds of the software to avoid confusion (configuration management).
- How you plan for and execute testing, both incrementally during development and for the entire product before delivery.
- How you track and resolve defects.
- How and when you conduct design reviews, code reviews, walk throughs, reviews of test scripts, reviews of test results (for example, is 100% of all code checked, or only the most complex parts?).
- Definitions, methods, and criteria you use to determine whether the software has passed each review.
At first glance, this seems OK. However, it is in fact rather a limited approach to quality planning. The problem with such a definition is that one could get away with almost anything (or nothing) in the Quality Plan document, since the only expectation is to have some form of test and review during the life of the project. Quality in its classical definition means "fitness for purpose". So the real question that should be asked of a Quality Plan is this: how does it ensure that the software delivered is fit for its purpose?
A more thoughtful approach to quality planning is that of the PRINCE 2 method developed by UK government, and now an internationally recognized approach. Here is a typical PRINCE 2 approach to quality planning:
Purpose
The purpose of the Project Quality Plan is to define how the supplier intends to deliver products that meet the customer's quality expectations and the supplier's quality standards:
- Does the plan clearly define ways in which the customer's quality expectations will be met?
- Are the defined ways sufficient to achieve the required quality?
- Are responsibilities for quality defined up to a level that is independent of the project and project manager?
- Does the plan conform to the corporate quality policy?
Composition
The Project Quality Plan should contain:
- Customer quality expectations
- Acceptance criteria, a prioritised list of criteria for the final product(s) that must be met before the customer will accept the final product(s).
- Quality responsibilities, who is responsible for each of the aspect of quality of the final product(s)
- Reference to any standards that need to be met
- The quality-control and audit processes to be applied to project management
- Quality-control and audit process requirements for specialist work
- Change management procedures
- Configuration management plan
- Any tools to be used to ensure quality.
Derivation
- Customers quality expectations and requirements
- Organisational or programme quality management system and standards
- Configuration management and change control requirements
Such a description will produce a more useful (if longer) document. However, there is still a fundamental problem with it. The problem lies in the innocuous phrase "Change management procedures". Typically such procedures comprise some combination of:
- Techniques for issue tracking
- Guidelines for approval of proposed changes.
This gives absolutely no indication of the complexity inherent in managing the sort of changes typically encountered during the life of even a moderately complex software project. This is because most enterprise software projects rely on concurrent design.
Demands for increased productivity and shorter times-to-market generally force software engineering organizations to adopt concurrent design. Different parts of a complex application are developed in parallel and then integrated, shortening project schedules. Typical interactions in this type of business process are activities such as agreeing on sub-contract terms, signing off a specification, concluding a project stage, and so on. Each of these may involve several parties, contain processing spread over varied systems on different platforms owned by different organizations, and require a number of steps to complete successfully. Further, although efficiency gains can be achieved via this approach, it carries risks of rework, which arises when concurrently performed work turns out to be incompatible, and an impact of one interaction is that others need to be repeated.
In other words, concurrent design is what Human Interaction Management defines as a typical human-driven process - fraught with instability, since software engineering managers are dealing with activities that are only partly predictable when the process commences. It is a fundamental characteristic of the whole environment that it is organic and dynamic, so hard coded process descriptions are unsuitable. Even if they are supported by tools that make modification of that process possible, the participants are innovative, creative people who need the flexibility to put their skills and experience to use in what seems like the most appropriate way at the time.
There is a parallel situation in the structure of the product itself. A complex software application may appear to decompose neatly into components (and services) but in fact it is a densely tangled set of solutions to a huge and varied set of requirements and constraints. Later modifications only increase the complexity. New connections and dependencies are introduced by tracing the impact of modifications, defining and implementing consequent changes, testing the whole package and restoring the integrity of the product.
TAKE AWAY
Software product managers attempting to deal with applications built using concurrent design generally find themselves tearing their hair out by the time the project is halfway through. If they are lucky they will be running to stand still. If not, they will find the project slipping further and further every week. Failure to properly handle concurrent design is probably the single biggest cause of software project failure.
The solution to managing concurrent design lies in giving the ever-changing nature of a human-driven process the respect it deserves. In such work, a major part of the workers' duties is to decide on next steps. This must be done both continually and collaboratively, since there are always new issues to resolve and few of them can be dealt with in isolation.
In the next instalment of this series, I will look at techniques for structuring this "continual decision on next steps". If you want to make your change management as elegant and efficient as your software code, stay tuned.
Posted by keithhb in
Management
• Service-Orientated Architecture
|
Digg This|
Add to del.icio.us
