Unit 1 - Approaches to software development

Question 1

What is a system?

Answer 1

We define a system as ‘an assembly of components that are connected together in an organised way’.

Question 2

A successful software project

must?

Answer 2

. resolve the diverse and possibly conflicting needs of users in a disciplined way
. satisfy the users’ expectations
. have been developed and delivered in a timely and economical manner
. be resilient to the changes that will be introduced during its operational lifetime
. demonstrate good overall system quality.

Question 3

What is a sociotechnical system?

Answer 3

A system that includes software, hardware which is part of a much wider context that involves not only other technical components, but also people, organisations and other social structures.

Question 4

What is a system boundary?

Answer 4

The system boundary is a conceptual line that divides the system that you want to study from ‘everything else’.

Question 5

What is a viewpoint?

Answer 5

A viewpoint is a personal understanding of a system depending on the sets of users interacting with it. Different viewpoints of a system correspond
to different sets of users and therefore different purposes.

Question 6

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

Answer 6

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

. 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. The number of errors is likely to depend on
the complexity of a system.

. Size. It is likely that there will be more errors in a large piece of software than in a small one.

Question 7

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

Answer 7

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 8

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

Answer 8

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 9

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

Answer 9

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 10

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

Answer 10

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 11

What are typical characteristics of legacy systems?

Answer 11

. old
. large
. developed using outdated techniques
. implemented with old programming languages
. critical to the business
. changed a number of times since their inception
. difficult to understand because of either a lack of documentation about their internal structure or a lack of experience within the group responsible for them
. difficult to maintain because of the above factors.

Question 12

Suggest a means of measuring the maintainability of a software system?

Answer 12

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 13

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

Answer 13

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 14

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

Answer 14

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.

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.

Still being dependent on the original developers, compound these problems.

Question 15

What is meant by decomposition?

Answer 15

Decomposing a problem into smaller and smaller parts or chunks until each one can be comprehended or dealt with by an individual

Question 16

What is the purpose of a module interface?

Answer 16

An interface to a module defines how other modules
can use that module. An interface is the means of connecting one module to another. 

It tells you what to expect about the behaviour of a given module and what services the module will provide, without telling you how those services
will be provided.

Question 17

What is meant by a module’s context dependencies?

Answer 17

A module may need to use the services of other modules. These are called its context dependencies.

Question 18

What is abstraction?

Answer 18

Abstraction is a particular way of viewing a complex problem to arrive at some useful decomposition of that problem.

Useful abstraction is achieved in a particular module
if the potential software clients of that module do not need to know more than is contained in its interface.

Question 19

What is coupling?

Answer 19

It refers to the degree of interdependence among the different parts of a system.

Question 20

What are the benefits of a loosely coupled system?

Answer 20

They are easier to understand and maintain.

A good software system has low coupling, which means that changes to one part are less likely to affect other parts of the system.

A further benefit of low coupling is that components are easy to replace and, potentially, reuse.

Question 21

What is cohesion?

Answer 21

Cohesion is a way of describing how closely the activities within a single module are related to each other.

In software systems, a highly cohesive module performs one task or achieves a single objective – ‘do one thing and do it well’ is a useful motto to apply.

Question 22

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

Answer 22

By splitting a large project into smaller

chunks, it is possible to identify a number of more manageable tasks for those involved.

Question 23

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

Answer 23

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 24

What is a module?

Answer 24

A module is any identifiable part of a software system that is considered separately.

Question 25

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

Answer 25

With low coupling, there are few dependencies between modules. Therefore changes made to one part of a software system are less likely to propagate throughout the whole system.

Question 26

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

Answer 26

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 27

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

Answer 27

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.

Question 28

What are the benefits of using modules with defined interfaces?

Answer 28

The benefits are as follows:

◦ Developers will need to know only about the module’s interface, 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 29

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

Answer 29

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 30

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 30

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 31

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

Answer 31

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 32

What is meant by architecture in software development?

Answer 32

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

Question 33

Give an example of a layered architecture in a computing system.

Answer 33

Presentation layer
Application domain
Infrastructure (OS/databases)

Question 34

What does re-use help address?

Answer 34

Reuse is one strategy to deal with increased complexity of software and it addresses the concerns of maintainability, minimising costs, short delivery
times and quality of software.

Question 35

What is a service?

Answer 35

A service is a unit of reuse corresponding to a piece of functionality, described in a standard language,
with published interfaces through which the service execution can be requested.

A service can be invoked using standard communication protocols.

A service is also discoverable, meaning that it can be used by clients independently of where it is located

Question 36

How do consumers use services?

Answer 36

They need to find them in a registry of service descriptions and once found they can bind to and invoke them.

Question 37

What are the characteristics of a component?

Answer 37

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 38

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

Answer 38

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 39

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

Answer 39

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 40

What are the similarities and differences between components and services?

Answer 40

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.

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.

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.

Question 41

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

Answer 41

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 42

List some common technical activities for the development of software:

Answer 42

Domain modelling. Understanding the environment in which a system may be introduced – the business processes and rules.

Requirements. A set of steps including requirements elicitation, where you identify the problem, and
requirements analysis, where you categorise, prioritise and model requirements. This defines what the system is to do.

Design. Determining how you will solve the problem.

Implementation. Acting upon the decisions made at the design stage.

Testing. Testing what you have done so that you can determine whether or not you have solved the problem.

Question 43

List 4 values of Agile Software Development

Answer 43

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Question 44

10 key principles of Agile

Answer 44

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

Question 45

Scum events comprise?

Answer 45

. the sprint – a development phase, no longer than a month, that has as a deliverable a useable working increment

. the sprint planning meeting – lasts no more than eight hours

. the daily scrum – a daily meeting, no longer than 15 minutes, looking at what has been done and planning the work for the next 24 hours.

Question 46

Why is traceability important to the development of software?

Answer 46

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 47

How would you characterise agile documentation?

Answer 47

Agile documentation should be gathered with a purpose, should be easy to use and above all should justify the effort put into gathering it.

Question 48

What are the main problems associated with the development of software?

Answer 48

. difficulty in capturing all the user requirements

. difficulties in managing and developing large and complex systems

. not meeting users’ requirements and avoiding dissatisfaction with the completed software

. continual changes in user requirements (often referred to as requirements creep)

. maintaining poorly documented software

. the presence of errors introduced unknowingly during development

. a changing world leading to changes in the needs of the users and decreasing the usefulness of the software

. low productivity of those developing software, and difficulties in measuring that productivity

. ensuring the quality of a software system.

Question 49

In terms of the development of software systems, models are?

Answer 49

. a way of understanding the problems involved

. an aid to communication among those involved, especially between the developer and the user, as part of some deliverable

. a component of the processes used in development activities such as analysis and design.

Question 50

In Agile, modelling should?

Answer 50

Only be done with a purpose and up to the point where they stop being useful.

Question 51

What is a model?

Answer 51

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 52

What is a ‘good model’?

Answer 52

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 53

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

Answer 53

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 54

What are the required characteristics of a standard modelling language?

Answer 54

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

Question 55

How does a standard modelling language contribute to software development?

Answer 55

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 56

In developing object-oriented software systems, the two distinct kinds of models are?

Answer 56

. structural (or static) models, which describe the objects in the real world or in a (software) system and their relationships to other objects

. behaviour (or dynamic) models, which describe the behaviour in the real world or of a (software) system over time.

Question 57

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

Answer 57

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 58

List the four major phases of a UP Project

Answer 58

1 Inception. The business case is developed, together with an idea of the scope of the system and a rough estimate of the effort required.

2 Elaboration. The core of the system is developed in an iterative fashion. In this phase all major risks are addressed and resolved, most of the requirements are identified and dealt with, and a more realistic estimate of the effort required is made.

3 Construction. The final product is constructed, including the remaining lower-risk and easier elements of the system, again in an iterative fashion.

4 Transition. This includes beta testing and deploying the system.

Question 59

What is the purpose of domain modelling?

Answer 59

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

Question 60

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

Answer 60

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 61

What is the purpose of the requirements phase?

Answer 61

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

Question 62

During the design process, which behavioural models are used?

Answer 62

UML uses interaction (sequence and communication) diagrams that show a set of classes and the messages between them.

Question 63

What is the purpose of analysis?

Answer 63

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

Question 64

What is the purpose of design?

Answer 64

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

Question 65

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

Answer 65

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.