Introduction to CMMI Development for Developers
App Dev Manager Darroll Walsh shares an introduction to CMMI development for developers.
The Capability Maturity Model Integrated (CMMI) is a process improvement and appraisal program that integrates with other process improvement programs such as the Project Management Body of Knowledge (PMBOK) and Agile. It works to streamline and standardize all processes and provide a means to have oversight and actionable metrics for Development, Services, Supplier Management, Cyber Maturity, and others.
What I want to do is provide an overview of CMMI Dev from a developer’s perspective. We will be skipping over the project management, business analyst, configuration management, and testing portions of CMMI DEV to focus on the impact of CMMI on a development team. If there is interest in the other roles or capabilities that may be a good topic for a later blog entry. Just note that there is a lot of work that happens before developers get started, even in Agile development.
Let us get started:
The BRS, or Business Requirements Specification is where it all begins, this is the single source of truth. This is where the business requirements that the product owner signs off on. While the developers may be consulted on creating the BRS, this is mainly the responsibility of BA’s. However, this is where a developer can really get to know the application they are developing; a place to get the big picture.
High-level and low-level designs is the architecture documentation that shows how the components of the application is connected. In the high-level design, we would lay out external dependencies and how the users and/or systems will interact with t our system. The low-level design would lay out how internal components interact with each other. Reviewing these would give another developer a very quick understanding of the workings of the application.
The SRS, or Software Requirements Specification, is where the developer documents how the application is going to be built. This is where services are documented, dependencies are laid out, and generally how the code is supposed to work, based on the BRS that was created. This is typically done before the code is written and is a standard task. I know some are asking why we would need to do this. My code is self-documenting. And while I am sure it is, code is spread through hundreds of files and thousands of lines of code. And sometimes the intention is not as clear as we would like. The SRS gives us one document to look at with a clear outline of what we can expect. It outlines use cases and expected behavior in a consistent manor.
After we define what we are going to do, and then write the code, it is time to have someone review what we did. Enter the Code Review. This is not only a good practice to catch any mistakes and ensure that we are following best practices and guidelines, it is a great way to share what the application is doing. The mere act of reviewing the code by a second set of eyes gives us a second person that is familiar with how the code works. As this has become standard practice across most development teams, I will not belabor this one.
Unit Testing is another main stay of most development programs. Unit testing whether done as part of Test Driven Development or done after the code is written, are one of the best ways to make sure future changes do not introduce errors into our code. In a CI/CD pipeline we can make sure that all tests pass before we allow code to be checked in. This helps us keep code in good working order.
Individually there is value in each set of documents above, however, the real gains begin when you can tie all this information together. In the beginning of the requirements gathering process, we start a Requirements Traceability Matrix that allows us to link business requirements, software requirements, code, unit tests, test plans and cases, and user acceptance together. Imagine six months into a large project and a change causes a test case to fail. We can now go back to the requirements, find out what the purpose of that code is, know exactly where the code is for that logic, modify the unit test to catch the new case, and implement a fix within hours, not days.
In the short term, CMMI may seem like overkill, but even on small projects, the knowledge captured by following the process shortens the cycle the longer you are away from the project. Not to mention if you’ve never worked on the project before.
Light
Dark
0 comments