Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Range of Methodologies
This design methodology works well for system-integration projects. In practice, it is lightweight; the two subproject teams are small, and the final design documentation is minimal. You will have observed that it has no object analysis, no collaboration diagrams, and no use case diagrams. The subprojects may use these techniques, if desired. As long as the 1,000 lines of code rule is followed, there is no need to have any complex models for the long-term design documentation.
Of course, the methodology is unsuitable for other kinds of projects, such as redeveloping a batch program for online use, implementing a data warehouse, or re-engineering a large monolithic application into smaller components. It is my belief that we need a range of different methodologies targeted at these different kinds of projects.
In many cases, the business requirement is for change that includes elements from several different kinds of project. For instance, in addition to integrating with an existing order-entry application, there might be a requirement to build a new order-entry application for a new line of product. I suggest that this project be handled in a similar way, starting with the task/message flow. Instead of having two subprojects, front end and back end, there are three: front end and the old and new back ends. It might be necessary to go through a prototype of the Web design before finalizing the task/message flow.
In summary, my approach is to have subprojects working with the methodology that suits them, rather than imposing some monstrous methodology on the whole project and to use high-level design and planning processes, techniques such as task/message flow, to provide the necessary coordination.