软件体系结构(SoftwareArchitecture)课件.ppt

1、软件体系结构软件体系结构(Software Architecture)讲义讲义1414：以体系结构为中心的：以体系结构为中心的 软件项目管理软件项目管理内容内容1.内容简介2.以体系结构为中心的软件项目计划3.全局分析4.管理期望5.项目组织6.建立项目文化和小组7.软件项目经理的角色8.权衡和项目决策9.增量式开发10.创建可视性与避免意外11.在激烈的竞争中保持冷静12.需关注的度量13.什么是“出色的工作”14.总结技术和管理是项目成功的两个基石技术和管理是项目成功的两个基石 好的设计和项目管理技巧对于项目的成功大有帮助 作为一个产业，我们还未能非常成功地管理成功的软件项目。成功的项目是

2、指达到计划的开发进度、提供承诺达到计划的开发进度、提供承诺的功能并交付高质量软件的功能并交付高质量软件的项目 据1995年Standish Group CHAOS的报告，他们对软件项目的研究表明：16%的软件项目完全成功，31%的项目被完全取消，53%的项目严重超出预算、延期并交付少于预期的功能 到1998年，成功地项目增多了：26%完全成功，28%被完全取消，46%超过预算、延期和缺少功能 情况在改善，但是，对于成功完成的软件开发项目，业界的纪录依旧很糟糕体系结构在管理中的作用体系结构在管理中的作用(1/3)以技术为中心的体系结构的作用观点，基于以下的基本假设 体系结构是开发软件系统的关键

3、体系结构是实现商业目标、达到软件质量品质的基础 为提高软件质量而设计软件体系结构，以及如何评估软件体系结构是否完全实现它的质量目标 如果说体系结构是实现系统所要达到的商业目标的核心，那么，体系结构也必须成为项目经理和软件架构师的工作核心“在缺少高层体系结构的情况下，工作的时间进度和工作量的估算是毫无价值的”项目经理需要根据体系结构来制定进度计划、进行估算和管理人员体系结构在管理中的作用体系结构在管理中的作用(2/3)估算的经验值，项目开发时间的分配 40%用于设计：最多用3个月的时间进行高层设计，剩下的用于底层设计 20%用于编码 40%用于测试：需要在开发小组内着重强调 对体系结构的纵向划分

4、使得系统能够增量式地添加其它功能，并调整功能以适应各种版本 正如体系结构体现了各种质量之间的权衡，进度计划也体现了交付时间、质量和功能之间的权衡。要向开发小组明确三者之间的优先级，并利用进度的压力来避免对质量和功能的过度强调 通过较短周期（8周）的增量式提交，有可能开发有限销售的功能，并选取在一次增量开发时间内那些以可接受的质量实现的功能体系结构在管理中的作用体系结构在管理中的作用(3/3)进度表依赖于体系结构，而增量式提交依赖于进度表，这种控制是以体系结构为基础的软件开发的根本特性 以体系结构为中心的项目管理技术是同现有的管理技术紧密相关的 制定明确的进度表 得到股东的支持 确定切实可行的期

5、望值 对员工的弱点感觉敏锐 在动荡中保持冷静 在任何环境中，这些都是好的项目经理应具备的素质项目经理的职责项目经理的职责(1/2)项目经理的主要工作 计划（Planning）组织（Organizing）：建立项目组和确定组成员的角色 实现（Implementation）：根据制定的项目计划，进行项目实现，并应付各种事先无法预测的情况 度量（Measurement）：在项目开发过程中及项目开发结束后，评估项目进度、项目组及各成员的业绩、提交的产品的有效性 其它任务 项目领导、控制、设定用户期望、革新、决策、指导以及提供帮助项目经理的职责项目经理的职责(2/2)项目经理的成功与否在很大程度上取决于

6、如何分配时间。永远也不会有足够的时间干完所有的事情，项目经理需要谨慎地决定各个任务的优先级，并成功地平衡时间 好的项目经理常常都有均衡的技术和人员管理的技能 人员管理的技能通常表现在交流、理解、领导能力、情感、教学、个人魅力等多方面 通常，项目组的技术能力可以通过任用强有力的软件架构师得到增强以体系结构为中心的项目管理以体系结构为中心的项目管理(1/3)以体系结构为中心的软件项目计划（Architecture-Centered Software Project Planning,ACSPP）方法 根据软件体系结构来估算开发项目的费用和进度 这里所描述的项目管理实践可以称为“中量级”的过程，介于

7、能力成熟度模型（CMM）和Rational统一过程（RUP）所描述的重量级过程与极限编程这样的轻量级过程之间 在前期准备工作中多花一些时间，包括为预想的产品设计软件体系结构以及制定项目计划。实现中采取增量开发方法，以便迅速占领市场，并在实现体系结构的同时，增量式地更新项目计划以体系结构为中心的项目管理以体系结构为中心的项目管理(2/3)基本特征 体系结构的设计和描述 项目计划：进度表、工作量估算和项目组织结构 增量式开发 项目经理/架构师小组：分别对应管理决策和技术决策 权衡分析：灵活管理各种开发风险 软因素：小组建设、士气、管理的影响、业务的影响、人员经验和文化等 项目经理需要做许多与设计无

8、关的事情，但明确的是，在管理项目的过程中，需要确定一个体系结构设计，它将能够代表将要开发的产品的理念和外观 软件开发计划说明如何实现体系结构所代表的理念 管理开发就是在计划的指导下，逐步实现体系结构 开发计划需要做许多中间过程的修正，但希望体系结构在实现过程中能够保持不变以体系结构为中心的项目管理以体系结构为中心的项目管理(3/3)需求分析全局分析风险分析版本发布计划版本交付管理开发小组软件开发计划体系结构设计市场需求产品因素风险和缓解进度次序如何做、谁承担、何时进行中间过程的修正产品产品因素体系结构描述问题和策略模块视图计划工作计划工作 项目计划开始于定义一系列的系统需求，结束于生成软件开发

9、计划。项目计划与软件体系结构的设计并行进行，并在开发过程的每一次增量式版本发布之前进行需求分析全局分析体系结构评估风险分析软件开发计划版本发布计划项目策略体系结构设计市场需求产品因素风险和缓解风险和缓解项目目标进度顺序产品因素体系结构描述问题和策略设计风险如何做、谁承担、何时进行模块视图组织工作组织工作 项目经理需要组织体系结构设计小组、开发小组和与项目管理相关的所有活动。项目管理活动包括和组织内其他功能的接口，如市场、质量保证、系统测试和文档编写组织设计小组自底向上的估算组织开发小组领导开发小组软件开发计划体系结构设计市场需求纸面设计每一构件所需的工作量开发小组如何做、谁承担、何时进行产品实

10、现软件架构师体系结构描述项目组成员实现工作实现工作 项目经理负责根据软件开发计划实现项目。体系结构设计所得到的模块视图是组织项目开发小组的基本依据组织开发小组风险分析版本发布计划软件开发计划版本交付状态会议管理开发小组体系结构设计组织的因素组织的因素进度顺序如何做、谁承担、何时进行中间过程的修正产品模块视图问题和策略缓解模块视图市场因素工作进展度量工作度量工作项目策略版本发布计划软件开发计划软件开发事后复审版本交付状态会议体系结构设计市场需求目标进度预算工作进展中间过程的修正产品改善行动问题和策略模块视图进度顺序市场需求体系结构草图 根据软件开发计划可以定义一些项目度量标准，作为项目开发的目标

11、。这些目标包括开发预算、重要里程碑、规模度量和质量度量内容内容1.内容简介2.以体系结构为中心的软件项目计划3.全局分析4.管理期望5.项目组织6.建立项目文化和小组7.软件项目经理的角色8.权衡和项目决策9.增量式开发10.创建可视性与避免意外11.在激烈的竞争中保持冷静12.需关注的度量13.什么是“出色的工作”14.总结以体系结构为中心的软件项目计划以体系结构为中心的软件项目计划 以体系结构为中心的软件项目计划（Architecture-Centered Software Project Planning,ACSPP）方法 根据软件体系结构来估算开发项目的费用和进度 好的软件项目管理始于

12、好的计划，合适的计划时间是在体系结构进行设计的时候 在软件开发初期给出的工作量和时间的估算可能是极其不准确的 在没有高层体系结构设计的情况下，所生成的工作量和时间的估计只有很小的价值 当设计完成后，才可以创建项目计划、进度表和人力资源分配方案，所有这些都依赖于该产品的软件体系结构ACSPP的时机的时机(1/2)在软件开发初期给出的工作量和时间的估算可能是极其不准确的Boehm 1981,Boehm et al.2000 ACSPP是在系统需求分析完成之后进行的产品需求定义（市场人员）产品需求定义（市场人员）系统需求分析（系统工程师）系统需求分析（系统工程师）高层设计（架构师）高层设计（架构师）

13、详细设计（软件工程师）详细设计（软件工程师）编码编码单元测试、集成测试、系统测试单元测试、集成测试、系统测试市场需求说明（MRS）系统需求说明（SRS）高层设计文档（HLDD）详细设计文档（DDD）ACSPPACSPPACSPP的时机的时机(2/2)根据Boehm1981的说法，对于在需求说明结束后所给出的成本估算，实际的投入可能是其1.5倍；对于在需求分析完成前，项目启动时所给出的估算，实际的投入可能是其4倍。在高层设计完成后，通过应用ACSPP和估算进度表，进度估算可以精确到15%20%采用小增量式开发，更有助于项目经理把握项目一系列短周期的简单计划要比一个大而复杂的计划更容易管理 业务经

14、理经常会乐于接受一个很早的进度计划，用其与潜在的客户沟通，并努力使开发小组按照此进度交付软件产品。这样经常会引起客户的不满，因为产品没有达到他们对于交付的期望，初始版本质量低下，开发小组疲惫不堪ACSPP方法方法(1/2)高层设计自底向上的估算项目进度表软件开发计划自顶向下的进度表版本发布计划个人进度表ACSPP方法方法(2/2)1.软件体系结构的高层设计由一个小型的设计小组发起2.与此平行，项目经理制定自顶向下的进度计划3.高层设计和自顶向下的进度估算成为版本发布计划的输入4.在高层设计中确定的软件构件是自底向上的估算过程的一部分5.项目经理然后可以计算各个软件构件规模和工作量的估算之和，并

15、与自顶向下的进度相比较6.根据所有这些信息，项目经理制定项目开发进度计划。这个进度计划与人员分配和项目组织结构共同组成软件开发计划（SDP）7.项目组成员以SDP为框架，制定个人进度计划体系结构的四视图和层次图体系结构的四视图和层次图图形用户界面（GUI）应用程序应用程序服务探查服务图像处理数据库服务系统服务操作系统层通信硬件概念模块代码源代码运 行硬 件自顶向下的进度表自顶向下的进度表 进度表包括的内容：工作量，成本和进度，开发主要阶段的持续时间，以及对具有各种开发技能的人员的需求 自顶向下的方法是软件项目经理估算新项目常用的方法 项目经理有很多可用的估算模型 Cocomo模型 SLIM P

16、RICE-S 功能点分析（FPA）就其本身而言，估算模型通常不是很精确，因此需要对模型进行较准，但很多组织缺少进行校准所需的采用类似技术的项目的历史数据 项目估算模型的结果确实很有用，因为它有助于项目经理在计划项目时，不至于忘记任何重大的工作量投入 自顶向下计划的估算模型也有助于管理人员了解新软件产品开发的范围和风险自底向上的估算自底向上的估算 在高层设计定义了所有构件之后，每个项目组成员进行指定构件的“纸面设计”，并估算每个构件的详细设计、编码和单元测试所需的工作量 项目经理应该把需估算的构件分配给最可能实现该构件的项目组成员。这样做可以增加估算的全面所有权，并且将个人与他们参与的系统各个部

17、分联系起来 这时也是将其他成员引进项目组、开始进行自底而上估算的时机。一直到这时，开发小组主要由项目经理和高层设计小组组成，由软件架构师领导 构件设计概要估算是与规模、信心水平、复杂度以及相关设计、编码和测试工作量等因素有关的版本发布计划版本发布计划 软件开发计划可以被设计成一系列不断增加功能的增量式工程版本 第一个版本将包含体系结构层次图的“纵向分块”，作为体系结构的原型 最后一个版本将是可以打包销售给客户的第一个功能集合 还可以计划内部测试或主要用户测试的或版本 需要计划版本的增量和测试，这样开发人员可以得到测试结果，以在下个版本中对错误进行修改 为这些增量版本定义的时间周期将依赖于测试和

18、特征开发所需的时间，同时也依赖于商业的限制构造计划构造计划 特征发布规格说明（FRS）经过市场部门和服务部门咨询，编写FRS，并详细说明每个工程版本包括哪些产品特征 构件发布规格说明（CRS）描述必要的构件版本发布，以实现在每个工程版本中所要求的特征 构件版本发布的责任被分派给小组成员，小组成员根据这些文档制定他们自己的个人进度表 在整个开发周期中，版本发布计划通常由一系列主要特征来标识目标版本；构造计划更多地集中于描述在下一个增量版本（即“内部工程版本”）中要开发的详细特征的实现顺序项目进度计划项目进度计划 根据自顶向下的进度、自底而上的估算、FRS和CRS，可以制定项目的进度纲要，以使得每

19、个内部工程版本都可以在预期的里程碑之内完成设计、编码、单元测试、集成以及系统测试等工作 对于每个版本，都可将每个构件的开发按照开发阶段（如详细设计、编码、单元测试、错误修正）分解为子任务，并在每一增量式发布的过程中重复这些阶段。根据自底而上估算过程所得到的工作量估算，制定每一个构件的进度表计划 提高计划的可见度，让每一个人都了解“项目战斗室”：所有项目进度计划表都被张贴到一个会议室的墙上，并每周更新项目进度，用彩笔标注出哪些项目已经完成，哪些已经迟于进度计划了实例：高层软件开发进度纲要实例：高层软件开发进度纲要软件开发计划软件开发计划（SDP）软件开发计划是一个短的文档，包括 项目进度表 工程

20、版本定义 人员需求 子承包商的应用 项目组织 成本估算 开发工具及过程 任务分配 风险 硬件平台 SDP引用该组织的软件开发过程、高层设计文档（HLDD）、功能发布说明（FRS）以及构件发布说明（CRS）实例：软件开发计划大纲实例：软件开发计划大纲1.0 引论 1.1 项目概论 1.2 项目交付物2.0 参考资料 2.1 说明 2.2 标准3.0 项目组织 3.1 过程模型 3.2 组织结构 3.3 组织边界和接口 3.4 项目职责4.0 管理过程 4.1 管理目标和优先级 4.2 假设、依赖关系和约束 4.3 监督和控制机制 4.4 人员安排和培训 4.5 子承包商管理5.0 技术过程 5.

21、1 方法、工具和技术 5.2 软件文档 5.3 项目支持功能6.0 风险管理7.0 工作要素、进度和预算 7.1 工作包 7.2 依赖关系 7.3 资源需求 7.4 预算和资源分配 7.5 高层软件开发过程个人进度表个人进度表 一旦包括项目进度在内的SDP完成，就应该把它交给项目开发组的所有成员。根据项目进度表、软件开发过程以及任务分配，每个成员制定个人进度表 这个进度表非常细，可以监控项目组每个人每周的开发情况 建议项目经理每周检查个人进度，并根据项目的规模和复杂程度，每两周或每月更新项目进度 一旦每个人对其所负责开发的构件在整个软件体系结构中的位置和作用都了解了，构件的开发将会变得更加简单

22、和可以预测 项目经理和软件架构师作为开发小组的教练，而不是如工头一样迫使小组接受计划并强制执行经验数据经验数据(1/2)与估算有关的工作所占用时间的经验数据与估算有关的工作所占用时间的经验数据高层设计持续时间：至多3个月开发小组规模：最多6个架构师估算的构件数目：最多150个每个构件的纸面设计时间：最多4小时自底而上的估算时间：最多3个星期工程版本发布间隔：最多8个星期进度偏移：最多20%项目总体工作量分配 设计：40%编码：20%测试：40%跟踪里程碑：每周进度更新和风险评估：每月或是在每一个版本发布之前经验数据经验数据(2/2)对于中等规模的项目应用这些经验值，我们估计高层设计阶段大约占总

23、共开发成本的5%我们假设，由45人工作3个月所进行的高层体系结构设计，将对一个由20个人工作一年甚至更长时间所开发的项目，产生深远的影响 这20个小组成员还将对体系结构中的每个构件进行设计，称为详细设计 因此，和设计有关的活动的工作量有可能占到整个项目成本投入的40%；但是最初的5%的对软件体系结构的投入，将对开发产生最为深刻的影响提示提示“当时间不够时，停止高层设计”问题：高层设计和详细设计的界限是什么？软件架构师的回答：当设计已详细到可以将每一个模块交给开发人员进行详细设计时，高层设计就结束了 对于实践的项目经理来说，这些界限是模糊的，是以里程碑为驱动的 建议：成功的做法是大致按照上表所提

24、供的经验数据，限制高层设计的时间。体系结构的设计永远不会完全结束，但是，确定一个必须完成和复查的时间将有助于指导设计小组内容内容1.内容简介2.以体系结构为中心的软件项目计划3.全局分析4.管理期望5.项目组织6.建立项目文化和小组7.软件项目经理的角色8.权衡和项目决策9.增量式开发10.创建可视性与避免意外11.在激烈的竞争中保持冷静12.需关注的度量13.什么是“出色的工作”14.总结什么是全局分析什么是全局分析 在着手设计一个新的软件系统体系结构时，一个众所周知的问题是：随着市场需求、技术、硬件和业务等因素的变化，系统的设计和实现也将相应地改变 其中一些影响因素影响整个系统，而其中某些

25、因素和其他因素直接冲突。为了避免潜在的大量返工，这些因素必须在高层设计的开始就予以考虑 全局分析就是分析对系统体系结构设计产生全局性影响的组织、技术和产品等方面的因素 全局分析是体系结构设计的一个组成部分，在设计阶段的开始便应用到体系结构的各个视图中 全局分析的结果是一组全局策略，可用于指导体系结构设计并提高系统对于各种已识别的影响因素的应变能力 全局分析得到的策略将影响体系结构的设计和项目计划全局分析方法全局分析方法分析组织因素分析技术因素分析产品因素影响因素为实现、构造能力和可变能力的改善制定策略全局分析活动全局分析活动 采用两种工具辅助全局分析并记录结果 因素表 问题卡片分析因素分析因素

26、1.确定和描述因素2.描述因素的灵活性和可变性3.分析因素的影响开发策略开发策略1.确定问题和影响因素2.制定解决方案和特殊策略3.确定相关的策略通用因素表：组织因素通用因素表：组织因素组织因素组织因素灵活性和可变性灵活性和可变性影响影响O1:O1.1:O1.2:O2:O2.1:O2.2:实例：因素表实例：因素表组织因素组织因素灵活性和可变性灵活性和可变性影响影响O1:管理 O1.1:新的管理 对于IS2000项目新的项目管理O2:人员 O2.1:士气低落 小组成员的士气低落造成软件开发人员的流动性大O4:开发进度表 O4.1:投入市场的时间 要求投入市场的时间是两年 新的项目管理有可能改变项

27、目目标随着人员的离开和替代，小组组成将发生变化由于是业务需求,该时间要求必须满足为了适应新的目标，需求和体系结构设计有可能改变剩下的或是新上任的小组成员需要理解体系结构设计。高层设计文档应该完整并易于阅读开发时间短将对设计选择和项目计划产生很大的影响通用问题卡片通用问题卡片体系结构设计问题的名称体系结构设计问题的名称影响因素:解决方案:策略:策略:相关策略:实例：问题卡片实例：问题卡片Pr1：积极的进度表：积极的进度表就估算的工作量以及可以获得的资源，在两年内可能难以完成软件的开发影响因素：O1.1:经常更换新的管理层并改变项目目标有可能减缓项目的开发O1.2:士气低落有可能造成员工离职，引起

28、小组规模减小O4.1:两年的时限是根据商业情况得到的。如果没有新的产品发布，公司难以生存解决方案：需要长于两年的时间来重新设计和开发所有的软件。有3种可能的策略：软件复用、购买商用成品商用成品（commercial off-the-shelf,COTS）构件，以及采用增量式开发和功能版本发布策略：S1.1:复用S1.1:从已有的项目中,复用一些公司内部的面向特定领域的构件策略:S1.2:购买COTSS1.2:尽可能地购买市场上可以得到的软件,而不是重新建造策略:S1.3:增量式开发S1.3:增量式开发和功能版本发布,使得可以较晚地添加优先级较低的产品功能组织的影响因素组织的影响因素 一些组织因

29、素（例如进度表和预算）只能应用于现在正在设计的产品，其他组织因素（例如组织的态度、文化、开发场所的位置和软件开发过程）会影响组织每一个开发的项目 一些组织因素可以控制，但在许多组织中，这些因素是固定的，因此，体系结构的设计必须在这些限制之内。在很多情况下，组织因素是项目经理必须接受和容忍的。组织因素（如组织结构、开发过程、人员和环境）经常不易改变，或是只有在很长一段时间后才会改变 组织因素一般包括以下几类：O1管理 O2员工技能、兴趣、强项、弱项 O3过程及开发环境 O4开发进度表 O5开发预算技术的影响因素技术的影响因素 技术因素将设计的选择局限于现有的硬件、软件、体系结构技术以及标准 产品

30、必须能够适应于技术的不断变化，因此体系结构设计时应保持灵活。由于技术变化快、厂家竞争等原因，技术因素和选择平台的决策是当前软件开发的重要问题 技术因素一般包括以下几类 T1通用硬件 T2领域特定硬件 T3软件技术 T4体系结构技术 T5标准产品的影响因素产品的影响因素 产品因素包括产品的功能及质量，例如性能、可信赖性、安全性以及成本。这些因素也许会在后来的版本中有所不同，因此需要设计体系结构以支持预期的变化 例如，为了支持产品线体系结构，产品影响因素的一个例子是，图形用户界面需要能够对不同应用程序适应于不同类型的用户 产品因素一般包括以下几类 P1功能 P2用户界面 P3性能 P4可信赖性 P

31、5故障检测、报告、恢复 P6服务 P7产品成本 P8可维护性对项目计划采用全局分析对项目计划采用全局分析 全局分析的问题和策略影响着设计和项目计划的活动需求分析体系结构设计体系结构评估风险分析软件开发计划版本发布计划项目策略全局分析市场需求产品因素风险和缓解风险和缓解项目目标进度顺序产品因素体系结构描述问题和策略项目策略结论如何做、谁承担、何时进行模块视图组织因素技术因素设计任务设计任务项目计划项目计划全局分析在开发过程中的位置和作用全局分析在开发过程中的位置和作用项目策略决定项目策略决定(1/2)作为项目经理，可以采用由全局分析得到的问题和策略作为软件开发计划的输入 计划应该说明在产品开发中

32、希望引起注意的所有主要的风险，定义项目策略结论是一种好的方式，用以明确项目的重点和目标，并保持一个简短的策略列表，使得所有开发组成员都了解。这些策略应该成为全体开发组成员的指导原则，有助于定义项目的目标和降低风险项目策略决定项目策略决定(2/2)实例：DPS2000项目的一些项目策略决策 增量式地开发DPS2000项目，以保证在期望的开发阶段内完成和发布一些基本的功能，并开始创收 将满足进度要求作为最高的项目优先级。如果需要的话，可以权衡功能来适应发布日期 复用已有产品的构件，购买而不是开发，以减少必要的新开发工作量 设计策略决定了体系结构的优先级和制约条件，有助于确定软件系统实现有关的潜在风

33、险 DPS2000全局分析的结果是确定了24个全局策略，我们验证这些策略可以解决影响因素。从这24个设计策略中，得到了6个主要的项目策略结论，它们可以作为DPS2000体系结构设计和产品开发的指导原则体系结构评估体系结构评估 体系结构权衡分析方法（ATAM）是体系结构评估中应用最为广泛的方法。ATAM根据非功能性需求评估软件体系结构，例如可伸缩性、安全性和性能。这些非功能性需求或是质量属性经常是在全局分析产生的因素表中所确定的因素 在全局分析中制定的设计和项目策略是ATAM复查小组的好的输入。随着有关不同的体系结构风格问题的提出，你可以在复查中讨论并确认这些策略风险分析风险分析(1/2)风险由

34、条件、结果以及周围的环境构成。在软件项目计划方面，风险可能是技术、政治、经济、资源或是其他一些事件，可以对项目开发、市场占有率或是达到项目目标（如尽速、预算、质量）造成灾难性的后果 项目经理对风险的计划、预期和反应的技能将直接影响项目的成功。应将风险缓解加入软件开发计划的任务中，以便于减少风险对项目产生负面影响的可能性 风险分析试图定量地分析一个特定的风险发生的可能性。风险分析工作是收集和考虑全局分析和ATAM复查中得到的问题，或是其他类型的体系结构评估方法得到的问题 问题卡片记录了全局分析得到的问题 ATAM简档记录了ATAM得到的风险，通常是由复查小组制作的演示图风险分析风险分析(2/2)

35、当开发新的产品来取代现有产品时，可能需要一个单独的风险缓解计划，既讨论技术风险也讨论市场风险及相关缓解方案 可能的策略：你也许需要对开发新产品这一计划保密 如果你的用户都得知了你的项目，他们也许会决定等用新的产品，而不再投资购买现有的产品。这有可能对现有产品的销售产生负面的影响 向用户保密可能会造成失去及时得到用户反馈的机会，而要等到最终产品发布之后 产品发布可能与交易联系在一起，这也许需要在发布之前有一个增量的版本，使得产品可以示范给潜在的用户开发项目策略开发项目策略 对问题、风险以及风险缓解的分析有助于制定项目策略及目标。每一个项目应该对满足进度、质量和功能目标之间的相对优先级有一个清楚的

36、说明 实例：IS2000项目的项目目标 满足进度要求比质量要求的优先级更高，质量要求比功能要求的优先级更高 项目经理对目标的说明：“我必须满足发布的进度要求，我的软件质量看起来不错，但是我未能提供一些简单的功能。不管怎样，让我们先把产品发布出去吧。”对项目目标的简短说明有助于小组成员牢记他们正在努力实现的目标。这些目标应该记录在软件开发计划中，并根据需要在开发过程中加以修改全局分析和版本发布计划全局分析和版本发布计划 定义了风险、风险缓解和项目目标，这些确实有助于制定版本发布计划。因为版本发布计划将转化成关于开发任务的进度计划，注意开发任务的次序将进一步缓解风险 在版本发布计划的过程中，需要将

37、功能特性映射到工程版本，以描述这些功能的实现序列的计划全局分析和软件开发计划全局分析和软件开发计划 软件开发计划是用于计划开发的主要依据，并在每一次开发增量前，由项目经理更新 由全局分析得到的问题、策略、项目策略结论以及关于风险和可能的缓解计划的列表均记录在SDP SDP是一个非常重要的文档，因为各次工程发布之间间隔时间并不长，在项目经理委托开发小组按照规定的发布日期开发下一个版本之前，每个小组成员都需要重温SDP 在重温SDP时，小组成员通常马上跳到相应的进度表，查看下一个增量版本的任务分配 定期地更新文档使得项目经理可以修改、补充或是更好地交流重要的风险和策略对测试计划采用全局分析对测试计

38、划采用全局分析 系统测试计划的首要依据是系统的需求说明。系统的测试小组主要是测试系统能否成功地实现功能需求。因此，他们的兴趣主要集中在产品的影响因素上 由全局分析得到的问题卡片有助于对测试计划提供重要的输入。如果有与产品功能相关的关键问题，这些问题是系统测试需要重视的地方 例如，对于人为风险高的部分，将会设计更彻底的测试用例内容内容1.内容简介2.以体系结构为中心的软件项目计划3.全局分析4.管理5.项目组织6.建立项目文化和小组7.软件项目经理的角色8.权衡和项目决策9.增量式开发10.创建可视性与避免意外11.在激烈的竞争中保持冷静12.需关注的度量13.什么是“出色的工作”14.总结引子

39、：管理层的期望引子：管理层的期望 实例：在IS2000项目中，管理层对于正在设计的软件体系结构的潜在开发费用表示担忧 每天都要多次被问及实现所需的工作量有多大，因此不得不在体系结构小组与管理层之间进行交流 如果提供的估算值过高，会使管理层感到沮丧；如果提供的估算值过低，会增高期望值，给开发小组带来额外的压力“正确的”答案是一个切实的估算值，这只有在我们有足够的时间进行需求分析，并提交一份有信心实现的体系结构时才能说明 项目经理需要合适的时间进行项目计划，未经计划的软件项目难以成功实现。项目计划的活动应在被称为“项目高层设计阶段”的期间进行 在项目计划的过程中管理期望值。如果管理层在项目的开始阶

40、段期望正确，则有可能制定切实可行的开发计划，并在整个开发过程中得到支持何时计划及何时提交何时计划及何时提交(1/2)对于以体系结构为中心的软件项目计划，项目计划应与体系结构设计并行。大约5%的开发预算以及20%的开发时间用于高层设计阶段 对项目进度和开发成本进行早期估算，通常给项目经理造成很大的压力 在高层设计阶段，项目经理同体系结构小组的成员一起探究各种情况，在队伍规模、进度计划以及开发成本之间加以权衡。项目经理也同管理层一起探究软件开发有关的业务和组织的限制，但在体系结构设计的过程中，项目经理应该只明确各种场景，而不是讨论具体的计划 一旦制定、存档和复查了最初的体系结构设计，项目经理就可以

41、考虑提交开发计划何时计划及何时提交何时计划及何时提交(2/2)计划提交是非常关键的环节 经理层同意支持项目并提供相应的资源 项目经理同意按照计划管理 开发组同意生产产品向上的管理向上的管理(1/2)当项目经理正在考虑开发产品的各种情形和策略，投向结构小组忙于设计体系结构时，管理层通常已经迫不及待地想了解开发的成本及何时可以得到产品。尤其是，市场和销售经理试图得到任何有关产品功能和可用性的信息，以提供给关键的用户 在这种环境下，非常重要的是对于项目小组正在考虑的各种项目开发情景的细节，应限制与外界交流。以使与管理层分离的体系结构小组能够更好地制定计划并得到管理层的支持 项目经理和首席软件架构师必

42、须完全相信他们能充分实现项目计划。无论项目经理或是首席软件架构师缺乏这种基本信心，项目都注定要失败。所有的小组成员都必须在某种程度上也具有这种信心，但他们通常是在项目经理和首席软件架构师的领导之下向上的管理向上的管理(2/2)如果项目经理认为受到压力而必须提交一份他认为不可能实现的计划，那么项目经理必须准备离开该项目 这一点最好在开发开始之前就认识到，而不是在开发失败、未能达到项目目标后才认识到。如果项目经理的管理层不接受他建议的计划，他最好在高层设计阶段结束时离开项目，并推荐任命其他的项目经理来接管。如果管理层认识到项目经理希望按期完成任务并对其承诺很严肃，通常他们愿意接受提交的计划 大多数

43、的美国项目经理努力在小的偏差范围内达到项目目标，他们倾向于用苛刻的目标挑战自我及其项目小组，并且在努力实现这些目标的过程中感到满足 项目经理是否正确地确定期望，并始终如一地实现承诺，是项目经理需要逐渐学会与上级沟通的方法横向的管理横向的管理 项目经理还需管理对等平行机构的期望，这是在开发过程中需要处理的，包括诸如系统测试、软件质量管理、用户文档、产品管理、市场以及销售等 在很多情况下，项目经理需要这些相关功能部门的合作与支持，但是他对其活动不能直接控制和管理。因此，由于缺乏控制权，项目经理必须通过增加交流加以补偿，以明确项目的需求以及他的期望 项目经理与支撑功能最常见的交流就是系统测试。采用增

44、量式的开发方式，项目经理需要每48周对增量版本进行系统测试 另一个重要的接口是负责定义产品功能的人员，他们通常兼有产品管理、市场或系统工程功能。如果这个角色被称为产品经理，项目经理需要与他建立密切的工作关系，包括经常讨论和细化产品计划或是实现的功能特征信息流信息流 对于项目管理，在高层设计阶段，需要管理与项目有关的期望，包括与上级的关系及横向的交流，在这中间，重要的是管理信息流产品经理首席软件架构师项目经理测试经理研发管理层业务管理层体系结构设计小组特征计划项目计划测试计划项目技术设计内容内容1.内容简介2.以体系结构为中心的软件项目计划3.全局分析4.管理期望5.项目组织6.建立项目文化和小

45、组7.软件项目经理的角色8.权衡和项目决策9.增量式开发10.创建可视性与避免意外11.在激烈的竞争中保持冷静12.需关注的度量13.什么是“出色的工作”14.总结项目组织项目组织 有多人参与的项目需要加以组织，以使得每一个小组成员都有特定的角色和交流途径 小组成员的技能不同，有些是专家，有些仅是普通技术人员 有些是经验丰富的软件件开发人员，有些则是新手 项目经理必须建立好项目的组织结构，以便圆满地完成任务产品的开发 有一种方便的方法定义项目的组织，即根据正在开发的产品的软件体系结构利用软件体系结构定义项目组利用软件体系结构定义项目组织织 体系结构的模块视图不仅为项目经理提供了一个构件的列表，

46、用以估算开发成本，还洞察了开发组织方式 模块视图描述了软件系统是如何分解为各个子系统和功能模块的。我们可以将此视图映射到项目组织，使项目组织反映体系结构，这有助于在项目中加强体系结构的概念，并根据小组成员所擅长的工作，分配各自的角色 在实际的项目中，体系结构层次图与项目的组织结构之间不可能是完全的一一对应关系 考虑各个小组的规模，保持在7(2)个人左右 注意在项目组织中，兼职人员数量以及与此有关的一些问题 另外，还要考虑人员之间的人际关系开发过程中体系结构小组的角开发过程中体系结构小组的角色色 在项目的高层设计阶段，开发小组主要局限于体系结构设计小组和项目经理 在高层设计结束时，通常需要更大的

47、队伍来开发产品，并引入额外的小组成员，参与自底而上的估算。也就在这时，项目经理开始组建项目组 最好是由可能负责设计和开发特定功能构件的小组成员负责该构件的估算，这有利于提高进度估算的精确性及对其的承诺，同时有助于弥补小组成员不同的经验水平 建立项目小组的一种方法是，在开发组内部，任命体系结构设计小组的成员作为各开发小组的负责人 对体系结构有更清楚的理解 将体系结构知识传递到整个开发组内 有助于在开发中加强体系结构，使得开发队伍中的每一个人都了解所实现的构件在整个产品中的作用软件架构师的角色软件架构师的角色 主要职责 建立作为产品来实现的体系结构的理念 项目的关键技术顾问 制定技术决策 培训小组

48、成员 协调小组成员的工作 实现产品 次要职责 参与编程支持功能矩阵支持功能矩阵 在许多组织中，与产品开发有关的支持功能会以矩阵的形式分配给特定的项目开发组，这是因为这些功能可能为多个项目组服务，这些服务小组有可能要并行地开发产品。这对于设计和实现产品线体系结构的组织尤其适用 支持功能的分配矩阵对项目经理来说是特殊的挑战，项目经理处理功能矩阵分配和管理的最好办法是通过充分计划 项目经理必须提供给支持功能的经理产品开发计划、对需要提供支持的复杂性和规模的估算以及有可能出错的事件 项目经理必须通知所有的支持功能他们有可能受影响的软件开发计划的细节 当支持功能物理上相隔遥远时，情况有可能变得更加复杂

49、为了项目的成功，项目经理必须与所有矩阵分配的支持功能建立友好的关系和相互信赖项目经理的权力项目经理的权力 在矩阵管理中，项目经理看起来更类似于员工，而不是生产线的管理者。你对开发组成员惟一能够造成实际影响的就是，你会影响其收入及他们在组织中未来的发展 如果与分配到项目组的成员的能力相比，你的手段过于软弱，并且没有任何实际的或感觉到的权力，你将很难实现项目目标 一些项目经理将其权力的大小与其所领导的开发组的规模相混淆。非常明确的是，小型开发队伍效率更高，因为他们能更方便地交流。因此，为了使你工作更简单并更有可能实现项目的目标，最好能将队伍保持在尽可能最小的规模上系统测试和质量保证系统测试和质量保

50、证 称职的质量保证和系统测试工作可以帮助项目经理在用户之前发现产品中的错误。与软件测试工作和质量保证工作充分合作，将给项目经理带来最大的利益 项目经理和测试经理需要共同工作，以身作则，以使测试成为建设性的而不是破坏性的工作 测试人员发现的每一个错误都使得用户可以少发现一个 开发人员有责任复查和处理每一个错误，即使还要保留在产品中不能改正，也要使每个错误都得到解答 项目经理还需要与质量保证工作建立起良好的工作关系 好的计划和对项目目标的清晰交流对于保证所有人为共同的目标努力是十分必要的 如果项目目标是迅速开发出低质量的原型产品，以便从最终用户处得到反馈意见，那么，需要告知QA人员，以便他们相应地