New insights into the software development process

Recently, I have a new understanding of product development process control in the project.

Demand analysis and design are divided by themes

Basically a R&D project can be divided according to the following themes:

1. Business and Problems Themes analyze needs and problems, and draw product ideas.
2. Design the solution after the analysis of the requirements of the solution theme (the core product function design of the product architecture).
3. Product function design after product function theme demand analysis. (covering all function points)
4. Program design (detailed data structure, process design (sequence diagram)) after program design subject requirement analysis.
5. The function implementation theme is coded according to the design.

Each theme has a needs analysis process, but the needs analysis here is specifically the needs analysis under the current theme. For example, the requirements analysis in program design refers to the interface content and interactive actions to be implemented.

These different themes will appear in the software development process.


-------------------------------------------------- ----------------
About the sequence diagram:
from the experience of automatic routing, the first version of the sequence diagram of the complex program will have many loopholes in the code. The writing needs to be modified many times. Therefore, the design document during function development should not contain
detailed sequence diagrams. The sequence diagrams should be stored in the tool, which is convenient for modification at any time, because the possibility of changes when writing the code is too great. .

This understanding is problematic. If the sequence diagram can be specified in detail before development, it should be included in the document. For the program sequence diagram of different complexity, the degree of clarity is different before it is developed. For example, the calling process of swing is more clear. There is no reason, it can be drawn in great detail, but it is deliberately simplified.

No matter how the sequence diagram is drawn, before development, I want to clarify and record the content to be developed. Just need to find an optimal form. If people's ability to think can be done without any tools, then the sequence diagram can be completely different.

The pre-development sequence diagram is used to discover the required classes and describe the main process in detail or in outline (depending on the difficulty of the problem). The sequence of the entire process does not need to be drawn, nor should it be used to limit changes in the code, because it may be possible to think of a better way or find that the previous idea is wrong during the implementation. Detailed and rigid usage sequence diagrams are useless now and will be useless in the future. The key sequence diagram can be written in the design document, and there is no need to use the uml tool to draw diagrams of other processes, because it is not necessary. Using a sequence diagram as a stepping stone, you can figure out a set of related processes. Those similar processes are not necessary to be expressed as sequence diagrams.

After development, the sequence diagram in the document can serve as the entry point for reading the code, which is a very good positioning. This is to be consistent with the software after development.

Through the above methods, the design document can be kept simple and effective, and because a single function needs to maintain fewer sequence diagrams, it is possible to keep the design document and software consistent.

The general principle of this idea is to believe in people's ability to think, and it is not necessary to rely on exhaustive types of design documents. Similar processes can be inferred from others.

The following is also a basic fact:
when writing code, it also needs to be designed. Sometimes it is very simple, it may be the direct application of a certain technology, or it may be very complex, involving complex algorithms and concurrent processing. Trial and error is required, which makes detailed design documentation difficult to be accurate. Therefore, it is still up to the developers to get the final implementation. Therefore, it is not necessary to define everything in the design document, the key content is described in the preparation, and the other content can be supplemented by the developer.
-------------------------------------------------- ------------

Terms like requirements, design, and architecture have their own connotations. However, in different subject areas, the referents are different. Therefore, it has its general and specific reference.
-------------------------------------------------- -------------