新型信息系统(软件工程系列文章之一) 

The business of building systems has changed. A time once existed when computer literacy, technical know-how, and programming skills were all it took to become a successful information systems professional. In many companies, this is still the case. But slowly, yet steadily, a new breed of systems professional is beginning to emerge. Technical skills are no longer enough. Business knowledge, communication ability, and a client centered perspective are becoming more and more important. With computer systems playing an ever increasing role in the management and the competitiveness of companies of all sizes, the information systems professional no longer just serves the company, in many case he or she has a major influence on the way business is conducted. 

系统建造这一工作（业务）已经变了！曾经一度时间，计算机素养、技术细节、 编程技巧是成为一个成功信息系统专业人士的全部。（事实上，）在很多公司里，目前 仍然是这样。但是，慢慢地，新一代的信息系统专业人员正在稳步开始出现。仅有技术 上的技巧已经不够，业务知识、沟通能力、以客户为中心的观点变得越来越重要。随着 计算机系统在各种（或所有）大大小小的公司中的管理和竞争能力方面起的作用越来越 重要，信息系统专业人员不再仅仅是为公司服务，在很多情况下他或她对业务运作的方 式有着关键的影响。


What does this mean for today's systems professional? It means the burden of keeping up is even more challenging than ever! Systems professionals must increasingly view themselves as business problem solvers and business enablers, not just technicians. Computing power has become a part of corporate strategy, and the system builders are charged with creating the business information systems "vision" and making it a reality. Add to this the vast array of technical platforms, programming languages, databases, and system building methodologies which are available in today's marketplace, and the job becomes somewhat overwhelming! So how should the computing professional approach these challenges? 


那么对于今天的系统专业人员来说，这意味着什么呢？ 意味着（系统）维护的 担子比以前更具有挑战性！系统专业人员必须进一步把自己当作业务问题的解决者和 业务使能者，而不仅仅是技术人员。现在，计算能力已成为公司策略的一部分，而系 统开发人员则负责创造业务信息系统的“愿景”，并将它变成现实。加上目前大量在 市场上可获得的技术平台、编程语言、数据库和系统开发方法，这项工作一定程度上 说势在必行！那么，计算业人员应如何面对这些挑战？


First, today's system builder must adopt a more business centered philosophy, and second, he or she must exercise discipline and flexibility as the company moves through the system building lifecycle. But which lifecycle? Traditional System Building Approaches, Information Engineering, Object Oriented Design, Rapid Application Development, and a host of others all possess inherent strengths and weaknesses. Which one is best? How should these approach decisions be made? 


首先，今天的系统建造人员必须采纳更加以业务为中心的哲学；其次，随公司沿着 系统建造生命周期的推进，他或她必须训练自己的纪律性和灵活性。然而是哪个生命周期？ 传统的系统建造方法，信息工程、面向对象设计、快速应用开发，以及其它方法都具有其固 有的优点和缺点。哪个是最好的？应当如何进行这些方法的决策？


Unfortunately, no easy answers exist to these questions. Depending on circumstances and experience, one approach may be preferable over another. In other situations, a sampling of techniques and methods from one or more of the current approaches may be appropriate. What follows within this web site is a mix. Some of the strengths from the traditional lifecycle are still present, the foundation of structured analysis is present, many of the advantages of information engineering have been incorporated, and the new paradigms of object-oriented analysis, design and programming are included. 

不幸的是，对于这些问题不存在简单的回答。在特定的环境和经验下，一种方法可能要 比其它方法好。然而在其它的环境下，从现有方法中提取的一些技术和方法可能更加合适。 这个网站构造就是一个(这种方法的)混合体。传统生命周期的部分优点依旧存在，结构化分 析的基础依旧存在，而很多信息工程的优点已经被结合，包括面向对象分析、设计、编程等 新方法。


The main criteria for discussion here is one of practicality. What are the approaches which make most sense in today's business climate, and which will yield the greatest productivity results given the ever increasing quality demands of the business clients. The other consideration for inclusion here is that the selected philosophies and approaches are proven and they work. They have been developed from actual IS implementation and support experiences.


这里讨论的主要准则是实用性。在今天的商业气候中最起作用的方法是什么，哪种方法 能面对商业客户不断增长的质量需要而产生最大的收益。这里，另一需要考虑的是被选体系 和方法应当是被证实的，并能工作的。它们是在实际的信息系统实施和支持实践中形成的。 


系统成功的关键The Bottom Line ---软件工程系列文章之二 

By Russ Finney

（来自软件工程论坛 seforum.yeah.net） (翻译yanrj ) 

Success! The system is in the hands of the client and it is processing real business information. Time for a project team celebration! Pats on the back all around for everyone. High minded speeches from team leaders, project sponsors, and various excited client participants. No more late nights, weekends, or early mornings. The effort was long and seemingly endless but it was all worth it. The sense of achievement experienced from the solution of a complex business problem by the installation of a new system is indescribable. A number of years and a large number of people may have been involved. The time has come to celebrate the team's victory! 

成功了！系统已经交到客户手中，并且正在处理真正的商业信息。正是项目团队庆祝的时间。轻轻拍拍每个人的后背，由来自团队领导、项目负责人、兴奋的客户方参与 者的有思想高度的演讲。不再有晚上的熬夜、未休息的周末、早起的清晨。付出的努 力是漫长的且似乎无止境，但是值得的。通过安装一个新的系统而解决一个复杂的业 务问题所获得的感觉是难以形容的。这可能要涉及到很多人数年的工作。现在是庆祝 团队胜利的时刻了！

But is it always this way? Another team is exhausted. The death march is finally over. They will never have to see each other again. Boxes and logon IDs can't be turned in quickly enough. All references to real names are removed from programs. "Don't call me when this thing blows up", is muttered now and then. No team gathering is held, just a slow disbanding as each team member disappears onto other projects or activities. The clients seem disenchanted. An air of uncertainty and impending difficulty surrounds the system and those associated with it... 

但结果都是这样吗？另一个团队精疲力竭。期限任务结束了。他们将不再彼此见 面了。而程序的逻辑单元和登录id还不能立即交付。所有涉及真名的参考都从程序中移走。“当它崩溃时不要找我”不时的被嘀咕着。没有团队的集会，仅仅是慢慢的解 散团队，每个成员消失而出现在其它的项目或活动中。客户看起来不再着迷。不确定 的氛围和迫近的困难环绕这系统和与之有关的人。

Or, the worst fate. A surprise meeting! The team has been progressing, but somewhat without direction. The budget is slipping, the client is unsure what is happening, and questions are raised about competence. No one team member can be identified who has a "vision" of the system or the system building process. The inevitable happens, the project is cancelled. The money spent to date was absolutely, totally wasted! 

或者，最坏的。令人惊讶的结果。团队在不断进步，但从某种程度说是没有方 向。目标是不可靠的，客户不能确定将要发生什么，有关能力的问题被提出。团对中 没有一个人能够确定系统的版本或系统的建造过程。必然的事情发生了，项目被撤 销。所有花费的钱完全彻底的浪费掉了。 

Why do some teams seem to make to the end successfully, other teams just make it to the end, and others never get the chance? Why are some teams on a continual "high" throughout the project while the members of a team right across the hall seem to drag into work every morning? Why is it that some clients describe a team with words like: * they understand my business * they are right on target * we are all a part of the same team * we were glad to be a part of this process? 

为什么有的团队成功的完成任务，而有的仅仅是完成，而另一些从没有机会。为 什么有的团队在整个项目中持续高度的状态而有的团队的成员好像是每天早晨要被拖 来工作？为什么有些客户这样形容一个团队： * 他们理解我的业务 * 他们在向着正确的目标前进 * 我们都是一个团队的部分 * 我们很高兴成为这个过程的一部分

Yet another team may be described with: * we not sure what they are doing * they don't understand how our business really works * we are very worried about how this mess is really going to turn out. Does some secret formula exist to insure success, or is it just a matter of luck? 

而另一些团队被形容成： * 我们不能确定他们在做什么 * 他们不理解我们的业务是怎样真正工作的 * 我们很担心这样一个混乱的结果是什么 是不是存在确保成功的秘诀，或仅仅是幸运？ 

Recent observations which have been made by non-technical business people are striking in their implications. One comes from Robert Townsend, the author of Further up the Organization, in which he states that "most of the computer technicians that you're likely to meet or hire are complicators, not simplifiers. They're trying to make it look tough, not easy. They're building a mystic, a priesthood, their own mumbo-jumbo ritual to keep you from knowing what they - and you - are doing". This is disturbing commentary. It gives a clear voice to the concerns that many clients express when the computer professional's back is turned: * Will I get the results I need? * Will my business problem be comprehended? * Will I understand both the solution as well as the process used to arrive at the solution? * How will I be included in the process? * How much control will I have? * Will I really have anything at the end to show for the risk I am taking? 

最近由非技术业务人员作的调查结果是显著的。一个来自Robert Townsend,Further up the orgization的作者，写到“大多数你可能遇到或雇用的 计算机专业人士是复杂化人士，而不是简单化的人。他们尽力使问题看起来困难，而 不是容易。他们正在建造一个神秘的、宗教色彩的，自己拥有的繁琐的过程，使你不 知道他们、还有你自己在做什么”。这是一个很烦恼的解释。这恰恰表明了当计算机 专业人士转过身去时客户所关心的： *我能得到我需要的结果吗？ *我的业务问题能被理解吗？ *我能理解解决方案和达到解决方案的过程吗？ *我将怎样被包括在这个过程中？ *我将能控制多少？ *在最后我能真正得到为我所付出的冒险的收益吗？

An even more disturbing observation comes from one of the acknowledged "thought leaders" in the systems field - Ed Yourdon. In his book, Managing the Structured Techniques, he writes: Managing the Structured Techniques "Something happened to the personality and mentality of the data processing profession as a whole as we moved to the ultra-sophisticated on-line, real-time, fourth-generation and fifth-generation machines of the 1980's and 1990's. The profession began to attract people who, regardless of their race, creed, color, or university degrees, are clerks. They think like clerks, talk like clerks, and they approach computer programming and systems analysis with all the enthusiasm of a sleepy civil service clerk who knows that he's just one year away from retirement.Having met some twenty-five thousand analysts, designers, and programmers throughout the world, I found a surprising number of them have never read any computer articles or even opened a copy of Datamation or Computerworld; have never heard of ACM, DPMA, IEEE, ASM, or any other professional organizations; can't spell Dijkstra's name and probably have never heard of him; aren't aware of the structured techniques and wouldn't be interested if somebody showed them." 

一个更令人烦心的观察来自于一个有名的系统领域的领导人，Ed Yourdon。在他 的书中，《管理结构化技术》，他写到：管理结构化技术 “当我们转向极其复杂的在线，实时，八十年代和九十年代的第四代和第五代机 器时，数据处理专业的素质和智力作为一个整体。这种技术开始吸引那些无视他们的 种族、信条、肤色或文化程度的人。他们象文职人员一样思考、交谈，他们与所有积 极的，但昏昏欲睡的知道自己还有一年就退休的文职服务人员一起处理计算机编程和 系统分析。已经遇到过整个世界的25000个分析员、设计员及程序，我很吃惊的发现 他们中的很多从来没有读过任何计算机的文章甚至是公开的Datamation或 computerworld的拷贝；没有听说过ACM,DPMA,IEEE,ASM,或者是其它任何专业组织； 不能拼出Dijkstra的名字，可能从来没有听说过他；不清楚结构化技术，即使是有人 告诉他们也不感兴趣。”

What makes this even more distressing, is that fact that business executives are now turning to the IS professionals on an ever increasing rate in order to provide them with systems which give the business a strategic as well as a competitive advantage. The major problem here is that computer programming clerks who are enamored with the technology and who could care less about the business itself, will not make this happen. A new breed of computer professional is required who has a balance of people skills, technical skills, and business skills. 

更悲伤的是，为了给他们提供业务的策略和竞争性的特点，行政人员现在正在以 前所未有的比例不断转向信息系统的专业人士的事实。这里的主要问题是那些着迷于 技术而不管新业务本身的计算机编程人员将不会让这个事实发生。新一代的具有人员 素质、技术技巧、业务技巧平衡的计算机人士需要出现。

Some Required Thinking Shifts: * Stop automating existing ways of doing business without assisting in improving the business processes first. * Stop thinking in terms of departmental processing. * Start thinking in terms of cross-organizational systems and business clients. * Start adjusting to the fact that business processes are changing at an ever increasing rate, and the development team must be prepared to keep up - even as a system is being designed and constructed. * Start embracing new forms of technology which show significant cost savings potential. * Start recognizing that if the business client's demands can't be met by you, countless other service providers exist who will be willing to meet those needs. 

需要考虑的问题： *首先停止不需要辅助提高业务过程的现有的自动化方法。 *停止在部门处理方面的思考。 *开始跨组织及商业客户方面的思考。 *开始向业务过程以高速变化的事实调整，同时开发团队必须准备跟上-即使是系 统已经设计和构建。 *开始采用具有低耗费的新型技术。 *开始认识到如果你不能达到业务客户的要求，存在无数的其它服务提供者希望满 足这些要求。

In today's information based society, the system building professional is faced with even greater challenges than ever before. Exploding technological innovation, relentless complexity increases, faster paced business changes, and increasingly sophisticated business clients are placing greater demands on the talents on the business system professional. In addition, a true spirit of trust and teamwork must exist and perpetuate between the business clients and the business systems professionals. This is the first real quest. The next is even more critical. In the end, a business system must be delivered. A system provides no benefit to anyone unless it is in an accepted technical environment and actually being utilized by the business. That is the creed of this site. All of the analysis and design, or the blood, sweat, and tears, won't amount to anything if a working system does not exist in the end as a result of the effort. 

在现在以信息为基础的社会，系统建造人士面临着比以前更大的挑战。技术革新 不断涌现，复杂性不断增加，快节奏的业务变化，不断老练的业务客户对业务系统人 士的才干提出了更高的需求。另外，在业务客户和业务系统人士之间的真正的信任何 团队精神必须存在并且长久。这是第一个要求。下一个更加苛刻。最后，一个业务系 统必须发布。直到系统被技术环境接收并被使用，它才真正的发挥作用。 这就是我们的信条。如果是在所有努力做出后，而而结果是不存在一个运行的系 统，则所有的分析和设计，或者是血、汗水、眼泪都是无用的。 

成功的项目团队Winning Project Teams 


---软件工程系列文章之三

By Russ Finney

（来自软件工程论坛 seforum.yeah.net） (翻译yanrj )

What makes a winning techical project team? A quick look at some of the factors which seem to be consistently present on 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. 



是什么造就了一个成功的专业项目团队？浏览一下成功的项目团队所固有的特点是 很好的。对每个因素的重视程度对于项目的成功和评价业务客户的信任度将有很大的 影响。 
System Building Competence 
系统建造能力 
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. 



这是绝对关键的。成功的能力是在努力的早期阶段在客户的思想和项目团队成员中 建立起来的。这个观点的本质在于管理能力和专业技术和由项目主管拥有的方向感 上。业务客户和团队能够快速清楚的察觉项目主管是否有带领他们向最终目标前进的 思想。毫无疑问这个感觉对士气是至关重要的。 
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在他的书《管理软件过程》中描述了一个衡量软件开发组织成熟 度的模型。这些观点由Carnegie Mellon大学的软件工程组织作了进一步精炼。有关 模型（有些术语与本文的一些要点有关）成熟层的简短概括如下： Initial Level 初始层 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. 
处于这层的团队和组织试图以一种混乱的，特别的，"如我们所想的"方法对待每一 个新的系统建造工程。 
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. 
处于这层的团队和组织通常使用编制计划技术，收集体系模式的需求，使用软件质 量保证技术，并在后来的开发中使用模式化的方法。
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. 
处于这层的团队和组织使用定义好的方法步骤，使用改进过程的技术来提高方法， 管理有序的练习程序，从综合的观点看待整个系统开发过程，使用更加严格的信息工 程和结构化开发技术。
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. 
处于这层的团队和组织通常为将来的评估和过程分析捕获并使用软件开发度量。另 外，整体质量管理的一些概念也被使用来增加整个开发过程的效力。
Optimized Level 优化层 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. 
处于这层的团队和组织使用持续的有组织的变化管理技术来优化他们的操作，强调 避免错误而不是发现错误，并经常寻求技术革新的机会。
Project Team Experience 项目团队的经验 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. 



即使是拥有高成功率的组织中，每个新努力中从不改变的因素是被选择的团队成员 拥有的经历的程度。项目团队应该包括一个业务专家？如果不是，指定的成员能够有 效的理解和讨论业务需求和客户术语中的组织？在团队里有没有理解这项业务的人士 个很自信的开发者？允许分析员和设计员向任何人询问简单的问题，而不是向客户。 这能充分利用每个人的时间，并增加后期工作的安全性。另外，它是每个人在合理的 范围里进行创造性的思想。 
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.
专门的技术怎样？是不是项目进入了没有向导的水域？有没有团队中的成员熟悉指 定技术领域的特定知识提供上面提到的同样的信心？一个技术专家能够帮助别人，做 出建议，开发标准，阻止耗时的错误。另外，她或他能通过例子提供领导能力。通过 传播工作并为他人创造例子，一个技术专家能够以及时有效的方式传播知识和经验。 这能阻止当一个团队在着手于一项新技术时通常发现他们处于按自己所想进行的处 境。



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? 



大型的复杂的事业需要在开发过程中很多人的参与，需要高水平详细的设计细节来 辅助独立的成果融入最后完整的产品中。当每个人专心与它所负责的系统的一部分 时，一个清楚的已经定义标准和规范的集合必须存在以保证最后的结果能够和其他人 的结果相吻合。在很多方式下，系统的建造项目可以看成是一系列规范，每层从广泛 的需求螺旋发展成为高度详细的过程指令。这些努力的集合就构成了一个整体，给整 个团体展现最后的挑战。那些方法能使这件事情成功的发生？
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. 



最后，三个关键的因素将对系统建造团队将会享受每个需求的综合点成功级别起作 用。这些因素之一是一致性标准的建立。在每个阶段，详细的细节必须为内容和最后 的运行产品的形式所制定。第二个重要的因素是跨团队的交流。通常的需求，相似的 组织，共享的数据和可复用的功能都应该被公开的讨论和协作。子团队应该参加整个 高层的开发，共享鼓舞跨团队交互作用和决策制定的目标。第三个是代表高层领导的 坚持性，个人和子团队的成功相交互。交付的一致性，质量的保证，方法和复审标准 必须对团队的所有成员一视同仁。 
Team Goals and Individual Objectives 团队目标和个人目标 
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. 



一个项目团队看起来时在开发一个独一无二的个性软件。成为每个参与者的反映， 如果士气高的话则充满自信和确定性，当缺乏方向时则由于疑虑和混乱而沸腾。怎样 才能使项目因团队的不同而不同？领导能力当然起了一个很关键的作用，但团队成员 的态度也会造成不同影响。 
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? 



两个基本的问题说明了组织努力的精神。首先，是不是团队的每个人都朝着已经制 定的清楚的目标前进？第二，这是谁的目标？在开发项目中可能发生这样令人惊讶的 事情，每个人都忙于她或他认为最重要的任务。希望是每个人的工作都能与其他人的 工作相吻合。如果每个人都很清楚并精确的指导最终的目标则可能，但如果不是呢？
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. 



当人类开始涉足的地方并且能过的兴趣。如果团队成员是目标驱动，而领导者对最 终的目标而疑惑，独立的或分散的目标突然出现。独自的潜在的议程出现。在你知道 之前每个人都忙于工作，而且是生产性的气氛。但要调和的时间摆在前面。在某个点 上独立的结果必须合并，以来与合适性，团队的态度最终会被影响。这时组织的任务 或目的变得很真实，因为这时团队才意识到在开始时就没有统一的方向，事实显然是 很痛苦的。 
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. 



为什么冒这个险？确保目标很清楚的确定，他们所从事的任务和活动被一律的理 解，将会给整个团队一种目的共享的感觉。每个人都需要由对每个阶段成果的责任 感，共享感。这样做肯定会影响每个人的态度。清楚的理解工作的关键和怎样影响最 终产品，是产生合作环境及创造成员界交流通道的强有力的因素。独立的目标可以被 想象成为大型团队目标的一部分。团队的目标去动态都会在产品的质量中有所反映。
Systems Building Vision 系统建造的蓝图 
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. 



如果蓝图只存在于一个人的脑中则不会给任何人带来好处。只有被团队吸取和采纳 才能使它的作用发挥出来。一个业务或系统的“蓝图”作用重要但有时仍不能实现。 她或他的希望是共享对情况的理解和见识，并采取了步骤以达到理想的结果，依赖于 两个因素：她或他的自信程度，忍耐审查和批评的能力。不管这些个人的冒险，一个 专业的系统建造者必须为成为一个系统设计者而奋斗。随着每个阶段的完成，她或他 必须持续开发和交流她或他对系统功能和项目方法的构想。
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. 
提出构想能有处于实现两个重要的结果。首先，它创造了继续讨论的基础。在很多 情况下，最初的系统/方法构想不能比好的思想提出和改进的讨论维持的时间长。第 二，构想提供建设性的严格的思考。



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. 
人们更倾向于提供更多的输入给“复审和提高”而不是“从零开始”的模式。最初 的构想的提出促进这个过程。另外，如果“构想”能够放弃最初的思想的所有权，而 成为组织的财产，这个过程的效果将会更加提高。系统建造者负责产生开始点的思 想，团队成员和业务客户辅助并负责共享的构想的方向和合成。



Project Team Confidence 项目团队信心 
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? 
另一个重要的团队是信心。开发复杂的系统将会给团队带来很多挑战。有时感觉是 一种信仰的活动。大量的细节被收集、分析、组织并吸取为整体的功能。在非常大的 付出中，仅有一些关键个人支配整个“图纸”，并随完成的不同层次不同。这种不确 定性时不时的检验团队成员的信心。给出这些不确定的事情，一个团队怎样才能在通 向成功的过程中感到有保证和信心，并反映到团队个人的态度呢？



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. 



很明显，在团队方面的实现，系统的设计在逐渐演化的过程中形成，从本质上交互 的过程，帮助每个人在不确定性逐渐消除的过程中保持忍耐。参加项目并经历整个系 统建造生命周期的成员越多，整个团队意识在每个主要里程碑所有事都具备的可能性 就越大。这对于一个缺乏经验的团队成员是一个重要的信心缔造者。团队拥有的信心 水平越高，，业务客户的安全感越大，团队就更加可能看到他们的胜利，即使是面对 未知的事情。


交付驱动方法的情况(软工系列文章之四) 

A Case for a "Deliverables Driven" Approach By Russ Finney 

（来自软件工程论坛 seforum.yeah.net） (翻译yanrj ) 

很多系统建造者认为交付证实的项目完全是一种费时的活动。他们给出持这种看法 的原因：

*为什么建造出来的东西最终会改变并变得过时？

*编制正规文档将占用真正任务所用的时间：为系统编制代码。

*我喜欢在这个过程的每个阶段公开放弃我的选择，编制文档首先将使我作错事。

*如果它不被写下来，我能不对它负责（这里事情到处发生-你不得不掩盖每条可能 发生的事情） 采取基于可交付方法的原因：

*它促使决策制定和问题解决。

*它产生确实的期限。

*它鼓励信息的完整性。

*它提供向开发者反馈的机制。

*及时记录项目的状态。

*给团队的成员以成就感。

Tom Demarco在他的书《控制软件项目》中，讨论了基于可交付方法对于一个管理 者的项目计划和控制策略应该产生的影响。作为讨论的一部分，他引用了项目模型的 主要规则：

*项目的活动由它的可交付性制定。

*每个可交付有一项活动。

*这项活动的工作是制造这个可交付系统的工作。

*当可交付系统交付并被接收后活动完成。 面向可交付的项目模型可能产出一些极大的活动，至少是一般项目控制系统的任意 的标准。但是进一步的将这些大的活动分解成生产不可辨识产品的构件使将付出投入 到详细设计的构想。 Fred Brooks在他的名著"The Mythical Man-Month"(davew注：Frederick P.Brooks，IBM OS/360之父，他的这本书问世近近三十年，至今畅销不已，每次再版 只是附增加Brooks新论文或新观点而已，如大家常常提的No silver bullet，原文 近乎不变。此书兄弟早期只是读了《Datamation》节选的7页，后来弄到原书，苦读n 遍，收获不少，建议大家多看看），对采用基于可交付方法的价值给出了更好的洞察 结果： “为什么要有正式的文档？ 首先，将决策写下来是关键的。只有写出后差距才能出现，矛盾才能突出。写的 过程是需求成百上千的小决策的过程，这些的存在将清楚的、准确的政策从模糊的政 策中区分出来。 其次，文档将会与其它人交流决策。管理者将会不断感到惊奇的是他采取的一般 知识的政策团队有些成员竟全然不知。既然他的基本工作是使每个人在一个方向上前 进，他的主要工作就是交流，而不是决策制定，他的文档能很好的减轻这个负担。 最后，管理者的文档给他提供了一个数据库和检验表。通过定期回顾他能知道自 己所处的位置，并看到为需要要对重点改变什么或方向作什么变动。”

A Case for a "Deliverables Driven" Approach By Russ Finney Many system builders consider formal project deliverables to be a complete waste of time. They give the following reasons for holding this opinion: * Why produce something which will just eventually change and become out-of-date anyway? * Producing formal documents takes time away from the really important task: programming the system. * I like to leave my options open through each phase of the process, and producing a document may commit me to something which was wrong in the first place. * If it is not written down, I can't be held accountable for it (and the way things go around here - you have to cover yourself every way possible!). Reasons for taking a deliverables based approach: * It forces decision making and issue resolution. * It creates tangible deadlines. * It encourages information completeness. * It provides a mechanism for feedback to the developers. * It records the state of the project at a moment in time. * It gives the team members a sense of accomplishment. Tom Demarco in his book, Controlling Software Projects, discusses the impact that a deliverables based approach should have on a manager's project planning and control philosophy. As a part of this discussion he refers to the Cardinal Rule of Project Modeling: * A project activity is defined by its deliverable. * There is one activity per deliverable. * The only work charged against that activity is work spent producing that deliverable. * The activity is complete when the deliverable is delivered and accepted. Deliverable-oriented project modeling may yield some overly large activities, at least by the arbitrary standards of common project control systems. But further dividing those activities into components that produce no discernible product is to invest precious effort into an illusion of detailed planning. Fred Brooks in his classic book, The Mythical Man-Month(davew注：Frederick P. Brooks，IBM OS/360之父，他的这本书问世近近三十年，至今畅销不已，每次再版只是附增 加Brooks新论文或新观点而已，如大家常常提的No silver bullet，原文近乎不变。此书兄 弟早期只是读了《Datamation》节选的7页，后来弄到原书，苦读n遍，收获不少，建议大家多 看看),gives even greater insight into the value of taking a deliverables based approach: "Why Have Formal Documents? First, writing the decisions down is essential. Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones. Second, the documents will communicate the decisions to others. The manager will be continually amazed that policies he took for common knowledge are totally unknown by some member of his team. Since his fundamental job is to keep everybody going in the same direction, his chief daily task will be communication, not decision-making, and his documents will immensely lighten this load. Finally, a manager's documents give him a data base and checklist. By reviewing them periodically he sees where he is, and he sees what changes of emphasis or shifts in direction are needed." 



那么到底什么是一个系统呢？（软工系列文章之五） 

What is a System Anyway?
By Russ Finney

翻译：方雨


一个系统是一套为完成一项业务而设计的的手动或者自动化过程。一些过程可 能支持每月的信息收集，其他的可能用于计算，总结，以及报告新东西，还有 一些可能集中于从已知的一系列取舍方法中选取，每个过程都蕴涵一系列必要 的决定。 一个系统可以是全手动的过程，完全自动化的过程，或者两者兼有的。 但是，所有的系统在任一时刻，看起来都是来自于一个或几个一下的类型传统机构型 在很多公司内部开发的系统具有很长的运作历史，稳定的产品或者服务，更倾向于基于缓慢升级的业务过程。在这些公司内，手动和自动混和的实际系统可能存在，随着时间推移，它会变成制度化。如果这是一个大的，机构臃肿的公司，大部分业务客户端会逐渐集中于一些小的个人任务，只有一些少数的老雇员会确实具有整个的大轮廓的印像。


经常调整型 
很多公司的商务活动由政府实体进行调控，他们可能更多的会有一些对多变的规则，规章适应并及时反应的系统，过程，和个人。依赖于调整的节奏，以及提前获得的通知的数量，系统可能顺利的升级至新的制度环境，或者他们可能降级至多分块的，临时的不确定的解决方案。

讲究原则型
一些系统只是基于简单的，已接受的业务原则。一个已经建立的，被很好界定的方法执行已存在的业务，所有的公司都遵循这个模式。审计（G/L,A/P,A/R,等等），薪酬制度，财务报表系统都适于这个范畴。既然不同公司，工厂之间的运行的系统的基本方法只有很小的区别，大量的非自身独有的（off the self 的意思，用英文来解释就是available without self,or on the other envirement－－方雨)自动化替代方案可以适应于从最大的，到最小的企事业实体。除了有彻底的业务原则改变发生，这些系统是所有之中最稳定的，最少动态改变的。往往一个公司从他们当前的系统中“成长”起来，这种情况会引发改变的发生。

工业制造型
每个工业企业具有独有的特点，这些特点确定了组织进行业务活动的方法和途径。这些工业化实践活动在公司内升级的系统中得到具体化。这些系统也更可能被最大程度的监护，因为他们被认为是代表一个全新的，高级的系统。任何类型的显著的组织化，过程化或者系统化的升级提供了更高的质量，更低的成本，或者更好的客户服务。能使公司具有重要的竞争的武器。对这种类型的系统的改变不存在细微的问题的。既然他们代表着企业的生命周期。


完全创新型


最后一类系统是这些从革新中诞生的。他们在一个新的组织形成时或者新的服务提供
时建立。当这些系统开发并升级时，必须首先意识到整个的短周期的冒险，长周期的
受益是整个组织首先要考虑的问题。既然业务流程的创建，以及随之的系统架构的创建趋向于“仓促”而就，公司更应该起用尽可能多的专家和有经验的人来参与整个过程。这保证为现在的业务和以后的增长建立一个坚实的基础。理解历史，特点，和一个特殊的新的，或者已经存在的系统是业务分析的重要的前提。

系统实施和支持的要求在以上的每种情况下都有不同。业务分析和系统设计必须敏锐的把握围绕着系统实施或者改变的业务意识。


What is a System Anyway?
By Russ Finney

A system is a set of manual and automated procedures devised for conducting business. Some procedures may support monthly information gathering, others may consist of calculations, summarizations, and report creation, and still others may center on picking from a series of known alternatives, each with a respective set of required decisions. A system can be a totally manual process, a completely automated process, or a combination somewhere in between. But all systems at one time or another seem to be rooted in one or more of the following sources: 

Tradition

Systems which are developed within companies with long operating histories and stable product or service lines, tend to be based on slowly evolving business procedures. Within these companies, a mix of manual and automated practices may exist which, over time, become "institutionalized". If the company is large and bureaucratic, the masses of business clients become focused on small individualized tasks, and only a handful of long term employees may really have any idea of the "big picture" of what is really occurring. 

Regulations

Companies which have their business practices regulated by governmental entities, tend to have systems, procedures, and individuals who are adaptive and reactive to the various changing rules and regulations. Depending on the regulatory pace and the amount of advance notification given the company, systems may either smoothly evolve to the new regulatory environment, or they may degrade into "piecemeal" temporary solutions which seem to live on indefinitely.


Principles

Some systems are simply based on accepted business principles. An established and well defined way of conducting business exists, and all companies follow this model. Accounting (G/L, A/P, A/R, etc.), payroll, and financial reporting systems all fit into this category. Since only minor differences exist in the fundamental way in which these systems operate from company to company, and from industry to industry, numerous "off the self" automation alternatives exist 
which suit the largest to the smallest business enterprise. Other than when sweeping business principle changes occur, these systems are by far the most stable and the least dynamic in the organization. Usually a company "grows" out their current systems, and this is the situation which triggers change. 

Industry Practices

Every industry has unique characteristics which define the organization's approach to conducting business. These industry practices become embodied in the systems which evolve within the company. These systems also tend to be the most closely guarded since they are perceived to represent a competitive advantage. Any type of significant organizational, procedural, or system advance which provides higher quality, lower costs, or better customer service can give the company an important competitive "edge". Changes to these types of systems are no trivial matter since they represent the "lifeblood" of the enterprise. 

Innovation

The last group of systems are those born from innovation. They are created when a new organization is formed or a new product or service is offered. As these systems develop and evolve, an awareness of the overall short term risks and the long term benefits should be the prime concern of the organization. Since the creation of the procedures and the associated system infrastructure tends to be from "scratch", a company is well advised to harness as much expertise and experience as possible during the process. This insures that a solid foundation 
is created for both current business requirements as well support for future growth needs.

Understanding both the history, character, and source of a particular new or existing system is a vital requirement of the business analyst. System implementation and support options vary in each of the above situations. The business analyst and system designer must be keenly aware of the business sensitivities surrounding system implementation or change effort. Understanding these "roots" of the particular system is the first step.