软件文档开发规范.pptVIP

软件文档开发规范2008.6 文档的概念 文档的编写 文档的评审 文档的配置管理 文档的查阅 文档的概念（1） 文档不同于在学校里写作的论文，论文是给自己、导师或学术杂志编辑看的，多为理论推导、研究性较强，但读者面相对较窄。而公司内部的文档则是围绕着产品的，是产品生命周期各阶段的记录，涉及到协同开发中的工作交接、延续，某些文档甚至直接面向用户，作为我们产品形象的一个介质。 文档的概念（2） 1、文档是指产品开发过程中用于描述开发、测试、生产、销售、维护、管理、计划等过程中与产品有关的记录与资料等文字文件（含图形、表格），以及源程序、硬件原理图等。 2、文档大致分为“过程文档”和“状态文档”。过程文档主要是指与产品开发设计部分有关的文档（如需求分析、概要设计、详细设计、测试计划、测试报告等）。而状态文档则是偏重于产品进入维护阶段以后出现的各类有保存价值的文档（如优化设计、版本升级说明、评审报告、出差报告等）。 3、研发体系技术类过程文档和状态文档、管理类文档以及软件代码、硬件原理图、PCB图、BOM清单等这些都属机密文档。 4、“只有已归档的文档才是文档，而未归档的文档不算文档”是错误的概念。 文档管理的意义 没有文档的劳动就是无效的劳动。 文档是产品的一部分；文档是技术的载体。 通过文档的评审可以控制开发质量；通过文档归档可以控制开发进度。 文档是新员工接手工作的基础；文档是你面向他人的合作界面。 文档编写 文档质量 软件开发过程 软件开发过程中涉及文档 各文档编写说明 文档质量（1） 可读性：文档表达清晰，逻辑条理分明、表现形式通用，使具有一定技术背景的工程师容易读懂。造成文档可读性差的常见原因包括有错别字、语句不通顺、前后逻辑矛盾、图形少或不清楚、编排混乱、缺少必要的背景知识介绍等。 完整性：文档内容覆盖所述问题的各个侧面或层次，包括市场需求说明、可测试性、可生产性、可维护性设计等下游部门的需求。 一致性：文档的内容要一与程序、硬件原理图的具体实现保持一致，要与相关的文档的内容保持一致。 准确性：文档中涉及的技术应该是可行的，文档内容要准确无误，设计思想、算法、数据结构以及测试方法、测试结果等要符合（程序的）实际情况。 及时性：按计划完成文档。每位开发人员，除了特殊原因使文档推迟或取消外，都应及时地按计划完成文档。 规范性：在RND-APPS“文档管理”上有全套研发文档最新模板，因随时会有更新，每次写作文档都要从中下载最新模板。员工必须按模板写作文档，不得随意删除其中的条目，如无内容可注明“无”，如需要可添加条目。 文档质量（2） 文档质量就是产品的质量，是我们的生命线。 文档写作要素： 1.文档规范命名，并明确产品版本号 2.套用正确的模板,参考文档未归档的请注明“未归档”。 3.重置样式 4.填写关键词和摘要 5.各级标题正确排序 6.刷新目录 7.定位图文框、插入对象 8.正确使用表号和图号 9.原理图尽可能打包附在文档中。如果文件太大，也可在文档中说明归档到文件中心的这些文件的正式名称 文档质量（3） 写文档一定要使用文档模板； 因模板经常会有更改，所以每次使用时请注意从服务器上直接调出，而不要用以前在自己机器上所留的备份； 文档模板正确的使用方法：将文档模板放置于WORD的模板目录下，在“文件”中选择“新建”。有两种错误：对照模板另行敲文档——无法利用模板提供的功能；或者直接打开文档模板进行修改——只能存成模板格式，且会丢失某些图表信息。 鼓励大家根据实际情况添加自己特殊的内容进去；对于确实没有的项目，则是在其后写“无”，不允许随意删减模板中的项目 文档质量（4） 活动缺陷发现密度 软件需求规格评审缺陷发现密度 (个/页) 软件需求规格评审发现的缺陷数 / SRS文档页数 用户文档评审缺陷发现密度 (个/页) 用户文档评审发现的缺陷数 / UM文档页数 系统测试计划评审缺陷发现密度 (个/用例) 系统测试计划评审发现的缺陷数 / ST用例数 概要设计评审缺陷发现密度 (个/页) 概要设计评审发现的缺陷数 / HLD文档页数 集成测试计划评审缺陷发现密度 (个/用例) 集成测试计划评审发现的缺陷数 / IT用例数 详细设计评审缺陷发现密度 (个/页) 详细设计评审发现的缺陷数 / LLD文档页数 单元测试计划评审缺陷发现密度 (个/用例) 单元测试计划评审发现的缺陷数 / UT用例数 编码评审缺陷发现密度 (个/KLOC) 代码评审发现的缺陷数 / 代码规模 文档质量（5） 缺陷引入密度 软件需求缺陷引入密度