GoConqr has a new look! Let us know what you think.

Sign up free

Flashcards

MODELOS DE ANALISIS

Xime Moreno Spanish 55 cards

Cards in this deck (55)

  1. 1MODELO EN CASCADAModelo conocido como: Modelo clásico, modelo tradicional o modelo lineal secuencial
  2. 2MODELO EN CASCADAModelo en el cual se ordenan rigurosamente las etapas del desarrollo del software
  3. 3MODELO EN CASCADAEnfoque clásico para el ciclo de vida del desarrollo de sistemas
  4. 4MODELO EN CASCADAEl inicio de una etapa de desarrollo deba de esperar el fin de la etapa anterior
  5. 5MODELO EN CASCADACualquier error detectado lleve al rediseño del área de código afectado, lo cual aumenta de costo el desarrollo del proyecto
  6. 6MODELO EN CASCADAEs una secuencia de actividades/etapas que consisten en el análisis de requerimientos, él diseño, la implementación, la integración y las pruebas
  7. 7MODELO EN CASCADAAnálisis de requerimientos: Consiste en reunir las necesidades del producto y casi siempre su salida es texto
    Diseño: Describe la estructura interna del producto y suele representarse con diagramas y texto
    La implementación: Significa programación. Producto de esta etapa es el código en cualquier nivel, incluido el producido por sistemas de generación automática
    La integración: Es el proceso de ensamblar las partes para completar el producto
  8. 8MODELO EN CASCADAEl inicio y el alcance del proyecto
    La planificación del proyecto (calendario, recursos necesarios, costo)
    Definición de las necesidades del negocio y el análisis en detalle dela solución
    La creación de la solución
    Prueba que la solución funciona. La entrega de la solución a su público objetivo
    Cierre del proyecto
  9. 9MODELO EN ESPIRALLas actividades se realizan conforme se van seleccionando de acuerdo al análisis de riesgo
  10. 10MODELO EN ESPIRALEn cada iteración se deberán de tomar en cuenta los objetivos
  11. 11MODELO EN ESPIRALLas alternativas se deberán de tomar de acuerdo a las características, estas son experiencia personal, requisitos a cumplir, las formas de gestión del sistema, entre otros
  12. 12MODELO EN ESPIRALEste modelo tiene dos formas en las cuales se debe de planificar el proyecto
    Forma angular: Indica únicamente el avance del software dentro del proyecto
    Forma radial: Indica el aumento del costo dado que cada iteración conlleva más tiempo de desarrollo
  13. 13MODELO EN ESPIRALEn cada vuelta o iteración hay que tener en cuenta:
    Los Objetivos: Qué necesidad debe cubrir el producto
    Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
    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
  14. 14MODELO EN ESPIRALAl ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos
  15. 15MODELO EN ESPIRAL DETERMINAR OBJETIVOSFijar los productos definidos a obtener: Requisitos, especificación, manual de usuario
    Fijar las restricciones
    Identificación de riesgos del proyecto/estrategias alternativas para evitarlos
    Hay una cosa que solo se hace una vez: Planificación Inicial
  16. 16MODELO EN ESPIRAL ANALISIS DEL RIESGOSe lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir
    Evaluar alternativas
    Crear prototipo antes de comenzar a desarrollar y probar
  17. 17MODELO EN ESPIRAL REGIONESLas seis regiones que componen este modelo son las siguientes:
    Comunicación con el cliente: Tareas necesarias para plantear la comunicación entre el desarrollador y el cliente.
    Planificación: Tareas inherentes a la definición de recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos
    Análisis de riesgos: Tareas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto
    Ingeniería: Tareas para construir una o más representaciones de la aplicación
    Construcción y adaptación: Tareas requeridas para construir, probar, instalar y proporcionar soporte a los usuarios
    Evaluación del cliente: Tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación
  18. 18MODELO UNIFICADOProceso que se distingue por la utilización de casos de uso, el cual está centrado en la arquitectura y la utilización de iteraciones incrementales
  19. 19MODELO UNIFICADOEn cada iteración, se busca el avance e iteración en determinadas áreas, con la cual se obtendrán resultados en los cuales se puede constatar el tiempo que se ha dedicado a las distintas áreas en el desarrollo de software
  20. 20MODELO UNIFICADOSus principales características son:
    Es iterativo e incremental, dirigido por casos de uso, centrado en la arquitectura y enfocado en los riesgos
  21. 21MODELO UNIFICADO CARACTERISTICAS - Iterativo e IncrementalEl Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas: Inicio, Elaboración, Construcción y Transición
    Cada una de estas fases es a su vez dividida en una serie de iteraciones
    La de inicio puede incluir varias iteraciones en proyectos grandes
    Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo
    Cada iteración se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada:
    Todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto
  22. 22MODELAMIENTO UNIFICADO CARACTERISTICAS - Dirigido por los casos de usoEn el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones
    La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc.
    El proceso dirigido por casos de uso es el RUP
  23. 23MODELAMIENTO UNIFICADO CARACTERISTICAS - Centrado en la arquitecturaEl Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema
    Por eso existen múltiples modelos y vistas que definen la arquitectura de software de un sistema
    Analogía: Si se construye un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.
  24. 24MODELAMIENTO UNIFICADO CARACTERISTICAS - Enfocado en los riesgosSe requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida
    Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero
  25. 25MODELO UNIFICADO FASES - INICIODefinición el negocio. Se facilita realizar el proyecto. Presentación de un modelo, visión, metas, deseos del usuario, plazos, costos y viabilidad.
  26. 26MODELO UNIFICADO FASES - ELABORACIONSe obtiene la visión refinada del proyecto a realizar, la implementación iterativa del núcleo de la aplicación, la resolución de riesgos altos, nuevos requisitos y se ajustan las estimaciones
  27. 27MODELO UNIFICADO FASES - CONSTRUCCIONAbarca la evolución hasta convertirse en producto listo incluyendo requisitos mínimos. Se afinan los detalles menores como los diferentes tipos de casos o los riesgos menores
  28. 28MODELO UNIFICADO FASES - TRANSICIONFase final, el programa debe estar listo para ser probado, instalado y utilizado por el cliente sin ningún problema. Una vez finalizada esta fase, se debe comenzar a pensar en futuras novedades para la misma
  29. 29PROGRAMACION XTREMEXp forma parte del conjunto de métodos ágiles que centran sus prioridades en las personas, no en los procesos
  30. 30PROGRAMACION XTREMEMetodología basada en un conjunto de reglas y buenas prácticas para el desarrollo de software en ambientes muy cambiantes con requisitos imprecisos, por ende está enfocada en la retroalimentación continua entre el equipo de desarrollo y el cliente.
  31. 31PROGRAMACION XTREMEIniciando el proyecto se deben definir todos los requisitos, para luego invertir el esfuerzo en manejar los cambios que se presenten y así minimizar las posibilidades de error
  32. 32PROGRAMACION XTREMEEn la actualidad Xp se proyecta a ser un modelo de desarrollo común, sencillo y adaptable a las características cambiantes y exigentes de empresas y clientes
  33. 33PROGRAMACION XTREME CARACTERISTICASCaracterísticas
    Desarrollo iterativo e incremental
    Programación en parejas
    Pruebas unitarias continuas
    Corrección periódica de errores
    Integración del equipo de programación con el cliente
    Simplicidad, propiedad del código compartida y refactorización del código
  34. 34PROGRAMACION XTREME PRINCIPIOS - ComunicaciónEs importante que haya una comunicación constante con el cliente y dentro de todo el equipo de trabajo. Debe llevarse a cabo de una manera sencilla, entendible y que se entregue al cliente lo que necesita
  35. 35PROGRAMACION XTREME PRINCIPIOS - simplicidadSe refiere que ante todo y sin importar qué funcionalidad requiera el usuario en su sistema. Éste debe ser fácil, de diseño sencillo y amigable al usuario, el código debe ser simple y entendible, programando sólo lo necesario y lo que se utilizará
  36. 36PROGRAMACION XTREME PRINCIPIOS - retroalimentacionEs la comunicación constante entre el desarrollador y el usuario.
  37. 37PROGRAMACION XTREME PRINCIPIOS - corajeValor para modificar o eliminar el código que se realizó con tanto esfuerzo. Identificar cuando el código que desarrolló no es útil en el sistema. Persistencia para resolver los errores en la programación
  38. 38SCRUMMetodología, que trabaja con el ciclo de vida iterativo e incremental, donde se va liberando el producto por pares de forma periódica
  39. 39SCRUMSe aplican buenas prácticas de trabajo colaborativo (en equipo), facilitando el hallazgo de soluciones óptimas a los problemas que pueden ir surgiendo en el proceso de desarrollo del proyecto
  40. 40SCRUMSe realizan entregas regulares y parciales (sprint) del producto final, todas ellas con una prioridad previamente establecida que nace según el beneficio que aporten al cliente
  41. 41SCRUMMinimizan los riesgos que pueden surgir de desarrollos extremadamente largos
  42. 42SCRUMMetodología apropiada para proyectos en entornos complejos, donde se necesitan obtener resultados de manera inmediata
  43. 43SCRUM EQUIPO - STAKEHOLDEREs el cliente. Responsabilidad: Definir los requerimientos, recibir el producto al final de cada iteración y proporcionar el feedback correspondiente
  44. 44SCRUM EQUIPO - PRODUCT OWNEREs el intermediario de la comunicación entre el cliente y el equipo de desarrollo. Prioriza los requerimientos según sean las necesidades de la solicitud
  45. 45SCRUM EQUIPO - SCRUM MASTERFacilitador ante todo el equipo de desarrollo. Elimina los impedimentos identificados durante el proceso, se encarga de que el equipo siga los valores y los principios ágiles, las reglas y los procesos de Scrum, incentiva al grupo de trabajo
  46. 46SCRUM EQUIPO - SCRUM TEAMEquipo auto gestionado. No existe un JEFE DE EQUIPO, motivo por el cual todos los miembros se deben de encargar de realizar las estimaciones y en base a la velocidad obtenida en las iteraciones irán construyendo el Sprint Backlog
  47. 47SCRUM REUNIONESUn punto fundamental en el proceso son las reuniones
    Se fomenta la comunicación y transparencia del proceso
  48. 48SCRUM Reunión de planificaciónSe debe realizar al inicio de cada sprint, esto con el objetivo de planificar la cantidad de trabajo a la que el equipo se va a comprometer a construir durante el próximo sprint
  49. 49SCRUM Reunión diariaReuniones cuyo lapso tiene un máximo 15 minutos, en ellas se realiza una retroalimentación de qué se hizo el día ayer, qué se hará hoy y cuáles han sido los problemas que han surgido hasta el momento. Objetivo: Establecer un plan para las próximas 24 horas
  50. 50SCRUM Reunión de revisiónSe lleva a cabo al final de cada sprint, en ellas se exponen los puntos completados y los que no
  51. 51SCRUM Reunión de retrospectivaReunión importante, constituye un espacio de reflexión y mejora continua. Una vez culminado un sprint se efectúa esta reunión, que tiene como objetivo que el equipo reflexione y saque como resultado posibles acciones de mejora. Quienes asisten: Todo el Equipo Scrum
  52. 52KANBANProviene del japonesa cuyo significado es “Tarjeta Visual”
  53. 53KANBANEs un marco de trabajo que requiere una comunicación en tiempo real sobre la capacidad del equipo
  54. 54KANBANUtiliza, para controlar el avance de trabajo, una línea de producción, en la cual se clasifican las tareas en sub estatus, esto con la intención de determinar los niveles de productividad en cada fase del proyecto
  55. 55KANBANPara el desarrollo de software:
    Se simplifica la planificación y la asignación de responsabilidades en un tablero
    Se representan los procesos del flujo de trabajo
    Cómo mínimo deben existir tres columnas (Pendiente, En Progreso, Terminado)
    La cantidad de tarjetas en estatus pendiente forma parte de lo solicitado por el cliente, aquellas colocadas en progreso dependerán de la capacidad del equipo de trabajo

Information

Description
Flashcards on MODELOS DE ANALISIS, created by Xime Moreno on 03/09/2019.
Created by
Xime Moreno
Views
0
Rating

Feedback

What is it about?

What do you think of the new look?

How do you like it?