Es necesario entonces contar con una aproximación sistemática sobre como disponer los flujos de eventos principal y alternativos, de forma que capturen en forma clara y precisa cada condición que el flujo del día feliz ha asumido como libre de error pero que es a su vez, el punto de inicio de un flujo alternativo.

La idea aquí es la de indicar el paso del flujo principal y la condición precisa que de violarse hace que se ejecute el flujo alternativo. De ser posible la condición ha de estar expresada en términos del modelo de dominio de forma tal que facilitar su traducción al sistema software.

Los pasos del flujo alternativo han de tener una enumeración propia de forma tal que no choquen los unos con los otros ni con los pasos del flujo principal. La forma exacta en que vamos a enumerar es cosa de cada quien, por lo que es un punto a documentar como parte del Plan de Gestión de Requisitos, documento este que suele ser parte del Plan de Desarrollo de Software.

Un ejemplo de todo lo anterior puede ser visto como parte del ejemplo de caso de uso en este blog. En el ejemplo referido se hace mención al caso de uso "llamada de voz" y se ha señalado la condición de error "número incorrecto". Veamos una versión ligeramente modificada del caso de uso de ejemplo para discutir como se puede implementar los flujos alternativos:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Diagrama:

Flujo Principal:
Paso 1 - Usuario: Levanta el auricular.
Paso 2 - Sistema: Da el tono de marcado.
Paso 3 - Usuario: Indica el número de teléfono.
Paso 4 - Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 - Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 - Sistema: Termina la conexión.

Flujo alternativo: Número incorrecto
Paso 3 - Sistema: Presenta tono de error. El caso de uso termina.

Flujo alternativo: Desconexión inesperada
Paso 5.1 - Sistema: Detecta un fin inesperado de la conexión. Indica todo de error.
Paso 5.2 - Usuario: Tranca el teléfono.
Paso 5.3 - Sistema: Registra error. El caso de uso termina.

Tabla 1 - Ejemplo de caso de uso con flujos alternativos

Como ya dije, este ejemplo es una modificación del ya visto en el post ejemplo de caso de uso, donde ahora se han considerado dos flujos alternativos, uno para la condición de número incorrecto y otro para la desconexión inesperada.

La condición ha sido indicada en términos abstractos, comprensibles desde una perspectiva técnica y luego se ha indicado el paso en que dicha condición se puede violentar. En el flujo alternativo del número incorrecto el paso es el tres y en caso de problemas las acciones a tomar son solo una: el sistema presenta tono de error.

Otro tanto puede ser dicho en el segundo flujo alternativo. La desconexión inesperada sin embargo a dado lugar a tres pasos. El sistema detecta un fin inesperado e indica tono de error. El usuario entonces tranca el teléfono. Finalmente el sistema registra el error. Estos tres pasos han sido enumerados con la secuencia 5.1, 5.2 y 5.3, de forma de hacer referencia a que son un flujo alternativo del paso cinco del flujo principal al tiempo de mantener una secuencia numerica propia.

Para obter a versão completa deste trabalho CLIQUE AQUI e AQUI TAMBÉM .

Day by day the research concerning Software Factories has increased, especially due to recent term growth in the worldwide scene. Indian and Chinese Factories had become quality and success reference, making countries like Brazil came to pursue a similar model that it has been able to manage multiple discussion operations. Operating an exigent and extremely dynamic market which the ideal balance between costs and quality impose the success at business world, the productivity has started to be a basic aspect for any organization survival. However, to reach this standard, it must be clear factors as processes, quality standards and manufacture solutions frameworks intervene directly with the final result. From this point of view, this technician-scientific paper presents a study of this software production model, making a literature revision of the structure and three basic models for its implantation: RUP - unified process, CMMI and PMBOK. Thus, it´s going to discuss about involved characteristics and make a more effective software operation pondering cost, business value increasing, quality, support forecasting and efficacy problem solutions, or better, it´s going to show a model which condenses the main parts of three models study; through mapping of the main software processes existents in software factories operation.

Download the complete version: CLICK HERE and HERE TOO .

Si pensamos un poco en el tema nos podemos percatar que la funcionalidad promedio de un caso de uso ha de tener bifurcaciones e incluso bucles. Esto es natural pensarlo ya que hay una similitud muy fuerte entre la noción de algoritmo y la de flujo de eventos vistos estos como listado de pasos.

Sin embargo, a diferencia de las notaciones formales utilizadas para expresar algoritmos, los flujos de eventos se construyen en lenguaje natural, lo cual impone limitaciones sobre cuan precisamente podemos indicar condiciones y bifurcaciones sin comprometer la claridad.

La solución a este problema claro esta, es la de tener más de un flujo de eventos. Tendremos uno sencillo y claro, que exprese lo que ha de ocurrir en el caso más probable y a su vez, tendremos otros flujos alternativos que lidien con las condiciones de error o casos que requieran bifurcación.

Al flujo de eventos principal, ese que contiene el caso más probable, se le llama Flujo de Eventos del Día Feliz, como forma de hacer referencia a la ausencia de condiciones de error. En otras palabras, le llamamos día feliz ya que en este flujo de eventos principal vamos a asumir que todo ocurre de la mejor forma: el actor tiene disponible la información y la indica sin fallas, el sistema puede completar todas las operaciones y así sucesivamente para cada posible desviación. En el flujo del día feliz simplemente todo ocurre correctamente.

El documento de cierre de iteración es una presentación de las actividades realizadas, los recursos dedicados, los hitos, los riesgos concretados, así como cualquier otro evento o información de la que queramos dejar constancia.

He de comentar que el Cierre de Iteración que presento aquí tiene una característica adicional: el control de evaluación de los artefactos. La idea es que en el Plan de Aseguramiento de Calidad se indiquen los criterios que deben ser evaluados en cada artefacto, para que luego entre el Plan de Iteración y el Cierre de Iteración se siga la pista de la evolución de estas calificaciones.

Es una característica un poco engorrosa, pero si se cuenta con recursos para mantener un equipo de control de calidad entonces se va a poder llevar a cabo este control, con miras a mejorar la ejecución del proyecto en su conjunto.

En cualquier caso, acá esta la plantilla del artefacto Cierre de Iteración:

Cierre de Iteración (en PDF)

Cierre de Iteración (en iScribd)

Si la inconformidad es muy grave y compromete la aceptación del producto por parte del cliente, es necesario dedicar esfuerzos adicionales en lograr que el producto sea conforme a lo especificado. A este esfuerzo adicional es a lo que llamamos retrabajo.

Técnicamente como para el glosario:

Inconformidad. Fallo de calidad definido como la desviación del producto de su especificación.

Y también:

Retrabajo. Esfuerzo adicional necesario para la corrección de una inconformidad en algún producto.

El problema que surge con el retrabajo es obvio: es un esfuerzo adicional que no puede en buena lid ser cobrado al cliente, pero que es necesario para que este quede conforme con lo que hemos hecho para él. La idea es entonces minimizar la cantidad de retrabajo en el que incurramos, objetivo deseado pero dificil de lograr sin un adecuado sistema de gestión de calidad.

Esta situación nos obliga a luchar por dos atributos básicos en todo nuestro sistema de requisitos: la claridad y la precisión.

Precisión de un requisito. Un requisito es preciso cuando indica sin ambigüedad lo que se desea especificar. Debe ir directo al punto y evitar todo adorno en el lenguaje. Debe documentar solo un aspecto del sistema y lo debe de hacer en forma exacta.

Y también

Claridad o legibilidad de un requisito. Un requisito es legible cuando el lenguaje en el que esta escrito es fácil de entender, tanto por los clientes como los analistas. La legibilidad se extiende no solo a la especificación escrita, sino también a los formalismos gráficos como los diagramas de casos de uso.

Es curioso observar que en los cursos universitarios sobre el tema, los profesores tengan la presión de explicar métodos y técnicas avanzadas, como las relaciones de extensión e inclusión de casos de uso, forzando al estudiante a adoptar estar técnicas en forma demasiado temprana. Esto causa una deformación profesional en el estudiante, quien sale del curso con la creencia que es mejor una especificación sofisticada que haga uso de todo lo visto en el curso, en lugar de una aproximación más informal y relajada que puede en verdad ser entendida por el cliente.

El lugar correcto para la extensión y la inclusión, así como para todas las técnicas de modelado de requisitos más sofisticadas, es en aquellos dominios de aplicación donde los requisitos reales sean muy complejos. Es decir por lo tanto, que en la práctica el analista ha de hacer esfuerzos por mantenerse sencillo, normalmente no vale la pena la complejidad del modelo de requisitos.

También es de hacer notar, que en mi experiencia la mayoría de los clientes intentan hacer otro tanto. Ellos suelen expresar lo que necesitan en la forma más directa que tienen disponible, sin embargo dado que los clientes son a su vez profesionales en un área especifica, la forma correcta en la ellos se expresan suponen tensión a los desarrolladores, quienes deben luchar por desarrollar un vocabulario común con el cliente para poder comprender sin errores lo que este pide.

En conclusión: lo sencillo se entiende más y la especificación de un sistema ha de entenderse bien. Cuan sofisticado hagamos nuestro modelo de casos de uso o nuestro documento de especificación, no es ni de lejos lo que en verdad importa. Es mucho mejor un caso de uso sencillo pero que captura valor de negocio, que uno sofisticado que haga un uso abundante de las técnicas más esotericas de modelado.

Библиотека документов IBM Rational (рус.)
Библиотека документов IBM Rational (англ.)

El diagrama de clases puede ser utilizado para presentar la vista estática del modelo de dominio, del modelo de diseño, o bien, del detalle de la implementación de un sistema en un lenguaje de programación orientado a objeto, como Eiffel, Java o C++. Para todos estos usos, lo que se desea es expresar las unidades en que el código se organiza -las clases- así como algunas características de estas, notablemente como dije antes, sus relaciones, atributos y métodos.

Es valido combinar los diagramas de clase con paquetes, dando lugar a un diagrama que muestra simultáneamente clases y paquetes. Dicha práctica ayuda a documentar elementos que estén en distintos paquetes pero que guarden alguna relación, aún cuando la especificación de UML habla de diagramas de tipos diferentes para los paquetes y las clases.

En este blog se encuentran muchos ejemplos de diagramas de clase, ya que se han incluido en los post que lo requieren como parte del asunto tratado. Algunos de estos son:

• "Modelo de Dominio" donde se utiliza un diagrama de clases para expresar el modelo inicial.
• "Tipos de diagramas de UML" donde se utiliza un diagrama de clases para decir cuales tipos de diagramas existen en UML y la forma en que estos se encuentran clasificados.
• "Diagrama de definición de elemento" donde un diagrama de clases tomado del metamodelo de UML ilustra los conceptos elemento y relación de UML.

Por lo anterior, si se queiren ver ejemplos de un diagrama de clases, basta con dar un paseo por el blog, seguro encontrará muchos ejemplos apropiados.

Como ejemplo de lo anterior podemos tomar el diagrama UML::Classes::Kernel::Root, parte del metamodelo de UML, en el cual se describe la noción de Elemento, en termino de sus relaciones con otros conceptos. Dicha descripción se presenta como un diagrama de clases convencional.

Fig. 1 - Descripción del concepto "Elemento" de UML
(Diagrama UML::Classes::Kernel::Root del metamodelo de UML)

Esta forma de definir los conceptos del lenguaje UML recurriendo a los propios mecanismos del lenguaje es conocido como Metamodelado y es uno de los puntos fuertes del lenguaje UML. Ahora, con el diagrama en mano, podemos ver los detalles del concepto de elemento simplemente leyendo las relaciones presentadas en el diagrama.

Por ejemplo, se deja ver en el diagrama que:

• Un elemento puede tener cualquier número de comentarios. Cero, uno o más.
• Un elemento puede o no, tener un dueño. En caso que lo tenga será único.
• Un elemento puede ser dueño de cualquier número de elementos.
• Las relaciones y comentarios son elementos a su vez.
• Las relaciones tienen un tipo especializado: las relaciones dirigidas. Estas tienen un elemento de origen y otro de destino.
• El origen y el destino de una relación dirigida puede ser el mismo elemento.

Entre otros posibles puntos mostrados en el gráfico.

I think it was the best UK Rational event for a long time, and there were some great speakers. Unfortunately the chairs were uncomfortable, some of the rooms too small and the venue would do well to invest in some air conditioning. I suspect that going to an event at the Royal College of Phyicians in the height of summer (assuming we ever have one in this country again) would be enough cause to need a doctor. Regardless of that, and the amount of walking up and down stairs I did, I think it was a great event. The buzz was mainly about the Jazz platform and associated tools (RTC, RQM, RRC).

Day 1

The conference was opened by Graham Spittle (IBM SWG UKISA VP) and Danny Sabbah (IBM Rational Worldwide VP) who set the scene well for Erich Gamma (in real life) and Grady Booch (in Second Life). Unfortunately the Second Life link went belly up and we did't get all of Grady's keynote. Which must have been extremely annoying for Grady since it was 3:30am for him! Erich then took over and gave an excellent Rational Team Concert demo (RTC). When he started his demo I was a bit worried he was going to cover all of my planned demo too, but fortunately it didn't overlap completely. Since he did the Monday keynote and I did the last slot on Tuesday there was enough time and quantity of information for the delegates so a little overlap didn't hurt. Erich also did a panel discussion on Agile development in the context of Geographically Distributed Development along with Scott Ambler and Julian Holmes moderated by Anthony Kesterton.

The great TQ (Terry Quatrani) was also present speaking on Agile Modelling, I had a meeting to attend so unfortunately didn't get to see her speak which is a shame because she's always great. I did speak to people that did go who just confirmed that I'd have rather gone than have a meeting!

Following the break it was then time for me to speak along with Linda Weedon of PwC and Matt Archer (also of IJI) on "CUPID - Implementing the IBM Rational Unified Process at PricewaterhouseCoopers" which is all about our experiences in deploying UP using a practice based approach. I think the session went really well, we had some pertinent questions which is always a good sign of people staying awake and listening :P To close the day Ian Spence gave an excellent (as usual) talk on "Conversations in Context: Using Use Cases on Agile Projects". Following an excellent dinner and a few glasses of wine kindly provided by a competitor it was time to commute home and eventually get to sleep at around 1am. It's much easier at conferences when you're staying at or really close to the venue! During the dinner there was a caricature artist or two wondering around who came to our table. Naturally we volunteered Ian to be caricatured and I managed to take a quick pic with my phone of him with his Mad Scientist caricature.

It's a little known fact that Ian is also a Kung Fu master which is why his hand appears blurred in this pic. Fractions of a second later my phone was whisked from my hand at the speed of lightening.

Day 2

Day 2 was for some peculiar reason started 30mins earlier than day 1. This didn't impress me, especially since like most people I hadn't noticed until I was texted while on the train on the way in. Fortunately I was early enough anyway to get there on time. Mike O'Rourke opened the day with some description of the Rational 2.0 Roadmap (Jazz and future products). Rumours were confirmed about Rational Project Management and Rational Enterprise Reporting being released Q1 next year.

Ivar Jacobson then gave an excellent keynote on "Back to basics: Getting Good Software Quickly and at Low Cost" which focussed on using practices in a smart way, not following processes. I've seen Ivar speak many times, and many times on practice based development, which isn't that surprising since I work for him but it's always entertaining to hear the man speak.

I also had some meetings on Day 2 but the sessions that really stood out for me were Peter Eeles talking on "The Rise of the Development Environment Architect" which was based on his paper on DevelopWorks. This is an excellent formalisation of something that has been part of my job for some time. I also enjoyed Derek Holt's talk on "RTC and the Agile Development Strategy".

Finally to wrap up Day 2 I presented on own this time on "Live Jazz: Process Execution in IBM Rational Team Concert". This started off with a demo of EssWork in Eclipse, shell sharing with RTC and creating a new process by composing practices as described in Ivar's slideware at morning keynote. I then started executing my new process in RTC. It was the end of a long two days in a really hot room so I kept it quite light and I think it went well - and hopefully the audience got something different and new from the talk. If you are now kicking yourself that you missed this talk, fear not I'll be repeating most of it as part of a webinar I'm doing in October - more details here.

Thanks to all those who attended my talks and came and said hello, especially those that read the Mac Daddy! :D I'll post the slides in a few days :)

La mayor parte de las visitas (son muy pocas todavía) que entran al blog buscan información sobre metodologías de desarrollo de software (podeis ver mi opinión sobre el tema en este post). Hoy contaré cuales han sido algunas de mis fuentes. Os facilito unos cuantos enlaces y lecturas que a mí me han resultado útiles:

RUP (Rational Unified Process) y UML (Unified Model Language)

Mis aprendizajes sobre RUP y UML se basaron en dos libros, estos son los títulos:

•  Unified Modeling Language User Guide
• The Unified Software Development Process

 Los dos son de los mismos autores, los padres de UML y RUP: Ivar Jacobson, Grady Booch y James Rumbaugh. Y los dos son de 1999, ya ha llovido desde entonces, RUP ha evolucionado y creo que también hay libros más adecuados, pero las bases de UML y RUP pueden verse en estos dos títulos. En la web, yo buscaría en los white papers y red books de IBM, podeis usar este enlace:  http://www.google.es/search?hl=es&q=rup+redbook+site%3Aibm.com&btnG=Buscar&meta=MSF (Microsoft Solution Framework)

Sobre MSF en el Download Center de la web de Microsoft, podéis encontrar todo sobre MSF: http://www.microsoft.com/downloads/results.aspx?pocId=&freetext=MSF&DisplayLang=en

Las dos últimas versiones son "MSF for Agile Software Development" y "MSF for CMMI", cada una con orientaciones diferentes, pero ni mucho menos puede decirse que la versión anterior a estas dos (MSF v3), esté ya caduca, es muy recomendable también su lectura y, por qué no, su aplicación, quizás MSF v3 se adapte mejor a tu equipo…

SCRUM

Para Scrum, esta es la página que visitaría, www.controlchaos.com, con cuidado de no tomarlo de un modo ortdoxo..

LEAN

Para aprender Lean, os puedo recomendar que leais "Lean Thinking" de James P. Womack y Daniel T. Jones. En internet, podeis visitar www.lean.org, y la versión de Lean aplicada al desarrollo de software que propone Poppendieck http://www.poppendieck.com/

Métrica

Los manuales de métrica pueden descargarse de la web del Consejo Superior de Informática, un organismo dependiente de la administración española, esta es la página: www.csi.map.es/csi/metrica3/index.html

Six Sigma

No os puedo dar una buena referencia sobre Six Sigma, por suerte para mi pude contar con los manuales de una empresa que aplica Six Sigma, y nunca me preocupé demasiado buscando por internet.

Acabo con algunas consideraciones que deben estar por encima de la metodología que utilicemos. Si no sois nuevos desarrollando software, posiblemente no sean más que obviedades, pero si no llevais mucho tiempo, quizás os convenga leerlas.

• Las metodologías no solucionan problemas, los problemas los solucionamos las personas. Está bien contar con un método que normalice el trabajo y sirva como guía, pero no hay una relación directa entre utilizar determinada metodología y tener éxito en un proyecto.
• Una comunicación correcta es fundamental. Durante el proceso de desarrollo de software generaremos mucha documentación dirigida a distintas personas con distintos roles. Es vital utilizar un lenguaje y un nivel de detalle adecuado para cada persona. Antes de empezar a elaborar cualquier documento, debemos pensar para quien estamos escribiendo.
• La utilización de una metodología es un medio, no un objetivo. El objetivo será mejorar determinado proceso de negocio, y nuestra solución debe cumplir este requisito, hacerlo bajo cierto método es un solo un aspecto secundario.
• Trabajar con una aplicación informática que nos permita gestionar  todo el proceso desarrollo de software, es fundamental para tener control sobre lo que estamos haciendo. Los informáticos somos un ejemplo constante de que "en casa del herrero, cuchillo de palo". Nos vamos apañando para las tareas de gestión del área con Excel y Project, sin embargo nos escandalizamos cuando uno de nuestros clientes ( no técnico) hace lo mismo con sus procesos de negocio.
• Contar conocimientos de varias metodologías es positivo. Como en todos los órdenes de la vida, cuanto más conocimientos tengamos, más recursos tendremos y más aportaciones podremos hacer. Posturas anti (ej.: AntiMicrosoft, AntiLinux,…) no aportan nada. No olvidemos que hablamos de tecnologías de la información y no de política o religión.

Acabo con una pregunta, ¿cómo lo veis vosotros? ¿Por donde irá el mercado en el futuro?

Al ente externo le llamamos actor por cuanto un caso de uso puede ser visto también como un guión, que a la manera de los guiones de una obra de teatro, dice paso a paso lo que el actor ha de hacer.

Es mucho lo que podemos decir de un caso de uso: nombre, descripción, pre condiciones, etc. Sin embargo, el aspecto más interesante de un caso de uso luego de la descripción del mismo es sin duda el flujo de eventos.

Al flujo de eventos lo podemos relacionar con un dialogo. Línea a línea, el flujo de eventos indica quien habla y qué dice. La secuencia se suele iniciar con algo dicho por el actor, y se continua intercalando sucesivamente lo hecho por el sistema con lo dicho por el actor. A cada una de estas líneas o indicaciones, le podemos llamar paso.

Un buen flujo de eventos recoge con detalle la identidad de quien realiza el paso, expresando sin ambigüedad la acción realizada. Es decir, que un buen paso ha de ser siempre una oración con sentido completo, escrita en voz activa, iniciando con el nombre del actor o bien del sistema que realiza la acción e indicando exhaustivamente los elementos de información que se intercambian.

Dichas oraciones con sentido completo, sin ambigüedad y demás características ya mencionadas, no son difíciles de redactar. Son de hecho la forma más directa de decir lo que hay que decir. Y es que a la hora de redactar un flujo de eventos debemos evitar recurrir a formas de redacción en prosa típicas de nuestros textos comunes. No vale sustituir el nombre del actor por un pronombre o demostrativo que le haga referencia. A la larga, dicha omisión del nombre del actor va a ser una fuente de ambigüedad y nos puede traer problemas.

Si bien para quienes acostumbran a redactar con estilo, estas normas para los flujos de eventos pueden sonar extrañas, son normas muy comunes para cuando queremos redactar documentos de requisitos. Básicamente estamos aplicando aquí los mismos consejos que se dan para redactar bien un requisito tradicional, del estilo "el sistema debe..." por lo que en Internet abundan los detalles sobre este particular.

Finalmente, la prosa tiene su refugio en la descripción breve de un caso de uso; y dado que es esta descripción breve la parte más importante del caso de uso, podemos decir que a la final todos vamos a poder estar contentos. Quienes quieren una redacción con estilo van a encontrar lo que buscan en la descripción breve y quienes necesitan los detalles operativos del caso de uso lo van a encontrar en los pasos del flujo de eventos.

A nivel personal, podemos establecer un símil con los consejos más comunes sobre como llevar una vida sana y exitosa. Consejos tales como "pensar antes de actual" o bien el elemental "dormir lo suficiente cada noche" son el equivalente de las mejores prácticas, aplicadas a como conducir la propia vida.

En el caso de las empresas, se confía en los institutos de investigación de cada sector, quienes identifican sistemáticamente las prácticas en uso, con el objetivo de publicar catálogos de mejores prácticas, que sean apropiadas para el sector industrial que se este considerando. Dichos catálogos suelen ser de acceso libre y son conocidos bajo diferentes denominaciones, como si se estuviera hablando de cosas diferentes en cada sector. Pero no hay confusión que valga: para todo sector valen distintas mejores prácticas, pero llámense como se quieran llamar, todas son mejores prácticas y poco más.

Cuando se esta diseñando un proceso empresarial, es útil considerar las mejores prácticas conocidas del sector o actividad en la que el proceso vive. Dado que existen gran cantidad de sectores, el analista de procesos puede beneficiarse de conocer que se considera como una buena idea, dando entonces una base sistemática para identificar objetivos de diseño para los procesos, más allá de cubrir las necesidades inmediatas demandadas por los clientes.

He de hacer notar también, que muchas de las mejores prácticas pueden ser apoyadas por sistemas de información apropiados; o dicho de otra forma, que hoy en día existen gran cantidad de sistemas de información, muchos de ellos construidos para dar cumplimiento a una o más de las mejores prácticas de sector destino del sistema.

Así que el asunto de las prácticas conviene tenerlo en mente.

Este hecho, creo que me influyó decisivamente, y me hizo tener una visión, al menos durante unos años, bastante ortodoxa en el desarrollo de software.
Desde entonces, he tenido tiempo de conocer y trabajar con otras metodologías. He tenido tiempo creer en determinados planteamientos, y más tarde de abandonarlos y creer en los contrarios. Así que sirva mi experiencia personal, para contar un ejemplo de cómo se ha movido el mercado en estas cuestiones en la última década.

Como decía allá por el 97, comencé con métrica v2, el nivel de detalle de esta metodología permitía casi, poner el manual encima de la mesa y comenzar con el análisis de los sistemas. Fue necesario un esfuerzo importante en el primer proyecto, pero después solo había que seguir el manual punto a punto. Creo que lo mejor de métrica, además de que ofrecía un perfecto guión para todo el análisis era, que sus resultados eran comprensibles prácticamente para cualquiera, sin necesidad de ser técnico.
De este periodo de métrica, me quedo con dos cosas, por una parte, el orden y la calidad que aportaba el método, y por otra, con un comentario que uno de los clientes nos hizo y que ahora detallaré. Habíamos desarrollado un análisis que superaba el millar de páginas, durante la implantación del sistema, el cliente se quejó del funcionamiento de un módulo, y yo le dije “el módulo funciona según se recoge en el capítulo tal del análisis”. Nuestro cliente cogió uno de los volúmenes en los que habíamos encuadernado nuestro trabajo y mientras lo levantaba mostrándomelo, me dijo “¿tú crees que yo tengo tiempo para leerme esto?”
En aquel momento me resultó insultante, más adelante me pareció una estupenda lección que, como ahora hago, he citado en más de una ocasión.

Más tarde en el año 2000, en otra compañía y en otro negocio, tras decidir que los futuros sistemas irían hacia un entorno web, hubo que definir y decidir cómo se trabajaría. El análisis y la programación estructurada ya no nos servía. Después de estudiar cual debía ser el camino, elegimos RUP (Rational Unified Process) como framework para nuestros desarrollos. Realmente, mirándolo con la distancia que da el tiempo, el principal motivo de la elección fue que era lo que todo el mundo estaba haciendo: todo el mercado no podía equivocarse. Elegimos un proveedor para hacer un importante desarrollo, nuestro planteamiento fue, nosotros haremos un análisis utilizando las “antiguas” técnicas de programación estructurada y nuestro proveedor debía “traducirlo” a orientación a objetos utilizando RUP y Rational Rose. Ellos eran expertos y nosotros no. De la etapa de RUP, también me llevé varios aprendizajes:

RUP no solo era un framework para el desarrollo de software, se había convertido también en una “buzzword” (termino que utilizan los anglosajones para aquellas palabras rimbombantes que se ponen de moda y están en boca de todo el mundo), y como tal todo el mundo se proclamó defensor, conocedor y experto de RUP. Yo no tenía intención de aprender RUP, pero como el proyecto fue mal, no me quedó más remedio. Fue entonces, después de días y días de estudio de UML y RUP, cuando me di cuenta de que todo el mundo hablaba de RUP pero pocos sabían de lo que hablaban y muy pocos estaban capacitados para trabajar con esta metodología, en mi opinión, tremendamente compleja, pesada y difusa. Primera enseñanza, cuidado con los expertos, si realmente no lo son, sus efectos pueden ser nocivos, y segunda enseñanza, en ocasiones la marcha atrás no es posible. Cuando esto ocurre, caben dos posibilidades seguir hablando de las excelencias de la decisión que se tomó, o bien, admitir que la decisión no fue la mejor. La situación no es buena con cualquiera de ellas, por que lo esencial es que la decisión fue equivocada. Pero esta es otra historia, yo estaba hablando de metodologías.

La cuestión en aquel punto es que necesitaba reorientar los análisis y puesto que había aparecido la versión 3 de métrica, que soportaba orientación a objetos, esta fue la elección. Al menos, métrica centraba más las cosas, y era más sencillo implementar el análisis que con RUP.

Y así seguí hasta 2005, pensando que RUP continuaba siendo el estándar, aunque a mí me resultaba tremendamente pesado y complejo. En verano de 2005 comenzó una temporada en que tuve tiempo para reflexionar sobre todo esto (acababa de ser despedido). Me venía a la cabeza aquel comentario que antes citaba, realizado 6 años atrás y referido a un tocho de análisis de más de mil páginas. “¿Tu crees que tengo tiempo para leerme esto”?. Por otra parte pensaba en lo poco explicativos que resultaban para los usuarios los diagramas de casos de uso (de utilización extensiva en RUP), y me pregunté, por que narices los informáticos obligábamos a nuestros clientes a que utilizasen nuestras técnicas de diagramación, en lugar de ser nosotros quienes utilizásemos las suyas. Hablé con unos cuantos compañeros y amigos (Gente de empresariales, económicas, ingenieros, MBA’s) y les pregunté que tipo de técnicas os han enseñado para definir procesos de negocio. La respuesta fue unánime: ninguna. Así que me dije a mi mismo, debes salvar al mundo de los sistemas de información (entiéndase el tono jocoso) y crear una metodología basada en las necesidades de los clientes y no al revés.

Comencé a esbozar algunas ideas al respecto, hasta que di con la palabra clave: “Ágil”, es sabido que las cosas no existen, hasta que no das en en Google con la palabra adecuada, y una vez que la encontré me enteré de que hacía no mucho, que se estaban iniciando con fuerza lo que se venían a llamar “Metodologías ágiles” de desarrollo de software, mas o menos en línea con las ideas que yo tenía. Mi primer sentimiento, fue de rabia, ya estaba inventado lo que yo iba buscando. El segundo fue de todo lo contrario, me sentí satisfecho por evolucionar hacia una tendencia relativamente nueva, luego mis ideas y mis planteamientos eran buenos.

No obstante, en ese momento, no quise aprender nada más sobre “métodos ágiles”, pensé que si leía más al respecto, me condicionaría y no me permitiría ser creativo.

Entre notas y notas sobre el tema, iba haciendo algunos cursos dirigidos a emprendedores, un compañero de curso me dijo sobre mi idea. Lo que dices, suena muy bien, pero, ¿alguien te lo comprará? Tras resistirme durante unos días a reconocerlo, finalmente me di cuenta de que la respuesta era muy simple: NO, así que…, abandoné la idea.

Sería principios de 2006, y ahí se inició un paréntesis en mi relación con las metodologías de desarrollo de software, que duraría hasta verano de 2007, cuando comienzo un periodo como consultor y he de trabajar con la metodología utilizada por una gran empresa para la que trabajaba.
En aquel momento, su metodología me parece un refrito de UML con algunas técnicas de modelado de procesos, donde habían quitado protagonismo al modelo de casos de uso. Pero, hace muy poco que he leido algo sobre UML 2.0 y también sobre el estándar de OMT para la definición de procesos de negocio (BPM) y pensándolo, quizás se hubiesen basado en ello al definir esta metodología.
El caso es que me seguía pareciendo compleja, no me parecía que se hubiese evolucionado y pensaba que no aportaba gran cosa respecto a RUP.

Así que, me interesé de nuevo por lo que había en el mercado, y descubrí Microsoft Solutions Framework (MSF) en su version 3.0 (que no era novedad, pero sí para mi). Me pareció excelente, potenciaba el trabajo en equipo y la creatividad, promovía que cada etapa fuese dirigida por quien más capacidad tuviese para ello, había oido hablar y algo había leido también sobre “empowerment” y equipos de alto rendimiento (perdón por los palabros), pero no tan en detalle como MSF lo proponía y por supuesto no aplicado al desarrollo de software. Así que estuve durante un tiempo interesándome por el tema. Leí también sobre eXtreme Programming, que basa sus técnicas en el desarrollo entre pares y la velocidad de proporcionar al cliente prototipos tan rápido como sea posible. Y también sobre Scrum, excelente para plantear la estrategia de los proyectos a corto plazo. XP no es demasiado de mi agrado, si lo es sin embargo Scrum, al igual que las nueva versión de MSF para entornos “Ágiles” (la versión para CMMI me resulta pesada).

Paralelamente a esto, un día curioseando en una librería, hojee “Lean Thinking”. El “Lean Thinking” basado en el sistema de producción de Toyota, tiene como máxima el evitar desperdiciar tiempo y recursos, haciendo solo aquello que realmente sea necesario (¿Software en producción que nunca ha sido utilizado? ¿Le suena a alguien?), así que lo incorporé a mi pensamiento actual.

Por otra parte también tuve la oportunidad de aprender algo sobre Six Sigma, un método orientado inicialmente a garantizar la calidad en procesos industriales. Aunque 6 Sigma me resulta demasiado pesado, me quedo con su método para definir objetivos, centrado en las necesidades del cliente (“la voz del cliente”) y la percepción que el mercado tiene de nuestros productos y de los de nuestra competencia. A partir de aquí obtendremos objetivos mensurables que llama CTQ’s (Critical to quality)

Sinceramente, creo que pretender continuar con metodologías “pesadas” es un error, y comprendo que en grandes empresas prescindir de ellas es complicado. Pero creo que es el camino a seguir, sirva el ejemplo de los padres de UML y Rational, moviéndose hacia lo “ágil”

Así pues, si tuviera que elegir escogería algo así como el Framework”de Microsoft, tomando planteamientos e ideas de Scrum, Lean y Six Sigma. Pero sobre todo me quedo, como decía en un post anterior, con el “Think” que Thomas J. Watson llevó primero a NCR y después a IBM. Cada problema, cada proyecto, cada empresa son diferentes y no hay ningún guión escrito para ellos, esto no significa que los procedimientos y métodos no nos ayuden, todo lo contrario, pero debemos tener siempre presente que lo realmente importante es la resolución del problema, y no la metodología, que solo será un medio para conseguir el objetivo.

ISO 9000

El término se refiere a una serie de normas universales que define un sistema de “Garantía de Calidad” desarrollado por la Organización Internacional de Normalización (ISO) y adoptado por 90 países en todo el mundo. ISO está compuesta por representantes de normas nacionales de más de 100 países. Su objetivo es promover el intercambio de productos y servicios en todo el mundo y fomentar la cooperación mundial en las áreas intelectual, científica, tecnológica y económica.

PMI (Project Mangement Institute)

Es una organización sin fines de lucro dedicada a desarrollar la Disciplina de Administración de proyectos (Project Management) en todo el mundo. Su casa central está en Pensilvania - USA y tiene más de 112.000 miembros en 125 países.

Los miembros son individuos que se desarrollan en proyectos en distintas industrias, entre otras, aeroespacial, automotriz, negocios, servicios financieros, tecnología de la información, telecomunicaciones, construcción, farmacéutica, ingeniería.

El PMI fue fundado en 1969 y desde ese entonces se fueron incorporando más miembros en distintos países y realizaron distintos eventos para difundir el mejor uso de la disciplina.

La certificación del PMI como Project Management Professional (PMP®) es la más reconocida en todo el mundo y está certificada en la ISO 9001.

ITIL (Tecnología de la Información Biblioteca de Infraestructura)

ITIL es un acrónimo de Tecnología de la Información Biblioteca de Infraestructura. ITIL son una serie de libros y manuales de capacitación que contienen y explican las prácticas que son las más beneficiosas para servicios de TI (por lo general se centró administrador). El objetivo de ITIL es para los administradores a tener muy altos niveles de TI en valor, así como una alta calidad financiera en el día a día las operaciones de TI. ITIL son los procedimientos proveedor independiente e incluyen materiales de instrucción en infraestructura de TI, las operaciones y cuestiones de desarrollo.

COBIT (Control Objectives Control Objectives for Information and related Technology)

Es el marco aceptado internacionalmente como una buena práctica para el control de la información, TI y los riesgos que conllevan. COBIT se utiliza para implementar el gobierno de IT y mejorar los controles de IT. Contiene objetivos de control, directivas de aseguramiento, medidas de desempeño y resultados, factores críticos de éxito y modelos de madurez.

MoProSoft

MoProSoft es el modelo de procesos para la industria mexicana de Software, realizado en conjunto por la Secretaría de Economía, la UNAM y AMCIS. Este modelo está diseñado para medir la capacidad de los procesos que siguen las empresas y para garantizar una calidad constante en los desarrollos y mantenimiento de software. Se tomaron los siguientes estándares internacionales como base para la creación de MoProSoft:

ISO 9000, ISO 15504, SW-CMM y CMM-I.

MoProSoft es un modelo de calidad que permitirá a la pequeña y mediana empresa de desarrollo de software, el acceso a las prácticas de Ingeniería de Software de clase mundial.

Es un producto de la Estrategia 6 "Alcanzar niveles internacionales en capacidad de procesos", del Programa Nacional para la Industria de Software administrado por la Secretaría de Economía

CMMI (Capability Maturity Model Integration)

Capability Maturity Model Integration (CMMI) es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para procesos eficaces.

Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay dos áreas de interés cubiertas por los modelos de CMMI: Desarrollo y Adquisición.

RUP (Rational Unified Process)

El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

--------------

La intención de este post es solo dar a conocer estas definiciones de forma no muy detallada simplemente para que sepamos de que nos hablan.

Si desean un poco mas de información acudan a papa google.. hay un verdadero mar de datos..

• The Invention of Use Cases
• The future of software development practices
• Aspect Orientated Programming
• Essential Unified Process
• SOA and Extreme Programming
• UML is Broken
• Developers are too fashionable

"We are as fashion orientated in our industry as clothing industries. We are changing fashion every five years. Go back five years ago it was Rational Unified Process (RUP). If you go just a few years ago extreme programming was very, very hot. Today you don't hear about extreme programming. Today it is SCRUM, the new silver bullet. I have met one of the founders of SCRUM, Ken Schwaber, and he would never have that opinion."

Ivar Jacobson: Developers are too fashionable

اساس RUP بر تكرار (iteration) است و اساس تكرار اين است كه هر تكرار به يك محصول قابل اجرا ختم شود. هر تكرار شامل هر هفت مرحله چرخه‌ي حيات در مدل سنتي آبشاري است، يعني: مدلسازي تجاري، تخمين نيازها، تحليل و طراحي، پياده سازي، تست، نگهداري و توسعه. 

در RUP كل فرآيند توليد نرم‌افزار به چهار فاز اصلي تقسيم مي‌شود، كه هر فاز مي‌تواند شامل يك يا چند تكرار باشد. هر فاز شامل مسيري است كه بين دو گردنه (milestone) قرار دارد. اين چهار فاز عبارتند از:

· آغاز (inception)

· جزييات (elaboration)

· ساخت (construction)

· انتقال (transition)

1- فاز آغاز

در اين فاز مدل تجاري سيستم رسم و دورنماي پروژه ترسيم مي‌شود. براي اين كار بايد همه‌ي موجوديت‌هايي كه سيستم با آنها تعامل دارد (بازيگران /Actors) شناخته شوند و نحوه تعاملشان با سيستم مشخص گردد. اين شامل تعيين همه‌ي موارد كاربرد (use case) و توضيح برخي از موارد مهم است. مدل تجاري شامل شرايط موفقيت، برآورد ريسك‌ها و تخمين منابع مورد نياز است. همچنين يك برنامه‌ي كلي كه زمانبندي مراحل انجام پروژه را نشان دهد. 

اهداف فاز آغاز

در انتهاي اين فاز اهداف چرخه‌ي حيات پروژه را تعيين مي‌كنيد و تصميم مي‌گيريد كه آنرا ادامه بدهيد يا نه. هدف اصلي اين فاز بدست آوردن هماهنگي بين تمام افراد درگير با پروژه درباره‌ي اهداف پروژه است. اهداف فرعي ديگر اين‌هايند:

· تعيين حدود و دورنماي پروژه

· تعيين موارد كاربرد حيياتي سيستم و سناريور اوليه آنها

· تعيين سناريوهاي جايگزين

· تخمين هزينه و زمان پروژه

· تخمين ريسك‌هاي احتمالي

خروجيهاي فاز آغاز

· سند نماي كلي (vision) : ديد كلي به هسته‌ي اصلي نيازهاي پروژه، قابليت‌هاي كليدي و حدود اصلي

· مدل مورد كاربرد: مشخص كردن همه‌ي موارد كاربردي كه در اين مرحله‌ي مقدماتي مي‌توانند شناسايي شوند)

· لغتنامه‌ي اوليه

· مدل تجاري اوليه، شامل زمينه‌ي تجارت، شرايط موفقيت، الزامات تجاري

· تخمين خطاي اوليه

· برنامه‌ي اوليه كه فازها و تكرارها را نشان مي‌دهد. 

2- فاز جزييات

در اين فاز تعريف محصول تصحيح مي‌شود و معماري آن مشخص مي‌گردد. همچنين خلاصه برنامه‌ي توسعه و گسترش محصول تدوين مي‌گردد. در انتهاي اين فاز اهداف و نماي پروژه دقيقتر تعيين مي‌شوند و انتخاب يك معماري و تبيين ريسك‌هاي عمده انجام مي‌گيرد. اين فاز مهمترين در بين چهار فاز ذكر شده است. فشار كار «مهندسي» نرم‌افزار در اين فاز است. 

در اين فاز، در يك يا چند تكرار، يك پيش نمونه (prototype) قابل اجرا از معماري سيستم ساخته مي‌شود. تعداد تكرارها بستگي به نما، اندازه، ريسك و جديدبودن پروژه دارد. 

اهداف فاز جزييات

هدف اين فاز آناليز دامنه‌ي مساله و ايجاد يك پايه‌ي درست براي معماري، توسعه‌ي برنامه‌ي پروژه و برطرف كردن عمده‌ترين ريسك‌هاي پروژه است. تصميم‌ها در مورد معماري بايد بر اساس دركي از كل سيستم اتخاذ شوند. اين متضمن آن است كه بيشتر موارد كاربرد توصيف شوند. اهداف اوليه اين فاز عبارتند از: 

· تعريف و تصحيح معماري، با بيشترين سرعت ممكن

· به دست آوردن يك برنامه‌ي درست براي فاز ساخت

· اثبات اينكه معماري مورد نظر، نياز پروژه را با هزينه و زمان معقولي تامين مي‌كند.

خروجيهاي فاز جزييات

· مدل مورد كاربرد 

· ديدن نيازهاي اضافي و غيركاركردي كه به مورد كاربرد خاصي وابسته نيستند. 

· يك نسخه‌ي قابل اجرا از معماري و مستندات پيوست (سند معماري نرم‌افزار) شامل طراحي زير مجموعه‌اي از موارد كاربرد و لغتنامه‌ي اصلاح شده

· مدل تجاري تجديد نظر شده

· فهرست ريسك‌هاي تجديد نظر شده

· برنامه‌ي توسعه‌ي پروژه

· راهنماي اوليه‌ي كاربر

3- فاز ساخت

در طول فاز ساخت، به صورت تكراري (iteratively) و افزايشي (incrementally) محصول نهايي كامل توليد مي‌شود، كه براي انتقال به كاربر آماده است. اين متضمن تبيين موارد كاربرد باقي‌مانده و ساير نيازمندي‌ها، تبيين طراحي، تكميل پياده سازي، و تست نرم‌افزار است. در انتهاي اين مرحله تصميم مي‌گيريد كه آيا نرم‌افزار، سايت و كاربران براي شروع بكار سيستم آماده‌اند يا نه.

در طول اين مرحله همه‌ي اجزاي باقي‌مانده ساخته مي‌شوند و قابليت‌هاي كاربردي توسعه يافته به محصول افزوده و تست مي‌شوند. در اين مرحله تاكيد و توجه بر مديريت منابع و كنترل عمليات براي بهينه كردن هزينه‌ها، زمانبندي و كيفيت است. اغلب پروژه‌ها آنقدر بزرگ هستند كه كارهاي اين مرحله بصورت موازي انجام گيرند. اين فعاليت‌هاي موازي باعث تسريع در توليد مي‌شوند، همچنانكه مي‌توانند پيچيدگي مديريت منابع را زياد كنند. يكي از مهمترين ويژگي‌هاي كيفي يك معماري خوب، سادگي ساخت آن است. اين يكي از دلايل آن است كه تعادل ميان توسعه‌ي معماري و برنامه‌ريزي در فاز جزييات مورد توجه بود. 

اهداف فاز ساخت

· كمينه‌كردن هزينه‌هاي توسعه با بهينه كردن منابع و اجتناب از ضايعات و دوباره‌كاري‌هاي غيرلازم

· بدست آوردن كيفيت كافي در كمترين زمان ممكن

· بدست آوردن نسخه‌هاي مورد نياز (آلفا، بتا و ساير نسخه‌هاي تستي) در كمترين زمان ممكن

خروجيهاي فاز ساخت

خروجي فاز ساخت محصولي است كه براي قرار گرفتن در دست‌هاي كاربر نهايي‌اش آماده است. اين شامل موارد زير است:

· محصول نرم‌افزاري، سوار شده بر سكو

· راهنماي كاربر و توضيحي درباره‌ي نسخه‌ي فعلي

4- فاز انتقال

در اين مرحله محصول در دست‌هاي كاربر نهايي قرار مي‌گيرد. معمولا در اين مرحله مواردي مطرح مي‌شوند كه نياز به كار بيشتر براي ميزان كردن سيستم و تصحيح مشكلات پيش‌بيني نشده دارد. اين مرحله معمولا با يك نسخه‌ي بتا آغاز مي‌شود. در پايان اين مرحله تصميم مي‌گيريد كه آيا اهداف چرخه توليد محقق شده‌اند يا نه، و اينكه آيا بايد چرخه‌ي ديگري آغاز شود؟ اين فاز خود مي‌تواند شامل چند تكرار (مانند نسخه‌ي بتا، نسخه‌ي نهايي و رفع خطاهاي كوچك و ريزه‌كاري‌ها) باشد. همچنين مسائلي چون آموزش كاربران و تبديل داده از پايگاه داده‌ي فعلي به جديد مورد توجه قرار مي‌گيرند. 

فعاليت‌هايي كه در تكرار‌هاي اين فاز انجام مي‌شوند، بستگي به هدف آن دارند: براي رفع خطاهاي كوچك، كار كدنويسي زيادي لازم نيست، ولي اگر قابليت جديدي بايد به محصول اضافه شود، تكرار شبيه فاز ساخت خواهد بود. 

اهداف فاز انتقال

· كسب توانايي خود-پشتيباني توسط كاربر

· بدست آوردن و آغاز بكار محصول نهايي با بيشترين سرعت و كمترين هزينه

منبع : http://www.dadeban.com ]]> http://synergix.wordpress.com/?p=216 Tue, 26 Aug 2008 04:31:29 +0000 Iván Garcerant http://synergix.bg.wordpress.com/2008/08/26/casos-de-uso-preferir-la-amplitud-a-lo-detallado/ Un caso de uso es la descripción de un escenario de interacción -un uso- entre un actor y el sistema. Dicho escenario captura el requisito funcional que el sistema ha de cumplir y documenta lo que se ha discutido entre el equipo de desarrollo y el cliente en una forma simple, de fácil lectura y razonablemente exacta.

Todo bien hasta aquí.

En sistemas reales, es inevitable encontrarse con las siguientes dos situaciones:

1. Algunos requisitos quedan sin descubrir y se convierten en riesgos.
2. Algunos requisitos muy especificados jamás encuentran un lugar en el desarrollo.

O en otras palabras, si no tenemos cuidado, tendremos casos de uso que especifican en detalle algo que esta por fuera del alcance del proyecto en tanto uno o más puntos importantes habrán quedado en el anonimato y nos atacaran en castigo a nuestro olvido.

Ambas situaciones son peligrosas y aún si las controlamos representaran costos imprevistos que pueden hacer peligrar el proyecto.

¿Como podemos evitar estos problemas? Sin querer decir que es una receta mágica, lo que la experiencia nos enseña es que un modelo de casos de uso (y quizás todo sistema de requisitos) ha de preferir documentar primero a lo ancho, cubriendo áreas cuanto más amplias mejor, del sistema a desarrollar, antes de descender a los detalles de las partes de mayor interés.

Si suponemos un desarrollo cualquiera, este consejo de ir primero a lo amplio y luego a lo detallado, significa que tendremos muchos casos de uso apenas en estado de borrador, que delinean a grandes rasgos lo que se pretende del sistema en términos de su funcionalidad y el alcance del proyecto. Luego, según vayamos atendiendo los requisitos en nuestras iteraciones o fases, podremos dedicar algo de tiempo en obtener los detalles de cada caso de uso de manera de desarrollar el sistema correcto.

Esta aproximación es interesante también desde el punto de vista de la gestión del proyecto. Es posible crear un plan de proyecto que dedique algunas semanas a la creación de un modelo de casos de uso muy amplio pero sin mayores detalles, para luego decir cuales casos de uso van en cada una de las iteraciones.

Claro que al gestionar nuestros proyectos de esta forma hay que priorizar los casos de uso, según el riesgo y según su relevancia para establecer una arquitectura estable, conceptos que ahora si podemos entender sin mayores problemas: del total de casos de uso identificados, detallamos en las primeras iteraciones aquellos que sean identificados como de alto riesgo o como de mayor impacto en la arquitectura del software.

La otra vía es casi imposible de practicar: documentar en detalle los requisitos aún antes de comenzar a desarrollar la primera línea del código es decir que todo se puede saber de antemano, por lo que para aquellos de entre nosotros que carecemos de la omnisciencia vamos inevitablemente a cometer errores.

Entonces no tentemos al destino. Los requisitos cambian durante el tiempo de vida de los proyectos; no perdamos el tiempo capturando detalles que van a cambiar. Por otra parte, identificar a grandes rasgos las principales características que se nos piden es vital para tener una idea de la magnitud del desarrollo así como de los recursos que tendremos que invertir (tiempo, dinero, etc.) y finalmente, no tiene mucho sentido excluir a los requisitos de la planificación del proyecto, por lo que tenemos de una u otra forma que integrar a los casos de uso en el diseño del proceso de desarrollo.

Todo lo anterior nos obliga a todos quienes practicamos el desarrollo guiado por casos de uso a trabajar primero a lo ancho: prefiriendo lo amplio a lo detallado en tanto dichos detalles no sean impresindibles.

Aceptado lo anterior, la herencia de actores va a ser la distribución a lo largo de una jerarquía de roles, de las actividades a realizar, representadas estas como casos de uso. O lo que es lo mismo, la herencia nace como una forma de organizar los enlaces entre actores y casos de uso a fin de simplificar los diagramas y reducir la necesidad de presentar información repetida.

Nuevamente pero algo más técnico: a lo largo de la jerarquía de herencia lo que vamos a organizar son las activaciones de casos de uso de cada actor con ayuda de categorías intermedias o actores abstractos.

A diferencia de la herencia de casos de uso, considero que la herencia de actores es una práctica básica y que no tiene mayor problema en ser entendido por los stakeholders ni mucho menos, presenta problemas a los analistas. La razón es que la dificultad de la herencia de los casos de uso es la definición detallada de como los múltiples elementos de información de un caso de uso se comporta durante la herencia, dificultad esta que no existe en la herencia de actores por ser estos tan sencillos.

Como dije antes, la herencia de actores es una forma legible de mejorar la presentación de nuestros modelos, por lo que ejemplo que daré tiene por motivación el mejorar la legibilidad de un por lo demás, muy sencillo modelo de casos de uso.

A efectos del ejemplo, supongamos que trabajamos con un sistema de ventas, que permite tanto a los promotores como a los empleados del departamento de ventas el visualizar las existencias de productos así como la consignación de mercancía, pero que excluye a los promotores de la posibilidad de aceptar devoluciones. La situación es presentada en el siguiente diagrama de casos de uso:

Fig. 1 - Ejemplo de modelo de casos de uso sin herencia

Si se observa con atención el diagrama 1, se ve como las líneas de activación se cruzan entre actores. Claro que podemos tratar de organizar un poco mejor el diagrama para evitar esto, pero hemos de reconocer que esto solo será una solución temporal. Conforme se incremente la cantidad de casos de uso nos encontraremos una y otra vez en esta situación. No es solo una cuestión de estética, de utilizar líneas segmentadas bien podríamos llegar a hacer el diagrama por completo ilegible. Es entonces necesario un enfoque alternativo.

Dicho enfoque alternativo naturalmente va a ser la herencia. En el segundo diagrama se ven exactamente los mismos casos de uso y los mismos actores, pero se ha establecido una relación de herencia con respecto a un actor abstracto u operador como estrategia para presentar la información sin tanto barullo de líneas.

Fig. 2 - Ejemplo de modelo de casos de uso con herencia entre actores

En este segundo diagrama hemos indicado que el operador puede realizar las dos tareas comunes, en tanto que por herencia hemos dicho que los empleados del departamento de ventas son los únicos autorizados a aceptar devoluciones de mercancías. Aquí hay que notar que no he establecido una relación de herencia entre promotor y ventas, sino que por el contrario he introducido un actor abstracto nuevo, que articula la presentación del modelo sin correr el riesgo de equivoco: promotor no es ventas y ventas no es promotor. El hecho que compartan dos casos de uso si es algo digno de mención pero sus identidades siguen por completo desligadas.

La presencia de un actor abstracto puede ser considerada una fuente de ruido a la hora de explicar el modelo, pero dado que es solo para simplificar las líneas de activación encuentro que la sobrecarga de información no es nociva. Por otra parte lo que hemos ganado en claridad es en mi opinión, mucho mayor a lo que hemos sacrificado al utilizar una notación un poco más técnica.

Proceso Unificado Racional (RUP)

El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente

Principios de desarrollo

El RUP está basado en 5 principios clave que son:

Adaptar el proceso

El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.

Balancear prioridades

Los requerimientos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.

Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados

Elevar el nivel de abstracción

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requerimientos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

Ciclo de vida

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requerimientos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

Principales características

- Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

- Pretende implementar las mejores prácticas en Ingeniería de Software

- Desarrollo iterativo

- Administración de requisitos

- Uso de arquitectura basada en componentes

- Control de cambios

- Modelado visual del software

- Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso)....

Fases

- Establece oportunidad y alcance

- Identifica las entidades externas o actores con las que se trata

- Identifica los casos de uso

RUP, a nivel de fases, contiene una estructura estática y una estructura dinámica. La estructura estática de RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

Proceso: Las etapas de esta seccion son:

- Modelado de negocio

- Requisitos

- Análisis y Diseño

- Implementación

- Pruebas

- Despliegue

Soporte: En esta parte nos conseguimos con las siguientes etapas:

- Gestión del cambio y configuraciones

- Gestión del proyecto

- Entorno

La estructura dinámica de RUP es la que permite que este sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

- Inicio (Tambien lla