COTSbased System Engineering Ian Sommerville 2007 COTSbased System

COTS-based System Engineering ©Ian Sommerville 2007 COTS-based System Engineering Slide 1

Objectives l l 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 ©Ian Sommerville 2007 COTS-based System Engineering Slide 2

Commercial Off-the-Shelf Systems (COTS) l l l 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 2007 COTS-based System Engineering Slide 3

Requirements issues l l 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 • • • l 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 2007 COTS-based System Engineering Slide 4

General benefits l l 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 2007 COTS-based System Engineering Slide 5

General problems l l l 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 • l l l 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 2007 COTS-based System Engineering Slide 6

Commercial Off-the-Shelf Systems (COTS) l COTS-solution systems • l 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 2007 COTS-based System Engineering Slide 7

COTS solution systems l Domain-specific applications • • l Generic applications • • l Application systems that are designed to support a particular business application For example, an appointment management system for dentists 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 2007 COTS-based System Engineering Slide 8

Domain specific applications l Domain-specific applications are (usually) business systems that have been designed to support a particular business function • • l l 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 2007 COTS-based System Engineering Slide 9

Benefits l l l 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 2007 COTS-based System Engineering Slide 10

Problems l The assumptions made by the vendor may not hold for the user of the system • l l l 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 2007 COTS-based System Engineering Slide 11

Generic applications l l 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 • l 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 2007 COTS-based System Engineering Slide 12

Benefits l l l 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 2007 COTS-based System Engineering Slide 13

Problems l As the systems are designed for stand-alone use, the API may not be well-defined or documented • l l This causes difficulties in integration with other systems Undocumented system features may be incompatible with or may conflict with other installed 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 2007 COTS-based System Engineering Slide 14

ERP systems l l l 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 2007 COTS-based System Engineering Slide 15

Systems architecture Purchasing Processes Supply chain Processes Logistics Processes CRM Processes Business rules System database ©Ian Sommerville 2007 COTS-based System Engineering Slide 16

ERP systems development l l 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 2007 COTS-based System Engineering Slide 17

Benefits l Integration across business functions. • • l 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 2007 COTS-based System Engineering Slide 18

Problems l l l 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 • l Can therefore lose competitive edge because of better processes than competitors Difficult to integrate with legacy systems ©Ian Sommerville 2007 COTS-based System Engineering Slide 19

COTS integrated systems l l l 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 2007 COTS-based System Engineering Slide 20

Solution vs integrated COTS solution systems COTS integrated systems Single product that provides required functionality Several heterogeneous products integrated to provide customised functionality Generic solution with standard processes Flexible solutions for specific processes Focus is on configuration Focus is on integration System vendor is maintainer System owner is maintainer System vendor provides infrastructure ©Ian Sommerville 2007 System owner provides infrastructure COTS-based System Engineering Slide 21

E-procurement system ©Ian Sommerville 2007 COTS-based System Engineering Slide 22

COTS products reused l l 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 2007 COTS-based System Engineering Slide 23

Benefits l l Extends the functionality of existing systems Faster system development and deployment • l 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 2007 COTS-based System Engineering Slide 24

Problems l Architectural mismatch • l Performance problems • l Systems with acceptable performance as stand-alone systems may not be as effective when combined with other systems Problems of upgrade management • l 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 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 2007 COTS-based System Engineering Slide 25

Key points l l l 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 2007 COTS-based System Engineering Slide 26