How to Achieve ZERO Defect Software

To write programs that are complex and at the same time without logical
faults or defects is a feat, or rather an Utopian dream. In a day and age when
computers are everywhere, one cannot help but be a little anxious at moments:
isn’t there a risk that the people who deal with my credit card will fleece me
without my noticing it? Are all the electronic circuits of the plane I am about
to board entirely compatible with one another? In general, the software at work
has to be validated and tested beforehand, all the more so if its malfunctioning
can have grave consequences. Furthermore, how can we be sure that everything was
verified? Undoubtedly, testing and validation does cost money, but isn’t it an
expense worth taking to ensure that ‘It is tested’!

Getting it Zero Defect

In-process Control–It examines the project during a specific phase of the
life cycle. In-process approach is usually limited to a segment of a project,
with the goal of identifying defects as work progresses, unlike the traditional
approach where defects are identified and managed at the close of a phase or
even later, resulting in huge costs and sometimes even losses.

Requirement Phase–The client starts discussion requesting for
assistance from the project team in developing of an application. A project
representative contacts the client, views the requirements and the first vision
of the application takes shape. Following the request, the project advances to
the Proposal phase where a common vision of the project is built among the key
stakeholders. This vision should include a mutual understanding of the business
needs being addressed and a firm estimation of the project constraints.

Client Acceptance–It consists of the client’s formal acceptance of
the Statement of Work and marks the shifting of focus from describing and
understanding towards building the application.

Project Management–It should respond to the customer needs or
problems. It should drive the team to a shared vision on how to meet the need or
solve the problem. All the team members need to know, "Why are we doing
this?". Project team should own the development process. Move the project
through the development phases and ensures that the right product is developed
at the right time.

Review–Peer reviews are conducted to utilize the variety of
perspectives and talents brought together in a team. The main goal is to
identify defects within the stage or phase of the project where they originate,
rather than in later stages. Whenever a few hundred lines of new code are added
to the project, set aside an hour or two to walkthrough the code to idenfity
erroneous lines of code. Document these findings and run down the list whenever
reviewing new code. Review of the code by peers would facilitate in tracing
errors that may have been overlooked.

Testing–It should articulate well what is wrong and what is right
with a product. It must know and address the issues before releasing the
product. An issue could be a fault in the development team’s code (known as a
defect), a deviation from the Program Management team’s specification, or a
defect in the requirement. The test team must develop test strategies, plans,
schedules and scripts in early phase of the development. It must ensure
high-level of user-friendly performance of the product. It should participate in
the design process to ensure that the product is useful and usable. And also
participate in the design phase to ensure that the product is deployable.

Design Phase–It is in this phase that the application’s
architecture is defined. The application architecture is based on the
Conceptual, Logical and Physical Design Models. In addition, the three variables
with which the team must work: schedule, resources, and application features are
more accurately defined during this phase.

Development Phase–It is based on the understanding of the
deliverables of the preceding phases. Here the production team performs the
project execution, which leads to the application coding being completed and the
application being released.

Stabilization Phase–It starts when the team shifts its focus from
code development to stabilizing the product and ends when the customer accepts
the product as complete. A significant aspect of this phase is that the customer
and users begin to pilot-test the product. This phase is also the training
ground for the organization’s operations and support teams. Stabilizing runs
in parallel with testing, and executables and documents are continuously
exchanged between the teams involved in the two phases.

Deployment Shipment Phase–It concludes the project development
process. At the end of this phase all project deliverables are with the client.
This phase is completed when the customer signs off the document.

Challenges

"Zero Defect" demands a lot of personal
commitment from each and every individual in the organisation. Many other
factors also play a vital role in attaining a defect free application, such as
Configuration, OS, Environment Simulations. It is very important to understand
the environment and vendor tools from the client’s perspective.

The management and the representatives from the technical
pool who will assist in making a feasibility study, evaluate the customer’s
wish list. The nature of activities will involve project staffing and project
schedule determination. Identification of the right resource and the training
that will have to be imparted is evaluated.

Some of the important points to be emphasized in the
requirement document, are–WHAT the system will do rather than HOW it is to be
done. What is more important to be recognized and documented is what the system
will NOT do. Oftentimes, a failure to recognize these implicit requirements will
require rework during the design phase causing an increase in the cycle time of
the system development.

As stated earlier, the goal of a quality culture is Zero
Defect. It is not to say that everyone actually expects to achieve perfection,
but having it as a goal makes each achievement a starting point for the next
level of improvement.

T M Natarajan senior vice-president, Polaris Software Lab

What is Zero Defect?

At the heart of quality is a commitment to continuous improvement, the basis
of which is the belief that within any situation or activity, there is always
room to improve. However, here the goal is perfection or "Zero
Defects," nothing less. This goal applies to every piece in the puzzle:
people, processes and products. All must work together to provide the foundation
for zero-defect.

Defect Free Code is a software code that passes without iteration at Unit
level, Module level, Integration level, System level, Deployment level and User
level.

Defect Free software is desirable...

To reduce cost: 80% of the money spent on coding phase is attributed
to defect removal which arises due to adaptation of code-and-fix model

To improve productivity: majority of the coding defects attribute to
poor or missing requirements

To accelerate time to market: the return opportunities double for
every 50% decrease in time to market

5 Steps to Zero Defect

Induction/Rewards/Selection Define the
characteristics of a successful induction scheme. Most induction programs
provide requisite information about different teams and related coordination.
However, the programs should be extensive, with topics based on business needs
of the organization and the like. Business needs focus on the mission and vision
statement of the organisation. Induction should be motivational; motivation
should be the core element of the programe.

Stringent Control Set objectives at the
beginning of every project and set reasonable goals to achieve them. Then,
prioritize those objectives. Whenever you have to make a decision, keep your
objectives in mind. If you do not set clear goals, you are doomed to accept the
results of random chance.

Automation Process There are errors which
show up only after the occurrence of a very definite sequence of "n"
number of operations. It is just not practical to trace them in one/two
operations. Using automation tools such as Code Generator, Report Writer,
Application Builder and Regression and Load testing tools are beneficial.

Horizontal & Vertical Forums Convenes
events for the specific purpose of sharing best practices and strategies, as
well as to explore new technologies.

Evolution Processes From Inception to
Implementation test each phase of your software development for various
parameters defined. Ensure you maintain the version controls. Perform basic
functionality test. Document all your findings and ensure that you eliminate all
identified errors before you proceed with the next phase of development. This is
more a discipline than direction.

Each of these steps represents a simple concept, but their combined benefits
are significant.

Some Serious Software Defects

1985-87 Radiation machine kills four: Faulty software in a Therac-25
radiation-treatment machine made by Atomic Energy of Canada Limited (AECL)
resulted in several cancer patients receiving lethal overdoses of radiation.
Four patients died. A later investigation by independent scientists Nancy
Leveson and Clark Turner found that accidents occurred even after AECL thought
it had fixed particular defects. "A lesson to be learned from the Therac-25
story is that focusing on particular software defects is not the way to make a
safe system, they wrote in their report." The basic mistakes here involved
poor software-engineering practices and building a machine that relies on the
software for safe operation.

1991 Patriot missile misses: The US Patriot missile’s battery
successfully headed off many Iraqi Scuds during the Gulf War. But the system
also failed to track several incoming Scud missiles, including one that killed
28 US soldiers in a barracks in Dhahran, Saudi Arabia. The problem stemmed from
a software error that put the tracking system off by 0.34 of a second.

The system was originally supposed to be operated for only 14 hours at a
time. In the Dhahran attack, the missile battery had been on for 100 hours. This
meant that the errors in the system’s clock accumulated to the point that the
tracking system no longer functioned. The military had in fact already found the
problem but hadn’t sent the fix in time to prevent the barracks explosion.

1996 to 1997 Java opens security holes; browsers simply crash: Java’s
problems surfaced in 1996, when research at the University of Washington and
Princeton began to uncover a series of security holes in Java that could,
theoretically, allow hackers to download personal information from someone’s
home PC. To date, no one has reported a real case of a hacker exploiting the
flaw, but knowing that the possibility existed prompted several companies to
instruct employees to disable Java in their browsers.