Presentation on theme: "Construction by Configuration: An opportunity for SE research"— Presentation transcript:
1 Construction by Configuration: An opportunity for SE research Prof. Ian Sommerville St Andrews University Scotland
2 St Andrews Small Scottish town, on the north-east coast of the UK Home of golfScotland’s oldest university (founded in 1413)Small university focusing on research and teaching excellence
3 Software engineering 2008Over the past 10 years or so, there has been a radical shift in development strategy for large-scale organisational information systemsInstead of developing software by programming in a conventional language, the primary development mode is now based around the reuse of off-the-shelf systems such as ERP systems or generic systems (COTS) for a specific application areaExisting approaches to software engineering have to evolve to take into account this approach to systems engineeringWhy has this happened? Lower perceived risk by senior management (not necessarily true). Commodification of IT - not seen as a means of gaining competitive advantage; Difficulties in finding and retaining staff; Faster time to deployment. Hard sell by vendors.
4 Commercial Off-the-Shelf Systems (COTS) COTS-based reuse relies on adopting a generic system that has been developed to deliver some business function and adapting that systems to the needs of a particular organisationIncreasingly, new systems are developed by integrating several existing COTS, sometimes with different owners. Systems are becoming systems of systemsMuse about researchers keeping in touch with practice. Problems if research only becomes relevant to niche areas of practice.
5 COTS-based reuseCOTS-based reuse is based around systems for a specific application domain (e.g. patient information system in healthcare).This incorporates generic functionality and abstractions from the domain which are configured for each specific customer. COTS are designed for configuration.This 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.Observation: This has already become the dominant mode of software development for business systems.
6 Construction by configuration (C-b-C) COTS and ERP systems include a set of reusable abstractions that represent an application domainThe reusable abstractions have to be configured to adapt them to their local circumstances of useThis can range from simple parameter setting through the definition of business rulesSometimes, configuration may require new, 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 model assumed by the COTS systemWe are still programming - but using a system-specific programming model rather than a generic model.
7 ConfigurationI use the term ‘configuration’ to cover both customisation and adapting software to a specific execution environmentAdapting 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.
8 Configuration activities Selecting required system modulesDefining a data modelDefining business rulesDefining workflowsDefining external interactionsDefining the user interfaceDefining reports producedSetting platform parametersData re-engineeringRe-defining business processesNot conventional programming - how much is normally understood by SE researchers.
9 A patient management system We have followed the deployment of a patient management system (PIMS) for mental healthcare in Edinburgh, ScotlandBased around a generic COTS-package developed for hospitals in EnglandThis was designed to be adapted for supporting different kinds of clinic including mental healthcareScotland has its own legal system and laws and healthcare is a devolved responsibility. The Scottish government sets its own targets and priorities for healthcare
10 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 recordedThe government placed a tight deadline on hospitals for reporting against a set of targetsThere was little time to carry out a detailed comparison of alternatives and this system had already been successfully deployed elsewhere
11 Software engineeringConfiguring the data model required for a particular set of clinicsConfiguring the menus for the particular type of clinic and the patient information that had to be recordedConfiguring the reports to be generated by the systemConfiguring the rules that should be applied to the system data
12 Issues and problems Objectives conflict Management objective - provide reports against a set of headings defined by the ExecutiveClinical objectives - record patient information according to clinical classificationInvalid 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 othersFailure to configure the processLocal process differences meant that different clinics recorded different information about patientsMake point here about the system not having a workflow based model so didn’t force a single process. But, it did not allow multiple data models to reflect the different processes
13 The C-b-C process for COTS There is often no clear distinction between specification, design and developmentSystems 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 systemThe expectations of system stakeholders have to be configured to reflect the realities of he system
14 Process characteristics Two-stage system requirements processIdentify general business requirements to chose a reusable system;Identify specific requirements from the settings where the system will be used.Business process redesignThe business processes have to be redesigned to r4flect the constraints of the selected systemCo-design of process and softwareMay be more active stakeholder involvement in the development process.Limited testing - often post-deployment’ testing to iron out problemsGood practices such as configuration management, reviews, etc. are very difficult to implementTesting - no specification to test against. System doesn’t break but is just unsuitable.
15 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 settingIssues 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’.
16 Co-designFor C-by-C, separating requirements and development/deployment is unlikely to be successfulRequirements compromises are essential because the stakeholder’s real needs need to be matched with what the system actually providesConfigurability makes co-design, with stakeholder involvement in the design process, much easierHowever, users may misunderstand the (lack of) system flexibility
17 System testing Testing is a particular problem for COTS-based systems Systems are not designed for running automated test suitesThere is no specification that can serve as a basis for deriving testsFailures are often not observable by testers as they are failures in process support that can only be recognised by usersProblems that arise are often a consequence of interactions between the process of use and the system rather than system failure.
18 System evolutionHandover process from consultants to local IT staff. Change of system ‘ownership’Limited expertise with system - may be managers rather than software engineersProblems of change management exacerbated because of the system configurabilityIncreasing system entropy as local configuration changes are implementedEvolution of underlying COTS system outside control of system owners
19 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
20 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)
22 Configuration predictability If you change a program, it is generally possible to hypothesise how this will affect the behaviour of the executing systemWhen you change a configuration, the relationship is less obviousChange 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
23 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.
24 Research challenges Design for configuration Configuration engineering Design principles for configurabilityConfiguration visibilityConfiguration descriptionConfiguration engineeringKnowledge management for system engineering:System modellingMethods and tools for COTS-based system testingAdapt supporting software engineering processes for C-by-C
25 Principles for configurable design We need a coherent set of tested principles in this area to guide design and implementationPossible 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?The diversity of different approaches to C-b-C mean that identifying unifying principles across different systems is very difficult
26 Configuration visualisation In most current systems, configurations are opaque - it is difficult or impossible to view the configuration as a whole, at different levels of abstraction or to navigate through the configuration spaceThere is a need for tools that allow engineers to see the ‘configuration state’ of a system and to explore dependencies across that stateWhat configuration information is most useful to system developers?What is the best way to present configuration views to system developers?
27 Configuration description Configuration policiesThere is sometimes a wide gap between organisational policy (especially, security policy) and the realisation of that policy as a configurationConfiguration compilationMethods and tools are needed to allow higher level configuration specification and the automatic generation of a configuration from that specification
28 Knowledge managementConfiguration engineering requires a close collaboration between different classes of system user, business analysts and system developersOur experience has been that major problems arise because of failure to communicate across and within the different groups in an organisationBetter knowledge management support is required to capture, classify and share knowledge about assumptions, problems, the organisation and the system itself
29 Configuration modelling Modelling notations such as the UML are focused on developing object-oriented models of the systemWhile some UML models (such as Use-Case models) can be used for configuration engineering, the majority of the UML models are either inappropriate or cannot be applied in a natural way when configuring a generic systemWhat domain-oriented modelling techniques are most useful, how can they be used and adapted to support understanding and analysis of systems being built using CbyC?
30 System testing Workflow testing Test management Test-first development How can workflow models built into the system be tested against the reality of work?Test managementHow can test coverage be assessed and improved?How can regression testing be supported?Test-first developmentIs this a valid approach for systems developed using CbC?
31 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? How do users find out about changes?Quality managementWhat does a ‘high-quality’ configuration mean?
32 ConclusionsConstruction by configuration is a reality for modern business software developmentPolitical, technical and business factors mean that this approach will be increasingly used for all types of systemOur current ‘ad hoc’ approaches are not good enough - we need to adapt software engineering methods and techniques for this approach.