Get best of the week

更改项目需求是关键的软件开发问题


开发大型计算机程序以交付给客户的步骤

上面的插图摘自Winston Royce博士在1970年发表的文章 “管理大型软件系统的开发”。可以相信，这是软件工程中对瀑布模型的首次描述。罗伊斯博士的图表遍布数百本教科书和文章。但是他们经常忘记瀑布的发明者立即写道：“这种特殊的实施是有风险的，并且会带来失败。”

我们开发软件来满足任何客户，用户或市场的需求。作为计算机科学领域的软件工程，其任务是使这种发展可预测且具有成本效益。

自第一次使用以来已有50多年的历史了在IFIP软件工程会议上，在此期间，提出了许多不同的技术，过程和模型来帮助开发人员实现这一可预测且具有成本效益的过程。但是即使在半个世纪之后，我们仍然遇到与以往一样的问题：迟到，结果不令人满意以及项目完全失败。

拿我多年以前从事的政府合同。毫无疑问，这是我有史以来最成功的项目，至少从正常的项目管理指标来看：它比预算提前完成，并在短短三天内通过了每月验收测试。

此项目有一些不寻常的限制。合同被提名并以绝对固定的固定价格以外币支付。合同根本没有规定任何变更管理过程。验收测试实际上是以一系列“可以做到这一点”的可观察测试的形式作为合同的一部分而进行的-通过测试（是/否）的检查几乎没有争议的空间。根据合同条款，要求或汇率发生任何变化的全部风险由我公司承担。

该过程绝对是经典的瀑布，我们充满信心地完成了各个阶段，直到最终系统完成安装，接受并通过了验收测试。

之后，我又与该系统一起工作了18个月，对其进行了修改，直到真正满足客户需求为止。事实是，在合同签订和软件交付之间的一年中，报告表格发生了变化，硬件平台的某些组件被新的和更先进的产品所取代，并且对系统应响应的法规进行了更改。

需求在变化。每个软件开发项目都会在某个时候遇到这个难题。

因此，所有软件开发过程都可以看作是针对此基本问题的各种解决方案。瀑布的最初（也是幼稚的）过程只是假设您可以从牢固批准必须满足的要求开始。

据信，Winston Royce博士在“大型软件系统的开发管理”中对瀑布进行了首次描述。他创建的数百张软件工程工作，教科书和文章中的插图都是可识别的图表。但是，通常会忘记，罗伊斯（Royce）在原始文章中还说：“ [此图上的]实现是有风险的，并且会导致失败。”

流程与环境保持一致


罗伊斯（Royce）的观察-从定义需求和提议的解决方案到创建软件，然后对其进行测试以符合这些要求，都经历了某些阶段-很好。实际上，即使从计算机科学领域的第一批作业开始，每个程序员都对此很熟悉。但是，如果您的需求在整个项目中都在变化，那么即使您完全满足初始需求，也可以保证无法满足客户的需求。

实际上，只有一个答案：您需要找到一种方法来确保需求开发交付周期与需求变更的速度相匹配。在我的政府项目中，我们是人为地完成的：在没有重大更改的情况下，很容易根据规格制造产品并通过验收测试。

罗伊斯（Royce）的原始文章实际上认识到开发过程中发生变化的问题。他的文章描述了一个迭代模型，其中意外的更改和无效的设计决策将流程返回到开发阶段。


该过程不限于连续步骤。温斯顿·罗伊斯（ Winston Royce）的文章中的插图

软件开发中的现实主义


一旦我们接受了软件开发始终是不确定性的内在要求，即需求不会长期保持不变，那么我们就可以开始开发应对不可避免的变化的方法。

首先，接受改变是不可避免的。

无论计划多么周密，任何项目最终都将至少与最初设想的项目稍有不同。开发过程必须接受这一点，并准备采取行动。

因此，该软件永远不会终止，而只会被放弃。

我们喜欢庆祝开发项目“完成”的一个特殊的，明确定义的时刻。但是，现实情况是，当我们说“一切都完成了”时，任何固定的时间点都只是人为的分界线。从“成品”交付之日起，新功能，经过修订的功能和错误修复将开始出现（实际上，在软件发布的那一刻，仍然有必要进行更改，这代表技术上的欠缺和延期的要求）。只要使用该软件产品，这些更改将继续。

这意味着没有软件产品能够绝对令人满意。。真正的软件开发就像在移动的目标上射击–目标的各种随机变化，目标运动，风和振动保证：尽管您可能接近靶心，但您将永远无法达到完美。

适应环境变化的过程


按照这种观点，软件开发可能看起来令人沮丧，甚至令人沮丧。听起来一切听起来好像可预测且具有成本效益的开发概念是梦are以求的。

不，不是这个。我们的论点是，如果考虑到现实情况，我们可以成为非常有效的开发人员。

第一个现实：尽管完美本身是无法实现的，但务实的成功是完全可能的。精益创业运动已成为MVP创业公司的共同目标，这是“最小可行的产品”。我们必须将这一思想扩展到所有发展中，并承认每种产品实际上都是MVP，这是当前对问题的最佳理解。

第二个现实是，我们不能真正停止需求的变化，因此我们需要在这样的条件下工作。长期以来，在实际开发中就已经理解了这一点：Parnassus规则提供了将系统拆分为模块的功能，以便在发生更改时增加系统的灵活性。同时，已经反复尝试以逐次逼近的方式描述软件开发过程，即渐进式开发过程（我将其称为“ 一次又一次” 方法论）。

一旦我们认识到？如果我们需要逐步发展，那么一旦我们摆脱理想解决方案的概念，我们便可以从容地接受变化。

第三个也是最后一个现实是，任何时间表都只是时间表。我们进入开发项目，无法确切地说出最终产品将是什么。因此，无法对完成时间进行早期预测，因此所有最终版本都是临时的。

敏捷发展为营救


出于对这些事实的认识，出现了敏捷宣言。定期发布工作软件是这种认可的一部分：一个真正灵活的项目会定期发布工作但非最终的实现。与最终用户的密切关系可确保在对需求的更改变得显而易见时，可以将其集成到工作计划中。

理想情况下，在一个非常早期的灵活项目中，已经有可行的实施方案，并且系统的显着进步逐渐导致发布令人满意的产品。记住目标射击的比喻：随着我们的进步，我们越来越接近苹果本身。因此，我们可以确定，经过一段时间后，产品将至少接近目标。


More articles:


All Articles