Un nuevo comienzo, no creo que es la mejor manera de empezar estas letras, pero creo que es la única manera de empezar un "blog", no voy a enfrascarme en el pasado pero si en mis días con y sin ti, en lo que pienso y siento en tu ausencia y durante nuestro tiempo juntos, por mas corto que sea. Así que por hoy empezare desde el principio de una nueva vida.
El día miércoles fue la audiencia de divorcio, pedí que me permitieran verte todos los días, ahora que tengo el tiempo por mi trabajo solicite cuidar yo de ti todas las tardes de entre semana, claro hasta la hora que llegue tu mama de su trabajo su horario es de 8am a 17h, pedí también que te manden a dormir conmigo un fin de semana saltando uno y que puedas venir conmigo una semana de vacaciones al año. Te cuento que todo esto me rechazaron, en cambio  me dieron tiempo contigo asignado, pedido de tu mama en el siguiente horario, martes y jueves de 1h30 a 17h00, y 1 sábado o un domingo alternado por semana, sin opción a dormir ni feriados ni vacaciones. 

No quiero que recientas a tu mama por lo que pide, ella te ama y siente que al darte mas tiempo conmigo te puede perder.

Hoy  debía ser nuestro primer sábado juntos en 1 mes y medio, 45 días sin que vengas conmigo y sin poderte llevar a ninguna actividad. Esta es mi frustración que a pesar de que ya esta sentenciado mientras no este ejecutoriada, tu mama no te va a  mandar, tal vez no sea la mejor forma de colocar esto en letras, y es mi frustración y la impotencia de no poderte ver y de no poder compartir contigo.

Al menos por este medio voy dejando plasmado mi sentir. Te amo mucho Agus.

nos vemos pronto.

¿Qué metodología debo usar para el desarrollo de un Software?

¿Qué metodología debo usar para el desarrollo de un Software?

Todos en algún momento nos hemos hecho esta pregunta, cuando hemos tenido que desarrollar un software. Y de hecho esta pregunta se torna muy importante, pues como arquitectos de Software, debemos tener un plano en que apoyarnos.

Todo desarrollo de software es riesgoso y difícil de controlar, pero si no llevamos una metodología de por medio, lo que obtenemos es clientes insatisfechos con el resultado y desarrolladores aún más insatisfechos.

Sin embargo, muchas veces no se toma en cuenta el utilizar una metodología adecuada, sobre todo cuando se trata de proyectos pequeños de dos o tres meses. Lo que se hace con este tipo de proyectos es separar rápidamente el aplicativo en procesos, cada proceso en funciones, y por cada función determinar un tiempo aproximado de desarrollo.

Cuando los proyectos que se van a desarrollar son de mayor envergadura, ahí si toma sentido el basarnos en una metodología de desarrollo, y empezamos a buscar cual sería la más apropiada para nuestro caso. Lo cierto es que muchas veces no encontramos la más adecuada y terminamos por hacer o diseñar nuestra propia metodología, algo que por supuesto no esta mal, siempre y cuando cumpla con el objetivo.

Muchas veces realizamos el diseño de nuestro software de manera rígida, con los requerimientos que el cliente nos solicitó, de tal manera que cuando el cliente en la etapa final (etapa de prueba), solicita un cambio se nos hace muy difícil realizarlo, pues si lo hacemos, altera muchas cosas que no habíamos previsto, y es justo éste, uno de los factores que ocasiona un atraso en el proyecto y por tanto la incomodidad del desarrollador por no cumplir con el cambio solicitado y el malestar por parte del cliente por no tomar en cuenta su pedido. Obviamente para evitar estos incidentes debemos haber llegado a un acuerdo formal con el cliente, al inicio del proyecto, de tal manera que cada cambio o modificación no perjudique al desarrollo del mismo.

Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas que dejaron de mencionar, recién en la etapa final del proyecto, pese a que se les mostró un prototipo del software en la etapa inicial del proyecto.

Los proyectos en problemas son los que salen del presupuesto, tienen importantes retrasos, o simplemente no cumplen con las expectativas del cliente.

Para dar una idea de qué metodología podemos utilizar y cual se adapta más a nuestro medio, mencionaré tres de ellas de las que considero las más importantes, tal como: RUP, XP y MSF.

Un breve analisis del documento vision. con enfoque a RUP

El documento Visión es el principal artefacto en el cual el análisis del problema  a solucionar.

Un  documento de visión es aquel en el cual se define el alcance de alto nivel y propósito de un programa, producto o proyecto. Es una declaración clara del problema, la solución propuesta, y las características de alto nivel de un producto  que ayudan a establecer las expectativas y reducir los riesgos de efecto del mismo.

“Muchas organizaciones capturar la visión de un "Documento de Visión", que generalmente contiene las necesidades del negocio y las características clave del sistema desde la perspectiva de los interesados​​. El documento de visión es simplemente un mecanismo para poner sobre el papel la idea” (http://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/articleType/ArticleView/articleId/334/What-is-a-Vision-Document.aspx).

Para el desarrollo de una visión el analista de produtos propietario o un negocio trabaja con las partes interesadas para desarrollar un documento de visión que define el ámbito de alto nivel y la finalidad del producto.

Una declaración clara del problema, la solución propuesta, y las características del producto de alto nivel ayuda a establecer las expectativas y reducir los riesgos.
En resumen este documento describe las siguientes actividades, que son coordinados por el analista para desarrollar la visión. Los StakeHolders proveen ​​aportaciones, revisiones y aprobaciones durante el proceso.

Estar de acuerdo con los StakeHolders en el problema que el producto va a resolver,  y en el alcance de la solución.

Hacer un bosquejo de solución que aborde los temas claves descritos en el problema.

Definir las características del producto de alto nivel.
Trazar las características del producto a las solicitudes de los StakeHolders.
Iniciar una revisión de la visión y las necesidades relacionadas de un conjunto diverso de partes interesadas, como los usuarios y accionistas de la empresa. Crear una línea base de los requisitos aprobados y el documento de visión.

Antes de desarrollar la visión, es necesario crear una infraestructura para su proyecto, instalar y configurar las herramientas, modificar el proceso y los informes para satisfacer las necesidades de la organización, añadir los miembros del equipo, asignar roles, y permitir el acceso a las áreas del proyecto.

El propietario de un producto o el analista de negocio debe identificar a los actores y el estudio del dominio del problema

Lo primero que se debe hacer es  Desarrollar un planteamiento del problema
Generar un acuerdo con las partes interesadas en el problema de que el producto va a resolver y el alcance de la solución.

Es necesario evaluar las necesidades de negocio y reunir las solicitudes los

StakeHolders.

     Crear una declaración clara del problema, que describe el propósito del producto o proyecto.

     Trabajar con las partes interesadas para revisar y perfeccionar el enunciado del problema.
     Añadir el enunciado del problema que el documento de visión.

     La segunda etapa consta en tratar de definir las características del producto usando las solicitudes  del enunciado del problema, la declaración de la solución, y las partes interesadas a las características del producto, y para esto necesitamos realizar análisis de la competencia.

    Necesitamos investigar recursos relacionados con el problema y su solución.
    Trazar los requisitos de cada una de las caracteristicas de alto nivel.
    Trazar las características  contra las solicitudes de los Stake Holders.

     Para que se pueda aprobar un documento de  visión es necesario iniciar una revisión del documento, sus  requerimientos y características, sus recurso de apoyo entre otros.

     Esta revisión tiene que incluir un conjunto diverso de StakeHolders, que van desde los usuarios a los accionistas de la empresa.

     Después de que la revisión se haya completado, los recursos aprovados servirán de base para la generación del documento  de visión.

Como Resultado tenemos que al completar esta tarea, se ha creado un documento de visión para registrar los objetivos de negocio y necesidades de los StakeHolders al  proporcionar una declaración del problema, una declaración de la solución, los requerimientos de alto nivel de cada una se sus características, y hemos trazado estas a las solicitudes de los StakeHolders.

Casos de Uso.- Los casos de Uso son una serie de escenarios que describen la intercaccion entre el usuario y el sistema. Un caso de Uso muestra las relaciones que existen entre actores y casos de uso, valiendo la redundancia.

Estos dos son los principales componentes de un caso de uso.

Un caso de uso viene a ser una vista externa del sistema que el usuario puede realizar en orden para completar una actividad propuesta, podríamos decir también que un caso de uso describe una secuencia de actividades entre el usuario y el sistema sin especificar la interface.

Para poder describir un caso de uso es necesario describir los pasos en un lenguaje simple y entendible. Esto alienta a los miembros del equipo para participar activamente en la definición de los requerimientos.

Kenworthy señala ocho pasos para el desarrollo de casos de uso

         

1.      Identificar quien esta ocupando el sistema

2.      Escoger uno de esos usuarios.

3.      Definir lo que ese usuario va a realizar en el sistema. Cada cosa que hace el usuario se convierte en un caso de uso.

4.      Para cada caso de uso se define el curso normal de eventos cuando el usuario se en encuentra en el sistema

5.      Describir el curso básico  en la descripción para el caso de uso; describir en términos de lo que hace el usuario en el sistema y lo que el sistema  hace en respuesta que el usuario debe tener en cuenta.

6.      Cuando el curso básico se describe considerar cursos alternativos de eventos y añadir los respectivos extender’s al caso de uso.

7.      Busque por similitudes entre los diferentes casos de uso, extraiga estos y anótelos como casos de uso de curso común

8.      Repetir los pasos del 2 al 7 para todo el resto de actores

Referencias

Ibm  <ftp://public.dhe.ibm.com/software/rational/web/datasheets/RUP_DS.pdf>

Malmö University

<http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_vsion.htm>

The Rational Unified Proces made Easy  Foreword_by: Grady Broch

<http://books.google.com/books?id=7FSf5661dfMC&pg=PT134&dq=rup+%22vision+document%22&hl=es&ei=TP3_TZX8Nebb0QHWo9SWDg&sa=X&oi=book_result&ct=result&resnum=4&sqi=2&ved=0CEEQ6AEwAw#v=onepage&q=rup%20%22vision%20document%22&f=false >

Software development for small-teams Foreword by: Philippe Kruchten

<http://books.google.com/books?id=sqNQJ6vi5aIC&pg=PA58&dq=rup+vision&hl=es&ei=Lf3_TYyEGKbr0gGX7fTNDg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDAQ6AEwAA#v=onepage&q=rup%20vision&f=false>

Kenworthy, E. (1997). Use case modeling: Capturing user requirements.

Herramienta para Diagramas de secuencia

Hoy me cansé de las herramientas pussy (aka ide-all-in-one-use-just-the-mouse) y comencé a utilizar una herramienta a lo menos poco usual, pues consiste en que el diagrama de secuencia lo programas, es decir, escribes la logica del diagrama y la herramienta se encarga generar la gráfica :) con eso me olvidé de esos problemas malditos de 'quedó un poco corrido', 'quedo desalineado', etc..

Una muestra del primer diagrama que hice y me tomó solamente unos 10 minutos, entre cranearme la lógica del diagrama de secuencias y aprender la sintaxis (que por cierto un muy pequeña)
con el siguiente script

Usuario:Actor
x:Buscar_Articulo ":Administrador/Encargado"
y:y ":Control Produco"
z:z ":Datos"
a:a ":Producto"
b:b ":Gestor_Compra"
c:c ":Cliente"
d:d "Factura"

Usuario:x.1 Ingresar sistema
x:5 producto=y.2 Buscar Producto
y:4 Producto =a.3 Escoger Producto
x:a.6 seleccionar Producto
a:b. 7 Genera Compra
b:9 datos cliente=c. 8 Consulta Clienta
b:z.10 datos cliente
x:z.11 si cliete== vacio[autenticar cliente] 
z:c. 12 Nuevo Cliente
c:d. 13 Realizar Compra
x:b. 14 si cliente es != vacio[relizar compra]
b:d. 15 Nueva compra

Definitivamente una herramienta que apunta a la productividad.

100% recomendada, el sitio de la herramienta es: http://sdedit.sourceforge.net