﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-努力创造未来！-随笔分类-软件工程</title><link>http://www.blogjava.net/pdw2009/category/18303.html</link><description>J2EE相关应用技术日志</description><language>zh-cn</language><lastBuildDate>Sun, 11 Nov 2007 11:36:44 GMT</lastBuildDate><pubDate>Sun, 11 Nov 2007 11:36:44 GMT</pubDate><ttl>60</ttl><item><title>成功的项目团队Winning Project Teams (转)</title><link>http://www.blogjava.net/pdw2009/archive/2007/04/12/110202.html</link><dc:creator>有猫相伴的日子</dc:creator><author>有猫相伴的日子</author><pubDate>Thu, 12 Apr 2007 08:17:00 GMT</pubDate><guid>http://www.blogjava.net/pdw2009/archive/2007/04/12/110202.html</guid><wfw:comment>http://www.blogjava.net/pdw2009/comments/110202.html</wfw:comment><comments>http://www.blogjava.net/pdw2009/archive/2007/04/12/110202.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/pdw2009/comments/commentRss/110202.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/pdw2009/services/trackbacks/110202.html</trackback:ping><description><![CDATA[By Russ Finney
<p>（来自软件工程论坛 seforum.yeah.net）<br>&nbsp;(翻译yanrj )</p>
<p><br>&nbsp;<br>What makes a winning techical project team? A quick look at <br>some of the factors which seem to be consistently present on <br>winning project teams is appropriate. The degree of <br>attention paid to each can have a distinct impact on the <br>success of the project as well as elevating the confidence <br>of the business client. </p>
<p>是什么造就了一个成功的专业项目团队？浏览一下成功的项目团队所固有的特点是<br>很好的。对每个因素的重视程度对于项目的成功和评价业务客户的信任度将有很大的<br>影响。<br>&nbsp;<br>System Building Competence<br>&nbsp;&nbsp; 系统建造能力<br>&nbsp;<br>This is absolutely critical. The ability to succeed is <br>established within the minds of the clients as well as the <br>project team members in the early stages of the effort. An <br>essential component of this perception is both the <br>management ability, the technical skills, and the sense of <br>direction possessed by the project leadership. Both the <br>business clients and the team can detect fairly quickly if <br>the project leaders have "what it takes" to take them to a <br>final product. Without question this feeling has a <br>tremendous impact on morale. </p>
<p>&nbsp;&nbsp; 这是绝对关键的。成功的能力是在努力的早期阶段在客户的思想和项目团队成员中<br>建立起来的。这个观点的本质在于管理能力和专业技术和由项目主管拥有的方向感<br>上。业务客户和团队能够快速清楚的察觉项目主管是否有带领他们向最终目标前进的<br>思想。毫无疑问这个感觉对士气是至关重要的。<br>&nbsp;<br>Humphrey Watts in his book Managing the Software Process, <br>describes a model for measuring the maturity of a software <br>development organization. These ideas were further refined <br>by the Software Engineering Institute (SEI) at Carnegie <br>Mellon University. A brief summary of the maturity levels of <br>the model (in terminology which will relate to some of the <br>central themes of this white paper) are presented below: </p>
<p>&nbsp;&nbsp; Humphrey Watts在他的书《管理软件过程》中描述了一个衡量软件开发组织成熟<br>度的模型。这些观点由Carnegie Mellon大学的软件工程组织作了进一步精炼。有关<br>模型（有些术语与本文的一些要点有关）成熟层的简短概括如下：<br>&nbsp;<br>Initial Level<br>&nbsp;&nbsp; 初始层<br>&nbsp;<br>A team or organization at this level tends to take a <br>chaotic, ad-hoc, "invent as we go" approach toward every new <br>systems building effort. <br>&nbsp;&nbsp; 处于这层的团队和组织试图以一种混乱的，特别的，"如我们所想的"方法对待每一<br>个新的系统建造工程。<br>&nbsp;<br>Repeatable Level<br>&nbsp;&nbsp; 可重复层<br>&nbsp;<br>A team or organization at this level uses planning <br>techniques, gathers requirements in a systematic fashion, <br>utilizes software quality assurance techniques, and follows <br>a patterned approach on each subsequent effort. <br>&nbsp;&nbsp; 处于这层的团队和组织通常使用编制计划技术，收集体系模式的需求，使用软件质<br>量保证技术，并在后来的开发中使用模式化的方法。<br>&nbsp;<br>Defined Level<br>&nbsp;&nbsp; 被定义层<br>&nbsp;<br>A team or organization at this level follows defined <br>methodological steps, uses process improvement techniques to <br>enhance the methodological approach, conducts regular <br>training programs, views the entire systems development <br>process from an integration perspective, and utilizes more <br>disciplined information engineering and structured <br>development techniques. <br>&nbsp;&nbsp; 处于这层的团队和组织使用定义好的方法步骤，使用改进过程的技术来提高方法，<br>管理有序的练习程序，从综合的观点看待整个系统开发过程，使用更加严格的信息工<br>程和结构化开发技术。<br>&nbsp;<br>Managed Level<br>&nbsp;&nbsp; 被管理层<br>&nbsp;<br>A team or organization at this level actually captures and <br>utilizes software development metrics for future estimation <br>and process analysis purposes. In addition, some of concepts <br>of Total Quality Management (TQM) are employed to reinforce <br>the effectiveness of the entire development process. <br>&nbsp;&nbsp; 处于这层的团队和组织通常为将来的评估和过程分析捕获并使用软件开发度量。另<br>外，整体质量管理的一些概念也被使用来增加整个开发过程的效力。<br>&nbsp;<br>Optimized Level<br>&nbsp;&nbsp; 优化层<br>&nbsp;<br>A team or organization at this level utilizes continuous <br>organizational change management techniques to optimize its <br>own operations (as well as the company's), emphasizes defect <br>prevention rather than defect detection, and constantly <br>seeks technological innovation opportunities. <br>&nbsp;&nbsp; 处于这层的团队和组织使用持续的有组织的变化管理技术来优化他们的操作，强调<br>避免错误而不是发现错误，并经常寻求技术革新的机会。<br>&nbsp;<br>Project Team Experience<br>&nbsp;&nbsp; 项目团队的经验<br>&nbsp;<br>Even within organizations with high success rates, one <br>factor which never changes on each new effort is the amount <br>of experience possessed by the chosen project team members. <br>Will the project team include a business expert? If not, <br>will the assigned members be able to effectively comprehend <br>and discuss the business requirements and issues in the <br>client terminology? Having someone on the team (even if only <br>in the initial phases) who understands the business is a <br>great confidence builder! It allows the analysts and <br>designers to ask the dumb or simplistic questions to someone <br>other than the client. This actually makes more effective <br>use of everyone's time and it adds an subsequent level of <br>security. In addition, it puts someone in the position of <br>making sure that "creative thinking" stays within reasonable <br>boundaries. </p>
<p>&nbsp;&nbsp; 即使是拥有高成功率的组织中，每个新努力中从不改变的因素是被选择的团队成员<br>拥有的经历的程度。项目团队应该包括一个业务专家？如果不是，指定的成员能够有<br>效的理解和讨论业务需求和客户术语中的组织？在团队里有没有理解这项业务的人士<br>个很自信的开发者？允许分析员和设计员向任何人询问简单的问题，而不是向客户。<br>这能充分利用每个人的时间，并增加后期工作的安全性。另外，它是每个人在合理的<br>范围里进行创造性的思想。<br>&nbsp;<br>What about technical expertise? Is the project entering <br>uncharted waters without a guide? Having someone on the team <br>who is familiar with the specialized knowledge surrounding a <br>selected technological environment provides the same <br>confidence creating benefits as those listed above. A <br>technical expert can assist others, make suggestions, <br>develop standards, and prevent time consuming mistakes. In <br>addition, he or she can provide leadership by example. By <br>spearheading the work and creating examples for others, a <br>technical expert can transfer knowledge and experience in a <br>timely and effective manner. The prevents the "invent as we <br>go" situation teams often find themselves in when embarking <br>on a new technology. <br>&nbsp;<br>&nbsp;&nbsp; 专门的技术怎样？是不是项目进入了没有向导的水域？有没有团队中的成员熟悉指<br>定技术领域的特定知识提供上面提到的同样的信心？一个技术专家能够帮助别人，做<br>出建议，开发标准，阻止耗时的错误。另外，她或他能通过例子提供领导能力。通过<br>传播工作并为他人创造例子，一个技术专家能够以及时有效的方式传播知识和经验。<br>这能阻止当一个团队在着手于一项新技术时通常发现他们处于按自己所想进行的处<br>境。</p>
<p>Project Control and Coordination<br>&nbsp;&nbsp; 项目的控制和合作<br>&nbsp;<br>Large, complex undertakings which require the participation <br>of many people throughout the development process, demand <br>both high-level and detailed guidelines to assist in the <br>channeling of the individual results into an integrated <br>final product. As each person focuses on his or her's part <br>of the system, a clearly defined set of standards and <br>specifications must exist insure that the final result will <br>"mesh" with the results being produced by others. In many <br>ways, a systems building project can be thought of a series <br>of specifications, each level spiraling from broad <br>requirements into highly detailed procedural instructions. <br>The collection of these efforts into a unified whole <br>presents the ultimate challenge for the group. What are some <br>of the ways to successfully make this happen? </p>
<p>&nbsp;&nbsp; 大型的复杂的事业需要在开发过程中很多人的参与，需要高水平详细的设计细节来<br>辅助独立的成果融入最后完整的产品中。当每个人专心与它所负责的系统的一部分<br>时，一个清楚的已经定义标准和规范的集合必须存在以保证最后的结果能够和其他人<br>的结果相吻合。在很多方式下，系统的建造项目可以看成是一系列规范，每层从广泛<br>的需求螺旋发展成为高度详细的过程指令。这些努力的集合就构成了一个整体，给整<br>个团体展现最后的挑战。那些方法能使这件事情成功的发生？<br>&nbsp;<br>Ultimately, three major factors contribute to the level of <br>success that systems building team will enjoy at each of the <br>required integration points. One of these factors is the <br>creation of "consistency" standards. During each phase, <br>guidelines should be developed for both the content as well <br>as the format of the final work products. A second important <br>factor is cross-team communication. Common requirements, <br>similar issues, shared data, and reusable functionality all <br>should be openly discussed and coordinated. Sub-teams should <br>participate in the development of overall high level shared <br>goals and objectives which encourage cross-team interaction <br>and decision making. A third factor is the insistence on the <br>part of the top team leadership that individual and sub-team <br>successes be innertwined. Consistent deliverable, quality <br>assurance, methodological, and review standards must apply <br>to all team members equally. </p>
<p>&nbsp;&nbsp; 最后，三个关键的因素将对系统建造团队将会享受每个需求的综合点成功级别起作<br>用。这些因素之一是一致性标准的建立。在每个阶段，详细的细节必须为内容和最后<br>的运行产品的形式所制定。第二个重要的因素是跨团队的交流。通常的需求，相似的<br>组织，共享的数据和可复用的功能都应该被公开的讨论和协作。子团队应该参加整个<br>高层的开发，共享鼓舞跨团队交互作用和决策制定的目标。第三个是代表高层领导的<br>坚持性，个人和子团队的成功相交互。交付的一致性，质量的保证，方法和复审标准<br>必须对团队的所有成员一视同仁。<br>&nbsp;<br>Team Goals and Individual Objectives<br>&nbsp;&nbsp; 团队目标和个人目标<br>&nbsp;<br>A project team seems to develop a unique "personality" over <br>time. It becomes a reflection of everyone involved, <br>radiating confidence and certainty if spirits are high, <br>seething with doubts and confusion when direction is <br>lacking. How can project dynamics be so different from one <br>team to the next? Leadership certainly plays a vital role, <br>but individual team member attitudes make the difference. </p>
<p>&nbsp;&nbsp; 一个项目团队看起来时在开发一个独一无二的个性软件。成为每个参与者的反映，<br>如果士气高的话则充满自信和确定性，当缺乏方向时则由于疑虑和混乱而沸腾。怎样<br>才能使项目因团队的不同而不同？领导能力当然起了一个很关键的作用，但团队成员<br>的态度也会造成不同影响。<br>&nbsp;<br>Two fundamental questions illuminate the spirit of the group <br>effort. First, is everyone on the team driving toward a well <br>defined and articulative objective? Second, whose objective <br>is it? An amazing thing can happen on development projects; <br>everyone is busily working away on whatever it is that they <br>individually perceive as his or her's most important tasks. <br>Hopefully, each person's work will mesh with the rest of the <br>group's results. This will probably happen if everyone <br>clearly and precisely understands the ultimate phase <br>objectives. But what if they don't? </p>
<p>&nbsp;&nbsp; 两个基本的问题说明了组织努力的精神。首先，是不是团队的每个人都朝着已经制<br>定的清楚的目标前进？第二，这是谁的目标？在开发项目中可能发生这样令人惊讶的<br>事情，每个人都忙于她或他认为最重要的任务。希望是每个人的工作都能与其他人的<br>工作相吻合。如果每个人都很清楚并精确的指导最终的目标则可能，但如果不是呢？<br>&nbsp;<br>This is where human nature begins to step in and things can <br>begin to get interesting. If the attitudes of the team <br>members tend to be goal driven (which is good) but the team <br>leadership is fuzzy about what the objectives really are <br>(which is bad), individual and sometimes scattered goals <br>begin to pop up. Unique and potentially conflicting agendas <br>take shape. Before you know it everyone is busily working <br>away and the atmosphere appears to be productive. But an <br>time of reconciliation lies ahead. At some point the <br>individual results must be combined, and depending on the <br>fit, the attitude of the team will ultimately be affected. <br>The group's mission or purpose at this point becomes very <br>real, because it is at this moment that the team realizes <br>that there may not have really been a common direction in <br>the first place, and that fact is painfully obvious. </p>
<p>&nbsp;&nbsp; 当人类开始涉足的地方并且能过的兴趣。如果团队成员是目标驱动，而领导者对最<br>终的目标而疑惑，独立的或分散的目标突然出现。独自的潜在的议程出现。在你知道<br>之前每个人都忙于工作，而且是生产性的气氛。但要调和的时间摆在前面。在某个点<br>上独立的结果必须合并，以来与合适性，团队的态度最终会被影响。这时组织的任务<br>或目的变得很真实，因为这时团队才意识到在开始时就没有统一的方向，事实显然是<br>很痛苦的。<br>&nbsp;<br>Why even take this risk? Insuring that goals and objectives <br>are clearly spelled out, and the activities and tasks which <br>will be followed to ultimately reach them are uniformly <br>understood, will only give the team a shared sense of <br>purpose. Everyone needs to have a stake in, and a share of, <br>the responsibility for the outcome of each phase. Doing this <br>can have an incredible impact on people's attitudes. Clearly <br>comprehending the relevance of the work and how it will <br>contribute to the final product, is a powerful motivator for <br>creating an air of cooperation and open channels of <br>communication between team members. Individual goals can be <br>visualized as a part of the larger team objectives. The goal <br>driven attitude of the team will truly be reflected in the <br>quality of the results. </p>
<p>&nbsp;&nbsp; 为什么冒这个险？确保目标很清楚的确定，他们所从事的任务和活动被一律的理<br>解，将会给整个团队一种目的共享的感觉。每个人都需要由对每个阶段成果的责任<br>感，共享感。这样做肯定会影响每个人的态度。清楚的理解工作的关键和怎样影响最<br>终产品，是产生合作环境及创造成员界交流通道的强有力的因素。独立的目标可以被<br>想象成为大型团队目标的一部分。团队的目标去动态都会在产品的质量中有所反映。<br>&nbsp;<br>Systems Building Vision<br>&nbsp;&nbsp; 系统建造的蓝图<br>&nbsp;<br>A "vision" doesn't do anyone any good if it is only in one <br>person's head. Only when it has been absorbed and adopted by <br>the team does its usefulness begin to emerge. A business or <br>system "visionary" plays an important yet sometimes <br>unenviable role in making this happen. His or her <br>willingness to share insight and understanding of a <br>situation, and the necessary steps he or she envisions to <br>arrive at a desired outcome, tend to be dependant on two <br>factors: the level of confidence he or she has in the ideas, <br>and his or her tolerance for scrutiny and criticism. <br>Regardless of these personal risks, a professional system <br>builder must strive to be a system "visionary". With each <br>passing phase of the project, he or she must constantly <br>develop and communicate his or her vision of both the system <br>functionality and the project approach. </p>
<p>&nbsp;&nbsp; 如果蓝图只存在于一个人的脑中则不会给任何人带来好处。只有被团队吸取和采纳<br>才能使它的作用发挥出来。一个业务或系统的&#8220;蓝图&#8221;作用重要但有时仍不能实现。<br>她或他的希望是共享对情况的理解和见识，并采取了步骤以达到理想的结果，依赖于<br>两个因素：她或他的自信程度，忍耐审查和批评的能力。不管这些个人的冒险，一个<br>专业的系统建造者必须为成为一个系统设计者而奋斗。随着每个阶段的完成，她或他<br>必须持续开发和交流她或他对系统功能和项目方法的构想。<br>&nbsp;<br>Putting forward this vision assists in accomplishing two <br>important results. First, it creates a baseline foundation <br>for continuing discussion. In many cases, the original <br>system/approach vision may not survive for long as better <br>ideas are presented and improvement discussions occur. <br>Second, the vision promotes constructive, critical thinking. <br>&nbsp;<br>&nbsp;&nbsp; 提出构想能有处于实现两个重要的结果。首先，它创造了继续讨论的基础。在很多<br>情况下，最初的系统/方法构想不能比好的思想提出和改进的讨论维持的时间长。第<br>二，构想提供建设性的严格的思考。</p>
<p>People tend to provide more input in a "review and improve" <br>mode rather than a "create from scratch" mode. The <br>presentation of a baseline vision stimulates this process. <br>In addition, if the "visionary" can relinquish ownership of <br>the original idea, and subsequently encourage it to become <br>the property of the group, the effectiveness of the process <br>can be even more enhanced. The system builder serves to <br>plant the "starting point" ideas, and the team members and <br>business clients assist with, and take responsibility for, <br>the ultimate direction and composition of the shared vision. <br>&nbsp;<br>&nbsp;&nbsp; 人们更倾向于提供更多的输入给&#8220;复审和提高&#8221;而不是&#8220;从零开始&#8221;的模式。最初<br>的构想的提出促进这个过程。另外，如果&#8220;构想&#8221;能够放弃最初的思想的所有权，而<br>成为组织的财产，这个过程的效果将会更加提高。系统建造者负责产生开始点的思<br>想，团队成员和业务客户辅助并负责共享的构想的方向和合成。</p>
<p>Project Team Confidence<br>&nbsp;&nbsp; 项目团队信心<br>&nbsp;<br>Another important team attitude is confidence. The <br>development of a complex system presents tremendous <br>challenges to a project team. Sometimes it can even feel <br>like an act of faith. An enormous amount of detail is <br>collected, analyzed, organized, and assimilated into a <br>functional "whole". On very large efforts, only a few key <br>individuals may possess the total "big picture", and this <br>may be at varying levels of completeness. This ambiguity can <br>from time to time test the confidence of the project team <br>members. Given these uncertainties, how does a team feel <br>assured and confident of success throughout the process, and <br>have this reflected in the individual team member attitudes? <br>&nbsp;<br>&nbsp;&nbsp; 另一个重要的团队是信心。开发复杂的系统将会给团队带来很多挑战。有时感觉是<br>一种信仰的活动。大量的细节被收集、分析、组织并吸取为整体的功能。在非常大的<br>付出中，仅有一些关键个人支配整个&#8220;图纸&#8221;，并随完成的不同层次不同。这种不确<br>定性时不时的检验团队成员的信心。给出这些不确定的事情，一个团队怎样才能在通<br>向成功的过程中感到有保证和信心，并反映到团队个人的态度呢？</p>
<p>Clearly, the realization on the part of the team, that a <br>system design is formed as a gradually evolving solution, <br>from a process which tends to be iterative in nature, helps <br>everyone to be patient with the slowly disappearing level of <br>ambiguity. The more team members who participate on the <br>project who have been through the complete system building <br>life cycle, the more likely the overall team awareness will <br>be that everything will come together at each major <br>milestone. This is an important confidence builder for the <br>less experienced members of the team. The higher the level <br>of confidence possessed by the team, the more secure the <br>business clients feel, and the more likely the team will <br>actually "see" themselves succeeding, even in the face of <br>the unknown. </p>
<p>&nbsp;&nbsp; 很明显，在团队方面的实现，系统的设计在逐渐演化的过程中形成，从本质上交互<br>的过程，帮助每个人在不确定性逐渐消除的过程中保持忍耐。参加项目并经历整个系<br>统建造生命周期的成员越多，整个团队意识在每个主要里程碑所有事都具备的可能性<br>就越大。这对于一个缺乏经验的团队成员是一个重要的信心缔造者。团队拥有的信心<br>水平越高，，业务客户的安全感越大，团队就更加可能看到他们的胜利，即使是面对<br>未知的事情。</p>
<p>&nbsp;</p>
<img src ="http://www.blogjava.net/pdw2009/aggbug/110202.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/pdw2009/" target="_blank">有猫相伴的日子</a> 2007-04-12 16:17 <a href="http://www.blogjava.net/pdw2009/archive/2007/04/12/110202.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>软件开发:需求分析的20条法则（收藏） </title><link>http://www.blogjava.net/pdw2009/archive/2007/04/12/110189.html</link><dc:creator>有猫相伴的日子</dc:creator><author>有猫相伴的日子</author><pubDate>Thu, 12 Apr 2007 07:47:00 GMT</pubDate><guid>http://www.blogjava.net/pdw2009/archive/2007/04/12/110189.html</guid><wfw:comment>http://www.blogjava.net/pdw2009/comments/110189.html</wfw:comment><comments>http://www.blogjava.net/pdw2009/archive/2007/04/12/110189.html#Feedback</comments><slash:comments>4</slash:comments><wfw:commentRss>http://www.blogjava.net/pdw2009/comments/commentRss/110189.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/pdw2009/services/trackbacks/110189.html</trackback:ping><description><![CDATA[邢学慧/(IT经理世界) <br><br>　　　对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 <br>---　　经理：&#8220;我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。&#8221; <br><br>--　　-分析员：&#8220;我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。&#8221; <br><br>--　　-经理觉得奇怪：&#8220;我不是刚告诉你我的需求了吗？&#8221; <br><br>--　　-分析员：&#8220;实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。&#8221; <br><br>--　　-经理：&#8220;业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？&#8221; <br><br>---　　分析员尽量解释从用户处收集需求的合理性：&#8220;如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。&#8221; <br><br>---　　经理坚持道：&#8220;行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。&#8221; <br><br>---　　风险躲在需求的迷雾之后 <br><br>-　　--以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。 <br><br>--　　-拨开需求分析的迷雾 <br><br>---　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像&#8220;雾里看花&#8221;般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容： <br><br>--　-&#183;业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。 <br><br>---　&#183;用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。 <br><br>---　&#183;功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。 <br><br>--　-&#183;非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。 <br><br>---　&#183;需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。&#8220;需求分析报告&#8221;在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。 <br><br>---　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循&#8220;业务需求&#8221;的规定，然而&#8220;业务需求&#8221;并不能为开发人员提供开发所需的许多细节说明。 <br><br>---　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。 <br><br>---　经理层有时试图代替实际用户说话，但通常他们无法准确说明&#8220;用户需求&#8221;。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。 <br><br>---　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。 <br><br>---　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。 <br><br>---　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。 <br><br>--　-客户的需求观 <br><br>--　-客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。 <br><br>---　1、 分析人员要使用符合客户语言习惯的表达 <br><br>---　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。 <br><br>---　2、分析人员要了解客户的业务及目标 <br><br>---　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s <br><br>---　3、 分析人员必须编写软件需求报告 <br><br>---　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份&#8220;需求分析报告&#8221;，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的&#8220;需求分析报告&#8221;有助于开发人员开发出真正需要的产品。 <br><br>---　4、 要求得到需求工作结果的解释说明 <br><br>---　分析人员可能采用了多种图表作为文字性&#8220;需求分析报告&#8221;的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。 <br><br>---　5、 开发人员要尊重客户的意见 <br><br>---　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家&#8220;兼听则明&#8221;。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。 <br><br>---　6、 开发人员要对需求及产品实施提出建议和解决方案 <br><br>---　通常客户所说的&#8220;需求&#8221;已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。 <br><br>---　7、 描述产品使用特性 <br><br>---　客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要&#8220;界面友好&#8221;或&#8220;健壮&#8221;或&#8220;高效率&#8221;，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的&#8220;友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。 <br><br>---　8、 允许重用已有的软件组件 <br><br>---　需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。 <br><br>---　9、 要求对变更的代价提供真实可靠的评估 <br><br>---　有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。 <br><br>---　10、 获得满足客户功能和质量要求的系统 <br><br>---　每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统&#8220;做什么&#8221;所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。 <br><br>---　11、 给分析人员讲解您的业务 <br><br>---　分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的&#8220;常识&#8221;。 <br><br>---　12、 抽出时间清楚地说明并完善需求 <br><br>---　客户很忙，但无论如何客户有必要抽出时间参与&#8220;头脑高峰会议&#8221;的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。 <br><br>---　13、 准确而详细地说明需求 <br><br>---　编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。 <br><br>---　在需求分析中暂时加上&#8220;待定&#8221;标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上&#8220;待定&#8221;。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进&#8220;软件需求报告&#8221;中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。 <br><br>---　14、 及时作出决定 <br><br>---　分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。 <br><br>---　15、 尊重开发人员的需求可行性及成本评估 <br><br>---　所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。 <br><br>---　16、 划分需求的优先级 <br><br>---　绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。 <br><br>---　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。 <br><br>---　17、 评审需求文档和原型 <br><br>---　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的&#8220;需求分析报告&#8221;不够准确，就有必要尽早告知分析人员并为改进提供建议。 <br><br>---　更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。 <br><br>---　18、 需求变更要立即联系 <br><br>---　不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。 <br><br>---　19、 遵照开发小组处理需求变更的过程 <br><br>---　为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。 <br><br>---　20、 尊重开发人员采用的需求分析过程 <br><br>---　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。 <br><br>---　&#8220;需求确认&#8221;意味着什么 <br><br>---　在&#8220;需求分析报告&#8221;上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把&#8220;签字&#8221;看作是毫无意义的事情。&#8220;他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。&#8221; <br><br>---　这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：&#8220;不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。&#8221; <br><br>---　同样问题也会发生在仅把&#8220;签字确认&#8221;看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着&#8220;需求分析报告&#8221;说：&#8220;您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。&#8221; <br><br>---　这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在&#8220;需求分析报告&#8221;上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。 <br><br>---　对&#8220;需求分析报告&#8221;的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：&#8220;我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。&#8221;对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 <br><br>---　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础<br><br>
<img src ="http://www.blogjava.net/pdw2009/aggbug/110189.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/pdw2009/" target="_blank">有猫相伴的日子</a> 2007-04-12 15:47 <a href="http://www.blogjava.net/pdw2009/archive/2007/04/12/110189.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>SVN简介</title><link>http://www.blogjava.net/pdw2009/archive/2006/12/11/86972.html</link><dc:creator>有猫相伴的日子</dc:creator><author>有猫相伴的日子</author><pubDate>Mon, 11 Dec 2006 10:00:00 GMT</pubDate><guid>http://www.blogjava.net/pdw2009/archive/2006/12/11/86972.html</guid><wfw:comment>http://www.blogjava.net/pdw2009/comments/86972.html</wfw:comment><comments>http://www.blogjava.net/pdw2009/archive/2006/12/11/86972.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/pdw2009/comments/commentRss/86972.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/pdw2009/services/trackbacks/86972.html</trackback:ping><description><![CDATA[Subversion是新一代的版本控制工具,由于其优于CVS的一些特点,得到了越来越多人的关注和使用,本人根据自己使用SVN的经验,写了这篇文章,希望对大家有所帮助,其中有些实践并不是仅仅适用于SVN,对其他版本控制工具也是适用的。<br /><br />1、养成良好的记录日志的习惯.<br />svn ci提交，最好在日志中记下清晰明确的信息,这个非常重要,对以后的维护(包括合并)都有很大帮助。<br /><br />2、格式统一.<br />开发人员提交的文件格式要保持一致,统一为DOS格式或者UNIX格式,同时提交前对源代码采用统一的风格格式化（比如jalopy）,这样对以后的合并、查看修改信息会更加方便。<br /><br />3、如何把分支合并到主干上。.<br />只需要比较分支的初始状态与最终状态，然后将这些分支的修改应用到主干目录的工作拷贝。<br />步骤：<br />(1)、在本地将最新的主干取出<br />svn co <a href="http://svn.example.com/repos/example/trunk" target="_blank"><font color="#154ba0">http://svn.example.com/repos/example/trunk</font></a> example<br />(2)、到当前的example目录下合并分支,4889,4906分别表示分支的最初版本号和最终版本号<br />svn merge -r 4889:4906 <a href="http://svn.example.com/repos/example/branches/branches_test" target="_blank"><font color="#154ba0">http://svn.example.com/repos/example/branches/branches_test</font></a><br /><br /><br />4、典型的svn目录结构<br />project/branches/<br />project/tags/<br />project/trunk/<br /><br />5、项目代码测试发布前别忘打上tag,作为一个基准.代表一次发布版本。<br /><br />6、实用的SVN命令<br />* svn copy 创建分支或者标签<br />svn copy <a href="http://svn.example.com/repos/calc/trunk" target="_blank"><font color="#154ba0">http://svn.example.com/repos/calc/trunk</font></a><a href="http://svn.example.com/repos/calc/tags/release-1.0" target="_blank"><font color="#154ba0">http://svn.example.com/repos/calc/tags/release-1.0</font></a> -m "Tagging the 1.0 release of the 'calc' project."<br /><br />* svn switch 切换工作拷贝到指定的分支或者返回主干<br />svn switch <a href="http://svn.example.com/repos/calc/branches/my-calc-branch" target="_blank"><font color="#154ba0">http://svn.example.com/repos/calc/branches/my-calc-branch</font></a><br /><br />* svn diff 版本比较<br />svn diff rules.txt 比较本地修改<br />svn diff --r 3 rules.txt 比较工作拷贝和版本库<br />svn diff --r 2:3 rules.txt 比较版本库与版本库 <br /><br />* svn revert 删除你的本地修改,恢复到修改前的状态.<br /><br />* 查一个过去的版本,重定向输出到一个文件<br />svn cat -r 2 rules.txt &gt; rules.txt.v2<br /><br />*svn info 查看当前工作拷贝是在主干还是在哪个分支上。<br />subeclipse下载地址<br /><a href="http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240">http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240</a><br /><br />启动服务<br /><font face="宋体">    svnserve -d -r d:\svn<br /><br />其中的 -d 参数表示 svnserve.exe 将会作为一个服务程序运行在后台，而 -r 参数表示将 ``D:\svn`` 目录指定为代码库的根目录。这样，当客户端使用类似 svn://192.168.0.1/foo 这样内容的 URL 来访问服务器时候，其所访问到的真实代码库，其实就是 ``D:\svn\foo``<br /><br />在服务器端的 ``D:\svn`` 目录下，建立一个名为 arm 的代码库，命令如下::<br />创建代码库<br />    D:\svn&gt;svnadmin create arm<br /><br />使用上述命令之后，如果不出问题的话，在 ``D:\svn`` 目录下就会多出一个叫做 ``arm`` 的目录，其下具备 conf、dav、hooks、locks、db 等子目录或文件，此即 **一个名为arm的代码库** 。从此，通过 ``svn://192.168.0.1/arm`` 这样的 URL，我们就可以对这个代码库进行访问了。接下来就要进入本文的正题了，也就是权限配置部分了。</font><img src ="http://www.blogjava.net/pdw2009/aggbug/86972.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/pdw2009/" target="_blank">有猫相伴的日子</a> 2006-12-11 18:00 <a href="http://www.blogjava.net/pdw2009/archive/2006/12/11/86972.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>