软件工程自学笔记一（基础篇）

第一部分 软件与软件工程

1. 软件的概念、特点

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据以及相关文档的完整集合。其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。

软件的分类

软件危机

计算机软件的开发和维护过程所遇到的一系列严重问题。

软件危机表现

• 对软件开发成本和进度的估算很不准确
• 难以准确获取用户需求，用户不满意
• 质量很不可靠，没有适当的文档
• 缺乏方法指导和工具支持，大型软件系统经常失败
• 供不应求：软件开发生产率跟不上计算机应用的迅速发展

做好软件定义时期的工作，是降低软件成本提高软件质量的关键。

解决途径

• 组织管理
  • 工程项目管理方法
• 技术措施
  • 软件开发技术与方法
  • 软件工具

2. 软件工程

用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及管理方法。

三要素

• 方法
• 工具
• 过程

软件工程目标之间的关系

软件工程的原则

原则一：抽象

抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象、自顶向下、逐层分解的办法控制软件开发过程的复杂性。例如：软件瀑布模型、结构化分析方法、结构化设计方法，以及面向对象建模技术等都体现了抽象的原则。

原则二：信息隐蔽

将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。

原则三：模块化

模块是程序在逻辑上相对独立的成分，是独立的编程单位，应有良好的接口定义。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。

原则四：局部化

要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证 模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于加强模块的独立性，控制解的复杂性。

原则五：确定性

软件开发过程中所有概念的表达应该是确定的、无歧义的、规范的。这有助于人们之间在交流时不会产生误解、遗漏，保证整个开发工作协调一致。

原则六：一致性

整个软件系统（包括程序、文档和数据）的各个模块应使用一致的概念、符号和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致。

原则七：完备性

软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。

原则八：可验证性

开发大型的软件系统需要对系统自顶向下、逐层分解。系统分解应遵循系统已于检查、测试、评审的原则，以确保系统的正确性。

软件工程的本质特征

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

软件工程的基本原理

原理一：用分阶段的生命周期计划严格管理

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

原理二：坚持进行阶段评审

软件的质量保证工作不能等到编码阶段结束之后再进行。错误发现与改正越晚，所需付出的代价也越高。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。

原理三：实行严格的产品控制

原理四：采用现代程序设计技术

采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。

原理五：结果应能清楚地审查

应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。

原理六：开发小组的人员应该少而精

3. 软件工程方法学

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

方法学三要素

• 方法，回答“怎么做”的问题
• 工具
• 过程

使用最广泛的软件工程方法学

• 传统方法学→面向数据流、结构化
  • 软件分析→总体设计→详细设计→面向过程的编码→测试
• 面向对象方法学
  • 软件分析与对象抽取→对象详细设计→面向对象的编码→测试

两种程序设计方法

• 结构化程序设计
  • 程序=数据结构+算法
• 面向对象程序设计
  • 程序=对象+消息

软件生命周期（传统方法学）

• 计划时期
  • 问题定义
  • 可行性分析
• 开发时期
  • 需求分析
  • 软件设计
  • 编码
  • 测试
• 运行时期
  • 软件维护

1.问题定义

问题定义阶段必须回答的关键问题是：“要解决的问题是什么？”

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

2. 可行性研究

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

技术上、经济上、操作上、时间上、法律上

3. 需求分析（功能分析）

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

系统分析员必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图（DFD）、数据字典（DD）和简要的算法表示。

在需求分析阶段确定的系统逻辑模型是以后设计和实现系统的基础。这个阶段的一项重要任务是用正式文档准确地记录对目标系统的需求，这份文档通常称为 规格说明书（specification）。（SRS）

4. 总体设计

这个阶段必须回答的关键问题是：“怎样实现目标系统？”

成果：系统结构图（SC）

一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。总体设计的另一项主要任务是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。

5. 详细设计

这个阶段的任务就是把解法具体化，也就是回答这个关键问题：“应该怎样具体地实现这个系统呢？”

这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明应该包含必要的细节，程序员可以根据它们写出实际的程序代码。

详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。

6. 编码和单元测试

这个阶段的关键任务是写出正确的、容易理解、容易维护的程序模块。

程序员应该根据目标系统的性质和实质环境，选择一种适当的高级程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

7. 综合测试

这个阶段的关键任务是通过各种类型的测试使软件达到预定的要求。

最基本的测试是集成测试和验收测试。

集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。

验收测试是按照规格说明书的规定，由用户对目标系统进行验收。

必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。

8. 软件维护

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

• 改正性维护，也就是诊断和改正在使用过程中出现的软件错误；
• 适应性维护，即修改软件以适应环境的变化
• 完善性维护，即根据用户的要求改进或扩充软件使它更完善；
• 预防性维护，即修改软件为将来的维护活动预先做准备。

软件开发模型（过程）

• 传统开发模型
  • 瀑布模型（waterfall model）
  • 快速原型模型（rapid prototype model）
• 演化开发模型
  • 增量模型（incremental model）
  • 螺旋模型（spiral model）
• 面向对象开发模型
  • 构建集成模型（component integration model）
• 形式化开发模型
  • 转换模型（transformational model）
  • 净室模型（clean room model）

1. 瀑布模型

瀑布模型是文档驱动的。

瀑布模型的特点：

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

2. 推迟实现的观点

   瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要指导思想。

3. 质量保证的观点

   • 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
   • 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

2. 快速原型模型

快速原型模型适用于中小型软件，且需求模糊的用户。

快速原型模型的特点：

• 快速开发工具
• 循环
• 低成本

种类：

• 渐进型
• 抛弃型

3. 增量模型

使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。

**增量：**小而可用的软件

增量模型的特点：

• 在前面增量的基础上开发后面的增量
• 每个增量的开发可用瀑布或快速原型模型
• 迭代的思路

4. 螺旋模型

螺旋模型是风险驱动的。

螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。

螺旋模型的特点：

• 瀑布模型+快速原型+风险分析
• 迭代过程

一个螺旋式周期：

• 确定目标、选择方案、选定完成目标的策略
• 风险角度分析该策略
• 启动一个开发阶段
• 评价前一步的结果，计划下一轮的工作

5. 构建集成模型

构建集成模型的特点：

• 面向对象
• 基于构件库
• 融合螺旋模型特征
• 支持软件开发的迭代方法
• 软件重用

---

第二部分 可行性研究（含初步需求分析）

1. 可行性研究的任务

目的和任务

可行性研究的目的不是解决问题，而是确定问题是否值得去解决。

可行性研究最根本的任务是对以后的行动方针提出建议。

本质

可行性研究的本质是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。

步骤

1. 首先需要进一步分析和澄清问题定义
2. 在澄清了问题定义之后，分析员应该导出系统的逻辑模型。
3. 再从逻辑模型出发，探索若干种可供选择的主要解法（即系统实现方案）。对每种解法都应该仔细研究它的可行性，一般说来，至少应该从下述三个方面研究每种解法的可行性：
   • 技术可行性：使用现有的技术能够实现这个系统
   • 经济可行性：这个系统的经济效益能超过它的开发成本？
   • 操作可行性：系统的操作方式在这个用户组织内行得通吗？
   • 必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。

投入时间

可行性研究需要的时间长短取决于工程的规模。一般来说，可行性研究的成本只是预期的工程总成本的5%~10%。

2. 可行性研究过程

典型的可行性研究过程有下述一些步骤：

步骤一：复查系统规模和目标

分析员对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束

步骤二：研究目前正在使用的系统

• 现有的系统是信息的重要来源，新的目标系统必须也能完成它的基本功能
• 现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题
• 运行使用旧系统所需要的费用是一个重要的经济指标，如果新系统不能增加收入或减少使用费用，那么从经济角度看新系统就不如旧系统。

步骤三：导出新系统的高层逻辑模型

优秀的设计过程通常总是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。

通过前一步的工作，分析员能够使用数据流图，描绘数据在系统中流动和处理的情况，从而概括的表达出对新系统的设想。为了把系统描绘的更清洗准确，还应该有一个初步的数据字典，定义系统中使用的数据。

步骤四：进一步定义问题

新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础

前4个步骤构成一个循环，直到提出的逻辑模型完全符合系统目标。

步骤五：导出和评价供选择的解法

分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的物理解法供比较和选择。

导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。

• 首先，根据技术可行性的考虑初步排除一些不现实的系统方案
• 其次，考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的哪些方案。
• 最后考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。

步骤六：推荐行动方针

• 根据可行性研究结果应该做出的一个关键性决定是，是否继续进行这项开发工程
• 如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由
• 通常使用部门的负责人主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。

步骤七：草拟开发计划

分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员和各种资源的需要情况，应该指明什么时候使用以及使用多长时间。

此外，还应该估计系统生命周期每个阶段的成本。

最后，应该给出下一个阶段（需求分析）的详细进度表和成本估计。

3. 系统流程图

系统流程图是概括地描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个组件（程序、文档、数据库、人工过程等）

系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流程图。

4. 数据流图 DFD

数据流图是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换（加工、处理）。

• 在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。
• 数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具
• 设计数据流程图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能。

顶级数据流图（0级）

符号

四种基本符号：

• 正方形或立方体表示数据的源点或终点
• 圆角矩形或圆形代表变换数据的处理
• 开口矩形或两条平行横线代表数据存储
• 箭头表示数据流，即特定数据的流动方向

例子

• 第一步从问题描述中提取数 据流图的4种成份：
  • 首先考虑数据的源点和终点。
  • 再次考虑处理。
  • 最后，考虑数据流和数据存储。系统把订货报表送到采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务在时间上明显不匹配，所以每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。因此，

分层数据流图

5. 数据字典 DD

6. 成本/效益分析

7. 小结

---

第三部分 软件需求分析基础

1. 需求分析的任务和步骤

2. 需求获取的常用方法

3. 分析建模

4. 软件需求说明

5. 结构化分析方法

6. 面向对象方法