2. 10/19/2019 2
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
1. Software development Life Cycle, (Where do we start?)
2. 6 Sigma overview
3. ITIL- (Information Technology Infrastructure Library)
• IT-sm, (Information Technology - service management)
4. Software development quality models
• CMM - Capability Maturity Model
• Method-1 product to assist in software project management.
• Relationships of ITIL / CMM / Method-1
5. Apply 6 Sigma methodology to the software life cycle
6. Conclusion
3. 10/19/2019 3
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
Deploy
Build
Design
Operate
Requirements
Optimize
Application Management
Life Cycle
4. 10/19/2019 4
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
Deploy
Build
Design
Operate
Requirements
Application Management
Life Cycle
Optimize:
Enhancements
New Development Ideas
5. 10/19/2019 5
What is Sigma?
Sigma is the Greek letter representing a
statistical unit of measurement that defines
the standard deviation of a population. It
measures the variability or spread of the
data.
6 Sigma is also a measure of variability. It is a name given to indicate
how much of the data falls within the customers’ requirements. The
higher the process sigma, the more of the process outputs, products
and services, meet customers’ requirements – or, the fewer the defects.
6. 10/19/2019 6
What is 6 Sigma?
A vehicle for strategic change ... an
organizational approach to performance
excellence
TRANSFORMATIONAL CHANGE
Across-the-board: Large-scale integration of
fundamental changes throughout the organization
– processes, culture, and customers – to achieve
and sustain breakaway results
TRANSACTIONAL CHANGE
Business processes: Tools and methodologies
targeted at reducing variation and defects, and
dramatically improving business results
7. 10/19/2019 7
6 Sigma Decision Paths
DMAIC: Improve
existing processes,
products, and
services to 6
Sigma quality
Leverage and sustain the gains
achieved by improvement and creation
DMEDI: Create
new processes,
products, and
services to 6 Sigma
quality
8. 10/19/2019 8
Market
Inputs Business
Processes
Suppliers
Critical Customer
Requirements
Process
Outputs
Defects
Variation in the Process Output
causes Defects that are seen by
the customer
Output Variation is caused by
Variation in Process Inputs and
by Variation in the Process itself
Focus on the Reduction of Variation that
Generates Defects for Customers
9. 10/19/2019 9
DMAIC: Improvement Process
Define Opportunities
Measure Performance
Analyze Opportunity
Improve Performance
Control Performance
Focuses on “real problems”
directly related to the
bottom-line
Realizes results in 4-6
months
Utilizes multiple tools and
techniques including
rigorous statistical methods
when needed
Sustains improvement over
the long-term
Disseminates improvement
throughout the organization
Acts as an agent of change
10. 10/19/2019 10
DMEDI: Creation Process
Define Opportunities
Measure Customer Needs
Explore Design Concepts
Develop Detailed Design
Implement Detailed Design
Focuses on development of new
products, services, processes,
and plants that precisely meet
customer current and future
needs
Realizes results in 6-18 months
depending on type of project
Utilizes multiple tools and
techniques including rigorous
statistical methods when needed
Sustains improvement over the
long-term
Disseminates improvement
throughout the organization
Acts as an agent of change
11. 10/19/2019 11
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
IT-sm Information Technology – service management
Assumes an application or service exists.
Customer Request Service Desk
•Service request
•Request for information
Incident Management
•Service interruption
•Get service restored
Problem Resolution
•Identify solution to problem
Change Request
•Modify infrastructure and test
•Modify Application and test
Release Management
•Schedule releases
•Communicate release content
13. 10/19/2019 13
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
Method - 1
Manage Project Focused
•Project Definition & Planning
•Analysis
•Design
•Build & Test
•Roll-out
Size and type of project specific.
•Client/Server-Large…Small
•Host based Large…Small
•Object Oriented
•Purchased Systems
Routes
Common set of activities
14. 10/19/2019 14
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
Deploy
Build
Design
Operate
Requirements
Management
Optimize:
Enhancements
New Development Ideas
Method - 1
Planning and Definition
Route
6 Sigma rigor and savings
Preliminary
Requirements
Method - 1
Development
Route
Method – 1
15. 10/19/2019 15
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
. Change
. Release
Deploy
Build
Design
. Call
. Incident
Operate
Requirements
Management
Optimize:
. Call
. Problem
Enhancements
New Development Ideas
Method - 1
Planning and Definition
Route
6 Sigma rigor and savings
Preliminary
Requirements
Method - 1
Development
Route
IT-sm
. Call
. Change
. Release
. Problem
. Incident
Method – 1
IT-sm
16. 10/19/2019 16
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
. Change
. Release
Deploy
Build
Design
. Call
. Incident
Operate
Requirements
Management
Optimize:
. Call
. Problem
Enhancements
New Development Ideas
Method - 1
Planning and Definition
Route
6 Sigma rigor and savings
Preliminary
Requirements
Method - 1
Development
Route
IT-sm
. Call
. Change
. Release
. Problem
. Incident
CMM
CMM Level 2 repeatable processes
Requirements Management
Software Project Planning
Project Tracking and Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management
Method – 1
IT-sm
CMM
17. 10/19/2019 17
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
Assumptions
• Use 6 Sigma to select new work activity
• IT-sm for maintaining the current production environment
• Use Method – 1 and CMM procedures/processes for the
development life cycle.
Investigation
Can we use 6 Sigma to guide us in where to concentrate on improving our
software development life cycle?
18. 10/19/2019 18
Identify, Measure, Reduce and Audit
Cost of Software Defects
Project Description
It is well documented and proven within the software industry that
the cost of fixing software defects due to faulty or incomplete
requirements, design, or coding escalates dramatically as one
advances through the software development process. Indeed
experts estimate that fixing software defects once software has
entered the “operational” phase is 40 to 1000 times more costly
than doing so at the earliest phases of the process. Hence it is
prudent to attempt to remove software defects throughout the
development process rather than focusing on doing so only in the
latter stages of development or implementation.
19. 10/19/2019 19
Identify, Measure, Reduce and Audit
Cost of Software Defects
Goal Statement
Goal1 = Decrease software development and support costs by identifying and
correcting software defects at the earliest phases of System Development Life
Cycle.
Define Y1 = f(X1, X2, X3, X4, X5, X6) + f(X7)
Y1 = total cost of repairing software defects
X1 = cost (including review and rework) of repairing defects during requirements phase
X2 = cost (including review and rework) of repairing defects during design phase
X3 = cost (including review and rework) of repairing defects during coding phase
X4 = cost (including review and rework) of repairing defects during development testing
X5 = cost (including review and rework) of repairing defects during acceptance testing
X6 = cost (including review and rework) of repairing defects post production
X7 = cost to the business (unavailability/inaccuracy/rework of end product)
20. Relative Cost of Fixing a Defect
(from Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, 1981)
0
10
20
30
40
50
60
70
Requirements Design Code Development
Testing
Acceptance
Testing
Operation
Development Phase
RelativeCosttoCorrectaDefect
Identify, Measure, Reduce and Audit
Cost of Software Defects
21. 10/19/2019 21
Identify, Measure, Reduce and Audit
Cost of Software Defects
Defects
Requirements
Review
Design
Review
Construct
Review
Test
Review Production
100 20 4 0.8 0.16 0.16
Time to fix 40 16 6.4 3.2 8
Cost to fix $2,200 $880 $352 $176 $440 $4,048
100 100 100 100 20 20
Time to Fix 0 0 0 400 1000
Cost to Fix $0 $0 $0 $22,000 $55,000 $77,000
Based on industry standards
100 defects/week (project), inspection catches 80% of the defects at each phase, 30 minutes to fix at inspection time
Ratio used for Time to Correct
Requirements 1 To 1
Design 2 To 1
Construct 4 To 1
Test 10 To 1
Production 100 To 1
Hourly cost 55
NP
I
1:1
Assembl
y
10:1
CPI
100:1
Requirements
Design
Construct
Test
Production
Product Support (Business) and IT
22. 10/19/2019 22
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Define Phase Process Mapping
Formal Review (Usually Analysis and Design/Requirements)
PhaseCompletionReview
Team Leader or
Author of
Application
Reviewer #1
(Rep for signing
SAF)
Application
Expert
(Sometimes)
Customer
Business
Expert
(Usually)
Person
Responsible for
Work Effort
Determine whether
review material
needs to be sent
prior to review
Schedule review
meeting
Does material
need to be
sent
Send material to
all meeting
participants
Y
Conduct
review meeting
N
Review Material Review Material Review Material
Walk through
material
Provide
addtional
information
during walk
through
Determine if walk
through is at
appropriate level
based on
audience
reaction or
questions
Attend meeting Attend meeting Attend meeting
Listen
Ask questions
(IT)
Listen
Ask questions
(Business)
functions)
Listen
Ask questions
(IT and Business)
Document
challenges,
issues, changes
needed
Accept or
reject
Sign applicable
documents
Y
Sign applicable
documents
N?????
Informal Review (Support Acceptance)
Reviewer AQA Coach <Function> <Function>
Person
Responsibile
for Work Effort
Schedule
meeting w/
Reviewer
Prepare for
Review
(Based on SAF)
Work with
Reviewer
Review the
material for
deliverable
Accept or
Reject
Correct potential
errors identified
Reject
Accept
Sign SAF
(Support
Acceptance
Form)
Process
Mapping
23. 10/19/2019 23
Identify, Measure, Reduce and Audit
Cost of Software Defects
Planning/Analysis Process Map
Analysis and Design/
Requirements
AQAPlanningHighLevelRequestandRequirementsAQADevelopment
ApplicationDevelopment ApplicationSupport
Customer
(Requestor)
Request
initiated
Sets target date
High level
requirements
(Scope,
function,ROI
etc...)
Budget
SWAG effort
Procee
d
Y
Kill
request
N
Contact
customer for
follow-up
AQA
Plannin
g
Route
Continuehigh
level
requirements
(40 hrs or less
target)
Continuehigh
level
requirements
(40 hrs or less
target)
Use
Case
template
s
List of
functions,PDR,
prelimivnary
charter Conduct A'
NPI Review
Proceed
Initiiate detail
requirements
gathering
Y
Table
reques
t
N
Detail
Requiremen
ts
Detail
Requiremen
ts
Detail
Requiremen
ts
Accept
Reject
Conduct A NPI
review
Accept
??? R
Conduct Peer
Review
Accpet
Reject
Sign SAF
Sign off
appropriate
documernts
Accept
????R
<Detail
Requirements>
DocumentsApplicationSupportCustomerApplicationDeveloper
Develop
measurementplan
Measurementplan
Developproject
plan
Projectplan
(scope,risk,
configuration
etc..)
Reviewproject
risk
Develop usecases
(Distributed)
Task Analysis(MF)
Interviews,JADothers...
FinalProject
charter
Usecases
Businessfunction
Identifyadditional
requirements
IT
supportabillity
Language
Platform
Reliability
Develop usecases
(Distributed)
Task Analysis(MF)
Develop usecases
(Distributed)
Task Analysis(MF)
Identifyadditional
requirements
Informal
Reviews
(iteratve)
withindev only, support ,
allparticipants?
Who signs which docs?
Do use cases look at
normal,exciting,expected
requirements
24. 10/19/2019 24
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Define Phase – Voice of the Customer (Process Partner)
-Population Base
-350 Applications Development and Support staff
-186 responses for 95% confidence in results
-Surveys, Focus Groups, Individual Interviews……
- Distributed 350 surveys
-Staff and Management
-Received 65% return rate (226 responses)
- Key information focus:
- Peer Review process
- Defect origination
26. 10/19/2019 26
Identify, Measure, Reduce and Audit
Cost of Software Defects
VOPP Origination of Defects
Introduced in Construct Introduced in TestIntroduced in Requirements
27. 10/19/2019 27
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Measure Phase
Measurement Plan – Validate VOPPMetric: Number of potential errors discovered during system development life cycle.
Spreadsheet for baseline measurements
- Rework time
'- Time to prepare and conduct
reviews/test, names of participants
'- Source of potential error or defect
(where injected I.e. reqs, design etc..)
- The individual spreadsheets will be routed to
Ken whenever a review/test is completed (Ken
will need a copy of the project plans to know
when to expect review/test
How will Data Be Displayed?
Identify the number and source of potential errors/defects and cost to repair. Use to identify improvement opportunities within system development life cycl
Behaviors: Show value and cost savings, understand the reasons. Know the reviews will be conducted so additional diligence will be applied.
Negative behavior would be skipping review/test or not documenting the results, bypassing the process,
Pie charts and Pareto (% of potential errors by life cycle stage), line charts for trends
How will Data be Collected
Other Data that should be Collected
at the same time
When will Data be Collected
How will Data Be Used?
Reduce the overall number of defects implemented into the production environment – improve quality
earliest stage of the system development life cycle, fixing potential errors earlier results in lower cost
conservatively $4m in correcting defects in production.
Customer requirements sets appropriate expectations and content.
Goal is to reduce Break/Fix, Non-critical faults, Data Discerepnacy etc....(warranty cost) in a cost effe
production environment. (Reference industry standards for the cost to fix at various stages of the life
- Number of potential errors
'- The basic life cycle to be measured includes:
High level requiremnents (Planning Route)
Analysis and Design - Detail requirements
Design - detail design
Construct (code, unit test, system test, integrated
test)
Test (Customer Acceptance test)
The individuals and/or project manager
participating in the reviews, testing
documenting potential errors in
spreadsheet.
- Work efforts identified by division managers
(Charlie, Dick, Peg, Rick)
'- Miniumum of 4 projects, different types (new
product, major enhancement MF, major
enhancement Distributed, IT Forced Change)
'- A project within MES implementing the Central
Development Org would be excellent opporunity
to measure both
Operational Definition
Performance Measure Data Source & Location Sample Size
28. 10/19/2019 28
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Measure Phase
Measurement System
Defect Count
Project Name
Breif Description of potential
"Production defect avoided'
Phase within the Life Cycle the
defect is found.
Phase the defect was
introduced.
Type of defect.
Severity of the defect. Status Time correcting Defect
(hours)
Date Defect is Entered
6 Sigma Project
Identify, Measure, Reduce and Audit Cost of Software
Defects
Examples
3
Add A Defect
Entered on: Aug-18-2003 07:25:57 AM
Defect Entry Form
Although the sheet is placing your data into the
individual spreadsheets, YOU MUST GO TO FILE
AND PRESS SAVE TO SAVE THE DATA TO DISK.
29. 10/19/2019 29
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Analysis Phase
Measurement Results – Validate VOPP
#Defects/Hours
Introduced
Rqmts
# Defects
Introduced
Rqmts
Hours to
Correct
Introduced
Design
# Defects
Introduced
Design
Hours to
Correct
Introduced
Construct
# Defects
Introduced
Construct
Hours to
Correct
Introduced
Impl
# Defects
Introduced
Impl
#
Defects Hours
Found
Requirements 23 53 0 0 0 0 0 0 23 53
Found Design 5 25 10 21 0 0 0 0 15 46
Found Construct 4 48 4 78 2 6 0 0 10 132
Found Unit Test 11 74 7 123 13 32 0 0 31 229
Found
Acceptance Test 3 33 3 16 7 31 0 0 13 80
Found
Implementation 2 52 2 91 11 88 6 10 21 241
Total Hours 48 285 26 329 33 157 6 10 113 781
30. 10/19/2019 30
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Analysis Phase
Statistical Analysis
Requirements
Phase Found
Design Construct Unit test Accept Test Implementation
31. 10/19/2019 31
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Analysis Phase
Statistical Analysis
Phase Found
Requirements Design Construct Unit test Accept Test Implementation
32. 10/19/2019 32
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Analyze Phase
Root Cause Analysis
Reviewsnot
conducted
Lackof
Resources
Lackofperceived
value
Personalities
Lackof
enforcement
Inconsistent
mgmt buy-in
Peer pressure
- Make others look bad
- Don't get along
Peer pressure
- Got real work to
do
Lack of technical or
business knowledge
Those with knowledge
pulled too much
No time, get it done
get it done
mentality
Fear of re-work
time and missed
deadlines
Use test to find
defects vs
reviews
Imposed target
dates
Percedption that my
work doesn't need
reviewedx
Technology
Legacy (Mainframe
applications)
Understanding of
peer review vs SME
review
Less knowledge of
web based apps
(Mostly OO
concepts)
Maintenance vs
development mode
Size/nature
of change
Constraints to Conducting
Reviews
33. 10/19/2019 33
Identify, Measure, Reduce and Audit
Cost of Software Defects
Root Cause Analysis Detail - Requirements
Majority of Defects
Introduced in
Requirements
Lack of customer
engagement
(Business)
Lack of a good
requirement
Understanding of Requirements
Management
Accountability
Need vs Want
Too generic
Use it or lose it
If not done now,
won't get later
Scope creep
Lack of requirements
gathering skills (IT)
Background
knowledge
Fear of showing a lack
of understanding
Don't understand
value of requirements
prior to development
Target dates set before
requirements gathered
Date is supported even
though unrealistic
Culture
Customers know IT
won't pushback
Support may be at
some level but not
consistent through
upper levels
Don't tell customers no
Rush to start coding and
'see' progress. Resource
leveling
Don't follow triple constraint
principle (KMM)
Making too many assumptions.
Not nailing down with customer
Most of application knowledge base
in support, development writing
requirements (many cases)
Lack of business knowledge
involved in the process
Too much business knowledge, lead
customer and designing in head
without listening and asking
Scope
Management
Fix problems resulting from poor
requirements with support
dollars. Use an excuse to keep
dev dollars lower
Model works, but used
in diffrerent depending
on who's advanatge
Estimates given, approved
and 'fixed' too early
IT conditioned
Want to provide good
customer satisfaction
Measured on jumping thru
hoops to deliver whatever is
promised (PDP)
Politically dangerous to
pushback
Accept defects -
will fix later
IT writing business
requirements
Time to fix it, but not
time to do it right
Don't understand what scope
creep is and its impact
IT tryijng to change to act like a software
house, while still in the culture of
supporting whatever the customer wants
and when
IT doesn't know how to or
when to engage customer
IT wants to do project, costs to do
project not always based on what
it will actually cost (bid to get the
work)
Lack of consistent tools/methodology for gathering
requirements (How)
No speific training or expertise in gathering requirements
Lack of understanding that time
and resources need to be
allocated
On a new system - keep old ways of doing things
rather than developing new requirements
Not allowed to follow
process as it should be
No enforced, repeatable process
Don't like to formally
document (see no
need or value)
Mgmt
accountability
for quality
34. 10/19/2019 34
Identify, Measure, Reduce and Audit
Cost of Software Defects
The number and costs of
software defects implemented
into productions drives a high
cost to the business to
provide and support business
and infrastructure applications.
Resources Culture
Knowledge
Tools and
Process
IT doesn't know how to or
when to engage customer
Lack of understanding that
time and resources need to
be allocated to requirements
(Business and IT)
Primary Causes:
Lack of good requirements
Inadequate Design
Business application knowledge is
primarily in the support organzation, while
development is charged with devloping
requirements (in many cases)
IT writing business
requirements
Lack of business knowledge
in requirements process
Making too many
assumptions. Not
nailing down with
customer
Lack of consistent tools/methodology for
gathering requirements (How) No speific
training or expertise in gathering
requirements
Designing in head without
listening and asking
questions to gather
requirements
No enforced,
repeatable process
Time to fix it, but not
time to do it right
Rush to start coding
and 'see' progress.
Resource leveling?
Estimates given, approved
and 'fixed' too early
Lack of accountability
for quality
Diversity of technology involved
(Language, database, platform,
connectivity, infrastructure)
Lack of
experience
Too many roles to become
proficient in a certain function Expectation gap between IT
and customer (too many
assumptions from
equirements)
Target dates don't provide
time needed
Knowledge is assumed
Lack of tools
(Data modeling, OO Design,
Design workbench)
Lack of business
knowledge across
integrated systems
Lack of Knowledge in
Architecture and Coding Language
Source of Defects
Root Cause Analysis Summary
35. 10/19/2019 35
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Improve Phase
-Brainstorm potential solutions
-VOPP, Measures, Root Cause Analysis as inputs
-Quantity vs Quality
-Evaluate, narrow and combine solutions
-Pugh Matrix as one method
-Iterative
-Evaluate strongest solutions
-Combine strengths of other solutions
36. 10/19/2019 36
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Improve Phase – Pugh Matrix
Evaluation Matrix
Criteria
AverageImportanceRating
Datum
Implementprocesses(organizational,tools,knowledge,
reviews)focusedonimprovingoutputsfrom
requirementsanddesignphases
1)Purchaserequirementstoolandprocess
implementedforthegatheringanddocumentationof
requirementstobetrackedthroughoutthelifecycle.
2)EducatemanagementuptoVPlevelonthe
processesandtheirvalue.Requiremanagementto
followprocesses
3)Implementintegratedtestenvironment
4)Implementstructured,mentoredapprenticeshipxx
monthsor#projectspriortodesigningordeveloping
newsystem.
5)OutsourceSupport(7x24)
6)Sharemore‘experts’fromsupporttodevelopment
7)Developcorecompetency(BusinessandTechnical
Requirements,FinalTestandexecutionoftechnical
reviewsthroughoutlifecycle-sourcedesignand
construct)Alloftheitemslistedbelowwillbeenabledby
trainingandgrowingthecorrectskill
8)Alignexpertsinkeyfunctionaltechnicalareastothe
functionsmorecritical-utilizecentersofexpertiseas
centersofexpertise
9)Repositoryforrequirements,designetc….all
documentsgeneratedwithinlifecyclerelatedtoproduct
orproject
Potential to reduce total defects and
improve product quality(Sigma Value)
Project Goals 9.571
- - - S S - + - -
Cost (less is better) 7.286 + + - + + + + + S
Employee engagement, career path
opportunities 4.714
- - - + - S - S -
Meets corporate strategy 5.714 - - S S S - + S -
Meets Gartner Benchmark
recommendations 4.429
- - + - - - + - S
Opportunity to reduce costs 7.571 - - - S + - + - -
Organizational Change Impact 6.857 + S + + - + - + S
Time to Implement 5 + + S + + + S + +
Training required (less is better) 5 + + + + S + S + +
Reality factor 7.857 S - - S + + + S S
Sum of Positives 4 3 3 5 4 5 6 4 2
Sum of Negatives 5 5 4 1 3 4 2 3 4
Sum of Sames 0 1 2 4 3 1 2 3 4
Weighted sum of Positives 24.1 17.3 16.3 28.9 27.7 32.0 42.4 24.1 10.0
Weighted sum of Negatives 32.0 32.0 29.1 4.4 16.0 27.3 11.6 21.6 27.6
-7.9 -14.7 -12.9 24.4 11.7 4.7 30.9 2.6 -17.6
Concepts
37. 10/19/2019 37
Identify, Measure, Reduce and Audit
Cost of Software Defects
DMAIC Control Phase
-Communications (all phases)
-Identify and execute pilot
-Develop process control plan and metrics
-Adjustments from pilot
-Implement solution and process management
Way we work
Extensive toolset available
Follow the Recipe
38. 10/19/2019 38
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
•Use 6 Sigma to select new work activity
• IT-sm for maintaining the current production environment
• Use Method – 1 and CMM procedures/processes for the
development life cycle.
• Use 6 Sigma to guide us in where to concentrate on
improving our software development life cycle
•Focus effort on developing and maintaining quality
Requirements.
• Training on why requirements are needed.
• Training on what are good requirements.
• Develop a process and organization that will elicit,
document, inspect, seek proper approval, store, and
maintain requirements.
Conclusion
39. 10/19/2019 39
6 SIGMA DISCIPLINE IN SOFTWARE DEVELOPMENT
!
Application
Development to the
Power of 6 Sigma
