cmmi软件开发流程.docx
《cmmi软件开发流程.docx》由会员分享,可在线阅读,更多相关《cmmi软件开发流程.docx(29页珍藏版)》请在冰豆网上搜索。
![cmmi软件开发流程.docx](https://file1.bdocx.com/fileroot1/2023-5/16/f506d0a1-120c-454b-9f71-575b40af0ba7/f506d0a1-120c-454b-9f71-575b40af0ba71.gif)
cmmi软件开发流程
软件开发流程
软件项目生命周期模型
需求分析流程图
需求分析
EPG部门经理
开始
1、组建临
时项目组
5、审批裁剪
需求分析
PM测试负责人临时项目组QA
2、制定需求阶
段日程表
3、建立配置库
4、申请裁剪
6、确定项目管理机制
7、编写需求清单
列表
8、确定系统架构/
编写需求规格书
9、评审架构设计书/需求规格书
11、确定项目目
标范围
12、项目估算
13、确定项目关键参数
14、协调人员及资源
15、建立工作环境
16、编制项目计划书
17、编制项目日程表
18、评审项目计划书
19、建立阶段
基线
20、阶段总结
结束
客户输入/输出
项目裁剪表
需求清单列表
架构设计书/需
求规格书
10、确认需
求规格书
规模估算表/项目
估算表
项目计划书
项目日程表
需求分析阶基线
需求分析阶段总
结报告
过程描述
1、由部门经理组建临时项目组,并指定PM、开发人员、测试人员、QA,人数根据项目规模确定。
2、PM制定需求阶段日程表,该表须通过研发经理审核。
3、PM指示配置管理员建立配置库。
4、由PM与测试负责人提出裁剪申请,QA指导临时项目组人员对项目进行裁剪,形成项目裁剪表。
5、EPG和部门经理对裁剪结果进行审批,审批通过项目裁剪表正式生效。
6、PM与测试负责人确定项目管理机制,内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、
QA、CM等。
7、项目组人员与客户进行沟通,编写需求清单列表。
8、PM组织临时项目组成员确定系统架构,编写架构设计书和需求规格书。
架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。
对技术方案选择(例如,系统结构、开发平台、数据库等的选择
),要事先建立评价准则
(例如,满足
系统需求的能力
(例如,功能、性能、可靠性等
)、技术的发展前景、供应商资质与实力等
)及相对优
先级,采用讨论表决的方法选择并确定最终的技术方案。
关于自行开发和采购复用的分析,
如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等),一般应进行复
用;
本公司没有能力开发或没有必要开发的非核心技术部分,如果采购成本在项目可接受范围内,可考虑
采购;
否则,由项目组自行开发。
架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。
10、PM组织临时项目组与客户沟通、说明需求,必要时编制系统原型向客户展示,直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。
11、临时项目组确定项目目标的范围,明确系统边界,建立系统的模块分解结构。
12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。
13、PM、测试负责人与临时项目组确定项目关键参数。
工作量、工期、日程、人数
成本/预算(由于本公司的项目的绝大部分成本是人力成本,对估计成本的管理等同于估计工作
量的管理,对实际成本的管理等同于实际工作量的管理,对预算的管理等同于计划工作量的管
理。
)
质量目标
14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。
15、项目组基于公司环境标准,结合项目实际情况建立适合的工作环境。
16、PM、测试负责人编制项目计划书。
17、PM、测试负责人编制项目日程表。
18、临时项目组、研发部、QA评审项目计划书,评审通过后正式生效。
19、PM指示配置管理员建立配置基线。
20、PM编制阶段总结报告(项目总结报告中的度量分析页面),召开阶段会议。
设计
设计流程图
PM
项目组
配置管理员
输入/输出
开始
A、需求规格
书
1、组织项目组成员
B、架构设计
书
学习需求调研报告
2、组织人员明确
C、设计说明
设计约束
书
3、系统功能设计
5、系统外围设计
6、组织人员评审
设计文档
8、建立阶段基线
9、组织召开阶段
H、会议纪要
会议
结束
过程描述
1)项目经理组织项目组人员学习需求规格书;
2)项目经理组织项目组中的开发人员确定设计约束,这些约束可能包括一下几个方面:
需求约束,需求规格书中约定的设计约束;
隐含约束,需求规格书中没有,但对系统的设计或者使用带来潜在影响的特殊约束。
3)项目经理及开发人员根据需求规格书、架构设计书进行设计,编制《设计说明书》。
基于对业务和现有系统结构的理解,划分/调整系统模块。
描述各系统模块协作实现各业务场景的处理流程(可用序列图)。
必要时(通常要反复几轮),修正系统模块划分和处理流程。
描述各处理流程中的各活动的输入、处理、输出和可能的异常。
系统模块构成及其相互关系。
(可用类图、包图。
)
系统模块内部设计。
(功能、管理的数据、对外的服务、对内的服务,要求明确各模块的对外接口。
)
4)开发人员根据《需求规格书》、《架构设计书》进行设计、《设计说明书》进行用户界面和数据库以及接口
等方面的详细设计,纳入《设计说明书》。
用户界面设计。
(建议使用Visio中的窗口和对话框、工具栏和菜单、公共控件这几个形状组来绘制,
具体操作方法是:
点击“文件”选项选定“形状”选定“软件和数据库”选定“软件”
次选定上述三类形状组。
)
数据库设计。
文件设计(文件的存贮位置与名称、格式与内容定义。
)。
接口设计。
(含内部通讯接口、外部通讯接口、用户图形界面、报表、其它接口。
)
依
5)项目经理组织开发人员、测试人员及其他技术骨干评审《设计说明书》。
6)配置管理员建立设计阶段配置基线;
7)项目经理编制阶段报告(项目总结报告中的度量数据页面),组织项目组人员并邀请部门经理召开阶段会议,并形成会议纪要。
编码流程
编码流程图
输入开发人员输出
编码规范
界面规范
设计说明书
过程描述
开始
(1)绘制详细类图
(2)审核详细类图
(3)培训编码、界面规范
(4)开发环境配置
(5)编码与调试
(6)评审代码
(7)进行联调
(8)编写阶段报告结束
详细类图
代码文件
阶段报告
a)根据准入条件中的设计文档,绘制详细类图,以指导编码。
b)对生成的类图进行审核。
c)项目经理组织开发人员学习编码规范、用户界面规范,以保障程序的可靠性、可读性、可修改性、可维护性、一致性以及界面的规范性。
d)开发环境的配置
项目经理或其指定人员在公司的《开发环境指南》的基础上编制开发环境配置说明,项目组成员遵照开发
环境配置说明配置统一的开发环境。
e)编写及调试
开发人员根据设计说明书和编码规范、用户界面规范的要求编写代码,自行进行检查、调试并解决BUG。
f)评审代码
项目经理组织开发人员、项目组外的专家等对本项目修订的所有代码进行评审或审批。
g)进行自测
开发人员对代码进行联调,对照测试人员编制的测试用例中的正常业务流程部分(在测试用例中已明确标
出)进行测试,并全部通过测试。
联调测试中,不要求记录BUG,不须编制测试报告。
h)编写阶段报告
项目经理编制阶段报告,召开阶段会议。
编码规范(见规范说明书)
测试流程
测试流程图
开发人员PM测试负责人测试人员
开始
1、学习、评审学习用户需求列表、需求规格书
2、编写测试方案
3、编写测试用例
4、评审测试方案、测试用例
5、负责测试方案、
测试用例等文档入库
6、召开阶段会议
结束
输入/输出
用户需求列表
需求规格书
测试方案
测试用例
阶段报告
过程描述
1、
测试负责人组织测试人员学习、评审《用户需求列表》
、《需求规格书》。
在学习、评审过程中充分
理解客户及业务需求,确保文档信息的正确性、充分性、一致性。
2、
测试负责人组织测试人员完成编写整个项目的测试方案。
3、
测试负责人组织测试人员基于《需求规格书》编写测试用例。
当《设计说明书》通过评审后,测
试人员基于《设计说明书》对测试用例进行必要的调整。
测试用例的组织分类须遵循以下原则:
测试用例的组织分类(例如,文档名、页面名、一级标题、二级标题等
)必须与需求规格书中的
各需求点明确对应起来。
4、
测试负责人组织测试人员、开发人员、
PM评审测试方案、测试用例。
5、
测试负责人指示配置管理员将测试方案及测试用例文档入库。
6、测试负责人组织PM、开发人员、测试人员召开阶段会议并形成阶段报告。
验收流程
验收流程图
项目经理客户代表客服人员测试人员开发人员CM输出
开始
(1)沟通验收事项
(2)产品安
装调试
(3)对客户进行培训
(4)开展试运行
(5)
汇总缺陷
验收缺陷
跟踪表
(6)
分派缺陷
(7)分析、解
处理责任
决缺陷
(8)
缺陷修复
循
环
确认
(9)回归测试
(10)更新试运行版本
(11)客户验收并交付使用
(12)整理项
(13)整理
目数据
工作产品
(14)
项目总结
总结报告
(15)
召开总结
归档
(16)
会议
结束
过程描述
1)项目经理与客服人员沟通验收事项。
2)客服人员在客户指定的环境下参照《安装维护手册》进行产品安装调试,并把合同约定的文档、源程序等交给客户。
3)客服人员对客户进行系统操作方法培训。
4)客户试用系统开展业务,测试人员收集客户反馈的问题;如果客户验收测试环境与生产环境差异明显时,要进行性能测试,以保证满足系统性能需求。
5)测试人员在验收中发现缺陷并告知项目经理,项目经理将缺陷记录到BugFree中。
某些情况下(例
如,缺陷描述不详、明显不是缺陷等)项目经理可以向相关人员(测试人员、客户)解释、说明,达
成一致后驳回相关人员(测试人员、客户)提出的问题。
6)项目经理将缺陷分派给适合的开发人员。
7)开发人员分析缺陷的原因及解决该缺陷,并将该缺陷的解决方法及解决状态更新BugFree。
8)项目经理将所有已处理的缺陷转移至测试人员进行缺陷修复的确认。
如果测试结果表明缺陷仍未解决,项目组内测试人员通过项目经理将该缺陷返回给处理该缺陷的
开发人员。
如果测试结果表明缺陷已解决,项目组内测试人员告知项目经理,项目经理关闭该缺陷。
9)在更新验收版本之前,测试人员要进行一次回归测试。
对即将发布的新版本,进行一次整体的测试。
10)验收中发现的缺陷累积到一定程度或严重缺陷导致验收无法继续时,应更新验收版本。
必须解决的缺陷全部解决后,配置管理员更新代码及配套文档并标识验收的产品版本,项目经理指定人员更新验收版本并部署至验收环境中。
测试人员分析本次更新涉及的范围,确定回归测试的范围,并在此范围内进行回归测试。
如果更新验收版本之后,要回到活动4,直至验收通过。
11)项目经理和客户代表根据验收期间的测试记录等依据验收通过准则,达成一致,根据所签署的商务合
同,向客户交付合同中要求提供的交付物,包括《用户手册》、《安装维护手册》等,并取得客户验收
通过的书面确认。
12)项目经理收集整理项目相关的资料和数据,在项目组内分配项目关闭各项工作,包括技术总结、软件产品总结,相关数据整理等。
13)配置管理员对配置库进行更新,整理相关工作产品。
14)项目经理收集项目组成员反馈的建议,根据对项目的监控过程进行项目总结,编制项目总结报告。
15)项目经理召开项目总结会议,邀请项目组成员、QA、技术总监、技术部骨干人员参加。
必要时可邀
请客户参加。
16)项目经理向QA、配置管理员发出项目结束通知,申请配置库归档。
配置管理员收回该项目配置库权
限,在《研发部配置项列表》中更新相关信息,并通知项目组、QA。
研发部释放项目组占用资源。
项目正式关闭。