Pressman ch3 项目管理的概念ppt课件

1、软件工程第二部分 管理软件工程 .第二部分 管理软件工程 这一部分主要思索方案、组织、监控和控制软件工程所需求的管理技术。将获得以下问题的回答：* 在一个软件工程中为什么必需管理人员、问题和过程？* 什么是软件度量？如何运用它们管理软件工程和软件过程？* 一个软件工程组如何对任务量、本钱和工程时间进展可靠的估算？* 采用什么技术去正式地评价影响工程胜利的风险？ .第二部分 管理软件工程 * 一个软件工程管理者如何选择软件工程任务义务集？* 如何创建一个工程进度方案？* 如何定义质量使其可以被控制？* 什么是软件质量保证？ * 为什么正式的技术复审那么重要？* 在计算机软件开发之中及它被交付给客

2、户之后如何进展变化管理？ .第三章 工程管理：概念 要点阅读概念：在建造基于计算机的系统和产品时“管理依然是一个非常必要的活动。工程管理涉及人员、过程和当软件从初始的概念演化为可运转的实现的过程中发生的事件的方案、监控和控制。人员：每个人均在某种范围内“管理，但是，管理活动的范围根据参与管理的人员而变化。软件工程师管理他的日常活动，方案、监控和控制技术义务。工程管理者方案、监控、和控制软件工程师队伍的任务。高级管理者协调业务和软件专业人员间的接口。 .第三章 工程管理：概念 为什么重要：建造计算机软件是一项复杂的义务，特别当它涉及很多人员在一个相当长的时期内共同任务时。步骤：了解4P人员Peo

3、ple、产品Product、过程Process和工程Project。人员必需被组织以有效地完成软件任务；必需和客户通讯以了解产品范围和需求；适宜于人员和产品的过程必需被选择；工程必需被经过估算任务量和完成任务义务的日程而方案：定义任务产品、建立质量检查点、以及建立监控和控制该方案所定义的任务的机制。 .第三章 工程管理：概念 产品：当管理活动开场，必需建立工程方案。该方案定义将被进展的过程和义务，将完成任务的人员，以及评价风险、控制变化和评价质量的机制。保证措施：在他按时并按预算交付高质量产品之前，他永远不能完全一定工程方案是正确的。然而，工程管理者正确地完成任务，假设他鼓励软件人员一同任务以

4、构成一支有效的队伍，并将他们的留意力聚焦到客户需求和产质量量上。 .第三章 工程管理：概念Meiler Jones给出了一段被许多软件工程顾问呼应的陈说：我访问了很多商业公司，好的和不好的，我又察看了很多数据处置的管理者，好的和不好的。经常地，我恐惧地看到这些管理者徒劳地与恶梦般的工程斗争，在根本不能够完成的最后期限下苦苦挣扎，或是交付了使其用户极为不满的系统，而后又继续破费大量的维护时间。 .Jones所描画的正是源于一系列管理和技术问题而产生的病症。一致的问题：工程管理太弱。将讨论进展有效的软件工程管理的关键概念。本章主要给出了根本的软件工程管理的概念和原那么。第4章论述了过程和工程度量，

5、这是进展有效的管理决策的根底。第5章讨论了用于估算本钱和资源需求并建立有效的工程方案的技术。第6章给出了进展有效的风险监控、缓解和管理的管理活动。第7章讨论了定义工程义务并建立一个可操作的工程进度方案所需的活动。第8章和第9章讨论了在工程开发过程中保证质量及在运用的整个生命期中控制变化所需的技术。 .3.1管理的范围 有效的工程管理集中于四个P上：人员people、产品product、过程process和工程project。其顺序不是恣意的。任何管理者假设忘记了软件工程是人的智力密集的劳动，他就永远不能够在工程管理上得到胜利；任何管理者假设在工程开发早期没有鼓励全面的客户通讯，他有能够为错误的

6、问题建造一个不错的处理方案。对过程不在意的管理者能够冒把有效的技术方法和工具插入到真空中的风险。没有一个可靠的工程方案就开场任务的管理者将危及产品的胜利。 .3.1管理的范围 3.1.1人员 “人的要素是如此重要，以致于软件工程研讨所专门开发了一个人员管理才干成熟度模型PMCMM，旨在“加强软件组织承当日益复杂的运用的才干，经过协助吸引、培育、鼓励、部署和留住改善其软件开发才干所需的人才 .3.1.1人员 人员管理成熟度模型为软件人员定义了以下的关键实际区域：招募、选择、业绩管理、培训、报酬、业开展、组织和任务设计、以及团队精神/企业文化培育。在人员管理上到达较高成熟度的组织更有能够实现有效的

7、软件工程实际。 PMCMM与软件才干成熟度模型第2章相配合，后者指点组织创建一个成熟的软件过程。 .3.1.2 产品(1)在进展工程方案之前，应该首先建立产品目的和范围，思索可选的处理方案，标识技术和管理的约束。没有这些信息，就不能够进展合理的准确的本钱估算；有效的风险评价；适当的工程义务划分；或是可管理的工程进度安排，其中给出了意义明确的工程进展的标志。 .3.1.2 产品(2)软件开发者和客户必需一同定义产品的目的和范围。在很多情况下，这项活动是作为系统工程或业务过程工程的一部分开场的，继续到作为软件需求分析的第一步。目的是标识出该产品的总体目的从客户的角度，而不思索这些目的如何实现。范围

8、标识出与产品相关的主要数据、功能和行为，更为重要的是，它以量化的方式约束了这些特性。 .3.1.2 产品(3)一旦了解了产品的目的和范围，就要开场思索备选的处理方案了。虽然这一步并不讨论细节，但它使得管理者和实际者可以选择一条“最好的途径，该选择是根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其它要素所构成的约束。 .3.1.3 过程软件过程提供了一个框架，在该框架下可以建立一个软件开发的全面方案。少量的框架活动可运用于一切软件工程，不思索其规模和复杂性。假设干不同的义务集合每一个集合都由义务、里程碑、任务产品以及质量保证点组成使得框架活动能被修正以顺应于不同软件工程的特征和工程组

9、的需求。最后是庇护性活动如软件质量保证、软件配置管理、和测度它们覆盖了过程模型。庇护性活动独立于任何一个框架活动，且贯穿于整个过程。 .3.1.4 工程进展方案好的和控制的软件工程的一个主要理由是这是独一知道的管理复杂性的方式。1998年，产业数听阐明26的软件工程彻底失败，而46的工程阅历了本钱和进度超出预算。为了防止工程失败，软件工程的管理者和建造产品的工程师必需防止一些常见的警告信号，了解关键的导致好的工程管理的胜利要素，并开发方案、监控和控制工程的常识性方法。 .3.2 人员 (1)在IEEE发表的一项研讨中，三个大型的技术公司的主管工程的副总裁被问到一个胜利软件工程中最重要的要素是什

10、么。他们的回答如下：第一位：我想假设必需在我们的环境中挑出一项最重要的要素，我必需成认它不是我们所用的工具，而是人。 .3.2 人员 (2)第二位：一个工程胜利的最重要的要素是有聪明的人我想不出其它的要素他为一个工程所做的最重要的事情是选择人员软件开发组织的胜利与其招募优秀人才的才干亲密相关。第三位：我在管理上独一的准那么是保证我有优秀的人员真正优秀的人员同时我也培育优秀的人员我提供培育优秀人员的良好环境。 .3.2 人员 (3)这是对软件工程过程中人的重要性的强有力的证明。不过，我们一切的人，从高级工程副总裁到低级的开发人员，经常以为人员是不成问题的。管理者表态说人员是主要的，但他们的行为有

11、时与说话不符。本节我们讨论参与软件过程的人员，以及如何组织他们实现有效的软件工程的方式。 .3.2.1 工程参与者 参与软件过程及每一个软件工程的人员可以分为以下五类：1 高级管理者：担任定义业务问题，这些问题往往对工程产生很大影响。2 工程技术管理者：必需方案、鼓励、组织和控制软件开发人员。3 开发人员：担任开发一个产品或运用所需的专门技术。4 客户：担任阐明待开发软件的需求。 .3.2.1 工程参与者 5 最终用户：一旦软件发布成为产品，最终用户是直接与软件进展交互的人。每一个软件工程都有上述的人员参与。为了到达有效，工程组的组织必需最大限制地发扬每个人的技术和才干。这是工程担任人的义务。

12、 .3.2.2 工程担任人 (1)工程管理是集中于人的活动，因此，胜任的开发人员经常是拙劣的工程担任人。他们完全不具备管理人应有的技艺。如Edgemon所说：“很不幸而且是很经常地，似乎人们碰巧落在工程管理者的位置上，也就不测地成为了工程管理者。在一本关于技术指点才干的优秀论著中，Jerry Weinberg提出了指点才干的MOI模型： .3.2.2 工程担任人 (2)鼓励Motivation：鼓励技术人员发扬其最大才干的一种才干。组织Organization：建模已有的过程的一种才干，以使得最初的概念可以转换成最终的产品。想法Ideas或创新Innovation：鼓励人们去发明并感到有发明性

13、的一种才干，即使他们其实必需在为特定软件产品或运用建立的约束下进展任务。 .3.2.2 工程担任人 (3)Weinberg提出：胜利的工程担任人应采用一种处理问题的管理风格，即，软件工程经理应该集中于了解待处理的问题，管理新想法的交流，同时，让工程组的每一个人知道质量很重要，不能妥协。关于一个有效的工程经理应该具有什么特点的另一个观念那么强调了以下四个关键质量： .3.2.2 工程担任人 (4)处理问题：一个有效的软件工程经理应该可以准确地诊断出技术的和管理的问题；系统地方案处理方案；适当地鼓励其它开发人员实现处理方案；把从以前的工程中学到的阅历运用到新的环境下；假设最初的处理方案没有结果，可

14、以灵敏地改动方向。管理者的特性：一个好的工程经理必需掌管整个工程。他在必要时必需有自信心进展控制，必需保证让优秀的技术人员可以按照他们的本性行事。 .3.2.2 工程担任人(5)成就：为了提高工程组的消费率，工程经理必需奖励具有自动性和作出成果的人。并经过本人的行为阐明控制下的冒险不会遭到惩罚。影响和队伍建立：一个有效的工程经理必需可以“读懂人；他必需可以了解言语的和非言语的信号，并对发出这些信号的人的要求作出反响。工程经理必需在高压力的环境下坚持可控形状。 .3.2.3软件工程组 (1)软件开发的人员组织构造几乎与开发软件的组织一样多。不论怎样说，组织构造不能随便改动。关怀组织改动所产生的实

15、践的及政策上的后果并不是软件工程管理者的责任范围。但是，在一个新的软件工程中直接涉及到的人员的组织那么是工程管理者的权限。QUOTE：并非每个小组都是开发队伍，并非每个开发队伍都是有效的。 .3.2.3软件工程组 (2)下面给出假设干可选方案，为一个工程分配人力资源，该工程需求n个人任务k年：1 n个人被分配到m个不同的功能义务，相对而言几乎没有协作的情况发生；协调是软件管理者的责任，而他能够同时还有六个其它工程要管。2 n个人被分配到m个不同的功能义务mn，这样要建立非正式的“小组；需指定专门的小组担任人；小组之间的协调由软件管理者担任。 .3.2.3软件工程组 (3)3 n个人被分成t个小

16、组；每一个小组分配一个或多个功能义务；每一个小组有一个特定的构造，该构造是为同一个工程的一切小组定义的；协调由小组和软件工程管理者共同控制。虽然对于上述的每一种方法都可以找到其优点和缺陷，但越来越多的证听阐明正式的小组组织第3种方法是消费率最高的。 .3.2.3软件工程组(4)“最好的小组构造是取决于组织的管理风格、组里的人员数目及他们的技术程度、和整个问题的困难程度。Mantei提出了三种普通的小组组织方式：民主分权式Democratic Decentralized，DD：这种软件工程小组没有固定的担任人。“义务协调者是短期指定的，之后就由其它协调不同义务的人取代。问题和处理方法确实定是由小

17、组讨论决策的。小组成员间的通讯是程度的。 .3.2.3软件工程组(5)控制分权式Controlled Decentralized，CD：这种软件工程小组有一个固定的担任人，他协调特定的义务及担任子义务的二级担任人。问题处理仍是一个群体活动，但处理方案的实现是由小组担任人在子组之间进展划分的。子组和个人间的通讯是程度的，但也会发生沿着控制层次产生的垂直通讯。控制集权式Controlled Centralized，CC：顶层的问题处理和内部小组协调是由小组担任人管理的。担任人和小组成员之间的通讯是垂直的。 .3.2.3软件工程组(6)Mantei还给出了方案软件工程小组的构造时应该思索的七个工程要

18、素：* 待处理问题的困难程度。* 产生的程序的规模，以代码行或者功能点来衡量。* 小组成员需求待在一同的时间小组生命期。* 问题可以被模块化的程度。 .3.2.3软件工程组(7)* 待建造系统所要求的质量和可靠性。* 交付日期的严厉程度。* 工程所需求的社交性通讯的程度。？：当组织软件队伍时，我们应该思索什么要素？ .3.2.3软件工程组(8)由于集中式的构造可以更快地完成义务，因此最适宜处置简单问题。而分散式的小组比起个人而言可以产生更多更好的处理方案，因此，这种小组在处置复杂问题时胜利的能够性更大。由于CD小组是集中式地处理问题，所以CD或CC小组构造可以胜利地运用于简单的问题。而DD构造

19、那么适于处理困难的问题。由于小组的表现与必需进展的通讯量成反比，所以很大的工程最好采用CC或CD构造的小组，假设子组划分是可以很容易地进展的话。 .3.2.3软件工程组(9)小组“在一同的时间长短影响小组的士气。发现DD小组构造可以产生较高的士气和任务称心度，因此适宜生命期较长的小组。ADVICE：一个经常的情形是：一组小的、重点明确的小组比一个单个的大队伍要好。.3.2.3软件工程组(10)DD小组构造最适于处理模块化程度较低的问题，由于它需求更多的通讯。假设有能够到达较高的模块化程度这时人们可以做他们本人的事情，那么CC或CD构造更加适宜。CC和CD小组已被发现可以产生比DD小组更少的缺陷

20、，但这些数据与小组所采用的特定的质量保证活动亲密相关。分散式构造通常需求比集中式构造更多的时间来完成一个工程，但假设要求高社交性，它是最适宜的。 .3.2.3软件工程组(11)Constantine提出了软件工程小组的四个“组织范型：1 封锁式范型：按照传统的权益层次来组织小组类似CC小组。这种小组在开发与过去曾经做过的产品相类似的软件时非常有效，但在这种封锁式范型下难以进展创新的任务。2 随机式范型：松散地组织小组，并依赖于小组成员个人的自动性。当需求创新或技术上的突破时，按照这种随机式范型组织的小组很有优势。但当需求“有次序的完成时，这种小组就会堕入姿态。 .3.2.3软件工程组(12)3

21、 开放式范型：试图以一种方式来组织小组，即具有封锁式范型的控制性，又包含随机式范型的创新性。任务的完成结合了大量的通讯和基于小组一致意见的决策。开放式范型小组构造特别适于处理复杂问题，但能够不象其它类型小组那么有效率。4 同步式范型：依赖于问题的自然划分，组织小组成员各自处理问题的片断，他们之间没有什么自动的通讯。 .3.2.3软件工程组(13)从历史角度看，最早的软件小组是控制集权式CC构造，原来称为主程序员小组。这种构造由Harlan Mills首先提出，并由Baker描画出来的。小组的中心是由以下人员组成的：一个高级工程师“主程序员，担任方案、协调和复审小组的一切技术活动；技术人员普通2

22、到5个人，执行分析和开发活动；及一个后备工程师，支持高级工程师的活动，并能在工程进展过程中以最小的代价取代高级工程师的任务。 .3.2.3软件工程组(14)主程序员可以由一个或多个专家如电讯专家，数据库设计者、支持人员如技术文档写作者，行政人员和软件资料员来配合。资料员为多个小组效力，完成以下功能：维护和控制一切软件配置即，文档，源程序，数据和磁介质；协助搜集和格式化软件消费率数据；分类和索引可复用软件构件；辅助小组进展研讨、评价及文档预备。资料员的重要性不能过分强调。资料员充任了软件配置的控制者、协调者及潜在的评价者。 .3.2.3软件工程组(15)Constantine提出了民主分权式小组

23、的一个变种，他主张具有创新独立性的小组，其任务的方式最好称之为“创新的无政府形状。虽然自在精神的软件任务方式是有吸引力的，但是，引入创新的能量到高性能的小组中必需是软件工程组织的一个中心目的。为了达成一个高性能的小组：* 小组成员必需互置信任。* 技艺的分布必需适宜于问题。* 闹独立的人员必需被排斥于小组之外，假设需求坚持小组凝聚力。 .3.2.3软件工程组(16)不思索小组的组织，每一个工程管理者的目的都是协助建立一个有凝聚力的小组。在其论著人件Peopleware中，DeMarco和Lister讨论了这个问题：我们在商业中往往是随意运用小组这个词，把任何被分配在一同任务的一组人都称为一个“

24、小组。但很多这样的组并不象小组。它没有一致的对于胜利的定义，没有任何可标识的团队精神。它们所短少的是一种很珍贵的东西，我们称之为凝聚力。 .3.2.3软件工程组(17)一个有凝聚力的小组是一组团结严密的人，他们的整膂力量大于个膂力量的总和一旦一个小组具有凝聚力，胜利的能够性就大大提高。这个小组可以变得不可阻挠，成为胜利的意味他们不需求按照传统的方式进展管理，也不需求去鼓励。他们曾经有了动力。 .3.2.3软件工程组(18)DeMarco和Lister以为有凝聚力小组的成员比起普通的小组而言具有更高的消费率和更大的动力。他们共享一个共同的目的、共同的文化，而且在很多情况下，“精英的觉得使得他们独

25、一无二。但是，并非一切小组均具有凝聚力，现实上，很多小组都受害于Jackman称为“小组毒性的东西。她定义了5个“培育潜在有毒的小组环境的要素： .3.2.3软件工程组(19)1. 一个狂乱的任务环境，在其中小组成员浪费能量并失去对将要完成的任务目的的关注。2. 导致小组成员间磨擦的个人、业务或技术要素所产生的高的挫败率。3. 变成完成义务的妨碍的“碎片式的或糟糕协调的规程或一个糟糕定义的或不适中选择的过程。4. 导致责任缺乏和指摘的不清楚的角色定义。5. 导致信息自信心缺乏和品德下降的“延续的和反复的失败。 .3.2.3软件工程组(20)Jackman提出了一组“抗毒素以对付这些常见问题。为

26、了防止狂乱的任务环境，工程管理者应该确保小组可访问完成任务所需的一切信息，以及主要的目的一旦定义，不到万不得已，不应该修正。此外，坏音讯不应该保守为，而是应该尽能够早的传送给小组当仍有时间以一种合理的和控制的方式作出反响时。 .3.2.3软件工程组(21)虽然挫败有很多缘由，但是，软件人员经常在他们短少权威去控制其情况时才觉得到。一个软件小组假设被给予了尽能够多的决策的责任，那么该小组可以防止挫败。给予小组的对过程和技术决策的控制越多，小组成员感遭到的挫败就越少。一个不适中选择的软件过程可以经过两种方式防止：(1) 确定将被建造的软件的特征符合所选择的过程的严厉性，以及(2) 允许小组去选择过

27、程。 .3.2.4协调和通讯问题 有很多缘由使软件工程堕入姿态。许多开发工程规模大，导致复杂性高、混乱、难以协调小组成员间的关系。不确定性是经常存在的，它会引起困扰工程组的一连串的改动。互操作性已成为许多系统的关键特性。新的软件必需与已有的软件通讯，并服从系统或产品所加诸的预定义约束。现代软件的这些特性规模、不确定性和互操作性都是现实的问题。为了有效地处置它们，软件工程小组必需建立有效的方法以协调参与任务的人。 .3.2.4协调和通讯问题 要完成这项义务，必需建立小组成员之间及多个小组之间的正式的和非正式的通讯机制。正式的通讯是经过“文字、会议及其它相对而言非交互的和非个人的通讯渠道来实现。非

28、正式的通讯那么更加个人化。软件工程小组的成员在一个特别的根底上共享其想法，出现问题时恳求协助，且每天相互交流。Kraul和Streeter调查了一系列的工程协调技术，并将其分为以下几类： .3.2.4协调和通讯问题 正式的、与人无关的方法：包括软件工程文档和交付物如源程序、技术备忘录、工程里程碑、进度和工程控制工具、改动恳求及相关文档、错误跟踪报告、和中心库数据。正式的、人员间的规程：集中于运用于软件工程任务产品的质量保证活动。包括形状复审会议及设计和代码检查。 .3.2.4协调和通讯问题非正式的、人员间的规程：包括信息传播、问题处理及“需求和开发人员配置的小组会议。电子通讯：包括电子邮件、电

29、子公告栏、Web站点以及基于视频的会议系统。人员间的网络：与工程组之外的人进展的非正式的讨论，这些人能够有阅历或见解，可以协助工程组成员。？：我们如何协调工程组成员间的动作？ .为了评价这些工程协调技术的效果，Kraul和Streeter调研了65个软件工程，其中包含上百个技术人员。图3.1KRA95中描画的变种阐明了上述协调技术的价值及运用。在图中给出了不同的协调和通讯技术的认知价值总分为7及它们在工程中的运用频率之间的关系。落在回归线之上的技术“被断定为，就给定的它们被运用的总量而言，相对而言价值较高。落在线之下的技术被以为价值较低。人员间网络被评为具有最高的协调和通讯价值的技术。早期的质

30、量保证机制需求和设计复审被以为比起后期的源代码评价代码检查更具价值。 .3.3产品 软件工程管理者从软件工程工程一开场就面临着进退两难的局面。需求定量的估算和有组织的方案，但却没有可靠的信息可以运用。对软件需求的详细分析可以提供必要的估算信息，但分析经常要花数周甚至数月的时间才干完成。需求能够是不固定的，随着工程的进展经常发生改动。不过，无论如何方案仍是“如今就需求的！ .3.3.1软件范围 软件工程管理的第一个活动是软件范围确实定。范围是经过回答以下问题来定义的：语境：待建造的软件如何顺应于大型的系统、产品或商业的语境，在该语境下要加什么约束？信息目的：软件要产生什么样的客户可见的数据对象作

31、为输出？需求什么样的数据对象作为输入？ .3.3.1软件范围 功能和性能：软件要执行什么样的功能使得输入数据变换成输出？需求满足任何特殊的性能特征吗？ADVICE：假设他不能把握他将建造的软件的某特征。将该特征作为一个专业的工程风险列出。 .3.3.1软件范围 软件工程范围在管理层和技术层都必需是无二义性的和可了解的。对软件范围的描画必需是界定的。即，明确给出定量的数据好像时用户的数目、邮件列表的大小、允许的最大呼应时间；阐明约束和/或局限如产品本钱限制内存大小；以及描画其它的缓解要素如，希望的算法可以被很好地了解并写成C+程序。 . 3.3.2问题分解 问题分解，有时称为划分或问题详细描画，

32、是一个软件需求分析的中心活动。在确定软件范围的活动中并不试图完全分解问题。而是将分解运用于两个主要方面：1必需交付的功能；2用于交付功能的过程。KEYPOINT：为了开发合理的工程方案，他必需功能地分界将被求解的问题。 .3.3.2问题分解 面对复杂的问题人类经常采用分而治之的战略。这是工程方案开场时所采用的战略。在估算开场之前，范围中所描画的软件功能必需被评价和精化以提供更多的细节。由于本钱和进度估算都是面向功能的，所以某种程度的分解通常是很有用的。.3.3.2问题分解 例如，思索我们要建造一个新的字处置产品的工程。该产品的独特功能包括：延续的语音输入和键盘输入；高级的“自动拷贝编辑功能；页

33、面规划功能；自动建立索引和目录；以及其它功能。工程管理者必需首先建立软件范围陈说，该陈说限定了这些特征以及其它的通用功能，如编辑、文件管理、文档生成等等。例如，延续语音输入功能能否需求用户进展专门的产品“训练？拷贝编辑特征提供了哪些才干？页面规划才干要到高级到什么程度？ .3.3.2问题分解 随着范围陈说的进展，自然产生了第一级划分。工程组研讨市场部与潜在客户的交谈并找出自动拷贝编辑应该具有以下功能：(1)拼写检查，(2)语句文法检查，(3)大型文档的参考书目关联检查，以及(4)大型文档中章节的参考书目关联确实认。这些特征的每一项都是软件要实现的子功能。同时，假设分解可以使方案更简单，那么每一

34、项又可以进一步精化。 .3.4过程 软件过程的普通性阶段定义、开发和维护适用于一切软件工程。问题在于选择一个适宜工程组要开发的软件的过程模型。多种软件工程范型：* 线性顺序模型* 原型模型* RAD模型* 增量模型* 螺旋模型.3.4过程 * WINWIN模型* 基于构件的开发模型* 并发开发模型* 方式化方法模型* 第四代技术模型ADVICE：一旦过程模型被选定，那么用可以产生高质量产品的最小的任务义务和任务产品集合来填充之，防止过程中的过度活动。 .3.4过程 工程管理者必需决议哪一个过程模型最适宜于：(1)需求该产品的客户和将做此任务的人员，(2)产品本身的特征，和(3)软件工程组任务的

35、工程环境。当一个过程模型被选定，工程组然后基于公共过程框架活动集合，定义一个初步的方案。一旦建立了初步的方案，便可以开场进展过程分解，即必需建立一个完好的方案，以反映框架活动中所需求的任务义务。.3.4.1合并产品和过程 工程方案开场于问题和过程的合并。软件工程组要开发的每一个功能都必需经过为软件组织定义的框架活动集合。假设组织采用了如下的框架活动集合：* 客户通讯建立开发者和客户之间有效需求诱导所需求的义务。* 方案定义资源、进度及其它相关工程信息所需求的义务。 .3.4.1合并产品和过程 * 风险分析评价技术的及管理的风险所需求的义务。* 工程engineering建立运用的一个或多个表示

36、所需求的义务。* 构造及发布构造、测试、安装和提供用户支持如，文档及培训所需求的义务。* 客户评价基于对在工程阶段产生的或在安装阶段实现的软件表示的评价，获取客户反响所需求的义务。 .3.4.1合并产品和过程 开发某产品功能的工程组成员都要将每一个框架活动运用于该功能的实现上。本质上，产生了一个类似图3.2所示的矩阵。每一个主要的问题功能被列在左手边的一列中。框架活动那么列在顶端的一行中。软件工程任务义务列在紧接着的行中。工程管理者和其它组员的任务是估算每一个矩阵单元的资源需求、与每一个单元相关的义务的开场和终了日期、以及每一个单元所产生的任务产品。 .图3-2.3.4.2过程分解 1软件工程

37、组在选择最适宜工程的软件工程范型、以及选定的过程模型中所包含的软件工程义务时，应该有很大的灵敏度。一个相对较小的工程假设与以前已开发过的工程类似，可以采用线性顺序模型。假设时间要求很紧且问题可以被很好地划分，RAD模型能够是正确的选择。假设时间太紧，不能够完成一切功能时，增量模型能够是最适宜的。类似地，具有其它特性如不确定的需求、突破性的技术、困难的客户、明显的复用潜力等的工程将导致选择其它过程模型。 .3.4.2过程分解 2一旦选定了过程模型，公共过程框架Common Process Framework，CPF应该顺应于它。在每一种情形，本章前面所讨论的CPF客户通讯，方案，风险分析，工程，

38、建造及发布，客户评价均可以被适宜于该范型。它可以适用于线性模型，还可适用于迭代和增量模型、演化模型、甚至是并发或构件组装模型。CPF是不变的，充任一个软件组织所执行的一切软件任务的根底。 .3.4.2过程分解 3ADVICE：总是运用CPF，而不论工程规模、关键性或类型。任务义务可以变化，但CPF不变。但实践的任务义务却是可变的。当工程管理者问到下面的问题时过程分解就开场了：“我们如何完成这个CPF活动？。例如，一个小型的、相对简单的工程在客户通讯活动中能够需求以下任务义务： .3.4.2过程分解41 列出需廓清问题的清单。2 与用户见面讨论需廓清的问题。3 共同给出范围陈说。4 和一切相关人

39、员一同复审范围陈说。5 根据需求修正范围陈说。 .3.4.2过程分解5这些事件能够在不到48小时的时间内发生。它们代表了适于小型的、相对简单的工程的一种过程分解。如今，我们思索一个复杂些的工程，它具有更广的范围和更重要的商业影响。这样一个工程在用户通讯活动中能够需求以下任务义务： .3.4.2过程分解61 复审客户要求。2 方案和安排与客户进展正式的、促进性的会议。3 研讨如何刻划引荐的处理方案和已有的方法。4 为正式的会议预备一份“任务文档和议程。5 召开会议。 6 共同制定可以反映软件的数据、功能和行为特征的小规约。.3.4.2过程分解77 复审每一份小规约，确认其正确性、一致性和无二义性

40、。8 把这些小规约组装起来构成一份范围文档。9 和一切相关人员一同复审范围文档。10 根据需求修正范围文档。两个工程都执行了我们称之为客户通讯的框架活动，但第一个工程组只执行了第二个工程组一半的软件工程任务义务。 .3.5工程 1为了管理胜利的软件工程，必需了解我们会做错什么和如何正确地完成义务。John Reel定义了10个标示一个信息系统工程正处于危险形状的信号：1. 软件人员不了解他们的客户的需求。2. 产品范围是糟糕定义的。3. 没有很好地管理变化。4. 选择的技术发生变化。 .3.5工程 25. 业务需求发生变化或未被很好地定义。6. 时限是不现实的。7. 用户抵抗。8. 失去资助或

41、从来没有真正地得到过。9. 工程组缺乏具有适宜技艺的人员。10. 管理者和开发者躲避已学到的最好的实际阅历。 .3.5工程3 QUOTE：在10个IS工程失败的信号中，至少7个信号在设计完成或开场书写一条代码前被确定。John Reel疲惫不堪的产业从业人员们在讨论特别困难的软件工程时，经常提及9090规那么：一个系统前面的百分之90破费了所分配任务量和时间的百分之90。系统后面的百分之10也会破费所分配任务量和时间的百分之90。导致该9090规那么的根源包含在上面列出的“信号中。 .3.5工程 4Reel提出了一个包含5部分常识的软件工程方法：1. 在正确的根底上开场任务。这是经过努力任务非

42、常努力以了解将被处理的问题，而后为每个涉及到工程中的人员设置现实的目的和期望而到达的。然后又经过建立适宜的开发组并给予小组完成任务所需的自主权、权益和技术而加强。 .3.5工程 52. 坚持动力。很多工程的启动有一个很好的开场，但是，渐渐地开场瓦解。为了维持动力，工程管理者必需提供鼓励措施以坚持人员的调整到绝对最小的量，小组应该强调它完成的每个义务的质量，而高层的管理应该尽其一切能够以不干涉小组的任务方式。3. 追踪进展。针对软件工程，当任务产品如，规约、源代码、测试用例集合被产出和作为质量保证活动的一部分而被同意经过正式的技术复审时，追踪其进展。此外，软件过程和工程测度可以被搜集并用于评价进展，根据软件开发组织的平均数据。 .3.5工程 64. 做出聪明的决策。本质上，工程管理者和软件小组的决策应该是“坚持其简单。只需能够，决议去运用商用的离架COTS软件或现存的软件构件，决议在规范的方法可用时防止定制界面，决议去标识、然后防止明显的风险，以及决议去分配比他以为需求的时间更多的时间来完成复杂的或风险的义务。5. 进展事后的分析。建立一个一致的机制以从每个完成的工程获取可学习的阅历。评价方案的和实践的进度，搜集和分析软件工程度量，从工程组成员和客户处获取反响，并记录下一切发现。 .3.6 W5H