Karteikarten
MODELOS DE ANALISIS
Karten in diesem Stapel (55)
- 1MODELO EN CASCADAModelo conocido como: Modelo clásico, modelo tradicional o modelo lineal secuencial
- 2MODELO EN CASCADAModelo en el cual se ordenan rigurosamente las etapas del desarrollo del software
- 3MODELO EN CASCADAEnfoque clásico para el ciclo de vida del desarrollo de sistemas
- 4MODELO EN CASCADAEl inicio de una etapa de desarrollo deba de esperar el fin de la etapa anterior
- 5MODELO EN CASCADACualquier error detectado lleve al rediseño del área de código afectado, lo cual aumenta de costo el desarrollo del proyecto
- 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
- 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 - 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 - 9MODELO EN ESPIRALLas actividades se realizan conforme se van seleccionando de acuerdo al análisis de riesgo
- 10MODELO EN ESPIRALEn cada iteración se deberán de tomar en cuenta los objetivos
- 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
- 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 - 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 - 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
- 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 - 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 - 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 - 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
- 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
- 20MODELO UNIFICADOSus principales características son:
Es iterativo e incremental, dirigido por casos de uso, centrado en la arquitectura y enfocado en los riesgos - 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 - 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 - 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. - 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 - 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.
- 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
- 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
- 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
- 29PROGRAMACION XTREMEXp forma parte del conjunto de métodos ágiles que centran sus prioridades en las personas, no en los procesos
- 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.
- 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
- 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
- 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 - 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
- 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á
- 36PROGRAMACION XTREME PRINCIPIOS - retroalimentacionEs la comunicación constante entre el desarrollador y el usuario.
- 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
- 38SCRUMMetodología, que trabaja con el ciclo de vida iterativo e incremental, donde se va liberando el producto por pares de forma periódica
- 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
- 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
- 41SCRUMMinimizan los riesgos que pueden surgir de desarrollos extremadamente largos
- 42SCRUMMetodología apropiada para proyectos en entornos complejos, donde se necesitan obtener resultados de manera inmediata
- 43SCRUM EQUIPO - STAKEHOLDEREs el cliente. Responsabilidad: Definir los requerimientos, recibir el producto al final de cada iteración y proporcionar el feedback correspondiente
- 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
- 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
- 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
- 47SCRUM REUNIONESUn punto fundamental en el proceso son las reuniones
Se fomenta la comunicación y transparencia del proceso - 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
- 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
- 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
- 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
- 52KANBANProviene del japonesa cuyo significado es “Tarjeta Visual”
- 53KANBANEs un marco de trabajo que requiere una comunicación en tiempo real sobre la capacidad del equipo
- 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
- 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
Informationen
- Beschreibung
- Karteikarten am MODELOS DE ANALISIS, erstellt von Xime Moreno am 03/09/2019.
- Erstellt von
- Xime Moreno
- Aufrufe
- 0
- Bewertung