Welcome to the Points-To-Ponder e-letter

Welcome to the S5 Systems thought provoking monthly e-letter; in these periodicals, we bring you a discussion of the issues and ideas that affect project managers, software managers and project leaders.

PRACTICAL TIPS TO SOFTWARE QUALITY – PART I - DO WE NEED A QUALITY PROCESS?

This is the first in a series of e-letters on software quality and the quality process required to create quality software.
 
Although a lot of papers and abundant information is available on the Internet, we find the information is scattered or information available is cryptic. This is our attempt to identify benefits of quality process and create an example quality process with which most companies and project managers would identify with.

This article, first in a series of articles explores a need for a quality process. It discusses the state of software development process, general myths related to software quality process and potential benefits of quality process.

State of the Software development processes

The statistics related to software development are sobering [1]: Something like 25% of large software projects are outright failures and Another 50% do not implement the promised functionality The average software development overshoots it schedule by half

Statistics related to software development projects are sobering

	Quality Problems - Too much rework causing the quality of the completed product to suffer
	Minimum or poor management visibility
	Consistent delays in delivery

General Myths associated with need for quality process

Quality process is widely seen as detrimental to delivery of the products.

Many managers believe they do not need a quality process Many managers believe that the quality process: Would cause unnecessary overhead and is only useful for large projects   Is not required for smaller projects or for building prototypes   Hinders agility, interferes with creativity and slows progress

Potential benefits/importance of a quality process

What do we want the quality process to achieve? We can identify key goals related to what the quality process should achieve:

Quality – Product quality is the key benefit of the quality process and identifying and measuring quality is dealt in the next section.

Predictability – Process must enable project manager to predict accurately how long it would take to develop the product. That means estimating accurately how long each part of the project takes and how delays in each part of the project affect the other parts.

Repeatability – Since creation and implementation of a process is tiresome work and once a good process is achieved, it must be repeatable to produce consistent results project after project. Repeatability allows gaining experience and continuous improvement based on gained experiences.

Effectiveness – An effective process must help create the right product. The process must help determine what the customer needs, document what the customer needs and importantly verify that what is produced is what the customer needs.

Maintainability – Process must enable the software to be maintained as software passes through initial architect, design, implementation and maintenance phases through  several developers over the lifecycle of the product.

Continuous Improvement – No process is expected to be perfect and as projects are performed learning based on a quality process from previous projects must be used to enhance the quality process.

Tracking – A process must allow the management, developers and customers to follow the status of a project. Tracking in complementary to predictability, tracking helps keep track of how good the project predictions are.

Quality – What does it mean?

The key goal of the quality process is to establish and maintain a link between the process and product quality of the produced product – software in this case. In order to establish such a link we must define Quality.

Quality is multi-dimensional and below is the important dimensions of quality:

1. Conformance – A measure of the extent to which the product is delivered based on the original specification.
2. Reliability – A measure of how often (in number of uses or in time) the product will fail. This is measured in terms of Mean Time Between Failures (MTBF).
3. Durability – For hardware products how long does the product last before it starts to fail, for software products durability is a measure of how long the software is manageable that it is easy and cost effective to manage and maintain. Software over a period of time tends to become too expensive and risky to add new features to.
4. Aesthetics – This although subjective is an important part of quality of a product – how appealing and easy is for the user to learn and use the product. The aesthetics although cannot be covered under product specification, there are steps in the quality process which ensure esthetically pleasing products (how to create esthetically pleasing product will be covered in a future e-letter)

Conclusion

Hence we conclude, a quality process is required to create a quality product and the effectiveness of the process is crucial for the quality of the product the process creates.

Keeping this in mind in our subsequent “points-to-ponder” news letters will touch on each stage of the quality process starting from the product specification to product integration and quality assurance.

We welcome comments

We look forward to your comments – on what you may agree or disagree with – share with us your experiences, send a short note to the Points-To-Ponder team at: ptpteam@s5systems.com.

References

1. Experience with a Software Quality Process - Richard A. Shaw and Perry Greenfield, Space Telescope Science Institute, Baltimore, BD 21218.
2. The Many Dimensions of the Software process – Sebastian Tyrrell, ACM Crossroads.