软件工程课件作者张海藩1_第7章节.pptVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
图7.6 主程序员组的结构 一个典型的主程序员组如图7.6所示。该组由主程序员、后备程序员、编程秘书以及1~3名程序员组成。在必要的时候,该组还有其他领域的专家(例如,法律专家,财务专家等)协助。 7.4.3 现代程序员组 民主制程序员组的最大优点,是组员们都对发现程序错误持积极、主动的态度。主程序员组的组织方式与民主制程序员组很不相同,主程序员对每行代码的质量负责,必须参与全部代码审查工作,但是,主程序员同时又是负责对小组成员进行评价的管理员,他参与代码审查工作自然会把所发现的程序错误与小组成员的工作业绩联系起来,从而造成小组成员不愿意发现错误的心理。 图7.7 现代程序员组 ? 摆脱上述矛盾的方法是,取消主程序员的大部分行政管理工作。上一小节已经指出,很难找到一个既是高度熟练的程序员又是成功的管理员的人,取消主程序员的行政管理工作,不仅可消除组员不愿意发现错误的心理障碍,也使得寻找主程序员的人选不再那么困难。于是,实际的“主程序员”应该由两个人共同担任:一个技术负责人,负责小组的技术活动;一个行政负责人,负责所有非技术的管理决策。这样的组织结构如图7.7所示。 图7.7 现代程序员组 图7.8 大型项目的技术管理组织结构 ? 由于程序员组的人数不宜过多,当软件项目规模较大时,应该把程序员分成若干个小组,采用图7.8所示的组织结构。该图描绘的是技术管理组织的结构,非技术管理组织的结构与此类似。由图可以看出,产品作为一个整体其开发工作是在项目经理的指导下进行的,程序员向他们的组长汇报工作,而组长向项目经理汇报工作。当产品规模更大时,可以再增加中间管理层次。 图7.9 包含分散决策的组织方式 ? 把民主制程序员组和主程序员组的优点结合起来的另一种方法,是在合适的地方采用分散做决定的方法,如图7.9所示。这样做有利于形成畅通的通信渠道,以便充分发挥每个程序员的积极性和主动性,集思广益攻克技术难关。这种组织方式对于适合采用民主方法的那类问题(例如,研究性项目或遇到技术难题需要用集体智慧攻关)非常有效。尽管这种组织方式适当地发扬了民主,但是上下级之间的箭头(即管理关系)仍然是向下的,也就是说,是在集中指导下发扬民主。显然,如果程序员可以指挥项目经理,则只会引起混乱。 项目管理者的目标是定义全部项目任务,识别出关键任务,跟踪关键任务的进展状况,以保证能及时发现拖延进度的情况。为了做到这一点,管理者必须制定一个足够详细的进度表,以便监督项目进度,并控制整个项目。 软件项目的进度安排是一项活动,它通过把工作量分配给特定的软件工程任务,并规定完成各项任务的起、止日期,从而将估算的工作量分布于计划好的项目持续期内。进度计划将随着时间的流逝而不断演化。在项目计划的早期,首先制定一个宏观的进度安排表,标识出主要的软件工程活动和这些活动影响到的产品功能。随着项目的进展,把宏观进度表中的每个条目都精化成一个详细进度表。于是完成一个活动所必须实现的特定任务被标识出来,并安排好了实现这些任务的进度。 7.3.1 估算开发时间 通常,成本估计模型也同时为我们提供估算开发时间T的方程。与工作量方程不同,各种模型估算开发时间的方程非常类似,如下所示: (1)Walston-Felix模型 T=2.5E 0.35 (2)原始COCOMO模型 T=2.5E 0.38 (3)COCOMO 2模型 T=3.0E 0.33+0.2×(b-1.01) (4)Putnam模型 T=2.4E1/3 其中, E为开发工作量(以人月为单位), T为开发时间(以月为单位)。 用上列方程计算出的T值,代表正常开发时间。客户往往希望缩短软件的开发时间,显然,为了缩短开发时间应该增加从事开发工作的人数。 但是,经验告诉我们,随着开发小组规模增大,个人的生产率将下降。出现这种现象主要有下述两个原因: ● 当小组变得更大时,每个人需要用更多时间与组内其他成员讨论问题、协调工作,因此,通信开销增加了。 ● 如果在开发过程中增加小组人员,则最初一段时间内项目组总生产率不仅不会提高反而会下降。这是因为开始时新成员还不是生产力,而且在他们学习期间还需要花费小组其他成员的时间。 综合上述两个原因,存在被称为Brooks规律的下述现象:向一个已经延期的项目增加人力,只会使得它更加延期。 事实上,做任何事情都需要时间。我们不可能用“人力换时间”的办法无限制地缩短一个软件项目的开发时间。Boehm根据经验指出,软件项目开发时间最多可以减少至正常开发时间的75%。如果试图把开发时间压缩得太短,

您可能关注的文档

文档评论(0)

118压缩包课件库 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档