martes, julio 29, 2008

No hay que desmerecer a los proyectos de mantenimiento

Estoy leyendo un libro titulado "Facts and Fallacies of Software Engineering" de Robert Glass y encontré unos hechos o "facts" sobre el mantenimiento en la ingeniería de software que me parecieron interesantes y compartí con el equipo del proyecto en cual trabajo (Que se trata sobre mantenimiento de varias aplicaciones) y tambien quiero compartir aca.

En este libro el autor presenta hechos y falacias, luego discute, luego cuenta las controversias alrededor del mismo y finalmente cita las fuentes.

Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Corolario: Old hardware becomes obsolete; old software goes into production every night.

Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.
The 60/60 rule: 60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement. Enhancing old software is, therefore, a big deal.

Maintenance is a solution, not a problem.
Far too many people see software maintenance as a problem, something to be diminished and perhaps even "obliterated." In saying that, they are really expressing their ignorance. The only way that software maintenance could be a problem would be if nearly all of it were about fixing errors. And we have already seen that it's not. Far from it, in fact. Maintenance, instead, is software's unique solution to the problem "we built this thing, but now we wish we had built something a little different."

In examining the tasks of software development versus software maintenance, most of the tasks are the same-except for the additional maintenance task of "understanding the existing product." This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.
Maintenance life cycle:
  • Defining and understanding the change-15 percent
  • Reviewing the documentation for the product-5 percent
  • Tracing logic-25 percent
  • Implementing the change-20 percent
  • Testing and debugging-30 percent
  • Updating the documentation-5 percent
Better software engineering development leads to more maintenance, not less.
Systems built using "modern development methods" were more reliable than those built using older ways. They required repair less often. But those systems required more time tomaintain them. How could that be?

These systems took longer to maintain than the others because more modifications were being made to them. And more modifications were being made because it was easier to enhance these better-built systems. Most organizations have a long backlog of enhancements to be made to their software products (Software 1988). The better-built systems were simply making their way through those enhancement queues faster than their more poorly built brethren.

Referencias: Facts and fallacies of software engineering, Robert Glass, 2002

3 comentarios:

Pedro Molina dijo...

Martín. Necesito orientación en algo que quizas me puedas dar una mano. Necesito alguna especie de guideline o libro de buenas prácticas para generar documentación y mantenerla. Ya googlee bastante pero no encuentro nada satisfactorio.

kfaday dijo...

Udai,

Con las metodologías agiles, apareció Agile modeling, que es como un parche a las metodologías agiles que trae indicaciones de como modelar (mediante UML) y como documentar, algo que no está muy explicito en las metodologías agiles en sí.

La semana pasada escribí sobre TAGRI (they ain't gonna read it), que es un principio enunciado por la gente de agile modeling. Leete el post:

http://kfaday.blogspot.com/2008/07/no-lo-van-leer-tagri.html

Además, te recomiendo que leas acá para ver como documentan ágilmente la gente de agile modeling:

http://www.agilemodeling.com/essays/agileDocumentation.htm

Avisame si te resulta útil.

Éxitos!

Pedro Molina dijo...

Martin,

Me estoy enviando los link al trabajo, mañana los leo mas detenidamente. Y te aviso de cualquier avance.

Saludos y gracias.