This is basically an adhoc approach of maintaining software. It is a fire fighting approach, waiting for the problem to occur and then trying to fix it as quickly as possible.



In this model, fixes would be done without detailed analysis of the long-term effects, for example, ripple effects through the software or effects on the code structure. There would be little, if any documentation. This model can be used if a system, is developed and maintained by a single person, he or she can come to learn the system well enough to be able to manage without detailed documentation, to be able to make instinctive judgments about how and how not to implement change. The job gets done quickly and cheaply. This is normally used due to pressure of deadlines and resources.

If customers are demanding the correction of an error they may  not be willing to wait for the organization to go through detailed and time-consuming stage of risk analysis. The organization may run a higher risk in keeping its customers waiting than it runs in going for the quickest fix. but what of the long-term problems?

If an organization relies on quick-fix along, it will run into difficult and very expensive problems, thus losing any advantage it gained from using the quick-fix model in the fist place.

We should distinguish the sort-term and long term upgrades. If a user finds a bug in a commercial word processor, for example, it would be unrealistic to expect a whole new upgrade immediately. Often, a company will release a quick fix as a temporary measure. The real solution will be implemented, along with other corrections and enhancements, as a major upgrade at a later date.

For more help in Quick-fix Software Model click the button below to submit your homework assignment