Mapa de Unidad 4 Ingeniería de Software

SALOMON CANCHOLA ESPINOZA
Mind Map by SALOMON CANCHOLA ESPINOZA, updated more than 1 year ago
SALOMON CANCHOLA ESPINOZA
Created by SALOMON CANCHOLA ESPINOZA over 3 years ago
1
0

Description

Mapa que contiene información de los capítulos 10 y 11

Resource summary

Mapa de Unidad 4 Ingeniería de Software
1 Mapear Modelos al Código
1.1 Visión Ganeral del Mapeo
1.1.1 Actividades
1.1.1.1 Optimización
1.1.1.1.1 Se dirige al rendimiento de los requisitos del modelo del sistema.
1.1.1.1.1.1 Cuatro optimizaciones sencillas
1.1.1.1.1.1.1 Añadir asociaciones para optimizar las rutas de acceso
1.1.1.1.1.1.1.1 Fuentes de Ineficiencia
1.1.1.1.1.1.1.1.1 Recorridos repetidos de asociación
1.1.1.1.1.1.1.1.2 Asociaciones muchos a muchos
1.1.1.1.1.1.1.1.3 Atributos fuera de lugar
1.1.1.1.1.1.2 Colapsar objetos en atributos
1.1.1.1.1.1.2.1 Convertir clases en atributos para reducir complejidad del modelo.
1.1.1.1.1.1.3 Retrasar los cálculos costosos
1.1.1.1.1.1.3.1 Objetos específicos caros (pesados) para crear, su creación puede ser a menudo retrasada hasta que se necesite su contenido real.
1.1.1.1.1.1.4 Almacenar en caché los resultados de los cálculos costosos
1.1.1.1.1.1.4.1 Reducción de cálculos en métodos cuyos resultados no cambian con frecuencia, mediante el uso de un atributo privado.
1.1.1.2 Implementar asociaciones
1.1.1.2.1 Se elabora mapa de asociaciones a partir del codigo fuente.
1.1.1.2.1.1 Tipos de Asociaciones
1.1.1.2.1.1.1 Unidireccionales uno-a-uno
1.1.1.2.1.1.2 Bidireccionales uno-a-uno
1.1.1.2.1.1.3 Uno-a-muchos
1.1.1.2.1.1.4 Muchos-a-muchos
1.1.1.2.1.1.5 Cualificadas
1.1.1.2.1.1.6 De clases
1.1.1.3 Mapear Contratos a Excepciones
1.1.1.3.1 Se describe el comportamiento de las operaciones cuando los contratos se rompen.
1.1.1.3.1.1 Incluye
1.1.1.3.1.1.1 Comprobar condiciones previas
1.1.1.3.1.1.2 Comprobar condiciones posteriores
1.1.1.3.1.1.3 Comprobar invariantes
1.1.1.3.1.1.4 Hacer frente a la herencia
1.1.1.3.1.1.5 Esfuerzo de Codificación
1.1.1.3.1.1.6 Aumento de las oportunidades de los defectos
1.1.1.3.1.1.7 Código ofuscado
1.1.1.3.1.1.8 Encontrar excepciones mediante
1.1.1.3.1.1.8.1 Omitir la comprobación de código para condiciones posteriores e invariantes
1.1.1.3.1.1.8.2 Centrarse en las interfaces del subsistema y omitir el código de verificación asociado con métodos privados y protegidos
1.1.1.3.1.1.8.3 Centrarse en los contratos de los componentes con la vida más larga.
1.1.1.3.1.1.8.3.1 Es decir, el código con más susceptibilidad de ser reutilizados y para sobrevivir a liberaciones sucesivas
1.1.1.3.1.1.8.4 Reutilización de código de comprobación de restricción
1.1.1.4 Mapear el modelo de clases a un esquema de almacenamiento
1.1.1.4.1 Selección de una estrategia de almacenamiento persistente (BD, archivos, etc.).
1.1.1.4.1.1 Base de Datos
1.1.1.4.1.1.1 Proceso de mapeo
1.1.1.4.1.1.1.1 Mapear clases y atributos
1.1.1.4.1.1.1.1.1 Mapeo de asociaciones
1.1.1.4.1.1.1.1.1.1 Mapeo de relaciones de herencia
1.1.1.4.1.1.1.1.1.1.1 Dos tipos
1.1.1.4.1.1.1.1.1.1.1.1 Mapeo Vertical
1.1.1.4.1.1.1.1.1.1.1.2 Mapeo Horizontal
1.2 Transformación
1.2.1 Tiene por objeto mejorar un aspecto del modelo, mientras conserva todas sus propiedades.
1.2.1.1 Cuatro tipos
1.2.1.1.1 Transformaciones de modelos
1.2.1.1.1.1 Su proposito es simplificar u optimizar el modelo original, con lo mas proximo al cumplimiento de todos los requisitos en la especificación.
1.2.1.1.1.1.1 Pueden ocurrir errores
1.2.1.1.1.1.1.1 Medidas para evitarlo cada transformación
1.2.1.1.1.1.1.1.1 1.- Debe abordar un solo criterio. 2.- Debe ser local. 3.- Se debe aplicar aislada de otros cambios. 4.- Debe ser seguido por una etapa de validación.
1.2.1.1.2 Refactorizaciones
1.2.1.1.2.1 Es una transformación del código fuente que mejora su legibilidad o modificabilidad sin cambiar el comportamiento del sistema.
1.2.1.1.3 Ingeniería hacia adelante
1.2.1.1.3.1 Su proposito es mantener una fuerte correspondencia entre el objeto del diseño del modelo y él código, reduciendo así el numero de errores y el esfuerzo de implementación.
1.2.1.1.4 Ingeniería Inversa
1.2.1.1.4.1 Su proposito es volver a crear el modelo para un sistema existente, ya sea porque el modelo se perdió o nunca fue creado, etc.
1.3 Gestión de la Implementación
1.3.1 Transformaciones de la Documentación
1.3.1.1 Información perdida en el proceso a causa de
1.3.1.1.1 Asociaciones de multiplicidad y colecciones
1.3.1.1.2 Asociaciones de multiplicidad y asociaciones enterradas
1.3.1.1.3 Condiciones posteriores e invariantes
1.3.1.1.4 Reducir problema mediante
1.3.1.1.4.1 Para una transformación dada, utilice la misma herramienta
1.3.1.1.4.2 Mantenga los contratos en el código fuente, no en el modelo de diseño de objetos
1.3.1.1.4.3 Utilice los mismos nombres para los mismos objetos
1.3.1.1.4.4 Hacer transformaciones explícitas
1.3.2 Asignación de Responsabilidades
1.3.2.1 Papeles
1.3.2.1.1 Arquitecto principal
1.3.2.1.1.1 selecciona las transformaciones que deben aplicarse sistemáticamente
1.3.2.1.2 Enlace de arquitectura
1.3.2.1.2.1 Es el responsable de la documentación de los contratos asociados a las interfaces del subsistema
1.3.2.1.3 Programador
1.3.2.1.3.1 Es responsable de seguir las convenciones establecidas por el arquitecto principal y en realizar la aplicación de las transformaciones y convertir el modelo de diseño de objetos en código fuente
2 Pruebas
2.1 ¿Qué son?
2.1.1 Son el intento sistemático para encontrar fallas de manera planificada en el software implementado
2.1.1.1 visión general de las actividades de prueba
2.1.1.1.1 Planificación de Pruebas
2.1.1.1.1.1 Asigna recursos y horarios de la prueba.
2.1.1.1.2 Pruebas de usabilidad
2.1.1.1.2.1 Trata de encontrar fallas en el diseño de la interfaz de usuario del sistema.
2.1.1.1.3 Prueba de la unidad
2.1.1.1.3.1 Trata de encontrar fallas en los objetos y/o subsistemas participantes con respecto a los casos de uso del modelo de casos de uso.
2.1.1.1.4 Pruebas de integración
2.1.1.1.4.1 Es la actividad de búsqueda de fallas para probar los componentes individuales en combinación.
2.1.1.1.4.2 Culmina en
2.1.1.1.4.2.1 Ensayo estructural
2.1.1.1.5 Pruebas del sistema
2.1.1.1.5.1 Pone a prueba todos los componentes juntos, vistos como un solo sistema para identificar fallas con respecto a los escenarios de la declaración del problema, los requisitos y objetivos de diseño identificados en el análisis y diseño de sistemas.
2.1.1.1.5.1.1 integra
2.1.1.1.5.1.1.1 Pruebas funcionales
2.1.1.1.5.1.1.1.1 Pruebas de los requisitos de la RAD y el manual de usuario.
2.1.1.1.5.1.1.1.2 Llevado a cabo por
2.1.1.1.5.1.1.1.2.1 Desarrolladores
2.1.1.1.5.1.1.2 Pruebas de rendimiento
2.1.1.1.5.1.1.2.1 comprueba los requisitos no funcionales y de diseño adicional las metas del SDD.
2.1.1.1.5.1.1.2.2 Llevado a cabo por
2.1.1.1.5.1.1.2.2.1 Desarrolladores
2.1.1.1.5.1.1.3 Pruebas de aceptación y control
2.1.1.1.5.1.1.3.1 Para la instalación del sistema en contra del proyecto acuerdo.
2.1.1.1.5.1.1.3.1.1 Hecho por
2.1.1.1.5.1.1.3.1.1.1 Clientes
2.1.1.1.5.1.1.3.1.1.2 Desarrolladores
2.2 Conceptos
2.2.1 Componente de prueba
2.2.1.1 Es una parte del sistema que puede ser aislado para la prueba. Un componente puede ser un objeto, un grupo de objetos, o uno o más subsistemas.
2.2.2 Falla
2.2.2.1 También llamado error o defecto, es un diseño o error de codificación que puede causar comportamiento del componente anormal.
2.2.2.2 Es una desviación entre la especificación y el comportamiento real.
2.2.3 Estado erróneo
2.2.3.1 Es una manifestación de un fallo durante la ejecución del sistema.
2.2.4 Caso de prueba
2.2.4.1 Es un conjunto de insumos y resultados esperados que ejerce un componente de prueba con el propósito de causar fallas y la detección de fallas.
2.2.4.1.1 Tiene cinco atributos
2.2.4.1.1.1 name
2.2.4.1.1.1.1 Nombre del caso de prueba.
2.2.4.1.1.2 location
2.2.4.1.1.2.1 Ruta completa del ejecutable
2.2.4.1.1.3 input
2.2.4.1.1.3.1 Datos o comandos de entrada
2.2.4.1.1.4 oracle
2.2.4.1.1.4.1 Resultados esperados de pruebas los cuales son comparados con los obtenidos por las pruebas
2.2.4.1.1.5 log
2.2.4.1.1.5.1 Salida producida por la prueba
2.2.4.1.2 Clasificación
2.2.4.1.2.1 Pruebas de caja negra
2.2.4.1.2.1.1 Se centran en el comportamiento de entrada/salida del componente.
2.2.4.1.2.2 Pruebas de caja blanca
2.2.4.1.2.2.1 Se centran en la estructura interna del componente.
2.2.5 Talón de prueba
2.2.5.1 Es una implementación parcial de los componentes en los que el componente de la prueba depende.
2.2.5.1.1 Sustituyen
2.2.5.1.1.1 Partes del sistema que faltan
2.2.6 Piloto de pruebas
2.2.6.1 Es una implementación parcial de un componente que depende del componente de prueba.
2.2.7 Corrección
2.2.7.1 Es un cambio a un componente. El propósito de una corrección es reparar una falla
2.3 Actividades
2.3.1 Inspección de componentes
2.3.1.1 Métodos
2.3.1.1.1 David Parnas
2.3.1.1.1.1 Revisión del diseño
2.3.1.1.1.1.1 Elimina la reunión de inspección de todos los miembros del equipo de inspección
2.3.1.1.2 Michael Fagan
2.3.1.1.2.1 Inspección de Fagan
2.3.1.1.2.1.1 Pasos
2.3.1.1.2.1.1.1 Información general
2.3.1.1.2.1.1.1.1 Preparación
2.3.1.1.2.1.1.1.1.1 Reunión de Inspección
2.3.1.1.2.1.1.1.1.1.1 Re trabajo
2.3.1.1.2.1.1.1.1.1.1.1 Seguimiento
2.3.1.1.2.1.2 Se lleva a cabo por un equipo de desarrolladores, entre ellos el autor del componente, un moderador que facilita el proceso y uno o más revisores que se encuentran fallas en el componente.
2.3.1.2 Encuentra fallas en un componente individual a través de la inspección manual de su código fuente
2.3.2 Pruebas de usabilidad
2.3.2.1 Tres tipos
2.3.2.1.1 Prueba de Prototipo
2.3.2.1.1.1 Los usuarios finales se presentan con un trozo de software que implementa los aspectos clave del sistema.
2.3.2.1.1.2 Tipos
2.3.2.1.1.2.1 Horizontal
2.3.2.1.1.2.1.1 Implementa una sola capa del sistema.
2.3.2.1.1.2.2 Vertical
2.3.2.1.1.2.2.1 implementa un caso de uso a través del sistema.
2.3.2.1.1.2.3 Mago de Oz
2.3.2.1.1.2.3.1 prototipo de interfaz de usuario en la que un operador humano está detrás de las escenas para tirar de las palancas
2.3.2.1.2 Prueba del producto
2.3.2.1.2.1 Es similar a la prueba de prototipo, excepto que una versión funcional del sistema se utiliza en lugar del prototipo.
2.3.2.1.3 Prueba de Escenario
2.3.2.1.3.1 Uno o más usuarios se les presentan una visión de un futuro escenario del sistema.
2.3.3 Prueba de la unidad
2.3.3.1 Más importantes
2.3.3.1.1 Equivalencia
2.3.3.1.2 Limites
2.3.3.1.3 Ruta
2.3.3.1.4 Basada en el estado
2.3.4 Pruebas de integración
2.3.4.1 Tpos
2.3.4.1.1 Vertical
2.3.4.1.1.1 Componentes son integrados de acuerdo a las funciones.
2.3.4.1.2 Horizontal
2.3.4.1.2.1 Componentes se integran de acuerdo con capas.
2.3.4.1.2.2 Varios Enfoques
2.3.4.1.2.2.1 Big Bang
2.3.4.1.2.2.2 De abajo hacia arriba
2.3.4.1.2.2.3 De arriba hacia abajo
2.3.4.1.2.2.4 Sándwich
2.3.4.1.2.2.5 Sándwich modificado
2.3.4.2 Detectan las fallas que no han sido detectadas durante las pruebas unitarias centrándose en pequeños grupos de componentes.
2.3.5 Pruebas del sistema
2.3.5.1 Se aseguran de que todo el sistema cumple con los requisitos funcionales y no funcionales.
2.3.5.1.1 Actividades
2.3.5.1.1.1 Pruebas funcionales
2.3.5.1.1.2 Pruebas de rendimiento
2.3.5.1.1.3 Pruebas piloto
2.3.5.1.1.4 Pruebas de aceptación
2.3.5.1.1.5 Pruebas de instalación
2.4 Administración
2.4.1 Describe la forma de gestionar las actividades de prueba para minimizar los recursos necesarios.
2.4.1.1 Se describe
2.4.1.1.1 Planificación de pruebas
2.4.1.1.1.1 A continuación, se describe
2.4.1.1.1.1.1 Pruebas de D
2.4.1.1.1.1.1.1 A continuación, se describen
2.4.1.1.1.1.1.1.1 Asignación de Responsabilidades
2.4.1.1.1.1.1.1.1.1 A continuación, se discuten
2.4.1.1.1.1.1.1.1.1.1 Pruebas de Regresión
2.4.1.1.1.1.1.1.1.1.2 Pruebas Automatizadas
2.4.1.1.1.1.1.1.1.1.3 Pruebas basadas en modelos
Show full summary Hide full summary

Similar

FUNDAMENTOS DE REDES DE COMPUTADORAS
anhita
Abreviaciones comunes en programación web
Diego Santos
Seguridad en la red
Diego Santos
Conceptos básicos de redes
ARISAI DARIO BARRAGAN LOPEZ
Evolución de la Informática
Diego Santos
TECNOLOGÍA TAREA
Denisse Alcalá P
Navegadores de Internet
al210561
DISPOSITIVOS DE ALMACENAMIENTO
Esteban Bravo3B
Mapa Conceptual de la arquitectura de base de datos
Alan Alvarado
Mapa Conceptual Hardware y Software
Jeferson Alfonso Alvarado Suarez
Curso Basico De Android
manrongel