archivo

Archivo de la etiqueta: mantenimiento de sistemas de información

Entregar por entregar una versión de un producto es algo que desgraciadamente estamos muy habituados a ver.

La entrega de software de baja calidad tiene consecuencias negativas, muchas más que si no hubieras entregado el producto a tiempo (por regla general):

– Cuando se entrega un software y se rechaza no solo estás perdiendo tiempo y dinero tú, sino también el cliente.

– Cuando se entrega un software con un elevado número de errores se incrementa la probabilidad de que alguno de ellos y de importancia llegue a producción, lo que puede provocar la liberación de un nuevo parche o de una serie de parches. Con eso también pierde dinero el cliente (mucho más ya que ha podido dejar bloqueado total o parcialmente un proceso, lo que ha provocado que una serie de trabajadores estén por debajo de su rendimiento habitual) y también lo perderás tú.

– Cuando se entrega un software con una deuda técnica alta estás condicionando su evolución, aquí también pierde dinero el cliente por el coste extra que tendrán las tareas de mantenimiento y por los posibles efectos colaterales que provoquen las nuevas versiones (si el software se encuentra muy acoplado y el testing no es suficiente) y también lo perderás tú, sobre todo si trabajas en proyectos a coste fijo.

Entregar software a la ligera por el simple hecho de cumplir una fecha o por pensar que no pasa nada, que ya se corregirán los defectos hace mucho daño, no solo al proyecto, ya que cuando se generalizan esas prácticas también se hace mucho daño a la profesión. Si queremos mejorar nuestras condiciones y la percepción que terceros tienen de nosotros necesitamos que no se nos vea como chapuceros.

De igual manera que resulta complicado realmente distinguir el desarrollo y el mantenimiento de software (en general y sobre todo en enfoques iterativos e incrementales), resulta complicado establecer una barrera entre lo que son requisitos y modificaciones, una vez que se ha definido un alcance inicial del sistema o se ha realizado una iteración.

Se podría considerar requisito si supone algo nuevo, aunque no deja de ser una modificación de una idea de base.

¿Tiene importancia establecer (o no) una diferencia entre uno y otro? Es cuestión de enfoque.

Yo sigo utilizando la palabra requisitos, ya que son tantos años usándola que me resulta complicado no hacerlo, sin embargo mi visión general de los mismos no es clásica o al menos no lo es, como decía antes, desde que se determina un alcance inicial del sistema, en mi opinión su tratamiento debería ser como modificaciones y las mismas no requieren de la formalidad de una ingeniería de requisitos: ¿hay que realizar una modificación? Hagamos lo necesario para llevarla a cabo.

Una cosa es que opine así y otra diferente que siempre pueda trabajar así, el contexto condiciona, las reglas de desarrollo de la organización también.

Hay muchos desarrolladores que aplican TDD en sus desarrollos o, al menos, desarrollan pruebas unitarias para el software que están implementando.

Sobre ambos aspectos TDD (las pruebas unitarias se construyen antes) o las pruebas unitarias en general hay defensores y detractores y como suele suceder en tantos aspectos, no hay una verdad absoluta, sino que la aplicación o no de estas estrategias dependen del contexto en que se realiza el desarrollo, del tipo de sistema y del equipo de programadores.

Pese a que hablo de contexto incluso en situaciones favorables existen reticencias por muchos desarrolladores que lo consideran una pérdida de tiempo o una carga que llevar encima desde que se implementan, sin embargo quienes lo utilizan y lo consideran como una actividad más dentro de la programación lo suelen aplicar prácticamente en cualquier contexto.

No voy a defender a unos o a otros, cada cual tiene su criterio. Desde mi punto de vista la posibilidad de realizar testing unitario y su automatización supuso en su día una revolución en el desarrollo de software y en el mantenimiento de sistemas porque todo lo que sea establecer controles que permitan construir sistemas más robustos y entregar productos con menos errores debería ser bienvenido

Martin Fowler como buen defensor de estas prácticas realizó la siguiente reflexión sobre los frameworks de pruebas unitarias: “Nunca en el campo de desarrollo de software tantos le debieron tanto a tan pocas líneas de código”.

Mantener software es complejo: es más difícil leer código que escribirlo, por regla general la situación de partida tendrá una elevada deuda técnica, te tienes que buscar la vida para entender el funcionamiento del sistema y para comprender determinadas decisiones de diseño, estás sometido a restricciones tecnológicas y presupuestarias, trabajas con gente que estará impaciente (por decirlo suavemente) porque tiene problemas, como consecuencia tendrás presión tanto del cliente como de tu propia organización…

Este tipo de situaciones curte, la experiencia y bagaje que se gana es superior a la media de los desarrollos que se realizan desde cero, por eso considero que la participación en el mantenimiento de sistemas de información es una fase por la que debemos pasar todos los que nos dedicamos a esta profesión porque se ve todo desde otra perspectiva.

Es cierto también que hay mantenimientos donde el ritmo es distinto, generalmente se trata de proyectos de larga duración sobre un único sistema o sobre una constelación de sistemas orientados a un mismo fin, bien dotados presupuestariamente, que no suelen tener problemas de gran calado (lo que se hace es contratar básicamente su continuidad) y, en consecuencia sin tanta presión. Como es lógico, este tipo de trabajos (generalizando) curte menos aparte de por el contexto, por el hecho de que generalmente se tiende a tirar por el camino más corto: parchear.

Volviendo a una visión más general de los mantenimientos, queramos o no, como decía en otro artículo, tendremos que pasar por esto teniendo en cuenta el contexto económico actual y también el sentido común ya que el ciclo de vida de los sistemas no puede ser tan efímero como viene sucediendo como consecuencia de malas ejecuciones de los trabajos, independientemente de que la causa sea provocada por el desarrollador, por los usuarios o por ambos, y/o por no pensar las cosas dos veces antes de encargar el desarrollo de un sistema (¿existen problemas organizativos que haya que solucionar antes de empezar un desarrollo?, ¿existe una estabilidad o visos de estabilidad en el proceso o procesos que vamos a informatizar?).

Por tanto eludir proyectos de mantenimiento se convertirá en algo cada vez más complicado y si se evitan habrá que analizar si el que lo hace está cambiando un beneficio a corto plazo por otro más a largo plazo y persistente (una experiencia que le hará mejor profesional).

El único aspecto en que las horas son un valor absoluto es cuando se multiplican por el coste por hora que tiene un determinado perfil, en lo demás no es para nada un valor absoluto, ya que el número de horas sólo indica tiempo dedicado al trabajo (que no necesariamente a trabajar) y no tiene en cuenta para nada la productividad.

No todos los técnicos tienen el mismo talento, no todos los técnicos tienen la misma profesionalidad, no todos los técnicos tienen el mismo nivel de concentración, por ese motivo las horas no son referencia de nada a la hora de medir trabajos realizados, salvo que se conozca muy bien a la persona o personas que van a realizar un determinado trabajo (en cuyo caso, las horas sí que pueden suponer una referencia). Esa es la razón por la cual no creo para nada en las bolsas de horas, aunque no tenga más remedio en ocasiones que utilizarlas. Lo mejor es trabajar por objetivos y a precio semicerrado (digo lo de semi, porque lo mismo hay contratiempos o cambios no esperados que implican una modificación pactada del coste), con una valoración económica lo más objetiva posible (evitando en lo posible el dedo al aire).