A Descriptive Approach to the Software Development Process

Form-oriented analysis proposes artifacts for modeling. These artifacts are accompanied by recommendations on when and how to produce these artifacts. However, these recommendations must not be misunderstood as prescriptions - form oriented analysis is a descriptive approach to software development. This means, first and foremost, that it should not be used to restrict the working software developer in any way. For example, we propose a couple of artifacts for the visualization of our form-oriented information system models, i.e., screen diagrams, page diagrams, form storyboards, formcharts, which differ with respect to granularity, comprehensibility, and preciseness. Coarse grain modeling is motivated by certain demands of the requirements elicitation process, e.g., the need for lightweight communication with the domain expert, or a desired jump start to modeling. However, the different kinds of form-oriented artifacts can not only be exploited in one defined proceedings. The arguments of form-oriented analysis aim at empowering the developer, they aim at improving the modeling of enterprise systems under the overall umbrella of artifact orientation. Ideally, form-oriented analysis provides the conceptual underpinning for some personal best working practices that the developer has already discovered by him- or herself, though in an ad hoc manner, or that he or she has learned from a colleague - typically from a senior developer.

In a wider sense, the descriptive approach has several properties, which are not mutually exclusive: Software development methods can have a product model aspect and a process model aspect. Different software development methods can put different foci on these aspects. Actually, we argue that a concrete software development method can be advantageous with respect to product modeling even without reference to any process model. As we have already mentioned, form-oriented analysis techniques and tools are orthogonal to process model aspects, too.

Form-oriented analysis focuses on conceptual insight. It tries to foster a precise understanding of the certain widespread class of enterprise applications. This does by no means imply that we do not propose concrete formats, concrete tools, and concrete activities. It just means that concrete formats, concrete tools, and concrete activities are subject to concrete elaboration and must not be overemphasized, i.e., they must not be considered more important than the understanding of the system semantics.

The form-oriented analysis approach does not strictly follow any other dominating paradigm. This does not mean that it is completely decoupled from proven techniques and concepts defined so far in the software development community. On the contrary, we believe that form-oriented concepts can be also used in scenarios where other techniques are already sucessfully established. It just means that form-oriented analysis is free from the dictates of other paradigms and metaphors.

Similarly, form-oriented analysis is not restricted to a certain modeling level or process stage, say, requirements specification, analysis or design. As a holistic approach form-oriented analysis is open for equal discussions of all kinds of problems the working software engineer is faced with. The only restriction of form-oriented analysis is a self-restriction: it does not aim at being a general purpose approach, but utilizes assumptions about the systems that it is designed for.