软件工程文档的总结

    软件工程视频看过之后就是文档的书写，这里面有很多值得我们注意的细节的地方，在师傅给我验收项目的时候提到，是我当时不曾注意的在这里列出来，有不足之处还望大家多多之处来：

1）各个文档由谁书写，又是写给谁看

这里我理出了一张表：

名称	作用	编纂人	目标读者
可行性研究报告	对所要进行的项目的可行性给出建议	行业内部的专家，本行业内具有工程咨询资质的单位	需求分析的软件分析员、客户、维护工作人员
项目开发计划	便于项目团队人员了解项目情况，使项目开展的各个过程合理有序	由项目管理团队集体编制，但对此负责的人是项目经理	用户、开发者、管理者、以及分析人员
软件需求规格说明书	为了分析出软件要达到的目标和功能，并能为项目干系人所认同，同时起到交流媒介的作用。	系统需求分析人员和用户	开发人员与用户
概要设计说明书	将系统的功能进行模块划分，建立模块的层次结构调用关系、确定模块之间的接口和人机界面	系统需求分析人员	项目经理，用户
详细设计说明书	进一步明确系统的结构和程序，对模块的编程给出详细指导	系统需求分析人员和项目经理	程序设计人员、测试人员和维护人员
数据库设计说明书	提供了数据库设计的可视性以及软件支持所需的信息		数据库设计师、数据库管理员
测试计划	描述将要进行测试活动的范围、方法、资源和时间进度	测试组长（测试主管）	测试人员
测试分析报告	对测试的结果以及测试的数据等加以记录和分析总结	测试组长（项目经理），以及参与测试工作的人员	软件开发人员
项目开发总结报告	对前期工作作出总结，对后期工作进行分析和部署	项目经理	软件开发人员
操作手册	针对系统的管理者对系统的各项操作叙述	系统需求分析人员	系统的使用者
用户手册	针对系统的最终用户详细叙述系统各个模块的功能和作用以及操作方法	系统需求分析人员	系统的最终用户
开发进度月报	总结本月工作，对下个月工作作出安排	项目经理以及项目开发人员	企业管理者和客户

除了这个表格之外我们还要注意一下的几点
1.软件需求规格说明书 是给项目干系人看的。项目干系人包括：客户、领导、项目组成员以及合作公司等等和项目相关的人。一般应该由系统分析员和客户一起写，通常是系统分析员写后让客户确定。如果分工细一些，就应该由需求分析员来写，但是有一点：应该由经常与客户打交道的人来写。
2.详细设计说明书给开发人员看，一定要细致。大到用到多少模块，多少类，小到标点符号的地方，事无巨细必须给出很明确的规定和指导。
3.操作手册一般应该由需求分析人员来写，需求人员对你的系统有清晰完整的认识，他应该跟踪整个软件的生命周期，从而写出完整可靠的用户手册。但实际操作中却由于公司规模限制都由测试人员代替了。
4.操作手册和用户手册的区别：操作手册的设计应当针对系统的管理者，就像机房里面的操作员管理员级别，而用户手册呢则是针对最终的用户，就像机房中的学生。
5.然后就是像项目开发计划，测试分析报告，项目开发总结报告在项目比较大的情况下都是由团队完成的，有项目经理级别的领导来对整个文档负责，做最终的整合，审核工作。

2）各种图都是用在哪些文档中的

阶段	工具	文档
计划	甘特图（进度安排）	项目开发计划
需求分析	数据流图DFD，数据字典DD，IPO图（判定树，判定表），原型图，用例图，用例说明，	软件需求规格说明书
概要设计	结构图（变换型和事务型），界面，架构图（粗粒度）	概要设计说明书
详细设计	图：程序流程图，N-S图，PAD图，包图（架构图），类图（类图说明，方法，参数），接口，时序图 表格：判定表 语言工具：PDL（伪码）	详细设计说明书
数据库设计	表，表结构，视图，SQL语句，脚本注释，数据库关系图	数据库设计说明书
测试	测试用例	测试计划
使用	修改历史，界面描述	用户手册

     在写文档的时候没有注意到很多东西，比方说在错误处理的时候只是很笼统的说，根据错误类型分别给出提示。之后反思，这叫什么话？人家客户知道你设计了什么样的错误处理？开发人员怎么知道你想要如何的处理方式？
然后就是师傅说得两句话很受启发：
1.文档中要放实实在在的东西，每个角色最关心的（这就要求我们熟知每个文档到底是写给谁的）
2.不要写废话，没有意义的不要写，并且要明确，不能模棱两可

总结：

写文档的时候要站在看文档的人的角度上来思考问题，关心他们最关心的问题，想人之所想；
我们不能受到文档模板的格式限制住自己的思维，要把如何清晰明白的把问题解释清楚放在首位。
图表等形象的方式要比，我们大段大段的文字叙述更具吸引力。