软件项目管理2016软件本科.ppt

软件项目管理 徐长青 SoftwareProjectmanagement 使用的开发工具 配置管理 MicrosoftVisualSourceSafe VSS 微软Windows平台下的一个小型软件配置管理工具 项目管理 MicrosoftProject 微软Windows平台下国际通用的项目管理软件 教材及参考资料 选用教材PANKAJJALOTE CMMinPractice ProcessesforExecutingSoftwareProjectsatInfosys 高等教育出版社 2000 主要参考书M C Paulk CapabilityMaturityModelforSoftware SEI 91 TR 24 1991 PankajJalote SoftwareProjectManagementinPractice 2002 3 IT项目管理 美 凯西 施瓦尔贝 KathySchwalbe 2015 思考 你是否参加过软件项目的开发 你是否组织过软件项目的开发 有哪些印象深刻的成功和失败案例 你认为软件开发中最具挑战性的问题是什么 你认为自己能否胜任以下职位 程序员 设计师 项目经理 开发顾问你希望将来在IT企业中充当什么角色 如何达成 1 1 软件开发与软件项目管理1 2 CMM简介1 3 INFOSYS公司的项目管理实践 第一章绪论 1 软件项目管理的重要性2 软件危机的提出3 世界软件产业发展现状及中国软件业的差距 1 1软件开发与软件项目管理 为何需要软件项目管理 软件的定义 是使计算机能够工作的指令集合和相应的数据结构和文档 是一种产品 将计算机的硬件能力发挥出来的一种工具 是传递信息的一种工具 对信息的处理手段 1 1 1软件项目管理的重要性 软件的特征 软件是一种逻辑元素 而不是物理元素 软件是开发出来的 而不是用传统的方法制造出来的 软件不会被用坏 一般产品的失败概率都遵循浴盆曲线 工业界已经是标准化装配时代 但软件还是定制时代 创新性和人为因素更高 1 1 1软件项目管理的重要性 项目的定义所谓项目 就是为创建某一独特产品或服务或者成果 在一定的环境和约束条件下进行的临时性的努力即它是利用有限的资源 在有限的时间内为特定客户完成特定目标的一次性工作 1 1 1软件项目管理的重要性 管理管理是通过利用已有的和可以争取到的各种资源 如人 财 物 技术等 以最少的投入获得最大的产出完成某种任务或达到某个目标的软活动 任务有 发现问题 拟定方案 作出决策管理有三个层次 高层 战略级 中层 策略级 基层 执行级 组织组织是由人和其它资源组成 为达到一个目的的集合或系统 管理是组织的任务 管理为组织服务 确保组织达到预期目标 1 1 1软件项目管理的重要性 项目管理一定的主体 为了实现其目标 综合运用专门的知识 技能 工具和方法 对执行中的项目周期的各阶段工作进行计划 组织 协调 控制 以满足甚至超越项目干系人的需求和期望 项目干系人参与项目和受项目影响的人 包括项目发起人 项目组 支持人员 客户 最终用户 供应商 项目对手 项目的核心知识是范围 时间 成本和质量 辅助知识是人力资源管理 风险管理和采购管理 1 1 1软件项目管理的重要性 软件项目管理是为了使软件项目能够按照预定的成本 进度 质量顺利完成 而对人员 People 产品 Product 过程 Process 和项目 Project 进行分析和管理的活动 软件项目管理的对象是软件工程项目 它所涉及的范围覆盖了整个软件工程过程 为使软件项目开发获得成功 关键问题是必须对软件项目的工作范围 可能风险 需要资源 人 硬件 软件 要实现的任务 经历的里程碑 花费工作量 成本 进度安排等做到心中有数 1 1 1软件项目管理的重要性 软件开发是一个高风险的过程软件过程的管理是软件成功的关键职业的发展方向 软件企业的生存的重要性 1 1 1软件项目管理的重要性 软件危机 软件在开发和维护过程中遇到的矛盾与问题 1 1 2软件危机的提出 软件危机 的主要原因用户不易准确描述对软件的需求 经常存在二义性 遗漏甚至错误 1 1 2软件危机的提出 软件危机 的主要原因大型软件往往需要成百上千人的合作 由于软件系统结构复杂 如何有效组织管理 充分发挥团队作用就成为软件开发成功的关键 1 1 2软件危机的提出 软件危机 的主要原因缺乏有效的软件开发方法和工具的支持 过分依靠程序设计在开发中的技巧和创造性 加剧了软件产品的个性化 开发过程没有统一 规范的方法论指导 文档资料不齐全 1 1 2软件危机的提出 软件危机 的主要原因缺乏软件开发经验及相关数据积累 无法准确估计经费和进度 导致经费严重超支 完成期限一拖再拖 忽视测试阶段的工作 提交的产品质量差 1 1 2软件危机的提出 软件项目失败的案例 1999 10月 美国NASA火箭气象卫星失踪 耗资1 25亿美元 软件的错误 英制和公制的转换问题导致 1963 1966美国IBM360机器的操作系统 5000人年的工作量 1000多人进行开发 100万行代码 新版本是在老版本中找出1000个以上的错误之后修正开发 当时的情况很不好 主要负责人Brooks把他们当时比作陷在泥潭的困兽 越挣扎越深 人月神话 软件项目失败案例 1999年8月 在美国的一个大型的商业高速数据网络里 软件的缺陷影响了7000多个商业用户 时间长达8天 1998年4月 美国的一个重要数据通讯网络出现24小时的故障 使大部分美国的信用卡业务受到影响 受影响的还有美国的一些大银行 零售商和政府的数据系统 也是软件故障 1997年8月 美国一家最主要的信用卡报告公司的新网站开启2天就关闭了 主要是查询自己的信用卡使用情况 但看到的是别人的账单 而不是自己的 软件项目失败案例 逻辑产品 不同于物理产品复杂性高逻辑产品 逻辑复杂性 远高于硬件复杂性软件的复杂性随规模呈指数级上升规模大应用扩大 代码量仍在不断膨胀影响软件生产率和质量的因素比较复杂人员的能力和水平团队合作缺乏有效 系统原理 原则 方法和工具的指导和辅助 产生软件危机的根源 总结 美国印度爱尔兰 1 1 3世界软件产业发展现状及中国软件业差距 与印度的比较与反思 1 1 3世界软件产业发展现状及中国软件业差距 2009年 我国软件收入去年已经达到人民币7573亿元 印度700到800亿美元 算下来相当于人民币6000亿左右 从这个角度说中国已经超越印度 陈冲 中国软件行业协会理事长 与印度的比较与反思 1 1 3世界软件产业发展现状及中国软件业差距 1 1 3世界软件产业发展现状及中国软件业差距 与印度的比较与反思 1 1 3世界软件产业发展现状及中国软件业差距 世界软件外包介绍 1 1 软件开发与软件项目管理1 2 CMM软件能力成熟度模型1 3 INFOSYS公司的项目管理实践 第一章绪论 1 CMM简介2 CMM的成熟度级别3 不同级别的KPA4 CMM的评估方法 1 2软件能力成熟度模型 1 2软件能力成熟度模型 CMM CapabilityMaturityModelforSoftware 软件能力成熟度模型是一种描述有效软件过程的关键元素的框架 CMM描述一条从无序的不成熟的过程到成熟的 有纪律的过程的进化的改进途径 CMM体系描述了在不同成熟度级别下的软件过程的关键因素 CMM包括对软件开发和维护进行策划 工程化和管理的实践 遵循这些关键实践 就能改进组织在实现有关成本 进度 功能和产品质量等目标上的能力 1 2 1软件能力成熟度模型简介 SEI给CMM下的定义是 对于软件组织在定义 实现 度量 控制和改善其软件过程的进程中各个发展阶段的描述 CMM模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题 从而为选择过程改进战略提供指南 CMM包括5个等级 共计18个过程域 52个目标 300多个关键实践 CMM的起源与发展 CMM的起源 软件危机 1986 SEI CMU的软件工程研究所 正式着手这项工作 1987年9月 发布 能力成熟度框架 和 成熟度问卷 1991 8CMM1 0 1993 CMM1 1 CMM I 1 2 1软件能力成熟度模型简介 CapabilityMaturityModelIntegration 1999年7月6日 由IBM和清华同方合资成立的北京鼎新信息系统开发有限公司 在国内首次通过CMM2级 2000年左右 全球60多家CMM5级的企业 印度占了40个 国内当时通过CMM5级的企业 有摩托罗拉中国研究院 华为印度研究院 2007年东大阿尔派 东软前身 一般 外包企业比较适用于通过CMM评估 而以创造性为主的软件公司 例如微软 IBM Google等 均没有进行CMM评估 大连海辉 华信都通过CMM5 主要做软件外包 1 2 1软件能力成熟度模型简介 我国的CMM发展情况 软件过程软件过程能力软件过程性能软件过程成熟度 1 2 1软件能力成熟度模型简介 软件过程人们用于开发和维护软件及其相关过程的一系列活动 包括软件工程活动和软件管理活动 1 2 1软件能力成熟度模型简介 软件过程能力描述 开发组织或项目组 遵循其软件过程能够实现预期结果的程度 它既可对整个软件开发组织而言 也可对一个软件项目而言 1 2 1软件能力成熟度模型简介 软件过程性能表示 开发组织或项目组 遵循其软件过程所得到的实际结果 软件过程性能描述的是已得到的实际结果 而软件过程能力则描述的是最可能的预期结果 它既可对整个软件开发组织而言 也可对一个特定项目而言 1 2 1软件能力成熟度模型简介 1 成熟度的五个级别2 成熟度等级的五个级别的主要特征3 软件过程的可视性4 过程能力和性能预测5 成熟度等级的内部结构 1 2 2CMM的成熟度级别 1级初始级 Initial 2级可重复级 Repeatable 3级已定义级 Defined 4级已管理级 Managed 5级优化级 Optimizing 成熟度等级1 5 1 2 2CMM的成熟度级别 初始级特征 软件过程的特点是无秩序的 偶尔甚至是混乱的 几乎没有什么过程是经过定义的 成功依赖于个人努力 可重复级特征 已建立基本的项目管理过程去跟踪成本进度和功能 必要的过程纪律已经就位 使具有类似应用的项目能重复以前的成功 成熟度等级的五个级别的主要特征 1 2 2CMM的成熟度级别 已定义级特征 管理活动和工程活动两方面的软件过程均已文档化 标准化 并集成到组织的标准软件过程中 全部项目均采用供开发和维护软件用的组织标准软件过程的一个经批准的普及剪裁版本 已管理级特征 已采集详细的有关软件过程和产品质量的度量 无论软件过程还是产品均得到定量了解和控制 优化级特征 利用来自过程和来自新思想 新技术的先导性实验的定量反馈信息 使持续过程的改进成为可能 成熟度等级的五个级别的主要特征 1 2 2CMM的成熟度级别 软件过程的可视性 等级1 一个黑盒等级2 项目里程碑处具有管理可视性等级3 盒子的内部结构可视等级4 软件过程被配备上度量 并得到定量地控制等级5 对过程不断改进 1 2 2CMM的成熟度级别 过程能力和性能预测随着成熟度增长 实际结果相对预定目标结果的偏差范围减小随着成熟度增加 预定目标结果得到改善 1 2 2CMM的成熟度级别 1 2 2CMM的成熟度级别 什么是关键过程区域 KeyProcessArea KPA 每个关键过程区域识别出一串相关活动 当这些活动全部完成时 能达到一组对增强过程能力至关重要的目标 KPA的特性 每个KPA识别出一串相关活动每个KPA定义在单个成熟度等级上KPA鉴别出为达到某一成熟度等级所必须解决的问题 1 2 3不同级别的KPA KPA的结构 目标共同特点执行约定执行能力执行活动度量和分析验证实施 1 2 3不同级别的KPA KPA的目标 Goal 目标概括一个KPA中的所有关键实践 并能用于确定一个组织或项目是否已有效地实施此KPA 目标表示每个关键过程域的范围 边界和意图 1 2 3不同级别的KPA KPA的共同特点 执行约定 CommitmenttoPerform 企业为了建立和实施相应KPA所必须采取的行动 执行能力 AbilitytoPerform 描述了为了某软件过程得以始终如一地执行必须在项目或企业中存在的先决条件 是企业实施KPA的前提条件 执行活动 ActivitiesPerformed 描述了执行KPA所需求的必要行动 任务和步骤 其是唯一一项与项目执行相关的属性 度量和分析 MeasurementandAnalysis 关注于这个关键过程域的活动需要做的度量和度量分析要求 验证实施 VerifyingImplementation 是验证执行活动是否与建立的过程一致 核实以确保所实施的过程是按照原定的计划以及达到其目标 着眼于保证过程的实现要通过独立的个人和高级管理人员验证 1 2 3不同级别的KPA 执行约定 CommitmenttoPerform 执行约定是企业为了建立和实施相应KPA所必须采取的行动 这些行动主要牵涉到企业范围的政策和高层管理的责任 1 2 3不同级别的KPA 执行能力 AbilitytoPerform 执行能力描述为了使某软件过程得以始终如一地执行的必须在项目或企业中存在的先决条件 是企业实施KPA的前提条件 企业必须采取措施 在满足了这些条件后 才有可能执行KPA的实践活动 执行能力关注于项目计划的实践 资源的配置 责任的布置与授权 以及各种有关的培训等 这些都是为了执行这个关键过程域的活动而对特定人以及作为整体的机构的能力开发起非常重要作用的事务 1 2 3不同级别的KPA 执行活动 ActivitiesPerformed 执行活动描述了执行KPA所需求的必要行动 任务和步骤 在五个公共属性中 执行活动是唯一与项目执行相关的属性 其余四个属性则涉及企业CMM能力基础设施的建立 执行活动一般包括计划 执行的任务 任务执行的跟踪等 1 2 3不同级别的KPA 验证实施 VerifyingImplementation 验证实施是验证执行活动是否与建立的过程一致 核实以确保所实施的过程是按照原定的计划以及达到其目标 着眼于保证过程的实现要通过独立的个人和高级管理人员验证 涉及到管理的评审和审计以及质量保证活动 包括 过程执行的确保 产品要求的确保 高层管理人员进行的审核和项目经理进行的审核 1 2 3不同级别的KPA 测量和分析 MeasurementandAnalysis 测量和分析关注于这个关键过程域的活动需要作的度量和度量分析要求 典型的测量和分析的要求是确定执行活动的状态和执行活动的有效性 1 2 3不同级别的KPA 1 2 3不同级别的KPA CMM共有18个KPA 其中 2级 6个3级 7个4级 2个5级 3个 等级2的KPA 需求管理RM RequirementsManagement 软件项目计划SPP SoftwareProjectPlanning 软件项目跟踪和监督SPTO SoftwareProjectTrackingandOversight 软件子合同管理SSM SoftwareSubcontractManagement 软件质量保证SQA SoftwareQualityAssurance 软件配置管理SCM SoftwareConfigurationManagement 1 2 3不同级别的KPA RM软件需求受控制 为软件工程和管理活动建立基线 软件计划 产品和活动与需求保持一致 SPP项目活动和约定是有计划的 并成文归档 受影响的小组和个人认同项目相关的约定 对项目的估计要文档化 便于在项目计划和跟踪时使用 SPTO实际的结果和性能要按照软件计划进行跟踪 实际的结果和性能严重偏离软件计划时 要采取正确的措施 并设法关闭 受影响的组和个人认问对约定的更改 SSM主合同方和子合同方认同他们的约定 主合同方根据他们的约定跟踪子合同方的实际结果 主合同方和子合同方在项目进行期间保持联系 主合同方根据他们的约定跟踪子合同方的实际性能 1 2 3不同级别的KPA SCM软件配置管理活动纳入计划 选定的软件工作产品被标识 受控制和便于利用 被标识的软件工作产品的更改是可控的 受影响的小组和个人知道软件基线的状态和内容 SQA软件质量保证活动纳人计划 软件产品和活动与采用的标准 规程和需求间的一致性被客观地验证 受影响的组和个人知道软件质量保证活动和结果 项目中无法解决的有意见分歧的事宜通知高级管理部门处理 1 2 3不同级别的KPA 等级3的KPA 组织过程焦点OPF organizationprocessfocus 组织过程定义OPD organizationprocessdefinition 培训大纲TP trainingprogram 集成软件管理ISM integratedsoftwaremanagement 软件产品工程SPE softwareproductengineering 组间协调IC intergroupcoordination 同行评审PR peerreviews 1 2 3不同级别的KPA OPF软件过程开发和改进活动在机构内保持一致 所使用的软件过程的强弱之处被确定 机构级的过程开发和改进活动纳入计划 OPD开发并维护机构的一个标准软件过程 与软件项目使用机构标准软件过程相关的信息被收集 评审并可用 TP培训活动纳入计划 提供关于执行软件管理和技术的人员所需的开发技巧和知识的培训 软件工程组和软件相关组里每个人都接受了执行工作所需的培训 ISM项目定义的软件过程是机构标准软件过程的裁剪版本 依据项目定义的软件过程来计划和管理项目 1 2 3不同级别的KPA SPE软件工程任务被定义 集成并遵照执行 以生产软件 软件工作产品相互间保持一致 IC所有受影响的组认同客户需求 所有的组认同不同组间的约定 各组识别 跟踪和解决组间问题 PR同行评审活动纳入计划 软件工作产品的缺陷被识别和清除 1 2 3不同级别的KPA 等级4的KPA 定量过程管理QPM quantitativeprocessmanagement 软件质量管理SQM softwarequalitymanagement 等级5的KPA 缺陷预防DP defectprevention 技术改革管理TCM technologychangemanagement 过程更改管理PCM processchangemanagement 1 2 3不同级别的KPA QPM将量化过程管理活动纳入计划 项目定义的软件过程的过程性能得到量化控制 机构标准软件过程的过程能力以量化项值表示 SQM将项目的软件质量管理活动纳入计划 对软件产品质量及其优先级的可测目标有定义 软件产品质量目标的实际进步得到量化管理 1 2 3不同级别的KPA DP将缺陷预防活动纳入计划 找出和识别引起缺陷的共同原因 引起缺陷的共同原因被赋予优先次序并被系统地清除 TCM将技术更新纳入计划 新技术被评估以决定对质量和生产率的影响 合适的新技术被引入到机构内正常使用 PCM将待续地过程改进纳入计划 机构软件过程改进活动的参加者遍及全部机构 机构软件过程和项目定义的软件过程得到持续地改进 1 2 3不同级别的KPA 1 过程评估与过程评价2 过程评估的方法 1 2 4CMM的评估方法 软件过程评估 用于确定一个组织的当前软件过程的状态 确定组织所面临的具有高优先级的与软件过程有关的问题 和获得组织对软件过程改进的支持 软件过程评价 用于识别合格的能完成软件工作的承包商或者监控现有软件工作中所应用的软件过程的状态 1 2 4CMM的评估方法 过程评估阶段 一 申请CMM评估二 选择主任评估师三 工作准备四 预评估五 正式评估 1 2 4CMM的评估方法 过程评估的方法 成熟度问卷文档面谈 1 2 4CMM的评估方法 1 1 软件开发与软件项目管理1 2 CMM简介1 3 INFOSYS公司的项目管理实践 第一章绪论 1 INFOSYS公司的背景知识2 SEPG对项目的支持3 高层经理参与项目4 项目经理培训5 INFOSYS过程体系结构6 项目管理过程 项目规划 项目执行 项目收尾 1 3INFOSYS公司的项目管理实践 Infosys技术有限公司是一家总部在印度班加罗尔的一家全球技术服务公司 这家公司在2011年财富印度500强中列第27名 Infosys在29个国家设有办公室并在印度 美国 中国 澳大利亚 英国 加拿大 日本等地设有研发中心 公司在超过30个国家提供商业咨询 技术 工程及外包服务 1 3Infosys简介 SoftwareEngineeringProcessGroup 软件工程过程小组工作开销SEPGVS QA 1 3SEPG CEOSEPG管理委员会 1 3高层管理者介入 1 3Infosys的过程体系结构 Infosys的过程是按照自上而下的方式组织的 过程 活动 子活动 阶段 阶段定义 ETVX模型 Entry Task Verification Exit入口 任务 验证和出口 过程的定义的模板 1 概述 该阶段的简要描述2 参与人员 所有参与执行该阶段中各种活动的人员3 入口准则 该阶段开始前必须具备的前提条件4 输入 执行该阶段所需的所有输人5 活动 所有在这个阶段执行的活动 有时包括一些重要的子活动 6 出口准则 该阶段结束时它的输出必须满足的条件7 输出 该阶段的所有输出8 度量 该阶段执行时必须进行的度量活动9 特殊考虑10 参考 概述 需求变更实施参与人员 客户 业务主管 项目经理 项目组入口准则 接收变更请求输入 变更请求和项目已经生产出来的工作产品活动 记录变更执行对工作产品造成影响的分析估计变更请求需要的工作量重新估计交付时间执行总的的花费影响分析如果超过阈值 则与高级管理者一起评审带来的影响获得客户的签署重新生产工作产品出口准则 变更已经被包含在内 输出 需求变更的影响分析报告 更改后的计划以及更改后的工作产品 度量 变更的工作量特殊考虑 变更工作量的类别与累计效应 工程过程 生命周期 开发过程 维护过程 增强过程 产品开发过程 管理 获得项目过程 项目管理过程 需求变更管理过程 配置管理过程 产品管理过程 OSDC管理过程 过程生命周期 过程实现和部署 过程分析和变更 过程定义 初始化过程定义生成一个过程的体系草案获得高级管理者的授权定义过程确定生命周期的各个阶段把活动确定到一个足够的粒度级别 细化活动 确定输入和输出确定入口和出口准则确定测量 参与者和参考写概述如果需要 建立ISO和CMM的交叉参考定义裁剪指南用户和高级管理者评审按照机构标准产生过程定义 启动过程试运行过程试运行计划确定试运行项目为试运行定义数据采集和分析计划为试运行项目组提供指导监督试运行项目收集数据 反馈 事宜和其他信息进行试运行结束后的分析关闭试运行根据需要 更新过程定义草案更新过程定义基线正式发布指导培训在机构范图内部署 项目计划阶段项目执行阶段项目收尾阶段 1 3项目管理过程 参加者项目负责人 计划 客户 SEPG的代表 项目业务主管 项目计划阶段 熟悉项目产生项目计划和进度安排定义项目目标计划人力资源定义项目机构为项目执行选择合适的标准过程根据项目需求裁剪标准过程确定方法 工具 模板和标准确定风险和克服风险的计划工作量估计定义项目里程碑定义项目进度安排定义质量计划定义项目测量计划定义项目培训计划定义项目跟踪规程定义项目计划的假设前提对项目计划和工作安排进行组评审获得高级管理者的授权确定和评审CM 配置管理 计划对项目组提供指导 项目执行阶段 参加者项目负责人 客户 SEPG的代表 项目业务主管 项目组 跟踪项目状态与高级管理者评审项目状态管理需求变更监督项目与定义好的项目过程的一致性进行里程碑评审 项目收尾阶段 参加者项目负责人 项目质量顾问 项目业务主管 项目组 主要目标是学习经验 使机构过程得以改进 项目结束的数据分析 包括执行的度量数据分折 为将来使用而收集的过程评估 记录学到的经验教训等等 主要输出是在项目中采集的度量数据 客户抱怨记录 项目管理的概念项目管理的主要内容项目管理的阶段划分 第二章软件项目管理概述 2 1项目管理的概念 下面哪些活动是项目 上课野餐活动某次企业的校园宣讲会社区保安开发某套管理软件每天的卫生保洁玉兔登月计划 项目的定义所谓项目 就是为创建某一独特产品或服务或成果 在一定的环境和约束条件下进行的临时性努力即它是利用有限的资源 在有限的时间内为特定客户完成特定目标的一次性工作 2 1项目管理的概念 项目的特征 一个明确的范围和目标 一个预期的完成时间 有可以利用的资源 一种已定义的性能评估方法 不是例行的任务 2 1项目管理的概念 下面哪些活动是项目 2 1项目管理的概念 上课野餐活动某次企业的校园宣讲会社区保安开发某套管理软件每天的卫生保洁玉兔登月计划 项目 日常活动 什么是项目管理 Badiru 1991 将项目管理定义为 一种为高效恰当地完成某个既定的目标而对资源进行管理 分配和调度的过程 我们也可以把项目管理定义为 一种为实现既定目标而对技术 人力及金融资源所进行的系统集成 2 1项目管理的概念 项目管理一定的主体 为了实现其目标 综合运用专门的知识 技能 工具和方法 对执行中的项目周期的各阶段工作进行计划 组织 协调 控制 以满足甚至超越项目干系人的需求和期望 2 1项目管理的概念 2 2项目管理的内容 质量管理 时间管理 成本管理 风险管理 人力资源管理 合同 采购管理 范围管理 通讯管理 项目综合管理 2 2项目管理的内容 项目管理的三要素 项目 质量 成本 进度 2 2项目管理的内容 项目管理主要有三大阶段项目规划项目执行项目收尾 2 3项目管理的阶段划分 项目规划 主要是项目经理审阅合同条款 并制定一个满足他们的计划 实际上包括 定义生命周期 估计工作量和进度 制定任务进度计划等 项目执行 包括执行项目计划 跟踪项目的状态 并在项目的绩效偏离项目计划设定的绩效时采取措施进行纠正 项目收尾 主要是在客户接收工作产品之后对项目进行系统的总结 数据分析是这一阶段的主要任务 2 3项目管理的阶段划分 规划 第三章需求规格和需求管理 需求开发 分析和产生需求的过程 发生在软件生命周期的开始 需求管理 包括对需求的评审 变更 跟踪 贯穿于整个软件生命周期 需求需求分析和需求规格需求变更需求跟踪 第三章需求规格和需求管理 什么是需求 IEEE软件工程标准词汇表 1997年 定义需求为 用户解决问题或达到目标所需的条件或权能 Capability 系统或系统部件要满足合同 标准 规范或其它正式规定文档所需具有的条件或权能 一种反映上面 或 所描述的条件或权能的文档说明 3 1需求 3 2需求分析和需求规格 需求开发阶段执行的活动主要集中在两个领域 问题分析和产品描述 需求分析的过程1 准备阶段 阅读技术以及商务概念上的背景资料并进行培训 熟悉客户使用的方法和工具 确定信息的采集方法 准备好提问问题 确定用户组与评审专家 计划原型 确定需求规格标准 制定会谈计划 开发会谈计划并与客户评审 2 采集 澄清需求 建立系统目标和范围 采集功能需求 采集外部接口信息 采集操作环境需求 采集性能需求 采集标准需求 采集用户特殊需求 准备和评估原型 执行反馈会话3 分析需求 设计过程模型 设计逻辑数据模型 建立数据字典 4 准备SRS SoftwareRequirementsSpecification 需求规格说明书 准备验收准则5 评审SRS和验收准则6 客户认可并签署SRS 3 2需求分析和需求规格 1 需求规格说明书 需求规格说明书的要求 3 2需求分析和需求规格 SRS的要求 正确性 无二义性 完整性 一致性 可测试性 可跟踪性 需求是会发生变化的 而且需求的变更可以在项目生命周期的任何时间发生 越是发生在后期 对项目的影响越大 如何管理好需求变更的申请是非常重要的 3 3需求变更管理 需求变更管理过程 变更管理过程规定如何发出变更申请 何时需要正式批准等 在出现需求变更申请时 必须执行需求变更管理过程 3 3需求变更管理 一般的变更管理过程记录变更分析变更对工作产品的影响估计变更申请所需的工作量重新估计交付时间表执行累计的成本影响风险如果影响超出一定的限度 则与高级主管一起评审影响客户不再提出变更申请修改工作产品 3 3需求变更管理 3 4需求跟踪管理 项目的基本目标是构建能满足客户需求的软件系统 需求跟踪意味着对每一项需求可以追踪到实现该需求的设计 编码以及测试实现的测试用例 需求跟踪 前向跟踪和后向跟踪 前向跟踪意味着看需求是否在生命周期的后期阶段 设计和编码阶段 的输出元素中得到体现 后向跟踪则相反 它意味着看后期各个阶段的输出元素满足何种需求 后向跟踪也经常意味着跟踪到需求原始状态的能力 跟踪矩阵 3 4需求跟踪管理 支持跟踪功能最简单的方式是进行从需求单元到设计单元 从设计单元到编码单元 从编码单元到测试用例的映射 跟踪矩阵的维护和使用 更新矩阵最简单的方式是在相关阶段评审结束后更新它 浏览矩阵中的需求数目和需求文档中的需求 确保矩阵中列出了所有的需求 没有遗漏 通过对需求编号进行排序 然后对照检查需求数目是否与需求文档中的数目一致 可以很容易地达到这个目标 为确保在矩阵中列出的所有程序在最终的软件中都是必要的 并且没有冗余的代码 必须在矩阵中指出每个程序 类和其他单元 通过确保功能需求没有空白列来检查需求的实现 对其他需求 如果设计和程序域是空白 需要仔细检查和验证这些需求对程序有没有直接的影响 3 4需求跟踪管理 对每个性能需求 都应该设计一些测试用例 使用矩阵 可以很容易地检查测试用例是否适合检测这项性能需求 集成和系统测试计划可以和矩阵一起进行交叉检查以此来保证需求的所有条件都包含在系统测试计划中 3 4需求跟踪管理 需求变更与跟踪矩阵的完整性需求文档 更改需求或补充变更需求跟踪矩阵 更改需求 依具体情形对矩阵中对应项更改 变更附加到需求文档中 跟踪矩阵中增加一个表项 软件开发过程及描述过程裁剪 第四章过程定义和过程裁剪 过程描述 定义过程描述是项目可以用来遵照执行某些任务的一系列步骤 以及执行这些步骤的指南 开发过程是提炼用户需求 设计 构建和测试满足这些需求的软件并最终将其交付给客户所需的过程 当开发新的应用或计划为现有的应用进行重要的增强时 就要使用开发过程 4 1过程定义 4 1 1软件开发过程 4 1 1软件开发过程 4 1 1软件开发过程 4 1 1软件开发过程 开发过程是提炼用户需求 设计 构建和测试满足这些需求的软件并最终将其交付给客户所需的过程 4 1 1软件开发过程 每个开发子过程都包括 输入准则输入输出准则输出度量 给出从计算机的逻辑角度开发针对用户需求的解决方案 参加者 设计团队 评审团队 客户输入准则 需求规格文档经过评审并授权输入 需求规格文档输出准则 概要设计文档经过评审和授权输出 概要设计文档 项目标准 概要设计评审记录度量 工作量 缺陷主要步骤 4 1 2概要设计 定义标准 编码 文档 用户接口等等 操作环境的决策 设计细节进行功能设计确定功能产生事件和功能的交叉参考确定每个功能的处理细节功能体系的归档开发物理数据库设计更新数据模型将实体和关系转化为表和记录类型执行规模估计执行受控非标准化确定索引 进一步对概要设计中的整体应用分解 分解成模块和程序 对程序进行逻辑设计 参加者 设计团队输入准则 概要设计文档经过评审和授权输入 概要设计文档输出准则 详细设计文档和单元测试计划已经经过评审和授权输出 详细设计文档和单元测试计划度量 工作量 缺陷主要步骤 4 1 3详细设计 将功能分成小的组件如果需要 开发数据移植程序设计 开发代码框架开发例程和工具程序设计确定程序调用的方法确定输入和输出设计程序逻辑确定数据结构确定使用的通用例程写程序规格并对其进行评审计划单元测试确定单元测试环境确定单元测试用例确定测试数据写单元测试计划并对其进行评审 根据详细设计用编程语言编写所需要的程序参加者 项目组成员 项目经理输入准则 详细设计文档经过评审并授权输入 详细设计文档 项目标准 单元测试计划 程序框架输出准则 成功执行所有单元测试计划中的测试用例输出 源代码 可执行代码 测试数据度量 工作量 缺陷主要步骤 4 1 4编码和单元测试 生成测试数据库生成代码对程序进行编码代码评审记录和修正评审出的缺陷进行单元测试进行单元测试进行附加测试更正缺陷进行独立的单元测试准备独立的单元测试进行独立的单元测试记录所有缺陷关闭独立单元测试 已通过单元测试的模块构建成一个完整软件结构的系统方法参加人员 集成测试团队输入准则 概要设计文档经过评审和授权输入 概要设计文档和程序输出准则 成功执行所有集成测试计划中的测试用例输出 源代码 可执行代码 测试数据度量 工作量 缺陷主要步骤 4 1 5集成测试 确定环境需求决定集成规程确定将要集成的关健模块确定集成顺序确定需要测试的接口开发集成测试计划确定测试用例和执行用例的规程确定测试试数据确定期望输出重排测试用例 依据需求规格验证软件产品有效性的活动 目的是为了发现那些只有通过测试整个系统才能暴露的缺陷参加者 系统测试团队输入准则 需求规格和概要设计文档经过评审和授权输入 需求规格和概要设计文档输出准则 成功执行所有系统测试计划中的测试用例输出 源代码 可执行代码 测试数据度量 工作量 缺陷 4 1 6系统测试 决定所需测试环境决定系统测试规程确定测试特性确定用户接口确定硬件接口确定软件接口确定通信接口确定系统执行的主要业务过程确定不需要测试的重要特性以及不测试的原因确定关键测试开发测试用例确定每个测试用例以及执行它的规程确定输入 输出数据需求确定预期结果 把软件产品集成到它的操作环境中 并在这个环境中经受测试 确保它按需求执行 参加者 安装团队 客户 项目经理输入准则 成功的完成系统测试输入 测试后的软件和验收测试文档输出准则 客户签署验收单输出 安装后的软件度量 工作量和缺陷 4 1 7验收测试和安装 执行验收为验收制定计划从客户那里获得验收环境的细节准备安装计划准备软件发布文档参加验收在验收环境下安装软件进行实况运行协助客户进行验收测试改正验收缺陷更新文档以反映所有变更获得客户的验收签署执行安装在产品环境下安装软件搭建产品环境载入软件和数据进行实况运行获得客户对每个安装的签署修改安装缺陷执行用户培训 主要是操作手册 用户手册及客户需要的其他文档 主要活动 4 1 8文档 准备用户手册准备操作手册准备数据转换手册准备联机帮助评审文档 手册 参加者 安装团队 维护团队输入准则 在运行的软件输入 安装后的软件 用户文档和软件故障报告输出准则 合同中指定的维护支持阶段终止及客户签署整个项目输出 客户签署的文档 已经安装的软件度量 工作量 缺陷 4 1 9系统维护 4 2过程裁剪 过程裁剪是调整组织标准过程的过程 以此来获得用于项目的特定业务或技术需要的过程 主要有 概要裁剪指南详细裁剪指南 提出基于某些项目特效 在项目中应该如何执行一些通常的活动 概要级剪裁 根据项目特征 应用总体指南标准对标准过程进行剪裁 用到如下特征 1 团队和项目经理的经验和熟练程度 2 团队人数最多时的人数 3 需求透明度 4 项目持续时间 5 应用的关键程度 4 2 1概要裁剪指南 概要指南 评审 工作量相关或形式 列出过程中各种生命周期阶段的所有活动 还包括对每个活动相应的裁剪活动 指定每个步骤是必要的还是可裁剪 并给出选择的指南 裁剪属性 执行 文档化 评审和详细级别 4 2 2详细裁剪指南 软件度量过程数据库 ProcessDatabase PDB 过程能力基线 ProcessCapabilityBaseline PCB 过程财富 ProcessAsset 第五章过程数据库与过程能力基线 软件度量可以来量化地描述软件过程和软件产品的不同方面的特点 过程度量的要素产品度量的要素 5 1软件度量 软件度量的作用 1 项目计划 2 控制项目过程 3 分析和改进组织过程 5 1软件度量 定义 PDB是存放从项目可获得的过程性能数据的数据库 这些数据可以用于项目计划 估计 生产率和质量分析等 5 2过程数据库 PDB的构成 由已经完成的项目的数据构成项目特征项目进度项目工作量项目规模故障风险 5 2过程数据库 项目特征信息包含项目名称 项目经理和模块经理的名字 项目所属业务单元 项目中使用的过程 应用领域 硬件平台 所用语言 所用DBMS 项目目标的简短描述 项目风险信息 项目持续时间和团队规模 进度信息主要包含项目期望开始和结束的日期以及实际开始和结束的日期项目工作量信息包含初始估计的工作量和实际总的工作量信息 规模信息包括已经开发的项目的软件规模 按照Loc 代码行数 简单 中等复杂或复杂程序的数目以及他们的组合来描述软件规模 缺陷信息包括在各种缺陷检测活动中发现的缺陷数 此外 在PDB中记录了一些注释 包括对估计的注释 区分简单 中等复杂或复杂程序的原则 和对风险管理的注释 贯穿于整个项目的风险察觉是如何变化的 5 2过程数据库 PDB的建立及访问PDB由SEPG建立项目经理可以阅读 人小时为单位 过程能力基线 PCB 的主要内容已交付软件的质量生产率进度计划工作量分布故障引入率过程中故障排除率质量成本故障分布 5 3过程能力基线 生产率的定义是每人月所生产的功能点 质量的定义是每个功能点所提交的缺陷数 提交的缺陷数是根据在整个验收测试 安装和维护期问所发现的所有缺陷估算出来的 缺陷注入率是在项目的生命周期内所有注入的缺陷除以规模得到的值 项目中全部的缺陷数是在过程中各个不同检测阶段所发现的缺陷数和在提交后发现的缺陷数的总和 整体缺陷清除率是在过程内通过各种缺陷检测活动所发现的缺陷数占全部缺陷数的百分比 F 用功能点描述的软件规模E 项目花费的所有工作量D1 在开发过程 提交之前 中发现的所有缺陷数D2 提交后发现的缺陷总数D D1 D2对于一个项目 则有如下定义 生产率 F E质量 D2 F缺陷注人率 D F整体缺陷清除率 D1 D PCB中的数据包含一些代表过程能力参数的平均值和范围 过程财富的组成组织标准软件过程组织的软件过程数据库 过程能力基线软件生命周期描述标准软件过程的剪裁指南和准则软件有关文档 5 4过程财富 项目管理计划配置管理计划进度标准 检查表 指南 模板和其他帮助已经开发的工具和相关注释培训材料 工作量估计模型概述估计方法 自底向上的估计方法 自顶向下的估计方法进度安排 第六章工作量估计和进度安排 工作量指分配给雇员的多少工作和时间 一个部门或其他集团的雇员在一段时间内完成的全部工作 成本人们要进行生产经营活动或达到一定的目的 就必须耗费一定的资源 其所费资源的货币表现及其对象化 软件项目的成本和用于编写软件所花费的工作量是成比例的 第六章工作量估计和进度安排 6 1工作量估计模型概述 自顶向下和自底向上这两种方法都需要项目的信息 以估计他们的基本输入数据 自顶向下方法的规模和自底向上方法的任务列表 工作量估计模型自顶向下的估计方法规模估计 整体工作量 各阶段工作量COCOMO模型自底向上的估计方法各阶段的工作量 整体的工作量此方法可以直接估计工作量 6 1工作量估计模型概述 自底向上估计任务分解 每个程序单元的复杂度定义 估计每个单元的编码工作量 计算整个程序的编码工作量 导出整体项目的工作量 各阶段的工作量 6 2 1自底向上的估计方法 程序单元分类的准则各种平台 各种语言 各种环境分类的标准不一样 方法的有效性估计工作量与实际工作量的比较 6 2 1自底向上的估计方法 用于估计的规程包括以下步骤 1 确定系统中的程序 并将它们分为简单 中等复杂或复杂 S M C 尽量使用提供的定义或其他项目使用的定义 2 如果存在项目特定的基线 从基线中获得构建S M C程序所需的平均工作量 3 如果项目特性的基线不存在 使用项目类型 技术 语言和其他属性来查找过程数据库中类似的项目 使用来自这些项目的数据来定义S M C程序的构建工作量 如果在过程数据库中没有类似的项目 并且不存在项目特性的基线 即 这个项目涉及到一个新领域或技术 使用通用过程能力基线中S M C程序的平均构建工作量 5 使用项目特定的因素来进一步改进S M C程序的构建工作量 6 使用S M C程序的构建工作量和程序被调用的总次数来获得总的构建工作量 7 使用能力基线或过程数据库中类似项目中的工作量分布数据来估计其他任务的工作量和总工作量 8 基于项目特定的因素重新改进估计 规模估计 整体工作量 各阶段工作量软件规模估计的主要估算方法 代码行 LOC KLOC 法功能点法 6 2 2自顶向下的估计方法 自顶向下的估计的整体方法包含以下步骤 1 获得按照功能点计算的整个软件规模的估计2 使用类似过程类型的过程能力基线生产率数据或过程数据库中类似项目的生产率数据来确定项目的生产率级别3 从生产率和规模估计获得整体工作量估计4 使用从过程能力基线 或类似项目 获得的工作量分布数据来估计各个阶段的工作量5 修正估计 将项目特定的因素考虑进去 COCOMO模型 基本COCOMO模型 中级COCOMO模型 6 2 2自顶向下的估计方法 1981年BoehmCOCOMO模型 ConstructiveCostModel 基本COCOMO模型E a S bD c E dE表示工作量 单位是人月 PM D表示开发时间 单位是月 M S是项目的代码行估计值 单位是千行代码a b c d是常数Boehm把软件划分为组织型 半独立型和嵌入型三类 允许不同应用领域和复杂程度的软件按照三类软件的适用范围选取相应的参数a b c d 软件类型abcd适用范围组织型2 41 052 50 38各类应用程序半独立型3 01 122 50 35各类实用程序 编译程序等嵌入型3 61 202 50 32实时处理 控制程序 操作系统 6 2 2自顶向下的估计方法 中级COCOMO模型E a S b EAFD c E d软件类型ab组织型3 21 05半独立型3 01 12嵌入型2 81 20工作量调节因子 EAF 软件产品属性1 软件可靠性2 软件复杂性3 数据库的规模 计算机属性4 程序执行时间5 程序占用内存的大小6 软件开发环境的变化7 软件开发环境的响应速度 人员属性8 分析员的能力9 程序员的能力10 有关应用领域的经验11 开发环境的经验12 程序设计语言的经验项目属性13 软件开发方法的能力14 软件工具的质量和数量15 软件开发的进度要求 6 2 2自顶向下的估计方法 每个要素调节因子Fi i 1 2 15 的值分为 很低 低 正常 高 很高 极高 共六级 正常情况下Fi 1 Boehm推荐的Fi值范围 0 70 0 85 1 00 1 15 1 30 1 65 当15个Fi的值选定后 EAF的计算如下EAF F1 F2 F15调节因子集的定义和调节因子定值是由统计结果和经验决定的 不同的软件开发组织 在不同的历史时期 随着环境的变化 这些数据可能改变 使用中间CoCoMo模型可以估算开发软件产品的工作量 比较各种开发方案的工作量