Política de versionado ejemplos y tips

¿Qué es una política? Introducción

Antes que nada, cuando hablamos de políticas o de una política, estamos queriendo significar un conjunto de reglas que gobierna el objeto al que se hace referencia. Así podemos hablar de políticas de nombres, de versionado, políticas organizacionales, etc. En definitiva son reglas de negocio, pero restringido a un ámbito o temática. Otra vez, al hablar de política de versionado estamos hablando de reglas de negocio de versionado.

Las políticas ayudan y guían tus acciones y decisiones dentro de la organización respecto de la temática que tratan.

La política de empresa es un conjunto de normas o reglas establecidas por la dirección de la misma para regular diferentes apartados del funcionamiento de la empresa. 

En algunos ámbitos la política se define como el criterio o directriz de acción elegida como guía en el proceso de toma de decisiones al poner en práctica o ejecutar las estrategias, programas y proyectos específicos del nivel institucional. Siendo así la política empresarial define previamente como quiere hacer las cosas la organización, en otras palabras se diría coloquialmente: "En esta empresa se hacen las cosas de esta manera", y no importa si la empresa es del mismo rubro, del mismo sector o subsector de mercado, sus políticas pueden ser diversas. 

Politicas de versionado

La política de versionado de un producto determinado (o todos en general) deberá estar formada por un conjunto de reglas que provean a la versión del producto de cierta consistencia e integridad, no dejando fisuras en las que permeen problemas asociados con el versionado.

Podemos hablar a diferentes niveles, así por ejemplo podemos hacer referencia a políticas que afectan de las versiones de productos de software, productos de trabajo, de archivos, etc.

Veamos un ejemplo

Especificaciones de formato de versión 1.0 para el versionado de productos de software de nuestra organización.

V<nro_producto>.<nro-funcional>.<nro-correccion>.<nro-recompilacion>

...

Políticas de versionado dentro de nuestra organización.

1. Cada producto de software utiliza como estructura de versión, la especificación de versión 1.0 para el versionado de productos de software, a partir de 01 de marzo del 2014.
2. Cada nuevo producto se inicia con un número secuencial creciente que comienza con el 1, la primera vez. La asignación es realizada por el Área de ventas. 
3. Cada vez que se crea un producto, todas los secciones de la especificación de versión serán 0, excepto el correspondiente al número del producto. El número de producto se incrementa en uno respecto del último número usado.
4. Cada vez que un producto atiende una solicitud de cambio que agrega, modifica o quita funcionalidad se incrementa en un dígito la sección correspondiente a funcionalidad. A partir de esta sección el resto de las secciones que le continúan se inicializan en 0.
5. Cada vez que se corrige un error, la sección correspondiente a corrección se incrementa en un dígito. El resto de las secciones que le continúan se inicializan en 0.
6. Cada vez que el código se compila, este incrementa en 1 dígito la compilación. Si es la primera compilación. Se pone 0.
7. Independientemente de la cantidad o el tamaño de la funcionalidad siempre se incrementa en 1.
8. De cada versión de producto entregada se guarda una linea base.
9. Se debe especificar para cada versión cual es el corrección y se debe especificar que funcionalidad se agrega, cambia o quita. No se específica porque se compila en forma obligatoria.
10. Gerencia es el sector de la organización que determina la discontinuidad de un producto y su correspondiente congelamiento de versión. A partir de esta decisión el producto de software no evolucionará y tampoco se comercializará.

Tips para la definición de reglas de una política de versionado

1. Cada regla debe ser independiente. Cada regla debe entenderse por si misma.
2. Cada regla tiene un identificador.
3. Preste atención a no poner politicas por que si.
4. Tenga en cuenta de explicitar los valores de las secciones cuyos valores dependen de otras secciones. Ejemplo regla 5
5. Realice “mentalmente” un ciclo de vida de cada sección o grupo de secciones, es decir, evalúe cuando nace, como evoluciona y si puede caducar, agotarse  o volverse obsoleta una sección.
6. Se pragmático y no consuma horas de discusión en cosas que no ocurrirán en el largo plazo, sus políticas se ajustaron en el mediano plazo por otros elementos no tenidos en cuenta. 
7. Las políticas se versionan.
8. Las políticas se auditan.
9. No sea purista, es probable que las políticas contengan elementos que no sean reglas de negocio estrictas, si aportan valor y no generan confusión déjelos

Eliminación de datos en cascada

Cuando se realiza el análisis de un sistema de información es importante analizar la vida útil de los objetos que han fallecido o que fallecerán. Este análisis suele ser importante pues, los datos fallecidos no vuelven a ser utilizados por el sistema de información a excepción de ciertas circunstancias muy particulares, tales como: una auditoría externa, una situación legal ocurrida por un reclamo, etc.
Sabemos que los objetos forman parte de la memoria de un sistema para siempre, serán eternos. Es decisión de su creador (aunque no arbitraria) por cuanto tiempo han de quedarse eternizados estos objetos en la memoria del sistema.

¿Por cuánto tiempo mantendremos al objeto hasta que nos empiece a molestar? 
La respuesta resulta simple, cuando el objeto comience a molestar en el sistema habrá llegado el momento de eliminarlo; ten por seguro que ese momento llegará.
La molestia comienza a presentarse cuando los tiempos de respuesta del sistema implementado decae, o simplemente se presenta información que ya no tiene sentido para el usuario. No creo que sean las únicas razones, pero seguro que están presente en los sistemas implementados en software.
Imagínate que todavía pudieras vender en tu sistema de ventas disquetes de 5 ¼, o cualquier producto que no se produce más, como un cassette; o ves a ese cliente que hace años que no te compra, o esa factura que jamás fue pagada, o simplemente esa persona que trabajaba con vos, pero ya no lo hace, y aún podés asignarle trabajo desde el sistema en funcionamiento. El dato / la información no corresponde que estén presente pues, ya produce efectos que no son buenos. Suelen poner de mal humor al usuario, o incluso producir errores no pensados.
Obviamente que los datos suelen ser borrados por razones más poderosas que las mencionadas, tienen que ver con la performance. Cuando las aplicaciones que implementan los sistemas se ponen lentas, el destino es borrar los datos que no tienen utilidad. Imagínate que se producen en tu ciudad, desde tu empresa, para tus 200.000 clientes, 200.000 facturas mensuales. Luego en 10 meses tenés 1 millón, luego en 5 años tendrás 6.000.000, pero si te fue bien tendrás más. Ahora imagínate las empresas que facturan servicios y, que en muchos casos son monopolio. Imagínate un municipio generando impuestos, o en un banco el nivel de transacciones diarias de sus clientes.

Las otras razones poderosas por la que los datos se mantienen por un tiempo y, hasta que no son necesarios, está dado por restricciones legales o porque son necesarios estadísticamente, o bien, su historia produce un beneficio social a largo plazo; luego solo pensaremos en destruirlos (Los datos que se mantiene para obtener estadísticas dentro del contexto social tienen una riqueza importante para comprender las sociedades en la que vivimos o vivíamos)

¿Qué debemos tener en cuenta para eliminar datos?
Sabemos que los datos no están solos en la memoria del sistema, sino que están dentro de una red de conexiones invisibles, por lo que, al momento de destruir, el analista debe analizar no solo que se borren los datos deseados, sino que también se borren los datos y las conexiones que los sostienen, los hacen estables o permiten que otros sean estables o comprendidos. Si vas a eliminar datos no podés dejar huecos en la memoria, no podes producir islas que constituyan puertas a errores que antes no existían, simplemente no te lo podés permitir.

Ejemplo: si quiero borrar un cliente que ha realizado compras y las compras tiene diferentes pagos, entonces borrar el cliente implica borrar sus compras y los pagos de estas. Si no lo hago dejo huecos de memoria irrecuperables, compras realizadas por humanos que se desconoce quienes son….un horror.
Entonces sin más preámbulos, borrar un objeto de la memoria, implica tomar todas los datos y las conexiones cuya vida depende del objeto y borrarlas también. Es lo que comúnmente llamamos una eliminación en cascada, pero ojo que si el dato conectado te sirve entonces quizás no corresponda borrar nada.
Definir estados anulados, cancelado o fuera de línea puede ayudar a quitar el dato obsoleto sin quitarlo realmente. Manejar bajar lógicas es otra historia del análisis que suele sacar de línea objetos obsoletos. Si tu problema no es de performance puede ser una solución buena, pero solo buena; cada nuevo requerimiento deberá ser analizado a luz de no contabilizar datos obsoletos, esto aumenta la complejidad.