09

  • Activity 9.2: Background Reading

    Please read chapter 8 and 9 and do the associated activities.
    8.1 Development Testing
    8.2 Test-Driven Development
    8.3 Release Testing
    8.4 User Testing
    9.1 Evolution Process
    9.2 Legacy system

  • Part 1: Software Testing

    Topics covered:
    Test-driven development
    Release testing
    User testing

  • Test-driven development

  • Benefits of TDD

    Code coverage
    Every code segment that you write has at least one associated test so all code written has at least one test.
    Regression testing
    Regression testing is testing the system to check that changes have not ‘broken’ previously working code.

    A regression test suite is developed incrementally as a program is developed.

    In a manual testing process, regression testing is expensive but, with automated testing, it is simple and straightforward.

    All tests are rerun every time a change is made to the program.

    Tests must run ‘successfully’ before the change is committed.
    Simplified debugging
    When a test fails, it should be obvious where the problem lies. The newly written code needs to be checked and modified.
    System documentation
    The tests themselves are a form of documentation that describe what the code should be doing.

    Test-Driven Development (TDD)

    Test-Driven Development (TDD) is an approach to program development in which you inter-leave testing and code development.

    Tests are written before code and ‘passing’ the tests is the critical driver of development.

    TDD was introduced as part of agile methods such as Extreme Programming. However, it can also be used in plan-driven development processes.

    📷 Test-driven development diagram

    TDD process activities

    Start by identifying the increment of functionality that is required.

    This should normally be small and implementable in a few lines of code.

    Write a test for this functionality and implement this as an automated test.

    Run the test, along with all other tests that have been implemented. Initially, you have not implemented the functionality so the new test will fail.

    You develop code incrementally, along with a test for that increment.

    You don’t move on to the next increment until the code that you have developed passes its test.

    Implement the functionality and re-run the test.

    Once all tests run successfully, you move on to implementing the next chunk of functionality.
    X
    Test-driven development diagram

  • Release testing

  • Release testing

    Release testing is the process of testing a particular release of a system that is intended for use outside of the development team.
    Release testing is usually a black-box testing process where tests are only derived from the system specification.
    Release testing is a form of system testing.

    The main goal of the release testing process

    It is to convince the supplier of the system that it is good enough for use.
    It has to show that the system delivers its specified functionality, performance and dependability, and that it does not fail during normal use.

    Release testing v.s. system testing

    The important differences between them are:
    A separate team that has not been involved in the system development, should be responsible for release testing.
    System testing by the development team should focus on discovering bugs in the system (defect testing).
    The objective of release testing is to check that the system meets its requirements and is good enough for external use (validation testing).

    Requirements based testing

    Requirements-based testing involves examining each requirement and developing a test or set of tests for it.

  • Case study:

    Mentcare system requirements

    Requirement 1: Add a warning message if a patient is allergic to any particular medication
    If a patient is known to be allergic to any particular medication, then prescription of that medication shall result in a warning message being issued to the system user.
    If a prescriber chooses to ignore an allergy warning, they shall provide a reason why this has been ignored.

    Requirements tests

    1. Set up a patient record with no known allergies. Prescribe medication for allergies that are known to exist. Check that a warning message is not issued by the system.
    2. Set up a patient record with a known allergy. Prescribe the medication to that the patient is allergic to, and check that the warning is issued by the system.
    3. Set up a patient record in which allergies to two or more drugs are recorded. Prescribe both of these drugs separately and check that the correct warning for each drug is issued.
    4. Prescribe two drugs that the patient is allergic to. Check that two warnings are correctly issued.
    5. Prescribe a drug that issues a warning and overrule that warning. Check that the system requires the user to provide information explaining why the warning was overruled.

    Features tested by scenario

    Example of a usage scenario for the Mentcare system

    A usage scenario for the Mentcare system

    George is a nurse who specializes in mental healthcare. One of his responsibilities is to visit patients at home to check that their treatment is effective and that they are not suffering from medication side effects.

    On a day for home visits, George logs into the Mentcare system and uses it to print his schedule of home visits for that day, along with summary information about the patients to be visited. He requests that the records for these patients be downloaded to his laptop. He is prompted for his key phrase to encrypt the records on the laptop.

    One of the patients that he visits is Jim, who is being treated with medication for depression. Jim feels that the medication is helping him but believes that it has the side effect of keeping him awake at night. George looks up Jim’s record and is prompted for his key phrase to decrypt the record. He checks the drug prescribed and queries its side effects. Sleeplessness is a known side effect so he notes the problem in Jim’s record and suggests that he visits the clinic to have his medication changed. Jim agrees so George enters a prompt to call him when he gets back to the clinic to make an appointment with a physician. George ends the consultation and the system re-encrypts Jim’s record.

    After, finishing his consultations, George returns to the clinic and uploads the records of patients visited to the database. The system generates a call list for George of those patients who He has to contact for follow-up information and make clinic appointments.

    Features tested by scenario

    1. Authentication by logging on to the system.
    2. Downloading and uploading of specified patient records to a laptop.
    3. Check Home visit scheduling.
    4. Encryption and decryption of patient records on a mobile device.
    5. Record retrieval and modification patient information.
    6. Links with the drugs database in order to check that maintains side-effect information.
    7. The system for call prompting.

    Non-functional requirement testing: Performance testing

    Part of release testing may involve testing the emergent properties of a system, e.g. performance testing.
    Tests should reflect the profile of use of the system.
    Performance tests usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable.
    Stress testing is a form of performance testing where the system is deliberately overloaded to test its failure behaviour.

  • User testing

  • 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.
    User testing is essential, even when comprehensive system and release testing have been carried out.
    The reason for this is that influences from the user’s working environment have a major effect on the reliability, performance, usability and robustness of a system. These cannot be replicated in a testing environment.

    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.

    The acceptance testing process

    Acceptance testing process diagram

    1. Define acceptance criteria
    2. Plan acceptance testing
    3. Derive acceptance tests
    4. Run acceptance tests
    5. Negotiate test results
    6. Reject/accept system

    Agile methods and acceptance testing

    In agile methods, the user/customer is part of the development team and is responsible for making decisions on the acceptability of the system.
    Tests are defined by the user/customer and are integrated with other tests in that they are run automatically when changes are made.
    There is no separate acceptance testing process.
    Main problem here is whether or not the embedded user is ‘typical’ and can represent the interests of all system stakeholders. (It is one of key risk factors: too many stakeholders; how to manage them?)

  • Key Points

    Test-first development is an approach to development where tests are written before the code to be tested.

    Scenario testing involves inventing a typical usage scenario and using this to derive test cases.

    Acceptance testing is a user testing process where the aim is to decide if the software is good enough to be deployed and used in its operational environment.

  • Part 2: Software Evolution

    Useful video: 📹 Software Evolution

    Topics covered:
    Evolution processes
    Legacy systems

    X

  • Software change

    Software change is inevitable, the reasons are as follow:
    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.

    Importance of Evolution

    Organisations 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.

    📷 A spiral model of development and evolution

    Evolution and servicing

    Evolution and Servicing Diagram

    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.
    X
    Spiral Model of Development and evolution diagram

  • Evolution Process

  • 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.
    Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated.
    Change identification and evolution continues throughout the system lifetime.

    📷 The software evolution process
    📷 Change identification and evolution processes

    Change implementation

    Iteration of the development process where the revisions to the system are designed, implemented and tested.
    A critical difference is that the first stage of change implementation may involve program understanding, especially if the original system developers are not responsible for the change implementation.
    During the program understanding phase, you have to understand how the program is structured, how it delivers functionality and how the proposed change might affect the program.

    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).

    Emergency repair process diagram
    X
    Software evolution process diagram
    X
    Change identification and evolution diagram

  • Agile methods and evolution

    Agile methods are based on incremental development so the transition from development to evolution is a seamless one.
    Evolution is simply a continuation of the development process based on frequent system releases.
    Automated regression testing is particularly valuable when changes are made to a system.
    Regression testing is testing the system to check that changes have not ‘broken’ previously working code.
    A regression test suite is developed incrementally as a program is developed.
    Changes may be expressed as additional user stories.

    Handover problems

    Where the development team have used an agile approach but the evolution team is unfamiliar with agile methods and prefer a plan-based approach.
    The evolution team may expect detailed documentation to support evolution and this is not produced in agile processes.
    Where a plan-based approach has been used for development but the evolution team prefer to use agile methods.
    The evolution team may have to start from scratch developing automated tests and the code in the system may not have been refactored and simplified as is expected in agile development.

  • Legacy systems

    Useful Video: 📹 Legacy system
    Useful Video: 📹 Agile Legacy Reengineering
    X
    X

  • Legacy system components

    1. System hardware Legacy systems may have been written for hardware that is no longer available.
    2. Support software The legacy system may rely on a range of support software, which may be obsolete or unsupported.
    3. Application software The application system that provides the business services is usually made up of a number of application programs.
    4. Application data These are data that are processed by the application system. They may be inconsistent, duplicated or held in different databases.
    5. Business processes These are processes that are used in the business to achieve some business objective.
    Business processes may be designed around a legacy system and constrained by the functionality that it provides.
    For instance: in an insurance company’s business process would be issuing an insurance policy; in a manufacturing company, a business process would be accepting an order for products and setting up the associated manufacturing process.
    6. 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.

    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.

    Legacy systems are not just software systems but are broader socio-technical systems that include hardware, software, libraries and other supporting software and business processes.

    P.S. socio-technical system is a system includes hardware & software components, that has defined operational processes followed by human operators and which operates within an organisation. It is therefore influenced by organisational policies, procedures and structures.

    Legacy system layers

    Socio-technical system

    Business processes
    Application software
    Platform and infrastructure software
    Hardware

    Each layer depends on the layer immediately below it and interfaces with that layer.

    Hardware: Legacy systems may have been written for hardware that is no longer available, that is expensive to maintain and that may not be compatible with current organizational IT purchasing policies.

    📷 The elements of a legacy system
    X
    Elements of Legacy System Diagram

  • Legacy system categories

    A: Low quality, low business value
    These systems should be scrapped.
    B: Low-quality, high-business value
    These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available.
    C: High-quality, low-business value
    Replace with COTS, scrap completely or maintain.
    D: High-quality, high business value
    Continue in operation using normal system maintenance.

    COTS system: A Commercial Off-the-Shelf system. an adjective that describes software or hardware products that are ready-made and available for sale to the general public. For example, Microsoft Office is a COTS product that is a packaged software solution for businesses. COTS products are designed to be implemented easily into existing systems without the need for customization See configurable application system.

    Configurable application system: An application system product, developed by a system vendor, that offers functionality that may be configured for use in different companies and environments.

    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

    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
    System structure degradation
    Program optimizations may make them hard to understand
    Data errors, duplication and inconsistency

    Legacy system management

    Organisations that rely on legacy systems must choose a strategy for evolving these systems
    Scrap the system completely and modify business processes so that it is no longer required;
    Continue maintaining the system;
    Transform the system by re-engineering to improve its maintainability;
    Replace the system with a new system.
    The strategy chosen should depend on the system quality and its business value.

    📷 An example of a legacy system assessment
    X
    Legacy System Assessment Diagram

  • Business process assessment

    Use a viewpoint-oriented approach and seek answers from system stakeholders
    Is there a defined process model and is it followed?
    Do different parts of the organisation use different processes for the same function?
    How has the process been adapted?
    What are the relationships with other business processes and are these necessary?
    Is the process effectively supported by the legacy application software?
    Example - a travel ordering system may have a low business value because of the widespread use of web-based ordering.

    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 gather results of their business needs/value.

    Issues in business value assessment

    The use of the system
    If systems are only used occasionally or by a small number of people, they may have a low business value.
    The business processes that are supported
    A system may have a low business value if it forces the use of inefficient business processes.
    System dependability
    If a system is not dependable and the problems directly affect business customers, the system has a low business value.
    The system outputs
    If the business depends on system outputs, then the system has a high business value.

    System quality assessment

    Business process assessment
    How well does the business process support the current goals of the business?
    Environment assessment
    How effective is the system’s environment and how expensive is it to maintain?
    Application assessment
    What is the quality of the application software system?

  • Factors used in environment assessment

    Factor Questions
    Supplier stability Is the supplier still in existence? Is the supplier financially stable and likely to continue in existence? If the supplier is no longer in business, does someone else maintain the systems?
    Failure rate Does the hardware have a high rate of reported failures? Does the support software crash and force system restarts?
    Age How old is the hardware and software? The older the hardware and support software, the more obsolete it will be. It may still function correctly but there could be significant economic and business benefits to moving to a more modern system.
    Performance Is the performance of the system adequate? Do performance problems have a significant effect on system users?
    Support requirements What local support is required by the hardware and software? If there are high costs associated with this support, it may be worth considering system replacement.
    Maintenance costs What are the costs of hardware maintenance and support software licences? Older hardware may have higher maintenance costs than modern systems. Support software may have high annual licensing costs.
    Interoperability Are there problems interfacing the system to other systems? Can compilers, for example, be used with current versions of the operating system? Is hardware emulation required?
    Understandability How difficult is it to understand the source code of the current system? How complex are the control structures that are used? Do variables have meaningful names that reflect their function?
    Documentation What system documentation is available? Is the documentation complete, consistent, and current?
    Data Is there an explicit data model for the system? To what extent is data duplicated across files? Is the data used by the system up to date and consistent?
    Performance Is the performance of the application adequate? Do performance problems have a significant effect on system users?
    Programming language Are modern compilers available for the programming language used to develop the system? Is the programming language still used for new system development?
    Configuration management Are all versions of all parts of the system managed by a configuration management system? Is there an explicit description of the versions of components that are used in the current system?
    Test data Does test data for the system exist? Is there a record of regression tests carried out when new features have been added to the system?
    Personnel skills Are there people available who have the skills to maintain the application? Are there people available who have experience with the system?

    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

    P.S. Quantitative research gathers data in numerical form which can be put into categories, or in rank order, or measured in units of measurement.  E.g questionnaires can produce both quantitative and qualitative information.
    For example, add open-ended and/or closed questions in a questionnaire. Add closed questions on a questionnaire would generate quantitative data as these produce either numerical data or data that can be put into categories (e.g. “true”, “false” ; “agree”, “ disagree”, “no comment”; “yes”, “no” etc. answers).  Add open-ended questions would generate qualitative information as they are a descriptive response.

  • 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.

    It is often cheaper and less risky to maintain a legacy system than to develop a replacement system using modern technology.

    The business value of a legacy system and the quality of the application should be assessed to help decide if a system should be replaced, transformed or maintained.

    There are 3 types of software maintenance, namely bug fixing, modifying software to work in a new environment, and implementing new or changed requirements.

  • Glossary

    ABCDEFILMNPRSTVW

    A

    agile methods

    methods of software development that are geared to rapid software delivery. The software is developed and delivered in increments and process documentation and bureaucracy are minimised. The focus of development is on the code itself rather than supporting document.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.757

    Return to Top

    B

    black-box testing

    An approach to testing where the testers have no access to the source code of a system or its components. The tests are derived from the system specification.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.758

    brownfield software development

    The development of software for an environment where there are several existing systems that the software being developed must integrate with.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.759

    Return to Top

    C

    component

    A deployable, independent unit of software that is completely defined and accessed through a set of interfaces.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.760

    configuable appliation system

    An application system product, developed by a system vendor, that offers functionality that may be configured for use in different companies and environments.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.761

    COTS system

    A Commercial Off-the-Shelf system. The term COTS is now mostly used in military systems. See configurable application system.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.761

    Return to Top

    D

    data processing system

    A system that aims to processes large amounts of structured data. These systems usually process the data in batches and follow an input-process=-output model. Examples of data processing systems are billing and invoicing systems and payment systems.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.761

    domain

    A specific problem or business area where software systems are used. Examples of domains include real-time control, business data processing and telecommunications switching.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.762

    domain model

    A definition of domain abstractions, such as policies, procedures, objects, relationships and events/ It serves as a base of knowledge about some problem area.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.762

    Return to Top

    E

    enterprise resource planning (ERP) system

    A large-scale software system that includes a range of capabilities to support the operation of business enterprise and which provides a means of sharing information across these capabilities. For example, an ERP system may include support for supply chain management, manufacturing and distribution. ERP systems are configured to the requirements of each company using the system.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.763

    Return to Top

    F

    fault detection

    The use of processes and run-time checking to detect and remove faults in a program before tests result in a system failure.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.763

    Return to Top

    I

    incremental development

    An approach to software development where the software is delivered and deployed in increments.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.764

    interface

    A specification of the attributes and operations associated with a software component. The interface is used as the means of accessing the component's functionality.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.765

    Return to Top

    L

    legacy system

    A socio-technical system that is useful or essential to an organisation but which has been developed using obsolete technology or methods. Because legacy systems often perform critical business functions, they have to be maintained.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.773

    Return to Top

    M

    maintenance

    the process of making changes to a system after it has been put into operation.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.765

    Mentcare system

    Metal Health are Patient Management system. This is a system used to record information about consultations and treatments prescribed for people suffering from mental health problems. Used as a care study in this book.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.776

    Return to Top

    N

    non-functional requirement

    A statement of a constraint or expected behaviour that applies to a system. This constraint may refer to the emergent properties of the software that is being developed or to the development process.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.767

    Return to Top

    P

    pair programming

    A development situation where programmers work in pairs, rather than individually, to develop code; a fundamental part of extreme programming.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.768

    process improvement

    Changing a software development process with the aim of making that process more efficient or improving the quality of its outputs. For example, if your aim is to reduce the number of defects in the delivered software, you might improve a process by adding new validation activities.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.767

    process model

    An abstract representation of a process. Process models may be developed from various perspectives and can show the activities involved in a process, the artefacts used in the process, constraints that apply to the process and the roles of the people enacting the process.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.767

    Return to Top

    R

    rapid application development (RAD)

    An approach to software development aimed at rapid delivery of the software. It often involves the use of database programming and development support tools such as screen and report generators.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.768

    reengineering

    The modification of a software system to make it easier to understand and change. Reengineering often involves software and data restructuring and organisation, program simplification and documentation.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.774

    reengineering, business process

    Changing a business process to meet a new organisational objective such as reduced cost and faster execution.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.769

    refactoring

    Modifying a program to improve its structure and readability without changing its functionality.

    Sommerville I. 2016"Software Engineering" 10th Edition. Pearson Pp.769

    release

    A version of a software system that is made available to system customers.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.769

    reliability

    A version of a software system that is made available to system customers.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.765

    reliability growth modeling

    The development of a model of how the reliability of a system changes (improves) as it is tested and program defects are removed.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.769

    resilience

    A judgement of how well a system can maintain the continuity of its critical services in the presence of disruptive events, such as equipment failure and cyberattacks.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.769

    Return to Top

    S

    security

    The ability of a system to protect itself against accidental or deliberate intrusion. Security includes confidentiality, integrity and availability.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.771

    senario testing

    An approach to software testing where test cases are derived from a scenario of system use.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.770

    software process

    The activities and processes that are involved in developing and evolving a software system.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.772

    system engineering

    A process that is concerned with specifying a system, integrating its components and testing that the system meets its requirements. System engineering is concerned with the whole socio-technical system =- software, hardware and operational processes- not just the system software.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.773

    system testing

    The testing of a completed system before it is delivered to customers.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.773

    Return to Top

    T

    test coverage

    The effectiveness of system tests in testing the code of an entire system. Some companies have standards for test coverage (e.g. the system tests shall ensure that all program statements are executed at least once.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.773

    test-driven development

    An approach to software development where executable tests are written before the program codes. The set of tests are run automatically after every change to the program.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.773

    Return to Top

    V

    valiation

    The process of checking that a system meets the needs and expectations of the customer.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.774

    verification

    The process of checking that a system meets the needs and specifications.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.774

    version control

    The process of managing changes to a software system and its components so that it is possible to know which changes have been implemented in each version of the component/system, and also to recover / recreate previous versions of the component/system.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.774

    Return to Top

    W

    white-box test

    An approach to program testing where the tests are based on knowledge of the structure of the program and its components. Access to source code is essential for white-box testing.

    Sommerville I. 2016 "Software Engineering" 10th Edition. Pearson Pp.774

    Return to Top