Preliminary Design of Software Development

What kind of solutions are we going to talk about? How can we design a good design scheme? These problems are the issues that should be paid attention to during the preliminary design of software development.

When talking about software design, we may have done it for everyone, but what kind of solution is a good design solution? How can we design a good design scheme? What should I pay attention to during the design process? Don't always say: low coupling, maintainability, scalability, simplicity, reusability, etc. This article tries to start from another angle, with the above questions, so that everyone can understand the answers to those questions, we will discuss with you.

What kind of solution is a good design?

After we have completed a good design scheme, we will go back and carefully analyze the factors that have affected our thinking, so that we can finally complete the process (to be exact, we have chosen) with this design scheme (rather than the other one), we will find that these factors are: user functional requirements, technical performance requirements, and R & D costs (or capabilities) constraints, of course, there are also some other factors, such as the subjective requirements of the customer, aesthetic or commercial factors, and forward compatibility requirements. However, most of these factors are non-technical factors and we will not discuss them too much here; whether these factors can be well met determines whether a design scheme is a good design scheme. Therefore, we must fully consider these factors at the beginning of the design.

How can we design a good design scheme?

But in fact, basically no solution can satisfy every factor. A good design solution is often a balanced result, this is also the reason why we are always discussing the design scheme, because different people can get a solution that he thinks is better from different perspectives, people will always have their own reasons, and those reasons are justified, but remember that a good design scheme is often a balanced result. In a sense, balancing is the key to determining whether a solution is a good solution, especially for complicated and large design solutions.

Balancing Art

But how can we achieve a good balance? The answer is obviously not: a bowl of water needs to be flattened. There is a well-known principle called the 28 principle, which is also suitable for our software development rules. Our 80-percent effort in design and development only brings us a 20-percent return, in other words, our return is only the result of our 20% effort. This principle tells us that we need to grasp the key points in the balance. If necessary, we can discard the non-key parts, dropping them may bring greater value. Next, we will analyze several key factors mentioned above to carefully discuss the art of balance.

Functional requirements of users

Without a doubt, the ultimate goal of our software is to meet user needs. Because we want to design a product-type software, it determines that our needs are not very clear, it may be widely used, and even some requirements may be imagined by ourselves, but it is precisely because of this that we have the need to balance. Imagine if we are working on a project, you only need to fulfill the requirements of Party A. The contract has even been clearly required, and there is not much balance to be done at this time. For a product-type software, the functions used by more than 80 users should be well designed for ease of use and outstanding performance, and a large amount of manpower R & D should be invested, those 50% of users can use less manpower and time, and those 5 of users can use the functions that require a large amount of time or even discard them.

However, the balance is not just about making or not doing a function with the choice, but also about how to do a function. We generally have the following implementation methods for user requirements:

1. Implement a simple and easy-to-use interface or function with good design and 100% satisfying user needs

2. Set options on some interfaces to meet user requirements

3. manually modify some configuration files to meet your needs (the R & D resources required for this implementation method only account for 1% of the first implementation method)

4. Use scripts to meet user needs

5. Implement the user's needs through plug-ins or custom development (the latter two methods actually do not consider this demand now, even if we can support it in the future)

Different implementation methods need to invest R & D resources of different magnitude, and occupy less and less R & D resources from top to bottom. This is what we need to balance.

　　Technical Performance Requirements

Users always want to get immediate results when performing any operation on the software interface, expect the system to support more and more online concurrency, and expect the system to run without downtime for the whole year without any errors, hope the system is compatible with various platforms ...... Therefore, we have many performance requirements for our system, requiring that we must support clusters, various high-speed caches, multiple languages, and transaction operations, some performance requirements must be carefully considered at the beginning of the design, because from the past experience, if the system did not consider the cluster, multi-language, and transaction at the beginning out of R & D costs, in the future, after the system is formed, it will often pay a higher price, which is sometimes broken.

It also meets the functional needs of users. One implementation requires a large amount of R & D resources, but the program efficiency is very high. The other requires only a small amount of R & D resources, but the program efficiency is slightly lower, how can we balance it now? I believe most people can make the right choice. We should consider the following factors: the number of currently available human resources, the difference in R & D resources to be invested, and the frequency of use of modules. I often say, for client applications, it takes less time to implement functions that are executed only once in one user interface operation, because the execution of one operation in 3 ms and the execution of one menu in 300 ms is not very different for users, but this is not applicable to server applications, server applications also need to consider the number of online users. If the number is 3 ms, more online users can be supported.

R & D cost (or capability) Constraints

This is often the most important factor we should consider, but it is often overlooked.

When an engineer develops 3 modules per year and 10 modules per year, he can basically make each module complete more than 90 minutes, including code quality, test units, documents, etc. He can also learn and study some new technologies for some time, and can maintain a pleasant mood and efficient work; but if he wants to develop 10 modules in a year, he may have to barely finish 60 or more for each module, the Code may not be fully considered and leave hidden risks, the test coverage rate is not high, and the documents are insufficient. The whole day is busy and there is no time to charge, resulting in low efficiency.

Most of the R & D engineers are optimistic and confident at the beginning. The time required for R & D is estimated too low. I often say that, to complete a module to 60 minutes or 1 person's month, it may take 3 persons's month to complete to 80 minutes, and 8 persons may need 8 months to complete to 90 minutes or more, the growth ratio is not straight, but parabolic, so the R & D cycle is often difficult to estimate. We must prepare enough buffer time for the future. In a sense, the more the better.

Therefore, this is precisely the important reason why there are some factors in the above balance process that need to be put into R & D resources, A well-prepared design solution can be regarded as a good solution for future R & D difficulties.

What should I pay attention to during the design process?

Starting from demand

It is always right to consider the requirements from the user's perspective. We should not only consider technical issues during design. Of course, technical issues must also be considered, however, the premise is that we must have a better understanding and analysis of the demand. From the perspective of the demand, we do not mean that the demand is the largest, and sometimes the demand must be balanced by other factors.

From the very beginning, consider the technical requirements that have a wide impact

These factors are likely to seriously affect the design and must be studied in advance. Such research can be fragmented from the demand, and sometimes even some test code can be written, but in the end it must start from the demand, after fully understanding various technical points, you can decide your final design.

Fully consider R & D resource costs

No matter whether the best design is implemented, the balance should be well balanced.

From http://kb.cnblogs.com/page/89505/