The central task of software engineering is to understand the software development process , to describe it, and to develop means of supporting it. These means comprise methods, (specification) languages, and tools. Some of them support single phases (see below) while others support the whole process. However, the integration of these means is still partly unsolved.
The software development process covers the whole software lifecycle , comprising the time from the development of software over the successive maintenance up to the point where the software isn't used anymore.
One of the earliest process models for the software development process is the waterfall model [GJM91]. This model distinguishes the phases of analysis , design , implementation , testing , and maintenance . It has two important drawbacks which software engineers have been trying to improve since then. First, the model supports only a unidirectional view of the software development process, even though it has soon become clear that this is far from being realistic. To the contrary, the phases are not completed one after the other, but there are recursions from later phases back to earlier phases. This problem has been addressed by the extended waterfall model (figure 7.2) which uses loops back from a phase to the predecessor phase. In reality, however, there are recursions back from any phase to all of its predecessor phases.
A second drawback is the separation of a naturally continuous process in discrete phases. This separation, however, is rather to be seen as a logical one, which helps to organise the efforts, than as a suggestion to actually proceed with the development of software following these steps one after the other. One possible attempt to tackle this second problem, choosing a finer granularity, will not overcome the main problem of discretization of a continuous process.
It is clear that, in order to overcome these drawbacks, an explicit modeling of directionality poses problems, and, if all possible directions are described, the model will become very tangled. There are approaches, however, which do try to avoid these problems. They do not emphasize the process itself, but they try to identify the working areas. That is, the phases which were related to a fixed point in time in the process are now discoupled from the time line and rather their intentional aspects are considered.
One of these approaches, the working area model [Nag90], identifies the areas of requirements engineering (RE), formerly analysis, programming in the large (PiL), formerly design, and programming in the small (PiS), formerly implementation. Testing and maintenance disappear as distinct phases for the following reasons: Testing is necessary in each area and also across these, to ensure consistency. Maintenance is considered not to be a separate area, but in fact is comprised of activities from the existing areas.
Moreover, to adequately describe the context of the software development process, additional working areas have been identified, which haven't been dealt with adequately up to know. These areas are project management (which comprises version control as well), documentation , and quality assurance . These socalled nontechnical areas interact with all of the above introduced technical areas, as shown in figure 7.3.
