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

2019 12 22 软件工程导论王培丽 1 2结构化分析 传统的软件工程方法学采用结构化分析技术 完成系统分析 问题定义 可行性研究和需求分析 的任务 结构化分析技术主要有下述几个要点 采用自顶向下功能分解的方法强调逻辑功能而不是实现功能的具体方法使用图形 主要是数据流图 进行系统分析并表达分析的结果 2019 12 22 软件工程导论王培丽 2 2 1可行性研究 可行性研究的任务可行性研究的过程系统流程图成本 效益分析 2019 12 22 软件工程导论王培丽 3 2 1 1可行性研究的任务 可行性研究的目的用最小的代价在尽可能短的时间内研究并确定客户提出的问题是否有行得通的解决办法 可行性研究的内容技术可行性 使用现有的技术能实现这个系统吗 经济可行性 这个系统的经济效益能超过他的开发成本吗 操作可行性 操作方式在这个系统内行得通吗 2019 12 22 软件工程导论王培丽 4 2 1 2可行性研究的过程 可行性研究的过程复查系统规模和目标研究目前正在使用的系统导出新系统的高层逻辑模型进一步定义问题导出和评价供选择的解法推荐行动方针草拟开发计划书写文档提交复审 2019 12 22 软件工程导论王培丽 5 2 1 3系统流程图 进行可行性研究时需了解和分析现有系统 并以概括的形式表达对现有系统的认识 系统流程图是概括的描绘物理系统的传统工具 基本思想是用图形符号以黑盒子的形式描绘组成系统的每个部件 表达数据在系统各部件之间流动的情况 2019 12 22 软件工程导论王培丽 6 2 1 3系统流程图 符号 2019 12 22 软件工程导论王培丽 7 2 1 3系统流程图 符号 2019 12 22 软件工程导论王培丽 8 2 1 3系统流程图 实例 图2 3库存清单系统的系统流程图 2019 12 22 软件工程导论王培丽 9 2 1 4数据流图 数据流图 dfd dataflowdiagram 是以图形的形式描绘数据在软件中流动和被处理的逻辑过程 设计数据流图只需考虑系统必须完成的基本逻辑功能 完全不需要考虑如何具体的实现这些功能 数据流图一般在软件生命周期的早期阶段开始进行设计 在软件生命周期后续阶段不断改进 完善和细化 2019 12 22 软件工程导论王培丽 10 2 1 4数据流图 符号 图2 4数据流图的4种基本符号 2019 12 22 软件工程导论王培丽 11 2 1 4数据流图 符号数据存储和数据流都表示数据 前者表示处于静止状态的数据 后者表示处于运动的数据 数据流图中忽略出错处理 基本要点是描绘 做什么 基本方法是从基本系统模型出发 自顶向下从抽象到具体分层次地画 2019 12 22 软件工程导论王培丽 12 2 1 4数据流图 数据流图的画法 1 先画顶层数据流图 只包含一个处理的图 画图时先画数据源点与终点 2 细化数据流图 3 功能级数据流图中描绘的系统主要功能进一步细化 2019 12 22 软件工程导论王培丽 13 2 1 4数据流图 画数据流图的原则 1 数据流图中所有图形只限于四种基本图形元素 2 每个处理至少有一个输入数据和一个输出数据 3 每个元素都必须有名字 4 数据流图只反映系统做什么 5 按照层次给处理过程编号 6 父图与子图要平衡 输入和输出要一致 7 存储 一个局部存储只要当它作为某些处理的数据接口或某个处理特定的输入输出时就要把它画出来 8 提高数据流的易理解性 合理分解 分层清楚 2019 12 22 软件工程导论王培丽 14 2 1 4数据流图 数据流图的命名规则 为数据流 或数据存储 命名 1 代表整个数据流 数据存储 的内容 2 部使用空洞的 缺乏具体含义的名字 3 名字只能是名词或名词短语 4 整体命名较困难时 可尝试分解 为处理命名 1 名字反映整个处理功能 2 名字为动宾结构 3 最好包括一个动词 4 通常先为数据流命名然后再为相关处理命名 2019 12 22 软件工程导论王培丽 15 2 1 5数据字典 数据字典是关于数据的信息的集合 是对数据流图中包含元素的定义的集合 它的作用是在软件分析和设计的过程中提供关于数据的信息描述 内容 1 数据流 名称 别名 简述 来源 去向 数据流通量 2 数据流分量 数据元素 数据元素名 别名 类型 数字 文字 长度 取值范围 3 数据存储 4 处理 2019 12 22 软件工程导论王培丽 16 2 1 6成本估计 代码行技术 估计实现软件的代码行数 然后乘以每行代码的平均成本得出软件的成本 任务分解结束首先把软件开发项目分解成若干个相对独立的任务 然后分别估计完成每项任务的成本 最后累加起来得到软件的总成本 2019 12 22 软件工程导论王培丽 17 思考与练习 课后题第2 3题要求 第2题要求画出存款系统的数据流图 并写出数据字典 第3题要求画出数据流图 2019 12 22 软件工程导论王培丽 18 2 2需求分析 为什么要进行需求分析 在需求阶段修复一个错误的费用是编码阶段的1 5到1 10 是维护阶段修复费用的1 100到1 200 因此 我们可以认为 设计错误的修复费用要远远高于编码错误的修复费用 通过 分析 理解用户的各种问题 通过 规格说明 把问题表达出来 要求大家 1 掌握具体的步骤和方法 2 提高分析问题和解决问题的能力 3 熟练运用一些图形工具 2019 12 22 软件工程导论王培丽 19 2 2 1需求分析的任务 需求分析的基本任务该阶段是软件定义时期的最后一个阶段 基本任务是准确地回答 系统必须做什么 这个问题 用户和软件人员双方一起来充分理解用户的要求 并把双方共同的理解明确地表达成一份书面文档 软件需求规格说明书 2019 12 22 软件工程导论王培丽 20 2 2 1需求分析的任务 需求分析的具体任务确定对系统的综合要求功能要求 系统必须完成的所有功能性能要求 系统必须满足的约束可靠性和可用性需求 系统的可靠性出错处理需求 系统对错误环境的响应接口需求 应用系统与环境通信的格式约束 设计系统应遵守的限制条件逆向需求 系统不应该做什么将来可能提出的要求 分析将来可能会提出的要求 2019 12 22 软件工程导论王培丽 21 2 2 1需求分析的任务 分析系统的数据要求分析系统的数据要求通常采用建立数据模型的方法 常用的图形工具有层次方框图和warnier图 导出系统的逻辑模型通常用数据流图 实体关系图 状态转换图 数据字典和主要的处理算法描述这个逻辑模型 修正系统开发计划 2019 12 22 软件工程导论王培丽 22 2 2 2与用户沟通获取需求的方法 访谈最早开始使用的获取用户需求的方法 是迄今为止仍广泛使用的需求分析方法 访谈有两种基本形式 正式的和非正式的谈判 正式谈判 系统分析员将提出一些事先准备好地具体问题 得出结论性的意见 如询问客户公司的产品种类等 非正式谈判 分析员将提出一些用户可以自由回答的开放性问题 如询问用户对目前使用的系统有哪些不满意的地方等 2019 12 22 软件工程导论王培丽 23 2 2 2与用户沟通获取需求的方法 访谈当需要调查大量人员的意见时 请被调查人填写调查表是十分有效的做法 在访问用户的过程中使用情景分析技术往往非常有效 所谓情景分析技术 就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析 2019 12 22 软件工程导论王培丽 24 2 2 2与用户沟通获取需求的方法 面向数据流自顶向下求精 图3 1面向数据流自顶向下求精过程 2019 12 22 软件工程导论王培丽 25 2 2 2与用户沟通获取需求的方法 简易的应用规格说明技术简易的应用规格说明技术是一种面向团队的需求收集技术 这种方法提倡用户与开发者密切合作 共同标识问题 提出解决方案要素 商讨不同的方案并指定基本需求 目前这种技术已经成为信息系统领域使用的主流技术 2019 12 22 软件工程导论王培丽 26 2 2 2与用户沟通获取需求的方法 快速建立软件原型快速建立软件原型是最准确 最有效 最强大的需求分析技术 所谓软件原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序 构建软件原型的要点是 它应该实现用户看得见的功能 省略目标系统的 隐含 功能 软件原型的特点 快速和易修改 2019 12 22 软件工程导论王培丽 27 2 2 3分析建模 模型的定义为了理解事物而对事物作出的一种抽象 是对事物的一种无歧义的书面描述 通常模型由一组图形符号和组织这些符号的规则组成 建模的准则 1 必须理解并描述问题的信息域 据这条准则应建立数据模型 2 必须定义软件应完成的功能 这条准则要求建立功能模型 3 必须描述作为外部事件结果的软件行为 这条准则要求建立行为模型 4 必须描述目标系统信息 功能和行为的模型进行分解 用层次的方式展示细节 2 2 4需求规格说明 需求规格说明 srs softwarerequirementspecification 精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件 作用 成为用户 分析人员和设计人员之间进行理解和交流的手段 支持系统测试活动 用于规划和控制系统的开发过程 27 需求规格说明 应该包括在srs中的内容功能 软件应该提供什么功能 外部接口 软件如何与人 系统硬件和其他系统等进行相互作用 性能 软件系统在运行速度 可用性 响应时间 恢复时间等方面有什么要求 特性 软件系统在可移植性 可维护性 安全性等方面有什么考虑 设计约束 是否存在必要的标准 开发语言 数据库 资源限制 运行环境等因素的影响和策略 28 编写需求规格说明的原则 原则1 只描述 做什么 而无须描述 怎么做 原则2 必须说明运行环境 原则3 考虑用户 分析员和实现者的交流 对形式化和自然语言之间作出恰当的选择 明确的理解最重要 不存在十全十美的软件规格说明书 原则4 力求寻找到恰如其分的需求详细程度 一个有益的原则就是编写单个的可测试需求文档 建议将可测试的需求作为衡量软件产品规模大小的尺度 30 编写需求规格说明的原则 原则5 文档段落不宜太长 简短 记住 不要在需求说明中使用 和 或 等等 之类的词 原则6 避免使用模糊的 主观的术语 如用户友好 容易 简单 迅速 有效 许多 最新技术 优越的 可接受的 最大化 最小化 提高等 不可验证 建议 采用一种标准的srs模板 31 1 引言1 1目的1 2文档约定1 3预期的读者和阅读建议1 4产品范围1 5参考文献2 综合描述2 1产品的前景2 2产品的功能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 其他需求附录 2019 12 22 软件工程导论王培丽 32 srs模板 需求验证 需求验证是检验需求能否满足客户的意愿 需求验证的技术 需求评审 由不同代表 如分析员 客户 设计人员 测试人员 组成的评审小组以会议形式对需求进行系统性分析 原型评价 客户和用户在一个可运行的系统模型上实际检验系统是否符合他们的真正需要 测试用例生成 通过设计具体的测试方法 发现需求中的许多问题 需求验证主要围绕需求规格说明的质量特性展开 33 需求规格说明的质量特性 正确性 需求规格说明对系统功能 行为 性能等的描述必须与用户的期望相吻合 代表了用户的真正需求 审查需求的正确性应该考虑的问题 用户参与需求过程的程度如何 每一个需求描述是否准确地反映了用户的需要 系统用户是否已经认真考虑了每一项描述 需求可以追溯到来源吗 举例 下面的需求描述正确吗 在用户每次存钱的时候系统将进行信用检查 34 需求规格说明的质量特性 无二义性 需求规格说明中的描述对于所有人都只能有一种明确统一的解释 审查需求的无二义性应该考虑的问题 需求规格说明是否有术语词汇表 具有多重含义或未知含义的术语是否已经定义 需求描述是否可量化和可验证 每一项需求都有测试准则吗 举例 下面的需求描述是无歧义的吗 如果用户试图透支 系统将采取适当的行动 35 需求规格说明的质量特性 完整性 需求规格说明应该包括软件要完成的全部任务 不能遗漏任何必要的需求信息 审查需求的完整性应该考虑的问题 是否存在遗漏的功能或业务过程 在每个定义的功能之间是否有接口 是否有信息或消息在所定义的功能之间传递 是否定义了功能的使用者 是否已经清楚地定义了用户与功能之间的交互 是否定义了与外部过程和系统之间的接口 36 需求规格说明的质量特性 审查需求的完整性应该考虑的问题 续 所描述的功能是否可以映射到业务过程中 文档中是否存在待确定的需求引用 文档中是否存在未定义的术语和引用 文档的各个部分都完整吗 需求包括非功能属性的说明吗 是否考虑了软件性能 是否考虑了安全性要求 是否考虑了可靠性 是否考虑了系统容量问题 37 需求规格说明的质量特性 可验证性 需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认 审查需求的可验证性应该考虑的问题 在需求文档中是否存在不可验证的陈述 诸如 用户界面友好 容易 简单 快速 健壮 最新技术 等 所有描述都是具体的和可测量的吗 举例 下面的两个需求描述中哪一个难以验证 系统将在20秒内响应所有有效的请求 如果用户试图透支 系统将采取适当的行动 38 需求规格说明的质量特性 一致性 需求规格说明对各种需求的描述不能存在矛盾 如术语使用冲突 功能和行为特性方面的矛盾以及时序上的不一致等 审查需求的一致性应该考虑的问题 文档的组织形式是否易于一致 不同功能的描述之间是否存在矛盾 是否存在有矛盾的需求描述或术语 文档中是否存在时序上的不一致 举例 下面的两个需求描述是否有矛盾 系统允许立即使用所存的资金 只有在手工验证所存资金后 系统才能允许使用 39 需求规格说明的质量特性 可修改性 需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致 审查需求的可修改性应该考虑的问题 是否存在明显的需求交叉引用 是否有内容列表和索引 是否存在冗余的需求 即同一个需求的描述出现在文档的不同地方 如果存在 它们是交叉引用吗 40 需求规格说明的质量特性 可跟踪性 每一项需求都能与其对应的来源 设计 源代码和测试用例联系起来 可跟踪性的两种形式 每一项需求都可以在早期的文档中追溯到其来源 例如备忘录 法规 会议记录等 每一项需求都有唯一的名称或索引号 与后期实现对应 举例 下面的需求描述记录了早期的文档来源 系统将在20秒内响应所有有效的请求 来自与用户的面谈 备忘录编号 1234 41 需求管理 需求管理是分析变更影响并控制变更的过程 主要包括变更控制 版本控制和需求跟踪等活动 需求管理 变更控制 版本控制 需求跟踪 需求状态跟踪 建议变更 确定需求文档 定义对其它需 定义需求状态 分析影响 的版本 求的连接链 跟踪需求的每 作出决策 确定单个需求 定义对其它系 一个状态 交流 文档的版本 统元素的连接 合并 链 测量需求的稳定性 42 需求管理 活动2 需求用于计 目标1 软件需求形成基线 划 产品和活动 活动1 需求在纳入项 需求基线 目开发之前进行评审 变更申请 活动3 对需求变更评审 目标2 计划 产品和活动与需求保持一致 43 需求管理 需求跟踪性 需求跟踪性是维护需求与软件制品之间的映射 例如设计对象 用例 测试用例 已实现的软件组件等 以满足整个开发生命周期的需要 建立需求跟踪性的过程 识别并唯一地标识srs中的每一个需求 建立和更新srs中的跟踪矩阵 工作制品的创建者负责增加该制品与需求的跟踪信息 跟踪矩阵应该作为工作制品的一部分进行审查 44 需求管理 需求跟踪矩阵示例 用例功能需求设计元素代码测试实例 uc1 catalog query sort classcatalog catalog sort test2 test3 uc2 catalog update classcatalog catalog update test10 test11test12 需求管理需要case工具的支持 例如 doors requisitepro 45 需求描述示例 举例1 产品必须在固定的时间间隔内提供状态信息 并且每次时间间隔不得小于60秒 问题 上述需求描述有什么缺陷 如何改正 46 需求描述示例与改正 改正 后台任务管理器应该在用户界面的指定区域显示状态信息 1 在后台任务进程启动之后 消息必须每隔60 10秒更新一次 并且保持连续的可见性 2 如果正在正常处理后台任务进程 那么后台任务管理器必须显示后台任务进程已完成的百分比 3 当完成后台任务时 后台任务管理器必须显示一个 已完成 的信息 4 如果后台任务中止执行 那么后台任务管理器必须显示一个出错信息 47 需求描述示例 举例2 如果可能的话 应当根据图书编号的列表在线确认所输入的图书编号 问题 如果可能的话 意味着什么 应当 是否精确 如何改正 48 需求描述示例与改正 改正 系统必须根据在线的图书编号列表确认所输入的图书编号 如果在图书编号列表中查不到该图书的编号 或者当进行图书编号确认时图书编号列表不可访问 系统必须显示一个出错信息并且拒绝预订 49 需求描述示例 举例2 如果可能的话 应当根据图书编号的列表在线确认所输入的图书编号 问题 如果可能的话 意味着什么 应当 是否精确 如何改正 48 需求描述示例与改正 改正 系统必须根据在线的图书编号列表确认所输入的图书编号 如果在图书编号列表中查不到该图书的编号 或者当进行图书编号确认时图书编号列表不可访问 系统必须显示一个出错信息并且拒绝预订 49 2019 12 22 软件工程导论王培丽 52 2 2 5实体 联系图 er图为了把用户的数据要求清楚 准确地描述出来 系统分析员通常建立一个概念性的数据模型 是一种面向问题的数据模型 描述了从用户角度看到的数据 内容 1 实体 即数据对象 用矩形框表示 2 关系 用连接相关实体的菱形框表示 3 属性 用椭圆形或圆角矩形表示 并用直线把实体或关系与其属性连接起来 2019 12 22 软件工程导论王培丽 53 2 2 6几种图形工具 状态转换图简称为状态图 描绘系统状态及引起系统状态变换的事件来表示系统的行为 反应了状态与事件之间的关系 状态图提供了行为建模机制 状态图描述了系统中某些复杂对象的状态变化 主要有状态 变迁和事件三种描述 2019 12 22 软件工程导论王培丽 54 2 2 6几种图形工具 状态状态是任何可以被观察到的系统行为模式 一个状态代表系统的一种行为模式 状态规定了系统对事件的响应方式 系统对事件的响应可以是做一个 或一系列 动作 也可以只是改变系统本身的状态 还可以既改变状态又做动作 状态图中定义的状态有 初态 终态和中间状态 在一张状态图中只能有一个初态 而终态可以有若干个 事件事件是引起系统做动作或转换状态的控制信息 2019 12 22 软件工程导论王培丽 55 2 2 6几种图形工具 符号 状态变量的名字和值 状态转换 entry 表示进入该状态的动作exit 表示退出本状态的动作do 在本状态下的动作 状态变迁通常是由事件触发的 这时应在状态转换上标出触发转换的事件表达