作者：李爱萍 崔冬华 李东生
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件工程(工业和信息化普通高等教育“十二五”规划教材)试读：
前言
自1968年第一届NATO会议上首次提出“软件工程”的概念至今，已经过去了四十多年，软件工程得到了很大发展，不断出现新方法、新技术和新模型，形成了软件工程领域的基础理论、工程方法和技术体系，具备了学科的完整性和教育学特色。2011年2月我国国务院学位委员会在新修订的学科目录中，将软件工程（学科代码为0835）增设为一级学科，进一步促进了软件工程的发展。
软件工程课程是高等学校计算机科学与技术、软件工程等专业的一门重要的专业核心课程，是信息类专业的推荐课程，也是每一个从事软件分析、设计、开发、测试、管理和维护人员的必备知识。
本书按照面向过程和面向对象两种开发方法，对软件生存周期各个阶段的基础理论和相关技术进行了介绍，同时给出两种不同方法的实验指导，比较全面地反映了软件工程的全貌。本书可用于高等学校相关专业的教学。
全书由3篇共计16章组成，按专题安排，便于组织教学。
第一篇为面向过程的软件工程，以传统的软件生存周期为主线，介绍软件工程的原理和方法。第1章介绍软件工程相关的基本概念。第2章至第8章按照软件生存周期的各个阶段顺序介绍可行性研究、需求分析、软件总体设计、详细设计、软件编码、软件测试和软件维护，详细介绍有关概念和软件工程方法，重点介绍结构化的分析和设计方法。
第二篇内容为面向对象的软件工程，以UML为主线，结合当前流行的开源工具StarUML，介绍面向对象软件工程的原理和方法。第9章为面向对象方法学以及面向对象的基本概念介绍；第10章介绍面向对象分析的过程，并给出一个面向对象软件开发过程案例的分析；第11章介绍面向对象设计与实现；第12章介绍软件开发工具StarUML的整体功能及其应用，并以一个教学管理系统实例介绍使用 StarUML 完成整个系统的分析、设计的全过程；第13章介绍几种典型的软件体系结构；第14章是设计模式简介；第15章介绍软件工程领域的一些最新技术。
第三篇给出了软件工程的实验环节要求和示例，包括面向过程的软件工程和面向对象的软件工程两种不同开发方法的实验要求，并通过两个典型的案例具体说明两类软件工程实验的具体实施步骤。
本书由长期从事软件工程教学和科研的教师编写。李爱萍、崔冬华同志负责全书架构的设计和统稿。本书共16章，其中第1章、第2章、第3章、第4章由崔冬华编写，第5章、第6章、第7章由武昭宇编写，第9章、第14章和附录由李新编写，第10.6节由李东生编写，第3.7节、4.4节、第10章、第11章、第12章由段利国编写，第8章、第13章、第15章、第16章由李爱萍编写，研究生马俊伟参与了StarUML工具的应用作图部分的相关工作。
本书编写过程中参考了国内外有关软件工程的专著、教材和论文，详见书后的主要参考文献。在此，向所有作者表示谢意。
由于软件工程近年来的快速发展以及作者水平所限，书中若存在错误和不足之处，敬请读者提出宝贵意见和建议。作者2014年1月第1篇面向过程的软件工程
第1章 概述
第2章 可行性研究
第3章 软件需求分析
第4章 软件总体设计
第5章 软件详细设计
第6章 软件编码
第7章 软件测试
第8章 软件维护第1章概述“软件工程”一词是由北大西洋公约组织（North Atlantic Treaty Organization，NATO）的计算机科学家在联邦德国召开的国际会议上首次提出来的。产生软件工程这门学科的时代背景是“软件危机”。软件工程的发展和应用不仅缓和了软件危机，而且促使一门新兴的工程学科诞生了。
软件工程是应用计算机科学、工程学、管理学及数学的原则、方法来创建软件的学科，它对指导软件开发、质量控制以及开发过程的管理起着非常重要的作用。本章介绍软件和软件工程的基本概念，包括软件、软件危机、软件工程方法学、软件过程和软件生存周期模型，传统软件工程与面向对象软件工程等，从而使读者对软件工程与软件开发技术有所认识。1.1 软件和软件危机1.1.1 软件的定义、特点及分类
1．软件的定义
软件不是程序，而是程序、数据以及开发、使用和维护程序需要的所有文档的完整集合。1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。其中的方法和规则通常是在文档中说明并在程序中实现的。特别是当软件成为商品时，相关的文档资料是必不可少的。没有相关文档，仅有程序是不能称为软件产品的。
程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列。它是由软件开发人员设计和编码的。程序执行时一般要输入一定的数据，也会输出运行的结果。而文档则是软件开发活动的记录，主要供人们阅读，既可用于专业人员和用户之间的通信和交流，也可以用于软件开发过程的管理和运行阶段的维护。我国国家标准局已参照国际标准，陆续颁布了《计算机软件开发规范》、《计算机软件需求说明编制指南》、《计算机软件测试文件编制规范》、《计算机软件配置管理计划规范》等文档规范。为了提高软件开发的效率和方便软件产品的维护，现在的软件人员越来越重视文档的作用及其标准化工作。
2．软件的特点
为了能全面、正确地理解计算机和软件，必须了解软件的特点。软件是一种特殊的产品，与传统的工业产品相比，它具有以下一些独特的特点。（1）软件是一种逻辑产品，而不是具体的物理实体，具有抽象性，人们可以把它记录在纸上，保存在计算机内存、磁盘和光盘等存储介质上，但却无法看到软件本身的形态，必须通过观察、分析、思考、判断以及通过计算机的执行才能了解到它的功能和作用。（2）软件产品的生产主要是开发研制，没有明显的制造过程。软件开发研制完成后，通过复制可以产生大量软件产品，所以对软件的质量控制，必须着重在软件开发方面下功夫。（3）软件产品在使用过程中，不存在磨损、消耗、老化等问题。但软件在运行时，为了适应软件硬件、环境以及需求的变化而进行修改、完善时，会引入一些新的错误，从而使软件退化，在修改的成本变得让人们难以接受时，软件就被抛弃，生存期停止。（4）软件产品的开发主要是脑力劳动，还未完全摆脱手工开发方式，大部分产品是“定做的”，生产效率低。（5）软件产品的成本相当昂贵，软件费用不断增加，软件的研制需要投入大量的人力、物力和资金，生产过程中还需对产品进行质量控制，对每件产品进行严格的检验。（6）软件对硬件和环境有不同程度的依赖性，为了减少这种依赖性，在软件开发中提出了软件的可移植性问题。（7）软件是复杂的。软件是人类有史以来生产的复杂度最高的工业产品，软件是一个庞大的逻辑系统。软件开发，尤其是应用软件的开发常常涉及其他领域的专门知识，这就对软件开发人员提出了很高的要求。
3．软件的分类
计算机软件发展非常迅速，其内容十分丰富，要给计算机软件做出科学的分类是比较困难的。传统意义上从计算机系统角度看，软件分为两大类：系统软件和应用软件。系统软件是指管理、控制和维护计算机及外设，以及提供计算机与用户界面等的软件，如操作系统、各种语言的编译系统、数据库管理系统及网络软件等。应用软件是指能解决某一应用领域问题的软件，如财会软件、通信软件、计算机辅助教学（CAI）软件等。
若从计算机软件用途来划分，大致分为服务类、维护类和操作管理类。（1）服务类软件。此类软件是面向用户的，为用户提供各种服务，包括多种软件开发工具和常用的库函数及多种语言的集成化软件，如Windows下的Visual C++软件等。（2）维护类软件。此类软件是面向计算机维护的，包括错误诊断和检测软件、测试软件、多种调试所用软件如Debug等。（3）操作管理软件。此类软件是面向计算机操作和管理的，包括各种操作系统、网络通信系统、计算机管理软件等。1.1.2 软件危机的定义及表现形式
1．软件危机“软件危机”是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机主要包含了两方面的问题：一是如何开发软件以满足软件日益增长的需求；二是如何维护数量不断增长的已有软件。
2．软件危机表现形式（1）对软件开发成本和研制进度的估计常常很不精确。经费预算经常突破，完成时间一拖再拖。这种现象降低了软件开发组织的信誉，而且有时为了赶进度和节约成本所采取的一些权宜之计又往往影响了软件产品的质量，从而不可避免地会引起用户的不满。（2）“已完成”的软件不能满足用户要求。软件开发人员常常在对用户需求只有模糊的了解，甚至对所要解决的问题还没有确切认识的情况下，就匆忙着手编写程序了。软件开发人员和用户又未能及时交换意见，使得一些问题不能得到及时解决，导致开发的软件不能满足用户要求，使得开发失败。（3）软件产品质量差，可靠性得不到保证。软件质量保证技术（审查、复审和测试）还没有坚持不懈地应用到软件开发的全过程中，提交给用户的软件质量差，在运行中暴露大量问题。（4）软件产品可维护性差，软件开发人员在开发过程中按各自的风格工作，各行其是，没有统一、公认的规范和完整规范的文档，发现问题后进行杂乱无章的修改。程序结构不好，运行时发现错误也很难修改，导致维护性差。（5）软件成本在计算机系统总成本中所占的比例逐年上升。软件的发展跟不上硬件的发展。由于微电子技术的进步和生产自动化程度的不断提高，硬件成本逐年下降，然而软件开发需要大量人力，软件成本也随着通货膨胀以及软件规模和数量的不断扩大而持续上升。（6）软件开发生产率提高的速度远远跟不上计算机应用速度普及深入的趋势。软件的发展跟不上用户的要求。软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。
以上列举的仅仅是软件危机的典型表现，与软件开发和维护有关的问题远远不止这些。1.1.3 软件危机的产生原因及解决途径
1．产生软件危机的原因
造成上述软件危机的原因与软件自身特点有关，也与软件开发人员在开发和维护时所采用的生产方式、方法、技术有关，可概括为以下几个方面。（1）软件是计算机系统中的逻辑部件。软件产品往往规模庞大，结构复杂，这给软件的开发和维护带来客观的困难。（2）软件开发的管理困难。软件规模大、结构复杂，又具有无形性，这导致管理困难，进度控制困难，质量控制困难，可靠性无法保证。（3）软件开发费用不断增加，维护费用急剧上升，直接威胁计算机应用的扩大。（4）软件开发技术落后。在20世纪60年代，人们注重如编译原理、操作系统原理、数据库原理等一些计算机理论问题的研究，而不注重软件开发技术的研究，用户要求的软件复杂性与软件技术解决复杂性的能力不相适应。（5）生产方式落后。有人统计，硬件的性能价格比在过去30年6中增长了10。一种新器件的出现，其性能较旧器件提高，价格反而有所下降，而软件则相形见绌。软件规模与复杂性增长了几个数量级，但生产方式仍然采用个体手工方式开发，根据个人习惯爱好工作，无章可循，无规范可依靠，带有很强的“个性化”特征的程序，因缺乏文档而根本不能维护，加剧了供需之间的矛盾。（6）开发工具落后，生产效率提高缓慢。软件开发工具趋于原始，没有出现高效率的开发工具，因而软件生产效率低下。还有软件开发人员忽视需求分析的重要性，轻视软件维护也是造成软件危机的原因。
2．解决软件危机途径
目前，计算机的应用日益广泛，世界上发达国家的许多企业将全部投资的10%以上用于计算机领域。但到目前为止，计算机的体系结构在硬件上仍然是冯·诺依曼计算机。实际中复杂、庞大的问题，只能由专门人员编制软件来解决。假设计算机能实现智能化，能进行推理和运算，正确解决用户所提出的问题，那么软件危机就会有根本性的缓解。然而新一代计算机体系结构的研制可能还需要一段时间。那么在目前计算机硬件条件下，要想解决软件危机必须解决以下问题。（1）首先应该对计算机软件有一个正确的认识，彻底清除“软件就是程序”的错误观念。（2）要使用好的开发技术和方法，并且要不断研究探索更好更有效的技术和方法。尽快消除在计算机系统早期发展阶段形成的一些错误观念和做法。（3）要有良好的组织、严密的管理，各类人员要相互配合，共同完成任务。充分认识软件开发不是某种个体劳动的神秘技巧。（4）应该开发和使用好的软件工具。正如机械工具可以“放大”人类的体力一样，软件工具也可以“放大”人类的智力，从而可以有效提高软件生产率。
软件系统开发与制造一台机器或建造一栋大厦有许多相同之处，所以要采用“工程化”的思想做指导来解决软件研究中面临的困难和混乱，从而走出软件危机的困境。1.2 软件工程1.2.1 软件工程的定义及目标
1．软件工程
软件工程是指导计算机软件开发和维护的一门工程学科。软件工程采用工程的概念、原理、技术和方法来开发和维护软件。
人们曾从不同的角度给软件工程下过各种定义，下面给出两种比较典型的定义。
1968年，在第一届NATO会议上曾经给出了软件工程的一种早期定义：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。”这个定义不仅指出了软件工程的目标是经济地开发出高质量的软件，而且强调了软件工程是一门工程学科，它应该建立并使用完善的工程原理。
1993年，IEEE进一步给出了一个更全面更具体的定义：“软件工程是：① 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件开发；② 研究① 中提到的途径。”
虽然软件工程的不同定义使用了不同的词句，强调的重点也有所差异，但是它的中心思想是把软件当作一种工业产品，要求“采用工程化的原理和方法对软件进行计划、开发和维护。”宗旨是为了提高软件生产率、降低生产成本，以较小的代价获得高质量的软件产品。
2．软件工程基本目标
软件工程是一门工程性学科，目的是成功地建造一个大型软件系统。所谓成功是指要达到以下几个目标：（1）降低软件开发成本；（2）满足用户要求的全部软件功能；（3）符合用户要求，令用户满意的软件性能；（4）具有较好的易用性、可重用性和可移植性；（5）较低的维护成本，较高的可靠性；（6）按合同要求完成开发任务，及时交付用户使用。1.2.2 软件工程的研究内容和基本原理
1．软件工程的研究内容
软件工程的主要研究内容是软件开发技术和软件开发过程管理两个方面。在软件开发技术方面，主要研究软件开发方法、软件开发过程、软件开发工具和技术。在软件开发过程管理方面，主要研究软件工程经济学和软件管理学。技术与管理是软件开发中缺一不可的两个方面。没有科学的管理，再先进的技术也不能充分发挥作用。
2．软件工程的基本原理
自从1968年“软件工程”正式提出并使用以来，从事软件工程研究的世界各国专家学者先后提出l00余条关于软件工程的准则。著名的软件工程学家B.W.Boehm综合有关专家和学者的意见，总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程7条基本原理。他认为这7条基本原理是确保软件产品质量和开发效率原理的最小集合。它们之间相互独立，其中任意6条原理的组合都不能代替另一条原理，因此，它们是缺一不可的最小集合。下面简单介绍软件工程的7条基本原理。（1）用分阶段的生存周期计划严格管理
阶段划分为计划、分析、设计、编程、测试和运行维护。B.W.Boehm认为在软件的整个生存周期中应该制定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运行维护计划。（2）坚持进行阶段评审
上一阶段评审没有通过，就不能进入下一阶段工作。在软件生存周期的每个阶段都要进行严格的评审，以便尽早发现在软件开发中犯下的错误并及时改正，对于保证软件质量、提高开发效率是非常重要的。（3）实行严格的产品控制
尽管面向对象软件开发支持用户需求变化，但是在开发过程中，改变一项要求是要付出较高代价的。在实际开发过程中，由于外部环境等的变化，相应地改变用户需求是一种客观需要，是难免的，显然不能硬性禁止用户提出改变需求的要求，而只是依据科学的产品控制技术来适应这种要求。（4）采用现代程序设计技术
实践表明，采用先进的程序设计技术既可以提高软件的开发效率，又可以提高软件的维护效率。面向对象技术在许多领域已经取代了传统的结构化开发方法。软件的开发效率、可维护性、可重用性都有一定程度的提高。（5）结果应能清楚地审查
软件产品是一种逻辑产品，软件开发工作的进度情况可见性差，很难准确度量，使得软件产品的开发过程比一般产品的开发过程更难以评价和管理。为了提高软件开发过程的可见性，更好地进行组织和管理，应该根据软件产品的总目标及完成期限，规定开发人员的责任和各阶段产品标准，从而使得软件开发每一阶段所得到的结果能够清楚地审查。（6）开发小组人员应该少而精
B.W.Boehm总结多年从事软件开发的实践经验得出这条基本原理，其含义是，开发小组的组成人员应该具有高素质、高水平，而人数不宜太多。软件开发组人员的素质和数量是影响软件产品质量和开发效率的关键因素。（7）承认不断改进软件工程实践的必要性
遵循以上7条基本原理，就可以实现软件的工程化生产，但并不能保证软件开发和维护的过程能与时代前进同步，能随着技术的发展而进步。因此，B.W.Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原理。按照这条基本原理，应该把主动采纳的软件开发技术和软件工程实践中总结的经验作为软件工程的基本原理。1.2.3 软件工程的发展史
软件工程是随着计算机系统的发展而逐步形成的计算机科学领域中的一门新兴学科。软件工程的发展经过了3个时代。
1．程序设计时代
1946年到1956年为程序设计年代。这个时代人们用很大力气研究和发展计算机硬件，经历了从电子管计算机到晶体管计算机的变革，然而对计算机软件的研究和发展却不够重视。当时，由于硬件的价格昂贵，运行速度低，内存容量小，所以当时的程序员非常强调“程序设计技巧”，把缩短每一个微秒的CPU时间和节省每一个二进制存储单元，作为程序设计的重要目标，但设计的程序难读、难懂、难修改。
2．程序系统时代
1956年到1968年为程序系统时代，或者程序+说明时代。在这个时代硬件经历了从晶体管计算机到集成电路计算机的变革，CPU速度和内存容量都有了很大的提高，从而为计算机在众多领域中的应用提供了潜在的可能性。这个时代的另一个重要特征是出现了“软件作坊”。这是因为随着计算机应用的普及和深化，需要的软件往往规模相当庞大，以致单个用户无法开发，此外许多不同的部门和企业往往需要相同或者类似的软件，各自开发就会浪费很大人力。在这种形势下，“软件作坊”就应运而生了。不过这个时代的开发方法基本上沿用了程序设计时代的开发方法，但开始提出了结构化的方法。随着计算机应用日益普及，软件需求量急剧增长，用户的需求和使用环境发生变化时，软件可修改性很差，往往需要重新编制程序，其研制时间很长，不能及时满足用户要求，质量得不到保证，开发人员的素质和落后的开发技术不适应规模大、结构复杂的软件开发，因此产生了尖锐的矛盾，所谓的“软件危机”便由此产生了。
IBM公司的360 OS和美国空军后勤系统，在开发过程中都花费了几千人/年的工作量，最后以失败告终。其中360 OS由4000个模块组成，共约100万条指令，花费了5000人/年的工作量，经费达数千万美元，拖延几年才交付使用，交付使用后每年发现近100个错误，结果以失败告终。360 OS开发负责人Brooks生动描述了研制过程中的困难和混乱：“……像巨兽陷入泥潭作垂死挣扎，挣扎得越猛，泥浆就沾得越多，最后没有一个野兽能逃脱淹没在泥潭中的命运……程序设计就像这样的泥潭，一批批程序员在泥潭中挣扎……没有料到问题会这样棘手……”。比360 OS更糟的软件系统并不少，即花费大量的人力、物力、财力结果半途而废，或者说完成之日就是遗弃之时。这就是人们常说的“软件危机”。
3．软件工程时代
1968 年至今为软件工程年代，或者程序+文档时代。这个时代硬件发展的特点是集成电路计算机发展到超大规模集成电路计算机，高性能低成本的微处理机大量出现，硬件速度的发展已经超过人们提供支持软件的能力。然而，硬件只提供了潜在的计算能力，对于复杂的大型软件开发项目，需要十分复杂的计算机软件才能实现。也就是说，如果没有软件来驾驭和开发的这种能力，人类并不能有效地使用计算机。在这个时代，软件维护费用、软件价格不断上升，没有完全摆脱软件危机。1.3 软件过程和软件的生存周期1.3.1 软件过程
ISO 9000把软件过程定义为：“把输入转化为输出的一组彼此相关的资源和活动”。
软件过程是为了获得高质量所需要完成的一系列任务的框架，它规定了完成多项任务的工作步骤。其中框架由几个重要过程组成，包括用来获取、供应、开发、操作和维护软件所用的基本的、一致的要求。各种组织和开发机构可以根据具体情况进行选择和取舍。
软件开发过程是把用户要求转化为软件需求，把软件需求转化为设计，用代码来实现设计，对代码进行测试，完成各阶段的文档编制，并确认软件可以投入运行使用的过程。1.3.2 软件生存周期
软件生存周期是借用工程中产品生存周期的概念而得来的，是指某一软件项目从被提出并着手实现开始，直到该软件报废或停止使用为止所经历的时间。生存周期是软件工程的一个重要概念，把整个生存周期划分为若干个阶段，是实现软件生产工程化的重要步骤。赋予每个阶段相对独立的任务，每个阶段都有技术复审和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，及时决定系统是继续进行，还是停止或是返工。
软件的生存周期一般分为软件计划、软件开发和软件运行3个时期。软件计划时期一般有问题定义和可行性研究两个阶段；开发时期有需求分析、软件设计（包括概要设计、详细设计）、编码和测试4个阶段；运行时期主要是维护阶段。图1.1列出了一个典型的软件生存周期。下面结合该图说明软件生存周期各阶段的主要任务。图1.1 典型的软件生存周期
1．计划时期
计划时期的主要任务是调查用户需求，分析新系统的主要目标，分析开发该系统的可行性。用户提出一个软件开发要求后，系统分析员首先要分析该软件项目的性质是什么，通过对用户和使用部门负责人的访问和调查，开会讨论即可得到解决。因此，用户和系统分析员的相互理解与配合是搞好这一时期工作的关键。（1）问题定义
问题定义是计划时期的第一步。这一步必须回答的问题是“用户需要计算机解决的问题是什么”。由系统分析员根据对问题的理解，提出关于“系统目标与范围的说明”，请用户审查和认可。（2）可行性研究
在对问题的性质、目标、规模清楚之后，还要确定该问题有没有行得通的解决办法。在这个阶段要为前一步提出的问题寻找一种以上在技术上可行，且在经济上有较高效益的可操作解决方案。为此，系统分析员应在高层次上做一次简化的、抽象的需求分析和概要设计，探索这个问题是否值得去解决。最后写出可行性研究报告。有时可行性研究报告要包含“系统流程图”，用来描述新系统（含硬件与软件）的组成。
2．开发时期
开发时期要完成设计、编码和测试3大任务。其中设计任务用需求分析、概要设计和详细设计3个阶段完成。（1）需求分析
需求分析阶段仍然不是具体地解决问题。其任务在于弄清用户对目标系统的全部需求，准确地确定“目标系统必须做什么”，确定目标系统必须具备哪些功能。
用户了解它们所面对的问题，知道必须做什么，但通常不能完整而准确地表达它们的需求，当然也不知道怎么利用计算机解决它们的问题。而软件开发人员虽然知道怎么用软件完成人们提出的各种功能要求，但是对用户领域内的业务和具体要求并不完全清楚。因此系统分析员在这个阶段必须和用户密切配合，充分交流信息，在此基础上用“需求规格说明书”的形式准确地表达出来。需求规格说明书应包括对软件的功能需求、性能需求、环境约束和外部接口等的描述。这些文档既是对用户确认的系统逻辑模型的描述，也是下一步进行设计的依据。（2）概要设计
概要设计又称总体设计。这个阶段必须回答的关键问题是“怎么做”，即应该怎样实现目标系统。主要任务是将需求转变为软件的表示形式。开发人员要把确定的各项功能需求转换成需求的体系结构，即从需求规格说明书导出软件结构图，确定由哪些模块组成及模块之间的关系。同时还要设计该项目的应用系统的总体数据结构和数据库结构。（3）详细设计
详细设计阶段不是编写程序，这个阶段的任务是要回答“应该怎样具体地实现这个系统”。为概要设计阶段得到的软件结构图中的每个模块完成的功能进行具体描述，要把功能描述转变为精确的、结构化的过程描述，即确定实现模块功能所需要的算法和数据结构，并用相应的详细设计工具表示出来。（4）编码
这一阶段是按照选定的语言，把设计的每一个模块的过程性描述翻译为计算机可接受的源程序。写出的程序应该与设计相一致，并且结构好，清晰易读。（5）测试
测试是开发时期的最后一个阶段，是保证软件质量的重要手段。按照不同的层次，又可细分为单元测试、集成测试、验收测试。单元测试也称模块测试，是查找各模块在功能和结构上存在的问题；集成测试也称组装测试，是将各模块按一定顺序组装起来的测试，主要是查找各模块之间接口上存在的问题；验收测试也称确认测试，是按照需求规格说明书的规定，由用户参加的对目标系统进行验收。
3．运行时期
软件人员在这一时期的主要工作是做好软件维护。运行时期是软件生存周期的最后一个时期，也是时间最长的阶段。已交付的软件投入正式使用后，便进入软件维护阶段，它可以持续几年甚至几十年。软件在运行过程中可能会发现潜藏的错误，需要对它们进行诊断和改正，称为改正性维护；也可能是为了适应变化了的软件工作环境而需要做适应性维护；也可能是在软件漫长的运行时期，用户业务发生变化往往会对软件提出新的功能要求和性能要求，这种增加软件功能、增强软件性能的维护称为完善性维护；另外还有一些其他维护，如为了提高软件的可维护性和可靠性而对软件修改的预防性维护。1.4 软件开发模型
建模是软件工程最常使用的一种技术。所谓软件开发模型，就是为整个软件建立的模型。模型是为了理解事物而对事物做出的一种抽象。过去几十年，已先后出现了多种软件开发模型，包括传统模型、演化模型和面向对象模型等。它们各有特色，分别适用于不同特征的软件项目，但一般都包含“计划”、“开发”和“维护”3类活动。“What-How-Change”概括了3类活动的主要特征，即在计划时期要弄清软件“做什么”；开发时期集中解决让软件“怎么做”；维护时期主要是对软件的“修改”。目前具体的软件开发模型包括几十种，如瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、构件集成模型、转换模型和净室模型等。在不同的软件开发模型中，所用的方法与工具也可能随所用的模型而不同。下面介绍其中一些软件开发模型。1.4.1 瀑布模型
软件开发的瀑布模型也称生存周期模型或线性顺序模型，是W. Royce于1970年首先提出来的。这种模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括问题定义、可行性研究、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，恰如奔流不息拾级而下的瀑布。在20世纪80年代之前，这种瀑布模型一直是唯一被广泛采用的生存周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程基本上可以用瀑布模型来描述，而且是以文档为驱动，适合于需求很明确的软件项目开发的模型。
图 1.1 所示的是按照传统的瀑布模型生存周期的各阶段出现的顺序，大致介绍了它的全过程。目的是向读者展示各阶段的主要任务，以及它们之间的联系。现在再深入一步，考察一下瀑布模型的特点，了解贯穿在整个生存周期的几个重要的观点。明确了这些观点之后，才可以在实际的软件开发中发挥更大的主动性和灵活性，使软件工程方法更好地得到应用。（1）阶段的顺序性和依赖性
这个观点有两重含义：首先必须等前一阶段的工作完成之后，才能开始后一阶段的工作；其次前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。图1.2显示了阶段之间的顺序和依赖关系。（2）推迟实现的观点
对于软件工程实践经验少的软件开发人员，接到软件开发任务以后，总想尽早开始编写程序，急于求成，但是实践证明，对于中、大规模软件项目来说，往往是编码工作开始得越早，最终完成开发工作所需要的时间就越长。这是因为前一阶段工作做得不够扎实，有缺陷，在这种情况下过早地考虑编写程序，常常造成大量返工，有时甚至给开发人员带来灾难性的后果，造成无法弥补的局面。
瀑布模型在编码之前是分析阶段和设计阶段。这两个阶段的任务是考虑目标系统的逻辑模型，不涉及软件的物理实现。把逻辑设计与物理设计清楚地区分开，是按照瀑布模型开发软件的一条重要的指导思想。（3）质量保证的观点
软件工程的重要目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的各个阶段都应该坚持以下两点重要的做法。
① 每一个阶段都必须完成所规定的相应文档，没有交出合格文档就是没有完成该阶段的任务。完整、准确地规范文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。
② 每一个阶段结束之前都必须对已完成的文档进行评审，以便尽早发现问题，纠正错误。从图 1.2 可以看出，越是早期阶段犯下的错误，暴露出来的时间就越晚，排除故障改正错误所需付出的代价就越高。因此，及时审查是保证软件质量降低软件开发成本的重要措施。图1.2 瀑布模型各阶段的相互关系（4）存在的问题
传统的瀑布模型，在促进软件开发工程化方面起了很大的作用。但是，按照瀑布模型来开发软件，只有当分析员能够做出准确的需求分析时，才能得到预期的正确结果。它是一种理想的线性开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。由于大多数用户不熟悉计算机，系统分析员对用户领域的专业知识也往往不甚了解，因而很难在软件开发的初始阶段清楚地给出完整的需求。F. Brooks曾经断言：“在对软件产品的某个版本试用之前，要用户（即使有软件工程师的配合）完全、精确和正确地对一个现代软件产品提出确切的需求，在实际上是不可能的”。为了克服瀑布模型的不足，人们提出了若干其他模型。1.4.2 快速原型模型
快速原型模型的主要思想是：首先快速建立一个能够反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践让用户了解未来目标系统的概貌，以便判断哪些功能是符合需要的，哪些方面需要改进。用户会提出许多改进意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……，这样反复改进，最终建立完全符合用户需求的新系统。
开发原型模型的目的是为了增进软件开发人员和用户对系统服务的理解，如果每开发一个软件都要先建立一个原型，成本就会成倍增加，因为它不像硬件或其他有形产品，先制造出一台“样机”，成功后可以成批生产，而软件属于单件生产。为此，在建立原型时应采取如下方法。（1）为了减少原型系统的开销，可以采用一些特殊的有别于通常软件开发时使用的技术和工具，可以采用功能很强的甚高级语言实现原型系统，如Unix支持的SHELL语言就是一种功能很强的甚高级语言，它执行速度比较慢，但它所需成本比用普通程序设计语言开发时低得多。在建立原型模型时这个优点是非常重要的。原型系统的另外一个长处是可以在各种不同类型的计算机上运行，暂不考虑速度、空间等性能效率方面的要求；不考虑错误恢复和处理。（2）如何产生最终的软件产品？可以把原型系统作为基础，考虑到原型系统的界面是与用户通信的“窗口”部分，通过这个“窗口”用户最容易获取信息和发表自己的意见。原型系统的界面要设计得简单易学，且最好与最终软件系统的界面相容。通过补充与修改获得最终的软件系统。但在实际中由于开发原型系统使用的语言效率低等原因，除了少数简单的事务系统外，大多数原型模型都废弃不用，仅把建立原型模型的过程当作帮助定义软件需求的一种手段。
图1.3显示了简洁的快速原型软件开发的生存期模型。可以看出它是一种循环进化的过程，用户的参与和反馈，使得这种方法开发出来的系统能够更好地满足用户的需求。图1.3 快速原型模型法生存期模型1.4.3 增量模型
增量模型也称为渐增模型，是瀑布模型的顺序特征和快速原型法的迭代特征相结合的产物。它是一种非整体开发的模型。软件在模型中是“逐渐”开发出来的，把软件产品作为一系列的增量构件来设计、编码、组装和测试。每个构件由多个相互作用的模型构成，并且能够完成特定的功能。开发出一部分，向用户展示一部分，可让用户及早看到部分软件，及早发现问题，如图1.4所示。图1.4 增量模型
第一个构件的规格说明文档完成后，规格说明组转向第二个构件的规格说明，与此同时设计组开始设计第一个构件……这种方法表明不同的构件将并行构建，有可能加快工程，但是这种方法会冒所有构件集成不到一起的风险，因此必须密切地监控整个开发工程，否则将事与愿违。例如，如果用增量模型开发一个大型的字处理软件，第一个增量构件提供基本的、核心的文件管理、文档编辑与生成功能；第二个增量构件提供更完善的文档编辑与生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件提供完成高级的页面排版功能。把软件产品分解为增量构件时，构件的规模要适中。另外，特别注意与新增量构件集成到现在软件中时，所形成的产品必须是可测试的。增量模型具有较大的灵活性，适合于软件要求不明确，设计方案有一定风险的软件项目。1.4.4 螺旋模型
螺旋模型是目前实际软件项目开发中比较常用的一种开发模型。对于一些复杂的大型软件开发总存在一些风险，而螺旋模型则加入了瀑布模型与增量模型都忽略了的风险分析，即将两种模型结合起来，弥补了两种模型的不足。它是一种风险驱动的模型。在软件开发中，普遍存在着各种各样的风险，对于不同的软件项目，其开发风险有大有小。在制定项目开发计划时，对项目的预算、进度与人力，对用户的需求、设计中采用的技术及存在的问题，都要仔细分析与估算。实践证明，项目越大，软件越复杂，估算中的不确定因素就越多，承担的风险也就越大。软件风险可能在不同程度上损害了软件开发过程和软件产品的质量，严重时可能导致软件开发的失败。因此，在软件开发过程中必须及时识别和分析风险，并且采取一定的措施，消除或降低风险的危害。
螺旋模型是一种迭代模型，它把开发过程分为几个螺旋周期，每迭代一次，螺旋线就前进一周，如图1.5所示。图1.5 螺旋模型
它的基本思想是，使用原型及其他方法来尽量降低风险，当项目按照顺时针方向沿螺旋移动时，每一个螺旋周期均包含了风险分析，可以把它看作是在每一个阶段之前都增加了风险分析的快速原型模型。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期可分为4个步骤来进行。首先，确定该阶段的目标，选择方案并设定这些方案的约束条件；其次，从风险角度分析、评估方案，通常用建造原型的方法来消除风险；第三，如果成功地消除了所有风险，则实施本周期的软件开发；最后，评价该阶段的开发工作，并计划下一阶段的工作。
螺旋模型适合于大规模高风险的软件项目开发，它吸收了软件工程“演化”的概念。当软件随着过程的进展而演化时，使开发人员和用户都能更好地了解每个螺旋周期演化存在的风险，从而做出相应的对策。螺旋模型的优势在于它是风险驱动的，因而使用该模型需要有相当丰富的风险评估经验和这方面的专门技术，这使该模型的应用受到一定限制。因此如果一个大的风险未被发现和控制，其后果是很严重的。1.4.5 喷泉模型
喷泉模型是一种比较典型的面向对象软件开发模型，以用户需求为动力，以对象作为驱动的模型，适合面向对象的开发方法。这克服了瀑布模型不支持软件重用和多项开发活动集成的局限性，喷泉模型使开发过程具有迭代性和无间隙性，如图1.6所示。图1.6 喷泉模型
系统某些部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。无间隙性是指在开发活动，即分析、设计和实现之间不存在明显的边界。1.4.6 基于构件的开发模型
面向对象的软件开发技术将事物封装成包含数据和加工该数据操作的对象，并抽象成类。经过一定的设计和实现的类可称为构件，它们可以在不同的计算机软件系统中复用，在某个领域具有一定的通用性。将这些构件储存起来成为一个构件库，为基于构件的软件开发模型提供了技术基础。
基于构件的开发模型是利用预先封装的软件构件来构造应用软件系统，从而提高软件的重用性和可靠性。1.4.7 统一过程（RUP）模型
软件统一开发过程是经过近 40 多年的发展形成的，它是基于面向对象统一建模语言UML（Unified Modeling Language）的一种面向对象的软件过程模型。它是汲取了多种生存周期模型的先进思想和丰富的实践经验而产生的。RUP（Rational Unified Process）是一个通用的过程框架，可以用于各种不同模型的软件系统，各种不同的应用领域和不同规模的项目。RUP的特点是由用例驱动，以构件为中心，采用迭代和增量的开发策略。RUP软件生存周期是一个二维的软件开发模型。1.4.8 基于形式化的开发模型
变换模型和净室模型是两种比较典型的适合于形式化开发的模型。
变换模型是结合形式化软件开发方法和程序自动生成技术的一种软件开发模型。它采用严格的、数学的表示体系来表示软件规格说明，从软件需求形式化说明开始，经过一系列变换，最终得到了系统的目标程序。
净室模型是一种形式化的增量开发模型。其基本思想是力求在分析和设计阶段就消除缺陷，确保正确，然后在无错误或“净室”的状态下实现软件的开发。1.5 传统的软件工程和面向对象的软件工程
程序设计语言可划分为“面向过程程序设计”和“面向对象程序设计”，那么软件工程也可区分为“面向过程软件工程即传统软件工程”和“面向对象软件工程”。传统软件工程是以结构化程序设计为基础，面向对象软件工程是以面向对象程序设计为基础。1.5.1 传统软件工程方法
传统的软件工程开发过程采用结构化技术来完成软件开发的各项任务，这是最早的软件开发方法。传统的软件工程的具体过程如下。（1）采用结构化分析、结构化设计和结构化实现完成软件开发的各项任务。（2）把软件生存周期划分成若干个阶段，然后顺序完成各个阶段的任务。（3）每一个阶段的开始和结束都有严格标准，前一阶段结束的标准是后一阶段工作开始的标准。（4）在每一阶段结束之前，必须正式地进行严格的技术审查和管理复审。
这些技术是建立在软件生存周期概念基础上的，因此结构化技术与瀑布模型紧密地结合在一起了，快速原型、增量、螺旋等模型实际上都是从瀑布模型拓展或演变而来的。1.5.2 面向对象软件工程方法
面向对象的开发方法的重点是放在软件生存周期的分析阶段。因为面向对象方法在开发的早期就定义了一系列面向问题领域的对象，即建立了对象模型，整个开发过程统一使用这些对象，并不过分充实和扩展对象模型，所以面向对象开发过程的特点是：开发阶段界限模糊，开发过程逐步求精，开发活动反复迭代。通常开发活动是在分析、设计和实现阶段的反复迭代。1.5.3 传统软件工程和面向对象软件工程的分析方法对比
与面向过程的软件工程的开发思想相比，面向对象开发方法不再是以功能划分为导向，而是以对象作为整个问题分析的中心，围绕对象展开系统的分析与设计工作。
在开发过程方面，面向对象软件工程和传统软件工程一样也是把软件开发划分为分析、设计、编码和测试等几个阶段，但各个阶段的具体工作不同，除了在编码阶段使用的语言不同外，面向对象软件工程为待开发软件确定“类与对象”一般在需求分析阶段进行，设计阶段则主要完成对象内部的详细设计；而在传统软件工程中，将软件设计划分为“总体设计”和“详细设计”，分别完成软件的总体结构图的设计和各个模块内部算法的详细设计。即：传统软件工程开发过程包括需求分析、总体设计、详细设计、面向过程的编码和测试；面向对象软件工程开发过程包括需求分析与对象抽取、对象详细设计、面向对象的编码和测试。本章小结
本章对计算机软件工程学做了一个简短的概述，使读者对软件工程的基本原理和方法有了概括的本质的认识。软件工程自1968年提出至今，正式发展成为用于指导软件生产工程化，覆盖软件开发方法学、软件工具和环境，软件工程管理学等内容的一门学科。随着编程语言从结构化程序设计发展到面向对象程序设计，软件工程也由传统的软件工程演变为面向对象的软件工程。
本章主要介绍了软件工程的基本内容，包括软件工程的学科背景、软件生存周期理论、软件开发模型、软件工程方法论等，这些知识都是后续章节的基础。习题1
1.1 什么是软件？软件和程序的区别是什么？
1.2 什么是软件生存周期？划分生存周期的主要原则是什么？
1.3 什么是软件危机？它有哪些主要表现？为什么会产生软件危机？
1.4 什么是软件工程？怎样利用软件工程消除软件危机？
1.5 何谓面向对象软件工程？简述它和传统软件工程的区别与联系。
1.6 什么是软件生存周期模型？试比较本章介绍的4种模型的优缺点，说明每种模型的使用范围。第2章可行性研究
在进行任何一项较大的工程时，首先要进行可行性分析和研究，对于软件项目开发也同样需要进行可行性分析和研究，首先要对有关的历史现状和经济前景做出调查，对各种可能方案进行可行性研究，并比较其优劣。只有认真进行了可行性研究，才会避免或者减轻项目开发后期可能出现的困境。2.1 可行性研究的目的和任务
可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。但是，这个阶段的目的不是解决用户提出的问题，而是确定这个问题是否值得去解决。其主要任务是，首先需要进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制，必须分析几种可能解法的利弊，从而判定原定系统的目标和规模是否现实，系统完成后带来的效益是否大到值得投资开发这个系统的程度。因此，可行性研究实际上就是一次大大简化了的系统分析和系统设计的过程，即以抽象的方式进行分析和研究。
首先需要进一步分析和澄清前一步的问题定义。之后，分析员进行简要的需求分析，导出该系统的逻辑模型，然后从系统逻辑模型出发，探索出若干种主要解法。对每种解法都要仔细、认真研究它的可行性，一般都要从经济、技术、操作和法律4个方面来研究每种解法的可行性，做出明确结论来供用户参考。
1．经济可行性
首先要进行成本—效益分析。从开发所需的成本和资源，潜在的市场前景等方面进行估算，确定要开发的项目是否值得投资开发，即要分析在整个软件生存周期中所花费的代价与得到的效益之间的度量。
2．技术可行性
对要开发项目的功能、性能和限制条件进行分析，评价系统所采用的技术是否先进，使用现在的技术能否实现系统达到的目标，现在技术人员的技术水平是否具备等。
3．操作可行性
系统的操作方式在这个应用范围内是否行得通。
4．法律可行性
新系统的开发会不会在社会上或政治上引起侵权，可能导致的责任，有无违法问题；应从合同的责任、专利权、版权等一系列权益方面予以考虑。2.2 可行性研究的步骤
怎样进行可行性研究，比较典型的可行性研究一般要经过下述一些步骤。
1．复查并确定系统规模和目标
分析员对关键人员进行调查访问，仔细阅读和分析有关材料，以便对问题定义阶段书写的关于系统的规模和目标的报告书进行进一步的复查和确认，清晰地描述对目标系统的一切限制和约束，改正模糊或不确切的叙述，确保分析员正在解决的问题确实是用户要求他解决的问题，这是这一步的关键。
2．研究目前正在使用的系统
目前正在使用的系统可能是一个人工操作系统，也可能是旧的计算机系统，旧的系统必然有某些缺陷，因而需要开发一个新的系统且必须能解决旧系统中存在的问题，那么现有的系统就是信息的重要来源。人们需要研究现有系统的基本功能，存在哪些问题，运行现有系统需要多少费用，对新系统有什么新要求，新系统运行时能否减少使用费用等。
应该仔细收集、阅读、研究和分析现有系统的文档资料和使用手册，实地考察现有系统。观察现有系统可以做什么，为什么这样做，有何缺点，使用代价及与其他系统的联系等，但并不了解它怎样做这些工作。分析员在考察的基础上，访问有关人员，画出描绘现有系统的高层系统流程图（见 2.3 节），与有关人员一起审查该系统流程图是否正确，为目标系统的实现提供参考。
3．建立新系统的高层逻辑模型
比较理想的设计通常总是从现有的物理系统出发，推导出现有系统的逻辑模型，由此再设想目标系统的逻辑模型，从而构造新的物理系统，然后使用建立逻辑模型的工具——数据流图和数据字典（参看本书3.4.3小节和3.4.4小节）来描绘数据在系统中的流动和处理情况。数据流图和数据字典共同定义了新系统的逻辑模型，为目标系统的设计打下了基础。但要注意，现在还不是软件需要分析阶段，只是概括地描绘高层的数据处理和流动。
4．导出和评价各种方案
分析员建立了新系统的高层逻辑模型之后，分析员和用户有必要一起再复查问题的定义、工程规模和目标，如有疑义，应予以修改，直到提出的逻辑模型完全符合系统目标为止。在此基础上分析员从他建立的系统逻辑模型出发，进一步导出若干个较高层次（较抽象的）物理解法，根据经济可行性、技术可行性、操作可行性、法律可行性对各种方案进行评估，去掉行不通的解，就得到了可行的解法。
5．推荐可行方案
根据可行性研究结果，分析员应做出关键性的决定，即这项工程是否值得去开发。如果值得开发，应该选择一种最好的解法，并说明该方案是可行的原因和理由。特别是对所推荐的可行方案要进行比较详细的成本/效益分析，供使用部门决策。
6．草拟初步的开发计划
计划中除工程进度表之外，还应估计对各种开发人员和各种软、硬件资源的需要情况，初步估计系统生存周期每个阶段的成本，给出需求分析阶段的详细进度表和成本估计。
7．编写可行性研究报告提交审查
应该把上述可行性研究各个步骤的结果写成可行性研究报告，提请用户和使用部门仔细审查，从而决定该项目是否进行开发，是否接受分析员推荐的方案。2.3 系统流程图
在可行性研究阶段和以后的一些阶段常常要描绘现在系统和目标系统的概貌，其传统的工具就是系统流程图。系统流程图是描述物理系统的工具。所谓物理系统，就是一个具体实现的系统。一个系统可以包含人员、硬件、软件等多个子系统。系统流程图的作用就是用图形符号以黑盒子形式描述组成系统的主要成分（硬件设备、程序、文档及各类人工过程等）。在系统流程图中，某些符号和程序流程图的符号形式相同，但是它却是物理数据流程图而不是程序流程图。程序流程图表示对信息进行加工处理的控制过程，而系统流程图表达的是信息在系统各部件之间流动情况。要注意区分它们之间的差别。2.3.1 系统流程图的符号
系统流程图符号中有5种基本符号是从程序流程图中借用来的（见图2.1），当以概括方式抽象描绘一个实际系统时，仅用此5种符号足够了，但需要更具体地描绘一个物理系统时，还需要使用图2.2中列出的11种系统符号。图2.1 基本的系统流程图符号图2.2 系统流程图符号2.3.2 系统流程图示例
下面通过一个简单的具体例子来说明系统流程图的用法。【例 2.1】 某校办工厂有一个库房，存放该厂生产需要的各种零件器材，库房中的各种零件器材的数量及其库存量临界值等数据记录在库存主文件上，当库房中零件器材数量发生变化时，应更改库存文件。若某种零件器材的库存量少于库存临界值，则立即报告采购部门以便订货，规定每天向采购部门送一份采购报告。
该校办工厂使用一台小型计算机处理更新库存文件和产生订货报告的任务。零件器材的发放和接受称为变更记录，由键盘输入到计算机中。系统中库存清单程序对变更记录进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息记录写在联机存储上。最后，每天由报告生成程序读一次联机存储，并且打印出订货报告。图2.3给出了该系统流程图。图2.3 库存管理系统的系统流程图
系统流程图的习惯画法是使信息在图中自顶向下或从左向右流动。2.4 成本—效益分析
成本—效益分析的目的是从经济角度评价开发一个新的软件项目是否可行。通过评估新的软件项目所需要的成本和可能产生的效益，便可以从经济上衡量这个项目的开发价值。这一分析在可行性研究报告中占有重要的地位。
系统成本包括开发成本和运行维护成本。
系统效益包括有形的经济效益和无形的社会效益两种。有形效益可以用货币的时间价值、投资回收期、纯收入等指标进行度量，很难直接进行量的比较。例如，计算机软件开发公司因售后服务欠佳而失去了用户，就属于无形效益。下面主要介绍有形的效益分析。2.4.1 货币的时间价值
成本估算的目的是对项目投资。经过成本估算后，得到项目开发时需要的费用，该费用就是项目的投资。项目完成后，应取得相应的效益。有多少效益才划算？这就应该考虑货币的时间价值。因为投资是现在进行的，而效益是将来获得的。
通常用利率的形式表示货币的时间价值。假设年利率为i，如果现在存入P元，则n年后可得到的钱数为F，若不记复利则F = P *（1 + n * i）
这也就是P元钱在n年后的价值。反之，如果n年后能收入F元钱，那么这些钱现在的价值是P = F /（1 + n * i）
试读结束[说明：试读内容隐藏了图片]