1 / 22

CBSE Process: issues and Challenges

CBSE Process: issues and Challenges. Gerald Kotonya Computing Department Lancaster University United Kingdom. Organisation. Background CBSE Process Elements of CBSE Process Conclusions. Background.

janna
Download Presentation

CBSE Process: issues and Challenges

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related