一、概述

软件工程的定义

软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。

软件工程的内容（应该

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

软件工程的目标

软件工程的目标是经济地开发出高质量的软件

软件工程的特征

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

软件的定义

1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。

软件生存周期

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

软件定义

软件定义时期的任务是：

1. 确定软件开发工程必须完成的总目标；
2. 确定工程的可行性；
3. 导出实现工程目标应该采用的策略及系统必须完成的功能；
4. 估计完成该项工程需要的资源和成本，并且制定工程进度表。

这个时期的工作通常又称为系统分析，由系统分析员负责完成。
软件定义时期通常进一步划分成3个阶段：

• 问题定义
• 可行性研究
• 需求分析

软件开发

开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：

• 总体设计
• 详细设计
• 编码和单元测试
• 综合测试。

其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。

软件维护

维护时期的主要任务是使软件持久地满足用户的需要。

• 当软件在使用过程中发现错误时应该加以改正；
• 当环境改变时应该修改软件以适应新的环境；
• 当用户有新要求时应该及时改进软件以满足用户的新需要。

通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

模型（瀑布、演化、螺旋、喷泉）

瀑布模型

传统瀑布模型如下

优点

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

缺点

• “瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。
• 在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。
• 总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。

快速原型模型

所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

• 把软件产品作为一系列的增量构件来设计、编码、集成和测试。
• 把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。
• 分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。
• 增量模型的另一个优点是，逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
• 使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。
• 软件体系结构必须是开放的。
  
  

  喷泉模型的优点

  喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 [1]

  喷泉模型的缺点

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

  CASE

  hat’s this/p>

  二、系统定义与软件计划

  这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗

  可行性研究的目的

  确定问题是否值得去解决

  可行性研究的任务

  • 可行性研究最根本的任务是对以后的行动方针提出建议。
  • 首先需要分析和澄清问题定义
  • 在澄清了问题定义之后，分析员应该导出系统的逻辑模型。然后从系统逻辑模型出发，探索若干种可供选择的主要解法(即系统实现方案)。对每种解法都应该仔细研究它的可行性。

  可行性研究的三个方面

  1. 技术可行性使用现有的技术能实现这个系统吗/li>
  2. 经济可行性这个系统的经济效益能超过它的开发成本吗/li>
  3. 操作可行性系统的操作方式在这个用户组织内行得通吗br> 必要时还要从法律、社会效益等更广泛的方面研究每种解法的可行性

  可行性研究过程

  1. 复查系统规模和目标
  2. 研究目前正在使用的系统
  3. 导出新系统的高层逻辑模型
  4. 进一步定义问题
  5. 导出和评价供选择的解法
  6. 推荐行动方针
  7. 草拟开发计划
  8. 书写文档提交审查

  系统流程图

  基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序，文档，数据库，人工过程等)。系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。它是物理数据流图而不是程序流程图。
  

  

  示例

  系统级

  

  二层数据流图

  

三、需求分析

这个阶段的任务是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。

需求分析的任务

• 确定对系统的综合要求

1. 功能需求
   指定系统必须提供的服务。需求分析应该划分出系统必须完成的所有功能。
2. 性能需求
   性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求
   可靠性需求定量地指定系统的可靠性。
   可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
4. 出错处理需求
   说明系统对环境错误应该怎样响应。
5. 接口需求
   接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。
6. 约束
   设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
   常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。
7. 逆向需求
   逆向需求说明软件系统不应该做什么。
8. 将来可能提出的要求
   应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。

• 分析系统的数据要求

1. 任何一个软件系统本质上都是信息处理系统
2. 分析系统的数据要求通常采用建立数据模型的方法
3. 复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。
4. 利用图形工具辅助描绘数据结构，常用的图形工具有层次方框图和Warnier图
5. 数据结构规范化

• 导出系统的逻辑模型

综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

• 修正系统开发计划

根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。

需求分析是软件生存周期中计划阶段的最后一个步骤

结构化分析方法（SA）

DFD（分层数据流图）：概念

分层：
面对复杂的系统时，一个比较好的方法是分层次地描绘这个系统。
首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。
然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。

数据字典（DD）
加工说明：结构化语言、判定表、判定树

与用户沟通获取需求的方法

访谈

• 正式访谈时，系统分析员将提出一些事先准备好的具体问题。
• 在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。
• 当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。
• 在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。

面向数据流自顶向下求精

• 软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法。
• 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。
• 必须请用户对上述分析过程中得出的结果仔细地复查，数据流图是帮助复查的极好工具。
  从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。
• 反复进行上述分析过程，分析员越来越深入地定义了系统中的数据和系统应该完成的功能。为了追踪更详细的数据流，分析员应该把数据流图扩展到更低的层次。通过功能分解可以完成数据流图的细化。
• 随着分析过程的进展，经过问题和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。图3.1粗略地概括了上述分析过程。
  

  符号

  • 矩形框代表实体
  • 用连接相关实体的菱形框表示关系
  • 用椭圆形或圆角矩形表示实体(或关系)的属性
  • 用直线把实体(或关系)与其属性连接起来。

  状态转换图

  状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
  状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。
  状态图提供了行为建模机制，可以满足第3条分析准则的要求。

  内容

  1. 状态

  • 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
  • 状态规定了系统对事件的响应方式。
    系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
  • 在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。
  • 状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。当描绘循环运行过程时，通常并不关心循环是怎样启动的。当描绘单程生命期时，需要标明初始状态(系统启动时进入初始状态)和最终状态(系统运行结束时到达最终状态)。

  2. 事件

  事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。

  3. 符号表示

  • 在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。
  • 中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。
  • 活动表的语法格式如下：事件名(参数表)/动作表达式

  

  层次方框图

  • 层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。
  • 随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。
  • 系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。
  

IPO图

• IPO图是输入、处理、输出图的简称
• 能够方便地描绘输入数据、对数据的处理和输出数据之间的关系
• IPO图使用的基本符号既少又简单
• 它的基本形式是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。
• 处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。
• 在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。
  

软件工具应该满足下列要求：

(1) 必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；
(2) 使用这个软件工具能够导出详细的文档；
(3) 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；
(4) 使用这个软件工具之后，应该能够改进通信状况。

软件需求说明书（SRS）

1. 通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。
2. 内容：通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
3. 为了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题，有些人主张用形式化方法描述用户对软件系统的需求。

四、概要设计（总体设计）

总体设计的基本

概要设计设计的基本任务

• 总体设计的基本目的就是回答“概括地说，系统应该如何实现/strong>”这个问题，总体设计又称为概要设计或初步设计。
• 总体设计需要划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等，但是每个物理元素仍然处于黑盒子级。
• 总体设计的另外一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。

概要设计设计的基本方法

• 总体设计过程首先寻找实现目标系统的各种不同的方案，需求分析阶段得到的数据流图是设想各种可能方案的基础。
• 然后分析员从这些供选择的方案中选取若干个合理的方案，为每个合理的方案都准备一份系统流程图，列出组成系统的所有物理元素，进行成本/效益分析，并且制定实现这个方案的进度计划。
• 分析员应该综合分析比较这些合理的方案，从中选出一个最佳方案向用户和使用部门负责人推荐。

总体设计的必要性

可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。

总体设计的设计过程

总体设计过程通常由两个主要阶段组成：

• 系统设计阶段，确定系统的具体实现方案；
• 结构设计阶段，确定软件结构。

典型的总体设计过程包括下述9个步骤：

1. 设想供选择的方案
2. 选取合理的方案
3. 推荐最佳方案
4. 功能分解
5. 设计软件结构
6. 设计数据库
7. 制定测试计划
8. 书写文档
9. 审查和复审

模块划分的原则：高内聚、低耦合

模块化

模块是由边界元素限定的相邻程序元素（例如，数据说明，可执行的语句）的序列，而且有一个总体标识符代表它。按照模块的定义，过程、函数、子程序和宏等，都可作为模块。面向对象方法学中的对象是模块，对象内的方法（或称为服务）也是模块。模块是构成程序的基本构件。

示例

HIPO图

HIPO图具有可追踪性，在H图(层次图)里除了最顶层的方框之外，每个方框都加了编号

示例

过程设计语言PDL

过程设计语言（PDL）也称为伪码，这是一个笼统的名称，现在有许多种不同的过程设计语言在使用。它是用正文形式表示数据和处理过程的设计工具。
PDL具有严格的关键字外部语法，用于定义控制结构和数据结构；另一方面，PDL表示实际操作和条件的内部语法通常又是灵活自由的，可以适应各种工程项目的需要。因此，一般说来，PDL是一种“混杂”语言，它使用一种语言的词汇，同时却使用另一种语言(某种结构化的程序设计语言)的语法。

特点

1. 关键字的固定语法，它提供了结构化控制结构、数据说明和模块化的特点。为了使结构清晰和可读性好，通常在所有可能嵌套使用的控制结构的头和尾都有关键字，例如，if…fi(或endif)等等。
2. 自然语言的自由语法，它描述处理特点。
3. 数据说明的手段。应该既包括简单的数据结构(例如纯量和数组)，又包括复杂的数据结构(例如，链表或层次的数据结构)。
4. 模块定义和调用的技术，应该提供各种接口描述模式。

优点

1. 可以作为注释直接插在源程序中间。这样做能促使维护人员在修改程序代码的同时也相应地修改PDL注释，因此有助于保持文档和程序的一致性，提高了文档的质量。
2. 可以使用普通的正文编辑程序或文字处理系统，很方便地完成PDL的书写和编辑工作。
3. 已经有自动处理程序存在，而且可以自动由PDL生成程序代码。

缺点

不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单。

示例（拼写检查）

详细设计说明书

详细设计产生的主要文件是详细设计说明书，它为编写源代码提供了必要的说明

六、软件编码

这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。
程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设

来源：T&King