80 likes | 338 Views
COMP3001 Technology Management & Professional Issues: Project Management CMMI and Improving Process Quality Lecture 10 Graham Collins, UCL. graham.collins@ucl.ac.uk. Introduction.
E N D
COMP3001 Technology Management & Professional Issues: Project ManagementCMMIand Improving Process QualityLecture 10Graham Collins, UCL graham.collins@ucl.ac.uk
Introduction • To improve the software development process it is important to implement measurement programs to establish current levels of performance and baselines against which improvements can be measured. • Quality can only be built in during the development process. • The widespread use of Capability Maturity Model (CMM) for software has created increased development as well as confusion in the number of models. Started in 1998, the Capability Maturity Model Integration (CMMI) was an ongoing project to provide a single, integrated framework for improving a wider range of engineering disciplines.
CMMI v1.2 • Capability Maturity Model Integration (CMMI) is a process improvement maturity model for the development of products and services. • It consists of best practices that address development and maintenance activities that cover the product lifecycle from conception through delivery and maintenance. • Purpose of CMMI for development is to help organisations improve their development and maintenance processes for both products and services. From CMMI second edition (for details see last slide)
Why adopt CMMI? • ‘CMMs focus on improving processes in an organisation. They contain the essential elements of effective processes for one or more disciplines and describe an evolutionary path from ad hoc, immature processes to disciplined , mature processes with improved quality and effectiveness.’ Chapt 1 Introduction p 8 CMMI second edition Chrissis et al (details last slide) • ‘It helps identify a place to start a project, develop a framework to prioritise actions and define how improvements will benefit the organisation. It also measures the benefits of a process against those realised from similar projects previously undertaken.’ Eric Cradrow ‘Made to Measure’ Computing 4 January 2007 p 14.
CMM (Capability Maturity Model) • Level 1: Initial, ad hoc development, organized practices for project management absent. • Level 2: Repeatable, development process is intuitive, rather that codified, procedures for project management SCM (software configuration management) • Level 3: Learning and leverage of experience is an important aspect of this level. • Level 4: The organisation’s ability to monitor the success of the project is greatly enhanced if the project goals are set in quantitative terms, and quantitative data is available about the progress of the project. Quantitatively managing the process is the focus of level 4. • Level 5: Process Change Management and Technology Change Management. Defect prevention.
Maturity Levels in the CMM Process Change Management Technology Change Management Defect prevention Level 5: Optimizing Software Quality Management Quantitative Process Management Level 4: Managed Integrated Software Management Peer Reviews Level 3: Defined Requirements Management Software Configuration Management Software Project Planning Level 2: Repeatable
Project Failure • Possible reasons for project failure include poor estimation (discussed session 4 on Earned Value) loose requirements management, inappropriate risk management and poorly engineered solutions etc. The key point is that these can be labelled as ‘process failure’. • ‘For a project to succeed, a key success parameter is the set of processes followed’-Jalote. Although processes are needed to satisfy project goals they are essential for satisfying the objectives of the client organisation. It is essential that there are clear processes in developing a business case as well as the organizations objectives. These should be balanced as indicated by the slides ‘Balanced Scorecard’. • Other categories discussed in session one include not getting buy-in from stakeholders, including not properly communicating with the team.
Further reading • Ahern, D.M. et al, CMMI Distilled, Addison-Wesley, second edition 2004. • Manchester, J., All Change, SIGS Application Development Advisor, Vol 9, No1,p12-15,Jan/Feb 2005. This article covers configuration management, the drivers and why it is important. • Druker, P.F.,The Effective Executive, Butterworth-Heinemann, 1967. A classic in time management, the sections on prioritisation have been discussed by numerous authors since, noticeably Stephen Covey’s book ‘First Things First,1994, which has incidentally the same title as Peter Drucker’s chapter 5. • Jalote, P., CMM in Practice, Addison-Wesley (SEI series in software engineering) 2000. Pankaj carefully distinguishes between the project management and engineering aspects of projects at Infosys. • Kenett, R.S., Baker, E.R., Software Process Quality, Marcel Dekker, 1999. • McGarry et al., Practical Software Measurement – Objective Information for Decision Makers, Addison-Wesley 2002. • Chrissis, M.B., Konrad,M., Shrum, S. CMMI Second Edition Guidelines for Process Integration and Product Improvement, Addison-Wesley (SEI Series in Software Engineering) 2007.