四种团队开发范型电子教案.docVIP

四种团队开发范型 精品文档 精品文档 收集于网络，如有侵权请联系管理员删除 收集于网络，如有侵权请联系管理员删除 精品文档 收集于网络，如有侵权请联系管理员删除 3.2.3软件项目组? 　　软件开发的组织结构几乎与开发软件的组织一样多。不管怎么说，组织结构不能轻易改变。关心组织改变所产生的实际的及政策上的影响，并不是软件项目管理者的责任范围。但是，在一个新的软件项目中直接涉及到的人员的组织，则是项目管理者的职责。 　　下面给出为一个项目分配人力资源的若干可选方案，该项目需要n个人工作k年n个人被分配来完成m个不同的功能任务，相对而言几乎没有合作的情况发生；协调是软件管理者的责任，而他可能同时还有六个其他项目要管。 　　2.n个人被分配来完成m个不同的功能任务(m＜n)，建立非正式的“小组”；指定一个专门的小组负责人；小组之间的协调由软件管理者负责。 　　3.n个人被分成t个小组；每一个小组完成一个或多个功能任务；每一个小组有一个特定的结构，该结构是为同一个项目的所有小组定义的；协调工作由小组和软件项目管理者共同控制。 　　虽然对于上述的每一种方法都可以找到其优点和缺点，但越来越多的证据表明正式的组织小组(策3种方法)是生产率最高的。 　　“最好的”小组结构取决于组织的管理风格、组里的人员数目及他们的技术水平和整个问题的难易程度。Mantei［MAN81］提出了三种一般的小组组织方式 　　民主分权式(Democratic Decentralized，DD)：这种软件工程小组没有固定的负责人。“任务协调者是短期指定的，之后就由其他协调不同任务的人取代”。问题和解决方法的确定是由小组讨论决策的。小组成员间的通信是平行的。 　　控制分权式(Controlled? Decentralized，CD)：这种软件工程小组有一个固定的负责人，他协调特定的任务及负责子任务的二级负责人关系。问题解决仍是一个群体活动，但解决方案的实现是由小组负责人在子组之间进行划分的。子组和个人间的通信是平行的，但也会发生沿着控制层产生的上下级的通信。 　　控制集权式(Controlled Centralized，CC)：顶层的问题解决和内部小组协调是由小组负责人管理的。负责人和小组成员之间的通信是上下级式的。 　　Mantei还给出了计划软件工程小组的结构时应该考虑的七个项目因素 　　·待解决问题的困难程度。 　　·要产生的程序的规模，以代码行或者功能点来衡量。 　　·小组成员需要待在一起的时间(小组生命期)。 　　·问题能够被模块化的程度。 　　·待建造系统所要求的质量和可靠性。 　　·交付日期的严格程度。 　　·项目所需要的社交性(通信)的程度。 　　表3－1［MAN81］总结了项目特性对小组组织的影响。因为集中式的结构能够更快地完成任务，因此最适合处理简单问题。而分散式的小组比起个人而言能够产生更多更好的解决方案，因此，这种小组在处理复杂问题时成功的可能性更大。因为CD小组是集中式地解决问题，所以CD或CC小组结构能够成功地用来解决简单的问题。而DD结构则适于解决难度较大的问题。 　　因为小组的性能与必须进行的通信量成反比，所以很大的项目最好采用CC或CD结构的小组组织方式，如果子组能够很容易地协调的话。 　　小组“在一起”的时间的长短影响小组的士气。我们发现DD小组结构能够产生较高的士气和工作满意度，因此适合生命期较长的小组。 　　DD小组结构最适于解决模块化程度较低的问题，因为它需要更多的通信。如果有可能要较高的模块化程度(这时人们自己做自己的事情)，则CC或CD结构更加合适。 　　CC和CD小组已被发现能够产生比DD小组更少的缺陷，但这与小组所采用的质量保证活动密切相关。分散式结构通常需要比集中式结构更多的时间来完成一个项目，但如果要求高社交性，它是最适合的。 　　Constantine［CON93］提出了软件工程小组的四种“组织范型”封闭式范型：按照传统的权利层次来组织小组(类似CC小组)。这种小组在开发与过去已经做过的产品类似的软件时十分有效，但在这种封闭式范型下难以进行创新式的工作。 　　2.随机式范型：松散地组织小组，并依赖于小组成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的小组很有优势。但当需要“有次序的执行”才能完成工作时，这种小组组织范型就会陷入困境。 　　3.开放式范型：试图以一种，既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织小组。工作的执行结合了大量的通信和基于小组一致意见的决策。开放式范型小组结构特别适于解决复杂问题，但可能不象其他类型小组那么效率高。 　　4.同步式范型：依赖于问题的自然划分，组织小组成员各自解决问题的片断，他们