第一章 软件工程概述

• 软件包含几部分、软件本身特点

软件
程序(指令集)	可执行代码，由字符、数字等组成
数据	输入输出数据
相关文档	规格说明文档、设计文档、用户手册和其他管理文档

特点:

1. 抽象：逻辑实体非物理实体（不直观）；
2. 不存在磨损问题，可无限期使用；
3. 可移植性；（零成本无限复制）；
4. 复杂性，实现、维护等越来越复杂；
5. 昂贵性，开发维护成本高；

• 软件危机概念，包含的两方面内容，提出的时间

软件危机的概念:计算机软件的开发和维护过程中遇到的一系列严重问题。两方面内容:

1. 如何开发软件，满足对软件日益增长的需求
2. 如何维护数量不断膨胀的已有软件。

提出的时间:
1968年，NATO北大西洋公约组织的计算机科学家召开了计算机国际会议，提出“软件危机”的概念，并提出了“软件工程”学科

• 为消除软件危机，需要采取哪两方面措施？

1. 对计算机软件有正确的认识，消除“软件就是程序”的错误认识。认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目，充分借鉴吸取已有经验。
2. 应该推广使用在实践中总结出来的开发软件的成功技术和方法，并继续研究探索。
3. 应该开发和使用更好的软件工具。
   总之，为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施
   管理: 通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。
   技术(软件工程方法学): 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。

• 软件工程的概念？软件工程方法学：传统方法学（生命周期方法学或结构化范型）和面向对象方法学，概念和优缺点

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

2. 软件工程方法学:

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

   • 3要素:

     • 方法：是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；
     • 工具：是为运用方法而提供的自动的或半自动的软件工程支撑环境；如，CASE(Computer-Aided Software Engineering )工具
     • 过程：需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

   • 传统方法学(生命周期方法学或结构化范型)——强调自顶向下:

     • 采用结构化技术来完成软件开发的各项任务；
     • 划分为若干个阶段，然后顺序地完成每个阶段的任务；
     • 每个阶段的任务相对独立，而且比较简单，降低了整个软件开发工程的困难程度； 前一个阶段是后一个阶段的前提和基础，而后一阶段提出的解法更具体，细节更多；
     • 每个阶段结束前必须从技术和管理两方面对这个阶段的开发成果进行严格的检查，通过之后这个阶段才算结束；保证了质量，提高可维护性；
     • 当软件规模庞大，或者的需求模糊或随时间而变化时，传统方法学往往不成功；维护起来仍然很困难。

   • 面向对象方法学——强调主动地多次反复迭代

     • 面向对象方法: 把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
     • 面向对象方法学4个要点：
       • 对象(object)：融合了数据及在数据上的操作行为。
       • 类(class)：类是对具有相同数据和相同操作的一组相似对象的定义。
       • 继承：按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。
       • 消息：对象彼此间仅能通过发送消息互相联系。
     • 优点:
       1. 面向对象方法学的尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程。
       2. 面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程，保证了在各项开发活动之间的平滑过渡。
       3. 促进了软件重用。最终的软件产品由许多较小的、基本上独立的对象组成，每个对象相当于一个微型程序，而且大多数对象都与现实世界中的实体相对应，降低了复杂性，提高了可理解性，简化了开发和维护工作。

• 软件生命周期（三个时期八个阶段）

1. 问题定义:

   任务: 问题是什么?

   • 通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告。
   • 经过讨论和必要的修改之后这份报告应该得到客户的确认。

   结果: 关于系统规模和目标的

2. 可行性研究:

   任务: 有可行的解吗?

   • 系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程。
   • 研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。

   结果:

   • 系统的高层逻辑模型（数据流图、成本效益分析）
   • 可行性论证报告（立即进行/推迟进行/不能或不值得进行）

3. 需求分析:

   任务: 必须做什么

   • 主要是确定目标系统必须具备哪些功能。
   • 系统分析员必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。

   结果:

   • 系统的逻辑模型（数据流图、数据字典、简要的算法描述）
   • 用规格说明书（Specification）准确地记录对目标系统的需求

4. 总体设计:

   任务: 如何提出已提出的问题

   • 设计出实现目标系统的几种可能的方案（低、中、高成本）。
   • 用适当的表达工具描述每种方案，分析优缺点，推荐一个最佳方案，制定出实现最佳方案的详细计划。设计程序的体系结构。

   结果:

   • 可能的解法(系统流程图、成本效益分析)
   • 推荐的系统体系结构(层次图或结构图)

5. 详细设计:

   任务: 怎样具体实现该系统

   • 详细地设计每个模块, 确定实现模块功能所需要的算法和数据结构

   结果:

   • 每个模块的算法和数据结构(程序流程图、PAD图、N-S图等)

6. 编码和单元测试:

   任务: 得到正确的程序模块

   • 选取一种适当的高级程序设计语言(必要时用汇编语言)，把详细设计的结果翻译成用选定的语言书写的程序；
   • 并且仔细测试编写出的每一个模块。

   结果: 代码和测试报告

7. 综合测试:

   任务: 得到符合要求的软件

   • 通过集成测试、验收测试、现场测试、平行运行等方法对目标系统进一步测试检验。
   • 通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。

   结果:

   • 测试计划、详细测试方案以及实际测试结果
   • 完整一致的软件配置

8. 软件维护:
   

   任务: 使系统持久地满足用户的需要

   • 改正性维护,诊断和改正在使用过程中发现的软件错误；
   • 适应性维护，修改软件以适应环境的变化；
   • 完善性维护，根据用户的要求改进或扩充软件；
   • 预防性维护，修改软件为将来的维护活动做准备。
   • 每一项维护活动经历了一次压缩和简化了的软件定义和开发的全过程。

   结果: 完整准确的维护记录

• 软件过程（几个模型）

1. 瀑布模型 (文档驱动型)

• 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落
• 特点:

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

  • 前一阶段的工作完成之后，才能开始后一阶段的工作；
  • 前一阶段的输出文档就是后一阶段的输入文档。

  2. 推迟实现的观点

  • 对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。

  3. 质量保证的观点

  • 每个阶段都必须完成规定的文档，是“文档驱动”的模型；
  • 每个阶段结束前都要对所完成的文档进行评审，尽早发现问题，改正错误。

• 优点:

  • 可强迫开发人员采用规范的方法；
  • 严格地规定了每个阶段必须提交的文档；
  • 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

• 缺点:

  • 只能通过文档了解产品，不经过实践的需求是不切实际的。

• 适用于:

  • 需求是预知的；
  • 软件实现方法是成熟的；
  • 项目周期较短。

2. 快速原型模型

• 特点:

  • 快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的。
  • 快速原型的本质是“快速”。应该尽可能快地建造出原型系统，以加速软件开发过程，节约成本。

• 根据原型的不同作用,有三类原型模型

  • 探索型原型——用于开发的需求分析阶段
  • 实验型原型——主要用于设计阶段
  • 演化型原型——用于及早向用户提交一个原型系统

• 快速原型模型的运用方式:

  • 抛弃策略——探索型和实验型采用此策略
  • 附加策略——演化型快速原型采用此策略

3. 增量模型

• 优点:

  • 人员分配灵活，刚开始不用投入大量人力资源。
  • 当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。
  • 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。

• 难点:

  • 软件体系结构必须是开放的。
  • 模型本身是自相矛盾的。整体——独立构件。
  • 不同的构件并行地构建有可能加快工程进度，但是冒无法集成到一起的风险。

• 适用于:

  • 适用于需求经常改变的软件开发过程。
  • 如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。
    4. 螺旋模型 (风险驱动型)
    

• 优点:

  • 主要优势在于它是风险驱动的。
  • 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；
  • 减少了过多测试或测试不足所带来的风险；
  • 维护只是模型的另一个周期，维护和开发之间没有本质区别。

• 缺点:

  • 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
  • 过多的迭代次数会增加开发成本，延迟提交时间。

• 适用于:

  • 特别适用于庞大、复杂并具有高风险的系统。
  • 适用于内部开发的大规模软件项目。
    5. 喷泉模型
    

• 优点:

  • 该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
  • 多次反复地增加或明确目标系统，而不是本质性的改动，降低错误的可能性。

• 缺点:

  • 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。
  • 要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

• 适用于: 面向对象的软件开发过程。

如有错误, 请在博客页下方评论