slike môn thu thập và phân tích yêu cầu nguyễn ngọc tú chương 7 tích hợp hướng tới chất lượng

Requirement
Engineering
Lesson 07:
An Integrated Quality
Approach
It’s not just a simple matter of
writing down what the customer
says he wants !!!
Lecturer: Nguyễn Ngọc Tú
Email:

Web: sites.google.com/site/kythuatthuthapyeucauphanmem/
Learning Outcomes
 Identify the connection between meeting customers’
real requirements and a quality approach
2012.08
Requirement Engineering
2
Issues
 Quality standards are worthwhile.
 Quality initiatives are difficult to sustain.
 do not share commitment
2012.08
Requirement Engineering
3
[1] chapter 08, p169
focusing on meeting customers’ real needs
Quality is the way we work
Outline
 Business Drivers for Quality
 Management’s Role

 Guiding Principles
 Priority Management
 The Components of an Integrated Quality Approach
 Quality Improvement Techniques
 The PDCA Cycle
 How to Design a Process
 Teamwork
 Case Study: An Example of Quality Improvement
Sidetracked
2012.08
Requirement Engineering
4
[1] chapter 08
Business Drivers for Quality
 A set of drivers exists that may be considered high-level
customer requirements:
 Continued business success;
 High-quality products or services;
 Meeting customer requirements;
 Cost reduction;
 Customer and employee loyalty;
 Improved performance;
 Defect removal;
 Efficiency;
 Reduced cycle time;
 Innovative solutions.
2012.08
Requirement Engineering
5
Management’s Role

 Strategic goals and business drivers are linked to
process improvement goals and activities
 Values and guiding principles are documented and
communicated, and senior management sets its
expectation that all levels of the organization will abide
by these principles in their daily work habits.
2012.08
Requirement Engineering
6
Management’s Role
 Define strategic goals, such as revenue, profit, customer
satisfaction, and employee retention;
 Enable process improvement (PI):
 Act as sponsor and advocate of PI;
 Verbalize the value and results of PI;
 Provide resources for PI;
 Establish an improvement cycle
 Establish values, such as the following
 Focus on fixing the process, not the people;
 Measure and periodically update the processes in use;
 Promote continuous improvement as essential to maintain and
grow the organization;
 Promote the view that the organization’s people are its most
important resource.
2012.08
Requirement Engineering
7
Management’s Role
 Make timely decisions;
 Determine areas that (a) matter most to customers, and (b)

need improvement, such as the following:
 Providing competitive solutions;
 Taking ownership of projects;
 Being flexible concerning working arrangements;
 Responding well to changes;
 Being responsive;
 Employing high-quality people;
 Providing good value;
 Meeting commitments;
 Listening well and understand needs;
 Being competent.
2012.08
Requirement Engineering
8
Guiding Principles
 a set of values that serve to provide high and effective
standards for how things are to be done
 For example:

Customer satisfaction is imperative for our continued
existence.

We will manage by fact (using data) rather than by
intuition or by the seat of our pants.

We have a set of rules of conduct used by the people in our
organization that reflect respect for people.

Continuous improvement is essential for all of our
processes.

2012.08
Requirement Engineering
9
Priority Management
2012.08
Requirement Engineering
10
The Components of an Integrated
Quality Approach
2012.08
Requirement Engineering
11
Quality Improvement Techniques
 the most effective approach is do it from the top and
implement these techniques across all projects.
 To establish a quality management board (QMB)
 implement plans for improvement and provide needed
resources and skills
2012.08
Requirement Engineering
12
Quality Improvement Techniques
2012.08
Requirement Engineering
13
Quality Improvement Techniques
 Training
 QI teams using the QI story
 Customer satisfaction surveys
 Employee satisfaction surveys

 QA
 Process design, management, and improvement
 Monitoring performance through metrics
 QI techniques
 QI story
2012.08
Requirement Engineering
14
If you can’t describe what you are doing as a process , you don’t know what you’re doing.
William Edwards Deming
Quality Improvement Techniques
 1. Identify the reason for improvement.
 Determine the nature of the problem.
 Collect data.
 Identify key processes.
 Develop a plan and schedule.
 2. Analyze the current situation.
 Identify customers’ real requirements.
 Set a target for improvement.
 3. Conduct analysis.
 Identify probable root causes of the problem.
 Select root causes that seem to have the most impact.
 Verify the selected root causes with data.
 4. Select counter measures that attack the verified root causes.
 Evaluate whether the countermeasures will do the following:
 Address the verified root causes;
 Impact the customers’ requirements;
 Prove to be cost beneficial.
2012.08
Requirement Engineering

15
Quality Improvement Techniques
 5. Develop an action plan to implement the selected counter measures.
 Obtain management approval.
 Coordinate with stakeholders to garner support and cooperation.
 6. Implement the countermeasures.
 7. Measure the results.
 Did the counter measures work?
 Are things improving?
 Are root causes being impacted?
 Evaluate the results compared to the target for improvement.
 Implement additional countermeasures if needed.
 8. Standardize an approach based on the results.
 What can be changed to ensure the problem does not recur (e.g., a new or
revised policy , procedure , work process , standard , training)?
 9. Consider what lessons have been learned from performing the
quality improvement effort.
 Should related problems be addressed?
 Should the approach for performing the QI story be revised?
2012.08
Requirement Engineering
16
The PDCA Cycle
Plan
Do
Check
Act
2012.08
Requirement Engineering
17

The PDCA Cycle
2012.08
Requirement Engineering
18
How to Design a Process
 A critical skill needed by the RA is the ability to design and to
improve processes—more specifically, to facilitate process
design and improvement sessions.

For example:
1. Identifying requirements;
2. Understanding customer needs and expectations;
3. Clarifying and restating the requirements (evolving the real requirements);
4. Analyzing the requirements;
5. Defining the requirements;
6. Specifying the requirements;
7. Prioritizing the requirements;
8. Deriving requirements;
9. Partitioning requirements;
10. Allocating requirements;
11. Tracking requirements;
12. Managing requirements;
13. Testing and verifying requirements;
14. Validating requirements.
2012.08
Requirement Engineering
19
How to Design a Process
 Process design and process improvement are activities
that do the following:

 They involve stakeholders (those who have an interest) in
deciding how things should be done, thus gaining their
buy-in to the implementation, use, and continuous
improvement of the process.
 They enable a project or organization to become
increasingly proficient. Once a process is documented,
everyone can understand it, and it can be done repeatedly
in the same way with the same results. Also, improvements
can be suggested, discussed, and incorporated.
2012.08
Requirement Engineering
20
How to Design a Process
2012.08
Requirement Engineering
21
How to Design a Process – PD
2012.08
Requirement Engineering
22
Name Name of the process or subprocess
General information
Process ID Unique process identifier
Goal Provide a brief description of the purpose and objective of the activity.
Standards
Identify the applicable process and product standards, including maturity-model
references.
Related processes
Identify processes that are related to this process, especially if this process is
part of a set that is normally viewed as a whole. List processes that either

produce inputs or consume outputs of this process.
Version number
Include version history. For each version, include version number, approval date,
and a summary of changes. As an example, the versions for this DID follow: 3.0
broadened SW-CMM to maturity models as a standard; added guidance on usage;
changed to a table format; added guidance on indicators; changed footer to
include version and date (10.14.02)
2.0 version on PAL labeled 2.0.
1.1 added reasons why organization or project goals and measurements may
change
1.0 updated process based on 7.1.99 peer review (7.12.99)
0.1 initial version (1995)
How to Design a Process – PD
2012.08
Requirement Engineering
23
Name Name of the process or subprocess
Customer description
Customer
Identify the internal and external stakeholders who benefit directly (receive
products/services) from the results (outputs) of this process.
Requirements
List each of the legitimate requirements that have been negotiated and agreed
to with the identified. These requirements should follow the RUMBA criteria in
that they should be reasonable, understandable, measurable, believable, and
achievable.
Interface description
Entrance criteria
Identify the criteria that must be satisfied before the activity can be initiated.
The criteria might say how to tell when a process can be started, for example at

the conclusion of another activity or process.
Inputs Identify the work products that are used at any point in the process.
How to Design a Process – PD
2012.08
Requirement Engineering
24
Name Name of the process or subprocess
Interface description
Entrance criteria
Identify the criteria that must be satisfied before the activity can be initiated.
The criteria might say how to tell when a process can be started, for example at
the conclusion of another activity or process.
Inputs Identify the work products that are used at any point in the process.
Outputs Identify the work products that are produced during the process.
Exit criteria
Identify the criteria that must be satisfied before the activity can be considered
complete. Exit criteria summarize the salient measurable tasks of the process.
How to Design a Process – PD
2012.08
Requirement Engineering
25
Name Name of the process or subprocess
What to do
Responsibilities Describe the groups that participate in the process.
Tasks
Describe the tasks that must be accomplished within the process. For ease of
reference, the tasks should follow the quality in daily work (QIDW) process
diagram referenced as the main exhibit. If the process is procedural, describe
the tasks in the order that they must be accomplished, numbering each task
step. Parenthesize the responsible group to the left of the task, as shown below:

(<Participating group>) <Task description>
Use action verbs to describe the tasks. Reference by process ID all tasks that are
further described elsewhere. Note any particular procedures, practices, or
methods that are employed in any step.
Tools Describe suggested or mandatory tools used during any step of the process.