软件工程概论_工程的三大要素结果大于过程大于方法吗

一、软件工程综述

1.1 软件工程的背景

1.1.1 软件及其特性

(1) 软件

(1-1) 相关概念
软件，计算机软件是与计算机操作系统有关的程序、规程、规则及其文档和数据的统称。

软件 = （程序 + 数据）+文档

(1-2) 软件分类
①通用软件产品。由软件开发机构制作并在市场上公开发售，可以独立使用。
②定制软件产品。根据用户需求而开发的定制化软件产品。

两类产品的区别。通用软件产品的软件描述由开发人员自己完成；定制软件产品的软件描述由客户给出，开发人员只根据客户需求开发即可。

(2) 软件特点

(2-1) 固有特性
①复杂性。软件中不仅要客观体现世界的自然规律，还要集成各种各样的功能。
②抽象性。软件不是客观存在的物质，是有大脑思考加工后的逻辑产物。
③依赖性。软件的开发和运行常受到计算机硬件的限制。

为了减少依赖性，提出来可移植性的概念。

④软件使用特性。软件在投入市场后，需要不断进行维护和再开发。

(2-2) 生产特性
①软件开发特性。软件开发特性体现在技术复杂性和管理复杂性两个方面。

技术复杂性：
软件提供的功能一般比硬件产品提供的功能要多，各项功能的实现，需要对代码的取舍、算法的优化等方面进行考虑。
管理复杂性：

1. 软件产品的可视化程度底，难以判断当前的开发进度；
2. 软件结构的合理性差，结构不合理会使管理成本过高。

②软件产品形式特性。软件产品设计成本极高但生产成本极低，因此软件的复制机极其容易，所以对软件的知识产权保护要格外重视。
③软件维护特性。软件维护分为纠错性维护、完善性维护和适应性维护。

纠错性维护：对投入运行软件产生的问题进行更正；
完善性维护：根据用户的再需求，对产品进行修改；
适应性维护：根据软件产品所依赖的硬件或环境来对软件进行修改。

1.1.2 软件危机

软件危机促进了软件工程的诞生。

(1) 背景

二十世纪六七十年代，软件规模不断扩大，其功能和复杂性都进一步增加。以往的软件开发过程无法解决这些问题，导致财力、人力等资源大量浪费。

(2) 软件危机的突出表现

(2-1) 软件生产率低。
表现1： 软件生产效率的提升速度远跟不上计算机的普及速度，加上开发人员的匮乏和开发方式的低下，使得供需差距不断扩大。
表现2： 由于缺乏有效的管理开发体系，现有的开发知识和经验无法充分复用，因此浪费了大量的人力、物力和财力。

(2-2) 软件产品常与用户要求不一致。
表现1： 开发人员与用户之间的信息交流往往存在着差异，因此导致诸多问题在后期集中暴露。
表现2： 开发人员与用户之间存在着知识背景、交流方式和对开发软件理解等诸多方面的差异。

(2-3) 软件复杂度的增加
表现： 缺乏有效的开发软件和开发方法，过分依赖于开发人员的技巧和创造性。因此软件的可靠性和质量开始下降。

(2-4) 不可维护性突出
表现： 软件的局限性和欠灵活性，不仅使错误常常难以纠正，也对后期的维护和完善造成阻碍。

(2-5) 软件文档不完全、不一致
表现： 由于软件文档不规范、不完整、不一致，给软件开发、交流、管理和维护带来了很多困难。

(3) 软件危机的产生原因

(3-1) 软件独有的开发和维护特点。
表现1： 软件的抽象性、复杂性和不可预见性，使软件开发进度难以估测、软件错误发现较晚、软件质量难以评价。
表现2： 由于软件错误往往具有隐蔽性，因此软件的纠错和维护往往难以保证。

(3-2) 软件开发人员的错误认识。
表现： 部分软件开发人员认为“软件开发就是编程”，忽视了需求分析和文档的重要性。

(3-3) 软件开发的自动化程度低。
表现： 软件开发仍然离不开开发人员的个人创造和手工操作，无法达到高度自动化生产。

1.2 软件工程概述

1.2.1 基本概念

(1) 早期软件工程

• 为了克服“软件危机”，在1968年NATO召开的计算机科学会议上Fritz Bauer首次提出来软件工程的概念。旨在开发出“成本低、功能强、可靠性高”的软件产品。
• 在Fritz Bauer的表述中，软件工程被定义为：为了经济可靠的、能在实际机器上高效运行的软件，而建立和使用的健全的工程原则。

(2) 现代软件工程

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

即：按工程化的原则和方法组织软件开发是有效的，是摆脱软件危机的一个主要出路。

1.2.2 软件工程的目标

(1) 软件工程的主要目标

• 软件开发成本较低；
• 软件的功能能够满足用户的需求；
• 软件性能较好；
• 软件可靠性高；
• 软件易于使用、维护和移植；
• 软件开发能够按时完成任务，并及时交付使用。

(2) 软件开发目标的制约关系

即：软件开发是一个多元化的过程，要充分考虑其相互关系以开发出最适合用户的软件产品。

1.2.3 软件工程三要素

软件工程三要素为： 过程、方法、工具。

• 软件工程三要素的根基是：软件质量的保证。没有可靠的软件质量，一切都没有意义。

(1) 软件质量的评价体系

软件质量通过可用功能性、可靠性、可用性、效率、可维护性、可移植性和可复用性等方面来综合评价。

(1-1) 可用功能性
可用功能性指软件所实现的功能是否符合规范和是否达到用户的预期需求。

(1-2) 可靠性
可靠性指软件在规定的时间内，是否能够正常的工作运行。

(1-3) 可用性
可用性指用户使用该软件所具备的基本能力。

(1-4) 效率
效率指软件在限定条件下实现某种功能所占用的计算机资源空间。

(1-5) 可维护性
可维护性指软件在环境改变或发生故障时，完成维护软件所需要的付出程度。

(1-6) 可移植性
移植性指软件在运行环境发生改变时，所需要的工作量。

(1-7) 可复用性
可复用性指在其他软件开发过程中，本软件是否可以为其他软件提供帮助或借鉴。

(2) 过程——软件工程的基础

软件过程主要有6个活动组成，分别为沟通、策划、建模、构建、部署、进化。

(2-1) 沟通
在软件开发前，与用户沟通和协作极为重要。这对了解项目目标，收集需求和定义软件特性和功能相当重要。

(2-2) 策划
开发策划有助于是软件开发过程可视化、有序化，便于开发者了解当前的开发进度和整体开发路径。

软件项目计划
软件项目计划定义和描述了软件工程的工作内容。。它包括了执行的技术任务、可能的风险、资源的需求、工作产品和工作进度计划。

(2-3) 建模
软件开发过程可以通过模型化来建立整个软件的结构体系。同过软件模型的不断优化，为软件的开发提供更好的方案。

(2-4) 构建
对软件的编码和测试进行全方面构建，便于日后发现软件的错误。

(2-5) 部署
通过软件和客户的对接，让用户进行评测并反馈意见。

(2-6) 进化
针对客户和市场的变化进行完善修改。

软件过程的典型支持性活动

• 软件项目的跟踪与控制；
• 风险管理；
• 软件质量保证；
• 技术评审；
• 测量；
• 软件配置管理；
• 可复用管理；
• 工作产品的准备和生产。

(3) 方法——软件工程的重要过程

(3-1) 结构化方法（以功能为主）
结构化方法是以软件功能为目标来进行软件构建，其中包括了结构化分析、结构化设计、结构化实现、结构化维护等相关内容。主要通过数据流的方式来对软件加工和结构化设计。

(3-2) 面向对象方法（以事物为主）
面向对象强调以问题域中的事物为中心，根据事物的本质特征进行思考和发现、认识问题。通过对事物种种特征的认识来把他们高度的抽象化为对象，通过各个对象之间的关系来设计软件模型。其中，寻找各个对象之间的关系是该过程的核心内容。

(4) 工具——软件开发的依靠

常见的软件开发工具：

• Microsoft Visio；（完成对流程图等框图的绘制工作）
• Rational Rose；（满足各种静态建模和动态建模的工作）

静态建模：例图、类图、对象图、组件图、配置图；
动态建模：协作图、序列图、状态图、活动图。

• Microsoft VSS(Visual Source Safe)；（对软件开发过程中的版本管理和数据文件进行存储）
• WinRunner；（测试软件产品是否达到预期及是否可以正常运行）
• LoadRunner。（用于测试软件性能是否达标）

1.2.4 软件类型的多样性

(1) 系统软件
操作系统、驱动器、网络软件、远程通信处理器、编译器、编辑器等。

(2) 独立应用软件
办公软件、图片处理软件等。

(3) 嵌入式控制系统

什么是嵌入式控制系统？

• 一类由软件控制系统和硬件管理设备组成的系统。

智能手环、智能手表、汽车仪表盘显示软件等。

(4) 以网络为中心的交互式应用
浏览器web应用、移动设备上的APP、云计算相关等。

(5) 娱乐系统
主要由各类游戏组成。

娱乐系统的高交互质量是其与其他系统的重要区别。

(6) 建模和仿真系统
用于科研或工程领域的相关软件，旨在系统模拟物理过程和环境。

(7) 数据采集系统
通过一系列传感器采集数据并加以分析的软件。

(8) 人工智能软件
机器人、识别软件、人工神经网络等。

1.2.5 软件工程与web

本节主要介绍web应用的常见三种结构。

(1) C/S(Client/Server，客户端/服务器)结构

(1-1) 结构介绍
在C/S结构的系统中，数据库安装在服务器上，应用程序则安装在客户端上。

(1-2) 结构优点

1. 安全性高。系统安装在局域网内部，受外界影响较小。
2. 即时性强。应用程序在客户端上，可以快速响应用户需求。
3. 共享程度高。数据集中存放，可广泛访问。

(1-3) 结构缺点

1. 版本不易同步。当应用程序要全部升级时，无法保证所有的应用程序都会升级优化。
2. 数据安全存在隐患。由于数据存放在同一个服务器中，各类用户都可以访问数据，会造成相应的安全隐患。

(1-4) 结构典范
微信、支付宝、微博、银行ATM取款系统等。

(2) B/S(Browse/Server，浏览器/服务器)结构

(2-1) 结构介绍
在B/S结构的系统中，数据库和应用程序均被安装在服务器端，用户通过浏览器来访问服务器的而应用程序，再有服务器上的应用程序直接访问数据库。

(2-2) 结构优点

• 应用软件易于维护升级。当所需要维护升级时，只需对服务器端升级即可，用户通过刷新浏览器便可使用升级后软件。

(2-3) 结构缺点

1. 存在网络安全隐患。由于该系统是建立在广域网上的，因此容易受到黑客攻击、病毒传播等问题。为解决这一系列问题，需要建立防火墙、病毒查杀软件等。
2. 人机交互性较差。由于需要用户不断对浏览器进行刷新操作，故用户体验感会相应降低。但可以通过Ajax技术实现无需重新加载页面的情况下实现网页部分更新。

(2-4) 结构典范
新闻浏览网站、电子商务网站等。

(3) 云计算

(3-1) 云计算介绍
云计算使数据处理在大量的分布式计算机上，而非本地计算机或远程服务器中。通过大量的分布式处理来完成各类程序软件的执行。

(3-2) 云计算的功用

1. 用户可以通过云服务器来建立并发布自己的网站；
2. 用户可以通过云服务器来搭建各类基础软件运行的环境；
3. 企业用户可以通过云服务器来搭建协同办公平台及相应应用；
4. 可以为用户提供各类程序的编程接口；
5. 提供网络安全配置服务；
6. 提供数据分析、计算、存储服务。

(3-3) 云计算优点

• 云计算的高灵活性可以使用户根据自己的需求来自由搭建工作平台。较以往的操作更加便捷、成本更加低廉。

(3-4) 云计算缺点

• 云计算的数据信息安全时其存在的主要隐患。

(3-5) 云计算典范
腾讯云、阿里云等。

1.2.6 软件工程的通用原则

(1) 第一原则：存在价值

一个软件系统应为用户提供价值而非无任何作用的软件产品。这一原则是下列所有原则的根基。

(2) 第二原则：有管理的软件过程

软件开发过程应当在合理的管理下进行，主要软件开发过程才能更加合理、高效。

(3) 第三原则：可用性和信息安全性

软件系统应当高效运行，不浪费计算机资源；同时，要保障软件运行的安全并不易受到外来攻击。

(4) 第四原则：需求工程

在软件开发前必须要充分了解到你需要做什么，预期目标是什么。这样才会对软件开发有个明确的预期，以降低中途破产的机率。

(5) 第五原则：提前计划复用

软件开发应当尽可能的使用当前已有的资源，这样可以最大程度的降低软甲开发成本。

(5) 第六原则：面向未来

保证软件的生命周期持久且持续有较高的存在价值，避免软件产品过早的被市场淘汰。

1.2.7 软件工程人员的职业道德

1. 公众感：软件工程人员应当时刻保持与社会公众的利益一致；
2. 客户和甲方：在保护社会公众利益不受侵害的前提下，最大程度的保证客户和甲方的利益；
3. 产品：最大程度保证开发出的产品及其相关附件达到行业较高水准；
4. 判断力：软件工程人员应当具备独立且公正的职业判断力；
5. 管理：提倡合乎道德的软件开发和软件维护的管理方法；
6. 职业感：软件工程人员应当弘扬正义感和荣誉感，尊重社会公众利益；
7. 同事：公平的协助每一位同事；
8. 自我：树立终身学习的理念，不断学习先进的专业知识。

二、软件过程

软件也有一个孕育、诞生、成长、成熟和衰亡的生存过程，我们把这个过程叫做软件的生命周期。

2.1 软件过程概述

软件开发中所遵循的路线图称为软件过程。软件过程提高了软件过程的稳定性、可控性和有组织性。
软件过程由软件描述、软件设计和实现、软件有效性验证和软件进化四种基本活动构成。

2.1.1 软件描述

软件描述阶段是软件项目的早期阶段，主要有软件分析人员和用户合作，针对有待开发的软件系统进行分析规划和规格描述，确定软件需要做什么，为后期开发做好准备。

需求工程
需求工程的目的是生成一个达成一致意见的需求文档，定义能满足客户需求的软件项目。

通常该文档需要表达两个层次的内容：

• 最终用户和客户需要的用户需求描述；
• 开发人员需要的详细系统描述。

需求工程的基本流程

2.1.2 软件设计与实现

(1) 软件设计

(1-1) 概述
软件设计是对实现系统的结构、系统的数据、系统构件间的接口以及所用算法的描述。

(2) 基本活动

1. 体系结构设计。识别系统的体系结构与基本构件之间的关系，最终确定那些构件是可以复用的；
2. 接口设计。通过精确的接口设计。可以实现构件的准确使用；
3. 构件设计。根据系统需求设计每一个构建的运行方式；
4. 数据库设计。设计合理的数据库以存储数据。

(2) 软件实现

根据先前的软件设计方案由软件开发人员开始对软件进行编码。同时，软件开发人员要及时对软件代码进行测试和纠错，最终实现满足需求的软件。

2.1.3 软件有效性验证

软件有效性验证是查看系统是否符合它的描述及系统是否符合客户的预期。

(1) 构件(或单元)测试

软件开发人员对每个构件单独测试，不受其他构件的影响。

(2) 系统测试

开始对单个构件进行集成，检测整个系统是否会出现错误，也开始关注系统是否能够满足功能性需求和非功能性需求。

(3) 接收测试

该阶段测试不在像前两阶段使用模拟数据，开始使用用户的真实数据。根据真实数据的反馈，发现系统中的错误和纰漏。这是软件产品投入市场的最后一次测试。

alpha测试（α测试）
若软件是为特定客户开发的特定软件，在接收测试时称之为alpha测试。α测试的最终目的是开发人员和客户都承认交付的软件 是满足最初的定义的。
beta测试（β测试）
若软件是要在市场上发行的，在上市前的测试称之为beta测试。β测试旨在将软件先行发布给部分用户，通过小部分用户的使用反馈来完善和纠错该软件。

2.1.4 软件进化

软件进化的目标是保障软件的正常运行及对软件进行更新维护。

2.1.5 软件开发团队组成

(1) 系统分析员

• 需求分析师、系统分析师、系统分析员。

(2) 系统设计员

• 系统架构师、软件设计师。

(3) 软件实现员

• 软件开发工程师(程序员)、数据库设计师、UI设计、美工。

(4) 测试员

• 系统测试工程师。

(5) 软件部署员

• 系统集成工程师。

(6) 项目管理员

• 项目经理、项目组长。

2.2 软件过程模型

2.2.1 软件过程模型

(1) 瀑布模型

瀑布模型师软件工程最早的范例。

瀑布模型存在的问题：

1. 实际项目很少遵守瀑布模型提出的顺序；
2. 客户难以准确描述软件的需求，但瀑布模型需要用户准确的描述出项目需求；
3. 客户需要有足够的耐心，因为在项目尾期客户才能得到相应的软件产品；
4. 各个任务之间的依赖性过强，导致牵一发而动全身。

(2) V模型

V模型提供了一种将验证和确认动作应用于早期软件工程工作中的直观方法。

V模型是瀑布模型的一个变体。

(3) 增量过程模型

增量模型把系统分成了多个模块，每个模块重复进行相应过程。

增量过程模型的优点：

1. 降低了适应用户需求变更的成本；
2. 在开发过程中更容易获得用户的开发意见；
3. 可以更快的交付和部署有用的软件。

(4) 构件复用模型

通过面向对象的方法将事务的实体封装成包含数据和数据处理方法的对象，并抽象为类。最后经过适当的设计和实现的类称之为构件。并且这些构件还具有一定的通用性。

构件复用模型的主要任务：

1. 需求框架描述；
2. 构件复用分析；
3. 需求修改与细化；
4. 系统设计；
5. 构件开发；
6. 系统集成。

2.2.2 应对变更的软件过程模型

(1) 抛弃式原型

抛弃式原型只适合于小型、简单、处理过程比较明确、没有大量运算和逻辑处理的系统。

(2) 进化式原型

进化式原型是先开发出一个原型系统让用户使用，然后再根据用户的反馈不断进行修改。

进化式原型存在的问题：

1. 不可能调整原型以满足非功能性的要求；
2. 开发过程中的快速更改必然意味着原型是没有文档的；
3. 原型开发过程中的变更可能会破坏整个系统；
4. 原型开发的质量标准会被一定程度放松。

(4) 螺旋模型

螺旋模型是瀑布模型和原型进化模型相结合而来的，并且里面添加了风险分析这一过程。螺旋模型常用于大型项目软件。

2.2.3 Rational统一过程

(1) 基本概念

(1-1) 概述
软件统一开发过程(Rational Unified Process，RUP)是基于面向对象统一建模语言(UML)的一种面向对象的软件过程。

(1-2) 优点
RUP的优点是由用例驱动，以架构为核心，采用迭代和增量的开发策略。

(1-3) 迭代方式

1. 每一个阶段可能被迭代的执行，其结果会一次次增量式的得到改善；
2. 所有阶段作为一个整体增量式的运行。

(2) 四个基本阶段

(2-1) 初始阶段
该阶段是为系统建立业务用例和确定项目的边界。

(2-2) 细化阶段
该阶段的目标是分析问题域，建立健全体系结构基础，淘汰项目中风险最高的元素。

(2-3) 构建阶段
该阶段的目标是开发所有构件和应用程序，把它们集成为客户需要的产品，并详尽测试他们的功能。

(2-4) 转换阶段
该阶段旨在用户在真实的使用环境下，使用用户真实的数据进行测试，用户反馈报告缺陷及必要的变更。
该阶段的主要活动：

• 过程工作流：业务建模、需求、分析与设计、实现、测试、部署；
• 支持工作流：配置与变更管理、项目管理、环境。

2.3 敏捷软件开发

2.3.1 敏捷软件开发

(1) 概述

在开发过程中，宁愿牺牲一些软件质量、降低某些需求来获得软件的快速支付。敏捷软件开发强调可以运行软件的快速交付而不那么看重中间产品。
敏捷方法适用于需求萌动、快速改变的中小型软件项目。

(2) 敏捷软件开发的方法优势

• 用户与开发者之间的交流胜过了开发过程和工具；
• 可运行的软件胜过了面面俱到的文档；
• 客户合作胜过合同谈判；
• 对变更的良好响应胜过了按部就班的遵循计划。

(3) 敏捷开发原则

1. 尽早、持续交付有价值的软件使用户满意；
2. 在开发后期也欢迎需求变更；
3. 经常性的交付和运行软件；
4. 业务人员和开发人员必须共同工作；
5. 为富有工作积极性的人创造、、提供开发条件与支持；
6. 在团队内部通过面对面沟通的放十四传递信息；
7. 可运行软件是进度的首要衡量标准；
8. 提倡可持续的开发速度；
9. 关注、学习优秀的技能和良好的设计方案；
10. 最大简化任何开发过程；
11. 通过团队协作完成架构、需求和设计；
12. 不断反思、调整开发行为。

2.3.2 极限编程

(1) 基本概念

极限编程(eXtreme Programming，XP)使用面向对象的方法最为开发模型，其包括了策划、、设计、编码、测试4个框架活动。

(2) 主要活动

(2-1) 策划
策划活动首先要建立一系列描述待开发软件的必要特征和功能的故事。

策划故事的排序标准：

• 所有选定的故事将在几周内尽快实现；
• 具有最高权值的故事将移到进度表的前面，并且要首先实现；
• 高风险故事将首先实现。

(2-2) 设计
XP设计严格遵循保持简洁原则。使用简洁而不复杂的描述。并且设计只满足目标即可，不鼓励额外功能性设计。

• XP鼓励使用类—责任—协作者作为有效机制；
• XP鼓励代码重构，通过对原有代码的修改而非重写代码；

(2-3) 编码
编码活动中的关键是结对编程，XP建议两个人面对同一台计算机对同一个故事进行编程。这样提供了实时解决问题和实时质量保证的机制，使得开发人员能集中精力解决手头问题。

(2-4) 测试
测试优先的开发方案是XP的重要创新之一。XP是先写测试程序然后才写代码。
XP验收测试也是客户测试，通过客户反馈的数据二评审软件功能。

三、可行性研究

3.1 可行性研究的任务

3.1.1 基本概念

可行性研究的目的不是解决问题，而是用最小的代价在最短的时间内确定问题是否可以解决。
可行性研究的实质就是在较高层次以较抽象的方式进行系统分析和设计的过程。

3.1.2 研究步骤

(1) 建立系统逻辑模型

在问题定义阶段初步确定项目规模和目标，并且对系统的约束和限制进行相应的表示出来。

(2) 系统实现方案的可行性研究

一般从技术可行性、经济可行性、社会可行性这三个方面进行研究。

(2-1) 技术可行性
确认现有的技术资源是否可以完成预期的软件项目。
一般从以下方面来考虑技术可行性：

• 开发风险：在限制的范围内，判断能否设计出软件系统及达到预期的功能和性能；
• 资源有效性：用于开发的人员、技术是否可以完成此软件项目；
• 技术：相关技术是否可以支持这个项目。

（2-2）经济可行性
通常对开发的成本进行估算及效益的评估，确定要开发的项目是否值得投资开发。

(2-3) 社会可行性
判断项目的开发是否符合当代社会的法律法规，是否符合当代社会的主流价值观。

(3) 方案选择

可行性研究的根本任务是对以后的行动方针提出建议。如果问题没有可行的解法，则应当放弃任务；若有可行的解法，则应当用一个较优解来完成任务。
同时，可行性研究的成本占工程总成本的5%~10%。

3.2 可行性研究的重要性

通过可行性研究可以基本判断项目是否在技术上存在可能，是否在市场上存在可能。通过可行性分析，可以帮助开发人员及用户了解项目的成功率也有助于减少开发者和用户的损失。

3.3 可行性研究的过程

1. 确定项目规划和目标；
2. 研究目前正在使用的系统；
3. 建立新系统的高层逻辑模型；
4. 导出和评价供选择的解法；
5. 推荐行动方针；
6. 草拟开发计划；
7. 编写可行性研究报告。

3.4 系统流程图与工作流程

3.4.1 流程图规范

(1) 基本流程图符号

(2) 其他流程图符号

3.4.2 分层

面对复杂的系统时，一个比较好的解决方法是分层次地描绘出这个系统，从而达到化繁为简的目的。
通常首先用一张高层次的系统流程图描绘系统总体概况，表明系统的关键功能；然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。

3.5 数据流图与系统功能

数据流图是一种图形化技术，是系统逻辑功能的图形化表示，它描绘信息流和数据从输入移动到输出过程中所经受的转换。

3.5.1 数据流图基本符号及其功能

• 圆角矩形－数据的处理和加工。表示对数据进行某种操作或变化，以数据结构或数据内容作为加工对象。
• 箭头－数据流。箭头的方向代表数据流的方向，是数据传输的通道。
• 开口矩形－数据存储。起到保存数据的作用，数据可以是文件或者任何形式的数据组织。
• 正方形－源点/终点。代表数据的发出或接受，旨在提供系统和外界环境之间关系的注释性说明。

3.5.2 数据流图的命名

(1) 为数据流(或数据存储)命名

名称应代表整个数据流(或数据存储)的内容。

(2) 为处理命名

命名时要先为数据流命名，再为处理命名。处理的命名要代表整个处理过程，通常使用动宾结构。

3.6 成本/效益分析(经济可行性分析)

3.6.1 成本估计方法

(1) 代码行估计法

根据以往经验和数据，估算一个功能大致所需要的源程序行数。在得出行数后，用每行代码的平均成本乘以行数就可以大致确定该软件的成本。而且每行代码的平均成本取决于软件的复杂度和工资水平。

(2) 任务分解估计法

(2-1) 方法步骤

1. 把软件开发工程分解为若干个相对独立的任务；
2. 分别估计每个单独的开发任务的成本；
3. 累加起来得出软件开发工程的总成本。

(2-2) 典型环境下各个开发阶段需使用的人力百分比

(3) 自动估计成本法

通过自动估计成本法可以得到较为客观的估计结果。但是需要长期大量的数据为基础和良好的数据库系统作为支持。

3.6.2 成本/效益分析的方法

(1) 货币的时间价值

通常用货币的利率来表示货币的时间价值。

• 已知年利率为i，若现在存入P元，则n年后可以得到的钱数为：
  F=P(1+i)ⁿ;
• F也就是P元钱在n年后的价值。
• 反之，如果n年后能收入F元钱，那么这些钱的当前价值为：
  P=F/(1+i)ⁿ。

(2) 投资回收期

投资回收期就是使累计的经济效益等于最初投资所需要的时间。

(3) 纯收入

在该工程的整个生命周期内累计经济效益(当前收入的值)与投资之差。

(4) 投资回收率

投资回收率计算方程：
P=F₁/(1+j) + F₂/(1+j)² + …… +F_n/(1+j)ⁿ。
说明：P是当前投资额；F_i是第 i 年年底的效益；n是系统的使用寿命；j是投资回收率。

四、结构化需求分析

4.1 需求

4.1.1 需求的定义

IEEE软件工程标准词汇表中把需求定义为：

1. 用户解决问题或达到目标所需的条件或能力；用户角度
2. 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力；开发人员角度
3. 对 1. 或 2. 所描述的条件或能力的文档化表述。

4.1.2 需求的层次

需求通常体现为三部分：业务需求、用户需求、系统需求。

(1) 业务需求

• 抽象层次最高的需求为业务需求，是系统建立的战略出发点，表现为高层次的目标。它描述了为什么要开发系统。
• 业务需求通常来自于项目投资人、产品购买方、用户管理者、市场营销部门、产品策划部门。
• 业务需求需要需求工程师寻找需求特性。需求特性要说明系统为客户提供的各项功能、限制了系统的范围。

(2) 用户需求

• 用户需求是指执行实际工作的用户对系统所完成的具体任务的期望，描述了系统能帮助用户做些什么。
• 用户需求主要来自系统的使用者，并且用户需求表达了用户对系统的期望。

(3) 系统需求

• 系统需求是用户对系统行为的期望，一些列的系统需求联系在一起可以帮助用户完成任务，达成用户需求，进而满足业务需求。
• 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。

4.1.3 需求的分类

(1) 功能需求

• 功能需求包括对系统应该提供的服务、如何对输入做出反应，以及系统在特定条件下行为的描述。在某些情况下，需求功能还需要声明系统不应该做什么。
• 系统功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述；一致性意味着需求描述不能前后矛盾。

(2) 非功能需求(性能需求)

• 非功能需求是对系统提供的服务或功能给出的约束，包括时间约束、开发过程的约束、标准等。
• 非功能需求常用于整个系统，通常不用在单个系统或服务中。

4.2 需求工程

4.2.1 需求工程的任务

• 需求工程必须说明软件系统将被应用的环境及其目标，说明软件要达成什么功能，还要说明在设计和实现这些功能时所用的方式方法；
• 需求工程必须将目标、功能和约束反映到软件系统中，将其映射为可行的软件行为，并对这些软件行为进行准确的规格说明；
• 需求工程还要妥善处理目标、功能和约束随着时间的变化情况。

4.2.2 需求工程的活动

需求工程分为：需求开发和需求管理两部分。

(1) 需求开发

(1-1) 需求获取
需求获取的目的是从项目的战略规划开始建立最初的原始需求。 需要研究系统将来的应用环境、确定系统的涉众、了解现有问题、建立新系统的目标、获取任务细节和用户具体需求。

(1-2) 需求分析
需求分析的目的是保证需求的完整性和一致性。 以原始需求和业务过程细节出发，将目标、功能和约束结合成软件行为，建立系统模型。随后对系统模型进行分析，发现并弥补遗漏的需求。

(1-3) 需求规格说明
需求规格说明的目的是将完整的、一致的需求与能够满足需求的软件行为以文档的方式明确的固定下来。

(1-4) 需求验证
需求验证的目的是保证需求及其文档的正确性，即反映了用户的真实意图。 它的另一个目标是通过检查和修正。保证需求及其文档的完整性和一致性。

(2) 需求管理

需求管理的目的是在需求开发活动之后，保证所确定的需求能够在后续的项目中有效的发挥作用，保障各种活动的开展都符合需求要求。

4.3 需求获取

4.3.1 需求获取中的困难

(1) 用户和开发人员的背景立场不同

(1-1) 知识理解困难

• 用户和开发人员具有不同领域的背景。当用户再传递信息时，开发人员对用户的表达可能会有偏差或误解。
• 为解决这个问题，需要开发人员尽可能的去了解软件的应用背景，理解组织业务逻辑，就进而形成与用户沟通的有效知识框架。

(1-2) 默认知识现象

• 默认知识指在表达者开来如此简单，以至于不值得专门进行解释或提及的知识。
• 因此面对这个问题，开发人员需要利用有效的获取方法和技巧来发现并获取默认知识。

(2) 普通用户缺乏概括性、综合性的表达能力

• 由于用户无法准确、完善的描述出软件需要，因此开发人员寄希望于用户能主动、完全、充分的表达需求是不可能的。
• 解决此问题，开发人员需要在与用户接触前先行确定获取内容的主题，通过具体的应用环境和场景条件，让用户在执行业务的细节中来描述问题并且表达期望。

(3) 用户存在认知困境

• 用户无法明确告知开发人员到底需要什么。但当开发人员给出一个方案时，用户能够快速判断该方案是否能为其解决问题或者解决了哪一部分的问题。
• 为解决此问题，需要开发人员利用有效的需求获取方法和技巧，引导用户去发现未形成明确认知的知识。

(4) 用户越俎代庖

• 用户提出的不是需求，而是解决方案;
• 用户固执地坚持某些特性和功能。
• 要解决此问题，开发人员需要保持业务领域和解决方案的区分界限；
• 而且当越俎代庖的情况出现时，往往表示用户的深层次需求没有被发现。因此开发人员往往需要去分析用户的深层次需求。

(5) 缺乏用户参与

1. 用户数量太多，选择困难；
2. 用户认识不足，不愿参加；
3. 用户情绪抵制，消极参与；
4. 没有明确的用户群体。

4.3.2 定义项目的前景和范围

业务需求、高层解决方案及系统特性被记录下来，定义为项目前景和范围文档。
前景 描述了产品的作用及最终功能，它将涉众都统一到一个方向上。
范围 为项目划定了需求的界限。

过程步骤：

1. 明确问题；
   分析软件项目涉众。将问题变得清晰，变得适宜进行分析。
2. 发现业务需求；
   业务需求指每一个明确、一致的问题都意味着涉众存在一些期望。因此，每个问题对应目标的过程就是业务需求的过程。
3. 定义解决方案和系统特性；
   1）确定高层次的解决方案
   通过定义高层次解决方案，尝尝可以尽早的发现开发人员与用户之间的隔阂。
   2）确定系统特性和解决方案的边界
   系统特性指在选定解决方案之后，需要进一步明确该解决方案需要具备的功能特性。我们需要根据这些功能特性，分析解决方案和周围环境形成的交互作用，定义了解决方案的边界。
   3）确定解决方案的约束
   约束会影响整个系统的方案选择，实现和提交解决方案的能力也会受到约束的限制，甚至有时候约束还会迫使开发人员持续考虑整个方案的选择。

常见约束源：

约束源	约束	理由
操作性	销售订单数据的一份完整备份必须被保存在原有系统的数据库中一年的时间	数据丢失的风险太大，所以新旧系统要并行运行至少一年的时间
系统及操作系统	应用在服务器上不应该占用超过20M的空间	服务器上可用的存储空间有限
设备预算	系统必须在已有的服务器和主机上开发	成本控制及已有的系统维护
人员资源	固定的人力资源，没有外部资源	在现在预算下操作成本已经固定
技术要求	应用面向对象的方面	相信这种技术的应用会增加生产率并增强软件的可靠性

4. 前景与范围文档
   业务需求、高层次解决方案和系统特性都应当被定义到项目前景与范围文档中，为后续的开发工作打好基础。
   前景与范围文档主要有需求工程师来完成，但文档负责人一般是项目的投资负责人或执行主管等。

4.3.3 选择信息来源

信息来源的主要途径：

• 涉众
  如：用户、客户、领域专家、市场人员、销售人员等。
• 硬数据
  如：登记表格、单据、报表、备忘录、日志等。
• 相关产品
  如：原有系统、竞争产品、协作产品等。
• 重要文档
  如：相关产品的规格说明、客户的需求文档等。
• 相关技术标准和法规
  如：法律法规、行业规范标准、领域参考模型等。

4.3.4 需求获取的方法

(1) 研究资料法

• 任何单位或组织都存在着大量的计划、报表、文件和资料。
• 这些资料分为两类：外部资料和内部资料。

外部资料：各项法规、市场信息等；
内部资料：企业计划、指标、经营分析报告、合同、账单、统计报表等。

• 对资料的分析，可以了解生产经营情况和正常的操作程序，了解信息的处理方式，有助于明确需求。
• 但这些资料只能反映静态的和历史的情况，无法反映企业的动态活动和过程。

(2) 问卷调查法

• 调查问卷分为：自由格式和固定格式。

自由格式问卷为回答者提供灵活回答问题的方式；
固定格式问卷需要实现设定选项或几种答案供用户选择。

• 优点：
  1） 多数调查问卷可以快速的被回答；
  2）问卷调查是一项低成本的信息获取途径；
  3）问卷调查允许保护个人隐私，并且便于整理和归纳。
• 缺点：
  1）问卷调查对回答的质量难以保证；
  2）对于模糊、隐含的问题则不便采用问卷调查的方式。

(3) 用户访谈

• 用户访谈是指面对面与用户沟通交流的方式来进行信息获取的。
• 用户访谈分为：结构化访谈和非结构化访谈。

结构化访谈指开发人员向访谈对象提出一系列事先设计好的问题，这些问题可以是开放性的也可以是封闭式的；
非结构化访谈指没有事先确定的问题，开发人员只是向访谈对象提出访谈的主题或问题，且只有一个谈话框架。

• 优点：
  1）访谈为分析人员提供了与访谈对象自由沟通的机会；
  2）通过与访谈对象积极的沟通，可以让访谈对象更加乐于参与到项目的推进中；
  3）通过访谈可以挖掘更深层次的用户需求；
  4）访谈允许开发人员结合自身实际，设计出一些个性化的问题。
• 缺点：
  1）访谈的成功与否取决于分析人员的经验和技巧；
  2）访谈过程所占用的时间和后续整理、归纳访谈资料所消耗的时间较多。

(4) 实地观察法

• 通过实地观察、分析来挖掘系统的深层次需求。一般会应用于较复杂的系统。
• 优点：
  1）通过实地观察得到的数据更加准确、真实；
  2）通过实际观察，有利于了解复杂的工作流程和业务处理流程；（这些问题有时候是文字很难描述清楚的）
• 缺点：
  1）在特定的时间进行观察，不能保证这就是平时的工作状态，有些任务不可能总是按照观察人员观测到的结果运行的；
  2）方法的进行和数据的处理都会花费较多时间。

(5) 原型法

• 原型法通常在需求模糊和不确定性较大的情况下使用。

4.4 需求分析

4.4.1 过程建模

过程建模就是处理需求获取活动所得到的信息，发现系统的功能和与外界的交互，建立能够实现系统功能的过程分解结构，形成系统的过程模型，并用图形的方式将过程模型描述出来。
过程建模的主要技术有：上下文图、数据流图、微规格说明书和数据字典。

(1) 上下文图

上下文图是数据流图的一个特定层次，用来说明系统的上下文环境、确定系统的边界。

(2) 数据流图

(2-1) 作用
数据流图常用来建立过程的分解结构。

(2-2) 基本元素

①外部实体
外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统。 所有的外部实体联合起来构成了软件系统的外部上下文环境。
它们与软件系统的交互流就是软件系统与外部环境的接口，这些接口联合起来定义了软件系统的系统边界。

②过程
过程是指施加于数据的动作或者行为，它们会使数据发生变化。
过程描述的内容是对数据处理行为的概括，这种概括可以表现为不同的抽象层次。

• 最高抽象层次，可以将整个软件系统的功能都描述成一个过程，实现用户所有期待的数据处理行为。
• 较高抽象层次，可以将系统中的某项业务处理描述为一个过程，而这项业务处理又会包含许多任务细节。
• 较低抽象层次，过程描述的可能是用户的一次活动。
• 最低抽象层次，过程描述的可能仅仅是一个逻辑行为，体现为软件系统的一个命令执行过程。

③数据流
**数据流是指数据的流动，他是系统与其环境之间或者系统内两个过程之间的通信形式。**数据流必须和过程是关联的，它要么是过程的数据输入，要么是过程的数据输出。

④数据存储
数据存储是系统软件需要在内部收集、保存，以供日后使用的数据集合。

数据流描述的是动态的数据；数据存储描述的是静止的数据。

(2-3) 规则

• 过程是对数据的处理，因此必须要有输入和输出，而且输入数据集合输出数据集应该存在一定的差异；
• 数据流必须与过程产生关联，要么是过程的数据输入，要么是过程的数据输出；
• 数据流图中所有元素都应该有一个可以唯一标识自己的名称。过程使用动宾结构，外部实体、数据流和数据存储使用名词结构。

(2-4) 分层结构
数据流图定义了3个层次类别的结构图，分别为：上下文图、0层图、N层图

①上下文图
上下文图是数据流图最高层次的图，是系统功能最抽象的部分。上下文图将这个系统看作一个整体，这个过程实现系统的所有功能。上下文图有且只有一个过程，该过程表示整个系统。
上下文图需要表示出系统所有和系统交互的外部实体，并描述交互的数据流(系统输入和系统输出)。

②0层图
0层图是位于上下文图下面一层的图。 它被认为是上下文图中单一过程的描述，是对该单一过程的第一次功能分解。
0层图通常被用来作为整个系统的功能归纳图。 建立0层图需要分析需求获取的信息，归纳出系统的主要功能，并将它们描述为几个高层次的抽象过程。有一些重要数据也会在0层图中存储出来。
0层图应该描述的简洁、清晰。 因此在描述复杂的系统时，0层图不应该出现太过具体的过程和数据存储。

③N层图

• 0层图中的每个过程都可以进行分解，从而展示更多细节。被分解的过程称为父过程，分解后产生的揭示更多细节的数据流图称为子图。对0层图的过程分解图称之为1层图。
  

• 0层图中较为复杂的过程应该是按照功能分解的做法扩展成一个更详细的数据流图。功能分解是一个拆分功能的描述，将单个复杂过程变为多个更加具体、更加准确和更加细节的过程。
  

• N层图不再进行细分的条件：
  1）所有过程都已经被简化为一个选择、计算或者数据库操作；
  2）所有的数据存储都仅仅表示了一个单独的数据实体；
  3）用户已经不关心比子图更加细节的内容，或者子图的描述已经详细得足以支撑后续的开发活动；
  4）每一个数据流都已经不需要进行更加详细得切分，以展示对不同数据的不同处理方式；
  5）每一个业务、事务、计算机的屏幕显示和业务报表都已经被表示为一个单独的数据流；
  6）系统的每一个最底层菜单选项都能在子图中找到独立的过程。

(3) 微规格说明书

(3-1) 作用
在数据流图结构中，所有复杂的过程都被解释为低层次的数据流子图。但是最低层次的子图没有得到充分的解释。为了充分描述系统功能，需要描述原始过程的逻辑处理，因此需要借助微规格技术说明来实现。
微规格说明主要有3中技术，分别为：结构化语言、判定表、判断树。

(3-2) 结构化语言
①相关概念
结构化语言借用了结构化程序设计的特点，比自然语言更加严谨和明确。
结构化语言的语法分为内层和外层。

• 外层语法描述操作的控制结构，如顺序、选择和循环。通过这些结构，可以将各个操作连接起来；
• 内存语法则一般没有什么限制。

②缺点

• 不适合描述复杂的判定逻辑；
• 很少有顺序处理的逻辑；

③适用范围
如果包含一般顺序执行的动作或循环执行的动作，建议使用结构化语言。

④示例

(3-3) 判定表
①相关概念

• 判断表可以比结构化语言更好的描述复杂的判定逻辑。
• 判定表的优点是能够保证判定分析的完备性。因为其列出了所有可能出现的判断条件和动作。

②判定表的结构组成

• 条件声明是进行判定时需要参考的条件列表；
• 条件选项是那些条件可能取到的值；
• 动作声明是判定后可能采取的行动；
• 动作选项表明那些动作会在怎么样的条件下发生。

③判定表构造步骤

1. 列出所有条件，将此填写到判定表的条件声明象限中去；
2. 列出所有的动作，将此填写至判定表的动作声明象限中去；
3. 计算所有可能的、有意义的条件组合，确定组合规则个数，填写在判定表的条件选项象限中去；
4. 将每一个组合得到的动作，填入动作选项象限；
5. 简化规则，合并及删除等价的操作；

合并原则：找出动作选项在同一行的，检查上面的每一个条件的取值是否影响该操作的执行；如果条件的取值不起作用，则可以合并等价操作，否则不能简化。

6. 重新排列合并后的判定表。

④适用范围
如果存在复杂的条件组合或动作，或者要求判定分析的完备性，建议用判定表进行描述。

⑤示例

(3-4) 判定树
①相关概念
若判定过程十分复杂，那么利用判定表进行描述会使得表的规模十分庞大，导致信息难以理解。因此需要借助判定树辅助理解。

②适用范围
如果条件和动作的顺序非常关键，或者希望用更加直观的方式来描述各种组合和动作，建议用判定树描述。

③示例

(4) 数据字典

(4-1) 作用

• 在数据流图的层次结构中，除对原始过程的逻辑内容进行细致的描述外，对涉及的数据流和数据存储也需要进行详细的说明。因此需要借助数据字典来实现。
• 数据字典列出了数据流图的所有元素，并定义每个元素的名称、表示方法、单位/格式、范围、使用地点、使用方法、以及其他信息的描述。

(4-2) 数据元素描述规范

(4-3) 数据字典常用符号

4.4.2 数据建模

(1) 基本概念

过程建模是以数据在系统中的产生和使用为重点，以数据交换的过程为核心，通过建立层次结构的过程模型来描述。它同时描述了系统的行为和数据。

(2) 实体关系图

数据建模通常使用**实体关系图(ER图)**进行。ER图使用实体、属性、关系这3个基本的构建单位来描述数据模型。

(2-1) 实体
实体是描述事物的元素，是需要在系统中收集和存储的现实世界事物的类别描述。

(2-2) 属性
①相关概念

• 属性是对实体进行描述的特征，一系列属性集合起来边可以描述一个实体的实例；属性是实体的特征而不是数据。
• 属性会以特定形式存在，而这种存在便是数据，这些数据称为属性的值。

②标识符

在把实例归类为实体进行统一形式的描述之后，需要一种唯一确定和表示每个实例的手段。

• ER图通过为实体指定一个或多个属性的组合来唯一地确定和表示每个实例。这些属性或属性组合称为实体的标识符，也称为键。
• 一个实体可以有许多的键，这些键也被称为候选键。
• 虽然所有的候选键都能用来标识实例，但通常会从多个候选键中选择和使用固定的某一个键来进行实例表示，而这个被选中的键称为主键，并且常在作为主键的属性下加下划线。没有被选为主键的其他候选键称为替代键。
  

(2-3) 关系
①相关概念

• 实体并非独立存在的，各个实体间会相互交互，相互影响，共同支持业务的完成；
• 关系就是存在于各个实体之间的自然联系；
• 所有的关系隐含都是双向的，这意味着它们可以从两个方向进行解释。

②关系度数
关系的度数指参与关系的实体数量，是度量关系复杂度的一个指标。

• 一元关系：只有一个实体参与的关系存在于实体的不同实例之间；
• 二元关系：存在于两个实体之间的关系，也是最为常见的相互关系；
• N元关系：存在与N个实体之间的关系。
  

③关系基数
关系的基数也称之为关系的约束。一个实体在关系中的基数定义了在该关系中其他实体实例确定的情况下，该实体实例可能参与关系的数量。
关系分为3种，分别为：一对一、一对多、多对多。

(2-4) ER图的创建
依据充分描述信息的ER图创建：

如果在建立ER图之前，所需要的数据描述信息已经得到充分的获取，那么ER图的创建过程是从信息的描述中辩识和描述数据模型元素的过程。

1. 辨别实体；
2. 确定实体的标识符；
3. 建立实体之间的关系；
4. 添加详细得描述信息。

依据硬数据表单的ER图创建：

除了文本信息，硬数据表单也是建立数据模型的理想材料。

1. 分析表单内容；
2. 建立主题之间的关系；
3. 围绕主题组织表单的项目；
4. 补充ER图的详细信息。

4.4.3 过程模型与数据模型的联系

(1) 背景

结构化的分析方法使用ER图来进行描述系统的数据，使用过程模型来描述系统的行为。但是在ER图和过程模型之间的协同问题上始终没有下形成有效的解决方案。

(2) 功能/实体矩阵

• 通过功能/实体矩阵，实现ER图与过程模型的同步；
• 建立功能/实体矩阵的过程也是一次极好的检查，可以帮助验证过程模型和数据模型的正确性，发现其中的错误、遗漏、冗余和不一致。

没有任何关联功能的实体都是可疑的，不对任何数据进行操作的过程都是可疑的。

(3) 示例

• 该表描述了一个课程注册系统的过程模型和数据模型的协同关系；
• 表的行反映的是该系统的过程模型，列反映的是该系统的数据模型。表中的数据单元说明了对应行的功能会对所对应的列的数据进行的操作；
• 操作分别为：创建©、读取®、更新(U)、删除(D)；因此功能/实体矩阵也被称为CRUD矩阵。

4.4.4 结构化分析的局限性

1. 虽然有了功能/实体矩阵，但过程模型和数据模型的连接仍然是一个较难的工作；
2. 结构化分析向结构化设计的过渡(数据流图到结构图的过度)，中间有着难以处理的鸿沟；
3. 结构化分析过于重视对已有系统的建模，随着更多复杂应用的出现，结构化分析方法举步维艰。

4.5 需求规格说明

需求规格说明活动就是将需求及其软件解决方案进行定义和文档化，并传递给开发人员的需求工程活动。

4.5.1 需求规格说明文档的类型

• 业务需求文档：描述项目的前景和范围形成的文档；
• 用户需求文档：如果用户需要继续招标，那么招标工作通常是基于用户需求文档进行的；
• 系统需求规格说明文档：在得到用户需求之后，需求工程师需要对其进行建模和分析，细化系统需求并形成系统需求规格说明文档；

系统需求文档从软件、硬件和人力整个系统的角度出发，描述系统的需求和解决方案。系统需求文档的内容较为抽象，具有概括性的特点。并且大多数项目都是以该项目为基础开发的。

• 软件需求规格说明文档：是整个系统功能分配给软件部分的详细描述；
• 硬件需求规格说明文档：是整个系统功能中分配给硬件部分的详细描述；
• 接口需求规格说明文档：是整个系统中需要软件和硬件协同实现部分的详细描述；
• 人机交互文档：是整个系统功能中需要进行人机交互部分的详细描述。

4.5.2 软件需求规格说明文档的读者

• 项目管理者：基于文档进行软件的估算；
• 设计人员和程序员：依据文档完成设计和编码工作；
• 测试人员：根据文档内容设计测试计划，指导后期的软件测试活动；
• 文档编写人员：依据文档内容着手计划用户手册的编写，在软件活动完成之后，结合实际软件的素材进行最终手册的编写；
• 软件维护人员：软件维护需要在充分理解软件现有需求的基础上进行，因此该文档是维护人员执行维护任务的主要依据；
• 培训人员：在理解文档的前提下，合理安排培训的内容和方式。

4.5.3 软件需求规格说明文档模板

下图为IEEE 830-1998标准给出的模板。

4.6 需求验证

4.6.1 相关概念

验证 = 验证 + 确认

• 需求验证，指检查一个文档或制品是否符合另一个文档或制品。
• 需求确认，指检查需求定义是否准确地反映了客户的需要。
• 需求验证(需求验证+需求确认)：一方面是要确保以正确的形式建立需求(需求验证)， 得到足以作为软件创作基础的需求；另一方面是要确保得到内容语义正确的需求(需求确认)，得到能够准确反映用户意图的需求。

4.6.2 需求验证的方法

(1) 需求评审

评审也称为同级评审，是指由作者之外的其他人来检查产品问题的方法。评审主要采用静态分析手段，并且原则上，每一个需求都需要经过评审。

(2) 评审参加人员

• 组织者：负责整个项目中审查活动的组织和规划；
• 仲裁者：负责确保整个审查过程的正确进行，并且协调审查活动；
• 作者：创建或维护软件需求规格说明文档的人，在评审中作为听众听取评论，并在需要时解答审查人员的问题；
• 阅读人员：在审查会议上负责逐一解释软件需求规格说明文档的内容；
• 记录人员：在审查会议上，负责记录审查中发现的问题及修改建议；
• 收集人员：有些评审过程并不会举行集中的会议，而是由分散的检查人员各自独立完成检查。这时，就需要收集人员分别从检查人员那里收集检查结果；
• 审查人员：领域专家、用户代表、技术人员(需要以被审查的文档内容开展工作的人，如设计人员、测试人员)、观察人员(在被审查的文档内容上具有一定经验的人，如作者的同级伙伴、相关产品的需求工程师)。

(3) 评审过程

1. 规划阶段：作者和仲裁者共同制订审查计划，决定审查会议的次数，安排每次审查会议的时间、地点、参加人员和审查内容。
2. 总体部署阶段：作者和仲裁者向所有参与审查会议的人员描述待审查材料的内容、输审查的目标及假设，并分发文档。
3. 准备阶段：审查人员各自独立执行审查任务，记录检查中发现的问题，用以准备开会讨论或提交给收集人员。
4. 审查会议阶段：通过会议讨论，识别、确认和分类分析的错误。
5. 返工阶段：软件作者修改发现的缺陷。
6. 跟踪阶段：仲裁者要确定所有发现的问题都得到了解决，所有的错误都得到了修正。

(4) 评审类型

• 临时评审：最不正式的评审，它只是作者临时起意发起的评审活动；
• 轮查或同级桌查：同时请几个作者的同事分别进行产品的检查；
• 走查：由产品的作者将产品逐一地向同事介绍，并且希望他们给出意见；
• 小组评审：和严格审查相比，它的总体会议和跟踪审查步骤被简化或忽略，一些评审者的角色也可能会被合并；
• 审查：最严格的评审方法，会严格遵守整个评审过程。
  

4.7 需求管理

需求管理阶段的主要任务包括建立和维护需求基线、建立需求跟踪信息、进行变更控制。

4.7.1 建立和维护需求极限

(1) 相关概念

需求基线，是被明确和固定的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合。

(2) 需求管理的方式和步骤

为了有效管理需求，需要建立良好的配置管理和对需求进行版本控制。

1. 为了实现基线的版本控制，需要标识每项需求，记录其相关属性，然后为每一个需求文档建立唯一的版本号标识；

需求属性：ID、来源、产生日期、产生理由、优先级、软件预期成本…

2. 在后续的版本变更中，每次变化都必须被明确记录下来，记录内容包含了变更情况、变更日期、变更原因。

基线的版本控制工作可以通过git等版本管理工具来实现。

4.7.2 建立需求跟踪信息

(1) 任务背景

为了避免软件系统开发过程或演化过程中发生与需求基线不一致、偏离风险增大的现象所导致的软件开发质量、成本和事件出现错误，因此提出了需求跟踪。

(2) 双向跟踪能力

• 后向跟踪：要求跟踪需求的去向，寻找特定需求的导出需求或者寻找实现特定需求的相关项目资产；
• 前向跟踪：要求跟踪需求的来源，寻找导出特定需求的更高一级需求或者寻找提出特定需求的用户。

4.7.3 进行变更控制

• 需求的提请者需要以正式的渠道提请需求变化的请求；
• 提交的需求变更请求都会被交给请求的接收者，接收者接受到请求之后会给每一个请求分配一个唯一标识的标签；
• 评估需求变化可能带来的影响，项目会指定固定的人来执行评估行为；
• 变更控制委员会批准的变更请求会被通知给所有需要修改工作产品的团队成员，并由他们完成变更的修改工作；
• 为了确保变更涉及到的各个部分都得到了正确的修改，还需要执行验证工作。验证完成后，修改者才可以将修改后的软件投入使用，并重新定义需求基线以反映新的变更。

五、结构化软件设计

5.1 软件设计的相关概念

5.1.1 软件设计任务

软件设计分为概要设计阶段和详细设计阶段。概要设计阶段将软件需求转化要完成体系结构设计、数据设计和接口设计；详细设计阶段要完成过程设计，对结构的表示进行细化，最终得到详细得数据结构和算法描述。

(1) 体系结构设计

体系结构设计定义软件模块及其之间的关系。软件的结构化设计一般分为两类：

• 根据系统的数据流进行设计（面向数据流的设计、过程驱动的设计）；
• 根据系统的数据结构进行设计（面向数据结构的设计、数据驱动设计）。

(2) 数据设计

根据需求阶段的ER图来确定软件涉及的文件系统结构和数据库的表结构。

(3) 接口设计

• 外部接口设计：用户界面、目标系统、其他软件设备、软件系统的接口；
• 内部接口设计：系统内部各种元素之间的接口。

(4) 过程设计

确定软件各个组成部分的内部数据结构和算法。

5.1.2 软件设计的原则

(1) 模块化

(1-1) 相关概念
模块是能够独立完成一定功能的程序语句的集合，即数据结构和程序代码的集合体。
模块也是软件构成的基本单位。
常见的模块有：函数、过程、子程序。

(1-2) 模块-成本关系

• 当模块数目增加时，各模块的实现成本降低，导致软件成本降低；
• 当模块数目增加时，各模块之间的接口成本上升，导致软件成本提升。

(2) 抽象

抽象是从众多公共事物中抽取公共的、相似的方面，忽略他们之间的差异，即抽取出每一个事物本质的特征而避开底层的细节。

(3) 信息隐藏

将一个模块的内部实现细节进行隐藏起来，即封装。模块外部只能通过模块间的接口进行消息传递。
信息隐藏有利于后期软件的修改，确保当修改一个模块时不会影响其他部分。

(4) 模块的独立性

(4-1) 相关概念
模块独立性指软件系统中每个模块完成一个相对独立子功能的能力，而且要和其他的模块接口是简单链接的。
通常从耦合和内聚两个角度来衡量系统的独立性。

• 耦合：衡量不同模块彼此间互相依赖连接的紧密程度；
• 内聚：衡量一个模块内部各个元素彼此结合的紧密程度。

良好的程序追求的是低耦合、高内聚的状态。

(4-2) 耦合

• 非直接耦合：两模块之间没有直接关系，而是完全通过主模块的控制和调用来实现的；
• 数据耦合：两模块之间通过参数表传递简单数据，而实现模块间的关联；
• 特征耦合：两模块之间通过传递数据结构加以联系，但实际只使用数据结构中的部分数据的耦合关系；

这里的数据结构不是简单的数据，而是记录、数据等数据结构。

• 控制耦合：一个模块传递给另一个模块的参数中包含了控制信息，且控制信息用于控制接受模块中的执行逻辑，这种耦合关系称为控制耦合；
• 外部耦合：一组模块都访问的是同一个全局简单变量而不是同一全局数据结构，并且不是通过参数表传递该全局变量的信息的耦合关系；
• 公共耦合：一组模块都会访问同一个公共数据环境的耦合关系；
• 内容耦合：一个模块直接访问另一个模块，且两模块之间有相同的代码和多个接口的耦合关系。
  

(4-3) 内聚

• 功能内聚：模块内的所有元素属于一个整体，只完成一个单一的功能；
• 顺序内聚：一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入；
• 通信内聚：一个模块内的各个功能部分都使用了相同的输入数据，或产生了想通的输出数据；
• 过程内聚：一个模块内部的处理是相关的，而且必须以特定的次序执行下去；
• 时间内聚：一个模块内的功能必须在同一时间内完成，这些功能也往往只是因为时间因素而被划分为一个模块的内聚；

典型的时间内聚：系统的初始化。

• 逻辑内聚：一个模块吧几种相关功能组合在一起，每次被调用时，由传递给模块的判断参数来确定该模块应该执行哪一个功能的内聚；
• 偶然内聚：如果一个模块完成一组任务，这些任务彼此间即使有关系，也是很松散的。
  

5.1.3 结构化设计图形工具

(1) 结构图

结构图可以清楚的反映出软件模块之间的层次调用关系和联系，严格的定义了各个模块的名字、功能和接口。

(1-1) 结构图的图形符号

1. 模块，用矩形框进行表示。模块的名字要恰当的反映模块的功能。

2. 模块间的调用关系，用单向箭头进行表示。箭头由调用模块指向被调用模块。

3. 模块间的信息传递，在连接线先旁边话短箭头进行表示。尾端为空心圆的短箭头表示数据信息；尾端为实心圆的表示控制信息。
   

4. 模块中的条件调用和循环调用，条件调用用菱形表示、循环调用用弧形符号表示。条件调用和循环调用的条件一般无需注明。
   

(2) HIPO图

HIPO图由H图和IPO图两部分组成。H图描述软件总的模块层次结构；IPO图描述每个模块的输入输出、处理功能及模块的调用的详细情况。

(1) H图
H图为层次图，是用树形结构的一系列多层次的矩形框描述软件系统的结构。

(2) IPO图
IPO图为输入、处理、输出图，IPO图使用简单而又少量的符号，方便的描述出输入数据、数据处理、输出数据之间的关系。

5.1.4 软件设计的规则

• 模块规模应当适中；
• 消除重复功能，改进软件结构；
• 深度、宽度、扇入和扇出要适中；

①深度：结构图中的层次数量。
②宽度：结构图中同一层模块的最大模块数量。
③扇入：结构图中调用一个给定模块的调用模块数目；一个模块的扇入数越大，说明共享该模块的上级模块越多。
④扇出：结构图中一个模块直接调用的下属模块的数目。扇出数一般是2~5，最多不要超过9。

• 模块的作用域在控制域之内；

模块的控制域：模块本身及所有直接或间接从属它的模块的集合。
模块的作用域：受一个模块内的一个判定影响的所有模块的集合。
在一个良好的软件系统中，模块的作用域是控制域的子集。

• 争取降低模块接口的复杂程度。

复杂的接口往往会带来较高的耦合度。

5.2 体系结构设计

5.2.1 数据流类型

(1) 变换流

1. 信息沿输入通路进入系统，同时由外部形式变换为内部形式；
2. 进入系统的信息通过变换中心，经过加工处理以后再沿输出通路变换成外部形式离开软件系统。

经过这两个过程的的信息流称为变换流。

(2) 事务流

事务流也称为数据流。事务流沿输入通路到达事务中心，事务中心根据输入数据的类型在若干条活动通路中选出一条来执行。

5.2.2 数据流的映射方法

1. 划定输入流、输出流的边界，确定变换中心。
   1）确定逻辑输入；
   2）确定逻辑输出；
   3）确定变换中心。
2. 进行第一级分解。
   将DFD映射成变换型的程序结构。
3. 进行第二级分解。
   1）输入控制模块的分解；
   2）输出控制模块的分解；
   3）变换控制模块的分解；
   4）标注结构图中的输入输出信息。
4. 初始结构图的改进。
   1）输入模块的改进；
   2）变化模块和输出模块的改进；
   3）将各个模块的功能进行细分，设计更多的下一级模块来实现模块功能的相互独立。

结构图的改进技巧：

1. 减少模块间的耦合度；
2. 消除**管道*模块；
3. 控制扇出数量。

5.3 数据设计

5.3.1 文件设计

(1) 适用情况

• 数据量大的非结构化数据；（多媒体信息）
• 数据量大，信息松散的数据；（历史记录、档案文件）
• 非关系层次化数据；（系统配置文件）
• 对数据的存取速度要求极高的数据；
• 临时存放的数据。

(2) 常见的文件组织方式

顺序文件、直接存取文件、索引顺序文件、分区文件、虚拟存储文件。

5.3.2 数据库设计

(1) 概念结构设计

概念结构设计是设计数据库的概念模型，通常采用ER图进行设计。

(2) 逻辑结构设计

逻辑结构设计提供了有关数据库内部构造的更加接近于实际存储的逻辑描述。通常将概念结构中的ER图映射成为数据库中的逻辑结构。

(2-1) 映射步骤

1. 实体映射：一个实体可以映射为一个表或多个表。可以采用横切和竖切的方法来进行。

横切：用于记录与时间相关的实体对象；
竖切：用于实例较少而属性较多的映射。

2. 关系映射。

常见的关系映射：1:1关系映射、1:N关系映射、M:N关系映射。

3. 数据表规范：

• 第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
• 第二范式：满足第一范式，而且每个非关键字属性都是由整个关键字决定的。
• 第三范式：符合第二范式，每个非关键字属性的进一步描述，即一个非关键字属性值不依赖于另一个非关键字属性值。

(3) 物理结构设计

物理结构设计是在逻辑结构设计的基础上建立数据库的物理模型，即数据库管理系统中的表、索引、视图等。

5.4 接口设计

5.4.1 相关概念

• 接口设计的依据是数据流图中的自动化系统边界。
• 自动化系统边界将数据图中的处理划分为手工处理部分和系统处理部分，在系统边界之外的是手工处理部分；在系统边界之内的事系统处理部分。
• 数据流可以在系统外部、系统边界和系统内部 流动。穿过系统边界的数据流代表了系统的输入和输出。
• 系统的接口设计是由穿过边界的数据流定义的。在最终的系统中，数据流将称为用户界面的表单、报表与其他系统交互的文件或通信。
• 接口设计包含：人机界面的交互设计、软件与其他硬件系统之间的接口设计、模块或软件构建间的接口设计。

5.4.2 人机界面的交互设计

人机界面是人机交互的主要方式，用户界面的质量直接影响用户对软件的使用、用户情绪和工作效率、用户软件产品的评价，以及软件产品的竞争力和寿命。

一般设计技巧：

• 一般可交互性方面：
  1）在同一用户界面中，所有的菜单选项、命令输入、数据显示、以及其他功能应当始终保持同一种形式和风格；
  2）通过向用户提供视觉和听觉的反馈，保持用户与界面间的双向通信；
  3）对所有可能造成损害的行为要求用户进行确认；
  4）对大多数行为运行操作；
  5）尽量减少用户记忆上的负担；
  6）最大程度减少用户敲击按钮的次数，减少鼠标移动的距离；
  7）对用户产生的错误采取最大的宽容态度；
  8）按功能分类组织界面上的活动；
  9）提供上下文敏感的求助系统；
  10）用简短的动词和动词短语提示命令。
• 信息显示方面：
  1）仅显示与上下文有关的信息；
  2）避免数据过于冗余；
  3）采用统一符号、约定的缩写和预先定义好的颜色；
  4）允许用户对可视环境进行维护；
  5）只显示有意义的出错信息；
  6）用大小写、缩进和分组的方式提供可理解性；
  7）用窗口分隔不同种类的信息；
  8）用类比的手法表示信息；
  9）合理划分并高效使用显示屏。
• 数据输入：
  1）尽量减少用户输入的动作；
  2）保证显示方式与输入方式协调一致；
  3）允许用户定制输入格式；
  4）采用多种交互方式，允许用户自主选择交互方式；
  5）隐藏当前状态下不可选用的命令；
  6）允许用户控制交互过程；
  7）为所有输入动作提供帮助信息；
  8）删除所有无现实意义的输入。

5.5 过程设计

5.5.1 结构化程序设计

结构化程序设计采用自上而下、逐步求精的设计方法，这种方法符合抽象和分解的原则，是人们解决复杂问题的常用方法。采用这种先整体后局部、先抽象后具体的步骤开发的软件一般都具有清晰的层次结构。
结构化程序设计能提高程序的可读性、可维护性和可验证性，从而提高软件的生产率。

5.5.2过程设计工具

(1) 程序流程图

程序流程图独立于任何一种程序设计语言，较为直观、清晰的展示程序逻辑。

(2) N-S图

N-S图也称为盒图，是一种符合结构化程序设计原则的图像描述工具。

(3) PAD图

PAD图也称为问题分析图，是表示程序逻辑结构的图形工具。

(4) 伪码

伪码是一种介于自然语言和形式化语言之间的半形式化语言，用于描述功能模块的算法设计和加工细节。

5.6 软件设计规格说明书文档

下图为IEEE 1016-1998标准的模板。

六、面向对象的需求分析

• 客观世界是由对象组成的，任何客观的事物或实体都是对象，复杂的对象可以有简单对象组成。
• 具有相同数据和操作的对象，可以规定为一个类，对象是类的一个实例。
• 类可以派生出子类，子类既可以继承父类的全部特性(数据和操作)，又可以有自己的新特性。子类与父类形成类的层次关系。
• 对象之间通过消息传递相互联系。类具有封装性，其数据和操作对外界是不可见的，外界只能通过消息请求某些操作，提供所需的服务。

即面向对象=对象+类+继承+通信。

6.1 面向对象的基本概念

6.1.1 对象与类

(1) 对象

对象是系统中用来描述客观事物的一个实体，他是构成系统的一个基本单位，由一组属性和对这个属性进行操作的一组服务组成的封装体。
服务和属性是构成对象的两个基本要素。

• 属性是用来描述对象静态特征的一个数据项；属性表示对象的性质，属性的值规定了对象的状态。
• 服务是用来描述对象动态特征的一个操作序列；服务是对象可以展现的外部服务，表现对象的行为。

同一个对象在软件的不同阶段会有不同的表现形式：

• 分析阶段：对象主要是从问题域中抽象出来的，反应的是概念的实体对象；
• 设计阶段：主要结合实现环境增加用户界面对象和数据存储对象；
• 实现阶段：使用一种确切的程序设计语言来详细描述该对象的代码。

(2) 类

类是具有相同属性和服务(方法)的一组对象的集合，他为该类的全部对象提供了统一的抽象描述，内部也包括属性和服务两个部分。

(3) 实例

类是对象的抽象，而对象是类的实例，类在现实世界是不存在的，类被具体化后得到的对象是具体存在于客观世界的实例。

(4) 消息(调用)

一个对象让另一个对象执行它的某种方法称为发消息，所发送的消息中需要包含接收消息的对象名和方法名。
在面向对象中，所有的功能都是通过对象之间互发消息来实现的，消息机制可以像搭积木一样，快速开发出一个全新的系统。

6.1.2 封装、继承和多态

通过封装能将对象的定义和对象的实现分开，通过继承能体现类与类之间的关系，通过它们之间的关系带来动态绑定和实体的多态性。

(1) 封装

封装把对象的属性和服务结合成一个独立的系统单元，将对象外部的特征（使用的方法）与内部的实现细节（属性和方法是如何实现的）分开。通过封装信息体现出来事务的相对独立性。

(2) 继承

继承是指一个类的定义中可以派生出另一个类的定义，派生出的类（子类）可以自动拥有父类的全部属性和服务。

类的继承是软件重用的一种形式，通过继承的属性和行为扩充原有类的功能，进而节省开发时间。

(3) 多态

(3-1) 重写
若子类中定义的某种方法与父类具有相同的名称和参数，则该方法称为重写。

(3-2) 重载
若一个类中定义了多个同名的方法，它们或有不同的参数个数或参数类型，则称之为重载。

(3-3) 接口的多态性
在一个接口中定义的抽象方法，可以有多个类以不同的方法来实现这个接口中的抽象方法。

6.1.3 面向对象的分析概述

面向对象的分析，就是抽取和整理用户需求建立问题域精确模型的过程。

• 从外部来看：面向对象分析就是对系统上下文或系统环境建模；
• 从交互来看：面向对象分析是对系统与环境之间或者是一个系统各组成成分之间的交互建模；
• 从结构来看：面向对象分析是对系统的体系结构和系统处理的数据结构建模；
• 从行为来看：面向对象分析是对系统的动态行为和事件的响应方式的建模。

常见的UML图：

• 活动图、用例图、时序图、类图、状态图。

面向对象的建模过程：

1. 与用户沟通，了解用户基本需求；
2. 确定系统的边界，建立上下文模型；
3. 了解业务流程，建立活动图模型；
4. 从系统与用户交互出发，确定目标系统功能，建立用例模型；
5. 识别问题域中的全部实体对象和类，建立系统静态结构模型；
6. 基于用例，通过时序图描述系统间各对象的关系；
7. 识别对象的行为和系统的过程，通过状态图描述事件的对象的状态变化；
8. 重复执行1~7，直至建立出完整的模型。

6.2 上下文模型

上下文图是数据流图的一个特定层次，用来说明系统的上下文环境、确定系统的边界。

6.3 活动图与业务流程

活动图本质上是一种流程图，它着重表现一个活动到另一个活动的控制流，是内部处理驱动的流程。

6.3.1 活动图规范

(1) 起始点

(1-1) 用途
起始点指的是一连串活动的开始点，在一个活动图中起始点有且只有一个。

(1-2) 图示

(2) 结束点

(2-1) 用途
结束点指的是一连串活动的终结点，在一个活动图中可以有多个结束点。

(2-2) 图示

(3) 活动

(3-1) 用途
活动指人或系统的一连串执行细节。

(3-2) 图示

(4) 对象

(4-1) 用途
活动图能表示对象的数据流和控制流。在活动图中，对象可以作为动作的输入或输出，或简单的表示指定动作对对象的影响。

当对象是一个动作的输出时，用一个从动作指向对象的虚线箭头来表示；当对象是一个动作的输入时，用一个从对象指向动作的虚线箭头来表示。

(4-2) 图示

(5) 迁移

• 迁移代表流程控制权的迁移。当某一个活动结束后，流程的控制权迁移给另一个活动。

(6) 分支

• 当指定一个分支时，从分支连接出去的迁移必须要有条件表达式，在UML中称之为“约束”。
• 在UML中用[ ]来表示约束，即依据条件来约束迁移。

(7) 分叉与会和

• 分叉与会和主要代表对于后续活动的同步处理。

(8) 分区

通过分区，可以将活动分配给相对于的角色。在UML中通常使用泳道图来表示。

6.3.2 活动图示例

下图为快餐选购系统活动图：

6.4 用例图与系统需求

6.4.1 用例图规范

(1) 用例

(1-1) 作用
用例代表着用户对系统的一个“完整的期望”，一个用例代表某个特定的用户在完成该期望后就可以离开系统。

(1-2) 图示

(2) 执行者

(2-1) 作用
执行者代表系统外部对于系统有影响力的用户或外部系统。

(2-2) 图示

(3) 边界

(3-1) 作用
边界代表着系统的范围，利用边界可以可视化地展示系统的内外之分。

(3-2) 图示

(4) 泛化

(4-1) 作用
执行者与执行者之间可以有泛化关系。

(4-2) 图示

(5) 关联

(5-1) 作用
执行者与用例之间的关系，只能用关联关系表示执行者启动用例。

(5-2) 图示

(6) 用例间的关系

(6-1) 种类

• 包含关系：一个用例可以包含其他用例的关系；
• 扩展关系：当某个基本用例需要附加一个用例来扩展其原有的功能时，附加的扩展用例与原始的基本用例之间的关系就是扩展关系；
• 泛化关系：类似于继承关系。

(6-2) 图示

6.4.2 用例图示例

下图为快餐修够系统用例图：

6.5 静态结构

• 系统中通常有静态结构和动态结构两种。

6.6 类图

类的种类：

• 实体类： 是从客观世界中的实体对象归纳和抽象出来的，用于长期保存系统中的信息，以及提供对这些信息的相关处理行为。
• 边界类： 是从系统和外界进行交互的对象中归纳、抽象出来的，它是系统的对象和系统外的执行者连接的媒介，外界的消息只有通过边界类对象的实例才能发送给系统；
• 控制类： 是用于协调系统边界类和实体类之间的交互。

6.6.1 类图的规范

(1) 类

类主要由类名、属性、操作构成。

(1-1) 类名

• 类名是访问类的索引，应当确保其清晰、准确、无歧义。

(1-2) 属性

• 属性有不同的可见性，利用可见性可以控制外部事件对类中属性的操作方式。

• 属性的语法格式：[可见性] 属性名 [：类型] [=初始值{约束特性}]

(1-3) 操作

• 操作描述对数据的具体处理方法 。
• 操作的语法格式：[可见性] 操作名 [(参数表)] [：返回类型] [约束特性]

(2) 关联

关联表达了两个类对象彼此间的结构性关系。

示例：

(3) 泛化关系

(3-1) 作用
泛化关系表达了两个类之间“一般”与“特殊”的关系。一般来说，会为了增加系统的弹性而设计泛化关系。

(3-2) 图示

(4) 整体-部分 关系

整体-部分关系分为聚合与组合两种。

• 聚合关系：处于部分方的类的实例，可以同时参与多个处于整体方的类的实例的构成，同时部分方的类的实例也可以独立存在；
• 组合关系：部分方的类的实例完全隶属于整体方的类的实例，部分类需要于整体类共存，一旦整体类的实例不存在了，部分类的实例便随之销毁。

图示：

(5) 依赖关系

依赖关系是一种使用关系，依赖关系的两个类并没有结构上的关联。

图示：

(6) 多重性

多重性通常在关联或整体-部分关系中加以使用。代表着对象关系结构中，彼此能够允许的最少或最多的数量。

图示：

6.6.2 类图的建模过程

1. 识别类与对象；
2. 识别属性；
3. 确定操作；
4. 识别关联；

6.6.3 类图的示例

下图为计算机销售系统的静态模型：

6.7 时序图与交互模型

6.7.1 时序图的功能

• 表达设计人员心中关于将来程序在运行时的对象协作模型；
• 验证软件领域模型类图的正确性；
• 为程序员提供编码蓝图。

6.7.2 时序图规范

(1) 对象

相关概念
对象在UML中以“对象名称：类名称”的方式来表达。若使用“：类名称”来表达对象，则代表该对象并没有被指定特定的名称。

(2) 消息

(2-1) 相关概念
常见的四种消息类型：

• 简单消息： 表示控制如何从一个对象发送给另一个对象，并不包含控制的细节；
• 同步消息： 同步意味着阻碍和等待，如果对象A给对象B发送一个消息，对象A等待对象B 执行完后再执行对象A自己的操作；
• 异步消息： 异步意味着非阻塞，如果对象A给对象B发送一个消息对象A不必等待对象B执行完这个消息就可以接着进行自身的工作；
• 返回消息： 操作调用一旦完成返回的消息。

(2-2) 图示

(3) 生命线

• 对象有生命线且用虚线表示。 在时序图中，对象必须要在其生命线中才能够彼此交换消息。在时序图中，时间因素主要通过自上而下的方式来呈现。
• 两个对象的生命线之间带有箭头的实线表示对象间的通信，而虚线则表示返回消息，也有对象可以给自己发送消息。
• 每个对象生命线上的狭长矩形是活动棒，在活动棒内的所有消息存在清晰的时序关系。这些消息所引发的操作要么全做，要么全不做，共同完成一个任务。

6.7.3 时序图示例

下图为快餐选购系统的时序图：

6.8 状态图与事件驱动模型

通过状态图来支持基于事件的模型。状态图用来描述一个类对象在不同用例间状态的迁移。当一个用例或某个事件发生时，类对象的状态就会发生迁移。状态图有助于分析人员审核业务逻辑，以完善静态模型。

6.8.1 状态图规范

(1) 起始状态

(1-1) 相关概念
在一个状态机或状态机图中，有且只有一个起始状态。

(1-2) 图示

(2) 结束状态

(2-1) 相关概念
结束状态代表整个状态机到此结束。在一个状态机或状态机图中，可以有多个结束状态。

(2-2) 图示

(3) 状态

(3-1) 相关概念
圆边矩形代表系统状态，其中可能包括此状态中执行动作的简单描述。

(3-2) 图示

(4) 迁移

(4-1) 相关概念
状态与状态之间利用迁移来表达期间的关系，这代表状态的变化情形。带标签的箭头代表促使系统从一种状态变为另一种状态的激励因素。

(4-2) 图示

(5) 事件触发器

因为某个事件发生而造成状态的迁移时，在迁移关系上可以标记该事件，这称之为事件触发器。

6.8.2 识别状态空间

1. 识别对象在问题域中的生命周期；
2. 确定对象生命周期阶段的划分策略；
3. 重新按阶段描述对象的生命周期；
4. 识别对象在每个候选状态下的动作，并对状态空间进行调整；
5. 分析每个状态的确定因素（对象的数据属性）；
6. 检查对象状态的确定性和状态间的互斥性。

6.8.3 状态图示例

下图为商品下单的状态图：

七、面向对象的设计

面向对象的设计是将分析所创建的分析模型转换为设计模型；同时通过进一步细化需求，对分析模型加以补充和修正。在面向对象设计中，主要考虑系统做什么，而不是系统怎么做。

7.1 面向对象软件设计概述

面向对象是以面向对象分析产生的系统规格说明书为基础，设计出描述如何实现各项需求的解决方案，这个解决方案是后续进行系统实现的基础。

7.1.1 面向对象设计的过程

(1) 基本概念

软件设计创建了软件的表示模型，该设计模型提供了软件体系结构、数据结构、接口和构建的细节，这些细节都是实现系统说必须的。
软件设计是建模活动的最后一个软件工程活动，后续就紧接着进入构建阶段编码和测试。

(2) 软件设计中的信息流

通过基于场景的元素、基于类的元素和行为元素所表示的需求模型是设计任务的输入，而数据或类的设计、体系结构设计、接口设计和构建设计是设计任务的输出。

1. 数据设计或类设计： 将类模型转化为设计类的实现及软件实现所要求的数据结构。（设计类和软件实现所需的数据结构）
2. 体系结构设计： 定义了软件主要结构化元素之间的关系、可满足系统需求的体系结构风格和模式，以及影响体系结构实现方式的约束。
3. 接口设计： 描述软件和协作系统之间、软件和使用人员之间是如何通信的。（数据交流的方式）
4. 构建设计： 将软件体系结构的结构化元素变换为软件构件的过程性描述。

(3) 面向对象设计的基本步骤

1. 通过建立模型表示系统或产品的体系结构；
2. 为各类接口建模，这些接口在软件和最终用户、软件和其他系统与设备及软件和自身组成的构建之间起到的连接作用；
3. 详细设计构成系统的软件构建。

7.1.2 面向对象设计准则

(1) 模块化

• 自顶向下、分而治之是控制系统复杂性的重要手段。
• 通过将问题分解成众多的子问题，可以得到更多易于管理和控制的模块。
• 这些模块具有清晰的抽象界面，同时还要指名模块与模块之间的相互作用关系，每个模块完成其指定的任务。
• 面向对象软件开发模式，把系统分解成模块的设计原理；对象就是模块，他把数据结构和操作这些数据的方法紧密链接在一起。

(2) 抽象

• 类实际上是一种抽象数据类型。
• 规格说明抽象：类对外开放的公共接口构成了类的规格说明（协议），这种接口规定了外界可以使用的合法操作服务，利用这些操作可对类实例中包含的数据进行操作。
• 参数化抽象：当描述类的规格说明时，并不去指定所要操作的数据类型，而是把类型作为参数。这使类的抽象程度更高，应用范围更广，可复用性更高。

(3) 信息隐蔽

• 在进行模块化设计时，应该使一个模块内包含的信息对于不需要这些信息的其他模块来说是不能被访问的。
• 在面向对象的方法中，信息隐蔽通过对象的封装来实现。
• 类结构分离了接口与实现，封装和隐蔽的不是对象的一切信息，而是对象的实现信息、实现细节，即对象属性的表示方法和操作实现的算法。

(4) 低耦合

(4-1) 基本概念

• 耦合度指一个软件结构内不同模块间互联的紧密程度。

如果一个类对象过多的依赖其他类对象来完成自己的工作，不仅会给理解、测试、修高造成困难，还会大幅降低该类的可复用性和可移植性。

• 对象之间应该通过类的接口来实现耦合。

(4-2) 耦合类型

• 交互耦合：对象之间的耦合通过消息连接来实现。
  [降低交互耦合]
  遵循规则：
  1）尽量降低消息连接的复杂程度。应该尽量减少消息中包含的参数个数，降低参数的复杂程度；
  2）减少对象发送或接收的消息数。

• 继承耦合：继承是一般化类与特殊类之间的一种耦合形式。在本质上，通过继承关系结合起来的父类与子类，构成了系统中粒度更大的模块。
  [提升继承耦合程度]

(5) 低内聚

(5-1) 相关概念
内聚性是衡量一个模块内部各个元素彼此结合的紧密程度。

(5-2) 内聚类型

• 操作内聚： 一个操作应该完成一个操作且仅完成一个功能；
• 类内聚： 一个类应该只有一个用途，它的属性和服务应该是高内聚的；类的属性和服务应该全都是完成该类对象任务所必须的；
• ** 泛化内聚：** 设计出泛化结构应该符合多数人的概念，这种结构应该是对相应的领域知识的正确抽取。

(6) 可复用

• 尽量使用已有的类，包括开发环境提供的类库及以往开发类似系统时创建的类；
• 若确实需要创建新的类，则在设计这些类时，应该考虑将来的可重复使用性。

7.2 体系结构设计

7.2.1 分层体系结构

(1) 相关概念

(1-1) 结构描述
将系统组织成分层结构，每一层中包含一组相关的功能。每一层提供服务给紧邻的上一层，因此最底层是有可能被整个系统所使用的核心服务。

(1-2) 使用时机

• 在已有系统的基础上构建新的设施时使用；
• 当开发团队由多个分散的小团队组成，且每个团队负责一层的功能时使用；
• 当系统存在多层信息安全性需求时使用。

(1-3) 结构优点

1. 允许在接口保持不变的条件下更换整个下一层；
2. 在每一层中可以提供多个重复的服务以增加系统的可靠性。

(1-4) 缺点

1. 在具体实践中，在各层之间提供一个干净的分离通常是困难的，高层可能不得不直接与低层进行直接交互而不是通过紧邻的下一层进行交互；
2. 性能会是个问题，服务的请求会在每一层中被处理，所以需要错层解释。

(2) 分层体系结构示例

• 第一层包括了系统支持软件，如数据库和操作系统的支持；
• 第二层是应用程序层，如与应用功能相关的组件、可以被其他应用组件利用的实用工具组件；
• 第三层是与用户界面管理相关，如提供用户的身份验证和授权；
• 第四层提供用户界面设施。

7.2.2 三层架构

(1) 界面层

用于显示数据和接收用户输入的数据，为用户提供一个人机交互式操作的界面。

(2) 业务逻辑层

主要针对具体问题进行操作，也可以理解成对数据层的操作、对数据业务逻辑处理。

业务逻辑层的主要任务：

• 从界面层接收请求；
• 根据业务规则处理请求；
• 将SQL语句发送到数据访问层或者从数据访问层获取数据；
• 将处理结果传回用户界面。

(3) 数据访问层

其功能主要是负责数据库的访问。

数据访问层的主要任务：

• 建立数据库的连接、关闭数据库的连接、释放资源；
• 接收业务逻辑层传来的SQL语句，完成数据的增、删、查、改，将数据返回业务逻辑层。

由于层是一种弱耦合结构，层与层之间的依赖是向下的，低层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。

7.2.3 采用MVC模式的Web体系结构

MVC是模式-视图-控制器的缩写。它用一种业务逻辑、数据、界面显示相互分离的方法组织代码，将业务逻辑聚集到一个部件中，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

• 视图，是用户看到并与其交互的可视化界面。
• 控制器，用于接收用户的请求并判断调用哪个模型去完成用户的请求。
• 模型，负责业务逻辑的处理及数据库的访问。

(1) MVC框架模式的优点

• 耦合性低。运用MVC应用程序的3个部件是相互独立的，改变其中一个部件不会影响其他两个。
• 重用性高。MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，且数据和业务规则从界面层分开，实现最大化的重用代码。
• 有利于开发，提高生产效率。采用MVC模式开发，各开发人员各司其职，开发时间会大大缩短。
• 可维护性高。MVC使开发和维护用户接口的技术含量降低。分离视图层和业务逻辑层使Web应用易于更改和维护。

(2) MVC的典例

最典型的MVC模式应用是：JSP+Servlet+JavaBean+DAO

• JSP作为表现层。
• Servlet作为控制器。
• JavaBean作为模型。
• DAO作为业务逻辑模型。

7.2.4 系统逻辑结构与类包图

包图由若干个包及包之间的关系组成。包是一种分组机制，将同类的类、对象、模型元素放在一起，形成高内聚、低耦合的类集合。包也就是一个子系统。

(1) 包图的规范

在MVC框架模式下，可以将属于同一层次的类放在相同的包中，即从逻辑上体现了系统的体系结构，又方便后期的组织编码开发。

(1-1) 包
包是包图的最基本元素。
包图的表示：

(1-2) 依赖关系
一个包中的类需要引用另一个包中的类或对象才能完成功能时，两个包之间形成依赖关系。
依赖关系由一条加箭头的虚线表示。

(2) 设计要求

• 层与层之间的耦合要尽量松散；
• 级别相同、职责类似的元素应该被组织到同一层中；
• 复杂的模块应该被继承分解为粒度更细的层或子系统；
• 尽可能的将发生变化的元素封装在一层中；
• 每一层应当只调用下一层提供的服务，而不能跨层调用；
• 一层绝不能使用上一层提供的功能服务，即不能在层与层间造成双向依赖。

(3) 包图建模

通过MVC模式建模

• Jsp包存放所有与用户交互的页面。
• Servlet包存放控制类、接收用户的请求、负责页面的跳转。
• Vo包存放实体类，负责数据的存储和传输。
• Dbc包存放负责加载数据库驱动、创建数据库连接、获得数据库连接、关闭数据库连接的类。
• Dao包存放业务逻辑处理和数据访问的类。

7.2.5 系统物理体系结构与构建图

构件是具有相对独立功能、可以明显辩识、接口由契约制定、语境有明显依赖关系、可独立部署且多由第三方提供的可组装软件实体。

(1) 构件图规范

构件的主要组成元素包括构件和接口。接口是一个构件给其他构件的一组操作。

(1-1) 构件
构件是系统中可以被抽换的物理部件，一个构件通常会实现一组特定的接口。

(1-2) 提供接口
构件可以利用提供接口来表达某个构件的接口集合，提供接口是向其他构件提供服务的，在构件内部需要实现该接口的全部特征。

(1-3) 需求接口
构件如果需要其他构件的服务才能运作，可以利用需求接口来表达。

(1-4) 依赖关系
构件之间的依赖关系表示一个构件需要另一些构件才能有完整的意义。
依赖关系用一个带箭头的虚线来表示。

(2) 基于实体类的构建图开发示例

7.2.6 系统物理体系结构与部署图

部署图是用于描述系统硬件的物理拓扑结构及在此结构上运行的软件。
部署图用于静态建模，是表示运行时过程节点的结构、构件实例及其对象结构的图。展示了构建图中所提到的构件是如何在系统硬件上部署的，以及各个硬件之间是如何连接的。

(1) 部署图规范

(1-1) 节点
节点是存在于运行时，代表一项计算机资源的物理元素。节点可以分为处理器和设备两种类型。

• 处理器，能够执行软件组件，具有计算能力的节点；
• 设备，不能执行软件组件的外围硬件，是没有计算能力的节点。通常是通过其接口为外界提供某种服务。

(1-2) 构件
构件是系统可替换的物理部件。

• 构件是被节点执行的事物；
• 构件是表示逻辑元素的物理模块，节点则是表示构件的物理部署。

(1-3) 关联关系
关联关系通过一条直线来进行表示，用于指出节点之间存在的某种通信关系。

(1-4) 依赖关系

(2) 部署图建模

7.3 构件级设计

必须在构造软件之前确定软件是否可以工作。。为了保证设计的正确性、以及早期设计表示（即数据、体系结构和接口设计）的一致性，构件级设计需要以一种可以评审设计细节的方式来表示软件。它提供了一种评估数据结构、接口和算法是否能够工作的方法。
在这里，每个构件类的定义或者处理说明都转化为一种详细设计，该设计采用图形或基于文本的形式来详细说明内部的数据结构、局部接口细节和处理逻辑。

7.3.1 从分析类到设计类

从分析类到设计类，需要增加更多实现所需的属性、方法及接口的详细设计。每个构件都要实施细化，细化一旦完成，要对每个属性、操作和接口进行更进一步的细化。对适合每个属性的数据结构必须予以详细说明。此外还需要说明实现与操作相关处理逻辑的算法细节，最后是实现接口所需机制的设计

7.3.2 从用例场景到设计类

用例反映了系统的需求，界定了系统的边界，涵盖了所有的系统运用场景。因此通过对用例场景的分析设计、对用例中对象间的通信机制进行描述，可以准确识别出实现该用例的全部设计类，以及其所需的属性和方法及接口的定义。

从分析类到设计类的转换需要具体的设计模式，在MVC中为 分析类 + 设计模式 = 设计类 这个模式。
在UML中边界对象、控制对象、实体对象的表示图如图所示：

7.3.3 构建详细类图建模

7.4 用户界面设计

用户界面设计的三个准则：

1. 把控制权交给用户；
2. 减轻用户的记忆负担；
3. 保持界面的一致。

7.4.1 将控制权交给用户

1. 以不强迫用户进入不必要或不希望的动作的方式来定义交互模式；
2. 提供灵活的交互；
3. 允许用户交互被中断或撤销；
4. 当技能水平高时可以使交互流线化并允许定制交互；
5. 使用户与内部技术细节隔离起来；
6. 设计应允许用户与出现在屏幕上的对象直接交互。

7.4.2 减轻用户记忆负担

1. 减少对短期记忆的要求；
2. 建立有意义的默认设置；
3. 定义直观的快捷方式；
4. 界面的视觉布局应该基于真实世界的象征；
5. 以一种渐进的方式显示信息。

7.4.3 保持界面一致

1. 允许用户将当前任务放入有意义的环境中；
2. 在完整的产品线内保持一致性；
3. 如果过去的交互模式已经建立起了用户期望，非必要的情况下不要改变它。

八、在面向对象思想下的软件开发

基于构件的开发

8.1 实施阶段的准备工作

8.1.1 硬件准备

硬件设备包括计算机主机、输入输出设备、存储设备、辅助设备（稳压电源、空调设备等）、通信设备等，要咱找系统设计方案购置、安装、调试这些设备。

8.1.2 软件准备

应用软件往往不是从底层进行开发的，而是建立在一定系统软件的基础上。
即使从底层开发，也需要准备编程语言软件、系统开发的工具软件、数据库管理软件等。软件的配置方案已经包含在系统设计方案中，按照配置方案进行落实就可以了。

8.1.3 开发人员准备

由于系统实施工作量大，需要更多的参与人员，而且软件分析员和软件设计员也并不可能参与到具体的系统实施，而是主要承担组织者和管理者的角色，负责系统需求和系统设计方案的修改和落实。因此需要进行人员的补充，特别是具体编程人员的加入。
由于新增加的人员没有参加系统分析和系统设计阶段，所以必须对这些新增人员进行培训，使他们尽快熟悉到开发任务中去。

8.1.4 数据准备

虽然数据字典和数据库设计书规定了数据的格式，但是系统在编程和测试过程中，需要使用到实际的数据，方便编程人员对程序进行调试和测试工作。
而数据的收集、整理、录入是一项繁琐的工作，又要保证工作质量，又要花费大量的人力和物力。
一般来说，确定数据库物理模型之后，就应当进行数据的整理、录入。这样既分散了工作量，又可以为系统调试提供真实的数据。

8.2 基于构件的编码

8.2.1 开发环境

由于构件详细到代码，首先需要选择实现系统的编程语言、开发环境，这些在设计阶段都已经得到了考虑。

(1) MyEclipse

MyEclipse是基于Eclipse开发的企业级集成开发环境，主要用于Java、JavaEE及移动应用的开发。

(2) JDK

JDK是Java语言的软件开发工具包，主要用于移动设备、嵌入式设备上的Java应用程序，

(3) Apache Tomcat

Apache Tomcat服务器是一个免费的开源代码的Web应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP程序的首选。

(4) MySQL

MySQL是一个关系型数据库管理系统，关系型数据库将数据保存到不同的表中，而不是放到一个大仓库中，这样就增加了速度并且提高了其灵活性。

8.2.2 从构件设计类图到编码

1. 设计构件模型；
2. 数据表的创建。

8.2.3 构件编码

1. 创建视图层；
2. 创建功能层；
3. DAO层的开发；
   1）使用数据库连接类（DatabaseConnection.java）
   2）映射数据库的VO类；
   3）DAO接口的创建；
4. 构件包目录结构。

8.3 实现问题

• 复用。多数现代软件都是对现有构件或系统的复用。开发一个软件时，应该尽可能的多用现有代码。
• 配置管理。在开发过程中，每个生成的软件构件都会有很多不同的版本；如果没有很好地在配置管理系统中追踪这些版本，有可能在系统中使用错误的版本构件。
• 宿主机-目标机开发。软件产品通常不会在与软件开发环境相同的计算机上运行，更多的是开发时使用一台计算机（宿主机），运行时使用另一台计算机（目标机）。宿主机和目标机的系统可能是同一个类型但是完全不同的运行时环境。

8.3.1 复用

(1) 复用的方向

• 抽象层。这一层不是直接复用软件，而是运用软件设计中的成功抽象。
• 对象层。在这一层中可以直接复用软件中的对象，代替自己编写代码。
• 构件层。构件是一组通过相互合作实现相关功能和服务的对象及对象类的集合，通常需要添加自己的代码对构件进行调整或扩展。
• 系统层。在这一层可以复用整个系统。

(2) 复用的花费

• 寻找可复用的软件并评估其是否符合需求的时间花费。
• 找到合适的可复用软件后，还要有购买此软件的花费。
• 调整和配置可复用的软件构件或系统，使其满足待开发系统需求的花费。
• 集成各个可复用软件及新代码的花费。

8.3.2 配置管理

配置管理是管理变更中软件系统的一般过程。配置管理的目标是支持系统集成过程，使得每个开发人员可以在管理中访问工程代码和文档、查找变更、编译连接构件并生成系统。

配置管理的基本活动：

• 版本管理。对软件构件不同版本的追踪提供支持。版本管理的目标包括协调多个程序员开发的机制，可以防止一个程序员覆盖其他人提交到系统中的代码。
• 系统集成。开发人员提供每一个系统版本时所用的构件定义。这些描述用来编译连接需要的构建从而自动构件一个系统。
• 问题追踪。继续提供支持允许用户报告缺陷及其其他问题，并允许开发人员查看谁在修复这些问题，以及何时完成的修复。

8.3.3 宿主机-目标机开发

软件在一台计算机(宿主机)上开发，但在另一台机器(目标机)中允许，一般情况下，称之为开发平台和运行平台。这些平台不只是指硬件设备，同时还包括安装的操作系统和其他支持软件。

如果开发平台和运行平台是相同的，这样就可以在同一台计算机上开发和测试软件。如果开发平台和运行平台不同，则需要将开发好的软件迁移到运行平台进行测试，或者在开发环境中安装模拟器。

模拟器通常在开发嵌入式系统时使用，用来模拟一个硬件设备。但是开发模拟器的成本较高，只会对当前最常见的几种硬件架构进行模拟。

开发平台所具备的基本条件：

1. 集成编译器和句法导向的编译系统，能够创建、编辑和编译代码；
2. 具有编程语言调试系统；
3. 具有图形编辑工具；
4. 具有测试工具；
5. 具有项目支持工具。

九、软件项目测试

9.1 软件测试概述

9.1.1 软件质量

软件质量的评价方向：

• 软件产品质量满足用户要求的程度；
• 软件各种属性的组合程度；
• 用户对软件产品的综合反映程度；
• 软件在使用过程中满足用户要求的程度。

9.1.2 软件测试的目的

• 从软件质量保证角度来看：测试就是验证或证明软件的功能特性和非功能特性是否满足用户的需求。
• 从软件测试的经济成本角度来看：测试就是需要尽可能早的发现更多的软件缺陷。
  软件测试的工作就是在时间、质量、成本这三者之间取得平衡，对于不同的软件产品，指定相应的可发布的质量标准，以评估软件是否可以发布。

G.J.Myers提出的程序测试的3个观点：

• 测试是为了证明程序有错，而不是为了证明程序无错；
• 一个好的测试用例在于它发现至今没有发现的错误；
• 一个成功的测试是发现了至今未发现的错误的测试。

9.1.3 软件测试的原则

• 尽可能早的开始测试工作；
• 所有的测试都应该能够追溯到用户的需求；
• 由独立的小组或者委托第三方机构来完成测试工作；
• 完全测试是不可能的，不要试图通过穷举测试来验证程序的正确性；
• 重视测试用例；
• 制定详细得测试计划，并严格执行它；
• 注重回归测试；
• Pareto原则。

9.1.4 软件测试用例

测试用例是为了测试能够高效、可靠地进行，对大量的数据中设计的具有代表性或者特殊性的数据进行测试，用来检验某个程序或者路径是否满足特定的要求。

测试用例通常包括测试目标、测试环境、输入数据、测试步骤及预期结果等，以便测试某个程序路径或核实程序是否满足某个特定需求。

在设计测试用例时，需确定测试策略、产品线、产品特性、质量需求等目标，来建立测试用例框架。通常从功能性测试目标和非功能性测试目标来分别进行设计。

在逐步细化设计具体测试用例时，应根据需求规格说明书中的描述、相关的功能模块及操作流程等寻找设计上的弱点、逆向考虑惯性思维及可能的异常输入情况。

测试用例常用组成元素包括用例ID、用例名称、测试目的、测试级别、测试环境、输入数据、测试步骤、预期结果、结论、日期等。

9.1.5 软件开发与软件测试的关系

• 项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。
• 需求分析阶段：进行测试需求分析，根据需求规格说明书制定系统测试计划。
• 详细设计和概要设计阶段：根据详细设计说明书和概要设计说明书，制定集成测试计划和单元测试计划。
• 编码阶段：由开发人员对自己负责的代码进行单元测试。
• 测试阶段：依据各个阶段（单元测试、集成测试、系统测试）的测试计划进行测试，并提交相应的测试报告。

9.2 软件测试技术

9.2.1 黑盒测试

黑盒测试通常在程序界面处进行测试，通过需规格说明书的规定来检测每个功能是否能够正常运行。
只知道系统的输入和输出，不需要了解程序内部结构和内部特性的测试方法称为黑盒测试。
常用方法有：边界值分析法、等价类划分法、因果图、场景法。

(1) 边界值分析法

边界值测试倾向于选择系统边界或边界附近的数据来设计测试用例，这样暴露出程序错误的可能性就会更大一些。

边界值测试一般遵循的原则：

• 如果输入条件规定了值的范围，则应取港大道这个范围的边界的值，以及刚刚超越这个边界的值作为测试的输入数据。
• 如果输入条件规定了值得个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。
• 如果程序的规格说明给出的输出域或输入域是有序集合，则应该选取集合的第一个元素和最后一个元素作为测试数据。
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试数据。
• 分析规格说明书，找出其他可能的边界条件。

(2) 等价类划分法

等价类的划分是将输入域的数据划分为若干不相交的子集，在这些子集中的数据对于揭露程序中的错误是等效的，继而从每个子集中选取具有代表性的数据。

等价类的划分包括有效等价类和无效等价类两种情况。

• 有效等价类是合理的、有意义的输入数据所构成的集合。
• 无效等价类是不合理的或者无意义的输入数据所构成的集合。

(3) 因果图

(3-1) 基本概念
因果图方法适用于多种组合情况产生多个相应动作的情形。
在因果图中，以直线连接左右节点。左节点表示输入状态（原因），右节点表示输出状态（结果）。

(3-2) 因果图的四种关系

(3-3) 因果图的约束关系
在实际情况下，输入状态、输出状态之间都可能存在某些依赖关系，称之为约束。

(3-4) 因果图设计测试用例的步骤

1. 分析软件规格说明描述中哪些是原因，哪些是结果。
2. 分析软件规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，将其表示成连接各个原因与各个结果的因果图。
3. 由于语法或环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。
4. 把因果图转换为判定表。
5. 把判定表的每一列拿出来作为依据，设计测试用例。

(4) 场景法

场景法一般包含基本流和备选流，从一个流程开始，通过描述经过的路径来确定过程，经过遍历所有的基本流和备选流来完成整个场景。

• 基本流是基本事件流，它是从系统某个初始状态开始，经过一系列状态后，到达终止状态的一个业务流程并且是最主要、最基本的一个业务流程。
• 备选流就是备选事件流，它是以基本流为基础，在基本流所经过的每个判断节点处满足不同的触发条件，而导致的其他事件流。

场景法设计测试用例的步骤：

1. 根据说明，描述出程序的基本流和各项备选流。
2. 根据基本流和各项备选流生成不同的场景。
3. 对每一个场景生成相应的测试用例。
4. 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值。

9.2.2 白盒测试

白盒测试又称结构测试。白盒测试清楚地了解了程序结构和处理过程，检查程序结构及路径的正确性，检查软件内部动作是否按照设计说明的规定正常进行。
白盒测试方法主要有逻辑覆盖测试法和基本路径法。

(1) 逻辑覆盖测试法

逻辑覆盖测试是根据程序内部的逻辑结构来设计测试用例的技术。逻辑覆盖可以分为语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖和路径覆盖。

1. 语句覆盖。语句覆盖即设计的若干个测试用例在运行时使程序中的每条语句至少执行一次。语句覆盖执行了每一条语句，但是对于逻辑运算，如||和&&，则无法全面地测试到。
2. 判定覆盖。判定覆盖又称分支覆盖，即设计的若干个测试用例在运行时使程序中的每个判断的真、假分支至少经历一次。判定覆盖比语句覆盖测试能力更强，但是只能判定整个判断语句的最终结果，没有办法确定内部条件的正确性。
3. 条件覆盖。条件覆盖即设计的若干个测试用例在运行时使程序中的每个判断中的每个条件都至少取一次真值一次假值。这种情况覆盖了每个条件，但是并不一定覆盖到了每个判断的分支。
4. 判定-条件覆盖。判定-条件覆盖是将判定覆盖和条件覆盖结合起来设计测试用例。这种方法使得程序所有条件的可能取值都至少执行一次，所有判断的可能结果也至少执行一次。
5. 条件组合覆盖。条件组合覆盖即设计的若干个测试用例在运行时使程序中所有可能的条件取值组合至少执行一次。条件组合覆盖满足了判定覆盖、条件覆盖和判定-条件覆盖准则。
6. 路径覆盖。路径覆盖即覆盖程序中所有可能的途径。

(2) 基本路径测试法

基本路径测试是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。

基本路径测试主要过程：

• 绘制出程序的程序流程图，根据程序流程图，绘制出程序的控制流图。
• 计算程序环路复杂度。环路复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本独立路径数目，这是程序中每个可执行语句至少执行一次所必需的最少测试用例数。
• 找出独立路径。通过程序的控制流图导出基本路径集，列出程序的独立路径。
• 设计测试用例。根据程序结构和程序环路复杂性设计用例输入数据和预期结果，确保基本路径集中的每一条路径的执行。

9.2.3 灰盒测试

**灰盒测试是介于白盒测试与黑盒测试之间的测试。**灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整。灰盒测试结合了白盒测试和黑盒测试的优点，相对于黑盒测试和白盒测试而言，投入的时间相对较少，维护量也较小。

灰盒测试考虑了用户端、特定的系统和操作环境，主要用于多模块的较复杂系统的集成测试阶段。灰盒测试既使用被测对象的整体特性，又使用被测对象的内部具体实现，即它无法知道函数内部具体内容，但是可以知道函数之间的调用。灰盒测试重点检验软件系统内部模块的接口。

灰盒测试能够有效地发现黑盒测试的盲点，可以避免过渡测试，能够及时发现没有来源的更改，行业门槛比白盒测试低。但是灰盒测试不适用简单的系统，相对于黑盒测试来说门槛较高，测试没有白盒测试那么深入。

9.3 软件测试过程

9.3.1 单元测试

单元测试是软件开发过程中所进行的最低级别的测试活动，其目的在于检查每个单元能否正确实现详细设计说明中的功能、性能、接口和设计约束等要求，发现单元内部可能存在的各种缺陷。单元测试作为代码级功能测试，目标就是发现代码中的缺陷。

(1) 单元测试的环境

单元测试是对软件设计的最小单元进行测试。对于一个模块或者一个方法来说，并不是独立存在的，因此在测试时需要考虑到外界与它的联系。

例如，如果对Java或者C++这种面向对象语言进行测试，则被测的基本单元可以是类，也可以是方法。

我们需要用到一些辅助模块来模拟被测模块与其他模块之间的联系。
辅助模块有以下两种：

• 驱动模块。用于模拟被测模块的上级模块。
• 桩模块。用于模拟被测模块在工作过程中所需要调用的模块。

(2) 单元测试的内容

1. 模块接口测试。 检查模块接口是否正确。例如，输入的实参与形参是否一致；调用其他方法的接口是否正确；标识符定义是否一致；是否进行出错处理等。
2. 模块局部数据结构测试。 检查局部数据结构的完整性。例如，是否有不合适或者不相容的类型说明；变量是否有初值、初始化或者默认值是否正确；是否存在从未使用的变量名等。
3. 模块中所有独立执行路径测试。 检查每一条独立执行路径的测试，保证每条语句至少执行一次。
4. 各种错误处理测试。 若模块工作时发生了错误，是否进行了出错处理，处理的措施是否有效。
5. 模块边界测试。 检查模块对于边界处的数据是否能够正常处理。

(3) 单元测试的过程

1. 制订测试计划。在制订单元测试计划时，需要先做好单元测试的准备，如测试所需的各方面资源需求、功能的详细描述、项目计划等相关资料等。然后制定单元测试策略，如在单元测试过程中需要采用的技术和工具、测试完成的标准等。最后根据实际的项目情况及客观因素制订单元测试的日程计划。
2. 设计单元测试。根据详细规格说明书建立单元测试环境，完成测试用例的设计和脚
   本的开发。
3. 实施测试。根据单元测试的日程计划，执行测试用例对被测软件进行完整的测试。若在测试过程中修改了缺陷，则应注意回归测试。
4. 生成测试报告。测试完成后，对文档和测试结果进行整理，形成相应的测试报告。

9.3.2 集成测试

集成测试即组装测试，将已测试过的模块组合成子系统，其目的在于检测单元之间的接口有关的问题，逐步集成为符合概要设计要求的整个系统。

集成测试的方法策略可以粗略地划分为非渐增式集成测试和渐增式集成测试。

• 非渐增式集成测试就是先分别测试各个模块，再将所有软件模块按设计要求放在一起组合成所需的程序，集成后进行整体测试。
• 渐增式集成测试就是从一个模块开始测试，然后把需要测试的模块组合到已经测试好的模块当中，直到所有的模块都组合在一起，完成测试。渐增式测试有自顶向下集成、自底向上集成和三明治集成。

(1) 自顶向下集成

自顶向下集成是从主控模块开始，以深度优先或者广度优先的策略，从上到下组合模块。在测试过程当中，需要设计桩模块来模拟下层模块。

自顶向下集成测试方法要求首先测试控制模块，可以较早的验证控制点和判定点，也有助于减少对驱动模块的需求，但是需要编写桩模块。

(2) 自底向上集成

自底向上集成是从程序的最底层功能模块开始组装测试逐步完成整个系统。这种集成方式可以较早的发现底层的错误，而且不需要编写桩模块，但是需要编写驱动模块。

(3) 三明治测试3.三明治集成

三明治集成也叫作混合法，是将自顶向下和自底向上两种集成方式组合起来进行集成测试， 即对于软件结构的居上层部分使用自顶向下集成方式，对于软件结构居下层部分使用自底向上方式集成，将两者相结合的方式完成测试。
三明治集成兼有自顶向下和自底向上两种集成方式的优缺点，适合关键模块较多的被测软件。

9.3.3 确认测试

确认测试是根据需求规格说明书来进一步验证软件是否满足需求。

经过确认测试，可以对软件做出结论性的评价，如软件各方面是否满足需求规格说明书规定，是否是一个合格的软件。

软件经过检验发现有哪些偏离了需求规格说明书的规定，列出缺陷清单并与开发部门和用户协商解决。确认测试的目标是验证软件的有效性。

确认测试一般包括有效性测试和软件配置审查。

(1) 有效性测试

有效性测试是在模拟的环境下，运用黑盒测试方法，验证被测软件是否满足需求规格说明书列出的需求。经过确认测试，应为该软件给出以下结论性的评价。

• 功能、性能符合需求规格说明书，软件是可以接受的，被认为是合格的软件。
• 功能、性能与需求规格说明书有偏离，要求得到一个缺陷清单。此时需要与用户协商，确定解决问题和缺陷的办法。

(2) 软件配置审查

配置审查工作在确认测试中是重要的一个环节，主要在于确保已开发软件的所有文件资料均已撰写完毕，资料齐全、条目清晰，足以支持运行以后的软件维护工作。

配置审查的文件资料包括用户所需的资料如下:

• 用户手册。用于指导用户安装、使用软件和如何获得服务与援助的相关资料。
• 操作手册。用于说明软件中进行各项操作时的具体步骤和方法。
• 设计资料。设计说明书、源程序及测试资料等。

9.3.4 系统测试

系统测试是将已经确认的软件、硬件等元素结合起来，对整个系统进行总的功能、性能等方面的测试。 系统测试是软件交付前最重要、最全面的测试活动之一。
系统测试是根据需求规格说明书来设计测试用例的。

(1) 系统测试的内容

系统测试的内容非常多，也很繁杂，主要有以下内容:

1. 性能测试。主要检验软件是否达到需求规格说明书中所规定的各种性能指标。性能测试常见的工具有JMeter、Load Runner、WebLoad等。
2. 压力测试。压力测试即强度测试，主要检查程序对异常情况的抵抗能力，通过增加负载来确定系统的性能瓶颈。
3. 容量测试。容量测试是检验系统在正常工作的情况下所能承受的极限条件。
4. 安全性测试。安全性测试是检验系统能够抵御入侵的能力。系统的安全不仅要求能够经受正面攻击，还要求能够经受侧面和背面的攻击。软件系统的安全性一般分为应用级别的安全性、数据库管理系统的安全性和系统级别的安全性。
5. 安装测试。安装测试是测试系统是否能够在不同操作系统上正常进行安装操作。
6. GUI 测试。图形用户界面(GUD测试可以确保系统界面向用户提供了适当的使用、操作信息。GUI测试主要要求界面易用、整洁、美观、规范，用户容易上手使用。
7. 文档测试。文档测试是对系统提交给用户的文档进行验证，可以提高系统的可维护性。

(2) 系统测试的过程

1. 计划阶段。计划阶段根据需求规格说明书分解出各种类型的需求、确定软件测试的范围、撰写系统测试的计划、定义系统测试策略等，形成软件系统测试计划文档。
2. 设计阶段。设计阶段对系统进行详细的测试分析，确定系统测试的具体内容，设计相应的测试用例及测试过程。系统测试设计得是否充分决定了系统测试的质量。
3. 实施阶段。实施阶段根据实际情况选择相应的测试工具，部署测试环境，录制测试脚本。实施阶段的工作直接影响软件测试结果的真实性和可靠性。
4. 执行阶段。执行阶段根据系统测试计划执行测试用例，并记录执行过程和结果。
5. 评估阶段。评估阶段验证系统测试是否达到需求规格说明书的要求，并提供相关数据方便系统调用。

9.3.5 验收测试

验收测试是检测产品是否符合最终用户的要求，并在软件正式交付前确保系统能够正常工作且可用，即确定软件的实现是否满足用户需要或者合同的要求。验收测试是软件正式交付使用之前的最后一个阶段。

验收测试应完成的主要测试工作包括配置复审、合法性检查、文档检查、软件一致性检查、软件功能和性能测试与测试结果评审等工作。

验收测试主要由用户代表来完成， 用户代表通过执行典型任务来测试软件系统，根据平时使用系统的业务来检验软件是否满足功能、性能等方面的需求。

验收测试的结果有两种：一种为功能、性能满足用户要求，可以接受；另一种为软件不满足用户要求，用户无法接受。

验收测试的策略通常有3种，分别为：正式验收测试、AIpha测试（即非正式验收测试）、Beta 测试。验收测试的策略通常根据合同的需求、公司的标准及应用领域的基础来选择。

(1) 正式验收测试

正式验收测试通常是系统测试的延续，是一项严格的过程。在很多组织中，正式验收测试是完全自动执行的。

对于正式验收测试来说，要测试的功能和特性、细节都是已知的，测试是可以自动执行并进行回归测试的。

但是，正式验收测试需要大量的资源和计划，并且由于测试时只会查找预期的缺陷，因此无法发现主观原因造成的缺陷。

(2) Alpha测试

Alpha 测试（即非正式验收测试)是用户在开发方的场所进行的活动， 用户在开发人员的指导下对软件进行使用，开发人员记录发现的错误和遇到的问题。

Alpha 测试是在受控的环境中进行的，不能由程序员或者测试人员来完成。Alpha 测试的关键在于尽可能还原用户实际运行情况和用户的实际操作，并且尽最大努力涵盖所有可能的用户操作方式。

(3) Beta 测试

Beta 测试是由最终用户在客户场所进行的活动。 开发人员通常不在Beta 测试的现场,因此，Beta 测试是软件在开发人员不能控制的真实环境中进行使用的。

用户记录在Beta测试过程中遇到的一切问题，并定期把这些问题反馈给开发人员。在接到反馈报告后，开发人员对软件进行必要的修改。

9.3.6 回归测试

回归测试是指修改了旧代码后，重新进行测试活动。 回归测试严格来讲并不是一个阶段，而是可以存在于软件测试各个阶段过程的测试技术。

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能会带来问题，因此需要进行回归测试回归测试的目的就是检验缺陷是否被正确修改，以及修改的过程中有没有引出新的缺陷。

为了在给定的经费、时间、人力的情况下高效地进行回归测试，需要对测试用例库进行维护，并且依据一定的策略选择相应的回归测试包

(1) 维护测试用例库

测试用例的维护是一个不断的过程，随着软件的修改或者版本的更迭，软件可能添加一些新的功能或者某些功能发生了改变，测试用例库中的测试用例因此可能不再有效或者过时，甚至不再能够运行，需要对测试用例库进行维护，以保证测试用例的有效性。

(2) 选择回归测试包

在回归测试时，由于时间和成本的约束，将测试用例库中的测试用例都重新运行一遍是不实际的，因此，在进行回归测试时，通常选择一组测试包来完成回归测试。在选择测试包时，可以采用基于风险选择测试、基于操作剖面选择测试及再测试修改的部分等策略。

(3) 回归测试的步骤

在进行回归测试时，一般会遵循以下步骤:

1. 识别出软件中被修改的部分。
2. 在原本的测试用例库中排除不适用的测试用例，建立一个新的测试用例库。
3. 根据合适的选择策略，从新的测试用例库中选出测试用例包，测试被修改的软件。
4. 重复执行以上步骤，验证修改是否对现有功能造成了破坏。

十、软件实施、维护与进化

10.1 软件实施概述

10.1.1 实施准备

实施准备阶段制订软件实施计划，为后期的实施过程做好详尽的准备工作。

• 成立软件实施组织机构；
• 对相关人员组织系统级的培训工作；
• 确定软件实施策略；
• 确定双方的工作范围及职责划分；
• 编制软件的实施计划；
• 制定软件实施过程中应遵循的规范、标准等。

10.1.2 业务交流

业务交流阶段根据准备阶段确定的实施策略，完成相关的工作。

业务交流阶段的成果为:

• 软硬件及网络配置规划；
• 软件实施规划建议书；
• 新老软件系统数据接口方案；
• 系统数据准备方案；
• 软件实施培训计划和软件实施培训教材。

10.1.3 软件实施培训

软件实施培训阶段需完成软件培训环境的搭建。软件实施培训包括系统管理员培训、数据库管理员培训和操作员培训。

10.1.4 数据准备及系统初始化

在数据准备阶段，需要对数据进行整理及规范化。软件系统的运行通常需要特定的数据基础，即软件是否能够成功实施也依赖客户是否能够准确、全面、规范化地提供软件所需的基础数据。 数据的整理与规范化主要包括历史数据的整理、数据资料的格式化及各类基础数据的收集与电子化。

系统初始化阶段为：

• 系统搭建运行环境；
• 对系统进行安装、初始化；
• 导入及整理应用的基础数据；
• 设置业务流程；分配用户角色的定义和系统权限；
• 设计与实现新老系统的接口；
• 确定和编制新老系统切换方式。

10.1.5 新老系统切换及试运行

新老系统切换是由先运行系统的工作方式向所开发的系统工作方式转换的过程。同时，系统的设备、数据、人员等也要发生转换。

新老系统切换的方式：

• 直接切入法。即在某一确定的时间点时切换，当到达该时间，老系统停止运行，新系统投入使用。
• 并行切换法。老系统使用的同时新系统也投入使用，新老系统同时运行期间对照两者的输出，利于老系统对新系统进行检验。
• 分段转换法。选用新系统的某一部分取代老系统作为试点，新系统逐步替代老系统。

按照制订的新老系统切换计划完成切换，新系统即投入试运行。在试运行的过程中需要协助用户完成系统的日常维护工作，并提供技术支持。
在系统试运行的过程中收集、整理用户的反馈意见。根据系统的试运行情况，协助用户编制系统试运行报告。若达到试运行的目标，则向用户提出系统验收申请，并完成准备工作，如制订系统验收计划。

10.1.6 系统验收

系统验收包括组织、完成新系统的验收工作，在协助甲方用户撰写系统验收报告。系统验收以后便开始实际运行，提供系统运行过程中的日常维护与技术支持工作。

10.2 软件维护概述

软件维护是软件生命周期的最后一个阶段，是对原有系统的一种修改,基本任务是保证软件在一个相当长的时期内能够正常运行。由于软件在使用过程中需要不断地发现和排除错误，以及适应新的要求，所以软件工程的主要目的就是提高软件的可维护性,减少软件维护所需要的工作量，降低维护成本。

10.2.1 软件维护的类型

国标GB/T11457-95对软件维护给出如下定义。

• 在一个软件产品交付使用后对其进行修改，以纠正故障。
• 在一个软件产品交付使用后对其进行修改，以纠正故障、改进其性能和其他属性，或使产品适应改变了的环境。

软件维护根据要求进行的维护原因不同，可以分为改正性维护、适应性维护、完善性维护和预防性维护四类。

(1) 改正性维护

改正性维护是一种限制在原需求说明书的范围之内，修改软件中的缺陷或者不足的过程。因为软件开发时的测试不彻底、不完全，软件必然会有一些隐藏缺陷遗留到运行阶段,而这些隐藏的缺陷在某些特定的环境下就会暴露出来。

(2) 适应性维护

计算机科学技术领域的各个方面都在迅速进步，大约每过36个月就有新一代的硬件出现，而应用软件的使用寿命却很长，远远长于最初开发这个软件时的运行环境的寿命。

因此，适应性维护是为了使软件适应操作环境变化而进行的修改软件的活动，是既不可避免又经常要进行的维护活动。

操作环境的变化包括外部环境（新的硬件、软件配置）和数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质等）。适应性维护可以是修改原有在DOS操作系统中运行的程序，使之能在Windows操作系统中运行；可以是修改两个程序，使它们能够使用相同的记录结构；可以是修改程序，使它能够适用于另一种终端设备。

(3) 完善性维护

完善性维护是为了改善、加强系统的功能和性能，改进加工的效率，提高软件的可维护性，而对软件进行的维护活动。完善性维护可以认为是一种有计划进行的软件“再开发”的活动。
实践表明，在所有维护活动中，完善性维护所占大约50%以上的工作量，比重是最大的。

(4) 预防性维护

预防性维护需要根据现有的信息对未来的环境变化进行预测，再根据预测的结果采取相应的解决措施，是为了提高软件未来的可维护性、可靠性等质量目标，为以后进一步改进软件奠定良好的基础。

10.2.2 软件维护存在的问题

1. 理解程序困难。 源代码在编写过程中，如果没有严格遵守开发规范、没有添加注释、缺失说明文档等，使得他人在维护过程中很难读懂程序.
2. 难以获得帮助。 在对软件进行维护时，不是开发人员进行维护，而是专门的维护人员进行维护。由于软件的维护时期较长，软件行业人员流动性较大，可能遇到问题时，开发人员已经离开该岗位或者投入到其他项目的开发当中了。因此，在维护时无法依靠开发人员提供软件说明。
3. 文档管理混乱。 在对软件进行维护时，会遇到文档不全或者没有合格的对应文档的情况。在软件开发过程中，经常会出现修改了程序却没有修改相关文档、修改了某个文档却没有修改与该文档相关的文档等现象。文档书写不规范、难以理解的情况也时有发生。
4. 软件设计有缺陷。 很多软件在开发时并没有考虑到可维护性、可扩展性。在分析设计阶段也没有采用具有前瞻性的设计和技术，没有采用功能独立的模块化设计方法，导致软件可能存在维护缺陷，使得软件难以理解和维护，在维护过程中也很容易引入新的错误。
5. 版本管理混乱。 很多软件发行过多个版本或者做过多次升级，并没有做到很好的版本管理工作，使得追踪软件的演化变得非常困难，甚至不可能。

10.2.3 软件维护的风险

(1) 维护费用高昂

随着软件规模的扩“大和软件复杂程度的增加，软件维护的工作越来越困难，费用也越来越昂贵。开发一个上线后就完全不需要改变的软件是不可能的。在过去的几十年里，软件维护的费用不断上升。

维护费用只是软件维护中的显性代价，除了费用，还有一些隐形代价也不可忽视，例如，软件维护占用太多资源而耽误了开发良机；维护过程中软件的改动引入了潜在缺陷，降低了软件质量；看起来合理的有关错误或修改的要求不能及时满足用户时引起用户的不满等。

维护的工作可以划分为生产型活动（分析评价、修改设计、编写程序代码等）和非生产型活动（程序代码功能理解、数据结构解释、接口特点和性能界限分析等）。

在软件维护中，软件维护的工作量影响软件成本的大小。而影响维护工作量的因素主要有以下6种：

1. 系统的规模大小。系统规模越大，功能就越复杂，软件维护的工作量也随之增大。
2. 程序设计语言。使用功能强大的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。
3. 系统使用时间。使用时间越长，所进行的修改就越多，而多次的修改可能造成系统结构混乱。由于维护人员经常更换，程序的可理解性越来越差，加之系统开发时大多文档不全，或在长期的维护过程中文档在许多地方与程序不一致，从而使维护变得非常困难。
4. 数据库技术的应用。使用数据库，可以简单有效地存储、管理系统数据，还可以减少生成用户报表应用软件的维护工作量。
5. 先进的软件开发技术。在软件开发过程中，如果采用先进的分析设计技术和程序设计技术，如面向对象技术、复用技术等，可以减少大量的维护工作量。
6. 其他因素。如应用的类型、数学模型、任务的难度、开关与标记、正 嵌套深度、索引或下标数等，对维护的工作量也有影响。

(2) 维护的副作用

软件维护主要有三类副作用：修改代码的副作用、修改数据的副作用和修改文档的副作用。

• 修改代码的副作用。对于代码的修改，小到一个语句都有可能导致灾难性的结果。一般在回归测试中对修改代码的副作用造成的软件故障进行查找和改正。
• 修改数据的副作用。修改数据的副作用是指数据结构被改动时有新的错误产生的现象。当数据结构发生变化时，新的数据结构可能会不适应原有的软件设计，从而导致错误的产生。
• 修改文档的副作用。在软件产品的内容更改之后没有对文档进行相应的更新，则会产生修改文档的副作用。

在对数据流、体系结构设计、模块过程或者任何其他有关特性进行修改时，必须对其支持的技术文档进行更新。如果没有及时进行更新，则在以后的维护工作中，可能因为阅读了老旧的技术文档而对软件特性做出不正确的评价，产生修改文档的副作用。
对文档进行及时更新及进行有效的回归测试可以减少软件维护的副作用。

10.2.4 软件维护的过程

软件维护的过程首先需要建立维护机构，然后确定维护报告的内容并进行相应的维护工作，记录维护流程、保存记录，最后确定评估及复审标准。

(1) 建立维护机构

通常，标准的维护机构由维护管理员、系统管理员、维护决策机构、配置管理员和维护人员构成。在维护开始前明确维护责任可以大大减少维护过程中可能出现的混乱现象。

(2) 用户提交维护申请报告

软件的维护要求应按照标准规范提出。维护申请报告是由用户填写的外部文件，通常包含错误的说明（输入数据、错误清单等内容），这是计划维护活动的基础，后续维护工作的关键。

(3)维护人员提交软件修改报告并实施相应的维护工作

经维护人员与用户进行反复协商，明确错误的情况及对业务的影响等，由维护管理员确认维护的类型，由软件组织内部制定出软件修改报告。

软件修改报告通常包含此次维护需求的类型、维护申请的优先级、完成申请表中所提出的需要的工作量及成本、预计修改后产生的影响等内容。软件修改报告提交给维护决策机构审查批准后进行维护工作的安排。

• 对于非改正性维护，应首先判断维护类型；对于适应性维护，需按照评估后的优先级放入队列；
• 对于完善性维护，需要考虑是否采取行动，若接受申请，则按照评估后的优先级放入队列，若拒绝申请，则通知请求者并说明原因；
• 对于工作安排队列中的任务，由修改负责人依次从队列中取出任务，按照软件维护的过程，规划、组织及实施工程。

在实施维护的过程中，需要完成以下工作：

• 修改需求规格说明书；
• 修改软件设计；
• 进行设计评审；
• 对源程序做必要的修改；
• 对源程序进行单元测试、集成测试、回归测试、确认测试；
• 进行软件配置评审。

(4)整理维护记录

在维护过程中的有效数据应收集保存，形成良好的维护文档记录，以便统计出维护性能方面的度量模型。需要记录的数据一般包括程序的标识、程序交付及安装日期、程序安装后运行的次数、运行时发生故障导致运行失败的次数、进行程序修改的次数内容及日期等。根据提供的定量数据，可以对软件项目的开发技术、维护工作计划、资源分配及其他许多方面做出正确的判断。

(5)对维护工作进行评估

维护工作完成之后，对维护情况进行评审，并且对相应问题进行总结。维护评审可以为软件机构提供重要的反馈信息。

10.2.5 软件的可维护性

软件的可维护性决定了软件生命周期的长短。

软件是否能够被理解、改正、适应和完善新的环境的难易程度，决定了软件可维护性的好坏。因此，软件的可维护性与软件的可理解性、可测试性和可修改性3个因素密切相关。

软件可维护性可定性地定义为：维护人员理解、改正、改动和改进这个软件的难易程度。

(1) 用于衡量可维护性的软件特性

在衡量软件可维护性时通常用这7个质量特性来衡量：可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。

对于不同类型的维护，这7种特性的侧重点也不相同。要将这些质量要求贯彻到各开发阶段的各步骤中。软件的可维护性是产品投入运行以前各阶段针对上述质量特性要求进行开发的最终结果。

(2) 如何提高软件的可维护性

提高软件的可维护性的技术途径通常从以下几个方面进行。
(2-1) 建立完整的文档管理体系
软件的文档包括用户文档和系统文档两类:

• 用户文档主要描述系统各个功能和使用的方法；
• 系统文档主要描述系统设计、实现和测试等方面的内容。

(2-2) 明确质量标准，设定不同侧重点
在软件的需求分析阶段就明确软件质量目标，确定标准，保证软件质量。软件的质量特性有些是相互促进的，有些是相互抵触的。针对不同软件设定不同的侧重点。例如，信息管理系统更强调可使用性和可修改性。

(2-3) 注重软件质量保证审查
在软件开发的每个阶段工作完成之前，都要进行严格的评审。进行软件质量保证审查来检测软件在开发和维护过程中发生的质量变化，用以提高软件的可维护性。若检测出问题,则可以及时纠正，控制了软件维护成本，延长软件系统的有效生命周期。

(2-4) 采用易于维护的技术和工具
采用易于维护的技术和工具进行软件开发，有利于提高软件的可维护性。
例如，采用面向对象、软件复用等先进的开发技术；采用模块化进行开发，减少模块间的相互影响；采用结构化进行程序设计；选择可维护性高的程序设计语言等。

10.3 软件进化概述

软件的开发不会因为系统的交付而停止，它贯穿系统的整个生命周期。软件在开发完成后用户使用期间，由于业务变更和用户期待的改变，使得对现有系统出现了新的需求，对软件进行修改也是不可避免的。
这些对系统的修改、提升性能或其他非功能特性，都意味着系统在交付以后是在不断进化以满足变更的需求。软件开发与进化是一个集成、完整、增量式的过程。

10.3.1 进化过程

软件进化过程在相当程度上依赖于所维护的软件的不同类型和参与开发过程的机构和人。
在所有机构中，系统变更建议都是系统进化的动力。这些变更建议可能包括在发布的颜本中还没有实现的已有需求、新的需求请求、系统所有者的补丁要求和来自系统开发团队的改进软件的新想法和建议。变更识别的过程和系统进化是循环和持续的，并且贯穿于系统的生命周期。

变更实现的过程可以看作是一个开发过程的迭代过程，在此迭代过程中完成对系统修改的版本的设计、实现和测试。

在进化过程中，要详细分析需求，因此往往在变更分析的早期阶段原本不明显的一些变更要求逐渐浮现出来。
这意味着所提出来的变更有可能要修改，并且在实现前需要进一步地与客户讨论。

10.3.2 遗留系统

遗留系统是过去开发的计算机系统，通常使用了目前已经过时或不再使用的技术。这些系统的开发可能在生命周期中一直持续，通过变更来适应新需求、新运行平台等方面的变化。
遗留系统不仅包括硬件和软件，还包括遗留的业务过程和步骤。对这类系统的一部分进行变更将不可避免地导致其他组成部分的变更。

(1) 遗留系统的结构

遗留系统不仅仅是旧的软件系统，它包含社会和技术双重因素在内的基于计算机的系统，包括软件、硬件、数据和业务过程。

• 硬件。在许多情况下，遗留系统是为大型机硬件设计的，这些大型机现在已经不能使用，或是因为维护费用太高，或是因为与当前的IT购买政策不符。
• 支持软件。遗留系统可能依赖于操作系统、由硬件制造商提供的实用程序、系统开发用的编译器等一系列软件。
• 应用软件。提供业务服务的应用系统，通常由多个程序组成，这些程序之间往往是独立的，在不同时间段上开发出来的。
• 应用数据。由应用系统处理的数据。
• 业务过程。为达到一定的业务目的而使用的过程。
• 业务策略和规则。用户规定业务应该怎样完成及对业务的约束。

(2) 遗留系统的进化策略

遗留软件的维护和升级通常会受到预算、期限等多种因素的约束，因此开发人员需要对遗留软件系统的实际情况进行准确的评价，然后选择最合适的进化策略。

遗留系统的进化策略有如下几个:

1. 完全放弃该软件。
2. 不改变该软件系统并继续进行常规的维护。
3. 对软件系统实施再工程以提高软件的可维护性。
4. 用新系统替换遗留软件系统的全部或其中一部分。

遗留软件系统的评价：

• 低业务价值，低系统质量。保持这些系统继续运转的费用很高，回报率很低，为抛弃的候选对象。
• 高业务价值，低系统质量。这些系统正在为业务做出重要贡献，不能抛弃，但是运行成本很高，需要以合适的系统替代或者进化。
• 低业务价值，高系统质量。这些系统对业务的贡献很小，但是维护费用较低，可以继续进行一般的系统维护，也可以抛弃。
• 高业务价值，高系统质量。这种系统必须保持云栈，进行常规维护。

系统质量的评价从技术因素和环境因素两个方面进行。
从技术角度来评价一个软件系统，需要同时考虑应用软件本身及软件运行的环境。
环境包括硬件和所有相关的支撑软件,如对系统维护所需要的编译器等。通常，环境评价考虑的因素包括厂商稳定性、失效率、已使用时间、性能、保障需求、维护成本及互操作性等。技术评价考虑的因素包括可理解性、文档、数据、性能、程序设计语言、配置管理、测试数据及人员技术能力等。

10.3.3 软件再工程

软件再工程是指对既存对象系统进行调查，并将其中非可重用构件改造为新形式代码的开发过程。软件再工程的主要特点之一是最大限度地重用既存系统中的各种资源。

软件再工程可以通过对遗留系统进行全部或者部分的改造，来提高已有软件的质量或者商业竞争力。软件再工程开始于已有的系统，通过改善原始系统的结构和产生新的系统文档，使得系统的可维护性得到提高。

实施软件再工程可以减少重新开发软件的风险，降低开发软件的成本。软件再工程的成本比重新进行软件开发要小得多。当一个系统有很高的业务价值，同时需要很高的维护费用时，对系统实施再工程就是一个较好的办法。

(1) 软件再工程的过程

典型的软件再工程过程模型定义了六类活动：库存目录分析、文档重构、逆向工程、代码重构、数据重构以及正向工程。

(1-1) 库存目录分析
库存目录分析包含关于每个应用系统的基本信息，如应用系统的名称、构建日期、已进行实质性修改次数、过去 18个月报告的错误、用户数量、文档质量、预期寿命、在未来 36个月内的预期修改次数、业务重要程度等。

库存目录分析阶段，应对每一个现存软件系统采集上述信息并通过局部重要标准对其排序，根据优先级不同选出再工程的候选软件，进而合理分配资源。对于预定将使用多年的程序、当前正在成功使用的程序和在最近的将来可能要做重大修改或增强的程序，可能成为预防性维护的对象。

(1-2) 文档重构
文档重构是对文档进行重建。软件老化的最大问题便是缺乏有效文档。 由于文档重构是一件非常耗时的工作，不可能为数百个程序都重新建立文档，因此，在文档重构的过程中，针对不同情况，文档重建的处理方法也是不同的。

若一个程序是相对稳定的,而且可能不会再经历什么变化，那么就保持现状，只针对系统中当前正在修改的部分建立完整文档，便于今后维护。如果某应用系统是完成业务工作的关键，而且必须重构全部文档,则应设法把文档工作减少到必需的最小量。

(1-3) 逆向工程
逆向工程是一种产品设计技术再现过程，即对一项目标产品进行逆向分析及研究，从而演绎并得出该产品的处理流程、组织结构、功能特性及技术规格等设计要素。 以制作出功能相近，但又不完全一样的产品。
逆向工程通常针对自己公司多年前的产品。期望从旧的产品中提取系统设计、需求说明等有价值的信息。逆向工程的关键在于从详细的源代码实现中抽取出抽象说明的能力。对于实时系统，由于须繁的性能优化，实现与设计之间的对应关系比较松散，设计信息不易抽取。

逆向工程导出的信息可以分为实现级、结构级、功能级及领域级4个抽象层次。

• 实现级包括程序的抽象语法树、符号表等信息；
• 结构级包括反映程序分量之间相互依赖关系的信息，如调用图、结构图等；
• 功能级包括反映程序段功能及程序段之间关系的信息；
• 领域级包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。

对于一项具体的维护任务，般不必导出所有抽象级别上的信息，如代码重构任务，只需获得实现级信息即可。

逆向工程根据源程序的类别不同，可以分为对用户界面的逆向工程、对数据的逆向工程和对理解的逆向工程。

• 对用户界面的逆向工程。现代软件一般都拥有华丽的界面，当准备对旧的软件进行用户界面的逆向工程时，必须先理解旧软件的用户界面，并且刻画出界面的结构和行为。
• 对数据的逆向工程。由于程序中存在许多不同种类的数据，如内部的数据结构、底层的数据库和外部的文件。其中，对内部的数据结构的逆向工程可以通过检查程序代码及变量来完成；而对于数据库结构的重构可以通过建立一个初始的对象模型、确定候选键、精化实验性的类、定义一般化，以及发现关联来完成。
• 对理解的逆向工程。为了去理解过程的抽象，代码的分析必须在以下不同的层次进行：系统、程序、部件、模式和语句。对于大型系统，逆向工程通常用半自动化的方法来完成。

(1-4) 代码重构
代码重构是软件再工程最常见的活动，目标是重构代码生成质量更高的程序。通常，重构并不修改软件的整个体系结构，仅关注个体模块的内部设计细节和局部数据结构，用新生成的易于理解和维护的代码替代原有的代码。

通常，对于具有比较完整、合理的体系结构，但是个体模块的编码方式比较难以理解、测试和维护的程序，可以重构可疑模块的代码。

1. 代码重构活动首先用重构工具分析代码，标注出与结构化程序设计概念相违背的部分；
2. 其次重构有问题的代码；
3. 最后复审和测试生成的重构代码（以保证没有引入异常）并更新代码文档。

(1-5) 数据重构
数据重构是对数据结构进行重新设计，适应新的处理要求。 代码的修改往往会涉及数据，并且随着需求的发展，原有的数据可能已经无法满足新的处理要求，因此需要重新设计数据结构，即对数据进行再工程。

数据重构是一种全范围的再工程活动，通常，数据重构始于逆向工程活动，分解当前使用的数据体系结构，必要时定义数据模型、标识数据对象和属性，并从软件质量的角度复审现存的数据结构。

(1-6) 正向工程
正向工程从现存软件中提取设计信息并用以修改或重建现存系统以提高系统整体质量。 当一个正常运行的软件系统需要进行结构化翻新时，就可对其实施正向工程。通常，被再工程的软件不仅重新实现现有系统的功能，而且加入了新功能和提高了整体性能。

(2) 软件再工程的方法

软件再工程的方法有再分析、再编码和再测试3种。

• 再分析。再分析主要是对既存系统进行分析调查，包括系统的规模、体系结构、外部功能、内部算法、复杂度等。其主要目的是寻找可重用的对象和重用策略，最终形成再工程设计书。
• 再编码。再编码主要是根据再工程设计书，对代码做进一步分析，产生编码设计书。
  编码设计书类似于详细设计书。
• 再测试。再测试阶段，通过重用原有的测试用例及运行结果，来降低再工程成本。对于可重用的独立性较强的局部系统，还可以免除测试。这也是重用技术被再工程高度评价的重要原因之一。

(3) 软件再工程的优点

• 软件再工程可以帮助软件机构降低软件演化的风险。
• 软件再工程可以帮助机构补偿软件投资。
• 软件再工程可以使得软件易于进一步变革。
• 软件再工程是推动自动软件维护发展的动力。
• 软件再工程有着广阔的市场。

(4) 软件再工程的问题与前景

• 需要自动化工具的支持。有可以标识、分析并提出源代码中的信息的工具，但它们不能重构、获取，以及表达、设计、抽象这些没有直接表示在源代码中的信息。
• 源代码中没有包含原设计的太多信息，缺失的信息必须从推论中重构。逆向工程的尝试最好是容易理解的、稳定领域中出现的信息系统。
• 在其他领域，只有用代码中隐含的信息、现有的设计文档、人员的经验及问题域的全面了解，才能进行设计恢复。
• 设计符号的形式和领域模型的引入，将扩展我们理解与维护软件时用到的信息。期望转换技术的提高，可支持更多的应用领域并提高再工程的自动化。

十一、软件工程标准与文档

11.1 软件工程标准

11.1.1 国际标准

国际标准是指由国际联合机构制定和公布，提供各国参考的标准。

国际标准化组织有着广泛的代表性和权威性，它所公布的标准也有较大的影响。20世纪60年代初，该机构建立了“计算机与信息处理技术委员会”（简称IOS/TC 97)，专门负责与计算机有关的标准化工作。

11.1.2 国家标准

国家标准是由政府或国家级的机构制定或批准，适用于全国范围的标准。 比较常见的国家标准如下。

• 美国国家标准协会(American National Standards Institute，ANSD)批准的若干个软件工程标准。
• BSI(British Standards Institution）——英国国家标准协会。
• JS(Japanese Industrial Standards)——日本工业标准。
• 中华人民共和国国家标准化管理委员会是我国的最高标准化机构，它所公布实施的标准简称为“国标(GB）”。

11.1.3行业标准

行业标准是由行业机构、学术团体或国防机构制定，并适用于某个业务领域的标准。 典型的该类机构如电气和电子工程师协会(IEEE)。

• GJB——中华人民共和国国家军用标准。这是由我国国防科学技术工业委员会批准，适合于国防部门和军队使用的标准。例如，1988年发布实施的《GJB473-1988军用软件开发规范》。
• DOD-STD(Department of Defense-Standards)—美国国防部标准。适用于美国国防部门。

11.1.4 企业标准

由于软件工程工作的需要，一些大型企业和公司制定了适用于本部门的规范。例如，美国IBM公司通用产品部在1984年制定的《程序设计开发指南》，供该公司内部使用。

11.1.5 项目规范

由某一科研生产项目组织制定，且为该项任务专用的软件工程规范。例如，计算机集成制造系统的软件工程规范。

11.2 软件工程国家标准

11.2.1 基础标准

• GB/T 11457-1995 软件工程术语。
  该标准定义了软件工程领域中通用的术语，适用于软件开发、使用维护、科研、教学和出版等方面。
• GB/T 1526-1989 信息处理一文件编制符号及约定。
  该标准规定了信息处理文档编制中使用的各种符号，并给出数据流图、程序流程图、系统流程图、程序网络图和系统资源图中使用的符号约定。
• GB/T 15538-1995 软件工程标准分类法。
  该标准提供了对软件工程标准进行分类的形式和内容，并解释了各种类型的软件工程标准。
• GB/T13502-1992 信息处理一程序构造及表示的约定。
  该标准定义了程序的构造图形表示，用于构造一个良好的程序。
• GB/T 15535-1995 信息处理一单命中判定表规范。
  单命中判定表指其任意一组条件只符合一条规则的判定表。该标准定义了单命中判定表的基本格式和相关定义，并推荐了编制和使用该判定表的约定。

11.2.2 开发标准

• GB/T 15853-1995 软件支持环境。
  该标准规定了软件支持环境的基本要求，软件开发支持环境的内容和实现方法，以及对软件生存期支持软件能力的具体要求，适用于软件支持环境的设计、建立、管理和评价。
• GB/T8566-1995 信息技术—软件生命周期过程。
  该标准规定了在获取、供应、开发、操作、维护软件过程中，要实施的过程、活动和任务，为用户提供了一个公共框架。
• GB/T14079-1993 软件维护指南。
  该标准描述软件维护的内容和类型、维护过程及维护的控制和改进。
• GB/T15697-1995 信息处理一按记录组处理顺序文卷的程序流程。
  该标准描述了两个可供选择的通用过程：检验适当层次终止后的控制前端条件、检验适当层次初始化前的控制前端条件。这两个通用过程用于处理按记录组逻辑组织的顺序文卷的任何程序。

11.2.3 文档标准

• GB/T8567-2006 计算机软件产品开发文件标志指南。
  该标准代替了GB/T8567-1988，规定了软件需求规格说明、软件测试文件、软件质量保证计划与软件配置管理计划等文档。
• GB/T9385-2008 计算机软件需求说明编制指南。
  该标准代替了GB/T9385-1988，为软件需求实践提供了一个规范化方法，适用于编写软件需求规格说明书，描述了软件需求说明书所必须包含的内容和质量。
• GB/T9386-2008 计算机软件测试文件编制规范。
  该标准代替了GB/T9386-1988，规定了一组软件测试文档，可以作为对测试过程完备性的对照检查表。
• GB/T 16680-1996 软件文档管理指南。
  该标准为软件开发负有责任的管理者提供软件文档的管理指南，协作管理者产生有效的文档。

11.2.4 管理标准

• GB/T12504-1990 计算机软件质量保证计划规范。
  该标准规定了在软件质量保证计划时应遵循的统一基本要求，适用于软件质量保证计划的定制工作。
• GB/T 16260-1996 信息技术一软件产品评价质量特性及其使用标准。
  该标准确定和评价了软件产品质量及开发过程质量。
• GB/T 12505-1990 计算机软件配置管理计划规范。
  该标准规定了在制定软件配置管理计划时应遵循的统一的基本要求。

11.3 软件工程文档的编制

11.3.1 软件的生产周期和各种文档的编写

(1) 项目组各类人员与对应文档

(2) 软件生存周期的的阶段

(2-1) 可行性与计划研究阶段
在可行性分析(研究)与计划阶段内，要确定该软件的开发目标和总的要求，进行可行性分析、投资一收益分析，制订开发计划，并完成可行性分析报告、开发计划等文档。

(2-2) 需求分析阶段
在需求分析阶段，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，以及对文档编制的要求，作为本阶段工作的结果。

一般来说,软件需求规格说明（也称为软件需求说明、软件规格说明)、数据要求说明和初步的用户手册应该编写出来。

(2-3) 设计阶段
在设计阶段，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计。
这些设计包括该软件的结构和模块或 CSCI(计算机软件配置项)的划分，功能的分配，以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文档包括结构设计说明、详细设计说明和测试计划初稿。

(2-4) 实现阶段
在实现阶段，要完成源程序的编码、编译（或汇编）和排错调试，得到无语法错误的程序清单。

• 开始编写进度日报、周报和月报（是否要有日报或周报，取决于项目的重要性和规模)；
• 并且要完成用户手册、操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。

(2-5) 测试阶段
在测试阶段，该程序将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。
作为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。

在整个开发过程中(即前五个阶段中)，开发团队要按月编写开发进度月报。

(2-6) 运行与维护阶段
在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。

11.3.2 文档编制中的考虑因素

(1) 文档的读者

每一种文档都具有特定的读者。
这些读者包括：个人或小组，软件开发单位的成员或社会上的公众，从事软件工作的技术人员、管理人员或领导干部。
他们期待着使用这些文档的内容来进行工作，如设计、编写程序、测试、使用、维护或进行计划管理。

因此，这些文档的作者必须了解自己的读者，文档的编写必须注意适应特定读者的水平、特点和要求。

(2) 重复性

本标准列出的文档编制规范的内容要求中显然存在某些重复，较明显的重复有两类：

• 第一类是引言。引言是每一种文档都要包含的内容，以向读者提供总的梗概。
• -第二类明显的重复是各种文档中的说明部分，如对功能性能的说明；对输入、输出的描述；系统中包含的设备等。

这是为了方便每种文档各自的读者，每种文档应该自成体系，尽量避免读一种文档时又不得不去参考另一种文档。

当然，在每一种文档中，有关引言、说明等同其他文档相重复的部分，在行文上、所用术语上、详细程度上要有一些差别，以适应各种文档的不同读者的需要。

(3) 灵活性

(3-1) 应编制的文档种类
一般来说，当项目的规模、复杂性和失败风险增大时，文档编制的范围、管理手续和详细程度将随之增加，反之，则可适当减少。

为了恰当地掌握这种灵活性，本标准要求贯彻分工负责的原则，这意味着：

• 一个软件开发单位的领导机构应该根据本单位经营承包的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定，主要是：在不同的条件下，应该形成哪些文档、这些文档的详细程度及该开发单位的每一个项目负责人，必须认真执行这个实施规定。
• 对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划（可以包含在软件开发计划中），包括如下内容。：
• • 应该编制哪几种文档，详细程度如何？
• • 各个文档的编制负责人和进度要求。
• • 审查、批准的负责人和时间进度安排。
• • 在开发时间内，各文档的维护、修改和管理的负责人，以及批准手续。
• • 每项工作必须落实到人。这个文件编制计划是整个开发计划的重要组成部分。
• • 有关的设计人员则必须严格执行这个文档编制计划。

(3-2) 文档的详细程度
从同一份提纲起草的文件的篇幅大小往往不同，可以少到几页，也可以长达几百页。对于这种差别，本标准是允许的。此详细程度取决于任务的规模、复杂性和项目负责人对该软件的开发过程及运行环境所需要的详细程度的判断。

(3-3) 文档的扩展

• 项目开发计划可能包括质量保证计划、配置管理计划、用户培训计划、安装实施计划。
• 系统设计说明可分写成系统设计说明、子系统设计说明。
• 程序设计说明可分写成程序设计说明、接口设计说明、版本说明。
• 操作手册可分写成操作手册、安装实施过程。
• 测试计划可分写成测试计划、测试设计说明、测试规程、测试用例。
• 测试分析报告可分写成综合测试报告、验收测试报告。
• 项目开发总结报告亦可分写成项目开发总结报告和资源环境统计。

(3-4) 章、条的扩张与缩并
在软件文档中，一般宜使用本标准提供的章、条标题。但所有的条都可以扩展，可以进一步细分，以适应实际需要。反之，如果章条中的有些细节并非必需，则也可以根据实际情况缩并，此时章条的编号应相应地变更。

(3-5) 程序设计的表现形式
本标准对于程序的设计表现形式并未做出规定或限制，可以使用流程图、判定表的形式，也可以使用其他表现形式，如程序设计语言（PDL)、问题分析图(PALb）等。

(3-6) 文档的表现形式
本标准对于文档的表现形式亦未做出规定或限制，可以使用自然语言，也可以使用形式化语言，还可以使用各种图、表。

(3-7) 文档的其他种类
当本标准中规定的文档种类尚不能满足某些应用部门的特殊需要时，可以建立一些特殊的文档种类要求，如软件质量保证计划、软件配置管理计划等，这些要求可以包含在本单位的文件编制实施规定中。

11.4 软件工程文档标准

软件工程文档标准 GB/T 8567-2006

—— writing by Pan Qifan(潘琦藩) ——