Ch6 Architectural Design PDF

Chapter 6 – Architectural Design 01/11/2020 Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural patterns 01/11/2020 Chapter 6 Architectural Design 2 Architectural design Architectural design is concerned with understanding...

Chapter 6 – Architectural Design 01/11/2020 Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural patterns 01/11/2020 Chapter 6 Architectural Design 2 Architectural design Architectural design is concerned with understanding how a software system should be organized and designing the overall structure of that system. Architectural design is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them. The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components. 01/11/2020 Chapter 6 Architectural Design 3 01/11/2020 Chapter 6 Architectural Design 4 Architectural abstraction Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies. 01/11/2020 Chapter 6 Architectural Design 5 Advantages of explicit architecture Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. System analysis Means that analysis of whether the system can meet its non- functional requirements is possible. Large-scale reuse The architecture may be reusable across a range of systems Product-line architectures may be developed. 01/11/2020 Chapter 6 Architectural Design 6 Architectural representations Simple, informal block diagrams showing entities and relationships are the most frequently used method for documenting software architectures. But these have been criticized because they lack semantics, do not show the types of relationships between entities nor the visible properties of entities in the architecture. 01/11/2020 Chapter 6 Architectural Design 7 Use of architectural models As a way of facilitating discussion about the system design A high-level architectural view of a system is useful for communication with system stakeholders and project planning because it is not cluttered with detail. Stakeholders can relate to it and understand an abstract view of the system. They can then discuss the system as a whole without being confused by detail. As a way of documenting an architecture that has been designed The aim here is to produce a complete system model that shows the different components in a system, their interfaces and their connections. 01/11/2020 Chapter 6 Architectural Design 8 Architectural design decisions Architectural design is a creative process so the process differs depending on the type of system being developed. However, a number of common decisions span all design processes and these decisions affect the non- functional characteristics of the system. 01/11/2020 Chapter 6 Architectural Design 9 Architectural design decisions 01/11/2020 Chapter 6 Architectural Design 10 Architecture reuse Systems in the same domain often have similar architectures that reflect domain concepts. Application product lines are built around a core architecture with variants that satisfy particular customer requirements. The architecture of a system may be designed around one of more architectural patterns or ‘styles’. These capture the essence of an architecture and can be instantiated in different ways. 01/11/2020 Chapter 6 Architectural Design 11 Architecture and system characteristics Performance Localise critical operations and minimise communications. Use large rather than fine-grain components. Security Use a layered architecture with critical assets in the inner layers. Safety Localise safety-critical features in a small number of sub- systems. Availability Include redundant components and mechanisms for fault tolerance. Maintainability Use fine-grain, replaceable components. 01/11/2020 Chapter 6 Architectural Design 12 Architectural patterns Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. Patterns should include information about when they are used and when the are not useful. Patterns may be represented using tabular and graphical descriptions. 01/11/2020 Chapter 6 Architectural Design 13 Layered architecture Used to model the interfacing of sub-systems. Organises the system into a set of layers (or abstract machines) each of which provide a set of services. Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected. 01/11/2020 Chapter 6 Architectural Design 14 The Layered architecture pattern Name Layered architecture Description Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system. See Figure 6.6. When used Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security. Advantages Allows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system. Disadvantages In practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at 01/11/2020 Chapter 6 Architectural Design 15 each layer. A generic layered architecture 01/11/2020 Chapter 6 Architectural Design 16 Repository architecture Sub-systems must exchange data. This may be done in two ways: Shared data is held in a central database or repository and may be accessed by all sub-systems; Each sub-system maintains its own database and passes data explicitly to other sub-systems. When large amounts of data are to be shared, the repository model of sharing is most commonly used a this is an efficient data sharing mechanism. 01/11/2020 Chapter 6 Architectural Design 17 The Repository pattern Name Repository Description All data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository. When used You should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time. Advantages Components can be independent—they do not need to know of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., backups done at the same time) as it is all in one place. Disadvantages The repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers 01/11/2020 Chapter 6 Architectural Design 18 may be difficult. Client-server architecture Distributed system model which shows how data and processing is distributed across a range of components. Can be implemented on a single computer. Set of stand-alone servers which provide specific services such as printing, data management, etc. Set of clients which call on these services. Network which allows clients to access servers. 01/11/2020 Chapter 6 Architectural Design 19 The Client–server pattern Name Client-server Description In a client–server architecture, the functionality of the system is organized into services, with each service delivered from a separate server. Clients are users of these services and access servers to make use of them. When used Used when data in a shared database has to be accessed from a range of locations. Advantages The principal advantage of this model is that servers can be distributed across a network. General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services. Disadvantages Each service is a single point of failure so susceptible to denial of service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by 01/11/2020 Chapter 6 Architectural Design 20 different organizations. A client–server architecture for a film library 01/11/2020 Chapter 6 Architectural Design 21 Pipe and filter architecture Functional transformations process their inputs to produce outputs. May be referred to as a pipe and filter model. Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems. Not really suitable for interactive systems. 01/11/2020 Chapter 6 Architectural Design 22 The pipe and filter pattern Name Pipe and filter Description The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing. When used Commonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs. Advantages Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system. Disadvantages The format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. 01/11/2020 Chapter 6 Architectural Design 23 This increases system overhead and may mean that it is impossible to reuse functional transformations that use Key points A software architecture is a description of how a software system is organized. Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used. Architectural patterns are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used and describe its advantages and disadvantages. 01/11/2020 Chapter 6 Architectural Design 24 Chapter 7 – Design and Implementation Object-oriented design using the UML Design patterns Implementation issues Open source development 30/10/2014 Chapter 7 Design and Implementation 1 Design and implementation Software design and implementation is the stage in the software engineering process at which an executable software system is developed. Software design and implementation activities are invariably inter-leaved. Software design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements. Implementation is the process of realizing the design as a program. 30/10/2014 Chapter 7 Design and Implementation 2 Build or buy In a wide range of domains, it is now possible to buy off- the-shelf systems (COTS) that can be adapted and tailored to the users’ requirements. For example, if you want to implement a medical records system, you can buy a package that is already used in hospitals. It can be cheaper and faster to use this approach rather than developing a system in a conventional programming language. When you develop an application in this way, the design process becomes concerned with how to use the configuration features of that system to deliver the system requirements. 30/10/2014 Chapter 7 Design and Implementation 3  An object-oriented design process Structured object-oriented design processes involve developing a number of different system models. They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective. However, for large systems developed by different groups design models are an important communication mechanism. 30/10/2014 Chapter 7 Design and Implementation 4 Process stages There are a variety of different object-oriented design processes that depend on the organization using the process. Common activities in these processes include: Define the context and modes of use of the system; Design the system architecture; Identify the principal system objects; Develop design models; Specify object interfaces. 30/10/2014 Chapter 7 Design and Implementation 5 Context and interaction models A system context model is a structural model that demonstrates the other systems in the environment of the system being developed. An interaction model is a dynamic model that shows how the system interacts with its environment as it is used. 30/10/2014 Chapter 7 Design and Implementation 6 Architectural design Once interactions between the system and its environment have been understood, you use this information for designing the system architecture. You identify the major components that make up the system and their interactions, and then may organize the components using an architectural pattern such as a layered or client-server model. 30/10/2014 Chapter 7 Design and Implementation 7 High-level architecture of the weather station 30/10/2014 Chapter 7 Design and Implementation 8 Object class identification Identifying object classes is often a difficult part of object oriented design. There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers. Object identification is an iterative process. You are unlikely to get it right first time. 30/10/2014 Chapter 7 Design and Implementation 9 Design models Design models show the objects and object classes and relationships between these entities. There are two kinds of design model: Structural models describe the static structure of the system in terms of object classes and relationships. Dynamic models describe the dynamic interactions between objects. 30/10/2014 Chapter 7 Design and Implementation 10 Examples of design models Subsystem models that show logical groupings of objects into coherent subsystems (packages). Sequence models that show the sequence of object interactions. State machine models that show how individual objects change their state in response to events. Other models include use-case models, aggregation models, generalisation models, etc. 30/10/2014 Chapter 7 Design and Implementation 11 Design patterns A design pattern is a way of reusing abstract knowledge about a problem and its solution. A pattern is a description of the problem and the essence of its solution. It should be sufficiently abstract to be reused in different settings. Pattern descriptions usually make use of object-oriented characteristics such as inheritance and polymorphism. 30/10/2014 Chapter 7 Design and Implementation 12 Pattern elements Name A meaningful pattern identifier. Problem description. Solution description. Not a concrete design but a template for a design solution that can be instantiated in different ways. Consequences The results and trade-offs of applying the pattern. 30/10/2014 Chapter 7 Design and Implementation 13 Implementation issues Focus here is not on programming, although this is obviously important, but on other implementation issues that are often not covered in programming texts: Reuse Most modern software is constructed by reusing existing components or systems. When you are developing software, you should make as much use as possible of existing code. Configuration management During the development process, you have to keep track of the many different versions of each software component in a configuration management system. Host-target development Production software does not usually execute on the same computer as the software development environment. Rather, you develop it on one computer (the host system) and execute it on a separate computer (the target system). 30/10/2014 Chapter 7 Design and Implementation 14 Open source development Open source development is an approach to software development in which the source code of a software system is published and volunteers are invited to participate in the development process Its roots are in the Free Software Foundation (www.fsf.org), which advocates that source code should not be proprietary but rather should always be available for users to examine and modify as they wish. 30/10/2014 Chapter 7 Design and Implementation 15 Open source systems The best-known open source product is, of course, the Linux operating system which is widely used as a server system and, increasingly, as a desktop environment. Other important open source products are Java, the Apache web server and the mySQL database management system. 30/10/2014 Chapter 7 Design and Implementation 16 Open source business More and more product companies are using an open source approach to development. They believe that involving the open source community will allow software to be developed more cheaply, more quickly and will create a community of users for the software. 30/10/2014 Chapter 7 Design and Implementation 17 Open source licensing A fundamental principle of open-source development is that source code should be freely available, this does not mean that anyone can do as they wish with that code. Legally, the developer of the code (either a company or an individual) still owns the code. They can place restrictions on how it is used by including legally binding conditions in an open source software license. Some open source developers believe that if an open source component is used to develop a new system, then that system should also be open source. Others are willing to allow their code to be used without this restriction. 30/10/2014 Chapter 7 Design and Implementation 18 Key points Software design and implementation are inter-leaved activities. The process of object-oriented design includes activities to design the system architecture, identify objects in the system, describe the design using different object models and document the component interfaces. A range of different models may be produced during an object- oriented design process. When developing software, you should always consider the possibility of reusing existing software, either as components, services or complete systems. Open source development involves making the source code of a system publicly available. 30/10/2014 Chapter 7 Design and Implementation 19  Chapter 8 – Software Testing Development testing User testing 30/10/2014 Chapter 8 Software Testing 1 Program testing Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use. When you test software, you execute a program using artificial data. You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes. Can reveal the presence of errors NOT their absence. Testing is part of a more general verification and validation process, which also includes static validation techniques. 30/10/2014 Chapter 8 Software Testing 2 Program testing goals To demonstrate to the developer and the customer that the software meets its requirements. To discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification. Defect testing is concerned with rooting out undesirable system behavior such as system crashes, unwanted interactions with other systems. 30/10/2014 Chapter 8 Software Testing 3 Testing process goals Validation testing To demonstrate to the developer and the system customer that the software meets its requirements A successful test shows that the system operates as intended. Defect testing To discover faults or defects in the software where its behavior is incorrect or not in conformance with its specification A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system. 30/10/2014 Chapter 8 Software Testing 4 An input-output model of program testing 30/10/2014 Chapter 8 Software Testing 5 Verification vs validation Verification: "Are we building the product right”. The software should conform to its specification. Validation: "Are we building the right product”. The software should do what the user really requires. 30/10/2014 Chapter 8 Software Testing 6 Inspections and testing Software inspections Concerned with analysis of the static system representation to discover problems (static verification) Software testing Concerned with exercising and observing product behaviour (dynamic verification) The system is executed with test data and its operational behaviour is observed. 30/10/2014 Chapter 8 Software Testing 7 Inspections and testing 30/10/2014 Chapter 8 Software Testing 8 Software inspections These involve people examining the source representation with the aim of discovering anomalies and defects. Inspections not require execution of a system so may be used before implementation. They may be applied to any representation of the system (requirements, design,configuration data, test data, etc.). 30/10/2014 Chapter 8 Software Testing 9 Advantages of inspections During testing, errors can mask (hide) other errors. Because inspection is a static process, you don’t have to be concerned with interactions between errors. Incomplete versions of a system can be inspected without additional costs. As well as searching for program defects, an inspection can also consider broader quality attributes of a program, such as compliance with standards, portability and maintainability. 30/10/2014 Chapter 8 Software Testing 10 Inspections and testing Inspections and testing are complementary and not opposing verification techniques. Both should be used during the V & V process. Inspections can check conformance with a specification but not conformance with the customer’s real requirements. Inspections cannot check non-functional characteristics such as performance, usability, etc. 30/10/2014 Chapter 8 Software Testing 11 A model of the software testing process 30/10/2014 Chapter 8 Software Testing 12 Stages of testing Development testing, where the system is tested during development to discover bugs and defects. Release testing, where a separate testing team test a complete version of the system before it is released to users. User testing, where users or potential users of a system test the system in their own environment. 30/10/2014 Chapter 8 Software Testing 13 Development testing Development testing includes all testing activities that are carried out by the team developing the system. Unit testing, where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods. Component testing, where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces. System testing, where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions. 30/10/2014 Chapter 8 Software Testing 14 General testing guidelines Choose inputs that force the system to generate all error messages Design inputs that cause input buffers to overflow Repeat the same input or series of inputs numerous times Force invalid outputs to be generated Force computation results to be too large or too small. 30/10/2014 Chapter 8 Software Testing 15 User testing User or customer testing is a stage in the testing process in which users or customers provide input and advice on system testing. 30/10/2014 Chapter 8 Software Testing 16 Types of user testing Alpha testing Users of the software work with the development team to test the software at the developer’s site. Beta testing A release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers. Acceptance testing Customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment. Primarily for custom systems. 30/10/2014 Chapter 8 Software Testing 17 The acceptance testing process 30/10/2014 Chapter 8 Software Testing 18 Key points Testing can only show the presence of errors in a program. It cannot demonstrate that there are no remaining faults. Development testing is the responsibility of the software development team. A separate team should be responsible for testing a system before it is released to customers. User testing 30/10/2014 Chapter 8 Software Testing 19  Chapter 9 – Software Evolution Software maintenance 30/10/2014 Chapter 9 Software Evolution 1 Software maintenance Modifying a program after it has been put into use. The term is mostly used for changing custom software. Generic software products are said to evolve to create new versions. Maintenance does not normally involve major changes to the system’s architecture. Changes are implemented by modifying existing components and adding new components to the system. 30/10/2014 Chapter 9 Software Evolution 2 Types of maintenance Fault repairs Changing a system to fix bugs/vulnerabilities and correct deficiencies in the way meets its requirements. Environmental adaptation Maintenance to adapt software to a different operating environment Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation. Functionality addition and modification Modifying the system to satisfy new requirements. 30/10/2014 Chapter 9 Software Evolution 3 Maintenance effort distribution 30/10/2014 Chapter 9 Software Evolution 4 Maintenance costs Usually greater than development costs (2* to 100* depending on the application). Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.). 30/10/2014 Chapter 9 Software Evolution 5 Maintenance costs It is usually more expensive to add new features to a system during maintenance than it is to add the same features during development A new team has to understand the programs being maintained Separating maintenance and development means there is no incentive for the development team to write maintainable software Program maintenance work is unpopular Maintenance staff are often inexperienced and have limited domain knowledge. As programs age, their structure degrades and they become harder to change 30/10/2014 Chapter 9 Software Evolution 6 Maintenance prediction Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs 30/10/2014 Chapter 9 Software Evolution 7 Maintenance prediction 30/10/2014 Chapter 9 Software Evolution 8 Complexity metrics Predictions of maintainability can be made by assessing the complexity of system components. Studies have shown that most maintenance effort is spent on a relatively small number of system components. Complexity depends on Complexity of control structures; Complexity of data structures; Object, method (procedure) and module size. 30/10/2014 Chapter 9 Software Evolution 9 Process metrics Process metrics may be used to assess maintainability Number of requests for corrective maintenance; Average time required for impact analysis; Average time taken to implement a change request; Number of outstanding change requests. If any or all of these is increasing, this may indicate a decline in maintainability. 30/10/2014 Chapter 9 Software Evolution 10 Software reengineering Restructuring or rewriting part or all of a legacy system without changing its functionality. Applicable where some but not all sub-systems of a larger system require frequent maintenance. Reengineering involves adding effort to make them easier to maintain. The system may be re- structured and re-documented. 30/10/2014 Chapter 9 Software Evolution 11 Advantages of reengineering Reduced risk There is a high risk in new software development. There may be development problems, staffing problems and specification problems. Reduced cost The cost of re-engineering is often significantly less than the costs of developing new software. 30/10/2014 Chapter 9 Software Evolution 12 Reengineering cost factors The quality of the software to be reengineered. The tool support available for reengineering. The extent of the data conversion which is required. The availability of expert staff for reengineering. 30/10/2014 Chapter 9 Software Evolution 13 Key points There are 3 types of software maintenance, namely bug fixing, modifying software to work in a new environment, and implementing new or changed requirements. Software re-engineering is concerned with re-structuring and re-documenting software to make it easier to understand and change. 30/10/2014 Chapter 9 Software Evolution 14  Chapter 9 – Software Evolution Evolution processes Legacy systems 30/10/2014 Chapter 9 Software Evolution 1 Software change Software change is inevitable New requirements emerge when the software is used; The business environment changes; Errors must be repaired; New computers and equipment is added to the system; The performance or reliability of the system may have to be improved. A key problem for all organizations is implementing and managing change to their existing software systems. 30/10/2014 Chapter 9 Software Evolution 2 Importance of evolution Organizations have huge investments in their software systems - they are critical business assets. To maintain the value of these assets to the business, they must be changed and updated. The majority of the software budget in large companies is devoted to changing and evolving existing software rather than developing new software. 30/10/2014 Chapter 9 Software Evolution 3 A spiral model of development and evolution 30/10/2014 Chapter 9 Software Evolution 4 Evolution and servicing 30/10/2014 Chapter 9 Software Evolution 5 Evolution and servicing Evolution The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system. Servicing At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added. Phase-out The software may still be used but no further changes are made to it. 30/10/2014 Chapter 9 Software Evolution 6 Evolution processes Software evolution processes depend on The type of software being maintained; The development processes used; The skills and experience of the people involved. Proposals for change are the driver for system evolution. Change identification and evolution continues throughout the system lifetime. 30/10/2014 Chapter 9 Software Evolution 7 Change identification and evolution processes 30/10/2014 Chapter 9 Software Evolution 8 The software evolution process 30/10/2014 Chapter 9 Software Evolution 9 Urgent change requests Urgent changes may have to be implemented without going through all stages of the software engineering process If a serious system fault has to be repaired to allow normal operation to continue; If changes to the system’s environment (e.g. an OS upgrade) have unexpected effects; If there are business changes that require a very rapid response (e.g. the release of a competing product). 30/10/2014 Chapter 9 Software Evolution 10 The emergency repair process 30/10/2014 Chapter 9 Software Evolution 11 Legacy systems Legacy systems are older systems that rely on languages and technology that are no longer used for new systems development. Legacy software may be dependent on older hardware, such as mainframe computers and may have associated legacy processes and procedures. 30/10/2014 Chapter 9 Software Evolution 12 The elements of a legacy system 30/10/2014 Chapter 9 Software Evolution 13 Legacy system components System hardware Legacy systems may have been written for hardware that is no longer available. Support software The legacy system may rely on a range of support software, which may be obsolete or unsupported. Application software The application system that provides the business services is usually made up of a number of application programs. Application data These are data that are processed by the application system. They may be inconsistent, duplicated or held in different databases. 30/10/2014 Chapter 9 Software Evolution 14 Legacy system components Business processes These are processes that are used in the business to achieve some business objective. Business policies and rules These are definitions of how the business should be carried out and constraints on the business. Use of the legacy application system may be embedded in these policies and rules. 30/10/2014 Chapter 9 Software Evolution 15 Legacy system replacement Legacy system replacement is risky and expensive so businesses continue to use these systems System replacement is risky for a number of reasons Lack of complete system specification Tight integration of system and business processes Undocumented business rules embedded in the legacy system New software development may be late and/or over budget 30/10/2014 Chapter 9 Software Evolution 16 Legacy system change Legacy systems are expensive to change for a number of reasons: No consistent programming style Use of obsolete programming languages with few people available with these language skills Inadequate system documentation Data errors, duplication and inconsistency 30/10/2014 Chapter 9 Software Evolution 17 Business value assessment Assessment should take different viewpoints into account System end-users; Business customers; Line managers; IT managers; Senior managers. Interview different stakeholders and collate results. 30/10/2014 Chapter 9 Software Evolution 18 System measurement You may collect quantitative data to make an assessment of the quality of the application system The number of system change requests; The higher this accumulated value, the lower the quality of the system. The number of different user interfaces used by the system; The more interfaces, the more likely it is that there will be inconsistencies and redundancies in these interfaces. The volume of data used by the system. As the volume of data (number of files, size of database, etc.) processed by the system increases, so too do the inconsistencies and errors in that data. Cleaning up old data is a very expensive and time-consuming process 30/10/2014 Chapter 9 Software Evolution 19 Key points Software development and evolution can be thought of as an integrated, iterative process that can be represented using a spiral model. For custom systems, the costs of software maintenance usually exceed the software development costs. The process of software evolution is driven by requests for changes and includes change impact analysis, release planning and change implementation. Legacy systems are older software systems, developed using obsolete software and hardware technologies, that remain useful for a business. 30/10/2014 Chapter 9 Software Evolution 20