【软考——系统架构师】系统开发基础知识-Toy模板网

这篇具有很好参考价值的文章主要介绍了【软考——系统架构师】系统开发基础知识。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

软考系统架构师,软考,系统架构,架构
🔎这里是【软考——系统架构师】，关注我考试轻松过线 👍如果对你有帮助，给博主一个免费的点赞以示鼓励
欢迎各位🔎点赞👍评论收藏⭐️

软考系统架构师,软考,系统架构,架构

👀软件开发方法

软件开发生命周期
1、需求规格说明书包括系统名称、功能描述、接口、基本数据结构、性能、设计需求、开发标准、验收原则等。
2、概要设计定义功能模块及功能模块之间的关系，详细设计研究模块内部，包括算法与数据结构、数据分布、数据组织、模块间信息接口和用户界面等设计。
3、测试分为单元测试、集成测试、确认测试和系统测试。
软件开发模型
1、瀑布模型严格按照软件生命周期的各阶段顺序执行，有利于人员的组织管理，但明显存在使用缺陷：用户并不能清晰定义及描述其需求、初始版本的呈现周期较长。
2、原型模型的原理即提前通过可视化的方式呈现需求，因此原型获取的三种途径一般为：
（1）利用模拟软件系统的人机界面和人机交互方式
（2）真正开发一个原型
（3）寻求一个或几个类似的软件
3、螺旋模型实在快速原型的基础上扩展的，支持大型软件开发，适用于面向规格说明、面向过程和面向对象的软件开发方法，通常将软件开发切割为多个周期，每个周期由 4 个阶段组成：
（1）目标设定
（2）风险分析
（3）开发和有效性验证
（4）评审
4、基于四代技术的模型，只侧重于支持软件的设计和实现阶段，并不支持全过程，其主要特征：
（1）非过程化语言：可通过生成器代替编程语言
（2）与数据库密切相关
敏捷方法
1、敏捷方法的特点
（1）强调“适应性”而非“预设性”
（2）强调“面向人的”而非“面向过程的”
2、敏捷方法的核心思想
（1）敏捷方法是适应型，而非可预测性
（2）敏捷方法是以人为本，而非以过程为本
（3）迭代增量式的开发过程
3、敏捷方法的主要内容
（1）4 个核心价值观
a、沟通：设计者、开发者和客户之间
b、简单：满足当前需求，代码简单化
c、反馈
d、勇气
（2）12 条过程实践原则：简单设计、测试驱动、代码重构、结对编程、持续集成、现场客户、发行版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40 小时工作机制。
RUP
1、RUP 的 9 个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与管理、项目管理和环境。
2、RUP 的 4 个阶段：初始、细化、构造和移交.
3、RUP 的特点
（1）用例驱动
（2）以体系结构为中心
a、体系结构的设计与代码设计无关，不依赖于程序语言
b、体系结构层次的设计问题包括系统的总体组织和全局控制、通讯协议、同步、数据存取、
给设计元素分配特定功能、设计元素的组织、物理分布、系统的伸缩性和性能。
（3）迭代与增量
4、“4+1”视图模型中不同人员对于视图的关注重点不同，如下表

视图名称	关注点
逻辑视图	描述系统功能，最终用户关注
实现视图	描述系统配置、装配，程序员关注
进程视图	描述系统性能、吞吐，集成人员关注
部署视图	描述系统安装、拓扑结构，系统工程师关注
用例视图	描述人机互动的系统行为，分析人员和测试人员关注

5、RUP 是一个通用的过程模板，包括开发指南、开发过程产物及过程中的角色说明，可用于
各类项目，因体系庞大，需要针对具体实例进行适当裁剪。
6、RUP 裁剪步骤
（1）确定开发过程涉及的工作流
（2）确定工作流的产出
（3）确定 4 阶段间的演进
（4）确定每个阶段的迭代计划
（5）规划工作流内部结构（难点）
软件系统工具
1、软件开发工具的衡量因素：功能、易用性、稳健性、硬件要求和性能、服务和支持
2、软件开发工具包括需求分析工具、设计工具、编码与排错工具、测试工具等。

👀需求管理

1、软件需求开发文档批准后，确立开发的需求基线。
2、需求管理的主要活动包括：变更控制、版本控制、需求跟踪、需求状态跟踪。
需求管理原则
1、CMM 模型第 2 级关键过程域增加需求管理，目标：
（1）为软件需求建立基线
（2）软件计划、产品和活动与软件需求保持一致
需求规格说明的版本控制
1、版本控制信息应包括变更内容、日期、变更人员及变更原因。
需求属性
1、需求属性包括：创建时间、版本号、创建人、批准人、状态、原因和依据、涉及子系统、
涉及产品版本号、验收/接受的标准、优先级、稳定性。
需求变更
1、为严格控制软件项目，需要确保：
（1）评估已提出的变更
（2）适当的人选评估和决策变更
（3）变更应及时通知所有人
（4）需求变更需要遵循一定程序
2、需求变更管理的目的是将变更产生的负面影响降到最低，过程包括：
（1）问题分析和变更描述
（2）变更分析和成本计算
（3）变更实现
3、需求变更应遵循的原则
（1）必须遵循变更控制程序
（2）变更未经批准不得实施
（3）变更应有变更控制委员会进行评估和决策
（4）项目干系人有权获悉变更信息
（5）变更库中的原始文档不得更改或删除
（6）变更的实施均应可追溯到已批准的变更请求
4、变更控制委员会的总则/章程应包括变更控制委员会的目的、授权范围、成员构成、决策
流程及操作步骤。
需求跟踪
1、需求跟踪链（traceability link）类型
（1）客户需求向前追溯到软件需求（需求变更更新至需求规格说明书中）
（2）从软件需求回溯相应的客户需求（确认每个需求的源头）
（3）从软件需求向前追溯到下一级工作产品（逐步确保最终产品满足需求）
（4）从产品部件回溯到软件需求（验证部件来源于）
需求变更的代价和风险
1、变更只能在项目时间、预算、资源等的限制允许范围内进行协商。
2、进行影响分析的能力依赖于跟踪能力、数据的质量和完整性。

👀开发管理

1、范围定义的输入包括：项目章程（初始的范围说明书）、项目范围管理计划、组织过程资
产（过程性成果）、批准的变更申请。
2、时间管理的过程包括：活动定义（WBS）、活动排序、活动资源估算、活动历时估算、制定
进度计划以及进度控制。
3、成本管理活动包括：成本估算、成本预算（基线）、成本控制。
配置管理、文档管理
1、产品配置是指一个产品在其生命周期各个阶段所产生的各种形式（机器可读或人工可读）
和各种版本的文档、计算机程序、部件及数据的集合，构成集合的元素称为配置项。
2、配置项的分类：
（1）产品的工作成果，包括产品本身的文档
（2）管理等过程中产生的文档
3、配置项的属性：名称、标识符、文件状态、版本、作者和日期等
4、文档分类
（1）用户文档，包括功能描述、安装文档、使用手册、参考手册、操作员指南。
（2）系统文档，和系统实现有关的文档。
软件开发的质量与风险
1、质量和等级的关系：质量是需求/要求的满足程度，等级是产品或服务的类别。
2、风险的必要条件：与损失或收益相关、存在偶然性或不确定性、需要抉择。

👀设计方法

结构化分析与设计
1、结构程序设计理论基础中三种基本控制构件包括：顺序、分支、循环。
面向对象的分析设计
1、面向对象的分析模型构成包括：顶层架构图、用例与用例图、领域概念模型。
2、面向对象的设计模型包括：软件体系结构图、用例实现图、类图、状态图、活动图等。
3、从分析到设计的步骤：
（1）根据用例设计实现方案（UML）
（2）设计技术支撑设施（非功能性公共支撑件）
（3）设计用户界面（类图）

👀软件的重用

1、重用/复用的软件元素（软部件）：需求分析文档、设计过程、设计文档、程序代码、测试用例和领域知识等。
2、软件重用的分类

名称	对象	举例
横向重用	不同应用领域中的软件元素	标准函数库
纵向重用	共性应用领域间的软部件

3、软件重用的优势：提高生产率、降低开发成本、缩短开发周期、改善软件质量、提高灵活性和标准化程度。

👀逆向工程与重构工程

1、基本概念：通过分析已有的程序寻求比源代码更高级的抽象表现形式（比如文档）的活动就是逆向工程，是在不同抽象层级中进行的溯源行为，而重构工程则是在同一抽象层级中转换系统描述的活动。逆向工程得出的设计称之为设计恢复，设计恢复不一定能够抽象还原到原设计；对逆向工程所形成的系统进行修改或重构，生成的新版本称为重构工程。
2、逆向工程信息恢复的级别

级别	内容	抽象级别	逆向工程恢复难度	工具支持可能性	人工参与程度
实现级	语法树、符号	递增	递增	递减	递增
结构级	程序间的关系，如视图	递增	递增	递减	递增
功能级	功能和程序段之间的关系	递增	递增	递减	递增
领域级	实体与应用域之间的关系	递增	递增	递减	递增
领域级	实体与应用域之间的关系	递增	递增	递减	递增

3、逆向工程信息恢复的方法

名称	适用级别	具体方法
用户指导下的搜索与变换法	实现级、结构级	通过查询语句及输出进行恢复
变换式方法	除领域级	自动分析法及基于特定库的用户指导变换法
基于领域知识的恢复法	功能级、领域级	一般用规则库表示，不确定性最大
铅板恢复法	实现级、结构级	识别公共构