软件工程结课论文敏捷开发在软件工程中的应用大学编程作业（TUST 天津科技大学 2022年）

本文由软件危机的产生开始，简要介绍了传统软件工程开发和敏捷开发的基本内容，根据现有软件工程模型的实际运用对比，列举出适合敏捷开发过程的应用场景，并对常用敏捷开发过程进行分析，为实现软件产品的轻量化开发管理交付提供了方法依据。这篇文章是我大三写的，现在回顾已经非常粗糙，分享出来一方面希望可以帮助初学者，另一方面希望能让同学们可以从目前大学中普遍毫无价值的形式主义作业中解脱出来，更加高效地学习优质计算

末影小黑xh

1273人浏览 · 2023-03-28 14:57:15

末影小黑xh · 2023-03-28 14:57:15 发布

软件工程结课论文敏捷开发在软件工程中的应用大学编程作业（TUST 天津科技大学 2022 年）

软件工程结课论文敏捷开发在软件工程中的应用大学编程作业（TUST 天津科技大学 2022 年）
- 一、论文简介
- 二、交流学习
软件工程结课论文敏捷开发在软件工程中的应用

一、论文简介

本文由软件危机的产生开始，简要介绍了传统软件工程开发和敏捷开发的基本内容，根据现有软件工程模型的实际运用对比，列举出适合敏捷开发过程的应用场景，并对常用敏捷开发过程进行分析，为实现软件产品的轻量化开发管理交付提供了方法依据。

这篇文章是我大三写的，现在回顾已经非常粗糙，分享出来一方面希望可以帮助初学者，另一方面希望能让同学们可以从目前大学中普遍毫无价值的形式主义作业中解脱出来，更加高效地学习优质计算机知识和主流编程技术，一起发扬开源精神，感受互联网技术的美好愿景。

二、交流学习

互联网开源精神需要大家一起互相交流学习，互相支持奉献。欢迎大家与我友好交流。

加我 QQ 好友获取所有项目源码和项目文档，感谢大家的支持！

软件工程结课论文敏捷开发在软件工程中的应用

【摘要】 本文由软件危机的产生开始，简要介绍了传统软件工程开发和敏捷开发的基本内容，根据现有软件工程模型的实际运用对比，列举出适合敏捷开发过程的应用场景，并对常用敏捷开发过程进行分析，为实现软件产品的轻量化开发管理交付提供了方法依据。

第一章引言

1.1 软件危机的背景

软件危机（software crisis），20 世纪 60 年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。

60 年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。

1968 年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机（Software crisis）一词。而 1960 年代中期开始爆发众所周知的软件危机，为了解决问题，在 1968、1969 年连续召开两次著名的 NATO 会议，并同时提出软件工程的概念。[文献 1]

1.2 软件工程的提出

软件工程在提出后，其目标便是付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用；开发的软件可靠性高。

软件工程概括来说，就是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本和改进算法。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型（paradigm）、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。

1.3 敏捷开发的提出

随着信息化技术的高速发展以及网络产品的普及，客户对于软件产品的版本稳定性及交付周期都提出了更为严格的要求，软件工程理念的引入正迎合了这一需求。

软件工程采用工程的概念、原理、技术、方法来开发与维护软件，利用软件工程模型整合资源、缩短开发周期，在实际运用中取得了良好效果。然而，在版本维护周期缩短，版本迭代速度提升的前提下，原有的软件工程模型在客户需求和开发时间的双重压力下，被开发负责人分解为多个相互联系也可独立运行的小模型并分别完成，在此过程中软件一直处于可使用状态，这就是敏捷开发。

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。[文献 2] 在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。本文通过分析软件工程模型的基础上，总结出敏捷开发应用的特点，在项目实际运用中具有参考价值。

第二章软件工程

2.1 软件工程的定义

软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

软件工程内涵有两部分：

一、软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下四个方面：

P（Plan）——软件规格说明。规定软件的功能及其运行时的限制。

D（DO）——软件开发。开发出满足规格说明的软件。

C（Check）——软件确认。确认开发的软件能够满足用户的需求。

A（Action）——软件演进。软件在运行过程中不断改进以满足客户新的需求。

二、从软件开发的观点看，它就是使用适当的资源（包括人员，软硬件资源，时间等），为开发软件进行的一组开发活动，在活动结束时输入（即用户的需求）转化为输出（最终符合用户需求的软件产品）。

2.2 软件工程的开发原则

软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

软件工程的原则有以下四项基本原则：

一、选取适宜开发范型，该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。因此，必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。

二、采用合适的设计方法，在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

三、提供高质量的工程支持，“工欲善其事，必先利其器”。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

四、重视开发过程的管理，软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。

2.3 软件工程的开发阶段

软件开发生命周期，亦叫做软件生命周期或者系统开发生命周期，是直到生命周期结束的软件生成生命周期。有问题定义，可行性分析，总体描述，系统设计，编码，调试和测试，验收。

将整个软件开发生命周期划分为多个阶段，以便每个阶段都有明确的任务，从而可以轻松地控制和管理具有大规模，复杂结构和复杂管理的软件开发。通常，软件开发周期包括可行性分析和开发计划，需求分析，设计（摘要设计和详细设计），编码，测试，维护等，可以按照适当的方式分配给不同的阶段：

一、需求阶段：

通过沟通交流，产出需求文档，包含页面的内容，则需要对应的进行设计稿的设计。通过评审会，使涉及到的人都有自己的了解，同时对需求进行改进。

二、开发阶段：

开发：编码，自行测试。

产品：对产品进行验收。

测试：编写测试用例，进行测试用例的评审会议。该阶段需要涉及人进行一个测试用例的评审会。

三、测试阶段：

测试人员根据测试用例进行测试，并进行问题反馈，编写测试报告，开发人员进行 bug 的修复，如有需求不确认的，再找分析/产品/PM 等进行确认。bug 修复完成后，测试再进行回归测试，同时测试还需要兼容性的测试，对依赖项或者机器都进行对应的测试。

灰度发布：（内部灰度，外部灰度）

为了防止在正式区发生问题，会有一个特定的环境，类似于线上环境，提供给到测试，防止后期出现问题，提前解决问题。

四、发布阶段：

发布阶段，为了防止会有依赖项出现问题，所以会对多台服务器进行控制，分批进行发布。

2.4 传统的软件工程模型分析

软件工程过程模型是一种策略，这种策略是由软件工程师在具体的实践工程活动当中设计并提炼出来，能够覆盖软件过程的基本阶段确定设计的方法、过程及工具。*[文献 3]*在实际中应用最多的软件工程模型主要包括瀑布模型、螺旋模型、迭代模型和原型模型，下表以表格的形式对这四种模型进行分析：

模型名称	形式	优势	劣势
瀑布模型	线性顺序模型。过程严格按照"需求一分析一设计一编码一测试"的步骤进行。每个阶段都要定义明确的产出物及验证准则。	可以保证软件产品具有较高的质量：保证提前发现和解决存在的缺陷；保证软件系统在整体上具有充分的把握，从而保证系统具备良好的可维护性和扩展性。	瀑布模型没有反馈环，难以完善和满足用户的需求，一旦需求发生变化后者需求增多，则瀑布模型就显示出了很大的劣势。
螺旋模型	螺旋模型每一次迭代仅仅包含了瀑布模型的某一个或者个阶段。	螺旋模型遵循了瀑布模型的模式，随着项目成本的逐渐增加，风险性则逐渐减小。有利于已有软件的重用，有助于把软件质量作为软件开发的重要目标。	缺点是对于风险评估比较困难。
迭代模型	迭代模型是指在进行较大规模的项目任务时，将迭代开发分为若干次，第一次迭代完成项目各阶段的基本业务，但是不包含较为复杂的业务和逻辑，通过第二个功能则针对相关的逻辑和业务逐渐补充完整并进行细化。	迭代模型能够较早得到用户的反馈，不断的测试和整合,是项目短期里程碑。主要适用于系统需求不稳定的情况，所包含的活动与瀑布模型一样，包括软件的需求分析和设计、代码生成测试及维护。	迭代周期以及每次迭代的内容难以规划，对于项目架构师要求较高。
原型模型	原型模型能够快速实现一个可以实际运作的系统初步模型，适用于有结构的系统或者需求不明确的系统。	原型模型是很好的启发方法，可以迅速地挖掘用户的需求并与用户达成一致，避免在签字时发现需求并不是客户所满意的东西。	没有反馈环。原型模型—服不单独采用，往往是与瀑布模型和迭代模型一起使用。

表 1 软件工程 4 种模型对比

由上表分析可知，在软件工程实际运用中，只采用单一种模型显然不能适应实际项目复杂的需求变更，采用各种模型组合开发的形式在实际运用中较为广泛，然而一些瀑布模型版本允许生命周期中相邻阶段的迭代，在大系统中肯定存在较晚阶段浮现的不能快速定位的问题，因而往往瀑布模型在实际运用中结束于大规模的迭代，那些迭代包括越来越多的生命周期阶段。生命周期的累加必然会造成开发周期的延长从而耽误交付时间，从而增加了软件开发的风险。因此采用面向对象的思想在传统软件模型基础上进行演进而产生的敏捷开发，就拥有了更多的应用场景。

第三章敏捷开发

3.1 敏捷开发的定义

称敏捷开发是一种从 1990 年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

3.2 敏捷开发的开发原则

一、快速迭代：

相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年发布仅 2~3 个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。

二、让测试人员和开发者参与需求讨论：

需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

三、编写可测试的需求文档：

开始就要用"用户故事"（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。

四、多沟通，尽量减少文档：

任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。

团队要确保日常的交流，面对面沟通比邮件强得多。

五、做好产品原型：

建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。

六、及早考虑测试：

及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。[文献 4]

3.3 敏捷开发的开发阶段

敏捷开发流程的八个步骤包括：

一、目标制定，目标对齐：

通过市场调研、业务思路、风险评估制定公司规划和目标，根据这一目标产生所有部门的目标并实现对齐。

二、产品规划：

产品研发部门根据目标制定产品关键路线图，这个路线图中分布着不同的产品特性和其完成时间。

三、组织产品待办列表：

产品规划产生的需求、客户需求、市场人员收集到的缺陷等将组成产品待办列表。

四、需求梳理：

然后产品负责人（Product Ower）对这个列表进行梳理，并在需求梳理会（Backlog Grooming Meeting）讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，输出本次迭代的待办事项列表，完成优先级排序等工作。

五、迭代规划：

通过 Sprint 计划会，明确要执行的工作、冲刺目标等。

六、迭代开发：

期间会进行每日站会、性能测试、CodeReview、Demo、测试等工作。

七、Sprint 评审：

由每个任务的负责人演示其完整的工作，由 PO 确定 Sprint 目标是否完成，版本什么时候对外发布，新增 bug 的紧急程度等等。

八、开回顾会议：

回顾会议由 Scrum 团队检视自身在过去的 Sprint 的表现，包括人、关系、过程、工具等，思考在下一个 Sprint 中怎么样可以表现得更好，更高效，怎么样可以和团队合作地更愉快。

敏捷开发的流程图

图 1 敏捷开发的流程图

3.4 敏捷开发过程的典型代表

面向对象的思想是把系统定义为一组正在交互的对象，是一种不同以往的思考形式。敏捷开发所遵循的基本价值观可以总结为以下几点：

开发团队和他们之间的交互比开发过程和所使用的工具更重要。

在软件产品上多下功夫比广泛的文档编制更重要。

在开发过程中间客户的良好协作比签订合同的谈判更重要。

积极面对需求的变更比实现一个完美的计划更重要。

在这一价值观引导下，敏捷开发的开发过程主要是：

3.2.1 极限编程（Extreme Programming，XP）

极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合，使软件能够快速开发出来并向客户提供最高效益*[文献 5]*。极限编程的极限就在于它将众所周知的软件开发"最佳实践"都发挥到极致：

计划游戏：在需求和实现间取得平衡。

小版本：在每个迭代周期交付可执行的版本，根据客户提供的评价获得反馈。

简单设计：只设计立刻需要的东西。

测试：程序员编写单元测试,使得他们对程序的信心成为程序的一部分。

重构：更改现有程序从而使添加功能变得简单。

结对编程：所有的生产代码都由两个人使用同一台计算机完成。

集体所有权：任何人有发现改进代码的机会，马上执行改进。

持续集成：几个小时的开发后对代码进行集成和测试。

现场客户：真实的客户同开发团队坐在一起，随时回答问题。

编码标准：人员交换和代码重构的要求，追求最小工作量。

极限编程（Extreme Programming，XP）的流程图

图 2 极限编程（Extreme Programming，XP）的流程图

3.2.2 Scrum（迭代式增量软件开发过程）

Scrum 是一种迭代的增量化过程，用于产品开发或工作管理，其将项目分成短期迭代，或者"短跑"（sprints）,每个 sprint 在开发团队和团队管理间有个短会跟踪进展，在每个 sprint 期间开发目标保持不变*[文献 6]*。在一个 sprint 运作期间，新需求的加入会规划到下一个 sprint 中去，从而保证每个 sprint 中的开发目标保持不变。

Scrum 是一种对已存在系统的管理、提高和维护方法，在 Scrum 中发布产品的重要性高于一切，其主要关注项目的客户需求、时间压力、竞争、质量、版本和资源。

Scrum（迭代式增量软件开发过程）的流程图

图 3 Scrum（迭代式增量软件开发过程）的流程图

3.2.3 RUP（统一软件开发过程）

RUP 将一个项目分解成多个开发周期，将每个开发周期分解成多个阶段：先启阶段、精化阶段、构建阶段和移交（产品化）阶段。每个阶段由依次的开发迭代组成，每个迭代产生可执行的产出物。RUP 在软件开发中确定了一系列的"工作流"：业务建模、需求、分析、设计、实现、测试、部署、配置和变更管理、项目管理、环境管理。所有的工作流在每个阶段都会涉及。

RUP 在每个阶段为每个开发成员都提供了行为准则、模板和工具指导，建立了简洁和清晰的过程结构，为开发过程提供较大的通用性，但是 RUP 只是一个过程，没有涵盖软件工程的全部内容。例如缺少软件运行和支持方面的内容*[文献 7]*，在实际运用中可以结合软件工程的整体计划进行改进。

RUP（统一软件开发过程）的流程图

图 4 RUP（统一软件开发过程）的流程图

3.2.4 Crystal（水晶方法）

水晶方法组由一系列以人为本、自适应、超轻型、可伸缩的软件开发方法构成。Crystal 方法不仅考虑最佳理论，而且考虑切实可行，因此希望获得好的折衷并最终满足大批需求而取得成果。过程的形式由项目的大小和种类比例决定，Crystal 经验包括：

强调一组：不同项目需要不同方法;

两个主要变数：开发团队人数和可靠性要求;

注重人性：考虑开发者不易遵循严格方法，强调不很严格但仍能保证成功和容易执行的方法。

Crystal 可以说是最轻的一类方法，但不惜对迭代过程后期评审加载以及早发现问题和及时纠正，强调对过程的监控，使开发过程呈现出定制化的特定，是非常人性化的开发方式。

Crystal（水晶方法）的流程图

图 5 Crystal（水晶方法）的流程图

第四章总结

在实际软件项目中，只要项目具有一定规模，不论是设计、开发、测试、部署各个阶段都会有分解任务给不同人员，而且这些阶段本身也属于一种任务的分解，在不同人员间分解任务就不可避免的引发额外的沟通成本——培训和相互沟通。因为软件开发本质上是一项系统工作——错综复杂的关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。

软件开发中时间再多一件事情也不可能做的完美，但总有时间做完一件事情。软件开发领域，永远不可能完美，所以建议我们先把事情做完。这就是敏捷的思想。先把事情做了，再去逐步逼近完美。所以敏捷管理主张持续交付，快速迭代，及时反馈，立刻验证，持续优化。

在实际系统项目运用中，是否采用敏捷开发要依据项目规模进行选择。对于系统项目（软硬件结合）：要采用软件工程的理论进行宏观分析，比如采用瀑布+迭代+风险管控的方式进行规划，而在实际实现阶段则可引入敏捷开发的理念，实现轻量化管理交付；对于纯软件项目则可直接进行规模分解根据软件规模选择敏捷开发中的开发过程，从而根据实际情况进行差异化开发。