CMMI^® Level 2: Project Planning

Special permission to use CMMI^® for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.02: CMMI^® - SE/SW/IPPD V1.02 (Staged Representation) © 2002 by Carnegie Mellon University, in "CMMI^® Level 2 - Project Planning" is granted by the Software Engineering Institute.

The SEI and CMU do not directly or indirectly endorse Mike Snyman's work.

Our discussion relating to the process areas required for level 2 commenced in the previous article, which a ddressed requirements management. We now turn our attention to project planning.

As one of the seven process areas required to satisfy the requirements necessary for CMMI^® level 2, the main objective of project planning is to establish and maintain plans that would be used to guide the testing project in the execution of the defined activities. Project planning involves creating a testing project plan, communicating with the relevant stakeholders with the aim of obtaining commitment to the plan, and concludes with the maintenance of the testing project plan.

The relationship between project planning and the other process areas is very important, as project planning will establish guidelines that will determine the timing and execution of all the other process- and project-related activities. We will now continue to discuss some of the specific goals and practices of project planning.

[Specific goals are prefixed with SG and numbered sequentially in the CMMI^® models; a specific practice has prefix SP followed by a number in the format x.y, where x refers to the specific goal the practice is mapped to, and y is the practice's sequence number. The specific goal and practice numbering was added by Test Focus Magazine to enable you to map the specific goals and practices back to the CMMI^® model under discussion, which is available at http://www.sei.cmu.edu/cmmi/models/ - sub-editor].

Establish Estimates [SG 1]

The first specific goal is to establish estimates, which include the following:

1. Establish the scope of the project [SP1.1].
2. Establish estimates of project attributes [SP1.2].
3. Define the project life cycle [SP1.3].
4. Determine estimates of effort and cost [SP1.4].

The testing project must identify all the factors that would contribute to the creation of an accurate and reliable plan. To provide confidence in the accuracy of the testing project plans produced, the information used by the testing project manager needs to be reliable.

When identifying factors for planning, the following may provide some guidance:

• the requirements that will form the base of all the testing,
• the tasks and work products to be performed and produced,
• the technical way in which testing will be approached,
• historical data on previously completed test projects, and
• the test methodology that would be used in the project.

It is of the utmost importance that the testing project manager documents and explains his rationale, and provides supporting data to back his proposals and estimates. This would convince the project stakeholders of the relevance and accuracy of planning documentation.

Work Breakdown Structure [SP1.1]

It is important at this stage for the testing project manager to develop a high-level work breakdown structure. The testing manager would use this for the first estimate. The breakdown structure would depict the activities to be completed during the testing project as smaller, but related, objectives. This is where one of the key guidelines of system development is incorporated, namely to divide and conquer.

Estimates [SP1.2]

The next step is to establish estimates for the activities depicted in the work breakdown structure. These estimates would, in most testing projects, look at effort, cost, and schedule. The inputs that could be used by the testing manager may include: source line of code; number of classes and objects; number of requirements (use cases); and number of pages. It is important that data from previous projects be used as a benchmark against which to test any estimates made. From a testing perspective, these inputs enable the accurate estimation of the time needed to construct outputs, such as test strategy, test cases, and test procedures.

Project Life Cycle [SP1.3]

While concerned with developing a work breakdown structure and estimates, it is important to remember that we will, in most cases, be functioning in a predefined project life cycle. This life cycle or methodology could be imposed on the testing team by the bigger organisation, or could have been designed specifically by the testing team or organisation. It is important that we comply with the logical execution of activities and deliverables dictated by the chosen life cycle, and it is thus very important that our testing plan reflects these existing phases and activities. Some software development models that we may come across as a testing team are: Evolutionary, Incremental, Iterative, Spiral, and Waterfall. Each of these has its own internal complexities, which need to be considered during the planning activity.

Identify Risks [SP2.2]

The identification of risks that could affect the accuracy of, and compliance with, the testing project plan is important. Once the risk has been identified, it needs to be analysed for impact, and for the probability of occurrence. The testing project manager could use the following tools in risk identification: risk taxonomies, risk assessments, checklists, structured interviews, brainstorming, performance models, cost models, network analysis, and quality factor analysis. Risks need to be documented and reviewed; agreement with the relevant stakeholders needs to be achieved with regard to the completeness, and correctness of these identified risks. Identified risks must be re-evaluated and updated when a new risk is identified, when a risk is no longer important, or when the project conditions change significantly.

Plan for Resources [SP2.4]

We need to understand the resources required to execute the test plan as defined. Resources are more than the human resources that will be used; they include computer equipment, lab space, software, and other materials - like printing paper. This information is used to expand the work breakdown structure. When planning human resources, the required skills are important; a skills database that references all the available resources, with applicable skills, could simplify this task.

Obtain Plan Commitment [SP3.3]

It is important to note that all of these test-planning activities do not happen in isolation. Testing teams are complicated and interdependent. The idea that the testing manager, or project manager, can dictate timeframes and deliverables to the team is outdated. All the team members, or stakeholders, need to be consulted to obtain specific input on tasks and activities planned. This could provide valuable input to all previously mentioned tasks.

In the next issue we continue our journey through CMMI^® level 2, looking specifically at Project Monitoring and Control.

Mike Snyman

References:

CMMI^® for Systems Engineering /Software Engineering/Integrated Product and Process Development, Version 1.02: CMMI^®-SE/SW/IPPD, V1.02 (Staged Representation)

®       Capability Maturity Model, Capability Maturity Modelling, Carnegie Mellon,CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.