Desarrollar Software es todo un arte, definitivamente la organización y la correcta definición de requerimientos, son la clave del éxito.

El dimensionamiento, de recursos, personal, equipos, tiempos, herramientas, es vital, lamentablemente más del 80% de los proyectos de desarrollo de software nunca concluyen bien porque siempre faltó la correcta definición de requerimientos por parte del cliente y el correcto dimensionamiento por parte del desarrollador.

Personalmente he tenido más conflictos queriendo resolver un mal planteamiento de los requerimientos del cliente que rechazando trabajos por la falta de una buena definición.

Es mejor dejar de lado proyectos mal planteados, que luego tener que lidiar, no sólo con la mala definición de requerimientos sino también con un mal dimensionamiento que es un resultado indefectible ante ese mal planteamiento de requerimientos.

ACTUALIDAD EN TWITTER

REQUERIMIENTOS

Cuándo un proceso o un trabajo requiere cierto nivel de automatización, rapidez, evaluación y consulta de gran cantidad de datos, es el momento adecuado para utilizar un software, que nos colabore con esas y otras tareas más.

La elección de esta importante herramienta, no debe darse por la moda, sino debe ser el resultado de un estudio cuidadoso y detallado de los verdaderos requerimientos que se tienen.

DIMENSIONAMIENTO

Con los requerimientos correctamente definidos es totalmente factible realizar un dimensionamiento muy adecuado tanto en tiempo, recursos y personas que deben intervenir para la implementación del software.

Desde luego con los requerimientos correctamente definidos y el dimensionamiento adecuado es más sencillo saber si el software, debe ser comprado de un proveedor que ya tiene ese tipo de herramienta en funcionamiento o si el software debe ser desarrollado desde 0.

FLEXIBILIDAD

Tanto para el cliente como para el desarrollador la flexibilidad es más que vital para concluir con éxito el proyecto.

Con la implementación de un software ya sea comprado o desarrollado existirán muchos cambios en diferentes niveles de la empresa y los procesos que lleva adelante.

El cliente, debe ser flexible, para poder asumir esos cambios, el desarrollador, debe ser flexible a la hora de adecuar y/o desarrollar muchos de los requerimientos solicitados.

PRESENTACIÓN

Indudablemente no podría dejar de tener en mi portal web, un segmento dedicado exclusivamente al desarrollo de software, desde mi primera página web allá por 1999, hasta el día de hoy, el desarrollo de software ha sido uno de los temas de los que más he escrito.

Durante todos estos años los paradigmas de desarrollo han cambiado de manera notable, sin embargo no tan notable como las herramientas y lenguajes de programación, los cambios para estos últimos han sido muy superiores, debido a las nuevas tecnologías, que pasaron de un modelo básico tipo cliente servidor hasta los modelos multicapa y por supuesto, el desarrollo de las aplicaciones móviles.

Más allá de todos los cambios que se han ido dando y los que seguramente están en camino, el mayor reto que ha existido desde el inicio del desarrollo de software ha sido poder definir de manera clara, precisa y concisa el propósito de mismo, poder definir efectiva y eficientemente todos y cada uno de los requerimientos que son la razón de ser del software.

Tanto para los clientes como para los desarrolladores, definir el propósito es lo más complejo, por lo general cuándo se plantea la necesidad de tener un software, no se piensa en que primero hay que diseñarlo, pero no desde el punto de vista del desarrollador, sino desde el punto de vista de los que van a utilizar y además desde el punto de vista de los que platean la necesidad de contar con uno, en síntesis desde el punto de vista del cliente.

La arquitectura del software es fundamental, pero pocas veces se la define de manera independiente, muchas veces el cliente que contrata el servicio de desarrollo deja que esta tarea la haga el desarrollador, lo cual es un error fatal, ya que nunca hará el diseño que en realidad el cliente necesita, sino el que el desarrollador cree que es el más adecuado, lo que siempre lleva al inevitable retraso y casi fracaso en el desarrollo de software.

Dadas estas características casi estándares con los proyectos de desarrollo de software, confirman de manera irrefutable los 3 conceptos planteados al inicio de esta sección REQUERIMIENTOS, DIMENSIONAMIENTO Y FLEXIBILIDAD, si podemos establecer de manera clara y precisa estos conceptos al momento de iniciar con la idea de desarrollar software, seguro que si iniciamos el proyecto concluirá con éxito, caso contrario, no se invertirá más que una pequeña fracción en determinar que no es la mejor opción, se podrán definir mejores alternativas que sean más económicas y desde luego evite el gasto innecesario de recursos.

En los segmentos posteriores planteo una serie de ideas, procesos y métodos, que podrían ser una ayuda para los desarrolladores, pero principalmente planteo la necesidad de que cada cliente, debe tener previamente a un arquitecto de software, que pueda diseñar y establecer de manera clara lo que necesita, pero desde el punto de vista del mismo cliente.

DISEÑO

Desarrollar un software, no es una tarea sencilla ni que deba tomarse a la ligera, la Ingeniería de Software es muy importante a la hora de llevar a cabo un proyecto de software, es la que se encarga de segmentar el proyecto en diferentes procesos, con la finalidad de tener tareas puntuales de propósito específico, para llevar adelante el proyecto de forma eficiente y efectiva.

  • Ingeniería de software

    Ingeniería de software

    Ofrece métodos y técnicas para desarrollar y mantener software. La creación del software es un proceso creativo y la Ingeniería del Software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo por medio de diversas técnicas que se han demostrado adecuadas en base a la experiencia previa. Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas.

Una de las tareas de propósito específico más importantes dentro de un proyecto de desarrollo de software es el diseño, de un buen diseño, de una buena arquitectura, se obtiene un buen software, que cubra los requerimientos para los que fue creado.

En el proceso de diseño de software que realicemos debemos incluir los siguientes componentes: (Pasa el cursor sobre los elementos de la lista para ampliar)

  • Análisis de requisitos o requerimientos

    Análisis de Requisitos o Requerimientos

    El análisis de requisitos o requerimientos es la tarea que plantea la creación de software a nivel de sistema, diseño de programas, flujos y procesos. El análisis de requisitos o requerimientos facilita al arquitecto de software la especificación de la función y comportamiento de los programas, flujos, procesos, permite definir las interfaces con otros elementos del sistema, establecer los alcances y estándares de diseño que debe cumplir el programa. El análisis de requisitos permite refinar la asignación de roles y representar el dominio de la información que será tratada por el programa.

    El análisis de requisitos o requerimientos le da al diseñador la representación de la información y las funciones que pueden ser traducidas en datos, arquitectura y diseño procedimental. Finalmente, la especificación de requisitos suministra al técnico y al cliente, los medios para valorar la calidad de los programas, una vez que se haya construido.

    Dentro de este importante componente, es importante brindarle al cliente el asesoramiento necesario para poder convertir las ideas, las necesidades y los requerimientos en flujos coherentes, tangibles y que sean reales, facilitando la consecución de los objetivos planteados al inicio y verificar la factibilidad del proyecto.

    Hacer este análisis, puede derivar en el desarrollo de software si es que el cliente así lo define o simplemente puede ser el servicio de análisis como tal, para que luego este análisis, pueda ser utilizado por los desarrolladores que se vayan a hacerse cargo del desarrollo.

  • Arquitectura

    Arquitectura

    La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.

    Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información.

    La Arquitectura de Software establece los fundamentos para que analistas, diseñadores, programadores, etc. trabajen en una línea común que permita alcanzar los objetivos del sistema de información, cubriendo todas las necesidades.

    Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas.

    La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué usuario o computadora tendrá asignada cada tarea.

    La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.

    Kruchten, Philippe

Con los componentes previos ya definidos e implementados ya se tiene el diseño de software, de un diseño adecuado tendremos un software, que sea útil, que cubra los requerimientos, de fácil mantenimiento y que sea escalable en el tiempo, el software es una herramienta que debe colaborar con la mejora de los procesos, debe integrarlos, no debe de convertirse en un problema más por resolver. Se debe tomar en cuenta estas premisas antes de iniciar un proyecto de desarrollo de software.

DESARROLLO

Existen muchos métodos y metodologías para desarrollar software, en la gráfica a la derecha se puede ver un esquema de los más convencionales para el desarrollo, lo importante es tener en mente que el método es una herramienta que nos colabora; para seleccionar alguna debemos basarnos en diferentes aspectos como: en el CORE del negocio, en la premura que se tenga para el desarrollo, en el conocimiento y/o dominio de un método en particular, lo importante es usar esta herramienta en beneficio del desarrollo.

El desarrollador debe entender que todo desarrollo para sus clientes tiene que ser rápido, preciso y por sobre todo escalable a lo largo del tiempo, durante mis años de desarrollador mi método de trabajo favorito ha sido el SCRUM, que permite agilizar y acortar tiempos en desarrollo; también he creado mi propia metodología de desarrollo, y mi propio FrameWork de desarrollo, al combinar estos elementos he podido desarrollar software en corto tiempo, documentado, organizado, escalable y adecuado al cliente, ahorrando tiempo y costo, tanto en mantenimiento como en nuevas incorporaciones.

A continuación comparto un resumen de cada uno de los elementos en los que he basado todo el proceso de desarrollo, estos elementos me han permitido cubrir con todos los requisitos, requerimientos y necesidades de cada cliente a la hora de implementar un proyecto de software:

  • Scrum

    Scrum

    Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

    Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.

    Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.

    Durante cada sprint, un periodo variable en días (este periodo es definido por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es el conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog forman parte del sprint y se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo, entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

    Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

  • Metodología

    Metodología

    La metodología que he desarrollado se llama Metodología BS. Me he basado en la experiencia y en el uso de muchas metodologías extrayendo lo más útil de cada una de ellas, prácticamente traté de establecer un estándar de desarrollo que me permita mayor calidad en cada producto que he desarrollado.

    La Metodología BS tiene etapas que implican distintos procesos, cada etapa genera componentes que son necesarios para la siguiente etapa por lo que es recomendable aplicar cada una de ellas para que el modelo funcione correctamente y nos genere un software óptimo.

    La Metodología BS ha sido completamente orientada para el desarrollo de herramientas de BI, sin embargo aplicando pequeñas modificaciones en las etapas 4 y 5, esta metodología puede ser utilizada para desarrollar cualquier tipo de software.

    Uno de los requerimientos más importantes de la metodología es generar documentación por cada etapa, en el documento se debe detallar los siguientes puntos:

    • Requerimientos: se deben plantear todos los recursos que se necesiten para que se pueda cumplir la etapa.
    • Procesos efectuados: modelos, diagramas, información, datos, en fin todos los procesos que se han desarrollado en la etapa deben ser documentados en este punto.
    • Resultados obtenidos: se deben listar y describir los resultados obtenidos en la etapa con el fin de ser útiles para la siguiente etapa de desarrollo.

    Para ver con mayor detalle la metodología, puedes leer y/o descargar el documento completo en el siguiente enlace:

  • FrameWork

    FrameWork

    La palabra "FrameWork" define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular, que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar.

    En el desarrollo de software, un FrameWork es una estructura conceptual y tecnológica de soporte definida, normalmente módulos de software concretos, con base en la cual otro proyecto de software puede ser organizado y desarrollado, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

    Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional.

    Pensando en la reutilización de componentes, la agilidad para desarrollar aplicaciones y basado en toda la experiencia que adquirí con los años, he creado mi propio FrameWork, que minimiza los tiempos de desarrollo, mejora la reutilización de componentes, permite hacer modificaciones en "caliente", de esta forma siempre me aseguré que los cambios que se podían realizar en la aplicación desarrollada sobre el FrameWork, fueran cambios que no generen ningún tipo de problemas a la hora de implementarlos.

BPM

Se llama Gestión de procesos de negocio (Business Process Management o BPM) a la metodología corporativa cuyo objetivo es mejorar la eficiencia a través de la gestión de los procesos de negocio, que se deben modelar, organizar, documentar y optimizar de forma continua. Como su nombre sugiere, BPM se enfoca en la administración de los procesos dentro de una organización.

Es un conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos.

A través del modelado de las actividades y procesos puede lograrse un mejor entendimiento del proceso y muchas veces esto presenta la oportunidad de mejorarlos. La organización de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa.

La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente, cumpliendo con estándares de calidad previamente establecidos, ayudando a la obtención de información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos, que se puede identificar posibles ineficiencias o fallas en los mismos, y así actuar sobre ellos para optimizarlos.

Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management System (BPMS), y con ellas se construyen aplicaciones BPM.

Durante mucho tiempo he asesorado a varios clientes en la selección de una herramienta BPM apropiada para cubrir sus necesidades de mejora en sus procesos de negocio.

WORKFLOW

El flujo de trabajo (workflow en inglés) es el estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de las tareas.

Si bien el concepto de flujo de trabajo no es específico a la tecnología de la información, una parte esencial del software para trabajo colaborativo (groupware) es justamente el flujo de trabajo.

Una aplicación de flujos de trabajo automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecución del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y brinda las herramientas necesarias para realizar la gestión.

Se pueden distinguir tres tipos de actividad:

  • Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común.
  • Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos.
  • Actividades de coordinación: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo mecanismos de coordinación para algunas actividades en particular.

Los objetivos de un sistema de workflow son:

  • Reflejar, mecanizar y automatizar los métodos y organización en el sistema de información.
  • Establecer los mecanismos de control y seguimiento de los procedimientos organizativos.
  • Independizar el método y flujo de trabajo de las personas que lo ejecutan.
  • Facilitar la movilidad del personal.
  • Soportar procesos de reingeniería de negocio.
  • Agilizar el proceso de intercambio de información y agilizar la toma de decisiones de una organización, empresa o institución.

BUSINESS INTELLIGENCE

El término inteligencia de negocios o business intelligence se refiere al uso de datos en una empresa para facilitar la toma de decisiones. Abarca la comprensión del funcionamiento actual de la empresa, como la anticipación de acontecimientos futuros, con el objetivo de ofrecer conocimientos para respaldar las decisiones empresariales.

Las herramientas de BI se basan en la utilización de un sistema de información o software que se forma con distintos datos e información extraídos de producción, con datos e información relacionada con la empresa o sus ámbitos y con datos e información del tipo económico.

Mediante las herramientas y técnicas ELT (extraer, cargar y transformar), se extraen los datos de distintas fuentes, se depuran y preparan (homogeneización de los datos) para luego cargarlos en un almacén de datos o más conocido como Data Warehouse.

La vida o el periodo de éxito de un software de inteligencia de negocios dependerá únicamente del nivel de éxito que tenga en la empresa que lo usa, si esta empresa es capaz de incrementar su nivel financiero, administrativo y sus decisiones mejoran el accionar de la empresa, la inteligencia de negocios usada estará presente por mucho tiempo, de lo contrario será sustituida por otra que aporte mejores resultados y más precisos.

Por último, las herramientas de inteligencia analítica posibilitan el modelado de las representaciones con base en consultas para crear un cuadro de mando integral que sirve de base para la presentación de informes.

Este conjunto de herramientas y metodologías tienen en común las siguientes características:

  • Accesibilidad a la información. Los datos son la fuente principal de este concepto. Lo primero que deben garantizar este tipo de herramientas y técnicas será el acceso de los usuarios a los datos con independencia de la procedencia de estos.
  • Apoyo en la toma de decisiones. Se busca ir más allá en la presentación de la información, de manera que los usuarios tengan acceso a herramientas de análisis que les permitan seleccionar y manipular sólo aquellos datos que les interesen.
  • Orientación al usuario final. Se busca independencia entre los conocimientos técnicos de los usuarios y su capacidad para utilizar estas herramientas.

Los niveles de realización de BI están de acuerdo a su nivel de complejidad y se pueden clasificar las soluciones de Business Intelligence en:

  • Consultas e informes simples (Querys and reports).
  • Cubos OLAP (On-Line Analytic Processing).
  • Data Mining o minería de datos.
  • Sistemas de previsión empresarial; predicción mediante estudio de series temporales (ejemplo: Previsión de ventas).

Tengo desarrollada una herramienta de BI que puede ser la respuesta a muchas necesidades y requerimientos, si estás interesado en conocer más sobre esta herramienta escríbeme para que te cuente más al respecto.

Si ya tienes tu propia herramienta desarrollada o tal vez necesitas algo de ayuda para concluirla, no lo pienses más y escríbeme.

ARQUITECTURA ORIENTADA A SERVICIOS - SOA

La arquitectura orientada a servicios de cliente (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio, permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros. SOA define las siguientes capas de software:

  • Aplicaciones básicas: Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad.
  • De exposición de funcionalidades: Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web).
  • De integración de servicios: Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración.
  • De composición de procesos: Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio.
  • De entrega: Donde los servicios son desplegados a los usuarios finales.

SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.

  • Servicio: Una función sin estado, auto-contenida, que acepta una(s) llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz bien definida. Los servicios pueden también ejecutar unidades discretas de trabajo como serían editar y procesar una transacción. Los servicios no dependen del estado de otras funciones o procesos. La tecnología concreta utilizada para prestar el servicio no es parte de esta definición. Existen servicios asíncronos en los que una solicitud a un servicio crea, por ejemplo, un archivo, y en una segunda solicitud se obtiene ese archivo.
  • Orquestación: Secuenciar los servicios y proveer la lógica adicional para procesar datos. No incluye la presentación de los datos. Coordinación.
  • Sin estado: No mantiene ni depende de condición pre-existente alguna. En una SOA los servicios no son dependientes de la condición de ningún otro servicio. Reciben en la llamada toda la información que necesitan para dar una respuesta. Debido a que los servicios son "sin estado", pueden ser secuenciados (orquestados) en numerosas secuencias (algunas veces llamadas tuberías o pipelines) para realizar la lógica del negocio.
  • Proveedor: La función que brinda un servicio en respuesta a una llamada o petición desde un consumidor.
  • Consumidor: La función que consume el resultado del servicio provisto por un proveedor.

Durante mi vida profesional he colaborado con varios clientes en la selección, adecuación, implementación y puesta en marcha de arquitecturas SOA independientemente del proveedor de esta herramienta, me convertí en un especialista en SOA, si quieres que te apoye en integrar todos tus sistemas de información y así tengas las herramientas necesarias para que puedas controlar, definir reglas, tener el gobierno sobre tus flujos, procesos y sistemas, entonces escríbeme.