Home >

Project Document Management From Project Handover

2009/3/25 12:03:00 42012

Plan management description document: if a complete Porject plan is the best, but this document must pay attention to its accuracy. When planning management with Project, the longer the project progresses, the more changes, the more difficult it is to plan and maintain. At this time, it is possible that the plan is unable to reflect the actual project progress.

Plan management documents must be carefully studied, whether the whole project plan is properly arranged, what tasks have been formulated, but which tasks have not been completed, which tasks have been cancelled, whether these cancelled tasks belong to the predetermined functional requirements, which links have not been carried out, which links have been repeatedly reprocessed, and the interruption of tasks occurred during the work process, which can be seen from the plan management document, which is more conducive to assess the actual situation and risk situation of the project, and can be perfected according to the imperfect contents in the previous stage.

At the same time, the key point is whether there are abnormal situations in these tasks, such as: you think the difficult technology research and development work has been completed in a short time, all of which need attention and understand the actual situation.

Finally, through the plan management statement, the target is confirmed.

The content that has been completed should be consistent with the results presented above. If there is no document in this part, it is necessary to supplement the whole process according to the corresponding results and staff.

After completion of this document, it can also become a basis for subsequent management and optimize the processing.

If there is no plan to manage documents, when supplemented, it is recommended to use Project to complete, the first result is submitted to the document, and it is best to use WBS to organize the task arrangement, and submit the submitted corresponding to the corresponding tasks.

Through the explanation of the state of the previous document, mark the unfinished content and see whether there are different tasks in the same task, which should belong to repetitive tasks and marking.

Three. Requirements specification: it is necessary to explain the initial demand of the product. In fact, the importance of the requirement specification has been greatly reduced for the product I am currently taking over, because the product has been developed and completed, and a complete user manual has been provided. However, there are two main purposes for sorting out the demand note:

1, it is necessary to establish a complete process traceability process to prepare for the follow-up work.

2, verify the effectiveness and availability of the results through requirements.

The requirement specification is a document that can be simplified and complex. In this project, the requirement manual is more about extracting the needs from the user's manual, and the actual meaning is not very big.

But if it is to make a new project, the requirement specification should be the most probable way to describe the user's business and not to adulterate personal understanding.

As to whether or not it can be realized, how to achieve it is a matter of follow-up work, not the content of this link.

Four. System design specification: the system design specification is now unable to consider the design problem at this time, but the following contents should be provided at this time:

1. The structure design and structure of the system are adjusted in the application process.

And it is best to provide structural analysis of defects.

2, interface design specification and interface specification and design specification.

Now the system is basically loose, through the interface standards to achieve the ultimate integration of the system, so the interface part is very critical, this part of the content must be very clear and accurate.

3, if the design documents can no longer be provided, it is suggested that the design of the third party tools should be generated according to the code of the results, and the documents should be supplemented on this basis. The design is better than the code, so this part should be provided.

If in this new project, this part of the content page suggests consideration, mainly planning interface calls, object functions and object relationships.

Five. Database design specification.

I still attach great importance to database design. Although there are many tools for DAO and object modeling, the actual application process is very few, especially for data analysis.

So I think this document is still very important.

As for the format of documents, because this aspect has been very "standardized", it is not being explained.

Six, the test report is not required. If it is a new project, it is suggested that the test plan should be carried out.

Basically, there are so many, many documents should be said, but it is a complete process. When the project started, it should set up the document specification, not many documents, but it should have a description of every link of the project.

I have seen a project light requirement description, there are many different documents, headache, and later maintenance will be very troublesome.

It is suggested that a unified document be included in each link.

Making a habit of reading is very important. Otherwise, everyone will not see it.

Make a summary:

Requirements specification document: it is recommended to decompose requirements first and then use tables to illustrate them.

If conditions permit, use RequisitePro to manage requirements and achieve tracking.

System analysis and design document: it is recommended that Rose be used. The use cases must have, even larger granularity, to explain the requirement analysis in the use case part, and to explain the specification requirements.

The components and class diagrams must have, standardize the interface invocation rules, organize the code structure, and establish a good system framework.

Which describes components or class functions.

This part is not entirely designed by the designer.

If possible, provide activity diagrams.

Programmers are more interested in activity diagrams than timing and statecharts.

You can use SoDA to generate corresponding documents (read-only) for development and query usage.

Not necessarily a Rose file, it can be multiple, if you want to split, corresponding demand split.

Database specification: it is recommended to use PD, and automatically generate documents (read-only) for development and query use.

Test report: you can use the test report to explain the results, but I personally feel that the test plan is more important than the test report, because without a good test plan to guide, the final test will become a description link.

Among them, it is recommended to use Project to carry out project plan management. It is best to use Projectserver to track, so that the union log can also be omitted.

Using version tools to document management must be very important.