摘要：软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、减低软件成本。IEEE对软件工程的定义是：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。
1.1.2软件工程
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、减低软件成本。IEEE对软件工程的定义是：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。
软件工程由方法、工具和过程三个部分组成。软件工程方法是完成软件工程项目的技术手段，它支持整个软件生命周期；软件工程使用的工具是人们在开发软件的活动中智力和体力的扩展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成；软件工程中的过程贯穿于软件开发的各个环节，管理人员在软件工程过程中，要对软件开发的质量、进度、成本进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证和配置管理等。
1.结构化方法
结构化方法属于自顶向下的开发方法，其基本思想是"自顶向下，逐步求精",强调开发方法的结构合理性及所开发软件的结构合理性。结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。针对软件生存周期各个不同的阶段，它包括了结构化分析（StructuredAnalysis,SA）、结构化设计（StructuredDesign,SD）和结构化程序设计（StructuredPrograming,SP）等方法。
为保证系统开发的顺利进行，结构化方法强调遵循以下几个基本原则：
（1）面向用户的观点。在开发过程中，开发人员应该始终与用户保持联系，从调查研究入手，充分理解用户的信息需求和业务活动，不断地让用户了解工作的进展情况，校准工作方向。（2）严格区分工作阶段，每个阶段有明确的任务和应得的成果。（3）按照系统的观点，自顶向下地完成系统的开发工作。（4）充分考虑变化的情况。在系统设计中，把系统的可变更性放在首位。（5）工作成果文献化、文档化。
结构化方法是目前最成熟、应用较广泛的一种工程化方法。当然，这种方法也有不足和局限性，主要体现在以下几个方面：
这些问题在应用中有的已经解决，同时也产生了其他一些方法，例如原型法、面向对象方法等。
2.软件开发模型
对于开发模型知识点，要掌握软件生命周期的概念、各种开发模型的特点和应用场合。主要考查的开发模型有瀑布模型、增量模型、螺旋模型、喷泉模型、迭代模型、V模型、敏捷方法和统一过程等。
（1）瀑布模型。瀑布模型也称为生命周期法，是结构化方法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型是最早出现的软件开发模型，它提供了软件开发的基本框架。瀑布模型的本质是"一次通过",即每个活动只做一次，最后得到软件产品，也称做"线性顺序模型"或者"传统生命周期".瀑布模型有利于大型软件开发过程中人员的组织与管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，软件开发各项活动之间并非完全是自上而下的，因此，瀑布模型存在严重的缺陷，只适用于需求明确或很少变更的项目，例如二次开发或升级型的项目。
（2）螺旋模型。螺旋模型将瀑布模型和快速原型模型相结合，综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程及客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的系统。
（5）迭代模型：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。在迭代模型中，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发。在现代的开发方法中，例如XP、RUP等，无一例外地都推荐、主张采用能显著减少风险的迭代模型。迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发中。
（6）V模型。在瀑布模型及其他的经典模型中，测试常常作为亡羊补牢的事后行为，但也有以测试为中心的开发模型，那就是V模型。V模型宣称测试并不是一个事后弥补行为，而是一个同开发过程同样重要的过程，如图1-5所示。
图1-5V模型示意图
V模型描述了一些不同的测试级别，并说明了这些级别所对应的生命周期中不同的阶段。在图1-5中，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程的各个阶段。请注意在不同的组织中，对测试阶段的命名可能有所不同。
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
单元测试的主要目的是针对编码过程中可能存在的各种错误。例如，用户输入验证过程中的边界值错误。集成测试的主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序部分之间的接口中可能存在的错误。系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行。例如，在产品设置中是否达到了预期的高性能。验收测试通常由业务希赛网或用户进行，以确认产品能真正符合用户业务上的需要。
3.需求工程
需求工程是包括创建和维护系统需求文档所必需的一切活动的过程，可分为需求开发和需求管理两大工作。
（1）需求开发。需求开发所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件与其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。需求开发包括需求获取、需求分析、需求定义和需求验证4个阶段。
需求获取。积极地与用户进行交流，捕捉、分析和修正用户对目标系统的需求，并提炼出符合解决问题的用户需求，产生用户需求说明书。需求分析。需求分析的目的是对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。需求定义。需求定义的目标是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求产生需求规格说明书。需求验证。需求验证是指开发方和用户共同对需求文档评审，经双方对需求达成共识后做出书面承诺使需求文档具有商业合同效果。
（2）需求管理。通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。
这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话来说，需求开发是努力更清晰、更明确地掌握客户对系统的需求；而需求管理则是对需求的变化进行管理的过程。
4.软件设计
从工程管理角度来看，软件设计可分为概要设计和详细设计两个阶段。
（1）概要设计。也称为高层设计，即将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系。概要设计主要包括设计软件的结构、确定系统由哪些模块组成，以及每个模块之间的关系。它采用的是结构图（包括模块、调用和数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入/处理/输出图）。整个过程主要包括复查基本系统模型、复查并精化数据流图、确定数据流图的信息流类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析，以及根据软件设计原则对得到的软件结构图进一步进行优化。
（2）详细设计。也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。同样如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。详细设计确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。经常使用的工具包括程序流程图、盒（N-S图）图、PAD图（ProblemAnalysisDiagram,问题分析图）及PDL（ProgramDesignLanguage,伪代码）。
5.软件测试
软件测试是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。
软件测试方法一般分为两大类，分别为动态测试和静态测试。
动态测试指通过运行程序发现错误，主要分为黑盒测试法和白盒测试法。
黑盒测试法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试，常用的黑盒测试用例的设计方法有等价类划分、边界值分析、错误猜测和因果图等。
白盒测试法把测试对象看做一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试及逻辑覆盖测试等。
静态测试指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态分析中进行人工测试的主要方法有桌前检查、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%~70%的逻辑设计和编码错误。
为了保证系统的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格的技术评审。而软件测试则是为了发现错误而执行程序的过程，根据测试的目的、阶段的不同，可以把测试分为单元测试、集成测试、确认测试和系统测试等几类。
6.软件维护
软件经过测试，交付给用户后，在使用和运行过程中可能在软件运行/维护阶段对软件产品进行的修改就是维护。软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充和压缩的容易程度。目前广泛用来衡量程序可维护性的因素包括可理解性、可测试性和可修改性等。
软件维护占整个软件生命周期的60%~80%,维护的类型主要有以下4种。
（1）改正性维护：为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。
（2）适应性维护：在使用过程中，外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。
（3）完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。
（4）预防性维护：这是指预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护可定义为"把今天的方法学用于昨天的系统以满足明天的需要".也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。
7.软件过程管理
在软件过程改进方面，主要考查有关模型和标准的基本概念，例如，软件过程能力成熟度模型（CapabilityMaturityModel,CMM）和能力成熟度模型集成（CapabilityMaturityModelIntegration,CMMI）等。
（1）CMM
CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。
初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。
可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。
已定义级：用于管理和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。
已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。
优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。
（2）CMMI
每一种CMMI模型都有两种表示法，即阶段式和连续式。连续式表示法强调的是单个过程域的能力，从过程域的角度考查基线和度量结果的改善，其关键术语是"能力";而阶段式表示法强调的是组织的成熟度，从过程域集合的角度考查整个组织的过程成熟度阶段，其关键术语是"成熟度".阶段式模型也把组织分为以下5个不同的级别。
初始级：代表了以不可预测结果为特征的过程成熟度，过程处于无序状态，成功主要取决于团队的技能。
已管理级：代表了以可重复项目执行为特征的过程成熟度。
严格定义级：代表了以组织内改进项目执行为特征的过程成熟度。
定量管理级：代表了以改进组织性能为特征的过程成熟度。
优化级：代表了以可快速进行重新配置的组织性能和定量的、持续的过程改进为特征的过程成熟度。
（3）ISO/IEC15504
ISO/IEC15504分为九个部分，分别是概念与介绍指南、过程与过程能力的参考模型、实施评估、评估实施指南、一个评估模型和指示指南、评估员资格认证指南、过程改进应用指南、判断供应商过程能力指南和词汇表，其中第一部分是资料，第二部分和第三部分是标准，其他部分都是参考性的。在ISO/IEC15504的第二部分（过程与过程能力的参考模型）中，在比较高的层次上详细定义了一个用于过程评估的二维参考模型，即过程维和能力维。在ISO/IEC15504中，能力等级是针对每个过程的，它定义了6级过程性能：
不完善的过程。在这个级别上通常不能成功地实现过程的目的。
已实施的过程。通常能够达到过程的目标，但过程并未遵循严格的计划且未被跟踪。
已建立的过程。通过采用一个基于好的软件工程原则所开发出的过程，整个过程被加以实施与管理。
可预测的过程。为了实现过程目标，已定义的过程在受控的范围内以一致的方式加以实施。
优化的过程。为了适应当前和未来业务方面的需要，对过程的实施应进行优化，而在达到所规定的业务目标的同时，过程也实现了可重复性。
（4）SJ/T11234-2001
我国行业标准软件过程能力评估模型（SJ/T11234-2001）针对软件组织对自身软件过程能力进行内部改进的需要，与CMMI连续表示形式基本相同。SJ/T11234-2001的每个过程能力划分为六个评估等级，分别是不完整级、已执行级、受管理级、已定义级、定量管理级和持续优化级。每个等级包含了通用目标、通用惯例、特定目标和特定惯例，它们组成一套衡量准则。不完整级是反映那些没有得到完整执行过程的状态，可能实现了部分特定目标，也可能什么目标都没有实现；处于已执行级的过程实现了全部特定的目标；受管理级、已定义级、定量管理级和持续优化级不仅实现了全部特定目标，而且依次实现了对应更高的通用目标。
8.软件构件技术
构件是软件系统可替换的、物理的组成部分，它封装了实现体（实现某个职能），并提供了一组接口的实现方法。可以认为构件是一个封装的代码模块或大粒度的运作时模块，也可以将构件理解为具有一定功能、能够独立工作或与其它构件组合起来协调工作的对象。
对于构件，应当按可重用的要求进行设计、实现、打包、编写文档。构件应当是内聚的，并具有相当稳定的、公开的接口。为了使构件更切合实际、更有效地被重用，构件应当具备可变性（variability），以提高其通用性。构件应向重用者提供一些公共特性，另一方面还要提供可变的特性。针对不同的应用系统，只需对其可变部分进行适当的调节，重用者要根据重用的具体需要，改造构件的可变特性，即客户化。需要进行客户化的构件称为抽象构件，而可以直接重用的构件称为具体构件。通用性越好，其被重用的面越广。可变性越好，构件就越易于调整，以便适用于应用的具体环境。
为了将不同软件生产商在不同软硬件平台上开发的构件组装成一个应用系统，必须解决异构平台的各构件间的互操作问题，目前已出现了一些支持互操作的构件标准，三个主要流派为OMG（ObjectManagementGroup,对象管理集团）的CORBA（CommonObjectRequestBrokerArchitecture,公共对象请求代理）、Microsoft的COM（ComponentObjectModel,构件对象模型）和DCOM（DistributedComponentObjectModel,分布式构件对象模型）和Sun的EJB（EnterpriseJavaBean,Java企业Bean）。
CORBA是由OMG制定的一个工业标准，其主要目标是提供一种机制，使得对象可以透明地发出请求和获得应答，从而建立起一个异质的分布式应用环境。CORBA技术规范的主要内容包括接口定义语言、接口池、动态调用接口、对象适配器等。
EJB是用于开发和部署多层结构的、分布式的、面向对象的Java应用系统的跨平台的构建架构。使用EJB编写的应用程序具有可扩展性、交互性，以及多用户安全的特性。这些应用只需要写一次，就可以发布到任何支持EJB规范的服务器平台上。有三种类型的EJB,分别是会话Bean、实体Bean和消息驱动Bean.
Microsoft的分布式DCOM扩展了COM,使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通信。使用DCOM,应用程序就可以在位置上达到分布性，从而满足客户和应用的需求。因为DCOM是COM的无缝扩展，所以可以将对基于COM的应用、构件、工具，以及知识转移到标准化的分布式计算领域中来。在做分布式计算时，DCOM处理网络协议的低层次的细节问题，从而使我们能够集中精力解决用户所要求的问题。DCOM具有语言无关性。任何语言都可以用来创建COM构件，并且这些构件可以使用更多的语言和工具。
软考备考资料免费领取
去领取
共收录117.93万道题已有25.02万小伙伴参与做题
售后投诉：156-1612-8671
您还不是该课程的学员，无法下载哦~点击下方立即学习，即可下载更多专享资料