论文部分内容阅读
盖一栋楼房，很少有人盖到一半提出新的要求，按照设计图纸施工被认为是理所当然的。而软件工程则没有这么幸运，到最后一刻用户都会提出修改要求。凯泽永久的项目也不能幸免，它是怎么做需求管理的呢？
对于大多数组织而言，软件工程项目意味着超支、超时且不满足要求。在项目进行中，软件开发商、公司信息技术部门和公司业务部门之间缺乏必要的沟通，信息不畅、错误理解成为常见现象。一些关键需求没有被给予足够的重视，直到最后时刻才有人恍然大悟：竟然有这个关键需求被忽视了。尽管发现问题比没有发现问题好，可是此时成本已经迅速增加，人们的情绪也可能飞涨，结果让一切变得糟糕而失去控制。
健康维护组织(Health Maintenance Organizations，HMO)凯泽永久(Kaiser Permanente)要求其软件开发商与业务部门之间更加紧密结合，推出了新的需求管理。实践证明，这个方法是强有力的、有效的，是软件工程项目的一剂良药。
磨刀不误砍柴功
目前，全美最大的健康维护组织其中之一，拥有311亿美元资产的凯泽永久发现，由于需求管理不力，它的软件工程项目正在经历困境。为此，凯泽永久决定，修补其软件开发过程以确保与业务实现紧密结合，同时安装需求管理的新软件和程序。在奥克兰、加利福尼亚州，2000名软件开发者中大约700人将使用这个系统，使用其中需求定义和管理软件包。按照凯泽永久的计划，不仅要解决软件工程的设计、测试和配置管理，而且还要估算成本、工期等。
“如果项目范围有变化，我们想通过需求管理软件，测算出它的经济影响。”凯泽永久的需求发展管理经理Schleifer说。
需求管理软件要求开发人员，在处理对新系统的各种需求时使用新的标准化方法，从而减少失误并加速项目开发。在凯泽永久，30个医疗中心的1.2万名医师为840万会员提供服务，有数百个可能在任何特定时间启动的软件工程项目。因此，误差小、返工少的改进方法可能带来的成本节约数额是巨大的。
当然，凯泽永久不会精确地说出他们的预期节约成本额，但Schleifer指出，估计缩短40%的项目时间，这将产生不菲的经济回报。多少才是“不菲”呢？可以考虑八位数。一位参与项目的顾问指出，对于凯泽永久这样一个信息技术预算超过10亿美元的大型组织来说，仅减少返工量一项，节约的成本就达6000万美元。
一位软件工程专家指出，在大多数开发项目中，都会存在30%到50%返工率，而且超过一半的返工是由需求不当引发。如果需求管理可以让凯泽永久这样的公司能够消除返工，大幅度的成本节约将是预期中的事情。
“我们想说的是，首次花1美元获取合适的需求，之后在你测试代码时就能够节省10美元。”Schleifer说。 凯泽永久的一位副总裁认为，从用户手中收集需求的好坏直接关系到软件工程项目的质量。
当然，并不是所有公司都能认识到需求的重要性，更不用说有严格的需求定义和管理程序。但是，凯泽永久已经认识到了，需求对软件开发项目的成功非常重要，尽管目前做得不是很好。
需求风险控制
一般来说，软件工程项目的需求就是指用户使用此软件可能实现某个目标的能力。需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求。从历史经验来看，在软件工程项目中，需求分析工程师在与用户交谈中，发现用户对新系统的需求。
在一些情况下，大开发商拥有自己的分析团队，这些分析团队一般都对软件非常了解，但对专门商业软件或某行业的业务知识知之甚少。一位软件需求管理专家说，分析团队需要能问恰当问题的人，而商业领域的知识对提问题非常有用。
在凯泽永久，许多项目遭受最新的变革、成本超限或错过完成日期，这一切都不是新鲜事情。而且，凯泽永久的项目规模通常都很大，如果在项目快完成的时候发现问题，就会对项目完成时间和成本产生巨大的影响。与此同时，一些启动迟缓的项目，在后来整个过程中都运行得很好。
Schleifer说，凯泽永久已经意识到，需要提高软件项目开发程序的质量，并按时完成，减少成本支出。他认为，急着去做编码的工作，还不如先仔细调查需求。同时，新启用的需求管理软件，可以对需求获取、需求数据库、软件变更和配置管理系统做一个全面的管理，控制需求方面各种潜在风险。使用需求管理软件中的需求定义工具，还可以让需求分析师和业务部门共同来创造和改变需求。
Schleifer和他的同事分析了需求分析上的一些潜在问题。他发现，没有足够业务部门人员参与是最大的问题。经常，业务部门不明白为什么收集需求和确保需求质量需花费那么多功夫，而开发人员可能也不重视用户的参与。Schleifer还发现，需求本应该送到管理者那儿签字，但管理者并没有看到具体细节。
究其原因，是因为一些开发人员认为，与业务部门合作不如编写代码有意思，还有开发人员了解了表面的需求时，就觉得已经明白用户的需求了。对此，Schleifer认为，既使客户也不太明白自己的真正需求，还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。Schleifer还决定，要使用新的需求管理软件，确保开发人员、测试人员能够明白需求的细节。
凯泽永久的开发团队碰到的第二个大问题是，用户需求的不断增加，不断变化。在开发过程中，经常有部门不断地补充需求，使项目就越变越庞大以致超过其计划及预算范围。实际上，这个问题根源在于用户需求的改变和开发者对新需求所作的修改。甚至还有业务部门认为，不再加点什么功能就对不起自己。有的项目在设计阶段没有很好地定义范围，当开发人员向项目管理者提出这个问题时，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，业务部门提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断接到投诉说项目失败。
为把需求变更范围控制到最小，凯泽永久使用需求管理软件对项目视图、范围、目标、约束限制和成功标准给予规范，同时使用软件对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
再一个困扰凯泽永久的问题是模棱两可的需求。模棱两可是需求规格说明中最为可怕的问题之一，它的一层含义是指诸多开发人员对需求说明产生了不同的理解，另一层含义是指单个开发能用不止一个方式来解释某个需求说明。模棱两可的需求会使不同的项目风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。凯泽永久的一位系统测试人员说，由于测试组成员对需求理解有误，以致不得不重写许多测试用例并重做许多测试。这需要不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。
应对渐变的需求
凯泽永久的大多数软件开发专家都认为，对于较大的项目，需求项目的渐变几乎是不可避免的。因此，变更控制程序是一个好助手，项目经理可以看到每一个需求的变化，并推测它对成本和时间的影响，同时知道他们在后面的程序中需要多久来完成这个改变。
Schleifer说，在做一个项目时不得不接受的事实是，需求将会在最后阶段改变，甚至还有项目经理推动项目需求的渐变。但现在和以往不同的一点是Schleifer能够说出，为什么一个项目迟了两个月，并且超出预算资金近百万？同时还可告诉他们，谁在这项目上签的字？现在，Schleifer可以清楚说出需求改变的数量，以及谁要求改变的，谁批准的。
有了问题总是需要去处理问题。凯泽永久的一名项目顾问同时也表示，项目需求的渐变是一个事实，应该是一个组织计划的部分。问题是，管理者往往不接受改变的事实和需求的增长。管理者需要适应改变，并应该有相应的机制去处理它。
当有人发现一个关键的需求被疏忽时，此项目将会在最后时刻遭受打击。这位顾问说：“例如，如果打开病人呼吸器，你发现这个需求漏掉了，这不仅仅是令人难堪的事了，而是会造成重大损失。”
整个需求数据库系统是事件驱动的，每个人都参与到需求开发的过程中，涉及到编码、开发、测试和业务代表，有一个针对需求变化的提议，将会通过E-mail对相关人员提出警告。同时，这系统也说明了因某个需求改变而受到影响的其他需求。
Schleifer说：“人们能根据需求了解变化，并且每个人都能看到那些变化。在这工具中，团队成员能够使用这些工具直接进行检测，这样节省了时间，也减少了需求丢失的可能。同时，这个工具描绘出整个程序，使用户能够回顾不同的业务细节，在确认过程中有很大帮助。”
新的需求管理软件要求业务部门评审需求文档。这给分析人员一个获得反馈信息的机会。如果客户认为编写的需求分析报告不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解需求。原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
尽管对于凯泽永久来说，不能太早报道任何可测量的结果，但公司对业务团体代表的非正式调查收到了肯定的评价，业务团体代表继续制定用于新程序和技术的需求。
一个业务代表认为，预先确定的需求有助于减少规范过程中产生的混淆，这有助于确定公司新经济人销售补偿应用的需求。此补偿应用是用来付给外部销售员向新客户提供凯泽永久健康医疗计划的报酬。
一个开发者说，这给我们带来对我们的商务消费者更大程度的信心。而另外有人写到，如果我们用于一个无论是IT团队还是业务员都可接触的业务需求智囊团，这一定是很有帮助。一个拥有6到12名分析家和开发者的核心团队，与业务代表合作，就能创造出需求。
对于大多数组织而言，软件工程项目意味着超支、超时且不满足要求。在项目进行中，软件开发商、公司信息技术部门和公司业务部门之间缺乏必要的沟通，信息不畅、错误理解成为常见现象。一些关键需求没有被给予足够的重视，直到最后时刻才有人恍然大悟：竟然有这个关键需求被忽视了。尽管发现问题比没有发现问题好，可是此时成本已经迅速增加，人们的情绪也可能飞涨，结果让一切变得糟糕而失去控制。
健康维护组织(Health Maintenance Organizations，HMO)凯泽永久(Kaiser Permanente)要求其软件开发商与业务部门之间更加紧密结合，推出了新的需求管理。实践证明，这个方法是强有力的、有效的，是软件工程项目的一剂良药。
磨刀不误砍柴功
目前，全美最大的健康维护组织其中之一，拥有311亿美元资产的凯泽永久发现，由于需求管理不力，它的软件工程项目正在经历困境。为此，凯泽永久决定，修补其软件开发过程以确保与业务实现紧密结合，同时安装需求管理的新软件和程序。在奥克兰、加利福尼亚州，2000名软件开发者中大约700人将使用这个系统，使用其中需求定义和管理软件包。按照凯泽永久的计划，不仅要解决软件工程的设计、测试和配置管理，而且还要估算成本、工期等。
“如果项目范围有变化，我们想通过需求管理软件，测算出它的经济影响。”凯泽永久的需求发展管理经理Schleifer说。
需求管理软件要求开发人员，在处理对新系统的各种需求时使用新的标准化方法，从而减少失误并加速项目开发。在凯泽永久，30个医疗中心的1.2万名医师为840万会员提供服务，有数百个可能在任何特定时间启动的软件工程项目。因此，误差小、返工少的改进方法可能带来的成本节约数额是巨大的。
当然，凯泽永久不会精确地说出他们的预期节约成本额，但Schleifer指出，估计缩短40%的项目时间，这将产生不菲的经济回报。多少才是“不菲”呢？可以考虑八位数。一位参与项目的顾问指出，对于凯泽永久这样一个信息技术预算超过10亿美元的大型组织来说，仅减少返工量一项，节约的成本就达6000万美元。
一位软件工程专家指出，在大多数开发项目中，都会存在30%到50%返工率，而且超过一半的返工是由需求不当引发。如果需求管理可以让凯泽永久这样的公司能够消除返工，大幅度的成本节约将是预期中的事情。
“我们想说的是，首次花1美元获取合适的需求，之后在你测试代码时就能够节省10美元。”Schleifer说。 凯泽永久的一位副总裁认为，从用户手中收集需求的好坏直接关系到软件工程项目的质量。
当然，并不是所有公司都能认识到需求的重要性，更不用说有严格的需求定义和管理程序。但是，凯泽永久已经认识到了，需求对软件开发项目的成功非常重要，尽管目前做得不是很好。
需求风险控制
一般来说，软件工程项目的需求就是指用户使用此软件可能实现某个目标的能力。需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求。从历史经验来看，在软件工程项目中，需求分析工程师在与用户交谈中，发现用户对新系统的需求。
在一些情况下，大开发商拥有自己的分析团队，这些分析团队一般都对软件非常了解，但对专门商业软件或某行业的业务知识知之甚少。一位软件需求管理专家说，分析团队需要能问恰当问题的人，而商业领域的知识对提问题非常有用。
在凯泽永久，许多项目遭受最新的变革、成本超限或错过完成日期，这一切都不是新鲜事情。而且，凯泽永久的项目规模通常都很大，如果在项目快完成的时候发现问题，就会对项目完成时间和成本产生巨大的影响。与此同时，一些启动迟缓的项目，在后来整个过程中都运行得很好。
Schleifer说，凯泽永久已经意识到，需要提高软件项目开发程序的质量，并按时完成，减少成本支出。他认为，急着去做编码的工作，还不如先仔细调查需求。同时，新启用的需求管理软件，可以对需求获取、需求数据库、软件变更和配置管理系统做一个全面的管理，控制需求方面各种潜在风险。使用需求管理软件中的需求定义工具，还可以让需求分析师和业务部门共同来创造和改变需求。
Schleifer和他的同事分析了需求分析上的一些潜在问题。他发现，没有足够业务部门人员参与是最大的问题。经常，业务部门不明白为什么收集需求和确保需求质量需花费那么多功夫，而开发人员可能也不重视用户的参与。Schleifer还发现，需求本应该送到管理者那儿签字，但管理者并没有看到具体细节。
究其原因，是因为一些开发人员认为，与业务部门合作不如编写代码有意思，还有开发人员了解了表面的需求时，就觉得已经明白用户的需求了。对此，Schleifer认为，既使客户也不太明白自己的真正需求，还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。Schleifer还决定，要使用新的需求管理软件，确保开发人员、测试人员能够明白需求的细节。
凯泽永久的开发团队碰到的第二个大问题是，用户需求的不断增加，不断变化。在开发过程中，经常有部门不断地补充需求，使项目就越变越庞大以致超过其计划及预算范围。实际上，这个问题根源在于用户需求的改变和开发者对新需求所作的修改。甚至还有业务部门认为，不再加点什么功能就对不起自己。有的项目在设计阶段没有很好地定义范围，当开发人员向项目管理者提出这个问题时，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，业务部门提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断接到投诉说项目失败。
为把需求变更范围控制到最小，凯泽永久使用需求管理软件对项目视图、范围、目标、约束限制和成功标准给予规范，同时使用软件对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
再一个困扰凯泽永久的问题是模棱两可的需求。模棱两可是需求规格说明中最为可怕的问题之一，它的一层含义是指诸多开发人员对需求说明产生了不同的理解，另一层含义是指单个开发能用不止一个方式来解释某个需求说明。模棱两可的需求会使不同的项目风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。凯泽永久的一位系统测试人员说，由于测试组成员对需求理解有误，以致不得不重写许多测试用例并重做许多测试。这需要不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。
应对渐变的需求
凯泽永久的大多数软件开发专家都认为，对于较大的项目，需求项目的渐变几乎是不可避免的。因此，变更控制程序是一个好助手，项目经理可以看到每一个需求的变化，并推测它对成本和时间的影响，同时知道他们在后面的程序中需要多久来完成这个改变。
Schleifer说，在做一个项目时不得不接受的事实是，需求将会在最后阶段改变，甚至还有项目经理推动项目需求的渐变。但现在和以往不同的一点是Schleifer能够说出，为什么一个项目迟了两个月，并且超出预算资金近百万？同时还可告诉他们，谁在这项目上签的字？现在，Schleifer可以清楚说出需求改变的数量，以及谁要求改变的，谁批准的。
有了问题总是需要去处理问题。凯泽永久的一名项目顾问同时也表示，项目需求的渐变是一个事实，应该是一个组织计划的部分。问题是，管理者往往不接受改变的事实和需求的增长。管理者需要适应改变，并应该有相应的机制去处理它。
当有人发现一个关键的需求被疏忽时，此项目将会在最后时刻遭受打击。这位顾问说：“例如，如果打开病人呼吸器，你发现这个需求漏掉了，这不仅仅是令人难堪的事了，而是会造成重大损失。”
整个需求数据库系统是事件驱动的，每个人都参与到需求开发的过程中，涉及到编码、开发、测试和业务代表，有一个针对需求变化的提议，将会通过E-mail对相关人员提出警告。同时，这系统也说明了因某个需求改变而受到影响的其他需求。
Schleifer说：“人们能根据需求了解变化，并且每个人都能看到那些变化。在这工具中，团队成员能够使用这些工具直接进行检测，这样节省了时间，也减少了需求丢失的可能。同时，这个工具描绘出整个程序，使用户能够回顾不同的业务细节，在确认过程中有很大帮助。”
新的需求管理软件要求业务部门评审需求文档。这给分析人员一个获得反馈信息的机会。如果客户认为编写的需求分析报告不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解需求。原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
尽管对于凯泽永久来说，不能太早报道任何可测量的结果，但公司对业务团体代表的非正式调查收到了肯定的评价，业务团体代表继续制定用于新程序和技术的需求。
一个业务代表认为，预先确定的需求有助于减少规范过程中产生的混淆，这有助于确定公司新经济人销售补偿应用的需求。此补偿应用是用来付给外部销售员向新客户提供凯泽永久健康医疗计划的报酬。
一个开发者说，这给我们带来对我们的商务消费者更大程度的信心。而另外有人写到，如果我们用于一个无论是IT团队还是业务员都可接触的业务需求智囊团，这一定是很有帮助。一个拥有6到12名分析家和开发者的核心团队，与业务代表合作，就能创造出需求。