【文档说明】软件工程第4章--软件分析课件.pptx，共(55)页，1.303 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-44999.html

以下为本文档部分文字说明：

第4章软件分析计算机系统结构软件系统前期分析项目可行性分析软件需求分析软件需求验证1.计算机系统工程计算机系统计算机系统是一个复杂的系统，它包含硬件系统、软件系统、网络通信系统、人工操作系统等诸多子系统，而其中的软件系统又由操作

系统、数据库系统、应用程序等更小的系统元素组成。计算机体系结构几种典型的计算机体系结构：中央主机结构：主机集中了全部智能，并依靠终端接口与外部设备连接。计算机体系结构客户机/服务器结构：智能分布于服务器与客户机，并依靠网络连接成系统。其中，服务

器处于核心位臵，提供被动核心服务；客户机处于边缘位臵，可主动访问服务器，寻求服务支持。计算机体系结构浏览器/服务器结构：一种更适合互联网远程交互的基于Web应用的特殊的客户机/服务器结构。2.软件系统前期分析可从以下方

面进行软件高层分析：软件系统的业务领域、业务边界与业务流程。软件系统对硬件设施、网络环境、数据环境的依赖。软件系统的安全层级、措施与防范机制。软件系统与其它相关系统之间的协作关系。软件系统与用户组织及其工作任务的协调性与适应性。系统结构建模使用矩

形与带箭头的线段来描述系统的基本结构下图是自动阅卷系统的系统框架图。通常用来描述系统的逻辑框架。读卡程序成绩数据库成绩单打印程序成绩查询程序成绩分析程序成绩备份程序阅卷程序系统工作流建模——系统流程图系统流程图是概括地描绘物理系统的传统工具。基本思想：用图形符号以黑盒子形式描绘组成系统的每个部

件(程序、文档、数据库、人工过程等)。系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不

是程序流程图。1.符号利用符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件（或数据库），把抽象处理具体化为特定的程序或手工操作等。以概括的方式抽象地描绘一个实际系统时，仅仅使用下图中列出的基本符号就足够了需要更具体地描绘一个

物理系统时还需要使用右图中列出的系统符号以一个简单的例子进行讲解。某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果哪种零件的库存量少于它的库存量临界

值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。2.例子该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中

；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。如下图所示。用来描述系统的工作流程，以系统中的物理组

件为单元说明系统的基本结构，并由此说明系统对数据的加工步骤下图是自动阅卷系统的系统流程图。答题卡片阅卷程序成绩数据库成绩查询程序查询显示成绩单成绩备份文件成绩备份程序成绩单打印程序读卡程序成绩分析程序3.项目可行性分析可行性分析意义工程经验表明：可行性分析对软件问题解决途径的探索，在以下几个

方面能够对软件项目带来积极的影响。1.通过少量的的费用，对项目能否实施尽早作出判断，以避免项目开展以后所带来的大量的人力、物力和时间的浪费。2.根据项目所受到的条件限制，对有待开发的系统在体系结构、工作模式等方面作出抉择，以利于项目今后的实现。3.可以把可行

性分析看作软件定义时期需要进行的前导性工作，其结果可以作为一个高层框架用于软件需求分析过程之中，以方便今后软件规格定义工作的顺利开展。可行性研究的任务可行性研究的目的不是解决问题，而是确定问题是否值得去解决。首先，进一步分析和澄清问题定义然后，分析员应该导出

系统的逻辑模型最后，探索若干种可供选择的主要解法可行性研究分析过程：可行性研究的任务至少应该从下述3个方面研究每种解法的可行性技术可行性使用现有的技术能实现这个系统吗?经济可行性这个系统的经济效益能超过它的开发成本吗?应用可行性法律法规、系统的操作方式在这个用户组织

内行得通吗?可行性研究过程怎样进行可行性研究呢?典型的可行性研究过程有下述8个步骤。1.复查系统规模和目标2.研究目前正在使用的系统3.导出新系统的高层逻辑模型4.进一步定义问题5.导出和评价供选择的解法6.推荐行动方针7.草拟开发计

划书8.写文档提交审查1.复查系统规模和目标分析员访问关键人员，仔细阅读和分析有关的材料，以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。这个步骤的工作，实质上是为了确保分析员

正在解决的问题确实是要求他解决的问题。2.研究目前正在使用的系统现有的系统是信息的重要来源。显然，如果目前有一个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功

能；另一方面，如果现有的系统是完美无缺的，用户自然不会提出开发新系统的要求，因此，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。应该仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。常见的错误做法是花费过多时间去分析现有的系统。没有一

个系统是在“真空”中运行的，绝大多数系统都和其他系统有联系。3.导出新系统的高层逻辑模型优秀的设计过程通常是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统

。4.进一步定义问题可行性研究的前4个步骤实质上构成一个循环。分析员定义问题，分析这个问题，导出一个试探性的解；在此基础上再次定义问题，再一次分析这个问题，修改这个解；继续这个循环过程，直到提出的逻辑模型完全符合系统目标。5.导出和评价供选择

的解法分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的物理解法供比较和选择。其次可以考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。接下来应该考虑经济方面的可行性

。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，这个进度表不需要制定得很详细，通常只需要估计生命周期每个阶段的工作量。6.导出和评价供选择的解

法根据可行性研究结果应该决定的一个关键性问题是：是否继续进行这项开发工程？分析员必须清楚地表明他对这个关键性决定的建议。如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。

通常客户主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。7.草拟开发计划分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对

各类开发人员和各种资源的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本。最后应该给出下一个阶段(需求分析)的详细进度表和成本估计。8.书写文档提交审查应该把上述可行性研究各个步骤的工作结

果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。4.需求分析任务与过程需求分析是为有效解决用户需求问题而需要进行的一项工程活动，所需考虑的需求问题有

：功能需求、性能需求、接口需求、数据需求。开发者与用户都将参与需求分析活动。开发者承担分析任务，但活动核心则是用户。需求分析任务需要由熟悉用户业务的系统分析师承担。需求分析步骤是：获取用户需求、创建需求模型、确定软件规格、进行需求验证。需求分析的任务1、确定对系统的综合要求虽然功能需求是

对软件系统的一项基本需求，但却并不是唯一的需求。通常对软件系统有下述几方面的综合要求。功能需求性能需求可靠性和可用性需求出错处理需求接口需求约束逆向需求将来可能提出的要求功能需求这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能

性能需求性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。可靠性和可用性需求可靠性需求定量地指定系统的可靠性，可用性与可靠性密切相关，它量化了用户可以使用系统的程度。出错处理需求这类

需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。接口需求接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；

硬件接口需求；软件接口需求；通信接口需求。约束设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。逆向需求逆向需求说明软件系统不应该做什么。理

论上有无限多个逆向需求，人们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时

能比较容易地进行这种扩充和修改。任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。2、分析系统的数据要求复

杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。为了提高可理解性，常常利用图形工具辅助描绘数据结构。综合上述两项分析的结果可以导出

系统的详细的逻辑模字典和主要的处理算法描述这个逻辑模型。3、导出系统的逻辑模型根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。4、修正系统开发计划需求分析过程可行性报告分析

用户需求需求框架描述需求规格说明书需求细节描述建立需求原型需求验证分析系统需求5.获取用户需求用户泛指一切可从软件获得服务的对象。可以是某个人，但也可以是人以外的机构、部门、其他系统或设备。可通过调查而获取用户需求。然而，有效的需求收集则依赖于有效的调查提问，并依赖于合适的调查方法。一些常用

调查方法是：访谈、座谈、问卷、跟班、收集资料。来自用户的需求将体现为需求规约，其可表达用户的软件价值。与用户沟通获取需求的方法访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。访谈有两种基本形式，

分别是正式的和非正式的访谈。1、访谈正式访谈时，系统分析员将提出一些事先准备好的具体问题，例如，询问客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间应该多快等。在非正式访谈中，分析员将提出一些用户可以自由回

答的开放性问题，以鼓励被访问人员说出自己的想法，例如，询问用户对目前正在使用的系统有哪些不满意的地方。在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。情景分析技术的用处主要体现在

下述两个方面。它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。结构化分析方法就是面向数据流自顶向下逐步求精进

行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。2、面向

数据流自顶向下求精数据流图是帮助复查的极好工具，从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。这些解释集中反映了通过前面的分析工作分析员所获得的对目标

系统的认识。随着分析过程的进展，经过提问和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。3、简易的应用规格说明技术简易的应用规格说明技术是为了解决使用传统的访谈

或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想的问题，提出的。简易的应用规格说明技术分析需求的典型过程如下1•进行初步的访谈

2•开发者和用户分别写出“产品需求”。3•开会讨论，各自展示需求列表4•得出了意见一致，为需求列表制定小型规格说明5•根据会议结果，起草完整的软件需求规格说明4、快速建立软件原型为了快速地构建和修改原型，通常使用下述3种方法和工具。第

四代技术可重用的软件构件形式化规格说明和原型环境快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序，快速原型应该具备的特性：快速原型应该具备的第一个特性是“快速”。快速原型应该具备的第二个特性是“容易修改”。6.建立需求模型需求建模是用户需求问题图解，一些常用模型有：业务树图、用

例图、活动图。其中，业务树是结构化需求建模，用例图是系统业务举例，活动图则反映系统工作流程。7.进行需求验证需求验证是指对需求分析成果的检查与确认。主要的需求验证内容有：有效性验证、一致性验证、完整性

验证、现实性验证。可通过需求原型确认或需求评审，而实现需求验证。验证软件需求1、从哪些方面验证软件需求的正确性需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质

量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证。一致性是指所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。完整性是指需

求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。现实性是指需求应该是用现有的硬件技术和软件技术基本上可以实现的。有效性是指必须证明需求是正确有效的，确实能解决用户面对的问题。上一小节已经指出，至少必须从一致性、完整性、现实性和有效性这4个不同角度验证软件

需求的正确性。那么，怎样验证软件需求的正确性呢?验证的角度不同，验证的方法也不同。2、验证软件需求的方法验证需求的一致性验证需求的现实性验证需求的完整性和有效性验证需求的一致性当需求分析的结果是用自然语言书写的时

候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不

能在正确的基础上顺利进行。为了克服上述困难，人们提出了形式化的描述软件需求的方法。验证需求的现实性为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。验证需求的完整

性和有效性只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要，只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要(特

别在要开发的系统是全新的，以前没有使用类似系统的经验时，情况更是如此)，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。3、

用于需求分析的软件工具为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求。必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法

说明的内容。使用这个软件工具能够导出详细的文档。必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果。使用这个软件工具之后，应该能够改进通信状况。