CMMI V1.3: The CMMI Product and Product Integration roadmaps

In a first posting on the CMMI roadmaps for CMMI V1.3, I described how the project roadmap has been improved to deliver an even better result. In this posting I’m covering the product and the product integration roadmap.

What is a CMMI roadmap? A roadmap is a set of CMMI process areas that together serve an organization to identify and implement process improvements. CMMI roadmaps are an effective tool to start with the CMMI continuous representation; thus providing an alternative for the staged approach. Biggest benefit from the CMMI roadmap approach is the alignment of your process improvement initiative with the business goals, ensuring quicker and more effective business results. The CMMI roadmaps are described in a Technical Note, which is published by the Software Engineering Institute.

The CMMI Product roadmap consists of Requirements Development, Requirements Management, Technical Solution, Configuration Management, Verification and Process and Product Quality Assurance. The Configuration Management (CM) process area has been extended with product lines and agile practices, like frequent builds, workspaces for teams and individuals, and automation. The definition of quality attributes (often called non-functional requirements) and architectural requirements has been clarified in the process area Requirements Development (RD), making very clear that this process are is not only about how to handle the functional requirements. This process area also includes information about agile, which explains how to handle requirements in iterations and how to document requirements in user stories, and manage them using a backlog and prioritization. Support for product lines is also included in RD. The Requirement Management (RM) process area has been extended with agile practices, like iterations, backlog, and story cards. Also the relationship between requirements and business needs and value has been emphasized. Examples of how to ensure traceability between requirements and work products are given. The Technical Solution (TS) process area has been extended with product lines and agile practices, like focusing on earlier decisions on which solution to implement, and on how the product will be maintained and the needed documentation to maintain it. Also support for quality attributes has been added, similar as in the process area RD. The process area Process and Product Quality Assurance (PPQA) contains limited information about deploying quality in agile organizations, but this is with a process quality focus, and not from a product quality point of view. The Verification (VER) process area has been extended with product lines and agile practices, like early and continuous verification and continuous integration.

The CMMI Product Integration roadmap consists of Requirements Development, Configuration Management, Technical Solution, Product Integration, Supplier Agreement Management and Validation. The process area Product Integration (PI) now mentions automated builds and continuous integration.  The process area Supplier Agreement Management (SAM) has been clarified; I assume that these clarifications are related to the CMMI for Acquisition (CMMI-ACQ) model that has been developed after CMMI V1.2 was released. In version V1.3, process areas from these two models can now be combined, so SAM can be replaced by for instance Solicitation and Supplier Agreement Development (SSAD) and Agreement Management (AM) from the CMMI-ACQ model if a more elaborated approach to subcontract management is needed. For the changes to the process areas Requirement Development, Technical Solution, and Configuration management, see the product roadmap. Changes to the Validation (VAL) process area have been mostly textual. There are some additions for agile, to support incremental delivery and to provide information  about resolving defects and initiating corrective actions.

My conclusion is that the extensions and clarifications of the process areas have made the product and the product integration roadmap more complete, mainly due to the addition of product lines and agile practices, and of quality attributes. When needed the roadmap can still be extended with other process areas, like Service System Development (from the CMMI for Services model) or Acquisition Requirements Development (from the CMMI for Acquisition model), depending on the business needs and priorities.

A next posting on CMMI roadmaps will cover the process and the measurement roadmaps. Stay tuned!

(Visited 629 times, 1 visits today)
Tags: , , , , , ,

About BenLinders

I help organizations with effective software development and management practices: continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>