Before you actually embark on the total model, it's a good idea to experiment with small-scale models. In that way, you'll acquire useful knowledge about the problem, and you'll get this information early enough in the development cycle to be useful later. Here are a few general points (though by no means all) about this experimental period.

In the model-prototype, the first decision to make is how to extract a miniproblem from the overall problem. The miniproblem provides the basis for a first-cut model of the whole problem. In practice, it's important to get a first-cut model as early as possible. That model serves two purposes: as a validation field for the specifications and as an experimental domain for the feasibility of the project. In this context, it's thus critical to choose a representative miniproblem. If the miniproblem that you extract is too simple, it won't show you how the application will perform. If it's too complicated, it will demand too much work--very possibly wasted effort if the model reveals a flaw in the preceding phases. In other words, the choice of a miniproblem has serious consequences. Your general experience and your knowledge of similar applications will greatly facilitate your choice. One fallback choice--sometimes the essential choice--is to use a small-scale instance of the entire problem.

Once the problem is well defined, it's up to you to design a sound model for it. Fortunately, with Solver, you can use the same language for the entire set of tasks: designing the model, prototyping the application, and implementing the project. In this way, the model itself will immediately yield the first prototype.