Bibliografica

http://ing-sw.blogspot.com/2005/04/tipos-de-pruebas-
de-software.html
http://www.pmoinformatica.com/2016/08/pruebas-
aceptacion-software-istqb.html
https://www.guiadigital.gob.cl/articulo/pruebas-de-
interfaces-y-contenidos.html
https://www.ecured.cu/Pruebas_de_caja_blanca
https://www.ecured.cu/Niveles_de_prueba_de_software

https://es.slideshare.net/mrocio1/diseo-caso-de-
pruebas-48099189
http://www.pmoinformatica.com/2015/06/modelo-informe-
pruebas-software.html
https://blogreinadl.blogspot.com/2019/07/fundamentos-
del-proceso-de-pruebas.html
http://www.juntadeandalucia.es/servicios/madeja/conten
ido/recurso/396
https://ingsoftware2.wordpress.com/?
s=Conceptos+del+proceso+de+pruebas&submit=
https://www.monografias.com/docs113/ingenieria-
software-prueba-caja-blanca-y-camino-
basico/ingenieria-software-prueba-caja-blanca-y-
camino-basico.shtml
https://pruebasdelsoftware.wordpress.com/2013/01/07/pr
incipios-fundamentales-del-proceso-de-pruebas/
https://www.ecured.cu/Diagrama_de_despliegue#:~:text=1
0%20Fuentes-,Definici%C3%B3n,ejecuta%20cada%20uno%20de
%20ellos.
https://es.slideshare.net/joshell/diagramas-uml-
componentes-y-despliegue
http://elchrboy.blogspot.com/2010/03/diseno-al-nivel-
de-componentes.html
http://interfaces-de-usuario.blogspot.com/
https://medium.com/@eugeniacasabona/dise%C3%B1ando-
interfaces-intuitivas-mediante-patrones-de-dise
%C3%B1o-998d589b6af0
https://medium.com/@eugeniacasabona/dise%C3%B1ando-
interfaces-intuitivas-mediante-patrones-de-dise
%C3%B1o-998d589b6af0
http://interfaces-de-
usuario.blogspot.com/2012/06/modos-de-uso-navegacion-
tecnicas-de.html
: Diseño de Interfaz de usuario.
Podemos definir que el Diseño de Interfaces de Usuario
se basa en diseño de computadoras, aplicaciones,
máquinas, dispositivos de comunicación móvil,
aplicaciones de software y sitios web enfocado en la
experiencia de usuario y la interacción. Normalmente
es una actividad multidisciplinar que involucra a
varias ramas del diseño y el conocimiento como el
diseño gráfico, industrial, web, de software y la
ergonomía; y está implicado en un amplio rango de
proyectos, desde sistemas para computadoras, vehículos
hasta aviones comerciales
Principios de Usabilidad:
 Visibilidad del estado del sistema.
 Libertad y control del usuario.
 Correspondencia entre el sistema y el mundo real.
 Prevención de errores.
 Coherencia y estándares.
 Reconocer en lugar de recordar.
 Flexibilidad y eficiencia de uso.
 Diseño estético y minimalista.
 Ayuda y documentación.
 Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores.

Usabilidad y Accesibilidad
Usabilidad Es el grado en el cual un producto puede ser utilizado por usuarios específicos
para alcanzar metas específicas con eficiencia, eficacia, y satisfacción en un contexto
específico de uso, Se refiere a cuán bien los usuarios pueden aprender y usar un producto
para lograr sus metas y qué tan satisfechos se encuentran con el proceso.
La usabilidad mide la calidad de la experiencia del usuario cuando interactúa con un producto.

¿Cómo medir la usabilidad?

-Facilidad de aprendizaje Qué tan rápido un usuario que nunca haya visto la interface de la
aplicación anteriormente, aprende a utilizarla suficientemente bien para lograr las tareas
básicas. Eficiencia de uso  Una vez que un usuario experimentado haya aprendido a usar el
sistema, qué tan rápido puede lograr su meta
-Memorización Si un usuario ha utilizado el sistema anteriormente, ¿puede él recordar cómo
usar el sistema efectivamente pasado un tiempo o necesita empezar todo el proceso de
aprendizaje nuevamente?
 -Frecuencia de error y severidad Qué tan seguido los usuarios cometen errores mientras
utilizan el sistema, qué tan serio son estos errores, y qué acciones realizan los usuarios para
enmendar estos errores.
-Satisfacción subjetiva Qué tanto al usuario le gusta usar el sistema

CONCEPTOS DE USABILIDAD
¿Qué es? La accesibilidad es el grado en el que todas las personas pueden utilizar un objeto,
visitar un lugar o acceder a un servicio, independientemente de sus capacidades técnicas,
cognitivas o físicas. Conlleva a que se diseñe pensando en ellos.
Las circunstancias de cada usuario son distintas: el país en el que reside y el idioma que habla, sus
capacidades visuales, motrices, auditivas y cognitivas… Una Software accesible tiene en cuenta
estas circunstancias para poder brindar a la mayoría de usuarios un fácil acceso a las tecnologías.
Por tanto, la accesibilidad es algo esencial en todo tipo de Software y es un ejercicio de solidaridad
con todo tipo de perfiles de usuario que pueden llegar a consultarla, con la intención de no dejar a
nadie fuera por ser incapaz de usar un Software. Es un ámbito en el que todos debemos participar.

¿Qué herramientas existen? Braille, Sintetizador de voz, Lector de pantalla, Subtítulo,

Teclados adaptados y sustitutos de ratón, Temas con alto contraste, íconos grandes, Texto
predictivo, teclado en pantalla, Magnificador de pantalla

Aspectos del diseño de interfaz

1. Simpleza: La simplicidad de tu interfaz permite que el usuario pueda usarla de forma
fluida. Si bien añadir características y contenido adicionales a tu aplicación puede ser
tentador, debes preguntarte si realmente dicha función es necesaria para el usuario.
Asegúrate que cada una de esas funciones tenga un propósito específico y mejore la
experiencia de usuario.
2. Claridad: Para mejorar la claridad de tu interfaz debes colocar textos precisos a
botones. Nombrar apropiadamente los elementos del menú y cualquier otro contenido textual
que posea la interfaz. Los mensajes deben ser concisos. Tu usuario espera poder navegar
rápidamente la página. Si no eres conciso en tus mensajes, los usuarios no los leerán y
afectará de forma negativa la experiencia de usuario.
3. Coherencia: Algunos factores que permiten la coherencia en una interfaz es el
tratamiento de las imágenes, las fuentes, el lenguaje y tono de comunicación, el uso de los
colores, la ubicación del menú y el logo. 
4. Familiaridad: Para poder tener una interfaz que se sienta familiar debes emplear
iconos universales como el hamburger menu en aplicaciones móviles e incluso en interfaces
web de ser necesario. También debes mantener ciertos elementos en sitios específicos, por
ejemplo, el logo en un sitio web se suele colocar en la parte superior izquierda y se enlaza con
la página de inicio, a pesar que el botón de “Inicio” sea uno de los elementos del menú.
5. Rapidez: Todas las características mencionadas previamente permiten que el usuario
pueda navegar y aprender a controlar la interfaz más rápidamente. Si bien la claridad y la
simplicidad permiten que el usuario pueda “leer” la interfaz rápidamente, es importante que
esa velocidad también debe ser reflejada cada vez que el usuario realiza alguna acción. Es
decir, la respuesta que debe obtener debe ser prácticamente inmediata.

Modos de uso
  La finalidad principal de la interfaz grafica es el de
guiar a los usuarios de manera intuitiva a través del
sistema y facilitarle la interacción con el mismo. El
sistema se manejará por medio de interfaces así la
información necesaria podrá ser procesada de manera
eficiente y en corto tiempo el sistema tendrá la
respuesta a los requerimientos del usuario, manejando
además los errores en los que este pueda incurrir.

Navegación

Sistema de Navegación
Se denomina "sistema de navegación" al conjunto de elementos presente en cada una de las
pantallas, que permite a un usuario moverse por las diferentes secciones de una interfaz gráfica
sin sentir la sensación de haberse perdido en ese camino.

 Menú de secciones: es una zona de la interfaz en la que se detallan las secciones o

categorías en las que está dividida la información contenida en la interfaz gráfica.
Normalmente se ubica en la parte superior de cada página o bien en la zona superior
derecha o izquierda. Hasta la aparición de los últimos estudios basados en
"eyetracking" no había una recomendación certera acerca de su ubicación; tras éstos,
parece indicado ubicarlos en la zona superior o en la zona superior izquierda.
 Menú de rastros: es el menú que indica mediante los nombres de cada sección o
categoría del menú, la distancia que separa a la página actual de la portada. Por
ejemplo, si el usuario está revisando la página del "Programa A", el menú
correspondiente debe indicar Portada > Programas > "Programa A". Este menú debe
ir siempre debajo de la Identificación de la sección o categoría y sobre el título.
 Identificación de secciones: debe estar en la zona superior de la interfaz, de manera
cercana la zona donde se encuentra el logotipo que se haya elegido para identificar
al Software. Puede ser gráfico y por lo mismo tener alguna imagen alusiva a la
sección o categoría o bien ser una solución que incorpore sólo texto y color. Sí debe
tener en forma destacada el nombre de la sección o categoría y por lo mismo, debe
aparecer en todas las pantallas que pertenezcan a dicha ésta. En términos de
tamaño, su ancho debe ser el de la zona de contenido y su alto, no menor a 100
pixeles (aproximado) para una adecuada visualización.
 Botones de acción: son aquellos elementos que permiten realizar acciones directas
relativas a la navegación y que se muestran como parte de ésta.
Diseño visual
DISEÑO VISUAL.

El uso de tipografía, símbolos, color y otros gráficos

estáticos y dinámicos son comúnmente usados para expresar
hechos, conceptos y emociones. Esto compone un diseño
gráfico sistemático orientado a la información que ayuda a la
gente a comprender información compleja. La comunicación
visual efectiva para este sistema se basa en algunos
principios básicos de diseño gráfico. Existen tres factores que
pueden considerarse para el diseño de una interfaz de
usuario correcta: factores de desarrollo, factores de viabilidad
y factores de aceptación. Los factores de desarrollo ayudan a
mejorar la comunicación visual. Esto incluye toolkits y
librerías de componentes, soportes para un rápido
prototipado, y adaptabilidad.

COLOR.
Las discusiones sobre el color suelen ser confusas porque
científicos, artistas, diseñadores, programadores y
profesionales del marketing describen el color de diferentes
formas. Algunas de estas formas difieren del rojo, verde y
azul que basan el sistema de color “RGB”, familiar para los
usuarios de periféricos con tubos de rayos catódicos (CRTs).
Los siguientes términos aclaran conceptos sobre esta manera
de entender el color:
• Matiz (Hue) es la composición espectral de longitud de
onda que produce percepciones de ser azul, naranja, verde,
etc. por ejemplo.
• Valor (Value) es la cantidad relativa de claridad u
oscuridad del color en un rango desde el negro al blanco
(también llamado intensidad).
• Saturación (Chroma) es la pureza del color en una escala
desde el gris a la variante mas viva del color percibido.
• Brillo (Brightness) es la cantidad de energía luminosa al
crear el color.
La importancia del color es comunicar. Los códigos de
colores deben respetar el uso profesional y cultural ya
existente de determinados colores. Las connotaciones varían
fuertemente respecto a los diferentes tipos de usuario,
especialmente cuando son de diferentes culturas. Las
connotaciones del color deben ser usadas con sumo cuidado.

ICONOS
: Son pequeños gráficos hiperenlace que:
• De forma aislada
• Acompañados de un hipertexto
• Acompañados de una etiqueta
• Acompañados de un "tooltip"
Utilizar ideografías estándar para representar las acciones de navegación. Para acciones de navegación
específicas de nuestro sitio: es preferible no utilizar iconos, o, de usarlos, acompañarlos de una etiqueta. En la
mayoría de casos aumenta la usabilidad un simple hipertexto, o un botón generado sólo con texto y las clases
de estilo adecuadas para conferirle apariencia de botón. Los tamaños pueden ser variables, aunque se ha
demostrado la misma eficacia para los micros iconos y tienen un peso apreciablemente menor:
• 40 X 40 pixeles Peso < 1 KBytes.
• 20 X 20 pixeles Peso < 300 Bytes.
• 12 X 12 pixeles Peso < 100 Bytes.

TIEMPO DE RESPUESTA
El tiempo de respuesta del sistema es la primera queja sobre muchas
aplicaciones interactivas. En general, se mide desde el punto en que el usuario
realiza alguna acción de control. El tiempo de respuesta del sistema tiene dos
características importantes: duración y variabilidad.
- Duración: Si la respuesta del sistema se demora mucho, la frustración y el
estrés del usuario son inevitables.
- Variabilidad: es la desviación del tiempo de respuesta promedio. Una baja
variabilidad permite que el usuario establezca un ritmo de interacción, aunque
el tiempo de respuesta sea relativamente largo.
Una vez que se ha creado un prototipo de interfaz de usuario operacional,
debe evaluarse y determinar si satisface las necesidades del usuario.

RETROALIMENTACIÓN.
Proceso por el cual parte de la respuesta del receptor es comunicada al emisor.
- Proceso por el cual parte de la respuesta del emisor es comunicada al
receptor.
- Proceso donde ni el emisor ni el receptor saben la respuesta.

Localización e Internacionalización.
Localización
Se entiende por localización la adaptación de un producto, una aplicación o el contenido de un documento con
el fin de adecuarlos a las necesidades (lingüísticas, culturales u otras) de un mercado destinatario concreto
(una "localidad" o "local" [locale]).

La palabra localización a veces se escribe "l10n", donde 10 es la cantidad de letras entre la ele y la ene.

Aunque se la considera a menudo sinónimo de traducción de la interfaz de usuario y de la documentación, la

localización suele ser un asunto considerablemente más complejo, que puede implicar la adaptación del
contenido en relación con:

Formatos numéricos, de fecha y de hora;

Uso de símbolos de moneda;
Uso del teclado;
Algoritmos de comparación y ordenamiento;
Símbolos, iconos y colores;
Texto y gráficos que contengan referencias a objetos, acciones o ideas que, en una cultura dada, puedan ser
objeto de mala interpretación o considerados ofensivos;
Diferentes exigencias legales;
Y muchas otras cuestiones.
Internacionalización.
Existen diferentes definiciones para la palabra internacionalización. La que damos aquí es una definición
operativa de alto nivel para usar con los materiales de la Actividad de internacionalización del W3C. Algunas
personas utilizan otros términos para referirse al mismo concepto, por ejemplo, "globalización".

La internacionalización es el diseño y desarrollo de un producto, una aplicación o el contenido de un

documento de modo tal que permita una fácil localización con destino a audiencias de diferentes culturas,
regiones o idiomas.

La palabra internacionalización a veces se escribe "i18n", donde 18 es la cantidad de letras entre la i y la ene.

La internacionalización generalmente implica:

Un modo de diseño y desarrollo que elimine obstáculos a la localización o la distribución internacional. Esto
incluye cuestiones tales como (entre otras) usar Unicode o asegurar, allí donde corresponda, un correcto
tratamiento de las codificaciones de caracteres anticuadas; controlar la concatenación de cadenas; o evitar que
la programación dependa de valores de cadenas pertenecientes a la interfaz de usuario.
Habilitar características que tal vez no sean usadas hasta el momento de la localización. Por ejemplo, añadir
en la DTD etiquetas para habilitar el texto bidireccional o la identificación de idiomas. O hacer la CSS
compatible con texto vertical u otras características tipográficas ajenas al alfabeto latino.
Preparar el código para hacer frente a las preferencias locales, regionales, lingüísticas o culturales. Por lo
general, esto supone incorporar características y datos de localización predefinidos a partir de bibliotecas
existentes o de las preferencias del usuario. Algunos ejemplos son: formatos de fecha y hora, calendarios
locales, formatos y sistemas de números, ordenamiento y presentación de listas, uso de nombres personales y
formas de tratamiento, etc.
Separar del código o contenido fuente los elementos localizables, de modo que puedan cargarse o
seleccionarse alternativas localizadas según determinen las preferencias internacionales del usuario.

Modelos metafóricos y conceptuales.

Metáforas
Uso de metáforas en diseño de interfaz.
Aplicar metáforas en el diseño de interfaz de un producto ayuda al usuario a establecer unas expectativas
acerca de su utilidad y funcionamiento. Un ejemplo: el escritorio.
Metáforas.
El uso de metáforas adecuadas en el diseño de un interfaz, facilita y acelera el aprendizaje del funcionamiento
de un producto.
Similitudes con otros mecanismos y procesos conocidos por el usuario que aplica lo que ya conoce a los
elementos y relaciones dentro de un dominio no familiar como puede ser una aplicación web o multimedia. El
ejemplo más tradicional: el escritorio con sus iconos representando carpetas y documentos. Las metáforas
ayudan al usuario a entender más rápidamente cómo moverse por un producto interactivo.

Conceptuales
El modelo conceptual de un sistema software constituye una abstracción externa que describe mediante
diagramas y notaciones con distinto grado de formalidad el conocimiento que debe poseer una persona acerca
de un sistema, conocimiento que se encuentra almacenado en la Memoria a Largo Plazo.

Patrones de Diseño de Interfaz.

¿Qué son los patrones de diseño?
Como su nombre lo indica, son elementos o componentes que observamos
repetidamente en los productos digitales que utilizamos. Estos nos proveen de
soluciones recurrentes a problemas de diseño comunes. 
Como consumidores constantes de información, estamos acostumbrados a que
ciertos componentes visuales funcionen de una forma específica
¿Para qué sirven los patrones de diseño?
Si bien los patrones de diseño nacen del arquitecto Christopher Alexander para
ser introducidos posteriormente al desarrollo de softwares, estos se utilizan en
diferentes disciplinas. Su esencia recae en que un patrón es una solución a un
problema recurrente de diseño.
Estándares de Interfaz.

Los siguientes principios son fundamentales para el diseño e implementación de interfaces gráficas efectivas,
ya sea interfaces GUI de escritorios o para la web.
Las interfaces gráficas efectivas son visualmente comprensibles y permiten errores por parte del usuario,
dándole una sensación de control. Los usuarios ven rápidamente el alcance de las opciones y comprenden
como obtener sus metas y realizar su trabajo.

- Anticiparse.
Una buena aplicación intentará anticiparse a las necesidades y deseos de los usuarios. No esperes que el
usuario busque o recuerde información o herramientas. Muestra al usuario toda la información y herramientas
necesarias para cada etapa en su trabajo.
- Autonomía.
El ordenador, la interfaz y el entorno de la tarea pertenecen al usuario, pero no podemos abandonarlo.
Ante una interface, al usuario hay que darle “cuerda” para que investigue y sienta que tiene el control del
sistema. No obstante, hay que tener en cuenta que los adultos nos sentimos más cómodos en un entorno que
no sea ni muy restrictivo, ni demasiado grande, un entorno explorable pero no peligroso.
Mantén informado al usuario del estado del sistema.
- Mantén la información de estado fácilmente visible y actualizado.
Los usuarios no tienen que buscar la información de estado. De un vistazo deberían ser capaces de hacerse
una idea aproximada del estado del sistema. La información de estado pude ser bastante sutil: el icono de la
bandeja de entrada puede mostrarse vacía, media llena o hasta los topes, por ejemplo. Sin embargo, no es
conveniente abusar
- Daltonismo.
Si utilizas el color para transmitir información debes utilizar otros elementos complementarios para la gente
con daltonismo.
Aproximadamente un 10% de los hombres adultos sufren daltonismo.
Las pistas secundarias pueden consistir en distintos tonos de gris, gráficos complementarios o etiquetas de
texto.
- Valores por defecto.
Los valores por defecto deberían ser poder descartados con facilidad y rapidez. Los campos de texto con
valores por defecto deben aparecer seleccionados, para que el usuario sólo tenga que teclear y no seleccionar
todo, borrar y escribir.
-Los valores por defecto deben tener sentido.
No uses la palabra "por defecto" en una aplicación o servicio. Utiliza "estándar", "Usar valores habituales",
"Restablecer valores iniciales" o términos más específicos que describan lo que sucederá.

Diseño de Componentes.

El diseño en el nivel de componentes tiene lugar una vez terminado el diseño de la arquitectura. En esta etapa
se ha establecido la estructura general de los datos y del programa del software. El objetivo es traducir el
modelo del diseño a software operativo.

El diseño de datos a nivel de componentes se centra en la representación de estructuras de datos a las que
se accede directamente a través de uno o más componentes del software.

El diseño en el nivel de componente transforma los elementos estructurales de la arquitectura del software en
una descripción de sus componentes en cuanto a procedimiento. La información obtenida a partir de los
modelos basados en clase, flujo y comportamiento sirve como la base para diseñar los componentes.

Principios del diseño de componentes.

Un principio se puede entender como una guía de
comportamiento amplia aplicable a muchas situaciones.
En general un principio no te dice que hacer exactamente,
sino que te da pistas de cuál es la acción correcta a través
de una gran cantidad de situaciones, pero los detalles están
a cargo de ti mismo.
Hablando de principios de diseño de software, puedes
pensar en ellos como en un faro que te guía a través de la
oscuridad de los requerimientos del problema, A diferencia
de los patrones de diseño, no establecen los pasos
necesarios para aplicarlos, ni siquiera la situaciones en las
que son aplicables, de hecho, se pueden crear varios
patrones y reglas basándonos en ellos.
Algunos principios de Diseño de Software
Don’t Repeat Yourself (No te repitas)
Este principio (conocido como DRY) se explica por sí mismo: debes evitar al máximo grado posible la
repetición de código. Partiendo de este principio se han creado un montón de maneras de reutilizar lo que ya
hemos programado, piénsalo un poco: funciones, módulos, bibliotecas, clases, prototipos, herencia,
composición, macros, saltos (goto).

Estas son sólo algunas maneras de evitar la repetición, claro, cada una de las estrategias anteriores lo logra a
su manera y añade otras ventajas y desventajas.
KISS
Este principio establece que el código, el diseño, la documentación, todo lo relacionado con el software, debe
ser tan simple como sea posible.

Los programadores tendemos a complicar las cosas. Nos piden un formulario sencillo y queremos hacer un
generador de formularios que soporte este y todos los formularios en el futuro. No tenemos ni 100 usuarios y
ya queremos usar Kubernetes. Necesitamos un simple binding de datos y queremos meter Angular 7, Ionic 3 y
250 bibliotecas más.

Este principio establece que:

- Nuestro software en general debería tener tan pocos componentes (y por lo tanto líneas) como sea
posible.
- No deberíamos tener funcionalidades que no se ocupen actualmente “por si en el futuro se ocupan”.
- La documentación debe tener la información estrictamente necesaria.
- El código debe ser lo más obvio y sencillo posible. Se deben evitar esas líneas que sólo sirven para
presumir lo inteligente que eres.
- El diseño debe mantener la estructura simple, siempre que se pueda.

Principios SOLID

Si te dedicas a programar, llegado cierto punto vas a encontrar estos principios mencionados lo suficiente
como para que tengas que aprender qué significan.

SOLID es un acrónimo que engloba el nombre de 5 principios, originalmente dirigidos a la programación

orientada a objetos, pero que son aplicables a muchas otras cosas.

Los 5 principios son:

- Single Responsibility (Responsabilidad Única). Una entidad de software debería tener una sola
responsabilidad, esto también se puede interpretar como “tener una y sólo una razón para cambiar”.
En pocas palabras, tu componente/función/clase debería hacer muy bien una sola cosa.
 - Open/Closed (Abierto/Cerrado). Una entidad de software (este principio está dirigido a las clases),
debería estar abierto a extensión (crecer sus funcionalidades con otras entidades externas) pero
cerrado a modificación.

- Liskov Substitution (Sustitución de Liskov). El principio de sustitución de Liskov habla de interfaces: si

una entidad de software usa una clase, este debe ser capaz de usar clases derivadas de esta. Esto
es muy parecido a la programación por contrato, en el que se establecen las interfaces antes de la
implementación.

- Interface Segregation (Segregación de interfaces). Los clientes (las entidades de software) que usan
una entidad de software (una clase, originalmente), no deberían estar obligados a depender de
métodos que no usan. Para resolver esto, interfaces de gran tamaño se deben segregar, es decir,
romper, en otras más pequeñas.

- Dependency Inversion. El principio de Inversión de Dependencias establece que los módulos de alto
nivel, es decir, los más cercanos a las ideas humanas de lo que debe hacer el software, no deben
depender de los de bajo nivel (los más cercanos a la implementación de los detalles para la
computadora). Ambos deberían depender de las abstracciones del problema (interfaces). Además los
detalles de implementación deben depender de las abstracciones también. Se llama así porque en
general la gente lo piensa al revés.

Diagrama de Componentes
 Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones
§ Muestran las opciones de realización incluyendo código fuente, binario y ejecutable
Ingeniería del Software 

 Los componentes representan todos los tipos de elementos software que entran en la
fabricación de aplicaciones informáticas

Pueden ser simples archivos, paquetes, bibliotecas cargadas dinámicamente

Diagramas de despliegue 
Los diagramas de despliegue son los complementos de los diagramas de
componentes que, unidos, proveen la vista de implementación del sistema. Describen
la topología del sistema la estructura de los elementos de hardware y el software que
ejecuta cada uno de ellos.Los diagramas de despliegue representan a los nodos y sus
relaciones. Los nodos son conectados por asociaciones de comunicación tales como
enlaces de red, conexiones TCP/IP.

Los diagramas de despliegue muestran la configuración en funcionamiento del

sistema incluyendo su software y su hardware. Para cada componente de un
diagrama es necesario que se deba documentar las características técnicas
requeridas, el tráfico de la red, el tiempo de respuesta.
Integración de componentes
El término "integración" hace referencia a una actividad de desarrollo de software que combina
componentes de software diferentes en un conjunto. La integración se realiza en varios niveles y
fases de la implementación.

 La integración del trabajo de un equipo que trabaja en el mismo subsistema de

implementación antes de liberar el subsistema para los integradores del sistema.
 La integración de subsistemas en un sistema completo.

La propuesta de integración de Rational Unified Process consiste en integrar el software en

incrementos. En la integración incremental, el código se escribe y se prueba en partes pequeñas
que, a continuación, se añaden a un conjunto de trabajo de una en una.

La propuesta contraria a la integración incremental es la integración por fases. La integración por

fases se basa en la integración de varios componentes (nuevos y cambiados) a la vez. El principal
inconveniente de la integración por fases es que introduce muchas variables y dificulta la
localización de errores. Esto se debe, principalmente, al hecho de que un error podría estar en
cualquiera de los componentes nuevos, en la interacción entre los componentes nuevos en el
centro del sistema o en la interacción entre los componentes nuevos.

Las ventajas de la integración incremental son:

 Los errores son fáciles de localizar. Cuando se produce un problema nuevo durante la

integración incremental, el componente nuevo o cambiado, o su interacción con los
componentes integrados anteriormente, son los lugares obvios para buscar un error. La
integración incremental hace más probable que los defectos se descubran de uno en uno, lo
que facilita la identificación de errores.
 Los componentes se prueban de forma más completa. Los componentes se integran a
medida que se desarrollan y, después, se prueban. Esto significa que los componentes se
ejercitan más a menudo que si la integración se realiza en un solo paso.
 La ejecución se produce antes. Los desarrolladores ven los primeros resultados del
trabajo y no tienen que esperar hasta el final, lo que es mejor para su moral. Esto también
hace posible obtener información de retorno antes.

Es importante comprender que la integración se produce, como mínimo, una vez en todas las
iteraciones. Un plan de iteración define qué deben utilizar los guiones de uso para el diseño y qué
clases se deben implementar. Lo principal de la estrategia de integración es determinar el orden de
implementación y combinación de las clases.

Fundamentos del Proceso de Pruebas.

¿Qué son las pruebas de software?
Es un proceso en el que se revisa el sistema a probar (el SUT) bajo condiciones definidas explícitamente, y se
le aplica (eventualmente con apoyo de software especializado de tipo CAST) un conjunto de estímulos (los
casos de prueba) diseñados de manera sistemática utilizando técnicas apropiadas, con el objetivo de detectar
niveles inadecuados de calidad. Este proceso debe llevarse a cabo disciplinadamente, y respaldarse en
métricas bien definidas. Todas estas actividades y sus resultados son documentados, en especial las fallas
detectadas
Conceptos del proceso de pruebas
 Defectos.
un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de
procesamiento incorrectos en un programa.
 Fallas.
La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas
dentro de los requisitos de rendimiento especificados.
 Error.
Error Una acción humana que conduce a un resultado incorrecto.
 Datos de prueba.
Es una lista de variables o posibles valores usados en el caso de prueba.
 Verificación.
El proceso de evaluación de un sistema o de uno de sus componentes para determinar
Si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase.
 Validación.
El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de
desarrollo para determinar si satisface los requisitos marcados por el usuario.

Principios de proceso de pruebas.

Las pruebas exhaustivas no son viables:  para proyectos cuyo  número de casos de
uso o historias de usuario desarrolladas sea considerable, se requeriría de una inversión muy
alta en cuanto a tiempo y recursos necesarios para cubrir pruebas sobre todas las
funcionalidades del sistema; por esta razón, es conveniente realizar un análisis de riesgos de
todas las funcionalidades del aplicativo y determinar en este punto cuales serán objeto de
prueba y cuales no. Naturalmente,  ninguna funcionalidad que haga parte del ciclo de negocio
del aplicativo debe quedar por fuera de esta revisión. 

El proceso no puede demostrar la ausencia de defectos: independientemente de la

rigurosidad con la que se haya planeado el proceso de pruebas de un producto, nunca será
posible garantizar al ejecutar este proceso, la ausencia total de defectos de un producto en su
paso a producción,  debido entre otras cosas, al principio no. 1, en el cual no se permite escribir
y ejecutar  casos de prueba de manera exhaustiva. Por lo anterior, un proceso de pruebas

Inicio temprano de pruebas: es típico ver como algunas firmas de desarrollo, ven el proceso

de pruebas como una serie de actividades que se dan de manera aislada y solo hasta el
momento en el que se tiene una reléase de pruebas del producto, el equipo de pruebas se
incorpora a ejecutar las respectivas actividades; aunque sea válido, lo recomendable es que las
actividades de pruebas se ejecuten de manera paralela con cada una de las etapas del proceso.
Planeado, puede garantizar una reducción significativa de los posibles fallos y/o defectos del
software, pero nunca podrá garantizar que el software no fallará en su ambiente de producción.
Las pruebas no garantizan la calidad del Software: si bien las pruebas del Software
ayudan a mejorar la calidad de un producto, esto no es totalmente garantizable,  si estas
actividades no son incorporadas desde  etapas tempranas del proyecto. Este nivel de calidad no
será garantizado, entre otros aspectos, porque existe la posibilidad de  que algunas
funcionalidades del software  pueden no suplir las necesidades  y expectativas  de los usuarios
finales a los cuales va dirigido el desarrollo, así el comportamiento del software sea correcto y
responda fielmente a lo que fue especificado.

Ejecución de pruebas bajo diferentes condiciones: en un plan de pruebas,  siempre existe

un apartado relacionado con la estrategia a utilizar por parte del equipo de pruebas, en este
item, se define entre otros aspectos, el número de ciclos de prueba que se ejecutarán sobre las
funcionalidades del negocio.

Las pruebas y el proceso de desarrollo de software}

Pruebas de software
son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e
independiente sobre la calidad del producto a la parte interesada. Es una actividad más en el proceso de
control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del
tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de
desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno
corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Pruebas estáticas
Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se
pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.

Pruebas dinámicas
Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.

Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a
la naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el comportamiento de
la aplicación desarrollada.

el proceso de desarrollo de software

 Planificación: es el paso previo al inicio de cualquier proyecto de desarrollo y sin dudas

el más importante. En este se definen los requerimientos y funcionalidades que debe
tener el software, mediante el trabajo en conjunto entre los desarrolladores, el
departamento de ventas, los estudios de mercado y, fundamentalmente, el contacto
con el cliente. En este punto se realizan asimismo los análisis de riesgo para el
emprendimiento y se fijan los requisitos de aseguramiento de la calidad.
  La implementación es parte del proceso en el que los ingenieros de software programan el código
para el proyecto de trabajo que está en relación de las demanda del software, en esta etapa se realizan
las pruebas de caja blanca y caja negra.

 Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del
proceso tiene la función de detectar los errores de software lo antes posible.

 La documentación del diseño interno del software con el objetivo de facilitar su mejora y su
mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un API,
tanto interior como exterior. Prácticamente es como una receta de cocina

 El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su
liberación y ha sido distribuido en el entorno de producción.

 Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores
de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta
inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del
software.

 El mantenimiento o mejora de un software con problemas recientemente desplegado, puede requerir

más tiempo que el desarrollo inicial del software. Es posible que haya que incorporar código que no
se ajusta al diseño original con el objetivo de solucionar un problema o ampliar la funcionalidad para
un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno rediseñar el
sistema para poder contener los costes de mantenimiento.

Proceso de pruebas
Objetivos de prueba.
La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre
sus objetivos están:
1. Detectar defectos en el software.
2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al
cliente.
5. Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes clases de errores,
haciéndolo con la menor cantidad de tiempo y esfuerzo.
Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los principios básicos que guían
las pruebas del software.
Diseño de casos de prueba
El diseño de casos de prueba, tiene un único objetivo: tener la mayor probabilidad de encontrar el mayor
número de errores con la mínima cantidad de esfuerzo y tiempo posible.

Cualquier producto software puede aprobarse de una las siguientes formas:

1. Conociendo la función para la que fue diseñado el producto.

 Se pueden utilizar pruebas para: comprobar su función operativa y buscar errores de cada función.

2. Conociendo el funcionamiento del producto.

 Se pueden utilizar pruebas para: comprobar que las operaciones esta de acuerdo con las especificaciones y
para comprobar que los componentes internos funcionan de forma adecuada.
Análisis de resultado
El análisis de resultados es la parte del informe en la que estableces las conclusiones del mismo. Debe ser
claro y conciso, ya que el lector suele llegar cansado a esta parte del ensayo. Este análisis debe proponer
cuestiones sobre el tema estudiado y plantear nuevas corrientes y perspectivas para futuras investigaciones.
Desde un Como.com marcaremos una línea de abordaje y te explicaremos cómo hacer un análisis de
resultados.

Pasos a seguir:
1- Empezar con las relaciones y generalizaciones que los propios resultados guardan con informe.
Evidentemente, los resultados salen del desarrollo del informe, por lo que deberás mostrar esas relaciones en
el análisis de resultados.
2- Señalar los aspectos no resueltos y no tratar de ocultarlos. Delimita lo que no cuadre. En algunos ensayos
puede haber algún resultado que no encaje o cuadre con el desarrollo de la investigación. Debes señalarlo y
dejar abierto el tema.
3- Mostrar las relaciones de tus resultados con trabajos anteriormente publicados, y también mostrar las
nuevas conclusiones propias de tu ensayo.
4- Explicar cuáles son las bases teóricas de la investigación y las posibles aplicaciones prácticas que pueda
tener. De donde salen tus conclusiones y para que sirven.
5- Formular detalladamente y de forma clara las conclusiones.
6- Dar recomendaciones o sugerencias si es necesario, para facilitar la compresión del informe.
7- Por último, resumir las pruebas que recogen esa información así como las fuentes.

Ambiente de desarrollo
Este es el lugar donde realizamos todos los cambios locos que se nos ocurran, nuevas ideas, o
ajustes del cliente. Nada de lo que se realice acá afectará realmente la aplicación de software. En
este ambiente se suelen hacer cambios directos a la base de datos como agregar o quitar
columnas, relación entre tablas y datos, nuevas tablas, cambiar los modelos de la base de datos
entre otros. La información que se trabaja acá siempre va a terminar siendo muy incoherente con la
realidad. Incluso en los ambientes de trabajo para software se recomienda que los datos de
usuarios y personas sean modificados para su tratamiento de los ingenieros.

Técnicas de pruebas.
Niveles de Pruebas
Prueba de unidad
La prueba de unidad es la primera fase de las pruebas dinámicas y se realizan sobre
cada módulo del software de manera independiente. El objetivo es comprobar que el
módulo, entendido como una unidad funcional, está correctamente codificado, Se
enfocan en un programa o un componente que desempeña una función específica
que puede ser probada y que se asegura que funcione tal y como lo define la
especificación del programa.

Consiste en una prueba estructural enfocada a los elementos más pequeños del
software. Esta prueba es aplicable a componentes representados en el modelo de
implementación, para verificar que los flujos de control y de datos estén cubiertos y
que ellos funcionen como se espera.
Durante la prueba de unidad, la comprobación selectiva de los caminos de ejecución
es una tarea esencial. Se deben diseñar casos de prueba para detectar errores
debidos a cálculos incorrectos, comparaciones incorrectas o flujos de control
inapropiados. Las pruebas del camino básico y de bucles son técnicas muy efectivas
para descubrir una gran cantidad de errores en los caminos.

Pruebas de Integración.
Su objetivo es identificar errores introducidos por la combinación de programas o
componentes probados unitariamente, para asegurar que la comunicación, enlaces y
los datos compartidos ocurran apropiadamente. 

En este nivel se asegura que las interfaces y ligas entre las partes del sistema
trabajen apropiadamente. Antes de las pruebas de integración, los componentes
tuvieron que haber pasado sus pruebas individuales, por lo que el enfoque ahora es
sobre el flujo de control entre los módulos, y sobre los datos que son intercambiados
entre ellos de manera independiente.

Prueba de sistema
Esta prueba tiene como objetivo verificar que se han integrado adecuadamente todos
los elementos del sistema y que realizan las operaciones apropiadas funcionando
como un todo. Es similar a la prueba de integración pero con un alcance mucho más
amplio.

Es en esta prueba donde se buscan los defectos globales dados por la mala
integración de los módulos y que impiden una buena aceptación en la decisión del
cliente. La responsabilidad es de todos los creadores de cada uno de los elementos
del sistema.

Tipos de pruebas
Prueba de Caja Blanca

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la

estructura de control del diseño procedimental para derivarlos. Mediante la prueba de
la caja blanca el ingeniero del software puede obtener casos de prueba que:

1. Garanticen que se ejerciten por lo menos una vez todos los caminos
independientes de cada módulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.

Pruebas de Caja Negra

Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten

completamente todos los requisitos funcionales de un programa. En ellas se ignora la
estructura de control, concentrándose en los requisitos funcionales del sistema y
ejercitándolos.

La prueba de Caja Negra no es una alternativa a las técnicas de prueba de la Caja

Blanca, sino un enfoque complementario que intenta descubrir diferentes tipos de
errores a los encontrados en los métodos de la Caja Blanca. Muchos autores
consideran que estas pruebas permiten encontrar:

Pruebas funcionales.
Una prueba no funcional es una prueba cuyo objetivo es la verificación de un requisito que especifica criterios
que pueden usarse para juzgar la operación de un sistema (requisitos no funcionales) como por ejemplo la
disponibilidad, accesibilidad, usabilidad, mantenibilidad, seguridad, rendimiento.

Las pruebas no funcionales de software nos permiten conocer qué riesgos corre el producto y nos dicen si
tiene un mal desempeño o un bajo rendimiento en los entornos de producción.

En ese sentido, las pruebas no funcionales de software se hacen con el fin de obtener información. Permiten
explicar lo que soporta el producto y si cumple con las expectativas de los clientes.

Pruebas de Interfaz.
Pruebas de interfaz son pruebas de integración que se ocupan de probar las interfaces entre componentes o
sistemas.

Pruebas de Aceptación.
En la Ingeniería del software, las pruebas de aceptación se realizan para establecer el grado de confianza en
un sistema, partes del mismo o en sus características no funcionales.

La confianza en el sistema estará determinada por su grado de adherencia a las necesidades, requerimientos y
procesos de negocio solicitados por el usuario o cliente. Es en función a estos que el usuario debe decidir si
acepta o no el sistema que le está siendo entregado.

Por lo tanto, las pruebas de aceptación suelen ser responsabilidad de los clientes o usuarios del sistema. Otros
interesados del proyecto pueden involucrarse también.

Instrumentos y herramientas para pruebas

Instrumentos y herramientas para Pruebas Herramientas para pruebas de software disponibles, en el mercado
como de manera gratuita (herramientas de código abierto), es muy amplio. Se encuentran divididas en
categorías Herramientas de gestión de pruebas Herramientas para pruebas funcionales Herramientas para
pruebas de carga y rendimiento