软件工程导论13章总结汇总.docx

资源描述

软件工程导论13章总结汇总.docx

《软件工程导论13章总结汇总.docx》由会员分享，可在线阅读，更多相关《软件工程导论13章总结汇总.docx（20页珍藏版）》请在冰豆网上搜索。

软件工程导论13章总结汇总.docx

软件工程导论13章总结汇总

提出研制要求

初步调查

可行性报告

可行性分析报告

修改目标，追加资源，等待条件

开发软件的基本过程：

审批

否修改

停止研制

详细调查

是

逻辑设计

修改说明书

系统说明书

停止研制

审批

否修改

总体设计

是

详细设计

系统设计说明书

修改设计方案

停止研制

审批

否修改

系统实施

是

调试

修改系统

验收

修改

是

交付使用

生命周期方法：

生命周期法采用介于形式语言和自然语言之间的描述方式，通过一套分层的数据流程图，附以数据字典、小说明等工具来描述系统。

生命周期法的基本思想

为保证系统开发的顺利进行，生命周期法强调遵循以下几个基本原则：

（一）面向用户的观点

信息系统的目的是为管理人员提供管理和决策信息，能否满足用户的信息需求，是系统成败的重要标志。

实践证明，用户的参与，尤其是领导的介入，是系统成功的关键。

在整个研制过程中，系统研制人员应该始终与用户保持联系，从调查研究入手，充分理解用户的信息需求和业务活动，不断地让用户了解工作进展情况，校准工作方向。

（二）严格区分工作阶段

生命周期法强调按时间顺序、工作内容，将系统开发划分为几个工作阶段，如系统规划阶段、系统分析阶段、系统设计阶段、系统实施阶段以及系统运行与维护阶段等等，各个阶段的任务是明确的，过程是循序渐进的。

对于复杂的系统，要强调和加强前期工作，强调分析设计的深入细致，以避免后期返工，造成投资耗费和负社会效益。

（三）自顶向下地完成系统的研制工作

在系统分析阶段，从全局出发，对企业进行周密的调查分析，自上而下，从粗到精，由表及里，逐层、逐级进行业务过程分解，最后进行逆向综合和抽象，完成新系统模型的构造。

在系统设计阶段，用划分子系统的方法，把系统逐层分解到详细模块，完成设计方案。

在实施阶段，从实现系统的框架开始，自上而下实现系统功能。

程序设计过程中同样采用结构化设计的方法，自顶向下，逐步求精。

（四）充分考虑变化的情况

组织的经营环境在变化，用户的信息需求也在变化，他们对信息系统的要求会自然越来越高。

生命周期法充分考虑了这种变化，在系统设计中，把系统的可变更性放在了首位，运用模块结构方式来组织系统，使系统的灵活性和可变更性得以充分体现。

（五）工作成果文档化、标准化

系统开发是一项复杂的系统工程，参加人员多，经历时间长。

生命周期法用文档的标准化保证开发工作的连续性，在每个开发阶段，都要用文字、图表表达该阶段的成果，资料格式标准化、格式化。

这些文档资料在开发过程中是开发人员和用户交流思想的工具和媒介，在开发完成后，成为系统维护的依据。

因此，要求文档资料简洁明确，无二义性，既便于研制人员阅读，又便于用户理解。

生命周期法的特点

生命周期法很适合于开发大型的事务处理系统、大型的管理信息系统和可靠性要求很高的复杂应用系统。

也是软件的社会化大生产的有效方法。

生命周期法具有以下特点：

1、强调计划性，排除不确定性。

生命周期法通常假定系统的应用需求是预先描述清楚的，排除所有的不确定性因素。

2、强调分工，严格区分系统开发的各个阶段中的任务和要求，目的明确，任务清楚。

3．强调标准化和规范化，排除个性化和自由发挥。

规范、齐全的文档，严格的审定记录和有序的过程调度。

生命周期法的缺点

生命周期法是最成熟、应用最广泛的一种工程化方法，它也有不足和局限性。

（一）系统需求的不确定性：

1．在系统开发的起始阶段，用户对系统的目的和功能不了解，他们无法准确地描述自己对信息的需求。

2．系统分析人员和用户无法预测组织和系统的未来，按照目前状况描述的系统需求，可靠性可能很差。

3．用户和系统分析人员对信息需求的理解上会有偏差和错误，造成信息需求的描述不准确。

4、组织管理体制的变更，导致信息需求和工作过程发生变化。

（二）开发周期长

一个规模较大的系统，其开发过程往往需要一至三年，这样一方面使用户在较长时间内不能得到一个可实际运行的物理系统，使用户有可望而不可及的焦虑；另一方面也难以适应环境变化，因为在开发过程中，信息需求可能已经发生了变化，系统尚未开发出来可能就已经过期了。

（三）文档化工作复杂：

生命周期法在开发的各个阶段中文档很多，工作烦琐，管理费用很高。

（三）缺乏灵活性：

开发中途修改方案的困难很大，涉及到的问题很复杂。

*数据流程图的画法

一般地说，画DFD应遵循“由外向内，自顶向下”原则进行。

由外向内是指：

先标定系统范围。

这个范围就是输入输出之间的部分，该部分的细节暂不考虑。

有时最外部难以表示出来全部数据流，但这不要紧，因为无法表示的内部数据流随着设计过程的深入，逐步会分解、画出并填补上去。

描述系统内部数据流，一般从输入端开始向输出端推进，每当经过使数据流的组成或数值发生变化的地方，就用一个“加工”将其连接起来，这个“加工”正是实现这一数据变化的。

注意，不要把相互无关的数据画成一个数据流，也不要把作为一个处理单位的数据画成两个数据流；如果牵涉到文件，则应表示出“文件”与“加工”的关系（读或写）。

画数据流程图时注意以下两点：

1、应该遵照业务处理过程（即前边的结果），将系统调查的资料和整理数据结合起来，在绘制的过程中不断地与相应的调查记录、数据记录对照，以便能及时发现诸如数据不匹配，流通渠道不畅，处理过程不合理之类的问题。

2、由于实际数据处理过程常常比较繁杂，故应该按照系统的观点，自顶向下地分层展开绘制，即先将比较繁杂的处理过程（不管有多大）当成一个整体处理块来看待（俗称“黑匣子”）；然后绘出周围实体与这个整体块的数据联系过程；然后再进一步将这个块展开，如果内部还涉及到若干个比较复杂的数据处理部分的话，又将这些部分分别视为几个小“黑匣子”，同样，先不管其内部，只分析它们之间的数据联系。

这样反复下去，依此类推，直至最终搞清了所有问题为止，也有人将这个过程比喻为使黑匣子逐渐变“灰”，直到“半透明”和“完全透明”的分析过程。

3、数据流程图举例

我们在前边示例中，调查分析该企业财务科数据流程、业务流程及其组织结构图，然后根据其组织结构图（图3.9）从上至下展开,画出各自的数据流程图。

如图3.14，然后将3.14分解细化为图3.15。

在图3.15的基础上，画出第一层对应的数据流程图，如图3.16（a）－（d）。

图3.15的每个处理对应图3.16中的一个数据流程图。

1.4.4

图3.13结构化分析方法的示意图

车间

上级

考勤表

厂长

成本报表

总会计师

会计

核算

车间

工时

成本分析表

车间

车间经费

领料单

车间

领料单汇总

仓库

燃料汇总表扎差表

水电气汇总表

动力

仓库

图3.14会计核算顶层图

3．成本核算

1．材料核算

2．工资核算

4．综合分析

成本分析表

燃料汇总表成本计算表

成本报表

水电气汇总表

工资表

车间经费材料分配表考勤表

工时

领料单汇总扎差表

领料单

图3.15会计核算零层图

1.1核对

1.2按部门汇总

1.3材料分配

结构化分析示例4.一层图

（1）

材料分配表

领料单汇总

材料消耗汇总表

领料单

产品明细目录

扎差表

部门资料

图3.16（a）材料核算

结构化分析示例4.一层图

（2）

2.1

汇总考核

2.2

计算工资

工资计算表

考勤表

考核汇总表

工时

工资文件

考核标准

图3.16（b）工资核算

结构化分析示例4.一层图（3）

3.6

汇总

3.5

企管费

3.4

工资分配

3.3

材料分配

3.2

费用分配

3.1

动力分配

3.7

成本计算

燃料汇总表

工时比例标准

水电气汇总表

车间经费

成本计算表

成本汇总表

材料分配表

工资表

企业管理费

产品明细文件其它计算标准

3.16（c）成本核算

结构化分析示例4.一层图（4）

4.1

成本分析

4.1

编制报表

成本历史文件

成本分析表

成本计算表成本报表

财务标准文件

3.16（d）综合分析

*画数据流程图的注意事项

1．数据守恒

数据守恒是指输入数据与输出数据匹配。

数据不守恒有两种情况。

一种是某个处理过程用以产生输出的数据，没有输入给这个处理过程，这肯定是遗漏了某些数据流。

另一种是某些输入在处理过程中没有被使用。

2．父子平衡

逐步扩展数据流程图，是对上层图（父图）中某些处理框加以分解，下层图（子图）是上层图中某个处理框的“放大”。

父图中某一处理框的输入，输出数据流必须出现在相应的子图中，否则就会出现父图与子图的不平衡，父图与子图的关系，类似于全国地图与各省地图的关系。

在全国地图上标出的主要的铁路、河流，在各省地图上则标得更详细，除了有全国地图上与该省相关的铁路、河流之外，还有一些次要的铁路、公路、河流等，如在上图3.15零层图中的材料核算共有三个入口，表现在图3.16（a）只有三个入口，上下表示是一致的。

3．均匀分解

如果在一张数据流程图中，某些处理已是基本加工，而另一些却还要进一步分解三四层，这样的分解就不均匀。

不均匀的分解不易被理解，因为其中某些部分描述的是细节，而其他部分描述的是较高层的功能。

遇到这种情况，应重新考虑分解，努力避免特别不均匀的分解。

4．适当命名

数据流程图中各种成分的命名与易解性有直接关系，所以应注意命名适当。

特别是处理框的命名应能准确地表达其功能，理想的命名由一个具体的动词加一个具体的名词组成，在下层尤其应该如此，例如“工资计算”、“材料分配”等。

画出数据流程图，要验证其正确性。

对一个大型系统不可能一开始就十全十美的，要经过逐步去粗取精，去伪存真的改进过程。

（四）汇总数据流程图

通过对数据流程分析，揭示出现行系统具有四个主要处理：

成本核算、材料核算、工资核算和综合分析。

我们从上至下对数据流程图进行汇总，确定该系统的逻辑模型如图3.17。

在数据流程图中显示出系统当前使用的数据存储有：

部门资料、考核标准、产品明细表、工时比例标准、工资文件、其它计算标准、成本历史文件、财务标准文件。

这些数据存储文件的内涵应在数据字典中进行详细描述。

三、数据字典

DFD表达了数据与处理的关系，数据字典（datadictionary,，DD）则是对系统中的数据的详尽描述，它提供对数据库数据描述的集中管理，目的是对收集到的数据进行标准化、统一化，有统一的名称、格式和含义。

数据字典除保存数据名、类型、长度、精度等有关信息外，还包括数据流向的描述和加工的描述，显然数据字典可供设计者和用户双方参照使用，它为系统设计人员提供了一个有力的工具。

单独的DFD和单独DD都没有任何意义，只有两者结合在一起，加上必要的说明才能构成“系统说明书”。

DD产生于数据流图，是对数据流图中的数据流、数据项、文件和加工等描述的产物。

（一）概述

系统分析中所使用的数据字典，主要用来描述数据流程图中的数据流、数据存储、处理过程和外部实体。

数据字典把数据的最小组成单位看成是数据项（数据元素），若干个数据项可以组成一个数据结构（组合数据项）。

数据结构是一个递归概念，即数据结构的成分也可以是数据结构。

数据字典通过数据项和数据结构来描写数据流，数据的存储的属性，它们之间的关系如3.18所示

数据流

数据存储

数据结构

数据项

图3.18数据结构与数据项

数据项组成数据结构，数据结构组成数据流和数据存储。

建立数据字典的工作量很大，相当繁琐，但这是一项必不可少的工作。

数据字典在系统开发中具有十分重要的意义，不仅在系统分析阶段，而且在整个研制过程中以及今后系统运行中都要使用它。

数据字典可以用人工方式建立，事先印好表格，填好后接一定顺序排列，就是一本字典。

也可以结合手工的整理，存贮在计算机内，这样使用、维护都比较方便。

（二）数据字典的内容与示例

数据字典中所包括的项目有六类：

数据项、数据结构、数据流、处理逻辑（加工）、数据存储文件、外部实体。

不同类型的项目有不同的属性需要描述，现分别说明如下：

1、数据项

数据项也称数据元素，是具有独立逻辑含义的最小数据单位，即逻辑上不可再分的数据单位，如学号、姓名等。

对每个数据项的定义包括以下内容：

①数据项的名称、编号、别名和简述；

②数据项的数值范围，如“工资”从200元到500元；

③数据项的长度，如“姓名”可以用四个汉字，即八个字节组成。

数据项定义

数据项编号：

A-004

数据项名称：

库存量

别名：

简述：

某种配件的库存数量

长度：

6个字节

取值范围：

0-999999

为了使用方便，可将多个数据项描述在同一表格内，表3.8数据项描述在同一表格内。

数据项编号

数据项名称

别名

长度

取值范围

简述

A-001

A-002

A-003

A-004

A-005

…

产品编号

产品名称

待产数

库存量

生产车间

…

CPMZ

DCS

KCL

SCCJ

…

0-999999

任何汉字、字母或数字

0-999999

任何汉字、字母或数字

…

对不同产品编号

产品的名称

需要生产数量

某种配件库存数量

指明某零件的生产单位

…

表3.8数据项定义

2、数据结构

由若干个数据项构成的数据组合称为数据结构，它描述了某些数据项之间的关系。

一个数据结构可以由若干个数据项组成；也可以由若干个数据结构组成；还可以由若干个数据项和数据结构组成。

例如，“产品明细表”这个数据结构可表示为：

产品明细表＝产品编号＋产品名称＋产品型号＋产品规格＋计量单位＋单价

在上述例子中，数据结构全部由数据项组成，称为简单的数据结构，在管理信息系统中，由于管理对象的复杂性，嵌套的数据结构是经常出现的。

例如，“销售合同”这个数据结构可表示为：

销售合同=合同编号＋订货日期＋用户＋产品＋订货数量＋交货日期

在销售合同这个数据结构中，除了合同编号、订货日期、订货数量、交货日期这些数据项外，还包含了“产品”和“用户”两个数据结构。

因此，我们称销售合同是一个嵌套的数据结构。

在数据字典中，对数据结构的定义包括以下几项内容：

①数据结构的名称和编号；

②简述；

③数据结构的组成

如果是一个简单的数据结构，只要列出它所包含的数据项就可以了；如果是一个嵌套的数据结构，需列出它所包含的数据结构名称，因为这些数据结构同样在数据字典中有定义。

例表3.9数据结构定义。

数据结构

编号

数据结构

名称

数据结构组成

简述

B-01

产品明细表

产品编号＋产品名称＋产品型号＋产品规格＋计量单位＋单价

B-02

销售合同

合同编号＋订货日期＋用户＋产品＋订货数量＋交货日期

产品、用户还是数据结构

B-03

…

用户订货单

…

订货单标识+用户情况+配件情况

…

用户所填写用户情况及订货要求等信息

…

表3.9数据结构定义

3、数据流

数据流是表明系统中数据的逻辑流向，该数据可以是数据项或数据结构。

数据流的定义包括以下内容：

①数据流的名称及编号；

②简述；

③数据流的来源；

④数据流的去向；

⑤数据流的组成；

⑥数据流的流通量；

⑦高峰期流通量。

例：

表3.10数据流定义

编号

名称

简述

数据来源

数据流向

组成

流通量

高峰流通量

C-01

半成品收发存日报

生产科为产品流向提供日报

各个生产车间

半成品仓库

半成品收发存日报的数据结构

30份/月

每日一份

次日上午

C-02

…

发货单

…

销售科为用户开具的发货单

…

销售科

…

用户

…

发货单数据结构

…

50份/日

…

70份/日上午9：

00-11：

…

4、处理逻辑（加工）

处理逻辑的定义仅对流程图中最低层的处理逻辑加以说明，内容包括：

处理逻辑名称及编号、输入数据、输出数据、处理频率、处理逻辑。

例：

图3.19是图3.16（b）汇总考核部分的最低层的一个数据流程图，我们对它的处理过程描述如表3.11。

2.1考核

考勤表

考核汇总表

工时

考核标准

图3.19

处理编号：

D-08

处理名称：

考核

输入数据：

①考勤表（No：

A—002）

②工时表（No：

A—006）

输出数据：

考核汇总表（No：

A—008）

处理逻辑：

（自然语言描述表）

1、按职工名单填写出勤天数；

2、填写完成工时数量；

3、按照考核标准计算绩效分数：

分数=工时/标准*35%+出勤天数/出勤标准*65%

4、计算奖金系数：

系数=分数*标准*（1+加贴分数+扣除分数+事故分数）

5、汇总各个班组总分；

6、汇总车间总分；

7、计算工资总额；

8、计算奖金总额。

表3.11处理过程描述

5、数据存储文件

数据存储文件是数据流动的暂时或永久保存的地方。

在数据字典中，数据存储的内容通常由数据存储的编号、名称、简述、组成、关键字和相关的处理等组成。

例：

对示例中的部分文件进行数据存储定义。

编号

名称

简述

组成

关键字