软件项目开发风险.pdfVIP

参加过项目制作的人 都知道一个项目开发过程中 会遇到许多困难，很多事情都会 影响一个软件开发的失败 风险是在项目中发生的一系列事件或不利结果的可能性。软 件开发是一项高风险的活动，在项目开发过程的任何一个阶段都可能存在风险。采取积 极的风险管理方式，可以使项目进程更加平稳，可以获得很高的跟踪和控制项目的能力， 可以规避、转移风险，或缓解风险带来的不利影响。风险管理是对项目风险进行识别、 分析、应对和监控的过程，是项目管理中很重要的管理活动，有效的实施软件风险管理 是软件项目开发工作顺利完成的保证。风险管理的达成必须包括三个要素：首先，在项 目开发计划中必须制定风险管理计划；第二，在项目预算中必须包含解决风险所需的经 费；第三，评估风险时，风险的影响也必须纳入项目计划中。 下面就软件开发过程中经常发生的风险， 2. 需求不明确 需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界 定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发 过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。 确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题： (1) 让用户参与开发 提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代 的需求分析和系统测试阶段，让客户能够参与开发。 在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参 与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代 表性的用户参与。 仅仅让用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。 (2) 开发用户界面原型 用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式， 帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面 原型的作用仅仅是收集用户需求，不应该再作它用，也不要给用户造成系统快要实现的 错觉。 (3) 需求讨论会议 对于用户分布广、用户量大的项目，要全面收集用户需求，往往很困难，通常采取需求 研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见，然后 集中各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求。本方法 适合于具有一定信息系统使用经验的用户。 (4) 强化需求分析与评审 首先，需求分析是项目成功的基础，需要引起足够的重视，并分配充足的时间和人力， 要让有经验的系统分析员负责，切忌让项目新手或程序员负责。其次，要进行需求评审， 尽可能让用户参与需求评审，不要让需求评审流于行式。第三，也是最重要的一点，通 过评审的需求规格说明书，要让用户方签字，并作为项目合同的附件，对双方都具有约 束力。在公司内部要将通过评审的需求规格说明书，纳入配置管理。 3. 项目缺少可见性 当一个项目经理或一名开发者说已经完成了 80%的任务，您必须保持审慎的态度。因为剩 下的 20%可能还需要 80%的时间，甚至永远都不能完成 [1] 。软件开发项目，往往在项目 进度和软件质量方面缺少可见性，项目越缺少可见性，项目就越难以控制，项目就越有 可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。 (1) 迭代开发 采用迭代的开发模型，将产品的交付过程分为多个阶段，按照功能递增式交付。以下是 一些典型的迭代： 一次简短的先期迭代，以建立规模和前景并确定商业理由； 一次精化迭代，其间将为稳定的构架划定基线； 一次构建迭代，其间将实现用例并充实构架； 几次产品化迭代，将产品转移到用户群。 每次迭代，都要充分接收用户的评审意见，以便为自我纠正。渐近式的功能交付，有利 于降低开发人员的压力，增加用户的满意度，有利于增强项目的可见性，是最好的进展 报告。 (2) 技术评审 技术评审是确保软件质量的重要环节，技术评审包括代码走查、会议评审和同行专家评 审。代码走审可以是开发人员之间的交叉审查，或者是高级开发人员对普通开发人员的 审查；会议评审一般应至少每两周进行一次，每次评审时间不宜太长；同行专家评审包 括技术和业务两个方面的专家，经常性地让精通业务的用户专家参与项目评审，是项目 成功的重要保证。 另外，充分利用质量审查的工具软件，也有利于提高代码质量。例如：在 Ec