A Brief History of Software Engineering Techniques Historically,the process-oriented paradigm was the paradigm of choice in industry.Recently,more project have been developed in an object-oriented manner.39495
Although many regard the adoption of the object-oriented paradigm as a radical departure from previous techniques, we view this adoption as a logical continuation of the software engineering techniques that precede it. Thus, we feel that understanding software engineering techniques that came before the advent of the object-oriented paradigm is important.
We can pide the costs of software development into two parts: the costs of the hardware on which the software will run and the costs of the software developer salaries. As the development costs devoted to hardware decreased,  the costs devoted to salaries increased. As the relationship between these costs inverted, tools were developed to make the human effort in software development more efficient. These tools became increasingly complex as efforts were made to automate some of the tedious tasks in software development. As the tools became more complex, the applications created by these tools became more sophisticated and took on more and more of the tasks of everyday life. As these applications proliferated, society became more dependent on these applications. The current state of affairs is that society depends on complex software applications to function properly. The development of these complex applications, however, is prone to failure, for reasons discussed earlier in this chapter. For society to function properly, the development of new software applications must proceed in a manner that is most likely to result in successful, useful software.
With the advent of structured programming in the late 1960s, the goto statement was officially banished from software. The motivation for this banishment was to improve source-code structure and to improve the robustness and reliability of the resulting system. The use of the goto statement leads to poorly structured programs. When goto statements are used in a program, the flow of control, or the order in which instructions are executed, can be difficult to understand and,therefore, difficult to control. In structured programming, the goto statement is replaced with function calls, and therefore program structure is simplified. When a function is invoked, the flow of control is not strictly linear, but control will(probably) eventually return from the function to the line of code following the function call.
As the systems to be implemented grew more complex, it became apparent that structured programming alone was not sufficient to ensure the delivery of quality software. Even if structured programming techniques are used, the resulting software can be difficult to understand and use. This realization lead to the development of the technique of functional decomposition.
Functional decomposition is the process of decomposing the system to be implemented into a series of increasingly detailed conceptualizations. These conceptualizations can then be communicated using a representation called a structure chart, which uses rectangles to represent each process created and then arrows to subprocesses.The iterative decomposition of the system leads to a highly modular result because each successive decomposition can be represented and implemented as a module. Because the primary role of each of these modules will be to perform a function or an activity in the final system, functional decomposition is used within the process-oriented paradigm. Such a conceptualization of the system to be developed is by definition process oriented.
To understand how modularity can result from increasingly detailed conceptualizations, let us explore what is meant by these conceptualizations.When we say "book-tracking system: we are describing, in the most abstract terms possible, the system to be implemented. This system can then be decomposed into its constituent, more detailed modules (from a process-oriented perspective). The functions that need to occur in a book-tracking system are check out, check in, and resolve. This set of modules is a second level of abstraction because it describes the book-tracking system in more detail than the term "book-tracking system." 软件工程技术英文文献和中文翻译:http://www.751com.cn/fanyi/lunwen_39805.html