Graphic Software Documentation

Import: First of all, small series to recommend a complete software engineering document download address---http://pan.baidu.com/s/1gdHYU47, easy and quick connotation ~ ~ ~

Well, starting into the subject.

A few days ago, brother Siang us a progress audit meeting, subject to the acceptance of software engineering documents. This is primarily a review of our understanding of the documentation, including a few key points in the documentation Reader, key documents (e.g., e-r diagrams, use case diagrams, prototype diagrams, interface designs, simple descriptions of the database, etc.) in the software Requirements specification.

Although the template was completed the first time the document, but in fact, the content of the document is not very deep understanding, just according to gourd painting scoop. Experience or to slow down the heart, a summary of a step, the foundation to fight.

In the document-driven software development method, the document is one of the core of software, the soul of software, the quality of the document directly related to the development of software. Different documents have different reading objects, lifetimes and different emphases, the correct distinction and clear can greatly improve the quality of our written documents, to ensure the correct direction.

The following will analyze the soft work document from different angles according to several graphs.

first, the document and reader (the red font is the key document).

For most of our classmates in the acceptance process is not clear document readers, small series according to the National Software engineering standards of 14 documents, collation of the document and corresponding to the relationship between the reader, mainly let us be able to clear hard to write a half-day document in the end is to whom to see. The importance of this is that we write documents that have to take into account what the audience wants to see and what to get from them, so that the documents are readable.

second, the key content of each document analysis.

This does not give the diagram, or the text description is better.

1, project development plan. It mainly proposes the project implementation plan and carries on the concrete analysis, including the work content, the project condition and the restriction (hardware and software, personnel, technology, environment, etc.), the running environment analysis, the task analysis, the budget and the Personnel Division and so on.

2, feasibility report analysis. The main analysis of the implementation of the project is economic, legal, technical and other aspects of the feasibility, according to the company's specific conditions for analysis, proposed programs and analysis.

3. Data Summary Manual. Mainly gives the logical data description and the request, according to the project characteristic carries on the data analysis, for later data management and the database establishment and so on completes the explanation and the preparation.

4, the software requirements manual. Very important document, mainly describes the system analyst and users to communicate the system requirements, including the system's function, performance, interface, data structure, operating environment, operational requirements (interface, fault handling) and so on.

5, test Plan. It mainly describes the necessary test requirements, use cases, methods, contents, environmental conditions, personnel arrangement and so on during the test.

6, the outline design manual. Important documents that describe the requirements outlined in the summary design phase, process flow, function allocation, module design, interface design, operation design, error handling, and security and confidentiality design.

7, detailed design instructions. Important document, mainly describes the implementation of the system, including system functions, performance, input and output, algorithms, program logic and interfaces.

8, the database design manual. Important documents, it is self-evident, mainly describes the database design methods (external design, structural design, operation design), design principles, table structure and so on.

9, module development files. Main record module development process.

10, User manual. Important documents, including detailed system functions and performance introduction, operation process and use method, error handling, etc., give the necessary illustrations.

11, Operation Manual. This paper mainly describes the detailed operation method of the system, and gives the necessary diagram explanation.

12. Test and Analysis report. This paper mainly describes the analysis of test results, and gives the development staff the index of system improvement and modification.

13, Development progress report. Detailed monthly development progress, but also to include factors affecting the progress.

14. Summary of project development. This article mainly describes the experience and technical summary of the project, including development cost (belongings), progress description, Project harvest, and compare with the actual implementation of the development plan, give the evaluation, for the next system development to provide reference.

Third, the main body of the document relations.

These people have both a document reader and a writer, and the synergy between them is broadly illustrated in the figure below. The documentation for the software changes as the software changes, so the documentation is a bridge between those people who are working together to develop software.

    

Iv. The distribution of specific documents within the lifetime of the software. in particular, the test process is based on the entire software development process, so it runs through the entire lifetime, and the user manual cannot be written at the end in a cursory manner, to be planned and written early, so as not to be omitted and too sketchy (see the Sony product specification for an example).

UML diagram and reader relationship and its distribution in the software life-time map. in fact, the UML diagram and the document does not have a very strict correspondence distribution, such as use case diagram, class diagram, etc. need to appear in the requirements document, class diagram, activity diagram, state diagram, sequence diagram, collaboration diagram, etc. need to appear in the summary/detailed design instructions, to do a more thorough description of the introduction, Other UML diagrams can be populated appropriately and flexibly in other documents, depending on the situation. Some graphs are filled repeatedly because the readers of each document are different.

Finally, it is important to write a soft document for document-driven software development, but no other development method documents can be ignored. It is a software development tracking and monitor, is the entire software text description. Some of the above diagrams describe the soft work document, UML diagram, document reader and software development life, and other content of the relationship is not very clear, insufficient places also please correct me.