Frequent Shopper Program, Part III
Quality Assurance Process and Procedures
While developing and implementing the Kudler Fine Foods Frequent Shopper Program, Smith Systems Consulting proposes to adhere to a well planned, comprehensive, and lifecycle-encompassing quality assurance process to assure the minimal standards of quality, as defined by Kudler Fine Foods within the functionality and performance requirements are met. This process goes well beyond debugging the software itself. Rather, the quality assurance process will begin on day one of the project lifecycle and will be completed the day the software is retired. That said, though, the goal and guiding principle of the quality assurance process is to guarantee that the developing system not deviate from the user requirements, but that it meet their needs exactly as specified. Deviations would be detected and resolved early on in the software development lifecycle (SDLC) and errors would be detected and fixed as early on in the SDLC as possible to avoid the far greater monetary and time costs incurred by errors that are discovered and fixed later on in the SDLC. Early error detection would even preclude having most errors find their way into the code at all. Quality assurance procedures, therefore, focus on detecting deviations and inconsistencies discovered in user requirements or in the way they are being developed. Early on, quality assurance activities would typically be centered on making correct design decisions and on meeting user requirements so that, in the later stages or iterations of development, the software will be easily implemented. Later on, during implementation, quality assurance activities consist mostly of testing. In the case of the development of the Frequent Shopper Program, development stages usually overlap, meaning that quality assurance procedures normally conducted at various phases in a traditional SDLC would likewise overlap. However, regardless of when various quality assurance activities are carried out, what needs to be done is to formally plan quality assurance procedures and to firmly stick to the plan. Provisions should be made to ensure that no excuse is made to short-change or skip the quality assurance process. Management, for example, needs to be brought onboard for quality assurance to happen. Also, the standards need to be easily understandable and measurable. Principally, quality assurance procedures would include the following four activities: 1.Defect Tracking
3.Testing (described in following section)
Defect tracking involves recording and tracking defects from detection to resolution (McConnell, 1998, p. 129). In technical reviews, whether formal or informal, developers receive constructive feedback from other developers. During analysis and design and even during implementation, walkthroughs help ensure the design model or the program being implemented is complete and accurate, and therefore, of higher quality. Inspections are similar to walkthroughs though more formal. The design model or code is reviewed by participants prior to the inspection group meeting. The inspection meeting comes up with agreed-upon solutions for all discussed errors. Testing, as discussed next, forms a large part, though not necessarily the most important part, of the quality assurance process. While reviews help guarantee upstream quality, system testing helps guarantee software quality downstream. System testing, which aims to cover 100% of system functionality, is usually conducted by an independent testing team (McConnell, 1998, p. 134). Defects detected are then corrected by developers. Taken alone, each of these quality assurance activities are effective, but nowhere nearly as effective as when done in conjunction with the other activities (McConnell, 1998, p. 135). The more effective testing and other quality...