The purpose of the Inception Phase

The Inception Phase is that part of the development lifecycle in which you will decide to embark on the development project. This is the time in which you will make a large number of crucial decisions regarding the need for and nature of the proposed system. The questions that must be asked in this phase will depend on particular circumstances, but may include the following:

• Why is the system needed?

• Are there better alternatives?

• Will the system be acceptable to its users?

• At what price will the system be marketed?

• Is there a market for the system?

• What are the legal implications of the system?

• What are the Trade Union implications of the system?

• What is the intended lifetime of the system?

• How reliable should the system be?

• Can management approval be obtained for system development?

• Will sufficient resources be available for system development?

• Will sufficient resources be available to run the system?

• Will the system be developed ‘in-house’ or will its development be put out to tender?

• How will tenderers' responses be assessed?

Although this phase is not directly involved with software development, it is vitally important that you ask the correct questions and obtain the correct answers to lead to a firm system requirement. These answers will affect all subsequent phases and ultimately the usefulness of the entire project.

The purpose of Project Debriefing

Now that the development project is over and your system is installed it is time to make sure that future projects will benefit from what you have achieved and learnt. This is the purpose of Project Debriefing; to record your experiences in carrying out the project in a way that will be of benefit to other projects and which will add to your organisation's collective database of project statistics.

The way in which the results of Project Debriefing can most help your organisation is in planning future projects. Such planning may be at the start of a new project or as part of a tendering activity. In either case the collected experiences of previous projects are of inestimable value in producing accurate project plans. For this reason, Project Debriefing should be strongly related to the topics of estimation and indicators discussed in chapter 2.

If you have been recording indicators throughout the project it will require little effort to organise, summarise and record these indicators as part of Project Debriefing. Of special importance will be indicators related to attributes used in arriving at the project plan (those of type (ii) on page 19). These indicator values can be used in updating the calibration of your cost estimation model or in pin-pointing weaknesses in the model. Weaknesses in the model or its use may show up in the form of input parameters to the model whose estimated values consistently bear no resemblance to their final values.

The aims of the System Definition Phase

Once the decision has been made to proceed, this is the most important phase of development. Decisions made here influence the rest of the project. Time spent here is rarely less than well-spent, if properly directed. On the other side of the coin, this is one of the most difficult stages as regards knowing where you start, knowing when you have finished and knowing how to go about it.

The purpose is clear however, namely to decide the following:

• What is to be produced,

• When it is to be produced by,

• What resources will be required to produce it.

These latter two may already have been determined for you. If so, you must regard them as constraints that limit what can be produced. In other words you will need to decide additionally that the system can actually be produced in the time with the resources.

Every project manager at this stage of his project needs to be reminded that there is a strong empirical correlation between failure to define a system adequately and failure to produce it. The temptation to short-circuit the Definition Phase is all the easier to succumb to, given the momentary feeling of an increased rate of progress.

The starting point of System Definition

It is most likely that you will start with some form of Requirement Specification.

The purpose of the System Design Phase

Introduction

Although your main concern in the System Definition Phase will have been to decide what functions the system is to perform, you will also have given some thought as to how it is to perform them. During the System Design Phase you continue this process by deciding upon and documenting the overall strategy by which the system will perform the required functions. This involves mapping the system functions onto elements of software (and hardware) which can in the next phase be designed in detail and implemented.

The means by which this mapping is carried out can vary enormously, as can the designs resulting from different design approaches. The principal aim of the System Design Phase should, however, be the same no matter what design method is used; namely, to produce a system design which

• is easily implemented,

and which, when implemented,

• will provide all required functions,

• will operate within any required constraints,

• will be easily maintained.

Let us consider the implications of each of these goals for any potential system design methodology.

Ease of implementation

The process by which the system design will be implemented involves the following basic ingredients:

• the system design (in the form of design documents),

• the implementers (i.e. programmers etc.),

• the virtual machine (i.e. the hardware and supporting systems software).

With the accelerating pace of work being done in the field of software engineering, it is becoming increasingly difficult to see the range of available techniques against a common background. Individual techniques are accessible throughout the literature but generally each is described in isolation. Comparison is difficult unless one has a strong idea of what one is looking for.

Our purpose in writing this book has therefore been to bring together, within a single framework, a variety of methods from all stages of software development and, in this way, to assist software engineers in particular in finding and evaluating the techniques appropriate to their own working environments. This should be regarded principally therefore as a book of signposts, leading the reader out into the field with a map, a compass and some reference points. By combining pointers to a selection of modern development practices with practical hints and checklists, all within one framework, we hope to fill the need for a vade-mecum to the software developer.

Managers with responsibility for software production will also, we hope, find much to stimulate their ideas about what modern practices have to offer and how their departments' efficiency and effectiveness could benefit. Students of computing science will be able to complement their more theoretical work by seeing the software development process as a day-to-day activity, a process that has managerial and sociological as much as purely technical aspects.

The transformation of your client's ideas about his proposed system into the physical, delivered system is a long one. If this transformation is to be at all manageable, it needs to be tackled as a sequence of stages, each bringing you closer to your destination.

The simplest model of the software development process is a purely sequential one with each succeeding stage following on in serial fashion from the previous one. Such a model could serve for a small one-man project but a better approximation to reality is contained in the so-called ‘cascade’ or ‘waterfall’ model suggested in figure 2.1. This recognises that it is generally necessary – even desirable – for the stages to overlap and even repeat.

It is normally customary at this point to talk of the software development ‘lifecycle’ and to draw a diagram along the lines of figure 2.2. This custom is based on the premise that the original development of a system from scratch has the same underlying sequence of events as the enhancement or correction of a system: inception, definition, design, implementation and acceptance. Superficially this is true but the similarity is slight and the generalisation at times unhelpful.

In this book we prefer to talk about the ‘development path’ and ‘maintenance cycles’ and to draw the ‘b-diagram’ along the lines of figure 2.3. This reflects reality more closely. The development path, starting from nothing more than a desire for a system, stands alone.

Given the task of developing a software system, how does one go about it? To start the building of a system of a thousand or maybe a million delivered lines of source code is a daunting (if exciting) prospect. No one should begin without a very clear idea about how the development is to be undertaken and how the quality of its output is to be assessed.

Turning this around we can say that anyone undertaking software development, on no matter what scale, must be strongly advised to establish a methodology for that development – one or more techniques that, by careful integration and control, will bring order and direction to the production process.

To paraphrase Freeman 1982: every software development organisation already has some methodology for building software systems. However, while some software is developed according to modern practices of software development, most of it is still built in an ad hoc way. So it is best to talk about software development techniques and methodologies in terms of changing current practices, replacing them with new techniques that improve the process of software development and the quality of the resulting products.

There is of course a dilemma here for us as system developers: technique X may offer us potential gains such as reduced development time, reduced costs, increased reliability, quality etc, but in adopting it we also incur the risks arising from the fact that we may be unfamiliar with technique X, it might not be suitable for the system we have to develop, and it might not suit our staff and their skills.

In this research, I have shown how principles of discourse structure, discourse coherency, and relevancy criterion can be used for the task of generating natural language text. Each of these areas is particularly important since the generation of text and not simply the generation of single sentences was studied. In this section, the principles and their incorporation as part of the text generation method are reviewed. Some limitations of the generation method are then discussed and finally, some possibilities for future research are presented.

Discourse structure

A central thesis of this research is based on the observation that descriptions of the same information may vary from one telling to the next. This indicates that information need not be described in the same way in which it is stored. For the generation process, this means that production of text does not simply trace the knowledge representation. Instead, standard principles for communication are used to organize a text. These rhetorical techniques are used to guide the generation process in the TEXT system. Since different rhetorical techniques are associated with different discourse purposes, it was shown that different descriptions of the same information can be produced depending upon the discourse situation. By incorporating commonly used techniques for communication into its answers, the system is able to convey information more effectively.

Relevancy criterion

It was pointed out that, when speaking, people are able to ignore large bodies of knowledge and focus on information that is relevant to the current discourse purpose. By constraining focus of attention to relevant information, a generation system is able to determine more efficiently what should be said next.

Focusing is a prevalent phenomenon in all types of naturally occurring discourse. Everyone, consciously or unconsciously, centers their attention on various concepts or objects throughout the process of reading, writing, speaking, or listening. In all these modalities, the focusing phenomena occur at many levels of discourse. For example, we expect a book to concern itself with a single theme or subject; chapters are given headings, indicating that the material included within is related to the given heading; paragraphs are organized around topics; and sentences are related in some way to preceding and succeeding sentences. In conversation, comments such as “Stick to the subject …”, “Going back to what you were saying before ‥”, or “Let's change the subject …” all indicate that people are aware that the conversation centers on specific ideas and that there are conventions for changing the focus of attention.

The use of focusing makes for ease of processing on the part of participants in a conversation. When interpreting utterances, knowledge that the discourse is about a particular topic eliminates certain possible interpretations from consideration. Grosz (77) discusses this in light of the interpretation of definite referring expressions. She notes that although a word may have multiple meanings, its use in an appropriate context will rarely bring to mind any meaning but the relevant one. Focusing also facilitates the interpretation of anaphoric, and in particular, pronominal, references (see Sidner 79). When the coherence provided by focusing is missing from discourse, readers and hearers may have difficulty in determining what a pronoun refers to. When speaking or writing, the process of focusing constrains the set of possibilities for what to say next.

There are two major aspects of computer-based text generation: 1) determining the content and textual shape of what is to be said; and 2) transforming that message into natural language. Emphasis in this research has been on a computational solution to the questions of what to say and how to organize it effectively. A generation method was developed and implemented in a system called TEXT that uses principles of discourse structure, discourse coherency, and relevancy criterion. In this book, the theoretical basis of the generation method and the use of the theory within the computer system TEXT are described.

The main theoretical results have been on the effect of discourse structure and focus constraints on the generation process. A computational treatment of rhetorical devices has been developed which is used to guide the generation process. Previous work on focus of attention has been extended for the task of generation to provide constraints on what to say next. The use of these two interacting mechanisms constitutes a departure from earlier generation systems. The approach taken here is that the generation process should not simply trace the knowledge representation to produce text. Instead, communicative strategies people are familiar with are used to effectively convey information. This means that the same information may be described in different ways on different occasions.

The main features of the generation method developed for the TEXT strategic component include 1) selection of relevant information for the answer, 2) the pairing of rhetorical techniques for communication (such as analogy) with discourse purposes (for example, providing definitions) and 3) a focusing mechanism.

A portion of an Office of Naval Research (ONR) database was used to test the TEXT system. The portion used contains information about military vehicles and weapons. The ONR database was selected for TEXT in part because of its availability (it had been in use previously in a research project jointly with the Wharton School of the University of Pennsylvania) and in part because of its complex structure. Even using only a portion of the database provided a domain complex enough to allow for an interesting set of questions and answers.

As discussed in Chapter One, TEXT accepts three kinds of questions as input. These are:

• What is a <e>?

• What do you know about <e>?

• What is the difference between <e1> and <e2>?

where <e>, <e1>, and <e2> represent any entity in the database. Since the TEXT system does not include a facility for interpreting English questions, the user must phrase his questions in the functional notation shown below which corresponds to the three classes of questions.

• (definition <e>))

• (information <e>)

• (differense <e1> <e2>)27

Note that the system only handles questions about objects in the database. Although the system can include information about relations when relevant to a question about a particular object, it can not answer questions about relations themselves.

System components

The TEXT system consists of six major components: a schema selector, a relevant knowledge selector, the schema filler, the focusing mechanism, a dictionary interface, and a tactical component.

The approach I have taken towards text generation is based on two fundamental hypotheses about the production of text: 1) that how information is stored in memory and how a person describes that information need not be the same and 2) that people have preconceived notions about the ways in which descriptions can be achieved.

I assume that information is not described in exactly the same way it is organized in memory. Rather, such descriptions reflect one or more principles of text organization. It is not uncommon for a person to repeat himself and talk about the same thing on different occasions. Rarely, however, will he repeat himself exactly. He may describe aspects of the subject which he omitted on first telling or he may, on the other hand, describe things from a different perspective, giving the text a new emphasis. Chafe (79) has performed a series of experiments which he claims support the notion that the speaker decides as he is talking what material should go into a sentence. These experiments show that the distribution of semantic constituents among sentences often varies significantly from one version of a narrative to another.

The second hypothesis central to this research is that people have preconceived ideas about the means with which particular communicative tasks can be achieved as well as the ways in which these means can be integrated to form a text. In other words, people generally follow standard patterns of discourse structure. For example, they commonly begin a narrative by describing the setting (the scene, the characters, or the time-frame).