计算机软件开发合同纠纷的六个实务争议与裁判思路

软件开发不是把一件形态确定的成品交给对方，而是把委托方的业务目标一点点转化为能够运行的程序。签约时，双方通常只能确定系统范围、主要模块和初步工期；随着需求调研、原型设计、编码、测试、试运行一路推进，原有需求不断细化，也会出现新增功能。开发成果通常需要经历多轮交付、反馈和修复，很难用某一个静态时间点概括全部履行情况。

正因如此，争议一旦发生，如果只依据合同名称、最初工期、问题数量或者验收文件的有无作形式判断，往往难以准确评价双方的实际履行情况。本文以笔者经办的一起企业管理系统开发仲裁案为主线，讨论六个焦点问题：合同名称与合同性质不一致时如何定性；需求细化与新增需求如何区分；交付、测试、试运行与验收如何衔接；迟延和软件瑕疵何时构成根本违约；无解除权一方发出的解除通知是否有效；合同解除后已经投入并形成的开发成果如何计价。这六个问题背后，贯穿着同一条逻辑——合同目的、需求基线、履行过程、成果可用性、解除效力与解除后结算。

案情本身很有代表性。A公司与B公司签订了一份名称为“系统销售合同”的协议，由A公司为B公司建设企业管理系统。项目启动后，双方陆续确认蓝图方案、需求说明书、原型文件和实施计划，需求数量由签约时估算的二百余项扩展至四百余项。A公司完成了主体PC端的开发、部署、培训和多轮测试，但约定的两个辅助终端尚未完成。B公司随后以迟延交付、功能不完整和使用体验不佳为由发出解除通知；A公司认为主体系统已经基本完成，要求支付剩余价款并承担违约责任。

一、合同叫“销售合同”，就按买卖处理吗？

——合同性质如何定性

（一）基本案情

涉案合同名称为“系统销售合同”，形式上使用了“销售”“产品”等表述，但合同履行并非交付一套已经定型的通用软件。A公司需要围绕B公司的具体业务流程开展需求调研，编制蓝图方案、需求说明书和原型文件，再完成程序设计、编码、部署、测试、培训及后续维护。合同成果包括主体PC端以及两个辅助终端，各端功能均需根据B公司的实际经营管理需求定制。

争议发生后，合同性质直接影响审理思路。如果作为普通软件买卖处理，关注重点容易集中在交货日期和成品是否符合规格；如果认定为计算机软件开发合同，则必须进一步考察需求形成、双方协作、阶段成果、测试反馈和迭代修复等连续履行过程。

（二）仲裁认为

仲裁庭没有拘泥于“销售合同”的名称，而是根据合同主要权利义务和实际履行内容，认定涉案合同属于计算机软件开发合同。B公司的合同目的并非取得市场上现成的软件许可，而是取得能够实现其特定业务流程和功能需求的定制化系统；A公司的核心义务也不是简单交货，而是完成调研、设计、开发、测试和交付。

在此基础上，仲裁庭将双方后续形成的蓝图、需求说明、原型确认、实施计划和测试记录纳入合同履行评价，而不是只对照合同签订时的概括条款。这一合同定性，为后续判断工期、需求范围、交付状态和解除后结算奠定了基础。

（三）实务分析

合同性质应当根据主要给付义务和合同目的判断，合同名称只是参考因素。定制开发通常有三个识别特征：一是成果需要针对委托方的特定业务设计，不能以成熟产品直接替代；二是开发方必须经历需求调研、原型确认、编码和测试等过程；三是委托方负有持续提供业务规则、数据、接口、测试人员和反馈意见等协作义务。即使合同同时包含软件许可、硬件采购、部署和维护，只要争议的核心发生在定制开发部分，仍应当按照软件开发合同的履行规律审查。

这一“重实质、轻名称”的定性思路，在最高人民法院的裁判中也有体现。在（2021）最高法知民终887号案中，法院根据合同约定的开发成果、交付资料及知识产权安排等主要权利义务，认定双方形成委托开发关系，而未拘泥于合同中有关后续生产安排等其他表述。这给我们的启示是，接手案件后不妨先制作一张“主要义务清单”，识别双方究竟是在买卖既有产品，还是在共同推进一个尚未完成的定制开发项目。

起草合同时，也应避免用“销售合同”“服务合同”简单覆盖复杂交易。比较稳妥的做法，是把成熟软件许可、定制开发、硬件采购、系统集成、培训和维护等义务区分开来，分别约定价款、交付物和验收标准。这样即使某一部分发生争议，也不至于让合同性质和责任边界整体混淆。

二、需求细化还是新增需求？

——开发范围的边界在哪里

（一）基本案情

合同签订时，双方仅确定了系统范围和初步功能。项目启动后，双方经过数月调研，先后确认多个版本的蓝图方案、需求说明书和原型文件，并共同签署实施计划。实施计划明确记载，需求功能已由签约时估算的二百余项增加至四百余项，实施周期可能相应顺延。

进入测试阶段后，B公司在共享问题清单中提出大量意见。部分意见属于程序自身问题，部分要求改变已经确认的页面、流程和业务规则，另有部分属于界面优化、操作习惯调整或全新的功能要求。A公司对程序问题优先修复，对其认为属于新增或优化的事项则标注暂缓处理，双方由此对“合同内义务”与“额外需求”的边界产生争议。

（二）仲裁认为

仲裁庭将双方签署或确认的蓝图方案、需求说明书、原型文件和实施计划共同作为需求基线，没有把最初合同附件视为唯一依据。双方在履行中对需求作出的确认，构成对原合同内容的补充或调整，也可用于确定开发范围和工期起算条件。

针对测试问题，仲裁庭结合需求基线逐项区分：能够在已确认功能中找到依据，且属于程序运行异常的问题，应由A公司修复；要求增加新的业务对象、流程或功能的，通常属于新增需求；不改变核心流程、主要涉及界面呈现和操作便利性的，通常属于优化事项；因使用方法不当产生的问题，则需结合培训和操作手册判断。

仲裁庭同时注意到，需求数量显著增加以及双方重新确认实施计划，客观上影响了原定开发周期，不能将全部延期归责于A公司。

（三）实务分析

需求细化与新增需求的核心区别，不在于表述是否发生变化，而在于新要求能否从原有功能和合同目的中合理推导。可以从五个方面判断：

第一，原需求是否已经包含相应的业务对象和流程；第二，新要求是否增加新的模块、接口、终端或权限体系；第三，是否需要改变既有架构或者重做已完成模块；第四，双方是否曾将该事项标记为“新增”“变更”，或者单独讨论费用、工期；第五，签约时开发方是否应当合理预见并计入报价。

例如，合同已约定“订单审批”，后续明确审批节点、字段和展示方式，通常属于需求细化；增加全新的供应链结算、第三方支付接口或新的移动终端，则更可能构成新增需求。界面美观度、操作习惯和用户体验的调整，应当与影响数据准确性、业务流转和权限安全的功能缺陷区分开来。

需求边界如何判断，最高人民法院的裁判同样给出了方向。（2022）最高法知民终1612号案认为，即使采用迭代式开发，每一阶段仍需形成相对清晰的需求确认；需求确认和新增工作量显著增加开发时间时，不能仅因未在原定日期上线就认定开发方违约。

该案与本案共同说明，需求争议不能停留在聊天记录的零散表述上，而应建立一张“需求矩阵”，把每项争议对应到原合同、后续确认文件、提出时间、开发方反馈、工作量和工期影响。

合同管理中应当设置正式的变更机制：变更申请写明提出主体、具体内容、是否属于原范围，以及对费用和工期的影响；双方尚未确认前，明确是暂停开发、先行开发后结算，还是仅列入后续版本。没有可追溯的变更机制，开发方容易陷入“做了无法收费、不做又被指违约”的两难，委托方也难以判断项目延期究竟由何种原因造成。

三、没签验收单，就等于没交付吗？

——交付、测试、试运行与验收的衔接

（一）基本案情

A公司完成主体PC端开发后，向B公司发送用户测试通知，提供系统地址、账号和密码，并将程序部署至约定的服务器环境。B公司组织各部门负责人开展测试，双方通过共享文档记录问题和处理结果。

此后，A公司继续修复程序问题、开展培训并交付操作手册，通知B公司用户测试结束、系统进入试运行阶段，同时催请B公司办理验收和支付下一期款项。

B公司始终没有签署正式验收报告，但其已经组织多部门测试，并在较长时间内持续反馈和使用系统。双方对主体PC端是否已经完成交付、是否具备正常使用条件以及付款节点是否成就存在分歧。

（二）仲裁认为

仲裁庭区分了交付、测试、试运行和验收的不同法律意义。A公司提供系统访问地址、账号密码并部署至约定环境，表明其已将可测试成果置于B公司控制之下；B公司组织人员测试并提交问题清单，说明成果已经进入测试阶段；A公司后续完成培训、交付操作手册并通知进入试运行，进一步证明主体PC端已经实际交付。

虽然双方未签署正式验收报告，且系统仍存在部分待完善事项，但测试结果显示大部分功能流程正常，程序自身问题大多已经修复，未解决事项主要是新增、优化或操作理解问题。仲裁庭据此认定主体PC端已经基本完成并可以正常使用。

换言之，未完成书面验收，不等于此前的实际交付、测试和试运行均不存在。

（三）实务分析

交付、测试、试运行与验收，应当按照履行过程分层判断。交付是开发方将可供检验的成果置于委托方控制之下；测试是双方发现并修复问题的过程；试运行是软件进入真实或接近真实的业务环境；验收则是委托方对成果是否达到约定标准作出确认。

四个阶段可以连续发生，但法律效果并不相同。上线或试运行通常能够证明软件已经交付并具有一定可用性，却不必然等同于最终验收合格；同样，存在少量待修问题，也不当然否定此前已经发生的交付。

裁判对这一点的把握是一致的。在（2020）最高法知民终1353号案中，最高人民法院明确区分软件开发成果的交付与验证确认：软件进入相关应用市场供公众下载安装，是交付开发成果的重要标志；此后项目才进入验证、测试和使用阶段，在验证阶段仍可能通过修改源代码和文档继续完善软件。

可见，交付与验收并非同一法律事实，关键仍要结合合同约定和实际履行过程判断。

实务中，开发方应保存部署日志、交付邮件、账号移交、测试通知、培训签到、操作手册、问题修复记录和上线数据；委托方如认为成果不合格，则应在约定期限内提出能够定位的问题，说明对应需求、复现步骤、严重程度及业务影响。

合同还应明确验收的启动条件、测试环境、反馈方式、整改次数和逾期未反馈的后果。只有开发方已经提供完整的测试条件和必要资料时，才能进一步讨论逾期验收或者视为验收的问题。

四、迟延和瑕疵，什么时候才算根本违约？

——关键看合同目的有没有落空

（一）基本案情

B公司主张，A公司超过最初预计日期较长时间才交付主体PC端，且测试中仍存在关联业务未打通、界面不友好和部分功能未开发等问题；两个辅助终端也尚未完成，因此A公司构成根本违约。

A公司则主张，双方在签约后持续细化和增加需求，并重新确认实施计划；主体PC端已经完成大部分功能和多轮测试，现存问题并不足以否定整体成果。

从实际履行看，B公司在最初期限经过后仍继续确认需求、参与测试和要求修复，没有立即以逾期为由拒绝履行。主体PC端承载绝大多数功能，可以独立运行；尚未完成的两个辅助终端所占功能和工作量相对较小。

（二）仲裁认为

仲裁庭认为，是否迟延不能只以合同签订日机械推算。合同将需求确认与工期相联系，双方又在履行中持续调整需求并签署新的实施计划，B公司还在原期限经过后继续配合测试。需求扩张和共同调整计划均对进度产生影响，因此不能将全部延期归责于A公司。

对于软件瑕疵，仲裁庭没有以问题数量作为判断标准，而是考察问题是否导致核心功能不能运行。现有证据不足以证明主体PC端存在使系统无法正常使用的逻辑错误或结构缺陷，测试中的程序问题大多已经处理，其他问题主要属于新增、优化或操作偏差。

两个辅助终端虽未完成，但相对独立且占整体工作量较小，不足以导致B公司的主要合同目的不能实现。因此，A公司的履行存在不完整和瑕疵，但未达到根本违约程度。

（三）实务分析

根本违约强调违约后果是否使合同目的不能实现，而不是要求软件“毫无问题”。

迟延构成根本违约，通常需要综合判断：工期起算条件是否成就；延期是否主要由开发方造成；委托方是否继续接受履行或者通过行为调整期限；迟延是否使特定商业目的落空；开发方经催告后是否仍拒绝或不能履行。

对软件瑕疵，则应重点考察未完成功能是否位于核心业务链，系统能否独立运行，问题能否在合理期限内修复，是否影响数据安全、业务闭环和关键接口，以及开发方是否拒绝整改。

反过来，如果缺陷直接否定委托方取得并稳定使用开发成果的核心利益，结论就会不同。在（2021）最高法知民终677号案中，开发方交付的软件存在第三方权利瑕疵，无法保障委托方依约取得并稳定行使源代码著作权，法院据此认定委托方的合同目的不能实现。

该案与本案的差异，不在表面问题数量，而在瑕疵是否触及交易的核心利益：非核心模块未完成，可能只构成部分履行；关键业务闭环、数据安全或者成果权利基础缺失，则可能使合同目的落空。

因此，争议处理中不宜简单统计BUG数量。问题清单应至少区分“阻断性缺陷、严重缺陷、一般缺陷、优化事项、新增需求和操作问题”，并记录版本、复现条件、修复状态和业务影响。

需要技术鉴定时，还应先固定交付版本和运行环境；如果委托方在争议后自行修改程序或者更换运行环境，检材同一性无法证明，鉴定结论的证明力将受到影响。

五、没有解除权，解除通知还有效吗？

——解除效力的两个层次

（一）基本案情

B公司以迟延交付、功能不完整和系统无法正常使用为由，向A公司发出解除合同通知。A公司确认收到通知，但明确表示B公司不具备约定或法定解除权，通知不产生解除效力。

仲裁审理过程中，仲裁庭要求双方明确是否愿意继续履行；B公司坚持解除，A公司也表示同意结束合同关系并按照已完成成果结算。

由此产生两个不同层次的问题：一是B公司最初发出的单方解除通知是否立即发生解除效力；二是即使该通知不发生解除效力，双方后来一致表示不再继续履行，是否可以形成新的解除合意。

（二）仲裁认为

仲裁庭首先审查B公司是否享有解除权。由于A公司的迟延不能完全归责于其自身，主体PC端已经基本完成且能够使用，未完成部分不足以导致合同目的不能实现，合同约定的解除事由和《民法典》第五百六十三条规定的法定解除条件均未成就。因此，B公司在无解除权的情况下发出的通知不产生解除合同的效力。

但仲裁庭进一步认为，单方解除不发生效力，并不意味着合同必须永久存续。仲裁过程中，双方均明确不愿继续合作，合同履行已经陷入僵局，继续履行缺乏现实基础。双方后续一致的意思表示构成合意解除，合同应以合意形成之日作为解除时间，而不能追溯至B公司最初发出通知之日。

（三）实务分析

解除通知是解除权的行使方式，不是解除权的来源。《民法典》第五百六十五条规定，依法主张解除合同应当通知对方，前提仍是通知方已经享有约定或者法定解除权。

《最高人民法院关于适用〈中华人民共和国民法典〉合同编通则若干问题的解释》第五十三条进一步明确：当事人一方以通知方式解除合同，并以对方未在约定的异议期限或者其他合理期限内提出异议为由主张合同已经解除的，人民法院应当对其是否享有法律规定或者合同约定的解除权进行审查。

也就是说，对方没有立即起诉确认通知无效，并不当然使无权解除转化为有效解除。

此外，还要避免把软件开发合同当然等同于承揽合同。有委托方援引《民法典》第七百八十七条关于承揽合同定作人任意解除权的规定，主张可以随时解约。最高人民法院在（2021）最高法知民终2353号案中指出，计算机软件开发合同属于技术类合同纠纷，不宜直接适用承揽合同任意解除权规则。

不过，这并不意味着合同陷入僵局后只能继续履行。依照《民法典》第五百八十条第二款，在符合法定条件时，当事人可以请求人民法院或者仲裁机构终止合同权利义务关系，违约责任仍应另行处理。

因此，应当区分通知解除、合意解除与请求司法或者仲裁终止合同关系，不能把三者混为一谈。

这一“无权解除不生效、但可另行合意解除”的思路，在裁判中亦有印证。（2021）最高法知民终228号案中，一方在不享有解除权的情况下发出通知，法院未据此认定合同已经解除；但双方后来在诉讼中均明确同意解除，法院据此确认了合意解除及其时间。

这与本案的处理一致，提示我们依次回答三个问题：通知方有无解除权；如果没有，双方其后是否另行协商解除；如果双方均不愿继续履行，解除合意在何时形成。

实务中，发出解除通知前应逐项核对合同约定和法定解除事由，区分一般瑕疵、迟延履行与合同目的不能实现。对于可以修复的问题，通常还应先书面催告并给予合理整改期限。

解除通知应载明具体违约事实、对应条款、催告经过、解除依据、解除日期和交接方案。没有解除权而贸然停用系统、关闭服务器或拒绝配合，可能使通知方自身构成拒绝履行，并影响后续结算和违约责任。

六、合同解除后，已经投入的成果怎么算钱？

——解除后的结算逻辑

（一）基本案情

涉案合同约定一个总价，没有分别标明主体PC端和两个辅助终端的价格。B公司已经支付首期款；A公司实质完成了主体PC端的开发、部署、测试、培训和操作手册交付，但两个辅助终端未完成，主体PC端仍有少量瑕疵，正式验收也尚未完成。合同解除后，培训、维护和继续完善等未来义务不再履行。

A公司主张主体系统已经基本完成，应支付剩余合同款并承担违约责任；B公司则认为A公司存在迟延和功能缺失，不应再支付价款。如何评价已经投入并形成的开发成果，成为解除后结算的核心。

（二）仲裁认为

仲裁庭依据《民法典》第五百六十六条，将“是否解除”与“解除后如何结算”分别处理。软件开发中的需求分析、架构设计、编码和测试一经完成，投入的人工无法返还，委托方已经取得的系统、文档和业务流程成果也难以恢复至合同订立前状态，因此不能机械适用“解除即全部返还”。

在合同没有模块单价、又缺乏可直接鉴定条件的情况下，仲裁庭以实施计划记载的各端一级、二级和三级功能数量为客观起点，同时结合主体PC端承担的核心业务、双方实际投入和沟通重点、系统可独立使用程度，认定主体PC端占整体开发工作的主要比重，并酌情按照合同总价约七成确定已完成成果价值。扣除B公司已经支付的首期款后，B公司仍需补付相应差额。

与此同时，仲裁庭没有支持A公司主张的违约金。主要考虑是两个辅助终端尚未完成，主体PC端仍有瑕疵且未经正式验收，合同解除后培训、维护和后续完善义务也不再履行。仲裁庭据此将已完成成果的价款结算与违约责任分别评价，避免对同一履行利益重复补偿。

（三）实务分析

合同解除后的清算，实质是对已经履行的利益、剩余义务和双方责任的综合分配。计算软件开发成果价值时，可以依次考察：合同是否约定里程碑或模块单价；已完成模块在整体系统中的功能地位；工作量和开发难度；成果能否独立运行；委托方是否已经使用或能够继续利用；源代码、文档、账号和部署环境是否交付；未履行的培训、维护和质保义务价值；双方对合同解除的过错程度。

本案采用的“模块占比＋酌情修正”方法具有现实意义。功能数量可以提供相对客观的锚点，但不能简单等同于工作量：核心算法、底层架构和关键接口的价值可能明显高于多个普通页面；反之，数量较多但重复度较高的功能，未必具有同等开发成本。

较为稳妥的做法，是先按照模块、里程碑或者功能数量确定基础比例，再根据核心程度、可用性、实际使用、交付状态和未履行义务作出修正。

这种“视情况折价”的立场，最高人民法院一以贯之。（2020）最高法知民终1545号案指出，判断先期开发款是否返还，应综合软件开发合同特点、实际履行、双方过错、投入工作量和已完成成果等因素，不能仅凭合同解除作全有或全无的处理。

只有在开发方的根本违约使成果完全无法利用，或者开发方未交付任何可识别成果时，全部返还才更具正当性；如果委托方已经取得并能够利用主要成果，即使合同解除，也应考虑折价补偿。

还有两个细节值得单独记下。

其一，在（2021）最高法知民终1525号案中，法院结合合同约定和履行情况，将首期款认定为软件开发项目的启动资金，并未因合同解除即判令全额返还。

其二，（2020）最高法知民终1545号案明确指出，除合同另有约定外，分期支付的每一期开发款并不当然要求存在与之逐项对应的阶段成果。

由此可见，解除后的结算既不能把首期款一概视为应当返还的预付款，也不能把“已完成工作量”与各期付款机械对应，仍须回到合同约定、履行程度、成果可用性和双方过错作整体判断。

从风险控制角度看，合同应当将PC端、移动端、接口、源代码、文档、培训和维护分别设置里程碑和价格权重，并明确解除时的计价方法。项目履行中还应持续记录各模块的完成状态、测试结果和交付版本。这样既能减少“全部返还”与“支付全款”之间的极端对立，也能在无法鉴定时为裁判者提供可解释的结算基础。

结语

软件开发合同纠纷的难点，不是缺少法律规则，而是如何把动态、技术化、碎片化的履行事实，转化为可以评价的合同事实。

本案所呈现的处理路径可以概括为：先依据主要给付义务确定合同性质；再通过合同附件和履行文件锁定需求基线；区分交付、测试、试运行和验收，判断问题属于程序缺陷、优化、新增需求还是操作偏差；结合核心功能、可用程度、修复可能性和双方协作评价是否构成根本违约；最后分别审查单方解除通知、后续解除合意以及已完成成果的结算。

对市场主体而言，有效的风险控制不是把合同写得更长，而是让需求、版本、变更、测试、验收和价款权重均可追溯。对争议解决者而言，不宜把软件项目中的每一个问题都等同于不合格，更不能因为系统“并不完美”就整体否定已经形成的开发成果。

只有在合同约定、行业特点、实际履行和公平原则之间建立可解释的联系，才能合理平衡开发投入与委托方的合同目的。

附：本文依据与案例索引

法条：《中华人民共和国民法典》第五百六十二条至第五百六十六条、第五百八十条、第五百八十四条、第五百八十五条、第七百八十七条；《最高人民法院关于适用〈中华人民共和国民法典〉合同编通则若干问题的解释》第五十三条。

案例：（2021）最高法知民终887号；（2022）最高法知民终1612号；（2020）最高法知民终1353号；（2021）最高法知民终677号；（2021）最高法知民终2353号；（2021）最高法知民终228号；（2020）最高法知民终1545号；（2021）最高法知民终1525号。

声明：本文仅为实务研究和经验交流，不构成针对任何具体事项的法律意见。