Download
1 / 57
600 likes | 959 Vues
Process improvement. Topics covered. The process improvement process Process measurement Process analysis Process change The CMMI process improvement framework. Process improvement.
E N D
Topics covered • The process improvement process • Process measurement • Process analysis • Process change • The CMMI process improvement framework
Process improvement • Many software companies have turned to software process improvement as a way of enhancing the quality of their software, reducing costs or accelerating their development processes. • Process improvement means understanding existing processes and changing these processes to increase product quality and/or reduce costs and development time.
Approaches to improvement • The process maturity approach, which focuses on improving process and project management and introducing good software engineering practice. • The level of process maturity reflects the extent to which good technical and management practice has been adopted in organizational software development processes. • The agile approach, which focuses on iterative development and the reduction of overheads in the software process. • The primary characteristics of agile methods are rapid delivery of functionality and responsiveness to changing customer requirements.
Process and product quality • Process quality and product quality are closely related and process improvement benefits arise because the quality of the product depends on its development process. • A good process is usually required to produce a good product. • For manufactured goods, process is the principal quality determinant. • For design-based activities, other factors are also involved, especially the capabilities of the designers.
Quality factors • For large projects with ‘average’ capabilities, the development process determines product quality. • For small projects, the capabilities of the developers is the main determinant. • The development technology is particularly significant for small projects. • In all cases, if an unrealistic schedule is imposed then product quality will suffer.
Process improvement process • There is no such thing as an ‘ideal’ or ‘standard’ software process that is applicable in all organizations or for all software products of a particular type. • You will rarely be successful in introducing process improvements if you simply attempt to change the process to one that is used elsewhere. • You must always consider the local environment and culture and how this may be affected by process change proposals. • Each company has to develop its own process depending on its size, the background and skills of its staff, the type of software being developed, customer and market requirements, and the company culture.
Improvement attributes • You also have to consider what aspects of the process that you want to improve. • Your goal might be to improve software quality and so you may wish to introduce new process activities that change the way software is developed and tested. • You may be interested in improving some attribute of the process itself (such as development time) and you have to decide which process attributes are the most important to your company.
Process improvement stages • Process measurement • Attributes of the current process are measured. These are a baseline for assessing improvements. • Process analysis • The current process is assessed and bottlenecks and weaknesses are identified. • Process change • Changes to the process that have been identified during the analysis are introduced.
Process measurement • Wherever possible, quantitative process data should be collected • However, where organisations do not have clearly defined process standards this is very difficult as you don’t know what to measure. A process may have to be defined before any measurement is possible. • Process measurements should be used to assess process improvements • But this does not mean that measurements should drive the improvements. The improvement driver should be the organizational objectives.
Process metrics • Time taken for process activities to be completed • E.g. Calendar time or effort to complete an activity or process. • Resources required for processes or activities • E.g. Total effort in person-days. • Number of occurrences of a particular event • E.g. Number of defects discovered.
Goal-Question-Metric Paradigm • Goals • What is the organisation trying to achieve? The objective of process improvement is to satisfy these goals. • Questions • Questions about areas of uncertainty related to the goals. You need process knowledge to derive these. • Metrics • Measurements to be collected to answer the questions.
GQM questions • The GQM paradigm is used in process improvement to help answer three critical questions: • Why are we introducing process improvement? • What information do we need to help identify and assess improvements? • What process and product measurements are required to provide this information?
Process analysis • The study of existing processes to understand the relationships between parts of the process and to compare them with other processes. • Process analysis and process measurement are intertwined. • You need to carry out some analysis to know what to measure, and, when making measurements, you inevitably develop a deeper understanding of the process being measured.
Process analysis objectives • To understand the activities involved in the process and the relationships between these activities. • To understand the relationships between the process activities and the measurements that have been made. • To relate the specific process or processes that you are analyzing to comparable processes elsewhere in the organization, or to idealized processes of the same type.
Process analysis techniques • Published process models and process standards • It is always best to start process analysis with an existing model. People then may extend and change this. • Questionnaires and interviews • Must be carefully designed. Participants may tell you what they think you want to hear. • Ethnographic analysis • Involves assimilating process knowledge by observation. Best for in-depth analysis of process fragments rather than for whole-process understanding.
Process models • Process models are a good way of focusing attention on the activities in a process and the information transfer between these activities. • Process models do not have to be formal or complete – their purpose is to provoke discussion rather than document the process in detail. • Model-oriented questions can be used to help understand the process e.g. • What activities take place in practice but are not shown in the model? • Are there process activities, shown in the model, that you (the process actor) think are inefficient?
Process exceptions • Software processes are complex and process models cannot effectively represent how to handle exceptions: • Several key people becoming ill just before a critical review; • A breach of security that means all external communications are out of action for several days; • Organisational reorganisation; • A need to respond to an unanticipated request for new proposals. • Under these circumstances, the model is suspended and managers use their initiative to deal with the exception.
Key points • The goals of process improvement are higher product quality, reduced process costs and faster delivery of software. • The principal approaches to process improvement are agile approaches, geared to reducing process overheads, and maturity-based approaches based on better process management and the use of good software engineering practice. • The process improvement cycle involves process measurement, process analysis and modeling, and process change. • Measurement should be used to answer specific questions about the software process used. These questions should be based on organizational improvement goals.
Process change • Involves making modifications to existing processes. • This may involve: • Introducing new practices, methods or processes; • Changing the ordering of process activities; • Introducing or removing deliverables; • Introducing new roles or responsibilities. • Change should be driven by measurable goals.
Process change stages • Improvement identification • This stage is concerned with using the results of the process analysis to identify ways to tackle quality problems, schedule bottlenecks or cost inefficiencies that have been identified during process analysis. • Improvement prioritization • When many possible changes have been identified, it is usually impossible to introduce them all at once, and you must decide which are the most important. • Process change introduction • Process change introduction means putting new procedures, methods and tools into place and integrating them with other process activities.
Process change stages • Process change training • Without training, it is not possible to gain the full benefits of process changes. The engineers involved need to understand the changes that have been proposed and how to perform the new and changed processes. • Change tuning • Proposed process changes will never be completely effective as soon as they are introduced. You need a tuning phase where minor problems can be discovered, and modifications to the process can be proposed and introduced.
Process change problems • Resistance to change • Team members or project managers may resist the introduction of process changes and propose reasons why changes will not work, or delay the introduction of changes. They may, in some cases, deliberately obstruct process changes and interpret data to show the ineffectiveness of proposed process change. • Change persistence • While it may be possible to introduce process changes initially, it is common for process innovations to be discarded after a short time and for the processes to revert to their previous state.
Resistance to change • Project managers often resist process change because any innovation has unknown risks associated with it. • Project managers are judged according to whether or not their project produces software on time and to budget. They may prefer an inefficient but predictable process to an improved process that has organizational benefits, but which has short-term risks associated with it. • Engineers may resist the introduction of new processes for similar reasons, or because they see these processes as threatening their professionalism. • That is, they may feel that the new pre-defined process gives them less discretion and does not recognize the value of their skills and experience.
Change persistence • The problem of changes being introduced then subsequently discarded is a common one. • Changes may be proposed by an ‘evangelist’ who believes strongly that the changes will lead to improvement. He or she may work hard to ensure the changes are effective and the new process is accepted. • If the ‘evangelist’ leaves, then the people involved may therefore simply revert to the previous ways of doing things. • Change institutionalization is important • This means that process change is not dependent on individuals but that the changes become part of standard practice in the company, with company-wide support and training.
Software Process • A software process is a road map that helps you create a timely, high quality result. It is the way we produce software and it provides stability and control. • Each process defines certain deliverables known as the work products.These include programs, documents, and data produced as a consequence of the software engineering activities.
CMMI - History • In 1986, in response to a request from the US Department of Defence to provide a method of assessing the capability of contractors to produce software on time and within budget, the SEI began the development of a process maturity framework. • The primary aim of the CMM was to determine an organisation's capability by measuring the degree to which processes are defined and managed. The CMM describes an evolutionary path from an immature, ad-hoc software process to an optimising, disciplined and mature process.
CMMI - History • CMM's success had led to the development of similar models addressing systems engineering (SE-CMM), integrated product development (IPD-CMM), software acquisition (SA-CMM), and human resources (People CMM). • The CMM Integration project was formed to sort out the problem of using multiple CMMs. As the name suggests, the CMMI is a model that combines three source models – the Capability Maturity Model for Software, the Alliance Interim Standard (EIA/IS) 731, and the Integrated Product Development Capability Maturity Model (IPD-CMM).
CMMI - History • The CMM (Software CMM) was the first capability maturity model adopted by software development companies • The CMM has been retired, and CMMI replaces it. • The SEI no longer maintains the SW-CMM model, its associated appraisal methods, or training materials, nor does the SEI offer SW-CMM training. All SW-CMM appraisal results expired on December 31, 2007. After December 31, 2007, all SW-CMM ratings will be considered invalid and should not be advertised.
CMMI • CMMI has two representations, i.e. staged and continuous • The staged representation uses a maturity levels and is a systematic and structured way to approach process improvement one step at a time. • The continuous representation uses capability levels to measure process improvement. The continuous representation is a flexible way to improve process performance as organisations are allowed to improve any single process areas or group of process areas.
Maturity Level Staged Representation 1 Initial 2 Managed 3 Defined 4 Quantitatively Managed 5 Optimizing CMMI - Staged • Staged representation • Maturity levels, which belong to the staged representation, apply to an organisation’s overall maturity. There are five maturity levels, numbered 1 through 5. Each maturity level comprises a predefined set of process areas.
CMMI - Staged • Staged representation Staged
CMMI - Staged • Process Areas: A process area is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. All CMMI process areas are common to both continuous and staged representations. • Specific Goals: Specific goals apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied. • Specific Practices: A specific practice is an activity that is considered important in achieving the associated specific goal.
CMMI - Staged • Example • Process Areas– Requirements Management • Specific Goals– SG 1 Manage RequirementsSpecific Practices: • SP 1.3-1 Manage requirements changes • SP1.5-1 Identify inconsistencies between requirements
SPI Model – CMMI - Staged • Generic Goals: In the staged representation, each process area has only one generic goal. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area. Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied. • Genetic Practices: Generic practices provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable, and lasting. Generic practices are categorized by generic goals and common features and are expected components in CMMI models.
CMMI - Staged • Example • Process Areas– Requirements Management • Generic Goal– SG 2 Institutionalize a Managed Process • Generic Practices: • GP 2.2 Plan the process • GP2.3 Provide resources • GP2.5 Train people
CMMI – Level 1 Initial • Ad-hoc software process • System development projects follow no prescribed process. • Each developer uses his or her own tools and methods. • Success or failure is usually a function of the skill and experience of the project team. • The process is unpredictable. • Documentation is not consistent from one project to the next, thus creating problems for those who must maintain a system over its lifetime
CMMI – Level 2 Managed • Project management processes and practices are established to track project costs, schedules, and functionality. • The focus is on project management, not system development. • Results of project management are reasonably predictable. • The necessary process discipline is in place to repeat earlier successes on projects with similar applications. • Experience from previous projects is gathered
CMMI – Level 3 Defined • A standard system development process (sometimes called a “methodology”) is purchased or developed. • The process is stable, predictable, and repeatable. • The software process for both management and engineering activities is documented and standardized for all software projects. • Success is achieved by the process (hero’s are expected). • Foundation is laid for major and continuing progress. • All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
CMMI – Level 3 Defined • Creates a group within the organization responsible for software process activities, called Software Engineering Process Group (SEPG). • Organization-wide training programs are established to ensure that staff has the necessary skills and knowledge to be able to fulfil their roles. • Management has good insight into the progress of the projects.
CMMI – Level 4 Quantitatively Managed • The process is in statistical control, so that special causes can be distinguished from common causes and the quality of the process can be controlled. • Detailed measures of the standard system development process and product quality are routinely collected and stored in a database. • Both the software process and products are quantitatively understood and controlled. • Organisation-wide software process database is established. • Managers have quantitative metrics for making decisions.
