915软件体系结构Software Architecture.ppt

软件体系结构(Software Architecture),讲义14：以体系结构为中心的 软件项目管理,内容,内容简介以体系结构为中心的软件项目计划全局分析管理期望项目组织建立项目文化和小组软件项目经理的角色权衡和项目决策增量式开发创建可视性与避免意外在激烈的竞争中保持冷静需关注的度量什么是“出色的工作”总结,技术和管理是项目成功的两个基石,好的设计和项目管理技巧对于项目的成功大有帮助作为一个产业，我们还未能非常成功地管理成功的软件项目。成功的项目是指达到计划的开发进度、提供承诺的功能并交付高质量软件的项目据1995年Standish Group CHAOS的报告，他们对软件项目的研究表明：16%的软件项目完全成功，31%的项目被完全取消，53%的项目严重超出预算、延期并交付少于预期的功能到1998年，成功地项目增多了：26%完全成功，28%被完全取消，46%超过预算、延期和缺少功能 情况在改善，但是，对于成功完成的软件开发项目，业界的纪录依旧很糟糕,体系结构在管理中的作用(1/3),以技术为中心的体系结构的作用观点，基于以下的基本假设体系结构是开发软件系统的关键体系结构是实现商业目标、达到软件质量品质的基础为提高软件质量而设计软件体系结构，以及如何评估软件体系结构是否完全实现它的质量目标如果说体系结构是实现系统所要达到的商业目标的核心，那么，体系结构也必须成为项目经理和软件架构师的工作核心“在缺少高层体系结构的情况下，工作的时间进度和工作量的估算是毫无价值的”项目经理需要根据体系结构来制定进度计划、进行估算和管理人员,体系结构在管理中的作用(2/3),估算的经验值，项目开发时间的分配40%用于设计：最多用3个月的时间进行高层设计，剩下的用于底层设计20%用于编码40%用于测试：需要在开发小组内着重强调对体系结构的纵向划分使得系统能够增量式地添加其它功能，并调整功能以适应各种版本正如体系结构体现了各种质量之间的权衡，进度计划也体现了交付时间、质量和功能之间的权衡。要向开发小组明确三者之间的优先级，并利用进度的压力来避免对质量和功能的过度强调通过较短周期（8周）的增量式提交，有可能开发有限销售的功能，并选取在一次增量开发时间内那些以可接受的质量实现的功能,体系结构在管理中的作用(3/3),进度表依赖于体系结构，而增量式提交依赖于进度表，这种控制是以体系结构为基础的软件开发的根本特性以体系结构为中心的项目管理技术是同现有的管理技术紧密相关的制定明确的进度表得到股东的支持确定切实可行的期望值对员工的弱点感觉敏锐在动荡中保持冷静在任何环境中，这些都是好的项目经理应具备的素质,项目经理的职责(1/2),项目经理的主要工作计划（Planning）组织（Organizing）：建立项目组和确定组成员的角色实现（Implementation）：根据制定的项目计划，进行项目实现，并应付各种事先无法预测的情况度量（Measurement）：在项目开发过程中及项目开发结束后，评估项目进度、项目组及各成员的业绩、提交的产品的有效性其它任务项目领导、控制、设定用户期望、革新、决策、指导以及提供帮助,项目经理的职责(2/2),项目经理的成功与否在很大程度上取决于如何分配时间。永远也不会有足够的时间干完所有的事情，项目经理需要谨慎地决定各个任务的优先级，并成功地平衡时间好的项目经理常常都有均衡的技术和人员管理的技能人员管理的技能通常表现在交流、理解、领导能力、情感、教学、个人魅力等多方面通常，项目组的技术能力可以通过任用强有力的软件架构师得到增强,以体系结构为中心的项目管理(1/3),以体系结构为中心的软件项目计划（Architecture-Centered Software Project Planning,ACSPP）方法根据软件体系结构来估算开发项目的费用和进度这里所描述的项目管理实践可以称为“中量级”的过程，介于能力成熟度模型（CMM）和Rational统一过程（RUP）所描述的重量级过程与极限编程这样的轻量级过程之间在前期准备工作中多花一些时间，包括为预想的产品设计软件体系结构以及制定项目计划。实现中采取增量开发方法，以便迅速占领市场，并在实现体系结构的同时，增量式地更新项目计划,以体系结构为中心的项目管理(2/3),基本特征体系结构的设计和描述项目计划：进度表、工作量估算和项目组织结构增量式开发项目经理/架构师小组：分别对应管理决策和技术决策权衡分析：灵活管理各种开发风险软因素：小组建设、士气、管理的影响、业务的影响、人员经验和文化等项目经理需要做许多与设计无关的事情，但明确的是，在管理项目的过程中，需要确定一个体系结构设计，它将能够代表将要开发的产品的理念和外观软件开发计划说明如何实现体系结构所代表的理念管理开发就是在计划的指导下，逐步实现体系结构开发计划需要做许多中间过程的修正，但希望体系结构在实现过程中能够保持不变,以体系结构为中心的项目管理(3/3),需求分析,全局分析,风险分析,版本发布计划,版本交付,管理开发小组,软件开发计划,体系结构设计,市场需求,产品因素,风险和缓解,进度次序,如何做、谁承担、何时进行,中间过程的修正,产品,产品因素,体系结构描述,问题和策略,模块视图,计划工作,项目计划开始于定义一系列的系统需求，结束于生成软件开发计划。项目计划与软件体系结构的设计并行进行，并在开发过程的每一次增量式版本发布之前进行,组织工作,项目经理需要组织体系结构设计小组、开发小组和与项目管理相关的所有活动。项目管理活动包括和组织内其他功能的接口，如市场、质量保证、系统测试和文档编写,组织设计小组,自底向上的估算,组织开发小组,领导开发小组,软件开发计划,体系结构设计,市场需求,纸面设计,每一构件所需的工作量,开发小组,如何做、谁承担、何时进行,产品实现,软件架构师,体系结构描述,项目组成员,实现工作,项目经理负责根据软件开发计划实现项目。体系结构设计所得到的模块视图是组织项目开发小组的基本依据,组织开发小组,风险分析,版本发布计划,软件开发计划,版本交付,状态会议,管理开发小组,体系结构设计,组织的因素,组织的因素,进度顺序,如何做、谁承担、何时进行,中间过程的修正,产品,模块视图,问题和策略,缓解,模块视图,市场因素,工作进展,度量工作,项目策略,版本发布计划,软件开发计划,软件开发,事后复审,版本交付,状态会议,体系结构设计,市场需求,目标,进度预算,工作进展,中间过程的修正,产品,改善行动,问题和策略,模块视图,进度顺序,市场需求,体系结构草图,根据软件开发计划可以定义一些项目度量标准，作为项目开发的目标。这些目标包括开发预算、重要里程碑、规模度量和质量度量,内容,内容简介以体系结构为中心的软件项目计划全局分析管理期望项目组织建立项目文化和小组软件项目经理的角色权衡和项目决策增量式开发创建可视性与避免意外在激烈的竞争中保持冷静需关注的度量什么是“出色的工作”总结,以体系结构为中心的软件项目计划,以体系结构为中心的软件项目计划（Architecture-Centered Software Project Planning,ACSPP）方法根据软件体系结构来估算开发项目的费用和进度好的软件项目管理始于好的计划，合适的计划时间是在体系结构进行设计的时候在软件开发初期给出的工作量和时间的估算可能是极其不准确的在没有高层体系结构设计的情况下，所生成的工作量和时间的估计只有很小的价值当设计完成后，才可以创建项目计划、进度表和人力资源分配方案，所有这些都依赖于该产品的软件体系结构,ACSPP的时机(1/2),在软件开发初期给出的工作量和时间的估算可能是极其不准确的Boehm 1981,Boehm et al.2000ACSPP是在系统需求分析完成之后进行的,产品需求定义（市场人员）,系统需求分析（系统工程师）,高层设计（架构师）,详细设计（软件工程师）,编码单元测试、集成测试、系统测试,市场需求说明（MRS）,系统需求说明（SRS）,高层设计文档（HLDD）,详细设计文档（DDD）,ACSPP,ACSPP的时机(2/2),根据Boehm1981的说法，对于在需求说明结束后所给出的成本估算，实际的投入可能是其1.5倍；对于在需求分析完成前，项目启动时所给出的估算，实际的投入可能是其4倍。在高层设计完成后，通过应用ACSPP和估算进度表，进度估算可以精确到15%20%采用小增量式开发，更有助于项目经理把握项目一系列短周期的简单计划要比一个大而复杂的计划更容易管理业务经理经常会乐于接受一个很早的进度计划，用其与潜在的客户沟通，并努力使开发小组按照此进度交付软件产品。这样经常会引起客户的不满，因为产品没有达到他们对于交付的期望，初始版本质量低下，开发小组疲惫不堪,ACSPP方法(1/2),高层设计,自底向上的估算,项目进度表,软件开发计划,自顶向下的进度表,版本发布计划,个人进度表,ACSPP方法(2/2),软件体系结构的高层设计由一个小型的设计小组发起与此平行，项目经理制定自顶向下的进度计划高层设计和自顶向下的进度估算成为版本发布计划的输入在高层设计中确定的软件构件是自底向上的估算过程的一部分项目经理然后可以计算各个软件构件规模和工作量的估算之和，并与自顶向下的进度相比较根据所有这些信息，项目经理制定项目开发进度计划。这个进度计划与人员分配和项目组织结构共同组成软件开发计划（SDP）项目组成员以SDP为框架，制定个人进度计划,体系结构的四视图和层次图,自顶向下的进度表,进度表包括的内容：工作量，成本和进度，开发主要阶段的持续时间，以及对具有各种开发技能的人员的需求自顶向下的方法是软件项目经理估算新项目常用的方法项目经理有很多可用的估算模型Cocomo模型SLIMPRICE-S功能点分析（FPA）就其本身而言，估算模型通常不是很精确，因此需要对模型进行较准，但很多组织缺少进行校准所需的采用类似技术的项目的历史数据项目估算模型的结果确实很有用，因为它有助于项目经理在计划项目时，不至于忘记任何重大的工作量投入自顶向下计划的估算模型也有助于管理人员了解新软件产品开发的范围和风险,自底向上的估算,在高层设计定义了所有构件之后，每个项目组成员进行指定构件的“纸面设计”，并估算每个构件的详细设计、编码和单元测试所需的工作量项目经理应该把需估算的构件分配给最可能实现该构件的项目组成员。这样做可以增加估算的全面所有权，并且将个人与他们参与的系统各个部分联系起来这时也是将其他成员引进项目组、开始进行自底而上估算的时机。一直到这时，开发小组主要由项目经理和高层设计小组组成，由软件架构师领导构件设计概要估算是与规模、信心水平、复杂度以及相关设计、编码和测试工作量等因素有关的,版本发布计划,软件开发计划可以被设计成一系列不断增加功能的增量式工程版本第一个版本将包含体系结构层次图的“纵向分块”，作为体系结构的原型最后一个版本将是可以打包销售给客户的第一个功能集合还可以计划内部测试或主要用户测试的或版本需要计划版本的增量和测试，这样开发人员可以得到测试结果，以在下个版本中对错误进行修改为这些增量版本定义的时间周期将依赖于测试和特征开发所需的时间，同时也依赖于商业的限制,构造计划,特征发布规格说明（FRS）经过市场部门和服务部门咨询，编写FRS，并详细说明每个工程版本包括哪些产品特征构件发布规格说明（CRS）描述必要的构件版本发布，以实现在每个工程版本中所要求的特征构件版本发布的责任被分派给小组成员，小组成员根据这些文档制定他们自己的个人进度表在整个开发周期中，版本发布计划通常由一系列主要特征来标识目标版本；构造计划更多地集中于描述在下一个增量版本（即“内部工程版本”）中要开发的详细特征的实现顺序,项目进度计划,根据自顶向下的进度、自底而上的估算、FRS和CRS，可以制定项目的进度纲要，以使得每个内部工程版本都可以在预期的里程碑之内完成设计、编码、单元测试、集成以及系统测试等工作对于每个版本，都可将每个构件的开发按照开发阶段（如详细设计、编码、单元测试、错误修正）分解为子任务，并在每一增量式发布的过程中重复这些阶段。根据自底而上估算过程所得到的工作量估算，制定每一个构件的进度表计划提高计划的可见度，让每一个人都了解“项目战斗室”：所有项目进度计划表都被张贴到一个会议室的墙上，并每周更新项目进度，用彩笔标注出哪些项目已经完成，哪些已经迟于进度计划了,实例：高层软件开发进度纲要,软件开发计划（SDP）,软件开发计划是一个短的文档，包括项目进度表工程版本定义人员需求子承包商的应用项目组织成本估算开发工具及过程任务分配风险硬件平台SDP引用该组织的软件开发过程、高层设计文档（HLDD）、功能发布说明（FRS）以及构件发布说明（CRS）,实例：软件开发计划大纲,个人进度表,一旦包括项目进度在内的SDP完成，就应该把它交给项目开发组的所有成员。根据项目进度表、软件开发过程以及任务分配，每个成员制定个人进度表这个进度表非常细，可以监控项目组每个人每周的开发情况建议项目经理每周检查个人进度，并根据项目的规模和复杂程度，每两周或每月更新项目进度一旦每个人对其所负责开发的构件在整个软件体系结构中的位置和作用都了解了，构件的开发将会变得更加简单和可以预测项目经理和软件架构师作为开发小组的教练，而不是如工头一样迫使小组接受计划并强制执行,经验数据(1/2),与估算有关的工作所占用时间的经验数据,经验数据(2/2),对于中等规模的项目应用这些经验值，我们估计高层设计阶段大约占总共开发成本的5%我们假设，由45人工作3个月所进行的高层体系结构设计，将对一个由20个人工作一年甚至更长时间所开发的项目，产生深远的影响这20个小组成员还将对体系结构中的每个构件进行设计，称为详细设计因此，和设计有关的活动的工作量有可能占到整个项目成本投入的40%；但是最初的5%的对软件体系结构的投入，将对开发产生最为深刻的影响,提示,“当时间不够时，停止高层设计”问题：高层设计和详细设计的界限是什么？软件架构师的回答：当设计已详细到可以将每一个模块交给开发人员进行详细设计时，高层设计就结束了对于实践的项目经理来说，这些界限是模糊的，是以里程碑为驱动的建议：成功的做法是大致按照上表所提供的经验数据，限制高层设计的时间。体系结构的设计永远不会完全结束，但是，确定一个必须完成和复查的时间将有助于指导设计小组,内容,内容简介以体系结构为中心的软件项目计划全局分析管理期望项目组织建立项目文化和小组软件项目经理的角色权衡和项目决策增量式开发创建可视性与避免意外在激烈的竞争中保持冷静需关注的度量什么是“出色的工作”总结,什么是全局分析,在着手设计一个新的软件系统体系结构时，一个众所周知的问题是：随着市场需求、技术、硬件和业务等因素的变化，系统的设计和实现也将相应地改变其中一些影响因素影响整个系统，而其中某些因素和其他因素直接冲突。为了避免潜在的大量返工，这些因素必须在高层设计的开始就予以考虑全局分析就是分析对系统体系结构设计产生全局性影响的组织、技术和产品等方面的因素全局分析是体系结构设计的一个组成部分，在设计阶段的开始便应用到体系结构的各个视图中全局分析的结果是一组全局策略，可用于指导体系结构设计并提高系统对于各种已识别的影响因素的应变能力全局分析得到的策略将影响体系结构的设计和项目计划,全局分析方法,分析组织因素,分析技术因素,分析产品因素,影响因素,为实现、构造能力和可变能力的改善制定策略,全局分析活动,采用两种工具辅助全局分析并记录结果因素表问题卡片,分析因素确定和描述因素描述因素的灵活性和可变性分析因素的影响,开发策略确定问题和影响因素制定解决方案和特殊策略确定相关的策略,通用因素表：组织因素,实例：因素表,通用问题卡片,实例：问题卡片,组织的影响因素,一些组织因素（例如进度表和预算）只能应用于现在正在设计的产品，其他组织因素（例如组织的态度、文化、开发场所的位置和软件开发过程）会影响组织每一个开发的项目一些组织因素可以控制，但在许多组织中，这些因素是固定的，因此，体系结构的设计必须在这些限制之内。在很多情况下，组织因素是项目经理必须接受和容忍的。组织因素（如组织结构、开发过程、人员和环境）经常不易改变，或是只有在很长一段时间后才会改变组织因素一般包括以下几类：O1管理O2员工技能、兴趣、强项、弱项O3过程及开发环境O4开发进度表O5开发预算,技术的影响因素,技术因素将设计的选择局限于现有的硬件、软件、体系结构技术以及标准产品必须能够适应于技术的不断变化，因此体系结构设计时应保持灵活。由于技术变化快、厂家竞争等原因，技术因素和选择平台的决策是当前软件开发的重要问题技术因素一般包括以下几类T1通用硬件T2领域特定硬件T3软件技术T4体系结构技术T5标准,产品的影响因素,产品因素包括产品的功能及质量，例如性能、可信赖性、安全性以及成本。这些因素也许会在后来的版本中有所不同，因此需要设计体系结构以支持预期的变化例如，为了支持产品线体系结构，产品影响因素的一个例子是，图形用户界面需要能够对不同应用程序适应于不同类型的用户产品因素一般包括以下几类P1功能P2用户界面P3性能P4可信赖性P5故障检测、报告、恢复P6服务P7产品成本P8可维护性,对项目计划采用全局分析,全局分析的问题和策略影响着设计和项目计划的活动,全局分析在开发过程中的位置和作用,项目策略决定(1/2),作为项目经理，可以采用由全局分析得到的问题和策略作为软件开发计划的输入计划应该说明在产品开发中希望引起注意的所有主要的风险，定义项目策略结论是一种好的方式，用以明确项目的重点和目标，并保持一个简短的策略列表，使得所有开发组成员都了解。这些策略应该成为全体开发组成员的指导原则，有助于定义项目的目标和降低风险,项目策略决定(2/2),实例：DPS2000项目的一些项目策略决策增量式地开发DPS2000项目，以保证在期望的开发阶段内完成和发布一些基本的功能，并开始创收将满足进度要求作为最高的项目优先级。如果需要的话，可以权衡功能来适应发布日期复用已有产品的构件，购买而不是开发，以减少必要的新开发工作量设计策略决定了体系结构的优先级和制约条件，有助于确定软件系统实现有关的潜在风险DPS2000全局分析的结果是确定了24个全局策略，我们验证这些策略可以解决影响因素。从这24个设计策略中，得到了6个主要的项目策略结论，它们可以作为DPS2000体系结构设计和产品开发的指导原则,体系结构评估,体系结构权衡分析方法（ATAM）是体系结构评估中应用最为广泛的方法。ATAM根据非功能性需求评估软件体系结构，例如可伸缩性、安全性和性能。这些非功能性需求或是质量属性经常是在全局分析产生的因素表中所确定的因素在全局分析中制定的设计和项目策略是ATAM复查小组的好的输入。随着有关不同的体系结构风格问题的提出，你可以在复查中讨论并确认这些策略,风险分析(1/2),风险由条件、结果以及周围的环境构成。在软件项目计划方面，风险可能是技术、政治、经济、资源或是其他一些事件，可以对项目开发、市场占有率或是达到项目目标（如尽速、预算、质量）造成灾难性的后果项目经理对风险的计划、预期和反应的技能将直接影响项目的成功。应将风险缓解加入软件开发计划的任务中，以便于减少风险对项目产生负面影响的可能性风险分析试图定量地分析一个特定的风险发生的可能性。风险分析工作是收集和考虑全局分析和ATAM复查中得到的问题，或是其他类型的体系结构评估方法得到的问题问题卡片记录了全局分析得到的问题ATAM简档记录了ATAM得到的风险，通常是由复查小组制作的演示图,风险分析(2/2),当开发新的产品来取代现有产品时，可能需要一个单独的风险缓解计划，既讨论技术风险也讨论市场风险及相关缓解方案可能的策略：你也许需要对开发新产品这一计划保密如果你的用户都得知了你的项目，他们也许会决定等用新的产品，而不再投资购买现有的产品。这有可能对现有产品的销售产生负面的影响向用户保密可能会造成失去及时得到用户反馈的机会，而要等到最终产品发布之后产品发布可能与交易联系在一起，这也许需要在发布之前有一个增量的版本，使得产品可以示范给潜在的用户,开发项目策略,对问题、风险以及风险缓解的分析有助于制定项目策略及目标。每一个项目应该对满足进度、质量和功能目标之间的相对优先级有一个清楚的说明实例：IS2000项目的项目目标满足进度要求比质量要求的优先级更高，质量要求比功能要求的优先级更高项目经理对目标的说明：“我必须满足发布的进度要求，我的软件质量看起来不错，但是我未能提供一些简单的功能。不管怎样，让我们先把产品发布出去吧。”对项目目标的简短说明有助于小组成员牢记他们正在努力实现的目标。这些目标应该记录在软件开发计划中，并根据需要在开发过程中加以修改,全局分析和版本发布计划,定义了风险、风险缓解和项目目标，这些确实有助于制定版本发布计划。因为版本发布计划将转化成关于开发任务的进度计划，注意开发任务的次序将进一步缓解风险在版本发布计划的过程中，需要将功能特性映射到工程版本，以描述这些功能的实现序列的计划,全局分析和软件开发计划,软件开发计划是用于计划开发的主要依据，并在每一次开发增量前，由项目经理更新由全局分析得到的问题、策略、项目策略结论以及关于风险和可能的缓解计划的列表均记录在SDPSDP是一个非常重要的文档，因为各次工程发布之间间隔时间并不长，在项目经理委托开发小组按照规定的发布日期开发下一个版本之前，每个小组成员都需要重温SDP在重温SDP时，小组成员通常马上跳到相应的进度表，查看下一个增量版本的任务分配定期地更新文档使得项目经理可以修改、补充或是更好地交流重要的风险和策略,对测试计划采用全局分析,系统测试计划的首要依据是系统的需求说明。系统的测试小组主要是测试系统能否成功地实现功能需求。因此，他们的兴趣主要集中在产品的影响因素上由全局分析得到的问题卡片有助于对测试计划提供重要的输入。如果有与产品功能相关的关键问题，这些问题是系统测试需要重视的地方例如，对于人为风险高的部分，将会设计更彻底的测试用例,内容,内容简介以体系结构为中心的软件项目计划全局分析管理项目组织建立项目文化和小组软件项目经理的角色权衡和项目决策增量式开发创建可视性与避免意外在激烈的竞争中保持冷静需关注的度量什么是“出色的工作”总结,引子：管理层的期望,实例：在IS2000项目中，管理层对于正在设计的软件体系结构的潜在开发费用表示担忧每天都要多次被问及实现所需的工作量有多大，因此不得不在体系结构小组与管理层之间进行交流如果提供的估算值过高，会使管理层感到沮丧；如果提供的估算值过低，会增高期望值，给开发小组带来额外的压力“正确的”答案是一个切实的估算值，这只有在我们有足够的时间进行需求分析，并提交一份有信心实现的体系结构时才能说明项目经理需要合适的时间进行项目计划，未经计划的软件项目难以成功实现。项目计划的活动应在被称为“项目高层设计阶段”的期间进行在项目计划的过程中管理期望值。如果管理层在项目的开始阶段期望正确，则有可能制定切实可行的开发计划，并在整个开发过程中得到支持,何时计划及何时提交(1/2),对于以体系结构为中心的软件项目计划，项目计划应与体系结构设计并行。大约5%的开发预算以及20%的开发时间用于高层设计阶段对项目进度和开发成本进行早期估算，通常给项目经理造成很大的压力在高层设计阶段，项目经理同体系结构小组的成员一起探究各种情况，在队伍规模、进度计划以及开发成本之间加以权衡。项目经理也同管理层一起探究软件开发有关的业务和组织的限制，但在体系结构设计的过程中，项目经理应该只明确各种场景，而不是讨论具体的计划一旦制定、存档和复查了最初的体系结构设计，项目经理就可以考虑提交开发计划,何时计划及何时提交(2/2),计划提交是非常关键的环节经理层同意支持项目并提供相应的资源项目经理同意按照计划管理开发组同意生产产品,向上的管理(1/2),当项目经理正在考虑开发产品的各种情形和策略，投向结构小组忙于设计体系结构时，管理层通常已经迫不及待地想了解开发的成本及何时可以得到产品。尤其是，市场和销售经理试图得到任何有关产品功能和可用性的信息，以提供给关键的用户在这种环境下，非常重要的是对于项目小组正在考虑的各种项目开发情景的细节，应限制与外界交流。以使与管理层分离的体系结构小组能够更好地制定计划并得到管理层的支持项目经理和首席软件架构师必须完全相信他们能充分实现项目计划。无论项目经理或是首席软件架构师缺乏这种基本信心，项目都注定要失败。所有的小组成员都必须在某种程度上也具有这种信心，但他们通常是在项目经理和首席软件架构师的领导之下,向上的管理(2/2),如果项目经理认为受到压力而必须提交一份他认为不可能实现的计划，那么项目经理必须准备离开该项目这一点最好在开发开始之前就认识到，而不是在开发失败、未能达到项目目标后才认识到。如果项目经理的管理层不接受他建议的计划，他最好在高层设计阶段结束时离开项目，并推荐任命其他的项目经理来接管。如果管理层认识到项目经理希望按期完成任务并对其承诺很严肃，通常他们愿意接受提交的计划大多数的美国项目经理努力在小的偏差范围内达到项目目标，他们倾向于用苛刻的目标挑战自我及其项目小组，并且在努力实现这些目标的过程中感到满足项目经理是否正确地确定期望，并始终如一地实现承诺，是项目经理需要逐渐学会与上级沟通的方法,横向的管理,项目经理还需管理对等平行机构的期望，这是在开发过程中需要处理的，包括诸如系统测试、软件质量管理、用户文档、产品管理、市场以及销售等在很多情况下，项目经理需要这些相关功能部门的合作与支持，但是他对其活动不能直接控制和管理。因此，由于缺乏控制权，项目经理必须通过增加交流加以补偿，以明确项目的需求以及他的期望项目经理与支撑功能最常见的交流就是系统测试。采用增量式的开发方式，项目经理需要每48周对增量版本进行系统测试另一个重要的接口是负责定义产品功能的人员，他们通常兼有产品管理、市场或系统工程功能。如果这个角色被称为产品经理，项目经理需要与他建立密切的工作关系，包括经常讨论和细化产品计划或是实现的功能特征,信息流,对于项目管理，在高层设计阶段，需要管理与项目有关的期望，包括与上级的关系及横向的交流，在这中间，重要的是管理信息流,内容,内容简介以体系结构为中心的软件项目计划全局分析管理期望项目组织建立项目文化和小组软件项目经理的角色权衡和项目决策增量式开发创建可视性与避免意外在激烈的竞争中保持冷静需关注的度量什么是“出色的工作”总结,项目组织,有多人参与的项目需要加以组织，以使得每一个小组成员都有特定的角色和交流途径小组成员的技能不同，有些是专家，有些仅是普通技术人员有些是经验丰富的软件件开发人员，有些则是新手项目经理必须建立好项目的组织结构，以便圆满地完成任务产品的开发有一种方便的方法定义项目的组织，即根据正在开发的产品的软件体系结构,利用软件体系结构定义项目组织,体系结构的模块视图不仅为项目经理提供了一个构件的列表，用以估算开发成本，还洞察了开发组织方式模块视图描述了软件系统是如何分解为各个子系统和功能模块的。我们可以将此视图映射到项目组织，使项目组织反映体系结构，这有助于在项目中加强体系结构的概念，并根据小组成员所擅长的工作，分配各自的角色在实际的项目中，体系结构层次图与项目的组织结构之间不可能是完全的一一对应关系考虑各个小组的规模，保持在7(2)个人左右注意在项目组织中，兼职人员数量以及与此有关的一些问题另外，还要考虑人员之间的人际关系,开发过程中体系结构小组的角色,在项目的高层设计阶段，开发小组主要局限于体系结构设计小组和项目经理在高层设计结束时，通常需要更大的队伍来开发产品，并引入额外的小组成员，参与自底而上的估算。也就在这时，项目经理开始组建项目组最好是由可能负责设计和开发特定功能构件的小组成员负责该构件的估算，这有利于提高进度估算的精确性及对其的承诺，同时有助于弥补小组成员不同的经验水平建立项目小组的一种方法是，在开发组内部，任命体系结构设计小组的成员作为各开发小组的负责人对体系结构有更清楚的理解将体系结构知识传递到整个开发组内有助于在开发中加强体系结构，使得开发队伍中的每一个人都了解所实现的构件在整个产品中的作用,软件架构师的角色,主要职责建立作为产品来实现的体系结构的理念项目的关键技术顾问制定技术决策培训小组成员协调小组成员的工作实现产品次要职责参与编程,支持功能矩阵,在许多组织中，与产品开发有关的支持功能会以矩阵的形式分配给特定的项目开发组，这是因为这些功能可能为多个项目组服务，这些服务小组有可能要并行地开发产品。这对于设计和实现产品线体系结构的组织尤其适用支持功能的分配矩阵对项目经理来说是特殊的挑战，项目经理处理功能矩阵分配和管理的最好办法是通过充分计划项目经理必须提供给支持功能的经理产品开发计划、对需要提供支持的复杂性和规模的估算以及有可能出错的事件项目经理必须通知所有的支持功能他们有可能受影响的软件开发计划的细节当支持功能物理上相隔遥远时，情况有可能变得更加复杂为了项目的成功，项目经理必须与所有矩阵分配的支持功能建立友好的关系和相互信赖,项目经理的权力,在矩阵管理中，项目经理看起来更类似于员工，而不是生产线的管理者。你对开发组成员惟一能够造成实际影响的就是，你会影响其收入及他们在组织中未来的发展如果与分配到项目组的成员的能力相比，你的手段过于软弱，并且没有任何实际的或感觉到的权力，你将很难实现项目目标一些项目经理将其权力的大小与其所领导的开发组的规模相混淆。非常明确的是，小型开发队伍效率更高，因为他们能更方便地交流。因此，为了使你工作更简单并更有可能实现项目的目标，最好能将队伍保持在尽可能最小的规模上,系统测试和质量保证,称职的质量保证和系统测试工作可以帮助项目经理在用户之前发现产品中的错误。与软件测试工作和质量保证工作充分合作，将给项目经理带来最大的利益项目经理和测试经理需要共同工作，以身作则，以使测试成为建设性的而不是破坏性的工作测试人员发现的每一个错误都使得用户可以少发现一个开发人员有责任复查和处理每一个错误，即使还要保留在产品中不能改正，也要使每个错误都得到解答项目经理还需要与质量保证工作建立起良好的工作关系好的计划和对项目目标的清晰交流对于保证所有人为共同的目标努力是十分必要的如果项目目标是迅速开发出低质量的原型产品，以便从最终用户处得到反馈意见，那么，需要告知QA人员，以便他们相应地调整工作,责任、角色、权限和所有权,软件开发项目组有几种主要的角色及职责。除了首席软件架构师及项目经理外，一些重要的角色包括小组负责人开发人员构造师（buildmeister）系统测试经理市场或产品经理,内容,内容简介以体系结构为中心的软件项目计划全局分析管理期望项目组织建立项目文化和小组软件项目经理的角色权衡和项目决策增量式开发创建可视性与避免意外在激烈的竞争中保持冷静需关注的度量什么是“出色的工作”总结,引子：团队文化,在对西门子公司的一个软件开发组织进行审计的过程中，我发现他们小组中的每一个成员都认为良好的团队协作精神是在那里工作的最突出的特点，其认同的一致性令我惊讶。按照能力成熟度模型（CMM）的等级，这个机构仅处于1级水平，但是，他们的产品得到了用户的高度评价，其软件品质优良，而且生产效率相对较高由此，我们可以推断出团队精神是他们这个机构取得成功的一个关键因素,确定项目目标(1/2),软件开发小组获取成功的关键因素之一就是让他们清楚地认识到什么是他们必须完成的目标，以及成功的具体标准。这就意味着所确立的项目目标能够被每一个小组成员了解和接受，并且他们坚信这个目标一定能实现项目目标通常要涉及进度、工作量（成本）、品质和功能等方面的优先级要求同时满足以上几个方面，即不但要保证产品按时发送、总的预算不超过预算，还要确保卓越的品质和完整的功能特征，这是不切实际的要求最佳的选择就是明确什么是最重要的，然后确定一个目标使得在进度、成本、品质和功能四个方面中至少有一个限制程度较低而易于达到要求,确定项目目标(2/2),举例，更切实际的项目目标描述我们一定会在截止日期前完成高质量的项目，但是要尽可能多地加入事先讨论通过的功能特性，而且无需过分考虑研发所需费用如果加大工作量能够确保优良的品质和按期完成，那么我们可以考虑增加预算确定项目目标的目的帮助所有组成员了解大家在努力实现什么，并且在每个人权衡决策时，确定其工作重点在达到目标之后，整个小组（以及管理层）能够意识到成功如果主要目标是一定要按期完成，而且所有人都持续不懈地为之努力，那么大家就会对项目组的成功有一致的认同,成功小组的特点(1/3),在成功的小组中，无论什么时候，只要有某个成员遇到了棘手的问题，其他人就会主动伸出援助之手帮助解决通常成功的小组中的人际关系都是十分宽松和舒适的，这一点可以表现在平时相互之间的经常地开玩笑和对各自特征善意的打趣成功的小组成员之间能够取长补短、交换意见，相互冲突的意见也通常可以得到立即处理和圆满解决成功的小组中的成员相互之间都非常了解，通常他们可以预见对方对所提出的建议的反应在他们的主要工作之外，成功的小组中的成员有时候也共同参加其它活动，如一起进餐或参加社交活动成功的小组中的成员都尽职尽责，而且认为这是为圆满完成任务并对其他成员的一种义务,成功小组的特点(2/3),成功小组中的每个人都承诺达到小组的目标在讲述有关成就的时候，小组成员通常使用我们而不仅仅是我优秀的小组需要一定的时间才能建立起来。人员的变动会阻碍项目的进展，而且新的成员需要一段时间才能融合到小组中被其他人所接受。但是一旦小组明确了新的成员的角色，那么整个集体就会继续进步在开始阶段，需要有负责人让大家学会如何成为一个优秀的小组。但是，随着时间的推移，负责人的作用逐渐弱化，更多的将会是小组的自主驱动。此时，负责人更像是一个“教练”而非“导演”小组成员的协同技能、见解、背景和价值观等都不尽相同，但是却可以相互弥补和促进。通常情况下，大家都明确地知道自己的任务和职责,成功小组的特点(3/3),成功的小组还具备了一定的成功经验，这也有助于形成小组的自豪感并且为小组成员树立信心通常也会有成员曾经在其他小组中犯过错误，或者曾在不成功的小组中工作优秀的小组都坚信能够圆满地完成工作任务 尽管很容易识别一个成功的小组，但是，建立一个成功的小组要难许多。要想组建软件开发小组，使其成为一个未来的成功集体，就需要尤其注意建立适当的项目文化,建立项目文化,每一个成员都知晓项目文化的特点，并且确保此文化与项目目标保持一致信任、公开与交流为了取得项目的成功，小组成员与项目经理之间必须是相互信任、彼此公开和经常交流的。信任需要经过一段时间才能建立，是通过言行一致、承担责任和兑现诺言等建立起来消除隔阂与文化差异处理个性冲突“恳谈会”项目经理在这种会议上将工作目标传达给属下并提出相应的要求和期望树立信心只有每个成员都坚信自己能圆满完成工作任务，整个小组才能获得最终的成功,内容,内容简介以体系结构为中心的软件项目计划全局分析管理期望项目组织建立项目文化和小组软件项目经理的角色权衡和项目决策增量式开发创建可视性与避免意外在激烈的竞争中保持冷静需关注的度量什么是“出色的工作”总结,引子：项目经理的职业技能,作为一名项目经理，他将有机会接触组织中的很多人：软件架构师、总工程师、开发人员、测试人员、销售经理、质量保证专家和用户等，若想成为一个成功的项目经理，必须知晓以上这些人对你的期望以及你应该期待从他们身上获得什么项目经理必须具备的职业技能优秀软件工程师领导者政治家运动员教练交流者,项目经理的角色,建立一种理念,项目经理要对成功的项目建立一种理念不能一厢情愿地认为整个开发过程中的每件事情都会按照计划顺利实现项目经理要对有可能存在的主要风险有基本认识，一旦发生就要选择适当方案进行应对，以保证项目获得全部成功项目经理要确信这种理念是完全可以实现的作为领导者，这种对于获取最终成功的坚定信心，会给整个小组带来积极的影响,训练,随着整个小组的经验越来越丰富，项目经理必须为小组成员做出的指导也越来越少一旦出现这种情形，项目经理的角色就应该由指挥员向教练员转化确保每个小组成员都