This book is a must-have for all IT professionals facing software development problems on a daily basis. If you are a systems analyst or requirements engineer it will provide an essential, practical guide from the task of identifying the problem to making the descriptions needed to resolve it. It will help decompose complex problems into simpler subproblems and see how the subproblems fit together; and build up a repertoire of simple, clear and easily applicable problem classes which you can access and reuse, drawing on the experience associated with each class. numerous real-world example problems are analyzed, giving you insight into how to recognize and structure your own problems in practice; a mixture of large and small problems is presented, showing the stripped down essence of problem classes and discussing different aspects of each problem; problem frames are independent of any particular development method, so they can be easily applied in your own situation; and appendices summarizing the descriptive languages and notations; plus a glossary of terminology.
Professor Michael Anthony Jackson (born 1936) works as an independent computing consultant in London, England, and also as a part-time researcher at AT&T Research, Florham Park, NJ, U.S.. He is a visiting research professor at the Open University in the UK.
Jackson was educated at Harrow School where he was taught by Christopher Strachey and wrote his first program under Strachey's guidance. He then studied classics at Oxford University (known as "Greats"), where he was a fellow student with C. A. R. Hoare, two years ahead of him. They had a shared interest in logic, which was studied as part of Greats at Oxford.
In the 1970s, Jackson developed Jackson Structured Programming (JSP). In the 1980s, with John Cameron, he developed Jackson System Development (JSD). Then, in the 1990s, he developed the Problem Frames Approach. In collaboration with Pamela Zave, he created Distributed Feature Composition, a virtual architecture for specification and implementation of telecommunication services.
In short, it's a poorly written book on a very interesting concept. The author presents 5 basic types for problems which is supposed to represent anything a software engineer might encounter, and of course these 5 "problem frames" don't cover everything. The ideas presented with the whole context diagrams and problems diagrams are useful in scoping the problem, if you can get through the text. And if you happen to have a problem that does fit one of Jackson's 5 problems frames, there is some useful analysis that can be made using material in the book. I do expect to use the ideas presented, I just wish the book was more clearly written.
I wish this was written differently as there's good stuff hiding in here, but it's really difficult to keep reading and rereading sections. I found it to be very slow at getting to the point after the first few chapters and it meant I put it down for longer and longer intervals, meaning I had to go back and reread earlier sections multiple times as the terminology invented and used was not commonplace so kept falling out of my head.
Regardless of how very difficult it is to read, there's some really high quality observations of value. The very concept of problem frames is quite powerful and the author has found a few which seem to cover most of the software we write, which is pretty astounding. As a game developer, I would have thought it was missing a lot of things commonly used, but actually, it turns out most problems are just the same kind of biddable lexical problems and display problems but with deeper and deeper hierarchies of sub domains. I'm not sure how much help it will be for those programming domains, but for the work I now do in a high safety environment, I think these frames will help guide the requirements phase better and expose some areas we may otherwise have missed.
Lösungen werden mit vertieftem Problemverständnis besser, daher Anforderungsanalyse. Anforderungen beziehen sich v.a. auf Probleme außerhalb des Computers, während letzterer Teil der Lösung ist. Jackson klassifiziert solche Beziehungen. Vor Kauf besser probelesen. Evtl. bessere Kontextdiagramme als in der UML.