谈某的项目中的问题与解决的方案.docVIP

PAGE PAGE 8浅谈某项目中的问题与解决方案 袁志军 2007/07/24 [摘要] 当前，在整个软件行业的激烈竞争下，项目的成败将关系到软件企业的生存与发展，项目需要建立在自我不断创新和高质量满足客户要求的基础上。建立这种基础的前提就是要具备很强的对“需求、问题或机会”的识别能力以及提出相应解决方案的能力。因此如何随时识别项目中各项风险和问题，对整个项目的实施过程中的风险进行预测，进而对各种风险进行跟踪预防、规避，转为问题后妥善的解决这些问题，成为项目成败的关键。选择适当的软件开发模型能清晰、直观地表达软件开发全过程，明确规定要完成的主要活动和任务，用来作为软件项目工作的基础。我们公司很多的项目都选用瀑布模型，瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节，其特点是每个阶段有明确的开始和结束点,一个阶段的输出为下一阶段的输入条件。它很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中用户很难参与进去，只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程缺乏灵活性，不适应实际的开发过程。我们所使用的实际上是渐增模型。渐增模型是在瀑布模型基础上加以改进而来的增量模型。它是以瀑布模型为基础，按功能增量方式进行增量开发 。[项目背景]某项目是个WEB系项目的典型：工期紧，开发人员能力弱的项目。项目生命周期为渐增模型。项目过程阶段为项目启动阶段、式样理解、编码Coding、Debug）、UT、画面集成、系统验收及维护、项目结束。项目要求2006年12月24日上线，为保证上线前ITF公司的结合测试和系统测试，我们必须于12月10日完成UT和初步的结合测试交货。由于时间仓促，式样设计没有完整的基本设计，详细设计预计于10月30日给我们未经Review的初版，11月10日给出经过Review的版本。项目规模：25人月。项目的各个阶段都有一些不同的问题存在，对其进行分析并提出解决方案，希望能为以后的项目提供帮助。一．项目前期：它包括建立项目组织、对项目进行估算、制订相关的计划、系统可行性调查分析、营业上的沟通、技术上的学习培训等准备工作。典型的工作产品：项目任务书，项目工程计划报告书。也就是用分阶段的生命周期计划严格管理。这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把 HYPERLINK /phrase/200603061230195.html \t _new 软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。为了更好的控制好项目，某项目导入CMMI,它很好的规范和定义好了软件开发和管理的过程，为项目的成功提供了在作计划是往往会碰到：1．没有完整的基本设计或详细设计；2．人力不足； 3.人员能力弱 等问题；由于这些问题的存在，想要完全按照瀑布模型来实施就会很困难；在某项目中式样设计由于时间仓促，没有完整的基本设计，详细设计预计于10月30日给我们未经Review的初版，到11月10日给出经过Review的版本。没有完整的基本设计式样理解就不完全，式样理解阶段就没结束，而瀑布模型规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节，所以编码开发就不能完全进行。如果等到式样理解完全结束在进入开发的话，就会增加开发、测试的风险—时间不够；因此采取了渐增的方式：开发从11/1日开始，11/1日～11/10日安排对新人的培训，根据一期的经验和能确定的稳定的式样先进性部分画面的开发，开发完毕后进入测试阶段；11月10日拿到经过Review的式样版本，～11/10进行式样理解，11/13日开始未开发的画面，开发完毕后进行测试； 设计设计开发式样理解测试设计开发式样理解测试时间进度符合使用渐增模型的开发模式。这样既能完成一部分页面的开发测试，同时新人在10天的培训中能力得到了提升，为后面页面的开发提供了保障。1.1式样不足：先找稳定的部分进行或和客户商讨找出相对稳定的模块先着手，把计划排在前面，不稳定的排在后面；先推动项目，去发现存在的问题，并且进行理解和讨论，不产生Rework的工作都可以安排先做起来，比如培训预算等；和客户确定接受物的日程，清楚什么时候能够拿到达成公式的稳定的资料；设定假定的条件，在假设的基础上的进行评估，如果假设变了，在重新评估；通过各种方法，尽可能促成假定条件得到满足。 1.2人力不足：开发只有参与过10月版的开发人员7名（含一名PJL），测试2名，另外一名PM，根据10月版开发的经验，当时的人力缺少开发5名（其中