软件工程导论 Software Engineering.pptVIP

Chap02 可行性研究 可行性研究的任务 可行性研究过程 系统流程图 数据流图 数据字典（内容、方法、用途、实现） 成本/效益分析（成本估计、分析方法） 2.1 可行性研究的任务 可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程： 分析和澄清问题定义 导出系统的逻辑模型－探索系统实现方案： 技术可行性：现有的技术 经济可行性：开发成本 操作可行性：用户操作 实现进度 可行性研究的成本：预期的工程总成本的5％～10％ 2.2 可行性研究的步骤 复查系统规模和目标 研究目前正在使用的系统 导出新系统的高层逻辑模型 重新定义问题 导出和评价供选择的解法 推荐行动方针 草拟开发计划 书写文档提交审查 复查系统规模和目标 对问题定义阶段书写的关于规模和目标的报告书进一步复查确认。改正报告书中的叙述模糊、不正确的地方。这个步骤的工作，实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。 进一步复查确认“规模和目标报告书” 研究目前正在使用的系统 正在使用的系统的基本功能以及某些缺点 分析现有系统的文档资料和使用手册，实地考察现有系统 描绘现有系统的高层系统流程图并确认 记录现有系统的接口 导出新系统的高层逻辑模型 设计过程通常总是从现有的物理系统出发，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。 使用数据流图，描绘数据在系统中流动和处理的情况，从而概括地表达出对新系统的设想。 通常为了把新系统描绘得更清晰准确，还应该有一个初步的数据字典，定义系统中使用的数据。 数据流图和数据字典共同定义了新系统的逻辑模型，以后可以从这个逻辑模型出发设计新系统。 重新定义问题 分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。 可行性研究的前四个步骤实质上构成一个循环。 导出和评价供选择的解法 分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的（较抽象的）物理解法供比较和选择。 从技术角度出发考虑解决问题的不同方案。例如，2．4节中将举例说明在数据流图上划分不同的自动化边界 根据技术可行性的考虑初步排除一些不现实的系统。例如，如果要求系统的响应时间不超过几秒钟，显然应该排除任何批处理方案。 考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。 考虑经济方面的可行性。 分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。 在这些估计数字的基础上，对每个可能的系统进行成本／效益分析。（参看2．6节） 制定实现进度表。 通常只需要估计生命周期每个阶段的工作量。 推荐行动方针 做出一个关键性的决定：是否继续进行这项开发工程。 如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。 草拟开发计划 为推荐的系统草拟一份开发计划： 工程进度表 估计对各种开发人员和各种资源的需要情况。 估计系统生命周期每个阶段的成本。 最后应该给出下一个阶段（需求分析）的详细进度表和成本估计。 书写文档提交审查 写成清晰的文档，请用户和使用部门的负责人仔细审查。 2.3 系统流程图 系统流程图是描绘物理系统的传统工具。 它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件（程序，文件，数据库，表格，人工过程等等）。 系统流程图表达的是信息在系统各部件之间流动的情况，而不是对信息进行加工处理的控制过程。 尽管系统流程图使用的某些符号和程序流程图使用的符号相同，但是它却是物理数据流程图而不是程序流程图。 基本符号 一个符号表示系统中的一个部件。 系统符号 2.3.2 例子 某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便定货，规定每天向采购部门送一次定货报告。 习惯画法是使信息在图中从顶向下，从左向右流动。 2.3.3 分层 首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。 然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。 这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。 2.4 数据流图－1 数据流图描绘系统的逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。 2.4