构建软件最难的部分不是编码,而是需求管理

2024-03-31   出处: stackoverflow  作/译者:Jared Toporek/Sally

为什么用人工智能取代程序员不是那么容易。

随着所有关于人工智能发展有多么惊人的文章,有很多人担心,作为软件开发人员,我们可能很快就会失业,被人工智能取代。他们想象所有的业务高管和产品研究人员将绕过大多数或所有的软件开发人员,直接要求AI构建他们认为他们想要或需要的东西。作为一个花了15年时间根据这些人创造的规格开发软件的人,我发现很难认真对待所有的担忧。

编写代码可能是一项挑战,但我从来没有花过超过两周的时间来找出代码中的问题。一旦掌握了语法、逻辑和技术,在大多数情况下,这是一个非常简单的过程。真正的问题通常集中在软件应该做什么。开发软件最困难的部分不是编写代码,而是编写需求,而这些需求仍然是由人类定义的。

本文将讨论需求和软件之间的关系,以及AI需要什么才能产生好的结果。

这不是bug,这是功能…不,等等,这是bug

在我软件生涯的早期,为了帮助提高团队的开发速度,我被安排在一个项目的中间阶段。该软件的主要目的是在电子商务网站上配置自定义产品。

我的任务是生成动态条款和条件。根据所购买产品的类型,以及根据法律要求,客户位于美国的哪个州,有条件的措辞。

在某种程度上,我认为我发现了一个潜在的缺陷。用户可以选择一种产品类型,这将生成适当的条款和条件,但在工作流的进一步过程中,它将允许用户选择不同的产品类型和预定义的条款和条件。它将违反具有客户签名的业务需求中明确同意的功能之一。

我天真地问客户:“我应该删除允许用户覆盖正确条款和条件的输入吗?”从那以后,我得到的回应一直烙在我的脑海里。他的原话是完全自信地说出来的:“那永远不会发生”。

这是一位在公司工作多年的高管,了解公司的业务流程,被选中负责软件开发是有原因的。重写默认条款和条件的能力是同一个人明确要求的。我到底有什么资格去质疑任何人,更不用说一家付钱给我们开发这个产品的公司的高管了?我耸耸肩,很快就忘了这件事。

几个月后,就在软件上线前几周,客户端的一个测试人员发现了一个缺陷,并把它分配给了我。当我看到缺陷的细节时,我笑出声来。

我担心会推翻违约条款,我被告知永远不会发生的事?猜猜发生了什么?猜猜谁为此受到了指责,谁被要求去修复它?

修复相对容易,而且错误的后果也很低,但这种经历一直是我构建软件的职业生涯中反复出现的主题。我已经和很多软件工程师同事谈过了,我知道我不是一个人。问题变得更大、更难修复、成本更高,但问题的根源通常是相同的:需求不明确、不一致或错误。

现在的AI:国际象棋vs自动驾驶汽车

人工智能的概念已经存在很长一段时间了,尽管这些引人注目的进展引起了媒体和国会的关注。人工智能在某些领域已经非常成功。首先想到的是国际象棋。

早在20世纪80年代,人工智能就被应用于国际象棋。人们普遍认为,人工智能已经超越了人类在国际象棋中获胜的能力。这也不足为奇,因为国际象棋的参数是有限的(但游戏还没有解决)。

国际象棋总是从64个方格的32个棋子开始,有很好的文件记录官方一致的规则,最重要的是有一个明确定义的目标。在每个回合中,可能的移动次数是有限的。下棋只是遵循规则引擎。AI系统可以计算每一步棋的影响,以选择最有可能的结果来夺取对手的棋子或获得位置,并最终获胜。

人工智能一直非常活跃的另一个领域是自动驾驶汽车。很长一段时间以来,制造商一直在承诺自动驾驶汽车。有些人有自动驾驶的能力,但有一些警告。在许多情况下,汽车需要主动监督;司机可能需要把手放在方向盘上,自动驾驶功能不是自动驾驶的。

像下棋的AI程序一样,自动驾驶汽车在很大程度上使用基于规则的引擎来做决定。与国际象棋程序不同的是,如何驾驭每种可能情况的规则并没有明确定义。在一个特定的行程中,司机会做出成千上万的小判断,以避免行人,绕过双停的汽车,以及在繁忙的十字路口转弯。做出正确的判断意味着安全抵达购物中心还是抵达医院。

在技术领域,可用性的标准是5个甚至6个9——一个网站或服务在99.999%(或99.9999%)的情况下可用。实现前99%的成本并没有那么高。这意味着你的网站或服务每年可能宕机超过三天(87.6小时)。然而,每增加一个9,到达该值的成本就会呈指数级增长。当你达到99.9999%时,你一年只能允许31.5秒的停机时间。它需要更多的计划和努力,当然也更昂贵。获得前99%可能不容易,但从比例上看,它比最后一小部分要容易得多,也便宜得多。

365 X 24 X 60分钟=每年525600分钟

99%可用性->宕机5256分钟,87.6小时99.9%的可用性->下降526分钟,8.76小时99.99% ->52分钟,小于1小时99.999% ->5.2分钟99.9999% ->0.52分钟,大约31.5秒

无论人工智能离足够好有多近,总会有事故和死亡的风险。这些风险和后果每天都发生在开车的人身上。我不知道政府能接受的事故和死亡比率是多少,但你必须认为它至少需要像人类一样好。

之所以很难达到可接受的安全水平,是因为驾驶汽车需要比下棋多得多的变量,而这些变量并不是有限的。前95%或99%可能是可预测的,也很容易解释。然而,在前99%之后有很多边界情况,每个边界情况可能有一些相同的特征,但每个都是独特的;道路上的其他车辆由其他人驾驶,道路封闭,施工,事故,天气事件,有多少次你在道路已经铺好但道路分界线的油漆还没有涂上之后开车。让你的AI模型能够解释和识别这些异常和边缘情况是非常困难的,更重要的是如何在不发生事故的情况下做出适当的反应。每个边缘情况可能有一些相同的特征,但很少是相同的,这使得人工智能更难确定适当的响应方式。

人工智能不能创造软件,只能创造代码

与下国际象棋相比,创建和维护软件与驾驶有更多的共同点。其中涉及的变量要多得多,而且规则是建立在判断基础上的。在开发软件时,你可能会有一个期望的结果,但它不太可能像国际象棋那样单一。软件很少完成;添加功能和修复bug;这是一个持续的练习。象棋游戏不像软件,一旦赢了或输了,就结束了。

在软件开发中,我们确实有一个工具可以让我们的软件设计更接近严格控制的国际象棋规则引擎:技术规范。在最好的情况下,规范会遍历预期的用户行为和程序流程。用户购买电子三明治的过程如下:单击此按钮,创建此数据结构,运行此服务。然而,我们很少得到这样的结果。太多时候,我们收到的愿望清单包括功能规格、草稿线框图和不明确的需求文档,并被告知要做出最好的判断。

更糟糕的是,需求变更或者被忽略。最近,我被要求帮助一个团队构建一些东西,可以帮助人们获得与COVID 19相关的健康问题的信息。该应用程序将用于全球没有可靠WIFI的地区。团队希望我帮助构建一个可以通过sms手机短信进行调查的应用程序。一开始我很兴奋能参与其中。

当我开始听到团队描述他们想要什么时,我意识到这将是一个问题。对于零售公司来说,让你在1-10的范围内再去他们商店购物的可能性是一回事。询问关于你可能感染COVID的症状的多步骤调查和多项选择问题是非常不同的。我从来没有说不,但我确实提出了这个过程中所有可能的失败点,并希望团队清楚地定义我们将如何处理所有问题的答案。是用逗号分隔的数字映射到每个答案上吗?如果提交的答案没有映射到给定的任何选项,会发生什么?

在所有这些问题之后,团队得出了相同的结论。我们决定最好还是不要做这件事。信不信由你,我得说这实际上是一个成功的结果。在提交无效用户数据时,如果不明确解决所有潜在错误,则会更加浪费。

使用人工智能创建软件,让相同的利益相关者直接与计算机对话,创建基于短信的调查,这背后的想法是吗?AI是否会提出关于如何处理通过SMS收集调查数据的所有可能问题的探索性问题?它会考虑到我们人类在这个过程中可能做错的所有事情以及如何处理这些错误吗?

为了从人工智能中产生一个功能软件,你需要知道你想要什么,并能够清晰准确地定义它。有时候,当我为自己编写软件时,直到我真正开始编写代码,我才意识到其中的困难和挑战。

在过去的十年中,软件行业已经从瀑布式方法过渡到敏捷方法。瀑布式在编写代码之前就明确地定义了你想要什么,而敏捷则提供了足够的灵活性,让你可以在编写代码的过程中不断调整。

很多使用瀑布式的软件项目之所以失败,是因为项目干系人认为他们知道自己想要什么,并且认为他们可以准确地描述和记录它,但是当最终产品交付时,他们却非常失望。敏捷软件开发被认为是这一过程的解毒剂。

人工智能可能最适合重写我们已经拥有的软件,但需要重写它以使用更新的硬件或更现代的编程语言。仍然有很多机构使用COBOL编写软件,但学习如何使用COBOL的程序员较少。如果你确切地知道你想要什么,也许你可以让人工智能比人类程序员团队更快、更便宜地生产软件。我相信人工智能可以创造出已经比人类程序员更快的软件,但那是因为有人在开发过程中弄清楚了软件应该做什么。

AI可能会使用瀑布过程(也被亲切地称为“死亡行军”)构建软件。你知道谁最不擅长瀑布吗?我们是人类。这并不是因为签署的文档会被移交给一个程序员团队,让他们编写代码。这是之前的一切。人工智能可以做一些非凡的事情,但它不能读心术或告诉你应该想要什么。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
172° /1720 人阅读/0 条评论 发表评论

登录 后发表评论