软件工程课件

软件工程第2章需求分析

本章要点：需求分析的任务和原则可行性研究的任务和步骤结构化分析分析方法和面向对象分析方法需求建模与规格说明软件需求验证软件工程本章学习目标：了解需求分析的任务和原则掌握可行性研究的步骤掌握结构化分析分析方法和面向对象分析方法了解需求建模与规格说明了解软件需求验证方法和有关工具软件工程2.1需求分析的任务

需求分析的基本任务是准确地回答“系统必须做什么?”这个问题。目标系统提出完整、准确、清晰、具体的要求。需求分析阶段的具体任务一、确定对系统的综合要求。

对系统的综合要求有下述四个方面：

1．系统功能要求

应该划分出系统必须完成的所有功能。

软件工程2．系统性能要求

例如，联机系统的响应时间(即对于从终端输入的一个“事务”，系统在多长时间之内可以做出响应)，系统需要的存储容量以及后援存储，重新启动和安全性等方面的考虑都属于性能要求。

3．运行要求这类要求集中表现为对系统运行时所处环境的要求。例如，支持系统运行的系统软件是什么，采用哪种数据库管理系统，需要什么样的外存储器和数据通信接口等。

软件工程4．将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦需要时能比较容易地进行这种扩充和修改。二、分析系统的数据要求任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立概念模型的方法。软件工程复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图。

三、导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、数据字典和主要的处理算法描述这个逻辑模型。

四、修正系统开发计划根据在分析过程中获得的对系统的更深入更具体的了解，软件工程可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。五、开发原型系统在计算机硬件和许多甚他工程产品的设计过程中经常使用样机。建造样机通常有两个主要目的：检验关键设计方案的正确性及系统是否真正满足用户的需要。对于软件系统的开发，使用“样机”(更正确的名称应该是原型系统)的主要目的是，使用户通过实践获得关于未来的系统将怎样为他们工作的更直接更具体的概念，从而可以更准确地提出和确定他们的要求。软件工程2.2需求分析的原则

需求分析的前提是准确、完整地获取用户需求。向问题领域的专家学习，进行用户需求查是需求分析的第一步。用户需求通常可以分为功能需求和性能需求两类。功能需求定义了系统应该做什么，系统要求输入什么信息，输出什么信息，以及如何将输入变换为输出。性能需求则定义了软件运行的状态特征，如系统运行效率，可靠性，安全性，可维护性等等。综合起来，应该获取用户需求的内容包括：(1)物理环境。系统运行的设备地点、位置是集中式的还是分布式的，对环境的要求如何(如温度、湿度，电磁场干扰等)。

软件工程(2)系统界面。要求与其他系统进行数据交换的内容与格式，终端用户的类型与熟练程度，用户对界面的特定要求，用户操作的易接受性等。(3)系统功能。系统应该完成的功能以及何时完成，对于系统运行速度、响应时间或者数据吞吐量的要求，系统运行的权限规定，系统可靠性要求，是否要求可移植，未来扩充或者升级的要求。(4)数据要求。输入偷出数据的种类与格式，计算必须达到的精度，数据接收与发送的频率，数据存储的容量和可靠性，数据或者文件访问的控制权限，数据备份的要求。软件工程(5)系统文档规格。系统要求交付什么文档，各类文档的编制规范和预期使用对象。(6)系统维护要求。系统出错后可以允许的最大恢复时间，对错误修改的回归测试要求，系统运行日志规格，是否允许对系统修改，系统变化如何反映到设计中。在获取需求过程中遇到的典型问题及其解决方法是：(1)如何理解问题。大多数情况下，软件开发人员不是问题领域的行家。但是要准确、完整的获取需求必须对问题具有深入的理解与把握。许多问题即使是用户业务人员也可能没有自觉的认识。(2)分析员与用户的通信问题。分析员对问题的理解软件工程必须从信息处理要求出发，而用户更多的考虑是本身的业务领域。与用户建立相互信任、有效的沟通是分析员的首要任务。(3)用户需求的可变性。用户需求通常是不断变化的，而软件开发人员则希望将需求冻结在某一时刻。影响用户需求变化的因素可以是用户领域的业务扩充或者转移，市场竞争的要求，用户主管人员的变更等。现实情况是分析员只能接受需求不断变化的事实，应该千方百计地使其工作适应需求的变化。现实世界是复杂多变的。为了将现实世界中问题的求解映射为信息处理模型，对问题进行分解与抽象是普遍有效的基本法则。

软件工程2.3可行性研究

2.3.1可行性研究的任务可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。确定问题是否值得去解。首先需要进一步分析和澄清问题定义。在问题定义阶段初步确定的规模和目标，如果

是正确的就进一步加以肯定，如果有错误就应该及时改正，如果对目标系统有任何约束和

限制，也必须把它们清楚地列举出来。

在澄清了问题定义之后，分析员应该导出系统的逻辑模型。然后从系统逻辑模型出

发，探索若干种可供选择的主要解法(即系统实现方案)。对每种解法都应该仔细研究它的

可行性，一般说来，至少应该从下述三方面研究每种解法的可行性：

软件工程(1)技术可行性使用现有的技术能实现这个系统吗?(2)经济可行性这个系统的经济效益能超过它的开发成本吗?(3)操作可行性系统的操作方式在这个用户组织内行得通吗?

分析员应该为每个可行的解法制定一个粗略的实现进度。软件工程2.3.2可行性研究的步骤

一、复查系统规模和目标

分析员访问关键人员，仔细阅读和分析有关的材料，以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。二、研究目前正在使用的系统

现有的系统是信息的重要来源。显然，如果目前有一个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功能；另一方面，如果现有的系统是完美无缺的，用户自然不会提出开发新系统的要求，因此，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。

软件工程

应该仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。三、导出新系统的高层逻辑模型

优秀的设计过程通常总是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。四、重新定义问题

新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。用户是否也有

同样的看法呢?分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查软件工程应该把数据流图和数据字典作为讨论的基础。五、导出和评价供选择的解法分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法供比较和选择。导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。在数据流图上划分不同的自动化边界，从而导出不同物理方案的方法。当从技术角度提出了一些可能的物理系统之后，应该根据技术可行性的考虑初步排除一些不现实的系统。软件工程其次可以考虑操作方面的可行性。接下来应该考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发

成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，这个进度表不

需要(也不可能)制定得很详细，通常只需要估计生命周期每个阶段的工作量。六、推荐行动方针根据可行性研究结果应该做出的一个关键性决定是，是否继续进行这项开发工程。分

析员必须清楚地表明他对这个关键性决定的建议。

软件工程七、草拟开发计划分析员应该进一步为推荐的系统草拟一份开发计划，除了工程进度表之外还应该估计对各种开发人员(系统分析员，程序员，资料员等等)和各种资源(计算机硬件，软件工具等等)的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本。最后应该给出下一个阶段(需求分析)的详细进度表和成本估计。八、书写文档提交审查应该把上述可行性研究各个步骤的结果写成清晰的文档，请用户和使用部门的负责人仔细审查，以决定是否继续这项工程以及是否接受分析员推荐的方案。

软件工程2.3.3系统流程图

系统流程图是描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件(程序、文件、数据库、表格、人工过程等等)。一、符号

当以概括的方式抽象地描绘一个物理系统时，仅仅使用图2．1中列出的基本符号就够了，其中每个符号表示系统中的一个部件。当需要更具体地描绘一个物理系统的时候还需要使用图2．2中列出的系统符号，利用这些符号可以把一个广义的输入／输出操作具体化为读／写存储在特殊设备上的文件(或数据库)，把一般的处理具体化为特定的程序或手工操作等等。

软件工程图2．1基本符号符号名

称说

明处理能改变数据值或数据位置的加工或部件，例如，程序、处理机、人工加工等都是处理

输入／输出表示输入或输出(或既输入又输出)，是一个广义的不指明具体设备的符号。

连接指出转到图的另一部分或从图的另一部分转来，通常在同一页上

换页连接指出转到另一页图上或由另一页图转来。

数据流用来连接其他符号，指明数据流动方向。

软件工程图2.2系统符号符号名

称

穿孔卡片表示用穿孔卡片输入或输出，也可表示一个穿孔卡片文件。

文档通常表示打印输出，也可表示用打印终端输入数据。

磁带磁带输入／输出，或表示一个磁带文件。

联机存储表示任何种类的联机存储，包括磁盘、磁鼓、软盘和海量存储器件等。

磁盘磁盘输入／输出。也可表示存储在磁盘上的文件或数据库。

磁鼓磁鼓输入／输出，也可表示存储在磁鼓上的文件或数据库。

显示CRT终端或类似的显示部件，可用于输入或输出，也可既输入又输出。

人工输入人工输入数据的脱机处理，例如，填写表格。

人工操作人工完成的处理，例如，会计在工资支票上签名。

辅助操作使用设备进行的脱机操作。

通信链路通过远程通信线路或链路传送数据。

软件工程二、例子

介绍系统流程图的最好方法可能是通过一个具体例子说明它的用法。下面是一个简单的例子。某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便定货，规定每天向采购部门送一次定货报告。该装配厂使用一台小型计算机处理更新库存清单主文件和产生定货报告的任务。零件库存量的每一次变化称为一个事务，通过放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在软件工程磁盘上的库存清单主文件，并且把必要的定货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出定货报告。图2．3的系统流程图描绘了上述系统的概貌。事务库存清单程序订货信息报告生成程序订货报告库存清单主文件图2.3库存清单系统的系统流程图软件工程三、分层面对复杂的系统时，一个比较好的方法是分层次地描绘这个系统。首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。这种分层次的描绘方法便于阅读者按照从抽象到具体的过程逐步深入地了解一个复杂的系统。

软件工程2.4需求分析方法

2.4.1结构化分析方法结构化分析技术是70年代中期由E．Yourdon等人倡导的一种面向数据流的分析方法。按照T．Demarco的定义，“结构化分析就是使用数据流图、数据词典、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档。”这里的结构化说明书，就是需求规格说明书。结构化分析技术将软件系统抽象为一系列的逻辑加工单元，各单元之间以数据流发生关联。按照数据流分析的观点，系统模型的功能是数据变换，逻辑加工单元接受输入数据流，使之变换成输出数据流。数据流模型常用数据流图表示。

软件工程

建立功能模型

数据流程图，又称数据流图，它是以图形的方式来表达数据处理系统中信息的变换和传递过程。作为一种描述手段，它可以模拟手工的、自动的以及两兼而有之混合的数据处理过程。数据流程图有三个重要属性：

．可以表示任何一个系统(人工的、自动的或混合的)中的信息流程。

．每个圆圈可能需要进一步分解以求得对问题的全面理解。

．着重强调的是数据流程而不是控制流程。软件工程以工资处理为例，我们画出这一过程中数据加工过程各项活动的数据流程图(见2.4)。图2.4可知，数据流程图中的基本符号有：1、数据流数据流是有名字有流向的数据，在数据流程图中，数据流用标有名字的箭头来表示，如图2.1中的工资调整表、工资发放表等。2、加工加工又称处理逻辑，表示数据所进行的加工或变换，图2.4中以标有名字的圆圈代表加软件工程工资汇总表工资发放表工资条工资计算工资册取款总务人事工资汇总工资分配开户银行职工统筹医疗费房租费水电费托儿费工资调整表调入人员工资单调出人员调出单病事假扣款单工资费用分配表工资发放图2.4工资处理数据流程图软件工程工。指向加工的数据流是该加工的输入数据，离开加工的数据流是该加工的输出数据，如图2.4中的工资计算、取款等。3、文件文件是数据暂存的处所，可对文件进行必要的存取，在图中以标有名字的双直线段表示，如图2.1中的工资册、工资汇总表等。对文件的存取分别以指向或离开文件的箭头表示。由于文件的内容能顾名思义，因而对其进行存取的箭头即使没有名字也不会造成混乱。4、数据源及数据终点表明数据处理过程的数据来源或数据去向的标志称为软件工程数据源及数据终点，在数据流程图中均以命名的方框来表示，如图2.4中的人事（科）。一般情况下，为了表达数据处理的数据加工过程，只用一个数据流程图是不够的。对稍为复杂一些的实际问题，常以层次结构的数据流程图来表示。任何系统都是有层次的结构，如果按照层次结构对系统进行逐步分解，就能很清楚地表达和理解整个系统。在每一个层次上，最核心的部分就是数据加工乃其相关的数据流。除了上述4种基本成分外，数据流程图还有几种附加成分，例如，星号“﹡”表示几股数据流之问是“与”的关系，加号“+”表示“或”的关系，⊙号表示从几股数据流中选取一股，软件工程即表示“互斥”的关系。我们来研究一个财务管理信息系统中的材料核算部分。图2.2中的基本系统模型把整个材料核算工作抽象成一个加工，并标上所有的输入数据流和输出数据流，即为材料核算子系统的项层数据流程图。有关材料统计报表材料分类明细帐材料采购付款凭证材料核算采购合同收料凭证发料凭证材料汇总表图2.5顶层数据流程图软件工程把材料核算处理功能进行分解。一般材料核算包括采购核算、储存核算、发出核算等，据此，我们画出如图2.5所示的第一层数据流程图。分解后的子图中生出了一些新的数据流和文件，它们是顶层数据流程图中加工“材料核算”内部的数据流和文件，与其外部元素没有联系。在“材料核算”被分解后，这些数据流和文件成了一些子加工的界面。分别把第一层数据流程图中的几个核算处理（加工）再进行分解，可画出第二层数据流程图。图2.5为其中的加工“材料发出核算”进行功能分解得到第二层数据流程图，其他如材料采购核算、材料储存核算等，都可以用同样的方法讲行分解扩展，画出相应的数据流程图。

软件工程图2.5、图2.6和图2.7画出了3种不同层次的信息流程，表示出需求分析一层比一层更为具体细致。软件工程收购凭证采购核算储存核算发出核算材料汇总核算材料采购付款凭证采购合同发料凭证材料明细帐材料汇总表材料明晰分类帐有关材料统计报表材料采购合同执行情况材料采购成本材料采购明细帐材料发出凭证生成用料应摊材料成本差异表其他用料存储材料明细帐生产材料分配表图2.6第一层数据流程图软件工程图2.7第二层数据流图生产用料分配表材料发出凭证材料发出凭证按用途归类按产品分配车间管理用料企业管理用料辅助生产用料材料明细表生产用料应摊材料成本差异软件工程

数据流程图是一种图解方法，它在软件需求分析中是非常有用的。然而，如果它的作用与程序流程图(框图)混淆的话，也会引起混乱。数据流程图描绘的是信息流，没有明显的控制说明(例如条件或循环)，它不是一个用圆圈表示的程序流程图。在推导面向软件的数据流时有几个非常有用而简单的准则：1、

1、

一层数据流程图应当是基本系统模型。2、应当仔细说明原始的输入／输出文件。3、所有箭头和圆圈均应加上标注(使用有意义的名字)。

4、必须维持信息的连续性。

软件工程5、每一次只应当细化一个圆圈。

6、可以在数据流程图中加上物质流。有助于帮助用户理解该数据流程图。在画分层数据流程图时，要特别注意下面几个问题：

1、加工的编号方法

加工的编号遵循两条原则：第一，从加工的编号能知道该加工处在哪一层分解；第二，从加工编号知道该加工是从父图中哪个加工分解得来的。2、分解程度

分解程度问题包括两个方面，其一是每个加工每次软件工程分解成几个子加工比较恰当；其二是分解深度，即分解的层数问题。这两个问题之间有一定的联系。经验表明，一个加工的分解以不超过7个子加工比较合适。3、父图和子图之间的平衡多层数据流程图中的父图和子图之间的数据流必须保持一致(或称保持“平衡“)，亦即，父图中出现的输入数据流和输出数据流都应在子图中出现，以保证加工过程的连续性和一致性。有时，当在子图中对父图的数据流做了分解后，检验父图和子图的平衡还需借助于数据字典。因为“自顶向下”逐层对数据流程图的分解，实际上不仅是对加工进行分解，同时也对数据流进行分解。软件工程

建立数据模型

在需求分析阶段则既要分析用户的数据要求（即需要哪些数据、数据之间有什么联系、数据本身有什么性质、数据的结构等等），又要分析用户的处理要求(即对数据进行哪些处理、每个处理的逻辑功能等等)。为了把用户的数据要求清晰明确地表达出来，系统分析员通常建立一个概念性的数据模型(也称为信息模型)。概念性数据模型是一种面向问题的数据模型，是按照用户的观点来对数据和信息建模。它描述了从用户角度看到的数据，它反映了用户的现实环境，且与在软件系统中的实现方法无关。最常用的表示概念性数据模型的方法，是实体一联系方法(Entity—RelationshipApproach)。这种方法用ER图。软件工程描述现实世界中的实体，而不涉及这些实体在系统中的实现方法。用这种方法表示的概念性数据模型又称为ER模型。通常，软件系统中有许多数据是需要长期保存的，为减少数据冗余，简化修改数据的过程，应该对数据进行规范化。ER模型中包含“实体”、“联系”和“属性”等三个基本成分，下面分别介绍这三个基本成分：1．实体

实体是客观世界中存在的且可相互区分的事物。实体可以是人也可以是物；可以是具体事物也可以是抽象概念。例如，职工、学生、课程、教师等都是实体。在ER图中用矩形框代表实体。软件工程2．联系客观世界中的事物彼此间往往是有联系的。例如，教师与课程间存在“教”这种联系，而学生与课程间则存在“学”这种联系。联系可分为三类：(1)一对一联系(1︰1)例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。

(2)一对多联系(1︰N)例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。软件工程(3)多对多联系(M︰N)例如，学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门程，而每门课程可以有多个学生来学。在ER图中，用连接相关实体的菱形框表示联系。3．属性属性是实体或联系所具有的性质。通常一个实体由若干个属性来刻画。例如，“学生”实体有学号、姓名、性别、系、年级等属性；“教师”实体有教工号、姓名、性别、职称、职务等属性；“课程”实体有课程号、课名、学时、学分等属性。软件工程联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性。N1NM教师教工号性别姓名职称职务教师教师教学姓名性别系年级学号成绩课程号课名学时学分图2.8某校教学管理ER图软件工程

在ER图中用椭圆形或圆角矩形表示实体(或联系)的属性，并用无向边把实体(或联系)与其属性连接起来。人们通常就是用实体、联系和属性这三个概念来理解现实问题的，因此，ER模型比较接近人的习惯思维方式。此外，ER模型使用简单的图形符号表达系统分析员对问题域的理解，不熟悉计算机技术的用户也能理解它，因此，ER模型可以作为用户与分析员之间有效的交流工具。

4．范式通常用“范式(NormalForms)”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5NF)数据冗余程度最小。但是，范式级别越高，存储同样数据就软件工程需要分解成更多张表，因此，“存储自身”的过程也就越复杂。第二，随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。第三，范式级别提高则需要访问的表增多，因此性能（速度）将下降。从实用角度看来，在大多数场合选用第三范式都比较恰当。

1．第一范式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。2．第二范式满足第一范式条件，而且每个非主属性完全依赖于某个软件工程候选键(而不是部分依赖于某个候选键)3．第三范式。符合第二范式的条件，所有非主属性即不部分依赖于某个候选键，也不传递依赖于某个候选键。

软件工程

建立行为模型

状态转换图通过描述状态以及导致系统改变状态的事件来表示系统的行为，它没有表示出系统所执行的处理，只表示了处理结果可能的状态转换。STD用带标记的圆圈或矩形表示状态，用箭头表示从一种状态到另一种状态的变换，箭头上的文本标记表示引起变换的条件。转换条件状态图2.9状态转换图基本图形元素软件工程分析建模是实现真实世界模型向计算机模型转换的核心环节，也是一种处理软件复杂性的有效手段。在需求开发阶段，分析建模的关键是针对用户需求建立抽象的分析模型，从而有助于开发人员理解用户需求，同时增强自然语言的需求规格说明。分析模型往往采用一些图形化的表示方式，从数据、功能和行为等不同角度表达用户需求。结构化分析是面向数据流进行需求分析的方法，经过20多年的发展，已经成为广泛应用的技术之一。结构化分析方法以数据字典为核心，采用实体关系图、数据流图和状态转换图等图形来表达需求，直观明了且易于理解和掌握。

软件工程

数据词典

数据字典是结构化分析方法的一个有力工具，它对数据流程图中出现的所有数据元素给出逻辑定义。有了数据字典，使数据流程图上的数据流、加工和文件能得到确切的解释。

数据字典的条目可以分成四大类，即：

·数据流条目。

·文件条目。

·数据项条目。

·加工条目。软件工程数据字典中的数据构成如图2.10所示的层次关系。这些数据元素的定义通常用定义式的形式给出。图2.10数据字典中数据的层次关系数据流文件数据结构数据元素软件工程通常，在数据字典的定义式中可能出现的符号及其含意是(设x和a、b都是数据元素)：

x=a+bx由a和b构成

x=[a︱b]x由a或b构成

x=(a)数据元素a在x中可出现，也可不出现

x={a}x由0个或多个重复的a构成软件工程1、数据流条目数据流条目主要说明数据流条目是由哪些数据项组成的，以及数据在单位时间内的流量，它的来源、去向等。条目格式如下：数据流名：组成：流量：来源：去向：软件工程例如：数据流“银行对账单”条目：条目格式如下：数据流名：银行对帐单组成：月份＋日期＋银行支票＋金额流量：2张∕3天，每张约40笔数据来源：开户银行去向：资金管理组软件工程2、文件条目文件条目主要说明文件由哪些数据项组成，存储方式和存取频率等。条目格式如下：文件名：

组成：

存储方式：

存储频率：软件工程例如：文件“现金日记账”条目如下：文件名：现金日记账

组成：月份＋日期＋摘要＋收入＋支出＋结存

存储方式：顺序

存储频率：20笔∕天软件工程3、数据项条目

数据项名：

类型：

长度：

取值范围：数据项条目主要说明数据项类型、长度、取值范围等。软件工程例如：数据项“凭证号”条目和数据项“经办人”条目如下：

数据项名：凭证号

类型：数值

长度：6位（含小数一位）

取值范围：1000.0～4999.9软件工程4、加工条目加工条目主要说明加工的输入数据、输出数据及其加工逻辑等。条目格式如下：

加工名：

输入数据：

输出数据：

加工逻辑：

软件工程例如加工“工资分配”条目：加工名：工资分配输入数据：工资结算单(汇总表)输出数据：工资费用分配表加工逻辑：各车间根据工资结算单，按产品种类或批别，分别分配管理人员工资和生产工人工资，并按比例提取福利基金。

软件工程

和数据流程图的层次概念相类似，一个数据字典的定义式不宜包含过多的项，这可以采取逐级定义的定义式，使得一些复杂的数据元素自顶向下多层定义，直到最后给出无需定义的基本数据元素。例如：日期=年+月+日数据字典就是这样构造起来的一组定义式。必要时，定义式之间还可能有一些特定的注释行出现，以利于理解。常用的词典相似，数据字典所收集的数据定义，都按词典的编辑方法顺序排列，以方便使用。当然，不允许出现一个数据元素有多个定义的现象。

软件工程2.4.2面向对象分析方法与UML

面向对象分析方法面向对象方法是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO方法，它是建立在对象概念(对象、类和继承)基础上的方法。面向对象方法成为90年代的主流开发方法，其原因主要在于：

1．从认知学的角度来看，面向对象方法符合人们对客观世界的认识规律

2．面向对象方法开发的软件系统易于维护，其体系结构易于理解、扩充和修改

3．面向对象方法中的继承机制有力支持软件的复用

软件工程一、面向对象的基本概念PeterCoad和EdwardYourdon提出用下列等式来认识面向对象方法：面向对象=对象(Obiect)+分类(Classification)+继承(Inheritance)+通过消息的通信(CommunicationWithMessages)可以说，采用这4个概念开发的软件系统是面向对象的。1．对象

对象是指一组属性以及这组属性上的专用操作的封装体。属性通常是一些数据，有时它也可以是另一个对象。

软件工程

对象中的属性只能通过该对象所提供的操作来存取或修改。操作也称为方法或服务，它规定了对象的行为，表示对象所能提供的服务。封装是一种信息隐蔽技术，用户只能看见对象封装界面上的信息，对象的内部实现对用户是隐蔽的，封装的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。一个对象通常可由对象名、属性和操作三部分组成。

2．类

类是一组具有相同属性和相同操作的对象的集合。一个类中的每个对象都是这个类的一个实例。

不必为每个对象逐个定义，只需对类作出定义，而对类的属性的不同赋值即可得到该类的对象实例，类和软件工程

对象之间的关系类似于程序设计语言中的类型和变量之间的关系。通常把一个类和这个类的所有对象称为类及对象，或称为对象类。一个类可以定义为另一个更一般的类的特殊情况，如“轿车”类是“汽车”类的特殊情况，我们称一般类是特殊类的父类，特殊类是一般类的子类。这样可以形成类的一种一般一特殊的层次关系。在这种一般一特殊的关系中，子类可以继承其父类(或祖先类)的所有属性和操作，同时子类中还可以定义自己特有的属性和操作。所以子类的属性和操作是子类中的定义部分和其祖先类中的定义部分的总和。继承是类间的基本关系，它是基于层次关系的不同类共享数据和操作的一种机制。父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和软件工程操作外，还可以对父类(或祖先类)中的操作重新定义其实现方法。如果一个子类只有惟一一个父类，这个继承称为单一继承。如果一个子类有一个以上的父类，这种继承称为多重继承。

3．消息传递消息传递是对象间通信的手段，一个对象通过向另一个对象发送消息来请求其服务。一个消息通常包括接收对象名、调用的操作名和适当的参数(如果有必要的话)。消息只告诉接收对象需要完成什么操作，但并不指示接收者怎样完成操作。消息完全由接收者解释，接收者独立决定采用什么方法完成所需的操作。软件工程4．多态性

多态性是指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。例如“画”操作，作用在“矩形”对象上，则在屏幕上画一个矩形，作用在“圆”对象上，则在屏幕上画一个圆。也就是说，相同操作的消息发送给不同的对象时，每个对象将根据自己所属类中定义的这个操作去执行，从而产生不同的结果。

与多态性密切相关的一个概念就是动态绑定(亦称动态定连)。传统的程序设计语言的过程调用与目标代码的连接(即调用哪个过程)放在程序运行前进行(称为静态绑定)，而动态绑定则是把这种连接推迟到运行时才进行。

软件工程二、面向对象分析

面向对象分析(Object—Oriented．Analysis，OOA)的目标是完成对所解问题的分析，确定待建的系统要做什么，并建立系统的模型。为达到这一目标，必须完成以下任务：

(1)在客户和软件工程师之间沟通基本的用户需求。

(2)标识类(包括定义其属性和操作)。

(3)刻画类的层次结构。

(4)表示类(对象)之间的关系。

(5)为对象行为建模。

软件工程(6)递进地重复任务(1)至任务(5)，直至完成建模。

其中任务(2)至任务(4)刻画了待建系统的静态结构，任务(5)刻画了系统的动态行为。

面向对象分析的一般步骤如下：

(1)获取客户对系统的需求：包括标识场景(Scenario)和用例(IJseCase)，以及建造需求模型。

(2)用基本的需求为指南来选择类和对象(包括属性和操作)。

(3)定义类的结构和层次。

(4)建造对象．关系模型。

软件工程(5)建造对象一行为模型。(6)利用用例／场景来复审分析模型。三、面向对象设计

面向对象设计(Object-Oriented．Design，OOD)是将OOA所创建的分析模型转化为设计模型。与传统的开发方法不同，OOD和OOA采用相同的符号表示，OOD和OOA没有明显的分界线，它们往往反复迭代地进行。在OOA时，主要考虑系统做什么，而不关心系统如何实现。在OOD时，主要解决系统如何做，因此需要在OOA的模型中为系统的实现补充一些新的类，或在原有类中补充一些属性和操作。OOD时应能从类中导出对象，以及这些对象如何互相关联，还要描述对象间的关系、行为以及对象间的通信如何实现。

软件工程OOD同样应遵循抽象、信息隐蔽、功能独立、模块化等设计准则。

面向对象设计的一般步骤如下：

(1)系统设计。·将子系统分配到处理器。

·选择实现数据管理、界面支持和任务管理的设计策略。

·为系统设计合适的控制机制。

·复审并考虑权衡。

软件工程(2)对象设计。

·在过程级别设计每个操作。

·定义内部类。

·为类属性设计内部数据结构。

(3)消息设计。

使用对象间的协作和对象．关系模型，设计消息模型。

(4)复审。

复审设计模型，并在需要时迭代。

目前有许多种面向对象方法，例如Coad&Yourdon方法、OMT方法、Booch方法等。

软件工程统一的建模语言

一、UML概述

1994年Booch和Rumbaugh在R~ionalsoftwareCorporation开始了UML的工作，其目标是创建一个“统一的方法”，他们把Booch一93和OMIT一2统一起来，于1995年发布了UM0.8(UnifiedMethod)。

OOSE的创始人jacobson加盟到这项工作中，他们以Booch方法、OMT方法、OOSE方法为基础，吸收了其他流派的长处，于1996年6月、10月、1997年1月、11月分别推出了UML0.9，UML0.91，UML1.0，UMLl.1。

1997年11月，国际对象管理组织OMG(ObjectManagementGroup)批准把UML1.1作为基于面向对象技术的标准建模语言。

软件工程一个系统往往可以从不同的角度进行观察，从一个角度观察到的系统，构成系统的一个视图(View)，每个视图是整个系统描述的一个投影，说明了系统的一个特殊侧面。若干个不同的视图可以完整地描述所建造的系统。视图并不是一种图表(Graph)，它是由若干幅图(Diagram)组成的一种抽象。每种视图用若干幅图来描述，一幅图包含了系统某一特殊方面的信息，它阐明了系统的一个特定部分或方面。由于不同视图之间存在一些交叉，因此一幅图可以作为多个视图的一部分。一幅图由若干个模型元素组成，模型元素表示图中的概念。UML语言建立在面向对象的基础上，它采用面向对象的概念和范型。UML语言的体系结构建立在四层元模型结构之上，这4层元模型分别为：元一元模型、元模型、软件工程模型、用户对象。1．元一元模型层元一元模型(Meta—metamodel)是建立元模型体系结构的基础结构(Infrastructure)。元一元模型定义描述元模型的语言，是任何模型的基础，用于对概念的形式化。2．元模型层元模型层(Metamodel)定义描述模型的语言。在UML语言的元模型中，定义了面向对象的范型的概念，如“对象类”、“属性”、“操作”、“组件”等，它们是元模型层的元对象。元模型是元一元模型的一个实例。例如，“对象类”、“软件工程属性”、“操作”分别是“元对象类”、“元属性”、“元操作”的实例。“对象类”是对一组具有共同的结构特征、行为特征、联系和语义的对象的描述。“对象”是“对象类”的一个实例。“关联”是对一组具有共同的结构特征、行为特征、联系和语义的链接的描述，“链接”用于为两个或多个实体(对象类)之间具有共同特征的联系建立模型。“链接”是“关联”的一个实例，“链接”用于为两个或多个对象之间的联系实例建立模型。3．模型层模型(Model)是元模型的一个实例，在模型层定义用于描述信息领域的语言。模型是对现实世界的抽象。无论是问题领域还是解决软件工程方案，都可以抽象成模型。模型是系统构建和更新的基础，用于对问题和解决方案的理解与交流，便于管理和控制系统的复杂性。4．用户对象层用户对象(Userobjects)是模型的实例，用户对象层定义一个特定的信息领域。用户对象层用于表达一个模型的特定情况。为了模型的可视化，UML为每一个模型元素规定了独特的图形表示符号，称为图标(Icon)。这些图标简洁明了能够容纳足够的语义，并且容易绘制方便区别。在UML的核心包中定义的分类符，如对象类、接口、软件工程数据类型、节点、组件、信号、UseCase、子系统等，它们的图标如图2．11所示。其中，对象类的图标是一个矩形框，并且可以划分成3个分割框，分别含有类的名字、属性和操作。接口的图标是一个圆，旁边标有接口的名字。数据类型的图标是一个矩形框，框内含有构造型<type>>、数据类型的名称、以及关于取值范围的说明(可选)。信号的图标是一个矩形框，框内含有构造型<<signal>>和信号的名字。UseCase的图标是一个椭圆，内含UseCase的名字。组件的图标是一个大矩形框的左边带两个小矩形，大框内含有组件的名字。节点的图标是一个三维立方体，其内含有节点的名字。包的图标是一个大矩形框的左上角带一个小矩形。子系统用包的图标表达，即在包的图标中含有构造型<<subsystem>>和软件工程子系统的名字。实际上，以上这些分类符的图标中可以包含比名字更多的信息。学生姓名入学注册查询成绩对象类分析风险UseCase<<type>>Int{from–2**31to=2**31-1}数据类型<<signal>>offHook信号<<subsystem>>教学管理子系统子系统接口IUnknown

image.java组件节点数据库服务器图2．11分类符图标示例软件工程UML定义的联系，如依赖、关联、泛化、实现(Realization)等，它们的图标如图2．12所示。其中，依赖的图标是一条虚箭线，从源模型元素指向目标模型元素，表示源模型元素依赖于目标模型元素。关联的图标是一条实线，连接两个模型元素，在关联端可标有多重性标记和关联角色。泛化的图标是一条带空心三角箭头的实箭线，从表示特殊性事物的模型元素指向表示一般性事物的模型元素。实现的图标是一条带空心三角箭头的虚箭线，从源模型元素指向目标模型元素，表示源模型元素实现目标模型元素。UML定义的联系还有聚合与组合。聚合与组合是两种特殊的关联，表示事物之问的部分与整体的关系。聚合与组合的图标是在关联线的一端分别加上一个空心或实心软件工程（a）依赖（b）泛化（c）关联（d）实现（e）聚合（f）组合图2．12联系的图标示例的小菱形，小菱形端连接表示整体事物的模型元素，另一端连接表示部分事物的模型元素。

软件工程UML定义的行为事物基本上分为两大类：交互和状态机。交互是这样一种行为：在一个特定的上下文环境里，一组对象之间交换消息，完成某个指定的任务。交互所涉及的模型元素有对象、消息、动作序列、链接等。消息的图标是一条带实心三角箭头的实箭线，从消息的发送对象指向消息的接受对象。消息的图标如图（a）所示。添加订货(a)消息

休闲(b)状态制定计划(c)活动图2．13消息、状态和活动的图标示例状态机是这样一种行为：一个对象的状态序列，或一个在整个对象的生存期中响应事件的交互。一个对象类软件工程和多个对象类的协同可以用状态机描述。状态机所涉及的模型元素有状态、转移、事件、活动等。状态的图标是一个带4个小圆角的矩形，含有状态的名字。活动(动作状态)的图标是一个由上下两条平行线段、两侧圆弧构成的图形，含有活动的名字。状态与活动的图标分别如图

(b)和图(c)所示。

UML定义的注解性的模型元素——注解(Comment)，是附加在其他模型元素上的一个文字串，用来对该模型元素做解释。注解没有强制性的语义，只是对模型元素作说明。注解常用注释(Note)图标表示。注释图标是一个右上角折角的矩形，内含注释文字或约束表达式。注释图标也可以标有特定的构造型，如<<requirement>>、软件工程<<constraint>>等，说明注释的作用或类型。表达一个模型元素的注释是把它的一个注释图标用一条虚线连接到该模型元素，如图2．14所示。

安全当前值（）历史值（）<<requirement>>遵照系统登录事务的规定，满足信息系统安全性要求图2．14注释示例用于表示模型元素之问相互连接的关系也是模型元素，如关联(Association)、泛化(Generalization)、依赖(Dependency)、聚集(Aggregation)等。这些关系的含义如下：

(1)关联：连接(Connect)模型元素及链接(Link)实例。

软件工程(2)泛化：表示一般与特殊关系，即“一般”元素是“特殊”元素的泛化，“特殊”元素是“一般”元素的特化(Specialization)。

(3)依赖：表示一个元素以某种方式依赖于另一个元素。

(4)聚集：表示整体与部分的关系，即“部分”元素是“整体”元素的一部分。

UML中有9种图(Diagram)和五种视图。九种图是：用例图(Use—caseram)、类图(Class)、对象图(Object)、状态图(State)、时序图(Sequence)、协作图(Collaboration)、活动图(Activity)、构件图(Component)和部署图(Deployment)。软件工程UML可以从下列五种视图来观察系统，即用例视图、逻辑视图、构件视图、并发视图和部署视图。二、使用UML的过程UML给出了面向对象建模的符号表示和规则，但并没有描述如何工作，即没有描述使用语言的过程或方法。实际上，UMI是为不同规模和目标的过程而设计的，尽管如此，要成功地使用UML仍需要一些过程。UML的设计者在设计UML时头脑中是有一些过程的，使用UML。过程的基本特征是：用例驱动(Use-case-driven)、以体系结构为中心(Architecture-centric)、反复(Iterative)、渐增式(Incremental)。

软件工程面向对象(OO)方法的主要步骤是需求分析、设计、实现和测试。UML的设计者将他们原先各自的面向对象开发过程进行合并，命名为RationalObjectoryProcess，其开发过程如图所示。初始阶段细化阶段构造阶段……细化阶段图2．15RationalObjectory开发过程1、初始阶段

初始阶段主要确定项目的范围和目标，并进行可行性分析。

软件工程2、细化阶段

细化阶段对开发项目的问题领域和功能做详细分析，画出用例图，建立系统的基础结构。

3、构造阶段

通常具有高优先级、高体系结构风险和高进度风险的用例应尽早实现，不要风险留到最后。4、移交阶段

移交阶段一般不再开发新的功能，该阶段的工作主要有B测试、产品包装、培训等。

软件工程2.5软件需求分析建模与规格说明

2.5.1需求分析建模

目标软件系统的模型用来刻划系统所涉及的信息、处理功能及实际运行时的外部行为，但是，分析阶段所建造的模型不应涉及软件实现细节，因为这样会分散分析人员的注意力，限制软件设计人员为提高软件的质量和效率而选择实现方法的自由度。通常，分析人员选定一些图形记号分别表示信息流、处理功能及系统行为．井利用受限的自然语言给出用户需求的描述。此外，为了处理大型问题，模型的表示机制还应具备良好的结构化能力。建立软件模型是分析活动的焦点。因为模型以一种简洁、准确、结构清晰的方式系统地描述了软件需求，从而使软件工程于分析人员剔除用户描述中的模糊性和不一致性，并使软件需求臻于完全。分析过程实质上是软件模型的建造和不断完善的过程。在分析的初期，开发方和用户方的联合小组通过访谈、会议及实际观察为构筑模型收集素材．同时也利用不太完整的初步模型作为小组内都相互沟通的需求表示机制、此后，分析人员不断地对模型进行精确化、一致化、完全化方面的工作。最终确立的软件模型既是生产需求规格说明的基础，又是软件设计和实现的基础。软件工程2.5.2规格说明及形式化说明技术

软件需求规格说明书(SoltwareRequirementSpecificatiOns，SIRS)是需求分析阶段的主要文档，它以一致的，无二义性的方式完整、准确地表达目标系统应该实现的用户需求。SRS既是软件开发设计的依据，也是将来用户测试验收的依据。提交并且通过复审的SRS是需求分析结束的里程碑。SRS围绕以下四个方面组织：(1)系统规格说明：目标系统的总体概貌；系统功能、性能要求；系统运行要求；将来可能的修改扩充要求。如果采用SA方法进行需求分析，则数据流图是描述系统逻辑模型主要工具。(2)数据要求：建立数据词典描绘系统数据要求，给出系统逻辑模型的准确、完整定义。软件工程(3)用户描述：从用户使用角度对系统的描述，相当于初始的用户手册。内容包括系统功能、性能概述，预期的系统使用步骤与方法，用户运行维护要求等。(4)修正的开发计划：经过需求分析，对系统开发的成本估计，资源使用要求，项目进度计划的可能修改。一份好的软件需求规格说明应该具有唯一性、完整性、可验证性、一致性、可跟踪性、可修改性等特征。1．唯一性用户的每一个要求／系统功能仅有一种解释。自然语言的二义性可能导致对于系统功能、性能的不同理解。

2．完整性软件工程需求分析的完整性包括：·系统包含全部重要的用户需求(功能、性能、设计约束、外部接口)；·规定每种输入数据的软件响应(正确输入的响应和不正确输入的响应)；·全部术语、图表完整，符合需求规范标准。3．可验证性

SRS中每个功能、性能需求是可以验证的。

4．一致性SRS陈述的各项功能、性能要求是相容的，没有互相发生软件工程矛盾或者冲突。5．可修改性SRS的组织结构使得当需求发生必须的变化时，对SRS的修改能够保证完整、一致、容易地完成。在SRS中，如果存在一个有关SRS内容的列表、索引和交叉引用表，则当某个需求发生变化时，就可以方便对SRS中必须修改的部分进行定位和修改。6．可跟踪性对于软件开发中的每个需求在SRS中可以追溯出其来源。实现可跟踪性的常用方法是对SRS中每个段落按层编号，每个需求给以唯一编码，使用特殊指示字对同一需求在SRS中的不同出现进行标识。软件工程2.6软件需求正确性验证

2.6.1软件需求正确性要求和验证方法

为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述四个方面进行验证：一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，软件工程对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。有效性必须证明需求是正确有效的，确实能解决用户面对的问题。那么，怎样验证软件需求的正确性呢?验证的角度不同，验证的方法也不同：1．验证需求的一致性当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格软件工程说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不能在正确的基础上顺利进行。为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性，从而能有效地保证软件需求的一致性。2．验证需求的现实性为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。软件工程3．验证需求的完整性和有效性只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要(即，需求的有效性)，只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要(特别在要开发的系统是全新的，以前没有使用类似系统的经验时，情况更是如此)，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。

软件工程2.6.2用于需求分析的软件工具

为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求：(1)必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；(2)使用这个软件工具能够导出详细的文档；(3)必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；(4)使用这个软件工具之后，应该能够改进通信状况。作为需求工程方法学的一部分，在1977年设计完成了软件工程RSL(需求陈述语言)。RSL中的语句是计算机可以处理的，处理以后把从这些语句中得到的信息集中存放在一个称为抽象系统语义模型(ASSM)的数据库中。有一组软件工具处理ASSM数据库中的信息以产生出用PASCAL语言书写的模拟程序，从而可以检验需求的一致性、完整性和现实性。美国密执安大学开发了PSL／PSA(问题陈述语言／问题陈述分析程序)系统。这个系统是“计算机辅助设计和规格说明分析工具(CADSAT)”的一部分，它的基本结构类似于RSL。其中PSL是用来描述系统的形式语言，PSA是处理PSL描述的分析程序。用PSL描述的系统属性放在一个数据库中。一旦建立起数据库之后即可增加信息、删除信息或修改信息，并且保持信息的一致性。PSA对数据库软件工程进行处理以产生各种报告，测试不一致性或遗漏，并且生成文档资料。PSL／PSA系统的功能主要有下述四种：(1)描述任何应用领域的信息系统；(2)创建一个数据库保存对该信息系统的描述符；(3)对描述符施加增加、删除和更改等操作；(4)产生格式化的文档和关于规格说明书的各种分析报告。PSL／PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和软件工程项目管理等八个方面描述信息系统。一旦用PSI一对系统做了完整描述，就可以调用PSA产生一组分析报告，其中包括所有修改规格说明数据库的记录，用各种形式描述数据库信息的参照报告(包括图形形式的描述)，关于项目管理信息的总结报告，以及评价数据库特性的分析报告。借助PSL／PSA系统可以边对目标系统进行自顶向下的逐层分解，边将需求分析过程中遇到的数据流、文件、处理等对象用PSI。描述出来并输入到PSL／PSA系统中。PSA将对输入信息作一致性和完整性检查，并且保存这些描述信息。软件工程2.7需求分析指南

按照软件工程对软件开发过程的描述，需求阶段我们可以细分为需求调研和需求分析两个小阶段，需求调研需要充分细致的了解客户目标，用户业务内容、流程等，这是一个对需求的采集过程，是进行需求分析的基础准备。当我们已经了解、理解了用户的业务，于是可以开始分析需求了。软件系统的需求分析可以由产品工程师或系统分析员或两者分阶段合作完成全部的需求分析工作。一、

提取出核心、主要、急迫的业务，明晰业务流程二、

运用管理思想，优化业务流程

软件工程本章小结

需求分析是在可行性研究的基础上进行的，可行性研究实质上是一次完整的分析和设计过程，只不过是在抽象的层次上进行的大大压缩和简化了的分析和设计过程。因此在可行性研究阶段已经进行了某些初步的分析，特别是已经得出了高层次的数据流图。但是，需求分析的主要任务是得出详细的系统逻辑模型。通常需求分析工作从可行性研究得出的数据流图出发，首先确定构成输出数据的各个数据元素，沿数据流图回溯寻求每个数据元素的源，在此过程中确定必要的处理算法并补充必要的数据元素，同时也会产生一些新的问题。在寻求这些问题的答案时，将澄清一些算法并划分出更多的数据元素，可能也会再遇到一些问题。对这些问题的解答又将导致对系统的更深入更具体的认识。在对系统的主要软件工程处理算法有充分了解之后，应该把数据流图进一步分层细化。通过需求分析应该得出用数据流图、ER图、数据字典和IPO图(或PDL等其他描述算法的工具)描绘的精确的系统逻辑模型。为了提高文档的可理解性，还可以用层次方框图或Warnier图等图形工具辅助描绘系统中的数据结构。为了减少冗余、简化修改步骤，往往需要规范数据的存储结构。需求分析的结果是软件开发的基础，必须仔细验证它的正确性，开发人员必须和用户取得完全一致的意见，需求分析的文档应该被用户所确认。软件工程第6章项目管理

本章要点：软件项目管理概念项目管理组织及过程

软件质量及保证CMM模型软件工程本章学习目标：了解项目管理过程

理解项目的估算方法了解CMM模型的层次结构

软件工程6.1项目管理概述

项目管理就是为了满足甚至超越项目涉及人员对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去。

需要在下面这些相互间有冲突的要求中寻求平衡：

范围、时间、成本和质量

有不同需求和期望的项目涉及人员

明确表示出来的要求（需求）和未明确表达的要求在软件行业，对项目实施有效的管理是软件成败的关键。软件工程项目管理的过程

软件项目启动度量

估算

风险分析

进程安排

追踪和控制

软件工程6.2项目计划

计划是管理工作的重要职能，在软件项目管理中，软件项目从制定项目计划开始。项目计划中需要确定以下几项内容：

目标：定义了待完成的目标，迫切需要的资源，约束和优先级。范围：定义待开发系统的边界，什么包括在系统里，什么不包括在系统里。产品技术说明：说明软硬件信息以及有关功能、性能、安全性等方面的约束。时间：进度表。资金：预算。地点：工作空间分配。人员：参与人员以及项目组织。软件工程6.3进度安排

软件开发项目的进展安排有两种考虑方式：

系统最终交付日期已经确定，软件开发部门必须在规定期限内完成任务。系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定

进度安排是基于对项目的需求分析和评审软件工程项目的并行性提出一系列进度要求。因为并行任务是同时发生的，以进度计划决定任务之间的从属关系，确定各个任务的先后次序和衔接，以及各个任务完成的持续时间。

软件工程6.4项目估算对软件项目进行有效的估算，取决于掌握多少有关项目范围的原始资料。估算的两个主要方法是：第一种方法是根据项目特征和算法进行估算。第二种方法是采用类比的方法，根据历史数据来进行估算。

软件工程项目规模估算量软件项目规模最常用的概念--LOC

L指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：JobControlLanguage）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。

规模估算的三种方法方法一、Delphi法

方法二、类比法方法三、功能点估计法

软件工程软件开发成本估算软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发过程所花费的代价作为依据的。

对于一个大型的软件项目，要进行一系列的估算处理，主要靠分解和类推的方法进行。基本估算方法分为3类：

自顶向下的估算方法自底向上的估算法差别估计法软件工程6.5项目组织组织原则

（1）

早落实原则

（2）

减少接口

（3）

责权均衡

2人员配备

软件工程6.6软件质量按照ANSI/IEEE1983年的标准，软件质量定义为“与软件产品满足需求所规定的和隐含的能力有关的特征和特性的全体。”软件产品中所能满足用户给定的全部特性的集合软件具有所期望的各种属性组合的程度用户主观得出的软件是否满足其综合期望的程度决定所用软件在使用中将满足其综合期望程度的软件合成特性软件工程质量保证的主要内容软件工程质量保证应用于整个软件过程的保护活动，包括：（1）

质量管理方法（2）

有效的软件工程技术（方法和工具）。（3）

应用于整个软件过程的形式化技术评论。（4）

多等级测试策略。（5）

软件文档以及对软件进行改变和维护的控制和约束（6）

确保遵照软件开发标准的过程。（7）

测量和报告机制。软件工程软件工程标准化软件工作的范围从只是使用程序设计语言编写程序，扩展到

整个软件生存期。所有这些方面都应逐步

建立起标准或规范来。

软件工程标准的类型也是多方面的。它可能包括过程标准(如方法、技术、度量等)、产品标准(如需求、设计、部件、描述、计划、报告等)、专业标准(如职别、道德准则、认证、特许、课程等)以及记法标准(如术语、表示法、语言等)。

软件工程软件工程标准的制定与推行通常要经历一个环状的生命期(参看图6．2)。最初，制定一项标准仅仅是初步设想，经发起后沿着环状生命期，顺时针进行要经历以下的步骤：软件工程CMM模型

CMM(CapabilityMaturityModel)即能力成熟度模型，定义了当一个组织达到不同的过程时应该具有的软件工程能力。它描述了软件过程从无序到有序、从特殊到一般、从定性管理到定量管理、最终到达可动态优化的成熟过程。给出了该过程中5个成熟阶段的基本特性和应遵循的原则、采取的行动，以帮助软件组织改进其软件过程。

CMM的基前提是：软件质量在很大程度上取决于开发软件的软件过程的质量和能力；软件过程是一个可管理、可度并不断改进的过程；软件过程的质量受到用以支撑它的技术和设施的影响；软件开发组织在软件过程中所采用的技术层次应适应于软件过程的成熟度。软件工程CMM模型

将CMM组织成下图所示的5个等级，其意在于增加软件过程成熟的改进行动按优先级排序。图中带有标记的箭头，指示在成熟度框架的每一步骤上，组织应予以规范化的过程能力的类型。

[5]优化级[4]已管理级[2]可重复级[3]已定义级[1]初始级软件工程6.7软件配置管理系统配置指的是交付给特定客户的一个系统构件的集合

软件配置管理是监督和控制工作产品中变化的过程。变化遍及整个软件开发过程。

软件配置管理是软件系统发展过程中管理和控制变化的规范[IEEEStD.1042-1987]。配置管理系统使得版本的识别、存储和检索以及支持状态记录自动完成。配置管理包括下列活动：配置项的确定变化控制状态记录审核软件工程配置管理的过程软件配置管理的方法大致分三类：单独文件、增量和条件编译。以上三种