System Description Methodology
Jan Burse, created Mar 29. 2009
In Zurich one can find an art nouveau house with the inscription which roughly translates to „Bethink before you begin“. An advice I will adhere to for the follow-up project, since this is not an arbitrary trial balloon but a project that should form the future of the company. A first concession was the writing of a business plan. How should the development of the sales system be advanced, with bethinking until we reach unconsciousness?
Precisely information technology is rich in methods to circumvent the inevitable, namely the writing of code. A near choice would be to apply a multi step process similarly to the original HTA project. A multi step process divides the project in multiple phases therefore it has been named „Waterfall Model“. The classical phases are analysis, design, realization, transition and maintenance.
The opposite of multi step processes are incremental methods based on prototyping. By including prototyping code is produced early on which is further matured so that it can be rolled out. The present project unfortunately excludes this approach. It is problematic to ask for productive increments, as the functionality of the sales system is quite entangled. So when we will publish successive development results for testing, we are nevertheless obliged to the waterfall model.
Our waterfall has already left one step behind. Namely we have identified „Steps“ when we define the IT architecture as part of the analysis phase. We were quite a bit challenged in defining the guidelines to identify the „Steps“. We had in mind that the „Steps“ not only represent single interactions between the user and the system or between the system and the system, but that in some way the desired workflow is represented.
We further require it to be rocket high without any reference to data models, screen masks, etc.. Such artefacts are supposed to be identified during the design phase. The „Steps“ deliver the base material of requirements from which these artefacts are later developed. Because the „Steps“ do not deal with these low level artefacts, a very simple documentation standard was defined. We used pure text not divided by tables and there is also no business rules catalogue. An example of such a description can be seen here.
It turned out, that although the „Steps“ were very abstract, they provide enough guidance to reach code without additional richer documentation. Method wise this means that we decided to combine the design and realization phase. Such a measure is only applicable here, because we have practically no decision paths something virtually impossible in practice. To speak in the pictures of Alistair Cockburn, we directly jump from the cloud to the clam.