Software development process and organisation

When developing components and component-based frameworks, the traditional development methods are no longer sufficient. Top-down methods involving decomposition will be complemented with new approaches. Structured layering and decomposition are combined with object-oriented use cases, scenarios, object class models and design patterns, as well as component-based reuse and composition methods, as shown in Chapter 6 of this thesis.

It is anticipated here, however, that the division of a software development process into incrementally applied requirements definition, design, implementation (or constructing and packaging), and testing phases will prevail. In fact, the incremental approach is well supported by the component technology, based on encapsulation and interfaces.

When considering the software development organisation, a good starting point is a general model of reuse processes and organisation, proposed by Ivar Jacobson. The model defines three software engineering processes, each with a specific responsibility (Jacobson et al., 1997, pp. 232 … 239):

• A Component System Engineering process staffed by a team for each component system. This process designs, constructs and packages components into a component system or framework. The process captures requirements from business models, domain experts, and application end users. The results are used to incrementally architect, design, implement and test components and component systems or frameworks.

• An Application System Engineering process staffed by a team for each application system. This process builds application systems by selecting, customising, and assembling components and frameworks from component systems or frameworks. The process starts with requirements capture from the customer and the end users of the application system. The application system is then incrementally analysed, designed, implemented, and tested – by reusing and specialising components and frameworks. Even if the application engineers try to reuse as much as possible, they often have to analyse, design, and implement system features that have little or no support from the component systems or frameworks.

• An Application Family Engineering process staffed by a team focusing on the definition of the division into systems and the interfaces between them. This process captures the requirements from a range of customers and transforms them into a suite of application systems. The process produces an architecture that defines the layers of the component systems and frameworks. Also make-or-buy decisions are made, concerning applicable component systems or frameworks. Another approach to the component-based software development process is formulated in the developing pattern language (see Chapter 3.3) ComponentDesignPatterns (Brown et al., 1999). The so-called Component Developer Perspective to the Component-Based Development (CBD) process corresponds to the Component System Engineering process above. In the same pattern language, the so-called Component Assembler Perspective corresponds to the Application System Engineering process above. The Component Developer Perspective has, additionally, some similarity to the Application Family Engineering process.

A developer with the Component Developer Perspective analyses the common requirements of the component users and knows how to construct reusable components. The developer focuses on understanding the underlying component object model, and on implementing a solution that can be reused many times in many different contexts. The tasks cover “the burden of multiple-component object models, multiple platforms, and components developed in different programming languages across many address spaces”. Special emphasis is put on quality issues, because the developed software will be used in several application systems.

A developer with the Component Assembler Perspective, on the other hand, adapts, customises, and integrates pre-existing components into the application system. The assembler focuses on delivering a solution that adequately solves the business problem at hand with one or several frameworks and pre-existing components. The tasks are domain oriented and focused on productivity and usability. The developers of ComponentDesignPatterns (Brown et al., 1999) indicate that the component assemblers often only ‘glue’ the components together by scripting and it may thus be difficult for them to discover opportunities to create new components based on their experiences in assembling the solution.

Also Ivar Jacobson notes that when the reuse business is first introduced into the organisation, or if the architecture is simple, it may well make sense to combine an instance of Application Family Engineering and Component System Engineering (Jacobson et al., 1997). When integrating these two software processes, the earlier Jacobson approach co-incides notably well with the more recent Component Developer and Component Assembler perspectives above.

The transition to component-based development leads to a need for learning on both individual and organisational levels. Individuals need to learn new technologies, processes, and tools. The organisation as a whole has to adapt to the new processes and organisational structures gradually, the larger the organisation, the longer it takes to change. Proper pilot projects and management commitment are also needed in this evolutionary process. Tom Vayda has published a list of guidelines (Vayda, 1999) for the transition to component-based development. It is presented here in a somewhat shortened and modified form:

• Start small. Smaller pilot projects and focused business units have a higher probability of success.

• Pick the highest potential gain. Choose business units with high visibility and potential to produce a set of reusable components, or a simple, but mission- critical server system.

• Focus on three time horizons. The introduction of components should produce useful results quickly, but the medium (change in the organization) and long-term (measurable process) targets must not be forgotten.

• Apply both top-down and bottom-up strategies. Both enterprise models of large- scale business processes, and small sets of components are important, for example a component set that implements the security rules of an organization.

• Measure the results. Collect simple but powerful project and process metrics that demonstrate the return on investment. The project metrics could include the amount of reuse, or time or cost per function point. The process metrics include the time and effort spent in various life cycle phases and tasks.

9.3 The approach of this thesis