系统集成项目管理工程师:第五章: 软件工程

摘要：软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。电气与电子工程师协会(lnstitute ofElectricaland ElectronicsEngine

1.软件工程定义

软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。电气与电子工程师协会(lnstitute ofElectricaland ElectronicsEngineers，IEEE)对软件工程的定义是:将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。计算机科学家Fritz Bauer给出的软件工程的定义是:建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。软件工程由方法、工具和过程3个部分组成。

2.软件工程使用的方法是完成软件项目的技术手段，它支持整个软件生命周期;软件工程使用的工具是人们在开发软件的活动中智力和体力的扩展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成;软件工程中的过程贯穿于软件开发的各个环节，是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。管理人员在软件工程过程中，要对软件开发的质量、进度、成本进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证和配置管理等。

3.软件需求

(1)需求的层次:业务需求、用户需求、系统需求。

(2)质量功能部署:

常规需求，用户认为系统应该做到的功能或性能，实现得越多，用户会越满意。

期望需求，用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。

意外需求，意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性)，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

(3)需求获取:需求获取是确定和理解不同的项目千系人对系统的需求和约束的过程。

(4)需求分析:需求分析是将提炼、分析和审查已经获取到的需求，以确保所有的项目干系人都明白其含义，并找出其中的错误、遗漏或其他不足的地方。

(5)需求规格说明书:软件需求规格说明书(Software Requirement Specification，SRS)是在需求分析阶段需要完成的文档，是软件需求分析的最终结果，是确保每个要求得以满足所使用的方法。SRS 应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。

4.一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。

5.结构化分析(Structured Analysis， SA)方法给出一组帮助系统分析人员产生功能规约的原理与技术，其建立模型的核心是数据字典。围绕这个核心，有3个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。

在实际工作中，一般使用实体关系图(E-R图)表示数据模型，用数据流图(DataFlow Diagram， DFD)表示功能模型，用状态转换图(StateTransform Diagram， STD)表示行为模型。

数据模型:实体关系图(E-R图)主要描述实体、属性，以及实体之间的关系;

功能模型:数据流图DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能;

行为模型:状态转换图STD通过描述系统的状态和引起系统状态转换的事件，指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。

6.面向对象设计

面向对象设计(Object-OrientedDesign，OOD)是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。在OOD中，数据结构和在数据结构上定义的操作算法封装在一个对象之中。由于现实世界中的事物都可以抽象出对象的集合，所以OOD方法是一种更接近现实世界、更自然的软件设计方法。

常用的OOD原则包括:

单职原则:一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

开闭原则:对扩展开放，对修改封闭。当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块Í珽卄家功能，使其满足新的需求。

里氏替换原则:子类可以替换父类，即子类可以扩展父类的功能，但不能改变父类原有的功能。

依赖倒置原则:要依赖于抽象，而不是具体实现，要针对接口编程，不要针对实现编程。

接口隔离原则:使用多个专门的接口比使用单一的总接口要好。

组合重用原则:要尽量使用组合，而不是继承关系达到重用目的。

迪米特原则(最少知识法则):一个对象应当对其他对象有尽可能少的了解。其目的是降低类之间的耦合度，提高模块的相对独立性。

7.在OOD中，类可以分为3种类型:实体类、控制类和边界类。

实体类

实体类映射需求中的每个实体，是指实体类保存需要存储在永久存储体中的信息。例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。实体类对用户来说是最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型的转换中，一个参与者一般对应于实体类。通常可以从SRS中的那些与数据库表(需要持久存储)对应的名词着手来找寻实体类。通常情况下，实体类一定有属性，但不一定有操作。

控制类

控制类是用于控制用例工作的类，一般是由动宾结构的短语(“动词+名词”或“名词+动词”)转化来的名词。例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象(控制类的实例)通常控制其他对象，因此，它们的行为具有协调性。控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。通常情况下，控制类没有属性，但一定有方法。

边界类

边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类,边界类使参与者能与系统交互。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更(例如，与其他系统的接口的变更、用户需求的变更等)分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。

8.统一建模语言

统一建模语言(Unified ModelingLanguage，UML)是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术，它的作用域不仅支持00A(面向对象分析法)和O0D(面向对象设计)，还支持从需求分析开始的软件开发的全过程。从总体上来看，UML的结构包括构造块、规则和公共机制3个部分。

9..UML中的关系

UML用关系把事物结合在一起，主要有4种关系:依赖、关联、泛化和实现。

(1)依赖(Dependency)，依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。

(2)关联(Association)，关联是指一种对象和另一种对象有联系。

(3)泛化(Generalization)，泛化是一般元素和特殊元素之间的分类关系，描述特殊元素的对象可替换一般元素的对象。其中的一个类指定了由另一个类保证执行的契约。

(4)实现(Realization)，实现将不同的模型元素(例如，类)连接起来。

10.软件测试是在将软件交付给客户之前所必须完成的重要步骤。软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。软件测试的目的就是确保软件的质量。

11.测试方法

软件测试方法可分为静态测试和动态测试。

1)静态测试

静态测试是指被测试程序不在机器上运行，只依靠分析或检査源程序的语句、结构、过程等来检查程序是否有错误，即通过对软件的需求规格说明书、设计说明书以及源程序做结构分析和流程图分析，从而找出错误。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检査单的形式进行，而对代码的静态测试一般采用桌前检査(Desk Checking)、代码走查和代码审查的方式。经验表明，使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误。

2)动态测试

动态测试是指在计算机上实际运行程序进行软件测试，对得到的运行结果与预期的结果进行比较分析，同时分析运行效率和健壮性能等。一般采用白盒测试和黑盒测试方法。

白盒测试也称为结构测试，主要用于软件单元测试中。它的主要思想是，将程序看作一个透明的白盒，测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按设计规格说明书的设定进行。

白盒测试方法是从程序结构方面出发对测试用例进行设计，主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正常以及内部结构是否有效，包括控制流测试、数据流测试和程序变异测试等。

另外，使用静态测试的方法也可以实现白盒测试。例如使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试的范畴。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考查对程序逻辑的覆盖程度，主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。

黑盒测试也称为功能测试，它是通过测试来检测每个功能能否正常使用。黑盒测试将程序看作一个不透明的黑盒，完全不考虑(或不了解)程序的内部结构和处理算法，根据需求规格说明书设计测试实例，并检查程序的功能是否能够按照规范说明准确无误地运行。对于黑盒测试行为必须加以量化才能够有效地保证软件的质量。黑盒测试根据SRS所规定的功能来设计测试用例，一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。

12.测试类型

根据国家标准《计算机软件测试规范》(GB/T15532)，软件测试可分为单元测试、集成测试、确认测试、系统测试、配置项测试和回归测试等类别。