Easy to fall back into the code and fix without proper requirement analysis, design, customer evaluation, and feedback.Difficult to know how long the project will last.May be too customer specific, no broad market.Difficult to finish if customer withdraw.Require extensive customer collaboration.An unstable/badly implemented prototype often becomes the final product.Errors can be detected much earlier as the system is made side by side.Regular visible process aids management.Good where requirement are changing/uncommitted.Reduce the risk of incorrect user requirement.In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs, and the output requirement, the prototyping model may be employed. In many instances, the client only has a general view of what is expected from the software product. A prototype usually turns out to be a very crude version of the actual system, possible exhibiting limited functional capabilities, low reliability, and inefficient performance as compared to actual software. A prototype is a toy implementation of the system. The prototype model requires that before carrying out the development of actual software, a working prototype of the system should be built.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |