Recommended to collect! A complete software development process

Take the baseline product development process as an example

Generally, when an enterprise develops software, it will perform project development work in two parallel ways: baseline and customization. No matter what company, it needs to follow a mature product development process system in order to produce better quality products. Therefore, if there are many projects, the baseline and milestones before customization should be reasonably arranged so that the baseline product can collect as many users' general needs as possible, provide technical support for the progress of the customization project, and reduce the large number of code changes in the customization project. , the need to add new modules occurs. In addition, the product development process system also needs to change according to the actual time requirements of the business. Don't stick to the waterfall method or the agile method. Everything needs to be managed in a way that suits you. Only your feet know whether the shoes fit your feet or not. We use a baseline product development process as the basis for process explanation. It should be noted that for each stage described below,

the goals of each stage must be clearly defined, plans specified, and communicated in a timely manner before the project is executed. , and ensure that all members have a consistent understanding of the project at each period

. Project kick-off meeting

The goal of the project kick-off meeting is to clarify the goals of the product development project. Goals do not exist in isolation. Goals and plans complement each other. Goals guide plans, and the effectiveness of plans affects the achievement of goals. Therefore, when executing goals, think clearly about your own action plan and how to accomplish the goals more effectively. This is a question that everyone must be clear about in detail. Otherwise, the unclear or too high goals will affect the actual performance of the project. result.

The project kick-off meeting needs to explain key matters such as project goals, stage divisions, organizational structure, and management processes

, and write these contents into PPT (preferably with a fixed format and sample text, so that Standards must be adhered to within the team or within the company) and everyone needs to reach a consensus. For the appointment of key roles, it is also necessary to listen to the opinions of relevant leaders and key project stakeholders beforehand. User requirements

Before starting to develop software, it is necessary to determine the comparison between the cost and the value obtained, that is, ROI (Return On investment). Once it is determined that it needs to be created, a series of resources need to be arranged. Support the survival of this software. This is the most primitive description of requirements.

Why do we need both user needs and product needs?

Because there is a difference between the two, user needs are proposed by users, and the technology is generally not described, only the product goals. Product requirements are technical implementation requirements transformed from user needs. It is necessary to subdivide the product goals proposed by users, summarize each specific function point, and then subdivide each function point into various operational processes. Technically define each operational process.

User needs and product needs are prone to differences. This is because although everyone is talking about needs, the starting point may be different, resulting in different concerns and ways of thinking between the two parties.

User requirements focus on how the system supports business processes, and the underlying requirement is to "achieve business goals." Technical staff focus on reasonable technical solutions, and the requirements behind them are "workload", "implementation difficulty" and "system performance"

. Product Requirements

We need to figure out why the product manager or project requirements proposer wants to do this project? This is the most essential business requirement. The business needs determined by demand analysis are all derived from business needs and must serve business needs.

Product requirements generally include

product requirements specifications and product requirements matrix

. The product requirements matrix generally lists all functional requirements according to the structure of subsystems, function sets, and execution units. Each column corresponds to the work steps of each function and the workload of each step. After the product requirements are written, they need to be reviewed. At the requirements review meeting, are the product and technology detailed review requirements complete? What are the normal scenarios for product functions? Is it forming a closed loop? What are the unusual scenarios? Is it thoughtful?

After the requirements review, the development and testing leaders will write technical solutions and test cases respectively.

Technical plan review, the development leader brings together the leaders involved in other systems to discuss.

The technical plan must have a business flow chart and a sequence diagram
. The business flow chart is to sort out the development impact on the business. understanding and whether it is consistent with the needs. The sequence diagram is to sort out the system interactions involved in this requirement. After the technical plan is reviewed and approved, the workload and delivery time will be confirmed and fed back to the product. The goal of the design phase is mainly to analyze and design the architecture of the system to be developed, and to establish the baseline of the system architecture, so as to provide a stable foundation for subsequent implementation work.

The design phase includes the output of the system architecture. A good system architecture design can help humans sort out the business logic and grasp the core requirements, design a stable and scalable business system, and evaluate the business development cycle and development Cost, effectively avoid risks

. For example, when building a house, you must have architectural drawings. Only with the drawings can you calculate the construction period.

The overall design is the framework design of the entire system. It is of great significance and cannot be omitted under normal circumstances (only maintenance projects can omit the overall design because the baseline project has been designed). All product development projects require First carry out the overall design, which is the first step of design. It is never allowed to put the cart before the horse and coding first and then designing. This is the second biggest pain point in software development (the first is unclear requirements and arbitrary changes in requirements!) .

The overall design is divided into three phases:

• The first phase: initial design. Based on the review and refinement of the given data flow diagram, it is converted into an initial module structure diagram.

• The second stage: Refined design. According to the principle of "high cohesion and low coupling" of modules, the initial module structure diagram is refined, and the global data structure and the interface of each module are designed.

• The third stage: Design review stage, review the high-level software structure obtained in the first two stages, and may also need to make some refinements to the software structure if necessary. chemical work.

Outline design

The purpose of outline design is to describe the internal design of each module of the system, and play a connecting role between the overall design and the detailed design.

The outline design is designed according to the structured design method. The basic idea of ​​the structured design method is: according to the problem domain, the software is refined step by step and decomposed into modules that do not need to be decomposed. Each module completes a certain function and serves one or more parent modules (i.e., accepts calls) , also accepts services from one or more submodules (i.e. calls submodules). The concept of modules corresponds to subroutines or functions in programming languages.

In the outline design stage, the software is decomposed into module levels according to certain principles, each module is given certain tasks, and the calling relationships and interfaces between modules are determined.

At this stage, the designer will generally consider and take care of the internal implementation of the module, but not get too entangled in it. Mainly focus on dividing modules, assigning tasks, defining calling relationships. Interfaces and parameter transfers between modulesAt this stage, they need to be formulated very carefully and clearly, and a rigorous data dictionary needs to be written to avoid confusion or misunderstanding in subsequent designs. The outline design is generally not done in one go, but requires repeated structural adjustments. Typical adjustments are to merge modules with duplicate functions or further decompose them into modules that can be reused. In the outline design stage, reusable modules should be extracted to the maximum extent, a reasonable structural system should be established, and the workload of subsequent links should be saved.

The most important parts of the outline design document are the hierarchical data flow diagram, structure diagram, data dictionary and corresponding text descriptions. Based on the outline design document, the detailed design of each module can be carried out in parallel.

Detailed design

The detailed design stage isBased on the decomposition of the outline design stage, the algorithm and process in each module are designed, and the functions completed by each module are described in detail. It is necessary to transform the functional description into a precise and structured process description.

In this stage of detailed design, each module can be assigned to different people for parallel design. The designer's work object is a module. Based on the local tasks and external interfaces assigned by the outline design, the designer designs and expresses the module's algorithms, processes, state transitions, etc. It should be noted here that if it is found that there is a need for structural adjustment (such as decomposing sub-modules, etc.), you must return to the outline design stage and reflect the adjustment into the outline design document, but cannot solve it on the spot without saying hello . The most important parts of the detailed design document are the module’s flow chart, state diagram, local variables and the corresponding text description, etc. One module corresponds to a detailed design document.

In the outline design stage, a software structure diagram is usually obtained. In the detailed design stage, common description methods include: flow chart, N-S diagram, PAD diagram, pseudo code, etc. The purpose of detailed design is to describe the internal processing flow, development methods and coding skills of a certain module. Generally speaking, the detailed design consists of project introduction, module description (specifically describing the internal processes, functions, logic, consumption and unresolved problems of each module), interface design (including internal interface and external interface), Data structure design (including physical structure and logical structure), Special processing and other parts. The detailed design of software is ultimately a written description of the specific design methods, logic, and functions of each part of the software system. In this way, during the implementation process, coders can implement the code strictly according to this principle.

Writing code

Writing code can follow the following principles:

• Do the stress test of the core module first: Many programmers are used to finishing things and then wait until they are about to go online before doing performance testing. So if the previous design This is a big problem. Of course, performance testing will also be done when it is about to go online later, but I think it is still very important in the early stage. Of course, to do this well, you need to understand some business. You need to know where the business pressure is and where the focus of business requests is. Many times, if the product manager does not explain it, you have to ask clearly.

• Ensure the process is controllable: The intermediate output must be maintained when the code is executed. For example, for every 100,000 logs processed, write a status log to record the processing The number of log entries and the current execution time.

• Log more: Many times, I am not very satisfied with the code I write. For example, a certain processing efficiency is not optimized enough, and a certain processing method is not concise enough. Or the scalability is relatively poor, and the code is written very retarded, but it may not be possible to figure out the most reasonable solution in a short time. Considering that this is not the focus in the early stage of the launch, we will not deliberately optimize it, but in this case I often leave notes and explain what possible ideas for next optimization are, or what feasible solutions I think of.

• Simple and easy-to-understand logic: Don’t get yourself involved. Over time, no one will be able to understand your logic. If the logic is really difficult to complete within a function, try splitting.

• Don’t be obsessed with frameworks: What is the biggest problem with frameworks? It's too cumbersome nesting. Why am I always annoyed by frameworks? Because we often encounter processing scenarios that require thousands of requests per second, when tuning, we have to look for data processing logic and performance stuck points from countless frameworks. We may only change two lines of code, but find The problem takes two days. Programmers remember that your technical capabilities must not be restricted by the framework.

• Use familiar and mature technologies: Many people do not understand their own obstacles and problems at all, and do not know the advantages and disadvantages of related technology products. Wherever you look at a bunch of third-party data evaluations, you will get excited and learn new technologies, and then you will fall into a pit and be unable to get out. If you are a startup company, the project may die in it. Before using a new technology, it is recommended to fully understand the characteristics, applicable scope, and non-applicable scope of the technology.

Code Review

As we all know, conducting code review (Code Review) in the team can improve code quality, share project knowledge, clarify responsibilities, and ultimately build better Software, better teams.

Code review is extremely important. Generally speaking, a code review should be done every week. First of all, code reviews help you track the progress of the project. We can really see how the people under us are progressing and find out earlier if they are going astray. Sometimes, people will say "It's almost done!", and you look at the code and find that there is nothing or just a bunch of garbage, etc., but it is still far from complete. In management, this situation is the most annoying, so I think code review is the best way to avoid this trouble.

Unit Test

To understand unit testing, you must first understand what a "unit" is. The so-called "unit" refers to the smallest unit of code call, which actually refers to a function block (Function) or method (Method). So unit testing refers to testing the units that call these codes.

Unit testing is a kind of white-box testing, which is a test that must be very clear about the code details of the unit. Therefore, the writing and execution of single unit tests are done by software engineers. Compared to unit testing, there are also integration tests. Integration testing is basically black box testing, which is mainly conducted by testers according to the function manual of the software. requires the cooperation of a special testing environment. Integration testing is divided into functional testing, regression testing, etc.

The code that requires unit testing is actually the logic written by the developers themselves. Testing whether the environment on which the logic depends is normal is not the purpose of unit testing

. Introducing logic into the environment access code will only make the logic more difficult to test, making the logic code impossible to unit test. Therefore, unit testable code can be unit tested. Another way to determine testable code is to see if the method can be run directly using a main function. If so, it is unit testable code. Another characteristic of testable code is that the parameters of the method unit can be simulated freely by developers without relying on the external environment. Integration testing

Integration testing, also called assembly testing or joint testing. On the basis of unit testing, all modules are assembled into subsystems or systems according to design requirements for integration testing. Practice shows that

Although some modules can work independently, there is no guarantee that they can work normally when connected. Some problems that cannot be reflected locally are likely to be exposed globally

.

Integration testing is a test performed during the integration process of software systems. Its main purpose is to check whether the excuses between software units are correct. According to the integration test plan, it combines modules or other modules into a larger and larger system while running the system to analyze whether the composed system is correct and whether the various components fit together. There are two main strategies for integration testing: top-down and bottom-up. can also be understood as the joint testing of various components of the application system (software units, functional module interfaces, links, etc.) when the software design unit and functional modules are assembled and integrated into the system to determine whether they can be together. Working together, components can be blocks of code, standalone applications, client-side or server-side programs on the network.

System testing

The system testing phase includes system test plan and use case writing, functional testing,performance testing, Stability Test.

In order to verify whether the functions determined by the requirements analysis are complete and correctly implemented, non-functional requirements such as installation, deployment, adaptability, security, and interface must also be tested. System testing is also the responsibility of testers. It should be designed after the requirements analysis is completed and implemented after the integration testing is completed.

Functional testing
is generally tested by an independent testing team using a black box method, mainly testing whether the system meets the "requirement specifications". After the above stages of testing and confirmation, the system is completely simulated to test the customer environment. System testing is to combine the confirmed software, computer hardware, peripherals, networks and other elements together to conduct various assembly tests and confirmation tests of the information system. The purpose is to find out by comparing with the system requirements. Where the developed system does not match or contradicts user needs, a more complete solution will be proposed.

Performance Test
Verify the stability and efficiency of the system and check whether the system meets the specified performance requirements. Performance testing usually selects some typical functions to check whether the system is stable when a large number of users use the system at the same time. Performance testing is the responsibility of the tester. It can be performed after the system test is completed, or performance testing of important modules can be performed first. It can run throughout the entire testing cycle. The purpose is to discover system performance bottlenecks as early as possible and solve them early.

Both stability testing and performance testing must wait until the system has basically no problems and becomes stable before they can be effective. Otherwise, it will be difficult to test smoothly. If an abnormality occurs, it will not be possible to determine whether it is a problem with the system architecture or whether it is a problem. Functional defects.

Stability test (also called reliability test)
By loading a certain business pressure on the system and letting the system continue to run for a period of time (usually 7x24 hours), it tests whether the system can run stably.

Product release

Product release is the last step after system testing. Usually, in the software product development process, there is no need for product trial production and it can go online directly. Only system testers are required to output system tests. Just report and approve the product for release (go live).

Before product release, a product release briefing session is required to review the entire product development process from project establishment to point out shortcomings in the entire process, summarize experience, and provide experience cases for the next project. This meeting can be held in the form of a formal meeting. Product managers, main developers, testers, superior leaders, etc. need to be summoned to participate. They must be fully prepared and try their best to explain the effects and benefits of the product after it is released, so as to evaluate the value after it is launched. prepare for. This link is indispensable. Even in Internet companies with fast iteration speed, this link still needs to be met.

Development Process Review

In fact, this process does not exist in the development process system, but I personally think it is very important.

All summaries can only be gained by thinking with questions. This is review. No matter how much I say it, if I haven’t had similar experiences, it will be difficult to have a strong resonance. I think the best way to see a problem clearly is that you have been in two different roles of the same problem.

The purpose of summarizing project experience and lessons is to summarize problems, analyze causes, and avoid making the same mistakes in the future, rather than to hold anyone accountable.

Suppose there is a flaw in requirements understanding. If it is discovered during the requirements stage, it may only take an hour to modify it. However, if the flaw is discovered when the design is completed, it is estimated to take a day because of the increase in people and documents involved. time, and if this flaw is discovered only after the code is written, it may take ten or eight days. What if the defect is not discovered and goes directly to the production system? This is no longer a matter of workload, and the estimated losses are difficult to estimate. In the theory of quality management, every time a defect is discovered late, the cost of repair will be multiplied ten times.

Written at the end

Agile development, extreme development and other models are to solve the problem of rapid iteration when the requirements are unclear and time is tight, rather than to fundamentally negate the R&D process. The design still needs to be designed , just divide the life cycle and divide the process horizontally into several cycles. Software development is a discipline with strict engineering requirements. Let us adhere to a rigorous attitude and efficient working methods to create highly available and high-quality software products.

This article is reprinted, original author: Zhou Mingyao, original address: https://mp.weixin.qq.com/s/-XDomowMhz9rX-zeCIJuaA