2007-7-17 13:19:07
以需求驱动来切实作好软件过程改进工作
前些日子公司刚通过了CMMI三级评估，感触还是很多，最大的一点就是CMMI过程改进的工作必须以项目的实际需求来驱动，而不是说CMMI强制要求你怎样去做，无中生有。只有真正的体会到这一点，才可能积极的去配合和实施CMMI，组织和项目的过程成熟度才能够提高。
CMMI过程改进是一个系统化过程，设计到个体，项目或组织的所有干系人的参与，同时还设计到组织的一些变革。CMMI只会告诉你需要做什么，但具体如何做？采用什么工具，方法和技术？遵循什么样一个标准的步骤来做？并没有给出答案。因此严格来讲CMMI本身不能够做为方法论。具体的方法，技术和工具的应用是在组织实施CMMI过程中，根据自身特点，实践，借鉴其它公司和项目成功经验不断总结和改进出来的。所以CMMI实施工作最好方式是以实际需求来驱动，真正遵循IDEAL组织过程改进模型。
CMMI虽然没有告诉我们如何做，但至少告诉我们了要做哪些事情。其实如何做本身并不可怕，往往可怕的是我们根本都不知道需要做什么事情。组织或项目乃至个人都有独立解决问题的能力，但可怕的是他们无法意识到自身存在问题。
另外我们不应该过分的去追求一定要采用什么方法或工具来做什么事情。如需求追踪并不一定要采用专门的类似RP的需求追踪工具才能够做。很多时候往往一个简单Excel就能够很好的达到追踪的效果。
这里先谈下跟软件生命周期相关过程相关的问题。
1.需求过程常见的问题和场景描述
需求描述含糊不清，有时候分析人员自我揣测用户需求
REQM_SP1.1 需求必须清新准确描述，唯一标识，可验证，可测试，可实现，可追踪
REQM_SP1.2 需求必须获得相关干系人的承诺，包括提供原始需求的用户和需求的实现人员
REQM_SP1.1 需求必须清新准确描述，唯一标识，可验证，可测试，可实现，可追踪
REQM_SP1.2 需求必须获得相关干系人的承诺，包括提供原始需求的用户和需求的实现人员
需求经常发生变化，对整个项目进度和质量造成巨大影响
REQM_SP1.3 需求的变更必须受到管理
REQM_SP1.3 需求的变更必须受到管理
开发出来的产品或系统不是用户真正想要的东西
REQM_SP1.2 需求开发完成后必须获得用户的承诺
RD_SP1.1 可以通过调研，原型，头脑风暴，同类产品对比，调查表，访谈，业务用例分析等多种方法发掘用户需求
RD_SP1.2 文档化下用户需求，明确定义确认和验证准则
REQM_SP1.2 需求开发完成后必须获得用户的承诺
RD_SP1.1 可以通过调研，原型，头脑风暴，同类产品对比，调查表，访谈，业务用例分析等多种方法发掘用户需求
RD_SP1.2 文档化下用户需求，明确定义确认和验证准则
需求分析不考虑系统的非功能性需求，如系统的性能和安全性等，使系统很难真正成为一个产品
REQM_SP1.1 组织级需要定义理解非功能性需求的详细指南
REQM_SP1.1 组织级需要定义理解非功能性需求的详细指南
在需求出现变更时候经常出现补东墙，拆西墙情况。项目频繁救火。
REQM_SP1.4 需求必须是双向可追踪的
REQM_SP1.4 通过纵向追踪识别需求变更对设计开发和测试影响。通过横向追踪识别需求
REQM_SP1.4 需求必须是双向可追踪的
REQM_SP1.4 通过纵向追踪识别需求变更对设计开发和测试影响。通过横向追踪识别需求
变更对其它已有需求的影响
用户想要什么就给什么，不做对用户潜在和真实需求的挖掘，导致系统变成一个定制应用而很难产品化
RD_SP2.1 将用户需求转化为产品和产品组件需求
RD_SP2.3 识别出需求和功能点的接口
RD_SP2.1 将用户需求转化为产品和产品组件需求
RD_SP2.3 识别出需求和功能点的接口
用户想要的东西不加思索的全部承诺，到后面却无法实现，及时实现也对整个系统架构造成巨大影响
RD_SP3.4 通过模拟，原型等多种方式来考虑可实现性和相关风险
RD_SP3.3 项目应该识别出对系统架构有重大影响的关键需求
RD_SP3.4 通过模拟，原型等多种方式来考虑可实现性和相关风险
RD_SP3.3 项目应该识别出对系统架构有重大影响的关键需求
2.设计开发方面的常见问题
各子功能或模块都开发完成时候结果产品集成时候出现大问题
系统在正式部署出现问题后不能很好的回退
TS_SP2.1 开发产品化组件，定义内部和外部接口，定义组件复用，设计准则，包和子系统的划分
PI_SP1.2 建立产品集成的环境
PI_SP1.3 建立产品的集成过程和准则
PI_SP3.2 装配产品组件
系统中的各子系统或模块藕合紧密，接口定义不清晰
开发过程中的安全，异常和日志等都没有统一的处理规范和准则
在针对用户的一些多样化需求的时候，系统需要修改或改造大量代码才能够实现
TS_SP1.3 文档化技术解决和实现方案和产品组件的选择
TS_SP2.1 开发产品化组件，定义内部和外部接口，定义组件复用，设计准则，包和子系统的划分
TS_SP2.1 设计应该满足清楚，简单，可维护，可验证，准确，安全，可扩展，可用的准则
TS_SP2.2 建立项目的技术资料包(重点是架构文档)
TS_SP2.3 建立接口描述
TS_SP2.4 确定相关组件是采购，复用还是新开发
开发过程中的安全，异常和日志等都没有统一的处理规范和准则
在针对用户的一些多样化需求的时候，系统需要修改或改造大量代码才能够实现
TS_SP1.3 文档化技术解决和实现方案和产品组件的选择
TS_SP2.1 开发产品化组件，定义内部和外部接口，定义组件复用，设计准则，包和子系统的划分
TS_SP2.1 设计应该满足清楚，简单，可维护，可验证，准确，安全，可扩展，可用的准则
TS_SP2.2 建立项目的技术资料包(重点是架构文档)
TS_SP2.3 建立接口描述
TS_SP2.4 确定相关组件是采购，复用还是新开发
产品很难交给他人安装和维护，用户拿到产品不知如何开始使用
TS_SP3.2 开发跟产品相关的用户手册，安装手册，维护手册等各种文档
TS_SP3.2 开发跟产品相关的用户手册，安装手册，维护手册等各种文档
编码没有重要注释，编码没有统一的编码规范和风格，导致代码可读性和可维护性都较差。
编码中大量拷贝，粘贴代码片断的情况
TS_SP3.1 设计的实现，编码应该考虑相关的规范和准则，考虑代码的可维护性。
编码中大量拷贝，粘贴代码片断的情况
TS_SP3.1 设计的实现，编码应该考虑相关的规范和准则，考虑代码的可维护性。
开发产品质量保证方面的
VER_SP1.1 应用提前计划出哪些工件或工序需要进行验证
VER_SP2.1 执行同行评审(包括审查，走查，互查)
VER_SP2.2 需要对同行评审的结果数据进行分析，对泄露进行分析，改进同行评审过程
VAL_SP1.3 建立确认过程和确认准则
VAL_SP2.1 执行确认过程(主要是用户验收和测试过程)
IT_SP1.2 标识出项目或团队所需要的知识和技能
IT_SP2.2 确定团队的章程
IT_SP2.3 确定团队成员的角色和相关责任
VER_SP1.1 应用提前计划出哪些工件或工序需要进行验证
VER_SP2.1 执行同行评审(包括审查，走查，互查)
VER_SP2.2 需要对同行评审的结果数据进行分析，对泄露进行分析，改进同行评审过程
VAL_SP1.3 建立确认过程和确认准则
VAL_SP2.1 执行确认过程(主要是用户验收和测试过程)
IT_SP1.2 标识出项目或团队所需要的知识和技能
IT_SP2.2 确定团队的章程
IT_SP2.3 确定团队成员的角色和相关责任
0
推荐到鲜果：
下一篇：我的Blog升级了
上一篇：对软件测试工程师面试题目的回答
评论