Some 15 years ago I taught courses in program design using the eponymous structured programming design method JSP devised by Michael A Jackson. I found it a very rewarding method to teach and apply.

Then, 5 years later, I was teaching courses about systems development methods such as SSADM and other approaches, such as OO, when I read about JSD by the same author. Jackson System Development is a very interesting method because it has the ability to model concurrent processes clearly and simply (many systems development and program design methods do not even attempt to model concurrency in any detail.) When MJSL was bought by LBMS, JSD was further expanded, although, as far as I can remember Michael was not involved in those changes.

In each case Michael's books describing these approaches to software development are characterised by clarity of thought and expression and this book is no exception. It looks first at the real world area of the problem and attempts to model its characteristics without reference to a computer solution. This is as it should be; some problems can be solved by getting people to do things differently, rather than saying 'what you need here is a database, program, widget, or ...', without studying where the problem really lies.

This area of systems analysis is largely about the 'soft' aspects of the problem domain. The book identifies that, in general, the problem is modelled using analytic (describes possible behaviours of the system) and analogic (an alternative reality with similar properties to the real system) models.

The book clearly differentiates between that part of the system that is being analysed for possible implementation as a computer system, 'the machine domain' and the real-world system that includes the prospective computer system and all that interfaces with that. As an example of the difference (to paraphrase the book); a library computer system would probably not need to be aware of information about book sizes or staffing levels in the machine domain, whereas the 'larger' real-world domain would need to be cognisant of these properties of the system.

The book then goes on to describe the process of finding and setting the boundaries of the problem space using context diagrams, which are used by many A&D methods to scope the area that needs further analysis. It identifies the 'machine' domain and the interfaces between it and the problem domains and the interfaces between the problem domains themselves. These problem domains are similar to external entities in other A&D methods.

Generally those problem domains that communicate with the machine domain, either directly or indirectly, need to appear in the context diagram. This is expressed clearly in the book, which considers examples of the types of problem domain that need to be included in the analysis.

Analysis of the machine and problem domains identifies the phenomena that need to be stored or passed between the domains. Part of the analysis at this point consists of separating the domains into sub-problems, identifying the requirements and linking them to the corresponding problem domains. If using top-down decomposition, the sub-problems are decomposed further until such time as the sub-problem domains can be implemented. Alternatively, Use Cases can be used as a part of the analysis process.

The main part of the book, of course, discusses problem frames (PFs), which are one of a number of ways of grouping problems by type. PFs are similar to the GOF's Design Patterns - Elements of Reusable Object-Oriented Software , but are problem, rather than solution, oriented. The argument in favour of problem frames seems to me to be entirely sensible; it is easier to solve a problem once you can classify the type of problem - even more so if you have solved that type of problem before.

One chapter discusses the maturity, or rather the lack of it, in the software development process. This in many respects mirrors discussions and arguments that have appeared in C Vu and Overload on the subject of professionalism in the software development process. My impression is that there is still a long way to go in software development before we are able to rival some other engineering disciplines' successes - software engineering is easily capable of mimicking the failures!

Throughout the book there are numerous examples and short question and answer sessions that clarify, or add to, the rest of the text. I also thought that it was readable - very useful for subject matter that many would find rather dry.

I really enjoyed this book. I would recommend that anyone working in software development should, at the very least, read it. It gives a different perspective on the approach to be taken in the early part of the development process, which I believe will improve the software and non-software solutions. Highly recommended.