主要学习软件工程、数据工程、系统集成和安全工程等内容。根据考试大纲，本小时知识点会涉及单项选择题，按以往全国计算机技术与软件专业技术资格考试的出题规律，约占1~5分。本小时内容属于基础知识范畴，考查的知识点既来源于教材，也有少量扩展内容。本小时的架构如图5-1所示。
信息系统工程是以工程化的原理和思想去管理信息系统项目，以期在有限的成本和资源下取得可预见的项目成果。在早期项目规模不是非常庞大的时候，这套理论发挥了巨大的作用。即使是在今天敏捷、DevOps和微服务开始大行其道的情况下，系统工程理论仍是很多理论的基石。所以学习本小时内容对后面知识的学习有非常重要的作用。
软件工程
定义
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。
组成
软件工程由方法、工具和过程三个部分组成。
架构设计
- 软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。
- 研究软件架构的根本目的是解决软件的复用、质量和维护问题，软件架构设计的一个核心问题是能否达到架构级的软件复用。
- Garlan和Shaw对通用软件架构风格进行了分类:
- 数据流风格。数据流风格包括批处理序列和管道-过滤器两种风格。
- 调用/返回风格。调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
- 独立构件风格。独立构件风格包括进程通信和事件驱动的系统。
- 虚拟机风格。虚拟机风格包括解释器和基于规则的系统。
- 仓库风格。仓库风格包括数据库系统、黑板系统和超文本系统。
- 软件架构评估。
- 软件架构设计是软件开发过程中的关键一步。
- 在架构评估过程中，评估人员所关注的是系统的质量属性。
- 敏感点是一个或多个构件(或之间的关系)的特性。
- 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
需求分析
- 软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
- 软件需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。
- 质量功能部署(QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工作过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
- 需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等
- 常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等
- 一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
- 需求分析的关键在于对问题域的研究与理解。
- 结构化分析(SA)
- 结构化分析有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。
- 在实际工作中，一般使用实体关系图(E-R图)表示数据模型，用数据流图(DFD)表示功能模型，用状态转换图(STD)表示行为模型。
- 面向对象的分析(OOA)。
- OOA的基本任务是运用面向对象的方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。
- OOA模型包括用例模型和分析模型，00A的核心工作是建立系统的用例模型与分析模型。
- 用例是一种描述系统功能需求的方法，使用用例的方法来描述系统功能需求的过程就是用例建模。
- 分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。
- OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和面向对象设计(OOD)的区别所在。OOA的任务是“做什么”，OOD的任务是“怎么做”。
- 在OOA方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。
- 建立分析模型的过程大致包括定义概念类，确定类之间的关系，为类添加职责，建立交互图等，其中有学者将前三个步骤统称为类-责任-协作者(CRC)建模。类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等。
- 需求规格说明书(SRS)编制。SRS是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。
- 需求验证与确认。
- 需求验证与确认主要是针对SRS的正确性，其活动内容包括: a.SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。 b.SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。 c.需求是完整的和高质量的。 d.需求的表示在所有地方都是一致的。 e.需求为继续进行系统设计、实现和测试提供了足够的基础。
- 在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。
