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. Together with computer programs, it forms computer software that can complete specific functions (Some people regard the source program as part of the document ). We know that hardware products and product materials are visible throughout the entire production process, while software production is very different. The documentation itself is a software product. Software without documentation cannot be software or software products. 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 actual work, there are many problems 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 documents are too expensive, incomplete, poorly written, outdated, or too many documents, making them difficult to use. What should I ask for it? What should I write in the document? What should I explain? What should I do? A brief introduction is provided here.
Graph document Bridge Function
The document serves as a bridge between software developers, software managers, maintenance personnel, users, and computers, as shown in Figure 9.2. In each phase, software developers use documents as the embodiment of the results of previous stages and the basis for subsequent 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 rationale of 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 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 shall provide the data logic description and various requirements for data collection, and prepare for the production and maintenance of system data volumes.
- Summary 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 algorithms 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.
| Document |
|
User Documentation |
|
User Manual |
| Operation Manual |
| Maintenance and modification suggestions |
| Software Requirement (specification) Specification |
| Development document |
|
Software Requirement (specification) Specification |
| Data Requirements Specification |
| Summary Design Specification |
| Detailed Design Instruction |
| Feasibility Study Report |
| Project development plan |
| Manage documents |
|
Project development plan |
| Test Plan |
| Test report |
| Monthly Development Progress Report |
| Development Summary Report |
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: the implementation plan for how to organize the test should be prepared for 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 execution 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 invested manpower. In addition, we also need to evaluate the development work and summarize the experience and training.
- Maintenance and modification suggestions: after the software product is put into operation, problems such as correction and modification are discovered, the existing problems, modification considerations, and modified impact estimates should be described in detail, written as maintenance modification suggestions, and submitted for approval. The above documents are prepared during the software life cycle as the work of each phase is carried out. Some of them only reflect the work of one stage, and others need to span multiple stages. Table 5 lists the phases in which documents should be written during the software life cycle. These documents should eventually be answered to the software management department or to the user:
Table 9.2 documents prepared at various stages of software survival
Phase Document |
Feasibility medicinal liquor and Plan |
Requirement Analysis |
Design |
Code Writing |
Test |
Operation and Maintenance |
| Feasibility Study Report |
|
|
|
|
|
|
| Project development plan |
|
|
|
|
|
|
| Software requirements |
|
|
|
|
|
|
| Data requirements |
|
|
|
|
|
|
| Summary Design |
|
|
|
|
|
|
| Galaxy Design |
|
|
|
|
|
|
| Test Plan |
|
|
|
|
|
|
| User Manual |
|
|
|
|
|
|
| Operation Manual |
|
|
|
|
|
|
| Test Analysis Report |
|
|
|
|
|
|
| Monthly Development Progress Report |
|
|
|
|
|
|
| Project Development Summary |
|
|
|
|
|
|
| Maintenance and modification suggestions |
|
|
|
|
|
|
- What needs to be met, that is, "What do you 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 ?"
- Who will do some development (or maintenance) work ?"
- 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
Question raised Document |
What |
Where |
When |
Who |
How |
Why |
| Feasibility Study Report |
√ |
|
|
|
|
√ |
| Project development plan |
√ |
|
√ |
√ |
|
|
| Software requirements |
√ |
√ |
|
|
|
|
| Data requirements |
√ |
√ |
|
|
|
|
| Summary Design |
|
|
|
|
√ |
|
| Detailed Design Description |
|
|
|
|
√ |
|
| Test Plan |
|
|
√ |
√ |
√ |
|
| User Manual |
|
|
|
|
√ |
|
| Operation Manual |
|
|
|
|
√ |
|
| Test Analysis Report |
√ |
|
|
|
|
|
| Monthly Development Progress Report |
√ |
|
√ |
|
|
|
| Project Development Summary |
√ |
|
|
|
|
|
| Maintenance and modification suggestions |
√ |
|
|
√ |
|
√ |
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.
