译者：陈峻
软件开发生命周期(SoftwareDevelopmentLifeCycle，SDLC)包含了软件从开始到发布的不同阶段。它定义了一种用于提高待开发软件质量和效率的过程。因此，SDLC旨在通过最少的资源，交付出高质量的软件。为了避免产生严重项目失败后果，软件开发的生命周期通常可以被划分为如下六个阶段：
需求收集
设计
测试和质量保证
部署
维护
值得注意的是，这些阶段并非是静态的，它们可以进一步地被分解成多个子类别，以适应独特的开发需求与流程。
图1软件开发生命周期
需求收集
这是整个周期中其他阶段的基础。在此阶段，所有利益相关者(包括客户、产品负责人等)都会去收集与待开发软件相关的信息。对此，项目经理和相关方会频繁召开会议。尽管此过程可能比较耗时，但是我们不可急于求成，毕竟大家需要对将要开发的产品有个清晰的了解。
利益相关方需要将收集到的所有信息，记录到软件需求规范(SoftwareRequirementSpecification，SRS)文档中。在完成了需求收集后，开发团队需要进行可行性研究，以确定项目是否能够被完成。
设计
此阶段旨在模拟软件应用的工作方式，并设计出软件蓝图。负责软件高级设计的开发人员将组成设计团队，并通过由上个阶段产生的SRS文档，来指导设计过程，并最终完成满足要求的体系结构。此处的高级设计是指包括用户界面、用户流程、通信设计等方面在内的基础要素。
在此阶段，具有不同专业知识(例如前端和后端)的开发人员或工程师，会通过处理设计的需求，来构建和实现软件。这既能够由一个人，也可以由一个大型团队来执行，具体取决于项目的规模。
后端开发人员负责构建数据库结构和其他必要组件。最后，由前端开发人员根据设计去构建用户界面，并按需与后端进行对接。
在配套文档方面，用户指南会被创建，源代码中也应适当地留下相应的注释。也就是说，为了保证良好的代码质量，适当的开发指南和政策也是必不可少的。
测试
专门的测试人员协同开发团队在此阶段开展测试工作。测试既可以与开发同时进行，也可以在开发阶段结束时再开展。通常，开发人员在开发软件时就会进行单元测试，以便检查每个源代码单元是否能够按照预期工作。同时，此阶段也包括如下其他测试：
系统测试--通过测试系统，以验证其是否满足所有指定的需求。
集成测试--将各个模块组合到一起进行测试。测试团队通过单击按钮，并执行滚动和滑动操作，来与软件交互。当然，他们并不需要了解后端的工作原理。
用户验收测试--是在启动软件之前，邀请潜在用户或客户进行的最终测试。此类测试可以验证目标软件，是否能够根据需求的规范，处理各种真实的场景。
测试对于软件开发生命周期是至关重要的。倘若无法以正确的方式开展，则会让软件项目团队反复在开发和测试阶段之间徘徊，进而影响到成本和时间。
部署
完成测试后，我们就需要通过部署软件，来方便用户使用了。在此阶段，部署团队需要通过遵循若干流程，来确保部署流程的成功。无论是简单的流程，还是复杂的部署，都会涉及到创建诸如安装指南、系统用户指南等相关部署文档。
维护
作为开发周期的最后阶段，维护涉及到报告并修复在测试期间未能发现的错误。在修复方式上，我们既能够采取立即纠正错误的方式，也可以将其作为常规性的软件更新。
此外，软件项目团队还会在此阶段从用户处收集反馈，以协助软件的改进，并提高用户的软件使用体验。
SDLC方法
虽然SDLC通常都会遵从上述步骤，但是它们在实现方式上略有不同。下面，我将介绍排名靠前的6种SDLC方法：
瀑布
敏捷
精益
迭代
螺旋
DevOps方法
瀑布方法
图2瀑布方法
作为最古老、也是最直接的SDLC方法，瀑布方法遵循的是线性执行顺序。如上图所示，从需求收集到维护，逐步依次推进，且不存在任何逆转或倒退的步骤。也就是说，只有当上一步完成后，才能继续下一步。
由于在设计阶段之后，该方法不存在任何变化或调整的余地，因此，我们需要在需求收集阶段，收集到有关项目的所有信息，即制作软件蓝图。可见，对于经验不足的开发团队而言，如果能够保证软件的需求从项目开始就精确且稳定的话，便可以采用瀑布方法。也就是说，瀑布模型的成功，在很大程度上取决于需求收集阶段的输出是否清晰。当然，它也比较适合那些耗时较长的项目。
瀑布的优势
需求在初始阶段就能够被精心设计。
具有容易理解的线性结构。
易于管理。
瀑布的缺点
既不灵活，又不支持变更。
任何阶段一旦出现延迟，都会导致项目无法推进。
由于较为死板，因此项目总体时间较长。
并不鼓励在初始阶段之后，利益相关者进行积极地沟通。
敏捷方法
图3敏捷方法生命周期
敏捷(Agile)即为快速轻松的移动能力。以沟通和灵活性为中心的敏捷原则与方法，提倡以更短的周期和增量式地进行部署与发布。
在敏捷开发的生命周期中，每个阶段都有一个“仪式(ceremony)”，以便从开发团队和参与项目的其他利益相关者处获取反馈。其中包括：冲刺(sprint)计划、每日scrum、冲刺评审、以及冲刺回顾。
总地说来，敏捷开发是在各个“冲刺”中进行的，每个冲刺通常持续大约2到4周。每个冲刺的目标不一定是构建MVP(最小可行产品，MinimumViableProduct)，而是构建可供客户使用的软件的一小部分。其交付出来的可能只是某个功能，而非具有完全功能的产品。也就是说，交付成果可能只是一个将来能够被慢慢增加的功能性服务，而不一定是MVP。
图4构建最小可行产品的示例
在每个冲刺结束后的冲刺审查阶段，如果利益相关者对开发的功能感到满意的话，方可开展下一轮冲刺。虽然新的功能是在冲刺中被开发的，但是整个项目期间的冲刺数量并不受限。它往往取决于项目和团队的规模。因此，敏捷方法最适用于那些从一开始就无法明确所有要求的项目。
敏捷的优势
适合不断变化的需求。
鼓励利益相关者之间的反馈和持续沟通。
由于采用了增量式方法，因此更易于管理各种潜在风险。
敏捷的缺点
最少量的文档。
需要具有高技能的资源。
如果沟通低效，则可能拖慢项目的速度。
如果过度依赖客户的互动，则可能会导致项目走向错误的方向。
精益方法
软件开发领域的精益方法源于精益制造的原则。这种方法旨在减少生产过程中的浪费和成本，从而实现利润的最大化。该方法虽与敏捷开发类似，但是侧重于效率、快速交付、以及迭代式开发。而区别在于，敏捷方法更专注于持续沟通和协作，以体现价值;而精益方法更专注于消除浪费，以创造客户价值。
精益方法的七个核心概念：
消除浪费--鼓励开发团队尽可能多地消除浪费。这种方法在某种程度上并不鼓励多任务处理。这意味着它只需要完成“份内”的处理工作，并通过节省构建所谓“锦上添花”的功能，来节省时间。同时在所有开发阶段都避免了不必要的文档和会议。
鼓励学习--通过鼓励创建一个有利于所有相关成员学习的环境，来促进团队对软件开发过程予以反馈。
推迟决定--在做出决定之前，应仔细考虑各种事实。
尽快交付--由于交付是基于时间的，因此它会专注于满足交付期限的增量式交付，而非大礼包式的发布。
团队授权--它避开了针对团队的微观管理，而是鼓励大家积极地参与到决策过程中，让彼此感到参与了重要的项目。它不但为团队成员提供了指导方向，而且为失败留出了足够的空间。
构建质量--由于在开发周期的所有阶段都
转载请注明地址:http://www.yujinxiangqiangzhi.com/rjcs/rjcs/16766.html
