unit -i - vidyarthiplus

54
UNIT - I Software quality In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions. Software product quality Product quality o conformance to requirements or program specification; related to Reliability Scalability o Correctness Completeness absence of bugs Fault-tolerance o Extensibility o Maintainability Documentation Software Quality Factors A software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract, but nevertheless is a desirable requirement which enhances the quality of the software program. Understandability Completeness Maintainability Conciseness Portability Consistency Testability Usability Reliability Structured ness Efficiency Security www.Vidyarthiplus.com www.Vidyarthiplus.com

Upload: others

Post on 20-Feb-2022

19 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: UNIT -I - Vidyarthiplus

UNIT - I

Software quality

In the context of software engineering, software quality measures how well software isdesigned (quality of design), and how well the software conforms to that design (qualityof conformance), although there are several different definitions.

Software product quality

Product qualityo conformance to requirements or program specification; related to

Reliability Scalability

o Correctness Completeness absence of bugs Fault-tolerance

o Extensibilityo Maintainability

Documentation

Software Quality Factors

A software quality factor is a non-functional requirement for a software program which isnot called up by the customer's contract, but nevertheless is a desirable requirementwhich enhances the quality of the software program.

Understandability Completeness Maintainability Conciseness Portability Consistency Testability Usability Reliability Structured ness Efficiency Security

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 2: UNIT -I - Vidyarthiplus

Software Quality Measurement

Measurement of software quality factors

Understandability

Are variable names descriptive of the physical or functional property represented? Douniquely recognizable functions contain adequate comments so that their purpose isclear? Are deviations from forward logical flow adequately commented? Are all elementsof an array functionally related?

Completeness

Conciseness

Is all code reachable? Is any code redundant? How many statements within loops couldbe placed outside the loop, thus reducing computation time? Are branch decisions toocomplex?

Portability

Does the program depend upon system or library routines unique to a particularinstallation? Have machine-dependent statements been flagged and commented?Has dependency on internal bit representation of alphanumeric or specialcharacters been avoided?

The effort required to transfer the program from one hardware/software systemenvironment to another.

Consistency

Is one variable name used to represent different physical entities in the program? Doesthe program contain only one representation for physical or mathematical constants? Arefunctionally similar arithmetic expressions similarly constructed? Is a consistent schemefor indentation used?'

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 3: UNIT -I - Vidyarthiplus

Developing a Set of Metrics

Quality Models

Why a quality model?

Enables quality comparison both qualitatively andquantitatively

Hierarchical models

considers quality under a series of quality characteristicsor criteria, each having a set of associated measures ormetrics

combined in a hierarchical nature into an overall

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 4: UNIT -I - Vidyarthiplus

assessment of quality

Questions what criteria should be employed? how do they inter-relate? how can they be combined to provide an overall assessment of quality?

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 5: UNIT -I - Vidyarthiplus

McCall’s Model

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 manymore contributions through his involvement in industry and academia.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 6: UNIT -I - Vidyarthiplus

Metrics Measurement and Analysis

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 7: UNIT -I - Vidyarthiplus

THE GOAL QUESTION METRIC APPROACH

The Goal Question Metric (GQM) approach is based upon the assumption that foran

organization to measure in a purposeful way it must first specify the goals foritself and its projects, then it must trace those goals to the data that are intended todefine those goals operationally, and finally provide a framework for interpretingthe data with respect to the stated goals.

Thus it is important to make clear, at least in general terms, what informationalneeds the organization has, so that these needs for information can be quantifiedwhenever possible, and the quantified information can be analyzed a to whetheror not the goals are achieved.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 8: UNIT -I - Vidyarthiplus

The approach was originally defined for evaluating defects for a set of projects inthe NASA Goddard Space Flight Center environment.

The result of the application of the Goal Question Metric approach application isthe specification of a measurement system targeting a particular set of issues anda 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 ofreasons, with respect to various models of quality, from various points of view,relative to a particular environment. Objects of measurement areProducts: Artifacts, deliverables and documents that are produced duringthe 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 theway the assessment/achievement of a specific goal is going to be performed basedon some characterizing model. Questions try to characterize the object ofmeasurement (product, process, resource) with respect to a selected quality issueand to determine its quality from the selected viewpoint.

3. Quantitative level (METRIC): A set of data is associated with every questionin order to answer it in a quantitative way. The data can beObjective: If they depend only on the object that is being measured and noton the viewpoint from which they are taken; E.g., number of versions of adocument, staff hours spent on a task, size of a program.Subjective: If they depend on both the object that is being measured andthe viewpoint from which they are taken; E.g., readability of a text, level ofuser satisfaction.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 9: UNIT -I - Vidyarthiplus

The complete Goal Question Metric model is as follows:

THE GOAL QUESTION METRIC PROCESS

A GQM model is developed by identifying a set of quality and/or productivitygoals, at corporate, division or project level; e.g., customer satisfaction, on-timedelivery, improved performance.

From those goals and based upon models of the object of measurement, we derivequestions that define those goals as completely as possible.

For example, if it is to characterize a software system (e.g., an electronic mailpackage, a word processor) with respect to a certain set of quality issues (e.g.,

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 10: UNIT -I - Vidyarthiplus

portability across architectures), then a quality model of the product must bechosen that deals with those issues (e.g., list of functional features that can beimplemented in different architectures).

The next step consists in specifying the measures that need to be collected inorder to answer those questions, and to track the conformance of products andprocesses to the goals.

After the measures have been specified, we need to develop the data collectionmechanisms, including validation and analysis mechanisms.

CONCLUSIONIn summary, the Goal Question Metric approach is a mechanism for defining andinterpreting 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.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 11: UNIT -I - Vidyarthiplus

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 12: UNIT -I - Vidyarthiplus

UNIT-II

Software Quality Assurance (SQA)

SQA consists of a means of monitoring the software engineeringprocesses and methods used to ensure quality.

It does this by means of audits of the quality management systemunder which the software system is created. These audits are backedby one or more standards, usually ISO 9000.

It is distinct from software quality control which includes reviewingrequirements documents, and software testing.

SQA encompasses the entire software development process, whichincludes processes such as software design, coding, source codecontrol, code reviews, change management, configurationmanagement, and release management.

Whereas software quality control is a control of products, softwarequality assurance is a control of processes.

Tasks

Quality EngineeringThe activity consisting of the cohesive collection of all tasks that areprimarily performed to ensure and help continually improve thequality of an endeavor’s process and work products .

Goals

The typical goals of quality engineering are to:

Ensure that the necessary levels of quality are achieved. Make the achievement of quality predictable and repeatable. Minimize endeavor, organizational, and personal risks due to

poor quality.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 13: UNIT -I - Vidyarthiplus

Objectives

The typical objectives of quality engineering are to:

Define what quality means on the endeavor in terms of a qualitymodel defining quality factors and quality sub factors.

Plan the quality tasks including helping the requirements teamdetermine and specify the quality requirements and associated qualityfactors (attributes) and quality metrics.

Assure the quality of the process used by the endeavor.Thus, quality assurance is concerned with fulfilling the qualityrequirements and achieving the quality factors of the endeavor’sprocess.“Are we building the products right?”

Control the quality of the work products delivered during theendeavor.Thus, quality control is concerned with fulfilling the qualityrequirements and achieving the quality factors of the endeavor’s workproducts.“Are we building the right products?”

Examples

Examples of quality engineering based on scope include:

Application Quality Engineering Business Quality Engineering Contact Center Quality Engineering Data Center Quality Engineering

Preconditions

Quality engineering typically may begin when the following preconditionshold:

The endeavor is started. The quality team is initially staffed and trained in quality engineering.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 14: UNIT -I - Vidyarthiplus

Completion Criteria

Quality engineering is typically complete when the following postconditions hold:

The endeavor is complete.

Tasks

The following diagram illustrates the relationships between the quality tasks:

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 15: UNIT -I - Vidyarthiplus

Plan

The purpose of this Software Quality Assurance Plan (SQAP) is to definethe techniques, procedures, and methodologies that will be used at theCenter for Space Research (CSR) to assure timely delivery of the softwarethat meets specified requirements within project resources.

The use of this plan will help assure the following:

(1) That software development, evaluation and acceptancestandards are developed, documented and followed.(2) That the results of software quality reviews and audits willbe given to appropriate management within CSR. This providesfeedback as to how well the development effort is conformingto various CSR development standards.(3) That test results adhere to acceptance standards.

Teams

The SQA team shall check that the quality is maintained during theproject and that the proper quality procedures are being followed,discovered problems are reported to the Project Management.

The members of the project team must work according to the part(s)of the SQAP that applies to their specific task.

The tasks of the SQA team

For the first phase of the project (UR), the SQA team must see to it that thefollowing documents are properly reviewed internally before they aresubmitted for an external review.

The URD

The SQA team must check whether the URD:

o contains a general description of the software that has to bedeveloped;

o contains requirements on the software to be developed as statedby the client;

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 16: UNIT -I - Vidyarthiplus

o contains constraints on the software to be developed;o contains a priority list of the requirements.

The SPMP

The SQA team must check whether the goals of the project are clearlydescribed. A life cycle approach for the project must be defined. TheSQA team must ensure that the SPMP is realistic by checking:

o the assumptions made during the planning of the project;o restrictions with respect to plan (e.g. availability of members);o external problems (e.g. delivery of PCs, interface card and

drivers). The SCMP

With respect to the SCMP, the SQA team has to check whether thedocument provides procedures concerning:

o CI identificationo CI storageo CI change controlo CI status indication

All documents must have a unique identifier and backups must bemade at least once every three days.

The SQAP

With respect to the SQAP, the SQA team must check wether theSQAP contains:

o Project standardso Review procedureso Problem reporting procedureso Responsibilities of the project members with respect to quality

assurance

Tasks during SR phase

For the second phase of the project (SR), the SQA team must see to it thatthe following documents are properly reviewed internally before they aresubmitted for an external review.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 17: UNIT -I - Vidyarthiplus

The SRD

The SQA team must check whether the SRD:

o contains requirements on the software to be developed, theserequirements must be based on the software requirements statedin the URD;

o contains constraints on the software to be developed, theseconstraints must be based on the software constaint in the URD;

o contains a priority list of the requirements.o contains a traceability matrix.

The SPMP-SR

The SQA team must ensure that the SPMP is realistic by checking:

o the assumptions made during the planning;o restrictions with respect to the planning (e.g. availability of

members);o external problems (e.g. external software/code).

The SCMP-SR

Whith respect to the SCMP, the SQA team must check wether theSCP contains:

o the additional baselines. The SQAP-SR

With respect to the SQAP, the SQA team must check wether theSQAP contains:

o the Tasks of the SQA team during the SR phase.

Tasks during AD phase

For the third phase of the project (AD), the SQA team must see to it that thefollowing documents are properly reviewed internally before they aresubmitted for an external review.

The ADD

The SQA team must check whether the ADD:

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 18: UNIT -I - Vidyarthiplus

o contains an architectural design of the software to be developed,this design must describe a logical model and the interfacesbetween the different classes;

o contains pre and post conditions of the methods in the locicalmodel;

o contains a tracibility matrix where the design is checked to thesoftware requirements in the SRD.

The SPMP-AD

The SQA team must ensure that the SPMP is realistic by checking:

o the assumptions made during the planning;o restrictions with respect to the planning (e.g. availability of

members);o external problems.

The SCMP-AD

Whith respect to the SCMP, the SQA team must check wether theSCMP contains:

o the additional baselines. The SQAP-AD

With respect to the SQAP, the SQA team must check wether theSQAP contains:

o the tasks of the SQA team during the AD phase.

Characteristics of a good QA (Quality Assurnace) Engineer:

• Understanding of business approach and goals of the organization• Understanding of entire software development process• Strong desire for quality• Establish and enforce SQA methodologies, processes and TestingStrategies• Judgment skills to assess high-risk areas of application• Communication with Analysis and Development team• Report defects with full evidence• Take preventive actions• Take actions for Continuous improvement• Reports to higher management

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 19: UNIT -I - Vidyarthiplus

• Say No when Quality is insufficient• Work Management• Meet deadlines

Documentation:

Project documentation may include many kinds of documents (e.g.,plans, task reports,

Project size, criticality (i.e., the severity of the consequence of failureof the system), and complexity are some features that may affect theamount of documentation a project should need.

For example, the design documentation may consist of a singledocument describing both the system architecture and the detailedmodules or it may consist of separate documents for the architectureand subsystems.

The purpose of this section is not to specify how many documentsshould be required.

Rather, this section identifies the information content needed for anyproject and the timeliness of requirements so that the information canbe used by the vendor, the utility, and the NRC reviewers.

Because the NRC reviewers cannot determine the characteristics ofthe software product without substantial technical specifications,project plans, and reports, NRC should specify the technical productsof the vendor that the utility must provide NRC.

Review:

The reviewers will also need to evaluate the installation package,which consists of installation procedures, installation medium (e.g.,magnetic tape), test case data used to verify installation, and expectedoutput from the test cases.

In some instances, the product may already be installed in the utility.NRC should request documentation on the results of installation andacceptance testing.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 20: UNIT -I - Vidyarthiplus

UNITIII

Reliability and Quality Control:

Although the terms reliability and quality are often used interchangeably,there is a difference between these two disciplines.

While reliability is concerned with the performance of a product over itsentire lifetime, quality control is concerned with the performance of aproduct at one point in time, usually during the manufacturing process.

As stated in the definition, reliability assures that components, equipmentand systems function without failure for desired periods during their wholedesign life, from conception (birth) to junking (death).

Quality control is a single, albeit vital, link in the total reliability process.Quality control assures conformance to specifications.

This reduces manufacturing variance, which can degrade reliability. Quality control also checks that the incoming parts and components meet

specifications, that products are inspected and tested correctly, and that theshipped products have a quality level equal to or greater than that specified.

The specified quality level should be one that is acceptable to the users, theconsumer and the public.

No product can perform reliably without the inputs of quality controlbecause quality parts and components are needed to go into the product sothat its reliability is assured.

Quality Tools:

Cause Analysis Tools Tips and tools for the first step to improvement: identifying the cause of a

problem or situation.

Evaluation and Decision-Making Tools Making informed decisions and choosing the best options with a simple,

objective rating system, and determining the success of a project.

Process Analysis Tools How to identify and eliminate unnecessary process steps to increase

efficiency, reduce timelines and cut costs.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 21: UNIT -I - Vidyarthiplus

Seven Basic Quality Tools These seven tools get to the heart of implementing quality principles.

Data Collection and Analysis Tools How can you collect the data you need, and what should you do with them

once they’re collected?

Idea Creation Tools Ways to stimulate group creativity and organize the ideas that come from it.

Project Planning and Implementing Tools How to track a project’s status and look for improvement opportunities.

Seven New Management and Planning Tools Ways to promote innovation, communicate information and successfully

plan major projects.

Seven Basic Quality Tools( Ishikawa's basic tools )

Quality pros have many names for these seven basic tools of quality, firstemphasized by Kaoru Ishikawa, a professor of engineering at TokyoUniversity and the father of “quality circles.”

Start your quality journey by mastering these tools, and you'll have a namefor them too: "indispensable."

1. Cause-and-effect diagram (also called Ishikawa or fishbone chart):Identifies many possible causes for an effect or problem and sorts ideas intouseful categories.

2. Check sheet: A structured, prepared form for collecting and analyzingdata; a generic tool that can be adapted for a wide variety of purposes.

3. Control charts: Graphs used to study how a process changes over time.4. Histogram: The most commonly used graph for showing frequency

distributions, or how often each different value in a set of data occurs.5. Pareto chart: Shows on a bar graph which factors are more significant.6. Scatter diagram: Graphs pairs of numerical data, one variable on each

axis, to look for a relationship.7. Stratification: A technique that separates data gathered from a variety of

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 22: UNIT -I - Vidyarthiplus

sources so that patterns can be seen (some lists replace "stratification" with"flowchart" or "run chart").

Case tools:

Computer-aided software engineering (CASE) is the use of software tools to assistin the development and maintenance of software. Tools used to assist in this wayare known as CASE Tools.

Some typical CASE tools are:

Code generation tools Data modeling tools UML Refactoring tools QVT or Model transformation Tools Configuration management tools including revision control

Preventing, Discovering and Removing Defects

To reduce the number of defects delivered with a software project anorganization can engage in a variety of activities.

While defect prevention is much more effective and efficient in reducing thenumber of defects, most organization conduct defect discovery and removal.

Discovering and removing defects is an expensive and inefficient process. Itis much more efficient for an organization to conduct activities that preventdefects.

Defect Removal Efficiency

If an organization has no defect prevention methods in place then they are totallyreliant on defect removal efficiency.

1. Requirements Reviews up to 15% removal of potential defects2. Design Reviews up to 30% removal of potential defects3. Code Reviews up to 20% removal of potential defects4. Formal Testing up to 25% removal of potential defects

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 23: UNIT -I - Vidyarthiplus

In other words, if your organization is great at defect removal the maximumpercentage of defects your organization can expect to remove is 90%.

If a software project is 100 function points, the total number of maximum(or potential) defects could be 120.

If you were perfect at defect removal your project would still have up to 12defects after all your defect discovery and removal efforts.

The far majority of organization would receive a B (medium) or even a D (poor)at defect removal efficiency.Activity Perfect Medium PoorRequirements Reviews 15% 5% 0%Design Reviews 30% 15% 0%Code Reviews 20% 10% 0%Formal Testing 25% 15% 15%Total Percentage Removed90% 45% 15%

Defect Discovery and Removal

Size in Function PointsTotals Defects Remaining

Points Max Defects Perfect Medium Poor100 120 12 66 102200 240 24 132 204500 600 60 330 5101,000 1,200 120 660 1,0202,500 3,000 300 1,650 2,5505,000 6,000 600 3,300 5,10010,000 12,000 1,200 6,600 10,20020,000 24,000 2,000 13,200 20,400

An organization with a project of 2,500 function points and was aboutmedium at defect discovery and removal would have 1,650 defectsremaining after all defect removal and discovery activities.

The calculation is 2,500 x 1.2 = 3,000 potential defects. The organizationwould be able to remove about 45% of the defects or 1,350 defects.

The total potential defects (3,000) less the removed defects (1,350) equalsthe remaining defects of 1,650.

Defect Prevention

If an organization concentrates on defect prevention (instead of defect detection)then the number of defects inserted or created is much less. The amount of time

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 24: UNIT -I - Vidyarthiplus

and effort required to discover and remove this defects is much less also.

1. Roles and Responsibilities Clearly Defined up to 15% reduction in number ofdefects created2. Formalized Procedures up to 25% reduction in number of defects created3. Repeatable Processes up to 35% reduction in number of defects created4. Controls and Measures in place up to 30% reduction in number of defectscreated

Imagine an organization with items 1 and 2 in place. A project with 100function points would have a potential of 120 defects, but since they havepreventative measures in place, they can reduce the number of potentialdefects by 48 (40% = 25% + 15%).

That makes the potential number of defects 72 compared to 120 with nopreventative efforts.

Assuming that an organization was medium at defect discovery and removalthey could remove 45% of the remaining defects or have 40 remaining whenthe project rolled to production.

Defect Removal Max Defects Prevention Medium100 120 72 40200 240 144 79500 600 360 1981,000 1,200 720 3962,500 3,000 1,800 9905,000 6,000 3,600 1,98010,000 12,000 7,200 3,96020,000 24,000 14,400 7,920

The above table represents the number of defects that an organization that doesitems 1 and 2 above and is medium at discovery and removal.

The problem for estimating defects is multidimensional. First the total number of defects must be estimated. Second the impact of defect prevention needs to be understood and the

estimated number of defects adjusted. Third an assessment needs to be done to understand how many defects can

be discovered and removed by an organization.

Clearly, the fewer number of defects that an organization must discover andremove the better. The way this is accomplished is by better process, a more stable

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 25: UNIT -I - Vidyarthiplus

organization and repeatable processes. The focus of software organizations needsto be on defect prevention instead of defect detection.

Software Reliability Models:

A proliferation of software reliability models have emerged as people try tounderstand the characteristics of how and why software fails, and try toquantify software reliability.

Over 200 models have been developed since the early 1970s, but how toquantify software reliability still remains largely unsolved. Interested readersmay refer to [RAC96], [Lyu95].

As many models as there are and many more emerging, none of the modelscan capture a satisfying amount of the complexity of software; constraintsand assumptions have to be made for the quantifying process.

Therefore, there is no single model that can be used in all situations. Nomodel is complete or even representative.

One model may work well for a set of certain software, but may becompletely off track for other kinds of problems.

Most software models contain the following parts: assumptions, factors, anda mathematical function that relates the reliability with the factors.

The mathematical function is usually higher order exponential orlogarithmic.

Software modeling techniques can be divided into two subcategories: predictionmodeling and estimation modeling. [RAC96] Both kinds of modeling techniquesare based on observing and accumulating failure data and analyzing with statisticalinference

Rayleigh Model

Rayleigh model has been found to be most suitable for predicting reliabilityof software product.

It predicts the expected value of defect density at different stages of lifecycle of the project, once parameters like total number of defects or totalcumulative defect rate and peak of the curve in terms of unit of time for thecurve are decided.

The nature of curve indicates the pattern of defect removal rate in the life

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 26: UNIT -I - Vidyarthiplus

cycle of the project.

The area bounded by the x-axis and the curve is the measure of total defectslikely to be unearthed from the software being developed.

Below is the plot of the Rayleigh Curve plotted for one of our projects:

Rayleigh Curve

05

101520253035

0.05

0.45

0.85

1.25

1.65

2.05

2.45

2.85

3.25

3.65

4.05

4.45

4.85

5.25

5.65

6.05

6.45

6.85

Life cycle stages

Def

ects

/KL

OC

HLD

LLDCODING

UT

IT

Rayleigh plot

The red line indicates the actual defect density observed as against the predictedvalues (brown smooth curve) obtained through a theoretical model. Observeddefect density closely matches with the defect density predicted by the model.

The curve indicates the defect density at the time of system testing as 21 defects.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 27: UNIT -I - Vidyarthiplus

ISO

Unit IV

Quality Management System

Topics covered

1. Concept of quality

2. QMS

3. Elements of qms

4. RAyleigh model

5. Reliability Growth Models

6. Complexity Metrics and Models

7. Customer Satisfaction Analysis

Concept of quality - historical background

The concept of quality as we think of it now first emerged out of TheIndustrial Revolution.

Previously goods had been made from start to finish by The sameperson or team of people, with handcrafting and tweaking.

The product to meet 'quality criteria'. Mass production brought hugeteams of people together to work on specific stages of productionwhere one person would not necessarily complete a product from startto finish.

In The late 1800s pioneers such as Frederick Winslow Taylor andHenry Ford recognize the limitations o the methods being used inmass production at the time and the subsequent varying quality ofoutput.

Taylor established Quality Departments to oversee the quality ofproduction and rectifying of errors, and Ford emphasizedstandardization of design and component standards to ensure astandard product was produced. Management of quality was theresponsibility of the Quality department and was implemented byInspection of product output to 'catch' defects.

Application of statistical control came later as a result of World War

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 28: UNIT -I - Vidyarthiplus

production methods.

Quality management systems are the outgrowth of work done by W.Edwards Deming, a statistician, after whom The Deming Prize forquality is named.

Quality, as a profession and The managerial process associated withThe quality function, was introduced during The second-half of The20th century, and has evolved since then.

Over this period, few other disciplines have seen as many changes asThe quality profession.

The quality profession grew from simple control, to engineering, tosystems engineering.

Quality control activities were predominant in the 1940s, 1950s, and1960s.

The 1970s were an era of quality engineering and The 1990s sawquality systems as an emerging field.

Like medicine, accounting, and engineering, quality has achievedstatus as a recognized profession

Quality Management System (QMS)

Quality Management System (QMS) can be defined as a set ofpolicies, processes and procedures required for planning andexecution (production / development / service) in the corebusiness area of an organization.

QMS integrates the various internal processes within theorganization and intends to provide a process approach forproject execution. QMS enables the organizations to identify,measure, control and improve

The various core business processes that will ultimately lead toimproved business performance.

ELEMENTS OF QUALITY MANAGEMENT SYSTEMS

The standards of ISO 9000 detail 20 requirements for an organization'squality management system in The following areas:

Management Responsibility

Quality System

Order Entry

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 29: UNIT -I - Vidyarthiplus

Design Control

Document and Data Control

Purchasing

Control of Customer Supplied Products

Product Identification and Tractability

Process Control

Inspection and Testing Control of Inspection, Measuring, and TestEquipment

Inspection and Test Status

Control of Nonconforming Products

Corrective and Preventive Action

Handling, Storage, Packaging, and Delivery

Control of Quality Records

Internal Quality Audits

Training

Servicing

Statistical Techniques

The Rayleigh Model Framework

Perhaps The most important principle in software engineering is "do itright The first time."

This principle speaks to the importance of managing quality throughoutThe development process.

The interpretation of the principle, in The context of software qualitymanagement, is threefold:

The best scenario is to prevent errors from being injected into Thedevelopment process.

When errors are introduced, improve the front end of Thedevelopment process to remove as many of them as early aspossible. Specifically, in the context of the waterfall developmentprocess, rigorous design reviews and code inspections are needed.In the Cleanroom methodology, function verification by The teamis used.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 30: UNIT -I - Vidyarthiplus

If the project is beyond the design and code phases, unit tests andany additional tests by the developers serve as gatekeepers for defects toescape the front-end process before the code is integrated into theconfiguration management system (The system library).

In other words, the phase of unit test or pre-integration test (Thedevelopment phase prior to system integration) is The last chance to doit right The "first time."

The Rayleigh model is a good overall model for quality management. Itarticulates The points on defect prevention and early defect removal relatedto The preceding items.

Based on the model, if The error injection rate is reduced, The entirearea under the Rayleigh curve becomes smaller, leading to a smallerprojected field defect rate.

Also, more defect removal at the front end of the development processwill lead to a lower defect rate at later testing phases and duringmaintenance. Both scenarios aim to lower the defects in The latter testingphases, which in turn lead to fewer defects in The field.

The relationship between formal machine-testing defects and fielddefects, as described by The model, is congruent with The famouscounterintuitive principle in software testing by Myers (1979), whichbasically states that The more defects found during formal testing, Themore that remained to be found later.

The reason is that at The late stage of formal testing, error injection ofThe development process (mainly during design and code implementation)is basically determined (except for bad fixes during testing).

High testing defect rates indicate that the error injection is high; if noextra effort is exerted, more defects will escape to The field.

If we use the iceberg analogy to describe the relationship between testingand field defect rates, The tip of The iceberg is the testing defect rate andThe submerged part is The field defect rate.

The size of The iceberg is equivalent to The amount of error injection.By the time formal testing starts, the iceberg is already formed and its sizedetermined.

The larger its tip, the larger The entire iceberg. To reduce thesubmerged part, extra effort must be applied to expose more of The icebergabove The water.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 31: UNIT -I - Vidyarthiplus

The following fig. shows a schematic representation of the iceberg analogy.

Figure Iceberg Analogy—Error Injection, Testing Defects, and LatentDefects

Reliability Growth Models

Although reliability growth models are meant for reliability assessment,they are also useful for quality management at the back end of thedevelopment process.

Models developed from a previous product or a previous release of thesame product can be used to track the testing defects of the current product.

To have significant improvement, the defect arrival rate (or failuredensity) of the current project must fall below the model curve.

The following fig. shows an example from a systems software productdeveloped at IBM Rochester.

Each data point represents a weekly defect arrival rate during the systemtest phase.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 32: UNIT -I - Vidyarthiplus

The defect arrival patterns represented by the triangles and circles indicatetwo later releases of the same product.

Compared to the baseline model curve, both new releases witnessed asignificant reduction in defect rate during the system test phase.

Figure : Reliability Growth Model for Quality Management

As a second example, when another product was just about at the start ofsystem testing, the PTR arrival rates were unusually high compared to themodel.

It was clear that proceeding in a business-as-usual manner would notresult in meeting the product's quality goal. A special quality improvementprogram (QIP) was then pro-posed, evaluated, approved, and swiftlyimplemented.

The QIP involved five extra activities:

1. Blitz testing— "artistic" testing in stressful environments

2. Customer evaluation— customers conducting testing in thedevelopment laboratory

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 33: UNIT -I - Vidyarthiplus

3. Code inspections— additional inspections of error-prone modules,especially routines that are difficult to test such as the errorrecovery/exception handling routines

4. Design reviews— rereview of designs of suspect components andmodules

5. Extension of system test— improvement of test suites and extensionof testing schedules to allow thorough final test execution

Because of the special QIP activities, the product ship date was delayed onemonth. As a result, more than 250 would-be field defects were found andremoved. The field quality of the product, evidenced by field defect arrivalsreported in later years, improved

Complexity Metrics and Models

Thus far the reliability and quality management models we havediscussed are either at the project or the product level.

Both types of model tend to treat the software more or less as a blackbox. In other words, they are based on either the external behavior (e.g.,failure data) of the product or the intermediate process data (e.g., type andmagnitude of inspection defects), without looking into the internal dynamicsof design and code of the software.

The unit of analysis is more granular, usually at the program-modulelevel. Such metrics and models tend to take an internal view and can provideclues for software engineers to improve the quality of their work.

Reliability models are developed and studied by researchers and softwarereliability practitioners with sophisticated skills in mathematics andstatistics; quality management models are developed by software qualityprofessionals and product managers for practical project and qualitymanagement.

Software complexity research, on the other hand, is usually conducted bycomputer scientists or experienced software engineers. Like the reliabilitymodels, many complexity metrics and models have emerged in the recentpast.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 34: UNIT -I - Vidyarthiplus

Lines of Code

The lines of code (LOC) count is usually for executable statements. It isactually a count of instruction statements.

The interchangeable use of the two terms apparently originated fromAssembler program in which a line of code and an instruction statement arethe same thing.

Because the LOC count represents the program size and complexity, it isnot a surprise that the more lines of code there are in a program, the moredefects are expected.

More intriguingly, researchers found that defect density (defects perKLOC) is also significantly related to LOC count.

Early studies pointed to a negative relationship: the larger the modulesize, the smaller the defect rate.

For instance, Basili and Perricone (1984) examined FORTRAN moduleswith fewer than 200 lines of code for the most part and found higher defectdensity in the smaller modules.

Shen and colleagues (1985) studied software written in Pascal, PL/S, andAssembly language and found an inverse relationship existed up to about500 lines.

Since larger modules are generally more complex, a lower defect rate issomewhat counterintuitive.

Interpretation of this finding rests on the explanation of interface errors:Interface errors are more or less constant regardless of module size, andsmaller modules are subject to higher error density because of smallerdenominators.

More recent studies point to a curvilinear relationship between lines ofcode and defect rate: Defect density decreases with size and then curves upagain at the tail when the modules become very large.

For instance, Withrow (1990) studied modules written in Ada for a largeproject at Unisys and confirmed the concave relationship between defectdensity (during formal test and integration phases) and module size.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 35: UNIT -I - Vidyarthiplus

Specifically, of 362 modules with a wide range in size (from fewer than63 lines to more than 1,000), Withrow found the lowest defect density in thecategory of about 250 lines.

Explanation of the rising tail is readily available. When module sizebecomes very large, the complexity increases to a level beyond aprogrammer's immediate span of control and total comprehension.

This new finding is also consistent with previous studies that did notaddress the defect density of very large modules.

Experience from the AS/400 development also lends support to thecurvilinear model. In the example in Figure , although the concave pattern isnot as significant as that in Withrow's study, the rising tail is still evident.

Figure. Curvilinear Relationship Between Defect Rate and Module Size—AS/400 data

The curvilinear model between size and defect density sheds new light onsoftware quality engineering.

It implies that there may be an optimal program size that can lead to thelowest defect rate.

Such an optimum may depend on language, project, product, andenvironment; apparently many more empirical investigations are needed.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 36: UNIT -I - Vidyarthiplus

Nonetheless, when an empirical optimum is derived by reasonablemethods (e.g., based on the previous release of the same product, or basedon a similar product by the same development group), it can be used as aguideline for new module development.

Customer Satisfaction Analysis

What the clients really want is the interpretation and analysis of the datato provide actionable information: What can we learn from it? What actionsdoes it suggest that we take to improve customer satisfaction with what weoffer? The analysis process starts by performing statistical tests to revealrelationships or differences in ratings of the performance on differentproduct and service attributes, and how they affect overall satisfaction. We compare the performance to the peers, utilizing The Benchmarkdatabase to describe how the performance rates on a relative basis. We identify the customers' product and service priorities and wecompare these to their perceptions of the performance through QuadrantAnalysis. We look for gaps in performance versus expectations in The search formajor opportunities for improvement. We augment The analysis of the quantitative survey data with carefulstudy of the qualitative information – the comments and observations madeby The customers. These are an invaluable The of insight into the reasons behind theirratings. In most cases, The analysis is aimed at identifying the key driversof satisfaction – those product or service elements that are most closelyrelated to customer satisfaction.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 37: UNIT -I - Vidyarthiplus

The clients benefit from the perspective of The years of experience witha wide variety of clients. Applying The knowledge,

The goal is to deliver actionable results – information you can use to createchange that will improve The competitive position and The bottom line

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 38: UNIT -I - Vidyarthiplus

UNIT V

QUALITY STANDARDS

Topics Covered:

Need for standards ISO 9000 series ISO 9000-3 series CMM and CMMI Six Sigma Concepts

1.Need for Standards:

Standardization (or standardisation) is the process of agreeing on technicalstandards.

A standard is a document that establishes uniform engineering or technicalspecifications, criteria, methods, processes, or practices. Some standards aremandatory while others are voluntary.

Some standards are defacto, meaning informal practices followed out of convenience,or dejure, meaning formal requirements.

Formal standards bodies such as the International Standard Organisation(ISO) or theAmerican National Standard University are independent of the manufacturers of thegoods for which they publish standards.

The goals of standardization can be to help with independence ofsingle suppliers (commodification), compatibility, interoperability,safety, repeatability, or quality.

In social sciences, including economics, the idea of standardization isclose to the solution for a coordination problem, a situation in whichall parties can realize mutual gains, but only by making mutuallyconsistent decisions.

Standardization is the process for select better choices and ratificatethis consistent decisions, as an obtained standard.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 39: UNIT -I - Vidyarthiplus

Types of standardization process:

Emergence in de facto use: tradition (old standards on countries)and/or domination (Microsoft ex.).

Fixed by a standard body:o in an impositive process: usually in mandatory norms (like

dictatorial Laws).o in a consensus process: usually for voluntary standards

Standardization is defined as: The development and implementation ofconcepts, doctrines, procedures and designs to achieve and maintain therequired levels of compatibility, interchangeability or commonality in theoperational, procedural, material, technical and administrative fields to attaininteroperability

2.ISO 9000 Series:

ISO 9000 is a family of standards for quality management systems. ISO9000 is maintained by ISO, the International Organization forStandardization and is administered by accreditation and certification bodies.

ISO-9001 covers the entire process from product design through after salesservice.

ISO-9002 covers only the manufacture (or a specific service such as aQC/QA laboratory) of the product.

ISO-9003 covers the "final inspection" of the product only.

ISO-9004 is an "Internal Use" standard - it cannot be registered and is notsubject to the third party audits.

ISO-9001:

Some of the requirements in ISO 9001 (which is one of the standards in theISO 9000 family) would include

a set of procedures that cover all key processes in the business; monitoring processes to ensure they are effective; keeping adequate records;

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 40: UNIT -I - Vidyarthiplus

checking output for defects, with appropriate corrective action wherenecessary;

regularly reviewing individual processes and the quality system itselffor effectiveness; and

facilitating continual improvement A company or organization that has been independently audited and

certified to be in conformance with ISO 9001 may publicly state thatit is "ISO 9001 certified" or "ISO 9001 registered."

Certification to an ISO 9000 standard does not guarantee thecompliance (and therefore the quality) of end products and services;rather, it certifies that consistent business processes are being applied.

Although the standards originated in manufacturing, they are nowemployed across a wide range of other types of organizations.

A "product", in ISO vocabulary, can mean a physical object, orservices, or software. In fact, according to ISO in 2004, "servicesectors now account by far for the highest number of ISO 9001:2000certificates - about 31% of the total"

ISO 9001:2000 specifies requirements for a quality management systemwhere an organization needs to demonstrate its ability to consistentlyprovide product that meets customer and applicable regulatory requirements.

It aims to enhance customer satisfaction through the effectiveapplication of the system, including processes for continualimprovement of the system and the assurance of conformity tocustomer and applicable regulatory requirements.

All requirements of this International Standard are generic and areintended to be applicable to all organizations, regardless of type, sizeand product provided.

Where any requirement(s) of this International Standard cannot beapplied due to the nature of an organization and its product, this canbe considered for exclusion.

Where exclusions are made, claims of conformity to this InternationalStandard are not acceptable unless these exclusions are limited torequirements within clause 7, and such exclusions do not affect theorganization's ability, or responsibility, to provide product that meetscustomer and applicable regulatory requirements.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 41: UNIT -I - Vidyarthiplus

ISO-9002:

Developing products to a standard of consistent high quality, corpion Research is arecognised leader in its field and proud to announce its achievement of the covetedISO 9002 quality certification.

The ISO 9002 standard is an emerging global standard for product and processquality, adopted by 91 countries which comprise the International Organisation forStandardisation (ISO).

ISO 9002 is best known to European countries who use the certification as a means ofidentifying companies dedicated to providing a customer with the best product andservice possible.

Scorpion Research has always emphasised its quality through a continuousimprovement program complementing its other quality initiatives. Achieving ISO9002 certification further demonstrates commitment to a consistent level of qualityrecognised under International standards.

According to ISO assessors, the certification process is rigorous and only a minorityof the applicants who strive to become certified are successful on their first audit.Scorpion Research is amongst this minority of organisations that passed the requiredcertification audit on the first assessment demonstrating its consistent emphasistowards a high quality standard.

Certification is an ongoing process and Scorpion Research will undergo regularinternal and external audits by third party ISO assessors in order to retain itscertification. The ISO certification complements the quality program by establishingan externally verified unbiased process of self-monitoring and problem-solving.

Scorpion Research joins firms such as British Telecom, Sony, IBM, Compaq, DigitalEquipment, Xerox, Toshiba and Hewlett-Packard in ISO certification.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 42: UNIT -I - Vidyarthiplus

ISO-9003: I003

This is the least complex and easiest to install of three standards in theISO 9000 series.

This standard is for organizations that do not participate in design anddevelopment, purchasing or have production controls.

It is designed for organizations that only require final inspection andtesting of their products and services to ensure that they have met thespecified requirements.

This system is generally only relevant to simple products and services. It is also an option for organizations that cannot justify the expense of

one of the other systems but still desire a quality management systemfor their organization.

ISO-9004: Your quality system must balance two needs:

Your customers' need to have qualityproducts at a reasonable price.

Your company's need to make qualityproducts at a reasonable cost.

3.ISO9000-3 for software development:

ISO 9000-3 4.4 Software development and design

4.4.1General

Develop and document procedures to control the product designand development process. These procedures must ensure that allrequirements are being met.

Softwaredevelopment

Control your software development project and makesure that it is executed in a disciplined manner.Use one or more life cycle models to helporganize your software development project.Develop and document your software developmentprocedures. These procedures should ensure that:Software products meet all requirements.Software development follows your:Quality plan.Development plan.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 43: UNIT -I - Vidyarthiplus

Software design Control your software design process and makesure that it is performed in a systematic way.Use a suitable software design method.Study previous software design projectsto avoid repeating old mistakes.Design software that is:Easy to test, install, use, and maintain.Safe and reliable when failure could cause:Human injury.Property damage.Environmental harm.Develop and document rules to control:Coding activities.Naming conventions.Commentary practices.Programming languages.Apply configuration management techniques todocument and control the use and review of all:Analysis tools.Design techniques.Compilers and assemblers.Train personnel in the use of such tools and techniques.

4.4.2Design anddevelopmentplanning

Create design and development planning procedures.Your product planning procedures should ensure that:Plans are prepared for each design activity or phase.Responsibility for implementing each plan,activity, or phase is properly defined.Qualified personnel are assigned to theproduct design and development process.Adequate resources are allocated to theproduct design and development process.Plans are updated, and circulated to theappropriate participants, as designs change.

Software designand developmentplanning

Prepare a software development plan. Your plan should bedocumented and approved before it is implemented. Your planshould control:Technical activities.Requirements analyses.Design processes.Coding activities.Integration methods.Testing techniques.Installation work.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 44: UNIT -I - Vidyarthiplus

Acceptance testing.Management activities.Project supervision.Progress reviews.Reporting requirements.Your software development plan should:Define your project.Identify related plans and projects.List your project objectives.Define project inputs and outputs.Define inputs for each project activity.Define outputs for each project activity.Explain how your project will be organized.Explain how your teams will be structured.Explain who will be responsible for what.Explain how subcontractors will be used.Explain how project participants will interact.Explain how all resources will be managed.Discuss project risks and potential problems.Identify important project assumptions.Present your project schedule.Define project phases and dependencies.Specify project time lines and milestones.Introduce your project budget.Describe the work that will be done.Describe each task.Describe the inputs for each task.Describe the outputs for each task.Identify all relevant control strategies.Identify all relevant standards and conventions.Identify all relevant rules and regulations.Identify all relevant practices and procedures.Identify configuration management practices.Identify backup and recovery procedures.Identify archiving procedures.Identify all relevant methods and approaches.Identify methods used to control nonconforming products.Identify methods used to control software development softwareIdentify methods used to control virus protection activities.Identify all relevant tools and techniques.Identify methods used to qualify all tools and techniques.Identify methods used to control all tools and techniques.

4.4.3Organizational

Identify the groups who should be routinely involved in theproduct design and development process, and ensure that their

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 45: UNIT -I - Vidyarthiplus

and technicalinterfaces

design input is properly documented, circulated, and reviewed.

Make sure that your software developmentplan or your subcontractors' plans:Define how the responsibility for software developmentwill be distributed between all participants.Define how technical information will be sharedand transmitted between all participants.Explain how all project participants will provide input.Explain how subcontractors will provide input duringdesign, installation, maintenance, and training.Explain how regulatory authorities will provide inputduring design, installation, maintenance, and training.Explain how help desk staff will provide input duringdesign, installation, maintenance, and training.Explain how other related projects will provide inputduring design, installation, maintenance, and training.Explain how end users will provide input duringdesign, installation, maintenance, and training.Make sure that your customer hasaccepted the responsibility to:Cooperate and support your project.Provide the information you need when you need it.Resolve outstanding issues in a timely manner.Make sure that your customer representative hasbeen given the responsibility and authority to:Clarify requirements and expectations.Answer questions and solve problems.Make and implement agreements.Approve plans and proposals.Establish acceptance criteria.Provide appropriate customer-supplied products.Define and distribute authorities and responsibilities.Schedule joint progress reviews. You andyour customer together should review:Activities.Your developmental activities.Your customer's activities.Your users' activities.Training activities.Conversion activities.Results.Results of verification activities.Results of acceptance tests.Results of conformance evaluations.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 46: UNIT -I - Vidyarthiplus

4.4.4Design input

Develop procedures to ensure that all design-input requirementsare identified, documented, and reviewed; and that all designflaws, ambiguities, contradictions, and deficiencies are resolved.Design input requirements can be classified as follows:Customer expectations.Contractual conditions.Statutory imperatives.Regulatory requirements.Environmental constraints.Safety considerations.Performance standards.Functional specifications.Descriptive prescriptions.Aesthetic preferences.

Softwaredesign input

Design input requirements should be specified by the customer.However, sometimes the customer will expect you to develop thedesign input specification. In this case, you should:Prepare procedures that you can use to develop the designinput specification. These procedures should be documentedand should explain:How interviews, surveys, studies, prototypes, and demonstrationswill be used to develop your design-input specification.How you and your customer will formally agree:To accept the official specification.To accept changes to the official specification.How changes to specifications will be controlled.How prototypes and product demonstrations will be evaluated.How system oriented input requirements will be met throughthe use of hardware, software, and interface technologies.How reviews, evaluations, and other discussionsbetween you and your customer will be recorded.Work closely with your customer in order to avoidmisunderstandings and to ensure that the specification meets thecustomers needs.Express your specification using terms that will makeit easy to validate during product acceptance.Ask your customer to formally approve theresulting design input specification.Your design input specification may address thefollowing kinds of characteristics or requirements:Functional requirements.Reliability requirements.Usability requirements.Efficiency requirements.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 47: UNIT -I - Vidyarthiplus

Maintainability requirements.Portability requirements.Interface requirements.Hardware interface requirements.Software interface requirements.Your design input specification may also needto address the following kinds of requirements:Operational requirements.Safety requirements.Security requirements.Statutory requirements.

4.4.5Design output

Develop procedures to control design outputs.Design outputs are usually documents. They include drawings,parts lists, process specifications, servicing procedures, andstorage instructions. These types of documents are used forpurchasing, production, installation, inspection, testing, andservicing.Design outputs must be expressed in terms that allowthem to be compared with design input requirements.Design output documents must identify those aspects of theproduct that are crucial to its safe and effective operation. Theseaspects can include operating, storage, handling, maintenance,and disposal requirements.Design output documents must be reviewedand approved before they are distributed.Design outputs must be accepted only ifthey meet official acceptance criteria.

Softwaredesign output

Prepare design output documents using standardized methodsand make sure that your documents are correct and complete.Software design outputs can include design specifications,source code, user guides, etc.

4.4.6Design review

Develop procedures that specify how design reviews should beplanned and performed. Design review procedures should:Be formally documented.Ensure that reviews are recorded.Ensure that representatives from all relevantareas are involved in the process of review.

Softwaredesign review

Plan and perform design reviews for software developmentprojects. Your reviews should ensure that all:Design activities and results are reviewed.Product nonconformities are identified and addressed.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 48: UNIT -I - Vidyarthiplus

Process deficiencies are identified and addressed.Review conclusions and observations are recorded.

Softwaredesign reviewprocedures

Develop and document design review procedures.Your procedures should make sure that you:Clarify exactly what is being reviewed.Distinguish between different types of reviews.Organize and schedule design review meetings.Indicate when design reviews should be performed.Maintain a record of all design review meetings.Invite all appropriate groups to participate.Invite customers to participate (when required).Confirm that customers agree with your results.Allow design activities to continue only if all:Deficiencies and nonconformities have been addressed.Risks and consequences have been assessed.Your design review procedures may also:Define the methods that should be used to ensurethat all rules and conventions are being followed.Define what needs to be done to preparefor a design review. This may include:Defining roles.Listing objectives.Preparing an agenda.Collecting documents.Define what should be done during the review.This may include:Defining the guidelines that should be followed.Defining the techniques that should be used.Define the criteria that constitute a successful review.Define the follow-up methods that should be used toensure that all outstanding issues will be addressed.

4.4.7Designverification

Develop procedures that specify how design outputs, at everystageof the product design and development process, should beverified.These procedures should:Verify that outputs satisfy design-input requirements.Ensure that objective evidence is used to verify outputs.Ensure that all design verifications are recorded.Ensure that all design documents are verified.These design verification procedures may also:Use alternative calculations to verify design outputs.Use tests and demonstrations to verify outputs.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 49: UNIT -I - Vidyarthiplus

Compare design outputs with proven designs.

Software designverification

Verify design outputs by:Performing design reviews.Performing demonstrations.Evaluating prototypes.Carrying out simulations.Performing tests.Maintain a record of design verifications.Record verification results.Record remedial actions.Record action completions.Accept design outputs for subsequent use only if they have beenproperly verified and only if all remedial actions have been taken.

4.4.8Designvalidation

Develop procedures that validate the assumption that your newlydesigned products will meet customer needs. Develop designvalidation procedures that:Confirm that your new product performs properlyunder all real-world operating conditions.Confirm that your new product will meet everylegitimate customer need and expectation.Ensure that validations are carried out early in the design processwhenever this will help guarantee that customer needs will bemet.

Softwaredesign validation

Prove that your product is ready for its intendeduse before you ask your customer to accept it.Accept validated products for subsequent use only if they havebeen properly verified and only if all remedial actions have beentaken.Maintain a record of design validations.Record validation results.Record remedial actions.Record action completions.

4.4.9Design changes

Develop procedures to ensure that all product designmodifications aredocumented, reviewed, and formally authorized before theresultingdocuments are circulated and the changes are implemented.

Softwaredesign changes

Develop procedures to control design changes that may occurduringthe product life cycle. Your procedure should ensure that you:

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 50: UNIT -I - Vidyarthiplus

Document the design change.Evaluate the design change.Justify the design change.Verify the design change.Approve the design change.Implement the design change.Monitor the design change.Your configuration management processmay be used to control design changes.

4.CMM and CMMI:

The Capability Maturity Model (CMM), also sometimes referred to asthe Software CMM (SW-CMM).

The CMM is a process capability model based on softwaredevelopment organisation processes/practices.

Though the CMM was retired in 1997 and has not been updated since,having been superseded by CMMI (Capability Maturity ModelIntegration), it has been used as a generally applicable model to assistin understanding the process capability maturity of organisations indiverse areas.

For example, software engineering, system engineering, projectmanagement, risk management, system acquisition, informationtechnology (IT) or personnel management, against a scale of fivematurity levels, namely: Initial, Repeatable, Defined, Managed andOptimized.

The Capability Maturity Model (CMM) is a process capabilitymaturity model which aids in the definiton and understanding of anorganisation's processes.

The CMM was originally used to enable the assessment of softwaredevelopment processes.

The SEI’s Capability Maturity Model (CMM) and Capability MaturityModel Integrated (CMMI) are the most prominent examples of amodel based approach to process improvement.

The CMM is limited to management and software engineeringpractices. The CMMI expands the CMM to address systemsengineering and integrated product development as well.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 51: UNIT -I - Vidyarthiplus

The CMMI is organized around a set of Process Areas (PAs).

The PAs are divided into groups associated with what are calledmaturity levels. In the CMMI, most basic management practices areconsidered part of maturity level 2, while most software engineeringpractices are associated with level 3.

Level 4 is about process and product quality management, while level5 includes processes for process optimization and technology changemanagement.

An organization that has practices that meet all the goals of maturitylevel 2 is characterized as a level 2 organization.

An organization that cannot demonstrate that its practices meet all theapplicable level 2 goals is considered level 1 by default.

An organization that meets the goals of all the PAs at level 2 and level3 is a level 3 maturity organization and so on.

The CMMI also offers an alternate approach call the "continuousrepresentation", where individual PA's are rated on a maturity scale of1 - 5. This allows the organization the flexibility to tailoring itsmaturity goals based on business needs for particular PA's.

As organizations move up the maturity ladder, they are more likely toproduce higher quality products with more predictable costs and cycletimes. The higher levels are more likely to correlate with higherproductivity and shorter cycle times as well.

The idea of model based software improvement is very simple. Firstpick the applicable Process Areas.

Next perform an assessment of organizational practices relative to themodel.

The organization practices do not have to conform exactly to therepresentative practices included in the model.

They just have to meet the stated goals of each PA.

Based on this comparison, assign a maturity level to the organizationand produce a list of strengths and weakness relative to the model.

The output of the assessment is used to prioritize areas forimprovement. The idea is to improve deficient practices at the lowermaturity levels first and systematically move up in maturity level overtime using additional assessments to measure progress.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 52: UNIT -I - Vidyarthiplus

Focusing on the lowest level practices puts a firm foundation in placebefore tacking the higher level processes and it give the organizationtime to internalize the changes.

This approach nicely avoids the twin problems of putting practices inplace before required supporting practices are available and trying todo too much too soon.

So model based improvement has a lot of very attractive features.One of the most attractive ones is the level goal itself.

The numerical level gives organizations a metric that that can beeasily understood, can used to measure progress, and can used tobenchmark against other organizations.

SEI has defined a formal appraisal methodology and provided a leadassessor training and certification program.

This means that assessment results, particular those obtained using athird party assessor, will be reasonably consistent and can be used tobenchmark against other organizations.

In fact SEI maintains a publicly accessible database of assessmentresults giving the number of organizations at each level by industryand the average time for an organization to improve from one level tothe next.

6. Six Sigma Concept:

Six Sigma at many organizations simply means a measure of quality thatstrives for near perfection. Six Sigma is a disciplined, data-driven approachand methodology for eliminating defects (driving towards six standarddeviations between the mean and the nearest specification limit) in anyprocess -- from manufacturing to transactional and from product to service.

The statistical representation of Six Sigma describes quantitativelyhow a process is performing.

To achieve Six Sigma, a process must not produce more than 3.4defects per million opportunities.

A Six Sigma defect is defined as anything outside of customerspecifications.

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 53: UNIT -I - Vidyarthiplus

A Six Sigma opportunity is then the total quantity of chances for adefect. Process sigma can easily be calculated using a Six-Sigmacalculator.

The fundamental objective of the Six Sigma methodology is theimplementation of a measurement-based strategy that focuses onprocess improvement and variation reduction through the applicationof Six Sigma improvement projects.

This is accomplished through the use of two Six Sigma sub-methodologies: DMAIC and DMADV. The Six Sigma DMAICprocess (define, measure, analyze, improve, control) is animprovement system for existing processes falling below specificationand looking for incremental improvement.

The Six Sigma DMADV process (define, measure, analyze, design,verify) is an improvement system used to develop new processes orproducts at Six Sigma quality levels.

It can also be employed if a current process requires more than justincremental improvement.

Both Six Sigma processes are executed by Six Sigma Green Belts andSix Sigma Black Belts, and are overseen by Six Sigma Master BlackBelts.

Six Sigma is a set of practices originally developed by Motorola tosystematically improve processes by eliminating defects.

A defect is defined as nonconformity of a product or service to itsspecifications.

While the particulars of the methodology were originally formulated by BillSmith at Motorola in 1986, Six Sigma was heavily inspired by six precedingdecades of quality improvement methodologies such as quality control,TQM, and Zero Defects. Like its predecessors, Six Sigma asserts thefollowing:

Continuous efforts to reduce variation in process outputs is key tobusiness success

Manufacturing and business processes can be measured, analyzed,improved and controlled

Succeeding at achieving sustained quality improvement requirescommitment from the entire organization, particularly from top-levelmanagement

www.Vidyarthiplus.com

www.Vidyarthiplus.com

Page 54: UNIT -I - Vidyarthiplus

Sigma (the lower-case Greek letter σ) is used to represent standard deviation(a measure of variation) of a population (lower-case 's', is an estimate, basedon a sample).

The term "six sigma process" comes from the notion that if one hassix standard deviations between the mean of a process and the nearestspecification limit, there will be practically no items that fail to meetthe specifications.

This is the basis of the Process Capability Study, often used by qualityprofessionals.

The term "Six Sigma" has its roots in this tool, rather than in simpleprocess standard deviation, which is also measured in sigmas.

Criticism of the tool itself, and the way that the term was derived fromthe tool, often sparks criticism of Six Sigma.

www.Vidyarthiplus.com

www.Vidyarthiplus.com