《软件工程 教学课件 ppt 作者 张海藩 1_ 第2章》由会员分享，可在线阅读，更多相关《软件工程 教学课件 ppt 作者 张海藩 1_ 第2章（146页珍藏版）》请在金锄头文库上搜索。
1、第2章 结构化分析,传统的软件工程方法学采用结构化分析技术完成系统分析（问题定义、可行性研究、需求分析）的任务。 所谓“结构化”，就是用一组标准的准则和工具来完成某项工作。具体说到结构化分析，它主要有以下几个要点： 采用自顶向下功能分解的方法； 强调逻辑功能而不是实现功能的具体方法； 使用图形（最主要的是数据流图）表达系统分析的结果。,2.1 可行性研究的任务 2.2 可行性研究过程 2.3 需求分析的任务 2.4 需求分析的过程 2.5 与用户沟通的方法 2.6 分析建模与规格说明 2.7 验证软件需求,2.8 系统流程图 2.9 实体-联系图 2.10 数 据 流 图 2.11 数 据 字
2、 典 2.12 其他图形工具 2.13 成本效益分析 2.14 结构化分析实例 2.15 小 结,2.1 可行性研究的任务 并不是任何问题都有简单明了的解决办法，事实上，许多问题不可能在预定的系统规模和期限之内解决。如果问题没有可行的解决办法，那么花费在这项开发工程上的时间、资源、人力和经费都是无谓的浪费。 可行性研究的目的就是，用最小的代价在尽可能短的时间内研究并确定所面临的问题是否能够解决。必须记住，可行性研究的目的不是解决问题，而是确定问题是否值得去解决。怎样达到这个目的呢？当然不能靠主观猜想而只能靠客观分析。必须分析几种主要的可能解法的利弊，从而判断原定的系统目标和规模是否现实，系统完
3、成后所能带来的效益是否大到值得投资开发这个系统的程度。因此，可行性研究实质上是要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。,返回目录,一般说来，至少应该从下述三方面研究每种解法的可行性。 （1）技术可行性：使用现有的技术能实现这个系统吗? （2）经济可行性：这个系统的经济效益能超过它的开发成本吗? （3）操作可行性：系统的操作方式在这个用户组织内行得通吗? 必要时还应该进一步从法律、社会效益等更广泛的角度研究每种解法的可行性。 分析员应该为每个可行的解法制定一个粗略的实现进度。,当然，可行性研究最根本的任务是对以后的行动方针提出
4、建议。如果问题没有可行的解，分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费；如果问题值得解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。 可行性研究需要的时间长短取决于工程的规模，一般说来，可行性研究的成本只是预期的工程总成本的5%10%。,2.2 可行性研究过程,怎样进行可行性研究呢？典型的可行性研究过程有下述一些步骤。 1. 复查系统规模和目标 2. 研究目前正在使用的系统 3. 导出新系统的高层逻辑模型 4. 进一步定义问题 可行性研究的前四个步骤实质上构成一个循环。分析员定义问题，分析这个问题，导出一个试探性的解；在此基础上再次定义问题，再一次分
5、析这个问题，修改这个解；继续这个循环过程，直至提出的逻辑模型完全符合系统目标。,返回目录,5. 导出和评价供选择的解法 6. 推荐行动方针 7. 草拟开发计划 8. 书写文档提交审查,2.3 需求分析的任务,为了开发出真正满足用户需求的软件产品，首先必须确切地知道用户的需求。对软件需求的深入理解，是软件开发工作获得成功的前提和关键，不论我们把设计和编码工作做得多么出色，不能真正满足用户需求的软件只会给用户带来失望，给开发者带来烦恼。 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。 需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完
6、成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。,返回目录,可行性研究阶段产生的文档，特别是数据流图，是需求分析的出发点。 需求分析的结果是系统开发的基础，关系到工程的成败和软件产品的质量。因此，必须用行之有效的方法对软件需求进行严格的审查验证。,下面简要地叙述需求分析阶段的具体任务。 1. 确定对软件系统的综合要求 对系统的综合要求主要有下述四个方面。 （1）系统功能要求 应该划分出系统必须完成的所有功能。 （2）系统性能要求 例如，联机系统的响应时间（即对于从终端输入的一个“事务”，系统在多长时间之内可以做出响应），系统需要的存储容量以及后援存储，重新启动和安全性等方面的考虑
7、都属于性能要求。 （3）运行要求 这类要求集中表现为对系统运行时所处环境的要求。例如，支持系统运行的系统软件是什么，采用哪种数据库管理系统，需要什么样的外存储器和数据通信接口等。 （4）将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦需要时能比较容易地进行这种扩充和修改。,2. 确定对系统的数据要求 任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分
8、析的一个重要任务。分析系统的数据要求通常采用建立概念模型的方法（参见2.9节）。,3. 导出系统的逻辑模型 综合上述两项需求分析的结果，可以导出系统详细的逻辑模型。通常用数据流图、数据字典和主要的处理算法描述这个逻辑模型。 4. 修正系统开发计划 根据在需求分析过程中获得的对软件系统更深入、更具体的认识，可以较准确地估计系统的成本和进度，从而可以修正在前一个阶段所制定的开发计划。,5. 开发原型系统 在需求分析过程中使用原型系统的主要目的是，使得用户通过实践获得关于未来的系统将怎样为他们工作的更直接更具体的概念，从而可以更准确地提出和确定他们对所开发的软件的要求。,具体地说，把建立原型系统作为
9、一种应该采取的策略的主要理由如下： 由于人类认识能力的局限性，用户往往不能预先提出全部要求； 在用户和系统分析员之间存在固有的通信鸿沟，分析员常常误解了用户的需求； 用户需要一个可运行的系统模型，以便获得有关未来系统的实践经验； 在软件开发过程中重复和反复是必要的和不可避免的； 目前已经有快速建立原型系统的工具可供选用。,2.4 需求分析的过程,结构化分析方法（简称SA方法）就是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目的之一就是把数据流和数据存储定义到元素级。为了达到这个目的，通常从数据流图的输出端着手分析，这是因为系统的目标是
10、产生这些输出，输出数据确定了系统必须具有的最基本的组成元素。,返回目录,典型的需求分析过程主要由下述步骤组成。 1. 沿数据流图回溯 2. 请用户复查 3. 细化数据流图 随着分析过程的进展，经过发现问题和解答问题的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能需求的满意了解。图2.1粗略地概括了上述分析过程。,图2.1 需求分析的基本过程,4. 修正开发计划 5. 书写文档 6. 审查和复审,2.5 与用户沟通的方法,软件需求分析过程总是从两方或多方之间的沟通与交流开始。用户面临的问题需要使用基于计算机的方案来解决；软件开发者的任务是开发出真正满足用户需求的软件产品
11、。通常，用户对他们所面临的问题有亲身体会，知道必须做什么，但是往往不能完整准确地表达出他们的要求，更不知道怎样利用计算机软件解决他们的问题；软件开发人员知道怎样用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。这样就需要相互沟通和交流信息。但是，从开始通信到真正相互理解的道路通常是充满坎坷的，良好的通信技术有助于加快相互理解的过程。,返回目录,正如我们在2.3节已经指出的那样，原型系统是促进沟通的重要手段，快速建立软件原型是最准确、最有效、最强大的需求分析技术。除了通过原型系统相互沟通之外，还有一些与用户通信的技术，本节将介绍两种典型技术。,2.5.1 访谈 访谈（或称为会谈）是最早
12、开始运用的获取用户需求的技术，也是迄今为止仍然广泛使用的主要的需求分析技术。 访谈有两种基本形式，分别是正式的和非正式的访谈。 当需要调查大量人员的意见时，向被调查的人员分发调查表是一个十分有效的做法。 在对用户进行访谈的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户运用目标系统解决某个具体问题的方法和结果进行分析。,情景分析的用处主要体现在下述两个方面： 它能在某种程度上演示产品的行为，从而便于用户理解，而且还可能进一步揭示出一些系统分析员目前还不知道的需求。 由于情景分析较易为用户所理解，因此，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是了
13、解用户的真正需求，而这一信息的惟一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。,2.5.2 简易的应用规格说明技术 使用传统的访谈技术定义需求时，用户和开发者往往有意无意地区分“我们和他们”。由于不能做到像同一个团队的人那样同心协力地识别和精化需求，这种方法的效果有时并不理想（经常发生误解，还可能遗漏重要的信息）。 为了解决上述问题，人们研究出了一种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案的要素，商讨不同的方法并指定基本的需求。今天，简易的应用规格说明技术已经成为信息系统界使用的主流技术。,尽
14、管存在许多不同的简易应用规格说明方法，但是它们遵循的基本准则是相同的，如下所述： 在中立地点举行由开发者和用户双方出席的会议。 制定准备会议和参加会议的规则。 提出一个议事日程，这个日程应该足够正式以便能够涵盖所有要点，同时这个日程又应该足够非正式，以便鼓励自由思维。 由一个“协调人”来主持会议，他既可以是用户也可以是开发者还可以是从外面请来的人。 使用一种“定义机制”（例如，工作表、图表等）。 目标是标识问题、提出解决方案要素、商讨不同的方法以及在有利于实现目标的氛围中指定初步的需求。,2.6 分析建模与规格说明,2.6.1 分析建模 系统分析，特别是需求分析的主要任务，是理解用户的需求定义
15、所要开发的目标系统。为了更好地理解问题，人们常常采用建立模型的方法。在本书前面的章节中已经非正式地使用了术语“模型”，所谓模型就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。 从技术的角度看，软件工程实质上是从一系列建模活动开始的，这些建模活动导致对要求开发的软件要有完整的需求规格说明和全面的设计表示。,返回目录,结构化分析就是一种建立结构化的分析模型的活动。从不同角度描述或理解软件系统，需要不同的模型。结构化分析主要建立功能模型和数据模型。数据流图是建立功能模型的基础，在本章2.10节将详细讲述数据流图。实体联系图是用
16、于建立数据模型的图形，将在2.9节中讲述。,2.6.2 软件需求规格说明书 由国家标准局发布的国家标准GB8567-88“计算机软件产品开发文件编制指南”，规定了在需求分析阶段应写出两份文档，分别是“软件需求说明书”和“数据要求说明书”。综合上述两份文档及其他资料的内容，本书以下给出了软件需求规格说明书的编写大纲，供读者在实际工作中使用。,. 引言 1. 编写目的 说明编写这份文档的目的，指出预期的读者。 2. 背景 指明项目的委托单位、开发单位、主管部门和用户，说明所开发的软件系统与其他系统的关系。 3. 定义 列出本文档中使用的专门术语的定义和缩写词的含义。 4. 参考资料 列出与本项目，特别是与本文档有关的参考资料，应该列出这些参考资料的标题、文件编号、发表日期和出版单位，说明可得到这些资料的来源。,. 任务概述 1. 目标 叙述该项软件开发的意图、应用目标、作用范围以及与其他相关软件之间的关系。如果所开发的软件是一个更大的系统的一个组成部分，则还应该说明它与该系统中其他各组成部分之间的关系。 2. 用户
