In the original paper of Boehm about the spiral model, he explains that the prototyping is meant for "building twice", a principle suggested by Royce in his paper about improving the waterfall approach.

Applied to a requirement analysis, the prototype can be as simple as a first mock, to explain and discuss the first ideas with the stakeholders. This is the same approach as RAD: with some tools you build a prototype that is not functional, but that allows to show screens to the users so that they can better imagine what is going to be build and fine-tune their requirements.

In the design phase, the prototype would entail some more concrete coding, to assess the feasibility and robustness of the architecture and some core ideas of the design.

This prototyping approach is very different from the incremental development that we are used to nowadays, and where you'd implement something that is really working to show to the user. A prototype is generally made for experimental needs and then thrown away: you'd see what works and what doesn't, and then you'd start to develop using the right approach.

About your last question, a prototype contributes to risk reduction in several means:

• it demonstrates feasibility of an idea
• it allows to verify that requirements have been well understood
• if reveals if requirements were incomplete and more needs to be done
• it allows to experiment with the architecture and design and verify some properties there of (e.g. can the architecture cope with high volumes).

P.S: you may be interested also in this answer to another question

In the original paper of Boehm about the spiral model, he explains that the prototyping is meant for "building twice", a principle suggested by Royce in his paper about improving the waterfall approach.

Applied to requirement analysis, the prototype can be as simple as a first mockup, to explain and discuss the first ideas with the stakeholders. This is the same approach as RAD: with some tools you build a prototype that is not functional, but that allows you to show screens to the users so that they can better imagine what is going to be build and fine-tune their requirements.

In the design phase, the prototype would entail some more concrete coding, to assess the feasibility and robustness of the architecture and some core ideas of the design.

This prototyping approach is very different from the incremental development that we are used to nowadays, and where you'd implement something that is really working to show to the user. A prototype is generally made for experimental purposes and then thrown away: you'd see what works and what doesn't, and then you'd start to develop using the right approach.

Regarding your last question, a prototype can contribute to risk reduction in several ways:

• It demonstrates the feasibility of an idea.
• It allows you to verify that requirements have been well understood.
• If reveals if requirements were incomplete and more needs to be done.
• it allows you to experiment with the architecture and design and verify some properties thereof (e.g. can the architecture cope with high volumes).

P.S: you may also be interested in this answer to another question

In the original paper of Boehm about the spiral model, he explains that the prototyping is meant for "building twice", a principle suggested by Royce in his paper about improving the waterfall approach.

Applied to a requirement analysis, the prototype can be a first mock, to explain and discuss the first ideas with the stakeholders. This is the same approach as RAD: with some tools you build a prototype that is not functional, but you can show screens to the users so that they can better imagine what is going to be build and fine-tune their requirement.

In the design phase, the prototype would entail some real coding, to assess the feasibility and robustness of the architecture and some core ides of the design.

This prototyping approach is very different from the incremental development that we are nowadays used to, and where you'd implement something that is really working to show to the user. A prototype is generally made for experimental needs and then thrown away: you'd see for example what works and what doesn't work, and then you'd start to develop using the working approach and carefully avoiding the not working approach.

About your last question, a prototype contributes to risk reduction in several means:

• it demonstrates feasibility of an idea
• it allows to verify that requirements have been well understood
• if reveals if requirements were incomplete and more needs to be done
• it allows to experiment with the architecture and design and verify some properties there of (e.g. can the architecture cope with high volumes).

In the original paper of Boehm about the spiral model, he explains that the prototyping is meant for "building twice", a principle suggested by Royce in his paper about improving the waterfall approach.

Applied to a requirement analysis, the prototype can be as simple as a first mock, to explain and discuss the first ideas with the stakeholders. This is the same approach as RAD: with some tools you build a prototype that is not functional, but that allows to show screens to the users so that they can better imagine what is going to be build and fine-tune their requirements.

In the design phase, the prototype would entail some more concrete coding, to assess the feasibility and robustness of the architecture and some core ideas of the design.

This prototyping approach is very different from the incremental development that we are used to nowadays, and where you'd implement something that is really working to show to the user. A prototype is generally made for experimental needs and then thrown away: you'd see what works and what doesn't, and then you'd start to develop using the right approach.

About your last question, a prototype contributes to risk reduction in several means:

• it demonstrates feasibility of an idea
• it allows to verify that requirements have been well understood
• if reveals if requirements were incomplete and more needs to be done
• it allows to experiment with the architecture and design and verify some properties there of (e.g. can the architecture cope with high volumes).

P.S: you may be interested also in this answer to another question