]]>
openerQ在B面通过opener对象可以讉KA面?br />
parent表示父窗口，比如一个A面利用iframe或frame调用B面Q那么A面所在窗口就是B面?br />
parent?br />
在JS中，window.opener只是对弹出窗口的母窗口的一个引用。比如：(x)
a.html中，通过点击按钮{方式window.openZ个新的窗口b.html。那么在b.html中，可以通过
window.openerQ省略写为openerQ来引用a.htmlQ包括a.html的document{对象，操作a.html的内宏V?br /> 假如q个引用p|Q那么将q回null。所以在调用opener的对象前Q要先判断对象是否ؓ(f)nullQ否则会(x)
出现“对象为空或者不存在”的JS错误?br />
<html>
<body>
<form. name=form1>
<input type=text name=inpu >
<input type=button >
</form>
</body>
</html>
--------------------------------
back2opener.html
--------------------------------
<html>
<body>
<form. name=form1>
<input type=text name=inpu >
<a class=under href=# >d</a>
</form>
</body>
</html>
window.opener q回的是创徏当前H口的那个窗口的引用Q比如点M(jin)a.htm上的一个链接而打开?br />
b.htmQ然后我们打在b.htm上输入一个值然后赋予a.htm上的一个id?#8220;name”的textbox中，可?br />
写ؓ(f)Q?br />
window.opener.document.getElementById("name").value = "输入的数?;
]]>
像说里那些早慧的年Q很早就试q用例驱动的需求文案，l果与客P一个愁默默Q一个恨l늉?nbsp;
最狂热的用例编写者也承认Q用例对客户与需求h员都是一Uheavy的相互折?br> 客户看用例时总要收摄?j)神来阅L个交互的程Q还有那些该ȝ扩展异常流Q没l过E序员专业抽象训l的客户Q对着q些伪代码一般的情景脚本Q刚开始的一两个q好Q看多了(jin)Q就是白天也能睡厅R客户只是看都如此了(jin)Q负责写的h当然也不?x)好q?/p>
但heavy的工作Lheavy的好处，否则早被唑ּ于舞台的背面?br> 在用L(fng)角度Q用例比模棱两可的功能点描述要清晎ͼ也更直白于系l的价倹{?br> 在开发团队角度，RUP的核?j)方法论之一---用例驱动的口P明白然明白他的妙用?br> 设计人员有了(jin)新的设计手段Q?#8220;用时序图分析用例的实玎ͼ在描q过E中定构g或类Q分配它们的职责和方?#8221;Q通过对用例覆盖率的追t，需求与设计之间的信息损耗这个famous problem大大降低?br> 试人员和文档h员，更可以直接把pȝ用例W纳为《测试用例》和《用h册》?/p>
来到亿迅后，被这里的用例文明l震住了(jin)Q每个项目的软g规格说明都是屯门清一色的几百늚前景Q用例规U，业务规则Q词汇表Q补充规U组?......隑־有情郎啊?br> 昨天又看C(jin)一Ҏ(gu)的用例诞生，但实在有好些明显的不_Q忍不住旧事重提的记下一批经典的错误。不q?....只要能和客户达成需求共识，是一份好的用例了(jin)Q也不用花太多时间在学术性的讨论上?/p>
1.客户没有能力阅读用例
如果客户实在没办法撑住困意看完用例的l节Q即使草草签?jin)名Q得不到用户真正认的用例，依然无法用来驱动设计和测试?br> 解决Ҏ(gu)Q放弃编写用例，改回用户Ҏ(gu)看的传统方式?/p>
2.团队没有能力实现用例驱动
如果开发团队在设计与测试时Q根本不依照用例l节驱动Q那用例对开发团队就只是个摆设，q?br> 解决Ҏ(gu)Q对设计、测试h员进行用例驱动的培训Q如果事不可为就q脆攑ּQ怎么省事怎么做?strong>
3.在用例中描述pȝ内部工作
l典错误Q开发h员把用例当作设计文档来写Q如“pȝ销售信息写入数据库”Q实际上应该写的?#8220;pȝ记录销?#8221;?br> 解决Ҏ(gu)Q站在客L(fng)角度Q把pȝ视ؓ(f)黑盒Q删除所有内部设计描q?/p>
4.在用例中描述界面
另一个经兔R误，不说?jin)，如果在意用户信息包括了(jin)姓名和密码Q可以在词汇表里记录Q而用例写?-昄<用户信息>?/p>
5.在用例中出pȝ边界描述整个业务程
要徏立的pȝ只是整个业务程里的一部，善良的需求h员ؓ(f)?jin)大家清楚来龙去脉，系l外的处理步骤也写进?jin)用例的情景?br> 如：(x)
1.用户去营业厅开?br> 2.用户拨号接入
实际上去营业厅开户不属于宽带接入认证pȝ的职责?br> 解决Ҏ(gu)Q开L(fng)描述应该攑ֈ用例的前|条件中。前|与后置条g是说明系l边界外的业务流E的好地斏V?nbsp;
6.q多的用例，让h晕菜
国外的惯例，一个用例一般有半个以上人月的开发量?br> 解决Ҏ(gu)Q?br> 1.开P销戯L(fng)CRUD型用例可以合q成一个管理用例，以四个主场景分别表达?br> 2."老板问：(x)你每天做什么阿?"Q?我每天登陆系l?。这是用例没有提供_价值的明显标志?br> 3.用例中的每一个步骤，其实都可以写成一个独立的用例Q分 or 不分Q?br> 4.用例的打包组l是一门艺术，功能包、顶U目标用例，ActorQ开发团队与版本L(fng)?/p>
7.q多的扩展事件和异常事g，让h晕菜
即是受q训l的E序员，2a, 3b1看多?jin)也要晕掉，C阅读者是不是机器?nbsp;
解决Ҏ(gu)Q?br> 1.如果逻辑不多Q可以一句话讲完Q不影响d景的Q不新v一个事件流?br> 2.可以使用zd图来辅助说明。在RSM7.0的模版里Q每个用例都?x)带上一个活动图?/p>
8.q多的关p，l箋让h晕菜
“不要׃个月的时间去讨论应该includeq是extend”。大家对include, extend and generalize都不熟?zhn)Q那干脆都不要用了(jin)?nbsp;
参考材料：(x)
《编写有效用?-Wriging Effective Use Case?/strong>Corkburn 2001Q大家现在用的用例模版都是他创下来的，此书无可替代?br> 《用例模式与蓝图--Use Cases Patterns and Blueprints?/strong>我觉得比另一本名字相q的《Patterns for Effective Use Cases》要实用一?/p>
]]>
对商业用h_(d)他们后面是成百上千个供应商，前面是成千上万个消费֮。怎样利用软g理错综复杂的供应商和消贚w客，如何做好_C个小调料包的进、销、调、存的商品流通工作，q些都是商业企业需要信息管理系l的理由。Y件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软g开发成功的关键所在?
--- l理Q?#8220;我们要徏立一套完整的商业理软gpȝQ包括商品的q、销、调、存理Q是总部-门店的连锁经营模式。通过通信手段门店自动订货Q供应商自动l算Q卖场通过扫条码实现销售，理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营q的报告?#8221;
-- -分析员：(x)“我已l明白这个项目的大体l构框架Q这非常重要Q但在制定计划之前，我们必须攉一些需求?#8221;
-- -l理觉得奇怪：(x)“我不是刚告诉你我的需求了(jin)吗？”
-- -分析员：(x)“实际上，(zhn)只说明?jin)整个项目的概念和目标。这些高层次的业务需求不以提供开发的内容和时间。我需要与实际要使用pȝ的业务h员进行讨论，然后才能真正明白辑ֈ业务目标所需功能和用戯求，?jin)解清楚后，才可以发现哪些是现有lg卛_实现的，哪些是需要开发的Q这样可节省很多旉?#8221;
-- -l理Q?#8220;业务人员都在招商。他们非常忙Q没有时间与你们详细讨论各种l节。你能不能说明一下你们现有的pȝQ?#8221;
--- 分析员尽量解释从用户处收集需求的合理性：(x)“如果我们只是凭空猜想用户的要求，l果不会(x)令h满意。我们只是Y件开发h员，而不是采购专家、营q专家或是胦(ch)务专Ӟ我们q不真正明白(zhn)这个企业内部运营需要做些什么。我曄试q，未真正明白这些问题就开始编码，l果没有人对产品满意?#8221;
--- l理坚持道：(x)“行了(jin)Q行?jin)，我们没有那么多的旉。让我来告诉(zhn)我们的需求。实际上我也很忙。请马上开始开发，q时将你们的进展情况告诉我?#8221;
--- 风险w在需求的q雾之后
- --以上我们看到的是某客户项目经理与pȝ开发小l的分析人员讨论业务需求。在目开发中Q所有的目风险承担者都寚w求分析阶D备感兴。这里所指的风险承担者包括客h面的目负责人和用户Q开发方面的需求分析h员和目理者。这部分工作做得CQ能开发出很优U的Y件品，同时也会(x)令客h意。若处理不好Q则?x)导致误解、挫折、障以?qing)潜在的质量和业务h(hun)g的威胁。因此可见——需求分析奠定了(jin)软g工程和项目管理的基础?
-- -拨开需求分析的q雾
--- 像这L(fng)对话l常出现在Y件开发的q程中。客户项目经理的需求对分析人员来讲Q像“N看花”般模pƈ令开发者感到困惑。那么，我们拨开雑֪(jing)Q分析一下需求的具体内容Q?
-- -·业务需求——反映了(jin)l织机构或客户对pȝ、品高层次的目标要求，通常在项目定义与范围文档中予以说明?
--- ·用户需求——描qC(jin)用户使用产品必须要完成的dQ这在用实例或Ҏ(gu)脚本中予以说明?
--- ·功能需求——定义了(jin)开发h员必d现的软g功能Q用户利用pȝ能够完成他们的Q务，从而满了(jin)业务需求?
-- -·非功能性的需求——描qC(jin)pȝ展现l用L(fng)行ؓ(f)和执行的操作{，它包括品必遵从的标准、规范和U束Q操作界面的具体l节和构造上的限制?
--- ·需求分析报告——报告所说明的功能需求充分描qC(jin)软gpȝ所应具有的外部行ؓ(f)?#8220;需求分析报?#8221;在开发、测试、质量保证、项目管理以?qing)相关项目功能中L(fng)重要作用?
--- 前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后l工作徏立了(jin)一个指导性的框架。其他Q何说明都应遵?#8220;业务需?#8221;的规定，然?#8220;业务需?#8221;q不能ؓ(f)开发h员提供开发所需的许多细节说明?
--- 下一层次需求——用户需求，必须从用品的用户处收集。因此，q些用户构成?jin)另一UY件客P他们清楚要用该产品完成什么Q务和一些非功能性的Ҏ(gu)需求。例如：(x)E序的易用性、健壮性和可靠性，而这些特性将?x)用户很好地接受具有该特点的Y件品?
--- l理层有时试图代替实际用戯话，但通常他们无法准确说明“用户需?#8221;。用户需求来自品的真正使用者，必须让实际用户参与到攉需求的q程中。如果不q样做，产品很可能会(x)因缺乏够的信息而遗留不隐(zhn)?
--- 在实际需求分析过E中Q以上两U客户可能都觉得没有旉与需求分析h员讨论，有时客户q希望分析h员无讨论和~写需求说明就能说出用L(fng)需求。除非遇到的需求极为简单；否则不能q样做。如果?zhn)的组l希望Y件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些开发者感到困惑的斚w?
--- 优秀的Y件品徏立在优秀的需求基之上Q而优U的需求源于客户与开发h员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时Q才能徏立v一U良好的合作关系?
--- ׃目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大安惛_发出一个既能实现商业h(hun)值又能满用戯求，q能使开发者感到满的优秀软g产品?
-- -客户的需求观
-- -客户与开发h员交需要好的方法。下面徏?0条法则，客户和开发h员可以通过评审以下内容q达成共识。如果遇到分歧，通过协商达成对各自义务的怺理解Q以便减以后的擦Q如一方要求而另一方不愿意或不能够满要求Q?
--- 1?分析人员要用符合客戯a?fn)惯的表?
--- 需求讨论集中于业务需求和dQ因此要使用术语。客户应有x语（例如Q采仗印花商品等采购术语Q教l分析h员，而客户不一定要懂得计算业的术语?
--- 2、分析h员要?jin)解客户的业务?qing)目标
--- 只有分析人员更好C(jin)解客L(fng)业务Q才能产品更好地满需要。这有助于开发h员设计出真正满客户需要ƈ辑ֈ期望的优U软g。ؓ(f)帮助开发和分析人员Q客户可以考虑邀(g)请他们观察自q工作程。如果是切换新系l，那么开发和分析人员应用一下目前的旧系l，有利于他们明白目前系l是怎样工作的，其流E情况以?qing)可供改q之处。s
--- 3?分析人员必须~写软g需求报?
--- 分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及(qing)规范、功能需求、质量目标、解x法和其他信息。通过q些分析Q客户就能得C?#8220;需求分析报?#8221;Q此份报告开发h员和客户之间针对要开发的产品内容达成协议。报告应以一U客戯为易于翻阅和理解的方式组l编写。客戯评审此报告，以确保报告内容准完整地表达光求。一份高质量?#8220;需求分析报?#8221;有助于开发h员开发出真正需要的产品?
--- 4?要求得到需求工作结果的解释说明
--- 分析人员可能采用?jin)多U图表作为文字?#8220;需求分析报?#8221;的补充说明，因ؓ(f)工作图表能很清晰地描q出pȝ行ؓ(f)的某些方面，所以报告中各种图表有着极高的h(hun)|虽然它们不太难于理解Q但是客户可能对此ƈ不熟(zhn)，因此客户可以要求分析人员解释说明每个图表的作用、符L(fng)意义和需求开发工作的l果Q以?qing)怎样(g)查图表有无错误及(qing)不一致等?
--- 5?开发h员要重客户的意?
--- 如果用户与开发h员之间不能相互理解，那关于需求的讨论会(x)有障。共同合作能使大?#8220;兼听则明”。参与需求开发过E的客户有权要求开发h员尊重他们ƈ珍惜他们为项目成功所付出的时_(d)同样Q客户也应对开发h员ؓ(f)目成功q一共同目标所做出的努力表C尊重?
--- 6?开发h员要寚w求及(qing)产品实施提出和解x?
--- 通常客户所说的“需?#8221;已经是一U实际可行的实施Ҏ(gu)Q分析h员应力从这些解x法中?jin)解真正的业务需求，同时q应扑և已有pȝ与当前业务不W之处，以确保品不?x)无效或低效Q在d弄清业务领域内的事情后，分析人员p提出相当好的改进Ҏ(gu)Q有l验且有创造力的分析h员还能提出增加一些用h有发现的很有价值的pȝҎ(gu)?
--- 7?描述产品使用Ҏ(gu)?
--- 客户可以要求分析人员在实现功能需求的同时q注意Y件的易用性，因ؓ(f)q些易用Ҏ(gu)或质量属性能使客h准确、高效地完成d。例如：(x)客户有时要求产品?#8220;界面友好”?#8220;健壮”?#8220;高效?#8221;Q但对于开发h员来Ԍ太主观了(jin)q无实用价倹{正的做法是，分析人员通过询问和调查了(jin)解客h要的“友好、健壮、高效所包含的具体特性，具体分析哪些Ҏ(gu)对哪些Ҏ(gu)有负面影响Q在性能代h(hun)和所提出解决Ҏ(gu)的预期利益之间做出权衡，以确保做出合理的取舍?
--- 8?允许重用已有的Y件组?
--- 需求通常有一定灵zL，分析人员可能发现已有的某个Y件组件与客户描述的需求很相符Q在q种情况下，分析人员应提供一些修攚w求的选择以便开发h员能够降低新pȝ的开发成本和节省旉Q而不必严格按原有的需求说明开发。所以说Q如果想在品中使用一些已有的商业常用lgQ而它们ƈ不完全适合(zhn)所需的特性，q时一定程度上的需求灵zL就昑־极ؓ(f)重要?jin)?
--- 9?要求对变更的代h(hun)提供真实可靠的评?
--- 有时Qh们面临更好、也更昂늚Ҏ(gu)Ӟ?x)做Z同的选择。而这Ӟ寚w求变更的影响q行评估从而对业务决策提供帮助Q是十分必要的。所以，客户有权利要求开发h员通过分析l出一个真实可信的评估Q包括媄(jing)响、成本和得失{。开发h员不能由于不惛_施变更而随意夸大评估成本?
--- 10?获得满客户功能和质量要求的pȝ
--- 每个人都希望目成功Q但q不仅要求客戯清晰地告知开发h员关于系l?#8220;做什?#8221;所需的所有信息，而且q要求开发h员能通过交流?jin)解清楚取舍与限Ӟ一定要明确说明(zhn)的假设和潜在的期望Q否则，开发h员开发出的品很可能无法让?zhn)满意?
--- 11?l分析h员讲解?zhn)的业?
--- 分析人员要依靠客戯解业务概念及(qing)术语Q但客户不能指望分析人员?x)成领域的专Ӟ而只能让他们明白(zhn)的问题和目标；不要期望分析人员能把握客户业务的l微潜在之处Q他们可能不知道那些对于客户来说理所当然?#8220;常识”?
--- 12?抽出旉清楚地说明ƈ完善需?
--- 客户很忙Q但无论如何客户有必要抽出时间参?#8220;头脑高峰?x)?#8221;的讨论，接受采访或其他获取需求的zd。有些分析h员可能先明白?jin)(zhn)的观点，而过后发现还需要?zhn)的讲解，q时误(g)心(j)对待一些需求和需求的_工作q程中的反复Q因为它是h们交中很自然的现象Q何况这对Y件品的成功极ؓ(f)重要?
--- 13?准确而详l地说明需?
--- ~写一份清晰、准的需求文档是很困隄。由于处理细节问题不但烦(ch)且耗时Q因此很Ҏ(gu)留下模糊不清的需求。但是在开发过E中Q必解册U模p性和不准性，而客h恰是册些问题作出决定的最佳h选，否则Q就只好靠开发h员去正确猜测?jin)?
--- 在需求分析中暂时加上“待定”标志是个Ҏ(gu)。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特D需求难以解x没有人愿意处理它而标注上“待定”。客戯量每w求的内容都阐q清楚，以便分析人员能准地它们写q?#8220;软g需求报?#8221;中去。如果客户一时不能准表达，通常p求用原型技术，通过原型开发，客户可以同开发h员一起反复修改，不断完善需求定义?
--- 14??qing)时作出军_
--- 分析人员?x)要求客户作Z些选择和决定，q些军_包括来自多个用户提出的处理方法或在质量特性冲H和信息准确度中选择折衷Ҏ(gu){。有权作出决定的客户必须U极地对待这一切，快做处理，做决定，因ؓ(f)开发h员通常只有{客户做出决定才能行动，而这U等待会(x)延误目的进展?
--- 15?重开发h员的需求可行性及(qing)成本评估
--- 所有的软g功能都有其成本。客h希望的某些品特性可能在技术上行不通，或者实现它要付出极高的代h(hun)Q而某些需求试图达到在操作环境中不可能辑ֈ的性能Q或试图得到一些根本得不到的数据。开发h员会(x)Ҏ(gu)作出负面的评P客户应该重他们的意见?
--- 16?划分需求的优先U?
--- l大多数目没有_的时间或资源实现功能性的每个l节。决定哪些特性是必要的，哪些是重要的Q是需求开发的主要部分Q这只能由客戯责设定需求优先Q因为开发者不可能按照客户的观点决定需求优先Q开发h员将为?zhn)定优先U提供有x个需求的p和风险的信息?
--- 在时间和资源限制下，关于所需Ҏ(gu)能否完成或完成多少应尊重开发h员的意见。尽没有h愿意看到自己所希望的需求在目中未被实玎ͼ但毕竟是要面对现实，业务决策有时不得不依据优先来羃?yu)项目范围或廉工期Q或增加资源Q或在质量上L折衷?
--- 17?评审需求文档和原型
--- 客户评审需求文档，是给分析人员带来反馈信息的一个机?x)。如果客戯为编写的“需求分析报?#8221;不够准确Q就有必要尽早告知分析h员ƈ为改q提供徏议?
--- 更好的办法是先ؓ(f)产品开发一个原型。这样客户就能提供更有h(hun)值的反馈信息l开发h员，使他们更好地理解(zhn)的需求；原型q是一个实际应用品，但开发h员能其转化、扩充成功能齐全的系l?
--- 18?需求变更要立即联系
--- 不断的需求变_(d)?x)给在预定计划内完成的质量品带来严重的不利影响。变更是不可避免的，但在开发周期中Q变更越在晚期出玎ͼ其媄(jing)响越大；变更不仅?x)导致代h高的q工Q而且工期被延误Q特别是在大体结构已完成后又需要增加新Ҏ(gu)时。所以，一旦客户发现需要变更需求时Q请立即通知分析人员?
--- 19?늅开发小l处理需求变更的q程
--- 为将变更带来的负面媄(jing)响减到最低限度，所有参与者必遵照项目变更控制过E。这要求不放弃所有提出的变更Q对每项要求的变更进行分析、综合考虑Q最后做出合适的决策Q以定应将哪些变更引入目中?
--- 20?重开发h员采用的需求分析过E?
--- 软g开发中最h战性的莫过于收集需求ƈ定其正性，分析人员采用的方法有其合理性。也许客戯为收集需求的q程不太划算Q但L(fng)信花在需求开发上的时间是非常有h(hun)值的Q如果?zhn)理解q支持分析h员ؓ(f)攉、编写需求文档和保其质量所采用的技术，那么整个q程会(x)更ؓ(f)利?
--- “需求确?#8221;意味着什?
--- ?#8220;需求分析报?#8221;上签字确认，通常被认为是客户同意需求分析的标志行ؓ(f)Q然而实际操作中Q客户往往?#8220;{֭”看作是毫无意义的事情?#8220;他们要我在需求文档的最后一行下面签名，于是我就{了(jin)Q否则这些开发h员不开始编码?#8221;
--- q种态度带来麻?ch)，譬如客户x攚w求或对品不满时׃(x)_(d)(x)“不错Q我是在需求分析报告上{了(jin)字，但我q没有时间去d所有的内容Q我是相信你们的Q是你们非让我签字的?#8221;
--- 同样问题也会(x)发生在仅?#8220;{֭认”看作是完成Q务的分析人员w上Q一旦有需求变更出玎ͼ他便指着“需求分析报?#8221;_(d)(x)“(zhn)已l在需求上{֭?jin)，所以这些就是我们所开发的Q如果?zhn)惌别的什么，(zhn)应早些告诉我们?#8221;
--- q两U态度都是不对的。因Z可能在项目的早期׃(jin)解所有的需求，而且毫无疑问地需求将?x)出现变_(d)?#8220;需求分析报?#8221;上签字确认是l止需求分析过E的正确Ҏ(gu)Q所以我们必L白签字意味着什么?
--- ?#8220;需求分析报?#8221;的签名是建立在一个需求协议的基线上，因此我们对签名应该这L(fng)解：(x)“我同意这份需求文档表qC(jin)我们寚w目Y仉求的?jin)解Q进一步的变更可在此基U上通过目定义的变更过E来q行。我知道变更可能?x)我们重新协商成本、资源和目阶段d{事宜?#8221;寚w求分析达成一定的p?x)双方易于忍受来的摩擦，q些摩擦来源于项目的改进和需求的误差或市(jng)场和业务的新要求{?
--- 需求确认将q雾拨散Q显现需求的真面目，l初步的需求开发工作画上了(jin)双方都明的句号Qƈ有助于Ş成一个持l良好的客户与开发h员的关系Qؓ(f)目的成功奠定了(jin)坚实的基
]]>
winning project teams is appropriate. The degree of
attention paid to each can have a distinct impact on the
success of the project as well as elevating the confidence
of the business client.
是什么造就?jin)一个成功的专业目团队Q浏览一下成功的目团队所固有的特Ҏ(gu)
很好的。对每个因素的重视程度对于项目的成功和评价业务客L(fng)信Q度将有很大的
影响?br>
System Building Competence
pȝ建造能?br>
This is absolutely critical. The ability to succeed is
established within the minds of the clients as well as the
project team members in the early stages of the effort. An
essential component of this perception is both the
management ability, the technical skills, and the sense of
direction possessed by the project leadership. Both the
business clients and the team can detect fairly quickly if
the project leaders have "what it takes" to take them to a
final product. Without question this feeling has a
tremendous impact on morale.
q是l对关键的。成功的能力是在努力的早期阶D在客户的思想和项目团队成员中
建立h的。这个观点的本质在于理能力和专业技术和由项目主拥有的方向?br>上。业务客户和团队能够快速清楚的察觉目ȝ是否有带领他们向最l目标前q的
思想。毫无疑问这个感觉对士气是至关重要的?br>
Humphrey Watts in his book Managing the Software Process,
describes a model for measuring the maturity of a software
development organization. These ideas were further refined
by the Software Engineering Institute (SEI) at Carnegie
Mellon University. A brief summary of the maturity levels of
the model (in terminology which will relate to some of the
central themes of this white paper) are presented below:
Humphrey Watts在他的书《管理Y件过E》中描述?jin)一个衡量Y件开发组l成?br>度的模型。这些观点由Carnegie Mellon大学的Y件工E组l作?jin)进一步精点{有?br>模型Q有些术语与本文的一些要Ҏ(gu)养I(j)成熟层的短概括如下：(x)
Initial Level
初始?br>
A team or organization at this level tends to take a
chaotic, ad-hoc, "invent as we go" approach toward every new
systems building effort.
处于q层的团队和l织试图以一UqQ特别的Q?如我们所想的"Ҏ(gu)对待每一
个新的系l徏造工E?br>
Repeatable Level
可重复层
A team or organization at this level uses planning
techniques, gathers requirements in a systematic fashion,
utilizes software quality assurance techniques, and follows
a patterned approach on each subsequent effort.
处于q层的团队和l织通常使用~制计划技术，攉体系模式的需求，使用软g?br>量保证技术，q在后来的开发中使用模式化的Ҏ(gu)?br>
Defined Level
被定义层
A team or organization at this level follows defined
methodological steps, uses process improvement techniques to
enhance the methodological approach, conducts regular
training programs, views the entire systems development
process from an integration perspective, and utilizes more
disciplined information engineering and structured
development techniques.
处于q层的团队和l织使用定义好的Ҏ(gu)步骤Q用改q过E的技术来提高Ҏ(gu)Q?br>理有序的练?fn)程序，从综合的观点看待整个pȝ开发过E，使用更加严格的信息工
E和l构化开发技术?br>
Managed Level
被管理层
A team or organization at this level actually captures and
utilizes software development metrics for future estimation
and process analysis purposes. In addition, some of concepts
of Total Quality Management (TQM) are employed to reinforce
the effectiveness of the entire development process.
处于q层的团队和l织通常为将来的评估和过E分析捕获ƈ使用软g开发度量。另
外，整体质量理的一些概念也被用来增加整个开发过E的效力?br>
Optimized Level
优化?br>
A team or organization at this level utilizes continuous
organizational change management techniques to optimize its
own operations (as well as the company's), emphasizes defect
prevention rather than defect detection, and constantly
seeks technological innovation opportunities.
处于q层的团队和l织使用持箋的有l织的变化管理技术来优化他们的操作，
避免错误而不是发现错误，q经常寻求技术革新的Z(x)?br>
Project Team Experience
目团队的经?br>
Even within organizations with high success rates, one
factor which never changes on each new effort is the amount
of experience possessed by the chosen project team members.
Will the project team include a business expert? If not,
will the assigned members be able to effectively comprehend
and discuss the business requirements and issues in the
client terminology? Having someone on the team (even if only
in the initial phases) who understands the business is a
great confidence builder! It allows the analysts and
designers to ask the dumb or simplistic questions to someone
other than the client. This actually makes more effective
use of everyone's time and it adds an subsequent level of
security. In addition, it puts someone in the position of
making sure that "creative thinking" stays within reasonable
boundaries.
即是拥有高成功率的l织中，每个新努力中从不改变的因素是被选择的团队成?br>拥有的经历的E度。项目团队应该包括一个业务专Ӟ如果不是Q指定的成员能够?br>效的理解和讨Z务需求和客户术语中的l织Q在团队里有没有理解q项业务的h?br>个很自信的开发者？允许分析员和设计员向M问简单的问题Q而不是向客户?br>q能充分利用每个人的旉Qƈ增加后期工作的安全性。另外，它是每个人在合理?br>范围里进行创造性的思想?br>
What about technical expertise? Is the project entering
uncharted waters without a guide? Having someone on the team
who is familiar with the specialized knowledge surrounding a
selected technological environment provides the same
confidence creating benefits as those listed above. A
technical expert can assist others, make suggestions,
develop standards, and prevent time consuming mistakes. In
addition, he or she can provide leadership by example. By
spearheading the work and creating examples for others, a
technical expert can transfer knowledge and experience in a
timely and effective manner. The prevents the "invent as we
go" situation teams often find themselves in when embarking
on a new technology.
专门的技术怎样Q是不是目q入?jin)没有向导的水域Q有没有团队中的成员熟?zhn)?br>定技术领域的特定知识提供上面提到的同L(fng)信心(j)Q一个技术专家能够帮助别人，?br>出徏议，开发标准，L耗时的错误。另外，Ҏ(gu)他能通过例子提供领导能力。通过
传播工作qؓ(f)他h创造例子，一个技术专家能够以?qing)时有效的方式传播知识和l验?br>q能L当一个团队在着手于一Ҏ(gu)技术时通常发现他们处于按自己所惌行的?br>境?/p>
Project Control and Coordination
目的控制和合作
Large, complex undertakings which require the participation
of many people throughout the development process, demand
both high-level and detailed guidelines to assist in the
channeling of the individual results into an integrated
final product. As each person focuses on his or her's part
of the system, a clearly defined set of standards and
specifications must exist insure that the final result will
"mesh" with the results being produced by others. In many
ways, a systems building project can be thought of a series
of specifications, each level spiraling from broad
requirements into highly detailed procedural instructions.
The collection of these efforts into a unified whole
presents the ultimate challenge for the group. What are some
of the ways to successfully make this happen?
大型的复杂的事业需要在开发过E中很多人的参与Q需要高水^详细的设计细节来
辅助独立的成果融入最后完整的产品中。当每个Z?j)与它所负责的系l的一部分
Ӟ一个清楚的已经定义标准和规范的集合必须存在以保证最后的l果能够和其他h
的结果相d。在很多方式下，pȝ的徏造项目可以看成是一pd规范Q每层从q泛
的需求螺旋发展成为高度详l的q程指o(h)。这些努力的集合构成了(jin)一个整体，l整
个团体展现最后的挑战。那些方法能使这件事情成功的发生Q?br>
Ultimately, three major factors contribute to the level of
success that systems building team will enjoy at each of the
required integration points. One of these factors is the
creation of "consistency" standards. During each phase,
guidelines should be developed for both the content as well
as the format of the final work products. A second important
factor is cross-team communication. Common requirements,
similar issues, shared data, and reusable functionality all
should be openly discussed and coordinated. Sub-teams should
participate in the development of overall high level shared
goals and objectives which encourage cross-team interaction
and decision making. A third factor is the insistence on the
part of the top team leadership that individual and sub-team
successes be innertwined. Consistent deliverable, quality
assurance, methodological, and review standards must apply
to all team members equally.
最后，三个关键的因素将对系l徏造团队将?x)n受每个需求的l合Ҏ(gu)功别v?br>用。这些因素之一是一致性标准的建立。在每个阶段Q详l的l节必须为内容和最?br>的运行品的形式所制定。第二个重要的因素是跨团队的交流。通常的需求，怼?br>l织Q共享的数据和可复用的功能都应该被公开的讨论和协作。子团队应该参加整个
高层的开发，׃n鼓舞跨团队交互作用和决策制定的目标。第三个是代表高层领导的
坚持性，个h和子团队的成功相交互。交付的一致性，质量的保证，Ҏ(gu)和复审标?br>必须对团队的所有成员一视同仁?br>
Team Goals and Individual Objectives
团队目标和个人目?br>
A project team seems to develop a unique "personality" over
time. It becomes a reflection of everyone involved,
radiating confidence and certainty if spirits are high,
seething with doubts and confusion when direction is
lacking. How can project dynamics be so different from one
team to the next? Leadership certainly plays a vital role,
but individual team member attitudes make the difference.
一个项目团队看h时在开发一个独一无二的个性Y件。成为每个参与者的反映Q?br>如果士气高的话则充满自信和确定性，当缺乏方向时则由于疑虑和混ؕ而沸腾。怎样
才能佉K目因团队的不同而不同？领导能力当然起了(jin)一个很关键的作用，但团队成?br>的态度也会(x)造成不同影响?br>
Two fundamental questions illuminate the spirit of the group
effort. First, is everyone on the team driving toward a well
defined and articulative objective? Second, whose objective
is it? An amazing thing can happen on development projects;
everyone is busily working away on whatever it is that they
individually perceive as his or her's most important tasks.
Hopefully, each person's work will mesh with the rest of the
group's results. This will probably happen if everyone
clearly and precisely understands the ultimate phase
objectives. But what if they don't?
两个基本的问题说明了(jin)l织努力的精。首先，是不是团队的每个人都朝着已经?br>定的清楚的目标前q？W二Q这是谁的目标？在开发项目中可能发生q样令h惊讶?br>事情Q每个h都忙于她或他认ؓ(f)最重要的Q务。希望是每个人的工作都能与其他h?br>工作相吻合。如果每个h都很清楚q精的指导最l的目标则可能，但如果不是呢Q?br>
This is where human nature begins to step in and things can
begin to get interesting. If the attitudes of the team
members tend to be goal driven (which is good) but the team
leadership is fuzzy about what the objectives really are
(which is bad), individual and sometimes scattered goals
begin to pop up. Unique and potentially conflicting agendas
take shape. Before you know it everyone is busily working
away and the atmosphere appears to be productive. But an
time of reconciliation lies ahead. At some point the
individual results must be combined, and depending on the
fit, the attitude of the team will ultimately be affected.
The group's mission or purpose at this point becomes very
real, because it is at this moment that the team realizes
that there may not have really been a common direction in
the first place, and that fact is painfully obvious.
当hcd始涉的地方q且能过的兴。如果团队成员是目标驱动Q而领D对最
l的目标而疑惑，独立的或分散的目标突然出现。独自的潜在的议E出现。在你知?br>之前每个人都忙于工作Q而且是生产性的气氛。但要调和的旉摆在前面。在某个?br>上独立的l果必须合ƈQ以来与合适性，团队的态度最l会(x)被媄(jing)响。这时组l的d
或目的变得很真实Q因时团队才意识到在开始时没有统一的方向，事实昄?br>很痛苦的?br>
Why even take this risk? Insuring that goals and objectives
are clearly spelled out, and the activities and tasks which
will be followed to ultimately reach them are uniformly
understood, will only give the team a shared sense of
purpose. Everyone needs to have a stake in, and a share of,
the responsibility for the outcome of each phase. Doing this
can have an incredible impact on people's attitudes. Clearly
comprehending the relevance of the work and how it will
contribute to the final product, is a powerful motivator for
creating an air of cooperation and open channels of
communication between team members. Individual goals can be
visualized as a part of the larger team objectives. The goal
driven attitude of the team will truly be reflected in the
quality of the results.
Z么冒q个险？保目标很清楚的定Q他们所从事的Q务和zd被一律的?br>解，会(x)l整个团队一U目的共享的感觉。每个h都需要由Ҏ(gu)个阶D|果的责Q
感，׃n感。这样做肯定?x)?jing)响每个h的态度。清楚的理解工作的关键和怎样影响最
l品，是生合作环境及(qing)创造成员界交流通道的强有力的因素。独立的目标可以?br>惌成ؓ(f)大型团队目标的一部分。团队的目标d态都?x)在产品的质量中有所反映?br>
Systems Building Vision
pȝ建造的蓝图
A "vision" doesn't do anyone any good if it is only in one
person's head. Only when it has been absorbed and adopted by
the team does its usefulness begin to emerge. A business or
system "visionary" plays an important yet sometimes
unenviable role in making this happen. His or her
willingness to share insight and understanding of a
situation, and the necessary steps he or she envisions to
arrive at a desired outcome, tend to be dependant on two
factors: the level of confidence he or she has in the ideas,
and his or her tolerance for scrutiny and criticism.
Regardless of these personal risks, a professional system
builder must strive to be a system "visionary". With each
passing phase of the project, he or she must constantly
develop and communicate his or her vision of both the system
functionality and the project approach.
如果蓝图只存在于一个h的脑中则不会(x)lQ何h带来好处。只有被团队吸取和采U?br>才能使它的作用发挥出来。一个业务或pȝ?#8220;蓝图”作用重要但有时仍不能实现?br>Ҏ(gu)他的希望是共享对情况的理解和见识Qƈ采取?jin)步骤以辑ֈ理想的结果，依赖?br>两个因素Q她或他的自信程度，忍耐审查和批评的能力。不这些个人的冒险Q一?br>专业的系l徏造者必Mؓ(f)成ؓ(f)一个系l设计者而奋斗。随着每个阶段的完成，Ҏ(gu)?br>必须持箋开发和交流Ҏ(gu)他对pȝ功能和项目方法的构想?br>
Putting forward this vision assists in accomplishing two
important results. First, it creates a baseline foundation
for continuing discussion. In many cases, the original
system/approach vision may not survive for long as better
ideas are presented and improvement discussions occur.
Second, the vision promotes constructive, critical thinking.
提出构想能有处于实现两个重要的结果。首先，它创造了(jin)l箋讨论的基。在很多
情况下，最初的pȝ/Ҏ(gu)构想不能比好的思想提出和改q的讨论l持的时间长。第
二，构想提供性的严格的思考?/p>
People tend to provide more input in a "review and improve"
mode rather than a "create from scratch" mode. The
presentation of a baseline vision stimulates this process.
In addition, if the "visionary" can relinquish ownership of
the original idea, and subsequently encourage it to become
the property of the group, the effectiveness of the process
can be even more enhanced. The system builder serves to
plant the "starting point" ideas, and the team members and
business clients assist with, and take responsibility for,
the ultimate direction and composition of the shared vision.
Z更們于提供更多的输入l?#8220;复审和提?#8221;而不?#8220;从零开?#8221;的模式。最?br>的构想的提出?j)进q个q程。另外，如果“构想”能够攑ּ最初的思想的所有权Q?br>成ؓ(f)l织的胦(ch)产，q个q程的效果将?x)更加提高。系l徏造者负责生开始点的?br>惻I团队成员和业务客戯助ƈ负责׃n的构想的方向和合成?/p>
Project Team Confidence
目团队信心(j)
Another important team attitude is confidence. The
development of a complex system presents tremendous
challenges to a project team. Sometimes it can even feel
like an act of faith. An enormous amount of detail is
collected, analyzed, organized, and assimilated into a
functional "whole". On very large efforts, only a few key
individuals may possess the total "big picture", and this
may be at varying levels of completeness. This ambiguity can
from time to time test the confidence of the project team
members. Given these uncertainties, how does a team feel
assured and confident of success throughout the process, and
have this reflected in the individual team member attitudes?
另一个重要的团队是信?j)。开发复杂的pȝ会(x)l团队带来很多挑战。有时感觉是
一U信仰的zd。大量的l节被收集、分析、组lƈ吸取为整体的功能。在非常大的
付出中，仅有一些关键个人支配整?#8220;囄”Qƈ随完成的不同层次不同。这U不?br>定性时不时的检验团队成员的信心(j)。给?gu)些不定的事情，一个团队怎样才能在?br>向成功的q程中感到有保证和信?j)，q反映到团队个h的态度呢？
Clearly, the realization on the part of the team, that a
system design is formed as a gradually evolving solution,
from a process which tends to be iterative in nature, helps
everyone to be patient with the slowly disappearing level of
ambiguity. The more team members who participate on the
project who have been through the complete system building
life cycle, the more likely the overall team awareness will
be that everything will come together at each major
milestone. This is an important confidence builder for the
less experienced members of the team. The higher the level
of confidence possessed by the team, the more secure the
business clients feel, and the more likely the team will
actually "see" themselves succeeding, even in the face of
the unknown.
很明显，在团队方面的实现Q系l的设计在逐渐演化的过E中形成Q从本质上交?br>的过E，帮助每个人在不确定性逐渐消除的过E中保持忍耐。参加项目ƈl历整个p?br>l徏造生命周期的成员多Q整个团队意识在每个主要里程所有事都具备的可能?br>p大。这对于一个缺乏经验的团队成员是一个重要的信心(j)~造者。团队拥有的信心(j)
水^高Q，业务客户的安全感大Q团队就更加可能看到他们的胜利，即是面?br>未知的事情?/p>
下面单介l一下具体的使用步骤Q?br>1. 下载的Java Service Wrapper包解压到本地Q目录ؓ(f){WRAPPER_HOME}Q?br>2. 服务应用E序名ؓ(f)MyServAppQ在目录d:\MyServApp下徏立bin、conf、logs、lib目录Qƈ把你的已有应用程序如NioBlockingServer.class拯到该目录下；
3. {WRAPPER_HOME}\src\bin\下的遗以下文件拷贝到MyServApp目录下，q命名?br>{WRAPPER_HOME}\bin\Wrapper.exe ?C:\ MyServApp \bin\Wrapper.exe
{WRAPPER_HOME}\src\bin\App.bat.in ?C:\ MyServApp\bin\MyApp.bat
{WRAPPER_HOME}\src\bin\InstallApp-NT.bat.in ?C:\ MyServApp\bin\InstallMyApp-NT.bat
{WRAPPER_HOME}\src\bin\UninstallApp-NT.bat.in ?C:\ MyServApp\bin\UninstallMyApp-NT.bat
4. {WRAPPER_HOME}\lib下的以下文g拯到C:\ MyServApp \lib目录?br>{WRAPPER_HOME}\lib\Wrapper.DLL
{WRAPPER_HOME}\lib\wrapper.jar
5. {WRAPPER_HOME}\src\conf\wrapper.conf.in拯到C:\ MyServApp \conf目录下ƈ命名为wrapper.confQƈ修改wrapper.conf文gQ在其中配置(zhn)的应用服务?br>主要修改以下几项卛_Q?br>#你的JVM位置Q?br>wrapper.java.command=D:\Sun\j2sdk1.4.0_03\bin\java
#q行参数Q如Q?br>wrapper.java.additional.1=-Dprogram.name=run.bat
#classpathQ?br>wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=../bin/.
# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=../lib
#MAIN CLASS 此处军_?jin)用Java Service Wrapper的方?br>wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
#你的Java应用c?br>wrapper.app.parameter.1= NonBlockingServer
# 服务?br>wrapper.ntservice.name=NB
# Display name of the service
wrapper.ntservice.displayname=Nio Nonblocking Server
# 服务描述
wrapper.ntservice.description=Nio Nonblocking Server
其他的配|根据你的需要改变即?br>6. 对以上配|的MyApp.batq行试Q运行MyApp.batQ就像在ConsoleH口下运行Tomcat一P
7. 对以上配|的服务q行试Q运行C:\ MyServApp\bin\InstallMyApp-NT.bat把你的应用Q此处ؓ(f)NioBlockingServerQ安装到Win32pȝ服务中了(jin)?br>8. 打开控制面板Q管理程序－服务Q看到Nio Nonblocking Server已经在系l服务中?jin)，其他用法׃我们熟(zhn)的Windows服务一样了(jin)?br>
Tomcat使用的是Java Service Wrapper模式二，q种方式需要对已有的程序进行小的改动，但可以通过Socket端口的方式控制服务程序核?j)的启动Q更加灵zRJava Service Wrapper提供的模式三比较复杂Q需要作出更多的~码Q我没有研究?br>采用模式一Q即可简单有效的把我们的服务E序包装成ؓ(f)pȝ服务E序Qƈ增强?jin)日志功能，我们可以把MyServApp的几个文件做成模板，每次修改文g名，配置文g可以了(jin)Q有_֊的朋友更可以做成Eclipse的pluginQ鼠标点点就把应用配成服务了(jin)?br>
]]>
event代表事g的状态，例如触发event对象的元素、鼠标的位置?qing)状态、按下的键等{?br />
event对象只在事g发生的过E中才有效?br />
event的某些属性只对特定的事g有意义。比如，fromElement ?toElement 属性只?onmouseover ?onmouseout 事g有意义?br />
例子
下面的例子检查鼠标是否在链接上单击，q且Q如果shift键被按下Q就取消链接的蟩转?br />
<HTML>
<HEAD><TITLE>Cancels Links</TITLE>
<SCRIPT LANGUAGE="JScript">
function cancelLink() {
if (window.event.srcElement.tagName == "A" && window.event.shiftKey)
window.event.returnValue = false;
}
</SCRIPT>
<BODY onclick="cancelLink()">
下面的例子在状态栏上显C鼠标的当前位置?br />
<BODY onmousemove="window.status = 'X=' + window.event.x + ' Y=' + window.event.y">
属性：(x)
altKey, button, cancelBubble, clientX, clientY, ctrlKey, fromElement, keyCode, offsetX, offsetY, propertyName, returnValue, screenX, screenY, shiftKey, srcElement, srcFilter, toElement, type, x, y
--------------------------------------------------------------------------------
1.altKey
描述Q?br />(g)查alt键的状态?br />
语法Q?br />event.altKey
可能的|(x)
当alt键按下时Qgؓ(f) TRUE Q否则ؓ(f) FALSE 。只诅R?br />
2.button
描述Q?br />(g)查按下的鼠标键?br />
语法Q?br />event.button
可能的|(x)
0 没按?
1 按左?
2 按右?
3 按左右键
4 按中间键
5 按左键和中间?
6 按右键和中间?
7 按所有的?
q个属性仅用于onmousedown, onmouseup, ?onmousemove 事g。对其他事gQ不鼠标状态如何，都返?0Q比如onclickQ?br />
3.cancelBubble
描述Q?br />(g)是否接受上层元素的事g的控制?br />
语法Q?br />event.cancelBubble[ = cancelBubble]
可能的|(x)
q是一个可d的布?yu)(dng)?
TRUE 不被上层原素的事件控制?
FALSE 允许被上层元素的事g控制。这是默认倹{?br />
例子Q?br />下面的代码片断演CZ(jin)当在囄上点击（onclickQ时Q如果同时shift键也被按下，取消上层元素（bodyQ上的事件onclick所引发的showSrc()函数?br />
<SCRIPT LANGUAGE="JScript">
function checkCancel() {
if (window.event.shiftKey)
window.event.cancelBubble = true;
}
function showSrc() {
if (window.event.srcElement.tagName == "IMG")
alert(window.event.srcElement.src);
}
</SCRIPT>
<BODY onclick="showSrc()">
<IMG onclick="checkCancel()" src="/sample.gif">
4.clientX
描述Q?br />q回鼠标在窗口客户区域中的X坐标?
语法Q?br />event.clientX
注释Q?br />q是个只d性。这意味着Q你只能通过它来得到鼠标的当前位|，却不能用它来更改鼠标的位|?br />
5.clientY
描述Q?br />q回鼠标在窗口客户区域中的Y坐标?
语法Q?br />event.clientY
注释Q?br />q是个只d性。这意味着Q你只能通过它来得到鼠标的当前位|，却不能用它来更改鼠标的位|?br />
6.ctrlKey
描述Q?br />(g)查ctrl键的状态?br />
语法Q?br />event.ctrlKey
可能的|(x)
当ctrl键按下时Qgؓ(f) TRUE Q否则ؓ(f) FALSE 。只诅R?br />
7.fromElement
描述Q?br />(g)?onmouseover ?onmouseout 事g发生Ӟ鼠标所d的元素?参考：(x)18.toElement
语法Q?br />event.fromElement
注释Q?br />q是个只d性?br />
8.keyCode
描述Q?br />(g)键盘事件相对应的内码?br />q个属性用?onkeydown, onkeyup, ?onkeypress 事g?br />
语法Q?br />event.keyCode[ = keyCode]
可能的|(x)
q是个可d的|可以是Q何一个Unicode键盘内码。如果没有引发键盘事Ӟ则该gؓ(f) 0 ?br />
9.offsetX
描述Q?br />(g)查相对于触发事g的对象，鼠标位置的水q_?
语法Q?br />event.offsetX
10.offsetY
描述Q?br />(g)查相对于触发事g的对象，鼠标位置的垂直坐?
语法Q?br />event.offsetY
11.propertyName
描述Q?br />讄或返回元素的变化?jin)的属性的名称?br />
语法Q?br />event.propertyName [ = sProperty ]
可能的|(x)
sProperty 是一个字W串Q指定或q回触发事g的元素在事g中变化了(jin)的属性的名称?
q个属性是可读写的。无默认倹{?br />
注释Q?br />你可以通过使用 onpropertychange 事gQ得?propertyName 的倹{?br />
例子Q?br />下面的例子通过使用 onpropertychange 事gQ弹Z个对话框Q显C?propertyName 的倹{?br />
<HEAD>
<SCRIPT>
function changeProp()
{
btnProp.value = "This is the new VALUE";
}
function changeCSSProp()
{
btnStyleProp.style.backgroundColor = "aqua";
}
</SCRIPT>
</HEAD>
<BODY>
<P>The event object property propertyName is
used here to return which property has been
altered.</P>
<INPUT TYPE=button ID=btnProp onclick="changeProp()"
VALUE="Click to change the VALUE property of this button"
onpropertychange='alert(event.propertyName+" property has changed value")'>
<INPUT TYPE=button ID=btnStyleProp
onclick="changeCSSProp()"
VALUE="Click to change the CSS backgroundColor property of this button"
onpropertychange='alert(event.propertyName+" property has changed value")'>
</BODY>
12.returnValue
描述Q?br />讄或检查从事g中返回的?
语法Q?br />event.returnValue[ = Boolean]
可能的|(x)
true 事g中的Dq回
false 源对象上事g的默认操作被取消
例子见本文的开头?br />
13.screenX
描述Q?br />(g)鼠标相对于用户屏幕的水q位|?
语法Q?br />event.screenX
注释Q?br />q是个只d性。这意味着Q你只能通过它来得到鼠标的当前位|，却不能用它来更改鼠标的位|?br />
14.screenY
描述Q?br />(g)鼠标相对于用户屏幕的垂直位|?
语法Q?br />event.screenY
注释Q?br />q是个只d性。这意味着Q你只能通过它来得到鼠标的当前位|，却不能用它来更改鼠标的位|?br />
15.shiftKey
描述Q?br />(g)查shift键的状态?br />
语法Q?br />event.shiftKey
可能的|(x)
当shift键按下时Qgؓ(f) TRUE Q否则ؓ(f) FALSE 。只诅R?br />
16.srcElement
描述Q?br />q回触发事g的元素。只诅R例子见本文开头?br />
语法Q?br />event.srcElement
17.srcFilter
描述Q?br />q回触发 onfilterchange 事g的o(h)镜。只诅R?br />
语法Q?br />event.srcFilter
18.toElement
描述Q?br />(g)?onmouseover ?onmouseout 事g发生Ӟ鼠标所q入的元素?参考：(x)7.fromElement
语法Q?br />event.toElement
注释Q?br />q是个只d性?br />
例子Q下面的代码演示?jin)当鼠标Ud按钮上时Q弹Z个对话框Q显C“mouse arrived?br />
<SCRIPT>
function testMouse(oObject) {
if(oObject.contains(event.toElement)) {
alert("mouse arrived");
}
}
</SCRIPT>
:
<BUTTON ID=oButton onmouseover="testMouse(this)">Mouse Over This.</BUTTON>
19.type
描述Q?br />q回事g名?br />
语法Q?br />event.type
注释Q?br />q回没有“on”作为前~的事件名Q比如，onclick事gq回的type是click
只读?br />
20. x
描述Q?br />q回鼠标相对于css属性中有position属性的上元素的x轴坐标。如果没有css属性中有position属性的上元素Q默认以BODY元素作ؓ(f)参考对象?br />
语法Q?br />event.x
注释Q?br />如果事g触发后，鼠标UdH口外，则返回的gؓ(f) -1
q是个只d性。这意味着Q你只能通过它来得到鼠标的当前位|，却不能用它来更改鼠标的位|?br />
21. y
描述Q?br />q回鼠标相对于css属性中有position属性的上元素的y轴坐标。如果没有css属性中有position属性的上元素Q默认以BODY元素作ؓ(f)参考对象?br />
语法Q?br />event.y
注释Q?br />如果事g触发后，鼠标UdH口外，则返回的gؓ(f) -1
q是个只d性。这意味着Q你只能通过它来得到鼠标的当前位|，却不能用它来更改鼠标的位|?/p>
]]>
也不够好Q针对这ơ出现的现象Q我觉得在用h事上必须表达Z个成功的业务场景的详l描q??br /> q附带UI来说?、业务规则的说明以及(qing)用户故事验证的说明?br /> 判断一个用h事是否完成的标准是成功的业务场景的执行、业务规则的满以及(qing)是否能够通过?br /> h事验证?br /> 验证工作由on-site customer做，多数情况下on-site customer是目l理、BA或需求分析h员?br /> 通过频繁发布的持l集成版本将自己实现的用h事与用户故事验证人员q行频繁的沟通和交流?br /> 开发h员往往对细节不够重视也是造成此现象的原因Q开发h员往往只注重主体功能的完成Q但把细
节却l忽略了(jin)Q这个在以后的P代中需要进行纠正，培养开发h员对于用h事完成的概念的认识?br />2、开发h员在实现d时出C(jin)不知如何下手的现?br /> 造成q种现象的发生我觉得最主要的仍然是CRC设计以及(qing)d分解上出C(jin)问题Q按照CRC设计的要
求以?qing)Q务分解的要求q种现象出现的情况应该是不会(x)发生的，管q次team的能力是有些Ơ缺Q但
CRC设计加上d分解其实?x)Ş成非常明的详细设计以?qing)如何实现详细设计的Q务，在这点上?br /> x案就是在下一ơP代会(x)议上加强CRC设计以及(qing)d分解q两块，CRC设计一定要能通过情景?br /> 试，d分解一定要分解的够清晎ͼ让开发h员都能明白是怎么做的Q至于碰到难点的地方自然?br /> 先安排ؓ(f)Spiked?br />3、开发h员在q行d跟踪时出现偏ȝ现象
开发h员仍然没能Ş成很好的d跟踪的习(fn)惯，q点只能不断的纠正，培养开发h员Ş成这L(fng)?br /> 惯?br />4、接口依赖造成的瓶颈现?br /> q是此次q代出现的一个较大的问题Q未形成一个P代中的接口依赖的全貌图，D?jin)在d分配?br /> 接口依赖常常集中在一个h的n上，出现?jin)瓶颈现象，q点在第二个q代中需要改q，增加整个q代
的接口依赖图Q这个可Ҏ(gu)CRC设计提取形成?br />5、Q务自行挑选造成的Q务完成有隑ֺ的现?br /> 此次q代中出C(jin)q个现象Q部分h员挑选了(jin)过其能力很多的dQ最后导致了(jin)d完成的过E中
出现?jin)很多的问题Q这个我仍然觉得一斚w是CRC设计的问题，另一斚w是缺PP的原因?br />6、持l集成失败次数过多的现象
此次q代中造成持箋集成p|的原因竟然多是测试代码编写的不正以?qing)测试代码对于运行数据的?br /> 赖，q个我在目ȝ?x)议上进行?jin)讲解Q由于这个项目压力太大，而且team能力实有些不Q所
以我未强制执行TDDQ不q仍然极度鼓励；W二个原因则是在造成?jin)持l集成失败后未列为最高优?br /> U的事去做?br />q次出现q些问题虽然有些是和团队个h相关Q但我更多的认ؓ(f)q就是整个团队的责QQ而不是某个h的，因此在第二个q代中我仍然是以培养整个团队的一致荣誉感为首Qƈ且仍然给予团队够的I间以及(qing)充分的信任；而且在第一ơP代中出现q些问题也是好事Q毕竟这是一支全新的团队Q在团队能力Ơ缺的情况下我对于团队的表现是比较满意的Q在后箋我仍然的更多是依靠交、反馈以?qing)共同作战来弥补上面的问题，而不是依靠制度和强制性的监督?br />比较可喜的是Team开始接受整个Y件过E，TDD也开始得到接受，而且team成员的能力提升也是比较的明显Q这其实Ҏ(gu)而言已l达到目标了(jin)Q相信这L(fng)一支团队是不会(x)让我失望的?/font>
]]>
echo 表示昄此命令后的字W?br />echo off 表示在此语句后所有运行的命o(h)都不昄命o(h)行本w?br />@ 与echo off相象Q但它是加在其它命o(h)行的最前面Q表C行时不显C命令行本n?br />call 调用另一条批处理文gQ如果直接调用别的批处理文g Q执行完那条文g后将无法执行当前文g后箋命o(h)Q?br />pause q行此句?x)暂停，昄Press any key to continue... {待用户按Q意键后l?
rem 表示此命令后的字Wؓ(f)解释行，不执行，只是l自׃后查扄?br />
例：(x)用edit~辑a.bat文gQ输入下列内容后存盘为c:\a.batQ执行该批处理文件后可实玎ͼ(x)根目录中所有文件写?a.txt中，启动UCDOSQ进入WPS{功能?
批处理文件的内容? 文g表示Q?
echo off 不显C命令行
dir c:\*.* >a.txt c盘文件列表写入a.txt
call c:\ucdos\ucdos.bat 调用ucdos
echo 你好 昄"你好"
pause 暂停,{待按键l箋
rem 使用wps 注释用wps
cd ucdos q入ucdos目录
wps 使用wps
批处理文件中q可以像C语言一样用参敎ͼq只需用到一个参数表C符%?
%表示参数Q参数是指在q行批处理文件时在文件名后加的字W串。变量可以从 %0?9Q?0表示文g名本w，字符串用%1?9序表示?
例如QCQ根目录下一批处理文件名为f.batQ内容ؓ(f) format %1
则如果执行C:\>f a: 则实际执行的是format a:
又如CQ根目录下一批处理文件的名ؓ(f)t.batQ内容ؓ(f) type %1 type %2
那么q行C:\>t a.txt b.txt 顺序地昄a.txt和b.txt文g的内?
]]>