软件工程经济学

1、软件工程经济学蔡坚勇第1章 为什么需要软件工程经济学两个案例的主要结论是：好的软件工程不仅关注编程，而且还要协调人与经济的因素。第一个案例得到的经验当我们开始面临实际的软件工程情况时，就会发现它们不仅包括编程问题，也包括非编程问题如操作问题、预算问题、进度问题，还有在决定用户需求的相对优先级时遇到的问题。绕过非编程问题，只关注编程，通常会导致随后的诸多麻烦经济学编程方案的主要价值在于，它使系统分析员能够从多个方面看问题从经济学角度分析软件工程的各种情况，能够得到更加令人满意的编程方案第二个案例得到的经验运用经济学原理时，不仅要从材料经济学角度考虑问题，还要从人类经济学(即社会经济学)角度考虑问

2、题。根据材料经济学方法做出的决策，将会带来诸如对有限自然资源的损耗等危险的长期后果，或者迫使人们从事的毫无意义的重复工作，如流水线之类的工作。软件工程经济学强调人类经济学方法，这是很重要的，将纯定量的面向货币的材料经济学方法进行扩展，从而使人们在做经济决策时，将对人际关系的定性考虑包括进去。材料经济学材料经济学是纯粹的定量经济学决策方法最初是在18、19世纪由Adam Smith等人提出，在20世纪由John Keynes等人精炼为高度形式化的学科材料经济学的主要指导原则所有的决策标准都可由货币等价物来表示机构应该根据利润最大化的原则做出决策材料经济学基于这样一个假设如果人与机构都遵循材料经济

3、学的指导原则行事，那么最大多数的人将受益主要优点使决策问题分析与解决起来相对简单，能相对方便地执行定量计划和控制活动对材料经济学的质疑近年来，很多人开始质疑这个假设的有效性有证据显示：根据材料经济学方法做出的决策，将会带来诸如对有限自然资源的损耗等危险的长期后果，或者迫使人们从事的毫无意义的重复工作，如流水线之类的工作。另一个破坏传统的材料经济学假设有效性的趋势是：从面向生产为主的经济，正在向以面向服务为主的经济转变的全球趋势。服务的基本目标是满足人们的需求，很显然，材料经济学方法需要进行扩展，应该考虑到评价服务有效性时所涉及的更为定性的人际关系方面。软件工程的核心作用软件工程在向面向服务经济

4、的过渡中起着核心作用软件工程经济学强调人类经济学方法，这是很重要的，将纯定量的面向货币的材料经济学方法进行扩展，从而使人们在做经济决策时，将对人际关系的定性考虑包括进去第2章 软件工程目标 编程专家总是将较大的系统进行简化或者分而治之，这样做能够使大多数编程问题易于处理。如果这样做是正确的（实际上也的确如此），那么我们如何证明：再在力求系统简单的同时考虑会使软件工程工作变得更复杂的人与经济因素是正确的？答案是双重的：不考虑人与经济因素，结果是我们负担不起的。前面的两个例子已经揭示了因为在软件工程中忽视了人与经济因素而带来的典型的令人不满的结果。通过在软件工程控制循环中嵌入分而治之的编程活动，并

5、在控制循环中包括根据一个更为全面的目标结构对编程产品进行定期的评审与迭代，能在很大程度上保留两种方法的优势。软件工程定义软件：是与系统，特别是计算机系统相关的一整套程序、过程、数据和相关文档。工程：是科学与数学的应用，通过这种应用使自然界中物质属性和能源在结构、机械、产品、系统和过程方面变得对人类有用。软件工程：软件工程是科学与数学的应用，通过这种应用，借助计算机程序、过程和相关文档，发挥计算机设备的能力，对人类有用。定义中包含的两个关键概念一是我们对软件的定义中，除了计算机程序之外，还包括很多东西因而，要成为一个好的软件工程师意味着除了学会如何编写计算机程序之外，还要学会很多其他技能。如学习

6、为计算机系统编制好的文档、数据库、运行过程等所需的技巧。二是“对人类有用”从实践的观点来看，这个短语说明作为软件工程师，应承担起责任以确保软件产品真正对人类有用。软件趋势软件是一个巨大的而且越来越昂贵的产品。软件对人类福利产生巨大的而且日益增长的影响。软件需求的增长很大程度上是源于这样一个事实：计算机硬件变得越来越便宜、可靠和种类繁多，人们发现对于机械性工作自动化能够带来越来越多的优点。软件工程目标结构两个子目标要在软件工程中获得完全成功，必须注意两个主要的子目标：实现一套成功的软件产品。执行一个成功的软件开发与维护过程。每个子目标都有三个相似的组成部分：人际关系资源工程程序工程成功的软件工程

7、是在这些子目标间实现适当平衡的结果，即软件产品和软件过程之间的平衡。GOALS方法软件工程的GOALS方法（生命周期软件面向目标方法）是一个过程，通过它，软件工程目标结构能用于指导我们如何详细说明、开发和维护软件GOALS是一种目标管理方法，其中的目标软件工作目标结构中的多元目标构成这样一来，GOALS方法的好处就与其他目标管理方法的好处相类似GOALS的主要好处为产品和过程目标建立明确的个人承诺为检查目标的完备性提供一个框架为达成目标建立起经过良好描述的子目标顺序如果某些子目标没有达成，能提供较早的警告为调和定量与定性目标提供检查点GOALS生命周期软件的面向目标方法Goal-Oriente

8、d Approach to Life-cycle Software定义：软件工程的GOALS方法是一个过程，通过它，软件工程目标结构能用于指导我们如何详细说明、开发和维护软件第3章 软件生命周期中的阶段及其活动软件生命周期的瀑布模型瀑布模型主要特点瀑布模型主要有如下的全局性特点：每一阶段都以验证与确认（V&V）活动作为结束，其目的是尽可能多地消除本阶段产品中存在的问题。在随后阶段里，尽可能对前面阶段的产品进行迭代。子目标的定义(1/3)瀑布模型生命周期中一个阶段的成功完成，与软件过程的程序工程目标序列中对应目标的实现相一致。这些子目标定义为以下活动的实现：1.可行性 定义软件产品的首选概念，并

9、确定其生命周期可行性以及与其它可选概念相比较的优势。2.需求 对软件产品所需功能、接口和性能要求的完整并经确认的说明书。3.产品设计 产品的整体软硬件体系结构、控制结构、数据结构及其他必要成分（如用户手册草稿和测试计划等）的完整并经确认的说明书。4.详细设计 每一个程序组件（100行源指令的例行程序）的控制结构、数据结构、界面关系、规模、关键算法、假设等的完整并经过确认的说明书。子目标的定义(2/3)5.编码 完整的并经过验证的程序组件集6.集成 由各软件组件组成的能完成适当功能的软件产品7.实施 全功能的可运行的软硬件系统，包括如程序、数据转换、安装和培训之类的目标8.维护 软硬件系统全部功

10、能的不断更新。每次更新都重复这个子目标9.淘汰 产品执行的功能清晰地过渡给继任者（如果有的话）子目标的定义(3/3)实现上述这些有序子目标的过程，一定会涉及到两个额外的程序工程子目标验证与确认（V&V）和配置管理（CM）在软件生命周期的每个阶段中都要使用到它们。对其作用描述如下：验证与确认（Verification and Validation）实现每一个程序工程生命周期子目标的一个重要组成部分，就是对它的中间软件产品能否确实满足目标的验证与确认。我们分别如下定义验证与确认：验证：确定软件产品与其说明书之间对应的真实性。确认：确定软件产品对于其操作任务是否适合或者是否有价值。瀑布模型经济学的两

11、个前提实现子目标瀑布模型的经济学基本原理是基于如下两个前提的：为了得到成功的软件产品，我们无论如何必须实现每个阶段所有的子目标。任何与模型不同的子目标实现顺序，都会使所构造的软件产品没那么成功。WBS为达到项目预算的计划和控制目的，把项目活动元素组成成一定的层次结构是非常有用的，这种层次结构被称之为工作分解结构(WBS)分层体系软件WBS包括两个分层体系，项目能以最适当的方式将两个分层体系关联起来。这两个分层体系是：产品分层体系，它表示各种软件组成部分（例程、模块、子系统等）如何协调地构成整个软件系统。活动分层体系，它表示处理软件组件的各项活动。产品分层体系活动分层体系软件工作分解结构实例第4

12、章 基本COCOMO模型根据软件产品中交付的源指令千行数（KDSI），来估算最普通软件产品开发所需人月（MM）的公式：MM=2.4(KDSI)1.05以月为单位来估算开发进度（TDEV）的公式TDEV=2.5(MM)0.38COCOMO模型的版本一般将COCOMO模型分为三个层次的模型：基本COCOMO模型：用于系统开发的初期，估算整个系统的工作量(包括软件维护)和软件开发所需要的时间；中间COCOMO模型：用于估算各个子系统的工作量和开发时间；详细COCOMO模型：用于估算独立的软部件，如子系统内部的各个模块。COCOMO模型的应用基础软件生命周期阶段和活动的定义附加的定义和假设附加的定义和

13、假设1基本的成本驱动因子是项目开发中交付的源指令（DSI）数。其定义如下：交付 这个术语通常意味着必须排除不可交付的支持软件，如测试驱动程序。然而，如果这些软件的开发需要付出与交付软件相同的努力，有其自身的评审、测试计划、文档等等，那么它们也应该计算在内。源指令 该术语包括由项目组成员编写的、并能又预处理程序、编译程序和汇编程序联合转换为机器人代码的所有程序指令。它不包括注释卡片和未经修改的公用软件。它包括作业控制语言、格式语句和数据申明。指令被定义为多行代码或卡片穿孔码。因此，一行中包含两条或更多条的源语句，应该算作一条指令附加的定义和假设2COCOMO成本估算所涵盖的开发期，开始于产品设计

14、阶段之初（对软件需求评审的成功完成；见表3-1），并且结束于集成与测试阶段之末（软件验收评审的成功完成）。其他阶段的成本和进度单独进行估算。3COCOMO模型成本估算包含并且仅仅包含图3-6b所示的那些软件工作分解结构（WBS）所显示的活动。因此，开发估算包括管理和文档编制的工作量，但不包括在开发期间发生的一些工作量，如用户培训、安装计划和移植计划。4COCOMO估算包括了上述假设3中说明的在项目里所有直接计费劳动力的活动。因此，它们应包括项目管理员和程序库管理员，但不包括计算机中心操作员、人事部门职员、秘书、高层管理人员、房屋管理员等等。附加的定义和假设5一个COCOMO人月由152小时的工

15、作时间组成。我们可以发现这与除去节日、假期和病假外余下的实际月平均工作时间是一致的。为了将以人月为单位的COCOMO估算转换成其他单位，使用如下方法：人时：乘以152人日：乘以19人年：除以126COCOMO估算假设项目能够得到开发人员和客户两方面的良好管理。例如，非生产性的闲散时间由管理员和用户控制得很小。附加的定义和假设7COCOMO假设需求说明书在计划与需求阶段完成之后不需要很大的改变。某些改进和重新说明是不可避免的，但任何重大的修改或新增的性能应该由修订的成本估算来反映。8详细COCOMO模型假设软件成本驱动因子的影响是依赖于阶段的。基本COCOMO模型和中间COCOMO模型除了区分开

16、发和维护阶段之外不作该假设。9阶段成本包括在该阶段发生的所有成本。因此，更新集成与测试计划、以及完成验收测试计划的成本，都包含在详细设计的阶段成本中。COCOMO软件开发过程特征COCOMO所假设的基础软件开发过程强调以下主要特征：1在整个系统设计的重要工作开始之前，先让相对较少的人员对软件需求说明书进行仔细的定义和确认。2在详细设计和编码的重要工作开始之前，由稍多一些但仍相对较少的一组人员对软件系统设计进行直至单元级别的仔细定义和确认。3由较多的一组程序员并行地执行详细设计、编码和单元测试，在一个基线稳定的系统设计框架内，通常依据计划好的增量开发过程来进行。4每个增量的集成及测试都是基于大量

17、的早期测试计划而进行的，并且几乎所有的错误排除都要经过走查和单元测试的过程。5为了给用户和开发人员提供产品运行性能的某些早期反馈，大量的文档编制工作在早期就开始进行。软件项目阶段、活动与里程碑人月估算与货币估算COCOMO模型避免以具体的一种货币为单位估算劳动力成本，因为在劳动力成本中应该包括哪些项（不承担管理费用？还是承担？包括退休金计划？办公室租金？利润？）的问题上，各机构之间存在巨大差异，而且，比起具体的货币、考虑到现行通货膨胀率和国际货币波动，人月是一个更加稳定的量。为了把COCOMO模型人月估算转换为货币估算，在简单性和准确性之间的最佳折衷方案是对每一主要阶段采用不同的每人月平均货币

18、数，以便说明通货膨胀和每一阶段中员工的薪金水平间的差异。基本COCOMO模型的工作量和进度公式组织型模式的软件项目，其基本工作量公式为：MM=2.4(KDSI)1.05对于组织型开发模式的软件项目，其基本进度公式为：TDEV=2.5(MM)0.38MM：人月TDEV：以月为单位来估算开发进度FSP：编码阶段所需的人员规模不经济经济学术语中，把在更大项目中生产率的降低称为规模不经济较大的软件产品出现规模不经济的主要原因如下：1为了编制能支持更多程序员并行工作所需的单元级的完整说明书，相对需要进行更多的产品设计。2验证与确认更多的需求和设计说明书相对需要更多的工作量。3即使有彻底定义的说明书，在较

19、大型项目中，程序员仍然需要花相对较多的时间进行交流和解决接口问题。4为集成单元模块，需要相对较多的集成活动。5一般来说，验证与确认软件产品相对需要较多的广泛测试。6管理项目需要相对较多的工作量年变化量（ACT）：在一年时间里（典型的），软件产品的小部分源指令所发生的变化通过增加或修改。给定估算的开发工作量(MM)D，则估算基本年维护量(MM)AM的COCOMO模型公式是:(MM)AM=1.0(ACT)(MM)D第5章 基本COCOMO模型的开发模式基本COCOMO模型，它只用1个预测变量（用交付源指令数所表示的规模）和3种软件开发模式来估算开发软件产品所需的工作量软件开发的三种COCOMO模式

20、组织型模式半独立模式嵌入模式组织型模式组织型模式是相对较小的软件团队在非常熟悉的内部环境中开发软件。与项目有关的大多数人在机构中有着相关系统的广泛开发经验，并且十分了解所开发的系统会对机构的目标产生怎样的影响。大多数项目人员能够在早期就对项目做出有益的贡献，在了解项目整体上是关于什么的、和其他每个人在做什么这些问题时，并不会产生大量的项目通讯费用。组织型模式组织型模式的项目对软件满足其需求和接口规格说明书的要求是相对比较宽松的。如果出现这样一种情况：要求软件产品与初始需求或接口说明书严格一致，将会引起大量返工，那么项目团队一般可以协商适当修改说明书，从而使开发更容易一些，而且对该说明书的修改用

21、户也比较容易接受。组织型模式这是组织型模式项目的生产率较高、而且规模不经济效应较小的另一个原因。组织型模式软件项目的其他因素特征是：一个总的来说还算稳定的开发环境，很少需要相关新硬件和操作系统程序的同时开发。对创新的数据处理体系与算法的需要最小。对项目提前完成的额外费用相对较低。相对较小的规模。几乎不存在组织型模式的项目开发出大于50 KDSI的新软件产品（较大 的组织型模式产品通常通过现有软件来开发的）。这些因素还趋向于与较高的项目生产率和较小的项目规模不经济效应相关联。三种模式之间的差别在生产率和规模效应上三种模式之间的差别是很显著的。半独立型模式的数据在这一点上还有所争议，但在组织型模式

22、和嵌入型模式之间的差别则是非常明显的。第6章 基本COCOMO模型的活动分布基本COCOMO模型包括按阶段的总体人员分布，它与雷利曲线模型十分相似。主要的区别如下：基本COCOMO模型直到产品设计全部完成并通过V&V之后，才给项目增加大量编程人员；这样，它向最多人员安排的接近比雷利曲线明显要晚，并且更为陡峭。COCOMO模型反映出在计划与需求阶段人员连续而缓慢的增加，而雷利曲线在产品设计阶段开始时是以零个人员作为起点的，然后迅速建起一个大型组织在前端增加了另外一个小雷利曲线以说明这一结果。第7章 中间COCOMO模型的产品级估算中间COCOMO模型，是对基本COCOMO模型的相兼容扩展，它所具

23、有的较高的精确性和详细程度使其更适于作为软件产品定义的更详细阶段中的成本估算。中间COCOMO模型包含15个附加的预测变量，它们说明了基本COCOMO模型未解释到的其余大量的软件项目成本变化因素。影响软件开发成本的因素类型应用类型；输入和输出的类型数；程序中输入输出指令、控制指令和算术指令的百分比；分析员和程序员的平均经验；所用的计算机配置和所使用的程序设计语言；产品决策中需要协同工作的人员数；项目活动中所需的人员出差次数。其他额外因素，如程序流的复杂性，分类的安全约束，以及对结构化编程技术、审查技术、自顶向下开发技术和主程序员组这些技术的使用等为了将大量的候选因素减少到相对便于管理的程度，从

24、而能用于实际的软件成本估算，对这些候选因素进行了两大类考察：通用性。这将排除那些在特定情况下，相对较小范围内才有意义的因素：如出差次数，分类的安全约束。独立性。在这一类考察中将排除那些与产品规模密切相关的因素（例如，输入输出的类型数），并将项目中那些高度相关的因素压缩成一个因素（例如，使用结构化程序设计和审查等技术，压缩成一个单一的“使用现代编程规范”因素）。中间COCOMO成本驱动因子属性中间COCOMO模型最终采用的15个因素的集合，或者说成本驱动因子属性被分为四类：软件产品属性计算机属性人员属性项目属性属性参数描述产品属性RELY所需的软件可靠性DATA数据库规模CPLX产品复杂性计算机

25、属性TIME执行时间约束STOR主存储器约束VIRT虚拟机的易变性TURN计算机周转时间人员属性ACAP分析员能力AEXP应用经验PCAP程序员能力VEXP虚拟机经验LEXP编程语言经验项目属性MODP现代编程规范TOOL软件工具的使用SCED所需的开发进度每个成本驱动因子属性确定一个因子，用于估算该属性对软件开发工作量的影响。将这些因子应用到一个标称COCOMO开发工作量估算，就可以得到对软件开发工作量的精确估算。采用同样的方法可以确定对软件维护工作量的精确估算。工作量因子中间COCOMO模型中工作量因子可用于维护阶段和开发阶段。对于大多数成本驱动因子属性，我们可以很安全地假设工作量因子对于维护阶段和开发阶段都是一样的。对于这些成本驱动因子，我们能简单地计算出成本驱动等级差别带来的调整：维护人员比开发人员具有更多（更少）经验；维护阶段较好（较差）的计算机响应时间等。SCED不能用于维护阶段的成本驱动因子：SCED开发成本驱