【信息系统项目管理师】学习笔记第5章信息系统工程 5.1软件工程

最新推荐文章于 2024-03-07 14:30:00 发布

专业研究祖传Bug编写术

最新推荐文章于 2024-03-07 14:30:00 发布

阅读量296

点赞数 2

文章标签：学习笔记

本文链接：https://blog.csdn.net/aahwj/article/details/132921210

版权

第5章信息系统工程

信息系统工程是用系统工程的原理、方法来指导信息系统建设与管理的一门工程技术学科，它是信息科学、管理科学、系统科学、计算机科学与通信技术相结合的综合性、交叉性、具有独特风格的应用学科。

5.1 软件工程

软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。

软件工程由方法、工具和过程三个部分组成：

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

5.1.1 结构设计

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成。

1.软件架构风格

Garlan和Shaw对通用软件架构风格进行了分类，他们将软件架构分为：

①数据流风格。数据流风格包括批处理序列和管道/过滤器两种风格。

②调用/返回风格。调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。

③独立构件风格。独立构件风格包括进程通信和事件驱动的系统。

④虚拟机风格。虚拟机风格包括解释器和基于规则的系统。

⑤仓库风格。仓库风格包括数据库系统、黑板系统和超文本系统。

2.软件架构评估

软件架构评估可以只针对一个架构，也可以针对一组架构。在架构评估过程中，评估人员所关注的是系统的质量属性。

在分析具体架构评估方法之前，先了解两个概念：敏感点(Sensitivity Point)和权衡点(Trade-off Point)。敏感点是一个或多个构件(或之间的关系)的特性，权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

从目前已有的软件架构评估技术来看，归纳为三类主要的评估方式，分别是基于调查问卷(或检查表)的方式、基于场景的方式和基于度量的方式。这三种评估方式中，基于场景的评估方式最为常用。

基于场景的方式主要包括：

架构权衡分析法 (Architecture Trade-off Analysis Method, ATAM) 、软件架构分析法 (Software Architecture Analysis Method, SAAM) 和成本效益分析法 (Cost Benefit Analysis Method, CBAM) 中。在架构评估中，一般采用刺激 (Stimulus) 、环境 (Environment) 和响应 (Response) 三方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激做出反应的。

5.1.2 需求分析

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。根据IEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

1.需求的层次

软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。

质量功能部署(Quality Function Deployment, QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

2.需求过程

需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。

1）需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，需求获取只有与用户的有效合作才能成功。常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。

2）需求分析

在需求获取阶段获得的需求是杂乱的。一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。

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

使用结构化分析(Structured Analysis, SA)方法进行需求分析，其建立的模型的核心是数据字典。围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。

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

E-R图主要描述实体、属性，以及实体之间的关系；
DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；
STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。

面向对象的分析(Object-Oriented Analysis, OOA)的基本任务是运用面向对象的(ObjectOriented,OO)方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。

3）需求规格说明书编制

软件需求规格说明书(Software Requirement Specification, SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

在国家标准GB/T 8567《计算机软件文档编制规范》中，提供了一个SRS的文档模板和编写指南，其中规定SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。国家标准GB/T 9385《计算机软件需求说明编制指南》也给出了一个详细的SRS写作大纲。

4）需求验证与确认

在系统分析阶段，检测SRS中的错误所采取的任何措施都将节省相当多的时间和资金。需求验证与确认活动内容包括：

SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；
SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；
需求是完整的和高质量的；
需求的表示在所有地方都是一致的；
需求为继续进行系统设计、实现和测试提供了足够的基础。

在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。只有在业务需求基本明确，用户需求部分确定时，同步进行需求测试，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。

3.UML

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

表5-1 UML的结构

部分	说明
构造块	UML有三种基本的构造块，分别是事物（Thing）、关系（Relationship）和图（Diagram）。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合
规则	规则是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行
公共机制	公共机制是指达到特定目标的公共UML方法，主要包括规则说明（详细说明）、修饰、公共分类（通用划分）和扩展机制四种

1）UML中的事物

UML中的事物也称为建模元素，包括结构事物(Structural Things)、行为事物(Behavioral Things，也称动作事物)、分组事物(Grouping Things)和注释事物(Annotational Things，也称注解事物)。这些事物是UML模型中最基本的OO构造块。如表5-2所示。

表5-2 UML中的事物

建模元素	说明
结构事物	结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。 UML 有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点
行为事物	行为事物是 UML 模型中的动态部分，代表时间和空间上的动作。 UML 有两种主要的行为事物。第一种是交互（内部活动），交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作）、连接（对象之间的连接）；第二种是状态机，状态机由一系列对象的状态组成
分组事物	分组事物是 UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。UML 只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统运行阶段
注释事物	注释事物是UML模型的解释部分

2）UML中的关系

UML用关系把事物结合在一起，主要有四种关系，分别为：

依赖（Dependency）：依赖是两个事物之间的语义关系，一个事物发生变化会影响另一个事物的语义。
关联（Association）：关联描述一组对象之间连接的结构关系。
泛化（Generalization）：泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
实现（Realization）：实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

3）UML2.0中的图

UML2.0包括14种图，如表5-3所示。

表5-3 UML2.0中的图

种类	说明
类图（Class Diagram）	类图描述一组类、接口、协作和它们之间的关系。在OO系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图
对象图（Object Diagram）	对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的
构件图（Component Diagram）	构件图描述一个封装的类和它的接口、端口，以及由内嵌的结构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体
组合结构图（Composite Structure Diagram）	组合结构图描述结构化类（例如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容
用例图（Use Case Diagram）	用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的
顺序图（Sequence Diagram，也称序列图）	顺序图是一种交互图（Interaction Diagram），交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图
通信图（Communication Diagram）	通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。在UML1.X版本中，通信图称为协作图（Collaboration Diagram）
定时图（Timing Diagram，也称计时图）	定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序
状态图（State Diagram）	状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模
活动图（Activity Diagram）	活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程
部署图（Deployment Diagram）	部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图
制品图（Artifact Diagram）	制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件
包图（Package Diagram）	包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系
交互概览图（Interaction Overview Diagram）	交互概览图是活动图和顺序图的混合物

4）UML视图

UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息，包括5个系统视图：

逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。
部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
用例视图：用例视图是最基本的需求分析模型。

另外，UML还允许在一定的阶段隐藏模型的某些元素，遗漏某些元素，可不保证模型的完整性，但模型逐步地要达到完整和一致。

4.面向对象分析

OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。

面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。

1）用例模型

结构化分析(Structured Analysis， SA)方法采用功能分解的方式来描述系统功能，在这种表达方式中，系统功能被分解到各个功能模块中，通过描述细分的系统模块的功能来达到描述整个系统功能的目的。

用例方法是一种需求合成技术，先获取需求并记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。在OOA方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必须的。

表5-4 构建用例模型的阶段

阶段	说明
识别参与者	参与者是系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。参与者一定在系统之外，不是系统的一部分。可以通过下列问题来帮助系统分析师发现系统的参与者：谁使用这个系统，谁安装这个系统，谁启动这个系统，谁维护这个系统，谁关闭这个系统，哪些（其他的）系统使用这个系统，谁从这个系统获取信息，谁为这个系统提供信息，是否有事情自动在预计的时间发生
合并需求获得用例	参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。①要将获取到的需求分配给与其相关的参与者，以便可以针对每个参与者进行工作，而无遗漏；②在合并之前，要明确为什么要合并，知道了合并的目的，才可能选择正确的合并操作；③将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架
细化用例描述	用例建模的主要工作是书写用例规约（Use Case Specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
调整用例模型	在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。 ● 包含关系：当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。 ● 扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。 ● 泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

2）分析模型

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。

建立分析模型的过程大致包括定义概念类，确定类之间的关系，为类添加职责，建立交互图等，其中学者将前三个步骤统称为类 - 责任 - 协作者（Class-Responsibility-Collaborator，CRC）建模。

类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等，它们在UML中的表示方式，如表5-5所示。

表5-5 类之间的关系

关系	图例	描述
关联		关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。其余的关系涉及类元自身的描述，而不是它们的实例。对于关联关系的描述，可以使用关联名称、角色、多重性和导向性来说明
依赖		两个类A和B，如果B的变化可能会引起A的变化，则称类A依赖于类 B。依赖可以由各种原因引起，例如，一个类向另一个类发送消息，一个类是另一个类的数据成员、一个类是另一个类的某个操作参数等
泛化		泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化
共享聚集		共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。例如，汽车和车轮就是聚合关系，车子坏了，车轮还可以用；车轮坏了，可以再换一个新的
组合聚集		组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。例如，一个公司包含多个部门，它们之间的关系就是组合关系。公司一旦倒闭，也就没有部门了
实现		实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作

5.1.3 软件设计

软件设计是需求分析的延伸与拓展。需求分析阶段解决“做什么”的问题，而软件设计阶段解决“怎么做”的问题。软件设计分为结构化设计与面向对象设计。

1.结构化设计

结构化设计（Structured Design，SD）是一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。

SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段，其中概要设计又称为总体结构设计，其主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务，而为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。根据任务的不同，详细设计又可分为多种，例如，输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。

在SD中，需要遵循一个基本的原则：高内聚，低耦合。内聚表示模块内部各成分之间的联系程度，是从功能角度来度量模块内的联系；耦合表示模块之间联系的程度。

2.面向对象设计

面向对象设计(OOD)是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。在OOD中，数据结构和在数据结构上定义的操作算法封装在一个对象之中。

OOD的主要任务是对类和对象进行设计，包括类的属性、方法以及类与类之间的关系。OOD的结果就是设计模型。对于OOD而言，在支持可维护性的同时，提高软件的可复用性是一个至关重要的问题，如何同时提高软件的可维护性和可复用性，是OOD需要解决的核心问题之一。常用的OOD原则包括：

单职原则：设计功能单一的类。本原则与结构化方法的高内聚原则是一致的。
开闭原则：对扩展开放，对修改封闭。
李氏替换原则：子类可以替换父类。
依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。
接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解。本原则与结构化方法的低耦合原则是一致的。

3.设计模式

设计模式是前人经验的总结，它使人们可以方便地复用成功的软件设计。设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。

根据处理范围不同，设计模式可分为类模式和对象模式。类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系；对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性。

根据目的和用途不同，设计模式可分为创建型（Creational）模式、结构型（Structural）模式和行为型（Behavioral）模式三种：

①创建型模式主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等；

②结构型模式主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等；

③行为型模式主要用于描述类或对象的交互以及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。

5.1.4 软件实现

1.软件配置管理

软件配置管理通过标识产品的组成元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的演进和完整性。

软件配置管理活动包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付等活动。

软件配置管理计划的制订需要了解组织结构环境和组织单元之间的联系，明确软件配置控制任务。软件配置标识活动识别要控制的配置项，并为这些配置项及其版本建立基线。
软件配置控制关注的是管理软件生命周期中的变更。
软件配置状态记录标识、收集、维护并报告配置管理的配置状态信息。
软件配置审计是独立评价软件产品和过程是否遵从已有的规则、标准、指南、计划和流程而进行的活动。
软件发布管理和交付通常需要创建特定的交付版本，完成此任务的关键是软件库。

2.软件编码

所谓编码就是把软件设计的结果翻译成计算机可以“理解和识别”的形式——用某种程序设计语言书写的程序。作为软件工程的一个步骤，编码是设计的自然结果，因此，程序的质量主要取决于软件设计的质量。但是，程序设计语言的特性和编码途径也会对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。

（1）程序设计语言。编码的目的是实现人和计算机的通信，指挥计算机按人的意志正确工作。程序设计语言是人和计算机通信的最基本工具，程序设计语言的特性不可避免地会影响人的思维和解决问题的方式，会影响人和计算机通信的方式和质量，也会影响其他人阅读和理解程序的难易程度。

（2）程序设计风格。阅读程序是软件开发和维护过程中的一个重要组成部分，而且读程序的时间比写程序的时间还要多。程序设计风格包括4个方面：源程序文档化、数据说明、语句结构和输入/输出方法。应尽量从编码原则的角度提高程序的可读性，改善程序的质量。

（3）程序复杂性度量。定量度量程序复杂程度的方法很有价值，把程序的复杂度乘以适当的常数即可估算出软件中故障的数量及软件开发时的工作量。定量度量的结构可以用于比较两个不同设计或两种不同算法的优劣；程序的定量的复杂程度可以作为模块规模的精确限度。

（4）编码效率。编码效率主要包括：

①程序效率。程序的效率是指程序的执行速度及程序所需占用的内存空间。任何对效率无重要改善，且对程序的简单性、可读性和正确性不利的程序设计方法都是不可取的。

②算法效率。源程序的效率与详细设计阶段确定的算法的效率直接相关。在详细设计翻译转换成源程序代码后，算法效率反映为程序的执行速度和存储容量的要求。

③存储效率。存储容量对软件设计和编码的制约很大。因此要选择可生成较短目标代码且存储压缩性能优良的编译程序，有时需要采用汇编程序，通过程序员富有创造性的努力，提高软件的时间与空间效率。提高存储效率的关键是程序的简单化。

④I/O效率。输入/输出可分为两种类型：一种是面向人（操作员）的输入/输出；另一种是面向设备的输入/输出。

3.软件测试

软件测试是在将软件交付给客户之前所必须完成的重要步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误（缺陷）的主要手段。

根据国家标准GB/T 15532《计算机软件测试规范》，软件测试的目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。通过测试发现软件缺陷，为软件产品的质量测量和评价提供依据。

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

①静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一般采用桌前检查(Desk Checking)、代码走查和代码审查。经验表明，使用这种方法能够有效地发现30%~70%的逻辑设计和编码错误。

②动态测试是指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。白盒测试也称为结构测试，主要用于软件单元测试中。它的主要思想是，将程序看作是一个透明的白盒，测试入员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。使用静态测试的方法也可以实现白盒测试。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考查对程序逻辑的覆盖程度。主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试中。黑盒测试将程序看作是一个不透明的黑盒，完全不考虑(或不了解)程序的内部结构和处理算法，而只检查程序功能是否能按照SRS的要求正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性等。黑盒测试根据SRS所规定的功能来设计测试用例，一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。

5.1.5 部署交付

软件部署是一个复杂过程，包括从开发商发放产品，到应用者在他们的计算机上实际安装并维护应用的所有活动。这些活动包括软件打包、安装、配置、测试、集成和更新等。

1.软件部署与交付

软件部署与交付是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。部署技术影响着整个软件过程的运行效率和成本投入，软件系统部署的管理代价占到整个软件管理开销的大部分。其中软件配置过程极大地影响着软件部署结果的正确性，应用系统的配置是整个部署过程中的主要错误来源。

目前，部署与交付常存在：

分支冗余导致合并困难；
缺陷过多导致阻塞测试；
开发环境、测试环境、部署环境不统一导致的未知错误；
代码提交版本混乱无法回溯；
等待上线周期过长；
项目部署操作复杂经常失败；
上线之后出现问题需要紧急回滚；
架构设计不合理导致发生错误之后无法准确定位等困境。

2.持续交付

持续交付是一系列开发实践方法，用来确保让代码能够快速、安全地部署到生产环境中。持续交付是一个完全自动化的过程，当业务开发完成的时候，可以做到一键部署。持续交付提供了一套更为完善的解决传统软件开发流程的方案，主要体现在：

在需求阶段，抛弃了传统的需求文档的方式，使用便于开发入员理解的用户故事；
在开发测试阶段，做到持续集成，让测试人员尽早进入项目开始测试；
在运维阶段，打通开发和运维之间的通路，保待开发环境和运维环境的统一。

持续交付具备的优势主要包括：

待续交付能够有效缩短提交代码到正式部署上线的时间，降低部署风险；
待续交付能够自动、快速地提供反馈，及时发现和修复缺陷；
持续交付让软件在整个生命周期内都处于可部署的状态；
待续交付能够简化部署步骤，使软件版本更加清晰；
持续交付能够让交付过程成为一种可靠的、可预期的、可视化的过程。

在评价互联网公司的软件交付能力的时候，通常会使用两个指标：

仅涉及一行代码的改动需要花费多少时间才能部署上线，这也是核心指标；
开发团队是否在以一种可重复、可靠的方式执行软件交付。

3.持续部署

对于持续交付整体来说，持续部署非常重要。

1）持续部署方案

容器技术目前是部署中最流行的技术，常用的持续部署方案有Kubernetes+Docker和Matrix系统两种。对比传统的虚拟机技术优点主要有：

容器技术上手简单，轻量级架构，体积很小；
容器技术的集合性更好，能更容易对环境和软件进行打包复制和发布；
容器技术的引入为软件的部署带来了前所未有的改进，不但解决了复制和部署麻烦的问题，还能更精准地将环境中的各种依赖进行完整的打包。

2）部署原则

在待续部署管理的时候，需要遵循一定的原则，主要包括：

部署包全部来自统一的存储库；
所有的环境使用相同的部署方式；
所有的环境使用相同的部署脚本；
部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，一旦发生问题可以有序地进行回滚操作；
整体部署由运维入员执行；
仅通过流水线改变生产环境，防止配置漂移；
不可变服务器；
部署方式采用蓝绿部署或金丝雀部署。

3）部署层次

首先要明确部署的目的并不是部署一个可工作的软件，而是部署一套可正常运行的环境。完整的镜像部署包括三个环节：Build—Ship—Run。

Build：跟传统的编译类似，将软件编译形成RPM包或者Jar包；
Ship：则是将所需的第三方依赖和第三方插件安装到环境中；
Run：就是在不同的地方启动整套环境。

制作完成部署包之后，每次需要变更软件或者第三方依赖以及插件升级的时候，不需要重新打包，直接更新部署包即可。

4）不可变服务器

不可变服务器是一种部署模式，是指除了更新和安装补丁程序以外，不对服务器进行任何更改。不可变服务器是技术逐步演化的结果。

5)蓝绿部署和全丝雀部署

蓝绿部署是指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。

金丝雀部署是指当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户。

4.部署与交付的新趋势

持续集成、待续交付和待续部署的出现及流行反映了新的软件开发模式与发展趋势，主要表现为：

工作职责和人员分工的转变：软件开发人员运用自动化开发工具进行持续集成，进一步将交付和部署扩展，而原来的手工运维工作也逐渐被分派到了开发入员的手里。运维人员的工作也从重复枯燥的手工作业转化为开发自动化的部署脚本，并逐步并入开发人员的行列之中。
大数据和云计算基础设施的普及进一步给部署带来新的飞跃：云计算的出现使得计算机本身也可以进行自动化创建和回收，这种环境管理的范畴将得到进一步扩充。部署和运维工作也会脱离具体的机器和机房，可以在远端进行，部署能力和灵活性出现了质的飞跃。
研发运维的融合：减轻运维的压力，把运维和研发融合在一起。

5.1.6 过程管理

软件过程能力是组织基于软件过程、技术、资源和人员能力达成业务目标的综合能力。包括治理能力、开发与交付能力、管理与支持能力、组织管理能力等方面。软件过程能力成熟度是指组织在提升软件产品开发能力或软件服务能力过程中，各个发展阶段的软件能力成熟度。常见的软件过程管理方法和实践包括国际常用的能力成熟度模型集成 (Capability Maturity Model Integration， CMMI)和中国电子工业标准化技术协会发布的 T/CESA 1159 《软件过程能力成熟度模型》 (Software Process Capability Maturity Model) 团体标准，简称 CSMM 。

1.成熟度模型

CSMM定义的软件过程能力成熟度模型旨在通过提升组织的软件开发能力帮助顾客提升软件的业务价值。该模型借鉴吸收了软件工程、项目管理、产品管理、组织治理、质量管理、卓越绩效管理、精益软件开发等领域的优秀实践，为组织提供改进和评估软件过程能力的一个成熟度模型，其层次结构如图5-1所示。

图5-1 软件过程能力成熟度层次结构

CSMM模型由4个能力域、20个能力子域、161个能力要求组成：

治理：包括战略与治理、目标管理能力子域，用于确定组织的战略、产品的方向、组织的业务目标，并确保目标的实现。
开发与交付：包括需求、设计、开发、测试、部署、服务、开源应用能力子域，这些能力子域确保通过软件工程过程交付满足需求的软件，为顾客与利益干系人增加价值。
管理与支持：包括项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、供应商管理能力子域，这些能力子域稷盖了软件开发项目的全过程，以确保软件项目能够按照既定的成本、进度和质量交付，能够满足顾客与利益干系人的要求。
组织管理：包括过程管理、人员能力管理、组织资源管理、过程能力管理能力子域，对软件组织能力进行综合管理。

2.成熟度等级

按照软件过程能力的成熟度水平由低到高演进发展的形势，CSMM定义了5个等级，高等级是在低等级充分实施的基础之上进行。成熟度等级的总体特征如表5-6所示。

表5-6 成熟度等级的总体特征

等级	结果特征	行为特征
1级：初始级	软件过程和结果具有不确定性	● 能实现初步的软件交付和项目管理活动 ● 项目没有完整的管理规范，依赖于个人的主动性和能力
2级：项目规范级	项目基本可按计划实现预期的结果	● 项目依据选择和定义管理规范，执行软件开发和管理的基础过程 ● 组织按照一定的规范，为项目活动提供了支持保障工作
3级：组织改进级	在组织范围内能够稳定地实现预期的项目目标	● 在2级充分实施的基础之上进行持续改进 ● 依据组织的业务目标、管理要求以及外部监管需求，建立并持续改进组织标准过程和过程资产 ● 项目根据自身特征，依据组织标准过程和过程资产，实现项目目标，并贡献过程资产
4级：量化提升级	在组织范围内能够量化地管理和实现预期的组织和项目目标	● 在3级充分实施的基础上使用统计分析技术进行管理 ● 组织层面认识到能力改进的重要性，了解软件能力在业务目标实现、绩效提升等方面的重要作用，在制定业务战略时可获得项目数据的支持。 ● 组织和项目使用统计分析技术建立了量化的质量与过程绩效目标，支持组织业务目标的实现。 ● 建立了过程绩效基线与过程绩效模型 ● 采用有效的数据分析技术，分析关键软件过程的能力，预测结果，识别和解决目标实现的问题以达成目标 ● 应用先进实践，提升软件过程效率或质量
5级：创新引领级	通过技术和管理的创新，实现组织业务目标的持续提升，引领行业发展	● 在4级充分实施的基础上进行优化革新 ● 通过软件过程的创新提升组织竞争力 ● 能够使用创新的手段实现软件过程能力的持续提升，支持组织业务目标的达成 ● 能将组织自身软件能力建设的经验作为行业最佳案例进行推广