Different demand changes
Author: Windy J.
Keywords: demand, demand change, demand analysis, cost estimation, object-oriented technology, package, inheritance, polymorphism, UML, software design, software maintainability, scalability, software reusability, interface
Abstract: The author puts forward its own insights for the current demand change in the current software system construction, and proposes that in addition to the way of reinforcing training and cost analysis, it is more important to carry out reasonable analytical design methods. Scalability design can effectively reduce risk and maintenance costs caused by demand changes, and give a specific example of scalability design.
The demand change problem during software system development is a software developer or software system customer. I believe that we have encountered the case of demanding changes, it is generally said that customers will require changing interface, change operation, and even change their business. Said, I was asked so that now, our business is adjusted ... At this time, it is necessary to interrupt the work in progress, need to verify the previous information, need to revise the plan, need ...
Demand includes business needs, user needs and functional requirements. Business Requirement reflects the organization or customer's high-level target requirements for the system, product, and user requirements describes the tasks that users must complete. Functional Requirement defines that developers must implement. Software function. In the software system development, there are many problems due to the fact that there is no correct collection, writing, negotiation, and modifying the real needs of the product in the demand analysis stage, which causes such conditions. There are several reasons: understanding of demand
When the customer is expressed by the demand analyst, it is often expressed by natural language. This expression is a description for real needs (even a description of a certain angle), which is far from guaranteed such a description. Get 100% correct understanding, perhaps the first time to communicate with the customer, I buried the seeds of understanding of the difference. I said that the customer said that the customer said that the elephant I want, the body is like a wall, the ear is like a fan, four legs icons Four columns, tail icon rope, analyst, oh, wall, fan, pillar, rope, these I know, but the customer will certainly jump! This is a problem that understands the difference, generally with the analyst's knowledge, background, and the standard level of the customer, and the exchange of the two sides; the construction of the system is too long, the construction of a large and medium-sized system may continue for a while, when the customer puts forward After the request, he did not see the system's operation, and when both parties considered to understand, there was probably no difference (in fact, there was a deadline), the development side began to work. When the customer gets almost the product you can try, he can actually operate, this time he will have some kind of experience in the interface, operation, function, performance, etc., it is possible to make a demand change requirement; the customer's specific situation is not current The customer's situation is different. It is possible that the customer industry has high competitiveness. It needs to make adjustments and reactions at any time, then they will naturally provide the requirements for demand changes; it is also possible that the industry operations are not standardized. There are many people in itself. It is time to prepare a strain at any time; development itself is possible to be from the developer's own version upgrade or performance improvement, design and revision requirements have changed, then it is impossible to bypass this problem! Therefore, even if there is no understanding between the analyst and customers, the customer will make some personal opinions about the actual system, even if there is no personal opinion, their own business changes or changes, these are unavoidable, so Don't dream so ideally, you should realize that when you start a project, you should realize that the customer needs will change, so what should we do for such status? The customer is God. We are like the previous, follow the needs of our customers to modify the software, extending the last construction period, the employee is exhausted, the cost is doubled, the customer satisfaction is reduced, the original design will change, the system is difficult maintain? The objective face of demand changes If the demand will change, if we have to face it, if we have painted thinking, if we want to change, then what else can improve our current situation Answers. Strengthen personnel training
From the measures that can be taken from objective aspects, first, I don't want to quo, strengthen the training of demand analysts, enhance the background knowledge of software systems, industry, improve the communication skills of customers, enhance service awareness and sense of responsibility. Because the system to be developed directly on demand analysis; simultaneous regulating requirements analyst and customer communication, and the format of the specification requirements, if possible, try to take the UserStory, or the user understanding of the user To standardize the needs, the description of the standard, guarantee that the two sides meet the needs of demand with the assistance of the tool, this is the old talk, there is not much to say. Determine the validity of the document (VALIDITY) is about documentation, the demand document is quite important, but there is a strange phenomenon. It is originally necessary to have a document, and it is in a specific format, of course This is not wrong, but next, no one cares about whether the real content of the document is correct, is really reasonable, whether it is practical (and in many cases, there is a few days to come out or make up), for example I encountered An example, it is necessary to carry out subsequent development on the basis of the original demand, the document is found, fully conforming to format, but I found the clue in it is limited, the result is a time to find data table structure, and even view The content of the data sheet, asked the developer at that time to analyze the needs of the relationship, this situation also exists in the design document, so mentioned, I hope our developers, PM, and leaders at all levels can pay attention to the effective documentation Sexual and usefulness issues, even in the format of the documentation.
Establishing a cost estimation concept This is equally important to the developer and customers, because if there is a change in demand, it is inevitable that the cost will increase, and the development time is prolonged. This impact is both sides. At this time, it is necessary to distinguish between demand changes. It is the necessary / unnecessary requirements of the customer, or because the development side's work error, the two parties have causes, and then analyze the reality, the cost of achieving the needs of the change needs. , Including time, manpower, resources, etc., and then discuss whether it is necessary to change and how to achieve changes in minimum cost. When customers see the actual cost estimate, they will also carefully consider the issue of demand changes, and it will be more easily understood in the system construction, and natural development servers do not have to pay all demand change costs, so cost-off Have active. Of course, there is also a need to establish a major demand management such as version control, and it is not specifically discussed here. From the software analysis and design, it has said that several strategies in the face of demand changes, then from the perspective of software system analysis and design, by adopting a reasonable analysis design method, the scalability design can effectively reduce demand changes. Risks and maintenance costs. Software systems that use OO techniques can be used to establish software systems that are easy to change and strengthen reusability. For OO technology, I think there is no strange concept: 1 Encapsulation reduces the impact of the problem, and the external change requires the impact of the system to be limited to a class level or some type of level, thus Part of the change system is relatively simple; 2 inheritance can make changes based on the original technical foundation, to a large extent reduction of repeated development work; 3 polymorphism applications can make development and designers under relatively unified interface Changing the system's implementation details, thereby changing the behavior of the system; 4 and because the industry has a very clear and clear description method for the OO system, it is the current specification description language -uml, very easy to understand and reach a consensus of the development group. Promote cooperation between members of the development group and the continuity of strengthening software development work; it is an analysis and design method of enhancing software maintainability, robustness, and maintaining design stability, itself can be somewhat The demand change is quickly reactive and the cost required for demand changes can be reduced. (OO's significance lies in the analysis and design of software system thinking, and the software reuse after establishing the object library will bring quality changes to the development of the software system, but before establishing the OO development system, it will be a thorns all over. The road, you need to pay double efforts and reach the transformation of ideas. There is also a misunderstanding that many people think that C , PB, VB, Delphi is the object-oriented development, in fact, some object-oriented Tools, there is still a structured analysis and design method in the bones, and the outer OOP housing is set.) Extensible-Design
Second, from the software design we can control, how to make a suitable design to minimize the cost of demand changes? Maybe some said that my design is very flexible. I have expected the customer's possible request, and design a few ways to deal with it. When you come out, huh, huh, I have solved. Such an idea is good, at least more than stiff design, but who can ensure that the designer can predict the future demand change? At the same time, in order to achieve this design, the design will become complex, and maybe those extra designs never used? Complex design will increase the difficulty and cost of implementation, and may have potential bugs that make the system difficult to maintain. The idea of design should have some small changes, that is, the design can be simple, but must be easily changed, but must be easily changed, but must be easily changed, but must be easy to change, but need to change the interface, this point is very important. For example, there is now a class called TCPConnection to represent a typical TCP connection in computer network communication. For this connection, it may be in the following states: Established (Connection has been established), Listening, Closed (CLOSED) Connection is closed). A connection object requires a request from another object. As for its reaction, it is determined that the state where the connection object is located, for (open the connection request), if it is connected to the closed state, Open () is in other states. Do not respond; Similarly, if the connection is established and listened, Close () can be made (), and Acknowledge () can be made (), i.e., receive data. For such a situation, the least outable design should be a HARD design with a series of Switch statements (or even if / else statements). For each time demand change, you need to change the source code, followed by system consistency, Work such as document update will enable developers to inevitably fall into a disaster. This consequence will result in the original unreasonable design to become more fragmented, and the cost of system maintenance will be more and more; even if there is no demand change, these design Reusability is also very poor. A slightly better design is to pre-estimate all possible states of the TCPConnection class, and add design, this need to pay more design, development, maintenance costs, and it is also difficult to achieve the perfect effect, so don't say more . Here is a classic design idea that fully reflects the scalability of "EXTENSIBLE-DESIGN" thinking "(system) to change the reserved interface" and very well achieved this idea. Here, we introduce an abstract class TCPState to represent the status of the TCPConnection class, give a general purpose operation interface of the specific state, and generate different subclasses (implement specific operations) to implement different status of the TCPConnection class, such as derived A TCPESTABLISHED class is used to implement the connection to establish the TCPConnection class. The structure is shown as follows:
It is only necessary to include a TCPState state reference, and updated to the current state reference when the status of TCPConnection changes, for example, when the connection is closed, the state reference should become TCPSTABLISHED, so that it is implemented The original requirement. But this design idea is much more than this. We can see that abstract class TCPState has left an interface for the TCPConnection class, and only needs to derive specific different status subclasses to achieve future status changes, and there is no need to affect the original design, no need to add extra The code is not required, so this is a beautiful, scalable design idea, very clear, easy to maintain, I believe you can give us some inspiration when making software design. Conclusion, in the face of the change of demand changes, in addition to the objective requirements of personnel training, cost analysis and other management methods, from the perspective of analysis and design, the angle of analysis and design can be changed. The awareness of the design can be flexible response to demand changes, at least to reduce maintenance costs and improve user satisfaction to some extent. The management and control of software needs is very professional. The author is in combination with your own practice, and only thinks of a role of throwing bricks. I hope everyone can face and find ways to solve our system development. The actual problem, I think that is what I really want to achieve.
