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 Terminología básica BPM - BPM & Proyectos Software Gestor de proyectos - BPM & Proyectos Comenzando - BPM & Proyectos

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.



Terminología básica BPM


Terminología BPM

Esta terminología no esta ordenada alfabéticamente, su intención es actualizarla a medida crezca el contenido. Los términos aquí son basados en el estándar de BPMN y no el de BPEL.

Para el gerente y los lideres de proyectos, es la guía perfecta, y adicional primordial para entenderse con los recursos: programadores y desarrolladores. Para el programador es esencial aprenderselos de memoria.

BPM: Business Process Management.
Metodología que permite automatizar el comportamiento de la organización a través de los procesos.
BPEL: Bussines Process Execution Languaje
Es la definición de lenguaje de programación para la implementación de BPM, cualquier regla se plasma y realiza al servidor de aplicaciones empleando este lenguaje.
BPMN: Business Process Manager Notation
Definicion adicional de un lenguaje visual el cual genera el BPEL para depues desplegar la idea o regla.
BAM: Business Activity Monitoring
Capacidad de la plataforma BPM empleada para vigilar y exponer los eventos (procesos corriendo y sus resultados) del negocio en accion. Este concepto logra extenderse a otra rama, el BI.
  • Elementos BAM: son necesarios porque permiten emplear decisiones para modificar las reglas de negocios, el fin de estos son optimizar los procesos:
  • KPI’s : indicadores claves de rendimiento-
  • Dashboard: monitorizacion en tiempo real el valor actual de los KPI’s
Orquestación:
Ejecución organizada de las reglas que definen un proceso, respecto el todo del negocio.
BPMS: Business Process Management System/Suite.
Las herramientas o componentes para la construcción de aplicaciones siguiendo la metodología BPM anteriormente ilustrada.
  • Componente BPMS: Artefactos de software que permiten trabajar modularmente la tecnologia y metodología BPM.
  • Workflow:Es el motor que ejecuta/orquesta los procesos de negocio definidos, por medio de BPEL.
  • Process Designer: La herramienta que permite definir los procesos de negocio por medio de un lenguaje que se traduzca a BPEL como lo son BPMN o XPDL.
  • Form Creator: Herramienta que permite definir formularios de interacción humana donde el actor puede iniciar, rechazar, aprobar, una instancia de un proceso de negocio.
BRE: Business Rules Engine
El entorno de ejecución donde el conjunto de varias reglas de procesos se relacionadas entre si o se encuentran.
BPMS Connectors:
Los componentes que permiten dotar de tecnologías para los procesos, es decir, el BPMS define las reglas en que se trabaja, pero no la tecnología empleada, de esto se encarga los conectores. Estos pueden ser para ECM, LDAP, ESB, etc. Son cruciales en los BPMS puesto definir las reglas sin ponerlas en practica en su máxima expresión no optimiza ningún negocio.
JBPM: Java/JBoss Bussines Process Modeling
Es la tecnologia de BPM empleada en ciertos BPMS, como versiones antiguas de oracle y ahora en versiones recientes de los productos de RedHat.
WS: Web Service
Tecnologia web basada en servicios a demanda.
XPDL: XML Process Definition Language
Lenguaje alternativo de BPM

Software Gestor de proyectos

Existen muchos, entre los privativos uno de los mas completos es Jira, enfocado en java, entre los libres Redmine esta tomando fuerza. Sin embargo estos tiene dos problemas, dependen de tecnologias no estandares y no estan sus dependencias en los hosting principales.

Todos sabemos que los proyectos estan presionados por la parte Gerencial, asi que lo siento, lastimosamente estos factores estaran molestando siempre.

Factores para implementar un software de gestion de proyecto

Que debe tener en cuenta al implementar un software de gestiion de proyecto:
  • Facil de usar
  • Entendible
  • Colaborativo
    • Soporte estimaciones
    • Soporte de tareas y tickets
    • Soporte de diagramas de grantt
    • Integrable a GIT, SVN y CVS
    • Sistema de documentacion
  • Enfoque:
    • Local interno de la empresa
    • Hosteado en un entorno empresarial o servidio externo
  • Sostenible
    • Tecnologia conocida, con soporte conocido comprobable.
    • Con soporte de alguna compañia resposable del mismo.
    • Seguro y fiable

Entre los mas usados estan Dotprojet, Jira, BaseCamp, Redmine, que integran muchos de los elementos, pero tambien estan las opciones por separado, estan no deben ser tomadas en cuenta, ay que dificultan la sotenibilidad del proyecto, el ejemplo mas famoso de estas soluciones por separado es mantis+mediawiki y sharepoint.

Los recomendados para usar aqui se clasifican en dos categorias: Internos manejados por la empresa misma o externos, y lo mas logico es que si es interno sea barato y administrado por la empresa misma.
Si la empresa emplea recursos por fuera de las instalaciones, debe optarse por tener salida y entrada segura de la red o un servicio externo de gestion de proyecto.

Gestor de proyecto interno: Redmine

Redmine es una solución flexible de vistas Web para la gestión de proyectos. Escrito el framework Ruby on Rails, Redmine es de código abierto, lo que significa que siempre se puede modificar el sistema, de acuerdo a las necesidades específicas de su empresa. El programa es multilingüe y está disponible en más de 30 idiomas. También cuenta con el apoyo de bases de datos múltiples: la aplicación está disponible en Postgre SQL, SQLite y MySQL. Esta es una imagen del redmine modificado solo a travez del tema, corriendo en Venenux 0.9 en la pestaña de control de versiones del software projecto desarrollado.


Pros:

  • Extremadamente sencillo y facil de usar
  • Diagrama de Gantt, que es la característica más esencial para la planificación del proyecto. 
  • Reportes: exporta cualqueira de las vistas en varios formatos
  • Modular:La mayoría de las características a nivel de proyecto se puede desactivar si es necesario.
  • Multiproyecto: soporta multiples proyectos y subproyectos, y adicional en una sola instancia o multiples.
  • Soporte empresarial externo: alojamiento en los servidores de Planio se inicia a partir de 9 $ por mes. Usted puede obtener una prueba gratuita de 30 días.
  • Tasklist: basado en la gestion del sistema de bugtracking, tiene sistema integrado de listas de tareas y adicional planificados.
  • Planificador: las definiciones de fin de requerimientos son gestionados en las tareas.
  • Bugtraking: incluye sistema de reporte y peticiones de incidencias.
  • Repositorios: se integra perfectamente a cuatro tipos de repositorios, siendo el que mas repositorios soporta, como git, bazar, subversion y el antiguo cvs.
Contras:
  • Es basado en tecnologia RubyOnRails y ningun hostig lo trae

Gestor de proyectos externos:

Aquí es cuando la empresa no cuenta con la infraestructura o tiene la necesidad de tener el proyecto en la nube, sea privado o publico.

Conclusiones


Redmine es el ganador obvio ya que es el que posibilita la mayor cantidad de capacidades, no perdere tiempo en compararlo con los demas ya que el colmo de los beneficios es que adicional a su facilicimo adaptacion de uso por parte de windoseros, esta el que se pueda integrar a gmail con xmpp.

Comenzando

En un proyecto hay tres partes:

Tecnica, Funcional y gerencial.

Lo primero que hay que hacer es convencer la gerencia, para esto un proyecto debe tener factibilidad, rentabilidad y por lo general y siempre es asi, integración e histórico con las tecnologías presentes.


Cada organización tiene sus propios procesos distintos de negocios que los diferencia de sus competidores. Nuestro caso es relativo a muchos procesos que son definidos por los propios trabajadores. La integración al unisono es una de las metas para la efectividad y productividad.

  • Atención al cliente (tiendas, modo entandar de trabajo y acopio)
  • Control de calidad (efectividad del producto respecto el mercado y la competencia)
  • Requerimientos (insumo, equipos, consumibles)
  • Administración (caja chica, contratación de recursos)

Minutas a tomar en cuenta al comenzar un proyecto:


  • No debe costar mucho.
  • No debe ser complicado de implementar.
  • Debe ser rapido de desarrollar o construir.
  • Debe tomarse en cuenta los riesgos de que se complete.
  • Debe tener en cuenta la tecnologia empleada.
  • Debe ser factible de emplear sus componentes y recursos en el tiempo que dure.
  • Sus componentes y recursos depen perdurar un tiempo despues de la culminacion de su desarrollo.

Esto son principios esenciales.

La parte tecnologica es importante, determina y ayuda mucho en la organizacion.