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.

Matriz de Dependencia de requerimientos

Introducción

Cuando realizamos proyectos en donde los requerimientos no están estabilizados, se produce mantenimiento o evolucionan por alguna otra razón, es más que conveniente establecer las relaciones de dependencias entre los mismos.
No suele ser muy visto en la práctica profesional, pero es una técnica importante para establecer y medir los impactos rápidos de los requerimientos ante la presencia de un cambio.

La matriz

La matriz de dependencias de requerimientos suele ser utilizada para varios fines. Un fin inmediato es poder observar el impacto que se tiene en los requerimientos, ante el cambio de un requerimiento.
La matriz de dependencias puede ser util para determinar los grupos de requerimientos altamente relacionados para que sean trabajados en distintos equipos en cualquiera de las disciplinas de un desarrollo clásico: análisis, diseño, programación y prueba.
Matriz de dependencias de ejemplo

Expliquemos las dependencias

El requerimiento 4 es un requerimiento de información, por lo que este muestre debe ser ingresado (y posiblemente modificarse). Esto es natural, la información no aparece de la nada, necesita de un alta; pero si se desconoce que se requiere consultar; lo que se presuma en el alta estará incompleto hasta llegar al requerimiento 4, entonces será necesario ajustar el alta posteriormente. No conviene comenzar por los requerimientos que no son de información. 
El requerimiento 3 refiere  a una modificación; existen muchos datos (quizás todos) que puedan ser modificados; pero para crear una modificación se debe primero saber que es posible modificar y cuales datos de los ingresados; consecuencia es conveniente conocer el alta (o altas) para aplicar la modificación.
No todas las dependencias son tan lineales, existen complejidades adicionales, pero uno puede suponer con escaso margen de error que si se requieren nuevos datos del requerimiento 4, posiblemente habrá impacto en el requerimiento 1 y con otra probabilidad en el requerimiento 3 que es un requerimiento que depende del requerimiento 1.

Los profesionales de sistemas sabemos que rapidamente aparecen nuevos requerimientos y hablar de un sistema con 50 requeirmientos no es ni lejano, ni loco. Si esta situación se presenta se deben agrupar los requerimientos. ejemplo en casos de uso.

Otras utilidades

El orden de dependencia sirve para que el analista pueda establecer una estrateria de trabajo si lo necesitara.

La Documentación

Luego de muchos años de profesión como analista de sistemas , ya no me caben dudas sobre algunas cosas:

1. la documentación es sumamente importante para soportar y mantener el trabajo de un proyecto o producto
2. documentar absolutamente todo es demasiado y poco probable. En algunos casos inútil.

El reto de cualquier profesional de sistemas es el de encontrar el equilibrio sobre qué documentar, con qué grado de talle y cuándo hacerlo.

La documentación es cultural, si el profesional no documenta su obra, en mi criterio esa persona no es un profesional, es un artista hasta el primer mantenimiento y luego sin lugar a dudas un malabarista con todas las letras.

Es muy importante dejar rastro de la obra, sino la obra termina no existiendo.

Las documentación sirve para facilitar el mantenimiento y reducir las sensaciones, los conflictos y las malas interpretaciones.

Nadie lee todo y nadie sabe todo, pero existe un responsable del producto que debe tener ciertos elementos para hacer evolucionar  al producto de software desarrollado e implementado , en nuestra cultura es el analista-diseñador del sistemas.

El programador para bien o para mal tendrá siempre una visión parcial del producto total, excepto que el programador sea analista en el mismo proyecto, pero es algo que va perdiendo fuerza y sostenibilidad con los softwares cada vez más complejos.

La primera premisa básica en cualquier intervención sistémica es que debe existir un mínimo de documentación y no es el código ese mínimo, excepto que sea un prototipo, aún así lo pongo en dudas.

La documentación permite comunicar ideas, conceptos y decisiones. Alguna documentación resulta crítica para el proyecto / producto y otra resulta complementaria.

Como sea, y en cualquier metodología con la que desarrollemos nuestro  trabajo profesional, este debe quedar documentado.

Se documenta para los cambios, para la evolución del producto y para tener un punto de partida para el crecimiento del software, del sistema o de la aplicación (o como te guste llamarlo).

Se documenta para conocer el impacto.

No te olvides que los requerimientos, cambian, las reglas cambian, el cliente cambia y los trabajadores de tu organización cambian, incluso cambian los equipos, entonces tenemos buenas razones para documentar, pero no perdamos de vista que debemos documentar lo que merece la pena ser documentado. Por esto, la documentación irá evolucionando en la medida que se necesite.

Los requerimientos funcionales son necesariamente documentables; en definitiva ellos dicen que debe hacer el software.

Las reglas de negocio refieren a las normas y pautas sobre la que el software está limitado a funcionar dentro del marco de, por ejemplo, una organización.

Luego puede aparecer un set de modelos interesantes que serán más relevantes en ciertos proyectos que otros. En mi opinión es visión del profesional expandir la documentación, o bien, retraerla en la medida que así lo vea necesario.

Es importante pensar en un mínimo y en la calidad. Generar documentación que nadie entiende o nadie le resulta de utilidad es una pérdida de dinero.

El secreto de las herramientas. Un secreto gritado a voces.

Todos sabemos que las herramientas ayudan a los profesionales de todos las áreas en su trabajo.

Algunas herramientas son más completas, otras más eficaces, algunas facilitan el trabajo, otras permiten hacer el trabajo más rápido. Como sea, sin herramientas muchos trabajos no se podrían realizar.

Clavar un clavo sin un martillo o ajustar los tornillo de una rueda sin al menos un llave CRUZ, serían tareas demasiado complejas, difíciles o imposibles de ejecutar, incluso para profesionales avezados.

La herramienta sola no es nada, dependemos de la habilidad de quien la usa, la herramienta debe estar en manos de un trabajador (worker); él es quien cambia el destino de una batalla.

Tener la herramienta sin el worker sólo te hace poderoso en una mesa, durante una charla, pero no en el campo de batalla.

En el área de conocimiento de software las personas y las herramientas son elementos importantes de la calidad, diría que la interacción producida entre la persona y la herramienta es mucho más importantes que los elementos por separado. La persona tiene el conocimiento y el herramienta el don de facilitarlo. El conjunto es un simbiosis fundamental.

No es concebible desarrollar software sin ambos elementos, mucho menos con calidad; pero recuerda el verdadero secreto no es la herramienta sino la persona que la usa.

De este modo comprenderás que si pones tu éxito sólo en las herramientas te estarás equivocando y si solo lo ponés en las personas será insuficiente deberás realizar una mezcla útil.

Tampoco puedes esperar que la relación se base en tomar un individuo  y darle una herramienta. El individuo debe conocer y saber hacer con la herramienta.

El éxito de la relación lo consigues cuando el profesional sabe usar la herramienta y tiene arraigado los conceptos que le permiten volverla más eficaz.

De nada sirve que se tenga una herramienta para modelar diagramas de actividad, si el profesional no conoce sobre  diagramas de actividad. Puede que haga un dibujo con componentes de diagrama de actividad, pero ¿estará haciendo un diagrama de actividad?