A software document, also known as a document, usually refers to recorded data and data media. It has a fixed form that can be read by humans and computers. It and computers Program Together constitute computer software that can complete specific functions (Some people treat the source program Composition File ). We know that hardware products and product materials are visible throughout the entire production process, while software production is very different. The document itself is a software product. Software without documentation cannot be software or software products. The preparation of software documentation (documentation) plays a prominent role and considerable workload in software development. Efficient and high-quality development, distribution, management and maintenance documents are of great significance for the transfer, change, correction, expansion and use of documents, and to give full play to the benefits of software products. However, in practice, there are many questions in the preparation and use of documents, which need to be solved. Software developers are generally not interested in document preparation. From the perspective of users, they often complain that the price of documents is too high, documents are incomplete, documents are not well written, documents are outdated or too many documents are difficult to use. What should I ask for it, what should I write in the document, and what questions should I explain? A brief introduction is provided here. Graph document Bridge Function
This document serves as a bridge between software developers, software managers, maintenance personnel, users, and computing machines. Software developers use documents as the embodiment of the results of previous stages and the basis for subsequent stages of work in various stages. This role is obvious. During software development, software developers need to prepare work plans or work reports which should be provided to management personnel and necessary support. Management personnel can learn about the software development project arrangement, progress, resource usage and results through these documents. Software developers need to provide detailed information about the use, operation, and maintenance of the software. We call this a user document.
The above three documents constitute the main part of the software documentation. The content of these three documents is listed in figure 6. 13 documents are listed, which are briefly described here:
· Feasibility Study Report: describes the technical, economic, and social feasibility of the software development project, comment on various possible implementation schemes that can be selected to reasonably achieve the development goal, and explain and demonstrate the reasons for the selected implementation scheme.
· Project Development Plan: Develop a specific plan for the software project implementation plan, it should include the person in charge of each part of the work, the development progress, the development budget, the required hardware and software resources, etc. The project development plan should be provided to the Management Department for reference in the development phase review.
· Software Requirement Specification: Also known as the software specification, which provides detailed descriptions of the features, performance, user interface and operating environment of the developed software. It is an agreement between the user and the developer on the basis of mutual understanding of the software requirements and the basis for the implementation of development.
· Data requirements manual: This manual should provide the logical description of data and the requirements of data collection to prepare for the production and maintenance of system data volumes.
· Outline Design Description: The summary is the work result of the outline design stage, 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, lay the foundation for detailed design.
· Detailed design description: describes how each module is implemented, including implementation. Algorithm And logical processes.
· User Manual: This Manual describes in detail the functions, performance, and user interface of the software, so that you can understand how to use the software.
Figure 3 Documents
· Operation Manual: This Manual provides the operator with relevant knowledge about the various running conditions of the software, especially the detailed operation methods.
· Test plan: an implementation plan for how to organize the test to complete the assembly test and validation test. The plan should include the testing content, progress, conditions, personnel, selection principles of test cases, and allowable deviation range of test results.
· Test Analysis Report: after the test is completed, a description of the implementation of the test plan should be submitted. Analyze the test results and put forward the test conclusions.
· Monthly Development Progress Report: This monthly report is a monthly project progress report submitted by software personnel to the management department. 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.
· Project Development Summary Report: after the software project is developed, it should be compared with the project implementation plan to summarize the actual implementation status, such as progress, results, resource utilization, cost and labor invested. In addition, it is necessary to evaluate the development work and summarize the experiences and lessons learned.
· What needs should be met, that is, the answer "what to do? "
· In what environment does the developed software implement and where the required information comes from? "
· How can I schedule some development work, that is, "When? "
· Some development (or maintenance) work is intended to be done by "who? "· How are some requirements met?
· Why do we need to make changes to software development or maintenance? The thirteen documents mentioned above have answered these six questions to a certain extent. This can be seen from the table.
Questions answered in the table document
So far, we have a further understanding of the role of the document. The tasks of each document are clear, and any document is redundant.
