基于UML的软件项目的过程质量保障
基本信息
- 原书名:Process Quality Assurance for UML-Based Projects
- 原出版社: Addison Wesley/Pearson
- 作者: (美)Bhuvan Unhelkar [作译者介绍]
- 译者: 曹学军 刘海燕 和华
- 丛书名: 软件工程丛书
- 出版社:电子工业出版社
- ISBN:7120000837
- 上架时间:2004-7-26
- 出版日期:2004 年7月
- 开本:16开
- 页码:320
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > UML
编辑推荐
本书探讨在基于UML的软件项目中,实施质量保障中的过程这方面的问题。过程是软件质量保障的两个主要领域之一,另一个是建模。鉴于基于UML的软件项目的质量保障的,尤其是专注于过程这一方面的文献缺乏的现状,本书应运而生了。
内容简介回到顶部↑
本书是一本专注于过程的探讨基于UML的软件项目的质量保障的图书,它简明扼要地阐述了UML的历史背景,UML定义,以及UML和实际的建模技术的相关性,通过一系列的对基于UML的CASE工具和开发过程的讲座来加深读者对采用UML进行直接和实际建模的理解。本书还特别地强调对要从事每个开发过程活动的角色的定义,重视系统开发中社会特征的重要性。
Bhuvan Unhelkar博士,是MethodScience.com的负责人,广受尊敬的咨询家、培训老师、作家和演讲者,计算机世界对象开发者的“跨机构的面向对象方法最佳使用奖”奖项的获得者,著有4本著作及大量论文、出版作品和演示作品。
Bhuvan Unhelkar博士,是MethodScience.com的负责人,广受尊敬的咨询家、培训老师、作家和演讲者,计算机世界对象开发者的“跨机构的面向对象方法最佳使用奖”奖项的获得者,著有4本著作及大量论文、出版作品和演示作品。
作译者回到顶部↑
本书提供作译者介绍
Bhuvan Unhelkar博士,是MethodScience.com的负责人,广受尊敬的咨询家、培训老师、作家和演讲家,计算机世界对象开发者的“跨机构的面向对象方法最佳使用奖”奖项的获得者,著有4本著作及大量论文、出版作品和演示作品。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第ⅰ部分 为软件质量保障布景
第1章 质量竞赛
1.1 不确定的软件质量
1.1.1 给质量下定义
1.1.2 质量和客观努力
1.1.3 软件的特性
1.1.4 质量保障:一项独特的工作
1.2 施加到质量上的各种压力
1.2.1 预算
1.2.2 时间
1.2.3 功能
1.2.4 质量
1.3 质量层次
1.3.1 数据质量
1.3.2 代码质量
1.3.3 模型质量
1.3.4 过程质量
1.3.5 管理质量
1.3.6 质量环境
1.4 质量软件过程
第1章 质量竞赛
1.1 不确定的软件质量
1.1.1 给质量下定义
1.1.2 质量和客观努力
1.1.3 软件的特性
1.1.4 质量保障:一项独特的工作
1.2 施加到质量上的各种压力
1.2.1 预算
1.2.2 时间
1.2.3 功能
1.2.4 质量
1.3 质量层次
1.3.1 数据质量
1.3.2 代码质量
1.3.3 模型质量
1.3.4 过程质量
1.3.5 管理质量
1.3.6 质量环境
1.4 质量软件过程
译者序回到顶部↑
本书针对应用UML技术进行开发的软件项目.的过程质量保障方法做了系统阐述。
UML,统一建模语言,作为一种被业界广为接受的可视化建模语言,现在正在被越来越多的国内信息技术工作者应用到了各种规模的软件项目的实践工作中。正如书中作者所指出的,UML不仅仅可以采用一种标准的机制来描述问题空间、解决方案空间及背景空间中的模型,还可以通过标准的可视化图形元素和规范的文档规格说明的结合充当一种直观、准确的交流媒介,方便软件项目中的各种主要角色对项目目标划定、功能需求分析、架构设计、详细设计、系统部署、系统测试、配置和维护工作的各项成果的表达和认知。我想不会有人否认UML的良好应用一定能够提升团队的软件开发过程的规范化程度,从而最终提升软件产品的质量。但是,正如作者本人所提到的,在基于UML的软件项目开发方法的各种探讨充斥了各种软件工程及信息技术图书和教材的时候,我们很少能够看到就UML和软件质量进行深入分析和系统探讨的作品。而本书恰恰填补了这样一个空白。
作为从事了多年软件项目开发实践的译者本人来说,对软件产品的质量特征不确定性的理解和本书作者在本书第一部分的精彩开场论述是不谋而合的。作者就质量和软件产品质量的理论探讨为后文充分展开讨论软件产品的过程质量保障奠定了很好的基础。
在对质量做了概念和理论分析之后,作者随后用了4个单节的篇幅分别介绍了质量环境、质量过程的体系架构、质量软件过程的实施和基于UML的项目估算和度量。这4个章节也就构成了本书的第二部分。其中在质量环境这一章中主要围绕质量职能管理进行讨论,作者分析了质量管理、质量职能体系的组织构成、软件项目质量环境中的软因素、项目社会学、软件项目中的相互影响分析、流行的质量技术,然后对质量、标准和CMM过程标准体系做了一下介绍;接下来在针对质量过程体系架构的讨论中,作者采用了图形化表示方法对构成质量过程的各个基本部件做了一一拆解分析;在第二部分的最后,作者对如何在基于UML的项目中进行估算和度量做了讨论,这些为我们采取量化分析方法来考察一个基于UML的软件项目提供了很多很好的参考建议和方法指导。
在本书的最后一个部分,作者用了一章的篇幅来围绕测试总结了基于UML的软件产品的质量控制技术。
本书主要由曹学军、刘海燕、和华、刘宏伟等人翻译;最后由曹学军做了整体内容的校订。本书翻译过程中得到了博文视点公司的孙学瑛等老师的多次指点。因译者水平所限,差错在所难免,欢迎业界同仁批评指正。
译者
2004年5月
北京
UML,统一建模语言,作为一种被业界广为接受的可视化建模语言,现在正在被越来越多的国内信息技术工作者应用到了各种规模的软件项目的实践工作中。正如书中作者所指出的,UML不仅仅可以采用一种标准的机制来描述问题空间、解决方案空间及背景空间中的模型,还可以通过标准的可视化图形元素和规范的文档规格说明的结合充当一种直观、准确的交流媒介,方便软件项目中的各种主要角色对项目目标划定、功能需求分析、架构设计、详细设计、系统部署、系统测试、配置和维护工作的各项成果的表达和认知。我想不会有人否认UML的良好应用一定能够提升团队的软件开发过程的规范化程度,从而最终提升软件产品的质量。但是,正如作者本人所提到的,在基于UML的软件项目开发方法的各种探讨充斥了各种软件工程及信息技术图书和教材的时候,我们很少能够看到就UML和软件质量进行深入分析和系统探讨的作品。而本书恰恰填补了这样一个空白。
作为从事了多年软件项目开发实践的译者本人来说,对软件产品的质量特征不确定性的理解和本书作者在本书第一部分的精彩开场论述是不谋而合的。作者就质量和软件产品质量的理论探讨为后文充分展开讨论软件产品的过程质量保障奠定了很好的基础。
在对质量做了概念和理论分析之后,作者随后用了4个单节的篇幅分别介绍了质量环境、质量过程的体系架构、质量软件过程的实施和基于UML的项目估算和度量。这4个章节也就构成了本书的第二部分。其中在质量环境这一章中主要围绕质量职能管理进行讨论,作者分析了质量管理、质量职能体系的组织构成、软件项目质量环境中的软因素、项目社会学、软件项目中的相互影响分析、流行的质量技术,然后对质量、标准和CMM过程标准体系做了一下介绍;接下来在针对质量过程体系架构的讨论中,作者采用了图形化表示方法对构成质量过程的各个基本部件做了一一拆解分析;在第二部分的最后,作者对如何在基于UML的项目中进行估算和度量做了讨论,这些为我们采取量化分析方法来考察一个基于UML的软件项目提供了很多很好的参考建议和方法指导。
在本书的最后一个部分,作者用了一章的篇幅来围绕测试总结了基于UML的软件产品的质量控制技术。
本书主要由曹学军、刘海燕、和华、刘宏伟等人翻译;最后由曹学军做了整体内容的校订。本书翻译过程中得到了博文视点公司的孙学瑛等老师的多次指点。因译者水平所限,差错在所难免,欢迎业界同仁批评指正。
译者
2004年5月
北京
前言回到顶部↑
质量是主观判断1
本书探讨在基于UML的软件项目中,实施质量保障中的过程这方面的问题。过程是软件质量保障的两个主要领域之一,另一个是建模。鉴于基于UML的软件项目的质量保障的,尤其是专注于过程这一方面的文献缺乏的现状,本书应运而生了。
这是因为,尽管UML的文献资料现在非常流行,但还是需要一些讨论UML在项目中的应用的质量和实践问题的图书。虽然我们现在已经有了一些非常优秀的论述软件开发过程的文献(其中包括由Jacobson等人创作的最为著名的《The Unified Process》,以及由Ian Graham等人撰写的《The OPEN Process Specification》),但是看起来还是缺乏单独的针对质量做探讨的图书。
另一方面,像Binder的《Testing Object Oriented Software》这样的作品,关注的是采用UML表示法进行的技术层面的测试内容。当然,我们不能责备上述提到的文献缺少对质量方面问题的讨论,因为这些作品并不是专门致力于讨论质量的。这些让人尊敬和受到广泛欢迎的作品的关注焦点要么是开发,要么是测试。而在您手中的这本书就填补了在UML领域对质量问题的关注空缺。
好的质量包括了所有能够满足用户需要的各个方面的内容。不过,“好”是一个主观色彩非常浓厚的词。对质量做出判定的参考点取决于时间、地点和形势,而所有这些都随时会发生变化!因此,能够产生好质量的基本要素是:
一个能够满足用户不断变化的需求的产品;
一个能够使创建、验证、确认这样一个产品成为可能的开发过程;
一套能够建立良好沟通的通用机制;
对生产产品的开发过程的连续不断的改进。
当这些要素应用到软件开发领域中时,这些质量上的需求就变成了生产的软件产品必须能够在规划、扩展和变更等各方面满足客户的需求——主要是业务方面的。我们不仅需要能够生产出这样的软件产品的开发过程,而且需要能够对这些用来构建软件产品的模型和过程做有效检查和交叉查证。我们同样也需要建立、遵循和查证所有的过程步骤,以期能够建立一套可以生产高质量软件产品的成熟过程体系。这些过程步骤必须以一种迭代式的、渐增的、充分的方式进行。
过程步骤必须足够灵活,以适应不同的开发环境和不同类型与规模大小的软件项目。这些都是专门化的与过程质量相关的工作领域的内容,这些内容对于本书所探讨的在项目中实施UML技术而言是必需的。这些质量方面的工作包括如何组织整个质量职能体系,还包括验证和确认这些UML框图所需的步骤,以及什么时候实施这样的验证,如何理解质量工作的结果数据,应该由谁来负责创建和确认UML框图,如何建立质量控制(测试)策略。
这些过程步骤将促成高质量的模型产生。通过对软件模型实施质量检查也能够进一步提升质量,从而确保它们句法正确、语义一致和美学上和谐。如果希望了解对于UML框图的模型质量的详细分析和讨论,我推荐读者阅读《Model Quality Assurance of UML-Based Project》。
本书分为6章,内容概述如下表所示。
章 说 明
1.质量竞赛 建立背景理论和有关质量方面的论点
2.质量环境:质量职能管理 质量管理,团队组建,高质量团队的社会学和心理学特性;过程的重要性
3.质量过程体系架构 过程组件由能够组成一个质量软件过程体系的活动、任务、交付品和角色构成
4.实施质量软件过程 实践中的质量过程、迭代、渐增和并行的软件开发
5.基于UML的项目估算和度量 一些针对实际的基于UML的软件项目的时间、预算和人员的估算建议
本书探讨在基于UML的软件项目中,实施质量保障中的过程这方面的问题。过程是软件质量保障的两个主要领域之一,另一个是建模。鉴于基于UML的软件项目的质量保障的,尤其是专注于过程这一方面的文献缺乏的现状,本书应运而生了。
这是因为,尽管UML的文献资料现在非常流行,但还是需要一些讨论UML在项目中的应用的质量和实践问题的图书。虽然我们现在已经有了一些非常优秀的论述软件开发过程的文献(其中包括由Jacobson等人创作的最为著名的《The Unified Process》,以及由Ian Graham等人撰写的《The OPEN Process Specification》),但是看起来还是缺乏单独的针对质量做探讨的图书。
另一方面,像Binder的《Testing Object Oriented Software》这样的作品,关注的是采用UML表示法进行的技术层面的测试内容。当然,我们不能责备上述提到的文献缺少对质量方面问题的讨论,因为这些作品并不是专门致力于讨论质量的。这些让人尊敬和受到广泛欢迎的作品的关注焦点要么是开发,要么是测试。而在您手中的这本书就填补了在UML领域对质量问题的关注空缺。
好的质量包括了所有能够满足用户需要的各个方面的内容。不过,“好”是一个主观色彩非常浓厚的词。对质量做出判定的参考点取决于时间、地点和形势,而所有这些都随时会发生变化!因此,能够产生好质量的基本要素是:
一个能够满足用户不断变化的需求的产品;
一个能够使创建、验证、确认这样一个产品成为可能的开发过程;
一套能够建立良好沟通的通用机制;
对生产产品的开发过程的连续不断的改进。
当这些要素应用到软件开发领域中时,这些质量上的需求就变成了生产的软件产品必须能够在规划、扩展和变更等各方面满足客户的需求——主要是业务方面的。我们不仅需要能够生产出这样的软件产品的开发过程,而且需要能够对这些用来构建软件产品的模型和过程做有效检查和交叉查证。我们同样也需要建立、遵循和查证所有的过程步骤,以期能够建立一套可以生产高质量软件产品的成熟过程体系。这些过程步骤必须以一种迭代式的、渐增的、充分的方式进行。
过程步骤必须足够灵活,以适应不同的开发环境和不同类型与规模大小的软件项目。这些都是专门化的与过程质量相关的工作领域的内容,这些内容对于本书所探讨的在项目中实施UML技术而言是必需的。这些质量方面的工作包括如何组织整个质量职能体系,还包括验证和确认这些UML框图所需的步骤,以及什么时候实施这样的验证,如何理解质量工作的结果数据,应该由谁来负责创建和确认UML框图,如何建立质量控制(测试)策略。
这些过程步骤将促成高质量的模型产生。通过对软件模型实施质量检查也能够进一步提升质量,从而确保它们句法正确、语义一致和美学上和谐。如果希望了解对于UML框图的模型质量的详细分析和讨论,我推荐读者阅读《Model Quality Assurance of UML-Based Project》。
本书分为6章,内容概述如下表所示。
章 说 明
1.质量竞赛 建立背景理论和有关质量方面的论点
2.质量环境:质量职能管理 质量管理,团队组建,高质量团队的社会学和心理学特性;过程的重要性
3.质量过程体系架构 过程组件由能够组成一个质量软件过程体系的活动、任务、交付品和角色构成
4.实施质量软件过程 实践中的质量过程、迭代、渐增和并行的软件开发
5.基于UML的项目估算和度量 一些针对实际的基于UML的软件项目的时间、预算和人员的估算建议
序言回到顶部↑
当我答应为本书写序时,我以为我需要在一片充满了行业术语的泥塘里奋力前行。我之所以愿意做这件事,仅仅因为统一建模语言(UML)在得克萨斯州加兰雷第恩这个地方是一门广为采用的语言,我希望能够借这个机会扩展我对UML的认知。坦白地说,我必须承认我是带着一种畏惧的心理开始阅读本书的,阅读过程中同时萦绕在我脑海里的还有一个非常基本的问题:如果不是想对UML是什么有更多的理解,我为什么要搭理它?
作为一名软件工程主管,我几乎不需要对开发语言和工具做详尽的了解,何况这些辅助开发的东西几年就会大变样。不过,UML显然抓住了软件工程师们的眼球,因此我拿起了这本《基于UML的软件项目的过程质量保障》。我说服自己的理由是,至少质量保障和开发过程这几个词是我所熟悉的,这些内容也是我的整个工作的一部分。
接下来发生的事令人吃惊:我一拿起书竟然就不能释手了。图书开篇提出的“质量天生就不确定”的观点和我自己的看法完全一致,而且这些观点表述得非常到位(常常带着幽默)。对UML的历史背景(Booch,Jacobson和Rumbaugh创建了UML)、UML的定义(一种通过标准的表示法、框图和规格说明,对面向对象的软件成品进行可视化描述、构建和编制文档的方法),以及UML和实际的建模技术之间相关性的阐述,简明而扼要。本书通过一系列的对基于UML的CASE工具和开发过程的讨论来加深读者对于采用UML进行直接和实际建模的理解,这些内容对于需求建模、测试、系统设计、数据库设计及架构设计也很有帮助。在我阅读本书的过程中,把这些内容归结为如下一些主要的观点:
■ UML的标准化对于大型程序来说是一件好事。
■ UML支持包括需求、测试、设计和实现在内的主要的程序开发活动。
■ UML在降低复杂性和增强测试可靠性方面的能力非常突出。
■ UML所致力解决的是系统开发中可能会遇到的大多数重大问题,尤其是提高用户预期的满意度方面的问题。
■ UML有助于缓解和解决一些长期困绕我们的问题,这些问题和软件的无形性有关。
■ UML有助于澄清系统内部之间的相关性问题,这些问题在系统集成领域是非常常见的。
■ UML并不是一个不可拆分的结构。它在问题、解决方案和背景(架构)建模空间中有着不同的适用性和应用。
■ 迁移到UML所需的转变必须仔细筹划和处理,你需要特别将UML技术和使用UML的CASE工具与开发过程分离开来看待。
在读完本书第一部分的时候,我已经成为一名UML和Bhuvan Unhelkar的写作风格的爱好者了。读者非但没有把UML看成是只有少数掌握了最深奥技能的专家和核心程序员们才能理解的神秘软件技术,反而开始认识到UML是一个能够创造附加价值的工具。在寻求高质量的过程中,UML能够支持从降低复杂性、澄清需求到为设计和集成过程增加结构性要素等一系列的系统开发工作。
本书的一个重要观点就是要从整个程序开发周期的角度来看一幅“大图”。Unhelkar把UML放到了每一个建模空间,以及为支持每个建模空间所进行的每个开发过程之中加以讨论。本书的一个特别之处就在于,它特别强调对要从事每个开发过程活动的角色的定义。
许多技术图书主要关注的是“做什么”,“什么时候做”和“如何做”,却常常忽略了“谁去做”。在本书中,Unhelkar认识到了系统开发中社会性因素的重要性。根据我自己的经验,我也已经看到了系统开发程序经理开始把程序开发人员的社会性特征及工作态度作为判定和管理程序开发的成本、进度和质量约束的一种有效参数。
从传统角度来看,系统开发基本上按照技术和方法两条线来组织。尽管现实中大量的项目失败都是由于糟糕的沟通所致,但是包括沟通在内的项目成功的非量化因素都被忽视了。程序经理们关注的是质量、进度和成本这三方面的因素。Unhelkar鼓励读者也关注一下位于这些约束条件之下的第二个层面上的要素,即人员、技术和过程。在解释清楚UML不是一种开发过程之后,本书将主要精力集中在带有各自角色、职责、活动、任务和交付品,并且能够生产出基于UML的工作成品的过程组件上。
Unhelkar清楚地认识到,人员因素是建立高质量的软件系统的关键,对人员的培训、组织、授权和管理是生产高质量系统的基本条件。对系统开发人员和系统用户等人员因素的强调在本书中随处可见。举个例子来说,Unhelkar就谈到;“对质量问题的正确研究必须深入到科学的其他分支中,如心理学、社会学和社会科学等。”
要想开发出一个系统,工程方面与非工程方面的许多条件都必须具备。对于那些非技术的条件,本书探讨到的内容包括理解用户、建立信任关系、评估和选择组件供应商、建立成本估算、准备测试计划、在质量和成本之间取得均衡、在系统重用和满足客户个性化需求与系统质量/成本/进度之间权衡、管理系统配置、实施灵活设计,以及选择和使用恰当的度量指标等。
显然,寻找一个能够充当系统开发中所有必需角色的工程师虽说不是不可能,但至少也是一个非常困难的任务。解决问题的办法在于,能否组建一支由多个成员组成的团队,这些成员有着互为补充的技能,这些成员的技能组合能够覆盖所有必需的角色。那些能够影响组建这样一支能力互补的高效团队的问题有:项目规模:团队成员是否分散在不同地方;由于缺乏面对面交流导致的内部沟通问题等。
本书关注的是组建团队的方法、多样性的价值,以及在一个虚拟环境中会产生的各种问题。Unhelkar也对团队成员做了概要描述以帮助每一个人能够选择和他们的技能及兴趣相一致的角色。行业专门知识和指导被作为提高团队凝聚力的一种辅助工具来探讨。
Unhelkar对指导工作的价值的认可,在他写本书的过程中已经表露无遗。看上去他对使用一堆行业术语来影响读者并不感兴趣,相反,他把读者定位在学习有关UML的知识、在一个过程框架下通过应用UML来了解它和
作为一名软件工程主管,我几乎不需要对开发语言和工具做详尽的了解,何况这些辅助开发的东西几年就会大变样。不过,UML显然抓住了软件工程师们的眼球,因此我拿起了这本《基于UML的软件项目的过程质量保障》。我说服自己的理由是,至少质量保障和开发过程这几个词是我所熟悉的,这些内容也是我的整个工作的一部分。
接下来发生的事令人吃惊:我一拿起书竟然就不能释手了。图书开篇提出的“质量天生就不确定”的观点和我自己的看法完全一致,而且这些观点表述得非常到位(常常带着幽默)。对UML的历史背景(Booch,Jacobson和Rumbaugh创建了UML)、UML的定义(一种通过标准的表示法、框图和规格说明,对面向对象的软件成品进行可视化描述、构建和编制文档的方法),以及UML和实际的建模技术之间相关性的阐述,简明而扼要。本书通过一系列的对基于UML的CASE工具和开发过程的讨论来加深读者对于采用UML进行直接和实际建模的理解,这些内容对于需求建模、测试、系统设计、数据库设计及架构设计也很有帮助。在我阅读本书的过程中,把这些内容归结为如下一些主要的观点:
■ UML的标准化对于大型程序来说是一件好事。
■ UML支持包括需求、测试、设计和实现在内的主要的程序开发活动。
■ UML在降低复杂性和增强测试可靠性方面的能力非常突出。
■ UML所致力解决的是系统开发中可能会遇到的大多数重大问题,尤其是提高用户预期的满意度方面的问题。
■ UML有助于缓解和解决一些长期困绕我们的问题,这些问题和软件的无形性有关。
■ UML有助于澄清系统内部之间的相关性问题,这些问题在系统集成领域是非常常见的。
■ UML并不是一个不可拆分的结构。它在问题、解决方案和背景(架构)建模空间中有着不同的适用性和应用。
■ 迁移到UML所需的转变必须仔细筹划和处理,你需要特别将UML技术和使用UML的CASE工具与开发过程分离开来看待。
在读完本书第一部分的时候,我已经成为一名UML和Bhuvan Unhelkar的写作风格的爱好者了。读者非但没有把UML看成是只有少数掌握了最深奥技能的专家和核心程序员们才能理解的神秘软件技术,反而开始认识到UML是一个能够创造附加价值的工具。在寻求高质量的过程中,UML能够支持从降低复杂性、澄清需求到为设计和集成过程增加结构性要素等一系列的系统开发工作。
本书的一个重要观点就是要从整个程序开发周期的角度来看一幅“大图”。Unhelkar把UML放到了每一个建模空间,以及为支持每个建模空间所进行的每个开发过程之中加以讨论。本书的一个特别之处就在于,它特别强调对要从事每个开发过程活动的角色的定义。
许多技术图书主要关注的是“做什么”,“什么时候做”和“如何做”,却常常忽略了“谁去做”。在本书中,Unhelkar认识到了系统开发中社会性因素的重要性。根据我自己的经验,我也已经看到了系统开发程序经理开始把程序开发人员的社会性特征及工作态度作为判定和管理程序开发的成本、进度和质量约束的一种有效参数。
从传统角度来看,系统开发基本上按照技术和方法两条线来组织。尽管现实中大量的项目失败都是由于糟糕的沟通所致,但是包括沟通在内的项目成功的非量化因素都被忽视了。程序经理们关注的是质量、进度和成本这三方面的因素。Unhelkar鼓励读者也关注一下位于这些约束条件之下的第二个层面上的要素,即人员、技术和过程。在解释清楚UML不是一种开发过程之后,本书将主要精力集中在带有各自角色、职责、活动、任务和交付品,并且能够生产出基于UML的工作成品的过程组件上。
Unhelkar清楚地认识到,人员因素是建立高质量的软件系统的关键,对人员的培训、组织、授权和管理是生产高质量系统的基本条件。对系统开发人员和系统用户等人员因素的强调在本书中随处可见。举个例子来说,Unhelkar就谈到;“对质量问题的正确研究必须深入到科学的其他分支中,如心理学、社会学和社会科学等。”
要想开发出一个系统,工程方面与非工程方面的许多条件都必须具备。对于那些非技术的条件,本书探讨到的内容包括理解用户、建立信任关系、评估和选择组件供应商、建立成本估算、准备测试计划、在质量和成本之间取得均衡、在系统重用和满足客户个性化需求与系统质量/成本/进度之间权衡、管理系统配置、实施灵活设计,以及选择和使用恰当的度量指标等。
显然,寻找一个能够充当系统开发中所有必需角色的工程师虽说不是不可能,但至少也是一个非常困难的任务。解决问题的办法在于,能否组建一支由多个成员组成的团队,这些成员有着互为补充的技能,这些成员的技能组合能够覆盖所有必需的角色。那些能够影响组建这样一支能力互补的高效团队的问题有:项目规模:团队成员是否分散在不同地方;由于缺乏面对面交流导致的内部沟通问题等。
本书关注的是组建团队的方法、多样性的价值,以及在一个虚拟环境中会产生的各种问题。Unhelkar也对团队成员做了概要描述以帮助每一个人能够选择和他们的技能及兴趣相一致的角色。行业专门知识和指导被作为提高团队凝聚力的一种辅助工具来探讨。
Unhelkar对指导工作的价值的认可,在他写本书的过程中已经表露无遗。看上去他对使用一堆行业术语来影响读者并不感兴趣,相反,他把读者定位在学习有关UML的知识、在一个过程框架下通过应用UML来了解它和







点击看大图

加载中...

