Software quality assurance processes and methodologies

Software Quality Assurance (SQA) is defined as:

"A systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within budgetary confines." (Galin, cited in Food for Thought, 2005)

During the 1970's, companies had difficulty delivering software within the constraints of schedule, budget, and quality (Food for Thought, 2005). The problem grew worse over time. Many projects undertaken in the 1980's and 90's were complete disasters, failing to deliver anything, grossly exceeding budget and schedule deadlines, and delivering poor quality. Also, during the 1980's a "software crisis" occurred in which the spending on software maintenance exceeded spending on creating new software products. The problems in software development and the "software crisis" brought about the emergence of SQA.

The SQA plan sets forth the process, methods, standards, and procedures that will be used to perform the SQA function for a project (Software quality assurance plan, 1997). Contents typically define the SQA roles and responsibilities of the members of the project team and their function at stage exit as well as required skills. Further, the plan will detail standards and audits and review processes (in-stage audits and reviews, stage exist reviews and peer reviews) to be used by the project. In-stage audits assure that the established system development and project management processes and procedures are being followed effectively, and exposures and risks to the project plan are identified and addressed. Stage of development will usually have at least one formal checkpoint called a stage exit. When a stage has been successfully exited, it indicates that all draft deliverables due to date have been completed, all outstanding issues have acceptable action plans, and there is a sound plan for the remainder of the project. The project's designated sign-off authorities must provide a written position of concur/non-concur at stage exit. The peer review represents a structured walkthrough on each lifecycle deliverable.

The SQA plan will also ensure the verification and validation of requirements and specify milestones (Software quality assurance plan, 1997). Verification is the process of determining whether or not the products of a given state of the software development cycle fulfill the requirements established during the previous stage. Validation, on the other hand, is the he process of evaluating software at the end of the software development process to ensure compliance with software requirements. Finally, SQA milestones provide a list of project activities and work products that the QA consultant will review and audit.

The purpose of SQA is (Food for Thought, 2005):