I am trying to setup a repository of reusable code. I was thinking about having each reusable code module have a certain “Maturity Level” rating. The rating would be defined as the level at which a reusable code lies within a certain set of requirements. The highest maturity level will be the highest degree of standard across a predefined set of requirements.
For example:
Level; Requirements; Description
Level 0; Code is legal to use; Is the code legal to use in commercial industry/across multiple contracts/etc?
Level 1; Base codeline and meets level 0 requirements; Prototyped code, 3rd party tools, etc
Level 2; Has Function Interface and comments and meets level 1 requirements; Sufficient documentation for each class and function; Able to determine functionality from comments
Level 3; Adheres to coding standards and meets level 2 requirements; Follows defined coding standards and passes code checking utility test
Level 4; Includes test cases and meets level 3 requirements; Has sufficient test cases to test all functionality of code
Level 5; Approved by reuse committee and meets level 4 requirements; Reviewed by reuse experts and peers and verified it meets all levels of maturity
I’m wondering if this maturity level should be a hierarchical structure, where in order to move to the next level you need to meet the requirements of all previous levels (as I have shown above)?
Or if it should be a subset of requirements to meet the next level?
For example, we have meet x out of y requirements, we can move to the next level (requirements would be the same as mentioned above).
Level 0, meets 0 out of 6 requirements
Level 1, meets 1 out of 6 requirements
…
The problem I see with the subset approach is some requirements should have a stronger weighting, and in this approach that will not be taken into account (unless I start getting specific like, meets a out of b and x out of y, etc). But then it could start to get complicated.
Has anyone done this before, and if so, how did you setup your library? Do you have a maturity level at all or some other structure? Any input would be greatly appreciated.
Setting up a code reuse repository is a difficult task. The main difficulty is not in how you set it up but in how you communicate the existence of the various libraries in the repository. Reuse libraries only good if they are used, and they are only used if they are known, and they are only used widely if the quality of the code is high and if it meets the needs of the users.
I like the idea of maturity levels, but as others have posted, there is probably quite a bit of setup/build work to do. I have thought of a similar approach to builds of an application – I called them confidence levels. In the application-build arena, a low confidence build is one that did not pass unit tests; a medium confidence might include passing unit tests, but not integration tests, and so on. This was a good mechanism for communicating to QA and users what to expect. A similar mechanism might be appropriate for libraries.
Documentation comments are a must, and must also have as much care put into them as you put into the code. The comments should communicate what, why, where, when, how, which, etc. Your build process should publish the documentation to a well-known location (again, communication is key).
Along the lines of communication, it doesn’t hurt to present from time-to-time just what is there. Again! communication.
So, at a minimum your build of each library should:
As to maturity levels, I would define them with a “level name” and a description of what the level means. Publish the criteria for what it means to move up or down a level. Actually, now that I think about it, perhaps you want a set of orthogonal criteria: a level for the code, a level for the documentation, use-policies (i.e. must have a license for XYZ), and other attributes. I do recommend you approach this in small increments though. At the end of the day, delivering functionality to end-users is what matters.
You have to also communicate a mindset of naturally pushing reusable bits into the repository. Developers have to have incentive to do this usually. Static code checking tools that look for duplication and peer reviews only go so far. Someone has to actually do the work of moving code to the repository.
Finally, I recommend that you use as much tool support as possible in the setup, build, maintenance, and communication of the repository. Otherwise, like any non-code artifact, you will face a certain amount of entropy which lowers the value as the non-code artifact becomes dated.