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, 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 Al igual que con los anteriores divide un proyecto en piezas más pequeñas Pone énfasis en el cumplimiento de las expectativas del negocio, mientras que las caráctristicas tecnicas o la excelencia del desarrollo tiene menos importancia. El control del proyecto da prioridad a las fases de desarrollo y define “deadlines”. 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.

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.

Asigna tareas y responsabilidades (quien hace que, cuándo y cómo) 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 incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye también roles que desempeñan acciones en un determinado momento. Incluye artefactos (que son los productos tangibles del proceso, como por ejemplo: Una persona puede desempeñar distintos roles a lo largo del proceso. El modelo de casos de uso El modelo de clases El código fuente

Adaptar el proceso RUP 5 Principios clave 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 Se pretende garantizar que se tiene un producto preparado para su entrega a los usuarios.

RUP Secciones Sección de Proceso Sección de Soporte 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 Fase de elaboración Fase de construcción 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 el proyecto? ¿Tengo toda la información que necesito? ¿El cliente me presentó una necesidad o una solución? ¿Están claros los compromisos? ¿Qué han hecho otros? ¿Qué ha hecho la competencia? ¿Qué han hecho los referentes a nivel mundial en el rubro?

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 Capacidades del sistema ¿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? ¿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?

Iteraciones cortas entre dos y cuatro semanas Metodologías ágiles Característica principal adaptación al cambio define alcance, costos y tiempos. Iteraciones cortas entre dos y cuatro semanas Se planifica solo cuando ha terminado una iteración Valores Individuos e iteraciones Vs. procesos y herramientas Software funcionando Vs. documentación extensiva Colaboración con el cliente Vs. negociación contractual Respuesta ante el cambio Vs. seguir un plan

Individuos e iteraciones Software funcionando Metodologías ágiles Individuos e iteraciones Prioridad Calidad profesional del equipo Entrega temprana y continua Cada 2 ó 4 semanas se entrega software funcional 100% operativo Vs. (tradicional) Procesos y herramientas Debe servir de ayuda pero no pueden ser el objetivo 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

Colaboración con el cliente Respuesta ante el cambio Metodologías ágiles 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 Solo el cliente conoce lo que da verdadero valor al negocio 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

Metodologías ágiles más comunes SCRUM KANBAN eXtreme Programming (XP) Roles Scrum Master Dueño del producto Equipo Artefactos Backlog del producto Backlog de sprint Incremento de funcionalidad Procesos Planificación Reunión diaria (15 min) Revisión Retrospectiva Reglas Mostrar el proceso Limitar el trabajo en curso (WIP) Optimizar el flujo de trabajo Tableros físicos con columnas Cola de espera Análisis En cola En curso Desarrollo Implementación Valores: Comunicación, Simplicidad, Retroalimentación , Respeto y Coraje Practicas Cliente in-situ Metáfora Refactoring Entregas cortas Semana de 40 horas Propiedad colectiva Código Estándar Programación de a pares Integración continua Juego de planificación Modificar el código sin modificar la interfaz ni la experiencia del usuario TDD Pair Programming

Generaciones de las metodologías de desarrollo Web 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. 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. 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

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

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.

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.

Metodologías MDWE OOHDMDA: Basada en la metodología de OOHDM (1995), que separaba el diseño de un sistema web en 3 modelos: conceptual, navegacional y de interface abstracta. WebML Development Process. Hay varias propuestas de metamodelos y transformaciones WebML1: Establece 4 metamodelos: CommonElements, DataView, HypertextView and PresentationView WebML2: Establece 5 metamodelos: Hypertext Organization, Access Control, Hypertext, Content Management and Content. Herramienta CASE: WebRatio. W2000: Establece 4 metamodelos: Information, Navigation, Presentation, Dynamic Behavior. UWE. Establece 5 metamodelos: Requirements, Content, Navigation, Presentation, Process. Y un conjunto de transformaciones para derivar unos modelos de otros. Herramienta CASE: MagicUWE. NDT: Incluye 2 metamodelos para el nivel PIM: Content, Navigational. Define un conjunto de transformaciones basadas en QVT, pars obtener PIM a partir de CIM. Herramienta CASE: NDT-Suite.

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. Notably, none of the approaches that we compare here covers the whole MDA. In theory, as is indicated in Figure 2, the use of common metamodels and transformations could facilitate a situation where developers choose to use models from a phase of one particular MDWE approach and transform them into models of other MDWE approaches to proceed on to the next phase of the development life cycle. Obviously, for such integration to work in practice, the authors of MDWE approaches must work together to define transformations so that approaches can be adapted for fusion. At present, interoperability of MDWE approaches is for the most part not easy if indeed feasible, but an example of how different approaches can be combined is provided in the work of Moreno et al. [36] where a common metamodel is defined to work with OOH, UWE and WebML. It has therefore been demonstrated that it is possible to overlap different MDWE approaches, thereby enabling Web developers to mix-and-match different approaches so that they can avail of the separate advantages of each approach as well as the combined benefit of integrating approaches which together support all levels of the MDA framework.

Metodología OOWS Fase de especificación del sistema

Metodología PIM Modelo de estructural o de objetos Modelo dinámico

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.

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

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.

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”).

Estándares MDA de OMG Metamodelado: Transformación de modelos 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

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