{ 项目名称 } 体系结构设计报告 文件状态: [√] 草稿 [ ] 正式发布 [ ] 正在修改 文件标识: Company-Project-SD-ARCHITECTURE 当前版本: X.Y 作 者: 完成日期: Year-Month-Day 版 本 历 史 版本/状态 作者 参与者 起止日期 备注 目 录 0. 文档介绍 4 0.1 文档目的 4 0.2 文档范围 4 0.3 读者对象 4 0.4 参考文献 4 0.5 术语与缩写解释 4 1. 系统概述 5 2. 设计约束 5 3. 设计策略 5 4. 系统总体结构 5 5. 子系统N的结构与功能 6 6. 开发环境的配置 6 7. 运行环境的配置 6 8. 测试环境的配置 6 9. 其它 6 0. 文档介绍 0.1 文档目的 0.2 文档范围 0.3 读者对象 0.4 参考文献 提示:列出本文档的所有参考文献(可以是非正式出版物),格式如下: [标识符] 作者,文献名称,出版单位(或归属单位),日期 例如: [AAA] 作者,《立项建议书》,机构名称,日期 [SPP-PROC-SD] SEPG,系统设计规范,机构名称,日期 0.5 术语与缩写解释 缩写、术语 解 释 SPP 精简并行过程,Simplified Parallel Process SD 系统设计,System Design … 1. 系统概述 提示:(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. 开发环境的配置 提示:说明本系统应当在什么样的环境下开发,有什么强制要求和建议? 类别 标准配置 最低配置 计算机硬件 软件 网络通信 其它 7. 运行环境的配置 提示:说明本系统应当在什么样的环境下运行,有什么强制要求和建议? 类别 标准配置 最低配置 计算机硬件 软件 网络通信 其它 8. 测试环境的配置 提示:说明本系统应当在什么样的环境下测试,有什么强制要求和建议? (1)一般地,单元测试、集成测试环境与开发环境相同。 (2)一般地,系统测试、验收测试环境与运行环境相同或相似(更加严格)。 9. 其它
62,046
社区成员
669,049
社区内容
加载中
.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。
希望和大家一起共同营造一个活跃、友好的社区氛围。
试试用AI创作助手写篇文章吧