In CMMI, have you noticed the evolutionary path for Process Areas? Infact CMMI Maturity Levels are defined as evolutionary stages of process improvement.

An evolutionary process is a process whose stages consist of expanding increments of the defined process.

Watts Humphrey’s Capability Maturity Model (CMM) was published in 1988. According to him organizations mature their processes in stages based on solving process problems in a specific order. Humphrey based his approach on the staged evolution of a system of software development practices within an organization, rather than measuring the maturity of each separate development process independently.

CMMs focus on improving processes in an organization. CMMI describes an evolutionary improvement path for the processes from ad hoc, immature processes to disciplined and mature processes with improved quality and effectiveness.

In some Process Areas the evolutionary path is very evident. It is detailed below.

Evolutionary paths are expected to be one of the new features in CMMI Next Generation

Measurement and Analysis starts at Maturity Level 2 and becomes more quantitative and statistical analysis at High Maturity levels. Even at Maturity level 3 Verification process area and Validation process area demand analysis of peer review data (SP 2.3 in VER) and validation results(SP 2.2 in VAL).

Requirements Management at Maturity level 2 talks about ensuring alignment between project work products and requirements through reviews and all (SP 1.5). Verification process area at Maturity Level 3 supports this process.

Risk Management begins at Maturity Level 2 (Process Area- Project planning SP 2.2 and Project Monitoring and Control SP 1.3) and becomes robust at Maturity Level 3.

Project Planning process area talks about planning for knowledge and skills needed to perform the project. This is aided by the Organizational Training process area in Maturity level 3 by which people can perform their roles effectively and efficiently.

Project Monitoring and Control talks about issue analysis at Maturity level 2 which becomes much more elaborated at ML5 in Causal Analysis and Resolution Process Area

The Process Area Organizational Process Focus is treated as a younger brother of the PA -Organizational Performance Management

Integrated Project Management at maturity Level 3 talks about establishing an integrated and defined process that is tailored from the organization’s set of standard processes. And Quantitative Project Management at Maturity level 4 talks about composing a defined process quantitatively to help the project to achieve the project’s quality and process performance objectives.

The below picture illustrates the Evolutionary path of the mentioned Process Areas

Evolutionary PAs

“Walking on water and developing software from a specification are easy if both are frozen.” –  Edward Berard

Baseline means ‘A Line which is the Base’. The word baseline may refer to surveying, typography, budgeting, pharmacology, Configuration Management, calculations etc.

In an IT industry, baseline mainly implies

  • A Configuration Baseline – A configuration of software, hardware or a process that is established and documented as a point of reference
  • A Process Performance Baseline (PPB) – A datum used as the basis for calculation or comparison

Configuration baseline

As and when a work product is created and ready for review, it should be labeled as ‘ready for review v0.9’. (The version number may change based on the project’s strategy). And at the same time the work product should be available in the configuration tool. Once the review, rework and verification are completed the work product is ready for approval. There should be an identified approving authority for each work product. After the approval, the work product is baselined. (The baseline string can be ‘baselined v1.0’). Whenever a change is triggered in the work product, initially an impact analysis is triggered. Impact analysis helps to understand the change in cost, schedule, competency requirements, affected work products etc. The Change Control Board (as defined in the project plan) should approve the change in order to update the work product. After update, the work product undergoes review, approval and baselining process ( If the change is a minor, the review process can be skipped as defined in the project plan). The baseline string can be ‘baselined v1.1’or ‘baselined v2.0’depending on whether the change is a minor or major. All the change requests should be recorded and tracked for future reference.

If there is no configuration management, many people have to work on a work product that is altering. It creates copy-over problem, which causes versions of files to be lost. The number of uncontrolled copies of files makes it difficult to determine where the latest version really exists or not.

A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and approved, that thereafter can be changed only through formal change mechanisms.

Process Performance Baseline

Project data is recorded in the organizational metric repository. And from the data, performance baselines are created, in most cases the center line and upper and lower control limits from a control chart on that process execution. These baselines are used as a benchmark for comparing actual process performance against expected process performance and are revisited over a defined frequency.

These baselines are used

  • In project estimation process
  • While setting Objectives for the project
  • As inputs to the process performance models

Baseline helps to monitor current project performance and also to improve the accuracy of future estimates.

In short

A Configuration baseline shows the current state of a configuration item while a Process Performance Baseline shows the current performance of a process.