软件项目管理【知识点总结】

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

增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

适用：1.项目开始，明确了需求的一部分，但是需求可能会发生变化。2.对于市场和用户把握不是很准，需要逐步了解3.对于庞大和复杂功能的系统进行功能改进，需要一步一步实施的。

4.项目立项

项目经理的角色

项目组织的领导者、管理者、决策者、分析者、计划者、控制者、组织者、评价者、协调者。

项目经理的责任

项目计划；组织实施；项目控制

项目立项(相关文档)
---->项目章程：确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等
---->项目立项申请报告：明确项目的目标、时间、项目使用的资源和经费，而且得到执行该项目经理和项目发起人的认可
---->召开项目立项会：通常由公司PMO(项目管理办公室)组成立项会，对项目调研、范围、项目经理等进行确定授权、评审，最后要有评审报告

三、项目计划

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

1.范围计划

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

wbs任务分解

工作分解结构（Work Breakdown Structure，简称WBS）就是把一个项目按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。即：项目→任务一工作一日常活动

工作分解结构以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。

wBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

工作包：

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

2.进度计划

进度是对执行的活动和里程碑制定的工作计划日期表。
进度管理是为了确保项目按期完成所需要的过程。
按时完成项目是项目经理最大的挑战之一。
时间是项目规划中灵活性最小的因素。进度问题是项目冲突的主要原因，尤其在项目的后期。

进度计划管理过程
---->活动定义：确定为完成项目的各个交付成果所必须的诸项具体活动
---->活动排序：去欸的那个任务依赖、前置任务、里程碑(里程碑显示项目进展种的重大工作完成)
---->活动历时估计：每个任务的历时估计、项目总历时估计，可采用定额算法、经验算法
---->任务资源估计：每个任务需要的资源类型和数量有一定的考虑，这些资源包括：人力资源、设备资源、其他资料资源

关键路径：关键路径是项目计划中最长的路线。它决定了项目的总实耗时间。项目经理必须把注意力集中于优先等级最高得任务，确保它们准时完成，关键路径上得任何活动得推迟将使整个项目推迟。向关键路径要时间，向非关键路径要资源。所以再进行项目操作的时候确定关键路径并进行有效的管理是至关重要的。

里程碑：在进度时间表上设立一些重要的事件检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进度进行检查和控制。这些重要的时间检查点被称作项目的里程碑。

3.成本计划

1.资源计划编制：确定项目需要的资源种类和数量
2.成本估算：编制一个为完成项目各活动所需要的资源成本的近似估算
3.软件项目规模：软件项目规模即工作量，是从如软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务。包括：软件规划，软件管理，需求，设计，编码，测试以及后期的维护等任务

规模的单位：
---->LOC(Loc of Code):源代码程序长度的测量，单位K代码行
---->FP(Function Point):用系统的功能数量来测量
---->人月(一人在一月完成的功能月)
---->人天
---->人年
5.软件的规模和成本的关系：规模是成本的而主要因素，是成本估算的基础
6.估算：算法不是很准确的，有误差的；经验(历史)数据非常重要；不要太迷信数学模型
7.成本估算：直接估算(与具体项目相关的成本)；简介成本(不能具体到某个项目中的成本，可以分摊到各个具体项目中的成本，例如培训、房租水电、员工福利等)

4.质量计划

质量的多种定义：

符合目的或者用途
用户的感觉就是质量
符合顾客在其合理价格下对产品的要求
产品或者服务满足明确和隐含需要能力的性能特性的总体

质量定义：质量是满足要求的程度，包括符合规定的要求和满足顾客的需求
软件质量：软件满足明确说明或者隐含的需求的程度。如：
---->明确说明：查询功能
---->隐含说明：查询速度
质量的重要性：软件危机的主要矛盾；低质量的软件就像定时炸弹；低质量的产品增加成本；质量是生命也是信誉
质量管理过程：

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

5.人力资源计划

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

职能型

职能型组织结构是目前最普遍的项目组织形式。它是一个标准的金字塔型组织形式。这个组织结构适用于主要由一个部门完成的项目或技术比较成熟的项目。

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

项目型

在项目型组织中，每个项目就象一个微型公司那样运行。完成每个项目目标所需的所有资源完全分配给这个项目，专门为这个项目服务。采用项目型组织的公司不生产标准产品，它的经营业务就是项目。

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

矩阵型

它是根据项目的需要，从不同的部门中选择合适的项目人员组成一个临时项目组，项目结束之后，这个项目组也就解散了，然后各个成员回到各自原来的部门，团队的成员需要向不同的经理汇报工作。这种组织结构的关键是项目经理需要具备好的谈判和沟通技能，项目经理与职能经理之间建立友好的工作关系。项目成员需要适应于两个上司协调工作。加强横向联结，充分整合资源，实现信息共享，提高反应速度等方面的优势恰恰符合当前的形势要求。这种组织结构适用于管理规范、分工明确的公司或者跨职能部门的项目。

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

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

6.沟通计划

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

7.风险计划

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

四、项目的实施与控制

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

1.项目实施与控制

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

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

2.配置管理

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

找不到某个文件的历史版本
开发人员使用错误的版本修改程序
开发人员未经授权修改代码或文档
人员流动，交接工作不彻底
已修复的Bug在新版本中出现
无法重新编译某个历史版本
因协同开发中，或者异地开发，版本变更混乱导致整个项目失败

配置管理定义：记录软件产品的演化过程；确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置；最终保证软件产品的完整性，一致性，追溯性，可控性
作用：版本管理、变更管理
配置项：软件配置项是项目定义其受控于软件配置管理的款项。(即管理内容)包括：系统规格说明书；软件需求规格说明书；设计规格说明书；源代码；测试规格说明书；
配置项版本：

工具：ClearCase、SVN、VSS、CVS等
配置管理委员会：配置项标识、跟踪；配置管理环境建立；变更管理；配置状态统计；配置管理计划

3.需求分析

软件需求：需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。

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

4.系统设计

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

5.系统开发

6.系统测试

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

五、项目结束

项目结束包括项目结束和系统维护两方面

1.成功与失败的标准

可交付成果如何；是否实现目标；是否达到项目业主的期望

2.制定结束要做的工作

---->指定结束计划(项目计划的一部分，与客户一同评审项目结束计划，细化并实施项目结束计划)
---->完成收尾工作：范围确认，项目验收，费用结算，合同终结
---->项目结束评审(内部评审)：是否实现项目目标，是否遵循项目进度，是否在预算成本内完成项目，项目进度过程中出现的问题以及解决措施是否合适，问题是否得到解决，从该项目的事件中可以得到哪些经验和教训
---->项目总结：总结成功的经验和失败的教训；软件项目历程文件(将项目中的有用信息总结分类，放入信息库，它是软件项目记录的资料)