What is a software development process model?

In contrast to software life cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities The Types of S.D.P.M includes: Waterfall model Spiral model Iterative model Prototyping model

Prototyping Approach
Software prototyping, is the development approach of activities during software development the creation of prototypes, i.e., incomplete versions of the software program being developed. Basic principles of the Prototyping Approach are: Not a standalone, complete development methodology approach, but rather an approach to handling selected portions of a larger, more traditional development methodology (i.e. Incremental, Spiral, or Rapid Application Development (RAD)) approaches. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. User is involved throughout the development process, which increases the likelihood of user acceptance of the final implementation. While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.

Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users requirements. A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.

Prototyping Software Life Cycle Model

The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throw away prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the System, since the interactions with prototype can enable the client to better understand the requirements of the desired system. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. In such situations letting the client "plan" with the prototype provides invaluable and Intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements. The process model of the prototyping approach is shown in the figure below.

Prototyping Model

The Prototyping Model was developed on the assumption that it is often difficult to know all of your requirements at the beginning of a project. Typically, users know many of the objectives that they wish to address with a system, but they do not know all the nuances of the data, nor do they know the details of the system features and capabilities. The Prototyping Model allows for these conditions, and offers a development approach that yields results without first requiring all information up-front . When using the Prototyping Model, the developer builds a simplified version of the proposed system and presents it to the customer for consideration as part of the development process. The customer in turn provides feedback to the developer, who goes back to refine the system requirements to incorporate the additional information. Often, the prototype code is thrown away and entirely new programs are developed once requirements are identified. Prototyping activities are usually completed during the requirements analysis and design phases. The prototyping activity has its own, usually informal, life cycle that is embedded within the early phases of the full system's life cycle. If any portion of the prototype is to become part of the final system, it must be validated through all the established checkpoints (design reviews, code reading, unit testing and certification, etc.). As a rule, such prototyping activities should require no more than 15 percent of the total development effort. For projects in which the end product is a prototype, however, an iterative life cycle may be preferable. This is particularly true when a new user interface is a significant component of the system. An initial version of the prototype is designed, implemented, and demonstrated to the customer, who adds or revises requirements accordingly. The prototype is then expanded with additional builds, and the cycle continues until completion criteria are met. Tailoring the life cycle for any type of prototyping requires careful planning. The more new technology that is to be used on a project, the greater the prototyping effort. The larger the prototyping effort, the more formalized must be its planning, development, and management. The results of even the smallest prototyping effort must always be documented. Lessons learned from the prototype are incorporated into plans for subsequent phases and are included in the project history. See Section 4 for additional guidance on planning and documenting prototyping activities. The basic reason for little common use of prototyping is the cost involved in this

Built-it-twice approach. However, some argue that prototyping need not be very costly and can actually reduce the overall development cost. The prototypes are Usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality. In addition, the cost of testing and writing detailed documents are reduced. These factors help to reduce the cost of developing the prototype. On the other hand, the experience of developing the prototype will very useful for developers when developing the final System. This experience helps to reduce the cost of development of the final system and results in a more reliable and better designed system.

Variation of the Prototyping Model A popular variation of the Prototyping Model is called Rapid Application Development (RAD). RAD introduces strict time limits on each development phase and relies heavily on rapid application tools which allow for quick development.

WHEN

TO PROTOTYPE????

As a rule of thumb, use prototyping whenever The project involves new technology, e.g., new hardware, development language, or system architecture The requirements are not understood. There are major, unresolved issues concerning performance, reliability, or feasibility. The user interface is critical to system success or is not clearly understood.

Advantages of Prototyping
Users are actively involved in the development. It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.

 Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed. Errors can be detected much earlier as the system is mode side by side. Quicker user feedback is available leading to better solutions.

Disadvantages
Leads to implementing and then repairing way of building systems. Practically, this methodology may increase the complexity of the system as scope of the system may expand.

References
Penedo, M.H. and E.D. Stuckle, PMDB--A Project Master Database for Software Engineering Environments, Proc. 8th. Intern. Conf. Soft. Engr., IEEE Computer Society, Los Alamitos, CA,ond original plans. My Documents\Downloads\Documents\Process-Models-SE-Encyc.pdf S Bell and A T Wood-Harper, Rapid Information Systems Development - a NonSpecialists Guide to Analysis and Design in an Imperfect World, McGraw-Hill, Maidenhead, UK, 1992.