Unit-5 Quality Management

The Software Dilemma

Any time software and business come together, there is an inherent conflict between “get

it done fast” and “do a good job”. This conflict often comes to a head when deadlines are

missed, whether through unrealistic expectation or underestimation on the part of the

developers.

The dilemma between quantity, speed and feature set isn’t going to go away any time

soon. It’s an inherent dilemma in software. But there are approaches we can take to help

solve it.

Any software project has three core elements: the speed at which the software ships, the

fidelity of the feature set, and the quality of the underlying code base. In a perfect world,

we’d be right in the middle, like so:

The triangle makes clear that as you move towards one goal, you tend to move away from

the others. Pushing for speed, for example, sacrifices quality and feature fidelity to some

degree.

And yet, often its impossible to live completely in the center of the triangle. After all, there

are deadlines to be met, and sometimes we need to push software out, even while

incurring technical debt. But leaving the center of the triangle does not necessarily mean

project ruin.

Imagine that the triangle has concentric zones. The outermost zone is a danger zone,

where one priority is overemphasized to the detriment of all others. Inside that zone is a

warning area, an area where a project can live temporarily, or even for a longer period of

time, before things begin to go wrong. This area might represent short pushes in one

direction or another for the good of the project or the company. And of course in the

center of the triangle is a “green zone”, where all priorities are largely equal in value to the

organization and the team.

Notice how the widest and largest area is the danger zone around the outside of the

triangle. The inner core of warning and good are smaller. This is only natural: it’s easy in a

software project to move too far off the safe ground, and too far towards one of the

corners of the triangle.

We haven’t really explored the pitfalls of moving too far in one direction, so let’s take a

look at each potential individually.

The need for speed

One of the most common things that developers hear from upper management is, “we

need to ship, and we need to ship now!” The need to ship a product to the greater market

is understandable, but can be misguided if we move too far away from the fidelity of the

features or the qualtiy of the code. The effects may not be felt for some time, but at the

end of the day, they will be felt, and usually with terrible consequences.

What happens when you sacrifice everything else for speed? You begin to incur something

called “technical debt.” This is the weight of poor decisions made in the sacrifice of quality

and feature set to speed. And that debt, like any debt, must be paid down eventually. The

“interest” on the debt is longer lead times to implement new features in the future. And

the payments can sometimes be so high that you end up in “bankruptcy” – a position

where the code is so disasterous that it must be cleaned up at the expense of all new

feature work.

Of course there are times when “damn the torpedoes, full speed ahead” is called for. From

time to time shipping something to match a competitor is essential. Other times you may

need to patch a vulnerability or a serious bug. These are valid uses of speed over all other

considerations, and should be used sparingly.

A focus on features

One company I worked for had this plan to ship a piece of software that was at feature

parity with all existing software in the field. They insisted that each feature be able to do

everything that all their competitors features did. The end result? The product never

shipped and the company inevitably went out of business.

Feature parity with existing software is a fool’s game. You end up chasing a moving target

and never really focusing on what makes you special. Similarly, expecting that you’ll ship

every single feature you can conceivably think of is a foolish enterprise as well. Multi-

billion dollar companies (think Apple) have shipped with incomplete feature sets only to

make modest improvements later on. Surely you can do the same thing.

Death by Code Quality

I am a huge fan of code quality, and I push for code reviews and code quality analysis as a

core part of my business and a core part of the development process. But it’s possible to

have too much code quality focus in your code.

Code quality focus becomes onerous when you start focusing on it at the expense of

everything else. When code quality becomes a goal in and of itself, feature development

halts and we’re ultimately never going to ship. Code quality for its own sake is a dangerous

game, and one with serious consequences.

Any project will take on certain levels of technical debt in order to function. Some design

decisions won’t be perfect or pure. That’s okay. But the developer who insists that no

technical debt be taken and no corners ever be cut will find herself quickly holding

together a failing project, because the end result will be a perfect monstrosity that doesn’t

accomplish any of the goals of the company.

Striking A Balance

In every project it’s crucial to strike a balance. It’s important that every team understand

the business needs of the project, alongside the technical needs of the project. Moreover,

hiring a well-rounded team that includes business-focused programmers, creative

developers and code purists helps ensure a healthy balance of developers all the way

around.

For example, on a well-balanced team the business focused developer will understand the

need to ship early and often and push on this central theme. Balancing him will be a

creative engineer that suggests a new feature that could be incorporated. He convinces

the business-minded developer and they together present it to a manager. Meanwhile the

code purist has found several places for refactoring and recommends that we do them

because they’ll make the product faster. Management likes this idea too, and agrees. All

elements of the team are working, and no one area is overly represented.

Building this kind of team is hard, but worthwhile. Developer managers would do well for

themselves to invest heavily in finding these right people and putting them in the right

positions to have an impact.

ACRONYMS

CMMICapability Maturity Model Integration

CoSQCoSQ Cost of Software Quality

COTSCommercial Off-the-Shelf Software

FMEAFailure Mode and Effects Analysis

FTAFault Tree Analysis

PDCAPlan-Do-Check-Act

PDSAPlan-Do-Study-Act

QFDQuality Function Deployment

SPISoftware Process Improvement

SQASoftware Quality Assurance

SQCSoftware Quality Control

SQMSoftware Quality Management

TQMTotal Quality Management

V&VVerification and Validation

Element of Software Quality Assurance

1. Planning The success of a project largely depends on the amount of thoughtful process applied to plan it. Whatever be the task " be it big or small, it is important to plan for it. List the activities involved in the task, and lay down the various milestones that need to be achieved.

Of course, in doing that, it is important to understand the customer's requirement clearly. Deliberate on the customer's requirement, get your understanding confirmed from the customer, and then prepare a plan.

Nowadays, the emphasis is on making use of agile methods for planning. The customer requirements may change every now and then; your plan should be able to adapt to those changes quickly and easily.

To prepare a realistic plan, making use of past data (collect metrics for the products developed earlier), and the resources that you have in hand.

Figure 1: Planning for a project

Using historical data for planning will lead to better estimates. Your aim should be to reduce the gap between the "estimated time" and the "actual time spent" for an activity.

One can use a Work Breakdown Structure (WBS) to chart out the Project Plan. The entire project is divided into various set of activities, which are then broken down into various sub-activities as shown in Figure 2 below.

2: Breaking a task into sub-tasks

2. CommitmentIn software development, commitment is an agreement between an organization and the customer, where the organization promises to fulfill some or all the requirements of the customer.

When making such a commitment, it is important to not over-commit to the customer. Do not promise more than what you can deliver. Wouldn't itt be better to under-promise, but deliver more?

3. Tracking of tasksTrack your tasks on regular basis. Set specific daily/weekly targets. Tools like Gantt Chart can be used to monitor the project progress and keep a track of the various milestones achieved/to be achieved. While monitoring the tasks, ask the following questions:

* Is my task on schedule? Check the deadlines. * Is there any delay? If yes, then why? Were there any unforeseen issues? What could have been done to avoid such a case in future? [Please note that deliberating on these points would help you in making future estimations]* Do I need to re-evaluate my plan?

In case the project progress is not as per schedule, update the plan. Reschedule the plan, using the lessons learnt. And always keep the customer informed of the status.

You should see to it that there is no rushing to complete tasks at the eleventh hour. Avoid last minute panic. Last minute scribbling may fetch you some marks in the exams, but can prove costly when applied in the software development.

4. Being honestBe honest to yourself and the customers. Never get tempted to please the customer, by providing false information.

Do not try to sweep things under the carpet. Whatever be the status, your customer must be promptly informed. Hiding facts will have disastrous consequences in the long run.

5. Humility and CourageHumility and courage are vital components in developing any high quality product. You must be ready to accept your mistakes, and have the courage to learn and improve upon them. As "human resources," we need to improve continuously.

Goals, Attributes, and Metrics:

Requirement quality : The correctness, completeness, and consistency of the

requirements model will have a strong influence on the quality of all work products

that follow. SQA must ensure that the software team has properly reviewed the

requirements model to achieve a high level of quality.

Design quality : Every element of the design model should be assessed y the

software team to ensure that it exhibits high quality and that the design itself

conforms to requirements.

Code quality : Source code and related work products must conform to local

coding standards and exhibit characteristics that will facilitate maintainability.

Quality control effectiveness : A software team should apply limited resources in

a way that has the highest likelihood of achieving a high–quality result. SQA

analyzes the allocation of resources for reviews and testing to assess whether they

are being allocated in the most effective manner.

Software quality goals, attributes, and metrics

Goal Attribute Metric

Requirement  quality Ambigully Number of ambiguous modifiers

(e.., many, large, human–friendly)

Completeness Number of TBA, TBD

Understandability Number of sections/subsections

Volatility Number of changes per

requirement Time (by activity)

when change is requested

Traceability Number of requirements not

traceable to design/code

Model clarity Number of UML models

Number of descriptive pages per

model

Number of UML errors

Design quality Architectural

integrity

Component

completeness

Interface

complexity

Patterns

Existence of architectural model

Number of components that trace

to architectural model

Complexity of procedural design

Average number of pick to get to a

typical function or content

Layout appropriateness

Number of patterns used

Code quality Complexity

Maintainability

Understandability

Reusability

Documentation

Cyclomatic complexity

Design factors (Chapter 8)

Percent internal comments

Variable naming conventions

Percent reused components

Readability index

QC effectiveness Resource

allocation

Completion rate

Review

effectiveness

Testing

effectiveness

Staff hour percentage per activity

Actual vs. budgeted completion

time

See review metrics

Number of errors found and

criticality

Effort required to correct an error

Origin of error

What Is Meant By Formal Approaches To SQA ?

Software Quality Assurance (SQA) is defined as a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures.SQA includes the process of assuring that standards and procedures are established and are followed throughout the software acquisition life cycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits. Software development and control processes should include quality assurance approval points, where an SQA evaluation of the product may be done in relation to the applicable standards. Software Quality Assurance is an umbrella of activities that is applied throughout the software process. SQA encompasses the following:

1. A quality management approach

2. Effective software engineering technology (methods and tools)

3. Formal technical reviews that are applied throughout the software process

4. A multi-tiered testing strategy

5. Control of software documentation and the changes made to it.

6. A procedures to assure compliance with the software development standards7. Measurements and reporting mechanisms

Quintessential features of Six Sigma Quality Assurance

Six Sigma quality assurance approach and methods have definitely set a

benchmark for excellence. It has been done by simply raising the standards of

quality through implementation of a methodical quality management

approach. Quality system suggested by Six Sigma has created quite a buzz in

almost every industry including healthcare, retail, BPO etc. Such state-of-the-art

methods are developed with the sole objective of testing the important products

and services to ensure that they are fulfilling the criteria of desired standards and

customer’s expectations pertaining to the products are successfully met. With the

ever increasing demand of quality products, Six Sigma quality management has

become the prime concern for organizations all over the world for survival and

profitability.

Six Sigma Green Belt approach is not only about ensuring quality in production, but also about promising and delivering quality. Promising quality is all about assuring the vital customers that the services and products being provided are of best quality. For delivering quality consistently, it is of paramount importance to adapt to the industry-approved testing techniques and methodologies. It is the job of quality assurance office to look after all such aspects of product development and deliver excellence. Let’s have a look at the roles and responsibilities of a quality assurance officer-

Time • Budget • Less use of quality standards • Lack of specialists • Project durations • Compromise on quality due to less profit • Developer’s attitude • Team formation for requirements gathering • PoliticsTime • Budget • Less use of quality standards • Lack of specialists • Project durations • Compromise on quality due to less profit • Developer’s attitude • Team formation for requirements gathering • Politics

Roles and Responsibilities of Quality Assurance Officer

1. He is responsible to ensure the quality of products and services; and thereby take care of the entire process of QA in software development cycle.

2. It is a quality assurance officer’s lookout to maintain the high standards of a product or service.

3. One of the most important responsibilities is that he has to improve the already set QA standards that are already set.

4. He is also responsible to over-view sales statistics and check out the possible drops in sales because of not-so-good quality of products and services.

5. It is the responsibility of the QA officer to make sure that the definition of quality is understood by all the employees to achieve the common goal.

6. With the passage of time, the quality assessment and testing techniques

have undergone revolutionary changes. Therefore, it becomes crucial for a

QA office to stay current and updated with the recent product launches,

seminars and workshops in quality management domain. This practice can

play a good role in maintaining the technical knowledge and keep up with

the rapidly growingQA standards. Often people consider quality control

and quality assurancethe same. In reality, there is a subtle difference in both

the methods. As per thequality management system experts, quality control

has more emphasis on the product concerned. On the other hand, QA is all

about focusing on the process of developing it.

7. Difference between Quality Control and Quality Assurance

Quality Control

Well... quality control is considered as a system. It is comprised of routine processes and activities, which are specifically aimed to measure and control the overall quality of the concerned product and service. It also involves accuracy check to ensure zero-error in data calculations and estimating the uncertainties. The quality assurance check should be regular. This is how the QC system can ensure data correctness, completeness and also the integrity. One major part of QC is to distinguish errors and rectify them.

Quality Assurance

As mentioned above QA is a process, which is executed to meet the expectations

of customers. There is a set of steps which are followed in order to attain the

quality management goals. Six Sigma QA approach and quality infrastructure are

gaining sky rocketing popularity in this domain as it is known to make use of a

planned and systematic process for quality checks. It is done to prevent defects.

Today, a lot of emphasis is laid and will continue to be laid, on the pursuit of

perfection, to improve quality. Ideally, businesses are heading towards a zero-

defect world. In achieving this perfection, a quality assurance officer will play a

crucial part, directly or indirectly.

Nowadays, every individual and business is on a constant pursuit of perfection. Hence, lot of emphasis is laid on quality of products and services delivered. There will be no exaggeration in stating that the modern business is naturally heading to a world with zero-defect. In such a scenario, quality assurancemethod can work wonders. Already, there is a huge demand for Software quality assurance, and its demand is rapidly growing in other industries as well.

ISO 9000 vs. 9001

ISO 9000 is a series, or family, of standards. ISO 9001 is a standard within the family. The ISO 9000 family of standards also contains an individual standard named ISO 9000. This standard lays out the fundamentals and vocabulary of quality management systems (QMS).

ISO 9000 Series standards

The ISO 9000 family contains these standards:

ISO 9001:2015: Quality management systems - Requirements ISO 9000:2015: Quality management systems - Fundamentals and

vocabulary (definitions)

ISO 9004:2009: Quality management systems – Managing for the sustained success of an organization(continuous improvement)

ISO 19011:2011: Guidelines for auditing management systems

ASQ is the only place to get the American National Standard versions of these standards in the ISO 9000 family.

ISO 9000 certification

Individuals and organizations cannot be certified to ISO 9000. ISO 9001 is the only standard within the ISO 9000 family to which organizations can certify.

ISO 9000:2000

ISO 9000:2000 refers to the ISO 9000 update released in the year 2000.

The Technical Committee responsible for the ISO 9000 family developed specifications for the ISO 9000:2000 revisions, leading to a significant advancement of the standards and reflecting contemporary concepts of quality management.

The ISO 9000:2000 revision had five goals:

1. Meet stakeholder needs2. Be usable by all sizes of organizations

3. Be usable by all sectors

4. Be simple and clearly understood

5. Connect quality management system to business processes

(From ISO 9000:2000 Shifts Focus of Quality Management System Standards, by Jack West.)

ISO 9000:2000 was again updated in 2008 and 2015. ISO 9000:2015 is the most current version.

ISO 9000 principles of quality management

The ISO 9000:2015 and ISO 9001:2015 standards are based on seven quality management principles that senior management can apply for organizational improvement:

1. Customer focuso Understand the needs of existing and future customers

o Align organizational objectives with customer needs and expectations

o Meet customer requirements

o Measure customer satisfaction

o Manage customer relationships

o Aim to exceed customer expectations

Learn more about the customer experience and customer satisfaction.

2. Leadershipo Establish a vision and direction for the organization

o Set challenging goals

o Model organizational values

o Establish trust

o Equip and empower employees

o Recognize employee contributions

Learn more about leadership and find related resources.

3. Engagement of peopleo Ensure that people’s abilities are used and valued

o Make people accountable

o Enable participation in continual improvement

o Evaluate individual performance

o Enable learning and knowledge sharing

o Enable open discussion of problems and constraints

Learn more about employee involvement.

4. Process approacho Manage activities as processes

o Measure the capability of activities

o Identify linkages between activities

o Prioritize improvement opportunities

o Deploy resources effectively

Learn more about a process view of work and see process analysis tools.

5. Improvemento Improve organizational performance and capabilities

o Align improvement activities

o Empower people to make improvements

o Measure improvement consistently

o Celebrate improvements

Learn more about approaches to continual improvement.

6. Evidence-based decision makingo Ensure the accessibility of accurate and reliable data

o Use appropriate methods to analyze data

o Make decisions based on analysis

o Balance data analysis with practical experience

See tools for decision making.

7. Relationship managemento Identify and select suppliers to manage costs, optimize resources, and create

value

o Establish relationships considering both the short and long term

o Share expertise, resources, information, and plans with partners

o Collaborate on improvement and development activities

o Recognize supplier successes

What is the Test Management Reviews & Audit?

Management Review: Management Review is also known as Software Quality Assurance or (SQA). It focuses more on the software process rather than the software work products. Quality Assurance is a set of activities designed to ensure that the project manager follows the standard process which is already pre-defined. In other words, Quality Assurance makes sure the Test Manager is doing the right things in the right way.

Audit: An audit is the examination of the work products and related information to assesses whether the standard process was followed or not.

Why do we need SQA in Test Management pro

As a Test Manager, you are the person who takes in charge these activities. However,you are at the highest position in the project team. Who will review your tasks and check the project management activities are executed to the highest standard?

Well, SQA auditor is the person who reviews and checks the project management activities are executed to the highest possible standard. Only through the result of this review, the Management Board can evaluate the quality of your project handling.

This is the reason why we do need Management Review or SQA in Test Management process.

The SQA interviews you, the Test Manager, to benchmark the project against set standards.

Benefits of SQA are -

1) Develop SQA Plan

Testing activity needs Test Plan likewise SQA activity also needs a plan which is called SQA plan.

The goal of SQA plan is to craft planning processes and procedures to ensure products manufactured, or the service delivered by the organization are of exceptional quality.

During project planning, Test Manager makes an SQA plan where SQA audit is scheduled periodically.

Step 1.1) Identify the role and responsibilities of SQA team

In a project team, every member must have responsibility for the quality of his or her work. Each person has to make sure their work meet the QA criteria.

The SQA team is the group of person who plays the major role in the project. Without QA, no business will run successfully. Therefore, the Test Manager has to make clear the responsibility of each SQA member in SQA plan as below:

Review and evaluate the quality of project activities to meet the QA criteria

Coordinate with management board and project teams to assess requirements and engage in project review and status meetings.

Design track and collect metrics to monitor project quality.

Measure the quality of product; ensure the product meet the customer expectations.

For example, in the SQA Plan of the project Guru99 Bank, you can create the list members of SQA team as below

PeterSQA

Leader

Develop and document quality standard and process for all management process

Manage software quality assurance activities for the project

2 JamesSQA auditor

Perform SQA tasks, report to SQA leader the result of SQA review.

3 BeanSQA auditor

Perform SQA tasks, report to SQA leader the result of SQA review.

Step 1.2) List of the work products that the SQA auditor will review and audit

The Test Manager should

List out all the work products of each Test Management Process

Define which facilities or equipment the SQA auditor can access to perform SQA tasks such as process evaluations and audits.

For example, for the project Guru99 Bank, you can list out the work products of each Test Management Process and define permission for SQA members to access these work products as per the following table

Step 1.2) List of the work products that the SQA auditor will review and audit

The Test Manager should

List out all the work products of each Test Management Process

Define which facilities or equipment the SQA auditor can access to perform SQA tasks such as process evaluations and audits.

For example, for the project Guru99 Bank, you can list out the work products of each Test Management Process and define permission for SQA members to access these work products as per the following table

Create the schedule to perform the SQA tasks

In this step, the Test Manager should describe the tasks to be performed by SQA auditor with special emphasis on SQA activities as well as the work product for each task.

Test Manager also creates the scheduling of those SQA tasks. Normally, the SQA schedule is driven by the project development schedule. Therefore, an SQA task is performed in relationship to what software development activities are taking place.

In the SQA plan, Test Manager makes the schedule for management review. For example

*****************************THE END**************************