Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Transcripción

1 Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las metodologías de desarrollo de software, y en especial sobre Métrica 3 y metodologías ágiles. Como sucede generalmente los debates fueron mucho más instructivos que los textos. La cualidad de ser debates vía correo electrónico ha facilitado la recopilación que ofrecemos a continuación. Las preguntas y opiniones están escritas en estilo normal, mientras que las respuestas están escritas en cursiva. Las preguntas y opiniones expresan las ideas que se tienen acerca de los temas tratados. Se han copiado textualmente de los documentos originales, salvo muy pocas excepciones donde se han realizado pequeños retoques para mejorar la claridad. La decisión de recopilarlo prácticamente todo puede producir redundancia en algunos temas, pero los matices son interesantes. A) Aproximación convencional Es una técnica rígida para mejorar la calidad y reducir los costos del desarrollo de software. Tradicionalmente se conoce como modelo en cascada, porque su filosofía es completar un paso con un alto grado de exactitud, antes de empezar el siguiente. Los principales problemas que se han detectado en esta aproximación son debidos a que se comienza estableciendo todos los requisitos del sistema: 1. En muchas ocasiones no es posible disponer de unas especificaciones correctas desde el primer momento, porque puede ser difícil para el usuario establecer al inicio todos los requisitos. R: De acuerdo 2. En otras hay cambio de parecer de los usuarios sobre las necesidades reales cuando ya se ha comenzado el proyecto, siendo probables que los verdaderos requisitos no se reflejen en el producto final R: De acuerdo 3. Otro de los problemas de esta aproximación es que los resultados no se ven hasta muy avanzado el proyecto, por lo tanto la realización de modificaciones, si ha habido un error, es muy costosa. R: De acuerdo Entre los problemas que se pueden encontrar con este modelo, se tienen: 1. Los proyectos raras veces siguen el modelo secuencial que se supone. Los cambios pueden causar confusión. R: De acuerdo 2. Es difícil disponer en principio de todos los requisitos. Este modelo presenta dificultades en el momento de acomodar estas incertidumbres. R: De acuerdo 3. La versión operativa de los programas no está disponible hasta que el proyecto está muy avanzado. Un error importante puede ser desastroso, si se descubre al final del proceso. R: De acuerdo 1

2 4. Los responsables del desarrollo siempre se retrasan innecesariamente R: No de acuerdo. Aunque puede suceder de forma accidental. 5. Algunos integrantes del equipo de desarrollo han de esperar a otros para completar tareas pendientes. (secuencial) R: De acuerdo B) Aproximación prototipo Es habitual que en un proyecto software no se identifiquen los requisitos detallados de entrada, procesamiento o salida. En otros casos no se está seguro de la eficiencia de un algoritmo, o de la forma en que se ha de implantar la interfaz hombre-máquina. En casos así, lo habitual es construir un prototipo, que idealmente sirviera como mecanismo para identificar los requisitos del software. Las premisas clave de esta aproximación son: 1. Que los prototipos constituyen un medio mejor de comunicación que los modelos en papel 2. Que la iteración es necesaria para canalizar, en la dirección correcta, el proceso de aprendizaje. El problema, es que los usuarios finales, ven lo que parece ser una versión de trabajo del software, sin considerar que no es la versión definitiva y por lo tanto no se han considerado aspectos de calidad o facilidad de mantenimiento. Cuando se les dice que el producto es, a partir de entonces, cuando se debe de empezar a "fabricar", no lo entiende y empieza de nuevo con ajustes, lo cual hace este proceso muy lento. R: Los prototipos pueden ser desechables o evolutivos. El primero es propio de la cascada, mientras que el segundo es propio de los desarrollos cíclicos. Los problemas citados pertenecen a los desechables, pero no a los evolutivos. El conflicto entre el concepto de prototipo y calidad es artificial. C) Aproximación evolutiva En esta aproximación el énfasis está en lograr un sistema flexible y que se pueda expandir de forma que se pueda realizar muy rápidamente una versión modificada del sistema cuando los requisitos cambien. Se diferencia de la aproximación anterior, en que en ésta los requisitos cambian continuamente, lo cual implicaría en el caso previo que las iteraciones no tendrían fin. R: Esta aproximación facilita enfrentar la incertidumbre cuando las cosas cambian. Si la diferencia entre esta aproximación y la anterior es la infinitud de las iteraciones, entonces la anterior se refiere a prototipos desechables. D) Aproximación incremental Es muy parecido al de desarrollo evolutivo, y frecuentemente comprendido en él. Se comienza el desarrollo del sistema para satisfacer un subconjunto de requisitos especificados. Las últimas versiones prevén los requisitos que faltan. De esta forma se logra una rápida disponibilidad del sistema, que aunque incompleto, es utilizable y satisface algunas de las necesidades básicas de información. La diferencia con la aproximación anterior es que en este caso cada versión parte de una previa sin cambios pero con nuevas funciones, mientras que la aproximación evolutiva cada vez se desarrolla una nueva versión de todo el sistema. R: El desarrollo incremental No es parecido al desarrollo evolutivo. El desarrollo evolutivo parte de la premisa de la presencia inevitable de incertidumbre, mientras que el 2

3 desarrollo incremental supone que no hay incertidumbre. El desarrollo incremental está concebido para manejar complejidad dimensional, pero no complejidad por incertidumbre. E) Aproximación espiral Nace con el objetivo de captar lo mejor de la aproximación convencional y de la de prototipo, añadiendo un nuevo componente, el análisis de riesgos. Esquemáticamente se puede ilustrar mediante una espiral, con cuatro cuadrantes que definen actividades. En la primera vuelta de la espiral se definen los objetivos, las alternativas y las restricciones y se analizan y se identifican los riesgos. Si como consecuencia del análisis de riesgo se observa que hay incertidumbre sobre el problema entonces en la actividad correspondiente a la ingeniería se aplicará la aproximación prototipo cuyo beneficio principal es el de reducir la incertidumbre de la naturaleza del problema de información y los requerimientos que los usuarios establecen para la solución a ese problema (mucho mejor para eliminar incertidumbres que las anteriores, e incorpora también determinación de alternativas, eliminación de ambigüedad) Al final de esta primera vuelta alrededor de la espiral el usuario evalúa los productos obtenidos y puede sugerir modificaciones. Se comenzaría avanzando alrededor del camino de la espiral realizando las cuatro actividades indicadas a continuación. En cada vuelta de la espiral, la actividad de ingeniería se desarrolla mediante la aproximación convencional o ciclo de desarrollo en cascada o mediante la aproximación de prototipos. o Actividades o Acciones o Planificación Determinación de alternativas, identificación y resolución de riesgos o Ingeniería o Desarrollo y verificación del producto de siguiente nivel o Evaluación del cliente o Valoración de los resultados del proceso de desarrollo R: No elimina incertidumbre. La espiral está concebida como un camino prudente de enfrentar riesgos, sólo eso. Parece que la espiral realiza cada iteración según una cascada, y así se lo dijimos como crítica personalmente a Boehm, su autor. Pero él respondió que la espiral no contenía cascadas. Y nos alegramos, porque una iteración NO puede ser una cascada porque el concepto de iteración contradice al concepto de cascada. F) Aproximación basada en transformaciones Con la aparición de las herramientas CASE junto con los generadores de código, el ciclo de desarrollo software en cascada ha cambiado a un ciclo de vida basado en transformaciones. CASE es un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información. La utilización de herramientas CASE afecta a todas las fases del ciclo de vida del software, este ciclo de vida se puede considerar como una serie de transformaciones. Primero se definen los requisitos del sistema, seguidamente existe un proceso de transformación que hace que la especificación se convierta en un diseño lógico del sistema. Posteriormente, este sufre otro proceso de transformación para lograr un diseño físico, es decir que responda a la tecnología destino. La tecnología CASE propone que estos procesos de transformación sean lo más automatizables posibles. Sus ventajas son (eliminan parte de incertidumbre) o Posibilidad de comprobación de errores en etapas iniciales de desarrollo o Posibilidad de realizar el mantenimiento en el ámbito de especificación 3

4 o Soporte de rastreabilidad de los requisitos o Soporte de reusabilidad o Potencia la especificación orientada al problema R: NO. La Cascada está definida como una transformación de documentos, los CASE sólo son herramientas de ayuda al trabajo humano. Esta pretendida aproximación es un timo como aproximación y NO eliminan incertidumbre alguna. PRESENCIA DE INCERTIDUMBRE Y SU EFECTO LAS TÉCNICAS DE DISEÑO SOFTWARE ESTRUCTURADO Y ORIENTADAS A OBJETOS En las técnicas de desarrollo orientada a objetos, los objetos están representados por un conjunto de propiedades denominados atributos y un comportamiento implementado a través de métodos. Una de sus características es la abstracción (otras son la encapsulación, modularidad, jerarquía, herencia, polimorfismo, reusabilidad), por lo que estas técnicas son mucho más flexibles y aptas para soportar la ambigüedad (incertidumbre) que las técnicas de diseño software estructurado que son más rígidas en planteamientos y definiciones de propiedades y requisitos. La abstracción es la propiedad que permite representar las características esenciales de un objeto, sin preocuparse de otras más específicas y menos relevantes. R: El texto precedente se corresponde con la propaganda comercial de los objetos. Aunque contiene elementos ciertos, más bien es falso. El Desarrollo Orientado a Objetos (DOO) tiene como principios: 1. Desarrollo mediante un ciclo de vida iterativo e incremental: reduce la complejidad y favorece el perfeccionamiento 2. Desarrollo orientado a objetos con la realización de casos de uso. Desarrollo centrado en la arquitectura todo ello favorece el acotamiento de la incertidumbre R: Este texto se corresponde con el Proceso Unificado, que es un caso particular de DOO. El planteamiento del curso NO ES acotar, ni arrinconar la incertidumbre, puesto que es inevitable. La Ingeniería de Requisitos son metodologías y técnicas para producir los requisitos de un sistema a desarrollar, representando los requisitos las necesidades, metas y objetivos del sistema. Consta de una serie de actividades que sirvan para derivar, validar y mantener los requisitos, las tareas son: o Educción de requisitos o Análisis y negociación o Documentación de requisitos o Validación de requisitos o Gestión de los requisitos Con todo ello reducimos la incertidumbre y el riesgo de los requisitos sobre el sistema. R: seguro? 4

5 El Análisis Orientado a Objetivos es una aproximación a la educción y modelización, y persigue: o Situar los requisitos en un contexto amplio, de clientes y usuarios o Entender como el problema se relaciona con otros del entorno y con los objetivos de la organización donde operará el sistema o Aprender los requisitos correctos Todo ello favorece que haya menos incertidumbre en los requisitos, y por ende en el sistema a desarrollar. R: Seguro? Respuestas a preguntas de los profesores Es adecuado suponer, por ejemplo, que Métrica v3 implementa un ciclo de vida en cascada? Pienso que sí, porque como define el ciclo de vida: secuencia que se sigue para desarrollar productos software: procesos en secuencia (aunque dentro de cada procesos las actividades / tareas puedan ser concurrentes). Pero además creo que es una metodología ya que define: tareas, pasos a seguir, técnicas apropiadas en cada tarea, participantes en cada tarea, productos a generar en cada proceso,... R: Métrica tiene un fondo cartesiano, como ya comentamos. Pero, no se puede decir rotundamente que sigue una cascada dada su permisividad de actividades paralelas. Métrica 3 deja libertad para escoger el orden de realización de las actividades. Los métodos ágiles presuponen algún tipo de ciclo de vida para su ejecución? Creo que no. Creo que es más bien una filosofía de valores, ideas, conceptos y principios para aplicar en la metodología que se desarrolle, y eso lo veo en las: o Los diez principios útiles en la preparación y ejecución de proyectos o Los seis puntos clave ideales que los proyectos deben alcanzar o Los cuatro valores ágiles: Encauzamiento del desarrollo, Mejoras en la predictibilidad, Alejar los peligros y Disminución de costes R: De acuerdo, pero cada una de las tendencias de los Ágiles se autodenomina metodología, por ejemplo extreme Programming. Todos aspiran a ser metodologías, a establecer pautas, a ser dios. Preguntas a los profesores: 1. Cómo medimos la incertidumbre? con métodos de calidad? R: La incertidumbre se puede medir en términos de la cantidad de información que se necesita para resolver la incertidumbre. Pero, no creemos que sea necesario medirla en la construcción de software. Qué son métodos de calidad? Qué es calidad? Hay una definición única? 2. Cómo valoramos a priori el riesgo de la incertidumbre sobre un proyecto por el daño que puedan causar sus efectos nocivos? 5

6 R: Riesgo es una terna formada por: un suceso, una consecuencia desfavorable, incertidumbre). Si falta alguno de sus componentes no hay riesgo. La valoración del riesgo integra a todos sus componentes. 3. Con los métodos de prevención de riesgos, técnicas de seguridad, etc, evitamos incertidumbre, pero cómo buscar el equilibrio de coste beneficio entre los recursos asignados a un proyecto de más para evitar incertidumbre y los costes de no hacerlo? R: Los métodos citados NO evitan la incertidumbre. Si evitaran la incertidumbre eliminarían los riesgos y no lo hacen. La finalidad de tales métodos es tomar un seguro contra riesgos, que como seguro al fin, encarece el producto. No hay equilibrio, simplemente se trata de apostar, igual que en un seguro de cualquier otro tipo. 4. Es cierto que al final los método ágiles y las técnicas de desarrollo orientadas a objetos se adaptan mejor o manejan mejor la incertidumbre? Si esto es así porqué no se adoptan por el coste? por el nivel de desarrollo? R: Sí, los métodos ágiles y las técnicas orientadas a objetos facilitan mejor el manejo de la incertidumbre. Pero, como nada es gratis son más costosas. Por tanto, no siempre se justifican. Y además, su adopción general, como un camino más, requiere de un cambio cultural que se está produciendo, pero que no se ha completado aún. 6