软件工程标准化和文档知识讲稿.pptVIP

可行性研究报告 说明该软件项目的实现在技术上、经济上和社会因素上的可行性; 评述为合理地达到开发目标可供选择的各种可能的实现方案; 说明并论证所选定实施方案的理由。 项目开发计划 为软件项目实施方案制定出的具体计划。它包括 各部分工作的负责人员 开发的进度 开发经费的概算 所需的硬件和软件资源等 项目开发计划应提供给管理部门，并作为开发阶段评审的基础。 软件需求说明书 对目标软件的功能、性能、用户界面及运行环境等作出详细的说明。 它是用户与开发人员双方对软件需求取得共同理解基础上达成的协议，也是实施开发工作的基础。 数据要求说明书 给出数据逻辑描述和数据采集的各项要求, 为生成和维护系统的数据文件做好准备。 概要设计说明书 该说明书是概要设计工作阶段的成果。它应当说明 系统的功能分配 模块划分 程序的总体结构 输入输出及接口设计 运行设计 数据结构设计 出错处理设计等 为详细设计奠定基础。 详细设计说明书 着重描述每一个模块是如何实现的，包括实现算法、逻辑流程等。 用户手册 详细描述软件的功能、性能和用户界面，使用户了解如何使用该软件。 操作手册 为操作人员提供软件各种运行情况的有关知识，特别是操作方法细节。 测试计划 针对组装测试和确认测试，需要为组织测试制定计划。计划应包括 测试的内容 进度安排 条件 人员 测试用例的选取原则 测试结果允许的偏差范围等 测试分析报告 测试工作完成后，应提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论性意见。 开发进度月报 该月报是软件人员按月向管理部门提交的项目进展情况的报告。报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 项目开发总结报告 软件项目开发完成之后，应当与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力。 还需对开发工作作出评价，总结经验和教训。 维护修改建议 软件产品投入运行之后，可能有修正、更改等问题。 应当对存在的问题、修改的考虑以及修改的影响估计等做详细的描述，写成维护修改建议，提交审批。 以上软件文档是在软件生存期中，随着各个阶段工作的开展适时编制的。其中，有的仅反映某一个阶段的工作，有的则需跨越多个阶段。 软件生存期各阶段与文档关系 文档最终要向软件管理部门，或向用户回答下列问题 What 哪些需求要被满足； Where 软件在什么环境中实现，所需信息从哪里来； When 开发时间如何安排； Who 开发(或维护)工作打算由谁来做； How 需求应如何实现； Why 为什么要进行这些软件开发或维护修改工作。 文档要回答的问题 对文档编制的质量要求 如果不重视文档编写工作，或是对文档编写工作的安排不当，就不可能得到高质量的文档。 质量差的文档 使读者难理解，给使用造成许多不便; 会削弱对软件的管理（难以确认和评价开发工作的进展情况)，提高软件成本(一些工作可能被迫返工); 造成误操作; 对编制高质量文档的要求 (1) 针对性 文档编制以前应分清读者对象。按不同的类型、不同层次的读者，决定怎样适应他们的需要。 管理文档主要面向管理人员 用户文档主要面向用户 这两类文档不应像开发文档(面向开发人员)那样过多使用软件的专用术语。 (2) 精确性 文档的行文应当十分确切，不能出现多义性的描述。同一课题几个文档的内容应当是协调一致，没有矛盾的。 (3) 清晰性 文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。 (4) 完整性 任何一个文档都应当是完整的、独立的，它应自成体系。 例如，前言部分应做一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。 同一课题的几个文档之间可能有些部分内容相同，这种重复是必要的。 不要在文档中出现转引其它文档内容的情况。如，一些段落没有具体描述，用“见××文档××节”的方式. (5) 灵活性 各个不同软件项目，其规模和复杂程度有着许多实际差别，不能一律看待。 应根据具体的软件开发项目，决定编制的文档种类。 管理部门应根据本单位承担的应用软件的专业领域和本单位的管理能力，制定对文档编制要求的实施规定。 对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划。其中包括： 编制哪几种文档，详细程度如何 各文档的编制负责人和进度要求 审查/批准负责人和时间进度安排 在开发时期内各文档的维护、修改和管理的负责人，以及批准手续 有关的开发人员必须严格执行这个文档编制计划。 当所开发的软件系统非常大时，一种文档可以分成几卷编写。例如， 项目开发计