cbse process issues and challenges l.
Skip this Video
Download Presentation
CBSE Process: issues and Challenges

Loading in 2 Seconds...

play fullscreen
1 / 22

CBSE Process: issues and Challenges - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CBSE Process: issues and Challenges' - janna

Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cbse process issues and challenges

CBSE Process: issues and Challenges

Gerald Kotonya

Computing Department

Lancaster University

United Kingdom

  • Background
  • CBSE Process
  • Elements of CBSE Process
  • Conclusions
  • 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
development process
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
re for development with reuse
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
requirements engineering
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)
requirements engineering contd
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
design for development with reuse
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
design process
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
design process contd
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.
  • 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
  • Component and system testing is a critical aspect of component-based development
    • Black-box nature of components
    • Perception of quality may vary
    • Extraneous features
  • 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
suggested solutions
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+)
testing regimes
Testing regimes
  • To address these problems, component-testing regimes should serve the following aims:
    • Discovery
    • Verification
    • Fitness for purpose
    • Masking
    • Adequacy
trust as mechanism for verification
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
management maintenance and extended development
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
elements of risk
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
addressing the risks
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
  • 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