CBSE Process: issues and Challenges

1. CBSE Process: issues and Challenges From CBSE Landscape document chapter

2. Background • CBSE is the process of building software systems from pre-fabricated software components • Motivation • Improving software quality and • Reducing development costs • However software component technology is still immature and poses many challenges for organisations intending to adopt it • Poorly documented components • Vulnerability risk • Limited adaptability of components • Limited interoperability across component technologies • Component volatility • Many of these problems can be mitigated by a better appreciation of the processes for developing component-based systems

3. CBSE Processes

4. Development with reuse

5. Development process • The planning phase sets out: • Justification, objectives, strategies (methods and and resources to achieve the development objectives) • Tactics ( start and end dates, tasks with duration) for the development project • The development phase implements the agenda set out in the planning phase • The verification phase is intended to verify the extent of “fitness” of various component solutions • The negotiation phase attempts to find an acceptable trade-off between the software components and system being built

6. Design for development with reuse • Component-based system design • Describes how the components that make up the system interact to deliver the desired functionality and, • the appropriateness of particular components and services in different contexts • Provides a good basis for performing impact analysis

7. Design process • Need for formal mechanisms that allow the designer to define architectural elements and their relationships and to support their evolution through levels of abstraction (UML 2.0?, Catalysis, D’Souza ’98; ADLs Shaw, ‘96; Medvidovic ‘00) • The design process starts with the partitioning of the system requirements (services and associated constraints) into logical “components” or “sub-systems” • The initial partitioning is driven by architectural considerations (possibly supported by design patterns that lend themselves to those properties) • Subsequent partitioning is subject to a negotiation process that must take into account business concerns, architectural considerations and software component considerations

8. Management: Maintenance and extended development • The maintenance and extended development of a component-based application poses many risks to the customer (Dean and Vidger ’99) • Nature of the development process • Application domain • System design characteristics • Choice of software components used

9. Summary • Component-based system development is a highly iterative process requiring simultaneous consideration of: • The system context (system characteristics such as requirements, cost, schedule, operating and support environments), • Capabilities of software components in the marketplace • Viable architectures and designs • We have identified the challenges and problems likely to be faced by component-based system developers • The importance of verification has been emphasised and a discussion of the management challenges of component-based systems provided • We have highlighted the importance of the process in mitigating the problems posed by CBD

11. Composition • Need for formal mechanisms to support system composition • System composition proceeds by replacing abstract design level components with concrete ‘equivalents’ and integrating them • Concrete components might be required to fulfil certain constraints (cost, architectural, resource etc ) before a replacement is allowed to proceed • Support for adaptation • For many systems there is need to repair a design “misfit” • The accompanying integration process may make use of some "gluing technology", which may be unrelated to the components: • To provide an interface between components • To adapt incompatible components

12. Verification • Component and system testing is a critical aspect of component-based development • Black-box nature of components • Perception of quality may vary • Extraneous features

13. Testing regimes • To address these problems, component-testing regimes should serve the following aims: • Discovery • Verification • Fitness for purpose • Masking • Adequacy

14. Trust as mechanism for verification • Models of trust • Contractual schemes are intended to provide cover against the effects of unsatisfactory or unexpected performance of a particular product • Certification schemes are based on the belief that certified products have undergone rigorous testing and found to be fit for use (conform to certain quality standards) • Experience-based schemes rely on reputed trust • Local evaluation schemesstrive to establish ‘demonstrated trust’. May be based on • Detailed evaluation • Self certification