1. METODOLOGÍA DE DESARROLLO DE SOFTWARE
METODOLOGÍA DE DESARROLLO TRADICIONALES
Docente Ing. Martin Luzon

3. OBJETIVO DE LA ASIGNATURA:
Aplicar una metodología de desarrollo de software durante el ciclo de vida de una
aplicación de manera autónoma.
OBJETIVO DE LA CLASE:
Conocer la importancia de la aplicación de una Metodología dentro del proceso de
desarrollo de un software.

4. Temática
 Metodologías de Desarrollo
Tradicionales
 Características
 Tipos de Metodologías T.
 Ventajas y desventajas
 Metodologías Tradicionales
vs Metodologías ágiles
 Metodología Tradicional
RUP

5. OBJETIVOS DE UNA METODOLOGÍA
Asegurar la
uniformidad y
calidad tanto
del desarrollo
como del
sistema en sí.
Satisfacer las
necesidades
de los usuarios
del sistema.
Conseguir un
mayor nivel de
rendimiento y
eficiencia del
personal
asignado al
desarrollo.
Ajustarse a los
plazos y costes
previstos en la
planificación.
Facilitar el
mantenimiento
posterior de
los sistemas.

6. OBJETIVOS DE UNA METODOLOGÍA
Definir
actividades a
llevarse a cabo
en un Proyecto
de Sistema de
Información.
Unificar criterios
en la
organización
para el
desarrollo del
Sistema de
Información.
Proporcionar
puntos de
control y
revisión.
Permitir
construir un
sistema
documentado y
que sea fácil de
mantener.
Ayudar a
identificar, lo
antes posible,
cualquier
cambio que sea
necesario
realizar dentro
del proceso de
desarrollo.

7. METODOLOGÍAS DE DESARROLLO TRADICIONALES
Desarrollar un software implica muchas cosas,
desde su planificación hasta su utilización se
deben de seguir un sinnúmero de pasos o
actividades. Hoy en día existen diversas
metodologías para hacerlo, sin embargo es
necesario definir primero la naturaleza del
software antes de elegir un determinado ciclo de
vida.
• Las metodologías tradicionales imponen una
disciplina de trabajo sobre el proceso de
desarrollo del software, con el fin de conseguir
un software más eficiente.

8. CARACTERÍSTICAS
• Una Metodología de desarrollo de
software, consiste en hacer uso de
diversas herramientas, técnicas,
métodos y modelos para el desarrollo.
• Este tipo de metodología, tienen la
necesidad de ser documentadas, para
que los programadores que estarán
dentro de la planeación del proyecto,
comprendan la metodología utilizada.
• Seguimiento detallado en cada una de
las fases.

10. TIPOS DE METODOLOGÍAS
TRADICIONALES

11. CASCADA ESPIRAL PROTOTIPO

12. VENTAJAS
• Evaluación en cada fase que
permite cambios de objetivos.
• Es sencillo al momento de aplicar
al desarrollo de software.
• Tiene un proceso de seguimiento
detallado en cada una de las
fases.

13. DESVENTAJAS
• La evaluación de riesgos es compleja.
• Con esto se puede poner al cliente en una
situación que puede ser muy incómoda
para él.
• El cliente deberá ser capaz de describir y
entender a un gran nivel de detalle para
poder acordar un alcance del proyecto
con él.

14. METODOLOGÍAS TRADICIONALES
VS
METODOLOGÍAS ÁGILES
• Con el paso del tiempo, las metodologías
tradicionales, simplemente no se iban a acoplar con
las nuevas tecnologías, los nuevos lenguajes y
sobretodo los programadores modernos. Es por ello
que se han desarrollado lo que son las metodologías
ágiles.
• Una metodología ágil, consiste principalmente en
trabajar con menos documentación de la que, como
vimos, las metodologías tradicionales utilizan en
todo momento.

15. METODOLOGÍAS ÁGILES
• Son aquellas que permiten adaptar la
forma de trabajo a las condiciones del
proyecto, consiguiendo flexibilidad e
inmediatez en la respuesta para acoplar
el proyecto y su desarrollo a las
circunstancias específicas del entorno.
• Las empresas que optan por esta
metodología consiguen gestionar sus
proyectos de forma flexible, autónoma y
eficaz reduciendo los costes e
incrementando su productividad.

16. POR QUÉ EMPLEAR METODOLOGÍAS ÁGILES
EN SU EMPRESA
• Mejoran la satisfacción del cliente dado que se involucrará y
comprometerá a lo largo de todo el proyecto.
• En cada etapa se informará al cliente de los logros y progresos del
mismo, con la visión de involucrarlo directamente para sumar su
experiencia y conocimiento.
• Optimizar las características del producto final obteniendo en todo
momento una visión completa de su estado.

17. POR QUÉ EMPLEAR METODOLOGÍAS ÁGILES
EN SU EMPRESA
• Mejora de la motivación e implicación del equipo de desarrollo, las
metodologías ágiles permiten a todos los miembros del equipo
conocer el estado del proyecto en cualquier momento, con esto se
logra que todos los miembros del equipo acepten los compromisos
del mismo.
• Permite ahorrar tiempo y costes el desarrollo ágil trabaja de un
modo más eficiente y rápido, con esto se logra cumplir de forma
estricta el presupuesto y los plazos pactados dentro de un proyecto.

18. Taller sobre las Metodologías Tradicionales
• Defina a cada Metodología
• Detalle 2 características por cada
metodología tradicional
• Mencione los roles de cada una
de las metodologías y elija un rol
el cual usted considere el mas
importante dentro del proceso

19. Preguntas sobre el tema tratado

21. METODOLOGÍA TRADICIONAL RUP
• Entre las principales metodologías tradicionales tenemos
los modelos conocidos como RUP y MSF, que centran su
atención en llevar una documentación exhaustiva de
todo el proyecto y además en cumplir con un plan de
proyecto, definido todo esto, en la fase inicial del
desarrollo del proyecto.
RUP es un proceso formal: Provee un acercamiento
disciplinado para asignar tareas y responsabilidades
dentro de una organización de desarrollo.

22. CARACTERÍSTICAS DE LA METODOLOGÍA RUP
• Forma disciplinada de asignar tareas y responsabilidades.
• Desarrollo iterativo.
• Administración de requisitos.
• Verificación de calidad de software.
• Pretende utilizar las mejores prácticas de desarrollo de
software.

23. FASES DE LA METODOLOGÍA RUP
• RUP divide el proceso en 4 fases, dentro de las cuales se realizan
varias iteraciones en número variable según el proyecto y en las
que se hace un mayor o menor esfuerzo en los distintas
actividades.

24. FASES DE LA METODOLOGÍA RUP
01
02
03
04
INICIO ELABORACIÓN
TRANSICIÓN CONSTRUCCIÓN

25. FASE 1: INICIO
• Esta fase tiene como propósito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados
al proyecto, proponer una visión muy general de la arquitectura de
software y producir el plan de las fases y el de iteraciones
posteriores.
• La fase de iniciación contiene los flujos de trabajo necesarios para
el acuerdo de las partes interesadas con los objetivos, la
arquitectura y la planificación del proyecto.

26. FASE 1: INICIO
• En esta etapa, los requisitos esenciales del sistema se transforman en
los casos de uso, esto conlleva a un proceso corto y se utiliza para
definir si es factible para continuar con el proyecto y definir los
riesgos y el coste del proyecto.

27. • En esta fase se establece el caso del negocio para el
sistema y se delimita el alcance del proyecto. Para
lograrlo, es necesario identificar todas las entidades
con las que el sistema va a interactuar (actores) y se
define la naturaleza de esta interacción a alto nivel. Lo
que implica identificar todos los casos de uso y
describir algunos (los más significativos).
• El caso de negocio incluye criterio de éxito, evaluación
de riesgos y estimación de recursos necesarios, y un
plan de fase que muestre las fechas de las etapas
principales.

28. ENTREGABLES AL FINAL DE LA FASE
• Documento de visión: Visión general de requerimientos,
características clave y restricciones principales.
• Modelo de casos de uso inicial
• Glosario de proyecto inicial
• Caso de negocio Inicial: Incluye contexto del negocio,
criterio de éxito y pronóstico financiero
• Evaluación de riesgos inicial
• Modelo de negocio, en caso de ser necesario

29. Los criterios de evaluación para la fase de
Inicio son:
• Concurrencia de las partes interesadas en la definición de alcance y
estimación de costos/programas (horarios).
• Evidencia de entendimiento de los requerimientos mediante la
comprobación de los casos de uso primarios.
• Credibilidad de los estimados de costos/programas, prioridades,
riesgos y proceso de desarrollo.
• Detalle y extensión de cualquier prototipo arquitectónico que se ha
desarrollado.
• Gastos actuales Vs. Gastos planeados.

30. FASE 2: ELABORACIÓN
• La elaboración consiste en la preparación para el diseño del
sistema, como complemento de la documentación de casos de
uso, frente a la arquitectura del sistema, revisar el modelo de
negocio para el proyecto e iniciar la versión del manual del usuario
y se debe tener las siguientes aceptaciones:
• Descripción del producto si es estable ? El plan del proyecto es
fiable?; Los costos son elegibles?

31. • El propósito de la fase de elaboración es analizar el dominio del
problema, establecer un fundamento arquitectónico, desarrollar el plan
del proyecto y eliminar los elementos de mayor riesgo para el proyecto.
Para lograr estos objetivos, se debe tener una vista del cuadro completo
del sistema. Las decisiones sobre la arquitectura se deben hacer
entendiendo el sistema completo: su alcance, requerimientos
funcionales y no funcionales como requerimientos de rendimiento.

32. El resultado de la fase de elaboración es:
• Un modelo de caso de uso (completo por lo menos el 80%), en donde todos los
casos de uso y actores han sido identificados y más casos de uso han sido
elaborados.
• Requerimientos suplementarios capturando lo requerimientos no funcionales y
cualquier requerimiento que no esté asociado con un caso de uso específico.
• Descripción de una Arquitectura de Software.
• Prototipo arquitectónico ejecutable.
• Lista de riesgos y casos de negocio revisados.
• Un plan de desarrollo para el proyecto global, incluyendo el plan del proyecto
desglosado, mostrando iteraciones y criterios de evaluación para cada iteración.
• Un caso de desarrollo actualizado especificando el proceso que se usará.
• Un manual de usuario preliminar

33. Al final de la fase de elaboración se da el segundo mayor hito del ciclo
de vida. En este punto se examina los objetivos y alcance detallados
del sistema, la selección de la arquitectura y la resolución de los
mayores riesgos.

34. Los criterios de evaluación para esta fase
deben responder las siguientes preguntas:
• ¿La visión del producto es estable?
• ¿La arquitectura es estable?
• ¿La demostración ejecutable muestra que los elementos de mayor riesgo han sido
direccionados y realmente resueltos?
• ¿El plan para la construcción de la fase fue lo suficientemente detallado y preciso?
¿Está respaldado con una base de estimaciones creíble?
• ¿Todas las partes interesadas están de acuerdo en que la visión actual puede ser
alcanzada si el plan actual se ejecuta para desarrollar el sistema completo, en el
contexto de la arquitectura actual?
• ¿Los gastos actuales vs. los gastos planeados son aceptables?

35. FASE 3: CONSTRUCCIÓN
• En la fase de construcción, el desarrollo físico del software se
inicia, códigos de programación y las respectivas pruebas.
• Se debe aceptar las pruebas para un proceso estable, y el código
del sistema puesto que son líneas base para su desarrollo.

36. En la fase de construcción, todos los componentes que faltan y las
características de la aplicación se desarrollan e integran en el producto, y todas
las características se prueban.
La fase de construcción es de cierto modo un proceso de manufactura que
pone énfasis en manejar los recursos y controlar las operaciones para optimizar
costos, programaciones y calidad.
Como mínimo consiste de:
• Producto de software integrado en la
plataforma adecuada.
• Manuales de usuario.
• Descripción de la versión actual.

37. El criterio de evaluación para la fase de construcción debe
responder las siguientes preguntas:
• ¿La versión del producto es suficientemente estable y madura para ser
desplegada a la comunidad de usuarios?
• ¿Están todas las partes interesadas listas para la transición en la comunidad
de usuarios?
• ¿Los costos actuales vs. los costos planeados siguen siendo aceptables?

38. FASE 4: TRANSICIÓN
• En esta fase es la entrega de software, que se lleva a cabo el plan
de despliegue y entrega, el seguimiento y la calidad del software.
• Es la entrega del producto, se verifica la satisfacción del cliente.
• En esta etapa también se lleva a cabo la formación de los usuarios
que viene a ser las capacitaciones al personal encargado del
manejo del sistema.

39. El propósito de la fase de transición es justamente la transición del producto de software en
la comunidad de usuarios.
Una vez que el producto se ha entregado al usuario final, surgen inconvenientes y requieren
nuevas versiones, corregir algunos problemas o terminar las características que fueron
pospuestas.
La fase de transición se da cuando una línea base está suficientemente avanzada para ser
desplegada en el dominio del usuario final.
Esto requiere casi siempre que algunos subconjuntos utilizables del sistema se hayan
completado en un nivel aceptable de calidad y que la documentación de usuario esté
disponible de manera que la transición de resultados positivos para todas las partes.

40. En este punto del ciclo de vida la retroalimentación de los usuarios debe ser
tomada primariamente para ajustar, configurar, instalar y ver las dificultades
de usabilidad del producto.
Los objetivos primarios de la fase de transición incluyen:
• Lograr que el usuario pueda usar el producto por sí mismo.
• Lograr que la concurrencia desplegada de las partes interesadas esté
completa y consistente con el criterio de evaluación de la visión.
• Lograr la línea base del producto final tan rápida y económicamente
efectiva como sea posible.

41. Al final de la fase de transición se da el cuarto hito mayor del proyecto.
En este punto se decide si los objetivos fueron logrados y si se debería
empezar otro ciclo de desarrollo.
Los criterios de evaluación para esta fase responden las siguientes
preguntas:
• ¿El usuario está satisfecho?
• ¿Los costos actuales vs. los costos planeados siguen siendo aceptables?

44. Trabajo en Clase
• De las fases de la metodología
RUP revisadas en clases,
seleccione los puntos más
relevantes que usted considere y
plasme en un organizador
gráfico.

45. Preguntas sobre el tema tratado

46. Palabras
Iteración: Es el acto de repetir un proceso, para generar una secuencia de
resultados, con el objetivo de acercarse a un propósito o resultado deseado.