Parts of the process could be automated and save effort, but the chance will be missed or unrecognised


Parts of the process could be automated and save effort, but the chance will be missed or unrecognised.  There are two related concepts here; lost opportunity to automate part of the business process, and lost opportunity to automate part of the software development process.


The processes of recognizing opportunities to automate software development process are basically the same as those needed to recognize opportunities to automate business process.  A manual process needs to happen relatively frequently to be a candidate for automation.  It needs to be capable of arranging so that semi-skilled staff can do the bulk of the work, with the occasional steer from skilled staff.  The presence of suitable Commercial Off-The-Shelf (COTS) solutions will make automation cheaper.  The need to formalize work and re-organize for automation will make automation more expensive.  Here we assume that Business Analysts will address the opportunities for automation of the business process, we address only automation of the software development process.

Prevention, Amelioration, Cure


Developments of the Schlaer-Mellor variant approach to Object-Oriented Analysis led ultimately to Translation Engines; tools that can produce software from detailed analysis-level models.  The attractive idea of automating all design and code generation is somewhat tempered by the degree of rigour needed in the models and the need to provide mappings from model to platform-specific code.  Both are expensive, though the latter may in theory be purchased ‘off-the-peg’ for common platforms.  The approach is fairly popular in control-rich software domains, but has rarely broken out of this niche.  One specific pattern is of interest; DeCoupleStages deals with preparing software development work for execution by semi-skilled workers (and potentially for full automation).


Modern Agile approaches value skilled workers and tend to go for less automation rather than more.  The rigour needed to support automation should only be undertaken at one point in the development of the product (usually at the point of producing source code), and the benefit of lightweight approaches is in the removal of rigour that is unnecessary when there is no low skill, poorly informed workforce that needs to be kept on track.  Note that removal of rigour should not be equated with removal of discipline.  This is one of the common misunderstandings of agile approaches, which are in general well disciplined but low in rigour.