匡宏宇-大语言模型时代需求自动追踪技术

大语言模型时代需求自动追踪技术 匡宏宇南京大学 演讲嘉宾 匡宏宇 CCF软件工程专委会执行委员/持续研究自动化软件追踪十余年 南京大学软件学院助理研究员，软件研发效能实验室核心成员，十余年来持续研究软件可追踪性、代码库挖掘、程序理解等软件开发相关方向，曾获ACM南京分会优秀博士论文、AIIDE 2019 Best Paper、教育部-华为“智能基座”栋梁之师等奖项，《开发运维一体化成熟度模型》国家标准的主要起草人之一（产品与需求部分），共发表论文20余篇，其中一作/通讯作者论文11篇（包含ICSE、FSE、ASE等顶尖软工会议论文），应邀担任过SANER2024程序委员，JSEP、JSS、SoSyM期刊审稿人，EASE2024PublicityLead(China)等学术兼职，主持南京大学软件学院需求课程体系建设与教学工作，主持并结题国自然青年基金一项，参与并完成多项重点企业技术合作。 软件研发效能@南京大学 oDevOps/研发效能全⽅位科研oDevOps教材及课程建设oDevOps知识体系构建oDevOps能⼒成熟度国家标准制定oDevOps/研发效能全流程产业合作研究oDevOps/研发效能中国·年度调查oDevOps/研发效能中国社区建设oDevOps/研发效能国内/国际学术论坛oDevOps/研发效能学术论⽂(260+)及专利(80+)oCCF-华为胡杨林基⾦成⽴以来唯⼀连续3年持续获得资助的科研团队 1.需求自动追踪技术背景与发展2.LLM时代需求追踪的重要价值3.基于LLM的需求追踪技术初探4.本人代表研究简介（请多指正）5.总结与展望 目录CONTENTS 需求自动追踪技术背景与发展PART 01 引言：为何要在软件项目开发中“溯源需求”？ •项目开发者视角：如何快速融入团队？以下为亲身经历 •被某世界级通讯技术公司专家当面质问：“你是大学老师？你们课上都在教些什么？？”•大哥为何愤怒：招来的名校新人程序员“不指定具体PRD和单元测试就写不出代码”•假设我们的培养“完美无缺”：学生充分掌握数学基础、编程范式、主流框架、实践经验•但TA大概率仍无法全面快速“上手”主流项目：不了解（复杂）项目的系统功能与演进历史•氛围良好、成熟稳定的开发团队可以缓解这一问题，但问题本质是系统功能与实现之间缺乏明确关联 •项目管理者视角：如何治理、盘活已有项目资产？ •知名网游IP《魔兽世界》：“原汁原味”的怀旧服vs.“锐意创新”的私服 •掌握全部项目资产的官方–直接上线包含所有缺点的经典版本 •自行破解还原的“同人”–推出多个广受好评的改版（官方对此类明确侵权行为态度暧昧） •为何？-项目代码复杂冗余，开发团队人员流失，项目退化为遗产代码（只能运行，无法维护更新） •2018年7.3.5版本尝试升级为20格，结果导致该版本在地图、进度、角色、装备等各个方面均涌现出严重错误 如何系统性应对此类问题？ 需求可追踪性：显式标识需求以及其它软件制品之间的联系 •软件可追踪性是软件系统所能具有的一种特性： [CoEST,theCenterofExcellenceforSoftwareandSystemsTraceability，http://www.coest.org] •系统中任意一个可被唯一标识出的软件制品（softwareartifact，如需求、设计、代码、测试等）与其它制品之间的关联关系 •这些关联关系能够随时间的变化而得到维护 •由这些关联关系组成的网络可以解答与一个软件系统及其开发流程相关的各类问题 •最早以需求可追踪性的方式提出[Gotel@RE1994]•重点关注需求（功能期望）到代码（实际运行）可追踪性 需求可追踪性的诞生 需求可追踪性成为软件开发规范 •诱因：“The Patriot Missile Failure”…的快速修复 •爱国者导弹拦截失败导致的海湾战争中美军单次最大损失•原因：战时长期开机积累的时钟漂移（使用的浮点数精度不足）•1991.2.25日袭击发生，2.26日制造商雷神发布修正软件 •结果：可追踪性引发热议并在90年代成为软件开发规范 •“You cannot manage what you cannot trace”[Watkins@IEEESoftware 1994] •需求可追踪性应该在软件系统中“普遍存在”[Gotel@RE1994] •软件团队能力成熟度CMMI 3级以上“要求实现”可追踪性 •仍是当前诸多关键领域软件的强制要求，如DoD、FAA、FDA、NASA等机构、核心网络设备、金融企业的safe-critical软件 需求可追踪性走入日常开发的价值、困难与挑战 •价值：有效提升（敏捷）软件开发的质量与效率 •（普通新手）开发者通过软件可追踪性可获取（至少）以下关键信息：代码库中需更改的代码元素，受影响的user story与测试用例，以及可咨询的项目组内开发者[Cleland-Huang@FOSE2014] •有效帮助理解已有代码与开发任务：“当前软件开发人员阅读代码与编写代码的耗时比例超过10：1”•Robert C. Martin 2008-《Clean Code: A Handbook of Agile Software Craftsmanship》 •软件维护任务在需求到代码可追踪性的支持下，正确率提高了60%，效率提高了20%[Maeder@ICSM2012]•在质量保证[Rath@TSE2017]、系统安全[Moran@ICSE 2020]、缺陷定位[Niu@ICSE2023]等研究中被广泛应用 •人工追踪成本近似于开发本身，导致现实系统中并不常见[Ramesh@JournalofDefenseSoftwareEngineering1995] •挑战：如何使得需求（软件）可追踪性“广泛存在” •Grand Challenge of Software Traceability: Ubiquitous[Gotel@RE2012]•引入自动化分析技术，构建高效、可信的需求自动追踪技术与工具 自动化需求追踪在软件工程领域研究中的发展 2005：确立方向 2017：继往开来 2014：承上启下 p探讨下一个十年的发展：如何利用软件代码库中的大数据、基于（深度）学习的自动化追踪技术、生产实践中的运用等 p领域内专业workshop—TEFSE开始接受软件可追踪性相关主题学术投稿 p总结软件可追踪性的发展趋势并展望未来方向:满足实际需求，实现可追踪性的低成本高价值、可配置、可信、可控、便捷 近15年需求自动追踪生成技术发展文献综述（2010-2024）搜索词条： 筛选条件： (traceabilityOR"requirementstrac*" OR"softwaretrac*" OR"linkrecover*" OR"tracerecover*") AND(artifactORartefactORdocumentORsoftware ORrequirementORissue) AND(recover* ORretriev* ORgenerat* ORcreat*) NOT(foodOR"networksecurity"OR"sensorsnetwork"OR"supplychain"OR"genetictraceability"OR"blockchain") 自动追踪目标制品：从传统文档到代码库制品 LLM时代需求追踪的重要价值PART 02 需求可追踪性对软件开发的积极作用–知名软件产品视角 •某著名蓝色支付软件–安卓APP“瘦身” •非必须系统功能的遗留使得软件过于“臃肿”，导致用户体验下降并增加安全风险•采用动态监控的方式逐步锁定冗余功能•“MiniMon:MinimizingAndroidApplicationswithIntelligentMonitoring-BasedDebloating”，ICSE2024 •若有可追踪性的支持，可在源码层面实现功能定位与系统重构 •某造车大成功的IoT生态公司–安卓OS社区被迫封闭 •机型丰富加重“安卓碎片化”，被迫大幅弱化系统的用户可定制性，关键的12.5版本发布也被拖累 •若有可追踪性的支持，可在源码层面实现“自底向上”的软件产品线模型构建与系统特性定制 •大模型出现后的时代需要–开发过程数据资产化是大模型助力软件开发的前提 •要充分利用大模型的对话式交互与超强文本归纳能力，必须有效治理、组织、利用开发过程中的各类数据 •需求可追踪性能够在不同类型、不同格式的制品之间显式建立追踪线索，是开发数据资产化的关键 需求可追踪性在大模型时代对软件开发的重要作用 •目前LLM是否已彻底改变软件开发？ •对程序员的个体编码能力提升较为明显•但从软件开发的人、过程、制品三个维度来看，整体效率并未大幅提升–“理解代码”的难度要远高于“写出代码”•基于系统功能显式关联各个软件制品的软件（需求）可追踪性是程序理解的关键 •如何更好地在特定领域项目开发上应用LLM？ •ChatGPT类通用大模型是在海量数据上的一次“最优化拟合”，难以直接回答特定问题，必须依赖有效的Prompt引导通用大模型“聚焦”•进一步通过开发数据资产化积累项目日常开发的高质量数据，从而基于这些数据构建专用的“小”大模型•数据资产化的核心是软件可追踪性的高效实现 1.⼤模型在具体开发任务上有赖于对专⽤数据的利⽤ 2.有必要在通⽤⼤模型的基础上构建专⽤⼤模型3.构建专⽤⼤模型需要构建⾼质量数据集与验证集4.将⼤模型与已有技术结合是值得去做的宝贵尝试5.项⽬专家依然需要⽤⾃⼰项⽬微调专⽤⼤模型，微调后的模型可以提供对话式的端到端交互 •将软件开发与LLM充分结合后的前景展望（代差）？ •有效应对软件开发的进一步复杂化•LLM时代会出现更多AI-Intensive系统，代码将不再是唯一关键制品（额外涉及AI模型与训练数据）•对软件（需求）可追踪性也提出了更高要求•开发效率持续提升后增强企业业务创新能力BizDevOps 基于LLM的需求追踪技术初探PART 03 需求追踪的本质问题：概念指派（Concept Assignment） •生成或维护需求与代码之间的追踪关系的本质问题，是要将模糊的人脑概念与明确的代码元素关联起来，即所谓的概念指派问题[Biggerstaff et al.,ICSE 1993] •人脑概念基于自然语言和领域知识，而代码逻辑基于数理逻辑与数学运算，二者存在本质区别 •需要人的创造跨越二者间的语义鸿沟-正向指派即为软件开发，逆向指派即为软件（需求）追踪 有了需求追踪加持的软件开发才能实现问题空间到解空间的持续转化，从而有效提升当前以软件维护与演化为核心的软件（敏捷）开发质量与效率 已有自动追踪技术的本质与趋势 •（半）自动追踪（生成）技术共通点•挖掘用户开发的已有软件 制品所包含的系统语义•代码结构、测试集合、制品文本、开发记录等•优先降低用户追踪成本，进而提升追踪质量•辅助追踪–构造测试–搜索筛选–日常标注•考虑到当前软件开发与概念指派的本质，需求追踪无法实现全自动化•“Human in theLoop”式的半自动化 基于信息检索的自动追踪生成技术概述 主要基于制品文本增强，以及结合软件制品特性的排序优化。更复杂的IR模型作用有限（因制品文本质量较差） 步骤： p⼤⼩写转换、去除特殊字符、去除停⽤词、提取词⼲ 2.使⽤IR模型计算⽂本相似度，⽣成候选追踪列表p常⽤检索模型：VSM，LSI，JSD，BM25，LDA等 3.分析并优化候选追踪列表，得到最终追踪列表 p语义鸿沟，单词失配p对上下⽂和语义理解能⼒有限p丢失部分⾮⽂本特征 p⽅法直观，可解释性强p可扩展性强 按IR值降序排列 相⽐于经典机器学习应⽤，可⽤于学习式⾃动追踪⽣成的数据少且质量差，同时⾯