- Email: [email protected]
Information-systems methodologies and life-cycle
books,, Information-systems methodologies and life-cycle Information systems methodologies: a framework for understanding T W Oile and six other members of IFIP Working Group 8.1 Addison-Wesley, Wokingham, UK (1988) 346 pp £17.50 softback
Computerized assistance during the Information Systems Life Cycle (Proceedings of the IFIP Working Group 8.1. CRIS 88 Conference) T W Olle, A A Verrijn-Stuart and L Bhabuta North-Holland, Amsterdam, The Netherlands (1988) 539 pp $115.75 hardback Many information systems methodologies have been produced in recent years. Some are actively promoted by commercial consultancies (such as James Martin Associates); others exist mainly in academic and research circles. These methodologies compete for attention and adoption, offering overlapping sets of features, advantages, and benefits. A methodology can be regarded as a generalized description of the activities of design projects, together with a theory that explains why such projects were successful. A methodology is usually presented not as a description but as a prescription a recommendation that projects of a given type should follow the generalized task structure. Some methodologies go further, insisting that success depends on the adoption of the methodology for all the projects of a given type across an enterprise. (This argument is based on the observation that the interfaces between systems are important, and on the assertion that to control an interface between systems, the methodology must, at least to some extent, control the systems themselves.) Such methodologies thus contain idealized descriptions of the coordination between projects, as well as the management of individual projects. But if a methodology is to be more 394
than a hypothesis, it should be tested by experience on real projects. (Unfortunately, since a real project uses at most one methodology, although this methodology may be a hybrid merger of two or more other methodologies, such tests cannot compare two methodologies directly). But this is difficult. To judge a methodology from a single project that fails may be unfair, for two reasons. First, it is never certain that the methodology has been fully and correctly applied on a given project, so a failure can always be attributed to deviations from the methodology, rather than to the methodology itself. Second, a methodology may not be able to completely eliminate risk (although it should substantially reduce it), so a failure can always be attributed to bad luck. And it is also unfair to judge a methodology from a single project that succeeds even though it ignores or disobeys all of the methodology's principles, since this may also be luck. Of course, recurrence of such counter-examples - - that fail when they ought to succeed, or vice versa - will seriously dent the credibility and reputation of a methodology, especially if similar results are found in different organizations. But such resuits are hard to come by. Facts are difficult to obtain, and more difficult still to interpret. And when accumulated experience does indicate problems in a given methodology (or class of similar methodologies) it is difficult to trace the faulty component. There can be no equivalent of Richard Feynmann's brilliant demonstration that the Space Shuttle explosion was due to the effect of cold on an elastic O-ring. Both the theory and the practice of methodologies require some other way of looking at them. Practitioners (including users) can act more intelligently on projects if they understand how the methodology fits together.
They need to understand a methodology from the inside, to know where shortcuts may be possible on a given project, without excessive risk. (This requires that the methodology be a visible system.) Researchers also need such an understanding, to explain (and, if possible, predict) success and failure of projects and to analyse the strengths and weakness of methodologies (and, if possible, improve them). Several attempts have been made in recent years to produce a 'metamethodology', a framework that does to methodologies what methodologies do to projects, namely, provide a generalized description of several of them, together with a theory of what makes them more or less successful. Previous attempts along these lines have included the Flexible Framework, published by a BCS Working Party in 1985, and Multiview. Now the IFIP Working Group 8.1, best known for its CRIS series of conferences, has published its own framework. The book is not intended as an introduction to methodologies and is unlikely to be used as a' primary undergraduate textbook. Instead, it should be read by practitioners, developers, and anyone who has some knowledge of methodologies already and wants to gain a deeper understanding of their structures and mechanisms. The framework as presented is provisional and deserves further development, but it is thought provokingly clear and shows few signs of having been written by committee. The second book under review comprises the advance material of the fourth CRIS conference, held in the UK in September 1988. (I hesitate to use the term 'proceedings' for a volume that contains the presented papers only, with no live discussion.) This conference focused on the automation of methodologies and the increasing use of CASE (computerinformation and software technology
books aided software engineering) tools for making systems development more efficient and hopefully more effective as well. Research in this field seems to be dominated by the Europeans, although there is one Japanese contribution and a couple from North America. Some of the tools described are commercially available, while others appear to be still at the R & D stage. Requiring all the tools to address the same case study makes the comparison easier, but perhaps the simplicity of the case masks the
advantages of the next generation of tools, which incorporate advanced modelling techniques and expert systems technology. The desirability of automation is taken for granted. Several contributors see the need for an increasing determinism of the systems development process, forcing different practitioners to arrive at the same endresult, as a precursor to further automation. Many in the industry will welcome this trend towards greater standardization and
reliability. As with the first book under review, this book is unlikely to serve as an introduction to the subject. However, it provides a good snapshot of the state of the art and will be referred to by many leading user organizations as well as by researchers and suppliers. The CRIS group is to be congratulated for continuing its programme of methodology innovation. R VERYARD James Martin Associates, Ashford, U K
Short but succinct guide to parallel programming P-PROLOG, a parallel logic pro9rammin9 languaye R Yang World Scientific Editions (1987) 138 pp hardback Parallel programming languages are an active research and industrial development area motivated by the increasing need of efficient systems in particular for realtime applications. Logic programming is also an active area because logic provides a clear and simple semantics that can be used in a number of situations with great success. Logic programming has introduced a new way of programming, providing programmers with a highly declarative and modular framework. There are several logic programming languages. PROLOG is undoubtedly the most popular. It permits the integration in a unified framework of many aspects of programming. Its computation rule is simple, but, however, not complete. A strong trend in logic programming is parallel processing. It is aimed at providing completeness to logic programming languages, a more constrained way of writing programs, and a greater efficiency. This short book presents the motivations and the syntax and semantics of a full parallel logic programming
vol 31 no 7 september 1989
language, P-PROLOG. Its implementation is discussed in detail. P-PROLOG has the advantages of guarded Horn clauses and integrates the don't know nondeterminism whenever required. The language introduces the new concept of classified Horn clauses, which can be defined as follows: • The language introduces the notion of exclusive guarded Horn clauses, which is a run-time concept that is used as a synchronization mechanism. • The language combines andparallelism and or-parallelism, thus the don't know and the don't care nondeterminism can be integrated. • The input/output pattern of predicates need not be specified in advance. The synchronization mechanism makes this task dynamically. For and-parallelism, goals in the guard and in the body are evaluated in parallel and the guard part on the one hand and the body part on the other are evaluated sequentially. For or-parallelism, the alternative clauses are called in parallel (head unification and guard); a set of alternative clauses (not necessarily exclusive) can be reduced in parallel search to get
multiple solutions. At the level of the implementation, an or-tree model is provided. An implementation model of it is proposed, combining the different types of parallel processing with quite good efficiency. Programming in P-PROLOG is somewhat more complicated than programming in pure PROLOG because the programmer has to follow the constraints of the language and has to keep in mind the computation rule used. It is, however, my feeling, quite simple to write programs in P-PROLOG, and the examples given are quite convincing. This book is thus a nice introduction to parallel programming, providing a language that can be easily used by system designers in the industry as well as by students and faculty members willing to familiarize themselves with this difficult domain. The book is well written, with, however, some spelling and grammatical errors that the publisher should have noticed. The book is short (sometimes a little too much when surveying related works) and can be read in a reasonable time.
P SAINT-DIZIER CNRS, Toulouse, France
395
Computerized assistance during the Information Systems Life Cycle (Proceedings of the IFIP Working Group 8.1. CRIS 88 Conference) T W Olle, A A Verrijn-Stuart and L Bhabuta North-Holland, Amsterdam, The Netherlands (1988) 539 pp $115.75 hardback Many information systems methodologies have been produced in recent years. Some are actively promoted by commercial consultancies (such as James Martin Associates); others exist mainly in academic and research circles. These methodologies compete for attention and adoption, offering overlapping sets of features, advantages, and benefits. A methodology can be regarded as a generalized description of the activities of design projects, together with a theory that explains why such projects were successful. A methodology is usually presented not as a description but as a prescription a recommendation that projects of a given type should follow the generalized task structure. Some methodologies go further, insisting that success depends on the adoption of the methodology for all the projects of a given type across an enterprise. (This argument is based on the observation that the interfaces between systems are important, and on the assertion that to control an interface between systems, the methodology must, at least to some extent, control the systems themselves.) Such methodologies thus contain idealized descriptions of the coordination between projects, as well as the management of individual projects. But if a methodology is to be more 394
than a hypothesis, it should be tested by experience on real projects. (Unfortunately, since a real project uses at most one methodology, although this methodology may be a hybrid merger of two or more other methodologies, such tests cannot compare two methodologies directly). But this is difficult. To judge a methodology from a single project that fails may be unfair, for two reasons. First, it is never certain that the methodology has been fully and correctly applied on a given project, so a failure can always be attributed to deviations from the methodology, rather than to the methodology itself. Second, a methodology may not be able to completely eliminate risk (although it should substantially reduce it), so a failure can always be attributed to bad luck. And it is also unfair to judge a methodology from a single project that succeeds even though it ignores or disobeys all of the methodology's principles, since this may also be luck. Of course, recurrence of such counter-examples - - that fail when they ought to succeed, or vice versa - will seriously dent the credibility and reputation of a methodology, especially if similar results are found in different organizations. But such resuits are hard to come by. Facts are difficult to obtain, and more difficult still to interpret. And when accumulated experience does indicate problems in a given methodology (or class of similar methodologies) it is difficult to trace the faulty component. There can be no equivalent of Richard Feynmann's brilliant demonstration that the Space Shuttle explosion was due to the effect of cold on an elastic O-ring. Both the theory and the practice of methodologies require some other way of looking at them. Practitioners (including users) can act more intelligently on projects if they understand how the methodology fits together.
They need to understand a methodology from the inside, to know where shortcuts may be possible on a given project, without excessive risk. (This requires that the methodology be a visible system.) Researchers also need such an understanding, to explain (and, if possible, predict) success and failure of projects and to analyse the strengths and weakness of methodologies (and, if possible, improve them). Several attempts have been made in recent years to produce a 'metamethodology', a framework that does to methodologies what methodologies do to projects, namely, provide a generalized description of several of them, together with a theory of what makes them more or less successful. Previous attempts along these lines have included the Flexible Framework, published by a BCS Working Party in 1985, and Multiview. Now the IFIP Working Group 8.1, best known for its CRIS series of conferences, has published its own framework. The book is not intended as an introduction to methodologies and is unlikely to be used as a' primary undergraduate textbook. Instead, it should be read by practitioners, developers, and anyone who has some knowledge of methodologies already and wants to gain a deeper understanding of their structures and mechanisms. The framework as presented is provisional and deserves further development, but it is thought provokingly clear and shows few signs of having been written by committee. The second book under review comprises the advance material of the fourth CRIS conference, held in the UK in September 1988. (I hesitate to use the term 'proceedings' for a volume that contains the presented papers only, with no live discussion.) This conference focused on the automation of methodologies and the increasing use of CASE (computerinformation and software technology
books aided software engineering) tools for making systems development more efficient and hopefully more effective as well. Research in this field seems to be dominated by the Europeans, although there is one Japanese contribution and a couple from North America. Some of the tools described are commercially available, while others appear to be still at the R & D stage. Requiring all the tools to address the same case study makes the comparison easier, but perhaps the simplicity of the case masks the
advantages of the next generation of tools, which incorporate advanced modelling techniques and expert systems technology. The desirability of automation is taken for granted. Several contributors see the need for an increasing determinism of the systems development process, forcing different practitioners to arrive at the same endresult, as a precursor to further automation. Many in the industry will welcome this trend towards greater standardization and
reliability. As with the first book under review, this book is unlikely to serve as an introduction to the subject. However, it provides a good snapshot of the state of the art and will be referred to by many leading user organizations as well as by researchers and suppliers. The CRIS group is to be congratulated for continuing its programme of methodology innovation. R VERYARD James Martin Associates, Ashford, U K
Short but succinct guide to parallel programming P-PROLOG, a parallel logic pro9rammin9 languaye R Yang World Scientific Editions (1987) 138 pp hardback Parallel programming languages are an active research and industrial development area motivated by the increasing need of efficient systems in particular for realtime applications. Logic programming is also an active area because logic provides a clear and simple semantics that can be used in a number of situations with great success. Logic programming has introduced a new way of programming, providing programmers with a highly declarative and modular framework. There are several logic programming languages. PROLOG is undoubtedly the most popular. It permits the integration in a unified framework of many aspects of programming. Its computation rule is simple, but, however, not complete. A strong trend in logic programming is parallel processing. It is aimed at providing completeness to logic programming languages, a more constrained way of writing programs, and a greater efficiency. This short book presents the motivations and the syntax and semantics of a full parallel logic programming
vol 31 no 7 september 1989
language, P-PROLOG. Its implementation is discussed in detail. P-PROLOG has the advantages of guarded Horn clauses and integrates the don't know nondeterminism whenever required. The language introduces the new concept of classified Horn clauses, which can be defined as follows: • The language introduces the notion of exclusive guarded Horn clauses, which is a run-time concept that is used as a synchronization mechanism. • The language combines andparallelism and or-parallelism, thus the don't know and the don't care nondeterminism can be integrated. • The input/output pattern of predicates need not be specified in advance. The synchronization mechanism makes this task dynamically. For and-parallelism, goals in the guard and in the body are evaluated in parallel and the guard part on the one hand and the body part on the other are evaluated sequentially. For or-parallelism, the alternative clauses are called in parallel (head unification and guard); a set of alternative clauses (not necessarily exclusive) can be reduced in parallel search to get
multiple solutions. At the level of the implementation, an or-tree model is provided. An implementation model of it is proposed, combining the different types of parallel processing with quite good efficiency. Programming in P-PROLOG is somewhat more complicated than programming in pure PROLOG because the programmer has to follow the constraints of the language and has to keep in mind the computation rule used. It is, however, my feeling, quite simple to write programs in P-PROLOG, and the examples given are quite convincing. This book is thus a nice introduction to parallel programming, providing a language that can be easily used by system designers in the industry as well as by students and faculty members willing to familiarize themselves with this difficult domain. The book is well written, with, however, some spelling and grammatical errors that the publisher should have noticed. The book is short (sometimes a little too much when surveying related works) and can be read in a reasonable time.
P SAINT-DIZIER CNRS, Toulouse, France
395