CBSE Process: issues and Challenges

1. CBSE Process: issues and Challenges Gerald Kotonya Computing Department Lancaster University United Kingdom

2. Organisation • Background • CBSE Process • Elements of CBSE Process • Conclusions

3. 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

4. CBSE Processes

5. Development with reuse

6. 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

7. RE for development with reuse • Good requirements engineering is essential for successful component-based system development (Ncube and Maiden, ’99) • Basis for component specification • Basis for initial system design • Critical for understanding change impact • Challenge • To develop requirements models and methods that allow us make the best use of the available component technology • By balancing aspects of requirements with the capabilities offered by software components, and the architectural assumptions embodied in the software components

8. Requirements engineering • Need to understand the system requirements from ‘external perspectives’ (Kotonya ’99, Nuseibeh ’98) • Component-based systems development is primarily a problem of integrating black-box components rather than creating components • Need for mechanisms that allow us to model the behavioural and non-behavioural properties • Most requirement methods are concerned with functional properties of system • Service modelling? Analysis by contract? etc… • Need to provide a mechanism for evaluating and ranking requirements • Cost-value analysis (criticality, effort, risk, stability etc)

9. Requirements engineering (contd.) • Need for schemes that support negotiation (PORE, AHP, SMART) • In practice the desired level of component software capability and quality is rarely achieved • Early evaluation is useful for establishing the availability and broad capabilities of off-the-shelf software components • For certain critical requirements, a component (COTS) solution may not be adequate or even appropriate • Need requirements schemes that reflect the changing ‘face’ of software component technology • Component as a leased service • Component as an off-the-shelf black-box software

10. 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

11. 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

12. Design process (contd.) • Need for mechanisms that allow the designer to evaluate the extent of “fitness” of a component or group of components in a context • The main objective of designer is to achieve “fitness for use” • Fitness is a property which is achieved when a component has an acceptable match with the context in which it is going to operate.

13. 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

14. 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

15. Complications • Poor specification • The lack of detailed component specification diminishes the quality of testing that can be done. • Enterprise heterogeneity • Different, possibly competing vendors may supply components • Technological heterogeneity • In a distributed environment, different components may be developed for different hardware and operating system platforms • Test adequacy assessment • A major problem with testing component-based systems is the lack of a sufficient theoretical basis for assessing the adequacy of the tests • Inability to perform ‘direct’ tests • As in the case of web services

16. Suggested solutions • Voas (Voas, ‘98) the risk posed by unreliable components should lead developers to think in terms of disposable software systems • Dean (Dean ’99) independent certification of components is the way to address the problem, particularly for critical systems • Harrold (Harrold ’99) the component vendor should make a summary of the test and analysis information available with the component • Others have suggested that components have built in tests (e.g. IST COMPONENT+)

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

18. 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

19. 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

20. Elements of risk • Different vendor-customer evolution cycles • Funding risk • Vulnerability risk • Upgrade risk • Hidden incompatibilities • New data formats that may require that the contents of existing files and databases be modified • Changes in the quality attributes • Additional capabilities that may have to be suppressed or restricted due to security concerns • Incompatibility with the existing hardware or operating platform • Changes in system resource requirements may be incompatible with the existing hardware and operating system

21. Addressing the risks • Asset management • Need for mechanisms for managing and tracking the acquisition, usage and evolution software components • impact analysis • Need for impact analysis techniques. • The system management process must consider the different ways that a component might cause changes to the operational system • Quality control • Need for cost-effective quality control methods that address the problem of the fault identification, repair, and the tracking of system fixes. • Configuration management • Need for a framework for tracking and controlling the versions of components and custom software installed at all sites • Market research

22. 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