论信息系统项目的集成管理.docVIP

论信息系统的本文结合作者的经验就项目的管理作了的论述；并就项目过程中采取的措施、方法作了介绍。最后，列举了该项目管理的一些不足 有效的沟通是项目成功的必要条件。为解决好这个问题，我采取了三个办法： 1、提高大家对沟通作用的认识，特别是提高领导人对沟通必要性和重要性的认识，从而对沟通工作给予必需的人员、经费和时间支持，保证了沟通工作得以按计划进行。 2、对项目组外部的沟通，坚持从实际出发，采用多种沟通方式。一方面，把必要的、重要的沟通需要以联席会议、工作计划、总结报告的形式制度化。另一方面，在适用的前提下，采用灵活、经济的沟通方式。比如：对一般的小问题或者是简单问题进行电话交流；复杂一点的问题开碰头会；需要后续解决的、比较重要的、涉及面较大的问题要形成书面的会议记要，有必要的情况下要由相关单位加盖公章确认。 3、对项目组内部沟通，进行适当的控制，避免形式主义，在保证效果的前提下节省时间，提高工作效率。规定项目组成员在每天工作中遇到的问题，将其记录下来，然后再以邮件方式发送给需要沟通或询问者。大家每天下班之前收取邮件，对于可以直接回答的问题则直接以邮件方式回复，对于无法直接答复而只需与提出问题者讨论的问题，在第二天上班前进行商议确定。而需要众人一起讨论的问题，则放到每周会议上讨论，较紧急的问题召开临时性会议。 通过以上方法，基本上实现了有关各方及项目组内部的有效沟通，及时发现问题、解决问题，避免了因各方立场不一致造成严重对立而影响项目进度，避免了因交流不畅形成重大质量问题。 二、合理配置人员，通过对人员的控制，达到对质量的控制。 通过对角色的质量控制，达到对软件质量的控制。我们制定了各组的规范及各类人员的职责，作为控制的标准。对项目组人员进行规划配置，合理分工，明确责任，保证项目各阶段、各方面的工作能够按计划完成。我们在项目组中配置了以下人员：技术组长一名，负责技术难题攻关，组间沟通协调；需求人员5名，负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化；设计人员5名，根据需求规格说明书，进行系统设计；开发人员8名，实现设计，完成用户功能；集成人员1名，负责整套系统的编译集成，督促各小组系统功能提交，及时发现各模块集成问题，起到各小组之间沟通的纽带作用；测试人员2名，对集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计；文档整理人员1名，将各小组内产生的文档进行整合、统一；维护人员1名，系统验收后维护系统，建议维护人员早期进入项目，参与系统测试，以便顺利承担起系统维护责任。 在人员的管理方面，一方面要求项目组成员相对稳定，以保证开发工作的连续性；另一方面，对不能够胜任工作的坚决调换，保证项目整体工作不受影响。通过平常和阶段性的工作考核、评价，对不合格人员进行调换。有一名需求分析人员因为工作态度不好，与客户单位的业务人员关系恶化，调查属实后，我们立即把他调出项目组。 三．重视需求变化的客观性，加强配置管理，控制变更。 我们采用了软件工程方法，使用渐增式的增量模型，注重满足用户需求和需求的变化。虽然在项目立项之初，省行科技部面向所有业务部门组织了需求征集活动，并形成了《需求说明书》，但由于业务调整的不断变化，造成调账系统的需求变化频繁。根据这个情况，为保证软件满足应用需要，我们规定：在整个项目的开发过程中，凡是业务部门提出的、经调查情况属实、经技术可行性论证可行的，全部予以响应。同时，采取措施避免需求的反复和无意义、不合理的变更。对较大的变更和比较关键的变更，要经各方联席会议论证通过，参与人员签字负责，并由提出变更的单位加盖公章确认。对于不合理或技术上不可行没有通过的需求变更，要提出替代的解决办法，并与业务单位协商，达成一致意见后予以解决。 我们由项目经理、业务代表、质量控制人员、配置管理人员组成变更控制委员会（CCB），按照提出变更、审查变更、批准（否决）变更、实施变更、验证变更、记录变更及原因的程序严格控制配置项变更，使项目的混乱减到最小，使错误达到最少。另外，我们也深刻体会到：只有和变更控制进行配合，将变更的原因和变更的结果（配置项的某一版本）联系在一起，才能以变更为主线，将所有版本变为“有理由的”，才能形成基线，真正发挥变更控制和版本管理的作用。 由于项目资金已经确定，我就在进度和质量之间找平衡点，力争把风险降到最低。由于业务流程不是很规范，系统需求也在不断调整、完善，给项目的进度带来一定影响。由于这个项目涉及到提高服务质量和社会信誉的问题，影响很大，通过与业务部门领导沟通，取得了他们的有力支持，在质量和进度之间优先考虑质量。同时，考虑到这个项目采用了增量开发模型和模块化的设计方法，我把项目目标进行了分解，涉及到业务经办的部分优先完成，保证系