Waterfall Model
Sometimes called the "waterfall model"，the lifecycle paradigm demands a systematic, sequential approach to soft-ware development that begins at the system level and progresses through analysis, design, coding, testing, and maintenance. Modeled after the conventional engineering cycle, the life cycle paradigm encompasses the following activities：
1．System Engineering And Analysis
Because software is always part of a larger system, work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. This system view inessential when software must interface with other elements such as hardware, people, and data base．System engineering and analysis encompass re-quarrymen's gathering at the system level with a small amount of top level design and analysis．
2 ．Software Requirements Analysis
The requirements gathering process is intensified and focuses specifically on software. To understand the nature of the program(s) to be built, the software engineer(“analyst”)must understand the information domain for the software, as well as requirked function, performance, and interfacing. Re-quarrymen's for both the system and the software are documented． 软件开发网 www.mscto.com
3 ．Design
Software design is actually a multistep process that focuses on three distinct attributes of the program: data structure, software architecture, and pro-caesural detail. The design process translates re-quarrymen into a representation of the software that can be assessed for quality before coding begins．Like requirements, the design is documented and becomes part of the software configuration.
4. Coding 软件开发网 www.mscto.com
the design must be translated into a machine-readable form. The coding step performs this task. If design is performed in a detailed manner, coding cane accomplished mechanistically.
5 ．Testing
Once code has been generated, program testing begins．The testing process focuses on the logical internals of the software, assuring that all statements have been tests to assure that defined input will pro-duce actual results that agree with required results
6 ．Maintenance
Software will undoubtedly, undergo change after it is delivered to the customer (a possible exception is embedded software)．Change will occur be-cause errors have been encountered, because the software must be adapted to accommodate changes units external environment(e．g. A change required because of a new operating system or peripheral device), or because the customer requires functional or performance enhancements、Software maintenance applies each of the preceding life cycle steps to an existing program rather than a new one. 软件开发网 www.mscto.com
The classic life cycle is the oldest and the most widely used paradigm for software engineering. However, over the past few years，criticism of the paradigm has caused even active supporters to question its applicability in all situations．
Among the problems that are sometimes encountered when the classic life cycle paradigm is applied are
(1)Real projects rarely follow the sequential flow that the model proposes．Its operation always occurs and creates problems in the application on the paradigm．
(2) It is often difficult in the beginning for thecustomer to state all requirements explicitly. The classic life cycle requires this and has difficulty ac-accommodating the natural uncertainty that exists at the beginning of many projects．
(3) The customer must have patience. A working version of the program (s) will not be available until late in the project time span. A major blunder undetected until the working program is reviewed can be disastrous．
Software has become critical to commercially vital technologies that account for 12 million jobs and one trillion dollars of sales in the US alone. Bandit continues to become central to more products，making many new ones possible and reducing cost or increasing functionality in existing ones．In addition, software products contribute indirectly to the delivery of many other important products and services such as banking telecommunications, and transportation.
For these reasons, software engineers face challenging times．As society becomes more dependent on software, engineers must increase customer sates-faction, boost software- development productivity rates, and reduce product-defect rates．Because software directly affects product users, the responsibility for customer satisfaction is increasing. With so many tasks dependent productivity can yield large eco-gnomic gains, while decreases in software-defect rates can prevent large economic losses．Most importantly, where software supports life-critical tasks or life-saving research, decreasing defect rates and increasing productivity rates will save lives．
International expansion is another factor. Na-tins now views, as potential software consumers will themselves become software producers once they comprehend the huge economic role of software pro-diction. These new sources of products will further broaden the choices for consumers and motivate the industry to stress customer satisfactions．
Software measurement is essential in our efforts to meet these challenges．Measurement enables engineers to quantify product reliability and performance, to isolate development process and product attributes that impact reliability and performance, and to demonstrate how process and product changes impact these attributes．Further, measurement lets develop-mint teams：
Set achievable goals, demonstrate their potential to meet these goals；
Track their progress，adjust processes to correct out-of bounds conditions；
Demonstrate the impacts of these adjustment son meeting goals．
翻译：
瀑布模式
生命周期范例有时称之为“瀑布模式”，它要求软件开发按系统的、顺序的方式，从系统级开始向分析、设计、编码、测试和维护发展。软件的生命周期范例包含以下活动：
1.系统工程和分析
由于软件总是大系统的一部分，所以工作是从建立整个系统元素的需求开始，然后再将这些软件需求划分为一些子集。当软件必须与诸如硬件、人和数据库等其它因素接口时，系统观点是不可少的。系统工程和分析包括系统级的需求收集和少量的高层设计和分析。
2.软件需求分析
需求收集过程非常重要，它着重于从软件的角度来收集需求。为了明确要建立的程序的性质，软件工程师（“分析员”）必须了解软件的信息范畴以及所需功能、性能和接口，把系统和软件的需求制成文档以供顾客查阅。
3.设计
软件设计实际上是多步的过程，它着重于程序的三个明显特征：数据结构、软件体系结构和过程细节。在编码前，设计过程把需求翻译成可评价的软件。象需求一样，设计要制成文档并成为软件配置的一部分。
4.编码
必须设计翻译成机器可识别的形式。编码阶段的任务就是做这样的工作，如果设计做得详细，编码就能由机器完成。
5.测试
一旦代码生成，程序测试就开始。测试过程注重于软件内部逻辑以确保所有语句都被测试。 对于外部功能，主要是进行在确保一定输入情况下能产生与要求 相符的结果的测试。
6.维护
毫无疑问，软件在交于用户之后还要进行修改（嵌入式软件可例外）。由于会遇到一些差错，由于必须调节软件使其与外部环境变化相适应（例如：由于 新的操作系统或外部设备产生的变化），或者由于用户对功能和性能要求提高，因而修改是必然的。软件维护是对于己存的而非新程序应用前述的各种生命周期步骤进行。
传统的生命周期范例在软件工程中是最早也是应用得最广泛的。尽管如此，最近几年里，出现了对此范例的批评，即使是对此范例热烈的支持者对它是否适合于所有情况也提出了质疑。应用传统生命周期范例有时会遇到的问题有：
(l)实际工程很少遵循模式中提出的次序流，应用此范例时经常发生重复和产生一些问题。
(2)要求用户在开始时明确提出全部要求往往是很困难的。传统的生命周期要求如此，许多工程开始时有不确定的自然因素。
(3)用户需要耐心。一程序的工作版本要延续到工程的后期才能使用，如果一主要的错误在工作程序复查时没被检测到，这将是灾难性的。
软件对于商业上至关重要的技术来说己变得很关键，而单单美国，这样的技术就已提供了1200万个工作岗位，而形成1万亿美元的销售额。而且，它将继续成为更多产品的核心，使许多新产品有可能诞生，并使现有产品降低成本或增加功能。此外，软件产品也对其它许多诸如银行业、电信业和交通运输业等方面 的重要产品和服务作出了间接的贡献。
由于这些原因，软件工程师面临着挑战的时代。随着社会对 软件依赖性的增大，工程师必须 增加客户的满意度，提高软件开发的生产率，降低产品缺陷率。 由于软件直接影响产品用户，确保客户满意的责任也就日益加重。由于有如此之多的工作依赖于软件，软件开发生产率的小小提高就可以产生巨大的经济效益，ifu软件缺陷率的降低则可防止巨大的址济损失。更为重要的是，如果软件支持的是生死忧关的工作或救生的研究工作，它的缺陷率的降低和生产率的提高就 能拯救生命。
国际上的发展是另一个因素。现在被视为潜在软件消费国的国家，一旦认识到软件生产的巨大经济作用，本身就会成为软件生产国。这些新的软件生产国将进一步扩大客户的选择范围，促进工业界重视客户的满意度。
软件计量在我们迎接这些挑战的工作中是必不可少的。计量能使工程师们对产品的可靠性与性能的开发过程与产品属性隔离开来，并验证开发过程和产品的更改如何影响这些属性。再则，计量能使开发小组：
确定可以实现的目标，验证他们实现这些目标的潜力；
跟踪他们的进展情况，调整开发过程，修正不可使用的条件：
验证这些调整对于实现这些目标的影响。