软件工程概论第二章：过程与生命周期模型

软件工程概论第二章：过程与生命周期模型

前言

用于西电软件工程专业软件工程概论课程复习使用，主要讲解了软件工程第二章过程与生命周期模型相关知识点，以下是完整版的知识点整理资源和相关复习资料，已传至CSDN下载中：复习资料下载地址

一、过程的含义

1.1、过程定义

过程是一系列涉及活动、约束和资源的步骤，这些步骤产生某种预期的输出。

1.2、过程特点

• 规定所有主要过程活动
• 使用资源，受制于一组约束（例如时间表）
• 生产中间产品和最终产品
• 可能由具有层次结构或链接的子流程组成(过程组织为层次结构，以便每个子过程有自己的过程模型)
• 每个流程活动都有进入和退出标准(这样就可以知道每个活动的开始和结束时间)
• 活动按顺序组织，所以时间很明确(知晓什么时候应该开始一个什么活动)
• 每个流程指导原则，包括每个活动的目标
• 约束可能适用于活动、资源或产品

1.3、过程的重要性

（1）生命周期的概念：涉及产品构建的过程
（2）软件的生命周期：描述了软件产品从概念到实现、交付、使用和维护的整个过程
（3）过程的重要性

• 对一组活动强加一致性和结构
• 指导我们了解、控制、检查和改进活动
• 使我们能够捕捉我们的经验并将其传递下去

1.4、软件开发过程

（1）、需求分析与定义——>系统设计——>程序设计——>编写程序——>单元测试——>集成测试——>系统测试——>系统交付——>维护

• 每个阶段本身就可以描述为一组活动的过程（或者一组活动）
• 每个活动包括约束、输出和资源（例如需求分析，以用户表述的功能和特征作为输入，输出就需求，约束就是产生需求说明文档的预算和进度，需求的种类和表示方法）
• 后续会讨论每一个阶段涉及的过程，资源，活动和输出，以及如何影响最终产品
• 每个过程都可以用不同的方式加以描述，例如文本，图等以表示过程特征

二、瀑布模型

2.1、核心思想

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期分为8个步骤，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

2.2、优点

（1）可强迫开发人员采用规范化的方法
（2）严格的规定了每个阶段必须提交的文档
（3）要求每个阶段交出的所有产品都必须是经过验证的。

2.3、缺点

• 瀑布模型最大的问题是不能反映实际的代码开发方式
• 瀑布模型中没有创建最终产品的迭代活动（大多数软件开发应用大量迭代）（一般开发是迭代的，因为可能面对没见过的问题，或者解决方案本身要随着业务情况或环境而改变，用户或开发人员都不完全了解影响期望结果的关键因素，所以或者停滞不前，或者反复重复）
• 没有提供如何在开发过程中处理产品和活动变更的指导（假设需求可以冻结）
• 将软件开发视为制造过程而不是创造过程
• 最终产品前的漫长等待

2.4、示意图

三、V模型

3.1、核心思想

• 编码为位于顶点，分析和设计在左边，测试和维护在右边
• 使用单元测试来验证程序设计
• 使用系统测试来验证架构（系统）设计
• 使用验收测试来验证需求
• 如果在验证和确认过程中发现问题，可以重新执行左侧的V，然后重新制定右侧的测试

3.2、优点

V模式使得隐藏在瀑布模型中的迭代和重做活动根据明确

3.3、缺点

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证

3.4、示意图

四、原型化模型

4.1、核心思想

它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

4.2、优点

（1）有助于满足用户真实需求
（2）原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确描述用户需求。
（3）软件产品的开发基本上是按线性顺序进行的
（4）建造出原型系统，开发人员可以加速软件开发过程，节约软件开发成本。

4.3、缺点

（1）所选用的开发技术和工具不一定符合主流的发展。
（2）快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
（3）使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

4.4、示意图

五、增量模型

5.1、增量模型核心思想

它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。

5.2、增量和迭代区别

• 增量开发：从小的功能子系统开始，并在每个新版本中添加功能
• 迭代开发：从完整的系统开始，然后随着每个新版本的发布更改每个子系统的功能

5.3、增量模型优点

（1）能在较短时间内向用户提交完成一些有用功能的工作产品。
（2）逐步增加产品的功能可以使用户有充裕的时间学习和适应新产品。
（3）项目失败风险较低
（4）优先级最高的服务首先交付，然后再将其他增量构建主次集成进来，这意味着，最重要的部分将接受最多测试。

5.4、增量模型缺点

与其他模型相比，需要更精心的设计。

5.5、示意图

六、螺旋模型

6.1、核心思想

螺旋模型是一种演化软件开发过程模型。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。

6.2、优点

（1）对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
（2）减少了过多测试或者测试不足带来的风险。
（3）维护只是模型的另一个周期，因此在维护和开发之间并没有本质区别。

6.3、缺点

要求开发人员必须具有丰富的风险评估经验和专门知识。

6.4、示意图

包括：制定计划，目标约束可选项，风险评估与分析，开发和测试

七、敏捷宣言

7.1、产生

20世纪70-90年代提出的开发方法，都是试图在软件构思、文档化、开发和测试过程中强加某种形式的严格性；90年代后期，就出现了抵制严格性的开发人员，强调灵活性的作用，即“敏捷宣言”

7.2、内容

• 重视个人和互动胜过流程和工具
• 更愿意花时间制作可工作的软件，而不是制作综合文档
• 专注于客户协作而不是合同谈判
• 专注于应对变化，而不是制定计划然后执行

7.3、总体目标

尽可能早地、持续地交付有价值的软件，使客户满意

7.4、实现方法

• 极限编程 (XP)： 激发开发人员规划，使管理最小化
• Crystal：基于每个项目都需要一组独特的策略和约定的概念的方法集合；人对软件质量有重要影响，交流与经常性交付，提高人的素质，软件质量也会提升。
• Scrum：30 天迭代； 多个自组织团队；日常“scrum”协调。
• 自适应软件开发 (ASD)：设立目标，围绕如何组织构建达成目标，变化包括在内。

7.5、极限编程(XP)

（1）特征：
沟通：客户和开发者之间的持续交流
简单：选择最简单的设计或实现
勇气：承诺尽早并经常交付功能
反馈：开发过程中内置于各种活动中的循环
（2）十二个方面：

• 现场客户 ( On-site Customer )
• 代码规范 ( Code Standards )
• 每周40小时工作制 (40-hour Week )
• 计划博弈 ( Planning Game )：要求结合项目进展和技术情况，确定下一阶段要开发与发布的系统范围。
• 系统隐喻 ( System Metaphor )：通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。
• 简单设计 ( Simple Design )
• 测试驱动 ( Test-driven )
• 代码重构 ( Refactoring )：代码重构是指在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。
• 成对编程 ( Pair Programming )
• XP：认为开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。
• 持续集成 ( Continuous Integration )：提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。
• 小型发布 ( Small Release )：强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。
  （3）过度极限问题：
  极限编程的实践是相互依赖的，需要很多人复盘当时的考虑（如果其中一个被修改，则会出现漏洞）
  表达为一组测试用例的需求必须由软件通过（系统通过了测试，但不是客户支付的费用）（用例不能完全代表需求，可能是面向解决方案的）
  重构的代价（很难在不降低其架构的情况下重新设计系统）

总结

第二章主要知识点是生命周期模型的优缺点以及核心思想，了解模型适用于什么样的软件开发。