Block 1 Unit 1

Question 1

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

Answer 1

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.

Question 2

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

Answer 2

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

Question 3

How might greater flexibility make a software system more

affordable over its whole life?

Answer 3

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.

Question 4

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

Answer 4

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.

Question 5

Suggest a means of measuring the maintainability of a software system

Answer 5

We could measure the effort required by a developer to locate and implement a given change to a software system. That effort can be classified in two components – the effort needed to locate and fix errors (bugs), and the effort needed to adapt the software system to meet its users’ needs.

Question 6

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

Answer 6

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.

Question 7

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

Answer 7

The inherent malleability of software makes it easy to change. You have already seen that a legacy system is lacking in flexibility as a result of the number of changes made to it during its operational lifetime. (The analogy with metalworking through malleability is useful. Once a blacksmith forms some component, usually in iron,
there is a limit to the number of times that it can be heated, formed and cooled before that component becomes brittle and hence liable to failure.)
This explains why our 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. The staff issues mentioned in (b) compound these problems.

Question 8

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

Answer 8

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.

Question 9

How does the complexity of a software system affect the

maintenance task?

Answer 9

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.

Question 10

What is a module?

Answer 10

A module is any identifiable part of a software system that is considered separately. For example, modules may be subroutines (in a procedural language equivalent to methods), classes (in an object-oriented language), library functions or other constructs that may be treated independently.

Question 11

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

Answer 11

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

Question 12

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

Answer 12

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

Question 13

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

Answer 13

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.

Question 14

What are the benefits of using modules with defined interfaces?

Answer 14

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.

Question 15

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

Answer 15

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

Question 16

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?

Answer 16

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.

Question 17

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

Answer 17

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.

Question 18

Suggest some similarities and differences between software architecture and
building architecture.

Answer 18

They are both abstractions of the structure of a system. They represent decisions that will affect concerns of different stakeholders. They are used as a communication vehicle with different stakeholders.
Changing a building once complete is expensive, whereas changing details or internal decoration is quite cheap but may incur costs in wastage in materials. Software has different properties from building components, in particular its malleability and complexity. Reworking the whole architecture of a software system is also expensive because of the complexity involved
– making internal changes does not incur costs in wastage of materials, as software is malleable, but it incurs other costs in terms of time and work invested.

Question 19

What are the characteristics of a component?

Answer 19

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.

Question 20

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

Answer 20

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.

Question 21

Which form of decomposition might be used in a software

architecture?

Answer 21

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.

Question 22

What are the similarities and differences between components and services?

Answer 22

There are similarities between a service and a component. They both promote reuse and flexibility. They both use public interfaces to allow requesters to make use of their functionality without relying on their implementation. There are differences too. A component is usually implemented in a specific object-oriented technology, therefore only clients compliant with that technology can easily communicate and integrate with it. In contrast, a service uses communication standards that allow the interoperation of diverse technologies.
Finally, components tend to be associated with business entities, while services tend to be associated to business processes – they may realise part or the whole of the functions within such a process and may involve several business entities. Be aware that although this is a widely accepted classification, not everyone follows it, and you may see components called services and vice versa.

Question 23

Give the characteristics of an engineering approach that support the argument that software development is an engineering discipline.

Answer 23

. it is concerned with meeting a set of requirements that are defined as clearly as possible
. it uses a defined process with clear activities, each of which has at least one identifiable end product
. developers can apply their skills and experience to the tasks demanded of them
. validation and verification are regarded to be as essential as building the software itself
. it makes sensible use of tools and standards
. it follows a code of practice.

Question 24

What is a development process?

Answer 24

A development process is a set of rules that defines how a software development project should be carried out. It incorporates a number of activities, and a process model (or life cycle) that indicates how these activities are ordered

Question 25

What should the role of project management be with respect to the deliverables of a development project?

Answer 25

A good software system must be affordable and available within an appropriate timeframe. Each deliverable uses resources, such as developers’ time, that add to its cost. Project management involves the identification of the appropriate deliverables for a given set of requirements and controlling the cost of producing them. Project management also involves ensuring that deliverables are produced on time and taking steps to cope with any delays.

Question 26

What is the difference between a customer and a user?

Answer 26

A customer is the person who pays for a software system, whereas a user is someone who will use that system on a day-to-day basis. A customer will also be a user when the proposed software system is intended to support their job.

Question 27

Suggest a reason why maintenance is a core activity in the

development of a good software system.

Answer 27

Maintenance allows a software system to evolve over its operational lifetime so that it continues to be useful.

Question 28

What additional task is needed when the development of a software system is partitioned into a number of increments?

Answer 28

A task devoted to the integration of the increments to form the final software system will be needed.

Question 29

What are the assumptions on which the waterfall model is based?

Answer 29

There is an assumption that once a particular activity or phase is finished, it is not re-entered, and that the activities do not overlap but follow each other in a sequential life cycle. There is no need for reviewing or reworking. All this presupposes that an end point for
each activity can be identified.

Question 30

Why might a software development company specialise in a certain
kind of customer, such as those in banking or health care?

Answer 30

Through specialisation, a software development company can foster experience in a given domain, whether it is banking, health care or any other field of interest. The developers in that company would have (or would hope to gain) sufficient knowledge to understand the problems raised by the users and therefore be able to present solutions in a form that can be understood by those users. In addition, the company may develop and use a consistent development process that is appropriate to the set of customers in that domain.

Question 31

In which of the activities in Figure 5 would you expect to do your configuration management during a project?

Answer 31

Maintenance deals with change. Configuration management is the discipline of managing and controlling change, and so you would
expect maintenance to be where you would perform many of the configuration tasks. However there is a role for configuration management during the development process in, for example, ensuring the consistency of models. Quality management is the activity in which you would perform these tasks.

Question 32

Why are there additional risks when developing large projects?

Answer 32

The chances of failure increase as the size of a software project increases, as more errors are likely to be introduced. Effective communication between the members of a large team also becomes more difficult.

Question 33

What is added to a development process with the introduction of risk management?

Answer 33

The most important additional aspect is the use of the identification, evaluation and reviewing of risks that are carried out with each iteration of the development. These steps introduce feedback into the process to help ensure that the deliverables at each stage are leading in a timely manner towards the correct product, and risks are controlled.

Question 34

Why is traceability important to the development of software?

Answer 34

Traceability is important for the reconstruction of significant events. In software development it should be possible to follow all the activities undertaken in response to a proposed change. In particular, you should be able to trace backwards from an implemented component or components, through their design, to a given requirement.

Question 35

How does documentation contribute to traceability within a development project?

Answer 35

Within a development project, documentation records the progress from requirements to implementation (and beyond). It is possible to identify each requirement and follow the actions taken to implement a solution to that requirement. You might, quite simply, be required to show that you have implemented each requirement correctly.

Question 36

Which activity or activities in the development process (shown in Figure 5) are most affected by poor documentation?

Answer 36

All seven activities will be affected by poor documentation. The maintenance and quality management activities will be most affected because they rely on the existence of traceability within the outputs of a development activity. (You saw this problem earlier when we looked at legacy systems.)

Question 37

For what kind of software system might you minimise or even avoid any documentation?

Answer 37

If a proposed software system is likely to have a short lifetime and will be discarded after use, it may be acceptable to minimise or avoid the task of documentation.

Question 38

How would you characterise agile documentation?

Answer 38

Agile documentation should be gathered with a purpose, should be easy to use and above all should justify the effort put into gathering it. There is no reason why this shouldn’t apply to any kind of documentation but often software development produces heavy documentation that is rarely used.

Question 39

Why is it important to review the contents of your project notebook?

Answer 39

The act of reviewing your notes helps you to identify what worked and what did not, as long as the notebook records accurately what you did and when. A review helps you to trace the events that led to the decisions you made since your previous review. Regularly reviewing your notes also enables you to check that you have followed up on all the decisions that you made.

Question 40

What is a model?

Answer 40

A model, in terms of software development, is an abstract representation of a specification, a design or a system, from a particular point of view. In general, it is a simplification of reality, created in order to understand an aspect or viewpoint of the system in question.

Question 41

What is a ‘good model’?

Answer 41

A ‘good model’ is an abstraction that allows those involved to concentrate on the essentials of a complex problem by excluding non-essential details while capturing those of interest.

Question 42

What are the two kinds of rule that govern the use of a modelling language?

Answer 42

A modelling language is normally diagrammatic, although it can be textual. In common with natural language, there are two distinct kinds of rule:
◦ those that determine whether or not a diagram is legal – the syntax of a diagram
◦ those that define what a legal diagram means – the semantics of a diagram.

Question 43

Does a modelling language need to be associated with a particular development process?

Answer 43

No, a modelling language does not dictate how it should be used and it is up to a development process to define which notations are appropriate and how they should be used. With experience practitioners tend to pick and mix from different modelling languages and use the notations that are most appropriate to the task – most modelling languages do not provide notations for all types of tasks.

Question 44

What are the required characteristics of a standard modelling language?

Answer 44

When choosing a modelling language, it should be:
◦ sufficiently expressive
◦ easy to learn and use
◦ unambiguous
◦ widely used
◦ supported by suitable tools.

Question 45

How does a standard modelling language contribute to software development?

Answer 45

) A standard modelling language helps when new people join a project – a common modelling language reduces the time needed to enable them to become productive team members. Also, when a modelling language is widely used, it is likely that project components will
have been constructed using that language. This makes the software easier and cheaper to maintain.

Question 46

Should you try to capture everything about a design in a single model?

Answer 46

No, because you will be interested in different aspects of a design at
different times, and different models of your design will be built to
reflect your interpretations of users’ needs.

Question 47

What is the difference between a structural and a behaviour model?

Answer 47

A structural model describes the elements of the system and their
relationships to other elements. A behaviour model describes the
behaviour of a system over a period of time.

Question 48

Do the models used in a given development project need to be consistent?

Answer 48

Yes, the whole set of diagrams should contain the different aspects of
a single software system, so they should not contradict one another.
For example, there must be some consistency checking between the
static and dynamic models. This can be automated by a suitable tool.

Question 49

What is the purpose of domain modelling?

Answer 49

Domain modelling is concerned with gaining an understanding of the
environment in which any system that is designed must operate.

Question 50

What is the role of each of the artefacts produced during domain modelling?

Answer 50

During domain modelling, we produce the following artefacts:
◦ initial problem statement – a description of the problem
◦ behaviour model – a description of the business processes and behaviour of the domain
◦ business rules – constraints on the way the behaviour model operates
◦ glossary – definitions of relevant terms
◦ structural domain model – an initial structural model
representing the concepts relevant to the domain.

Question 51

What is the purpose of the requirements phase?

Answer 51

The requirements phase is concerned with establishing and modelling what a software system must do.

Question 52

What is the purpose of analysis?

Answer 52

Analysis starts modelling the structure and behaviour of a software solution from a user’s perspective.

Question 53

What is the purpose of design?

Answer 53

Design is concerned with making decisions concerning how a system will meet its specification.

Question 54

What is the role of each of the artefacts produced during design?

Answer 54

During design you produce the following artefacts:
◦ structural model, an updated version of the one produced during analysis but with its operations specified
◦ behavioural models, showing how objects in the system will interact and behave internally, and also how functionality will be distributed across the system.

Question 55

Software may deteriorate over time because…

Answer 55

a. errors are introduced when the software is changed

b. errors are caused by the environment in which the software operates

Question 56

Decomposition helps people

Answer 56

to cope with complexity.

Question 57

give 2 points regarding Abstraction

Answer 57

allows you to hide detail and focus on specific aspects.

is a good basis for modelling.

Question 58

The waterfall model of software development is

Answer 58

a reasonable approach when the requirements are well understood and defined

Question 59

Agile software development:

Answer 59

does not require heavy documentation

Question 60

Traceability:

Answer 60

allows you to control the effect of changes to requirements

Question 61

Modelling:

Answer 61

can help communication among team members