软件工程讲义_第二章

软件工程是一种层次化的技术。任何工程方法必须构 建在质量承诺的基础上。 软件工程的基础是过程层。软件过程将各个技术层次 结合在一起，使得合理、及时地开发计算机软件成为 可能。 软件工程方法为构建软件提供技术上的解决方法。 软件工程工具为过程和方法提供自动化或半自动化的 支持。
软件过程
软件过程是工作产品构建时所执行的一系 列活动、动作和任务的集合。 活动主要实现宽泛的目标，与应用领域、 项目大小、结果复杂性或者实施软件工程 的重要程度没有直接关系。 动作包含了主要工作产品生产过程中的一 系列任务。 任务关注小而明确的目标，能够产生实际 产品。

增量模型

增量模型以迭代的方式运用瀑布模型。随 着时间的推移，增量模型在每个阶段运用 线性序列。每个线性序列生产出一个软件 的可交付增量。
增量模型
课本图2-5 增量模型
增量模型的使用方法
软件被作为一系列的增量来进行开发，每 一个增量都提交一个可以操作的产品，可 供用户评估。 第一个增量往往是核心产品：满足了基本 的需求，但是缺少附加的特性。 客户使用上一个增量的提交物并进行自己 评价，制定下一个增量计划，说明需要增 加的特性和功能。 重复上述过程，直到最终产品产生为止。

增量模型应用举例

应用举例：开发一个类似于Word的字处 理软件。 – 增量1：提供基本的文件管理、编辑和 文档生成功能。 – 增量2：提供高级的文档编辑功能。 – 增量3：实现拼写和语法检查功能。 – 增量4：完成高级的页面排版功能。
增量模型的优点
提高对用户需求的响应：用户看到可操作 的早期版本后会提出一些建议和需求，可 以在后续增量中调整。 人员分配灵活：如果找不到足够的开发人 员，可采用增量模型，早期的增量由少量 人员实现，如果客户反响较好，则在下一 个增量中投入更多的人力。 可规避技术风险：不确定的功能放在后面 开发。

过程模型
所有的过程模型都可用前述的过程框架概 括。过程模型的适用性是成功的关键，不 同的模型在一些方面有很大区别。 惯用过程模型：强调对过程活动和任务的 详细定义、识别和应用。 敏捷过程模型：强调项目的灵活性，并在 一些基本原则的指导下，采用非正式的方 式执行软件过程。

软件工程实践

实践的精髓

使用方法二：把原型系统作为需求分析的工具，明 确需求后，原型系统被抛弃。
原型开发应用举例

应用举例：开发一个教务管理系统。




第一次迭代：完成基本的学籍管理、选课和成绩管理 功能。（6周） 客户反馈：基本满意，但是对大数据量运行速度慢效 率，不需要学生自己维护学籍的功能等。 第二次迭代：修改细节，提高成绩统计和报表执行效 率（2周）。 客户反馈：需要严格的权限控制，报表打印格式不符 合要求。 第三次迭代：完善打印和权限控制功能。（2周） 客户反馈：可以进行正式应用验证。

运用瀑布模型遇到的问题

实际的项目很少遵守瀑布模型提出的 顺序。 客户通常难以清楚地描述所有的需求。 客户必须要有耐心，只有在项目接近 尾声的时候，他们才能得到可执行的 程序。
瀑布模型的适用场合
需求相当稳定，客户需求被全面的了解风 险管理。 开发团队对于这一应用领域非常熟悉。 外部环境的不可控因素很少。 小型清晰的项目或长周期的项目。
软件过程
软件过程可定义为一个为建造高质量软件 所需要完成的活动、动作和任务的框架。 软件过程定义了软件开发中采用的方法， 但软件工程还包含该过程中应用的技术 （技术方法和自动化工具）。 软件工程是由有创造力、用知识的人完成 的，他们根据产品构建的需要和市场需求， 选取成熟的软件过程。

通用过程模型
原型开发的优点
快速开发出可以演示的系统，方便了客户 沟通。 采用迭代技术能够使开发者逐步弄清客户 的需求。

原型开发存在的问题
软件工程实践
软件过程

软件同其他资产一样，是知识的具体体现，而 知识最初都是以分散的、不明确的、隐蔽的且不 完整的形式广泛存在的，因此，软件开发是一个 社会学习的过程。软件过程是一个对话，在对话 中，软件所必需的知识被收集在一起并在软件中 实现。过程提供了用户与设计人员之间、用户与 不断演化的工具之间以及设计人员与不断演化的 工具（技术）之间的交互途径。软件开发是一个 迭代的过程，在这个过程中，演化的工具本身就 作为沟通的媒介，每新一轮对话都可以从参与的 人员中获得更有用的知识。[BAE98]

原型开发模型

很多时候，客户提出了软件的一些基本功 能，但是没有详细定义输入、处理和输出 需求。另一种情况下，开发人员可能对算 法的效率、操作系统的兼容性和人机交互 的形式等情况不确定。在这些情况下，原 型开发范型是较好的解决方法。
原型开发模型
图2-6 原型开发模型
原型模型的使用方法

使用方法一：

瀑布模型

瀑布模型(the waterfall model)，又被 称为经典生命周期，它提出了一个系统的、 顺序的软件开发方法，从用户需求规格说 明开始，通过策划、建模、构建和部署的 过程，最终提供一个完整的软件并提供持 续的技术支持。
瀑布模型
沟通
项目启动 需求获取
策划
项目估算 进度计划 项目跟踪
1.理解问题（沟通和分析） 2.计划解决方案（建模和软件设计） 3.实施计划（代码生成） 4.检查结果的正确性（测试和质量保证）

7个关注软件工程整体实践的核心原则 第1原则：存在价值 对用户是否有用 ?? 第2原则：保持简洁简洁不是简化不是快速和粗糙 ?? 第3原则：维护视图清晰的视图是软件项目成功的基础 ?? 第4原则：关注使用者让别人明白你在做什么 ?? 第5原则：面向未来设计不要限于一隅但不要过分 ?? 第6原则：计划复用复用省时省力但也有代价 ?? 第7原则：认真思考动手之前要认真思考 ??
过程模式
软件过程可以定义为一系列模式的组合， 这些模式定义了一系列的软件开发中需要 的活动、动作、工作任务、工作产品及其 相关的行为[AMB98] 通俗地讲，过程模式提供了一个模板—— 一种描述软件过程中重要特征的一致性方 法。通过模式组合，软件团队可以定义能 最好满足项目需求的开发过程。

过程模式模板[AMB98]
模式名称：应能清楚地表述该模式在软件过程中的功能。 目的：简洁地描述模式的目的。 类型：定义模式类型。 启动条件：描述模式应用的前提条件。 问题：描述模式将要解决的问题。 解决办法：描述模式的实现。 结束条件：描述模式成功执行之后的结果。 相关模式：以层次或其他图的方式列举与该模式相关的 其他模式。 已知应用实例：介绍该模式的具体实例。

过程框架

过程框架定义了若干个小的框架活动， 为完整的软件开发过程建立了基础。 这些框架活动可广泛应用于所有软件 开发项目。
通用框架活动
沟通：包含了与客户(和其他共利益者)之间大 量的交流和协作，还包括需求获取以及其他相关 活动。 策划：指为后续的软件工程工作制定计划。它 描述了需要执行的技术任务、可能的风险、资源 需求、工作产品和工作进度计划。 建模：它包括创建模型和设计两方面。创建模 型有助于客户和开发人员更好地理解软件需求； 设计可以实现需求。 构建：它包括编码(手写或自动生成)和测试。 部署：软件(全部或者完成的部分)交付到用户， 用户对其进行评测并给出反馈意见。

通用框架活动

对许多项目来说，随着项目的的开展，框 架活动可以迭代应用。即，在项目的多次 迭代过程中，沟通、策划、建模、构建、 部署等活动不断重复。每次项目迭代都会 产生一个软件增量，每个软件增量实现了 部分的软件特性和功能。随着每一次增量 的产生，软件逐渐完善。
普适性活动
软件项目跟踪和控制 风险管理 软件质量保证 正式技术评审 测量 软件配置管理 可复用管理 工作产品的准备和生产

增量模型存在的问题
每个附加的增量并入现有的新增量时应简单、方便 ——该类软 件的体系结构应当是开放的。 仍然无法处理需求发生变更的情况。 管理人员须有足够的技术能力来协调好 各增量之间的关系。

演化过程模型
演化模型是迭代的过程模型，使得软件工 程师能够逐步开发出更完整的软件版本。 迭代的思想：对一系列活动的重复应用， 用以评估一系列论断，解决一系列风险， 达成一系列开发目标，并逐步增量地建立 并完善一个有效的解决方案。 常见的演化过程模型有原型开发、螺旋模 型等。

过程模式

过程模式提供了一种有效的机制来描述各 种软件过程。模式使得软件工程组织能够 从高层抽象开始，开发层次化的过程描述。 高层抽象描述又进一步细化为一系列步骤 模式以描述框架活动，然后每一个步骤模 式又进一步逐层细化为更详细的任务模式。 过程模式一旦建立起来，就可以在过程变 体的定义中复用——即软件开发队伍可以 将模式作为过程模式的构建模块，定制特 定的过程模型。
惯例过程模型
惯例过程模型规定了一套过程元素——框 架活动、软件工程动作、任务、工作产品、 质量保证以及每个项目的变更控制机制。 每个过程模型还定义了工作流——即过程 元素之间相互关联的方式。 所有的软件过程模型都支持通用框架活动， 但是每一个模型都对框架活动有不同的侧 重，并且定义了不同的工作流如何以不同 的方式执行每一个框架活动。

任务集

任务集定义了为达到一个软件工程动作的 目标所需要完成的工作。每一个软件工程 动作都由若干个任务集构成，而每一个任 务集都由工作任务、工作产品、质量保证 点和项目里程碑等组成。通常选择最满足 项目需要和适合开发组特点的任务集。软 件工程动作可以根据软件项目的特定需要 和开发队伍的特点作适当的调整。
建模
分析 设计
构建
编码 测试
部署
交付 支持 反馈
瀑布模型
瀑布模型基本思想