37 Introduction to SQA, Preproject, Project Life Cycle Components (till Review)- Summary I

The Uniqueness of the Software Development Process, the fundamental differences between software products and other products are caused by:

The higher product complexity.
The invisibility of software.

The nature of the product development and production process.

The environmental characteristics of SQA involves contract conditions and commitments defining the contents and timetable. The conditions of the customer–supplier relationship, realized by the need for consultation with the customer and the acquisition of his approval. Need for cooperation and coordination with other software and hardware. Need for interfaces with other software systems. Need to continue carrying out a project when team members change. Need to conduct maintenance of the software system for several years.

In software quality assurance, Software, is the combination of computer programs, procedures, documentation, and data necessary for operating the software system. Software quality, is the degree of conformance to specific functional requirements, specified software quality standards, and Good Software Engineering Practices. Software quality assurance, is the systematic, planned set of actions to provide adequate confidence that a software development process conforms to established functional technical requirements as well as the managerial requirements of keeping to schedules and operating within the budget. Assuring, with acceptable levels of confidence, conformance to functional technical requirements. Assuring, with acceptable levels of confidence, conformance to managerial requirements of scheduling and budgets. Initiating and managing activities for the improvement and greater efficiency of software development and SQA activities. The issues related to the various attributes of software and its use and maintenance, can be classified into content groups called Quality Factors. McCall’s factor model classifies all software requirements into 11 software quality factors. The 11 factors are grouped into three categories –

Product operation factors: Correctness, Reliability, Efficiency, Integrity, Usability.
Product revision factors: Maintainability, Flexibility, Testability.
Product transition factors: Portability, Reusability, Interoperability.

Two factor models, appearing during the late 1980s, considered to be alternatives to the McCall classic factor model.

The Evans and Marciniak factor model
The Deutsch and Willis factor model

SQA components, are employed to challenge the multitude of sources of software errors and to achieve an acceptable level of software quality. The components are:

Pre-project quality components
Project life cycle quality components
Infrastructure error preventive and improvement
components Software quality management components
Standardization, certification and SQA assessment
components Organizing for SQA – the human components

Contract review activities must include a detailed examination of the project proposal draft and the contract drafts. Contract review activities include:

Clarification of the customer’s requirements.
Review of the project’s schedule and resource requirement estimates.
Evaluation of the professional staff’s capacity to carry out the proposed project.
Evaluation of the customer’s capacity to fulfill his obligations.
Evaluation of development risks.

Once a software development contract has been signed or a commitment is made to undertake an internal project for the benefit of another department of the organization, a plan is prepared of the project (“development plan”) and its integrated quality assurance activities (“quality plan”). Eleven types of elements constitute a development plan:

Project products
Project interfaces

Project methodology and development tools

Software development standards and procedures
Mapping of the development process

Project milestones

Project staff organization

Required development
facilities Development risks
Control methodology
Project cost estimates.

Quality assurance activities happens in conjunction with the completion or examination of activity milestones, which require review of the product development activities previously completed. SQA professionals should be acquainted with the various software engineering so that they can prepare a quality plan that is properly integrated into the project plan. The four models of the software development are discussed.

The Software Development Life Cycle (SDLC)
model The prototyping model
The spiral model
The object-oriented model.

The SDLC Model is the classic model. It provides the most comprehensive description of the process available. It displays the major building blocks for the entire development process, described as a linear sequence. The SDLC Model can serve as a framework within which the other models are presented. The Prototyping Model is based on replacement of one or more SDLC model phases by an evolutionary process, where software prototypes are used for communication between the developer and the users and customers. The Spiral Model provides a methodology for ensuring effective performance at each of the SDLC model phases. It involves an iterative process that integrates customer comments and change requirements, risk analysis and resolution, and software system planning and engineering activities. The Object-Oriented Model incorporates large-scale reuse of software by integrating reusable modules into new software systems. In cases where no reusable software modules are available, the developer may perform a prototyping or SDLC process to complete the newly developed software system.

Factors Affecting SQA activities includes:

Project factors:

Magnitude of the project

Technical complexity and difficulty

Extent of reusable software components

Severity of failure outcomes if the project fails

Team factors:

Professional qualification of the team members

Team acquaintance with the project and its experience in the area

Availability of staff members who can professionally support the team Familiarity with the team members.

Quality assurance activities examine three different aspects of quality by means of software product verification, validation and qualification. Verification examines the consistency of current development activities with the products from previous phases. Validation represents the customer’s interests by examining the extent to which the customer’s original requirements have been fulfilled. Qualification reviews project application of professional standards and coding procedures, based on the assumption that applying these standards facilitates maintenance.

A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Reviews acquire special importance in the SQA process because they provide early detection and prevent the passing of design and analysis errors “downstream”, to stages where error detection and correction are much more intricate, cumbersome, and therefore costly.

The various types of review objectives are:

The Direct Objectives:

To detect analysis and design errors.
To identify new risks expected to affect the completion of the project. To identify deviations from templates and style procedures.
To approve the design product, allowing the team to continue to the next development phase.

The Indirect Objectives:

To serve as an informal meeting place for the exchange of knowledge about development tools, techniques etc.
To promote and support the improvement of development methods by supplying new data for analysis of design errors.

Formal design reviews, variously called “design reviews”, “DRs” and “formal technical reviews (FTR)”, differ from all other review instruments by being the only reviews that are necessary for approval of the design product. Without this approval, the development team cannot continue to the next phase of the software development project. The review leader should have: Knowledge and experience in development of projects of the type reviewed. Seniority at a level similar to if not higher than that of the project leader. The review team: The entire review team should be selected from among the senior members of the project team together with appropriate senior professionals assigned to other projects and departments, customer–user representatives, and in some cases, software development consultants. Team members are expected to review the design document and list their comments prior to the review session. In cases where the documents are sizable, the review leader may ease the load by assigning to each team member.

In follow-up process the person who follows up the corrections is required to determine whether each action item has been satisfactorily accomplished as a condition for allowing the project to continue to the next phase. Follow-up should be fully documented to enable clarification of the corrections in the future. Formal design reviews are authorized to approve the design documents so that work on the next stage of the project can begin. This authority is not granted to the peer reviews, whose main objectives are detecting errors and deviations from standards. Two peer review methods are defined as Inspections and Walkthroughs. Expert opinions, prepared by outside experts, support quality evaluation by introducing additional capabilities to the internal review staff. The organization’s internal quality assurance activities are thereby reinforced. Outside experts transmit their expertise by either:

Preparing an expert’s judgement about a document or a code section.
Participating as a member of an internal design review, inspection or walkthrough team.