【软件工程导论学习笔记】第二章：可行性研究

前言：

感谢大佬们的不求回报的分享，
感谢好人们的百忙之中的帮助。

爱的传递，希望能帮到更多的人。

2.1 可行性研究的任务……P35

可行性研究的目的：就是用最小的代价在尽可能短的时间内确定问题是否能够解决。

技术可行性：使用现有的技术能实现这个系统吗？

经济可行性：这个系统的经济效益能超过它的开发成本吗？

操作可行性 : 系统的操作方式在这个用户组织内行得通吗？

必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。

2.2 可行性研究过程………P36

过程

复查系统规模和目标。

研究目前正在使用的系统。

导出新系统的高层逻辑模型。

进一步定义问题。

导出和评价供选择的解法。

推荐行动方针。

草拟开发计划。

书写文档提交审查。

2.3 系统流程图……………P38

符号（系统流程图）

例子

分层

分解思想，化繁为简。

2.4 数据流图………………P40

数据流图的基本要点：描绘“做什么”，而不考虑“怎么做”。
数据流图(DFD) 是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
符号（数据流图）

如图2. 4(a)所示，数据流图有4种基本符号:

正方形(或立方体)：表示数据的源点或终点;

圆角矩形(或圆形)：代表变换数据的处理;

开口矩形(或两条平行横线)：代表数据存储；

箭头：表示数据流，即特定数据的流动方向。

注意：

数据流与程序流程图(参看本书第5章)中用箭头表示的控制流有本质不同，千万不要混淆。熟悉程序流程图的初学者在画数据流图时，往往试图在数据流图中表现分支条件或循环，殊不知这样做将造成混乱，画不出正确的数据流图。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。

例子

命名

为数据流（或数据存储）命名：

名字应代表整个数据流(或数据存储)的内容,而不是仅仅反映它的某些成分。

不要使用空洞的、缺乏具体含义的名字(如“数据"、“信息”、“输人”之类)。

如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的,应该试试重新分解,看是否能克服这个困难。

为处理命名：

通常先为数据流命名,然后再为与之相关联的处理命名。这样命名比较容易,而且体现了人类习惯的“由表及里”的思考过程。

名字应该反映整个处理的功能，而不是它的一部分功能。

名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。

通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。

如果在为某个处理命名时遇到困难,则很可能是发现了分解不当的迹象，应考虑重新分解。

注意：

数据源点/终点并不需要在开发目标系统的过程中设计和实现，它并不属于数据流图的核心内容，只不过是目标系统的外围环境部分(可能是人员、计算机外部设备或传感器装置)。通常,为数据源点/终点命名时采用它们在问题域中习惯使用的名字(如“采购员”、“仓库管理员”等)。

用途

利用它作为交流信息的工具。

作为分析和设计的工具。

2.5 数据字典………………P47

定义是自顶而下的分解，所以数据字典也是的。
数据元素组成数据的3种基本模型

顺序：即以确定次序连接两个或多个分量。

选择：即从两个或多个可能的元素中选取一个。

重复：即把指定的分量重复零次或多次。

如果在开发小型软件系统时暂时没有数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据的信息。这样做会使更新和修改比较方便，而且能单独处理描述每个数据的信息。每张卡片上主要应该包含下述这样一些信息:名字、别名、描述、定义、位置。当开发过程进展到能够知道数据元素的控制信息和使用特点时，再把这些信息记录在卡片的背面。