软件项目管理2016软件本科

1、软件项目管理,徐长青,Software Project management,使用的开发工具,配置管理： Microsoft Visual SourceSafe (VSS)。微软Windows平台下的一个小型软件配置管理工具。 项目管理： Microsoft Project。微软Windows平台下国际通用的项目管理软件。,教材及参考资料,选用教材 PANKAJ JALOTE, CMM in Practice: Processes for Executing Software Projects at Infosys, 高等教育出版社, 2000. 主要参考书 M.C. Paulk, Capab

2、ility Maturity Model for Software, SEI-91-TR-24, 1991. Pankaj Jalote, Software Project Management in Practice, 2002. 3.IT项目管理 美 凯西.施瓦尔贝（Kathy Schwalbe) 2015,思考,你是否参加过软件项目的开发? 你是否组织过软件项目的开发? 有哪些印象深刻的成功和失败案例? 你认为软件开发中最具挑战性的问题是什么? 你认为自己能否胜任以下职位 程序员、设计师、项目经理、开发顾问 你希望将来在IT企业中充当什么角色？如何达成？,1.1. 软件开发与软件项目管理

3、 1.2. CMM简介 1.3. INFOSYS公司的项目管理实践,第一章 绪论,1. 软件项目管理的重要性 2. 软件危机的提出 3. 世界软件产业发展现状及中国软件业的差距,1.1 软件开发与软件项目管理,为何需要软件项目管理？ 软件的定义： 是使计算机能够工作的指令集合和相应的数据结构和文档，是一种产品，将计算机的硬件能力发挥出来的一种工具，是传递信息的一种工具，对信息的处理手段。,1.1-1 软件项目管理的重要性,软件的特征： 软件是一种逻辑元素，而不是物理元素； 软件是开发出来的，而不是用传统的方法制造出来的； 软件不会被用坏，一般产品的失败概率都遵循浴盆曲线； 工业界已经是标准化装

4、配时代，但软件还是定制时代； 创新性和人为因素更高。,1.1-1 软件项目管理的重要性,项目的定义 所谓项目，就是为创建某一独特产品或服务或者成果，在一定的环境和约束条件下进行的临时性的努力 即它是利用有限的资源，在有限的时间内为特定客户完成特定目标的一次性工作。,1.1-1 软件项目管理的重要性,管理 管理是通过利用已有的和可以争取到的各种资源(如人、财、 物、技术等)，以最少的投入获得最大的产出完成某种任务或达到 某个目标的软活动。任务有: 发现问题 拟定方案 作出决策 管理有三个层次: 高层(战略级)、中层(策略级)、基层(执行级) 组织 组织是由人和其它资源组成，为达到一个目的的集合或

5、系统。 管理是组织的任务，管理为组织服务，确保组织达到预期目标,1.1-1 软件项目管理的重要性,项目管理 一定的主体，为了实现其目标，综合 运用专门的知识、技能、工具和方法，对执 行中的项目周期的各阶段工作进行计划、组织、 协调、控制，以满足甚至超越项目干系人的需求 和期望。 项目干系人 参与项目和受项目影响的人，包 括项目发起人、项目组、支持人员、客户、最终 用户、供应商，项目对手。 项目的核心知识是范围、时间、成本和质量。辅 助知识是人力资源管理、风险管理和采购管理。,1.1-1 软件项目管理的重要性,软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（Peop

6、le）、产品（Product）、过程（Process）和项目(Project)进行分析和管理的活动。 软件项目管理的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程.为使软件项目开发获得成功，关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数.,1.1-1 软件项目管理的重要性,软件开发是一个高风险的过程 软件过程的管理是软件成功的关键 职业的发展方向、软件企业的生存的重要性,1.1-1 软件项目管理的重要性,软件危机： 软件在开发和维护过程中遇到 的矛盾与问题。,1.1-2 软件危机的提出,“

7、软件危机” 的主要原因 用户不易准确描述对软件的需求，经常存在二义性，遗漏甚至错误,1.1-2 软件危机的提出,“软件危机” 的主要原因 大型软件往往需要成百上千人的合作，由于软件系统结构复杂，如何有效组织管理、充分发挥团队作用就成为软件开发成功的关键。,1.1-2 软件危机的提出,“软件危机” 的主要原因 缺乏有效的软件开发方法和工具的支持，过分依靠程序设计在开发中的技巧和创造性，加剧了软件产品的个性化。开发过程没有统一、规范的方法论指导，文档资料不齐全。,1.1-2 软件危机的提出,“软件危机” 的主要原因 缺乏软件开发经验及相关数据积累，无法准确估计经费和进度，导致经费严重超支，完成期限

8、一拖再拖。 忽视测试阶段的工作，提交的产品质量差。,1.1-2 软件危机的提出,软件项目失败的案例,1999,10月，美国NASA火箭气象卫星失踪，耗资1.25亿美元。软件的错误，英制和公制的转换问题导致。 1963-1966 美国IBM360机器的操作系统，5000人年的工作量，1000多人进行开发，100万行代码，新版本是在老版本中找出1000个以上的错误之后修正开发。当时的情况很不好，主要负责人Brooks 把他们当时比作陷在泥潭的困兽，越挣扎越深。-人月神话,软件项目失败案例,1999年8月，在美国的一个大型的商业高速数据网络里，软件的缺陷影响了7000多个商业用户，时间长达8天。 1

9、998年4月，美国的一个重要数据通讯网络出现24小时的故障，使大部分美国的信用卡业务受到影响。受影响的还有美国的一些大银行、零售商和政府的数据系统。也是软件故障。 1997年8月，美国一家最主要的信用卡报告公司的新网站开启2天就关闭了，主要是查询自己的信用卡使用情况，但看到的是别人的账单，而不是自己的。,软件项目失败案例,逻辑产品，不同于物理产品 复杂性高 逻辑产品，逻辑复杂性，远高于硬件复杂性 软件的复杂性随规模呈指数级上升 规模大 应用扩大，代码量仍在不断膨胀 影响软件生产率和质量的因素比较复杂 人员的能力和水平 团队合作 缺乏有效、系统原理、原则、方法和工具的指导和辅助,产生软件危机的根

10、源总结,美国 印度 爱尔兰,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 软件

11、能力成熟度模型 1.3. INFOSYS公司的项目管理实践,第一章 绪论,1. CMM简介 2. CMM的成熟度级别 3. 不同级别的KPA 4. CMM 的评估方法,1.2 软件能力成熟度模型,1.2 软件能力成熟度模型,CMM Capability Maturity Model for Software. 软件能力成熟度模型是一种描述有效软件过程的关键元素的框架，CMM描述一条从无序的不成熟的过程到成熟的、有纪律的过程的进化的改进途径。 CMM体系描述了在不同成熟度级别下的软件过程的关键因素。 CMM包括对软件开发和维护进行策划、工程化和管理的实践。遵循这些关键实践，就能改进组织在实现有关

12、成本、进度、功能和产品质量等目标上的能力。,1.2-1 软件能力成熟度模型简介,SEI给CMM下的定义是：对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述。 CMM模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题，从而为选择过程改进战略提供指南。 CMM包括5个等级，共计18个过程域，52个目标，300多个关键实践。, CMM的起源与发展,CMM的起源: 软件危机,1986，SEI（CMU的软件工程研究所）正式着手这项工作,1987年9月， 发布“能力成熟度框架”和“成熟度问卷”,1991.8 CMM1.0,1993，CMM1.1,，

13、CMM-I,1.2-1 软件能力成熟度模型简介,Capability Maturity Model Integration,1999年7月6日，由IBM和清华同方合资成立的北京鼎新信息系统开发有限公司，在国内首次通过CMM2级。 2000年左右，全球60多家CMM5级的企业，印度占了40个。国内当时通过CMM5级的企业，有摩托罗拉中国研究院，华为印度研究院，2007年东大阿尔派（东软前身）。 一般，外包企业比较适用于通过CMM评估，而以创造性为主的软件公司，例如微软、IBM、Google等，均没有进行CMM评估。 大连海辉、华信都通过CMM5，主要做软件外包。,1.2-1 软件能力成熟度模型简

14、介,我国的CMM发展情况：,软件过程 软件过程能力 软件过程性能 软件过程成熟度,1.2-1 软件能力成熟度模型简介,软件过程 人们用于开发和维护软件及其相关过程的一系列活动，包括软件工程活动和软件管理活动。,1.2-1 软件能力成熟度模型简介,软件过程能力 描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。,1.2-1 软件能力成熟度模型简介,软件过程性能 表示（开发组织或项目组）遵循其软件过程所得到的实际结果，软件过程性能描述的是已得到的实际结果，而软件过程能力则描述的是最可能的预期结果，它既可对整个软件开发组织而言，也可对

15、一个特定项目而言。,1.2-1 软件能力成熟度模型简介,1. 成熟度的五个级别 2. 成熟度等级的五个级别的主要特征 3. 软件过程的可视性 4. 过程能力和性能预测 5. 成熟度等级的内部结构,1.2-2 CMM的成熟度级别,1级 初始级 (Initial) 2级 可重复级 (Repeatable) 3级 已定义级 (Defined) 4级 已管理级 (Managed) 5级 优化级 (Optimizing),成熟度等级1-5：,1.2-2 CMM的成熟度级别,初始级特征：软件过程的特点是无秩序的，偶尔甚至是混乱的，几乎没有什么过程是经过定义的，成功依赖于个人努力。 可重复级特征：已建立基本

16、的项目管理过程去跟踪成本进度和功能，必要的过程纪律已经就位，使具有类似应用的项目能重复以前的成功。,成熟度等级的五个级别的主要特征,1.2-2 CMM的成熟度级别,已定义级特征：管理活动和工程活动两方面的软件过程均已文档化、标准化，并集成到组织的标准软件过程中，全部项目均采用供开发和维护软件用的组织标准软件过程的一个经批准的普及剪裁版本。 已管理级特征：已采集详细的有关软件过程和产品质量的度量，无论软件过程还是产品均得到定量了解和控制。 优化级特征：利用来自过程和来自新思想、新技术的先导性实验的定量反馈信息，使持续过程的改进成为可能。,成熟度等级的五个级别的主要特征,1.2-2 CMM的成熟度

17、级别,软件过程的可视性： 等级1 一个黑盒 等级2 项目里程碑处具有管理可视性 等级3 盒子的内部结构可视 等级4 软件过程被配备上度量，并得到定量地控制 等级5 对过程不断改进,1.2-2 CMM的成熟度级别,过程能力和性能预测 随着成熟度增长，实际结果相对预定目标结果的偏差范围减小 随着成熟度增加，预定目标结果得到改善,1.2-2 CMM的成熟度级别,1.2-2 CMM的成熟度级别,什么是关键过程区域（Key Process Area，KPA）？ 每个关键过程区域识别出一串相关活动，当这些活动全部完成时，能达到一组对增强过程能力至关重要的目标。 KPA的特性： 每个KPA识别出一串相关活动

18、 每个KPA定义在单个成熟度等级上 KPA鉴别出为达到某一成熟度等级所必须解决的问题,1.2-3 不同级别的KPA,KPA的结构： 目标 共同特点 执行约定 执行能力 执行活动 度量和分析 验证实施,1.2-3 不同级别的KPA,KPA的目标（Goal）： 目标概括一个KPA中的所有关键实践，并能用于确定一个组织或项目是否已有效地实施此KPA。 目标表示每个关键过程域的范围、边界和意图。,1.2-3 不同级别的KPA,KPA的共同特点： 执行约定(Commitment to Perform) ：企业为了建立和实施相应KPA所必须采取的行动； 执行能力(Ability to Perform) ：

19、描述了为了某软件过程得以始终如一地执行必须在项目或企业中存在的先决条件，是企业实施KPA的前提条件； 执行活动(Activities Performed) ：描述了执行KPA所需求的必要行动、任务和步骤；其是唯一一项与项目执行相关的属性。 度量和分析(Measurement and Analysis) ：关注于这个关键过程域的活动需要做的度量和度量分析要求。 验证实施(Verifying Implementation) ：是验证执行活动是否与建立的过程一致，核实以确保所实施的过程是按照原定的计划以及达到其目标，着眼于保证过程的实现要通过独立的个人和高级管理人员验证。,1.2-3 不同级别的KP

20、A,执行约定(Commitment to Perform) ： 执行约定是企业为了建立和实施相应KPA所必须采取的行动，这些行动主要牵涉到企业范围的政策和高层管理的责任。,1.2-3 不同级别的KPA,执行能力(Ability to Perform) 执行能力描述为了使某软件过程得以始终如一地执行的必须在项目或企业中存在的先决条件，是企业实施KPA的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的实践活动。 执行能力关注于项目计划的实践；资源的配置；责任的布置与授权；以及各种有关的培训等，这些都是为了执行这个关键过程域的活动而对特定人以及作为整体的机构的能力开发起非常重要作

21、用的事务。,1.2-3 不同级别的KPA,执行活动(Activities Performed) 执行活动描述了执行KPA所需求的必要行动、任务和步骤。 在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。 执行活动一般包括计划、执行的任务、任务执行的跟踪等。,1.2-3 不同级别的KPA,验证实施(Verifying Implementation) 验证实施是验证执行活动是否与建立的过程一致，核实以确保所实施的过程是按照原定的计划以及达到其目标，着眼于保证过程的实现要通过独立的个人和高级管理人员验证。涉及到管理的评审和审计以及质量保证活动，包括

22、：过程执行的确保，产品要求的确保，高层管理人员进行的审核和项目经理进行的审核。,1.2-3 不同级别的KPA,测量和分析（Measurement and Analysis）： 测量和分析关注于这个关键过程域的活动需要作的度量和度量分析要求。典型的测量和分析的要求是确定执行活动的状态和执行活动的有效性。,1.2-3 不同级别的KPA,1.2-3 不同级别的KPA,CMM共有18个KPA，其中： 2级 6个 3级 7个 4级 2个 5级 3个,等级2的KPA： 需求管理 RM(Requirements Management) 软件项目计划SPP(Software Project Planning)

23、 软件项目跟踪和监督SPTO(Software Project Tracking and Oversight) 软件子合同管理SSM (Software Subcontract Management) 软件质量保证SQA(Software Quality Assurance) 软件配置管理SCM(Software Configuration Management),1.2-3 不同级别的KPA,RM 软件需求受控制，为软件工程和管理活动建立基线； 软件计划、产品和活动与需求保持一致。,SPP 项目活动和约定是有计划的，并成文归档； 受影响的小组和 个人认同项目相关的约定； 对项目的估计要文档化

24、，便于在项目计划和跟踪时使用。,SPTO 实际的结果和性能要按照软件计划进行跟踪；实际的结果和 性能严重偏离软件计划时，要采取正确的措施，并设法关闭； 受影响的组和个人认问对约定的更改,SSM 主合同方和子合同方认同他们的约定； 主合同方根据他们的约定跟踪子合同方的实际结果； 主合同方和子合同方在项目进行期间保持联系； 主合同方根据他们的约定跟踪子合同方的实际性能。,1.2-3 不同级别的KPA,SCM 软件配置管理活动纳入计划； 选定的软件工作产品被标识、受控制和便于利用； 被标识的软件工作产品的更改是可控的； 受影响的小组和个人知道软件基线的状态和内容,SQA 软件质量保证活动纳人计划；

25、软件产品和活动与采用的标准、规程和需求间的一致性被客观 地验证； 受影响的组和个人知道软件质量保证活动和结果； 项目中无法解决的有意见分歧的事宜通知高级管理部门处理。,1.2-3 不同级别的KPA,等级3的KPA： 组织过程焦点OPF (organization process focus) 组织过程定义OPD(organization process definition) 培训大纲TP(training program) 集成软件管理ISM (integrated software management ) 软件产品工程SPE(software product engineering) 组

26、间协调IC(intergroup coordination) 同行评审PR( peer reviews),1.2-3 不同级别的KPA,OPF 软件过程开发和改进活动在机构内保持一致；所使用的软件过程的强 弱之处被确定；机构级的过程开发和改进活动纳入计划。 OPD 开发并维护机构的一个标准软件过程；与软件项目使用机构标准软件 过程相关的信息被收集、评审并可用； TP 培训活动纳入计划； 提供关于执行软件管理和技术的人员所需的开发技巧和知识的培训； 软件工程组和软件相关组里每个人都接受了执行工作所需的培训。 ISM 项目定义的软件过程是机构标准软件过程的裁剪版本；依据项目定义 的软件过程来计划和

27、管理项目。,1.2-3 不同级别的KPA,SPE 软件工程任务被定义、集成并遵照执行，以生产软件； 软件工作产品相互间保持一致。 IC 所有受影响的组认同客户需求； 所有的组认同不同组间的约定； 各组识别、跟踪和解决组间问题。 PR 同行评审活动纳入计划; 软件工作产品的缺陷被识别和清除,1.2-3 不同级别的KPA,等级4的KPA： 定量过程管理QPM (quantitative process management) 软件质量管理SQM (software quality management) 等级5的KPA： 缺陷预防DP (defect prevention) 技术改革管理TCM(t

28、echnology change management ) 过程更改管理 PCM(process change management ),1.2-3 不同级别的KPA,QPM 将量化过程管理活动纳入计划； 项目定义的软件过程的过程性能得到量化控制； 机构标准软件过程的过程能力以量化项值表示。 SQM 将项目的软件质量管理活动纳入计划； 对软件产品质量及其优先级的可测目标有定义； 软件产品质量目标的实际进步得到量化管理。,1.2-3 不同级别的KPA,DP 将缺陷预防活动纳入计划； 找出和识别引起缺陷的共同原因； 引起缺陷的共同原因被赋予优先次序并被系统地清除。 TCM 将技术更新纳入计划； 新

29、技术被评估以决定对质量和生产率的影响； 合适的新技术被引入到机构内正常使用。 PCM 将待续地过程改进纳入计划； 机构软件过程改进活动的参加者遍及全部机构； 机构软件过程和项目定义的软件过程得到持续地改进。,1.2-3 不同级别的KPA,1. 过程评估与过程评价 2. 过程评估的方法,1.2-4 CMM的评估方法,软件过程评估：用于确定一个组织的当前软件过程的状态，确定组织所面临的具有高优先级的与软件过程有关的问题，和获得组织对软件过程改进的支持。 软件过程评价：用于识别合格的能完成软件工作的承包商或者监控现有软件工作中所应用的软件过程的状态。,1.2-4 CMM的评估方法,过程评估阶段：一、

30、申请CMM评估二、选择主任评估师三、工作准备四、预评估五、正式评估,1.2-4 CMM的评估方法,过程评估的方法：成熟度问卷文档面谈,1.2-4 CMM的评估方法,1.1. 软件开发与软件项目管理 1.2. CMM简介 1.3. INFOSYS公司的项目管理实践,第一章 绪论,1. INFOSYS公司的背景知识 2. SEPG对项目的支持 3. 高层经理参与项目 4. 项目经理培训 5. INFOSYS过程体系结构 6. 项目管理过程(项目规划, 项目执行, 项目收尾),1.3 INFOSYS公司的项目管理实践,Infosys技术有限公司是一家总部在印度班加罗尔的一家全球技术服务公司。这家公司

31、在2011年财富印度500强中列第27名。Infosys在29个国家设有办公室并在印度、美国、中国、澳大利亚、英国、加拿大、日本等地设有研发中心。公司在超过30个国家提供商业咨询、技术、工程及外包服务。,1.3 Infosys简介,Software Engineering Process Group，软件工程过程小组 工作开销 SEPG VS. QA,1.3 SEPG,CEO SEPG 管理委员会,1.3 高层管理者介入,1.3 Infosys的过程体系结构,Infosys的过程是按照自上而下的方式组织的。,过程,活动,子活动,阶段,阶段定义：ETVX模型（Entry,Task,Verific

32、ation,Exit 入口、任务、验证和出口）,过程的定义的模板：,1.概述: 该阶段的简要描述 2.参与人员: 所有参与执行该阶段中各种活动的人员 3.入口准则: 该阶段开始前必须具备的前提条件 4.输入: 执行该阶段所需的所有输人 5.活动: 所有在这个阶段执行的活动(有时包括一些重要的子活动) 6.出口准则: 该阶段结束时它的输出必须满足的条件 7.输出: 该阶段的所有输出 8.度量: 该阶段执行时必须进行的度量活动 9.特殊考虑 10.参考,概述：需求变更实施 参与人员：客户、业务主管、项目经理、项目组 入口准则：接收变更请求 输入：变更请求和项目已经生产出来的工作产品 活动： 记录变

33、更 执行对工作产品造成影响的分析 估计变更请求需要的工作量 重新估计交付时间 执行总的的花费影响分析 如果超过阈值，则与高级管理者一起评审带来的影响 获得客户的签署 重新生产工作产品 出口准则: 变更已经被包含在内。 输出：需求变更的影响分析报告、更改后的计划以及更改 后的工作产品。 度量: 变更的工作量 特殊考虑：变更工作量的类别与累计效应,.,工程过程,生命周期 .开发过程 .维护过程 .增强过程 .产品开发过程,管理 .获得项目过程 .项目管理过程 .需求变更管理过程 .配置管理过程 .产品管理过程 .OSDC管理过程,过程生命周期,过程实现和部署,过程分析和变更,过程定义,初始化过程定

34、义 生成一个过程的体系草案 获得高级管理者的授权 定义过程 确定生命周期的各个阶段 把活动确定到一个足够的粒度级别（细化活动） 确定输入和输出 确定入口和出口准则 确定测量、参与者和参考 写概述 如果需要，建立ISO和CMM的交叉参考 定义裁剪指南 用户和高级管理者评审 按照机构标准产生过程定义,启动过程 试运行过程 试运行计划 确定试运行项目 为试运行定义数据采集和分析计划 为试运行项目组提供指导 监督试运行项目 收集数据、反馈、事宜和其他信息 进行试运行结束后的分析 关闭试运行 根据需要，更新过程定义草案 更新过程定义基线 正式发布 指导培训 在机构范图内部署,项目计划阶段 项目执行阶段

35、项目收尾阶段,1.3 项目管理过程,参加者 项目负责人（计划）、客户、SEPG的代表、项目业务主管。,项目计划阶段,熟悉项目 产生项目计划和进度安排 定义项目目标 计划人力资源 定义项目机构 为项目执行选择合适的标准过程 根据项目需求裁剪标准过程 确定方法、工具、模板和标准 确定风险和克服风险的计划 工作量估计 定义项目里程碑 定义项目进度安排 定义质量计划 定义项目测量计划 定义项目培训计划 定义项目跟踪规程 定义项目计划的假设前提 对项目计划和工作安排进行组评审 获得高级管理者的授权 确定和评审CM（配置管理)计划 对项目组提供指导,项目执行阶段,参加者 项目负责人、客户、SEPG的代表、

36、项目业务主管、项目组。,跟踪项目状态 与高级管理者评审项目状态 管理需求变更 监督项目与定义好的项目过程的一致性 进行里程碑评审,项目收尾阶段,参加者 项目负责人、项目质量顾问、项目业务主管、项目组。,主要目标是学习经验，使机构过程得以改进。项目结束的数据分析，包括执行的度量数据分折，为将来使用而收集的过程评估。记录学到的经验教训等等。 主要输出是在项目中采集的度量数据、客户抱怨记录,项目管理的概念 项目管理的主要内容 项目管理的阶段划分,第二章 软件项目管理概述,2.1 项目管理的概念,下面哪些活动是项目？,上课 野餐活动 某次企业的校园宣讲会 社区保安 开发某套管理软件 每天的卫生保洁 玉

37、兔登月计划,项目的定义 所谓项目，就是为创建某一独特产品或服务或成果，在一定的环境和约束条件下进行的临时性努力 即它是利用有限的资源，在有限的时间内为特定客户完成特定目标的一次性工作。,2.1 项目管理的概念,项目的特征： 一个明确的范围和目标； 一个预期的完成时间； 有可以利用的资源； 一种已定义的性能评估方法； 不是例行的任务,2.1 项目管理的概念,下面哪些活动是项目？,2.1 项目管理的概念,上课 野餐活动 某次企业的校园宣讲会 社区保安 开发某套管理软件 每天的卫生保洁 玉兔登月计划,项目,日常活动,什么是项目管理？ Badiru(1991)将项目管理定义为： 一种为高效恰当地完成某

38、个既定的目标而对资源进行管理、分配和调度的过程。 我们也可以把项目管理定义为： 一种为实现既定目标而对技术、人力及金融资源所进行的系统集成。,2.1 项目管理的概念,项目管理 一定的主体，为了实现其目标，综合运用专门 的知识、技能、工具和方法，对执行中的项目周期 的各阶段工作进行计划、组织、协调、控制，以满 足甚至超越项目干系人的需求和期望。,2.1 项目管理的概念,2.2 项目管理的内容,质量管理,时间管理,成本管理,风险管理,人力资源管理,合同/采购管理,范围管理,通讯管理,项目综合管理,2.2 项目管理的内容,项目管理的三要素：,项目,质量,成本,进度,2.2 项目管理的内容,项目管理主

39、要有三大阶段 项目规划 项目执行 项目收尾,2.3 项目管理的阶段划分,项目规划： 主要是项目经理审阅合同条款，并制定一个满足他们的计划，实际上包括：定义生命周期、估计工作量和进度、制定任务进度计划等。 项目执行： 包括执行项目计划、跟踪项目的状态，并在项目的绩效偏离项目计划设定的绩效时采取措施进行纠正。 项目收尾： 主要是在客户接收工作产品之后对项目进行系统的总结。数据分析是这一阶段的主要任务。,2.3 项目管理的阶段划分,规划,第三章 需求规格和需求管理,需求开发（分析和产生需求的过程，发生在软件生命周期的开始） 需求管理 （包括对需求的评审、变更、跟踪，贯穿于整个软件生命周期）,需求 需

40、求分析和需求规格 需求变更 需求跟踪,第三章 需求规格和需求管理,什么是需求？ IEEE软件工程标准词汇表（1997年）定义需求为： 用户解决问题或达到目标所需的条件或权能（Capability）。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面 或 所描述的条件或权能的文档说明。,3.1 需求,3.2 需求分析和需求规格,需求开发阶段执行的活动主要集中在两个领域： 问题分析和产品描述,需求分析的过程 1)准备阶段：阅读技术以及商务概念上的背景资料并进行培训、熟悉客户使用的方法和工具、确定信息的采集方法、准备好提问问题、确定用户组与评审专家、计划原型

41、、确定需求规格标准、制定会谈计划、开发会谈计划并与客户评审。 2)采集、澄清需求：建立系统目标和范围、采集功能需求、采集外部接口信息、采集操作环境需求、采集性能需求、采集标准需求、采集用户特殊需求、准备和评估原型，执行反馈会话 3)分析需求：设计过程模型、设计逻辑数据模型、建立数据字典； 4)准备SRS（Software Requirements Specification, 需求规格说明书）、准备验收准则 5)评审SRS和验收准则 6)客户认可并签署SRS,3.2 需求分析和需求规格,1. 需求规格说明书 （需求规格说明书的要求）,3.2 需求分析和需求规格,SRS的要求： 正确性、无二义性

42、、完整性、一致性、可测试性、可跟踪性。,需求是会发生变化的，而且需求的变更可以在项目生命周期的任何时间发生。越是发生在后期，对项目的影响越大。如何管理好需求变更的申请是非常重要的。,3.3 需求变更管理,需求变更管理过程： 变更管理过程规定如何发出变更申请、何时需要正式批准等。在出现需求变更申请时，必须执行需求变更管理过程。,3.3 需求变更管理,一般的变更管理过程 记录变更 分析变更对工作产品的影响 估计变更申请所需的工作量 重新估计交付时间表 执行累计的成本影响风险 如果影响超出一定的限度，则与高级主管一起评审影响 客户不再提出变更申请 修改工作产品,3.3 需求变更管理,3.4 需求跟踪

43、管理,项目的基本目标是构建能满足客户需求的软件系统。 需求跟踪意味着对每一项需求可以追踪到实现该需求的设计、编码以及测试实现的测试用例。 需求跟踪:前向跟踪和后向跟踪。前向跟踪意味着看需求是否在生命周期的后期阶段（设计和编码阶段)的输出元素中得到体现。后向跟踪则相反，它意味着看后期各个阶段的输出元素满足何种需求。后向跟踪也经常意味着跟踪到需求原始状态的能力。,跟踪矩阵,3.4 需求跟踪管理,支持跟踪功能最简单的方式是进行从需求单元到设计单元、从设计单元到编码单元、从编码单元到测试用例的映射。,跟踪矩阵的维护和使用,更新矩阵最简单的方式是在相关阶段评审结束后更新它。,浏览矩阵中的需求数目和需求文

44、档中的需求，确保矩阵中列出了所有的需求，没有遗漏。通过对需求编号进行排序，然后对照检查需求数目是否与需求文档中的数目一致，可以很容易地达到这个目标。 为确保在矩阵中列出的所有程序在最终的软件中都是必要的，并且没有冗余的代码，必须在矩阵中指出每个程序、类和其他单元。 通过确保功能需求没有空白列来检查需求的实现。对其他需求，如果设计和程序域是空白，需要仔细检查和验证这些需求对程序有没有直接的影响:,3.4 需求跟踪管理,对每个性能需求，都应该设计一些测试用例。使用矩阵、可以很容易地检查测试用例是否适合检测这项性能需求。 集成和系统测试计划可以和矩阵一起进行交叉检查以此来保证需求的所有条件都包含在系

45、统测试计划中。,3.4 需求跟踪管理,需求变更与跟踪矩阵的完整性 需求文档：更改需求或补充变更需求 跟踪矩阵：更改需求，依具体情形对矩 阵中对应项更改； 变更附加到需求文档中，跟 踪矩阵中增加一个表项,软件开发过程及描述 过程裁剪,第四章 过程定义和过程裁剪,过程描述/定义 过程描述是项目可以用来遵照执行某些任务的一系列步骤，以及执行这些步骤的指南。 开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户所需的过程。当开发新的应用或计划为现有的应用进行重要的增强时，就要使用开发过程。,4.1 过程定义,4.1-1 软件开发过程,4.1-1 软件开发过程,4.1-1 软件

46、开发过程,4.1-1 软件开发过程,开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户所需的过程：,4.1-1 软件开发过程,每个开发子过程都包括： 输入准则 输入 输出准则 输出 度量,给出从计算机的逻辑角度开发针对用户需求的解决方案。 参加者：设计团队、评审团队、客户 输入准则：需求规格文档经过评审并授权 输入：需求规格文档 输出准则：概要设计文档经过评审和授权 输出：概要设计文档、项目标准、概要设计评审记录 度量：工作量、缺陷 主要步骤：,4.1-2 概要设计,定义标准(编码、文档、用户接口等等) 操作环境的决策/设计细节 进行功能设计 确定功能 产生事件和功

47、能的交叉参考 确定每个功能的处理细节 功能体系的归档 开发物理数据库设计 更新数据模型 将实体和关系转化为表和记录类型 执行规模估计 执行受控非标准化 确定索引,进一步对概要设计中的整体应用分解，分解成模块和程序，对程序进行逻辑设计。 参加者：设计团队 输入准则：概要设计文档经过评审和授权 输入：概要设计文档 输出准则：详细设计文档和单元测试计划已经经过评审和授权 输出：详细设计文档和单元测试计划 度量：工作量、缺陷 主要步骤：,4.1-3 详细设计,将功能分成小的组件 如果需要、开发数据移植程序 设计/开发代码框架 开发例程和工具 程序设计 确定程序调用的方法 确定输入和输出 设计程序逻辑

48、确定数据结构 确定使用的通用例程 写程序规格并对其进行评审 计划单元测试 确定单元测试环境 确定单元测试用例 确定测试数据 写单元测试计划并对其进行评审,根据详细设计用编程语言编写所需要的程序 参加者：项目组成员 、项目经理 输入准则：详细设计文档经过评审并授权 输入：详细设计文档、项目标准、单元测试计划、程序框架 输出准则：成功执行所有单元测试计划中的测试用例 输出：源代码、可执行代码、测试数据 度量：工作量、缺陷 主要步骤：,4.1-4 编码和单元测试,生成测试数据库 生成代码 对程序进行编码 代码评审 记录和修正评审出的缺陷 进行单元测试 进行单元测试 进行附加测试 更正缺陷 进行独立的

49、单元测试 准备独立的单元测试 进行独立的单元测试 记录所有缺陷 关闭独立单元测试,已通过单元测试的模块构建成一个完整软件结构的系统方法 参加人员：集成测试团队 输入准则：概要设计文档经过评审和授权 输入：概要设计文档和程序 输出准则：成功执行所有集成测试计划中的测试用例 输出：源代码、可执行代码、测试数据 度量：工作量、缺陷 主要步骤：,4.1-5 集成测试,确定环境需求 决定集成规程 确定将要集成的关健模块 确定集成顺序 确定需要测试的接口 开发集成测试计划 确定测试用例和执行用例的规程 确定测试试数据 确定期望输出 重排测试用例,依据需求规格验证软件产品有效性的活动；目的是为了发现那些只有

50、通过测试整个系统才能暴露的缺陷 参加者：系统测试团队 输入准则：需求规格和概要设计文档经过评审和授权 输入：需求规格和概要设计文档 输出准则：成功执行所有系统测试计划中的测试用例 输出：源代码、可执行代码、测试数据 度量：工作量、缺陷,4.1-6 系统测试,决定所需测试环境 决定系统测试规程 确定测试特性 确定用户接口 确定硬件接口 确定软件接口 确定通信接口 确定系统执行的主要业务过程 确定不需要测试的重要特性以及不测试的原因 确定关键测试 开发测试用例 确定每个测试用例以及执行它的规程 确定输入、输出数据需求 确定预期结果,把软件产品集成到它的操作环境中，并在这个环境中经受测试，确保它按需

51、求执行。 参加者：安装团队、客户、项目经理 输入准则：成功的完成系统测试 输入：测试后的软件和验收测试文档 输出准则：客户签署验收单 输出：安装后的软件 度量：工作量和缺陷,4.1-7 验收测试和安装,执行验收 为验收制定计划 从客户那里获得验收环境的细节 准备安装计划 准备软件发布文档 参加验收 在验收环境下安装软件 进行实况运行 协助客户进行验收测试 改正验收缺陷 更新文档以反映所有变更 获得客户的验收签署 执行安装 在产品环境下安装软件 搭建产品环境 载入软件和数据 进行实况运行 获得客户对每个安装的签署 修改安装缺陷 执行用户培训,主要是操作手册，用户手册及客户需要的其他文档。 主要活

52、动：,4.1-8 文档,准备用户手册 准备操作手册 准备数据转换手册 准备联机帮助 评审文档/手册,参加者：安装团队、维护团队 输入准则：在运行的软件 输入：安装后的软件、用户文档和软件故障报告 输出准则：合同中指定的维护支持阶段终止及客户签署整个项目 输出：客户签署的文档、已经安装的软件 度量：工作量、缺陷,4.1-9 系统维护,4.2 过程裁剪,过程裁剪是调整组织标准过程的过程，以此来获得用于项目的特定业务或技术需要的过程。 主要有： 概要裁剪指南 详细裁剪指南,提出基于某些项目特效，在项目中应该如何执行一些通常的活动。 概要级剪裁：根据项目特征，应用总体指南标准对标准过程进行剪裁，用到如

53、下特征。 （1）团队和项目经理的经验和熟练程度。 （2）团队人数最多时的人数。 （3）需求透明度 （4）项目持续时间 （5）应用的关键程度,4.2-1 概要裁剪指南,概要指南:评审、工作量相关或形式。,列出过程中各种生命周期阶段的所有活动，还包括对每个活动相应的裁剪活动,指定每个步骤是必要的还是可裁剪，并给出选择的指南。 裁剪属性：执行、文档化、评审和详细级别。,4.2-2 详细裁剪指南,软件度量 过程数据库（Process Database, PDB） 过程能力基线(Process Capability Baseline , PCB) 过程财富( Process Asset),第五章 过程数

54、据库与过程能力基线,软件度量可以来量化地描述软件过程和软件产品的不同方面的特点。 过程度量的要素 产品度量的要素,5.1 软件度量,软件度量的作用 （1）项目计划 （2）控制项目过程 （3）分析和改进组织过程,5.1 软件度量,定义：PDB 是存放从项目可获得的过程性能数据的数据库，这些数据可以用于项目计划、估计、生产率和质量分析等。,5.2 过程数据库,PDB的构成：由已经完成的项目的数据构成 项目特征 项目进度 项目工作量 项目规模 故障 风险,5.2 过程数据库,项目特征信息包含项目名称、项目经理和模块经理的名字，项目所属业务单元、项目中使用的过程、应用领域、硬件平台、所用语言、所用DB

55、MS、项目目标的简短描述、项目风险信息、项目持续时间和团队规模。 进度信息主要包含项目期望开始和结束的日期以及实际开始和结束的日期 项目工作量信息包含初始估计的工作量和实际总的工作量信息。 规模信息包括已经开发的项目的软件规模。按照Loc（代码行数)、简单、中等复杂或复杂程序的数目以及他们的组合来描述软件规模。 缺陷信息包括在各种缺陷检测活动中发现的缺陷数。 此外，在PDB中记录了一些注释，包括对估计的注释(区分简单、中等复杂或复杂程序的原则)和对风险管理的注释(贯穿于整个项目的风险察觉是如何变化的）。,5.2 过程数据库,PDB的建立及访问 PDB由SEPG建立 项目经理可以阅读,人小时为单

56、位,过程能力基线（PCB）的主要内容 已交付软件的质量 生产率 进度计划 工作量分布 故障引入率 过程中故障排除率 质量成本 故障分布,5.3 过程能力基线,生产率的定义是每人月所生产的功能点。 质量的定义是每个功能点所提交的缺陷数，提交的缺陷数是根据在整个验收测试、安装和维护期问所发现的所有缺陷估算出来的。 缺陷注入率是在项目的生命周期内所有注入的缺陷除以规模得到的值。项目中全部的缺陷数是在过程中各个不同检测阶段所发现的缺陷数和在提交后发现的缺陷数的总和。 整体缺陷清除率是在过程内通过各种缺陷检测活动所发现的缺陷数占全部缺陷数的百分比.,F=用功能点描述的软件规模 E=项目花费的所有工作量

57、D1=在开发过程(提交之前)中发现的所有缺陷数 D2=提交后发现的缺陷总数 D=D1+D2 对于一个项目，则有如下定义: 生产率=F/E 质量=D2/F 缺陷注人率=D/F 整体缺陷清除率=D1/D,PCB中的数据包含一些代表过程能力参数的平均值和范围。,过程财富的组成 组织标准软件过程 组织的软件过程数据库/过程能力基线 软件生命周期描述 标准软件过程的剪裁指南和准则 软件有关文档,5.4 过程财富,项目管理计划 配置管理计划 进度 标准、检查表、指南、模板和其他帮助 已经开发的工具和相关注释 培训材料,工作量估计模型概述 估计方法 - 自底向上的估计方法 - 自顶向下的估计方法 进度安排,

58、第六章 工作量估计和进度安排,工作量 指分配给雇员的多少工作和时间； 一个部门或其他集团的雇员在一段时间内完成的全部工作。 成本 人们要进行生产经营活动或达到一定的目 的，就必须耗费一定的资源，其所费资源 的货币表现及其对象化。,软件项目的成本和用于编写软件所花费的工作量是成比例的。,第六章 工作量估计和进度安排,6.1 工作量估计模型概述,自顶向下和自底向上这两种方法都需要项目的信息，以估计他们的基本输入数据自顶向下方法的规模和自底向上方法的任务列表。,工作量估计模型 自顶向下的估计方法 规模估计整体工作量各阶段工作量 COCOMO 模型 自底向上的估计方法 各阶段的工作量整体的工作量 此方法可以直接估计工作量,6.1 工作量估计模型概述,自底向上估计 任务分解每个程序单元的复杂度定义估计每个单元的编码工作量计算整个程序的编码工作量导出整体项目的工作量各阶段的工作量,6.2-1 自底向上的估计方法,程序单元分类的准则 各种平台，各种语言，各种环境分类的标准不一样。 方法的有效性 估计工作量与实际工作量的比较,6.2-1 自底向上的估计