A fundamental concept in software engineering is the software life cycle. Software， like many other products， goes through a cycle of repeating phases （Figure 5-1）.
Software is first developed by a group of developers/programmers. Usually， it is in use for a while before modifications are necessary. Modification is often needed due to errors found in the software， changes in the roles or laws， or changes in the company itself. The software should be modified before further use. These two steps use and modify， continue until the software becomes obsolete. By "obsolete，" we mean the software loses its validity because of inefficiency， obsolescence of the language， major changes in the company， or other factors. Some examples of software developments that normally go through this cycle are student registration systems， billing systems， and accounting systems.
The development process in the software life cycle involves four phases：analysis， design， implementation， and testing. Figure 5-2 shows these phases as part of the development process.
The development process starts with the analysis phase， which shows what the package should do. In this phase， the systems analyst defines requirements that specify what the proposed system is to accomplish. The requirements are usually stated in terms that the user understands. There are four steps in the analysis phase：define the user， define the needs， define the requirements， and define the methods.
A software package may be designed for a generic user or a specific user. For example， an accounting package may be created for use by any firm. On the other hand， a customized banking package may be created for a specific bank. The user of the package must be clearly defined.
After the user has been identified， the analysts clearly define the needs. In this step， the best answer comes from the user. The user， or the representative of the user， clearly defines his/her expectations of the package.
Based on the needs of the user， the analyst can exactly define the requirements for the system. For example， if a package is to print checks at the end of the month for each employee， what level of security and accuracy should be implemented？
Finally， after the requirements are defined in clear terms， the analyst can choose the appropriate methods to meet those requirements.
The design phase defines how the system will accomplish what was defined in the analysis phase. In the design phase， the systems are determined， and the design of the files and the databases is completed.
There are two types of testing： black box and white box. Black box testing is done by the system test engineer and the user. White box testing is the responsibility of the programmer.
Black box testing gets its name from the concept of testing a program without knowing what is inside it and without knowing how it works. In other words， the program is like a black box that you can't see into.
Simply stated， black box test plans are developed by looking only at the requirements statement. This is why it is so important to have a good set of requirements. The test engineer uses these requirements and his or her knowledge of systems development and the user working environment to cream a test plan. This plan will then be used when the system is tested as a whole. You should ask to see these test plans before you write your program.
Whereas black box testing assumes that nothing is known about the program， white box testing assumes that you know everything about the program. In this case， the program is like a glass house in which everything is visible.
White box testing is the responsibility of the programmer， who knows exactly what is going on inside the program. You must make sure that every instruction and every possible situation have been tested. That is not a simple task！
Experience will help a programmer design good test data， but one thing that she can do from the start is to get in the habit of writing test plans. She should start her test plan when she is in the design stage. As she builds her structure chart， she should ask herself what situations， especially unusual situations， she needs to test for and make a note of them immediately. She may not remember an hour later.
When she is writing her flowcharts， she should review them with an eye toward test cases and make notes of the cases she needs.
When it comes time to construct her test cases， she should review her notes and organize them into logical sets. Except for very simple student programs， one set of test data will not completely validate a program. For large-scale development projects： 20， 30， or more test cases may need to be run to validate a program.
Finally， while she is testing， she will think of more test cases. Again， she should write them down and incorporate them into her test plan. After her program is finished and in production， she will need the test plans again when she modifies the program.
【New Words】
life cycle
生命周期
test case
测试用例
validate
确认，证实，验证
algorithmic
算法的
modularity 模块性，模块化
structure chart
结构图
generic
通用的，一般的，类的 package
程序包
validity
有效性
obsolescence
过时，淘汰
5.2 The Methods of Modern Software Design
We shall briefly discuss some topics in modern software designs such as top-down design/programming， bottom-up design/programming， and structured design/programming.
Top-down design is basically a decomposition process， which focuses on the flow of control or on the control structure of the program. The first step is to study the overall aspects of the task at hand and to break it down into a number of modules （perhaps 3 to 10）. The second step is to break down each one of these modules further into independent sub modules. The process repeats until you can obtain modules that are small enough to grasp mentally and to code at one sitting in a straightforward， uncomplicated way. A multi-level logic/control structure is thus formed. Clearly， some modules may extend through several levels.
