Nicolas Bortolotti

Para este artículo la idea es trabajar con un estándar para el modelado de procesos de negocio, en el desarrollo de soluciones sabemos muy bien que es de vital importancia conocer el dominio del problema, lógicamente mientras más concreta sea esta actividad, simple, flexible y con opciones de ingreso al software, más nos acercamos a cumplir el objetivo del cliente. Bien, ahora para comenzar el desarrollo, la idea es analizar BPMN (Business Process Modeling Notation) provisto por la OMG (Object Management Group), no voy a desarrollar el estándar ya que el objetivo del articulo es ver una implementación, les dejo algunos vínculos para descargar información específica si es que lo requieren. http://www.bpmn.org/ http://www.omg.org/docs/formal/08-01-17.pdf Ahora les voy a presentar las herramientas de la demo: EA 7.0 Enterprise Architect BizAgi Process Modeler 1.3 En la primera de las opciones tendremos toda una suite de modelado en donde BPMN se compone de un profile que permite a la herr...

En este artículo les traigo un repaso sobre modelado, donde como eje central vamos a trabajar con diagramas de secuencia. Siempre es interesante un pequeño repaso para situarnos en tema, y para hablar de diagramas de secuencia vamos a hablar de UML, ya en v2.0 y de interacciones. Los diagramas de interacción de UML se pueden utilizar para modelar cualquier tipo de interacción entre instancias de clasificador. Existen 4 tipos de diagramas de interacción, cada uno de los cuales enfatiza un aspecto diferente de la interacción. Diagramas de secuencia Diagramas de comunicación Diagramas de visión de interacción Diagramas de tiempo En este segmento voy a trabajar sobre los diagramas de secuencia como les mencioné en el inicio del artículo, para ello voy a utilizar EA 7.0 como herramienta de modelado. "Los diagramas de secuencia muestran interacciones entre líneas de vida como una secuencia ordenada en el tiempo de eventos." Algo que me gustaría nombrar, es la diferencia de las secu...

Para este artículo me propuse analizar un segmento muy pequeño de las métricas que podemos obtener en el escenario de la ingeniería de software. Para este objetivo tenemos que tener claro que la medición es un elemento clave en cualquier proceso de ingeniería, las medidas se emplean para comprender mejor los atributos de los modelos que se elaboran y con esto se puede evaluar la calidad de los productos. Hay una discusión de varios autores sobre las medidas directas de varias ramas de la ingeniería en contraste con las medidas indirectas de la ingeniería de Software, para este punto voy a citar a Fenton: "La medición es el proceso mediante el cual se asignan números o símbolos a los atributos de entidades reales para definirlas de acuerdo con reglas claramente establecidas… En las ciencias físicas, la medicina y, más recientemente, las ciencias sociales, ahora podemos medir atributos que se consideraban imposibles de medir…Por supuesto, estas mediciones no tienen el mismo refinam...

En este artículo voy a analizar un material que me gustó y me hizo reflexionar sobre el concepto de arquitecto, cualidades y habilidades necesarias sobre el rol. Para comenzar voy a citar el material sobre el cual quiero reflexionar y de paso les recomiendo la lectura en su totalidad: http://msdn.microsoft.com/en-us/arcjournal/cc505974.aspx Autor: Joseph Hofstader "En proyectos de software, el título Arquitecto es a menudo definido de forma ambigua y el valor que brindan los arquitectos no se mide con facilidad" Este frase resume la actualidad sufrida en los actuales proyectos de ingenieria de software, incluso se torna muy complejo para las organizaciones encontrar el valor agregado por el concepto de arquitecto. La idea es encontrar como objetivo general el valor que los buenos arquitectos aportan a los procesos de desarrollo de software. ¿Les parece un buen objetivo? Algo de lo que debemos partir para esta discusión es una definición de un buen arquitecto, para este objeti...

En este articulo me pareció interesante repasar algunos principios de diseño desde la óptica de componentes, particularmente que son para mi punto de vista son "no negociables" en la ingenieria de software. Hay cuatro principios básicos de diseño aplicables al diseño al nivel de componentes y se han adoptado ampliamente cuando se aplica ingenieria de software orientada a objetos. La idea es lograr diseños que sean más sensibles al cambio y reducir la propagación de efectos secundarios cuando ocurren cambios. El objetivo del artículo es cubrir uno de los principios nombrados, "el principio abierto-cerrado (PAC)". ¿Qué dice este principio? "El componente de un módulo debe estar abierto para la extensión, pero cerrado para modificación" Para expresarlo de manera simple, el diseñador debe especificar el componente de manera que permita extenderlo (dentro del dominio funcional que atiende) sin necesidad de modificaciones internas al propio componente (al nivel ...

Decidí escribir este artículo para realizar un análisis sobre el desarrollo ágil, su definición, sus bases y definir que tan ágiles podemos ser en el desarrollo de una solución. El primer punto que voy a analizar es un interrogante, ¿Cuándo surgen las ideas sobre el desarrollo ágil? Este interrogante se responde de forma muy simple, las ideas sobre el desarrollo ágil han estado presentes por muchos años, pero no ha sido hasta la década pasada que se han cristalizado y consolidado en un "movimiento". En esencia, los métodos ágiles se desarrollaron en un intento por superar las debilidades advertidas y reales en la ingenieria de software convencional. El desarrollo ágil proporciona beneficios importantes, pero recuerden es imposible aplicarlo a todos los proyectos, productos, personas y situaciones. Bien, hasta este punto linda la introducción pero, es necesario, indispensable definir la ingenieria de software ágil, el concepto combina una filosofía y un conjunto de directrice...