teoria de sistemas ciclos de vida
TRANSCRIPT
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
CBDDESCRIPCIÓN DE LAS ETAPAS DEL MODELO
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.
CBDDESCRIPCIÓN DE LAS ETAPAS DEL MODELO
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
XPFASES QUE LO COMPONEN
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.
XPFASES QUE LO COMPONEN
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
XPFASES QUE LO COMPONEN
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
SCRUMCONCEPTOS IMPORTANTES
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
SCRUMCONCEPTOS IMPORTANTES
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
SCRUMREUNIONES EN SCRUM
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
SCRUMREUNIONES EN SCRUM
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
SCRUMREUNIONES EN SCRUM
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