7149210
Beschreibung
Mindmap von SALOMON CANCHOLA ESPINOZA, aktualisiert more than 1 year ago
|
Erstellt von SALOMON CANCHOLA ESPINOZA
vor etwa 8 Jahre
|
|
Mapa de Unidad 4 Ingeniería de
Software
- Mapear Modelos al Código
- Visión Ganeral
del Mapeo
- Actividades
- Optimización
- Se dirige al rendimiento de
los requisitos del modelo
del sistema.
- Cuatro
optimizaciones
sencillas
- Añadir asociaciones para optimizar las rutas de acceso
- Fuentes de Ineficiencia
- Recorridos repetidos de asociación
- Asociaciones muchos a muchos
- Atributos fuera de lugar
- Recorridos repetidos de asociación
- Fuentes de Ineficiencia
- Colapsar objetos en atributos
- Convertir clases en atributos para
reducir complejidad del modelo.
- Convertir clases en atributos para
reducir complejidad del modelo.
- Retrasar los cálculos costosos
- Objetos específicos caros (pesados) para crear,
su creación puede ser a menudo retrasada
hasta que se necesite su contenido real.
- Objetos específicos caros (pesados) para crear,
su creación puede ser a menudo retrasada
hasta que se necesite su contenido real.
- Almacenar en caché los resultados de los cálculos costosos
- Reducción de cálculos en métodos cuyos resultados no cambian
con frecuencia, mediante el uso de un atributo privado.
- Reducción de cálculos en métodos cuyos resultados no cambian
con frecuencia, mediante el uso de un atributo privado.
- Añadir asociaciones para optimizar las rutas de acceso
- Cuatro
optimizaciones
sencillas
- Se dirige al rendimiento de
los requisitos del modelo
del sistema.
- Implementar
asociaciones
- Se elabora mapa de
asociaciones a partir del
codigo fuente.
- Tipos de
Asociaciones
- Unidireccionales
uno-a-uno
- Bidireccionales
uno-a-uno
- Uno-a-muchos
- Muchos-a-muchos
- Cualificadas
- De clases
- Unidireccionales
uno-a-uno
- Tipos de
Asociaciones
- Se elabora mapa de
asociaciones a partir del
codigo fuente.
- Mapear Contratos a
Excepciones
- Se describe el comportamiento
de las operaciones cuando los
contratos se rompen.
- Incluye
- Comprobar condiciones previas
- Comprobar condiciones posteriores
- Comprobar invariantes
- Hacer frente a la herencia
- Esfuerzo de Codificación
- Aumento de las oportunidades de los defectos
- Código ofuscado
- Encontrar excepciones mediante
- Omitir la comprobación de
código para condiciones
posteriores e invariantes
- Centrarse en las interfaces del subsistema
y omitir el código de verificación asociado
con métodos privados y protegidos
- Centrarse en los contratos
de los componentes con la
vida más larga.
- Es decir, el código con más
susceptibilidad de ser
reutilizados y para sobrevivir a
liberaciones sucesivas
- Es decir, el código con más
susceptibilidad de ser
reutilizados y para sobrevivir a
liberaciones sucesivas
- Reutilización de código de
comprobación de restricción
- Omitir la comprobación de
código para condiciones
posteriores e invariantes
- Comprobar condiciones previas
- Incluye
- Se describe el comportamiento
de las operaciones cuando los
contratos se rompen.
- Mapear el modelo de clases a
un esquema de
almacenamiento
- Selección de una estrategia
de almacenamiento
persistente (BD, archivos,
etc.).
- Base de Datos
- Proceso de mapeo
- Mapear clases y atributos
- Mapeo de asociaciones
- Mapeo de relaciones de herencia
- Dos tipos
- Mapeo Vertical
- Mapeo Horizontal
- Mapeo Vertical
- Dos tipos
- Mapeo de relaciones de herencia
- Mapeo de asociaciones
- Mapear clases y atributos
- Proceso de mapeo
- Base de Datos
- Selección de una estrategia
de almacenamiento
persistente (BD, archivos,
etc.).
- Optimización
- Actividades
- Transformación
- Tiene por objeto mejorar un aspecto del
modelo, mientras conserva todas sus
propiedades.
- Cuatro
tipos
- Transformaciones
de modelos
- Su proposito es simplificar u optimizar el modelo
original, con lo mas proximo al cumplimiento de
todos los requisitos en la especificación.
- Pueden ocurrir errores
- Medidas para evitarlo cada
transformación
- 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.- 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.
- Medidas para evitarlo cada
transformación
- Pueden ocurrir errores
- Su proposito es simplificar u optimizar el modelo
original, con lo mas proximo al cumplimiento de
todos los requisitos en la especificación.
- Refactorizaciones
- Es una transformación del código fuente que mejora su legibilidad o
modificabilidad sin cambiar el comportamiento del sistema.
- Es una transformación del código fuente que mejora su legibilidad o
modificabilidad sin cambiar el comportamiento del sistema.
- Ingeniería hacia adelante
- 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.
- 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.
- Ingeniería
Inversa
- Su proposito es volver a crear el modelo para un sistema existente,
ya sea porque el modelo se perdió o nunca fue creado, etc.
- Su proposito es volver a crear el modelo para un sistema existente,
ya sea porque el modelo se perdió o nunca fue creado, etc.
- Transformaciones
de modelos
- Cuatro
tipos
- Tiene por objeto mejorar un aspecto del
modelo, mientras conserva todas sus
propiedades.
- Gestión de la Implementación
- Transformaciones de la Documentación
- Información perdida
en el proceso a
causa de
- Asociaciones de multiplicidad y colecciones
- Asociaciones de multiplicidad y
asociaciones enterradas
- Condiciones posteriores e invariantes
- Reducir problema mediante
- Para una transformación dada,
utilice la misma herramienta
- Mantenga los contratos en el código fuente,
no en el modelo de diseño de objetos
- Utilice los mismos nombres
para los mismos objetos
- Hacer transformaciones explícitas
- Para una transformación dada,
utilice la misma herramienta
- Asociaciones de multiplicidad y colecciones
- Información perdida
en el proceso a
causa de
- Asignación de Responsabilidades
- Papeles
- Arquitecto principal
- selecciona las
transformaciones que
deben aplicarse
sistemáticamente
- selecciona las
transformaciones que
deben aplicarse
sistemáticamente
- Enlace de arquitectura
- Es el responsable de la
documentación de los
contratos asociados a las
interfaces del subsistema
- Es el responsable de la
documentación de los
contratos asociados a las
interfaces del subsistema
- Programador
- 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
- 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
- Arquitecto principal
- Papeles
- Transformaciones de la Documentación
- Visión Ganeral
del Mapeo
- Pruebas
- ¿Qué son?
- Son el intento sistemático para
encontrar fallas de manera planificada
en el software implementado
- visión general de las actividades de prueba
- Planificación de Pruebas
- Asigna recursos y
horarios de la prueba.
- Asigna recursos y
horarios de la prueba.
- Pruebas de usabilidad
- Trata de encontrar fallas en el diseño de la
interfaz de usuario del sistema.
- Trata de encontrar fallas en el diseño de la
interfaz de usuario del sistema.
- Prueba de la unidad
- Trata de encontrar fallas en los objetos y/o subsistemas participantes
con respecto a los casos de uso del modelo de casos de uso.
- Trata de encontrar fallas en los objetos y/o subsistemas participantes
con respecto a los casos de uso del modelo de casos de uso.
- Pruebas de integración
- Es la actividad de búsqueda de fallas para probar
los componentes individuales en combinación.
- Culmina en
- Ensayo estructural
- Ensayo estructural
- Es la actividad de búsqueda de fallas para probar
los componentes individuales en combinación.
- Pruebas del sistema
- 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.
- integra
- Pruebas funcionales
- Pruebas de los requisitos de la
RAD y el manual de usuario.
- Llevado a cabo por
- Desarrolladores
- Desarrolladores
- Pruebas de los requisitos de la
RAD y el manual de usuario.
- Pruebas de rendimiento
- comprueba los requisitos no funcionales
y de diseño adicional las metas del SDD.
- Llevado a cabo por
- Desarrolladores
- Desarrolladores
- comprueba los requisitos no funcionales
y de diseño adicional las metas del SDD.
- Pruebas de aceptación y control
- Para la instalación del sistema en contra del proyecto acuerdo.
- Hecho por
- Clientes
- Desarrolladores
- Clientes
- Hecho por
- Para la instalación del sistema en contra del proyecto acuerdo.
- Pruebas funcionales
- integra
- 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.
- Planificación de Pruebas
- visión general de las actividades de prueba
- Son el intento sistemático para
encontrar fallas de manera planificada
en el software implementado
- Conceptos
- Componente de prueba
- 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.
- 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.
- Falla
- También llamado error o defecto, es un diseño o error de codificación
que puede causar comportamiento del componente anormal.
- Es una desviación entre la especificación y el comportamiento real.
- También llamado error o defecto, es un diseño o error de codificación
que puede causar comportamiento del componente anormal.
- Estado erróneo
- Es una manifestación de un fallo
durante la ejecución del sistema.
- Es una manifestación de un fallo
durante la ejecución del sistema.
- Caso de prueba
- 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.
- Tiene cinco atributos
- name
- Nombre del caso de prueba.
- Nombre del caso de prueba.
- location
- Ruta completa del ejecutable
- Ruta completa del ejecutable
- input
- Datos o comandos
de entrada
- Datos o comandos
de entrada
- oracle
- Resultados esperados de pruebas
los cuales son comparados con los
obtenidos por las pruebas
- Resultados esperados de pruebas
los cuales son comparados con los
obtenidos por las pruebas
- log
- Salida producida por la
prueba
- Salida producida por la
prueba
- name
- Clasificación
- Pruebas de caja negra
- Se centran en el
comportamiento
de entrada/salida
del componente.
- Se centran en el
comportamiento
de entrada/salida
del componente.
- Pruebas de caja blanca
- Se centran en la estructura
interna del componente.
- Se centran en la estructura
interna del componente.
- Pruebas de caja negra
- Tiene cinco atributos
- 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.
- Talón de prueba
- Es una implementación parcial de
los componentes en los que el
componente de la prueba depende.
- Sustituyen
- Partes del sistema
que faltan
- Partes del sistema
que faltan
- Sustituyen
- Es una implementación parcial de
los componentes en los que el
componente de la prueba depende.
- Piloto de pruebas
- Es una implementación parcial
de un componente que depende
del componente de prueba.
- Es una implementación parcial
de un componente que depende
del componente de prueba.
- Corrección
- Es un cambio a un componente. El propósito
de una corrección es reparar una falla
- Es un cambio a un componente. El propósito
de una corrección es reparar una falla
- Componente de prueba
- Actividades
- Inspección de componentes
- Métodos
- David Parnas
- Revisión del diseño
- Elimina la reunión de inspección de todos
los miembros del equipo de inspección
- Elimina la reunión de inspección de todos
los miembros del equipo de inspección
- Revisión del diseño
- Michael Fagan
- Inspección de Fagan
- Pasos
- Información general
- Preparación
- Reunión de Inspección
- Re trabajo
- Seguimiento
- Seguimiento
- Re trabajo
- Reunión de Inspección
- Preparación
- Información general
- 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.
- Pasos
- Inspección de Fagan
- David Parnas
- Encuentra fallas en un componente individual a
través de la inspección manual de su código fuente
- Métodos
- Pruebas de usabilidad
- Tres tipos
- Prueba de Prototipo
- Los usuarios finales se presentan con un trozo de
software que implementa los aspectos clave del sistema.
- Tipos
- Horizontal
- Implementa
una sola capa
del sistema.
- Implementa
una sola capa
del sistema.
- Vertical
- implementa un caso de uso a través del sistema.
- implementa un caso de uso a través del sistema.
- Mago de Oz
- prototipo de interfaz de usuario en la
que un operador humano está detrás de
las escenas para tirar de las palancas
- prototipo de interfaz de usuario en la
que un operador humano está detrás de
las escenas para tirar de las palancas
- Horizontal
- Los usuarios finales se presentan con un trozo de
software que implementa los aspectos clave del sistema.
- Prueba del producto
- Es similar a la prueba de prototipo, excepto que una versión
funcional del sistema se utiliza en lugar del prototipo.
- Es similar a la prueba de prototipo, excepto que una versión
funcional del sistema se utiliza en lugar del prototipo.
- Prueba de Escenario
- Uno o más usuarios se les presentan una visión
de un futuro escenario del sistema.
- Uno o más usuarios se les presentan una visión
de un futuro escenario del sistema.
- Prueba de Prototipo
- Tres tipos
- Prueba de la unidad
- Más importantes
- Equivalencia
- Limites
- Ruta
- Basada en el estado
- Equivalencia
- Más importantes
- Pruebas de integración
- Tpos
- Vertical
- Componentes son
integrados de acuerdo a
las funciones.
- Componentes son
integrados de acuerdo a
las funciones.
- Horizontal
- Componentes se
integran de
acuerdo con capas.
- Varios Enfoques
- Big Bang
- De abajo hacia arriba
- De arriba hacia abajo
- Sándwich
- Sándwich modificado
- Big Bang
- Componentes se
integran de
acuerdo con capas.
- Vertical
- Detectan las fallas que no han sido
detectadas durante las pruebas
unitarias centrándose en pequeños
grupos de componentes.
- Tpos
- Pruebas del sistema
- Se aseguran de que todo el sistema
cumple con los requisitos
funcionales y no funcionales.
- Actividades
- Pruebas funcionales
- Pruebas de rendimiento
- Pruebas piloto
- Pruebas de aceptación
- Pruebas de instalación
- Pruebas funcionales
- Actividades
- Se aseguran de que todo el sistema
cumple con los requisitos
funcionales y no funcionales.
- Inspección de componentes
- Administración
- Describe la forma de gestionar las actividades de
prueba para minimizar los recursos necesarios.
- Se describe
- Planificación de pruebas
- A continuación, se describe
- Pruebas de D
- A continuación, se describen
- Asignación de Responsabilidades
- A continuación, se discuten
- Pruebas de Regresión
- Pruebas Automatizadas
- Pruebas basadas en modelos
- Pruebas de Regresión
- A continuación, se discuten
- Asignación de Responsabilidades
- A continuación, se describen
- Pruebas de D
- A continuación, se describe
- Planificación de pruebas
- Se describe
- Describe la forma de gestionar las actividades de
prueba para minimizar los recursos necesarios.
- ¿Qué son?
Möchten Sie kostenlos Ihre eigenen Mindmaps mit GoConqr erstellen? Mehr erfahren.