Pain-free software maintenance-forgotten needs

Let's start with a joke. There was a production team leader who said to the experts: "Now we are growing more and more production teams, and Niu is getting increasingly busy. I want this kind of ox. He eats as much grass as a normal ox, but does ten times as much work as a normal ox ." Experts said: "This kind of ox can be made, and now there is genetic engineering ." The captain said, "Well, you have made some of these cows ." So the experts found the biological laboratory and asked the people in the biological laboratory to create a genetic project and create the cattle. As a result, the project is huge and investment cannot be guaranteed. Cooperation is mostly unpleasant.

In the real world, the process of analyzing requirements is similar to that of this expert. They focus on the functional points proposed by users, but are not interested in the actual needs of users. There are many software companies andProgramPersonnel are actually doing similar genetic engineering. If this expert focuses on the business needs of the production team leader rather than the features he has proposed, he will say, "I know a tractor seller. You can take a look at it ."

One important reason why software maintenance is so painful is that the demand has been forgotten.

Demand is an activity that has direct commercial value to users and should not involve any function implementation methods. Multiple solutions can be used to implement the same requirement. Each solution has its own functional method. The crucial functional points in a solution may be irrelevant in another solution.

In the waterfall development process, a group of experts who know the user's business will first investigate the user's needs and find out what functions the system should have, form a very important document-xxx System Requirement Specification. The customer approves this manual, signs and seals it, and adds the contract accessories. The project acceptance will be subject to this. At this time, the demand has been divided into functional points, and from this time on, the demand itself is gradually forgotten. Designers work around these functional points and consider the technical means used to create the functional points. The production details of Function Points form another important document, "XXX project design specification". This design specification is handed over to programmers for coding.

This practice has already formed a big problem in development.

First of all, in the face of such a requirement specification, the designer has no idea what the original requirement is. If the functional points in the Requirement Specification do not conflict with each other, but they are different from the user's needs, the designer cannot find such a situation, the encoding staff cannot find it either. If the test is based on the requirement specification, the tester cannot find it. Until the customer finally sees the program in front of them. Demand analysis requires continuous feedback in the subsequent process. The traditional process is not without feedback, but the feedback takes too long.

Secondly, because the designer has no idea what the basic requirements are, it is impossible to model the business. This requirement analysis is centered on the needs of developers, but the results just impede developers' understanding of the requirements. If developers do not know much about the user's business process, they have only one option: do not try to understand the needs, simply follow these functional points. Therefore, the object model they created is not based on requirements, but on functions and interfaces. I have seen a lot of such systems. developers have a high level of abstract thinking. The program has designed very clever controllers and interfaces, which can be easily developed and changed. However, the objects at the business layer are very simple. Once a real business change occurs, it is still very hard.

A greater difficulty occurs when the program is maintained.

Assume that a mobile communication company needs to create a system to solve the problem of mobile phone users accessing the network. This requirement has the following elements:

1: the user pays, gets a SIM card and a number, and installs the SIM card into the mobile phone to talk.
2: the money received by the salesperson should be recorded and provided to the Auditor. The cash and accounts must be flat.
3: the user pays for the bill to be transferred to his account, which can print the bill.
4: The user must sign the contract and archive the contract with the salesperson.

These elements are directly related to the commercial interests of communications companies and do not involve any system implementation methods. If you do not consider the internal business specifications of the communications company, there are dozens of implementation solutions. The following lists two solutions:

1: The SIM card is sent to the salesperson. When the user enters the network, select a number and pay for it. The salesperson enters the SIM card number and phone number into the system and registers on the exchange network. Then the SIM card can be called. Various expenses are then recorded in each user's account, and the contract is archived.

2: Before the SIM card is sent to the salesperson, it is first registered on the exchange network, and a certain amount of phone charge has been set up in advance. The user selects this number, and takes the SIM card and calls the phone after paying the money. The salesperson enters the user's contract information after the event, and the fee is included in the account of each user. The contract is archived.

These two solutions are different in implementation, so they have different functions. For example, SIM cards in the second solution can be called before they are sold, so you must monitor the call charges of such numbers. This function is not required in the first solution. In addition, there is a big difference between the two schemes in checking accounts. These two solutions are a set of different functional points that fulfill the same business requirement.

In the development phase, if the system does not retain the user's business needs, but only leaves a list of function points, it will bring great difficulties to the maintenance personnel. Maintenance personnel cannot find out what their initial needs look like from such a bunch of functional points. You can try it. If we forget the four requirements above, let's just look at a specific implementation scheme below. From this complicated implementation process, it is hard to know what the current user needs are. Once the demand changes, these feature points may go wrong, or the timing of the feature points may encounter unexpected errors. Maybe the account cannot be checked, maybe the SIM card you have taken cannot be called.

I don't know where the demand is.CodeWhich nerves will touch the demand. Most of the pain points of maintenance personnel come from this.

"It doesn't matter. The customer remembers his or her needs ." However, customers generally do not understand the technology. Even if they understand the technology, they do not know how the system is implemented. If developers rely on the customer to propose new solutions, the result is to turn the software engineering into a "biological engineering ". In the end, the money is basically spent, and people are basically exhausted. The feelings between Party A and Party B are basically broken down.

Software development must be divided into several processes, but each step should have a unified core-business needs.

In the demand investigation phase, you should clarify your business needs. To achieve this purpose, you can ask and answer questions, track and interview users, or make a demo to show them, the ultimate goal is to find out what the user is doing, what problems it encounters, and what problems the program should solve. This is the work at this stage.

Then, design and design the logical structure and physical structure of the system. The logical structure must meet the requirements, and each object must call each other to implement the business process in demand. Meanwhile, the physical structure should be reasonably divided, in line with the actual distribution, the required performance can be achieved, and the physical operation mode of the business process is reasonable and efficient. This stage is still centered on business needs.

The next step is encoding. The first step is to write some infrastructure, such as network communication, database, file read/write, and distributed computing. These infrastructure has nothing to do with business needs and there are many ready-made frameworks, with these frameworks, we can get through this dark phase as soon as possible. Then write the business object. At this time, some concepts in the business requirements gradually appear in the Code, such as the example above, business elements such as "user", "Number", "contract", "inbound", and "SIM card resources" gradually emerge, the attributes and running behaviors of these objects are the same as the actual requirements. Then these business objects are connected together to implement the business process, and now the business needs are back to people's vision. What are business requirements and how to implement them are clearly visible here. Finally, call these processes in the ui or interface to provide functions to users or other systems.

Testing should focus on business needs. normal business processes should produce normal results. If a resource is missing or inappropriate data is input, exceptions with clear business meanings should occur. In addition, the Business Objects of the system are at an independent level, which is not closely related to the UI and infrastructure, so that automated testing methods can be conveniently used.

Such a system must be maintained less than a lot of pain points.