Tải bản đầy đủ (.pdf) (76 trang)

Lecture Software process improvement: Lesson 27 - Dr. Ghulam Ahmad Farrukh

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (919.14 KB, 76 trang )

Software Process Improvement 
Using PDCA
Lecture # 27

1


Software Process Improvement
• There are a number of models for instituting 
software process improvement programs in 
organizations
• All these models have to be incorporated in 
orderly and cyclic manner
• These introductions cannot and must not be 
made abruptly
2


Shewart cycle
• The Shewart cycle is one such way of 
introducing software process improvement 
program in organization. It was was 
popularized by W. Edwards Deming
• The Shewart cycle has four steps





Plan
Do


Check
Act

3


PDCA
• Plan: Identify and resolve risks
• Do: Train, adapt, consult, remove barriers
• Check: Evaluate results, ensure success, 
celebrate
• Act: Revise, develop next­level process, 
convince others

4


PDCA
• The PDCA model can be combined with the 
famous spiral process model, specially 
adapted for process improvements
• This results in a new spiral process 
improvement model for software

5


Following slide to be inserted
Spiral Model for Process­
Improvement Adoption


6


Spiral Model for Process­Improvement 
Adoption

7


• Let’s discuss this picture in some detail 
cycle by cycle

8


Cycle I: SPI Spiral Model





Project plans new practice (plan)
Project tries new practice (do)
Successful project (check)
Practice described as part of success (act)

9



Cycle II: SPI Spiral Model





Other project(s) plan to use (plan)
Minimal new documentation added (do)
Other successes linked to practice (check)
Decision for “organization­wide” use, 
successes told widely (act)

10


Cycle III: SPI Spiral Model
• People assigned to document, train, and support 
(plan)
• Training manual, process support by staff, initial 
process metrics (do)
• More projects use with few hard problems, initial 
measurable results (check)
• Procedures revised, expected results quantified, 
management refers to as “standard” (do)
11


Cycle IV: SPI Spiral Model
• All projects plan to use, urgent requests for 
training, improvements planned (plan)

• Support processes standardized, initial 
automation, metrics to monitor effectiveness (do)
• Most projects use, practice evaluated against 
measurable goals, most people convinced to value 
(check)
• Procedures revised, ongoing responsibility for 
effective use assigned, management reviews 
effectiveness (act)
12


Cycle V: SPI Spiral Model
• Plans to optimize infrastructure (plan)
• Number of infrastructure personnel reduced 
to optimal ongoing levels (do)
• Metrics monitored to ensure no loss of 
benefits (check)
• Effectiveness reviewed, process tuned (act)

13


• The figure shows a progression from first­
time practice usage (in the center, “project 
plans new practice”) to widespread 
organizational adoption
• Normal product (development) projects 
aren’t organized to go through this entire 
spiral. At best, there may be a product­line 
architecture that could ideally do so if all 

planned products were done
14


• This figure shows some useful insights for 
process improvement projects that can help 
us assess to what extent an improvement 
has been adopted

15


• The model includes several patterns across 
the plan/do/check/act quadrants. These 
reflect
– Increasing people and resource investments
– Greater management understanding, attention, 
and commitment, and 
– Better control with process metrics
16


• Let’s now talk about the steps/quadrants of 
the Shewart cycle

17


Plan
• Most new improvements are first tried by 

one project team.  If it is a success, these 
improvements are spread to other projects
• As usage spreads, planning aspects of new 
adoptions include ways to provide better 
documentation, training, and support

18


• Eventually, demand outpaces the ability of 
the people helping the new adopters to keep 
pace, and plans for an ongoing 
infrastructure are developed and tuned

19


Plan: Identifying Risks and 
Deciding What to Do

20


• While P/D/C/A always starts with some 
form of commitment, the nature and 
strength of that commitment is constantly 
challenged as plans solidify
• Anticipating these challenges helps you to 
strengthen plans to help ensure success


21


• Business planning includes changes that makes 
good business sense to you and link to your 
goals. The closer the tie they make between 
you and your competitive needs, the easier it 
will be for you to decide and act
• You need to plan the scope, timing, cost, and 
payback of each change. Without such 
scoping, you have no basis for comparing 
proposed process­improvement projects to any 
22
other business proposals


• Understand your organization’s readiness 
and enthusiasm for each proposed change
• Your culture, your existing processes, and 
your people’s underlying beliefs all affect 
changes
• If you don’t consider these aspects, even a 
simple process improvement can fail or not 
be cost effective
23


• Focus on developing core­competence is 
extremely important for organizations in 
software business

• By thinking about these needs strategically, 
managers more easily tie improvement 
objectives to business needs

24


• Such objectives are compelling and more 
likely to sustain management commitment 
than ones justified solely around some 
methodology or technology that is poorly 
understood by decision­making managers
• Core­competence planning is just as 
important as business planning in setting an 
organization’s long­term strategy
25


×