软件工程实践.pptVIP

人员角色以及职责 人员角色以及职责表 填充框架性用例人员职责表 需求分析 分析活动的参与者： 需求工程师 软件设计师 项目软件经理 用户（客户） 系统工程师 质量保证工程师 需求分析 分析活动的进入准则 领域概念模型和用例模型已经基本确定 参与分析活动的人员已经具备必需的技术及管理技能 所有技术性及管理性工作事项的职责已明确到个人 分析活动的输入 需求分析活动是在需求获取活动的工作成果的基础上展开的，其输入与获取活动的输出相同。在所有输入中，领域概念模型和用例模型最为重要。 需求分析 分析活动的步骤 分析需求的质量属性 确定各个需求条目的优先级，选取优先分析的用例 精化领域概念模型 用例分析。每个分析依次进行以下工作： 提取分析类 利用UML交互图表示用例的交互动作序列 基于领域概念模型和交互图构造分析类图 构造状态图、活动图 构造快速原型 评审分析模型 分析需求的质量属性 需求的质量属性因项目而已，可基于以下属性列表适当裁剪或者扩充。 正确性 一致性 精确性 完全性 无冗余 可行性 稳定性 可测试性 可修改性 用户价值 实现风险 确定需求优先级 要完成的3项任务 为每个需求项确定优先级 安排待分析用例的优先次序 根据分析优先级的结论调整工作计划 步骤： 确定需求优先级 编排用例分析的优先次序 调整工作计划 精化领域概念模型 本步骤的目标：提取跨越多个用例的全局性、关键性的公共概念，清晰表达这些概念的内涵及其相互关系，为后续分析活动奠定公共的概念基础。 具体方法： 在需求获取活动所得到的领域概念模型的基础上，结合用例描述和业务术语字典，提取多个用例中相同或相似的概念，对其统一命名，标识其中蕴藏的属性，研究它们的关系。 必要时，记录用例模型与此类图之间的追踪关系。 提取分析类 业务逻辑处理主要由以下三种分析类协同完成： 边界类：负责目标软件系统与外部执行者之间的交互。 界面控制 外部接口 环境隔离 控制类：负责协调、控制其他类共同完成用例规定的功能或行为。 实体类：负责保存目标软件系统中具有持久意义的信息项并向其他类提供信息访问操作。 构造交互图 典型的用例功能的完成过程基本上遵循如下过程框架： 主动执行者向边界类发出命令。 边界类仅完成必要的输入信息解析的工作，将命令以控制类可识别的内部表示形式传向控制类。 控制类为了完成命令所要求的业务逻辑处理，可能向实体类发送消息以获取必要的信息项，也可能向实体类发送消息以持久保存业务逻辑处理的结果。 控制类将业务逻辑处理的结果通知边界类。 边界类针对处理结果进行必要的从内部表示形式向外部表示形式的变换，再将结果传递给被动执行者。 布局规则下的典型顺序图 构造分析类 具体方法： 比较并研究领域概念模型和交互图，以领域概念模型为基础初创分析类图 根据消息确定分析类的职责。 根据消息传递确定分析类之间的连接 根据交互图确定分析类的属性 整理分析类图 构造活动图 需求分析阶段的活动图主要用于描述： 软件系统与外部实体共同参与的业务处理流程；多对象协同的单个用例中的处理流程，或者多个用例联合起来形成的处理流程。 构建快速原型 具体过程： 分析与规划 设计与实现 检查与评审 改进 评审分析模型 评审方法与需求获取阶段的评审方法的差异： 分析模型评审的主要关注点除模型的一致性、精确性和完全性外，还应包括分析模型相对于用例模型的一致性，以及分析模型面向软件设计师的可理解性、详略得当行。 相对于用例模型，基于分析模型更易构造可实际运行的快速原型。 充分利用分析过程中记录的分析决策，判断这些决策的合理性，基于这些决策来理解、评审分析模型。 用户和业务专家在分析模型评审中的作用相对弱化，因为他们可能难于理解分析模型中的技术性内容。 需求分析 分析活动的输出包括： 分析模型 需求追踪表 需求优先级分析结论 可行性分析结论 分析决策 新版工作计划 分析活动的出口准则： 需求分析目标业已到达，并且其输出已经通过评审 需求分析 分析活动小结 需求规格化 需求规格说明书的主要内容： 系统概述 文档概述 实体类 系统简述 软件产品描述 用户特征 设计和实现约束 假设与依赖 参考文献 功能性需求 非功能性需求 界面需求 接口定义 需求验收标准 需求来源表 需求规格化 主要参与者： 文档支持工程师 需求工程师 测试工程师 质量保证工程师 配置管理工程师 进入准则： 需求获取及分析活动的输出已就绪 需求规格说明书的文档模板已就绪 文档支持工程师已具备撰写需求规格说明书所必需的技术及写作技能 需求规格化 主要工作步骤： 按照需求规格说明书模板撰写需求规格说明 整理需求追踪关系 将需求规格说明书置于配置管理的控制之下 出口准则： 需求规格说明书已撰写完成，并且通过了参与需求获取和分析活动的所有