Each element in the second level of abstraction can be further decomposed,creating yet a third level of abstraction. For example, the check-out process may be further decomposed into the following modules: check-for-overdue-books ,change-book-status, update-patron-info, and update-librarian-work-info.The combined result of decomposing each element from the second level of abstraction forms the third level of abstraction. Figure l.5 shows the structure chart for a functional decomposition of the book-tracking system, where common module are shared among modules in a higher level of abstraction. Notice that this is not a complete functional decomposition because some of the processes are still too abstract. For example, all three modules at the second level of abstraction share the change-book-status process. The details of how the book status is to be changed in each situation have not yet been defined but must be defined in a later decomposition of the inpidual processes. 
 This example illustrates one of the most important concepts in all software development paradigms: abstraction. As a software development team begins their work, their first and most critical task is to study the system to be developed.Their initial understanding of this system will be imprecise and vague, and can only be conceptualized very abstractly. For example, the software development team's knowledge may be limited to knowing the system is to be used by a library to track books. As a result, the team uses a notation to represent the system as a book-tracking system.As the team studies the problem at hand, additional details will emerge, and these details can be incorporated into representations of later system conceptualizations.
The objectives of functional decomposition are to provide an orderly mechanism for understanding the system to be developed through abstraction and to produce a well-structured software system as a result. We can translate the modules at the various levels of abstraction into functions, procedures, or subprograms in the actual system implementation.  Thus the conceptualization and representation of the system are compatible with its actual  source-code structure. The technique of starting with an abstract conceptualization of the system and moving to progressively more detailed levels of abstraction is stepwise refinement. The technique of stepwise refinement continues to be used today, but the structure charts that resulted from early functional decomposition tasks typically did not provide enough information to ensure a well-structured, accurate solution. To begin to add some of that necessary information,  structured analysis and design techniques have been developed.  
软件工程技术历史简介
从历史上看，面向过程的模式是行业选择的一种典型的方式。近来，更多的项目开发已经开始使用一种叫做面向对象的方式。虽然很多人认为采用面向对象的方式与以前技术大相径庭，但我们认为这种技术的采用是对它之前的软件工程技术的一种合乎逻辑的延续。因此，我们认为深刻理解在面向对象技术出现之前的软件工程技术是很重要的。论文网
我们可以把软件开发的成本分为两部分：将运行该软件的硬件成本以及软件开发人员薪金的费用。随着时代的发展，在硬件上的花费逐渐在降低，而开发人员的薪水却在不断的增长。由于相关花费之间的关系，许多软件开发工具被开发出来，使得程序员在开发软件时更加高效。这些开发工具变得越来越复杂，因为人们努力地去提高这些开发工具在面对一些繁琐任务时的自动化程度。由于这些工具变得越来越复杂，用这些工具开发的应用程序也变得更加复杂，而且也越来越多的承担了更多的日常生活中的任务。这些应用程序激增，社会也逐渐变得更加依赖于这些应用。目前的状况是，我们的社会只有依赖于这些复杂的软件才能正常运转。但是，这些复杂应用程序的开发很容易出现故障。为了让社会能正常运行，新的软件的开发必须使用一种最有可能开发出成功的，有用的应用软件的方法。 软件工程技术英文文献和中文翻译(2):http://www.youerw.com/fanyi/lunwen_39805.html