2022年维护类项目实施方案_第1页
2022年维护类项目实施方案_第2页
2022年维护类项目实施方案_第3页
2022年维护类项目实施方案_第4页
2022年维护类项目实施方案_第5页
已阅读5页,还剩10页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

整理范本整理范本..整理范本.文件编号:密级:工程ID:工程编号:维护类工程实施方案版本【V1.00】拟制日期审核日期批准日期声明本文件所有权和解释权归GDTEC所有,未经GDTEC书面许可,不得复制或向第三方公开。修订历史记录版本日期AMD修订者说明V1.002021-01-17A田冬添加,M-修改,D-删除〕目录1. 系统架构设计 41.1系统特点 41.2系统任务的类型 41.3系统设计原那么 41.4、用户界面设计原那么 51.5数据建模原那么 52、概要设计 62.1、设计原那么 6统一设计原那么 6先进性原那么 6高可靠/高平安性原那么 7标准化原那么 7成熟性原那么 7适用性原那么 7可扩展性原那么 73、工程启动 74、需求管理 84.1需求调研 84.2需求分析 94.3需求变更 95、范围控制 116、进度控制 117、质量保证 12QA经理 12QA工程师 128、沟通管理 12工程经理 12工程组 13QA工程师 139、风险控制 13 在出现不可修复的危害之前准备修复方案; 1310、保密措施 13公司保密制度 13工程保密制度 1411、技术与支持 14资深专家技术支持 14合作、交流与培训 14系统架构设计1.1系统特点总体资源和时间在合同中确定,阶段点处会调整面向不同的客户,需要有较强的沟通能力先期未参与开发,要求快速地理解和对应能力维护任务随机性强,要求合理地定制和调整方案客户参与度高,要求使用度量数据了解和控制工程的执行1.2系统任务的类型新增功能开发缺陷修改文档修改需求变更1.3系统设计原那么业务规那么是支持企业决策,影响或控制企业业务行为的指示,它是企业处理业务过程中始终要遵循的规那么,而工作流那么是根据业务规那么制定的实际应用当中需要流转的程序。在系统的编制过程中将严格遵守业务规那么和根据业务规那么制定的工作流程,在系统的编程中业务规那么是一条语句,它定义或约束业务的某些方面。其目的是对业务结构做出断言,或者对业务行为施加控制和影响。开发时通过制定严格的开发标准,并通过严格的工程管理和实施方法来标准程序员的编码标准,提高系统的可维护性;在数据建模时也会采用基于标准的扩展的数据模型构建方法,在数据交换、系统接口等领域也基于国家数据交换标准进行设计与开发;在系统的整体设计开发实施维护过程,都将基于国际国内的主流标准进行。由于系统是根据标准架构和分层编写而成,对于想增加工作流程或者业务规那么的情况,系统也可以很容易的进行扩展,如在系统中参加的新的业务规那么只要在层次上分清属于系统的哪一层次,在系统的层次中新参加组件就可以很方便和容易的对系统进行扩展。在系统中,复用是减少代码量和代码可读性一个必须要考虑的问题。需要用到的重复代码需要编写可复用的方法,对接口的定义需要考虑到相同功能中所有的问题编写可复用的接口,公用的类也可以做到复用。1.4、用户界面设计原那么系统的界面风格统一采用编制好的CSS文件,对单元格、按钮、下拉列表、文本框都进行统一的规格化,页面布局采用左边菜单项右边功能页的页面布局。在内容填充中,对每一录入项都进行数据合法化校验,如果出现异常和错误将采用统一的报错页面和易懂的提示语言对异常或错误进行描述。对于用户操作来说,越容易、越简便越好,在系统的编制过程中我们将表达以人为本的友好操作页面,根据登陆人的不同,根据权限的不同对每个人的操作页面都能做到定制,方便操作人的操作和管理。由于系统采用同步和异步两种方式进行数据的交互,异步操作可以使用户更加方便的在页面操作过程中和数据库中的数据进行交互,同步操作可以使用户提交页面时实时的对提交的内容进行查看和修改。系统提供在操作过程中根据输入项和功能来提示的功能来帮助用户更好的使用和操作系统。1.5数据建模原那么既继承又创新;数据模型将会对原有系统中使用较成熟局部进行继承,一方面有利于提高系统成功几率,另一方面也方便与数据的移植;在继承的根底上,对于原有系统中不成熟局部将针对原有数据模型存在的问题进行重新设计。既继承又创新的数据模型设计原那么,是数据模型设计成功的保障。数据的完整性与一致性;数据的完整性和一致性是原有系统数据库存在的主要问题之一,一个个别离的数据库相对独立,和其他数据库不存在直接的完整性和一致性规那么,本次开发将对原有系统数据模型进行整合,一方面从数据模型层面保证数据的完整性和一致性,另一方面消除原有数据库的一个个信息孤岛,为查询、统计、分析等业务管理效劳。主要变化的适应性;在系统建设时,将对业务进行充分的分析,对于可能存在的主要变化进行研究,在数据模型设计时将充分考虑这些变化性,数据模型将能对这种变化性进行适应。数据模型在设计时将采用纵向和横向两种结构进行设计,对于变化的适应性,可以采用纵向字段语义扩展和横向结构两种方法来对变化性进行适应。数据模型的标准化;数据建模过程中,采用标准的数据建模工具,遵循数据模型的建设标准,使用国际、国家等数据标准,对于数据接口也采用标准的数据接口标准。支持数据的移植;数据的移植也是新系统数据模型建设需要考虑的一个重要问题。一方面,我们将对原有系统的成熟数据模型进行继承,以便于进行数据移植,另一方面,对于新数据模型,会建立新旧数据模型之间的映射关系,并消除中间产生的冲突。在移植时,为了可以准确高效的进行数据的移植,可以借助于第三方的数据移植工具。实施时,将根据系统实际情况,进行分步的数据移植和系统的切换。2、概要设计系统建立在各种标准之上,架构标准、数据标准等,并将在实际开发过程中建立统一的系统开发标准标准体系,从整体上提高系统的水平,便于与外部机构进行接轨。2.1、设计原那么统一设计原那么统筹规划和统一设计系统结构。尤其是应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容,均需从全局出发、从长远的角度考虑。数据库和接口涉及需要考虑相互的统一性,保证系统的接口与数据存储的一致性,保证系统的高性能应用。先进性原那么系统构成必须采用成熟、具有国内先进水平,并符合国际开展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的标准、标准,借鉴国内外目前成熟的主流网络和综合信息系统的体系结构,以保证系统具有较长的生命力和扩展能力。保证先进性的同时还要保证技术的稳定、平安性。采用先进的系统架构,能够为将来的系统规划提供便利,为今后的开展奠定根底。高可靠/高平安性原那么系统设计和数据架构设计中充分考虑系统的平安和可靠。对于高性能要求平台系统来说,必须保证系统得平安可靠。才能获得持久稳定的开展。标准化原那么支持业务开展、横向的信息扩展和宏观管理的要求,系统对操作的标准化,即系统有检入检出的机制,确保数据维护的一致性和版本控制的可操作性。系统对数据导入导出采用统一标准接口,如采用现在最流行的XML标准。成熟性原那么在开发工具的选型阶段,应该尽量选择成熟的产品和标准,如.net、XML、ADO.NET、ODBC之类已经成为标准的、被大量实践所采用的技术。选用具有成熟性,可持续开展性的开发工具。系统要采用国际主流、成熟的体系架构来构建,实现跨平台的应用。适用性原那么保护已有资源,急用先行,在满足应用需求的前提下,尽量降低建设本钱。目前现有系统独立建立,数据库分散,但是数据库资源丰富,有大量的效劳器。所以缩减本钱,充分利用现有系统是保证节约本钱的重要局部。可扩展性原那么系统设计要考虑到业务未来开展的需要,尽可能设计得简明,降低各功能模块耦合度,并充分考虑兼容性。系统能够支持对多种格式数据的存储。对于海量数据的存储,系统的设计必须考虑高效和别离的部署结构,不仅保证能够轻松建立接口,而且能够提高数据库的扩展能力。3、工程启动工程合同或协议的签订标志着工程的正式启动。工程启动阶段的主要任务是:召开工程启动会确定工程范围:通过初步的需求调研,明确工程开发的范围形成工程方案:包括软件开发方案、量化管理方案、风险管理方案、组间协调方案、质量保证方案、配置管理方案等评审工程初始需求及工程方案工作流程图如下:4、需求管理4.1需求调研①调研用户领域的组织结构、岗位设置和职责定义,从功能上区分有多少个子系统,划分系统的大致范围,明确系统的目标。②调研每个子系统所需的工作流程、功能与处理规那么,收集单据、报表和账本等原始资料,分析物流、资金流和信息流三者的关系,以及如何用数据流来表示这三者的关系。③对调研的内容事先准备,针对不同管理层次的用户询问不同的问题,列出问题清单。将操作层、管理层和决策层的需求既联系,又区分开来,形成一个金字塔,使下层满足上层的需求。④对与用户沟通的情况及时总结归纳,整理调研结果,找出新的疑点,初步构成需求基线。⑤假设基线符合要求,那么需求分析完毕;反之返回到第1步或第2或第3步。如此循环屡次,直到需要分析使双方满意为止。4.2需求分析需求分析阶段主要是指工程组对用户需求进行进一步调研分析,最终形成用户确认的系统需求说明书的过程。在这个过程中包含需求调研分析、需求评审、细化软件开发方案等内容。4.3需求变更需求变更流程(客户提出需求变更)执行条件:客户提出需求变更图:需求变更流程流程说明:需求来源:客户提交相关需求变更审核需求变更:评估如果实现该需求,需要的时间、人力本钱多少;并评估对工程工期影响有多大?判断那些需求能够目前解决,那些需要留到下一版本解决。最后输出一份审核确认表反响给客户,和客户进行商讨。参与评审的人员要包含工程经理,工程组长,测试组长,市场人员。配置管理员:对变更需求进行记录,需求文档进行更新,并通知相关人员工程组长:负责调整相关开发进度表,评估任务时间,分发给相关开发人员测试组长:根据变更需求和开发进度,对测试进度进行相对应调整,并修改测试需求分析书,分发需求更新给相关测试人员。测试人员对用例进行补充,修改。客户提交的变更需求最后必须让客户进行签字确认。5、范围控制公司有严格的工程范围管理体系,进行变更管理,变更控制。从在工程启动开始就明确需求,量化需求,需求阶段明确需求的可验证,可跟踪,无二义性等。进行评审确认后,工程组在CMMI的变更管理过程指导下制定工程的变更控制管理过程,在工程实施过程中,用户的需求变更都是按照事先指定好的过程执行。范围分解WBS〔workbreakdownstructures〕即工程工程工作分解结构是指定方案在工程启动开始后,把工程主要的可交付成果细分成较小的、更易管理的组分。工程组以工程进度为依据划分WBS〔Workbreakdownstructure〕,第一层是大的工程成果框架,每层下面再把工作分解。WBS结构最底层的分为是管理工程所需的最低层次的,可管理,可量化的,同时也是可跟踪的任务。范围变更控制公司的工程管理体系中有一套严格、高效、实用的变更管理流程。变更控制程序经过多年持续不断改进的及反复实践变更管理流程。6、进度控制工程经理根据工程方案、已设定的相关阈值和控制规那么分析偏差;对于需控制的偏差,应分析其产生的原因,并制定相应的预防和纠正措施。必要时修改工程各项方案,包括工程性能及质量目标。工程经理根据制定措施,安排工程工作。工程经理每周通过例会等了解工程情况,以便尽早发现偏差。例会的内容通常包括:进度/质量情况、偏差说明、问题分析、新的方案及任务分工等。工程经理每周报告工程的进展情况,分析工程偏差,说明偏差纠正措施。工程经理跟踪纠正偏差的过程,直到偏差被消除为止。工程主管审核纠正偏差的措施和效果。7、质量保证质量保证工作,主要设计QA经理、QA工程师。QA经理协调安排QA组的活动参与QA方案制定和评审定期向工程主管报告QA组的活动状态QA工程师参加工程准备工作,参与软件工程开发方案、工程约定等内容的制定和评审制定并执行工程QA方案参加工程组例会每周对工程进行检查,填写质量周报、QA问题与处理单定期地对工程进行审计,并报告审计结果协助工程经理制定偏差修改方案将工程组内不能解决的问题上报QA经理和工程经理8、沟通管理沟通管理主要涉及工程经理、工程组之间、QA协调人员。沟通管理从角色来进行如下设置:工程经理定期评审组间协调活动处理组间不能解决的问题监督和协调技术活动并解决技术问题工程经理无法完成上述活动时,需上报工程主管和部门经理工程组建立系统需求监督和协调技术活动并解决技术问题确定组间协调方案和关键依赖关系协调组间工作和关键依赖关系定期召开技术评审和交流会议QA工程师评审和〔或〕审核组间协调活动和工作产品,并报告结果9、风险控制找出潜在的问题和风险,每周提交风险列表;尽量防止风险,清楚定义工程中所需要的步骤、任务和事件从而消除潜在的风险;降低风险,每周提供风险躲避方案,指定措施减轻各种风险;在出现不可修复的危害之前准备修复方案;成认风险,记录工程管理中索发生的风险;为了有效发现风险,躲避风险,在工程整个生命周期每周QA组,工程组都会各自提供一份,工程组?技术风险、工程管理风险?列表,风险管理的过程记录在案,工程经理每周会汇报?技术风险、工程管理风险?躲避及处理方法。随着时间推移,风险逐渐接受处理,转移,或者躲避的过程。文档中记录工程风险发生概率,处

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论