Unit 1 Flashcards Preview

TM354 Software engineering - Copy > Unit 1 > Flashcards

Flashcards in Unit 1 Deck (68)
Loading flashcards...
1

What is a system?

An assembly of components that are connected together in an organised way.

2

What is a socio-technical system?

A system seen as a whole, including the software, the hardware where it is installed and running, and the wider context that involves other technical components, but also people, organisations and other social structures.

3

What is meant by the viewpoint of a system?

A perspective on a system from the point of view of a particular person or group of people.

4

What is meant by a system boundary?

A conceptual division between the system to be studied and ‘everything else’.

5

What are the three important characteristics of software that affect its development and the likelihood of errors?

1. Malleability - Software is easy to change. This malleability creates a constant pressure for software to be changed rather than replaced. Every change introduces the possibility of new errors. 2. Complexity - Software is often complex. Complexity can usually be recognised, but it is less easy to define. One item of software can be considered more complex than another if it requires more explanation. Part of that complexity arises from the potential variety of pathways between the components of a system. The number of errors is likely to depend on the complexity of a system. 3. Size. It is likely that there will be more errors in a large piece of software than in a small one.

6

For each of these software characteristics: malleability, complexity, and size; explain why errors might arise in a piece of developed software.

Malleability - As change is easy to make, often changes are introduced without thorough consideration of the full consequences of each new change introduced. Complexity - The more complex a piece of software becomes, the more chances there are of a change affecting other parts of the software. Size - The greater the number of lines of code in a piece of software, the greater the number of likely errors.

7

What is the defining quality of a good software system, and what are its main characteristics?

A good software system is one that meets its users' needs. We can characterise a good software system as useful, usable, reliable, flexible and affordable.

8

How might greater flexibility make a software system more affordable over its whole life?

Users’ needs will change over time. The time taken to implement the changes in requirements in a flexible system is less than for less flexible software. As labour costs are the most significant component of software costs, flexible software is more affordable.

9

Give two reasons why a delivered software system might not meet its users’ needs.

Software systems are usually out of date even as they are being developed because: - some needs are often missed during requirements capture - users’ needs change with time.

10

What is meant by the maintainability of software?

The effort required to understand, locate and fix errors or make changes to a system i.e. how easily bugs can be found and fixed.

11

What is a legacy system?

An old software system that is still required because it meets some useful purpose to an organisation. It is not considered to be replaceable and so it is maintained, usually on a restricted budget.

12

What can we learn from legacy systems about developing a good software system?

A legacy system may have started out with all the characteristics of a good software system, yet those characteristics may have changed over time, resulting in a less flexible and maintainable product. As change is inevitable, the right processes should be in place to make change happen in a more controlled way. This requires the adoption of standards and documentation conventions that help decision making on changes and how to introduce them. Any changes need to be well documented so that software is still understandable and less dependent on the people initially involved with developing and maintaining the software.

13

Suggest a reason why legacy systems will always be a problem.

The inherent malleability of software makes it easy to change. A legacy system can therefore lack flexibility as a result of the number of changes made to it during its operational lifetime. The ability to bolt features and fixes onto a legacy system means that it will eventually become too fragile, and it will become precarious to go any further.

14

What is meant by decomposition?

Splitting a problem into smaller and smaller parts or chunks until each one can be comprehended or dealt with by an individual. In software we identify a number of different activities or tasks that an individual or a group of individuals might perform.

15

What is meant by a module interface?

The interface of a module is a description of all the externally visible operations and what other modules need to know and do to make use of them, but without any details of how the operations are implemented internally.

16

What is meant by abstraction?

It is the process of describing the essential features of a problem and ignoring other details. It permits you to concentrate on a problem at some level of generalisation, without regard to irrelevant detail. It also permits you to work with concepts, terms and models that are familiar in the problem environment (or domain).

17

Why might you consider splitting up a large project into smaller chunks (decomposition)?

There is a limit to how much one person can understand at any one time. So there is a limit to the size of a software system that any one person can deal with. By splitting a large project into smaller chunks, it is possible to identify a number of more manageable tasks for those involved.

18

How does the complexity of a software system affect the maintenance task?

It is essential to be able to make a change to a software system without having to know all about that system. Each change becomes difficult when the flow of control and dependencies within programs are complex. The greater the number and nature of the dependencies, the harder it is to maintain a software system.

19

What is a module?

A module is any identifiable part of a software system that is considered separately. For example, modules may be subroutines, classes, library functions, or other constructs that may be treated independently.

20

Why does it help to have low coupling in a software system?

With low coupling, there are few dependencies between modules. Therefore changes made to one part (one or more modules) of a software system are less likely to propagate throughout the whole system. (A clear record of the dependencies between modules helps you to predict the impact of a proposed change to a software system.)

21

Give examples of the kinds of information that would be valuable when considering a change to a given module.

There are two kinds of information that contribute to the analysis of a proposed change: - Which modules are clients of the module in question? This information indicates how far a change may propagate through the software system. - What assumptions have been made in client modules of the module in question? An understanding of the expected services of a module will help assess the risks associated with a particular change.

22

What are the context dependencies of a module? How do they relate to a module’s interface?

The context dependencies for a module are the services of other modules that the module needs in order to work correctly. You can express the context dependencies for a module in terms of other interfaces. In effect, you can express the responsibilities of a module in terms of its interface and context dependencies. If the context provides the services that the module needs and clients meet any conditions specified in the interface, the module can guarantee the provision of the services described in its interface.

23

What are the benefits of using modules with defined interfaces?

The benefits are as follows: - Developers will need to know only about the module’s interface (its syntax and what it requires and achieves – its semantics), not how it provides those services. Consequently developers can be more productive. - Developers can understand aspects of the software system more thoroughly, so fewer bugs will be introduced. - It should be easier to find bugs, as irrelevant modules are avoided. - The possibility of module reuse is increased once it is known what that module provides and requires.

24

Why does it help to have high cohesion in the modules of a software system?

With high cohesion, a module carries out a sensible set of operations or activities. Ideally high cohesion implies just one major abstraction per module. The interface abstracts away from what a developer must know in order to use a module. This makes it easier for developers to understand the purpose of the module and how to use it. In addition high cohesion tends to make a module more reusable in other applications, because it provides a set of operations that sit naturally together.

25

What characteristics should a module display that will help to ensure that it is easy and cheap to develop and maintain, and that errors are kept to a minimum?

A module should have low coupling and high cohesion, represent a good abstraction, and have a well-defined interface that is an encapsulated abstraction of a well-understood concept.

26

Why is it important to achieve a balance between coupling and cohesion?

In constructing a system, you may have a choice between a smaller set of loosely coupled, less cohesive modules, or a larger set of tightly coupled, more cohesive modules. In the former case each module may be difficult to understand, while in the latter case the relationships between them may be over-complex. You need to strike an appropriate balance.

27

What is meant by the software architecture of a system?

It is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

28

What are the characteristics of a component?

A component is a module that is considered to be a sufficiently good abstraction for the problem in hand. A component should be capable of being reused in future projects having the same software architecture, or being easily replaced at a later date within the existing software system. As with all modules, a good component has a well-defined interface and is an encapsulated abstraction of a well-understood concept, with strong cohesion and low coupling.

29

How does the concept of an architecture contribute to component reuse?

The architecture of a software system embodies high-level decisions about the overall structure of the system, and this architecture may apply to more than one system.

30

Which form of decomposition might be used in a software architecture?

The basic form of decomposition used in a software architecture is partitioning to meet a number of separate concerns, each concern being addressed by a subsystem. For example, you might want to separate the user interface layer from the core business services layer, or you may decide to build or reuse components and/or services for some of the partitions.