Prototyping
Introduction: In comparison to modeling-based approaches, prototyping takes a different approach to problem analysis. In prototyping, a partial system is built, which is then used by clients, users and developers to gain a better understanding of the problems and needs. Therefore, the real experience with a prototype that implements part of the final software system, is used to analyze the problem and understand the requirements of the final software system. A software prototype can be defined as a partial implementation of a system that aims to learn something about the solution or the solution approach to the problem.
Prototype can also be used to evaluate or evaluate a design option. Here we focus primarily on the prototype used to understand requirements. There are two approaches to the prototype; Tiresome and evolutionary
In Throwaway approach the prototype is constructed with the idea that after completion of the analysis, it will be rejected and the final system will be made from scratch. In the evolutionary approach, the prototype is built with the idea that eventually it will be converted to the final system. From the problem analysis and understanding perspective, the Fenquet prototype is more favorable.

The first question that needs to be addressed is whether to prototype or not. In other words, it is important to clearly understand that when prototype should be done. The requirements of a system can be divided into three sets - which are well understood which are considered bad, and which are not known. In a throwaway prototype, there are poorly understood requirements that should be included.
It may be possible to split a set of poorly understood sets into two sets - important for designing and not important for designing. Requirements can be easily included in the system, which is considered non-political to design.
Development activity begins with SRS for prototype. However, to develop SRS for the prototype it is necessary to identify the tasks that should be included in the prototype. This decision is usually application-dependent. As mentioned earlier, in general, the requirements that become unclear and unclear, or where customers and users are unsure or change their mind, are those who should be implemented in prototype. User interface, new features to be added, and features that may be inflexible are common candidates for prototypes. Depending on which aspects of the system are included in the prototype, the prototype can be considered vertical or horizontal. In horizontal prototype the system is organized as a series of layers and some layer prototype is the focus. In vertical prototype, a selected part of the system, which is not well understood, is fully designed.
This approach is used to validate some of the functionality or capabilities of the system. The development of a tireless prototype is fundamentally different from developing final product-quality software. During prototype, the basic focus is to keep costs low and reduce prototype production time. Due to this, many bookkeeping, documentation and quality control activities that are usually done during software product development are kept minimal during prototype. Efficiency concerns also take the rear seat, and often high level interpretive languages are used for prototyping. For these reasons, the temptation to change the prototype into the final system should be given. Experience is achieved by putting the system to use by the actual customer and the users. To understand their responses, it is necessary to have continued contact with clients / users during this activity.
For prototypes of requirements for possible analysis, its cost should be kept low. As a result, only those features will be a valuable return from the user experience which are included in the prototype. Exception handling, retrieval, conformance with some standards and formats are usually not included in the prototype. Because prototype is to be thrown, only the minimum development documents should be produced during the prototype.
The cost of developing and running a prototype can be approximately 10% of the total development cost. However, it should be noted that if the cost of prototype is 10% of the total development cost, it does not mean that this amount has increased the cost of development. The main reason is that due to the use of prototype in the context of low requirement errors, there is a possibility of substantial reduction in the cost of development and the reduced amount of requests for change required.
Prototype can also be used to evaluate or evaluate a design option. Here we focus primarily on the prototype used to understand requirements. There are two approaches to the prototype; Tiresome and evolutionary
In Throwaway approach the prototype is constructed with the idea that after completion of the analysis, it will be rejected and the final system will be made from scratch. In the evolutionary approach, the prototype is built with the idea that eventually it will be converted to the final system. From the problem analysis and understanding perspective, the Fenquet prototype is more favorable.

The first question that needs to be addressed is whether to prototype or not. In other words, it is important to clearly understand that when prototype should be done. The requirements of a system can be divided into three sets - which are well understood which are considered bad, and which are not known. In a throwaway prototype, there are poorly understood requirements that should be included.
It may be possible to split a set of poorly understood sets into two sets - important for designing and not important for designing. Requirements can be easily included in the system, which is considered non-political to design.
Development activity begins with SRS for prototype. However, to develop SRS for the prototype it is necessary to identify the tasks that should be included in the prototype. This decision is usually application-dependent. As mentioned earlier, in general, the requirements that become unclear and unclear, or where customers and users are unsure or change their mind, are those who should be implemented in prototype. User interface, new features to be added, and features that may be inflexible are common candidates for prototypes. Depending on which aspects of the system are included in the prototype, the prototype can be considered vertical or horizontal. In horizontal prototype the system is organized as a series of layers and some layer prototype is the focus. In vertical prototype, a selected part of the system, which is not well understood, is fully designed.
This approach is used to validate some of the functionality or capabilities of the system. The development of a tireless prototype is fundamentally different from developing final product-quality software. During prototype, the basic focus is to keep costs low and reduce prototype production time. Due to this, many bookkeeping, documentation and quality control activities that are usually done during software product development are kept minimal during prototype. Efficiency concerns also take the rear seat, and often high level interpretive languages are used for prototyping. For these reasons, the temptation to change the prototype into the final system should be given. Experience is achieved by putting the system to use by the actual customer and the users. To understand their responses, it is necessary to have continued contact with clients / users during this activity.
For prototypes of requirements for possible analysis, its cost should be kept low. As a result, only those features will be a valuable return from the user experience which are included in the prototype. Exception handling, retrieval, conformance with some standards and formats are usually not included in the prototype. Because prototype is to be thrown, only the minimum development documents should be produced during the prototype.
Also read
OBJECT ORIENTED MODELING
The cost of developing and running a prototype can be approximately 10% of the total development cost. However, it should be noted that if the cost of prototype is 10% of the total development cost, it does not mean that this amount has increased the cost of development. The main reason is that due to the use of prototype in the context of low requirement errors, there is a possibility of substantial reduction in the cost of development and the reduced amount of requests for change required.
from Technology development http://bit.ly/2VoseVG
Comments
Post a Comment