如何做好管理支撑应用系统建设工程项目管理？
作为系统管理部门的一员，要协调好使用系统的业务部门和开发系统的厂商之间的关系，保证项目顺利进行，从全局、整体的层面出发，协调项目各方面的因素，做好项目的整体管理，保证项目能满足业务部门的需求和期望。
结合自己工作后学到的知识，现对工程项目建设的过程总结如下。
一、需求开发与管理
对于应用系统的建设，尤其要强调系统需求开发和需求管理。
如果不重视应用系统的统筹规划，或者不按照事先的需求进行应用系统建设，建成后的应用系统很可能出现协同困难，难以实现系统的预期功能，难以实现系统建设的目标。
从长远看还会造成资源浪费，使得将来必须为之付出更大的系统改进与整合成本。
应用系统建设项目立项后，需要进行详细的需求分析。
需求分析是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。
需求工程的活动可以划分为需求开发和需求管理两个部分，分别关注对业务部门请求的加工提炼和对需求的跟踪管理，贯穿整个系统开发的始终。
需求开发和需求管理的问题对产品成本有显著的影响，错误的需求会导致额外的返工、项目延期或项目失败等问题。
好的需求开发和管理需要组织、技术与流程三者的有机结合。
（一）需求开发
需求开发的目的是通过调查与分析，获取业务部门需求，主要包括运行环境、系统数据流、界面设计要求、业务功能等。
整个需求开发过程一般分为如下四个部分。
1、需求获取
需求获取指通过访谈、文件分析和会议等方法确定和理解不同业务部门的需要和限制的过程，是通过与业务部门和其他第三发系统开发相关人员交流来发现和理解业务部门完整需求的过程。
在获取需求时，要确保充分全面的业务部门参与，不能忽略某类业务部门，且要尽量避免过于抽象的、有歧义的需求，而作为研发人员不能为了获得业务部门的满意度主动添加需求。
好的需求应该是完整且一致的，没有二意性，可以被业务部门正确的理解。
2、需求分析
需求分析的目的是在需求开发的过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映业务部门的真实意图。
在分析时，需要确定需求是否完备可实现，确定需求的优先级等。
3、需求文档化
需求文档化即详细阐述、优化和将需求组织成文档的活动。
通过编写详细的需求规格说明书，使业务部门、开发者及分析和测试人员对该应用系统的初始规划有一个共同的理解，它说明了本系统的各项功能需求、性能需求和数据需求，明确标识各项功能的具体含义，阐述实用背景及范围，提供业务部门解决问题或达到目标所需要的条件或权能，提供一个度量和遵循的基准。
编写需求规格说明书时，针对业务部门的重点是清楚的表达业务部门提出的需求，让业务部门看了文档后确定他的表达和描叙是否被我们所了解，而我们将要开发的系统功能是否符合他们所提出的需求。
同时，为了让业务部门更好的了解我们提出来的模型，在文档中要加入适当的图形分析，最好是先做好系统原型。
例如报账平台的需求说明书中详细定义了每个报账单的模板，这样既可以方便业务部门理解，又可以让所有的项目风险承担者明白为何提供这些功能需求，可以凭借需求规格说明书追溯每项需求的来源。
针对开发人员的重点是告诉他们系统需要具有哪些功能，有哪些对象，对象有哪些属性，对象之间有哪些关系，就为将来的系统开发提供了目标和参考方向，同时需求规格说明书也是将来业务部门验收系统的依据。
同时有必要在需求规格说明书中为每项需求定义优先级，为后续系统扩容或升级提供依据和方向。
4、需求确认
需求确认是评估一个产品是否能满足业务部门需要并将此确认为需求的活动，需求确认确保了需求能在设计和开发之前被充分的详述以满足业务部门需求。
需求确认时要确保适当的、全面的用户参与，针对需求规格说明书逐个确认需求的完整性和正确性，重点陈述不能实现的需求，以消除业务部门的一些顾虑。
通
过对需求的多次确认，给需求开发工作初步画上双方都明确的句号。
这样有助于形成一个持续良好的业务部门与开发人员的关系，为项目的成功奠定坚实的基础。
（二）需求管理
需求管理要保证在业务部门与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。
在应用系统的开发中，需求变更不可避免，但一定要在可控范围之内。
应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保需求与开发生命周期的其他工件之间的依赖关系。
需求管理一般分为属性管理、基线确认、变更管理和需求跟踪四个部分。
1、属性管理
需求的属性就是需求的补充信息，属性管理就是为了收集有用的信息以解释、判断、跟踪和报告需求。
在属性管理工作开始时要先识别你需要跟踪的属性，定义和维护所有需求的属性，根据需求的优先级、需求的当前状态等信息进行属性管理。
2、基线确认
需求基线即应用系统开发或项目开发过程中的经过技术评审一致认同的部分，这些被认同的部分可以作为项目开发的基础，后续的研发、执行、变更都以基线为基础。
需求基线是需求开发与需求管理的分界，当需求出现变更时就需要由需求管理经过需求基线到需求开发变更控制流程。
需求基线的设立需要考虑业务规则、变更控制、业务部门观点、接口等因素。
在开发过程中，需求确定并经过评审后(业务部门参与评审)，可以建立第一个需求基线。
此后每次变更并经过评审后，都要重新确定新的需求基线。
3、变更管理
定义需求时无论怎样谨慎小心，也总会有可变的因素。
变更管理是为了更好的解决范围蔓延引起的进度、成本、质量上的问题，另一个就是要为以后留下开发空间，方便后续资源、经费的追加。
需求变更需要根据已经通过评审的《需求规划说明书》对新产生的需求变更进行分析、控制和跟踪。
4、需求跟踪
需求跟踪是跟踪一个需求使用期限的全过程，提供由需求到产品实现整个过程范围的明确查阅能力，这样可以改善质量，降低成本，实现重用。
需求跟踪的实施首先明确跟踪项、创建需求跟踪矩阵，然后使用需求管理工具进行跟踪。
二、应用系统开发阶段
与业务部门确认需求后，相关承建厂商开始进行系统开发。
在编码开发前，要确保开发环境与正式环境保持一致。
项目开发时，会制订一个开发计划。
开发计划的作用，就是作为一个进度标准，要求项目按计划来完成。
开发厂商需要通过日报、周报等方式随时与我们同步开发进度，以确保开发工作可以按时完成。
但在实际开发中，经常因为某些原因，比如人员变动和需求变化。
导致项目进度与计划发生偏差，项目进度往往会延迟。
针对这种问题，要做到发生偏差时就进行偏差分析，进而对开发工作做出调整。
在项目实施中，应该严格按照项目计划来执行，如果发生需求变更，就要及时根据变更范围去调整项目计划。
例如，人员发生变动，要确保厂商尽快采取相应的措施补充人员，如果补充不到人员，就要通过公司和部门的审批，调整进度计划，以免最后项目延迟。
三、系统测试
测试的目的是在应用系统在上线之前找出应用系统的漏洞，同时在应用系统投入运行之前，要和相关的系统、接口等完成对接，以保证各系统能协调的正常工作。
应用系统开发的质量如何，测试工作进行得是否扎实势必与能否顺利、成功地完成系统测试关系极大。
另一方面，系统测试实际上是针对系统中各个部分进行的综合性检验。
测试环境要和生产环境相同，尽量采用真实数据，在测试的同时详细描述问题，记录测试结果。
核实每个功能模块是否被准确实现时，要参考需求说明书，仔细核对每项要实现的需求是否被实现。
几种常见的系统测试包括功能测试、恢复测试、安全测试、压力测试和性能测试等。
其中有过完整接触的是对软件开发团队的日志管理系统做功能测试，根据需求文档设计测试方案和测试用例，检测日志管理系统的各功能。
除了此类常规测试外，还要对网络、硬件等进行测试，测试人员也要广一些，不能只局限于少量业务部门或者技术人员，避免问题被掩盖。
四、上线与交维
应用系统在经过开发和测试后，一般选择适当的时间即业务量最少的日子进行系统上线。
系统上线前，要提前给出割接方案，安排好上线时的具体步骤，如服务器、数据库在何时启停等，细化每个流程的负责人，确保系统上线不能影响原有的工作和业务。
上线后的应用系统要试运行一段时间，不能放弃原有的工作
流程和内容，要双轨并行一段时间，等应用系统稳定后，和其他业务系统的交互正常，数据库和服务器运行正常后方可进行彻底替换。
上线后，厂商需协助业务部门制定培训、推广计划，使相关的业务部门更好的使用系统。
参加过兰德公司的门户的交维培训，通过交维培训理解了门户迁移的背景、迁移后物理架构和动态集群等。
五、项目验收
系统交维前，要对系统进行网络与信息安全验收测试和评估，并留下验收测试记录；系统上线后，厂商需要提交技术文档，由管理部门负责签署初验报告后，归档。
以上是对接触到对应用系统建设工程项目管理有关了解，体会最多的是系统开发前期和后期中与需求相关内容，对于应用系统的开发的过程和上线交维的体会还不全面，理解不够深刻，以后在工作中会继续努力补充学习相关知识。
