[工学]软件工程导论张海藩第5版第23章.ppt

《[工学]软件工程导论张海藩第5版第23章.ppt》由会员分享，可在线阅读，更多相关《[工学]软件工程导论张海藩第5版第23章.ppt（62页珍藏版）》请在三一办公上搜索。

1、2023/2/1,软件工程导论 王培丽,1,2 结构化分析,传统的软件工程方法学采用结构化分析技术，完成系统分析(问题定义、可行性研究和需求分析)的任务。结构化分析技术主要有下述几个要点：采用自顶向下功能分解的方法 强调逻辑功能而不是实现功能的具体方法 使用图形(主要是数据流图)进行系统分析并表达分析的结果,2023/2/1,软件工程导论 王培丽,2,2.1 可行性研究,可行性研究的任务 可行性研究的过程 系统流程图 成本/效益分析,2023/2/1,软件工程导论 王培丽,3,2.1.1 可行性研究的任务,可行性研究的目的 用最小的代价在尽可能短的时间内研究并确定客户提出的问题是否有行得通的解

2、决办法。可行性研究的内容技术可行性：使用现有的技术能实现这个系统吗？经济可行性：这个系统的经济效益能超过他的开发成本吗？操作可行性：操作方式在这个系统内行得通吗？,2023/2/1,软件工程导论 王培丽,4,2.1.2 可行性研究的过程,可行性研究的过程 复查系统规模和目标 研究目前正在使用的系统 导出新系统的高层逻辑模型 进一步定义问题 导出和评价供选择的解法 推荐行动方针 草拟开发计划 书写文档提交复审,2023/2/1,软件工程导论 王培丽,5,2.1.3 系统流程图,进行可行性研究时需了解和分析现有系统，并以概括的形式表达对现有系统的认识。系统流程图是概括的描绘物理系统的传统工具。基本

3、思想是用图形符号以黑盒子的形式描绘组成系统的每个部件，表达数据在系统各部件之间流动的情况。,2023/2/1,软件工程导论 王培丽,6,2.1.3 系统流程图,符号,2023/2/1,软件工程导论 王培丽,7,2.1.3 系统流程图,符号,2023/2/1,软件工程导论 王培丽,8,2.1.3 系统流程图,实例,图2.3库存清单系统的系统流程图,2023/2/1,软件工程导论 王培丽,9,2.1.4 数据流图,数据流图(DFD,Data Flow Diagram)是以图形的形式描绘数据在软件中流动和被处理的逻辑过程。设计数据流图只需考虑系统必须完成的基本逻辑功能，完全不需要考虑如何具体的实现这

4、些功能。数据流图一般在软件生命周期的早期阶段开始进行设计，在软件生命周期后续阶段不断改进、完善和细化,2023/2/1,软件工程导论 王培丽,10,2.1.4 数据流图,符号,图2.4数据流图的4种基本符号,2023/2/1,软件工程导论 王培丽,11,2.1.4 数据流图,符号数据存储和数据流都表示数据，前者表示处于静止状态的数据，后者表示处于运动的数据。数据流图中忽略出错处理，基本要点是描绘“做什么”。基本方法是从基本系统模型出发，自顶向下从抽象到具体分层次地画。,2023/2/1,软件工程导论 王培丽,12,2.1.4 数据流图,数据流图的画法(1)先画顶层数据流图，只包含一个处理的图，

5、画图时先画数据源点与终点；(2)细化数据流图；(3)功能级数据流图中描绘的系统主要功能进一步细化。,2023/2/1,软件工程导论 王培丽,13,2.1.4 数据流图,画数据流图的原则:(1)数据流图中所有图形只限于四种基本图形元素；(2)每个处理至少有一个输入数据和一个输出数据；(3)每个元素都必须有名字；(4)数据流图只反映系统做什么；(5)按照层次给处理过程编号；(6)父图与子图要平衡(输入和输出要一致);(7)存储：一个局部存储只要当它作为某些处理的数据接口或某个处理特定的输入输出时就要把它画出来；(8)提高数据流的易理解性，合理分解，分层清楚。,2023/2/1,软件工程导论 王培丽

6、,14,2.1.4 数据流图,数据流图的命名规则:为数据流(或数据存储)命名(1)代表整个数据流(数据存储)的内容；(2)部使用空洞的、缺乏具体含义的名字；(3)名字只能是名词或名词短语；(4)整体命名较困难时，可尝试分解。为处理命名(1)名字反映整个处理功能；(2)名字为动宾结构；(3)最好包括一个动词；(4)通常先为数据流命名然后再为相关处理命名,2023/2/1,软件工程导论 王培丽,15,2.1.5 数据字典,数据字典是关于数据的信息的集合，是对数据流图中包含元素的定义的集合。它的作用是在软件分析和设计的过程中提供关于数据的信息描述。内容(1)数据流：名称，别名，简述，来源，去向，数据

7、流通量；(2)数据流分量(数据元素)：数据元素名，别名，类型(数字，文字)，长度，取值范围；(3)数据存储；(4)处理。,2023/2/1,软件工程导论 王培丽,16,2.1.6 成本估计,代码行技术：估计实现软件的代码行数，然后乘以每行代码的平均成本得出软件的成本。任务分解结束首先把软件开发项目分解成若干个相对独立的任务，然后分别估计完成每项任务的成本，最后累加起来得到软件的总成本。,2023/2/1,软件工程导论 王培丽,17,思考与练习,课后题第2,3题要求：第2题要求画出存款系统的数据流图，并写出数据字典；第3题要求画出数据流图。,2023/2/1,软件工程导论 王培丽,18,2.2

8、需求分析,为什么要进行需求分析？在需求阶段修复一个错误的费用是编码阶段的1/5到1/10，是维护阶段修复费用的1/100到1/200。因此，我们可以认为，设计错误的修复费用要远远高于编码错误的修复费用。通过“分析”，理解用户的各种问题，通过“规格说明”把问题表达出来。要求大家：（1）掌握具体的步骤和方法（2）提高分析问题和解决问题的能力（3）熟练运用一些图形工具,2023/2/1,软件工程导论 王培丽,19,2.2.1 需求分析的任务,需求分析的基本任务 该阶段是软件定义时期的最后一个阶段，基本任务是准确地回答“系统必须做什么？”这个问题。用户和软件人员双方一起来充分理解用户的要求，并把双方共

9、同的理解明确地表达成一份书面文档软件需求规格说明书。,2023/2/1,软件工程导论 王培丽,20,2.2.1 需求分析的任务,需求分析的具体任务 确定对系统的综合要求 功能要求：系统必须完成的所有功能 性能要求：系统必须满足的约束 可靠性和可用性需求：系统的可靠性 出错处理需求：系统对错误环境的响应 接口需求：应用系统与环境通信的格式 约束：设计系统应遵守的限制条件 逆向需求：系统不应该做什么 将来可能提出的要求：分析将来可能会提出的要求,2023/2/1,软件工程导论 王培丽,21,2.2.1 需求分析的任务,分析系统的数据要求 分析系统的数据要求通常采用建立数据模型的方法。常用的图形工具

10、有层次方框图和Warnier图。导出系统的逻辑模型 通常用数据流图、实体关系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。修正系统开发计划,2023/2/1,软件工程导论 王培丽,22,2.2.2 与用户沟通获取需求的方法,访谈 最早开始使用的获取用户需求的方法，是迄今为止仍广泛使用的需求分析方法。访谈有两种基本形式：正式的和非正式的谈判。正式谈判：系统分析员将提出一些事先准备好地具体问题，得出结论性的意见。如询问客户公司的产品种类等。非正式谈判：分析员将提出一些用户可以自由回答的开放性问题，如询问用户对目前使用的系统有哪些不满意的地方等。,2023/2/1,软件工程导论 王培丽,

11、23,2.2.2 与用户沟通获取需求的方法,访谈 当需要调查大量人员的意见时，请被调查人填写调查表是十分有效的做法。在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析技术，就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。,2023/2/1,软件工程导论 王培丽,24,2.2.2 与用户沟通获取需求的方法,面向数据流自顶向下求精,图3.1面向数据流自顶向下求精过程,2023/2/1,软件工程导论 王培丽,25,2.2.2 与用户沟通获取需求的方法,简易的应用规格说明技术 简易的应用规格说明技术是一种面向团队的需求收集技术。这种方法提倡用户与开发者密切合作，共同标识问题，

12、提出解决方案要素，商讨不同的方案并指定基本需求。目前这种技术已经成为信息系统领域使用的主流技术。,2023/2/1,软件工程导论 王培丽,26,2.2.2 与用户沟通获取需求的方法,快速建立软件原型 快速建立软件原型是最准确、最有效、最强大的需求分析技术。所谓软件原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建软件原型的要点是，它应该实现用户看得见的功能，省略目标系统的“隐含”功能。软件原型的特点:快速和易修改。,2023/2/1,软件工程导论 王培丽,27,2.2.3 分析建模,模型的定义 为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。通常模型由一组图

13、形符号和组织这些符号的规则组成。建模的准则(1)必须理解并描述问题的信息域，据这条准则应建立数据模型；(2)必须定义软件应完成的功能，这条准则要求建立功能模型；(3)必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型；(4)必须描述目标系统信息、功能和行为的模型进行分解，用层次的方式展示细节。,2.2.4 需求规格说明,需求规格说明(SRS,Software Requirement Specification）精确地阐述一个软件系统必须提供的功能和性能以及它 所要考虑的限制条件。,作用,-成为用户、分析人员和设计人员之间 进行理解和交流的手段,-支持系统测试活动,-用于规划和控制系统

14、的开发过程,27,需求规格说明,应该包括在SRS 中的内容 功能：软件应该提供什么功能？-外部接口：软件如何与人、系统硬件和其他系统等进行相互作用？-性能：软件系统在运行速度、可用性、响应时间、恢复时间 等方面有什么要求？-特性：软件系统在可移植性、可维护性、安全性等方面有什 么考虑？-设计约束：是否存在必要的标准、开发语言、数据库、资源 限制、运行环境等因素的影响和策略？,28,编写需求规格说明的原则,原则 1：只描述“做什么”而无须描述“怎么做”原则 2：必须说明运行环境,原则 3：考虑用户、分析员和实现者的交流,对形式化和自然语言之间作出恰当的选择-明确的理解最重要，不存在十全十美的软件

15、规格说明书 原则 4：力求寻找到恰如其分的需求详细程度,-一个有益的原则就是编写单个的可测试需求文档-建议将可测试的需求作为衡量软件产品规模大小的尺度,30,编写需求规格说明的原则,原则 5：文档段落不宜太长,-简短,-记住：不要在需求说明中使用“和/或”、“等等”之类的词,原则 6：避免使用模糊的、主观的术语,-如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等,-不可验证,建议：采用一种标准的SRS 模板,31,1.引言1.1 目的1.2 文档约定1.3 预期的读者和阅读建议1.4 产品范围1.5 参考文献2.综合描述2.1 产品的前景2.2 产品

16、的功能2.3 用户类和特征2.4 运行环境2.5 设计和实现上的设计2.6 假设和依赖3外部接口需求3.1 用户界面,3.2 硬件接口3.3 软件接口3.4 通信接口4.系统特性 4.1 说明和优先级 4.2 激励/响应序列 4.3 功能需求5.非功能需求 5.1 性能需求 5.2安全设施需求 5.3 安全性需求 5.4 软件质量属性 5.5业务规划5.6 用户文档6.其他需求 附录,2023/2/1,软件工程导论 王培丽,32,SRS模板,需求验证,需求验证是检验需求能否满足客户的意愿。,需求验证的技术,-需求评审：由不同代表（如分析员、客户、设计人员、测试 人员）组成的评审小组以会议形式对

17、需求进行系统性分析。-原型评价：客户和用户在一个可运行的系统模型上实际检验 系统是否符合他们的真正需要。,-测试用例生成：通过设计具体的测试方法，发现需求中的许 多问题。,需求验证主要围绕需求规格说明的质量特性展开。,33,需求规格说明的质量特性,正确性,-需求规格说明对系统功能、行为、性能等的描述必须与用户 的期望相吻合，代表了用户的真正需求。,审查需求的正确性应该考虑的问题,-用户参与需求过程的程度如何？,-每一个需求描述是否准确地反映了用户的需要？-系统用户是否已经认真考虑了每一项描述？-需求可以追溯到来源吗？,举例：下面的需求描述正确吗？,-在用户每次存钱的时候系统将进行信用检查。,3

18、4,需求规格说明的质量特性,无二义性,-需求规格说明中的描述对于所有人都只能有一种明确统一的 解释。,审查需求的无二义性应该考虑的问题,-需求规格说明是否有术语词汇表？,具有多重含义或未知含义的术语是否已经定义？-需求描述是否可量化和可验证？,-每一项需求都有测试准则吗？,举例：下面的需求描述是无歧义的吗？,-如果用户试图透支，系统将采取适当的行动。,35,需求规格说明的质量特性,完整性,-需求规格说明应该包括软件要完成的全部任务，不能遗漏任 何必要的需求信息。,审查需求的完整性应该考虑的问题,-是否存在遗漏的功能或业务过程？-在每个定义的功能之间是否有接口？是否有信息或消息在所定义的功能之间

19、传递？-是否定义了功能的使用者？,-是否已经清楚地定义了用户与功能之间的交互？是否定义了与外部过程和系统之间的接口？,36,需求规格说明的质量特性,审查需求的完整性应该考虑的问题（续）,所描述的功能是否可以映射到业务过程中？-文档中是否存在待确定的需求引用？-文档中是否存在未定义的术语和引用？-文档的各个部分都完整吗？,-需求包括非功能属性的说明吗？,是否考虑了软件性能？,是否考虑了安全性要求？是否考虑了可靠性？是否考虑了系统容量问题？,37,需求规格说明的质量特性,可验证性,-需求规格说明中描述的需求都可以运用一些可行的手段对其 进行验证和确认。,审查需求的可验证性应该考虑的问题,在需求文档

20、中是否存在不可验证的陈述，诸如“用户界面友 好”、“容易”、“简单”、“快速”、“健壮”、“最新技术”等？-所有描述都是具体的和可测量的吗？,举例：下面的两个需求描述中哪一个难以验证？,-系统将在 20 秒内响应所有有效的请求。,-如果用户试图透支，系统将采取适当的行动。,38,需求规格说明的质量特性,一致性,-需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。,审查需求的一致性应该考虑的问题-文档的组织形式是否易于一致？-不同功能的描述之间是否存在矛盾？-是否存在有矛盾的需求描述或术语？-文档中是否存在时序上的不一致？,举例：下面的两个需

21、求描述是否有矛盾？,-系统允许立即使用所存的资金。,-只有在手工验证所存资金后，系统才能允许使用。,39,需求规格说明的质量特性,可修改性,-需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致。,审查需求的可修改性应该考虑的问题,-是否存在明显的需求交叉引用？,-是否有内容列表和索引？,-是否存在冗余的需求，即同一个需求的描述出现在文档的不 同地方？如果存在，它们是交叉引用吗？,40,需求规格说明的质量特性,可跟踪性,-每一项需求都能与其对应的来源、设计、源代码和测试用例 联系起来。,可跟踪性的两种形式,-每一项需求都可以在早期的文档中追溯到其来源，例如备忘 录、法规、会议记录

22、等；,-每一项需求都有唯一的名称或索引号，与后期实现对应。举例：下面的需求描述记录了早期的文档来源。,-系统将在 20 秒内响应所有有效的请求。,来自与用户的面谈，备忘录编号#1234,41,需求管理,需求管理是分析变更影响并控制变更的过程，主要包 括变更控制、版本控制和需求跟踪等活动。,需求管理,变更控制,版本控制,需求跟踪,需求状态跟踪,建议变更,确定需求文档,定义对其它需,定义需求状态,分析影响,的版本,求的连接链,跟踪需求的每,作出决策,确定单个需求,定义对其它系,一个状态,交流,文档的版本,统元素的连接,合并,链,测量需求的稳 定性,42,需求管理,活动 2：需求用于计,目标 1：软

23、件需求形成基线,划、产品和活动,活动 1：需求在纳入项,需求基线,目开发之前进行评审,变更申请,活动 3：对需求变更评审,目标 2：计划、产品和活动与需求保持一致,43,需求管理,需求跟踪性,-需求跟踪性是维护需求与软件制品之间的映射（例如设计对 象、用例、测试用例、已实现的软件组件等），以满足整个 开发生命周期的需要。,建立需求跟踪性的过程,-识别并唯一地标识SRS 中的每一个需求-建立和更新SRS 中的跟踪矩阵,-工作制品的创建者负责增加该制品与需求的跟踪信息-跟踪矩阵应该作为工作制品的一部分进行审查,44,需求管理,需求跟踪矩阵示例,用例 功能需求 设计元素 代码 测试实例,UC1,Ca

24、talog.query.sort,Class catalog,Catalog.sort(),test2,test3,UC2,Catalog.update,Class catalog,Catalog.update(),test10,test11 test12,需求管理需要CASE 工具的支持,-例如：DOORS，RequisitePro,45,需求描述示例,举例 1,产品必须在固定的时间间隔内提供状态信息，并且每次时间间隔 不得小于 60 秒。,?,?,?,?,问题,-上述需求描述有什么缺陷？-如何改正？,46,需求描述示例与改正,改正,后台任务管理器应该在用户界面的指定区域显示状态信息。（1）

25、在后台任务进程启动之后，消息必须每隔 6010 秒更新一 次，并且保持连续的可见性。,（2）如果正在正常处理后台任务进程，那么后台任务管理器必 须显示后台任务进程已完成的百分比。,（3）当完成后台任务时，后台任务管理器必须显示一个“已完 成”的信息。,（4）如果后台任务中止执行，那么后台任务管理器必须显示一 个出错信息。,47,需求描述示例,举例 2,如果可能的话，应当根据图书编号的列表在线确认所输入的图书 编号。,问题,-,“如果可能的话”意味着什么？,-,“应当”是否精确？,-如何改正？,48,需求描述示例与改正,改正,系统必须根据在线的图书编号列表确认所输入的图书编号。如果 在图书编号列

26、表中查不到该图书的编号，或者当进行图书编号确 认时图书编号列表不可访问，系统必须显示一个出错信息并且拒 绝预订。,49,需求描述示例,举例 2,如果可能的话，应当根据图书编号的列表在线确认所输入的图书 编号。,问题,-,“如果可能的话”意味着什么？,-,“应当”是否精确？,-如何改正？,48,需求描述示例与改正,改正,系统必须根据在线的图书编号列表确认所输入的图书编号。如果 在图书编号列表中查不到该图书的编号，或者当进行图书编号确 认时图书编号列表不可访问，系统必须显示一个出错信息并且拒 绝预订。,49,2023/2/1,软件工程导论 王培丽,52,2.2.5 实体-联系图,ER图 为了把用户

27、的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型，是一种面向问题的数据模型，描述了从用户角度看到的数据。内容(1)实体(即数据对象)，用矩形框表示；(2)关系,用连接相关实体的菱形框表示；(3)属性，用椭圆形或圆角矩形表示，并用直线把实体或关系与其属性连接起来。,2023/2/1,软件工程导论 王培丽,53,2.2.6 几种图形工具,状态转换图 简称为状态图，描绘系统状态及引起系统状态变换的事件来表示系统的行为，反应了状态与事件之间的关系。状态图提供了行为建模机制。状态图描述了系统中某些复杂对象的状态变化，主要有状态、变迁和事件三种描述。,2023/2/1,软件工程导论

28、王培丽,54,2.2.6 几种图形工具,状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应可以是做一个（或一系列）动作，也可以只是改变系统本身的状态，还可以既改变状态又做动作。状态图中定义的状态有：初态、终态和中间状态；在一张状态图中只能有一个初态，而终态可以有若干个。事件事件是引起系统做动作或转换状态的控制信息。,2023/2/1,软件工程导论 王培丽,55,2.2.6 几种图形工具,符号,状态变量的名字和值,状态转换,Entry:表示进入该状态的动作Exit:表示退出本状态的动作Do:在本状态下的动作,状态变迁通常是由

29、事件触发的，这时应在状态转换上标出触发转换的事件表达式如果箭头上没有标明事件，则表示在源状态内部活动完成后自动出发转换,状态的名称,事件表达式的语法：事件说明守卫条件/动作表达式事件说明的语法：事件名（参数表）守卫条件是一个布尔表达式动作表达式表示当状态转换开始时执行该表达式,（4）实例,【一】电话系统状态图,43,2023/2/1,软件工程导论 王培丽,57,2.2.6 几种图形工具,层次方框图 层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。,2.2.6 几种图形工具,Warnier图 由法国专家Warnier提出 用树形结构描绘信息 表明了信息的逻辑组织结构,47,2023

30、/2/1,软件工程导论 王培丽,59,2.2.6 几种图形工具,IPO图 描绘输入数据、对数据的处理和输出数据之间的关系。,1.需求分析（）A.要回答“软件必须做什么？”B.可概括为：“理解、分解、表达”6个字 C.要求编写需求规格说明书 D.以上都对2.结构化分析方法使用的描述工具（）定义了数据流图中每一个图形元素 A.数据流图 B.数据字典 C.判定表 D.判定树3.软件需求规格说明书的内容不应该包括对（）的描述。A.主要功能 B.算法的详细过程 C.用户界面及运行环境 D.软件的性能,思考与练习,4.数据存储和数据流都是（），仅仅所处的状态不同。A.分析结构 B.事件 C.动作 D.数据

31、5.需求分析最终结果是产生（）A.项目开发计划 B.可行性分析报告 C.需求规格说明书 D.设计说明书6.在结构化分析方法（SA）中，与数据流图配合使用的是（）A.网络图 B.数据字典 C.实体联系图 D.程序流程图7.SA方法的基本思想是（）A.自顶向上逐步抽象 B.自顶向上逐步分解 C.自顶向下逐步分解 D.自顶向下逐步抽象,思考与练习,8.下列哪项不是在需求分析阶段要进行工作（）A.问题识别 B.分析与综合C.导出软件的逻辑模型 D.编码9.可行性分析研究的目的是（）A.争取项目B.项目是否值得开发 C.开发项目D.规划项目10DFD是常用的进行软件需求分析的图形工具，其基本符号是（）A输入、输出、外部实体和加工 B.变换、加工、数据流和存储 C.加工、数据流、数据存储和外部实体 D.变换、数据存储、加工和数据流,思考与练习,