Chapter 7:

 Design and implementation phase

- Stage at which an executable software system is developed

- Software design and implementation activities are invariably inter-leaved
- Sometimes there is a separate design stage, and this design is modeled and
documented.
- Design is about how to solve a problem, so there is always a design process.
 What do context diagrams represent?
- the interactions between a system and other actors (external factors)
 Relationship between use-case and context diagram.

- System context models and interaction models present complementary views of the
relationships between a system and its environment

 We talked about how UML diagrams and architectural models are applied to “design and
implementation” in chapter 7. If you need more information about these diagrams and
architectures, refer to chapters 5 & 6.
 Difference between Structural and dynamic models.
- Structural describes the static structure of the system while the dynamic describes the
dynamic interaction between objects.
 How observer pattern works.
- defines one to many dependencies(relationships) between objects. When one object
changes state, all of its dependencies are notified and updated automatically.
 Advantages and disadvantages of software reuse.

- Advantages: Faster development periods, Lower development risks.

- Disadvantages: Costs and schedule pressure mean that this approach became
increasingly unviable, especially for commercial and Internet-based systems.
 Know the descriptions of software reuse, configuration management, and host target
development.

- Software reuse: The only significant reuse or software was the reuse of functions and
objects in programming language libraries.
- Configuration management: general process of managing a changing software system.
- Host target development: Most software is developed on one computer (the host), but
runs on a separate machine (the target).

 Version management, system integration, and problem tracking.

- Version management: where support is provided to keep track of the different versions
of software components.
 - System integration: where support is provided to help developers define what versions
of components are used to create each version of a system.
- Problem tracking: where support is provided to allow users to report bugs and other
problems, and to allow all developers to see who is working on these problems and
when they are fixed.

 How open-source development works: In principle at least, any contributor to an open-

source project may report and fix bugs and propose new features and functionality.
However, in practice, successful open-source systems still rely on a core group of
developers who control changes to the software.

Chapter 8:

 Things you would perform during the testing phase

- demonstrate to the developer and the customer that the software meets its
requirements.
- Discover situations in which the behavior of the software is incorrect, undesirable, or
does not conform to its specification. Caused by defects(bugs)
 Validation testing and defect testing.
- The first goal leads to validation testing

o You expect the system to perform correctly using a given set of test cases that
reflect the system’s expected use.

- The second goal leads to defect testing

o The test cases are designed to expose defects. The test cases in defect testing can
be deliberately obscure and need not reflect how the system is normally used.

 Difference between software inspection and software testing.

- Software inspection: Concerned with the analysis of

the static system representation to discover problems (static verification)
- Software testing Concerned with exercising and observing product behavior (dynamic
verification)
 Meanings of development testing, release testing, and user testing.

- Development testing, where the system is tested during development to discover bugs
and defects.
- Release testing, where a separate testing team tests 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.
 Three stages of development testing: Unit testing, component testing, and system testing.}

1. Unit testing, where individual program units or object classes are tested. Unit
testing should focus on testing the functionality of objects or methods.
 2. Component testing, where several individual units are integrated to create
composite components. Component testing should focus on testing component
interfaces that provide access to the component functions.
3. System testing, where some or all the components in a system are integrated and
the system is tested as a whole. System testing should focus on testing component
interactions.
 Testing strategies: partition testing and guideline-based testing.
- Partition testing, where you identify groups of inputs that have common
characteristics and should be processed in the same way.
- Guideline-based testing, where you use testing guidelines to choose test cases.
 Test-driven development and extreme programming(XP).

- Test-driven development (TDD) is an approach to program development in which you

inter-leave testing and code development.
- TDD was introduced as part of agile methods such as Extreme Programming(XP).
However, it can also be used in plan-driven development processes.
 Benefits of test-driven development.

- helps programmers clarify their ideas of what a code segment is actually supposed to
do.
 Requirement testing and performance testing.

- Requirement testing: To check if these requirements have been satisfied.

- Performance testing: usually involve planning a series of tests where the load is
steadily increased until the system performance becomes unacceptable.
 User testing: Alpha, beta, acceptance. Know the meaning of these.

- Alpha testing
 where a selected group of software users work closely with the development team
to test early releases of the software.
- Beta testing
 where a release of the software is made available to a larger group of users to
allow them to experiment and to raise problems that they discover with the
system developers.
- Acceptance testing
 Customers test a system, using their own data, and decide if it should be accepted
and ready to be deployed in the customer environment. Primarily for custom
systems. Acceptance implies that final payment should be made for the software.

Chapter 9:

 Reasons for software change

- 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.
 Development and evolution

 Urgent change requests

- Urgent changes may have to be implemented without going through all stages of the
software engineering process.
o If a serious system fault has to be repaired to allow normal operation to
continue.
o If changes to the system’s environment (e.g. an OS upgrade) have unexpected
effects.
o If there are business changes that require a very rapid response (e.g. the
release of a competing product). New legislation that affects the system.

 Challenges facing evolution

- A key problem for all organizations is implementing and managing change to their
existing software systems.
 What is a legacy system and its components
- Legacy systems are older systems that rely on languages and technology that are no
longer used for new systems development.
Components:
o System hardware Legacy systems may have been written for hardware that is
no longer available, or expensive to maintain.
o Support software The legacy system may rely on a range of support
software(from the operating system and utilities provided by the hardware
manufacturer), which may be obsolete or unsupported.
o Application software The application system that provides the business
services is usually made up of a number of application programs.
o Application data These are data that are processed by the application system.
In many legacy systems, an immense volume of data has accumulated over the
lifetime of the system. They may be inconsistent, duplicated, or held in
different databases.
  Reasons for legacy system replacement:
- Legacy system replacement is risky and expensive so businesses continue to use these
systems
 Challenges facing legacy system replacement
- 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
 Four basic issues that you have to discuss with stakeholders when determining the value of
a legacy system.

- The use of the system

o If systems are only used occasionally or by a small number of people. This may
mean that it has a low business value.
- The business processes that are supported
o A system may have a low business value if it forces the use of inefficient
business processes.
- System dependability
o If a system is not dependable and the problems directly affect business
customers, the system has a low business value.
- The system outputs
o If the business depends on system outputs, then the system has a high
business value.
 What is done at the maintenance stage?
- Modifying a program after it has been put into use.
- Changes are implemented by modifying existing components and adding new
components to the system.
 Maintenance cost and how to reduce it
- Usually greater than development costs (2* to 100* depending on the application).
- The only way around this problem is to integrate development and maintenance so
that the original development team remains responsible for software throughout its
lifetime.
 Difference between refactoring and reengineering
- Re-engineering takes place after a system has been maintained for some time and
maintenance costs are increasing. You use automated tools to process and re-engineer
a legacy system to create a new system that is more maintainable.
- Refactoring is a continuous process of improvement throughout the development and
evolution process. It is intended to avoid the structure and code degradation that
increases the costs and difficulties of maintaining a system.
 What do bad smells in program code mean.
- where the code of a program can be improved.

Local and global impacts of computing solutions on individuals, organizations, and society
• Know the positive and negative impact of computing solutions

Positive: Employment benefits, higher quality products, aid to the handicapped, improved safety,
better information retrieval

Negative: Computing solutions sometimes produce displacement and unemployment,

Unemployment refers to the total number of people, which are out of work, If displacement
workers cannot find similar jobs elsewhere or if they cannot find other work, then there is indeed
an increase in unemployment, Another problem is preserving the privacy of confidential
information when large data banks are linked by networks, etc.