Software Development Maturity Model
Copyright (c) 2007 NDP Software. All Rights Reserved
The following table summarizes rough categories of software development maturity within in organization. It was inspired by the CMM (capability maturity model), but in no way tries to emulate it.
To use this table, first you must assess where your organization is. Obviously your organization won't simply fit into one maturity level, but different levels in different areas. For example, it's not uncommon to have source code management tools working well, but no bug tracking system.
Numerous pedagogical theories argue in various ways that you must walk before you can run. (CMM echos this.) What this means for a software organization is that before attempting maturity in one area, focus on improving the areas where you are weakest. This will give you the largest return on your investment. That was the idea behind putting this table together.
| Level 1 | Level 2 | Level 3 |
|---|---|---|
| requirements, product and project management | ||
| have working software; future requirements (un-prioritized, incomplete); process chaotic or ad hoc; success may require heroics; failures; abandoned projects | active project management, consistent successes; published, prioritized requirements (or user stories); fire drills, late or buggy releases; product process defined (although not necessarily followed) | predictable success; agile, efficient, maximize value; institutionalized, optimizing; both strategic and tactical plans, with the ability to be opportunistic; seldom buid low-value features; shared understanding of process; ability to re-prioritize requirements efficiently; reliable estimates; risk management |
| programming team | ||
| individuals build the products | functional team, code ownership, code style guide; shared designs as needed | shared code ownership, shared software designs, patterns and strategy; code style compliance, code reviews; professional development, cross-training; |
| Code | ||
| "Hey, it works!"; siloed knowledge; mine-fields; buggy areas; home-grown solutions; unmodifiable legacy areas | works well; some legacy problem areas; core business concepts validated and documented; duplicate solutions to same problems | collective ownership; consistency; organized; modern patterns and tools; integrated modern tools |
| quality control | ||
| defect tracking system as well as post-its and to-do lists; for QA, everyone chips in, or "sales team looks it over" | defect tracking system, QA plan; functional tests; may have some automated testing, unit testing; most changes go through system | integrated in development; continuous integration, code coverage metrics, other software metrics as needed; QA plan in place and executed |
| programming tools | ||
| tools (editors, compilers, etc.) | modern, professional tools | unified, modern and professional tools |
| source code management and builds (configuration management) | ||
| have source code, backups, numbered releases | modern tool such as svn, cvs, git, p4, etc.; mostly scriptable builds | linkage of code changes to requirements and bugs; visibility and metrics into code; fully-scripted and automated builds; |
| release process | ||
| determined (or delayed) by software quality and feature completion | scheduled based on feature completion at regular intervals; early planning sacrifices features; late sacrifice of quality or ship date | always releasable quality; maintain quality and release date; sacrifice low-value features |
| it, hosting | ||
| part-time, "Hey, it works!" | ||
