Software Development pyramid

Zookeeper

 

In software development, a pyramid can be used to describe the entire process from Requirement Analysis to coding. Analyze the advantages and disadvantages of the entire development process and the development process.

The pyramid consists of requirement analysis, outline design, detailed design, and code. The requirement analysis is divided into requirement and Software Requirement Specification, as shown in 1:

 

Figure 1 standardized software development pyramid

Next we will analyze the standard software development pyramid from bottom to top.

In software development, whether your software is large or small, demand analysis is the most important and essential, and also the basis of the entire software development. In Figure 1, the light green section is the requirement analysis. The requirement analysis is divided into the requirement and the software requirement specification. In actual project development, many projects do not require specification specifications. On the one hand, the project may be too small, and on the other hand, the requirements for documents are insufficient.

Requirement analysis aims to clarify what the user and customer need, what the software needs to do, what the problem to solve, what the software looks like, and what the final effect will be. This is almost the goal of the project. With the goal, we began to analyze the problems to be solved in detail, find out the requirements of the problem, including what data needs to be input, what results should be obtained, and finally what should be output, what guidelines should be followed during the process, and finally sort out the Software Requirement Specification. The software project is an engineering project, and the specification of the software requirement is equivalent to the design of the project. Through this design, we can reach an agreement with the customer, so that developers can have a clear development goal. If this is missing, the software we have worked so hard to develop may end up not being what the customer needs, leading to reverse engineering.

With the design, it is time to build the software architecture, describe the functions of each module, and implement the module interface connection and data transmission. This stage is the outline design, that is, the brown part in Figure 1. In the outline design stage, we need to divide the system from the overall perspective by function, establish the module hierarchy and call relationship, and determine the interface between modules and man-machine interface among others to design the software structure.. We also need to describe the data features, determine the structure characteristics of the data, and design the database to complete the design of the data structure. Complete the logic model of the target system through software structure design and data structure design.

The logic model of the target system has been designed. Next, we should design the implementation algorithms of each module, the required local data structure, and conduct in-depth analysis on the modules described in the outline design, analyzes the combinations of modules and describes the specific functions and phenomena of the program. This is what we need to do with the detailed design. The yellow part in Figure 1 is the detailed design.

With the requirements, design, logic model, and specific implementation descriptions, we can determine the development language to be used based on the system features and company personnel, which project team is responsible for coding. Here, our software development pyramid is basically completed.

 

Figure 2 nonstandard software development pyramid

In the actual development process, whether or not we clearly divide these stages for development, we are all potential to develop according to such a process, but only some stages, the process is as shown in figure 2. Through these pyramid, we can also Visually Demonstrate the time we need to spend in these stages, as well as possible risks in the later maintenance process.

 

Figure 3 functions of each level in the pyramid

From figure 3, we can see the responsibilities of each stage. The requirements are the problems raised by the customer, the problems that need to be solved by our software, and the principles for solving these problems, everything is around the problem. The specification for software requirements is designed to solve these problems. We use it to reach an agreement with the customer. if the customer is satisfied, we can proceed to the next step. This design will also guide our developers to develop standards, because its final effect is to reach an agreement with the customer, so that the customer finally wants, only the software developed according to this standard can pass the customer's acceptance. With the design, can we get started with coding? I don't think it's a problem. Although we already have a design, our understanding of the entire system is still unclear, and we still have a lot of fuzzy points. Therefore, we need to establish a logic model of the target system based on the design. This logic model is used to analyze the overall architecture of the system, the design of the data structure, and the division of each module, and the potential risks to the system when new problems arise in the future. Only by looking at the system as a whole can we build a better system architecture, make the system more stable, and make the code structure design more reasonable, so that we can withstand the challenges of the emergence of unknown problems. Then how can we better decode the logic model of the target system.

According to the entire coding process, the time spent before real encoding is much longer than the coding time. However, our construction period is limited. Therefore, many companies put a lot of processes on the sidelines and use the non-standard software development pyramid in Figure 2, the previous work took very little time and most of the time was put in coding. In fact, this nonstandard pyramid encoding process also includes the outline design and detailed design, but they are synchronized.

The nonstandard pyramid is full of loopholes, and there are also many problems. It seems that the system can be quickly made. Although there are many problems, it can be modified slowly in the future, in short, the customer can be handed over a system at the end of the construction period, and the general function can be implemented. However, where is the most time we spend on a piece of software? Is it development? Apparently not. We developed a system that won't be done for the customer. We don't have to worry about it anymore. We need to maintain it and solve its problems, the time we spend on system maintenance is much longer than the development time.

Obviously, we have done a good job in the early stage, reached an agreement with the customer, and analyzed all aspects of the system. We can analyze the system comprehensively. Therefore, no matter what new requirements are added during later maintenance, it will not have much impact on the structure of the entire system. Even if the maintenance personnel did not know the system at all, their predecessors left behind "design", the logic model of the target system, and the description of the system implementation. Soon, they will be able to understand the entire system, it can also be well involved in system maintenance. Even with new requirements, he can redesign and develop the system based on the overall architecture to ensure the overall architecture, performance, and code structure quality of the system. In this way, the maintenance cost can be greatly reduced.

The non-standard pyramid will spend most of the time coding, and the preliminary work will be done in a rush without leaving many useful design documents. Many aspects of the system are fuzzy, and there may be many problems encountered in the coding process due to these fuzzy, but there is no good solution, or the solution only considers the current module and ignores the system as a whole, resulting in other problems. This vicious circle continues. The final system may not be as effective as the customer expects. There are still many problems and vulnerabilities, resulting in many bugs. No useful documents are left for later maintenance. In this way, the development cost may not be reduced, but the maintenance cost is greatly increased.

Even if design documents are written at the end of maintenance, although they are conducive to development and maintenance in the later stage, the written documents are more or less subject to the interference of the existing system, such as inaccurate understanding, the lack of some important analysis will affect the later maintenance, resulting in the compilation of documents may have design problems, as a result, the maintenance personnel who do not understand the system cause many adverse effects in the development and maintenance of the system. For example, the branch machine ticketing management module of the China North Bill System and the branch office quota ticket management module have the same functions. From the browser's address bar, the paths are different, the two modules should be separately written. From the implementation point of view, the two modules can be put together for processing and display, however, later documents can only be written separately. If other types of tickets are added and new modules are added, and the functions are similar, the documents should be developed accordingly, the implemented module code has to be written again because of the different ticket types, which undoubtedly increases the maintenance cost. Similar to this, other old systems also exist.

In summary, the more standardized our development process and documents are, the more conducive we will be to the development and maintenance of our software products in the long run, and the quality of our software products can also be guaranteed, this reduces development and maintenance costs.

Software Development pyramid