软件项目范围计划PPT学习教案

1、会计学1 软件项目范围计划软件项目范围计划 业务 需求 用户 需求 功能 需求 系统 需求 非功 能性 需求 质 量 特 性 约束和 假设 软件需求规格 第2页/共42页第1页/共42页 第3页/共42页第2页/共42页 No.Top 10 FactorsAVG 1Inadequate requirements specification4.5 2Changes in requirements4.3 3Shortage of systems engineers4.2 4Shortage of software managers 4.1 5Shortage of qualified projec

2、t managers 4.1 6Shortage of software engineers 3.9 7Fixed - price contract 3.8 8Inadequate communications for system integration 3.8 9Insufficient experience as team3.6 10Shortage of application domain experts 3.6 Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University,

3、 Software Engineering Institute 第4页/共42页第3页/共42页 需求工程的目标是获取高质量的软件需求。 以系统化、条理化、可重复的方法和技术进行与需求相关以系统化、条理化、可重复的方法和技术进行与需求相关 的活动，从而提高需求活动和过程的可管理性，降低需求的活动，从而提高需求活动和过程的可管理性，降低需求 开发和管理的成本。开发和管理的成本。 需求工程分为需求开发和需求管理。 第5页/共42页第4页/共42页 需求工程 需求管理需求开发 需求获取需求分析 需求规格说明需求验证 变更管理 第6页/共42页第5页/共42页 用户要求 扩展需求 基线需求 软件需 求

4、 目的是从宏观上把握用户的具体需求方向和趋势，了解 现有的组织架构、业务流程、软硬件环境、现有运行系 统等具体情况和客观信息。 第7页/共42页第6页/共42页 确定需求计划 确定项目范围 确定调查对象 收集用户需求 确定非功能性需求 和约束条件 需求获取需要从用户提供的大量信息中分析和理解用户 的真正需求(做什么)，而应剔除实现方式(怎么做)。 第8页/共42页第7页/共42页 需求分析是为最终用户所看到的系统建立一个概念模型(逻 辑模型)，是对需求系统地抽象描述。 需求分析的基本任务是分析和综合已收集到的信息，在于 透过现象看本质，找出需求信息之间的内在联系和可能的 矛盾，提炼、分析和仔细

5、审查已收集到的需求信息，找出 真正系统的需求，以确保项目相关人员对需求都有唯一的 理解。 需求分析建立的逻辑模型反应的是业务运作流程，而不是 技术开发流程。 第9页/共42页第8页/共42页 当前系 统 物理模型逻辑模型 目标系 统 物理模型逻辑模型 模型模型 化化 抽象抽象 化化 例化例化具体具体 化化 导出导出 理解需求理解需求表达需求表达需求 第10页/共42页第9页/共42页 需求规格说明书的编制是为了使用户和软件开发者双方对 该软件的初始规定有一个共同的理解，使之成为整个开发 工作的基础。 需求规格说明书是需求工程的最终输出，以文档的形式确 定用户需求和逻辑模型。 1）需求规格是软件

6、设计和实现的基础； 2）需求规格是测试和验收的重要依据； 3）需求规格为软件维护提供重要信心。 第11页/共42页第10页/共42页 一个大系统中的一个元素，那么整 个大系统也包括在规格说明的描述 之中； 6）可行性：规格说明应该包括系 统运行环境； 7）抽象性：规格说明应该是一个 认识模型； 8）开放型：规格说明应该容许不 完备性并允许扩充。 第12页/共42页第11页/共42页 1.引言 2.5 设计限制 1.1 目的 2.6 假设和依赖 1.2 文档约定3. 需求规格 1.3 预期读者 3.1 功能需求 1.4 产品范围 3.2 逻辑模型 1.5 参考文献 3.3 数据字典 2. 项目概

7、述 3.4 性能需求 2.1 项目背景 3.5 安全性需求 2.2 项目目标 3.6 接口需求 2.3 用户类 3.7 其他需求 2.4 运行环境附录 第13页/共42页第12页/共42页 第14页/共42页第13页/共42页 5 需求管理是为有效地控制和管理需求变更等所进行的活动。 需求管理的主要任务就是在开发人员在与提出更改的请求 者协商的基础上，评估需求变更带来的潜在影响及其可能 的成本和费用，然后实施更改，以及有效地管理需求规格 说明书和跟踪更改需求的状态。 第15页/共42页第14页/共42页 8.衡量需求稳定性 9.管理和控制需求基线的过程 10.需求变更控制系统 一个正式的文档，

8、说明如何控 制需求变更 建立变更审批系统 第16页/共42页第15页/共42页 变更申请 需求方 开发方 忽略 选择变 更方式 SCCB评估项目经理自行决定 评估 结果 拒绝接受本次修改下个版本再修改 修改合同相关信息修改相关需求修改相应的项目计划 第17页/共42页第16页/共42页 软件基线产品修改申请单 申请人张三申请日期2010-03-24 项目名称软件项目管理系统 阶段名称系统设计 文件名称RCR-PM-01.doc, RCR-PM-02.doc 修改内容 1）修改测试流程控制：将2个角色，3个渠道流， 改为3个角色，4个渠道流，详见RCR-PM-01.doc 2）增加开发人员技能信

9、息库管理，详见RCR-PM- 02.doc 验证意见 同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更 可以推迟到下一个版本实施 验证人李四验证日期 2010-03-30 SCCB李四，王五，赵六填表人张三 第18页/共42页第17页/共42页 可跟踪信息分类： u需求-源 可跟踪性：与说明该需求的人或文档连接； u需求-理由 可跟踪性：和理由描述连接； u需求-需求 可跟踪性：和依赖于该需求的需求连接； u需求-体系结构 可跟踪性：与实现系统连接； u需求-设计 可跟踪性：与特定组件连接； u需求-界面 可跟踪性：与外部系统界面连接。 第19页/共42页第18页/共42页

10、 uWork packages：WBS的最低层次的可交付成果 u任务分解的过程：将一个项目分解为更多的工作细目 或者子项目，使项目变得更小、更易管理、更易操作 。 u任务分解的结果：WBS（任务分解结构）。 uWBS：面向可交付成果的。 第20页/共42页第19页/共42页 系 统 子系统子系统子系统 模 块 模 块 模 块 模 块 模 块 模 块 模 块 模 块 模 块 第21页/共42页第20页/共42页 WBS的最低层次的可交付成果 工作包应当由唯一主体负责 这一交付成果可以分配给另外一位项目经理进行计划 和执行,或者通过子项目的方式完成 第22页/共42页第21页/共42页 “变化计数

11、器”系统 版本 比较 找出 增删 行 统计 增删行 统计 总行 标记修 改 记录 修改 预 处 理 文 件 比 较 结 果 处 理 增 加 代 码 删 除 代 码 增 加 行 数 删 除 行 数 第23页/共42页第22页/共42页 第24页/共42页第23页/共42页 使用应用领域内标准或半标准的WBS作为模板参考使用。 与类比所参照的WBS不同，模板更具有抽象性，在任务分 解时需根据指导说明来开发项目的WBS。 第25页/共42页第24页/共42页 第26页/共42页第25页/共42页 “变化计数器”系统 文件比较 预处理 增加代码 结果处理 统计总行 标 记 修 改 记 录 修 改 版本

12、比较 找出增删行 统计增删行 删除代码 增加行数 删除行数 第27页/共42页第26页/共42页 “变化计数器”系统 文件比较 预处理 增加代码 结果处理 统计总行 标 记 修 改 记 录 修 改 版本比较 找出增删行 统计增删行 删除代码 增加行数 删除行数 第28页/共42页第27页/共42页 第29页/共42页第28页/共42页 系 统 1子系统2子系统3子系统 1. 2 模 块 1. 3 模 块 1. 1 模 块 2. 2 模 块 3. 3 模 块 2. 1 模 块 2. 3 模 块 3. 1 模 块 3. 2 模 块 第30页/共42页第29页/共42页 WBS任务名称工期开始时间完

13、成时间 1项目计划6 工作日2010年3月8日2010年3月13日 2软件开发44 工作日2010年3月15日2010年5月8日 2.1 需求分析6 工作日2010年3月15日2010年3月20日 2.2 总体设计9 工作日2010年3月22日2010年3月31日 2.3 详细设计9 工作日2010年4月1日2010年4月13日 2.4 应用程序编码18 工作日2010年4月14日2010年5月6日 2.5 驱动程序编码30 工作日2010年3月29日2010年5月6日 2.6 软件测试18 工作日2010年4月14日2010年5月6日 2.7 软件审核2 工作日2010年5月7日2010年5

14、月8日 3机构设计7 工作日2010年3月18日2010年3月25日 4硬件设计49 工作日2010年3月15日2010年5月14日 4.1 硬件前期工作12 工作日2010年3月15日2010年3月27日 4.2 原理图6 工作日2010年3月15日2010年3月20日 4.2.1 原理图设计5 工作日2010年3月15日2010年3月19日 4.2.2 原理图审核1 个工作日2010年3月20日2010年3月20日 4.3 PCB21 工作日2010年3月26日2010年4月21日 4.3.1 PCB画图和封装10 工作日2010年3月29日2010年4月10日 4.3.2 PCB与机构沟

15、通10 工作日2010年3月26日2010年4月8日 4.3.3 BOM表4 工作日2010年3月29日2010年4月1日 4.3.4 BOM器件采购12 工作日2010年4月2日2010年4月17日 4.3.5 PCB制版采购7 工作日2010年4月14日2010年4月21日 4.4 电路板制作10 工作日2010年4月22日2010年5月5日 4.4.1 SMT5 工作日2010年4月22日2010年4月27日 4.4.2 电路板焊接4 工作日2010年4月28日2010年5月4日 4.4.3 电路板测试1 个工作日2010年5月5日2010年5月5日 4.5 软硬件集成4 工作日2010

16、年5月10日2010年5月13日 4.6 产品初期验收1 个工作日2010年5月14日2010年5月14日 第31页/共42页第30页/共42页 第32页/共42页第31页/共42页 规划 需求 设计 编码 测试 提交 u按照生存期分解：u按照产品组成分解： 1.1 招生管理 1.2 分班管理 1.3 学生档案管理 1.4 学生成绩管理 分解标准要统一，不能同时使用两种标准进行分解 第33页/共42页第32页/共42页 第34页/共42页第33页/共42页 7. 每个Work package必须有一个 提交物 8. 定义任务完成的标准 9. 每个WBS必须有利于责任分配 10.可以准备WBS的

17、字典 11.最后与相关人员进行评审 第35页/共42页第34页/共42页 WBS编号： 名称： 主题目标： 描述： 完成的任务： 责任者： 完成的标识： 备注： 第36页/共42页第35页/共42页 第37页/共42页第36页/共42页 F F1 配置管理 F2 故障管理 F3 安全管理 F4 性能管理 F3.2F3.3F3.1F3.4 F4.2F4.3F4.5F4.6F4.7F4.4F4.1 F4.7.1F4.7.2 第38页/共42页第37页/共42页 标识项标识项模块说明模块说明 F1.1获取网络资源数据 F1.2将资源数据存入数据库 F1.3获取网络资源信息 F1.4观察网络资源 F1.4.1依类型分类观察网络资源 F1.4.2依状态分类观察网络资源 F1.5观察逻辑网 F1.6观察资源状态 F1.7修改网络资源的状态 F1.8依条件检验网络使用情况 F1.9显示拓扑图 F1.10建立通道 第39页/共42页第38页/共42页 经过过去几年的发展,家里不断壮大, 无论是时间和金钱上的需