软件工程3.0:大模型驱动的研发新范式

978-7-115-66639-0
作者: 朱少民王千祥
译者:
编辑: 佘洁

图书目录:

详情

本书系统地探讨了软件工程从 1.0 到 3.0 的演进历程,深入剖析了软件工程 3.0 的新范式及其核心特征。书中详细介绍了软件工程 3.0 的实施策略和路线图,以及提示工程、RAG、智能体、数据治理、模型工程和安全治理等核心能力的建设。通过对需求分析、架构设计、UI 生成、结对编程、测试智能化和运维监控等关键环节的实践案例分析,全面重塑了软件开发生命周期。此外,书中还对软件工程的未来进行了展望,探讨了多模态技术和 AGI(通用人工智能)等对软件研发的深远影响。 本书适合软件研发管理人员(包括研发总经理、技术经理、项目经理、测试经理等)、 软件工程师、软件测试工程师,以及对软件工程智能化转型感兴趣的读者阅读参考。

图书摘要

版权信息

书名:软件工程3.0:大模型驱动的研发新范式

ISBN:978-7-115-66639-0

本书由人民邮电出版社发行数字版。版权所有,侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用,未经授权,不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟,与我们共同保护知识产权。

如果购买者有侵权行为,我们可能对该用户实施包括但不限于关闭该帐号等维权措施,并可能追究法律责任。

版  权

著    朱少民 王千祥

责任编辑 佘 洁

人民邮电出版社出版发行  北京市丰台区成寿寺路11号

邮编 100164  电子邮件 315@ptpress.com.cn

网址 http://www.ptpress.com.cn

读者服务热线:(010)81055410

反盗版热线:(010)81055315

内容提要

本书系统地探讨了软件工程从1.0到3.0的演进历程,深入剖析了软件工程3.0的新范式及其核心特征。书中详细介绍了软件工程3.0的实施策略和路线图,以及提示工程、RAG、智能体、数据治理、模型工程和安全治理等核心能力的建设。通过对需求分析、架构设计、UI生成、结对编程、测试智能化和运维监控等关键环节的实践案例分析,全面重塑了软件开发生命周期。此外,书中还对软件工程的未来进行了展望,探讨了多模态技术和AGI(通用人工智能)等对软件研发的深远影响。

本书适合软件研发管理人员(包括研发总经理、技术经理、项目经理、测试经理等)、软件工程师、软件测试工程师,以及对软件工程智能化转型感兴趣的读者阅读参考。

推荐序1

在人类科技发展的长河中,软件工程作为连接创造力与数字世界的桥梁,始终站在时代变革的前沿。从最初的瀑布模型到敏捷开发,再到如今大模型驱动的智能化范式,每一次跃迁不仅是技术视角的革新,更是管理理念的迭代,是从“确定性控制”迈向“不确定性适应”的伟大跨越。本书系统阐述了这一划时代变革的理论基础与实践路径,恰逢其时。

作为长期从事管理工程与计算机科学研究的学者,我深刻认识到大模型带来的变革远超技术层面。以多学科视角审视,我们可以清晰地看到:生物学的神经元与神经网络启发了人工神经网络的设计,认知科学的注意力机制成为Transformer结构的理论基础,复杂性科学则为理解大模型的涌现能力提供了分析工具。正是这种深层次的学科交叉,推动了AIGC从实验室走向应用,并正在重塑软件工程的基本范式。

大型软件系统的研发面临的核心挑战不仅仅是技术问题,更是管理与协同问题。过去,我们观察到一些问题,例如研发技术流程和管理流程未深度融合;协同内容未实现要素化、标准化;跨组织协同困难、可追溯性差;上下游环节参与度不足、质量管理不到位等。而大模型技术为解决这些挑战提供了新契机。依托系统工程思维、管理科学理论与人工智能技术,软件工程3.0正在构建全新的协同开发范式。从需求分析到系统设计,从编码实现到测试验证,大模型不仅作为工具参与,更作为智能体重塑了软件研发的整个管理流程。这种新型协同模式将使软件开发从“线性串行”走向“网络协同”,从“人工控制”走向“人机共治”。

在这一过程中,我们必须着力解决跨时空多粒度资源配置与网络化调控、跨生命周期价值链的迭代优化、全生命周期数据融合与知识体系化建模等关键问题。这些挑战不仅需要技术创新,更需要管理科学的理论支撑。正如我常说的,“科技使世界越来越强大,管理使世界越来越精彩”,未来软件工程的突破点将在技术与管理的交叉地带,在人工智能与管理科学的融合中诞生。这种新型软件生产关系将深刻改变软件工程师的角色定位——从代码编写者转变为价值引导者,从问题解决者升格为系统治理者。

大模型引发的变革也带来了管理上的全新挑战。传统软件项目管理基于明确的需求规格说明和确定性算法,而大模型驱动的软件开发则面对概率性输出、涌现能力和黑盒决策。这要求我们重新思考软件项目的质量评估标准、风险管控机制和责任边界划分。特别是在数据偏向、算法偏见等方面,我们需要从公平性、公正性等维度进行全面评估,确保技术发展与社会价值同频共振。

展望未来,大模型将成为科技创新、产业变革与社会治理的核心支撑。在科学研究领域,它能助力生物结构预测、新材料设计、数学定理证明等突破;在产业应用中,从无人驾驶到智能医疗,大模型正在创造前所未有的价值;在社会治理方面,它为包容性服务、智能决策提供了新可能。正如我在研究AIGC时所发现的,当前对其应用尚处于“点状”阶段,未来必将从线到面,最终迈向全方位深度融合。

《软件工程3.0》不仅系统梳理了软件研发变革的脉络,更提供了面向未来的软件工程方法论与实践指南。在这个智能与创新交织的新时代,我们既要保持开放心态,拥抱变革;也要保持理性思考,防范风险。期待本书能为每一位软件行业从业者提供前进方向,共同探索人机协同的无限可能,为数字文明的可持续发展贡献智慧与力量。

杨善林  

中国工程院院士

推荐序2

若将人类文明进程比作一幅波澜壮阔的画卷,科技革命定是其中最亮眼的一笔。从软件工程1.0时代的结构化开发,到2.0时代的敏捷迭代,直至今日大模型驱动的人机协同范式,我们迎来了一个崭新的时代——软件工程3.0时代。这不仅意味着技术的跃迁,更是观念与方法的深刻变革。

纵观软件工程的发展轨迹,本质上是人类不断探索、应对软件复杂度的过程。从结构化编程到面向对象,从瀑布模型到敏捷迭代开发,每一次范式变革都在试图破解更高层次的复杂性。如今,大模型技术为我们带来全新的复杂度管理手段——不在于消除复杂度,而在于通过人机协同更好地驾驭复杂度。

我长期关注人工智能(AI)与软件工程的交叉融合,尤其是在“三脑协同”理论框架下,通过电脑智能、数脑智能与人脑智能的有机结合,从多维度推动AI理论创新与产业应用落地。大模型技术的兴起,促进了三种智能形态的深度融合,这种融合为软件工程注入强劲动力——为软件研发提供了前所未有的智能共生体。正是在这个大背景下,软件工程3.0应运而生,契合了“三脑协同”的核心理念:人脑擅长价值判断与创新决策,电脑确保逻辑严谨与确定性,数脑保障大数据的高效处理与知识融合。

我在2024年的外滩大会上提出“大模型产业闭环的三大核心环节”——数据与知识的深度耦合、算法与算力的协同进化、场景与落地的价值闭环。在研读《软件工程3.0》的过程中,我欣喜地发现,本书正是从这几点着手,构建了“数据治理—模型工程—智能体协同”的系统体系,阐述了如何将大模型切实转化为软件生产力。它也让我们看到智能化软件工程未来发展的关键,这不仅是技术层面的突破,也是新型软件生产关系的构建和研发管理模式的迭代与再造。

《软件工程3.0》精准捕捉了这一历史性变革。它不是简单地介绍如何使用大模型辅助编程,而是系统性地重新思考软件构建的本质——从程序到模型的软件形态迁移,到人机协同新范式,再到质量保障的全面革新。尤为重要的是,作者明确指出,软件工程3.0并非对传统范式的割裂式颠覆,而是在50余年软件工程积累之上的升华,而且未来软件工程的发展必然是多种范式共存、融合协作的局面。

在软件工程3.0时代,人机协同将成为常态,如人机结对编程、人机结对测试等构成了研发新模式。然而,正如我之前提出的“三脑理论”所强调的那样,人类的经验判断与价值观取向仍然不可替代,关键决策依然把握在人类手中。软件工程3.0的本质不是技术取代人,而是人机协同创造更大价值。为此,我们需要培养新型软件工程人才,他们既了解传统软件工程方法论,又精通AI思维模式,能够在“人机共生”的新型关系中掌握主导权。

当前,具身智能的迅猛发展正在模糊物理世界与信息世界的边界,这也给软件工程带来全新挑战:如何构建支撑“物理—信息—社会”三元融合的软件系统?如何在保障软件系统可靠性的同时最大化释放AI创造力?如何在效率提升与伦理安全之间找到平衡?本书对这些问题进行了具有启发性的思考,值得我们深入研读。

《软件工程3.0》不仅是一本技术指南,更是一场关于人类智能与技术进程关系的深刻对话,体现了跨学科、多元化融合创新的精神。我期待读者能从本书中获得启发,在实践中思考,在思考中实践。我相信,它不仅能引导软件从业者思考并持续优化软件工程实践,也能激发我们对AI时代如何保持人与机器协作平衡的深刻洞察和讨论。

科技发展日新月异,但以十年为尺度审视技术革命的视野至关重要。正如书中所言,大模型技术的真正威力尚未完全释放,但它改变软件创造方式的趋势已不可逆转。令人欣慰的是,越来越多的研究者和工程师正积极投身这一伟大变革。我也相信,这本书能成为引领软件行业从业者迈向智能时代的一盏明灯。

蒋昌俊  

中国工程院院士

前  言

回顾软件行业的发展历程,我们可以发现,每一次范式的转变都伴随着对软件内涵与外延的再认识,这些转变不断推动着整个行业向前发展。

在软件工程1.0时代,瀑布模型和V模型是主流开发范式。通过结构化分解,开发者成功降低了软件系统的复杂性;同时,面向对象的方法有效降低了系统的耦合度,提升了系统的可维护性和可扩展性。

进入软件工程2.0时代,敏捷开发和DevOps方法逐渐兴起,并伴随着软件从“产品”形态向“软件即服务(SaaS)”转型。在这一时期,持续集成与持续交付(CI/CD)成为关键,显著提高了开发效率,使团队能够更快速地响应日益加速的市场变化。

如今,大语言模型(Large Language Model,LLM)及其代表的机器学习技术,凭借强大的生成和理解能力以及自适应特性,正在深刻改变我们对“软件是什么”“软件能做什么”以及“我们如何开发软件”的基本认知。我们正迈入“程序 + 模型”的时代——软件工程3.0时代,开创“智能软件工程”的新纪元。

值得强调的是,软件工程 3.0 绝非割裂式革命,而是基于软件工程五十余年的深厚积累而实现的进化与升华。如同软件版本升级是在原有功能基础上增强或新增功能,软件工程 3.0 亦是继承了软件工程 1.0 与 2.0 的方法、技术及实践,在已有的规范化、服务化、自动化、CI/CD、平台工程等基础上迈出的关键一步。在如今多元共存的新格局中,传统软件工程的 V 模型仍在航空航天等高可靠性领域发挥重要作用,敏捷研发范式继续在快速迭代的业务场景中创造价值,而智能软件工程则在其适用领域释放出前所未有的生产力。总而言之,软件工程从 1.0 到 2.0,再迈向 3.0,是一个持续成长与演进的过程,绝非简单的替代过程。

软件形态的迁移:从“程序”到“模型”

回顾过去,软件常常被视为一套确定性逻辑:通过编写指令序列、设计算法与数据结构,处理确定性输入并输出确定性结果。这种形态在软件工程1.0与2.0时代都行之有效。但随着大模型[1]的崛起,软件开始包含一个全新的核心要素——“模型”。对未来软件而言,它不再只是一段库函数或辅助脚本,而是影响系统功能与行为的“关键计算实体”。

[1] 大模型是目前常见说法,通常是指大语言模型(LLM),也可以是多模态大模型(MLLM)。

传统程序:以算法和数据结构为基石,适合处理确定性问题,且是从问题出发,分析问题、解决问题。

大模型:以海量参数、高维向量及关联关系为基础,善于应对不确定性、大规模输入,常输出概率性结果。大模型(包括之前的深度学习)不是从问题出发,而是直接在解空间中搜索相对最优解。

这种新型软件也被称为软件2.0,它由程序与模型共同构成,而且相互促进:一方面,模型需要程序来训练、部署和运维;另一方面,模型可反哺程序,甚至自动生成新的程序,为人机交互和高级功能提供支持。这种形态的出现意味着软件已从“延伸人类计算能力”阶段,迈向“延伸人类思维能力”的更高层次。

从影响软件工程方法的视角来看,最初的软件形态是“产品”,经历了20世纪末出现的SaaS(Software as a Service,软件即服务),再到如今的SaaM(Software as a Model,软件即模型),软件形态发生了显著变化。相应地,软件研发范式也随之发生了变化。例如,在SaaS时代,我们可以实现快速部署,CI/CD才更具价值;而服务的持续性使得运维显得特别重要,从而迎来了DevOps。

人类思维的模拟与边界

大模型常被认为是“对人类思维过程的模拟”。事实上,计算机自诞生之初就担任了人类信息处理和存储的角色,但它更像是一个“确定性大脑”。相比之下,大模型则在不确定场景和预测性任务中表现出跨越式提升,如自然语言理解、机器翻译、图像识别、推理生成等。这种模拟优势源于概率分布与多层神经网络的强大表达和推理能力,并且大模型开始具备一定的“反思”能力。然而,大模型与人类思维之间仍存在明显边界——大模型并不具备真正的情感和意识,因此仍然需要我们在宏观规划、价值判断及伦理监管等方面进行掌控。

优势:能够处理复杂场景和不确定性;具备快速学习能力,可自动生成内容。

局限:无法真正自主决定目标与价值取向,容易出现“幻觉”或做出错误推断。

人机交互与研发模式

在软件工程3.0阶段,如何让人和大模型发挥各自所长,成为研发模式迭代的核心问题。敏捷与 DevOps 让软件工程2.0取得了显著成效,但研发过程依然是以人为主导、工具为辅助。本质上,团队需要进行需求分析、架构设计、代码编写、测试用例设计等一系列工作,最终快速交付到生产环境。然而,当大模型的生成和自治能力融入各环节时,我们将会遇到以下关键问题。

人机如何高效交互和协同完成功能开发与维护?哪些部分由大模型主导,哪些部分仍需人的审查或决策?

如何确保软件的可解释性与可验证性?当大模型的不确定输出与传统线性思维发生碰撞时,如何规避风险?

在更高层面,软件如何在运行中实现“自演化”?这涉及自适应策略、自验证,以及基于数据动态优化等。

在未来的软件工程实践中,这些问题不仅会发生在编程环节,还会体现在需求收集、系统设计、测试脚本生成与缺陷修复、大规模日志分析与故障定位等诸多方面。我们看到多智能体(AI Agent)彼此配合,进入“人机协同研发”状态:有的智能体负责检索资料、理解业务意图并生成初步的需求用例,有的智能体负责设计与编程,而其他智能体则负责自动评审、验证或测试,甚至缺陷修复。通过定制化流程,人的创意和经验将与大模型的高效计算和自动生成相结合,从而实现人机协同的高效运行。

在软件工程 3.0 的新型研发范式里,人机协同、人机交互智能成为常态。在人机协同过程中,人始终是主导因素。无论技术多么先进,最终都要服务于人类,为人类创造价值,关键决策也由人类做出。大模型虽能拓展开发者的认知边界、参与协作与决策,但领导力、创造力和价值判断仍是人类的核心优势。

软件测试和质量保障更具挑战性

随着大模型的广泛应用,软件质量保障正面临前所未有的挑战。传统软件的测试方法难以完全适配AI应用软件,因为AI系统的动态性、不可预测性及复杂性使得质量保障变得更加复杂,具体如下。

不可预测性与复杂性:AI应用软件的行为高度依赖于训练数据和模型结构,其输出结果通常具有动态性和不可预测性。这给测试用例设计和自动化测试带来很大挑战。此外,AI大模型的不可解释性进一步增加了问题的复杂性,例如,开发者和测试人员难以准确定位问题或复现Bug。

安全性与鲁棒性:AI大模型易受到对抗样本攻击,这种攻击通过微小的输入扰动可能导致模型输出错误内容。如何确保AI大模型在面对噪声、缺失数据或异常输入时依然能够稳定运行,是一个极具挑战性的问题。

数据数量和质量的要求:AI应用软件的性能依赖于评测指标和评测数据集,这通常对数据集的规模和多样性、场景覆盖广度、一致性等都有很高要求。同时,如何确定有效且充分的评测指标、如何避免评测数据泄露导致过拟合等问题,都会给测试团队带来新的挑战。

公平性与伦理问题:AI系统可能存在数据偏向、算法偏见或人为主观因素导致的不公平性。这些问题不仅影响系统的可靠性,还可能引发伦理争议。因此,测试需要从公平性、公正性等维度进行全面评估。

迈向软件工程3.0的关键思考

有学者形容大模型“把软件带进了量子时代”,这一说法暗示了模型计算与传统可编程逻辑之间的范式冲突。冯诺依曼曾将计算机体系结构与神经网络进行类比,认为两者在理论上具有等价性。事实上,某些高复杂度问题虽然可以通过确定性图灵机求解,但往往需要极高的计算量,而神经网络模型却能够在实践中为这些问题提供可行的近似解。

大模型并非凌驾于程序之上。大模型离不开程序的运行与训练,而程序也能借助大模型突破自身限制,解决过去难以应对的场景。因此,二者相辅相成、相互交融,正是软件工程3.0的内在逻辑:这既是对软件编程范式的扩展,也是对算法与数据融合的深化。

人机协同研发绝非简单的工具应用,更不是一蹴而就的过程。它要求组织与个人在思想和实践上都付出长期的努力。

重新定义研发流程:将大模型视作核心资产,并在需求、设计、测试、运维等全部环节配置相应的“模型协同”机制。

建立新型评估体系:既能度量传统的软件质量,也能度量基于大模型的智能应用的输出效果与可信度。

注重团队角色培养:算法工程师、数据科学家、模型训练专家等将成为未来研发团队中不可或缺的角色。

强化软件伦理与合规:对大模型可能产生的风险做好预案,在技术与伦理层面审慎行事。

审视大模型技术发展,我们应超越当下,以十年为期进行战略思考。正如互联网诞生之初,鲜有人预见其对人类社会的彻底重塑;敏捷宣言发布后,也历经漫长十年才被主流接受。如今,评判大模型对软件工程的影响,也不应受制于当前技术局限。凯文·凯利在《5000天后的世界》中曾展望,技术的长期影响常被低估,而短期影响往往被高估。大模型技术的真正威力尚未完全展现,但它改变软件创造方式的趋势已不可阻挡。待十年后回望,今天的软件工程 3.0 或已成为软件开发史上的重要分水岭。

所以说,软件工程3.0正为我们展开新的可能性:让传统程序与大模型携手走向更高级别的自适应与智能决策,用不确定的思维方式解决那些原本难解的确定性或近似性难题。诚然,挑战仍在,但变革的号角已然吹响。希望每一位读者都能从本书中获得启发,并结合自身业务与团队特色,迅速踏上这一进化旅程。让我们携手迎接这场未来软件的变革,为即将到来的“感知—学习—决策”及“人—机—物”深度融合的智能时代做出新的贡献。

致  谢

本书的出版,得益于学术界和工业界同仁的肯定与支持。在此,特别感谢中国信息通信研究院、应用现代化产业联盟、华为云计算技术有限公司、腾讯科技(深圳)有限公司、中兴通讯股份有限公司、招商银行等组织或公司的认可。它们在出版或发布的相关材料,如《AI4SE⾏业观察》《应用现代化实践指南》《AI加持下的新时代软件工程》《AI驱动下的测试设计智能化》《软件工程3.0点燃招行数智交付新引擎》等中引用了“软件工程3.0”的定义。

在此特别感谢中国工程院院士杨善林老师和蒋昌俊老师从百忙之中抽出宝贵时间为本书写序,并对本书给予肯定。同时,也非常感谢为本书的修改提出宝贵意见并致推荐辞的几位老师:北京大学金芝教授、美国Drexel大学蔡元芳教授、阿里巴巴通义实验室NLP负责人黄非博士、华为公司谈宗玮等。

本书在写作过程中,参考了《智能化软件开发落地实践指南》的相关内容,感谢本指南的众多编写者:黄毅刚、秦思思、闫东伟、齐可心、杨志伟、周林峰、贺美迅、翟传璞、汪维敏、毛哲文、高超、李钟麒、申博、程啸、范娜、黄慧娴、董剑、潘冬雪、郝毅、马宇驰、张琦、周建祎、石敏、付安、乔蔚云、罗斌、杨宏宇、钟诚。

本书能以科学准确的文字、亮眼的封面和精心设计的版面与读者见面,离不开人民邮电出版社几位编辑的努力,他们是信息技术分社社长陈冀康、责任编辑佘洁和内文版式设计郭丽娟,以及特邀封面设计师曹妍。

最后,感谢家人的大力支持,让我们能够全心投入本书的写作。

资源与支持

资源获取

本书提供如下资源:

本书思维导图和随书赠送的电子资源;

异步社区7天VIP会员。

要获得以上资源,扫描右侧二维码,根据指引领取。

提交错误信息

作者和编辑尽最大努力来确保书中内容的准确性,但难免会存在疏漏。欢迎您将发现的问题反馈给我们,帮助我们提升图书的质量。

当您发现错误时,请登录异步社区(https://www.epubit.com/),按书名搜索,进入本书页面,单击“发表勘误”,输入错误信息,单击“提交勘误”按钮即可(见右图)。本书的作者和编辑会对您提交的错误进行审核,确认并接受后,您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。

与我们联系

我们的联系邮箱是contact@epubit.com.cn。

如果您对本书有任何疑问或建议,请您发邮件给我们,并请在邮件标题中注明本书书名,以便我们更高效地做出反馈。

如果您有兴趣出版图书、录制教学视频,或者参与图书翻译、技术审校等工作,可以发邮件给我们。

如果您所在的学校、培训机构或企业,想批量购买本书或异步社区出版的其他图书,也可以发邮件给我们。

如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为,包括对图书全部或部分内容的非授权传播,请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护,也是我们持续为您提供有价值的内容的动力之源。

关于异步社区和异步图书

异步社区”(www.epubit.com)是由人民邮电出版社创办的IT专业图书社区,于2015年8月上线运营,致力于优质内容的出版和分享,为读者提供高品质的学习内容,为作译者提供专业的出版服务,实现作者与读者在线交流互动,以及传统出版与数字出版的融合发展。

异步图书”是异步社区策划出版的精品IT图书的品牌,依托于人民邮电出版社在计算机图书领域40余年的发展与积淀。异步图书面向IT行业以及各行业使用IT技术的用户。

第1章 演变之路:软件工程的三个时代

随着OpenAI推出的全新对话式通用人工智能工具——ChatGPT火爆出圈,人工智能再次受到工业界、学术界的广泛关注,并被认为向通用人工智能迈出了坚实的一步,在众多行业和领域有着广泛的应用潜力,甚至会颠覆很多领域和行业。特别是在软件研发领域,它必然会引起软件开发模式和实践的巨大变化。为此,我们经过调研、实验和思考之后,提出了“软件工程3.0”。

用软件版本号的方式,如1.0、2.0、3.0来分别定义第一代、第二代、第三代软件工程,符合软件工程的思维方式,而且简洁明了地体现了软件工程的演进过程。

1.1 1.0时代:传统软件工程

软件工程1.0——第一代软件工程,即我们过去常说的“传统软件工程”。传统软件工程主要是向建筑工程和水利工程等学习,吸收了这些领域百年实践积累下来的方法和实践经验,以及沉淀下来的思想。它的诞生可以追溯到1968年。

在20世纪五六十年代,软件危机的出现促使布鲁克斯(Frederick P. Brooks)在《人月神话》一书中描述了一幅场景:软件开发被比喻为众多史前巨兽在焦油坑中痛苦地挣扎,无法自拔,如图1-1所示,它们越挣扎,焦油纠缠就越紧密。这场软件危机迫使人们寻找产生危机的内在原因,进而寻找解决方案。面对“软件危机”,人们对软件开发的实际情况进行了调查研究,并逐步认识到工程化方法在软件系统研发和维护中的必要性。为了应对软件危机,业界专家齐聚一堂,共同探讨问题的解决途径。1968年,NATO(North Atlantic Treaty Organization,北大西洋公约组织)的计算机科学家在德国召开国际会议,专门讨论软件危机问题。在这次会议上,“软件工程”(Software Engineering)这一术语被正式提出,一门新的工程学科诞生了,并自此不断发展,逐渐走向成熟。软件工程1.0体现了以下特征。

1)结构化方法:采用结构化分析、设计和编程方法,有效降低软件的复杂性和耦合性,使软件具有良好的可维护性。

2)过程控制:秉承“过程决定结果”的理念,一方面通过过程节点进行控制,如通过需求评审后才能开始设计、通过设计评审后才能开始实施(编程)、编程结束再进行测试等,以瀑布模型为典型代表;另一方面,重视流程的定义和过程改进(如CMMI,即能力成熟度模型集成),提高软件开发过程的成熟度,确保软件开发的稳定性(包括进度、质量和成本等方面),从而降低软件项目失败的概率。

3)项目和质量管理:借鉴传统工程的经验,强化项目管理和质量管理,实施全面的计划和严格的变更控制,包括人员角色定义清晰、分工细致、责任明确,从而有效控制项目风险,确保项目顺利进行。

4)文档规范化:强调规范文档的重要性,定义大量文档模板,加强文档评审,提高研发过程的一致性,降低成本,促进知识传递。

图1-1 《人月神话》原书封面

1.2 2.0时代:敏捷软件工程

虽然软件工程1.0极大地缓解了软件危机,提升了软件产品交付的成功率和质量,但它依旧存在一些问题。首先,它没有充分认识软件的柔性和数字化特性,把软件视为传统的工业产品来交付,这导致交付周期较长,不能及时满足业务需求的更新和变化,也不能及时完成价值交付。在竞争日益激烈的商业市场中,这些问题变得更加突出。其次,软件工程1.0的阶段性开发方式往往造成大量人力资源的浪费。再者,软件工程1.0过于关注过程而忽视了人的因素,软件研发人员往往得不到足够的尊重,他们的潜力没有得到充分的释放。

人们开始认识到软件开发是一种需要高度创造性和智力投入的活动,这引导人们不断进行新的思考,在这样的背景下,一系列轻量型开发方法应运而生,包括水晶方法(Crystal Method)、自适应软件开发(ASD)、动态系统开发方法(DSDM)、Scrum、特性驱动开发(FDD)等。2001年,17位软件开发轻量型流派“掌门人”联合签署了敏捷软件开发宣言,如图1-2所示。宣言的发布标志着软件工程进入2.0时代,也就是我们通常所说的现代软件工程,但更准确的称呼应该是敏捷软件工程。

图1-2 敏捷联盟官网的敏捷软件开发宣言截图

这个过程的演化得益于开源软件运动和互联网的深远影响。开源软件运动首先让我们认识到人的重要性,人的因素是最重要的,超越了“软件过程”和“软件管理”;其次,软件架构和数据结构的重要性也日益凸显,它们强调简单和解耦,如采用SOA和微服务架构来解耦,使软件系统更具可扩展性。

没有互联网,软件就无法部署在数据中心为用户提供服务,也就不会有SaaS(Software as a Service,软件即服务)这种新形态的出现。如果软件不是作为一种服务存在,那么持续交付(Continuous Delivery,CD)就没有意义,因为我们无法做到将包装盒形式的软件产品持续交付到客户手中。虽然可以在内部实现持续集成(Continuous Integration,CI),但无法做到CD,CI的价值也会大打折扣。此外,SaaS模式还提高了并发量(或系统容量)、可用性、安全性的要求,促使运维与开发变得同等重要,从而催生了DevOps开发模式。

在市场快速变化和竞争加剧的背景下,客户或用户期望我们能够按时交付高质量的产品,同时希望软件具备灵活性和随需应变的能力,以满足业务的新需求。软件工程2.0借助SaaS这种新形态,实现了从“产品”到“服务”的转变,并通过CI/CD实践来满足这种不断变化的业务需求。

软件工程2.0的特征可以简单概括为以下几点。

1)持续迭代:软件以一种服务存在,通过持续构建、集成、测试和交付,最大限度地减少市场风险,加速价值流动,及时响应业务需求的变化。

2)以人为本:强调个体与团队协作胜于流程和工具,采用史诗般的故事、用户故事、站立会议等方式,使软件研发工作更加有趣和健康,激发软件研发人员的潜力和创造力,从而开发出更优秀的软件产品;同时强调将项目的计划、估算等工作授权给实际从事研发的人员,如不再由管理者下达任务安排,而是由研发人员自主选择适合自己的任务,符合软件研发管理作为知识管理的需求。

3)自我管理的团队:像初创公司一样运营,具有主动性、风险承担能力和自治能力,能够自主设定目标和计划,并持续反思和改进。

4)开发、测试和运维的融合:强调测试与开发的融合、开发与运维的融合,并推崇全栈工程师的概念等。

5)真正以用户为中心:用户和产品经理尽可能参与研发过程,注重用户体验,实现个性化服务。

1.3 3.0时代开启:智能软件工程

在软件工程 2.0 时代,尽管引入了大量的开发、测试和运维工具,自动化水平仍然较低。多数开发与测试工作仍依赖于手工操作,导致软件企业的研发成本居高不下,且在持续集成和持续交付方面也面临重重困难,难以满足用户和市场的需求。

然而,人工智能(AI)技术的蓬勃发展,尤其是如 GPT-4 这类大语言模型(LLM)的相继推出,正在帮助我们缩小这一差距。借助 AI 技术,软件研发的自动化水平得到显著提升,持续构建与持续测试成为可能。2022 年 11 月发布的ChatGPT令人惊艳,进而引发了 2023 年各类大模型的爆发式涌现。我们见证了基于 LLM 生成代码、测试用例等强大能力,甚至无需编写代码,仅通过自然语言对话就能完成应用程序的开发,这在过去是难以想象的。正如前哈佛大学计算机科学教授、谷歌工程主管Matt Welsh在国际计算机学会(ACM)组织的会议中所提出的观点:“ChatGPT 和 GitHub Copilot 预示着编程终结的开始”“这个领域将发生根本性变化”“当程序员开始被淘汰时,只有产品经理和代码评审人员两个角色可以保留”。

GPT-4的进化速度迅猛,从单模态GPT-4快速发展到多模态GPT-4v、GPT-4o,具备了更强大的能力,如分析架构设计和UI设计等。未来更强大的大模型(如推理模型)将能够执行如代码生成、错误检测、软件设计等一系列复杂任务,对软件研发的影响将更为显著。

我们坚信,LLM的兴起标志着软件工程迈入了一个崭新的时代——软件工程3.0时代,亦称为智能软件工程时代。2023年也可以视为软件工程3.0时代的元年,如图1-3所示。

图1-3 软件工程3个时代的划分示意图

1.3.1 软件工程3.0的特征

在软件工程3.0时代,尽管算力、算法、数据等要素受到关注,人依然是决定性因素。一方面,算力的提升和优化、算法的改进或新算法的开发、数据治理、模型训练等都依赖于软件研发人员、数据科学家和算法工程师;另一方面,由于幻觉和能力等限制,大模型还不能完全自主处理复杂的软件工程问题,需要人的参与,更需要人对整个过程进行规划、协调,以及对大模型输出的结果进行检查和审视。

事实上,人类工程师的战略决策能力与价值判断力正日益成为核心能力。软件系统的成败,在更深层次上依赖于人类设计者的决策智慧。软件架构师需要精准把握业务本质,构建出契合技术趋势的顶层架构;研发人员则必须具备与大模型高效对话的能力,借助专业化提示工程以及领域知识引导,将大模型的潜力充分转化为实际生产力。这种人与AI的深度协同,正推动着软件开发范式发生质变,从传统的“工具辅助”阶段迈向全新的“智能增强”阶段。

软件工程3.0建立在软件工程2.0之上,继承了软件工程2.0中以人为本、CI/CD等思想和实践,同时也具有自己的特征,以下简要阐述这些特征,第2章及后续会逐步展开讨论。

1.软件新形态:SaaM

此前,为了实现软件的每个功能,我们需要为特定的功能写特定的代码,才有可能为用户所用。但是,在软件工程3.0时代,软件形态发生了变化。例如,像ChatGPT这样的应用具备如生成代码、生成测试用例、翻译、阅读文章生成摘要、回答问题、生成图片、解释图片等多种功能,而这些功能并非通过编写特定代码实现。我们称这种软件形态为“软件即模型”(Software as a Model,SaaM),这里的“模型”是指机器学习模型、大语言模型或其他通用人工智能(Artificial General Intelligence,AGI)模型。正如前面所说,软件工程3.0建立在软件工程2.0之上,软件工程2.0的软件形态SaaS依旧存在,它可以融合SaaS和SaaM两种形态,形成模型即服务(Model as a Service,MaaS)形态。

2.软件研发新范式

软件研发范式也发生了变化。GPT-4等大模型支持更智能、更高效和协作的开发方法,使软件工程领域发生了革命性变化。软件研发的新范式是模型驱动开发、模型驱动运维,如图1-4所示,即研发人员在开发、测试前,先训练好软件研发大模型(可能包括业务大模型、代码大模型、测试大模型等),并部署这个研发大模型,然后基于这个大模型进行需求分析、设计、编程和测试,即借助大模型来理解需求、自动生成UI、自动生成产品代码、自动生成测试脚本等。具体而言,研发大模型将在生成和评审需求文档、自动生成高质量代码、生成全面的测试用例等一系列工作中产生巨大价值,从而显著提高软件研发的效率和质量。

图1-4 软件工程3.0研发范式示意图

3.人机交互智能是常态

人机自然对话成为可能,我们能够向新一代软件研发平台传达我们希望生成的内容,即人工智能生成内容(Artificial Intelligence Generated Content,AIGC),如软件需求定义文档、需求或用户故事的验收标准、代码、测试用例、测试脚本等,软件研发进入AIGC时代,软件研发过程就是人与计算机之间的自然交互过程。

在这个过程中,研发人员与大模型协同工作,大模型(或基于LLM构建的工具或系统)扮演着助手(Assistant)、副驾驶(Copilot)或合作伙伴的角色,研发人员通过提示词(Prompt)不断引导大模型生成所需的、更准确的内容。例如,在需求分解过程中,研发人员逐步细化需求,生成更细致的需求项。这个过程涉及提示工程,即研发人员根据任务需求提供恰当的提示词,本书后续将详细介绍提示工程。同时,LLM生成的内容须由研发人员进行检查、评审,确保内容的准确性,而研发人员的工作成果也可以利用基于LLM的工具进行审查,从而实现真正的人机协同工作环境。展望未来,人机交互智能有望超越LLM和人类自身的智能,人机结对编程和测试将成为新常态,如图1-5所示。

图1-5 人机协同开发软件的场景(图片由AI生成)

4.数据更具价值

业务数据和研发过程数据的重要性日益凸显。过去很多实验和研究表明,数据质量对模型输出结果的影响大于模型规模。例如,一个7B的代码大模型可能比一个70B的通用大模型生成的代码质量更好。因此,我们需要投入更多的精力来构建、采集或维护研发过程中的数据,它们将成为LLM训练或微调的基础语料。

5.模型更具价值

能够产生代码的模型比程序代码本身更具价值。在智能软件开发中,大模型能够自动生成规范代码,并能解释、评审和优化代码,形成一个闭环。这样的大模型不仅能极大地提升开发效率,而且能够减少人为编写的错误,提高代码的质量和可靠性。随着大模型能力的增强,它能够理解和整合大量上下文信息,生成更符合整体架构和设计模式的代码。有了这样强大的大模型,大部分代码都可以通过大模型生成。

6.提出好问题更具价值

提出好问题比解决问题本身更具有深远价值。在大模型作为汇聚人类知识的智慧库的背景下,提出好问题变得尤为宝贵,因为好的问题可以转化为高效的提示词,激发大模型产出更卓越的成果。好问题不仅能挖掘和利用大模型的涌现能力,还能引导其生成更为轻便、灵活、经济的解决方案。此外,精心设计的问题有助于减少开发过程中的迭代次数,避免资源浪费,并帮助开发者深入理解大模型的潜力与边界。

软件工程3.0宣言

软件工程3.0时代虽然刚刚起步,其发展和成熟需要未来数年乃至数十年的探索与实践,持续地丰富和完善,然而基于过去两年的实践、观察和思考,我们认为软件工程3.0时代将秉承以下价值观:

             人机交互智能 胜于 研发人员个体的能力

        业务数据和研发过程数据 胜于 流程和工具

           可产生代码的模型 胜于 程序代码本身

              提出好问题 胜于 解决问题

我们承认右项仍然具有价值,但左项将更为关键。

我们同样相信,面对安全、法律、伦理等方面的挑战,我们有能力应对,软件工程的未来是值得特别期待的。

1.3.2 软件工程跨时代的比较

在软件工程 3.0 时代,新一代软件研发平台展现出了卓越的能力,它能够理解需求、设计和代码等,推动软件研发从信息化时代迈入真正的数字化时代,这标志着一个具有深远意义的进步。此时,软件研发人员的工作重点不只是提示工程(Prompt Engineering)以及为大模型和大数据平台提供支持,如模型创建、训练、调优、使用等,同时他们的工作方式也发生了重大转变,对研发人员的要求更高,更注重对业务的深刻理解、系统性和逻辑思维能力。

回顾软件工程2.0时代,虽然当时已经开始面向CI/CD(持续集成/持续交付),但在实际执行过程中仍遭遇不少挑战。而随着软件工程3.0时代的到来,得益于设计、代码、测试脚本等的自动生成,真正的持续交付成为可能,这使得我们能够迅速响应客户需求,及时交付客户所需的功能特性。

为了更全面地理解软件工程1.0、2.0和3.0之间的差异,进行一个详尽的对比是非常必要的,如表1-1所示。

表1-1 三代软件工程的比较

比较项

软件工程1.0

软件工程2.0

软件工程3.0

标志性事件

1968年10月在德国Garmisch举行的软件工程大会

2001年2月签署、发布的《敏捷软件开发宣言》

2023年3月OpenAI发布大语言模型GPT-4

基本
理念

过程决定结果,如CMM,其思想来源于传统建筑工程等

软件研发是一项智力劳动,以人为本、尽早持续交付价值

基于LLM底座,快速生成所需代码和其他所需内容

软件
形态

普通的工业产品

软件即服务(SaaS,包括PaaS、IaaS)为主

软件即模型(SaaM),并提出“模型即服务”(MaaS)

运行
环境

单机(PC、主机)

网络、云

万物互联IoT、人机融合

支撑
内容

纸质文档

信息化

数字化

主要
方法

结构化分析、设计和编程

面向对象的方法

面向对象的方法

SOA、微服务架构(一切皆服务)

模型驱动、人机交互智能

流程

以瀑布模型、V模型为代表

阶段性明确(需求分析、设计、编程、验证、维护)

敏捷(如Scrum)/DevOps(规划、编程、构建、测试、发布、部署、运维、监控)

提倡CI/CT/CD,但还做不到

模型驱动研发和运维(规划、创建、验证、打包、发布、配置、监控)

真正实现所需即所得,真正做到持续交付服务

工作
中心

以架构设计为中心

以价值交付为中心,持续演化

以“大模型+数据”为中心,提供个性化服务

团队

规模化团队

(两个披萨)小团队

更小的团队,超级个体的出现

研发
人员

分工明确、细致

提倡全栈工程师

开发和测试融合

业务/产品人员、验证/验收人员(两头成为主导研发的人员)

自动化程度

手工

半自动化(如只实现了测试执行、部署、版本构建等的自动化)

自动化(AIGC)

代码/脚本/设计等自动生成

对待
变化
的态度

严格控制,建立CCB(变更控制委员会)

拥抱变化(其实还是怕变化)

真正地拥抱变化

需求

确定的、可理解的、可表述的PRD文档

用户故事

具有不确定性、可协商

回归自然语言,构建提示词模板、知识库

质量
关注点

产品功能、性能、可靠性

服务质量(QoS)、用户体验

数据质量

1.3.3 软件工程3.0的核心优势

软件工程3.0时代的到来,标志着基于LLM或AIGC技术(即智能化技术)的研发成为提升企业竞争力的关键因素,企业也逐渐认识到智能化研发的巨大潜力,尤其是在软件开发领域。根据中国信息通信研究院的调查数据,智能化技术显著提升了企业研发效率,提升幅度在10%~80%之间,中位数达到41%。这一数据不仅证实了智能化技术的有效性,也预示着它在降低成本、缩短产品上市时间方面的深远影响。随着技术的不断演进,智能化研发将在市场竞争中扮演越来越关键的角色,助力企业保持领先地位。

1.提升研发效率

智能化研发可以显著提升企业的研发效率。传统的研发过程依赖大量人力和时间的投入,而引入智能化技术(特别是大模型技术)后,通过需求分析助手、编程助手(如CodeArts Snap等)、测试助手等可以实现自动化、智能化的研发流程,包括需求文档生成、智能代码生成和优化、测试生成等,显著减少了研发人员在繁琐任务上的时间投入。这些工具也能够快速识别缺陷、提出修复建议,甚至自动修复代码,从而加快开发周期,提升研发效率,根据相关企业应用结果和调查数据,效率提升约40%。

2.降低成本

效率的提升也意味着成本的降低。通过智能化数据分析和模拟,企业可以更精确地预测产品性能和市场需求,避免不必要的试错成本,同时优化资源配置,减少对人力资源的依赖,进一步降低软件开发成本。

3.加速产品上市时间

智能化研发通过需求文档生成、代码自动生成和优化、测试生成等,提升了研发效率,缩短了研发周期,自然也缩短了从概念到产品的时间,即加速了产品上市时间。AI辅助的设计和决策支持系统能够帮助团队快速做出正确决策。自动化的构建和部署流程,在集成了LLM能力之后,也会加快产品迭代速度,使企业能够迅速响应市场变化。

4.改善产品质量

智能化研发通过自动代码评审、自动生成单元测试和代码注释等,提高了测试覆盖率,提升了代码质量,进而提高了产品的质量。未来,借助大模型的深入数据分析,我们能预防问题发生或预测潜在问题,在产品发布前对代码进行优化,并在下一个迭代开发前对研发人员进行培训,这种预防性的质量保证措施大幅提升了产品的可靠性和质量。

5.增强创新能力

智能化研发解放了部分生产力,为研发人员释放了更多工作时间,使他们有更多时间去思考和创新。大模型提供的强大数据分析和模式识别能力,进一步激发了团队的创新潜力。通过深入理解用户行为和市场趋势,企业能开发出更符合用户需求的创新产品。

总之,软件工程3.0在提升研发效率、降低成本、加速产品上市时间等方面带来了显著效益,增强了企业竞争力,有助于实现可持续发展。未来,随着人工智能、大数据等技术的不断发展,智能化研发将更深入地渗透到各行各业,为企业带来更多机遇,实现更长远的发展目标。

1.3.4 软件工程3.0时代的挑战

随着智能化技术在软件开发领域的广泛应用,它所带来的效率提升和成本降低已获得业界的广泛认可。然而,这也伴随着一系列挑战。在智能化研发中,人才短缺和算力需求是两个迫切需要解决的问题,同时,提升认知水平、工具改造与融合,以及CI/CD流程优化也是重要难题。如何有效培养和吸引人才、提高算力利用效率、完善工具和流程,都是智能化研发亟待解决的问题。

1.组织挑战:文化、认知和人才

智能化研发涉及组织文化的变革、思维方式的转变和机器学习人才的需求。

1)企业需要建立一种开放合作、持续学习和创新的组织文化,通过有效的变革管理来克服阻力。例如,鼓励跨部门的沟通和协作,打破信息孤岛,促进知识和经验的共享。

2)企业需要提升全员对智能化技术的认知水平,从高层管理到一线开发人员,每个人都应该理解智能化的潜力和挑战,通过教育和培训全面、正确地认识机器学习、大模型及其作用。

3)智能化研发需要高度专业化的数据治理、模型训练等方面的人才,但目前这类人才相对短缺。企业需要打造吸引人的工作环境,提供有竞争力的薪酬和持续的职业发展机会,以此吸引和留住人才。

2.技术挑战

智能化研发涉及多种技术的融合,包括机器学习、自然语言处理、自动化工具等。这些技术需要与现有的开发流程、工具和管理系统无缝整合或集成,这在技术上是一个巨大挑战。例如,企业需要对现有的工具进行改造,以适应智能化需求,以及将CI/CD流程和DevOps工具链融入大模型技术,从而更好地支持智能化研发和运维等。

3.算力资源挑战

算力是智能化研发的基础资源。随着AI模型的日益复杂,对高性能计算资源的需求也在不断增长。企业需要通过优化算法、分布式调度和云计算服务来提高算力的利用效率;同时,通过对大模型、智能化工具自身的算法进行优化(如DeepSeek R1所采用的技术)来减少资源浪费,提高算力效率。

4.安全可信的挑战

智能化研发依赖大量数据,包括用户数据、业务数据等。这些数据的安全性和隐私保护至关重要。企业必须确保智能化系统的数据收集、存储和处理符合法律法规,并保护用户隐私。

智能化技术,尤其是机器学习和人工智能算法,可能因训练数据的偏差导致产生不公平或歧视性结果。此外,算法决策过程缺乏透明度,难以获得用户和监管机构的理解和信任。开发人员须采取措施以减少算法偏见,提高算法的可解释性。

相关图书

DeepSeek原理与项目实战大模型部署、微调与应用开发
DeepSeek原理与项目实战大模型部署、微调与应用开发
AI辅助编程实战
AI辅助编程实战
大模型工程化:AI驱动下的数据体系
大模型工程化:AI驱动下的数据体系
软件开发中的决策:权衡与取舍
软件开发中的决策:权衡与取舍
大模型驱动的游戏开发
大模型驱动的游戏开发
推荐系统:产品与算法解析
推荐系统:产品与算法解析

相关文章

相关课程