软件开发过程

在软件工程， 一个软件开发过程是分裂的过程软件开发在较小，平行或顺序的步骤或子过程中工作以改进设计，产品管理。它也被称为软件开发生命周期（SDLC）。该方法可能包括特定的预定可交付成果以及由项目团队创建和完成的工件，以开发或维护应用程序。[1]

大多数现代发展过程都可以模糊地描述为敏捷。其他方法包括瀑布，原型，迭代和渐进发展，螺旋发展，快速应用开发， 和极端编程.

生命周期的“模型”有时被认为是一类方法论和软件开发“过程”的更一般术语，该过程更具体地参考特定组织选择的特定过程。例如，有许多适合螺旋生命周期模型的特定软件开发过程。该领域通常被认为是系统开发生命周期.

历史

直到1960年代，软件开发方法（也称为SDM）框架才出现。根据Elliott（2004）的说法系统开发生命周期（SDLC）可以被认为是建造最古老的形式化方法框架信息系统。SDLC的主要思想是“以一种非常有刻意，结构化和有条理的方式追求信息系统的开发，需要生命周期的每个阶段 - 从想法的开始到交付最终系统 - 被严格执行”[2]在应用框架的上下文中。该方法论框架在1960年代的主要目标是“发展大规模功能业务系统大规模商业集团的时代。信息系统活动围绕沉重数据处理和数字运算例程”。[2]

方法，过程和框架范围从组织在日常工作中直接使用的特定规定步骤到组织使用的灵活框架，该框架用于生成根据特定项目的需求量身定制的一组定制步骤或团体。在某些情况下，“赞助商”或“维护”组织分发了描述该过程的官方文件。具体示例包括：

1970年代
1980年代
1990年代
2000年代

2010年代

值得注意的是，自1994年DSDM以来，除RUP以外的所有方法论都是敏捷的方法论 - 然而，许多组织，尤其是政府，仍然使用敏捷的过程（通常是瀑布或类似的过程）。软件流程和软件质量紧密相关；在实践中观察到了一些意外的方面和效果[3]

其中，在此中建立了另一个软件开发过程开源。在公司范围内采用这些最佳实践已知和已建立的流程被称为内源.

原型

软件原型制作是关于创建原型，即开发的软件程序的不完整版本。

基本原则是：[1]

  • 原型制作不是独立的，完整的开发方法，而是一种在完整方法（例如增量，螺旋或快速应用开发（RAD））背景下尝试特定特征的方法。
  • 试图通过将项目分为较小的细分市场并在开发过程中提供更大的变化来减少固有的项目风险。
  • 客户在整个开发过程中都参与其中，这增加了客户接受最终实施的可能性。
  • 虽然某些原型是在期望将其丢弃的期望中开发出来的，但在某些情况下，有可能从原型发展到工作系统。

对基本业务问题的基本理解对于避免解决错误的问题是必要的，但是对于所有软件方法来说都是如此。

方法论

敏捷发展

主要文章：敏捷软件开发

“敏捷软件开发”是指基于迭代开发的一组软件开发框架，在该框架中，需求和解决方案通过自组织跨职能团队之间的协作发展。该术语是在2001年创造的敏捷宣言被配制。

敏捷软件开发将迭代开发作为基础，但比传统方法提倡更轻松，以人为中心的观点。敏捷流程从根本上结合了迭代以及它为连续完善和提供软件系统提供的持续反馈。

敏捷模型还包括以下软件开发过程：[4]

持续集成

主要文章：持续集成

持续集成是将所有开发人员工作副本合并到共享的做法主线一天几次。[5]Grady Booch首先命名和建议的CI他的1991方法，[6]尽管他没有提倡每天整合几次。极端编程（XP）采用了CI的概念，并确实倡导每天多次整合一次 - 也许每天多达数十次。

增量发展

主要文章：迭代和渐进发展

可以接受各种方法来将线性和迭代系统开发方法结合起来，而每个方法的主要目的是通过将项目分解为较小的细分市场，并在开发过程中提供更大的变化来降低固有的项目风险。

增量发展有三种主要变体：[1]

  1. 进行了一系列迷你水域，在进行下一次增量之前，在系统的一小部分完成瀑布的所有阶段，或
  2. 在进行进化之前，定义总体需求
  3. 最初的软件概念，需求分析和建筑和系统核心的设计是通过瀑布定义的，然后是增量实现，最终在安装最终版本（工作系统）中。

快速应用开发

主要文章：快速应用开发
快速应用开发（RAD）模型

快速应用开发（RAD）是一种软件开发方法，有利于迭代发展和快速的建设原型而不是大量的前期计划。使用RAD开发的软件的“计划”与编写软件本身交织在一起。缺乏广泛的预先计划通常可以使软件的编写速度更快，并且可以更轻松地更改要求。

快速发展过程始于初步的发展数据模型和业务流程模型使用结构化技术。在下一阶段，使用原型验证了需求，最终可以完善数据和过程模型。这些阶段是迭代重复的。进一步的开发导致“用于构建新系统的合并业务需求和技术设计声明”。[7]

该术语首先用于描述由詹姆斯·马丁在1991年。根据Whitten（2003）的说法，它是各种合并结构化技术，尤其是数据驱动信息技术工程，采用原型技术来加速软件系统开发。[7]

快速应用程序开发的基本原则是：[1]

  • 关键目标是以相对较低的投资成本快速开发和交付高质量的系统。
  • 试图通过将项目分为较小的细分市场并在开发过程中提供更大的变化来减少固有的项目风险。
  • 旨在快速生产高质量的系统，主要是通过迭代原型制作（在开发的任何阶段），积极的用户参与和计算机化开发工具。这些工具可能包括图形用户界面（GUI）建筑商，计算机辅助软件工程（案例）工具，数据库管理系统（DBMS），第四代编程语言，代码生成器和面向对象的技术。
  • 关键重点是满足业务需求，而技术或卓越的技术或工程学的重要性较小。
  • 项目控制涉及优先考虑开发和定义交付截止日期或“时间表”。如果该项目开始滑倒，则重点是减少要求安装时间表的要求，而不是增加截止日期。
  • 通常包括联合申请设计（JAD），用户大量参与系统设计，通过结构化研讨会或电子促进的相互作用的共识建设。
  • 积极的用户参与是必须的。
  • 迭代生产软件，而不是抛弃原型。
  • 生成必要的文档，以促进未来的发展和维护。
  • 标准系统分析和设计方法可以安装在此框架中。

瀑布发展

主要文章：瀑布模型
软件开发过程的活动表示瀑布模型。还有其他几个模型可以代表此过程。

瀑布模型是一种顺序发展方法，其中开发被视为经过多个阶段的稳定向下流动（如瀑布）：

该方法的第一个正式描述通常被引用为发表的文章温斯顿·罗伊斯（Winston W. Royce）[8]1970年，尽管罗伊斯（Royce）在本文中没有使用“瀑布”一词。罗伊斯（Royce）作为一个有缺陷的无工作模型的示例提出了这一模型。[9]

基本原则是：[1]

  • 该项目分为顺序的相位，在相之间可以接受一些重叠和飞溅。
  • 重点是一次计划，时间表，目标日期，预算和整个系统的实施。
  • 通过广泛的书面文档，正式评论以及用户的批准/签署，在项目的生活中保持严格的控制。信息技术管理发生在开始下一阶段之前的大多数阶段结束。书面文档是每个阶段的明确交付。

瀑布模型是一种用于软件工程的传统工程方法。一旦完成后，严格的瀑布方法会阻止重新审视和修改任何以前的阶段。[根据谁？]纯瀑布模型中的这种“僵化”已成为其他更“灵活”模型的支持者的批评来源。它被广泛归咎于几个大规模政府项目超过预算，随着时间的流逝，有时由于没有预算的要求大型设计方法。[根据谁？]除非合同要求，否则瀑布模型在很大程度上被专门为软件开发开发的更灵活和多功能的方法所取代。[根据谁？]看批评瀑布模型.

螺旋发展

螺旋模型（Boehm，1988）
主要文章：螺旋模型

1988年Barry Boehm发布了正式的软件系统开发“螺旋模型”，结合了一些关键方面瀑布模型和快速原型制作方法论是为了结合优势自上而下和自下而上概念。它提供了许多人认为的关键领域的重点：其他方法论：故意的迭代风险分析，尤其是适合大型复杂系统。

基本原则是：[1]

  • 专注于风险评估和最大程度地降低项目风险，通过将项目分解为较小的细分市场，并在开发过程中提供更大的变化，并提供了评估风险并在整个生命周期中考虑项目延续的机会。
  • “每个周期都涉及通过相同的步骤，对于产品的每个部分以及其每个级别的详细级别的进展，从整体操作概念文档到每个单独程序的编码。”[10]
  • 每次围绕螺旋的旅行都会遍历四个基本像限：（1）确定迭代的目标，替代方案和约束，以及（2）评估替代方案；识别和解决风险；（3）从迭代中开发和验证可交付成果；（4）计划下一次迭代。[11]
  • 通过确定利益相关者及其“胜利条件”开始每个周期，并以审查和承诺结束每个周期。[12]

形状

Shape Up是一种软件开发方法。大本营在2018年。这是BaseCamp在内部开发的一系列原则和技术，以克服项目的问题，没有明确的目的。它的主要目标受众是远程团队。Shape Up没有估计和速度跟踪，积压或冲刺，与瀑布，敏捷， 或者Scrum。取而代之的是，这些概念被食欲，博彩和周期所取代。截至2022年，除了Basecamp外，采用形状的著名组织还包括Uservoice和Block。[13][14]

周期

通过试验和错误，Basecamp发现理想的周期长度为6周。这个6周的时间足够长，可以建立有意义的功能，并且仍然足够短，可以引起紧迫感。

成型

整形是准备工作之前的过程设计师和工程师。形状的工作阐明了解决方案的主要UI元素，标识了兔子孔，并概述了清晰的范围边界。它本来应该是粗糙的，并为建筑商（设计师和工程师）提供更精细的细节来解决，从而使建筑商可以行使其创造力并进行权衡。[15]使用在线文档解决方案的音调形式记录了形状的工作，该解决方案支持评论，使团队成员可以异步贡献技术信息。这样的评论对于发现可能破坏该项目的隐藏意外至关重要。

在一个周期开始之前，利益相关者持有投注表，并在其中审查了音调。对于每个音高，都决定下注或放下它。[16]

食欲

形状的方式决定了将多少时间分配给项目的时间与其他方法相反。Shape Up以食欲（例如6周）开始，并以该限制内传递的解决方案设计结束。胃口成为项目建筑商的艰难截止日期。[17]

建造

Shape Up是一个两轨系统，塑形器和构建器并行工作。在当前周期中正在塑造的工作可能会给设计师和工程师在未来的周期中构建。

认识到建筑物所带来的技术不确定性，使用图表来跟踪进度，该图表可视化山丘的隐喻，恰当地命名为山丘图。上坡阶段是建筑商仍在锻炼他们的方法，而下坡则是未知数被消除的地方。建筑商使用Basecamp上的交互式在线山丘图上积极和异步的自我报告进度吉拉，将重点从已完成或不对的状态转移到未知或解决问题。山丘图的使用取代了在Scrum中报告线性状态或看板站起来。[18][19]

高级方法论

其他高级软件项目方法包括：

过程元模型

一些 ”过程模型“是评估，比较和改善组织采用的特定过程的抽象描述。

  • 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
  • 软系统方法论 - 改善管理流程的一般方法
  • 方法工程 - 改进信息系统过程的一般方法
更多信息：过程模式

在实践中

适用于软件开发方法框架的三种基本方法。

多年来，各种此类框架都在发展，每个框架都有自己的公认优势和劣势。一个软件开发方法框架不一定适合所有项目使用。每个可用的方法论框架最适合基于各种技术，组织，项目和团队注意事项的特定项目。[1]

软件开发组织实施过程方法来减轻开发过程。有时，承包商可能需要采用的方法，例如美国国防工业，需要根据过程模型获得合同。描述选择，实施和监视软件生命周期的方法的国际标准是ISO/IEC 12207.

数十年的目标是找到可重复的可预测过程，以提高生产率和质量。有些人试图系统化或正式化设计软件的不规则任务。其他申请项目管理设计软件的技术。大量软件项目在功能，成本或交付时间表方面不符合他们的期望 - 请参阅失败和超额筹码的自定义软件项目列表对于一些值得注意的例子。

组织可能会创建一个软件工程流程组（SEPG），这是过程改进的焦点。该小组由具有不同技能的线条从业人员组成，是组织中每个人都参与软件工程流程改进的每个人的合作努力的中心。

特定的开发团队还可以同意编程环境详细信息，例如综合开发环境被使用一个或多个编程范例，编程样式规则或特定的选择软件库或者软件框架。这些细节通常不取决于模型或一般方法的选择。

软件开发生命周期（SDLC）

也可以看看

参考

  1. ^一个bcdefg医疗保险和医疗补助服务中心（CMS）信息服务办公室（2008年）。选择开发方法。网站。美国卫生与公共服务部（HHS）。重新验证：2008年3月27日。检索2008年10月27日。
  2. ^一个bGeoffrey Elliott（2004）全球业务信息技术：综合系统方法。皮尔逊教育。第87页。
  3. ^Suryanarayana，Girish（2015）。“软件流程与设计质量：战争拔河？”。IEEE软件.32（4）：7–11。doi：10.1109/女士2015.87.
  4. ^“软件开发过程”。 2020年8月19日。
  5. ^“持续集成”.
  6. ^Booch，Grady（1991）。面向对象的设计：应用程序.本杰明·卡明斯。 p。 209。ISBN 9780805300918。检索8月18日2014.
  7. ^一个b惠顿，杰弗里·L。；Lonnie D. Bentley，凯文·迪特曼（Kevin C. Dittman）。 （2003）。系统分析和设计方法。第六版。ISBN0-256-19906-X。
  8. ^Wasserfallmodell> Entstehungskontext，Markus Rerych，fürGestaltungs-und wirkungsforschung，tu-wien。2007年11月28日在线上访问。
  9. ^康拉德·韦瑟特（Conrad Weisert），瀑布方法：没有这样的东西！
  10. ^Barry Boehm（1996）。，“软件开发和增强的螺旋模型“。 在：ACM Sigsoft软件工程笔记（ACM）11（4）：14-24，1986年8月
  11. ^Richard H. Thayer，Barry W. Boehm（1986）。教程：软件工程项目管理。计算机社会出版社。第130页
  12. ^Barry W. Boehm（2000）。可可II的软件成本估算：第1卷.
  13. ^“杰森·弗里德（Jason Fried）的前言|形状”.basecamp.com。检索2022-09-11.
  14. ^“塑造只是一个不错的理论吗？”.好奇的实验室。检索2022-09-12.
  15. ^“塑造原理|形状”.basecamp.com。检索2022-09-11.
  16. ^“赌注，不是积压|塑造”.basecamp.com。检索2022-09-11.
  17. ^“交出责任|塑造”.basecamp.com。检索2022-09-11.
  18. ^“显示进度|形状”.basecamp.com。检索2022-09-12.
  19. ^“ Atlassian Marketplace”.marketplace.atlassian.com。检索2022-09-12.
  20. ^伦比克，丹尼尔；范·莱森（Van Lesen），塔莫（Tammo）（2016）。“在BPMN中为行为驱动的发展进行建模测试案例”。IEEE软件.33（5）：15–21。doi：10.1109/女士2016.117.S2CID 14539297.

外部链接