【软考架构】2025系统架构设计师开坑指南——后端开发（科目选择，考试大纲，真题分析）

【软考架构】2025系统架构设计师开坑指南——后端开发（科目选择，考试大纲，真题分析）

1、考试介绍（后端/前端/运维/网络/项目）

背景：

• 自从好多年前考了中级之后，就一直想集邮集个高级的，集到了就是终生且永久的。
  但是无奈中级水到可以裸考，高级确总有一种比较麻烦的感觉，尤其是论文，尤其是对于没时间复习，常年不写字的人来说，更加是这样。
• 主要还是学点东西，学东西是目标，考试只是顺带的，架构、运维、高项都是很有用的东西~
  当年还是笔试的时候几乎没有太多信心，所以复习过一阵子据说资料最全，最简单的高项，报了几次但是因为没有时间，最终一次都没去考过。事实上高项背的东西很多，而作为后端开发本身，最近突然看到职业通道相关的原来一直都是另一门课程，所以想着再去玩一下。
• 技术经历
  1、后台方向，全栈开发、应用开发，web开发、前端开发 vue、后端开发 ts，python、大数据开发 spark
  2、后台方向，后端开发 goland、计算虚拟化 kvm、云原生 k8s、云计算 公有云 运维ansible、算法llm nvlink torch

1.1 考试时间

• 每年有2次，上半年和下半年。
  2025.10月报名，2025.11月考试

• 2025上半年场
  2025.03报名，2025.05考试这场已经来不及了（只能下半年再来了）
  

1.2 科目选择

• 系统架构工程师 System Architect Engineer
  站点运维工程师 Site Reliability Engineering
• 高级五大科目选择
  信息系统项目管理师=>项目管理，PM
  系统架构设计师=》后端
  系统分析师=》前端
  网络规划设计师=》网络
  系统规划与管理师=》运维
  

1.3 有啥好处

2、考试大纲（系统架构-后端）

架构师技术图谱包括：
编程语言、前端、框架、微服务、分布式、存储、大数据、推荐系统、消息队列、设计模式、重构、集群等内容。1

考试说明

• 考试目标：
  考试合格人员应能够根据系统需求规格说明书，结合应用领域和技术发展的实际情况，考虑有关约束条件，设计正确、合理的软件架构，确保系统架构具有良好的特性；
  能够对项目系统架构进行描述、分析、设计与评估；能够按照相关标准编写相应的设计文档；
  能够与系统分析师、项目管理师相互协作、配合工作；具有高级工程师的实际工作能力和业务水平。
• 考试要求：
  （1）掌握计算机硬软件与网络的基础知识；
  （2）熟悉信息系统开发过程；
  （3）理解信息系统开发标准、常用信息技术标准；
  （4）熟悉主流的中间件和应用服务器平台；
  （5）掌握软件系统建模、系统架构设计基本技术；
  （6）熟练掌握信息安全技术、安全策略、安全管理知识；
  （7）了解信息化、信息技术有关法律、法规的基础知识；
  （8）了解用户的行业特点，并根据行业特点架构合适的系统设计；
  （9）掌握应用的数学基础知识
  （10）熟练阅读和正确理解相关领域的英文文献；
• 科目设计
  （1）信息系统综合知识，考试时间为 150分钟，笔试，选择题；
  （2）系统架构设计案例分析，考试时间为 90分钟，笔试，问答题；
  （3）系统架构设计论文，考试时间为 120分钟，笔试，论文题。

科目1：信息系统综合知识

• 1.计算机软件与网络基础知识
  1.1 操作系统
  操作系统的类型和结构
  操作系统基本原理
  网络操作系统及网络管理
  嵌入式操作系统与实时操作系统
  1.2 数据库系统
  数据库管理系统的类型、结构和性能评价
  常用的关系型数据库管理系统
  数据库模式
  数据库规范化
  分布式数据库系统，并行数据库系统
  数据仓库与数据挖掘技术
  数据库工程
  备份恢复
  1.3嵌入式系统
  嵌入式系统的特点
  嵌入式系统的硬件组成与设计
  嵌入式系统应用软件及开发平台
  嵌入式系统网络
  嵌入式系统数据库
  1.4数据通信与计算机网络
  数据通信的基本知识
  开放系统互连参考模型
  常用的协议标准
  网络互连与常用网络设备
  计算机网络的分类与应用
  1.5多媒体
  多媒体的类型、特点及数据格式
  多媒体数据的压缩编码
  1.6系统配置与性能评价
  多层结构、分布式系统
  系统配置方法（双份、双重、热备份、容错、集群）
  性能计算（响应时间、吞吐量、TAT）
  性能设计（系统调整、Amdahl解决方案、响应特性、负载均衡）
  性能指标（SPEC-Int、SPEC-Fp、TPC、Gibsonmix、响应时间）
  性能评估
• 2.信息化基础知识
  2.1信息系统工程总体规划
  总体规划目标、范围
  总体规划的方法论
  信息系统的组成
  信息系统的实现
  2.2政府信息化与电子政务
  电子政务的概念、内容和技术形式
  中国政府信息化的策略和历程
  电子政务建设的过程模式和技术模式
  2.3企业信息化与电子商务
  企业信息化的概念、目的、规划、方法
  ERP的主要模块和主要算法
  企业业务流程重组（BPR）
  CRM、PDM在企业的应用
  知识管理
  企业应用集成
  全程供应链管理的思想
  商业智能
  电子商务的类型、标准
  2.4信息资源管理
  2.5国际和国内有关信息化的标准、法律和规定
• 3.系统开发基础知识
  3.1开发管理
  项目的范围、时间、成本
  文档管理工作、配置管理
  软件开发的质量与风险
  软件的运行与评价
  3.2需求管理
  需求变更
  需求跟踪
  需求变更风险管理
  3.3软件开发方法
  软件开发生命周期
  软件开发模型（瀑布模型、演化模型、增量模型、螺旋模型、原型，构件组装
  模型、RUP，敏捷方法）
  构件与软件重用
  逆向工程
  形式化方法
  3.4软件开发环境与工具
  集成开发环境
  开发工具（建模工具、分析设计工具、编程工具、测试工具、项目管理工具等）
  3.5设计方法
  分析设计图示（DFD、ERD、UML、流程图、NS图、PAD）
  结构化分析与设计
  模块设计
  面向对象的分析与设计
  I/O设计、人机界面设计
  设计模式
  3.6基于构件的开发
  构件的概念与分类
  中间件技术
  典型应用架构（J2EE、.NET）
  3.7应用系统构建
  应用系统设计与开发（分析与设计方法的使用、外部设计、内部设计、程序设 计、测试）
  软件包的使用（开发工具、运行管理工具、业务处理工具、 ERP、群件、OA 工具）
  3.8测试与评审
  测试评审方法
  验证与确认（V&V）
  测试自动化
  测试设计和管理方法
• 4.软件架构基础知识
  软件架构的概念
  软件架构的风格
  特定领域软件架构
  基于架构的软件开发方法
  软件架构评估
  软件产品线
  设计模式
• 5.安全性与可靠性技术
  5.1信息安全与保密
  加密和解密
  身份认证（数字签名、密钥、口令）
  访问控制
  安全保密管理（防泄漏、数字水印）
  安全协议（SSL、PGP、IPSec）
  系统备份与恢复
  防治病毒
  5.2系统可靠性
  可靠性设计（容错技术、避错技术）
  可靠性指标与评估
  5.3安全性规章与保护私有信息规则
  信息系统安全法规与制度
  计算机防病毒制度
  保护私有信息规则
• 6.标准化与知识产权
  标准化意识，标准化的发展，标准的的生命周期
  国际标准、美国标准、国家标准、行业标准、地方标准、企业标准
  代码标准、文件格式标准、安全标准、软件开发规范和文档标准
  标准化机构
  知识产权
• 7.应用数据
  概率统计应用
  图论应用
  组合分析
  算法（数值算法与非数值算法）的选择与应用
  运筹方法（网络计划技术、线性规划、预测、决策、库存管理、模拟）
  数学建模
• 8.专业英语
  具有高级工程师所要求的英文阅读水平
  掌握本领域的英语术语

考试科目 2：系统架构设计案例分析

• 1.系统规划
  系统项目的提出与可行性分析
  系统方案的制定、评价和改进
  新旧系统的分析和比较
  现有软件、硬件和数据资源的有效利用
• 2.软件架构设计
  软件架构设计
  XML技术
  基于架构的软件开发过程
  软件质量属性
  架构模型（风格）
  特定领域软件架构
  基于架构的软件开发方法
  架构评估
  系统演化
• 3.设计模式
  设计模式的概念
  设计模式的组成
  模式和软件架构
  设计模式分类
  设计模式的实现
• 4.系统设计
  处理流程设计
  人机界面设计
  文件设计、存储设计
  数据库设计
  网络应用系统的设计
  系统运行环境的集成与设计
  中间件、应用服务器
  性能设计与性能评估
  系统转换计划
• 5.软件系统建模
  系统需求
  建模的作用和意义
  定义问题（目标、功能、性能等）与归结模型（静态结构模型、动态行为模型、 物理模型）
  结构化系统建模、数据流图
  面向对象系统建模
  统一建模语言（UML）
  数据库建模、E-R图
  逆向工程
• 6.分布式系统设计
  分布式通信协议的设计
  基于对象的分布式系统设计
  基于Web的分布式系统设计
  基于消息和协同的分布式系统设计
  异构分布式系统的互操作性设计
• 7.嵌入式系统设计
  实时系统和嵌入式系统特征
  实时任务调度和多任务设计
  中断处理和异常处理
  嵌入式系统开发设计
• 8.系统的可靠性分析与设计
  系统的故障模型和可靠性模型
  系统的可靠性分析和可靠度计算
  提高系统可靠性的措施
  系统的故障对策和系统的备份与恢复
• 9.系统的安全性和保密性设计
  系统的访问控制技术
  数据的完整性
  数据与文件的加密
  通信的安全性
  系统的安全性设计

考试科目 3：系统架构设计论文

• 根据给出的系统架构设计有关的若干个专题，选择其中一个专题，按照规定的要求撰写论文。
• 1.系统建模
  定义问题与归结模型
  结构化系统建模
  面向对象系统建模
  数据库建模
• 2.软件架构设计
  软件架构设计
  特定领域软件架构
  基于架构的软件开发方法
  软件演化
• 3.系统设计
  处理流程设计
  系统人机界面设计
  文件设计、存储设计
  数据库设计
  网络应用系统的设计
  系统运行环境的集成与设计
  系统性能设计
  中间件、应用服务器
• 4.分布式系统设计
  分布式通信协议的设计
  基于对象的分布式系统设计
  基于 Web的分布式系统设计
  基于消息和协同的分布式系统设计
  异构分布式系统的互操作性设计
• 5.系统的可靠性分析与设计
  系统的故障模型和可靠性模型
  提高系统可靠性的措施
  系统的故障对策和系统的备份与恢复
• 6.系统的安全性和保密性设计
  系统的访问控制技术
  数据的完整性
  数据与文件的加密
  通信的安全性
  系统的安全性设计

3、真题分析（附2024真题，以论文为例）

3.1 试卷结构和备考策略

1、试卷结构

• 综合知识：每题1分，45/75题， 45/75分，2小时
• 案例分析：每题25分，5选3题，45/75分，2小时，合并4小时1门
• 论文写作：每题75分，4选1题，2小时，必考软件架构
  
  

3.2 综合知识和案例分析

答题技巧

• 第一题必做，先做完第一题。对于四选二，快速浏览所有题目问题和问题描述，是否能看懂，再进行选题。
• 问题与题目描述相结合，尤其是遇到系统分析和设计以及新技术等问题，答案一般都在题目描述里，从题目描述里抽象总结出问题答案即可。
• 列条目回答问题，把自己认为对的都写上，多写不会扣分，少写一定会扣分。
• 若遇到新的知识点，没关系，要稳住心态。能避开则避开，否则就理解所问问题的倾向性，顺势答题即可

软件架构设计（T1）

• 主要考査质量属性、软件架构风格、软件架构评估、MVC 架构、面向服务的架构 SOA 等知识。
  对于其他未考査的架构领域重点知识如 DSSA、ABSD 等。

• 1、质量属性效用树、质量属性判断
  在架构评估过程中，所普遍关注的质量属性有以下几种。
  (1)性能: 指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。
  设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
  (2)可靠性: 是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性通常用平均失效等待时间(Mean Time ToFailure，MTTF)和平均失效间隔时间(Mean Time Between Failure，MTBF)来衡量。在失效率为常数和修复时间很短的情况下MTTF 和 MTBF 几乎相等。可分为容错和健壮性。容错是指在错误发生时确保系统正确的行为，并进行内部“修复”。健壮性是指系统不受错误使用和错误输入的影响，按既定程序忽略错误。设计策略:冗余、心跳、选举、Ping/Echo。
  (3)可用性:是系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略:冗余、心跳、选举、Ping/Echo。
  (4)安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服。
  (5)可修改性:是指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价来衡量可修改性。可分为可维护性、可扩展性、结构重组和可移植性。
  可维护性:在错误发生后“修复”软件系统的难易程度
  可扩展性:软件因适应新需求或需求变化而增加新功能的能力。
  结构重组:重新组织软件系统的构件及构件之间的关系。
  可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
  设计策略:接口-实现分类、抽象、信息隐藏。
  (6)功能性:是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
  (7)可变性:指架构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时，可变性是很重要的。
  (8)互操作性:作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件架构。
  质量属性效用树
  ATAM 方法采用效用树(Utility tree) 这一工具来对质量属性进行分类和优先级排序。效用树的结构包括:
  树根–质量属性–属性分类-质量属性场景(叶子节点)。
  ATAM 主要关注4类质量属性:性能、安全性、可修改性和可用性，这是因为这4个质量属性是利益相关者最为关心的。
  

• 2、软件架构风格
  软件架构风格是描述某一特定应用领域中，系统组织方式的惯用模式。
  架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
  敏感点和权衡点:
  敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
  权衡点 是影响多个质量属性的特性，是多个质量属性的敏感点。
  架构风险: 是指架构设计中潜在的、存在问题的架构决策所带来的隐患
  风险点与非风险点: 不是以标准专业术语形式出现的，只是一个常规概念，即可能引起风险的因素，可称为风险点。 某个做法如果有隐患，有可能导致一些问题，则为风险点:而如果某件事是可行的可接受的，则为非风险点。
  架构含义与风格对比
  
  

• 3、MVC 架构
  MVC 强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了模型、视图、控制器三个核心模块。
  (1)模型(Model):是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。
  (2)视图(View):是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。
  (3)控制器(Controller):是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

• 4、J2EE 架构
  四层结构:
  1、客户层组件 :J2EE 应用程序可以是基于 Web 方式的,也可以是基于传统方式的、静态的 HTMI(标准通用标记语言下的一个应用)页面和 Applets(客户层组件)。
  2、Web 层组件:J2EE Web 层组件可以是 JSP 页面或 Servlet。
  3、业务层组件:业务层代码的逻辑用来满足特定领域的业务逻辑处理。
  4、信息系统层: 企业信息系统层处理企业信息系统软件包括企业基础建设系统，例如企业资源计划(ERP)、大型机事务处理、数据库系统和其它的遗留信息系统。例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统。
  JSP+Servlet+JavaBean+DAO
  JSP:用于显示、收集数据的部分。作为 MVC 中的视图 V。
  Servlet: 作为业务逻辑层,用于处理复杂的业务逻辑,如验证数据、实例化 JavaBcan、调用 DAO连接数据库等。作为 MVC 中的控制器C。在其中会调用 Service 方法处理服务
  JavaBean:用于数据的封装，方便将査询结果在 Servlet 与 JSP 页面之间进行传递等。
  DAO:用于连接数据库及进行数据库的操作如:查询、删除、更改等。

• 5、面向服务架构SOA
  SOA 是一种设计理念，其中包含多个服务,服务之间通过相互依赖最终提供一系列完整的功能。
  各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。

• 6、企业服务总线ESB
  简单来说是一根管道，用来连接各个服务节点。ESB 的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。
  ESB 的特点:
  (1)SOA的一种实现方式，ESB 在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合;
  (2)描述服务的元数据和服务注册管理:
  (3)在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等;
  (4)发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。
  ESB 的主要功能:①服务位置透明性;②传输协议转换;③消息格式转换;④消息路由;⑤消息增强;⑥安全性;⑦监控与管理。

• SOA和微服务的区别
  （1）SOA：
  依赖企业服务总线（ESB）进行服务间通信，ESB负责消息路由、转换和协调。
  常用SOAP等重量级协议，强调标准化。
  倾向于共享数据库，服务通过ESB访问中心化数据源。
  强调数据一致性（如通过分布式事务）
  服务通常部署在应用服务器（如WebLogic、WebSphere）上，更新可能影响整个系统。
  扩展需要整体扩容（如扩展ESB）。
  企业级技术栈（如Java EE、XML），团队按职能划分（开发、测试、运维）。
  企业内系统整合（如银行核心系统对接 legacy 系统）
  需要严格标准化和中央控制的场景。
  （2）微服务：
  服务间通过轻量级协议（如HTTP/REST、gRPC）直接通信。
  可能使用消息队列（如Kafka）或服务网格（如Istio）简化通信。
  每个服务拥有独立数据库（Database per Service），避免共享数据存储。
  通过最终一致性（如Saga模式）处理跨服务数据同步。
  独立部署：每个服务可单独部署，通常容器化（如Docker+Kubernetes）。
  弹性扩展：仅扩展需要高负载的服务（如“购物车服务”独立扩容）。
  语言支持（如Go、Node.js、Python），团队按服务划分（全功能小团队）
  高并发互联网应用（如电商平台、社交网络）。
  需要快速迭代和弹性扩展的场景。

3.3 论文写作

八大架构： 教材下篇的章节目录，分别是:

• 层次式架构
  层次式体系结构设计是将系统组成一个层次结构，每一层为上层服务，并作为下层客户。
  软件层次式体系结构是最通用的架构,也被叫作 N层架构模式。大部分的应用会分成表现层(或称为展示层)、中间层(或称为业务层)、数据访问层(或称为持久层)和数据层。
  

• 云原生架构
  云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
  

• 面向服务架构
  SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。
  在 SOA 中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
  SOA 并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。
  

• 大数据架构
  （数据流动图）
  大数据平台本质上就是对海量数据从采集、存储、计算、应用、管理、运维的多方位、多维度的组合研究设计，从而建设合理、高效的大数据平台架构。

• 信息系统架构
  （感觉和层次差不多）
  信息系统架构是系统的抽象，描述元素、属性及关系，包括物理和逻辑结构。常用架构模型有单机、C/S、SOA等。TOGAF是架构框架标准，通过六个组件支持企业。

• 安全架构
  （网络隔离架构）
  全架构是计划和设计组织的、概念的、逻辑的、物理的组件的规程和相关过程，这些组件以一致的方式进行交互，并与业务需求相适应，以达到和维护一种安全相关风险可被管理的状态

• 嵌入式系统架构
  （硬件通信架构）
  嵌入式系统架构是一种专为特定功能或任务设计的计算系统，它通常包含微处理器或微控制器、内存、输入/输出设备和软件。

• 通信系统架构
  （网络通信架构）
  通信系统网络架构 单核心网的特点， 核心交换设备通常采用二层、三层及以上交换机，如采用三层以上交换机可划分成VLAN，VLAN内采用二层数据链路转发，VLAN

• 系统分析
  风险治理系统，大数据系统，支付系统
  终端信息管理系统，资产管理系统，设备管理系统
  安全监管系统，漏洞挖掘系统，生产经营管理系统，零售系统

论文写作介绍:
考试时间:下午 14:30-16:30;考试时长:120分钟。
考试题目: 四选一，必有1题考查软件架构，每道题会有相关概述和子题目，要仔细审题
考试形式:机试，约 2500字。

论文题目类型:
1、软件架构，自从 2020 年以来，更偏向于考査具体的架构，而不是之前的宏观上的架构风格、架构评估等内容。尤其喜欢考查改版后的八大架构，如云原生、微服务、安全架构等。
2、系统开发，这块也是每年必考，软件工程全生命周期都有可能考查，而且也是更具体，比如具体的开发方法、开发模型，以及需求分析、设计、测试、运维等全过程。
3、系统可靠性、安全性、容错技术等。
4、企业应用集成、企业集成平台等
5、其他:项目管理、数据库等。

历年真题

写作原则

• 基本原则:
  不能口语化、每段不宜太长;
  字数一般在 300+2200 左右，机试时有实时字数统计，多注意把握;
  写正文时，不要生硬的回答问题，要根据问题要点组合成一篇通顺的文章;
  论点分开论述，没必要全写编号。

• 其他原则:
  提前准备好自己要写的项目，必须是近三年的中大型商业项目;
  不要猜题，要复用构件(摘要+项目背景+结尾)，不要整篇复用;
  不要直接抄范文，要选择适合自己的范文进行范文修改，改写成属于自己的论文;
  练习论文主题时发现有不会的知识点，一定要全部背会;
  站在系统架构设计师的角度看待项目，技术细节适中，理论联系实际;
  不同角度看论文，以论文写作技巧课程为依据，对自己的论文进行自评;
  最后，要勇于迈出第一步，万事开头难，坚持写完第一篇，之后越写越容易。

• 论文字数范围，各部分字数如何分配?
  建议摘要 300 字左右，正文 2000-2700 字之间，建议 2200 字;
  具体建议:摘要 300 字+项目背景 500 字+正文主体 1200 字+结尾 500 字。

• 结尾
  如某年某月，公司要做什么项目，任命我为系统架构设计师，最后收尾仍然要写客户一致满意，切记。

• 项目背景
  使用离考试三年内，持续时间6个月以上，并且已完成的项目;如果项目真的比较久远，或者持续时间较短，但是规模却是足够的，那么可以根据实际情况灵活修改时间。
  关于项目名称: 真实项目名称不需要写，也不能写，只能写某地级市、某医院、某公司等。
  关于项目级别: 建议是省市级、集团级，不要是县级、社区级等。如果你做的项目规模是符合要求的，真的是县级的真实项目，那也没有问题。
  关于项目团队成员:可省略。为了保证真实性，也可以简单带过，例如有需求分析人员3人，开发人员 10 人，测试人员6人等。
  关于项目金额: 要和项目时间还有项目团队成员相对应，如果项目组一共有 30 人，按每人每月 2 w算，一个月需要 60 w，再乘以持续时间(假设为 15 个月)，那么项目金额在 900 w左右是比较合理的，但不要写整数，可以写 869 w、915 w等字眼。
  如果是自己改编的项目，请不要构造太大的项目，项目金额最好在 500 w左右。

• (1)推荐项目
  大型信息系统项目 大企业的 OA、ERP; 大数据、云计算等各种软件及信息系统。
  (2)不能选项目
  小型企业项目:如进销存系统、图书管理系统、单机版系统。
  尚未完成的项目:一定要已经完成并上线运行，并最好是三年内的。
  纯建网站项目:如建设企业或政府门户网站，只有静态网页链接介绍，没有后台大型应用的。
  硬件项目:如综合布线、安防、视频会议等。
  纯技术项目:如数据升级迁移、内部技术研究等。

• 论文摘要
  包含内容:项目名称、项目金额、项目历时、项目简介、我的责任。
  摘要是对论文全文内容的浓缩和精华，通过摘要，可以让读者迅速总揽全文内容。一般的，摘要至少包含三部分内容。
  一是项目背景简介，如时间、项目名称、项目主要内容;
  二是作者角色及工作内容;
  三是项目技术简介，如采用的主要方法、结论和成果。
  摘要字数为 300 左右为宜。
  (1) 本文讨论……系统项目的……(指的是项目主题，例如进度管理等)，
  该系统是由某单位建设的，投资多少，系统是用来做什么的(项目背景，简单功能等)。
  在本文中，首先讨论了……(过程、方法、措施)，最后……(主要是不足之处/如何改进、特色之处、发展趋势等)。
  在本项目的开发过程中，我主要担任了……(在本项目中的角色)。
  (2)根据.….需求(项日背景)，我所在的…….组织了.….项目的开发。该项目.…(项目背景、简单功能介绍)。
  在该项目中，我担任了.…(角色)。我通过采取……(过程、方法、措施等)，使项目圆满成功，得到了用户的一致好评。
  但通过项目的建设，我发现…(主要是不足之处/如何改进、特色之处、发展趋势等)。
  (3)…年…月，我参加了…项目的开发，担任.(角色)。
  该项目投资多少，建设工期是多少,该项目是为了(项目背景、功能介绍)。
  本文结合作者的实践，以…….项目为例，讨论.…(论文主题),包括…(过程、方法、措施)。

• 项目背景
  包括内容:项目开发的原因、岗位职责、项目开发周期及规模、项目功能组成介绍、项目技术(可省略)。
  项目背景，500-600字。
  ①项目由来/缘起/定位/目标，主要介绍项目的前提和诞生的背景等:
  ②)项目主要内容:简要介绍,不是摘要中简单的重复,应比摘要稍详细:
  具体可以参考下述 5w2h框架:
  ·when:何时，近三年项目(体现技术先进性);
  ·where:何地，某省/某市，注意不能实名;
  ●who:甲乙方、作者，甲方名称不能实名，我方称**“我司/我单位|我厂/我公司”**:
  ●why:为何立项，项目建设目的;
  ·what:项目名、项目内容、作者的工作内容;
  ●howmuch:项目预算，不宜太小，不能太大;
  ●how:作者采用的技术/方法;

• 论文正文
  1)理论部分，400~500字
  ①紧扣题干要求:一般是对题干的应答，注意要写成一段:
  ②)逐点回答:分论点的基本概念、基本原理、应用场景、简单举例即可;
  ③惜字如金:注意控制字数，不要挤占实践部分。
  2)实践部分，900~1100字
  ①结构上:与理论部分相呼应对应，最好保持一致
  ②分论点标题:最好拟一个小标题，注意小标题的行文格式
  ③分论点内容:先识别问题，阐述 why;然后分析/设计/解决问题，阐述 how;最后阐述效果

• 论文结尾
  结尾，400-600字。
  获得好评、下一步计划等;
  ①项目效果:呼应论点、上线、稳定运行、
  ②)存在的问题:阐述小问题，且已解决的:注意各部分之间要有过渡，不能太生硬。