Unit 1 - Approaches to software development

Question 0

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

Answer 0

• Malleability
  Software is easy to change (programmers are often tempted to tweak their code). 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. 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 in a small one.

[Unit 1, p. 10]

Question 1

A successful software project must…?

Answer 1

… 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

… demonstrate good overall system quality.

… be resilient to the changes that will be introduced during its operational lifetime

[Unit 1, p. 5]

Question 2

For each of the three characteristics of software mentioned above [Malleability, Complexity and Size], 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.

[Unit 1, SAQ 2, p 10]

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

[Unit 1, SAQ 3a, p. 11-12]

Question 4

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.

[Unit 1, SAQ 3b, p. 11-12]

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 because:

• some needs are often missed during requirements capture.
• users’ needs change with time.

[Unit 1, SAQ 3c, p. 11-12]

Question 6

What greatly influences the maintainability of software?

Answer 6

The maintainability of software is greatly influenced by how software is designed, written and documented.

[Unit 1, p. 12]

Question 8

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

Answer 8

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.

[Unit 1, SAQ 4a, p. 14]

Question 9

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

Answer 9

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.

[Unit 1, SAQ4b, p. 14]

Question 10

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

Answer 10

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.

[Unit 1, SAQ 4c, p. 14]

Question 11

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

Answer 11

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.

[Unit 1, SAQ 5a, p. 20]

Question 12

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

Answer 12

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.

[Unit 1, SAQ 5b, p. 20]

Question 13

What is a module?

Answer 13

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.

[Unit 1, SAQ 5c, p. 20]

Question 14

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

Answer 14

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

[Unit 1, SAQ 5d, p. 20]

Question 15

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

Answer 15

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.

[Unit 1, SAQ 5e, p. 20]

Question 16

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

Answer 16

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.

[Unit 1, SAQ 5f, p. 20]

Question 17

What are the benefits of using modules with defined interfaces?

Answer 17

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

[Unit 1, SAQ 5g, p. 20]

Question 18

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

Answer 18

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.

[Unit 1, SAQ 5h, p. 20]

Question 19

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 19

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.

[Unit 1, SAQ 5i, p. 20]

Question 20

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

Answer 20

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.

[Unit 1, SAQ 5j, p. 20]

Question 21

In the context of TM354, what is the definition of “software architecture”?

Answer 21

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.

[Unit 1, p. 22]

Question 22

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

Answer 22

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.

[Unit 1, p. 22]

Question 23

What are the characteristics of a component?

Answer 23

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.

[Unit 1, SAQ 7a, p. 25]

Question 24

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

Answer 24

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.

[Unit 1, SAQ 7b, p. 25]

Question 25

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

Answer 25

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.

[Unit 1, SAQ 7c, p. 25]

Question 26

What are the similarities and differences between components and services?

Answer 26

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. [A component is technology dependent, a service is technology neutral. Unit 1, p. 24]

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.

[Unit 1, SAQ 7d, p. 25]

Question 27

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

Answer 27

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.

[Unit 1, SAQ 8, p. 29]

Question 28

What are the 5 typical technical activities for the development of software?

Answer 28

Domain modelling 
Requirements engineering [gathering]
Design
Implementation 
Testing 

[Unit 1, p. 29]

Question 29

What is a development process?

Answer 29

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.

Unit 1, SAQ 9a, p. 33

Question 30

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

Answer 30

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.

Unit 1, SAQ 9b, p. 33

Question 31

What is the difference between a customer and a user?

Answer 31

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.

Unit 1, SAQ 9c, p. 33

Question 32

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

Answer 32

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

Unit 1, SAQ 9d, p. 33

Question 33

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

Answer 33

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

Unit 1, SAQ 9e, p. 33

Question 34

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

Answer 34

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.

Unit 1, SAQ 9f, p. 33

Question 35

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

Answer 35

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.

Unit 1, SAQ 10a, p. 41

Question 36

In which of the activities in Figure 5 [Project management, quality management, maintenance, analysis, design, implementation, testing] would you expect to do your configuration management during a project?

Answer 36

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.

Unit 1, SAQ 10b, p. 41

Question 37

Why are there additional risks when developing large projects?

Answer 37

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.

Unit 1, SAQ 10c, p. 41

Question 38

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

Answer 38

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.

Unit 1, SAQ 10d, p. 41

Question 39

Why is traceability important to the development of software?

Answer 39

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.

Unit 1, SAQ 11a, p. 43

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.

Unit 1, SAQ 11b, p. 43

Question 41

(c) Which activity or activities in the development process in Figure 5 [Project management, quality management, maintenance, analysis, design, implementation, testing] 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 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.)

Unit 1, SAQ 11c, p. 43

Question 42

(d) 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 short lifetime and will be discarded after use, it may be acceptable to minimise or avoid the task of documentation.

Unit 1, SAQ 11d, p. 43

Question 43

(e) How would you characterise agile documentation?

Answer 43

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.

Unit 1, SAQ 11e, p. 43

Question 44

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

Answer 44

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.

Unit 1, SAQ 11f, p. 43

Question 45

What are the main problems associated with the development of software? You should be able to identify at least six.

Answer 45

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

Unit 1, Exercise 1, p. 44

Question 46

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

Answer 46

As the size of a project increases, so does the number of people involved, and consequently the complexity of the interactions involved, and the difficulty of managing the team. As with programs, the greater the complexity of interaction, the greater the chance of errors occurring due to poor communication.

Unit 1, Exercise 2a, p. 45

Question 47

What management steps might be taken to tackle the problems that arise in a large-scale project?

Answer 47

One of the functions of software project management is to manage project 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). Another way, encouraged by an agile approach to development, is to encourage practices of communication and cooperation in development, such as working in pairs and having daily short meetings.

Unit 1, Exercise 2b, p. 45

Question 48

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

Answer 48

If maintenance is not mentioned, it is likely that it will not be considered to be an integral part of the overall software process model. 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.

Unit 1, Exercise 3, p. 45

Question 49

What kinds of software system would be best suited to an iterative and incremental development process?

Answer 49

Software systems where the problem can grow incrementally or where it 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. An iterative and 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.

Unit 1, Exercise 4, p. 45

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 refers to the fact that there could be deliverables, such as requirements documents, that exist prior to any software being built, and these also require maintenance. 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.

Unit 1, Exercise 6, p. 45

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.

SAQ 12

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.

SAQ 12

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.

SAQ 12

Question 54

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

Answer 54

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.

SAQ 12

Question 55

What are the required characteristics of a standard modelling
language?

Answer 55

• sufficiently expressive
• easy to learn and use
• unambiguous
• widely used
• supported by suitable tools.

SAQ 12

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.

SAQ 12

Question 57

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

Answer 57

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.

SAQ 13

Question 58

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

Answer 58

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.

SAQ 13

Question 59

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

consistent?

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.

SAQ 13

Question 60

What does the UP (Unified Process) promote?

Answer 60

• Timeboxing
• iterative development
• dealing with high-risk issues in early iterations
• prioritising the user’s perspective by involving users in requirements, evaluation and feedback
• building a view of the system’s architecture in early iterations.

p. 53

Question 61

Name the 4 UP phases

Answer 61

• Inception (business case, scoping)
• Elaboration (requirements, core development)
• Construction (final construction)
• Transition (beta-testing, deployment)

p. 54

Question 62

What are the 5 views addressed by the UP (Unified Process)?

Answer 62

• The use case view
• The logical view
• The implementation view
• The deployment view
• The process view

p.55

Question 63

What is the purpose of domain modelling?

Answer 63

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

SAQ 14

Question 64

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

Answer 64

1. Initial problem Statement - a description of the problem
2. Behaviour Model – a description of the business processes
   and behaviour of the domain
3. Business Rules – constraints on the way the behaviour model operates
4. Glossary – definitions of relevant terms
5. Structural Domain Model – an initial structural model
   representing the concepts relevant to the domain

Question 65

What is the purpose of the requirements phase?

Answer 65

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

Question 66

What is the purpose of analysis?

Answer 66

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

Question 67

What is the purpose of design?

Answer 67

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

Question 68

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

Answer 68

During design you produce the following artefacts:

1. Structural Model - an updated version of the one produced during analysis but with its operations specified.
2. Behavioural Models - showing how objects in the system will interact and behave internally, and also how functionality will be distributed across the system.