The purpose of this article is to present the impact of ASD to the software development lifecycle and to show the effects in terms of effort shifting from one phase to another.
Typically, in a software development lifecycle, the following phases can be distinguished:
R = Requirements phase
A = Architecture phase
D = Design phase
C = Coding phase
I = Integration phase
T = Testing phase
M = Maintenance phase
Note that this does not imply that a strict waterfall process is obeyed; even with agile processes, each iteration shows activities that would fall into these phases. Applying ASD to the software development lifecycle has the following effect in terms of effort distribution:
As can be seen from this figure, the effort shifts towards the design phase, but such that the net effect still favours the use of ASD since less effort has to be spent during coding, integration and testing, because ASD’s automatic code generation reduces implementation effort and formal verification reduces testing and rework.
This effect is also compounded to an extent by the fact that ASD allows designers to rapidly discover whether a certain approach to a problem will deliver an acceptable solution. For instance a designer might find that a particular approach leads to an explosion in complexity and decides to refactor a component accordingly. To a project manager this may look like rework that has been forced on his designer by ASD and that the use of ASD is delaying his project. In fact the opposite is true: without ASD the design flaw would have propagated through the lifecycle and would only appear much later, causing much more rework.
This has the following consequences:
- Since project managers have no experience with this effect it is difficult for them to trust the outcome – all their experience with software development tells them that development will take longer than planned. Therefore project managers performing their first ASD project need support, not least to boost their confidence that useful work is actually being done but also that early investment in modelling and verification will lead to less implementation and testing work (and in the longer term even less maintenance work);
- When using ASD, most project managers will try to plan for reaching the end of the design phase based on their conventional development experience, which is regarded as being difficult and unpredictable. Conventionally, a component is considered to be ready for integration when (i) designed, (ii) coded, and (iii) unit-tested; in other words, only when the end of the coding phase has been reached, a component can be integrated with other components and at the end of the integration phase it is known whether this component works together with other components. During the design phase, a designer tries to eliminate risk and provide sufficient information such that a project manager can establish a predictable plan towards the end of the development cycle. In reality, it is often the integration and testing phase that then become difficult and unpredictable to plan since only during these phases feedback is obtained about the completeness and correctness of the requirements and architecture; paradoxically, the feedback only refers to what can be expected – the unexpected is never tested and therefore makes testing insufficient and therefore difficult to plan reliably. However, due to ASD’s verification technology a component is effectively already being designed and unit-tested during the design phase but such that the mathematics guarantee that the composition of all components will work together; with a single push-on-the-button code is then generated. Therefore when using ASD, project managers must realize that reaching the end of the design phase effectively means reaching (almost) the end of the integration phase compared when development would have been executed conventionally. From that point of view, they experience a similar uncertainty as compared when the integration and testing phases would have been entered. The substantial difference being that ASD offers an objective measure indicating when a component is ready;
- At the end of the architecture phase when all the external interfaces have been identified project managers can make an accurate effort/cost estimation for the remainder of the software development plan (i.e. the end of the testing phase). When these external interfaces are modelled in ASD, they contain necessary information that facilitates such estimations and can therefore take away the uncertainty as described before.
For guidelines to make the right architectural/design decissions which will improve the predictability to plan, see the following article: Modelling guidelines to improve predictability