References
Rapid Application Development
Beynon-Davies, P., Carne, C., Mackay, H., & Tudhope, D. (1999). Rapid Application Development (RAD): An Empirical Review.European Journal of Information Systems, 8(3), 211-223. Retrieved from
Waterfall Method
Liu, L., & Horowitz, E. (1989). A Formal Model for Software Project Management. IEEE Transactions on Software Engineering,15(10), 1280-1293.

An Old Waterfall
The waterfall model is one of the oldest software development processes often cited in project management. It has been over 40 years since it was first formally described by Winston W. Royce. The model was viewed in the same regard as real life waterfalls because of how the model was presented. The development process of the waterfall model is a linear sequential process just like a waterfall flowing from top to bottom. It is very interesting to me, that often at times the waterfall model can also show backward pointing arrows contrary to a true waterfall where once water flows down, it cannot flow back up. This tells me that the original waterfall model was not perfect nor is any other type of project management process.
In Royce’s original model he lists six phases in its model: requirements, preliminary designs, interface designs, final designs, testing and integration; before advancing to any following phase it must be verified. This verification can be considered milestones and is used as a tracking mechanism of the progress of the project. The waterfall model provides the map for developers to follow and use for explanation. Originally, Royce’s waterfall model was strictly shown as step by step sequential series of tasks in order to complete the project, but has changed over the time. Presently, waterfall models typically shown with backward arrows in order to return to previous phases allowing the waterfall model to be practical for usage.
The strength of the waterfall model is its simplicity; it is easily interpreted because of its sequential diagram and this is the reason why many product installation instructions are written in the same linear sequential form. Each step in the waterfall model demonstrates high focus in each phase before being able to move the project forward. The first phase must list all requirements of the project or the new system must be captured and documented in a software requirement document. Using the waterfall model project managers must gather all the detailed information for the project before signing off and proceeding to the next designing phases. After reaching the final phases of the project for testing and then implementation the end user returns and gives their feedback. The customer is now able to see their first prototype since they first met with developers in the initial requirements phase.
There are many criticisms of the waterfall model which also originate from the waterfall models strengths. As projects became more difficult the first phase requirements cannot possibly capture every detail of the project before starting. As projects became much larger the time it took complete the project went much longer than projected. Designers or programmers would have to wait until requirements were completely captured before working on their phase. Also, the customer, end user, would wait the longest time in order to see the project at the implementation phase. The negatives of the waterfall model became apparent when trying to apply the waterfall model to all projects. Therefore, revisions of the waterfall model came to fruition and the model was now allowed being expressed by the ability to flow back to previous phases of the model. Introducing the ability to backtrack in the process model adds more inefficiency to it. For example, when the project is completed and the customer requirements change. The project would return back to the drawing board and start over in the first phase and have to redevelop the product again through each of the steps.
A lot has changed after 40 years and the modern world has embraced technology along with its instantaneous gratification. The waterfall model is now very old and it was evident while search for a journal or publishing on the topic. The waterfall model does not address the needs of customers fast enough or precise enough in modern times. If a customer’s requirements changes in the middle of the waterfall model, there isn’t way to implement the changes quickly. A new methodology called Rapid Application Development was developed to address both these issues.
Rapid Application Development is another type of model that emphasizes on speed and quick development of products. The model is designed to promote a strong collaboration between the developer and the customers. RAD is a linear model that incorporates a small development team of both developers and customers on a highly focused problem solving project. The model has three phases: requirement planning, user design and construction, and lastly cutover. RAD can focus on solving the problem at hand by first identifying the projects need and scope quickly. There is very little documentation in this phase as it is merely the first step into the model. The second phase of RAD is what puts the rapid in RAD. It is the user design and construction phase. The goal of this phase is to create a working prototype as quickly as possible. When a prototype is created it is able to be tested by its customers. RAD allows customers and users to see the prototype quickly as possible in order to verify its deliverables. The main idea of RAD is the faster a project is to a prototype the faster the project can obtain feedback on it. Feedback is important for projects because it is the verification of the project itself. The user/development team can now demonstrate the prototype. The prototype is discussed and the user/development team agrees on changes or enhancements needed. In RAD, the first prototype created is not the last one. This phase is completed at least three times until it can reach the final stage of implementation. The repetition of the second phase is called incremental prototypes. The requirements for the prototype are that each prototype should build off one another, meaning, the components developed should be able to be reused and recycled. The components being able to be recycled allow the RAD model to maintain its efficiency and rapid development. It also, keeps the prototypes as revisions of the original prototype instead of creating an entirely new prototype each time. Users review the project to see any problems with the prototype. RAD allows the team to be able to change their problems immediately by recycling the prototype and redesigning from reused components of the product.
The final implementation phase of the RAD model is final product after completing each of the tasks in all the phases. The final product in RAD comes out quickly and is usable because the users have reviewed it multiple times and are completely satisfied with it. RAD requires very strong collaboration between the small group of users and developers. In order to have strong collaboration both the users and developers need strong social and business skills. The problem is solved rapidly and under the scope of the initial project.
Rapid Application Development and the waterfall method are both process models used in project management. Both of them are linear and sequential moving through each of their own phases. And both development models have the same end goal to produce results that solve the initial projects scope of requirement needs. They both involve developers and users in the design of the project. Lastly, both models share the difficulty of acquiring the projects requirement and needs.
Starting from the first phase, both models start by acquiring requirements for the project, but the waterfall model is an intense detailed documentation of the needs by trying to capture the entire projects requirement in the first phase. RAD also has difficulty too because it starts off with partial list in which after repeating its user/development phase several times it can continue to fill its partial list. Both models have the same problem in the same phase, but in different aspects.
While projects using the waterfall model are still continuing to gather initial requirements, projects using RAD model have already created a first prototype that is useful for its users. In RAD the customer is re-introduced in the model again for feedback on the first prototype. In the waterfall model the customer is heavily involved in the initial requirements phase, but not seen again until the final product is created. In RAD, the customer is in constant contact with the developers the projects changes. In RAD, their requirements list is recreated in small changes from each prototype to the next. Waterfall modeled projects focus all of their time on the requirements needs in order to advance to the next phase.
The waterfall model starts its design using the detailed requirements given to them by the customers. Both models have user requirements, but the waterfall model will begin their design with more clarity. The RAD model’s clarity isn’t feasible until several prototypes have been created as with each revision more specification is added to the requirements during the customer feedback phases. Both models are able to accept changes however; RAD is able to see problems earlier because of its concurrent process of collaboration with its users. In the waterfall model changes aren’t as easy because waterfall represents the inability to go backwards. By the time a waterfall model reaches its end users for feedback. The users could have entirely different requirements.
RAD is supposed to be faster and cheaper than the waterfall method. Because of the ability to integrate early changes introduced to the project’s scope. RAD is able maintain efficiency by reusing their components in each prototype. Each prototype is refined on each increment until satisfaction is complete. In the waterfall model the project takes a lot more time to complete and because the customer is left out of the loop for so long if a large change is required to the project the waterfall method would take even longer and cost a lot more funds to re do the project again with a new detailed project scope.
Both models incorporate focus in their projects, but in waterfall models focus is a step by step focus through each phase, but takes a much longer time to reach the end. In the RAD models focus is towards problem solving. RAD focuses on speed at solving the problem and speed on getting the problem graded by its users. RAD processes are concurrent where developing and designing are done together in its phase, and the waterfall model maintains its step by step process. Waterfall models keep everyone waiting developers need to wait for the project requirements and customers need to wait for the project results. In RAD no one is waiting as everyone is working together concurrently.
The waterfall model and the RAD model are just two of many models used in project management. Both have their own strengths and weaknesses and choosing the correct model to use in your project can benefit you. In my work I have used both models with success, but this is because the majority of my projects are very simple ones. My office sent an email blast out to employees of the corporation soliciting my computer services. My coworkers are my customers and initiation would be from an email requesting a creation of some kind of form or template. I would use the RAD model to manage my projects.
First, I would obtain requirements and start developing my first prototype immediately. The first prototype needs feedback so I can verify the work has captured foundation of the requirements. For example, the tool I made a worksheet that incorporated a mail macro. This macro would individualize existing worksheets into individual files and get attached to individual outlook emails. Specifically, the workbook had twenty worksheets for the twenty case managers with each worksheet containing a caseload. When the supervisor needed to send out everyone caseloads they would need to manually insert worksheets. The second prototype would incorporate custom email bodies.
The final prototype was making the tool visually aesthetic. After each prototype new requirements were introduced and developed into the next prototype. The final version of the Flag list template would allow the user to click a single button and each of the twenty worksheets gets attached to emails going to the case manager and their supervision. In addition secondary files could be attached my adding the file names and email bodies could be written. Lastly, the caseloads contained dates in which the customer wanted a simple conditional formatting to highlight when work was close to being overdue. I’ve done many of these types of projects and most of them last one a day to week. I helped solve my coworker’s current problem helping them work smarter and not harder. The turnaround time was quick and it was incorporated into their workflow seamlessly.
My corporation has a saying “it’s all about the process” it seems fitting because I feel that many of my coworkers including myself use the waterfall method in many of our projects. A current project I’m in is applying to an RFP, Request for Proposal. An RFP is a solicitation sent to my company and other providers where we can propose a service for its requirements. The requirements phase is the most important phase for us because we need to be to have as much clarity of the requirements to win the bid. The RFP document can sometimes leave information out and we ask additional questions after we read through the information. After gathering the information we move to the designing stage of the model. This is where we create a design team made of a Proposal Writer, Budget Manager, Corporate Assistant Director, Directors of existing programs providing the same services and any specialists we find beneficial.
The design team is considered all experts in their respective fields and together they create a sort of dream team in order to visualize and put the new program requested into paper. We use similar programs to model the new program from. We add or remove certain aspect in order to remain in compliance to any of the rules and regulations to the services and/or the RFP. The design and implementation happen together as the Proposal Writer creates the actual proposal and the Budget Manager creates the fiscal files such as: a balanced budget, staffing pattern and revenue schedule. When drafts are complete they are presented to the design team in the verification phase. This is the last time we can makes changes and the only time we can go back to the prior phases. Once the final drafts are created and verified it there are sent the original soliciting funder. In the final phase if we win the bids we can negotiate any type of terms for our program.