Modelo de cascada	Se muestra el orden explíto de los eventos Al fin de cada epidodio tenemos un conjunto completo de artefactos (componentes constitutivos) Problemas En la vida real, pocos proyectos siguen una secuencia linealq
Iteración e incremento	Las operaciones de análisis se extienden a lo largo del ciclo de vida Cada versión procura acercarse más al blanco de su predecesora Los aspectos se atienden en orden de importancia actual Hay múltiples instancias de cada fase
Fortalezas de iteración e incremento	Se puede verificar el producto de software en cada iteración La robusrez de la arquitectura puede determinarse temprano Podemos mitigar riesgos temprano Se tiene una versión funcional desde el principio
Iterativo-Incremental versus cascada	EL modelo iterativo incremental es el modelo de cascada, aplicado sucesivamente. Cada incremento es un mini proyecto de cascada
Modelo de codificar y arreglar	No hay diseño No hay especificaciones (mal para el mantenimiento) La forma más fácil de desarrollar software pero la más cara
Programación extrema	Nuevo enfoque Historias Estimar duración y costo de cada historia Seleccionar historias para la siguiente construcción Cada construcción se divvide en tareas Los casos de prueba se redactan primero Programación por pares Integración continua de tareas
Pocesos ágiles	Menos énfasis Implementación más temprana (menos importancia de documentación) Rápida respuesta al cambio Colaboración cercana con el cliente Son buenos cuando los requerimientos son vagos o cambiantes
Modelo de sincronización y estabilización	Modelo de ciclo de vida de Microsoft Entrevistar clientes potenciales Dividir proyecto en estructuras que se llevan a cabo por equipos en paralelo que se sincronizan al final del día (depuración) Al final de la estructura se estabiliza (congelar la obra)
Prototipado rápido	Las imperfecciones se pueden ignorar Solo muestra la funcionalidad clave Enfasis en lo que el cliente ve Su objetivo es proveer al cliente una comprensión del producto Se construye para cambiarse
Prototipado rápido	El cliente y los usuarios deben interactuar con el interfaz de usuario El mantenimiento es difícil sin documentos de especificación y diseño Las restricciones de tiempo real son difíciles de satisfacer
Modelo en espiral	Proceder cada fase por: alternativas y análisis de riesgo Seguir cada fase por: evaluación y planeación de la siguiente fase. Dimensión radial: costo acumulado a la fecha Dimensión angular: progreso a través de la espiral
Fortalezas y debilidades	Es fácil juzgar cuantas pruebas hacerse, no se hace distinción entre desarrollo y mantenimiento Solo para software a gran escala y de desarrollo interno
Flujo de trabajo de requerimientos	Comprender el dominio de la aplicación Construir un modelo de negocio Usar el modelo de negocio para determinar los requerimientos del cliente
Dominio	Cada miembro del equipo de desarrollo debe volverse completamente familiar con el dominio de la aplicación Construir un glosario: lista de palabras técnicas usadas en el dominio, y sus significados
Modelo de negocio	ES una descripción de los procesos de negocio de una organización Proporciona una comprensión del negocio del cliente como un todo (esencial para asesorar al cliente con respecto a la compurarización) El analista necesita obtener una comprensión detallada de los diversos procesos de negocio
Entrevista	Encuentro con el cliente para extraer información relevante Preguntas cerradas: Requieren una respuesta específica Preguntas abiertas: Permiten al entrevistado explayarse
Otras técnicas de relevamiento	Encuesta: es útil cuando se necesita determinar las opiniones de cientos de individuos Formularios: los formularios de negocios muestran como trabaja actualmente el cliente Observación directa: puede ser util pero también es poco práctica (examinar cintas, los empleados pueden cohibirse)
Caso de uso	Modela una interacción entre el producto de software mismo y los usuarios de ese producto de software
Actor	Miembro del mundo exterior al producto de software Juega un rol con relación al producto cmo usuario, iniciador o alguien que desempeña una parte crítica en el caso de uso, un usuario puede tener más de un rol No necesita ser un humano (sistema externo, el tiempo)
Requerimientos	Se basan en el modelo de negocios inicial, después se van perfeccionando Los requerimientos son dinámicos- hay cambios frecuentes
Categorías de requerimientos	Funcional: especificca una acción que el producto de software debe poder realizar No funcional: especifica propiedades del producto de software mismo como restricciones de plataforma o tiempos de respuesta
Proceso unificado	en una metodología adaptable, ha de ser modificada para el producto de software específico a desarrollarse, no es un asecuencia de pasos para construir un producto de software
UML	Es gráfico, los diagramas permiten a los ingenieros de software comunicarse rápidamente y con precisión. El proceso unificado es una técnica de modelado, UML (lenguaje unificado de modelado)
Artefactos de requerimientos	Todo item entre los artefactos del análisis debe ser trazable a un item en los artefactos de requerimientos
Artefactos del análisis	Deben verificarse por medio de una revisión con representantes del cliente y el equipo de análisis
Artefactos del diseño	Las revisiones del diseño son esenciales, generalmente sin la presencia de un representante del cliente
Artefactos de la implementación	Cada componente se prueba en cuanto está implementado Al final de cada iteración, los componentes son combinados y probados (prueba de integración) Cuando el producto parece estar completa se prueba como un todo (prueba del producto) El cliente prueba el producto una vez instalado (prueba de aceptación)
Mantenimiento posentrega	Los problemas pueden ser causados por falta de documentación de todo tipo
Tipos de prueba	Pruebas de cambios hechos durante el mantenimiento posentrega Pruebas de regresión: Repetir casos de pruebas anteriores para cerciorarse de que no se comprometio nada del resto del producto
Retiro	Un software puede ser inmantenible por Un cambio drástico en el diseño El producto debe implementarse en una plataforma totalmente nueva hardware/sistem operativo Falta documentación o es inexacta Estas son instancias de mantenimiento (reescribir el software existente)
Retiro real	Es infrecuente, ocurre cuando la organización del cliente ya no necesita la funcionalidad proporcionada por el producto
Ventajas modelo iterativo incremental	Modela la producción de software en el mundo real y utiliza el proceso unificado
Ventajas y desventajas Codificar y arreglar	Es util para programas pequeños que no requieren mantenimiento No sirve para sistemas más grandes
Ventajas y desventajas modelo cascada	Es disciplinado y posee buena documentación pero el producto entregado podría no satisfacer las necesidades del cliente
Ventajas y desventajas prototipado rápido	Asegura que el producto entregado satisface las necesidades del cliente aunque le faltan más pruebas
Programación extrema	Funciona cuando los requerimientos del cliente no son del todo claros aunque aparentemente solo funciona con proyectos pequeños
Sincronizar y estabilizar	Asegura una integración exitosa entre componentes pero solo ha sido probado por Microsoft
Modelo espiral	Orientado al riesgo, solo puede utilizarse en grandes proyectos internos.

Descubre

Crear Tarjetas

Acerca de Nosotros

Explore Tarjetas

Comparta este Set de Tarjetas de Aprendizaje

Tarjetas de Aprendizaje relacionadas

Modelos De Ciclo De Vida

Cómo estudiar sus tarjetas

Rango de Cartas a estudiar

38 Cartas en este set