软件工程管理问题

导语：软件工程管理问题一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

1时美国国防部曾立题专II研究软件项日做不好的原因，发现70%的项日是因为管理不善引起的，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。这个结论仆常重要。到了90年代中期，软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。针对软件项目管理不善的局而，我简要谈谈石二软件项目管理中存在的一些问题。1客户干不份要全程参与不少软件企业认为客户的参与主要在二件事情上:协议签订和需求调研、客户需求变更和项目验收签字，其它事情足企业内部项日开发管理的事情，属公司内部行为，无需客户参与。

结果，企业经常发现客户严重拖延验收，而Il在验收期间客户大量的需求变史，致使项目的进展严重推迟。经常一个预期益利的项}」，最后拖的不堪重负口我认为这里边的一个重要原因就是客户没有参与项目的全过程。比方，项目初期的启动会议、项日过程中所有干系人的知情制度，每周的工作例会、项日阶段性工作总结等等都需要客户的参与和反馈。否则当企业年之后提交一个无比庞人和复杂的最终方案时，客户方根本不了解你的方案的进程，由谁敢签字验收昵?客户只能花I几儿个月来完全“肢解”消化整个方案，最终当然是发现大堆问题需要改进，企业只能再花上几个月重新修改，如此往而复始，恶性循环。

2如果份求分析很困难，可不可以先做软件对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，修改越晚代价越人，就跟治病一样道理。一是在项日的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即.IJ,具体细节可以在以后填充。软件过程改善是一个持续改善的过程，需要不断地学习，需要知识的积累，特别是当主客观环境发生变化时，需要对过程进行修改，以适应变化了的情况。无论多么细致的需求分析，儿乎都难以避免修改。实际上许多软件项日失败的最l要的原因就是需求阶段对问题的描述不够细致，导致后来顶算超出或者时间进度达不到要求。这就要求在项H需求分析阶段，开发方与客户方必须个面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并民，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽早地对需求变动问题进行沟通。

3软件项目份求的改变容易实现吗在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一此需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变，而且这此改变可很容易地被实现”。实践表明，随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改需要花费1倍的代价;那么，在系统设计和编码阶段，需要花费1.5-6倍的代价;在系统测试阶段需要花费10-20倍的代价;在软件版本以后，甚至可能要花费60-100倍的代价。由此可见，在项日开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少，容易被实现。

4项目的质f提高是否要依救完普的质fm试制度不少企业把软件的测试工作定位于提高软件开发项目的质量。我认为质量测试制度只是」个补救措施，是来挑出各种因素造成的缺陷，但不能避免新的缺陷的出现。真正有效的质量管理是建立在一套质量保证体系l几的全过程质量管理方案，每一个环节的规范化管理是质量保证的一个基础，除此之外，规范的项目方案评审制度也是质量保证的必备步骤，经常客户对质量的评价首先是方案质量的优劣。有效的、科学的测试制度也将有助于在提交客户之前发现设计中的问题。

5所有的内部洲试工作是不是全部应该由洲试人员完成软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“自盒法”对测试人员各方面素质的种种要求，在进行程序测试时测试人员总是最优先使用“黑盒法”。他们的上作方式往往是先对程序进行“黑盒法”测试;如果测试没有通过，不得已这才考虑对程序代码进行“自盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。如何解决这个问题?一方面需要提高对测试人员的要求，另一方向也需要程序员完成部分的“白盒法”测试。

6如果我们落后于计划，是否可以增加更多的程序员来解决客观情况是软件开发不同J二传统的农业生产，人多不见得力量大。如果给落后于计划的项日增添新手，可能会更加延误项日。因为:

1)新手会产生很多新的错误，使项目混乱。

2)老手向新手解释上作以及交流思想都要花费时间，使实际开发时间更少。所以科学的项I-I计划很重要，不在乎计划能提前多少，重在恰如其分。如果用“”的方式奔向共产卞义，只会产生倒退的后果。投入项目上的人力，多多益善。在某些业务项日卜确实如此。但在系统项目管理中却很少是这样的。人们的技能和知识是不能互换的。如果多一些人加入到系统项目中来，由于协调不利和要培训人员以快速适应丁:作，通常会减慢项日的进度。

7技术骨千是否应该成为项目的项目经理项目经理一定是所有项目成员中薪水最高的。在“软件作坊”时代，这是一种普遍使用而目.效果不错的方法;而在“软件”时代，这种方法却带来各种问题，有时甚至直接导致项日失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变—最注重的不是其对某项专业技术的掌握程度，而是其组织、领导、协调开发团队的能力。至于项目经理的薪水问题，这和定薪制度有很大关系。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不-定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。