Skip to content

0x01软件工程学概述

为什么要讲软件工程

  • 只有对软件和软件的开发过程有充分的认识,才能更好地开发出过程受控、质量受控的软件产品。

  • 对于软件和软件开发过程的认识是困难的,存在很多困惑,需要对此有深刻的认识。

软件的定义

软件由三部分组成

  1. 程序:在运行时,能提供所希望的功能和性能的指令集。
  2. 数据:使程序能够正确运行的数据。
  3. 文档:描述程序研制过程、方法及使用的文档。

软件处理的是信息和逻辑

  • 软件的开发,不仅仅是编写程序。
  • 软件围绕着逻辑进行。
  • 软件就是一个信息交换器。

  • 产生、管理、获取、修改、显示或传送信息。

软件的特征

软件是逻辑的而不是有形的系统元件,具有与硬件完全不同的特征

  1. 软件是被开发或设计的,而不是传统意义上被制造的。
  2. 软件成本集中于开发上,软件项目不能像制造项目那样管理。
  3. 软件不会磨损,不过它会退化
  4. 对未发现的BUG的修复,会引起较高的故障率。
  5. 不能像硬件维修中直接更换磨损的零件,软件维护要复杂得多。
  6. 大多数软件开发,仍是手工作坊式的开发模式
  7. 在硬件世界和现代工业的发展中,被大量使用的标准设计的构建是一条非常成功的路子。
  8. 标准化也是软件设计的一个方向,软件产业正在向基于构件的组装前进。
  9. 软件是一种逻辑实体,具有抽象性
  10. 人们可以使用软件,但是无法看到软件本身的形态。必须通过必须通过观察、分析、思考、判断,才能了解其功能、性能等特性。
  11. 设计中,软件的质量、可维护性、可测试性更加重要。
  12. 软件是复杂的,而且以后会更加复杂
  13. 软件是人类有史以来生产的复杂度最高的工业产品。
  14. 软件的复杂,不是因为软件本身复杂,而是人的思想复杂。

软件危机

表现

  • 软件成本日益增长

  • 开发进度难以控制

  • 软件质量差

  • 软件维护困难

  • 软件开发速度跟不上计算机发展速度

原因

技术原因:

  1. 软件规模越来越大
  2. 软件复杂度越来越高

管理原因:

  1. 软件开发缺乏正确的理论指导,过分依靠个人技巧和创造性。
  2. 对用户需求没有完整准确的认识,就匆忙着手编写程序。

如何克服软件危机

软件工程。

消除软件危机的途径

  • 对计算机软件正确认识。(软件不仅仅是程序)
  • 推广使用开发软件成功的**技术**和**方法**,研究探索更好更有效的技术和方法,消除错误概念和做法。
  • 开发和使用更好的软件工具。
  • 需要组织管理措施

软件工程正是从**技术和管理**两方面研究如何更好地开发和维护计算机软件的一门新兴学科。


软件工程

IEEE对软件工程的定义

软件工程

  1. 将系统化、规范化、可量化的工程原则和方法,应用于软件的开发、运行和维护。
  2. 对 1 中方法的理论研究。

软件工程

观点:按照工程化的原则和方法组织软件开发工作,是摆脱软件危机的一个主要出路。

目标:高效开发高质量软件。

软件工程规范

工业界:参照修改其他工程项目的管理模式,如ISO, PMI, Six Sigma

学术界:CMM

软件工程基本原理(开发与维护的指导)

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

软件开发的规律

软件生命周期

软件开发过程

  • 瀑布模型
  • 快速原型、螺旋模型
  • 喷泉模型

软件开发新过程

  • 敏捷软件开发(极限编程——XP)
  • 快速软件开发
  • 统一软件开发过程

软件开发方法

  • 结构化方法
  • 面向对象方法
  • Jackson 系统开发方法
  • 模块化方法
  • 软件复用

软件工程方法学

把在软件生命周期全过程中使用的一整套**技术的集合**称为方法学(methodology),也称范型(paradigm)。

软件工程方法学三个要素:方法、工具和过程

  • 方法是完成软件开发各项任务的技术,回答“如何做”
  • 工具是为方法的运用提供自动或半自动软件支撑环境,回答“用什么做”
  • 过程是为获得高质量的软件要完成的一系列任务的框架,规定完成各项任务步骤,回答“如何控制、协调、保证质量”。

传统方法学与面向对象方法学

  • 目前使用得最广泛的软件工程方法学。
  • 传统方法学也称为**生命周期方法学**或**结构化范型**
  • 当软件规模较大,或对软件的需求是**模糊**的或随时间**变化**的时候,使用结构化范型开发软件往往不成功。
  • 此外,使用传统方法学开发出的软件,维护起来通常都很困难。
  • 结构化——静态分析。面向对象——动态分析。

传统方法的特点

  • 生命周期模型
  • 软件过程划分为若干个阶段
  • 每个阶段有各自的任务
  • 阶段之间有某种顺序性

面向对象方法

  1. 对象作为融合数据及在数据之上的操作行为的统一的软件构件。

  2. 把所有对象都划分成类,每个类都定义了一组数据和一组操作。

  3. 按照父类与子类的关系,把若干个相关类组成一个层次结构的系统。在类系统中,下层派生类自动拥有上层基类中定义的数据和操作,称为继承。
  4. 对象彼此间仅能通过发送消息互相联系——封装性。

OO特点

  • 面向对象方法学的出发点和基本原则,是尽可能模拟人类习惯的思维方式。

  • 用面向对象方法学开发软件的过程,是一个主动地多次反复迭代的演化过程。

  • 概念和表示方法上的一致性,阶段间平滑(无缝)过渡。

  • 特殊到一般的归纳思维过程;一般到特殊的演绎思维过程。(继承的思想)

  • 最终产品中的对象与现实世界中的实体相对应,降低了复杂性,提高了可理解性,简化了软件的开发和维护工作。

  • 对象是相对独立的实体,容易在软件产品中重复使用,促进了软件重用。

  • 面用对象方法特有的继承性,也进一步提高了面向对象软件的可重用性。


软件生命周期

软件生命周期由**软件定义**、**软件开发**和**运行维护**三个时期组成,每个时期又可进一步划分成若干个阶段,每个阶段有各自的任务。

问题定义(领域分析1)

必须回答的关键问题是:“要解决的问题是什么”。

可行性研究 (领域分析2,问题背景)

回答的关键问题是:“上一个阶段所确定的问题是否有行得通的解决办法”。

需求分析

  • 仍然不是具体地解决客户的问题,而是准确地回答“目标系统必须做什么”。

  • 此外,要用正式文档准确地记录对目标系统的需求,这份文档通常称为规格说明(specification)。

概要设计

  • 概括地回答“怎样实现目标系统?”这个问题。概要设计又称为初步设计、逻辑设计、高层设计或总体设计。

  • 可以给出实现目标系统的几种可能的方案。

  • 另一项主要任务是设计程序的体系结构,即确定程序由哪些模块组成以及模块间的关系。

详细设计

  • 任务是把解法具体化,回答“应该怎样具体地实现这个系统”这个关键问题。

  • 还不是编写程序,而是设计出程序的详细规格说明。

  • 又称为模块设计、物理设计或低层设计。

编码和单元测试

  • 关键任务是写出正确的容易理解、容易维护的程序模块,并测试。

综合测试

  • 关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。

  • 集成测试、验收测试、系统测试

  • 分析系统的可靠性

  • 记录测试计划、详细测试方案及实际测试结果,作为软件配置的一部分。

软件维护

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

通常有四类维护活动

  1. 改正性维护,也就是诊断和改正在使用过程中发现的软件错误;

  2. 适应性维护,即修改软件以适应环境的变化;

  3. 完善性维护,即根据用户的要求改进或扩充软件使它更完善;

  4. 预防性维护,即修改软件为将来的维护活动预先做准备。

软件过程

在实际软件开发时,软件规模、种类、开发环境及开发时使用的技术方法等因素,影响阶段的划分。

生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序,因此,也称为过程模型。

瀑布模型

在20世纪80年代之前,瀑布模型一直是唯一被广泛采用的生命周期模型,现在仍然是应用得最广泛的过程模型。

特点:

  1. 阶段间具有顺序性和依赖性
  2. 推迟实现的观点
  3. 清楚地区分逻辑设计与物理设计,尽可能推迟程序的物理实现。

传统瀑布模型的缺陷:

  1. 不希望有“变化”,变化来的越晚,付出的代价越高。

  2. 设计阶段过多的假设,导致理想化、一厢情愿的东西过多。(用户只参与需求)

  3. “文档驱动”,静态

质量保证的观点:

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

  • 每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误。

快速原型模型

快速建立起可以运行的程序,其功能往往是最终产品功能的子集。

模型的第一步是快速建立一个能反映用户主要需求的原型系统,让用户试用,通过实践了解目标系统的概貌。

特点:

  • 本质:“快速”。

  • 尽可能快地建造出原型系统,以加速软件开发过程,节约软件开发成本。

  • 原型的用途是获知用户的真正需求,一旦需求确定了,原型将被抛弃。(原型通常没有严格的规范化,缺少文档,难以维护)

增量模型(渐增模型)

  • 把软件产品作为一系列增量构件来设计、编码、集成和测试。

  • 每个构件由多个相互作用的模块构成,并且能够完成特定的功能。

  • 使用增量模型时,第一个增量构件往往实现软件的基本需求,提供最核心的功能。(滚雪球方式)

螺旋模型

基本思想:使用原型及其他方法尽量降低风险。

在每个阶段之前都增加了风险分析过程的快速原型模型。

完整的螺旋模型中带箭头的点划线的长度代表当前累计的开发费用,螺线旋过的角度值代表开发进度。

原型模型可以在一定程度上降低风险,但对有些风险也无能为力。

需要专业的风险评估人员。