There are many very important aspects of SDLC related to s/w development activities which should be implemented whether you outsource or not. Some of them are essential to DOM. Your intermediary whether internal or external must verify that these steps are taken and not just as a checkmark on a SDLC compliance list, they have to be made consistently and to a degree that satisfies the intent.
The first is the code standards. Of course following language naming conventions goes without saying; there are a few more standards that have to be diligently followed:
- All names are in English (classes, variables, methods, etc.) ALL
- Sufficient level of comments, of course in proper grammatically correct English. Developers must understand that they are not required to write essays; they just have to get comments to unambiguous level.
- Same applies to headers, check in notes, etc.
Next is the documentation. Creating the documentation that could be used to learn about the code and its intent, that doesn’t lose concurrency and go stale, and that doesn’t cost you an arm and a leg is not a trivial exercise. As a matter of fact a detailed design / technical design documentation is one of the most controversial topics in s/w development methodology. In a large degree the documentation’s level of detail depends on the SDLC model employed. In particular the level of documentation details digresses considerably with level of agility of the process. That is often exacerbated by a low level of maturity of organizations electing agile methodology. I do not want to get too deep into this topic at this point, just want to point out several mandatory elements:
- High level functional and technical design documentation.
- Functional and technical design documentation at detail level, specific artifacts depend on SDLC methodology, type of the project, rate of change and many other organization specifics.
- Comments in the code written in a standard way that allow JavaDoc or similar tools to generate meaningful documentation is one of the most important steps. Same goes for DB schema.
A couple relevant notes here:
- Waterfall style processes with their high degree of details in documentation, staged delivery and isolated hand-offs work naturally with DOM, in particular when the vendor offers a higher level of CMMI maturity.
- Agile methodologies work exceptionally well DOM unless they are taken superficially. That becomes particular clear in attitude towards documentation. It’s amazing how many times I heard things like “we run agile development process, so we do not do the documentation