软件工程作业4

一、为什么软件工程开发周期总是预估的2-3倍

看完Micheal Wolfe有趣的回答，总结下来就是在软件开发过程总会天有不测风云，冷不丁的就会发生什么意外。接下来总结了几个影响进度的原因。

1、80-20原则与过于乐观的进度控制

　　80-20原则在软件开发项目进度控制方面体现在：80%的项目工作可以在20%的时间内完成，而剩余的20%的项目工作需要80%的时间。这个80%的项目工作不一定是在项目的前期，而可能是分布在项目的各个阶段，但是剩余的20%左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉，使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。

2、范围、质量因素对进度的影响

　软件开发项目比其他任何建设项目都会有更经常的变更，大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧，用户是想改就改，造成需求的蔓延，项目经理有时还不知如何拒绝，加上要说“我能”的心理因素，一般都会答应修改。这样集少成多，逐渐影响了项目进度。

3、资源、预算变更对进度的影响

　　资源，最主要的还是人力资源，有时某方面的人员不够到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。还有一个很重要的资源，就是信息资源，如某些国家标准、行业标准，用户可能提供不了，而是需要去收集或购买，如果不能按时得到，就会影响需求分析、设计或编码的工作。其他资源，如开发设备或软件没有到货，也会对进度造成影响。

4、低估了软件开发项目实现的条件

　　低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。

5、项目状态信息收集的情况

　　由于项目经理的经验或素质原因，对项目状态信息收集的的掌握不足，及时性准确性完整性比较差。另外其它一些原因也会造成这种现象。

6、执行计划的严格程度

　　没有把计划作为项目过程行动的基础，而是把计划放在一边，比较随意去做。例如对于项目团队内部沟通或外部沟通，在计划中要说明清楚人员、周期、方式、方法，不能遗漏，但在实际项目过程中，可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。

7、计划变更调整的及时性

　　渐近明细是项目的特点，特别是对于软件开发项目，并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些，随着项目的进展，特别是需求明确以后，项目的计划就可以进一步的明确，这时候应该对项目计划进行调整修订，通过变更手续取得项目干系人的共识。计划应该随着项目的进展而逐渐细化、调整、修正。没有及时调整的计划或者是随意的不负责任的计划的项目是难以控制的。

8、未考虑不可预见事件发生造成的影响

　　假设、约束、风险等考虑“不周”造成项目进度计划中未考虑一些不可预见的事件发生。

9、程序员方面的因素对进度的影响

　　程序员方面有两种常见的心态影响了进度的控制：一是技术完美主义、二是自尊心。

10、未考虑软件开发过程的循环、迭代特性

　　对软件开发的各个过程分类过于精细，制定进度计划时各项工作过于紧凑、没有弹性，造成的后果是，定期提交项目进度阶段报告的制度只有在表面上起到效果，按照计划的时间表提交阶段成果也只是在表面上起到效果。

　11、其他因素

　　以上这些因素是影响项目进度的几个主要方面，除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素，这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等，都会对项目进度造成影响，这是因为由于软件开发的特性。

二、什么是分而治之

       所谓“分而治之” 就是把一个复杂的算法问题按一定的“分解”方法分为等价的规模较小的若干部分，然后逐个解决，分别找出各部分的解，把各部分的解组成整个问题的解，这种朴素的思想来源于人们生活与工作的经验，也完全适合于技术领域。在软件工程中也是如此，一个项目千头万绪，要一下完成很难，所以我们要把一个项目拆分成若干个需求，每一次只干其中的一件事，然后一件一件的完成。

三、了解WBS

     工作分解结构（简称WBS）跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。即：项目→任务→工作→日常活动。

     工作分解结构以可交付成果为导向，对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。