Copyright ©2001 Software Quality Consulting Inc.Slide 1 An overview of Management’s Role in...

Copyright ©2001 Software Quality Consulting Inc.

Slide 1

An overview ofManagement’s Role in Achieving

Predictable Software Development

An overview ofManagement’s Role in Achieving


Q Software Quality Consulting

Inc.

Steven R. Rakitin ConsultingPresident Training

Quality Systems

Phone: 508.529.4282 www.swqual.comFax: 508.529.7799 [email protected]


Inc.


Quality Systems



Slide 2

Topics

• Motivation– Economics of Software Development

• Balancing Quality, Features, and Schedule– Management’s Role

• Balancing People, Process, and Product– Management’s Role


Slide 3

Motivation

Software Development is like the stock market

You’d be way ahead of the game if only you could predict what will happen


Slide 4

Motivation

• Many software development organizations lack:– Discipline– Credibility– Predictability

• As a result, these organizations are unable to accurately predict when products will be released.

• To be competitive in today’s global economy, these issues must be addressed.

• Many software development organizations lack:– Discipline– Credibility– Predictability

• As a result, these organizations are unable to accurately predict when products will be released.

• To be competitive in today’s global economy, these issues must be addressed.

When willthe software

be done?


Slide 5

Motivation

• Managers have the ability to change the organization and influence the behavior of developers, QA, and project managers.

– How can you exert this influence?

– What behaviors should be encouraged and which should be discouraged?

– How can you know if you are on the right track?

• Managers have the ability to change the organization and influence the behavior of developers, QA, and project managers.

– How can you exert this influence?

– What behaviors should be encouraged and which should be discouraged?

– How can you know if you are on the right track?


Slide 6

The Goal

Delighting your Customers by consistently delivering Quality products on time.




Slide 7

Unpredictable Organizations

– Planning new product releases is difficult

– Staffing projects difficult

– Customer frustrated from promises not kept

– Employees frustrated from promises not kept

– Many unplanned bug fix releases

– Product quality low

– Time to market goals consistently not met

– Costs higher than expected

– Revenue projections frequently not met– Over-commit AND under-deliver

– Planning new product releases is difficult

– Staffing projects difficult

– Customer frustrated from promises not kept

– Employees frustrated from promises not kept

– Many unplanned bug fix releases

– Product quality low

– Time to market goals consistently not met

– Costs higher than expected

– Revenue projections frequently not met– Over-commit AND under-deliver


Slide 8

Root Causes

• Inadequate training

• Lack of measurement

• Unrealistic schedules

• Poor project management skills

• Don’t understand Customers

• “Crisis mentality”

• Reward wrong behaviors

• Inadequate training

• Lack of measurement

• Unrealistic schedules

• Poor project management skills

• Don’t understand Customers

• “Crisis mentality”

• Reward wrong behaviors


Slide 9


• Set achievable expectations

• Develop accurate, realistic schedules

• Meet them!

• Follow a documented Development process

• Hold people accountable

• Proactively Manage Risk

• Manage Internal and External Commitments

• Measure what happens

• Set achievable expectations

• Develop accurate, realistic schedules

• Meet them!

• Follow a documented Development process

• Hold people accountable

• Proactively Manage Risk

• Manage Internal and External Commitments

• Measure what happens


Slide 10

Characteristics of Predictable Organizations

• Measure Quality and Customer Satisfaction regularly

• Measure Employee Satisfaction regularly

• Make effective use of scarce, expensive resources

• Rarely in ‘fire fighting’ mode

• Few unplanned bug fix releases

• Follow a documented Development Process

• Actively Manage Risks

• Under-commit AND Over-deliver

• Measure Quality and Customer Satisfaction regularly

• Measure Employee Satisfaction regularly

• Make effective use of scarce, expensive resources

• Rarely in ‘fire fighting’ mode

• Few unplanned bug fix releases

• Follow a documented Development Process

• Actively Manage Risks

• Under-commit AND Over-deliver


Slide 11


ScheduleFeatures

Quality

PredictableSoftware

Development

People

Process Product

Commitment Management

Risk Management


Slide 12

From a Management Perspective...

Culture

Process

Performance


Slide 13

Economics of Software Development

• How Startups Acquire Bad Habits

• Cost of Software Defects• Time to Market vs. Quality• Economic Value of Quality


Slide 14

Cost of Software Defects

Requirement

Analysis

Requirements Definition $1

Design$5

Coding $20

Testing $50

Maintenance$100

Relative cost factor to find and fix defects at each phase of the Software Development Life Cycle

Source: Boehm, B., Software Engineering Economics, Prentice-Hall, 1981

Relative cost factor to find and fix defects at each phase of the Software Development Life Cycle

Source: Boehm, B., Software Engineering Economics, Prentice-Hall, 1981


Slide 15

Software Defect Cost Model

Rework Cost

Profit loss due to schedule slip

DesignDesign Inspections

CodingCode Inspections

Integration Testing

Validation TestingDocumentation

Software Defect Cost

Ward, J., “Calculating the real cost of software defects”, AAMI 27th Annual Conference Proceedings, 1992.


Slide 16

This cycle can take from 10-30 hours per defect

Using an average of $150 per hour for Software Engineering time...

Max cost per defect is:

30 * $150 = $4,500

For a product with 100 defects, the cost is:

100 * $4,500 = $450,000

Pre-release Find/Fix Cycle

Development includes fix in next baseline

New release to SQA

SQA performs regression testing

Testing uncovers a potential defect

Potential defect reported

Dev. investigates & verifies defect

Dev. fixes defect & does some testing


Slide 17

This cycle can take from 20-60 hours per defect

Using an average of $150 per hour for Software Engineering time...

Max cost per defect is:

60 * $150 = $9,000

For a product with 100 defects, the cost is:

100 * $9,000 = $900,000

Post-release Find/Fix Cycle

Update documentation

New version released to Mfg

New version distributed to Customers

Customers install new version

Defects?

No

Yes

Pre-Release Find/Fix

Cycle


Slide 18

Economic Motivation

How do you want to allocate Engineering resources?

Develop New Projects OR Rework Existing Products

$$

Generates revenue Doesn’t generate revenue

$


Slide 19

Balancing Quality, Features, and Schedule

ScheduleFeatures

Quality

• Software Quality Myths/Facts

• “Good Enough” Quality Debate

• Economic and Competitive Value of Quality

• Creating accurate, realistic schedules

• Management’s Role

• Software Quality Myths/Facts

• “Good Enough” Quality Debate

• Economic and Competitive Value of Quality

• Creating accurate, realistic schedules

• Management’s Role


Slide 20

Creating Accurate, Realistic Schedules

• Understand why estimates and schedules wrong most of the time

• Identify “Best Practices” for estimating and scheduling

• Provide staff with training in “Best Practices”

• Allow them to do it!


Slide 21

Why are estimates and schedules wrong?

• We play ridiculous negotiating games...

Doubling and Add Some Reverse Doubling Spanish Inquisition “Guess the date I'm thinking...”

We don’t teach people how to do it!

We allow feature creep without assessing impact

We don’t hold people accountable

Accountability = Responsibility + Authority

Source: Yourdon, E., Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible” Projects, Upper Saddle River, NJ: Prentice-Hall PTR, 1997


Slide 22

Why are estimates and schedules wrong?

• Management frequently OVER-commits

• Project teams have not been taught estimating and scheduling techniques

• Project Management skills are lacking

• Interdependencies are frequently ignored

• “People issues” are frequently ignored

• Known risks are frequently ignored


Slide 23

Typical “scheduled-backwards” Project

• Project starts with predetermined end date

• Tasks estimated based on time available rather than time required

• Task interdependencies not identified

• Unexpected things that ALWAYS happen on every project not anticipated...

• the requirements WILL change• key members of the project team will leave• a key assumption about the product will prove wrong• needed training for new tools / technology not provided• dependencies arise that were previously unknown or ignored• key resources pulled off to fight most recent “fire”• etc...


Slide 24

Typical “scheduled-backwards” Project

• Sooner or later, the schedule slip becomes so large it can’t be ignored

– Project Manager panics and starts paring down features and cranking up coding

– Whatever process the project was following is abandoned

– Activities like Design Reviews and Code Inspections are eliminated. Testing time curtailed.

• Usual outcome is a lose-lose situation– Organization loses

– Customers lose


Slide 25

Some Observations...

• Projects that are late are almost always “scheduled backwards”

• “Scheduling backwards” has a negative impact on project morale, product quality, and productivity

• Scheduled backwards projects frequently require unplanned bug fix releases

• Many people have personal “Quality Standards” that are significantly higher than Management’s...


Slide 26

Estimation and Scheduling “Best Practices”

• COCOMO II

• Function Points

• Feature Points

• Wideband Delphi

• Yellow Sticky Method


Slide 27

Balancing Quality, Features, and Schedule

• Management’s Role:– Work to create culture - under-commit / over-

deliver

– Train staff in estimating and scheduling techniques

– Manage commitments made to Customers

– Require schedules be developed going forwards by people who will be doing the work

– Negotiate schedule based on fact not fiction

– Hold project team accountable

– Reward teams that meet commitments!


Slide 28

Balancing People, Process, and Product

People

Process Product

• Software Development Best Practices

• People Issues

• Product Issues


Slide 29

Best Practices

• Risk Management• Define Requirements FIRST• Peer Reviews• Binary Quality Gates at the inch-pebble level• Project-wide visibility of project plan and

progress vs. plan• Defect tracking against Quality Targets• Configuration Management

Source: Ed Yourdon, Rise & Resurrection of the American Programmer, Prentice-Hall, 1998

Web sites: www.spmn.com www.christine.com


Slide 30

Binary Gates at the Inch Pebble Level

Project Start Scheduled Ship Date

Management made awarethat there is a “crisis”

The Problem...


Slide 31


• Beware of the “90% done” syndrome

• Use binary measures (done / not done)

• Precisely define what is meant by “done”

• Define gates at each major stage of development

• Proceed “at risk” when gates not met

• Beware of the “90% done” syndrome

• Use binary measures (done / not done)

• Precisely define what is meant by “done”

• Define gates at each major stage of development

• Proceed “at risk” when gates not met


Slide 32


Gate Precise Definition

RequirementsComplete

SRS conforms to standard. SRS reviewed and approved.

DesignComplete

SDD conforms to project standard. SDD reviewed and approved.

Code Complete All features coded and checked into source control All modules compile with no errors Unit testing completed and bugs fixed

TestingComplete

All planned tests have been executed Bugs reported fixed and validated Planned regression testing completed Release criteria defined in Test Plan met


Slide 33

Best Practices Summary

• A Written Software Development Process...

– The “wrapper” that encompasses Best Practices

– Best Practices are only BEST if they work for you

– Measurement is essential - You can’t know what you don’t measure

– A written Development Process DOES NOT limit people’s ability to do creative work

– Software Development Process should include Development, QA, and Doc


Slide 34

Software Development Best Practices

• Management’s Role– Work to create “process-oriented” culture

– Require written process that’s appropriate and flexible - tailored to meet specific needs of each project.

– Require people who must follow the process be actively involved in creating it.

– Ensure the process is communicated and understood. If necessary, provide training.

– Hold project teams accountable for following the process.

– Require the process be reviewed periodically and changed based on process measures.

• Management’s Role– Work to create “process-oriented” culture

– Require written process that’s appropriate and flexible - tailored to meet specific needs of each project.

– Require people who must follow the process be actively involved in creating it.

– Ensure the process is communicated and understood. If necessary, provide training.

– Hold project teams accountable for following the process.

– Require the process be reviewed periodically and changed based on process measures.


Slide 35

The Goal...





Slide 36

Thank you...

...for taking time to attend this meeting!

If you have any questions on the material in this presentation, please don’t hesitate to call or e-mail


Inc.


Quality Systems



Inc.


Quality Systems


Copyright ©2001 Software Quality Consulting Inc.Slide 1 An overview of Management’s Role in...

Documents

Transcript of Copyright ©2001 Software Quality Consulting Inc.Slide 1 An overview of Management’s Role in...