云设计方案Word下载.docx

云设计方案Word下载.docx

《云设计方案Word下载.docx》由会员分享，可在线阅读，更多相关《云设计方案Word下载.docx（19页珍藏版）》请在冰豆网上搜索。

本系统的设计目标包括：

Ø

提供不同的双因素选项以满足强认证的需求。

即使用户处于离线状态，仍可以通过安讯云移动应用或固定电话来完成认证。

此外，还允许用户有多个设备，以及选择其喜好的登录认证方法。

提高客户用户云端基于策略和控制的授权访问以及管理能力，提供完善的设备和用户管理和查询统计功能。

提升客户满意度，满足各方安全，实时，便捷的需求。

2.2设计原则

1、模块化原则

系统必须由一系列独立部署的模块组成，模块的设计应该满足以下要求：

模块多实例运行：

应该尽量满足对每一个模块都可以同时运行多个模块实例的需求，以保证系统的高可靠性与可伸缩性。

模块粒度合理确定：

综合考虑系统性能、扩展性等方面的因素，同时兼顾系统在部署、维护和管理等方面的要求，合理确定模块粒度。

每个模块均可以承担服务提供者和服务使用者两种角色，服务使用者通过访问服务提供者的接口获取相应的服务。

系统必须实现模块的分布透明机制。

组成系统的模块实例可以部署在一台或多台主机上。

模块提供的服务访问对分布地点、位置透明，服务使用者通过模块的逻辑名称即可获取服务而与模块所在主机的物理位置无关。

2、面向对象的多线程，多进程原则

系统设计须遵循松耦合、高内聚的面向对象原则。

对象/模块之间保持松耦合状态，服务的具体实现方式对服务使用者透明。

在对象/模块内部所实现的功能与结构保持高度逻辑相关性的同时，保证对象/模块间的相互独立性。

。

3、功能参数化原则

系统对所监控、调度、管理的设备类型扩展性有较强的要求，为了能迅速对管控设备的增减，满足多种异构设备的管控需求，就要对各个功能依据不同的设备类型、不同的业务能力，能够快速配置来满足实际的功能需要，即功能参数化设计。

同时一些其它的业务功能，例如外部系统的接口功能，系统用户权限管理，系统数据日志等的备份管理功能，也按照参数化设计原则来达到维护便利、扩展迅速的能力。

4、开放性原则

这是面向对象设计（OOD）的基石，也是最重要的原则。

开放性强的系统设计能够方便快捷的集成第三方软件，与第三方软件无缝结合完成特定应用处理的需要。

开放性原则在系统中也体现在对扩展开放，包括功能扩展、协议扩展、网络硬件扩展上。

5、安全原则

系统往往保存有企业安全的资料和设备，也会有个人用户的一些保密资料，这就要求系统能有效防止外部各种病毒攻击和恶意攻击，能够进行严格、细致的访问权限管理，内部数据具有多种备份方式。

确保用户可以自由选择多种合适的在线或离线身份认证和访问控制。

为防止不必要的系统故障，除了在平台设计中选择高可靠性的方案以防止系统本身出现故障以外，整个系统也应该对外来的有意和无意的非授权访问。

由于增加了安全防护措施，必然造成一些性能的损失。

因此在设计时需要考虑哪些数据及服务器应该受到重点保护，哪些服务器则可以降低安全性标准。

6、高可用原则

高可用原则要求系统的界面友好，结构清晰，流程合理，功能一目了然，菜单操作充分满足用户的视觉流程和使用习惯。

易理解、易学习、易使用、易维护、易升级，实现“傻瓜相机”式的操作，将实施、培训成本和周期降到最低。

易用性对软件的顺利实施和使用具有至关重要的意义，易用性的欠缺造成项目失败的案例已经屡见不鲜。

系统也注重实用性，即务实不务虚，就是注重解决实际问题，做精、做细核心功能，兼顾常用的辅助功能，实现快捷、方便地部署和使用，并节省投资，降低风险。

2.3技术架构

系统总体上采用B/S架构，设计方面采用分层的思想，以隔离各个层次之间的依赖性，便于系统扩充。

2.4硬件环境建议

因为系统各项性能指标有如下要求

系统存储能力：

表记录100k/条，历史及统计数据能保存20年；

系统响应能力，保证监控实时数据每秒刷新一次；

根据该项目特点，我们建议所有的硬件设备都要考虑双机热备，对系统主要硬件环境建议如下。

2.5系统性能设计

数据模型设计符合三范式要求，建模规范化，使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新。

遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。

并充分利用数据库提供的索引机制，在开发过程中持续对数据库的访问进行优化，提高后端的响应能力，使应用程序的运行效率最高。

系统部署时采用集群配置，集群中的所有服务器都对外提供服务。

集群网关负责将应用请求转发到相应的应用服务器。

如果一台服务器停机或过载，集群网关自动将请求发送到另一台服务器，其工作由其它服务器共同承担，完成负载均衡。

经过优化和负载均衡后的系统在性能方面应满足以下指标：

历史及统计数据能保存>

=20年；

系统能长时间稳定运行，保证7X24无间断无故障运行；

3.工程实施方案

工程实施方案将详细阐述我们在实施该项目时依据质量体系和工程经验所制定的割接计划、质量管理、风险规避以及人力资源保障等措施，以最稳定、安全、高效的方式推进系统上线运行。

3.1项目实施进度

大致实施计划如下：

项目实施进度

第1月

第2月

第3月

第4月

第5月

第6月

第7月

项目准备

需求调研

设计开发

系统测试

系统交付

安讯云软件开发周期

实施进度描述如下：

项目实施前期的准备工作，例如人员组织，相关厂商沟通、生产模拟环境搭建等，保障项目实施顺利进行。

对客户需求进行深入挖掘和调研，采集详细需求，对调研结果进行分析，制定系统解决方案。

根据系统技术方案和需求规格说明书，进行系统架构设计和功能设计。

在确定的开发模式下进行快速开发和单元测试。

设计过程是需求于编码之间的桥梁，是系统开发中非常重要的一个环节。

系统设计过程包括概要设计、详细设计两个阶段。

在概要阶段要完成收集相关资料，确定设计目标，重点是完成软件系统的体系结构设计也就是软件的总体设计，在这个阶段从计算机实现的逻辑角度设计确定组成产品的模块，定义每个模块的功能任务，定义模块间接口及模块到运行环境的外部接口，并说明他们在技术上如何工作；

详细设计阶段在概要设计基础上完成每个程序、模块的内部设计，确定其程序流程，缩小于编码的差距。

并且可以通过使用设计语言、图形流程图等将设计文档化。

发现并修正概要设计阶段的问题。

在基本完成系统功能开发的基础上，进行集成测试和系统联调，以验证软件与用户要求是否一致，即验证用户需求分析报告的符合性。

在集成测试中将通过了单元测试的模块组装起来进行联合测试，以发现和接口有关的错误，决定各模块之间能否在一起共同工作。

在集成测试之后，由测试组完成最大的对产品由重要影响的测试。

根据需求分析报告的规定，模仿用户使用软件的测试方法，从功能、性能、界面、压力等方面检查软件是否达到预定的要求。

项目组织架构

项目组织架构示意图

项目组各角色职能如下：

组织架构

职能说明

领导小组

主持对系统目标、范围、方针、路线等重大问题的决策。

负责系统建设中人、财、物的保障。

管理组

项目经理

负责项目建设的工程范围、建设方案、总体进度、资源调度等方面的决策。

负责解决各方之间的争议。

组织审批系统的阶段里程碑结果。

领导整个团队按照项目进度计划完成整个项目的建设

1、组织审核整体项目的工作范围，并对工作范围的重大变更进行决策；

2、确定项目总体进度目标，并对总体进度的重大变更进行决策；

3、组织审核整体项目的系统验收；

4、负责项目建设中的关系协调；

5、负责与用户沟通项目期望、项目进展状况和存在的问题；

6、组织审核阶段性工作；

7、参加阶段性报告；

8、根据规范的项目管理方法，双方的项目负责人共同对整个项目的进度安排、资源计划、风险分析、变更管理、质量保证等方面进行综合分析，并提出相应的解决方案和实施计划；

9、在项目总负责人的宏观决策指导下与管理组一起进行项目的总体管理和总体控制；

10、协调、解决、落实项目实施过程中出现的问题与争议；

11、及时汇报项目实施过程中所产生的问题与争议，并提供相应的问题分析及解决方案；

12、发现、评估、协调、跟踪、解决、落实项目实施中的风险与依赖；

13、定期汇报项目实施状况；

14、根据规范的项目管理方法要求提交相应项目管理文档；

15、领导管理组统一集中管理系统项目开发；

16、负责最终审核和签发项目组的对外提交物和项目管理文件；

17、领导整个团队按照项目进度计划完成系统项目。

需求组

负责对客户需求进行深入挖掘和调研，采集详细需求

1、在需求分析阶段，负责组织和协调需求访谈、需求分析讨论，并完成需求确认、需求争议讨论等工作；

2、后续各阶段，负责新需求的收集、分析，控制需求变更；

3、负责审核最终提交物与需求规格的符合程度。

开发组

负责系统开发、测试及培训工作

1、应用系统设计开发；

2、系统测试及调试；

3、对系统的使用进行培训；

4、与各系统接口的调试。

保障组

系统上线后的技术支持工作。

3.2软件开发过程

随着信息化技术的不断普及和深入，公司在软件开发过程方面也不断进行探索，通过多年的耕耘，取得了斐然的成绩。

我们摒弃了原有的传统的开发模式（瀑布模型和敏捷开发模型），换以客户体验和感知更好的敏捷开发模式，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

3.2.1传统的开发过程

1、瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。

同时评审该项活动的实施，若确认，则继续下一项活动；

否则返回前面，甚至更前面的活动。

开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。

瀑布模型

瀑布模型有以下优点：

为项目提供了按阶段划分的检查点

当前一阶段完成后，只需要去关注后续阶段

可在敏捷开发模型中应用瀑布模型

瀑布模型有以下缺点：

在项目各个阶段之间极少有反馈

只有在项目生命周期的后期才能看到结果

通过过多的强制完成日期和里程碑来跟踪各个项目阶段

3.2.2敏捷开发模型

如果要实行一个很好的scrum,通常要满足两点：

一、团队有三名或以上的研发工程师；

二、团队内有一名合适的ScrumMaster。

当团队内无法找到合适的ScrumMaster时，不要轻易推行敏捷。

如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的ScrumMaster出现。

当真正实行敏捷开发时，要注意量化衡量团队的执行力的指标：

完成度、评估准确度、计划合理度。

这是评定整个进度的很重要的指标，也是让迭代更好的进行下去的准则。

敏捷开发模型

与传统的瀑布模型相比较，迭代过程具有以下优点：

简单设计，重复迭代。

减少不必要的文档。

客户最关心的功能最先完成。

要求客户有时间对每次迭代的成果进行确认，提出改进意见。

3.3质量管理

本模块包括项目开发和项目实施，项目的质量管理也需要根据不同的项目阶段制定不同的管理方案。

基本上，在项目规划阶段和项目实施阶段，主要参照ISO9001（2000版），在项目开发阶段会主要参照CMMI理论制订项目质量管理方案。

根据CMMI理论，没有正确的开发过程，就不会有正确的产品。

为了切实保证项目的质量，需要明确工作角色和职责，制订质量工作计划，制订过程规范和模板，通过质量跟踪监督等手段保证过程规范得到遵守，项目提交物达到预定的质量标准。

3.3.1质量管理策略

我们为保障项目实施的质量，有如下管理策略：

明确项目组各个角色在质量管理方面的责任，强化质量意识。

明确项目开发和实施中的过程规范，确保按照过程规范完成相应工作。

明确工作提交物质量要求，杜绝不符合质量要求的工作提交物。

强化过程监督和提交物质量控制，保证开发过程规范化和工作提交物的质量。

3.3.2开发过程质量控制

根据CMMI理论和北京安讯奔多年的软件项目开发经验，软件项目整体开发过程包括以下过程：

软件项目计划

软件项目开发管理的计划制定，包括开发进度计划、风险控制计划等。

软件项目跟踪和监控

防范项目开发过程中所产生的计划偏离问题，使项目组对软件项目的进展了解并控制。

软件配置和变更管理

保证在软件项目开发生命周期中，文档和程序模块的完整性，如配置项的版本控制和变更流程控制。

软件需求管理

分析、确认客户真实需求，并控制需求的变化。

系统设计

包括总体方案设计、概要设计和详细设计。

系统实现

系统编程和代码调试。

根据客户需求检查和验证系统是否满足预定的功能、性能等设计目标。

软件质量保证

通过对软件开发过程的监控和评测以保证软件质量。

过程规范举例说明：

编码注释规范中会明确规定源代码中每个源代码文件都有该代码文件的功能概要说明，主要作者，完成时间等信息；

每个模块/函数都必须注释说明该模块的调用参数/输出参数，详细功能等信息。

在系统项目中，开发过程的质量控制方案如下：

开发过程

过程规范

责任人

质量要求

开发项目管理规范

开发活动符合过程规范要求

软件配置管理

配置管理规范

配置工程师

软件变更管理

需求管理规范

系统设计规范

开发工程师

编码注释规范

系统测试规范

测试工程师

质量管理方案

质量工程师

3.3.3实施过程质量控制

在项目实施阶段，主要参照ISO9001质量标准，对项目实施过程中的主要活动，充分尊重和满足客户需求，主动和客户讨论具体的实施方案，客户同意后再具体实施。

实施活动

系统应用软件及接口联调

ISO9001_系统开发集成和项目实施要求、顾客要求控制规范

提交系统测试报告

应用培训

培训工程师

提交培训效果评估报告

系统联调和试运行

提交联调结果分析报告

系统工程师

提交系统交付报告

技术服务

提交技术服务客户反馈表

3.3.4工作提交物质量控制及编写要求

3.3.4.1工作提交物质量控制

在系统项目中，重点控制以下工作提交物的质量。

工作提交物

软件项目开发计划

项目管理层评审通过

项目开发进度报告

内容符合文档模板要求

需求规格说明书

需求工程师

客户代表/项目经理/质量经理/主要设计工程师评审通过

概要设计说明书

设计工程师

开发经理/主要设计工程师评审通过

逻辑模型及物理模型设计说明书（含接口）

数据字典

系统程序源码

符合编码注释规范

用户操作手册

系统测试方案

开发经理/主要工程师评审通过

系统测试报告

培训手册

项目交付报告

说明：

责任人负责按照开发进度计划提交工作提交物，并通知QA组发起评审；

评审必须有QA工程师参加，必须有评审记录；

QA工程师负责评审中发现的问题跟踪。

3.3.4.2工作提交物编写要求

工作提交物文档基本结构：

封面、历史记录、目录、正文部分、附录、参考文献。

封面

文档封面主要由文件编号、文档适用范围、项目名称、内容主题和文档控制信息等几部分内容组成。

其中，文档控制信息应包括五个方面的基本内容：

编撰、审核、批准、生效日期和密级。

历史记录

为便于跟踪，应以表格方式记录文档的修改历史，具体内容包括：

修订日期、版本号、修订人和修改说明。

目录

为便于查阅，文档应该生成相应的目录。

目录层次不易过多，只要显示到3级即可。

正文部分

正文部分包含了文档的核心内容，可根据各文档的具体要求编写相关的章节段落。

附录

正文部分不便与列出的补充资料，可放置在附录部分加以说明。

参考文献

参考文献部分用于列举曾经在正文中被引用过的、正式发表的文献资料，以便读者查阅。

3.4风险管理

所有的项目风险均隔周审核、更新一次。

当一个项目风险升级为项目问题时，项目经理必须在《项目周报》中加以反映，以确保项目领导小组成员及时解决问题。

项目管理风险表需要维护、存放在项目版本管理系统的公共目录下，以便项目组所有成员方便、及时的查阅。

3.5项目监控

我们在项目实施时将建立完善的项目监控机制，延用公司专业化的项目组汇报制度，包括：

项目组每周五下午由项目经理召集举行项目工作例会，内容包括当前工作进度和主要问题；

项目经理主持讨论工作汇报和问题讨论；

所有会议上讨论的问题（包括：

项目管理、技术争议）均应在会议上达成解决方案，项目经理根据会议记录跟踪相关解决方案或决议的落实情况；

项目经理每周汇总工作周报，同时抄送给项目组全体成员。

3.6软件测试

3.6.1测试策略

系统测试作为重要的质量保证手段，在软件项目开发中占有举足轻重的位置。

本项目的系统测试策略如下：

对测试任务划分阶段和重点：

系统测试工作整体划分为测试准备、测试开发和测试执行三个阶段，每个阶段的工作任务重点不同，便于提高工作效率和质量。

测试准备充分：

在系统测试开始前的准备阶段，测试人员充分了解业务功能和流程，熟悉系统需求和系统总体设计，做到对系统有整体认识和把握。

测试开发：

根据工作系统需求和系统总体设计要求，编写测试用例。

测试执行：

根据编写好的测试用例对系统进行测试，由于系统功能多，时间和人力资源有限，需要区分关键功能和业务流程。

对系统功能、业务流程、系统接口、系统性能和稳定性，重点测试。

3.6.2测试方案

根据系统的特点，项目总体测试方案如下，详细的系统测试方案在《需求规格说明书》和《概要设计说明书》定稿后完成。

根据项目开发计划和模型，功能测试和流程测试会安排多轮（详细安排会在测试计划中体现），每轮完成后提交测试报告。

1、测试方法

在这系统中，根据不同的测试类型，采用不同的测试方法，具体如下：

功能测试

根据《需求规格说明书》编写覆盖全部需求的功能测试案例，逐个执行这些测试案例，根据执行结果填写功能测试报告，发现缺陷提交缺陷记录并进入缺陷跟踪流程；

流程测试

根据《业务规范》、《技术规范》和《概要设计说明书》编写覆盖全部流程测试案例，逐个执行这些测试案例，根据执行结果填写功能测试报告，发现缺陷提交缺陷记录并进入缺陷跟踪流程；

采用自动测试工具把测试执行过程脚本化，提高测试执行效率；

性能和负载测试

根据《技术规范》，设计覆盖全部性能指标和稳定性指标的测试场景方案，使用性能和负载测试工具完成这些测试方案，提交性能和负载测试分析报告，帮助和配合系统开发人员完成系统性能调优工作；

硬件主机网络测试

根据《技术规范》，设计覆盖主要硬件指标的测试案例并执行，提交测试结果报告；

安全测试

根据《技术规范》，设计覆盖主要安全指标的测试案例并执行，提交测试结果报告；

操作性和适用性测试

根据《技术规范》，设计覆盖主要操作性和适用性指标的测试案例并执行，提交测试结果报告；

用户测试

根据用户要求，帮助和配合用户对系统进行各种测试；

上线测试

根据《需求规格说明书》和《需求差异化分析》，增加和完善功能和流程测试案例，逐个执行这些测试案例，根据执行结果填写功能测试报告，发现缺陷提交缺陷记录并进入缺陷跟踪流程。

2、测试环境

测试管理环境

用于测试案例和测试缺陷的记录、跟踪和分析，采用专业的测试管理工具搭建测试管理环境。

开发测试执行环境

包括数据库服务器、网络环境，要求和开发环境独立，软硬件配置和开发环境保持一致。

上线联调环境

包括数据库服务器、网络环境，要求和开发环境独立，和实际的外部系统连通。

3.6.3测试管理流程

流程说明：

测试准备：

根据项目进度计划和总体测试方案，制定测试计划；

熟悉业务规范和系统需求；

熟悉系统平台架构和总体设计方案；

准备测试工具和环境；

根据测试计划，完成全部的测试案例设计并通过主要设计人员的评审；

根据开发进度，制定测试执行计划；

根据测试执行计划执行相关测试案例，观察、记录和分析测试结果；

根据测试结果完善测试案例的设计；

缺陷跟踪：

分析测试结果，属于系统缺陷的，提交缺陷记录，进入缺陷跟踪流程；

督促相关人员修复缺陷，进行缺陷修复验证；

测试评估：

每轮测试结束后，提交相关测试报告，提出测试覆盖率和测试通过率的量化指标及改进措施等；

全部测试结束后，提