Está en la página 1de 6

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
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
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
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
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
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.