Analysis Within the Systems Development Life-Cycle. Book 2: Data Analysis–the Methods

283 Pages·1987·15.227 MB·English

by  Rosemary Rock-Evans (Auth.)

Analysis within
the systems
development life-cycle
Book 2 Data analysis —
the methods
Rosemary Rock-Evans
Published by
Pergamon Infotech Limited
Berkshire House Queen Street
Maidenhead Berkshire
England SL6 1NF
Telephone: [phone]
International + 44 628 39101
Telex: 847319
(Answerback INFO G)
Fax: [phone] (Gp 2 & 3)
Printed by
A Wheaton & Company Limited
Exeter Devonshire
England
British Library Cataloguing in Publication Data
Rock-Evans, Rosemary
Analysis within the systems development
life-cycle.
Vol. 2: Data analysis: the methods
1. Electronic data processing 2. System
analysis
I. Title
004.2Ί QA76
ISBN 0-08-034101-2
UDC 681.3
Dewey 658.505
© Rosemary Rock-Evans, 1987
All rights reserved. No part of this publication may
be reproduced, stored in a retrieval system, or
transmitted in any form or by any means, elec-
tronic, mechanical, photographic, or otherwise,
without the prior permission of the copyright
owner.
To David
About the author
Rosemary Rock-Evans was educated at Sheffield University, obtaining an Honours degree in Applied
Mathematics and Computing Science.
She started her career as a business systems analyst with British Steel, primarily analysing and designing
commercial systems such as payroll, pensions, stock control, purchasing, commercial order handling and
various financial applications.
She became more and more interested in database technology and the analysis techniques associated with
its introduction and moved into British Steel's Corporate Planning Group to become a data administrator.
There she became involved in strategic corporate planning, data architectures, data and activity modelling,
network planning and design, and data dictionaries. She was instrumental in introducing a structured
analysis method to the corporation.
Rosemary then joined a major consultancy which was at the forefront of the movement towards better
analysis and design methods and had a particular interest in database technology and its effective
exploitation. The consultancy was a pioneer of many new techniques which today are taken for
granted—data modelling and entity life-cycles being examples.
At that time a strong team of consultants pooled their project experiences with the aim of improving, refining
and building on the foundations laid, and she contributed to this team while lecturing and working in
Belgium, England, The Netherlands and Norway.
It was also at this time that she wrote the 'Computer Weekly' articles which were to generate so much
interest in new analysis techniques.
She was one of the few consultants to see the successful completion of the projects on which she had worked
because she worked as project manager on a semi-permanent basis. In four years a total of six major systems
were successfully implemented using the methods and, as a result, many new ideas were generated.
Rosemary now works for Database Consultants Europe, a company founded to develop the methods further
into areas such as strategy studies, feasibility studies, hardware planning and design, and software
evaluation.
She was asked to join them specifically to write an up to date reference book of the methods which had
proved successful on projects. In effect, her job was to document the combined knowledge which she and
her fellow consultants had gained so that it could be disseminated to a wider audience. This series of books
is the result of her work. She has also lectured extensively on some of the techniques described in the books
and has provided a considerable amount of advice to firms wishing to set up effective project life-cycles and
introduce new methods.
vu
Preface
This second book in the series of four, deals with how to actually carry out data analysis (in Book 1
I described what deliverables needed to be collected).
While doing the research, I found this subject to be lacking in any helpful books. There seemed to be
a considerable amount of material on normalisation as the only suggested method of analysis, but
none on what is often the main fact gathering techniques—interviewing the end user and analysing the
interview notes.
Until now, no-one has attempted to pull together the methods used to gather facts (collection) and those
used to analyse them, of which normalisation is only one.
It seemed extraordinary to me that there were books and courses on 'conventional' systems analysis, dealing
with interviewing and observation techniques, for example, and completely separate books and courses on
data analysis. It was as if the two were somehow nothing to do with one another, but nothing could be
further from the truth. It is, in fact, extremely foolish to separate the two, as the fact gathering techniques
taught by many firms must be about facts or 'raw input' which are capable of being analysed. Furthermore,
the most difficult and skilled part of an analyst's job is this 'synthesis' process—the conversion of the raw
input into its deliverable form. I found that the acres of literature produced on 'data modelling' nearly always
described the mechanics of drawing a data model—nothing was ever said about how you use the raw input
of fact gathering to obtain a model.
I hope I have remedied these problems in this book. Certainly, I believe it brings together, for the first time,
all the tasks of analysis—from collection to synthesis and verification. By doing this I have been able to
show, again for the first time, how the results of fact gathering can be used to produce and verify the analysis
deliverables.
I have also been able to suggest a number of alternative methods of analysis other than normalisation which,
as you will see, can be cumbersome and disadvantageous.
Readers who are involved in expert systems will be particularly interested in the references I have made
to PROLOG and LISP and the part these languages could play in the analysis process. Again, I do not
think that anyone has realised, let alone written about, the link there is between the work being done
in expert systems and its relevance to 'non-expert' systems—that is, normal 'commercial' type systems.
This latter area I find particularly exciting and hope that the book generates enough interest to provoke
more research.
XI
Introduction
This book is the second in a series of four which deal with the topic of analysis—finding out what business
systems exist and what systems are needed.
In Book 1 I explained how the original idea grew into four books in my attempts to achieve the objectives
I had set myself. These objectives concentrated on needs such as producing a comprehensive work on the
subject of analysis; providing a complete guide to the deliverables to be collected in analysis; showing the
purpose of those deliverables in relation to the other tasks in the Systems Development Cycle (SDC);
separating deliverables from their packaging; and providing a number of alternative ways of obtaining the
deliverables.
Book 1 concentrated on defining and explaining the purpose of the deliverables of data analysis. This
book—Book 2—concentrates on how you find those deliverables (the actual tasks of data analysis) and aims
to provide a number of alternative ways of obtaining data analysis deliverables.
The latter books mirror Books 1 and 2 by describing the deliverables (Book 3) and the tasks (Book 4) of
activity analysis.
Book 4 is very closely tied in with this book. Many tasks are 'shared', in that they can be used to produce
the two types of deliverable.
This book describes everything which must be done to obtain the deliverables. It is assumed that the reader,
having read Book 1, knows the main deliverables, understands the terms entity type, relationship type,
attribute type and permitted value, and is familiar with the technique of data modelling.
The tasks to be carried out are shown in the logical order of progression—preparation, collection, analysis
of the existing system (which comprises the tasks of synthesis, verification and approval)—and in each case
how the input from the previous task is converted to the output for the next task until the final output—the
verified approved deliverables—is obtained.
Chapter 1 does three things as follows:
1 It puts analysis into its place in the SDC and explains what 'analysis' really means.
2 It gives an overview of the tasks described in this book and how they fit into the SDC. This is particularly
important as it places the rest of the book in its proper context.
3 It provides a reminder of what is meant by a deliverable.
The next chapters cover, in logical sequence of dependency, the actual tasks of data analysis.
Xlll
Chapter 2 deals with the preparation task—the work required to identify what raw input is actually
available, what the sources of raw input are and which are the best. The 'scope' of the study is used to
determine the extent of the search for both raw input and sources.
Chapter 3 covers the collection task which involves sifting the 'best' available raw input identified at the
preparation stage and arranging for its subsequent collection. This chapter also examines the actual output
of the collection task ('verified' raw input).
Chapter 4 deals with the 'synthesis' task (also referred to in the book as 'data conversion') at which stage
the raw input is converted into the deliverable form. Four basic techniques or 'methods' are used:
1 Synthesis (bottom-up) using 'real world' data occurrences.
2 Synthesis (bottom-up) using design occurrences (normalisation).
3 Synthesis (top-down) using real world abstractions.
4 Synthesis (bottom-up) using design abstractions.
The advantages and disadvantages of each method are described in the context of the life-cycle as a whole
and in terms of the reliability of raw input, time problems and so on. Chapter 4 also describes how each
of the data models obtained using the different methods can be combined and subsequently refined using
a number of step-by-step checks.
Chapter 5 deals with the verification task when as yet unverified deliverables, produced from the synthesis
stage, are checked to ensure that they are consistent, logical, complete and a true representation of the
business—the real world. This chapter shows that checks for consistency and logical soundness can be
almost mechanical in their operation, but that verifying the results as a true match with the real world
is more subjective and certainly not mechanical.
Chapter 6 deals with the approval task: obtaining the required agreement from end users that the
deliverables are a true and accurate representation of what exists. Suggested methods of obtaining approval
include packaging the deliverables into a report and the use of 'approval sessions'—presentations and
meetings for example—to gain acceptance. Thus Chapters 2-6 cover the tasks themselves, going into
considerable detail to explain what has to be done to obtain the deliverables.
Chapter 7 is the summary chapter and serves two purposes:
1 It provides a summary of the tasks described in the book and shows how the meta-model is expanded
by considering the intermediate outputs of the tasks of data analysis.
2 A small section answers three of the most common questions asked about analysis: what are the best
ways of documenting the deliverables?; what things can go wrong when carrying out analysis?; and how
can these new techniques be introduced into an organisation?
All the chapters should be easily understood by expert and novice alike, but the book must be read in the
order given or the logical flow and sequence between the tasks will be lost.
The book has been organised so that it has a direct use as a reference after it has been read and, as such,
should prove invaluable for project planning as well as in any study.
xiv
Acknowledgements
My thanks go to the following people or firms who have helped me in producing this book, or have been
instrumental in the development of the method described. At DCE: Keith Greystoke, Michael Broddle, Bill
Stephens, Ian Brindle, Rik Op den Brouw, Len Brown, Rory Fogerty, Wim Gielis, Ray Goodsir, Richard Irwin,
Fred van Leeuwen, Gerard Otten, Glenn Pereira, Howard Thomas and Brian Watson. At Derby Hospital:
Drs Lewis and Nancy Dann for their help in practical hospital procedure and for the use of their forms.
Particular thanks to Roger Bates, who lent me the book on logic.
My thanks must also go to: Mr and Mrs Yates (my mother and father), who did most of the original typing
when the book was in its infancy; to Rosemarie Sheppard, for doing the later typing when the book started
to grow up; to Jacqueline de Henau, for also helping with the typing at the early stages; to Roger Jerram,
David Rock-Evans and Luc Vercruysse, for the encouragement to keep going; and to Paul Mortlock and
Doreen Dowding of Pergamon Infotech. In particular my thanks go to all the consultants and specialists
who have played a part in the development of the methods described in this book—including Ian Palmer,
John Dodd, Leslie Jennison, Richard Barker, David Gradwell, Harry Ellis and many more.
References
I have only included books from which I have extracted ideas (and therefore owe an acknowledgement)
or books which I have found to be particularly pertinent. These are as follows:
• Emery F E—'Systems thinking' (parts 1 and 2)
• Drucker P—'Managing for results'
• Townsend R—Op the organisation'
• Jevons W S—'Logic'
• Harper W M—'Statistics'
• Ennals R—'Beginning Micro PROLOG'
• Clocksin W F and Mellish C S—'Programming in PROLOG'.
xv
Chapter 1 Introduction
'New opinions are always suspected and usually
opposed, without any reason but because they are
not already common9
—John Locke
1
Chapter 1 Introduction
1 Deliverables
An essential part of any Systems Development Cycle (SDC) is the output (deliverables) expected from a major
stage of it. Each task in the life-cycle converts the deliverables of one stage into the deliverables of the next
in a succession of smooth and well-defined steps (see Figure 1.1).
There is a considerable difference between a deliverable (a type of fact which must be collected) and the
ways in which it could be packaged. A deliverable might be the null value or format of an attribute type
or the volumes of an entity type, but it would not be the users' report, the forms on which we record the
deliverables or even the data dictionary system—these are simply means of recording, or 'packaging', the
deliverables. Book 1 was devoted to the deliverables of data analysis and no mention was made of how they
should be packaged.
2 The task of analysis
In Book 1 we saw how the actual task of analysis fits into the SDC so now we can concentrate on looking
at the tasks in the analysis process.
Whether we are carrying out strategic, overview or detailed analysis, the tasks are identical—the only
differences between the stages are in the scope and amount of detail expected from the stage. This is a most
important point.
Figure 1.2 shows all the tasks of analysis—preparation, collection, analysis of the existing system,
specification of the new system, choice of solution and completeness checks—and shows quite clearly what
is covered in this book and what is covered in Book 4.
Many of the tasks omitted from this book relate to the development of new logical business systems.
They have been omitted because it is easier to discuss the development of a new solution in the
context of a total systems solution, including activities and data-related deliverables. In Book 4 we
will see that the data analysis deliverables figure prominently during the discussion of these tasks.
This book concentrates on analysis of the existing system, but before describing the tasks of analysis,
it is important to distinguish between analysis of the existing system and invention of a new system or
'solution'.
At no stage am I referring to computer or clerical systems—the emphasis is still on the logical mechanism-free
systems expressed only in terms of the analysis deliverables. This means that it is possible to have different
data models and different activity models representing different solutions to business problems—an idea
introduced in Book 1 when versions were described. The important feature of a version was that, although
3