软件项目管理与案例分析复习.docx_第1页
软件项目管理与案例分析复习.docx_第2页
软件项目管理与案例分析复习.docx_第3页
软件项目管理与案例分析复习.docx_第4页
软件项目管理与案例分析复习.docx_第5页
已阅读5页,还剩11页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件项目管理与案例分析第一章1. 项目生命期中的几个概念项目生命期中与时间相关的重要概念1) 检查点(Check Point):指在规定的时间间隔内对项目进行检查,比较实际与计划之间的差异,并根据差异进行调整2) 里程碑(Mile Stone):是完成阶段性工作的标志,不同类型的项目里程碑不同 3) 基线(Base Line) :指一个(或一组)配置项在项目生命期的不同时间点上,通过正式评审而进入正式受控的一种状态 2. 本章小结1) 项目是为实现一个独特目的而进行的临时性任务,项目具有独特性、临时性及需要资源等特性,每个项目都有一个项目发起人并含有不确定性。2) 项目管理的三项约束指的是管理项目的范围、时间、成本3个维度。3) 项目管理是指在项目活动中运用相关的知识、技能、工具和技术以满足项目要求的活动。4) 利益相关者是指参与项目或者受项目活动影响的人。5) 项目管理框架包括利益相关者、项目管理知识领域和项目管理工具与技术。知识领域包括项目综合管理、项目范围、项目时间、项目成本、项目质量、人力资源、项目沟通、项目风险和项目采购管理。6) 过程管理在软件项目管理中有着重要的作用,通过不断的优化和规范过程,可以帮助企业提高软件生产能力。7) 软件项目管理的核心是项目规划和项目跟踪控制。3. 复习思考题1) 什么是项目?他与多数人的日常工作有什么不同? 项目是为创造独特的产品、服务或其他成果而进行的一次性工作。工作通常有两种不同方式:一类是持续不断和重复的,称为常规运作;另一类是独特的一次性任务,称为项目。 他与日常的不同在于项目是一次性的,日常运作是重复的;项目是以目标为导向,而日常运作是通过效率和有效性体现的;项目是通过项目经理及其团队工作完成的,而日常运作是职能式的线形管理;项目存在大量的变更管理,而日常运作是基本保持持续的连贯性。2) 分别举3个项目活动的例子和3个不属于项目活动的例子。第二章1. 合同生存期技术合同管理是围绕合同生存期进行的。其中合同生存期分为四个阶段:合同准备、合同鉴署、合同管理、合同终止。技术合同包括主合同与合同附件。合同环境主要由3个:需方合同环境、供方合同环境和企业内部合同环境。2. 需方合同环境(了解)企业在需方合同环境下,关键要素是提供准确、清晰和完整的需求,选择合格的供方并对采购对象(采购对象包括产品服务、人力资源等)进行必要的验收。1) 合同准备 招标书定义(采购需求定义) 启动一个项目主要是由于存在一种需求,招标书定义主要是需方的需求定义,也就是甲方(买方)定义采购的内容。 供方选择 招标文件确定后,就可以通过招标的方式选择供方(乙方或者卖方)。 合同文本准备 如果需方选择了合适的供方(软件开发商),需方应该与供方(软件开发商)签订一个具有法律效力的合同;签署合同之前需要起草一份合同文本。 2) 合同签署 合同签署过程就是正式签署合同,使之成为具有法律效力的文件; 同时,根据签署的合同,分解出合同中需方(甲方)的任务,并下达任务书,指派相应的项目经理负责相应的过程。 3) 合同管理对于企业处于需方(甲方)的环境,合同管理是需方对供方(乙方)执行合同的情况进行监督的过程,主要包括: 对需求对象(采购对象)的验收 验收过程是需方对供方交付的产品或服务进行验收检验,以保证它满足合同条款的要求。 对违约事件处理 在合同的执行过程中,如果供方发生与合同要求不一致的问题,导致违约事件,需要执行违约事件处理过程。 4) 合同终止 当项目满足结束的条件,项目经理或者合同管理者应该及时宣布项目结束,终止合同的执行,通过合同终止过程告知各方合同终止3. 供方合同环境(了解)1) 合同准备 企业作为供方,其合同准备阶段包括三个过程: 项目分析 项目分析是供方分析用户的项目需求,并据此开发出初步的项目计划,作为下一步能力评估和可行性分析之用。 项目竞标n 能力评估;n 可行性分析;n 参加竞标。 合同文本准备 一般是需方(甲方)提供合同的框架结构,并起草主要内容,供方(乙方)提供意见。 2) 合同签署 供方的合同签署过程也类似于需方的合同签署过程,但是这个阶段对于供方的意义是重大的,它标志着一个软件项目的有效开始,这个时候,应该正式确定供方的项目经理。 这里需要说明的是项目任务书,项目任务书明确项目的目标、必要的约束,同时授权给项目经理。 项目任务书是项目正式开始的标志,同时也是对项目经理有效授权的依据。 项目经理需要对这个任务书进行确认。 具体活动描述可以参见需方的合同签署过程。3) 合同管理 企业处于供方的环境,合同管理主要包括: 合同跟踪管理过程 合同修改控制过程 违约事件处理过程 产品交付过程 产品维护过程4) 合同终止 在合同终止过程中,供方应该配合需方的工作,包括:项目的验收、双方认可签字、总结项目的经验教训、获取合同的最后款项、开具相应的发票、获取需方的合同终止的通知、将合同相关文件归档。第三章1. 经典软件生存周期的模型(特点及使用情况)1) 软件生命周期:软件从需求确定、设计、开发、测试直至投入使用,并在使用中不断地修改、增补和完善,直至被新的系统所替代而停止该软件的使用的全过程。2) 确定软件生存周期管理的主要阶段 选择合适的生存期模型。 标识和定义生存期的的任务,即创建软件生存期。 建立管理和技术上的的软件生产过程。 整个周期内对生存期过程的管理。3) 软件项目生存期模型的基本特征:描述了开发的主要阶段 定义了每一个阶段要完成的主要过程和活动规范了每一个阶段的输入和输出提供了一个框架,可以将必要的活动映射到该框架中。4) 常用的模型:瀑布模型、螺旋模型、进化模型、原型模型、增量模型等。 瀑布模型:n 特点: 文档驱动的模型 阶段间具有顺序性和依赖性 项目开发周期较长 实际项目很少按照该模型给出的顺序进行n 使用情况: 项目的需求在项目开始前很明确 解决方案在项目开始前也很明确 类似的项目如:公司的财务系统、 库存管理系统 短期项目 原型模型:n 特点: 在需求定义之前,需要快速构建一个系统 根据构建系统的优缺点,用户给开发人员提出反馈意见 根据反馈意见修改软件需求规格以便系统更正确地反映用户的需求 减少各种假设以及风险n 使用情况: 项目的需求在项目开始前不明确 需要减少项目需求的不确定性 类似的项目如:确定显示界面、第一次开发的产品,验证可行性 增量模型:n 特点: 融合了瀑布模型和原型的迭代特征。 每一个增量均发布一个可操作产品n 使用情况: 项目开始,明确了需求的大部分,但是需求可能会发生变化 对于市场和用户把握不是很准,需要逐步了解 对于有庞大和复杂功能的系统进行功能改进,就需要一步一步实施 进化模型:n 特点: 看作是重复执行的多个瀑布模型。n 使用情况: 项目开始,需求和设计不明确且可能发生显著变化。 有多个用户组,可能产生需求冲突的。 系统功能需要向用户演示以便于项目的演进。 项目引进了新的、未经验证的技术 螺旋模型:n 特点: 基于风险驱动的开发模型, 使用原型法或其它方法来尽量降低风险。 适用于需求不明确的大规模软件项目n 使用情况: 风险是项目的主要制约因素,不确定因素和风险限制了项目的进度 用户对自己的需求不明确。2. 质量计划1) 软件质量:软件产品满足明确或隐含需求的能力有关的特征和特性的总和。2) 质量体系、质量手册和质量计划(概念和关系) 质量体系:指为保证产品、过程或服务质量,满足规定的要求,由组织机构、职责、程序、活动、能力和资源等构成的有机整体。 质量手册:描述企业质量体系的文件,根据各企业的规模和复杂程度,质量手册在其详略程度和编排格式方面可以不同。 质量计划:确定项目应达到的质量标准和决定如何满足质量标准的计划安排和方法 三者之间的关系n 质量体系好比一个国家的法制机构,质量手册就如同宪法,是质量体系的文档化体现。而每个项目制定的质量计划类似地方的法规,它在符合质量手册的前提下,根据自身的要求和特殊性,通过适当的裁减修正而来。第四章1. 软件项目团队管理概述1) 定义:软件项目团队管理就是运用现代化的科学方法,对项目组织结构和项目全体参与人员进行管理,在项目团队中开展一系列科学规划、开发培训、合理调配、适当激励等方面的管理工作,使项目组织各方面人员的主观能动性得到充分发挥,以实现项目团队的目标2) 任务:包括团队组织计划、团队人员获取、团队建设3个部分 团队组织计划:指确定、记录与分派项目角色、职责,并对请示汇报关系进行识别、分配和归档。 团队人员获取:指获得项目所需的并被指派到项目的人力资源(个人或集体)。 团队建设:既包括提高利害关系者作为个人做出贡献的能力,也包括提高项目团队作为集体发挥作用的能力。个人的培养(管理能力与技术水平)是团队建设的基础。团队的建设是项目实现其目标的关键。3) 重要性: 是软件项目管理中至关重要的组成部分 是有效地发挥每个参与项目的人员作用的过程 人员的组织管理是影响软件开发项目质量的决定性因素2. 项目团队的角色分类(写出)1) 软件项目经理 2) 系统分析员3) 系统设计员4) 软件开发人员5) 系统测试人员6) 软件配置管理人员7) 质量保证人员 3. 软件项目的基本组织结构及其比较(了解)1) 直线性组织结构2) 职能性组织结构3) 直线型组织职能结构4) 矩阵形组织结构三种组织结构优缺点及比较n 线性组织结构特点1) 反应迅速灵活;2) 运营成本较低;3) 指令唯一且责任明确;4) 低正规化和高度集权度的结构会导致高层信息超载;5) 随着规模的扩大制定决策变得非常缓慢;6) 高层经理会陷入日常经营活动而无法做好长期性的资源配置工作。n 职能制组织形式特点1) 在人员利用上有较大的弹性和适应性;2) 个别专家可被不同项目利用;3) 部门中的专家可以被组织起来共享知识和经验;4) 在个别人离开项目甚至上级组织时仍可以保持技术上的延续性;5) 职能部门有自己的常规工作,这些工作常常优先于项目考虑,客户常被忽略;6) 职能部门中没有人对项目全权负责,不能引起对项目的高度责任感;7) 协调性差;8) 不易形成对项目的系统化管理系统n 矩阵制组织形式特点1) 项目管理强调的重点是,项目经理个人负责管理项目以保证项目在规定费用之内按期完成;2) 由于项目组织覆盖于职能部门之上,因此人力资源管理方便,且项目可充分利用职能部门的技术优势;3) 对客户反应迅速;4) 项目决策权力需要在项目组织和职能部门二者之间平衡从而带来一定困难;5) 多个项目之间优化项目目标是矩阵制的一个优点但也由此带来项目之间的资源竞争从而互相影响;6) 由于项目人员至少有两个上级:项目经理和职能部门经理,容易造成上级命令的不统一,从而带来管理混乱。4. 马斯洛把人的需求分为五个层次:1) 生理需要(衣食住等)2) 安全需要(稳定,身体安全,经济安全)3) 社交需要(亲情,友情,归属感)4) 尊重需要(地位和自我尊重、认可和感激)5) 自我实现需要5. 绩效评估遵循的原则1) 公开性原则2) 客观、公正原则3) 及时反馈原则4) 敏感性原则,又称区分性原则5) 可行性原则6) 多层次、多渠道、全方位评价的原则7) 绩效评估经常化、制度化的原则 第五章1. 需求开发和管理过程1) 需求工程:也叫需求过程或需求阶段,包括需求开发和需求管理.2) 需求开发包括需求获取、需求分析、编写需求规格说明、验证需求四个阶段,在这些阶段执行以下活动: 确定产品所期望的用户类; 获取每个用户类的需求; 了解实际用户任务和目标以及这些任务所支持的业务需求; 分析源于用户的信息以区别业务需求、功能需求、质量属性、业务规则,建议解决的方法和附加的信息; 分解需求,并将需求中的一部分分配给软件组件; 了解相关属性的重要性; 划分实施优先级; 编写需求规格说明和模型; 评审需求规格,验证对用户需求的正确理解和认识。2. 需求获取方法1) 访谈、调研及专题讨论会 访谈与调研n 和用户进行访谈和调研通常是适用于任何环境下的最重要最直接的方法之一。n 访谈的一个主要目标是确保访谈者的偏见或主观意识不会干扰自由的交流 专题讨论会n 专题讨论会是一种可用于任何情况下的软件需求调研方法。n 专题讨论会的目的是鼓励软件需求调研并且在很短的时间内 对讨论的问题达成一致。2) 脑力风暴 是一种对于获取新观点或创造性的解决方案而言非常有用的方法。 通常,专题讨论会的一部分时间是用于进行脑力风暴,找出关于软件系统的新想法和新特征。 脑力风暴包括两个阶段:想法产生阶段和想法精化阶段。3) 场景串联 场景串联的目的是为了尽早的从用户那里得到用户对建议的系统功能的意见。 场景串联被分成三种模式:静态的场景串联、动态的场景串联以及交互的场景串联第六章1. 软件项目规模估算常用的软件规模度量方法有三种:LOC估算法、FP估算法、PERT估算法1) LOC估算法:代码行可以分为无注释的源代码行(NCLOC)和注释的源代码行(CLOC),源代码的总行数LOC即为NCLOC与CLOC之和2) LOC估算法(示例)2. 软件项目进度估算1) 工程评价技术:利用网络顺序图的逻辑关系和加权历时估算来计算项目历时。采用加权平均的算法是:(O+4M+P)/6其中:O是活动完成最小估算值,P是活动完成最大估算值,M是活动完成的最大可能估算值。2) 工程评价技术(示例)P1193. 软件项目进度计划1) 甘特图(概念):是各种任务活动与日历表的对照图。 显示基本的任务信息 可以查看任务的工期、开始时间和结束时间以及资源的信息 只有时标,没有活动的逻辑关系 有两种表示方法(棒状、三角形)2) 网络图(概念):用网络分析的方法编制的进度计划称为网络图。 在网络图中一个活动用一个方框、节点或者其他方式表示 每一个活动被各种关系线相连接着 将项目中的各个活动的逻辑关系表示出来 网络图开始于一个任务、工作、活动、里程碑 网络图结束于一个 任务、工作、活动、里程碑 有些活动前置任务或者后置任务3) 路径和关键路径 路径:在网络图中,从发点开始,按照各个任务的顺序,连续不断地到达收点的一条通路称做路径。 关键路径:在各条路径上,完成各个任务的时间之和是不完全相等的。其中完成各个任务需要时间最长的路径称为关键路径。 关键路径是决定项目完成的最短时间。 项目整个网络图中最长的路径 关键路径上的任何活动延迟,都会导致整个项目完成时间的延迟 关键路径上的任何任务都是关键任务 是时间浮动为0(Float=0)的路径 如果关键路径上的一个活动比计划的时间长,整个项目的进度将会拖延,除非采取纠正措施 并不是所有的关键任务都在关键路径上 明确关键路径后,你可以合理安排进度 关键路径可能不止一条 在项目的进行过程中,关键路径可能改变的4) 关键任务:组成关键路径的任务缩短关键任务所需的时间,就可以缩短项目的完工时间。5) 任务持续时间:完成某一软件任务所需的时间,用Tij表示,节点i和节点j之间的有向边表示的任务持续的时间。确认任务时间的两种方法: “一点时间估计法”:确定一个时间值作为完成任务需要的时间 “三点时间估计法”:T=(O+4M+P)/66) 任务的最早开始时间、最晚开始时间及缓冲时间 最早开始时间:(重点) 正推法:按照时间顺序计算最早开始时间和最早完成时间的方法,称为正推法 计算步骤首先建立项目的开始时间项目的开始时间是网络图中第一个活动的最早开始时间从左到右,从上到下进行任务编排当一个任务有多个前置时,选择其中最大的最早完成日期作为其后置任务的最早开始日期 公式:EF =ES(最早开始时间)+Duration(任务历时)ES2= EF1+Lag(滞后时间)1为前置任务,2为后置任务 示例 最晚开始时间: 逆推法(Backward pass):按照逆时间顺序计算最晚开始时间和最晚结束时间的方法,称为逆推法. 计算步骤:首先建立项目的结束时间项目的结束时间是网络图中最后一个活动的最晚结束时间从右到左,从下到上进行计算当一个前置任务有多个后置任务时,选择其中最小最晚开始日期作为其前置任务的最晚完成日期 公式:LS= LF-DurationLF1= LS2-Lag1为前置任务,2为后置任务 示例 缓冲时间:任务最晚开始时间和最早开始时间的差值就是其缓冲时间。 定理:在PERT图的关键路径中,任务的缓冲时间为07) 已获值分析(重点) 基本变量 已完成工作的预算成本:BCWP 计划完成工作的预算成本:BCWS 已完成工作的实际成本:ACWP 确定进度和预算情况 进度偏差:SV=BCWP-BCWSSV=0:按进度进行; SV0:进度超前。 进度效能指标:SPI=BWCP/BCWSSPI=1:按进度进行; SPI1:进度超前。 成本偏差:CV=BCWP-ACWPCV=0:按预算进行; CV0:低于预算。 成本状况指标:CPI=BCWP/ACWPCPI=1:按预算进行; CPI1:低于预算。 利用EVA进行预测 项目完成时的预算(BAC)即总的预算成本 项目完成时的成本估算值(EAC)即预计的项目总成本 EAC=BAC/CPI 项目完成时的进度(SAC)即预计的项目持续时间 SAC=(初始计划的项目持续时间)/SPI 项目完成时的偏差(VAC)即预算的最终成本差 VAC= BAC-EAC4. 案例分析开发计划任务工作量/日预计完成日期(第几周内)确立任务31规格说明22设计输出105计划测试36编码实现57单元测试38集成测试29确认测试310总计31计划工作量周次到该周为止计划获取的工作量周次到该周为止计划获取的工作量1361825723378264119285151031第3周结束时的已获值分析任务工作量/日完成百分比已获值确立任务3100%3规格说明250%1设计输出1025%2.5计划测试300编码实现500单元测试300集成测试200确认测试300总计310.65(BCWP)1) 基本度量计算BCWP=6.5工作日BCWS=7工作日,ACWP=10工作日2) 进度分析:进度偏差SV=BCWP-BCWS=-0.5,进度落后了进度效能指标SPI=BCWP/BCWS=0.928,进度92.8%成本偏差CV=BCWP-ACWP=-0.35,超出预算成本状况指标 CPI=BCWP/ACWP=0.65,超出预算35%3) 基本度量计算完成项目需要的时间 SAC=(初始计划的项目持续时间)/SPI=10/0.928=10.7周11周完成项目需要的费用 EAC=BAC/CPI=31/0.65=47.7 48工作日完成项目的成本偏差 VAC=总的预算成本-EAC=31-48=-17工作日4) 分析按照目前项目进展情况分析,项目完成将推迟一周完成,且费用超出预算35%第七章1. 软件项目风险管理概述1) 风险管理的4个层次 危机管理:是在风险已经造成麻烦后才着手处理它们。 风险缓解:事先制定好风险发生后的补救措施,但不制定任何的防范措施。 着力预防:将风险识别与风险防范作为软件项目的一部分加以规划和执行。消灭根源:识别和消灭可能产生风险的根源。2. 风险识别1) 风险条目检查表(概念)风险条目检查表是最常用也是比较简单的风险识别方法,它是利用一组提问来帮助管理者了解项目在各方面有哪些风险。 在风险条目检查表中,列出了所有可能的与每一个风险因素有关的提问,使得风险管理者集中来识别常见的、已知的和可预测的风险。 风险条目检查表一般根据风险要素进行编写,包括项目的环境、管理层的重视度、技术情况以及内部因素。3. 本章小结1) 风险管理计划包括确定风险管理的目标、制定风险管理策略、定义风险管理过程以及风险管理验证等。2) 核对清单、德尔菲法、会议法是风险识别的主要工具与技术。3) 风险应对策略包括:避免、转移、缓解、接受、研究、储备以及回避等。第八章1. 软件项目监控和报告体系建立项目监控和报告体系的首要任务是项目信息跟踪采集。跟踪采集是依据规定的规范对项目开发过程中的有关数据进行收集和记录,作为观察分析项目性能、标识偏差的依据。1) 跟踪采集过程 跟踪采集主要是在项目生存期内,根据项目计划中规定的跟踪频率按照规定的步骤对项目管理、技术开发和质量保证活动进行跟踪 目的是监控项目实际情况,记录反映当前项目状态的数据 属于项目度量实施过程2) 建立跟踪采集对象 确立采集对象:采集对象主要是对项目有重要影响的内部和外部因素。 内部因素:指项目基本可以控制的因素,例如变更、范围、进度、成本、资源、风险等 外部因素:指项目无法控制的因素,比如法律法规、市场价格、外汇牌价等 一般要根据项目的具体情况选择采集对象。如果项目比较小,可以集中在进度、成本、资源、产品质量等内部因素;

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论