常规的流程应该先内部验收，在软件开发接近尾声时，开发团队首先进行内部测试和质量保证活动，包括单元测试、集成测试、系统测试等，以确保软件基本功能的正确性和系统整体的稳定性。这是对软件进行初步验收的过程。然后内部测试通过后，开发团队会将软件交付给客户进行用户验收测试（UAT）。在此阶段，客户或其指定的代表会按照预先定义的验收标准，对软件进行全面的功能验证、性能评估、用户体验测试等，以确认软件是否满足他们的具体业务需求和使用场景。在UAT过程中，客户可能会发现软件存在的缺陷、不符合要求之处或改进点。这些反馈会被记录并提交给开发团队。团队针对反馈进行问题定位、修复，并可能进行必要的回归测试，确保问题得到有效解决。
经过一轮或多轮迭代修复后，客户再次进行验收测试，直至确认软件已无重大问题，完全符合验收标准。此时，客户会签署验收报告，正式表明对软件的认可。
完成正式验收后，开发团队按照合同约定的方式将软件及相关文档、源代码（如有必要）、授权信息、技术支持协议等交付给客户。交付方式可能包括提供安装包、在线部署、云服务开通等，确保客户能够顺利接收并启用软件。
这应该属于一个比较标准的流程~
但是认真思考了很久，我觉得有必要详细说说，讲个故事大家就明白了~
想象一下，你正在策划一场盛大的生日派对，你想要的是一切都完美无缺，从精美的装饰到美味的蛋糕，再到精彩的娱乐节目。当然，你不会在一切都还没准备妥当，甚至都没亲自检查过的情况下，就大张旗鼓地邀请宾客们来参加吧？同样的道理，当我们谈论软件开发的时候，也是要等到一切都经过仔细查验，确认无误后，才会放心地把它交到用户的手中。这就是为什么软件通常是“先验收，后交付”。
让我们把整个过程比作烹饪一道复杂的佳肴。首先，厨师（开发团队）会在厨房里忙碌起来，精心挑选食材（编写代码），按照菜谱（设计文档）一步步烹饪，期间还要不断地尝味道、调整火候（内部测试），确保菜肴的基础口感没问题。这就好比软件开发中的内部验收阶段，开发团队自己先进行全面的质量检查和测试，确保软件的基本功能正常运作。
然而，仅仅厨师满意还不够，毕竟最终品尝这道菜的是食客（用户）。所以，当内部验收通过后，厨师会小心翼翼地将菜肴端到食客面前，请他们亲自尝一尝，看看是否合乎口味，是否有需要调整的地方。食客可能会提出：“盐好像稍微多了一点”或者“我希望再加点香菜提味”。这时候，厨师会立刻回到厨房，按照食客的反馈进行微调，然后再请食客试吃，直到他们满意地点点头。对应到软件开发，这就是用户验收测试（UAT）阶段。用户按照实际使用场景去操作软件，看看它是否能满足自己的业务需求，界面是否友好，速度是否够快，如果有任何不满或者建议，开发团队都会及时修改完善。
经历了几轮这样的“试吃-反馈-调整”循环后，食客终于满意了，点头说：“就是这个味儿！
”于是，这道菜就可以正式上桌，供所有人享用了。同样，当用户对软件的各项功能、性能、用户体验都感到满意，签署了验收报告，这就意味着软件已经通过了正式验收。此刻，开发团队就像那位骄傲的厨师，可以满怀信心地将精心烹制的“软件佳肴”，连同详细的使用说明书、售后服务承诺等“配菜”，一并打包好，通过各种方式（比如提供安装文件、在线部署、开通云服务等）交付到用户的餐桌上。
总结来说，软件开发如同烹饪一道大餐，需要先经过内部验收确保基础品质，再通过用户验收测试满足个性化需求，不断调试优化直至用户满意，最后才正式交付到用户手中。这样严谨的流程，既是对用户负责，也是对开发成果的尊重，确保用户拿到手的就是一份满足期待、可以立即“享用”的高质量软件产品。
然后再回到原问题我们套用这个故事的常识可以得出结论，所以说软件开发项目必须遵循“先验收，后交付”的原则。只有当软件通过了客户或相关利益方的严格验收，确认其满足所有预设条件和质量要求后，才会进行正式的交付环节。这样的流程有助于确保客户接收到的是符合预期、能够立即投入使用的成熟软件产品，从而降低后续因质量问题导致的返工风险和额外成本。
