目录
项目管理定义及通俗理解：
定义：使项目能够按照预定的成本、进度、质量、顺利完成并让所有干系人得到满意，而对成本、人员、进度、质量、风险等进行分析和管理的活动。
通俗理解：假设我们要做一件事，有一定的约束和目标要求，诸如时间、资金、人力、等条件限制，那么如何在这些约束条件下有效的达到我们预想的目标，通过相关的理念、技术方法和工具进行管理的过程就是项目管理。
框架：
五大标准化过程组
1.启动阶段：项目的可行性分析、立项、招投标、合同签署等
2.计划阶段：范围定义、进度安排、资源安排、成本估价、质量保证计划、风险计划、实施计划等
3.实施及控制阶段：项目实施、进度控制、费用控制、质量控制、变更控制等
4.结束阶段：范围确认、质量验收、费用结算与审计、项目资料验收、项目交接与清算、项目审计与评估、项目总结等
一.项目启动
项目类型：
合同项目：招投标、合同谈判、甲乙双方有合同约束。参考项目”xxx合同书“
内部项目：确定任务范围和相关人员进行有效的配合，无合同约束。
1.初始项目分析
项目可行性分析：根据市场、技术、人员等各资源分析项目的可行性，对分析结果进行认证讨论。
项目范围分析：确定项目的功能模块、边界范围等。
项目干系人分析：分析确定项目相关人员包括：项目发起人，项目开发人员、测试人员、维护人员、客户等
2.生存期模型
瀑布模型：
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
优点：
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
缺点：
1）在项目各个阶段之间极少有反馈。
2）只有在项目生命周期的后期才能看到结果。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
适用：项目的需求明确、解决方案也很明确，适合短期项目
原型模型：
核心思想：在限定的时间内，用最经济的方法开发出一个可实际运行的系统模型，用户在运行使用整个原型的基础上，通过对其评价，提出改进意见，对原型进行修改，统一使用，评价过程反复进行，使原型逐步完善，直到完全满足用户的需求为止
开发步骤：
1、快速分析：在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型所要体现的特征描述基本需求以满足开发原型的需要。
2、构造原型：在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、坚固性、例外处理等等，主要考虑原型系统能够充分反映所要评价的特性，而暂时删除一切次要内容。
3、运行原型：这是发现问题、消除误解、开发者与用户充分协调的一个步骤。
4、评价原型：在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见。
5、修改：根据评价原型的活动结果进行修改。若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。
适用：项目开始前，项目的需求不明确，需要减少项目需求的不确定性，类似的项目如：第一次开发的产品，验证可行性
增量模型：
增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。
使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。把软件产品分解成增量构件时，唯一必须遵守的约束条件是，当把新构件集成到现有构件中时，所形成的产品必须是可测试的。
增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。
适用：1.项目开始，明确了需求的一部分，但是需求可能会发生变化。
2.对于市场和用户把握不是很准，需要逐步了解
3.对于庞大和复杂功能的系统进行功能改进，需要一步一步实施的。
3.项目立项
项目章程：确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。
立项申请报告：明确项目的目标、时间、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可。
召开项目立项会：通常由公司PMO(项目管理办公室)组织立项会，对项目的调研、范围、项目经理等进行确定授权，评审，最后要有评审报告
二、项目计划
范围计划
项目范围：项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。
wbs任务分解
工作分解结构（Work Breakdown Structure，简称WBS）就是把一个项目按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
即：项目→任务一工作一日常活动
工作分解结构以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。
wBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。
工作包
WBS的最低层次的项目可交付成果称为工作包（WorkPackage），具有以下特点：
工作包可以分配给另一位项目经理进行计划和执行。
工作包可以通过子项目的方式进一步分解为子项目的WBS.工作包可以在制定项目进度计划时，进一步分解为活动。
工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包（Commi tment Package） 。
工作包的定义应考虑80小时法则（80—HourRule）或两周法则（TwoWeek Rule），即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。
任务分解原则
1、将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
2、每个任务原则上要求分解到不能再细分为止；
3、日常活动要对应到人、时间和资金投入
进度计划
进度是对执行的活动和里程碑制定的工作计划日期表。
进度管理是为了确保项目按期完成所需要的过程。
按时完成项目是项目经理最大的挑战之一。
时间是项目规划中灵活性最小的因素。
进度问题是项目冲突的主要原因，尤其在项目的后期。
进度计划管理过程
●活动定义：确定为完成项目的各个交付成果所必须进行的诸项具体活动
●活动排序：确定任务依赖、前置任务、里程碑(里程碑显示项目进展中的重大工作完成)
●活动历时估计：每个任务的历时估计、项目总历时估计，可采用定额算法、经验算法。
●任务资源估计：每个任务需要的资源类型和数量有一定的考虑， 这些资源包括，人力资源，设备资源，以及其它资料资源
关键路径与里程碑
●关键路径
关键路径是项目计划中最长的路线。它决定了项目的总实耗时间。项目经理必须把注意力集中于那些优先等级最高的任务，确保它们准时完成，关键路径.上的任何活动的推迟将使整个项目推迟。向关键路径要时间，向非关键路径要资源。所以在进行项目操作的时候确定关键路径并进行有效的管理是至关重要的。
●里程碑
在进度时间表上设立一些重要的时间检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进度进行检查和控制。这些重要的时间检查点被称作项目的里程碑。
成本计划
资源计划编制:确定项目需要的资源种类和数量。
成本估算:编制一个为完成项目各活动所需要的资源成本的近似估算。
软件项目规模：软件项目规模即工作量，是从软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务。包括:软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。
成本估算
●直接成本：与具体项目相关的成本.
●间接成本：不能具体到某个项目中的成本，可以分摊到各个具体项目中的成本，例如:培训、房租水电、员工福利、市场费用、管理费、其他等等。
质量计划
质量定义：
质量是满足要求的程度,包括符合规定的要求和满足顾客的需求.
软件质量是软件满足明确说明或者隐含的需求的程度
明确说明:查询功能
隐含说明:查询速度
代码质量活动
静态分析：不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态测试技术。
动态测试(Test)：单元测试、集成测试、系统测试
缺陷追踪：使用项目管理工具(如ClearQuest)跟踪缺陷解决程度
人力资源计划
职能型：
职能型组织结构是目前最普遍的项目组织形式。它是一个标准的金字塔型组织形式
这个组织结构适用于主要由一个部门完成的项目或技术比较成熟的项目。
优点：
1)以职能部门作为承担项目任务的主体，可以充分发挥职能部门的资源集中优势，有利于保障项目需要资源的供给和项目可交付成果的质量。
2)职能部门内部的技术专家可以同时被该部门承担的不同项目同时使用，节约人力，减少了资源的浪费。
3)同一职能部门内部的专业人员便于相互交流、相互支援，对创造性地解决技术问题很有帮助。
4)当有项目成员调离项目或者离开公司，所属职能部门可以增派人员，保持项目的技术连续性。
5)项目成员可以将完成项目和完成本部门的职能工作融为一体，可以减少因项目的临时性而给项目成员带来的不确定性。
缺点：
1)客户利益和职能部门的利益常常发生冲突，职能部门会为本部门的利益而忽视客户的需求。
2)当项目需要多个职能部门共同完成，或者一个职能部门内部有多个项目需要完成时，资源的平衡就会出现问题。
3)当项目需要由多个部门共同完成时，权力分割不利于各职能部门之间的沟通交流、团结协作。
4)项目成员在行政上仍隶属于各职能部门的领导，项目经理对项目成员没有完全的权利，项目经理需要不断地同职能部门经理进行有效的沟通以消除项目成员的顾虑。
项目型
项目型组织结构中的部门完全是按照项目进行设置，是一种单目标的垂直组织方式。
在项目型组织中，每个项目就象一个微型公司那样运行。完成每个项目目标所需的所有资源完全分配给这个项目，专门为这个项目服务。采用项目型组织的公司不生产标准产品，它的经营业务就是项目。
优点：能控制资源；向客户负责。
缺点：成本低效、项目间缺乏知识信息交流。
矩阵型
矩阵型组织结构是职能型组织结构和项目型组织结构的混合体，既具有职能型组织的特征，又具有项目型组织结构的特征。
它是根据项目的需要，从不同的部门中选择合适的项目人员组成一个临时项目组，项目结束之后，这个项目组也就解散了，然后各个成员回到各自原来的部门，团队的成员需要向不同的经理汇报工作。这种组织结构的关键是项目经理需要具备好的谈判和沟通技能，项目经理与职能经理之间建立友好的工作关系。项目成员需要适应于两个上司协调工作。加强横向联结，充分整合资源，实现信息共享，提高反应速度等方面的优势恰恰符合当前的形势要求。这种组织结构适用于管理规范、分工明确的公司或者跨职能部门的项目。
优点：
（1）将企业的横向与纵向关系相结合，有利于协作生产。
（2）针对特定的任务进行人员配置有利于发挥个体优势，集众家之长，提高项目完成的质量，提高劳动生产率。
（3）各部门人员的不定期的组合有利于信息交流，增加互相学习机会，提高专业管理水平。
缺点：
（1）项目负责人的责任大于权力，因为参加项目的人员都来自不同部门，隶属关系仍在原单位，只是为"会战"而来，所以项目负责人对他们管理困难，没有足够的激励手段与惩治手段，这种人员上的双重管理是矩阵结构的先天缺陷；
（2）由于项目组成人员来自各个职能部门，当任务完成以后，仍要回原单位，因而容易产生临时观念，对工作有一定影响。
（3）由于项目一般涉及较多的专业，而项目负责人对项目的成败具有举足轻重的作用，所以要求项目负责人具有较高的协调能力和丰富的经验，但是优秀的项目负责人比较难找到。
沟通计划
项目沟通的基本原则:及时性、准确性、完整性、可理解性
风险计划
风险的定义:损失发生的不确定性;对潜在的，未来可能发生损害的一种度量。
风险的三要素:一个事件、事件发生的概率、事件的影响。
风险管理的基本程序包括风险识别、风险估测、风险评价、风险控制和风险管理效果评价等环节。
1．风险的识别：是经济单位和个人对所面临的以及潜在的风险加以判断、归类整理，并对风险的性质进行鉴定的过程。
2．风险的估测：是指在风险识别的基础上，通过对所收集的大量的详细损失资料加以分析，运用概率论和数理统计，估计和预测风险发生的概率和损失程度。风险估测的内容主要包括损失频率和损失程度两个方面。
3．风险管理方法：分为控制法和财务法两大类，前者的目的是降低损失频率和损失程度，重点在于改变引起风险事故和扩大损失的各种条件；后者是事先做好吸纳风险成本的财务安排。
4．风险管理效果评价：风险管理效果评价是分析、比较已实施的风险管理方法的结果与预期目标的契合程度，以此来评判管理方案的科学性、适应性和收益性。
三、项目的实施与控制
1.项目实施与控制
项目跟踪控制过程：
2.配置管理
定义：记录软件产品的演化过程。确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置。最终保证软件产品的完整性、一致性、追溯性、可控性。
配置项
软件配置项是项目需定义其受控于软件配置管理的款项。
系统规格说明书、软件需求规格说明书、设计规格说明书、源代码、测试规格说明书
软件需求规格说明书：需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。
3.需求分析
4.系统设计
5.系统开发
6.系统测试
四、项目结束
成功与失败的标准：1.可交付成果如何2.是否实现目标3.是否达到项目业主的期望
完成收尾工作：范围确认、项目验收、费用结算、合同终结。
项目结束评审：是否实现项目目标；是否遵循项目进度；是否在预算成本内完成项目；项目进度过程中出现的突发问题以及解决措施是否合适问题是否得到解决；从该项目的实践中可以得到哪些经验和教训。