University of Tennessee, Knoxville TRACE: Tennessee Research and Creative Exchange

The Harlan D. Mills Collection Science Alliance

9-1987

Cleanroom Software Engineering

Harlan D. Mills

M. Dyer

R. C. Linger

Follow this and additional works at: https://trace.tennessee.edu/utk_harlan

Part of the Software Engineering Commons

Recommended Citation Mills, Harlan D.; Dyer, M.; and Linger, R. C., "Cleanroom Software Engineering" (1987). The Harlan D. Mills Collection. https://trace.tennessee.edu/utk_harlan/18

This Article is brought to you for free and open access by the Science Alliance at TRACE: Tennessee Research and Creative Exchange. It has been accepted for inclusion in The Harlan D. Mills Collection by an authorized administrator of TRACE: Tennessee Research and Creative Exchange. For more information, please contact [email protected]. <4ag :

Q U A L I T Y A S S U R A N C E

Cleanroom Software Engineering

Harlan D. Mills, Information Systems Institute Michael Dyer and Richard C. Linger, IBM Federal Systems Division Software quality can be R ecent experience demonstrates ate units oftime (real or processor time) of that software can be engineered the delivered product. The certification engineered under R under statistical quality control takes into account the growth of reliabil- statistical quality control and that certified reliability statistics can ity achieved during system testing before withbetter be provided with delivered software. delivery. anddelivered IBM's Cleanroom process' has uncovered To gain the benefits of quality control quality. The Cleanroom a surprising synergy between mathemati- during development, Cleanroom software process gives manage- cal verification and statistical testing of engineering requires a development cycle an software, as well as a major difference of concurrent fabrication and certification ment engineering between mathematical fallibility and of product increments that accumulate approach to release debugging fallibility in people. into the system to be delivered. This lets reliable products. With the Cleanroom process, you can the fabrication process be altered on the engineer software under statistical quality basis of early certification results to control. As with cleanroom hardware achieve the quality desired. development, the process's first priority is defect prevention rather than defect Cleanroom experience removal (of course, any defects not Typical of our experience with the prevented should be removed). This first Cleanroom process were three projects: an priority is achieved by using human IBM language product (40,000 lines of mathematical verification in place of pro- code), an Air Force contract helicopter gram debugging to prepare software for flight program (35,000 lines), and a NASA system test. contract space-transportation planning system (45,000 lines). A major finding in statistical certification of the software' these cases was that human verification, quality through representative-user testing even though fallible, could replace debug- atthesystem level. The measure of qual- ging in software development - even ityTis the mean time to failure in appropri- informal human verification can produce

September 1987 0740-7459/87/0900/0019/$01.00 © 1987 IEEE 19 software sufficiently robust to go to sys- processing (1000 to 2000 lines), indicates The Cleanroom process permits a tem test without debugging. better productivity and quality with the sharper structuring of development work Typical program increments were 5000 Cleanroom process than with interactive between specification, design, and testing, to 15,000 lines of code. With experience debugging and integration - even the first with clearer accountabilities for each part and confidence, such increments can be time you use it.3 of the process. This structuring increases expected to increase in size significantly. management's ability to monitor work in All three projects showed productivity Management progress. Inexperienced software equal to or better than expected for ordi- perspective managers often fail to recognize and nary software development: Human At first glance, statistical quality control expose early software problems (like hard- verification need take no more time than and software development seem incom- ware or specification instability, inex- debugging (although it takes place earlier patible. Statistical quality control seems to perienced personnel, and incomplete in the cycle). apply to manufacturing, especially man- design solutions) and mistakenly think The combination of formal design ufacturing of multiple copies of a previ- they can resolve and manage these prob- methods and mathematics-based verifica- ously specified and designed part or lems over time. The Cleanroom process tion had a positive development effect: product. Software development seems to forces these early problems into the open, More than 90 percent of total product be a one-of-a-kind logical process with no giving all levels of management an oppor- defects were found before first execution. statistical properties at all. After all, ifthe tunity to resolve them. This is in marked contrast to the more cus- software ever fails under certain condi- The Cleanroom process requires stable tomary experience of finding 60 percent of tions, it will always fail under those con- specifications as its basis. Because speci- product defects before first execution. ditions. fications are often not fully known or veri- This effect is probably directly related to fied during initial development, it might the added care and attention given to appear at first glance that the Cleanroom design in lieu ofrushing into code and rely- Developing stable process does not apply. But, in fact, the ing on testing to achieve product quality. specifications early discipline of the Cleanroom process is A second encouraging trend is the drop most useful in forcing specification defi- in total defect count (by as much as half), establishes clear ciencies into the open and giving manage- which highlights the Cleanroom focus on accountability. ment control ofthe specification process. error prevention as opposed to error detec- As long as development is treated as a tion. industry averages at 50 to 60 trial-and-error process, the incompleteness With However, by rethinking the process of errors per 1000 lines ofcode, halving these of specification can be accommodated as statistical quality control itself from a just one more source oftrial and error. The numbers is significant. management perspective, we can find a The IBM language product result is diluted accountability between way to put software development under specifiers and developers. A better way is (Cobol/SF2) experience is especially statistical quality control with significant instructive-. This advanced technology to develop software to early, stable speci- management benefits. fications that remain stable in each itera- product, comparable in complexity to a But where do the statistics come from, compiler, was formally specified and then tion. This establishes a clear accountability when neither software nor its development between specification and development, designed in a process-design language. have any statistical properties at all? The Specification text exceeded design text by keeping management in control of speci- statistics come from the usage ofthe soft- fication changes. about four to one. Every control structure ware, not from its intrinsic properties. in the design text was verified in formal, Engineering software under statistical mathematics-based group inspection, so quality control requires that we not only Statistical quality the product proved very robust. A first specify the functional behavior of the soft- control phase of development (20,000 lines) had ware but also its statistical usage. Statistical quality control begins with an just 53 errors found during testing. Cleanroom software engineering is a agreement between a producer and Correctness verification was the corner- practical process to place software devel- receiver. A critical part of this agreement, stone ofthe project; many programs were onM*'rUt Inder- St-2Ati%'t;zd ~julicontro. explicit or implicit, is how to measure qual- redesigned to permit simpler verification The significance of a process under statisti- ity, particularlystatistical quality. For sim- arguments. Productivity averaged more cal quality control is well-illustrated by ple products with straightforward than 400 lines of code per man-month, modern manufacturing techniques where physical, electrical, or other measure- largely as a result of sharply reduced test- the sampling of output is directly fed back ments, the agreement may be simply stated ing time and effort compared to conven- into the process to control quality. Once - for example, 99 percent of certain fila- tional developments. the discipline of statistical quality control ments are to exhibit an electrical resistance A controlled experiment at the Univer- is in place, management can see the devel- within 10 percent of a fixed value. How- sity of Maryland, with student teams opment process and can control process ever, software is complex enough to developing a common project in message changes to control product quality. require a new understanding on how

20 IEEE Software statistical quality can be measured. and performance. So a certification of having no gotos without acquiring the fun- For even the simplest of products, there software quality is a business measure, damental discipline of mathematical is no absolute best statistical measure of part of the overall consideration in verification in engineering software - of quality. For example, a statistical average producing and receiving software. even discovering that such a discipline can be computed many ways - an arith- Once a basis for measuring statistical exists. metic average, a weighted average, a geo- quality of delivered software is available, In contrast, learning the rigor of mathe- metric average, and a reciprocal average creating a management process for statisti- matical verification leads to behavioral can each be better than the others in vari- cal quality control is relatively straightfor- modification in both individuals and ous circumstances. ward. In principle, the goal is to find ways teams of programmers, whether programs It finally comes down to a judgment of to repeatedly rehearse the final measure- are verified formally or not. Mathemati- business and management - in every case. ment during software development and to cal verification requires precise specifica- In most cases, the judgment is practically modify the development process, where tions and formal arguments about the automatic from experience and precedent, necessary, to achieve a desired level of correctness with respect to those specifi- but it is a judgment. In the case of soft- statistical quality. cations. ware, that judgment has no precedent The Cleanroom process has been Two main behavioral effects are read- because the concept of producing software degn ocarryotis pnciple. It c ily observable. First, communication under statistical quality control is just at forthe are in incre- among programmers (and managers) its inception. 'ments that nermit realistic measuremenTs becomes much more precise, especially A new basis for the certification of soft- .rof statistical quality during d;evelopout program specifications. Second, a ware quality, given in Currit, Dyer, and with provision for improving themasure remium is placed on the simplest pro- Mills,' is based on a new software- grams possible to achieve specified func- engineering process.4 This basis requires a tion and performance. software specification and a probability If a program looks hard to verify, it is distribution on scenarios of the software's Statistical quality the program that should be revised, notthe use; it then defines a testing procedure and measurements verification. The result is high productiv- a prescribed computation from test data ultimately come down ityin producing software that requires lit- results to provide a certified statistical to and tle or no debugging. quality of delivered software. management This new basis represents scientific and business judgmentsCleanroomthematical verificationsoftwar engineeringto replace pro-uses engineering judgment of a fair and gram debugging before releaseato-staTi- reasonable way to measure statistical qual- cal testing. This mathematical verification ity of software. As for simpler products, quality by additional testing, by process isdone by people, based on standard there is no absolute best and no logical changes (such as increased insnections and software-engineering practices such as arguments for it beyond business and conguration control), or by lh those taught at the IBM Software Engi- management judgment. But it can provide mnietnods. ' - neering Institute. We find that human a basis for software statistical quality as a verification is surprisingly synergistic with contractual item where no such reasonable statistical testing - that mathematical fal- item existed before. Mathematical libility is very different from debugging The certification of software quality is verification fallibility and that errors of mathematical given in terms of its measured reliability Software engineering without mathe- fallibility are much easier to discover in over a probability distribution of usage matical verification is no more than a statistical testing than are errors of debug- scenarios in statistical testing. Certifica- buzzword. When Dijkstra introduced the ging fallibility. tion is an ordinary process in business - idea ofstructured programming at an early Perhaps one day automatic verification even in the certification ofthe net worth of software-engineering conference,5 his of software will be practical. But there is a bank. As in software certification, there principal motivation was to reduce the no need to wait for the engineering value is a fact-finding process, followed by a length of mathematical verifications of and discipline ofmathematical verification prescribed computation. programs by using a few basic control until that day. In the case of a bank, the fact-finding structures and eliminating gotos. Experimental data from projects where produces assets and liabilities, and the Many popularizers of structured pro- both Cleanroom verification and more computation subtracts the sum of the lia- gramming have cut out the rigorous part traditional debugging techniques were bilities from the sum of the assets. For the about mathematical verification in favor used offers evidence that the Cleanroom- bank, there are other measures of impor- ofthe easy part about no gotos. But by cut- verified software exhibited higher quality. tance besides net worth - such as good- ting out the rigorous part, they have also For the verified software, fewer errors will, growth, and security of assets - just cut out much of the real benefit of struc- were injected, and these errors were less as there are other measures for software tured programming. As a result, a lot of severe and required less time to find and than reliability - such as maintainability people have become three-day wonders in fix. The verified product also experienced September 1987 21 better field quality, all ofwhich was due to cal usage. A structured specification is a the added care and attention paid during Cleanroom software formal specification (a relation or set of design. engineering ordered pairs) for a decomposition into a While it may sound revolutionary at nested set of subspecifications for succes- Findings from an early Cleanroom proj- first glance, the Cleanroom software engi- ect (where verified software accounted for sive product releases. A structured speci- neering process is an evolutionary step in fication defines not only the final software approximately half the product's func- software development. It is evolutionary tion) indicate that verified software but also a release plan for its incremental in eliminating debugging because, over the implementation and statistical testing. accounted for only one fourth the error past 20 years, more and more program count. Moreover, the verified software A stepwise refinement or decomposition design has been developed in design lan- of requirements creates successive levels of was responsible for less than 10 percent of guages that must be verified rather than the severe failures. These findings substan- software design. At each level of decom- executed. So the relative effort for position, mathematics-based correctness tiate that verified software contains fewer advanced teams in debugging, compared defects and that those defects that are pres- arguments ensure the accuracy of the to verifying, is now quite small, even in evolving design and the continued integrity ent are simpler and have less effect on non-Cleanroom development. product execution. of the product requirements. The work It is evolutionary in statistical testing strategy is to create specifications and the The method of human mathematical because with higher quality programs at design to those specifications, as well as to verification used in Cleanroom develop- the outset, representative-user testing is check the correctness ofthat design before ment, called functional verification, is correspondingly a greater and greater frac- proceeding to the next decomposition. quite different than the method of axio- tion of the total testing effort. And, as The Cleanroom design methods use a matic verification usually taught in univer- limited set of design primitives to capture sities. It is based on functional semantics software logic (sequence, selection, and and on the reduction of software verifica- iteration). They use module and procedure tion to ordinary mathematical reasoning In verfied software, primitives to package software designs about sets and functions as directly as developers essentially into products. Decomposition of software possible. never resorted to data requirements is handled by a compan- ion set of data-structuring primitives The for debugging. (sets, motivation functional verifica- and that ensure tion and for the stacks, queues) product earliest possible reduction designs with strongly typed data opera- of verification reasoning to sets and func- tions. Specially defined design tions is the problem of up. A languages scaling set or already noted, we have found a surprising document designs and provide a function can be described in three lines of straight- synergism between human verification and forward translation to standard program- ordinary mathematics notation or in 300 statistical testing: People are fallible with ming forms. lines of English text. There is more human human verification, but the errors they In the Cleanroom test- in model, structural fallibility 300 lines of English than in leave behind for system testing are much ing that requires knowledge of the design three lines of mathematical notation, but easier to find and fix than those left behind is replaced by formal verification, but the verification paradigm is the same. from debugging. functional testing is retained. In fact, this By introducing verification in terms of Results from an early Cleanroom proj- testing can be performed with the two sets and functions, you establish a basis for ect where verification and debugging were goals of demonstrating that the product reasoning that scales up. Large programs used to develop different parts ofthe soft- requirements are correctly implemented in have many variables, but only one func- ware indicate that corrections to the veri- the software and of providing a basis for tion. Mills and Linger6 gave an additional fied software were accomplished in about product-reliability prediction. The latter is basis for verifying large programs by one fifth the average time of corrections to a unique Cleanroom capability that results designing with sets, stacks, and queues the debugged software. In the verified from its statistical testing method, which rather than with arrays and pointers. software case, the developers essentially supports statistical inference from the test never resorted to debugging (less than 0.1 to operating environments. While initially harder to teach than axio- percent of the cases) to isolate and repair The Cleanroom life cycle of incremen- matic verification, functional verification reported defects. tal product releases supports software test- scales up to reasoning for million-line sys- The feasibility of combining human ing throughout the product development tems in top-level design as well as for verification with statistical testing makes rather than only when it is completed. This hundred-line programs at the bottom it possible to define a new software- allows the continuous assessment of prod- level. The evidence that such reasoning is engineering process under statistical qual- uct quality from an execution perspective effective is in the small amount of back- ity control.' For that purpose, we define and permits any necessary adjustments in tracking required in very large systems a new development life cycle of successive the process to improve observed product designed top-down with functional verifi- incremental releases to achieve a struc- quality. cation.7 tured specification of function and statisti- As each release becomes available, 22 IEEE Software statistical testing provides statistical esti- tionship between the number of errors in ing), and mates of its reliability. Software process software and the time between failures in * sporadic failures. analysis and feedback can be used to meet its execution. Half as many errors would Even terminating or permanent failures reliability goals (for example, by increased mean half the failure rate and twice the may be followed by a restart of the soft- verification inspections and by more inter- mean time between failures. In this case, ware, so you can imagine a long history of mediate specification formality) for sub- efforts to reduce errors would automati- execution and, in this history, the failures sequent releases. As errors are found and cally increase reliability. marked at each instant of time. Clearly, fixed during system testing, the growth in It turns out that every major IBM soft- this history will depend on the software's reliability ofthe maturing system can also ware product - without exception - has initial conditions (and data) and on the be estimated so a certified reliability esti- an extremely high error-failure rate vari- subsequent inputs (as commands and mate ofthe system-tested software can be ation. In stable released products, these data) to it. Such a history can be very arbi- provided at final release. failure rates run from 18 months between trary, but suppose for argument's sake Cho8 has also proposed the develop- failures to more than 5000 years. More that representative histories (scenarios of ment of software under statistical quality than half the errors have failure rates of use) are conceivable. control, using as a measure the ratio of more than 1500 years between failures. The behavior of software is determinis- correct outputs to total outputs. He Fixing these errors will reduce the number tic in that repeating an initial condition and regards software as a factory for produc- of errors by more than half, but the history of use will reproduce the same out- ing output, rather than for producing a decrease in the product failure rate will be puts (with the same failures). But, in fact, product itself. The ratio ofcorrect outputs imperceptible. More precisely, you could ifsoftware is used in more than one history to total outputs is directly related to the by more than one user, the histories ofuse mean time between failures, where time is will usually be different. For that reason, normalized to output production. Such a we consider as part of a structured speci- normalization is one possibility in the fication a probability distribution of usage Cleanroom process, but other normaliza- Users do not see errors histories, typically defined as a stochastic tions may be more meaningful in most sys- in software, they see process. tem applications. failures in execution. This probability distribution of usage A principal difference between the histories will, in turn, induce a probabil- Cleanroom and Cho's ideas is the use of a ity distribution of failure histories in which certification model to account for the statistics about times between failures, growth in reliability during development. remove more than 60 percent ofthe errors failure-free intervals, and the like can be Another major difference is an insistence but only decrease the failure rate by less defined and estimated. So, even though on human mathematical verification with than 3 percent. software behavior is deterministic, its no program debugging before These surprising refutations of conven- reliability can be defined relative to its representative-user testing at the system tional wisdom in software reliability are statistical usage. Such a probability distri- level. As Mills discussed,9 human mathe- due to data painstakingly developed over bution of usage histories provides a matical verification is possible and prac- many years by Adams. 10 statistical basis for software quality tical at high production rates. The time To be more precise about software control. spent on verification can be less than the errors and failures, assume that a specifi- time spent on debugging. cation and its software exist. Then, when the software is executed, its behavior can Certifying sttistical Statistical basis be compared with its specification and any quality Software people customarily talk about discrepancies (failures). Such failures may For software already released, it is sim- errors in the software, typically measured be catastrophic and prevent further execu- ple to estimate its reliability in mean times in errors per thousand lines of code. Cur- tion (for example, by abnormal termina- to failure: Merely take the average of its rent postdelivery levels in ordinary soft- tion). Other failures may be so serious that times between failure in statistical testing. ware are one to 10 errors per thousand every response from then on is incorrect However, for software under Cleanroom lines. Good methodology produces post- (for example, if a database is com- development, the problem is more compli- delivery levels under one error per thou- promised). Less serious failures represent cated, for two reasons: sand lines. But such numbers are irrelevant the case in which the software continues to 1. In each Cleanroom increment, and misleading when you consider soft- execute with at least partially correct results of system testing may indicate soft- ware reliability. Users do not see errors in behavior beyond the failure. ware changes to correct failures found. the software, they see failures in execution, These examples illustrate that failures 2. With each Cleanroom increment so the measurement of times between represent different levels of severity, release, untested new software will be failures is more relevant. beginning with three major levels: added to software already under test. If each error had the same or similar * terminating failures, In fact, each change or set ofchanges to failure rate, there would be a direct rela- * permanent faihures (but not terminat- correct failures in a release creates a new September 1987 23 software product very much like its gives producer and receiver (seller and pur- aggregate testing experience across incre- predecessor but with a different reliability chaser) a common, objective way to cer- ments. A simple aggregation could com- (intended to be better, but possibly worse). tify the reliability of the delivered plement separately treated increments with However, each ofthese corrected software software. The certification is a scientific, management judgment. products, by itself, will be subject to a statistical inference obtained by a A more sophisticated treatment of sep- strictly limited amount oftesting before it prescribed computation on test data war- arate releases would be to model the fail- is superseded by its successor, and statisti- ranted to be correct by the developer. ure contribution of each newly released cal estimates of reliability will be cor- In principle, the estimators for software part ofthe software and to develop strati- respondingly limited in confidence. reliability are no more than a sophisticated fied estimators release by release. Earlier Therefore, to aggregate the testing expe- way to average the times between failure, releases can be expected to mature while rience for an increment release, we define taking into account the change activity later releases come under test. This matu- a model of reliability change with called for during statistical testing. As test ration rate in reliability improvement can parameters Mand R (as discussed in Cur- data materializes, the reliability can be esti- be used to estimate the amount oftest time rit, Dyer, and Mills') for the mean time to mated, even change by change. And with required to reach prescribed reliability failure after c software changes, of the successful corrections, the reliability esti- levels. form MTTF = MRC where Mis the initial mates will improve with further testing, mean time to failure of the release and providing objective, quantitative evidence Mean time to failure and the rate of where R is the observed effectiveness ratio of the achievement of reliability goals. change in mean time to failure can be use- for improving mean time to failure with This objective evidence is itself a basis ful decision tools for project management. software changes. for management control of the software For software under test, which has both an Although various technical rationales development to meet reliability goals. For estimated mean time to failure and a are given for this model by Currit, Dyer, example, process analysis may reveal both known rate of change in mean time to fail- and Mills,' it should be considered a con- unexpected sources oferrors (such as poor ure, decisions on releasability can be based tractual basis for the eventual certification understanding of the underlying hard- on an evaluation of life-cycle costs rather of the finally released software by the ware) and appropriate corrections in the than on just marketing effect. developer to the user. Moreover, because process itself for later increments. Inter- When the software is delivered, the there is no way to know that the model mediate rehearsals ofthe final certification average cost for each failure must include parameters M and R are absolutely cor- provide a basis for management feedback both the direct costs of repair and the rect, we define statistical estimators for to meet final goals. indirect costs to the users (which may be them in terms of the test data. The choice The treatment of separate increment much larger). These postdelivery costs can of these estimators is based on statistical releases should also be part ofthe contrac- be estimated from the number of expected analysis, but the choice should also be a tual basis between the developer and user. failures and compared with the costs for contractual basis for certification. Perhaps the simplest treatment is to treat additional predelivery testing. Judgments The net result of these two contractual separate increments independently. How- could then be made about the profitabil- bases - a reliability change model and ever, more statistical confidence in the ity of continuing tests to minimize lifetime statistical estimators for its parameters - final certification will result from costs. -6-

References 4. R.C. Linger, H.D. Mills, and B.I. Witt, 7. A.J. Jordano, "DSM Software Architec- Structured Programming: Theory and ture and Development," IBM Technical 1. A. Currit, M. Dyer, and H.D. Mills, "Cer- Practice, Addison-Wesley, Reading, Mass., Directions, No. 3, 1984, pp. 17-28. tifying the Reliability of Software," IEEE 1979. Trans. SoftwareEng., Jan. 1986, pp. 3-1. 8. C.K. Cho, Quality Programming: Develop- ing and Testing Software with Statistical 2. Cobol Structuring Facility Users Guide, 5. E.W. Dijkstra, "Structured Program- Quality Control, John Wiley & Sons, New IBM Corp., Armonk, N.Y., 1986. ming," in Software Engineering Tech- York, 1987. niques, J.N. Burton and B. Randell, eds., 3. R.W. Selby, V.R. Basili, and F.T. Baker, NATO Science Committee, New York, 9. H.D. Mills, "Structured Programming: "Cleanroom Software Development: An 1969, pp. 88-93. Retrospect and Prospect," IEEE Software, Empirical Evaluation," Tech. Report Nov. 1986, pp. 58-66. TR-1415, Computer Science Dept., Univ. 6. H.D. Mills and R.C. Linger, "Data- 10. E.N. Adams, "Optimizing Preventive Ser - of Maryland, College Park, Md., Feb. Structured Programming," IEEE Trans. vice of Software Products," IBM J. 1985. Software Eng., Feb. 1086, pp. 192-197. Research and Development, Jan. 1984.

24 IEEE Software A SOFTWARE ENGINEERS EMTEK HEALTH CARE SYSTEMS, a fast-growing member of Motorola's New Enterprises Organization based in Phoenix, is looking for some very talented people to develop a state-of-the-art hospital clinical information management system. Engineering Positions are available for: Harlan D. Mills is director of the Information Systems Institute in Vero Beach, Fla., and a * System Architecture professor of computer science at the University * Relational Database Tools Development of Maryland at College Park. He has been an * Hospital Applications Development IBM fellow, a member of the IBM Corporate * Computer-to-Computer Interfaces Technical Committee, and director of software engineering and technology in the IBM Federal Applicants should have an MS in Computer Science with 3-5 years of rele- Systems Division. vant experience. Mills received his PhD in mathematics from Iowa State University and served on the facul- Phoenix, AZ-the valley of the Sun. ties of Iowa State, Princeton, New York, and Johns Hopkins universities. He has served as a The economic forecast for the Phoenix area is sunny indeed- this is the 2nd regent ofthe DPMA Education Foundation and fastest growing market in the country. Steady business growth, warm climate as a governor of the Computer Society of the and diverse economic base are drawing new residents (average age 31.3 years) IEEE. from all over. Join us in one of the most dynamic markets in the U.S. If you are the best at what you do, and want the challenge and excitement of getting in on the ground floor of a dynamic start-up, send your resume, including salary requirements, for immediate, confidential consideration to: Personnel Manager, Dept. #IEEE0901, MOTOROLA INC., P.O. Box 2953, Mail Drop CS44, Phoenix, AZ COMPLETE 85062. An Equal Opportunity/Affirmative Action ClT (usTo Employer. E_VT sATIsFAcTION A Motorola New Enterprises Company |AA MOTOROLA INC. b

Michael Dyer is a senior programming manager at IBM Federal Systems Division. He has held various management and staff positions and is currently responsible for Cleanroom software development and methodology. Dyer received a BS in mathematics from Fordham University. He is a member of the Computer Society of the IEEE.

FEATURES: * Built in Screen Compiler (converts Screen Images to Object Modules without Source Code) * Mainframe style Transaction Processor * 3270 Keyboard Features * End User control over Screen Colors * Realtime Full Screen Editor MANY MORE UNIQUE FEATURES! REQUIREMENTS: * IBM PC, XT, AT, 3270 PC, or 100% compatibles Richard C. Linger is a senior programming * Lattice "C" 3.x or Microsoft "C" 4.0 manager of software engineering studies in the IBM Federal Systems Division. * 256 K Linger received a BS in electrical engineering from Duke University. He is a member of the ACM and Computer Society of the IEEE. Price $295.00 Tel. C91 4) 245-8392 Mills can be reached at Information Science Institute, 2770 Indian River Blvd., Vero Beach, Ad For more information write to: FL 32960. Dyer and Linger can be contacted at IBM Federal Systems Division, 6600 Rockledge W WOLF PAK RE!SEARCH, INC. Dr., Bethesda, MD 20817. WOLF P I so90 Upland Rd. RESEARCH. INC. Yorktown Hts., NY 10598 September 1987 In Australia: CSC Computer Systems, (03) 749-6046 Reader Servke Nmumber 3