首页 课程

# 软件项目管理大纲

Rat

# 1. 项目和项目管理的基本概念

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

项目管理定义： 项目管理是一系列伴随着项目进行而进行的，确保项目能达到期望结果的一系列管理行为。
项目管理过程：启动、计划、执行、控制与收尾

项目管理三维约束：范围 、 时间 、 成本。
项目风险三要素：1. 风险事件的存在； 2. 风险事件发生的概率； 3. 风险事件可能带来的损失。

软件项目管理包含哪些内容：范围管理、成本管理、时间管理、人员管理、风险管理

image-20221116102120237

# 2. 项目的确立

  1. 瀑布模型： 阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的输入。对本阶段工作进行评审，若得到确认，则继续下阶段工作。

    适用于 需求明确，线性工作流程的短期项目

  2. 原型模型：开发原型了解需求，原型模型减少了软件需求不明确带来的风险。
    适用于 用户需求不确定，需要人机交互。

  3. 螺旋模型：风险驱动的，每一阶段一个螺旋，不断完善项目。
    适用于 大型项目，对风险比较关注的项目。

  4. 增量模型：融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。把软件产品作为一系列的增量构件来分析、设计、编码、测试和发布。
    适用于 需求基本明确，可能发生变化，系统逐步改造的项目。

  5. V 模型：v-model 改进了瀑布模型，在软件开发的生存期，其 开发活动 和 测试活动 几乎同时的开始，这两个并行的动态的过程就会极大的较少 bug 和 error 出现的几率。
    适用于 需求明确，系统性能、安全等有严格要求。

# scrum 敏捷开发：

​ Scrum 是敏捷开发方式的一种。Scrum 强调沟通，要求团队所有人坐在一起工作，通过高效沟通解决问题， 并且敏强调周期很短地交付可工作的软件成果。

敏捷宣言: 个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

另外 12 条原则总结为：尽早交付，响应变化，周期求短，激发个体，业务合作，简洁为本，追求成果，定期反思，面谈交流，优化设计。

极限编程：小规模发布，策划活动、隐喻、简单设计、测试和编码一起进行、重构、结对编程，持续集成

# 项目立项过程：

​ 识别项目→论证项目→项目评估报告→申请项目→立项建议书→申请审核→确立项目 ****
目的： 明确项目的目标、时间表、项目使用的资源和经费，而且得到项目经理和项目发起人的认可。

# 招标阶段任务：

​ 甲方：招标书定义、供方选择、合同签署。
​ 乙方：进行项目选择、投标、合同签署。

# * 需求管理的过程：

​ 需求获取 → 需求分析 (原型，用例、流程图) → 需求规格编写 → 需求验证 → 需求变更

# 3.WBS

结构分解的工具是工作分解结构 WBS (Work Breakdown Structure)，它是一个分级的树型结构，是将项目按照其内在结构或实施过程的顺序进行逐层分解而形成的结构示意图。

image-20221115093951653

# WBS 设计的主要方法：

​ 类比法、自上而下法、自下而上法。

# 范围核实：

​ 项目干系人对项目范围的正式承认。

# 范围变更：

​ 通过识别和确定项目目标和项目主要产出物，明确项目的具体实施方案，确定项目的工作范围。

范围管理相关案例：见本篇最底部（按住 Ctrl 点击）

# 4. 成本因素

要求：常见成本估计方法：列举五种即可

基于问题的估算：

S=(S op+4S m+S pess)/6S=(S~op+4S~m+S~pess)/6

  1. 代码行估算法：从软件程序量的角度定义项目规模；

  2. 功能点估算法:q 通过评估、加权、量化得出功能点；FP =UFC*TCF;

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

  3. 用例点估算法：根据用例模型，计算工作量；

  4. 类比 (自顶向下) 估算： 根据历史数据；

  5. 自下而上估算 WBS：根据 WBS 细分的任务活动

  6. 参数估算法： E= a+b*Sc

  7. 专家估算法：组织者计算每位专家的 Ei=(ai+4mi+bi)/6

👆回到顶部–按住 Ctrl 点击回到顶部👆👆

# 5. 风险规划

​ 针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件造成的影响。

常见风险：

(1) 合同风险
(2) 需求变更风险
(3) 沟通不良风险
(4) 进度风险
(5)) 人员流动风险
(6) 分包商风险
(7) 质量风险

主要策略：(选择题判断是哪种风险)

①接受风险： 小风险，或者采取措施后投入的成本比风险发生后的损失还多。

②规避风险： 对风险有足够的认识，尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案。

③缓解和降低风险：采取措施，降低风险的发生可能性。

④转移风险：将损失转嫁出去，如：分包，开脱责任合同，准备保险。

# 6. 进度管理

# 图示

  1. 网络图： 了解单代号网络图；双代号网络图

    image-20221116083405216 image-20221116083353305

  2. 甘特图：了解甘特图画法

    image-20221116083442217

  3. 里程碑图： 了解里程碑的概念（里程碑的工期为 0）

    image-20221116083327089

  4. 资源图： 稍微了解一下

    image-20221116083457334

# 任务四种关系

1、FS (完成 - 开始) 关系：

必须先完成任务 A，然后任务 B 才能开始。

2、SS (开始 - 开始) 关系

如果任务 A 没有开始，那么任务 B 也无法开始。

3、FF (完成 - 完成) 关系

任务 A 的完成日期决定任务 B 的完成日期

4、SF (开始 - 完成) 关系

任务 A 的开始日期决定任务 B 的完成日期。现实中发生频率较其它关系低.

软件的使用过程中，常用的关联关系是 FS (完成 - 开始) 关系、SS (开始 - 开始) 关系两种。其他关系的使用按实际需求来选择。

# 相关计算： （关键路径、浮动时间）很重要

# 进度计划参考资料 按 Ctrl + 左键打开

image-20221116101726009

[👆回到顶部](#软件项目管理复习大纲)--按住 Ctrl 点击回到顶部👆👆

# 范围管理案例

(会考类似题目！)

image-20221116085959313 image-20221116090204851 image-20221116090216754 image-20221116090250136 image-20221116091516702
image-20221116091604458 image-20221116091613666 image-20221116091622675 image-20221116091635361 image-20221116103058727

image-20221116103219081

这是一个成功的项目管理案例，项’目经理张工有效的运用范围管理，在不同的项目干系人中达成一致，使项目的结果同时满足了高层经理、客户和项目组成员的要求。

作为一个项目管理者，必须熟练掌握和应用项目管理九大领域涵盖的知识与技能，对于进行信息系统开发项目而言，范围管理是其中最重要的技能之一。

软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制的。软件系统的需求来源于用户需求，在软件项目目标是满足用户需求的情况下，对于相同的用户价值可以定义出不同的系统需求。

在本案例中，高层经理 S 就提出了试图打破这个三角形的要求。他要求，项目组可以增加部分资源，但要提前两个月完成。初一看，并没有在不增加投入的情况下要求项目提前完成，似乎合情合理，比起既要马儿跑又不让马儿吃草的要求好得多，但细一想，增加的资源和提前的时间还是不成比例。项目经理张工深知此中奥妙，因此在听到高层经理的要求后，马上意识到这是一个不可能完成的任务。

那么该如何解决这个矛盾呢？还是要从这个三角形入手。既然时间和资源的变化已经打破了项目规律，那么不妨根据新的时间和资源来重新划定合理的项目范围，保证项目的正常运作。于是，张工将这个项目拆分为两部分，重新定义这两部分的项目范围，使每一部分的范围都可以与已经确定的资源和时间匹配起来，让项目的运作又重新满足了项目的客观规律，最终取得了成功。

在案例中，还有一些细节需要考生注意。张工最初估算整个项目需要花费 60 人月的总工作量，但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因素，超出原计划半个月是正常的。计划在 6 个月内完成。在把项目拆分后，实际是用了 6 个半月的时间，也就是花费了 65 人月完成了项目。对于上面介绍的时间、成本和范围的关系而言，仅是在理想情况下成立，即项目成员始终能以固定的成本完成固定的工作。而在实际情况下，项目的工期、复杂度等因素都会对项目造成影响。在案例中，虽然看似两部分工作的总和等于没有拆分前的项目，但这仅对于最终目标而言，拆分后的项目增加了若干中间成果，项目的范围实际上还是扩大了。

因为软件项目的范围直接与需求相关，所以，很多人误认为控制项目范围就是控制需求，而控制的方法就是减少需求的内容。这种理解是完全错误的。

范围控制体现在软件开发的各个阶段，很多范围控制并非是针对客户的要求而进行的。例如，本案例中，范围控制就是针对高层经理的要求进行的。再比如，在设计中，我们既可以设计刚刚够用甚至略有欠缺，通过牺牲系统的扩展性、维护性等方面来简化设计，也可以对系统进行充分良好的设计，甚至可能是过度设计。采取哪一种设计策略也是软件项目范围管理的一部分。项目经理可以根据目前的项目的目标与环境出发，综合考虑质量和成本的约束，制定明确的项目范围，保证项目的成功。根据笔者的经验，即时需求已经确定，通过有效的范围管理仍能给项目带来很大的收益，可以在不牺牲软件质量的前提下通过范围管理来降低项目成本，缩短项目工期。

上面主要针对张工在范围控制方面进行了分析，实际在整个案例中，张工还进行了其他的范围管理工作。

首先，在项目刚刚开始，张工就对项目范围进行了定义，进而划分了 WBS 并对项目进行了估算和计划。在 S 提出需要缩短工期的要求后，张工首先进行了项目范围的控制，缩小了第一步需要完成的项目范围。紧接着张工又对两阶段需要完成的项目范围进行了重新定义，制定了验收标准。最后，张工对重新定义的范围进行了确认，与客户和高层经理达成一致。

对于项目而言，仅仅管理范围仍不能保证项目的成功。在这个案例中，张工也运用了其他的管理手段。其中包括，张工对项目进行了估算，这属于项目时间管理的范畴；张工协调了多个项目干系人之间的矛盾，这属于沟通管理的范畴。

有了上面的分析，这道考题的答案也就很清晰了。

image-20221116103343082

👆回到范围管理（按住 Ctrl 点击） 👆回到范围管理（按住 Ctrl 点击） 👆回到范围管理（按住 Ctrl 点击）