Chapter 5 The C omponents of the S oftware Q uality Assurance ystem

1. Chapter 5The Components of the SoftwareQuality Assurance ystem

2. SQA system components can be classified into six classes: 1- Pre-project components. To assure thatthe project commitments havebeen adequately defined considering • the resources required, • the scheduleand budget, • the development and quality plans 2- Components of project life cycle activities assessment. The project lifecycle is composed of two stages: the development life cycle stage and the operation–maintenance stage. • The development life cycle stage components detect design and programmingerrors. Its components are divided into the following four sub-classes: – Reviews – Expert opinions – Software testing. • assuring the quality of project parts performed by subcontractors and other external participants during project development and maintenance. • The SQA components used during the operation–maintenance phaseinclude specialized maintenance components as well as development lifecycle components, which are applied mainly for functionality improving maintenance tasks.

3. 3- Components of infrastructure error prevention and improvement. Themain objectives of these components, which are applied throughout theentire organization, are to eliminate or at least reduce the rate of errors,based on the organization’s accumulated SQA experience 4- Components of software quality management. This class of componentsis geared toward several goals, the major ones being the control of developmentand maintenance activities and the introduction of earlymanagerial support actions that mainly prevent or minimize schedule andbudget failures and their outcomes. 5- Components of standardization, certification, and SQA system assessment.These components implement international professional and managerial standards within the organization. 6- Organizing for SQA – the human components. managers, testing personnel, the SQA unit and practitionersinterested in software quality. They • initiate and support the implementation ofSQA components, • detect deviations from SQA procedures and methodology, • suggest improvements.

4. 1-Pre-project components The SQA components belonging here are meant to improve the preparatorysteps taken prior to initiating work on the project itself. • Contract review • Development and quality plans. Contract review Software may be developed • within the framework of a contract negotiated with a customer • or in response to an internal order originating in another department. 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. • A similar approach is applied in the review of maintenance contracts for the sake of performance improvement (termed “functionality improvement maintenance”).

5. 5. Software Quality Assurance Components5.1. Pre-project Components5.1.1 Contract Review

6. A bad contract is always an undesirable event • A bad contract is usually characterized by • loosely defined requirements, and • unrealistic budgets • schedules and is expected to yield low-quality software. • Quality assuranceefforts • review of the proposal draft and, • later, the contract draft • The two reviews are aimed atimproving the budget and timetable and revealing pitfalls at an early stage.

7. Bad Contract Example: • The completion of a 10-month projectfor Carnegie Fruits and Vegetables. • The new informationsystem registers product receipts from growers, processes clients’ ordersand produce shipments to clients (greengrocers and supermarkets), billsclients, and calculates payments made to the growers. • This very successful projecthad actually lost about $90 000. • The only phase where the estimatesfailed was one of the project’s final phases, the client’s instruction, that wherethe client’s staff are instructed on how to use the new information system. • Itnow appears that no one had read the relevant RFP (requirement for proposal)section carefully enough. • This section stated that the software would be instructed in its use by the software supplier. • Nobody tried to find out how manybranches the client operates. • Nobody mentioned that CFV operates 19branches – six of them overseas before signing the contract. • They tried to renegotiate the installation and instruction budget items withthe client, but the client insisted on sticking to the original contract.

8. Reasons for Bad Contracts: • Losses stem from sloppily writtenproposals or poorly understood contracts. • Shallow and quick resourceestimates, as well as exaggerated software sales efforts, have led to unrealisticschedules and budgets, or to unrealistic professional commitments. • Unrealistic professional commitments lead tofailure to achieve the required software quality. • In most cases,schedule and budget failures are accompanied by lower than acceptable softwarequality, due to pressures exerted on team members by management “tosave time” and “to save resources”. • Such excessive pressures eventually lead to high rates of software failure. Contract review is the software quality element that reduces the probabilityof such undesirable situations.

9. The contract review process and its stages: • Several situations can lead a software companyto sign acontract with a customer. The most common are: • Participation in a tender. • Submission of a proposal according to the customer’s requirement for proposal. • Receipt of an order from a company’s customer. • Receipt of an internal request or order from another department in the organization.

10. The review process itself is conducted in two stages: • Stage One – Review of the proposal draft prior to submission to thepotential customer (“proposal draft review”). • Stage Two – Review of contract draft prior to signing (“contract draftreview”). • This stage reviews the contract draft on the basis of the proposaland the understandings (including changes) reached during the contract negotiations sessions. • After the completion of a review stage it is required that the necessarychanges, additions and corrections are introduced • by the proposal team(after the proposal draft review) and • by the legal department (after the contract draft review).

11. Contract review objectives: Proposal draft review objectives: • Customer requirements have been clarified and documented: Clarifications of vague requirements should be recorded in a separate document that is approved by both the customer and the software firm. • Alternative approaches for carrying out the project have been examined: Often, promising and suitable alternatives are there such as encompassing software reuse, and partnerships or subcontracting with firms that have specialized knowledge or staff that can qualify for meeting the proposal’s terms. • Formal aspects of the relationship between the customer and the softwarefirm have been specified: • Customer communication and interface channels • Project deliverables and acceptance criteria • Customer design and test follow-up method • Customer change request procedure. • Identification of development risks: such as • insufficient professional know-how regarding the use of required development tools, need to be identified and resolved. • Adequate estimation of project resources and timetable. • professional staff • project’s budget, • subcontractors’ fees. • time requirements of all the parties participating in the project.

12. Examination of the company’s capacity with respect to the project. • professional competence • the availability of the required team members and development facilities • Examination of the customer’s capacity to meet his commitments. • customer’s financial and organizationalcapacities • personnel recruitment and training, • installation of therequired hardware • upgrading of its communications equipment. • Definition of partner and subcontractor participation. • quality assurance issues, • payment schedules, • distribution ofproject income/profits, • cooperation between project management and teams. • Definition and protection of proprietary rights. • reused software is insertedinto a new package • future reuse of the currentsoftware • use of proprietary data crucial for operating the system • security measures.

13. Contract draft review objectives: • No unclarified issues remain in the contract draft. • All the understandings reached between the customer and the firm are to be fully and correctly documented in the contract and its appendices. • These understandings are meant to resolve all the unclarified issues and differences between the customer and the firm that have been revealed so far. • No changes, additions, or omissions that have not been discussed and agreed upon should be introduced into the contract draft. • Any change, whether intentional or not, can result in substantial additional and unanticipated commitments on the part of the supplier.

14. Implementation of a contract review: Factors affecting the extent of a contract review: • Project magnitude: usually measured in man-month resources. • Project technical complexity. • Degree of staff experience in the project area. (frequently linked with software reuse possibilities; in cases where a high proportion of software reuse is possible, the extent of the review is reduced.) • Project organizational complexity. (The number of organizations, partners, subcontractors, and customers taking part in the project, the greater the contract review efforts required.) • Simple contract reviews can be carried out by one reviewer. • Large-scale contract review may require the participation of a team to examine a wide range of subjects.

15. Who performs a contract review? • The leader or another member of the proposal team. • The members of the proposal team. • An outside professional or a company staff member who is not a member of the proposal team. • A team of outside experts.

16. Implementation of a contract review for a major proposal: • Major proposals are proposals for projects characterized by at least some ofthe following: • very large-scale project, very high technical complexity, • Newprofessional area for the company, and high organizational complexity (realizedby a great number of organizations, i.e., partners, subcontractors, andcustomers, that take part in the project). Almost everybody agrees that contract review is a major procedure forreducing the risks of major project failures.

17. The difficulties of carrying out contract reviews for major proposals: • Time pressures: • The tender team isunder considerable time pressures. • As a result, each stage of the contractreview has to be completed within a few days to allow for the subsequentcorrections of documents to take place. • Proper contract review requires substantial professional work. • The potential contract review team members are very busy. The potentialmembers of the contract review team are often senior staff members andexperts who usually are committed to performing their regular tasks.

18. Recommendations for implementing major contract reviews: • The careful planning of contract reviews is required for their successful completion. • The contract review should be scheduled. • A team should carry out the contract review. Teamwork makes it possible to distribute the workload among the team members so that each member of the contract review team can find sufficient time to do his or her share (which may include preparing a written report that summarizes his or her findings and recommendations). • A contract review team leader should be appointed. It is important that the responsibility for organizing, managing and controlling the contract review activities be defined, preferable by appointing a team leader. • The activities of the team leader include: – Recruitment of the team members – Distribution of review tasks among the team’s members – Coordination between the members of the review team – Coordination between the review team and the proposal team

19. Contract reviews for internal projects: • A substantial number, if not the majority, of software projects are internalprojects — “in-house” projects – carried out by one unit of an organizationfor another unit of the same organization. • In such cases, the software developmentunit is the supplier, while the other unit can be considered thecustomer. • Frequently, internal software development projects are not based onwhat would be considered a complete customer–supplier relationship. • Inmany cases, these projects are based on general agreements, with goodwillplaying an important role in the relationships between the two units. • It followsthat the developing unit will perform only a short and “mild” contractreview, or none at all.

20. Typical internal projects and their in-house customers:

21. Typical Problems of loose relationships in in-house projects: • Unfortunately, loose relationships are usually characterized by insufficientexamination of the project’s requirements, its schedule, resources anddevelopment risks. • As a result of loose relationships, the following problems are likely to arise: • Inadequate definition of project requirements. • Poor estimates of required resources. • Poor timetable/scheduling. • Inadequate awareness of development risks. • In-house projects performedfor internal customers are more prone to failure than are outside-contractedprojects.

22. Disadvantages of loose relationships in internal projects: