信息化建设解决方案之应用系统篇

信息化建设解决方案之应用系统篇1、国内应用系统建设综述【导读】应用系统工程建设是一项综合性工程，集技术、业务、工程管理等于一体，实施过程以脑力劳动为主，呈现性、可观察性差，这是应用系统工程建设难以管控的根本原因。在此，我们从系统建设方和开发方的角度，来探讨下应用系统建设过程中存在的问题及失败的原因。当前，我国正处在社会、经济变革的关键阶段，信息化建设在十八大报告中被明确提出，通过广泛深入的信息化建设逐步实现管理流程、组织架构、决策分析等一系列优化、变革，以适应信息时代的发展要求。信息技术发展日新月异，如何将信息技术与产业发展相结合，构建出符合发展趋势、质量可靠可用的应用系统是信息化建设成败的关键。应用系统建设是一项复杂的系统工程，牵涉到多方面的因素，相对其它行业项目而言，软件项目失败的风险更大。通过采样分析以往众多软件项目案例，可以发现影响软件项目的因素遍及应用系统建设的全过程，这其中有企业对自己需求认识不清、用人不当的原因，也有软件开发方能力不足等原因。工程建设现状随着信息技术的发展和普及，应用系统已经与我们的工作、生活越来越密不可分，而软件应用系统建设现状却不容乐观。根据研究机构StandishGroup的统计，近几年来软件应用系统建设项目成功率均在30%以下，超过70%的项目均由于项目延期、超出预算、功能缺失等原因而失败甚至取消。综合分析软件应用系统建设项目，可以了解到当前比较典型的应用系统建设现象如下：（1）业务部门对需求调研、业务需求采集工作敷衍不重视，推三阻四，不积极配合；业务部门对系统建设目标和范围不明确，或是系统业务需求脱离实际，华而不实；需求采集完后，开发方有意或无意的遗漏需求；需求确认后，开发方需求管理混乱，业务部门需求变更频繁，难以控制；系统建设过程中，业务部门抱怨系统没有按照需求实现，开发方抱怨业务部门需求不合理，双方矛盾重重。（2）开发方厂商众多，很难看出哪家产品更有优势，有的厂商还会虚假宣传误导用户，各开发方报价差异也比较大，不知道该如何选择；确定了开发方后，系统建设过程中开发方不及时主动与用户沟通，有时对用户的要求阴奉阳违，有时用户甚至被开发方牵着鼻子走；用户发现系统问题后，由于与开发方合同内容不清晰，开发方强调各种理由不配合进行修改，或是要求追加费用；想更换开发方，但系统建设已经初具规模，难度很大；开发方项目团队人员变化频繁，不跟主管部门打招呼就换人，新人多，有经验的人少，人员管理松散，开发效率低。（3）项目计划经常不能按时完成，计划调整频繁，项目进度延期后，开发方又拿不出好的解决方案，项目看不到完成的希望；项目投入的资金、人力、时间、设备等严重超出计划，不接着投入就半途而废，继续投入也看不到成效，系统建设骑虎难下。（4）系统建设完成后，质量问题多，改起来没完没了，也不知道还有多少潜在隐患没有被发现；系统功能实现与需求差异大，或功能缩水，功能无法正常使用；系统经常受到外部安全攻击，不知道系统数据有没有被窃取，系统内部用户可以越级查看或操作系统数据，也不知道系统还存在哪些安全漏洞；系统功能时而正常，时而不正常，运行不稳定；系统提交一个操作后，很长时间都没有反应,运行速度慢；系统功能操作繁琐，界面不友好，用户使用反馈不好；用户客户端种类繁多，有些用户使用正常，有些用户使用不正常；系统建成后与其他系统集成困难，数据无法共享，系统成为信息孤岛。（5）系统上线后，每隔一段时间就需要重启一次，不重启就无法正常运行；系统出现突发问题无法快速解决，需要长时间暂停，业务无法正常开展，上级主管部门和业务部门给予很大压力；系统扩展升级麻烦，或系统升级后，部分数据丢失且无法恢复；系统上线一段时间后，运行越来越慢或运行不稳定。当前问题分析为什么软件应用系统建设项目失败率居高不下？为什么软件应用系统建设存在那么多的问题？以下对这些现象进行简要的分析：（1）需求调研分析困难重重，有了需求却难以控制。信息化建设往往是由信息中心等信息化建设主管部门负责，业务部门配合进行业务需求调研、可行性研究等工作。由于业务部门自身业务繁忙，而信息化建设相关工作需要投入较多业务人员配合，基于自身利益考虑，业务部门往往不重视相关配合工作，不想承担相关责任，以规避自身风险，而主管部门又得不到领导层强有力的支持，也无法有效协调业务部门。作为应用系统建设的主体，开发方往往从自身利益考虑进行需求分析，同时也往往缺少既懂业务又懂技术的经验丰富的人才，这就导致业务部门人员与开发方技术人员进行业务需求调研分析时，出发点不一致，对需求的理解也不一致，需求调研分析的过程坎坷曲折，即使形成了需求成果，也往往不够细化，甚至部分业务需求被有意无意的遗漏或被曲解。在需求管理过程中，业务部门对业务需求的认识也是一个由模糊到清晰的过程，这就导致很多早期形成的需求都需要进行变更，开发方要么对需求变更以各种理由搪塞，要么疲于应付各种需求变更，需求变更控制形同虚设。（2）系统开发方难于选择和驾驭，己方利益难以保障。在系统规划阶段，由于开发方实力或其产品差距不大，而软件产品质量的检测和评价往往专业性比较强，导致开发方或产品难以评判;开发方自身成本、报价计算方法不同，对项目建设内容理解不同，自身实力不同，产品成熟度不同，导致开发方的报价有较大差异，报价高的不一定能做好，报价低的又怕开发方项目投入少。在系统建设过程中，为了回避项目中可能存在的各种问题，系统开发方不希望主管部门过多参与到项目管理中。由于信息化建设主管部门与系统开发方技术水平不对称，开发方为了降低成本，尽力以功能实现的便捷性作为系统设计的目标，减少成熟产品或组件的修改，努力以各种技术理由说服用户按照开发方思路接收系统，将生米做成熟饭，抓住了主管部门骑虎难下的心理，往往导致系统建设先天基础不良，后期出现问题积重难返，即使要求开发方修改，开发方也会找各种理由搪塞或者要求追加费用。（3）项目延期司空见惯，进退两难。由于项目管理信息量大，跟踪统计分析工作量大，开发方往往尽力简化自身的过程监管工作；由于信息化建设主管部门与系统开发方人员数量不对称，导致主管部门无法投入较多人力进行项目过程全面监管工作，项目进度情况更多的依赖于开发方自身的跟踪统计，数据的透明度往往不够；开发方基于自身发展和成本考虑，在项目组人员构成上，往往以老带新，通过项目实践锻炼新手，而新手由于技术水平相对较差，工作经验较少，开发效率较低；同时，由于应用系统建设项目过程中存在诸多不确定性或技术风险，如果开发方不能有效的预防和解决，就会造成项目进展缓慢，风险解决效率低，项目不断由于各种不确定因素和风险造成延期。（4）漏洞百出，满目疮痍。由于应用系统质量度量的复杂性，系统功能性往往是用户最为直观感受，也最为重视的质量特性，为了降低项目成本，加快项目进度，系统开发方大多以功能的实现作为项目进度的主要目标，系统的安全性、可靠性、性能、易用性等其他非功能质量特性往往被忽视；在系统设计过程中以功能实现的便捷性为目标，不重视其他非功能质量特性，造成系统的先天基础不良；系统编码往往完全依赖于开发方自身的规范管理，而开发方技术人员的技术水平和素质参差不齐，容易导致系统编码阶段形成的程序不严格遵守编码规范，程序只满足功能性要求，不能充分满足非功能质量特性要求；系统测试往往依赖于开发方自身的测试团队，为了降低人力成本，很多情况下测试人员往往与开发人员不成比例，或者直接由开发人员兼任，容易导致测试不够全面，不对非功能质量特性进行专业测试，非功能问题隐患潜伏在系统中。（5）维有名无实，形同虚设。由于应用系统上线后，运维工作更多的依赖于系统开发方，而运维阶段多采用人工的方式进行系统的日常运维管理，缺少专业性运维管理技术、工具支撑，也缺少专业的运维技术人员，造成系统运维管理效率低、操作性差，运维数据无法跟踪统计分析；同时开发方在运维过程中往往缺少运维管理制度建设，造成运维管理更多依赖于管理人员的自身素质，缺少有效的管控机制对运维管理工作进行监管，造成日常运维管理工作规范性、全面性较差。开发方在系统建设阶段往往忽视系统扩展性，仅考虑系统当前的使用情况，当系统需要扩展时，需要对系统进行大量修改，造成扩展效率低。开发方往往不制订针对性的应急响应预案，或应急响应预案可操作性差，出现突发问题后，不能对突发问题产生原因进行快速定位，也不能对突发问题形成有效的解决方法。从技术角度方面分析，软件应用系统建设项目失败比例过高的一个很重要原因在于，软件应用系统正在向大型化、复杂化的方向发展，而应用系统建设也变得周期更长、管控难度更大、技术更复杂。从管理角度方面分析，应用系统建设项目由于建设方和承建方信息、人员、技术等方面的不对称性，造成系统管理工作只能更多依赖于系统开发方自身的管理，应用系统建设主管部门缺少有效的项目过程监督及对开发方的约束机制。探寻解决之道为了改进软件应用系统建设项目存在的各方面问题，提高系统建设质量，目前已经有信息系统工程监理、软件开发过程模型理论等方法，但是通过实践证明，这些方法在实际应用中都存在一定局限性。信息系统工程监理从工作时间范围来讲，只覆盖应用系统建设过程中的实施阶段和交付阶段相关建设工作的监理，不覆盖系统规划阶段、运维阶段的相关工作监理，也无法发现和解决这两个阶段中出现的问题。从工作内容来讲，信息系统工程监理重点关注系统实施阶段和交付阶段相关建设单位的工作监管，通过对建设单位工作内容的跟踪统计，使系统建设相关方了解项目情况，但对于系统建设质量无法进行评估，也无法全面有效的发现系统中存在的质量问题。从工作的适用性来讲，信息系统工程监理的依据主要为监理标准，缺少监理标准和软件过程理论的结合，无法很好地适应应用系统建设项目的特点。软件开发过程模型目前已经有很多成熟的方法论，如软件能力成熟度模型（CMMI）、统一软件开发过程（RUP）、净室软件工程、极限编程、敏捷开发等。这些方法从适用性来讲，主要针对软件开发企业，不适合应用系统建设主管部门，需要结合主管部门特点进行改进，改进的工作量和难度都很大。从实用性来讲，这些方法理论性强，和实践结合难，很多时候也不符合国内应用系统建设项目的特点。从覆盖范围来讲，这些方法重点在软件开发过程，不覆盖系统规划阶段、运维阶段的相关工作。项目的成功是质量、时间、成本三个要素互动后一个最佳的匹配过程，而质量仍然是居于首位的。如果没有质量保证，时间再短，成本再低都毫无意义，因此在确保质量的前提下，我们能否把时间缩短一些，成本降低一些？这正是我们想与您探讨的问题。基于全程质量保障的软件过程模型，覆盖软件应用系统建设项目的规划阶段、实施阶段、交付阶段、运维阶段全过程，通过各个阶段质量控制和质量保证方法，使项目全过程公开透明可控，为我们的项目装上“质量防火墙”。

2、软件过程全解析【导读】从软件工程诞生之日起，人们一直没有停止对软件过程的探索与实践，其中最著名的的莫过于CMMI，二十年多来它帮助无数软件开发企业完善了自己的软件开发过程，在业界享有极高的认可度。另外，还有众多软件工程研究者在实践的基础上提出了很多其他过程模型，比如IBM的RUP，微软的MSF，以及近几年热炒的敏捷编程、极限编程等，表明软件过程研究领域仍然活跃，软件工程之路仍然漫长。本节介绍的模型以全面的质量管理（TQM）为核心理念，综合CMMI、RUP等业界软件工程理论及我们的最佳实践，将整个应用系统建设过程分为系统规划、系统实施、系统交付和系统运维四大阶段，分别介绍在每个阶段的主要工作内容、工作方法、质量管控措施及常见问题及风险等，旨在向我们的客户提供一套系统的可信的应用系统建设方法论。概述应用系统都有从诞生、发展到退役这样一个过程，我们称这样一个过程为应用系统生命周期，从软件工程角度这个生命周期可以划分为系统规划、系统实施、系统交付和系统运维四个阶段。 纵观软件过程是建设单位和开发单位充分合作、协同工作的一个过程（如下图所示），在这个过程中建设单位依据本单位业务需求进行可行性分析及项目立项、招标等工作，开发单位依据项目需求编制解决方案提供开发服务。开发单位中标后即正式启动项目，进入项目建设单位进行需求调研并与项目建设单位进行确认，随后开始系统的设计、实现，并进行相关的项目管理工作（过程检查、风险控制、配置管理等），向建设单位汇报项目相关进展情况，这个过程有时需要反复进行直至系统交付，进入应用系统试运行与生产运维阶段。图SEQ图\*ARABIC1软件过程活动框架2.1.1协同项目管理项目一般具有独特性、时限性、不确定性及不可逆转性等特点，正是这些因素导致项目管理变得复杂，对项目管理的研究也更具现实意义。软件项目管理的主要任务是制定软件开发计划，跟踪、监督和协调工作进度，保证工程如期按质完成。要做好项目管理工作，一套成熟有效的项目管理机制有无可替代的作用。由PMI维护的项目管理知识体系在全球有着广泛的认同。在PMI发布的最新一版的项目管理知识体系中，项目管理划分为10个知识域，即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、干系人管理、采购管理、风险管理和综合管理。 在软件工程领域，项目管理更加讲究协同，以适应软件项目以脑力劳动为主的特点，通过充分的协同确保信息流畅准确传递，确保项目中各类角色所获得信息一致，从而推动项目更加高效的前进。这就是目前备受业界推崇的协同项目管理（如下图所示）。 协同项目管理将软件开发过程中主要活动都置于监控、调度之下，统一为任务这一个管道，并以任务形式传达至个人工作台；通过细粒度的数据监控、采集与分析，实施对项目的度量与分析。2.1.2典型软件项目管理架构典型的软件项目管理架构一般包括项目管理办公室（PMO）、系统架构师、系统分析师、系统设计及编码人员、质量保证人员、测试管理人员及测试人员、配置管理人员、培训人员及其他后勤支持人员等。各类角色及岗位人员各负其责，协同工作。2.1.3关键项目管理活动介绍风险管理任何可能对项目结果产生积极或消极影响的事件或条件都是风险。风险管理就是要提前识别、分析和定位项目风险，避免对项目造成损害或损失。沟通管理用于建立软件工程组各成员之间、软件工程组与其他工程组之间、软件工程组与客户之间、软件工程组与公司管理层之间的沟通机制，以及时预防和解决软件项目管理与开发过程中因交流问题可能造成和已造成的各种障碍。计划管理制定并评审项目计划，以便所有相关人员按照该计划有条不紊地开展工作。周期性的跟踪任务（含进度和工作量）、费用、资源、工作成果等，及时了解项目的实际进展情况。缺陷管理对软件开发过程出现的问题、测试发现的问题等实施缺陷管理，进行统一跟踪处理，避免遗漏。配置管理软件过程是一个多人协作、信息交换的过程，越是复杂的项目越需要实施配置管理。实施配置管理，首先要有效识别项目中的各类配置项，根据管理需要建立配置管理规范，使配置管理制度化，形成良好的协同效应，避免版本冲突影响项目开发进度、引入软件系统缺陷。过程检查检查软件过程中的各项活动，以验证是否符合项目管理规范的要求。系统规划系统规划是应用系统生命周期的第一个阶段，其任务是对企业的环境、目标及现有系统的状况进行初步调查，根据企业目标和发展战略，确定应用系统的发展战略，对建设新系统的需求做出分析和预测，同时考虑建设新系统所受的各种约束，研究建设新系统的必要性和可能性。根据需要和可能，给出拟建系统的备选方案。对这些方案进行可行性分析，编制《可行性分析报告》。《可行性分析报告》审议通过后，将新系统建设方案及实施计划编写成系统设计任务书。2.2.1系统规划价值应用系统建设是投资大、周期长、复杂度高的社会技术系统工程。系统规划可以减少盲目性，使系统具有良好的整体性、较高的适应性，建设工作有良好的阶段性，以缩短系统开发周期，节约开发费用。目前，国内企业建设的应用系统，单项应用的多，综合应用的少，系统适应性差，难以扩充。缺乏科学的规划是造成这种现象的原因之一，有些规模较大的项目，由于没有系统规划和科学论证，上马时轰轰烈烈，上马后困难重重，导致骑虎难下的局面，不仅造成资金、人力的浪费，而且为今后的系统建设留下隐患。因此系统规划是应用系统建设的关键，必须敢于投入、加大力气做好系统规划与论证工作。第一部分中有关问题从根源上来看，有些就是规划问题，比如：已建成系统与业务匹配度低，可用性差，无助于企业管理改善；系统建设周期长，环境适应能力差，不能满足企业不断变化的发展要求；企业管理架构不能适应系统，不能充分发挥系统的作用，系统价值体现不明显；应用系统规划建设脱离企业实际，导致系统无法建成，形成“烂尾楼”项目。2.2.2系统规划流程系统规划是软件项目正式启动之前的一系列活动，包括可行性分析、产品选型、项目招标、成立项目组、确定项目计划、项目启动等。该阶段是项目成功与否的一个决定性阶段，这个阶段直接决定着项目后续各阶段的开展状况，因此，做好项目规划是有效控制项目风险，确保项目成功的关键。系统规划也是有章可循的，基本步骤可以分为6个（如下图所示），分别为：图SEQ图\*ARABIC2系统规划过程企业系统现状调研分析根据企业发展战略和目标，从同行标杆企业及本企业中采集各类信息，站在企业管理者的角度审查企业现状、系统建设及应用现状。分析确定系统目标根据企业发展诉求及现状调研成果，分析确定系统应具备的质量属性、范围等。分析确定系统组成及基本功能制定系统实施方案根据系统目标进行阶段划分，目的是使复杂目标化解成一个个小的可控的较易实现的目标，对这些目标进行优先级分析、排序，形成总体实施方案。系统可行性研究对系统投资、技术可行性、资源等进行综合分析，形成《系统可行性研究报告》，并进行可行性评审论证等。制定系统建设方案依据《系统可行性研究报告》的相关内容，对各项技术指标进行评估、落实，形成系统建设方案。2.2.3关键质量活动根据系统规划的工作流程及交付成果，在本阶段主要的质量管控活动包括以下内容：系统实施方案评审可行性研究报告评审系统建设方案评审产品选型（方案评审、比对测试）投资估算2.2.4系统规划成果 通过系统规划，可以获得《可行性分析研究报告》及《系统设计任务书》、《实施方案等》，通过这些材料可以获取以下重要信息：明确项目规模：建立项目的软件规模、范围，明确了项目的基本验收标准；评估项目风险：通过可行性分析，对项目面临的各类风险获得了基本认知；制定项目计划：获得了初步的项目实施方案，对整个项目的总体成本、计划等有了基本认知。2.2.5系统规划风险无法获得企业高层领导的充分支持；企业信息化水平低，无法清楚表达自身需求；业务部门不配合。系统实施2.3.1需求分析阶段系统需求阶段的基本任务是在充分了解用户需求的基础上，借助于形式化语言进行系统描述，即需求规格说明书。系统需求分析需要在系统规划的基础上，对企业的业务活动进行全面的调查分析，详细掌握有关的工作流程，收集与系统有关的各种资料，分析现有业务流程、原有系统的局限性等，从而为新系统进行更好的建模设计。需求分析流程系统需求分析发展至今，已形成自有的一套完善流程，并有诸多相关的理论建设，即需求工程。图SEQ图\*ARABIC3需求工程 软件需求工程是包括创建和维护软件需求文档所必需的一切活动的过程，可分为开发和需求管理两大工作。 需求开发包括需求获取、需求分析、编写需求规格说明书和需求验证评审等4个阶段。 在需求开发阶段需要确定软件所期望的用户类型，获取每种用户类型的需求，了解实际的用户任务和目标，以及这些任务所支持的业务需求。同时还包括分析源于用户的信息，对需求进行优先级分类，将所收集的需求编写成为需求规格说明书和需求分析模型，以及对需求进行评审等工作。 需求管理通常包括定义需求基线、处理需求变更和需求跟踪等方面的工作。 需求开发是主线，是目标；需求管理是支持，是保障。关键质量活动本阶段主要的质量管控活动包括以下内容：需求评审变更管理需求分析阶段成果需求调查报告需求分析规格说明书需求分析风险贪多求全，导致需求爆炸式增长，反而淹没了重要的需求；无足够用户参与；需求描述语言的多以性；对需求分析阶段的认识和重视程度不够，缺少良好的需求评审和管理机制；需求分析的时间不足；没有挖掘用户的核心需求，导致软件项目没有亮点，使用户误以为开发团队能力不足。2.3.2系统设计阶段系统设计的目标是绘制系统的蓝图，权衡和比较各种技术和实施方法的利弊，合理分配技术等资源，构建系统的详细设计方案和相关模型，用以指导系统实现工作的顺利开展。（1）概要设计概要设计又称系统总体结构设计，主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图。通过概要设计，将系统的总体目标分解成许多基本的、具体的子任务。（2）详细设计详细设计是概要设计的延伸，在详细设计过程中对概要设计所分解的子任务进行具体数据结构、算法、技术的确定。根据任务特点，详细设计可以分为代码结构设计、接口设计、数据存储设计等。图SEQ图\*ARABIC4系统设计过程关键质量活动设计计划跟踪设计规范检查设计规格说明书技术评审变更管理系统设计风险先对系统设计人员进行“专题”培训，让他们掌握必要的系统设计技能。由于国内绝大多数的大学不开设“用户界面设计课程”，这导致大部分软件开发人员不善于设计用户界面。项目开发小组应当设法邀请用户界面设计专家参与（或指导）本软件的界面设计。系统设计人员可以根据产品的特征，适当地修改《体系结构设计报告》、《用户界面设计报告》、《数据库设计报告》和《模块设计报告》的模板。对系统设计过程中产生的所有有价值的文档进行配置管理。2.3.3系统实现阶段 系统实现阶段是将涉及的系统付诸实施的过程。这一阶段的任务包括程序编写与调试、设备安装和调试等。在这个阶段，往往几个互相关联、制约的任务同时展开，因此，合理安排组织非常重要。系统实现是按实施计划分阶段完成的，每个阶段应写出实施进展报告。系统实现阶段主要工作内容如下：（1）系统编码（界面、业务逻辑、数据持久层）及单元测试（代码静态检审、代码运行期测试、代码安全测试）（2）系统集成及集成测试（内外接口测试）（3）系统测试图SEQ图\*ARABIC5实现过程关键质量活动代码检审单元测试集成测试系统测试系统实现阶段风险工作量估计过低，对软件的规模做出正确的估计不是一件容易的事；项目团队水平不足，技术人员的水平如果不能与项目要求相适应，对项目的质量、成本、进度都会产生影响；开发计划不充分，没有良好的开发计划和开发目标，项目的成功无从谈起；项目经理的管理能力不足；来自高层管理者的支持不够，对项目所依赖的外部因素无法控制等。2.4系统交付通过详细严谨的需求分析、系统设计及实现，应用系统建设逐步转入交付阶段。2.4.1系统交付价值系统交付是在项目预定里程碑均已获得之后，将应用系统向客户交付的一个阶段。通过本阶段工作，可以对系统进行充分梳理、封装，从开发环境移植到生产环境，使系统真正成为一个可运营的生产系统。2.4.2系统交付流程图SEQ图\*ARABIC6交付过程 系统交付阶段需要完成系统上线运行方案，结合企业业务特征制定业务规范、用户手册，实施用户培训，帮助系统潜在用户尽快熟悉并应用系统；在对系统运行环境及使用场景充分评估的基础上，制定应急方案，确保系统上线后一旦出现故障，能够立即采取措施进行回退或者切换。 由专人部署系统并安排进行试运行工作，在试运行期间要建立有效的问题反馈机制，确保用户意见得到充分评估并给出处理建议。 可在试运行期间或之后开展验收测试工作，目前多数项目选择了第三方独立测试，确保验收测试的公正性、权威性。通过第三方验收测试及时发现系统潜在的问题，避免上线后出现重大运营故障。 一般系统试运行后，由业主组织进行系统初验工作。2.4.3关键质量活动文档审查；验收测试；专题测试（性能、安全性、可靠性等）；系统部署方案、应急响应方案模拟演练。2.4.4系统交付成果在系统交付阶段，主要产生以下重要资产，主要包括：用以指导系统试运行的业务操作规范；完善准确的系统用户操作手册；完善准确的系统培训资料（PPT、视频、操作速查手册等）；系统部署方案；系统切换方案；系统应急预案；验收测试报告。2.4.5系统交付风险在系统交付阶段，主要存在以下因素对系统交付产生影响，详细说明如下：业务操作规范与用户实际场景有出入；系统切换方案有疏漏；没有建立系统部署应急响应机制，或者应急响应方案有疏漏；数据迁移方案有疏漏，数据迁移不完整；系统培训未对用户实施分类，培训不充分。2.5系统运维经过系统规划、系统实施、系统交付之后，一个健全的应用系统已基本构建完成，系统随之转入运行维护阶段。系统运维需要跟踪记录系统运行情况，并评价系统的应用水平及经济效益等。2.5.1系统运维价值 在应用系统正式上线生产后，客观上来说仍然会存在一些之前未曾发现的潜在的问题，这些问题随着对系统使用规模的扩大、深入而逐渐暴露出来，比如少量功能问题、性能问题等。对于这些问题要及时记录并建档，输入缺陷跟踪系统进行逐一跟踪解决。系统运维过程是一个较长期的系统演进过程，通过演进使系统可以更好的适应用户环境，发挥系统的价值。这正是做好系统运维工作的重要作用。2.5.2系统运维流程图SEQ图\*ARABIC7运维过程在对应用系统建设单位移交的相关技术资料（系统设计资料、用户手册、运维手册）审核确认后，系统正式转入运营维护阶段。系统运维包括多方面的工作，基本的是根据系统特点及系统运行环境，制定合理的运维管理制度，包括系统运行、数据维护等，同时对系统运行维护日常工作实施检查督导。除此之外，要采集用户使用意见反馈，识别新增需求及需求变更问题，审议制定系统升级、功能改造方案等。另外，要建立应用系统的档案，包括应用系统配置、系统升级维护记录等；建立应用系统监测体系，阈值报警体系等；对系统出现的故障实施问题分析定位，协调技术人员解决问题；建立应急救援机制，编制应急响应预案，并进行有针对性的演练；对应用系统配置数据及运行期间产生的各类数据进行备份，并进行恢复性演练。2.5.3关键质量活动（1）档案维护：对应用系统的基础资料建立档案、相关配置项建立档案；（2）应用系统运行监测、性能优化、故障诊断、容量规划等；（3）系统数据应用系统数据维护、备份、数据库运行状态检查、数据备份策略制定及检查；数据恢复预案制定及演练。（4）应急救援应急响应预案制定：针对应用系统中的重要资产、制定应急响预案，并有计划的进行演练和改进；应急响应：针对应用系统突发的重大事件，以最快的时间进行故障排查定位和应急处理。2.5.4系统运维成果通过系统的运维建设，企业IT管理部门可以获得以下重要信息资产：完善规范的系统运维管理制度易于维护、结构清晰的系统档案立体式的应用系统运营保障机制（运行监测、性能优化、故障诊断、容量规划）完整有效的系统数据备份恢复策略可行的应用系统应急救援体系不断演进的应用系统，与业务流程切合度高2.5.5系统运维风险在系统运维阶段，主要存在以下因素对系统运维产生影响，详细说明如下：运维体系不健全，人员职责不明确；应用系统是非单一系统，是EAI的组成之一，系统结构复杂；应用系统供应商人员流动性大，对系统适应性升级改造响应不及时；

3、全程质量保障服务方案【导读】没有质量的商品没有任何价值，同样一个质量低下的应用系统对企业而言其价值也将被严重降低。那么，在应用系统建设期间，我们应如何做才能有效避免上述问题，从而向我们的企业交付一套质量可靠、运转高效的应用系统呢？山东省软件评测中心从软件工程的一般建设规律及当前信息技术领域主要的质量管理方法、工具等方面，结合我们多年从事第三方软件系统监理、测评服务的知识积累，总结提出了质量驱动的软件过程模型。本模型以全面的质量管理（TQM）为核心理念，将整个应用系统建设过程分为系统规划、系统实施、系统交付和系统运维四大阶段，分别介绍在每个阶段的主要工作内容、工作方法、质量管控措施及常见问题及风险等，旨在向读者提供一套系统的可信的应用系统建设方法论。3.1方案概述从对当前工程建设现状及问题的分析来看，导致项目失败的因素在系统建设的各个阶段都有涉及，也就是说在整个应用系统建设过程中每个环节出了问题都有可能导致整个项目的失败。因此，要想获得一个高质量的软件产品，需要对整个软件过程生命周期实施科学管控，因此，很多国际知名的著名IT厂商，如HP、IBM等相继提出ALM（应用生命周期管理）的概念。ALM是站在软件提供者角度提出的系统的新一代软件开发过程支持体系，而对软件的最终用户的质量关切的解决方案并未阐述清楚，有鉴于此，结合我们在第三方监理、测评服务十多年与客户沟通交流的基础上，总结提出质量驱动的软件过程模型，即全程质量保障，模型完全从软件使用者的角度提出，覆盖整个软件过程，以一体化综合性方案解决软件购买者、使用者所关心的质量问题。全程质量保障服务方案以专业的软件测试和质量管理解决方案帮助企业和用户确保交付的软件产品的功能性、可靠性和性能等质量要求得以最大化的满足，同时在确保软件质量的前提下，降低软件产品交付的风险和成本。质量驱动的软件过程模型是以用户为关注焦点，以质量为核心追求的创新型软件过程，它最突出的特点是质量活动作为独立过程域分布在系统规划、系统实施、系统交付及系统运维四个阶段，遍布应用系统整个生命周期，构成全方位的质量防护体系。目前，国内信息技术产业现状是无论开发方还是工程监理机制均无法有效解决用户所关心的工程质量问题，实施全面的质量管理不仅仅需要成本，更需要洞察万千的质量管理技术，因此，我们提出全程质量保障服务以解决应用系统建设质量的最后一公里问题，通过实施全程质量保障服务，为用户提供专业的质量管控服务，防微杜渐，确保应用系统建为所用、用为所需！全程质量控制是基于对应用系统建设的再认识构建的，从系统规划、系统实施、系统交付和系统运维四个阶段的质量保障需求出发，定制质量控制内容，有的放矢、精准执行！（如下图所示）图SEQ图\*ARABIC8全程质量保障服务框架全程质量保障服务可以因项目情况而灵活定制，所有质量保障活动都建立与软件质量需求和项目进度、成本等要求之上，根据项目要求，规划质量保障过程，所有质量保障活动可灵活组装，如质量保证、质量控制可分开进行，质量保证可只进行需求评审，质量控制中可只做系统测试或验收测试等等。通过不同组装，在质量需求、项目进度、项目成本、质量保障之间寻求平衡，力争以最小代价获得最优质量。3.2服务内容3.2.1全面的项目管理从前面所述可知，无论是CMMI理论还是项目监理都存在一定的局限性，我们在协同项目管理的基础上，借助于全面深入的全程质量保障服务，提出更为全面的项目管理解决方案。全面的项目管理基于PMBok2012作为理论基础，融合监理规范及测评技术，从而有效避免了监理重过程轻结果，测试轻过程重结果的弊端，使项目管理工作与系统建设过程融合，覆盖四阶段的生命周期。概括来说，全面的项目管理包括质量计划管理、测试管理、缺陷管理、任务管理以及风险监控、进度监控、人力资源管理、干系人管理等，同时具有以下特点和优势：全生命周期覆盖解决时间局限性问题：致力于为用户提供高可用系统，从项目规划开始即以项目的形式实施全面管理，提高事务的执行力；专业人员、专业工具解决纯监理的技术局限性：投入专业项目管理人员，使用专业的项目管理工具及测试工具，既发现问题也解决问题。深入项目建设全过程，提供一线一手项目实施数据，数字化全面展现项目进度、质量等情况，从而彻底打破建设方和开发方信息不对称的不公平格局。3.2.2规划咨询服务规划咨询方案旨在协助进行系统的规划设计、系统实施方案咨询、系统可行性分析等。通过专业的项目规划可以从专业角度为用户提供科学有效的系统建设依据，对技术方案的把握以及未来发展潮流的预测更加准确，以便避免盲目投资，减少不必要的损失。规划咨询方案包括三个方面的内容，分别是：可行性分析可行性分析包括两个方面的内容：建立应用系统的必要性和建立应用系统的可能性。通过可行性分析形成应用系统建设方案，并对方案实施评估，对方案中的系统架构、可靠性、可扩展性、兼容性、风险、投资成本等内容进行评估，以明确系统建设的风险和可行性，为领导决策提供支持。同时，针对方案中的不足给出改进建议。产品选型规划设计产品比对方案，进行专业测评，对系统及所要用到的软件产品或服务进行规格选型、对比，找出各备选系统、产品或服务的优劣点，出具比对报告，协助用户选择最佳产品，从而有效解决建设单位面对供应商众多，不知如何选择的窘境。图SEQ图\*ARABIC9产品比对投资估算投资估算服务基于COCOMOII模型，通过抽取项目指标特征进行综合计算，获得一个项目指导价。通过该项服务可以帮助用户对准备建设或选用的软件系统进行成本评估，提供投资标线，以做出更合理的投资，降低投资成本和风险。3.2.3实施控制服务实施控制是应用系统建设的主要阶段，包含了需求分析、系统设计及系统实现等核心过程，因此确保实施质量将直接对应用系统质量产生影响。实施控制方案主要包括质量保证和质量控制两部分内容，其中质量保证主要解决确保项目组“正确的做事”，质量控制主要解决确保项目组“做正确的事”，项目管理主要解决项目组“规范的做事”。（1）质量保证质量保证的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。质量保证过程主要包含三部分内容：制定质量保证计划过程与产品质量检查问题跟踪与质量改进通过质量保证可以有效解决以下问题：系统需求过程没有遵照既定规范执行，导致需求采集分析质量下降；系统设计过程没有遵照既定规范执行，导致系统设计质量下降；系统编码过程没有遵照既定规范执行，导致代码编写质量下降；任务执行与计划有出入，出现延期问题或有延期风险；及时纠正现有软件过程中不符合项目要求的地方，改进软件过程。（2）质量控制质量控制主要通过技术评审和过程测试（包括单元测试、集成测试、系统测试）来发现问题，并实施全面的缺陷跟踪管理。通过质量控制的实施可以有效解决以下问题：需求调研不充分，后期需求变更困难；系统设计与需求不符；功能实现与业务部门要求不一致，业务部门不断抱怨；系统潜在问题较多，上线后随着使用的深入逐渐暴露出来，系统不稳定，维护成本高。（3）项目管理项目管理主要通过对项目过程中的人员、计划、成本、风险等项目要素进行资源优化及权衡。3.2.4交付验收服务项目验收是整个项目建设中一个很重要的步骤，是用来验证承建方所交付的软件产品是否符合建设方的要求。通常，建设方对项目验收工作非常重视。但是，由于人员、时间、技术等因素，建设方很难在短的时间内来全面深入的评判承建方所交付的软件产品是否符合自己的需要，这为后期的系统上线运行带来风险。第三方验收测试服务依据项目建设方和承建方所签订的技术合同等文件中规定的验收标准和方法，检验完整的软件系统，以证实承建方所提供的软件产品或技术服务是否满足软件开发技术合同（或用户需求）规定的要求，为承建方的项目验收提供重要的客观参考。图SEQ图\*ARABIC10验收测试内容通过全面、深入、客观的验收测试，我们可以及时发现软件产品交付使用前仍然存在的一些缺陷。我们整理缺陷文档，并提交给承建方进行整改，从而可以避免软件产品带着大量的缺陷上线运行。同时，我们将测试结果整理成测试报告，并交付给项目建设方。项目建设方可将第三方验收测试报告作为项目验收的一项重要客观参考内容，从而可以更客观、全面的进行项目验收工作。3.2.5系统运维服务借助ITIL（IT基础架构国际最佳实践指南）的最佳实践，针对应用系统的运维特点，我们提出以下7项服务，分别是档案维护、故障诊断、性能优化、容量规划、系统监测和应急救援、系统扩展升级，全面覆盖应用系统上线、使用及灾备等环节，确保用户获得一个持续可用的业务系统。通过系统运维方案可以有效解决以下问题：应用系统档案缺乏或不完善，升级过程依赖于原开发商，出问题回溯性差等；系统硬件资源得到充分利用，系统容量最大化；系统性能低下，找不到瓶颈；系统结构复杂，出现问题后定位困难，从而导致系统长时间瘫痪，影响业务进程。

3.3方案价值项目质量问题司空见惯，这些问题往往不是孤立的，要系统的解决这些，充分保障软件质量，非常必要在应用系统建设过程中引入独立的第三方质量保障服务机构，独立担负软件过程中的质量管理和质量控制工作。第三方质量保障服务机构独立于软件开发单位之外，与软件开发单位构成对立、协同的关系，一方负责开发，一方负责检测，相互监督，相互制约，相互促进，共同完成项目研发工作，从而可以保障软件项目的进度和质量。这就是本节阐述的全程质量保障服务方案，概括描述如下：明确软件系统质量需求，将质量需求纳入到软件需求管理中，在项目初期就明确项目的质量目标；定义质量管理过程，采用软件工程的方法管理开发过程，通过检查、评审、测试验证等手段来贯彻落实“早预防、早检查、早控制”的质量管理策略；全面的计划和及时、准确的项目跟踪及报告，对计划、变更进行全面控制；建立软件质量评价、软件产品交付机制，对软件定义、研发、交付等过程进行基于质量的动态跟踪和控制；软件质量保障过程可以依据项目需求随需定制；融合多种工程方法思想。质量保障过程，融合了CMMI3级、RUP、敏捷软件工程等多种软件工程方法思想，在吸取了各软件工程方法精华的基础上，结合最佳实践，制订相应的质量保障规划。通过实施全程质量保障服务，项目建设单位可以在技术层面获得解放，把精力放到项目的管控、决策上面，使用户回归到项目领导者的应有位置上，避免被开发单位以技术的名义“挟持、绑架”，综合来说，全程质量保障给用户赢得以下优势：丰富项目仪表板，助你决策、掌控、导引，是核心的成功驱动力通过实施全程质量保障服务，可以完整的追踪项目各项信息，获得每一阶段的一线数据，能轻易地定义、查询，获得项目报表，充分保障用户知青权，提升用户的决策能力。信息感知，专业转换、无遗漏传递通过实施全程质量保障服务，可以将技术信息转换为系统建设单位看得懂、听得清的管理决策信息，避免被系统开发单位误导。改变信息不对称的格局软件过程将变得规范、明晰，系统建设方将可以对项目风险、进度、质量状态全面了解，使软件开发过程由一个“黑匣子”变得透明、可控。质量驱动式开发，避免质量成本被削减软件质量得到充分的重视，避免了原有开发方式中，由于成本、进度、利润等因素，软件开发商私自压缩质量保证和测试人员，减少相关工作量的做法，在制度和工作模式上保证了软件开发的质量。专款专用，保护系统建设单位的质量投入实施全程质量保障不会带来成本的显著上升。软件开发项目具有固定的成本，该成本中包括了软件开发过程中需求分析、设计、编码、测试、管理及运维等各类成本，该方案将软件开发过程中的各项工作分离出来，由两个在其各自领域更专业的单位来完成，并没有增加额外的工作量，也没有增加相应的成本，反而因专业而提升工作效率，降低成本。（注：在将所有预算分配给一家单位时，该单位有可能会降低总额度，但他是以软件质量为代价的。）确保质量获得提升，降低运维成本和风险，改善IT部门口碑通过质量的提升，会降低软件开发、使用成本。软件质量的提升，将会大量减少后期的维护工作量，避免因缺陷而导致的系统服务中止等故障，提升系统可靠性，从而大大降低使用中的维护成本，同时也有利于降低开发商的后期维护服务费用。4、最佳实践【导读】行业的不同、环境的不同都会导致项目