软件测试文档管理
测试计划的目标是规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要
测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险（IEEE829-1998关于软件测试文档的标准）。测试计划需要明确测试目标、人员、地点、责任、测试特性清单、测试阶段、测试进度、任务分配、结果度量统计以及风险和问题。同时要明确定义软件的质量和测试的进入、退出规则。
测试计划是软件测试人员和产品开发小组之间的交流的主要方式，它把软件拆分为具体
特性和可测试项并分派到具体人员，但没有指明如何测试。
测试设计说明为提炼测试方法，明确指出设计包含的特性和相关测试，如果要求完成测
试还应明确指明测试用例和测试的程序，指定特性通过/失败的规则。其目的是组织和描述针对具体特性需要进行的测试，但不给出具体的用例或者执行测试的步骤。
测试说明主要包括内容：标识符、要测试的特性、方法、测试用例确认（用例的高级描
述，如等价划分）、通过/失败规则。
测试用例说明用于编写用于输入的实际数值和预期输出结果数值以及使用具体测试用
例产生的对测试程序的任何限制，该说明应尽可能压缩，要控制其详细程度使其能用于具体的指导操作。编写测试用例的目标要求满足：组织、重复性、跟踪和测试证实。
主要包括内容有：标识项、测试项、输入说明、输出说明、环境要求、特殊过程要
求、
用例之间的依赖性。
软件测试文档管理和控制
https://www.doczj.com/doc/4b16515355.html,发布者：ooaa 来源：网络转载发布日期：2013年12月27日文章评论发表
文章
测试工作看起来比较简单，但是实际上并不是如此容易，它所涉及的内容是很多，而且还要充分地认识到它前期的工作和后期的工作。其中前期的工作就是非常仔细的测试设计和围绕测试设计所选择的恰与其分的测试用例。另外这里的所说的后期工作就是如何对问题进行分析判断问题在各个部分中存在和分布的情况，这是一件不容易的事情。这需要充分的测试实战经验和能够合理地、有序地对问题进行分析。这需要有充分的数据资源。基于以上情况，我将综合五年来我在测试工作上经验和行动。根据测试部数以百计的测试文档。较系统地综合归纳测试的工作。
总述
前期的测试文档的设计主要集中在测试大纲的编写、测试设计（包括测试方法的挑选）的编写，然后根据测试设计的要求从测试用例库中精心地挑选具有典型的用例。
对测试前期的文档设计的要求就是能够根据产品总体设计和产品详细设计中得到要测试的东西，因为软件测试的路子千千万万条，首先绝对不能保证面面俱到，另外在测试中重复性的路径测试过多。所以即要保证通过测试设计做到能够抓住重点，而且还要保证撒出的网的比较大。因此在前期工作中建立的测试大纲和测试设计看起来的就是很重要的，可以说它是指明了方向。（它们二者之间
的关系将在图1）。
测试大纲和测试设计建立出来后，只能说前期测试工作的骨头架子已经打起来。下面就是要求填血肉的了，这就是在测试设计上选择能够适应的测试用例。我认为在前期文档编写中测试设计的编辑是最耗时间和精力的。诚然编写一个很好的测试设计是很不容易的，但是难度之二就是选择测试用例。为了缓解工作压力，我希望能够建立一个比较充实的测试用例库，库中可以进行有效分类地保存。当要对一个产品的某一部分使用一种测试方法，可以很容易寻找到相应的测试用例。
图1
后期的文档的编写将重点集中在对数据的处理和统计，如将对测试过程中所发现的问题进行系统的整理和统计（主要是通过各种数据统计图表进行分析）。另外还要对本次测试中的测试用例进行统计和入库处理。这一点是非常关键，因为在后期的文档编写就是要通过进行数据的各种统计来找出测试中的教训和经验。
另外后期的文档的编写工作还可以很好地支持测试各项的工作顺利地开展。
如测试用例库的建立可以很好地支持的测试的前期文档的编写，并且将给测试人员给予极其大的帮助。测试问题库的建立和使用，不仅可以给测试人员极大的帮助，而且它也成为了测试用例库的很好的素材，并且将有助于开发人员的工作（即可以起到跟踪问题的效果）。
测试问题库和测试用例库的建立和使用。关键就是在于这两个库的数据一定要详实。将每一种情况的都要做到分类量化。便于进行各种数据统计。
在数据统计中，常用的方法主要就是表格，典型的分析表格就是柏拉图。另外现在比较的重要的图表分析方法就是问题分析趋势图。建立问题分析趋势图对于监管测试工作是一个非常好的方法。做到这一点不是一件非常容易的事情。对监管人要有很好的要求。
后期文档的管理和控制参照图2
图2 测试前期的文档——测试大纲
测试大纲可以说一份指导性的文件。它所起到的作用可以说有以下两种作用。首先保证在测试中所要测试的面基本上可以起到完全覆盖的作用。其二是大
纲中的内容不仅是首先要求填写的，有一部分是要求使用者（即为测试者）自行填写的。
测试大纲的建立和使用是从1998年开始的，经过多年的使用后，发现原先希望它能够起到的作用的并没有达到。2001年，测试部着手对测试大纲进行仔细地修改。
后来发现，在建立了测试规范后，测试大纲的作用逐渐明朗起来了。将它和具体的测试设计分家和结合。完成了测试大纲作为总纲地位的确定。
对于测试大纲的设计要求来说，要求不一定很详细。要求的就是面面俱到，对于每一个面做到点到为止。保证当使用测试大纲时，不会出现遗漏的现象。
新版的测试大纲在设计上和思想的考虑，比以前的测试大纲有了突破。
1、标准化处理：标准化的处理，是对测试文档建立和管理的基本要求。测试大纲的每一条测试路径都要求进行标准管理。
2、加入测试方法：在测试大纲中加入测试方法的描述，即在测试某一部分时，也要主要地说明它的测试方法。
3、权值的加入：在测试大纲中每一条测试路径后面都要求加入必要的权值。而且要求在加权值时要对各种参数都要有要求，必须在进行一次主要的测试时，要都要修改权值。而且最好是两次。头一次是预期值，第二次是测试完后的实际权值。这样可以进行合理地比较。现在看起来这是极其重要的（加权值的方法非常重要。在下面将较完整的描述）
测试大纲应该是一种常新常换的文件，如在权值的设定上，每一次运行系统程序或应用程序，所对应的权值都会发生相应的变化。
测试大纲在设计上应该注重在简洁性、实用性。能够方便测试人员使用。内容结构如下：
图3 测试前期的文档——测试设计
测试前期中最重要的文档就是测试设计，这里先简单地说明为什么要在黑盒测试中考虑到做到测试设计。首先将测试操作分为两部分，这两种方法都是相对极端的。第一种方法就是测试凭着自我感觉进行。进行这种测试时不需要打腹稿，想到哪里就测试到哪里。第二种方法就是测试的每一步骤都要设定下来并加以文字说明，如象记录到打开一个记录，然后光标定位到某一个字段，输入一个字节。
可以说这两种方法都存在各自的误区，第1种方法可以说盲目性太大，并且重复性和遗漏性也比较高。第2种方法在测试设计上又过于僵硬和死板，操作起来没有更好地变通性。
所以基于以上两种情况，测试设计就出现了。可以说它是在考虑了上述两种情况之后，所考虑的一种变通和调节。我们要从测试设计中体现一种思想，这种
思想就是在进行功能测试中，我们即要追求测试深度的渐进，还要考虑到测试广度的延伸覆盖的程度。
从另一个方面来说，测试设计的编写实际上使对测试大纲中某一部分的放大。可以说测试大纲的前期的全部编写可以由测试主管或者测试项目负责人来进行。而测试设计可以分配给各个测试人员来编写，谁来负责一部分就由谁编写相关的测试设计。
对编写测试设计的要求是比较高，主要要求如下：
1、要求在编写相关的测试设计，要具有一定深度和较大的面。一定的深度的意思就是要切中要害。通过仔细地研究各种技术文件和被测软件，对自己认为可能会出现问题的地方做到更深一层的思考和判断。较大的面就是所铺开的网尽可能的大。不要存在遗漏，这样做也可以避免重复性操作的产生。
2、对所了解的测试方法也要有要求，测试大纲中的测试方法只是相当于一个概念性的。而在测试设计中所要求的测试方法就要比较具体。比如在时钟测试中，在走时的精确度的测试，可能就要标注上要用的方法就是比较法。各种的测试方法有很多种，在黑盒测试中主要的测试方法就有：等价类、边界值、正交法和判定表这样的方法。
3、在测试设计中对于除了正常的功能测试还需要进行那些特殊的测试，如强度测试、回归测试和安全测试等都必须加以标注。
好的测试设计，可以帮助测试人员理清整个测试的脉络。并且可以很有效地
查找到测试。这是一份非常重要的文档，它也和测试大纲一样，为了更高地寻找和发现到错误，并且在每一次测试中进行修改。
在测试设计中也要求分清测试项目中哪些是重点，这是贯穿到整个测试。测试设计中的深度的意思也是针对该点。没有重点就不能谈到深度的要求。测试设计经过多次地修改，每一次都能够确定相关的重点。测试设计中的重点需要进行二次评审。第一次是在进行实测前的确定重点。第二次确定重点是要在实测后重新划分。第一次的确定主要靠的是经验。
在测试设计中确定各种测试方法，具体到什么地方使用什么样的测试方法，这是极其关键的。在这一点上需要测试人员的经验的培养。
现在以一份较好的测试设计加以说明：
测试设计上的编写实际上就是让测试人员在测试前理清一遍自己的测试思路。这是非常关键的。所以对于测试设计上来说，就要求进行必要的测试设计方面的评审工作。
测试前期的工作文档——测试设计和测试用例库的结合
测试部自2001年4月份就强调测试用例的编写，在目前并没有很好的系统地对测试用例进行研究的情况。目前就是将测试用例全部记录下来。在测试用例比较多的时候，就必须将它象测试问题库一样建立起来测试用例库。测试用例库的具体建立和操作在这里不做过多的说明。
这里想说的就是将测试用例库中的测试用例和测试设计建立相关联的方法。
让我们来看看测试用例吧，找出它们之间的规律。看起来针对一个产品的测试用例有成千上万条。但是通过采取测试方法或者测试范围找规律，只有最多不超过一百处具有较相同规律的测试用例。
再看看测试设计，固然编好测试设计，需要的是测试人员的经验。但是如果有一个强大的数据资料库的支持。就可以为建立一个高效率的测试设计节省了很多时间。而且可以保证你所编写的测试设计非常精辟。
比如在选择需要进行安全性测试的情况（即要通过各种正常、异常的操作突破密码的防范）。在测试设计中编写到这一部分时，就可以调出以前对安全性测试的资料。可能就会有十几种供你选择。
测试的强大资料库——测试问题库和测试用例库
测试工作中我们会记录下大量的数据资料。其中宝贵的资料是很多的。我们自己有一个习惯，就是喜欢有书面记录下成绩。当然这是很重要的。但是经过我多年的工作下来。我已经越来越不喜欢用书面记录下记录。因为这些内容如果没有专人来管理。很容易会成为压箱底的东西。
你的资料需要得到灵活的运用。这就需要靠这些手段来完成。因此我建立了测试问题库这一方式来保存数据资料。
测试问题库在许多的高科技开发公司都已经存在。有很多已经实现了自动入库的方式（即当你出一份测试问题报告，测试问题报告中的信息就已经编写到库中了）。
我强调的是在目前要求测试问题库中的信息可以包括很多，并且要记录下来有价值的内容。因为测试问题库建立起来，第一不仅要交给测试人员使用，还要帮助开发人员跟踪问题和修改问题。第二是一个完善的测试问题库还可以为建立问题分布柏拉图和问题分布分析趋势图都有很多的帮助。
从下图中可以看出，测试问题库中包含的信息是比较多的。通过库可以了解到被测软件的一些基本信息资料。有描述的比较完善的问题过程、问题现象和问题分析的内容。同时为了便于跟踪记录，有两个栏位就是为了跟踪问题的发展（特别是对未被改正的问题）。
测试人员通过使用测试问题库，可以非常方便地查询问题，另外可以自己在编写测试文档过程中确定重点的方向。
另外测试问题库的确立和使用，还有更为深远的意义。测试问题库的建立实际上为建立动态地对测试问题的控制和管理打下了良好的基础。
同样，为了配合测试工作的顺利高效的进行，我们要求建立第二个资料数据
库，这就是测试用例库。关于测试用例库的重要性的介绍中，前面在简要介绍测试前期的文档和后期的文档作用已经通过图表描述了。
这里说测试问题库的建立是对测试结果的保存和使用。而测试用例的建立就是对测试过程的保存和使用。
这两个数据库极其关键和重要，我从事测试工作多年，比较遗憾的事情就是一直在研究对测试工作如何进行有效率的控制，而不是人为地控制。其实现在才发现通过测试问题库和测试用例库的使用就是可以进行有效的控制。
测试后期的工作文档——数据统计图表
在介绍测试两个巨大的数据库的内容时，已经提到可以通过图表描述，那么这里有两种图表加以介绍。
一种的图表中就是柏拉图的方法。柏拉图的内容可以通过一个具体的例子来进行说明。
问题分析的柏拉图的内容是由两个坐标组成的，一个是以柱状图说明在哪些软件模块的问题分步数目。第二个是以线状图来表示出在总的问题量每一个模块所占有的问题的百分比的分布。
通过问题分布的柏拉图可以很容易看出哪些问题是很容易出现问题的地方。柏拉图的作用：第一可以便于可以根据柏拉图进行问题数据统计分析。另外如果正在分阶段地进行对一个大系统的测试。通过柏拉图还可以进行分阶段的问题技术分析。通过每一个阶段的柏拉图来找出这个大系统的问题分布的一般规律。通过柏拉图来分析出高风险的问题区域。这一点是非常关键的。对于在测试大纲中设定权值有非常大的作用。
问题分析的第二中图表的分析就是使用缺陷分析图表。这是一种非常管用的分析图表。它是用来记录在测试过程中的问题的变化（也称‘打开/关闭’图表[打开的意思就是寻找发现问题，而关闭的意思就是修改问题]）。
在一个测试过程，关于发现和修改问题都有一定的规律。
这是一个p5v6.80问题趋势图，我们可以把这个图的变化趋势分为三个阶段（上升阶段、中间阶段和平缓（结尾）阶段）。上升阶段就是指刚刚测试产品时，在该阶段会发现大量的问题。累计问题数目趋势线会上升很快，甚至非常陡，这是非常棒的。第2个阶段就是中间阶段。这个阶段就象我们上山一样。有陡然上升的阶段，也有平缓的阶段。造成这种情况的是存在着很多我们在测试中不可预知的东西，属于测试稳定阶段。第3阶段在经历了累计问题数目阶段和测试稳定阶段。被测试的软件基本上趋于稳定。在正常状态下该问题的曲线应该平缓。所说的就是接近直线。当然可能达到这一阶段的时间是可以预计的，或者是不可很好地预计。但是我们可以通过该分析图的下面两条线做出判断。一条线是真实地记录了每一天发现的问题个数，第二条线则就是描述了对这些问题的哪些问题进行了改正。
因为我们知道对问题的改正实际上就增加产生问题的新的隐患。所以每次改正问题后直接的就是在上图中的趋势线出现波动。我们希望的每一次改动问题都不会让趋势图发现很大的波动影响。第二就是在到了第3阶段时下面的两条线都可以逐渐接近横轴。并且没有什么样大的变化。
我们看出在问题分析我们灵活地运用柏拉图和缺陷分析图表分析被测模块的高风险性和在测试过程考察被测的效果。总之一句话，我们通过问题分析，可以更好地保证软件的可靠性。这一点至关重要。
测试后期的工作文档——测试报告和未改问题集
测试报告是组成测试后期工作文档的最重要的技术文档。测试报告主要有五个部分组成：1）测试条件创建的描述；2）柏拉图的画制；3）根据柏拉图进行问题分析，指明高风险区；4）列出未改问题集；5）总体分析评价。
关于第2部分和第3部分在前面已经做了介绍。下面我先说明第1部分和第5部分内容。至于第4部分内容我将单独说明。
第1部分——测试条件创建的描述：在软件测试中，建立一个良好的测试环境。所有在测试中涉及到的条件（包括工具、机器配置、编译环境）以及在相关的企业标准中所涉及到的内容（如指环境测试、强度测试和电气测试）。一个好的测试环境，可以排除掉一些不存在的问题。也为寻找和修改问题提供了便利。我们认为测试环境应该尽可能和开发调试中的环境相类似，甚至相同。
特别如果在测试中测试到专门的情况时，如功耗测试或者灵敏度测试时，在建立测试环境时应该由开发人员确认。其实在建立测试环境时，应该由专业人士认可。
正是由于建立一个良好的、完整的和准确的测试环境是那么重要。那么我们在编写测试报告时就应该将一个你所建立的一个较完整的测试环境系统说明清
楚。包括上述所说明的内容（详细的内容可以参照国家软件文档设计标准）。在特定的情况。如在描述测试电气特性的时候，可以将接线图绘制出来。我们希望能够重点注意一下建立测试环境上，并且能够较详细地说明出来。因为上面也说过。出现问题的地方在建立错误的测试环境会有很大关系。关于建立一个测试环境的事情。在后面将详细总结。
第5部分——总体分析评价：请千万不要忽视掉总体分析评价的内容，当你的测试报告快要写完的地方，并且感觉很累的时候。希望你能够在写总体分析评价时能够休息一下大脑。想一想在经过一个时间不短的测试后，如何能够对最终的产品给出一个令人信服的结论。因为总体分析评价的内容可能是在开评估会时就有可能关心的。
现在我们应该认为总体分析评价是最客观的。最好不要存在什么主观的意念。那么如何才能使总体分析评价具有很强的客观性和准确性。我想有应该有两点应该注意就是：
（i）实事求是，不能够就人论事。把你自己的主观感觉强加在总体分析评价中，特别你自己的喜怒哀乐。当然你也不能受外界因素的影响，力求做到按照既定的原则处理。
（ii）在要求总体分析评价的客观性中，我想如何要一个总体分析评价客观性，最好的办法就是收集和整理各种客观实际的数据资料。关于收集和整理的客观数据资料。我们已经在介绍数据统计分析中说明了一些。但是我们还有很多方法可以来运用。关于这一点的详细介绍我将在《对各种测试资料的灵活统计分析》
一文详细论述。下面我只蜻蜓点水的说明一下。
易度文档管理产品介绍 版本: 2.0 版权: 上海润普网络信息技术有限公司 日期: 2009.3.18 章节索引 1. 企业为什么需要文档管理 2. 易度文档管理 3. 产品设计理念 3.1. 全面的文档管理 3.2. 以知识管理思想为指导 3.3. 简单易用，高用户体验 4. 功能和特点 4.1. 强大的全文检索和高级搜索 4.2. 文档和图纸在线预览 4.3. 图片自动缩略预览 4.4. 全方位的安全防护 4.5. 柔性、易用的权限控制 4.6. web文件夹:批量上传和下载 4.7. 实用的批量元数据处理 4.8. 清晰的树状文件夹结构，支持剪切移动与复制 4.9. 创新的分组标签筛选功能 4.10. 在线编写文本文件 4.11. 评注和订阅：多人文档协作 4.12. 个人文件和共享 4.13. 实用的文档审核流程 4.14. 简单易用的文档多版本支持 4.1 5. 文件回收站：数据误删和恢复 4.16. 开放、可靠、可扩展的存储 4.17. 现有数据导入工具 4.18. 工作管理平台模块之一，功能可扩展 4.19. 开放API，可集成 5. 产品创新和独特性 6. 系统配置 6.1. 推荐硬件配置 6.2. 网络
6.3. 系统软件 7. 实施过程 8. 产品版本比较 9. 附：润普公司介绍 1. 企业为什么需要文档管理 文档是企业重要的智力资产。在企业中，文档一般都一电子的形式存在，比如微软的.doc格式，或者.- pdf格式，纯文本.txt格式等；从内容上，可能商务合同、会议记录、产品手册、客户资料、设计文档、推广文案、竞这些文档，可能是过程性质的，也可能是公司正式发布的文档，可能处在编写阶段，也可能已经存档不- 得再修改。 企业在进行文档管理的过程中，经常会碰到以下的问题： 1. 文档存储分和混乱，导致文档查找非常困难，员工效率受到影响。 2. 文档版本繁多，审核流程多样化，出现使用错误的文档版本、审核不全面的现象，导致了严重的后- 果。 3. 文档泄密，导致公司重大损失。 4. 员工走了，交接不全，相关文档也丢失了，工作难以接续。 5. 文档共享协作不方便，让各员工之间工作配合非常低效。 事实上，企业要求能够可靠的存储集中文档，方便的获取需要文档，有效的协作编写文档，安全的控制- 文档的读写权限。 2. 易度文档管理 易度文档管理系统，ZDMS，是润普公司针对上述问题和需求，基于知识管理的理念，开发的一套用于- 企业电子文档、电子资料管理的软件系统，帮助企业管理各种形态、各个阶段的文档资料。 ZDMS为企业中的个人、团队、以及部门，提供海量文档资料的安全集中的存储空间，采用了领先的文- 档权限控制和SSL加密技术，支持文档的共享和审核协作管理，并提供强大的文档检索机制。 易度文档管理解决方案，是易度专业人员在ZDMS产品的基础上，为企业提供系统的初始化、培训、客- 户化定制、系统集成、上线支持的全套软件和咨询服务，为企业提供交钥匙的专业服务。 3. 产品设计理念 3.1. 全面的文档管理 通过易度文档管理系统（ZDMS）企业可以更高效地管理文档的整个生命周期：创建、修改、版本控制- 、审批程序、存储、查询、重用以及归档。 3.2. 以知识管理思想为指导 文档是企业智力资产最重要的承载形式。文档管理，本质上是知识管理的重要组成部分。企业进行文档- 管理，是为了让文档服务于人，服务于企业的核心业务，最终能提升是企业的核心竞争力。 易度文档管理，在设计上特别从知识管理的角度给予支持。比如文档的订阅评注、文档的标签分类、全- 文搜索等，都是从知识的提升、获取等角度专门设计的。
目录 1.项目管理 (1) 1.1项目范围管理 (1) 1.2项目时间管理 ......................................................................... 错误!未定义书签。 1.3项目里程碑 (6) 1.4培训方案 (6) 1.5技术支持与售后服务 (7) 1.6项目进度管理 (8) 信息系统项目建设项目管理文档 1.项目管理 1.1项目范围管理 （1）概述 项目范围管理就是要明确项目目标是什么，界定哪些工作必须做，并将项目目标分解到可以独立分包的程度，形成工作分解结构（WBS），并以此作为控制项目范围变更的基准。即项目范围管理是确保项目包含且只包含项目所必须完成的工作。 很多项目经常由于有做不完的报表、解决不完的问题而导致项目无法验收，很大一部分原因就是因为项目的范围没有定义清楚或者项目范围经常发生无可控制的变更所致。事实证明，缺少正确的项目范围定义和范围的核实是导致项目失败的主要因素。 因此，项目管理最重要的也是最难做的一项工作就是确定项目范围，并使项目范围在控制中，这就是项目范围管理的范畴，即项目范围管理就是项目该做什么，不该做什么，以及确保该做的事情必须做到，不该做的事情不能做。 在项目的规划阶段和蓝图设计阶段的前期，我们通过售前阶段的资料和项目
现场的需求调研，确定项目该做什么，这就是经常说的定义项目范围。 （2）管理内容 1、定义项目范围 1）定义项目范围重要的参考资料和依据一般如下： ●项目售前实施方案； ●项目主合同； ●许可软件通用条款及清单； ●咨询实施服务和工作任务书； ●支持服务条款； ●战略合作承诺书； ●建设单位内部正式发问的项目实施意见书。 2）口头承诺 定义范围除了依据上述可见的项目资料外，售前阶段的一些口头承诺也是定义项目范围的重要信息来源，因此在项目准备阶段与售前进行内部交接时，一定不能忘记交接口头承诺的内容，实践证明，口头承诺的往往是在项目实施过程中难以交付的或者需求范围不好清晰界定的，正是范围管理的难点。 通过范围定义，可形成详细的范围说明书，以及对项目管理计划进行更新。 2、项目范围 范围是指项目所提供的产品或服务的总和，它包括以下两种含义： ●产品范围：产品或者服务的特性与功能，其衡量标准为产品要求，即产 品需求说明书。 ●项目范围：为交付所需产品（具有特定属性和功能）和服务而必须完成 的工作，其衡量标准为项目管理计划、项目范围说明书、WBS及WBS词汇 表。 项目实施的产品范围的描述一般应该通过两个维度，即产品功能模块和公司范围两个维度，清晰的描述出哪些公司具体实施、哪些产品的功能模块，对于集团型企业一定要以企业法人作为实施的公司范围。借用EXCEL建立功能模块与法人
文档管理流程XX天音通信XX 分销信息系统 编写人员: AMT咨询项目组 编写日期: 2001年11月12日更新日期: 2001年11月12日文档编码: 天音/0001 文档版本: 1.0 批准人员:
文档控制 修改记录 审阅记录 分发记录 按照项目文档管理流程的要求，文档接收者请注意： 如果您收到本文档的电子版，请打印本页并在相应的栏目中签字。 如果您收到本文档的原件，请直接在相关栏目中签字。
目录 文档控制ii 修改记录ii 审阅记录ii 分发记录ii 文档概述4 目的4 适用X围4 相关文档4 项目资料库5 目的5 资料库结构及分类5 文档控制流程7 目的7 流程说明7 文档控制标准8 目的8 软件标准9 编写标准9 命名标准11 附录：项目文档模板12
文档概述 目的 本文档主要明确所有交付成果及其项目文档的管理流程和标准，并将在XX天音通信XX 分销信息系统的全过程中加以运用和控制。 适用X围 本文档就项目文档管理中的以下方面进行明确。 ?项目资料库 ?文档控制流程 ?文档控制标准 ?文档发布流程 本文档管理流程将同时适用于参与实施的AMT实施项目组（包括实施联合体科讯公 司实施组及PTC公司技术支持组等）和XX天音项目组的所有成员。 相关文档 1.AMT项目实施文档标准
项目资料库 目的 按照本项目的实施X围和总体策略，将建立集中管理的项目资料库，便于各类实施 文档的更新、审阅、批准和发布管理。同时将在项目开始的初期，快速建立企业信 息门户作为项目组进行沟通和文档发布的交互平台，本文档中确定的资料库分类及 其他相关的流程都将作为此信息平台建立的需求标准之一。 项目资料库由以下要素构成： 1.主目录 2.目录 3.子目录 4.主页 5.标题 资料库结构及分类 主目录与本实施项目有关的所有文档及其他相关资料将统一存放在“分销信息系统 资料库”主目录内。 目录根据实施项目的X围和总体策略，将按照各个分项目对目录进行分类： 1-项目管理文档 2-财务管理系统实施文档 3-人力资源管理系统实施文档 4-项目设计管理系统实施文档 5-项目施工管理系统实施文档 6-办公与企业信息门户系统实施文档 7-集成与技术开发文档 子目录按照AMT实施方法论(AIM)和项目管理方法论(PJM)，建立以下分类子目录：
模版集萃 综述 在程序员的日常工作中，除了编写代码之外，还免不了需要编写各种技术文档。一个编写良好的技术文档在项目中能够很好地建立沟通与协作，起到很积极的作用。因此，编写技术文档也就成为了程序员技能提升的很重要的一面。 为此，我们特意收集了一些在项目开发过程中经常用到的文档模板，这些模板包括格式和简单的写作说明，相信能够帮助大家编写出更加高效、实用的技术文档。在收集过程中，我们十分注重其实用性，以确保每个模板的价值，而且对于一些重要的文档提供了多个模板。 为了方便大家查找，我们将收录的57模板分为以下几类： 项目及开发管理类：包括立项前的分析，立项后的计划、以及进度跟踪、风险控制方面的文档模板，共计16个； 需求分析类：明确清晰的需求，是项目成功的基础，在此收集了在需求分析过程中所将使用到的文档模板，共计14个； 系统分析与设计类：包括体系结构设计、高层设计、详细设计、数据库设计等6个相关文档模板； 软件质量保证类：软件测试是质量保证的关键活动，在此收集了软件测试相关的11个文档模板； 其它类：除此之外，还收集了关于用户手册、软件维护等方面的10个文档模板，其中还有一个软件过程规范的示例。 另外，值得说明的是，文档模板只是为文档的编写提供一个基础，在实际的编写过程中，你可以根据自己的需要进行必要的剪裁和增补。
一、项目及开发管理类 1.1 可行性研究报告(ISO标准) 编者说明： 在立项时，应该对项目进行综合分析，探讨项目的经济、社会、技术可行性，从而为决策提供基础。该模板为ISO标准文档模板，其不仅适用于软件项目，对于其它的系统项目也适用。 1. 引言 1.1 编写目的 [编写本可行性研究报告的目的，指出预期的读者。] 1.2 背景 a.[所建议开发的软件系统的名称；] b.[本项目的任务提出者、开发者、用户及实现该软件的计算站或计算机网络；] c.[该软件系统同其他系统或其他机构的基本的相互来往关系。] 1.3 定义 [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。] 1.4 参考资料 [列出用得着的参考资料。] 2. 可行性研究的前提 [说明对所建议开发的软件的项目进行可行性研究的前提。] 2.1 要求 [说明对所建议开发的软件的基本要求。] 2.2 目标 [说明所建议系统的主要开发目标。] 2.3 条件、假定和限制 [说明对这项开发中给出的条件、假定和所受到期的限制。] 2.4 进行可行性研究的方法 [说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的，摘要说明所使用的基本方法和策略。] 2.5 评价尺度 [说明对系统进行评价时所使用的主要尺度。] 3. 对现有系统的分析 [这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能
项目管理文档填写及流程管理规范 1 项目文档管理 (2) 1.1项目前期 (2) 1.2项目中期 (2) 1.3项目后期 (2) 1.4项目整个周期 (3) 1.5硬件及网络布线 (3) 2 项目管理流程 (3) 2.01项目管理整体流程 (3) 2.02项目立项单流程 (5) 2.03项目调研流程 (5) 2.04项目计划审批流程 (6) 2.05项目预算审批流程 (6) 2.06客户上线准备调查报告 (6) 2.07出差申请单 (6) 2.08项目周报 (7) 2.09新增需求单 (7) 2.10项目费用申请单 (7) 2.11问题集审批流程 (8) 2.12项目转售后服务流程 (8) 2.13奖金制定流程 (8) 2.14洽谈报告 (9)
1项目文档管理 1.1项目前期 《项目整体进度步骤》 《系统功能要求》 《客户资料信息表》 《项目立项表》（产品版本、项目人员） 《项目实施计划表》《项目实施详细时间表.》 《项目预算表》 《系统初始设置表》 《进驻现场准备表》（与系统相关的其他项目时间进度、如设备到长时间、人员安排、机房建设） 《标准培训文档》 1.2项目中期 《服务器设备调试报告》（服务器配置数据库配置） 《POS设备调试报告》（pos机配置型号、系统安装配置） 《其他设备调试报告》（条码打印、电在称、价签、等等） 《培训确认报告》（培训功能模块、时间、人数、部门、负责人确认） 《系统正式使用确认报告》包括转入售后部分 1.3项目后期 《文档提交确认单》 《售后服务单》
1.4项目整个周期 出差申请单（参考财务） 《项目增项需求单》（新需求或变动） 《项目周报》 《项目分配奖金表-部门》 费用申请单（参考财务单据，应用项目当中设备采集、或特殊费用申请单）系统问题集（将项目中遇到的系统问题和客户的一些意见记录成文件，为产品升级提供依据） 1.5硬件及网络布线 《设备验收清单》（包括第三方软件） 网络布线报告（由第三方布线公司提供） 2项目管理流程 2.01项目管理整体流程
软件文档管理指南 范围 本标准为那些对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南。本标准的目的在于协助管理者在他们的机构中产生有效的文档。 本标准涉及策略、标准、规程、资源和计划，管理者必须关注这些内容，以便有效地管理软件文档。 本标准期望应用于各种类型的软件，从简单的程序到复杂的软件系统。并期望覆盖各种类型的软件文档，作用于软件生存期的各个阶段。 不论项目的大小，软件文档管理的原则是一致的。对于小项目，可以不采用本标准中规定的有关细节。管理者可剪裁这些内容以满足他们的特殊需要。 本标准是针对文档编制管理而提出的，不涉及软件文档的内容和编排。 引用标准 下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均为有效，所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。 计算机软件开发规范 计算机软件产品开发文件编制指南 软件工程术语 定义 本标准采用下列定义，其他定义见。 文档 一种数据媒体和其上所记录的数据。它具有永久性并可以由人或机器阅读。通常仅用于描述人工可读的内容。例如，技术文件、设计文件、版本说明文件。 文档（集）；文档编制 一个或多个相关文档的集合。 文档计划 一个描述文档编制工作方法的管理用文档。该计划主要描述要编制什么类型的文档，这些文档的内容是什么，何时编写，由谁编写，如何编写，以及什么是影响期望结果的可用资源和外界因素。 文档等级 对所需文档的一个说明，它指出文档的范围、内容、格式及质量，可以根据项目、费用、预期用途、作用范围或其他因素选择文档等级。 软件产品 软件开发过程的结果，并推出供用户使用的软件实体。 软件文档的作用 ) 管理依据； ) 任务之间联系的凭证； ) 质量保证； ) 培训与参考；
国内外知识管理软件比较 1.国内知识管理软件 （1）盛大麦库 这是一款采用云计算概念的网络文件管理平台“麦库”，通过这个平台，用户可以实现在线免费的文件保存。盛大麦库是一个免费、永久在线，安全的个人知识管理平台。您可以用电脑、手机等设备，随时随地在麦库里保存笔记、备忘、写文档，存资料，并可以方便的整理和分享。麦库为用户提供的核心服务包括记录笔记备忘、管理知识文档、批量文件上传、共享我的知识等。据悉，麦库目前处于测试期，用户注册可以获得500M的空间，通过邀请好友加入麦库可以实现空间扩容。同时，麦库的内容可以分享到开心网、人人网、豆瓣等主流SNS平台。 盛大麦库的特点是采用云计算的技术，永远不会丢失自己保存的知识资料。（2）Wiz（为知） Wiz(为知个人知识管理PKM)是一款基于互联网的个人知识管理软件产品；它以用户知识数据为核心，提供实用便捷的工具集；可以强制捕捉网页文档。 Wiz能快记快找，它基于互联网，可在多台电脑和手机上使用，支持分类、标签、全文检索等组织方式；具有快速、便捷、移动互联、数据开放、易于扩展等特点； Wiz可以当作轻量级的wiki、sharepoint来使用，可以用于时间管理、文档管理、任务管理、离线网摘、日记博客、桌面便笺等。 Wiz以统一的存储机制、安全机制、全文检索机制、插件机制和同步机制为基础，由为知管理器(WizExplorer)、同步工具(WizSync)、编辑器(WizHtmlEditor)、查看器(WizViewer)、网页捕捉工具、文档导入工具、日历(WizCalendar)和便笺(WizNote)等组成。同时还使用到知识在线服务(Wiz Online)，与多类移动终端(WizMobile)进行数据同步；也可以使用专用的订阅工具(WizReader)订阅分享的内
**科技股份有限公司软件项目管理制度 目录
项目开发计划 编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发工作。编制内容要求如下： 1引言 1．1编写目的 说明编写这份项目开发计划的目的，并指出预期的读者。 1．2背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1．3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1．4参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； C．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2项目概述 2．1 工作内容 简要地说明在本项目的开发中须进行的各项主要工作。 2．2主要参加人员 扼要说明参加本项目开发工作的主要人员的情况，包括他们的技术水平。 2．3产品 2．3．1程序 列出需移交给用户的程序的名称、所用的编程语言及存储程序的媒体形式，并通过引用有关文件，逐项说明其功能和能力。 2．3．2文件 列出需移交给用户的每种文件的名称及内容要点。 2．3．3服务 列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持的级别和服务的期限。 2．3．4非移交的产品 说明开发集体应向本单位交出但不必向用户移交的产品（文件甚至某些程序）。 2．4验收标准 对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。 2．5完成项目的员迟用限 2．6本计划的批准者和批准日期 3实施计划
软件项目文档管理 文档管理是项目管理中最关键的部分之一，文档管理的规范与否关系到项目进展状况，关系整个项目工作的效率与效益。抓住项目规范、文档规范，是推进公司发展的推动力。 一、文档管理的目标 文档管理的目标是将软件项目各阶段的各种文档资料（如各种图表、文字说明材料、数据文件、报告等）有效地进行组织、规划、归类，使文档的获得、归类、查找和提取更容易。最终目的就是使其成为软件项目中的一部分，与其他的项目内容构成完整的知识。 二、文档管理的作用及方法 1、文档管理的作用 软件文档也称文件，通常指的是一些记录的数据和数据媒体，它具有固定不变的形式，可被人和计算机阅读。它和计算机程序共同构成了能完成特定功能的计算机软件。文档本身就是软件产品，没有文档的软件，不成其为软件，更谈不到软件产品。软件文档的编制在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档，对于充分发挥软件产品的效益有着重要意义。 文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间的多种桥梁作用。软件开发人员在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或工作报告，这些计划和报告都要提供给管理人员，并得到必要的支持。管理人员则可通过这些文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料，我们称此为用户文档。以上三种文档构成了软件文档的主要部分。 2、文档管理的方法 文档管理方法是最好有一套文档管理系统，作用：记录文档的变更、修改、增加、删除等操作情况，有效管理好软件项目各阶段的文档。为使用文档的人员提供了集中统一、安全的管理文档的渠道，实现了文档管理的电子化。 三、文档管理的任务 1、确定文档管理的范围 2、确定文档管理的内容和分类 3、记录文档的变更情况 4、建立编制、更改和维护文档的各种规程 5、不断检查已建立起来的过程，以保证符合各种规程并遵守有关标准和指南 6、在文档中存在商业秘密或技术秘密的情况下，还应注意保密 四、文档管理任务的实现 1、确定文档管理的范围 在一个软件项目中可能需要管理的文档有： （1）可行性研究报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施的方案，说明并论证所选定实施方案的理由。 （2）项目开发计划：为软件项目实施方案制定出具体计划，应该包括各部分
本人从网上收集整理的几个需求管理工具- 项目管理 需求是研发团队工作的起点，很多研发团队的开发过程混乱的源头都在于需求管理没有做好。这里是本人收集整理的几个需求管理系统，希望对大家有点帮助。 Rational RequisitePro Rational RequisitePro是一个强大、易用、集成的需求管理产品。而通过与Rational系列软件产品的广泛集成，大大扩展了RequisitePro及其他产品的功能，给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响，帮助验证所有的规划需求被交付物所满足、降低项目风险。 网址：https://www.doczj.com/doc/4b16515355.html,/software/awdtools/reqpro/ IBM Rational DOORS IBM Rational DOORS前身是大名鼎鼎的Telelogic DOORS，被IBM收购后更名为IBM Rational DOORS。DOORS 是最老牌的企业需求管理套件，通过使用DOORS/ERS，可以帮助企业更有效地进行沟通并加强协作与验证，从而降低失败的风险。通过对整个组织实施多种需求管理的方法，可以使项目的管理更加透明。它可以使企业跨越地域与组织的边界来按国际化的方式运行。
网址：https://www.doczj.com/doc/4b16515355.html,/software/awdtools/doors/ Borland CaliberRM Borland CaliberRM是一个基于Web 和用于协作的需求定义和管理工具，可以帮助分布式的开发团队平滑协作，从而加速交付应用系统。CaliberRM 辅助团队成员沟通，减少错误和提升项目质量。CaliberRM 有助于更好地理解和控制项目，是Borland 生命周期管理技术暨Borland Suite 中用于定义和设计工作的关键内容，能够帮助团队领先于竞争对手。CaliberRM提供集中的存储库，能够帮助团队在早期及时澄清项目的需求，当全体成员都能够保持同步，工作的内容很容易具有明确的重点。此外，CaliberRM 和领先的对象建模工具、软件配置管理工具、项目规划工具、分析设计工具以及测试管理工具良好地集成。这种有效的集成有助于更好地理解需求变更对项目规模、预算和进度的影响。 网址：https://www.doczj.com/doc/4b16515355.html,/us/products/caliber/index.html
GB/16680－1996软件文档管理指南 1 范围 本标准为那些对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南。本标准的目的在于协助管理者在他们的机构中产生有效的文档。 本标准涉及策略、标准、规程、资源和计划，管理者必须关注这些内容，以便有效地管理软件文档。 本标准期望应用于各种类型的软件，从简单的程序到复杂的软件系统。并期望覆盖各种类型的软件文档，作用于软件生存期的各个阶段。 不论项目的大小，软件文档管理的原则是一致的。对于小项目，可以不采用本标准中规定的有关细节。管理者可剪裁这些内容以满足他们的特殊需要。 本标准是针对文档编制管理而提出的，不涉及软件文档的内容和编排。 2 引用标准 下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均为有效，所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。 GB 8566-88 计算机软件开发规范 GB 8567-88 计算机软件产品开发文件编制指南 GB/T 11457-1995 软件工程术语 3 定义 本标准采用下列定义，其他定义见 GB/T 11457 。 3.1 文档 document 一种数据媒体和其上所记录的数据。它具有永久性并可以由人或机器阅读。通常仅用于描述人工可读的内容。例如，技术文件、设计文件、版本说明文件。 3.2 文档（集）；文档编制 documentation 一个或多个相关文档的集合。 3.3 文档计划 documentation plan 一个描述文档编制工作方法的管理用文档。该计划主要描述要编制什么类型的文档，这些文档的内容是什么，何时编写，由谁编写，如何编写，以及什么是影响期望结果的可用资源和外界因素。 3.4 文档等级 level of documentation 对所需文档的一个说明，它指出文档的范围、内容、格式及质量，可以根据项目、费用、预期用途、作用范围或其他因素选择文档等级。 3.5 软件产品 software product 软件开发过程的结果，并推出供用户使用的软件实体。 4 软件文档的作用 a) 管理依据； b) 任务之间联系的凭证； c) 质量保证； d) 培训与参考； e) 软件维护支持； f) 历史档案。 4.1 管理依据 在软件开过过程中，管理者必须了解开发进度、存在的问题和预期目标。每一阶段计划安排的定期报告提供了项目的可见性。定期报告还提醒各级管理者注意该部门对项目承担的
软件产品认证管理方法文档 Software product certification management method doc ument 编订：JinTai College
软件产品认证管理方法文档 前言：办法是有关机关或部门根据党和国家的方针、政策及有关法规、规定，就某一方面的工作或问题提出具体做法和要求的文件。本文档 根据办法内容要求和特点展开说明，具有实践指导意义，便于学习和 使用，本文下载后内容可随意调整修改及打印。 “软件产品管理办法”一般是指“软件产品认证”，那 么《软件产品认证管理规定》有哪些相关法规呢?下面小泰给 大家介绍关于软件产品认证管理规定，欢迎阅读! 第一章总则 第一条为了加强软件产品管理，促进我国软件产业的发展，根据国家有关法律法规和国务院《鼓励软件产业和集成电路产业发展的若干政策》（以下简称《产业政策》），制定本办法。 第二条中华人民共和国境内的软件产品（含国产软件和 进口软件）经营与管理活动，适用本办法。 单位或个人自己开发并自用的软件以及委托他人开发的 自用专用软件不适用本办法。
第三条本办法所称的软件产品，是指向用户提供的计算机软件、信息系统或设备中嵌入的软件、或在提供计算机信息系统集成、应用服务等技术服务时提供的计算机软件。 本办法所称国产软件，是指在我国境内开发生产的软件产品。 本办法所称进口软件，是指在我国境外开发，以各种形式在我国生产、经营的软件产品。 第四条软件产品的开发、生产、销售、进出口等活动应遵守我国有关法律、法规和标准规范。任何单位和个人不得开发、生产、销售、进出口含有以下内容的软件产品：（一）侵犯他人知识产权的; （二）含有计算机病毒的; （三）可能危害计算机系统安全的; （四）含有国家规定禁止传播的内容的; （五）不符合我国软件标准规范的。 第五条信息产业部负责全国软件产品的管理，其主要职责是：
设计文档管理程序
目录 1 目的 (3) 2 适用范围 (3) 3 引用文件 (3) 4 定义 (3) 5 职责 (3) 6 工作要求和程序 (4) 7 附件 (5)
1 目的 为进一步提高建设工程项目文档管理和信息共享水平，确保文档的完整、有序和统一，更好的完成档案验收，特制定本程序。 2 适用范围 本程序适用于XXXXX制甲醇及转化烯烃项目设计文档的管理。 3 引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单或修订版均不适用于本标准。凡是不注日期的引用文件，其最新版本适用于本标准。 SEP-SPM-GS1001《中国石化项目管理手册》 中国石化建[2011]763号《中国石化固定资产投资项目设计管理规定》 SHSG-046-2005《工程设计文件签署规定》 4 定义 下列术语和定义适用于本标准。 4.1文档 文档是指在项目管理全过程中产生的与项目建设有关的所有书面文件和电子文件,包括管理文件和技术文件，如设计图纸、合同、公文、传真、电子邮件、图片、录音文件、录像文件、通讯报道、网页等。 4.2设计文档 设计文档即为与设计有关或为了完成工程设计而形成的文档。主要包括可行性研究报告、工程设计合同、总体设计、基础设计、详细设计、设计变更、竣工图、工程设计总结、设计质量事故报告、设计质量事故处理报告等。 4.3设计文档管理 设计文档管理即对设计文档包括编码、收发、登记、系统录入、发布、版本控制、借阅、使用、保管、整理、归档、鉴定销毁等的管理。 5 职责 5.1建设单位负责制定有关实施细则，负责设计文档管理，组织档案验收。 5.2设计单位按要求提供设计文档，进行设计文档管理。
软件文档知多少？ 如今，软件开发越来越复杂，软件功能也越来越丰富。而几乎所有成熟的商业软件，都是靠一个开发团队齐心协力的血汗结晶。“罗马不是一天建成的！”，当我们震撼于Microsoft Windows的惊世巨著的同时，也道听途说了微软公司软件工程是如何的完善规范。的确，集数百名员工几年的共同努力之大成，软件项目管理的成败是控制开发成本的关键环节。这里面，少不了贯穿其中的重要步骤----软件文档。 软件文档可以分为开发文档和产品文档两大类。 开发文档包括：《功能要求》、《投标方案》、《需求分析》、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》、《界面文档》、《编译手册》、《QA文档》、《项目总结》等。 产品文档包括：《产品简介》、《产品演示》、《疑问解答》、《功能介绍》、《技术白皮书》、《评测报告》、《安装手册》、《使用手册》、《维护手册》、《用户报告》、《销售培训》等。 一、开发文档 1. 《功能要求》--来源于客户要求和市场调查，是软件开发中最早期的一个环节。客户提出一个模糊的功能概念，或者要求解决一个实际问题，或者参照同类软件的一个功能。有软件经验的客户还会提供比较详细的技术规范书，把他们的要求全部列表书写在文档中，必要时加以图表解说。这份文档是需求分析的基础。 2. 《投标方案》--根据用户的功能要求，经过与招标方沟通和确认，技术人员开始书写《投标方案》，方案书一般包括以下几个重要的章节： 前言--项目背景、公司背景和业务、技术人员结构、公司的成功案例介绍等。 需求分析--项目要求、软件结构、功能列表、功能描述、注意事项等。 技术方案--总体要求和指导思想、技术解决方案、软件开发平台、网络结构体系等。 项目管理--描述公司的软件开发流程、工程实施服务、组织和人员分工、开发进度控制、软件质量保证、项目验收和人员培训、软件资料文档等。 技术支持--公司的技术支持和服务介绍、服务宗旨和目标、服务级别和响应时间、技术服务区域、技术服务期限、授权用户联系人等。 系统报价--软、硬件平台报价列表、软件开发费用、系统维护费用等。 项目进度--整个项目的进度计划，包括签署合同、项目启动、需求分析、系统分析、程序开发、测试维护、系统集成、用户验收、用户培训等步骤的时间规划。 3. 《需求分析》--包括产品概述、主要概念、操作流程、功能列表和解说、注意事项、系统环境等。以《功能要求》为基础，进行详细的功能分析(包括客户提出的要求和根据开发经验建议的功能)，列出本产品是什么，有什么特殊的概念，包括那些功能分类，需要具备什么功能，该功能的操作如何，实现的时候该注意什么细节，客户有什么要求，系统运行环境的要求等。这里的功能描述跟以后的使用手册是一致的。 4. 《技术分析》--包括技术选型、技术比较、开发人员、关键技术问题的解决、技术风险、技术升级方向、技术方案评价，竞争对手技术分析等。以《需求分析》为基础，进行详细的技术分析(产品的性能和实现方法)，列出本项目需要使用什么技术方案，为什么，有哪些技术问题要解决，估计开发期间会碰到什么困难，技术方案以后如何升级，对本项目的技术有什么评价等。 5. 《系统分析》--包括功能实现、模块组成、功能流程图、函数接口、数据字典、软件开发需要考虑的各种问题等。以《需求分析》为基础，进行详细的系统分析(产品的开发和
第6章 软件管理文档 6.1 管理文档概述 软件管 理文档 软件开发管理人员 软件开发人员 软件操作人员 用户维护人员 软件管理文档 项目开发计划测试计划测试分析报告开发进度报告开发总结报告 图6.1 管理文档的作用 图6.2 管理文档的组成 实用软件文档写作
实用标准文案 6.2 项目开发计划 6.2.1 项目开发计划书 6.2.2 工作分解结构 图6.3 工作分解结构6.2.3 项目里程碑与阶段性文档 图6.4 需求过程中的里程碑精彩文档
实用软件文档写作 6.2.4 项目进度 图6.5 项目进度过程 6.2.5 运用图和表描述项目进度 表6.1 任务的持续时间及其依赖关系 任务持续时间（天数）依赖关系T1 8 T2 15 T3 15 T1（M1） T4 10 T5 10 T2,T4（M2） T6 5 T1,T2（M3） T7 20 T1（M1） T8 25 T4（M5） T9 15 T3,T6（M4） T10 15 T5,T7（M7） T11 7 T9（M6） T12 10 T11（M8）
实用标准文案 精彩文档 图6.6 活动网络 图6.7 活动条形图 表6.2 任务—开发人员分配表
实用软件文档写作 任务开发人员任务开发人员T1 人员 1 T7 人员5 T2 人员 2 T8 人员3 T3 人员 1 T9 人员1 T4 人员 3 T10 人员2 T5 人员 4 T11 人员3 T6 人员 2 T12 人员3 图6.8 人员分配及时间表 6.2.6 风险管理 表6.3 一些可能出现的典型的风险 风险风险类型描述职员跳槽项目有经验的职员未完成项目就跳槽 管理层变更项目不同的管理层考虑、关注的事情会不同 硬件缺乏项目项目所需的基础硬件没有按期交付 需求变更项目和产品软件需求与预期的相比，将会有许多变化 描述延迟项目和产品有关主要的接口的描述未按期完成 低估了系统规模项目和产品过低估计了系统的规模 CASE工具性能较差产品支持项目的CASE工具达不到要求 技术变更业务系统的基础技术被新技术取代 产品竞争业务系统还未完成，其他有竞争力的产品就已经上市了
项目文档管理办法 （版本）
1 引言 1 .1编写目的 制订统一的文档管理办法及格式，对项目过程中产生的项目有关资料提供规范，便于在今后项目开展过程中对各项资料的查找和相互交流 ,以利项目开发及进展； 制订项目开发过程中的评审和查阅规范，明确相应的管理人员责任。 2 任务概要 2 .1工作内容 项目发展的过程中，随着项目逐步展开，会产生大量的设计方案文件、设计说明书、源代码、会议记录及培训资料等内容，对这些内容进行分类整理归档；同时根据项目需要，对有关文档在项目文档服务器上发布。 2 .2工作要求 项目部目前使用SVN管理项目文档，建立相应文档目录，根据要求适时添加文档并与相关人员（各专业组负责人）合作及时将文件归档，注意对项目信息的及时更新，以帮助各组人员获得最新信息。 2 .3工作程序 对于项目常规文档： 1.综合组对文档（纸质和电子版）收集及文档分类。 2.各专业组负责人负责对项目每个阶段过程中产生的文档资料进行
汇总，由负责人审核后将相关文档上传到SVN服务器相关目录（建立统一的项目文档目录，例如命名为“项目存档文档”）下。 3.项目进行每个阶段产生的各项文档资料包括：调研资料、设计方案文件/图、设计说明书、会议培训资料、汇报材料、报告文件、数据文档、文献等文档资料。 对于项目存档文档： 1.综合组对项目常规文档目录下的文档进行审核。 2.对阶段性重要的文件进行归档，文档管理员将其处理成PDF格式， 加入文档编号后上传到SVN服务器相关目录下。 注：各类存档文件均需提交由质量测试组审核。 3 文档管理 3 .1总则 3.1.1 所有重要文档集中管理，维护档案的安全与完整。 3.1.2 所有存档文件根据需要归档。 3.1.3 各项目专业组人员在工作中形成的具有参考价值的文件、材料由个人或该组负责人整理后报文档管理人员存档。 3.1.4 所有人员均有承担按时提交文档的义务和职责。 3.1.5 由专人负责项目文档管理工作。 3 .2范围 3.2.1 项目准备阶段 a. 与本项目有关的上级主管部门下达的规划和工作计划；
密级：内控 研发本部版本管理规范 V1.0 浪潮集团山东通用软件有限公司
目录 文档类别使用对象 (2) 1．引言 (3) 1.1目的 (3) 1.2范围 (3) 1.3术语定义 (3) 1.4参考资料 (4) 1.5版序控制记录 (4) 1.6版本更新记录 (4) 2．版本管理 (5) 2．1版本标识方法 (5) 2．1．1正式版本 (5) 2．1．2特殊版本 (5) 2．2目录结构 (5) 2．3文档的存放 (7) 2.3.1 当前版本和历史版本的存放 (7) 2.3.2 开发文档的存放 (7) 2.3.3 源代码的存放 (7) 2.3.4 SQL语句的存放 (7) 2.3.5发行文档的存放 (8) 2．4权限控制管理 (8) 3．更新管理 (8) 3．1源程序的修改 (8) 3．2已发布版本的维护及修改 (9) 3．3外出人员对产品的修改 (9) 3．4版本升级 (12) 3.4.1 版本升级原则 (12) 3.4.2 新版本的发布 (12) 3.4.3 安装盘制作步骤 (13) 4．备份管理 (13) 5．用户版本管理 (14)
文档类别使用对象 文档类别 该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。使用对象 该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相关人员。未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
1．引言 1.1目的 本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。 1.2范围 本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3术语定义 SCM Softwere Configuration Management缩写 SVM Software Version Management缩写 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确
ITSM四大管理工具的比较 很多人都知道，工具在ITSM中的地位要排在流程和人的后面，但是这并不说明工具就不够重要。与此相反，正是因为它担负着要把无形的流程固化下来的重任导致它永远不可能被忽视。如今，各家厂商ITSM 的工具所包含的广度越来越大，但在同时，单个工具的亮度也越来越被弱化。 具体来讲，IBM、HP和BMC、CA在工具拓展上呈现出两大截然相反的趋势。就前两者而言，虽然都在强调收购对象与本公司原有产品的优势互补，但是收购的重点显然并不一样。IBM就把其Tivoli的技术平台认为是IBM在ITSM产品上的核心部分，其中针对各个具体领域（比如监控）的软件工具是其价值所在；而HP对Peregrine的收购，说明其正在努力使其原有的OpenView Service Desk产品在标准化和定制化两个方向上能够左右逢源。另外，变更和配置管理数据库（CMDB）似乎已经是ITSM在现阶段的一个热点产品。它作为一个统一连接点与许多模块都相关联。但也有人指出，现在大炒变更和配置管理数据库的概念似乎也存在着一种要将用户带入一个在技术上不透明地带的趋向。 据META Group的观点，在2007年以前，大厂商的技术解决方案并不能完全实现流程整合。这也从另一个角度反映了谁能率先实现流程整合的功能，将在ITSM的竞赛中占得先机。 IBM IBM对目前的IT服务管理市场无疑非常看好。按照IBM大中华区软件集团市场总监左洪所说，目前中国的企业每天有一百万美金花费在IT服务管理上，而且这个市场正以超过20％的速度增长；而在另一方面，这个市场非常分散，几乎没有一个厂商占到超过15％的份额。IBM认为，这个市场未来将很快得以整合，而IBM本身所提供的的ITSM工具将在这场份额争夺战中具有相当强的优势。 IBM宣称，它的ITSM覆盖了所有的IT管理流程——从变更管理、配置管理、发布管理到信息生命周期管理等。IBM基于自有的中间件产品Tivoli、Rational、WebSphere和DB2，扩大了它在自主管理技术领域的创新，ITSM内含的“工具顾问（tool mentors）”可以帮助用户完成对ITIL描述的所有流程的部署。 值得一提的是，IBM Tivoli的变更和配置管理数据库（CCMDB）。与其他厂商不同，IBM认为这是一个将分散在多个数据库中的IT信息联合在一起的“虚拟”数据库。它可以为运行在数十个服务器上的应用提供一个单一的视图，以便IT人员根据变更和配置信息做出更准确的决策。这一产品将在2006年上半年进行有限发布，（最终将在2007年完成发布）。 HP 惠普公司拥有一种包括了基础设施和Service Desk流程功能的、可*集成的服务管理解决方案。在2005年4月份履新成为HP企业客户及公共事业集团软件部总经理的刘洪表示: “现在OpenView已经完成从技术到品牌的过渡阶段，正在转向行业解决方案。”而他说这番话的背景是惠普的软件收入中多一半是来自OpenView。为了品牌的一致性，惠普在过去一年中更新和新开发的软件，全部以OpenView命名，如今在OpenView这个品牌下总共有47款产品之多。 而从技术手段上看，惠普通过一系列的收购和研发投入，已使OpenView 从网络和系统管理扩展到应用管理，IT服务管理和业务流程管理，并且在身份管理和变更管理的产品技术上处于领先地位。 对于收购Peregrine公司一事，业界一度猜测这是否表明HP对本身的Open View Service Desk性