Case study and its answer of nestle

Transfer For several years the author was involved in a research project at a major aerospace corporation. The project studied techniques for program synthesis, automatic code generation, very high-level languages, graphical design tools and similar topics. The goal was to simplify specification of software systems and to make code synthesis practical by working in a restricted domain. As in most industrial research laboratories there was the pressure to show practical relevance of the work.

To that ND, the project developed a number of prototype tools that were considered practical and useful by academic standards (e. G. [3, 2, 8, 4, 5]). But academic standards are not good enough to be accepted by those responsible for real products. Several attempts to transition some of the lab’s technology to product divisions were met with universal rejection.

There were several reasons for this rejection, most of them non-technical in nature. * Academics tend to develop tools in the abstract, I. E. , they solve an intellectually interesting problem without regard to actual applications.

When scientists talk about concepts such as ‘ ‘ completeness of decision procedures” of ‘ ‘ expressiveness of languages,” their value will not be apparent to decision makers.

Technology must be sold by describing the concrete problems being solved, how much time is saved, and how quality is Improved. The technology is irrelevant, It is its impact that matters. * People In charge of software projects are extremely concerned about schedule risk. Even If a new tool promises great time savings, It will be rejected If there Is even minimal risk that It might negatively Impact the schedule.

Large potential time savings are often not realistic due to a steep learning curve.

* Researchers tend to build tools In Isolation without consideration of the environment and the work process of software production. Tools that require changes In an established software development process are difficult to sell. * An Important reason for rejection Is the perceived and often real lack of maintenance and support for systems that come out of research labs. * One frequent objection to the use of machine generated code was readability. From the academic point of view, machine enervated Dad code Is no different than compiler generated assembly code.

But the programmer In the field will be skeptical of the new technology and will want to Inspect and understand the code.

As a consequence significant effort was spent on generating human readable, commented code. Case Study and Its Answer ofNestleBy Jailhouse how much time is saved, and how quality is improved. The technology is irrelevant, it is its impact that matters. * People in charge of software projects are extremely concerned about schedule risk.

Even if a new tool promises great time savings, it will e rejected if there is even minimal risk that it might negatively impact the schedule.

Researchers tend to build tools in isolation without consideration of the environment and the work process of software production. Tools that require changes in an * An important reason for rejection is the perceived and often real lack of maintenance and support generated Dad code is no different than compiler generated assembly code. But the programmer in the field will be skeptical of the new technology and will want to inspect and understand the code. As a consequence significant effort was spent on