搜索
软件工程导论SoftwareEngineering主讲：张虎E-mail:zhanghu@sxu.edu.cn来自可行性研究可行性研究的任务可行性研究过程系统流程图数据流图数据字典（内容、方法、用途、实现）成本/效益分析（成本估计、分析方法）可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决；可行性研究的目的不是解决问题，而是确定问题是否值得去解。来自可行性研究的任务可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程：分析和澄清问题定义导出系统的逻辑模型－探索系统实现方案：技术可行性：现有的技术经济可行性：开发成本操作可行性：用户操作实现进度可行性研究的成本：预期的工程总成本的5％～10％来自复查系统规模和目标对问题定义阶段书写的关于规模和目标的报告书进一步复查确认。改正报告书中的叙述模糊、不正确的地方。这个步骤的工作，实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。•进一步复查确认“规模和目标报告书”来自研究目前正在使用的系统①正在使用的系统的基本功能以及某些缺点②分析现有系统的文档资料和使用手册，实地考察现有系统③描绘现有系统的高层系统流程图并确认④记录现有系统的接口来自导出新系统的高层逻辑模型设计过程通常总是从现有的物理系统出发，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。使用数据流图，描绘数据在系统中流动和处理的情况，从而概括地表达出对新系统的设想。通常为了把新系统描绘得更清晰准确，还应该有一个初步的数据字典，定义系统中使用的数据。数据流图和数据字典共同定义了新系统的逻辑模型，以后可以从这个逻辑模型出发设计新系统。来自重新定义问题分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。可行性研究的前四个步骤实质上构成一个循环。定义问题分析问题导出一个试探性的解重新定义问题符合系统目标？YN来自导出和评价供选择的解法分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的（较抽象的）物理解法供比较和选择。1.从技术角度出发考虑解决问题的不同方案。例如，2．4节中将举例说明在数据流图上划分不同的自动化边界2.根据技术可行性的考虑初步排除一些不现实的系统。例如，如果要求系统的响应时间不超过几秒钟，显然应该排除任何批处理方案。3.考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。4.考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。在这些估计数字的基础上，对每个可能的系统进行成本／效益分析。（参看2．6节）制定实现进度表。通常只需要估计生命周期每个阶段的工作量。来自推荐行动方针做出一个关键性的决定：是否继续进行这项开发工程。如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。来自草拟开发计划为推荐的系统草拟一份开发计划：1.工程进度表2.估计对各种开发人员和各种资源的需要情况。3.估计系统生命周期每个阶段的成本。4.最后应该给出下一个阶段（需求分析）的详细进度表和成本估计。来自书写文档提交审查写成清晰的文档，请用户和使用部门的负责人仔细审查。来自系统流程图系统流程图是描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件（程序，文件，数据库，表格，人工过程等等）。系统流程图表达的是信息在系统各部件之间流动的情况，而不是对信息进行加工处理的控制过程。尽管系统流程图使用的某些符号和程序流程图使用的符号相同，但是它却是物理数据流程图而不是程序流程图。2.3.1符号来自基本符号一个符号表示系统中的一个部件。符号名称说明处理能改变数据值或数据位置的加工或部件，例如，程序、处理机、人工加工等都是处理。输入／输出表示输入或输出（或既输入又输出），是一个广义的不指明具体设备的符号。连接指出转到图的另一部分或从图的另一部分转来，通常在同一页上。换页连接指出转到另一页图上或由另一页图转来。数据流用来连接其他符号，指明数据流动方向。来自例子某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便定货，规定每天向采购部门送一次定货报告。习惯画法是使信息在图中从顶向下，从左向右流动。系统流程图来自分层首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。来自数据流图－1数据流图描绘系统的逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。来自数据流图－2因为数据流图是逻辑系统的图形表示，即使不是专业的计算机技术人员也容易理解，所以是极好的通信工具。此外，设计数据流图只需考虑系统必须完成的基本逻辑功能，完全不需要考虑如何具体地实现这些功能，所以它也是软件设计的很好的出发点。来自四种基本符号表示数据的源点或终点。表示变换数据的处理。表示数据存储（静止数据）。表示数据流，即特定数据的流动方向（流动数据）。来自三个附加符号*:表示数据之间是“与”关系。+：表示数据之间是“或”关系。：表示数据之间是“互斥”关系（只能从中选一个）。来自说明数据存储和数据流都是数据，仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。来自说明有时数据的源点和终点相同。如果只用一个符号代表数据的源点和终点，则至少有两个箭头和这个符号相连（一个进一个出，）可能其中一条箭头相当长，这将降低数据流图的清晰度，如果代表同一个事物的同样符号在图中出现在n个地方，则在这个符号的一个角上画n-1条短斜线做标记。来自说明数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。熟悉程序流程图的初学者在画数据流图时，往往试图在数据流图中表现分支条件或循环，殊不知这样做将造成混乱，画不出正确的数据流图。来自说明在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。数据流图的基本要点是描绘“做什么”而不考虑“怎样做”。来自例子问题定义：一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据：零件编号，零件名称，定货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某个零件的库存数量少于库存量临界值时就应该再次定货。来自提取数据流图的四种成分－1“通过放在仓库中的CRT终端把事务报告给定货系统”——仓库管理员是数据源点。“采购部每天需要一张定货报表”——采购员是数据终点。“采购部需要报表”——用于产生报表的处理。“事务的后果是改变零件库存量”——对事务进行的加工的处理。来自提取数据流图的四种成分－2“系统把定货报表送给采购部”——定货报表是一个数据流。“事务需要从仓库送到系统中”——事务是一个数据流。“每当有一个事务发生时立即处理它，然而每天只产生一次定货报表”——应该有一个数据存储保存产生定货报表的数据。“当某个零件的库存数量少于库存量临界值时就应该再次定货”——应该有一个数据存储保存库存清单数据。来自当进一步分解将涉及如何具体地实现一个功能时就不应该再分解了。例如：为什么不进一步分解“产生报表”这个功能呢？定货报表中需要的数据在存储的定货信息中全都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。来自当对数据流图分层细化时必须保持信息连续性。也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入／输出数据流必须相同。来自应该注意在图中对处理进行编号的方法。来自命名数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。来自为数据流（或数据存储）命名1.名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。2.不要使用空洞的、缺乏具体含义的名字（如：“数据”、“信息”、“输入”等）。3.如果在为数据流（或数据存储）起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应尝试重新分解，看是否能克服这个困难。来自为处理命名－11.通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。2.名字应该反映整个处理的功能，而不是它的一部分功能。3.名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。来自为处理命名－24.通常名字