跳转到内容

软件工程/过程/方法论简介

来自维基教科书,开放的书籍,开放的世界

在软件工程中,软件开发方法论系统开发方法论是一个用于构建、规划和控制信息系统开发过程的框架。

软件开发方法论框架直到1960年代才出现。根据Elliott (2004)的说法,系统开发生命周期 (SDLC) 可以被认为是最古老的用于构建信息系统的正式化方法论框架。SDLC 的主要思想是“以非常谨慎、结构化和有条理的方式追求信息系统的开发,要求生命周期的每个阶段,从想法的产生到最终系统的交付,都必须以严格和顺序的方式执行”。[1]在应用框架的上下文中。这种方法论框架在1960年代的主要目标是“在大型企业集团时代开发大型功能性业务系统。信息系统活动围绕着大量数据处理和数字运算例程”。[1]

作为名词

[编辑 | 编辑源代码]

作为名词,软件开发方法论是一个用于构建、规划和控制信息系统开发过程的框架——这包括对项目团队为开发或维护应用程序而创建和完成的特定交付成果和工件的预定义。[2]

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

多年来,各种各样的框架不断发展,每个框架都有自己公认的优点和缺点。一个软件开发方法论框架不一定适合所有项目使用。每个可用的方法论框架最适合特定类型的项目,这取决于各种技术、组织、项目和团队方面的考虑。[2]

这些软件开发框架通常与某种组织绑定,该组织进一步开发、支持使用和推广方法论框架。方法论框架通常在某种正式文档中定义。特定的软件开发方法论框架(名词)包括

  • 自1998年以来的Rational Unified Process (RUP, IBM)。
  • 自2005年以来由Scott Ambler提出的Agile Unified Process (AUP)。

作为动词

[编辑 | 编辑源代码]

作为动词,软件开发方法论是组织和项目团队应用软件开发方法论框架(名词)的一种方法。特定的软件开发方法论(动词)包括

1970年代
  • 自1969年以来的结构化编程
  • Cap Gemini SDM,最初来自PANDATA,第一个英文翻译版本于1974年出版。SDM代表系统开发方法论
1980年代
  • 自1980年以来的结构化系统分析与设计方法论 (SSADM)
  • 信息需求分析/软系统方法论
1990年代
  • 面向对象编程 (OOP) 自1960年代初开始发展,并在1990年代中期发展成为一种主要的编程方法
  • 自1991年以来的快速应用开发 (RAD)
  • 自1990年代末以来的Scrum
  • 由Watts Humphrey在SEI开发的团队软件过程
  • 自1999年以来的极限编程

动词方法

[编辑 | 编辑源代码]

每个软件开发方法论框架都作为应用特定方法来开发和维护软件的基础。自信息技术起源以来,已经使用了多种软件开发方法。这些方法包括:[2]

  • 瀑布模型:一种线性框架
  • 原型设计:一种迭代框架
  • 增量:一种组合的线性迭代框架
  • 螺旋式:一种组合的线性迭代框架
  • 快速应用开发 (RAD):一种迭代框架
  • 极限编程

瀑布式开发

[编辑 | 编辑源代码]

瀑布模型是一种顺序开发方法,其中开发被视为稳定地向下流动(像瀑布一样)通过需求分析、设计、实现、测试(验证)、集成和维护的阶段。该方法的第一个正式描述通常被引用为 Winston W. Royce 于 1970 年发表的一篇文章 [3],尽管 Royce 在这篇文章中没有使用“瀑布”这个词。

基本原理是:[2]

  • 项目被分成顺序阶段,在阶段之间允许一些重叠和回溯。
  • 重点在于规划、时间表、目标日期、预算和一次性实施整个系统。
  • 通过广泛的书面文档、正式审查以及用户和信息技术管理部门在大多数阶段结束前开始下一个阶段之前进行的批准/签署,对项目生命周期进行严格控制。

原型设计

[编辑 | 编辑源代码]

软件原型设计,是在软件开发过程中进行活动的一种开发方法,即创建原型,即正在开发的软件程序的未完成版本。

基本原理是:[2]

  • 不是独立的完整开发方法论,而是一种处理更大、更传统开发方法论(例如增量、螺旋式或快速应用开发 (RAD))中选定部分的方法。
  • 试图通过将项目分解成更小的部分并在开发过程中提供更多易于更改的方式来降低固有的项目风险。
  • 用户在整个开发过程中都参与其中,这增加了用户接受最终实施的可能性。
  • 按照迭代修改过程开发系统的缩略模型,直到原型演变到满足用户的需求。
  • 虽然大多数原型都是为了被丢弃而开发的,但在某些情况下,可以从原型演变到工作系统。
  • 对基本业务问题的基本了解对于避免解决错误的问题是必要的。

增量开发

[编辑 | 编辑源代码]

各种方法都可以接受,用于组合线性系统和迭代系统开发方法论,每个方法的主要目标都是通过将项目分解成更小的部分并在开发过程中提供更多易于更改的方式来降低固有的项目风险。

基本原理是:[2]

  • 执行一系列迷你瀑布,其中系统的某个小部分完成了瀑布的所有阶段,然后继续到下一个增量,或者
  • 在进行系统的单个增量的演化式、小型瀑布式开发之前,将定义总体需求,或者
  • 通过瀑布式方法定义初始软件概念、需求分析以及架构和系统核心设计,然后进行迭代式原型设计,最终安装最终原型,即一个可工作的系统。

螺旋式开发

[编辑 | 编辑源代码]
螺旋模型。

螺旋模型是一种软件开发过程,它结合了设计和分阶段原型设计的元素,旨在结合自顶向下和自底向上概念的优势。

基本原理是:[2]

  • 重点是风险评估,通过将项目分解成更小的部分并在开发过程中提供更高的易变性来最大程度地降低项目风险,同时提供机会评估风险并在整个生命周期中权衡项目持续的考虑因素。
  • “每个周期都涉及通过相同的步骤序列进行进展,对于产品的每个部分及其每个精细程度,从整体操作概念文档到每个单独程序的编码”。[4]
  • 绕螺旋的每次循环都会遍历四个基本象限:(1)确定迭代的目标、备选方案和约束;(2)评估备选方案;识别和解决风险;(3)开发和验证迭代的可交付成果;以及(4)计划下一次迭代。 [4][5]
  • 每个周期都以识别利益相关者及其成功条件开始,并在每个周期结束时进行审查和承诺。 [6]

快速应用开发

[编辑 | 编辑源代码]

快速应用开发 (RAD) 是一种软件开发方法,它涉及迭代开发和原型构建。快速应用开发是最初用来描述詹姆斯·马丁在 1991 年引入的一种软件开发过程的术语。

基本原理是:[2]

  • 主要目标是以相对较低的投资成本快速开发和交付高质量系统。
  • 试图通过将项目分解成更小的部分并在开发过程中提供更多易于更改的方式来降低固有的项目风险。
  • 旨在快速生产高质量系统,主要通过迭代式原型设计(在开发的任何阶段)、积极的用户参与和计算机化开发工具。这些工具可能包括图形用户界面 (GUI) 构建器、计算机辅助软件工程 (CASE) 工具、数据库管理系统 (DBMS)、第四代编程语言、代码生成器和面向对象技术。
  • 重点是满足业务需求,而技术或工程卓越性则不那么重要。
  • 项目控制涉及优先考虑开发并定义交付期限或“时间箱”。如果项目开始出现问题,重点是减少需求以适应时间箱,而不是延长期限。
  • 通常包括联合应用设计 (JAD),其中用户通过结构化研讨会或电子协作来积极参与系统设计,达成共识。
  • 积极的用户参与至关重要。
  • 迭代地生成生产软件,而不是一次性原型。
  • 生成必要的文档以促进未来的开发和维护。
  • 标准系统分析和设计方法可以融入到这个框架中。

其他实践

[编辑 | 编辑源代码]

其他方法实践包括

  • 面向对象开发方法,例如格雷迪·布奇的面向对象设计 (OOD),也称为面向对象分析和设计 (OOAD)。布奇模型包括六个图:类图、对象图、状态转换图、交互图、模块图和过程图。 [7]
  • 自顶向下编程:由 IBM 研究员哈兰·米尔斯(和尼克劳斯·维尔特)在 20 世纪 70 年代发展起来的结构化编程。
  • 统一过程 (UP) 是一种迭代软件开发方法框架,基于统一建模语言 (UML)。UP 将软件的开发组织成四个阶段,每个阶段包含一个或多个在该开发阶段可执行的软件迭代:初始阶段、细化阶段、构建阶段和指导阶段。许多工具和产品存在于促进 UP 实施。UP 的一个更流行的版本是 Rational Unified Process (RUP)。
  • 敏捷软件开发是指一组基于迭代开发的软件开发方法,其中需求和解决方案通过自组织的跨职能团队之间的协作来发展。该术语是在 2001 年制定敏捷宣言时创造的。
  • 集成软件开发是指一个基于可交付成果的软件开发框架,使用三种主要的 IT(项目管理、软件开发、软件测试)生命周期,这些生命周期可以使用多种(迭代式、瀑布式、螺旋式、敏捷式)软件开发方法,其中需求和解决方案通过自组织的跨职能团队之间的协作来发展。

软件开发过程发展各种处理因此,软件开发不是一项容易的任务,它涉及各种处理。根据 IBM 研究:”软件开发是指专门用于该过程的一组计算机科学活动。

创建 设计 部署 支持 软件

子主题

[编辑 | 编辑源代码]

视图模型

[编辑 | 编辑源代码]
TEAF 视图和视角矩阵。

视图模型是一个框架,它提供了关于系统及其环境的观点,用于软件开发过程。它是一种图形表示,代表了视图的底层语义。

观点和视图的目的是使人类工程师能够理解非常复杂的系统,并将问题和解决方案的元素组织到专业领域。在对物理密集型系统进行工程设计时,观点通常对应于工程组织内的能力和职责。 [8]

大多数复杂的系统规范都非常广泛,以至于没有一个人能够完全理解规范的所有方面。此外,我们每个人对特定系统都有不同的兴趣,以及检查系统规范的不同原因。企业高管提出的系统构成问题与系统实施者提出的问题不同。因此,观点框架的概念是为了提供对特定复杂系统的规范的不同观点。这些观点都满足了对系统某些方面感兴趣的受众。与每个观点相关联的是一种观点语言,它优化了该观点受众的词汇和表示。

业务流程和数据建模

[编辑 | 编辑源代码]

当前信息状态的图形表示为用户和系统开发人员提供了一种非常有效的信息呈现方式。

业务流程和数据模型之间交互的示例。 [9]
  • 业务模型说明了与所建模业务流程相关的功能以及执行这些功能的组织。通过描绘活动和信息流,可以创建基础来可视化、定义、理解和验证流程的性质。
  • 数据模型提供了要存储的信息的详细信息,在最终产品是为应用程序生成计算机软件代码或准备功能规范以帮助计算机软件做出制造或购买决策时,主要使用数据模型。有关业务流程和数据模型之间交互的示例,请参见右侧的图。 [9]

通常,在进行称为业务分析的访谈后创建模型。访谈包括主持人提出一系列问题,旨在提取描述流程所需的信息。面试官被称为主持人,以强调信息是由参与者提供的。主持人应该对感兴趣的流程有一定的了解,但这不像拥有一个结构化的提问方法来询问流程专家那样重要。方法很重要,因为通常有一组主持人正在收集整个设施的信息,并且一旦完成,所有面试官的信息结果必须相互匹配。 [9]

模型的开发用于定义流程的当前状态,在这种情况下,最终产品称为“现状”快照模型,或者是一组关于流程应该包含哪些内容的想法的集合,从而形成一个“可能是什么”模型。流程和数据模型的生成可用于确定现有的流程和信息系统是否健全,只需要进行一些小的修改或增强,或者是否需要进行重新设计作为纠正措施。创建业务模型不仅仅是一种查看或自动化信息流程的方式。分析可以用来从根本上改变您的企业或组织开展业务的方式。[9]

计算机辅助软件工程

[edit | edit source]

计算机辅助软件工程 (CASE),在软件工程领域,是指将一套工具和方法科学地应用于软件,从而产生高质量、无缺陷且可维护的软件产品。[10] 它也指开发信息系统的方法以及可以在软件开发过程中使用的自动化工具。[11] 术语“计算机辅助软件工程”(CASE) 可以指用于自动化开发系统软件(即计算机代码)的软件。CASE 功能包括分析、设计和编程。CASE 工具自动化了在所需编程语言中设计、记录和生成结构化计算机代码的方法。[12]

计算机辅助软件系统工程 (CASE) 的两个关键理念是:[13]

  • 在软件开发和/或软件维护过程中促进计算机辅助,以及
  • 对软件开发和/或维护的工程化方法。

典型的 CASE 工具用于配置管理、数据建模、模型转换、重构、源代码生成和统一建模语言。

集成开发环境

[edit | edit source]
Anjuta,一个用于 GNOME 环境的 C 和 C++ IDE

集成开发环境 (IDE) 也称为集成设计环境集成调试环境,是一种软件应用程序,为计算机程序员提供全面的软件开发设施。IDE 通常由以下部分组成:

  • 源代码编辑器,
  • 编译器和/或解释器,
  • 构建自动化工具,以及
  • 调试器(通常)。

IDE 的设计目的是通过提供紧密结合的组件(具有相似的用户界面)来最大限度地提高程序员的生产力。通常,IDE 专注于特定编程语言,以便提供最符合该语言编程范式的功能集。

建模语言

[edit | edit source]

建模语言是指任何可以用它来表达信息或知识或系统的人工语言,其结构由一组一致的规则定义。这些规则用于解释结构中组件的含义。建模语言可以是图形化的或文本化的。[14] 图形建模语言使用带有名称的符号来表示概念,使用连接符号的线来表示关系,以及各种其他图形注释来表示约束。文本建模语言通常使用标准化关键字以及参数来创建可由计算机解释的表达式。

软件工程领域中图形建模语言的示例包括

  • 业务流程建模符号 (BPMN) 以及 XML 格式的 BPML 是流程建模语言的一个例子。
  • EXPRESS 和 EXPRESS-G (ISO 10303-11) 是国际标准通用数据建模语言。
  • 扩展企业建模语言 (EEML) 通常用于跨层业务流程建模。
  • 流程图是算法或逐步过程的示意性表示,
  • 基本建模概念 (FMC) 用于软件密集型系统的建模语言。
  • IDEF 是一系列建模语言,其中最著名的是 IDEF0 用于功能建模,IDEF1X 用于信息建模,IDEF5 用于本体建模。
  • LePUS3 是一种面向对象的视觉设计描述语言和正式规范语言,主要适用于大型面向对象(Java、C++C#)程序和设计模式的建模。
  • 规范和描述语言 (SDL) 是一种规范语言,针对的是对反应式和分布式系统的行为进行明确的规范和描述。
  • 统一建模语言 (UML) 是一种通用建模语言,是用于规范软件密集型系统的行业标准。UML 2.0 是当前版本,支持 13 种不同的图表技术,并且拥有广泛的工具支持。

并非所有建模语言都是可执行的,对于那些可执行的语言来说,使用它们并不一定意味着程序员不再需要了。相反,可执行建模语言旨在提高熟练程序员的生产力,以便他们能够解决更困难的问题,例如并行计算和分布式系统。

编程范式

[edit | edit source]

编程范式是计算机编程的基本风格,与软件工程方法论形成对比,软件工程方法论是解决特定软件工程问题的风格。范式在用于表示程序元素(如对象、函数、变量、约束……)的概念和抽象以及构成计算的步骤(赋值、求值、延续、数据流……)方面有所不同。

一种编程语言可以支持多种范式。例如,用 C++ 或 Object Pascal 编写的程序可以是纯粹的过程式的,也可以是纯粹的面向对象的,或者包含两种范式的元素。软件设计师和程序员决定如何使用这些范式元素。在面向对象编程中,程序员可以将程序视为相互交互的对象的集合,而在函数式编程中,程序可以被认为是一系列无状态函数求值。在对具有多个处理器的计算机或系统进行编程时,面向过程的编程允许程序员将应用程序视为一组作用于逻辑上共享的数据结构的并发进程。

正如软件工程中不同的群体提倡不同的方法论一样,不同的编程语言也提倡不同的编程范式。有些语言是为了支持一种范式而设计的(Smalltalk 支持面向对象编程,Haskell 支持函数式编程),而其他编程语言则支持多种范式(例如 Object Pascal、C++、C#、Visual Basic、Common Lisp、Scheme、Python、Ruby 和 Oz)。

许多编程范式因其禁止的方法而闻名,就像因其允许的方法而闻名一样。例如,纯函数式编程禁止使用副作用;结构化编程禁止使用 goto 语句。部分由于这个原因,习惯于早期风格的人往往将新的范式视为教条主义或过于僵化。citation needed 避免使用某些方法可以更容易地证明关于程序正确性的定理,或者只是更容易理解程序的行为。

软件框架

[edit | edit source]

软件框架是软件系统或子系统的可重用设计。软件框架可能包括支持程序、代码库、脚本语言或其他软件,以帮助开发和粘合软件项目的不同组件。框架的各个部分可以通过 API 公开。

软件开发流程

[edit | edit source]

软件开发流程是强加于软件产品开发的框架。同义词包括软件生命周期和软件流程。有几种这样的流程模型,每种模型都描述了在流程过程中进行的各种任务或活动的方法。

越来越多的软件开发组织实施流程方法论。其中许多组织来自国防行业,在美国,国防行业需要根据“流程模型”进行评级才能获得合同。描述选择、实施和监控软件生命周期的国际标准是 ISO 12207。

一个长期的目标是找到可重复、可预测的流程,以提高生产力和质量。一些人试图将编写软件的看似杂乱无章的任务系统化或形式化。另一些人则将项目管理方法应用于编写软件。如果没有项目管理,软件项目很容易延期或超支。由于大量软件项目在功能、成本或交付进度方面没有达到预期,有效的项目管理似乎是缺失的。

另请参阅

[edit | edit source]
列表
  • 软件工程主题列表
  • 软件开发理念列表
相关主题
  • 领域特定建模
  • 轻量级方法论
  • 对象建模语言
  • 结构化编程
  • 集成 IT 方法论

参考资料

[edit | edit source]
  1. a b Geoffrey Elliott (2004) 全球商务信息技术:集成系统方法。Pearson Education。第 87 页。
  2. a b c d e f g h 美国医疗保险和医疗补助服务中心 (CMS) 信息服务办公室 (2008)。选择开发方法。网络文章。美国卫生与公众服务部 (HHS)。重新验证:2008 年 3 月 27 日。2015 年 7 月 15 日检索。
  3. 瀑布模型 > 产生背景,Markus Rerych,维也纳科技大学设计与影响研究学院。2007 年 11 月 28 日在线访问。
  4. a b Barry Boehm (1996., "螺旋模型的软件开发和增强"。在:ACM SIGSOFT 软件工程笔记 (ACM) 11(4):14-24,1986 年 8 月
  5. Richard H. Thayer,Barry W. Boehm (1986)。教程:软件工程项目管理。IEEE 计算机协会出版社。第 130 页
  6. Barry W. Boehm (2000)。使用 Cocomo II 的软件成本估算:第一卷
  7. Georges Gauthier Merx 和 Ronald J. Norman (2006)。使用 Java 的统一软件工程。第 201 页。
  8. Edward J. Barkmeyer 等人 (2003)。自动化系统集成概念 NIST 2003。
  9. a b c d Paul R. Smith 和 Richard Sarfaty (1993)。使用计算机辅助软件工程 (CASE) 工具创建配置管理战略计划。 1993 年美国能源部/承包商和设施 CAD/CAE 用户组论文。
  10. Kuhn,D.L (1989)。"选择和有效使用计算机辅助软件工程工具"。年度西屋计算机研讨会;1989 年 11 月 6-7 日;宾夕法尼亚州匹兹堡(美国);美国能源部项目。
  11. P. Loucopoulos 和 V. Karakostas (1995)。系统需求工程。麦格劳希尔。
  12. CASE 定义 在:电信词汇 2000。2008 年 10 月 26 日检索。
  13. K. Robinson (1992)。将软件工程融入 CASE。纽约:约翰·威利父子公司。
  14. 何晓 (2007)。"图形建模语言符号的元模型"。在:2007 年计算机软件与应用大会。COMPSAC 2007 - 第 1 卷。第 31 届年度国际会议,第 1 卷,第 1 期,2007 年 7 月 24-27 日,第 219-224 页。
[编辑 | 编辑源代码]
华夏公益教科书