维护类项目实施方案.docx

1、维护类项目实施方案文件编号：v1.0可编辑可修改密级：项目ID :项目编号：维护类项目实施方案版本【V】拟制日期审核日期批准日期本文件所有权和解释权归 GDTEC所有，未经GDTEC书面许可，不得复制或向第三方公开。修订历史记录版本日期AMD修订者说明V2011-01-17A田冬（A-添加，M-修改，D-删除）1.系统架构设计系统特点 系统任务的类型.系统设计原则.、用户界面设计原则数据建模原则.2、概要设计 、设计原则 统一设计原则 先进性原则 高可靠/高安全性原则标准化原则 成熟性原则 适用性原则 可扩展性原则3、 项目启动 4、 需求管理 需求调研 需求分析需求变更5、范围控制10111

2、26、 进度控制 7、 质量保证 QA经理.QA工程师8、 沟通管理 项目经理项目组.12131313141414QA工程师9、风险控制 在岀现不可修复的危害之前准备修复计划;10、 保密措施 公司保密制度 项目保密制度 11、 技术与支持 资深专家技术支持 合作、交流与培训 151515151516141.系统架构设计2.系统特点E、维护任务随机性强，要求合理地定制和调整计划客户参与度高，要求使用度量数据了解和控制项目的执行系统任务的类型新增功能开发需求变更系统设计原则(1)业务规则是支持企业决策， 影响或控制企业业务行为的指示， 它是企业处理业务过程中始终要遵循的规则，而工作流则是根据业务

3、规则制定的实际应用当中需要流转的程序。在系统在系统的编制过程中将严格遵守业务规则和根据业务规则制定的工作流程,的编程中业务规则是一条语句，它定义或约束业务的某些方面。其目的是对业务结构做出断言，或者对业务行为施加控制和影响。(2)开发时通过制定严格的开发规范， 并通过严格的项目管理和实施方法来规范程序员的编码规范，提高系统的可维护性；在数据建模时也会采用基于标准的扩展的数据模型构建方法，在数据交换、系统接口等领域也基于国家数据交换标准进行设计与开发;系统的整体设计开发实施维护过程，都将基于国际国内的主流标准进行。(3)由于系统是根据标准架构和分层编写而成， 对于想增加工作流程或者业务规则的情况

4、，系统也可以很容易的进行扩展，如在系统中加入的新的业务规则只要在层次上分清属于系统的哪一层次，在系统的层次中新加入组件就可以很方便和容易的对系统进行扩展。需要用到的重(4) 在系统中，复用是减少代码量和代码可读性一个必须要考虑的问题。复代码需要编写可复用的方法， 对接口的定义需要考虑到相同功能中所有的问题编写可复用的接口，公用的类也可以做到复用。、用户界面设计原则(1) 系统的界面风格统一采用编制好的 CSS文件，对单元格、按钮、下拉列表、文本框都进行统一的规格化，页面布局采用左边菜单项右边功能页的页面布局。 在内容填充中,对每一录入项都进行数据合法化校验， 如果出现异常和错误将采用统一的报错

5、页面和易懂的提示语言对异常或错误进行描述。(2)对于用户操作来说，越容易、越简便越好，在系统的编制过程中我们将体现以人为本的友好操作页面，根据登陆人的不同，根据权限的不同对每个人的操作页面都能做到定制，方便操作人的操作和管理。(3)异步操作可以使用户更加方便由于系统采用同步和异步两种方式进行数据的交互,的对提交的内容进行查看和修改。(4) 系统提供在操作过程中根据输入项和功能来提示的功能来帮助用户更好的使用和操作系统。数据建模原则(1)既继承又创新;数据模型将会对原有系统中使用较成熟部分进行继承,方面有利于提高系统成功几率，另一方面也方便与数据的移植； 在继承的基础上，对于原有系统中不成熟部分

6、将针对原有数据模型存在的问题进行重新设计。 既继承又创新的数据模型设计原则， 是数据模型设计成功的保障。(2) 数据的完整性与一致性;数据的完整性和一致性是原有系统数据库存在的主要问题之一,一个个分离的数据库相对独立，和其他数据库不存在直接的完整性和一致性规则,本次开发将对原有系统数据模型进行整合，一方面从数据模型层面保证数据的完整性和一致性,另一方面消除原有数据库的一个个信息孤岛，为查询、统计、分析等业务管理服务。(3) 主要变化的适应性;在系统建设时，将对业务进行充分的分析， 对于可能存在的主要变化进行研究， 在数据模型设计时将充分考虑这些变化性，数据模型将能对这种变化性进行适应。数据模型

7、在设计时将采用纵向和横向两种结构进行设计,对于变化的适应性，可以采用纵向字段语义扩展和横向结构两种方法来对变化性进行适应。(4) 数据模型的标准化;数据建模过程中，采用标准的数据建模工具， 遵循数据模型的建设标准,使用国际、国家等数据标准，对于数据接口也采用标准的数据接口标准。(5) 支持数据的移植;数据的移植也是新系统数据模型建设需要考虑的一个重要问题。一方面，我们将对原有系统的成熟数据模型进行继承， 以便于进行数据移植，另一方面，对于新数据模型,会建立新旧数据模型之间的映射关系，并消除中间产生的冲突。在移植时，为了可以准确高效的进行数据的移植， 可以借助于第三方的数据移植工具。 实施时，将

8、根据系统实际情况，进行分步的数据移植和系统的切换。2、概要设计系统建立在各种标准之上，架构标准、数据标准等，并将在实际开发过程中建立统一的系统开发标准规范体系，从整体上提高系统的水平，便于与外部机构进行接轨。、设计原则统一设计原则统筹规划和统一设计系统结构。 尤其是应用系统建设结构、 数据模型结构、数据存储结构以及系统扩展规划等内容， 均需从全局岀发、从长远的角度考虑。数据库和接口涉及需要考虑相互的统一性，保证系统的接口与数据存储的一致性，保证系统的高性能应用。先进性原则系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借

9、鉴国内外目前成熟的主流网络和综合信息系统的 体系结构，以保证系统具有较长的生命力和扩展能力。保证先进性的同时还要保证技术的稳定、 安全性。采用先进的系统架构，能够为将来的系统规划提供便利，为今后的发展奠定基础。高可靠/高安全性原则对于高性能要求平台系统来说,系统设计和数据架构设计中充分考虑系统的安全和可靠。须保证系统得安全可靠。才能获得持久稳定的发展。标准化原则系统对数据导入导岀采用统一标准接、XML、ODBC之类已经成岀的机制，确保数据维护的一致性和版本控制的可操作性。口，如采用现在最流行的 XML标准。成熟性原则在开发工具的选型阶段，应该尽量选择成熟的产品和规范, 为标准的、被大量实践所采

10、用的技术。选用具有成熟性，可持续发展性的开发工具。系统要采用 国际主流、成熟的体系架构来构建，实现跨平台的应用。适用性原则立建立，数据库分散，但是数据库资源丰富，有大量的服务器。所以缩减成本，充分利用现有系 统是保证节约成本的重要部分。可扩展性原则分考虑兼容性。系统能够支持对多种格式数据的存储。 对于海量数据的存储， 系统的设计必须考 虑高效和分离的部署结构，不仅保证能够轻松建立接口，而且能够提高数据库的扩展能力。3、项目启动项目合同或协议的签订标志着项目的正式启动。项目启动阶段的主要任务是:召开项目启动会 确定项目范围：通过初步的需求调研，明确项目开发的范围 形成项目计划：包括软件开发计划、

11、量化管理计划、风险管理计划、组间协调计划、 质量保证计划、配置管理计划等 评审项目初始需求及项目计划工作流程图如下:4、需求管理需求调研1调研用户领域的组织结构、岗位设置和职责定义，从功能上区分有 多少个子系统，划分系统的大致范围，明确系统的目标。2调研每个子系统所需的工作流程、功能与处理规则，收集单据、报 表和账本等原始资料，分析物流、资金流和信息流三者的关系，以及如何 用数据流来表示这三者的关系。3对调研的内容事先准备，针对不同管理层次的用户询问不同的问 题，列出问题清单。将操作层、管理层和决策层的需求既联系，又区分开 来，形成一个金字塔，使下层满足上层的需求。4对与用户沟通的情况及时总结

12、归纳， 整理调研结果，找出新的疑点,初步构成需求基线。3步。如此循环多次，直到需要分析使双方满意为止。需求分析需求分析阶段主要是指项目组对用户需求进行进一步调研分析，最终形成用户确认的系统需求说明书的过程。在这个过程中包含需求调研分析、需求评审、细化软件开发计划等内容。需求变更需求变更流程（客户提出需求变更）执行条件：客户提出需求变更霁户提岀需求变史邮件通知相关 人员丿跋人员测试人员1配酬理员顶H组长测试组长图：需求变更流程流程说明:需求来源：客户提交相关需求变更审核需求变更：评估如果实现该需求，需要的时间、人力成本多少；并评估对项目工期影响有多大判断 那些需求能够目前解决，那些需要留到下一版

13、本解决。最后输出一份审核确认表反馈给客户，和客户进行 商讨。参与评审的人员要包含项目经理，项目组长，测试组长，市场人员。配置管理员：对变更需求进行记录，需求文档进行更新，并通知相关人员项目组长：负责调整相关开发进度表，评估任务时间，分发给相关开发人员测试组长：根据变更需求和开发进度，对测试进度进行相对应调整，并修改测试需求分析书，分发需求 更新给相关测试人员。测试人员对用例进行补充，修改。客户提交的变更需求最后必须让客户进行签字确认。5、范围控制公司有严格的项目范围管理体系， 进行变更管理，变更控制。从在项目启动开始就明确需求,项目组在CMMI量化需求，需求阶段明确需求的可验证， 可跟踪，无二

14、义性等。进行评审确认后,按照事先指定好的过程执行。范围分解WB( work breakdown structures )即工程项目工作分解结构是指定计划在项目启动开始后, 把项目主要的可交付成果细分成较小的、更易管理的组分。项目组以项目进度为依据划分 WBS( Work breakdow n structure )，第一层是大的项目成果框架，每层下面再把工作分解。 WBS结构最底层的分为是管理项目所需的最低层次的，可管理, 可量化的，同时也是可跟踪的任务。范围变更控制续不断改进的及反复实践变更管理流程。6、进度控制1.项目经理根据项目计划、已设定的相关阈值和控制规则分析偏差;2.对于需控制的偏

15、差，应分析其产生的原因，并制定相应的预防和纠正措施。5.6.项目经理每周通过例会等了解项目情况，以便尽早发现偏差。例会的内容通常包括：进度 /质量情况、偏差说明、问题分析、新的计划及任务分工等。项目经理每周报告项目的进展情况，分析项目偏差，说明偏差纠正措施。7、质量保证质量保证工作，主要设计 QA经理、QA工程师。QA经理QA工程师1.参加项目准备工作，参与软件项目开发计划、项目约定等内容的制定和评审4.每周对项目进行检查，填写质量周报、 QA问题与处理单5.定期地对项目进行审计，并报告审计结果6.协助项目经理制定偏差修改方案7.将项目组内不能解决的问题上报 QA经理和项目经理8沟通管理沟通管

16、理主要涉及项目经理、项目组之间、QA协调人员。沟通管理从角色来进行如下设置:项目经理1.定期评审组间协调活动2.处理组间不能解决的问题3.监督和协调技术活动并解决技术问题项目经理无法完成上述活动时，需上报项目主管和部门经理 项目组建立系统需求监督和协调技术活动并解决技术问题确定组间协调计划和关键依赖关系协调组间工作和关键依赖关系定期召开技术评审和交流会议QA工程师评审和（或）审核组间协调活动和工作产品，并报告结果9、风险控制找岀潜在的问题和风险，每周提交风险列表;尽量避免风险，清楚定义项目中所需要的步骤、任务和事件从而消除潜在的风险;降低风险，每周提供风险规避计划，指定措施减轻各种风险;在岀现

17、不可修复的危害之前准备修复计划;承认风险，记录项目管理中索发生的风险;为了有效发现风险，规避风险，在项目整个生命周期每周QA组，项目组都会各自提供一份，项目组技术风险、项目管理风险列表，风险管理的过程记录在案，项目经理每周会汇报技术风险、项目管理风险规避及处理方法。随着时间推移，风险逐渐接受处理,转移，或者规避的过程。文档中记录项目风险发生概率，处理风险责任人，风险策略等，完整的风险控制机制。10、保密措施公司保密制度为了保护客户的信息安全和技术机密， 我们制定了严格的保密制度并采取严格的保密措施:1、公司员工在签订劳务合同时，均需签署保密协议;2、督促员学习和了解公司的保密制度和具体规定;项

18、目保密制度项目过程中，采取严格的保密措施，主要体现为:1.签署协议： 和客户签署保密协议，严格遵守协议中约定内容;2.文档保密：依靠先进的文档管理工具，采取多级权限设置，按照文档的密级，对文档的创建对象、修改对象和阅读对象进行控制，保证文档的阅读对象在可控范围内。3.数据保密：对客户的数据，实现生产库、测试库和开发库分离。生产库数据严格控制对数据的操作，并有详细的数据操作日志，测试库和开发库数据经过处理，通过屏蔽、伪数据方式保护客户的重要数据。11、技术与支持资深专家技术支持1、我公司承诺如贵公司有一些重要应急或分析项目的疑难问题，随时可以增加和调配公司其它专业的资深专家。2、积极跟进项目进展

19、情况，充分发挥公司专家团队的技术能力，保证项目开展过程有的放矢。3、我公司承诺准备充足的技术过硬的后备技术专家力量，随时保证贵公司的项目要求。资深专家队伍由经验丰富的业务、软件开发专家组成。4、我方承诺在重要节日和大型活动期间，提供24小时热线电话，当系统岀现意外故障,积极派岀资深专家以最快的时效协助处理故障。合作、交流与培训1、如贵公司有需求，我公司将派岀有经验的专业技术人员在现场进行相关技术的协助及问题的处理；如有技术上的疑问，我公司将上门进行技术交流。2、我公司可以根据贵公司的需要，组织人员对项目的新技术、新软件和新标准进行专题研讨、技术交流和培训讲解。3、发挥我公司在省内各地市项目技术经验的优势，积极开展与其它地市项目人员的交流、沟通，组织各地技术骨干、专家与贵公司进行交流，及时引进其它地区的方法、思路。4、为加强双方共同合作，促进双方相互了解和配合，为使项目顺利进行，以及今后更好的合作，我公司保证可以为贵公司提供有深度的软件开发方面合作。