• Barajar
    Activar
    Desactivar
  • Alphabetizar
    Activar
    Desactivar
  • Frente Primero
    Activar
    Desactivar
  • Ambos lados
    Activar
    Desactivar
  • Leer
    Activar
    Desactivar
Leyendo...
Frente

Cómo estudiar sus tarjetas

Teclas de Derecha/Izquierda: Navegar entre tarjetas.tecla derechatecla izquierda

Teclas Arriba/Abajo: Colvea la carta entre frente y dorso.tecla abajotecla arriba

Tecla H: Muestra pista (3er lado).tecla h

Tecla N: Lea el texto en voz.tecla n

image

Boton play

image

Boton play

image

Progreso

1/38

Click para voltear

38 Cartas en este set

  • Frente
  • Atrás
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.