An analysis of two case studies to understand the process improvement<br />Presented by<br />Priyaashree<br />Rakesh<br />...
Introduction<br />The CMMI is a framework for business process improvement<br />It is NOT an engineering development stand...
Brief History of CMMI<br />In the 1980s a Standish Group study found that over 30% of all large software projects failed t...
CMMI : few structural concepts<br />The SEI identified 25 total process areas and put them into the CMMI.  <br />There are...
Case Study 1<br />GENERAL MOTORS Implementation of CMMI for acquisition <br />
Objective and Solution <br />BUSINESS CHALLENGES: GM has been acquiring and not developing  IT-solutions for decades. It h...
Implementation <br />Requirements: Acquirer ownership of requirement is essential and acquirer must be skilled in requirem...
Case Study 2<br />Implementation by a leading telecom  giant to improve the quality of the entire software development pro...
Objective and Challenge <br />Objective: <br />Improve the quality of the entire software development process and ensure C...
Absence of formal estimation processes
Lack of proper documentation
No rationale for estimates - incorrect estimations
Upcoming SlideShare
Loading in...5
×

Cmmi Final

1,906

Published on

This presentation is on two well known case studies of CMMI implementation in the industry.

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,906
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Cmmi Final

  1. 1. An analysis of two case studies to understand the process improvement<br />Presented by<br />Priyaashree<br />Rakesh<br />Vishaal<br />Indranil<br />Rohit Prasad<br />Surya<br />CMMI <br />
  2. 2. Introduction<br />The CMMI is a framework for business process improvement<br />It is NOT an engineering development standard or a development life cycle<br />There are currently three &quot;flavours&quot; of CMMI called constellations. <br />-CMMI for Development - 22 Process Areas.<br />-CMMI for Acquisition - 21 Process Areas.<br />-CMMI for Services - 24 Process Areas.<br />The three constellations share 16 &quot;core&quot; process areas.<br />Process Areas are organized in two main ways, called &quot;Representations“.<br />Staged<br />Continuous <br />Maturity Level and Capability Level<br />
  3. 3. Brief History of CMMI<br />In the 1980s a Standish Group study found that over 30% of all large software projects failed to be delivered, and, of the remaining, nearly 80% failed to come in on time and budget<br />To beat these odds, and to lower the overall cost of buying software, the Department of Defense funded the Software Engineering Institute (SEI) at Carnegie Mellon University to find ways to help defense contractors build software more economically.<br />Result became the Capability Maturity Model for software, or CMM.<br />Today, the CMM/CMMI are the de facto standard for software management throughout the Federal government and is internationally recognized as a very powerful business tool and competitive differentiator.<br />
  4. 4. CMMI : few structural concepts<br />The SEI identified 25 total process areas and put them into the CMMI.  <br />There are two ways to apply the 25 processes depending on which approach suits the development shop best.  They can choose to apply pre-determined processes in a specific sequence to achieve &quot;maturity&quot; in managing development, or, they can choose the processes most important to their business and apply the necessary rigor to achieve a &quot;capability&quot; for managing development.<br />The &quot;maturity&quot; scale has 5 levels And, the &quot;capability&quot; scale has 6 levels<br />the &quot;maturity&quot; levels are pre-defined, the approach is called &quot;staged.&quot;  The &quot;capability&quot; approach is called &quot;continuous&quot; because the performance of the processes are tied to business objectives <br />
  5. 5. Case Study 1<br />GENERAL MOTORS Implementation of CMMI for acquisition <br />
  6. 6. Objective and Solution <br />BUSINESS CHALLENGES: GM has been acquiring and not developing IT-solutions for decades. It had to evolve constantly with changing business need. Implementation of the model required structural change and following global standard practices.<br />CMMI SOLUTION: GM recognized that it must excel in Requirements ,architecture and Project management to be a successful acquirer and customer.<br />
  7. 7. Implementation <br />Requirements: Acquirer ownership of requirement is essential and acquirer must be skilled in requirement engineering<br />Action: established requirement team and requirement prototyping is done<br />Architecture: Architectural philosophy varies within supplier base<br />Action: Enterprise level system engineering team built and cross area/functional architecture planning meeting held<br />Project management: better relationship with customers was necessary for the acquisition PM<br />Action: integrated GM and supplier project plan, Standard peer and acceptance review was done.<br />BENEFIT: General motors was the first commercial enterprise to be appraised utilizing CMMI- ACQ <br />The best practices encompassed in the CMMI-ACQ drove quality throughout the IT acquisition model of GM<br />
  8. 8. Case Study 2<br />Implementation by a leading telecom giant to improve the quality of the entire software development process<br />
  9. 9. Objective and Challenge <br />Objective: <br />Improve the quality of the entire software development process and ensure CMMI Level 2 process quality for all key process areas (KPAs)<br />Business Challenge:<br /><ul><li>Volatile requirements
  10. 10. Absence of formal estimation processes
  11. 11. Lack of proper documentation
  12. 12. No rationale for estimates - incorrect estimations
  13. 13. Change in project Plans during project
  14. 14. High degree of post release defects handled by the support team – No feedback to Dev team
  15. 15. Review process was inadequate enough to analyze the review data captured
  16. 16. Any process addition or process improvement initiative was looked upon as a cost to the product lifecycle
  17. 17. The organization culture focused on defect management rather than defect prevention</li></li></ul><li>Solution<br /><ul><li>Gap Analysis – As it is – To Be
  18. 18. Process action teams - Address these gaps
  19. 19. Looked at individual KPAs and tried to address the gaps in the same
  20. 20. Requirement management measures and change management process were defined for the key projects
  21. 21. In project planning, new project management roles were defined.
  22. 22. A methodology for tracking effort was laid down and a tool was created and implemented to track efforts
  23. 23. A new estimation methodology was drafted.
  24. 24. Quality planning was also implemented along with core project metrics which were then regularly reviewed.
  25. 25. A new approach to configuration management procedure was proposed along with necessary templates.
  26. 26. Change management metrics were defined and software configuration management planning, change control, status accounting and configuration audits were implemented.</li></li></ul><li>Business Benefits<br /><ul><li>Specific pain areas identified by the client were addressed and new processes defined to address the same.
  27. 27. The client was assessed at CMMI Level 2 maturity after implementing and practicing the recommended process changes.
  28. 28. The Wipro consultants also identified gaps in the existing process with respect to CMM Level 3 requirements which helped the client in drawing up the future roadmap.</li></li></ul><li>Conclusion<br />

×