IImmpplleemmeennttaacciióónn ddeell RRUUPP eenn uunnaa OOrrggaanniizzaacciióónn

-- EEll eennffooqquuee ddee VVOOLLVVOO IITT GGoorraann VV.. GGrraahhnn && BBoorriiss KKaarrllssoonnnn VVoollvvoo IInnffoorrmmaattiioonn TTeecchhnnoollooggyy VVOOLLVVOO IITT WWhhiittee PPaappeerr __________________________________________________________________________

2

““Escrito por Volvo, este artículo describe la implementación del Rational Unified Process (RUP) en Volvo IT y como los efectos de usar RUP son evaluados a través de cuestionarios y usando el framework SPICE (ISO 15504) para el diagnóstico de la capacidad del proceso de software.””

3

TTaabbllaa ddee CCoonntteenniiddoo RESUMEN......................................................................................................................... 4

INTRODUCCIÓN ............................................................................................................ 5 VOLVO IT...................................................................................................................... 5 CONTEXTO DE LAS MEJORAS AL PROCESO DE SOFTWARE EN VOLVO IT ......................... 5

CONTEXTO DEL NEGOCIO ........................................................................................ 7 OBJETIVOS Y DESAFÍOS DEL NEGOCIO............................................................................. 7 EFECTOS ESPERADOS....................................................................................................... 7

IMPLEMENTACIÓN DE UN NUEVO PROCESO DE DESARROLLO DE APLICACIÓN................................................................................................................... 8

LA ESTRATEGIA DEL MÉTODO......................................................................................... 8 CRITERIO DE EVALUACION..................................................................................... 9 MAPS – LA IMPLEMENTACIÓN DEL PROYECTO RUP .................................................... 10

EXPERIENCIA DE LOS PROYECTOS RUP............................................................ 15 CUESTIONARIOS............................................................................................................. 15 HISTORIAS DE ÉXITO...................................................................................................... 16

EVALUANDO EL EFECTO DE USAR RUP ............................................................. 17 COMO MEDIR LOS EFECTOS DE USAR RUP ................................................................... 17 EL FRAMEWORK SPICE................................................................................................. 17 ESTABLECIENDO PERFILES OBJETIVOS DE CAPACIDAD PARA EL RUP .......................... 18 PROGRAMA DE EVALUACIÓN ......................................................................................... 19 RESULTADO DE LA EVALUACIÓN ................................................................................... 20 COMO TRASLADAR EL CAPACIDAD DEL PROCESO A PRODUCTIVIDAD........................... 22

CONCLUSIONES........................................................................................................... 23 HEMOS ALCANZADO LOS OBJETIVOS? ........................................................................... 23 RECOMENDACIONES GENERALES................................................................................... 23

NOTAS............................................................................................................................. 25

4

RReessuummeenn __________________________________________________________________________________________ El Rational Unified Process[1] o RUP es una estructura completa del proceso del Desarrollo de Software creado por Rational Software. Es una metodología de desarrollo iterativo enfocada hacia “los casos de uso, manejo de riesgos y el manejo de la arquitectura”. Para muchos desarrolladores de Software empezar a usar el RUP implica nuevos conceptos, lo que significa que se requiere muchísima capacitación y aprendizaje en aquellos proyectos que usan el RUP por primera vez. Sólo “leer el libro” no es suficiente! Este WhitePaper describe cómo el RUP es implementado en VOLVO Information Technology, y como los efectos de usar el RUP se evalúan a través de cuestionarios y usando el Framework SPICE (ISO 15504) para evaluar el mejoramiento y la capacidad de los procesos de software de los equipos de desarrollo.

5

IInnttrroodduucccciióónn __________________________________________________________________________________________

VVOOLLVVOO IITT Volvo Information Technology (Volvo IT) es una filial propia de AB Volvo, uno de los grupos industriales más grandes de la Región Nórdica. Volvo IT provee todo tipo de soluciones industriales IT en una variedad de ambientes técnicos. La compañía fue fundada en 1998, a través de una fusión de todos los recursos IT de diferentes compañías del grupo Volvo. Volvo IT provee al Volvo Group, Volvo Cars(desde 1999 en manos de la compañía Ford Motor) y otros clientes seleccionados con soluciones IT efectivas como resultado de un largo período en el valor de los negocios. Volvo IT es una compañía IT de cobertura mundial con cerca de 4300 empleados y unas ventas anuales que supera los 5 billones de SEK1. La organización de las técnicas de Desarrollo de Aplicación, las cuales están representadas en grandes sitios, es responsabilidad de los equipos de soporte a aplicaciones de desarrollo y mantenimiento, con procesos de desarrollo, métodos, herramientas y aplicaciones del ambiente de desarrollo. CCoonntteexxttoo ddee llaass MMeejjoorraass aall PPrroocceessoo ddee SSooffttwwaarree eenn VVoollvvoo IITT Las mejoras al proceso de Software están siempre ejecutadas en el contexto del negocio. Ya que el Desarrollo de Aplicación es uno de los procesos claves dentro de Volvo IT, la implementación de un nuevo proceso de Desarrollo de Aplicación debe ser vista como un mayor aumento de los procesos claves. En nuestro esfuerzo por implementar el RUP hemos trabajado en tres “capas”:

• El nivel de la Estrategia del Método • El nivel de Desarrollo del Proceso/Método • El nivel de Desarrollo de la Aplicación.

1 SEK (Swedish Krona- Corona Sueca), Moneda de Suecia. 1 SEK= Aprox. 0,10782 USD

6

En el nivel de la Estrategia del Método nosotros nos enfocamos en el desafío y objetivos del negocio, y qué efectos esperamos mejorando los proceso del Software dentro de Volvo IT. Esto se discute en el capitulo “Contexto del Negocio”. Para cumplir los objetivos de la Estrategia del Método nosotros necesitamos Procesos y Métodos, por ejemplo, Desarrollo de una Aplicación. En el capitulo “Implementación de un nuevo proceso de Desarrollo de una Aplicación”, se discute la estrategia para evaluar, seleccionar e implementar tales procesos y métodos. También en ese capítulo se discuten los Objetivos de Implementación y los resultados para verificar los efectos esperados en el nivel de Mejorar los Procesos de Software en ese capitulo. La base para evaluar los resultados de la implementación del RUP es el resultado de los proyectos que usan el RUP. En el capitulo “Experiencia de los proyectos RUP” nosotros presentamos varios feedback y lecciones aprendidas de clientes y desarrolladores. En el capítulo “Evaluando el Efecto de Usar RUP” se discuten cómo hemos usado la experiencia de los proyectos RUP junto con las evaluaciones de SPICE para verificar a que grado hemos llegado en cuanto a los efectos esperados en la mejora de los procesos de Software de Volvo IT.

7

CCoonntteexxttoo ddeell NNeeggoocciioo __________________________________________________________________________________________

OObbjjeettiivvooss yy DDeessaaffííooss ddeell NNeeggoocciioo Como muchas otras compañías en el negocio de las Tecnologías de Información IT, Volvo IT enfrenta nuevos desafíos que requieren cambios en la manera en que desarrollamos, liberamos y le damos mantenimiento a las aplicaciones software. Algunos de estos desafíos son:

• Las aplicaciones llegan a ser más y más integradas con el negocio. Por consiguiente el proceso de desarrollo de aplicaciones debe estar integrado con el proceso de Ingeniería del Negocio.

• El ritmo del cambio del negocio está aumentando. Por consiguiente, Volvo IT debe mejorar la productividad para poder responder a los nuevos y requerimientos cambiantes.

• Los clientes desean soluciones globales. Este hecho se traduce en un incremento en el número de proyectos donde los equipos del proyecto se distribuyen en diferentes ciudades y continentes.

La conclusión es que necesitamos un proceso de Desarrollo de Aplicaciones, el cual junto con nuestros procesos existentes para Administración de Proyectos e Ingeniería de Negocios establecen un framework para satisfacer los desafíos y cumplir los objetivos. EEffeeccttooss EEssppeerraaddooss A largo plazo los efectos esperados de usar el nuevo framework de procesos son:

• Requerimientos bien definidos del negocio como entrada al proyecto de desarrollo de Aplicaciones

• Mejor producto ajustado a las necesidades presentes en el momento de entrega.

• Reducción del tiempo requerido hasta la liberación de la primera versión de la aplicación.

• Más proyectos en el tiempo estimado y dentro del presupuesto. • Reducción de costos/tiempo de corrección. • Mejor mantenimiento del producto. • Un proceso común para el Desarrollo de Aplicaciones.

8

IImmpplleemmeennttaacciióónn ddee uunn NNuueevvoo PPrroocceessoo ddee DDeessaarrrroolllloo ddee AApplliiccaacciióónn __________________________________________________________________________________________ Gartner Group afirma que:

“Para implementar totalmente una metodología AD 2 en una Organización AD con 100 a 200 desarrolladores podría fácilmente requerirse de 2 a 3 años”

Puesto que Volvo IT es una compañía mucho más grande que el ejemplo de la cita de Gartner, fue importante entender que este tipo de esfuerzo tomaría tiempo, y necesitaría una administración apropiada. Volvo IT inició un proyecto a mediados de 1998 a fin de establecer una estrategia de cómo administrar asuntos metodológicos y encontrar candidatos adecuados para los procesos de Desarrollo de Aplicaciones. LLaa EEssttrraatteeggiiaa ddeell MMééttooddoo La implementación o cambios en el proceso de desarrollo de una aplicación en un negocio, es una tarea con muchas trampas. En la Estrategia del Método se reconocen “factores críticos en el éxito” de nuestro trabajo para el establecimiento de un proceso común en el desarrollo de una aplicación en la compañía. Los factores de éxito se basaron en lo que el grupo Gartner Group y otros han encontrado. Algunos de los más importantes factores de éxito son:

• Participación de la Administración. Estamos convencidos que es absolutamente necesario tener una participación activa de la alta gerencia, y que la administración entienda el alcance del cambio cuando una compañía está cerca de implementar un nuevo y común proceso.

• Proceso interno en las habilidades de ingeniería. El proceso de desarrollo de aplicaciones(incluyendo sus diferentes variantes) es una parte central de los negocios de Volvo IT, y por consiguiente, es importante que nosotros tengamos control del contenido y configuración de los diferentes procesos variantes dentro de la compañía.

• Integración entre el proceso de desarrollo de aplicaciones, sus métodos y herramientas. Precisamente un proceso(describe que hacer) para el desarrollo de aplicaciones no es suficiente, tampoco es precisamente el método (describe como hacerlo)- se necesitan ambos, y es importante que los diferentes métodos y herramientas sean consistentes con el proceso.

2 AD: Application Development – Desarrollo de Aplicaciones

9

• El proceso debe ser fácil de liberar.

Puesto que comprendemos que el proceso seleccionado continúa evolucionando, debe ser fácil distribuir nuevas versiones y configuraciones del mismo. Muchos procesos y métodos buenos han quedado “olvidados”, lo que no significa “implementados”.

CCRRIITTEERRIIOO DDEE EEVVAALLUUAACCIIOONN Basado en la Estrategia del Método, Volvo IT decidió iniciar la investigación del mercado de candidatos aptos para los procesos de desarrollo de aplicaciones. Fue un objetivo de Volvo IT usar un proceso estándar conocido, ensayado y probado de un proveedor en el mercado que soporte practicas modernas en el Desarrollo de aplicaciones. Para este propósito se estableció un conjunto de criterios, los cuales fueron usados en la evaluación de los diferentes candidatos, con énfasis en el proceso mismo asi como posibles relaciones con el proveedor. Los criterios que se determinaron fueron:

• Proceso Iterativo. Para responder de forma efectiva a los requerimientos del negocio que varían constantemente, es importante que el proceso soporte desarrollo iterativo

• El proceso debe ser parametrizable.

Cada proyecto es único, y un proceso es una descripción genérica, normativa de una situación ideal. Por consiguiente el proceso debe ser configurable a las necesidades del proyecto específico. Sin embargo, incluso si cada proyecto es único, es posible clasificar los proyectos en "Tipos de Proyectos". Por consiguiente también se tiene la necesidad de configurar el proceso, no solamente para un proyecto específico sino también para algunas "variantes del proceso"

• Entrenamiento Global y Soporte. Es importante que los desarrolladores de Volvo IT puedan obtener entrenamiento y soporte equivalente al de nuestras sedes principales.

• Buen proveedor establecido. Dado que es una inversión a largo plazo, es importante seleccionar un proveedor que sobreviva en el mercado. También es importante que tenga una estrategia para continuar desarrollando el proceso influenciado por las necesidades de los clientes.

Basado en los anteriores criterios, Volvo IT evaluó posibles procesos y proveedores diferentes, y el resultado fue que se selecciono el Rational Unified Process como el Proceso común para el Desarrollo de Aplicaciones.

10

MMAAPPSS –– LLaa IImmpplleemmeennttaacciióónn ddeell PPrrooyyeeccttoo RRUUPP Basado en la Estrategia de Implementación, Volvo IT decidió establecer un proyecto para la implementación del RUP. El proyecto tomo el nombre de MAPS (Methods And Process for System development). Un enfoque por Etapas Cambiar el “Proceso de Producción” de un negocio siempre significa estrés para el negocio afectado. Cuando el proceso del negocio cambia, y por consiguiente el procedimiento en el negocio, esto significa un cambio cultural de grandes proporciones. Este cambio cultural significa que la gente dentro del negocio necesita cambiar su manera de “mirar” y “pensar” el negocio. A fin de facilitar este cambio cultural debemos empezar a incrementar la experiencia con el nuevo proceso para el desarrollo de aplicaciones. Ya que nos dimos cuenta que sería imposible para nuestra compañía empezar a usar un enfoque de implementación por etapas. El primer paso, de acuerdo con este enfoque, fue arrancar con unos pocos proyectos pilotos, y basados en la experiencia de estos proyectos continuar con más proyectos en diferentes pasos de implementación.

Los resultados que se esperaban del proyecto MAPS fueron:

• Un suficiente número de desarrolladores entrenados en RUP, el uso de UML y Racional Suite, que han ganado experiencia en al menos un proyecto en cómo el proceso, métodos y herramientas encajan entre sí.

11

• Un número suficiente de personal interno para hacer de Volvo IT autosuficiente en cuanto a entrenadores del RUP y especialistas del RUP.

• Material de soporte adaptado a las especificas necesidades de Volvo IT para permitir dar un soporte a los proyectos RUP.

El proyecto MAPS continuará hasta que se alcance una “masa crítica” de desarrolladores, entrenadores y especialistas. ¿Cómo Empezar? Se empieza definiendo criterios de selección de proyectos apropiados durante el primer paso de la implementación. La razón de los criterios fue darnos cuenta que no podríamos permitir fallar en los primer proyectos del RUP en ningún aspecto, así que tuvimos que ser muy selectivos cuando decidimos cuales proyectos deberían ser los primeros en usar el RUP. Los criterios fueron:

• Tamaño del Proyecto: Proyectos con equipos de 3 -10 personas, Duración de 3 – 9 meses, 2000 – 5000 horas de esfuerzo.

• Tiempo de Aprendizaje: La entrega no debe tener una “fecha límite crítica”. También esperábamos baja productividad en las fases iniciales de los primeros proyectos: Nosotros estimamos que por lo menos 4 semanas extras eran necesarias para aprender el nuevo proceso, los métodos y las herramientas.

• Interés en el aprendizaje: El administrador del proyecto y el equipo deberían estar interesados en aprender el RUP.

¿Cómo Organizarse? Está comprobado que el más eficiente método para aprender nuevos temas(ej. RUP, UML y las herramientas) es combinando la teoría con la práctica. Para ser capaz de usar el RUP y las herramientas por primera vez, y para que al mismo tiempo se construya un producto de alta calidad, el equipo del proyecto necesita mucho soporte. Es responsabilidad de los Entrenadores del RUP ofrecer dicho soporte. El material de soporte es desarrollado por Especialistas del RUP. Ellos también prestan ayuda a los entrenadores del RUP y soporte a los desarrolladores. En el comienzo necesitábamos experiencias externas puesto que no contábamos con personal interno listo dentro de Volvo IT que pudiera actuar como Entrenadores o Especialistas. Nos dimos cuenta que sería imposible para el proyecto MAPS “ingresar” el RUP dentro de la organización – necesitábamos “sacar” la organización. Para lograrlo, nosotros establecimos Coordinadores locales para cada sitio de desarrollo de Volvo IT. Los coordinadores pueden ser vistos como administrador del sub-proyecto, con la responsabilidad de coordinar todas las actividades de la implementación del RUP dentro de sus sitios. De hecho, los coordinadores son el equipo del proyecto MAPS. Este enfoque ha demostrado funcionar muy bien. Hoy tenemos personal en Volvo IT actuando como Entrenadores y Especialistas del RUP.

12

Implementación de Roles Claves En Volvo IT es responsabilidad de la organización usar RUP. Recursos tales como entrenamiento, licencias, herramientas y capacitación son suministrados por el proyecto MAPS. Entrenador RUP El propósito a largo plazo del Entrenador del RUP es apoyar el uso del RUP en su sitio, dando asistencia practica a los miembros del proyecto, e informando a las partes de interés acerca de nuevos desarrollos, planes y resultados. El objetivo a corto plazo es aprender a entrenar; llegar a ser hábil en el proceso, métodos y herramientas participando en proyectos RUP e intercambiando experiencias con otros entrenadores participando en la red de entrenamiento. EL entrenador necesita entender los artefactos producido en cada flujo de trabajo y el nivel de acometimiento apropiado en cada fase e iteración dependiendo de las características del Proyecto. Para ser capaz de actuar como un entrenador del RUP, se requiere experiencia en el desarrollo del sistema y también un entendimiento de los roles del desarrollo y sus partes en el proceso. El entrenador debe ser capaz de juzgar cuales herramientas son apropiadas, teniendo en cuenta el tipo de proyecto y las experiencias previas de los miembros del proyecto. El entrenador también necesita buenas cualidades personales tales como habilidades de líder (hacer que las cosas funcionen y enfocarse en resultados), habilidades comunicativas (ser capaz de escuchar, ganarse la confianza, motivación y persuasión), y habilidades educativas (ser capaz de poner la teoría dentro de la práctica).

13

Especialista RUP Las responsabilidades de un Especialista en RUP incluyen desarrollo y mejoramiento del material de soporte, ej. Configuración del RUP en Volvo IT y sus plantillas, guías, etc. El Especialista es también responsable de asistir al Entrenador del RUP en el soporte a proyectos. Para actuar como un Especialista del RUP, la persona debería tener amplia experiencia en soporte de proyectos RUP (ej. trabajar como un Entrenador del RUP), a través del conocimiento del RUP, configuración del proceso y revisiones. Normalmente un Especialista en RUP se enfoca en uno o pocos flujos de trabajo del RUP. Coordinador Las responsabilidades de un coordinador son planear, administrar y monitorear el uso del proceso, métodos y herramientas en su sitio. El trabajo del coordinador conlleva planeación y monitoreo del uso del RUP, asistir la administración del sitio para encontrar adecuados proyectos RUP, coordinación del entrenamiento e información de personal, clientes y otras partes interesadas en el RUP. El Coordinador también debería participar como miembro del Comité de Seguimiento de los proyectos que usan RUP, para monitorear el uso y efectos del mismo. Para actuar como Coordinador, la persona debe tener un entendimiento general del RUP y sus implicaciones para los proyectos. La persona debe también ser vista como representante del sitio, tanto desde el punto de vista de la administración como de los desarrolladores. Principales Actividades del Proyecto La parte principal de las actividades del MAPS se ejecutan desempeñadas localmente en los diferentes proyectos RUP. La mayor responsabilidad de MAPS es coordinar todas estas actividades. Las diferentes actividades pueden ser clasificadas en los siguientes grupos: Entrenamiento: El Entrenamiento en RUP, métodos y herramientas es necesario y es un prerrequisito para el éxito! Pero el entrenamiento solo brinda un conocimiento teórico del RUP, los métodos y las herramientas. Estamos convencidos de que este conocimiento teórico no es suficiente y por consiguiente las sesiones de entrenamiento son seguidas por más soporte durante los primeros proyectos del RUP (ver siguiente gráfica). Dependiendo del rol(es) que tiene una persona en el proyecto, se le recomienda tomar diferentes cursos de entrenamiento acorde a la tabla siguiente. La mayoría de los cursos de entrenamiento son cursos estándar de Rational, pero nosotros también tenemos un entrenamiento corto introductorio para aquellos que necesiten entender las características de un proyecto RUP y las diferencias entre un proyecto RUP y un proyecto “tradicional” . Ejemplo de personas en ese grupo objetivo, los clientes, usuarios y administradores de Volvo IT, quienes usualmente están involucrados en los Comités de Seguimiento.

14

Soporte a los Proyectos RUP: Como se describe arriba, el enfoque de aprendizaje del RUP es la combinación del conocimiento teórico con el trabajo práctico. Basados en la experiencia de los Proyectos RUP hemos clasificado el soporte en tres tipos: Talleres, Actividades de entrenamiento y revisiones.

Talleres: Muy rápidamente nos dimos cuenta de que todos los proyectos tienen casi los mismo problemas cuando enfrentan ciertas actividades por primera vez. Para hacer el entrenamiento más efectivo y proactivo, nosotros creamos un conjunto configurable de talleres. Cada Taller:

• Refresca el conocimiento teórico, obtenido en los cursos de entrenamiento.

• Aplica el conocimiento teórico a los problemas específicos del proyecto RUP, artefactos, etc.

Puesto que RUP, UML y las herramientas son nuevas para la mayoría de los desarrolladores, es importante enfocar los talleres lo más temprano posible en el proyecto. En la práctica esto significa que existe normalmente un enfoque fuerte en este tipo de soporte en las fases de Concepción y Elaboración.

15

Entrenamiento: El Entrenamiento es el soporte diario a los diferentes roles del equipo del Proyecto RUP a través de los talleres. Las actividades de entrenamiento son normalmente de una naturaleza muy práctica y tangible. Tiene que ver con interpretar las actividades o artefactos del RUP, crear un modelo específico UML en una situación específica o cómo usar ciertas herramientas en una situación específica. Revisiones: Las Revisiones son decisivas! Además de las revisiones normales que garantizan la calidad del producto construido dentro del proyecto, también se evalúan los efectos del soporte entregado al proyecto. Esta evaluación “extra” es importante para nosotros dado que la implementación del RUP será evaluada basada en el éxito del soporte a los proyectos RUP. Las revisiones son realizadas por lo menos al final de cada fase, pero ellas pueden también ser usadas como “diagnóstico del estado” al final de las iteraciones.

EExxppeerriieenncciiaa ddee llooss PPrrooyyeeccttooss RRUUPP __________________________________________________________________________________________ Implementar y empezar a usar un nuevo proceso común para el desarrollo de aplicaciones implica una gran inversión para una compañía como Volvo IT. Por consiguiente fue muy importante para nosotros recibir feedback, de cómo el RUP en sí y el soporte fueron recibidos por los miembros del equipo del proyecto RUP y los clientes. CCuueessttiioonnaarriiooss Una manera de evaluar el RUP y el soporte del RUP es través de cuestionarios. La evaluación se hace con clientes representativos, el administrador del proyecto y el equipo del proyecto cuando el Proyecto RUP termina. El cuestionario se centra en 5 diferentes áreas:

• RUP vs. “La forma tradicional de trabajar”. • Desarrollo del proceso. • Entrenamiento. • Acompañamiento y soporte. • El enfoque iterativo.

Por cada área usamos diversas preguntas a fin de encontrar las opiniones de todos los involucrados.

16

El resultado es compilado y presentado al equipo del proyecto y al comité de seguimiento del proyecto MAPS. Nuestro objetivo general es tener por lo menos el 80% de los encuestados satisfechos (nivel 3 ó 4 en una escala de 1 a 4). Los resultados mostraron que nosotros por lejos excedimos esta objetivo- en algunos casos por encima del 95%! Si resumimos las lecciones aprendidas basados en preguntas específicas del cuestionario y comentarios adicionales dados por los encuestados, los mensajes más importantes son:

• El foco en los requerimientos y los riesgos durante el proyecto se estima especialmente.

• Se espera que el costo de mantenimiento de la aplicación sea más bajo en comparación con mantener una aplicación desarrollada de la manera tradicional.

• Implementar un nuevo proceso de Desarrollo de Aplicación es una inversión en competencia, y debe ser considerada como una mejora a largo plazo.

HHiissttoorriiaass ddee ÉÉxxiittoo La prueba más valiosa se da cuando los clientes de los proyectos RUP dicen querer la “nueva” forma de trabajar. Tenemos varios ejemplos de esto. A continuación se presentan citas del cliente de uno de los proyectos RUP, presentadas en una revista interna de Volvo IT: “Ha sido fantástico. Hemos sido invitados a tomar parte de una discusión y hemos aportado una solución lista para ser puesta en operación.” “Hemos encontrado que las diferentes fases han traído a discusión temas que probablemente nunca hubiéramos pensado. Como encontramos la arquitectura a buena hora, no fuimos afectados por sorpresas desagradables de última hora.” “Realmente ellos han estado trabajando para encontrar ejemplos de la manera en que soluciones diferentes funcionan y han explicado cosas de una forma que todos entiendan. Todos han estado involucrados e influenciados del proceso, desde los líderes de producción y trabajadores de ensamblaje. Siempre han estado muy receptivos a nuestras necesidades y deseos. Como si pudieran entender lo importante. Trabajando de esta forma nos han hecho mejores definiendo solicitudes.”

17

EEvvaalluuaannddoo eell EEffeeccttoo ddee uussaarr RRUUPP __________________________________________________________________________________________

CCoommoo MMeeddiirr llooss EEffeeccttooss ddee UUssaarr RRUUPP El número total de desarrolladores para ser entrenados en RUP se estima en 1000 personas. Esto es equivalente a una inversión en el rango de 5 – 10 millones de SEK, equivalente a 5 – 10 Millones de USD. Así la pregunta de la alta gerencia no fue una sorpresa: “Puede usted probar que el RUP es una buena inversión?” A menos que los efectos positivos de usar el RUP en la primera ronda del proyecto pudieran ser documentados, porque deberíamos continuar? Ahora bien, que podríamos medir?

• El cuestionario diseñado para proporcionar un feedback de los proyectos RUP pilotos evidentemente no sería considerado una prueba objetiva. Es normal ser positivo cuando se está entre los primeros que trabajan con un nuevo proceso y usando nuevas herramientas.

• Sólo mirando la precisión de entrega (Tiempo Actual y Costo comparado con estimaciones iniciales) de los proyectos usando RUP no sería suficiente para juzgar los efectos del RUP. Por el contrario, el enfoque iterativo permite al cliente y el proveedor estar de acuerdo con cambios en el alcance y las prioridades, a medida que el conocimiento del problema y la solución aumenta.

• Luego nos encontramos con el Framework SPICE (Software Process Improvement and Capability dEtermination) para evaluar la “Capacidad del Proceso”. Evaluando la “manera tradicional de trabajo” de un equipo involucrado en un proyecto, y luego comparando estos datos con los resultados de una evaluación del mismo equipo “trabajando con RUP”, esperaríamos ser capaces de documentar cómo la capacidad del Proceso de Software del equipo fue mejorada.

EEll FFrraammeewwoorrkk SSPPIICCEE SPICE2 (ISO/IEC TR 15504) suministra un modelo bidimensional de procesos y capacidad de procesos que forma la base para la evaluación de procesos. Los procesos se agrupan en cinco categorías:

• Procesos Cliente – Proveedor, ej. Recolección de Requerimientos • Procesos de Ingeniería, ej. Construcción del Software • Procesos de Soporte, ej. Administración de la Configuración • Procesos Administrativos, ej. Administración de Proyectos • Procesos Organizacionales, ej. Administración de Recursos Humanos

Dentro de cada categoría, los procesos se describen por un enunciado del propósito del proceso, el cual incluye una descripción de los resultados deseados del proceso de implementación.

18

Para cada proceso, la capacidad del mismo es evaluada usando nueve atributos, examinando el desempeño del proceso, cómo es administrado, qué productos del trabajo se producen, como se administran los cambios, etc. La calificación de estos atributos se usa para obtener el nivel de capacidad del proceso. Cada proceso recibe una evaluación separada del nivel de capacidad.

SPICE tiene mucho en común con el modelo de Capacidad y Madurez (Capability Maturity Model3 - CMM ™) del instituto de Ingeniería de Software (Software Engineering Institute (SEI)) de la Universidad Carnegie Mellon, US. La principal diferencia es que SPICE permite seleccionar cuales procesos usted desea evaluar, y cada proceso es calificado por si mismo, mientras que CMM tiene un “paquete” de procesos que deben ser ejecutados de acuerdo a ciertos requerimientos para que la organización alcance un determinado nivel de madurez. El nuevo CMM integrado (CMMI) ofrece un enfoque similar al SPICE. EEssttaabblleecciieennddoo PPeerrffiilleess OObbjjeettiivvooss ddee CCaappaacciiddaadd ppaarraa eell RRUUPP Así, debe ser posible establecer un "Perfil Objetivo de Capacidad" que una organización puede lograr si se sigue el RUP de manera idealista. En realidad dicho perfil objetivo existió dentro de Rational Software4 como resultado de un estudio interno en 1998 por John Smith de Rational Software. Este estudio evaluó una versión anterior de RUP usando una versión anterior de SPICE. En la primavera del 2000 un "perfil objetivo de capacidad" para el RUP versión 5.5 fue determinado usando la versión actual de SPICE en la Universidad de Boras, Suecia5. El

19

resultado de este estudio muestra que se espera un nivel de capacidad 3 para un conjunto de procesos seleccionados en una situación idealista cuando se sigue la metodologia del RUP. Sin embargo, se espera alcanzarlo en un lapso de 2 - 3 años en un equipo trabajando con RUP. No podemos esperar que los equipos de proyectos alcancen el nivel 3 en sus primeros proyectos usando el RUP, si estos parten del nivel 1 o 2.

PPrrooggrraammaa ddee EEvvaalluuaacciióónn Se configuró un programa de evaluación para determinar el "Antes/Después de" los perfiles de capacidad para tres de los diez equipos del proyecto RUP en el paso 1 de nuestra implementación del RUP. Los proyectos fueron escogidos para representar diferentes áreas de aplicación, diferentes situaciones y diferentes ambientes técnicos. Se contrato un consultor externo para entrenar algunos asesores internos y dirigir el equipo de evaluación, y planeamos nuestro programa de evaluación con las siguientes fases, de acuerdo con los requerimientos de SPICE:

• Cuestionarios Pre-evaluación, con recolección de documentos claves • Plan de evaluación y cronograma • Reuniones informativas de 1 con el equipo del proyecto (una semana antes de

las entrevistas) • 1 día de entrevistas al equipo del proyecto • Validación y Evaluación

20

• Feedback de conclusiones al equipo del proyecto (un día después de las entrevistas)

• Reporte de Evaluación (Una semana después de las entrevistas) El alcance de la evaluación en términos de los procesos evaluados, se muestra en la Fig8. Para todos estos procesos el nivel esperado de capacidad es igual a 3 usando RUP 5.5 de una manera ideal. Para cada proyecto evaluado:

• La "Evaluación del antes" o 'La forma tradicional de trabajo" fue ejecutada al inicio del proyecto, observando como el proyecto probablemente se ejecutaría si no hubiese sido seleccionado como uno de nuestros proyectos RUP.

• La "Evaluación del después", evaluando la manera de trabajar con el RUP fue

realizada en la fase de construcción del RUP. Las entrevistas fueron delimitadas para ajustarlas en un día, para interrumpir lo menos posible al equipo del proyecto mientras al mismo tiempo se recolectaba suficiente información para ser capaz de dar una correcta evaluación. En un caso, un día fue muy corto para evaluar todos los procesos que teníamos planeados evaluar. También descubrimos que en algunos casos fue muy prematuro evaluar el proceso de Integración y Pruebas dado que estos no habían sido realizados en la primera iteración, para el alcance que una satisfactoria evaluación tuviera. RReessuullttaaddoo ddee llaa EEvvaalluuaacciióónn Abajo se muestra los resultados de la evaluación de uno de los proyectos. Para cada proceso, la barra de arriba representa la “Forma Tradicional de trabajo” y la de abajo representa “El Trabajo con RUP”.

21

El diagrama muestra que la capacidad incrementó de nivel 1 a nivel 2 en los procesos de Requerimientos, Análisis, Diseño y Administración del Proyecto. Los procesos de Verificación y Administración de Riesgos no fueron ejecutados del todo de la forma tradicional de trabajo. “Trabajando con RUP” , estos fueron clasificados en el nivel 1. En todos los tres proyectos que evaluamos, los procesos de Requerimientos, Análisis, Diseño, Construcción y Administración del Proyecto fueron clasificados en el nivel 2 al “Trabajar con RUP” (con una excepción). Estos son los procesos en los que se ha centrado la capacitación de estos primeros proyectos RUP. Es claro que el enfoque cuando se empieza a usar RUP está en conseguir primero el producto final correcto, lo que significa que el proceso de ingeniería, las técnicas de Modelamiento y las nuevas herramientas se les da la mayor atención. En dos de estos proyectos el ambiente Windows DNA se uso por primera vez, adicionando más necesidades al entrenamiento y acompañamiento en temas técnicos. El resultado de la evaluación claramente indica que la implementación del RUP está teniendo efectos. Sin embargo, hay un gran potencial para mejoras adicionales a la capacidad del proceso con la experiencia ganada en RUP. Las acciones de mejoras en el proceso fueron sugeridas a los equipos del proyecto en las sesiones de feedback en donde los resultados de cada evaluación fueron presentados y discutidos. Existe también un potencial para incrementar el soporte dado a los proyectos RUP en los procesos de Administración y Soporte. Las acciones sugeridas concernientes tanto al

22

contenido del soporte así como a la manera en que se brinda, fueron documentadas durante las evaluaciones. Así, además de suministrar pruebas de que la implementación del RUP tenia efectos positivos, las evaluaciones dieron un valioso entendimiento de las fortalezas y debilidades de cómo se estaba ejecutando la implementación. CCóómmoo TTrraassllaaddaarr llaa CCaappaacciiddaadd ddeell PPrroocceessoo aa PPrroodduuccttiivviiddaadd Cuando se reportó lo que habíamos determinado a la alta gerencia, ellos estuvieron bastante satisfechos pero no pudieron contener la pregunta: “Puede decirnos cuanto dinero ahorraremos?” Bien, una pregunta difícil de contestar... Sin embargo, la edición de abril de 2001 de IT Metrics Strategies6 contiene un articulo, que discute que tan rápido, económico y mejor un equipo que trabaja en CMM nivel 2 comparado con un equipo trabajando en CMM nivel 1. El articulo se basa en estadísticas de evaluación CMM en una gran base de datos ejecutada por Quantitative Software Managment (QSM), que contiene medidas de productividad aproximadamente de 2500 proyectos. Al mismo tiempo que este artículo discute algunos grandes proyectos, también hace referencia a datos presentados por QSM7 que muestran que pasar de CMM nivel 1 a CMM nivel 2 cuando se codifica y prueba una aplicación de negocios de aproximadamente 50000 líneas de código.

• Reducirá el cronograma en un 17% • Reducirá el esfuerzo en un 46% • Reducirá los defectos en un 51%

Y, pasar de CMM nivel 2 a CMM nivel 3 reducirá nuevamente los esfuerzos y defectos en aproximadamente un 50%! Ahora, los niveles de madurez del CMM no son exactamente los mismos niveles de capacidad del SPICE, pero el mensaje esta claro: Las Mejoras al Proceso de Software tendrán un efecto muy positivo tanto en Tiempo para Comercializarlo y Costo, así como en calidad del producto. Implementando RUP, estaremos en capacidad de alcanzar nivel de capacidad 3 para procesos seleccionados en un lapso de 2 – 3 años para equipos trabajando con RUP. Así que, aún cuando la inversión necesaria para implementar RUP conforme a “La Metodologia de Volvo IT” es considerable, nuestro potencial de ahorro es mucho mayor. La alta gerencia aceptó esta “serie de evidencias circunstanciales”, y nos dio la aprobación para seguir con el siguiente paso en el plan de implementación.

23

CCoonncclluussiioonneess __________________________________________________________________________________________

HHeemmooss aallccaannzzaaddoo llooss OObbjjeettiivvooss?? Basados en el feedback de los cuestionarios y testimonios de los clientes, la conclusión es que nosotros estamos moviéndonos en la dirección correcta. Clientes así como desarrolladores apoyan la nueva forma de trabajo y dicen que los requerimientos son de mejor calidad los cuales conducen a una más sólida arquitectura. Las posibilidades de administrar los cambiantes requerimientos y tener una primera versión del producto montado y funcionando más pronto en el proyecto se aprecia especialmente. Ellos también anticipan que el producto construido acorde al RUP debe ser fácil y más barato de mantener. El diagnóstico de SPICE resulta evidentemente indicando que la implementación del RUP incrementa la capacidad del Desarrollo de Aplicaciones. Sin embargo, hay un gran potencial para fomentar mejoras a la capacidad del proceso con crecimiento en la experiencia en RUP. Cuando este viene de”Un proceso común de Desarrollo de Aplicaciones” sabemos que tomará tiempo para alcanzar el objetivo. Probablemente esto tomará otros cinco años, pero hoy nosotros estamos confiados que este puede y debe ser hecho. RReeccoommeennddaacciioonneess GGeenneerraalleess Basados en nuestra experiencia y diagnóstico nosotros pensamos que este enfoque de implementación del RUP, también funcionara adecuadamente en otras organizaciones. Algunas de nuestros factores claves de éxito han sido:

• Participación de la Gerencia. Asegurarse que la administración brinda un soporte activo para la implementación del RUP desde el comienzo y durante todo el proyecto de implementación.

• Establecer un proyecto de implementación. Es importante separar este tipo de gran esfuerzo de las actividades normales en el campo de la organización. Establecer un proyecto separado hace posible dar al esfuerzo el foco y la atención necesarios.

o Ejecutar la Metodología. No implementar todas las partes del RUP en todas las partes de la compañía de inmediato. Implementar un nuevo proceso de desarrollo de aplicaciones es implementar una nueva forma de pensamiento y de trabajo en la compañía. Mucha competencia se ha construido a partir de diferentes roles y que toman tiempo.

o Roles bien definidos Y Responsabilidades. No intentar “imponer” el RUP dentro de la organización. Usar una organización corresponsabilidades bien definidas y distribuidas para coordinar la implementación y acompañamiento a los miembros del proyecto.

24

• Paquetes de Talleres (incluyendo material de soporte), para ser adaptado a las necesidades especificas del proyecto. Asegurar que usted puede soportar los proyectos RUP preparando buen material de soporte.

Sin embargo... para implementar nuevos procesos de desarrollo de aplicaciones como el RUP es aún un desafio para el equipo de mejoramiento del proceso de software y para la compañía. Algunas de las lecciones aprendidas son:

• Inversión Inicial. Toma tiempo y cuesta mucho dinero la implementación de un nuevo proceso de desarrollo. Por consiguiente el esfuerzo debería ser contemplado como una inversión en competencia. En cuanto a cada inversión usted debería estimar la rentabilidad.

• No menos preciar el factor humano. Para cambiar la forma de pensar y actuar de las personas toma tiempo. Es importante ser paciente.

A pesar de todo - Es posible!

25

NNoottaass __________________________________________________________________________________________ [ 1 ] Philipe Krutchen, The Rational Unified Process, An Introduction, Secon Edition, [ 2 ] Information about the SPICE Framework is available on the official homepage of SPICE at www.sqi.gu.edu.au/spice [ 3 ] Paulk M. C. et al. The Capability Maturity Model – Guidelines for improving the Software Process, Addison-Wesley, 1995. [ 4 ] The assessment of RUP 5.0 against an older version of SPICE is available at www.rational.com/products/rup/resource_center/media/RUP15504final.pdf [ 5 ] Jakobsson Marie, Predicting software quality with ISO/IEC TR 15504 – Capability determination of the Rational Unified Process, Master Thesis of Informatics 2000:M17, Department of Computer Science and Business Administration, University of Borås, Sweden. [ 6 ] Rifkin Stan., Climbing the SEI CMM Makes a Difference on Software Projects, in: IT Metrics Strategies, April 2001, The Cutter Consortium [ 7 ] Putnam Lawrence H., Linking the QSM Productivity Index with the SEI Maturity Level, available at: www.qsm.com select Resources, look under White Papers

26

EL SECRETO DETRÁS DE LA TECNOLOGIA DE

INFORMACIÓN INDUSTRIAL EXITOSA

Un problema, casi solucionado, aún es un problema no resuelto. Una solución que funcione en la teoría aún no es una solución. Un problema no esta resuelto hasta que la solución ha demostrado funcionar en la práctica.( y no ha se ha creado un nuevo problema). Así es como nosotros hemos aprendido a considerar estos problemas después de muchos años en medio de la realidad de la industria. Alcanzar el éxito no sólo requiere un completo conocimiento de las Tecnologías de la Información. También es necesario tener unas bases sólidas de los procesos industriales y las altas demandas de una compaña industrial interesada en alcanzar el éxito en el mercado actual. En Volvo IT usted tiene un socio que ha hecho de volvo el usuario líder de las Tecnologías de Información en la industria automotriz. Nosotros estamos complacidos de compartir nuestro conocimiento y experiencia con usted. Y lo que es más importante, nosotros no tememos asumir compromisos y estamos confiados del trabajo realizado.