软件项目管理1-7章

第一章 项目管理概述

1.项目的定义：项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。

2.项目的特征：①明确目标②相关性③限定周期④独特性⑤约束成本资源⑥不确定性

3.项目、日常运作的共同点：①人来完成②有限资源限制③需要计划、执行、控制

4.项目、日常运作的不同点：①项目一次性，日常运作重复进行②项目以目标为导向，日常运作由效率和有效性体现③项目通过经理和团队完成，日常运作是职能式线性管理④项目大量变更管理，日常运作基本持续连贯

5.软件项目要素（3个）：①软件开发过程，②软件开发结果，③软件开发资源和项目特定委托人

6.客户，既是项目结果的需求者，也是项目实施资金提供者

7.项目目标实现制约因素（4个）：项目范围S，成本C，进度计划T，客户满意度Q

8.项目管理定义：项目管理是一系列的伴随着项目的进行而进行的、目的是为了确保项目能够达到期望的结果的一系列管理行为。

9.软件项目管理：①软件工程组成部分②确保软件项目满足预算，成本等约束，提交高质量软件产品。

10.项目管理铁三角：时间，质量，成本

11.软件项目管理的根本目的：让软件项目尤其是大型项目的生命周期在管理者的控制之下，以预定成本按期、按质地完成软件项目并交付用户使用

12.研究软件项目管理的目的：总结前人原则、方法，从而避免前人的失误

13.软件项目五个过程组：

项目计划，项目控制，项目执行是核心控制组

 

14.PMBOK：项目管理知识体系指南

PMP：项目管理专业人员资格

15.PMI：对项目管理所需的知识、技能和工具进行的概括性描述

16.过程管理：对过程进行管理，目的是让过程能够被共享、复用，并得到持续的改进

 简而言之，过程管理：总结-＞复用，过程改进：优化

17.敏捷模型：①敏捷组织提出的一个灵活开发方法②应对迅速变化需求的快速软件开发方法③是一种迭代、循序渐进的开发方法

18.敏捷开发过程：慢慢改进

19.敏捷宣言（4价值）：①个体和互动高于流程和工具②可工作的软件高于详尽的文档③客户合作高于合同谈判④响应变化高于遵循计划

20.敏捷原则

 21.软件项目的特殊性（4个）：①逻辑实体②相互作用的系统③渐进明细④变更

22.敏捷原则：比较务实的一种原则

23.甲方和乙方：甲方--需求、买方 ；乙方--供应、卖方

第二章 项目初始-项目确立

1.项目初始包括两个方面：项目确立和生存期

2.项目立项启动背景：①合法②满足相关方需求③创造改进或修复产品、过程或服务④执行、变更业务或技术战略

3.项目立项的内容：明确项目的目标、时间表、项目使用的资源和经费，并获得项目经理和项目发起人的认可（立项三因素：目标、时间、费用）

4.Make or Buy决策（自造-购买决策）

包含三种：采购（选择供应商->签定合同->验收），自主研发，外包开发(选择承包商->签订合同->过程监控->验收)

5.项目招投标过程：甲方招标书定义->乙方项目分析->招标与竞标->合同签署

6.甲方主要任务（3个）：1.招标书定义2.供方选择3.合同签署

7.乙方主要任务：项目选择

8.乙方包括三个过程（3个）：项目分析、竞标、合同签署

9.招标书主要包括（3部分）：技术说明，商务说明，投标说明

10.招标的方式（4个）：公开招标，有限招标，多方洽谈，直接谈判

11.项目章程（任务书）：正式的授权项目，项目正式开始的标志

12.授权书：确认项目存在的文件，包含对项目的确认、都项目经理的授权和项目目标的概述

13.敏捷项目章程基本要素：项目目标，发布标准，预期的工作流

14.项目经理的职责：开发计划->组织实施->项目控制，领导团队实现项目目标

15.敏捷强调：仆人式领导方式

16.项目经理的能力：技术项目管理，领导力，战略和商务管理

第三章-项目初始-生存期

1.软件开发模型变迁：作坊式->过程控制->敏捷->DevOps

2.预测模型：瀑布模型、V模型：需求很明确，方案很明确，前者适用于短期，后者适用于系统性能、安全等有严格要求

3.迭代模型（原型模型）：需求不明确，项目复杂性高且频繁变更

4.增量模型：需求基本明确，可能发生变化，对于市场和用户要逐步了解，系统改造要一步一步实施

5.渐进式阶段模型优点：阶段式提交一个可运行的产品，关键的功能更早出现，早期预警问题，避免缺陷蔓延，阶段性完成可以降低估计失误

6.敏捷方法：是一个囊括了各种框架和方法的函数性术语

7.Scrum模型：先进开发方法。敏捷模型的代表

8.产品订单（产品目标）：按照优先级排列的需要完成的工作的概要的需求（目标）

9.迭代开发过程：迭代计划会->迭代->每天站会->迭代评审会议->迭代回顾会

10.XP模型：极限编程模型。一套针对业务需求和软件开发实践的规则

11.XP实施原则：①快速反馈②假设简单③包容变化

12.精益（Lean）：精益模式提倡持续不断地改进，减少流程中的浪费

13.持续交付：持续集成->持续部署->持续交付

14.DevOps：融合一系列基本原则和实践的方法论。用于促进开发、技术运营和质量保障部门之间的沟通协作和整合。

15.DevCloud：一站式云端

16.燃尽图：

第四章-软件需求

1.软件需求：起着承上启下的作用

2.软件需求的定义：需求是指用户对软件的功能和性能的要求

3.软件需求管理的过程：软件需求开发+软件需求管理

4.需求分析：为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述

5.理解需求的过程：将现实生活中的物理模型抽象为逻辑模型，实例化为物理模型，物理模型具体化为目标系统。

6.需求分析完成的标志：形成一个完整的、规范的需求规格说明书

7.需求验证：明确用户需求

8.需求变更管理：①确定需求变更控制过程②建立变更控制委员会（SCCB）③需求变更影响分析④跟踪所有受变更影响的工作产品⑤建立需求基准版本和需求控制版本文档⑥维护需求变更历史记录⑦跟踪每项需求的状态⑧衡量需求稳定性

9.需求建模基本方法：①原型方法②基于数据流建模③基于UML建模

10.原型方法：快速获取用户需求的方法

11.基于数据流-结构化分析方法：①面向数据流方法②自顶向下逐步求精③根据软件内部数据传递、变换的关系进行分析的

12.基于数据流的技术：数据流图（DFD），数据字典（DD），系统流程图

13.面向对象的用例分析：

①基于面向对象的情景分析方法

②从用户角度出发考虑的功能需求

③用例是系统向用户提供一个有价值的结果的某项功能

14.UML需求视图：用例视图、顺序图、状态图、活动图

15.敏捷需求建模方法：

渐进明细

开发的时候是模糊的，然后越来越明确

story cards

功能需求和非功能需求

通过讨论循序渐进的方法进行确定，可以User story进行描述

16.MED需求管理案例：①需求确认：软件需求规格②需求变更：变更控制流程

第五章 任务分解

1.任务分解是项目管理的基础

2.任务分解过程：将一个项目分解为更多的工作项目或子项目，使项目变得更小，更易管理、更易操作

3.任务分解结果：WBS（任务分解结构）

4.需求拆分以获取范围灵活性

5.WBS：1️⃣是对项目由粗到细的分解过程2️⃣面相交付成果的3️⃣WBS组织并定义了整个项目范围

6.工作包（Work packages）：WBS的最低层次可交付成果，由唯一主体负责

7.任务分解的方法：1️⃣模板参照法2️⃣类比法3️⃣自顶向下4️⃣自底向上

8.模板参照法：标准或半标准的WBS作为模板参考使用

9.类比法：WBS经常被重复使用，有些项目具有相似性

10.自顶向下：（一般到特殊）

11.自底向上：特殊到一般

12.任务分解基本步骤：1️⃣确认并分解项目的组成要素（WBS编号）2️⃣确定分解标准（分解的标准要统一）3️⃣确定分解是否详细：是否可以作为费用和时间的估计标准4️⃣确定项目交付成果（可以编制WBS字典）5️⃣验证分解的正确性

13.项目的各组成元素的编码都是唯一的

14.分解标准应统一：

不能同时使用两种标准进行分解

15.WBS字典：WBS的具体工作阐述，包括对工作包的阐述，明确WBS组件是什么

16.检验分解结果的标准：最底层的要素是否实现目标的充要条件2️⃣最底层要素是否有重复3️⃣每个要素是否清晰完整定义4️⃣最底层要素是否有清晰的负责人5️⃣是否可以进行成本估算和进度安排

17.WBS分解建议：1️⃣最底层不必过细2️⃣每个工作包必须有一个提交物3️⃣定义任务完成标准4️⃣有利于责任分配5️⃣推荐任务分配到40小时以内，敏捷项目分解到小时

18.敏捷项目的任务分解：基于story的分解方法，敏捷任务分解输出

敏捷项目注释：敏捷任务分解中，基于story的分解方法是指将项目需求按照用户故事（User Story）进行细化和组织。用户故事是一种描述产品功能或特性的方式，它以用户的角度出发，简洁地表述其期望得到的价值或完成某个目标所需的功能。

在基于story的分解过程中，主要包含以下关键概念和步骤：

Epics：
Epics是大型的、高层次的需求叙述，通常代表一组相关的用户故事，它们共同实现一个较大的业务目标或功能领域。Epics是对项目整体愿景或产品路线图的概括性表达，由于其规模较大，不适合直接进入开发，需要进一步拆分为更小的、可管理的部分。

Epics breakdown：
将Epics进行细化分解的过程称为Epics breakdown。通过此过程，将每个Epic分解成多个具体的、独立的用户故事。这些用户故事应满足以下特点：

- 独立性：每个故事应尽可能独立于其他故事，以便在开发过程中可以单独进行设计、编码、测试和部署。
- 有价值：每个故事应为用户或利益相关者带来明确的业务价值或用户体验改善。
- 可估算：开发团队应能相对准确地评估故事的工作量，以便进行优先级排序、规划迭代（Sprint）和跟踪进度。
- 可测试：每个故事应有明确的验收标准，使得完成的故事可以通过具体的测试用例进行验证。

Product (Sprint) Backlog：
基于story的分解输出形成了产品的待办事项列表——Product Backlog。在敏捷框架如Scrum中，Product Backlog会被进一步细化为Sprint Backlog，用于指导当前迭代（Sprint）的工作。随着项目的进展和对需求理解的深入，Product Backlog会逐步完善，包含更多详细、具体且优先级排序的用户故事。

总结来说，基于story的分解方法是敏捷项目管理中的一种重要实践，它通过将项目需求组织成用户故事的形式，确保需求清晰、聚焦用户价值，并支持敏捷团队进行高效的需求管理、迭代规划和持续交付。

第六章 成本计划

1.估算：①估算不是很准确②项目经验数据非常重要③不要太迷信某些数学模型

2.软件项目规模：即软件工作量

3.软件规模单位：①LOC（源代码长度测量）②FP（用系统的功能数量来测量）③人月/人天/人年（一个人一月/天/年完成的工作量）

4.软件项目成本：①完成软件规模相应付出的代价②待开发的软件项目需要的资金③人的劳动的消耗所需要的代价是软件产品的主要成本

5.规模是成本的主要因素，是成本估算的基础。有了规模就确定了成本

6.成本估算的结果：①直接成本②间接成本

 7.估算基本（传统）方法：①代码行估算法②功能点估算法③用例点估算法④类比（自顶向下）估算法⑤自下而上估算法⑥三点估算法⑦参数估算法⑧专家估算法

8.代码行估算法：最早，最简单的估算法

 9.代码行技术的主要优点：①代码是所有软件开发项目都有的产品②很容易计算代码行数

10.代码行技术的缺点：①没有公认标准定义②数量依赖于个人编程风格③项目早期很难准确估算④编码工作量只是项目实现的一部分

11.功能点（FP）估算法：①与实现语言和技术没有关系②用系统的功能数量来测其规模③通过评估、加权、量化得出功能点

12.功能点公式；FP=UFC*TCF

UFC：未调整功能点计数； TCF：技术复杂度因子

13.功能技术项（从处理逻辑的角度）：①外部输入EI②外部输出EO③外部查询EQ④外部接口文件EIF⑤内部逻辑文件ILF

①外部输入EI：给软件提供面向应用的数据的项（屏幕、表单、对话框、控制、文件）；数据穿越外部边界进入到系统内部

②外部输出EO：向用户提供（经过处理的）面向应用的信息，如报表和出错信息

③外部查询EQ：外部查询是一个输入引出一个即时的简单输出。没有处理过程

④外部接口文件EIF：用户可以识别的一组逻辑相关数据，这组数据只能被引用。用这些接口把信息传送给另一个系统

⑤内部逻辑文件ILF：用户可以识别的一组逻辑相关数据，而且完全存在于应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目

 14.UFC-未调整功能点计数：

 

 15.TCF技术复杂度因子

 

 

 

 16.用例点（UCP）估算法步骤：

①计算未调整的角色权值UAW

②计算未调整的用例权值UUCW

③计算未调整的用例点UUCP

④计算技术和环境因子TEF（包括技术复杂度因素TCF和环境因素ECF）

⑤计算调整的用例点UCP（UCP=UUCP*TCF*ECF）

⑥计算工作量（man-hours）（effort=UCP*PF）

 

 

 

 

17.类比（自顶向下）估算法（了解即可）

18.自下而上估算法：利用任务分解图（WBS），对各个具体工作包进行的详细成本估算，然后将结果累加起来得出项目总成本。

19.自下而上估算法特点：①相对准确，它的准确度来源于每个任务的估算情况②花费时间

20.三点估算法：基于任务成本的三种估算值来计算预期成本的方法。

21.参数估算法：①使用条件：1）具有良好的项目数据为基础2）存在成熟的项目估算模型

                           ②特点：1）比较简单，比较准确2）如果模型选择不当或数据不准会导致偏差

 参数模型有面向LOC驱动的和面向FP（功能点）驱动的

22.参数模型整体公式：

 LOC:代码行，FP：功能点，KLOC：千行代码

23.参数估算法两种模型：Walston-Felix模型，COCOMO模型

 

24.COCOMO模型：①结构化成本模型②是目前应用最广泛的参数型软件成本估计模型，由Barry Boehm团队开发的

 

25.COCOMO两种模型：COCOMO81 ，COCOMO II

26.COCOMO81模型级别：基本（静态单变量模型），中等（在基本上考虑影响因素，调整模型），高级（中等基础上考虑各个步骤影响）

     COCOMO81项目类型：有机Organic，嵌入式Embedded，半嵌入Semidetached

 

 

 

 

 27.COCOMO II组成

28.参数模型综述：①根据项目模型进行回归分析，得出回归模型作为参数模型②回归分析法：线性回归，多项式回归，逻辑回归，神经网络，集成方法③参数模型可以是线性的也可以是非线性的

29.模型研究例子：①项目数据②项目数据图③多项式回归拟合方法

30.专家估算法：多位专家进行成本估算，最后得出综合的估算值

31.敏捷估算思维：①采取轻量级估算方法快速生成高层级估算②短期规划可以进行详细的估算

32.Story point（故事点）用来度量一个Story需要付出的工作量相对估算。

33.

 33.实用软件估算步骤：

 

 34.总估算成本（BAC）

35.成本预算：将项目的总成本按照项目的进度分摊到各个工作单元中去，目的是产生成本基线

36.估算（BAC）与预算（BCWS）

 37.分配项目成本预算三种情况：①给任务分配资源成本②给任务分配固定资源成本③给任务分配固定成本

①给任务分配资源成本：常规方法，与资源费率相关

②分配固定资源成本：如项目中一个兼职人员的成本

③分配固定成本：如项目中某些外包成本是固定的

38.成本基线：在编制成本预算中应提供成本基线。成本基线是每个时间段内的成本，它是项目管理者度量和监控项目的依据。

39.①开发成本=内部成本+外包成本

②管理成本=开发成本*10%

③直接成本=开发成本+管理成本

④间接成本=直接成本*20%

⑤总估算成本=直接成本+间接成本

40.①未调整的用例点UUCP=UAW（未调整角色权值）+UUCW（未调整用例权值）

②技术复杂度因子TCF=0.6+（0.01*∑TCF）

③环境复杂度因子ECF=1.4-0.03*∑ECF

④用例点UCP=UUCP*TCF*ECF

⑤规模Effort=UCP*PF（项目生产率）

1人天=8小时

 

第七章 进度计划

1.进度管理的目标是在给定的限制条件下，用最短时间、最少成本、以最小风险完成项目工作。

2.好的项目管理者是好的时间管理者

3.进度计划的重要性：①按时完成项目是项目经理最大的挑战之一（按时完成难）②时间是项目规划中灵活性最小的因素（时间灵活性小） ③进度问题是项目冲突的主要原因

4.进度的定义：进度是对执行的活动和里程碑指定的工作计划日期表

5.任务活动在本章认为指代相同

6.任务定义：完成具体交互成果所对应项目过程中的活动

7.任务关联关系：根据各项活动之间存在一定的关联关系，根据这些关系安排任务之间的顺序

8.任务之间的关系

 9.任务之间关联关系的依据（4种）

①强制性依赖关系（硬逻辑/硬依赖）：法律、合同、工作内在性质，客观限制

②选择性依赖关系（软逻辑/首选逻辑/优先逻辑）：根据主观意志去调整和确定的项目活动的关系

③外部依赖关系：项目活动和非项目活动之间的依赖关系，不在团队控制之内

④内部依赖关系：项目活动之间的关系，通常在项目团队掌控之中

 10.进度管理图示：①网络图②甘特图③里程碑图④资源图⑤燃尽图⑥燃起图

11.网络图：a.是活动安排的一个输出 b.展示项目中各个活动以及活动之间的逻辑关系

12.常见网络图：PDM（优先图法，节点法（单代号）网络图），ADM（箭线法（双代号）网络图）

13.PDM：①构成PDM网络图的基本特点是节点（Box）②节点表示活动（任务）③用箭头表示个任务之间的逻辑关系④方便表示活动之间的逻辑关系

 

14.ADM：①箭线表示活动（任务）②两个代号唯一确定一个任务③代号（圆圈）表示前一任务的结束，同时也表示后一任务的开始

 为什么有虚线：创建一个虚活动避免与两个代号唯一确定一个任务冲突

15.虚活动（保证两个代号唯一确定一个任务）：①为了定义活动②为了表示逻辑关系③不消耗资源和时间

16.甘特图：任务工期、开始时间、结束时间、资源信息

17.里程碑图示：①时间要求为零的任务②是一个标志性事件③仅表示事件的标记，不消耗资源和时间

 18.资源图：显示项目进展中资源的分配情况

19.燃尽图：进度图。在项目完成之前，对需要完成的工作的一种可视化表示。Y工作/X时间，理想情况，该图表示一个向下的曲线，随着剩余工作完成，燃尽至0。燃尽图向项目组成员和企业主提供了工作进展的一个公共视图。

20.燃尽图包括：①剩余时间燃尽图②故事点燃尽图

其中，故事点燃尽图才真正实现类敏捷原则（可工作的软件是进度的首要衡量指标）

 21.燃尽图的作用：①团队共同维护信息，提供实时客观任务完成情况，从而得到团队乃至产品的客观进度②避免口头不准确，尽早、客观明确进度风险，以及时采取措施③提高透明度。

22.燃尽图带来透明性

23.燃起图-进度图：

24.历时估算：估计任务、路径、项目的持续时间

25.历时估算的基本方法：①定额估算法②经验导出模型③CPM（关键路径法估计）④PERT（工程评估评审技术）⑤预留分析⑥其它

①定额估算法：T=Q/（R*S）

T：活动历时    Q：任务工作量   R：人力数量  S：工作效率

②经验导出模型：D=a*E^b

D：进度（以月单位）  E：工作量（以人月单位） a：2-4之间    b：1/3左右：依赖于项目的自然属性

Walston-Felix模型（建议掌握）：D=2.4*E^0.35

基本COCOMO（建议掌握）：D=2.5*E^b

 ③CPM（关键路径法估计）：

 

④PERT（工程评估评审技术）：利用网络顺序图逻辑关系和加权历时来计算项目历时

适用于：具有一定风险性，项目中某项单独活动存在很大的不确定性，加权算法估算任务历时

工程评估评审技术（PERT）-加权算法：基于对某项任务乐观、悲观以及最可能的概率时间估计

 PERT的风险性：用PERT估计历时存在一定风险，有必要给出风险分析结果

 标准差=（最大估算值-最小估算值）/6  ；方差=标准差的平方

如上述：标准差=（24-8）/6=2.67  

 

 解题思路：1.求路径历时估计E-＞2.求每个活动标准差-＞3.求方差-＞4.求标准差

 ⑤预留分析：应急预留（已经识别到的风险）和管理预留（不可预见的风险）

⑥1）其它-基于承诺进度估算：开发人员做出进度承诺，不进行中间的工作量（规模）估计。

   优点：有利于开发者对进度的关注

2）其它-Jones的一阶估算准则：估算项目功能点，从幂次表中选择合适的幂次将功能点升幂

 

 3）类比估算：以过去估计当前项目持续时间

4）专家判断：专家掌握进度计划+有关估算+学科应用知识来估算

5）敏捷估算方法：举手表决，基于故事点生产率估算，基于迭代生产率估算

26.进度编制的基本方法：①超前lead与滞后lag②关键路径法③时间压缩法④资源优化⑤敏捷计划

①超前与滞后：超前的优点：解决任务搭接，对任务合理拆分，缩短项目工期

②关键路径法：

浮动时间：是一个任务的机动性，是一个任务在不影响其他任务或者项目完成的情况下可以延迟的时间量

总浮动TF：在不影响项目最早完成时间的前提下，一个任务可以延迟的时间 TF=LS-ES或者TF=LF-EF

自由浮动FF：在不影响后置任务最早开始时间的前提下，一个任务可以延迟的时间FF=ES-EF-lag

求总浮动只与当前任务有关，求自由浮动除了当前任务，还要考虑当前任务的后继活动。

关键路径： ①网络图中最长的路径②是决定项目完成的最短时间③时间浮动为0的路径④关键路径上的任何活动延迟都会导致整个项目完成时间的延迟⑤关键路径可能不止一条

 正推法：按照时间顺序计算最早开始时间和最早完成时间的方法。

 注：如果没提项目开始时间默认以0开始

逆推法：按照逆时间顺序计算最晚开始时间和最晚结束时间的方法

当一个任务有多个后置任务时，选择后置任务中最小LS减去Lag作为其LF

例题：

③时间压缩法（缩短项目时间的方法）： 不改变项目范围的前提下缩短项目工期的方法

主要两种方法：a.应急法－－赶工（Crash）

 

赶工的方法：1）进度压缩单位成本方法：线性关系 2）Charles Symons（1991）方法：进度压缩比普通进度短的时候费用迅速上涨（不要过度压缩） 

（1）时间成本平衡（2）快速压缩因子

进度压缩单位成本方法：

压缩范围：正常值与可压缩值之间

项目活动的正常值：正常历时，正常成本；压缩值：压缩历时，压缩成本

进度压缩单位成本方法：

进度压缩单位成本=（压缩成本-正常成本）/(正常进度-压缩进度)

例题：

 项目存在一个可能的最短进度，很难突破

应急法（2）－进度压缩因子方法：

进度压缩因子=压缩进度/正常进度<100%

压缩进度的工作量=正常工作量/进度压缩因子

b.平行作业法－－快速跟进

改变活动间的逻辑关系，并行开展某些活动（提前量方法）

平行作业常导致返工和增加风险

作用：解决任务搭接，对任务进行合理拆分

④资源优化法：尽量充分利用已有资源。根据资源供需情况，调整活动的开始和完成日期。

资源优化：资源平衡，资源平滑

资源平衡：通过调整任务时间来协调资源的冲突，资源平衡往往导致关键路径的改变

资源平滑：在项目编排中进行资源的优化配置，保证资源最优化。资源平滑不会改变关键路径，完工日期也不会延迟。活动只在其自由和总浮动时间内延迟

⑤敏捷计划：发布计划，迭代计划

发布计划：远期计划（粗计划）

近期计划：近期计划（细计划）

Scrum两层项目计划：产品代办事项列表（粗），Sprint代办事项列表（细）

用户需求又称用户故事