气象软件的开发风险与解决策略探讨

导语：气象软件的开发风险与解决策略探讨一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

项目开发中的风险与解决方法

对于大型复杂的海洋气象服务项目而言，最大程度的减少项目风险，对于项目的成败至关重要。下面结合我在这个海洋气象预警服务平台项目管理过程中碰到的风险相关问题分别加以讨论。识别风险和编制风险管理计划与风险应对计划首先我们在项目开发的前期风险工作中要识别项目风险，编制风险管理计划和风险应对计划。在本次软件开发项目中的风险主要是该项目要将先进的海洋天气预报模型移植到小型机上的工作，软件预报模式本地化运行的效果，要求能在几个小时内出结果，保证预报的时效，否则当你运行三天后才出结果，时间早过了。另外，项目要求采用流行的B/S架构和地理信息系统作二次开发，项目人员少，每人都兼了多个角色，不过，可复用以前做过的项目的一部分源代码，包括数据库操作类、权限管理类等。项目参加人员分布在省内沿海地区气象各级台站，这无疑增加了沟通的难度，在项目一启动，基本了解客户需求的情况下，我召集开发人员、气象专业人员、单位领导、甚至别的项目组人员坐到一起，采用头脑风暴法，来分析该项目存在的风险，同时借鉴风险历史数据库中的风险数据，取出我们没有想到而确实存在的风险条目，也将它们添加到本次软件开发的风险列表里，然后分析研究每个风险条目发生的概率、风险级别，而且针对该风险条目而制定的应对措施，并形成一个风险记录表。风险管理贯穿项目的始终，风险管理计划和风险应对计划缺一不可。因为风险一直在变化，所以在项目实施的每个阶段都要更新。进度风险与应对方法进度风险是项目管理中比较常见的风险，我们要制定合理的项目管理计划，化解开发中的进度风险。该项目工作量大，时间短，只有一年。作为项目经理，我的压力非常大，所以我做开发进度计划的时候，根据最终交付日期，采取倒推法，将时间逐一分配到各个任务上，同时尽量考虑到任务的并发执行，而且要细化到半天。我使用MSProject软件，利用PERT技术，在工作分解结构上定义每个任务的开始时间，结束时间，识别关键路径，然后从甘特图就能自动显示人力资源状态图，能自动统计每个人每个任务或者每个时间段的工作量，而且通过这个软件，可以非常方便的拆分任务，定义里程碑事件等。范围风险与应对方法在软件开发过程中，需求总会不断的变化，要将范围扩大风险降到最低需要进行软件需求管理，降低项目范围的风险。在和客户的初步沟通中，确定了需求的大致范围，定下了海洋天气预报信息、海洋天气预警信息、实时天气监测信息和历史气象信息四个大项，每个大项内又有10到20多个模块，然后针对每个模块讨论实现的功能、数据的流程、模块间的接口等。因为有些业务包括用户在内都不太清楚，所以在需求讨论的时候常常很难达成一致的意见。于是，我使用了WORD版本控制功能，几易其稿，使需求基本趋向一致，形成了软件功能规格说明书，确定了产品的范围，双方签字认可。然后，我用Excel做了一个软件需求跟踪矩阵，是一个二维表格，每行就是一个功能，而且是按层次分解的，每列是一个阶段，从需求定义阶段开始，到设计、编码、测试、交付、维护等阶段。在每个阶段结束时都来更新这个需求跟踪矩阵，主要是更新每个任务的状态，如已批准、已实现、已确认、已删除，如果功能点有变化，可以在上面增加或者修改、删除该功能点，管理起来非常方便和有效。另外，我们采用软件原形开发的模式，主要分为两个阶段迭代。我将需求按优先级排序，先完成客户最想要的功能。沟通风险与应对方法沟通是软件开发过程中及为重要的一方面，因沟通不畅带来的风险也是我们这次软件项目开发中的常见问题，因此我制定了沟通计划，解决项目中沟通的风险。在该项目中，用户分布在全省各市县，沟通不太方便。与用户的沟通基本是Notes，因为全国气象部门内部都是使用Notes进行办公，它达到县级气象台站。我单位也有专用ID，也就是Notes邮箱的帐号，我在单位内发的Notes邮件可以传到省气象局客户那里，使用这种邮件沟通方式查阅方便，跟踪起来也容易，客户也都习惯使用该方式办公。而且Notes沟通非常大的好处是沟通内容都落在纸面上，便于将来分清责任。其次，是电话联系，这种沟通方式最直接，和客户的沟通，效果可能更好。此外，我上级领导总在另外一个城市办公，所以遇到需要上级领导拍板的问题我就借助于单位的视频会议，而且邀请用户参加，不但及时解决这些问题，同时也让用户感觉到我们管理层对该项目的重视和支持。

项目开发风险的总结

在项目团队经过一年的辛苦工作后，项目才得以顺利完成，得到省气象局业务主管领导的好评，这不仅是对项目的高效稳定的赞许，而且也是对我们这个项目团队的赞许。我在本项目实施过程中总结出了项目风险管理成功的几点因素：1项目变更的有效执行和控制，防止了需求的不断变更和范围的蔓延，保证了进度按原计划进行的重要因素。2定期召开的项目例会，让我及时了解各小组进展情况和遇到的问题，通过交流遇到的问题，发挥集体智慧，共同探讨解决的方法。3在聘请的老专家和老教授帮助下，项目组克服了不少技术与业务上的的难点。4项目质量是用户最关心的，定期请用户参与项目阶段性质量评审，坚定用户的信心。当然，在该项目的实施中也并非一帆风顺，由于对开发人员流动性的估计不足，另外我方业务骨干也并非只为这一个项目工作，导致项目的进度和人力资源发生冲突的事常有发生。于是，我重新整理项目历时估算，资源估算也做得更为细致，及早向单位领导提出人员调用申请，与各部门领导沟通，与项目小组负责人深入沟通，确保项目顺利实施。另外，在项目开发团队成员中由于既有新人，也有从业多年经验丰富的骨干，人员的绩效结果也参差不并。在项目进行了三个月后，有组员出现了情绪不高的情况，我和相关小组负责人进行了分析和了解，发现由于熟悉业务和技术的人员都关心自己的绩效完成情况，对新人的请教和学习没有耐心解答和帮助。针对这样的情况，我和各小组负责人商议，每个月中和月底，定期组织项目成员的培训和经验交流会议，为期半天，每次由2-3名业务骨干进行主持，内容丰富或者效果好，则给予一定的奖励，这样加强团队整体能力的提升，又为单位培养了新人。项目在开发过程中实施的各项活动交互重叠，不可避免的会发生冲突和矛盾，矛盾和冲突发生时，在双方方案均具有合理性，又各持已见、相持不下时，换位思考以求折中、平衡，从而化解冲突和矛盾，不失为整体管理工作中的一项行之有效的方法。在本项目中，历史资料和实时资料从短期预报、中期预报和长期预报上的计算方法、使用上的不相同，各类预报业务人员由于专业背景的关系和研究方向上的差异，在对问题的解决上，常各持己见，互不相让。为了解决这一问题，我们经过计划和组织，在每月抽半天举办项目开发中的学术交流活动，请两方的专家讲解、介绍各自领域的知识，使双方都能从对方的技术观点有客观的理解，从而有利于在工作配合、协调时，能够站在对方的角度，寻找双方均满意的平衡点，为海洋气象预报预警服务项目的成功实施创造了良好的氛围。因为项目要求基于web地理信息系统开发，我单位在这方面的技术人员少，所以需要经常加班研究相关技术，大家非常的疲惫，而且加班费很少。我也采取了一些弥补措施，请求单位领导在精神方面做了一些鼓励和表扬，适当的也去聚餐、参加集体运动，一定程度上缓解了紧张的氛围，而且大家也没有太多的怨言，否则就要另当别论了。项目初期文档模板准备不充分，很多情况下由于不同书写者的习惯，使得文档千奇百怪，增加阅读者的阅读难度。为了减少软件开发人员和开发人员之间的通讯障碍，提高沟通效率，我和项目组成员集体制定了应对措施，事先规定文档书写规范，命名规范、重视文档的编写、保管等工作。重视文档与设计的一致性，先修改文档，再修改程序，不至于因为文档与设计的不一致而影响工期，对跨越里程碑的文档修改设置严格评审。

海洋气象预报预警服务项目顺利成功的实施完毕几个月后，于2012年3月获得了省气象科研开发一等奖，等同于地市级科技进步一等奖，本人排第三位。现在回头再想想对这个项目的管理，我学到了很多书本中学不到的知识，让我明白一个项目经理必须要做好项目的风险管理，才能保证项目的顺利实施，通过与项目风险管理，可以很好的处理已发生的问题和为即将发生的问题提供有效的解决方法，极大的提高了项目的实施效率。

本文作者：祁欣任曙霞马文静杨红梅多海伟曹德煜白雪班欣张华荣工作单位：江苏省连云港市气象局