软件工程-第三章-可行性分析[精选].pptVIP

软件工程Software Engineering 第三章 可行性分析 第三章 可行性研究 可行性的任务与步骤 系统分析 分析原理 结构化分析 系统流程图 可行性研究 数据流图 数据字典 成本——效益分析 可行性研究的文档 项目开发计划 3.1.1 研究任务 是在尽可能短的时间内用最小的代价确定该软件项目是否值得去开发 可行性研究所要考虑的四个方面 技术可行性 经济可行性 社会可行性 操作的可行性 3.1.2 研究步骤 系统定义 对于现行系统进行分析研究 导出新系统的逻辑模型 设计方案 推荐可行的方案 编写可行性研究报告 3.2 系统分析 系统分析 的任务 研究系统规格说明和软件项目计划，为分析建立通信关系 问题评价与解的综合 为需求分析选择原型开发的方法 制定需求分析文档（规格说明和用户手册） 3.2.1系统分析员 能掌握抽象概念（abstract concepts），并能把其整理为逻辑划分（logical divisions），以及根据每一个逻辑划分综合为解（solutions）的能力 有弄清用户环境的能力 有从冲突（conflict）或混惑（confusions）中吸取恰当事实的能力 系统分析员 有用较好的书面和口头形式进行通信（communication）的能力 有把硬件和软件系统用于用户环境（user/customer environments）的能力 有“从树木见森林”的能力 3.2.2系统分析员任务 问题识别（problem recognition）。 评价和综合（evaluation and synthesis） 建模（modeling） 规格说明（specification） 评审（review） 3.2.3 面临的问题域 恰当信息的获取 随着任务规模的增大，分析任务的复杂性也在增加，如何对大任务进行有效地划分 如果进行有效的通信，避免通信中的误解和遗漏 软件需求怎样与其他系统元素改变相适应， 怎样评价需求改变可能对其他软件部分的影响，以及为了避免副作用，我们在规格说明中怎样进行错误的改正 系统分析过程中问题产生的可能原因 缺少通信，使信息获得困难 由于不适当的技术和工具致使规格说明不充分或不准确 在需求分析中，试图走捷径，导致不可靠的设计 在软件定义前，方案选择错误 3.2.4 通信技术 过程的开始 深入了解 方便的应用规范技术(FAST) FAST应用必须遵循的原则 会议由上一级部门或请中立部门主持，开发人员和用户双方参加 一位主持人（可以是用户、开发商或局外人），是被指定控制会议的人 确定准备和参加的原则 提出一个议事日程，这个议事日程是正规的，并包括所有重要观点。但是要不拘礼节地鼓励大家自由发表意见 一张确定的日程（可以是工作单、可转动的图表、墙上张贴物或墙上印刷牌） 目标就是确定问题，提出解的各种元素，协商不同方法，以及定义一个初步解的需求集。而且能在一个有助于目标完成的气氛中进行 3.3 分析原理 问题的信息域必须能被表示和被理解 应当开发描述系统信息、功能和行为的模型 问题必须能按一定形式进行分割，就是用一种层次（或分层）形式来揭示它们的细节 分析过程应当从基本信息开始，直到实现细节 3.3.1 信息域 信息域是一信息字或一组信息中的特定部分，信息域中的内容通常被作为一个整体来处理。 信息域包括三种不同方面的数据和控制： 信息内容、信息结构和信息流。 3.3.2 建立模型 在软件需求分析过程中，我们要完成将建立的系统的模型。模型主要说明系统必须做什么，而不是表达怎样做。在一般情况下，我们用图形符号表示的方法来描述信息、处理、系统行为，而其他特性则使用性质不同的和公认的图符（icons）表示。如果条件允许，可以采用源代码通过在机器上演示说明系统做什么。模型的另外一些部分可以是纯的文字形式。对需求的描述可以用自然语言或专用语言。 建立模型的作用 这种模型可以辅助分析人员更好地了解系统的信息、功能和行为，从而使分析更容易和更系统化 模型是评审的焦点，是确定系统完整性（completeness）、一致性（consestency）和规格说明准确性（accuracy）的关键 模型也是设计的基础。能给设计人员提供一种软件的基本表达式，这种表达式可以映射成为实现的正文。 3.3.3 分解 从本质上讲，分解就是把一个问题划分为几个组成部分。在概念上，我们可以建立一种分层的功能或信息表达式，然后按下述两条分解出最主要的元素： （1）在分层中，按垂直方向逐层细化； （2）在分层中，按水平方向对功能进行分解 分解举例-分析一个文字处理软件系统 3.4 结构化分析 基本思想 特点 优点 存在问题 基本思想 结构化方法总的指导思想： 自顶向下，