Mr.Ghanshyam Dhomse (घनश्याम ढोमसे)



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:

[pic]

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.

[pic]

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

CMMI

Capability Maturity Model Integration

CoSQ

CoSQ Cost of Software Quality

COTS

Commercial Off-the-Shelf Software

FMEA

Failure Mode and Effects Analysis

FTA

Fault Tree Analysis

PDCA

Plan-Do-Check-Act

PDSA

Plan-Do-Study-Act

QFD

Quality Function Deployment

SPI

Software Process Improvement

SQA

Software Quality Assurance

SQC

Software Quality Control

SQM

Software Quality Management

TQM

Total Quality Management

V&V

Verification and Validation

[pic]

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.

[pic][pic]

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. Commitment

In 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 tasks

Track 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 honest

Be 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 Courage

Humility 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 |Existence of architectural model |

| |Component completeness |Number of components that trace to architectural model |

| | |Complexity of procedural design |

| | |Average number of pick to get to a typical function or content |

| |Interface complexity |Layout appropriateness |

| | |Number of patterns used |

| | | |

| |Patterns | |

|Code quality |Complexity |Cyclomatic complexity |

| |Maintainability |Design factors (Chapter 8) |

| |Understandability |Percent internal comments |

| | |Variable naming conventions |

| |Reusability |Percent reused components |

| |Documentation |Readability index |

|QC effectiveness |Resource allocation |Staff hour percentage per activity |

| |Completion rate |Actual vs. budgeted completion time |

| |Review effectiveness |See review metrics |

| |Testing effectiveness |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

[pic]

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

• Politics

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

• 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.

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.

[pic]

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 needs

2. 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 focus

o 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. Leadership

o 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 people

o 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 approach

o 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. Improvement

o 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 making

o 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 management

o 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

[pic]

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 -

[pic]

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

| |Peter |SQA Leader |Develop and document quality standard and process for all management process |

| | | |Manage software quality assurance activities for the project |

|2 |James |SQA auditor |Perform SQA tasks, report to SQA leader the result of SQA review. |

|3 |Bean |SQA 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**************************

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download