计算机软件开发项目管理规范.doc
《计算机软件开发项目管理规范.doc》由会员分享，可在线阅读，更多相关《计算机软件开发项目管理规范.doc（25页珍藏版）》请在冰点文库上搜索。
计算机软件开发项目管理规范YNQB/QB0001-2004
云南旗标软件有限公司企业标准
1主题内容与适用范围 3
2引用标准 3
3软件开发项目管理一般原则 3
3．1建立完善的评审机制 3
3．1．1评审内容 3
3．1．1．1阶段评审 3
3．1．1．2功能评审 4
3．1．2评审机构 4
3．1．2．1阶段评审机构 4
3．1．2．2功能评审机构 4
3．2项目成果保护与共享 5
4项目组织 5
4．1项目组织机构 5
4．2对外协调 6
4．3项目外包 6
4．3．1外包评估 7
4．3．2外包合同 7
4．3．3外包资金 7
4．3．4文件 7
4．3．5其他 7
5项目实施 8
5．1计算机软件开发流程划分 8
5．1．1按软件生产周期划分 8
5．1．2按软件生存周期划分 8
5．1．3从项目管理角度来划分 9
5．2软件开发期各阶段的时间分配 9
5．3软件开发的要求与规则 9
5．3．1软件开发各阶段流程及要求 10
5．3．1．1可行性与计划研究阶段 10
5．3．1．2需求分析阶段 10
5．3．1．3设计阶段 12
5．3．1．4实现阶段 13
5．3．1．5测试阶段 14
5．3．1．6其他 14
5．3．2软件开发规则 15
5．3．2．1项目各阶段的承接 15
5．3．2．2编码规范 15
5．3．2．3软件开发过程控制 16
6产品定制与生产 18
6．1产品定制与生产发生在项目存续期间的 19
6．2产品定制与生产发生在项目结束后的 19
7文档编制 19
7．1文档编制 19
7．2文档使用对象 20
8文档管理 21
9资源配置 22
9．1人力资源 22
9．1．1招聘 22
9．1．2培训 22
9．1．3项目人员配给 22
9．1．3．1项目主管领导 22
9．1．3．2项目经理 23
9．1．3．3设计人员 23
9．1．3．4编程人员 24
9．1．3．5测试人员 24
9．1．3．6文档管理人员 24
9．1．3．7用户 24
9．1．4开发成果保护 25
9．2资金 25
9．2．1资金来源 25
9．2．2资金拨付 25
9．2．3资金使用 25
9．2．3．1采用新技术的项目资金的使用 25
9．2．3．2采用成熟技术的项目资金的使用 25
9．3设备（包括软件设备和硬件设备） 25
9．3．1设备采购 25
9．3．2设备配置 25
9．3．3设备使用 25
10项目预算/核算 25
10．1预算 25
10．2核算 25
11奖励与惩罚 25
11．1评审 25
11．2奖励 26
11．3惩罚 26
1主题内容与适用范围
本规范规定了在开发一般商业计算机软件项目时应该遵循的统一的基本要求。
本规范适用于软件项目特别是重要软件项目的开发工作。
对于非重要软件项目，可以参照本规范规定的子集简化执行。
本规范是云南旗标软件有限公司组织软件开发项目的一般性指导文件，可以作为组建项目组、编制开发文档、制订开发计划、组织软件开发过程的基本依据。
可以依据本规范制订其他相关标准，如程序代码编写规范、评审规范。
2引用标准
GB/T11457软件工程术语
GB8566计算机软件开发规范
GB8567计算机软件产品开发文件编制指南
GB/T12505计算机软件配置管理计划规范
3软件开发项目管理一般原则
3．1建立完善的评审机制
在计算机软件开发的整个过程当中，建立完善的评审机制以对项目中涉及的人员、成本、进度、项目成果、学术等各个方面进行全面的评审是必要的和必需的。
这不但是成本及项目进度控制的需要，也是项目组内或项目组间以及项目组同其他部门间沟通的需要，还可以借此开展学术上的讨论，丰富和提高项目组技术知识水平和项目管理水平。
3．1．1评审内容
3．1．1．1阶段评审
阶段评审是一项重要的评审活动。
在项目进行的每一个阶段完成后，都必须组织本阶段工作成果的评审，否则，不允许进入下一个项目阶段。
在阶段评审中，应着重评审以下内容：
1、人员：
工作态度、沟通
2、项目阶段成本
3、项目进度
4、阶段成果
5、学术
3．1．1．2功能评审
功能评审是针对软件实现功能方面的评审，它着重的是软件的各个模块是否符合用户的最终需求，界面布局是否合理，代码实现是否简单有效，程序运行是否高效，操作是否方便、是否符合习惯等。
在功能评审中，要求构建相应的评测环境，如果是数据库系统，还应产生足够的记录数以模拟实际环境。
模拟数据的产生可参照下表执行：
系统规模
评测记录数
备注
小规模
5万行
年数据量在5万行以下
中规模
50万行
年数据量在5万至50万行
大规模
100万行
年数据量在50万行以上
3．1．2评审机构
对于任何一项评审，经由项目经理牵头，成立由相关人员组成的评审机构予以评审。
3．1．2．1阶段评审机构
阶段评审机构可以是常设机构，也可以根据情况临时成立。
该机构人员结构应该由公司技术主管、项目主管领导、相关行业专家、相关技术专家、质量控制工程师等组成。
该评审机构人数应该不少于三人，采取一票否决的评审方式进行评审。
3．1．2．2功能评审机构
功能评审只在项目组内进行，由项目负责人（项目经理）根据情况临时成立，评审完后即行撤消。
功能评审人员由项目负责人、项目技术主管、除实现者外的其他功能实现人员组成。
功能评审人数不少于三人，并且应该为奇数，采取投票方式进行评审，得票超过一半即通过评审。
3．2项目成果保护与共享
原则上，项目成果及其产权属于公司所有。
为了保护公司利益和项目知识产权，项目组在运行时，必须充分考虑项目开发期中的安全性、连续性和一贯性。
具体来说，可以采取如下几方面的措施：
1、项目中同一任务必须至少有两个人完全清楚。
2、各种设计资料、开发文档必须保留至少两份副本。
3、所有资料（包括源代码）必须定期备案。
备案以后，所有修改应及时更新，保证项目成员手中的资料必须与备案资料完全一致。
4、在条件允许时，尽量采用成对编程的方法进行代码编制。
这样的话，可以保证资料及代码的共享性，不至于项目组成员离开时，项目出现瘫痪。
4项目组织
规定计算机软件开发项目的组织与运作方式。
4．1项目组织机构
项目组采用项目经理负责制。
在项目执行期内，项目经理直接对项目主管领导负责，不受其他部门及领导的约束。
在人事上项目组成员（包括项目经理）隶属于他所在的编制部门，行政上接受部门经理的领导。
项目组内所有成员必须服从项目经理的安排及调度。
在必要的时候，项目经理经请示有权变更项目组成员或取消项目组成员的项目参与资格。
项目组可采用下图所示的结构组建：
项目经理
设计人员
代码实现
测试人员
文档管理
项目主管领导
用户代表
图一项目组组织结构
在上图中，项目主管领导可不视为项目组成员。
设计人员：
指进行可行性研究、需求分析、概要设计、详细设计及数据库设计的人员。
该工作可以由项目组内其他成员担任。
代码实现人员：
指具体进行程序代码编写的人员。
该工作根据项目具体情况可以是非本公司人员。
代码实现的主要依据是数据库设计说明书、概要设计说明书、详细设计说明书及其他需求说明书和相关资料。
测试人员：
指负责程序功能测试及Bug查找的人员。
该工作可由代码实现人员充任，但必须交叉进行，自己编写的代码须由其他人员检查、测试。
文档管理人员：
指项目存续期内负责日常工作文档及用户手册、操作手册、开发进度月报等文档的编制和管理的人员。
该工作可由项目组内其他人员充任。
设计人员、代码实现人员和测试人员应完成自己份内的文档编制，可参考以下第6条执行。
用户代表：
用户代表这一角色在项目组中，是一个相当重要的角色。
他应是能充分了解用户需求的人：
精通业务、熟悉管理、熟悉企业组织结构及内部运作方式，并能够不经或略经培训即能充分理解和参与制订项目任务、要求、目标等重要设计的人。
可以说，对于项目的成功与失败，用户代表这一角色起着至关重要的作用。
用户代表应至少有一名，并不限数目。
4．2对外协调
项目经理应在项目启动时向财务部门提供项目预算方案及资金使用计划。
项目组接受财务部门的经济监督，有义务按公司的财务调度计划安排资金的使用。
项目组成员应该经常与售前售后服务人员及用户（包括用户代表）交流，充分掌握用户的底层需求。
在必要时，项目组成员可以申请资金用于现场调研。
在必要的时候，项目组成员有义务协助营销人员搞好产品的推广销售工作。
但，此时发生的任何费用不在项目开发费里开支。
4．3项目外包
项目任务可以以外包的形式完成。
外包可整体外包，也可只将部分模块外包。
根据情况，项目任务可外包给公司内部其他项目组，也可外包给公司以外的组织或个人。
4．3．1外包评估
软件项目在外包前必须进行外包评估，只有当评估认为可以外包时，才能将项目外包。
评估时应着重考虑以下方面：
1、否有利于新技术的获得
2、是否有利于降低开发成本
3、是否有利于缩短开发周期
4．3．2外包合同
外包任务必须签定外包合同。
合同上必须至少载明以下内容：
任务名称，任务内容、要求及目的，进度计划，完成日期，开发费用，开发结果交付方式，违约责任等。
4．3．3外包资金
外包任务所需资金在项目开发费里列支。
由项目经理提出计划，在得到主管领导及总经理批准后实施。
资金使用不应一次性支付完毕，而应当按进度逐步支付，并且在外包合同完成时，应至少滞留30%的资金用于预后处理（包括调试、测试分析、修改完善）。
待整个项目完成，并经用户验收合格投入使用后，方可付完所有外包开发费。
4．3．4文件
在项目外包时，我公司可提供需求分析、概要设计、数据库设计说明书、详细设计说明书、项目开发计划、测试计划及其他必要文件等相关资料。
在外包任务完成时，承包方应交回合同规定的所有文件，包括程序源代码、模块开发卷宗、测试分析报告及合同规定的其他文件。
4．3．5其他
在条件允许时，可尽量将项目任务外包，公司内部最好只做可行性研究、需求分析、概要设计等上层设计。
这样，我们就可以以少量的资源投入而获得更多更好的开发成果和经济效益。
外包合同履行期间，项目经理有责任和义务监督合同的履行及外包任务的进度，以保证整个项目的进度计划。
在合同履行出现问题时，项目经理应采取果断措施，最大限度地为公司挽回损失。
如果项目经理不能决绝，应立即请示主管领导，直至总经理。
5项目实施
5．1计算机软件开发流程划分
5．1．1按软件生产周期划分
每个软件项目从启动到结束，最终都会有一个确定的生产周期，从这个角度来说，计算机软件开发流程可分为如下六个阶段：
需求分析
概要设计
详细设计
编程
测试
集成测试
其中需求分析及概要设计属于上层设计。
对于大型项目来讲，应该进行这两个项目的设计，而对于小型项目或者是开发周期要求很紧的项目而言，经总经理或主管领导批准，也可不进行这两项设计。
5．1．2按软件生存周期划分
一项计算机软件，从出现一个构思之日起，经过这项软件开发成功投入使用，直到最后决定停止使用，并被另一项软件代替之时止，被认为是该软件的一个生存周期。
一般地说这个软件生存周期可以分成以下六个阶段：
可行性与计划研究阶段
需求分析阶段
设计阶段
实现阶段
测试阶段
运行与维护阶段
5．1．3从项目管理角度来划分
根据项目管理的理论，所有的项目都要经历五个阶段：
起动阶段
计划阶段
执行阶段
控制阶段
结束阶段
一般地，我们按第二种方式（即6．1．2）组织软件开发。
5．2软件开发期各阶段的时间分配
软件生存周期对不同的软件来讲，会有相当大的区别，但开发期内各阶段的时间需求比例大致相当，因此，我们可以就一般的开发过程拟制一个参考进度安排方案，如下表所示：
表一软件开发期各阶段时间分配
流程
10
20
30
40
50
60
70
80
90
100
可行性与计划研究阶段
需求分析阶段
设计阶段
实现阶段
测试阶段
该表可作为制订软件开发项目进度计划的参考。
5．3软件开发的要求与规则
软件开发是一个复杂的系统工程，它要求有组织、有计划、有规则地多方位合作进行，它不可能是一个或某几个人的单独的行为，或他们的行为合并。
这就要求在整个开发期间内，项目组成员必须按照一定的规则和要求完成开发周期内各阶段的工作。
因此，制定一整套切实可行的开发规则无疑是非常重要的。
5．3．1软件开发各阶段流程及要求
5．3．1．1可行性与计划研究阶段
在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。
对于小规模的软件项目，在征得用户的同意、并经项目主管领导或总经理批准后，可不进行本阶段的工作。
可行性与计划研究阶段工作流程如图二所示。
客户要求
初步调查
明确问题
编写材料
可行性研究
制订开发计划
签署合同
评审
和
审批
可行性
研究
报告
（初步）
项目开
发计划
项目取消
图二可行性与计划研究阶段工作流程
需求
分析
5．3．1．2需求分析阶段
图三需求分析阶段工作流程
调查环境
需求分析
修订开发计划
制订确认
测试计划
编写用户手册
评审
（修订）
项目开发计划
（概要）
用户手册
修改
概要设计
可研阶段
软件需求说明书
数据需求说明书
（确认）测试计划
在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文件编制的要求，作为本阶段工作的结果，一般地说，软件需求说明书、数据要求说明书和初步的用户手册应该编写出来。
对于一个软件开发项目来讲，需求分析是非常重要的，只有明白了用户在硬件及软件方面的需求，我们才能够进行软件设计，并最终开发出符合用户需求的实际可行的软件来。
但，对于一个新的项目来说，往往无法确知用户到底需要什么，导致无法很好地制定软件开发的目标、方向、要求及方式。
对于需求明确的项目，
对于需求不明确的项目，
功能模块
逐步细化
程序模块
接口设计
程序模块
过程设计
模块测试
方案制订
评审
模块开
发卷宗
修改
图五详细设计阶段工作流程
实现阶段
概要设计
详细设计说明书
系统
总体设计
功能模块总体结构设计
数据库或数据结构设计
制订组装
测试计划
评审
（组装）测试计划
修改
图四概要设计阶段工作流程
详细设计
需求分析
数据库/结构设计说明书
概要设计说明书
5．3．1．3设计阶段
设计阶段可以细分为概要设计及详细设计两个步骤。
在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块的划分、功能的分配以及处理流程。
在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。
在一般情况下，应完成的文件包括：
概要设计说明书、详细设计说明书和测试计划初稿。
对于小规模的软件开发项目，可直接进入详细设计步骤，而忽略概要设计步骤。
5．3．1．4实现阶段
程序编码
单元测试
编写手册
评审
操作
手册
修改
图六实现阶段工作流程
测试阶段
详细设计
用户
手册
模块开发卷宗
在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始编写模块开发卷宗，并且要完成用户手册、操作手册等面向用户的文件的编写工作，还要完成测试计划的编制。
图八确认测试阶段工作流程
强度测试
执行
确认测试闭幕
分析测试结果
手册核验
开发总结
评审
（确认）
测试报告
项目开发总结报告
修改
运行维护
组装测试
用户手册
操作手册
执行组装测试计划
分析测试结果
评审
（组装）测试报告
修改
图七组装测试阶段工作流程
确认测试
实现阶段
5．3．1．5测试阶段
测试阶段可分为两个阶段：
即组装测试阶段和确认测试阶段。
在测试阶段，该程序将被全面地测试，已编制的文件将被检查审阅。
一般要完成模块开发卷宗和测试分析报告，作为开发工作的结束，所生产的程序、文件以及开发工作本身将逐项被评价，最后写出项目开发总结报告。
测试终结并通过，该项目即终结。
5．3．1．6其他
下一次开发要求
图九运行和维护阶段工作流程
运行管理
评审报告
维护修改
重新测试
修改文件
评审
软件问
题报告
有关文件
修改
确认测试
软件修
改报告
在整个开发过程中（即前五个阶段中），开发集体要按月编写开发进度月报。
在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改。
修改过后应及时补充或修改相关文档，务使所有文档必须准确反映最终结果。
5．3．2软件开发规则
5．3．2．1项目各阶段的承接
在各个阶段的工作完成后，经评审，工作成果应提交主管领导或总经理批准之后方可进入下一阶段。
如果工作成果被驳回，应根据处理意见重新论证并提出修正方案，再次报请批准。
各阶段的承接应该遵循如图十流程所示进行。
没有经过评审或未经批准的阶段成果不允许流入下一阶段，也不能启动下一阶段的工作。
否
上一阶段
阶段成果评审
批准
下一阶段
通过否
是
否
批准否
是
图十软件开发各阶段承接处理基本流程
修改
5．3．2．2编码规范
项目开发小组应根据不同的开发工具分别制订一套适合于小组内所有成员的代码编写约定规范，之后所有程序员的代码均应按该约定规范进行编写和检查。
不符合规范的代码，项目负责人可以责成程序员重新编写，直至所有代码符合约定规范的要求。
对于同一项目，在程序代码的编写上，应该采取同样的风格，并严格按照约定的方式编写，不能各程序员自成一套。
程序界面（包括窗体模式、窗体布局、调色等）也是一样，各个模块间要保持同样的风格和布局。
务使整个程序看起来如同一个人编写完成的。
每一个模块头部应加注释块，描述模块名称、版本号、设计者、设计日期、版权、功能简要说明、本模块调用的单元列表以及调用本单元的模块列表等内容。
对于模块中重要的代码段，应予详细注释，在代码修改时，也应同步修改相应的注释，不用的注释应及时删除。
对于函数、过程，要说明功能用途、输入参数、返回值、以及版本、设计日期等。
采用面向对象的开发方法，进行程序设计。
尽量不定义全局变量，而应将全局变量定义为属性，以供其他模块以对象属性的方式进行调用。
对于数据库的设计，应规定表、视图、存储过程、触发器以及字段的命名及注释方法。
所有本公司产品，均应采用同一标准。
每一个数据库在定义完成时，应增设如下全局表：
表定义表，字段定义表，视图、存储过程及触发器定义表。
这些表用于描述整个数据库各元素的创建方式和过程。
使用这些表，我们可以方便地对数据库进行维护，可以重新构建整个数据库结构，并可作为元数据用于在应用程序中自动初始化用户界面。
作为重要的维护工具以及用户使用手册内容之一的数据库结构模型，需采用专用数据库建模工具认真编制，并发布在项目组共享的开发平台上，以方便开发期中项目组各成员随时查询使用。
数据库结构如有变动，也应及时修改该模型。
5．3．2．3软件开发过程控制
程序设计过程控制参考如图十一所示方法进行。
如图所示，项目开发周期可分为若干个迭代周期，每个迭代周期又由若干个工作日组成。
迭代周期可以看作是软件开发过程中一个完整的功能模块的实现周期，是一个不可细分的工作时段。
日常工作中，须以迭代周期为基本单元来组织软件开发。
当然，项目规模比较大的话，可以有多个迭代周期同时进行，不同的迭代周期各自完成编码、测试、审核与集成发布，互不干扰，但相互依存。
交叉审核，指的是代码的审核，交叉审核用以调试代码、排查编码错误及代码优化，其目的是使程序代码更加优美、功能实现简单而有效。
交叉审核是内部审核，是程序员间的审核。
而功能审核指的是程序模块在实现外部功能（包括界面、事务处理功能）方面的审查，要求有用户的高度参与，而不仅指是测试员的工作。
测试与功能审核要求测试人员尽可能找出软件的Bug，还要求用户能就功能方面提出修改意见和建议，最终完全达到用户的需求。
需要说明的是，此处的审核与5．3．1中的评审是不一样的，后者指的是项目各阶段最终成果的检查与审核，是一种公司的内部考评、监督机制和行为，是项目审核。
而前者的范围却小得多，是项目组内部的行为，是功能上的审核，还要求有用户的充分参与。
如果采用的是成对编程的开发方法，图中下班前的交叉审核一项实际上已经变化成为编程全过程的相互检查、测试和审核，因此可不进行下班前的交叉审核。
每个
迭代
周期
继续
功能模块编码完成
测试
集成、发布
用户
修改
功能审核
图十一软件开发过程控制
每工
作日
编码
测试
每日晨会
（项目负责人主持）
交叉审核
（下班前）
下一个迭代周期
软件开发过程中，应强调如下几点：
1、要求用户的高度参与。
可以说，用户的参与程度直接影响项目的成败。
用户可作为强有力的测试人员，还必须充当审核成员之一，确保功能模块能充分实现用户需求。
如果项目组内没有用户参与，可将集成好的功能模块交给用户测试，但要求用户测试完成后提交测试报告，测试报告需详细记录参与人员、测试过程、测试结果、意见及建议等以供程序修改完善之用。
修改完成后再次交还用户测试，如此周而复始，直至该功能模块完全满足用户需求为止。
2、如条件允许，可以采用成对编程的方法进行日常软件开发，这样既可以提高效率，也可以尽可能地减少程序错误、减少返工，并且保证任何一行程序编码都至少有两个人清楚，以保证开发成果的集体共享性。
对于小项目，可以采用交叉审核的方法进行，某程序员的代码由另一程序员检查、调试，出现问题时可以及时修改。
交叉审核应该在每天工作结束前进行。
3、以尽可能小的迭代周期（功能模块开发周期）组织开发，同步测试、逐步集成和发布。
完成一个功能，测试、集成和发布一个功能，然后进入下一个迭代周期。
在每个迭代周期内，应在分析与设计完成后，组织审核，只有审核通过后才能进入下一个迭代周期。
4、应建立一个让整个项目组共享的测试、集成和发布环境，以方便所有成员动态掌握整个项目的进展情况，利于有效地相互沟通，并能保证项目组内所有成员随时获得的都
升级会员 