Metodologías de desarrollo Web

Pierre Sergei Zuppa Azúa

Keyword
 Metodologías de desarrollo
Es el entorno que se usa para
estructurar, planificar y controlar
el proceso de desarrollo de un
sistema de información.
Cada proyecto define que
metodologia usar deacuerdo a
sus fortalezas y debilidades.
Consiste en:
–Una filosofía de desarrollo de
software.
–Asistir en el proceso de desarrollo de
software.
–Suele estar documentada y alguna
clase de documentación formal.
 Tipos de enfoques generales
• Waterfall Model – Lineal
• Prototyping – Iterativo
• Incremental – combinación
de iterativo y lineal
• Spiral – Combinación de
iterativo y lineal
• Rapid Application
Development (RAD) --
iterativo
 Waterfall Model
(Modelo encascada)
El desarrollo se ve como una
serie de escalones
descendentes a través de las
distintas fases.
–Análisis
–Diseño
–Desarrollo
–Pruebas
–Integración
–Mantenimiento
 Waterfall Model
principios
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.
 Metodología de prototipos

Son versiones incompletas del producto

que va ha ser desarrollado.

Principios básicos son:

–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.
 Incremental
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.

Principios básicos:
•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)
 Espiral
Consiste en una serie de ciclos
que se repiten en forma de
espiral, comenzando desde el
centro. Se suele interpretar como
que dentro de cada ciclo de la
espiral.
En cada vuelta o iteración hay
que tener en cuenta:
• Objetivos
• Alternativas
» 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
 Espiral
si el resultado no es el adecuado
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
 Espiral
actividades por ciclo
Determinar o fijar objetivos
– Fijar los productos definidos a obtener,
requerimientos, especificaciones, manual
de usuario
– Fijar las restricciones
– Identificación de riesgos del proyecto y
estrategias alternativas para evitarlos
Análisis del riesgo
– Se estudian todos los riesgos
potenciales y se seleccionan una o
varias alternativas propuestas para
reducir o eliminar los riesgos.
Desarrollar, verificar y validad
(pruebas)
– Tareas de la actividad propia y prueba
– Análisis de alternativas e identificación
de resolución de riesgos
– Dependiendo del resultado de la
evaluación de riesgos, se elige un modelo
para el desarrollo, cascada, iterativo,
etc...
Planificar
– Revisamos todo lo realizado,
evaluándolo y decidimos si continuamos
con las fases siguientes y planificamos la
próxima actividad
 RAD
Rapid Application Development
Este método comprende el desarrollo iterativo, – El control del proyecto da prioridad a las
la construcción de prototipos y el uso de
fases de desarrollo y define “deadlines”.
herramientas CASE.
– Si el proyecto empieza a excederse en
– Aporta la velocidad del desarrollo, tiempos, se considera reducir los
principalmente por el uso de las herramientas requerimientos, no aumentar los tiempos.
CASE.
– La Calidad es otra de sus características,
– Los usuarios están especialmente
mediante la implicación del usuario en las involucrados (esto es imperativo) en las
etapas de análisis y diseño fases de diseño mediante el uso de
– Apropiado para proyectos de pequeña sesiones de trabajo (Workshops)
embergadura
– Al igual que con los anteriores divide un
– Produce documentación para facilitar la
proyecto en piezas más pequeñas evolución futura del producto y el
– Pone énfasis en el cumplimiento de las mantenimiento.
expectativas del negocio, mientras que las
caráctristicas tecnicas o la excelencia del
desarrollo tiene menos importancia.
 RUP

• Constituye la metodología estándar

más utilizada para el análisis,
implementación y documentación de
sistemas orientados a objetos.
• RUP no es un sistema cerrado, es
un conjunto de metodologías
adaptables al contexto y
necesidades de cada organización.
• Su ciclo de vida es una
implementación del Desarrollo en
espiral.
 RUP
Características
Asigna tareas y responsabilidades
(quien hace que, cuándo y cómo)

– Pretende implementar las mejores

prácticas en Ingeniería de software.
– Desarrollo Iterativo
– Administración de requisitos
– Arquitectura basada en componentes
– Control de cambios
– Modelado visual de software
– Verificación de la calidad del software
 RUP
Se caracteriza por ser iterativo e –El código fuente
incremental, estar centrado en la
arquitectura y guiado por los casos de
• Incluye también roles que
uso.
desempeñan acciones en un
determinado momento.
•Incluye artefactos (que son los
productos tangibles del proceso, como – Una persona puede desempeñar
por ejemplo: distintos roles a lo largo del proceso.

–El modelo de casos de uso

–El modelo de clases
 RUP
5 Principios clave
Adaptar el proceso

– Balancear Prioridades
– Demostrar valor iterativamente
– Elevar el nivel de abstracción
– Enfocarse en la calidad
 RUP
Ciclo de vida
–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
•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
 RUP
Secciones

–Sección de Proceso
•Modelado de Negocio
•Requisitos
•Análisis y diseño
•Implementación
•Pruebas
•Despliegue

–Sección de Soporte
•Gestión del cambio y configuraciones
•Gestión del proyecto
•Entorno
 RUP
Artefactos
–Fase de Inicio
•Documento Visión
•Especificación de requerimientos

–Fase de elaboración
•Diagramas de caso de uso

–Fase de construcción
•Trabaja desde cuatro vistas:
–Vista lógica
»Diagrama de clases
»Modelo ER
–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
Metodología UCD
Metodología Diseño Centrado en el Usuario
Metodología Diseño Centrado en el Usuario
 ¿Para qué sirve hacerlo?
Rebrief Benchmark
¿Qué necesito saber antes de empezar ¿Qué han hecho otros?
el proyecto? ¿Qué ha hecho la competencia?
¿Tengo toda la información que ¿Qué han hecho los referentes a nivel
necesito? mundial en el rubro?
¿El cliente me presentó una necesidad
o una solución?
¿Están claros los compromisos?
 Necesito saber sobre
La empresa
Sus servicios
Sus competidores
Su posicionamiento
Su personalidad
Su identidad corporativa
Sus soportes de difusión
Sus planes a futuro
¿Que se espera del sitio?
¿Cómo se planea medir el éxito?
¿Tiene el cliente referentes para compartir?
¿Que sería bueno que el sitio hiciera?
¿Quién se encargará de los contenidos?
¿Cuanto sabe mi cliente de Interrnet? Tiene sitio
ya?
Que pasa con el servidor?
¿Y sobre la fotografía?
¿En que estado se encuentran los recursos?
¿Algún deadline?
Y ¿alguna posibilidad de fee?
 ¿Para qué sirve hacerlo?
Persona
¿Conozco a mi usuario?
¿Tengo argumentos suficientes para
tomar decisiones de diseño en función
del comportamiento de mis usuarios?
¿Estoy diseñando para mí o para mi
usuario?
Capacidades del sistema
¿Que va hacer el sitio?
¿Qué propuestas deben cotizarse?
¿Qué funcionalidades deben esperar a
una segunda etapa?
¿Cómo se relacionan los distintos
contenidos?
¿Como se llamarán las secciones del
sitio?
 Metodologías ágiles
Característica principal adaptación al Valores
cambio define alcance, costos y
tiempos.
1. Individuos e iteraciones Vs.
procesos y herramientas
•Iteraciones cortas entre dos y 2. Software funcionando Vs.
cuatro semanas documentación extensiva
3. Colaboración con el cliente Vs.
•Se planifica solo cuando ha negociación contractual
terminado una iteración 4. Respuesta ante el cambio Vs.
seguir un plan
 Metodologías ágiles

•Individuos e iteraciones •Software funcionando

–Prioridad –Prioridad
•Calidad profesional del equipo •Satisfacción del cliente
•Entrega temprana y continua •Aportar valor al negocio
– Cada 2 ó 4 semanas se entrega software funcional Parte del desarrollo (código documentado) es la
100% operativo documentación del proyecto

Vs. Documentación extensiva

Vs. (tradicional) Debe servir de complemento pero no ser un impedimento
Procesos y herramientas
Debe servir de ayuda pero no pueden ser el
objetivo
 Metodologías ágiles

• Colaboración con el cliente • Respuesta ante el cambio

– Prioridad – Prioridad
• Participación con el cliente • Aceptar cambios de requerimientos
• Comunicación directa y continua • Ventaja competitiva para el negocio
En XP el cliente está físicamente presente en el momento del
desarrollo

Vs. Seguir un plan

Vs. Negociación contractual El cliente no está realmente seguro hasta que no prueba
Solo el cliente conoce lo que da verdadero valor al negocio el software
 Metodologías ágiles
más comunes
SCRUM KANBAN eXtreme Programming (XP)
Roles Reglas Valores: Comunicación,
Scrum Master Mostrar el proceso Simplicidad, Retroalimentación ,
Dueño del producto Limitar el trabajo en curso Respeto y Coraje
Equipo (WIP) Practicas
Optimizar el flujo de trabajo Cliente in-situ
Artefactos Metáfora
Backlog del producto Tableros físicos con columnas Refactoring
Backlog de sprint Cola de espera Entregas cortas
Incremento de funcionalidad Análisis Semana de 40 horas
En cola Propiedad colectiva
Procesos En curso Código Estándar
Planificación Desarrollo Programación de a pares
Reunión diaria (15 min) En cola Integración continua
Juego de planificación
Revisión En curso Modificar el código sin modificar
Retrospectiva Implementación la interfaz ni la experiencia del
En cola
En curso usuario
TDD
Pair Programming
 Generaciones de las metodologías de
desarrollo Web
1. Principios de los 90: Se sientan las bases de la ingeniería Web, en los
que se incluyen conceptos como construcción de navegación, separación
entre estructuras y el contenido durante el ciclo de desarrollo.
2. Segunda mitad de los 90: Se refinan los primeros modelos y se añaden
los soportes de funcionalidad básica y se llevan a cabo los primeros
esbozos de proceso donde se delimitan los modelos conceptual, lógico y
físico.
3. A partir del 2000: Se lleva a cabo la profundización en el soporte para
la funcionalidad, enfatización de la figura del usuario en los métodos, y se
avanza hacia la estandarización de notaciones, procesos y lenguajes de
especificación.
 Modelos de un sistema Web

• Modelo conceptual de
información
• Modelo navegacional
• Modelo de presentación

31
 ¿qué es UWE?

La propuesta de Ingeniería Web

basada en UML pero con un
enfoque de ingeniería de
software para el dominio Web
con el objetivo de cubrir todo el
ciclo de vida de desarrollo de
aplicaciones Web. El aspecto
clave que distinguen UWE es la
dependencia de los estándares.
 Aspectos de UWE
• Uso de una notación estándar, para
todos los modelos (UML: Lenguaje de
modelado unificado).
• Definición de métodos: Definición de
los pasos para la construcción de los
diferentes modelos.
• Especificación de Restricciones: Se
recomienda el uso de restricciones
escritas (OCL: Lenguaje de
restricciones de objetos) para
aumentar la exactitud de los modelos.
 Model-Driven Web Engineering
(MDWE)
Propone la representación de conceptos
mediante metamodelos que son
independientes de la plataforma.
• El proceso de desarrollo se apoya en un
conjunto de transformaciones y de las
relaciones entre los conceptos de los
modelos que permite el desarrollo ágil y
asegura la coherencia entre los modelos.
• MDE también se utiliza en las pruebas del
software, en el ámbito del desarrollo
dirigido por pruebas TDD (Testing-Driven
Development), mediante la definición de
metamodelos para representar aspectos
de prueba y el uso de transformaciones
para derivar casos de prueba.

34
 MDWE
Metamodelos
• Se refiere al uso del paradigma basado en
modelos en metodologías de desarrollo Web.
• Ayuda a obtener modelos en un punto
específico del proceso de desarrollo, mediante
el uso de los conocimientos adquiridos en las
etapas anteriores, con los modelos
previamente desarrollados.
• Los metamodelos proporcionan una solución
para la multiplicidad de vocabularios y
enfoques.
• Un metamodelo es una representación
abstracta de los conceptos o artefactos que se
permitirán usar en los modelos que se basen
en ese metamodelo.
• No se centra en la terminología o forma
(símbolos o código) en la que se expresarán
los conceptos en los futuros modelos, sino en
los conceptos y la relación entre ellos.

35
 Model-Driven Architecture
(MDA)
Niveles de modelado
• CIM (Computer-Independent
Model): define conceptos que captan
la lógica del sistema.
• PIM (Platform-Independent
Model): define el sistema de software
sin ninguna referencia a la plataforma
de desarrollo específica.
• PSM (Platform-Specific Model):
define los modelos, con detalles que
dependen de la plataforma de
desarrollo específico.
• Code: Representa el código fuente
de la aplicación.
36
 Metodologías MDWE
• OOHDMDA: Basada en la metodología • W2000: Establece 4 metamodelos:
de OOHDM (1995), que separaba el Information, Navigation, Presentation,
diseño de un sistema web en 3 modelos: Dynamic Behavior.
conceptual, navegacional y de interface
abstracta. • UWE. Establece 5 metamodelos:
Requirements, Content, Navigation,
Presentation, Process. Y un conjunto de
• WebML Development Process. Hay
transformaciones para derivar unos modelos
varias propuestas de metamodelos y de otros. Herramienta CASE: MagicUWE.
transformaciones
– WebML1: Establece 4 metamodelos:
• NDT: Incluye 2 metamodelos para el nivel
CommonElements, DataView, HypertextView
and PresentationView PIM: Content, Navigational. Define un
conjunto de transformaciones basadas en
– WebML2: Establece 5 metamodelos:
Hypertext Organization, Access Control, QVT, pars obtener PIM a partir de CIM.
Hypertext, Content Management and Herramienta CASE: NDT-Suite.
Content.
– Herramienta CASE: WebRatio.
37
 Comparación de metodologías MDWE
MDA Framework
Una de las ventajas más importantes
del paradigma MDWE es la posibilidad
de hacer compatibles diversas
metodologías.
• Si se define un metamodelo o algunas
transformaciones utilizando un
lenguaje común, la conexión entre las
metodologías podría ser sencilla.
• Para este fin, el uso de perfiles UML
ofrece resultados muy interesantes.
• Un UML Profile es un mecanismo de
extensión que ofrece UML para
extender los conceptos básicos de un
enfoque MDWE.
38
 Metodología OOWS
Fase de especificación del sistema

39
 Metodología PIM

Modelo de estructural o de objetos Modelo dinámico

40
 Modelo funcional (PIM)
Captura la semántica asociada a los cambios de estado de los
objetos.

El valor de cada atributo es modificado dependiendo de la

acción que activó el cambio de estado, de los argumentos de
dicho evento y del estado actual del objeto.

41
 Modelo de navegación (PIM)

•Representa los contextos de navegación que han sido

identificados en las primeras fases de especificación
del sistema.
•También aparecen sobre el modelo los servicios que
son ejecutados al iniciar y finalizar una sesión.
– Cuando el servidor Web recibe una petición de un
internauta, ejecuta el servicio crear del Usuario
Navegante asociándole además una Cesta.
– Cuando el Usuario Navegante abandona el sistema se
ejecuta el servicio destruir, eliminando además, si no ha
sido confirmada, su Cesta asociada.
•Se aprecia que el Usuario Navegante siempre tendrá
disponibles los contextos (marcados como contextos
de exploración) Autores, Categorías, Cesta y
Registrarse.
•A partir de estos, y siguiendo diferentes caminos
navegacionales, podrá alcanzar los demás
(Detalles_Autor, Detalles_Categoría, Albumes y
Facturas).
42
 Modelo de navegación (PIM)
•Donde se recupera la información sobre un
autor (su nombre), los álbumes que están
disponibles de este autor (título, año y
precio) y el nombre de la categoría del
álbum.
•Seleccionando el título de un álbum
podremos navegar al contexto Álbumes,
donde se proporcionará información
adicional del álbum y podremos comprarlo.
•Una estructura de acceso índice de tipo
atributo, que permitirá acceder a los
autores por su letra_inicial (atributo
derivado definido en la clase Autor).
•Un filtro de tipo aproximado para facilitar
la búsqueda de autores por su nombre.

43
 Modelo de presentación (PIM)
•Se captan los requisitos de presentación de
información para cada contexto del mapa de
navegación.
•Se especifica que los objetos de la clase directora
se presentarán en modo tabular y el contexto
(objetos de la clase directora) estará paginado con
una cardinalidad estática de 1 elemento, con
posibilidad de acceso secuencial y circular.
•El patrón de presentación asociado a la relación de
contexto definida entre un Autor y sus Albumes
será maestro-detalle, con el detalle en modo
tabular y con una paginación de cardinalidad
estática de 5 elementos, con acceso secuencial,
circular.
•Se ha definido una ordenación de los elementos de
la clase Album por el año de modo ascendente y la
relación de contexto definida entre la clase Album
con la clase Categoría se presentará en modo
tabular (relación “1 a 1”).
44
 Estándares MDA de OMG
Metamodelado:
MDA
Lenguaje MOF
Lenguaje OCL
Perfiles UML
Transformación de modelos
Lenguaje QVT
Lenguajes de modelado específico
BPMN: Business Process Model and
Notation
IFML: Interaction Flow Modeling
Language
SYSML: Systems Modeling Language

45
Frase

“El primer 90% del código

está reservado para el
primer 90% del tiempo de
desarrollo. El 10% de
código restante es para el
otro 90% del tiempo de
desarrollo”
Tom Cargill