|
Next: Roles of a Component-Oriented
Up: Componentware - Methodology and Process
Previous: Introduction: Componentware Methodology
The characteristics of a componentware methodology as described in Section 1 require a suitable process model. Such a process model should itself follow the componentware paradigm: it should consist of a box of building blocks which can be individually tailored to the specific needs of the actual project. There should also be a strong focus on reuse and architectural issues.
- New Tasks and Roles
- To leverage the technical advantages of componentware and to support the reuse of existing components, the introduction of new tasks accomplished by individuals or groups in new roles is immanent. This pertains to roles like Component Developer and Component Assembler , and to tasks like searching for existing components and evaluating them before their integration into the overall system architecture. The initial elaboration and the continued development of such an architecture requires further tasks like architecture design to be performed by special roles like system architects.
- Adaptability and Flexibility
- The rigidity of traditional, prescriptive process models is widely felt as a strong drawback, and there is common agreement about the need to adapt the process to the actual needs. A flexible process model should be more modular and adaptable to the current state of the project, much in analogy to the essential properties of components and componentware systems themselves. To provide the necessary flexibility, our approach uses so-called ``Process Patterns'' (cf. [Cop94,DW98,BRSV98a]).
- Combining Top-Down and Bottom-Up Development
- With componentware, the successful combination of top-down and bottom-up development is essential. On the one hand, one has to take into account the initial customer requirements, breaking them down into components in a top-down fashion until the level of detail is sufficient for implementation. On the other hand, one has to reach a high reuse rate of existing components. Hence, one starts with existing, reusable components, which are then iteratively combined and composed to higher-level components in a bottom-up fashion. Obviously, neither pure bottom-up nor pure top-down approaches are practical in most cases. New process models, like the Rational Unified Process [Iva99] or the German V-Modell [IAB98] already try to resolve these both aspects by defining an iterative and incremental process.
- Evolutionary Approach
- The introduction of new roles and tasks is a key aspect of a process model tailored to componentware. However, this doesn't imply that the process model in question has to be completely new and revolutionary. After all, componentware is itself an evolutionary approach based on the technical foundations of earlier paradigms like object-orientation. Therefore a proposed process model for componentware should represent an adapted and improved version of established practice. In [ABD+99] we have outlined how the German V-Modell standard can be tailored to componentware, focusing on reuse issues and process patterns.
Next: Roles of a Component-Oriented
Up: Componentware - Methodology and Process
Previous: Introduction: Componentware Methodology
Andreas Rausch
3/22/1999
contact the organizers
download the PDF file
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2004
by Carnegie Mellon University
URL: http://www.sei.cmu.edu/papers/41/node2.html
Last Modified: 3 February 2003
|
