同步操作将从 fakerlove/Software-Project-Management 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
软件项目管理
项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力
目标性
相关性
周期性
独特性
没有完全一样的项目”,项目的这种独特性对实际项目管理有非常重要的指导意义,因此软件的项目管理业具备了一定的独特性。
约束性
不确定性
软件项目是抽象的,因此软件项目的管理具有不确定性
结果的不可逆转性
项目的三大特点:临时性、独特性和渐进明细性。
项目管理是以项目为对象,通过使用知识、技能、工具和方法来组织、计划、实施并监控项目,使之满足项目目标需求的过程。
项目的范围约束 项目的范围就是规定项目的任务是什么?作为项目经理,首先必须搞清楚项目的商业利润核心,明确把握项目发起人期望通过项目获得什么样的产品或服务。对于项目的范围约束,容易忽视项目的商业目标,而偏向技术目标,导致项目最终结果与项目干系人期望值之间的差异。 因为项目的范围可能会随着项目的进展而发生变化,从而与时间和成本等约束条件之间产生冲突,因此面对项目的范围约束,主要是根据项目的商业利润核心做好项目范围的变更管理。既要避免无原则的变更项目的范围,也要根据时间与成本的约束,在取得项目干系人的一致意见的情况下,合理的按程序变更项目的范围。
项目的时间约束 项目的时间约束就是规定项目需要多长时间完成,项目的进度应该怎样安排,项目的活动在时间上的要求,各活动在时间安排上的先后顺序。当进度与计划之间发生差异时,如何重新调整项目的活动历时,以保证项目按期完成,或者通过调整项目的总体完成工期,以保证活动的时间与质量。在考虑时间约束时,一方面要研究因为项目范围的变化对项目时间的影响,另一方面要研究,因为项目历时的变化,对项目成本产生的影响。并及时跟踪项目的进展情况,通过对实际项目进展情况的分析,提供给项目干系人一个准确的报告。
项目的成本约束
项目的成本约束就是规定完成项目需要花多少钱。对项目成本的计量,一般用花费 多少资金来衡量,但也可以根据项目的特点,采用特定的计量单位来表示。关键是通过成本核算,能让项目干系人,了解在当前成本约束之下,所能完成的项目范围及时间要求。当项目的范围与时间发生变化时,会产生多大的成本变化,以决定是否变更项目的范围,改变项目的进度,或者扩大项目的投资。 在我们实际完成的许多项目中,多数只重视项目的进度,而不重视项目的成本管理。一般只是在项目结束时,才交给财务或计划管理部门的预算人员进行项目结算。对内部消耗资源性的项目,往往不做项目的成本估算与分析,使得项目干系人根本认识不到项目所造成的资源浪费。因此,对内部开展的一些项目,也要进行成本管理。
无规则、混乱的开发状态,进度滞后,费用超支等失败的例子很多 业务失败,合同纠纷,法律诉讼,客户投诉等困扰软件业。
简述:
概念(Concept) 开发(Development) 实施(Implementation) 结束(Termination)
启动--> 计划--> 控制---> 结束
计划和控制为重点
合同是使卖方负有提供具体产品和服务的责任,买方负有为该产品和产品服务付款的责任的一种双方相互负有义务的协议。
软件项目合同主要是技术合同
技术合同是法人之间、法人和公民之间、公民之间以技术开发、技术转让、技术咨询和技术服务为内容,明确相互权利义务关系所达成的协议;
技术合同有三种环境:需(甲)方环境、供(乙)方环境和内部环境; 技术合同一般包括主合同和合同附件。
企业在需方合同环境下,关键要素是提供准确、清晰和完整的需求,选择合格的供方并对采购对象(采购对象包括产品服务、人力资源等)进行必要的验收。 这个需求可能来自于企业内部的需要,也可能是在为客户开发的软件项目中的一部分,通过寻找合适的软件开发商,将部分软件外包给其他的开发商。
招标书定义(采购需求定义) 启动一个项目主要是由于存在一种需求,招标书定义主要是需方的需求定义,也就是甲方(买方)定义采购的内容。
招标书主要内容可分为三大部分:程序条款、技术条款、商务条款。
包含下列主要九项内容:1、招标邀请函;2、投标人须知;3、招标项目的技术要求及附件;4、投标书格式;5、投标保证文件;6、合同条件(合同的一般条款及特殊条款);7、技术标准、规范;8、投标企业资格文件;9、合同格式。
流程如下:
需方申请
需求定义
商务条件确定
验收标准确定
资料汇集
采购需求认可
编写招标文件
招标文件
供方选择 招标文件确定后,就可以通过招标的方式选择供方(乙方或者卖方)。
流程如下:
招标文件
招标
手机供方的建议书
评定供方
最终供方确定
供方名单
建议书
合同文本准备 如果需方选择了合适的供方(软件开发商),需方应该与供方(软件开发商)签订一个具有法律效力的合同;签署合同之前需要起草一份合同文本。
采购资料
合同草案指定
合同草案评审
合同草案修订
合同草案确定
合同草案
合同签署过程就是正式签署合同,使之成为具有法律效力的文件; 同时,根据签署的合同,分解出合同中需方(甲方)的任务,并下达任务书,指派相应的项目经理负责相应的过程。
对于企业处于需方(甲方)的环境,合同管理是需方对供方(乙方)执行合同的情况进行监督的过程,
主要包括: 对需求对象(采购对象)的验收 验收过程是需方对供方交付的产品或服务进行验收检验,以保证它满足合同条款的要求。 对违约事件处理 在合同的执行过程中,如果供方发生与合同要求不一致的问题,导致违约事件,需要执行违约事件处理过程。
验收过程
违约处理
当项目满足结束的条件,项目经理或者合同管理者应该及时宣布项目结束,终止合同的执行,通过合同终止过程告知各方合同终止
过程
企业在供方(乙方)合同环境下,关键要素是了解清楚需方(甲方)的要求并判断企业是否有能力来满足这些需求。 作为软件开发商,更多担任的是供方的角色。
在合同终止过程中,供方应该配合需方的工作,包括:项目的验收、双方认可签字、总结项目的经验教训、获取合同的最后款项、开具相应的发票、获取需方的合同终止的通知、将合同相关文件归档。
过程
企业内部项目实施管理的核心是确定任务范围和确保相关各方进行有效的配合,这可以通过相关各方之间的“协议”来保证,此处“协议”可视为“合同”。
企业内部项目“合同”无特别的商业约束。
总结
软件项目技术合同的执行过程可以划分为四个阶段,即:合同准备、合同签署、合同管理与合同终止。
针对企业在不同合同环境中承担的不同角色,又可将合同管理分为需方合同管理、供方合同管理及内部合同管理。
作为软件企业,一般是处于供方(乙方)的角色,因此,软件企业的项目经理应该重点掌握供方(乙方)的合同管理过程。
合同标志一个项目的真正开始,通过项目任务单明确项目经理,从此,项目经理可以真正行使相应的职责和权力。
为了保证软件产品的质量,1991年美国卡内基·梅隆大学软件工程研究所(CMU/SEI)将软件过程成熟度框架进化为软件能力成熟度模型(Capability Maturity Model For Software,简称SW-CMM),并发布了最早的SW-CMM 1.0版。 SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架,阶梯共有五级。
(1)初始级(initial)。工作无序,项目进行过程中常放弃当初的计划。管理无章法,缺乏健全的管理制度。开发项目成效不稳定,项目成功主要依靠项目负责人的经验和能力,他一但离去,工作秩序面目全非。
(2)可重复级(Repeatable)。管理制度化,建立了基本的管理制度和规程,管理工作有章可循。初步实现标准化,开发工作比较好地按标准实施。变更依法进行,做到基线化,稳定可跟踪,新项目的计划和管理基于过去的实践经验,具有重复以前成功项目的环境和条件。
(3)已定义级(Defined)。开发过程,包括技术工作和管理工作,均已实现标准化、文档化。建立了完善的培训制度和专家评审制度,全部技术活动和管理活动均可控制,对项目进行中的过程、岗位和职责均有共同的理解。
(4)已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势,如预测偏差,实现及时纠正。
(5)优化级(Optimizing)。可集中精力改进过程,采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据,并可据进行分析,从而得出最佳方法
概念描述
软件过程
是指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。
软件开发过程管理
是指在软件开发过程中,除了先进技术和开发方法外,还有一整套的管理技术。
是针对软件生产过程中会对产品质量产生影响的问题而进行的,它的直接结果是软件过程能力的提高。 现在常见的软件过程改进方法:ISO 9000,SW-CMM和由多种能力模型演变而来的CMMI。
除第一级外,SW-CMM的每一级都是按完全相同的结构组成的。每一级包含了实现这一级目标的若干关键过程域(KPA),每个KPA进一步包含若干关键实施活动(KP),无论哪个KPA,它们的实施活动都统一按六个公共属性进行组织,即每一个KPA都包含六类KP:
由于不同领域能力成熟度模型存在不同的过程改进,重复的培训、评估和改进活动以及活动不协调等一些问题。于是由美国国防部出面,美国卡内基·梅隆大学软件工程研究所(CMU/SEI)于2001年12月发布的CMMI 1.1版本包括四个领域:软件工程(SW)、系统工程(SE)、集成的产品和过程开发(IPPD)、采购(SS)。
所谓“ISO9000”不是指一般意义上的一个质量保证标准,而是一族系列标准的统称。
软件从需求确定、设计、开发、测试直至投入使用,并在使用中不断地修改、增补和完善,直至被新的系统所替代而停止该软件的使用的全过程。
可划分为以下子阶段
1.可行性研究
2.需求分析和定义
3.总体设计
4.详细设计
5.编码(实现)
6.软件测试、运行维护
**据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量模型等。**本节分别对这几种传统的软件开发生命周期模型予以介绍。
容易理解,管理成本低;强调开发的阶段性早起计划及需求调查和产品测试。软件项目较小
为避免一次性投资太多带来的风险
融合了瀑布模型和原型的迭代特征。
每一个增量均发布一个可操作产品。
较短的时间向用户提交有用的功能
逐步增加产品的功能
项目失败风险低
优先级最高的服务首先交付,意味着软件马上就能使用
如果没有对用户的变更要求进行规划,那么产生的初始增量可能会造成后来增量的不稳定;
如果需求不像早期思考的那样稳定和完整,那么一些增量就可能需要重新开发;
管理发生的成本、进度和配置的复杂性,可能会超出组织的能力。
Word 字处理软件
教务系统
这个模型可看作是重复执行的多个瀑布模型。
螺旋模型将瀑布模型和演化模型结合起来,加入了两种模型均忽略的风险分析,弥补了这两种模型的不足。
甲方提供了详细,准确的需求文档,我们的解决方案也是很明确,且安全性要求非常的严格.
2001年,为了避免许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些敏捷开发过程的方法:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme Programming,简称XP)。
极限编程将开发阶段的4个活动(分析、设计、编码和测试)混合在一起,在全过程中采用迭代增量开发、反馈修正和反复测试。
软件质量
是“所有描述计算机软件优秀程度的特性的组合”
软件质量度量模型有三层组成
识别哪些质量标准适用于软件项目,并确定如何满足这些标准的需求
指为保证产品,过程或服务质量,满足规定(或潜在)的要求,有组织机构,职责,程序,活动,能力和资源等构成的有机整体
描述企业质量体系的文件
质量管理的第一过程域
软件项目团队管理就是运用现代化的科学方法,对项目组织结构和项目全体参与人员进行管理,在项目团队中开展一系列科学规划、开发培训、合理调配、适当激励等方面的管理工作,使项目组织各方面人员的主观能动性得到充分发挥,以实现项目团队的目标。
项目团队是软件项目中最重要的因素,成功的团队管理是软件项目顺利实施的保证
软件项目开发团队是通过将不同的个体组织在一起,形成一个具有团队精神的高效率的队伍来进行软件项目的开发
团队组织计划
指确定、记录与分派项目角色、职责,并对请示汇报关系进行识别、分配和归档。 团队人员获取 指获得项目所需的并被指派到项目的人力资源(个人或集体)。
团队建设
既包括提高利害关系者作为个人做出贡献的能力,也包括提高项目团队作为集体发挥作用的能力。
个人的培养(管理能力与技术水平)
是团队建设的基础。团队的建设是项目实现其目标的关键。
大多数软件项目中,组织计划是在最早的项目阶段编制的。 组织计划编制的结果应在整个项目过程中定期审查以保证其连续的适用性。 如果初始的组织编制不再有效,应及时修正。
软件项目经理
软件企业最基层的管理人员,负责分配资源、确定优先级、协调与客户之间的沟通,尽量使项目团队一直集中于正确的目标。 项目经理需要领导、决策、组织、控制和创新方面的能力。
系统分析员
主要从事需求获取和研究,是项目中业务与技术间的桥梁。 系统分析员应该善于简化工作、善于协调,并且具有良好的人际沟通和书面沟通技巧,必须具备业务和技术领域知识,需要熟悉用于获取业务需求的工具,同时还要掌握引导客户描述出需求的方法。
系统设计员
根据软件需求说明书进行构架设计、数据库设计和详细设计,负责在整个项目中对技术活动和工件进行领导和协调。
软件开发人员
负责按照项目所采用的标准来进行单元开发与测试。 软件开发人员需要能够迅速并准确地理解系统设计员的设计文档,并能快速地进行代码开发和单元测试。
系统测试人员
负责对测试进行计划、设计、实施和评估。
软件配置管理人员
负责策划、协调和实施软件项目的正式配置管理活动的个人或小组。
质量保证人员
负责计划和实施项目质量保证活动的个人或小组,以确保软件开发活动遵循软件过程标准。
定义和分配工作的过程是在项目启动阶段开始运作并且是重复进行的。一旦项目组决定了采用的技术方法,他们将建立一个工作分解结构图(WBS)来定义可管理的工作要素。接着,他们指定活动定义,进一步确定WBS中各个活动所包含的工作,最后指派工作。
RAM 就是将工作分解结构图(WBS)中的每一项工作指派给OBS中的执行人而形成的一个矩阵。
项目的组织结构,是具体承担某一项目的全体职工为实现项目目标,在管理工作中进行分工协作,在职务范围、责任、权力方面所形成的结构体系。
职能结构,
即完成项目目标所需的各项业务工作及其比例和关系;
层次结构,
即各管理层次的构成,又称为组织的纵向结构;
部门结构,
即各管理部门的构成,又称为组织的横向结构;
职权结构
即各层次、各部门在权力和责任方面的分工及相互关系。
在实际的项目管理中,主要有三种基本的项目组织形式——直线性、职能性和矩阵形。
优点
可以防止多重指令和防止双头管理现象的出现,对于一个部门来说可以避免出现接收多个相互矛盾指令的情况。
缺点
缺少安全感
在职能组织结构中,工作部门的设置是按照专业职能和管理业务来划分的.
1
优点
职能组织结构有利于发挥职能部门的专业管理作用和专业管理专长,能适应生产技术发展和间接管理复杂化的特点。
缺点
但如果多维指令产生冲突,则将使得下级部门无所适从,容易造成管理混乱。
直线型组织职能结构(直线型+职能型)
直线型组织职能结构在职能组织结构的基础上引入线性组织结构在命令源上单一和一致性的优点,可以防止组织中出现矛盾的指令,同时,保持线性指挥的前提下,在各级领导部门下设置相应的职能部门,分别从事各项专门业务。
矩阵组织结构的主要特点是按两大类型设置工作部门。其命令源是非线性的,因而横向管理部门和纵向管理部门各自负责的工作和管理内容必须明确。
通过组织计划编制过程决定了软件项目所需的人员之后,需要做的就是确定如何在合适的时间获得这些人员。
在项目经理确定之后,项目经理就要与公司相关人员一起商讨如何通过招聘流程获取项目所需的人力资源,这种招聘过程可以是面向内部员工,也可以面向社会人力资源。
软件项目团队的组建工作包括:团队成员的到位和项目组内部的组织结构、角色分配和任务分工。
就是团队成员为了团队的整体利益和目标而相互合作、共同努力的意愿与作风。
按时按预算开发出满足用户真实需要的软件
一个软件项目的开始阶段。在软件工程中,需求分析阶段是 包括客户、用户、业务或需求分析员、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者在内的所有的风险承担者都需要参与的阶段。
IEEE软件工程标准词汇表(1997年)中将需求定义为: 用户解决问题或达到目标所需的条件或权能(Capability); 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能; 一种反映上面(1)或(2)所描述的条件或权能的文档说明。
在UP(统一过程)中,软件需求是根据FURPS+模型来分类的,其中FURPS的含义如下:
也叫做需求过程或需求阶段,包括需求开发和需 求管理。
包括需求获取、需求分析、编写需求规格说明、验证需求四个阶段,在这四个阶段执行以下活动:
需求获取的主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、系统环境等,对任务进行分析、从而开发、捕获和修订用户的需求,以建立良好的沟通渠道和方式.
需求获取需要执行以下活动:
需求分析包括提炼、分析和仔细审查已收集到的需求,为最终用户所看到的系统建立一个概念模型以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。
分析用户需求应该执行以下活动:
软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础。
需求规格说明模板
1 | 2 | 3 | 4 | 5 | 6 | |
---|---|---|---|---|---|---|
a.引言 | 目的 | 文档约定 | 预期的读者和阅读建议 | 产品的范围 | 参考文献 | |
b. 综合描述 | 产品的前景 | 产品的功能 | 用户类和特征 | 运行 环境 | 设计和实现上的限制 | 假设和依赖附 |
c. 外部接口需求 附录 | 用户界面附录 | 硬件接口 | 软件接口 | 通信 接口 | ||
d. 系统特性 | 说明和优先级 | 激励响应序列 | 功能需求 | |||
e. 其它非 功能需求 | 性能需求 | 安全设施需求 | 安全性需求 | 软件 质量属性 | 业务规则 | 用户文 |
f. 其它需求 | ||||||
g. 附件 | 词汇表 | 分析模型 | 待确定 问题的列 |
验证是为了确保需求说明准确、无二义性并完整地表达系 统功能以及必要的质量特性。 需求验证要求客户代表和开发人员共同参与,对提交后的需求规格说明进行验证,分析需求的正确性,完整性以及可行性等等。
需求验证中的活动一般包括:
是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法,可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。
有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性,以及与其它需求和其它项目工件之间的可追踪性。
内容包括
定义需求基线
评审需求变更并评估每项需求变更对软件产品的影响从而决定是否实施它。
以一种可控制的方式将需求变更融入当前的软件项目。 让当前的项目计划和需求保持一致。
估计变更所产生的影响并在此基础上协商新的约定 实现通过需求可跟踪对应的设计、源代码和测试用例。
在整个项目过程中跟踪需求状态及其变更情况。
需求变更管理是项目管理中非常重要的一项工作。有效的需求变更管理能对变更带来的潜在影响及可能的成本费用进行评估。
需求变更管理中活动一般包括:
简介
软件需求分析者利用场景或经历来描述用户和软件系统的交互方式,并以此来获取软件需求。 使用用例的分析方法来源于面向对象的思想。 用例分析方法最大的特点在于面向用例,在对用例的描述中引入了外部角色的概念。
相关技术 用例需求分析常常采用UML(Unified Modeling Language,统一建模语言)技术,UML是一种面向对象的建模语言。
结构化分析方法(Structured Method,结构化方法)
是强调开发方法的结构合理性以及所开发软件的结构合理性的软件开发方法。
结构化的分析方法的基本步骤为:
具体流程
明确项目所包含的各项工作;项目分解的结果就是WBS (任务分解结构)
WBS(任务分解结构)图是实施项目、创造最终产品或服务所必须进行的全部活动的一张清单,也是进度计划、人员分配、预算计划的基础
项目分解就是先把复杂的项目逐步分解成一层一层的要素(工作),直到具体明确为止
项目分解的工具是工作分解结构WBS原理,它是一个分级的树型结构,是一个对项目工作由粗到细的分解过程
Work Breakdown Structure主要是将一个项目分解成易于管理的几个部分或几个细目,以便确保找出完成项目工作范围所需的所有工作要素它是一种在项目全范围内分解和定义各层次工作包的方法
Work Breakdown Structure结构层次越往下层则项目组成部分的定义越详细,WBS最后构成一份层次清晰,可以具体作为组织项目实施的工作依据
WBS ——Work Breakdown Structure通常是一种面向“成果”的“树”,其最底层是细化后的“可交付成果”,该树组织确定了项目的整个范围。但WBS的形式并不限于“树”状,还有多种形式。
基于可交付成果的划分
基于工作过程的划分
层次结构图和锯齿列表(清单)
由高层向下层用多位码编排,要求每项工作有唯一的编码。
是指预测构造软件项目所需要的工作量以及任务经历时间的过程
规模(即工作量)的估算
确定每个软件功能所必须执行的一系列软件工程任务
成本的估算
确定完成软件项目规模相应付出的代价
进度的估算
估计任务的持续时间,即历时估计
规模估算方法
代码行(LOC,Lines of Code)估算法、功能点(FP,Function Points)估算法和计划评审技术(PERT,Program Evaluation and Review Technique)估算法
成本估算方法
自顶向下(类比)估算法、自下而上估算法、参数估算法、专家估算法、猜测估算法等
进度估算方法
基于规模的进度估算、工程评价技术、关键路径法、专家估算方法、类推估算方法、模拟估算方法、进度表估算方法、基于承诺的进度估算方法和Jones的一阶估算准则等
LOC估算法
代码行可以分为无注释的源代码行(NCLOC, Non-Commented Source Lines Of Code)和注释的源代码行(CLOC: Commented Source Lines Of Code),源代码的总行数LOC即为NCLOC与CLOC之和
FP估算法
功能点度量是在需求分析阶段基于系统功能的一种规模估计方法,该方法通过研究初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目,从而确定功能点数量
静态模型
用一个唯一的变量(如程序规模)作为初始元素来计算所有其他变量(如成本、时间),且所用计算公式的形式对于所有变量都是相同的
动态模型
没有类似静态模型中的惟一基础变量,所有变量都是相互依存的
具体模型讲解
已有的模型 1) Farr-Zagorski模型; 2) Price-S模型;3) Walston-Felix模型 ;4) Putnam模型;5) COCOMO模型
COCOMOⅡ模型
在现代软件工程研究结果的基础上,将未来软件市场划分为基础软件、系统集成、程序自动化生成、应用集成、最终用户编程五个部分,COCOMO II通过三个生命周期模型 (估算早期原型工作量的应用组合模型,早期设计模型,后体系结构模型 )支持上述的五种软件项目。
Putnam模型
Putnam模型是Putnam于1978在来自美国计算机系统指挥部的200多个大型项目(项目的工作量在30~1000人年之间)数据的基础上推导出来的一种动态多变量模型。Putnam模型假设软件项目的工作量分布类似于Rayleigh曲线。Putnam模型包含两个方程:软件方程和人力增加方程。
实用软件估算模型
是一种自下而上和参数法的结合模型,步骤如下: 对任务进行分解 估算每个任务i的最大值Max、最小值Min、最可能值Avg,Ei=(Max +4 Avg + Min)/6(或者使用唯一的估计值:最可能值) 直接成本=E1+E2+……+ Ei+……+ En 项目总估算成本= 直接成本+间接成本 项目总报价=项目总估算成本+风险利润 风险利润=利润+风险基金+税
活动定义(Activity definition)
确定为完成项目的各个交付成果所必须进行的诸项具体活动 完成WBS中的细目和子细目
活动排序(Activity sequencing)
对活动进行适当的顺序安排. 项目各项活动之间存在相互联系与相互依赖关系 根据这些关系安排各项活动的先后顺序
活动历时估计(Activity duration estimating)
制定进度计划(Schedule development)
进度控制(Schedule control)-项目跟踪
网络图、甘特图、里程碑图、资源图
展示项目中的各个活动以及活动之间的逻辑关系; 网络图是活动排序的一个输出;网络图可以表达活动的历时
常用网络图 :PDM:节点法 (单代号)网络图、ADM:箭线法 (双代号)网络图、CDM:条件箭线图法
(Precedence diagram )
(Arrow diagram)
(condition diagram )
关键路径法(CPM)
CPM是根据指定的网络顺序逻辑关系和单一的历时估算,计算每一个活动的单一的、确定的最早和最迟开始和完成日期 计算网络图中完成时间最长的路径 计算浮动时间
正推法
按照时间顺序计算最早开始时间和最早完成时间的方法,称为正推法
逆推法
按照逆时间顺序计算最晚开始时间和最晚结束时间的方法,称为逆推法.
时间压缩法
赶工(Crash)
快速跟进(Fast tracking:搭接)
改变活动间的逻辑关系,并行开展活动
资源调整尝试法
针对关键路径
最早开始时间(Early start)
最晚开始时间(Late start)
最早完成时间(Early finish)
最晚完成时间(Late finish)
自由浮动(Free Float)
在不影响后置任务最早开始时间本活动可以延迟的时间
总浮动( Total Float)
在不影响项目最早完成时间本活动可以延迟的时间
超前(Lead)
滞后(Lag)
浮动时间
浮动时间是一个活动的机动性,它是一个活动在不影响其它活动或者项目完成的情况下可以延迟的时间量 Float>0:时间安排比较合理 Float=0:比较紧张 Float<0:项目进度会推迟
时间压缩法是在不改变项目范围的前提下缩短项目工期的方法
应急法--赶工(Crash)
进度压缩单位成本计算方法
项目成本预算
分配项目成本,进行成本预算
项目的预算成本组成:
成本预算的作用
分配项目成本包括三种情况
调整计划
解决资源冲突的方法
优化进度,缩短工期
调整项目成本预算
风险管理是指在项目进行过程中不断对风险进行识别、评估,制定策略,监控风险的过程。通过风险识别、风险分析和风险评价去认识项目的风险,并以此为基础合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制,妥善处理风险事件造成的不利后果,以最小的成本保证项目总体目标的实现。
风险管理可以分为四个层次:
危机管理:是在风险已经造成麻烦后才着手处理它们。
风险缓解:事先制定好风险发生后的补救措施,但不制定任何的防范措施。
着力预防:将风险识别与风险防范作为软件项目的一部分加以规划和执行。
消灭根源:识别和消灭可能产生风险的根源。
风险管理策略有两种:救火模式和主动模式。
项目实施风险管理的意义可归纳如下:
风险识别
或称风险辨识,是寻找可能影响项目的风险以及确认风险特性的过程。风险识别的目标是:辨识项目面临的风险,揭示风险和风险来源,以文档及数据库的形式记录风险。
风险识别的输入与输出
输入可能是项目的WBS、工作的陈述(Statement Of Work,SOW)、项目相关信息、项目计划假设、历史项目数据,其他项目经验文件、评审报告、公司目标等。风险识别的输出是风险列表。
包括以下活动
风险识别方法的确定 ;风险定义及分类;风险文档编写。
险评估又称风险预测,就是对识别出的风险做进一步分析,对风险发生的概率进行估计和评价,对风险后果的严重程度进行估计和评价,对风险影响范围进行估计和评价,以及对于风险发生时间进行估计和评价。 风险评估可采用定性风险评估和定量风险评估来进行。
具体过程
定性风险评估 定性风险评估主要是针对风险概率及后果进行定性的评估。 例如采用历史资料法、概率分布法、风险后果估计法等。历史资料法主要是应用历史数据进行评估的方法,通过同类历史项目的风险发生情况,进行本项目的估算。
定量风险评估 定量风险评估是一种广泛使用的管理决策支持技术。一般,在定性风险分析之后就可以进行定量风险分析。 定量风险分析过程的目标是量化分析每一个风险的概率及其对项目目标造成的后果,也分析项目总体风险的程度。定量风险评估可以包括以下方法:
定量风险评估 定量风险评估是一种广泛使用的管理决策支持技术。一般,在定性风险分析之后就可以进行定量风险分析。
定量风险分析过程的目标是量化分析每一个风险的概率及其对项目目标造成的后果,也分析项目总体风险的程度。定量风险评估可以包括以下方法:
风险规避
风险规避是改变项目计划来消除特定风险事件的威胁。通常情况下我们可以采用多种方法来规避风险。例如,对于软件项目开发过程中存在的技术风险,我们可以采用成熟的技术,团队成员熟悉的技术或迭代式的开发过程等方法来规避风险;对于项目管理风险我们可以采用成熟的项目管理方法和策略来规避不成熟的项目管理带来的风险;对于进度风险我们可以采用增量式的开发来规避项目或产品延迟上市的风险。对于软件项目需求不确定的风险我们可以采用的原型法来规避风险。
风险转移
风险转移是转移风险的后果给第三方,通过合同的约定,由保证策略或者供应商担保。软件项目通常可以采用外包的形式来转移软件开发的风险,例如发包方面对一个完全陌生领域的项目可以采用外包来完成,发包方必须有明确的合同约定来保证承包方对软件的质量,进度以及维护的保证。否则风险转移很难取得成功。
风险减轻
风险减轻是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在项目的早期采取风险减轻策略可以收到更好的效果。例如,软件开发过程中人员流失对于软件项目的影响非常严重,我们可以通过完善工件,配备后备人员等方法来减轻人员流失带来的影响。
风险接受
准备应对风险事件,包括积极的开发应急计划,或者消极的接受风险的后果。对于不可预见的风险,例如不可抗力;或者在风险规避,风险转移或者风险减轻不可行,或者上述活动执行成本超过接受风险的情况下采用。
保证项目能够按照预先设定的计划轨道行驶,使项目不要偏离预定的发展进程。跟踪控制是一个反馈过程,需要在项目实施的全过程对项目进行跟踪控制。
建立标准
即建立项目正确完成应该达到的目标
观察项目的性能
建立项目监控和报告体系,确定为控制项目所必需的数据
测量和分析结果
将项目的实际结果与计划进行比较
采取必要措施
当实际的结果同计划有误差时,必要时修正项目计划
控制反馈
如果修正计划,应该通知有关人员和部门
不控制的危害
在对项目进行跟踪控制时,应该确定偏差的接受准则,比如进度、成本、质量等计划与实际的偏差比例等。
范围(质量)计划
进度计划
成本计划
建立项目监控和报告体系的首要任务是项目信息跟踪采集。跟踪采集是依据规定的规范对项目开发过程中的有关数据进行收集和记录,作为观察分析项目性能、标识偏差的依据。
采集对象主要是对项目有重要影响的内部和外部因素
其输入是软件项目的计划需求范围(即需求规格)和实际执行过程中的范围及其控制标准。在项目范围控制过程中,通过与计划的需求规格比较,如果出现范围变化,即出现增加/修改/删除部分需求范围,就需要通过范围变更控制系统来实现变更,以保证项目范围在可以接受的范围内进行。
防治不合理的范围扩张
根据跟踪采集的进度、成本、资源等数据,并与原来的基准计划比较,对项目的进展情况进行分析,以保证项目在可以控制的进度、成本、资源内完成。
输入
计划进度、成本、资源 实际进度、成本、资源
方法
图解控制法 挣值分析法
输出
进度、成本、资源修改决定
图解控制法
能清楚确定项目状况,但没有量化信息
挣值分析法(盈余分析法、已获取价值分析法)
Eared Value Analysis 利用成本会计评估项目进展情况的一种方法,可以提供更多量化的信息
通过质量跟踪的结果来判断项目执行过程的质量情况,决定产品是否可以接受,还是需要返工或者放弃产品。
项目评审是通过一定的方式对项目进行评价和审核的过程,通过项目评审,
按活动类别分
按时间类别分
项目评审结束后需要将评审的结果以评审报告的形式进行发布。评审报告包括定期评审报告、事件评审报告和阶段(里程碑)评审报告。
这个系统包括四个环节,即建立基线计划、信息采集、信息处理、信息输出。
根据评审结果决定是否修改项目计划 修改计划过程
当项目接近生命期末期时,项目资源开始转向其他活动或项目,项目经理和项目团队成员所面临的工作也开始转向项目收尾活动。
范围确认
项目接收前,重新审核工作成果,检验项目的各项工作范围是否完成,或者完成到何种程度,最后,双方确认签字
质量验收
质量验收是控制项目最终质量的重要手段,依据质量计划和相关的质量标准进行验收,不合格不予接收
费用决算
费用决算是指对从项目开始到项目结束全过程所支付的全部费用进行核算,编制项目决算表的过程
合同终结
整理并存档各种合同文件
资料验收
检查项目过程中的所有文件是否齐全,然后进行归档
项目结束中一个重要的过程是项目的最后评审,它是对项目进行全面的评价和审核。
作为项目验收的标准,一般选用项目合同书;也有选用国标、行业标准和相关的政策法规、国际惯例等。
对项目进行验收时, 主要依据项目的工作成果和成果文档。
从项目验收的内容划分,项目验收范围通常包括质量验收和文件验收。
项目质量验收
项目质量永远是考查和评价项目成功与否的重要方面。一个项目的最终目的是满足客户的需求,这种需求是以质量保证为前提的,必须从项目计划、项目控制、项目验收等不同环节严把质量关
项目文件验收
项目文件是项目整个生命周期的详细记录,是项目成果的重要展示形式。项目文件既作为项目评价和验收的标准,也是项目移交、维护和后期评价的重要原始凭证
项目验收完成后,如果验收的成果符合项目目标规定的标准和相关的合同条款及法律法规,参加验收的项目团队和项目接收方人员应在事先准备好的文件上签字。这时项目团队与项目业主的项目合同关系基本结束,项目团队的任务转入对项目的支持和服务阶段
当项目通过验收后,项目团队将项目成果的所有权交给项目接收方,这个过程就是项目的移交 。当项目的实体移交、文件资料移交和项目款项结清后,项目移交方和项目接收方将在项目移交报告上签字,形成项目移交报告
**项目验收是项目移交的前提;移交是项目收尾的最后工作内容,是 项目管理的完结。 **
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。