- 无设计文档
- 有设计文档，但形同虚设
- 设计时没有考虑可以重用以前项目或者第三方的代码或组件
- 没有用需求来驱动设计
- 设计没有考虑多过一个的方案
- 没有考虑清楚设计的原则和标准
- 设计的弹性不够、架构落后
- 代码与设计脱节
- 到处都是面条式代码
- 决定的方案缺乏可行性；有些产品不能满足技术性能要求和用户需要
- 解决设计或架构问题会增加测试工作量或返工
- 客户对从他们需求而来的解决方案非常惊讶，这是我要的吗
- 测试工作量增加或者返工导致成本增加；性能不能满足客户需求有业务流失风险
- 产品不能适应技术发展和未来业务发展等问题
- 技术解决方案这个PA，主要讲述的是设计开发、实现方面的问题
1
- “需求开发”过程域提供需求至“技术解决方案”过程域，在此处需求被转换为产品架构、产品组件设计与产品组件（如通过编码、制造等）
- “技术解决方案”过程域开发产品组件的技术数据包，用于“产品集成”过程域或“供方协议管理”过程域。备选解决方案被考察，并基于已建立的准则选择最优设计。这些准则可以因产品不同而有显著区别，这取决于产品类型、操作环境、性能需求、支持需求以及成本或交付进度。选择最终解决方案的工作会用到“决策分析与解决”过程域中的特定实践
- “技术解决方案”过程域依赖于“验证”过程域中的特定实践，以在设计过程中并在最后的构建之前，执行设计验证与同级评审
- 确认中发现的问题往往在“需求开发”过程域或“技术解决方案”过程域中得到解决
- 迭代很可能发生在需求开发与技术解决方案之间。这些过程的重复应用能够解决所引出的问题。迭代能够在下一个过程的应用之前确保质量
- 技术解决方案（Technical Solution，TS）的目的在于选择、设计并实现对需求的解决方案。解决方案、设计与实现包括单独的或以适当形式组合的产品、产品组件以及与产品相关的生命周期过程
- “技术解决方案”过程域适用于产品架构的任一层级和每一个产品、产品组件以及与产品相关的生命周期过程。在本过程域内，用到术语“产品”与“产品组件”的地方，其预期的含义也包含服务、服务系统及其组件
- 评价并选择解决方案（有时亦指“设计方法”、“设计概念”或“初步设计”），这些解决方案可能满足所分配的功能性需求与质量属性需求的适当集合
- 开发所选解决方案的详细设计（所谓详细指的是包含所有制造、编码或其它将设计实现为产品或产品组件的必要信息）
- 将设计实现为产品或产品组件
- SP 1.1 开发备选解决方案与选择准则
- SP 1.2 选择产品组件解决方案
- SP 2.1 设计产品或产品组件
- SP 2.2 建立技术数据包
- SP 2.3 使用准则设计接口
- SP 2.4 执行自制、购买或复用分析
- SP 3.1 实现设计
- SP 3.2 开发产品支持文档
-
根据你至今了解的一切来创建架构 -
提升抽象的级别来应付复杂性 -
让问题驱动解决方案 -
按照组件松耦合高聚集的方式组织架构 -
重用存在的资产 -
发架构作为协作工具的优势
- 数据设计是把分析过程中产生的信息域模型转化成执行软件所需要的数据结构。数据对象和数据关系被定义在E-R图里，数据字典中详细描述的数据内容提供了数据设计活动的基础
- 架构设计定义了主要的程序结构化的模块之间的关系。设计说明-模块框架-可由多个分析模型和在分析模型中定义的子系统交互中得到
- 接口设计描述了软件本身如何自我通信，和其他系统的交互以及和使用者的交互。数据和控制流程图提供了接口设计所需要的信息
- 流程设计把程序架构的结构化组件转化成软件部件的流程描述
- 设计必须体现所有包含在分析模型中的明确的需求，同时也必须考虑客户期望的隐含的需求
- 对于软件的编码、测试和维护人员而言，设计必须是易读的、易懂的指南
- 设计必须提供软件完整的描述，从执行的角度描述数据、功能性和执行性
- 设计应该展示一个有层次的组织架构，体现出在软件的模块之间的智能化的控制（好的面向对象的设计不需有此特点）
- 设计应该是模块化的软设计应该使系统分解为可展示独立功能特点的多个模块
- 设计应该减少模块之间、模块和外部环境之间的连接的复杂度
- 设计应该是模块化的—软件应该是逻辑化的分割成多个实现功能和子功能的模块
- 设计应该包含数据和流程的抽象
- 应该通过一种可重复的方法生成设计，这种方法是由在软件需求分析过程中获得的信息来驱动
- 不能以狭窄的视角来做设计-而是应该在设计决定之前评估多种方法
- 设计应该可以回溯到分析模型
- 设计不应该是全新的活动-复用已有的设计组件
- 设计应该是结构化以适应变更
- 设计应该是即使遇到错误数据事件或者错误操作时也能平滑过渡。
- 设计不是编码-编码不是设计
- 设计应该在创建时评价其质量而不是创建之后
- 设计应该经过评审，减少语义错误
- 设计应该使软件和问题之间距离最小化，就像它在现实生活中存在的那样。
- 设计应该体现一致性和统一性
-
定义需求（需求定义） -
定义解决方案（系统规范） -
概念化的解决方案（系统概要设计） -
划分任务（产品说明） -
定义产品设计（产品概要设计） -
将产品划分为组件（组件规范） -
定义组件设计（组件概要设计） -
将组件划分为模块（模块规范） -
细化解决方案（模块细化设计） -
实施解决方案（编码和单元测试）
过程总体流程图
详细设计活动
程序实现及文档相关活动
- 组织总体架构：在流程、技术与业务接口、信息标准化上的最佳管理与实施的理论与方法，为了改善组织的综合能力与企业在IT发展和运行上的投资。由企业战略和业务驱动，资源包括战略、业务、人员和IT技术多个方面。企业总体架构＝架构的模块和组件＋模块之间的关系＋构架治理原则
- 业务架构：是建设IT 战略和IT 体系架构的基础，因为业务架构是数据、应用、技术架构的决定因素。业务架构将高层次的业务目标转换成可操作的业务模型，描述业务应该以何种方式运作才能满足成功必须的能力和灵活性。业务架构＝流程+数据+位置+角色+业务规则+时序+…
- 应用架构：定义支持关键业务的主要的应用，按照银行业应用架构的层次模型细划为各个应用/应用群的功能模块和应用范围、应用之间及与外围系统的关联关系、应用/应用群的分布模式、接口定义及数据流向。
- 安全架构：包括：物理、网络、系统、应用、数据层面的身份认证、访问管理、加密、防恶意代码、加固、监控、审核跟踪和备份恢复。
- 技术架构：业务架构基础上提供了一个贯穿与信息数据、应用和基础设施的框架，为发展和开发一个在企业一级交互不同的部门和领域的、在技术层面上的、与业务相一致的解决方案提供了一个基础。保持了企业在技术标准技术选型、应用设计、供应商产品的选择等等一切技术层面的组合和组件与企业的战略规划、业务架构和各个业务领域的实际需求的一致性。
- 数据架构：提供了银行业务对信息数据需求的内容。保证数据有效的共享和交换是企业总体架构的主要目的之一。数据架构描述了我行的业务现在和未来是如何使用数据的。
中国移动通信研究院 科技管理部
