ROEVER ENGINEERING COLLEGE Elambalur,Perambalur DEPARTMENT OF CSE SOFTWARE QUALITY MANAGEMENT

Size: px
Start display at page:

Download "ROEVER ENGINEERING COLLEGE Elambalur,Perambalur DEPARTMENT OF CSE SOFTWARE QUALITY MANAGEMENT"

Transcription

1 ROEVER ENGINEERING COLLEGE Elambalur,Perambalur DEPARTMENT OF CSE SOFTWARE QUALITY MANAGEMENT UNIT-1 INTRODUCTION TO SOFTWARE QUALITY 1. What are the views of quality? Explain in Detail the views of quality. The Transcendent view The product based view The value based view. The manufacturing view. The user based view. Authors view 2. Explain the boehm model of Quality. Boehm s Model Barry W. Boehm is known for his many contributions to software engineering. He was the first to identify software as the primary expense of future computer systems; he developed COCOMO, the spiral model, wideband Delphi, and many more contributions through his involvement in industry and academia.

2 Metrics Measurement and Analysis

3 2. Explain in detail GQM model. THE GOAL QUESTION METRIC APPROACH The Goal Question Metric (GQM) approach is based upon the assumption that for an

4 organization to measure in a purposeful way it must first specify the goals for itself and its projects, then it must trace those goals to the data that are intended to define those goals operationally, and finally provide a framework for interpreting the data with respect to the stated goals. Thus it is important to make clear, at least in general terms, what informational needs the organization has, so that these needs for information can be quantified whenever possible, and the quantified information can be analyzed a to whether or not the goals are achieved. The approach was originally defined for evaluating defects for a set of projects in the NASA Goddard Space Flight Center environment. The result of the application of the Goal Question Metric approach application is the specification of a measurement system targeting a particular set of issues and a set of rules for the interpretation of the measurement data. The resulting measurement model has three levels: 1. Conceptual level (GOAL): A goal is defined for an object, for a variety of reasons, with respect to various models of quality, from various points of view, relative to a particular environment. Objects of measurement are Products: Artifacts, deliverables and documents that are produced during the system life cycle; E.g., specifications, designs, programs, test suites. Processes: Software related activities normally associated with time; E.g., specifying, designing, testing, interviewing. Resources: Items used by processes in order to produce their outputs; E.g., personnel, hardware, software, office space. 2. Operational level (QUESTION): A set of questions is used to characterize the way the assessment/achievement of a specific goal is going to be performed based on some characterizing model. Questions try to characterize the object of measurement (product, process, resource) with respect to a selected quality issue

5 and to determine its quality from the selected viewpoint. 3. Quantitative level (METRIC): A set of data is associated with every question in order to answer it in a quantitative way. The data can be Objective: If they depend only on the object that is being measured and not on the viewpoint from which they are taken; E.g., number of versions of a document, staff hours spent on a task, size of a program. Subjective: If they depend on both the object that is being measured and the viewpoint from which they are taken; E.g., readability of a text, level of user satisfaction. The complete Goal Question Metric model is as follows:

6 THE GOAL QUESTION METRIC PROCESS A GQM model is developed by identifying a set of quality and/or productivity goals, at corporate, division or project level; e.g., customer satisfaction, on-time delivery, improved performance. From those goals and based upon models of the object of measurement, we derive questions that define those goals as completely as possible. For example, if it is to characterize a software system (e.g., an electronic mail package, a word processor) with respect to a certain set of quality issues (e.g., portability across architectures), then a quality model of the product must be chosen that deals with those issues (e.g., list of functional features that can be implemented in different architectures). The next step consists in specifying the measures that need to be collected in order to answer those questions, and to track the conformance of products and processes to the goals. After the measures have been specified, we need to develop the data collection mechanisms, including validation and analysis mechanisms.

7 CONCLUSION In summary, the Goal Question Metric approach is a mechanism for defining and interpreting operational and measurable software. It can be used in isolation or, better, within the context of a more general approach to software quality improvement. Figure below outlines the basic roles and flows of information for this model.

8 Unit-II SOFTWARE QUALITY ASSURANCE 1. Explain in detail about the Documentation. Particularly important - documents are the tangible manifestation of the software. Documentation process standards Concerned with how documents should be developed, validated and maintained. Document standards Concerned with document contents, structure, and appearance. Document interchange standards Concerned with the compatibility of electronic documents

9 Interchange standards allow electronic documents to be exchanged, mailed, etc. Documents are produced using different systems and on different computers. Even when standard tools are used, standards are needed to define conventions for their use e.g. use of style sheets and macros. Need for archiving. The lifetime of word processing systems may be much less than the lifetime of the software being documented. An archiving standard may be defined to ensure that the document can be accessed in future. 2. Explain in detail the CMM Compatibility of Reviews and audits.

10 3. Explain the software inspection process. Meetings (real or virtual) during which designs and code are reviewed by people other than the original developer. New perspective Finding defects may be easier for people who haven't seen the artifact before and don t have preconceived ideas about its correctness. Knowledge sharing Regarding designs and specific software artifacts Regarding defect detection practices Find flaws early Can dramatically reduce cost of fixing them During detail design even before code is written Or code that does not yet have a test harness Or code in which testing has found flaws but root causes are not understood Reduce rework and testing effort Can reduce overall development effort 1. Inspections / Formal Technical Reviews Participation defined by policy Developers Designated key individuals peers, QA team, Review Board, etc.

11 Advance preparation by participants Typically based on checklists Formal meeting to discuss artifact Led by moderator, not author Documented process followed May be virtual or conferenced Formal follow-up process Written deliverable from review Appraise product 2. Walkthroughs No advance preparation Author leads discussion in meeting No formal follow-up Low cost, valuable for education 3. Other review approaches Pass-around preparation part of an inspection Peer desk check examination by a single reviewer (like pair programming) Ad-hoc informal feedback from a team member Formal technical reviews will find more bugs Ford Motor: 50% more bugs with formal process But they also cost more

12 4. a) Explain walkthrough process. Walkthrough: Method of conducting informal group/individual review is called walkthrough, in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems or may suggest improvement on the article, walkthrough can be pre planned or can be conducted at need basis and generally people working on the work product are involved in the walkthrough process. The Purpose of walkthrough is to: Find problems Discuss alternative solutions Focusing on demonstrating how work product meets all requirements.ieee 1028 recommends three specialist roles in a walkthrough: Leader: who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author) Recorder: who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meeting, normally generate minutes of meeting at the end of walkthrough session. Author: who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items. Walkthrough Process: Author describes the artifact to be reviewed to reviewers during the meeting. Reviewers present comments, possible defects, and improvement suggestions to the author. Recorder records all defect, suggestion during walkthrough meeting. Based on reviewer comments, author performs any necessary rework of the work product if required. Recorder prepares minutes of meeting and sends the relevant stakeholders and leader is normally to monitor overall walkthrough meeting activities as per the defined company process or responsibilities for conducting the reviews, generally performs monitoring activities, commitment against action items etc. Inspection: An inspection is a formal, rigorous, in-depth group review designed to identify problems as close to their point of origin as possible., Inspection is a recognized industry best practice to improve the

13 quality of a product and to improve productivity, Inspections is a formal review and generally need is predefined at the start of the product planning, The objectives of the inspection process are to Find problems at the earliest possible point in the software development process Verify that the work product meets its requirement Ensure that work product has been presented according to predefined standards Provide data on product quality and process effectiveness Inspection advantages are to build technical knowledge and skill among team members by reviewing the output of other people Increase the effectiveness of software testing. IEEE 1028 recommends three following roles in an Inspection: Inspector Leader: The inspection leader shall be responsible for administrative tasks pertaining to the inspection, shall be responsible for planning and preparation, shall ensure that the inspection is conducted in an orderly manner and meets its objectives, should be responsible for collecting inspection data Recorder: The recorder should record inspection data required for process analysis. The inspection leader may be the recorder. Reader: The reader shall lead the inspection team through the software product in a comprehensive and logical fashion, interpreting sections of the work product and highlighting important aspects Author: The author shall be responsible for the software product meeting its inspection entry criteria, for contributing to the inspection based on special understanding of the software product, and for performing any rework required to make the software product meet its inspection exit criteria. Inspector: Inspectors shall identify and describe anomalies in the software product. Inspectors shall be chosen to represent different viewpoints at the meeting (for example, sponsor, requirements, design, code, safety, test, independent test, project management, quality management, and hardware engineering). Only those viewpoints pertinent to the inspection of the product should be present. Some inspectors should be assigned specific review topics to ensure effective coverage. For example, one inspector may focus on conformance with a specific standard or standards, another on syntax, and another for overall coherence. These roles should be assigned by the inspection leader when planning the inspection. All participants in the review are inspectors. The author shall not act as inspection leader and should not act as reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role. Individuals holding management positions over any member of the inspection team shall not participate in the inspection Inspection Process: Following are review phases: Planning Overview

14 Preparation Examination meeting Planning: Inspection Leader perform following task in planning phase Determine which work products need to be inspected Determine if a work product that needs to be inspected is ready to be inspected Identify the inspection team Determine if an overview meeting is needed. The moderator ensures that all inspection team members have had inspection process training. The moderator obtains a commitment from each team member to participate. This commitment means the person agrees to spend the time required to perform his or her assigned role on the team. Identify the review materials required for the inspection, and distribute materials to relevant stake holders Overview: Purpose of the overview meeting is to educate inspectors; meeting is lead by Inspector lead and is presented by author, overview is presented for the inspection, this meeting normally acts as optional meeting, purpose to sync the entire participant and the area to be inspected. Preparation: Objective of the preparation phase is to prepare for the inspection meeting by critically reviewing the review materials and the work product, participant drill down on the document distributed by the lead inspector and identify the defect before the meeting Examination meeting: The objective of the inspection meeting is to identify final defect list in the work product being inspected, based on the initial list of defects prepared by the inspectors [identified at preparation phase and the new one found during the inspection meeting. The Lead Auditor opens the meeting and describes the review objectives and area to be inspected. Identify that all participants are well familiar with the content material, Reader reads the meeting material and inspector finds out any inconsistence, possible defects, and improvement suggestions to the author. Recorder records all the discussion during the inspection meeting, and mark actions against the relevant stake holders. Lead Inspector may take decision that if there is need of follow up meeting. Author updates the relevant document if required on the basis of the inspection meeting discussion Rework and Follow-up: Objective is to ensure that corrective action has been taken to correct problems found during an inspection. b) Explain the Audit process. Audit

15 An audit is an evidence gathering process. Audit evidence is used to evaluate how well audit criteria are being met. Audits must be objective, impartial, and independent, and the audit process must be both systematic and documented. There are three types of audits: first-party, second-party, and third-party audits. First-party audits are internal audits. Second and third party audits are external audits. Organizations use first party (internal) audits to audit themselves for internal purposes. However, you don t have to do them yourself. You can ask an external organization to carry out an internal audit on behalf of your organization. You can also use first party audits to declare that your organization complies with an ISO standard (this is called a self-declaration). Second party audits are external audits. They re usually done by customers or by others on their behalf. However, they can also be done by any external party that has an interest in your organization. Third party audits are external audits as well. However, they re performed by independent (disinterested) external organizations. Thir d party audits are used to determine whether or not an organization complies with an ISO standard. These auditors are referred to as registrars or certification bodies. Audit criteria Audit criteria include policies, procedures, and requirements. Audit evidence is used to determine how well such audit criteria are being met. Audit evidence is used to determine how well policies are being implemented, how well procedures are being applied, and how well requirements are being met. Auditee An auditee is an organization (or part of an organization) that is being audited. Organizations include companies, corporations,

16 enterprises, f irms, charities, associations, and institutions. Organizations can be either incorporated or unincorporated and can be privately or publicly owned. Audit evidence Audit evidence includes records, factual statements, and other verifiable information that is related to the audit criteria being used. Audit criteria include policies, procedures, and requirements. Audit evidence can be either qualitative or quantitative. Objective evidence is data that shows or proves that something exists or is true. Audit findings Audit findings result from a process that evaluates audit evidence and compares it against audit criteria. Audit findings can show that audit criteria are being met (conformity) or that they are not being met (nonconformity). They can also identify improvement opportunities. Audit findings are used to assess the effectiveness of the quality management system and to identify opportunities for improvement. Audit evidence includes records, factual statements, and other verifiable information that is related to the audit criteria being used. Audit criteria include policies, procedures, and requirements. Auditor In the context of this quality management standard, an auditor is a person who collects evidence in order to evaluate how well quality management systems meet requirements. Auditors are expected to determine whether quality management systems comply with standards and other planned arrangements. They must also be able to determine whether quality management systems are properly implemented and maintained. And they must

17 be able to do all of this while being independent, objective, impartial, and competent. Audit plan An audit plan specifies how you intend to conduct a particular audit. It describes the activities you intend to carry out and the arrangements you intend to make. An audit is an evidence gathering process. Audit evidence is used to evaluate how well audit criteria are being met. Audit scope The scope of an audit is a statement that specifies the focus, extent, and boundary of a particular audit. The scope of an audit is generally defined by specifying the physical location of the audit, the organizational units that will be examined, the processes and activities that will be included, and the time period that will be covered. Unit- III QUALITY CONTROL AND RELIABILITY CS1020 SOFTWARE QUALITY MANAGEMENT 1. Explain in Detail about the Ishikawa s basic tools in software development Check sheet Pareto diagram Histogram Scatter diagram Run chart Control chart Cause and effect diagram. 2. a) Explain in detail about the CASE tools. Advantages of CASE tools. Types of CASE tools. The Excelerator CASE tools.

18 The Information Engineering Facility b) Explain the Defect Prevention Process. 3. Explain the Defect removal Effectiveness. (16) 4. Explain the Reliability models. Rayleigh model Reliability growth model J-M Model Littlewood Model Goel-Okumoto Imperfect Debugging Model Goel-okumoto Non homogenous poison process model. Musa-okumoto logarithmic poison Execution Time model. The delayed S and inflection S Model. Basic Assumptions 5. Explain in detail about the Rayleigh model. J-M Model Littlewood Model Goel-Okumoto Imperfect Debugging Model Goel-okumoto Non homogenous poison process model. Musa-okumoto logarithmic poison Execution Time model.

19 The delayed S and inflection S Model. Basic Assumptions 6. Explain Reliability growth model for quality assessment Quality improvement plan QIP activities. Advantages Quality management principle. Problems Directions for quality improvement plan Four best scenarios Unit-IV QUALITY MANAGEMENT SYSTEM 1. Explain in detail the elements of QMS. Definition of QMS Organizational structure Responsibilities Procedures Processes Resources Statistical process control Quality control

20 2. Explain the Rayleigh model framework. Quality management principle Problems Directions for quality improvement plan Four best scenarios 3. Explain the Reliability Growth models. Quality improvement plan QIP activities Advantages 4. Explain the complexity metrics and its models Lines of code Halstead software science Cyclomatic complexity Syntactic constructs Structure metrics 5. Explain Lines of Code and Halstead s Software Science. Definition Primitives Halstead s equations

21 7.a)Explain Syntactic constructs Definition Two field defects level Field defect= LOC+.001unique operands Field defect= 0.11 IF-THEN Number of calls b) Briefly explain structure metrics. Definition Kafura s structure complexity Mc Cabe s cyclomatic complexity 8. Explain in detail the Customer satisfaction surveys / analysis. Definition Customer satisfaction surveys Methods of survey data collection Personal interviewer Telephone interviewer Mailed Questionnaire Method Sampling Method Simple random sampling Systematic sampling Stratified sampling Cluster sampling

22 1. Discuss in detail about the needs for standards. Unit V QUALITY STANDARDS Standards are generally defined in term of a model of best practices. The standards estabishes the model, in the case of a quality management system Types of accreditation Benefits to the supplier Series of quality standard The contents of the standard Assessment of the quality standard 2. Explain the ISO9000 series standard. The ISO9000 series of standards are the international standards defined for quality management systems. The series dates from 1979, BS 5750 was introduced in the UK The ISO 9000 series of quality management standards 1. ISO ISO ISO ISO ISO 9004 Comparison of the requirements of the standards Management responsibility. Quality system Contract review Design control Document control Purchasing

23 Purchaser supplier product Product identification and traceability Process control Inspection and testing Control of nom conforming product Corrective action Quality records Training Servicing 3. Explain the ISO standard for software development. Structure of ISO standard Introductory material Three clauses of the standards Quality system framework Quality system life cycle activates Quality system supporting activities Guidance o f ISO Explain the CMMI Model Introduction to the model levels of the CMMI Views of quality underpinning the model Stages of the model Evolution f the CMMI The role of the CMMI 5. Explain the Six Sigma Concepts. Based on teachings of Dr. Walter Shewhart, Dr. W. E. Deming & Dr. J. Juran.

24 Process Control; Plan Do Check Act; Common and Special Causes; Improvement can be done project by project Statistical tools Hawthorne Plant Experiences Developed by Bill Smith at Motorola in 1980s Degree of variation; Level of performance in terms of defects; Statistical measurement of process capability; Benchmark for comparison; Process improvement methodology; It is a Goal; Strategy for change; A commitment to customers to achieve an acceptable level of performance Business Definition A break through strategy to significantly improve customer satisfaction and shareholder value by reducing variability in every aspect of business. Technical Definition A statistical term signifying 3.4 defects per million opportunities. Definition Areas under normal curve Specification limits Centered six sigma Shifted six sigma

25