SRE01需求实践现状分析.pptVIP

SRE01-需求实践现状分析 1、概述 在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。 然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上创造真正的效益。 归根结底，软件需求实践这一共同的软肋是问题的根源。 2 、软件项目失败的根源 “在中国做软件太难了!客户连自己的需求都说不清楚” 。 软件项目失败率居高不下、需求问题层出不穷的现象并不仅仅是中国软件业的困扰，全世界的软件业也未能幸免。 第三方机构StandishGroup所对软件项目实践现状进行分析与统计。 StandishGroup 报表表1-1 项目超支、超期情况分析 软件项目失败的根源 为了帮助软件开发组织找到明确的改进方向，StandishGroup还总结出了十大成功保证(针对或功项目的总结)和十大败因(针对彻底失败项目的总结), 如下表所示。 表1-2 项目成败因素分析 软件项目失败的根源 在表1-2中可以看出，十大成功保证中有三个是直接与需求相关的(已加粗显示)，累计权重达到37.1％；而十大败因中与需求直接相关的更是高达五个，累计权重高达51.6％，可见需求问题对项目影响程度之高。 软件项目失败的根源 而对于那些成本超支、进度超期的项目而言，报告也总结出了导致这一结果出现的十大因素： 缺乏用户参与、不完整的需求、需求变更频繁、缺乏执行层的支持、技术能力缺乏、资源不足、不切实际的用户期望、没有清晰的愿景和目标、不切实际的时间限制、新技术风险。 3、需求相关败因简要分析 CHAOS报告总结的“软件项目十大败因”中，有五项是与软件需求直接相关的。以下我们就简要地对这些失败因素做个初步的分析。 (1) 不完整的需求 什么样的需求是完整的呢? 实际上，如果没有一个有效的“完整仁评价标准”，那么这个问题也必将是无解的。 不完整的需求 “谁更有可能可以对需求的完整性进行评价?”。我想大家一定会认同“用户代表要比开发人员更适合对完整性进行评价”这一观点吧! 而当我们回头去审视“软件需求规格说明书”时，却发现其中充斥着诸如数据字典管理、报表子系统、新增客户等以技术动词为主的表述方式，这样做显然会将技术功底并不深厚的用户代表排除在有效读者群之外。 不完整的需求 因此要想让用户代表能够更好地参与到完整性评价中来，就必须采用“业务导向”的组织结构，而不是让用户将一大堆技术动作翻译到自己的业务场景中去。 在实际的操作过程中还有一个要点，那就是利用树型层次结构将宏观信息与微观信息进行有效的剥离。 不完整的需求 验证变成确认 试图以“以点代面”的形式完成验证 需求规格说明书应该采用业务导向的树型层次结构来组织. (2) 缺乏用户参与 用户都不能有效地参与到项目中来，也许诸如“你们先做，做出来我们试试后再改”之类的话。实际上这个现象的背后存在几个方面的因素。 事不关己，高高挂起 逃离无趣区 被你赶走 缺乏用户参与 通过业务利益争取用户参与到需求活动中，始终让技术解决方案在冰山之下以使用户不中途离开，也许是缓解该问题的很重要的策略。 对于需求分析员而言,真正的专业主义是基于业务利益(解决问题、创造机会、提高管控力等)的沟通。 （3）不切实际的用户期望 在实际上，用户总是很天真地提出了大量的需求，有些是技术上根本无法实现的，有些则是原本就脆弱的费用与时间预算内无法实现的。 就像孩子们不知道能够飞上月球的航天飞机要多少钱一样，客户也不知道自己提出的需求真的需要多大的成本。 不切实际的用户期望 那么问题的根源是什么呢? 其实原因就在于软件的无形和成本的不透明。 简单地说，做不到是无效的，要说明为什么做不到才能解决问题。 （4）需求变更频繁 在国内软件行业中，对变更进行分类、统计的做法仍然不是很普遍。但如果只是简单地将所有的需求变更都当作一个问题来看待，那么是无法有效地找出问题的根源的，也无法有针对性地改进需求过程，提高设计的弹性。这也许就是经验和经历之间的区别吧! 需求变更频繁 另外一方面，用户并没有意识到变更对软件项目的负面影响。而究其原因，其实与绝大多数软件企业一样缺乏统一的变更处理渠道，使得变更相对而言比较散落，没有集中地体现出来。 5 提供了不再需要的 到底谁才是知道用户最需要什么功能的人呢?产品经理、开发人员还是用户代表? 其实最了解用户需求的是软件本身!越经常被使用到的功能，就是越重要的功能，那些根本没有几次访问量的功能模块，一定是那些不再需要的。 3 透过表象，分析本质 低质的医术： “头痛医头，脚痛医脚”，低级的观点：“软件项目失败的关键在于项目管理技能不足”。 虽然提高项目管理能力很重要，但它不是万能的；现在许多软件项目遇到的问题，从表面上看