组织度量库建立和维护规程.docx
《组织度量库建立和维护规程.docx》由会员分享，可在线阅读，更多相关《组织度量库建立和维护规程.docx（26页珍藏版）》请在冰豆网上搜索。
组织度量库建立和维护规程
生命周期模型
建立日期：
2009年3月18日
文档编号：
CS-OPD-GC-7
版本
变更原因
变更内容简述
编制/修订者
批准者
发布日期
V1.0
建立
V1.1
修改
增加迭代模型的第2种形式以适应公司实际开发模式
1前言
1.1目的
该文档为神舟软件公司确定合适的软件生命周期提供指导，说明了公司具有代表性的三种项目类型，以及对应的软件生命周期的描述。
1.2适用范围
适用于公司所有的软件开发项目，软件开发可分为：
项目开发、产品开发和升级类项目。
1.3术语和缩略语
EPG：
EngineeringProcessGroup工程过程小组
SOW：
StatementOfWork，工作任务说明书
WBS：
WorkBreakdownStructure，工作任务分解结构
SRS：
软件需求规格说明书
PPQA：
产品与过程质量保证
MA：
度量分析
CM：
配置管理
CCR：
关键计算机资源
2过程综述
该过程阐述了公司最具代表性的项目类型特性，以及他们所对应的软件生命周期描述。
这三种项目类型分别为：
项目开发，产品开发，升级类项目。
同时又着重对开发类项目中的瀑布模型和迭代模型进行了详细描述。
开发类项目是指公司新承接的，由客户方提出的，有明确需求的项目，或由公司自主立项的新项目。
该类项目一般有比较完整的软件生命周期，也可能根据项目的具体情况将其中几个阶段合并或拆分。
维护类项目是指对公司原有开发完毕的已发布的项目进行维护，维护的需求可能来自客户提交的问题报告单，也可能来自公司内部测试人员提交的在发布时没有解决的问题报告单。
升级类项目是指公司对原有开发完毕项目进行的后期开发项目，后期开发的主要内容可能包括前期项目的缺陷修复、功能增强、新功能等等。
3角色与职责
角色（参考）
职责
高层经理
（公司总经理、副总经理）
批准组织级生命周期模型；
EPG组
建立、维护组织过程资产及生命周期模型内容
确保组织过程资产满足模型和适合组织的实际需要。
事业部经理
向EPG组提交生命周期模型改进的意见、建议
项目经理
参与项目生命周期模型的评审。
向事业部经理提交项目、度量信息及过程资产使用的有关问题的反馈
PPQA工程师
参与生命周期模型的评审。
度量工程师
参与生命周期模型的评审。
配置工程师
参与生命周期模型的评审。
技术专家
参与生命周期模型的评审。
管理专家
其他有关人员
4主要过程
根据软件工程和公司项目的实际情况，主要对开发类项目的瀑布模型、迭代模型，以及维护类和升级类项目分别描述。
各个项目可以根据项目的需求特点，开发周期，团队规模，团队技术水平以及应用的重要程度等项目的特性数据来选择适合自己项目的软件生命周期。
4.1瀑布模型
瀑布模型是最常用的软件开发模型，它的各个阶段是按线性序列组织的。
开发过程中的阶段划分为项目策划、需求分析、概要设计、详细设计、编码和单元测试、软件集成和集成测试、系统测试、验收和安装等（图1）。
尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。
瀑布模型的每个阶段均具有以下特征：
●从上一阶段接受本阶段工作的对象，作为输入；
●对上述输入实施本阶段的活动；
●给出本阶段的工作成果，作为输出传入下一阶段；
对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工作，否则返回前一阶段，甚至更前阶段。
4.1.1项目策划阶段
项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。
项目策划的主要工作是进行估计和制定管理项目的计划。
目标
根据项目特点和组织情况制定项目计划，并获得相关人员的同意/批准
适用标准和规范
《集成项目管理过程定义》
相关工具
MSWord文件编辑工具
MsProject项目管理工具
MSExcel
主要输入
《项目任务书》、《建议书》或《合同技术附件》
《客户书面的需求》
入口准则
《客户书面需求》已被批准
《项目任务书》、《建议书》已被批准
《合同技术附件》已签定
项目经理已经到位
参与项目准备和策划的人员接受过相关技能的培训
活动
1.选择项目生命周期模型
2.建立项目已定义过程
3.构建顶层WBS
4.估计项目的规模、工作量、成本、进度和关键计算机资源（CCR）等
5.标识和分析风险
6.计划资源及其获取方式
7.编制项目计划及PPQA计划和配置管理计划
8.评审和批准项目计划和从属计划
主要输出
估计记录，包括规模，进度和成本
《项目风险识别和跟踪一览表》
《项目计划》，包括：
进度计划、WBS、《项目数据管理计划和跟踪表》、《项目相关人员参与计划和跟踪表》
《PPQA计划》、《配置管理计划》
出口准则
项目计划得到受影响的组织和个人的承诺
项目计划得到批准并置于配置管理之下
度量
项目策划所花的工作量
约束
项目策划：
时间跨度比例占项目周期比例的5-10%
投入工作量比例占项目总工作量的比例5-10%
角色
职责
高层经理
（公司总经理、副总经理）
批准项目计划，提供项目计划所需要的资源
事业部经理
（部门经理）
审核项目计划
项目经理
建立和维护项目计划、风险管理
PPQA工程师
建立和维护《PPQA计划》
度量工程师
建立和维护《度量计划》
配置工程师
建立和维护《配置管理计划》
技术专家
参与项目计划建立和维护的评审、估计
管理专家
其他有关人员
4.1.2需求分析阶段
需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档。
用户需求规格说明书和软件需求规格说明书（SRS）是该阶段的主要输出。
需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。
需求分析阶段执行的活动主要集中在两个领域：
问题分析和产品描述。
问题分析活动分准备、采集需求和分析等，而产品描述活动分准备SRS和评审SRS等。
目标
生成一个正确说明客户所有需求的文档
适用标准和规范
《需求分析规程》《需求管理规程》
相关工具
文件编辑工具：
MSWord
客户需求分析工具：
如ROSE、MSVisio
主要输入
初始的客户需求
分配的软件系统需求
入口准则
项目已经立项并得到批准
参与需求分析的人员接受过相关技能的培训
活动
一、获取用户需求
1、确定需求的获取方法
2、进行需求调研，获取用户需求，收集共利益者的需要、期望、限制条件和接口，并且把他们转换成顾客需求。
3、确定是否需要开发原型
4、文档化《用户需求规格说明书》
5、评审《用户需求规格说明书》
6、建立需求库、需求跟踪矩阵
二、分析需求
1、分析用户需求和利益相关者的需求
2、文档化《软件需求规格说明书》
3、评审《软件需求规格说明书》
4、维护《需求跟踪矩阵》
5、编制《测试计划》、《系统测试用例》
6、将《用户需求规格说明书》、《软件需求规格说明书》、需求跟踪矩阵形成需求基线，《测试计划》、《系统测试用例》入配置库
7、根据项目监控的情况，修正《项目计划》
主要输出
《用户需求规格说明书》
《软件需求规格说明书》
《测试计划》
《系统测试用例》
出口准则
《用户需求规格说明书》、《软件需求规格说明书》通过评审、所有发现的问题都得到处理，并置于配置管理之下。
评审覆盖率100%
错误发现率不得低于5-15个/100页，修复率100%;
度量
参见《度量和分析规程》
约束
需求阶段：
时间跨度比例为整个项目周期的10-25%，
工作量占总工作量5-20%
角色
职责
中层经理
（部门经理）
参与评审
项目经理
组织编写需求文档并参与评审
需求工程师
负责撰写《用户需求规格说明书》、《软件需求规格说明书》、建立《需求跟踪矩阵》，参与评审
测试经理
根据《软件需求规格说明书》撰写《系统测试大纲》，参与评审
PPQA工程师
检查《软件需求规格说明书》、《系统测试大纲》、《需求跟踪矩阵》的符合性，评审活动的符合性
变更控制委员会
负责主持评审，并批准需求基线的建立
度量工程师
参与里程碑评审活动；
记录、度量和分析过程活动中产生的度量数据。
配置工程师
建立需求基线，负责将评审通过的《软件需求规格说明书》、《系统测试大纲》、《需求跟踪矩阵》入配置管理
技术专家
参与评审
开发工程师
其他有关人员
4.1.3设计阶段
概要设计阶段是从实现的角度开发针对客户需求的解决方案，完成软件的架构设计和数据库设计，详细设计是从架构设计和数据库设计入手，完成模块的详细设计或界面设计。
目标
从实现的角度开发针对客户需求的技术解决方案
适用标准和规范
《概要设计规程》《详细设计规程》
相关工具
文件编辑工具：
MSWord、EXCEL、PowerPoint等
软件设计工具：
如ROSE、MSVisio
主要输入
《软件需求规格说明书》
《系统解决方案说明书》（可裁减）
入口准则
《软件需求规格说明书》、《系统解决方案说明书》（可裁减）已经通过评审，并且软件需求和《需求跟踪矩阵》已经基线化。
活动
一、概要设计
1、确定设计准则；
2、设计产品和产品构件。
包括：
总体设计、功能设计、逻辑模型设计、过程模型设计、数据模型（数据库）设计、实现模型设计、部署模型设计、用户接口（界面）设计、错误处理设计等；
3、将设计文档化，编写《概要设计说明书》；
4、确认设计，评审《概要设计说明书》；
5、根据概要设计，设计《集成测试用例》和《用户操作手册》；
6、维护《需求跟踪矩阵》；
7、《概要设计说明书》、《需求跟踪矩阵》形成设计基线，并入配置库；
8、根据项目监控的情况，修正《项目计划》。
二、详细设计
1、根据《概要设计说明书》细化模块功能、用户接口（界面），并细化功能模块的数据结构和算法，完善重用软件和单元的算法和处理流程；
2、将设计文档化，编写《详细设计说明书》；
3、根据详细设计，完善《用户操作手册》，设计《单元测试用例》；
4、确认设计，评审《详细设计说明书》；
5、维护《需求跟踪矩阵》；
6、《详细设计说明书》、《需求跟踪矩阵》形成设计基线，并入配置库；
7、根据项目监控的情况，修正《项目计划》。
主要输出
《概要设计说明书》
《数据库设计说明书》（可裁减）
《集成测试用例》
《详细设计说明书》
《用户操作手册》
《单元测试用例》
《评审报告》
出口准则
《概要设计说明书》、《数据库设计说明书》（可裁减）、《详细设计说明书》得到评审和批准并置于配置管理之下
评审覆盖率100%
错误发现率不得低于5-15个/100页
修复率100%
度量
参见《度量和分析规程》
约束
设计投入的时间跨度占项目周期比例20-50%，工作量占20-50%
角色
职责
中层经理
（部门经理）
参与评审，协调资源配置
项目经理
负责组织编写设计文档并参与评审
开发工程师
承担产品设计并编写设计文档并参与评审，建立《需求跟踪矩阵》
测试工程师
根据《测试计划》《测试大纲》编写接口测试用例，参与评审
PPQA工程师
检查设计文档、《需求跟踪矩阵》、《项目计划》的符合性，评审活动的符合性
变
升级会员 