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”, never from anyone who understands agile though.
- In order to define an appropriate level of documentation for your process you need continuously evaluate value of documentation for the process and for execution on DOM vs. the cost of producing and supporting it.
Next, in no particular order some of great development practices that have been proven to work under broad range of models from clean room waterfall to XP:
- Unit Test written before the code, at best taken all the way to Test Driven Development. Take a look at www.testdriven.com a site with a lot of good references by Eric Vautier and David Vydra.
- Continues Integration. There is a plenty of info on CI and supporting tools. In CI builds I strongly recommend include smoke tests, subset of unit test suite, and a number of management reports. CI scope is typically different for check-in runs and nightly builds.
- Code Review. Somewhat controversial technique which might backfire if not performed properly; I would strongly recommend using tools to facilitate code reviews, in particular I suggest crucible.
- Frequent progress reviews with live demos; I recommend at least bi-weekly.
- Collective Code Ownership (CCO). There is however a plenty of controversy associated with this practice, in particular accountability. I see huge value in eliminating blind spots which CCO offers and recommend introducing “feature” or “area” lead. Under that model CCO still is taken to full extent when it comes to work unit allocation and yet there is a single point of contact for each “area”.