Abstract

The objective of this paper is to examine in detail the activity of programming as such. In particular, it is concerned with those aspects of requirements analysis and design which are (and can probably only be) embedded into programming itself, regardless of the method or project model that is used. Software development is usually based on a rational organization of work into stages such as requirements engineering, analysis, design, programming, testing, etc. Each is seen as resulting in artefacts which are then further refined and concretized throughout later stages. Different methods are often contrasted to each other with regards to the amount of design that is required before implementation, the looping of stages and the extent of formal documentation which is handed from one stage to the next. However, little evidence can be found that one method is actually better than the others. This paper indicates that one reason might be that programming is poorly understood and that too many methods and process models still wrongly assume that programming simply translates an existing design into code.

Citations