软件工程概述

软件和软件危机

什么是软件？

  软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。其中：

  程序是按事先设计的功能和性能要求执行的指令序列；

  数据是使程序能正常操纵信息的数据结构；

  文档是与程序开发、维护和使用有关的图文材料。
软件的特点

  软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性；

  软件的生产与硬件不同，在它的开发中没有明显的制造过程。对软件的质量控制，必须着重在软件开发方面下功夫；

  与硬件不同，软件在运行和使用期间，没有机械磨损、老化问题。

  硬件磨损：可以用备用零件替换；

  软件出故障：无法用备用零件替换来解决，是因为设计开发过程中存在错误；

软件维护比硬件维护更复杂，它与硬件的维修有本质差别：

              

  虽然软件不存在磨损与老化，但它存在退化问题。软件退化缘于修改。

关于Bugs的术语：

  human mistake、error（错误）：指软件开发中的人为出错；

  fault（错误、缺陷、瑕疵）：人为错误所导致的工作产品缺陷；

  failure（故障、失效）：对用户而言，指相对于系统预期行为的偏离

软件工程

何谓软件工程

  软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

软件工程的基本原理

  著名的软件工程专家B．W．Boehm于1983年提出了软件工程的七条基本原理。他认为这七条原理是确保软件产品质量和开发效率的原理的最小集合：

  1.用分阶段的生命周期计划严格管理；

  把软件生命周期划分成若干阶段，并相应制定出切实可行的计划，并严格按照计划对软件的开发与维护工作进行管理；

  2.坚持进行阶段评审；

 大部分错误是在编码之前造成的，例如，根据Boehm等人的统计，设计错误占软件错误的63％，编码错误仅占37％；

 错误发现与改正得越晚，所需付出的代价也越高。

  3.实行严格的产品控制；

 当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。；

 所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分(各个阶段产生的文档或程序代码)。

 基准配置管理也称为变动控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。

  4.采用现代程序设计技术；

  实践表明，采用先进的技术既可提高软件开发和维护的效率，又可提高软件产品的质量。

  5.结果应能清楚地审查；

  为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。

  6.开发小组的成员应该少而精；

  开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。

  7.承认不断改进软件工程实践的必要性。

  不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验，评价新的软件技术的效果，指明必须着重开发的软件工具和应该优先研究的技术。

软件工程方法学

  通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（methodology），也称为范型（paradigm）。

  软件工程方法学包含三个要素：方法、工具和过程。

 

  方法：完成软件开发的各项任务的技术方法，回答“怎样做”的问题；

  工具：软件工具为软件工程方法提供了自动或半自动的软件支撑环境；

  如果这些工具能够集成起来，即一个工具产生的信息可被另一个工具使用时，称这样的支持软件开发的系统为CASE（计算机辅助软件工程）

  过程：是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的步骤，将软件工程的方法和工具综合起来以达到合理、及时地进行软件开发的目的。它定义了：

  方法使用的顺序；

  要求交付的文档资料；

  为保证质量和适应变化所需要的管理；

  软件开发各个阶段完成的里程碑。

  目前使用得最广泛的软件工程方法学分别是传统方法学和面向对象方法学。

  传统方法学又称生命周期方法学或结构化范型。

  采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。

  把软件生命周期的全过程划分为若干个阶段：

  前一阶段是基础、前提；后一阶段是细化；

  每一个阶段的开始和结束都有严格的标准；

  在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审；
  优点：

  通过将软件生命周期划分成若干个阶段降低了整个软件开发过程的困难程度；

  每个阶段结束前的严格审查保证了软件的质量，提高了软件的可维护性。

  缺点：

  当软件规模庞大，或者对软件的需求是模糊的或会随时间而变化的时候，使用传统方法学开发软件往往不成功，而且维护起来仍然很困难。

  原因：把原本密切相关的数据和操作人为地分离成了两个独立的部分，增加了软件开发与维护的难度。

  面向对象方法学

  面向对象方法学是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。

  面向对象方法学的4个要点：

  把对象作为融合了数据及在数据上的操作行为的统一的软件构件；
  把所有对象都划分成类；

  按照父类与子类的关系，把若干个相关类组成一个类层次结构，位于下层的类继承了上层中某类的特点；

  对象彼此间仅能通过发送消息互相联系。  

  “面向对象=对象+类+继承+通信”

  面向对象方法学的出发点和基本原则，是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，从而使描述问题的问题空间与实现解法的求解空间在结构上尽可能一致。
  优点：

  降低了软件产品的复杂性；

  提高了软件的可理解性；

  简化了软件的开发和维护工作；

  促进了软件重用。

软件工程涉及的人员角色

  角色（Role）：一种职责对应关系。

  通常情况下，软件工程涉及的人员分为三种角色：

  客户（Customer）：花钱开发软件系统的公司、组织或个人；

  开发者（Developer）：为客户构建软件系统的公司、组织或个人；

  用户（User）：最终使用该系统的人员。

  引发角色交叉的新情况：通用商业软件包（Commercial off-the-shelf， COTS）、转包（Subcontract）

软件工程与其他学科的关系

  软件工程应用计算机科学、数学和管理科学等原理，借鉴传统工程的原则、方法来创建软件，从而达到提高质量、降低成本的目的。其中：

  计算机科学和数学用于构造模型、分析算法；

  工程科学用于制定规范、明确范型、评估成本、确定权衡；

  管理科学用于进度、资源、质量、成本等的管理。

软件生命周期

  概括地说，软件生命周期由 软件定义、软件开发 和 运行维护 3 个时期组成，每个时期又进一步划分成若干个阶段。
  软件定义时期：

   问题定义阶段 ：界定问题的范围，确切地定义问题；

  可行性研究阶段 ：研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法；

  需求分析阶段 ：确定目标系统必须具备哪些功能；

  另外，要估计完成该项工程所需要的资源和成本，制定工程进度表。
  软件开发时期：

  具体设计和实现在前一个时期定义的软件。

  总体设计阶段：设计出实现目标系统的几种可能的方案，权衡利弊推荐一最佳方案，并制定实现最佳方案的详细计划，以及设计软件的体系结构；

  详细设计阶段：设计出程序的详细规格说明；

  编码和单元测试阶段：写出正确的、容易理解、容易维护的程序模块；

  综合测试阶段：通过各种类型的测试使软件达到预定的要求。集成测试/验收测试/现场测试/平行运行。

  运行维护时期： 

  维护阶段的关键任务是：通过各种必要的维护活动使软件系统持久地满足用户的需要。通常的4种维护活动：

  改正性维护：诊断和改正使用过程中发现的软件错误；

  适应性维护：修改软件以适应环境的变化；

  完善性维护：根据用户需要改进或扩充软件使之更完善；

  预防性维护：修改软件从而为将来的维护活动做好准备。

软件开发团队的成员

  维护人员：这个角色可能包括上面所有角色

  文档库管理员：组织和维护项目文档、记录软件的开发过程

  配置管理小组：维护变更、控制变更、确保变更正确实现、报告变更

软件过程

  软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
  瀑布模型特点

  阶段间具有顺序性和依赖性

  必须等前一阶段的工作完成之后，才能开始后一阶段的工作

  前一阶段的输出文档就是后一阶段的输入文档

  推迟实现的观点

    清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现

  质量保证的观点

    每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。

    每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
  瀑布模型的优点：

    可强迫开发人员采用规范的方法（例如，结构化技术）

    严格地规定了每个阶段必须提交的文档

    要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证

    瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型

  瀑布模型的缺点：

    要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的

    仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品

    将本来非线性的软件开发过程人为地加以线性化，不符合实际中的软件开发情况

    软件开发耗时长，可运行版本要等到项目后期才能得到，一旦在后期发现错误，付出的代价将是巨大的。

     “由文档驱动”的这个事实也是瀑布模型的一个主要缺点,这可能导致最终开发出的软件产品不能真正满足用户的需要

  V模型

     瀑布模型的改进，强调测试活动与分析和设计之间的关联：

     单元测试和集成测试－>校验程序设计；

     系统测试－>校验（verify）系统设计；

     验收测试－>确认（validate）需求；

     与瀑布模型关注文档和工作产品不同，V模型的关注点是软件开发各阶段的活动以及正确性，因此V模型是以活动驱动的。

  验证（Verification）

    目标是确定系统中各项功能可以正常工作，实质上是检查实现的质量如何。

  确认（Validation）

    目标是确定系统实现了全部的需求，确保开发方建造的是正确的、用户需要的产品。
  

  V模型的改良之处与存在的问题

  本质是把瀑布模型中一些隐含的迭代过程明确出来，使开发活动和验证活动的相关性更加明显；

  V模型使抽象等级的概念也更明显：所有从需求到实现部分的活动关注的是建立更多的系统详细表述，而所有从实现到交付运行的活动关注的是对系统的验证和确认。

  和瀑布模型一样，都是对软件开发过程过份简单、理想化的抽象，对需求变化的适应性差。

原型/快速原型模型

  所谓原型，是一个可以实际运行的模型，它在功能上可以看作是最终产品的一个子集（展示了目标系统的关键功能）。

  原型模型的优势：

  快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的。原因如下

  原型系统已经通过与用户交互而得到验证

  开发人员通过建立原型系统已经学到了许多东西

  利用原型能统一客户和开发人员对软件项目需求的理解，有助于需求的定义和确认；

  可以考虑结合瀑布模型，二者互补性强。用快速原型做为需求分析的一种技术，用于收集客户的真实需求，然后把客户满意了的原型再作为瀑布模型的输入，从而达到优势互补。