需求工程第5章确定项目的前景和范围.ppt

5.5.2 使用活动图进行业务过程分析 获取业务过程描述后，按如下步骤，使用活动图进行业务过程分析： 确定活动图的上下文环境 界定业务流程的处理界限 分析业务流程中的主要处理步骤 的行为 分析业务流程中的主要数据流 识别参与者，进行职责分配，将业务流程的处理步骤划分到不同的泳道，并将处理步骤和数据流的传递组织起来，建立活动图 添加活动图的详细信息，完善活动图描述。 5.5.2 使用活动图进行业务过程分析 尤其要注意下列工作： 分析不同动作之间的协同是同步还是异步，同步使用控制流和数据流，异步使用信号与事件。 分析是否存在业务过程失败场景，添加流终结节点。 分析是否存在较为复杂的行为，为其建立活动。 分析业务过程中是否有异常，补充异常处理。 始终要检查令牌平衡，修正不平衡的节点。 案例分析 行为识别 对象流 商品信息 预付款项 物品 派送状态 账款 协同点 细化点 中断 分层 外置 主要内容 确定项目前景和范围的活动 问题分析 目标分析 业务过程分析 定义系统边界 项目前景和范围文档 定义系统边界 系统边界是系统与环境互动的界限。 定义系统边界可以明确系统需要满足的与外界的交互行为，从宏观上界定了系统的功能概要。 系统边界是后续需求分析活动的起始模型，后续需求分析是逐一细化系统边界中的对外交互行为的活动。 定义系统边界 问题分析的系统边界定义 将每个问题的解决方案边界合并起来就是系统的边界定义。 目标分析的系统边界定义 从目标模型中抽取系统的边界定义。 分配主体包括将要构建的系统和系统环境的底层目标，这表明系统与环境存在互动，这就是系统边界定义要考虑的目标，称边界目标 分析边界目标所关注的数据对象，可以得到系统与环境的输入、输出流，并据此建立结构化的系统边界定义——上下文图。 分析边界目标所覆盖的场景和操纵的操作 （任务），可以得到系统用例，据此建立面向对象的系统边界定义——系统用例图。 定义系统边界 业务过程分析的系统边界定义 依据其动作和对象流完善边界定义。 活动图的每一个动作都可能是一个用例，据此完善面向对象方法的系统用例图。 活动图中的每一个对象流都可能是一个系统与环境的输入、输出数据流，据此完善结构化方法的上下文图。 系统用例图示例 上下文图示例 图5－5、自助餐厅订餐系统上下文图 自助餐厅在线订餐系统 顾客 工资系统 菜单管理人 送餐人员 自助餐厅工作人员 送餐请求 从工资中扣除餐费的请求 付款要求 菜单内容 送餐请求 付款请求 食物订单 菜单 食物订单 食物订购信息 注册从工资中扣除餐费 自助餐厅库存系统 食物订单 可提供的食物信息 从工资中扣除餐费的响应 更新食物状态 主要内容 确定项目前景和范围的活动 问题分析 目标分析 业务过程分析 定义系统边界 项目前景和范围文档 5.7 前景和范围文档 业务需求、高层次解决方案和系统特性都应该被定义到项目前景与范围文档之中 前景与范围文档主要由需求工程师来完成，但文档的负责人一般是项目的投资负责人、执行主管或其他类似角色 文档中记录的应该是清晰、明确的业务需求、高层次解决方案和系统特性 项目合约或抽象的业务用例文档也可以实现类似目的 5.7 前景和范围文档——模板 5.7前景和项目文档 业务需求 描述新系统将带给投资人、购买者、用户的利益，说明项目的最终目标。 应用背景：描述原有的应用状况，新系统开发的动机。 业务机遇： 业务目标与成功标准： 业务风险 5.7前景和项目文档 项目前景 前景概述 主要特性 假设与依赖 项目范围 第一版范围 后续版本范围 限制与排除 5.7前景和项目文档 项目环境 操作环境 涉众 项目属性 5.7 前景和范围文档—— 示例 A vision and scope document RUP VS Document Template And an example 实例分析 在公司内部，为确定项目的前景和范围，一般通过用户开会，进行摸底。由于公司的用户一般都是非计算机专业出生，一般对于项目的前景和范围，主要从实际工作出发，提出构想和思路，但是有个明显的问题是，有些构想太过理想化，有些思路又太过细节。 面临最大的挑战就是：由于公司业务的快速变更和快速拓展，公司内部员工提出的需求，比较难落到实处，太虚的目标都比较大，细节的需求又太细。 所以，我们的项目需求收集人员，不仅要能熟悉业务，而且要懂得归纳，懂得演绎，确实存在不少困难。 思考题 你被任命为替换学生财务资助项目的项目经理。你想开发一个工作陈述来定义范围并降低范围蔓延的风险。 财务资助部门的主管坚持要你15个月、600 000美元的预算内替换他现有的系统就可以了。他说这就是你需要知道的全部，不需要浪费时间开发一个工作陈述了。 省略工作陈述的风险是什么？你将