Software Certification CSQA Release Date

The primary concern of the user during acceptance testing is that the deliverables meet the user requirements. The specific concerns during this phase are:

Meets specifications

All of the deliverables provided by the contractor meet the user requirements as specified in the contract.

On time

The delivered products will be in the hands of the user on the date specified on the contract.

Adequate test data

The customer should prepare sufficient test data so that the deliverables can be adequately tested. For application systems, this may be test transactions to verify the processing performed by the application. The acceptance test criteria for training courses and manuals may be review and examination. For example, the contractor may be asked to put on a training class in order to determine the adequacy of the material.

Preparation for operation

Any supporting activities should be completed in time for acceptance testing. This may involve the ordering of forms, making changes to existing operating systems, and other application systems, developing procedures to use the application, etc. The customer should have identified these needs during the feasibility phase, and worked on meeting those requirements while the contractor was preparing the application system.

User training

The users of the application should be trained prior to the acceptance test phase. This training may be provided by the organization itself, or it may be done by the contractor.

When can it begin

Acceptance testing should occur on the date which was specified in the contract.

Conversion to production

The procedures and steps necessary to put the application into production should be tested during the acceptance testing phase. These are normally customer obligations to prepare files, schedule production, etc. These procedures should be tested just as vigorously as the contractor’s application system.

Static testing is another name for in-process reviewing. It means that the test is being performed without executing the code. Static testing occurs throughout the development life cycle; however, a large part of it takes place during the requirements and design phases in the form of walkthrough inspections, and system reviews. Other examples of static testing include code analyzers or writing analyzers.

Dynamic testing (also known as program testing) implies that the code is being executed on a machine.

Subjective baseline studies will be the most commonly conducted studies in measuring quality and productivity. Subjective means that judgment is applied in making the measure. We noted in the discussion on objective measures that when the individual involved in recording time has the option of applying judgment, then the measure becomes subjective.

Baselines should be quantitative even if it is a subjective measure, but quantitatively subjective. For example, because quality conformance and nonconformance must be defined by people, we are looking for ways to put this information into a quantifiable format. This does not convey a lot of information, but it is indicative of a problem. However, if we develop a five-point scale for unresponsiveness, and ask your dissatisfied customer to complete that scale, we now have conveyed a lot more information. If our scale rates “1” as very poor service, and “5” as very good service, there is a great deal of difference between a “1” rating and a “3” rating for dissatisfaction.

Examples of products/services that can be measured subjectively for developing a baseline include:

Customer satisfaction

Effectiveness of standards/manuals

Helpfulness of methodologies to solve problems

Areas/activities causing the greatest impediments to quality/productivity

Causes for missed schedules/over-budget conditions

Understandability of training materials

Value of tools

Importance of activities/standards/methods/tools to individual activity

Baselines can be conducted for any one of the following three purposes:

Planning: To determine where detailed investigation/survey should be undertaken.

Internal analysis: To identify problems/areas for quality improvement. Once the problem/area has been identified, then no additional effort need be undertaken to formalize the results.

Benchmarking: Comparison against external organizations.

The starting point in new product development is the decision of what to build for whom. This requires determining customers, finding out what they want, and identifying whatcapabilities can be provided to them. In QFD, the fundamental deployments of customers and quality address this.

Customer Deployment involves determining which types of customers for which the organization is trying to provide a product or service. It precedes the determination of requirements in quality deployment. Customers must be identified first in order to know to which voices to listen. The customer deployment component of QFD is particularly important for software, as a single software product must often satisfy many types of customers.

Quality Deployment has tools and techniques for the exploration and specification of high-value customer requirements (or "demanded quality"). Once captured, the customer requirements are translated and deployed into technical requirements (or “quality characteristics”) in the House of Quality matrix. (The House of Quality is the first matrix that a product development team uses to initiate a Quality Function Deployment (QFD) process.) This can be done at various levels of sophistication, ranging from four matrices to a dozen.

These fundamental deployments are the foundation for downstream design-and-development decisions about “how” the product will work (the horizontal deployments) and 'how well' it will be designed and developed (the vertical deployments). Both horizontal and vertical deployments are required to appropriately handle this complexity.