Software Development Problem Framework -- Structured Analysis of Real-World Problems

Author: Michael Jackson
Publisher:
Publish Date: 2005-01-01
Features: The book features:
· Analyzes many real-world example problems and explains how to identify and structure problems in practice.
· Combines problems of various sizes, peeling away layers to reveal the essence of problem categories and discusses different aspects of each problem.
· The problem framework is independent of any specific development method, making it easy to apply to specific environments. The book helps:
· Break down complex problems into simple subproblems and discuss how to combine them.
· Establish a simple, clear, and usable repository of problem categories that can be accessed and reused, deriving experience related to each category.
The book analyzes many real-world example problems and explains how to identify and structure problems in practice. It covers both large and small problems, revealing the hierarchical nature of problem categories and discussing different aspects of each problem. The book is suitable for teachers, students, and practitioners in system analysis, system specification, and software and requirements engineering, as well as anyone interested in the concepts and smart tools of software development. "Understanding and using problem frameworks is likely to become a fundamental skill for all software system designers, and Jackson's book provides an excellent pathway into this field." — David Garlan, Professor of Computer Science at Carnegie Mellon University "I believe Michael Jackson has absorbed the essence of many design patterns in this book and constructed a more accessible technique for using framework metaphors." — Warren Keuffel, Senior Editor of Software Development In handling software development problems, people often hastily start considering solutions. However, software development problems involve the world outside the computer (i.e., the real environment in which the system operates), so the characteristics, relationships, and context of the surrounding environment must be considered. Problem frameworks are tools for classifying, analyzing, and structuring such software development problems. Object-oriented patterns primarily focus on solutions, while problem frameworks focus on the problems themselves, enabling you to understand and solve them clearly and directly.
Problem Frames: Analyzing and Structuring Software Development Problems by Michael Jackson
The book features:
· Analyzes many real-world example problems and explains how to identify and structure problems in practice.
· Combines problems of various sizes, peeling away layers to reveal the essence of problem categories and discusses different aspects of each problem.
· The problem framework is independent of any specific development method, making it easy to apply to specific environments. The book helps:
· Break down complex problems into simple subproblems and discuss how to combine them.
· Establish a simple, clear, and usable repository of problem categories that can be accessed and reused, deriving experience related to each category.
The book analyzes many real-world example problems and explains how to identify and structure problems in practice. It covers both large and small problems, revealing the hierarchical nature of problem categories and discussing different aspects of each problem. The book is suitable for teachers, students, and practitioners in system analysis, system specification, and software and requirements engineering, as well as anyone interested in the concepts and smart tools of software development. "Understanding and using problem frameworks is likely to become a fundamental skill for all software system designers, and Jackson's book provides an excellent pathway into this field." — David Garlan, Professor of Computer Science at Carnegie Mellon University "I believe Michael Jackson has absorbed the essence of many design patterns in this book and constructed a more accessible technique for using framework metaphors." — Warren Keuffel, Senior Editor of Software Development In handling software development problems, people often hastily start considering solutions. However, software development problems involve the world outside the computer (i.e., the real environment in which the system operates), so the characteristics, relationships, and context of the surrounding environment must be considered. Problem frameworks are tools for classifying, analyzing, and structuring such software development problems. Object-oriented patterns primarily focus on solutions, while problem frameworks focus on the problems themselves, enabling you to understand and solve them clearly and directly.
Translator's Preface What are requirements? What is the true meaning of software requirements? Why do we need software? What do we need software for? These are questions that researchers in requirements engineering have been trying to answer. From general textbooks and many research papers, we often see two viewpoints: One view holds that requirements are the conditions or capabilities needed to solve problems or achieve goals, from a user's perspective. The other view holds that requirements are the conditions or capabilities possessed by a system or its components to meet a contract, standard, specification, or other form of document, with the collection of all requirements forming the basis for subsequent development of the system or its components, from a software developer's perspective. Both viewpoints reflect the characteristics of software requirements at certain levels. However, is it enough to understand requirements only at this level? I believe most people would answer negatively. Because if we use them as definitions of requirements, when facing the real world and preparing to capture, grasp, and describe requirements, we would still be lost. We often ask: In the real world, there are so many diverse tasks to be done and so many different problems to be solved—what can software solve? What should we focus on when capturing software requirements? In other words, what is the true meaning of software requirements? Emphasizing the description of the environment in which software will operate and referring to the meaning of requirements in terms of environmental descriptions is a consistent viewpoint of the author, Michael Jackson. This viewpoint can be traced back to an article he published in Annals of Software Engineering in 1997, where he first introduced the concept of the environment in which software operates. The relationship between software requirements and software goals, i.e., environment, software requirements. This viewpoint is currently gaining increasing attention in the international requirements engineering community, as it examines the connotation of requirements from a completely new perspective. What kind of environment can software operate on? What changes can software bring to the environment when it operates on it? What are the characteristics of this interaction? The author believes that the real-world problems that software can address are the true essence of software requirements, and structuring and analyzing them are the fundamental starting point for requirements analysis. Answering these questions will provide guidance for capturing and analyzing software requirements. This book attempts to provide practical solutions to these problems in real-world scenarios. It starts by focusing on and identifying real-world problems, then moves on to the decomposition of real-world problems, the focus and style of problem frameworks, variations and special considerations of different problem frameworks, the combination of problems, and the incremental software development process, revealing the basic patterns of real-world problems that software can solve. It should be noted that when the translator began translating this book, this was a completely new concept for them. Although the translator read many other relevant materials written by the author over the past few years and engaged in in-depth discussions with the author on some issues, due to the depth of understanding of this issue and the urgency of time, there may be some inappropriate translations, and the translator sincerely requests the readers' corrections. Spring 2004, Beijing
Michael Jackson has over 40 years of experience in the software development industry. He created the JSD method for system development and the JSP method for program design. He was awarded an honorary doctorate, the Stevens Award, the IEE Achievement Award, the Lovelace Medal from the British Computer Society, and the ACM SIGSOFT Award for his contributions to this field. He is frequently invited to give presentations at international conferences and has written four books. He is now an independent consultant and a part-time researcher at ATT Research.
Software Development Problems The central goal in software development problems is to create software for computer systems that serve a specific real-world purpose. This book discusses how to analyze and structure such problems. These problems can appear in many different contexts and forms. If you are engaged in software development, you may need to build a system to serve as a repository and access mechanism for bank account and loan information. You may need to develop a telephone switching system to route local calls. You may need to create a tool for writing and editing text and graphics, or create a device to maintain the speed of a car, or create a compiler to convert Java programs into bytecode. Almost any part of human society and the physical world can serve as the raw material and context for software development problems. Because computers have so many uses and play a central role in solving many problems, the practice of software development is less rigorous than that of mature engineering disciplines. Developers and development projects vary greatly, so we should start by describing and structuring problems in a way that is rarely needed in other engineering disciplines. In other engineering disciplines, the variations in problems to be solved are much smaller. A car engineer designing a sports car does not need to ask whether the car must be able to carry 15 people, whether it can drive underwater, whether it can carry a load of 10 tons, or whether it can move backward at a speed of 100 miles per hour. The term "sports car" both clarifies the problem and specifies acceptable solutions for many other problems. However, as a software developer, you rarely solve immediately identifiable and easily understandable problems. You often have to start by asking: What kind of problem is this? What exactly is this problem? What is its purpose? What behavior and characteristics must the computer have for this purpose? Often, software development seems to start from scratch.
Problem Frames When you analyze a problem, you need to identify what kind of problem it is and pinpoint the focus and difficulties to be solved. The focus in a Java compiler will be completely different from that in a car braking system. You will have to consider different things, make different kinds of descriptions, and combine them into various forms of arguments. Problem analysis will take you from identifying the level of the problem to the level of descriptions needed to solve it. However, most real-world problems are too complex to be handled with just these two levels. Another level is needed: structuring the problem as a collection of interacting subproblems. If the structuring is successful, the subproblems will be smaller and simpler than the original problem, and their interactions will be clear and understandable. Then you can analyze each subproblem independently (and they are simple problems themselves) and make the necessary descriptions. The central idea of this book is to use problem frameworks in problem analysis and structuring. They will help you by defining different categories of simple problems. When you structure a large, real-world problem, you can choose subproblems so that each subproblem is defined by a problem framework. Then, when you analyze a subproblem, you can look at what focus it introduces according to the appropriate problem framework. This framework shows what needs to be done to solve the problem. Problem frameworks define problems by capturing the characteristics and interconnections of the part of the world they involve, as well as the possible focuses and difficulties. So, problem frameworks help you focus on the problem rather than getting lost in imagining solutions. This is achieved by emphasizing the effects required outside the computer world, as well as the relationship between the real-world events and things that the customer ultimately judges to determine whether these effects have been achieved. Problem frameworks draw on many of the of design patterns. Design patterns delve deeply into computers and their software, while problem frameworks look outward to discover the world of problems. However, both identify and describe recurring scenarios, providing a terminology system where each increment of your experience and knowledge can find a suitable place in a larger framework and can be shared and accessed more effectively. In object-oriented design, if you are familiar with design patterns, you can say, "We need an instance of the decorator pattern here." Similarly, in problem decomposition, if you are familiar with problem frameworks, you can say, "This part of the problem is a artifact problem." If you can identify a problem as belonging to a known problem framework, you can leverage the experience related to that framework.
The idea of problem frameworks was first introduced in my book Software Requirements Specifications, where it was briefly mentioned as one of several related topics in the abstract. This book builds on that foundation, updating and discussing many basic and composite problem frameworks, as well as various styles and variations, and examining some of the focuses they introduce. Additionally, it examines and illustrates how to use problem frameworks when decomposing real-world problems into subproblems.
Focus Perspectives Some people argue that this perspective on software development problems is too focused and narrow. They point out that computer systems and software development itself are almost always embedded in a complex and variable social, political, ethical, and economic environment. When you discover the requirements for a system, you may become involved in the social negotiation process among conflicting project stakeholders. When you make a decision about the functionality of a system, you may lean toward one side. When you expand the scope of a system, you often give political rights to one group while imposing costs on another. When you analyze the purpose of a system, you explore its economic and organizational consequences. So, from this perspective, the main focus of software development is social and political, organizational and economic. It is not reasonable to consider these concerns in terms of problems. These concerns are indeed very important in many developments, but they are ignored in this book. We do not intend to discuss how to extract requirements, how to generate a business case, how to manage projects, how to convene meetings, or how to reach compromises. We ignore these things not because they are unimportant, but simply because they are not the subject of this book. If you want to understand something, you should not try to understand everything. Instead, we will try to understand some more focused ideas in problem structure and analysis within the broader context of software development. Our topic is the specific, observable effects that systems should bring to the world, the computer behavior that achieves these effects, and the relationships between them. In short, it is functional requirements, software specifications, and the path from functional requirements to software specifications.
Focusing on Problems Focusing on problems in software development is not an easy task. One reason is that some aspects of a problem are precise, while others are less so, and all of these draw your attention. Like Odysseus on his journey home from Troy, your voyage is plagued by the Sirens ahead and the whirlpool behind, and you must try to sail through the middle. Some people argue that our perspective on problems is too formal and narrow. If influenced by this argument, you might drift to the right, into the imprecise world of human problems—sociology and anthropology—where nothing is entirely certain or entirely accurate. That is an important world, but it ignores software and software development. However, if you think that the problem itself is less attractive than the software solutions for it, you might drift to the left, toward a more precise world of programming—variables, methods, and object classes—where Boolean values are either true or false, and never in between. Programming is also important, but without analyzing the problem and figuring out what the program must do, it is useless. In the problems discussed in this book, there are many precise and imprecise components, and we strive to balance the two to understand and analyze the problem.
Formalization and Informalization If you sail correctly between the Sirens and the whirlpool and successfully focus on the problem, your descriptions must sometimes be quite formal and sometimes quite informal. Formalization is certainly easy to observe. Some software developers consider themselves absolutely formal when they draw according to certain rules rather than imagination. Some believe that without relying on strict mathematical correctness, development is undoubtedly informal. Software development problems are about the real world, and systems must operate in the real world. Therefore, the degree of formality required in most of the work done in problem analysis depends on the degree of formality of the real-world problems being handled. It is of course good to be as precise and formal as the problem allows and as required by the task: why be vague when you can be precise? However, it is also very important to recognize that many things in the physical world cannot be described accurately, even in purely formal terms.
In the excellent book Engineering and the Mind's Eye, Eugene Ferguson laments that many engineering disasters occur because modern engineers focus too much on the calculation and formal analysis of structures and too little on the fact that structures are also part of the physical real world. He argues that the real problem in engineering education is the implicit acceptance of the view that advanced analytical courses are superior to encouraging students to develop an intuition for the uncomputable complexities of real-world engineering practices. Perhaps, as highly practical software developers, we should not feel guilty about paying too much attention to "advanced analytical courses," but we do spend a lot of time on essentially grammatical and conceptual techniques. This makes us like the engineers whose education is criticized by Ferguson, spending too little attention on the uncomputable complexities of the real world. Problems and requirements are in the world, not in the computer. They must be focused on directly and described cautiously.
Is There Really a Problem? Some people do not start by thinking about problems in software development for other reasons. They view each system and its environment as co-evolving and adjusting to each other. Installing and using a system (or even proposing to install and use one) leads to changes in the environment, which in turn affect the system's evolution in future versions. "Problem" is continuously modified from the moment it is proposed. The description of the problem is at best a snapshot of the problem at a moment when it will soon disappear. There is nothing like "requirement," if there is, it is useless. This is often used as a strong argument for incremental deployment and evolutionary development, and it may also be a good argument for trying to anticipate the effects of the system, calculate the changes it will bring to the environment, and consider these changes in system development. Designing a bridge to handle current and foreseeable traffic needs is not enough; you must also be able to handle the additional uncertain requirements that the bridge itself introduces. However, this is not a valid argument for rejecting the idea of starting with problems and requirements. When a computer system (or an incremental or evolutionary improvement to it) is installed and running, it will certainly have some specific behaviors determined by the software, and these behaviors will have effects and impacts in the problem world, some of which may be desired and others not. To capture requirements and structure and analyze problems is to do your best to determine what results are desired and to create software that can bring these results. It is to specify different results and different software for next year, which cannot be a reason for problems with this year's software. The correct way to deal with the uncertainty and variability of requirements is not to give up this task, but to work at a higher level of generality. One technique is to encode some functionality as an explicit description that the machine interprets when it executes, and then the user can modify this description to change the system's behavior. This technique for increasing generality belongs to the problem analysis methods discussed in this book: it uses a variant framework with a description domain. Of course, this also belongs to the common practice of design patterns, where it is represented by patterns with names such as reflection, metadata, or type objects.
What Method? The use of problem frameworks does not imply a specific development method. One reason is that different frameworks require different methods and use different concepts and notations. The idea that there is a magic bullet to solve many software development difficulties is now believed by few. But unfortunately, it still exists. Surprisingly, there are still people who claim to have a magic bullet for every problem and are designing and selling them, and they seem to be very popular. If a method could help with every problem, there would be no need to expect it to help much with a specific problem. Another reason why problem frameworks do not advocate a specific development method is that most widely used methods today are strongly solution-oriented. You need a solution-oriented method to help you arrive at solutions, but they provide very little help, and often they are pure obstacles, in structuring and analyzing problems. Problem frameworks and related ideas can serve as a front-end for all actions, or perhaps they can just clarify it. If you adopt these ideas, you should practice them gradually rather than changing everything at once. You may find that many of the concepts are just names for ideas and intuitions you already have, and naming them will make you more consciously think about and use them when needed. For some concepts that are new to you, they may bring a glimmer of hope to some areas where you have previously felt difficulties but never quite understood.
Structure of the Book The key idea of this book is to structure complex and real-world problems as a structure of simple subproblems that fit known problem frameworks. Therefore, the book mixes problems of all sizes. Some smaller problems may not have practical significance, especially those used to illustrate the most basic problem frameworks. But do not underestimate the problems that do not have practical significance. They present the essence of problem categories in the most direct form, making it easier to recognize them when they appear under larger problems. The problems in this book are not presented in ascending order of size and complexity, although that would be reasonable and concise, but it would make the book less readable. Larger and smaller problems are interwoven, and different aspects of each problem are discussed where they appear to be relevant and provide a good example for the current argument. Some themes (such as descriptive languages and notations) run throughout the book, and the various aspects of these themes are introduced when they appear. This informal structure is supplemented by two appendices: one summarizes the descriptive languages and notations used, and the other provides a glossary, as well as a unified list of references.
Is This Book for You? We hope this book will benefit teachers, students, and practitioners in the fields of system analysis, system specification, and software and requirements engineering, as well as anyone interested in the concepts and smart tools of software development. This book is not a textbook, but it can be used as a supplementary text for some software development courses.