（1） 研发部门组成结构
部门领导主要有PDT/TDT（产品开发团队）经理、开发代表、维护经理。PDT/TDT经理主要负责整个部门的管理工作。维护经理主要负责网上版本的维护支持工作。开发代表主要负责的软件开发的领导和管理工作。
开发团队分为系统组和开发组（开发组里又细分为几个开发小组）。系统组主要是由有多年开发工作经验、能力强的SE（系统工程师）组成。系统组的主要职责是做产品开发的前期分析、预研、需求答复、架构设计、开发组技术指导等要求较高、影响较大的工作。开发组主要专注于CMM开发活动。
（2） CMM项目开发的相关角色
RDPDT:开发代表，开发团队领导。负责项目资源支持和监管。
SE:系统工程师，指导项目组开发,类似于高级工程师,属于项目组外围支持人员
QA:质量保证师，质量管理部人员,监督项目是否按照CMM流程运行,属于项目组外围支持人员。
TC:测试协调员, 参与测试计划和测试用例评审,测试部人员,属于项目组外围支持人员。
TDC：资料协调员，资料组成员,属于项目组外围支持人员。
PM:项目经理，项目的第一负责人，项目运行的中枢。
SWE:软件工程师，开发实现的主体。
CMO:配置管理员, 通常由SWE兼任。
MC:度量协调员, 通常由SWE兼任。
（3） 项目的启动
根据市场或相关部门间版本配套需求，首先经过系统组的前期分析和架构设计（实际也是经过了SE-CMM流程：场景分析、功能分析、功能设计等环节）输出SOW（工作任务书）文档，下发到开发组，开发代表任命项目经理PM和主要的项目小组成员，项目小组需要对sow进行评审，SE根据评审意见修改，最后经过开发代表和PM的批准生效。开发代表向上级申请项目ID启动项目，项目ID申请成功后，项目即启动。
（4） CMM开发流程
首先进入的是PPL（项目计划）阶段。PPL阶段主要是PM在项目小组成员的支持下开展以下活动：
a.项目组评审SOW
b.代码估计：采用专家法或delphi法进行代码估计。专家法主要是由对某个特性开发有相当经验的专家直接给出代码估计值。Dephi法估计主要如下：
协调人（一般为PM）主持会议
1、各专家使用统一的估算假设（包括代码量估计标准，估计结果接受偏差范围）,进行第一轮估算（针对每个估计点给出最低值，最高值，最可能值）
2、统计第一轮各专家估算结果（不公开专家姓名）
3、讨论分歧，一般控制在15~20分钟内
4、各专家修正估算
5、重复上述步骤，直至4轮，或分歧范围小，或会议指定时间到，或专家都不想改变自己的观点
6、确定估算结果，可取平均值、中值、乐观值、悲观值或一个范围
7、结果取得共识，获得审批
c. PHB软件生命周期模型：对软件开发活动模型的选取。比如PM认为HLD概要设计可以不要，即可在标准的模型的去除该阶段，当然这个模型的选取需要得到QA和开发代表的批准。
d.PPL、WBS文档输出：PPL项目计划书详细说明了开发活动各个阶段的时间点/质量目标/代码等交付件规模/人员角色分工/资源需求/依赖条件/评审计划/培训计划等项目关键计划。WBS工作任务分解主要是说明小组人员各自承担的各个功能点以及各阶段活动中详细的时间进度
e.CMP、RMP、TS、DPP文档输出：CMP配置管理计划书说明的是代码或文档的配置管理，比如配置库位置、相关文档名字、源代码申请、测试用例以及需求点编号方案等。RMP风险管理计划：列出本项目进行中的可能出现的风险、风险的预防和应急措施。TS测试策略描述项目测试阶段需要的资源支持以及测试方案等。DPP缺陷预防说明书：根据项目情况以及以往项目经验需要对可能出现的一些缺陷进行干预活动。
PPL阶段的这些文档都是要经过评审和批准的。
PPL阶段结束后要开开工会议，开工会议邀请到跟项目相关的所有人员参加，由PM介绍项目的整体情况以及一些关键计划。
开工会后项目即进入比较实质的V字型流程的开发流程中：
SRS(STP、STC)ST
/
HLD(ITP、ITC) IT
/
LLD(UTP、UTC) UT
/
CODE
SRS需求分析阶段：该阶段主要是让开发人员详细的对需求进行分析，主要的交付件是需求说明文档和系统测试用例，活动如下：
SWE分析清楚各自的需求是什么，主要是输入、处理、输出
输出SRS文档
评审SRS文档
修改SRS文档
输出STP文档
评审STP文档
修改STP文档
需求跟踪矩阵
根源分析（可选）
代码重估计
更新项目计划和相关文档
发布配置状态报告
阶段结束会议
QA审计
HLD概要设计阶段：
与SRS基本类型，如下有不同
输出的是HLD和ITP：HLD重要的是描述模块间的设计关系和接口
代码重估计是可选
LLD详细设计阶段：
输出的是LLD和UTP：LLD细化到类和主要函数实现，文档中可用伪代码写作。
代码重估计必须
Code：编码阶段
一般编码时间较短。一般达到编译通过，基本功能可用即可。代码需要符合编程规范、经过PC-Lint/代码覆盖率测试等
UT：单元测试
根据LLD阶段输出的UTC进行测试，UTC可补充修改
IT：集成测试
根据HLD阶段输出的ITC进行测试，ITC可补充修改
ST：系统测试
根据SRS阶段输出的STC进行测试，STC可补充修改
BBIT构建模块集成和测试
模块间的集成和测试：比如这个项目中的功能是和另外一个项目中的业务功能耦合在一起的时候，就需要进行BBIT测试。
关闭转测试
发布，转测试部测试。测试部经过三轮的测试后，对外发布。
需求变更：
在项目开发过程需求变化是很难避免的，如果变化影响较大这个时候就需要提出需求变化方填写需求变更说明书。变更说明书需要经过CCB变更控制委员会的批准。PM需要及时根据需求变更调整项目计划或进行一定的规避措施，减少对项目进度和质量的冲击。
例外报告
每个阶段活动或由于团队以外的突发事件影响可能出现项目进度偏差、代码规模偏差、缺陷率偏差、工作量投入偏差等偏差较大的情况。PM需要分析这个偏差数据，找出引发这些偏差的根源，并指定应对措施，需要向QA和开发代表输出例外报告，例外报告需要经过QA批准。
培训活动
每个项目都要根据项目实际情况指定本项目开发活动中需要进行必要的培训活动
项目小组成员及时填写timsheet
Timesheet是度量项目小组成员投入情况的重要收集手段。如果数据填写真实，PM可以从中发现一些引发项目异常的诱因。MC需要及时督促和收集工时投入情况（当然还包括评审意见以及缺陷数据）
每个阶段QA都需要审计，只有QA审计通过了，项目才能进入下一阶段。
PM都需要发布阶段结束报告和阶段结束会议
联系我们
Contact us
战略解码