Article 3: Software Development Module

I am not a man who worships the software model very much. Many domestic software companies like to try one development mode after another. I often see some people complain that this mode is not good or that mode is not suitable. In my opinion, the software development model is the same as the corporate culture. Different enterprises have different personnel structures and different product (Project) development tasks. Therefore, if you only use one development mode, you may be reluctant to accept it!

In the previous article, I wrote "decomposition process of development tasks". Thank you for your comments. They said that the requirements are summed up, not broken down, but I think it is difficult to sum up the goals that need to be completed without breaking down into understandable units, only after the project has a comprehensive understanding can we summarize and extract Reusable Modules and clarify the relationship between each module, "developers will use their own experience to replace the actual requirements of the customer and cause the target deviation", qingrun said. In fact, this problem occurs in every step, for example, there is an error in understanding between the customer and the requirement collection personnel, between the requirement collection personnel and the design analysis personnel, and between the design analysis personnel and the functional development personnel. In this case, I personally think that, we need to learn each other's documents (Review) to eliminate this error. During our development process, it is assumed that there is an error in communication and understanding between people, and the ability of individuals to execute tasks is limited. That is to say, each person may make an error and the probability of an error is relatively high. Therefore, the project is divided into various understandable independent modules, the purpose is to check whether the target is different from the original requirement within the minimum range.

Many software companies lack documents. Some of them do not have documents. Some of them are documents that have not been updated. When a problem occurs in the system, they are not supported by documents, it usually requires a lot of manpower support. In the IT industry with a lot of mobility, this extra labor expenditure often greatly increases the project cost, in addition, developers are exhausted to cope with these repeated bugs. One of the most important reasons for lack of documentation is that project participants think that the document is useless. If you waste a lot of time writing documents, it is better to write code early (or because the project budget is too tight, so that there is no time to write documents.) If documents are completed in some development modes, it is indeed very time-consuming. For example, the number of documents in cmme is more than 20, each document involves a lot of content and a lot of content, which is redundant for developers. Developers only care about what functions they need to implement, then they mainly want to find a way to implement these functions. So many documents are an extra burden for them. However, documents are essential to the company's technical support. Therefore, we only select useful documents and write as few documents as possible. Each document only writes the required content, this saves a lot of time and effort for both review and learning documents.

Because our projects are not large-sized, we also try to reduce the writing time of documents and adopt a development mode called "v". The advantage of this development mode is that, reduce the number of documents to a minimum. The "v" development mode is as follows:

It can be seen that the "v" Development Mode compresses the development process to six steps, each step has its own document, each document is inherited forward, the document on the left side of the vword provides evidence for the process on the right side of the word. Because each link continues the previous part, the difficulty of this model lies between two links. In this Transitional Link, it takes a lot of time to learn and evaluate the results, only after the participants in the previous step determine the results of the next step can the process be pushed forward. This ensures that there will be no misunderstanding deviation in the understanding process of each link, if there is a deviation from the previous document, the participants in the previous section are responsible for explaining their goals. If you review the document in the next section, if any deviation is found, the review participant must correct the deviation. Through repeated review, we can usually eliminate the deviation of understanding. In this case, if there is a problem that does not meet the user's needs, the problem often occurs in the acquisition of requirements, rather than in the design analysis. In other words, this layer-by-layer review method not only ensures that the understanding is not biased, but also traces the process of the problem when an error occurs.

In the above six steps, the documents to be completed are:

Requirement document-Requirement Analysis

Overview document ----- summary Design

Detailed documentation-Detailed Design

Development Documentation ----- Encoding

In this way, the test document is removed and only four documents are required (DB documents can be included in the summary document). These documents have different focuses, in addition, the documents in the subsequent stages must contain all the content of the previous documents, and further describe the same functions from different perspectives and methods.

I am not quite sure that the v‑type development mode is not counted as the "Regular Army" of the software development mode. This mode is similar to the workflow of some traditional industries, I used to work in a large design institute where hundreds of designers were required to participate in a project. After several years or even decades, their design model was to first separate independent modules, then we design and describe each independent module, which not only guarantees the project's completeness, but also ensures that some independent modules can be reused, sometimes it is enough to directly call the drawings of other projects. This is a bit like the modular production of military enterprises. (I forgot to say that CMMS may be suitable for military enterprises, common software companies are unable to digest), which is easy to produce. If necessary, you can develop multiple modules at the same time and trace errors easily, every error can be identified by a designer.

PS: for software, I seem to be a layman. I always use non-software modules to solve software problems. ^_^