1 PreProject Software Quality Components Chapters 5 6

1 Pre-Project Software Quality Components Chapters 5 & 6 Galin, SQA from theory to implementation © Pearson Education Limited 2004

Chapter 5 2 Contract review • • • Contract review process and stages Contract review objectives Implementation of contract review Contract review subjects Contract review for internal projects Galin, SQA from theory to implementation © Pearson Education Limited 2004

3 1. Introduction Galin, SQA from theory to implementation © Pearson Education Limited 2004

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. Galin, SQA from theory to implementation © Pearson Education Limited 2004

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. Galin, SQA from theory to implementation © Pearson Education Limited 2004

6 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. Galin, SQA from theory to implementation © Pearson Education Limited 2004

7 5. 1 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! Galin, SQA from theory to implementation © Pearson Education Limited 2004

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. • Effective RFPs typically reflect the strategy and short/long-term business objectives, providing detailed insight upon which suppliers will be able to offer a matching perspective. [3] • Similar requests include a request for quotation and a request for information. Galin, SQA from theory to implementation © Pearson Education Limited 2004

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. Galin, SQA from theory to implementation © Pearson Education Limited 2004

10 5. 2 Common Contract Situations 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 Galin, SQA from theory to implementation © Pearson Education Limited 2004

11 Contract objectives and stages Carry out the Contract Review process in two stages: 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. 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! Galin, SQA from theory to implementation © Pearson Education Limited 2004

12 5. 3 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. ’ • Formal aspects of the relationship between the customer and the software firm specified 1. Extremely critical. How are communications to take place? Frequency? How are deliverables deployed? Customer responsibilities? Customer testing? Change control procedure identified? Galin, SQA from theory to implementation © Pearson Education Limited 2004

13 5. 3 Contract Review Objectives To make sure that the following activities have been satisfactorily 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. 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 techologies also do it. • 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? • The firm’s capacity with respect to the project examined availability of professional competence and development facilities? CMMi. . . Galin, SQA from theory to implementation © Pearson Education Limited 2004

14 5. 3 Contract Review Objectives To make sure that the following activities have been satisfactorily carried out: 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? • Protection of proprietary rights defined 7. 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? Galin, SQA from theory to implementation © Pearson Education Limited 2004

15 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 Galin, SQA from theory to implementation © Pearson Education Limited 2004

16 5. 4 Implementation of a Contract Review Galin, SQA from theory to implementation © Pearson Education Limited 2004

17 Contract Review Considerations • Can be very exacting • May focus on technical or organizational issues • Thus different levels of effort and participation are often needed depending on the nature of the contract. • Any student experiences with this? Class Discussion • Certainly you may discuss in lots of detail some / all of the following: – Project magnitude (measured in man-months effort) – Project technical complexity – Familiarity with application domain by staff may affect extent of the review – Project organizational complexity – the larger the number of participants (subcontractors, customers, developers, partners, etc. The greater the contract review effort needs to be. Galin, SQA from theory to implementation © Pearson Education Limited 2004

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. Galin, SQA from theory to implementation © Pearson Education Limited 2004

19 Implementation of Contract Review for Major Proposal • This is a big deal for major proposals. • For very complex, large-scale, very technical areas, new professional areas for the company developers, issues if there are many organizations such as partners, subcontractors, etc. • Book offers “Implementation of a contract review process for a major project usually involves substantial organizational difficulties. ” – Getting parties together, vested interests, etc. HUGE. – May require lots of professional work and time from busy people! • Contract reviews must be – Scheduled; – Distribute portions to appropriate roles for review – Contract review team leader needs to be appointed. • Many responsibilities: recruitment of team members; distribution of review tasks, coordination between review team and proposal team; follow up activities; Summarization. Galin, SQA from theory to implementation © Pearson Education Limited 2004

20 5. 6 Types of internal projects 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 Galin, SQA from theory to implementation © Pearson Education Limited 2004

21 Internal Projects • Important to note that projects normally take place via general agreements and goodwill; • There may be mild or superficial contract review, if any, or none at all. • Fraught with problems! • Due to the loosy-goosey way ‘contracts’ are ‘done. ’ • Classroom experiences? IST at UNF? Galin, SQA from theory to implementation © Pearson Education Limited 2004

22 Very prone to failure! Subject Disadvantages to the internal customer (1) Inadequate definition * Implementation deviates from the needed of project requirements applications * Low satisfaction (2) Poor estimate of the * Unrealistic expectations about project required resources feasibility (3) Poor timetable * Missing scheduled dates for beginning the distribution of new products (4) Inadequate awareness * Customer unprepared for project risks of development risks and their consequences Galin, SQA from theory to implementation © Pearson Education Limited 2004

23 Subject Disadvantages to the internal customer (1) Inadequate definition * Higher change requirements of project requirements * Wasted resources due to introducing avoidable changes (2) Poor estimate of the * Substantial deviations from budget required resources * Friction between units induced by requirements for budget additions (3) Poor timetable * Development activities are under time pressures and suffer from low quality * Delays in freeing staff for their next project (4) Inadequate awareness * Tardy initiation of efforts to overcome of development risks difficulties Galin, SQA from theory to implementation © Pearson Education Limited 2004

Suggestions 24 • 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 bewen internal customer and internal supplier. Galin, SQA from theory to implementation © Pearson Education Limited 2004

25 Homework • You are to individually answer questions 5. 7 and 5. 8 and submit these to me via Blackboard Assignment no later than 4 pm on the date of the next class. Galin, SQA from theory to implementation © Pearson Education Limited 2004

26 Team Discussion Forum • Team 1 is to fully prepare and discuss the following questions at the end of Chapter 5: • 5. 4 • 5. 8 • 5. 10 Galin, SQA from theory to implementation © Pearson Education Limited 2004