13 types of documents to be written in software project development-reprinted by Sun Software Institute

During software project development, thirteen types of documents should be written according to software development requirements. The documents should be specific, accurate, clear, complete, flexible, and traceable!

Demand stage

1. Feasibility Analysis Report

Describe the technical, economic, and social feasibility of the implementation of the software development project, and comment on various possible implementation schemes available to reasonably achieve the development goal, describe and demonstrate the reasons for the selected implementation scheme.

2. Project Development Plan

A specific plan should be formulated for the software project implementation scheme, including the person in charge of each part of the work, development progress, development budget, required hardware and software resources.

3. Software Requirement Specification (software specification)

The functions, performance, user interface, and running environment of the developed software are described in detail. It is written under the conditions that both users and developers have a common understanding of the software requirements and reach an agreement. It is also the basis for the implementation of development work. This manual should provide data logic and data collection requirements to prepare for the production and maintenance of system data files.

Design Phase

4. Summary Design Specification

This manual is the work result of the actual phase, it shall describe the function allocation, module division, overall program structure, input and output, interface design, operation design, data structure design and error handling design, and provide the basis for detailed design.

5. Detailed Design Instruction

Describes how each module is implemented, including algorithms and logical processes.

Development Phase

6. Monthly Development Progress Report

This monthly report is the project progress report submitted by software personnel to the Management Department on a monthly basis, the report should include the comparison of the progress plan and actual implementation, the results of the phase, the problems encountered and solutions, and the plans for the next month.

Test phase

7. Test Plan

In order to do a good job in integration testing and acceptance testing, we need to develop an implementation plan for how to organize testing. The plan should include the testing content, progress, conditions, personnel, selection principles of test cases, and allowable deviation range of test results.

8. Test Analysis Report

After the test is completed, a description of the implementation of the test plan should be submitted, the test results should be analyzed, and the conclusions and opinions of the test should be put forward.

Final Stage

9. user operation manual

This manual describes in detail the functions, performance, and user interfaces of the software, giving users a detailed understanding of how to use the software and providing operators with relevant knowledge about the various operating conditions of the software, in particular, the specific details of the operation method.

10. Project Development Summary Report

After the software project is developed, it should be compared with the project implementation plan to summarize the actual implementation, such as progress, results, resource utilization, cost and manpower invested. In addition, it is also necessary to evaluate the development work and summarize the experiences and lessons learned.

11. Software maintenance manual

It mainly includes software system description, program module description, operating environment, support software description, and maintenance process description to facilitate software maintenance.

Maintenance Phase

12. Software Issue Report

Identifies software issue registration information, such as date, discoverer, status, module of the problem, and provides the preparation documents for software modification.

13. Software Modification report

After the software product is put into operation, if problems such as modification and modification need to be discovered, a detailed description of the existing problems, modification considerations and impact of the modification should be provided and submitted for approval.

Source from: www.china-cio.com, reprint please indicate the source.

 

 

 

Do not contract in the project or product "shell"-reprinted by Sun software College

It may have been a long time to stay in the shell, so that the current world is almost confused. This is the case when developers are busy with development and do not know the changes in the environment around them all day long. Technology may have advanced, but other capabilities are degrading. At that time, there was always an interesting place in the product process, that is, to consider both the market and technology. Not only in the same industry Development, competitor actions, and sometimes consider companies and channels in the relevant upstream and downstream industry chain, as well as the industry in which customers using your products are located. No one can tell you what is right, Sometimes it is completely followed by feelings and even competitors. When the customer comes to the door to communicate with you and asks you to do this, some methods are acceptable, while others are whimsical. However, there are other needs that make you laugh, not even BT, because from their perspective, everything should exist as long as you can make money and "Everything is possible. At this time, you need to combine your professional background and market analysis capabilities Give them your views on these features or problems, understand the original intention of the customer to propose this function or idea, evaluate the feasibility of the related solutions, and demonstrate your own ideas. Maybe in a round or even several rounds of communication Then, you will find that developing these features is not as complex (or simple) as you thought at the beginning ). It's just that it was too complicated or simple. I used to make a mistake, so I was eager to code it. It seems that a lot of time and energy have been wasted. In fact, users may need a small function, but I did not care to use a lot of framework models, resulting in serious over-design, even carry the "practice with customers" Suspect. This kind of preference may occur in projects or products all day long. However, only after being in contact with users can users wake up with cold water. Some colleagues who have been shrinking their heads and writing spam code in the shell all day do not think they are not aware of who you are when wearing a vest. The ugly daughter-in-law will see her in the morning and evening. When you show your "work" and things to a customer or employer, the dashboard will still be shot on your ass. I hope that the developers behind the projects and products will come out and come to the peers to exchange your design ideas and experiences. In this way, they can train their own expression skills, verify their own methods, and enhance their self-confidence. Of course, sometimes it will be pointed out by some peers, and even some personal attacks. However, either they will perish or they will erupt. There are two kinds of outbreaks: one is to directly reverse the lip, regardless of the head back. One is to find out the cause. If you do not make a mistake, identify the mistake and seek understanding, and correct it in subsequent development, if you don't have any problems, point out the problems in your opinion in good faith or seek a solution together to grow with your peers. I don't want to dive into products or projects any more. After a long time, I will lose my ability to live in the sun and on land. After years of development, I began to observe the environment outside the circle and expand my world. Source from: www.china-cio.com, reprint please indicate the source.