Arquitectura - Aterrizando Conceptos - BPMN o UML

Fuente: http://www.bpm-guide.de/bpmn/

La notación gráfica de BPMN permite representar fácilmente los elementos que intervienen en un proceso de negocio, como eventos, secuencias, actividades  y el orden en que estas se deben ejecutar, mensajes y el orden en que se intercambia.

Su importancia radica en poder entender el flujo de información dentro de la estructura del negocio y no en las tareas que realiza una persona especifica, BPMN debe ser el punto de partida de cualquier esfuerzo de desarrollo de software. 

Entonces al modelar sistemas de información  lo primero que debemos identificar son los procesos de la organización y sus interrelaciones o flujos de trabajo (Workflows). Luego debemos crear los diagramas BPMN por cada proceso de negocio identificado.

Por otro lado existe otro estándar técnico  de representación gráfica, que nos permite documentar un sistemas de software,  UML aporta seis tipos de diagramas para llevar a cabo esta labor, pero el que mas se relaciona con BPMN, es el de  actividad.

Los dos estándares son soportados por la OMG y su notación es muy similar, UML es mas utilizado por desarrolladores e ingenieros de software, en la documentación de sistemas de software orientado a objetos. BPMN es mas utilizado por Ingenieros Industriales y Arquitectos de Sistemas que necesitan representar procesos de Negocio.

En conclusión los estándares se pueden complementar para describir en mayor detalle el modelo del negocio, el uso de un lenguaje, no debe descartar el otro.

Arquitectura - Aterrizando Conceptos

Ya hemos cumplido un poco mas de un mes de clases, y llego el momento de empezar a aplicar lo aprendido en el proyecto final, pero son muchas las dudas que aun nos quedan. Y trato de analizar y entender porque esta parálisis de creatividad al momento de realizar los diseños de arquitectura, todos en el grupo somo ingenieros y de una manera u otra se que nos hemos enfrentado a este tipo de situaciones, hemos participado en proyectos de toda índole, de desarrollo, de implementación de software, de adquisición de Hardware y siempre hemos sabido como salir adelante, porque esa es nuestra bandera ser  "INGENIEROS".

Entonces pienso que debemos apropiarnos de estos temas y empezar a dar soluciones a  nuestro problema,  así como cuando en mas de una ocasión nos ha tocado aprender a manejar X o Y software o plataforma sin tener idea, tomábamos los manuales, nos los digeríamos, cachareabamos y resultábamos siendo los expertos en el tema.

Entonces nuestra problemática ya tiene un limite definido, que son las diferentes metodologías y mejores practicas para la definición de arquitecturas de  sistemas de información o arquitectura empresarial.

Que nos falta? buscar las fuentes de información, digerirnos lo manuales y empezar a cacharrear, entonces este es nuestro Menú para abordar la problemática:

BPMN: Business Process Model and Notation, un estándar que nos permite representar  de manera gráfica los procesos de negocio, para su entendimiento. en el sitio del Object Management Group encontramos guías de referencia rápida y ejemplos:  http://www.bpmn.org/ y su guía rápida en http://www.bpmnquickguide.com/viewit.html

UML:  Unified Modeling Lenguaje Es un lenguaje gráfico para visualizar , especificar y documentar un sistema, como clases, objetos,comportamientos e interacciones (Casos de Uso). También sirve para modelar los procesos de negocio, por lo que puede complementar BMPN  Las guías oficiales las podemos encontrar en: http://uml.org y un buen tutorial en: http://www.jeckle.de/umllinks.htm#tutorials

XML: Extensible Markup Lenguaje : Es un lenguaje de marcas utilizado para el intercambio de información estructurada y busca expresar la información de la manera mas extracta y reutilizable posible. El sitio oficial lo encontramos en: http://www.w3.org y su  correspondiente tutorial en http://www.xmlmaster.org/en/article/d01/c01/

Bueno, entonces manos a la obra...

Acerca del Método Iterativo e Incremental

Fuente: http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa

Son varias las metodologías que utilizan estas técnicas para el desarrollo de proyectos de software, las iteraciones consisten en definir requisitos concretos para lograr un producto (entregable) en cortos periodo de tiempo y así minimizar el riesgo en el alcance costo vs tiempo. Por ejemplo SCRUM utiliza periodos de hasta dos semanas, una vez terminada una iteración se inicia la siguiente para mejorar el producto e introducir nuevas características

Es necesario tener en cuenta que los dos métodos son diferentes y pueden ser utilizados de manera separada o en conjunto.

El método incremental

Consiste en dividir el problema en partes e ir desarrollando uno por uno hasta obtener el producto completo, un ejemplo claro de esto podría ser el desarrollo de un ERP, primero desarrollaríamos el modulo contable, luego el financiero, luego el de recurso humanos y así sucesivamente.

El método iterativo

Consiste en ir mejorando un producto en ciclos de desarrollo, en cada iteración se adicionan nuevos requisitos y nuevos elementos de calidad.

Entonces el "Ciclo de vida e incremental" utiliza los dos enfoques para ir obtienendo al final de cada ciclo una versión mas completa y estable del software, de más calidad siendo este el principal aspecto el que se debe mantener y mejorar en cada iteración.

Sus principales características son 

- Se deben priorizar los entregables de acuerdo al impacto (tiempo/costo)que tengan sobre el proyecto .

- El entregable debe estar completo, debe incluir pruebas y documentación.

- En cada iteración el producto debe ir evolucionando (nuevos requisitos).

- Al finalizar cada iteración el cliente de revisar y aprobar los entregables.

Sus ventajas

- El cliente puede ver el avance y obtiene resultados del proyecto desde sus inicios.

- Es mas fácil introducir clientes solicitados por el cliente.

- Mayor control de riesgos

- En caso de que el proyecto no sea viable para el cliente, se pierden menos recursos.

La importancia del Contexto en la Arquitectura de Software

Fuente: http://blanmr.blogspot.com.co/2011/02/origen-y-evolucion-del-lenguaje.html

Según su definición Contexto es "El conjunto de circunstancias que rodean una situación y sin las cuales no se puede comprender correctamente".

Entonces queda claro que el contexto es elemento esencial para  la definición de la Arquitectura de Software, las soluciones de software cambian de acuerdo a la definición de su contexto, es por eso que este debe quedar claramente definido desde el principio.

Algunas de las características para la definición de un contexto,  en una solución de software pueden ser:

- Culturales 
- Políticas
- Económicas
- Tecnológicas.
- El modelo de negocio.

Existen metodologías para definir el diagrama de contexto para una Arquitectura de software, por ejemplo el Lenguaje UML nos ofrece los diagramas de contexto o también conocidos como "Diagaramas de Nivel 0",que permiten definir los limites de la solución, con relación a su entorno y mostrando los elementos con los que se relaciona e interactua.

Fuente: http://es.slideshare.net/COMPUTO1ISTENE/diagrama-de-contexto

En el diagrama apreciamos el actor principal en el centro, las entidades a su alrededor representados por cuadros con su respectiva etiqueta y las relaciones son flechas entre las entidades y el sistema, estas pueden ir etiquetadas para dar un mayor nivel de claridad, por ejemplo para el diagrama anterior se podría aclarar la relación usuario cajero automático "Interactua".

Con frecuencia los diagramas de caso de uso son reemplazados por los diagramas de casos de uso, ya que dan un mayor detalle para la formulación de requerimientos.

Modelo de Información

Fuente: http://www.documentalistaenredado.net

La importancia de la información en las Empresas, como herramienta para la planeación y ayuda en la toma de decisiones, hacen que la definición de un Modelo de Información, sea necesario.

Los datos una vez capturados, no aportan mayor valor para la toma de decisiones, es necesario procesarlos, estructurarlos y clasificarlos para que tengan significado y permitan su posterior análisis.

Un modelo de Información nos permite obtener información de valor, de manera veraz, eficaz y oportuna. Para lograr esto la información debes estar estructurada y categorizada de acuerdo a las necesidades de los interesados.

Categorizar la información nos permite clasificarla en conjuntos, permitiendo navegar a través de ella de una manera estructurada, y dependiendo el contexto del interesado poder satisfacer sus necesidades de análisis de  información.

Vista y Punto de Vista

Fuente: http://winkal.com

Y continuando con el tema de las palabras y sus definiciones, en esta ocasión tenemos dos invitadas a nuestra clase de Modelado, en teoría son fáciles de definir:Vista y Punto de Vista.
 
Vista :  Regresando a las épocas del colegio, se utilizaba para representar gráficamente un solido, en una de sus dimensiones.

Punto de Vista: Es como lo mismo cierto?, desde donde miremos  el solido (Vista superior, inferior, frontal, posterior o lateral ) pues así lo representamos.

Pero entonces que diferencia hay entre las dos... y viene  entonces la definición formal obtenida en clase:

Vista: "Representación de un sistema desde un punto de vista"

Punto de Vista: "Posición que un sujeto toma frente a un sistema y esta en estrecha relación con sus intereses y demás aspectos que sugieren un problema o una inquietud"

Y bien aquí se aclaro un poco el tema, pero entonces buscando un ejemplo real en nuestra tema de interes "Modelado y Gestión de la Información", encontré uno muy práctico y fácil de entender, tomados del marco TOGAF : El sistema aeropuerto con dos interesados.

SISTEMA: Aeropuerto

VISTAS: La del piloto, La del controlador aéreo 

Los dos tienen una vista diferente del sistema, cada uno tiene su perspectiva y ninguna representa el sistema por completo

PUNTO DE VISTA PILOTO: Utiliza un modelo de posicionamiento vectorial que le permite acercarse o alejarse de la pista de aterrizaje, también le interesa el combustible, la altitud, la velocidad.

PUNTO DE VISTA CONTROLADOR: Utiliza un modelo para representar el espacio aéreo y las posiciones vectoriales de los aviones en este espacio, esto lo logra por medio del radar.

Los dos interesados tienen un lenguaje de comunicación común para intercambiar esta información, para mantener la seguridad.

Por ultimo es interesante observar  las vistas utilizadas por los principales marcos arquitectónicos.

• Tomado de: "Introducción a la Arquitectura de Software" - Carlos Billy Reynoso

Un poco de diversión cae muy bien!!!

Bueno para los que nos iniciamos en esto de los Blogs, no es fácil encontrar un tema que pueda resulta útil o interesante, mientras buscaba algo de inspiración me encontré un par de vídeos divertidos, que abordan nuestra profesión, espero los disfruten tanto como yo, y muy bien por los creativos que generan este tipo de material.

ISO en TICs

Estuve investigando un poco acerca de las Normas ISO relacionadas con las tecnologías de la información, y me pareció interesante resumir lo encontrado en el siguiente cuadro, coloque los enlaces de cada norma al sitio de la ISO que la amplia.

NORMAS ISO EN TICs
12207	Information Technology / Software Life Cycle Processes	Establece un marco de trabajo común para la ingeniería del software, a lo largo de todo el ciclo de vida del producto
15504	Software Process Improvement Capability Determination (SPICE)	Es un modelo para la mejora, evaluación de los procesos de desarrollo, mantenimiento de sistemas de información y productos de software
20000	Service Management	Estándar reconocido internacionalmente en gestión de servicios de TI
22301	Business continuity management system (BCMS)	La norma proporciona todos los requisitos necesarios para diseñar, implantar, mejorar y certificar un Sistema de Gestión de Continuidad del Negocio.
25000	Systems and software Quality Requirements and Evaluation (SQuaRE)	La norma provee una guia para la uso de la nueva serie de estándares internacionales llamada Requisitos y Evaluación de Calidad de Productos de Software.
27000	Set of Information Security Standard	Es una serie de normas, estándares y mejores prácticas para la seguridad de la información. 27001 Information Security Management System 27003 Guidance for the Implementation of an ISMS 27004 Information Security Management measurement and metrics 27005 Information Security Risk Management 27006 Guidelines for the accreditation of organizations offering ISMS certification.
38500	Information Technology - Governance of IT for the organization	Su objetivo es proporcionar un marco de principios para que la dirección de las organizaciones los utilicen al evaluar, dirigir y monitorear el uso de las tecnologías de la información (TI's).

Referencias:

http://www.iso.org/iso/home/standards.htm

https://www.s2grupo.es/pdf/Carlos_Manuel_AENOR.pdf

http://www.javiergarzas.com/2014/06/normas-iso-para-tecnologia.html

El Fracaso en los Proyectos TIC

En esta ocasión quise investigar un poco acerca de los fracasos en los proyectos relacionados con las TIC y es bastante la información que se encuentra  al respecto, pero en el caso Colombiano no existen estudios serios al respecto, aunque el ministerio de las TIC a desarrollado un gran esfuerzo en medir el nivel de inversión y la penetración delas TIC, en cuanto al fracaso o perdidas económicas en los proyectos TIC no se evidencia mucha información.

A nivel Internacional,  existen estadísticas y estudios que demuestran que el porcentaje de proyectos fallidos se ha reducido en los últimos años, aunque el porcentaje sigue siendo demasiado alto, según la Standish Group, en 2009 el 68% de proyectos no fue exitoso,  en el 2012 esta cifra fue del 61% .

Conocemos que un proyecto fracasa por  el incumplimiento de cualquiera de las tres variables de la Gestión de Proyectos:  Alcance, Tiempo y Costo. Y para enfocar el problema en el tema que nos corresponde, se ha demostrado que esta situación se debe en gran parte, a que los responsables de lo proyectos, no tienen las habilidades adecuadas para modelar y definir con claridad los requerimientos del negocio, no conocen los procesos de las empresas, por tanto no pueden interpretar sus necesidades.

Es aquí donde surge el reto, de formarnos, de incorporar metodologías, estándares y mejores practicas como  TOGAF, COBIT, ISO, PMI,etc. que permitan a los Gerentes de proyecto de TICS, proponer proyectos de valor para sus compañías y llevarlos a buen termino.

Abstracción una sola palabra múltiples conceptos

Como exponía en mi entrada anterior, tenemos muchos conocimientos que creemos dominar, y en esta ocación me voy a referir a una de ellas, la "abstración". Y para nosotros los Profesionales de las tecnologías de la Información, esta palabrita si que es común y puede ser la responsable de grandes alegrías o tristezas, porque según su definición, nos deja la responsabilidad de conceptualizar y/o definir un problema. Según esto nuestras capacidades y conocimientos en metodologías  y técnicas  para el modelado de sistemas de información, se deben reforzar a tal punto que nos lleven a una adecuada abstracción de un problema.

Indagando más, le pregunte a papá Google y me entrego este interesante documento "La importancia de la abstracción en la informática",  [Ing. Edgar Serna M. ]del cual puedo concluir lo siguiente:

• No todos tenemos la misma capacidad para generar modelos y diseños Informáticos adecuados, esto depende de nuestra formación y conocimientos en las técnicas  matemáticas y/o de ingeniería.
• El nivel de abstracción debe incluir solo los detalles necesarios, con el cuidado de no omitir detalles que dejen el modelo incompleto, confuso o incomprensible.
• El Software en si es abstracto y requiere de habilidades de abstracción.
• Los planes curriculares de las universidades, deben incluir módulos que impliquen  utilizar la abstracción para explicar, modelar, especificar, razonar o resolver problemas.