Software Quality Assurance: II Software Life Cycle

Transcription

1 Software Quality Assurance: II Software Life Cycle Room E Tel hg@upb.de

2 Outline I Introduction II Software Life Cycle III Quality Control IV Infrastructure V Management VI Standards VII Conclusion & Summary I-2

3 II Software Life Cycle II.1 Contract Review II.2 Development and Quality Plan II.3 Development II.4 Maintenance II.5 External Contributions II.6 Discussion & Summary II.7 Bibliography I-3

4 II.1 Contract Review Contract reviews are required by ISO 9001! Overview: Contract review process and stages Contract review objectives Implementation of contract review Contract review subjects Contract review for internal projects I-4

5 Common Contract Situations Participation in a tender Proposal submission according to customer s RFP (request for proposal) Receipt of an order from a company s customer Internal request from another department in the organization I-5

6 Contract Review Stages The contract review consist of Proposal draft review Reviews the proposal prior to submission to the potential customer This includes customer s requirement documents, cost and resource estimates, existing contracts or contract drafts of the supplier with partners and subcontractors Contract draft review Reviews the contract draft prior to signing Review on the basis of the proposal and the understanding (including changes) reached during the contract negotiation sessions. I-6

7 Proposal Draft Review - Objectives Make sure that the following activities have been satisfactorily carried out: 1. Customer requirements clarified and documented 2. Alternative approaches for carrying out the project examined 3. Formal aspects of the relationship between the customer and the software firm specified 4. Development risks identified 5. Project resources and timetable adequately estimated 6. The firm s capacity with respect to the project examined 7. The customer s capacity to fulfill his commitments examined 8. Partner and subcontractor s participation conditions defined 9. Protection of proprietary rights defined I-7

8 Contract Draft Review - Objectives Make sure that the following activities have been satisfactorily carried out: No unclarified issues remain in the contract draft All understandings reached subsequent to the proposal are correctly documented No new changes, additions, or omissions have entered the contract draft I-8

9 Implementing Contract Reviews Factors effecting the extend Project magnitude Project technical complexity Degree of staff acquaintance with and experience in the project area Project organizational complexity Who performs the review? The leader or another member of the proposal team The members of the proposal team An outside professional or company staff member who is not member of the proposal team A team of outside experts (ascending order, according to the complexity of the project) I-9

10 Contract Reviews for Major Proposals (1/2) We have a major proposal when we have a very high project magnitude, a very high technical complexity of the project, a new professional area for the company, or a very high organizational complexity. Resulting problems: Time pressure: only a few days for each stage Substantial professional work Team members are often very busy I-10

11 Contract Reviews for Major Proposals (2/2) Recommendations: Schedule for contract review Teamwork to share workload Appoint a contract review team leader (clear responsibilities) Review team leader responsibilities: Recruiting Coordinate with proposal team Distributed review tasks Follow-up activities, especially Coordinate review team conformance with the schedule Report finding to the proposal team I-11

12 What about Internal Projects? Types of internal projects: (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 Contract vs. loose relationship problems: (1) Inadequate definition of project requirements (2) Poor estimate of the required resources (3) Poor timetable (4) Inadequate awareness of development risks I-12

13 Disadvantages to Internal Customers Subject (1) Inadequate definition of project requirements (2) Poor estimate of the required resources (3) Poor timetable (4) Inadequate awareness of development risks Disadvantages to the internal customer * Implementation deviates from the needed applications * Low satisfaction * Unrealistic expectations about project feasibility * Missing scheduled dates for beginning the distribution of new products * Customer unprepared for project risks and their consequences Internal customer should insist on some from of contract I-13

14 Disadvantages to Internal Developers Subject (1) Inadequate definition of project requirements (2) Poor estimate of the required resources (3) Poor timetable (4) Inadequate awareness of development risks Disadvantages to the internal developer * Higher change requirements * Wasted resources due to introducing avoidable changes * Substantial deviations from budget * Friction between units induced by requirements for budget additions * Development activities are under time pressures and suffer from low quality * Delays in freeing staff for their next project * Delayed initiation of efforts to overcome difficulties Internal Developer should also insist on some from of contract I-14

15 II.2 Development and Quality Plan Overview: Why not reuse the project proposal? Development plan and quality plan objectives The elements of the development plan Elements of the quality plan Example of a detailed SQA Plan Software development risks and software risk management I-15

16 Why not reuse the Project Proposal? Projects need plans that: Are based on proposal materials which have been re-examined and thoroughly updated. Are mire comprehensive than the proposal (w.r.t. schedules, resource estimates, risks) Include additional subjects, absent from the proposal Were prepared at the beginning of the project! I-16

17 Objectives (Quality + Process) Planning is meant to prepare adequate foundations for successful and timely completion of the project. The planning process includes: 1. Scheduling development activities and estimating the required manpower resources and budget 2. Recruiting team members and allocating development resources 3. Resolving development risks 4. Implementing required SQA activities 5. Providing management with data needed for project control I-17

18 Development Plan: Elements 1. Project products, specifying deliverables 2. Project interfaces 3. Project s methodology and development tools 4. Software development standards and procedures 5. Map of the development process 6. Project milestones 7. Project staff organization and coordination with external participants 8. Required development facilities 9. Development risks and risk management actions 10. Control methods 11. Project cost estimates I-18

19 Quality Assurance Plan: Elements A quality assurance plan sets out the desired product qualities and how these are assessed and defines the most significant quality attributes. The quality assurance plan should define the quality assessment process. It should set out which organisational standards should be applied and, where necessary, define new standards to be used. [Sommerville2004] Elements: 1. List of quality goals 2. Review activities 3. Software tests 4. Acceptance tests for software externally developed 5. Configuration management plans: tools, procedures, and dates for version release I-19

20 Detailed SQA Plan (1/3) 1 Purpose of Plan 2 Reference Documents 3 Management 3.1 Organization 3.2 Tasks 3.3 Responsibilities 4 Documentation 4.1 Purpose 4.2 Minimum Documentation Software Requirement Specification Software Design Description Software Verification and Validation Plan Software Verification and Validation Report User documentation Configuration Management Plan. 4.3 Other Documentation [Horch1996,IEEE Std ] I-20 22

21 Detailed SQA Plan (2/3) 5 Standards, Practices and Conventions, and Metrics 5.1Purpose 5.2Documentation, Logic, Coding, and Commentary Standards and Conventions 5.3Testing Standards and Conventions 5.4Metrics 6 Reviews and Audits 6.1Purpose 6.2Minimum Requirements Software Requirements Review Preliminary Design Review Critical Design Review Software Verification and Validation Review Functional Audit Physical Audit Inprocess Reviews Managerial Reviews Configuration Management Plan Review Postmortem Review 6.3Other Reviews and Audits [Horch1996,IEEE Std ] I-21 22

22 Detailed SQA Plan (3/3) 7 Test 8 Problem Reporting and Corrective action 8.1 Practices and Procedures 8.2 Organizational Responsibilities 9 Tools, Techniques and Methodologies 10 Code Control 11 Media Control 12 Supplier control 13 Records Collection, Maintenance and Retention 14 Training 15 Risk Management [Horch1996,IEEE Std ] I-22 22

23 Classes of Software Development Risks 1. Scheduling and timing risks 2. System functionality risks 3. Subcontracting risks 4. Requirement management risks 5. Resource usage and performance risks 6. Personnel management risks WS04/05 Short excursus: Software Quality risk management Assurance I Introduction (1/7) I-23

24 Top 10 Software Risk Items (SRI) 1. Developing wrong software functions 2. Unrealistic schedules and budgets 3. Developing wrong user interface 4. Gold plating 5. Continuing stream of requirement changes 6. Shortfalls in externally furnished components 7. Shortfalls in externally performed tasks 8. Personnel shortfalls 9. Real-time performance shortfalls 10. Straining computer science capabilities WS04/05 Short excursus: Software Quality risk management Assurance I Introduction (2/7) I-24

25 Risk Management Actions (1/4) No. Risk management actions (RMA) Internal risk management Prevention Risks early on Identify resolution 1 Detailed analysis of the requirements and estimated schedules and costs 2 Efficient project organization, adequate staff and team size 3 Personal Training 4 Arranging for take over in case of turnover and unanticipated workloads 5 User participation in the development process 6 Efficient change control (change request screening) 7 Intensive SQA measures such as inspections, design reviews, and benchmarking WS04/05 Short excursus: Software Quality risk management Assurance I Introduction (3/7) I-25

26 Risk Management Actions (2/4) No. Risk management actions (RMA) Internal risk management Prevention Risks early on Identify resolution 8 Periodic checking for timely availability of firm professionals currently occupied with other projects 9 Arranging for participation of professional staff members with experience with SRIs 10 Scheduling SRI-related activities as early as possible 11 Prototyping SRI related modules or applications 12 Preparing scenarios for complicated SRI-related modules or applications 13 Simulating related modules or applications WS04/05 Short excursus: Software Quality risk management Assurance I Introduction (4/7) I-26

27 Risk Management Actions (3/4) No. Risk management actions (RMA) Subcontracting Prevention Risks early on Identify resolution 1 Preparing comprehensive and through contracts with subcontractors and suppliers, including contract reviews 2 Participating in internal progress control and SQA activities of subcontractors (incorporated in the contract) 3 Arranging for loans of professionals with specialized knowledge and experience if the need arises 4 Hiring consultants to support the team in the absence of sufficient know-how and experience WS04/05 Short excursus: Software Quality risk management Assurance I Introduction (5/7) I-27

28 Risk Management Actions (4/4) No. Risk management actions (RMA) Customer Prevention Risks early on Identify resolution 1 Formulating comprehensible and thorough contracts with customers, including contract reviews 2 Negotiate with the customer to change requirements with high risk 3 Negotiate with the customer to change schedule elements with high risk WS04/05 Short excursus: Software Quality risk management Assurance I Introduction (6/7) I-28

29 Risk Management Process Activities are triggered due to: New projects Changes or additions to ongoing projects Feedback form monitoring the projects Pre - project New project Risk identification and assessment Planning risk management activities Ongoing projects Identifying and assessing new software risks Required results achieved Planning and updating risk management activities Implementing risk management actions (risk resolution) Monitoring software risk management activities Evaluate monitoring results Unsatisfactory results WS04/05 Short excursus: Software Quality risk management Assurance I Introduction (7/7) I-29