Buenas. Sobre este tema pueden leer más en el sommerville, pág 260
Emergency system repairs have to be completed as quickly as possible. You choose a quick and workable solution rather than the best solution as far as system structure is concerned. This tends to accelerate the process of software ageing so that future changes become progressively more difficult and maintenance costs increase. Ideally, after emergency code repairs are made, the new code should be refactored and improved to avoid program degradation. Of course, the code of the repair may be reused if possible. However, an alternative, better solution to the problem may be discovered when more time is available for analysis.
Pueden leer el resto de la sección para entender cómo es un proceso para cambios no urgentes. Pero les puedo adelantar que, por ejemplo, se pueden obviar el análisis de impacto (o hacer una versión muy simplificada), también la actualización de los documentos de requisitos, manuales de usuario y otras. Se hace lo mínimo para dejar el sistema en funcionamiento de nuevo, que suele ser lo que está en la figura, tocar el código. Las actividades que se saltean se pueden realizar después, por ejemplo, al otro día, como comento en el video. Muchas veces se deja para después también actividades de diseño, se revisa por ejemplo la solución y se busca que cumpla principios de diseño o se busca otra solución mejor.
Saludos,
Seba