| 文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 | 文件标识： | Company-Project-SD-ARCHITECTURE |
| 当前版本： | X.Y | |
| 作者： | ||
| 完成日期： | Year-Month-Day |
| 版本/状态 | 作者 | 参与者 | 起止日期 | 备注 |
0. 文档介绍
0.1 文档目的
0.2 文档范围
0.3 读者对象
0.4 参考文献
0.5 术语与缩写解释
1. 系统概述
2. 设计约束
3. 设计策略
4. 系统总体结构
5. 子系统N的结构与功能
6. 开发环境的配置
7. 运行环境的配置
8. 测试环境的配置
9. 其它
0.1 文档目的
0.2 文档范围
0.3 读者对象
0.4 参考文献
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符] 作者，文献名称，出版单位（或归属单位），日期
例如：
[AAA] 作者，《立项建议书》，机构名称，日期
[SPP-PROC-SD] SEPG，系统设计规范，机构名称，日期
0.5 术语与缩写解释
| 缩写、术语 | 解 释 |
| SPP | 精简并行过程，Simplified Parallel Process |
| SD | 系统设计，System Design |
| … |
提示：（1）说明本系统“是什么”，（2）描述本系统的主要功能。
2. 设计约束
提示：
（1）需求约束。体系结构设计人员从需求文档（如《用户需求说明书》和《软件需求规格说明书》）中提取需求约束，例如：
本系统应当遵循的标准或规范
软件、硬件环境（包括运行环境和开发环境）的约束
接口/协议的约束
用户界面的约束
软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。
（2）隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。
3. 设计策略
提示：体系结构设计人员根据产品的需求与发展战略，确定设计策略（Design Strategy）。例如：
扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。
复用策略。说明本系统在当前以及将来的复用策略。
折衷策略。说明当两个目标难以同时优化时如何折衷，例如“时－空”效率折衷，复杂性与实用性折衷。
4. 系统总体结构
提示：
（1）将系统分解为若干子系统，绘制物理图和逻辑图，说明各子系统的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解系统。
（3）说明各子系统如何协调工作，从而实现原系统的功能。
5. 子系统N的结构与功能
提示：
（1）将子系统N分解为模块（Module），绘制逻辑图（如果物理图和逻辑图不一样的话，应当绘制物理图），说明各模块的主要功能。
（2）说明“如何”以及“为什么”（how and why）如此分解子系统N。
（3）说明各模块如何协调工作，从而实现子系统N的功能。
6. 开发环境的配置
提示：说明本系统应当在什么样的环境下开发，有什么强制要求和建议？
| 类别 | 标准配置 | 最低配置 |
| 计算机硬件 | ||
| 软件 | ||
| 网络通信 | ||
| 其它 |
提示：说明本系统应当在什么样的环境下运行，有什么强制要求和建议？
| 类别 | 标准配置 | 最低配置 |
| 计算机硬件 | ||
| 软件 | ||
| 网络通信 | ||
| 其它 |
提示：说明本系统应当在什么样的环境下测试，有什么强制要求和建议？
（1）一般地，单元测试、集成测试环境与开发环境相同。
（2）一般地，系统测试、验收测试环境与运行环境相同或相似（更加严格）。
联系客服
