To transform requirements into a working system， designers must satisfy both customers and the system builders on our development team. The customers understand what the system is to do. At the same time， the system builders must understand how the system is to work. For this reason， design is really a two-part， iterative process. First， we produce conceptual design that tells the customer exactly what the system will do. Once the customer approves the conceptual design， we translate the conceptual design into a much more detailed document， the technical design， what allows system builders to understand the actual hardware and software needed to solve the customers’ problem. The process is iterative because， in actuality， the designers move back and forth among activities involving understanding the requirements， proposing possible solutions， testing aspects of a solution for feasibility， presenting possibilities to the customers， and documenting the design for the programmers. Sometimes the design is described in one document， but often there are two. The two design documents describe the same system， but in different ways because of the different audiences for the documents. Thus， the conceptual design concentrates on the system's functions， and the technical design describes the form the system will take.
Object-oriented methodology is an approach to system lifecycle development that takes a top-down view of data objects， their allowable actions， and the underlying communication requirement to define system architecture. The data and action components are encapsulated， that is， they are combined together， to form abstract data types. Encapsulation means that if I know what data I want， I also know the allowable processes against that data. Data are designed as lattice hierarchies of relationships to ensure that top-down， hierarchic， inheritance and sideways relationships are accommodated. Encapsulated objects are constrained only to communicate via messages. At a minimum， messages indicate the receiver and action requested. Messages may be more elaborate， including the sender and data to be acted upon.
Object orientation is the usual approach to developing applications in aerospace and defense organizations， and experiments with its use are occurring in most large companies. Object-oriented design appears to be the best suited method for real-time applications， and is useful for on-line applications.
【Vocabulary】
discipline
n. 纪律，学科 vt. 训练
automate
vt. 使自动化
identification
n. 辨认，证明，鉴定
sufficient
adj. 充分的，足够的
terminology
n. 术语学
prototype
n. 原型
vehicle
n. 交通工具，车辆，媒介
debug
vt. 调试，除错
validation
n. 确认
correspond
vt. 符合，协调，相应，相当
substantial
adj. 坚固的，实质的，充实的
implementation
n. 执行
deteriorate
v. 使恶化
maintenance
n. 维护，保持，抚养
iterative
adj. 重复的，反复的
capsule
n. 胶囊，太空舱
feasibility
n. 可行性，可能性
audience
n. 观众，听众，接见，拜见
architecture
n. 建筑，建筑学
elaborate
vt. 精心制作，详细阐述
aerospace
n. 航空宇宙
methodology
n. 方法学，方法论
【参考译文】
软件工程
软件工程是工具、方法和规则的应用，用于产生和维护一个现实世界问题的自动化解决方案。它要求我们识别出一个问题，一台执行某一软件产品的计算机及其软件产品存在的环境（包含人员、设备、计算机、文档等）。显然没有计算机程序就没有软件产品，更没有软件工程。但这只是一个必要而非充分条件。
一个大规模的软件工程需要跨越相当长的时间来完成。这段时期可以划分为不同的阶段，这些阶段一起构成所谓的“软件生命周期”。
虽然实际的名称可能不同，但是大多数作者都认为软件生存周期分为五个关键阶段。
第一阶段，需求定义，表示在这个阶段内系统希望的需求，也就是精确说明它的功能特性和运行细节。该阶段的输入是陈述（一般是不太确切的陈述）对该软件的要求。通常，一个“需求文档”是该阶段的输出，是经过明确说明的特征或约束条件的集合，这也是最终产品必须满足的。这虽然不是设计，但是必须在设计之前，规定系统应该做什么而不规定它如何去做。一个需求文档的存在，提供一些针对设计的（该生存周期的下一个阶段）并可以使其有效化的东西。有的时候一个快速开发的原型可能是调试需求的一个有用的工具。
对任何阶段，都不允许把错误带到后续阶段是十分重要的。例如，在需求方面，一个错误陈述的功能导致一个有错误的设计和一个并不要求做的事情的实现。如果没有查明，让错误一直发展到测试阶段，则修正这个错误（包括重新设计和重新实现）的代价就可能很大了。
第二阶段，设计，在这个阶段创造性占统治地位，虽然有人表明创造性是内在的而不能够被训练和提高，但是借助于良好的步骤和工具它肯定可以被提高。这个阶段的输入是一份（已经调试而且已经有效化的）需求文档，该阶段的输出则是以某种形式（如伪代码）表示的一个设计。一个设计的有效化是重要的。在需求文档中的每一个需求都必须有一个相应的设计片段来满足它。正式验证，虽然在有限程度上是可能的，但是一般却是极其困难的。更多的非正式验证在整个设计团队，管理人员甚至客户处循环出现。
第三阶段，实现，是对第二阶段中开发设计的实际编码。该阶段的诱惑力是强大的，所以有很多鲁莽的程序员没有经过前两个阶段的充分准备就跳到了这个实现阶段。结果是许多要求没有完全理解，因而设计也是有缺陷的。实现阶段盲目的进行，结果会出现许多问题。
第四阶段，测试，用来证明所实现的程序的正确性。某些测试不可避免地作为前两个阶段的一部分已经被执行。任何有经验的程序员，在任何正式测试阶段之前，每产生一条线路时都会从内心去检测它，也会从内心模拟任何模块的执行。测试决不是容易的。Edsger Dijkstra 写到，虽然测试能够有效的显示出错误的存在，但从不显示它们的不存在。一次“成功”的测试运行仅仅意味着在所测试的特定环境中没有错误被发现；关于其他环境它却没有说明什么。在理论上，测试是显示出一个程序是否正确的唯一途径，好像所有可能的情况都被尝试了（如众所周知的穷举测试），甚至对最简单的程序在技术上都是一种不可能的情况。例如，假设我们已经写了一个程序来计算一次考试的平均分。一次穷举测试将需要分数和班级大小的所有可能的组合；它可能要花费很多年来完成该测试。
第五阶段，程序维护阶段。不幸的是，学生程序员们很少能够涉及本阶段。但是它在现实世界中的重要性也不能被过分地强调。因为维护一个被广泛应用的程序的成本可以达到或着超过开发它的成本。与硬件维护不同，软件维护不涉及已损坏的部件的修复，而涉及设计者缺陷的修复，它可能包括附加功能的供应来满足新的要求。程序员生产各新程序的能力明显受到他们维护旧程序耗费的时间长短的影响。维护的不可避免性必须被承认，且必须采取各个步骤以减少它的时间耗费。
软件设计可以用相同方式考察。我们使用需求规范来定义该问题。那么，如果它能够满足该规范中的所有要求的话，我们就声明它是一个问题的解决方案。在许多情况下，可能的解决方案的数目是没有限制的。一个顾客可以从若干可能性中选择一种以实现一种解决方案。
为了将各个需求转变为一个工作系统，设计师们必须使顾客和我们的开发团队中的诸系统建造师两者都满意。顾客要知道该系统将要做什么，同时建造师也必须理解该系统如何工作。由于这个原因，设计实际上是一两部分的迭代过程。第一，我们生产概念设计，它确切地告诉顾客该系统将要做什么。一旦顾客批准了该设计理念，我们就要将概念设计翻译成一个更详细的文档，该技术设计允许诸系统建造师理解为解决该顾客的问题所需要的实际硬件和软件。这个过程是反复的，因为在现实中设计师往返于理解各项要求、提出可能的解决方案、测试解决方案的可行性、向顾客提供可能的各个解决方案以及为程序员们编写设计文档。有时该设计被描述于一个文档，但往往有两个文档。这两个设计文档描述同一个系统，但是以不同的方式描述，因为诸文档针对不同的读者。这样，概念设计集中于系统的诸功能，而技术设计则描述该系统将采用的形式。
面向对象的方法学是针对系统生命周期开发的一种方法，该方法对诸数据对象允许的动作和基本的通信需求采取一个由顶向下的视图来定义一个系统的体系结构。这些数据及动作部件被封装，也就是它们被组合在一起以形成抽象的数据模型。封装意味着如果我们知道需要什么数据，那么我们就还知道针对该数据的各个许可的进程。各个数据被设计成格状层次关系，以确保自顶向下关系、层次关系、继承性关系、横向关系等被接受。封装的各个对象被约束只是为了通过报文进行通信。最低限度下各个报文指明接收者和所请求的行动。各个报文可以更加复杂，包括发送者和作用于它上面的数据。
面向对象是在宇航和国防机构中开发各种应用程序的常用方法，对它使用的各个试验也正在大多数的大公司中发生。面向对象程序设计对于实时应用是一种最合适的方法，对在线应用也是很有用的。
【Reading Material】
Software Life Cycle