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

©Ian Sommerville 2007COTS-based System Engineering Slide 2 Objectives l To introduce the notion of COTS reuse and to discuss the different approaches to COTS reuse that may be adopted l To explain the benefits and problems of the different approaches to COTS reuse

©Ian Sommerville 2007COTS-based System Engineering Slide 3 Commercial Off-the-Shelf Systems (COTS) l COTS systems are complete application systems (not components of some larger system) that can be deployed and run as independent systems. l Reuse of COTS systems involves adapting and configuring these systems for a specific operational environment. l Examples Develop Excel spreadsheets to support project costing Configure a patient record system for a specific medical practice

©Ian Sommerville 2007COTS-based System Engineering Slide 4 Requirements issues l The top-down process of identifying requirements then building a system to deliver these requirements does not work l 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 l Stakeholders expectations have to be managed The delivered system may not provide them with what they want

©Ian Sommerville 2007COTS-based System Engineering Slide 5 General benefits l Extensive functionality can be delivered more quickly and more cheaply than for applications that are specially developed for specific requirements l Systems should be more reliable because they are widely used and extensively tested l Businesses can focus on their core activity rather than concerning themselves with IT systems development l Technology updates may be simplified as operating platforms evolve

©Ian Sommerville 2007COTS-based System Engineering Slide 6 General problems l Choosing the right COTS system for a particular organisation can be difficult l There may be a lack of expertise available to support systems development l 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 l Source code is not available so buyers are reliant the system vendor continuing to support the product l Product documentation is often inadequate l Difficult to estimate the costs and risks of system configuration and integration

©Ian Sommerville 2007COTS-based System Engineering Slide 7 Commercial Off-the-Shelf Systems (COTS) l 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. l 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 2007COTS-based System Engineering Slide 8 COTS solution systems l Domain-specific applications Application systems that are designed to support a particular business application For example, an appointment management system for dentists l Generic applications Generic systems that can be used with a range of other applications For example, clients or spreadsheets l Enterprise Resource Planning (ERP) systems Generic business systems built around a shared database

©Ian Sommerville 2007COTS-based System Engineering Slide 9 Domain specific applications l 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 l Usually have a basis in a specific system which has been generalised for wider use l 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 2007COTS-based System Engineering Slide 10 Benefits l Designed for a specific application area so provide extensive, integrated functionality to support that area l A specific user community may be created to share knowledge of problems and how to use the system effectively l Usually designed to support information sharing

©Ian Sommerville 2007COTS-based System Engineering Slide 11 Problems l 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 l The process of use may not match user processes l Systems may only be available on limited platforms l Sometimes expensive l Reliant on continuing support from a single vendor l May be no or limited API for integration with other systems

©Ian Sommerville 2007COTS-based System Engineering Slide 12 Generic applications l Generic applications are general-purpose systems such as Excel or clients. That is, they offer functionality that is likely to be useful in many different areas of work l They may be configured to create personal systems Excel, especially, has very powerful configuration features that allow application-oriented spreadsheets to be created l More commonly, generic applications are incorporated as part of COTS-integrated systems

©Ian Sommerville 2007COTS-based System Engineering Slide 13 Benefits l Usually cheap l Widely used and tested so fairly reliable l May already be licensed for use by the organisation procuring the system l May be supported on different platforms l Users may already be familiar with their user interface (e.g. if Word is used for text input) l Incorporate extensive functionality so may be used in a range of different application types

©Ian Sommerville 2007COTS-based System Engineering Slide 14 Problems l 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 l Undocumented system features may be incompatible with or may conflict with other installed systems l System versions on different platforms may not be completely compatible l Systems are regularly superceded by new versions which may be incompatible l The system vendor may not support older versions of the system

©Ian Sommerville 2007COTS-based System Engineering Slide 15 ERP systems l ERP systems are intended to provide support for all data and processes in an organisation in a single, integrated system l Most large companies have now adopted some form of ERP system l Everything is integrated around a single database l 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 l Primarily used by large companies and organisations l SAP and Oracle are the major vendors of ERP systems

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

©Ian Sommerville 2007COTS-based System Engineering Slide 17 ERP systems development l Modules in an ERP system are large and complex and extensive configuration is needed to describe the processes and rules of a business l 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 2007COTS-based System Engineering Slide 18 Benefits l Integration across business functions. Data from one function is visible to other functions Reduces data duplication l Reduces the number of separate software systems that have to be managed and maintained

©Ian Sommerville 2007COTS-based System Engineering Slide 19 Problems l Very complex to configure ERP systems - thousands of tables and reports may have to be defined l There may be a mismatch between the processes and rules supported by the ERP system and an organisation’s processes l Forces a standard way of working on businesses Can therefore lose competitive edge because of better processes than competitors l Difficult to integrate with legacy systems

©Ian Sommerville 2007COTS-based System Engineering Slide 20 COTS integrated systems 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 l An application is constructed by integrating COTS systems from different vendors l Middleware is used to support communications between these different systems

©Ian Sommerville 2007COTS-based System Engineering Slide 21 Solution vs integrated COTS COTS solution systems COTS integrated systems 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 2007COTS-based System Engineering Slide 22 E-procurement system

©Ian Sommerville 2007COTS-based System Engineering Slide 23 COTS products reused l On the client, standard and web browsing programs are used. l 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 system is also integrated to generate for clients. This also requires an adaptor to receive data from the ordering and invoicing system.

©Ian Sommerville 2007COTS-based System Engineering Slide 24 Benefits l Extends the functionality of existing systems l Faster system development and deployment E.g. the e-procurement system was delivered in 9 months rather than the predicted 3 years l Infrastructure upgrades are provided by the system vendors E.g. systems are updated for new releases of the OS

©Ian Sommerville 2007COTS-based System Engineering Slide 25 Problems l 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 l Performance problems Systems with acceptable performance as stand-alone systems may not be as effective when combined with other systems l Problems of upgrade management Different vendors may have different upgrade cycles l Security issues The security features of the different systems may be incompatible. Integration may only be possible by weakening security

©Ian Sommerville 2007COTS-based System Engineering Slide 26 Key points 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 l COTS solution systems are single domain specific or generic systems that are reused. Development involves configuration l COTS integrated systems involve several different COTS systems. Development involves both integration and configuration