OOA & D practical path -- Analysis of real cases oo Theories and Practices (III. Risk reduction)

Risks everywhere
In the previous article, we wrote a list of features. Then, can I analyze the requirements? Unfortunately, we still have a lot of work to do. The first thing after getting the feature list is to minimize risks. Here we will not give a long story about how risks are going. We will first discuss how to reduce risks.

Dry
Here, we first need to introduce an OO principle-dry.

Dry principle, full name: Don't repeat yourself, refers to: in the system, each piece of information or behavior fragment should only exist in one copy and exist in a suitable place.

Many people think of this principle as "do not duplicate code", which is a one-sided understanding. In fact, oo is not just about how to write good code, but about how to develop good software. Therefore, many oo principles are not just code-level principles, but can be applied to the entire development process. Next we will focus on the deep significance of this principle and discuss its application in risk reduction.

How to Use dry to Reduce Risks
Among all the development risks, there is a risk that the same information or behavior segment is scattered in different places of the system, resulting in repetitive work and hidden risks for modification and maintenance.
The following describes two adverse consequences through examples.
1. repetitive work
For example, in the feature list, if the two features are a feature, they are mistaken for two different features. All feature-based analysis and design are repetitive, that is, the same feature is analyzed and designed twice until repeated results are found. This cost is huge.
2. Modify and maintain hidden risks
For example, a code segment is similar but appears in many places of the program. These similar code segments must have identical functions, so they have the "same generation and elimination" feature, that is, if a code segment needs to be modified, in general, all repeated codes of this Code must be modified. This poses a great risk to maintenance.

The dry principle is a solution to this risk. For the application of dry in the code, let's put it down now. Here we only look at its application in the feature list arrangement. Obviously, according to the dry principle, features in the feature list must not be repeated, so let's take a closer look at our feature list:

1. Various raw material information can be published to the system.
2. franchisees and chain stores can determine materials online through the system
3. franchisees and chain stores register through the Internet. The system can be officially used only after the head of the general store reviews the system.
4. The system requires an administrator who can manage the system.
5. Use the shopping cart function to set online materials
6. After the completion of the set material, generate a set material order and print it

After careful inspection, it is not difficult to find that 2 and 5 are actually describing a feature, so we combine 2 and 5 into a new feature: the shopping cart function can be used by franchisees and chain stores to determine online materials. In addition, it can be seen that "Head of the store" and "Administrator" are actually a concept. After finishing the sorting, we will get a list of the following new features:

1. Various raw material information can be published to the system.
2. franchisees and chain stores can use the shopping cart function to set materials online.
3. The franchisee and chain stores register through the network. The system can be officially used only after the Administrator reviews the system.
4. The system requires an administrator who can manage the system.
5. Generate a bill after the completion of the plan and print it.

Check carefully and there are no repeated features. In this way, we use the dry principle to avoid the first risk: the risk of repetitive work. The following is a definition of this risk:
Repetitive Labor Risks: this refers to the analysis and design process for the same feature more than once due to the existence of repeated features. In the end, resources are wasted and development efficiency is reduced, which may lead to delayed delivery.

Knowing is unknown
After using dry to sort out the feature list, the next step is to avoid the second risk: fuzzy concept.

Fuzzy conceptual risks: developers are not familiar with a certain field of knowledge, but take a certain concept for granted, and then analyze and design it based on the results taken for granted. If an incorrect idea occurs, the system may fail to work properly or fulfill the purpose of the business, resulting in rework or project failure.

Obviously, developers are generally not business experts. Therefore, it is normal that you are not familiar with business in the field. As a qualified developer, you should be cautious about the concept of unfamiliar business by following the teachings of Kong's "knowing what you know, not knowing what you do not know, rather than simply imagining it. The correct method is to first examine the feature list and consult a domain expert or customer for unfamiliar or inaccurate concepts. Next we will continue to use our project as an example.
After analyzing the feature list, we can find out the following questions or fuzzy concepts:
1. Raw Materials (What are the raw materials and need to be classified ?)
2. What are the differences between franchisees and chain stores? Is the scheduling business process the same ?)
With two questions, we visited the customer again. We will not talk about the specific conversation, and finally we get the following results.
1. The raw materials are mainly cooking ingredients that need to be kept confidential, such as fried powder and spices. They are not very special and do not need to be classified.
2. The franchisee and chain store are not a concept. The franchisee is directly affiliated to the company, and the chain store may be directly affiliated to a franchisee. The franchisee and the chain stores of the directly affiliated company determine materials directly from the company, and the chain stores that are not directly affiliated receive raw materials from the corresponding franchisees. The chain stores are priced based on the original price, and the franchisees are classified into 5 levels, with different discounts for each level.
After some understanding above, we have basically clarified the fuzzy concept, and after such understanding, our feature list will change accordingly:

1. Various raw material information can be published to the system.
2. franchisees and chain stores can use the shopping cart function to set materials online.
3. The franchisee and chain stores register through the network. The system can be officially used only after the Administrator reviews the system.
4. The system requires an administrator who can manage the system.
5. Generate a bill after the completion of the plan and print it.
6. The direct chain stores are priced based on the original price, and the franchisees are divided into 5 levels by level, with different discounts for each level

We think that the franchisee level and discount are very important features, so we added them to the feature list.

Ensure that we can implement
We have already avoided two risks. Now let's look at a risk. For example, if a architect designs a new villa with a seasonal adjustment device in the yard, you can adjust the season in the yard to any season in spring, summer, and autumn. What do you think of this feature? Cool idea, right? But if you are a villa customer, do you think so? I don't think you will be excited with the designer for this cool feature. You will first ask the designer how to implement this feature. Yes, it is great to adjust the courtyard for the season. Don't forget that our villa will eventually be built in reality, and there will always be many constraints that won't make every idea a reality.
Same as above. No matter how messy things we designed, coding is ultimately required. Therefore, we must ensure that all features have solutions at the encoding level. Even if we don't know the exact solution right away, we need to know how to implement it. This leads to the third risk:

Implementation capability risks: risks that cannot be solved by specific technologies due to a specific feature. This risk includes two levels. First, the existing technology cannot be completely solved. The second reason is that the development team has no solution. This risk may lead to project delays or even failures.

To avoid such risks, we need to review one by one whether our features can be addressed within the existing technical scope. After careful review, there should be no problem at the first level, and all the six features can be addressed within the existing technology. However, for Feature 2, we have some problems. Because we didn't have any experience in designing a shopping cart at the time, and we suddenly didn't know how to implement it.
To solve this problem, we need to do the following. Note that we may discuss many details here, but we should avoid entering details in advance. Therefore, all the details discussed here do not need to be analyzed or designed. Instead, they only have a great spectrum through brainstorming. This "spectrum" is often very different from the final implementation, but at least we know that this feature can be implemented in some way.
In the event of such risks, the first thing to do is to find relevant information. After searching for some information, we learned that the shopping cart is generally divided into session implementation mode and database implementation mode. These two methods have different features. The former supports online shopping and does not store customers' shopping information. Then, you must log on to the ECS console before you can shop. This involves the interests of the customer, so it is up to the customer to decide.
So we asked the customer, and we got a reply: "You must be able to fix the issue when you are not logged on, and you must keep the issue information ." This sentence is a bit vague, but generally we can understand what the customer means, so we rewrite it into the following paragraph: "Unlogged users can use the shopping cart, but cannot make a ticket, you can only place an order after logging on. Login users can keep information in the shopping cart ." We showed it to the customer and described it. The customer agreed with the decision.
After confirming this, we will discuss the specific solution. I would like to explain again here that the discussion below is not about analysis or design, but just to make us clearer about the difficult problems, so we have a good idea, do not know how to implement it.
After some discussion, we all agree that the solution is "non-logged-on users use session to process shopping cart, and login users use databases to store shopping information. When a user logs on, if there is shopping information in the session, the information in the session is transferred to the database ."
This discussion ends. Because we don't need to be too precise, we just need to have a rough spectrum in our hearts.

Summary
1. After the feature list is complete, we should first reduce the risk, rather than conduct analysis or design.
2. duplicate features are at risk. You can use the dry principle.
3. There are risks in the characteristics of vague concepts. Ask the customer carefully.

4. There is a risk that you do not know how to implement the features. Make sure that you have a rough idea about how each feature is implemented, but you do not need to be accurate.

Zhang Yang http://www.cnblogs.com/leoo2sk/archive/2008/12/11/1352021.html