Q：perforce 时遇到这样的问题：文件在客户端删除后，提交。depot 中的文件也没了，如何才能找回我删除的文件？ A：用 P2Win 显示已经删除的文件,操作:Show deleted Depot Files 就会看到你已经删除的文件

在不同 linux 机器上迁移 bugzilla，请把数据库停掉再导出数据

首先访问 Bugzilla Web 站点（请参阅 参考资料 部分的链接），下载应用程序的最新 tarball。然后将 tarball 放入一个 Web 服务器用户可以访问的目录。在本例中，由于您正在使用 Apache Web 服务器，所以您需要将 tarball 下载到 Apache 的默认目录中。大部分 Apache 的基本安装允许 “apache” 用户访问 /var/www/html/ 目录。

请查阅 Apache 安装的文件，以确保将 tarball 放入了可以访问的目录。在任何情况下您都可以根据需要对此进行修改。

解开 Bugzilla

清单 1 展示了如何将所有 Bugzilla 文件解压到一个名为 bugzilla-2.1.8rc3 的目录中。简单起见，您可以选择使用所示的 move 命令将那个目录重命名为 “bugzilla”。

清单 1. 解压 Bugzilla tarball

$ cd /var/www/html/ $ tar zxvf bugzilla-2.18rc3.tgz $ mv bugzilla-2.18rc3/ bugzilla/ 安装 Perl 模块

清单 2 中的 Perl 脚本检查您的系统上是否已经安装了所需的 Perl 模块。它还会确认您是否拥有支持曲线图和报表等特性的可选 Perl 模块。

清单 2. Perl 模块安装

$ su root $ ./checksetup.pl

这个脚本运行后，将告诉您需要哪些模块，以及从 CPAN 仓库安装它们所需要的相应的 CPAN 命令。那个命令类似于以下命令：$ perl -MCPAN -e 'install ""' 。为需要安装的每一个 Perl 模块执行这个命令。如果您已经连接到 Internet，那么会自动地下载和安装所需要的模块。

完成所有所需模块的安装后，重新运行 checksetup.pl 脚本。如果一切正常，您应该会看到指出所有需要的 Perl 模块都已经安装的输出。

配置 Bugzilla

这个脚本在 bugzilla 目录中创建一个名为 localconfig 文件（如清单 3 所示）。

清单 3. Bugzilla 配置

$ vi localconfig

配置 Bugzilla 应用程序使用您的本地数据库服务器。该命令只是会在 vi 编辑器中打开这个文件。在此，您只需要修改这个文件中的一个值，即 $db_pass 字段，这是 bugzilla 的 MySQL 帐号（您马上就要创建它）所使用的口令。如果您拥有不只一个 “定制的” MySQL 安装，那么您应该检查所有 $db 设置，因为它们对应于主机名、通信端口，等等。

为 Bugzilla 创建一个数据库帐号

然后，您需要为 Bugzilla 创建 MySQL 数据库。连接到 MySQL 数据库实例，执行下面的命令：

清单 4. 添加 Bugzilla MySQL 帐号（版本 4.0 或者更新版本）

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES, CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY '$db_pass'; mysql> FLUSH PRIVILEGES;

这组命令创建了 bugs 用户，并授予那个用户帐号本地连接到 “bugs” 数据库时的多级访问权限。如果您要连接到远程的数据库，或者使用任何其他定制的配置，可以参阅 MySQL Administration 文档（请参阅 参考资料），以获得类似的命令。

再次检查那些 Perl 模块

为了再一次让自己确信已经安装了所需要的模块，请在 Bugzilla 目录中重新运行 checksetup.pl 脚本（清单 5）。现在它会检测到 localconfig 已经被修改，并且它会启动用户界面编辑进程。之后，使用在 localconfig 文件中指定的帐号创建 “bugs” 数据库，并在数据库中创建必要的表。

清单 5. 在 Bugzilla 目录中重新运行 checksetup.pl

$ ./checksetup.pl

最后，在这个过程中会询问您希望如何配置 Bugzilla 的管理员帐号。

编辑 HTTP 服务器的配置

在大部分基本的 Apache 安装中，httpd.conf 文件位于 /etc/httpd/conf/ 目录。一定要检查您的安装，确保从正确的目录中打开 Apache 配置文件。使用下面的命令打开它：$ vi /etc/httpd/conf/httpd.conf。

您需要编辑这个文件中的一些行，令 Apache 能够利用 Bugzilla。首先，您需要允许 Apache 运行 cgi-bin 目录之外的 CGI 脚本。为此，必须在 httpd.conf 中添加（或者去除注释）以下这一行： AddHandler cgi-script .cgi 。

然后，您需要允许 Bugzilla 的 .cgi 文件能够在 Bugzilla 目录中运行。将下面这两行添加到 指示符中：

...... Options ExecCGI FollowSymLinks <---- add this line. AllowOverride Limit <---- add this line.

最后一个步骤，通过将下面的内容添加到 httpd.conf 中 DirectoryIndex 那一行的最后，您必须配置 Apache，以便在进入 Bugzilla 目录时查找 index.cgi 文件： DirectoryIndex index.html index.html.var index.cgi 。

就是这样！现在您应该能够访问 http:///bugzilla 的 Bugzilla 页。记着使用本文前面通过 checksetup.pl Perl 脚本创建的管理员帐号/口令进行登录。

结束语

使用新安装的 Bugzilla，您可以建立并配置其他许多功能。我鼓励您去研究 Bugzilla 的各种功能，并指出您想要如何使用它们（我计划使用 Bugzilla 服务器作为跟踪我们部门中出现的众多问题的方法）。作为一个代码版本系统，或者作为一个问题标签（problem-ticketing）系统， Bugzilla 足以满足您的商业需求。

1. Anywhere but here.

注意看喔！这三个字都非常的简单，而它所表达的意思更是简洁有力，就是「除了这里，哪里都好」的意思。比如说天气已经热得不象话了，而你却待在一个没冷气的地方，此时有人问说要换去何处时，你就可以说：Anywhere but here.我们还可以稍作变化，比如说有人帮你介绍男/女朋友，对方却是你的仇人，你就可以说：Anyone but him / her.「除了他? 她都行。」或者是你在逛街，叽哩呱啦的售货小姐一直向你推销最贵的产品，此时你只好狠下心对她说：Anything but this.「除了这个，其它都 行。」

1. It comes and goes.

It comes and goes. 顾名思义就是「它来来去去。」的意思，从 come and go 而来，字 面上不难理解，表示某事或某物只做短暂的逗留，颇有昙花一现的味道；或者你也可以用来形容病痛，那种时好时坏，时有时无的情形。

1. There's bound to be more of them. be bound to「一定、绝对」这个词组是此句话的精髓，相当于 definitely 的意思，虽 然有点预测的意味，可是却有十成的把握。下次与人打赌时，自己对于答案的正确性胸有成竹的时候，便是你使用此一句型的最佳时机。

2. I'm done with…

这里的 do with 解释为「容忍、忍受」，整句的意思是「我受够了……」，所以当你觉得对某件事忍无可忍的时候，便是你呛出这个句型的最佳时机，另外，你比较常见这个句型以否定句的形式表现，好比说 I can't do with loud music.「我无法忍受吵杂的音乐。」

1. This one's straight from the top.

「这是直接由上头交代的。」句中的 top 是指「最高层」的意思。别以为这句是军事用语喔，这「最高层」可以是父母、可以是老师，更可以是你的老板，所以它在日常生活中也是很好用的。当你想表达一件事的重要性，而相关人士却还老神在在、无关痛痒地在纳凉，你只好拿大官来压小官，假传圣旨?！比如说，你的弟弟妹妹老是不鸟你，叫他们倒个垃圾推三阻四的，此时你就可拿着鸡毛当令箭，告诉他们这是老爸老妈交代的：This one's straight from the top.

1. Fill me in.

fill in 这个词组一般较常用在填表格的时机，来表示「填写」这个动作。今天我们要 告诉大家另一种词意，就是「向……报告最新状况」，所以 Fill me in.就是「跟我说 发生什么事了。」超适合用在想要插入一个话题或是某个讨论团体时，让大家告诉你之前讨论了什么。但最好确认别人愿意跟你说，以免造成尴尬。

1. Like finding a needle in a stack of needles.

原句应该是 find a needle in a haystack，haystack 是「大干草堆」之意，find a needle in a stack of needles 这句话的意思就是「海底捞针」，依照字面上的意思来 看，要在一束针之中找一根针是不是很难呢？而片中说成 in a stack of needles 是因 为在这场战争中，所有的军人都着同色的军服，看来一模一样，要再其中找出一个士兵难如登天之故。

1. That figures.

figure 经常被使用在口语中，意思是「了解、明白」，一般与 out 连用，这里 that 指的 是前面所讲的事情；利用前面说过的事情，推理出后面的结果，与 that makes sense 近似，所以 That figures.便引申为「不用说也知道。」或是「一看就知道。」通常发生在一件事的结果显而易见、理所当然，或你了解某人习性甚深，知道他对所提之事的应有响应，That figures.便可派上用场。好比说，某人性喜孤僻，当你提出邀约又被断然拒绝时，就可以补上一句 That figures.「我早就知道了。」来抒发你的无奈之鸣。

1. Take your time.

Take your time 是一个非常口语化的词组，指的就是你可以慢慢来，不用着急。当你请人帮忙，而对方又是个急惊风时，你就可以用上这句 Take your time.。或者是你正在学直排轮，连站都站不稳就想学倒溜，你的教练就会对你说：Take your time.

1. I'm with…on…

I'm with someone (on something) .字面上的意义是说「我跟某人在同一边」，引申 为「（在某件事上）我跟某人的意见相同；我同意某人的看法」的意思，相当于另一个句型 I am on one's side.「我跟某人站在一边。」，所以下次大家在侃侃而谈，各抒己见地讨论事情时，刚好有人与你心有戚戚焉，说出你想要说的话，就得赶紧祭出 I'm with you.「我赞同你。」

1. do us a favor

「帮个忙」这句话也是超级常用的，日常生活中要请人帮忙的情况很多，也许是请人帮你拿一下东西，也许是请人帮你带便当，都可以用上这句 Do me a favor.。要请人帮忙还有另一种说法，就是 May I ask a favor of a you?，不过记得在别人帮完后，别忘了向人家说声谢谢！Could you do me a favor?或是 Could you give me a hand?这算 是比较正式而礼貌的讲法。有时候要请别人帮忙不太好意思说时，可以贼一点地说 Could you do me a little favor?「能不能帮我一个小忙？」把对方弄上钩再说。

1. be way out of line

其实这句话从字面上就可以猜到它的意思了，out of line「越线」就是意指「?矩、过 分」；这条 line 可以把它当做界限、容忍范围看待。要特别介绍 way 的用法，这里是当副词用，就是「远远地、大大地、非常」的意思，属于夸张化的说法，比如要形容「很高」，如果你觉得 too high 还不能描绘出你要表达的高，你就可以在 too high 前加一个 way，用 way too high 来形容。所以 You're way out of line.就是「你实在是太过分了。」就是要对方收敛一点，别太超过！

1. It's not to reason why, it's but to do and die.

这句的意思就是「别问原因，尽管去做」，原句应是 Ours is not to reason why, ours is but to do and die.，这是出自十九世纪的一首古诗，这里的 ours 所指的是 our responsibility「我们的责任」，即是说「我们的职责不是在问为什么，我们的职 责就是鞠躬尽瘁死而后已。」因此这句话的使用时机，就是叫人废话少说，少开口、多做事，当然用来拍马屁时也蛮好用的，不妨参考看看！

1. I'm all ears.

通常美国人是说 I'm all your ears.，来看看字面上的意思「我把所有的耳朵都给你 了」稍作修饰后，不就是咱们中文里的「洗耳恭听」吗？假设你的好朋友失恋了来找你诉苦，此时你就可以贴心地说 I'm all your ears.，搞不好因此掳获美人心，从此过着幸福快乐的日子。

1. by all means

means 是「方法、手段」，by all means 是「必定、一定、无论如何」的意思，有 of course「当然」之意，通常是加强语气之用。比如人家邀请你去吃饭，你就可以说 I'll come by all means.「我一定会来的。」要注意的是，by any means 同样也是「一定、 无论如何」之意，但是通常用在否定句之中。还有一个词组 by no means，这个的意思就是「绝不」

1. in my way of thinking

依字面上之意，是「以我思考的方式」，所以 in my way of thinking 就是「以我看 来，就我而言」的意思。同样的意思，你也可以说 as far as I'm concerned，或者简 单一点的 in my opinion。这都是一种谦虚表达意见的方式，在发言之前先声明这纯属 个人的想法。

1. What's this all about?

这句话的意思是「这是怎么回事？」相当于 What's up with that?，这句也完全等于 What happened?或是 What's going on?，当你搞不清楚状况时，这几句话都可以为你除 疑解惑。不过用 What's this all about?来寻求解答时，是比较想知道事情的来龙去 脉，而不仅只是想知道发生什么事而已。

1. a sight for sore eyes

这是美语中一个口语化的说法，「看到你真是消除眼睛疲劳」意思就是「人见人爱的悦目之物」，白话一点就是「见到你真好」，有点像是见到救星的那种感觉，或者是看到好久不见的朋友，也可以用上这一句话。比如说你刚吃完一顿大餐，酒足饭饱之余才发现没带钱，正当不知所措准备进厨房洗碗时，看到了好友就在别桌用餐，总算露出一线生机，你就可以跟你的朋友说：You are a sight for soar eyes.

1. get a word in

word 当作「话」来用，按字面上来解释 get a word in 就是「插话」的意思，比较特殊的是，这里是指「（在别人不停地谈话时），找到插话的机会」，而且一般大部分是用否定方式 not get a word in edgewise (edgeways) 表示，如 Jean didn't let me get a word in edgewise.「珍不让我有插话的机会。」因此，每当有人高谈阔论，滔滔不 绝，说得让你连插句话的机会都没有时，你就可以利用此一佳句跟人抱怨。

1. You're going to love it here.

要表达喜欢一个地方，你可以说 I like / love this place.，或是说成更道地的 I like /love it here.。这里的 it 是指「气氛」atmosphere 而言，若是你要跟别人挂保 证，担保他一定会喜欢上某个地方，你就可以对他说 You're going to (You'll) like / love it here.。

1. I don't seem to fit.

fit 是指「合适」之意，这句话的意思就是「我跟这里格格不入。」之意。通常也会说成 I don’t seem to fit in.当你觉得某个地方或场合，和你犯冲，待在那里就是让你 浑身不对劲时，你就可以说：I don’t seem to fit in.

1. You're well on the way. 如果说 way 是指一段路途的话，那么 be well on the way 就是指在这段路途上很顺遂， 有着好的开始。用 be well on the way 这个句型用来形容一个人学习的路途，就是指他 「有慧根，悟性高」。

2. I don't mean to be rude, but...

rude 这个字是指「言行举止粗鲁的」，而 I don't mean to...这个句型是指「我不是故 意要……，我无意……」。I don't mean to be rude, but...「我无意冒犯，但 是……」这个句型的使用时机是，当你知道自己说的话可能会伤到人，可是你又想要追问，当然这也可以只是你在损人之前所用的的借口。

1. You're out of your mind.

mind 是指「心智状态，神智」，be out of...是指「没有了…?，用完了……」，be out of one's mind 的意思就是「（某人）丧失神智」，也就是「（某人）发疯」的意 思。当你觉得有人做了非一般正常人会做的事，你就可以对他说 You're out of your mind.。当然这可以指暂时丧失神智，也可能是真的发了疯。

1. I wouldn't look at it like that.

「每一件事都有两面。」There are two sides of a story.而对于同一件事的看法， 每个人或许都不尽相同。下次当有人所提出的看法，你自己不能苟同之时，就可以用上这句话 I wouldn't look at it like that.「我不会用这个角度来看。」以表示自己对 于同一件事，持有不同的意见。

1. It's all there for a reason.

有许多的观念都是长久以来传袭下来的，诸如传统或是一些约定俗成的规章，若你觉得这些经过时间考验的规章、传统甚或观念，「自有其存在的道理」，你就可以用这句话 It's all there for a reason.来表达你捍卫传统的立场。

1. I don't have time for this.

I don't have time for this.这句话的使用时机主要有两个，一是当你参与了某个活 动，你却发现整个过程却是在浪费时间，这时候你就可以说 I don't have time for this.「我没时间瞎搅和。」以表示自己的不耐烦；I don't have time for this.的另 一个使用时机，就是当有人一味地拐弯抹角说话，你就可以用这句话要对方赶快切入正题。

1. give this to you (real) straight

这句话的意思就是前一阵子政坛上最流行的一句话「讲清楚，说明白」，在美语中，give this to you straight 最常用在男女朋友分手，好说歹说都没用时，逼不得已只 好打开天窗说亮话：I'm gonna give this to you straight. I do not love you at all.

1. pain in the ass

这个句型虽然有点不雅，但是各位看官一定都记忆犹新，在各大电影、电视影集里都曾出现过，就字面上的意思不难了解，就是中文里「眼中钉、肉中刺」的意思。想想看，屁股里的痛（可能是指痔疮吧），抓也抓不到，摸也摸不着，是不是让人很难受，很痛苦呢？形容的还真是传神！

1. I know what it takes to...

take 这里是做「花时间」解释，引申为「付出代价」的意思。当你花时间，投注精力下去，相对地会有代价发生。所以 I know what it takes.便是说「我知道那代价是什 么。

1. lay low for a while

所谓「树大招风」，所以这里就教你 lay low for a while，就是「保持低调」是也。 其实这句英文和中文也有相合的地方，就是中文的「低」和英文的 low，都有那种行事不太惹人侧目的意思包含其中，所以 lay low for a while 字面意义是「停在低的地方 一会儿」，实际上就是指「保持低调」了。万一做了坏事，怕被抓到，也可以学学此句，这时的用法就是指「避风头」了。下次万一身边某人统一发票刮中两百万，就可以跟他说 You should stay low for a while.，以免不是引起歹人侧目要不就被狠刮一顿大请客，搞不好还得不偿失哩。

1. ...be the best thing that ever happened to me.

有时候在说到碰到的情境真像是前世修来的，就可以说...be the best thing that ever happened to me.，指「……是我碰过最好的事。」其实这句话并不难，光看字面 意思就能感受得到说出口的时机。所以当想大力推崇某人或某事，表达你对遇到它 （他）们的感激与感动，就牢记此句，好用无比。

1. If there is anything I can do...

常常会遭遇到一些时刻，很想出一己之力去帮助某人，这时候就可以搬出 If there is anything I can do...，来说「若有什么我可以帮忙的……」当个起头，通常都用在安 慰人、表达关心的时刻。所以万一某人的家里遭逢不幸或变故，你想要表达自己的关怀时，就可以说 If there is anything I can do, just let me know.，表示自己愿意毫 无保留的帮助对方。这可是句相当雪中送炭、温暖人心的句子喔。

1. walk away from...

walk away from...字面上的意思是「从……走开」，而在使用上，后面可以接一件 事，意指「放弃正在进行中的事」walk away from something，而后面接的若是人，则是指「撇下某人不管」walk away from someone.，用以表达事情只做了一半，就虎头蛇尾地一走了之，留下烂摊子给别人收拾。

1. She saw it coming.

...see it coming 字面上的意思是指「……看到某事来了」，在使用上就是指对于事 物，在未来将会如何发生延续下去，事先有着预感。

1. You have a way with people.

way 是指「手段、方法」，have a way with...可以用在人与人的关系上，意指某人 「很有交际手腕，对人际关系很有一套」；have a way with...也可以用在事物上，意 指「对于某方面的造诣很高」，好比有人对于文字语言的运用很娴熟，就可以说成 He has a way with words。

1. What do you want from me?

What do you want from me?这句话的使用时机，通常有两个，一个是当对方需索无 度，让人招架不住之时，你就可以对他说 What do you want from me?「你到底要我怎 样？」来表达自己洗小的抱怨；另一个情况是对方的要求太高，太难取悦，不论你怎么做，他就是不满意，这时你也可以用 What do you want from me?来表达自己的无奈。

1. You're not cut out to be...

be cut out to be 字面上的意思是「被切割成……的形状」，引申用作成为……的典 型，也就是「当……的料」。有些人一看就知道是天生吃某行饭的料，有些人怎么看就是注定不适合某个工作的人，此时你就可以活用这个表达法，来形容那个人是不是那块料。

1. You have one shot.

就像参加日本的「火焰挑战者」节目，奖金虽高，但挑战的机会只有一个，这时候主持人就可以对参赛者说 You have one shot.，表示对方只有一个机会。这里的 shot 指得就是玩像篮球这样必需投射得分的运动时，只有一球可投的意思，所以 You have oneshot.就引申为「你只有一个机会」的意思。下次有那种孤注一掷的时刻，这句话就可以派上用场了。

1. The answer is out there.

电视影集《X 档案》有句名言：「真相就在那里。」The truth is out there.但是在哪 里？就是在「那里」，只是必须要你自己去找而已！当有人说 The answer is out there.时，代表这答案是远在天边，近在咫尺，只是当局者迷，你一时看不透罢了！或者是，有些问题的答案显而易见，但却是怎么想都想不起来时，你也可以说：The answer is out there.。当然，当大家都不知道答案而只有你知道时，你也可以故弄玄 虚地说：The answer is out there.

1. The time has come to make a choice.

这里的 the time 是指「关键性的时刻」，就是没时间再让你想东想西。比如说你参加了《超级大富翁》，这一题的答案实在是不知道该选蛋黄还是纸条，而时间已经到了，主持人就会对你说：The time has come to make a choice.或是你脚踏两条船，东窗事发了，此时你踏的那两艘船就会对你说：The time has come to make a choice.

1. Do I make myself clear?

「我说得够清楚吗？」Do I make myself clear?，这就相当于中文的「你明白吗？」 通常 Do I make myself clear?的使用时机是在吵架，或是上对下的批评，但是其中带 有「警告」的意味，就是有人屡劝不听，你已经受不了而给他最后警告时，最后就可补上这一句 Do I make myself clear?

1. There's no turning back.

依字面上来看，There's no turning back.就是「没有退路。」的意思，凡是遇到势在 必行，决定了就不能反悔的事情，都可以说 There's no turning back.。说得文言一点 就是「背水一战」。

1. Time is always against us.

against 就是「跟……相反，跟……作对」，所以 Time is always against us.这句就 是「时间总是跟我们作对。」也就是在抱怨时间不够时，常常会脱口而说的一句话。例如答应老师放学前把作业交出来，没想到时光飞逝，转眼就放学了，这个时候你就可以感叹地说：Time is always against us.

生成 Maven 项目网站 Maven 可以用项目的规律和项目的相关信息，创建一个项目网页。

步骤 要想创建一个 Maven 项目网站，请使用以下 Maven 命令来运行 Site 插件： C:\dev\mavenbook\code\genapp\test-application> maven site

运行 Site 插件，将会在默认网站输出目录下创建项目网站：test-application/target/docs/index.html。如果你加载这个 HTML 页，你就会看到一个带有独特的 Maven 外观的网站。图 1-5 显示了一个略微经过定制的 Maven 网站，上面有定制的组织徽标和项目徽标。这不是一个认为编写的网站，你所看到是一个名为 Jaxen 的项目的网站，这个项目把 Maven 当作编译系统来使用。

图 1-5 Maven 项目网站示例

大多数 Maven 项目网站都有一个项目文档导航栏，点击其中的链接，可以查看所有 Maven 项目所共享的信息。Project Info(项目信息) 链接包含项目的相关信息、有件列表、关于源代码控制系统的信息以及发行追踪 (所有这些都在第四章中学习)。生成的 Maven 网站的内容通过创建和修改 xdocs 目录下的 XML 标记来产生。在图 1-5 中，这个项目包含五个项目指定的文档：概览 (Overview)、FAQ、发布 (Releases)、CVS 访问 (CVS Access) 和状态 (Status)。这些文档包含在左边的导航栏中，因为它们包含在 xdocs/navigation.xml 文件中。xdocs 目录是 Maven 用来存放项目指定文档的目录，这些文档都是 XML XDoc 格式。下面是 Jaxen 中 navigation.xml 文档的内容：

<?xml version="1.0" encoding="ISO-8859-1"?>

Added the slidedeck from mySD-West presentation.

Check out thesePerformanceBenchmarks comparing dom4j and Jaxen against Xerces and Xalan.

[...]

一旦生成了项目网站，你就可以在浏览器中加载 target/docs/index.html 来打开你的项目网站。 关于这些文件的语法 你可以在 Maven XDoc 插件 FAQ 站点找到更多关于 navigation.xml 文件的语法和格式的信息，站点的 URL: [url]http://maven.apache.org/reference/plugins/xdoc/faq.html/url]。你还可以在 Maven[ XDoc 插件主页找到更多关于个人主页格式的信息，URL 如下： [url]http://maven.apache.org/reference/plugins/xdoc/index.html/url]。这个插件的主页还包含更多关于如何定制 Site 插件的输出和行为的指导。[ 本书的第四章将更加深入地分析能够使项目的行为和结构焕发光彩的多种报表。 定制网站报表 网站的生成创建了许多有用的报表。但是，根据不同的风格，你可能需要某些报表处于非激活状态。 步骤 要改变 Maven 在生成网站时创建的报表，就得修改 project.xml 文件中 reports 元素的内容。以下是一个 reports 元素，其中有几个 report 项是激活的：

maven-changelog-pluginmaven-changes-pluginmaven-checkstyle-pluginmaven-clover-pluginmaven-cruisecontrol-pluginmaven-developer-activity-pluginmaven-faq-pluginmaven-file-activity-pluginmaven-license-pluginmaven-linkcheck-pluginmaven-javadoc-pluginmaven-jdepend-pluginmaven-jira-pluginmaven-junit-report-pluginmaven-jxr-pluginmaven-pmd-pluginmaven-simian-pluginmaven-tasklist-plugin 要把一个报表在 Maven 生成网站时排除在外，只要从 reports 元素中移除这个报表 plug-in 元素。没有制定 reports 元素的项目会生成一组默认报表：jdepend、Checkstyle、changes、changelog、developer-activity、file-activity、license、javadoc、jxr、junit、linkcheck 以及 tasklist。当你在项目的 project.xml 文件中添加一个 reports 元素时，你必须列出所有你想要生成的报表。 回顾 reports 元素列出了所有的报表，但你可能想知道这些报表到底有什么功能。表 1-1 列出了对这些报表的简要描述。

表 1-1 报表插件

报表插件 描述 maven-changelog-plugin Changelog 是一个使用 repository 元素 创建报表的插件，所创建的报表记录源代码 控制系统中最近的变化。 maven-changes-plugin 格式化 xdocs 目录中的 changes.xml maven-checkstyle-plugin 关于 Java 代码风格的报表 maven-clover-plugin 使用一款商业的覆盖率测试工具为项目的单元 测试覆盖率生成 HTML 页。 maven-cruisecontrol-plugin 这个插件将在第四章中讨论。 maven-developer-activity-plugin 创建一个报表，它记录最近源代码控制系统中开发者的活动情况。 maven-faq-plugin 格式化 xdocs 目录下，项目的 FAQ 文档。 maven-file-activity-plugin 创建一个报表来记录源代码控制系统中文件的活动情况。 maven-filebugs-plugin 找出 Java 代码中常见的有漏洞的模式。 maven-license-plugin 包括一个链接，它链接到项目报表中的项目许可 maven-linkcheck-plugin
maven-javadoc-plugin 向生成的 Maven 网站中添加 JavaDoc maven-jcoverage-plugin 生成有关单元测试覆盖率的报表和图象。 maven-jdepend-plugin 创建一个报表，它列出了包之间的依赖项 maven-jira-plugin 从一款名为 Jira 的商业发布追踪系统读取公开的发布,并创建报表。 maven-junit-report-plugin 创建一个聚集 JUnit 结果的报表。 maven-jxr-plugin 以注释的形式生成 JAVA 源代码的 相互参照项 maven-pmd-plugin 为潜在的编码错误生成报表，如未使用的本地变量和复杂的表达式等。 maven-simian-plugin 找出源代码树中重复的代码。 maven-statecvs-plugin 生成 CVS 活动的统计和图象。 maven-tasklist-plugin 在源代码中搜索@todo标签。

获取插件和报表更详尽的列表，请访问： .Maven 插件：[url]http://maven.apache.org/reference/plugins/index.html/url][ .Maven 的插件沙盒：[url]http://maven.apache.org/plugins-sandbox/index.html/url][ .SourceForge 上的 Maven 插件：[url]http://maven-plugins.sourceforge.net//url][ .第三方 Maven 插件：[url]http://maven.apache.org/reference/3rdparty.html/url][ .Matrix Maven 论坛：[url]http://www.matrix.org.cn/topic.shtml?forumId=31/url][

生成项目文档 如果你正在开发一个 Java 应用程序或视一个类库，你可能需要生成 JavaDoc。 步骤 只要执行了 javadoc 命令，Maven 就会生成项目文档。以下是执行 javadoc 命令的输出结果： C:\dev\mavenbook\code\genapp\test-application>maven javadoc

---

| \/ |__ Apache_ ___ | |\/| / ` \ V / -) ' \ ~ intelligent projects ~ || |_,|_/__|||_| v. 1.0.2 build:start:

xdoc:init:

maven-javadoc-plugin:report: [mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\ target\javadoc\src [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package mdn.testapp... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.5.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Generating C:\dev\mavenbook\code\genapp\test-application\ target\docs\apidocs\constant-values.html... [javadoc] Copying file C:\Documents and Settings\tobrien.maven\cache\ maven-javadoc-plugin-1.7\plugin-resources\stylesheet.css to file C:\dev\ mavenbook\code\genapp\test-application\target\docs\apidocs\stylesheet.css... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [delete] Deleting directory C:\dev\mavenbook\code\genapp\test- application\target\javadoc\src BUILD SUCCESSFUL Total time: 7 seconds

一旦这个 Maven 命令被执行，JavaDoc 将被放置在 tes-application/target/javadoc/src 目录下。 总结 Maven 又完成了 “繁重” 的任务。你需要 JavaDoc，然后告诉 Maven 生成 JavaDoc，仅此而已。需要强调的是，你并没有向 Maven 传递任何关于项目的信息，它知道怎么办。Maven 的大部分功能就像这样简单直接。你只需告诉 Maven 关于项目的信息，你要做的事就所剩无几了；Maven 自会处理细节。

让 Maven 了解你的团队 Maven 是一款很好用的进行合作开发的工具。你可以使用它来生成开发人员活动报告以及项目投稿人列表和邮件列表。

步骤 很多项目都有邮件列表，人们用它来讨论架构于实现。像 Tomcat、Maven 和 Ant 这样的项目都是由一个社区的开发者共同开发的，他们共同订阅同一个邮件列表。并不只是开源项目有邮件列表，很多组织已经开始使用在开源的、公开的项目中所使用的合作模型。因为邮件列表是合作中极为重要的一部分，所以 Maven 提供了一种在 project.xml 文件中指定项目邮件列表的方法。以下是 project.xml 文件的一部分，它向 project.xml 文件中添加了 mailingLists 元素：

Maven User Listusers-subscribe@maven.apache.orgusers-unsubscribe@maven.apache.orghttp://marc.theaimsgroup.com/?l=turbine-maven-userMaven Developer Listdev-subscribe@maven.apache.orgdev-unsubscribe@maven.apache.orghttp://marc.theaimsgroup.com/?l=turbine-maven-dev Maven 项目中有两种类型的队员：投稿者与开发者。然而，在你的项目中，这个定义可能要改变了。投稿者通常是指开源社区中提供补丁和文档的成员，开发者是项目的核心成员。在 ASF 中，投稿者与执行者 (committers) 都可以给项目投稿，但投稿者没有对源代码库的写入权限，也没有对项目中重大决定的表决权。以下是 project.xml 文件的一部分，它向 project.xml 文件添加一个 contributor 元素和一个 developer 元素：

Vincent Massolvmassolvmassol@apache.orgApache Software FoundationAuthorDeveloperhttp://www.massol.net+1Tim OBrientobrien@apache.orgApache Software FoundationAuthorDeveloperhttp://www.oreillynet.com/pub/au/1738-6

总结 你得告诉 Maven 谁在为项目工作，一旦我们生成了项目网站，这么做就会有用了。生成网站的插件和从源代码控制系统生成报表的很多插件都将使用这个 POM 中所列出了开发者和投稿者的信息。

把 Maven 指向源代码控制系统 你使用源代码控制系统吗？把源代码控制系统的相关信息告诉 Maven，你就可以生成一些有趣的报表，这将在本书后面的部分学习。把项目与一个源代码库联系在一起，你就可以使用 Maven 的源代码控制管理 (SCM) 插件了，这个插件提供可以用来从从版本控制系统 (如 CVS 或 Subversion) 更新和释放源代码的 Maven 命令 (goals)。

步骤 首先你得在 project.xml 文件中添加一个 repository 元素。以下 repository 元素来自 Apache Struts 项目，它指向了位于 [url]http://svn.apache.org/repos/asf/struts/core/trunk/url] 的 Subversion[ 中的源代码库：

scm:svn:[url]http://svn.apache.org/repos/asf/struts/core/trunk/url][ scm:svn:[url]https://svn.apache.org/repos/asf/struts/core/trunk/url][http://svn.apache.org/repos/asf/struts/core/trunk

connection 元素告诉 Maven SCM 的位置，这个位置是只读的。SCM 把这个 URL 标识为一个 SCM 位置，svn 告诉 Maven 位于这个 URL 的是一个 Subversion 库，URL 的最后一部分表示项目主体的位置。你还可以指定 developerConnection 元素；当你想要把相关人员分成有源代码写入权限的和无源代码写入权限的，你就会用到 developerConnection url 元素提供的 URL，可以用来浏览源代码库。在 Struts 中，Struts 自己已经指向一个 Subversion 库，因为用常规浏览器就可以浏览。Struts 团队也可以选择指向 ViewCVS 的实例，它被配置为指向 ASF Subversion 库，这个库位于以下 URL： [url]http://cvs.apache.org/viewcvs.cgi/struts/core/trunk?root=Apache-SVN/url]。[ 当你把一个 project.xml 文件指向一个特定的源代码控制系统时，你还可以指定某一特定项目的不同版本和不同分支。以下 XML 片段显示了 Apache Struts 的 project.xml 中 versions 元素和 branches 元素的精简版本：

1.2.01.2.0STRUTS_1_2_01.2.61.2.6 STRUTS_1_2_6 STRUTS_1_1_BRANCH STRUTS_1_2_BRANCH

版本 (Versions) 会被一些插件使用，例如，Announcements 插件，它为每个版本创建释放记录。

关于 CVS 许多公司和开源项目已经转为使用 Subversion，一些像 JBoss 这样的主要的开源项目也已经转为使用 Subversion。如果你的项目正在使用 CVS，你得添加一个 repository 元素，这个元素类似于 Jakarta Cactus 项目中的 repository 元素，以下是 Jakarta Cactus 项目中的 repository 元素：

scm:cvs:pserver:anoncvs@cvs.apache.org:/home/cvspublic:jakarta-cactushttp://cvs.apache.org/viewcvs.cgi/jakarta-cactus/

如果你要使用 CVS 的 pserver 来暴露你的库，以上的 repository 元素会很合适。如果你要通过 SSH 来访问 CVS，你得设定环境变量 CVS_RSH 的值为 ssh，语法如下：

scm:cvs:pserver:anoncvs@cvs.apache.org:/home/cvspublic:jakarta-cactushttp://cvs.apache.org/viewcvs.cgi/jakarta-cactus/ scm:cvs:ext:tobrien@somehost:/home/cvs/repository:modulename

然而一个单独得 id 元素会有效，我们不推荐这样的做法，在 Maven2 中将不会有这种情况。你可能在其它的项目中也见过这样的做法，但请尽量使用 groupId 和 artifactId 来确认依赖项。

依赖 Snapshots 如果你正在开发一个带有依赖项的程序，而它的依赖项会经常变化，你可能想要依赖最新的编译结果，而不是给每一个依赖项硬编码一个版本。当一个项目的依赖项仍然是测试版时，或者正如第三章讨论的那样，你正在开发一系列互相依赖的 Maven 项目，这就非常有用了。在这一节的示例中，你将学会如何依赖 SNAPSHOT。

步骤 不必指定依赖项的特定版本，只要把关键字 SNAPSHOT 作为版本名称的一部份就可以了。每当执行一个 Maven 命令的时候，Maven 会检查远程 Maven 库，看有没有依赖项的新版本。如果 Maven 找到了比本地 Maven 库中的依赖项更新版本，Maven 就会把它下载下来。例如，下边的依赖项总是下载最新的 spring 开发用 JAR1.2：

springframeworkspring1.2-SNAPSHOT

总结 使用 SNAPSHOT 依赖项，其实就是告诉 Maven 使用远程 Maven 库中的最新版本。 当你使用 Multiproject 插件的时候，当你的项目要依赖于还处于开发阶段的 artifact 时，或者，你所在的开发团队的人数不少，这样的功能就会十分有用。如果你的项目要依赖于某一个组件开发版或者未发行版，这个时候就会用到 SNAPSHOTY 依赖项。SNAPSHOT 依赖项应该只为开发意图服务。作为一项规则，你绝不能发布一个依赖于 SNAPSHOT 依赖项的项目。

离线编译 如果你要在断开网络的情况下使用 Maven，那就得让 Maven 不检查是否存在 SNAPSHOT 依赖项的最新版本。本节将教你如何使用 Maven 进行离线编译。

步骤 过程很简单：使用命令行选项-o。例如，你不能上网，但你想执行 test 命令，运行 maven –o test，它就会在不检查依赖项的情况下执行 test 命令。如果你的项目不必依赖于 SNAPSHOT 来编译，即使在不上网的情况下，也不用在命令行添加-o。如果项目依赖于 SNAPSHOT 来编译，你就得在命令行添加-o。因为 Maven 每执行一个命令，它就会检查是否 SNAPSHOT 的新版本。在这种情况下，如果不使用-o，编译将不会成功。

总结 ……没有下载 artifact，能不能进行离线下载？ 当然不行。要想进行离线下载，本地库中必须要有所需的依赖项，让 Maven 下载项目所需的依赖项，最简单的办法是，运行每个 Maven 项目自带的 “noop” 命令。例如，build:start。这个命令在其它所有命令执行前执行，并且什么都不做。如果你运行 build:start，Maven 将会获取在 project.xml 文件中引用的依赖项。

使用 Maven 控制台 (Maven Console) 如果你需要反复地从命令行运行 Maven，使用 Maven 控制台将会帮你节省时间。Maven 控制台提供了一个 “shell”，你可以输入 Maven 的命令。使用了 Maven 控制台，每当你想运行 Maven 命令时，就不必等待虚拟机 (JVM) 启动。

步骤 Maven 控制台是一个插件，你可以在命令提示符中输入 maven console 来启动它。这将会产生如下的输出： __ __ | \/ |__ Apache_ ___ | |\/| / ` \ V / -) ' \ ~ intelligent projects ~ || |_,|_/__|||_| v. 1.0.2 The following commands are available: list - list all available goals help - this message - attain a goal quit - quits the console test-application 1.0 >

可以在命令行中执行的命令，都可以在这里执行。让我们试验一下。输入 java:compile，Maven 将执行 java:compile 命令，然后返回，等待下一个命令。如果要一次执行两个命令，输入的时候用空格分开即可。例如，clean test。这种方法被称为 “命令连续”，有了这种方法，你可以按照顺序指定一系列你想让 Maven 执行的命令。要退出 Maven 控制台，输入 quit，要查看可用的命令，输入 list。

总结 Maven 执行 java:compile 命令的速度非常快，不是吗？当你使用 Maven 控制台时，其实你是在一个已有的 JAVA 虚拟机 (JVM) 中执行 Maven 命令。从命令行运行 Maven，每当你想运行 Maven 命令的时候，不得不等待 JAVA 虚拟机 (JVM) 启动。如果你不相信性能有所提高，你可以自己试一下。先从命令行连续运行 10 次 java:compile 命令，再从 Maven 控制台连续运行 10 次同样的命令。对比命令行和 Maven 控制台所用的时间，你会发现，JAVA 虚拟机 (JVM) 的启动时间有所增加。如果你要反复的运行 Maven 命令，请使用 Maven 控制台，这样一来，JAVA 虚拟机 (JVM) 只启动一次，会节省一些时间。

生成 Eclipse 项目 我肯定你想在 IDE(集成开发环境) 中开始工作。Maven 有 Eclipse 插件、IntelliJ IDEA 插件、JBuilder 插件、JDeveloper 插件以及 Emacs 插件。Maven 可以很好的与这些工具集成。本节将学习 Maven 与 Eclipse 的集成。Eclipse 是一款很受欢迎的开源 IDE。

步骤 过程很简单，运行 eclipse 插件即可： C:\dev\mavenbook\code\genapp\test-application> maven eclipse build:start: eclipse:generate-project: [echo] Creating C:\dev\mavenbook\code\genapp\test-application/.project ... eclipse:generate-classpath: [echo] Creating C:\dev\mavenbook\code\genapp\test-application/.classpath ... [echo] Contains JUnit tests [echo] Setting compile of src/test to target/test-classes Plugin 'cactus-maven' in project 'Test Application' is not available [echo] Setting default output directory to target/classes eclipse: [echo] Now refresh your project in Eclipse (right click on the project and select "Refresh") BUILD SUCCESSFUL Total time: 2 seconds

Maven 创建了两个文件：.project 和.classpath，这两个文件标识这个项目为 Eclipse 项目。 你可以通过以下步骤将这个项目导入到 Eclipse 中：

1. 启动 Eclipse。
2. 从菜单上选择文件 (File)?导入 (Import)…。
3. 选择 “现有项目”，单击 “下一步” 按钮。
4. 在 “导入” 对话框中选择 C:\dev\mavenbook\code\genapp\test-application 目录，然后单击 “完成” 按钮。

接下来还有一步：把 Eclipse 指向本地 Maven 库。Eclipse 使用变量－MAVEN_REPO 来指向本地 Maven 库。你可以使用 Maven 来设置变量 MAVEN_REPO。方法是从命令行执行如下命令： maven -Dmaven.eclipse.workspace=c:\eclipse\workspace eclipse:add-maven-repo 这个 Maven 命令用来设置位于 c:\eclipse\workspace 目录下的 workspace 中的全局变量：MAVEN_REPO。 你也可以手工配置这个变量。步骤如下：

1. 在菜单栏上选择窗口 (Window)?偏好 (Reference)，来打开 “偏好” 对话框。
2. 在左侧的树形菜单中，选择 Java?编译路径 (Build Path)?Classpath 变量。
3. 单击 “New” 按钮来建立一个新的 classpath 变量，这时会弹出 “New Variable Entry” 对话框。
4. 输入变量名称 MAVEN_REPO。
5. 单击 “文件夹” 按钮，然后选择 Maven 本地库。
6. 单击 “OK” 按钮，然后重新编译项目。

变量 MAVEN_REPO 只配置一次就可以了，因为这个变量是全局的，所有 Eclipse 项目共享这个变量。

关于 IDE ……JBuilder，JDeveloper，IntelliJ IDEA 这些 IDE 都有一些用于 Eclipse 的简单插件。要为 JBuilder 项目生成必要的文件，运行 maven jbuilder 命令。对 JDeveloper 项目来说，运行 maven jdeveloper 命令；对于 IntelliJ IDEA 项目，运行 maven idea。

获取插件和报表更详尽的列表，请访问： .Maven 插件：[url]http://maven.apache.org/reference/plugins/index.html/url][ .Maven 的插件沙盒：[url]http://maven.apache.org/plugins-sandbox/index.html/url][ .SourceForge 上的 Maven 插件：[url]http://maven-plugins.sourceforge.net//url][ .第三方 Maven 插件：[url]http://maven.apache.org/reference/3rdparty.html/url][ .Matrix Maven 论坛：[url]http://www.matrix.org.cn/topic.shtml?forumId=31/url][

使用项目对象模型 项目对象模型 (POM) 是 Maven 中最重要的部分，你将在本书中学会使用它。 如何使用 POM POM 也叫做项目描述文件。project.xml 中的 XML 元素描述了项目的源代码、开发者、源代码控制、许可以及确认信息，如项目名称、赞助项目的组织名称。Maven 的 POM 是编译系统得一个突破。Maven 没有给每一次编译提供具体的说明，而是采用了声明的方式。也就是说，你不必告诉 Maven 去做什么，因为 Maven 会根据 project.xml 去寻找。另一方面，Ant 是一种需要立刻处理的编译项目的方式，你得告诉 Ant 去编译一个类、建立一个目录、把文件打包成 WAR。Maven 维护多个插件，这些插件被设计用来与标准 POM 一同工作。标准 POM 是指结构、验证和内容的声明。 如果你看一下上一个练习生成的 project.xml 文件，你会发现很多元素在上面的讨论中被忽略了。下面的 XML 以被期望的顺序列出了 POM 中的顶层元素：

本章将学习上面的 XML 文件中的大多数元素，包括 contributors，developers，dependencies，reports，and repository。本章中的示例将提供详尽的细节，但你应该使用上面的 XML 文件节选，把元素放在 project.xml 中的合适位置。

列出可用的 goals(Maven 命令) 当你使用 Maven 的时候，其实就是在执行 goals。Maven 的插件就是一组相关的 goals。例如，要从项目创建一个 JAR 文件，你得像这样执行 JAR 插件的 jar:jar： C:\dev\mavenbook\code\genapp> maven jar:jar 冒号前面的 jar 表示这个 Maven 命令属于 JAR 插件。要想查看 JAR 插件的所有 Maven 命令，输入以下命令： C:\dev\mavenbook\code\genapp> maven -P jar

---

| \/ |__ Apache_ ___ | |\/| / ` \ V / -) ' \ ~ intelligent projects ~ || |_,|_/__|||_| v. 1.0.2

Goals in jar

[jar] Create the deliverable jar file. deploy ......................... Deploy a jar to the remote repository deploy-snapshot ................ Deploy a snapshot jar to the remote repository install ........................ Install the jar in the local repository install-snapshot ............... Install a snapshot jar in the local repository jar ............................ Create the deliverable jar file. snapshot ....................... Create a snapshot jar, ie ' id-YYYYMMDD.hhmmss.jar' Plugin for creating JAR files. Requires Maven 1.0 RC2.

如果你需要查看可用的插件和 goal 的列表，输入以下命令： C:\dev\mavenbook\code\genapp\test-application> maven -g | more 插件的整个列表太长了，因为 Maven 的插件功能全面，从为不同的 IDE 生成项目文件到生成 WAR 文件，再到启动和关闭应用程序服务器。在接下来的事例中，我们将学习一些更有用的插件。

注释:以上输出中的 Goals 就是指 Maven 命令。

生成 Debug 信息 现在，你可能已经注意到了，Maven 做了大量 “繁重的” 工作。如果你正在使用 Ant，你就得编写 Ant 的 build.xml 文件，并且添加需要编译的任务、jar 和单元测试。Maven 降低了复杂程度，但是当面对 DEBUG 时，就应该观其细节。Maven 可以在 DEBUG 模式下运行，并且打印出编译的每一个细节，如果你要确认每一次编译是否准确地如你所愿地进行了，这样的功能是十分有用的。

步骤 在这个示例的一开始，让我们再看一下上一个测试程序，当运行 maven test 命令时，输出如下： java:compile: [echo] Compiling to C:\dev\mavenbook\code\genapp\test-application/ target/classes [echo] java:jar-resources: [...]

在 java:compile 命令或者 java:jar-resources 命令执行的时候，到底发生了什么？运行 maven –X test 命令将会显示在 Maven 编译时，所有被执行的命令的 DEBUG 信息。让我们试一下，只使用前面列出的三个命令。运行 maven –X test，产生如下输出： [...] java:compile: [echo] Compiling to C:\dev\mavenbook\code\genapp\test-application/ target/classes [javac] DEBUG fileset: Setup scanner in dir C:\dev\mavenbook\code\genapp\test-application\src\java with patternSet{ includes: [ ] excludes: [*/package.html] } [javac] VERBOSE mdn\testapp\App.java omitted as mdn/testapp/App.class is up to date. java:jar-resources: DEBUG FileSet: Setup scanner in dir C:\dev\mavenbook\code\genapp\test-application\src\conf with patternSet{ includes: [.properties] excludes: [ ] } VERBOSE app.properties omitted as app.properties is up to date. [...]

Java:compile 命令的输出看上去很熟悉。它们是 Ant 的 echo 和 javac 命令的输出。正如在第二章中解释的那样，Maven 经常使用 Ant 的命令来执行像复制、删除、编译以及创建 JAR 文件等一般操作。

回顾 你所执行的两个命令，产生了简单的 DEBUG 输出。Java:compile 命令只是扫描了放置源代码的目录，检查是否有比与 Java 源代码有关联的类文件更新的 Java 源代码。Java:jar-resources 命令寻找资源，并把找到的资源放入 JAR 文件中。像 test:test 这样更复杂的命令将会产生虚拟机和类装载器 (class loader) 的 DEBUG 信息。 当 Maven 出现问题时，或是命令抛出异常时，Maven 只会打印出一条很短的消息，告诉你出错了。如果你需要更多的信息，并且想看一下堆栈追踪，就在命令行上添加-e 标志。有了-e 标志，Maven 在遇到错误时，就会打印出完整的堆栈追踪。

添加依赖项 现在，你有了一个含有一个类的项目，你已经成功编译并运行了这个类。接下来，你要在项目描述文件中添加一个依赖项，并开始使用 Maven 来管理项目依赖项。考虑到这个 lab 的目的，我们假设你使用了 Spring 框架。然后再 Spring 框架的两个 artifact ：spring-core-1.1.4.jar 和 web-1.1.4.jar 上添加一个依赖项。

步骤 首先，你得在 Maven 的默认中心库中找到你需要的 JAR 文件，URL 为 [url]http://www.ibiblio.org/maven//url][ 。在浏览器中打开这个地址，你将看到一系列目录，我们需要的目录是 springframework，它的子目录的结构如下： [url]http://www.ibiblio.org/maven/url][ /springframework /jars spring-core-1.1.4.jar spring-dao-1.1.4.jar spring-web-1.1.4.jar

要依赖一个 artifact,你要在 dependency 元素中，使用这三个元素：groupId，artifactId 和 version。你可以在两个 artifact 上添加依赖项，方法是：用下边的 XML 替换掉 test-application/project.xml 中的 dependencies 元素。

springframeworkspring-core1.1.4springframeworkspring-web1.1.4

现在，运行 jar 命令，并留意一下 Maven 的输出；它应该包含一些像下面这样的输出： Attempting to download spring-core-1.1.4.jar. 266K downloaded Attempting to download spring-web-1.1.4.jar. 111K downloaded

图 1-1 显示了下面的一系列由 jar 命令引发的事件：

1. Maven 搜索 project.xml 中定义的 POM，找到了 springframework 组中两个 artifact 的依赖项。然后 Maven 开始在 Maven 本地库中寻找 spring-core-1.1.4.jar 和 spring-web-1.1.4.jar。
2. Maven 没有找到这些文件，所以它去 [url]http://www.ibiblio.org/maven/springframework/jar//url][ 获取这两个 JAR 文件。然后这些文件被下载下来，放到你的 Maven 本地库中，同时也被添加到项目的类路径 (classpath) 中。你的项目再需要这两个文件时，Maven 将会到本地库中去获取。

图 1-1 Maven 的本地库 (Local Repository) 和远程库 (Remote Repository) 为项目 test-ap- Plication 提供 sping 框架的 JAR 文件。

回顾 Maven 为你降低了难度，节省了时间。在 Maven 出现以前，依赖项通常与项目捆绑在一起，放在 lib 目录下，还有一种情况就是，一个项目会有一些说明，教你如何把正确的 JAR 文件添加到类路径 (classpath) 中。用 Maven 来管理依赖项有着明显的优势。对于初学者来说，如果你的项目要依赖 30 个外部的 JAR 文件，没有必要把这么多文件放到源代码控制库中，这样会节约存储空间，而且，当你需要从源代码控制系统中检出项目时，下载速度也会更快。此外，如果你有多个项目依赖相同的外部文件，Maven 会一次把它们都下载下来，而且之下载一次，你的每一个项目，会引用本地 Maven 库中的依赖项的一个单独的副本。如果可以从远程 Maven 库中下载依赖项，我们没有什么特别的理由要存储这些依赖项并区分它们的版本。 当 Maven 下载依赖项时，其实它把文件从远程 Maven 库中复制到本地机器上本地 Maven 库。Maven 是如何找到依赖项的？它是依靠 project.xml 中 dependency 元素所提供的信息做到的。如图 1-2 所示。

图 1-2 Maven 库 (Repository) 和项目对象模型 (POM) 之间的映射。

指定了 groupId，Maven 会去查找指定的目录-springframework。指定了 type，Maven 会去查找指定的子目录，如 jars 或是 wars(请注意 Maven 在 type 元素后面添加的字母 “s”)；在这种情况下，type 会被忽略掉，因为 JAR 是默认类型。指定了 artifactId，Maven 就会知道从 jars 目录下载哪一个文件。顶层目录-springframwork 代表 group 的标识符，JAR 文件的文件名的第一部分代表 artifact 的标识符，最后一部分，去掉扩展名，代表 version 的标识符。Maven 使用以下方式来解析 Maven 库中的一个依赖项，其中的 [REPO_ROOT] 是指远程 Maven 库的 URL： [REPO_ROOT]//s/-.

提示 在 Maven2.0 中，Maven 库的结构将更像 JAVA 包的结构。在预计的结构中， groupId 将不会是 springframework，而是 org.springframework。此外，每一个 版本都有一个单独的目录，这样可以提高 Maven 库的效率。了解更多变动的 信息，请访问 http:// docs.codehaus.org/display/MAVEN/Repository+Layout+-+Final。

Maven 在你的主目录下维护一个本地库，以此来处理依赖项。在装有 Unix 的机器上，你的 Maven 库位于~ /.maven/repository 目录；在装有 Windows 的机器上，Maven 库位于你的%USERPROFILE% 目录下。如果你查看一下你的本地 Maven 库，你会发现里面有一个 springframework 目录。在%USERPROFILE%\maven\repository\springframework/jars 含有 spring-core 依赖项的两个文件：spring-core-1.1.4.jar 和 spring-core-1.1.4.jar.md5 文件，后者含有 MD5 哈希，用来确保 spring-core 的 JAR 文件的完整性。现在的 Maven1 没有使用 MD5 来验证 artifact 的完整性。但是以后的版本可能要使用 MD5 来验证下载的 artifact。

提示 在 Windows 机器上，%USERPROFILE% 目录通常被分解为像这样的一个目录： C:\Documents and Settings\vmassol。%USERPROFILE% 被用作 Unix 主目录的缩写。

关于 id 元素的使用 如果你要管理现有的项目，你可能会有一些使用 id 元素的依赖项。下面的 dependencies 元素演示了如何使用一个单独的 id 元素来依赖 1.0 版的 Jakarta Commons Math：

commons-math1.0

只使用 id 元素的话，只有在 groupId 与 artifactId 相匹配的时候才有效，如果你浏览 Maven 库，你会看到如下的目录结构： /commons-math /jars commons-math-1.0.jar commons-math-1.1.jar

project.xml 是项目的描述文件；这是一个含有项目对象模型 (POM) 的 XML 文件。我们来看一下为这个项目定制的 project.xml 文件的副本：

3test-applicationTest Application1.0Your Organizationhttp://www.someorganization.biz/http://www.someorganization.biz/logo.gif|jpg|... 2005 mdn.testapp http://yourproject/logo.jpg|gif|... An example project How to use maven in different situations <!--许多元素被省略 (见生成 POM) --> src/java src/test /*Test.java /NaughtyTest.java src/conf *.properties

这个文件告知 Maven 关于项目的所有信息。build 元素定位源代码、单元测试以及将会与应用程序一起打包的资源。Name、artifactId、currentVersion,、inceptionYear,、description, 和 shortDescription 确定了项目，并且提供了信息，用来命名从项目创建的 artifact。

注释:artifact 指的是某一特定项目的输出，包括 JAR、WAR、SAR、RAR 等。

提示 如果你使用了已有的 Maven 项目，在元素 artifactId 的位置，你看到的是元素 id。 我们不推荐使用元素 id，你应该使用元素 artifactId。

resources 元素被 JAR 插件用来把资源复制到 JAR artifact。在这个元素中，你在 resource 标签中指定了一组资源。在这个示例中，来自 src/conf 目录的资源将被复制到类路径 (classpath) 的根目录。也就是说，资源 app.properties 将会被复制到生成的 JAR artifact 的根目录。如果你想让 src/conf 目录下所有的.properties 资源和.xml 资源在生成的 JAR 包 mdn.testapp 中可用，就得用以下方法指定一个目标路径 (targetPath)：

src/conf mdn/testapp .properties .xml

project.properties 可以使你为特定项目定制 Maven 和 Maven 插件的行为。在本书后面的部分，我们将会使用这个文件来给生成的网页定制外观，给 JAR 文件定制内容。

提示 Maven 还有很多在线文档，这里是一篇不使用 Genapp 插件创建新项目的快速入门指南， “十分钟测试”，作者：布莱特.波特，网址：http:// maven.apache.org/start/ten-minute-test.html。

关于 Maven 追踪合作项目信息的能力 为了简化这个示例，我们从原来的 project.xml 文件中删除了一些元素，原来的 project.xml 文件描述了邮件列表、源代码库、开发者和网站。在第四章和第五章中，我们将会更加详尽地学习如何使用 Maven 来发布网站以及如何使用 Maven 与现有的源代码库一起工作。

通过代理使用 Maven Maven 依赖于互联网，它会通过 HTTP 下载所有的依赖项和插件。如果你在像公司一样的环境中工作，你可能需要配置 Maven，以使它能够通过代理服务器来工作。 步骤 你需要在项目的 project.properties 文件中设置一些属性。project.properties 文件允许你通过设置已命名的属性，来定制 Maven 的行为。要想配置代理服务器，必须把以下的 project.properties 文件与项目的 project.xml 文件放在同一个目录下：

maven.proxy.host = proxy.company.com maven.proxy.port = 80 这些属性配置了 Maven，使它可以连接到 proxy.company.com 这台机器的 80 端口上。如果你使用了要求验证的代理服务器，你必须指定两个额外的属性：

maven.proxy.username = tobrien maven.proxy.password = myp@ssw0rd 如果你要连接要求 NTLM 验证的代理服务器，请设置如下属性：

maven.proxy.ntlm.username = tobrien maven.proxy.ntlm.password = myp@ssw0rd

提示 在第二章中，你将会了解到：像这样特定用户的属性，应该定义在~/build.properties 文件中，或者%USERPROFILE%\build.properties 文件中。现在，如果你想在防火墙后面完成这个示例，就把这些属性定义在 project.properties 文件中。

项目的编译和测试 你现在有一个新项目，它有一个类和一个单元测试。接下来，让我们编译项目，并运行 App 类。 步骤 执行 Maven 命令 jar:jar，以此来创建一个 JAR 文件，这个 JAR 文件包含这个应用程序的类。JAR 插件定义了一个快捷命令 jar，它依赖于 jar:jar 命令。执行任意一个将获得相同的结果。所有的插件都定义了快捷命令。例如，test 命令执行 Test 插件的 test:test 命令。使用 maven jar 来执行 jar 命令： C:\dev\mavenbook\code\genapp\test-application>maven jar

---

| \/ |__ Apache_ ___ | |\/| / ` \ V / -) ' \ ~ intelligent projects ~ || |_,|_/__|||_| v. 1.0.2 Attempting to download junit-3.8.1.jar. 118K downloaded build:start: java:prepare-filesystem: [mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\ target\classes java:compile: [echo] Compiling to C:\dev\mavenbook\code\genapp\test-application/ target/classes [echo] [javac] Compiling 1 source file to C:\dev\mavenbook\code\genapp\testapplication\ target\classes java:jar-resources: Copying 1 file to C:\dev\mavenbook\code\genapp\test-application\target\ classes test:prepare-filesystem: [mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\ target\test-classes [mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\ target\test-reports test:test-resources: test:compile: [javac] Compiling 3 source files to C:\dev\mavenbook\code\genapp\testapplication\ target\test-classes test:test: [junit] Running mdn.testapp.AppTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.078 sec jar:jar: [jar] Building jar: C:\dev\mavenbook\code\genapp\test-application\ target\test-application-1.0.jar BUILD SUCCESSFUL Total time: 9 seconds

Maven 创建了名为 target 的目录来放置中间文件和 JAR 文件。创建了 JAR 文件之后，按照如下方式执行 App 类： C:\dev\mavenbook\code\genapp\test-application> java ^ More? target\test-application-1.0.jar mdn.testapp.App Hello World!

如果你想重新来一遍，运行 maven clean 来删除 target 目录，然后重新编译。 注释: ^和 more 的意思是 DOS 命令行要继续执行。 Maven 开始工作了，第一次，它要运行单元测试。如果本机没有安装 JUnit，它会自动下载。不必在网上搜索 JAR 文件。

回顾 运行 jar 命令时，Maven 使用 JAR 插件创建了一个 JAR artifact。首先，Maven 必须运行一系列命令，才能创建本程序的 JAR 文件。JAR 插件有一个 jar:jar 命令，这个命令又依赖于其它的命令。Maven 运行了如下一系列命令：java:prepare-filesystem，java:compile， java:jarresources，test:prepare-filesystem，test:test-resources， test:compile，and test:test。 Maven 运行了 Test 插件的一个命令，这个命令执行 JUnit 测试，并且检查本机的 Maven 库里是否含有 JUnit 的 JAR 文件。因为 Maven 在第一次使用时，会从 Maven 的默认库 [url]http://www.ibiblio.org/maven//url][ 下载 junit-3.8.1.jar 。 在本章后面的部分，你将学到本地 Maven 库和 Maven 强大的依赖项管理能力。

在来看看本地仓库目录结构 Repository -- junit |-- junit |-- 3.8.1 | `-- junit-3.8.1.jar 现在大家应该明白了吧，多余的话不说啦。照葫芦画瓢就是。不过注意先建目录后写配置文件，否则一旦保存，智能的插件就马上开始下载了…

现在开始手动建立 oracle 的 jdbc 目录并配置文件,首先建立目录结构如下： Repository -- ojdbc |-- ojdbc |-- 14 | `-- ojdbc-14.jar 如果你手头的 jar 文件名叫 ojdbc14.jar，则改为 ojdbc-14.jar,写配置文件: xml 代码

1. 
   
2. ojdbc
   
3. ojdbc
   
4. 14
   
5. 
   

那么现在一个完整的 pom.xml 文件如下： xml 代码

1. <?xml version="1.0"?>
2. 
   
3. 4.0.0
   
4. com.mycompany.app
   
5. myapp
   
6. Maven Quick Start Archetype
   
7. 1.0-SNAPSHOT
   
8. [url=http://maven.apache.orghttp://maven.apache.org[/url]]
   
9. 
   
   1. 
      
   2. ojdbc
      
   3. ojdbc
      
   4. 14
      
   5. 
      
   6. 
      
   7. junit
      
   8. junit
      
   9. 3.8.1
      
   10. 
       
   
   
10. 
    

保存之，则发现工程管理透视图发生了一点变化,依此方法再加上 jdbc 的架包，现在可以开始写程序了，建一个类并添加 main 函数，编写程序如下： java 代码

1. public static void main( String[] args )
   
2. {
   
3. Connection conn = null;
   
4. PreparedStatement ps = null;
   
5. ResultSet rs = null;
   
6. try {
   
7. Class.forName("oracle.jdbc.driver.OracleDriver");
   
8. conn = DriverManager.getConnection("jdbc:oracle:thin:@(description=(address_list=(address=(protocol=TCP)(port=1521)(host=192.168.0.240)))(connect_data=(SERVER = DEDICATED)(SERVICE_NAME = db.efriendnet.com)))", "efnx", "efnx");
   
9. ps = conn.prepareStatement("select * From tb_partyinfo");
   
   1. rs = ps.executeQuery();
      
   2. while(rs.next())
      
   3. {
      
   4. System.out.println(rs.getString("topic"));
      
   5. }
      
   6. } catch (Exception e) {
      
   7. System.out.print(e.getMessage());
      
   8. }
      
   9. finally
      
   10. {
       
   11. if (rs != null) {try {rs.close();} catch (SQLException e) {}}
       
   12. if (ps != null) {try {ps.close();} catch (SQLException e) {}}
       
   13. if (conn != null) {try {conn.close();} catch (SQLException e) {}}
       
   14. }
       
   15. }
       

别忘了 import 相应的包

八、编译程序 采用 maven 构建系统，则编译过程就独立了出来。这时你再用 eclipse 自带的编译工具就不起作用了。所以要想编译、调试、运行还要做一些工作。以前是在 dos 命令行方式下进行编译，现在的插件很好用，在 eclipse 配置一下就可以编译了。很方便。现在就做一个介绍。

Eclipse 有一个扩展工具就是用来集成其他构建工具的在工程的节点上点击鼠标右键，选择属性，在 “编译” 的右边窗口选择” 新建” 按钮，在对话框的 “name” 中输入：study,点击 “Browse Workspace…” 列出工程列表供选择。 选择完毕后，在 goals 中输入 package。别忘了 apply.好了，让我们 Run 吧。如果一切正常， 控制台会打出 maven 的编译信息如下： [INFO] --------------------------------------------------------------------- [INFO] Building Maven Quick Start Archetype [INFO] task-segment: [package] [INFO] --------------------------------------------------------------------- [INFO] resources:resources [INFO] Using default encoding to copy filtered resources. [INFO] compiler:compile [INFO] Nothing to compile - all classes are up to date [INFO] resources:testResources [INFO] Using default encoding to copy filtered resources. [INFO] compiler:testCompile [INFO] Nothing to compile - all classes are up to date [INFO] surefire:test [INFO] Surefire report directory: D:\eclipse\workspace\study\target\s

urefire-reports

T E S T S

Running com.efn.AppTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.157 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] jar:jar [INFO] Building jar: D:\eclipse\workspace\study\target\study-1.0-SNAPSHOT.jar [INFO] ---------------------------------------------------------------------------- [INFO] BUILD SUCCESSFUL [INFO] --------------------------------------------------------------------- [INFO] Total time: 4 second [INFO] Finished at: Fri Aug 04 10:55:42 CST 2006 [INFO] Memory 2M/7M [INFO] -------------------------------------------------------------------- 注意，别忘了每一次程序改动完毕后都要经过这一步编译。因为这是 maven 的编译器！

九、调试程序 经过以上步骤我们已经完成了 mave 管理下的软件生命周期，但是作为一个程序开发人员我们还要进行调试。这里的调试设置和普通的 java 程序的调试是一样的。 首先，打开 debug 对话框： 因为是一个一般的 java 应用程序，所以我们选择 Java Application,点击 “New” 按钮，输入一些相应的参数，apply-Debug Ok,一切正常！希望你也顺利！

十、结束语 本文只是简单的对 maven 的操作步骤做一个指南性的说明，实际应用还有很多东西需要实践。如果发现哪里有错误和纰漏也欢迎批评指正！

转载自：[url=http://blog.csdn.net/lddongyu/archive/2007/10/08/1815265.aspxhttp://blog.csdn.net/lddongyu/archive/2007/10/08/1815265.aspx[/url]]

很是美啊

zoe 于 2008-7-8 17:31 发表
顶～ [/quote]

网站已经快 72 小时不能访问了。。。换了独立 IP 了。

实例说明最后，笔者介绍几个实际的案例，希望对大家选择软件配置管理工具软件有帮助。

案例一

某公司拥有 10 名专职开发人员以及一些兼职的开发人员，主要从事 Windows 和 Linux 平台下的软件开发，采用的工具包括 Visual Studio 系列、GCC 等。为了能够加强版本控制与配置管理工作，决定引入一些自动化配置管理工具。经过慎重的选择，采用了两步走的方法：

1）首先采用了 Visual Studio 软件包中的 VSS 做为配置管理工具；由于 VSS 安装、配置、操作都十分简单，上手容易，这样在执行配置管理的过程中，工具的培训没有带来太大的阻力，大家可以集中精力理解配置管理。这样很快就在团队中形成了版本控制、配置管理的氛围与习惯。

2）然后构建了 CVS 服务器，做为整个开发组织的配置管理工具；CVS 能够有效地支援 Windows、Linux 两个平台上的应用开发，其性能优秀，而且免费，另外，它对于兼职人员的配置管理十分有效。采用 CVS 至今，效果明显，除了功能、使用上有些不方便之处外，没有出过任何大问题。

案例二北京某公司拥用 230 名专职开发人员，长期从事金融业务的开发，随着业务的良性发展，在管理上也出现了一些不足：

1）开发管理沟通滞后，开发人员孤立操作，变更和维护信息无法实时反馈；

2）主管领导对所开发的 100 多种产品的项目开发进程不能及时了解，很多资源滞留在个人手中；

3）随着产品的需求日益增加，无法快速标识和查找软件的历史版本；

4）无法对处于不同开发平台上的项目进行统一管理和资源配置；

5）无法实现异地开发团队的协调和沟通。

因此，该公司决定引入软件配置管理，在配置管理工具软件的选择上，考虑到其人员规模较大，项目较多，工作复杂，在针对可靠性、易用性、稳定性、安全性、技术支持能力以及软件的各功能进行了仔细的综合评估后，最后选择了国内技术支持较到位的 Hansky Firefly 软件配置工具软件。

在采用了 Hansky Firefly 之后，有效地解决了这些问题，还帮助其顺利地通过了 CMM 2 级认证，为企业的进一步发展打下了坚实的基础。

大家能否谈谈文件的管理问题（不使用版本控制工具) [url]http://www.vchelp.net/cndevforum/subject_view.asp?subject_id=3922&forum_id=61/url][ ROGRAM MER 工具点评 [url]http://www.hansky.com/cn/news/select_scm.pdf/url][

A． 项目的软件配置管理小组要参加对上述四类由间接供货单位提供的软件的物理配置检查； 这些软件的功能配置检查由项目的软件质量保证小组负责。

B． 在这些软件送入软件受控库与其他软件成分进行组装之前，软件配置管理小组要对其存放媒体和配置标识进行认真的审查。

C． 由软件质量保证小组审查选用的上述四类软件，必须经过正式的验收手续，并由项目技术管理小组负责人批准，然后置于软件配置管理小组的控制之下。

6 记录的惧维护和保存

在本项目及其所属的各个子系统的研制与开发期间，要进行各种软件配置管理活动。准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的下沉运行与维护工作十分有利。在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。

A． 基础上组装系统、各个子系统、专用支持软件及选用软件的功能基线、指派基线与产品基线要送入软盘或磁带，至少必须一式两份且存放在两个不同的地点。这些记录应该每 6 个月拷贝一次，以免意外损伤与自然老化。

B． 上述这些软件的文档也应送入软盘或磁带，至少必须工式两份且存放在两个不同的地点，并应有一份打印的硬拷贝。磁媒体应该每隔 6 个月拷贝一次，以免意外损伤与自然老化。

C． 软件产品的源程序、测试数据、测试报告及其他有关文档，除了按 A、B 规定妥善存放外，要在项目结束后再保存 2 年，或在条件成熟时转交给这些软件产品的生产系统。

注：具体保存年限要根据项目的性质与开发单位的任务来确定，此处仅作为一个示例。

D． 上述这些软件的各项配置的个性状态、评审记录与修改历史，要作为这些软件的历史记录来保存，目前可用打印硬拷贝一式两份存放，有条件时再转移到在线光学存储媒体中。

E． 鉴于处理版权或清理财务的需要，本软件系统的各项配置可能要求存放 5~7 年，但由于我国对这些问题尚无明确的规定，因此，有关本条款的具体规定待将来有必要与可能时再作修改与补充。

　

附录 B

配置管理报表及其格式

（参考件）

B1 软件问题报告单（SPR）

在系统的运行与维护阶段对软件产品的任何修改建议，或在软件开发的任一阶段中对前面各个阶段的阶段产品的任何修改建议，都应填入软件问题报告单。软件问题报告单的格式见表 B1。

B1．1 配置管理人员填写内容

表中 A、B、C、P 和状态等项目是由负责修改控制的配置管理人员填写的。表中其他各项即 D、E、F、G、H、I、J、K、N 和 O 各项是由发现问题的人或申请配置管理的人填写的，他可能还要填写 J、L 和 M 三项内容。前四项内容的意义如下：

A 是由配置管理人员确定的登记号，一般按报告问题的先后顺序编号；

B 是由配置管理人员登记问题报告的日期；

C 是发现软件问题的日期；

P 是填写若干补充信息和修改建议。

关于配置管理七种状态的含义在下面解释。

B1．2 配置管理状态

状态一栏分成七种情况，现分别说明如下：1 表示软件问题报告正被评审，已确定采取什么行动；2 表示软件问题报告已由指定的开发人员去进行维护工作；3 表示修改已经完成、测试好，正准备释放给主程序库；4 表示主程序库已更新，主程序库修改的重新测试尚未完成；5 表示已经进行了复测，但发现问题仍然存在；6 表示已经进行了复测，已经顺利完成所做的修改，软件问题报告单被关闭（维护已完成）；7 表示留待以后关闭，因问题不是可重产生的，或者是属于产品改善方面的，或者只具有很低的优先级等等。

B1．3 配置管理申请人员填写的内容

在软件问题报告单中，属于配置管理申请人填写的各项内容的意义如下：

D、E 两项是项目和子项目的名称，F 是该子项目的代号，这应按配置标识的规定来命名代号；

阶段名和报告人的姓名、住址和电话等的含义是显而易见的；

G 表示问题属于哪一方面，是程序的问题还是例行程序的问题，是数据库的问题还是文档的问题，是功能适应性修改还是性能改进性修改问题，也可能是它们的某种组合；

H 表示子例行程序/子系统，即要指出出现问题的子例行程序名字，如果不知是哪个了例行程序，可标出子系统名，总之，尽可能给出细节；

I 是修订版本号，指出出现问题的子例和程序版本号；

J 是媒体，表示包含有问题的子例行程序的主程序库存储媒体的标识符；

K 是数据库，表示当发现问题时所使用的数据库标识符；

L 是文档号，表示有错误的文档的编号；

M 表示出现错误的主要测试实例的标识符；

N 是硬件，表示发现问题时所使用的计算机系统的标识；

O 是问题描述/影响，填写问题征候的详细描述，如果可能则写明实际问题所在，还要给出该问题对将来测试、界面软件和文档等的影响。

B2 软件修改报告单（SCR）

对软件产品或其阶段产品的任何修改，都必须经过评审、批准后才能重新投入运行或作为阶段产品释放。这一过程用软件修改报告单（software change report）给以记录。软件修改报告单的格式见表 B2。当收到了软件问题报告单之后，配置管理人员便填写软件修改报告单。软件修改报告单要指出修改类型、修改策略和配置管理状态，它是供配置控制小组进行审批的修改申请报告。表中各项内容的意义如下：

A 是登记号，它是配置修改小组收到软件修改报告单时所作的编号；

B 是配置管理人员登记软件修改报告单的日期；

C 是已经准备好软件修改报告单、可以对它进行评审的时间；

D、E 和 F 的意义与软件修改报告单的编号，如该编号中提出的问题只是部分解决，则在填写时要在该编号后附以字母 P（PAET 表示部分之意）；

H 指出是程序修改、文档更新、数据库修改还是它们的组合，如果仅是指出用户文档的缺陷则在解释处作上记号；

I 是修改的详细描述，如果是文档更新，则要列出文档更新通知单的编号；如果是数据库修改，则要列出数据库修改申请的标识号；

J 是批准人，经批准人签字、批准后才能进行修改；

K 是语句类型，程序修改中涉及到的语句类型包括：输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、存放语句）；

L 是程序名，批被修改的程序、文档或数据库的名字。如果只要求软件修改报告单做解释性工作，则是重复软件问题报告单中给出的名字；

M 指当前的版本/修订标识；

N 指修改后的新版本/修订本标识；

O 指数据库，如果申请数据库修改，这里给出数据库的标识符；

P 是数据库修改申请号 DBCR；

Q 指文档，即如果要求文档修改，这里给出文档的名字；

R 是文档更新通知单编号 DUT；

S 表示修改是否已经测试，指出已对修改做了哪些测试，如单元、子系统、组装、确认和运行测试等，并注明测试成功与否；

T 指出在软件问题报告单中给出问题描述是否准确，并回答是或否；

U 是问题注释，准确地重新叙述要修改的问题；

表 B1 软件问题报告单（SPR）

登记号（A）

软件问题报告单 登记日期（B）年 月 日

发现日期（C）年 月 日

项目名（D）子项目名（E）代号（F）

软件 需求 概要 详细 编码 组装 安装 运行 1 2 3 4 5 6 7

阶段名 定义 分析 设计 设计 测试 测试 验收 维护 状态

□ □ □ □ □ □ □ □ □

　

姓名 电话

报告人 地址

问题（G）例行程序□ 程序□ 数据库□ 文档□ 改进□

子例行程序/子系统：（H）修改版本号：（I）媒体：（J）

数据库：（K）文档：（L）

测试实例：（M）硬件：（N）

问题描述/影响：（O）

　

附注及修改建议：（P）

表 B2 软件个性报告单（SCR）

登记号（A）

软件修改报告单 登记日期（B）年 月 日

评审日期（C）年 月 日

项目名（D）子项目名（E）代号（F）

响应哪些 SPR：（G）

修改类型（X）修改申请人（Y）修改人（Z）

修改：（H）程序□ 数据库□ 文档□ 解释□

修改描述：（I）

　

　

批准人：（J）

改动：

语句类型：（K）I/O□ 计算□ 逻辑□ 数据处理□

程序名：（L）老版本号：（M）新版本号：（N）

数据库（O）DBCR：（P）文档：（Q）DUT：（R）

修改已测试否：（S）单元 子系统工程 组装 确认 运行

成功否：（S）

　

SPR 的问题叙述准确否？（T）是□ 否□

附注：（U）

　

问题来自：（V）系统设计规格说明书□ 需求规格说明书□ 设计说明书□ 数据库□ 程序□

资源来自：（W）人工数：（单位：人日）计算机时间：（单位：小时）

　

V 指明问题来自哪里，如系统设计规格说明书、软件需求规格说明书、概要设计说明、详细设计说明书、数据库、源程序等；

W 说明完成修改所需要的资源估计，即所需要的人月数和计算机终端时数；

X 指出所要进行修改的类型，由执行修改的人最后填写。修改类型主要有适应性修改、改进性修改以及计算错误、逻辑错误、输入和输出错误、接口错误、数据库错误、文档错误以及配置错误等的修改；

Y 是提出对软件问题进行修改的人员或单位；

Z 是完成软件问题修改的人员或单位。

　

　

附加说明：

本标准由中华人民共和国机械电子工业部提出。

本标准由北京航空天大学计算机软件工程研究所负责起草。

本标准主要起草人张子让、周伯生、黄征、张社英。

4．3．3 配置状态的记录和报告

本条必须：

A． 指明怎样收集、验证、存储、处理和报告配置项的状态信息；

B． 详细说明要定期提供的报告及其分发办法；

C． 如果有动态查询，要指出所动态查询的能力；

D． 如果要求记录用户说明的特殊状态时，要描述其实现手段。

例如，在配置状态记录和报告中，通常要描述的信息有：

A． 规格说明的状态；

B． 修改建议的状态；

C． 修改批准的报告；

D． 产品版本或其修改版的状态；

E． 安装、更新或交付的实现报告；

F． 用户提供的产品（如操作系统）的状态；

G． 有关开发项目历史的报告。

4．3．4 配置的检查和评审

本条必须：

A． 定义在软件配置计划的第 4.2.2 条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用；

B． 规定每次检查和评审所包含的配置项；

C． 指出用于标识和解决在检查和评审期间所发现的问题的工作规程。

4．4 工具、技术和方法

本章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具、技术和方法：

A． 软件媒体和媒体的标识。

B． 把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。

C． 编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别（如项目负责人、配置控制小组、软件配置管理人员和用户）的管理报告的工具、技术和方法。

4．5 对供货单位的控制

供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求。管理规程应该规定在本软件配置管理计划的执行范围内控制供货单位的方法；还应解释用于确定供货单位的软件配置管理能力的方法以及监督他们遵循本软件配置管理计划需求的方法。

4．6 记录的收集、维护和保存

本章必须指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施（其中包括要使用的后备设施），并指明要保存的期限。

GB/T 12505-90

　附录 A

软件配置管理计划示例

（参考件）

计划名 CADCSC 软件配置管理计划

项目名 中国控制系统 CAD 工程化软件系统

项目委托单位

代表签名 年 月 日

项目承办单位

代表签名 年 月 日

1 引言

1．1 目的

本计划的目的在于对所开发的 CADCSC 软件规定各种必要的配置管理条款，以保证所交付的 CADCSC 软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。

软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。

1．2 定义

本计划中用到的一些术语的定义按 GB/T 11457 和 GB/T 12504。

1．3 参考资料

GB/T 11457 软件工程术语

GB 8566 计算机软件开发规范

GB 8567 计算机软件产品开发文件编制指南

GB/T 12504 计算机软件质量保证计划规范

GB/T 12505 计算机软件配置管理计划规范

CADCSC 软件质量保证计划

2 管理

2．1 机构

在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。

软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。

2．2 任务

在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第 3.2 条中详细规定。

2．3 职责

在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下：

A． 组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责；

B． 软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范；

C． 项目的专职配置管理人员检查在作配置更改时的质量保证措施；

D． 各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

E． 用户代表负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行情况；

F． 项目专职的配置管理人员协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。

2．4 接口控制

对各类接口进行严格、合理的控制，是软件配置管理中最重要的任务之一。整个软件项目及其各子系统都必须对进行严格的控制。在工程化软件系统中，主要的接口有如下五类：

A． 用户界面：用户界面是指各子系统与设计人员、用户或维护人员之间的操作约定。同时还指实现这些操作约定的物理部件的功能与性能特性。

B． 系统内部接口：系统内部接口是指各子系统在集成为一个总的软件系统时的各种连接约定。

C． 标准程序接口：标准程序接口是指各应用子系统与标准子程序库（包括宿主计算机系统已有的库程序）之间的调用约定。

D． 设备接口：设备接口是指各子系统与各种设备（包括终端和其他各种输入/输出设备）之间的连接约定。

E． 软件接口：软件接口是指各个子系统与宿主计算机上的系统软件以及与调用本软件的其它软件系统之间的连接约定。

以上五类接口是一个软件系统各项配置的重要组成部分。对接口修改进行合理的控制，是软件配置管理的重要任务之一。这五类接口都涉及到 CADCSC 软件系统的全局，因此，当要求对这五类接口中的任一类接口进行修改时，都必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第 3.2 条中规定（可参阅表 1）。

表 1 两类修改的审批程序

步骤 A 类修改的审批程序 B 类修改的审批程序

1 发现问题，填写软件问题报告单 发现问题，填写软件问题报告单

2 项目组长评审 项目组长评审

3 软件配置管理小组评审 子系统配置管理人员评审

4 项目总体组批准 子系统负责人批准

5 修改配置并填写软件修改报告单 修改配置并填写软件修改报告单

6 项目组长评审 项目组长评审

7 软件质量保证小组评审 子系统质量保证人员评审

8 总体组批准 项目的软件配置管理小组与子系统负责人共同批准并报项目总体组备索

2．5 软件配置管理计划的实现

在实现软件配置管理计划的过程中，要特别注意实现以下三个里程碑：

A． 建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软件配置管理小组；

B． 建立各阶段的配置基线：随着 CADCSC 软件系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着总体组编写的《CADCSC 软件需求规格说明书》的批准，建立起指派基线；随着 CADCSC 工程化软件系统的集成与系统测试的完成，建立起产品基线。

C．建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。

2．6 适用的标准、条例和约定

除应奠定本计划第 1.3 条中指出的参考资料以及本计划中的其他章条所作的各项规定外，还应该遵守如下标准、条例和约定：

A． 软件开发库、软件受控库与软件产品库的操作规程与管理规程；

B． 系统、子系统、模块和程序单元的命名约定；

C． 文档和测试用例的命名和管理规程。

这引起命名约定、操作规程与管理规程应由 CADCSC 项目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目总体组审批。在执行过程中，如果发现某些条款需要修改，则必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第 3.2 条中规定。

3 软件配置管理活动

3．1 配置标识

3．1．1 文档

所有为本项目编制的文档，都要符合 GB 8567 中的规定。CADCSC 软件系统及其所属的各个子系统所编写的文档数目，可根据 GB 8567 的规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。

3．1．2 程序

所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。

3．1．3 各类基线

所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。

3．2 配置控制

软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。配置控制的要点如下：

A． 修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为 A 类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为 B 类修改），都必须通过本项目各个子系统的配置管理人员审查，并经项目的软件配置管理小组与各个子系统负责人的共同批准并报项目总体组备案。

B． 修改审批程序：上述两类修改的审批程序如表 1。

C． 修改控制工具：修改控制工具是协助软件配置管理人员进行配置控制的有效手段。

3．3 配置状态审计

利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。

注：本计划在此处应给出软件问题报告单与软件修改报告单的具体格式，并作出必要的说明。鉴于本计划拟采用附录 B（参考件）中建议的格式，因而这两个报告单的格式及其说明可参阅附录 B。

3．4 配置的检查和评审

项目软件配置管理小组要对所有由第三方提供的软件进行物理配置检查；对本项目及其各个子系统的每一个新的释放进行功能配置检查和物理配置检查；对宿主计算机系统所提供的软件和硬件配置要每隔半年检查一次；在软件验收前要对宿主计算机系统、各个子系统及其专用支持软件的配置进行综合检查。

在软件开发周期各阶段的评审与检查工作中，要对该阶段所进行的配置管理工作进行必要的评审和检查。应该进行评审与检查的内容与次数，由 CADCSC 软件质量计划规定。配置修改的审批程序按本计划第 3.2 条的规定处理（见表 1）。

4 工具、技术和方法

在软件的开发过程中，与软件配置有关的工具有软件测试工具、软件配置管理工具、文档辅助生成工具与图形编辑工具等到三种。

A． C 软件测试工具：它支持用 C 语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖 C0 和分支覆盖率 C1 的值、并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。

B． 软件配置管理工具：它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。

C． 文档辅助生成工具与图形编辑工具：它主要协助用户绘制描述程序流程与结构的 DFD 图与 SC 图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述系统特性的一些其他图形，同时还可生成若干与 CADCSC 软件文档编制大纲适应的文档模板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，这有助于提高文档的编制质量。

有关这些工具的详细需求可参阅这三项工具的需求规格说明书中的规定。

5 对供货单位的控制

CADCSC 项目所属的各个子系统开发组如果需要从软件销售单位购买、委托其他开发单位、从开发单位现存软件库选用或从项目委托单位或用户的现有连锁反应加中选用软件时，则在选用前应向 CADCSC 总体组报告，然后由 CADCSC 总体组组织"软件选用评审小组"进行评审、测试与检查，只有当演示成功、测试合格后才能批准使用。如果只选用其中部分内容，则按等待开发软件的处理过程办理，此时 CADCSC 总体组不予预。在进行上述工作过程中，软件配置管理人员要进行下列工作：

　　

4.3.2 配置控制 4.3.2.1 本条必须描述在本计划第 4.2.2 条描述的软件生存周期中各个阶段使用的修改批准权限的级别。 4.3.2.2 本条必须定义对已有配置的修改建议进行处理的方法，其中包括： A. 详细说明书在本计划第 4.2.2 条描述的软件生存周期各个阶段中提出建议的程序（可以用注上自然语言的流程图来表达）； B. 描述实现已批准的修改建议（包括源代码、目标代码和文档的修改）的方法； C. 描述软件库控制的规程，其中包括存取控制、对于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七项规程； D. 如果有必要修补目标代码，则要描述其标识和控制的方法。 4.3.2.3 对于各个不同层次的配置控制组和其他修改管理机构，本条必须： A. 定义其作用，并规定其权限和职责； B. 如果已组成机构，则指明该机构的领导人员及其成员； C. 如果还没有组成机构，则说明怎样任命该机构的领导人、成员及代理人； D. 说明开发者和用户与配置控制组的关系。 4.3.2.4 当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时，本条必须说明对其进行配置控制的方 法。如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则本条必须描述这些机构的组成、它们与配置控制组的关系以及它们之间的相互关系。 4.3.2.5 本条必须说明与特殊产品（如非交付的软件、现存软件、用户提供的软件和内部支持软件）有关的配置控制规程。

4.3.3 配置状态的记录和报告 本条必须： A. 指明怎样收集、验证、存储、处理和报告配置项的状态信息； B. 详细说明要定期提供的报告及其分发办法； C. 如果有动态查询，要指出所动态查询的能力； D. 如果要求记录用户说明的特殊状态时，要描述其实现手段。

例如，在配置状态记录和报告中，通常要描述的信息有： A. 规格说明的状态； B. 修改建议的状态； C. 修改批准的报告； D. 产品版本或其修改版的状态； E. 安装、更新或交付的实现报告； F. 用户提供的产品（如操作系统）的状态； G. 有关开发项目历史的报告。

4.3.4 配置的检查和评审 本条必须： A. 定义在软件配置计划的第 4.2.2 条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用； B. 规定每次检查和评审所包含的配置项； C. 指出用于标识和解决在检查和评审期间所发现的问题的工作规程。

4.4 工具、技术和方法

本章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具、技术和方法： A. 软件媒体和媒体的标识。 B. 把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。 C. 编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别（如项目负责人、配置控制小组、软件配置管理人员和用户）的管理报告的工具、技术和方法。

4.5 对供货单位的控制

供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求。管理规程应该规定在本软件配置管理计划的执行范围内控制供货单位的方法；还应解释用于确定供货单位的软件配置管理能力的方法以及监督他们遵循本软件配置管理计划需求的方法。

4.6 记录的收集、维护和保存

本章必须指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施（其中包括要使用的后备设施），并指明要保存的期限。

来源：[url]http://blog.csdn.net/hk_von/archive/2004/10/07/126807.aspx/url][

[url]http://hr.baidu.com/job.php?job=79/url][

我投过，不过没人甩我。。。。。被鄙视了

ms 最近跳槽的很多呀.

工作流程明细：定义系统

最初的两个需求工作流程明细（分析问题和理解涉众需要）创建了关键系统定义的早期迭代（包括前景文档指定的特性）、用例模型的第一个大纲，以及初始需求属性。下一个工作流程明细即定义系统，通过改进特性定义，添加新主角、用例和补充规约，完善了高级系统需求说明。

图 12： 定义系统 [点击图片可在新窗口打开]

工作流程明细：定义系统

更新词汇表是为了反映当前对术语的理解，这些术语用于描述在用例模型及补充规约中捕获的特性和需求。

系统分析员使用在改进的前景文档中定义的特性集来派生用例并以说明，这些用例详细阐述用户对系统预期行为的观点。用例模型作为客户、用户和系统开发人员之间的合同，规定了所选特性如何在系统中发挥作用。它有助于系统开发人员设置符合现实的期望和目标，帮助客户和用户验证系统是否达到了这些期望。

一些系统需求没有很好地符合用例。系统分析员就在补充规约里说明这些需求。许多非功能性需求，如可用性、可靠性、性能、可支持性等，都放在补充规约中。应该注意，这些类型的许多非功能性需求专门针对单个用例。用例阐释者最好将这些需求放在用例规约本身（请参见改进系统工作流程），在补充规约里描述系统范围的非功能性需求。

在该工作流程明细中，系统分析员创建和设置了补充需求的属性（如优先级和相关用例）。除此之外，系统分析员还为初始用例和新用例添加并更新属性值。

最后，系统分析员通过追踪重要用户需要和关键特性到相关用例以及补充规约说明的需求，以此来管理依赖关系。

工作流程明细：管理系统规模

在确定特性级别的需求，描述大多数主角、用例以及补充规约所指定的其他需求后，系统分析员应该收集需求属性（如优先级、工作量、成本和风险等），并尽可能精确地为其指定属性值。这使得人们对如何确定系统发布的初始规模有了更好的理解，也让构架设计师能够从结构上确定具有重要意义的用例。

由项目和开发管理人员一起制定的迭代计划，首次出现在该工作流程明细：管理系统规模中。迭代计划也是一个开发计划，它定义为发布版计划的迭代次数和频率。早期的迭代应计划规模内风险最高的元素。

管理规模工作流程的其他重要输出包括软件构架文档的初始迭代和一个修订过的前景文档，前景文档反映分析员和关键涉众对系统功能和项目资源的加深理解。

与前面提到的商业理由一样，迭代计划的第一个问题是，软件构架文档不是需求管理工作流程的一个工件，尽管它与该工作流程有关而且是 Rational Unified Process 的一部分。这部分内容不在本文的讨论范围内。

图 13： 管理系统规模 [点击图片可在新窗口打开]

工作流程明细：管理系统规模

构架设计师为用例的风险范围、构架重要性和构架覆盖范围确定优先顺序。尽管定义系统时用到了许多用例和补充规约需求，但通常只有用例的一个子集才是好的系统构架的关键。确定用例的优先级后，构架设计师改进迭代或开发计划，利用 Rational Rose 这类工具建立系统构架的用例视图模型。

系统分析员通过改进前景中特性的需求属性来管理依赖关系。他们还对用例和补充规约里的需求进行改进。系统分析员确保涉众需要、特性、用例需求和补充规约需求存在适当的可追踪性。这里特意使用了 “适当的可追踪性”。请参见本文中插入的关于可追踪性的说明文字。

在整个项目中，该步骤是最为重要的步骤之一。第一次，我们对所提议的系统了解如此之深，使得我们能对需求、项目资源和交付日期作出重大承诺。同时也必须理解，这些需求将会随着了解程度的加深而变更。如果在前三个工作流程对依赖关系进行管理，则执行这一步骤就会容易得多，将来进行变更也更容易。

贯穿项目的整个生命周期，随着形势和环境的变化，由于系统分析员必须就修改后的项目规模和前景与关键涉众进行协商，因此将会多次重新检查该工作流程明细。涉众和开发团队成员只有把该步骤看作一个自然前进过程 - 既不要让用户措手不及，也不要企图向组织索要更多时间和金钱 - 才能成功管理项目规模，使之与可用资源相符合。该工作流程在项目的主要里程碑处需重复多次，以便评估对系统及系统问题的新认识是否要求变更规模。尽管已承诺的需求、预算和期限很难更改，但随着对确定优先级的用例、补充规约和早期系统迭代的深入理解，不可避免会导致人们重新考虑系统规模。

需要重申，在到达改进阶段之前，以及在贯穿项目生命周期内发生变化前，项目团队应维持日常的规模管理，这一点很关键。涉众代表必须理解并相信，在难度不断增加的规模协商中，他们的优先考虑和利益始终得到认真的对待。在改进系统需求之前，只有重要的需求才有待于协商或修改。除非建立有效的规模管理制度，否则项目注定会变成一次 “死亡之旅” - 规模过大的项目将残酷地走向延期和成本超支的绝路。

工作流程明细：改进系统定义

进入改进系统定义后，该工作流程明细假设已经概述了系统级别的用例并至少简要描述了主角。通过项目规模管理，前景中的特性再次确定了优先顺序，现在可以相信，这些特性在比较严格的预算和期限下是可以实现的。该工作流程的输出是对系统功能更深入的理解，这些系统功能在详细用例、已修订的补充规约以及系统本身的初期迭代中进行说明。

显然，不是所有的系统都有用户界面，不是所有的初期迭代都包括 GUI 元素。这里我们仅仅将它们作为初期迭代的示例。其他例子包括原型、模型和示意板。

图 14： 改进系统定义 [点击图片可在新窗口打开]

工作流程明细：改进系统定义

用例阐释者详述每个用例的事件流定义、前置和后置条件以及其他文本属性。为最大限度地减少工作量并提高可读性，建议使用标准文档格式或用例规约模板来记录每个用例的文字信息。创建考虑周全的用例规约对系统质量至关重要。制定规约要求对涉众需要以及与用例相关的特性有透彻的理解。让项目团队的若干成员（如软件工程师）参与用例创建是再好不过了。

同时，用例阐释者使用并非用例特有的附加需求对补充规约进行修订。

用户界面设计员模拟系统的用户界面并进行原型设计。这项工作与用例的演进密切相关。

对每个需求有更深入的理解后，用例阐释者和系统分析员对其工作量、成本、风险以及其他属性值进行修正。

系统定义改进流程的结果提交给另一轮管理规模工作流程明细。对系统有更多的了解后，可能需要改变优先级。毫无疑问，如果必要，系统发布的规模将需要复审和改进。

工作流程明细：管理需求变更

当变更发生时 -- 变更是不可避免会发生的 -- 管理需求变更工作流程明细需持续应用于项目生命的全过程，这与管理系统规模工作流程明细一样。该工作流程的输出可能导致对每个工件的修改，这又要求在所有的项目团队成员和涉众之间进行有效的交流。

在这个工作流程中，我们引入了受需求工作流程影响的其他工件。需求的变更必然影响在分析设计工作流程中表示的系统模型。需求变更还影响用于验证需求是否正确实施的测试。在前面的例子中，这些工件是 Rational Unified Process 的组成部分，但不是本文论述的主题。在管理依赖关系流程中确定的可追踪性关系是理解这些影响的关键。

管理需求变更工作流程的另一个重要概念是需求历史追踪。通过把握需求变更的性质和基本原理，复审员（工作受变更影响的任何软件项目团队成员）将收到对变更作出正确响应所需的信息。

图 15： 管理需求变更 [点击图片可在新窗口打开]

工作流程明细：管理需求变更

出于各种原因，任何涉众或项目团队成员都有可能提出变更需求的请求。所有变更请求 (Cr)，包括对需求或扩展请求甚至缺陷的变更，都应该通过同一个变更请求管理 (CRM) 流程进行疏导。至少，这应包括在一个集中数据库系统中记录并追踪请求，并由中央复审委员会执行复审。CRM 流程的详情见 Rational Unified Process 的其他小节。

系统分析员应该协调最好由变更控制委员会 (CCB) 执行的复审活动，收集并检查所有的变更请求，并将它们分类为：

* 实施中不影响需求的缺陷 * 对现有的某类型需求的修改 * 扩展要求

分类后，按在其他需求工作流程中描述的方法为所提出的需求变更指定属性和值。

在复审变更请求的时候，系统分析员向一个由涉众代表和项目团队成员组成的 CCB 陈述确定优先顺序的需求变更。超过资源限制的规模修改请求被拒绝，或者将其上交给涉众代表，涉众代表有权批准对日期以及预算事项的必需变更。CCB 批准或拒绝需求变更。

系统分析员把需求变更传达给需求阐释者，或直接修改前景、用例、补充规约文档或其他需求工件中的需求。

需求复审员（开发人员、测试员、经理及其他团队成员）通过审查需求历史，对需求变更对他们的工作造成的影响进行评估。最后，他们实施变更，对他们有权修改的相关需求作适当改动。

总结

管理需求的需要并不新鲜。那么，究竟是什么值得我们去思考呢？ 首先，如果项目常常不能满足客户、错过最后期限和预算超支，就有理由重新考虑开发方案了。在设计方案时，如果您确信与需求相关的问题正在消耗你的开发工作，就有理由考虑改进需求管理了。

其次，本文总结的需求管理方案体现了几千个案例的集体经验和智慧，而且代表了许多个人深思熟虑的观点，他们在需求管理领域与客户合作已有数年时间。我们认为，他们的贡献 - 以及 Rational Unified Process 对这些贡献所作的透彻陈述 - 总结起来代表了需求管理的 “最佳方案”。你将发现这些需求建议是最可靠的。

作者向 Dr. Ivar Jacobson 对本文的直接和间接贡献，以及 Dean Leffingwell、Dr. Alan Davis、Ed Yourdon 和 Elemer Magaziner 等人的帮助表示感谢。尤其，我们要感谢 Rational Software 的客户，他们在数以百计开发项目中应用和改进了这些方案。

最后，在过去的两年内，生产有效软件开发解决方案的领先公司 Rational Software 接受需求管理的挑战，生产了多种工具来使执行这一艰巨任务实现自动化。长期、普遍存在的需求管理问题得到了解决。也许这最终才是今天在需求管理领域开始追求卓越的最佳原因。

[url]http://space.itpub.net/?uid-12639375-action-viewspace-itemid-149119/url][

图 6： 定义特性的需求属性 [点击图片可在新窗口打开]

图 7 显示了 RequisitePro 中某个项目的特性需求实例。注意，即使未完整地显示每个需求，但我们从属性值即可了解每个需求的很多内容。在这个例子中，需求的优先级和难度 - 毫无疑问是由团队的不同成员指定的 - 有助于团队兼顾考虑涉众优先级，以及对难度属性值所反映工作量的大致估计，把项目规模限制在可用资源和时间的合理范围内。在更详细的需求类型中，优先级工作量属性可能有更多的具体值（如预计时间、代码行等），从而进一步改进规模。需求的多维性以及不同类型的需求（每种类型都有自己的属性）对于组织大量需求和管理项目的整体规模来说是不可或缺的。

图 7：设置各个需求的属性值 [点击图片可在新窗口打开]

变更历史

单个需求和需求集合都有历史记录，并且内容随着时间的推移而更具有含义。变更在所难免，而且变更有助于与环境变化和技术发展保持同步。记录项目需求版本有助于团队领导人找出变更项目的原因，如新的系统发布等。需求集合可能与某一个软件版本相关，理解这一点有助于人们扩大对变更的管理，降低风险，提高实现重大里程碑的几率。随着单个需求发展，理解它们的变更历史是很重要的：变更内容、起因、时间和谁授权变更等。

实施需求管理工作

需求管理采用上面介绍的关键技巧和概念成功地识别并解决问题。

为了建立一个真正满足客户需求的系统，项目团队首先必须确定系统要解决的问题。然后，团队必须确定涉众，从中获得业务和用户需要，对其进行描述，并区分它们的优先级。从这一组高层期望或需求出发，对产品或系统特性集达成一致意见。

详细的软件需求应该以客户和开发团队都能理解的形式写下来。我们发现，使用客户的语言来描述这些软件需求在取得理解和共识的过程中是最有效的。这些详细的软件需求随后用作系统设计规约的输入，或者作为实施和验证所需的测试计划及过程的输入。软件需求还应该促进初始用户文档规划及设计。

图 8： 需求管理结构概述 [点击图片可在新窗口打开]

为了推动需求管理，项目团队应该：

* 对项目的常用词汇表取得一致。 * 制定系统前景，描述系统将要解决的问题以及系统的主要特性。 * 至少获得五个重要领域的涉众需要：功能、可用性、可靠性、性能和可支持性。 * 决定使用哪些需求类型。 * 为每一个需求类型选择属性及属性值。 * 选择需求的说明格式。 * 确定创造一种或多种需求类型的团队成员，以及那些对此有贡献或仅仅进行查看的团队成员。 * 决定所需的可追踪性。 * 制定变更需求需遵守的提议、复审、决议程序。 * 开发一个追踪需求历史的机制。 * 为团队成员和管理人员创建进度和状态报告。

这些必要的需求管理活动与行业、开发方法和需求工具无关。它们同时也很灵活，能够在最严格、变化速度最快的应用软件开发环境下执行有效的需求管理。

需求管理：工作流程明细

根据领域的不同，需求管理可遵循的方案有无限多种。下面的方案给出了六个详细的工作流程，它们适用于每一个关键的需求管理技巧，但也可以应用到任何领域。

下面的工作流程图摘自 Rational Unified Process [6]，需求工作流程明细。这些工作流程用角色、活动和工件（输入或输出）表示，图 9 的活动图对它们进行了概括。旁边的文字简单描述了每个工作流程，希望藉此增进读者对改进需求管理流程的理解和兴趣。关于 Rational Unified Process 的更多信息，可参考 [url]http://www-900.ibm.com/cn/software/rational/products/unified_process/index.shtml./url][

图 9： Rational Unified Process 中的需求工作流程 [点击图片可在新窗口打开]

工作流程明细：分析问题

在问题分析中，主要的活动是制定项目前景。此活动的结果是产生了一个前景文档，它确定了待建系统的高级用户或客户视图。前景文档将初始需求作为关键特性表述，这些特性是系统为了解决重大问题并满足关键涉众需要而必须具备的。系统分析员在此工作流程中扮演主要角色。系统分析员应该具有问题分析领域的专业知识，对问题有一定的理解，还应该能描述其认为可以解决问题的流程。此阶段要求各个项目涉众积极参与，还应该考虑所有相关的涉众请求。

要开始管理依赖关系活动，应该为职责分配属性，如基本原理、相对值或优先级以及请求的来源等。随着前景的发展，分析员确定可能用例的用户和系统（主角）。主角是用例模型的首要要素，它们将定义系统的功能性和非功能性技术需求。

图 10： 分析问题 [点击图片可在新窗口打开]

工作流程明细：分析问题

启动：一个或多个认识到问题存在的涉众启动工作流程。

开发团队中的系统分析员可以和这几个最初的涉众展开会话，帮助他们描述需要解决的问题。对所认识问题的简要说明达成一致意见是很重要的。下表列出了问题说明的关键元素： 问题 定义问题 对涉众影响 列出受问题影响的涉众 问题的影响 描述问题的影响 成功的解决方案 列出成功解决方案的一些主要优点

问题说明简明扼要解释了项目的目的。问题分析员深入调查所有涉众请求和初始商业理由，包括显著优点以及大致估计的成本等。在定义问题说明的同时，团队还应该编写词汇表，记录常用术语并统一其定义。

问题分析员还确定系统的主要主角。主角是系统的用户或者将与之交换信息的其他任何系统。在这一阶段，问题分析员应该简单确定主角与系统交互的一些显而易见的方式。说明应面向业务流程而非系统行为。例如，预算程序可能会允许一个类型的主角 “制定部门预算”，而其他类型的主角可以 “合并部门预算”。系统分析员以后可以将它们用到其他用例中，这些用例与特定系统行为结合起来更有意义。例如，“制定部门预算” 可以产生像 “导入电子表格信息” 以及 “创建预算视图” 等系统用例。

上述问题分析会话通常进行不止一次，会话对象可能是不同的涉众，并且中间还夹带开发团队的内部会话。与涉众打交道的系统分析员将主持一次与开发团队成员的会话，展望问题的技术解决方案，从初始涉众输入中导出特性，并起草前景说明，即待建系统的第一个定义。为了方便初始涉众理解提议的解决方案，系统分析员可以利用建模工具或手工绘图技术来完善前景说明。

要从多方面向初始涉众咨询，以帮助改进问题说明，限制可能解决方案的个数和规模。涉众和系统分析员就关键特性的优先级进行谈判，对资源及开发资源所需的工作量取得一般性的理解，藉此来管理该工作流程中的依赖关系。尽管优先级和工作量/资源的估计不可避免会发生变化，但提早管理依赖关系可建立起一个在整个开发生命周期中一直延续使用的重要模式。这是规模管理的本质所在，是一个项目成功的早期预报器。

A 在经过几次草案更新后，前景文档进入团队必须决定是否对额外需求获取进行投资的阶段。同时，商业理由的批准过程也分别开始启动了。本文不打算深入探讨商业理由，只对其进行简单说明。商业理由描述：

* 环境（产品领域、市场和规模） * 技术方案 * 管理方案（时间安排、风险、对成功的客观评测方法） * 以及财政预测

工作流程明细：理解涉众需要

如果初始问题分析证明增加投资是合理的，则郑重开始理解涉众需要工作流程。这一阶段的关键活动是获取涉众请求。主要结果是收集确定优先级的涉众需要和特性，利用此结果可改进前景文档，加深对需求属性的理解。另外，在这个工作流程中，您可以根据用例和主角对系统展开讨论。另一个重要输出结果是经过更新的词汇表，它使团队成员对常用词汇有一致的理解。

图 11：理解涉众需求 [点击图片可在新窗口打开]

工作流程明细：理解涉众需要

系统分析员和关键涉众通过访谈、专题讨论会、示意板、业务流程用例和其他手段，确定更多的涉众，获取他们的请求，确定关键需要和特性。这些会话由一个或多个系统分析员主持进行。需求专题讨论会是最有用的需求获取手段。该流程包括用户、帮助台人员、企业主、测试员以及其他对提议项目的结果有利害关系的个人。涉众请求通常是不明确、重叠甚至是离谱的。除正式的获得结果外，涉众请求还可以用格式设计很好的文档、数据库的缺陷和扩展请求或者电子邮件和群件线程等形式表达。系统分析员记录已确定的关键涉众需要，对其进行分类和区分优先次序。

对涉众需要有了更好的理解之后，开发团队里的系统分析员改进前景文档，将主要精力放在制定 “产品定位说明” 上。该说明用简洁的两三句话确立项目的显著价值。说明应包括预期用户、项目解决的问题、所带来的利益，以及它所取代的竞争者。所有的团队成员都应该理解该项目的主题。系统分析员还更新词汇表，促进团队对术语的共同理解。

从多方面向关键涉众咨询，以便对从理解涉众需要得到的新特性的优先级进行协商，获得对当前开发新特性所需资源和工作量的理解。利用问题分析，在该工作流程中管理依赖关系有助于管理项目的规模。它还建立起涉众请求、需要与系统特性之间的可追踪性，让涉众相信他们的建议确实得到考虑。

三、CheckStyle 的最佳实践

　　3.1. Sun’s Code Conventions 的修改

　　在 CheckStyle 的最新发布版本中，有一个对于 Sun 的 Java 编码规范的配置文件信息。但是，其中有很多条目并不一定符合项目开发的需要。就算是对于很多优秀的开源项目，按照这个规范来进行检查，也会出现成千上万的错误。

　　下面提出的一些修改意见，是从实际项目执行过程中总结出来的，可以作为大家的参考。我们以 CheckStyle3.0 配置文件的顺序来介绍：

　　1. 去除对于每个包都有一个 package.html 文件的限制；

＜!--＜module name="PackageHtml"/＞--＞ 　　 　　2. 修改对于 JavaDoc Comments 的限定：对于很多使用 Code Generator 的项目来说，需要将手写代码与生成代码、单元测试代码的检查分开进行；

　　3. 修改对于体积大小的限制：目前，很多显示器都是 17 寸，而且打印方面的限制也比以前有所改善，同时，由于代码中 Factory 等模式的运用，以及有意义的方法名称等约定，默认每行代码的长度（80）是远远不能满足要求；对于方法长度等等，也应该根据项目情况自行决定：

＜module name="FileLength"/＞ ＜module name="LineLength"＞ ＜property name="max" value="120"/＞ ＜/module＞ ＜module name="MethodLength"＞ ＜property name="max" value="300"/＞ ＜/module＞ ＜module name="ParameterNumber"/＞

　　4. 修改对于 Throws 的的限制：允许 Throws Unchecked Exception 以及 Throws Subclass Of Another Declared Exception。

＜module name="RedundantThrows"＞ ＜property name="allowUnchecked" value="true"/＞ ＜property name="allowSubclasses" value="true"/＞ ＜/module＞

　　5. 修改成员变量的可视性：一般情况下，应该允许 Protected Members 以及 Package Visible Members。

＜module name="VisibilityModifier"＞ ＜property name="protectedAllowed" value="true"/＞ ＜property name="packageAllowed" value="true"/＞ ＜/module＞

　　3.2. CheckStyle 应用的最佳实践

　　采用 CheckStyle 以后，编码规范的检查就变得及其简单，可以作为一项切实可行的实践加以执行。

　　一般情况下，在项目小组中引入 CheckStyle 可以按照下面的步骤进行：

　　1． 强调 Code Review 与 Code Conventions 的重要作用；

　　2． 介绍 CheckStyle；

　　3． 初步应用 CheckStyle：参照 CheckStyle 附带的配置文件，酌情加以剪裁，在项目的 Ant 配置文件中，添加 CheckStyle 任务，可以单独执行；

　　4． 修改、定型 CheckStyle 的配置文件：按照基本配置文件执行一段时间（2～3 周），听取开发人员的反馈意见，修改配置信息；

　　5．作为开发过程的日常实践，强制执行 CheckStyle：稳定 CheckStyle 的配置信息，同时将 CheckStyle 任务作为 Build 的依赖任务或者配置源码控制系统（目前，CheckStyle 可以与 CVS 有效集成），使得代码在加入系统之前必须通过检查。

　　同时需要指出的是，CheckStyle 的有效执行需要依赖两个条件：

　　·Ant 的广泛应用：CheckStyle 基于 Ant 执行的方式比较容易，而且可以在项目内容形成一致的执行环境。同时，也比较容易与其它任务，例如 Build 等发生关联。

　　·IDE Format Code 的强大功能：由于 CheckStyle 本身并没有提供很强大的 Code Format 等功能，因此，需要借助 IDE 的帮助，从而使得在发生错误的时候，可以很容易的进行修复。目前，主流的 Java IDE 都提供了这方面的功能，IDEA 在这方面尤其突出。它提供的统一、可定义的 Code Format Template（项目小组内部可以使用统一模板）以及方便的快捷键功能 (Ctrl+Alt+T：Format Code, Ctrl+Alt+O：Optimize Import 等)。

　　四、结论

　　利用 CheckStyle 可以方便的对于编码的 Code Conventions 进行检查，同时，也有效地减少了 Code Review 的工作，使得 Reviw 人员的精力更多的集中到逻辑和性能检查。

[url]http://dev.yesky.com/453/2357953_1.shtml/url][

定义系统

定义系统指的是解释涉众需求,并整理为对要构建系统的意义明确的说明.在系统定义的初期要确定以下内容:需求构成,文档格式,语言形式,需求的具体程度 (需求量及详细程度),需求的优先级和预计工作量 (不同人在不同的实践中通常对这两项内容的看法大不相同),技术和管理风险以及最初规模.系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型.系统定义的结果是用自然语言和图解方式表达的系统说明.

管理项目规模

为使项目高效运作,应仔细根据所有涉众的需求确定优先级,并对项目规模进行管理.有的开发人员仅仅重视所谓的"复活节彩蛋"(即开发人员感兴趣或觉得有挑战性的特性),而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面,这已使太多的项目蒙受损失.为确保尽早解决或降低项目中的风险,应以递增的方式开发系统.要慎重选择需求,以确保每次增加都能缓解项目中的已知风险.要达到目的,您需要和项目的涉众协商每次迭代的范围.通常,这要求具备管理项目各个阶段的期望结果的良好技能.

除了控制开发过程本身,您还需控制需求的来源,并控制项目可交付工件的外观. 改进系统定义系统的详细定义应能让涉众理解,同意并认可.它不仅需要具备所有功能,而且应符合法律或法规上的要求,符合可用性,可靠性,性能,可支持性和可维护性.感觉构建过程复杂的系统就应该有复杂的定义,这是一种常见的错误看法.这会给解释项目和系统的目的造成困难.人们可能印象深刻,但他们会因不甚理解而无法给出建议.应该致力于

了解您制作的系统说明文档的读者.您可能常会发现需要为不同的读者准备不同的说明文档.

我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法,它常与简单的可视化原型结合使用.用例有助于为需求提供一个环境,利用它可生动地说明系统使用的方式.

系统详细定义的另一个构件是说明系统采用的测试方式.测试计划及要执行测试的定义将会说明要核实哪些系统功能.

管理需求变更

定义需求时无论怎样谨慎小心,也总会有可变因素.变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求.应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系.管理变更包括建立基线,确定需要追踪的重要依赖关系,建立相关项之间的可追踪性,以及变更控制等活动.

七、需求管理所要完成的任务

可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。需求管理需要完成的任务包括：

●明确需求并达成共识； ●建立关联； ●根据不同需求设计相应解决办法； ●进行系统优化； ●提出设计方案； ●监控和解决可能出现的问题以及需要做出的改变； ●控制不同开发任务的开展； ●对最终产品做出评测； ●监控可能出现的重复开发； ●提出项目实施时间表； ●确定最终用户界面。

有时侯我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。"需求之需求"正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。

以下篇幅分别介绍需求管理在系统工程中的不同应用。

需求共识：

首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里的"用户"泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。

需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。

根据需求设计解决办法：

我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。

系统优化：

任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。

面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。

方案设计：

明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。

必要的修改：

方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。

任务划分：

一个大的开发项目可能涉及 20-30 组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。

主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。

不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。

产品测试：

需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。

这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。

重复开发：

对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。

方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。如下图所示，用户反馈同产品开发是统一的。

项目管理的辅助：

在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或资源分配等无关。实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。

试想以下三种情况：

●一场高水准的音乐会，预算合理，演出时间却晚了两天。 ●质量优良的小轿车，交货及时，然而造价是市价的两倍。 ●一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。

这三种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。

"我付了钱，但这不是我想要的"，没有用户愿意这么说。要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束，只有这件设计充分解决了需求，它才具有里程碑般的意义。同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。

开发进程中的每一块里程碑都意味着需求的解决又前进了一步，这样的每一块里程碑也都是委托商付款的重要参照，产品开发的整个进程都可以通过需求管理进行监控。

里程碑构造机制的基本方法之一就是进程管理，一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。

通过我们对需求管理实际应用的分析，几个关键因素凸现出来。首先，需求管理在开发周期中是自始至终存在的。注意：不要把它简单理解为"需求周期"，需求管理必须始终保持更新，它构成了技术管理的基础。

其次，需求管理同项目管理是密不可分的。如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，我们就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。

八、需求管理的工具

需求管理所用到的工具必须能够处理和应用于本文所提到的各种需求，应当有助于我们分析需求，确定相应开发和支持工具以处理相关信息，进而处理系统相应模块。系统工程师始终致力于用简单的工具将需求形象化的展现出来，常用的工具比如附有标注说明的系统发布工具以及相关数据库等。

需求管理涉及到一系列复杂的对象，其任务面向很广，关系到整个设计开发的方方面面。其使用的工具应当提供如图列举的一些功能：

九、总结：需求管理

本文论述围绕于需求管理工程。需求管理是开发工作有效进行的确证。很明显需求管理是一种很高层次的系统行为，涉及整个开发过程和产品本身。

需求管理首先要针对需求做出分析，随后应用于产品并提出方案。需求分析的模型正是产品的原型样本，优秀的需求管理提高了这样的可能性：它使最终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求管理是产品质量的基础。 [url]http://www.itisedu.com/phrase/200603282323585.html/url][

需求跟踪 (Requirement Track)

为什么要进行需求跟踪？在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。确保所有的实现是以用户需求为基础。对于需求实现是否全部的覆盖。同时确保所有的输出与用户需求的符合性。

需求跟踪有两种方式，正向跟踪与逆向跟踪：

正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。 逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。 正向跟踪和逆向跟踪合称为 “双向跟踪”。不论采用何种跟踪方式，都要建立与维护《需求跟踪矩阵》。需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。矩阵单元之间可能存在 “一对一”、“一对多” 或 “多对多” 的关系。见下表：简单的需求跟踪矩阵示例。

需求代号 需求规格说明书 V1.0 设计文档 V1.2 代码 1.0 测试用例 测试记录 R001 标题或标识符 标题或标识符 代码文件名称 　 测试用例标识或名称 R002 … … … 　 … … … … … 　 …

简单的需求跟踪矩阵示例 1

使用需求跟踪矩阵的优点是很容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差，避免干冤枉活。

很多人有这样的误解：如果依照 “需求开发－系统设计－编码－测试” 这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设计、编程、测试会与需求不一致，因此可以省略需求跟踪。那么，需要指正的是，按照软件生命周期严格线性顺序的开发模型并不能保证各个开发阶段的工作产品与需求保持一致。因为开发者是人而不是机器。而且，大多数开发人员也都深有体会。

生活中 “以讹传讹” 的例子，想必大家都很熟悉。学生甲在精工实习时被机器弄破了手指，于是到医院包扎。同学乙路过医院时看到甲的手血迹斑斑，以为甲的手指被机器割断，于是将这个坏消息告诉同学丙。丙急忙转告同学丁，说甲的手被机器割断，正躺在医院里。丁十万火急地告诉全班同学，大家陷入悲痛之中，都以为 “甲的胳膊被机器割断了，正躺在医院里，人快不行了。”

由于人们的表达能力、理解能力不可能完全相同，人与人之间的协作很难达到天衣无缝的境界。而使用需求追溯的本身也是一种传递的过程。

需求追溯本身并不是一件复杂的事，而是我们的本身一种理念在支配著我们。也许就有人认为这本身就是在浪费时间，主要麻烦是，当需求或工作产品发生变更时，开发人员要及时更新需求跟踪矩阵。然而没想到的事，如果后来再花时间来做同样的事的时候，将会付出更多。也时也就丢去了本身做这件事的意义。

需求变更控制 (Requirement Change Control)

需求变更通常会对项目的进度、人力资源产生很大的影响，这是开发商非常畏惧的问题。也是必须面临与需要处理的问题。作为软件项目，特别在外地实施的工程软件项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有：

随著项目生命周期的不断往前推进，人们（包括开发方和客户方）对需求的了解越来越深入。原先的提出的需求可能存在著一定的缺陷，因此要变更需求。 市场业务需求发生了变化，原先的需求可能跟不上当前的市场业务发展，因此要变更需求。由于市场变化而导致需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了 “上一顿” 就没有 “下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。 如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。

总的而言，人们提出需求变更，本就是出于能够是产品更加符合市场或客户需求，出发点本身是好的。但对于开发小组而言，需求的变更则意味着要需要重新进行估计，调整资源、重新分配任务、修改前期工作产品等，而作为开发商，需要增预算与投资，开发组要为此付出较重的代价。假定每次需求变更请求都被接受的话，那么这个项目将会成为一个连环式的工程。

需求变更控制的动机是：

如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。 当然，好处与坏处并不是主观的，而是通过客观的分析与评价而得出的。 对于需求的变更，在某一个程度上来说，也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与，包括负责人及市场人员。当然，我们需要根据变更的内容来灵活运用。 需求变更控制过程中最难办的事情是莫过于 “拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。怎么解决这个问题呢，通常情况下，每一类 “游戏” 都有一定的游戏规则，那么我们事先也需要建立 “游戏规则”。 如果事先没有 “游戏规则” 的话，开发方的负责人需要一些社交技巧来减缓矛盾。例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。 另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。 需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。

二、为什么需要管理需求？

简单地说,系统开发团队之所以管理需求,是因为他们想让项目获得成功.满足项目需求即为成功打下了基础.若无法管理需求,达到目标的几率就会降低. 以下最近收集的证据很有说服力: Standish Group 从 1994 年到 2001 年的 CHAOS Reports 证实,导致项目失败的最重要的原因与需求有关. 2001 年,Standish Group 的 CHAOS Reports 报导了该公司的一项研究,该公司对多个项目作调查后发现,百分之七十四的项目是失败的,既这些项目不能按时按预算完成.其中提到最多的导致项目失败的原因就是"变更用户需求".

三、为什么要管理需求？

避免失败就是一个很充分的理由.提高项目的成功率和需求管理所带来的其他好处同样也是理由.Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理.

什么是需求？

理解需求管理的第一步就是对什么是需求管理达成共识.Rational 把需求定义为"(正在构建的) 系统必须符合的条件或具备的功能".电气和电子工程师学会使用的定义与此类似. 著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义,它特指软件方面 - 但不仅仅限于软件:

"软件需求可定义为: 用户解决某一问题或达到某一目标所需的软件功能. 系统或系统构件为了满足合同,规约,标准或其他正式实行的文档而必须满足或具备的软件功能."

什么是需求管理

由于需求是正在构建的系统必须符合的事务,而且符合某些需求决定了项目的成功或失败,因此找出需求是什么,将它们记下来,进行组织,并在发生变化时对它们进行追踪,这些活动都是有意义的. 换句话说,需求管理就是：一种获取,组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程.

这个定义与 Dorfman 与 Thayer 以及 IEEE 的"软件需求工程"的定义相似.需求工程包括获取,分析,规定,验证和管理软件需求,而"软件需求管理"则是对所有相关活动的规划和控制.这里介绍的以及 IBM Rational 提出的需求管理定义包括了所有这些活动.它们的区别主要在于这里选用了"管理"这个词,而不是"工程".管理这个词更合适用来描述所有涉及到的活动,并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性.

对那些不熟悉"引出"这个词的人来说,它可定义为团队用来获取或发现涉众请求,确定请求后隐藏的真正需要,以及为满足这些需要对系统提出的一组适当需求.

需求管理问题 一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢 当它真正在实际项目实施时,困难就暴露出来了.图 1 显示了年对开发人员,经理和质量保证人员所做的一次调查结果.该图显示了经历过最常提到的需求相关难题的受访者比例.

下面列出了更多与需求有关的问题:

需求不总是显而易见的,而且它可来自各个方面. 需求并不总是容易用文字明白无误地表达. 存在不同种类的需求,其详细程度各不相同. 如果不加以控制,需求的数量将难以管理. 需求相互之间以及与流程的其他可交付工件之间以多种方式相关联. 需求有唯一的特征或特征值.例如,它们既非同等重要,处理的难度也不同. 需求涉及众多相关利益责任方,这意味着需求要由跨职能的各组人员来管理. 需求发生变更. 需求可能对时间敏感. 当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时,许多团队都对管理好需求不抱希望了.IBM Rational 已经开发出指导团队提高需求管理技能和流程的专业技术,并使用相应的工具使得上述的流程和专业技术得以实现.

需求捕获

从上述的分析可以看出,需求的捕获是需求管理的基础和前提.在这里,将介绍一种为业界所广泛采用并经验证的需求捕获方法,即用例模型. 用例模型是系统既定功能及系统环境的模型,并作为客户和开发人员之间的契约.

用例模型用作分析,设计和测试活动的基本输入.用例是贯穿整个系统开发的一条主线.同一个用例模型即为需求工作流程的结果,可当作分析设计工作流程以及测试工作流程的输入使用.参与者 (Actor) 和用例 (UseCase) 是用例模型中的主要元素. 下图显示了自动取款机系统用例模型的一部分:

客户

查询

提款

转帐

客户身份验证系统时钟

数据库服务器

(from ) 系统维护

信函打印机

打印对帐单

用例图用于显示包含参与者和用例的用例模型示例.系统建模有许多种方法,每种建模方法可以满足不同的目的.然而,用例模型最重要的作用是将系统行为传达给客户或最终用户.可能与该系统交互的用户和任何其他系统都是参与者.由于参与者代表了系统用户,它们协助界定系统并提供十分明确的系统用途说明.编写用例依据参与者的需求来进行.这样就确保该系统成为用户期望得到的系统.

参与者和用例都是通过将客户需求及潜在用户当作重要的信息查找到的.找到这些用例和参与者后,应对它们作简要说明.在详细说明这些用例之前,客户应复审该用例模型以核实所有的用例和参与者都已经找到,并且它们可以提供客户所需要的东西. 在迭代开发环境中,您可以选择用例的子集以便在每个迭代中详细描述.参与者和用例找到后,需要详细说明每个用例的事件流.这些说明指出系统与参与者交互的方式以及在各个独立用例中系统执行的有关操作.

最后,对已完成的用例模型 (包括用例说明) 进行复审,开发人员和客户使用该模型对系统应执行的操作达成一致意见.

四、需求管理模型

在需求管理的流程中,需求的捕获手段固然重要,但在需求的捕获和需求最终成型的过程中,我们会面临各种和需求相关的信息和资料 (也可以把这些信息笼统地称做"需求"),如何发现这些信息之间的关系并有效组织,更为关键. 需求类型 在 RUP 中,我们采用一种金字塔方式的管理办法,来组织和管理我们获取的信息乃至最终的需求.

为了建立一个真正满足客户需求的系统,项目团队首先必须确定系统要解决的问题.然后,团队必须确定涉众,从中获得业务和用户需要,对其进行描述,并区分它们的优先级.从这一组高层期望或需求出发,对产品或系统特性集达成一致意见.而后,由产品特性来抽取软件需求,在我们的模型中,软件需求是以用例模型的方式来描述.从测试的角度来看,测试项一定来自于软件需求,即软件需求中确定了哪些需求项,测试就要根据这些需求项来制定和实现.

系统越大越复杂,出现的需求类型就越多.一个需求类型不过是指需求的一个类.通过确定需求类型,团队可以把大量需求组织成意义明确且更容易管理的组.在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类,并使相互之间的沟通更为清楚明确.从上述的分析中我们可以看到,通常,一类需求可以细分即分解成其他类型的需求.这里,我们就把需求分解为几种类型,并在他们之间建立相应的关联.业务规则和前景声明包括高层次的需求,团队可以从中导出用户需要,特性和产品需求类型.用例和其他建模形式驱动设计需求,该需求可分解为软件需求,并可以用分析设计模型来说明.测试需求源于软件需求,它被分解为具体的测试过程.如果既定项目中有成百上千个,甚至上万个需求实例时,对需求进行分类可以使项目更容易管理.上述的这些需求类型同时保存在对应的 RUP 文档和数据库中.

五、应用需求类型

通过定义需求类型,以及他们之间的关系,我们就建立了一个需求管理模型的框架. 当然,我们建立这样的一个模型,是为了方便我们使用需求,为了达到这一目的,我们还需要在此基础上添加相应的内容. 需要对各种需求类型添加它们的属性,以便于对需求进行查询等管理手段.比如,可以针对用户需要,确定该需要的必要性,优先级,确定性等属性.在实际的项目中,就可以确定这些属性的值,而后根据这些实际属性值来安排项目的进度表等.或是在项目进度紧急时,确定哪些需求是可以延期完成,而哪些是必须完成的,等等.

需求的追踪性其次,可以根据不同需求的导出情况,在不同的需求之间建立追踪关系.譬如,用户需要决定了要构建产品的特性,产品的特性又决定了产品的软件需求,等.在这些不同类型的需求之间建立关联,一旦其中的某些需求发生变化,就可以确定它可能带来的影响,从而制定相应的策略.

六、需求管理的工作流程

工作流明细简介

问题分析

问题分析可以通过了解问题及涉众的最初需要,并提出高层解决方案来实现.它是为找出"隐藏在问题之后的问题"而进行的推理和分析.问题分析期间,将对"什么是面临实际问题"和"谁是涉众"等问题达成一致.而且,您还要从业务角度界定解决方案,以及制约该解决方案的因素.您应该已经对项目进行过商业理由分析,这将便于您更好地预计能从构建中的项目中得到多少投资回报.

理解涉众需要

需求来自各个方面,比如来自客户,合作伙伴,最终用户或是某领域的专家.您需要掌握如何准确判断需求应来源于哪方面,如何接近这些来源并从中获取信息.提供这些信息主要出处的个人在本项目中称为涉众.如果您正在开发一个在您公司内部使用的信息系统, 那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员.通常讨论将在业务模型这一级上展开,而不是在系统这一级上展开.如果正在开发一个要在市场上出售的产品,那么您可以充分调动营销人员,以便更好地了解该市场中用户的需要. 获取需要的活动可使用这样一些技巧:访谈,集体讨论,概念原型设计,问卷调查和竞争性分析等.获取结果可能是一份图文并茂的请求或需要列表,并按相互之间的优先级列出.

此人经常出没于水木,哈哈哈

一个实例的同步脚本可能如下：

#!/bin/sh REPOS="$1" REV="$2" SLAVE_HOST=slave.example.com SLAVE_PATH=/my/local/copy/of/repos

# Ensure svnadmin is in $PATH on both this machine and the remote server! svnadmin dump --incremental -r$2 $1 > /tmp/$2.dump scp /tmp/$2.dump $SLAVE_HOST:$SLAVE_PATH ssh $SLAVE_HOST "svnadmin load $SLAVE_PATH < $SLAVE_PATH/$2.dump" ssh $SLAVE_HOST "rm $SLAVE_PATH/$2.dump" rm /tmp/$2.dump

进一步阅读

关于 WebDAV 代理的更多信息可以看 in the repository。 改进和 bug 修正 Copy/move-related improvements (client and server)

The abilities and behavior of copy and move operations are significantly improved in 1.5+. Improved copy-handling during updates (client and server)

A common problem in older versions of Subversion was the way in which svn update handled incoming copies and moves.

Consider this scenario: Harry runs svn move foo bar; svn commit, and meanwhile Sally makes local changes to ‘foo’, and then runs svn update. In earlier versions of Subversion, the server would send down a completely new file ‘bar’, and unversion the file ‘foo’ (if it had no uncommitted changes, Subversion would remove it entirely.) From Sally’s point of view, her changes seem to be lost; the newly added ‘bar’ file has the older content, and the file ‘foo’ has been taken out of version control.

In Subversion 1.5, the client and server both attempt to be smarter about this. The server doesn’t send a whole new file during the update, but rather instructions to copy something that likely already exists in the working copy. So Sally’s ‘foo’ file is copied to ‘bar’ (with local edits intact!).

In theory, this is the best-case scenario. There are a few caveats: this “proper copying” of existing working-copy resources only works on files, not (yet) on directories. Also, if an incoming move-operation deletes ‘foo’ before it attempts to copy it to ‘bar’, then the copy will fail, and the client reverts to the old behavior of fetching a pristine copy of the file from the repository. We hope to address this in svn 1.6.

See issue #503 for more. Peg revisions (client)

Copy and move operations now accept sources with peg (”@”) revisions.

See issue #2546 for more. Multiple working copy copy/move operations (client)

Clients may now perform chained copy/move operations locally on a single object in a working copy:

svn mv path1 path2 svn mv path2 path3

See issue #756 for more. Improved handling multiple copy/move sources (client)

Clients now accept multiple sources for copy and move operations, with the ability to copy/move each of the sources to the specified directory. This mirrors the behavior of standard command-line copy and move tools, such as cp and mv. For example:

svn mkdir new_subdir svn mv foo.txt bar.txt baz.txt new_subdir

In practice, this means users can take advantage of shell globbing when doing a local copy or move:

svn cp *.c dir

Multiple source copy/move also works for all previously defined copy/move working copy and repository combinations.

See issue #747 for more. Copy takes -rBASE (client)

Copy now understands the special revision “BASE” in a working copy (as in: “-rBASE“).

See issue #1643 for more. Creation of intermediate directories with copy/move (client and server)

See the section on the new –parents option for more about this. Cancellation improvements (client)

Clients operations are now significantly more responsive to cancellation (e.g. via control-c). In pre-1.5 releases, after directing an operation to stop, one sometimes had to wait for some time (e.g. while I/O occurred) before the operation would actually stop. Command-line client improvements (client)

There are far too many enhancements and new options to the command-line client to list them all here. Aside from all the ones mentioned already in these release notes, below are a few more that we consider important, but please see the 1.5.0 section in the CHANGES file for a complete list. New “resolve” subcommand replaces “resolved”

A new resolve subcommand replaces the “resolved” subcommand (the latter is deprecated, but still present for compatibility). The new subcommand takes a –accept=orig|mine|repo option to select which version of a file to retain (which means Subversion now supports batch-style conflict resolution).

See issue #2784 for more. Create intermediate directories if asked

Add, mkdir, copy, and move take a new –parents option, which makes intermediate directories as necessary to create the destination path.

See issue #1776 for more New –keep-local option retains path after delete.

Delete (remove) now takes a --keep-local option to retain its targets locally, so paths will not be removed even if unmodified. Commit now takes a –with-revprop option.

Commit now takes a –with-revprop option allowing one to set revision properties

See issue #1976 for more. Easier to try out experimental ra_serf DAV access module (client)

Subversion 1.4 introduced the experimental ra_serf repository access module for accessing HTTP[S] DAV Subversion servers. This uses the serf library instead of the Neon library which the original DAV support uses. serf supports pipelined requests which may lead to better performance. However, Subversion 1.4 required you to choose which module to use for accessing DAV servers at build time, which made it difficult to find out which module performs better for your usage patterns.

Subversion 1.5 allows you to build both modules at the same time; you can choose which library to use on a global or host-by-host basis by setting the http-library variable in your run-time server configuration file (~/.subversion/servers). In recognition of the fact that both libraries are DAV clients, we have renamed ra_dav to ra_neon. API changes, improvements and language bindings (client and server)

There are too many new and revised APIs in Subversion 1.5.0 to even begin to list them all here. See the Subversion API Documentation page for general API information. If you develop a 3rd-party client application that uses Subversion APIs, you should probably look at the header files for the interfaces you use and see what’s changed.

One general change is that most APIs that formerly took a recurse parameter have been upgraded to accept a depth parameter instead, to enable the new sparse checkouts feature.

Language bindings have mostly been updated for the new APIs, though some may lag more than others. Bug fixes (client and server)

A great many bugs have been fixed. See the 1.5.0 section in the CHANGES file for details. Subversion 1.3.x series no longer supported

The Subversion 1.3.x line is no longer supported. This doesn’t mean that your 1.3 installation is doomed; if it works well and is all you need, that’s fine. “No longer supported” just means we’ve stopped accepting bug reports against 1.3.x versions, and will not make any more 1.3.x bugfix releases, except perhaps for absolutely critical security or data-loss bugs. Subversion Dependencies Distribution: Binary Compatibility Issues Background

APR 0.9.x and 1.x are binary-incompatible. This means if you are already using Subversion with APR 0.9.x, and then upgrade your libapr to 1.X without rebuilding Subversion, things will break. Things will also break if your Subversion server libraries are linked to one version of APR but your Apache HTTPD server is linked to a different version.

For a long time, Subversion’s main source distribution included APR 0.9.x, which was the latest available at the time, along with a few other things (e.g., Neon, zlib) that weren’t yet widespread on installation systems. Subversion 1.5.0 Dependencies Distribution

Today, these dependencies are no longer exotic, so our source distribution contains just Subversion itself. Those building Subversion are expected to have the necessary libraries already installed, or to be able to fetch them easily. But for convenience, we still offer a “deps” distribution: it doesn’t contain Subversion, it just has source code for those third-party libraries.

Until Subversion 1.5.0, the deps distribution contained APR 0.9.x, but as of 1.5.0, we’re finally upgrading it to APR 1.x. This is because by now there are very few systems that will have binary compatibility issues, and of those, few are likely to build using the “deps” dist.

If you already have a Subversion installation using APR 0.9.x, it’s still possible to move to APR 1.x safely (although you are not required to, unless you use the deps dist). Just be sure to recompile Subversion, and Apache httpd if necessary, after upgrading APR.

Note that it’s perfectly safe to use APR 1.x from the beginning. In fact, we recommend it. If you’re building Subversion for the first time, there’s no compatibility issue to worry about, so just grab the latest version of APR (or use our deps dist).

转载自：[url]http://rocksun.cn/?p=115/url][

[[i] 本帖最后由 scmroad 于 2008-6-22 21:12 编辑 ]