计算机软件开发项目管理规范

1、计算机软件开发项目管理规范 YNQB/QB0001-2004云南旗标软件企业标准1 主题内容与适用范围32 引用标准33 软件开发项目管理一般原则331 建立完善的评审机制3311 评审内容33111 阶段评审33112 功能评审4312 评审机构43121 阶段评审机构43122 功能评审机构432 项目成果保护与共享54 项目组织541 项目组织机构542 对外协调643 项目外包6431 外包评估7432 外包合同7433 外包资金7434 文件7435 其他75 项目实施851 计算机软件开发流程划分8511 按软件生产周期划分8512 按软件生存周期划分8513 从项目管理角度来划分

2、952 软件开发期各阶段的时间分配953 软件开发的要求与规则9531 软件开发各阶段流程及要求105311 可行性与计划研究阶段105312 需求分析阶段105313 设计阶段125314 实现阶段135315测试阶段145316 其他14532 软件开发规则155321 项目各阶段的承接155322 编码规范155323 软件开发过程控制166 产品定制与生产1861产品定制与生产发生在项目存续期间的1962产品定制与生产发生在项目结束后的197 文档编制1971 文档编制1972 文档使用对象208 文档管理219 资源配置2291 人力资源22911 招聘22912 培训22913 项

3、目人员配给229131 项目主管领导229132 项目经理239133 设计人员239134 编程人员249135 测试人员249136 文档管理人员249137 用户24914 开发成果保护2592 资金25921 资金来源25922 资金拨付25923 资金使用259231 采用新技术的项目资金的使用259232 采用成熟技术的项目资金的使用2593 设备（包括软件设备和硬件设备）25931 设备采购25932 设备配置25933 设备使用2510 项目预算/核算25101 预算25102 核算2511 奖励与惩罚25111 评审25112 奖励26113 惩罚261 主题内容与适用范围本

4、规范规定了在开发一般商业计算机软件项目时应该遵循的统一的基本要求。本规范适用于软件项目特别是重要软件项目的开发工作。对于非重要软件项目，可以参照本规范规定的子集简化执行。本规范是云南旗标软件组织软件开发项目的一般性指导文件，可以作为组建项目组、编制开发文档、制订开发计划、组织软件开发过程的基本依据。可以依据本规范制订其他相关标准，如程序代码编写规范、评审规范。2 引用标准GB/T 11457 软件工程术语GB 8566 计算机软件开发规范GB 8567 计算机软件产品开发文件编制指南GB/T 12505 计算机软件配置管理计划规范3 软件开发项目管理一般原则31 建立完善的评审机制在计算机软件

5、开发的整个过程当中，建立完善的评审机制以对项目中涉及的人员、成本、进度、项目成果、学术等各个方面进行全面的评审是必要的和必需的。这不但是成本及项目进度控制的需要，也是项目组内或项目组间以及项目组同其他部门间沟通的需要，还可以借此开展学术上的讨论，丰富和提高项目组技术知识水平和项目管理水平。311 评审内容3111 阶段评审阶段评审是一项重要的评审活动。在项目进行的每一个阶段完成后，都必须组织本阶段工作成果的评审，否则，不允许进入下一个项目阶段。在阶段评审中，应着重评审以下内容：1、 人员：工作态度、沟通2、 项目阶段成本3、 项目进度4、 阶段成果5、 学术3112 功能评审功能评审是针对软件

6、实现功能方面的评审，它着重的是软件的各个模块是否符合用户的最终需求，界面布局是否合理，代码实现是否简单有效，程序运行是否高效，操作是否方便、是否符合习惯等。在功能评审中，要求构建相应的评测环境，如果是数据库系统，还应产生足够的记录数以模拟实际环境。模拟数据的产生可参照下表执行：系统规模评测记录数备 注小规模5万行年数据量在5万行以下中规模50万行年数据量在5万至50万行大规模100万行年数据量在50万行以上312 评审机构对于任何一项评审，经由项目经理牵头，成立由相关人员组成的评审机构予以评审。3121 阶段评审机构阶段评审机构可以是常设机构，也可以根据情况临时成立。该机构人员结构应该由公司技

7、术主管、项目主管领导、相关行业专家、相关技术专家、质量控制工程师等组成。该评审机构人数应该不少于三人，采取一票否决的评审方式进行评审。3122 功能评审机构功能评审只在项目组内进行，由项目负责人（项目经理）根据情况临时成立，评审完后即行撤消。功能评审人员由项目负责人、项目技术主管、除实现者外的其他功能实现人员组成。功能评审人数不少于三人，并且应该为奇数，采取投票方式进行评审，得票超过一半即通过评审。32 项目成果保护与共享原则上，项目成果及其产权属于公司所有。为了保护公司利益和项目知识产权，项目组在运行时，必须充分考虑项目开发期中的安全性、连续性和一贯性。具体来说，可以采取如下几方面的措施：1

8、、 项目中同一任务必须至少有两个人完全清楚。2、 各种设计资料、开发文档必须保留至少两份副本。3、 所有资料（包括源代码）必须定期备案。备案以后，所有修改应及时更新，保证项目成员手中的资料必须与备案资料完全一致。4、 在条件允许时，尽量采用成对编程的方法进行代码编制。这样的话，可以保证资料及代码的共享性，不至于项目组成员离开时，项目出现瘫痪。4 项目组织规定计算机软件开发项目的组织与运作方式。41 项目组织机构项目组采用项目经理负责制。在项目执行期内，项目经理直接对项目主管领导负责，不受其他部门及领导的约束。在人事上项目组成员（包括项目经理）隶属于他所在的编制部门，行政上接受部门经理的领导。项

9、目组内所有成员必须服从项目经理的安排及调度。在必要的时候，项目经理经请示有权变更项目组成员或取消项目组成员的项目参与资格。项目组可采用下图所示的结构组建：项目经理设计人员代码实现测试人员文档管理项目主管领导用户代表图一 项目组组织结构在上图中，项目主管领导可不视为项目组成员。设计人员：指进行可行性研究、需求分析、概要设计、详细设计及数据库设计的人员。该工作可以由项目组内其他成员担任。代码实现人员：指具体进行程序代码编写的人员。该工作根据项目具体情况可以是非本公司人员。代码实现的主要依据是数据库设计说明书、概要设计说明书、详细设计说明书及其他需求说明书和相关资料。测试人员：指负责程序功能测试及B

10、ug查找的人员。该工作可由代码实现人员充任，但必须交叉进行，自己编写的代码须由其他人员检查、测试。文档管理人员：指项目存续期内负责日常工作文档及用户手册、操作手册、开发进度月报等文档的编制和管理的人员。该工作可由项目组内其他人员充任。设计人员、代码实现人员和测试人员应完成自己份内的文档编制，可参考以下第6条执行。用户代表：用户代表这一角色在项目组中，是一个相当重要的角色。他应是能充分了解用户需求的人：精通业务、熟悉管理、熟悉企业组织结构及内部运作方式，并能够不经或略经培训即能充分理解和参与制订项目任务、要求、目标等重要设计的人。可以说，对于项目的成功与失败，用户代表这一角色起着至关重要的作用。

11、用户代表应至少有一名，并不限数目。42 对外协调项目经理应在项目启动时向财务部门提供项目预算方案及资金使用计划。项目组接受财务部门的经济监督，有义务按公司的财务调度计划安排资金的使用。项目组成员应该经常与售前售后服务人员及用户（包括用户代表）交流，充分掌握用户的底层需求。在必要时，项目组成员可以申请资金用于现场调研。在必要的时候，项目组成员有义务协助营销人员搞好产品的推广销售工作。但，此时发生的任何费用不在项目开发费里开支。43 项目外包项目任务可以以外包的形式完成。外包可整体外包，也可只将部分模块外包。根据情况，项目任务可外包给公司内部其他项目组，也可外包给公司以外的组织或个人。431 外包

12、评估软件项目在外包前必须进行外包评估，只有当评估认为可以外包时，才能将项目外包。评估时应着重考虑以下方面：1、 否有利于新技术的获得2、 是否有利于降低开发成本3、 是否有利于缩短开发周期432 外包合同外包任务必须签定外包合同。合同上必须至少载明以下内容：任务名称，任务内容、要求及目的，进度计划，完成日期，开发费用，开发结果交付方式，违约责任等。433 外包资金外包任务所需资金在项目开发费里列支。由项目经理提出计划，在得到主管领导及总经理批准后实施。资金使用不应一次性支付完毕，而应当按进度逐步支付，并且在外包合同完成时，应至少滞留30%的资金用于预后处理（包括调试、测试分析、修改完善）。待整

13、个项目完成，并经用户验收合格投入使用后，方可付完所有外包开发费。434 文件在项目外包时，我公司可提供需求分析、概要设计、数据库设计说明书、详细设计说明书、项目开发计划、测试计划及其他必要文件等相关资料。在外包任务完成时，承包方应交回合同规定的所有文件，包括程序源代码、模块开发卷宗、测试分析报告及合同规定的其他文件。435 其他在条件允许时，可尽量将项目任务外包，公司内部最好只做可行性研究、需求分析、概要设计等上层设计。这样，我们就可以以少量的资源投入而获得更多更好的开发成果和经济效益。外包合同履行期间，项目经理有责任和义务监督合同的履行及外包任务的进度，以保证整个项目的进度计划。在合同履行出

14、现问题时，项目经理应采取果断措施，最大限度地为公司挽回损失。如果项目经理不能决绝，应立即请示主管领导，直至总经理。5 项目实施51 计算机软件开发流程划分511 按软件生产周期划分每个软件项目从启动到结束，最终都会有一个确定的生产周期，从这个角度来说，计算机软件开发流程可分为如下六个阶段：需求分析概要设计详细设计编程测试集成测试其中需求分析及概要设计属于上层设计。对于大型项目来讲，应该进行这两个项目的设计，而对于小型项目或者是开发周期要求很紧的项目而言，经总经理或主管领导批准，也可不进行这两项设计。512 按软件生存周期划分一项计算机软件，从出现一个构思之日起，经过这项软件开发成功投入使用，直

15、到最后决定停止使用，并被另一项软件代替之时止，被认为是该软件的一个生存周期。一般地说这个软件生存周期可以分成以下六个阶段：可行性与计划研究阶段需求分析阶段设计阶段 实现阶段测试阶段运行与维护阶段513 从项目管理角度来划分根据项目管理的理论，所有的项目都要经历五个阶段：起动阶段计划阶段执行阶段控制阶段结束阶段一般地，我们按第二种方式（即612）组织软件开发。52 软件开发期各阶段的时间分配软件生存周期对不同的软件来讲，会有相当大的区别，但开发期内各阶段的时间需求比例大致相当，因此，我们可以就一般的开发过程拟制一个参考进度安排方案，如下表所示：表一 软件开发期各阶段时间分配流程102030405

16、060708090100可行性与计划研究阶段需求分析阶段设计阶段实现阶段测试阶段该表可作为制订软件开发项目进度计划的参考。53 软件开发的要求与规则软件开发是一个复杂的系统工程，它要求有组织、有计划、有规则地多方位合作进行，它不可能是一个或某几个人的单独的行为，或他们的行为合并。这就要求在整个开发期间内，项目组成员必须按照一定的规则和要求完成开发周期内各阶段的工作。因此，制定一整套切实可行的开发规则无疑是非常重要的。531 软件开发各阶段流程及要求5311 可行性与计划研究阶段在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编

17、制的文件。对于小规模的软件项目，在征得用户的同意、并经项目主管领导或总经理批准后，可不进行本阶段的工作。可行性与计划研究阶段工作流程如图二所示。客户要求初步调查明确问题编写材料可行性研究制订开发计划签署合同评审和审批可行性研究报告（初步）项目开发计划项目取消图二 可行性与计划研究阶段工作流程需求分析5312 需求分析阶段图三 需求分析阶段工作流程调查环境需求分析修订开发计划制订确认测试计划编写用户手册评审(修订)项目开发计划（概要）用户手册修改概要设计可研阶段软件需求说明书数据需求说明书（确认）测试计划在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求

18、和设计约束，确定对文件编制的要求，作为本阶段工作的结果，一般地说，软件需求说明书、数据要求说明书和初步的用户手册应该编写出来。对于一个软件开发项目来讲，需求分析是非常重要的，只有明白了用户在硬件及软件方面的需求，我们才能够进行软件设计，并最终开发出符合用户需求的实际可行的软件来。但，对于一个新的项目来说，往往无法确知用户到底需要什么，导致无法很好地制定软件开发的目标、方向、要求及方式。对于需求明确的项目，对于需求不明确的项目，功能模块逐步细化程序模块接口设计程序模块过程设计模块测试方案制订评审模块开发卷宗修改图五 详细设计阶段工作流程实现阶段概要设计详细设计说明书系统总体设计功能模块总体结构设

19、计数据库或数据结构设计制订组装测试计划评审（组装）测试计划修改图四 概要设计阶段工作流程详细设计需求分析数据库/结构设计说明书概要设计说明书5313 设计阶段设计阶段可以细分为概要设计及详细设计两个步骤。在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块的划分、功能的分配以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文件包括：概要设计说明书、详细设计说明书和测试计划初稿。对于小规模的软件开发项目，可直接进入详

20、细设计步骤，而忽略概要设计步骤。5314 实现阶段程序编码单元测试编写手册评审操作手册修改图六 实现阶段工作流程测试阶段详细设计用户手册模块开发卷宗在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始编写模块开发卷宗，并且要完成用户手册、操作手册等面向用户的文件的编写工作，还要完成测试计划的编制。图八 确认测试阶段工作流程强度测试执行确认测试闭幕分析测试结果手册核验开发总结评审(确认)测试报告项目开发总结报告修改运行维护组装测试用户手册操作手册执行组装测试计划分析测试结果评审（组装）测试报告修改 图七 组装测试阶段工作流程确认测试实现阶段5315测试阶段测试

21、阶段可分为两个阶段：即组装测试阶段和确认测试阶段。在测试阶段，该程序将被全面地测试，已编制的文件将被检查审阅。一般要完成模块开发卷宗和测试分析报告，作为开发工作的结束，所生产的程序、文件以及开发工作本身将逐项被评价，最后写出项目开发总结报告。测试终结并通过，该项目即终结。5316 其他下一次开发要求图九 运行和维护阶段工作流程运行管理评审报告维护修改重新测试修改文件评审软件问题报告有关文件修改确认测试软件修改报告在整个开发过程中（即前五个阶段中），开发集体要按月编写开发进度月报。在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改。修改过后应及时补充或

22、修改相关文档，务使所有文档必须准确反映最终结果。532 软件开发规则5321 项目各阶段的承接在各个阶段的工作完成后，经评审，工作成果应提交主管领导或总经理批准之后方可进入下一阶段。如果工作成果被驳回，应根据处理意见重新论证并提出修正方案，再次报请批准。各阶段的承接应该遵循如图十流程所示进行。没有经过评审或未经批准的阶段成果不允许流入下一阶段，也不能启动下一阶段的工作。否上一阶段阶段成果评审批 准下一阶段通过否是否批准否是图十 软件开发各阶段承接处理基本流程修改5322 编码规范项目开发小组应根据不同的开发工具分别制订一套适合于小组内所有成员的代码编写约定规范，之后所有程序员的代码均应按该约定

23、规范进行编写和检查。不符合规范的代码，项目负责人可以责成程序员重新编写，直至所有代码符合约定规范的要求。对于同一项目，在程序代码的编写上，应该采取同样的风格，并严格按照约定的方式编写，不能各程序员自成一套。程序界面（包括窗体模式、窗体布局、调色等）也是一样，各个模块间要保持同样的风格和布局。务使整个程序看起来如同一个人编写完成的。每一个模块头部应加注释块，描述模块名称、版本号、设计者、设计日期、版权、功能简要说明、本模块调用的单元列表以及调用本单元的模块列表等内容。对于模块中重要的代码段，应予详细注释，在代码修改时，也应同步修改相应的注释，不用的注释应及时删除。对于函数、过程，要说明功能用途、

24、输入参数、返回值、以及版本、设计日期等。采用面向对象的开发方法，进行程序设计。尽量不定义全局变量，而应将全局变量定义为属性，以供其他模块以对象属性的方式进行调用。对于数据库的设计，应规定表、视图、存储过程、触发器以及字段的命名及注释方法。所有本公司产品，均应采用同一标准。每一个数据库在定义完成时，应增设如下全局表：表定义表，字段定义表，视图、存储过程及触发器定义表。这些表用于描述整个数据库各元素的创建方式和过程。使用这些表，我们可以方便地对数据库进行维护，可以重新构建整个数据库结构，并可作为元数据用于在应用程序中自动初始化用户界面。作为重要的维护工具以及用户使用手册内容之一的数据库结构模型，需

25、采用专用数据库建模工具认真编制，并发布在项目组共享的开发平台上，以方便开发期中项目组各成员随时查询使用。数据库结构如有变动，也应及时修改该模型。5323 软件开发过程控制程序设计过程控制参考如图十一所示方法进行。如图所示，项目开发周期可分为若干个迭代周期，每个迭代周期又由若干个工作日组成。迭代周期可以看作是软件开发过程中一个完整的功能模块的实现周期，是一个不可细分的工作时段。日常工作中，须以迭代周期为基本单元来组织软件开发。当然，项目规模比较大的话，可以有多个迭代周期同时进行，不同的迭代周期各自完成编码、测试、审核与集成发布，互不干扰，但相互依存。交叉审核，指的是代码的审核，交叉审核用以调试代

26、码、排查编码错误及代码优化，其目的是使程序代码更加优美、功能实现简单而有效。交叉审核是内部审核，是程序员间的审核。而功能审核指的是程序模块在实现外部功能（包括界面、事务处理功能）方面的审查，要求有用户的高度参与，而不仅指是测试员的工作。测试与功能审核要求测试人员尽可能找出软件的Bug，还要求用户能就功能方面提出修改意见和建议，最终完全达到用户的需求。需要说明的是，此处的审核与531中的评审是不一样的，后者指的是项目各阶段最终成果的检查与审核，是一种公司的内部考评、监督机制和行为，是项目审核。而前者的范围却小得多，是项目组内部的行为，是功能上的审核，还要求有用户的充分参与。如果采用的是成对编程的

27、开发方法，图中下班前的交叉审核一项实际上已经变化成为编程全过程的相互检查、测试和审核，因此可不进行下班前的交叉审核。每 个迭 代周 期继续功能模块编码完成测试集成、发布用户修改功能审核图十一 软件开发过程控制每 工作 日编 码测 试每日晨会（项目负责人主持）交叉审核（下班前）下一个迭代周期软件开发过程中，应强调如下几点：1、要求用户的高度参与。可以说，用户的参与程度直接影响项目的成败。用户可作为强有力的测试人员，还必须充当审核成员之一，确保功能模块能充分实现用户需求。如果项目组内没有用户参与，可将集成好的功能模块交给用户测试，但要求用户测试完成后提交测试报告，测试报告需详细记录参与人员、测试过

28、程、测试结果、意见及建议等以供程序修改完善之用。修改完成后再次交还用户测试，如此周而复始，直至该功能模块完全满足用户需求为止。2、如条件允许，可以采用成对编程的方法进行日常软件开发，这样既可以提高效率，也可以尽可能地减少程序错误、减少返工，并且保证任何一行程序编码都至少有两个人清楚，以保证开发成果的集体共享性。对于小项目，可以采用交叉审核的方法进行，某程序员的代码由另一程序员检查、调试，出现问题时可以及时修改。交叉审核应该在每天工作结束前进行。3、以尽可能小的迭代周期（功能模块开发周期）组织开发，同步测试、逐步集成和发布。完成一个功能，测试、集成和发布一个功能，然后进入下一个迭代周期。在每个迭

29、代周期内，应在分析与设计完成后，组织审核，只有审核通过后才能进入下一个迭代周期。4、应建立一个让整个项目组共享的测试、集成和发布环境，以方便所有成员动态掌握整个项目的进展情况，利于有效地相互沟通，并能保证项目组内所有成员随时获得的都是项目成果的最新版本。5、项目存续期内，要求项目组成员必须统一工作地点，以保证信息交流与问题解决的通畅和及时性。6、每天工作前应由项目负责人（项目经理或其指定代理人）主持每日晨会，听取进度汇报、调整资源配给、督促项目进度、协调关系、解决问题。每日晨会可控制在15分钟以内。对于小的项目，可以不进行每日晨会，由项目承担人定期或不定期向项目负责人汇报和协商即可。7、项目开

30、发进度计划采用自下而上的方法逐步汇总制订。即每个项目成员编写其分配工作的相应计划，然后逐级向上汇总，最终合并成为整个项目进度计划。各成员在制订计划时，可能会对项目估计不足而过于乐观或出于某种目的而过分消极，因此，项目负责人应组织有相关专家及公司领导参与的论证和评估，务使开发进度计划尽量合理，便于操作、监督和考核。8、如无特殊需要，尽量不安排项目组成员加班或延长工作时间，让项目组各成员随时保持旺盛的精力，以确保项目开发质量。9、应注重保护项目成果，在项目任一事务中，要求至少有两名人员同时参与和熟悉（在项目组的人员配置上应加与考虑）。6 产品定制与生产产品定制指的是根据不同的用户需求及应用环境，将

31、软件的各功能模块按需组成成品的过程，其中包括软件授权。产品生产则指软件产品的拷贝、包装、运输等。产品定制与生产一般可分为两种情况：61产品定制与生产发生在项目存续期间的如果产品的定制与生产发生在项目存续期间，应由项目经理指定项目成员负责完成，不再成立单独的定制与生产机构。62产品定制与生产发生在项目结束后的如果产品的定制与生产在项目结束后才发生，应成立专门的定制与生产机构负责处理。当然，作为公司常设机构的软件开发部，可以成立一个专门处理软件定制与生产的工作小组，这样，在产品开发成功后，随即将产品的定制、拷贝、包装等工作移交给该小组，并由其组织日常生产。当然。为了节省开支和提高公司效率，该小组成

32、员可以是兼职的。7 文档编制71 文档编制在软件开发项目的各个阶段内，将会产生大量的文档。这些文档描述、记录了项目的整个开发过程，也是软件开发的主要成果。这些文档对项目的管理、软件的最终运行及维护起着至关重要的作用。因此，对于任何一个项目参与者来说，开发文档的编制是一项重要的工作内容。在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文件编制的要求，作为本阶段工作的结果，一般地说，软件需求说明书、数据要求说明

33、书和初步的用户手册应该编写出来。在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块的划分、功能的分配以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文件包括：概要设计说明书、详细设计说明书和测试计划初稿。在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始编写模块开发卷宗，并且要完成用户手册、操作手册等面向用户的文件的编写工作，还要完成测试计划的编制。在测试阶段，该程序将被全

34、面地测试，已编制的文件将被检查审阅。一般要完成模块开发卷宗和测试分析报告，作为开发工作的结束，所生产的程序、文件以及开发工作本身将逐项被评价，最后写出项目开发总结报告。在整个开发过程中（即前五个阶段中），开发集体要按月编写开发进度月报。在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改。对于一项软件而言，其生存周期各阶段与各种文件编写工作的关系可见表一，其中有些文件的编写工作可能要在若干个阶段中延续进行。表1 软件生存周期各阶段中的文件编制件阶段文可行性研究与计划阶段需求分析阶段设计阶段实现阶段测试阶段运行与维护阶段可行性研究报告项目开发计划软件需求

35、说明书数据需求说明书测试计划概要设计说明书详细设计说明书数据库设计说明书模块开发卷宗用户手册操作手册测试分析报告开发进度月报项目开发总结软件问题报告软件修改报告72 文档使用对象对于使用文件的人员而言，他们所关心的文件的种类，随他们所承担的工作而异。管理人员：可行性研究报告项目开发计划模块开发卷宗开发进度月报项目开发总结报告开发人员：可行性研究报告项目开发计划             软件需求说明书     

36、0;       数据要求说明书             概要设计说明书             详细设计说明书             数

37、据库设计说明书             测试计划             测试分析报告维护人员：设计说明书测试分析报告模块开发卷宗用户：用户手册          操作手册8 文档管理在整个软件生存期中，各种文档作为半成品或是最终成品，会不断地生成、

38、修改或补充。为了最终得到高质量的产品，达到上节提出的质量要求，必须加强对文档的管理。1、 软件开发小组可设一位文档保管人员，负责集中保管本项目已有文档的两套主文本。两套文本内容完全一致。其中的一套可按一定手续，办理借阅。2、 软件开发小组的成员可根据工作需要在自己手中保存一些个人文档。这些一般都应是主文本的复制件，并注意和主文本保持一致，在作必要的修改时，也应先修改主文本。3、 开发人员个人只保存着主文本中与他工作相关的部分文档。4、 在新文档取代了旧文档时，管理人员应及时注销旧文档。在文档内容有更动时，管理人员应随时修订主文本，使其及时反映更新了的内容。5、 项目开发结束时，文档管理人员应收回开发人员的个人文档。发现个人文档与主文本有差别时，应立即着手解决。这常常是未及时修订主文本造成的。6、 在软件开发过程中，可能发现需要修改已完成的文档，特别是规模较大的项目，主文本的修改必须特别谨慎。修改以前要充分估计修改可能带来的影响，并且要按照：提议、评议、审核、批准和实施等步骤加以严格的控制。7、 项目开发结束时，应将所有开发文档整理后归档。归档时应按国家档案管理的有关规定