Software Quality Assurance: II Software Life Cycle



Similar documents
PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >

I.3 Quality Management

<name of project> Software Project Management Plan

Project Management. Massimo Felici Room 1402, JCMB, KB

Software Quality Subcontractor Survey Questionnaire INSTRUCTIONS FOR PURCHASE ORDER ATTACHMENT Q-201

Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements

ASSAM POWER GENERATION CORPORATION LIMITED

TITLE: Control of Software

MNLARS Project Audit Checklist

Quality management systems

ISO :2005 Requirements Summary

SOFTWARE ASSURANCE STANDARD

Evaluation and Integration of Risk Management in CMMI and ISO/IEC 15504

Procedure for Assessment of System and Software

QUALITY MANUAL 3 KENDRICK ROAD WAREHAM, MA FAX

Network Certification Body

Vigilant Security Services UK Ltd Quality Manual

Quality Manual. DuraTech Industries, Inc Commerce Street La Crosse, WI MANUAL SERIAL NUMBER 1

Design Specification for IEEE Std 1471 Recommended Practice for Architectural Description IEEE Architecture Working Group 0 Motivation

PROJECT PLAN TEMPLATE

Development, Acquisition, Implementation, and Maintenance of Application Systems

MTAT Software Engineering Management

INTEGRATED MANAGEMENT SYSTEM MANUAL IMS. Based on ISO 9001:2008 and ISO 14001:2004 Standards

The President of Inductors Inc. is the senior executive responsible for operations.

An organization properly establishes and operates its control over risks regarding the information system to fulfill the following objectives:

NABL NATIONAL ACCREDITATION

Request for Proposal for Application Development and Maintenance Services for XML Store platforms

AIPM PROFESSIONAL COMPETENCY STANDARDS FOR PROJECT MANAGEMENT PART B CERTIFIED PRACTISING PROJECT PRACTITIONER (CPPP)

CHECKLIST TO DESIGNATE AREAS OF EVALUATION FOR REQUESTS FOR PROPOSAL (RFP)

FINE LOGISTICS. Quality Manual. Document No.: Revision: A

Project Management Guidelines

The Fulfillment of AS 9100 Rev C Requirements by EnterpriseIQ

CS 1632 SOFTWARE QUALITY ASSURANCE. 2 Marks. Sample Questions and Answers

DEC STD ISO Quality Systems - Model for Quality Assurance in Production and Installation

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

How to Write a Software Process Procedures and Policy Manual for YOUR COMPANY

CORPORATE QUALITY MANUAL

Rev: Issue 4 Rev 4 Quality Manual AOP0101 Date: 10/07/13. Quality Manual. CBT Technology, Inc. 358 North Street Randolph, MA 02368

Software Quality Assurance: VI Standards

Software Quality Management

Contents. viii. 4 Service Design processes 57. List of figures. List of tables. OGC s foreword. Chief Architect s foreword. Preface.

CENTRIS CONSULTING. Quality Control Manual

CDC UNIFIED PROCESS JOB AID

Comparison ISO/TS (1999) to VDA 6.1 (1998)

International Association of Scientific Innovation and Research (IASIR) (An Association Unifying the Sciences, Engineering, and Applied Research)

RDTL Procurement Best Practice Guide 7: Managing Contracts. RDTL MINISTRY OF FINANCE Procurement Service BEST PRACTICE GUIDE 7: MANAGING CONTRACTS

NEOXEN MODUS METHODOLOGY

Risk. Risk Categories. Project Risk (aka Development Risk) Technical Risk Business Risk. Lecture 5, Part 1: Risk

ISO 9001 : 2008 QUALITY MANAGEMENT SYSTEM AUDIT CHECK LIST INTRODUCTION

Project Implementation: Procurement & Contract Management. April 2012

Noorul Islam College of Engineering M. Sc. Software Engineering (5 yrs) IX Semester XCS592- Software Project Management

REQUEST FOR PROPOSAL FOR CONSTRUCTION MANAGEMENT SERVICES. Part I: Proposal Information

ICT Competency Profiles framework Job Stream Descriptions

ISO 9001:2000 AUDIT CHECKLIST

Certified Software Quality Engineer (CSQE) Body of Knowledge

UoD IT Job Description

Lecture 1: Introduction to Software Quality Assurance

ISO 9001:2008 Quality Management System Requirements (Third Revision)

NABET Accreditation Criteria for QMS Lead Auditor Training Course

Invitation to Tender

ISO/IEC QUALITY MANUAL

Old Phase Description New Phase Description

AS 9100 Rev C Quality Management System Manual. B&A Engineering Systems, Inc Business Park Drive, Suite A-1 Costa Mesa, CA 92626

Aberdeen City Council. Performance Management Process. External Audit Report o: 2008/19

Certified Software Quality Assurance Professional VS-1085

AP1000 European 18. Human Factors Engineering Design Control Document

Program Lifecycle Methodology Version 1.7

ISO 9001:2008 Audit Checklist

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

NATO GUIDANCE ON THE USE OF THE AQAP 2000 SERIES

GE Power Electronics Business Total Quality Management for Suppliers

Software Project Management Plan (SPMP)

CERTIFICATION OF SEAFARER RECRUITMENT AND PLACEMENT SERVICE PROVIDERS

Business Analyst Position Description

North American Development Bank. Bid Evaluation Procedures

MP Plumbing & Heating Ltd Quality Policy Manual THE QUALITY POLICY STATEMENT OF:

Software Test Plan (STP) Template

REQUEST FOR PROPOSAL FINANCIAL PLANNING CONSULTANT

Request for Proposal and Qualifications for Audit and Tax Preparation Services October 2015

Chapter 8: Software Quality Assurance. What is not tracked is not done

NATO Integrated Quality Requirements for Software throughout the Life Cycle

Company Quality Manual Document No. QM Rev 0. 0 John Rickey Initial Release. Controlled Copy Stamp. authorized signature

Develop Project Charter. Develop Project Management Plan

Project Plan for <project name>

Implementation of a Quality Management System for Aeronautical Information Services -1-

Negotiations feedback for successful project preparation. ERANIS workshop, , Minsk

Control No: QQM-02 Title: Quality Management Systems Manual Revision 10 07/08/2010 ISO 9001:2008 Page: 1 of 22

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

AEROSPACE STANDARD. Quality Management Systems - Requirements for Aviation, Space and Defense Organizations RATIONALE

Application of software product quality international standards through software development life cycle

The use of computer systems

QUALITY ASSURANCE IN EXTREME PROGRAMMING Plamen Balkanski

Description: Publication Date: 9/21/2015. Closing Date/Time: Open Until Contracted

DOC Electronic Timekeeping System Quarterly Project Oversight Report: Comprehensive Review For Period January March 2015

Quality Manual. UK Wide Security Solutions Ltd. 1 QM-001 Quality Manual Issue 1. January 1, 2011

SWEBOK Certification Program. Software Engineering Management

Transcription:

Software Quality Assurance: II Software Life Cycle Room E 3.165 Tel. 60-3321 Email: hg@upb.de

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 4.2.1 Software Requirement Specification 4.2.2 Software Design Description 4.2.3 Software Verification and Validation Plan 4.2.4 Software Verification and Validation Report 4.2.5 User documentation 4.3.6 Configuration Management Plan. 4.3 Other Documentation [Horch1996,IEEE Std. 730.1-1989] I-20 22

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 6.2.1 Software Requirements Review 6.2.2 Preliminary Design Review 6.2.3 Critical Design Review 6.2.4 Software Verification and Validation Review 6.2.5 Functional Audit 6.2.6 Physical Audit 6.2.7 Inprocess Reviews 6.2.8 Managerial Reviews 6.2.9 Configuration Management Plan Review 6.2.10 Postmortem Review 6.3Other Reviews and Audits [Horch1996,IEEE Std. 730.1-1989] I-21 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. 730.1-1989] I-22 22

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

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

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

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

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

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

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