Process Model for Componentware

  

Figure 1: Component-Oriented Process Model

The main parts are resembling the phases of conventional process models although we explicitly separate business-oriented design from technical design: Analysis, Business Design, Technical Design, Specification, and Implementation. All main development tasks, like Business Design, consist of subtasks like Architecture Design, Component Design, Evaluation, and Search each of which is requiring and/or producing development results. For instance, during some task a so-called Component Design Document is created which may contain several diagrams using the description techniques mentioned in [BRSV98b] and which is reflected in the result structure shown in Figure 1.

The produced documents and other development artifacts serve as interfaces of the main tasks, analogous to ``real'' interfaces of software components. The connections between the tasks, namely, the consistency conditions and the flow of structured development information, are visualized by thick, grey arrows in Figure 1.

Note that there are no arrows between the subtasks (resp. subresults) in a main task (resp. result). This is due to the fact that these subtasks are even closer coupled than the main tasks and are usually developed together. As componentware is based on reusing existing software, it is not plausible, for example, to design the technical architecture (subtask Architecture Design of main task Technical Design) without searching for and evaluating existing technical components (subtasks Search and Evaluation of the same main task).

In contrast to traditional process models, we do not define any particular order on the temporal relationship between the development tasks and their results. We believe that a truly flexible process should be adapted to the current state of the project which is partly determined by the current state of the development documents. According to this state, a given development context, and a set of external conditions, we define so-called process patterns which provide guidelines about the next possible development steps. Details about the proposed result structure and the pattern-based approach can be found in [BRSV98a]. In the following, we describe the tasks (resp. results) and involved roles in more detail.

• Analysis:
• Business Design:
• Technical Design:
• Specification:
• Implementation: