Skip to main content

CMMI Process

The CMMI process is utilized when a waterfall approach is required to align with a customer's business process environment.

The CMMI process is linear and the product is typically delivered for a fixed contract price. Requirements are gathered for the entire project at the beginning of the project. They are then developed into a comprehensive set of use cases that further define core requirements and describe user interation and system behavior in detail.

Coding and development, testing, and product delivery is determined by the project workplan and delivery milestones which are set at the beginning of the project during the requirements phase. Requirements added after this phase are considered change requests.

The hierarchy of work items in DevOps for the CMMI process looks like this:

cmmi process

Requirement - Workflow & Life-cycle​

The Requirement work item specifies the functions and product elements the team needs to create. All requirements, including desired user interactions and system behavior scenarios, should be entered into the project backlog at the onset of the project by the Product Owner.

Since requirements are the most used work item, let's break down their life-cycle and how they move through the kanban board. Then we'll briefly cover the other work items. backlog kanban

  1. "New" status - During the Requirements phase, the requirements are added to the backlog with an initial staus of New.

Next Steps: Additional details are added to the requirements in the form of detailed use cases. Ideally, the requirements should get organized and grouped under Epics and Features based on the project work plan and delivery milestones by the Product Owner during this time.

  1. "Active" status – requirements are moved to active status and assigned to a developer in the planning meeting based on the project workplan and delivery milestones. The Development Manager then creates tasks for the requirement as needed and assigns them to the Developer who then implements the criteria specified in the requirement and/or tasks and creates a PR once completed. Creating a PR moves it to the Resolved status. Once the PR is merged it is assigned to the QA Tester by the Developer.

  2. "Resolved" status – once moved to resolved status, the requirement undergoes a process of approval where it must be approved by the appropriate reviewers, the Product Owner, QA tester and Project Manager are "required approver" roles and the requirement must be approved by each before it is moved to Closed.

  3. "Closed" status – once the requirement is approved by all "required approvers" it is moved to Closed.

Requirement - Priority​

Used to rate order of importance for requirements.

  • 1=CRITICAL Product cannot ship without the successful resolution of the work item, and it should be addressed as soon as possible.
  • 2=HIGH Product cannot ship without the successful resolution of the work item, but it does not need to be addressed immediately.
  • 3=MEDIUM Product can ship without the successful resolution of the work item, but it should be a high priority for the next shipment/iteration.
  • 4=LOW Resolution of the work item is optional based on resources, time, and risk.

Requirement - Triage​

The traige field is used to indicate if there are outstanding decisions needed before the requirement is moved to an "Active" status to be worked. This field is also used for the "bug" work item with the same options listed below.

Availble options include:

  • Pending: means the work item has all info needed for a decision to be made and is waiting for the decision
  • More Info: means more info is needed before a decision can be made about the work item
  • Info Received: means that all information needed to make a decision about the work item has been received
  • Triaged: means that a decision has been made

Epic​

The Epic work item represents a large “chunk” of work or a business initiative to be accomplished. For example:

  • High performance
  • Intersection editing
  • External integrations

As noted above, Epics should be added at the beginning of a project so features and requirements can be added under them based on the project work plan and delivery milestones.

Feature​

The Feature work item represents a single shippable component of software. For example:

  • Map interface for discovery and visualization of intersections
  • Ability to query routes using text search
  • Ability to send email notifications from the SLD

Similar to Epics above, Features should added at the beginning of a project so requirements can be added under them based on the project work plan and delivery milestones.

Task​

The Task work item tracks the individual elements of work needed to support the completion/implementation of a requirement. For example:

  • Add standard navigation tools
  • Add basemap widget
  • Add a content panel for map display

Tasks are created and added to "Active" requirements as needed to complete implementation. See Requirement Life-Cycle above.

Bug & Issue​

The Bug work item records a defect with the product and is related to a specific requirement.

The Issue work item tracks unplanned activities and impediments that may impact the completion of meeting a requirement in the planned scope.

Change Request​

The Change Request work item records a new requirement that is a deviation of the orginal agreed upon requiremets and exceeds project scope.

Resources​

Waterfall Best Practices​

  • Strict Sequential Structure - break project development activities into strict, sequential phases. It is critical that time is taken to develop a realistic project work plan and delivery milestones involving the Product Owner, Development Manager in addition to the Project Manager at the beginning of the project before any implentation work is done.
  • Strong Project Documentation - gain a clear understanding of the system early on the project and document with thourough documentation of requirements, use cases, technical design specifications, deliverables criteria, needed team skills, project timeline, test planning, and how the team plans to tackle the project from beginning to end with buy in sign off by client.
  • Utilize Phase Gates Reviews - phase gate reviews, especially at the end of the project initiation and requirements phases will help enure that client stakeholders acknowledge and accept the project budget, timeline, scope of requirements, system bevior and user interaction defined in the use cases prior to code development and implementation.