Abstracts

Page maintained by Norman Fenton. Last updated: 13 July 2000

Abstracts should appear on the front page of a report. There are two types of abstracts: descriptive and informative. A descriptive abstract says what is in the report without providing any of the results. An informative abstract says what the report contains, including summarising the main results. You should always write informative abstracts. Compare the following two abstracts describing the same case study:

Version A (descriptive)

This report describes a major case study to evaluate the effectiveness of using a certain formal method during software development. <general blurb about formal methods removed> We describe the background of the particular method used and discuss the claims made in favour of these methods. We describe the experimental set-up and the particular software under investigation. We present a range of results indicating the circumstances under which formal methods may be effective. We explain the measurements that were used, along with the rationale for using them. We compare the results of the measurements at different life-cycle phases. We consider the different uses of the system. Finally, we present a number of strong recommendations.

Version B (informative)

VDM is one of the best known formal methods used in software development. We describe a case study to evaluate whether higher quality code results from the use of VDM. The case study involved an air traffic control system developed over three years. Some of the modules in the system were developed using VDM (160 modules making approximately 400 KLOC) while the rest of the modules (300 making approximately 700 KLOC) were developed informally. We found that, prior to release, the fault density of formally developed modules was not significantly different to the informally developed modules (4 faults per KLOC being typical). However, the fault density in the 6 months post-release was significantly lower for formally developed modules (on average 0.6 faults per KLOC compared to 1.4 faults per KLOC). We also found that more faults were found during the early development phases in the formally developed modules. This favourable evidence to support formal methods is countered by the following observations: i) the formally developed modules generally took 25% longer to complete than similar sized informal modules. ii) the formally developed modules were those concerned with the critical functions and were developed by more experienced and better qualified staff with a strong mathematical background; iii). the non-formally developed modules included all of the interface code so faults discovered in the first 6 months post-release were inevitably more likely to be in this part of the system. Despite these reservations we believe that the post release fault-density for the formally developed modules was very low. We therefore recommend that companies should consider using formal methods such as VDM for the most critical components, providing that they have well trained staff with a very good mathematical background.

Obviously Version A is shorter, but only because the general blurb about formal methods has been removed. Version A actually tells the reader nothing about the case study. This writer is challenging the reader to read through the entire report in order to find out the basic results. Version B, on the other hand tells us all the key information about the case study without including anything superfluous. Version B does not tell us that the paper contains a discussion about formal methods - it does not need to since we know that a paper investigating formal methods must contain some such discussion. Version B is better in every respect. Even if we do not have time to read the paper (and most readers never get further than the abstract) it tells us what we really need to know. It even makes us more likely to read the paper because it will identify and target key readers.

Since informative abstracts are so obviously superior to descriptive ones why do the majority of scientific writers still insist on providing descriptive abstracts that infuriate us and insult our intelligence? The answer is simple: laziness (although in some cases it may be due to the fact that the author really has nothing to say!). Descriptive abstracts are often written before the work has even been carried. In other words the abstract is merely a plan for the author. Now plans are fine and necessary in order to complete a piece of work. But if you were delivering any product you would not use your original project plan as a replacement for the product description. So never use a descriptive abstract.

Return to top of page

Return to Good Writing Guide index

Return To Norman Fenton's home page