2. Te
xt
METODOLOGÍA
Es de un vocablo generado a partir de tres palabras de
origen griego:meta(“mas allá”), odós(“camino”) y logos
que es (“estudio”)
3. METODOLOGÍA EN
INGENIERIA DE
SOFTWARE
Una Metodología puede seguir uno o varios modelos de ciclo de vida, es
decir, el ciclo de vida indica qué es lo que hay que obtener a lo largo del
desarrollo del proyecto pero no cómo hacerlo.
La Metodología indica cómo hay que obtener los distintos productos
parciales y finales
4. CARACTERISTICAS
DESEABLES DE UNA
METODOLOGÍA
Existencia de reglas Predefinidas
Cobertura total del ciclo de Desarrollo
Verificaciones Intermedias
Planificación y Control
Comunicación Efectiva
Utilización sobre un abanico amplio de
proyectos
Fácil Información
Herramientas CASE
Actividades que mejoren el Proceso de
Desarrollo
Soporte al Mantenimiento
Soporte ala Reutilización de Software
5. MODELOS
PRESCRIPTIVOS
Los modelos prescriptivos de software fueron ideados originalmente para
ordenar el caos del desarrollo de software, y la historia nos muestro que el
uso de estos han tardío tanto un camino a seguir en el desarrollo de software
así como estructuras utiles.
8. MODELO CASCADA
El modelo de cascada original, publicada por Winston W. Royce en
1970, fue de hecho, no identificado por el nombre con el que
conocemos hoy en día. Royce, de hecho, presentó el modelo como
un modelo defectuoso y que no trabajan. Pero debido a las diversas
ventajas que este enfoque hacia el diseño de software y la aplicación
presentada, pronto se hizo muy popular en el mundo de desarrollo
de software.
9. El más conocido, esta basado en el ciclo
convencional de una ingeniería, el paradigma del
ciclo de vida abarca las siguientes actividades:
Ingeniería y
Análisis del
Sistema
Análisis de
Requisitos
Diseño
Codificación
Prueba
Mantenimiento
10. INGENIERÍA Y EL
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
11. 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 (Analistas) debe
comprender el ámbito de la información del software, así como la función, el
rendimiento y las interfaces requeridas.
12. 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.
13. CODIFICACIÓN
El diseño debe traducirse en una forma legible para la maquina. El paso de
codificación realiza esta tarea. Si el diseño se realiza de una manera detallada
la codificación puede realizarse mecánicamente.
14. 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.
15. MANTENIMIENTO
El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a
que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo
(sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento.
16. VENTAJAS
* No hace falta mencionar, es un modelo lineal y, por supuesto, los
modelos lineales son las más simples a ser implementadas.
* La cantidad de recursos necesarios para implementar este
modelo es mínimo.
* Una gran ventaja del modelo de cascada es que la
documentación se produce en cada etapa del desarrollo del
modelo de cascada. Esto hace que la comprensión del producto
diseñar procedimiento más sencillo.
* Después de cada etapa importante de la codificación de software,
las pruebas se realizan para comprobar el correcto funcionamiento
del código
17. DESVENTAJAS
• Los proyectos reales raramente siguen el flujo secuencial que propone el
modelo, siempre hay iteraciones y se crean problemas en la aplicación del
paradigma.
• Normalmente, es difícil para el cliente establecer explícitamente al principio
todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en
acomodar posibles incertidumbres que pueden existir al comienzo de
muchos productos.
• El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto, no estará disponible una versión operativa del programa. Un error
importante no detectado hasta que el programa este funcionando puede ser
desastroso.
