archivo

Archivo de la etiqueta: RUP

Barry Boehm es una buena referencia a la hora de considerar como adecuados determinados indicadores obtenidos en sus investigaciones y proyectos, no en vano siempre ha sido considerado como una de las referencias en el campo de la ingeniería del software, metodologías de desarrollo, estimación de costes y obtención y determinación de métricas relacionadas con el proceso de desarrollo.

Independientemente del indicador que cita Boehm y que indicaré al final de artículo, la propia experiencia nos dice que el coste de corrección de un error se dispara conforme nos alejamos del momento en que se ha producido. Esto es así porque un error arrastra tras de sí otros trabajos que correctos o no, se verán alterados por la corrección del mismo. Por ejemplo, una mala especificación de un requisito que llega a producción tendrá repercusión en el producto final, pero también su corrección requerirá un esfuerzo considerable por los diferentes artefactos que se tienen que modificar o incluso rehacer.

La aparición de los modelos de testing en V o de testing en W son una respuesta posible ante esos problemas, como también lo son la aplicación de otras técnicas en el proceso de construcción, como por ejemplo pruebas unitarias, integración continua, etc…

No solo afectó esta circunstancia a la aparición de modelos o técnicas de testing, sino que las metodologías de una u otra manera quedan impregnadas por la necesidad de detectar y corregir cuanto antes los errores (de hecho el propio testing en V no es más que una variante del ciclo de vida clásico o en cascada) como por ejemplo podemos ver en RUP o por la propia dinámica de desarrollo siguiendo metodologías ágiles.

Sobre la detección tardía de errores y sus implicaciones en los costes de un proyecto, Barry Boehm comenta lo siguiente (en relación a errores en etapas muy tempranas en el desarrollo, como lo son la obtención de especificaciones o requisitos): “Corrige los errores de especificación cuanto antes. Corregirlos después, costará: un 500% más en la etapa de diseño, un 1000% en la etapa de codificación, un 2000% en la etapa de testing unitario y un 20000% más en la entrega”.

He insistido en diferentes artículos que gran parte de la suerte del proyecto se juega antes de que comience. Una mala negociación, una mala venta condiciona todo lo demás (pudiéndose partir de una situación de Death March Project) y solo produciéndose determinadas circunstancias ideales: un equipo de proyecto motivado y de calidad y un cliente y unos usuarios que facilitan las tareas, pueden paliar las pérdidas del proyecto, tangibles (en dinero), como intangibles (de pérdida de imagen con el cliente ante un proyecto de ejecución deficiente).

Sin embargo, la venta inicial del producto es solo una de las variables que condicionan el posterior desarrollo del proyecto, la elección de una mala metodología ya sea por parte del proveedor o impuesta por el cliente puede hacer estragos en el trabajo realizado, en el coste y en los resultados.

Lo mismo si no se delimita de manera adecuada el alcance (ya sea antes de la venta o antes incluso de empezar a recoger requisitos).

Y después toca el análisis. Si la metodología condiciona un desarrollo en cascada la realización de un análisis excelente es esencial, si bien, todo se puede ir al traste en el momento en que cambia algunas de las variables del proyecto (interlocutores, procesos, etc…) y es que los modelos predictivos tienen ese problema.

Si la metodología es ágil o al menos iterativa incremental (como RUP), las tareas de análisis también son de gran importancia, aunque desarrollos iterativos y evolutivos dan un mayor margen para la corrección de deficiencias en la captura e interpretación de los requisitos y en el modelado de la solución.

Por tanto, independientemente de que en función de la metodología aplicada la realización de un buen análisis tenga una mayor importancia, en todas condiciona el resto del proyecto y muchísimo.

Un mal análisis, si se detecta en etapas tardías (en muchos casos, cuando el producto ha llegado a producción), provocará un más que probable fracaso de la puesta en marcha del sistema y un más que probable esfuerzo económico importante para resolver esta circunstancia, mediante mantenimientos correctivos y evolutivos, que podrían ser incluso no asumibles si la deuda técnica del desarrollo es elevada.

Pero es que un mal diseño también tiene consecuencias y muy importantes en el resultado final del software.

Por eso destaco siempre que, además de contar con buenos programadores, disponer de buenos analistas funcionales y orgánicos permite que el trabajo de los que codifican brille más y sobre todo, sea útil.

De ahí la importancia de realizar testing desde el principio, fundamento este que dió lugar, por ejemplo a las metodologías de testing en V o en W.

En resumen, aunque muchos piensen que el partido se juega en la construcción del software, si no se han realizado de manera adecuada las etapas anteriores, el partido se habrá perdido antes de que el árbitro de el pitido inicial.

Tanto si vamos a trabajar con metodologías ágiles, como con otras metodologías como RUP y sobre todo, en ciclos de vida clásicos o en cascada, resulta fundamental delimitar cuanto antes el alcance del proyecto.

Como mínimo hay que llegar a una primera aproximación en la negociación del contrato con el cliente (cuanto mejor sea la misma, más variables se tendrán a favor para hacer una correcta valoración en esfuerzo y plazos del proyecto) y es más que recomendable hacer otra aproximación al inicio del proyecto.

Acotar el alcance no debe ser entendido como poner límites al proyecto, al menos en el sentido estricto, ya que a través de la propia evolución del software, la aplicación tenderá a ir hacia donde van las expectativas del usuario. Pero sí se debe entender como un marco hacia donde enfocar el desarrollo, ya que no todas las funcionalidades que se quieren implementar son iguales de prioritarias o críticas.

El proyecto debe centrarse en lo verdaderamente importante, dejando para más adelante aquello que no lo es. Probablemente no habrá presupuesto (por lo menos en primera instancia) para todo, por lo que lo primordial es cubrir lo que resulta necesario.

Si no delimitamos el alcance, se quedarán demasiadas puertas abiertas por detrás, con el riesgo de que el cliente o usuarios quieran volver a ellas. Es cierto que al final el proyecto va hacia donde quiere el cliente o los usuarios, pero no es lo mismo tener pactado por escrito un alcance que no tenerlo y no es lo mismo hacer pedagogía desde el inicio del proyecto que no hacerla.

El prototipado es una técnica aplicable a prácticamente cualquier metodología de desarrollo ya que no es más que concretar en un entregable, que puede ir desde una serie de imágenes (para mostrar como sería el diseño de un formulario) hasta un producto software, las ideas que el usuario va lanzando sobre lo que quiere que la aplicación haga.

En ciertos tipos de ciclos de vida como el clásico o en cascada este tipo de técnica tiene mucho interés porque independientemente de que estas metodologías sean predictivas y no adaptativas, sí que resulta conveniente que por lo menos, de inicio, la diferencia entre lo que el usuario espera y lo que el analista interpreta sea la menor posible.

En metodologías evolutivas como lo son, por ejemplo, RUP o el conjunto de metodologías ágiles, cuando las iteraciones son cortas, la importancia del prototipado disminuye, si bien sigue resultando un instrumento muy útil cuando se trata de abstraer a un programa de ordenador un aspecto de negocio complejo o para intentar obtener la información más precisa posible del usuario, cuando este no tiene muy claro lo que quiere o no lo sabe explicar de manera adecuada.

Sobre el prototipado Larry Bernstein realiza la siguiente reflexión: “El prototipado reduce el tiempo de desarrollo y el coste en un 40%”.

David (Dave) Lorge Parnas es un profesional canadiense pionero en el campo de la ingeniería del software de la cual ha sido un ferviente defensor a lo largo de su carrera. Ha recibido numerosos premios a lo largo de su carrera y ha sido profesor en universidades de diferentes países del mundo.

El desarrollo de software se realiza para organizaciones que están en continuo movimiento: puede cambiar el mercado, los procesos, los usuarios, los responsables técnicos, etc…, a lo que hay que sumar que se intentan abstraer procesos que se realizan en el mundo real a un programa de ordenador y no es nada fácil ese proceso porque los que definen el sistema no tienen claro, por regla general, lo que quieren realmente (tienen una idea, pero hasta que no la ven reflejada, no terminan por matizarla).

La naturaleza del software es adaptativa, mediante aproximaciones y evoluciones se consiguen alcanzar productos que satisfacen las necesidades del usuario, a través del feedback que se obtiene de los mismos una vez que hacen uso del sistema. Los principios ágiles definen ese marco (que también se tiene en cuenta en metodologías del proceso unificado como RUP), si bien, nuestra propia experiencia personal nos dirigirá de alguna u otra forma y de forma paulatina hacia enfoques iterativos e incrementales en lugar de ciclos de vida clásico o en cascada.

Dave Parnas, sobre este tema realiza la siguiente reflexión (traducción libre): “Por regla general, los sistemas software no funcionan adecuadamente hasta que han sido utilizados y han fallado repetidamente en entornos reales”.

Martin Fowler creó el concepto de integración continua como una técnica o estrategia que consiste en programar automáticamente el proceso de compilación y ejecución de pruebas unitarias de un software que se está desarrollando.

El objetivo de la técnica consiste en detectar errores unitarios y de integración lo antes posible. Si se dejan estas comprobaciones para etapas muy tardías del proyecto los costes de corrección de estas incidencias se disparan) sobre todo en equipos de proyecto de tamaño medio o grande que trabajan en diferentes localizaciones).

No es una estrategia exclusiva de metodologías ágiles (podría ser utilizada perfectamente en metodologías del proceso unificado como RUP o en la fase de construcción de metodologías clásicas como por ejemplo el ciclo de vida en cascada), si bien su aplicación en las mismas resulta de gran importancia tanto en el proceso de desarrollo como para reducir los tiempos de implantación del sistema.

Se entiende integración continua cuando el proceso se programa para que se ejecute automáticamente. También podría considerarse cuando la integración se realice de forma planificada, aunque se realice de forma manual, en intervalos razonablemente cortos de tiempo. No es integración continua si se ejecuta de manera esporádica o en momentos próximos a la entrega.

El desarrollo siguiendo los principios ágiles tiene como objetivo principal conseguir la satisfacción del usuario a través del cumplimiento de sus expectativas.

El modelado de un proceso suele resultar complejo en el sentido de que se están informatizando unas dinámicas de trabajo que hasta ahora se realizaban utilizando otros instrumentos (incluyendo productos informáticos como por ejemplo soluciones ofimáticas para realizar determinadas tareas).

Resulta muy complicado en la mayoría de los casos acertar a la primera con una solución que satisfaga al usuario y sea productiva. La solución más adecuada se consigue a través del feedback.

Las metodologías unificadas como RUP o las ágiles tienen en cuenta esta dinámica de funcionamiento como algo natural en el desarrollo de software ya que tiene una naturaleza adaptativa y no predictiva (que es el enfoque que siguen las metodologías tradicionales, como el ciclo de vida clásico o en cascada).

Aceptar esta realidad no es perder el tiempo ya que lo que hace es aproximarte más hacia el objetivo. Perder el tiempo es desarrollar funcionalidades que no se van a utilizar o realizar documentación que no tiene ningún tipo de utilidad.