花在需求上的时间及其对项目成功和开发时间的影响


15

是否有证据表明花时间在编写或思考需求上会对开发时间产生影响?Standish(1995)进行的研究表明,部分不完整的需求(13.1%)导致了项目的失败。是否有任何研究表明花费在需求分析上的时间会影响项目的开发时间或项目的成功程度。


3
敏捷模型如何适合这里?可以说,他们花了需求的时间(打开和关闭),但没有这样的需求“阶段”。
拉斐尔

1
同意@Raphael。我们要对软件工程提出疑问吗?还是该站点的正式政策不值得在此时区分“计算机科学”和“软件工程”?
Patrick87 2012年

1
@ Patrick87让我们将其移至meta
拉斐尔

在我看来,这个问题将更适合现有的软件工程项目管理站点。
亚当李尔

Answers:


10

请参阅表3-1,Steve McConnell编写的Code Complete。他根据引入和检测缺陷的时间比较修复缺陷的平均成本。在构建时进行检测的成本比在需求时进行检测的成本高5-10倍,而发布后的成本则高10-100倍。

该表基于以下来源:

  1. “减少程序开发中的错误的设计和代码检查”(Fagan 1976)

  2. 软件缺陷清除(Dunn 1984)

  3. “休斯飞机的软件过程改进”(Humphrey,Snyder和WIllis,1991年)

还有更多


仅凭这一点还不够。昂贵的错误必须经常发生,并且必须通过提出适当的要求来经常发现。否则,提出需求的额外成本可能仍会超过错误成本。
拉斐尔

确实如此。我们必须假设,在一定程度上,不急于需求意味着需求中的错误更少,但这似乎并不过分。
2012年

10

是的,有关此主题的研究很多。当然,对于所有类型的软件开发项目来说,这个问题都太笼统了,但是从多种情况来看,有证据支持正确地进行需求分析将对实施阶段产生积极影响的观点。此证据已部分收集到“法律”中,下面是三个示例:

格拉斯定律: 需求不足是项目失败的主要原因。

该法律得到大型软件开发项目的案例研究证据的支持。格拉斯发现,在失败的案例中,需求太多了,由于后期更改而不稳定,并且模棱两可且不完整。

这表明需求质量与项目成果之间存在联系。

Boehm的第一定律: 在需求和设计活动中,错误最常见,而消除错误的代价越大。

这也得到了案例研究证据的支持,并有助于通过以下方式回答问题:正确执行需求将减少系统中的错误数量,并且在开始实施之前纠正错误将比寻找它们更便宜。当实施已经开始时(或者更糟糕的是,系统已经交付时)关闭。

Boehm的第二条定律:( 显着)原型减少了需求和设计错误,尤其是对于用户界面。

这是通过在学生环境中进行受控实验来支持的。一种可能的解释是,需求和设计阶段不必完全由文档驱动和理论化。取而代之的是,将原型作为需求和设计阶段的一部分,这相当于花时间在思考需求上,这将影响项目的成功和实施时间。

还有许多其他证据也指向同一方向:花时间准备实施会以较低的风险和因意外而导致进度超支的机会得到回报。尽管问题不关乎测试,但适当的准备也对测试产生积极影响。

这些法律的参考是:

格拉斯定律:格拉斯,RL:软件失控。从大规模软件项目失败中学到的教训。新泽西上萨德尔河:Prentice Hall 1998

Boehm的第一定律:Boehm,BW,McClean,RK,Urfrig,DB:大型可靠软件设计的自动辅助方面的一些经验。IEEE Trans on软件工程1,1,(1975),125–133

Boehm的第二定律:Boehm,BW,Gray,TE,Seewaldt,T .:原型设计与指定:多项目实验。IEEE Trans on软件工程10,3(1984),290–302

同样,以下参考文献可能是您感兴趣的:Endres,A.和Rombach,D.软件和系统工程手册。实证观察,定律和理论。Fraunhofer IESE系列软件工程。艾迪生·韦斯利(Addison Wesley),2003年。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.