第一章软件工程研究的主要内容：为了在有限的资金、资源和时间条件下开发满足客户要求的高质量软件，需要研究与软件开发和管理相关的模型、方法、技术等。

在《计算机科学技术百科全书》中，对计算机软件作出如下定义：计算机软件指计算机系统中的程序及其文档。

程序是计算任务的处理对象和处理规则的描述。

任何以计算机为处理工具的任务都是计算任务。

处理对象是数据或信息。

处理规则一般指处理的动作和步骤。

文档是为了便于了解程序所需的阐述性资料。

软件工程的定义：⑴ＩＥＥＥ在软件工程术语汇编中的定义：①软件工程是将系统化的的方法用于软件的开发、运行和维护，即将工程化应用于软件；②在①中所述方法的研究⑵软件工程是应用计算机科学等原理，开发软件的工程。

软件工程借鉴传统工程的原则、方法，以提高质量、降低成本为目的。

其中，计算机科学、数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源等管理。

软件工程的框架：目标，过程和原则软件工程目标是指生产具有正确性、可用性、和开销合宜的产品。

正确性指软件产品达到预期功能的程度。

可用性指软件基本结构、实现及文档为用户可用的程度。

开销合宜指软件开发、运行的整个开销满足用户要求的程度。

软件工程原则包括围绕工程设计、工程支付和工程管理所提出的以下4条基本原则(1)选取适宜的开发模型(2)采用合适的设计方法(3)提供高质量的工程支撑(4)重视软件工程的管理软件生存周期是指软件产品或软件系统从产生、投入使用到被淘汰的全过程。

软件生存周期分为6个阶段：计算机系统工程、需求分析、设计、编码、测试、运行和维护软件过程是生产一个最终满足需求且达到工程目标的软件产品所需的步骤。

软件过程是软件生存周期中的一系列相关的过程。

过程是活动的集合，活动是任务的集合。

软件过程有3层含义：一是个体含义，即指软件产品或系统在生存周期中的某一类活动的集合；二是整体含义，即指软件产品或系统在所有上述含义下的软件过程的总体；三是工程含义，即指解决软件过程的工程，应用软件工程的原则、方法来构造软件过程模型、并结合软件产品的具体要求进行实例化，以及在用户环境，并结合软件产品的具体要求进行实例化，以及在用户环境下运作，以此进一步提高软件生产率，降低成本。

软件过程模型也称软件开发模型，是软件开发全部过程、活动和任务的结构框架。

典型的软件过程模型有：瀑布模型、演化模型（如增量模型、原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式方法模型等。

瀑布模型是1970年由W.Royce提出的，它给出了软件生存周期活动的固定顺序，上一阶段的活动完成后向下一阶段的活动过渡，最终得到所开发的软件产品。

其特征是：接受上一阶段活动的结果作为本阶段活动的输入依据上一阶段活动的结果实施本阶段应完成的活动对本阶段的活动进行评审将本阶段活动的结果作为输出，传递给下一阶段瀑布模型也逐渐暴露出它的不足（1）不少软件的需求存在着不确定性，（2）如果发现不满足客户需求的问题，那么修改软件的代价是巨大的演化模型，是从构造初始的原型出发，逐步将其演化成最终软件产品的过程。

演化模型适用于对软件需求缺乏准确认识的情况。

典型的演化模型有：增量模型、原型模型、螺旋模型增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一个版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。

增量模型融合了瀑布模型的基本成分和演化模型的迭代特征，强调每一次增量都发布一个可运行的产品。

特征：（1）适用于需求经常发生变化的软件开发（2）在市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品，此时也适宜用增量模型进行开发（3）能有计划的管理技术风险原型方法的目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模并构建原型根据原型使用的目的不同，可以分为：探索型、实验型、演化型原型使用策略：废弃策略、追加策略螺旋模型将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来，不仅体现了这两种模型的优点，而且还增加了风险分析其有四个方面的任务：制定计划、风险分析、工程实施、客户评估一种基于构件的开发模型包括两个部分：领域工程和应用系统工程领域工程的目的：构建领域模型、领域基准体系结构和可复用构件库应用系统工程的目的：使用可复用构件组装应用系统基于构件的开发模型的作用（优点）：提高软件生产率、提高软件质量、降低成本、提早上市时间敏捷（Agile）开发的4个价值观：（1）个人和交互高于过程和工具（2）可运行软件高于详尽的文档（3）与客户协作高于合同谈判（4）对变更及时做出反应高于遵循计划计算机辅助软件工程（computer aided sofrware engineering,CASE）是指使用计算机及相关的软件工具辅助软件开发、维护、管理等过程中各项活动的实施，以确保这些活动能高效率、高质量地进行CASE研究和实践的重点集中在CASE工具和软件开发两个方面软件开发环境（software development environment）是支持软件产品开发的软件系统第二章业务过程工程的目标是：定义一个能有效地利用信息进行业务活动的体系结构。

语境中分析和设计3种体系结构：数据体系结构、应用体系结构和技术基础设施。

产品工程的目标：将客户期望的一组已定义的能力转换成工作产品。

体系结构包含4种不同的系统元素：软件、硬件、数据（和数据库）和人员。

计算机系统工程目的是分析基于计算机的系统的功能、性能等要求，并把它们分配到基于计算机系统的各个系统元素中，确定它们的约束条件和接口。

可行性研究分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。

可行性分析包括：机会选择、初步可研究性分析、详细可研究性分析第三章需求工程是应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题，评估可行性，协商合理的解决方案、无歧义地规约方案、确认规约以及将规约转换到可运行的系统时的管理要求，需求工程通过合适的工具和符号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持可将需求工程分为6个阶段：需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理在需求获取阶段出现的问题：（1）用户提出的要求超出的要求软件系统可以实现的范围或实现能力(2)不同的用户提出了相互冲突的需求软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望创建用况模型的主要步骤如下：（1）确定谁会直接使用该系统，即执行者（2）选取其中一个执行者（3）定义该执行者希望系统做什么，执行者希望系统所做的第件事将成为一个用况（4）对每件事来说，何时执行者会使用系统，通常会发生什么，这就是腹部的基本过程（5）描述该用况的基本过程需求分析原则：必须能够表示和理解问题的信息域必须能够定义软件将完成的功能必须能够表示软件的行为（作为外部事件的结果）必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节分析过程应该从要素信息转向细节信息问题分析的目的是要能心层次化的方式对问题进行分解和不断细化常用的分析方法有以下几种：面向数据流的结构化分析方法（SA）面向数据结构的分析方法面向对象的分析方法（OOA）软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求需求验证的目的是要检验需求是否能够反映用户的意愿第四章软件需求分析解决“做什么”的问题，软件设计过程则解决“怎么做”的问题。

软件设计主要包含两个阶段：软件体系结构设计阶段和部件级设计阶段软件体系结构设计将软件需求转化为数据结构和软件的系统结构。

部件级设计将软件体系结构中的结构性元素转化为软件部件的过程性描述，得到软件详细的数据结构和算法。

体系结构设计定义了软件的整体结构，由软件部件、外部可见的属性和它们之间的关系组成。

判断设计好坏的3条特征，也就是软件设计过程的目标：设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。

设计必须是可读、可理解的，使得将来易于编程、易于测试、易于维护。

设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。

软件设计的过程：制定规范、体系结构和接口设计、数据/类设计、部件级（过程）设计、编写设计文档软件的设计人员通常采用的原则：抽象与逐步求精、模块化和信息隐藏抽象是在软件设计的规模逐渐增大的情况下，控制复杂性的基本策略。

软件设计中的主要抽象手段有：过程抽象和数据抽象。

过程抽象（功能抽象）：任何一个完成明确定义功能的操作都可被使用者当作单个实体对待，尽管这个操作实际上由一系列更低级的操作来完成的。

数据抽象：定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据。

模块化：把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件。

模块化实际上是系统分解和抽象的过程。

模块：数据说明、可执行语句等程序对象的集合，是单独命名的，并且是可以通过名字来访问。

模块化的理论依据：把复杂问题分解成许多容易解决的小问题，则原来复杂的问题也就容易解决了。

采用模块化原理使程序错误通常局限在有关的模块及它们之间的接口中，模块化使软件容易调试和测试，有助于提高软件的可靠性，同时变动往往只涉及少数几个模块，从而模块化能够提高软件的可修改性；使软件结构清晰。

这样每个模块的内容不仅容易设计也容易阅读/和理解。

模块独立：模块完成独立的功能并且与其他模块的接口简单，符合信息隐蔽，模块间关联和依赖程度尽可能小。

模块的独立性：第一，功能被划分，并且接口被简化，所以具有有效模块化的软件更易于开发。

第二，由于因设计和编码修改引起的副作用受到局限，错误传播被减小，并且模块复用成为可能，所以独立的模块更易于维护和测试。

内聚cohesion是一个模块内部各个元素彼此结合的紧密程度的度量。

耦合coupling是模块之间的相对独立性（互相连接的紧密程度）的度量。

高内聚性低功能内聚顺序内聚通信内聚过程内聚时间内聚逻辑内聚巧合内聚强模块独立性弱功能单一功能分散低耦合性高非直接耦合数据耦合标记耦合控制耦合外部耦合公共耦合内容耦合强模块独立性弱软件体系结构关注系统的一个或多个结构，包含软件部件、这些部件的对外可见的性质以及它们之间的关系。

Bass提出体系结构重要的3个关键理由：方便利益相关人员的交流；有利于系统设计的前期决策；建立了一个系统的可传递的抽象常见的软件体系结构：单主机结构、客户/服务器（C/S）结构、浏览器/服务器（B/S）结构。