2005年02月18日

Just a test

power test
test 2′

test end;

2004年10月27日

(1)Options

Key for the type column: F=file, G=grammar, R=rule, L=lexer, S=subrule, C=C++ only.

Symbol

Type

Description

language

F

Set the generated language

k

G

Set the lookahead depth

importVocab

G

Initial grammar vocabulary

exportVocab

G

Vocabulary exported from grammar

testLiterals

LG,LR

Generate literal-testing code

defaultErrorHandler

G,R

Control default exception-handling

greedy

S

False implies you want subrule loop, (..)* and (..)+, to exit when it sees lookahead consistent with what follows the loop.

codeGenMakeSwitchThreshold

G

Control code generation

codeGenBitsetTestThreshold

G

Control code generation

buildAST

G

Set automatic AST construction in Parser (transform mode in Tree-Parser)

analyzerDebug

G

Spit out lots of debugging information while performing grammar analysis.

codeGenDebug

G

Spit out lots of debugging information while doing code generation.

ASTLabelType

G

Specify the type of all user-defined labels, overrides default of AST.

charVocabulary

LG

Set the lexer character vocabulary

interactive

G

Both the lexer and the parser have an interactive option, which defaults to “false”. See the parser speed section above.

caseSensitive

LG

Case is ignored when comparing against character and string literals in the lexer. The case of the input stream is maintained when stored in the token objects.

ignore

LR

Specify a lexer rule to use as whitespace between lexical rule atomic elements (chars, strings, and rule references). The grammar analysis and, hence, the lookhaead sets are aware of the whitespace references. This is a lexer rule option.

paraphrase

LR

An easy way to specify a string to use in place of the token name during error processing.

caseSensitiveLiterals

LG

Case is ignored when comparing tokens against the listerals table.

classHeaderPrefix

G

Replace the usual class prefix (“public” in Java) for the enclosing class definition.

classHeaderSuffix

G

Append a string to the enclosing class definition. In Java, this amounts to a comma-separated list of interfaces that your lexer, parser, or tree walker must implement.

mangleLiteralPrefix

F

Sets the prefix for the token type definitions of literals rather than using the default of “TOKEN_“.

warnWhenFollowAmbig

S

Warnings will be printed when the lookahead set of what follows a subrule containing an empty alternative conflicts with a subrule alternative or when the implicit exit branch of a closure loop conflicts with an alternative.  The default is true.

generateAmbigWarnings

S

When true, no ambiguity/nondeterminism warning is generated for the decision associated with the subrule.  Use this very carefully–you may change the subrule and miss an ambiguity because of the option.  Make very sure that the ambiguity you mask is handled properly by ANTLR.  ANTLR-generated parsers resolve ambiguous decisions by consuming input as soon as possible (or by choosing the alternative listed first).

See the Java and HTML grammars for proper use of this option.  A comment should be supplied for each use indicating why it is ok to shut off the warning.

filter

LG

When true, the lexer ignores any input not exactly matching one of the nonprotected lexer rules.  When set to a rule name, the filter option using the rule to parse input characters between valid tokens or those tokens of interest.

namespace

FGC

When set, all the C++ code generated is wrapped in the namespace mentioned here.

namespaceStd

FGC

When set, the ANTLR_USE_NAMESPACE(std) macros in the generated C++ code are replaced by this value. This is a cosmetic option that only makes the code more readable. It does not replace this macro in the support C++ files. Note: use this option directly after setting the language to C++.

namespaceAntlr

FGC

When set, the ANTLR_USE_NAMESPACE(antlr) macros in the generated C++ code are replaced by this value. This is a cosmetic option that only makes the code more readable. It does not replace this macro in the support C++ files. Note: use this option directly after setting the language to C++.

genHashLines

FGC

Boolean toggle, when set to ‘true’ #line <linenumber> “filename” lines are inserted in the generated code so compiler errors/warnings refer the .g files.

noConstructors

FGLC

Boolean toggle, when set to ‘true’ the default constructors for the generated lexer/parser/treewalker are omitted. The user then has the option to specify them himself (with extra initializers etc.)

 

2004年09月24日

高级口译,日语三级,软件设计师,在职研究生

妈的,估计一个都没戏。

2004年09月17日

留意留意Web Service,  WorkFlow, EAI等方面的东西。

中间件与Web Services
http://www.uml.org.cn/WebService/WebService100801.htm

EAI和Web服务 – 轻松进行企业应用集成
http://www-900.ibm.com/developerWorks/cn/webservices/ws-eai/cxl/index.shtml

什么是Web Service
http://www.sawin.com.cn/doc/SA/NewTech/webservice1.htm

IBM developerWorks: Web Service专区
http://www-900.ibm.com/developerWorks/cn/webservices/index.shtml

Web Services开发篇
http://tech.ccidnet.com/pub/article/c317_a24768_p1.html

面向服务架构(SOA)的原则
http://www.umlchina.com/News/Content/39.htm

向Web Service进军--Axis+Tomcat模拟一个银行存取款服务
http://info.tlw.cn/22227.htm

A OpenSource WorkFlow Project: OpenWFE
http://openwfe.sourceforge.net/

OBE – Open Business Engine
http://www.openbusinessengine.org/index.html

程序员的窝- 工作流(workflow)专题
http://www.delfan.com/workflow/

山南水北-工作流
http://udoo.51.net/mt/archives/000136.html

Java与工作流
http://www.javaflow.net/index.php

2004年09月14日

最近不忙,一直在研究一些开源的java开发的框架,越研究越有一丝说不出的惶恐,不是因为我的无知和我对java世界的陌生,而是在想,我们到底要干些什么,java社团日新月异,新概念新东西层出不穷,我们一直时髦地跟着潮流走,有没有想过根源在哪里?什么才是软件开发中最最基本的东西?很多人喜欢把软件业和建筑业相提并论,那打个不恰当的比喻,我们现在更像是搞装潢的而不是建筑师,我们的自由仅仅在于安装什么样的地板,挂什么样的吊顶,贴什么样的墙纸。可真正建筑的灵魂在哪里?软件开发的精髓又在哪里?以我的能力和经验,我总结不出,希望能有高明之士醍醐灌顶,期待光明使者的出现。

 

Taglib

《深入浅出taglib》
http://www.javaresearch.org/article/showarticle.jsp?column=106&thread=9477

taglib简介
http://www-900.ibm.com/developerWorks/cn/java/j-jsp07233/index.shtml?ca=dwcn-isc&me=ccid

《Taglib学习笔记》
http://www.csdn.net/develop/Read_Article.asp?Id=27159

Tapestry

取代JSP的新技术-tapestry
http://www.chinaunix.net/jh/26/224472.html

Tapestry介绍和实例
http://www.matrix.org.cn/blog/magicgod/archives/week_2004_08_08.html#000617

2004年09月10日

我们对这里的各个property元素一一说明:

  • dialect:使用了Oracle9的对照
  • connection.driver_class:Oracle的JDBC驱动类名
  • connection.username:Oracle数据库访问用户名
  • connection.password:Oracle数据库访问密码
  • connection.url:Oracle数据库访问URL
  • connection.pool.size:数据库连接池大小
  • statement_cache.size:JDBC statement缓冲大小
  • jdbc.fetch_size:设定JDBC的Statement读取数据的时候每次从数据库中取出的记录条数
  • jdbc.batch_size:设定对数据库进行批量删除,批量更新和批量插入的时候的批次大小
  • show_sql:设定是否在控制台上显示向数据库提交的SQL语句,在开发调试时比较有用

提下来的mapping resource则是我们对数据库表的一个个的映射文件的清单

2004年09月08日

作了一个性格测试,结果如下:

性格类型:ISFP ISFP型的人平和、敏感,他们保持着许多强烈的个人理想和自己的价值观念。他们更多地是通过行为而不是言辞表达自己深沉的情感。ISFP型的人谦虚而缄默,但实际上他们是具有巨大的友受和热情之人,但是除了与他们相知和信赖的人在一起外,他们不经常表现出自我的另一面。因为ISFP型的人不喜欢直接地自我表达,所以常常被误解。ISFP型的人耐心、灵活,很容易与他人相处,很少支配或控制别人。他们很客观,以一种相当实事求是的方式接受他人的行为。他们善于观察周围的人和物,却不寻求发现动机和含义。 ISFP型的人完全生活在现在,所以他们的准备或计划往往不会多于必需,他们是很好的短期计划制定者。因为他们喜欢享受目前的经历,而不继续向下一个目标兑现,所以他们对完成工作感到很放松。 ISFP型的人对于从经历中直接了解和感受的东西很感兴趣,常常富有艺术天赋和审美感,力求为自己创造一个美丽而隐蔽的环境。 没有想要成为领导者,ISFP型的人经常是忠诚的追随者和团体成员。因为他们利用个人的价值标准去判断生活中的每一件事,所以他们喜欢那些花费时间去认识他们和理解他们内心的忠诚之人。他们需要最基本的信任和理解,在生活中需要和睦的人际关系,对于冲突和分歧则很敏感。

适合领域 手工艺、艺术领域 医护领域 商业、服务业领域

适合职业 时装、首饰设计师、装潢、园艺设计师、陶器、乐器、卡通、漫画制作者、素描画家、舞蹈演员、画家等 出诊医生、出诊护士、理疗师、牙科医生、个人健康和运动教练等 餐饮业、娱乐业业主、旅行社销售人员、体育用品、个人理疗用品销售员等

看来我的确不适合做程序员哩,呵呵。

还有一份类似者的职业发展报告:

内向 感觉 情感 知觉于 ISFP——“思想起决定作用”
基本描述:
  • 你和蔼、友善、敏感,谦虚地看待自己的能力。你能平静愉悦地享受目前的生活,喜欢体验。珍视自由自在地安排自己的活动,有自己的空间,支配自己的时间。
  • 你善于观察、务实、讲求实际,了解现实和周围的人,并且能够灵活地对他们的情况和需要做出反应,但很少寻求其动机和含义。你是优秀的短期规划者,能够全身心地投到此时此刻的工作中,喜欢享受现今的经验而不是迅速冲往下一个挑战。
  • 你有耐心,易通融,很好相处。你没有领导别人的愿望,往往是忠实的跟随者和很好的合作伙伴。你很客观,而且能以一种实事求是的态度接受他人的行为,但你需要基本的信任和理解,需要和睦的人际关系,而且对矛盾和异议很敏感。
  • 你很有艺术天份,对自然的美丽情有独钟,对直接从经验中和感觉中得到的信息非常感兴趣,喜欢为自己创造一种幽雅而个性化的环境,你希望为社会的福利和人类的幸福做些贡献。你内心深沉,其实很热情,不太喜欢表现。

可能的盲点:

  • 你完全着眼于现在,从不喜欢寻找和发现那些你认为不存在的可能性,这使你无法发现更广阔的前景,也不能为将来做打算,不能很好地安排时间和精力。
  • 你天生对他人具有高度的敏感,总是难以拒绝别人,有时为了满足他人的需求而拼命地工作,以至于在此过程中忽视了自己。
  • 你过分忽视事物之间的内在联系和逻辑思考,难以理解复杂的事情。
  • 你对他人的批评会感到生气或气馁,有时容易过分自责。你容易相信别人,很少对别人的动机有所怀疑,也不会发现别人行为背后的隐含意义。你们需要更注重自己的需求,而且要对别人的行为加以分析。在分析中加入一些客观和怀疑的态度会让你们更准确地判断人的性格。

动力分析
动力是指人们深层次的内在驱动力,直接影响到人的决策、行事、自信、毅力等各个方面,也是影响一个人绩效的深层因素。不同的动力,反映出你在工作中不同的特点、不同的行为特点,及对组织不同的态度。

动力结果(百分比)
成功愿望 29
影响愿望 21
回避失败 95
情绪稳定 31

具有审慎、缄默、温和、无争的特点。影响和控制愿望不高,通常不过多地发表个人的看法和见解,干事踏实,勤恳,谨慎小心,工作没有过高的要求;为人比较温和。

在工作中,有一定的执行倾向,通常能够在团体中发挥一定的作用,对上级指示和要求,一般能够组织下属开展工作,通常不会采取强制性的组织和管理措施。能够与上下级和谐相处,但尽量避免协调复杂的人际关系。对自己的工作任务负责、认真,但没有过高的要求,不求有功,但求无过。对矛盾、冲突、困难和挫折非常敏感,易受无关因素影响,往往采取回避的态度。


适合的岗位特质
研究发现:职业满足会使你的工作主动性更强,积极性更高,更愿意去工作。以下不是简单的告诉你什么样的工作适合你,而是细化的帮你分析工作中的哪些特质对你重要,你还需要从中选出你认为最重要的,因为不同经历的人对特质的重要程度要求是不同的。每个岗位的工作内容都在随企业的发展而发展,不是一成不变的,有时候岗位的发展方向需要我们自己去争取。所以找到适合的工作不如找到适合自己发展的岗位更直接。这些特质可以帮助明确如何主动的发展或争取你岗位中的那些特质。

下面的条目从各个侧面验证了您怎样才能感受到真正的职业满足,看完这些条目之后,我们建议您根据它们对您的重要程序进行排序,排序的时候,回想一下您过去的学习、工作经历以及当前学习环境和工作感受,并思考:“哪一些是令你感到特别满意,有哪些令你极其不高兴”。试着寻找贯穿这些经历的主题。

你的岗位特质:

  • 在活跃的、合作的环境下工作,最小限度的人际冲突
  • 作为对集体忠诚和乐于合作的一员,在彼此积极支持的气氛下工作
  • 工作要求关注细节,切实,能够快速处理问题,提供实际帮助
  • 有独立工作的自由,周围的人必须和谐有礼貌,工作中没有太多的规则、结
    构、僵化的程序
  • 符合你的内在价值观和审美情趣
  • 工作不要求例行公事的公开讲话,或总是拒绝别人

职业类型

本页内容通过将你的测试结果与具体工作相匹配,使你能更深入理解自己的特质,从而拓宽择业视角,绝非要限制你的工作选择面。工作名称的列举不是要告诉你“你仅仅适合这些工作”,而是期望在面对新工作机会时,你能独立的对工作进行分析,确定自己的特质与工作的吻合程度。

适合的职业

  • 你非常喜欢那些可以通过双手创造出美丽、吸引人同时又有用的东西的职业并且这些职业可以给你提供灵活自由的空间。与本特质相关的职位包括: 室内/风景设计师、宝石设计师、画家、演员、服装设计师、乐器制造、漫画/卡通制作、厨师等。
  • 医疗保健事业可以给许多像你这样特点的人带来成就感,在那里你可以直接接触到病人,做细致的观察,迅速及时的解决问题,给他们提供身体和精神上的帮助。与本特质相关的职位包括: 牙医、药剂师、外科医生、营养学者、康复专家、职业咨询师等。
  • 你做事灵巧、细致,那些户外的,可以接触实事,变化丰富的工作也是你该考虑的。与本特质相关的职位包括: 植物/动物/生物学者、地质/考古学者、摄像师、计算机操作员、系统分析师、检查员等。
  • 在服务性行业中,通过具体的、切实的方式帮助他人、关心他人,是自己价值观的体现。与本特质相关的职位包括: 文科教师、警察、美容专家、策划、翻译人员、社会工作人员、客户销售代表、工程师、娱乐工作者、消防员、野外探险领导者、保险鉴定人等。

深入思考

  1. 在不同企业文化中,即使同样的职业,也会有大相径庭的工作内容。除了工作名称之外,我们更应该深入关注工作的具体内容,及相应的企业文化。
  2. 当今时代,经济飞速发展,新型工作不断涌现,上面罗列的职业肯定不是所有适合你工作的综合,但却能向你展示此前你很少考虑的工作可能性!你需要发掘这些不同工作种类背后的东西—与你性格/动力特点相匹配的部分。

个人发展建议

现在你对自己的人格类型和动力已经有了一个比较清楚的了解,但这还不够。“如何通过这些信息使你在这份工作上取得更大的成功”这是关健所在。

运用你的能力非常容易,你成功的秘决在于:

  • 学会更好的沟通,表达自己的内心感受和观点
  • 在一定高度下考虑问题,发展你的前瞻性
  • 客观公正,不要太个人化的看待事物

个人发展建议是我们咨询师多年测评职业咨询和职业生涯规划的心得体会和经验总结,我们意识到以下的建议中有很多是难以完全照办的,但只要你花时间认真思考,一定会对你有极大的帮助和改变:

发展建议:

  • 需要学会怀疑和挑战他人的观点,深入分析外界信息,而不是一味接受
  • 学会规划和计划,更多考虑长远发展的前景
  • 需要更果敢和更直接地对待他人,学会说“不”
  • 尽量理智客观的对待事情的结果
  • 增强做事的主动性,并注意不要在竞争激烈的环境中工作
  • 不要过于陷入细节,随时关注事情的发展方向与变化
  • 增强对整体和全局的关注
  • 尽量理智客观的考虑问题,减少无关因素的影响
  • 增强做事的计划性和条理性,以及持续推进工作的韧性
  • 注意解决问题的灵活性

 

这篇文章原文在http://www.systemmobile.com/articles/IntroductionToHibernate.html,是由 Nick Heudecker 根据自己的经验而撰写的 Hibernate 教程,该教程篇幅适度,适合 Hibernate 初学者和希望了解 Hibernate 的开发者。我尝试着把它翻译成了中文。第一次正而八经的翻译技术文章。hehe……

一个企业应用的开发中有很大一部分工作都涉及到持久化层的创建和维护,这些持久化层主要用来从数据库中存贮和获取对象。很多组织都采取自己开发持久化层的方式,但是这些自己开发的代码往往问题成堆。如果是数据库底层的设计发生变化,那么当这些变化影响到整个应用的其它部分时,代价将是十分昂贵的。Hibernate试图去消除这些不足之处,它为Java应用提供了一个易于使用但却无比强大的面向对象持续化框架。

Hibernate是按照GNU协议发布的,是一个开源项目,这说明你可以在你的商业应用中使用Hibernate。它支持很多数据库,包括Oracle和DB2,以及一些广泛使用的开源数据库比如PostgreSQL和MySQL。它还有一个用户社区对用户提供帮助,也提供一些可以扩展Hibernate的工具,使得使用Hibernate更加容易。

这篇文章适用于Hibernate 2.1,这个版本于2003年12月发布。

Hibernate如何工作

Hibernate使用运行时反射机制来决定一个类的持久化属性,这种方法比使用字节码处理机制或者代码生成的方法要好。

 

未完待续……

翻译这事还真不好干,又要尽可能的阐述原文的意思,又要流畅的用中文表达出来,还真累。刚刚翻译一小段就感觉有点吃力了,希望能坚持下去。

转macro关于需求分析的一篇好文:

客户与开发人员交流需要好的方法。下面建议20条法则,客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧,将通过协商达成对各自义务的相互理解,以便减少以后的磨擦(如一方要求而另一方不愿意或不能够满足要求)。 

1、 分析人员要使用符合客户语言习惯的表达 

  需求讨论集中于业务需求和任务,因此要使用术语。客户应将有关术语(例如:采价、印花商品等采购术语)教给分析人员,而客户不一定要懂得计算机行业的术语。 

2、分析人员要了解客户的业务及目标 

  只有分析人员更好地了解客户的业务,才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员,客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统,那么开发和分析人员应使用一下目前的旧系统,有利于他们明白目前系统是怎样工作的,其流程情况以及可供改进之处。s 

3、 分析人员必须编写软件需求报告 

  分析人员应将从客户那里获得的所有信息进行整理,以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析,客户就能得到一份“需求分析报告”,此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告,以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。 

4、 要求得到需求工作结果的解释说明 

  分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明,因为工作图表能很清晰地描述出系统行为的某些方面,所以报告中各种图表有着极高的价值;虽然它们不太难于理解,但是客户可能对此并不熟悉,因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果,以及怎样检查图表有无错误及不一致等。 

5、 开发人员要尊重客户的意见 

  如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间,同样,客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。 

6、 开发人员要对需求及产品实施提出建议和解决方案 

  通常客户所说的“需求”已经是一种实际可行的实施方案,分析人员应尽力从这些解决方法中了解真正的业务需求,同时还应找出已有系统与当前业务不符之处,以确保产品不会无效或低效;在彻底弄清业务领域内的事情后,分析人员就能提出相当好的改进方法,有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。 

7、 描述产品使用特性 

  客户可以要求分析人员在实现功能需求的同时还注意软件的易用性,因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如:客户有时要求产品要“界面友好”或“健壮”或“高效率”,但对于开发人员来讲,太主观了并无实用价值。正确的做法是,分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性,具体分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案的预期利益之间做出权衡,以确保做出合理的取舍。 

8、 允许重用已有的软件组件 

  需求通常有一定灵活性,分析人员可能发现已有的某个软件组件与客户描述的需求很相符,在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间,而不必严格按原有的需求说明开发。所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合您所需的特性,这时一定程度上的需求灵活性就显得极为重要了。 

9、 要求对变更的代价提供真实可靠的评估 

  有时,人们面临更好、也更昂贵的方案时,会做出不同的选择。而这时,对需求变更的影响进行评估从而对业务决策提供帮助,是十分必要的。所以,客户有权利要求开发人员通过分析给出一个真实可信的评估,包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。 

10、 获得满足客户功能和质量要求的系统 

  每个人都希望项目成功,但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制,一定要明确说明您的假设和潜在的期望,否则,开发人员开发出的产品很可能无法让您满意。 

11、 给分析人员讲解您的业务 

  分析人员要依靠客户讲解业务概念及术语,但客户不能指望分析人员会成为该领域的专家,而只能让他们明白您的问题和目标;不要期望分析人员能把握客户业务的细微潜在之处,他们可能不知道那些对于客户来说理所当然的“常识”。 

12、 抽出时间清楚地说明并完善需求 

  客户很忙,但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论,接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点,而过后发现还需要您的讲解,这时请耐心对待一些需求和需求的精化工作过程中的反复,因为它是人们交流中很自然的现象,何况这对软件产品的成功极为重要。 

13、 准确而详细地说明需求 

  编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时,因此很容易留下模糊不清的需求。但是在开发过程中,必须解决这种模糊性和不准确性,而客户恰恰是为解决这些问题作出决定的最佳人选,否则,就只好靠开发人员去正确猜测了。 

  在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚,以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达,通常就要求用原型技术,通过原型开发,客户可以同开发人员一起反复修改,不断完善需求定义。 

14、 及时作出决定 

  分析人员会要求客户作出一些选择和决定,这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切,尽快做处理,做决定,因为开发人员通常只有等客户做出决定才能行动,而这种等待会延误项目的进展。 

15、 尊重开发人员的需求可行性及成本评估 

  所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通,或者实现它要付出极高的代价,而某些需求试图达到在操作环境中不可能达到的性能,或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价,客户应该尊重他们的意见。 

16、 划分需求的优先级 

  绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的,哪些是重要的,是需求开发的主要部分,这只能由客户负责设定需求优先级,因为开发者不可能按照客户的观点决定需求优先级;开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。 

  在时间和资源限制下,关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对现实,业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷。 

17、 评审需求文档和原型 

  客户评审需求文档,是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确,就有必要尽早告知分析人员并为改进提供建议。 

  更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员,使他们更好地理解您的需求;原型并非是一个实际应用产品,但开发人员能将其转化、扩充成功能齐全的系统。 

18、 需求变更要立即联系 

  不断的需求变更,会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的,但在开发周期中,变更越在晚期出现,其影响越大;变更不仅会导致代价极高的返工,而且工期将被延误,特别是在大体结构已完成后又需要增加新特性时。所以,一旦客户发现需要变更需求时,请立即通知分析人员。 

19、 遵照开发小组处理需求变更的过程 

  为将变更带来的负面影响减少到最低限度,所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后做出合适的决策,以确定应将哪些变更引入项目中。 

20、 尊重开发人员采用的需求分析过程 

  软件开发中最具挑战性的莫过于收集需求并确定其正确性,分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算,但请相信花在需求开发上的时间是非常有价值的;如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利。