Software Engineering B.

Tech IT/II Sem-II

Term: 2008-2009 Unit-8 PPT SLIDES Text Books:1.Software Engineering, A practitioners approach Roger s. Pressman 6th edition McGraw-Hill 2.Software Engineering Somerville 7th edition

Unit 8 Syllabus
Quality Management : Quality concepts, Software quality assurance, Software Reviews, Formal technical reviews, Statistical Software quality Assurance, Software reliability, The ISO 9000quality standards.

INDEX Unit 8
S.No Topic Name Lecture No Slide No.

1
2 3 4 5 6

Quality Management: Quality Concepts

Software Quality Assurance Software Reviews Formal Technical Review Statistical software quality assurance Software Reliability

L1
L2 L3 L4 L5 L6

4
7 10 11 18 20

ISO 9000 2000 quality assurance

L7

21

Quality Management
Quality Concepts
Variation control is the heart of quality control Form one project to another, we want to minimize the difference between the predicted resources needed to complete a project and the actual resources used, including staff, equipment, and calendar time Quality of design Refers to characteristics that designers specify for the end product
4

Quality Management
Quality of conformance Degree to which design specifications are followed in manufacturing the product Quality control Series of inspections, reviews, and tests used to ensure conformance of a work product to its specifications Quality assurance Consists of a set of auditing and reporting functions that assess the effectiveness and completeness of quality control activities
5

Quality Management
Cost of Quality Prevention costs Quality planning, formal technical reviews, test equipment, training Appraisal costs In-process and inter-process inspection, equipment calibration and maintenance, testing Failure costs rework, repair, failure mode analysis External failure costs Complaint resolution, product return and replacement, help line support, warranty work
6

Software Quality Assurance

Software quality assurance (SQA) is the concern of every software engineer to reduce cost and improve product time-to-market. A Software Quality Assurance Plan is not merely another name for a test plan, though test plans are included in an SQA plan. SQA activities are performed on every software project. Use of metrics is an important part of developing a strategy to improve the quality of both software processes and work products.
7

Software Quality Assurance

Definition of Software Quality serves to emphasize: 1.Conformance to software requirements is the foundation from which software quality is measured. 2. Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered. 3.Software must conform to implicit requirements (ease of use, maintainability, reliability, etc.) as well as its explicit requirements.

SQA Activities
Prepare SQA plan for the project. Participate in the development of the project's software process description. Review software engineering activities to verify compliance with the defined software process. Audit designated software work products to verify compliance with those defined as part of the software process. Ensure that any deviations in software or work products are documented and handled according to a documented procedure. Record any evidence of noncompliance and reports them to management.

Software Reviews
Purpose is to find errors before they are passed on to another software engineering activity or released to the customer. Software engineers (and others) conduct formal technical reviews (FTRs) for software quality assurance. Using formal technical reviews (walkthroughs or inspections) is an effective means for improving software quality.
10

Formal Technical Review

A FTR is a software quality control activity performed by software engineers and others.The objectives are: 1. To uncover errors in function, logic or implementation for any representation of the software. 2. To verify that the software under review meets its requirements. 3. To ensure that the software has been represented according to predefined standards. 4. To achieve software that is developed in a uniform manner and 5. To make projects more manageable.
11

Formal Technical Review

Review meeting in FTR The Review meeting in a FTR should abide to the following constraints 1. Review meeting members should be between three and five. 2. Every person should prepare for the meeting and should not require more than two hours of work for each person. 3. The duration of the review meeting should be less than two hours.
12

Formal Technical Review

The focus of FTR is on a work product that is requirement specification, a detailed component design, a source code listing for a component. The individual who has developed the work product i.e, the producer informs the project leader that the work product is complete and that a review is required. The project leader contacts a review leader, who evaluates the product for readiness, generates copy of product material and distributes them to two or three review members for advance preparation . Each reviewer is expected to spend between one and two hours reviewing the product, making notes

13

Formal Technical Review

The review leader also reviews the product and establish an agenda for the review meeting The review meeting is attended by review leader, all reviewers and the producer. One of the reviewer act as a recorder,who notes down all important points discussed in the meeting. The meeting(FTR) is started by introducing the agenda of meeting and then the producer introduces his product. Then the producer walkthrough the product, the reviewers raise issues which they have prepared in advance.

If errors are found the recorder notes down

14

Review reporting and Record keeping

During the FTR, a reviewer( recorder) records all issues that have been raised A review summary report answers three questions 1. What was reviewed? 2. Who reviewed it? 3. What were the findings and conclusions? Review summary report is a single page form with possible attachments The review issues list serves two purposes 1. To identify problem areas in the product 2. To serve as an action item checklist that guides the producer as corrections are made
15

Review Guidelines
Review the product, not the producer Set an agenda and maintain it Limit debate and rebuttal Enunciate problem areas, but dont attempt to solve every problem noted Take return notes Limit the number of participants and insist upon advance preparation. Develop a checklist for each product i.e likely to be reviewed Allocate resources and schedule time for FTRS Conduct meaningful training for all reviewer Review your early reviews

16

Software Defects
Industry studies suggest that design activities introduce 50-65% of all defects or errors during the software process Review techniques have been shown to be up to 75% effective in uncovering design flaws which ultimately reduces the cost of subsequent activities in the software process

17

Statistical Quality Assurance

Information about software defects is collected and categorized Each defect is traced back to its cause Using the Pareto principle (80% of the defects can be traced to 20% of the causes) isolate the "vital few" defect causes Move to correct the problems that caused the defects in the "vital few
18

Six Sigma for Software Engineering

The most widely used strategy for statistical quality assurance Three core steps: 1. Define customer requirements, deliverables, and project goals via well-defined methods of customer communication. 2. Measure each existing process and its output to determine current quality performance (e.g., compute defect metrics) 3. Analyze defect metrics and determine vital few causes. For an existing process that needs improvement 1. Improve process by eliminating the root causes for defects 2. Control future work to ensure that future work does not reintroduce causes of defects If new processes are being developed 1. Design each new process to avoid root causes of defects and to meet customer requirements 2. Verify that the process model will avoid defects and meet customer requirements

19

Software Reliability
Defined as the probability of failure free operation of a computer program in a specified environment for a specified time period Can be measured directly and estimated using historical and developmental data Software reliability problems can usually be traced back to errors in design or implementation. Measures of Reliability Mean time between failure (MTBF) = MTTF + MTTR MTTF = mean time to failure MTTR = mean time to repair Availability = [MTTF / (MTTF + MTTR)] x 100%

20

ISO 9000 Quality Standards

Quality assurance systems are defined as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management. ISO 9000 describes the quality elements that must be present for a quality assurance system to be compliant with the standard, but it does not describe how an organization should implement these elements. ISO 9001:2000 is the quality standard that contains 20 requirements that must be present in an effective software quality assurance system.
21