A prototype represents the shell of an actual production application. Prototypes are built early in the development lifecycle, and they’re used to provide valuable insight into the look, feel, and general workflow of an application. (Sometimes people call the first production implementation a prototype, but that’s not correct. If you have multiple implementations, the first one is more aptly called a pilot test. Likewise, a prototype is not used to validate whether a proposed solution works. This is more aptly called a proof-of-concept.)
The main purpose of a prototype is to gather and document requirements. If you’re pretty confident that you have a good set of requirements, there’s not necessarily a reason to build an initial prototype. After you build an initial prototype you should show it to the clients to validate the work done so far looks okay. You then use the prototype to gather additional requirements. As you receive requirements, you should document them in the same way you would document the additional requirements you’re gathering though other means.
The prototype starts off as a shell that contains the online screens. There should be very little programming of the core business processes and only enough program code to allow the prototype to go from screen to screen. The point of the prototype is to provide a visual representation of the application, not the complex business logic that goes behind it.
What happens to the prototype?
There are two options for what happens to the prototype once it’s built.
1. Complete or partial throw-away. Typically, if you build a prototype, you’ll throw it away after the requirements have been gathered. Remember that the prototype does not have to be the start of the final solution. The main purpose is to gather requirements. I’ve seen online applications that appeared to be running on the web, when, in reality, the team members built the prototype in PowerPoint or Excel. There was no thought that somehow this PowerPoint prototype would be reused further as the project progresses. On the other hand, in many instances you’ll build a prototype using the same technology as the final solution. In this case, there may be some aspects that can be reused. You may be able to leverage some of the physical components of the prototype as a starting point for the Design and Construct Phases of the project.
2. Iteratively develop into final application. If you’re using an iterative development approach, the first prototype should still be put together quickly. However, instead of the work being abandoned or thrown away, the prototype is updated with the new requirements. In the second pass, more business logic is also placed into the application. At this point, it’s no longer called a prototype. Instead, the prototype shell is used as the basis for developing the final solution.
In summary, prototypes are used to gather requirements, and are especially useful in visualizing the look and feel of an application and the process workflow. The useful life of a prototype will vary according to the project lifecycle model. It’s possible that the prototype can be thrown away, or that some components can be reused later in the project. It’s also possible that the prototype can be used as the basis for developing the final solution.
The main purpose of a prototype is to gather and document requirements. If you’re pretty confident that you have a good set of requirements, there’s not necessarily a reason to build an initial prototype. After you build an initial prototype you should show it to the clients to validate the work done so far looks okay. You then use the prototype to gather additional requirements. As you receive requirements, you should document them in the same way you would document the additional requirements you’re gathering though other means.
The prototype starts off as a shell that contains the online screens. There should be very little programming of the core business processes and only enough program code to allow the prototype to go from screen to screen. The point of the prototype is to provide a visual representation of the application, not the complex business logic that goes behind it.
What happens to the prototype?
There are two options for what happens to the prototype once it’s built.
1. Complete or partial throw-away. Typically, if you build a prototype, you’ll throw it away after the requirements have been gathered. Remember that the prototype does not have to be the start of the final solution. The main purpose is to gather requirements. I’ve seen online applications that appeared to be running on the web, when, in reality, the team members built the prototype in PowerPoint or Excel. There was no thought that somehow this PowerPoint prototype would be reused further as the project progresses. On the other hand, in many instances you’ll build a prototype using the same technology as the final solution. In this case, there may be some aspects that can be reused. You may be able to leverage some of the physical components of the prototype as a starting point for the Design and Construct Phases of the project.
2. Iteratively develop into final application. If you’re using an iterative development approach, the first prototype should still be put together quickly. However, instead of the work being abandoned or thrown away, the prototype is updated with the new requirements. In the second pass, more business logic is also placed into the application. At this point, it’s no longer called a prototype. Instead, the prototype shell is used as the basis for developing the final solution.
In summary, prototypes are used to gather requirements, and are especially useful in visualizing the look and feel of an application and the process workflow. The useful life of a prototype will vary according to the project lifecycle model. It’s possible that the prototype can be thrown away, or that some components can be reused later in the project. It’s also possible that the prototype can be used as the basis for developing the final solution.
