软件工程

软件工程 第11章分析概念和原则

第11章分析概念和原则 11.1需求分析 11.2软件的需求诱导 11.2.1 过程的启动 11.2.2 便利的应用规约技术 11.2.3 质量功能部署 11.2.4 use-case

第11章分析概念和原则 11.3分析原则 11.3.1 信息域 11.3.2 建模 11.3.3 划分 11.3.4 要素视图和实现视图 11.4软件原型实现 11.4.1 选择原型实现方法 11.4.2 原型方法和工具

第11章分析概念和原则 11.5 规约 11.5.1 规约原则 11.5.2 表示 11.5.3 软件需求规约 11.6规约评审 11.7小结

需求分析任务: • 发现 • 求精 • 建模 • 规约需求工程是系统地使用已被证明的原理、技术、语言和工具去处理价格有效的分析、文档以及用户需要的系统的外部行为规约的不断演化。

11.1 需求分析 需求分析是种软件工程活动在系统级软件分配和软件设计间起桥梁作用系统工程软件需求分析软件设计

软件需求分析5个工作阶段： • 问题识别 • 评估和方案综合 • 建模 • 规约 • 评审

11.2 软件的需求诱导 • 软件需求分析中的相互通信总是要在两方或多方间进行

11.2.1 过程的启动 • 客户和开发者之间最常用的交流方式以及开始相互通信过程的技术是进行预备会议或访谈。 • 必须启动通信活动，分析员可从询问一组语境无关的问题开始，语境无关的问题就是，一组将导致对问题、需要解决方案的人员、希望的解决方案的性质以及第一次遭遇的效率等的基本理解的问题。第一组语境无关的问题关注于客户、整体目标和收益。

典型FAST—11.2.2便利的应用规约技术方法： • 在中立的地点举行会议 • 建立准备和参与会议的规则 • 建议一个足够正式的议程而又是足够非正式 • 一个“协调者”控制会议 • 使用一种“定义机制”(工作表、图表等) • 目标是标识问题、方案的要素、商议的方法、解决方案需求

11.2.3 质量功能部署 • 质量功能部署(QFD)是一种质量管理技术，它将客户的需要翻译为软件的技术需求。QFD “集中于最大限度地让客户满意”。 QFD强调理解什么是对客户有价值的，然后在整个工程活动中部署这些价值。

11.2.3质量功能部署 质量功能部署(QFD)标识三类需求： • 正常的需求 • 期望的需求 • 兴奋的需求

11.2.4 use-case 当需求作为非正式会议、FAST或QFD的一部分而收集之后，软件工程师可创建一组标识一串待构造系统的使用场景。这些场景被称为：use-case，它提供了系统将被如何使用的描述。控制软件的4种交互模式（角色）：编程模式(编程员)、测试模式(测试员)、监控模式(监控员)、纠错模式(纠错员) 通常，一个use-case只简单地是一段撰写的叙述，描述某参与者在和系统交互时的角色。

11.3 分析原则 • 必须表示和理解问题的信息域 • 必须定义软件将完成的功能 • 必须表示软件的行为(作为外部事件的结果) • 必须划分描述信息、功能和行为的模型 • 分析过程应该从要素信息移向细节实现

针对“需求工程”的指导性原则： • 建立模型前先理解问题。 • 开发使用户了解人机交互的原型 • 记录每个需求的起源及原因 • 使用多个需求视图 • 给需求赋予优先级 • 努力删除歧义性

11.3.1 信息域 信息域包含三个数据和控制视图：信息内容和关系（数据模型）：表示个体数据和控制对象，它们构成了某个更大的被该软件变换的信息集合。信息流：表示数据和控制在系统中流动时变化的方式。信息结构：表示各种数据和控制项的内部组织。

11.3.2 建模 创建系统的模型: 功能模型行为模型输入处理输出 • ｛

11.3.3 划分 本质上:划分将问题分解为其构成成分概念上:我们建立信息或功能的层次表示，然后划分最上层的元素，通过在层次上垂直向下移动而暴露更多的细节或在层次上水平移动而分解问题。

11.3.3 划分 • 在层次上垂直向下移动而显露更多的细节 • 在层次上水平移动而分解问题

11.3.4 要素视图和实现视图 • 软件需求的基本视图给出了将要完成的功能和将要处理的信息，而不管实现细节。 • 软件需求的实现视图给出了处理功能和信息结构的现实世界表示。 • 软件需求分析应该着重于软件将完成什么，而不是处理将如何实现

11.4 软件原型实现 11.4.1选择原型实现方法原型范型：封闭结束――丢弃型原型实现开放结束――演化型原型实现

原型实现的候选因素可被定义： • 软件应用领域 • 软件应用复杂性 • 客户特征 • 项目特征

客户和原型交互信息的两个基本点： • 客户资源被用于原型评估和精化 • 客户能够以即时的方式作出需求决策

建议原型的实现方法

11.4.2 原型实现方法和工具 三个类属的方法和工具类： • 第四代技术 • 可复用软件构件 • 形式化规约和原型实现环境

11.5 规约 11.5.1 规约原则 • 分离功能性和实现 • 开发一个系统的行为模型-- 包含了系统对各种数据和功能的反应 • 通过刻画其他系统构件和软件交互的方式，建立软件操作的语境

11.5.1 规约原则 4.定义系统运作的环境并指明“一组高度缠绕在一起的代理如何对环境中由其他代理产生的刺激（对象的变化）作出反应” 5.创建认知模型而不是设计或实现模型 6.认识“规约必定是不完整的和可增加的” 7.建立规约的内容和结构，并使得它能适应未来的变化

11.5.2 表示 指导原则： • 表示格式和内容应该和问题相关 • 包含在规约中的信息应该是嵌套的 • 图和其他符号应该在数量上有所限制，并在使用上一致 • 表示应该是可修订的

11.5.3 软件需求规约 软件需求规约的候选格式 • 引言 • 信息描述 -- 功能描述，行为描述 • 确认标准 -- 确认标准的规约是对其他需求的隐式评审 • 参考书目和附录

11.6 规约评审 软件需求规约(和/或原型)的复审是由软件开发者和客户一起进行的，因为规约构成了设计和以后的软件工程活动的基础，在进行复审时必须给予特别的重视。

11.7 小结 需求分析必须关注问题的： • 信息 • 功能 • 行为域

11.7 小结 分析后的实现方法： • 创建模型 • 划分问题 • 描述需求要素 • 表示以后的实现细节

11.7 小结 • 需求分析是软件工程过程的第一步骤，它被精化为具体的规约，它是后面所有软件设计活动的基础。 • 软件需求规约作为分析的结果而被开发

软 件 工 程

软 件 工 程

Presentation Transcript

软件工程

软件工程