Does RAD allow you changes or modification after the cutover phase without the need to redo the system? [closed]

Question

Like other agile models, that is a close loop where changes after the system development can still be implemented without the need to redo the whole system, is this possible for the RAD model as well?

Since I was told that in the Waterfall model, if there are changes after the development, it can only be implemented by redoing the whole system since it is a one way approach unlike agile where you can just go back to the development stage again.

Example:

After the cutover phase of the system, when it is already released for a few months, then the client decided that "hey I want this and that to be implemented I think it would make the system better with it". Can this be done immediately following the process model of the RAD and just directly proceed to construction phase, or do we need to recreate the entire RAD process from the start or the requirements planning phase?

From what I understood of Waterfall method, if a change is needed during the maintenance period or way after the system has been completed, it is a requirement to redo the entire Waterfall process and start from the start, which is very different for agile models where you can just go to the development stage to apply the necessary changes.

Answer 1

In any methodology, you can response to changes or modifications. However, some methodologies are better at responding to changes and delivering those changes at less expense (of time and/or money) to customers and users.

It sounds like you have a fundamental misunderstanding of what the difference between agile (iterative and incremental) and waterfall (sequential) models are. Even if you are following a sequential model, you don't need to redo the whole system if there are changes after development. In a traditional waterfall model, you capture your requirements up front and fix them. Then, you design those requirements and implement a solution, then test the solution, and finally release a system. The idea is that this system meets all of the needs of the customer and users. But there's still maintenance after the fact, and even in a sequential environment, you can release patches and new versions of the software. If you continue to follow a sequential model, you'll bundle up a large number of requirements at the front, and proceed sequentially through each of the other steps, ending in a release.

The iterative and incremental models focus on delivering smaller pieces of the software. These pieces are delivered quickly to the user and are used to obtain feedback and perform course corrections - identify mistakes or misunderstandings in the requirements or design. You don't fix the whole set of requirements for the product at the start, but instead prioritize and either demonstrate or deliver the things that will add the most value earlier in the project. This type of approach takes the mindset that software can continually evolve and change, and a project isn't done until the customers and/or users are satisfied.

---

Specifically, in RAD, if you get a change after Cutover, you'll have to do some level of Requirements Planning. You can't just go and implement a change (in most projects, especially larger, corporate projects). You'll need to ensure that any changes make sense within the product/project scope and constraints and that the requirements are clear and consistent. You also want to ensure that changes made for one stakeholder don't have negative impacts on other stakeholders. Most of the change effort should be in the User Design and Construction, though, and then you proceed to Cutover.