第3章软件过程模型
软件工程03-软件生命周期与开发模型
本章任务
本章任务-了解软件工程的发展史及常用的开发模型 知识目标： 了解软件工程的发展史 熟悉软件的生命周期 熟悉常用的开发模型 能力目标： 能描述软件的生命周期 能描述常用的软件开发模型及适用场景
1.软件工程概述
软件危机：落后的软件生产方式无法满足迅速增长的计算机 软件需求，从而导致软件开发与维护过程中出现一系列严重 问题的现象。 表现形式: 软件开发费用和进度失控。费用超支、进度拖延的情况屡 屡发生。有时为了赶进度或压成本不得不采取一些权宜之 计，这样又往往严重损害了软件产品的质量。 软件的可靠性差。尽管耗费了大量的人力物力，而系统的 正确性却越来越难以保证，出错率大大增加，由于软件错 误而造成的损失十分惊人。 生产出来的软件难以维护。很多程序缺乏相应的文档资料 ，程序中的错误难以定位，难以改正，有时改正了已有的 错误又引入新的错误。随着软件的社会拥有量越来越大， 维护占用了大量人力、物力和财力。
1.软件工程概述
传统软件工程
为迎接软件危机的挑战，人们进行了不懈的努力，这些努 力大致上是沿着两个方向同时进行的。 第一个方向是从软件开发管理的角度，希望实现软件 开发过程的工程化，它包括软件度量、项目估算、进 度控制、人员组织、配置管理、项目计划等。这方面 最为著名的成果就是提出了大家都很熟悉的“瀑布式 ”生命周期模型，它是在60年代末“软件危机”后出 现的第一个生命周期模型。如图5-1所示
（1）瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按 固定顺序而连接的若干阶段工作，形如瀑布流水 逐级下落，最终得到软件产品。 瀑布模型的核心思想是按工序将问题简化，将功 能的实现与设计分开，便于分工协作，即采用结 构化的分析与设计方法将逻辑实现与物理实现分 开。将软件生命周期划分为可行性研究与计划、 需求分析、设计、编码、测试和运行维护等六个 基本活动，并且规定了它们自上而下、相互衔接 的固定次序，如同瀑布流水，逐级下落。如果需 求发生变化，而需要逐级返回，修改所有相关的 文档及代码。
第3章软件项目全生命周期的阶段划分
第3章软件项目全生命周期的阶段划 分
第3章软件项目全生命周期的阶段划 分
其软件开发活动具有以下特点： 1)阶段性 要求在开发过程中前一阶段工作完成以 后，后一阶段工作才能开始。 2)阶段评审 对每一阶段完成的工作都要进行评审， 以利于尽早发现问题，避免后期的返工，如 果评审不合格，则不能开始下一阶段工作。 3)文档管理 每个阶段都明确规定了要完成的工作。 如果文档没有完成，就认为本阶段的工作没 有完成。
第3章软件项目全生命周期的阶段划 分
(4)模型的使用 在模型实际的使用不能生搬硬套现有的 开发模型，而是要深刻领会模型的精神，结 合自己软件项目的实际情况，选择符合本身 项目特点的开发模型。 瀑布模型无法解决软件需求不明确或不 准确的问题，会对整个软件开发工作带来严 重影响，最终可能导致开发出的软件并不是 用户真正需要的，且这一点只有在软件开发 完成后才可以被发现，所以瀑布模型对于需 求简单、明确的软件开发项目比较适合。
问题定义通常很简短，但在性质上它是 一个相对独立的步骤，不应该和其他步骤混 淆，更不应该省略。问题定义清楚后，形成 一份关于该项目的规模、目标及成本粗略估 计的报告书。
第3章软件项目全生命周期的阶段划 分
(2)可行性分析
可行性分析的主要目的是论证项目在时间、 资源、资金、效果、实现技术和方法等方面 的必要性和可能性。主要包括经济可行性、 技术可行性与操作可行性等方面。
第3章软件项目全生命周期的阶段划 分
利用演化模型进行软件开发的最大优点 或特点是在软件开发过程中，如果一次迭代 还不能满足用户的实际需求，可通过下一次 的迭代完成，这样就可以在一定程度上减少 软件开发的盲目性，提高软件的开发效率。
软件工程第3章 软件需求分析(终)
第3章软件需求分析案例3: 图书馆图书信息管理系统“图书馆管理系统”是借助计算机来完成图书馆日常管理工作，能提供借书帐号注册、登录功能，基于图书标题、图书编号、作者、出版社的查询，也可以同时多个选项进行同时查询提供图书状态的查询，如可借和不可借，完成借书登记、还书的登记，能帮助管理人员完成图书信息的管理，如图书信息的修改、新图书的增加、旧图书的删除，图书分类工作，从而使图书馆的日常工作信息化、快捷化，减轻图书馆管理工作的困难。
因此，“图书馆管理系统”对于图书馆的日常管理工作和信息化到至关重要的作用。
【知识导入】通过对本章节内容的学习，掌握软件需求分析的基本内容，需求分析的特征及评审。
能够完成项目的需求分析，确立正确的项目开发思路。
软件需求是一个项目的开端，是整个软件项目开发的基础。
即表示该软件经过可行性分析后确立有此需求，而开发该项目。
因此，需求分析在整个项目建设过程中至关重要，是项目开发的基石，基石的牢固程度决定了后期项目的进展以及项目开发完工后的产品质量的优劣，可以说需求分析的好坏直接影响到软件项目开发的成败。
软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。
IEEE （美国电气和电子工程师协会）是这样对需求分析做定义的：①用户解决问题或达到系统目标所需要的条件②为满足一个协议、标准、规格或其他正式制定的文档，系统或系统构建所需满足和具有的条件或能力③将需求要求条件进行文档化描述。
这个概念全方位阐述了需求的概念，较完整的表达了软件需求的内涵和外延，便于用户的全面理解。
而需求分析最终就是通过对应用问题及其环境的分析与理解采用一系列的分析方法和技术将用户的需求逐步精确化、完全化、一致化，最终形成需求规格说明文档的过程。
系统分析阶段产生的系统规格说明书和项目规划是软件需求分析的基础，分析人员需要从软件的角度对其进行检查和调整，并在此基础上展开需求分析。
需求分析阶段的成果主要是需求规格说明书，该成果又是软件设计、编码、测试直至维护的主要基础。
软件工程-软件过程模型
4 演化模型-螺旋模型
Evolutionary Model
螺旋模型的基本思想
每一个螺旋周期（Spiral model sectors）包 含四个部分： （1）确定目标，选择方案，设定约束条件， 选定完成本周期所定目标的策略。 （2）分析该策略可能存在的风险。 （3）在排除风险后，实现本螺旋周期的目标。 （4）评价前一步的结果，并且计划下一轮的 工作。
第二章 软件过程模型
软件生存周期 软件开发模型 瀑布模型 进化式模型 演化模型 形式化开发
第一节 软件生存周期
软件生存周期的概念： 一个软件从计划起，到废弃不用止。
软件生存周期包括：计划、开发、运行。
第二节 软件开发模型概念
软件开发模型的概念：
为整个软件生存期建立的模型。
交付客户
构件n
规格说明
设计
实现和集成
交付客户
增量模型的基本思想
每个增量提供系统功能的一个子集，一个增 量完成并交付，部分系统功能可以提前交付 使用。 对增量中服务的分配取决于服务优先次序。 最高优先权的服务首先被交付。 第一个增量往往是核心的产品。 开发者能通过对系统的经验帮助理解后面的 增量需求和目前增量后续版本的需求变更。
思考题
为以下各系统提出合适的软件过程模型，阐 述理由： （1） 汽车防锁死刹车控制系统 （2）一个支持软件维护的虚拟现实系统 （3）大学记账系统，准备替换一个已存在的 系统 （4）一个位于火车站的交互式火车车次查询 系统
建立原型系统的方法
原型系统仅包括未来系统的主要功能，以及 系统重要的接口。 开发原型系统尽可能使用能缩短开发周期的 语言和工具。
3 演化模型-增量模型
Evolutionary Model
软件过程的定义与模型
5
第二节
软件生命周期
• 软件生命周期的概念 • 传统软件生命周期的各个阶段
统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。
29
敏捷过程与极限编程
随着计算机技术的迅猛发展和全球化进程的加快，软件需求常 常发生变化，强烈的市场竞争要求更快速的开发软件，同时软件 也能够以更快的速度更新。传统的方法在开发时效上时常面临挑 战，因此，强调快捷、小文档、轻量级的敏捷开发方法开始流行。 敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程 方法，它更强调软件开发过程中各种变化的必然性，通过团队成 员之间充分的交流与沟通以及合理的机制来有效地响应变化。
11
几种模型之间的关系
5．软件测试 软件测试是保证软件质量的关键步骤。软件测试的目的是发现软件产品中存在的 软件缺陷，进而保证软件产品的质量。在软件开发的实践中，软件缺陷的产生是必然 的。软件缺陷发现得越晚，弥补缺陷所需的成本就越高，损失也就越大。为了尽早发 现软件缺陷，有效地进行软件测试是必须的。按照测试点的不同，测试可以分为单元 测试、集成测试、系统测试和验收测试。
17
快速原型模型
快速原型的基本思想是快速建 立一个能反映用户主要需求的原型系 统，让用户在计算机上试用它，通过 实践来了解目标系统的概貌。通常， 用户试用原型系统之后会提出许多修 改意见，开发人员按照用户的意见快 速地修改原型系统，然后再次请用户 试用……反反复复地改进，直到原型 系统满足用户的要求。
【软件体系结构】 复习
第一章1. 体系结构发现、演化、重用体系结构发现解决如何从已经存在的系统中提取软件的体系结构，属于逆向工程范畴。
由于系统需求、技术、环境、分布等因素的变化而最终导致软件体系结构的变动，称之为软件体系结构演化。
体系结构重用属于设计重用，比代码重用更抽象。
由于软件体系结构是系统的高层抽象，反映了系统的主要组成元素及其交互关系，因而较算法更稳定，更适合于重用。
2.基于软件体系结构的软件开发方法：问题定义—>软件需求—>软件体系结构—>软件设计—>软件实现3.评价软件体系结构的方法权衡分析方法（ATAM方法），软件体系结构分析方法（SAAM方法）,中间设计的积极评审（ARID方法）第二章1. 建模结构模型：研究结构模型的核心是体系结构描述语言。
以体系结构的构件，连接件和其他概念来刻画结构。
并力图通过结构来反映系统的重要语义内容。
框架模型：与结构模型类似，但不太侧重细节，而侧重于整体结构。
动态模型：是对结构和框架模型的补充，研究系统大颗粒的行为性质。
过程模型：研究构造系统的步骤和过程，结构是遵循某些过程脚本的结果。
功能模型：认为体系结构是由一组功能构件按层次组成，下层向上层提供服务。
功能模型可以看作是一种特殊的框架模型。
4+1视图模型：逻辑视图、进程视图、物理视图、开发视图和场景视图逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。
在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。
这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。
在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图开发视图通过系统输入输出关系的模型图和子系统图来描述。
进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。
物理视图主要考虑如何把软件映射到硬件上。
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
第3章软件需求分析与建模
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
软件工程导论第3章
2.访谈
访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍 然广泛使用的需求分析技术。 访谈有两种基本形式： 正式访谈：系统分析员将提出一些事先准备好的具体问题。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题， 以鼓励被访问人员说出自己的想法。 调查表是当需要调查大量人员的意见时的一个十分有效的做法。 分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户， 以便向他们询问在分析调查表时发现的新问题。 在访问用户的过程中可以使用情景分析技术。情景分析技术的 用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便于用户理解， 而且还可能进一步揭示出一些分析员目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术能保证用户在 需求分析过程中始终扮演一个积极主动的角色。
（1） 数据对象
数据对象是对软件必须理解的复合信息的抽象。所谓 复合信息是指具有一系列不同性质或属性的事物，仅有单 个值的事物(例如，宽度)不是数据对象。 数据对象可以是外部实体(例如，产生或使用信息的任 何事物)、事物(例如，报表)、行为(例如，打电话)、事件 (例如，响警报)、角色(例如，教师、学生)、单位(例如，会 计科)、地点(例如，仓库)或结构(例如，文件)等。总之，可 以由一组属性来定义的实体都可以被认为是数据对象。 数据对象彼此间是有关联的，例如，教师“教”课程， 学生“学”课程，教或学的关系表示教师和课程或学生和 课程之间的一种特定的连接。
（4）需求验证 由软件开发者和用户一起来进行软件需求规格
说明的复审。确保需求规格说明可作为软件设计和最 终系统验收的依据。
二. 需求获取的常用方法
1. 建立联合分析小组 建立一个由用户、系统分析员和领域专家参加 的联合分析小组，密切合作，共同标识问题，提出 解决方案要素，商讨不同方案并指定基本需求。 这是一种面向团队的需求收集法，又称为简易 的应用规格说明技术。
软件过程管理 (4)
用户测试 运行原型
chapter__3
32
原型开发过程
建立原 型目标
定义原 型功能
开发 原型
评估 原型
原型规划
框架ห้องสมุดไป่ตู้义
可执行原型
评估报告
chapter__3
33
原型模型分类
原型是项目系统中的一个方面或者多个方 面的工作模型。 l 抛弃型原型：用于试验某些概念，试 验完系统将无用处 l 进化型原型：原型系统不断被开发和 被修正，最终它变为一个真正的系统。
当你对一个定义得很好的版本进行维护或将一个产品移植到一 个新的平台上，可以采用瀑布模型。 在质量需求高于成本需求和进度需求的时候，可以采用瀑布模 型。
n
n
chapter__3
24
瀑布模型的缺陷
n
n n
n
n
在项目开始的时候，用户常常难以清楚地给出所有需求；用户与 开发人员对需求理解存在差异。 很少软件项目按照顺序模型进行，不能很好地支持迭代。 缺乏灵活性，因为瀑布模型确定了需求分析的绝对重要性，但是 在实践中要想获得完善的需求说明是非常困难的，导致“阻塞状 态”。反馈信息慢，开发周期长。 只有到了整个项目的后半段时间，客户才能看到软件的模样。一 个没有及时发现的错误，可能导致灾难。 虽然存在不少缺陷，瀑布模型经常被嘲笑为“旧式的”，但是在 需求被很好地理解的情况下，仍然是一种合理的方法。
一、生存期模型定义 二、常用生存期模型 三、案例分析
chapter__3
3
建筑工程类项目典型生存期模型
chapter__3
4
制药项目典型生存期模型
chapter__3
5
生存期模型选择
软件工程课本讲解第3章 软件设计(详细设计)
第3章 软件设计 章
3.6 软件详细设计表示法
关于描述工具的有关说明： 关于描述工具的有关说明： 1.为了给出软件结构图中每一个模块的算法和块内数据结构 为了给出软件结构图中每一个模块的算法和块内数据结构 的清晰描述,需要采用适当的表达工具。 的清晰描述 需要采用适当的表达工具。 需要采用适当的表达工具 2.详细设计的表达工具有三类：图形、表格和语言。 详细设计的表达工具有三类：图形、表格和语言。 详细设计的表达工具有三类 3.无论哪类描述工具不仅要具有描述设计过程，如控制流程、 无论哪类描述工具不仅要具有描述设计过程，如控制流程、 无论哪类描述工具不仅要具有描述设计过程 处理功能、数据组织及其它方面的细节的能力 而且在编码 处理功能、数据组织及其它方面的细节的能力,而且在编码 阶段能够直接将它翻译为用程序设计语言书写的源程序。 阶段能够直接将它翻译为用程序设计语言书写的源程序。 4.详细设计的描述工具除了以前介绍过判定树和判定表外， 详细设计的描述工具除了以前介绍过判定树和判定表外， 详细设计的描述工具除了以前介绍过判定树和判定表外 还有程序流程图、 图及PDL等几种常用的工具 等几种常用的工具. 还有程序流程图、N-S图、PAD图及 图 图及 等几种常用的工具
第3章 软件设计 章 1．采用自顶向下、逐步求精的程序设计方法 采用自顶向下、 在需求分析、 概要设计中， 都采用了自顶向下、 在需求分析 、 概要设计中 ， 都采用了自顶向下 、 逐层细化的方法。使用“抽象”这个手段， 逐层细化的方法 。 使用 “ 抽象 ” 这个手段 ， 上层对问 题抽象、对模块抽象和对数据抽象， 题抽象 、 对模块抽象和对数据抽象 ， 下层则进一步分 进入另一个抽象层次。在详细设计中， 解 ， 进入另一个抽象层次 。 在详细设计中 ， 虽然处于 具体”设计阶段， “ 具体 ” 设计阶段 ， 但在设计某个模块内部处理过程 中，仍可以逐步求精，降低处理细节的复杂度。 仍可以逐步求精，降低处理细节的复杂度。
高级软件工程第三章几种典型的开发模型实例课件
5. 项目角色的组成：程序管理、产品管理、开发、测试、 部署、用户培训，但微软并不是每个项目都配全了这 些角色，尤其是小的项目角色会有重叠。强调最好由 用户来充当产品管理角色。
6. 测试人员和开发人员的比例：项目测试人员和开发人 员的比例为1:1，微软通常是2:1，微软通常会雇用大 量的学生等临时人员来进行开发和测试。
PPT学习交流
14
MSF团队角色的职责范围
➢产品经理：了解客户特征，尤其是商业特征，明确客 户的需求以及需求的期望值。
➢程序经理：负责制定计划，每天找出完成该计划的风 险所在，排除风险，每天交付应该完成的内容，确保
计划按质、按量实施。
➢用户体验：设计友好的用户界面，对用户进行培训， 确保用户能够并且愿意和喜欢使用开发出的产品。
化方法。
PPT学习交流
4
瀑布模型的局限性
➢ 客户必须能够完整、正确和清晰地表达他们的需要。
➢ 可能要花费更多的时间来建立一些用处不大的文档。
➢ 在开始的两个或三个阶段中，很难评估真正的进度 状态。
➢ 在一个项目的早期阶段，过分地强调了基线和里程 碑处的文档。
➢ 开发人员一开始就必须理解其应用。 ➢ 当接近项目结束时，出现了大量的集成和测试工作。 ➢ 直到项目结束之前，都不能演示系统的能力。
PPT学习交流
12
续
7. 强调进行风险管理：对项目风险进行确认并全 程跟踪。
8. 项目开发过程进行里程碑的建立和管理。 9. 项目总结制度：每个项目完成后，对其失败和
成功的地方进行总结。
PPT学习交流
13
MSF团队模型
➢MSF组队模型展示了如何组织项目队伍，在时 间控制和连续不断发展计划的要求下，有效的 交付系统的解决方案。它描述了六种基本的角 色（程序管理、产品管理、开发、测试、用户 体验和发布管理）。
软件工程第3章 软件工程过程模式
组件技术是基于面 向对象技术发展起来的， 可以把组件视作为一个 盒子，它里面封装了许 多个类模块。
在基于组件复用的
软件开发中，软件由组 件装配而成，如同用标 准零件装配汽车一样。
7. 组件复用模式
组件复用模式是对基于组件的系统集成的过程 支持。组件复用可带来了流水线软件装配，系 统所需组件大多无须专门开发，而可通过专业 制作机构提供，由此可提高软件开发效率，并 可提高软件产品质量。
7. 组件复用模式
需求框架描述 组件复用分析 需求修改与细化
系统设计 组件开发 系统集成
（1）问题定义：这是软件生存期的第一个阶段， 主要任务是弄清用户要计算机解决的问题是什 么。
（2）可行性研究：任务是为前一阶段提出的问 题寻求一种至数种在技术上可行、且在经济上 有较高效益的解决方案。
（3）需求分析：弄清用户对软件系统的全部需 求，主要是确定目标系统必须具备哪些功能。
软件开发时期
开发时期具体设计和实现在前一个时期定义的软件， 它通常由下述4个阶段组成：总体设计，详细设计， 编码和单元测试，综合测试。其中前两个阶段又称 为系统设计，后两个阶段又称为系统实现。 （1）总体设计（也称为概要设计）：设计软件的 结构，即确定程序由哪些模块组成以及模块间的关 系。 （2）详细设计：针对单个模块的设计。 （3）编码和单元测试：按照选定的语言，把模块 的过程性描述翻译为源程序，并进行测试。 （4）综合测试：通过各种类型的测试(及相应的调 试)使软件达到预定的要求。
瀑布模式在编码之前设置了系统分析与系统设计 的各个阶段，分析与设计阶段的基本任务规定，在 这两个阶段主要考虑目标系统的逻辑模型，不涉及 软件的物理实现。
3、质量保证的观点
软件工程的基本目标是优质、高产。为了保 证所开发的软件的质量，在瀑布模式的每个阶 段都应坚持两个重要做法。
《软件工程》课件第3章 软件设计
第3章 软件设计
3.1 软件概要设计概述 3.2 软件设计的基本原理 3.3 软件结构准则 3.4 基于IDEF0图的设计方法 3.5 软件详细设计 3.6 软件详细设计表示法 3.7 小结 习题
第3章 软件设计
3.1 软件概要设计概述
3.1.1 概要设计基本任务 1．设计软件系统结构(简称软件结构) 为了实现目标系统，最终必须设计出组成这个系
4．评审 在该阶段，对设计部分是否完整地实现了需求中 规定的功能、性能等要求，设计方案的可行性、关键 的处理和内外部接口定义正确性、有效性以及各部分 之间的一致性等，都一一进行评审。
第3章 软件设计
3.1.2 软件概要设计文档 概要设计说明书是概要设计阶段结束时提交的技
术文档。按国标GB8576—88的《计算机软件产品开发文 件编制指南》规定，软件设计文档可分为“概要设计 说明书”、“详细设计说明书”和“数据库设计说明 书”。
在大多数情况下，模块间的控制耦合并不是必需的， 可以将被调模块内的判定上移到调用模块中去，同时将 被调模块按其功能分解为若干单一功能的模块，将控制 耦合改变为数据耦合。
第3章 软件设计
(5) 公共耦合：指通过一个公共数据环境相互作 用的那些模块间的耦合。公共数据环境可以是全程变 量或数据结构、共享的通信区、内存的公共覆盖区及 任何存储介质上的文件和物理设备等(也有将共享外部 设备分类为外部耦合的)。
概要设计说明书的主要内容如下： (1) 引言：编写目的，背景，定义，参考资料。 (2) 总体设计：需求规定，运行环境，基本设计 概念和处理流程，结构。
第3章 软件设计
(3) 接口设计：用户接口，外部接口，内部接口。 (4) 运行设计：运行模块组合，运行控制，运行时 间。 (5) 系统数据结构设计：逻辑结构设计，物理结构 设计，数据结构与程序的关系。 (6) 系统出错处理设计：出错信息，补救措施，系 统恢复设计。
软件工程第三章
3.2.1、结构化分析（SA） 3.2.1、结构化分析（SA）方法
2、数据流图 （1）、数据流图的组成 “ 四大组成部分：外部实体(也就是数据的源点或终 点)、处理、数据流和数据存储
3.2.1、结构化分析（SA） 3.2.1、结构化分析（SA）方法
2、数据流图 （2）、数据流图的符号 “ a、基本符号 b、附加符号： * ——表示数据流之间是“与”的关系。 + ——表示数据流之间是“或”的关系。 ⊕ ——表示只能从中选一个(互斥关系)。
数据流图实例：××培训中心管理系统
“
3.2.1、结构化分析（SA） 3.2.1、结构化分析（SA）方法
数据流图实例：××培训中心管理系统
“
3.2.1、结构化分析（SA） 3.2.1、结构化分析（SA）方法
3、数据字典 数据字典是关于数据的信息的集合，也就是对数据 “ 流图中包含的所有元素的定义的集合。当数据流图 和对数据流图中每个元素的精确定义(数据字典)放 在一起时，才能共同构成系统的规格说明
1、Jackson系统开发方法 前期(20 世纪70 年代)： “ 主要研究以处理数据为主的结构化程序设计，称 JSP(Jackson Structured Programming)方法 后期(20世纪80 年代)： 集中研究软件系统的开发，称JSD(Jackson System Development)方法
3.2.4、Jackson系统开发方法 Warnier方法 3.2.4、Jackson系统开发方法、Warnier方法 系统开发方法、
1、Jackson系统开发方法 基本思想是从数据结构出发建立对应的程序结构， “ 适合于设计企事业事务管理类的数据处理系统。
3.2.4、Jackson系统开发方法 Warnier方法 3.2.4、Jackson系统开发方法、Warnier方法 系统开发方法、
第三章软件过程模型
第三章软件过程模型1.简述软件过程、软件⽣存周期、软件过程模型（软件⽣存周期模型）三者之间的概念区别。
（1）软件过程：软件⽣存周期中的⼀系列相关过程所涉及的活动（2）软件⽣存周期:软件也有⼀个从⽣到死的过程，这个过程⼀般称之为软件的软件⽣存周期或⽣命周期。
（3）软件过程模型：⼀个包括软件产品开发、运⾏和维护中有关过程、活动和任务的框架，覆盖了从系统的需求定义到系统的使⽤终⽌。
2.软件过程就是软件开发过程么？为什么？软件过程不是软件开发过程。
软件过程是指软件⽣存周期中的⼀系列相关活动所涉及的活动，⽽软件⽣存周期是软件从⽣到死的过程，包含软件的开发过程。
3.请选择两个常见的软件过程模型，谈谈你对它们的理解？并对它们进⾏⽐较。
（1）瀑布模型：将软件⽣命周期划分为软件计划、需求分析和定义、设计、实现、测试、运⾏和维护这6个阶段，规定了它们⾃上⽽下、相互衔接的固定次序，如同瀑布流⽔逐级下落。
从本质来讲，它是⼀个软件开发架构，开发过程是通过⼀系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产⽣循环反馈，是⽂档驱动型的模型。
（2）原型模型：利⽤原型法技术尽可能快地构造⼀个实际系统的简化模型。
⽐较：瀑布模型适⽤于已经确定好的、深思熟虑过的模型，⽽且⼀旦确定好，再进⾏加⼯或改动会造成很⼤的影响。
⽽原型模型适⽤于不能预先确切定义需求的软件项⽬，能够快速建⽴⼀个软件模型，⽽且软件的模型是在⼀次次的原型模型的迭代中修改完善的。
4.瀑布模型和其他常见模型有什么关联和区别？（1）瀑布模型与原型模型：瀑布模型适⽤于规模较⼤的软件，是⽂档驱动型的模型，⽽且瀑布模型⼀旦成型以后更改很⿇烦，但是原型模型更改很容易，⽽且采取原型模型的软件就是通过不断的更改达到对软模型的完善。
两者的关联是通过不断迭代（2）瀑布模型与增量模型：增量模型的某些阶段是按照瀑布模型的整体⽅式进⾏开发，但是两者的区别是增量模型将设计模块分成了⼏个部分，可以同时进⾏设计，原型模型不⾏。
《软件工程》各章课后习题答案
第一章课后参考答案1.什么是软件危机？它们有哪些典型表现？为什么会出现软件危机？“软件危机”是指计算机软件的“开发”和“维护”过程中所遇到的一系列“严重问题”。
这些问题决不仅仅是不能正常运行的软件才具有的，实际上，几乎“所有软件”都不同程度地存在这些问题。
它们有以下表现：（1）对软件开发成本和进度的估计常常很不准确；（2）用户对“已完成的”软件系统不满意的现象经常发生；（3）软件产品的质量往往靠不住；（4）软件常常是不可维护的；（5）软件通常没有适当的文档资料；（6）软件成本在计算机系统总成本中所占的比例逐年上升；（7）软件开发生产率提高的速度，远远跟不上计算机应用普及深入的趋势。
出现软件危机的主要原因（1）与软件本身的特点有关（2）与软件开发和维护过程中使用的方法不正确有关2.假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”时在引入变动，当然付出的代价更高。
一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是整体构架的错误。
3.什么是软件工程？它有哪些本质特征？怎么用软件工程消除软件危机？软件工程是指导知道计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.5 构件集成模型
构件集成模型是基于构件的开发模型 构件集成模型： 整个系统模块化 复用构件库中的软件构件 构件集成模型是演化形的，开发过程是迭代的 5个阶段： 软件的需求分析和定义 体系结构设计 构件库建立 应用软件构建 测试和发布
构件集成模型
需求分析和定义 体系结构设计 构件库建立 应用软件构建 测试和发布 1：N
构件集成模型存在问题
模型由于采用自定义的组装结构标准，缺乏通用的组
装结构标准，这样就引入了比较大的风险。
可复用性和软件高效性不容易协调，需要比较有经验
的开发人员。
3.6 统一过程模型
统一过程（Unified Process，UP) 是风险驱动的、基
于用例技术的、以架构为中心的、迭代的、可配置的 软件开发流程。 统一过程是以用例驱动的，以架构为中心，迭代和增 量的过程。 统一过程是一个软件开发过程，是一个通用的过程框 架：
初始
细化 构造
移交
统一过程的四个阶段
统一过程五个核心工作流
需求(Requirements Capture)：致力于开发正确的系统
分析(Analysis)：更精确地理解需求 设计(Design)：深入理解与非功能性需求和约束相联
系的问题 实现(Implementation)：实现系统与集成 测试(Test)：验证实现的结构
敏捷开发12条原则
我们最优先要做的是通过尽早的、持续的交付有价值
的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。敏捷过程利
用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几
个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天
每隔一定时间，团队会在如何才能更有效地工作方面
进行反省，然后相应地对自己的行为进行调整。
3.7.1 极限编程
极限编程（eXtreme Programming，XP）是一种软件
工程方法学，是敏捷开发中最富有成效的方法学之一 由KentBeck在1996年提出 具有强沟通、简化设计、迅速反馈等特点
每个时期又细分为若干个阶段。把整个软件生存周期 划分为若干阶段，使得每个阶段有明确的任务，使规 模大，结构复杂和管理复杂的软件开发变的容易控制 和管理。
软件生存周期包括可行性分析、项目计划、需求分析
、软件设计、编码与测试、维护等阶段，每个阶段有 包含一系列的活动。
3.2 瀑布模型
瀑布模型将软件生命周期划分为软件计划、需求分析
极大地增加了工作量。 用户只有在末期才能见到开发成果。 经常遇到等待其他成员完成其所依赖的任务情况。
3.3 增量模型
增量模型（Incremental Model）也称为渐增模型，是
在项目的开发过程中以一系列的增量方式开发系统。 软件被作为一系列的增量构件来设计、实现、集成和 测试，每一个构件是由多种相互作用的模块所形成的 提供特定功能的代码片段构成. 增量方式包括：
和定义、设计、实现、测试、运行和维护这6个阶段 ，规定了它们自上而下、相互衔接的固定次序，如同 瀑布流水逐级下落。
从本质来讲，它是一个软件开发架构，开发过程是通
过一系列阶段顺序展开的，从系统需求分析开始直到 产品发布和维护，每个阶段都会产生循环反馈.
瀑布模型示意图
瀑布模型
它是一个软件开发架构，开发过程是通过一系列阶段
核心工作流
统一过程准则
准则 迭代的开发软件 需求管理 基于构件的体系结构 可视化软件建模 验证软件质量 控制软件的变更 统一过程主要的优点是提高了团队生产力
3.7 敏捷过程
敏捷不是一个过程，是一类过程的统称。
敏捷方法的两大主要特征： 对“适应性”的强调 对“人”的关注 做法： 快速响应:引入迭代式的开发手段 将整个软件生命周期分解为若干个小的迭代周期 获取切实有效的客户反馈 提出12条基本原则
结对编程
优势： 可以减少风险 可以使团队生产效率更高 是知识传播的最好途径 可以打造出最佳的合作团队。 可以生成更好的代码 方法： 面对面结对编程 分布式结对编程
软件开发模型是指软件开发全部过程、活动和任务的结构框架，
小结
能清晰、直观地表达软件开发全过程，明确规定了要完成的主要 活动和任务，用来作为软件项目工作的基础。 瀑布模型是一种线性模型，文档驱动的模型。 增量提交模型采用一系列的增量方式开发系统。 螺旋模型结合瀑布模型和快速原型，是一种风险驱动的开发模型
风险识别
风险分析 风险控制
特别适合于大型复杂的系统
每一个周期都包括需求定义、风险分析、工程实现和
评审
螺旋模型示意图
螺旋模型活动
四个象限分别代表了以下活动： 制定计划：确定软件目标，选定实施方案，确定项目开 发的限制条件； 风险分析：分析评估所选方案，考虑如何识别和消除风 险； 实施工程：实施软件开发和验证； 客户评估：评价开发工作，提出修正建议，制定下一步 计划。 螺旋模型是风险驱动的模型
结对编程(Pair-Programming) 是XP中非常重要的实践
之一。
定义：两个人坐在同一台计算机前面，使用相同的键
盘和鼠标来开发同样的一个模块，一个称为驾驶者 (Driver)，负责代码的键入，另外一个称为领航员 (Navigator)，负责监看与决策，包括低级错误和方向 性的错误。当出现的一个问题对其中一个人来说，难 以解决，而恰好是另外一个人的强项的时候，那么角 色就会发生转换。
而是交付满足客户需求的可运行产品的一个子集。 存在缺陷：
加入构件必须不破坏已构造好的系统部分；
很容易退化为边做边改模型，从而使软件过程的控制失
去整体性。
3.4 螺旋模型
螺旋模型（Spiral Model）是结合了瀑布模型和快速原
型模型的迭代开发模型 强调了其他模型均忽略了的风险分析：
适合于规模小、进度紧、需求不稳定、开发小项目的
小团队。
极限编程
特点： XP模型是“轻量型”或“灵活”的软件过程模型 与面向对象语言结合的开发方案 “专家协作”的开发方式，解决难点问题 重视客户反馈 核心有四个要点： 交流 简单 反馈 勇气
3.7.2 结对编程
增量开发：以一定的时间间隔开发部分工作软件
增量提交：以一定的时间间隔增量方式向用户提交工作
软件及相应文档
增量模型融合了线性顺序模型的基本成份和原型实现
ቤተ መጻሕፍቲ ባይዱ
模型的迭代特征。
增量构造模型
需求分析 编码2 设计 编码3 编码1 测试1 测试3 测试2
增量模型
增量模型在各个阶段并不交付一个可运行的完整产品，
都在一起工作。
围绕被激励起来的个体来构建项目，给他们提供所需
的环境和支持，并且信任他们能够完成工作。
敏捷开发12条原则(续)
在团队内部，最具有效果并富有效率的传递信息的方
法，就是面对面的交谈。 工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和
用户应该能够保持一个长期的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。 简单是最根本的。 最好的构架、需求和设计出于自组织团队。
第3章 软件过程模型（内容提要）
瀑布模型
增量模型 螺旋模型
协同开发模型
面向对象模型 面向方面的软件开发
3.1 软件生存周期
软件也有一个从生到死的过程，这个过程一般称之为
软件的软件生存周期或生命周期（Software Development Life Cycle）
软件生存周期可划分为定义、开发和运行三个时期，
构件集成模型利用模块化方法将整个系统模块化，复用构件库中 统一过程模型是以用例驱动的，以架构为中心，迭代和增量的过
的软件构件，通过组合手段提高应用软件系统过程的效率和质量。 程。
敏捷方法是一组敏捷实践技术的总称，包括极限编程、自适应软
件开发、动态系统开发和特征驱动开发等等
顺序展开的。 每个阶段都会产生循环反馈
各个阶段产生的文档是维护软件产品时必不可少的，
没有文档的软件几乎是不可能维护的。 瀑布模型是一种文档驱动的过程模型
瀑布模型特点
顺序性和依赖性
推迟实现 质量保证的观点
是一种线性模型
强调文档的作用
瀑布模型存在问题
各个阶段的划分完全固定，阶段之间产生大量的文档，