©Ian Sommerville 2006MSc module: Advanced Software Engineering Slide 1 COTS Reuse.
-
Upload
liam-stray -
Category
Documents
-
view
215 -
download
0
Transcript of ©Ian Sommerville 2006MSc module: Advanced Software Engineering Slide 1 COTS Reuse.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 2
Objectives
To introduce the notion of COTS reuse and to discuss the different approaches to COTS reuse that may be adopted
To explain the benefits and problems of the different approaches to COTS reuse
To discuss the issues around the development of software by configuring and adapting COTS systems and components
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 3
Topics covered
COTS solution systems COTS integrated systems Construction by configuration Configuration issues and problems
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 4
Commercial Off-the-Shelf Systems (COTS)
COTS systems are complete application systems (not components of some larger system) that can be deployed and run as independent systems.
Reuse of COTS systems involves adapting and configuring these systems for a specific operational environment.
Examples• Develop Excel spreadsheets to support project costing• Configure a patient record system for a specific medical
practice
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 5
Requirements issues
The top-down process of identifying requirements then building a system to deliver these requirements does not work
Rather, requirements engineering is an iterative process• What is wanted by stakeholders?• What is available from existing systems?• What is available from the system that is chosen
Stakeholders expectations have to be managed• The delivered system may not provide them with what
they want
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 6
General benefits
Extensive functionality can be delivered more quickly and more cheaply than for applications that are specially developed for specific requirements
Systems should be more reliable because they are widely used and extensively tested
Businesses can focus on their core activity rather than concerning themselves with IT systems development
Technology updates may be simplified as operating platforms evolve
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 7
General problems
Choosing the right COTS system for a particular organisation can be difficult
There may be a lack of expertise available to support systems development
System evolution is controlled by the system vendor rather than the system buyer• New versions may include unwanted functionality; Required
functionality may not be included Source code is not available so buyers are reliant the
system vendor continuing to support the product Product documentation is often inadequate Difficult to estimate the costs and risks of system
configuration and integration
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 8
Commercial Off-the-Shelf Systems (COTS)
COTS-solution systems • Choose a generic system that has been developed
to deliver some business function and adapt that system to the needs of a particular organisation.
COTS-integrated systems • Develop a new system by choosing a number of
COTS systems and integrating these to deliver combined functionality. Additional software (glueware) is required to make these systems work together.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 9
COTS solution systems
Domain-specific applications• Application systems that are designed to support a
particular business application• For example, an appointment management system for
dentists Generic applications
• Generic systems that can be used with a range of other applications
• For example, email clients or spreadsheets Enterprise Resource Planning (ERP) systems
• Generic business systems built around a shared database
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 10
Domain specific applications
Domain-specific applications are (usually) business systems that have been designed to support a particular business function• Document management• Payroll and salaries• Student record management• Event booking
Usually have a basis in a specific system which has been generalised for wider use
Systems incorporate assumptions made by the vendor about the domain of application• E.g. students will only be registered for a degree at one
university
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 11
Benefits
Designed for a specific application area so provide extensive, integrated functionality to support that area
A specific user community may be created to share knowledge of problems and how to use the system effectively
Usually designed to support information sharing
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 12
Problems
The assumptions made by the vendor may not hold for the user of the system• We shall see later a system that had problems because
it assumed that it would be used under a particular legal system
The process of use may not match user processes Systems may only be available on limited platforms Sometimes expensive Reliant on continuing support from a single vendor May be no or limited API for integration with other
systems
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 13
Generic applications
Generic applications are general-purpose systems such as Excel or e-mail clients. That is, they offer functionality that is likely to be useful in many different areas of work
They may be configured to create personal systems• Excel, especially, has very powerful configuration
features that allow application-oriented spreadsheets to be created
More commonly, generic applications are incorporated as part of COTS-integrated systems
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 14
Benefits
Usually cheap Widely used and tested so fairly reliable May already be licensed for use by the
organisation procuring the system May be supported on different platforms Users may already be familiar with their user
interface (e.g. if Word is used for text input) Incorporate extensive functionality so may be
used in a range of different application types
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 15
Problems
As the systems are designed for stand-alone use, the API may not be well-defined or documented• This causes difficulties in integration with other systems
Undocumented system features may be incompatible with or may conflict with other COTS systems
System versions on different platforms may not be completely compatible
Systems are regularly superceded by new versions which may be incompatible
The system vendor may not support older versions of the system
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 16
ERP systems
ERP systems are intended to provide support for all data and processes in an organisation in a single, integrated system
Most large companies have now adopted some form of ERP system
Everything is integrated around a single database Generally, ERP systems include a number of business-
focused modules (e.g. manufacturing, supply chain, human resources, etc.) that are integrated using a set of process workflows and business rules
Primarily used by large companies and organisations SAP and Oracle are the major vendors of ERP systems
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 17
Systems architecture
System database
Business rules
PurchasingSupply chain
Logistics CRM
Processes Processes Processes Processes
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 18
ERP systems development
Modules in an ERP system are large and complex and extensive configuration is needed to describe the processes and rules of a business
Configuration involves:• Selection of modules - what business activities should
be/can be integrated• Development of process workflows• Specification of schemas• Definition of business rules• Definition of input forms• Definition of output reports
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 19
Benefits
Integration across business functions. • Data from one function is visible to other functions
• Reduces data duplication Reduces the number of separate software
systems that have to be managed and maintained
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 20
Problems
Very complex to configure ERP systems - thousands of tables and reports may have to be defined
There may be a mismatch between the processes and rules supported by the ERP system and an organisation’s processes
Forces a standard way of working on businesses • Can therefore lose competitive edge because of better
processes than competitors Difficult to integrate with legacy systems
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 21
COTS integrated systems
This approach is used when there is no single COTS system that can provide the required functionality or where it is essential for a new system to integrate with existing organisational systems
An application is constructed by integrating COTS systems from different vendors
Middleware is used to support communications between these different systems
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 22
Solution vs integrated COTS
COTS solution systems
COTS integratedsystems
Single product that provides required functionality
Generic solution with standard processes
Focus is on configuration
System vendor is maintainer
System vendor provides infrastructure
Several heterogeneous products integrated to provide customised functionality
Flexible solutions for specific processes
Focus is on integration
System owner is maintainer
System owner provides infrastructure
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 23
E-procurement systemClientWeb browserE-mail systemServerE-commercesystemOrdering andinvoicing systemE-mail systemAdaptorAdaptor
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 24
COTS products reused
On the client, standard e-mail and web browsing programs are used.
On the server, an e-commerce platform has to be integrated with an existing ordering system which was part of an ERP system.• This involves writing an adaptor so that they can
exchange data.• An e-mail system is also integrated to generate e-
mail for clients. This also requires an adaptor to receive data from the ordering and invoicing system.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 25
Benefits
Extends the functionality of existing systems Faster system development and deployment
• E.g. the e-procurement system was delivered in 9 months rather than the predicted 3 years
Infrastructure upgrades are provided by the system vendors • E.g. systems are updated for new releases of the
OS
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 26
Problems Architectural mismatch
• The architectural models of the different products may be incompatible e.g. they may use different event models. Middleware may have to be written to resolve this problem
Performance problems• Systems with acceptable performance as stand-alone
systems may not be as effective when combined with other systems
Problems of upgrade management• Different vendors may have different upgrade cycles
Security issues• The security features of the different systems may be
incompatible. Integration may only be possible by weakening security
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 27
Construction by Configuration: COTS application engineering
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 28
Construction by configuration (C-b-C)
Software development with reuse rarely means reusing domain abstractions without change.
The reusable abstractions have to be configured to adapt them to their local circumstances of use.
This can range from simple parameter setting through the definition of business rules to special purpose component development.
C-b-C also may also include configuring the process as well as configuring the software that is the way people work has to change to meet the demands of the software.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 29
Reuse and configuration
Components and services are intended to be used with limited configuration. Here the adaptation and configuration is often in the ‘glue code’ used to link these entities.
System families are configured by adapting specified parts of the system code.
ERP systems and generic COTS, by contrast, are designed for configuration without access to the source code of the system.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 30
COTS configuration
COTS solution systems are designed for configuration The systems have been designed to include generic
functionality and abstractions from the domain which are configured for each specific customer through configuration interfaces
Programming is therefore configuration programming rather than programming in a conventional language
Configuration programming can be a (very) long-term process• The current Spanish en-route air traffic control system
is being reconfigured for use in the UK. The process is anticipated to take 6 years.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 31
Configuration
I use the term ‘configuration’ to cover both customisation and adapting software to a specific execution environment.
Adapting the system to reflect:• The specific needs of a customer (e.g. a hospital);• The requirements of a user or group of users (e.g.
maternity unit or physiotherapy or both);• Interaction with other systems;• The characteristics of the platform on which the
software executes.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 32
Configuration activities
Selecting required functionality Defining a data model Defining business rules Defining workflows Defining external interactions Defining the user interface Defining reports produced Setting platform parameters Data re-engineering Re-defining business processes
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 33
A patient management system
We have followed the deployment of a patient management system (PIMS) for mental healthcare in Edinburgh, Scotland.
Based around a generic COTS-package developed for hospitals in England.
This was designed to be adapted for supporting different kinds of clinic including mental healthcare.
Scotland has its own legal system and laws and healthcare is a devolved responsibility. The Scottish Executive sets its own targets and priorities for healthcare.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 34
Procurement issues
A major influence in choosing the particular COTS system was that it offered the opportunity for hospital managers (rather than clinical staff) to control how information was recorded.
The Executive placed a tight deadline on hospitals for reporting against a set of targets.
There was little time to carry out a detailed comparison of alternatives and this system had already been successfully deployed elsewhere.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 35
Software engineering
Configuring the data model required for a particular set of clinics.• i.e. setting up information about conditions, treatments,
etc. Configuring the menus for the particular type of clinic
and the patient information that had to be recorded. Configuring the reports to be generated by the system. Configuring the rules that should be applied to the
system data.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 36
Issues and problems
Objectives conflict• Management objective - provide reports against a set of
headings defined by the Executive.• Clinical objectives - record patient information according
to clinical classification. Invalid configuration assumptions
• The language for defining the rules of the system was not expressive enough to cover the requirements of Scots law regarding the forced detention of patients who were a danger to themselves or others.
Failure to configure the process• Local process differences meant that different clinics
recorded different information about patients.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 37
The C-b-C process for COTS
There is often no clear distinction between specification, design and development.
Systems are rarely completely configured before being put into use. The configuration process continues as the system is integrated with operational processes
There can be extensive (uncontrolled) “user” configuration of the system.
It is often necessary to configure the expectations of system stakeholders.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 38
Process differences
Two-stage system requirements process• Identify general requirements to chose a reusable
system;• Identify specific requirements from settings where the
system will be used. Co-design of process and software
• May be more active stakeholder involvement in the development process.
System testing is a problem. Good practices such as configuration management,
reviews, etc. are practically impossible to implement.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 39
Choosing a COTS system
The decision on which COTS system to use is rarely a transparent process, based on a detailed analysis of the requirements in a specific setting.
Issues that affect the decision include:• Political issues;• Platform issues;• Cost and schedule issues;• Availability of expertise;• Prejudice!
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 40
Co-design
For C-b-C, separating requirements and development/deployment is unlikely to be successful.
Requirements compromises are essential because the stakeholder’s real needs need to be matched with what the system actually provides.
Configurability makes co-design, with stakeholder involvement in the design process, much easier.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 41
System testing
Testing is a particular problem for COTS-based systems.
Systems are not designed for running automated test suites.
There is no specification that can serve as a basis for deriving tests.
Problems that arise are often a consequence of interactions between the process of use and the system rather than system failure.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 42
System evolution
Handover process from consultants to local IT staff. Change of system ‘ownership’• Limited expertise with system - may be managers
rather than software engineers. Problems of change management exacerbated
because of the system configurability• Increasing system entropy as local configuration
changes are implemented. Evolution of underlying COTS system outside control
of system owners.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 43
Configuration problems
Understanding the configuration possibilities• Knowing what can be configured is not easy, especially
if more than one product is included in the system Understanding how to configure a system
• Typically, configuration requires both business knowledge and technical knowledge
Predicting the consequences of configuration decisions• It is often difficult to understand how changing a
configuration will affect the use and behaviour of a system while it is in operation
Understanding how a system is configured
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 44
Multiple configuration possibilities
Ways in which MS Word can be configured (that I’m aware of)• Preferences screen• Customisation screen• Organiser screen• Definition of templates• Definition of styles• Definition of macros• Inclusion of add-ins (e.g. Endnote)
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 45
Understanding how to configure
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 46
Configuration predictability
If you change a program, it is generally possible to hypothesise how this will affect the behaviour of the executing system.
When you change a configuration, the relationship is less obvious.
Change becomes a process of ad hoc experimentation. Gurus evolve who can suggest what to do but who can’t explain why it should be done that way.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 47
Understanding the configuration
Once a system has been configured, how can others understand the configuration.
Requirements/design/code traceability is difficult enough in conventional systems but much harder in COTS where:• Requirements are not properly documented as a result of the
co-design process;• Understanding requires knowledge of the COTS system +
knowledge of the configuration. Change costing and impact analysis is difficult
• E.g. in the healthcare system we looked at, it was originally estimated that changing menus would take a few days. It ended up taking several months.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 48
Challenges for C-b-C
Establish methods, tools and techniques for system engineering• Discover/establish general principles for designing
systems for dependable configuration.• Define processes and standards for C-b-C• Design new methods and tools to support the
processes of C-b-C. Adapt supporting software engineering processes for
C-b-C.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 49
Principles
The diversity of different approaches to C-b-C mean that identifying unifying principles across different systems is very difficult
Possible examples of principles• Principle of visibility - make configurations explicit?• Principle of low coupling - reduce dependencies across
configurations?• Principle of scalability - separate configuration of
system deployment from configuration of functionality?• Principle of localisation - localise volatile configuration
entities?
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 50
Methods, tools and techniques
Visualisation and analysis of configurations• There is a need for tools that allow engineers to
see the ‘configuration state’ of a system and to explore dependencies across that state
Configuration policy description• There is a wide gap between organisational policy
(esp. security policy) and the realisation of that policy as a configuration. Methods and tools are needed to bridge this gap and hence reduce configuration errors.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 51
Processes for C-b-C
Requirements engineering• Separation of the essential and the accidental
• Essential elements used to select reusable systems• Accidental requirements subject to negotiation
• This will clearly affect procurement processes. Design and implementation
• How can configuration ‘designs’ be modelled? System testing
• Testing against an incomplete spec. is difficult• How can test coverage be assessed?
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 52
Supporting processes
Users may be partly responsible for parts of the configuration process. This causes major problems with supporting processes • Configuration management
• Existing tools are oriented to source code
• Change management• Can users be stopped from making ad hoc changes?
• Quality management• What does a ‘high-quality’ configuration mean?
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 53
Conclusions
Construction by configuration is a reality for modern business software development.
Political, technical and economic factors mean that this approach will be increasingly used for all types of system.
Our current ‘ad hoc’ approaches are not good enough - we need to adapt software engineering methods and techniques for this approach.
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 54
Key points
Reuse of COTS systems requires the business to adapt its requirements and processes to fit the assumptions in the system that is being reused
COTS solution systems are single domain specific or generic systems that are reused. Development involves configuration
COTS integrated systems involve several different COTS systems. Development involves both integration and configuration
©Ian Sommerville 2006 MSc module: Advanced Software Engineering Slide 55
Key points
Construction by configuration is an approach to software engineering that relies on configuring existing COTS systems
Existing software engineering methods have to be adapted for this approach to development
Key problems include visualising and analysing configurations, understanding configuration interactions and testing configured systems