软件研发管理制度

软件研发管理制度内容摘要：

时角色 职责说明 立项建议小组 （ 1）开展立项调查、产品构思和可行性分析，撰写相应文档。 （ 2）申请立项，并在立项评审会议上答辩。 立项评审委员会 由机构领导、各级经理、市场人员、技术专家、财务人员等组成，委员会按少数服从多数原则投票决定是否同意立项。 结项评审委员会 对项目的有形资产和无形资产进行清算 ，对项目进行综合评估，总结经验教训等。 结项委员会的人员组成与立项评审委员会的类似。 技术评审委员会 对工作成果进行正式技术评审，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷。 该委员会由项目内外的技术专家组成。 配置控制委员会 对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。 表 13 精简模型 的角色与职责简表 8 公司 软件过程的政策 目标  持续改进机构的软件过程能力，不断地提高产品质量、提高生产率并且降低开发成本。 机构领导的支持  机构领导批准用于 软件过程改进的必要经费，例如支付咨询费，购买相关软件工具等。  机构领导组建 SEPG 和 QAG，专门从事软件过程改进工作。 SEPG 的主要职责是建立适合于机构的过程规范， QAG 的主要职责是监督该规范的实施。 建议让 SEPG 和QAG 的大部分人员重叠，这些人既是 SEPG 成员又是质量保证员，扮演两种角色。 这样不仅节约人力资源，并且提高了工作效果（由制定规范的人去监督规范的实施最合适不过）。 一般地， SEPG 成员和质量保证员共占机构总人数的 5%左右。  机构领导不仅要口头支持，还要亲自参与软件过程改进的实践。 例如参加培训和考试 ，准照过程规范执行立项管理和结项管理等。 质量管理的政策 质量管理口号：“在开发过程之中内建质量而非修补质量”。 质量管理有种基本措施：“质量保证”、“技术评审”和“测试”。 一、 质量保证 机构的质量保证员周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量”。 机构的质量保证员独立于任何项目，并赋予他一定的权利，对质量不合格的工作成果作出处理。 二、技术评审 在工作成果刚产生之际，对其进行技术评审（分正式或非正式两种），目的是尽早地发现工作成果中的缺 陷，并帮助开发人员及时消除缺陷，从而提高产品的质量。 如果时间允许的话，应当尽可能多地对产品的重要工作成果进行技术评审。 技术评审活动由项目开发团队组织。 三、测试 测试是指通过运行测试用例（ test case）来找出软件中的缺陷。 测试与技术评审的主要区别是前者要运行软件而后者不必运行软件。 一般地，产品开发过程中有四个测试阶段：单元测试、集成测试、系统测试和验收测试。 其中单元测试和集成测试可以由项目开发团队组织。 系统测试阶段必须有项目外的人员参与，以保证系统测试的客观性。 验收测试由客户组织。 如果有条件的话， 建议 9 机构成立专门的测试小组从事单元测试、集成测试和系统测试工作。 质量保证小组的政策 机构领导任命一位熟悉过程规范并且有丰富的质量管理经验的人担任 QAG 的负责人（或称为质量经理）。 在机构领导的许可下，该负责人组建 QAG（成员可以是全职的也可以是兼职的）。 QAG 在行政上独立于任何项目。 这种独立性有助于质量保证员客观地检查和监控“过程以及产品的质量”。 QAG 准照 SEPG 制定的“质量保证规范”开展工作。 机构领导赋予 QAG 一定的权利，可以对质量不合格的工作成果做出处理。 这种权利使得 QAG 的工作不会 被轻视，并有助于加强全员的质量意识。 对于 QAG 与项目之间出现的难以调和的争议，由机构领导处理。 项目团队的政策 项目中的任何管理人员、开发人员、测试人员等，必须学习与本职工作相关的过程规范，每个人都必须明白自己“ 应当在什么时候依据什么规范做什么事情 ”。 项目经理应当树立榜样，并且督促项目成员们按规范做事。 允许项目经理根据本项目的特征，在 SEPG 和 QAG 的指导下，适当地裁剪或扩充机构的过程规范，从而快速建立本项目的过程规范。 这项工作应当在“项目规划过程域”中完成，并在《项目计划》中体现出来。 如果项目对机构过程规范的裁剪幅度比较大，遭到 QAG 的反对，如果双方不能达成共识，则由机构领导处理该争议。 SEPG 对项目过程能力的评估成绩将作为评定项目人员工作业绩的重要因素，具体比重由机构领导决定，建议占 30％以上的比重。 2 立项 管理 参见《 项目管理制度试行 版本》 3 项目规划 在立项管理过程域的项目筹备阶段，机构领导首先任命一位项目经理，之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。 如果必要的资金和资源已经到位，那么项目经理和核心成员即可组成一个项目规划小组，着手 制定《项目计划》，并按计划执行研发和管理工作。 项目的计划书可分两类：一是全局的计划书（ Overall Plan），这里称为《项目计划》； 10 二是一些下属计划书（ Subordinate Plan），例如《配置管理计划》、《质量保证计划》、一些开发计划和测试计划等。 下属计划书是对《项目计划》的补充，其内容不可与《项目计划》冲突。 通常《项目计划》由项目经理负责制定，由机构领导审批。 而下属计划书一般由项目成员制定，由项目经理审批即可。 项目计划过程域有 3 个主要规程：“制定项目计划”、“审批项目计划”和“项目计划变更控制”，流程如图 31 所示。 图 31 项目规划流程图 项目计划模板 4 项目监控 项目监控（ Project Monitoring and Control, PMC）的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等，不断地了解项目的进展情况，以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施。 本规范阐述了项目监控过程域的三个主要规程：  项目计划跟踪  控制偏差  项目进展汇报 图 41 项目监控流程 制定项目计划 审批项目计划 项目计划变更控制 按计划执行 研发与管理工作 项目计划跟踪 偏差控制 项目进展总结 周期性地开展 11 项目计划跟踪 周期性的跟踪任务（含进度和工作量）、费用、资源、工作成果等，及时了解项目的实际进展情况。 为持续过程改进提供有价值的数据。 任务跟踪 项目经理（或其指定的项目成员）周期性地（如每周一次）跟踪每个重要的任务，将采集的数据保存在《项目监控数据表》之中。 任务跟踪表的参考格式如表 41 所示。 任务名称 实际起止时间 跟踪日期、当前进度 实际工作量 实际工作成果 表 41 任务跟踪表 费用跟踪 项目经理（或其指定的项目成员）周期性地跟踪项目费用，将采集的数据保存在《项目监控数据表》之中。 费用跟踪表的参考格式如表 42 所示。 费用类别 主要开支项、用途 金额 时间 表 42 费用跟踪表 资源跟踪 项目经理（或其指定的项目成员）周期性地跟踪软硬件资源，将采集的数据保存在《项目监控数据表》之中。 资源跟踪表的参考格式如表 43 所示。 软硬件资源名称 级别 实际配置 获取方式与时间 使用说明 关键 12 关键 普通 … 普通 表 43 资源跟踪表 工作成果及其规模跟踪 项目经理（或其指定的项目成员）周期性地跟踪工作成果及其规模，将采集的数据保存在《项目监控数据表》之中。 工作成果跟踪表的参考格式如表 44 所示。 工作成果名称 新开发的成果规模 （代码行、类、文档页数） 复用或自动生成的成果规模 （代码行、类、文档页数） 工作成果 1 工作成果 2 … 总和 表 44 工作成果及其规模跟踪表 控制偏差 对比“项目实际进展”和“项目计划”，分析偏差，如果发现项目实际进 展显著偏离计划，则及时采取纠正措施。 记录日期 显著偏差描述 原因分析 纠正措施 结果 表 45 项目偏差控制报告 13 项目进展汇报 周期性地汇报项目进展情况。 项目经理周期性地总结项目进展情况，撰写《项目进展报告》并通报给机构领导和所有项目成员。 基本信息 项目名称 报告日期 项目编号 报告批次 第 N 份 项目经理 项目所处阶段 项目进展状况 计划 实际情况 任务与进度 工作成果 费用 人力资源 软 硬件资源 问题与对策 表 46 项目 进展 报告 14 5 风险管理 风险管理（ Risk Management, RiskM）的目的是在风险产生危害之前识别它们，从而有计划地消除或削弱风险。 所有可能危害项目的因素都称为风险。 被刻画为风险的事件最终可能发生也可能不发生。 人们对待风险有两种态度。 一种是被动态度，可比作“救火模式”。 另一种是主动态度，可比作“防火模式”。 风险管理属于“防火模式”，目的就是“防止风险产生真正的危害”。 为了便于量化管理，我们给风险定义 3 个参数：  风险严重性 ：指风险对项目造成的危害程度。  风险可能性：指风险发生的几率。  风险系数：是风险严重性和风险可能性的乘积。 参数 等级 值 描述 风险 严重性 很高 5 例如进度延误大于 30%，或者费用超支大于 30%。 比较高 4 例如进度延误 20%~30%，或者费用超支 20%~30%。 中等 3 例如进度延误低于 20%，或者费用超支低于 20%。 比较低 2 例如进度延误低于 10%，或者费用超支低于 10%。 很低 1 例如进度延误低于 5%，或者费用超支低于 5%。 表 51 风险严重性等级 参数 等 级 值 描述 风险 可能性 很高 5 风险发生的几率为 ~ 比较高 4 风险发生的几率为 ~ 中等 3 风险发生的几率为 ~ 比较低 2 风险发生的几率为 ~ 很低 1 风险发生的几率为 ~ 表 52 风险可能性等级 风险 系数 风险可能性 很高 5 比较高 4 中等 3 比较低 2 很低 1 风险 严重性 很高 5 25 20 15 10 5 比较高 4 20 16 12 8 4 中等 3 15 12 9 6 3 比较低 2 10 8 6 4 2 很低 1 5 4 3 2 1 本表灰色部分的风险系数值为 10~25，应当优先处理。 表 53 风险系数等级 15 风险严重性的等级划分如表 51 所示，风险可能性的等级划分如表 52 所示，风险系数的等级划分如表 3 所示。 风险管理有 4 个主要活动：  风险识别：根据风险检查表，识别出本项目的风险。  风险分析：估计风险严重性、风险可能性、风险系数。  风险减缓：对于风险系数超过“容许值”的每一个风险，都应当采取减缓措施。  风险跟踪：跟踪风险减缓 过程，记录风险的状态。 图 51 风险管理示意图 在项目的生命周期内，上述 4 个活动将被循环执行，如图 51 所示。 直到项目的所有风险都被识别与解决为止。 常用的 《 风险检查表 》 ，使用者应根据实际情况进行适当的删减或补充。 风险管理过程域产生的主要文档是 《风险管理报告》。 商业风险 风险类型 检查项 政治 法律 市场 政府或者其他机构对本项目的开发有限制吗。 有不可预测的市场动荡吗。 有不利于我方的官司要打吗。 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗。 竞争对手有不正当的竞争行为吗。 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗。 是否在开发很少有人真正需要却自以为很好的产品。 是否在开发可能亏本的产品。 客户 客户的需求是否含糊不清。 客户是否反反复复地改动需求。 客户指定的需求和交付期限在客观上可行吗。 客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗。 客户的合作态度友善吗。 与客户签的合同公正吗。 双方互利吗。 风险识别 风险分析 风险减缓 风险跟踪 16 客户的信誉好吗。 例如按客户的需求开发了产品，但是客户可能不购买。 子 承包商 供应商 与子承包商、 供应商 签订的合同公正吗。 双方互利吗。 子承包商、 供应商 的信誉好吗。