1.软件工程学概述

1.1软件危机

1.1.1软件危机的介绍

  • 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题
  • 软件危机包含两方面的问题：如何开发软件，以满足对软件日益增长的需求，如何维护数量不断膨胀的已有软件。

1.1.2产生软件危机的原因

  • 客观原因：由软件本身的特点决定

    • 软件是手工劳动，是智力产品—-生产率低。
    • 软件是逻辑实体，出错容易，纠错困难。
    • 软件的复杂性使得仅靠人的智力难以驾驭。

  • 主观原因：

    • 开发方式：认为开发软件就是写程序。
    • 组织方式：作坊式的生产方式；开发无计划、开发过程无规范、开发过程难控制。
    • 用户方面：对软件需求描述不精确。
    • 开发人员方面：对用户需求的理解与用户本来愿望有差异，相互之间的信息交流不及时、不准确、有误解。

  • 软件危机的表现形式

    • （1）对软件开发成本和进度的估计常常很不准确。
    • （2）用户对“已完成的”软件系统不满意的现象经常发生。
    • （3）软件产品的质量往往靠不住。
    • （4）软件常常是不可维护的。
    • （5）软件通常没有适当的文档资料。
    • （6）软件成本在计算机系统总成本所占的比例逐年上升。
    • （7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势、软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

1.1.3消除软件危机的途径

  • 为了消除软件危机，首先应该对计算机软件有一个正确的认识。
  • 软件=程序+数据+文档
  • 1）加快新一代计算机的研制工作；
    2）应该有组织，有计划，通过严格的管理手段进行软件的开发；
    3）及时总结软件开发的成功技术和方法并加以推广；
    4）应该选择好的开发工具进行软件的开发

1.2软件工程

1.2.1软件工程的介绍

  • 软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行、维护过程，也就是把工程应用于软件；②研究①中提到的途径。

  • 软件工程的本质特性

    • 1.软件工程关注于大型程序的构造
    • 2.软件工程的中心课题是控制系统复杂性
    • 3.软件经常变化
    • 4.开发软件的效率非常重要
    • 5.和谐的合作是开发软件的关键
    • 6.软件必须有效地支持它的用户
    • 7.在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品

1.2.2软件工程的基本原理

  • 1.用分阶段的生命周期计划严格管理
  • 2.坚持进行阶段评审
  • 3.实行严格的产品控制
  • 4.采用现代程序设计技术
  • 5.结果应能清楚地审查
  • 6.开发小组的人员应该少而精
  • 7.承认不断改进软件工程时间的必要性

1.2.3软件工程方法学

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

  • 软件工程方法学包含3个要素：方法、工具和过程，方法是主导，工具是辅助

    • 过程：为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤
    • 方法：完成软件开发的各项任务的技术方法，回答“怎样做”的问题；
    • 工具：为运用方法而提供的自动的或半自动的软件工程支撑环境

  • 软件工程的目标

    • 在给定成本、进度的前提下，开发出满足用户需求的高质量的、易于维护的软件产品。
    • 软件工程是从技术和管理两方面研究如何更好地开发和维护计算机软件。
    • 成本、进度和质量将是未来若干年中导致软件激烈竞争的主要因素。

  • 软件工程面临的问题

    • 软件费用仍然很高。
    • 可靠性难以稳定地保证。
    • 可维护性差。
    • 可重用性低。
    • 生产率不能有效提高。

  • 传统方法学（生命周期法或结构化范型）

    • 这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。

  • 面向对象方法学

    • 面向对象方法是把数据和行为看成同等重要，是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。面向对象方法学有下述4个要点：

      • （1）把对象作为融合了数据及在数据上的操作行为的统一的软件构建。
      • （2）把所有对象都划分成类
      • （3）按照父类（或称基类）与子类（或称为派生类）的关系，把若干个相关类组成一个层次结构的系统。
      • （4）对象彼此间仅能通过发送消息互相联系。

1.3软件生命周期

软件定义

  • 问题定义

    • 要解决的问题是什么？

  • 可行性研究

    • 对于上一个阶段所确定的问题有行得通的解决办法吗？

  • 需求分析

    • 为了解决这个问题，目标系统必须做什么？

软件开发

  • 总体设计

    • 概括地说，应该怎样实现目标系统？

  • 详细设计

    • 应该怎样具体实现这个系统呢？

  • 编码和单元测试

    • 写出正确的容易理解、容易维护的程序模块

  • 综合测试

    • 通过各种类型的测试（及相应的调试）使软件达到预定的要求。

运行和维护

  • 软件维护

    • 通过各种必要的维护性活动使系统持久地满足用户的需求
    • 改正性维护
    • 适应性维护
    • 完善性维护
    • 预防性维护

1.4软件过程

1.4.1瀑布模型

  • 1.阶段间具有顺序性和依赖性
  • 2.推迟实现的观点
  • 3.质量保证的观点
  • 优点：
    • 可强迫开发人员采用规范的方法；
    • 严格地规定了每个阶段必须提交的文档；
    • 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
    • 对文档的约束，使软件维护变得容易一些，且能降低软件预算
  • 缺点：
    • 开发过程一般不能逆转，否则代价太大；
    • 实际的项目开发很难严格按该模型进行；
    • 客户往往很难清楚地给出所有需求；
    • 软件的实际情况必须到项目开发的后期客户才能看到
  • 适用范围：
    • 用户的需求非常清楚全面，且在开发过程中没有或很少变化
    • 开发人员对软件的应用领域很熟悉
    • 用户的使用环境非常稳定
    • 开发工作对用户参与的需求很低

1.4.2快速原型模型

  • 快速原型是快速建立起来的可以在计算机上运行的程序，它能完成的功能往往是最终产品能完成的功能的一个子集。
  • 优点：
    • 可以得到比较好的需求分析定义，容易使用需求的变化；
    • 有利于开发与培训同步；
    • 开发费用低，开发周期短且对用户更友好。
  • 缺点：
    • 客户与开发者对原型理解不同；
    • 准确的原型设计比较困难；
    • 不利于开发人员的创新；
  • 适用范围：
    • 对所开发的领域比较熟悉而且有快速的原型开发工具；
    • 项目招投标时，可以用原型模型作为软件的开发模型
    • 进行产品移植或升级时，或对已有原型进行客户工作化时。

1.4.3增量模型

  • 使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
  • 优点：
    • 能在短时间内向用户提交可完成部分工作的产品
    • 逐步增加功能，减少了全新的软件可能给客户组织带来的冲击
  • 缺点：
    • 并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
    • 增量模型的灵活性很容易退化成边做边改模型，从而使软件过程的控制失去整体性。
  • 适用范围：
    • 进行已有产品升级或新版本开发；
    • 对完成期限严格要求的产品
    • 对所开发的领域比较熟悉而且已有原型系统。

1.4.4螺旋模型

  • 基本思想是，使用原型及其他方法来尽量降低风险
  • 优点：
    • 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量组为软件开发的一个重要目标；
    • 减少了过多测试或测试不足所带来的分线；
    • 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
  • 缺点：
    • 需要丰富的风险评估经验和专门知识，如果未能够即使标识风险，会造成重大损失
    • 过多的迭代次数会增加开发成本，延迟提交时间。
  • 适用范围：
    • 适用于内部开发的大规模软件项目

1.4.5喷泉模型

  • ”喷泉“这个词体现了面向对象软件开发过程迭代和无缝的特性。
  • 为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程作为总目标

1.4.6Rational统一过程

  • 最佳实践

    • 迭代式开发
    • 管理需求
    • 使用基于构件的体系结构
    • 可视化建模（UML）
    • 验证软件质量
    • 控制软件变更

  • RUP软件开发生命周期

    • （1）核心工作流

      • 业务建模
      • 需求
      • 分析与设计
      • 实现
      • 测试
      • 部署
      • 配置与变更管理
      • 项目管理
      • 环境

    • （2）工作阶段

      • 初始阶段
      • 精化阶段
      • 构建阶段
      • 移交阶段

1.4.7敏捷过程与极限编程

  • 敏捷过程

    • 个体和交互胜过过程和工具—合作、沟通交互更重要
    • 可以工作的软件胜过面面俱到的文档
    • 客户合作胜过合同谈判
    • 相应变化胜过遵循计划

  • 极限编程。把好的开发实践运用到极致。极限编程广泛应用于需求模糊且经常改变的场合。

    • 客户作为开发团队成员
    • 使用用户素材
    • 短交付周期—反复迭代，每次完成部分需求
    • 验收测试
    • 结对编程—两人在用一台机器上共同编写同一程序，编码；审查测试
    • 测试驱动开发—先设计测试方案，再编程，所有测试通过才能结束
    • 集体所有—代码归属集体，每个成员都可以修改，都对全部代码质量负责
    • 持续集成— 一天之内多次集成系统，根据需求变化，不断进行回归测试
    • 可持续的开发速度
    • 开放的工作空间—在同一场所一起工作，方便自由交流讨论
    • 及时调整计划
    • 简单的设计
    • 代码重构—在不改变系统行为的前提下，重新调整和优化系统内部结构，以提高系统性能
    • 使用隐喻—把隐喻看成是系统的全局视图，描述系统如何运作

1.4.8微软过程

  • 基本准则

    • 项目计划应该兼顾未来的不确定因素
    • 有用效的风险管理来减少不确定因素的影响
    • 经常生成并快速地测试软件的过渡版本，以提高软件的稳定性和可预测性
    • 采用快速循环、递进的开发过程
    • 项目进度表应该具有较高稳定性和权威性
    • 使用小型项目组并发地完成开发工作
    • 使用原型验证概念，对项目进行早期论证
    • 把零缺陷作为追求的目标
    • 里程碑评审会的目的是改进工作，切记相互指责

  • 生命周期

    • 微软过程把软件生命周期分为5个阶段，即规划、设计、开发、稳定、发布。各阶段有里程碑。