1. Contract Review Software Quality Assurance and Testing

2. Chapter Outline Contract review process and stages Contract review objectives Implementation of contract review Contract review subjects Contract review for internal projects

3. Chapter Objectives At the conclusion of studying this chapter, we should be able to: – Explain the two contract review stages – List the objectives of each stage of the contract review – Identify factors that affect the extent of the review – Identify the difficulties in performing a major contract review – Explain the recommended avenues for implementing a major contract review – Discuss the importance of carrying out a contract review for internal projects.

4. A Word about Contracts Contracts are vitally important (ذات أهمية حيوية) – Any of you deal with contracts? – experiences with them? Care to share? Basis for considerable litigation (أساس للتقاضي)when delivered software does not perform as expected. Bad contracts arise out of poorly defined requirements and unrealistic budgets and schedules. Result: poor quality software. Preventive Quality Assurance starts with a discussion of Contracts.

5. A Word about Contracts Author discusses two contracts: 1.a proposal draft contract, and 2.contract draft. Purpose: to arrive at a realistic budget and timetable and discovering pitfalls (المزالق) early. Then, to arrive at final contract draft with these important parameters revealed. The overall ‘contract-review process’ originates in the customer- supplier relationship for both external and internal projects.

6. Introduction the CFV Project Completion Celebration Read through this. All thought all was fine until the VP Finance popped the bubble citing major shortcomings in meeting the original RFP. Poorly understood and poorly written contracts with unrealistic schedules and budgets and professional commitments cause many problems. Lots of pressure in all projects to save time and money. These pressures often lead to major software failures. Overall Result: failure to meet necessary software quality!

7. Introduction the CFV Project Completion Celebration “Nobody tried to find out how many branches our client operates. Nobody mentioned that CFV operates 19 branches – six of them overseas – before signing the contract!” He continued: “We tried to renegotiate the installation and instruction budget items with the client, but the client insisted on sticking to the original contract.” Result: Shallow ( سطحية) and quick resource estimates, as well as exaggerated (مبالغ فيه) software sales efforts, have led to unrealistic schedules and budgets, or to unrealistic professional commitments.

8. RFPs (from Wiki) A request for proposal (RFP) is a solicitation made, often through a bidding process, by an agency or company interested in procurement of a commodity, service or valuable asset, to potential suppliers to submit business proposals. It is submitted early in the procurement cycle, either at the preliminary study, or procurement stage. –The RFP process brings structure to the procurement decision and is meant to allow the risks and benefits to be identified clearly up front. The RFP presents preliminary requirements for the commodity or service, and may dictate to varying degrees the exact structure and format of the supplier's response.

9. RFPs in Principle (طلب العروض من حيث المبدأ) Inform suppliers that an organization is looking to procure and encourages them to make their best effort. Require the company to specify what it proposes to purchase. If the requirements analysis has been prepared properly, it can be incorporated quite easily into the Request document. Alert suppliers that the selection process is competitive. Allow for wide distribution and response. Ensure that suppliers respond factually to the identified requirements. Are generally expected to follow a structured evaluation and selection procedure, so that an organization can demonstrate impartiality - a crucial factor in public sector procurements.

10. Why do software companies sign contracts with customers? Participation in a tender ( مناقصة ) – We pay you $X to deliver this product… Proposal submission according to customer’s RFP – Discussed. Common! Receipt of an order from a company’s customer – Most common Internal request from another department in the organization – Very common

11. Contract Review Definition Contract review is the software quality element that reduces the probability of such undesirable situations. Contract review is the SQA component devised to ( وضعت لـ) guide review drafts of proposal and contract documents.

12. Stages of the Contract Review Process 1.Review proposed draft prior to submission to potential customer – Review final proposal draft and customer’s requirement documents and explanations of requirements, costs, resources, maybe with partners /subcontractors. 2.Review of contract prior to signing – Review draft on basis of the proposal and understandings reached during the contract negotiation sessions. – Major activities and elaborate checklists are often used!

13. Contract Review Objectives To make sure that the following activities have been satisfactorily carried out: 1.Customer requirements clarified and documented Some documents (most) may well be vary vague. These vague items must be clarified and spelled out clearly! Author suggests an additional supplementary document… 2.Alternative approaches for carrying out the project examined Should be captured. Oftentimes the use of contract groups, reusable strategies, and more may be valid approaches. These need to be spelled out to avoid any future misunderstanding as to ‘who does what.’ 3.Formal aspects of the relationship between the customer and the software firm specified – Extremely critical. How are communications to take place? Frequency? – How are deliverables deployed? Customer responsibilities? Customer testing? – Change control procedure identified?

14. Contract Review Objectives 4. Development risks identified – HUGE area! Risk may be technical (don’t have know-how), environmental (developed under unusual circumstance...), political, social (different ethnic groups), personal (people get sick, die, have babies, need assistance, etc.), project complexity, software methodologies / technologies to be used, on and on and on. – Many projects have failed due to poor assessment of risk! MOVING RISK back to earlier stages in development was a primary motivation of iterative and incremental development. The UP does it, and all modern technologies also do it. 5.Project resources and timetable adequately estimated – Do we need subcontractors? What constraints might they have? Global partners? Their constraints? Resource estimation and the project’s budget: Does the software firm have the viability to deliver on schedule? 6.The firm’s capacity with respect to the project examined – availability of professional competence and development facilities?

15. Contract Review Objectives 7.The customer’s capacity to fulfill his commitments examined – How about the customer’s organization? Their financial capacities? Will they be able to train new people on new system? Recruit new people? Can they install and assume operational control for a delivered system? Maintenance? Handover? 8.Definition of Partner and Subcontractor Participation – These conditions must be clearly defined. Payment schedules? – Cooperation between project management and teams? – Communications? 9.Protection of proprietary rights defined – Who owns the software? Especially critical for future use and modification. Is this reusable software reused in other parts of the software development firm? Consider proprietary files?

16. Contract Draft Review Objectives To make sure that the following activities have been satisfactorily carried out: 1.No unclarified issues remain in the contract draft 2.All understandings reached subsequent to the proposal are correctly documented 3.No “new” changes, additions, or omissions that have not been fully discussed have entered the contract draft

17. Factors affecting the extent of a contract review –Project magnitude (measured in man-months effort) –Project technical complexity –Degree of staff acquaintance with and experience in the project area. –Project organizational complexity – the larger the number of participants (subcontractors, customers, developers, partners, etc.) The greater the contract review effort needs to be.

18. Who Performs the Review? Various people depending on the nature of the project –Leader or another member of the proposal team –Members of the proposal team –An outside professional or company staff member who is not a member of the proposal team –A team of outside experts. Usually a contract review team composed of outside experts may be used especially for major proposals. May be needed for a smaller project, but often not.

19. Implementation of Contract Review for Major Proposal Major proposals are proposals for projects characterized by at least some of the following: – large-scale, – very technical areas, – new professional areas for the company developers, – issues if there are many organizations such as partners, – subcontractors, etc.

20. The difficulties of carrying out contract reviews for major proposals Time pressures. – Both stages of the contract review, proposal draft review and contract draft review are usually performed when the tender team is under considerable time pressures. Proper contract review requires substantial professional work. The potential contract review team members are very busy. – The potential members of the contract review team are often senior staff members and experts who usually are committed to performing their regular tasks at the very time that the review is needed.

21. Recommended avenues for implementing major contract reviews The contract review should be scheduled – Contract review activities should be included in the proposal preparation schedule A team should carry out the contract review – which may include preparing a written report that summarizes his or her findings and recommendations A contract review team leader should be appointed. 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 – Follow-up of activities, especially compliance with the schedule – Summarization of the findings and their delivery to the proposal team.

22. Types of Internal Projects (“in-house” projects) Types of Many software projects are for internal use in an organization. The developer is the supplier; the consumer is the customer. Typical internal projects may be: 1.Administrative or operative software to be applied internally 2.Software packages originally intended to be sold to the public as “off-the-shelf” packages 3.Firmware to be embedded in the company’s products

23. Disadvantages of “loose relationships” internal projects to internal customers Very prone to failure!

24. Disadvantages of “loose relationships” internal projects to internal developers

25. Suggestions Author suggests that the customer-supplier relationship for external proposals should be used for internal. This will never happen. But the chances to avoid problems, if this approach were adopted, would be affected! Internally, needed are –Adequate proposals for the project –Appropriate contract review –Adequate agreement between internal customer and internal supplier.

26. Topics for discussion 5.2 (page 90) 5.4 (page 90) 5.7 (page 91)