设计方案_设计方案评审报告 - CSDN
精华内容
参与话题
  • 软件设计方案

    千次阅读 2018-10-19 18:38:57
    软件设计方案 1 引 言 1.1 编写目的 阐明编写本设计方案说明书的目的,指明读者对象。 1.2 项目背景 包括:a.本项目的委托单位、研制单位和主管部门;b.该软件系统与其它系统的关系。 1.3 定 义 列出本...

    转:https://blog.csdn.net/ckpckp/article/details/78838446

     

    软件设计方案

    1  引  言

    1.1 编写目的

    阐明编写本设计方案说明书的目的,指明读者对象。

    1.2 项目背景

    包括:a.本项目的委托单位、研制单位和主管部门;b.该软件系统与其它系统的关系。

    1.3 定  义

    列出本文档中所用到的专门术语的定义和缩写词的原意。

    (1)软件配置项(CSCI,ComputerSoftware Configuration Item)。为独立的配置管理而设计的并且能满足最终用户功能的一组软件(部件)。

    (2)计算机软件部件(CSC,ComputerSoftware Component)。计算机软件配置项中性质不同的部分。计算机软件部件可进一步分解为其它计算机软件部件和计算机单元。又称计算机软件模块。

    (3)计算机软件单元(CSU,ComputerSoftware Unit)。计算机软件部件中确定的能单独测试的部分。

    (4)软件接口(SI,SoftwareInterface)。软件系统中程序之间的接口,包括软件系统与其它系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。

    1.4 引用文件

    列出该计划中引用到的所有文档的编号、标题、修订版及日期。本章还应标识所有不能通过正常政府采购活动得到的文档的来源。

    2  项目概述

    2.1 目  标

    根据合同或项目任务书、用户提出的战术技术指标要求等有关文件,在对用户进行多次调研的基础上,逐项说明该软件各项功能的详细需求,描述为完成各项功能所需要的输入、输出、处理及达到的目标。确定软件的主要功能和次要功能,并用文字、图形的形式详尽描述。

    2.2 运行环境

    简要说明支持软件运行的硬件/网络环境(如单机、局域网、城域网、广域网等)和软件环境(如单机、客户机/服务器、多层客户机/服务器、浏览器/服务器环境等)。

    2.3 需求概述

    从用户的使用角度,以场景的角度,详细描述软件在指定运行环境下应该提供的功能、性能、输入、输出等。

    2.4  条件与限制

    说明开发本软件必须具备的条件以及可能受到的各种限制。

    3  总体设计

    注:描述软件总体结构、功能和处理流程。

    3.1 体系结构

    对所开发软件包含各部分及其相互关系进行描述。

    3.2 软件构成

    如果软件由多个软件包构成,则描述各个软件包及其相互关系,以及每个软件包由哪些软件配置项构成。

    以下分节描述每个软件包内的软件配置项之间的关系设计;如果没有软件包,则可直接描述软件配置项之间的关系;如果没有内部关系,则可直接写第6章。

    3.3  ××软件包

    3.3.1  配置项设计

    根据需求规格说明中的软件结构分析、功能分析,用图表说明软件包中各配置项的划分。

    分层次地给出软件包各个配置项之间的控制与被控制关系。详细描述系统的整体环境、依赖软件及相互之间的层次关系。

    3.3.2  信息处理设计

    说明对每个输入或条件进行响应的软件配置项行为的设计和输出设计。

    3.3.3  关键数据结构设计

    3.3.4  性能设计

    3.3.5  用户界面设计

    若有的话,说明用户界面设计的要求。

    4  软件配置项设计

    注:描述该软件各配置项的功能、性能以及详细的程序描述(包括输入、输出、算法、程序逻辑、测试要点等)。

    4.1 ××软件配置项(配置项唯一标识)

    4.1.1  结构设计

    4.1.1.1  部件图

    画出整个CSCI的所有部件(CSC)和组成部件的单元(CSU)的层次图。

    4.1.1.2  部件描述

    4.1.1.3  类描述

    对软件配置项下所有类进行描述。

    4.1.2  性能设计

    4.1.3  接口设计

    a)本节描述软件配置项的接口特性,既包括内部软件单元之间的接口,也包括与外部实体,如系统、配置项、用户之间的接口;

    b)本节只描述对软件需求规格说明(SRS)中的接口需求部分做出修改或增加的接口,其余相同的部分可在此引用;

    c)如果本节部分内容已在接口设计说明(IDD)中给出,则在此引用不必具体描述。如接口设计说明中没有提供,那么一定要在此处给出。

    4.1.3.1  外部接口设计

    4.1.3.2  内部接口设计

    4.1.4  执行序列设计

    本节描述该软件配置项中所有软件单元之间相互调用的执行序列。

    4.2  ××软件配置项

    展开全文
  • 04-软件设计方案

    万次阅读 2017-04-18 15:52:22
    阐明编写本设计方案说明书的目的,指明读者对象。 1.2 项目背景 包括:a.本项目的委托单位、研制单位和主管部门;b.该软件系统与其它系统的关系。 1.3 定 义 列出本文档中所用到的专门术语的定义和缩写词的...

    1  引  言

    1.1 编写目的

    阐明编写本设计方案说明书的目的,指明读者对象。

    1.2 项目背景

    包括:a.本项目的委托单位、研制单位和主管部门;b.该软件系统与其它系统的关系。

    1.3 定  义

    列出本文档中所用到的专门术语的定义和缩写词的原意。

    (1)软件配置项(CSCI,ComputerSoftware Configuration Item)。为独立的配置管理而设计的并且能满足最终用户功能的一组软件(部件)。

    (2)计算机软件部件(CSC,ComputerSoftware Component)。计算机软件配置项中性质不同的部分。计算机软件部件可进一步分解为其它计算机软件部件和计算机单元。又称计算机软件模块。

    (3)计算机软件单元(CSU,ComputerSoftware Unit)。计算机软件部件中确定的能单独测试的部分。

    (4)软件接口(SI,SoftwareInterface)。软件系统中程序之间的接口,包括软件系统与其它系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。

    1.4 引用文件

    列出该计划中引用到的所有文档的编号、标题、修订版及日期。本章还应标识所有不能通过正常政府采购活动得到的文档的来源。

    2  项目概述

    2.1 目  标

    根据合同或项目任务书、用户提出的战术技术指标要求等有关文件,在对用户进行多次调研的基础上,逐项说明该软件各项功能的详细需求,描述为完成各项功能所需要的输入、输出、处理及达到的目标。确定软件的主要功能和次要功能,并用文字、图形的形式详尽描述。

    2.2 运行环境

    简要说明支持软件运行的硬件/网络环境(如单机、局域网、城域网、广域网等)和软件环境(如单机、客户机/服务器、多层客户机/服务器、浏览器/服务器环境等)。

    2.3 需求概述

    从用户的使用角度,以场景的角度,详细描述软件在指定运行环境下应该提供的功能、性能、输入、输出等。

    2.4  条件与限制

    说明开发本软件必须具备的条件以及可能受到的各种限制。

    3  总体设计

    注:描述软件总体结构、功能和处理流程。

    3.1 体系结构

    对所开发软件包含各部分及其相互关系进行描述。

    3.2 软件构成

    如果软件由多个软件包构成,则描述各个软件包及其相互关系,以及每个软件包由哪些软件配置项构成。

    以下分节描述每个软件包内的软件配置项之间的关系设计;如果没有软件包,则可直接描述软件配置项之间的关系;如果没有内部关系,则可直接写第6章。

    3.3  ××软件包

    3.3.1  配置项设计

    根据需求规格说明中的软件结构分析、功能分析,用图表说明软件包中各配置项的划分。

    分层次地给出软件包各个配置项之间的控制与被控制关系。详细描述系统的整体环境、依赖软件及相互之间的层次关系。

    3.3.2  信息处理设计

    说明对每个输入或条件进行响应的软件配置项行为的设计和输出设计。

    3.3.3  关键数据结构设计

    3.3.4  性能设计

    3.3.5  用户界面设计

    若有的话,说明用户界面设计的要求。

    4  软件配置项设计

    注:描述该软件各配置项的功能、性能以及详细的程序描述(包括输入、输出、算法、程序逻辑、测试要点等)。

    4.1 ××软件配置项(配置项唯一标识)

    4.1.1  结构设计

    4.1.1.1  部件图

    画出整个CSCI的所有部件(CSC)和组成部件的单元(CSU)的层次图。

    4.1.1.2  部件描述

    4.1.1.3  类描述

    对软件配置项下所有类进行描述。

    4.1.2  性能设计

    4.1.3  接口设计

    a)本节描述软件配置项的接口特性,既包括内部软件单元之间的接口,也包括与外部实体,如系统、配置项、用户之间的接口;

    b)本节只描述对软件需求规格说明(SRS)中的接口需求部分做出修改或增加的接口,其余相同的部分可在此引用;

    c)如果本节部分内容已在接口设计说明(IDD)中给出,则在此引用不必具体描述。如接口设计说明中没有提供,那么一定要在此处给出。

    4.1.3.1  外部接口设计

    4.1.3.2  内部接口设计

    4.1.4  执行序列设计

    本节描述该软件配置项中所有软件单元之间相互调用的执行序列。

    4.2  ××软件配置项

    展开全文
  • 如何写好项目规划和方案设计文档

    万次阅读 多人点赞 2018-07-27 09:49:14
    问题可大可小,形式上是否叫它为一个项目并不重要,重要的是为了解决这个问题,项目规划和方案设计的流程是一致的。就大数据平台构建的语言环境来说,它可以是整个平台体系的搭建方案,也可以是具体某个组件如调度...

     

    在工作中,很多时候,我们都需要就一个问题提出一个解决方案,这时候,我们很可能需要产出一个文档来供大家讨论,并指导下一步工作计划。

    问题可大可小,形式上是否叫它为一个项目并不重要,重要的是为了解决这个问题,项目规划和方案设计的流程是一致的。就大数据平台构建的语言环境来说,它可以是整个平台体系的搭建方案,也可以是具体某个组件如调度系统的建设,还可以是某个具体的功能点或问题改进比如用户任务脚本的依赖关系分析,系统稳定性的提升等等。

    一篇项目规划和设计文档的好坏,往往决定了一个项目整体的调性和可预期的产出结果。但是,这么重要的文档,真正能写好的同学却并不多,很多同学甚至可能都没有意识到它的重要性,而仅仅是把它当作领导要求的一个软件流程的规范来简单应付,怎么快怎么来。

    事实上,撰写项目规划和设计文档,最重要的不是文档的模版和格式,而是里面的具体内容,它往往需要结合实际客观环境因素来综合考虑,平衡取舍,是一个需要充分脑力活动的工作。尽管如此,在大多数情况下,还是有一些相对通用的指导原则可以帮助我们更好的完成这项工作。

    本文侧重于方案的需求分析到概要设计部分,因为这部分内容通常是最容易被大家忽视,也最需要方法论和“端正的思想”来指导的 ;)而详细设计相关内容,考验更多的是技术的深度,以及如何做到全面周到,我计划在后续文章中另行阐述。

    总体原则和目标:

    首先,需要有明确项目背景,目标,以及核心需求分析

    方案规划设计文档的好坏,几乎完全取决于这一部分内容。但多数同学在这一部分内容身上,往往花费的时间却是最少的,常见的方式,就是“直奔主题”,上来就写具体要做的事

    项目背景和目标

    项目背景不是让你写一堆无关痛痒的铺垫材料。实际上,项目背景的作用是:

    Why?为什么要在这个时候做这个项目?

    换句话说,就是这个项目从产品或业务的角度,最核心的推动力是什么?再换句话说,痛点是什么?

    有痛点自然就有目标,你希望项目最终以什么方式解决问题,能达成什么目标。

    背景和目标的阐述,必须要能够自然合理的推导出下一部分内容:项目的核心需求/功能是什么。

    如果项目背景,目标的描述不能起到这个作用,那这一节内容就没写好,因为项目方案文档就缺乏了根本的出发点,后续的内容都没有了好坏对错判断的基本依据。

    项目核心需求

    项目核心需求和项目目标有什么区别?实际上没有严格的区别,只是对需要解决的问题的概括抽象程度的不同,或者描述角度的不同。

    目标可以理解为希望达到的一个状态,是抽象的,和技术方案无关的偏结果角度的表述方式。

    而项目核心需求,可以理解为了解决背景描述的问题,为了实现那几个目标,进一步推导出来的,在当前系统环境或方案框架体系中:必须要提供的产品功能形态,或者是必须满足的关键特性,又或着是不能违背的约束条件。你也可以理解为用更技术的语言进行细化描述的项目目标。因为目标和背景的不同,可能同一件事推导出来的核心需求也不同。

    这么说比较抽象。举个例子,如果我想构建一个数据交换服务或ETL系统,那么上述各环节的内容可能是(简化的写):

    • 背景 : 当前数据ETL链路极端难用,效率低下,稳定性差,维护代价高,用户抱怨多等等。
    • 目标 : 用户全自助,简单易用;可维护性好;性能高;可靠性好。
    • 核心需求 :比如针对“用户全自助,简单易用”这点(其它目标可以类似分析推理),可能是:
      • 提供统一的,标准化的配置后台:用配置的形式表达ETL业务语意,屏蔽下层实现细节。
      • 提供完善的错误反馈信息/机制:让用户能自助解决使用中遇到的问题。
      • ETL业务流程标准化:将最佳实践沉淀下来,通过配置的方式让用户选择,减少重复工作,降低用户开发的难度,规避使用姿势错误可能造成的问题。

    讲完区别,继续回来讲,这部分内容的要求。很多同学在写这部分方案的时候,很容易把需求和实现手段混为一谈。所以:

    核心需求的重点是:本质上需要提供什么能力,而不是具体实现上要做什么

    换个角度说,核心需求的描述方式是:要做成什么样,是功能目标而不是实现手段。

    在完整的项目文档中,显然目标和手段都需要,但是

    目标必须先于手段,而非相反

    原因也很简单,脱离了目标谈手段是没有意义的,很容易导致方向做偏,使得最终的结果产出背离了项目最初真正的需求出发点。

    实践中,做成什么样和怎么做有时候很难绝对分开。一句话的描述方式可能既包含了目标需求也包含了实现手段。那么,怎么判断这部分内容写得是否满足要求呢。

    • 如果你描述的侧重点只是需求的一种实现方式,而这个需求可能还有更多的其它实现方式,或者即使真的只有一种实现方式,你所描述的内容的也只是因果关系中,间接的因而非直接的果,那么很可能你描述的就只是手段而非目标。
    • 如果看文档的同学看完只知道你要做什么,而不知道做这些是为了什么?是否做这些就足够了,还应该做点别的?是否有别的解决方案,又或者做完了到底有什么用。那么也很可能是因为你把需求和实现手段混为一谈了。
    • 核心需求必须是本质的,一定要实现的功能,它是一个原则,不是工作列表。不要事无巨细,凡是想做的都列在上面,那样反而淡化了项目最根本的诉求。但它也必须足够全面,要能确实解决项目目标中所提出的要求,应该用适当抽象的语言概括一个完整的事项。

    总结一下,核心需求的根本目标是,让参与项目的同学有方向感,能够知道这个项目最终想要通过提供哪些能力,满足哪些约束条件来解决问题,至于怎么实现,具体要做哪些事,那是下一步才需要回答的问题,简单来说:先选择做正确的事,再考虑怎么把事做正确。

    其次,需要对现状和问题进行充分的收集和分析

    这一部分内容,从实际操作的先后顺序来说,未必是第二步,很可能在我们总结前面的背景,目标,核心区需求的时候,就需要加以收集和分析。

    不过,从方案文档的角度来说,放在这里,是为了进一步细化问题,分析目标,核心需求与当前现状的差距在哪里,具体有哪些实际问题需要解决。为后续具体的实现方案,准备必要的输入信息,确定工作的优先级,重要性,项目迭代的步骤等等。

    需要强调的是,现状和问题分析,要围绕前面的核心需求的条目展开,两者是强关联的,不要相互脱节,各讲各的

    这块内容本身没有太特别的地方,就是现在实际情况如何,有什么问题,关键是如何把问题收集完整。

    所以这部分内容,难的是如何发现问题,很多做技术的同学往往容易陷入只关心技术难点,只能看到技术问题的局面中,而实际上,更多的问题往往是整体流程如何设计更加合理的问题,而不是技术方案绝对对错的问题。

    尽管行文上不难,但它的重要性,也往往容易被忽略,很多情况下被简单对待。实际的情况是,很多项目的方案计划往往是在对现状问题相关信息没有充分收集和分析的基础上就做出来的。导致项目方案后期不断调整,或者一期一期的总是在小步迭代,甚至不断推翻重来。而最终使用方真正关心的问题却一直没有得到重视和解决。

    最后,是输出解决方案

    定完需求目标,分析完问题和现状,接下来才是规划具体做什么,怎么做,什么时候做。

    这部分内容,强依托前面的核心需求和问题分析工作,没有做好前面的准备工作,千万不要着急开始动手“规划”方案!!!

    那么具体写的时候有哪些注意事项呢?

    做什么:

    • 做什么和前面项目目标的要求刚好皆然相反,需要输出明确的可执行的事项,而不是模糊的不可执行的要求。
    • 具体做的每一件事情,都要和前面的核心需求和现状问题对应上。如果你发现有些工作,和前面的目标没有任何关联性,那么考虑一下目标是否需要再评估调整,或者这件事情根本就是不重要的。
    • 要做的事项列表,是一个经过归纳思考以后的总结,而不只是一个个零散的事情的随机列表。需要有重点和优先级。如果有必要,以归类,分组等形式结构化的组织相关联的事项。
    • 完整的事项列表,应该是一个和最终目标对应的完整解决方案,而不仅仅只是完成目标工作中的某一个环节。
      • 比如面向用户的终端产品项目,需要包括整个产品的交互逻辑,业务流程的规范设计等等,而不仅仅是对底层系统实现和后台功能点的设计。
      • 这点很多同学也很容易忽略,总觉得功能和架构的实现才是有挑战,需要规划的内容,而产品的形态并没有花心思去琢磨,事后开发前端时才来考虑。实际上后者可能才是真正影响项目成功的关键,也很可能会影响到底层架构的设计和取舍。类比一下,好比一个用户产品都开发完了,才来考虑埋点,数据采集和数据分析的工作,这时候就很被动了。

    怎么做:

    • 前期方案文档,没有必要列出详细的技术方案细节,只需要一个整体的技术方向选型和初步的架构设想。但是,如果是涉及到核心需求能否有效满足的关键的技术点,有可能影响整体的架构或产品实现的,那就有必要就可能的方案的进行详细的评估并得出初步的结论。
    • 无关架构或进度安排的方案细节,没有必要写太多,可以后续再补充。
    • 方案中有不明确的地方,即使没有时间调研,也不要简单的略过不写,要在文档中明确的把问题写出来,给出下一步调研的方向计划等。归根到底,方案文档中,对每一个已知重要的问题,都需要一个明确的结论或者可以后续跟进的计划,以免事后遗漏。

    再强调一下,做什么和怎么做就是手段,既然是手段,就要写得足够具体,具体到有明确的可落地实施的事情,有明确可以衡量的标准,或者针对当前存在的一个具体问题,不要在这个地方又写得像目标,没有明确的可执行的点。

    继续举上文数据交换服务的例子,针对其中的一个核心需求:

    • ETL业务流程标准化:将最佳实践沉淀下来,通过配置的方式让用户选择,减少重复工作,降低用户开发的难度,规避使用姿势错误可能造成的问题。

    这个内容要写具体的要做的事项。以下方式来写可能就是不合格的,因为不够具体,还没有足够思考:

    • 总结最佳实践
    • 生成标准的流程
    • 总结常见的错误

    以下内容可能就更加明确,更加可落地一些:

    • 统一当前增量数据导入的存储,合并,归档方案
    • 将常见合并,去重逻辑标准化,通过配置自动生成任务脚本
    • 制定ODS快照表生命周期管理方案,规范存储路径和命名方式,定期清理过期数据。

    什么时候做,谁来做:

    • 这是做什么和怎么做的进一步延伸,需要强调的是整个项目如何实施的整体步骤计划,而不仅仅是简单的列一下每项工作的人员和排期,
    • 需要分析系统可能的迭代步骤(包括可能的短期应急和长期解决方案),上下游依赖梳理,需要协同进行的工作,最终项目上线时可能的业务迁移,数据迁移,系统集成等等外围工作的安排。

    如果不是工期严格要求,deadline为导向的项目,整体的依赖和步骤往往才是在项目规划阶段需要重点阐述的内容,也是有可能对整体产品的进度,风险产生影响的事项

    而具体工作工期的安排,说实话,多数情况下,反到没有那么重要。如果整体工作和步调没考虑周全,工期排得再科学,再精细,也毫无意义。

    总结一下,什么时候做什么事,最重要的目的,不在于工期的计算,甚至也不是人力资源的安排,而是为了理顺事情依赖关系,控制可能的意外风险,提升项目开发进度的可控性。

    小结

    方案规划设计文档,绝对不是为了满足流程需要凑数的文档,也不是头脑风暴式的简单记录。它的根本目标,抽象来说是:明确问题,圈定范围,确定重点,阐明路径。本质是为了统一认识,控制风险。它应该是一个问题经过思考以后的输出的答案,而不是问题的调查报告,笔记或备忘录。

    它很像一个议论文体裁,事实,分析,结论缺一不可。所以,无论你的方案文档写的多么翔实,如果只是相关内容细节的罗列,只议不论,缺乏抽象总结,还需要阅读文档的同学再去揣摩项目意图,或者看完以后对项目所要做的工作为什么要做,重不重要,要做成什么样都不明确的话。那它就只是一个不合格的半成品,不能对后续的项目开发工作发挥实质的指导和规划作用。

    结论列表

    上面花了大量篇幅展开讨论,目的是说服你接受我的看法。

    如果你只需要明确的结论,那么再总结一下:

    总体原则:

    • 项目方案规划文档的根本目标是统一认识:明确问题,确定重点,阐明路径,控制风险。
    • 文档的撰写方式,是目标和需求先行,围绕出发点,逐步递进展开。
    • 文档的基本要素:背景,目标,核心需求,现状问题分析,关键方案难点解析,总体实施路径,工作事项列表,进度计划安排。

    再细化到一些注意事项:

    • 核心需求,必须是核心的,一定要实现的内容!不能缺,也不能滥。
    • 问题现状,工作事项,必须呼应核心需求,要有明确的相关性,不要无的放矢。
    • 围绕最终目标,输出完整的端到端的解决方案,而不是局部环节的方案。需要从最终产品/功能形态的角度考虑要做的事,而不是仅仅考虑底层技术实现。
    • 事项目标列表,不要仅仅罗列要做什么事,更重要的是说明想要得到的结果,而不仅仅是描述实现手段。
    • 所有工作事项,需要明确思考过实施步骤,重要性和优先级,结合目标和需求,进行抽象归纳,而非简单随机罗列。
    • 要有明确的计划排期,但更重要的是,要完整的分析思考可能的上下游和周边工作依赖。排期只是结果,完整的梳理才是关键。

    两条辅助判断依据:

    • 如果开发同学看完文档,无法根据后续开发过程中遇到的实际情况,调整工作事项和优先级,完善和改进这个文档,那么大概率这个项目方案文档是没有写好的。因为这个文档可能只起到了事项罗列和工作安排的作用,却没有起到指导思考,授人予渔的作用
    • 如果看完文档,这个项目的最终产出你无法预见,你对项目的目标最终能否实现无从判断,那么这个项目方案文档大概率也是没有写好的。因为这个文档自身的归纳总结可能还没做到位,风险和问题可能还没有评估清楚,还需要走一步看一步。

    提示

    写项目方案文档,不是八股文,所以本文的内容并非绝对的教条,你当然可以根据项目的实际情况和复杂程度自行调整,但前提是你真的知道你为什么要这么做,而不仅仅是为了偷懒

    本文多数内容是各种观点,注意事项,结论和目标,具体如何做到这些,每个同学都可以自行思考。当然除了思想和目标端正,每个环节,其实也有一些具体Tips和checklist可供参考。下一次再说,下一次再说吧。。。

    软广

    本文写的各项原则,在我们之前的项目实践上实际都有体现,有兴趣结合实例比对参考的同学,我再厚脸皮再推一下这本书 《大数据平台基础架构指南》

    京东,淘宝,中亚有售,JD购买链接 : https://item.jd.com/29923944547.html ;)


    常按扫描下面的二维码,关注“大数据务虚杂谈”,务虚,我是认真的 ;)

    展开全文
  • 系统重构设计方案

    千次阅读 2018-11-27 14:55:39
    文档介绍 1.1系统重构目的 提高开发的效率,方便快速迭代化开发。...1、本系统的系统开发人员:开发人员(了解重构的设计方案、结合现有系统修改)。   2.重构设计思想 2.1 多个基础微服务合成一个微...

    文档介绍

    1.1系统重构目的

    1. 提高开发的效率,方便快速迭代化开发。
    2. 增加登录校验、参数校验、统一日志格式、异常处理。
    3. 删除多余的功能模块。

    1.2文档范围

    本文档包含以下几个部分:

    1. 重构设计思想
    2. 实施方案

    1.3读者对象

    本文档主要读者包括:

    1、本系统的系统开发人员:开发人员(了解重构的设计方案、结合现有系统修改)。

     

    2.重构设计思想

    2.1 多个基础微服务合成一个微服务,整合现有微服务

    (1) authService、attachmentService、configService、notifyService、rateService、systemService、validateService合成一个foundationService

    (2)userService、kycService、operationService、onlinebankService、nanoService 仍然是单独的微服务

    (3)workflowService、amazonService、ccService、channelService、channelService、chargeService、chicagoService、ifspService、japaneseService、tradeService、financeService删除

    (4)tradeapp删除

    2.2登录校验

    (1)增加authorityInterceptor,实现spring的HandlerInterceptor的接口,完成对所有.do结尾的接口的登录校验

    (2)ebank、management、onlinebankapp三个应用里增加该功能

    2.3参数校验

    (1)针对Controller层,利用spring的aop拦截方法,实现methodInterceptor的接口,完成对Controller层的对象的参数校验

    (2)针对微服务,利用duobbo的filter,完成对微服务接口方法的对象的参数校验

    (3)支持javax.validation的标准格式

    (4)支持中英文信息显示,在messageXX.properties配置信息。

    2.4日志

    (1)统一使用PanLogger,PanLogger和logger的方法一致

    (2)PanLogger格式包括日期、线程号

    (3)PanLogger日志文件分离,各个应用输出各自文件

    2.5异常处理

    (1)针对Controller层,利用spring的aop拦截方法,实现methodInterceptor的接口,完成对Controller层的方法调用的异常处理,统一返回标准的格式

    (2)针对微服务,利用duobbo的filter,完成对微服务接口调用的异常处理,统一返回标准的格式

    2.6 微服务接口字段变更

    (1)微服务生产者的ReqDTO,增加字段,兼容已发布的消费者

    (2)微服务生产者的ReqDTO,改变字段的类型,删除字段,不兼容已发布的消费者

    (3)微服务的序列化协议由kryto改为hession2

     

     

    3.重构后的架构体系

    4. 实施方案

    4.1 微服务整合

    (1)  authService、attachmentService、configService、notifyService、rateService、systemService、validateService功能移入到foundationService

    (2)workflowService、amazonService、ccService、channelService、channelService、chargeService、chicagoService、ifspService、japaneseService、tradeService、financeService删除,上述服务如果存在仍然需要使用的部分功能,示具体的功能移到重构后的微服务当中

    4.2 登录校验、异常处理 

    (1)前台人员增加全局登录校验、异常处理的提示

     

    展开全文
  • 技术方案书模板-1

    万次阅读 2011-11-26 12:49:11
    1 序言  简述项目实施的必要性及意义。  2 需求分析  2.1 技术现状  描述用户现有技术应用环境、人员技术状况。  2.2 用户需求  ...3 硬件系统技术方案设计  3.1 网络方案设计  3.1.1 设计
  • 方案1:通过每次设计好的芯片通过工厂来制作出来,之后在利用生产的替代原来的,这个方案每个周期=芯片计算设计时间+芯片生产制作时间+加芯片替换时间 方案2:通过FPGA来代替工厂生产,这样芯片的...
  • IT技术方案书模版

    千次阅读 2013-09-27 23:08:58
    IT技术方案书模版 1 序言 简述项目实施的必要性及意义。 2 需求分析 2.1 技术现状 描述用户现有技术应用环境、人员技术状况。 2.2 用户需求 着重描述用户的目前需求及未来的设想。 3 硬件系统技术方案设计 3.1 ...
  • 系统安全架构设计方案

    千次阅读 2019-10-25 16:46:23
    系统安全架构设计主要包含应用安全、数据安全、主机安全、网络安全四个方面,详见下图。
  • 测试方案和测试策略的区别

    万次阅读 2019-06-04 12:56:48
    测试方案:侧重测试的方法,测试环境的规划,测试工具的设计和选择,测试用例的设计方法,测试代码的设计方案。 测试策略:侧重需求分析,评估风险,定义测试范围,确定测试方法,制定测试启动、停止、完成标准和...
  • 测试计划和测试方案区别

    万次阅读 多人点赞 2018-07-20 16:18:50
    关于测试计划和测试方案的区别,这里主要从编写目的、定义和层次、编写时间和依据、软件过程、文档内容这五方面来说明,具体内容如下: 一、编写目的 制定测试计划目的:按照所制定的测试计划可以有效的计划、执行...
  • APP开发技术方案模板

    千次阅读 2019-02-17 13:24:06
    下载链接:https://download.csdn.net/download/ycy0706/10961357 目 录 1 项目概述 3 1.1 项目说明 3 1.1.1 项目背景 3 1.1.2 项目目标 3 1.2 项目建设内容 3 1.3 项目建设目标 3 2 系统总体需求 3 ......
  • 接口设计与数据同步解决方案小结

    万次阅读 2012-05-12 23:07:11
    接口设计方面:   在做项目过程中,对于一个Web平台性的系统来说,往往需要为其他程序开放系统接口,即是以自己做的系统为平台,允许第三方的程序接入。需要和第三方的程序数据打交道,需要第三方程序通过调用web...
  • 系统测试方案

    千次阅读 2019-04-10 17:19:01
    测试计划是从管理角度规划和... 测试代码的设计方案 系统测试方案的核心内容: 系统测试策略选取 系统测试子项划分 测试策略(测试策略是如何用尽量少的资源来尽量好的完成测试): 单元测试策略(对应多...
  • 软件设计方案说明书的编写

    万次阅读 2018-10-09 11:37:36
    关于软件设计方案说明书的编写,其根本目的有两个,一是便于项目内部各职能的成员进行沟通和项目执行时的依据(比如编码、测试等),二是作为项目的一部分,是项目文档的一部分。软件设计方案说明书的格式和内容,...
  • 怎样制定一个合格的测试方案

    万次阅读 多人点赞 2020-07-05 21:01:22
    在项目测试过程中,测试方案制定的好坏,会直接影响到项目的的质量。因此需要制定一份完善的测试方案,那么如何才能制定一份完善的方案呢?
  • 本文为博主原创, 为2015年全国大学生电子设计竞赛专题系列的第三篇文章,这是博主准备参加2015综合测评时候的练习一下2013年的综合测评的Multisim仿真电路方案,不当之处,还请指正。 2013年Multisim仿真电路2013年...
  • 技术方案模板

    万次阅读 2017-09-18 14:24:35
  • MySQL常用集群方案

    万次阅读 2018-06-30 11:15:37
    大型互联网程序用户群体庞大,所以架构需要特殊设计。 单节点数据库无法满足大并发时性能上的要求。 单节点的数据库没有冗余设计,无法满足高可用。 单节点 MySQL无法承载巨大的业务量,数据库负载巨大。 一、...
  • 测试方案和测试计划的区别

    万次阅读 2009-08-05 17:05:00
    作者:刘洪鹏 新闻来源:焦点测试网 更新时间:2007-7-19 17:59:32一、测试计划:对测试全过程的...二、测试方案:描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试
  • 题目背景: 之前做电商运营,打算转行做开发,参加了几个面试,几乎每家都会问到大数据量时的解决方案。暂时不讨论问这个题目的合理性,既然有需求,那自己就加强吧。所以基于目前个人做的一个...订单表设计方案及查
1 2 3 4 5 ... 20
收藏数 1,076,194
精华内容 430,477
关键字:

设计方案