软件项目管理7c

第1章 软件项目管理概述

什么是项目？

项目（Project）是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性努力（活动），是以一套独特而相互联系的任务为前提，有效地利用资源，在一定时间内满足一系列特定目标的多项相关工作的总称。

项目特点？

有明确的目标性、明确的时限性、资源成本的约束性、项目的不确定性、唯一性

软件项目的特点？

软件是逻辑实体，高度地抽象性；软件没有明显地制造过程；软件不存在磨损和老化，存在退化问题；软件开发受外界因素的制约：计算机系统；手工订制，通用组织仍不健全；软件本身是复杂的；软件成本高昂；软件涉及很多社会因素

软件项目日常运作活动与项目的区别？

项 目：唯一性、时限性、目标导向、变更管理、项目组织、项目经理负责； 日常运作：重复性、连续性、绩效优先、线性管理、职能部门、部门经理负责

软件管理生命周期与软件工程生命周期区别?

软件管理生命周期： 1．启动 项目获得授权正式被立项，并成立项目组，宣告项目开始。启动是一种认可过程，用来正式认可一个新项目或新阶段的存在。 2．计划 明确项目范围，定义和评估项目目标，选择实现项目目标的最佳策略，制定项目计划。 3．执行 调动资源，完成项目管理计划中确定的工作。 4．控制 监控和评估项目偏差，必要时采取纠正行动，以保证项目计划的执行，实现项目目标。 5．结束 软件工程生命周期：问题定义、可行性与需求分析、系统设计、程序实现、测试确认、维护支持

项目管理知识体系（PMBOK）9个领域，以及4个核心领域？

四个核心：项目范围、项目进度、项目成本、项目质量； 九大领域：项目集成管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理

第2章 项目的启动和准备

如何进行项目分析？

前期市场调研 项目调研：1、准备阶段：了解用户行业、资料准备、制订调研计划。2、撰写调研报告 需求分析：1、需求收集（功能、性能、安全性、其他），运行环境、人员素质；2、需求说明书（SRS）、规格说明书 需求管理：专人管理需求工程；细化需求；需求确认；严格需求变更；界面快速展示 需求分析报告

可行性分析报告包括哪些内容？

技术可行性：全面考虑系统开发过程所涉及的技术问题 尽可能采用成熟技术 慎重引入新技术（新版本） 着眼于具体的环境环境和开发人员 技术可行性评价 经济可行性： 经济可行性是指可以使用的资源（人力资源、自然资源、资金条件）可能性；并估算开发成本与费用，预测系统可取得的未来效益，明确是否值得可开发。 风险控制可行性： 定量分析 预期收益

然后甲方：提交建议书，乙方签订合同，成立项目研发团队

项目章程是什么？

项目章程是确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。 项目要明确以下几点：项目名称、项目的重要性、项目目标项目、项目经理、主要项目干系人、项目总体进度安排、项目总体预算、各个职能部门应提供的配合、项目审批要求、本章程的批准

软件需求/规格说明书的区别？

需求说明：通常是指以用户语言描述的产品要求。 规格说明：用产品领域的语言描述的产品要求。

几种常见的合同？

成本补偿合同、固定总价/单价合同、功能计费点合同 项目经理的责任?开发计划、组织实施、项目控制

第4章 软件项目需求管理

项目成功三要素

• 质量、时间、成本

项目范围的定义

• 软件项目范围具体的说包括产品范围和项目范围两方面，产品范围是指产品、服务或者成果所具有的特性和功能；项目范围是指为交付具有规定特性与功能的产品、服务或者成果而必须完成的工作。

软件需求层次?

软件需求可以分为功能需求和非功能需求，功能需求进一步分为三个层次，业务需求、用户需求和功能需求，系统需求也是功能需求的一个来源；非功能需求进一步分为业务规则、质量属性、性能属性、对外接口、约束条件。

软件需求获取方法？

（1）问卷调查 （2）访谈 访谈有经验的项目参与者、干系人和领域专家，有助于识别和定义项目可交付成果的特征和功能。 （3）引导式研讨会 引导式研讨会通过邀请主要的干系人一起参加会议，对产品需求进行集中讨论与定义。 （4）头脑风暴 又称为智力激励法、自由思考法或集思广益会，是用来产生和收集对项目需求与产品需求的多种创意的一种技术。 （5）原型法：在获取一组基本需求之后，快速地构造出一个能够反映用户需求的初始系统原型，它使干系人有机会体验最终产品的模型，而不是只讨论抽象的需求陈述。原型法符合渐进明细的理念，因为原型需要重复经过制作、试用、反馈、修改等过程。

需求规格说明书：

1.范围 2.引用文档 3.功能需求 4.数据需求 5.非功能需求 6.运行需求

需求管理

• 需求变更流程？ 1.提出变更 2.评估变更 3.决策变更 4.实施变更 5.验证变更

• 需求跟踪？ 需求跟踪有两种类型的跟踪，前向跟踪和后向跟踪。 4种需求链: （1）客户需求可以向前追溯到系统需求。 （2）可以从系统需求回溯到相应的客户需求。 （3）从需求追溯到后续工作产品。 （4）从产品部件回溯到需求。 需求跟踪矩阵内容包括需求代号R001、需求用例UC-28、设计实例Catalog、编码实例Catalog.sort()、测试用例Search7

第5章 项目进度管理

PERT评审模型五个步骤

• 确定完成项目必须进行的每一项有意义的活动，完成每项活动都产生事件或结果。

• 确定活动完成的先后次序。

• 绘制活动流程从起点到终点的图形，明确表示出每项活动及其它活动的关系，用圆圈表示事件，用箭头线表示活动，结果得到一副箭头线流程图，称之为PERT网络。

• 估算每项活动的完成时间。

  • （1）专家判断

  • （2）类比估算

  • （3）参数估算

  • （4）三点估算 首先需要估算出进度的3个估算值，然后使用这3种估算值来界定活动历时的近似区间： 最可能时间（TM）：对所需进行的工作和相关时间进行比较现实的估算，所估算的活动历时。 最乐观时间（TO）：基于最好的情况，所估算的活动历时。 最悲观时间（TP）：基于最差的情况，所估算的活动历时。 活动持续时间TE = (TO+4TM+TP)/6，标准差（TP-TO)/6，据此来界定活动历时的近似区间， 例如，3周±2天

• 借助包含活动时间估计的网络图，制定出包括每项活动开始和结束日期的全部项目的只程计划。在关键路线上没有松弛时问，沿关键路线的任何延迟都直接影响整个项目的完成期限。

项目进度编制的方法？

维持工期不变，资源平衡，使资源强度尽可能平衡 使工期最短,在满足资源约束条件下 2.资源优化 资源优化（资源平衡和资源平滑）用于调整活动的开始和完成日期，以调整计划使用的资源，使其等于或少于可用的资源。 3．进度压缩 进度压缩技术是指在不缩减项目范围的前提下，缩短或加快进度工期，以满足进度制约因素、强制日期或其他进度目标。 【赶工】加班等； 【快速跟进】将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。例如，在大楼的建筑图纸尚未全部完成前就开始建地基。 线性关系方法 见课本 进度压缩因子方法 见课本

第6章 项目的估算和成本管理

不同估算方法适合不同阶段

• 这些估算方法不会考计算，不现实，要知道每个方法是做什么的

• 初期

  • 类比 (自顶向下)估算法；类比法通常用来验证参数法和自下而上法的结果

  • 专家估算法

• 计划阶段

  • 自下而上估算法

    • 费时费力

  • 参数法估算法

    • 比较简单，自下向上法与参数法的估计精度相似

• 实施阶段（包括变更发生）

  • 自下而上估算法

  • 参数法估算法

项目估算方法

• Delphi专家估算法

  • 组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格，请他们估算 专家详细研究软件规格说明后，对该软件提出3个规模的估算值：最小ai、最可能的mi、最大bi 计算每位专家的Ei=(ai+4mi+bi)/6, 综合结果后:E=E1+E2+…En/n（N:表示N 个专家） 某多媒体信息查询系统—专家估算 专家1：1，8，9=〉（1+9+4 * 8 ）/6=7（万元） 专家2： 4， 6 ， 8 =〉（4+8+4*6）/6=6 （万元） 估算结果=（6+7）/2=6.5 （万元）

• 自下而上估算法

  • 三点估算法：对每项工作的工期给出三种预估值：最可能时间、最乐观时间和最悲观时间，然后加权平均，计算出其计划时间。 最可能时间Tm：根据以往的经验，这项工作最有可能用多长时间完成。 最乐观时间To：当一切条件都顺利时该项工作所需时间。 最悲观时间Tp：在最不利条件下，该项工作需要的时间。 那么计划时间Te的计算公式如下： Te=（To+4×Tm+Tp）/6 标准差=（Tp - To）/6

• 类比 (自顶向下)估算法

  • 估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中。 使用情况：有类似的历史项目数据、信息不足（要求不是非常精确)的时候、在合同期和市场招标时 等价代码行=[(重新设计代码百分比+重新编码代码百分比+重新测试代码百分比)/3]*已有代码行

• 参数估计法

  • COCOMO模型

    • 基本COCOMO模型，是静态单变量模型，它用一个已经估算出来的源代码行数L为自变量的函数来计算软件开发工作量； MM=a(KDSI)^b TDEV=cMM^d 其中，MM为开发工作量（度量单位为人月），TDEV为所需的开发时间（度量单位为月），DSI是项目的源代码行估计值，不包括程序中的注释和文档，KDSI=1000DSI。 一个33.3 KLOC的软件开发项目，属于中等规模、半有机型的项目，采用基本COCOMO： a=3.0，b=1.12。 E = 3.0＊L ^1.12 = 3.0＊33.3 ^1.12 = 152 PM

    • 中级COCOMO模型，是一个静态多变量模型，它在用L作为自变量的函数来计算软件开发工作量的基础上，再使用成本因素来调整工作量的估算结果； MM=a(KDSI)^bEAF 一个33.3 KLOC的软件开发项目，属于中等规模、半有机型的项目，采用中等COCOMO模型 a=3.0，b=1.12。 乘法因子＝0.700.851……1.15=1.09 E = 3.0＊L ^1.12 = 3.0＊33.3 ^1.12 ＊ 1.09=166PM

    • 详细COCOMO模型，包括了中级COCOMO模型的所有特性，并结合成本因素对软件开发过程中的每一个步骤的影响进行评估。

  • IBM估算模型

    • E = 5.2×L0.91 D = 4.1×L0.36 S = 0.54×E0.6 DOC = 49×L1.01 其中L是源代码行数（以KLOC计），E是工作量（以PM计），D是项目持续时间（以月计），S是人员需要量（以人计），DOC是文档数量（以页计）。 如一个规模为10KDSI的嵌入型软件，使用IBM模型进行计算： E = 5.2×100.91=42.27（人月） D = 4.1×100.36=9.84（月） S = 0.54×42.270.6=5.1（人）

估算工作量的方法

• 项目规模表示： LOC(Line of Code)源代码程序长度的测量 FP(Function Point)用系统的功能数量来测量 开发工作量估算单位：人月、人天、人年

• 代码行： 某软件公司统计发现该公司每一万行Java源代码形成的源文件约为250KB。某项目的源文件大小为3.75MB，则可以估计出该项目源文件代码行大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用等），则该项目中单位LOC的价值为： （240×10000）/150000=16元/LOC 该项目的人月均编码行数为： 150000/240=625LOC/人月

• 功能点

  • 功能计数项：外部输入EI、外部输出EO、外部查询EQ、外部文件EIF、内部文件ILF

  • FP =UFCTCF UFC：未调整功能点计数 TCF：技术复杂度因子 一般可以采用下面的公式计算出系统的未调整功能点数UFC：UFC=Σ各复杂度等级的信息域数量×加权值 技术复杂性因子TCF由以下公式计算： TCF=0.65+0.01(sum(Fi))： Fi:0-5,TCF:0.65-1.35，DI=sum(Fi):140-14*5

  • FP=UFCTCF UFC=301 TCF=0.65+0.01(143)=1.07 FP=301*1.07=322

实用软件估算模型：

是一种自下而上和参数法的结合模型,步骤如下:

• 对任务进行分解:1,2,…,i…

• 估算每个任务的成本Ei： 先估算规模Qi，然后估算成本Ei= Qi *人力成本参数 唯一估计值：Qi=Avg PERT算法: Qi=(Max+4Avg+Min)/6 直接成本组成: 开发成本、管理成本、质量成本 例如：人力成本参数=2万/人月，30人月规模的项目的直接成本是 60万

• 直接成本=E1+E2+……+ Ei+……+ En

• 项目总估算成本= 直接成本+间接成本 估算成本=规模人力成本参数（1+间接成本系数） 成本系数=人力成本参数 （1+间接成本系数） 简易算法：估算成本=规模*成本系数例如：成本系数= 3万/人月

• 项目总报价=项目总估算成本+风险利润 （利润+风险基金+税） 即：项目总报价=(a+b+c) %*项目总估算成本+项目总估算成本

第7章 软件项目的质量管理

质量标准

• ISO质量标准 ISO 8042：反应实体满足明确的和隐含的需求的能力的特性的总和。 ISO 9126软件质量模型中的6个质量特征定义如下： 1）功能性 2）可靠性 3）可用性 4）效率 5）可维护性 6）可移植性

• CMM/CMMI的5个等级 (1)初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。 (2)可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 (3)已定义级(Defined)。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。 (4)已管理级(Managed)。运用度量方法和数据，可以对软件产品和开发过程实施定量的分解和控制 (5)优化级(Optimizing)。可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。

• Boehm模型

• McCall模型

评审方法：

（1）同行评审（2）走查（3）会议审查（4）检查表（5）场景分析

估算方法：

六西格码方法 σ是一个统计学术语，用来衡量一个过程的质量。σ的量级为2至6，代表百万个产品之中有多少个缺陷。 对于一般公司来说，能够达到4σ就是一个不错的成绩了，这相当于每百万个产品中有6000个缺陷(合格率为99.4%)。我们的奋斗目标是6 σ，相当于每百万个产品中有3.4个缺陷，即合格率达到99.9997%。合格率越高，经济效益自然越高。

质量保证3个策略：

1）以检测为重。产品制成之后进行检测，只能判断产品质量，不能提高产品质量。 2）以过程管理为重。把质量保证工作的重点放在过程管理上，对开发过程中的每一道工序都要进行质量控制。 3）以产品开发为重。在产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患。

第8章 软件项目风险管理

风险识别

• 常见的项目风险因素: 技术、安全、政策、沟通

风险评估

• Boehm模型 ：1.技术与管理流程 2.计划和执行风险管理 3.管理项目风险特征库 4.风险分析 5.处理风险 6.风险监控 7.评估风险管理流程

• CRM模型： 要求在项目生命期的所有阶段都关注风险识别和管理，将风险管理活动分为5个步骤：风险识别、分析、计划、跟踪、控制；这是一个在项目开发过程中反复持续进行的活动序列

• Riskit 模型 ： 提供风险的明确定义：损失的定义建立在期望的基础上，即项目的实际结果没有达到项目相关者对项目的期望的程度； 明确定义目标、限制和其它影响项目成功的因素 采用图形化的工具 Riskit分析图对风险建模，定性地记录风险； 使用应用性损失的概念排列风险的损失； 不同相关者的观点被明确建模。

风险处理：

规避。通过变更项目计划消除风险或风险的触发条件，使目标免受影响。 转移。不能消除风险，而是将项目风险的结果连同应对的权利转移给第三方。 弱化。将风险时间的概率或结果降低到一个可以接受的程度，其中降低发生的概率更为有效。 接受。不改变项目计划，而考虑发生后如何应对

风险监控:

在项目实施过程中监督人们认真执行风险管理的组织和技术措施。

第9章 人力资源和沟通管理

团队类型结构：

职能型： 优点：可以充分发挥职能部门的资源集中优势；部门的专家可以同时为部门内不同项目使用；便于相互交流 , 相互支援；可以随时增派人员；可以将项目和本部门的职能工作融为一体。 缺点：项目和部门利益发生冲突，职能部门更重视本部门的目标,会忽视项目目标；资源平衡会出现问题；权利分割不利于各个职能部门的交流和团结协作；行政隶属关系使得项目经理没有充分的权利。 项目型： 优点：项目经理对项目可以负全责；项目目标单一，可以以项目为中心,有利于项目顺利进行；避免多重领导；组织结构简单，交流简单,快速。 缺点：资源不能共享；各个独立的项目处于相对封闭状态,不利于公司政策的贯彻；对项目组织的成员缺少一种事业上的连续性和安全感；项目组织之间处于分割状态,缺少信息交流。 矩阵型可分为：弱矩阵型组织结构、平衡型矩阵组织结构和强矩阵型组织结构。 优点：专职的项目经理负责整个项目 , 以项目为中心；公司的多个项目可以共享各个职能部门的资源；即利于项目目标的实现,又利于公司目标方针的贯彻；项目成员的顾虑减少了。 缺点是：容易引起职能经理和项目经理权力的冲突；资源共享也能引起项目之间的冲突。

激励理论

马斯洛需要层次理论，从低到高：生理需要、安全需要、社交需要、尊重需要和自我实现

激励方式：

物质激励。包括工资、奖金和各种福利; 环境激励。良好的工作环境和生活环境； 成就激励。细分为组织激励、榜样激励、荣誉激励、绩效激励、目标激励和理想激励； 能力激励。两种方式：培训激励、工作激励； 情感激励。情感沟通和情感鼓励。

沟通技术：

（1）会议沟通 成本较高，沟通的时间一般比较长，因此常用于解决较重大、较复杂的问题。几种适用场景举例 （2）Email沟通 成本低，方便快捷，小范围沟通，有时间思考斟酌，等； （3）口头沟通 是一种自然、亲近的沟通技术。加深彼此之间的友谊、加速问题的解决。几种应用场景：办公距离近；存有误会，采用Email无效等 （4）电话沟通 成本较低，距离远无法当面沟通，问题相对简单，采用Email无效等情况下适用。 （5）即时通讯 QQ/MSN/微信（群），快捷，方便，可以群讨论，但是闲聊可能会影响工作。

团队沟通方式：

1. 正式沟通与非正式沟通 。正式沟通效果好，沟通信息具有权威性，但较刻板；非正式沟通形式不限，但难以控制。 2.上行沟通、下行沟通和平行沟通。上行沟通层层过滤，效率不佳；下行沟通可明确领导意图，但易营造高高在上印象。平行沟通助于培养团队友谊，但信息量大，易造成混乱。

2. 单向沟通和双向沟通 。单向沟通信息传递的速度快，但不能产生平等和参与感；双向沟通信息准确性较高，有助于建立双方的感情。

3. 书面沟通和口头沟通 。书面沟通可作为资料长期保存，反复查阅；口头沟通比较灵活、速度快，双方可以自由交换意见，且传递信息较为准确。 5.言语沟通和体语沟通。言语沟通利用语言、文字、图画、表格等形式进行；体语沟通利用动作、表情姿态等非语言方式进行，是项目沟通的主要组成部分。

第10章 项目验收

老师课堂口述总结

• 资料的准备： 纸质：需求规格说明书、概要设计说明书、E-R图、测试文档、软件需求规格说明书 电子资料：代码、数据库--数据字典 安装部署环境的准备：软件安装说明、环境的搭建、mysql数据库，tomcat启动环境、微信小程序、APP提供平台的账户信息

• 验收文档的准备：功能点通过或没通过的一个说明，对未通过或需要后期修改的功能点要说明完成整改的时间

• 项目的培训：给最终用户做技术培训，日常的运行维护，如服务器日志的备份、数据的备份

• 后期维护：改正性维护、适应性维护、完善性维护、预防性维护。

• 最后，对内部来说，项目的总结，出现了哪些风险、怎么应对的，成本的估算，进度的估算，形成一个总结文档

1.合同收尾：

合同收尾是项目管理人员与客户对照合同一项项的核对，审核是否完成了合同所要求的内容，是否达到合同所提出的指标或条件，也就是通常所讲的客户验收。 合同收尾是结束合同并结清账目，包括解决所有尚未结束的事项。合同收尾需要对整个采购过程进行系统地审查，找出进行本项目其它产品或本组织内其它项目采购时值得借鉴的成功和失败之处。

2.管理收尾：

管理收尾是对于项目组内部，把做好的项目文档、代码、与客户交流的文件等归档保存，对项目中遇到的问题及解决方法、有效的创新技术进行及时地总结，对外宣称项目结束，转入维护期，把相关的产品说明及技术文档转到维护组。

3.项目验收流程:

项目验收是一个循序渐进的过程，要经历准备验收材料、提交申请、初审、复审，直到最后的验收合格，完成移交工作。

4.软件项目的验收工作：

（1）软件系统验收: 已经配置好的系统环境；软件产品，例如，软件光盘介质等；项目成果规格说明书；系统使用手册；项目的功能、性能技术规范；测试报告等。 （2）质量验收：质量验收主要是对软件系统的功能、性能、用户操作界面、可维护性等方面进行验收 （3）资料验收： 1)开发文档：主要包括软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、可行性研究报告等。 2）管理文档：主要有项目开发计划、测试计划、测试报告、开发进度月报、质量评估报告、重要会议纪要、变更记录控制文档、验收审核表、项目开发总结等。 3）用户文档：用户手册、操作手册、维护修改建议等。

5.项目的移交工作：

用户培训：用户基本熟悉软件系统的业务操作。 系统上线：工作包括硬件设施的搭建、网络环境的搭建、操作系统的安装和设置、数据库的安装和数据的准备、业务软件系统的部署和配置。 后期维护：改正性维护、适应性维护、完善性维护、预防性维护。

6.项目总结包括技术方面和管理方面。

项目评价包括项目背景、项目实施过程评价、效果评价、结论和经验教训。

by 7c