The generic component-based software development process centers around three main activities: component selection, component configuration and instantiation, and composition.
 

Component selection

This activity concerns the hierarchical selection of best fitting components, i.e. components which meet the application requirements best. At the top most level of abstraction, this comprises selecting a system architecture and thereby a functional decomposition into components. Thus, the type of components to be used and their architectural environment are chosen. On the next levels, components and sub-components are chosen from a pool of reusable components to instantiate the architecture. The selection is done with respect to structural constraints as well as functional and non-functional properties.
 

Component configuration and instantiation

In most cases, the selected components will be generic components. As a consequence, they have to be configured and instantiated in order to implement the system (which is, in this context, the custom built run-time platform). Values of generic parameters have to be chosen, determining the concrete properties of the component. Tools will then instantiate the components, i.e., generate their source code.
 

Composition

The instantiated components are successively combined to form larger building blocks, thereby implementing the runtime platform under development. Components to be combined have to be compatible with respect to import and export interfaces, semantics, adherence to protocols, and other aspects of the system architecture. As far as possible, the dependency and compatibility statements are made based on the generic component, i.e., before the decision about exact values of generic parameters are made. In the case where the resulting properties of a configured component can be formulated as a function of the generic parameters and their values, the resulting properties can be predicted prior to component instantiation.
 

Although these activities might anticipate a strict ordering (selection, configuration/instantiation, composition), there are a lot of interdependencies rendering a sequential approach unapplicable. For example, configuring a component can show that the desired properties can not be adjusted, making it necessary to go back and choose a different component. In the same way the selection phase is dependent from the composition phase since only those components should be selected that can sensibly be combined -- as an example on a higher level of abstraction, it is generally counterproductive to combine hard real-time scheduling with virtual memory management. There also dependencies existing between component instantiation and composition. Mismatches found while combining components can, e.g., pose requirements on adaptor components to be configured and instantiated (e.g., if a component is not constructed for remote invocation, it is possible to encapsulate it in an RPC or ROI object which has to be configured accordingly).