Está en la página 1de 7

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Modelo de cascada
El modelo en cascada es un proceso de desarrollo secuencial, en el que el
desarrollo de software se concibe como un conjunto de etapas que se ejecutan
una tras otra. Está basado en el ciclo convencional de una ingeniería y su visión es
muy simple: el desarrollo de software se debe realizar siguiendo una secuencia de
fases. Cada etapa tiene un conjunto de metas bien definidas y las actividades dentro
de cada una contribuyen a la satisfacción de metas de esa fase o quizás a una
subsecuencia de metas de la misma.
Año y Autor
Winston W. Royce (1970)
Características
 Es el más utilizado
 Es una visión del proceso de desarrollo de software como una sucesión de
etapas que producen productos intermedios
 Para que el proyecto tenga éxito deben desarrollarse todas las fases
 Las fases continúan hasta que los objetivos se han cumplido
 Si se cambia el orden de las fases, el producto final será de inferior calidad
Etapas
1. Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de
un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los
elementos del sistema y luego asignando algún subconjunto de estos requisitos
al software.
2. Análisis de los requisitos del software: el proceso de recopilación de los
requisitos se centra e intensifica especialmente en el software. El ingeniero de
software debe comprender el ámbito de la información del software así como la
función, el rendimiento y las interfaces requeridas.
3. Diseño: el diseño del software se enfoca en cuatro atributos distintos del
programa; la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño traduce
los requisitos en una representación del software con la calidad requerida antes
de que comience la codificación.
4. Codificación: el diseño debe traducirse en una forma legible para la máquina. Si
el diseño se realiza de una manera detallada, la codificación puede realizarse
mecánicamente.
5. Prueba: una vez que se ha generado el código comienza la prueba del
programa. La prueba se centra en la lógica interna del software y en las
funciones externas, realizando pruebas que aseguren que la entrada definida
produce los resultados que realmente se requieren.
6. Mantenimiento: el software sufrirá cambios después de que se entrega al
cliente. Los cambios ocurrirán debidos a que se haya encontrado errores, a que
el software deba adaptarse a cambios del entorno externo (sistema operativo o
dispositivos periféricos) o a que el cliente requiera ampliaciones funcionales o
del rendimiento.
Ventajas y desventajas
Ventajas
 El tiempo que se pasa en diseñar el producto en las primeras fases del
proceso puede evitar problemas que serían más costosos cuando el proyecto
ya estuviese en fase de desarrollo.
 La documentación es muy exhaustiva y si se une al equipo un nuevo
desarrollador, podrá comprender el proyecto leyendo la documentación.
 Al ser un proyecto muy estructurado, con fases bien definidas, es fácil
entender el proyecto.
 Ideal para proyectos estables, donde los requisitos son claros y no van a
cambiar a lo largo del proceso de desarrollo.
Desventajas
 En muchas ocasiones, los clientes no saben bien los requisitos que
necesitarán antes de ver una primera versión del software en funcionamiento.
Entonces, cambiarán muchos requisitos y añadirán otros nuevos, lo que
supondrá volver a realizar fases ya superadas y provocará un incremento del
coste.
 No se va mostrando al cliente el producto a medida que se va desarrollando,
si no que se ve el resultado una vez ha terminado todo el proceso. Esto cual
provoca inseguridad por parte del cliente que quiere ir viendo los avances en
el producto
 Los diseñadores pueden no tener en cuenta todas las dificultades que se
encontrarán cuando estén diseñando un software, lo que conllevará
rediseñar el proyecto para solventar el problema.
 Para proyectos a largo plazo, este modelo puede suponer un problema al
cambiar las necesidades del usuario a lo largo del tiempo. Si por ejemplo,
tenemos un proyecto que va a durar 5 años, es muy probable que los
requisitos necesiten adaptarse a los gustos y novedades del mercado.
Modelo de espiral
Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa
de construcción de prototipos con los aspectos controlados y sistemáticos del
modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de
versiones incrementales del software.
Año y Autor
Barry Boehm (1976)
Características
 En cada giro se construye un nuevo modelo del sistema completo
 Este modelo puede combinarse con otros modelos de proceso de desarrollo
(cascada, evolutivo)
 Mejor modelo para el desarrollo de grandes sistemas
 El análisis de riesgo requiere la participación de personal con alta calificación
 No hay número definido de iteraciones. Las iteraciones debe decidirlas el
equipo de gestión de proyecto
 Más realista que el ciclo de vida clásico
 Este es el enfoque más realista actualmente
Etapas
1. Comunicación con el cliente: Las tareas requeridas para establecer
comunicación entre el desarrollador y el cliente.
2. Planificación: Las tareas requeridas para definir recursos, el tiempo y otra
información relacionadas con el proyecto.
3. Análisis de riesgos: Las tareas requeridas para evaluar riesgos técnicos y de
gestión.
4. Ingeniería: Las tareas requeridas para construir una o más representaciones de
la aplicación.
5. Construcción y acción: Las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario (por ejemplo: documentación y práctica)
6. Evaluación del cliente: Las tareas requeridas para obtener la reacción del cliente
según la evaluación de las representaciones del software creadas durante la
etapa de ingeniería e implementada durante la etapa de instalación. Cada una
de las regiones está compuestas por un conjunto de tareas del trabajo, llamado
conjunto de tareas, que se adaptan a las características del proyecto que va a
emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su
formalidad es bajo. Para proyectos mayores y más críticos cada región de
tareas contiene tareas de trabajo que se definen para lograr un nivel más alto
de formalidad. En todos los casos, se aplican las actividades de protección.
Ventajas y desventajas
Ventajas
 Puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
 Es un enfoque realista del desarrollo de sistemas y de software a gran escala.
 Como el software evoluciona, a medida que progresa el proceso el
desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en
cada uno de los niveles evolutivos.
 Utiliza la construcción de prototipos como mecanismo de reducción de
riesgos.
 Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos
en cualquier etapa de evolución del producto.
 Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida
clásico, pero lo incorpora al marco de trabajo iterativo que refleja de forma
más realista el mundo real.
 Demanda una consideración directa de los riesgos técnicos en todas las
etapas del proyecto, y, si se aplica adecuadamente, debe reducir los riesgos
antes de que se conviertan en problemáticos.
Desventajas
 Puede resultar difícil convencer a grandes clientes (particularmente en
situaciones bajo contrato) de que el enfoque evolutivo es controlable.
 Requiere una considerable habilidad para la evaluación del riesgo.
 No se ha utilizado tanto como los paradigmas lineales secuenciales o de
construcción de prototipos.
Desarrollo Rápido de Aplicaciones (RAD)
El método comprende el desarrollo iterativo, la construcción de prototipos y el uso
de utilidades CASE. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a
englobar también la usabilidad, utilidad y la rapidez de ejecución.
El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD)
es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza
un ciclo de desarrollo extremadamente corto. DRA es una adaptación a “Alta
velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de
construcción basado en componentes. Si se comprenden bien los requisitos y se
limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear
un “sistema completamente funcional” dentro de periodos cortos de tiempo.
Año y Autor
James Martin (1980)
Características
Equipos Híbridos
 Equipos compuestos por alrededor de seis personas, incluyendo
desarrolladores y usuarios de tiempo completo del sistema así como aquellas
personas involucradas con los requisitos.
 Los desarrolladores de RAD deben ser "renacentistas": analistas,
diseñadores y programadores en uno.
Herramientas Especializadas
 Desarrollo "visual"
 Creación de prototipos falsos (simulación pura)
 Creación de prototipos funcionales
 Múltiples lenguajes
 Calendario grupal
 Herramientas colaborativas y de trabajo en equipo
 Componentes reusables
 Interfaces estándares (API)
"Timeboxing"
 Las funciones secundarias son eliminadas como sea necesario para cumplir
con el calendario.
Etapas
1. Modelado de gestión: el flujo de información entre las funciones de gestión se
modela de forma que responda a las siguientes preguntas: ¿Qué información
conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la
genera? ¿A dónde va la información? ¿Quién la proceso?
2. Modelado de datos: el flujo de información definido como parte de la fase de
modelado de gestión se refina como un conjunto de objetos de datos necesarios
para apoyar la empresa. Se definen las características (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
3. Modelado de proceso: los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de información necesario para
implementar una función de gestión. Las descripciones del proceso se crean
para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la
comunicación entre los objetos.
4. Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta
generación. En lugar de crear software con lenguajes de programación de
tercera generación, el proceso DRA trabaja para volver a utilizar componentes
de programas ya existentes (cuando es posible) o a crear componentes
reutilizables (cuando sea necesario). En todos los casos se utilizan
herramientas automáticas para facilitar la construcción del software.
5. Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han
comprobado muchos de los componentes de los programas. Esto reduce tiempo
de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
Ventajas y desventajas
Ventajas
 Comprar puede ahorrar dinero en comparación con construir.
 Los entregables pueden ser fácilmente trasladados a otra plataforma.
 El desarrollo se realiza a un nivel de abstracción mayor.
 Visibilidad temprana.
 Mayor flexibilidad.
 Menor codificación manual.
 Mayor involucramiento de los usuarios.
 Posiblemente menos fallas.
 Posiblemente menor costo.
 Ciclos de desarrollo más pequeños.
 Interfaz gráfica estándar.
Desventajas
 Comprar puede ser más caro que construir.
 Costo de herramientas integradas y equipo necesario.
 Progreso más difícil de medir.
 Menos eficiente.
 Menor precisión científica.
 Riesgo de revertirse a las prácticas sin control de antaño.
 Más fallas (por síndrome de “codificar a lo bestia”).
 Prototipos pueden no escalar, un problema mayúsculo.
 Funciones reducidas (por “timeboxing”).
 Dependencia en componentes de terceros: funcionalidad de más o de
menos, problemas legales.