Metodologas de desarrollo Web Pierre Sergei Zuppa Aza

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.

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 artefactos (que son los productos tangibles del proceso, como por ejemplo: –El modelo de casos de uso –El modelo de clases –El código fuente • Incluye también roles que desempeñan acciones en un determinado momento. – Una persona puede desempeñar distintos roles a lo largo del proceso.

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 • Se pretende garantizar que se tiene un producto preparado para su entrega a los usuarios.

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 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?

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 1. Individuos e iteraciones procesos y herramientas 2. Software funcionando documentación extensiva 3. Colaboración con el cliente negociación contractual 4. Respuesta ante el cambio seguir un plan Vs.

Metodologías ágiles • Individuos e iteraciones • Software funcionando –Prioridad • Calidad profesional del equipo • Entrega temprana y continua • Satisfacción del cliente • Aportar valor al negocio – Cada 2 ó 4 semanas se entrega software funcional Parte del desarrollo (código documentado) es la documentación del proyecto 100% operativo Vs. (tradicional) Procesos y herramientas Debe servir de ayuda pero no pueden ser el objetivo Vs. Documentación extensiva Debe servir de complemento pero no ser un impedimento

Metodologías ágiles • Colaboración con el cliente • Respuesta ante el cambio • Participación con el cliente • Comunicación directa y continua • Aceptar cambios de requerimientos • Ventaja competitiva para el negocio – Prioridad En XP el cliente está físicamente presente en el momento del desarrollo Vs. Seguir un plan Vs. Negociación contractual Solo el cliente conoce lo que da verdadero valor al negocio El cliente no está realmente seguro hasta que no prueba el software

Metodologías ágiles más comunes SCRUM 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 KANBAN e. Xtreme Programming (XP) Reglas Mostrar el proceso Limitar el trabajo en curso (WIP) Optimizar el flujo de trabajo Valores: Comunicación, Simplicidad, Retroalimentación , Respeto y Coraje Tableros físicos con columnas Cola de espera Análisis En cola En curso Desarrollo En cola En curso Implementación En cola En curso 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 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 de OOHDM (1995), que separaba el diseño de un sistema web en 3 modelos: conceptual, navegacional y de interface abstracta. • Web. ML Development Process. Hay varias propuestas de metamodelos y transformaciones – Web. ML 1: Establece 4 metamodelos: Common. Elements, Data. View, Hypertext. View and Presentation. View – Web. ML 2: Establece 5 metamodelos: Hypertext Organization, Access Control, Hypertext, Content Management and Content. – Herramienta CASE: Web. Ratio. • W 2000: 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: Magic. UWE. • 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. 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 específico de modelado 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