Comparativo entre metodologías tradicionales y Ágiles
|
Modelo “codificar y corregir”
|
Respuestas
|
||||||||||||||||||||||||||||||||||||||||||
|
1: Definición
|
Es un modelo poco útil, pero
sin embargo bastante común Se puede tener una especificación formal, o no
tenerla Si no se ha utilizado formalmente un método, probablemente ya se esté
usando el método Codificar y Corregir en forma intuitiva Cuando se utiliza
éste método se empieza con una idea general de lo que se necesita construir,
Se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba
no formales que sirven hasta que se tiene el producto listo para entregarlo.
Ventajas: No conlleva ninguna gestión; no se pierde tiempo en la planificación, en la documentación, en el control de calidad, en el cumplimiento de los estándares, o en cualquier otra actividad que no sea codificación pura. Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso. Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa está familiarizada con éste modelo. Para proyectos pequeños que se intentan liquidar en un tiempo breve, o para modelos como programas de demostración o prototipos desechables, el modelo codificar y corregir puede ser útil. Desventajas: El modelo resulta peligroso para otro tipo de proyectos que no sean pequeños. Puede que no suponga gestión alguna, pero tampoco ofrece medios de evaluación del progreso. No proporciona medios de evaluación de la calidad o de identificación de riesgos. Si al llevar tres cuartas partes de la codificación descubre que el diseño es incorrecto, no hay otra solución que desechar el trabajo y comenzar de nuevo. |
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
2: Características
|
_Empieza
con una idea general.
-No lleva
ninguna gestión
-No pierde
tiempo en la planificación ni papeleo.
-No hay control
de calidad.
Codificación
pura.
-No se
necesita experiencia.
- solo
proyectos pequeños.
- Son
tiempos largos
|
||||||||||||||||||||||||||||||||||||||||||
|
Tomado
de imágenes de Google:
|
Características
de codificar y corregir
|
||||||||||||||||||||||||||||||||||||||||||
|
3: Etapas
|
CODE-AND-FIX.
-Codificar parte del software.
- Corregir errores, agregar funcionalidad a nuevos elementos.
|
||||||||||||||||||||||||||||||||||||||||||
|
Tomada
de imágenes de Google:
|
Etapas de cosificar y corregir
|
||||||||||||||||||||||||||||||||||||||||||
|
4: Ventajas
- Permite una construcción rápida el sistema
- Es útil para sistemas de un tamaño muy reducido, que no requiera más de dos o tres programadores y que no requiera un mantenimiento posterior - No pierde tiempo en las etapas de planificación, documentación, control de calidad... - Cualquiera, sin preparación técnica, lo puede utilizar |
5: Desventajas:
- Carece de cualquier control y gestión del proceso
- No dispone de las fases necesarias en todo proyecto de software: especificaciones, diseño... - Se dificulta la corrección de errores y el mantenimiento al carecer de una documentación del proceso adecuada - No proporciona medios de evaluación ni de prevención de riesgos - Resulta peligroso para proyectos grandes
-El código
es difícil de reparar por su pobre preparación para probar y modificar
|
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Se aplica a qué tipo de
proyectos
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Modelo en “cascada”
|
|
||||||||||||||||||||||||||||||||||||||||||
|
1: Definición
|
Es el enfoque
metodológico que ordena rigurosamente las etapas del ciclo de vida del
software, de tal forma que el inicio de cada etapa debe esperar a la finalización
de la inmediatamente anterior.
|
||||||||||||||||||||||||||||||||||||||||||
|
2: 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 personas de alta calificación.
No hay número definido
de iteraciones.
-Las iteraciones debe
definirlas el equipo de gestión de proyectos.
Más realista que el
ciclo de vida clásico.
-
Este
es el enfoque más realista actualmente
|
||||||||||||||||||||||||||||||||||||||||||
|
Tomado de imágenes de Google:
|
Características del modelo
cascada.
|
||||||||||||||||||||||||||||||||||||||||||
|
3: Ventajas:
- Es un modelo sencillo y disciplinado
-Es fácil aprender a utilizarlo y comprender su funcionamiento
- Está dirigido por los tipos de documentos y resultados que deben
obtenerse al final de cada etapa
- Ha sido muy usado y, por tanto, está ampliamente contrastado
- Ayuda a detectar errores en las primeras etapas a bajo costo
- Ayuda a minimizar los gastos de planificación, pues se realiza sin
problemas
|
4:
Desventajas:
- Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida
- Es difícil que el cliente exponga
explícitamente todos los requisitos al principio
-El cliente debe tener paciencia pues obtendrá el producto al final del
ciclo de vida
- No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo - Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones -El producto final obtenido puede que no refleje todos los requisitos del usuario |
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
5: Etapas
|
-Análisis de requisitos
- Diseño del Sistema y software - Diseño del Programa - Codificación - Pruebas
- Implantación
-Mantenimiento
|
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Modelo en “V”
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Definición
|
El modelo
representa, en forma de V, las relaciones temporales entre las distintas
fases del ciclo de desarrollo de un proyecto.
Es una representación
gráfica del ciclo de vida del desarrollo del sistema. Resume los pasos
principales que hay que tomar en conjunción con las correspondientes entregas
de los sistemas de validación.
La parte izquierda
de la V representa la corriente donde se definen las especificaciones del
sistema.
La parte derecha
de la V representa la corriente donde se comprueba el sistema (contra las
especificaciones definidas en la parte izquierda).
La parte de abajo,
donde se encuentran ambas partes, representa la corriente de desarrollo.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Características
|
-Muestra como se
relacionan las actividades de prueba en el análisis y diseño.
-Hace más
explícita la parte de las iteraciones y repeticiones de trabajo que están
ocultas en la modelo cascada.
Se centra en las
actividades y la corrección.
|
||||||||||||||||||||||||||||||||||||||||||
|
Tomado de imágenes de Google:
|
Modelo V
Características.
|
||||||||||||||||||||||||||||||||||||||||||
|
Ventajas:
-La relación entre las etapas de desarrollo y los distintos tipos de
pruebas facilitan la localización de fallos
- Es un modelo sencillo y de fácil aprendizaje - Hace explícito parte de la iteración y trabajo que hay que revisar - Especifica bien los roles de los distintos tipos de pruebas a realizar -Involucra al usuario en las pruebas |
Desventajas:
-Es difícil que el cliente exponga explícitamente todos
los requisitos
-El cliente debe tener paciencia pues obtendrá el producto al final del
ciclo de vida
- Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas - El producto final obtenido puede que no refleje todos los requisitos del usuario |
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Etapas
|
Análisis
Especificación
Diseño
Programación
Prueba
Documentación
Mantenimiento
Reingeniería
|
||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Se aplica a qué tipo de
proyectos.
|
En el desarrollo de Juegos de video.
|
||||||||||||||||||||||||||||||||||||||||||
|
Modelo en espiral
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Definición
|
Este es un
modelo de proceso de software evolutivo, el cual enlaza la naturaleza
iterativa de la construcción de prototipos,
pero conservado
aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe así:
El modelo de desarrollo en espiral es un generador de modelo de proceso
guiado por el riesgo que se emplea para conducir
sistemas intensivos de ingeniería de software concurrente y a la vez con
muchos usuarios.
|
||||||||||||||||||||||||||||||||||||||||||
|
Tomado de Internet:
|
El enlace está en la parte de abajo.
|
||||||||||||||||||||||||||||||||||||||||||
|
Características
|
-Un enfoque cíclico
para el crecimiento incremental del grado de definición e implementación de
un sistema,
mientras que disminuye
su grado de riesgo.
- Un conjunto de puntos
de fijación para asegurar el compromiso del usuario con soluciones de sistema
que sean factibles y mutuamente satisfactorias.
-Decidir
qué problema se quiere resolver antes de viajar a resolverlo.
-Examinar
tus múltiples alternativas de acción y elegir una de las más convenientes
- Evaluar
qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
- No ser tan ingenuo para
pensar que el sistema que estás construyendo será "EL" sistema que el
cliente necesita.
- Conocer
(comprender) los niveles de riesgo, que tendrás que tolerar.
|
||||||||||||||||||||||||||||||||||||||||||
|
Tomada de Internet:
|
El enlace está en la parte de abajo.
|
||||||||||||||||||||||||||||||||||||||||||
|
Ventajas
El modelo en espiral puede adaptarse y
aplicarse a lo largo de la vida del software de computadora.
-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 nivele evolutivos.
-El modelo en espiral permite a quien lo
desarrolla aplicar el enfoque de construcción de prototipos en cualquier
etapa de evolución del producto.
-El modelo en espiral 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 problemas.
-En la utilización de grandes sistemas
ha doblado la productividad.
|
Desventajas
-Resulta difícil convencer a grandes clientes de que
el enfoque evolutivo es controlable.
-Debido a su elevada complejidad no se aconseja
utilizarlo en pequeños sistemas.
-Genera mucho tiempo en el desarrollo del sistema
-Modelo costoso
-Requiere experiencia en la identificación de riesgos.
|
||||||||||||||||||||||||||||||||||||||||||
|
Tomado de internet:
|
El enlace está en la parte de abajo.
|
||||||||||||||||||||||||||||||||||||||||||
|
Etapas
|
-Comunicación con el cliente.
-Planificación.
-Análisis de riesgo.
-Ingeniería
-Evaluación del cliente
-Construcción y entrega.
|
||||||||||||||||||||||||||||||||||||||||||
|
A continuación, inserto la tabla con los
puntos 6,7,8,9,10:
|
|||||||||||||||||||||||||||||||||||||||||||
Tomado de internet:
Comentarios
Publicar un comentario