项目管理名词解释

AlexQin

原帖由 husthxd 于 2009-7-28 17:39 发表


呵呵，偶的理解：
QA:保证做对的事情(通过检查流程)
QC:保证把事情做对(通过检查产品)

也就是说，QA负责的是过程，QC负责的是结果。
就像做数学证明题一样
用户给出了一个证明题
Dev Team负责做题；
QA负责监督过程，要保证Dev Team用的方法、理论、公式、定理等是符合这个命题的；即“保证做对的事情”
而QC相当于老师，他去评卷，去判断这个证明题的演推是否正确？即“保证把事情做对”

AlexQin

原帖由 husthxd 于 2009-7-28 17:35 发表
单元测试（Unit Test）：是对软件中的基本组成单位进行的测试，如Java类中的一个方法、Oracle后台的一个存储过程或函数等等。大多数情况下，单元测试往往由程序员自行完成，谁编码，谁负责；
集成测试（Integration Test）：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。由测试人员、系统分析员或PM负责；
系统测试（System Test）：是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法；
确认(验收)测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是由客户对分发的软件进行的测试；
回归测试：回归测试是进行修改之后进行的验证测试。其目的是检验对软件进行的修改是否正确，包括bug是否已修复，是否产生新的bug等。

对于集成测试，我觉得除了要检查软件单元之间的接口是否正确之外，还应该包括这些单元组合之后，成为一个新的大单元，是否能正确运行

china50

原帖由 husthxd 于 2009-7-28 17:38 发表


习惯使用两种类型的需求：
涉众需求（STR）即业务需求和需求规约（SRS）即系统规格需求。
对这三种需求的区别，老谷最好可以举例说明一下了

SRS是 System Requirements Specification，还是Software Requirements Specification？

husthxd

原帖由 china50 于 2009-7-29 09:32 发表


SRS是 System Requirements Specification，还是Software Requirements Specification？

System Requirements Specification，系统需求规约。

husthxd

2009.6.23出现的名词：TQC

TQC：是英文Total Quality Control(全面质量管理)的简写。全面质量管理是将组织的所有管理职能纳入质量管理的范畴，强调一个组织以质量为中心、以全员参与为基础，强调全员的教育和培训。

husthxd

2009.6.30 项目估算 出现的名词：FP、IFPUG、LOC
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法。

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数，求出人月数表示的系统规模。再乘上每人月的单价，即得到系统开发成本的估算。

以上摘自http://arronxiao.blog.ccidnet.co ... 9137-uid-11600.html

LOC（ Line of Code），即代码行。

[ 本帖最后由 husthxd 于 2009-7-29 10:49 编辑 ]

husthxd

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之间没有任何关系。

husthxd

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

husthxd

2009.7.14 甲、乙方项目监控－项目管理MSN群线上讨论4
出现的名词：挣值管理、CMMI-SVC、CMMI-ACQ、CMMI-DEV、ITIL

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

计划值（PV）包含两个内容：实际的计划工作加上为完成该计划工作所批准的预算,先前被称作“计划工作的预算成本” （BCWS，Budgeted Cost of Work Scheduled）；
挣值（EV）也包含两个内容：实际完成的工作加上该工作批准的预算。在给定的时间内（通常为从项目开始至今），为已完成的（部分）活动批准的成本预算（可能包括分摊的开销，例如一般管理费用）总额。先前被称作“已完成工作的预算费用”（BCWP，Budgeted Cost of Work Performed）；
实际成本（AC）是指在给定的时间范围内，完成工作所引起的、与计划值和挣值（他们有时仅是直接人工工时，或仅是直接成本，或是包括间接成本在内的所有成本）范围内任何预算成本相关的全部成本。先前被称作“已完成工作实际费用”（ACWP，Actual Cost of Work Performed）。在项目管理中运用挣值分析时，需要建立项目的工作分解结枚（WBS），编制切合实际的工作进度计划，定期地对项目执行中的各个参数进行数据检测，并根据检测结果对项目进行调整和预测。

挣值管理的目的是在保证质量目标不变的前提下，通过对偏差的分析尽早的对项目完工时的最终进度与成本做出预测，并分析偏差产生的原因，实施相应的纠正措施，从而降低项目风险。在使用挣值管理方法进行偏差分析时所采用的评价指标是：进度偏差（SV），成本偏差（CV），进度绩效指数（SPI），成本绩效指数（CPI）。
　　进度偏差（SV）：是指一项活动计划完成与实际完成的差异，在挣值中，SV=EV-PV。其含义是：当SV>0时，进度提前，当SV<0时，进度落后。
　　成本偏差（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所强调的核心思想是应该从客户（业务）而不是IT 服务提供方（技术）的角度理解IT 服务需求。也就是说，在提供IT服务的时候，我们首先应该考虑业务需求，根据业务需求来确定IT需求。

[ 本帖最后由 husthxd 于 2009-7-29 11:28 编辑 ]

pharos

小栋哥辛苦了！