FDD不能参与CMM实践吗？——特征驱动开发方法在CMM中的实践（茹海燕）

特征驱动开发方式，即FDD，是在对软件项目进行严格的CMM等流程控制，和对用户需求的快速反应之间的矛盾日益尖锐之时，应运而生的一种软件开发方式。它将关注的目标牢牢定位在软件的实际设计和构造上，力争让软件开发挣脱流程和框架的束缚，显现它的生命力。FDD以用户的需求为驱动，分析其特征，制定计划，针对特征进行设计和构造，然后不断地迭代，直至完全满足用户对系统的需求。这就是FDD的五个过程，如图1所示。

图1 FDD的五个过程

（原图选自《特征驱动开发方法原理与实践》）

然而，过多的灵活性在没有严格流程的约束时，必然会渐渐走向另一个极端：无秩序状态；而且对于已经实施了CMM的软件企业，对特殊的项目网开一面，采用另一套流程管理，不但增加了管理难度，也会引起潜在的不平等议论，最终也难免引发新一轮矛盾的产生。那么，“既然山不能到穆罕默德这里来，穆罕默德可以到山那里去”，能不能将CMM的流程进行改造，将FDD纳入CMM流程管理呢？

回答是：完全可以。在一个经常需要根据用户需求而变更的维护系统中，我们采用了特征驱动的开发方法原理，同时采用CMM的流程管理，取得了很好的效果，以下就是我们的做法。

首先我们来分析FDD的五个过程，其一，属于业务模型构建，主要是分析用户需求，并经过评审；其二，是在业务模型的基础上，分析列举系统需要完成的用户要求，这是一个FDD完整周期需要完成的研发目标；其三，根据过程二的目标制定详细计划；其四和五，当然是不断地完成详细的设计、评审、编码、调试、测试，直至本次FDD列举的所有用户需求都满足，新的版本可以发布。

仅以CMM2和3举例，与FDD五个过程相应的CMM流程包括：需求管理（RM）中的用户需求分析和系统需求分析；同行评审（PR），软件项目管理（SPP），项目计划追踪（SPTO），软件配置管理（SCM），软件质量保障（SQA）等等。这些过程与FDD过程的对应关系如图2所示。

图2 FDD与CMM的过程对应关系图

有人会问，这样子不是又要全盘采用CMM，让项目背上沉重的壳子，步履蹒跚吗？不，所有这些CMM的流程都要经过多方协调，为了达到特征驱动开发的目标：关注实际设计和构造，让繁冗的流程事件不至于影响项目的进度。具体来讲，经过协调，与SQA达成共识：

1． 在SPP过程制定项目策略计划

这不是一个有确定时间规划和版本规划的可执行计划，而是一种“战略规划”。它明确地定义，什么样的用户需求变更，采用正式的CMM流程，什么样的需求变更可以采用简约流程。而且，还定义了简约流程中项目的模式，如整个项目采用迭代式开发，分期发布版本，每个版本采用瀑布式开发；定义了此后每个版本根据用户需求规模，制定具体的项目执行计划的模式，如需求在评审之后，可以不进行系统设计，直接进入详细设计等；相应的项目追踪SPTO与之适应。

2． 需求管理RM不能省略

因为用户的需求此时成为指导项目方向的灯塔；不过，这个阶段的加速体现在PR中；

3． 同行评审PR设立三种方式以适应不同的场合

（1）审查，即要求所有相关同行必须进行预审，和召开正是评审会议，周期一般在三天；
（2）走查，人员在3到4人，采用电子评审方式，不用开会，主持人将被评审对象发送给各个评审员，大家提出意见，如果问题不大，作者答复即可；如果问题较大，再召开评审会议，周期一般1到2天；
（3）单人复审，只有一名评审员，单独审查作者提交的文档或者代码，并直接与作者交流，最终确定是否评审通过，周期一般1到2天；

所以，简约流程一般采用走查形式，而对于涉及面更小的用户需求，采用单人复审即可。

4． 软件配置管理SCM也相应裁减

每个版本的需求分析、计划、设计和构造，涉及的只是系统的一部分，因此配置管理只针对这新增或者修改的部分，进行统计和审查，其他部分采用“引用以前文件”的方式提供其状态报告和数据。同样，相应的测试也采用模块测试加回归测试的方式执行。这中间涉及到一个问题：如何判断哪些部分是新增或者修改的，哪些部分没有变动过呢？这个责任主要应由项目组承担，所以由项目组向SCM管理员提供相关资料来说明。

经过这样的调整，CMM推进组和项目组互相达成谅解，对开发需要遵守的过程取得共识，制定的规范过程得到了项目组的支持和配合。同时，项目组也得到了充分的活动空间来关注自己的事情，双方在此后的合作也很愉快。这些经验很快在其他项目中间得到了推广。
FDD与CMM，并不是天生的冤家，他们都是为了将软件做得更好。他们同样有活力，但是都需要人来深刻理解各自的精髓和使用方式，并且活学活用，才能达到其效果。

本文由作者向AMT提供
作者联系方式：ru.haiyan@zte.com.cn

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友