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

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

正确的理解和管理需求及其变更

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

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

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

上述1，2个问题其实都是对需求跟踪和管理机制的不完善引起的。在任何一个软件开发过程中，都充分地强调了需求管理的重要性。因此，在项目初期，相对花比较多的时间做需求的搜集和跟踪，完善业务人员和技术人员的沟通机制是很重要的。这会减少大量的由于曲解需求导致软件不符合用户需求从而返工造成的人力和物力的浪费。避免这种情况产生的一种方式是，在项目立项后，由专人或专门的团队(这些人必须是了解该项目业务领域的知识，并且有相关的技术经验)搜集该项目的原始需求，然后和技术专家(或团队)进行充分的沟通和讨论，保证技术专家对原始需求乃至一些用户要求的细节有完整而正确的理解，接着技术专家就会根据原始需求的文档，根据对需求的理解撰写软件规格书，在写的过程中，应该不断让业务专家一定程度的参与(例如审稿或一定程度的修订，并且参与评审)，这样的软件规格书才能为进一步正确地进行软件分析设计提供素材和指导。对第3个问题，用户提出的对软件进行改进可能是经常有的事情，遇到这种情况，有两种处理办法。一种办法是用户提出的改进建议在下一个发布版本中实现。但是用户往往要求能够在当前版本中进行实现。第二种办法就是认真考虑用户用户的建议，用各种方法来满足用户的需求，其中包括系统重构。在这些过程中，可能会造成一些混乱。其实归根结底还是需求的跟踪机制不完善引起的。建议采用需求和变更跟踪工具(比如rational clearquest)来对需求和变更进行全过程的跟踪，这样在形成需求文档的时候，每个需求来源和其状态都是非常清楚的。

配置管理

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

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

问题2: 培训和支持不充分，对配置管理工具的用法不了解。目前配置管理工具很多，比如大家常用的vss，可能相对比较熟悉一些。但是诸如CVS和ClearCase 等工具，由于软件功能非常复杂，并且对国内用户来说易用性比较差，虽然功能强大，但是没有真正派上用场。

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

此，在项目启动后，经过技术人员之间的讨论，在配置项的命名规定，目录结构，存放位置等达成共识，因为这些在具体使用上还和开发工具，开发语言等是密切相关的，在讨论的时候也应充分考虑这些因素，给技术人员在使用它们的时候提供最大的便利。当然，为了安全起见，大型项目中，权限的控制也是很重要的。另外，在一些情况下，如果没有权限控制，项目成员可以随意修改其它文件，这样可能会导致一些混乱情况的发生。

第二个问题，对ClearCase等大型的配置管理工具，如果不作充分的研究和大量的培训，对软件配置和使用不当，缺乏对组织内人员的统一培训，因为配置管理工具是几乎每个人都会用到的，这样造成的问题会相当多。在ClearCase中，比如基线的概念，可能很多人都不甚了解，还有动态视图，静态视图，集成视图，流等，这些如果不能做充分而细致的培训，技术人员会感到相当的困惑，如果支持不到位或在使用中的问题无法解决，会造成项目进度的延迟乃至停滞。所以，在对待此类问题上，培训和支持的工作是必不可少的，虽然可能会在初期浪费一些资源，但是磨刀不误砍柴功，组织内人员都掌握了强大工具的使用方法，将会极大地提高开发效率和节省时间。

。

文档

国内进行软件开发从最初的完全不重视文档，到后来吸取无数的经验教训后，对文档的重视又被提高到前所未有的地步。但是不少公司对应该写多少文档，怎么写文档不能把握好，因为技术人员往往对文档方面的任务是抵触的，认为不如多抽点时间专注在技术方面，写文档纯粹是浪费时间。但是文档却是必不可少的，应该怎样处理好这种矛盾呢? 事实上，这种矛盾天生就是难以化解的，因为技术人员对技术和相关情况最了解，其它人很难撰写这些文档，项目经理所需要做的是，通过斟密的项目进度安排，给技术人员留出一些时间来书写文档(在工作时间而不是在加班时间里完成，否则难免会有怨言的)，并在规定的进度下进行评审。在Rup和Xp中，对文档的看法有些不一样。在RUP中，对文档非常的重视，每个阶段都有一些工件是必须要评审和交付的，其中除了代码外，绝大部分都是文档，写起来相当费时费力。而在XP流程中，强调的是通过代码和面对面的沟通，来加强团队的协作性，文档除了一些设计性和需要保留的资源需要撰写外，只是起到一些辅助性的作用。但不管怎样，重要和必要的文档总是要写的。让每个技术人员了解文档的重要性，合理的分配和预留写文档的时间，都是可以一定程度上化解矛盾的做法。

如何保持工件的一致性(同步)

在软件开发过程中，不断有新的工件产生，而且有些工件随着一些变更的发生，就需要进行更新，但工件数量太多，一则维护更新不容易，另外有些工件只是项目结束后参考性的资源，立即更新也不必要，求大求全则会一定程度上占用项目资源，耽误进度。因此，一个建设性的建议就是，对必要的工件，如需求规格书，产品定义书，概要设计书，详细设计书.....等工件是一定要根据项目和评审情况立即进行修订和更新的，但是，对另外一些衍生的工件，如用户指南等工件，虽然在开发流程中，可能是在每个阶段都必要写的，但是却可以在评审进行前集中进行更新一些，避免频繁修订造成的资源占用和进度延迟。

重视风险管理

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