1、软件工程导论（第6版）,第1章 软件工程学概述,迄今为止，计算机系统已经经历了4个不同的发展阶段，但是，人们仍然没有彻底摆脱“软件危机”的困扰，软件已经成为限制计算机系统发展的瓶颈。 为了更有效地开发与维护软件，软件工作者在20世纪60年代后期开始认真研究消除软件危机的途径，从而逐渐形成了一门新兴的工程学科计算机软件工程学。,第1章 软件工程学概述,引言,主要内容,主要内容,1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程,1.1 软件危机,主要内容,1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程,1.1.1 软件危机的介绍,1.1 软件危机,1.1.
2、1 软件危机的介绍,在计算机软件的开发和维护过程中所遇到的一系列严重问题。,软件危机的典型表现,1.1 软件危机,1.1.1 软件危机的介绍,软件危机的典型表现,1.1 软件危机,1.1.1 软件危机的介绍,1.1.2 产生软件危机的原因,1.1 软件危机,与软件本身特点有关,1.1.2 产生软件危机的原因,与软件本身特点有关,1.1 软件危机,1.1.2 产生软件危机的原因,软件开发与维护的方法不正确有关,1.1 软件危机,1.1.2 产生软件危机的原因,1.1 软件危机,1.1.2 产生软件危机的原因,在软件开发的不同阶段进行修改需要付出的代价,1.1.3 消除软件危机的途径,1.1 软件
3、危机,1.1.3 消除软件危机的途径,1.2 软件工程,主要内容,1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程,1.2.1 软件工程的介绍,1.2 软件工程,1.2.1 软件工程的介绍,软件工程概述,软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。,1968年在第一届NATO会议上曾经给出了软件工程的一个早期定义：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和
4、使用完善的工程原理。”,1993年IEEE进一步给出了一个更全面更具体的定义：“软件工程是： 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件； 研究中提到的途径。,1.2 软件工程,1.2.1 软件工程的介绍,软件具有的本质特性,1.2.1 软件工程的介绍,1.2 软件工程,1.2.2 软件工程的基本原理,1.2.2 软件工程的基本原理,1.2 软件工程,1.2.3 软件工程方法学,1.2.3 软件工程方法学,1.2 软件工程,1.2 软件工程,1.2.3 软件工程方法学,传统方法学 概念：传统方法学也称为生命周期方法学或结构化范型。它采用结构化技术(结构
5、化分析、结构化设计和结构化实现)来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。,1.2 软件工程,1.2.3 软件工程方法学,传统方法学的特点： 传统方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。 每个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。,1.2 软件工程,1.2.3 软件工程方法学,在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审。 审查的一条主要标准就是每个阶段都应该交出“最新式的”(即和所开发的软件完全一致的)高质量的文档资料，从而保证在软件开
6、发工程结束时有一个完整准确的软件配置交付使用。,1.2 软件工程,1.2.3 软件工程方法学,采用生命周期方法学可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。目前，传统方法学仍然是人们在开发软件时使用得十分广泛的软件工程方法学。,1.2 软件工程,1.2.3 软件工程方法学,面向对象方法学： 概念：与传统方法相反，面向对象方法把数据和行为看成是同等重要的，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。,1.2 软件工程,1.2.3 软件工程方法学,四个要点,1.2 软件工程,1.2.3 软件工程方法学,面向对象方法学基本原则： 尽量模拟人类习惯的思维方式，使开发
7、软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程，从而使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。,1.2 软件工程,1.2.3 软件工程方法学,面向对象方法学： 优点： 降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。 面向对象方法特有的继承性和多态性，进一步提高了面向对象软件的可重用性。,1.2 软件工程,1.2.3 软件工程方法学,1.3 软件生命周期,主要内容,1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程,1.3 软件生命周期,1.3 软件生命周期,软件生命周期由软件定义、软件开
8、发和运行维护(也称为软件维护)3个时期组成，每个时期又进一步划分成若干个阶段。,软件定义时期的任务是： 确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。,1.3 软件生命周期,1.3 软件生命周期,软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为
9、系统实现。维护时期的主要任务是使软件持久地满足用户的需要。,1.3 软件生命周期,1.3 软件生命周期,下面简要介绍软件生命周期每个阶段的基本任务,1.3 软件生命周期,1.3 软件生命周期,下面简要介绍软件生命周期每个阶段的基本任务,在实际从事软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素，都影响阶段的划分。,1.4 软件过程,主要内容,1.1 软件危机1.2 软件工程1.3 软件生命周期1.4 软件过程,1.4 软件过程,1.4 软件过程,软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程描述为了开发出客户需要的软件，什
10、么人（who）、在什么时候（when）、做什么事（what）以及怎样（how）做这些事以实现某一个特定的具体目标。,1.4.1 瀑布模型,1.4 软件过程,1.4.1 瀑布模型,瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。如下图所示为传统的瀑布模型,图1.2传统的瀑布模型如图1.2所示为传统的瀑布模型。,图1.2 传统的瀑布模型,1.4.1 瀑布模型,按照传统的瀑布模型开发软件，有下述的几个特点。 阶段间具有顺序性和依赖性： 两重含义： 必须等前一阶段的工作完成之后，才能开始后一阶段的工作； 前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一
11、阶段的输出文档正确，后一阶段的工作才能获得正确的结果。,1.4 软件过程,1.4.1 瀑布模型,1.4.1 瀑布模型,b) 推迟实现的观点 瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。,1.4 软件过程,1.4.1 瀑布模型,1.4.1 瀑布模型,c) 质量保证的观点： 软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法。 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。 每个阶段结束前都要对所完成的文档进行评审，以便
12、尽早发现问题，改正错误。,1.4 软件过程,1.4.1 瀑布模型,1.4.1 瀑布模型,传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。实际的瀑布模型是带“反馈环”的，如系统图1.3所示。,1.4 软件过程,1.4.1 瀑布模型,1.4.1 瀑布模型,1、图中实线箭头表示开发过程，虚线箭头表示维护过程。、 2、实际的瀑布模型当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。,1.4.1 瀑布模型,瀑布模型有许多优点： 可强迫开发人员采用规范的方法（例如，结构化技术）；严格地规定了每个阶段必须提交的文档；
13、 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。,1.4 软件过程,1.4.1 瀑布模型,1.4.1 瀑布模型,1.4.2. 快速原型模型,1.4 软件过程,1.4.2. 快速原型模型,概念： 快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。 如下图1.4所示：,图1.4 中实线箭头表示开发过程 虚线箭头表示维护过程,1.4.2. 快速原型模型,快速原型模型是不带反馈环的，这正是这种过程模型的主要优点： 软件产品的开发基本上是线性顺序进行的。能基本上做到线性顺序开发的主要原因如下：,1.4 软件过程,1.4.2. 快速原型模
14、型,1.4.2. 快速原型模型,1.4 软件过程,1.4.2. 快速原型模型,1.4.2. 快速原型模型,1.4.3. 增量模型,1.4 软件过程,1.4.3. 增量模型,概念： 增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。 增量模型如下图1.5所示：,图1.5 增量模型,1.4.3. 增量模型,优点：,1.4 软件过程,1.4.3. 增量模型,1.4.3. 增量模型,1.4 软件过程,1.4.3. 增量模
15、型,使用增量模型的困难：,1.4.3. 增量模型,1.4 软件过程,1.4.3. 增量模型,风险更大的增量模型：,1.4.3. 增量模型,1.4.4 螺旋模型,1.4 软件过程,概念： 螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。 螺旋模型如下图所示：,1.4.4 螺旋模型,图1.7 简单得螺旋模型,1.4.4 螺旋模型,图1.8完整的螺旋模型,1.4.4 螺旋模型,1.4.5. 喷泉模型,1.4 软件过程,概念： “喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。迭代是软件开发过程中普
16、遍存在的一种内在属性。用面向对象方法学开发软件时，工作重点应该放在生命周期中的分析阶段。 喷泉模型图如下图1.9所示：,1.4.5. 喷泉模型,图中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在交迭；图中在一个阶段内的向下箭头代表该阶段内的迭代（或求精）。 图中较小的圆圈代表维护，圆圈较小象征着采用了面向对象范型之后维护时间缩短了。,1.4.5. 喷泉模型,1.4 软件过程,概念： Rational统一过程（Rational Unified Process,RUP）是由Rational软件公司推出的一种完整而且完美的软件过程。RUP总结了经过多年商业化验证的6条最有效的软件开发经验，这
17、些经验被称为“最佳实践”。,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4 软件过程,a) 最佳实践 迭代式开发 迭代式开发允许在每次迭代过程中需求都可以有变化，这种开发方法通过一系列细化来加深对问题的理解，因此能更容易地容纳需求的变更。 管理需求 RUP描述了如何提取、组织系统的功能性需求和约束条件并把它们文档化。,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4 软件过程,a) 最佳实践 使用基于构件的体系结构 UP提供了使用现有的或新开发的构件定义体系结构的系统化方法，从而有助于降低软件开发的复杂性，提高软件重
18、用率。 可视化建模 可视化建模语言UML紧密地联系在一起，在开发过程中建立起软件系统的可视化模型，可以帮助人们提高管理软件复杂性的能力。,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4 软件过程,a) 最佳实践 验证软件质量 软件质量评估不再是事后型的或由单独小组进行的孤立活动，而是内建在贯穿于整个开发过程的、由全体成员参与的所有活动中。 控制软件变更 RUP描述了如何控制、跟踪和监控修改，以确保迭代开发的成功。,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4 软件过程,b) RUP软件开发生命周期 RUP软件开发
19、生命周期是一个二维的生命周期模型，如下图1.10所示。图中纵轴代表核心工作流，横轴代表时间。 核心工作流 RUP中有9个核心工作流，其中前6个为核心过程工作流程，后3个为核心支持工作流程。,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4 软件过程,RUP软件开发生命周期 工作阶段 RUP把软件生命周期划分成4个连续的阶段。每个阶段都有明确的目标，并且定义了用来评估是否达到这些目标的里程碑。每个阶段的目标通过一次或多次迭代来完成。 下面简述4个阶段的工作目标。,1.4.6. Rational统一过程,1.4.6. R
20、ational统一过程,1.4 软件过程,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4 软件过程,b) RUP软件开发生命周期 RUP迭代式开发 RUP重复一系列组成软件生命周期的循环。每次循环都经历一个完整的生命周期，每次循环结束都向用户交付产品的一个可运行的版本。 每个阶段又进一步细分为一次或多次迭代过程。,1.4.6. Rational统一过程,1.4.6. Rational统一过程,1.4 软件过程,概念： 敏捷过程为了使软件开发团队具有高效工作和快速响应变化的能力，17位著名的软件专家于2001年2月联合起草了敏捷软件开发宣言。敏捷软件开发宣
21、言由下述4个简单的价值观声明组成。,1.4.7.敏捷过程与极限编程,1.4.7.敏捷过程与极限编程,1.4 软件过程,1.4.7.敏捷过程与极限编程,1.4.7.敏捷过程与极限编程,1.4 软件过程,极限编程： 极限编程（eXtreme Programming,XP）是敏捷过程中最富盛名的一个，其名称中“极限”二字的含义是指把好的开发实践运用到极致。 目前，极限编程已经成为一种典型的开发方法，广泛应用于需求模糊且经常改变的场合。,1.4.7.敏捷过程与极限编程,1.4.7.敏捷过程与极限编程,1.4 软件过程,极限编程的整体开发过程,1.4.7.敏捷过程与极限编程,1.4.7.敏捷过程与极限编
22、程,1.4 软件过程,极限编程的迭代过程,图1.11描述了极限编程的整体开发过程。首先，项目组针对客户代表提出的“用户故事” 进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行“试探” 。然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制订交付计划。接下来开始多个迭代过程（通常每个迭代历时13周），在迭代期内产生的新用户故事不在本次迭代内解决，以保证本次开发过程不受干扰。开发出的新版本软件通过验收测试之后交付用户使用。,1.4.7.敏捷过程与极限编程,1.4.7.敏捷过程与极限编程,图1.11,1.4.7.敏捷过程与极限编程,1.4 软件过程,a) 微软过程准则：项目计划应该兼顾
23、未来的不确定因素。 用有效的风险管理来减少不确定因素的影响。 经常生成并快速地测试软件的过渡版本，从而提高产品的稳定性和可预测性。 采用快速循环、递进的开发过程。 用创造性的工作来平衡产品特性和产品成本。 项目进度表应该具有较高稳定性和权威性。 使用小型项目组并发地完成开发工作。 在项目早期把软件配置项基线化，项目后期则冻结产品。 使用原型验证概念，对项目进行早期论证。 把零缺陷作为追求的目标。 里程碑评审会的目的是改进工作，切忌相互指责。,1.4.8. 微软过程,1.4.8. 微软过程,1.4 软件过程,b) 微软软件生命周期：如下图1.13所示,1.4.8. 微软过程,规划阶段 设计阶段
24、开发阶段 稳定阶段 发布阶段,1.4.8. 微软过程,图1.13,1.4.8. 微软过程,1.4 软件过程,c) 微软过程模型： 微软过程的每一个生命周期发布一个递进的软件版本，各个生命周期持续、快速地迭代循环。如下图1.14所示,1.4.8. 微软过程,1.4.8. 微软过程,图1.14,1.4.8. 微软过程,本章小结,1.本章对计算机软件工程学作一个简短的概述，回顾计算机系统发展简史。 2.本章介绍 软件工程的基本原理和方法有概括的本质的认识，详细讲解生命周期相关知识。 3. 详细讲解8种典型的软件过程模型。,本章小结,软件工程导论（第6版）,第2章 可行性研究,第2章可行性研究,引言,
25、第2章可行性研究,并非任何问题都有简单明显的解决办法，事实上，许多问题不可能在预定的系统规模或时间期限之内解决。 如果问题没有可行的解，那么花费在这项工程上的任何时间、人力、软硬件资源和经费，都是无谓的浪费。 可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。,主要内容,主要内容,2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析,第2章可行性研究,2.1 可行性研究的任务,主要内容,2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.
26、6 成本/效益分析,第2章可行性研究,2.1可行性研究的任务,2.1 可行性研究的任务,可行性研究的目的不是解决问题，而是确定问题是否值得去解决。,首先，进一步分析和澄清问题定义 然后，分析员应该导出系统的逻辑模型 最后，探索若干种可供选择的主要解法,可行性研究分析过程：,第2章可行性研究,2.1 可行性研究的任务,至少应该从下述3个方面研究每种解法的可行性,2.1可行性研究的任务,第2章可行性研究,2.2 可行性研究过程,主要内容,2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析,第2章可行性研究,2.2 可行性
27、研究过程,怎样进行可行性研究呢?典型的可行性研究过程有下述8个步骤。,复查系统规模和目标 研究目前正在使用的系统 导出新系统的高层逻辑模型 进一步定义问题 导出和评价供选择的解法 推荐行动方针 草拟开发计划书 写文档提交审查,2.2 可行性研究过程,第2章可行性研究,2.2 可行性研究过程,复查系统规模和目标,分析员访问关键人员，仔细阅读和分析有关的材料，以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。这个步骤的工作，实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。,2.2 可行性研究过程,第2章可行性研究
28、,2.2 可行性研究过程,2.研究目前正在使用的系统,现有的系统是信息的重要来源。显然，如果目前有一个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功能；另一方面，如果现有的系统是完美无缺的，用户自然不会提出开发新系统的要求，因此，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。 应该仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。 常见的错误做法是花费过多时间去分析现有的系统。 没有一个系统是在“真空”中运行的，绝大多数系统都和其他系统有联系。,2.2 可行性研究过程,第2章可行性研究,2.2 可行性研究过程,3.
29、导出新系统的高层逻辑模型,优秀的设计过程通常是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。,4.进一步定义问题,可行性研究的前4个步骤实质上构成一个循环。分析员定义问题，分析这个问题，导出一个试探性的解；在此基础上再次定义问题，再一次分析这个问题，修改这个解；继续这个循环过程，直到提出的逻辑模型完全符合系统目标。,2.2 可行性研究过程,第2章可行性研究,2.2 可行性研究过程,5.导出和评价供选择的解法,分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的物理解法供比较和选择。 其次可以考虑
30、操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。 接下来应该考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。 最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，这个进度表不需要制定得很详细，通常只需要估计生命周期每个阶段的工作量。,2.2 可行性研究过程,第2章可行性研究,2.2 可行性研究过程,6.导出和评价供选择的解法,根据可行性研究结果应该决定的一个关键性问题是： 是否继续进行这项开发工
31、程？分析员必须清楚地表明他对这个关键性决定的建议。如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。通常客户主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。,2.2 可行性研究过程,第2章可行性研究,2.2 可行性研究过程,7.草拟开发计划,分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员和各种资源的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本。最后应该给出下一个阶段(需求分析)的详细进度表和成本估
32、计。,8. 书写文档提交审查,应该把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。,2.2 可行性研究过程,第2章可行性研究,2.3 系统流程图,第2章可行性研究,2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析,第2章可行性研究,2.3 系统流程图,系统流程图是概括地描绘物理系统的传统工具。,基本思想： 用图形符号以黑盒子形式描绘组成系统的每个部件(程序、文档、数据库、人工过程等)。,系统流程图表达的是数据在系统各部件之间流
33、动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流程图。,2.3 系统流程图,第2章可行性研究,2.3.1符号,2.3 系统流程图,2.3.1符号,利用符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件（或数据库），把抽象处理具体化为特定的程序或手工操作等。,第2章可行性研究,2.3 系统流程图,以概括的方式抽象地描绘一个实际系统时，仅仅使用下图中列出的基本符号就足够了,2.3.1符号,第2章可行性研究,需要更具体地描绘一个物理系统时还需要使用右图中列出的系统符号,2.3.1符号,第2章可行性
34、研究,2.3.2 例子,2.3 系统流程图,以一个简单的例子进行讲解。某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果哪种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。,2.3.2 例子,第2章可行性研究,2.3 系统流程图,该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的
35、库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。 如下图所示。,2.3.2 例子,第2章可行性研究,2.3.2 例子,第2章可行性研究,2.3.3 分层,2.3 系统流程图,面对复杂的系统时，一个比较好的方法是分层次地描绘这个系统。首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。,2.3.3 分层,第2章可行性研究,2.4 数据流图,主要内容,2.1 可行性研究的任务 2.2 可
36、行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析,第2章可行性研究,2.4 数据流图,概念,数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。,2.4 数据流图,第2章可行性研究,2.4.1 符号,2.4 数据流图,2.4.1 符号,数据流四中基本符号,第2章可行性研究,附加符号,基本符号,2.4.1 符号,第2章可行性研究,2.4.2 例子,2.4 数据流图,以简单例子说明怎样画数据流图,假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件
37、应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。,2.4.2 例子,第2章可行性研究,2.4 数据流图,首先考虑数据的源点和终点，从上面对系统的描述可以知道“采购部每天需要一张订货报表”，“通过放在仓库中的CRT终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。,第一步可以从问题描述中提取数据流图的4种成分：,2.4.2 例子,第2章可行性研究,2.4 数据流图,因此必须有一个用于产生报表的处理。事务的后果是改变
38、零件库存量，然而任何改变数据的操作都是处理，因此对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。,第二步：再一次阅读问题描述，“采购部需要报表”,2.4.2 例子,第2章可行性研究,2.4 数据流图,系统把订货报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个处理在时间上明显不匹配每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。因此，用来产生订货报表的数据必须存放一段时间，也就是应该有一个数据存储。,第三步：考虑数据流和数据存储,2.4.2 例子,第2
39、章可行性研究,分析结果,步骤一：,2.4.2 例子,第2章可行性研究,把数据流图的4种成分都分离出来以后（上图所示），就可以着手画数据流图了,步骤二：,2.4.2 例子,第2章可行性研究,步骤三：,把基本系统模型细化，描绘系统的主要功能,2.4.2 例子,第2章可行性研究,步骤四：,对功能级数据流图中描绘的系统主要功能进一步细化,2.4.2 例子,第2章可行性研究,2.4.3 命名,2.4 数据流图,数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。因此，给这些成分起名字时应该仔细推敲。,2.4.3 命名,第2章可行性研究,2.4 数据流图,数据流命名时应注意的问题,名字应代表整个
40、数据流的内容，而不是仅仅反映它的某些成分 不要使用空洞的、缺乏具体含义的名字 在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解,2.4.3 命名,第2章可行性研究,2.4 数据流图,为处理命名时应注意的问题,通常先为数据流命名，然后再为与之相关联的处理命名。 名字应该反映整个处理的功能，而不是它的一部分功能。 名字最好由一个具体的及物动词加上一个具体的宾语组成。 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，
41、应考虑重新分解。,2.4.3 命名,第2章可行性研究,2.4.4 用途,2.4 数据流图,1、画数据流图的基本目的是利用它作为交流信息的工具。2、数据流图的另一个主要用途是作为分析和设计的工具。3、数据流图辅助物理系统的设计时，以图中不同处理的定时要求为指南，能够在数据流图上画出许多组自动化边界，每组自动化边界可能意味着一个不同的物理系统,2.4.4 用途,第2章可行性研究,2.5 数据字典,主要内容,2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析,第2章可行性研究,2.5 数据字典,概念,数据字典是关于数据的信
42、息的集合，也就是对数据流图中包含的所有元素的定义的集合。,2.5 数据字典,第2章可行性研究,2.5.1 内容,2.5 数据字典,2.5.1 内容,一般说来，数据字典应该由对下列4类元素的定义组成。,第2章可行性研究,数据元素的别名就是该元素的其他等价的名字，出现别名主要有下述3个原因：,2.5 数据字典,2.5.1 内容,第2章可行性研究,2.5.2 定义数据的方法,2.5 数据字典,由数据元素组成数据的方式只有下述3种基本类型：,2.5.2 定义数据的方法,第2章可行性研究,2.5 数据字典,第4种关系算符,=意思是等价于(或定义为)； +意思是和(即连接两个分量)； 意思是或(即从方括弧
43、内列出的若干个分量中选择一个)，通常用“|”号隔开供选择的分量； 意思是重复(即重复花括弧内的分量)； ()意思是可选(即圆括弧里的分量可有可无)。,2.5.2 定义数据的方法,第2章可行性研究,2.5.3 数据字典的用途,2.5 数据字典,2.5.3 数据字典的用途,第2章可行性研究,2.5.4 数据字典的实现,2.5 数据字典,目前，数据字典几乎总是作为CASE“结构化分析与设计工具”的一部分实现的。在开发大型软件系统的过程中，数据字典的规模和复杂程度迅速增加，人工维护数据字典几乎是不可能的。,2.5.4 数据字典的实现,第2章可行性研究,2.5 数据字典,在开发小型软件系统时暂时没有数据
44、字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据的信息。 下面给出第2.4节的例子中几个数据元素的数据字典卡片，以具体说明数据字典卡片中上述几项内容的含义。,2.5.4 数据字典的实现,2.5.4 数据字典的实现,第2章可行性研究,2.5.4 数据字典的实现,第2章可行性研究,2.5 数据字典,2.6 成本/效益分析,主要内容,2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析,第2章可行性研究,2.6.1 成本估计,2.6 成本/效益分析,软件开发成本主要表现为人力消耗(乘以平均工资则得到开发
45、费用)。成本估计不是精确的科学，因此应该使用几种不同的估计技术以便相互校验。 下面简单介绍3种估算技术。,2.6.1 成本估计,代码行技术 任务分解技术 自动估计成本技术,第2章可行性研究,2.6 成本/效益分析,任务分解技术最常用的办法是按开发阶段划分任务。典型环境下各个开发阶段需要使用的人力的百分比大致如下表所示:,2.6.1 成本估计,第2章可行性研究,2.6.2 成本/效益分析的方法,2.6 成本/效益分析,成本/效益分析方法主要从四个方面考虑,2.6.2 成本/效益分析的方法,货币的时间价值 投资回收期 纯收入 投资回收率,第2章可行性研究,货币的时间价值,通常用利率的形式表示货币的
46、时间价值。假设年利率为i，如果现在存入P元，则n年后可以得到的钱数为：,F=P(1+i)n,这也就是P元钱在n年后的价值。反之，如果n年后能收入F元钱，那么这些钱的现在价值是：,P=F/(1+i)n,2.6 成本/效益分析,2.6.2 成本/效益分析的方法,第2章可行性研究,货币的时间价值,例如，修改一个已有的库存清单系统，使它能在每天送给采购员一份订货报表。修改已有的库存清单程序并且编写产生报表的程序，估计共需5000元；系统修改后能及时订货，这将消除零件短缺问题，估计因此每年可以节省2500元，5年共可节省12500元。但是，不能简单地把5000元和12500元相比较，因为前者是现在投资的
47、钱，后者是若干年以后节省的钱。,假定年利率为12%，利用上面计算货币现在价值的公式可以算出修改库存清单系统后每年预计节省的钱的现在价值，如下表所示。,2.6 成本/效益分析,2.6.2 成本/效益分析的方法,第2章可行性研究,货币的时间价值,2.6 成本/效益分析,2.6.2 成本/效益分析的方法,第2章可行性研究,本章小结,1.了解可行性研究的必要性，以及如何进行可行性研究 2.学习系统流程图、数据流图 3.学习数据字典的概念、用途及实现 4.成本/效益分析方法,本章小结,第2章可行性研究,软件工程导论（第6版）,第3章 需求分析,第3章需求分析,为了开发出真正满足用户需求的软件产品，首先必
48、须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件，不论人们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发者带来烦恼。,引言,需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么”这个问题。,第3章需求分析,尽管目前有许多不同的用于需求分析的结构化分析方法，但是，所有这些分析方法都遵守下述准则。,引言,第3章需求分析,第3章需求分析,主要内容,主要内容,3.1需求分析的任务 3.2与用户沟通获取需求的方法 3.3分析建模与规格说明 3.4实体联系图 3.5数据规范化 3.6状态转换图 3.7其他图形工具 3.8验证软
49、件需求,第3章需求分析,3.1需求分析的任务,主要内容,3.1需求分析的任务 3.2与用户沟通获取需求的方法 3.3分析建模与规格说明 3.4实体联系图 3.5数据规范化 3.6状态转换图 3.7其他图形工具 3.8验证软件需求,第3章需求分析,3.1.1 确定对系统的综合要求,3.1 需求分析的任务,虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求。通常对软件系统有下述几方面的综合要求。,3.1.1 确定对系统的综合要求,功能需求 性能需求 可靠性和可用性需求 出错处理需求,接口需求 约束 逆向需求 将来可能提出的要求,第3章需求分析,3.1 需求分析的任务,功能需求,这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能,性能需求,性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。,第3章需求分析,3.1.1 确定对系统的综合要求,3.1 需求分析的任务,可靠性和可用性需求,可靠性需求定量地指定系统的可靠性，可用性与可靠性密切相关，它量化了用户可以使用系统的程度。,出错处理需求,这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。,
