teoria de sistemas ciclos de vida

TEORIA DE SISTEMASCICLOS DE VIDA

CICLOS DE VIDA ABORDADOS

MODELO DE DISEÑO DE HIPERMEDIA ORIENTADO A OBJETOS - OOHDM

DESARROLLO BASADO EN COMPONENTES - CBD

METODOLOGIAS AGILESEXTREME PROGRAMMING – XPSCRUM

MODELO DE DISEÑO DE HIPERMEDIA ORIENTADO A OBJETOS - OOHDM

DESCRIPCIÓN

FASES LO COMPONEN

VENTAJAS Y DESVENTAJAS DEL MODELO

EJEMPLO DE SISTEMA PARA EL QUE SERÍA ADECUADO EL CICLO DE VIDA

OOHDMDESCRIPCIÓN

Es un método para el desarrollo de aplicaciones Web. Fue uno de los primeros métodos para separar de las dificultades que definían diferentes modelos que se separaban en las siguientes fases del diseño: conceptual, diseño navegacional, diseño interfaz abstracta y implementación.OOHDM se apoya en código abierto, disponible libremente, ejecutado en diferentes ambientes.

OOHDMFASES LO COMPONEN

Conceptual:Se construye un modelo del dominio de la aplicación, a través de las tecnicas del modelado orientado a objetos, se puede partir de un modelo E/R. Diseño Navegacional:Para construir la estructura navegacional se debe tener en cuenta:Nodos que serán navegables, establecer los atributos que

poseen y sus relaciones.Contexto en que el usuario navegara para organizar el espacio

navegacional.Vistas de los objetos navegacionales.Estructuras que permiten acceder a los nodos.

OOHDMFASES LO COMPONEN

Diseño Interfaz Abstracta:En esta etapa se define la forma en la que serán percibidos los objetos a través de la interfaz de usuario y también la apariencia que tendrán. Implementación:Es la ultima etapa, en la que, a partir de los modelos diseñados, se deben escoger las correspondencias con los objetos concretos de la plataforma de implementación. Es una etapa totalmente dependiente de la plataforma de implementación escogida.

OOHDMVENTAJAS

Sirve como base para el desarrollo de nuevos sistemas de información web.

Esta basada en el diseño.Hace uso de la orientación a objetos y de un

diagrama tan estandarizado como el de clases.Ofrece una serie de ideas muy adecuadas a la

hora de plantear una metodología de desarrollo que tenga en cuenta la navegación y la interfaz.

OOHDMDESVENTAJAS

Deja fuera de su ámbito el tratamiento de la funcionalidad del sistema.

No ofrece ningún mecanismo para trabajar con múltiples actores.

OOHDMEJEMPLO

Los ejemplos que ilustran el método sean siempre del mismo tipo.

El objetivo de OOHDM es cubrir la concepción de todo tipo de aplicaciones hipermedia.

El término hipermedia toma su nombre de la suma de hipertexto y multimedia, una red hipertextual en la que se incluye no sólo texto, sino también otros medios: imágenes, audio, vídeo, etc. (multimedia).

En la presentación multimedia, al usuario se le suele ofrecer un componente mediante el cual éste pueda ejercer un control sobre la presentación.

Lo más común es que se trate de un reproductor virtual con controles en forma de botones.

9

DESARROLLO BASADO EN COMPONENTES - CBD

DESCRIPCIÓN

FASES LO COMPONENCARACTERÍSTICAS DE UN COMPONENTEDESCRIPCIÓN DE LAS ETAPAS DEL MODELO

VENTAJAS Y DESVENTAJAS

EJEMPLO DE SISTEMA PARA EL QUE SERÍA ADECUADO EL CICLO DE VIDA

10

CBDDESCRIPCIÓN

Es una rama de la ingeriría de software que enfatiza la separación de asuntos.Es un acercamiento basado en la reutilización para definir, implementar y componer componentes de software.Se consideran los componentes como parte de la plataforma inicial para la orientación a servicios

11

CBDFASES QUE LO COMPONEN

Componente: Es una unidad de composición de aplicaciones de software. Posee un conjunto de interfaces y un conjunto de requisitos.

CBDCARACTERÍSTICAS DE UN COMPONENTE

Identificable:Debe tener una identificación que permita acceder fácilmente a sus servicios. Su acceso debe ser sólo a través de su interfaz (Debe asegurar que estas no cambiaran a lo largo de su implementación).

Auto contenido:Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado. Puede ser reemplazado por otro componente.

Sus servicios no varían:Las funcionalidades ofrecidas en su interfaz no deben variar, pero su funcionalidad si.

13

CBDCARACTERÍSTICAS DE UN COMPONENTE

Bien Documentado:Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, adaptar, etc.

Es Genérico:sus servicios deben servir para varias aplicaciones. Reutilizado Dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.

Independiente de la plataforma:Hardware, Software, SO.

CBDDESCRIPCIÓN DE LAS ETAPAS DEL MODELO

Análisis de Requerimientos:En esta etapa del ciclo de vida los procesos y las necesidades del negocio se descubren y se expresan en los casos de uso. Selección, construcción, análisis y evaluación de la Arquitectura de Software.

Identificación y arreglo para requisitos particulares del componente: Los componentes deben ser seleccionados por los requerimientos funcionales y de calidad que satisfaga cada componente. Luego de haber sido identificados los componentes que serán integrados al sistema, se debe evaluar si el componente necesita ser sujeto a alguna modificación.

15


Integración del Sistema:En esta etapa se debe examinar, evaluar y determinar como va a ser la comunicación y la coordinación entre los componentes que harán parte del sistema. Luego debe ensamblarse el sistema y proseguir con una serie de pruebas que determinaran si los componentes seleccionados son los adecuados.

Pruebas: Evaluar el funcionamiento de los componentes que fueron integrados en el sistema, si algún componente demuestra no estar funcionando de forma correcta se debe pensar en la posibilidad de reemplazarlo o modificarlo para luego proceder con la re-integración.


Mantenimiento:Vigilar el correcto funcionamiento del sistema, corregir fallas en el comportamiento, etc.

17

CBDVENTAJAS

Este tipo de desarrollo provee beneficios tanto en el corto como en el largo plazo, para el software y para las organizaciones que patrocinan software.

Reutilización del Software:Nos lleva a alcanzar un mayor nivel de reutilización de software.

Simplifica las pruebas:Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo.

CBDVENTAJAS

Simplifica el mantenimiento del Sistema:Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.

Mayor Calidad:Dado que un componente puede ser construido y luego mejorado, la calidad de una aplicación basada en componentes mejorara con el paso del tiempo.

Ciclos de desarrollo más cortos:La adición de una pieza dada de funcionalidad tomara días en lugar de meses o años.

19

CBDVENTAJAS

Mejor Rol:Usando correctamente esta estrategia, el retorno sobre la inversión puede ser más favorable que desarrollando los componentes de uno mismo.

Funcionalidad Mejorada:Para usar un componente que contenga una pieza de funcionalidad, solo se necesita entender su naturaleza, más no sus detalles internos. Así, una funcionalidad que seria impractica de implementar, se vuelve ahora completamente asequible.

20

CBDDESVENTAJAS

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificación de riesgos

Genera mucho trabajo adicional

Cuando un sistema falla se pierde tiempo y coste dentro de la empresa

Exige una cierta habilidad en los analistas

CBDEJEMPLO

Un modelo de componentes es una definición de estándares para la implementación, documentación y el despliegue de componentes.

Ejemplos de modelos de componentes son: el modelo Enterprise Java Beans (EJB), el modelo COM+ (modelo .NET), el modelo de componentes Corba.

El modelo de componentes especifica como deben ser definidas las interfaces y los elementos que deben ser incluidos en una definición de interfaz.

22

METODOLOGIAS AGILESEXTREME PROGRAMMING (XP)

DESCRIPCIÓNFASES LO COMPONENVALORESROLESVENTAJAS Y DESVENTAJASEJEMPLO

XPDESCRIPCIÓN

Es una metodología de desarrollo de la ingeniería de software y el mas destacado de los procesos ágiles de desarrollo de software.La XP se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Sus defensores consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable y deseable del desarrollo de proyectos. Creen que adaptarse a los cambios de requisitos les da ventaja sobre definir los requisitos al comienzo del proyecto e invertir esfuerzo en controlar los cambios en los requisitos.

XPFASES QUE LO COMPONEN

Desarrollo Iterativo e Incremental: pequeñas mejoras, unas tras otras. Pruebas Unitarias: continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación (TDD). Algunas herramientas utilizadas son JUnit en Java, NUnit en .NET o PHPUnit en PHP. Programación en Parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera, el código es revisado y discutido mientras se escribe, es más importante que la posible pérdida de productividad inmediata.

25


Frecuente Integración del Equipo de Programación con el Cliente o Usuario: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Corrección de todos los errores antes de añadir nuevas funcionalidades. Hacer entregar frecuentes. Refactorización del Código: reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.


Propiedad del Código Compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

27


Simplicidad en el Código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

XPVALORES

Simplicidad

Comunicación

Retroalimentación o Feedback

Coraje o valentía

Respeto

29

XPROLES

Programador: Escribe las pruebas unitarias y produce el código del sistema. Es la esencia del equipo Cliente: Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio Tester: Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas

XPROLES

Tracker: Es el encargado de seguimiento. Proporciona realimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Entrenador (Coach): Responsable del proceso global. Guía a los miembros del equipo para seguir el proceso correctamente.

31

XPROLES

Consultor: Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto. Ayuda al equipo a resolver un problema específico. Además este tiene que investigar según los requerimientos. Gestor (Big Boss): Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.

XPVENTAJAS

Programación organizada

Menor taza de errores

Satisfacción del programador

Solución de errores de programas

Versiones nuevas

Implementa una forma de trabajo donde se adapte fácilmente a las circunstancias

33

XPDESVENTAJAS

Es recomendable emplearlo solo en proyectos a corto plazo

Altas comisiones en caso de fallar

Imposible prever todo antes de programar

Demasiado costoso e innecesario

XPEJEMPLO

35

METODOLOGIAS AGILESSCRUM

DESCRIPCIÓNCONCEPTOS IMPORTANTESROLES PRINCIPALES Y AUXILIARESFASES QUE LO COMPONENREUNIONES EN SCRUMVENTAJAS Y DESVENTAJASEJEMPLO

36

SCRUMDESCRIPCIÓN

Scrum es un proceso de desarrollo en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

37

SCRUMDESCRIPCIÓN

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

38

SCRUMCONCEPTOS IMPORTANTES

Sprint:Es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duración de sprint en particular (2 o 3 semanas) e ir ajustándolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y el resultado obtenido es un producto que, potencialmente, se puede entregar al cliente.Así mismo, se recomienda no agregar objetivos al sprint o sprint backlog a menos que su falta amenace al éxito del proyecto. La constancia permite la concentración y mejora la productividad del equipo de trabajo

39


Product Backlog:Se trata como un documento de alto nivel para todo el proyecto. Es el conjunto de todos los requisitos de proyecto, el cual contiene descripciones genéricas de funcionalidades deseables, priorizadas según su retorno sobre la inversión. Representa el qué va a ser construido en su totalidad. Es abierto y solo puede ser modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendrá probablemente más prioridad, debido a que su retorno sobre la inversión será más alto.

40


Sprint Backlog:Es el subconjunto de requisitos que serán desarrollados durante el siguiente sprint. Al definir el sprint backlog, se describe el cómo el equipo va a implementar los requisitos durante el sprint. Por lo general los requisitos se subdividen en tareas, a las cuales se asignan ciertas horas de trabajo pero ninguna tarea con una duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca adecuado.

41

SCRUMROLES PRINCIPALES

Product Owner:Representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

Scrum Master o Facilitador: El Scrum es facilitado por un Scrum Master, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El Scrum Master no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El Scrum Master se asegura de que el proceso Scrum se utiliza como es debido. Es el que hace que las reglas se cumplan.

42

SCRUMROLES PRINCIPALES

Equipo de Desarrollo:El equipo tiene responsabilidad de entregar el producto. Es recomendable un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

43

SCRUMROLES AUXILIARES

Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados ("stakeholders"). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

44

SCRUMROLES AUXILIARES

Stakeholders (Clientes, Proveedores, Vendedores, etc):Son las personas que hacen posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su desarrollo. Sólo participan directamente durante las revisiones del "sprint".

Administradores o Managers:Son los responsables de establecer el entorno para el desarrollo del proyecto.

45

SCRUMFASES QUE LO COMPONEN

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite

46

SCRUMREUNIONES EN SCRUM

Daily Scrum:Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. La reunión comienza puntual, dura 15 minutos, solo hablan los involucrados en el proyecto, se celebra en el mismo lugar y a la misma hora todos los días.Cada miembro debe responder a 3 preguntas: ¿Que hiciste desde ayer?, ¿Que vas a hacer hoy?, ¿Tuviste algún problema que te haya impedido alcanzar tu objetivo?(Es el papel del ScrumMaster recordar estos impedimentos).El objetivo último de las reuniones diarias es que cada miembro del equipo sepa si se están cumpliendo los plazos marcados para el "sprint".

47


Scrum de Scrum:Estas reuniones, por lo general, se realizan cuando en la organización existan varios equipos Scrum, y les permiten discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración. Se hace normalmente cada día después del “Daily Scrum” o, como máximo, cada dos días. Asiste una persona asignada por cada equipo Scrum.La agenda será la misma que la del Daily Scrum, añadiendo, además, las siguientes cuatro preguntas:¿Qué hizo tú equipo desde la ultima reunión?,¿Qué hará tú equipo antes de volvernos a reunir?, ¿Hay algo que demore o estorbe a tú equipo?¿Estás a punto de poner algo en el camino del otro equipo?

48


Reunión de Planificación del Sprint:Al inicio de cada ciclo de Sprint (cada 15 o 30 días), se lleva a cabo una reunión de planificación del Sprint. En esta, se busca: Seleccionar que trabajo se hará, preparar con el equipo completo el Sprint Backlog que detalla el tiempo que llevará hacer el trabajo, identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint, realizarse esta planificación en ocho horas como tiempo límite.

49


Reunión de Revisión del Sprint:Revisar el trabajo que fue completado y no completado, presentar el trabajo completado a los interesados (demo), el trabajo incompleto no puede ser demostrado, cuatro horas como limite.

Retrospectiva del Sprint:Después de cada sprint, se lleva a cabo una retrospectiva del propio sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.

50

SCRUMVENTAJAS

Flexibilidad a cambiosReducción del Time to MarketMayor calidad del softwareMayor productividadMaximiza el retorno de la inversiónPredicciones de tiempos.Reducción de riesgos

51

SCRUMDESVENTAJAS

Falta de documentación del diseñoProblemas derivados de la comunicación oralCostes de tiempo y dinero inexactosFecha final no fijada -> se sigue añadiendo

funcionalidadMiembros no centrados -> Proyecto fallaraSólo optimo en equipos pequeños de trabajoReducción de riesgosSolo miembros de equipo experimentadosSe marcha miembro -> efecto negativo enorme

52

SCRUMEJEMPLO

Un buen ejemplo es Spotify, quien hizo especial hincapié en la figura del Scrum Master. En Spotify decidieron acercarse al Scrum de forma muy sistemática. Sabían que en cualquier momento podían ser derrotados por la competencia, al menos que fuesen más rápidos, más baratos y mejores.En Spotify los equipos se organizan en escuadrones, pequeños equipos de Scrum con la habilidad de implementar el software desarrollado al final de cada sprint, sin romper ningún equipo. La compañía tiene una muy buena coordinación central ya que necesitan implementar, cambiar y actualizar su código constantemente sin romper nada más.

53

SCRUMEJEMPLO

Un mal ejemplo de uso de SCRUM es Healthcare.org. Healthcare es un proyecto del gobierno de EE.UU diseñado para ofrecer toda la información sobre el mercado de seguros sanitarios, para que los consumidores puedan asegurarse de obtener el mejor valor. Las principales causas del fracaso de este proyecto se deben a la falta de liderazgo en un proyecto con mas de 20 consultoras implicadas y no haber lanzado el proyecto fase a fase sin testeo ni aprendizaje en el medio, haciendo imposible detectar las fases que funcionabas de las que no. Hubo un muy corto periodo de testing.

54

BIBLIOGRAFIAhttps://es.wikipedia.org/wiki/OOHDMhttps://prezi.com/awcjzx3xucxq/oohdm-modelo-de-diseno-de-hipermedia-orientado-a-objetos-/https://prezi.com/xohf4fhthijv/metodologia-oohdm/http://www.hipertexto.info/documentos/oohdm.htmhttp://www.hipertexto.info/documentos/hipermedia.htm#hipermediahttps://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software_basada_en_componenteshttps://prezi.com/plx_2efoedrc/desarrollo-basado-en-componentes/http://es.slideshare.net/martincito123/modelo-componenteshttps://es.wikipedia.org/wiki/Programaci%C3%B3n_extremahttp://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.htmlhttps://proyectosagiles.org/que-es-scrum/https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software)https://al095668.wordpress.com/2013/06/01/ventajasdesventajas-de-las-metodologias-agiles/https://plus.google.com/118416497256331964442/posts/iVnKbSkL49Ahttp://comunidad.iebschool.com/iebs/agile-scrum/exitos-y-fracasos-en-proyectos-scrum-spotify-vs-healthcare/

55

CREDITOS

Teoría de SistemasTrabajo Práctico Ciclos de Vida

Iván A. Szyszivan.szysz@gmailcom

Pedro [email protected]

Octubre de 2016

56

mailto:ivan.szysz@gmailcom

mailto:[email protected]

teoria de sistemas ciclos de vida

Engineering