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

Page(s)   1  2  3  4