软件工程课件

第2章 可行性研究本章主要内容2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本效益分析2.7小结2.1可行性研究的任务一、问题定义的内容 包括：明确问题的背景、开发系统的现状、开发的理由和条件、开发系统的问题要求、总体要求、问题的性质、类型范围、要实现的目标、功能规模、实现目标的方案、开发的条件、环境要求等等，然后写出问题定义报告（或称系统定义报告），以供可行性分析阶段使用。2.1可行性研究的任务二、问题定义的步骤

在问题定义阶段，系统分析员要深入现场，阅读用户写的书面报告、听取用户对开发系统的要求、调查开发系统的背景理由。还要与用户负责人反复讨论，以澄清模糊的地方、改正不正确的地方。最后写出双方都满意的问题定义报告，并确定双方是否可进行深入系统可行性研究的意向。2.1可行性研究的任务可行性研究目的：用最小的代价在尽可能短的时间内确定问题是否有可行的解决办法（解法），并是否值得取解决。可行性研究任务：经过一次大大压缩简化了的系统分析和设计过程，给出系统是否可解并值得去解的可行性研究报告。可行研究过程：通过进一步分析和澄清问题的定义（性质、目标和规模）；从现有的物理系统导出目标系统的逻辑模型；由此逻辑模型出发探索若干种可供选择的解法；对每一种解法进行可行性研究等具体过程，最后提出可行性研究报告。若有可行的解法，则推荐一个较好的方案，并制定实施计划；否则，则建议停止项目，以避免时间、资源、人力和金钱的浪费。2.1可行性研究的任务一般说来，研究可行性应该从下述几方面进行：（1）技术可行性：指使用现有的技术能否完成这个项目。（2）经济可行性：指通过对软件开发项目进行成本/效益估计，以确定软件系统可能带来的经济效益能否超过研制和维护此系统所需的费用。（3）社会因素的考虑：软件开发是否会侵犯他人、集体或国家的利益，是否违反国家的法律并可能由此而承担法律责任。2.2可行性研究的过程可行性研究步骤（1）复查系统规模和目标（2）研究目前正在使用的系统（3）导出新系统的高层逻辑模型（数据流图＋数据字典）

（4）重新定义问题（5）导出和评价供选择的方案（6）推荐方案和行动方针（7）草拟开发计划（8）书写文档、提交审查2.3系统流程图系统流程图是描绘物理系统的传统工具，它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件（程序、文件、数据库、表格、人工过程等）。注：尽管系统流程图使用的某些符号和程序流程图所用的符号相同，但系统流程图表达的是信息在系统中各个部件之间流动的情况，而不是对信息进行加工处理的控制过程。系统流程图的基本符号2.4数据流图数据流图定义 数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。数据流图是系统逻辑功能的图形表示。此外，设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能。

2.4数据流图1、符号

（1）数据流的源点和终点：在数据流图中用方框表示，在框内写上相应的名称。（2）变换数据的处理：是对数据流执行的某种操作或变换。在数据流图中加工用圆圈表示，在圆圈内写上加工名。（3）文件：是按照某种规则组织起来的、长度不限的数据。在数据流图中文件用一直线表示，在线段旁注上文件名。（4）数据流：是一组数据。在数据流图中数据流用带箭头的线表示，在其线旁标注数据流名。

2.4数据流图2、由外向里画数据流图的步骤（1）确定系统的输入输出：由于系统究竟包括哪些功能可能一时难于弄清楚，可使范围尽量大一些，把可能有的内容全部都包括进去。此时，应该向用户了解“系统从外界接受什么数据”、“系统向外界送出什么数据”等信息，然后，根据用户的答复画出数据流图的外围。2.4数据流图2、由外向里画数据流图的步骤（2）由外向里画系统的顶层数据流图 首先，将系统的输人数据和输出数据用一连串的加工连接起来。在数据流的值发生变化的地方就是一个加工。接着，给各个加工命名。然后，给加工之间的数据命名。最后，给文件命名。

2.4数据流图2、由外向里画数据流图的步骤（3）自顶向下逐层分解，绘出分层数据流图 对于大型的系统，为了控制复杂性，便于理解，需要采用自顶向下逐层分解的方法进行，即用分层的方法将一个数据流图分解成几个数据流图来分别表示。2.5数据字典

数据字典

数据字典的任务就是对于数据流图中所出现的所有被命名的图形元素在数据字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。 数据字典的内容包括：图形元素的名字、别名或编号、分类、描述、定义、位置等。 数据字典中所有的定义都应是严密的、精确的，不可有半点含混，不可有二义性。

数据词典中常用符号的含义2.6成本/效益分析

成本/效益分析的目的：

是从经济角度评价开发一个新项目是否可行、是否划算，从而帮助使用部门的负责人正确地作出是否投资于这项开发的决定。一、成本估计

1．代码行技术：通常先根据经验和历史数据来估计实现一个功能所需要的源程序行数，然后用每行代码的平均成本乘以行数就可以确定软件的成本。当有以往开发类似工程的历史数据可供参考时，这个方法是非常有效的。2.6成本/效益分析一、成本估计

2、任务分解技术：首先把软件开发工程分解为若干个相对独立的任务，再分别估计每个单独的开发任务的成本，最后累加起来得出软件开发工程的总成本。估计每个任务的成本时，通常先估计完成该项任务所需要使用的人力（以人月为单位），再乘以每人每月的平均工资而得出每个任务的成本。划分任务时最常用的办法是按开发阶段进行。如果软件系统很复杂，由若干个子系统组成，则可以把每个子系统再按开发阶段进一步划分成更小的任务。2.6成本/效益分析二、成本/效益分析的方法估计软件生命周期的必要性

运行费运取决于系统的操作费用（操作人员人数，工作时间，消耗的物资等）和维护费用。系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。因为运行费用和经济效益两者在软件的整个生命周期内都存在，总的效益和生命周期的长度有关，所以应该合理地估计软件的寿命。为保险起见，以后在进行成本/效益分析时一律假设生命周期为5年。2.6成本/效益分析二、成本/效益分析的方法1．货币的时间价值

从经济角度判断系统是否值得投资，应该比较新系统的开发成本和经济效益。但是，投资是现在进行的，效益是将来获得的，不能简单地比较成本和效益，应该考虑货币的时间价值。货币的时间价值通常用利率的形式表示。假设年利率为i，如果现在存入P元，则n年后可以得到的钱数为：

F＝P×(1十i)n

2.6成本/效益分析二、成本/效益分析的方法

这也就是P元钱在n年后的价值。反之，如果n年后能收入F元钱，那么这些钱的现在的价值是：

P＝F÷(1十i)n2．投资回收期 所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间。显然，投资回收期越短就能越快获得利润，这项工程也就越值得投资。2.6成本/效益分析二、成本/效益分析的方法3．纯收入

纯收入就是在整个生命周期之内系统累计经济效益（折合成现在值）与投资之差。这相当于比较投资开发一个软件系统和把钱存在银行中（或贷给其他企业）这两种方案的优劣。第三章需求分析本章主要内容

3.1需求分析的任务

3.2与用户沟通获取需求的方法

3.3分析建模与规格说明3.4实体---联系图

3.5数据规范化

3.6状态转换图

3.7其它图形工具

3.8验证软件需求第三章需求分析软件定义时期的三个任务

问题定义，用来界定问题。

可行性研究，用较小的成本在较短的时间内确定是否存在可行的解法。需求分析，用来确定系统必须完成哪些工作，而不是确定系统怎样完成它的工作，其基本任务是准确地回答“系统必须做什么”。需求分析的必要性系统分析员与程序员往往与用户有着不同的知识背境。3.1需求分析的任务需求分析的主要任务

1、确定对系统的综合要求

2、分析系统的数据要求

3、导出系统的逻辑模型

4、修正系统开发计划3.1需求分析的任务一、确定对系统的综合要求

1、功能需求划分出系统必须完成的所有功能。

2、性能需求通常包括对速度、信息量速率、主存容量、磁盘容量、安全性和方面的需求。

3、可靠性和可用性需求定量的指定系统的可靠性，量化了用户可以使用系统的程度。

3.1需求分析的任务一、确定对系统的综合要求4、出错处理需求一方面，系统可以处理错误的信息输入，这类错误不是由系统本身造成的；另一方面，系统发现它本身犯下一个错误时所采取的行动。5、接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户、硬件、软件、通信接口需求。6、约束指实现应用系统时应遵守的限制条件。常见的有：精度、工具和语言约束、设计约束、硬件平台约束。3.1需求分析的任务一、确定对系统的综合要求7、逆向需求说明软件系统“不应该做什么”，仅选择能澄清真实需求且可消除可能发生的误解的那些逆向需求。8、将来可能提出的要求设计过程中对系统将来可能的扩充和修改预做准备。二、分析系统的数据要求软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌。3.1需求分析的任务二、分析系统的数据要求

分析系统的数据要求通常方法：

1、数据建模，最基本方法。

2、数据字典，定义基本数据元素及其之间的逻辑关系，但不够形象直观。

3、图形工具，用来辅助描绘数据结构，常用的有层次方框图和Warnier图。三、导出系统的逻辑模型

常采用数据流图、实体—联系图，状态转换图、数据字典和主要的处理算法来描述这个逻辑模型。3.1需求分析的任务四、修正系统开发计划

通过在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。3.2与用户沟通获取需求的方法常用的方法：

1、访谈2、面向数据流自顶向下求精3、简易的应用规格说明技术4、快速建立软件原型3.2与用户沟通获取需求的方法一、访谈

有两种基本形式，分别是正式和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题；非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。当需要调查大量人员的意见时，发调查表法也是一个十分有效的做法。

3.2与用户沟通获取需求的方法一、访谈

情境分析技术，就是系统分析员根据自己对目标系统应具备的功能的理解，对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。该技术便于用户指出分析中的错误，从而能够获知用户的具体要求，起到了“投石问路”的作用。情境分析技术的用处：两个方面（略）二、面向数据流自顶向下求精目标：把数据流和数据存储定义到元素级。3.2与用户沟通获取需求的方法二、面向数据流自顶向下求精

实施途径：沿数据流图从输出端往输入端回溯，应该能够确定每个数据元素的来源，与此同时也就初步定义了有关的算法。

实施结果：系统中更多的数据元素被划分出来了，更多的算法被搞清楚了。对结果的复查：分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。

3.2与用户沟通获取需求的方法三、简易的应用规格说明技术

一种面向团队的需求收集法，简易的应用规格说明技术已经成为信息系统领域使用的主流技术。分析需求的典型过程如下：1、确定问题范围和解决方案，发出会议邀请2、会议前的产品需求审查3、确立新产品，展示个人列表并进行讨论4、建立针对每个议题的组合列表，进行讨论。5、细分小组，为每张列表中的项目制定小型规格说明6、展示小型规格说明7、创建意见一致的确认标准3.2与用户沟通获取需求的方法四、快速建立软件原型

快速建立起来的旨在演示目标系统主要功能的可运行的程序。两个特点：“快速”、“容易修改”三种方法和工具：第四代技术、可重用的软件构件、形式化的规格说明原型环境。形式规格说明语言缺点：自身的抽象化，另外还没有实现自动化。3.3分析建模与规格说明模型：就是为了理解事物而对事物作出的一种抽象，由一组图形符号和组织这些符号的规则组成。需求分析的两大任务：创建分析模型、写出软件需求规格说明书。一、分析建模

需求分析过程应建立三种模型——数据模型、功能模型、行为模型。实体联系图

数据模型数据流图

功能模型状态转换图

行为模型3.3分析建模与规格说明二、软件需求规格说明

两种说明工具——自然语言、形式语言。自然语言可以完整、准确、具体地描述系统的各种需求，但用自然语言说明时可能存在不一致、歧义、含糊、不完整及抽象层次混乱等问题。

3.4实体—联系图概念性数据模型：是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现无关。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此的联系。一、数据对象定义：是对软件必须理解的复合信息的抽象，而复合信息是指具有一系列不同性质或属性的事物，可以由一组属性定义的实体都可以被认为是数据对象。数据对象的性质：关联性、封装性3.4实体—联系图二、属性定义了数据对象的性质。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。三、联系

客观世界中的事物彼此间往往是有联系的，这种数据对象彼此间的相互联系的方式称为联系（关系）。联系的分类：（1）一对一联系（1：1）（2）一对多联系（1：N）

（3）多对多联系（M：N)3.4实体—联系图四、实体联系图

又叫ER图，把用ER图描绘的数据模型称为ER模型。

ER图中包含的三种符号：矩形框（表示实体）、菱形框（表示实体的关系）、椭圆形或圆角矩形（表示实体的属性）。3.6状态转换图需求分析过程中建立软件系统行为模型的工具，通过描绘系统的状态及引起系统状态转换的事件来表示系统的行为。一、状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，规定了系统对事件的响应方式。系统对状态的响应方式有三种：做一个（或一系列）动作、改变系统本身的状态、既改变状态又做动作。状态的分类：初态、终态、中间状态。注：一张状态表中只能有一个初态，而终态则可以有0个至多个。3.6状态转换图二、事件

对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象，就是引起系统做动作或（和）转换状态的控制信息。三、符号

符号的种类：实心圆（初态）、同心圆（终态）圆角矩形（中间状态）、带箭头连线（状态转换）。中间状态的分割：分上中下三部分，分别表示状态名称（必有项）、状态变量的名字和值（可选项）、活动表（可选项）。3.6状态转换图三、符号

活动表中的格式：事件名（参数表）/动作表达式。其中，事件名有三种标准类型，entry（进入该状态的动作）、exit（退出该状态的动作）、do（在该状态下的动作）。事件表达式：通常写在状态转换的箭头线上，标出触发转换的事件。其格式为：事件说明[守卫条件]/动作表达式其中，守卫条件是一个布尔表达式（结果为0或1）其执行过程为：同时使用事件说明和守卫条件，当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真，状态转换就发生。3.7其它图形工具前在已介绍了用于建立模型的数据流图、用于建立数据模型的实体—联系图和用于建立行为模型的状态图，本节再简要地介绍在需求分析阶段可能用到的另外几种图形工具。

层次方框图随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。

IPO图它是由美国IBM公司发展起来的一种图形工具，能够方便地描绘输入数据，对数据的处理和输出数据之间的关系。3.8验证软件需求一、验证软件需求的目的：为了提高软件质量,确保软件开发成功,降低软件开发成本。二、软件需求验证的几个方面：

1、一致性需求分析的两种书写方法:(1)自然语言(2)形式语言用自然语言书写时，往往用人工的方法验证需求的一致性，而当目标系统规模庞大时，人工审查的效果是没有保证的，冗余、遗漏和不一致等问