小软件项目开发的管理_软件开发项目审计管理员 是否好职位

小软件项目开发的管理

作者：不详

  一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的 经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。

一、小项目的特点

　大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点:
　1.项目功能相对较少
　2.开发人员较少
　3.开发周期较短
　　另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.

二、小项目开发中常犯的错误 　　

　　小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:
　　1、开发之前没有认真地进行项目可行性和工作量的估计。　　往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。
　　2、没有真正的设计过程
　　开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。

　　这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。 　　另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。
　　第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解 以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。
　　3.不经过单元测试而直接进入系统测试
　　造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。
　　殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当 调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测 试，就会很容易消除一些隐患。真可谓欲速则不达也。

三.合理的开发流程

　　合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开 发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。
　　以下我从几个方面描述一下我认为比较合理的模式.

1.需求获取

　　在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。
　　软件项目可以大致分为专用软件和通用软件两大类。
　　对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。
　　但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。
　　对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用 什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。
　　为了比较好地与用户进行交流，使用一些工具是很有好处的。 　　为了讨论用户界面，可以用VB, delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)
　　为了讨论软件运行的流程，可以采用UML的Use Case图。

2.需求分析

　　在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的 分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。
　　这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。
　　我想强调几个问题。
　　一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。 　　二是需求获取与需求分析的关系。
　　用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。
　　例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。

　　三是分析与设计过程的衔接。
　　分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程 语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设 计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。
　　对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采 用其他的平台时，便可以以这份分析文档作为开发的基础。
　　对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。
　　现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。

3.设计过程

　　设计阶段的工作包括:
　　对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。
　　定义界面部分、数据访问(数据库)部分。
　　由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。

4.编码

　　进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。

5.测试

　　如前所述，即使是小项目，也应该严格地进行测试。

四、人员的安排

　　比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用，

　　经验告诉我几条原则:
　　1.协调几个人的工作比自己完成一段编码更重要.
　　由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。
　　只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。 　　2.给每个开发人员明确的任务书.
　　不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系 统。但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。
　　3.让大家都大致熟悉设计模型.
　　让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。

主页   论坛   留言   打印   联系  

创建成功的工程 

作者：Bruce Eckel，翻译：UMLChina.Hairui 

　

Bruce Eckel，著名的计算机语言和工程专家，著有《C++编程思想》（Thinking in C++）、《Java 编程思想》（Thinking in Java）等书籍 相关网站：http://www.bruceeckel.com --译者注 

以下工程开发指导是我对决定一项使用任何语言的软件工程成功与否的决定因素的一些认识。 

1．记住往往事与愿违 

纯粹的“轶事工程”（原文为：anecdotal project，其含义不好理解，暂译为"轶事工程"，盼指正--译者）的失败几率总是存在，一些低至百分之五十而另一些高达百分之八十，但是所有的这些都表明：你失败的机会大于你成功的机会。为什么我要从这个令人丧气的预测开始我的话题呢？因为每一天开始时，我都想“今天将会不同，我今天能够完成四倍数量的事情”，尽管（在此之前）有过一系列不间断的例外。对于软件工程来说，过度的狂热往往被那些（只）关心结果人所夸大——“这一次，我们将解决以前从来没有人解决过的问题，只需付出更少的时间和更小的代价”，尽管他们知道，真正的规则是：“你只能从此三者中选择一个”。 

记住你身后高高堆积的纸牌[i]非常重要。你手中有一根包含时代力量的魔术手杖或者是挂在悬崖上，会让你做出完全不同的两个决定。如果你懂得你的处境属于后者，你将会说：“是的，这很好。但首先让我们看看我们是否能够在现有的进度和预算情况下完成这一切。” 

一个将不稳定形势和对失败的认识放到显著位置的方法是研究过去的失败。一份很好的资料是Roberts Glass（一位爱好研究崩溃的专家）的著作：《软件失控》(Software Runaways,出版信息：Prentice Hall 1998)，以及他其它的著作。此外可以阅读Tom Demarco和Tim Lister的经典之作《人件——生产性工程和团队》 (Peopleware: Productive Projects and Team,出版信息：第二版，Dorset House,1999)。 



2．切合实际地安排时间 

时间安排的“魔法”经常受到非开发人员为满足软件开发实践之外的愿望和期待而产生的想法所驱使。最近我校正了自己的时间安排策略。我先将整个工程显示脑海中，然后闭上眼睛，清理自己的大脑并让它判断这个工程大概需要多少时间。如果不考虑奇怪的技术问题、各种会议和其他分心的事物的影响，得出的这个时间居然非常合理。但我建议将这个合理的时间乘以3，或许可能是4，并且加上百分之十。如果这个估计出来的时间将让你失去市场机遇，那么考虑不要进行这个工程。如果你认为像这样计划时间不合理，那么首先请注意，大多数工程将遵循这个规律。其次，试想一下，如果你所在公司的所有工程都很成功进行会带来局面：你将拥有更多的收入；更少的程序员会因为愚昧的工程时间安排筋疲力尽而退出。 

你也许还会争论说这个时间评估技术非常没有科学性，这一点我同意。然而，所有的软件评估技术都含有臆测和直觉的成分在内，甚至连功能点（原文为：function point，若有其他正规译法，请指正）分析都需要对功能点进行猜测。我的“信封背面”技术将所有臆测结合到了一起，而不试图假装没有猜测。用更少的时间，也许产生更好的结果。但是，我的猜测是建立在我自己的经验之上的。 



3．首先让它运作起来 

当我试图进行一些无意义的事情时，我最大的创造性成功来临了。铭记最重要技巧——当你开始一个工程时，你好比已经用手指将自己挂在一个悬崖之上；然后你考虑一下能够做什么疯狂的事情简单地让你的工程运作起来。这并不意味着你需要马上投入进去并用通常的方式开始撰写代码，你只需要尽早尽快找到一个转换周期非常短的工具，用来判断你是否可以做该项工作以及你的工程可行性如何。我在后面将要提到的Python语言就是这样一种工具。 

将你的计划运作起来有很多好处。凭你的经验，你应该知道，用户只有能够开始使用你开发的东西的时候才能理解你开发的是什么，然后他们会突然产生各种念头并对该软件应该做些什么真正提出要求。一份系统说明书往往只是一份文档，人们往往不会认真地阅读，但是如果你让他们体验一个可运行的程序之后，他们就会确切地明白你的意思。更早地了解用户们真正想要什么岂不是更好？ 

事情往往会比你想象出来的要复杂四倍以上，所以对你能够完成的东西要尽可能地保守一些。无论何时，一些不可知的因素都在伴随着你的工作（这一点你可以从产品描述中一些“最”中察觉到：“最快”、“最大”、“最新”），原型的价值不能进行夸大。如果在此之前你没有做过类似的工程，那么最重要的事情是尽快地判明该工程是否可以实现，开发一个根本不能发挥作用的程序将会以浪费你的大量金钱而收场。 

最后一点，优化。要能够在这个阶段抵抗得了诱惑。牢记Donald Knuth说过的话（其中略有一点开玩笑的意思）：“不成熟的优化是所有麻烦的根源”。虽然优化是一些工程的关键因素，但是在确认程序切实可行之前一切优化都是盲目的。在最后建造系统之前浏览一遍所有的问题。每个工程都有一些你没有接触过的东西，你应该首先将注意力放到这个领域，创建一个测试程序或者原型来寻找解决问题的方法。在你知道你是否可以做到并且知道做到的难度有多大之前，你没有其他办法能够得知工程是否能够成功、如何为它安排时间以及它需要多少付出等等。 



4．使用恰当的工具 

一个工程的早期部分应该是高度探索性和实验性的，因为那个阶段是发现自己不会做什么以及如何去建造程序的阶段。寻找最适合工具的最好方法是去体验一下他们，然后摈弃其中工作效率低下的那些。例如，你可能开始的时候用的是Rational Rose，后来决定使用Visio Professional来创建视图，因为你需要Visio（或者通过Versa）提供的一些特性。 

用来做工程的恰当工具并不一定就必须是你已经了解的编程语言。当使用一种语言时，你就被局限在该语言所能表示的范围之中了。如果你是一个C++程序员，你很自然可能想用C++创建所有的工程管理和工具。但当你需要更加灵活的工具时，Perl是一种更快速的选择（甚至将考虑学习需要的时间在内）。在你的实际工程开发中，使用Python来快速造型或者甚至交付一个内嵌Python语言的应用程序将给你带来更好的局面。首先，它是免费的，所以不需要支付任何许可授权费用；同时它对C 和Java有完全兼容的接口，你可以使用Python解决所有Perl能够解决的问题，所以它是C++和Java的一种完美的辅助语言。 



5．接口的设计 

在C++中，接口是一个包含所有虚函数的类；而在Java中接口技术被直接支持；在COM和COBRA中，你没有其他选择，你和所有的抽象打交道——所有的都是接口，没有实现。接口提供了一个更加整洁的设计方式。要想让程序员们确信这一点有些困难，但是它对将COM或者COBRA指定为构件模型非常有帮助的（COBRA技术也是与操作系统无关的技术）。它不仅仅提供了工程实现语言的灵活性，并让你能够完全地将工程切割开来。如果你打算在你的开发组或者公司之外实现你的工程的一部分，整洁的接口可以阻止任何与工程其它部分不适当的连接，同时你可以用任何语言来进行开发。你可以采取快速造型来实现所有的接口，稍后才对其中比较特别的部分进行优化。 



6．设计时充分考虑异常情况 

在C++中，异常控制并不像在Java中那样得到有力支持——这是Java在工程管理方面成功之处。在设计、代码编写和模块使用的时候往往会有一些错误，除非软件自身能够通过抛出一个异常来声明这些错误，否则你将会花费许多小时或月的时间来捕获这些问题。只有通过严谨的异常使用，你才能保证这些问题不会出其不意地让你的工程陷入困境。 



7．简洁往往付出代价 

虽然很难说服管理部门，但是“简洁”这个词是可维护性和复用性的同义词。不仅如此，一个简洁的程序让人感觉很好。但是因为我们确信软件工程是一种商业行为，目的是为了赚钱，而不是为了感觉，因此很难说简洁的程序比其他非简洁的程序更加有灵气地结合在一起。但是由于软件是一种能够赚钱的艺术实体，在美学和实用性之间必然会一场争论。 



8．人与人之间的交流是一个瓶颈 

这就是为什么小型的组队往往更加有生产力的原因。当一个工程像火焰一样失去控制的时候，将更多的程序员扔进火焰将使情况变得更糟。这也是为什么简短的小会议往往可以发挥作用而冗长的大型会议却做不到，还有为什么太深的管理机制会导致生疏的原因。参阅《人件》（早些时候提及过）一书了解更多的细节。 

解决交流问题的最好办法是免费的：在一台废弃的计算机上安装一个Linux服务器，你可以在几分钟内完成这项工作，自动安装将包括一个Apache网页服务器。然后将你们所有的文档，从测试分析到用户文档，拷贝到服务器上，以便每个人都能够访问到最新的信息。你可以轻松地加入Java Servlets或者Perl脚本（http://www.perl.com/）或者Python(http://www.python.org/)来收集每一页的内容，然后用一个List服务器来向所有的成员发送公告。如果你想用camera-ready格式来提供文档，你可以用Adobe Acrobat格式来代替HTML格式。如果你的工程足够大的话，指定一名成员专门负责维护服务器是值得的。 



9．制定一份计划（可以是任何类型的） 

我曾经见过许多工程在没有签订任何合同（更别说一份计划）时已经有大量资金流动。哪怕是对于一个很小的工程，你也需要某种计划，甚至它可能只是被写在一个信封的背面或者只存在于主程序员的脑海中。当工程逐渐变大，你需要一个回顾的过程。一个典型的计划包括：分析阶段（包括你打算用程序解决什么问题以及程序将完成什么）、设计阶段（程序如何完成它的任务、程序实现的组成、分析阶段预定目标是否达到的测试使用信息以及发布、安装和培训等事项）。当新的信息被收集时，这些阶段将被重复。根据工程的大小，这些步骤将被缩小或者放大，但你必须像熟悉你的编程语言一样熟悉它们。 



10．考虑外部帮助 

一种放弃：我的公司提供培训和咨询服务，因此当然我感觉这是一个好主意。然而，如果你的公司内部有经验丰富的人可以担任你的工程的顾问，你可以不必向公司之外寻求帮助。这是一种以知识为基础的商业行为，生产力最低和最高的软件工人之间的生产力差别是很大的。如果你无法雇用那些最有生产力的工人，你可以通过培训提高他们的生产力，通过咨询和代码预排来改进你的工程的分析、设计和实现。对于顾问和客户来说，有一本优秀的书籍是Weinberg的《咨询的秘密》（出版信息：Dorset House,1986） 

另一方面，我曾经见过一些工程中，使用外部的开发组队剥夺了内部的队伍的权利，该项目最后以花费更多的时间和资金收场。这将我们带到我的最后一个提示: 



11.了解永远没有银弹（原文为：silver bullets,此处直译为银弹，估计引申含义和free lunch接近）的道理 

这句谚语是由Fred Brooks发明的，对于今天仍然适用——尽管有许多“银弹”已经被发明出来了。统一建模语言（UML）就是这样一个例子：它当然是一个很好的通用词汇表和设计符号集，但是UML仅仅轻微地减少了方法学家之间的争论而已。永远不会有不劳而获的事情。你必须艰辛地计划你的对象、它们的接口和结构，然后跨越一道道障碍将工程变成成果。你必须清楚没有任何可以保证成功的方案可以依赖，同时牢记工程的失败的几率让自己更好的瞄准成功。

主页   论坛   留言   打印   联系  

成功项目管理的秘密 

摘自SDMagazine，Karl Wiegers著，UMLChina.Shids译 



在最好的情况下，管理软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。 



1. 定义项目成功的标准 

在项目的开始，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常，满足一个预定义的进度安排是唯一明显的成功因素，但是肯定还有其他的因素存在，比如：增加市场占有率，获得指定的销售量或销售额，取得特定用户满意程度，淘汰一个高维护需求的遗留系统，取得一个特定的事务处理量并保证正确性。



2. 识别项目的驱动、约束和自由程度 

每个项目都需要平衡它的功能性，人员，预算，进度和质量目标。我们把以上五个项目方面中的每一个方面，要么定义成一个约束，你必须在这个约束中进行操作，要么定义成与项目成功对应的驱动，或者定义成通向成功的自由程度，你可以在一个规定的范围内调整。相关的详细信息，请参照我的《创建一种软件工程文化》（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。 



3. 定义产品发布标准 

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与你的客户指的“质量”一致。 



4. 沟通承诺 

尽管有承诺不可能事件的压力，从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时，要有好的信誉。你的任何以前项目的数据会帮助你作说服的论据，虽然这对于不讲道理的人来说没有任何真正的防御作用。 



5. 写一个计划 

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划。困难的部分是作这个计划--思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。 



6. 把任务分解成英寸大小的小圆石 

英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确的估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。 



7. 为通用的大任务开发计划工作表 

如果你的组经常承担某种特定的通用任务，如实现一个新的对象类，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他/她必须处理的大任务的每个实例相关的工作量。 



8. 计划中，在质量控制活动后应该有修改工作 

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用作任何的修改，很好，你已经走在了本任务的计划前面。但是不要去指望它。 



9. 为过程改进安排时间 

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投资一些时间在过程改进上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100％的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。 



10. 管理项目的风险 

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。要一个软件风险管理的简要的指南，参见我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。 



11. 根据工作计划而不是日历来作估计 

人们通常以日历时间作估计，但是我倾向于估计与任务相关联的工作计划（以人时为单位）的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。 



12. 不要为人员安排超过他们80％的时间 

跟踪你的组员每周实际花费在项目指定工作的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。 



13. 将培训时间放到计划中 

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。 



14. 记录你的估算和你是如何达到估算的 

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。 



15. 记录估算并且使用估算工具 

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即产品大小，小组大小和进度安排组合起来没有已知项目成功的情况。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一试的好工具。 



16. 遵守学习曲线 

如果你在项目中第一次尝试新的过程，工具或技术，你必须认可付出短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。 



17. 考虑意外缓冲 

事情不会象你项目计划的一样准确的进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为填料，而不是明智的承认事实确实如此。指明一些以前项目不愉快的意外，来说明你的深谋远虑。 



18. 记录实际情况与估算情况 

如果你不记录花费在每项任务上的实际工作时间，并和你的估算作比较，你将永远不能提高你的估算能力。你的估算将永远是猜测。 



19. 只有当任务100%完成时，才认为该任务完成 

使用英寸大小的小圆石的一个好处是，你可以区分每个小任务要么完成了，要么没有完成，这比估计一个大任务在某个时候完成了多少百分比要实在的多。不要让人们只入不舍他们任务的完成状态；使用明确的标准来判断一个步骤是否真正的完成了。 



20. 公开、公正地跟踪项目状态 

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正操作，并且在条件允许时进行表扬。 



这些提示不能保证你的成功，但是它们将帮助你在你的项目上获得一个坚实的把手，并且保证你做了所有你可以做的事来让项目在这个疯狂的世界上成功。 

原文链接：http://www.processimpact.com/articles/proj_mgmt_tips.html

主页   论坛   留言   打印   联系  

更好地领导一个项目的诀窍

----Warren Keuffel

自：SD Magazine，Sep,1999. UMLChina.Think译

----------------------------------------------------------------------------

　技术管理就像开车。当你做得正确时，没有人注意，一旦某个环节出错，问题会接踵而来。以下是我11年来作为Interviewing Manager的Team管理体会，排名不分先后，你必须注意每一点。

1. 不要重复过去二三十年来别人犯过的错误

　这句话来自Steve Mcconnell，IEEE软件编辑和软件开发畅销书作家。Mcconnell的作品包括经典著作“Code Complete”。Mcconnell认为，“大量阅读”是避免凡重复错误的最好方法。

2. 80%的管理就是选择正确的人选

　Scott Adams, Dilbert漫画的作者认为一个好的项目经理必须创造一个人尽其用的环境。所有的项目经理都应该读一读Tom Demarco和Tim Lister的新书“Peopleware：Productive Projects and Teams”（2nd Edition, Dorset House, 1999）。

3. 总是试图雇用比你强的人

　不要让你的自负成为项目的瓶颈。组织一支聪明的队伍，给他们足够的资源和解决问题的规则，让员工自己解决问题。

4. 不要浪费时间

　Tom Bragg，Intellisys Technology Corp.的首席技术官员，认为太多的项目由于不能如期开始最后陷入麻烦。通常导致延迟的原因包括其它任务的干扰，人事变动，不准时的经理等等。

5. 最优的未必是最大的

　Tom Bragg的另一个建议是：密切注意项目开始后发生的事情。Bragg说：“计划好你的工作然后如期进行，过分紧张的工作强度反而往往导致生产率的降低，可能保持每周50小时以内的工作强度是最佳的。

6. 真实的，公正的估计

　项目经理应该避免“依照管理者的欲望修改计划”的陷阱。“一个有效的估计的特征是所估计的时间与金钱比实际情况低和高的概率相等”，Bragg说。

7. 使你的组织结构更有效率

　很多情况下，你可以采用另外一种与现在不同的组织结构。看一看Apache Web server的开发小组，他们的层次组织并不分明，却开发出了成功的产品。

8. 使用WWW上的免费工具

　从http://sunnet.usc.edu/winwin/winwin.html，你可以下载由Barry Boehm的学生开发的，能够把W理论（WinWin模型）和螺旋形模型结合起来的工具。在项目管理研究所的网址www.pmi.org，你可以下载它的联机手册。从www.spmn.com你可以看到从CMM模型出发的一些建议以及两套工具：Control Panel和Risk Radar。Control Panel是Excel表格形式，由于监测生产率和质量；Risk Radar是一个Access数据库，对项目的风险进行量化管理。

9. 不要小看老程序员

　重新训练现有的程序员比雇用新毕业的大学生要有价值。老的程序员在以往的多个项目上有丰富的经验，通过新技能的训练后，他们的经验和知识会帮助年轻的程序员（包括项目经理）节约时间和金钱。

10. 为你的项目选择定正确的工作流程

　并不是所有的项目都适用一种开发流程。Intel公司有规律地检查每个开发小组的工作质量，如果出现了延迟交付或质量问题，Intel鼓励该小组改进他们的工作流程。

11. 做好你的生存计划

....

主页   论坛   留言   打印   联系  

参与变革

 
---------发现更多可重用的过程与简单的版本控制相比，更易走向成功 

Lisa J. Roberts，译：umlchina.mirnshi(mirnshi@263.net) 



译者序：本文刊登于SDMagazine，2000年11月。论述了为什么要建立可重用过程以及从中得到的好处。译文中部分语句采用了意译，不妥之处和曲意之处请参见原文。 



对开发过程共享实施猛烈的变革和改变是个什么样子？除了可能的时间大量损失（好，其实这是很小的

可能，除了正在改变开发过程时），当它们获得了人们支持时就都会成功。 

在历史上，人民，社会的劳动者，通过联合推动了社会变革。这就是我们所满意的应用程序，MeshTV，用二维和三维的有限元网格以图形的方式可视化和分析数据。它也能处理多种不同的网格类型，提供各种方式查看数据并去除了大多数的硬件和厂商的依赖，同时以自身图形硬件的速度显示图形。MeshTV也可以并行工作，你可以想象得到这需要一些组织级别满足程序的复杂性，保持有序。最后说一点，MeshTV大约有450,000行源代码。 

这是我所作的全部描述。如果你想了解得更多，查看www.llnl.gov/bdiv/meshtv，你可以下载可执行程序、源代码和手册。 



受约束的混乱 


象许多为内部使用而开发的程序一样，在加利福尼亚Livemore的劳伦斯Livemore国家实验室，对程序必需的修改和增加超出了可用的资源。在MeshTV项目中，这导致了混乱，（on the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（译者注：这句话不好译）没有人有时间坐下来画出应用流程。我们都在实验室的里里外外，忙于我们客户的贪婪的需求。（有约150个文档用户-可能更多，实际上要靠5个兼职的开发人员支持）在我们这种状况下，这种过程导致了我们用户更多的抱怨和可靠性匮乏的程序。 

三年前，我们的职责很小（几个用户，几个开发人员，很少有广泛的应用功能）允许我们在CVS上用非常不正规的过程管理源代码。当用户数和他们需求差异增多时，相应的代码管理的复杂性也增加了。处理我们增长的工作量也变得更加困难，我们知道有些事情必须要改变了。我们决定加入到我们部门的其他开发小组中去，并使用Rational软件公司的版本控制系统—ClearCase。从此，我们过程的改进氛围（our process improvement culture）开始改变，变革的种子已经播下了 

在我们转向ClearCase前，我们小组的一位经理曾经诱导我们更多的集中在过程上，她徒劳了。她看到了增长的压力和用户的不满，她想我们应该尝试用不同的方法提高我们程序的可靠性和在用户那里的名声。不幸的是，她的话从来没有引起重视，同样我们也认识到了这点，但我们不得不忙于作完我们的工作。开发人员认为最好的情况是软件工程学所论述的那样，而在最糟和最可能的情况下，会占用大量的时间，提供众多的文档，用处不是很大。我们的一些老开发人员认为改进我们的过程没有用并且……（Some of our veteran developers saw no use for "improving our process" and would have sooner appeared in public in a tutu rather than utter such a sissy phrase.）（译者注：这句话太难译了，单词也不认识）而且俱乐部所有人，包括我也怀疑我们要收获的巨大好处。我认为CVS工作得很好，我们真的不需要更多先进的东西。 

在CVS工作的同时，ClearCase工作得更好。我认为在每个软件工程生产力上没有真正的提高，但是可以用我以前不能采用的工作方式工作。这些新的工作方法可以使管理源代码变得更容易，同时也减少了我曾经在CVS中遇到的问题。例如，我现在可以轻松的多并发地开发，我可以在我完成后可靠的归并我所作的。新特性弥补了我花在开发和学习新过程上的时间。 



真正的产出 


过渡不久，一位同事和我与一位来自苹果计算机公司的开发同行进行了一次有趣的讨论。他的工作需要产品开发过程的急迫应用，包括构建方法学和发行版本管理过程。当我们叙述我们通常随意无计划的方式时，他几乎震惊晕倒。后来的讨论，使我们惊奇的了解到了通过改进我们的过程所获得的好处。有一位经理鼓励我们是一方面，但是非同寻常的另一面是听到一位开发同行称赞他发现的好处。这是真正的产出，计算机科学风格的。 

我们对其思考的越多，我们越认识到我们需要行动。将新特性和缺少固定发行日期联系起来的狂热，导致了在发行新版本和功能性的匮乏测试间长久的延期。我们的意图是好的，我们想让我们的客户满意。然而，不知何故，我们的期望事实上很糟糕，似乎看起来我们工作得很辛苦，但是，我们听到了更多的抱怨。我们需要改变现状。 

首先，我们转换到有目的的发行版本日期，使其包含明确的更改和新的功能。像许多的内部产品，MeshTV有着明显的直接的用户（MeshTV had users who lived "right down the street."）。新特性的不同的声音淹没在所有的目标回应中，我们尝试经常性的从那些所有从会议厅走下来，停下来聊会儿天的用户那里获取要求。（这些打断也可以避免我们持续工作）荒谬的是在试图获取所有要求中，我们不能满足他们中的大多数，我们失望了。所以我们从这种方法上退回来。或者试图将所有要求放进去（可能匆忙地完成，没有更多明显的bugs）,或者针对最后的抱怨作一个改正（从而没有旧的要求）。我们需要一个载明新发行版本应体现哪些要求的计划。 

这表明另一个过程需要改进。在决定之前，我们通过将bugs报告和要改变的要求写到纸上，保证可追踪。这片纸经常“走向了所有事物的归途”，或者偶然的扔进了废纸篓，或者压在了其他所有的纸张下面。（这点上我坚信我已危险地靠近制造我自己桌面中子星）（译者注：黑洞乎）那些纸随着时间的流逝而不能理解，无心的造成了客户输入损失的结果。 

我们需要很好的保持我们改变要求的追踪，这样我们就可以为下一个发行版本选择明确的要求。在对几个产品调研后，我们购买了Pure Atria的ClearDDTS，帮助我们管理我们的改变要求，我们试图一年四次发布新版本应用程序，这作为一策略被我们采纳，这样我们就可以很快的清晰地增加新功能，不用更新得过于频繁导致没有时间测试我们的修改。为了达到结束点，我们努力选择一定量的能够在三个月内完成的工作。第一次时，因为我们没有人知道如何预测一个详细的修改需要多长时间，我们彻底失败了。幸运的是，我们可以通过ClearDDTS跟踪我们曾经预测的时间和工作中实际花费的时间，并且个别开发人员利用这些数据预测将来。在为其他版本的选择工作中，这获得了重大的成功。变革明显的站住了脚。 

我们也决定与目标发行版本并进，着手提高质量的工作。为了完成这点，我们要求所有决意要改变的要求要被不具有开发责任的其他人所验证。当我们知道其他人会检查工作时，我们就都会非常仔细，这多么惊奇。我们也开始采用Mercury Interactive’s Xrunner和内部使用的脚本开发了一个自动测试系统。将来，在我们发布一个新版本应用程序前，这些测试必须成功的测试过。 



持续的改进 


所有这些工作都以我们不能想象的方式的到回报了。我们更好地跟踪我们的改变要求，也就是我们没有丢掉它们，我们确实能跟得上用户的更新状态了。用户喜欢这点，我们也不再面对来自客户的挫折。他们也喜欢我们更频繁的更新和更加健壮的程序。 

我们正在寻找另外的方式，我们可以从改变我们过程中获得好处的方式。现在，我们正在研究软件开发成熟度模型（CMM）,看是否能通过遵从2级帮助我们提供更好的应用软件（请到http://www.sei.cmu.edu/查看更多的CMM信息）。我们可以从这种方式中获得好处，但是我们想确认通过2级认证能够编写更好的代码，不只是更多的文书工作的要求。我们的兴趣在于进步，不在于核对boxes。 

我们正在进行的另一个改变是，我们能够更容易地在我们每年四个主版本之间发布修订bugs的版本。这点可以是我们更快的转向用户的要求，平息用户的愤怒。（我们基于用户认识到的严重性和我们察觉的严重性的比较，选择哪些bugs被改正，还包括工作区存在的风格。我们在整体上也为客户整合了全部优先级的感觉） 

我们过程改革的更多惊人结果之一是不只影响了程序，更多地影响了程序开发人员。他们停止了改善用户的态度，转向提高应用程序。程序变得更可靠，发行版本变得更可预测的同时，用户对应用软件整体上也更加满意。 

但是我们不仅只关心我们的过程的改革。MeshTV的开发人员同其他的开发小组并同工作着，我们试着同其他的小组分享我们的经验，学习我们的胜利和错误。围绕我们新的过程，我们提供了四个展示，至少有一个小组已经决定采用我们的一些经验。变革在成长。 



成功孕育成功 


当管理层尝试推动改变过程时，从最初的怀疑和愤怒，我们在这个过程中经历了巨大的变革。这些曾经著名的过程都是那些所有刊物都讨论过，当作福音传授给我们的同事。当我回头看看我们的小组，我惊奇于我们从使用一个版本控制系统改变到几个可重用性、文档化过程，甚至将那些经验出售给别人。什么能够允许我们背离我们正规的商业方式 

对于我们来说，在开展新的过程中最重要的因素是一个成功的战士，他酝酿了过程改革中的兴趣。这个战士应该是一个受到尊敬的开发人员，在小组里的，因持续工作而闻名，因渴望经验的增长而受人尊重。在我们的事中，我们有二位战士，我的同事Sean Ahern和我自己。在我们兴奋于可能的好处并开始着手于一些改革后，小组的其他人信服了并跟随我们。当管理层决定了过程必须跟随时，来自小组外的压力出现了。对于外来的，组员将可能排斥它，对此我不能强调得足够多。然而，来自里受人尊敬的组成员的狂热，开发人员感到是必须听从。毕竟，这些人们事实上知道到底它象个什么样子。一旦其他团队里的人看到了真正的好处，他们就会跳进这个潮流中，变革也就会良好的进行下去。当开发人员开始思考改进过程的方式，获取真正的好处时，好戏就开始了 

你如何开始你的变革？每次一个改变。一旦明显有好处，你的同事就会加入到你的行列中，同你一起征服编程世界。

主页   论坛   留言   打印   联系  

CMM、TSP、PSP讲义稿

Blueski 

　　CMM/TSP/PSP应该是目前世界上公认的最好的软件管理模式。

    CMM提供了框架和目标，PSP针对个人进行优化，TSP针对团队进行优化。

    以下提供的是一些CMM/TSP/PSP 介绍的幻灯片。压缩为cmmtsppsp.zip，打开后共有4个文件，其中cmmtsppss.ppt是主文件，带有对其它文件的连接。

    点击下载：

    下载-->> CMM、TSP、PSP讲义稿

此致

2001-8-30制作

主页   论坛   留言   打印   联系  

开发流程中的可用性

来源：

http://www.microsoft.com/China/msdn/msdnonline/features/articles/uicycle.ASP

Microsoft Corporation
2000年10月

摘要：本文讨论反复、周期性的设计过程，包括以用户为中心进行设计的四个原则、两种类型的产品设计过程，以及可用性活动如何渗透产品开发的各个阶段并为其带来益处。

目录

·         简介

·         使用反复、周期性的设计过程

·         构思阶段

·         规划阶段

·         开发阶段

·         稳定化阶段

·         为下一版本做准备

简介

可用性测试为您带来的好处

简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您在最后的处理过程中省去重新开发这一环节。

本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、开发、稳定化以及为下一版本做准备。

在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用、易于学习，并会长期使用。

使用反复、周期性的设计过程

反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：

·         及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。

·         综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。

·         及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。

·         反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。

多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越难。

相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。

螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。

构思阶段

产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、风险评估以及项目构架。

在构思阶段，通常进行下列可用性活动：

环境研究

基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一书中所述的方法，此类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。

环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并不是不可或缺的。

环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。

竞争性测试

通过竞争性可用性测试，您可以为产品设置量化的可用性目标 — 任务完成的速度、每项任务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成任务时的性能。

竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争 — 产品必须比现有的进程更有效、更好。

进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、最重要的功能。

用户/受众分析

了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关的？”，例如：

·         计算机使用经验

·         年龄

·         接受培训的程度

·         用户群之间的社会关系

·         特殊要求（可访问性）

您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具体的群体而不是普通大众。

规划阶段

规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft Visual Basic® 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着手测试是非常值得采取的做法。

根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。

用户情况

创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。

任务分析

任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。

一些要考虑的问题和活动：

·         此环境中的任务是什么？环境研究应能帮助您找出并描述用户所执行的任务。

·         创建顺序图，描述用户执行的任务之间、用户和产品之间的相互作用。

·         在构思阶段确定功能的作用领域。提出问题：“我们要支持的具体任务是什么？”

·         与产品设计者一起创建情节串联图板或顺序简图。

启发式评估

启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困难而且成本更高。

如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，启发式评估包括以下步骤：

1.        每个评估人员都浏览数遍界面，检查各种对话框元素，然后将其与一些已知的可用性原则相比较。

2.        评估人员相互合作，将结果合并到列表中，列出用户界面中的可用性问题，并注明设计方案中违反的相关可用性原则。

3.        一旦每个评估人员都分别执行了启发式评估后，他们就集中起来将其评估结果合并在一起。

在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。

认知性遍历

认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么或用户必须进行的计算 — 认知性任务决定学习和使用您的产品的难易程度。认知性遍历可帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！

根据 Gregory Abowd 的 Performing a Cognitive Walkthrough，要进行认知性遍历活动，需要以下四个条件：

1.        对系统原型的详尽描述，例如初级规范可提供什么样的系统。这种描述不一定是完整的，但要相当详尽。诸如菜单的位置或措辞这样的细节也可能导致相当大的差异。

2.        对用户在系统中要完成的任务的描述。该任务应当是大多数用户将要执行的有代表性的任务。

3.        一个完整的、书面的操作清单，列出使用给定原型完成任务所需执行的操作。

4.        指出用户的身份，以及评估人员能够假定这些用户已具有哪一类别的知识和经验。

有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期要求合理执行这些步骤。

GOMS

GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符 (Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。

Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。

·         不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、下几秒钟？

·         操作符是指软件允许用户采取的操作。

·         方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。

·         选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。

GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用选择规则来确定在此情况下哪种方法更为适用。

卡片排序

卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。

卡片排序用于：

·         展示用户对于任务范围的总体模型。

·         展示用户如何对项目进行分组或分类的。

·         展示用户对项目之间的关系和相似性的看法。

·         将用户的概念模型转换为设计。

反复可用性测试

对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并且成本更低。

您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程师就是计算机，并且在测试的过程中与用户在一起。

在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。

如 Jakob Nielsen 所述，反复的可用性测试包括：

1.        用户和任务观察 — 观察用户，保持安静，让用户做一切通常情况下会做的操作。

2.        情况 — 使用一种可以减少功能数量、降低功能级别的建模方法。

3.        简化的对谈式测试 — 一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知测试人员”。

4.        启发式评估 — 基于基本可用性原则来评价界面。

开发阶段

开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。

在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。

真实代码测试

让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。

可用性实验室测试

在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。

注意：   作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用性测试。

稳定化阶段

当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增强功能应被记录下来，以备下一版本使用。

基准测试

对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状态。

要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用性可以较低，可记录下来在将来的版本中再作改进。

为下一版本做准备

将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许多相同任务。例如，您将进行：

·         竞争性测试 — 在稳定化阶段，这种测试是对自己的产品进行测试，以将其与先前收集的有关竞争产品的数据作比较。

·         现场研究 — 类似于环境研究（该研究是要了解“我们要做什么软件？”），使用您已构建的软件来找出存在哪些问题，可在下一版本加以解决。

·         关于事件的工具化版本研究 — 软件的工具化版本基本上用来观测软件自身并在发生事件时记录数据。您在大量会话和用户的基础上对产品进行测量以找到使用趋势。

主页   论坛   留言   打印   联系  

如何组织软件开发团队

专家、多面手还是他们的组合？

Scott W. Ambler
总裁，Ronin International
2000 年 11 月 2 日

本文来自IBM DeveloperWorks中国网站

如何构建软件开发团队取决于可供选择的人员、项目的需求以及组织的需求。本文阐述了各种团队组织的策略。

有效的软件项目团队由担当各种角色的人员所组成。每位成员扮演一个或多个角色；可能一个人专门负责项目管理，而另一些人则积极地参与系统的设计与实现。常见的一些项目角色包括：

·         分析师

·         策划师

·         数据库管理员

·         设计师

·         操作／支持工程师

·         程序员

·         项目经理

·         项目赞助者

·         质量保证工程师

·         需求分析师

·         主题专家（用户）

·         测试人员

您是如何组织项目团队的？是采用垂直方案、水平方案还是混合方案？以垂直方案组织的团队由多面手组成，每个成员都充当多重角色。以水平方案组织的团队由专家组成，每个成员充当一到两个角色。以混合方案组织的团队既包括多面手，又包括专家。

一个重要的考虑因素是可供选择的人员的性质。如果大多数人员是多面手，则您往往需要采用垂直方案，同样，如果大多数人员是专家，则采用水平方案。如果您正引入一些新人，即使这些人员都是合同工，则仍然需要优先考虑您的项目和组织。本文描述了形成团队组织的垂直、水平和混合方案，并指出了它们各自的优缺点。本次讨论的一个重要含意是您的团队组织和用于管理项目的手段之间应构成默契；任何方法上的失谐都很可能导致项目产生问题。

垂直团队组织

垂直团队由多面手组成。用例 分配给了个人或小组，然后由他们从头至尾地实现用例。

优点

·         以单个用例为基础实现平滑的端到端开发。

·         开发人员能够掌握更广泛的技能。

缺点

·         多面手通常是一些要价很高并且很难找到的顾问。

·         多面手通常不具备快速解决具体问题所需的特定技术专长。

·         主题专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。

·         所有多面手水平各不相同。

成功因素

·         每个成员都按照一套共同的标准与准则工作。

·         开发人员之间需要进行良好的沟通，以避免公共功能由不同的组来实现。

·         公共和达成共识的体系结构需要尽早在项目中确立。

水平团队组织

水平团队由专家组成。此类团队同时处理多个用例，每个成员都从事用例中有关其自身的方面。

优点

·         能高质量地完成项目各个方面（需求、设计等）的工作。

·         一些外部小组，如用户或操作人员，只需要与了解他们确切要求的一小部分专家进行交互。

缺点

·         专家们通常无法意识到其它专业的重要性，导致项目的各方面之间缺乏联系。

·         “后端”人员所需的信息可能无法由“前端”人员来收集。

·         由于专家们的优先权、看法和需求互不相同，所以项目管理更为困难。

成功因素

·         团队成员之间需要有良好的沟通，这样他们才能彼此了解各自的职责。

·         需要制定专家们必须遵循的工作流程和质量标准，从而提高移交给其他专家的效率。

混合团队组织

混合团队由专家和多面手共同组成。多面手继续操作一个用例的整个开发过程，支持并处理多个使用例中各部分的专家们一起工作。

优点

·         拥有前两种方案的优点。

·         外部小组只需要与一小部分专家进行交互。

·         专家们可集中精力从事他们所擅长的工作。

·         各个用例的实现都保持一致。

缺点

·         拥有前两种方案的缺点。

·         多面手仍然很难找到。

·         专家们仍然不能认识到其他专家的工作并且无法很好地协作，尽管这应该由多面手来调节。

·         项目管理仍然很困难。

成功因素

·         项目团队成员需要良好的沟通。

·         需要确定公共体系结构。

·         必须适当地定义公共流程、标准和准则。

项目团队士气是项目成功的一个因素

大部分项目成功的定义说的是项目如何按时完成、是否在预算内以及是否满足用户的需要。但是，在如今要找到好的软件专业人员都非常困难，更不用说留住他们的这种情况下，还需要将项目成功的定义扩展为包括项目团队的士气。可能在努力完成一个软件项目后，不料却因为压榨他们过度而失去了重要的开发人员，这样做可能会符合组织的短期需要，但它对构建一个高效的软件部门的长远利益来说肯定是有害的。衡量项目成功与否的一个重要手段是项目结束后团队的士气。在项目结束之际，项目团队的各个成员是否觉得他们从自己的经历中学到了一些知识、是否喜欢为这次项目工作，以及是否希望参与组织的下一个项目都是非常重要的。

主页   论坛   留言   打印   联系  

软件项目管理（CMM）经验谈

（张凤岐　2001年07月04日 （电脑商报）

编者按： 
CMM认证是当今IT界最热的话题之一，这表明中国软件企业已开始重视与软件项目管理有关的问题了。为了了解国内软件企业对软件项目管理的认识程度以及他们在软件项目管理方面的具体做法，日前，记者采访了开思、东方通、瑞星三家纯软件公司的相关负责人。三家公司中，东方通业已开始按照CMM规范进行软件开发。在采访中，三家公司的负责人分别介绍了各自企业在软件项目管理方面的经验。开思公司的产品总监石宏峰先生还为记者详细讲解了开思公司的《产品部开发规范》。 

经过整理，我们将东方通和瑞星两家公司的负责人在采访中所说的主要内容刊登于此。我们相信，其具有一定的认识价值。另外，我们将开思公司《产品部开发规范》的一部分也刊登于此——我们并不认为开思的规范就是最好的规范。对软件项目管理而言，普适性是不存在的，好坏是相对的，适用不适用才是绝对的——我们相信，其具有一定的参照价值。　 


加强相关教育和培训

朱律玮（东方通科技首席软件设计师） 

杨桦（东方通科技总经理助理）　　　 

东方通科技从去年底开始为参加CMM认证（二级）做准备。拟议中正式参评的时间是今年11月。在这之前我们会请国内咨询公司的有关专家和国外的评估师进行两次预评估。 

半年多来，我们觉得一切还算顺利。起初我们担心编程人员会有抵触情绪——因为每完成一天的工作或一道工序或一个项目后都要做记录、编文档、写报告，较之以前，工作量无疑是增加了——后来看看，大家对执行CMM规范还是理解的、支持的。

按照CMM规范开展工作后，到目前为止，公司的运营成本是增加了——因为要增加管理人员、撰写文档也需要人手——但从长远看，其会带来降低成本、提高质量、提高用户满意度等好处。对此，我们确信不疑。 

与国外相比，我们在软件工程管理方面的差距不仅表现为管理体制、管理方法、管理思想的陈旧，整个软件业的落后才是根源。 

个人英雄主义情结、喜欢单打独斗是我们的民族性之一，其在软件人才身上表现得尤为明显，已成为中国软件企业做大的一个瓶颈。造成这种状况的原因，除了国内软件业的发展水平不高、软件项目规模不大和软件企业管理者自身素质不高外，还有很重要的一点，即与软件工程管理有关的教育内容几乎没有。在国外，PSP和GSP均为软件专业学生的必修课，可在国内，这两门课在学校里至今还没有开起来。国外施行的是定岗培训，比如撰写文档就是一门专业课，专门有人修它，毕业后拿它来“安身立命”，国内则是大家过独木桥，统统都学写程序。应该说，目前国内同行对软件工程管理的重要性已有了一定的认识，但在相关人员的培训上下的力气仍远远不够。 

其实人才才是最关键的。现在软件业最缺的人才之一就是产品经理，他们是软件工程管理的主角。产品经理必须具备以下素质：具有长期的软件开发经验——般来讲，要在8年以上；了解用户的需求；对产品熟、对市场熟——他可以不了解一个产品的底层技术，但必须了解其功能，能把握其发展方向；具有协调能力。总之，产品经理并不一定非常聪明，并不需要在某一方面特别突出，但要八面玲珑。这样的人才太难找了。东方通的产品经理都是自己培养的。 

CMM规范并非只适用于大型软件企业，其也适用于中小型企业。CMM规范只是一个框架、纲要性质的东西。企业在落实它时要细化一次；企业将其落实到具体的某个项目时，要再细化一次；中小企业可以不像大型企业那样将CMM规范细化得那么细，够用就好，不要教条。 

实施CMM规范、通过CMM认证有如下一些好处：确定工作流程和方式，从而使产品的质量和开发的可延续性有了保证；可以提高企业在用户中的信誉度，增加企业与强势公司竞争的筹码；可以承接国际大公司的外包项目———美国公司愿意找印度公司来承接其外包项目，就是因为印度公司对CMM规范普遍比较重视，通过CMM认证的软件企业也多；公司不再受制于人，人走了，事照做，这是一个公司成熟的表现。 


软件商业化的必要手段

谈文明（北京瑞星科技股份有限公司研发部经理） 

中国软件产业发展时间不长，虽然已有部分技术达到国际水平，但由于商业环境还不够完善，在软件技术的商业化与软件工程管理等方面，与国际同行相比，还存在差距。 

只有率先将技术先进的产品推向市场的公司才会赢得利润。在瑞星，技术商品化已被当作一种制度，它有助于提高整个企业的素质。 

瑞星意识到在充满竞争的环境中要获得成功，天才人物是必不可少的，但他们并不是全部。目前，一个软件工程的成功更多地要依靠科学家、工程师、制造人员和销售人员的协同努力。 

在软件商业化的过程之中，建立规范化的易于操作的软件开发行为规范是首先要做的工作。针对杀毒软件的特点，瑞星专门设计了瀑布模型结合增量模型的开发方式，即将项目分阶段来实现。首先实现市场最需求的核心功能，然后在此基础上继续开发，每个单独的阶段都采用瀑布模型的开发方式。 

具体地说，一个基本的软件开发流程包括需求阶段、系统设计阶段、详细设计阶段、编码阶段、单元测试阶段、集成测试阶段、系统测试阶段、软件发布软件维护阶段。其中决定软件开发成功与否的关键阶段是：软件需求管理、软件计划管理、软件质量管理和软件配置管理。 

为了在用户和处理用户需求的软件项目组之间达成共识（用户由最终用户、高层领导、销售人员和市场调研人员组成），“软件需求规格说明书”是必不可少的。经过正式的评审和确认，其将成为后续工作的基础。 

软件项目的实施过程是根据软件项目的资源、约束条件和执行能力确定的，因此需要制定合理的软件工程管理计划，这是项目经理的职责之一。项目经理应定期检查“项目开发计划书”，按照当前项目开发的实际情况，对其进行调整。 

为了保证每一个软件产品都合乎需求，需要设立一个负责项目监督和协调的SQA。其会对软件产品是否符合定义好的软件过程中的相应部分进行审查、复审和测试。公司高层主管应该定期参与、评审SQA的活动。 

软件配置管理是指在整个工程期间对项目的所有软件配置项进行规范化管理。如采用版本控制软件对软件配置项版本进行版本控制，采用基线管理方法对变化进行控制，即在遵循软件工程标准的基础上对整个软件进行控制和管理，维护其完整性、一致性和可跟踪性。 

瑞星努力营造的是一个广泛的网络，研发、制造、销售、分销和服务，连续进行。围绕着产品、市场和开发阶段而不是单纯的技术来组织各项工作。为了这个目的，标准操作是必不可少的。 


附录：开思公司《产品部开发规范》　（摘要）

说明：第一部分为《目录》，从中可以看出开思公司《产品部开发规范》的整体架构；第二部分为《开发规范概述》，从中可以看出开思公司在软件项目管理方面的一些具体做法。 

1　　目　录 

1　目的 

2　开发规范概述 

2．1　应用项目管理管理开发过程 

2．2　标准的阶段性开发工作 

2．2．1　总体规划 

2．2．2　项目立项 

2．2．3　需求分析 

2．2．4　系统分析 

2．2．5　系统设计 

2．2．6　编码实现 

2．2．7　项目测试 

2．2．8　文档制作 

2．2．9　项目验收 

2．2．10　项目版本化发布 

2．3　项目组织 

3　开发工作规范 

3．1　总体规划阶段 

3．1．1　项目需求报告 

3．1．1．1　工作定义 

3．1．1．2　前序工作及输入成果 

3．1．1．3　具体工作内容 

3．1．1．3．1　资料收集（可选） 

3．1．1．3．2　资料研究（可选） 

3．1．1．3．3　项目需求报告编制 

3．1．1．3．4项目需求报告讨论准备 

3．1．1．3．5　项目需求报告讨论 

3．1．1．3．6　项目需求报告修改 

3．1．1．3．7　项目需求报告验收 

3．1．1．4　参与者及职责 

3．1．1．5　输出成果及后序工作 

3．1．2　技术可行性实验（可选） 

3．1．3　项目计划书 

3．2　项目立项 

3．2．1　立项申请 

3．2．2　项目立项评估 

3．2．3　项目进度计划 

3．2．4　项目立项审批 

3．3　需求分析 

3．3．1　资料收集 

3．3．2　需求分析编制 

3．3．3　讨论准备 

3．3．4　需求分析讨论 

3．3．5　需求分析修改 

3．3．6　需求分析验收 

3．4　系统分析 

3．4．1　系统分析准备 

3．4．2　确定问题域 

3．4．3　需求建模 

3．4．4　建立分析对象模型 

3．4．5　系统分析合并 

3．4．6　系统分析测试 

3．4．7　系统分析修改（测试后） 

3．4．8　系统分析验收 

3．5　系统设计 

3．5．1　系统设计准备 

3．5．2　界面设计 

3．5．3　建立设计模型 

3．5．4　系统设计合并 

3．5．5　对象持久化设计 

3．5．6　详细设计 

3．5．7　系统设计测试 

3．5．8　系统设计修改（测试后） 

3．5．9　系统设计验收 

3．6　编码实现 

3．6．1　编码准备 

3．6．2　编码 

3．6．3　编码单元测试（测试工作） 

3．6．4　单元测试后编码修改 

3．6．5　编码联调 

3．6．6　集成测试（测试工作） 

3．6．7　集成测试后编码修改 

3．6．8　系统测试（测试工作） 

3．6．9　系统测试后编码修改 

3．6．10　编码验收 

3．7　项目测试 

3．7．1　系统分析测试 

3．7．2　系统设计测试 

3．7．3　项目测试方案 

3．7．4　单元测试 

3．7．5　集成测试 

3．7．6　系统测试 

3．8　文档编制 

3．8．1　开发文档整理 

3．8．2　用户文档编制 

3．8．3　宣传资料编写 

3．9　项目验收 

3．10　项目版本化发布 

4　项目工作总结 

4．1　项目任务数 

4．1．1　总任务数 

4．1．2　阶段任务数 

4．2　输出成果 

2　　开发规范概述 

2．1　应用项目管理管理开发过程 

产品部接受的各种开发任务均以项目形式出现，包括：新产品开发，产品维护（错误修改、功能增强、缺陷完善等），产品客户化开发及维护等，全程使用项目管理方法进行控制和管理。 

根据项目规模和难易有大、小，繁简之分。每个项目的完成周期要控制在6个月以内，项目规模控制在60个人月内。过大的项目需要拆分成多个小的项目来完成。30个人月以上的项目称为大项目，10个人月以内的项目称为小项目。 

每个项目要根据具体情况拆分成工作阶段，即里程碑，以便对项目进度的有效控制与检测。 

2．2　标准的阶段性开发工作 

2．2．1　总体规划 

全面规划项目工作的内容，确定目标市场、技术指标和应用要求，划定项目工作范围和交付成果，明确项目实现的总体设想和实施方案；确定项目中的新技术的可行性；明确项目需要用到的各种资源，估算项目的工作量和成本。 

2．2．2　项目立项 

产品部对要进行的开发项目进行立项申请，提交项目资料。由公司的有关人员对项目进行一系列的风险评估。 

通过风险评估的项目，由产品部进行详细进度计划安排，落实时间进度、资源（人员／设备、内部／外部）、技术、资金和费用等，相关资源和资金使用计划要详细列出。 

最后所有的项目申请资料、风险评估报告及产品进度计划都要报给公司上级领导审批，进行立项评审。 

立项通过的项目才能进入正式的开发工作。 

2．2．3　需求分析 

根据项目需求报告界定的工作范围和应用方案的设计思路，进一步深入细化应用方案，描述将要开发出计算机系统中包含的各项业务是如何做的，及业务流程、相关理论、运算公式、原理、业务数据、单据报表格式等。 

2．2．4　系统分析 

根据项目需求分析，对将要建立的满足用户需求的计算机系统进行分析。在系统分析过程中采用面向对象分析技术（OOA）划分需求的问题域，对每一个问题域进行分析和抽象，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域及其系统责任所需的类及对象，定义这些类和对象的属性与服务，以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求，并能够直接反映问题域和系统责任的面向对象的分析模型。 

2．2．5　系统设计 

根据项目需求分析和系统分析，针对具体实现中的人机界面、数据存储、任务管理等内容，运用面向对象设计技术（OOD）进行系统设计。主要包括UI设计、对象设计和数据库表设计。 

2．2．6　编码实现 

根据系统设计的结果，运用面向对象的方法进行程序编码（OOP）以实现系统设计的内容。 

编码过程就是用具体的数据结构来定义对象的属性，用具体的语言来实现服务流程图所表示的算法。在对象设计阶段形成的对象类和关系最后被转换成特殊的程序设计语言、数据库或者硬件的实现。 

2．2．7　项目测试 

对系统分析、系统设计、程序编码等运用面向对象的方法进行测试（OOT）。项目的测试工作贯穿项目的整个开发过程。主要包括：分析（OOA）测试、设计（OOD）测试和编码（OOP）测试，以及集成测试和系统测试。 

2．2．8　文档制作 

跟随项目开发过程应产生的文档主要包括三类： 

（1）开发文档：分析、设计、编码、测试以及各种开发管理文档等资料； 

（2）用户文档：在线帮助，安装指南，使用手册，技术手册，培训教材等； 

（3）宣传资料：产品介绍资料，产品白皮书，产品宣传PPT，演示光盘等。 

2．2．9　项目验收 

对完工的项目按照验收步骤进行验收。验收过程中对项目的情况给予评价。 

2．2．10　项目版本化发布 

对验收通过的项目进行版本控制，整理项目版本包含的内容并版本化，发布产品发布通告。 

2．3　项目组织 

每个项目指定一个项目经理进行管理，同时指定一个分析、设计人员（来自分析设计组）负责对技术问题的管理。当任务涉及到多个职能组的工作时（有些项目可能只涉及单一的职能组），由项目经理根据项目工作安排与职能组的组长进行协调，由职能组的组长来协助安排本组承担的项目工作，指定组内人员来完成相关工作。项目经理根据各职能组长的安排汇总编制整个项目的进度计划，并根据最终形成的项目计划对项目进行控制和管理。 

项目进行过程中需按照项目管理的要求对项目进行跟踪、总结，各职能组的人员要对这些工作给予积极的支持和配合。产品委员会（或产品部内部）不定期组织人员对项目进行审查，确保项目的进度和质量。

项目完工后需要由产品委员会组织对项目进行验收。

主页   论坛   留言   打印   联系  

实施软件质量保障体系CMM/TSP/PSP的建议

　　软件产业的发展，在经历了从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代，到90年代中期，以CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代，而软件发展第三个时代，及软件工业化生产时代，从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪，估计到2005年，可以实现真正的软件工业化生产，这个趋势应该引起软件企业界和有关部门的高度重视，及早采取措施，跟上世界软件发展的脚步。软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。软件过程改善是当前软件开发技术的核心问题。
　　　--------摘自北京航空航天大学软件工程研究所周伯生教授的《CMM评估基本要点及最新动态》学术报告

引言

　　50多年来计算事业的发展使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。软件生产转向以改善软件过程为中心，是世界各国软件产业或迟或早都要走的道路。软件工业已经或正在经历着"软件过程的成熟化"，并向"软件的工业化"渐进过渡。规范的软件过程是软件工业化的必要条件。
　　软件过程研究的是如何将人员、技术和工具等组织起来，通过有效的管理手段，提高软件生产的效率，保证软件产品的质量。

软件过程的理论研究与实践成果
n 国际
n 国内

国 际

软件过程的三个流派：
CMU-SEI的CMM/PSP/TSP
SO 9000质量标准体系
SO/IEC 15504（SPICE）

CMU-SEI的CMM/PSP/TSP

　　20世纪80年代中期国际软件产业界对软件的研究十分重视，因为在采用软件工程方法克服软件危机的过程中，人们认识到，软件是否完善是软件风险大小的决定因素。这方面的研究取得了重大的突破，其标志是1987年美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表的研究成果"承制方软件工程能力的评估方法"，该成果在1991年发展成为CMM（软件过程能力成熟度模型）。软件过程能力成熟度模型被国际软件界公认为软件工程学的一项重大成果。软件目前，软件能力成熟度模型2.0版已经修订问世。CMM在软件工程的实践方面已有很大的影响，在工业界已得到广泛接受。不仅已用于军事控制系统，而且已用于全球经济领域的主要组织。有数千个组织在利用CMM的软件过程改进。在美国，关于CMM模型的教程已经作为参考和研究的对象出现了，这样做是为了让CMM模型极其相关问题引起工业界的更密切地关注。基于CMM模型的工具如成熟度问题集，软件过程评估训练和软件能力评价训练已经在CMM中渐渐得到修订。近期的关于CMM的活动主要是发展关于CMM模型的不同版本。由于CMM并未提供有关实现CMM关键过程域所需的具体知识和技能，因此，美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发了个体软件过程PSP（Personal software process）和群组软件过程TSP(Team Software Process)，形成CMM/PSP/TSP体系。

ISO 9000质量标准体系

　　最初的软件质量保证系统是在70年代由欧洲首先采用的，其后在美国和世界其他地区也迅速地发展起来。目前，欧洲联合会积极促进软件质量的制度化，提出了如下ISO9000软件标准系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002。这一系列现已成为全球的软件质量标准。除了ISO9000标准系列外，许多工业部门、国家和国际团体也颁布了特定环境中软件运行和维护的质量标准，如：IEEE标准729-1983、730-1984、Euro Norm EN45012等。

ISO/IEC 15504（SPICE）

　　CMM的方法很快就引起了软件界的广泛关注，1991年国际标准化组织采纳了一项动议，开展调查研究，在此后引发了一系列的研究工作，现已取得重要成果，产生了技术报告ISO/IEC 15504《信息技术-软件过程评估》，预计于今年产生正式标准。从该技术报告的内容来看，其基本的目的和思路，均与CMU/SEI的CMM相似。
　　目前，学术界和工业界公认美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发的软件能力成熟度模型CMM是当前最好的软件过程，已成为业界事实上的软件过程的工业标准。

国 内

　　学术界：中国生产力促进协会、北航SEI、中科院研究SEI等科研机构已于近几年在北京、上海、广州和深圳等地先后举办过多次报告会和研讨会，组织过课程学习和应用实验，开展了软件过程方面的研究与开发工作，并发表了多篇的研究成果和学术论文，在软件质量保障平台支撑环境也取得了一定的成果。
　　产业界：近两年来，CMM在我国获得了各界越来越多关注，业界有过多次关于CMM的讨论，国务院发布的《鼓励软件产业和集成电路产业发展的若干政策》对中国软件企业申请CMM认证给予了积极的支持，在第17条规定"对软件出口型企业CMM认证费用予以适当支持。"2000年中国村电脑节上还有CMM专题论坛，吸引了众多业内人士。鼎新、东大阿尔派、联想、方正、金蝶、用友、浪潮、创智、华为、东大阿尔派等大型集团或企业等都从1997---2000年起批企业都在进行研究、实验或实施预评估。其中鼎新公司从1997年着手进行CMM认证工作。1999年7月通过第三方认证机构的CMM2认证。东大阿尔派公司于2000年10月通过第三方认证机构的CMM2认证。2001年1月，联想软件经过英国路透集团的严格评估，顺利通过CMM2认证。

　　总体上讲，国内对软件过程理论的讨论与实践正在展开，目标是使软件的质量管理和控制达到国际先进水平，中国的软件产业获得可持续发展的能力。专家分析，在未来两三年内，国内软件业势必将出现实施CMM的高潮。从这一趋势看，中国的软件企业已经开始走上标准化、规范化、国际化的发展道路，中国软件业已经面临一个整体突破的时代。

软件质量保障体系的实施

　　根据一直以来对国际上软件过程理论与实践的发展、尤其是近几年来着重在CMM、PSP和TSP以及ISO软件过程标准草案等方面的研究工作，国内专家学者建议，软件过程的改善应该从三方面着手进行：
　　o 软件能力成熟度模型CMM(Capability Maturity Model)
　　o 个体软件过程PSP (Personal Software Process)
　　o 群组软件过程TSP(Team Software Process)
三者各有侧重，但互为补充。

CMM

　　o 迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的软件过程。
　　o 为评估软件组织的生产能力提供了标准。
　　o 为提高软件组织的生产过程指明了方向。

CMM软件过程成熟度模型概要*

1、 比较
　　
　　在介绍CMM内容之前，首先概述一下不成熟软件组织与成熟软件组织的差异。在不成熟的软件单位，软件过程一般由实践者及其管理者在项目进程中临时拼凑而成，因而推迟进度和超出预算已成为惯例，产品质量难以预测，有时为了满足进度要求，常在产品功能和质量上做出让步。
　　然而，一个成熟软件组织具有在全组织范围内管理软件、开发过程和维护过程的能力，规定的软件过程被正确无误地通知到所有员工，工作活动均按照已规划的过程进行。并通过可控的先导性试验和费效分析使这些过程得到改进，对已定义过程中的所有岗位及其职责都有清楚的描述，和通过文档与培训使全组织有关人员对已定义的软件过程都有很好的理解，从而使其软件过程所导致的生产率和质量能随时间的推移得到改进。
　　表1给出了不成熟和成熟软件组织的比较，这种比较分析不仅是形成软件能力成熟模型的基础，也有利于理解该模型。
　　　

2、 CMM的一些基本概念

　　（1）软件过程：人们用于开发和维护软件及其相关过程的一系列活动，包括软件工程活动和软件管理活动。
　　（2）软件过程能力：描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。
　　（3）软件过程性能：表示（开发组织或项目组）遵循其软件过程所得到的实际结果，软件过程性能描述的是已得到的实际结果，而软件过程能力则描述的是最可能的预期结果，它既可对整个软件开发组织而言，也可对一个特定项目而言。
　　（4）软件过程成熟：一个特定软件过程被明确和有效地定义，管理测量和控制的程度。
　　（5）软件能力成熟度等级：软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。
　　（6）关键过程域：每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程域，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域，反之有非关键过程域是指对达到相应软件成熟度等级的目标不起关键作用。归纳为：互相关联的若干软件实践活动和有关基础设施的一个集合。
　　（7）关键实践：对关键过程域的实践起关键作用的方针、规程、措施、活动以及相关基础设施的建立。关键实践一般只描述"做什么"而不强制规定"如何做"。整个软件过程的改进是基于许多小的、渐进的步骤，而不是通过一次革命性的创新来实现的，这些小的渐进步骤就是通过一些着关键实践来实现。
　　（8）软件能力成熟度模型：随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力也伴随着这些阶段逐步前进，完成对软件组织进化阶段的描述模型。

3、 CMM模型概要

　　软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。
　　CMM提供了一个框架，将软件过程改进的进化步骤组织成5个成熟等级，为过程不断改进奠定了循序渐进的基础。这5个成熟度等级定义了一个有序的尺度，用来测量一个组织的软件过程成熟和评价其软件过程能力，这些等级还能帮助组织自己对其改进工作排出优生次序。成熟度等级是已得到确切定义的，也是在向成熟软件组织前进途中的平台。每一个成熟度等级为连续改进提供一个台基。每一等级包含一组过程目标，通过实施相应的一组关键过程域达到这一组过程目标，当目标满足时，能使软件过程的一个重要成分稳定。每达到成熟框架的一个等级，就建立起软件过程的一个相应成分，导致组织能力一定程度的增大。
　　下面表2给出了CMM模型概要，表中的5个等级各有其不同的行为特征。要通过描述不同等级组织的行为特征：即一个组织为建立或改进软件过程所进行的活动，对每个项目所进行的活动和所产生的横跨各项目的过程能力。
　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　表2 CMM模型概要
　
　　

4、 CMM的结构

　　
　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　
　　软件机构的最终质量保证模式可以用下图1说明，图1给出软件质量计划、质量控制、质量改进一个简单循环，其实，它归纳出CMM的真正内核，所以，可以说CMM的模型是一种新兴管理思想：连续改进（Continuos Improvement）循环的体现。
　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　图1

CMM的作用

　　n 科学地评价软件开发单位的软件能力成熟等级
　　n 帮助软件开发单位进行自检，了解自己的强项和弱项，从而不断完善和改进单位的软件开发过程，确保软件质量，提高软件开发能效率。

CMM实施的思考

　　根据CMM的基本原理、基本内容和基本方法，对CMM提出4个问题供大家思考：
　　1. 过程成熟度需要多长时间？多少费用？对企业有何好处？
　　2. 影响基于CMM的软件过程的成败因素是什么？
　　3. CMM是否会导致过度官僚主义？是否会使组织变得更保守，不愿冒风险？
　　4. 有无合适的、易理解的框架（不仅仅是告诉"我们做什么"，而且告诉"我们怎么做"）可指导所有软件组织进行CMM改进？
　　这些针对CMM提出的问题与争论，国外进行了一些调查工作，但国内基本上没有这方面的专业调查和研究，以后再根据国内企业对CMM的认识、认证的增强和增多，这些问题会得到更科学的解答。
　　现给出国外针对上述问题的一些调查结果：
　　问题1：成熟度提升一级建议安排1年到2年，费用问题国内外相距太远不好比较。对企业的好处问题给出下表说明：
　　　　　　

　　问题2：影响过程改进失败的因素有：无法实施计划和跟踪、突发事件或危险造成、时间和资源限制造成、知道应该做什么而不知道如何做造成。
　　问题3：大部分（84%-96%）不认为会使组织变成官僚主义机构、难于创新和不敢冒风险。
　　问题4：这需要不断总结经验，提出办法。

　　在国内要想取得过程改进成功，作者认为：
　　1、 软件过程改进必须有高级主管的支持与委托，并积极地管理过程改进的进展。
　　2、 中层管理的支持很重要
　　3、 责任分明，过程改进小组威望高
　　4、 基层的支持与参与极端重要
　　5、 如何利用定量的可观察数据，尽快使过程改进成果可见，从而激励参与者的兴趣
　　6、 为企业的商业利益服务，并要求有成功的过程改进相符的企业文化变革

　　如果企业出现如下情况，过程改进肯定就失败：
　　1、 高层领导机构态度不明确，见解不一致
　　2、 各部门只管自己，互不通气，互不支持
　　3、 对以前不成功的过程改进冷嘲热讽
　　4、 项目成员认为软件过程改进会影响实际工作，而不支持软件过程改进活动

　　结论：CMM不是万能的，它的成功与否，与一个组织内部有关人员的积极参与和创造性活动是密不可分的。

　　CMM是对软件工程的工业实践所需的有关目标、方法和实践的最佳有效描述。问题是如何在一个实验室或者产业环境中做到CMM规则的应用？
　　CMM是一个致力于组织过程改进的框架，问题是如何才能确保CMM使工作有效而且便利？
　　未提供有关实现关键过程域所需要的具体知识和技能。
　　因此，个体软件过程PSP(Personal Software Process)也就应运而生。

PSP概述

　　个体软件过程（Personal Software Process ,PSP）是由美国Carnegie Mellon大学软件工程研究所(CMU/SEI)的Watts s. Humphrey领导开发的，于1995年它的推出，在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。PSP是一种可用于控制、管理和改进个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。 PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段， PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。根据对参加培训的104位软件人员的统计数据表明，在应用了PSP后，软件中总的差错减少了58.0％，在测试阶段发现的差错减少了71.0％，生产效率提高了20.0％。PSP的研究结果还表明，绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的，只有很少一部分是由于技术问题而产生的。而且根据多年来的软件工程统计数据表明，如果在设计阶段注入一个差错，则这个差错在编码阶段引发了3一5个新的缺陷，要修复这些缺陷所花的费用要比修复这个设计缺陷所花的费用多一个数量级。因此，PSP保障软件产品质量的一个重要途径是提高设计质量。

个体软件过程PSP的现状

o 从1993年开始，美国、欧洲、澳大利亚等地已先后有20多所大学开设了讲授PSP的课程。
o 在工业界，PSP也先后在Motorola、 HP、 AIS等公司推广使用。
o 北航软件工程研究所于1997年开始，在北航计算机科学与工程系率先讲授了PSP课程，并组织了PSP应用实验。

个体软件过程PSP的演化*

个体软件过程PSP的内容

　　PSP与具体的技术（程序设计语言、工具或者设计方法）相对独立，其原则能够应用到几乎任何的软件工程任务之中。PSP能够：
(1) 说明个体软件过程的原则；
(2) 帮助软件工程师作出准确的计划；
(3) 确定软件工程师为改善产品质量要采取的步骤；
(4) 建立度量个体软件过程改善的基准；
(5) 确定过程的改变对软件工程师能力的影响。

个体软件过程PSP支持环境

　　北航软件工程研究所在研制的基于Internet的"个体软件过程支持环境"，支持个体软件过程的定义、运作、度量、分析和优化，支持PSP在实际软件开发项目中的应用，支持PSP概念和方法的推广普及，支持软件工作人员软件工程方面素质的提高。

个体软件过程PSP的作用

l 使用自底向上的方法来改进过程，向每个软件工程师表明过程改进的原则，使他们能够明白如何有效地生产出高质量　的软件。
l 为基于个体和小型群组软件过程的优化提供了具体而有效的途径。其研究与实践填补了CMM的空白。
l 帮助软件工程师在个人的基础上运用过程的原则，借助于PSP提供的一些度量和分析工具，了解自己的技能水平，控　制和管理自己的工作方式，使自己日常工作的评估、计划和预测更加准确、更加有效，进而改进个人的工作表现，提　高个人的工作质量和产量，积极而有效地参与高级管理人员和过程人员推动的组织范围的软件工程过程改进。

群组软件过程TSP概述

　　致力于开发高质量的产品，建立、管理和授权项目小组，并且指导他们如何在满足计划费用的前提下，在承诺的期限范围内，不断生产并交付高质量的产品。
　　TSP指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。

实现TSP方法需要具备的条件

o 需要有高层主管和各级经理的支持，以取得必要的资源
o 整个软件开发小组至少应在CMM的第二级（可重复层）。
o 全体软件开发人员必须经过PSP的培训，并有按TSP工作的愿望和热情。
o 开发小组成员应在2到20个人之间。
　　在实施TSP的过程中，首先要有明确的目标，开发人员要努力完成已经接受的委托任务。在每一阶段开始，要做好工作计划。如果发现未能按期按质完成计划，应立即分析原因，以判定问题是由于工作内容不合适或工作计划不实际所引起，还是由于资源不足或主观努力不够所引起。开发小组一方面应随时追踪项目进展状态并进行定期汇报，另一方面应经常评审自己是否按PSP的原理工作。开发小组成员应按自己管理自己的原则管理软件过程，如发现过程不合适，应及时改进，以保证用高质量的过程来产生高质量的软件。项目开发小组则按集体管理的原则进行管理，全体成员都要参加和关心小组的规划、进展的追踪和决策的制定等项工作。

按TSP原理对开发小组的基本度量要素

o 所编文档的页数。
o 所编代码的行数。
o 花费在各开发阶段或各开发任务上的时间（以分为单位）。
o 在各个开发阶段中引入和改正的差错数目。
o 在各个阶段对最终产品增加的价值。

度量TSP实施质量的过程质量元素

o 软件设计时间应大于软件实现时间。
o 设计评审时间至少应占一半以上的设计时间。
o 代码评审时间至少应占一半以上的代码编制时间。
o 在编译阶段发现的差错不超过10个/KLOC
o 在测试阶段发现的差错不超过5个/KLOC。

CMM、PSP和TSP组成的软件过程框架

　　　　　　　　　　　　

l CMM是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式。企业只有开始　CMM改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训，合理分配项目人员，　并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。
l PSP能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软　件过程和产品质量。经过PSP学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用PSP，从　而有助于CMM目标的实现。
l TSP结合了CMM的管理方法和PSP的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与　组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项　目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。

PSP和TSP对CMM的支持*

l CMM/TSP/PSP代表了目前国际上软件过程工程研究方面最先进的成果，它们对促进软件生产的科学化管理，提高软件　生产能力意义重大。
l 软件的生产过程及其它的许多子过程、软件的开发者和用户、以及系统的使用中存在着巨大的变化和不同，要使一个　软件过程对软件生产的改善真正有所帮助，其框架应是由CMM、TSP和PSP组成的一个完整体系，即从组织、群组和个　人三个层次进行良好的软件工程和管理实践的指导和支持。总而言之，单纯实施CMM，永远不能真正做到能力成熟度　的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。

建议

　　过程改善工作必然具有一切过程所具有的固有特征，即需要循序渐进，不能一蹴而就需要持续改善，不能停滞不前；需要联系实际，不能照本宣读需要适应变革，不能凝固不变。我认为，将CMM／PSP／TSP引人软件企业最有效的途径首先要对单位主管和主要开发人员进行系统的培训。Carnegie Mellon大学软件工程研究所曾尝试让软件工程师通过自学的方式来进行，但实际上，只有不到20％的人能够坚持到底。另外一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。

　　CMM就如同软件生产的一面镜子，以之来衡量自己可以折射出企业发展的水平以及具体的差距。借鉴CMM的方法，改进软件研发项目管理，提高软件开发水平。软件研发项目管理管理是影响软件研发项目全局的因素，而技术只影响局部。建议以CMM为框架，先从PSP做起，然后在此基础上逐渐过渡到TSP，以保证CMM／PSP／TSP确实在企业中生根开花。我相信只要坚持改善软件工程的管理，并在实践中总结适合自身的经验，一定能取得很好的效果。
　　不过强调一点，我们必须根据自身的实际制定可行的方案。不深入研究就照搬别的企业的模式是很难起到提高软件产品质量水平的真正目的的。

/*

本文来自--

http://www.china-pub.com/computers/eMook/0891/info.htm

中国互动出版网

2001-4-10

*/

主页   论坛   留言   打印   联系  

软件开发质量保证体系

来自lannuo.533.net

1. 使用范围

2. 引用标准 

3. 定义 

4. 质量体系框架 

4.1 管理职责 

4.2 质量体系

4.3 评审

4.4 纠正措施

5. 质量体系生存周期

5.1 合同评审

5.2 需方需求规格说明

5.3 开发计划

5.4 质量计划

5.5 设计和实现

5.6 测试和确认

5.7 验收

5.8 复制、交付和安装

5.9 维护



软件开发质量保证体系

　

公司内部标准

本标准参照ISO9000-3 《质量管理和质量保证标准 第三部分：在软件开发、供应和维护中的使用指南》。

　

1、 使用范围

本标准作为本公司在软件项目开发、供应和维护时的质量要求，以保证产品的质量，防止不合格产品。

以下详细描述了软件开发各阶段的控制手段和要求。要求质量保证贯穿各个阶段，始终保证严格实施。

2、 引用标准

本标准制定考虑本公司的实际情况，因此本标准仅用于本公司内部控制产品质量。

使用本文档时，请尽量参照最新版本。

3、 定义

产品：以下指软件产品，即交付给用户的一整套计算机程序、规程及相关的文档和数据。

开发：创作软件产品的所有活动。

供方：指本公司。

需方：指具体项目的需求方，即客户。

质量体系：质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。

　

4、 质量体系框架

4.1管理职责

4.1.1 供方(及具体的项目开发组)负责以下职责 

组织机构 
本公司内部专门设立部门质量保证部门，由部门负责人及专门经过培训的人员组成。具体项目开发组，设立质量保证组，或委托公司质量保证部门协助开展工作。

质量保证部门负责以下工作：

建立并维护公司内部的质量保证体系。 
对可能导致产品不合格的问题予以识别，采取措施予以避免。 
发现并记录产品的质量问题。 
提出、采取或推荐问题解决办法。 
验证解决办法的实施效果。 
对不合格产品的处理、交付过程进行控制，确保最终问题得以纠正。 
质量保证部门的评审活动应由与被评审工作无直接责任的人员组成。

制定质量方针和质量目标 
确保项目组成员均理解质量方针并能坚持贯彻执行。

公司内部制定一般性的质量方针及对软件产品的质量目标，作为各项目组的参照，各项目组可根据具体客户期望及需求作出具体质量目标及质量承诺，具体质量目标及承诺，特别是超出公司目标的部分，提交给质量保证部门，以便提交给质量保证部门充分理解并协助实施。

《质量方针和质量目标》见附录

管理评审 
质量保证部门负责人应每月对质量体系进行评审，主要是对内部质量审核结果的评定，以保证质量体系持续有效，保存评审记录。

4.1.2 需方（客户）应负的职责

在项目中，应向需方（客户）提出具体要求，明确其需要承担的职责，以便相互配合，共同保证项目的顺利实施。

需方应明确指定项目相关负责人，应具有足够的权力处理以下问题： 
向供方提出需求 
回答供方提出的某些相关问题 
认可供方的提案 
与供方签订协议并能确保遵守签订的协议 
规定验收准则和规程 
向供方提供必要的信息,提供有利的环境并解决项目中一些障碍。 
4.1.3 共同评审

双方定期地交流，并联合评审软件是否满足已经商定的需求规格说明书。

4.2 质量体系

本质量体系贯穿整个开发周期，是为了在开发过程中保证质量，并非在开发结束时才检查质量问题，所以重点强调防止问题地发生，问题发生后的纠正仅作为补充手段。

本公司将采取必要手段保证这一体系得以有效地贯彻实施。

质量体系文件 
本公司的质量体系文件,包括质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施。

质量体系文件见附录《质量体系文件》

质量计划 
具体项目开发组根据公司质量体系制订质量活动计划并形成《质量保证计划》，以保证开发组能正确理解质量体系并能遵照执行。

附录之《质量保证计划指导》作为各项目组制订计划的指导。

4.3 审核 

本公司内部建立全面的审核制度，以验证各具体项目中的质量活动是否符合计划要求，同时检查质量体系的有效性，以不断完善质量体系。

审核过程及采取的措施均要按书面方式进行。

审核结果形成报告，提交审核部门负责人。对于审核时发现的问题，相关负责人应及时采取措施。

4.4 纠正措施

纠正措施必须制定书面规程，应包括以下内容：

调查问题产生的直接原因，并制定防止同类事件发生所需的措施。 
查询分析各类过程记录、让步记录、操作记录、质量记录、客户投诉等等，已查明潜在原因并消除 
根据风险程度，采取预防措施 
对纠正措施的有效实施加以控制 
对纠正措施的记录 


　 　 
5. 质量体系生存周期

要求各阶段必须有合格的产品（包括文档），并以其作为下一阶段的工作基础。对每一阶段的产品，必须组织评审，确保其质量，避免错误影响后续工作。

本标准适用于任何生存周期模型。

5.1 合同评审

本公司应评审每一合同，以确保：

规定合同的范围和需求并写入文档 
识别可能出现的风险 
恰当的保护有关的专利信息 
解决所有与招标不一致的需求 
有能力满足需求 
规定其他涉及项目的供货商的责任 
统一双方对术语的理解 
需方有能力履行合同职责 
合同评审记录应妥善保管。

此外，应注意有关质量条款

验收准则 
在开发过程中对需求变更的处理 
对验收后出现问题的处理 
确定需方的责任，尤其是在需求规格说明、安装和验收时的作用 
有需方提供的必要便利条件，如设施、工具和软件等 
采用的标准和规程 
　

5.2 需方需求规格说明

在某一具体项目进行开发前，本公司应具有一套该项目的完整、精确、无歧义的功能需求，这些需求应包括需方的所有要求。

因为本公司在业务领域具有丰富的经验，可以大力配合客户识别并确定需求，需求在开发前得到需方的确认。

该需求应足以成为产品验收确认时的依据。

在制订需求规格说明时应注意：

双方制定专人负责 
需求认可和更改的批准 
防止误解，定义好术语，对需求的背景进行说明 
记录和评审双方讨论的结果，以备将来查询某些需求确定原因。 

5.3开发计划

在项目进行前制定开发计划，作为总体的策划，指导整个项目有序的进行。

开发计划要求包括以下方面：

项目定义 
项目资源组织管理 
开发阶段 
进度 
确定质量保证计划、测试计划、集成计划等 
随着项目的进展，开发计划要不断更新，在生命周期模型每一阶段开始之前，都要有该阶段的工作计划，并经过评审后实施。

以下较详细的说明开发计划中应具备的各方面。

A. 开发阶段

开发计划应将项目目标转化为最终结果的过程、方法等清楚的描述出来，可以把工作分为几个阶段，比如按照生命周期法划分开发阶段。

开发阶段要确定以下项：

要执行的开发阶段 
每一阶段所需的输入 
必须用文档方式确定下来，每一项需求均有明确的定义，以保证完成情况可被检验。

每一阶段应产生的输出 
验证阶段输出，必须满足以下几点：

满足相应的要求 
有明确的验收准则，作为验收评审的参考。 
符合开发惯例和约定 
每一阶段需要执行的验证步骤 
必须有对每阶段输出的验证计划，并在适当的时间进行验证评审。

分析各阶段可能潜在的问题或需要解决的问题 
　

B. 项目管理 

项目开发、实施等过程的时间进度安排 
进度的控制方法及活动 
确定组织机构及其职责、各工作组的资源及工作分配 
不同工作组间的组织协调方法，并明确技术接口问题。 
C. 开发方法和工具

规定项目活动应共同遵循的方法及使用的工具，包括：

开发规范、惯例 
开发工具及技术 
5.4 质量计划

质量计划作为开发计划的一部分。

质量计划随项目进展而更新，质量计划经正式评审，并得到所有与计划执行有关的组织的统一。

质量计划应包含或引用以下内容：

质量目标，尽可能以定量方式给出 
定义每一阶段的输入、输出准则 
确定要进行的测试、验证和确认活动的类型和详细计划，包括时间、进度等。 
确定具体质量活动的职责：比如，评审和测试、更改控制、对缺陷的控制和纠正措施。 
5.5 设计和实现

设计和实现活动是将需求规格说明转化为软件产品的过程。为保证软件产品的质量，这些活动必须在严格规定的方法下进行，不能依赖于事后的审查监督。

设计 
设计阶段要满足各阶段的共同要求，此外，设计阶段还应考虑：

选用适合所开发产品类型的设计方法 
总结吸取以往项目的经验教训 
设计应考虑软件以后的测试、维护和使用 
B. 实现 

规定编程规则、编程语言、命名约定、编码和注释规则等 
要求在实现过程中严格遵守既定开发规则 
选用合适的方法和工具实现产品 
本公司内部制定《开发规范》，各项目组可参照制定适合特定项目的规范。

C. 评审

为使需求规格说明得以满足和上述规则方法得以实施，必须以评审的方式加以保证。直到所有被发现的缺陷被消除，或确定缺陷的风险可被控制后，才能进入下一步的设计或实现工作。

各项目组引用公司规范或参照制定的开发规范应在取得本项目组广泛认可的情况下，提交给评审部门，作为评审参照依据。

评审纪录应保存，评审结果可能作为个人及项目组工作成绩评定的参考之一。

5.6 测试和确认

要具有完整的测试计划，测试计划要经过评审，并以此为依据进行测试活动。

A.测试计划 

包括单元测试计划、集成测试计划、系统测试计划、验收测试计划 
制定测试用例、测试数据和预期结果 
考虑要进行的测试类型，如：功能测试、边界测试、性能测试、可用性测试等 
描述测试环境、工具以及测试软件 
软件产品是否完成的判断准则 
测试所需人员及其要求 
B.测试活动 

记录发现的问题，指出可能的受影响的其他部分的软件，通知相关负责人员。 
确定受影响的其他部分软件，并对其进行重新测试。 
评价测试是否适度和适当。 
在验收和交付产品前，必须尽可能在类似使用环境中进行确认测试。 
　

5.7 验收

当软件产品已经完成，经过内部确认测试，准备好交付后，应要求需方根据合同中的规定原则判断是否可以进行验收。对于验收中发现问题的处理办法由双方商定并纳入文档。

具备验收条件后，应制定验收计划并逐步实施。

验收计划应包括：

时间进度 
评估规程 
软件/硬件环境 
验收准则 
5.8 复制、交付和安装

制定安装分发计划。

复制 
制作好安装程序，复制好必要的拷贝。

准备好该交付的操作手册、用户指南等文档。

交付 
交付前应对所交付产品的正确性及完整性进行检验。

安装 
就以下方面双方明确商定各自的作用、责任和义务：

时间进度及安排，包括非工作时间及假日的人员安排及工作责任 
提供出入便利条件，如通行证等 
指定熟练人员的密切配合 
提供必要的系统及设备 
对每次安装的确认条件需明确规定 
对每次安装认可的正式规程 
5.9 维护

对于软件产品在初次交付及安装后，本公司必须提供的维护应在合同中明确规定。合同中应明确以下各项的维护期：

程序 
数据 
规格说明 

维护工作一般包括：

问题的解决 
接口的调整 
功能扩充和性能改进 
本公司针对以上维护工作制订完善的维护方案，并严格遵照执行。具体维护方案见《维护工作流程》

　

附录C 质量体系文件

包括质量要素、各要素需要达到的目标以及在开发过程中必须采取的措施

质量要求要素定义如下：

正确性 在预定环境下，软件满足设计规格说明及用户预期目标的程度。它要求软件没有错误。 
可靠性 软件按照设计要求，在规定时间和条件下不出故障，持续运行的程度。 
效率 为了完成预定功能，软件系统所需的计算机资源的多少。 
完整性 为了某一目的面保护数据，避免它受到偶然的，或有意的破坏、改动或遗失的能力。 
可使用性 对于一个软件系统，用户学习、使用软件及为程序准备输入和解释输出所需工作量的大小。 
可维护性 为满足用户新的要求，或当环境发生了变化，或运行中发现了新的错误时，对一个已投入运行的软件进行相应诊断和修改所需工作量的大小。 
可测试性 测试软件以确保其能够执行预定功能所需工作量的大小。 
灵活性 修改或改进一个已投入运行的软件所需工作量的大小。 
复用性 一个软件（或软件的部分）能再次用于其它应用（该应用的功能与软件或软件部件的所完成功能有联系）的程度。 
在设计开发过程中，必须注意以下要求，以保证软件的质量达到目标。

正确性 
软件的功能要满足用户的要求，在预定环境下能够完成预期的功能。因此，必须明确的了解用户的需求。

在需求确定方面，应通过深刻的理解电信企业的运营系统及了解其发展趋势，建立模型并分析，广泛了解其他系统的特长，并总结以往的经验教训的基础上，确定出需求并通过与用户的交流最终确定。

在需求的表达方面，强调以全面、精确、细致、易于理解的方式表达，可能需要以多种形式，比如：功能描述、数据描述、数据流图、系统说明等。

可维护性 
遵从统一的规范，包括命名规范、界面规范、编程风格。

编码应具有良好的可读性，注释完整清晰。

避免复杂的逻辑判断条件，易读，易测试

编码应尽量简练，逻辑简单

保存异常信息与错误日志以便于调试与分析

降低模块之间的耦合度，增强模块内的内聚。

可用性 
用户容易理解和使用该功能

响应时间快，操作方便，提高用户工作效率。

提示信息简洁准确

可靠性 
具有异常捕获功能并提供异常处理与恢复功能

5、效率

尽量降低系统资源的开销

查询语句要充分考虑到索引

减少与数据库的不必要的交互

灵活性，易于扩展 
充分考虑到各地的不同的环境，通过参数设置使其易于适应不同的要求。

完整性、安全性 
保证相关的数据一致性

考虑数据的存取权限。

文档完善 
按文档要求完成相关文档。

　

审查制度

对于每一阶段的文档及软件产品都应交付证质量保证部门，由审查小组按质量要求严格审查。

审查内容：

文档：开发计划、用户需求规格说明、概要及详细设计文档、技术文档、用户手册等，详细要求见文档计划。评审文档是否规范，表达清晰，有实用价值。

设计方案：是否达到设计目标。

应用程序：是否达到质量目标和符合设计目标。

审查流程：

项目组按计划准备好交付的产品及文档 
交付质量保证部门，组织评审 
完成评审，发现错误报告 
发现错误的返工 
复查返工问题是否已解决

主页   论坛   留言   打印   联系  

技术讨论指南---如何“不战而胜”

来自lannuo.533.net

限制参与者人数。精心选择合适的人选，只让必需的人参加，不必求全。

准备好讨论问题，明确主要目的，将问题和目的书面化，这样会更清晰，并让参与者清楚地了解这些问题和目的。最好能给参与者比较充足的思考时间。

控制讨论主题，避免离题。

注意突出重点、不要陷入细枝末节，一般能进入正式讨论的问题不会是太琐碎的问题。不要试图在讨论会上将所有作业完全做完，有些事情本应该会后进行，比如具体实现等。避免让大家为个人做作业。

不能取得大家理解的问题暂时记录在案，留待以后讨论。有时一个问题被提出，但多数人并未理解该问题的重要性，除非能够有效地解释明白，否则应在时机更成熟时再讨论。如果是关键核心问题当然另当别论。

不能期望取得绝对的一致，对分歧较大和争执不休的问题及时转换角度，先讨论判断准则及衡量方法等，如果暂时没有讨论思路则记录在案，留待以后讨论。再更充分的思考后，更容易找到问题的关键点和思路。

做好书面记录。对问题的解决做好文档，被否定的思路也应该包含在文档中，有利于以后理解方案选择思路。

　

主持人的责任

充分理解讨论目的，控制讨论朝目标前进。必须做好前期准备。

对贬低和羞辱别人的行为严加约束。会前强调：“讨论发言必需对产品而不能对人，绝对避免攻击别人的行为，哪怕是以开玩笑的方式”，指出这样的行为是不光彩的。讨论期间如果不幸发生这样的事情，果断明确地指出。必要时（失去控制时）立即停止讨论，不要勉强进行。正常地，引导讨论在和谐的气氛和态度中。

限制争论和辩驳。将问题引导到判断准则、衡量方法和解决思路上来。

制止冗长无效率的发言，制止离题的发言，制止进入琐碎细节的发言。以简单总结问题的方法或时间进度的理由抢回主动控制权。提醒和警告经常转移问题的人，重申讨论重点和目的。

总结讨论成功与失败的经验，使自己和别人可以做得更好。

主页   论坛   留言   打印   联系  

任务管理

来自lannuo.533.net

概述

    一个工程项目是由一系列的任务组成，合理地安排这些任务单元并保证其按时完成，才能保证整个项目进度能够按时完成。为此我们制订以下方法加强任务管理。

    一个任务是包含在一个整体计划环境中的，因此作为个体首先要服从于整体计划。

任务管理方法

    任务安排：

    采用明确任务、明确责任的方式来安排任务。

下达任务必须书面化。
要求负责人明确、时限明确、任务表达明确、优先顺序明确。
明确任务的结果。

方法： 我们定制格式化任务安排表，附录《任务安排工作单》即为一个实例。

    协调及控制：

    统一协调调度任务，及满足每个人的任务量，又避免超负荷。并监督任务能按时按质完成。

合理安排每个人的长期任务和紧急任务。
协调者必须监督进度的进展，及时地调整或督促。
通过日常检查监控任务的进展。其中应特别关注关键路径上的任务。
对重要任务进行正式评审。以保证其完成质量。

方法：
可以在定期举行的例会上总结汇报工作。
为帮助统一管理任务及人力，我们设计了附录《任务安排汇总表》，将任务、人力、进度三维统一表达，即可以看到一个任务由那几个人来完成，及各自的角色，又可以看到每个人当前所承担的所有任务，便于工作量均衡。进度跟踪便于统计剩余任务工作量。

    结果考评：

    个人工作成绩通过任务完成情况纪录为依据。

任务等级定义

    任务分为几个等级，在安排任务时确定轻重缓急，任务等级作为安排者和执行者间交流的一种简洁的信息，包含了安排者在全局的层次上对任务的一种认识和理解，并将这种理解记录下来，并传达给执行者，有利于执行者能理解并按统一调度执行任务。这样可以更好地控制进度，避免关键或紧急任务被拖后。

    对执行者来说，可以有根据当前任务的优先级，有条理地安排工作。

    任务等级可从以下方面来考虑：

    紧急程度：（对任务过程的时间要求）

宽松：时限十分宽松，可以在其他任务后考虑。
一般：时间比较充裕，可以合理安排进度。
较急：有明确要求的时限，且应该尽快着手尽快完成。一般在关键路径上的任务至少有较急的级别。
紧急：立即着手，以尽快的速度解决问题。一般在任务进度可能造成较大影响时定义该级别，比如影响项目进度或影响客户业务使用。具有较高的优先级别，
特急：立即着手，需要时必须加班，需要赶赴现场时必须以最快的速度到达。需要其他人力配合时立即联系相关人员。一般在对客户业务造成重大影响时定义特急的级别。最高优先级别。

注释：紧急程度可能随着时间变动。

    重要程度：（对任务本身的影响及作用的估计）

不重要：任务失败不会造成严重结果，能够容忍。
普通：任务失败会造成一定影响，能通过措施补救，不在关键路径上，不影响整体进度，不影响客户业务。
重要：任务重要，对整个系统或项目影响很大，比如在关键路径上的任务，必须保证其成功完成。一般要在工期和质量上给以充分的控制。
关键：影响整个系统或项目的成败，必须给予最高的重视，对任务进行充分的控制，确保成功完成。

    任务排序优先级：（任务执行的先后次序，利于有条理的工作）

暂缓：尽量向后安排
普通：按顺序安排
尽快：尽量向前安排
立即：安排在任务列表最前。

    以上作为粗略地优先级别估计，方便于优先级的调整，缺省地，任务排序按照紧急在先、重要在先的原则排列。

表中符号代表分值：   *：20     ！：10      +：5    -：-5    /：不定义

附件一：任务汇总表（示例） 可打印格式见其word文档 - 任务管理

任 务 汇 总 表           项目简称：          阶段日期：

    工作量：

d天 h小时 角色：M负责 A分析 D设计 P编码 T测试 J辅助参与 进度：已完成则打勾

附件二：任务单（示例） 可打印格式见其word文档 - 任务管理

任 务 单 任务编号

主页   论坛   留言   打印   联系  

项目管理篇系列之七 - 项目管理软件

摘自www.computerworld.com.cn
左美云 李东 董小英等著

主页   论坛   留言   打印   联系  

项目管理系列之六-质量管理

摘自www.computerworld.com.cn
左美云 李东 董小英等著

主页   论坛   留言   打印   联系  

项目管理系列之五-团队管理

摘自www.computerworld.com.cn
左美云 李东 董小英等著