Unit 1 - Approaches to Software Development

Question 1

Define a system

Answer 1

an assembly of components that are connected together in an organised way

Question 2

A software system is built to meet requirements. What must a successful software project do?

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.

Question 3

What is the system boundary?

Answer 3

The system boundary is simply a conceptual line that divides the system that we wish to study from ‘everything else’. It is useful to think of a system’s environment as being made up of those things which are not part of the system, but which can either affect the system or be affected by it.

Question 4

Hospitals are a domain where you can find software being put to a variety of uses. A hospital might, for example, join together a series of patient-monitoring systems along with the database management system that manages medical records, to make a larger system with a different scope. A forward-looking hospital might also wish to go further and add weather-forecasting software. The extension would allow planners to deal with the ebb and flow of patients that arise according to the season. Beds may be allocated, and other resources, such as drugs, can be bought in preparation.

In the above, 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 4

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 5

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

Answer 5

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.

Question 6

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

Answer 6

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 7

(a) What is the defining quality of a good software system, and what are its main characteristics?
(b) How might greater flexibility make a software system more affordable?
(c) Give two reasons why a delivered software system might not meet its users’ needs.

Answer 7

(a) 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.
(b) 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.
(c) Software systems are usually out of date even as they are being developed, since users’ needs:
- are often missed during requirements capture;
- change with time.

Question 8

Legacy systems often have what characteristics?

Answer 8

are large;
are critical to the business;
have been changed a number of times since their inception;
are 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;
are difficult to maintain because of the above factors.

Question 9

(a) Suggest a means of measuring the maintainability of a software system.
(b) How does a legacy system relate to the attributes of a good software system?
(c) Suggest a reason why legacy systems will always be a problem.

Answer 9

(a) 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); and the effort needed to adapt the software system to meet its users’ needs.
(b) 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.
(c) 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 10

What is the main technique to simplify the construction of a complex software solution?

Answer 10

The main technique for dealing with such messy situations is decomposition. We can decompose a problem into smaller and smaller parts or chunks until each one can be comprehended or dealt with by an individual.

Question 11

What are modules?

Answer 11

internal boundaries and smaller subsystems identified within the system,

Question 12

What is heroic programming?

Answer 12

An individual attempting to develop a complex system.

Question 13

What are projections and partitions?

Answer 13

A projection overlaps (there are elements that are found in more than one projection).
A partition is an independent sub-problem.

Question 14

What is coupling?

Answer 14

In software engineering, the term coupling is used to refer to the degree of interdependence among the different components of a system.

Question 15

What is circular dependency?

Answer 15

Where chains of independent modules join up in a particularly strong (or high) form of coupling.

Question 16

Two classes need to be coupled in order to communicate. What factors indicate coupling?

Answer 16

A inherits from B
A has an attribute of class B
A has a method that uses an instance of class B as an input or output argument
A knows of a public attribute of class B

Question 17

What is an interface to a module?

Answer 17

In general, we say that the 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. An interface encapsulates what we know about the class.

Question 18

When a module provides services to other modules and in turn uses services from other modules, what is this called?

Answer 18

These required services are called its context dependencies.

Question 19

What is cohesion?

Answer 19

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

Question 20

What is abstraction?

Answer 20

Abstraction is a particular way of viewing a complex problem. The idea is to group together similar objects or situations and, while ignoring the differences, focus on one particular aspect of the problem.

Question 21

(a) Why might you consider splitting up a large project into smaller chunks?
(b) How does the complexity of a software system affect the maintenance task?
(c) What is a module?
(d) Why does it help to have low coupling in a software system?
(e) Give examples of the kinds of information that would be valuable when considering a change to a given module.
(f) What are the context dependencies of a module? How do they relate to a module’s interface?
(g) What are the benefits of using modules with defined interfaces?
(h) Why does it help to have high cohesion in the modules of a software system?
(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?
(j) Why is it important to achieve a balance between coupling and cohesion?

Answer 21

(a) 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.
(b) 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.
(c) 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.
(d) 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.)
(e) 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.
(f) 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.
(g) 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.
(h) 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.
(i) A module should have low coupling and high cohesion, a good abstraction, and a well defined interface that is an encapsulated abstraction of a well understood concept.
(j) 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 22

(a) What are the characteristics of a component?
(b) How does the concept of an architecture contribute to component reuse?
(c) Which form of decomposition might be used in a software architecture?

Answer 22

(a) 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.
(b) 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.)
(c) Complexity is best managed by decomposing a problem into smaller sub problems. 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 23

(a) Why would a good software system need to be both useful and usable?
(b) If a piece of software contained bugs, how might they affect the usefulness and usability of that software?

Answer 23

(a) 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.
(b) 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 are the typical technical activities for the development of software>

Answer 25

- Analysis. As you saw with the definition of a system, you need to be able to include all that you consider to be relevant. This includes requirements elicitation, where you identify the problem and then produce a (clear) statement of the problem, and requirements specification, where you decide what needs to be done to solve the problem. - Design. You determine how you will solve the problem. - Implementation. You act upon the decisions made at the design stage. - Testing. You apply what you have done so that you can determine whether or not you have solved the problem. - Maintenance

Question 26

What is the waterfall method?

Answer 26

If you arrange the five activities of analysis, design, implementation, testing, and maintenance into a single sequence, then you have the classic waterfall model for the development of software.

Question 27

(a) What is a development process? (b) What is the role of project management with respect to the deliverables of a development project? (c) What is the difference between a customer and a user? (d) Suggest a reason why maintenance is a core activity in the development of a good software system. (e) What must the users and developers do before developing a prototype, in order to avoid any false expectations? (f) What additional task is needed when the development of a software system is partitioned into a number of increments? (g) What are the distinguishing characteristics of the waterfall model? (h) What is the main function of a prototype? (i) What are the problems associated with prototyping?

Answer 27

(a) 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. (b) 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. (c) 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. (d) 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. (e) 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’. (f) A task devoted to the integration of the increments to form the final software system will be needed. (g) 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. (h) The main function of a prototype is to facilitate requirements analysis, and reduce the risk of the requirements being identified incorrectly. (i) 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 28

(a) Why might a software development company specialise in a certain kind of customer, such as those in banking or health care? (b) In which of the activities in Figure 4 would you expect to do your configuration management during a project? (c) What are the additional risks affecting large projects? (d) What is the effect of adding more people to a software development team? (e) What important aspect is added to a development process with the introduction of risk management?

Answer 28

(a) 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. (b) 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. (c) 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. (d) 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. (e) 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 29

(a) Why is traceability important to the development of software? (b) How does documentation contribute to traceability within a development project? (c) Which activity or activities (shown in Figure 4) are most affected by poor documentation? (d) For what kind of software system might you minimise or even avoid any documentation? (e) Why is it important to review the contents of your project notebook?

Answer 29

(a) 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. (b) 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. (c) 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.) (d) 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. (e) 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 30

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

Answer 30

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 31

(a) How do you think a large-scale project differs from a small-scale project in terms of the management of the development team? (b) What steps might be taken to tackle the problems that arise?

Answer 31

(a) 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. (b) 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 32

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 32

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 33

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

Answer 33

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 34

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

Answer 34

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 35

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 35

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 36

(a) What is a model? (b) What is a ‘good model’? (c) What are the two kinds of rule that govern the use of a modelling language? (d) Does a modelling language need to be associated with a particular development process? (e) What are the required characteristics of a standard modelling language? (f) How does a standard modelling language contribute to software development?

Answer 36

(a) 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. (b) 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. (c) 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. (d) No, although a particular development process is likely to define its own modelling notation. (e) When choosing a modelling language, it should be: - sufficiently expressive; - easy enough to use; - unambiguous; - widely used; - supported by suitable tools. (f) 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 37

(a) Should we try to capture everything about a design in a single diagram? (b) What is the difference between a static and a dynamic model? (c) The diagrams within a single model must be consistent. Does the same apply to all the models used in a given development project?

Answer 37

(a) 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. (b) 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. (c) 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 38

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 38

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 39

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 39

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 40

(a) What is the purpose of domain modelling? | (b) What is the role of each of the artefacts produced during domain modelling?

Answer 40

(a) Domain modelling is concerned with gaining an understanding of the environment in which any system that is designed must operate. (b) 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 41

What is the purpose of requirements engineering?

Answer 41

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

Question 42

(a) What is the purpose of design? | (b) What is the role of each of the artefacts produced during design?

Answer 42

(a) Design is concerned with making decisions concerning how a system will meet its specification. (b) 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 43

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

Answer 43

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 44

What does CASE stand for?

Answer 44

Computer-aided software engineering (CASE) tools were created to support the professional software engineer in the complex task of developing large information systems, and to improve their productivity.

Question 45

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

Answer 45

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.