<< 1 >>
Rating: 
Summary: A useful new approach to software requirements analysis
Review: "Problem Frames" is best regarded as volume 2 of a two-volume work whose first volume is Jackson's earlier book, "Software Requirements and Specifications". Before tackling "Problem Frames" you should dip into SRS. SRS is a relatively small book, an easy and enjoyable read, and very accessible. Then, if you find that you like SRS and want more, you should move on to "Problem Frames".I tried out the Problem Frames Approach on a couple of my own software development problems, and found out that, just as Jackson asserts, it is a lot easier to think clearly about several small and relatively simple problems than it is to think about one big inchoate problem. Jackson calls this "separation of concerns", and PFA gives you the theoretical justification - and the tools - for doing it. And it works; it produces real and helpful insights and makes requirements analysis much more manageable. Jackson's method of exposition is detailed discussion of illustrative examples. This means that you have to devote some effort to carefully following the details of many specific examples. If you do, then "Problem Frames" repeatedly passes the Aha! test. This book and the Problem Frame Approach represent a major advance in the way we approach computer requirements specification. "Problem Frames" is as seminal a work for requirements analysis as Design Patterns was for object-oriented design. Anyone who is seriously interested in computer software requirements analysis -- and especially if you are familiar with Jackson's earlier works -- will absolutely want to study this book.
Rating:
Summary: A useful new approach to software requirements analysis
Review: "Problem Frames" is best regarded as volume 2 of a two-volume work whose first volume is Jackson's earlier book, "Software Requirements and Specifications". Before tackling "Problem Frames" you should dip into SRS. SRS is a relatively small book, an easy and enjoyable read, and very accessible. Then, if you find that you like SRS and want more, you should move on to "Problem Frames". I tried out the Problem Frames Approach on a couple of my own software development problems, and found out that, just as Jackson asserts, it is a lot easier to think clearly about several small and relatively simple problems than it is to think about one big inchoate problem. Jackson calls this "separation of concerns", and PFA gives you the theoretical justification - and the tools - for doing it. And it works; it produces real and helpful insights and makes requirements analysis much more manageable. Jackson's method of exposition is detailed discussion of illustrative examples. This means that you have to devote some effort to carefully following the details of many specific examples. If you do, then "Problem Frames" repeatedly passes the Aha! test. This book and the Problem Frame Approach represent a major advance in the way we approach computer requirements specification. "Problem Frames" is as seminal a work for requirements analysis as Design Patterns was for object-oriented design. Anyone who is seriously interested in computer software requirements analysis -- and especially if you are familiar with Jackson's earlier works -- will absolutely want to study this book.
Rating: 
Summary: disappointment: do not buy this book
Review: I am electronic engineer and have years of practice in hardware production (at first part of my carrier), system administration, and software production (various assemblers, Modula-2, Fortran, Clipper, FoxPro, Lotus Notes, Informix, Visual Basic, C, C++, ASP, UML, Java). I have seen various notations and approaches to software design so far. I respect what all other reviewers have said about the book and it is possible that till the end of this book I shall find at least the tiny part of their excitement about it. But I doubt it. One reviewer said this book would stand side by side to the GoF book? I do not understand that. The complexity and influence of GoF is so much far from this book that these two can't even be compared in my opinion. If this book can stand with GoF book, how come the GoF book is reviewed by 173 people at Amazon from 1995 year, and this book from 2000 year is only reviewed from 5 people till now including my comment? Even the same reviewer asks himself the question why he cannot find other resources on the same topic - of course he can't find them because this concept is BAD. The other reviewer, Mr. Tarrani, probably carries the world record with 673 comments on Amazon. Interestingly enough he gave ALL HIS 673 BOOKS HE COMMENTED 5 STARS. The guy is really in love with every book he read! Another reviewer, Mr. Daniel Duffy thinks Mr. Jackson's method is good "because current object-oriented techniques (based on UML, for example) tend to be solution-oriented in the early stages". First, I think this is dependable on designer's experience alone, so UML itself should not be blamed for bad designs. You can do bad design with Mr. Jackson's method too if you are a bad designer. Now, when reading only the first three chapters of the book, I can't resist the temptation to tell my opinion of the book: it is so boring and dull that you think you would die till the end of this painful book. Jackson could say all this in much less words. So far as I got into the book, Jackson explains how to represent the specific part of software concept, which is at the outside of the computer. Jackson uses extensively the examples of hardware controllers throughout the whole book; the hardware controller is put in a special box with two stripes in the middle of the main or so-called context diagram. That hardware controller is connected afterwards with other boxes, which are either software parts or some objects in the vicinity. Perhaps Mr. Jackson's concept would suit some of the needs of my previously favorite field - hardware controllers. But this book claims to deal with "software development" which is not true - it deals only with the UML business cases, and that mostly for hardware controlers. Why would anybody learn complicated schemes of Mr. Jackson just to start the software design process? Maybe we should buy 10 other books Mr. Jackson is writing for us now? After browsing through the book, I am more and more convinced that Mr. Jackson's method is very narrow to be implemented to the whole design process from requirements to programming (in his new book he admits that, read the comment at Amazon), his method is much more complicated than it should be by my humble opinion. Simply said - it is a commercial miss. The UML by all undivided opinions have much longer future. The UML covers the whole design process, and Mr. Jackson covers just barely the very beginning of the process! And in my opinion finite state machines would do just fine without his notation! In order to explain his system, Mr. Jackson is talking so slowly, so flatly, that you count his every word. I am sorry to say that - the book is useless. People, learn from my experience and don't get yourself killed by boredom - do not buy this book!
Rating:
Summary: A solid approach to identifying and analyzing problems
Review: Short and sweet: this book is about structuring and analyzing problems, not about solutions. In fact, from the beginning the author discusses the difficulty of focusing on problems and the tendency to jump to a solution before the problem is completely understood. The structured approach that Mr. Jackson provides starts with bounding the problem and drilling down into subproblems, called problem frames. I like his approach to bounding problems because it shows how to identify and isolate the problem and place it into its proper context. This forces you to focus on the problem and not drift off into a premature solution. I also like how he breaks down problems into manageable chunks by placing subproblems into domains through the use of projections (where subproblem domains overlap) and partitions (where associated phenomena are isolated). This allows you to see the whole problem in its magnificent splendor, which is the first step towards tackling each of its parts. As Mr. Jackson's approach evolves you will find patterns emerging. If you are a proponent of design patterns you will appreciate how he breaks problems into classes and five basic frames. This is a powerful concept because as you gain experience using problem frames you will be able to quickly classify problems and approach them in a consistent, repeatable manner. This part of the book greatly influenced my way of thinking about problems, and the material is reinforced by examples given in subsequent chapters, as well as chapters devoted to variant and composite frames. This book is ostensibly about problem frames and methods as they relate to software development. However, the approach given in the book has much wider applications. I was able to relate it to physical devices, processes and procedures. Moreover, Mr. Jackson's approach itself can be decomposed into a collection of useful tools and techniques that, taken individually, will prove invaluable in requirements analysis, design and related endeavors. I am giving it 5 stars only because I cannot give it more.
Rating:
Summary: A solid approach to identifying and analyzing problems
Review: Short and sweet: this book is about structuring and analyzing problems, not about solutions. In fact, from the beginning the author discusses the difficulty of focusing on problems and the tendency to jump to a solution before the problem is completely understood. The structured approach that Mr. Jackson provides starts with bounding the problem and drilling down into subproblems, called problem frames. I like his approach to bounding problems because it shows how to identify and isolate the problem and place it into its proper context. This forces you to focus on the problem and not drift off into a premature solution. I also like how he breaks down problems into manageable chunks by placing subproblems into domains through the use of projections (where subproblem domains overlap) and partitions (where associated phenomena are isolated). This allows you to see the whole problem in its magnificent splendor, which is the first step towards tackling each of its parts. As Mr. Jackson's approach evolves you will find patterns emerging. If you are a proponent of design patterns you will appreciate how he breaks problems into classes and five basic frames. This is a powerful concept because as you gain experience using problem frames you will be able to quickly classify problems and approach them in a consistent, repeatable manner. This part of the book greatly influenced my way of thinking about problems, and the material is reinforced by examples given in subsequent chapters, as well as chapters devoted to variant and composite frames. This book is ostensibly about problem frames and methods as they relate to software development. However, the approach given in the book has much wider applications. I was able to relate it to physical devices, processes and procedures. Moreover, Mr. Jackson's approach itself can be decomposed into a collection of useful tools and techniques that, taken individually, will prove invaluable in requirements analysis, design and related endeavors. I am giving it 5 stars only because I cannot give it more.
Rating:
Summary: Problem Frames resources on the web
Review: The academic community is slowly getting interested in the problem frames approach. The first conference workshop on problem frames was held in Edinburgh, Scotland on May 14, 2004. There are a few online resources: see... http://www.ferg.org/pfa/index.html
Rating:
Summary: Problem Frames resources on the web
Review: The academic community is slowly getting interested in the problem frames approach. The first conference workshop on problem frames was held in Edinburgh, Scotland on May 14, 2004. There are a few online resources: see... http://www.ferg.org/pfa/index.html
Rating:
Summary: Finally a book that can stand with Design Patterns by GoF!!
Review: This is a seminal book on software requirements analysis. Its 300 odd pages makes it very handy and "carryable". I have just finished reading the book and started implementing Michael Jackson's ideas into a software project. The benefits have just started showing up. Oddly, enough I did not find too many other resources on the same topic in the web.
Rating:
Summary: A highly useful book for architects and analysts
Review: This is an excellent book. Michael Jackson resolves a number of major problems by drawing a distinction between the description of the problem domain and the description of the solution domain. This is needed because current object-oriented techniques (based on UML, for example) tend to be solution-oriented in the early stages of the software development lifecycle. This mindset can lead to maintainability problems later. Another 'gem' is that Jackson develops a scheme for decomposing a problem into simpler subproblems. This 'divide and conquer' approach has been known to mathematicians for hundreds of years. Structured analysis methods use similar techniques but they have seemingly been forgotten (or never learned?) by the OO community where the objects are there 'just for the picking' (to quote Bertrand Meyer). This reviewer now realises that life is not so simple. I have benefited from Jackson's problem frames and have applied them as a 'front-end' to UML in order to structure medium and large systems. In particular, viewing a specific application (such as a home heating system, ATM ...) as an instance of a more general category is very useful as it allows us to gain insights into the current problem. I have specialised the frames to discover domain categories for process control, manufacture, MIS, access control and tracking. This book could trigger a number of developments. For example, discovering and documenting structural and behavioural patterns in this phase of the software development lifecycle could would be a good idea. In particular, looking at requirements as goals instead of jumping directly into the over-hyped use cases seems like a good idea as well. To this end, it might be worth looking at a number of methods that are mentioned in the book, for example KAOS.
<< 1 >>
| 
