Unit 1

Question 1

In Example 3, 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 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 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 of their relationship.

Question 2

• Malleability. Software is easy to change (all programmers are often tempted to ‘tweak’ their code). This malleability creates a constant pressure for software to be changed rather than replaced. Every change that is made to the software 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 the description of the first requires more explanation than that of the second. 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.
• Size. It is likely that there will be more errors in a large piece of software than there will be in a small one.

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

Answer 2

Malleability: every time a change is made to a piece of software it introduces the possibility of a new error; the easier it is to make changes, the greater the chances of introducing new errors into the software.

Complexity: the more complex a piece of software becomes, the more chances there are of introducing an error.

Size: there are likely to be more errors in a large piece of software than in a small one.

Question 3

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, affordable and available.

Question 4

How might greater flexibility make a software system more affordable?

Answer 4

Users’ needs will change over time. The time taken to implement the changes in requirements is less than if that software were inflexible. Since labour costs are the most significant component of software costs, flexible software is more affordable.

Question 5

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, since users’:

• needs are often missed during requirements capture;
• needs change with time.

Question 6

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 eventually implement a given change to a software system.

We could classify that effort in two components:

• the effort needed to locate and fix errors (bugs);
• the effort needed to adapt the software system to meet its users’ needs.

Question 7

How does a legacy system relate to the attributes of a good software system?

Answer 7

A legacy system is lacking in flexibility. It may have started out with all the characteristics of a good software system, yet those characteristics may have changed over time. The longer a software system is used, the more difficult it will become to maintain, because of the number of changes made since its development. So it gradually loses its maintainability. As a software system ages, the quality of applied changes will be affected by their affordability and the relative importance of the system. Ultimately all the staff who developed and knew about the software system may have moved on, so those new staff allocated to its maintenance may not fully comprehend its features. This can happen to all software systems, including those being developed today. Thus a legacy system still serves some useful purpose, but there are problems that make it less flexible and maintainable (and so affordable) than it was originally.

Question 8

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 metal-working 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 9

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

Answer 9

There is a limit to how much a 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

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

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

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. (A clear record of the dependencies between modules helps you to predict the impact of a proposed change to a software system.)

Question 13

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, and these are as follows.

• What assumptions have been made in other modules (clients) that call upon the module in question?
• An understanding of the expected services of a module will help assess the risks associated with a particular change. Which modules are clients of the module in question?

This information indicates how far a change may propagate through the software system.

Question 14

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 those services 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, then the module can guarantee the provision of the services described in its interface.

Question 15

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 achieves – its semantics), not how it provides those services, and 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

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. The developer can concentrate on the work required and create software that is useful, usable, reliable and affordable. Indeed, high cohesion tends to make a module more usable.

Question 17

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,
• a good abstraction,
• a well defined interface that is an encapsulated abstraction of a well understood concept.

Question 18

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

Answer 18

In constructing a system, we 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; in the latter case the relationships between them may be over-complex.

We need to strike an appropriate balance.

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.

A good component has a well defined interface and is an encapsulated abstraction of a well understood concept.

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. (An approach called product-line development, covered later in M363, will produce a sequence of systems that have much in common, through a shared architecture, and makes software more affordable if it uses the same components.)

Question 21

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

Answer 21

Complexity is best managed by decomposing a problem into smaller subproblems. The basic form of decomposition used in a software architecture is partitioning to meet a number of separate concerns. For example, we might want to separate the user interface from the core business services.

Question 22

Why would a good software system need to be both useful and usable?

Answer 22

If a software system is not useful, it will not meet the users’ needs; if it is not usable, the users will be hindered from performing the tasks they need the software for.

Question 23

If a piece of software contained bugs, how might they affect the usefulness and usability of that software?

Answer 23

If a piece of software contained bugs, it might not meet the users’ needs at all in some respect, or it might meet their needs but in a way that affected usability and made it harder for users to carry out particular tasks.

Question 24

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 those involved:

• are concerned with meeting a clear set of requirements that are defined as clearly as possible;
• use a defined process with clear activities, each of which has at least one identifiable end-product;
• can apply their skills and experience to the tasks demanded of them;
• regard validation and verification to be as essential as building the software itself;
• make sensible use of tools and standards.

Question 25

What is a development process?

Answer 25

A development process is a set of rules that define how a software development project should be carried out. It incorporates a life cycle, and involves a number of methods and procedures.

Question 26

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

Answer 26

Each deliverable uses resources, such as developers’ time, that add to its cost. A good software system must be affordable, and project management is concerned with controlling the cost of developing such systems. So 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

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

Suggest a reason why maintenance is a core activity in the development of a good software system.

Answer 28

We expect a software system to change during its operational lifetime. Maintenance allows a software system to evolve so that it continues to be useful.

Question 29

What must the users and developers do before developing a prototype, in order to avoid any false expectations?

Answer 29

It is important that both users and developers agree on the purpose of a prototype, since both parties need to avoid any misunderstandings that might arise. For example, users may seek to add new features that undermine the existing agreements. Evaluation of the prototype with respect to its agreed purpose will guard against ‘feature creep’.

Question 30

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

Answer 30

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

Question 31

What are the distinguishing characteristics of the waterfall model?

Answer 31

There is an assumption that once a particular activity or phase is finished, it is not re-entered, and, furthermore, 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 32

What is the main function of a prototype?

Answer 32

The main function of a prototype is to facilitate requirements analysis, and reduce the risk of the requirements being identified incorrectly.

Question 33

What are the problems associated with prototyping?

Answer 33

On the one hand, the client wants to use the prototype as the final system to avoid the delays associated with engineering a proper product. On the other hand, the developer forgets that implementation compromises have been built into the prototype, and begins to treat these compromises as an integral part of the software system.

Question 34

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

Answer 34

Through specialisation, a software development company can foster experience in a given area, 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 (hopefully) be able to present solutions in a form that can be understood by those users. In addition, each company may develop and use a consistent development process that is appropriate to each set of customers.

Question 35

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

Answer 35

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 36

What are the additional risks affecting large projects?

Answer 36

The chances of failure increase as the size of a software project increases. Effective communication between the members of a large team becomes more difficult. There are also risks when developers have little or no experience of the problem domain.

Question 37

What is the effect of adding more people to a software development team?

Answer 37

The basic effect is that the number of communication channels between members of the development team will increase. The consequence is that team members will spend more time communicating with each other, rather than doing their allocated tasks, and the chance of introducing errors will be greater.

Question 38

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

Answer 38

The most important additional aspect is the use of the reviewing, determination and evaluation steps that have been specified for a given process. These introduce feedback into the process to help ensure that the deliverables at each stage are leading, in a timely manner, towards the correct product.

Question 39

Why is traceability important to the development of software?

Answer 39

Traceability is concerned with 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 40

How does documentation contribute to traceability within a development project?

Answer 40

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 41

Which activity or activities (shown in Figure 4) are most affected by poor documentation?

Answer 41

All seven activities will be affected by poor documentation. The maintenance and quality management activities will be most affected, since 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 42

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

Answer 42

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

Question 43

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

Answer 43

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.

Question 44

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

Answer 44

Here is our list of problems that affect software development (you may have identified others):

• difficulty in capturing all the user requirements;
• difficulties in managing and developing large and complex systems;
• difficulties in meeting users’ requirements and avoiding dissatisfaction with the completed software;
• continual changes in user requirements (often referred to as ‘requirements creep’);
• difficulties in maintaining software;
• the presence of errors introduced during development;
• a changing world leading to changes in the needs of the users and decreasing the usefulness of the software;
• apparent low productivity of those developing software, and difficulties in measuring that productivity;
• maintaining momentum and avoiding getting ‘stuck’, especially when the development process hides the goal of delivering a good software system;
• ensuring the quality of a software system.

Question 45

How do you think a large-scale project differs from a small-scale project in terms of the management of the development team?

Answer 45

As the size of a project increases, so does the number of people involved, and consequently the complexity of the interactions involved. For example, in a two person project there is only one pairwise path of communication; with three people there are three pairwise paths; with four there are six pairwise paths; and so on. As with programs, the greater the complexity of interaction, the greater the chance of errors occurring.

Question 46

As the size of a project increases, so does the number of people involved, and consequently the complexity of the interactions involved.

What steps might be taken to tackle the problems that arise?

Answer 46

One of the functions of software project management is to reduce this complexity. One way to achieve this aim is to modularise project teams by splitting them up into a number of groups. Each group performs a specific task and communicates with the other groups through one person (for example, the head of the group).

Question 47

Life-cycle models sometimes show only the software-creation activities and exclude software maintenance. What problems are associated with the use of such models?

Answer 47

If maintenance is not mentioned, it is likely that it will not be considered to be an integral part of the overall software life cycle. This may result in a design that does not take the needs of maintenance into account, and hence a product that is difficult and expensive to change. This is especially likely if time and/or budget are already tight.

Question 48

What kinds of software system would be best suited to the incremental model?

Answer 48

Software systems where the problem falls naturally into partitions, each of which represents a fairly self-contained unit that could be developed and delivered on its own to provide the users with a useful chunk of functionality, would be well suited to this model. The incremental approach allows several design issues to be tackled simultaneously and enables the system to be implemented in relatively small steps in order to contain the complexity. Of course, this assumes that the design can be partitioned.

Question 49

Figure 7 shows a spiral process for software development. Into which quadrant of that figure does each of the seven technical activities fit?

Analysis, design, implementation, testing, maintinence, project management and quality management.

Answer 49

The analysis, design, implementation and testing activities all fit into the ‘develop and verify a (partial) solution or product’ segment.

The analysis activity also overlaps the evaluation quadrant where objectives and risks are analysed. The testing activity overlaps the ‘review and plan’ quadrant.

The maintenance, project management and quality management activities (including configuration management) operate in all four quadrants.

Question 50

It has been said that ‘the maintenance activity begins with the first deliverable of a development project’. What does this imply about the maintenance activity?

Answer 50

This question refers to the fact that there could be deliverables, such as requirements documents, that exist prior to any software being built.

The maintenance activity allows a software system to evolve. It is the activity that responds to changes.

For example, you might detect errors or inconsistencies in a document that lists the important terms in your users’ domain; or you might have to respond to changes in the environment, which may be due to new regulations or market forces.

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:

1 those that determine whether or not a diagram is legal – the syntax of a diagram;

2 those that define what a legal diagram means – the semantics of a diagram.

Question 54

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

Answer 54

No, although a particular development process is likely to define its own modelling notation.

Question 55

What are the required characteristics of a standard modelling language?

Answer 55

When choosing a modelling language, it should be:

• sufficiently expressive;
• easy enough to use;
• unambiguous;
• widely used;
• supported by suitable tools.

Question 56

How does a standard modelling language contribute to software development?

Answer 56

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 57

Should we try to capture everything about a design in a single diagram?

Answer 57

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

Question 58

What is the difference between a static and a dynamic model?

Answer 58

A static model describes the elements of the system and their relationships to other elements.

A dynamic model describes the behaviour of a system over a period of time.

Question 59

The diagrams within a single model must be consistent. Does the same apply to all the models used in a given development project?

Answer 59

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 60

Suppose you and a colleague used UML on a particular development project. What would be the consequences of introducing symbols or notations that were not defined in UML?

Answer 60

Such an extension would incur costs as well as offering potential benefits. The costs include the need to communicate the syntax and semantics of your new symbols or notation to other developers.

Question 61

In the past, there have been many attempts to standardise modelling notations and languages. How might the choice of modelling language affect the maintenance of a software system?

Answer 61

Every time a new standard is defined, it allows new software systems to be built using that standard. It can only help with existing software retrospectively.

For example, a developer might use the new standard to express a proposed change to the software. There is no guarantee that an existing software system used any modelling language at all, let alone any agreed standard for one. Even if a standard was used, new staff arriving on the team for the purpose of maintenance might not know about it. Each variety of standard would affect the organisation of a component library.

For example, if components using a particular standard were to be put in a library, the descriptions would be likely to require some maintenance as that standard changes over time.

Question 62

What is the purpose of domain modelling?

Answer 62

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

Question 63

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

Answer 63

During domain modelling, we produce the following artefacts.

Dynamic model: a description of the business processes and behaviour of the domain.

Business rules: constraints on the way the above model operates.

Glossary: definitions of relevant terms.

Structural domain model: an initial structural model representing the concepts relevant to the domain.

Question 64

What is the purpose of requirements engineering?

Answer 64

Requirements engineering is concerned with establishing what a software system must do.

Question 65

What is the purpose of design?

Answer 65

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

Question 66

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

Answer 66

During design we produce the following artefacts:

Structural model: This is an updated version of the one produced during domain modelling but with its operations specified.

Behavioural models: These show how objects in the system will interact and behave internally, and also how functionality will be distributed across the system.

Question 67

When is the earliest point that you might need to produce a deployment model in a development project?

Answer 67

The users of a software system may be dispersed throughout the organisation, and you should expect that their requirements would reflect this. Your conceptual model should avoid this aspect of the requirements, but some consideration of the users’ diverse locations would be expected. Thus you should expect to produce some form of deployment model very early in the project, as a separate design activity, after the separation of the logical and physical requirements during analysis. What is in the model will depend on the nature of the requirements. For example, you might be asked to develop software to suit an existing hardware configuration, which is a physical constraint.

Question 68

Which factors may contribute to the successful adoption of CASE tools within an organisation?

Answer 68

Across the organisation, there should be established methods and procedures that can be supported by the tools. Adequate investment should be put into training managers and developers. Deployment should occur over a long period of time, as the benefits of CASE tools are not short term. Clear procedures should be established for the use of different tools within development, and standards should be followed for information exchange among tools. To overcome some of the deficiencies of current tools, they should be integrated within practices that support project management and customer–developer communication.