【SDLC】软件开发生命周期 - 入门

简介：SDLC的六个阶段

软件开发生命周期（SDLC, software development life cycle)，包含软件从开始到发布的不同阶段，旨在提高待开发软件的质量和效率。常划分为以下六个阶段：需求分析 (Analysis)，设计 (Design)，开发 (Implementation)，测试 (Testing)，部署 (Deployment) 和 维护 (Maintenance)。

1. 需求分析(Analysis): 需求分析是软件开发过程中最重要和基础的环节。该阶段所有利益相关方(如：产品经理、业务需求方、开发者等)就软件需求(解决哪些问题)及可行性(能否被解决)进行讨论，并将所搜集到信息记录软件需求文档中(SRS, Software Requirement Specification)。

2. 产品设计(Design): 根据上一阶段记录的软件需求文档，设计出能满足相关需求的体系架构。该阶段定义交互和数据透传流程。

3. 软件开发(Implementation): 该阶段，开发人员根据设计开发和实现软件。后端工程师负责构建数据库结构和其他必要组件。前端工程师负责用户界面设计，并负责与后端架构对接。该阶段，用户指南、源代码的注释等配套文档将有助于提升代码质量，及降低后期软件使用和维护成本。

4. 测试(Testing): 软件正式上线前，为避免软件存在问题和确保软件达到预期效果，相关人员将进行测试。该阶段既可以与开发同时进行，也可以在开发阶段结束时再开展。

5.部署(Deployment): 即软件正式上线阶段，安装指南、系统用户指南等相关部署文档将有效辅助软件部署。该阶段常采用灰度开放的方式逐步完成，避免软件存在问题带来生产事故。

6. 维护(Maintenance): 软件正式上线后，对报告的测试期间未能发现错误进行修复。同时，通过搜集使用者反馈，进一步优化软件设计，提升使用者体验。

SDLC常用方法

在具体实施过程中，SDLC方法因项目需求及背景存在一定差异。以下是常见的几种SDLC模型：

瀑布法(Waterfall Model)

瀑布法遵循的是线性执行顺序，在上一阶段彻底完成后进入下一开发阶段，开发阶段之间不会互相重叠。

适用场景： 需求文档详细、清晰、无变动，技术确定且所需资源(资金、人力、设备等)充足的小型/短期项目。

优点： 易于理解和管理，可为每个阶段设置截止时间。文档清晰，项目完成度易于衡量，易于分工。

缺点： 在开发完成前业务方无法使用软件，可能造成软件效果不理想或与业务需求存在偏差。开发阶段无交互过程，前期文档的目标清晰度将很大成都决定最终软件效果。虽然项目进展清晰，但每个阶段内的进展难以衡量。无法实时变更需求和调整开发。

迭代法(Iterative Model)

将整个项目拆分成多个可独立开发的部分，每次独立开发上线其中的一部分功能，直到整个所有需求全部完成，是一种增量法。

适用场景： 主要需求清晰明确，部分功能需求可能随着时间不断改进得更加详细具体；需要使用新技术，或者进行具有风险的开发项目；部分资源暂时尚不可用的项目。

优点： 项目进展过程中一直有可用的程序，有利于尽快发现程序的错误。阶段性产出成果，更利于定期衡量结果。可以多线开展开发工作。每个阶段发现的问题可以在下阶段被优化。

缺点： 由于小型项目常无法进一步拆解，主要适用于大型项目。需要更多资源和管理。由于并非所有需求都在项目初期确定，可能在开发过程中遇到架构问题。需要更有经验的人进行风险分析。

螺旋法(Spiral Model)

瀑布法与迭代法的结合，且在此基础上更强调风险分析的作用，由定义需求(Identification)， 设计(Design)，开发(Construct/Build)，评估和风险分析(Evaluation&Risk Analysis) 四个环节不断重复组成。

适用场景： 螺旋法是软件开发的常用方法。适用于预算和风险评估非常重要的中高风险的长期项目。项目初期需求并不明确且较为复杂，产品需要尽早发版。项目中可能出现重大改动的需求。

优点： 所需功能可能随着开发产生，并被逐步添加进产品中。可以广泛使用原型。用户早期就可以使用产品并给出反馈。项目被分为多个部分逐步开发，更利于风险控制。

缺点： 需要更复杂的管理。在项目早期，无法预估产品彻底完成的时间。对较小或低风险项目而言成本较高。过多的中间步骤导致需要非常多的文档记录。严重依赖风险分析。

检验法(V-Model, Verification&Validation Model)

检验法是瀑布法的延展，其在开发的每个阶段都增添了对应的测试环节：在需求分析阶段会设计验收试验设计；在架构设计环节，大的项目被拆解为多个小项目，并在预算和可行范围内提出多种设计方案，该步骤被称为高层设计(High Level Design, HLD)；模块设计阶段会进行更为详细的模块构造设计，也被称为低层设计(Low Level Design, LLD)。在设计完成后，会确立使用的编程语言进行开发，开发完成后进入验证阶段：在对各个模块测试完成后，再对模块间的信息流通进行测试，随后是系统的测试（软硬件兼容性），最后由业务方进行验收确认测试。

适用场景： 同瀑布法一样，验证法适用于需求明确且无变动的短开发场景，常用于医药领域。

优点： 项目一次性完成且开发过程严谨，利于管理。

缺点： 不确定性和风险较大，难用于复杂或时间较长的项目。不利于需求在开发过程中不断调整的项目。项目彻底完成前，无可用程序。

敏捷法(Agile Model)

与迭代法类似，敏捷法也是一个逐步开发的模型，但他更关注在快速迭代(一至三周)中用户的满意度和软件的可用性。敏捷法强调不断的与需求方沟通，通过demo软件与用户进行交互，不断根据反馈进行修改。 相比传统的预测性开发方法，敏捷法是一种适应性的开发方法。（预测性开发方法在开发前完成需求分析步骤，适应性开发方法在开发过程中动态调整需求。）

适用场景： 开发人员与需求方交流较方便的场景。

优点： 促进团队合作和跨部门训练，所需资源较少，对变动需求和固定需求均适用。易于管理。

缺点： 需要项目经理进行跨部门管理沟通，对需求方要求较高，由于文档较少可能不利于交接。