| Once, software developers believed it was possible to create the technical software design for a comprehensive system completely, correctly and free of contradictions right at the beginning of a project. Many projects proved though that this ideal approach can hardly be realized. More often it causes significant problems.
A typical example of this fact are those requirements that were either unknown or not taken into consideration at the beginning of a project and thus were not integrated into the original system design. Later on, integration of these disregarded requirements into the project is much more difficult. If the developers are lucky, the requirements will fit seamlessly into the existing system. However, this is rarely the case. So-called ‘work-arounds’ are needed. These enable developers to meet the requirements within the system, even though the actual software design is not suitable for such an approach.
One problem of these work-arounds is that they cause a gradual degeneration of the system design that leads to a loss of structure. The more work-arounds are built into the system, the more difficult it becomes to recognize and apply the original software design. Often developers describe such a system as ‘historically grown.’
Today, many development methods have a different approach to software design. Especially agile development methods – most prominently extreme programming – no longer treat software design as a clearly and rigidly defined constant that is defined at the beginning of a development project. Instead, they assume that a software design emerges step by step during the development process. If it is continuously adapted and improved to meet present requirements, it is called emergent design. Design improvements become established as an important and independent activity during development and evolve into an integral part of this process. This activity is called refactoring. |
|
|
|