「软件工程」编程生产力概述
首席架构师2020-05-06 23:06
编程生产力（也称为软件生产力或开发生产力）描述单个程序员或开发团队构建和发展软件系统的能力程度。传统上，生产力是指软件生产量与软件成本之比。这里的微妙之处在于找到一种合理的方法来定义软件数量。
术语
生产力是制造业、组织心理学、工业工程、战略管理、财务、会计、市场营销和经济学等学科研究的重要课题。分析层次包括个人、团体、部门、组织和国家层面[5]。由于这种多样性，尽管已经进行了一个多世纪的研究，但对生产力及其影响因素没有明确的定义。像在软件工程中一样，对于什么才是真正的生产力缺乏共识，被认为是对生产力进行实质性讨论的主要障碍。[1]以下定义描述了对术语的最佳共识。[2]
生产力
虽然对生产率的定义没有达成共识，但似乎有一种共识，即生产率描述了产出与投入之间的比率：
生产力=产出/投入
然而，在不同的学科中，可以找到不同的概念，特别是不同的输入和输出测量单位。制造业通常使用生产单位数量和消耗单位数量之间的直接关系。[3]非制造业通常使用工时或类似单位来比较产出和投入。
一个基本的一致意见是，生产力的含义和衡量生产力的方法取决于所评估的环境。在制造业公司，可能的情况是：[2]
- 单个机器或制造系统；
- 制造功能，例如装配；
- 单个产品或一组相关产品的制造过程；
- 工厂；以及
- 公司的整个工厂系统
只要传统的生产过程被认为是一个直接的生产力衡量标准，它就很简单：一个特定质量的产品有多少单位是由哪种成本生产的。对于智力工作来说，生产力要复杂得多。我们如何衡量作者、科学家或工程师的生产力？由于知识工作（相对于手工工作）的重要性日益提高，[4]许多研究人员试图开发可应用于非制造环境的生产率测量方法。人们普遍认为，知识工作的性质与手工工作有着根本的不同，因此，除了简单的产出/投入比之外，还需要考虑其他因素，例如质量、及时性、自主性、项目成功、客户满意度和创新。然而，这两个学科的研究团体都未能建立广泛适用和公认的生产力测量方法。[5]对于更具体的编程生产力领域也是如此。
盈利能力
盈利能力和业绩是紧密相连的，事实上，它们常常混淆不清。然而，由于盈利能力通常被定义为收入与成本的比率
盈利能力=收入/成本
它的范围比绩效更广，即影响盈利能力的因素数量大于影响生产率的因素数量。特别是，盈利能力可以在不改变生产力的情况下改变，例如，由于成本或价格上涨等外部条件。除此之外，生产率和盈利能力之间的相互依赖性通常被延迟，即生产率的提高很少反映在短期盈利能力的提高更可能在长期实现。
绩效
绩效这个术语甚至比生产力和盈利能力更广泛，涵盖了影响公司成功的众多因素。因此，众所周知的绩效控制工具，如平衡计分卡，确实将生产率作为一个中心因素，但并非唯一因素。其他相关因素包括客户或利益相关者对公司的看法。
效率（Efficiency） 和效力（Effectiveness）
效率和有效性是一些术语，它们本身常常混淆在一起，而且效率常常与生产率混淆在一起。效率和效率之间的区别通常被非正式地解释为效率就是正确地做事情（efficiency is doing things right ），有效性就是做正确的事情（effectiveness is doing the right things ）。虽然有许多其他定义，[2]有一种共识，即效率指的是资源的利用，主要影响生产率所需的投入。另一方面，效率主要影响生产率的产出，因为它通常对客户有直接的影响。有效性可以定义为“达到预期产出的能力”。
一般来说，假定效率（efficiency ）可以量化，例如通过利用率，比效率容易得多。
质量
Tangen说：“质量的提高，除了没有错误的产品增加了输出水平之外，不应该包括在生产力的概念中。”[2]然而，大多数非软件学科的经典文献，特别是在制造领域，没有明确讨论产出质量在生产率中的作用。[6]最近非制造业学科的研究更侧重于知识、办公室或白领工作，因此越来越多地讨论质量对质量的作用。[4][5][7][8][9]
德鲁克强调了质量对评价知识型员工生产力的重要性：“因此，知识型员工的生产力必须首先以获得质量为目标，而不是以最低质量为目标，而是以最佳质量（如果不是最高质量）为目标。只有这样，人们才能问：“工作量是多少？”[四]
萨里用他对生产力的扩展公式抓住了质量的重要性：[8]
总生产率=（产出质量和数量）/（投入质量和数量）
然而，这些将质量纳入生产力测定的努力似乎还没有形成一个可操作的概念。目前还不清楚如何量化“产出质量和数量”以及“投入质量和数量”这两个模糊术语，更不用说计算比率了。
编程生产力的现状
在软件开发中，事情比商品的生产更复杂。软件开发是一个工程过程。
可可莫II（COCOMO II）
Boehm是最早系统地研究软件生产力领域的研究人员之一。他的成本估算模型COCOMO——现在的COCOMO II[10]——是标准的软件工程知识。在这个模型中，他定义了一组影响生产率的因素，比如所需的可靠性或分析师的能力。这些因素在其他类似的生产率方法中得到了广泛的重用。模型的其余部分基于函数点，最后是源代码行（LOC）。LOC作为一种生产力测量方法的局限性是众所周知的。
琼斯的软件生产力（Jones's Software Productivity）
琼斯是一系列关于软件生产力的书的作者。除了一些理论上的考虑，他的主要贡献是系统地提供和整合大量与生产力分析相关的数据。在他的至少两本书中，[11][12]他给出了一些生产力因素，但同时也指出，对于每个项目，不同的一组因素是有影响的。这些因素可以构成生产力评估和与工业平均值比较的基础。
这是一个这样的列表：
根据历史数据确定对软件项目的量化影响的20个因素如下：
- 使用的编程语言
- 程序大小
- 程序员和设计人员的经验
- 需求的新颖性
- 程序及其数据的复杂性
- 结构化编程方法的使用
- 程序类或方法分布
- 应用领域的程序类型
- 工具和环境条件
- 增强现有程序或系统
- 维护现有程序或系统
- 重用现有模块和标准设计
- 程序生成器
- 第四代语言
- 开发地点的地理分隔
- 潜在缺陷及消除方法
- （现有）文档
- 主要开发开始前的原型设计
- 项目组和组织结构
- 员工士气和薪酬[12]
功能点
Albrecht于1977年提出功能点，作为比LOC更好的软件尺寸度量。在这种情况下，它是基于软件的规格说明，因此旨在衡量其功能的大小，而不是代码本身。原因是代码的大小不仅取决于功能的大小，还取决于程序员的能力：更好的程序员将为相同的功能生成更少的代码。多年来，功能点经历了几次重新设计，主要由国际功能点用户组（IFPUG）驱动。该集团规模庞大，有1200多家公司作为成员，这表明该措施得到了相当强烈的接受。然而，在许多领域，它仍然缺乏实际应用，因为它通常被认为只适用于业务信息系统。
基于价值的软件工程
一些研究者提出经济驱动或基于价值的软件工程是未来软件工程研究的重要范式。Boehm和Huang指出，不仅要跟踪软件项目的成本，还要跟踪实际的挣值，即对客户的价值。[13]他们解释说，创建软件业务案例并使其保持最新状态非常重要。从本质上讲，基于价值的软件工程关注的是客户价值，主要以货币单位来衡量。
人用品 （Peopleware）
de Marco和Lister的著名著作《Peopleware:Productive Projects and Teams》（Peopleware:Productive Projects and Teams）将与人相关的因素的重要性吸引到了更广泛的受众的注意。他们在许多软件项目中收集了对团队生产力有影响的好的和坏的管理实践的经验。他们和其他人表明，这些是软件工程中的决定性问题，但只能用轶事来描述。
影响编程效率的因素
可能有很多因素影响个人和团队的编程效率。例如，所使用的软件开发过程可能会影响团队的有效性和效率。
软件程序员的个性会影响所使用的编码风格，进而影响程序员的工作效率。
