(CEN)第二章软件工程与需求工程

需求工程的内容：
需求工程
需求开发
需求管理
需求获取
编写规格 说明
建立基线
需求跟踪
需求建模
需求验证
Hale Waihona Puke Baidu
变更控制
Pressman的需求工程过程： Roger Pressman从需求开发过程 的角度，提出的需求工程过程包括 以下步骤： 导出需求：理解客户的要求 需求分析和协商：分析需求，协 商出合理的解决方案 需求规范：明确解决方案，使其 明白无误。 系统建模 需求确认：确认规范 需求管理
最后集成造成较大的风险。由于过程中的线 性传递特点，常常在集成中出现问题时就已为 时太晚。最后会发现前期未发现的错误或设计 缺陷，由于没有时间恢复而增加了风险。 它是文档驱动的，文档工作量非常大。 当瀑布模型必须面对范围管理的挑战时，就 显得力不从心了。如果把这个模型应用于大范 围的项目时，会出现最后期限到来时，没有任 何实质性的成果，系统集成和测试被迫推迟或 放弃，在前期需求规格说明、设计和编码中可 观的投入未能产生有效的成果，没有任何可提 交的产品。
采用瀑布模型需要具备的项目特征: 在系统开发前要对需求有完整、全面、清晰 的了解。 上述需求不存在隐含的不可克服的风险。 需求变更不能过于频繁。 不同涉众的需求互相兼容，不存在明显的冲 突。 开发团队掌握了解决需求问题的有效方法。 开发期限允许分阶段地串行工作。
(2)快速原型模型 ：RAD（快速 应用开发模型）是原型模型的一 种特殊模型
5. 列出互相满足要求的选项
6. 研究折衷选项
7. 预期管理
8. 将达成的协议融入规格说明 和计划中
9. 重复步骤1-8，直到产品完 全开发完成
10. 面临和解决新的风险项目
1、确定重要的涉众
2、确定满足涉众要求的条件
3、确定满足要求的条件中的冲突因素 4、协商满足各方要求的高层会议 5、列出互相满足要求的选项 6、研究折中选项 7、预期管理
需求工程的方法 面向过程 面向数据 面向控制 面向对象
1. 需求获取
2. 需求分析
3. 需求规格说明
4. 系统建模
5. 需求确认
6. 需求管理
Boehm的需求工程过程：
1. 确定重要的涉众
2. 确定满足涉众要求的条件
3. 确定满足要求的条件中的冲 突因素
4. 协商满足各方要求的高层协议
RUP的迭代开发模式
多次迭代
RUP的优点: 降低了在一个增量上的开支风险。如果开发人 员重复某个迭代，那么损失只是这一个开发有误 的迭代的花费。 降低了产品无法按照既定进度进入市场的风险。 通过在开发早期就确定风险，可以尽早来解决而 不至于在开发后期匆匆忙忙。 加快了整个开发工作的进度。因为开发人员清 楚问题的焦点所在，他们的工作会更有效率。 由于用户的需求并不能在一开始就作出完全的 界定，它们通常是在后续阶段中不断细化的。因 此，迭代过程这种模式使适应需求的变化会更容 易些。
采用RAD模型的项目特征: 系统可模块化（基于组件的结构）和可 缩放。 用户能参与到整个生命周期中。 项目开发周期很短通常约60天。 项目团队熟悉问题领域，能熟练使用开 发工具。
（3）螺旋模型
螺旋模型的优点： 能够及时找到项目存在的风险，避免 因为克服不了的困难而造成大的损失。 使用户能够尽早将信息经常反馈给开 发人员，保证了产品的正确性和高质量。 可以方便地评估和验证每次迭代的成 果；实现从开发到维护的无缝连接。
RUP的缺点:
RUP只是一个开发过程，并没 有涵盖软件过程的全部内容，例如 它缺少关于软件运行和支持等方面 的内容 它没有支持多项目的开发结构， 这在一定程度上降低了在开发组织 内大范围实现重用的可能性。
RUP的核心概念
(5)喷泉模型 喷泉模型是一种以用户需求为动 力，以对象为驱动的模型，主要用于 描述面向对象的软件开发过程。 该模型认为软件开发过程自下而 上周期的各阶段是相互重叠和多次反 复的，就像水喷上去又可以落下来， 类似一个喷泉。各个开发阶段没有特 定的次序要求，并且可以交互进行， 可以在某个开发阶段中随时补充其他 任何开发阶段中的遗漏。
特例：RAD模型图
开 发 工 作 量 用户描述 需求计划 结束 构建
时 间
RAD模型(快速应用开发模型)的优 点: 采用高效率的开发工具，从而减 少了整个产品的开发周期。提高了 生产率，降低了成本。 用户能够持续地参与开发，提高 了用户参与程度，从而使用户的满 意度上升，保证了系统能够满足用 户的需要。 工作重点从文档转为构建，所见 即所得 。
RAD模型的缺点: 如果用户不能持续地参与整个生命周期 中，最终产品会受到负面影响。 要求系统能适当模块化，如果没有可重 用的组件，它的效率就会下降。 盲目应用时，会缺乏成本概念和项目完 成的时间限制。项目有永远不能完结的风 险。 对于大型的、但可伸缩的项目，RAD 需 要足够的人力资源以创建足够的RAD 组。 RAD 要求承担必要的快速活动的开发者 和用户在一个很短的时间框架下完成一个 系统。如果两方中的任何一方没有完成约 定，都会导致RAD 项目失败。
瀑布模型的缺点 （一）: 它有内在的线性顺序，尝试重新使 用两个或更多阶段来改正一个问题或 缺陷，会导致成本上升和进度安排上 工作量的急剧增加。 它不能准确反映软件开发中解决问 题的特点。各阶段严格与活动一致， 而不管开发团队的实际工作如何。 它的状态和进展容易给人以错觉， 实际工作中“完成50%的工作”对项 目经理来说并无实际意义。
RUP的核心工作流（二）
3个核心支持工作流 配臵和变更管理（Configuration & Change Management） 项目管理（Project Management） 环境（Environment）
RUP的裁剪 确定本项目需要哪些工作流。RUP的9个核心 工作流并不总是需要的，可以取舍。 确定每个工作流需要哪些制品。 确定4个阶段之间如何演进。确定阶段间演进要 以风险控制为原则，决定每个阶段要哪些工作流， 每个工作流执行到什么程度，制品有那些，每个 制品完成到什么程度。 确定每个阶段内的迭代计划。规划RUP的4个 阶段中每次迭代开发的内容。 规划工作流内部结构。工作流涉及角色、活动 及制品，它的复杂程度与项目规模即角色多少有 关。最后规划工作流的内部结构，通常用活动图 的形式给出。
需求工程的涉众。 需求工程方法大致分为四类：面向过 程、面向数据、面向控制、面向对象。 面向对象的需求工作流包括：问题分 析，理解涉众需要，定义系统，管理项 目规模，改进系统定义。 软件需求过程的改进具有以下两个主 要目标：解决在以前项目或目前项目中 遇到的问题；防止和避免你可能在将来 的项目中要遇到的问题。 需求过程改进路线图。
螺旋模型的缺点： 如果项目本身是低风险的或者规 模较小，采用该模型可能产生昂贵 的成本。每一次螺旋结束后评估风 险的时间及人工耗费都较大。 模型本身比较复杂，开发人员和 用户难于掌握。 大量的中间阶段会产生额外的内 外部文档。 难以定义每阶段的目标。
采用螺旋模型的项目特征： 适用于大型项目；更适用于内部开发 （指没有外包的开发内容）。 用于新功能、新产品或需要采用新技 术时。 收益不确定，项目不能确保成功时。 用户不能确定其需求或需求很复杂时。
喷泉模型的优点： 喷泉模型不像瀑布模型那样，需 要分析活动结束后才开始设计活动， 设计活动结束后才开始编码活动。 该模型的各个阶段没有明显的界 限，开发人员可以同步进行开发。 可以提高软件项目开发效率，节 省开发时间，适应于面向对象的软件 开发过程。
喷泉模型的缺点：
由于喷泉模型在各个开发阶段 是重叠的，因此在开发过程中需 要大量的开发人员，因此不利于 项目的管理。 此外这种模型要求严格管理文 档，使得审核的难度加大，尤其 是面对可能随时加入各种信息、 需求与资料的情况。
瀑布模型的缺点 （二）: 实际的项目很少按照该模型给出的顺 序进行。虽然瀑布模型能够容许迭代， 但却是间接的。结果，在项目组的开发 过程中变化可能引起混乱。 用户常常难以清楚地给出所有需求， 而瀑布模型却要求如此，它还不能接受 在许多项目的开始阶段自然存在的不确 定性。
开发者常常被不必要地耽搁。在对 实际项目的分析中，Bradac ［BRA ,1994］发现传统生命周期的 线性特征会导致“阻塞状态”，其 中某些项目组成员不得不等待组内 其他成员先完成其依赖的任务。事 实上，花在等待上的时间可能会超 过花在开发工作上的时间。阻塞状 态经常发生在线性顺序过程的开始 和结束。
（4）统一软件过程 （RUP： Rational Unified Process）
RUP的核心工作流（一）
6个核心过程工作流 商业建模（Business Modeling ） 需求（Requirements） 分析和设计（Analysis & Design） 实现(Implementation) 测试（Test） 部署（Deployment）
形式化方法的缺点: 形式化规约主要关注于功能和数据，而 问题的时序、控制和行为等方面却更难于 表示。 使用形式化方法来建立规约比其他分析 方法更难于学习 。 形式化模型的开发目前还很费时和昂贵。 因为很少有软件开发者具有使用形式化 方法所需的背景知识，所以尚需多方面的 培训。 难以使用该模型与用户进行交流沟通， 因为几乎所有的用户对其一无所知。
第二章 软件工程 与需求工程
2.1软件开发过程模型 主要软件生命周期模型: 瀑布模型 快速原型模型（特例RAD） 螺旋模型 RUP 喷泉模型 形式化方法
(1) 瀑布模型 （Waterfall Model）
瀑布模型的优点: 客户很容易熟悉该模型。 以有序的方式解决复杂的问题，易于 理解，目标简单—完成所需要的活动。 可以严格控制项目进程，使项目管理 易于实施。 方便按阶段设臵里程碑，便于项目跟 踪。 定义了质量控制过程。运用该过程来 确定系统的质量。
喷泉模型主要用于面向对象的软件 项目，软件的某个部分通常被重复多次， 相关对象在每次迭代中随之加入渐进的 软件成分。 各活动之间无明显边界，例如设计和 实现之间没有明显的边界，这也称为 “喷泉模型的无间隙性”。 由于对象概念的引入，表达分析、 设计及实现等活动只用对象类和关系， 从而可以较容易地实现活动的迭代和无 间隙。
形式化方法的优点: 形式化规约可以用数学方法研究， 而非形式化方法则不能。 某些形式的不完整性和不一致性可 以被自动地检测 。 形式化方法提供了规约环境的基础， 它使得所生成的分析模型比用传统的 或面向对象的方法生成的模型更完整、 一致和无二义。集合论和逻辑符号的 描述使得软件工程师能创建清晰的关 于事实(需求)的陈述。
（6）形式化方法
A 形式化方法模型包含了一组活动，它 们带来了计算机软件用数学说明描述的 方法。形式化方法使得软件工程师能够 通过采用一个严格的、数学的表示体系 来说明、开发和验证基于计算机的系统。 B 支配形式化方法的基本概念是：
数据不变式。—个条件表达式，它 在包含一组数据的系统的执行过程中 总保持为真； 状态。系统访问和修改的存储数据； 操作。系统中发生的动作，以及对 状态数据的读或写。每一个操作是和 两个条件相关联的：前臵条件和后臵 条件。 离散数学。与集合和构造性规约、 集合运算符、逻辑运算符、以及序列 相关联的符号体系，形成了形式化方 法的基础。这些数学在形式化规约语 言，如Z 语言中被实现。
2.2 需求工程 需求工程是指应用已证实有效的技术、方 法进行需求分析，确定客户需求，帮助分 析人员理解问题并定义目标系统的所有外 部特征的一门学科。 完整的软件需求工程包括需求开发和需求 管理两个部分，需求开发的一般过程分为 需求获取、需求建模、需求规格说明、需 求验证四个阶段，需求管理则主要包括需 求基线的建立、需求变更控制以及需求跟 踪等活动。 需求工程过程被认为是建立软件系统最重 要的方面之一。在项目中，它涵盖了与需 求相关的所用活动。