Prototyping versus SDLC

Prototyping is defined as designing and building a scaled down, but functional version of the desired system. Prototyping produces an early, rapidly constructed working version of the proposed information system known as a prototype. Dixit (2007) says that a prototype can be built with any computer language or development tool, but special prototyping tools have been developed to simplify the process. Rainer & Cegielski (2010) noted that prototyping approach defines an initial list of user requirements, builds a model of the system and then improves the system in several iterations based on user’s feedback. In contrast, SDLC is a system development approach which follows step-by-step procedures. The steps include feasibility study, analyzing, designing, coding, conducting system tests, execution, assessing, reviewing and maintaining the system. 

There are two different prototyping methods which include system and design prototyping (Shelly & Rosenblatt, 2011). System prototyping produces a full-featured working model of the information system. Design prototyping is used to verify user requirements after which the prototype is discarded and implementation continues (Shelly & Rosenblatt, 2011). In this case the prototyping objectives are more limited, but no less important. The end product of design prototyping is a user-approved model that documents and benchmarks the features of the finished system (Shelly & Rosenblatt, 2011). Most prototyping is done using CASE tools, application generators, report generators, screen generators and fourth generation languages (Shelly & Rosenblatt, 2011).

Why Prototyping is Beneficial over the Traditional SDLC

In prototyping, developers do not try to obtain a complete set of user requirements for the software at the start and they do not plan to develop the system all at once. Rainer & Cegielski (2010) say that analyst and designers instead quickly develop a smaller version of the system known as prototype. Users make suggestions for improving the prototype, based on their experiences with it. The programmers then assess and review the prototype with the users and use their suggestions to refine the prototype. In SDLC programs are first developed according to the stipulated time until they are installed and put into use. Stair & Reynolds (2011) argue that in SDLC the system should be put under maintenance for as long as it is used. This implies that in case the application requires changes out of its maintenance reach, it is subject for replacement.     

While in SDLC, the user does not use the solution until the system is nearly complete: in prototyping, throughout each modification, specifications and optional system, where the issues are highlighted and examined, fresh systems are developed and a segment of the application is put into operation. Stair & Reynolds (2011) say that those who use the system are required to put it into practice and offer criticism or pinpoint areas that need correction. According to Stair & Reynolds (2011), this model of system development begins with developing a prelude model of a main application or a prototype edition of the full application. The subsystem may be developed in order to demonstrate models of reports and forms used to capture data. When the users confirm the prototypes of the forms, user interface and reports; they are then put into use as the actual systems. The programmers can then develop the real system using development tools and languages such as VB.Net. The refinements are carried out until the entire system is fully functional according to user requirements (Stair & Reynolds, 2011).

In prototyping, the analyst works with users in order to determine the initial or basic requirements for the system, while in SDLC, Dixit (2007) asserts that the spotlight on goals timeline. This means that SDLC focus more on the analysis and design part of the system instead of fully conceptualizing user requirements. The probability of failing to capture user’s needs is higher; hence, calling for continued maintenance. Dixit (2007) noted that errors established early during the development cycle can be twice as costly as establishing and fixing the errors during the analysis and design of the system. On the other hand, in prototyping a subsystem of the final system may be developed early on in investigation to help the analysts recognize what users want. The ultimate system is built as per the user’s specifications of the prototype.

In SDLC, the outcome of emphasizing on deadlines rather than on good practice is unnecessary rework and maintenance effort, both of which are expensive. Dixit (2007) argues that maintenance costs amount for 40% to 70% of system development costs. In prototyping, if a working model is built, the developer attempts to use existing program fragments or applies tools that enable working programs to be generated quickly (Dixit, 2007). When bugs are established in the final stages of SDLC, the preceding stages must be revised to a large scope. Also, the bugs established after software is set up may entail that users are trained once again when a solution has been established (Stair & Reynolds, 2011).

In SDLC, users cannot easily review intermediate products and evaluate: whether a particular product such as data flow diagram meets their business needs. In addition, documentation in SDLC is expensive and time consuming to create.  The use of prototyping leads to improved operational feasibility of systems during implementation and a boost in the confidence of users and developers because they have been working with a visible, yet simple system, rather than some ideas on paper. Shelly & Rosenblatt (2011) say that as the system emerges, users become more positive about the process and the results.     

Reasons for Using Prototyping

Agarwal, Tayal & Gupta (2009) noted that there are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the users. This is valuable in gaining a better understanding of the user’s needs. The prototype model is very useful in developing the graphical user interface (GUI) part of the system. Prototyping model can be used when the technical solutions are unclear to the development team. Agarwal, Tayal & Gupta (2009) articulated that major design decisions depend on issues such as the response time of a hardware controller or the efficiency of a sorting algorithm. In such circumstances, a prototype may be the best or the only way to resolve the technical issues. The third reason for developing a prototype is that it is impossible to get it right for the first time and one must plan to throw away the first product in order to develop a good one later as advocated (Agarwal, Tayal & Gupta, 2009).

Drawbacks of Prototyping

In prototyping, iterations build on the previous one. The final solution might be only incrementally better than the initial solution. Shelly & Rosenblatt (2011) say that the rapid pace of development can create quality problems, which are not discovered until the finished system is operational. The second drawback is that other system requirements such as reliability and maintainability cannot be tested adequately using a prototype; thus, resulting to systems that does not capture all requirements. The third drawback of prototyping is that in a very complex system, the prototype becomes unwieldy and difficult to manage (Shelly & Rosenblatt, 2011). System analysts should note that the final version of the system typically demand higher-level performance than the prototype can provide.

The prototype might lack security requirements, exception and error handling procedures and other required functions. The fourth major drawback of prototyping is that when software is developed quickly with a nonexistent software process, the result is often code that is poorly designed, poorly documented and difficult to maintain (Shelly & Rosenblatt, 2011). The pressures of rapid development can result to significant amount of time wasted on re-implementing modules, when previous could have been reused assuming they had been well-developed, designed and documented in the first place. 

Where Prototyping is not a Good Fit

Prototyping is not a good fit in development environments where there are multiple sources of expertise, multiple users, or a large problem domain. Mora, Forgionne & Gupta (2003) argued that where there are multiple sources of expertise, different heuristics may emerge to achieve similar goals and the knowledge engineer must cause those to converge for the purpose of system development. The uses of prototyping where there are multiple users with different characteristics and needs, tailoring the system to individuals needs are problematic. System developers may lack time, budget or ability to contact all potential users (Mora, Forgionne & Gupta, 2003). The interactive nature of prototyping demands that the size of the project team be kept as small as possible. As a result it is only appropriate as better suited for modular applications.  

Where the problem domain is huge, prototyping can lead to an ill-structured and most likely inaccurate knowledge base. Where procedural cuing is used implies the need for a known desired structure, which necessitates specification, at least in outline, in advance of coding (Mora, Forgionne & Gupta, 2003). Under these conditions, prototyping as a methodology may be inappropriate and the structured method should be employed. Prototyping is, therefore, a treacherous way of developing systems, if the business knowledge of the users in not utilized to the full extent (Mora, Forgionne & Gupta, 2003). Development may just degenerate into coding before the programmers and designers know what they are supposed to do.

In conclusion, the use of prototyping clarifies the business needs, but can muddy the technical vision of the development team if the prototyping activities are not controlled within the required framework. Developers should record all changes to the requirements as soon as possible after they have been identified. Prototyping should be introduced in such a way that it provides a non-threatening, supportive environment, encouraging learning and growth of employees with low status and self-esteem. System analyst and designers should be cautious that prototyping should not eliminate or replace activities; rather it should improve the quality of these activities.