IT Directions« How to become an IT professional | Main | Quality is a moving target »
April 30, 2007Bomb-proof your software development This is the sixth in a blog series on the Future of Programming. So far in the series I have discussed the need for a mature enterprise development capability (whether or not you outsource development work), and ways to leverage such a capability - both as an alternative to packaged solutions such as BPMS tools, and as the basis for engagement with outsourcing suppliers.
My last entry generated enquiries by email. I mentioned that "In my own consultancy work, I provide clients proposing to engage in an outsourcing project with a learning trail that their key technical staff should follow, customized to the particular type of project they are considering" and some people asked for examples. So here is such a learning trail, for Eclipse Plug-in Development using Java.
Note that such a trail can be used both by developers employed by the outsourcing supplier and by those people in your own organization with technical responsibility for the projects concerned. Doing so will ensure that all the people involved have a proper understanding of the technologies and approaches required. This is the first step in establishing the kind of close and mutually supportive working relationship that is necessary if the projects are to succeed.
The second step is to decide what outputs you expect from each project. This will be a lot more than a set of software code modules, since you also need everything necessary for maintaining the solution(s). Most projects take care to produce the various forms of application documentation required by new users, regular users, power users, system administrators, support staff, operations staff, and so on. They may also have a requirements document and/or some form of system specification. However, there are some additional outputs that often get paid only lip service, yet are crucial to success:
- System Architecture. While software documentation is increasingly being integrated into the code itself, as well as into the static/dynamic models used to generate the code, some high-level information should always be kept separate, and its ongoing maintenance treated as a priority. This information includes a description of the system's purpose and how it achieves it, the decisions made about key implementation issues such as concurrent use, deployment considerations, licensing strategy, placeholders for future enhancement, and so on.
- Technical plan. It is necessary to consider up-front the techniques to be used for developing the software, and choose suitable tools with which to implement them. Such techniques range from high-level work management practices, for example the many variants of agile methodologies, to low-level code development matters such as configuration management strategy.
- Quality plan. How will you ensure that (every release of) the application meets user needs? Typically, a combination of strategies is necessary, ranging from code-level practices such as test-driven design and continuous integration through to quality assurance practices based on the principles of Human Interaction Management.
Let's note some things about these documents.
First, such documents are required whether you are implementing business processes via a BPMS, implementing business processes via Model-Driven Architecture, or implementing anything else at all. Whether you are building a stock trading system for a bank or an embedded device driver for a mobile phone, software construction has certain general principles that must be adhered to. The rise of agile thinking, and the associated rise of "New Methodologies" designed to handle requirements changes on the fly, have led many people to abandon tried-and-tested software construction practices as old-fashioned. Beware of throwing the baby out with the bathwater!
Second, the documents do not have to be long. Rather, the shorter the better. As long as they cover the required ground, and are consistent with your actual working practice, 3 pages are always preferable to 30.
Third, if you are not going to keep these high-level documents up-to-date, you may as well not bother creating them at all. Anyone who has ever developed any software at all knows that it always seems to be a moving target. Everything changes under your feet from the very first day. In the white heat of a development project, the extra effort required to maintain high-level documents such as those described above may seem like the last thing you should be worrying about. But actually it is almost the most important thing you can do.
TAKE AWAY
The high-level software project documents described above are not only your personal bomb-proofing - the evidence, if things go wrong, that you personally acted as a responsible professional - but also the bomb-proofing for the project as a whole. Armed with current, complete high-level documentation it is possible to salvage many a software project that appears doomed - certainly such documents make it far easier to hand the work over to a new outsourcing supplier, or take it back in house. Without them, you are working blind.
My first step when engaged to rescue an ailing software project is to make sure that the documents described above are in place and up-to-date - creating them from scratch if necessary, as a retrospective exercise. Before you can make decisions about where to go next, you need to know where you are now.
In the next postings to this blog I will say more about how to guarantee the success of a software development - and show, in particular, how the often-overlooked Quality Plan can be used to make life easier for everyone.
Posted by keithhb in
Business Process Management
• Management
• Service-Orientated Architecture
|
Digg This|
Add to del.icio.us
