典型情境是指软件开发的常见情境,本文选择如下来进行分析:
1. 传统瀑布模型开发下的需求评审
2. 使用IEEE Std. 1028的需求评审
3. 敏捷开发下的需求评审
传统瀑布模型下的需求评审
对传统瀑布模型现有需求评审的分析
传统瀑布模型在需求阶段末期安排有关键的需求里程碑评审,其特征参见2.8节情况1。在业界实际操作中,往往出现如下情况:
1,召集包括领导在内的各方代表,历经1~2小时会议,评审30页以上需求规格说明书,走过场式各方签字通过评审;
2,各方对需求规格书有各种各样意见,历经3~n次评审会,眼看工期已经有明显拖延,后续开发已经跟进,甚至开发快完成了,总算获得通过;
3,经过多方运筹协调,前后费时4周多,召集各方到某度假村,历经三天讨论修改评审,总算通过评审。
以上情况就体现了前文所言的“官僚繁琐、繁文缛节”,其弊端明显。在[26]文同样也识别到:需求评审往往流于形式。
受CMM/CMMI要求和启发,为了让需求阶段最后的里程碑评审能够顺利通过,需求同级评审得到了使用[12][13]。常见有如下情况:
1,在需求完稿时,计划一次同级评审会议,关注于技术方面,形成同级评审发现和记录。这对胜利通过里程碑评审有很大帮助,但往往是更为了应付CMM/CMMI的评估;
2,分阶段安排多次会议或非即时的需求同级评审,关注技术方面,记录评审发现并解决。这是CMM/CMMI比较推荐的做法,能大大缓解瀑布型需求阶段里程碑评审的弊端。
综合以上分析,为便于整体理解,得下表。
表8 瀑布模型下需求评审情况
标准评审 | 需求评审框架分析说明 |
---|---|
需求里程碑评审 | 有预审的会议形式,里程碑,技术和管理方面,非同级需求文档评审 |
需求完稿同级评审 | 有预审的会议形式,完稿,技术方面,同级需求文档评审 |
分段需求同级评审 | 有预审的会议形式,分段,技术方面,同级需求文档评审 |
新需求评审框架对传统瀑布模型的启示
启示1:值得开展定期的双人即时评审,每次时间约15~30分钟,适合位置坐在一起的团队同伴。好处:尽早交流,彼此学习。
启示2:值得把技术方面评审与管理方面评审分开,先进行各种类型的技术方面评审,然后召开里程碑管理方面评审。好处:技术方面评审问题解决后,需求阶段里程碑评审着重于管理方面,比如需求规模、进度、工作量等等,更加关注项目整体成功,也能大大节约会议时间。
使用IEEE Std. 1028的需求评审
对照到需求评审,IEEE Std. 1028中的管理评审、技术评