《软件项目计划》PPT课件.ppt

0 软件项目管理 信息科学与工程学院软件工程系崔焕庆 2020 3 26 1 RoadMap 2020 3 26 2 前情回顾 项目立项阶段甲方 招标书 乙方选择 签署合同乙方 项目分析 竞标 签署合同项目章程 确认项目存在的文件 包括对项目的确认 对项目经理的授权和项目目标的概述等 生存期模型 瀑布 V 增量 原型 螺旋 渐近模型 3 第二篇 软件项目计划 2020 3 26 4 RoadMap 5 第2章 范围计划 2020 3 26 6 为什么进行范围计划 做过项目的人可能会有这样的经历 一个项目做了很久 感觉总是做不完 就像是一个无底洞 用户总是有新需求要项目开发来做 就像用户在 漫天要价 而开发方在 就地还钱 实际上 这里涉及一个 范围管理 的概念 项目哪些该做 做到什么程度 哪些不该做 都是由 范围管理 来决定的 缺乏正确的项目范围界定是导致项目失败的主要原因之一 项目管理中最重要也是最难做的就是确定项目范围 2020 3 26 7 开发软件系统最为困难的部分就是准确说明开发什么 弗雷德里克 布鲁克斯 2020 3 26 8 什么是范围管理 1 什么是范围 产生项目产品所包括的所有工作及产生这些产品所用的过程 产品范围界定 产品或服务范围的特征和功能 工作范围界定 项目工作的完成 为的是能交付一个有特殊特征和功能的产品 2 范围管理对项目包括什么和不包括什么的定义与控制过程 用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程 有一个共同的理解 2020 3 26 9 本章要点 一 关于软件需求二 需求管理过程三 编写需求规格的方法四 任务分解定义五 任务分解方法六 任务分解结果的检验七 案例分析 2020 3 26 10 软件需求的重要性 40 60 的问题是在需求分析阶段埋下的隐患 40 的开发总费用是返工开销 70 80 的返工是需求方面的错误导致的 80 的失败项目是需求分析不明确造成的 总之 好的需求管理是项目成功的第一位因素 采用需求管理可以给项目组带来很多的好处 直至项目取得成功 2020 3 26 11 项目失败的原因分析 No Top10Factors 平均值 1 Inadequaterequirementsspecification 4 5 2 Changesinrequirements 4 3 3 Shortageofsystemsengineers 4 2 4 Shortageofsoftwaremanagers 4 1 5 Shortageofqualifiedprojectmanagers 4 1 6 Shortageofsoftwareengineers 3 9 7 Fixed pricecontract 3 8 8 Inadequatecommunicationsforsystemintegration 3 8 9 Insufficientexperienceasteam 3 6 10 Shortageofapplicationdomainexperts 3 6 Scale 5 VerySerious3 Serious1 NoSerious Source Carnegie MellonUniversity SoftwareEngineeringInstitute 2020 3 26 12 什么是软件需求 需求是指用户对软件的功能和性能的要求 就是用户希望软件能做什么事情 完成什么样的功能 达到什么性能 正在构建的系统必须符合的条件或具备的功能 Rational用户解决某一问题或达到某一目标所需的软件功能 系统或系统构件为了满足合同 规约 标准或其他正式实行的文档而必须满足或具备的软件功能 MerlinDorfman RichardH Thayer 2020 3 26 13 软件需求的层次 业务需求 表示组织或客户高层次的目标 业务需求通常来自项目投资人 购买产品的客户 实际用户的管理者 市场营销部门或产品策划部门 业务需求描述了组织为什么要开发一个系统 即组织希望达到的目标 使用前景和范围文档来记录业务需求 这份文档有时也被称作项目轮廓图或市场需求文档 2020 3 26 14 软件需求的层次 业务需求 用户需求 描述的是用户的目标 或用户要求系统必须能完成的任务 用例 场景描述和事件 响应表都是表达用户需求的有效途径 也就是说用户需求描述了用户能使用系统来做些什么 2020 3 26 15 软件需求的层次 业务需求 用户需求 功能需求 规定开发人员必须在产品中实现的软件功能 用户利用这些功能来完成任务 满足业务需求 功能需求有时也被称作行为需求 因为习惯上总是用 应该 对其进行描述 系统应该发送电子邮件来通知用户已接受其预定 功能需求描述是开发人员需要实现什么 三个层次 2020 3 26 16 软件需求的层次 业务需求 用户需求 功能需求 系统需求 用于描述包含多个子系统的产品 即系统 的顶级需求 系统可以只包含软件系统 也可以既包含软件又包含硬件子系统 人也可以是系统的一部分 因此某些系统功能可能要由人来承担 2020 3 26 17 软件需求的层次 业务需求 用户需求 功能需求 非功能性需求 系统需求 对产品的功能描述作了补充 它从不同方面描述了产品的各种特性 这些特性包括可用性 可移植性 完整性 效率和健壮性 它们对用户或开发人员都很重要 其他的非功能需求包括系统与外部世界的外部界面 以及对设计与实现的约束 2020 3 26 18 软件需求的层次 业务需求 用户需求 功能需求 非功能性需求 约束和假设 系统需求 限制了开发人员设计和构建系统时的选择范围 2020 3 26 19 软件需求的层次 业务需求 用户需求 功能需求 软件需求规格Softwarerequirementspecification 非功能性需求 约束和假设 系统需求 2020 3 26 20 软件需求的层次 2020 3 26 21 本章要点 一 关于软件需求二 需求管理过程三 编写需求规格的方法四 任务分解定义五 任务分解方法六 任务分解结果的检验七 案例分析 2020 3 26 22 需求工程 需求工程是应用已证实有效的技术 方法进行需求分析 确定客户需求 帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科 2020 3 26 23 需求获取是通过各种途径获取用户的需求信息 原始材料 产生 用户需求说明书 需求获取 2020 3 26 24 需求获取 用户要求 基线需求 软件需求 主要任务 是和用户方的领导层 业务层人员访谈把握用户的具体需求方向和趋势 了解现有的组织架构 业务流程 硬件环境 软件环境 现有系统的运行状况等信息 2020 3 26 25 需求获取方法 开始前 做好准备 写出访谈提纲 进行中 要注意聆听和引导 结束后 要写感谢信 旁敲侧击的方式 复述 复述 复述 聆听不要指导 两个人去访谈 让被访者上司安排 不要问太多 2020 3 26 26 需求获取方法 头脑风暴法 集思广益会 德尔菲技术 1 根据问题的特点 选择和邀请相关专家 2 将与问题有关的信息提供给专家 请他们各自独立发表自己的意见 并写成书面材料 3 管理者收集并综合专家们的意见后 将综合意见反馈给各位专家 请他们再次发表意见 如果分歧很大 可以开会集中讨论 否则 管理者分头与专家联络 4 如此反复多次 最后形成代表专家组意见的方案 2020 3 26 27 需求获取方法 其他方法 需求研讨会用例模型角色扮演原型法Q A邮件提问电视电话会议访谈 2020 3 26 28 需求的分析 整理和确认 目标 要知道每个需求的 为什么 从 如何实现 实现什么 分析隐含需求 需求跟踪矩阵 2020 3 26 29 需求获取注意问题 1 识别真正的客户2 正确理解客户的需求3 具备较强的忍耐力和清晰的思维4 使用符合客户语言习惯的表达5 提供需求开发评估报告6 尊重开发人员和客户的意见 妥善解决矛盾7 划分需求的优先级8 说服和教育客户 2020 3 26 30 需求分析 需求阶段 设计阶段 编码阶段 开发测试 验收阶段 运行阶段 1x 3x 6x 10 x 15x 40 x 30 x 70 x 1000 x 2020 3 26 31 需求分析模型 2020 3 26 32 需求分析活动 1 以图形表示的方式描述系统的整体结构 包括系统的边界与接口 2 向用户提供可视化的界面 用户可以对需求做出自己的评价 3 以模型描述系统的功能项 数据实体 外部实体 实体间的关系 实体之间的状态转换 2020 3 26 33 处理需求不明确问题的方法 1 让用户参与开发 2 开发用户原型界面 3 需求讨论会议 4 强化需求分析与评审 2020 3 26 34 需求规格 需求分析工作完成的一个基本标志是形成了一份完整的 规范的需求规格说明书 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解 使之成为整个开发工作的基础 2020 3 26 35 软件需求规格说明的原则 从现实中分离功能 即描述要 做什么 而不是 怎样实现 采用一定的规格说明语言 如果被开发软件只是一个大系统中的一个元素 那么整个大系统也包括在规格说明的描述之中 规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩充 SRS实例 2020 3 26 36 需求验证内容 1 需求的正确性2 需求的一致性3 需求的完整性4 需求的可行性5 需求的必要性6 需求的可检验性7 需求的可跟踪性8 最后签字 与其他软件需求或高层需求不相矛盾 验证是否所有可能的状态 状态变化 转入 产品和约束都在需求中描述 验证每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施 验证需求是否是用户需要的 验证是否能写出测试案例来满足需求 如用演示 检测等来确定产品是否确实按需求实现了 每项需求以一种结构化的 粒度化的方式编写并单独标明 避免大段大段的叙述 2020 3 26 37 需求变更管理 1 确定变更控制过程2 建立软件变更委员会3 进行变更影响分析4 跟踪变更影响的产品5 建立基准和控制版本6 维护变更的历史记录7 跟踪每项需求的状态8 衡量需求稳定性 选择 分析 决策 项目进度 资源 工作量 项目范围 对其他需求的影响 确定 已实现 暂缓 新增 变更 记录需求基线的数量和每周或每月的变更 2020 3 26 38 变更申请 需求方 开发方 忽略 选择变更方式 SCCB评估 项目经理自行决定 根据评估结果 拒绝 接受本次修改 下个版本再修改 修改合同相关信息 修改相关需求 修改相应的项目计划 需求变更管理过程 2020 3 26 39 本章要点 一 关于软件需求二 需求管理过程三 编写需求规格的方法四 任务分解定义五 任务分解方法六 任务分解结果的检验七 案例分析 2020 3 26 40 编写需求规格的方法 原型方法结构化分析法面向对象的用例分析法功能列表法关联模型行为模型数据模型结构化模型面向对象模型其他方法 2020 3 26 41 编写需求规格实例 关联模型 ATM系统 2020 3 26 42 编写需求规格实例 行为模型 预订机票 2020 3 26 43 编写需求规格实例 状态机模型 微波炉 2020 3 26 44 编写需求规格的思维方法 六顶思考帽 2020 3 26 45 本章要点 一 关于软件需求二 需求管理过程三 编写需求规格的方法四 任务分解定义五 任务分解方法六 任务分解结果的检验七 案例分析 2020 3 26 46 WBS WorkBreakdownStructure 任务分解的过程将一个项目分解为更多的工作细目或者子项目 使项目变得更小 更易管理 更易操作 任务分解的结果WBS 任务分解结构 WBS面向可交付成果的 Workpackages 工作包 WBS的最低层次的可交付成果代表项目经理监督和控制项目进度的最低层工作 工作包也可以指代说明和报告 一件特殊的硬件设备 如 特定的服务器 2020 3 26 47 WBS WorkBreakdownStructure WBS第1层 WBS第2层 工作包 2020 3 26 48 WBS的清单类型 1 变化计数器1 1比较两个版本的程序1 1 1预处理1 1 2文件比较1 1 3结果处理1 2找出修改后的程序中增加和删除的代码行1 2 1找出增加的代码行1 2 2找出删除的代码行1 3统计修改后的程序中增加和删除的代码行数1 3 1统计增加代码行数1 3 2统计删除代码行数1 4统计总的代码行数1 5设定标记以指示修改的次数1 6在程序的头部增加修改纪录 2020 3 26 49 WBS的图表类型 飞行系统 飞行器 支持设备 设施 测试与评价 项目管理 培训 数据 系统工程管理 支持性项目管理活动 设备培训 设施培训 服务培训 技术命令 工程数据 管理数据 实物模型 运作测试 开发测试 基地大楼 维护设施 组织层次的 中间层次的 补给站层次 机身 引擎 通信系统 导航系统 消防系统 2020 3 26 50 WBS的图表类型 家庭装修 设施 结构 墙体 地板 门窗 厨房 厕所 洗浴 空调 照明 通讯 洁具 燃具 风机 垃圾 橱柜 水池 上水管 下水道 龙头阀门 过滤网 2020 3 26 51 WBS的图表类型 软件产品发行版本5 0 项目管理 项目需求 详细设计 构建 整合测试 管理 会议 规划 培训资料 用户文档 软件 培训资料 用户文件 软件 培训资料 用户文件 软件 培训资料 用户文件 软件 2020 3 26 52 WBS的图表类型 文艺演出 节目 剧务 后勤 经营 策划 编导 排练 表演 化妆 道具 灯光 音响 交通 就餐 住宿 安全 广告 销售 票务 财务 2020 3 26 53 任务分解步骤 确认并分解项目的组成要素确定分解标准确定分解是否详细确定项目交付成果验证分解的正确性 建立编号 2020 3 26 54 分解标准 生存期功能组成项目的组织单位 2020 3 26 55 分解标准应统一 学生管理按照生命期分解规划需求设计编码测试提交按照产品组成分解1 1招生管理1 2分班管理1 3学生档案管理1 4学生成绩管理 2020 3 26 56 分解标准应统一 不能同时使用两种标准进行分解招生管理分班管理学生档案管理学生成绩管理规划需求设计编码测试提交 2020 3 26 57 WBS字典 描述和定义WBS中的元素 以及其他的计划信息 如预算 工期 责任人等 2020 3 26 58 WBS字典 2020 3 26 59 本章要点 一 关于软件需求二 需求管理过程三 编写需求规格的方法四 任务分解定义五 任务分解方法六 任务分解结果的检验七 案例分析 2020 3 26 60 任务分解方法 使用指南类比法自上而下自下而上心智图法 2020 3 26 61 使用指南 一些组织通常都会为特定项目制订WBS的格式和内容 例如 美国国防部 DOD 要求项目承包方基于DOD提供的WBS建议准备WBS 并据此审查承包方的成本建议和基于WBS的自身内部成本估算 很多组织提供开发WBS的准则和模板 以及过去项目的WBS样例 PMI开发了一个WBS实践标准为制作和应用WBS提供准则和指南 其中还包含了WBS样例库 涵盖了很多行业领域各种类型的项目 如 网页设计 电信 服务业外包 软件开发等 PMI会员免费下载 WWW PMI ORG 非会员需购买 WBS模板 2020 3 26 62 自上而下与自下而上 自上而下法是创建WBS的传统方法 即 从项目最大项开始 将它们分解成下一级的项 这个过程实际上就是对工作的进一步细分 该方法适用于对整个项目有宏观技术把握的项目经理使用 自下而上法项目组成员首先识别出尽可能多的与项目有关的具体任务 随后 将这些具体的任务集中分类并组织成概要任务或WBS中的较高层次 该方法通常比较耗时 项目经理通常运用该方法处理全新的系统 2020 3 26 63 心智图法 MindMapping 心智图法 又称思维导图 是一种从核心思想向外辐射出分支的方法 用以组织思路和想法 该方法可以让人们以非线性方式构想 用形象的无结构化的方法定义WBS的项 随后可以直接将信息转化成图表格式 2020 3 26 64 心智图法 MindMapping 1 首先在纸的中心画一个彩图 既明确主题 且刺激创意性思维 2 多用图画 醒目 利于记忆 3 以粗体字书写 这样更清晰 便于阅读 便于反馈 4 字词以线相连 这样形成一个基本框架结构 5 多用单个的词语 这样每个词语间连接起来更自如 联想空间更大 更自由 更多变 6 多用各种颜色 同样是为了醒目 强化记忆 7 大脑应尽可能地保持 自由 这样可以充分利用其创造性 任何关于事物应朝何处发展及是否应包括在思维导图中等方面的 思维 都会直接使大脑创造性思维减速 2020 3 26 65 心智图法 MindMapping 2020 3 26 66 心智图法 MindMa