METOFOLOGIAS TRADICIONALES

1. METODOLOGÍA DE DESARROLLO DE SOFTWARE
Período académico: junio 2022 – octubre 2022
Docente Ing. Martin Luzon
METODOLOGÍA DEL DESARROLLO DE SOFTWARE

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:
Al final de la clase usted podrá:
Analizar los conceptos referentes a las metodologías de desarrollo de un software

4. Temática
 Presentación
 Puntos relevantes de la
asignatura(Syllabus,
dosificación)
 Evaluación diagnóstica
 Metodologías de desarrollo
tradicionales.
 Metodología RUP
 Actividad en clase
 Trabajo autónomo
 Preguntas

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?

43. Preguntas sobre el tema tratado

44. TRABAJO AUTÓNOMO
 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.
 Fecha de presentación: martes 14 de JUNIO del 2022 (19H50)
Nombre del archivo: APELLIDO_NOMBRE_DEBER1
Formato de presentación: PDF
Subir al enlace compartido por el docente.

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