软件开发过程中的常见问题及对策

软件开发过程中的常见问题及对策
正确的理解和管理需求及其变更
问题1: 从项目的需求搜集开始，业务专家搜集和提出基于整个业务的需求体系，但是在从初始的需求转化为软件特性和功能的过程中，由于业务专家和技术人员的沟通不充分或者需求描述不完善，导致技术人员对需求的理解产生曲解，从而影响该软件完成后不符合用户提出的真实需求。

问题2: 从初始的业务需求转化为软件特性的过程中，缺乏有效的跟踪和管理，导致软件功能特性与用户需求脱节。

问题3: 在项目过程中，用户提出改进的需求或者增加软件功能和特性，项目组在了解需求后，对软件架构进行调整或者重构，但是如此频繁的重复下来，需求来源不清楚，软件规格书未反应需求变化，或者接受需求但未调整项目的整体进度，导致一些混乱情况的发生。

上述1，2个问题其实都是对需求跟踪和管理机制的不完善引起的。

在任何一个软件开发过程中，都充分地强调了需求管理的重要性。

因此，在项目初期，相对花比较多的时间做需求的搜集和跟踪，完善业务人员和技术人员的沟通机制是很重要的。

这会减少大量的由于曲解需求导致软件不符合用户需求从而返工造成的人力和物力的浪费。

避免这种情况产生的一种方式是，在项目立项后，由专人或专门的团队(这些人必须是了解该项目业务领域的知识，并且有相关的技术经验)搜集该项目的原始需求，然后和技术专家(或团队)进行充分的沟通和讨论，保证技术专家对原始需求乃至一些用户要求的细节有完整而正确的理解，接着技术专家就会根据原始需求的文档，根据对需求的理解撰写软件规格书，在写的过程中，应该不断让业务专家一定程度的参与(例如审稿或一定程度的修订，并且参与评审)，这样的软件规格书才能为进一步正确地进行软件分析设计提供素材和指导。

对第3个问题，用户提出的对软件进行改进可能是经常有的事情，遇到这种情况，有两种处理办法。

一种办法是用户提出的改进建议在下一个发布版本中实现。

但是用户往往要求能够在当前版本中进行实现。

第二种办法就是认真考虑用户用户的建议，用各种方法来满足用户的需求，其中包括系统重构。

在这些过程中，可能会造成一些混乱。

其实归根结底还是需求的跟踪机制不完善引起的。

建议采用需求和变更跟踪工具(比如rational clearquest)来对需求和变更进行全过程的跟踪，这样在形成需求文档的时候，每个需求来源和其状态都是非常清楚的。

配置管理
配置管理占据了越来越重要的角色，对文档，图形，代码和各种项目数据进行分类管理，并对不同的人拥有的权限进行控制，方便技术人员对其负责的配置项进行创建，提交和修改，提高项目整体的运作效率。

但是在配置管理中也存在着一些问题：
问题1: 没有制定好文档，图形，代码应放的位置，配置项命名比较随意，无权限控制，造成各配置项存放混乱，寻找不易。

问题2: 培训和支持不充分，对配置管理工具的用法不了解。

目前配置管理工具很多，比如大家常用的vss，可能相对比较熟悉一些。

但是诸如CVS和ClearCase 等工具，由于软件功能非常复杂，并且对国内用户来说易用性比较差，虽然功能强大，但是没有真正派上用场。

对第一个问题，在小型项目中可能尚不明显，但是在大型项目中，由于各种文档，代码等非常多，如果不能进行正确的配置管理，很有可能被弄得一团糟。

因
此，在项目启动后，经过技术人员之间的讨论，在配置项的命名规定，目录结构，存放位置等达成共识，因为这些在具体使用上还和开发工具，开发语言等是密切相关的，在讨论的时候也应充分考虑这些因素，给技术人员在使用它们的时候提供最大的便利。

当然，为了安全起见，大型项目中，权限的控制也是很重要的。

另外，在一些情况下，如果没有权限控制，项目成员可以随意修改其它文件，这样可能会导致一些混乱情况的发生。

第二个问题，对ClearCase等大型的配置管理工具，如果不作充分的研究和大量的培训，对软件配置和使用不当，缺乏对组织内人员的统一培训，因为配置管理工具是几乎每个人都会用到的，这样造成的问题会相当多。

在ClearCase中，比如基线的概念，可能很多人都不甚了解，还有动态视图，静态视图，集成视图，流等，这些如果不能做充分而细致的培训，技术人员会感到相当的困惑，如果支持不到位或在使用中的问题无法解决，会造成项目进度的延迟乃至停滞。

所以，在对待此类问题上，培训和支持的工作是必不可少的，虽然可能会在初期浪费一些资源，但是磨刀不误砍柴功，组织内人员都掌握了强大工具的使用方法，将会极大地提高开发效率和节省时间。

文档
国内进行软件开发从最初的完全不重视文档，到后来吸取无数的经验教训后，对文档的重视又被提高到前所未有的地步。

但是不少公司对应该写多少文档，怎么写文档不能把握好，因为技术人员往往对文档方面的任务是抵触的，认为不如多抽点时间专注在技术方面，写文档纯粹是浪费时间。

但是文档却是必不可少的，应该怎样处理好这种矛盾呢? 事实上，这种矛盾天生就是难以化解的，因为技术人员对技术和相关情况最了解，其它人很难撰写这些文档，项目经理所需要做的是，通过斟密的项目进度安排，给技术人员留出一些时间来书写文档(在工作时间而不是在加班时间里完成，否则难免会有怨言的)，并在规定的进度下进行评审。

在Rup和Xp中，对文档的看法有些不一样。

在RUP中，对文档非常的重视，每个阶段都有一些工件是必须要评审和交付的，其中除了代码外，绝大部分都是文档，写起来相当费时费力。

而在XP流程中，强调的是通过代码和面对面的沟通，来加强团队的协作性，文档除了一些设计性和需要保留的资源需要撰写外，只是起到一些辅助性的作用。

但不管怎样，重要和必要的文档总是要写的。

让每个技术人员了解文档的重要性，合理的分配和预留写文档的时间，都是可以一定程度上化解矛盾的做法。

如何保持工件的一致性(同步)
在软件开发过程中，不断有新的工件产生，而且有些工件随着一些变更的发生，就需要进行更新，但工件数量太多，一则维护更新不容易，另外有些工件只是项目结束后参考性的资源，立即更新也不必要，求大求全则会一定程度上占用项目资源，耽误进度。

因此，一个建设性的建议就是，对必要的工件，如需求规格书，产品定义书，概要设计书，详细设计书.....等工件是一定要根据项目和评审情况立即进行修订和更新的，但是，对另外一些衍生的工件，如用户指南等工件，虽然在开发流程中，可能是在每个阶段都必要写的，但是却可以在评审进行前集中进行更新一些，避免频繁修订造成的资源占用和进度延迟。

重视风险管理
建立风险管理体系，让风险意识贯穿整个流程体系，对不断出现的可能的风险进行预测，分析和讨论对策，划分风险级别，采用各种方法来降低风险变成现实
后对整个项目所造成的损失。

风险管理体系是一个项目预防可能潜在风险的一个很好的保障方式，在项目初期，根据项目情况如资金，人员和可能的进度对整个项目的风险作一个预先的评估，采用的方式可以是以项目经理为中心，集体讨论的形式来进行。

在讨论结束后形成一份risk list，项目经理
由此整理出一份文档，即风险管理文档。

在项目进行当中，随着情况不断变化，项目经理应该不断组织一些专题会议，对风险进行讨论，并统一对策。

这样在风险变成现实后，整个项目组不至于束手无策，而是可以采取一些补救的措施来把风险可能造成的损失降到最低。

关于周报和月报
在很多公司中，都要求开发人员填写周报和月报，以便在项目周会，月总结上了解每个人任务的进展情况和对人员进行考核。

但是技术人员总是对此类工作不胜其烦，往往敷衍了事，填几个比较大的任务(如开发XX系统等)，而且一连几周都是如此，这样对了解项目进展和对人员考核的参考作用就失去了意义。

虽然技术人员比较反感写这类东西，但是还是必须要写的。

应该怎样化解此类矛盾呢？实际上，这类任务主要是人的因素在发挥作用。

要想达到有效性的目的，对项目成员进行一定程度的指导和培训是必要的。

例如，一种比较好的方法就是，可以推荐项目成员进行daily plan一类每日计划的编写，每个人对每日工作任务进行划分和规划时间，然后在每日工作结束后对预先计划和完成情况进行对比，并在下一个工作日进行改进。

坚持下去，项目成员必然在工作计划和完成情况间越来越接近，养成良好的习惯，这样不仅在保障进度上人的正面因素可以被大大增强，而且在编写周报和月报时就有所依据而不是匆匆了事，能够发挥应有的效果。

了解培训的重要性
在各类组织中，都会对员工进行一定程度的培训。

在项目立项过程中，就应该考虑人员配备情况。

比较理想的情况当然是项目组每个成员都对该项目的技术了如指掌，对软件开发流程比较了解，相互之间能够进行充分的沟通，能充分理解沟通对象的意图等等。

但是理想情况往往不是经常存在的。

由于IT行业的人员具有一定的流动性，而且项目组的人员配备往往不是非常固定的。

因此，项目经理应该充分考虑到这些因素，在项目成员比较确定后，如果有一些新手，就必然要进行一些技术，业务，开发流程等方面进行有计划的正式培训，当然，还应该指定每个老资历的项目成员带1-3个新手，这样，新手在各方面都能够迅速提高，也能促进整个项目按照预先计划高质量地完成。