软件开发过程
在软件工程中，软件开发过程是计划和管理软件开发的过程。它通常涉及将软件开发的工作分为较小，并行或顺序的步骤或子过程，以改善设计和/或产品管理。它也被称为软件开发生命周期（ SDLC ）。该方法可以包括由项目团队创建和完成以开发或维护应用程序创建和完成的特定可交付成果和工件的预定义。
大多数现代发展过程都可以模糊地描述为敏捷。其他方法包括瀑布，原型制作，迭代和增量开发，螺旋发展，快速应用开发和极端编程。
生命周期“模型”有时被认为是一种方法论和软件开发“过程”的更一般术语，是一个更具体的术语，是指特定组织选择的特定过程。例如，有许多适合螺旋生命周期模型的特定软件开发过程。该领域通常被认为是系统开发生命周期的子集。
历史
软件开发方法（也称为SDM）框架直到1960年代才出现。根据Elliott（2004）的说法，系统开发生命周期（SDLC）可以被认为是建筑信息系统的最古老的形式化方法框架。 SDLC的主要思想是“以非常有刻意，结构化和有条理的方式追求信息系统的开发，需要生命周期的每个阶段 - 从想法的开始到交付最终系统 - 在应用框架的上下文中进行严格和顺序地进行。该方法论框架在1960年代的主要目标是“在大规模业务集团的时代开发大规模的功能性业务系统。信息系统活动围绕着繁重的数据处理和数字处理程序旋转”。
需求收集和分析：自定义软件开发过程的第一阶段涉及了解客户的要求和目标。这个阶段通常涉及进行详尽的讨论并与利益相关者进行访谈，以确定软件的所需功能，功能和整体范围。开发团队与客户紧密合作，分析现有系统和工作流程，确定技术可行性并定义项目里程碑。
计划和设计：一旦理解了要求，自定义软件开发团队就开始制定全面的项目计划。该计划概述了开发路线图，包括时间表，资源分配和可交付成果。在此阶段还建立了软件体系结构和设计。用户界面（UI）和用户体验（UX）设计元素被考虑以确保软件的可用性，直觉和视觉吸引力。
开发：随着计划和设计，开发团队开始编码过程。此阶段涉及编写，测试和调试软件代码。敏捷方法（例如Scrum或看板）通常被用来促进灵活性，协作和迭代发展。开发团队与客户之间的定期沟通可确保透明度并实现快速反馈和调整。
测试和质量保证：为了确保软件的可靠性，性能和安全性，严格的测试和质量保证（QA）流程。采用不同的测试技术，包括单位测试，集成测试，系统测试和用户接受测试，用于识别和纠正任何问题或错误。质量保证活动旨在根据预定义的要求验证该软件，以确保其功能按预期发挥作用。
部署和实施：软件通过测试阶段后，就可以进行部署和实施。开发团队协助客户设置软件环境，在必要时迁移数据并配置系统。还提供了用户培训和文档，以确保平稳的过渡并使用户能够最大程度地发挥软件的潜力。
维护和支持：部署软件后，持续的维护和支持对于解决任何问题，增强性能并纳入未来增强功能至关重要。释放常规更新，错误修复和安全补丁，以使软件保持最新和安全。此阶段还涉及为最终用户提供技术支持并解决其查询或疑虑。方法，流程和框架范围从组织在日常工作中直接使用的特定规定步骤到组织使用的灵活框架，该框架用于生成根据特定项目的需求量身定制的一套定制步骤或团体。在某些情况下，“赞助商”或“维护”组织分发了描述该过程的官方文件。具体示例包括：
- 1970年代
- 自1969年以来结构化编程
- Cap Gemini SDM ，最初来自Pandata，第一次英语翻译发表于1974年。SDM代表系统开发方法论
- 1980年代
- 从1980年开始的结构化系统分析和设计方法（SSADM）
- 信息需求分析/软系统方法论
- 1990年代
- 以对象为导向的编程（OOP）于1960年代初期开发，并在1990年代中期成为一种主要的编程方法
- 自1991年以来的快速应用开发（RAD）
- 自1994年以来，动态系统开发方法（DSDM）
- 自1995年以来
- 团队软件流程，自1998年以来
- 自1998年以来由IBM维护的理性统一过程（RUP）
- 极限编程，自1999年以来
- 2000年代
- Scott Ambler自2005年以来维护的敏捷统一过程（AUP）
- 纪律敏捷交付（爸爸）取代AUP
2010年代
值得注意的是，自1994年DSDM以来，除了RUP以外的所有方法论都是敏捷的方法论 - 然而，许多组织，尤其是政府，仍然使用敏捷的过程（通常是瀑布或类似的过程）。软件过程和软件质量紧密相关；在实践中观察到了一些意外的方面和效果
其中，在开源中建立了另一个软件开发过程。在公司范围内采用这些最佳实践和已建立的过程称为内部来源。
原型
软件原型制作是关于创建原型，即开发的软件程序的不完整版本。
基本原则是：
- 原型制作不是独立的，完整的开发方法，而是一种在完整方法（例如增量，螺旋或快速应用开发（RAD））背景下尝试特定特征的方法。
- 试图通过将项目分解为较小的细分市场，并在开发过程中提供更便捷的变化来降低固有的项目风险。
- 客户在整个开发过程中都参与其中，这增加了客户接受最终实施的可能性。
- 虽然某些原型是开发出来的，但期望它们会被丢弃，但在某些情况下，有可能从原型发展到工作系统。
对基本业务问题的基本了解对于避免解决错误的问题是必要的，但是对于所有软件方法来说都是如此。
方法论
敏捷发展
“敏捷软件开发”是指基于迭代开发的一组软件开发框架，在该框架中，要求和解决方案通过自组织跨职能团队之间的协作发展。该术语是在制定敏捷宣言的2001年创造的。
敏捷软件开发将迭代开发作为基础，但比传统方法提倡更轻松，以人为中心的观点。敏捷流程从根本上结合了迭代以及它为连续完善和提供软件系统提供的持续反馈。
敏捷模型还包括以下软件开发过程：
持续集成
连续集成是将所有开发人员工作副本合并到共享主线几次的实践。 Grady Booch在1991年的方法中首先命名并提出了CI的命名，尽管他没有每天融合几次。极限编程（XP）采用了CI的概念，并确实提倡每天整合一次以上，也许每天多达数十次。
增量发展
可以将各种方法组合在一起，用于将线性和迭代系统开发方法结合起来，而每个方法的主要目的是通过将项目分解为较小的细分市场并在开发过程中提供更大的变化来降低固有的项目风险。
增量开发的三种主要变体：
- 进行了一系列的迷你水域，在系统的一小部分完成瀑布的所有阶段，然后再进行下一个增量或
- 在进行进化之前，定义总体需求
- 最初的软件概念，需求分析以及建筑和系统核心的设计是通过瀑布定义的，其次是增量实现，这最终在安装最终版本（工作系统）中。
快速应用开发
快速应用开发（RAD）是一种软件开发方法，它有利于迭代开发和原型的快速构建，而不是大量的前期计划。使用RAD开发的软件的“计划”与编写软件本身交织在一起。缺乏广泛的预设通常可以使软件的写入速度更快，并且可以更轻松地更改要求。
快速开发过程始于使用结构化技术的初步数据模型和业务过程模型的开发。在下一阶段，使用原型验证了需求，最终可以完善数据和过程模型。这些阶段是迭代重复的。进一步的开发导致“用于构建新系统的合并业务需求和技术设计声明”。
该术语首先用于描述詹姆斯·马丁（James Martin）在1991年引入的软件开发过程。根据Whitten（2003）的说法，它是各种结构化技术的合并，尤其是数据驱动的信息技术工程，并使用原型技术来加速软件系统开发。 。
快速应用程序开发的基本原则是：
- 关键目标是以相对较低的投资成本快速开发和交付高质量的系统。
- 试图通过将项目分解为较小的细分市场，并在开发过程中提供更便捷的变化来降低固有的项目风险。
- 旨在快速生产高质量的系统，主要是通过迭代原型（在开发的任何阶段），积极的用户参与和计算机化开发工具。这些工具可能包括图形用户界面（GUI）构建器，计算机辅助软件工程（案例）工具，数据库管理系统（DBMS），第四代编程语言，代码生成器和面向对象的技术。
- 关键重点是满足业务需求，而技术或卓越的技术或工程学的重要性较小。
- 项目控制涉及优先考虑开发和定义交付截止日期或“时间表”。如果该项目开始滑倒，则重点是减少要求安装时间表的要求，而不是增加截止日期。
- 通常包括联合应用设计（JAD），其中用户通过在结构化研讨会上的共识建设或以电子方式互动而参与系统设计。
- 积极的用户参与是必须的。
- 迭代生产软件，而不是抛弃原型。
- 生成必要的文档，以促进未来的发展和维护。
- 标准系统分析和设计方法可以安装在此框架中。
瀑布发展
瀑布模型是一种顺序发展方法，其中开发被视为经过多个阶段的稳定向下流动（如瀑布）：
该方法的第一个正式描述通常被称为温斯顿·罗伊斯（Winston W. Royce）于1970年发表的文章，尽管罗伊斯（Royce）在本文中没有使用“瀑布”一词。罗伊斯（Royce）作为一个有缺陷的无工作模型的示例提出了这一模型。
基本原则是：
- 该项目分为顺序阶段，在相之间可以接受一些重叠和飞溅。
- 重点是一次计划，时间表，目标日期，预算以及一次整个系统的实施。
- 通过广泛的书面文档，正式审查以及在开始下一阶段开始之前，在大多数阶段结束时，通过广泛的书面文档，正式审查以及批准/签名来维持严格的控制。书面文档是每个阶段的明确交付。
瀑布模型是一种用于软件工程的传统工程方法。一旦完成后，严格的瀑布方法会阻止重新审视和修改任何以前的阶段。在纯瀑布模型中，这种“僵化”已成为其他更“灵活”模型的支持者的批评来源。这是对几个大型政府项目，随着时间的推移而超过预算的几个大规模政府项目，由于最佳设计，有时未能满足要求。除非合同要求，否则瀑布模型在很大程度上被专门为软件开发开发的更灵活和多功能的方法所取代。请参阅对瀑布模型的批评。
螺旋发展
1988年， Barry Boehm发表了正式的软件系统开发“螺旋模型”，该开发结合了瀑布模型的某些关键方面和快速的原型方法，以结合自上而下和自下而上的概念的优势。它强调了许多人认为其他方法论忽略的关键领域：故意迭代风险分析，尤其是适合大规模复杂系统的迭代风险分析。
基本原则是：
- 专注于风险评估和最大程度地降低项目风险，通过将项目分解为较小的细分市场，并在开发过程中提供更大的变化，并提供了评估风险并在整个生命周期中考虑项目延续的机会。
- “每个周期都涉及通过相同的步骤，对于产品的每个部分以及其每个级别的详细级别的进展，从整体操作文档到每个单独程序的编码。”
- 围绕螺旋的每次旅行都会遍历四个基本像限：（1）确定迭代的目标，替代方案和约束，以及（2）评估替代方案；识别和解决风险； （3）从迭代中开发和验证可交付成果； （4）计划下一次迭代。
- 通过确定利益相关者及其“胜利条件”开始每个周期，并以审查和承诺结束每个周期。
形状
Shape Up是BaseCamp在2018年引入的软件开发方法。这是BaseCamp在内部开发的一系列原理和技术，以克服项目拖延而没有明确终点的问题。它的主要目标受众是远程团队。与瀑布，敏捷或Scrum不同，Shape UP没有估计和速度跟踪，积压或冲刺。取而代之的是，这些概念被食欲，博彩和周期所取代。截至2022年，除了Basecamp外，采用形状的著名组织还包括Uservoice和Block。
周期
通过反复试验，Basecamp发现理想周期长度为6周。这个6周的时间足够长，足以建立有意义的功能，并且仍然足够短，可以引起紧迫感。
成型
塑造是准备工作的过程，然后将其移交给设计师和工程师。形状的工作阐明了解决方案的主要UI元素，标识了兔子孔，并概述了清晰的范围边界。它本来应该是粗糙的，并为建筑商（设计师和工程师）提供更精细的细节来解决，从而使建筑商可以行使其创造力并进行权衡。使用在线文档解决方案以支持评论的在线文档解决方案的形式记录了形状的工作，使团队成员可以异步贡献技术信息。这样的评论对于发现可能使该项目脱轨的隐藏惊喜至关重要。
在周期开始之前，利益相关者持有一个投注表，并在其中审查了音调。对于每个音高，都决定下注或丢弃它。
食欲
形状的方式决定了向项目分配了多少时间与其他方法相反。 Shape Up以食欲（例如6周）开始，并以解决方案设计结束，该设计可以在此约束中传递。胃口成为项目建筑商的艰难截止日期。
建筑
Shape Up是一个两轨系统，塑形器和构建器并行工作。在当前周期中正在塑造的工作可能会给设计师和工程师在未来的周期中构建。
认识到建筑物所带来的技术不确定性，使用图表来跟踪进度，该图表可视化山丘的隐喻，恰当地命名为山丘图。上坡阶段是建筑商仍在锻炼他们的方法，而下坡则是未知数被消除的地方。建筑商使用BaseCamp或Jira上的交互式在线山丘图进行了积极和异步的自我报告进步，将重点从完成或不是Done的状态转变为未知或解决问题。山丘图的使用取代了在Scrum或看板站立中报告线性状态的过程。
高级方法
其他高级软件项目方法包括：
- 行为驱动的发展和业务流程管理。
- 混乱模型- 主要规则始终首先解决最重要的问题。
- 增量资金方法- 一种迭代方法
- 轻量级方法论- 仅具有一些规则和实践的方法的一般术语
- 结构化系统分析和设计方法- 瀑布的特定版本
- 作为较大慢速运动的一部分，缓慢的编程强调了谨慎而逐步的工作，而没有时间压力（或最少）时间压力。缓慢的编程旨在避免错误并过于快速发布时间表。
- V模型（软件开发） - 瀑布模型的扩展
- 统一过程（UP）是基于统一建模语言（UML）的迭代软件开发方法框架。 UP将软件的开发分为四个阶段，每个阶段都包括一个或多个在开发阶段的软件的可执行迭代组成：启动，详细说明，构建和准则。存在许多工具和产品来促进实施。 UP最受欢迎的版本之一是理性统一过程（RUP）。
- 大爆炸方法 - 用于小型或不确定项目的方法，通常几乎没有计划的风险很高。
过程元模型
一些“过程模型”是用于评估，比较和改善组织采用的特定过程的抽象描述。
- ISO/IEC 12207是描述选择，实施和监视软件生命周期的方法的国际标准。
- 功能成熟度模型集成（CMMI）是主要模型之一，是基于最佳实践的。独立评估级组织，了解他们如何遵循其定义流程，而不是根据这些过程的质量或所产生的软件的质量。 CMMI替换了CMM 。
- ISO 9000描述了一个正式组织过程的标准，以制造产品以及管理和监视进度的方法。尽管该标准最初是为制造业创建的，但ISO 9000标准也已应用于软件开发。像CMMI一样，ISO 9000的认证不能保证最终结果的质量，只遵循正式的业务流程。
- ISO/IEC 15504信息技术 - 过程评估也称为软件流程改进能力确定（SPICE），是“评估软件流程的框架”。该标准旨在为过程比较设置明确的模型。香料的使用方式与CMMI一样。 IT对处理，控制，指导和监视软件开发的过程进行了建模。然后，该模型用于衡量开发组织或项目团队在软件开发过程中的实际作用。分析此信息以识别弱点并推动改善。它还确定了可以继续或整合到该组织或团队的共同实践中的优势。
- ISO/IEC 24744软件工程 - 开发方法的型矩模是一种基于电源类型的软件开发方法的元模型。
- 对像管理组的SPEM 2.0。
- 软系统方法论- 改善管理过程的一般方法。
- 方法工程- 一种改进信息系统过程的通用方法。
在实践中
多年来，各种此类框架都在发展，每个框架都有自己的公认优势和劣势。一个软件开发方法框架不一定适合所有项目使用。每个可用的方法论框架都最适合基于各种技术，组织，项目和团队注意事项的特定类型的项目。
软件开发组织实施过程方法来减轻开发过程。有时，承包商可能需要采用的方法论，一个例子是美国国防工业，该行业需要基于过程模型获得合同的评级。描述选择，实施和监视软件生命周期的方法的国际标准是ISO/IEC 12207 。
数十年的目标是找到可重复的，可预测的过程，以提高生产率和质量。有些人试图将设计软件的看似不守规矩的任务系统化或形式化。其他人将项目管理技术应用于设计软件。大量软件项目在功能，成本或交付时间表方面不符合他们的期望 - 有关一些值得注意的示例，请参见失败和超额企业定制软件项目列表。
组织可以创建一个软件工程流程组（SEPG），这是过程改进的焦点。该小组由具有不同技能的线条从业人员组成，是组织中每个参与软件工程过程改进的每个人的协作工作的中心。
特定的开发团队还可以同意对环境详细信息进行编程，例如使用哪个集成开发环境使用一个或多个主导的编程范式，编程样式规则或特定软件库或软件框架的选择。这些细节通常不取决于模型或一般方法的选择。
