Z26 Project Management CMMI and Improving Process Quality Lecture 5 a Graham Collins, UCL

Introduction  Important to implement measurement programs to establish current levels of performance and baselines against which improvements can be measured.  One approach to improve quality for software development and allied fields is the implementation of a software quality program (SQP).  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 engineering disciplines.

Requirements  Does the software, accurately capture what the customer requires?  These include functional, and performance as well as maintainability and interoperability.  The significance is that the requirements are in effect quality requirements.

Software Quality Program Requirements establishment, Implementation and Control SQP Methodology and procedures establishment and control, requirements analysis, design, test, code, configuration management Software quality evaluation, products (algorithms), activities and methodologies

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 Requirements Management Software Configuration Management Software Project Planning Integrated Software Management Peer Reviews Software Quality Management Quantitative Process Management Level 2: Repeatable Level 3: Defined Level 4: Managed Process Change Management Technology Change Management Defect prevention Level 5: Optimizing

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  Manchester, J., All Change, SIGS Application Development Advisor, Vol 9, No1,p12-15,Jan/Feb This article covers configuration management, the drivers and why it is important.  Druker, P.F.,The Effective Executive, Butterworth-Heinemann, 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) 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,  McGarry et al., Practical Software Measurement – Objective Information for Decision Makers, Addison-Wesley 2002.