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

Author: (English) Jackson (Jackson, M.) wrote, Jin Zhi translated
Publisher:
Publishing Date: 2005-02-01
Features: ProblemFrames: Analyzing and Structuring Software Development Problems Michael Jackson
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 discuss different aspects of each problem. · Problem frames are independent of any specific development methodology, so they can be easily applied to specific environments. This book helps: · Break down complex problems into simple subproblems and discuss how to combine these subproblems. · Establish a simple, clear, and easy-to-use problem category repository that can be accessed and reused to derive experience related to each category. This book analyzes many real-world example problems and explains how to identify and structure problems in practice. It provides both big and small problems, revealing the hierarchical nature of problem categories, and discusses different aspects of each problem. This book is suitable for 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 intelligent tools of software development. "Understanding and using problem frames is likely to become a fundamental skill for all software system designers," Jackson's book provides an excellent pathway into this field. "--David Garlan, Professor of Computer Science at Carnegie Mellon University" I believe that Michael Jackson has absorbed the essence of many design patterns in this book and constructed a more accessible technique for utilizing the framework metaphor. "--Warren Keuffel, Senior Editor of the Software Development magazine
When dealing with software development problems, people often hastily start considering their solutions. However, software development problems involve the world outside the computer (i.e., the real environment in which the system operates), so it is necessary to consider the characteristics, relationships, and context of the surrounding environment. Problem frames are a tool for classifying, analyzing, and structuring such software development problems. Object-oriented patterns primarily focus on solutions, while problem frames focus on the problems themselves, enabling you to clearly and directly understand and solve them.
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 required 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 satisfy a contract, standard, specification, or other form of document. The collection of all requirements forms the basis for the 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 this understanding of requirements sufficient? I believe most people would answer negatively. Because if we use them as definitions of requirements, when faced with the real world, ready to capture, seize, and describe requirements, we are still lost. We often ask: In the real world, there are so many diverse things to do, and so many different problems to solve. Which are the problems that software can solve? Which are the issues we must 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 the meaning of requirements to the description of the environment is a consistent viewpoint of the author, Michael Jackson. This viewpoint can be traced back to an article he published in the Annals of Software Engineering in 1997, where he first introduced the environment in which software operates. The relationship between software requirements and goals in this environment, i.e., environment, software requirements. This viewpoint is currently gaining increasing attention in the international requirements engineering community, offering a fresh perspective on the connotation of requirements. What kind of environment can software act upon? What changes can software bring to the environment when it acts upon it? What are the characteristics of this action? 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 solutions to these problems in practical scenarios. It starts by focusing on and locating real-world problems, then moves on to the decomposition of real-world problems, the focus and style of problem frames, various variants and special considerations of problem frames, the combination of problems, and the incremental software development process, revealing the basic real-world problem patterns that software can solve.
It should be noted that when the translator began translating this book, they were also exposed to this entirely new idea for the first time. Although they read many other relevant materials written by the author in recent years and had in-depth discussions with the author on some issues, due to the depth of their understanding of this issue and the urgency of time, there may be some inappropriate translations, and we sincerely ask the readers to point them out. Spring 2004, Beijing.
Michael Jackson has over 40 years of experience in the software development field. 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 in 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 certain 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 car speeds, 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. Because the variations in problems to be solved are much smaller in other engineering disciplines. 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 10 tons, or whether it can move backward at 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 usually have to start by asking: What kind of problem is this? What is this problem exactly? 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 look at what kind of problem it is and identify 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 large and 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 themselves are simple problems) and make the necessary descriptions. The central idea of this book is to use problem frames 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 frame. Then, when you analyze a subproblem, you can look at what focus it introduces according to the appropriate problem frame for it. This frame shows what needs to be done to solve the problem. Problem frames 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 frames help you focus on the problem rather than getting lost in thinking about solutions. By emphasizing the effects needed outside the computer world, as well as the relationship between the real-world things and events that the customer ultimately judges whether the effects have been achieved, problem frames achieve this. Problem frames draw on many of the of design patterns. Design patterns delve deeply into computers and their software, while problem frames look outward to discover the world of problems. However, they both identify and describe recurring scenarios, providing a terminology system where each increase in your experience and knowledge can find its 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 frames, you can say, "This part of the problem is a artifact problem." If you can identify a problem as belonging to a known problem frame, you can leverage the experience related to that frame. The idea of problem frames was first published in my book Software Requirements Specifications, where it was briefly introduced as one of several related topics in the abstract. This book builds on that foundation, discussing and explaining many basic and composite problem frames, as well as many styles and variants, and examining some of the focuses they introduce. Additionally, it examines and explains how to use problem frames when decomposing real-world problems into subproblems.
Focus of Perspective Some people believe 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 complex and variable social, political, ethical, and economic environments. 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 the system, you may lean toward one side more than another. When you expand the scope of the system, you often give political rights to one group while imposing costs on another. When you analyze the purpose of the system, you explore its economic and organizational consequences. Therefore, from this perspective, the main focus of software development is social and political, organizational and economic, and it is not reasonable to consider these focuses in terms of problems. These focuses 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 thoughts in problem structure and analysis within the broader context of software development. Our topic is the specific, observable effects that the system 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 easy. One reason is that some aspects of the 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 in front and the whirlpools behind, and you must try to navigate through the middle. Some people believe that our perspective on problems is too formal and narrow. If influenced by this argument, you may stray to the right, into the imprecise world of human problems—sociology and anthropology—where nothing is entirely certain or accurate. That is an important world, but it ignores software and software development. However, if you believe that the problem itself is less attractive than its software solution, you may stray to the left, toward the more precise world of programming—variables, methods, and object classes—where Boolean values are either true or false, never in between. Programming is also important, but without analyzing the problem and deducing 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 navigate correctly between the Sirens and the whirlpools 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, much of the formalization in problem analysis depends on the degree of formalization of the real-world problems being handled. It is, of course, good to be as precise and formal as the problem allows and requires: 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 complains that many engineering disasters occur because modern engineers pay too much attention to the calculation and formal analysis of structures and too little attention to the part of the physical reality that structures are a part of. He argues that the real problem in engineering education is implicitly accepting the view that high-level analytical courses are better than encouraging students to develop an intuition for the incomputable complexities of real-world engineering practices. Perhaps, as highly practical software developers, we will not feel guilty about paying too much attention to "high-level analytical courses," but we do spend a lot of attention on essentially grammatical and conceptual techniques. This makes us like the engineers whose education process is criticized by Ferguson, spending too little attention on the incomputable 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 thinking about software development from the perspective of problems for other reasons. They view each system and its environment as co-evolving and adjusting to each other. Installing and using a system (even proposing to install and use one) leads to changes in the environment, which in turn affect the system in its future versions. "Problem" is continuously modified from the moment it is proposed, and 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 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 of it) is installed and running, it will certainly have specific behaviors determined by the software, and these behaviors will have effects and impacts in the problem world, some of which may be desired or undesired. 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 of the descriptive domain framework. 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 Problem frames do 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 rarely believed. But unfortunately, it still exists. Surprisingly, there are still people who claim to have a magic bullet for every problem, and they are still designing and selling, 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 frames do not promote a specific development method is that most widely used methods today are strongly solution-oriented. You need a solution-oriented method to help derive solutions, but they provide little help and are often a pure obstacle in structuring and analyzing problems. Problem frames and related ideas can serve as a front-end for all actions, or perhaps just to clarify it. If you adopt these ideas, you should proceed gradually rather than making a complete change overnight. 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 conscious of using 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 decompose complex and real-world problems into structures composed of simple subproblems that fit known problem frames. Therefore, the book mixes problems of all sizes. Some smaller problems may not be practically meaningful, especially those used to illustrate the basic problem frames. But do not underestimate the problems that are not practically meaningful. They gradually reveal the essence of problem categories in a direct form, making it easier to identify 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 are 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, another provides a glossary, and there is also 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 intelligent tools of software development. This book is not a textbook, but it can be used as a supplementary text for some software development courses.