Metodologías de Desarrollo

1. Metodologías de Desarrollo
Ing. Noretsys Rodríguez

2. DEFINICIÓN
Conjunto integrado de técnicas y métodos que permiten abordar de
forma homogénea y abierta cada una de las actividades del ciclo de vida
de un proyecto de desarrollo
Proceso de software detallado y completo
Comprende los procesos a seguir para idear, implementar y mantener un
producto de software desde que surge la necesidad hasta que se cumple el
objetivo por el cual fue creado.
se basan en una combinación de los modelos de proceso genéricos (cascada,
incremental…). Definen artefactos, roles y actividades, junto con prácticas y técnicas
recomendadas.

3. IMPORTANCIA
DESDE LA
GESTIÓN
Facilita la tarea de Planificación.
Facilita la tares de control y seguimiento de un proyecto.
Mejora la relación costo / Beneficio.
Optimiza el uso de recursos disponibles.
Facilita la evaluación de resultados y cumplimiento de objetivos.
Facilita la comunicación Usuario – Desarrollador.
DESDE LOS
INGENIEROS DE
SOFTWARE
Ayuda a la comprensión del problema.
Optimiza cada una de las fases del proceso de desarrollo.
Facilita el mantenimiento del producto final.
Permite la reutilización del partes del producto.
DESDE EL CLIENTE
O USUARIO
Garantía de la calidad del producto.
Confianza en los plazos de tiempo fijados en la definición
del proyecto.

4. ES IMPORTANTE TENER PRESENTE:
El cliente demanda sistemas de software eficientes, con
un alto desempeño funcional y alta calidad.
Nace la necesidad de contar con una metodología para
gestionar los proyectos bajo un enfoque disciplinado y
sistemático.
Existen variedad de metodologías de desarrollo y no
siempre se escoge la mas adecuada, o se termina
proponiendo una nueva

5. ENFOQUES SOBRE EL DESARROLLO
DE SOFTWARE
Cada metodología de desarrollo tiene más o menos su
propio enfoque de en lo que debería de consistir un
proyecto de desarrollo de software.
Pero todas ellas se basan en una serie de enfoques
generalistas como son:
• Waterfall Model – Lineal
• Prototyping – Iterativo
• Incremental – combinación de iterativo y lineal
• Spiral – Combinación de iterativo y lineal
• Rapid Application Development (RAD) -- iterativo

6. WATERFALL MODEL – MODELO
CASCADA
El desarrollo se ve como una serie de
escalones descendentes (como si se
tratara de una cascada de agua) a través
de las distintas fases.
– Analisis
– Diseño
– Desarrollo
– Pruebas
– Integración
– Mantenimiento
Creada en 1970 por Winston W. Royce

7. PRINCIPIOS MODELO CASCADA
El proyecto se divide en fases secuenciales, se
permite algún tipo de solapamiento entre las
distintas fases.
• Hace enfasis en la planificación, los tiempos,
fechas objetivo, presupuestos y en la
implantación del sistema completo al mismo
tiempo.
• Se mantiene un férreo control durante la duración
del proyecto a través del uso extensivo de
documentación así como a través de revisiones y
aprobaciones por los usuarios y gestores del
proyecto, al final de cada fase antes de comenzar
la siguiente.

8. PROTOTIPO - ITERATIVO
Se conoce así a las actividades de creación de
prototipos durante el desarrollo de software, los
prototipos son versiones incompletas del
producto que va ha ser desarrollado.

9. PRINCIPIOS
No es una metodología que funcione por si sóla, es mas una vía
para manejar determinadas fases de una metodología más
tradicional y amplia (Incremental, Espiral o RAD)
Intenta reducir el riesgo inherente al proyecto dividiendo el
proyecto en partes más pequeñas.
El usuario está más involucrado a través del proyecto, y eso
hace que se incremente la aceptación final del producto por los
usuarios.
Se van realizando maquetas a menor escala siguiendo una
política de modificaciones hasta culminar los requerimientos de
los usuarios.
Mientras que la mayoría de los prototipos se desarrollan con la
expectativa de ser deshechos, es posible en algunos casos
evolucionar los prototipos hacia el sistema final

10. INCREMENTAL – ITERATIVO + LINEAL
Es la combinación de metodologías iterativas y lineales con el
objetivo primario de reducir los riesgos del proyecto, los
proyectos se dividen en partes mas pequeñas, de esta
manera también se facilitan los cambios durante el proceso
de desarrollo.
Se realizan una serie de mini-waterfalls, donde todas las fases del
desarrollo en cascada se completan para una pequeña parte del
sistema, antes de abordar la siguiente parte.
Los conceptos iniciales del sistema, análisis de requerimientos,
diseño de arquitectura, etc. Del sistema completo se definen
usando también la técnica de Cascada.
Después de esto mediante prototipos se van desarrollando las
distintas partes en las que ha sido dividido el proyecto.
Finalmente el proceso culmina con la implantación del sistema en
su conjunto (otro mini-waterfall)
Principios

11. ESPIRAL
Consiste en una serie de ciclos que se repiten en
forma de espiral, comenzando desde el centro.
El Espiral puede verse como un modelo evolutivo
que conjuga la naturaleza iterativa con los
aspectos controlados y sistemáticos del Modelo
Cascada, con el agregado de gestión de riegos.
Este método está indicado en grandes proyectos.

12. ESPIRAL
En cada vuelta o iteración hay que tener en
cuenta:
Los Objetivos: Que necesidad debe cubrir el producto.
Alternativas: Las diferentes formas de conseguir los
objetivos de forma exitosa, desde diferentes puntos de
vista como pueden ser:
Características: experiencia del personal, requisitos a cumplir,
etc.
Formas de gestión del sistema.
Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software

13. ESPIRAL
Si el resultado no es el adecuado o se necesitan mejoras:
Se planifican los siguientes pasos y se comienza un nuevo
ciclo de la espiral, la espiral tiene dos dimensiones, la
radial y la angular.
Angular
Indica el avance del proyecto dentro de un ciclo
Radial
Indica el aumento del coste del proyecto, ya que con
cada nueva iteración se pasa más tiempo
desarrollado

14. ESPIRAL

15. RAPID APLICATION DEVELOPER - RAD
Este método comprende el desarrollo iterativo, la
construcción de prototipos y el uso de herramientas CASE.
Aporta la velocidad del desarrollo , principalmente por el
uso de las herramientas CASE.
La Calidad es otra de sus características, mediante la
implicación del usuario en las etapas de análisis y diseño.
Apropiado para proyectos de pequeña embergadura.
Pone énfasis en el cumplimiento de las expectativas del
negocio, mientras que las características técnicas o la
excelencia del desarrollo tiene menos importancia.

16. RAD
El control del proyecto da prioridad a las fases de
desarrollo.
Si el proyecto empieza a excederse en tiempos, se
considera reducir los requerimientos, no aumentar los
tiempos.
Los usuarios están especialmente involucrados (esto es
imperativo) en las fases de diseño mediante el uso de
sesiones de trabajo (workshops).
Produce documentación para facilitar la evolución futura
del producto y el mantenimiento.

17. RATIONAL UNIFIED PROCESS - RUP
Controla: Proceso para el desarrollo de software
iterativo que constituye la metodología estándar más
utilizada para el análisis, implementación
y documentación de sistemas orientado a objetos.
Definición: Marco de trabajo de proceso adaptable,
con la idea de ser adaptado a las organizaciones de
desarrollo y los equipos de proyecto de software
Se basa: en un conjunto de módulos o elementos de
contenido, que describen qué se va a producir, las habilidades
necesarias requeridas y la explicación paso a paso
describiendo cómo se consiguen los objetivos de desarrollo.

18. CARACTERÍSTICAS DE RUP
Forma disciplinada de asignar tareas y
responsabilidades (quien hace que, cuando y
cómo).
Pretende implementar las mejores prácticas en
Ingeniería de software.
Desarrollo Iterativo.
Administración de requisitos.
Uso de arquitectura basada en componentes.
Control de cambios.
Modelado visual de software.
Verificación de la calidad del software.

19. MÓDULO PRINCIPALES
Roles (quién): un rol define un conjunto de
habilidades, competencias y
responsabilidades relacionadas.
Productos de trabajo (qué): un producto de
trabajo representa algo que resulta de una
tarea, incluyendo todos los documentos y
modelos producidos mientras que se trabaja
en el proceso.
Tareas (cómo): una tarea describe una unidad
de trabajo asignada a un rol que proporciona
un resultado significante.

20. PRINCIPIOS
Adaptar el proceso
El proceso deberá adaptarse a las características propias del
proyecto u organización, El tamaño del mismo, así como su tipo o
las regularizaciones que lo condicionen, incluirán en su diseño
específico.
También se deberá tener en cuenta el alcance del proyecto.
Balancear Prioridades
Los requerimientos de los distintos participantes pueden ser
diferentes, contradictorios o disputarse recursos limitados.
Debe encontrarse un balance que satisfaga los deseos de todos.
Debido a este balanceo se podrán corregir desacuerdos en el
futuro.

21. + PRINCIPIOS
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en
etapas iteradas.
En cada iteración se analiza la opinión de los inversores, la
estabilidad y calidad del producto, y se refina la dirección del
proyecto, así como también los riesgos involucrados.
Elevar el nivel de abstracción
Persigue el uso de elementos reutilizables tales como los
patrones de software, lenguajes 4GL o frameworks.
Desarrollo con la mente puesta en la reutilización del código
Un alto nivel de abstracción también permite discusiones sobre
diversos niveles y soluciones arquitectónicas.

22. + PRINCIPIOS
Enfocarse en la calidad
El control de la calidad no debe realizarse al final de cada
iteración, sino en todos los aspectos de la producción.
El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.

23. FASES DE RUP
Las primeras iteraciones (en las fases de inicio y
elaboración) se enfocan hacia:
La comprensión del problema y la tecnología.
La delimitación del ámbito del proyecto.
La eliminación de los riesgos críticos y al
establecimiento de la línea de base de la
arquitectura.

24. FASES DE RUP
Fase de Iniciación
Las iteraciones hacen mayor énfasis en actividades de modelado del
negocio y de requerimientos.
Fase de elaboración
Las iteraciones se orientan al desarrollo de la línea de base de la
arquitectura, abracan más los flujos de trabajo de requerimientos,
modelos de negocio, análisis, diseño e implementación orientada a la línea
de base de la arquitectura.
Fase de Construcción
Se lleva a cabo la construcción del producto mediante series de
iteraciones.
Para cada iteración se seleccionan algunos casos de uso, se refina su
análisis y diseño y se procede a su implementación y pruebas.
Se realiza una pequeña cascada para cada ciclo.
Se realizan tantas iteraciones como requiera la implementación del
producto.
Fase de Transición
Se pretende garantizar que se tiene un producto preparado para su
entrega a los usuarios.

25. ARTEFACTOS
Sirven para comprender mejor tanto el análisis como
del diseño del sistema.
Fase de Inicio
Documento Visión
Especificación de requerimientos
Fase de elaboración
Diagramas de caso de uso
Fase de construcción
Vista lógica
Diagrama de clases
Modelo ER

26. FASES DE RUP
Vista de implementación
Diagrama de Secuencia
Diagrama de estados
Diagrama de colaboración
Vista conceptual
Modelo de dominio
Vista física
Mapa de comportamiento HARDWARE

27. METODOLOGÍAS ÁGILES
Método para desarrollar Software
Característica principal : adaptación al cambio
Opuesto a métodos tradicionales (predictivos)
Definen de entrada:
Alcance (funcionalidad, tecnología, etc..)
Costos
Tiempos (de inicio a fin del proyecto)
Establecen métodos de monitorización y control para
prevenir desvíos.
Realizan iteraciones cortas entre 2 y 4 semanas.

28. MANIFIESTO ÁGIL
• Individuos e iteraciones
– Prioridad
• Calidad profesional del equipo
• Entrega temprana y continua
– Cada 2 o 4 semanas se entrega software funcional 100% operativo
VS (tradicional)
Procesos y herramientas
Debe servir de ayuda pero no pueden ser el objetivo

29. MANIFIESTO ÁGIL
• Colaboración con el cliente
– Prioridad
• Participación con el cliente
• Comunicación directa y continua
En XP el cliente está físicamente presente en el momento del desarrollo
VS
Negociación contractual
Sólo el cliente conoce lo que da verdadero valor al negocio

30. MANIFIESTO ÁGIL
• Software funcionando
– Prioridad
• Satisfacción del cliente
• Aportar valor al negocio
Parte del desarrollo (código documentado) es la documentación del proyecto
VS
Documentación extensiva
Debe servir de complemento pero no ser un impedimento

31. MANIFIESTO ÁGIL
• Respuesta ante el cambio
– Prioridad
• Aceptar cambios de requerimientos
• Ventaja competitiva para el negocio
VS
Seguir un plan
El cliente no está realmente seguro hasta que no prueba el software

32. METODOLOGÍA SCRUM
Definición: Scrum es una metodología ágil y flexible para
gestionar el desarrollo de software, cuyo principal objetivo
es:
Maximizar el retorno de la inversión para su empresa (ROI)
Se basa en construir primero la funcionalidad de mayor valor
para el cliente y en los principios de inspección continua,
adaptación, auto-gestión e innovación.
Uso: gestionar y controlar desarrollos complejos de software y productos usando
prácticas iterativas e incrementales.

33. BENEFICIOS DE SCRUM
Cumplimento de expectativas: El cliente establece sus
expectativas indicando el valor que le aporta cada requisito
/ historia del proyecto, el equipo los estima y con esta
información el cliente establece su prioridad. De manera
regular, el cliente comprueba que efectivamente los requisitos
se han cumplido y transmite se feedback al equipo.
Flexibilidad a cambios: Alta capacidad de reacción ante los
cambios de requerimientos generados por necesidades del
cliente o evoluciones del mercado. La metodología está
diseñada para adaptarse a los cambios de requerimientos que
conllevan los proyectos complejos.
Reducción del Time to Market: El cliente puede empezar a
utilizar las funcionalidades más importantes del proyecto antes
de que esté finalizado por completo.

34. BENEFICIOS DE SCRUM
Mayor calidad del software: La metódica de trabajo y la
necesidad de obtener una versión funcional después de cada
iteración, ayuda a la obtención de un software de calidad
superior.
Mayor productividad: Se consigue entre otras razones,
gracias a la eliminación de la burocracia y a la motivación del
equipo que proporciona el hecho de que sean autónomos
para organizarse.
Maximiza el retorno de la inversión (ROI): Producción de
software únicamente con las prestaciones que aportan
mayor valor de negocio gracias a la priorización por retorno
de inversión.

35. BENEFICIOS DE SCRUM
Predicciones de tiempos: Mediante esta metodología se
conoce la velocidad media del equipo por sprint (los
llamados puntos historia), con lo que consecuentemente, es
posible estimar fácilmente para cuando se dispondrá de una
determinada funcionalidad que todavía está en proceso de
desarrollo.
Reducción de riesgos: El hecho de llevar a cabo las
funcionalidades de más valor en primer lugar y de conocer la
velocidad con que el equipo avanza en el proyecto, permite
despejar riesgos eficazmente de manera anticipada.

36. PROCESO DE SCRUM
El desarrollo se realiza de forma iterativa e
incremental. Cada iteración,
denominada Sprint, tiene una duración
preestablecida de entre 2 y 4 semanas, obteniendo
como resultado una versión del software con nuevas
prestaciones listas para ser usadas. En cada
nuevo Sprint, se va ajustando la funcionalidad ya
construida y se añaden nuevas prestaciones
priorizándose siempre aquellas que aporten mayor
valor de negocio.

37. PROCESO DE SCRUM
Product Backlog: Conjunto de requisitos denominados historias descritos en un
lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por
retorno de inversión considerando su beneficio y coste.
Sprint Planning: Reunión durante la cual el cliente presenta las historias del
backlog por orden de prioridad. El equipo determina la cantidad de historias que
puede comprometerse a completar en ese sprint y organiza cómo lo va a
conseguir.
Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para
convertir las historias del cliente a las que se ha comprometido, en una nueva
versión del software totalmente operativo.
Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del
sprint.
Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo
se sincroniza para trabajar de forma coordinada.
Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el
equipo presenta las historias conseguidas mediante una demonstración del
producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien,
qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.

38. ROLES DE SCRUM
Scrum master: Persona que lidera al equipo
guiándolo para que cumpla las reglas y procesos de
la metodología. Gestiona la reducción de
impedimentos del proyecto y trabaja con el Product
Owner para maximizar el ROI.
Product owner (PO): Representante de lso
accionistas y clientes que usan el software. Se
focaliza en la parte de negocio y el es responsable del
ROI del proyecto (entregar un valor superior al dinero
invertido). Traslada la visión del proyecto al equipo,
formaliza las prestaciones en historias a incorporar
en el Product Backlog y las reprioriza de forma
regular.
Team: Grupo de profesionales con los conocimientos
técnicos necesarios y que desarrollan el proyecto de
manera conjunta llevando a cabo las historias a las
que se comprometen al inicio de cada sprint.

39. OOWS
Fue creado en la Universidad Politécnica de
Valencia.
OOWS proviene de OO-Method (Método
Orientado a Objetos) .
metodología de desarrollo de software
basada en una clara separación del
Espacio del Problema (el 'qué') del Espacio
de la Solución (el 'cómo').
OOWS se basara en el enfoque bottom-up.

40. CARACTERISTICAS DE OOWS
Aborda de forma sistemática el modelado conceptual
de aplicaciones web
Propone una arquitectura software multinivel basada
en servicios web
Introduce un conjunto de reglas que permiten
transformar las abstracciones conceptuales en cada
uno los componentes software que implementan los
niveles de la arquitectura, haciendo uso intensivo de
patrones de diseño.

41. ARQUITECTURA DE OOWS

42. PROCESO
Contempla dos pasos principales:
Especificación del Problema.
Se deben capturar las peculiaridades y el
comportamiento que debe ofrecer el sistema para
satisfacer los requisitos de usuario identificados. En este
paso se incluye el conjunto de requisitos usando una
aproximación de Casos de Uso y posteriormente las
actividades de modelado conceptual del sistema.
Desarrollo de la Solución.
En el modelado conceptual, las abstracciones que se
derivan del problema son especificadas en términos de
clases y de su estructura, comportamiento y
funcionalidad, construyendo los siguientes modelos:
Objetos, Dinámico, Funcional, Navegacional, y
Presentación.

43. MODELO DE OBJETOS OOWS
 El Modelo de Objetos, define la estructura y las
relaciones estáticas entre clases identificadas en el
dominio del problema.

44. MODELO DINÁMICO
En el Modelo Dinámico, se describen las posibles secuencias
de servicios y los aspectos relacionados con la interacción
entre objetos.

45. MODELO FUNCIONAL
El Modelo Funcional, captura la semántica asociada a los
cambios de estado entre los objetos motivados por la
ocurrencia de eventos o servicios.

46. MODELO DE NAVEGACIÓN
El Modelo de Navegación, define la semántica navegacional
asociada a las clases de los objetos del modelo. Es en este
modelo es donde se explica la navegación permitida en la
aplicación para cada agente del sistema.

47. MODELO DE NAVEGACIÓN
Objetivo: definir cómo se le proporcionará a cada
usuario del sistema el acceso a la información y la
funcionalidad que le es relevante para llevar a cabo su
tarea dentro del sistema y qué secuencias de caminos
deberán seguir para conseguirlo.
En la aproximación OOWS, los requisitos
navegacionales de una aplicación web se obtienen
añadiendo una “vista navegacional” (mapa
navegacional) sobre el Modelo de Objetos de OO-
Method, indicando el conjunto posible de caminos
navegacionales que se le proporcionarán al usuario.

48. MODELO DE NAVEGACIÓN
El modelo de navegación está compuesto por un
conjunto de mapas de navegación (uno por cada
agente) que representan y estructuran la visión global
del sistema para cada tipo de usuario, definiendo su
navegación permitida
Existen dos posibilidades: que los nodos (contextos)
navegacionales sean alcanzables desde cualquier
ubicación en el sistema (llamados contextos de
exploración, E) o que los nodos sólo sean alcanzables
siguiendo un camino predeterminado de pasos de
navegación (llamados contextos de secuencia, S).

49. DESARROLLO DE LA SOLUCIÓN
Se propone una estrategia de generación de código
basada en componentes para integrar la solución
propuesta en ambientes web.
En esta etapa se obtendrá una aplicación web, con
una funcionalidad equivalente a la especificación
inicial según una visión operativa
Facilita las tareas de mantenimiento y evolución, ya
que la generación automática basada en patrones se
realiza utilizando soluciones previamente probadas
y validadas.
Esta filosofía nos permite obtener de una manera
más rápida aplicaciones finales de calidad, evitando
entre otras, la fase de pruebas (testing) del sistema.