Managing Process Architecture and Requirements in a CMMI based SPI project 1

Managing Process Architecture and Requirements in a CMMI based SPI project 1 Author: Filippo Vitiello Abstract When developing or changing a process, and all its related assets, often the process engineers have to face an important issue: how defining an integrated set of processes so that each process element is designed taking in consideration its relationships with all the other interfacing elements. Together with this issue, we also have the need to ensure that all the relevant requirements for the processes and their process assets are fully understood and correctly managed. These objectives are even more difficult to achieve when more persons are working in parallel to the improvement of different process areas. The approach described in the following paper, leverages a defined process architecture and a documented specification of process requirements to ensure integration among the process elements. All the examples are referred to a CMMI based process definition but the most of the concepts are applicable also when adopting process models other than CMMI. Why process integration is important? A necessary condition, to enable process effectiveness, is that all the process areas making up the entire development process could work together without disruptions. This implies that all the process elements and the related assets that support and drive the process execution, are designed and built in a way that takes into account the integration needs among themselves. As process elements and assets we mean a very wide range of things like: policies, processes and procedures descriptions, templates, tools, roles, skill and everything is needed to perform the intended process. Here are some examples of integration problems: A Requirements Traceability Matrix is defined in the scope of the Requirements Management process but it is not related to the traceability system that has been selected or built in support to the Testing activities. A resulting effect could be that Test Cases are not traced to the requirements or that this traceability must be twice documented and maintained in the two traceability systems. An Estimating procedure has been documented but it does not clearly define which input from Requirements Management should be considered as the base for a high level rather than a detailed estimation. This may cause estimates to be unrelated to the requirements. Plans must be developed for the execution of each process area but they are not merged together in a usable (and hopefully simple!) overall project plan. Heterogeneous naming conventions adopted for the different document templates or information elements; this can generate confusion about the meaning and extra effort to repeat almost the same information on multiple different project documents. Poor process integration is often a cause for: information missed along the execution of the process, redundant information documented multiple times, poor process assets usability, unnecessary extra effort. All this has a negative impact on the process efficiency and effectiveness. 1 CMMI is a registered trademark of the Carnegie Mellon Univerity Seite 1 von 6

Key elements to ensure process integration In order to avoid or limit the effect of process integration issues, it is important to identify them as soon as possible and take find a remedy before a new version of the process is being deployed across an organization. Therefore the process engineers (or more in general those people who are responsible to develop and maintain processes and the related assets), should pay attention to the following potential sources of integration issues: Work products which are output of a (sub-) process and that have to be considered in input to another (sub-) process. When the two (sub-) processes are being developed (particularly when they are not developed by the same person) it happens that input and outputs fail to be coupled in the correct way. Particular attention should be given to those work products which are made available to other processes by means of a shared repository (archive), since this as an impact on the repository s design. o Example: the Project Monitoring process expects the Cost Performance Index indicator from the Measurements Process. This last process actually will provide the CPI indicator but just once in a month. This might be an ineffective solution for the objectives of the Project Monitoring process. Constraints or process requirements, that have been identified while designing or while gathering requirements for a (sub) process, and that must be implemented in the scope of another process. o Example: In order to have a Requirements Management Plan integrated in a overall Project Management Plan, the template of this last work product should be designed considering the specific planning needs of the Requirements Management Process. In this case, while developing the Project Planning process, requirements coming from the Requirements Managements process must be taken into account. Interfaces (inputs, outputs and process design requirements) with external processes. This processes are those being outside the scope of the SPI project; for example they may be: Customer processes, Administrative processes, Sales processes, Procurement processes, HR Processes o Example: the Sales process expects as input a cost estimate as soon as the high level design is developed; instead the Estimating process is not designed to produce an estimate before a detailed analysis has been carried out. Terms and definitions for: acronyms, process phases, process roles, organizational roles and functions, work products, databases, naming standards It is important to build, and then systematically use and maintain, a common glossary so that similar terms are not used with different meanings and different terms are not used to mean the same concept. o Example: A Project Planning procedure assigned the planning responsibility to the Project Manager - PM. The Requirements Management procedure says that the changes to requirements should be finally approved by the Project Responsible - PR. Are the PM and the PR the same person? How process architecture can help The main purpose of defining the process architecture is to summarize and enable the management of all the relationships (interfaces) among process elements belonging to the different sub-processes. Then, when a process model (like the CMMI ) is adopted as a reference, the documentation of process architecture will also provide a mapping of the process against the model itself. In CMMI this includes a mapping on the specific and generic goals and practices but, in the method here below outlined, a great importance is given to the CMMI Typical Work Products too. Seite 2 von 6

Here below we are going to explain how the process Archive 1 architecture can be built to support a CMMI based process 1a Archive 3 improvement project and how the process improvement Proc-A ca c3 team can take advantage of using it. 1b The method is particularly oriented to process improvement ac ae Proc-C initiatives aiming to establish Defined and Standard Processes (so aiming Capability Level 3 or higher). Proc-E Nevertheless, this approach is applicable to Capability Level cd Proc-B ed 2 objectives, since we have in any case to establish project a2 Proc-D level Managed Processes. In this case we are likely to consider several different solutions for the different projects b2 Archive 2 2d since we are not aiming to get to a standard process. The process architecture is made of a set of matrixes, at least Figure 1 -Process Architecture one for each Specific Goal (SG) and each Generic Goal (GG). To simplify, we might assume that, each Specific Goal corresponds to at least one distinct sub-process and that, for each sub-process, at least one process description document (i.e. a procedure document) is available or must be created. The approach works also when we have more sub-processes mapped to a same SG (in this case we are going to manage more matrixes for the same goal) or a same sub-process covering more Specific Goals. For example, let us take the Project Monitoring and Control process area; we have 2 SG and we have decided to map these goals against two sub-processes which we have given the following names: Software Project Tracking, and Project Issues Management. For each sub-process we prepare a matrix whose structure is like in the following sample (which, for brevity, includes only the first two specific practices of the CMMI PMC Process Area). Sub-Process: Software Project Tracking CMMI PMC SG1 Process Descriptions INPUTS (Specify From which sub-process) WP From SP/GP Typical Work Product Actual Work Product OUTPUTS (Specify To which subprocess) WP To SP 1.1 Monitor the actual values of the project planning parameters against the project plan. Records of significant deviations Records of project performance.. Seite 3 von 6

Each process engineer (or team) is given the responsibility to fill the matrixes of their responsibility; this task should be performed meanwhile conducting the process analysis (process requirements analysis and solution outline) and completed before starting to develop or modify the process assets. Here is a possible procedure: 1. Analyze each CMMI Typical Work Product (TWP) and decide which must be adopted in the target process (the process to defined or changed). 2. Give a name to the Actual Work Products that will be used in the target process and map them to the TWPs (mostly, more CMMI TWPs will be summarized in a single Actual Work Product but in some cases it may happen the contrary). 3. Identify those Actual Work Products (AWPs) that are an output of the selected process and therefore an input for other sub-processes. Indicate these target sub-processes possibly specifying the practices that will receive the WP in input. When a work product is stored in a repository (archive), this should be specified as well. Finally, do not forget to consider also those inputs directed to sub-process which are outside of the scope of the CMMI framework. 4. Similarly analyze, for each practice, which inputs are necessary and which sub-process they are expected to come from. 5. To facilitate the work, it is important that each input from or output to written on a matrix is copied (possibly automatically) in the related matrixes so that each process engineer can easily see if a new input or output is requested for his own sub-processes. 6. Write the names of all the Process Description documents driving the execution of the practices. It may be a single procedure or a set of procedures, guidelines, work instructions, related tailoring criteria and whatever more is used to describe the way the sub-process is performed. A similar approach should be used for the Generic Goals and Generic Practices, but taking care of the following differences: 1. Since CMMI TWPs are not defined for each GP, we can just define the AWPs by focusing on the most relevant documented information that should support the generic practice. (An example for the PMC Process Area: an AWP for the GP 2.2 may be named Project Tracking Plan and it is supposed to direct all the key monitoring and control activities). 2. Consider the relationship between the GPs and the other Process Areas (particularly the Support Process Areas) as sources of inputs and outputs. For example to support the GP 2.2 Plan the Process is it better to specify all these planning activities and related work products (plans) inside the Project Planning descriptions or is it better to spread them across each sub-process description. Whatever we decide an interface with among all the PAs and the Project Planning PA exist and therefore it should be defined in the architecture. To better understand the relationships among GPs and Process Areas, refer to the CMMI for Development, Version 1.2 at paragraph Process Areas That Support Generic Practices. Once all the matrixes are ready, we have a first version of the entire Process Architecture document. Now each process engineer can systematically review the inputs posted on his own sub-processes by the owners of other sub-processes therefore he will be able to discover Seite 4 von 6

additional interface requirements that could not be seen by simply analysing a focused set of subprocesses. In this way, the process architecture helps to identify the integration issues that ought to be resolved before deploying the processes. In this way collaboration among process engineers is also going to be fostered, since they have to dialogue and negotiate about the interface requirements, to remove integration defects before the can affect the deployed processes and the related assets. Once a first baseline of the architecture is established, a clear responsibility for its maintenance should be assigned. In this way every change (especially changes affecting inputs or outputs) can be accomplished only after reviewing its impact together with the owners of the interfacing processes. The responsible of the process architecture should also be in charge of: facilitating the resolution of integration issues, proposing possible solutions and assuring whether the integration issues have been resolved before starting the deployment of the new process. Managing process requirements Almost in parallel to the development of the process architecture, an analysis of process requirements should be carried on. This is important in order to ensure that the process engineers get to know all the required features for the new process and related assets. Possible sources of process requirements are: Appraisals or gap analyses findings and recommendations. Expectations and issues captured during interviews and workshops with internal and external stakeholders (particularly important those from the Customers and the Suppliers) The process model itself. For CMMI we can consider Goals and Practices as high level requirements to be further developed. Interface requirements (or integration requirements), that are particularly put in evidence while developing the process architecture. Constraints affecting the design of process assets and that may depend on previous design decision (i.e. all the document templates must respect a common documentation standard). All these requirements should be documented in one or more requirements documents to be used as the base for developing the process asset. These Process Requirements documents should contain the following information: The name of sub-processes in scope. A unique ID for each process requirement. The source of the requirement. For the interface requirements, a reference to the Process Architecture document (which input and output they refer to) should be included. The dependencies with other sub-processes. Particularly when the requirement (or any derived requirement) requires to be implemented in the scope of other sub-processes The list of the relevant stakeholders for each requirement. These stakeholders are those to involve in the validation of the outlined process solution. In case of dependencies, the relevant stakeholders list would include the process engineers responsible for the dependent sub-processes. Seite 5 von 6

A specification for each requirement, in order to explicitly outline the projected process solution satisfying the requirement. The process assets affected by the requirement. For each impacted asset, this is a kind of technical specification (minimally a summary description) of the features to be implemented or modified. When the Process Requirements documents are ready they should undergo a peer review together with the Process Architecture. It recommendable that all the process engineers take part at this review; in this way every team member will get an insight about the solutions outlined for all the sub-process. Consequently the team is lead to deepen the process analysis and to discover defects or previously unknown issues like: additional process requirements, redundant solutions, unfeasible or ineffective solutions, requirements not properly assigned, unidentified stakeholders In order to facilitate following the approach in this paper outlined, it is recommendable to adopt or implement a tool (for instance, a database) both for the Process Architecture matrixes and the Process Requirements documents. This choice will make easier the collaborative development of the process elements and will enable an overall control on the entire picture during the project. At the end of the process improvement project, these documents will continue to be a major asset to be maintained and re-used as the base for the future improvement initiatives. Kontakt: Wetterkreuz 19a 91058 Erlangen Tel. +49-(0)9131-9 72 06-XXX Fax +49-(0)9131-9 72 06-200 info@methodpark.de http://www.methodpark.de Autoren: Dipl. Ing. Filippo Vitiello Sr. Consultant Filippo.Vitiello@methodpark.de Seite 6 von 6