导图社区 5.1 软件工程
- 75
- 0
- 0
- 举报
5.1 软件工程
根据第四版《信息系统项目管理师》教材整理。如 软件过程能力成熟度是指组织在提升软件产品开发能力或软件服务能力过程中，各个发展阶段的软件能力成熟度。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- 相似推荐
- 大纲
5.1 软件工程
5.1.1架构设计
1.软件架构风格
①数据流风格。数据流风格包括批处理序列和管道/过滤器两种风格。
②调用/返回风格。调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
③独立构件风格。独立构件风格包括进程通信和事件驱动的系统。
④虚拟机风格。虚拟机风格包括解释器和基于规则的系统。
⑤仓库风格。仓库风格包括数据库系统、黑板系统和超文本系统。
2.软件架构评估
敏感点(Sensitivity Point)和权衡点(Trade-off Point)。敏感点是一个或多个构件(或之间的关系)的特性，权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。
软件架构评估技术
基于调查问卷(或检查表)的方式
基于场景的方式
架构权衡分析法(Architecture Trade-offAnalysis Method,ATAM)
软件架构分析法(Software Architecture Analysis Method,SAAM)
成本效益分析法(Cost Benefit Analysis Method,CBAM)
在架构评估中，一般采用刺激(Stimulus)、环境(Environment)和响应(Response)三方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激做出反应的。
基于度量的方式
5.1.2需求分析
定义
软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望
1.需求的层次
业务需求、用户需求和系统需求
质量功能部署(Quality Function Deployment,QFD)软件需求分为三类，分别是常规需求、期望需求和意外需求。
2.需求过程
1)需求获取
需求获取只有与用户的有效合作才能成功。
常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
2)需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。
方法
结构化分析(Structured Analysis,SA)方法
进行需求分析，其建立的模型的核心是数据字典。
模型
数据模型
一般使用实体关系图(E-R图)表示数据模型
E-R图主要描述实体、属性，以及实体之间的关系
功能模型
数据流图(Data Flow Diagram,DFD)表示功能模型，
DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能
行为模型(也称为状态模型)
态转换图(State Transform Diagram,STD)表示行为模型
STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。
面向对象的分析(Object-Oriented Analysis,OOA)
模型
用例模型
用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；
分析模型
分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型),以及它们如何保持通信，实现系统行为(动态模型)。
3)需求规格说明书编制
软件需求规格说明书(Software Requirement Specification,SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。
4)需求验证与确认
需求验证与确认活动内容包括：
SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；
SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；
需求是完整的和高质量的；
需求的表示在所有地方都是一致的；
需求为继续进行系统设计、实现和测试提供了足够的基础。
需求进行验证方法：
需求评审
需求评审就是对SRS进行技术评审，发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。
需求测试
只有在业务需求基本明确，用户需求部分确定时，同步进行需求测试，才可能及早需求的遗漏和错误从而在需求开发阶段以较低的代价解决这些问题。
3.统一建模语言 (Unified Modeling Language,UML)
统一建模语言(Unified Modeling Language,UML)持从需求分析开始的软件 开发的全过程、OOA和OOD(Object-Oriented Design,面向对象设计)
从总体上来看，UML的结构包括构造块、规则和公共机制三个部分
构造块
概述
UML有三种基本的构造块，分别是事物(Thing)、关系(Relationship)和图(Diagram)。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合
1)UML中的事物
UML中的事物也称为建模元素，这些事物是UML模型中最基本的OO构造块，
结构事物(Structural Things)
结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。UML有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点
行为事物(Behavioral Things,也称动作事物)
行为事物是UML模型中的动态部分，代表时间和空间上的动作
交互(内部活动)
状态机
分组事物(Grouping Things)
分组事物是UML模型中组织的部分，可以看成是个盒子，模型可以在其中进行分解。UML只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统运行阶段
注释事物(Annotational Things,也称注解事物)
注释事物是UML模型的解释部分
2)UML中的关系
依赖(Dependency):依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
关联(Association):关联描述一组对象之间连接的结构关系。
泛化(Generalization):泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
实现(Realization):实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
3)UML2.0中的图
类图(Class Diagram)
类图描述一组类、接口、协作和它们之间的关系。在OO系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图
对象图(Object Diagram)
对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的
构件图(Component Diagram)
构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体
组合结构图(Composite Structure Diagram)
组合结构图描述结构化类(例如，构件或类)的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容
用例图(Use Case Diagram)
用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的
顺序图(Sequence Diagram,也称序列图)
顺序图是一种交互图(Interaction Diagram),交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图
通信图(Communication Diagram)
通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构(关系)。在UML 1.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模型及其详细说明。OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是O0A和OOD的区别之所在。O0A的任务是“做什么”,OOD的任务是“怎么做”。
面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。
1)用例模型
用例方法是一种需求合成技术，先获取需求并记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型
构建用例模型的四个阶段
识别参与者
参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。
合并需求获得用例
参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。
细化用例描述
用例建模的主要工作是书写用例规约(Use Case Specificatio）
调整用例模型
用例之间的关系主要有包含、扩展和泛化。利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。
2)分析模型
分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型),以及它们如何保持通信，实现系统行为(动态模型)。
建立分析模型的过程
定义概念类
确定类之间的关系
为类添加职责
类-责任-协作者(Class-Responsibility-Collaborator, CRC)建模
建立交互图
类之间的主要关系
关联
关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。其余的关系涉及类元自身的描述，而不是它们的实例。对于关联关系的描述，可以使用关联名称、角色、多重性和导向性来说明
依赖
两个类A和B,如果B的变化可能会引起A的变化，则称类A依赖于类B。依赖可以由各种原因引起，例如，一个类向另一个类发送消息，一个类是另一个类的数据成员，一个类是另一个类的某个操作参数等
泛化
泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也 就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化
共享聚集
共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”,“部分”与“整体”的生命周期可以不相同。
例如，汽车和车轮就是聚合关系，车子坏了，车轮还可以用；车轮坏了，可以再换一个新的
组合聚集
组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”,“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
例如，一个公司包含多个部门，它们之间的关系就是组合关系。公司一旦倒闭，也就没有部门了
实现
实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作
5.1.3软件设计
1.结构化设计 (Structured Design,SD)
结构化设计是一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。
基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，
两个阶段
概要设计
又称为总体结构设计，系统开发的总任务分解成许多个基本的、具体的任务，
主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
详细设计
为每个具体任务选择适当的技术手段和处理方法
基本的原则
高内聚，低耦合
内聚表示模块内部各成分之间的联系程度，是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做目标单一的一件事情
耦合表示模块之间联系的程度
2.面向对象设计 (OOD)
基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。
主要任务是对类和对象进行设计，包括类的属性、方法以及类与类之间的关系。
结果是设计模型
核心问题是如何同时提高软件的可维护性和可复用性
原则
单职原则：设计功能单一的类。本原则与结构化方法的高内聚原则是一致的。
开闭原则：对扩展开放，对修改封闭。
李氏替换原则：子类可以替换父类。
依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。
接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
迪米特原则(最少知识法则):一个对象应当对其他对象有尽可能少的了解。本原则与结构化方法的低耦合原则是一致的。
3.设计模式
设计模式是前人经验的总结，它使人们可以方便地复用成功的软件设计。
设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
根据处理范围不同，设计模式可分为
类模式
类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系
对象模式。
对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性。
根据目的和用途不同，设计模式可分为
创建型(Creational)模式
创建型模式主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等；
结构型(Structural)模式
结构型模式主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等
行为型(Behavioral)模式
行为型模式主要用于描述类或对象的交互以及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。
5.1.4软件实现
1.软件配置管理
软件配置管理计划
软件配置标识
软件配置控制
软件配置状态记录
软件配置审计
软件发布管理与交付
2.软件编码
编码就是把软件设计的结果翻译成计算机可以“理解和识别”的形式——用某种程序设计语言书写的程序。
编码的目的是实现人和计算机的通信，指挥计算机按人的意志正确工作。
(1)程序设计语言。
(2)程序设计风格
源程序文档化、数据说明、语句结构和输入/输出方法。
(3)程序复杂性度量
程序的定量的复杂程度可以作为模块规模的精确限度。
(4)编码效率
①程序效率。程序的效率是指程序的执行速度及程序所需占用的内存空间。
②算法效率。在详细设计翻译转换成源程序代码后，算法效率反映为程序的执行速度和存储容量的要求。
③存储效率
提高存储效率的关键是程序的简单化。
选择可生成较短目标代码且存储压缩性能优良的编译程序，有时需要采用汇编程序，提高软件的时间与空间效率。
④I/0效率。
面向人(操作员)的输入/输出；
面向设备的输入/输出。
3.软件测试
软件测试是在将软件交付给客户之前所必须完成的重要步骤。
根据国家标准GB/T 15532《计算机软件测试规范》,软件测试的目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。
软件测试方法
静态测试
静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。
对文档的静态测试主要以检查单的形式进行，对代码的静态测试一 般采用桌前检查(Desk Checking)、代码走查和代码审查。
经验表明，使用这种方法能够有效地发现30%~70%逻辑设计和编码错误。
动态测试
动态测试是指在计算机上实际运行程序进行软件测试
白盒测试
白盒测试也称为结构测试，主要用于软件单元测试中。
主要思想是，将程序看作是一个透明的白盒，测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作。
白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。使用静态测 试的方法也可以实现白盒测试。
最常用的技术是逻辑覆盖，使用测试数据运行被测程序，考查对程序逻辑的覆盖程度。主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。
黑盒测试
黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试中。完全不考虑(或不了解)程序的内部结构和处理算法，而只检查程序功能是否能按照SRS的要求正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息(例如，文件和数据库等)的完整性等。
黑盒测试根据SRS所规定的功能来设计测试用例，一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。
5.1.5部署交付
1.软件部署与交付
软件部署即通过配置、安装和激活等活动来保障软件制品的后续运行。
2.持续交付
持续交付是一个完全自动化的过程，当业务开发完成的时候，可以做到一键部署。
方案
在需求阶段，抛弃了传统的需求文档的方式，使用便于开发人员理解的用户故事；
在开发测试阶段，做到持续集成，让测试人员尽早进入项目开始测试：
在运维阶段，打通开发和运维之间的通路，保持开发环境和运维环境的统一。
优势
持续交付能够有效缩短提交代码到正式部署上线的时间，降低部署风险：
持续交付能够自动、快速地提供反馈，及时发现和修复缺陷；
持续交付让软件在整个生命周期内都处于可部署的状态；
持续交付能够简化部署步骤，使软件版本更加清晰；
持续交付能够让交付过程成为一种可靠的、可预期的、可视化的过程。
评价互联网公司的软件交付能力的指标
仅涉及一行代码的改动需要花费多少时间才能部署上线，这也是核心指标；
开发团队是否在以一种可重复、可靠的方式执行软件交付。
3.持续部署
1)持续部署方案
容器技术目前是部署中最流行的技术，常用的持续部署方案有Kubernetes Docker和Matrix系统两种。
优点
容器技术上手简单，轻量级架构，体积很小；
容器技术的集合性更好，能更容易对环境和软件进行打包复制和发布；
容器技术的引入为软件的部署带来了前所未有的改进，不但解决了复制和部署麻烦的问题，还能更精准地将环境中的各种依赖进行完整的打包。
2)部署原则
部署包全部来自统一的存储库；
所有的环境使用相同的部署方式；
所有的环境使用相同的部署脚本；
部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，一旦发生问题可以有序地进行回滚操作
整体部署由运维人员执行；
仅通过流水线改变生产环境，防止配置漂移；
不可变服务器；
部署方式采用蓝绿部署或金丝雀部署。
3)部署层次
部署的目的并不是部署一个可工作的软件，而是部署一套可正常运行的环境
完整的镜像部署包括三个环节
Build:跟传统的编译类似，将软件编译形成RPM包或者Jar包；
Ship:则是将所需的第三方依赖和第三方插件安装到环境中；
Run:就是在不同的地方启动整套环境。
4)不可变服务器
不可变服务器是一种部署模式，是指除了更新和安装补丁程序以外，不对服务器进行任何更改。
容器部署就像一个集装箱，直接把所有需要的内容全部打包并进行复制和部署。
5)蓝绿部署和金丝雀部署
蓝绿部署是指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。
金丝雀部署是指当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户。
4.部署与交付的新趋势
工作职责和人员分工的转变：
软件开发人员运用自动化开发工具进行持续集成，进一步将交付和部署扩展，而原来的手工运维工作也逐渐被分派到了开发人员的手里。运维人员的工作也从重复枯燥的手工作业转化为开发自动化的部署脚本，并逐步并入开发人员的行列之中。
大数据和云计算基础设施的普及进一步给部署带来新的飞跃：
云计算的出现使得计算机本身也可以进行自动化创建和回收，这种环境管理的范畴将得到进一步扩充。部署和运维工作也会脱离具体的机器和机房，可以在远端进行，部署能力和灵活性出现了质的飞跃。
研发运维的融合：
减轻运维的压力，把运维和研发融合在一起。
5.1.6过程管理
概述
软件过程能力成熟度是指组织在提升软件产品开发能力或软件服务能力过程中，各个发展阶段的软件能力成熟度。
常用的能力成熟度模型集成(Capability Maturity Model Integration,CMMI)和中国电子工业标准化技术协会发布的T/CESA1159《软件过程能力成熟度模型》(Software Process Capability Maturity Model)团体标准，简称CSMM。
1.成熟度模型CSMM
在通过提升组织的软件开发能力帮助顾客提升软件的业务价值。
2.成熟度等级
按照软件过程能力的成熟度水平由低到高演进发展的形势，CSMM定义了5个等级，高等级是在低等级充分实施的基础之上进行。
能力域的等级要求