Unit 1 SAQs

Question 1

SAQ 1
In Example 4, we suggested that two systems, for patient monitoring and managing medical records, might be combined into a single system.
Suggest an additional function that might be possible with the combined system that would not have been possible with either of the two original systems alone. What can you say about the boundary of the combined
system compared with the boundaries of the original separate systems?

Answer 1

Suppose the monitoring system detected that a patient taking a common drug had a heart problem. If the two systems were combined, it would be possible to automatically check whether the heart problem might be due to a known allergy recorded in the patient’s record.
The boundary of the combined system encompasses a wider scope than the combined boundaries of the separate systems because the combination of patient monitoring and medical records supports a wider range of verifications.

Question 2

SAQ 2
For each of the three characteristics of software mentioned above, explain why errors might arise in a piece of developed software.

Answer 2

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 3

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

Answer 3

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 4

SAQ 3

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

Answer 4

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 5

SAQ 3
(c) Give two reasons why a delivered software system might not meet its users’ needs.

Answer 5

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 6

SAQ 4
(a) Suggest a means of measuring the maintainability of a software system.

Answer 6

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 7

SAQ 4

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

Answer 7

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 8

SAQ 4

(c) Suggest a reason why legacy systems will always be a problem.

Answer 8

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.

Question 9

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

Answer 9

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 10

SAQ 5
(b) How does the complexity of a software system affect the maintenance task?

Answer 10

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 11

SAQ 5

(c) What is a module?

Answer 11

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 12

SAQ 5
(d) Why does it help to have low coupling in a software system?

Answer 12

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.

Question 13

SAQ 5
(e) Give examples of the kinds of information that would be valuable when considering a change to a given module.

Answer 13

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 14

SAQ 5
(f) What are the context dependencies of a module? How do they relate to a module’s interface?

Answer 14

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 15

SAQ 5
(g) What are the benefits of using modules with defined interfaces?

Answer 15

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 16

SAQ 5
(h) Why does it help to have high cohesion in the modules of a software system?

Answer 16

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 17

SAQ 5
(i) 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 17

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 18

SAQ 5
(j) Why is it important to achieve a balance between coupling and cohesion?

Answer 18

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 19

SAQ 6

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

Answer 19

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 20

SAQ 7
(a) What are the characteristics of a component?

Answer 20

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 21

SAQ 7
(b) How does the concept of an architecture contribute to component reuse?

Answer 21

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 22

SAQ 7

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

Answer 22

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 23

SAQ 7

(d) What are the similarities and differences between components and services?

Answer 23

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 24

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

Answer 24

Software development follows an engineering approach provided that the following conditions are met:

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

SAQ 9

(a) What is a development process?

Answer 25

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 26

SAQ 9
(b) What should the role of project management be with respect to the deliverables of a development project?

Answer 26

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 27

SAQ 9

(c) What is the difference between a customer and a user?

Answer 27

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 28

SAQ 9
(d) Suggest a reason why maintenance is a core activity in the development of a good software system.

Answer 28

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

Question 29

SAQ 9
(e) What additional task is needed when the development of a software system is partitioned into a number of increments?

Answer 29

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

Question 30

SAQ 9
(f) What are the assumptions on which the waterfall model is based?

Answer 30

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 31

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

Answer 31

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 32

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

Answer 32

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 33

SAQ 10

(c) Why are there additional risks when developing large projects?

Answer 33

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 34

SAQ 10
(d) What is added to a development process with the introduction of risk management?

Answer 34

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 35

SAQ 11
(a) Why is traceability important to the development of software?

Answer 35

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 36

SAQ 11
(b) How does documentation contribute to traceability within a development project?

Answer 36

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 37

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

Answer 37

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 38

SAQ 11
(d) For what kind of software system might you minimise or even avoid any documentation?

Answer 38

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 39

SAQ 11
(e) How would you characterise agile documentation?

Answer 39

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 40

SAQ 11
(f) Why is it important to review the contents of your project notebook?

Answer 40

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 41

SAQ 12
(a) What is a model?

Answer 41

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.

Question 42

SAQ 12
(b) What is a ‘good model’?

Answer 42

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 43

SAQ 12
(c) What are the two kinds of rule that govern the use of a modelling language?

Answer 43

Syntax and Semantics

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 44

SAQ 12
(d) Does a modelling language need to be associated with a particular development process?

Answer 44

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.

Question 45

SAQ 12
(e) What are the required characteristics of a standard modelling language?

Answer 45

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

Question 46

SAQ 12
(f) How does a standard modelling language contribute to software development?

Answer 46

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 47

SAQ 13
(a) Should you try to capture everything about a design in a single model?

Answer 47

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 48

SAQ 13
(b) What is the difference between a structural and a behaviour model?

Answer 48

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 49

SAQ 13

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

Answer 49

Yes, the whole set of diagrams should contain the different aspects ofa 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 50

SAQ 14
(a) What is the purpose of domain modelling?

Answer 50

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

Question 51

SAQ 14
(b) What is the role of each of the artefacts produced during domain modelling?

Answer 51

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 52

SAQ 15

What is the purpose of the requirements phase?

Answer 52

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

Question 53

SAQ 16

(a) What is the purpose of analysis?

Answer 53

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

Question 54

SAQ 16

(b) What is the purpose of design?

Answer 54

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

Question 55

SAQ 16

(c) What is the role of each of the artefacts produced during design?

Answer 55

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.