项目管理名词解释

项目管理名词解释

一、需求

1.业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。

2.用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在用例文档或方案脚本说明中予以说明

3.规格需求(spicification requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

二、质量

1.SQA(软件质量保证)是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

2.QA，即质量保证，职责是审计过程的质量，保证过程被正确执行；是过程质量审计者；

3.QC，即质量控制，职责是检验产品的质量，保证产品符合客户的需求，是产品质量检查者。

但在很多实际项目中，QA往往等价于测试人员，是团队中担任测试角色的成员，包括但不限于PM、系统分析员、专职测试人员等；而出于成本或组织环境等各种原因，过程质量审计的角色往往会缺失。也就是说，只保证了把事情做对，而没有保证做对的事情。

可编辑word,供参考版！

4. SEPG(Software Engineering Process Group)是软件工程过程组的缩写，指由软件过程专家组成的团队，负责在软件组织内推动和促进软件过程改进；

5.QA： 确保过程被正确执行；

同行评审（peer review）：除工作产品的作者之外的一个或多个人检查该产品，以期发现缺陷及其改进时机的一种活动。评审成员往往由组织内部具有相关经验的成员组成，包括但不限于客户代表、团队内部其他Team的成员、其他项目组成员、其他职能部门成员等，一般是所在领域的业务专家或技术专家。

三、测试

1.单元测试（Unit Test）：是对软件中的基本组成单位进行的测试，如Java类中的一个方法、Oracle后台的一个存储过程或函数等等。大多数情况下，单元测试往往由程序员自行完成，谁编码，谁负责；

2.集成测试（Integration Test）：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确以及由单元组成的更高一级的模块是否可以正常运行。一般由测试人员、系统分析员负责；

3.系统测试（System Test）：是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法；

4.确认(验收)测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是由客户对分发的软件进行的测试；

可编辑word,供参考版！

5.回归测试：回归测试是进行修改之后进行的验证测试。其目的是检验对软件进行的修改是否正确，包括bug是否已修复，是否产生新的bug等。

四、项目估算

出现的名词：FP、IFPUG、LOC

1.FP（Function Point，功能点）估算：70年代，IBM工程师A. J. Albrecht提出了用功能点度量软件规模的观点，并在IBM内部使用。80年代初，A. J. Albrecht发表了用程序的输入/输出及系统内部数据文件衡量应用程序规模的方法，这就是FP法。1986年，美国成立了IFPUG（International Function Point Users Group）组织，继续沿着A. J. Albrecht 的思路开发FP法。

2.FP原理：FP法将商业信息系统抽象成输入数据，输出数据，查询数据，系统内部文件，系统外部文件。其原理是对于每一个基本事务处理（或者说基本用例），如一次数据录入，一次数据查询，或者一个报表输出，提炼出该事务处理涉及到的所有种别的EI，EO，EQ数据，评估这些数据的复杂度，折算成功能点。这称为TFP（Transaction Function Point），用基本处理的TFP衡量该处理的规模。对于每一个ILF和EIF，评估该文件记录的复杂度，折算成DFP（Data Function Point）。因为系统内部处理逻辑的复杂度和系统处理的内部数据及输入数据相关，因此，用DFP衡量系统内部处理的规模。所有基本事务处理的TFP累加，再加上DFP，就是整个系统的FP，这叫未调整的FP。系统的复杂度和系统的性能要求，是否分布式系统等特性相关，因此还要评估系统特性。FP法提出了14项系统特性，每项系统特性从简单到复杂，计分为0到 5。通过评估系统特性，得出一个调整因子，未调整FP乘上该调整因子，得出系统的FP数，这个FP就是最终评估出来的系统规模。有了FP表征的系统规模，再根据历史数据或专家估算得出的每人月能完成的FP数，求出人月数表示的系统规模。再乘上每人月的单价，即得到系统开发成本的估算。

可编辑word,供参考版！

FP功能点估算法将功能点分为以下5类：

1. ILF：Internal Logical File内部逻辑文件

2. EIF: External Interface File外部接口文件

3. EI: External Input外部输入

4. EO: External Output外部输出

5. EQ: External Inquiry外部查询

其中ILF和EIF属于数据类型的功能点，EI、EO、EQ属于人机交互类型的功能点。

ILF、EIF要与EI、EO、EQ分开计算。对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。对EI、EO、EQ复杂度的计算可以理解为对程序开发复杂度的计算。一般软件项目都是由数据和程序构成的，因此计算ILF、EIF和计算EI、EO、EQ之间没有任何关系。

可以看出，FP估算也是通过诸如分解或拆分等手段，化整为零，使系统的复杂度降低到可以估算的程度，以便于得出量化的数据，然后再从整体的角度去考量系统，得出调整因子，最终汇总得出系统整体规模或工作量。

五、项目监控

出现的名词：挣值管理、CMMI-SVC、CMMI-ACQ、CMMI-DEV、ITIL

可编辑word,供参考版！

1、挣值管理是测量项目绩效的一种方法，通过比较计划值、实际完成的工作价值和实际的花费来确定成本和进度是否按照计划进行。三个基本参数分别是计划值（PV，Planed Value）、挣值（EV，Earned Value）和实际成本（AC，Actual Cost）。

（1）计划值（PV）包含两个内容：实际的计划工作加上为完成该计划工作所批准的预算,先前被称作“计划工作的预算成本” （BCWS，Budgeted Cost of Work Scheduled）；

（2）挣值（EV）也包含两个内容：实际完成的工作加上该工作批准的预算。在给定的时间内（通常为从项目开始至今），为已完成的（部分）活动批准的成本预算（可能包括分摊的开销，例如一般管理费用）总额。先前被称作“已完成工作的预算费用”（BCWP，Budgeted Cost of Work Performed）；

（3）实际成本（AC）是指在给定的时间范围内，完成工作所引起的、与计划值和挣值（他们有时仅是直接人工工时，或仅是直接成本，或是包括间接成本在内的所有成本）范围内任何预算成本相关的全部成本。先前被称作“已完成工作实际费用”（ACWP，Actual Cost of Work Performed）。在项目管理中运用挣值分析时，需要建立项目的工作分解结构（WBS），编制切合实际的工作进度计划，定期地对项目执行中的各个参数进行数据检测，并根据检测结果对项目进行调整和预测。

挣值管理的目的是在保证质量目标不变的前提下，通过对偏差的分析尽早的对项目完工时的最终进度与成本做出预测，并分析偏差产生的原因，实施相应的纠正措施，从而降低项目风险。

在使用挣值管理方法进行偏差分析时所采用的评价指标是：进度偏差（SV），成本偏差（CV），进度绩效指数（SPI），成本绩效指数（CPI）。

进度偏差（SV）：是指一项活动计划完成与实际完成的差异，在挣值中，SV=EV-PV。其含义是：当SV>0时，进度提前，当SV<0时，进度落后。

可编辑word,供参考版！

成本偏差（CV）：是指一项活动的预算成本与该活动的的实际成本之间的差额，在挣值中，CV=EV-AC。其含义是：当CV>0时，成本节约，当CV<0时，成本超支。

进度执行指数（SPI）：是一项活动计划完成与实际完成的比值，在挣值中，SPI=EV/PV。其含义是：当SPI>1时，进度提前，当SPI<1时，进度落后。

成本执行指数（CPI）：是指一项活动的预算成本与该活动的的实际成本之间的比值，在挣值中，CPI=EV/AC。其含义是：当CPI>1时，成本节约，当CPI<1时，成本超支。

关于挣值的更多内容请参考PMBOK 4th Edition.

CMMI-ACQ：为采购方或采购专业领域的CMMI框架应用提供指导。这些执行方法主要在于供应者选择、供应者协议的起草、签订的必要活动，以及透过一组标准的度量、验收准则及供应者交付项目，来管理产品与服务的采购。CMMI-ACQ整合了对于采购方来说至为重要的知识体系，透过这些知识体系的整合，使得本模型可以为采购方在与供应者一起发展及维护产品与服务时，提供持续的解决方案。CMMI-DEV可以视为供应者在获取项目范围内，执行系统工程、软件开发、及硬件设计工作时的一项参考。

CMMI-DEV：用于产品和服务的开发方（以开发或维护产品和服务为商业目的企业）。

CMMI-SVC：向服务型企业、组织提供建立，管理，和交付服务提供指导，重点在于提供组织内部及外部客户服务的参考模式，服务范围覆盖所有的服务行业，并不仅仅限于IT服务业务。

ITIL：是英国政府中央计算机与电信管理中心（CCTA）在20世纪90年代初期发布的一套IT服务管理最佳实践指南，旨在解决IT服务质量不佳的情况。ITIL所强调的核心思想是应该从客户（业务）

可编辑word,供参考版！

而不是IT 服务提供方（技术）的角度理解IT 服务需求。也就是说，在提供IT服务的时候，我们首先应该考虑业务需求，根据业务需求来确定IT需求。

六、项目质量管理

名词：项目度量、产品度量、过程度量，度量有三个范畴，产品度量、项目度量和过程度量。

1、项目度量，反映项目状态，关注实际结果与计划或过程标准的偏差，用于项目监督和控制。

2、产品度量，对软件产品进行的、独立于产品生产过程的度量，通常关注重点是产品质量。

3、过程度量，量化了软件过程或开发环境的属性，对于成熟企业关注过程性能和能力的度量。广义的过程度量涵盖了这三部分。

七、敏捷专题

出现名词：Scrum、XP

1、Scrum基本原理：Scrum是经验型方法，是”可能性的艺术“ ，使得所有事项充分可见，使“秘密交易”最小化 ，其运作基础是个人和团队的承诺，而非严密的规划及控制。相对于强行控制计划，其忠诚度、自组织和员工责任感是更为有效的机制。团队成员只有事先集体负责，承诺在固定时间内交付实际产品后，才算真正掌握Scrum。

2、ScrumManager主要职责: 排除产品开发和负责人之间的障碍，确保产品负责人直接推动开发工作 ；教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标； 激发创造力和放权，从而改善开发团队的环境；千方百计提高开发团队的生产力 ；改善工程实践和工具，确保每个功

可编辑word,供参考版！

能增量都具备潜在可交付性；向各方确保团队工作进展实时更新并高度可视。

3、ScrumMaster与传统项目经理区别：从传统的控制者到引导者的转变

ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。

ScrumMaster使团队在Sprint过程中免受干预

产品负责人谈论业务需求和目标，团队则讲技术。由于产品负责人很难掌握技术，ScrumMaster的主要职责之一就是教会团队谈论商业需求和目标。团队与产品负责人之间的公分母是产品Backlog

4、极限编程（Extreme Programming，XP）是一种轻量级的、灵巧的、简单的软件工程方法。与传统的开发过程不同，极限编程的核心活动体现在需求→测试→编码→设计过程中。因此适用于规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求。

更多的资料:google 极限编程

【此文档部分内容来源于网络，如有侵权请告知删除，本文档可自行编辑和修改内容，感谢您的支持！】

可编辑word,供参考版！