维护类项目实施方案.docx
《维护类项目实施方案.docx》由会员分享，可在线阅读，更多相关《维护类项目实施方案.docx（12页珍藏版）》请在冰豆网上搜索。
维护类项目实施方案
文件编号：
密级：
项目ID：
项目编号：
维护类项目
实施方案
版本【V】
拟制
日期
审核
日期
批准
日期
声明
本文件所有权和解释权归GDTEC所有，未经GDTEC书面许可，不得复制或向第三方公开。
修订历史记录
版本
日期
AMD
修订者
说明
V
2011-01-17
A
田冬
添加，M-修改，D-删除）
系统架构设计
系统特点
总体资源和时间在合同中确定，阶段点处会调整
面向不同的客户，需要有较强的沟通能力
先期未参与开发，要求快速地理解和对应能力
维护任务随机性强，要求合理地定制和调整计划
客户参与度高，要求使用度量数据了解和控制项目的执行
系统任务的类型
新增功能开发
缺陷修改
文档修改
需求变更
系统设计原则
业务规则是支持企业决策，影响或控制企业业务行为的指示，它是企业处理业务过程中始终要遵循的规则，而工作流则是根据业务规则制定的实际应用当中需要流转的程序。
在系统的编制过程中将严格遵守业务规则和根据业务规则制定的工作流程，在系统的编程中业务规则是一条语句，它定义或约束业务的某些方面。
其目的是对业务结构做出断言，或者对业务行为施加控制和影响。
开发时通过制定严格的开发规范，并通过严格的项目管理和实施方法来规范程序员的编码规范，提高系统的可维护性；在数据建模时也会采用基于标准的扩展的数据模型构建方法，在数据交换、系统接口等领域也基于国家数据交换标准进行设计与开发；在系统的整体设计开发实施维护过程，都将基于国际国内的主流标准进行。
由于系统是根据标准架构和分层编写而成，对于想增加工作流程或者业务规则的情况，系统也可以很容易的进行扩展，如在系统中加入的新的业务规则只要在层次上分清属于系统的哪一层次，在系统的层次中新加入组件就可以很方便和容易的对系统进行扩展。
在系统中，复用是减少代码量和代码可读性一个必须要考虑的问题。
需要用到的重复代码需要编写可复用的方法，对接口的定义需要考虑到相同功能中所有的问题编写可复用的接口，公用的类也可以做到复用。
、用户界面设计原则
系统的界面风格统一采用编制好的CSS文件，对单元格、按钮、下拉列表、文本框都进行统一的规格化，页面布局采用左边菜单项右边功能页的页面布局。
在内容填充中，对每一录入项都进行数据合法化校验，如果出现异常和错误将采用统一的报错页面和易懂的提示语言对异常或错误进行描述。
对于用户操作来说，越容易、越简便越好，在系统的编制过程中我们将体现以人为本的友好操作页面，根据登陆人的不同，根据权限的不同对每个人的操作页面都能做到定制，方便操作人的操作和管理。
由于系统采用同步和异步两种方式进行数据的交互，异步操作可以使用户更加方便的在页面操作过程中和数据库中的数据进行交互，同步操作可以使用户提交页面时实时的对提交的内容进行查看和修改。
系统提供在操作过程中根据输入项和功能来提示的功能来帮助用户更好的使用和操作系统。
数据建模原则
既继承又创新；
数据模型将会对原有系统中使用较成熟部分进行继承，一方面有利于提高系统成功几率，另一方面也方便与数据的移植；在继承的基础上，对于原有系统中不成熟部分将针对原有数据模型存在的问题进行重新设计。
既继承又创新的数据模型设计原则，是数据模型设计成功的保障。
数据的完整性与一致性；
数据的完整性和一致性是原有系统数据库存在的主要问题之一，一个个分离的数据库相对独立，和其他数据库不存在直接的完整性和一致性规则，本次开发将对原有系统数据模型进行整合，一方面从数据模型层面保证数据的完整性和一致性，另一方面消除原有数据库的一个个信息孤岛，为查询、统计、分析等业务管理服务。
主要变化的适应性；
在系统建设时，将对业务进行充分的分析，对于可能存在的主要变化进行研究，在数据模型设计时将充分考虑这些变化性，数据模型将能对这种变化性进行适应。
数据模型在设计时将采用纵向和横向两种结构进行设计，对于变化的适应性，可以采用纵向字段语义扩展和横向结构两种方法来对变化性进行适应。
数据模型的标准化；
数据建模过程中，采用标准的数据建模工具，遵循数据模型的建设标准，使用国际、国家等数据标准，对于数据接口也采用标准的数据接口标准。
支持数据的移植；
数据的移植也是新系统数据模型建设需要考虑的一个重要问题。
一方面，我们将对原有系统的成熟数据模型进行继承，以便于进行数据移植，另一方面，对于新数据模型，会建立新旧数据模型之间的映射关系，并消除中间产生的冲突。
在移植时，为了可以准确高效的进行数据的移植，可以借助于第三方的数据移植工具。
实施时，将根据系统实际情况，进行分步的数据移植和系统的切换。
2、概要设计
系统建立在各种标准之上，架构标准、数据标准等，并将在实际开发过程中建立统一的系统开发标准规范体系，从整体上提高系统的水平，便于与外部机构进行接轨。
、设计原则
统一设计原则
统筹规划和统一设计系统结构。
尤其是应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容，均需从全局出发、从长远的角度考虑。
数据库和接口涉及需要考虑相互的统一性，保证系统的接口与数据存储的一致性，保证系统的高性能应用。
先进性原则
系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。
在设计过程中充分依照国际上的规范、标准，借鉴国内外目前成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。
保证先进性的同时还要保证技术的稳定、安全性。
采用先进的系统架构，能够为将来的系统规划提供便利，为今后的发展奠定基础。
高可靠/高安全性原则
系统设计和数据架构设计中充分考虑系统的安全和可靠。
对于高性能要求平台系统来说，必须保证系统得安全可靠。
才能获得持久稳定的发展。
标准化原则
支持业务开展、横向的信息扩展和宏观管理的要求，系统对操作的标准化，即系统有检入检出的机制，确保数据维护的一致性和版本控制的可操作性。
系统对数据导入导出采用统一标准接口，如采用现在最流行的XML标准。
成熟性原则
在开发工具的选型阶段，应该尽量选择成熟的产品和规范，如、XML、、ODBC之类已经成为标准的、被大量实践所采用的技术。
选用具有成熟性，可持续发展性的开发工具。
系统要采用国际主流、成熟的体系架构来构建，实现跨平台的应用。
适用性原则
保护已有资源，急用先行，在满足应用需求的前提下，尽量降低建设成本。
目前现有系统独立建立，数据库分散，但是数据库资源丰富，有大量的服务器。
所以缩减成本，充分利用现有系统是保证节约成本的重要部分。
可扩展性原则
系统设计要考虑到业务未来发展的需要，尽可能设计得简明，降低各功能模块耦合度，并充分考虑兼容性。
系统能够支持对多种格式数据的存储。
对于海量数据的存储，系统的设计必须考虑高效和分离的部署结构，不仅保证能够轻松建立接口，而且能够提高数据库的扩展能力。
3、项目启动
项目合同或协议的签订标志着项目的正式启动。
项目启动阶段的主要任务是：
召开项目启动会
确定项目范围：
通过初步的需求调研，明确项目开发的范围
形成项目计划：
包括软件开发计划、量化管理计划、风险管理计划、组间协调计划、质量保证计划、配置管理计划等
评审项目初始需求及项目计划
工作流程图如下：
4、需求管理
需求调研
①调研用户领域的组织结构、岗位设置和职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。
②调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表和账本等原始资料，分析物流、资金流和信息流三者的关系，以及如何用数据流来表示这三者的关系。
③对调研的内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。
将操作层、管理层和决策层的需求既联系，又区分开来，形成一个金字塔，使下层满足上层的需求。
④对与用户沟通的情况及时总结归纳，整理调研结果，找出新的疑点，初步构成需求基线。
⑤若基线符合要求，则需求分析完毕；反之返回到第1步或第2或第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组，项目组都会各自提供一份，项目组《技术风险、项目管理风险》列表，风险管理的过程记录在案，项目经理每周会汇报《技术风险、项目管理风险》规避及处理方法。
随着时间推移，风险逐渐接受处理，转移，或者规避的过程。
文档中记录项目风险发生概率，处理风险责任人，风险策略等，完整的风险控制机制。
10、保密措施
公司保密制度
为了保护客户的信息安全和技术机密，我们制定了严格的保密制度并采取严格的保密措施：
1、公司员工在签订劳务合同时，均需签署保密协议；
2、督促员学习和了解公司的保密制度和具体规定；
项目保密制度
项目过程中，采取严格的保密措施，主要体现为：
签署协议：
和客户签署《保密协议》，严格遵守协议中约定内容；
文档保密：
依靠先进的文档管理工具，采取多级权限设置，按照文档的密级，对文档的创建对象、修改对象和阅读对象进行控制，保证文档的阅读对象在可控范围内。
数据保密：
对客户的数据，实现生产库、测试库和开发库分离。
生产库数据严格控制对数据的操作，并有详细的数据操作日志，测试库和开发库数据经过处理，通过屏蔽、伪数据方式保护客户的重要数据。
11、技术与支持
资深专家技术支持
我公司承诺如贵公司有一些重要应急或分析项目的疑难问题，随时可以增加和调配公司其它专业的资深专家。
积极跟进项目进展情况，充分发挥公司专家团队的技术能力，保证项目开展过程有的放矢。
我公司承诺准备充足的技术过硬的后备技术专家力量，随时保证贵公司的项目要求。
资深专家队伍由经验丰富的业务、软件开发专家组成。
我方承诺在重要节日和大型活动期间，提供24小时热线电话，当系统出现意外故障，积极派出资深专家以最快的时效协助处理故障。
合作、交流与培训
如贵公司有需求，我公司将派出有经验的专业技术人员在现场进行相关技术的协助及问题的处理；如有技术上的疑问，我公司将上门进行技术交流。
我公司可以根据贵公司的需要，组织人员对项目的新技术、新软件和新标准进行专题研讨、技术交流和培训讲解。
发挥我公司在省内各地市项目技术经验的优势，积极开展与其它地市项目人员的交流、沟通，组织各地技术骨干、专家与贵公司进行交流，及时引进其它地区的方法、思路。
为加强双方共同合作，促进双方相互了解和配合，为使项目顺利进行，以及今后更好的合作，我公司保证可以为贵公司提供有深度的软件开发方面合作。
升级会员 