系统建设项目实施组织方案.docx
《系统建设项目实施组织方案.docx》由会员分享，可在线阅读，更多相关《系统建设项目实施组织方案.docx（34页珍藏版）》请在冰豆网上搜索。
系统建设项目实施组织方案
系统建设项目
实施组织方案
1建设需求
Ø总体性能指标如下：
系统支持在线用户数1800人，并发用户数100人，客户端请求响应时间不超过10秒,故障恢复时间小于4个小时，具有故障恢复和安全备份功能。
1.1数据需求
为使甲方政务办公管理平台数据能够安全可靠的使用，应能保证在数据库发生问题时快速可靠的进行数据恢复。
要求备份数据存储于内网并提供异机备份，保障数据的可靠性且不会泄露。
1.2性能需求
系统主要性能指标需求如下：
（1）高效运行
要求系统运行速度较快，操作响应时间不高于5秒。
系统应具备快速响应各用户端的数据服务请求的能力，平均数据响应时间小于5秒。
（2）稳定性
保证系统5×8小时长期稳定不间断的正常运转；系统必须有足够的健壮性，在软、硬件发生意外故障等情况下，能够很好的处理并尽快恢复，恢复时间不高于4小时。
（3）并行性
系统支持多用户并发访问，在并发用户30个的情况下，反应时间不大于5秒。
（4）可维护性
系统提供对自身的维护功能，实现数据的备份和恢复。
各项维护操作应尽量简单、清晰，减少手工维护工作量。
系统维护时尽量避免对系统运行的影响。
（5）易操作性
提供美观实用、友好直观的中文图形化用户管理界面，充分考虑日常操作习惯，方便易学、易于操作，含全菜单式处理和各种快捷操作。
系统提供各种图形操作方式，使信息表现更为直观和高效。
（6）可扩展性
为满足今后系统应用范围扩充的需求，系统应充分考虑结构、功能、管理对象等方面的扩展。
考虑软硬件平台的扩展和升级不影响系统的应用。
（7）开放性
系统的数据格式应符合有关国际标准、国家标准和行业标准。
采用开放的硬件和基础软件平台，提供成熟的应用程序二次开发接口。
1.3安全需求
本建设项目存在对以下五个方面的安全要需求：
Ø物理安全
保证该系统各种设备的物理安全是保障整个系统安全的前提。
物理安全是保护计算机网络设备、设施以及其它媒体免遭地震、水灾、火灾等环境事故以及人为操作失误或错误及各种计算机犯罪行为导致的破坏过程。
Ø网络安全
网络安全是整个安全解决方案的关键，包括隔离与访问控制、通信保密、入侵检测、扫描系统、防病毒等内容。
Ø系统安全
在应用系统安全设计时考虑，应用服务器尽量不要开放一些不常用的协议及协议端口号。
如文件服务、电子邮件服务器等应用系统，可以关闭服务器上如HTTP、FTP、TELNET、RLOGIN等服务。
还有就是加强登录身份认证。
确保用户使用的合法性；并严格限制登录者的操作权限，将其完成的操作限制在最小的范围内。
充分利用操作系统和应用系统本身的日志功能，对用户所访问的信息做记录，为事后审查提供依据。
Ø应用安全
应用直接面对使用者，它的安全性问题涉及面也最广，其中包括存取控制、统一身份认证和操作审计等。
Ø管理安全
制定健全的安全管理体制将是安全保障体系得以实现的重要保证；构建安全管理平台将会降低很多因为无意的人为因素而造成的风险；同时要增强人员的安全防范意识。
1.4部署要求
本次招标不包括硬件设备。
软件部署应在综合考虑系统运行性能要求、现有设备的配置和运行情况等各方面因素后，提出支撑平台稳定、高效运行的部署方案。
方案要统筹考虑，利用好甲方目前的数据存储系统。
1.5基本设计路线
在系统的设计、开发和运行过程中，采用下列的技术路线：
1．采用多层架构的B/S结构。
2．采用WebService技术。
3．利用XML作为系统接口的数据交换标准，进行信息资源整合。
4．根据不同的应用类型，采用面向对象或面向过程的方法分析和设计系统。
5．采用应用服务器和组件开发技术，提高系统的灵活性和可扩展性。
6．支持Oracle大型的主流数据库。
7．支持Windows操作系统。
1.6软硬件环境
系统建设项目要求基于甲方公文流转系统进行改造建设，采用B/S模式进行系统开发，整体运行于甲方内部网络（互联网与内部系统），数据库平台采用Oracle。
1．系统在设计实现考虑数据服务器采用WindowsServer操作系统。
2．数据库采用Oracle11g。
3．应用服务器采用操作系统。
4．客户端浏览器仅支持IE8.0及以上版本。
1.7约束和假定
项目中各系统供甲方用户使用，在用户提供的网络内和计算机设备上运行。
在本项目中，将设计合理的组织机构，包括专家组、财务组、技术组等，并由参加单位领导参加，确保决策有力，协调推进项目。
为避免沟通协调不一致导致的风险，一是要建立沟通机制，确保双方的沟通渠道畅通；二是对于沟通中的问题处理，要建立汇报和解决的工作流程；三是沟通的结论要建立档案机制，确保成果的积累和良好管理。
为避免没有足够的人才团队，一方面将加强项目的管理力度，从人力资源规划方面，储备备用人力资源，同时也将提前进行人员的储备和培养、完善培训机制和手段。
在应用支撑系统设计过程中，避免建设内容及数据不一致，从总体上来遵循以下思路：
1．应基于现有公文流转系统来搭建新建设的应用系统，应遵循现有平台的总体架构，以及现有的应用支撑系统。
根据建设要求，在现有应用支撑系统之上进行二次开发。
2．在数据库方面，应充分利用现有的小型数据库。
3．在安全方面，身份认证应采用现有CA统一身份认证系统，不单独进行建设；在用户管理、权限管理方面，基于现公文流转系统的访问控制系统，不单独进行建设。
1.8接口访问日志
用户每次访问任何一个服务接口的操作，均应通过接口访问模块写入日志表记录操作人员的操作日志，对每一访问都能记录在库，做到有据可查，使得系统信息化管理更加完善，安全。
1.9数据库任务计划
数据库需要考虑建立定期执行的任务计划，完成以下功能：
1．数据备份。
定制各类数据的备份策略，完成数据的灵活和自动备份。
2．日志管理。
根据系统的设置，对系统日志进行管理，实现日志信息导出或删除等工作。
1.10数据库设计原则
满足第三范式的设计原则，采用统一的命名规则。
尽量避免表与表之间多对多的关系。
严格监理主外键及其他索引字段，提高数据索引性能。
2项目管理措施
2.1项目进度管理
编制科学合理的总体施工进度计划，运用专业管理软件，对项目计划进行动态控制；并在总计划的基础上分解明确的项目各阶段计划，项目经理抓住主要矛盾，严格按计划安排组织工作，重点抓好关键工序的施工。
定期检查计划的执行与完成情况，及时对施工进度计划进行调整，保证项目的进度能够如期完成；在施工过程中，根据施工进展和各种因素的变化情况，不断优化项目方案，保证项目研发各阶段的衔接和项目研发各部门之间的衔接。
具体研发阶段，如下图所示：
图6项目开发模型示意图
2.2项目质量管理
根据本项目的实际情况，在项目的开发实施过程中，应严格遵循GB/T19001，即2000版ISO9001国家标准和美国CMMI3质量管理体系标准。
同时，还要着重考虑进行如下的质量控制。
1．质量控制内容不单依靠产品质量检验，更强调把质量设计（注入）到产品中去，在项目各个重要环节确保高质量：
质量计划和测试计划；需求检查、概要设计检查；详细设计复核和检查；程序代码复核和检查；单元测试、系统测试。
2．同行检查：
每位项目人员交付的工作结果，包括需求文档、设计文档、源程序、测试用例等，由较高级项目人员给予指导、检查和认可，并可以要求形成正式的检查文档；质量保证人员独立地检查项目人员的工作是否符合组织规定的标准和规范，跟踪和管理发现的问题，要求形成正式的检查文档。
3．监测和度量：
使用定量方法监测项目工作产品和工作过程，获得质量分析、管理决策所需要的重要数据，为产品放行和过程改进提供依据。
4．软件缺陷跟踪：
记录、跟踪和纠正发现的每个软件缺陷。
5．阶段总结会议：
在每个项目工作阶段结束时，由项目经理召集阶段总结会议，分析存在的问题，提出和采取改进措施。
6．二元质量关：
各阶段的工作成果必须提交正式的评审会议；由高级经理主持会议，项目经理、质量保证人员和相关人员与会。
评审会议必须给出通过或不通过决议,如果未通过评审，项目经理必须拟定和实施对应的整改方案，以后再次提交评审。
2.3项目资金管理
本项目中，项目资金将专款专用，专账核算。
项目资金主要用于项目的研究开发、软硬件购置、基础环境改造、培训运维等方面。
项目单位收到拨付资金后将按有关规定进行财务处理。
项目总体目标完成后，项目承接单位向相关部门提出验收申请。
项目验收后，项目单位应妥善保管有关档案和验收资料。
相关财务部门可以根据规定对资金的使用情况进行跟踪问效和不定期检查。
2.4项目文档管理
文档维护主要是配置管理小组的工作。
在本项目的开发中，配置管理小组的一个非常重要的任务就是书写文档规范和文档模板。
文档模板可以保证书写文档的人员只剩下"填空"的工作，加快文档编制速度。
文档通过审查后方可以正式提交，进入软件配置管理的循环中。
配置管理小组真正核心的工作是对文档的组织管理。
根据文档的不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。
从以往项目的经验来看，类似本项目规模的系统开发，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个小组需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。
2.5项目服务质量管理
根据招标文件对项目运维服务要求，以及本项目建设项目的特点，我公司在本次项目的建设期间和后期维护中将充分整合各方资源，充分利用我公司多年IT项目建设为用户长期售后服务的经验，为本项目提供本地化支持和快速响应服务，使各级用户能够得到及时优质的服务保障，保证所有系统安全、稳定、畅通地运行。
为此我公司将成立专门的运维服务组，配备专业的售后服务人员，在接到该系统相关用户服务要求时，即时向用户提供实时技术支持。
运维服务组共4人。
运维服务组组长具有5年以上维护管理经验，具备良好的沟通、协作能力；维护人员全部具有3年以上承担类似工作的经验，其中部分维护人员参与本系统的开发。
2.6项目测试管理
系统开发涉及到一系列的过程，每一个过程都有可能引入缺陷（Bug），本系统质量的好坏直接关系到正常使用和日后的维护。
在开发过程中，我们将质量控制贯穿于所有阶段和所有参与系统的人员中，包括系统分析、设计和编码。
分阶段的评审和测试是软件质量的有力保障。
本系统存在平台测试和应用系统的测试以及最终的测试。
由于测试也存在协调的问题，如错误具体定位，在应用系统发现一个错误，到底是应用系统的自身的错误还是中间件存在的错误，需要测试人员进行准确的判断。
为了达到良好的测试目的，我们在本系统测试工作由测试组来完成，主要采用黑盒测试、白盒测试、单元测试、组装测试、确认测试、系统测试等方法完成系统的测试工作。
3
项目保障措施
针对项目实施过程中，对可能存在的质量、进度、人员、运维等方面的问题，提出相应的应对措施和风险管理计划。
成立公文流转系统项目工作的组织管理机构，保障项目顺利开展。
项目的组织管理机构如下图：
图7项目组织管理机构图
项目领导小组：
由主管信息化工作的领导、各机关处室负责人以及信息中心领导组成，负责对整个项目进行协调、管理。
需求组：
由业务处室经办人、建设单位需求分析人员组成。
负责业务分析、需求调研、需求整理、业务建模等工作。
实施组：
由信息中心工作人员、建设单位研发及实施人员组成。
负责项目技术路线的把控、技术方案的编写、项目的详细设计以及编码、测试和调试，负责项目的具体实施工作。
监管组：
由信息中心项目负责人及监理单位组成。
负责控制项目质量、进度和费用目标。
本次综合应用系统建设项目的具体保障措施如下：
3.1进度保障措施
在进度控制方面主要采取以下措施：
✓方案设计经项目管理部、客户及客户组织的专家确认；
✓使用公认或经过实践的成熟技术；
✓实行业务管理和技术管理分离的项目管理制度，给项目管理人员和技术人员营造好的工作环境；
✓制定详细的项目进度计划。
3.2质量保障措施
按照“精心设计、精心实施、精心组织、精心管理、高标准、高质量建设基础地理信息系统工程”的指导思想，坚持“优质、高速、低耗、安全”的工作作风，奉献一项精品工程。
✓准备质量保证计划；
✓复审软件过程描述；
✓复审软件工程活动、核实软件过程；
✓审计指定的软件工作产品、核实软件产品；
✓记录工作偏差，处理工作偏差；
✓追踪偏差，向项目管理者汇报。
3.3生产安全保障措施
在项目执行过程中始终以安全生产为首要原则，确保项目顺利完成。
✓建立、健全安全生产责任制；
✓组织制定安全生产规章制度和操作规程；
✓保证安全生产投入的有效实施；
✓督促、检查安全生产工作，及时消除生产安全事故隐患；
✓组织制定并实施生产安全事故应急救援预案；
✓及时、如实报告生产安全事故；
✓切实做好数据安全保密制度。
3.4运行维护保障措施
系统建成投入运行后，需要稳定的技术队伍进行日常维护，以保障系统的长期正常运行。
将从现有技术队伍中组建一支由高素质技术人员组成的系统维护队伍，成立系统运行维护机构，专门负责各业务系统的日常维护。
✓指派技术人员，提供现场技术服务；
✓指定服务人员，提供热线电话或电子邮件技术服务；
✓定人定则跟踪服务；
✓长期技术服务。
4
系统测试方案
4.1测试总体要求
Ø安全测评内容
安全测评交由具有相关资质的第三方测评机构完成，以访谈、检查和测试的方法对系统进行功能、安全性能测试，对网络环境安全、基本链路进行测试，对安全管理制度建设、应用安全进行评估等。
甲方在委托第三方测试机构前，我方将为甲方提供软件自测报告及测试记录。
Ø软件测评内容
软件测评交由具有相关资质的第三方测评机构完成，以专家评价和测试的方法对系统各模块的功能和性能、用户文档、技术服务进行测评。
甲方在委托第三方测试机构前，我方将为甲方提供软件自测报告及测试记录。
4.2测试管理规范
从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。
但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。
即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。
因此，理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。
为了确保软件的质量，对项目开发过程应进行严格的管理。
虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。
4.3测试的过程及组织
当设计工作完成以后，就开始着手测试的准备工作，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。
在软件开发组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般按下列方式组织：
首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。
为了保证测试的质量，将测试过程分成几个阶段，即：
代码审查、单元测试、集成测试和验收测试。
1．代码会审：
代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。
会审小组由组长，2～3名程序设计和测试人员及程序员组成。
会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。
实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。
例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功能说明、模块间接口和系统结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。
2．单元测试：
单元测试集中在检查软件设计的最小单位——模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。
由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。
高可靠性的模块是组成可靠系统的坚实基础。
3．集成测试：
集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。
如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。
4．验收测试：
验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。
经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如用户合理期待的那样。
经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。
4.4测试方法的应用
集成测试及其后的测试阶段，一般采用黑盒法。
其策略包括：
1．用边值分析法和（或）等价分类法提出基本的测试用例；
2．用猜测法补充新的测试用例；
3．如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上1、2两步进行。
单元测试的设计策略稍有不同。
因为在为模块设计程序用例时，可以直接参考模块的源程序。
所以单元测试的策略，总是把白盒法和黑盒法结合运用。
具体做法有两种：
1．先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。
如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。
覆盖的标准应该根据模块的具体情况确定。
对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。
2．先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。
4.5测试的人员组织
为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。
因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。
基于此，测试人员的组织也应是分阶段的。
软件的设计和实现都是基于需求分析规格说明进行的。
需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。
为了保证需求定义的质量，应对其进行严格的审查。
软件设计是将软件需求转换成软件表示的过程。
主要描绘出系统结构、详细的处理过程和数据库模式。
按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。
软件测试是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。
软件测试在软件生存周期中横跨两个阶段：
通常在编写出每一个模块之后，就对它进行必要的测试（称为单元测试）。
编码与单元测试属于软件生存周期中的同一阶段。
该阶段的测试工作，由软件开发组内部人员进行交叉测试（避免编程人员测试自己的程序）。
这一阶段结束后，进入软件生存周期的测试阶段，对软件系统进行各种综合测试。
测试工作由专门的测试组完成，测试组设组长一名，负责整个测试的计划、组织工作。
测试组的其他成员由具有一定的分析、设计和编程经验的专业人员组成，人数根据具体情况确定。
4.6测试工具
本项目的测试采用自动化测试工具，在性能测试方面，采用LOADRUNNER进行性能测试。
LOADRUNNER是一种预测系统行为和性能的工业标准级负载测试工具。
通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LOADRUNNER能够对整个企业架构进行测试。
通过使用LOADRUNNER，项目能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
4.7软件测试文件
软件测试文件描述要执行的软件测试及测试的结果。
由于软件测试是一个很复杂的过程，同时也是设计软件开发其它一些阶段的工作，对于保证软件的质量和它的运行有着重要意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。
测试文件的编写是测试工作规范化的一个组成部分。
测试文件不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。
在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。
测试文件对于测试阶段工作的指导与评价作用更是非常明显的。
需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须用到测试文件。
4.7.1测评文档的类型
根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。
测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。
由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。
测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。
测试报告用来对测试结果的分析说明，经过测试后，证实了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件质量的评价，又是决定该软件能否交付用户使用的依据。
4.7.2测评文档的使用
测试文件的重要性表现在以下几个方面：
验证需求的正确性：
测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的。
1．检验测试资源：
测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。
如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。
2．明确任务的风险：
有了测试计划，就可以弄清楚测试可以做什么，不能做什么。
了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。
3．生成测试用例：
测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。
在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。
4．评价测试结果：
测试文件包括测试用例，即若干测试数据及对应的预期测试结果。
完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。
5．再测试：
测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再测试时，是非常有用的。
6．决定测试的有效性：
完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了依据。
同时还可以证实有关方面的结论。
4.7.3测评文档的编制
在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。
4.8系统测试
由于该项目建设涉及面广、系统结构复杂，测试将针对系统的功能性、可靠性、易用性、效率、可维护性、可移植性、中文特性、用户文档等方面进行，测试工作的主要内容，具体如下：
1．系统级测试
系统验收测试：
依据GB/T-17544《软件包质量要求和测试》的国家标准，按合同条款与系统需求说明书对信息系统工程项目进行全面质量验收评测，验证是否满足需求，功能实现与性能指标是否达到业主的要求。
测试指标包括：
功能度、安全可靠性、资源占用率、兼容性、易用性、用户文档、效率、可扩充性等。
网络系统测试：
在对网络系统解决方案评估的基础上，对网络结构、网络性能、网络存储、网络安全等
升级会员 