软件项目管理(学习笔记)

1.项目与项目管理

项目

1.项目：项目是一次性的、以目标为导向的（目标明确）、通过项目经理及其团队工作完成的、存在大量的变更管理。
2.项目的特点：

有明确的目标性
明确的时限性
资源成本的约束性
项目的不确定性
唯一性(一次性)
3.项目的定义：是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的活动。

项目管理

1.项目管理通俗理解：假设要做一件事情，有一定的约束和目标要求，诸如时间、资金、人力等条件限制，那么如何在这些约束条件有效地达到我们预想地目标，通过相关的理念、技术方法和工具进行管理的过程就是项目管理。
2.项目管理的定义：使项目能够按照预定的成本、进度、质量顺利完成让所有干系人（相关的人）得到满意，而对成本、人员、进度、质量、风险等进行分析和管理的活动。

2.项目管理框架

五大标准化过程组

1.启动阶段：项目的可行性分析、立项(确定可以做)、招投标、合同签署
2.计划阶段：范围定义、进度安排、资源计划、成本估计、质量保证计划、风险计划、实施计划等
3.实施及控制阶段：项目实施、进度控制、费用控制、质量控制、变更控制等
4.结束阶段：范围确认、质量验收、费用结算与审计、项目资料验收、项目交接与清算、项目审计与评估、项目总结等

十大知识领域

1.项目整合管理
2.项目范围管理
3.项目时间管理
4.项目成本管理
5.项目质量管理
6.项目人力资源管理
7.项目沟通管理
8.项目风险管理
9.项目采购管理
10.项目干系人管理

四十七个过程

3.项目启动

项目类型：
1.合同项目：招投标(招标和投标)、合同谈判、合同签署，甲乙双方有合同约束
2.内部项目：确定任务范围和相关人员进行有效地配合，无合同约束
3.项目干系人分析：分析确定项目相关人员，包括：项目发起人、项目开发人员、测试人员、维护人员、客户等

初始化项目分析

1.可行性项目分析：根据市场、技术、人员等各资源分析项目地可行性，对分析结果进行认证讨论。
2.项目范围分析：确定项目的功能模块、边界范围等
3.项目干系人分析：分析确定项目相关人员，包括：项目发起人、项目开发人员、测试人员、维护人员、客户等

生存期模型(常用)

1.瀑布模型：通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。

瀑布模型适合项目的需求很明确、解决方案也很明确的短期项目。
2.原型模型：原型模型即样品模型，先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。
原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程种难以对用户的反馈做出快速的响应。

原型模型适用于在项目开始前，项目的需求不明确的的项目。
3.增量模型：增量模型融合了瀑布模型的基本成分(重复应用)和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

增量模型适用于在项目开始前，明确了需求的一部分，但是需求可能会发生变化、对于时常和用户把握不是很准，需要逐步了解、对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的项目。

项目立项

1.项目经理的角色：项目组织的领导者、管理者、决策者、分析者、计划者、控制者、组织者、评价者、协调者。
2.项目经理的责任：项目计划；组织实施；项目控制
3.项目立项(相关文档)
---->项目章程：确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等
---->项目立项申请报告：明确项目的目标、时间、项目使用的资源和经费，而且得到执行该项目经理和项目发起人的认可
---->召开项目立项会：通常由公司PMO(项目管理办公室)组成立项会，对项目调研、范围、项目经理等进行确定授权、评审，最后要有评审报告

4.项目计划

项目计划包括：范围计划、进度计划、成本计划、质量计划、人力资源计划、沟通计划、风险计划

项目计划的重要性：

范围计划

项目范围的管理是对项目应该包括什么和不包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围的合适。

WBS任务分解
WBS(工作分解结构)就是将一个项目按一定的原则分解，项目分解成任务，任务再分解成一项项的工作，再把每一项工作分配到每个人的日常活动种，直到分解不下去为止
即：项目—>任务----->工作----->日常活动
工作分解结构以交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。
WBS总是处于计划过程的中心，也是制动进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

工作包：WBS最底层的项目可交付成果称为工作包(不能再细分的任务)
工作包特定：
1.工作包可以分配给另一位项目经理进行计划和执行
2.工作包可以通过项目的方式进一步分解为子项目的WBS
3.工作包可以由唯一的一个部门或承包商负责。用于在组织之外分包时，称为委托包。
工作包的定义应考虑80小时或两周法则，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。
任务分解原则
1.将主题目标逐步细化分解，最底层的日常活动可直接分派到个人去完成
2.每个任务原则上要求分解到不能再细分为止
3.日常活动要对应到人、时间和资金投入
任务分解标准
1.分解后的活动结构清晰，从树根到树叶一目了然，尽量避免盘根错节
2.逻辑上形成一个大的活动，集成了所有的关键因素包含临时的里程碑和监控点，所有活动全部定义清楚，要细化到人、时间和资金投入
WBS任务分解实例

进度计划

进度是对执行的活动和里程碑指定的工作计划日期表。
进度管理是为了确保项目按期完成所需要的过程。
按时完成项目是项目经理最大的挑战之一。
时间是项目规划种灵活性最小的因素。(时间问题不可商量)
进度问题是项目冲突的主要原因，尤其子啊项目的后期。
1.进度计划管理过程
---->活动定义：确定为完成项目的各个交付成果所必须的诸项具体活动
---->活动排序：去欸的那个任务依赖、前置任务、里程碑(里程碑显示项目进展种的重大工作完成)
---->活动历时估计：每个任务的历时估计、项目总历时估计，可采用定额算法、经验算法
---->任务资源估计：每个任务需要的资源类型和数量有一定的考虑，这些资源包括：人力资源、设备资源、其他资料资源
2.关键路径：关键路径是项目计划中最长的路线。它决定了项目的总实耗时间。项目经理必须把注意力集中于优先等级最高得任务，确保它们准时完成，关键路径上得任何活动得推迟将使整个项目推迟。向关键路径要时间，向非关键路径要资源。所以再进行项目操作的时候确定关键路径并进行有效的管理是至关重要的。
3.里程碑：在进度时间表上设立一些重要的事件检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进度进行检查和控制。这些重要的时间检查点被称作项目的里程碑。

成本计划

1.资源计划编制：确定项目需要的资源种类和数量
2.成本估算：编制一个为完成项目各活动所需要的资源成本的近似估算
3.软件项目规模：软件项目规模即工作量，是从如软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务。包括：软件规划，软件管理，需求，设计，编码，测试以及后期的维护等任务
4.规模的单位：
---->LOC(Loc of Code):源代码程序长度的测量，单位K代码行
---->FP(Function Point):用系统的功能数量来测量
---->人月(一人在一月完成的功能月)
---->人天
---->人年
5.软件的规模和成本的关系：规模是成本的而主要因素，是成本估算的基础
6.估算：算法不是很准确的，有误差的；经验(历史)数据非常重要；不要太迷信数学模型
7.成本估算：直接估算(与具体项目相关的成本)；简介成本(不能具体到某个项目中的成本，可以分摊到各个具体项目中的成本，例如培训、房租水电、员工福利等)

质量计划

1.质量的多种定义：

符合目的或者用途
用户的感觉就是质量
符合顾客在其合理价格下对产品的要求
产品或者服务满足明确和隐含需要能力的性能特性的总体
2.质量定义：质量是满足要求的程度，包括符合规定的要求和满足顾客的需求
3.软件质量：软件满足明确说明或者隐含的需求的程度。如：
---->明确说明：查询功能
---->隐含说明：查询速度
4.质量的重要性：软件危机的主要矛盾；低质量的软件就像定时炸弹；低质量的产品增加成本；质量是生命也是信誉
5.质量管理过程：

6.质量保证：确定项目应达到的质量标准；决定如何满足质量标准的计划安排和方法；通过评价项目整体效绩，建立对质量要求的新人；提供项目和产品可视化的管理报告
7.代码质量活动
---->静态分析：不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态测试技术。
---->动态测试：单元测试、集成测试、系统测试
---->缺陷追踪：使用项目管理工具(如ClearQuest)跟踪缺陷解决程度
8.需要有质量计划文档

人力资源计划

1.组织结构的主要类型:职能型;项目型;矩阵型

职能型

优点：
1.可以充分发挥职能部门的资源集中优势
2.部门的专家可以同时为部门内不同项目使用
3.便于相互交流，相互支援
4.可以随时增派人员
5.可以将项目和本部门的职能工作融为一体
缺点：
1.项目和部门发生利益冲突，职能部门更重视本部门的目标、会忽视项目目标
2.资源平衡会出现问题
3.权力分隔不利于各个职能部门的交流和团结协作
4.行政隶属关系使得项目经理没有充足的权利

项目型

优点：
1.项目经理对项目可以负全责
2.项目目标单一，可以以项目为中心，有利于项目顺利进行
3.避免多重领导
4.组织结构简单，交流简单，快速
缺点：
1.资源不能共享
2.各个独立的项目处于相对封闭状态，不利于公司政策的贯彻
3.对项目组织的成员缺少一种事业上的连续性和安全感
4.项目组织之间处于分隔状态，缺少信息交流

矩阵型

优点：
1.专职的项目经理负责整个项目，以项目为中心
2.公司的多个项目可以共享各个职能部门的资源
3.即利于项目目标的实现，又利于公司目标方针的贯彻
4.项目成员的顾虑减少了
缺点：
1.容易引起职能经理和项目经理权力的冲突
2.资源共享也能引起项目之间的冲突
3.项目成员有多头领导

2.人员管理计划：人员管理计划描述了项目团队的组织结构，团队成员及角色、成员加入到团队和离开团队的时间、人员培训计划等。作为项目计划一部分，详细程度因项目而异。

沟通计划

1.基本原则：及时性；准确性；完整性；可理解性
2.沟通方式：书面沟通和口头沟通；语言沟通和非语言沟通(UML)；正式沟通和非正式沟通；单向沟通和双向沟通；网络沟通
3.沟通计划编制：沟通需求分类；沟通的内容；沟通方法；沟通职责；沟通进度；沟通计划维护

风险计划

1.定义：损失发生的不确定性；对潜在，未来可能发生的损害的一种度量
2.风险的三要素：一个事件；事件发生的概率；事件的影响
3.风险类型
---->预测角度：已知风险；可预测风险；不可预测风险
---->范围角度：项目风险；技术风险；商业风险
4.风险管理的四个过程：风险识别---->风险评估---->风险规划----->风险控制----->风险识别
5.风险识别：
---->风险识别领域：产品规模；商业影响；客户相关；过程定义；开发技术；开发环境；人员数目及经验
---->识别方法(结合使用)：头脑风暴法；情景分析法；面谈法；风险条目检查表
6.风险评估：确定风险发生概率的估计和评价，项目风险后果严重程度的估计和评价，项目风险影响范围的分析和评价，以及对项目风险发生时间的估计和评价
7.风险规划
---->风险概率值：没有可能(0)；确定(1)
---->风险概率度量：高、中、低；极高、高、中、低、极低；不可能、不一定、可能和极可能等等
8.风险后果：风险影响项目目标的严重程度；从无影响到无穷大
---->风险后果度量：高、中、低；极高、高、中、低、极低；灾难、严重、轻微、可忽略等等
8.风险控制：针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而指定风险应对策略和应对措施的过程，即指定一定的行动和策略来对付、减少、以至于消灭风险事件
9.风险措施
---->回避风险：对所有可能发生的风险尽可能的规避，采用主动放弃或者拒绝使用导致风险的方案。例如采用新技术
---->转移风险：为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法。例如出售、分包。
---->损失控制：损失预防、损失抑制
---->自留风险：由项目组织自己承担风险事故所致损失的措施

5.项目实施与控制

项目实施与控制---->配置管理---->需求分析---->系统设计---->系统开发---->系统测试

项目实施与控制

1.项目实施与控制核心：产品规格/质量，进度，成本
2.项目跟踪控制过程：

3.项目跟踪控制程度：项目中可以接受出现偏差；注意力应放在紧急的必须要解决的问题上。
参与项目进展报告，周例会会议纪要。(控制项目进度)

配置管理

软件项目中可能遇到如下问题：

找不到某个文件的历史版本
开发人员使用错误的版本修改程序
开发人员未经授权修改代码或文档
人员流动，交接工作不彻底
已修复的Bug在新版本中出现
无法重新编译某个历史版本
因协同开发中，或者异地开发，版本变更混乱导致整个项目失败
配置管理定义：记录软件产品的演化过程；确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置；最终保证软件产品的完整性，一致性，追溯性，可控性
作用：版本管理、变更管理
配置项：软件配置项是项目定义其受控于软件配置管理的款项。(即管理内容)包括：系统规格说明书；软件需求规格说明书；设计规格说明书；源代码；测试规格说明书；
配置项版本：
工具：ClearCase、SVN、VSS、CVS等
配置管理委员会：配置项标识、跟踪；配置管理环境建立；变更管理；配置状态统计；配置管理计划
软件需求：需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。

软件需求规格说明书:需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书；需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，实质成为整个软件开发的基础。
需求总在变化解决方案：确定需求变更控制过程；建立需求变更控制委员会(SCCB);进行需求变更你影响分析；跟踪所有收需求变更影响的工作产品；建立需求基准版本和需求控制版本文档；维护需求变更的历史记录；跟踪每项需求的状态；衡量需求稳定性

系统设计

系统设计包括概要设计和详细设计

测试

测试包括：单元测试；集成测试；系统测试

6.项目结束

项目结束包括项目结束和系统维护两方面
1.成功与失败的标准：可交付成果如何；是否实现目标；是否达到项目业主的期望
2.制定结束要做的工作：
---->指定结束计划(项目计划的一部分，与客户一同评审项目结束计划，细化并实施项目结束计划)
---->完成收尾工作：范围确认，项目验收，费用结算，合同终结
---->项目结束评审(内部评审)：是否实现项目目标，是否遵循项目进度，是否在预算成本内完成项目，项目进度过程中出现的问题以及解决措施是否合适，问题是否得到解决，从该项目的事件中可以得到哪些经验和教训
---->项目总结：总结成功的经验和失败的教训；软件项目历程文件(将项目中的有用信息总结分类，放入信息库，它是软件项目记录的资料)

7.案例分析