软件工程视频看过之后就是文档的书写，这里面有很多值得我们注意的细节的地方，在师傅给我验收项目的时候提到，是我当时不曾注意的在这里列出来，有不足之处还望大家多多之处来：
1）各个文档由谁书写，又是写给谁看
这里我理出了一张表：
|
名称 |
作用 |
编纂人 |
目标读者 |
|
可行性研究 告 |
对所要进行的项目的可行性给出建议 |
行业内部的专家，本行业内具有工程咨询资质的单位 |
需求分析的软件分析员、客户、维护工作人员 |
|
项目开发计划 |
便于项目团队人员了解项目情况，使项目开展的各个过程合理有序 |
由项目管理团队集体编制，但对此负责的人是项目经理 |
用户、开发者、管理者、以及分析人员 |
|
软件需求规格说明书 |
为了分析出软件要达到的目标和功能，并能为项目干系人所认同，同时起到交流媒介的作用。 |
系统需求分析人员和用户 |
开发人员与用户 |
|
概要设计说明书 |
将系统的功能进行模块划分，建立模块的层次结构调用关系、确定模块之间的接口和人机界面 |
系统需求分析人员 |
项目经理，用户 |
|
详细设计说明书 |
进一步明确系统的结构和程序，对模块的编程给出详细指导 |
系统需求分析人员和项目经理 |
程序设计人员、测试人员和维护人员 |
|
数据库设计说明书 |
提供了数据库设计的可视性以及软件支持所需的信息 |
|
数据库设计师、数据库管理员 |
|
测试计划 |
描述将要进行测试活动的范围、方法、资源和时间进度 |
测试组长（测试主管） |
测试人员 |
|
测试分析 告 |
对测试的结果以及测试的数据等加以记录和分析总结 |
测试组长（项目经理），以及参与测试工作的人员 |
软件开发人员 |
|
项目开发总结 告 |
对前期工作作出总结，对后期工作进行分析和部署 |
项目经理 |
软件开发人员 |
|
操作手册 |
针对系统的管理者对系统的各项操作叙述 |
系统需求分析人员 |
系统的使用者 |
|
用户手册 |
针对系统的最终用户详细叙述系统各个模块的功能和作用以及操作方法 |
系统需求分析人员 |
系统的最终用户 |
|
开发进度月 |
总结本月工作，对下个月工作作出安排 |
项目经理以及项目开发人员 |
企业管理者和客户 |
2）各种图都是用在哪些文档中的
|
阶段 |
工具 |
文档 |
|
计划 |
甘特图（进度安排） |
项目开发计划 |
|
需求分析 |
数据流图DFD，数据字典DD，IPO图（判定树，判定表），原型图，用例图，用例说明， |
软件需求规格说明书 |
|
概要设计 |
结构图（变换型和事务型），界面，架构图（粗粒度） |
概要设计说明书 |
|
详细设计 |
图：程序流程图，N-S图，PAD图，包图（架构图），类图（类图说明，方法，参数），接口，时序图 表格：判定表 语言工具：PDL（伪码） |
详细设计说明书 |
|
数据库设计 |
表，表结构，视图，SQL语句，脚本注释，数据库关系图 |
数据库设计说明书 |
|
测试 |
测试用例 |
测试计划 |
|
使用 |
修改历史，界面描述 |
用户手册 |
在写文档的时候没有注意到很多东西，比方说在错误处理的时候只是很笼统的说，根据错误类型分别给出提示。之后反思，这叫什么话家客户知道你设计了什么样的错误处理发人员怎么知道你想要如何的处理方式/span> 然后就是师傅说得两句话很受启发： 1.文档中要放实实在在的东西，每个角色最关心的（这就要求我们熟知每个文档到底是写给谁的） 2.不要写废话，没有意义的不要写，并且要明确，不能模棱两可
总结：
写文档的时候要站在看文档的人的角度上来思考问题，关心他们最关心的问题，想人之所想； 我们不能受到文档模板的格式限制住自己的思维，要把如何清晰明白的把问题解释清楚放在首位。 图表等形象的方式要比，我们大段大段的文字叙述更具吸引力。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！