Archive for the ‘Capacitacion’ Category

Comprendiendo la necesidad del versionamiento (2)

miércoles, marzo 27th, 2013

El proceso

Inicialmente existe uno o varios requerimientos que deben ser agrupados por el usuario o jefe de un proyecto (quien es el encargado de dar la prioridad a las necesidades del usuario). Ahí define la funcionalidad que uno o un grupo de requerimientos genera, y le encarga la tarea a un desarrollador.

El desarrollador debiese descargar la ultima version de desarrollo, generar los cambios de uno o más archivos, y comprometer al repositorio de codigo con alguna forma identificadora de la funcionalidad.

sc0000

Con esto el desarrollador hace su liberación.

La persona encargada de QA debe descargar un copia de la ultima version de produccion, compila, ejecuta, hace las pruebas y da su veredicto. si la aprueba, se genera una version QA con la funcionalidad, sino, se devuelve al desarrollador.

sc0002

Finalmente el encargado de generar el release, segun la planificcion o roadmap de la aplicacion se da el momento de fusionar todas las funcionalidades liberadas y que existan en QA ya probadas y liberadas. Esta construccion debiese ser limpia debido a que las funcionalidades no son dependientes unas de otras, eso es la idea que se transmitió al principio.

Con lo cual se tiene mas o menos lo siguiente

sc0003

Comprendiendo la necesidad del versionamiento

miércoles, marzo 27th, 2013

En muchos momentos he tenido que hacer entender a gente no informática que existe la necesidad de versionar lo que hacemos como proyecto debido a que de un punto al siguiente existen avances, y por ende modificaciones al original. Por lo tanto un ‘artefacto’ evoluciona a través del tiempo para perfeccionarse y llegar a ver la luz como el requerimiento que fue solicitado.

El problema me ocurre también con gente que si es informática, o sea, tampoco entienden porque existe esta necesidad y ven que es sólo una pérdida de tiempo. Aquí va una manito…

La situación

En general el desarrollador crea una version un archivo de código fuente de desarrollo, que luego debe ser probada por otros para asegurar la calidad (QA, de Quality Assurance) y ellos a su vez dan el paso a producción, algo más o menos así(perdon el dibujo a mano, pero carezco de tiempo, y me es más rápido así):

IMG_0009

Ahora bien, existen distintos tipos de modificaciones dentro de desarrollo: nuevos desarrollos, optimizaciones, correcciones de errores, etc. Todos atacan alguna funcionalidad específica. Lo que hay que tener claro es que el desarrollador programa una funcionalidad y una funcionalidad puede estar compuesta de más de un requerimiento que para el caso de la funcionalidad son indivisibles. Algo que se puede representar asi:

sc0001

Hay que tener cuidado en definir entonces los requerimientos y funcionalidades, en el primer caso no todo es indivisible, ya que 2 requerimientos pueden ser muy cercanos lo que no necesariamente los hace inidivisibles, quizas los puede hacer dependientes pero no indivisible, por ejemplo para calcular un bono de reconocimiento en Chile (un instrumento financiero) es necesario calcular la UF, el calculo de la UF es un requerimiento del cuan el calculo del bono depende, pero el calculo de la UF puede ser vista de forma independiente del calculo del bono.

Entonces, cuando un desarrollador termina una funcionalidad, recien entonces esa funcionalidad puede ‘pasarse’ a QA para que la revise. Este ‘pasarse’ implica pasar todos los archivos de codigo, scripts y configuraciones necesarias para la correcta ejecucion de la funcionalidad. QA lo revisa, lo acepta o lo rechaza, si lo acepta la funcionalidad, o sea, todos los archivos y configuraciones necesarias quedan a la espera de ser fusionadas con la version de produccion para generar un release productivo.

Si lo rechaza es otro cuento, debido a que la funcionalidad se ‘saca’ de la version de QA y no pasara al release, es aqui donde se debe poseer un proceso adecuado para que no se ‘ensucien’ las liberaciones de las funcionalidades junto con otras, este control es el que debe ser cuidadoso. Es aqui donde aparece el control de versiones y el proceso de versionamiento de software.

(Continuará…)

¿Porqué SOA?

viernes, enero 4th, 2013

Yo creo que SOA más que una evolución natural de las TI fue una necesidad. Muchos alumnos me preguntan más de una vez porque las empresas tienen distintos sistemas para lo mismo, bases de datos de clientes no consolidadas, cosas en donde la teoría nos indica que esta mal pensado o mal construido.

La verdad es que los negocios se mueven por si solos, y obligan a que la tecnología se adapte. O sea, muchas veces cuando una multinacional llega a un pais elige a una o mas empresas para comprar, cada una de las cuales tiene lineamientos TI distintos, lo que implica que luego de la compra hay que proveer recursos para fusionar bases de datos, eliminar productos por el licenciamiento, etc.

SOA aqui llega como ayuda para que todas estas integraciones puedan provocarse, para TI el argumento debe ir por

Reuso. O sea, crear nuevos procesos de forma rápida.
Composición. La capacidad de alterar un proceso de negocio de forma rapida y rentable.
La capacidad de cambiar un sistema incrementalmente. Cambiar de proveedores, extender servicios, modificar proveedores y consumidores de servicios.
La capacidad de construir un sistema incrementalmente. Esta es una de las bondades de SOA.

Pero quiero ir más alla, creo que convencer a TI no es lo díficil, sino que en un plano gerencial, responder a la pregunta ¿porque SOA? no tiene los mismos argumentos, pero si la misma raíz.

Reducción de costos en el desarrollo de sistemas. Si la empresa se orienta a los servicios una de las primeras cosas que debe definir son los datos empresariales, obligando a la empresa a conocerse a si misma. Lo que provoca un estudio de los procesos de negocio. Teniendo esto como base, la inserción de un nuevo sistema será con un menor costo, ya que los procesos serán conocidos y las estructuras también

Reducción del ‘Time to market’. El reuso de servicios empresariales, además de la reutilización de las entidades empresariales (o datos de empresa) reducen el tiempo de desarrollo de un nuevo sistema, debido a que este se adhiere a las normativas creadas, pero además reutiliza servicios se negocio o procesos de negocio, logrando una sinergía de sistemas.

Procesos de negocio adaptable a cambios. Uno de los aplicativos muy ligados a SOA son los BPM (Bussiness Process Modeler), para quienes hemos trabajado con estas herramientas, la posibilidad de tener un repositorio de servicios granular posibilita la construcción de procesos de negocio de forma rápida es más cercana cuando existe una implantación de SOA bien manejada. Además de una creación rápida, las modificaciones son tanto más rapidas que permite una mejor adaptación a los negocios.

Mejora en la experiencia del Cliente. El tener mejores procesos, poder tener la capacidad de ofrecer servicios multicanal, debido a la reutilización tecnológica, cae a través del tiempo en una mejor percepción de los clientes a los cuales está focalizado el servicio.

Ahora bien, para implantar SOA debes seguir ciertos pasos. No esperes pasar de un día para otro a SOA si no existen definiciones de negocio claras, creo que el primer paso de una empresa es conocerse a sí misma (en cuanto a datos y procesos) antes de querer hacer algo.

Gestion del tiempo

viernes, enero 4th, 2013

Es importante para cada uno ver como ocupa el tiempo, más si estas en ingenierías donde el tiempo es un bien escaso. Bien es cierto que por mi parte utilizo conceptos de PSP (Personal Software Process) para gestionar mi tiempo, existen personas que hacen mucho más que yo y el tiempo les alcanza y les sobra.

Por lo mismo es interesante compartir un articulo (una traducción) de Martin Marsavsky que es un inversor en nuevas tecnologías además de dirigir más de una compañía… lo ideal es que solo trabaja de 9 a 14hrs.

Ser o no ser Arquitecto de Software

miércoles, octubre 24th, 2012

¿De que se habla cuando se dice Arquitectura de Software?
¿Por que se necesita?
Al punto que una jefa de recurso humanos de una compañía de desarollo de Software me hizo derechamente la pregunta ¿Porque necesitamos un arquitecto? cuando le presente mi cargo como «Arquitecto»… aun cuando creo que ella inicialmente pensó en construcción y no en software.

La verdad es que de vez en cuando veo una tras otra definicion, algunas de las cuales no me hacen más que reír, y otras reflexionar. Dentro de esta última un articulo interesante es ¿Quién necesita un arquitecto?.

Con esto quiero comenzar una serie de artículos relacionados a la arquitectura de software, que es lo que es, y como se relaciona el arquitecto con el desarrollo de aplicaciones.

Templates para documentación UML

martes, octubre 2nd, 2012

UML es una notación, no es en si un proceso de desarrollo de software, para ello existe RUP (Rational Unified Process) el cual presenta los pasos a seguir en la creación del sistema propieamente tal. La forma de documentar RUP es a través de lo que la metodología denomina artefactos (un documento es un artefacto dentro de la metodología, pero no es el único atefacto, los diagramas tambien lo son), un conjunto completo de plantillas se pueden encontrar aqui.

Este zip esta completamente explicado en el sitio.