Seven stages of software life cycle

The first stage: the imagination stage

At this stage, the feasibility, cost and benefit of this hypothesis need to be verified repeatedly; If similar software is available in the industry, it will be easier. If not, we can only use some simulation and prediction methods to help. When the plan is implemented, a kick-off meeting must be organized. Participants include all stakeholders, and the president-level leader will announce the official start of the project. The purpose is to give you a way forward, and I hope all parties will work together.

The second stage: the demand development stage

At this stage, we should consider the usability of the five features of the software. This stage is probably the most controversial. There will be many solutions to the same business function requirement, and each solution will have a set of detailed software function descriptions. The cost and availability of different solutions will be different. From the perspective of business departments, the better the usability, the better the satisfaction. But from the point of view of the information department, if the cost exceeds the budget, it is necessary to make an additional budget. If it is not approved, it is necessary to discuss and negotiate with the business department repeatedly. Project leaders in all aspects of the information department must participate in the discussion at this stage. If the cost of a certain aspect exceeds the budget, it must be put forward in time, including development, testing and hardware. Usually, some companies only have one project manager or salesperson to participate in the discussion on behalf of the information department at this stage, and accept many business needs with costs far exceeding the budget. I don't know how this person can grasp all aspects of the situation and accurately calculate the cost. I wonder what the top management of these companies think? If such unprofessional practices as Party B are usually losing money, the only solution is to continuously squeeze the front-line technicians. This abnormal phenomenon is very common in China. As a practitioner in the information industry, I really hope that this phenomenon can be improved as soon as possible, giving technicians more opportunities for respect and growth, and finally forming a virtuous circle.

Usually, front-line technicians will not participate in this stage, and the person in charge of participating technicians is required to be familiar with the company's existing technical architecture and the cost of use or reuse; Strong communication and coordination skills; Familiar with the workflow of the company's finance department, budget department and purchasing department; All quality requirements are to be able to deeply understand and grasp the three elements and high quality standards marked by the triangle mentioned at the beginning.

From the point of view of the person in charge of the whole project, balancing the interests of all parties is usually a challenging task. The author once attended a course called Thinking Technology organized by Jingyue Company, in which he mentioned the methodology that is most suitable for all stakeholders from multiple solutions to a problem. The author thinks that this methodology can be used in the current controversial focus.

If there is no dispute at this stage, it is abnormal. The more disputes at this stage, the less disputes at the later stage. From the whole project, the success rate is relatively high and the total cost is relatively low.

The third stage: the design stage

Only when the work in the previous stage is fully done can the work in this stage be more meaningful and valuable. The work at this stage is very important, connecting the preceding with the following.

In terms of software, the author thinks that the technical director, the design director, the implementation director and the three-level software operation and maintenance support director involved in the requirements development stage are the same person. These four persons in charge can be separated, but it is necessary to ensure that the person in charge of the next stage can fully understand and recognize the idea of the work output of the person in charge of the previous stage. If the four responsible persons are separated, they will face the following management problems:

1. Because the person in charge of the previous stage did not continue to be responsible downwards, there may be problems of carelessness or substandard output results; The person in charge of the next stage may have the same problem, so that the problem has been solved until the end, or even can not be solved, and the cost far exceeds the budget.

2. The problem of knowledge transfer, if the person in charge of the next stage can't understand the idea of the person in charge of the previous stage, then two people in charge need to fully communicate together to reach a * * * knowledge, but if both people in charge can't reach a * * * knowledge, it will cause another problem.

However, if the four responsible persons are all the same person, some people may question that a person's energy is limited and he is not competent for a big project. Here, the author must declare that he is an agile developer. In the actual work process, the version is usually released once a month or two, and it will be put into operation once it passes the test. This solves the problem of a person's limited energy. In fact, the range factor in the triangle mentioned at the beginning is set to the limit that is just suitable for a person in charge. The biggest benefit of this method is self-evident, the project has high success rate and low risk, and the value of the software can be realized as soon as possible-serving the business. Some people may question that if there are too few new functions in each released version, there may be deviations in architecture design, and the architecture needs to be redesigned constantly. The author has always understood that software architecture and software source code can be considered separately. For example, the relationship between architecture and source code is just like the relationship between bookshelves and books. You can prepare a large bookshelf at first, and then add one book after another, so you don't have to change the bookshelf for a long time. If you start with a small bookshelf, books will fill it quickly. A small bookcase is not enough at this time. The solution can be to add a small bookshelf or change it into a large bookshelf. Adding a small bookshelf is equivalent to adding a subsystem, and replacing it with a large bookshelf is equivalent to redesigning the architecture and then adding new modules. But the author is not sure whether to use a small bookshelf or a big bookshelf at first. If you must make comments, the author advocates designing the bookshelf into a model in which one can flexibly increase or decrease the volume of the bookshelf. At this time, the value of architects is clearly displayed. The work of putting books is relatively simple.

The logic of hardware and testing should be similar.

The fourth stage: the realization stage

With the quality standard and design scheme, the next work is to realize the processing. In the process of realization, it is necessary to constantly check whether the quality is up to standard and whether it is realized according to the design scheme. If the person in charge of this stage is the person in charge of the design stage, and then the person in charge of the third-level operation and maintenance support, then these two inspections will be smooth. Software must have source code management tools. There must be a hardware configuration management tool.

The fifth stage: quality inspection stage

The quality inspection in the realization stage belongs to internal inspection, and the quality inspection in this stage belongs to external inspection. Professional quality inspectors should look at the problem from another angle and see if they can meet the quality standards. The author argues that the technical person in charge in the requirements development stage, the person in charge in the design stage, the person in charge in the quality inspection stage and the person in charge of repeated quality inspection during operation and maintenance should all be the same person.

At this stage, another management problem is the communication between quality inspectors and developers, so defect management tools and perfect quality reports are necessary. For the accident after the software goes online, if the cause of the accident is an undiscovered software defect and there must be punishment measures, the author advocates that the developer is responsible for 60% and the quality inspector is responsible for 40%. The author does not advocate reward and punishment measures, but advocates the cultivation of ownership spirit. Because many times it is difficult to distinguish between merits and demerits, which will inevitably lead to unfairness; But it is easy for everyone to understand that the company has good performance, more bonuses and improved welfare, and individuals also have jobs in the company. But the cultivation of the sense of ownership is an advanced topic, which is beyond the scope of the author's work experience. There is only one profound experience that the company should give employees the feeling of home. As long as we serve the company wholeheartedly as always, there is no reason for the company to abandon this family, and the annual salary increase is at least not lower than the inflation rate. The author thinks that such a family should have a strong sense of ownership.

Phase 6: Deployment Phase

This stage realizes the combination of software and hardware. I can mention the following points:

1. Automated deployment tools can be used at this stage.

2. Software deployment can be divided into application layer and database layer.

3. If Windows server and domain management are used, the connection between application and database must use integrated authentication.

4. The account of the application pool must use the service account, and the password must use the password management tool.

5. The service account can only be used in the application pool to connect the application and the database, and remote login to the server is not allowed. It is used in the client software connected to the database.

6. If domain management is not possible, then all passwords should be encrypted.