教育软件项目实施问题的分析和策略应对

　为了认真贯彻党的十五届五中全会精神，加快在中小学普及信息技术教育的步伐，教育部2000年11月14日发出《关于在中小学实施“校校通”工程的通知》，决定在全国中小学实施“校校通”工程。从此，全国各级各类学校都开始建设校园网，教育信息化飞速发展。以江苏南京为例，几乎所有的中小学、幼儿园都已经建立了千兆或百兆到桌面的校园网，并以10 M，100 M以上带宽专线接入互联网，甚至不少学校的网络都已经更新换代过好几次。解决了硬件、网络问题之后，各单位开始开发各种应用系统，以充分发挥信息化的优势，提高教育教学、日常办公的效率。经过多年的发展，我们取得了很多成果，推出了很多好的应用，但也出现了不少问题。
　　一、存在的问题
　　1.注重前期投入，忽视升级保障
　　软件和硬件不一样，硬件靠一次性投入，好坏主要看产品质量和前期投入，有各种指标去检测衡量，只要达标即可。而软件是智力产品，虽有各种性能指标来评测，但是软件总归是有缺陷的，所以没有最好，只有更好，需要不断地修复与完善，需要持续的人力、物力投入。有生命力的软件，哪个不是持续升级的？
　　2.过分追求个性化，拉高开发成本
　　在实际项目中，十个领导十个都会说，我们需要做出一个有特色的平台，跟其他的不一样。这种思想无可厚非，但是这正中了软件公司的下怀，本来各单位可以通用的产品，现在每个单位都要定制一套，浪费大量资金，不利于教育行业软件的发展。可喜的是，我们的职能管理部门已经意识到这个问题，不少省、市、区已经开始进行顶层设计，制定各种标准，虽然这些标准未必就是完美的，但有总比没有强。
　　3.贪大求全，追求研发速度，违背开发常理
　　很多单位在早期信息化软件建设时，胆子小，建设的平台功能都比较较单一，效果也很好，但现在面临多个系统整合的问题。还有一种极端是：当前很多单位的信息化软件建设，一上来就要做大而全的系统，什么功能都要有，方方面面都能管理，有的9月才立项，12月就要上马。作为用户，这些要求无可厚非，但却违背了软件开发的常理，不切实际，是“大跃进”，搞到最后产品是一摊烂泥，可能计划3个月，结果搞了3年，还没做好。
　　4.需求分析不充分，缺少系统详细设计，开发常返工
　　软件项目前期最重要的就是需求分析，有的项目连需求都没弄清就着手开发，有的项目没有进行系统详细设计，最终的产品符不符合需求可想而知。由于需求分析及设计工作没做好，项目开发过程中，开发人员老是抱怨我们的需求不固定、变更太频繁，我们则抱怨开发人员不理解自己的思路，做出来的产品不是想要的，最终拖垮了开发人员，也连累了自己。
　　5.缺少系统测试，产品瑕疵多，系统稳定性差
　　软件最终是要在日常工作中投入使用的，如果能尽早试用，就能尽早发现问题，从而修正开发方向，弥补开发失误。然而，很多软件在开发过程中，没有测试制度或规范来约束和保障，没有组建测试团队，甚至在整个开发周期中，开发人员只管自己埋头编程，不及时让用户参与开发版的测试，更不用说单元测试、白盒测试、黑盒测试、回归测试、集成测试、冒烟测试、压力测试等，就将产品匆匆集成交付。这样制作出来的软件必然有缺陷，错误多多，稳定性差。
　　二、解决的办法
　　1.转变思想观念，改变合作模式
　　软件开发是一种智力密集型的劳动，一个软件产品的问世，凝聚了开发人员的汗水、心血和智慧，同样离不开用户的全力配合和支持。软件项目启动后，需要我们和开发人员不断交流，进行头脑风暴、思维碰撞，做需求分析；在原型设计、系统详细设计时，需要我们进行确认；在程序设计和开发阶段需要对项目做持续构建，以方便测试团队和我们对系统进行及时测试和试用。所有这一切绝不能认为只是开发人员的事情，与用户无关，我们必须清醒地认识到，如果用户不尽心参与，软件必定做不成功，做好了也不好用。软件开发需要我们全员参与，积极主动地全身心投入，参与开发的全过程。
　　2.协助做好需求分析和系统设计工作
　　软件有生命周期，一个好的软件生命周期可以很长，差的软件从交付那天起生命周期可能就终止了。软件生命周期包含：问题定义、可行性分析、需求分析、系统概要设计、系统详细设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，每个阶段都要有定义、工作、审查并形成文档，以供交流或备查，提高软件的质量。
　　在项目的可行性分析阶段，我们必须实事求是，选择合适的硬件平台、熟练掌握并精通的语言、成熟稳定的技术架构，制定合理的产品指标，让一切都在开发人员及用户的能力掌控之下，切不可好高骛远、不切实际，选择超过预算的硬件、超过能力掌控的软件技术、根本达不到的性能指标。
　　项目的需求分析必须详细，用例分析必须清晰，重点业务要辅助以原型设计、业务流程图。在需求分析中，很重要的一个环节就是编写用例说明。用例是一个动词或短语，表示谁要做什么事情，事情描述必须清晰，功能必须单一，以便于程序设计；如果用例过大，会造成用例描述不清楚，编程麻烦。在项目进行中，需求变更一般是避免不了的，那么双方如何处理呢？我们要坚持一个原则，任何需求变更必须有书面（或邮件）报告，由双方责任人签署意见，注明受此影响的研发费用处理方式、项目周期变更情况。
　　编制系统详细设计说明书的目的是为了说明软件系统各个层次中的每个程序（模块、接口或子程序）的情况、数据库系统的设计情况，以便为程序员编码提供依据，其重点是业务执行流程和数据库系统详细设计。如果项目比较小，功能比较简单，可以只编写概要设计说明书。当前软件开发一般采用面向对象思想、分层模式设计，各层之间松耦合。如果是B/S应用，现在一般会采用AJAX，HTML5等技术，以提高用户体验效果。
3.要求开发人员做好配置管理、持续交付工作
　　配置管理指是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。通俗地说就是开发人员的代码、文档必须放在诸如CVS，SVN，Git等版本控制之下。
　　持续交付就是将持续集成工作扩展到整个软件生命周期，频繁且规律性地自动构建代码并将其部署到测试环境中，然后通过一系列的测试，选择适当的版本部署到预演环境中试运行，最后选择稳定的版本部署到生产环境中，我们可以尽早参与软件使用，使软件BUG能及时被发现[1]。
　　4.做好软件测试工作
　　软件测试主要从以下几个方面来进行：
　　（1）兼容性及UI友好度测试。C/S软件、单机软件要检测其对操作系统的要求，好的软件不挑系统。B/S软件要检测页面对浏览器的要求，好的B/S软件能够在各种浏览器、各种版本、各种分辨率上有良好的表现。软件UI友好度决定着一个软件的成败。好的软件用户界面美观大方，符合大众审美观，积极向上。软件操作符合主流习惯，容易上手，一个任务操作步骤一般控制在3步以内。如果软件功能复杂，需要提供菜单式、向导式操作界面。好的软件应具有详细的帮助文章，具有入门教程、主要功能操作指导教程，人机交互时，应具有准确恰当的提示信息，输入错误时应有相应的错误提示信息。
　　（2）代码规范性及稳定性测试。软件编码应该符合该语言相应的规范标准，注释、缩进等恰当、准确、详细。所有功能应具有相应的单元测试。软件的稳定性需要详尽周全的测试和运行。主要指标：无故障工作时间、最大在线用户数、响应速度。
　　（3）可维护性及可扩展性测试。系统维护包括：系统升级、系统安装；数据管理包括：数据导入、数据备份、数据恢复；安全性包括：系统安全性、密码策略、权限控制等。可扩展性包括：是否支持二次开发、是否支持第三方接入。好的软件维护方便，可扩展性高。
　　5.做好软件验收工作
　　软件测试通过后，就可以做项目验收了。一般来说，项目验收需要准备如下文档：（1）开发总结文档；（2）需求文档：包括需求规格说明书、需求变更文档等；（3）设计文档：包括概要设计、详细设计、数据库设计等；（4）测试文档：包括测试方案、内部测试报告、第三方测试报告等；（5）实施文档：包括实施部署方案、用户手册、维护手册等；（6）过程文档：包括项目周报、会议纪要等。
　　在这些文档中，需求文档、设计文档、测试文档最为重要，其中测试文档必须由软件测试得来。
　　三、结束语
　　软件项目管理是一门融合众多技术、知识的综合学科，不是一篇短文所能说清道明的，本文以用户的角度分析了当前软件项目合作中存在的问题，提出了对应的解决办法，以期改变双方的合作模式，规范开发流程，从而提高软件开发效率和产出质量。
　　参考文献
　　[1] 乔梁.走向“持续部署”[EB/OL].http：//page/157115.