Rapid Prototyping and DevOps On Artificial Intelligence Projects

Source:-it.toolbox.com

Managers and technical personnel unfamiliar with AI are initially dubious about being able to develop even a limited-capability prototype in the space of just one or two months. (Rapid prototyping, in the jargon of the trade.) However, many rapid prototypes have been built in only a few weeks. These prototypes are necessarily limited in the degree to which they meet the overall requirements of the final system.

Rapid prototypes provide a number of significant benefits. The feasibility of the project plan can be verified before spending a major part of the budget. Meaningful discussions of functional requirements between the developers and users or customers can occur early in the project. These discussions can be helpful in reducing misunderstanding. Even with a detailed 500-page product specification, established and agreed upon at the beginning of a project, misunderstandings between developer and user can arise later in the project. It is difficult to perceive in advance all of the questions which may arise or differences in interpretation of what the specification means. When both developers and users are studying the same CRT screen output of a prototype, it is much easier to resolve differences in the scope of the problem, its solution, and the performance requirements for the system.

The initial prototype and its subsequent upgrades are helpful in assisting both the developer and the intended user to further define the subtleties of the problem. Many of these applications are in uncertain problem domains and the users themselves may be unsure of what the system should do and the environment in which it will operate. Since it is relatively easy to change the knowledge base in the prototype, further refinement of the user’s thinking can be readily accommodated without causing substantial schedule and cost problems. If the extent of the requested modification becomes too great, the prototype can be used to evaluate the probability that the project constraints will be exceeded.

Even experienced Al project managers can be pleasantly surprised by the ease and speed with which a limited scope prototype can be developed.

A group of development engineers and manufacturing personnel had conceived of a knowledge system which they believed would be of great help to the quality assurance function. They explained the concept to a manager who only vaguely understood what the system would do. She agreed that the idea was certainly worth further study, but insisted that the concept be described more completely before development of even a demonstration-level prototype was started.

She stated to the development group, “Before we talk about funding you for this effort, please define the scope of the prototype. Give me a better feel for what this system will do and how much will be required to develop it.”The development group was then charged with the responsibility, assisted by manufacturing, to write up a more detailed description of what they proposed to do. However, instead of writing up a definitive project specification, the development personnel went off by themselves. Two weeks later they called up the manager arid asked her to come down to the laboratory. At that time, they were able to give her an effective demonstration that contained perhaps 15 or 20 rules. In the space of just two weeks, they were able to indicate both concept feasibility and potential benefits.

Although there are wide variations, a typical rule-based rapid prototype might comprise from 50 to 100 rules. Generally, building such a prototype requires one to three months of development time. The development time may be considerably shortened if effective software tools are utilized. Enthusiasm for immediate implementation of an operational system, generated by this short development time, must be tempered with reality regarding the capabilities of the prototype. Limitations of the first prototype may include:

1. Shallow knowledge inconsistent with a full-scale system
2. Ability to handle only one or two limited test cases
3. Inefficient implementation
4. Constrained user interface
5. System operation requiring supervision by the developer

As noted in some of my previous posts, it is desirable to select an Al project which can subsequently also serve as a building block for additional applications. The rapid prototype can be an effective vehicle to provide a basis for considering other applications. Evaluation and use of the prototype frequently generate other ideas, either from the domain expert or from the intended user. Some of these new ideas may go considerably beyond the intended scope of the first Al project.