Meet user expectations-head first OOA & D Reading Notes (2)

Part 1:Software Development Process Overview-Head first OOA & DReading Notes(1)

In the first part(Http://www.cnblogs.com/lihongchao/archive/2008/01/12/1036586.html), Briefly introduces a typical process of software development, that is, the so-called lifecycle. to build a software project, all the steps here are essential, not to say that these steps are indispensable, but the specific work contained in them will certainly be taken into account, either intentionally or unintentionally. in other words, to be able to complete the project well, simply focusing on these general steps will certainly not work, the key to determining the success or failure of a project is whether the work we do in each step can provide accurate and sufficient information and data for the next step. When we try to analyze a project (if you still have this opportunity), you may find that the problem is not due to a missing step, but a certain step is not doing well enough, or is wrong. For example, the requirements described in the Requirement Description document are not correct, the design document is unreasonable, the fixbug is too hasty, and the unit test is in the form. Remember to read a copy calledMan pieceAs mentioned in the book, "there is no plan too well to have a wrong plan ". A wrong plan will paralyze a team and make everyone think that the plan is reasonable and follows the wrong plan, so that it will lead the development of the project to the end of failure. Therefore, we must first ensure that our work is based on a correct understanding and moving in the right direction to achieve the expected results. First, we will discuss how to correctly take the first step and collect and analyze requirements.

Each project implements requirement management. The ultimate goal is to express the real needs of the project in a concise and accurate manner. Then, the requirements can be easily changed to computer languages. How can we achieve this arduous goal? Different projects have different features. The methods used to solve the demand problem are critical to the entire development process. The most significant difference is that the development process adopted by the project is waterfall, iterative, or scrum. In fact, the requirement is a key factor that determines the development process. Our goal isDevelop software that meets user expectations. So we need to know the user's expectations. What should we do first?

1.Vision,Conversation,Feature list (vision, Discussion & feature list))

Let's not talk about what we need to do first, but think about how a new project starts. The beginning of most projects is very hasty. Leaders, users, or other people who can instruct you will give you a piece of so-called demand document, there may also be hundreds of documents, but the valuable content is generally one or two pieces of paper, which is not better than the example in the book.

Figure 1 vision

is this required? Neither is it. It can only be said that it is an incomplete requirement. In fact, this is only the user's vision , that is, it only describes some fragmented and exciting functions, the usage details of these functions are not described enough. Let's develop a system based on this. It is definitely impossible to start. Before we fully understand the problem, we should minimize the number of subsequent work. For example, when the requirement design is unclear, try to drag the time to start writing Code , because once you start building a system, it means that it will take a lot of money to make any changes. So what can we do to make the demand clearer? communication ! Not only at the beginning of the project, but throughout the development process, customer participation is a key factor for project success. However, in the initial stage of the project, the communication method is relatively simple. Generally, the communication mode is to communicate with the customer face-to-face with paper and pen, and record the customer's various expressed information as much as possible. For customers who are not very mature, it is difficult for us to deepen this conversation, because it is not easy for users to imagine what the system they need. Sometimes, you need to use some tools to inspire customers, existing systems, and archived documents. A common method to obtain deep-level requirements is to construct a prototype (prototype), to allow users to be specific, in this way, we can find more detailed requirements. It should be noted that the prototype is constructed to clarify our needs and has no other effect. When requirements come to an end, the prototype should be discarded. In other words, the prototype is a product that will eventually be deprecated. Therefore, the focus of prototype development is to quickly and accurately "implement" some of the requirements we understand for users to judge. The prototype development technology is completely different from that of the system development in the future. For example, many companies now use Ruby to build a web prototype and then use DOTNET or Java to develop the system.

If some requirements are abstract and difficult to describe, we can take some insights, suchSame-sex analysis (Commonality and Variability)That is, to describe what the system is. There are similar systems with similar functions, similar services, and even similar interfaces. We also need to know which system is not, which does not include any functions and does not need to consider any factors. In this way, the scope required by the system is well defined.

After the conversation, we need to confirm all the requirements with the user and archive them after they are correct. It is best to classify them in a certain way for future reference. How can we use so many complicated demands? This is a technical problem. In fact, at this stage, we only need to identify the most important part, that is to say, if our system does not implement these functions, our system will not be able to realize its value. We should remember that we should do our best to let the details back to the end, otherwise we will encounter difficulties in the overall analysis. Other requirements are also very important, but the bid value can only be reflected in future work, such as twoProgramWhen the personnel disagree about the function implementation, we can find relevant records in these requirement records to get the correct solution. Currently, we can get a list of functions, which can be sorted by priority and dependency order, supplemented by a brief introduction. This function list should be expressed in words familiar to the customer, and then confirm that this is what the user wants. If this can be done accurately, it will be a very successful preliminary work. Note thatFunction(Feature)AndRequirement(Requirement)There is no clear difference. It is generally considered that a function is more abstract. Generally, a function is covered to meet multiple requirements. You can also abstract the function, it is still called a requirement, just like.

Figure 2 feature list sample

The function list is only a description of the system, indicating which functions the system must have. Another point is how users can use the system.Use case diagram (Use Case digoal),The two documents are compared to each other to ensure that we have complete requirements.

2.Real world)

Our software will eventually be used in the real environment, and will not always run on our development and testing machines. Our operations are far richer than our test cases. Therefore, when collecting requirements, we need to make sufficient consideration for some situations in the real environment. For example, different users' operation habits, users' network conditions, and users' knowledge levels. To a large extent, we use the imagination and Simulation of actual scenarios to find out the special situations we need to deal with. The probability of these special situations is generally not high, however, the system stability and customer impressions are very important. Only by predicting and solving possible situations in actual scenarios can users be satisfied from the perspective of customers rather than developers. For example, if you delete an email in Gmail, a prompt is displayed at the top.

Figure 3 undo Option

This gives users the opportunity to undo their operations, so that they will be very happy when necessary, and they will think that the system is really what they think. If this function is not available, developers can fully push irrecoverable responsibilities to users, which is caused by user operation errors and deleted by mistake. Such an explanation may have the upper hand in mutual criticism, but in the end it does not satisfy the product users really want. Therefore, when collecting requirements, system analysis, coding, and testing, we must consider that our products will eventually be installed on the client server and used by real users. Therefore, we should try our best to place ourselves in the user's perspective and consider our needs, design and development systems in real scenarios. Generally, this part of requirements is easy to ignore, because they take it for granted, and developers do not know it.

3.Problem break up & use case)

Based on the classification of end users, the different scenarios in which the system is used, and the list of system functions, we can split the entire system into logical modules, split a system into multiple small systems. The splitting here is only based on different use cases. The purpose of splitting is to make the processes used by the system and the goals to be achieved in each scenario relatively simple, easy to analyze.

For every scenario where the system is used, we must carefully learn and understand the requirements to ensure that we have the correct requirements. Then you can describe this requirement in detail. Complete operations for each user are a combination of operations that are independent of each other using the system to achieve a valuable goal. For example, I need to use an ATM to withdraw money, and I need to use a mobile phone to send text messages. These individual application scenarios are:Use Cases(Usecase), Also known as story, basically refers to the same thing. By sorting out all the combinations of valuable operations that the system can satisfy the user's needs, we will get a list of system use cases. Generally speaking, the system we developed can help users achieve these goals and achieve the expected results, even if we deliver a successful system. The feature of this use case list is that we do not use any technical vocabulary to express the needs through text and graphics, so users can understand it accurately. In this way, we can confirm that all the things the user needs to do are covered in this list. A more vivid representation is to draw an example (as shown below ).

Figure 4 example

The use case diagram is a blueprint of our system (blueprint), which vividly describes what our system can do for users. The villain in the figure refers to the user (the user is not necessarily a person or another system), and the ellipse in the figure refers, A set of user operations to be implemented in the system. Let's call this EllipseUse Cases(Use Case). The use case describes a series of operations performed by the system to achieve a target for the user. A complete Use Case must contain three elements. First, the use case must have clear values. Second, use cases must have the start and end points. Third, use cases must be triggered by external entities. A use case often reflects the sequence of multiple executions. Generally, there is a main execution path and several secondary execution paths. The secondary execution path is used only under certain conditions. The execution sequence is calledScenario(Scenario)These scenarios all achieve the same goal, that is, the value of this case. When using use cases to describe the requirements, we must ensure that we have understood the requirements and need to communicate with users to avoid independent use case development without confirmation from users. Use Cases can be described in many ways, but the purpose is to make the user's use of the system as comprehensive and concise as possible.

Text description, which is easy to read and understand, but difficult to express the loop and logic branch scenarios.

Figure 5 Use Case sample

The Chart Method description case can clearly describe the sequence of system operations and various condition judgments.

Figure 6 sequence dimo-sample

When we describe all the requirements as use cases in a certain form, we will find some hidden, we do not pay attention to, or the user did not tell us the requirements. Therefore, one of the values of use cases is to help us discover and manage user needs and easily communicate with users. The use cases are also related to the function list. Our use cases must cover all the records in the function list. In this way, the function list we get through talking to the customer can help us verify whether the use cases are complete. In practice, hidden use cases are often not discovered. On the contrary, not all functions in our function list can find a corresponding use case to use this function. This is because the use case describes how the system is used, there is no clear representation of the call relationship within the system. We can see that the use cases and functions are coordinated, but they are not the same thing.

There is a development method calledScenario-driven development(Scenario driven developing),As the name implies, a scenario is locked for development at a time so that the system can successfully perform these operations. After the system implements this scenario, it selects another scenario for implementation. After all the scenarios are implemented, the development will be completed. It is also called case-driven development. It can be seen that the focus of scenario-driven development is the user's needs, and it is the problem behind the implementation of each function for the user. This starting point is very important. Otherwise, despite the implementation of many cool functions, the interface is also very beautiful. In the end, we can find that users do not like it, and there is no value.

Another development method is calledFunction-Driven Development (Feature driven developing),That is, by dividing the functions in the function list (break down), selecting a function point for development, and finding out all the places where this function is used in the system, implement this function to meet all potential requirements. Then implement another function, and so on, and implement all the functions to implement the entire system.

There are no advantages or disadvantages between the two development methods. There are only different application scenarios. Generally, the scenario-driven granularity is relatively large, and the function-driven granularity is relatively small. That is to say, the number of scenarios in which a system is decomposed is much smaller than the number of functions in which the system is decomposed. If we compare software development to painting, and develop a scenario like drawing a complete line segment, we will continue to implement various scenarios, and there will be more and more lines on the screen. A function is more like a point, and the number of points on the canvas increases constantly, forming a complete picture.

4.Domain Analysis)

With the complete Use Case, we can perform domain analysis, that is, through the study of existing systems and usage history, based on the potential knowledge and technology in the business scenario, the process of collecting, identifying, and displaying relevant knowledge and information is often carried out with the participation of field experts. Because the focus of this process is to accurately understand the current business logic and related business knowledge of the user, it is very necessary for the user to intervene. Therefore, we need to describe our system in a language that users can understand. I often see people who don't understand anything. I asked the customer what they needed by showing some UML class diagrams, modules, and even code to the customer, isn't it self-defeating.

The purpose of the analysis is to divide the system into modules based on user knowledge. This module division actually changes the system from the user's perspective to the developer's perspective. Users only know the functional points and requirements one by one. Developers need to know how our system modules, databases are organized, how business logic is encapsulated, how the user interface is displayed, and how system exceptions are handled. After field analysis, we will basically determine a system architecture model, which is a three-tier architecture, MVC, and so on. We may even have some ideas on the implementation of some specific functions, for example, which design mode is used to solve the problem. Which system architecture is used is based on the analysis of these requirements and use cases, rather than blindly pursuing the trend. In other words, the purpose of dividing the system into modules is to break down a complex system into multiple simple systems and implement these simple systems one by one, finally, we will find that this complicated system is complete. The principles of dividing modules are similar to those of our system design or OO design. They all divide the requirements of the same attributes and similar behaviors into the same modules, minimize the relationship between modules and reduce the dependency between modules.

For small modules, we can easily use object-oriented analysis and design methods. Taking the example in Figure 5 as an example, we first find the nouns in the text, which can be regarded as potential classes or objects. Of course, it cannot be too rigid. Some nouns are not in the system, such as actor, and some nouns do not need to be separated. Analyze the verb again. These verbs are the potential methods or attributes of the entity class represented by the subject. Then, we use some oo principles to improve the analysis results and isolate and encapsulate the changes. Abstract The Interaction part into an interface. In the end, an important design product will be generated.Class Diagram (Class digoal),In the next article, I will explain in detail the principles and methods of these oo analysis and design.

Figure 7 class digoal

5.Iteration (Iteration)

From the above, we can see that by analyzing, designing, coding, testing, and integrating small modules, we can finally complete the development of the entire system. We can divide different modules into several iterations for development, so that we can complete an iteration in a short period of time, and there is a basic usable System for user testing. Make sure that our design and implementation are the real needs of users, and then perform the second iteration. When there is any deviation from the user's ideas, you can also communicate as early as possible to adjust the system. In this way, you can gradually make the requirements clearer and meet the needs of users at a small cost. Those modules are placed in the first iteration, and those that can be put behind the implementation are also exquisite. Under normal circumstances, we should focus on which modules have the greatest risk, our vague understanding, and the greatest impact on the entire system. We should first solve these modules. Our goal is to continuously reduce uncertainty and development risks. In the following sections, I will introduce in detail how to use oo analysis to gradually convert these inaccurate requirements into specific classes that can be operated.

Finally, leave a job. We will discuss the disadvantages of adopting this iterative development method and the more popular agile development? How can this problem be solved? It is related to the user.