Archive for the ‘MTR’ 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á…)

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.

Maquinas virtuales para probar multiples navegadores

jueves, octubre 11th, 2012

Microsoft elaboro una lista de máquinas virtuales para que los desarrolladores web puedan probar su sitio web bajo los distintos navegadores que hay existen en el mercado.

Aqui encontratraras la lista completa

https://www.microsoft.com/en-us/download/details.aspx?id=11575

Lo unico si, es que dependiendo de tu velocidad, debes armarte de paciencia para la descarga.

Workflow básico de documentación

jueves, agosto 16th, 2012

Recurrentemente se establecen formas de trabajar con la documentación debido a que tiene que pasar por una serie de aprobaciones antes de ver la luz. Para un grupo más bien pequeño, sin pensar en editores y editores de editores un workflow básico de documentación sería como el siguiente.

Workflow Básico

En el método de trabajo que tengo un cliente esta especificado con un acronimo de al menos tres letras (caracterizado aqui por CCC) al igual que un proyecto (aqui como PPP). Entonces un cliente tendría un documento con Titulo, más una version X, que es la que irá incrementando. Si es la primara version Y sería cero(0) por lo que no la establezco a menos que haya una modificación a posteriori.

El incremento de X es cuando existe la necesidad de generar otra versión debido a modificaciones o grandes adiciones que incrementen el documento, si solo son correcciones a lo ya existente entonces se incrementa sólo Y.

Recomendación para organizar carpetas de proyectos

jueves, abril 26th, 2012

En la suerte de método de trabajo que tengo, debo organizar los distintos proyectos que manejo, con las distintas empresas que existen dentro de mi ambiente, por lo cual decidí en un momento tener la carpetas «proyectos»… Suena inteligente ¿no?

Luego de crear la carpeta de proyectos, que es sólo para que no interfiera con las otras carpetas existentes dentro de windows (y linux) establesco el cliente, entiendase como a la empresa que estoy atendiendo, luego de lo cual establezco el nombre que internamente le ha dado la empresa al proyecto, que si no tiene, yo le asigno uno.

Entenderan que yo to lo veo como un proyecto, debido a lo cual cualquier cosa que se hace es en sí un proyecto en potencia… incluso licitaciones que nunca llegan a un destino optimo para mi reciben la distincion como proyecto.

Luego de que tengo creada una carpeta por cliente (o por amigo) con el cual estoy haciendo algo entonces me dedico a rescatar los proyectos, o sea, enumero con nombre cada proyecto con el cual trabajo para ese cliente… el ejemplo mas claro es donde estoy actualmente en donde existen un par de proyectos internos…

Ejemplo Carpeta Proyectos

Para mí existen la carpeta doc, donde dejo documentacion generada por mi, o que se me entrego para trabajar, en la carpeta infoIn dejo toda esa información que llega por correo y aqui estan los documentos originales, cuando me llegan para ser trabajados. Esta la carpeta modelo, con subcarpeta datos y uml, en general dejo los modelos proveídos por la herramientas que se usen para el proyecto. En la carpeta release, igualmente que por fecha (en formato AAAMMDD) guardo los release de desarrollo (dev) quality assurance (QA) y productivo (prod). y Finalmente mi carpeta de trabajo wks, con las subcarpetas de desarrollo wksDev, de QA wksQA y producción wksProd. En ellas trabajo los códigos y demás cosas relacionadas con el codigo fuente del proyecto.

Con esto a grandes rasgos, ordeno las carpetas y mis días. Este articulo es para que reflexiones que tu cabeza trabaja de una forma, de esa forma es la que debes buscar plasmar, porque en momentos complicados el preguntarse ¿donde deje el archivo? es super importante.