2 ObjectivesTo introduce the notion of COTS reuse and to discuss the different approaches to COTS reuse that may be adoptedTo explain the benefits and problems of the different approaches to COTS reuseTo discuss the issues around the development of software by configuring and adapting COTS systems and components
3 Topics covered COTS solution systems COTS integrated systems Construction by configurationConfiguration issues and problems
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.ExamplesDevelop Excel spreadsheets to support project costingConfigure a patient record system for a specific medical practice
5 Requirements issuesThe top-down process of identifying requirements then building a system to deliver these requirements does not workRather, requirements engineering is an iterative processWhat is wanted by stakeholders?What is available from existing systems?What is available from the system that is chosenStakeholders expectations have to be managedThe delivered system may not provide them with what they want
6 General benefitsExtensive functionality can be delivered more quickly and more cheaply than for applications that are specially developed for specific requirementsSystems should be more reliable because they are widely used and extensively testedBusinesses can focus on their core activity rather than concerning themselves with IT systems developmentTechnology updates may be simplified as operating platforms evolve
7 General problemsChoosing the right COTS system for a particular organisation can be difficultThere may be a lack of expertise available to support systems developmentSystem evolution is controlled by the system vendor rather than the system buyerNew versions may include unwanted functionality; Required functionality may not be includedSource code is not available so buyers are reliant the system vendor continuing to support the productProduct documentation is often inadequateDifficult to estimate the costs and risks of system configuration and integration
8 Commercial Off-the-Shelf Systems (COTS) COTS-solution systemsChoose 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 systemsDevelop 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.
9 COTS solution systems Domain-specific applications Application systems that are designed to support a particular business applicationFor example, an appointment management system for dentistsGeneric applicationsGeneric systems that can be used with a range of other applicationsFor example, clients or spreadsheetsEnterprise Resource Planning (ERP) systemsGeneric business systems built around a shared database
10 Domain specific applications Domain-specific applications are (usually) business systems that have been designed to support a particular business functionDocument managementPayroll and salariesStudent record managementEvent bookingUsually have a basis in a specific system which has been generalised for wider useSystems incorporate assumptions made by the vendor about the domain of applicationE.g. students will only be registered for a degree at one university
11 BenefitsDesigned for a specific application area so provide extensive, integrated functionality to support that areaA specific user community may be created to share knowledge of problems and how to use the system effectivelyUsually designed to support information sharing
12 ProblemsThe assumptions made by the vendor may not hold for the user of the systemWe shall see later a system that had problems because it assumed that it would be used under a particular legal systemThe process of use may not match user processesSystems may only be available on limited platformsSometimes expensiveReliant on continuing support from a single vendorMay be no or limited API for integration with other systems
13 Generic applicationsGeneric 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 workThey may be configured to create personal systemsExcel, especially, has very powerful configuration features that allow application-oriented spreadsheets to be createdMore commonly, generic applications are incorporated as part of COTS-integrated systems
14 Benefits Usually cheap Widely used and tested so fairly reliable May already be licensed for use by the organisation procuring the systemMay be supported on different platformsUsers 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
15 ProblemsAs the systems are designed for stand-alone use, the API may not be well-defined or documentedThis causes difficulties in integration with other systemsUndocumented system features may be incompatible with or may conflict with other COTS systemsSystem versions on different platforms may not be completely compatibleSystems are regularly superceded by new versions which may be incompatibleThe system vendor may not support older versions of the system
16 ERP systemsERP systems are intended to provide support for all data and processes in an organisation in a single, integrated systemMost large companies have now adopted some form of ERP systemEverything is integrated around a single databaseGenerally, 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 rulesPrimarily used by large companies and organisationsSAP and Oracle are the major vendors of ERP systems
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 businessConfiguration involves:Selection of modules - what business activities should be/can be integratedDevelopment of process workflowsSpecification of schemasDefinition of business rulesDefinition of input formsDefinition of output reports
19 Benefits Integration across business functions. Data from one function is visible to other functionsReduces data duplicationReduces the number of separate software systems that have to be managed and maintained
20 ProblemsVery complex to configure ERP systems - thousands of tables and reports may have to be definedThere may be a mismatch between the processes and rules supported by the ERP system and an organisation’s processesForces a standard way of working on businessesCan therefore lose competitive edge because of better processes than competitorsDifficult to integrate with legacy systems
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 systemsAn application is constructed by integrating COTS systems from different vendorsMiddleware is used to support communications between these different systems
22 Solution vs integrated COTS COTS solution systemsCOTS integrated systemsSingle product that provides required functionalityGeneric solution with standard processesFocus is on configurationSystem vendor is maintainerSystem vendor provides infrastructureSeveral heterogeneous products integrated to provide customised functionalityFlexible solutions for specific processesFocus is on integrationSystem owner is maintainerSystem owner provides infrastructure
24 COTS products reusedOn the client, standard 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 system is also integrated to generate for clients. This also requires an adaptor to receive data from the ordering and invoicing system.
25 Benefits Extends the functionality of existing systems Faster system development and deploymentE.g. the e-procurement system was delivered in 9 months rather than the predicted 3 yearsInfrastructure upgrades are provided by the system vendorsE.g. systems are updated for new releases of the OS
26 Problems Architectural mismatch Performance problems 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 problemPerformance problemsSystems with acceptable performance as stand-alone systems may not be as effective when combined with other systemsProblems of upgrade managementDifferent vendors may have different upgrade cyclesSecurity issuesThe security features of the different systems may be incompatible. Integration may only be possible by weakening securityExample of architectural mismatch is who is in control. Each COTS product may assume that it is in control thus making it hard for them to work togetherAlso issues of overlapping infrastructure - each product may supply overlapping functionality of libraries etc. This may lead to very large systems and performance problems.
27 Construction by Configuration: COTS application engineering
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.We are still programming - but using a local programming model rather than a generic model.
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.
30 COTS configurationCOTS solution systems are designed for configurationThe systems have been designed to include generic functionality and abstractions from the domain which are configured for each specific customer through configuration interfacesProgramming is therefore configuration programming rather than programming in a conventional languageConfiguration programming can be a (very) long-term processThe current Spanish en-route air traffic control system is being reconfigured for use in the UK. The process is anticipated to take 6 years.
31 ConfigurationI 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.
32 Configuration activities Selecting required functionalityDefining a data modelDefining business rulesDefining workflowsDefining external interactionsDefining the user interfaceDefining reports producedSetting platform parametersData re-engineeringRe-defining business processesEXPLAIN WHAT THESE MEAN
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.EXPLAIN ABOUT HEALTHCARE TARGETS
34 Procurement issuesA 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.CHANGING THE POLITICAL POWER BASE IN HOSPITALS
35 Software engineeringConfiguring 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.
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 assumptionsThe 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 processLocal process differences meant that different clinics recorded different information about patients.
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 processesThere can be extensive (uncontrolled) “user” configuration of the system.It is often necessary to configure the expectations of system stakeholders.
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 softwareMay 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.
39 Choosing a COTS systemThe 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!The end result is often like the old joke where a man asks for directions to how to get to Dublin..The response is ‘If you’re going to Dublin, then I wouldn’t start from here’.
40 Co-designFor 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.
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.
42 System evolutionHandover 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 configurabilityIncreasing system entropy as local configuration changes are implemented.Evolution of underlying COTS system outside control of system owners.
43 Configuration problems Understanding the configuration possibilitiesKnowing what can be configured is not easy, especially if more than one product is included in the systemUnderstanding how to configure a systemTypically, configuration requires both business knowledge and technical knowledgePredicting the consequences of configuration decisionsIt is often difficult to understand how changing a configuration will affect the use and behaviour of a system while it is in operationUnderstanding how a system is configured
44 Multiple configuration possibilities Ways in which MS Word can be configured (that I’m aware of)Preferences screenCustomisation screenOrganiser screenDefinition of templatesDefinition of stylesDefinition of macrosInclusion of add-ins (e.g. Endnote)
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.
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 difficultE.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.
48 Challenges for C-b-CEstablish methods, tools and techniques for system engineeringDiscover/establish general principles for designing systems for dependable configuration.Define processes and standards for C-b-CDesign new methods and tools to support the processes of C-b-C.Adapt supporting software engineering processes for C-b-C.
49 PrinciplesThe diversity of different approaches to C-b-C mean that identifying unifying principles across different systems is very difficultPossible examples of principlesPrinciple 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?
50 Methods, tools and techniques Visualisation and analysis of configurationsThere is a need for tools that allow engineers to see the ‘configuration state’ of a system and to explore dependencies across that stateConfiguration policy descriptionThere 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.
51 Processes for C-b-C Requirements engineering Design and implementation Separation of the essential and the accidentalEssential elements used to select reusable systemsAccidental requirements subject to negotiationThis will clearly affect procurement processes.Design and implementationHow can configuration ‘designs’ be modelled?System testingTesting against an incomplete spec. is difficultHow can test coverage be assessed?
52 Supporting processesUsers may be partly responsible for parts of the configuration process. This causes major problems with supporting processesConfiguration managementExisting tools are oriented to source codeChange managementCan users be stopped from making ad hoc changes?Quality managementWhat does a ‘high-quality’ configuration mean?
53 ConclusionsConstruction 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.
54 Key pointsReuse of COTS systems requires the business to adapt its requirements and processes to fit the assumptions in the system that is being reusedCOTS solution systems are single domain specific or generic systems that are reused. Development involves configurationCOTS integrated systems involve several different COTS systems. Development involves both integration and configuration
55 Key pointsConstruction by configuration is an approach to software engineering that relies on configuring existing COTS systemsExisting software engineering methods have to be adapted for this approach to developmentKey problems include visualising and analysing configurations, understanding configuration interactions and testing configured systems