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

Author: Software Development Problem Framework: Structured Analysis of Real-World Problems
Publisher:
Publish Date: 2005-02-01
Features: ProblemFrames: Analyzing and Structuring Software Development Problems by Michael Jackson
Features of the Book:
· Analyzes numerous 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.
· ProblemFrames are independent of any specific development methodology, making it easy to apply them to specific environments.
This book helps:
· Break down complex problems into simpler subproblems and discuss how to combine them.
· Establish a simple, clear, and reusable library of problem categories 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 covers both large and small problems, revealing the hierarchical nature of problem categories and discussing different aspects of each problem. This book is suitable for teachers, students, and practitioners in the fields of systems analysis, system specification, software engineering, 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, 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
When dealing with software development problems, people often hastily start considering their solutions. However, software development problems involve the world outside of computers (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 perspectives: 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 considers requirements as the conditions or capabilities possessed by a system or its components to satisfy 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 views reflect certain levels of the characteristics of software requirements. However, is this level of understanding of requirements sufficient? I believe most people would answer negatively. Because if we take 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 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 the meaning of requirements to the description of the environment is a consistent viewpoint of the author, Michael Jackson. This perspective dates 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 goals, i.e., environment, software requirements. This viewpoint is currently gaining increasing attention in the international requirements engineering community, offering a fresh perspective on the 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 interaction? The author believes that the real-world problems that software can address are the true meaning of software requirements, and structuring them is 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. 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, variations and special considerations of different problem frames, the combination of problems, and the incremental software development process, revealing the fundamental patterns of real-world problems that software can solve.
It should be noted that when the translator began translating this book, they were also new to this entirely fresh idea. Although they read many other related 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 their understanding of this topic and the urgency of time, there may be some translation inaccuracies. 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 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 with 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 automotive speed, 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 typically start the software development process by describing and structuring the problem in a way rarely needed in other engineering disciplines, where the problems to be solved are much more stable. 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 it and many other similar 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 behaviors and characteristics must the computer have for this purpose? Often, software development seems to start from scratch.
Problem Frames When analyzing a problem, you need to identify what kind of problem it is and pinpoint the focus points and difficulties to be addressed. The focus points in a Java compiler will be completely different from those in a car braking system. You will need 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 structured successfully, the subproblems will be smaller and simpler, and their interactions will be clear and understandable. Then you can analyze each subproblem independently (and they are simple problems themselves) and create 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 structuring a large, real-world problem, you can choose subproblems such that each subproblem is defined by a problem frame. Then, when analyzing a subproblem, you can look at what focus points it introduces according to the appropriate problem frame. 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 potential focus points and difficulties. Therefore, problem frames help you focus on the problem rather than getting lost in imagining solutions. By emphasizing the effects required outside the computer world, as well as the relationship between the real-world things and events that customers ultimately judge as whether these 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, both identify and describe recurring scenarios, providing a terminology system where each increment of your experience and knowledge can be placed in a larger framework and shared and accessed more effectively. In object-oriented design, if you are familiar with design patterns, you might say, "We need an instance of the decorator pattern here." Similarly, in problem decomposition, if you are familiar with problem frames, you might 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 illustrating many basic and composite problem frames, as well as various styles and variations, and exploring some of the focus points they introduce. Additionally, it examines and illustrates how to use problem frames when decomposing real-world problems into subproblems.
Perspective of Focus Some people argue that this perspective on software development problems is too narrow and focused. They point out that computer systems and software development themselves 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 stakeholder groups. When you make a decision about the system's functionality, you may lean toward one side. When you expand the system's scope, you may be giving political rights to one group while imposing costs on another. When you analyze the system's purpose, you are exploring 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 focus points in terms of problems. These focus points 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 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 fraught with the Sirens ahead and the whirlpools behind, and you must try to navigate through the middle. Some people argue that our perspective on problems is too formal and narrow. If influenced by this argument, you might stray 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 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, with no middle ground. Programming is 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 them 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 of course easily observable. Some software developers consider themselves absolutely formal when they draw according to certain rules rather than imagination. Others believe that without relying on rigorous mathematical proofs, 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 formality of the real-world problems being handled. It is naturally better to be as precise and formal as the problem allows and requires: why be vague when you can be precise? However, it is also 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 part of the real-world engineering practice that is irreducibly complex. He argues that engineering education implicitly accepts the view that advanced analytical courses are superior to encouraging students to develop an intuition for the irreducibly complex complexities of real-world engineering practice. Perhaps as highly practical software developers, we will not feel guilty about paying too much attention to "advanced analytical courses," but we do spend a lot of attention on essentially grammatical and conceptual techniques. This makes us like the engineers whose education was criticized by Ferguson, spending too little attention on the irreducibly complex 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 (or even proposing to install and use one) leads to changes in the environment, which in turn affect the system in its future versions. "The 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 "requirements," 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 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 response to the uncertainty and variability of requirements is not to abandon 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 common practices in design patterns, where it is represented by patterns with names such as reflection, metadata, or type objects.
What Method? The use of problem frames does not imply a specific development methodology. One reason is that different frames 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 actually claim to have a magic bullet for every problem, and they are designing and selling it, and it seems to be quite 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 methodology is that most widely used methods today are strongly solution-oriented. You need a solution-oriented method to help derive solutions, but they offer little help and can often be an 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 or suggest how to extend or modify practices. 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 areas where you have previously found difficulties but never fully understood.
Structure of the Book The key idea of this book is to decompose complex and real-world problems into structures of simple subproblems that fit known problem frames, so there are problems of all sizes. Some smaller problems may not have practical significance, especially those used to illustrate the basic problem frames. But do not underestimate the problems that lack practical significance; they progressively reveal the essence of problem categories in the most 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. This book is suitable for teachers, students, and practitioners in the fields of systems analysis, system specification, software engineering, 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 supplementary material for some software development courses.