- 1 Share and Enjoy !
- 2 Software Development Models:
- 2.1 Prototype Model
- 2.2 The process steps for prototype
- 2.3 Advantages of Prototype Model
- 2.4 Disadvantages of Prototype Model
- 3 Share and Enjoy !
Software Development Models:
A software cycle deals with various parts and phases from planning to testing and deploying. All these activities are carried out in different ways, as per the needs. Each way is known as a Software Development Lifecycle Model (SDLC).
Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are lots of models, and many companies adopt their own, but all have very similar patterns.
Software prototyping, a possible activity during software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed.
A prototype typically implements only a small subset of the features of the eventual the program, and the implementation may be completely different from that of the eventual product.
The purpose of a prototype is to allow users of the software to evaluate proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions.
Prototyping has several benefits: The software designer and implementer can obtain feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met.
The process steps for prototype
- Identify basic requirements: Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.
- Develop Initial Prototype: The initial prototype is developed that includes the only user.
- Review: The customers, including end-users, examine the prototype and provide interfaces.
- Revise and Enhancing the Prototype: Using the feedback both the specifications and
the prototype can be improved. Negotiation about what is within the scope of the contract/ product may be necessary. If changes are introduced then a repeat of steps # 3 and # 4 may be needed.
Advantages of Prototype Model
Reduced time and costs:
Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software.
Improved and increased user involvement:
Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said.
Since users know the problem domain better than anyone on the development team does, increased interaction can result in a final product that has greater tangible and intangible quality. The final product is more likely to satisfy the user’s desire to look, feel and performance.
Disadvantages of Prototype Model
The focus on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain. Further, since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a model.
User confusion of prototype and finished system:
Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. (They are, for example, often unaware of the effort needed to add error checking and security features which a prototype may not have.) This can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers.
Users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system. If users are able to require all proposed feature be included in the final system this can lead to the feature creep.
Developer attachment to prototype:
Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture.
Excessive development time of the prototype:
A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.
The expense of implementing prototyping:
The start-up costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to just jump into the prototyping without bothering to retrain their workers as much as they should.
A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for the use of a prototyping technique, there is an often-overlooked need for developing the corporate and project-specific underlying structure to support the technology. When this underlying structure is omitted, lower productivity can often result.