信息系统项目管理师第四版学习笔记——信息系统工程之软件工程

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

电气与电子工程师协会(Institute of Electrical and Electronics Engineers,IEEE)对软件工程的定义是：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。

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

1.架构设计

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

软件架构分为：数据流风格、调用/返回风格、独立构件风格、虚拟机风格、仓库
风格。

• 数据流风格包括批处理序列和管道/过滤器两种风格。
• 调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
• 独立构件风格包括进程通信和事件驱动的系统。
• 虚拟机风格包括解释器和基于规则的系统。
• 仓库风格包括数据库系统、黑板系统和超文本系统。

软件架构评估方式：基于调查问卷(或检查表)的方式、基于场景的方式和基于度量的方式。基于场景的评估方式最为常用。

基于场景的方式主要包括：架构权衡分析法(Architecture Trade-off Analysis Method,ATAM)、软件架构分析法(Software Architecture Analysis Method,SAAM)和成本效益分析法(Cost Beneft Analysis Method,CBAM)。

在架构评估中，一般采用刺激(Stimulus)、环境(Environment)和响应(Response)三方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激做出反应的。

2.需求分析

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

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

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

• 需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
• 需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。需求分析的关键在于对问题域的研究与理解。
• 软件需求规格说明书(Software Requirement Specification,SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。
• 在系统分析阶段，检测SRS中的错误所采取的任何措施都将节省相当多的时间和资金。

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

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

面向对象分析(Object-Oriented Analysis,OOA)的基本任务是运用面向对象的(Object-Oriented,OO)方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求。

• OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型),以及它们如何保持通信，实现系统行为(动态模型)。

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

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

在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。

统一建模语言(Unified Modeling Language,UML)是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持OOA和OOD(Object-Oriented Design,面向对象设计),还支持从需求分析开始的软件开发的全过程。

UML的结构包括构造块、规则和公共机制三个部分。

UML中的事物也称为建模元素，包括结构事物(Structural Things)、行为事物(BchavioralThings,也称动作事物)、分组事物(Grouping Things)和注释事物(Annotational Things,也称注解事物)。

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

UML用关系把事物结合在一起，主要有四种关系：依赖(Dependency)、关联(Association)、泛化(Generalization)、实现(Realization)。

UML2.0中的图包括：类图(Class Diagram)、对象图(Object Diagram)、构件图(Component Diagram)、组合结构图(Composite Structure Diagram)、用例图(Use Case Diagram)、顺序图(Sequence Diagram,也称序列图)、通信图(Communication Diagram)、定时图(Timing Diagram,也称计时图)、状态图(State Diagram)、活动图(Activity Diagram)、部署图(Deployment Diagram)、制品图(Artifact Diagram)、包图(Package Diagram)、交互概览图(Interaction Overview
Diagram)。

UML包括5个视图：逻辑视图、进程视图、实现视图、部署视图、用例视图。

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

面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。在OOA方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型。

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

类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等。

3.软件设计

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

在SD中，需要遵循一个基本的原则：高内聚，低耦合。内聚表示模块内部各成分之间的联系程度，是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做目标单一的一件事情；耦合表示模块之间联系的程度。紧密耦合表示模块之间联系非常强，松散耦合表示模块之间联系比较弱，非耦合则表示模块之间无任何联系，是完全独立的。

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

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

4.软件实现

软件实现包括：软件配置、软件编码、软件测试。

软件配置管理通过标识产品的组成元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的演进和完整性。软件配置管理活动包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付等活动。

5.部署交付

软件部署与交付是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。

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

持续交付具备的优势主要包括：
●持续交付能够有效缩短提交代码到正式部署上线的时间，降低部署风险：
●持续交付能够自动、快速地提供反馈，及时发现和修复缺陷：
●持续交付让软件在整个生命周期内都处于可部署的状态；
●持续交付能够简化部署步骤，使软件版本更加清晰；
●持续交付能够让交付过程成为一种可靠的、可预期的、可视化的过程。
在评价互联网公司的软件交付能力的时候，通常会使用两个指标：
●仅涉及一行代码的改动需要花费多少时间才能部署上线，这也是核心指标：
●开发团队是否在以一种可重复、可靠的方式执行软件交付。

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

容器技术目前是部署中最流行的技术，常用的持续部署方案有Kubernetes+Docker和Matrix系统两种。

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

完整的镜像部署包括三个环节：Build—Ship—Run。

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

不可变服务器是一种部署模式，是指除了更新和安装补丁程序以外，不对服务器进行任何更改。

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

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

6.过程管理

软件过程能力是组织基于软件过程、技术、资源和人员能力达成业务目标的综合能力。包括治理能力、开发与交付能力、管理与支持能力、组织管理能力等方面。

按照软件过程能力的成熟度水平由低到高演进发展的形势，CSMM定义了5个等级：初始级（软件过程和结果具有不确定性）、项目规范级（项目基本可按计划
实现预期的结果）、组织改进级（在组织范围内能够稳定地实现预期的项目目标）、量化提升级（在组织范围内能够量化地管理和实现预期的组织和项目目标）、创新引领级（通过技术和管理的创新，实现组织业务目标的持续提升，引领行业发展）。