分析与设计规程.docVIP

密级：机密 文件编号： 分析与设计规程 版本：0.0.0-1.0 文件修改控制 修改编号 版本 修改条款及内容 修改日期 1 0.0.0-1.0.0 新建 目录 TOC \o 1-3 1. 概述 1 1.1 目的 1 1.2 角色职责 1 1.3 入口标准 1 1.4 输入 1 1.5 输出 1 1.6 出口标准 2 2. 流程 3 2.1 系统设计 3 2.1.1 业务分析 3 2.1.2 系统定位分析 3 2.1.3 产品/产品构件分解 3 2.1.4 分配产品/产品构件需求 3 2.1.5 确定技术架构 4 2.1.6 架构决策 4 2.2 概要设计 4 2.2.1 主要用例/业务流程说明 4 2.2.2 技术路线分析 4 2.2.3 设计产品/产品构件的逻辑结构 4 2.2.4 设计进程（运行时体系）结构 5 2.2.5 设计部署结构 6 2.2.6 设计实现模型 6 2.2.7 考虑非功能性需求 6 2.2.8 设计数据库 6 2.3 详细设计 7 2.3.1 用户界面设计 7 2.3.2 用例设计 8 2.3.3 子系统/模块设计 8 2.3.4 类设计 8 分析与设计规程 版本：0.0.0-1.0.0 第 PAGE 2页 概述 目的 本文的目的是描述项目中与分析设计相关的活动，指导设计师将软件需求转变为设计文档。 角色职责 架构师：负责系统的整体分析与设计，编写“系统设计报告”； 设计师：负责概要设计，编写“概要设计报告”和“数据库设计报告”； 软件工程师：进行详细设计，编写“详细设计报告”和“用户界面设计报告”； 系统工程师：对设计师提供技术支持。 入口标准 前景、业务建模报告已通过评审。 软件需求规约已通过评审（针对于概要设计和详细设计活动）。 输入 前景 业务建模报告 软件需求规约 输出 系统设计报告 概要设计报告 数据库设计报告 详细设计报告 界面设计报告 更新后的RTM 出口标准 所有的输出文档通过了评审。 所有输出文档进行了恰当的配置管理。 分析与设计规程 版本：0.0.0-1.0.0 第 PAGE 9页 流程 系统设计 系统设计的目的是针对于用户需求提出相应的解决方案，将系统分解为产品或产品构件，将用户需求分解到产品需求，并描述产品/产品构件间的关系，同时记录分析过程中的重要决策。系统设计主要解决系统（产品）间的关系。架构师将以下活动的结果记录到“系统设计报告”并更新RTM。 业务分析 根据“业务建模报告”，分析目标系统所涉及到的业务范围，包括组织机构、部门及相互间的关系，描述主要的业务流程或场景。 说明业务部门之间的主要接口关系。 系统定位分析 从业务分析出发，找出目标系统与周边其它系统的关系，说明系统的范围，及目标系统与周边其它系统的接口。 分析目标系统与其它系统的关系 从业务分析出发，找出目标系统与周边其它系统的关系，说明系统的范围，及目标系统与周边其它系统的接口。 说明目标系统的逻辑结构 从逻辑、概念的层次描述系统的结构，为下面的产品/产品构件分解提供依据。 产品/产品构件分解 将目标系统分解成实际的产品/产品构件。 通过图示说明这些产品/产品构件如何相互配合来实现业务的主要流程和场景。 分配产品/产品构件需求 分配产品/产品构件需求 分别说明构件所要满足的功能和非功能需求，将用户需求分解到产品需求。 确定构件的选择 说明该构件是复用、购买还是自制以及选择的理由。 确定技术架构 说明目标系统所采用的技术选择，所采用的技术能够使多个产品/产品构件协调工作，并满足用户关于系统质量等方面的非功能性需求。相关的技术可能有平台框架，分层技术，数据同步，接口通信，安全，可靠性考虑，多应用整合，SSO等等。 架构决策 架构师应记录在系统分析与设计过程中的一些重要决策，如产品/产品构件的选择，复用/自制的选择，技术方案的选择等，说明决策的背景、可供选择的方案及选择的结果和理由，并记录在“系统设计报告”中。 概要设计 概要设计针对于系统设计中所识别出的需要自制的产品/产品构件进行设计，其主要目的是将产品/产品构件分解为子系统或模块并明确相互间的接口，识别出主要的设计元素，为详细设计提供依据。以下活动除数据库设计外，其它活动的结果记入“概要设计报告”，同时更新RTM。 主要用例/业务流程说明 说明该产品/产品构件所要实现的核心用例/业务流程，概要设计将围绕这些用例/业务