Fundamentos de Tecnología de Negocios (I) - BPM & Proyectos DataWarehousing y Levantamiento de Informacion - BPM & Proyectos Software Gestor de proyectos: mudando datos de redmine desde y hacia... - BPM & Proyectos La documentación, adentrándose dentro del UP - BPM & Proyectos Adquisición de un servicio de consultora versus la propia implementacion del software - BPM & Proyectos

Fundamentos de Tecnología de Negocios (I)

Este es un documento en progreso, hay laminas con comentarios que describen su contenido. Sepa que esta en progreso de revisión y cambio.

Objetivo(s).

El documento ilustra y ayuda a intervenir sin desconocimiento en este mundo, introduciendolo en términos y tecnologías relacionadas, y como se apoyan entre si, aclarando las dudas y mitos acerca de esta famosa pero mal entendida forma de organizar el funcionamiento y optimizacion de la empresa.

Presentación de fundamentos de Tecnología de Negocios.

DataWarehousing y Levantamiento de Informacion

La etapa mas dificil de un nuevo proyecto es el levantamiento de informacion. Esto es mas dificil aun si es un proyecto que tiene que comunicar muchas o algunas tecnologias (y mas aun si son tecnologias heredadas como programas "hechos en casa" y/o tecnologias desactualizadas).

Esta etapa es extensa y la mayoría de las veces la gerencia no esta muy dada a contemplar el tiempo que implica ello.

El levantamiento de informacion es un proceso practicamente de "datawarehousing virtual". ¿Pero que quiere decir esto?

"DataWarehousing virtual" y DataWarehouse

(en construccion)

Software Gestor de proyectos: mudando datos de redmine desde y hacia...

El software para gestionar un proyecto es muy conocido por la gráfica "gantt" que es muy usada, y las expresiones de "recurso forzado" que significa que no hay tiempos de descanso ni de revisión.

Redmine no es el mejor de todos, pero es el mas simple de todos que integra todos los componentes (o la mayoría), si no esta a gusto chiliproyect es un redmine mas parecido a trac o github y mas adecuado.

Esta entrada se centra en documentar como mudar datos de un gestor existente de redmine a otro, que están en base de datos distintas.

Redmine 

El redmine no crea referencias entre talbas, pero si indices. La diferencia entre sqlite y mysql es que sqlite tiene unas tablas de enlace que no estan en mysql.

Sqlite3 to MySQL o viceversa

El redmine no crea referencias entre talbas, pero si indices. La diferencia entre sqlite y mysql es que sqlite tiene unas tablas de enlace que no estan en mysql.

  1. realizar un dump del archivo de sqlite en sql, para leer y respaldar los datos.
  2. Abrir el archivo de respaldo dumpeado y copiar solo las sentencias de instercion.
  3. Realizar un dump de la base de datos de mysql de la nueva instalacion de redmine, pero que incluya borrado de tablas si ya existen, y sin los datos.
  4. Crear una copia del dump del mysql pero sin las inserciones, es decir si hay alguna insercion borrarla (aunque arriba se especifico que no).
  5. Ingresar este dump sin inserciones en el nuevo redmine, para que de esta manera borre los datos viejos.
  6. Ingresar los dumps solo de inserciones de sql de la base de datos sqlite para poblar el redmine nuevo con los datos viejos.

Este proceso es innecesario si cambian en un mismo host, solo es necesario si estan dichas migraciones en hosts distintos. El paquete debian de redmine se encarga de ello incluso el redmine mismo (usando sentecias ruby) crea la base de datos dependiendo de lo existente.

Al terminar se deben ajustar algunos detalles:
  1. Los proyectos, usuarios y datos todos estan privados al realizar la migracion. Esto se soluciona con estos dos querys:
    $ mysql -p -u redmine redmine_default
    MariaDB [redmine]> use redmine
    MariaDB [redmine]> UPDATE projects SET is_public = 1 WHERE `is_public` = 0;
    MariaDB [redmine]> UPDATE users SET admin = 1 \
    WHERE admin = 0 \
    AND (type != 'Group' AND type != 'AnonymousUser') \
    AND login = 'admin';
    Estos querys recuperan el administrador (si no se cambio el login de admin) y adicional coloca todos los proyectos en publico, claro que se debera definir de nuevo si alguno es distinto. Es decir no es perfecta la migracion y puede que exista algún detalle.
  2. Los repositorios deben reenlazarse de nuevo borrando y creandolos neuvos.
No se nota ninguna relacion desde la base de datos por lo que se intuye que esto esta definido en los ficheros de cache y configuracion.

Esto puede que le sirva a chiliproyect tambien.

La documentación, adentrándose dentro del UP

Estando ya cristalizado la idea del proyecto, se debe empezar a formalizar y llevar a ejecución. Para tomar el control y asegurar la continuidad de la organización del proyecto respectos los cambios del mismo, se debe implementar en el un proceso de fabricado, UP (Proceso Unificado) es un estándar para ello, en las empresas hoy día se aplica sobre RUP, sin embargo la mayoría de las etapas son comunes, hay dos que son importantes: la documentación y la gestión de calidad.

La gestión de calidad comienza desde el primer momento que la documentación se empieza cristalizar, el equipo encargado de esto debe trabajar muy de cerca con el equipo de ingenieros que diseñan y construyen los artefactos de software así como la gerencia que define la funcionalidad de estos.

Involucrados en las etapas iniciales

En esto hay tres actores involucrados, los Gerentes, que junto con, los Ingenieros, definen las funcionalidades del proyecto y los artefactos de software resultantes, los ingenieros a partir de estos crean los preliminares técnicos. El equipo de Aseguramiento de Calidad o Calidad, trabaja paralelo, y en un principio en conjunto, es el que se asegura todo se paute según lo acordado, es el policía de turno entre las partes.

El resultado de todo el trabajo realizado entre estos tres primeros equipos de participantes son los Documentos Funcionales y los Documentos Técnicos, las dos piezas fundamentales que ayudaran a construir el producto resultante de la realización de dicho proyecto cualquiera.

Documento funcional

El documento funcional define la utilidad y valor agregado desde el punto de vista humano y gerencial, el cual dará por medio de la abstracción (imaginando el producto final insofacto), utilidad y funciones adicionales o nuevas a determinadas tareas existentes o no existentes necesarias para la empresa o un fin determinado.

Este documento se ve desde dos punto de vista (que en empresas grandes se discuten por separado), el gerencial, el cual enfoca el valor monetario y agregado a la empresa; y el humano, el cual por medio de un lenguaje entendible discute lo que el proyecto cristalizara para la empresa o fin convenido necesario.

Es el primer artefacto que se fabrica en un proyecto en general, y ayuda a definir los distintos niveles de documentos técnicos necesarios para el desarrollo de los artefactos de software.

Los documentos funcionales definen las ideas y las plasman ayudando a no desviar dicho proyecto de las metas pautadas. Un proyecto sin documento funcional, es como una petición de algo sin tener las ideas claras y plasmadas para poder decir que ya están definidas.

Documento técnico.

El documento técnico surge de los varios análisis por parte del equipo de ingenieros durante las etapas venideras después de realizados los documentos funcionales.

Los documentos técnicos definen a nivel de desarrollo, que se deberá realizar para llevar a cabo las ideas plasmadas en los documentos funcionales. Aunque esto no siempre es así, se dice esto en términos generales.

Estos documentos se fabrican en etapas posteriores y aquí intervienen dos actores participantes, el mismo equipo de Ingenieros lideres del proyecto, que previamente definieron los funcionales (en reuniones con los Gerentes); y los Recursos, que son equipos de desarrolladores, algunos lideres de sub equipos por cada parte de artefacto de software a fabricar.

Base de documentación y trabajo colaborativo, requisitos obligatorios

Ya para estas etapas iniciales se debe de tener un Artefacto para Gestionar el Proyecto, ya que debe haber una base de documentación accesible por las partes involucradas. Es obvio que los niveles de accesibilidad son distinto por razones implícitas de políticas propias por la empresa, un recurso no debe saber nada de los cambios a nivel gerencial, para eso esta dentro de el equipo de ingenieros su lider de proyecto, el cual interpretara lo necesario y le proporcionara tareas por medio del software de gestión.

Este Software Gestor de proyectos, permite organizar los roles participantes, así como trabajar de manera colaborativa, requisito necesario para terminar rápidamente estas primeras etapas que son las mas difíciles.

Definiciones, Formatos y estandares

Los documentos a generar, deben tener un formato, ademas deben estar versionados.

Las platillas son archivos esenciales que ayudan a esto, se emplean en los software de oficina, al abrir una plantilla predefinida esta tiene ya escrito una estructura.

Se deben definir plantillas ofimáticas para la realización de estos documentos. Esto ayuda a formalizar la documentación y agilizar el trabajo entre las partes. 

Ademas permite que los recursos de las etapas secundarias los cuales no se enfocan en el trabajo ofimática, ahorren tiempo solo rellenando las entradas de texto necesarias indicadas por estos formatos de plantillas.

Se provee aquí: DocumentoFuncional.ott un ejemplo de plantilla para un documento funcional desde cero, con algunas notas de ayuda. Al abrirla, y empezar a llenarla, deberá guardarla, aquí el software ofimática preguntara el nombre del archivo y se producirá el primer documento funcional-técnico por su parte.

Lineamientos y definiciones de trabajo en los archivos de documentos:

  • Deben tener todos en la cabecera un código que relacione el proyecto dentro de la empresa.
  • En el pie de pagina debe tener el nombre del departamento involucrado
  • En las paginas segunda o tercera debe haber un cuadro referenciando los documentos relacionados necesarios para poder entender los temas citados o implicados en el mismo.
  • Al guardar el documento, no se debe dejar espacios en el nombre del archivo.
  • Todos los documentos deben tener encendido el sistema de grabación de versiones, para el trabajo colaborativo entre las partes involucradas.
  • Tener un glosario de términos o palabras empleadas.

Sistema de versionado del software ofimatico.

Este se activa desde el menu de "Ediccion", un elemento de menu que dice "Cambios". En sistemas privados licenciados esta en un menu especial de "Revisiones". En sistemas mas pequeños se encuentra de la misma manera, en un menu especifico llamado "Colaborar".

Practicante consta de tres cosas, activar el versionado o grabar, ver los cambios y gestionarlos, no es muy difícil, "jugando un poco" se llega entender esto.

Adquisición de un servicio de consultora versus la propia implementacion del software


Se debe dejar en claro las diferencias y beneficios de la adquisición de un servicio de consultoría, y que cuando son basados en productos código abierto, no es exactamente gratis. Al adquirir un software el soporte en general viene de tres maneras: el libre, opensource en comunidad (este es importante para los desarrolladores); el opensource de licencia dual (que es una combinación entre libre y licenciado); así como el profesional o de consultoría (al que la empresa recurre oficialmente). La siguiente tabla ilustra diferencias entre opensource y licenciado:

Empleo de Software Libre Opensouce
Servicios duales OpenSource y/o Privados
Servicios y Consultoría Privada Profesional
Todo es visible, con esfuerzo bien funciona”
Todo visible, y funciona si me compras”
Funciona excelente, pero es una caja negra”
  • Los servicios se limitan a los que hay disponible en el ámbito global, y no específicos a las necesidades de una empresa solicitante.
  • Los servicios se limitan a los que hay disponible en el ámbito global, y no específicos a las necesidades de una empresa solicitante.
  • La empresa especifica según sus requerimientos a la consultoría que es lo que necesita y esta le debe proporcionar una solución viable.
  • Entornos de producción funcionan completos, pero se limitan si son incompatibles con licencias no libres.
  • Los entornos de producción funcionan limitados si no se adquieren las licencias. Permite la combinación de licencias.
  • Se requiere licencia para entorno de producción, las cuales expiran en un tiempo determinado y entonces dejan de funcionar.
  • La estabilidad depende de la popularidad del proyecto o software, no existen garantías de funcionamiento ya que el producto se ofrece “así tal cual”.
  • La estabilidad depende del tipo de producto adquirido, si no es licenciado este depende de la popularidad respecto su contraparte licenciada.
  • Los entornos de producción son certificados estables, y si aparecen problemas la empresa responde por la eventualidad con soporte pero según los acuerdos de licencia.
  • El software no esta apadrinado ni apoyado por compromiso alguno. Su continuidad y soporte se basa en su popularidad. Por ello esta disponible el producto con su fuente.
  • El soporte y continuidad depende de la competitividad de las licencias. También parte es basada en su popularidad. Ofrecen si se adquieren licencias migraciones.
  • El software ofrece continuidad basado en las tendencias del negocio, en casos de migración, las licencias definen el alcance y soporte de apoyo y servicios ya sin uso.
  • Las herramientas de software pueden usarse en su totalidad sin restricciones, incluso modificar sus partes según las necesidades.
  • Las herramientas pueden estar restringidas si no se adquiere las licencias, pero en la mayoría de los casos ofrecen el código fuente para modificarlo según necesidades.
  • Las herramientas son modulares, mas no modificables, la consultoría se realiza bajo los estándares y tecnologías ya fabricadas, o los definidos por el servicio de consultoría.
  • Si se modifica alguna herramienta según las necesidades, los foros y comunidades ofrecen el apoyo disponible.
  • Si se modifica alguna herramienta según las necesidades, su soporte y apoyo debe estar contemplado en la licencia.
  • Es ilegal si se modifica alguna herramienta utilizada durante la consultoría, a menos se haya declarado ello.
  • Los estándares están en la red, no cambian los parámetros ni implementan nada nuevo sin aprobación de la comunidad.
  • Los estándares intentan ser mixtos, entre los abiertos y los apegados a los impuestos por grandes empresas.
  • Los estándares son seguidos incluso ofrecen soporte extra. Sin embargo, las empresas implementan “mejoras” que rompen los estándares.