Está en la página 1de 12

Instituto Tecnológico Superior de

Acayucan

ITSA

(Extensión Jáltipan)

Alumno: Angel Teodoro Guzmán García

Docente: MTI. Feliciano Sánchez Mendoza

Asignatura: Verificación y validación de


software.

Grupo: 803-C

Carrera: Sistemas Computacionales

ÍNDICE
Introducción.............................................................................................................................2

1
5.1 Implementación.................................................................................................................2
5.2 Entradas para pruebas....................................................................................................4
5.3 Plan de pruebas (estrategia de prueba, ambientes, test team, atacar y
asegurar regresión)................................................................................................................5
5.4 Ejecución de tipos generales de pruebas..................................................................7
5.5 Caja negra y caja blanca.................................................................................................8
5.6 Otros tipos de test............................................................................................................8
5.7 GUI's y Zooming user interface.....................................................................................8
5.7.1 Documentación (técnica y de usuario)................................................................9
5.7.2 Seguridad..................................................................................................................11
5.7.3 Diseño de las pruebas............................................................................................12

Introducción
La implementación está basada en una filosofía de diseño que tiene por
objetivo la creación de productos que resuelvan necesidades concretas de sus
usuarios finales, consiguiendo la mayor satisfacción y mejor experiencia de uso
posible con el mínimo esfuerzo de su parte.
Haciendo uso de la facilidad con que las personas pueden utilizar una
herramienta particular o cualquier otro objeto fabricado por humanos con el fin
de alcanzar un objetivo concreto. La usabilidad también puede referirse al
estudio de los principios que hay tras la eficacia percibida de un objeto.
Analizando el proceso de verificación y validación del software, y aplicando
métricas para la evaluación de los resultados finales.

5.1 Implementación.
Plan de implementación.
Después del diseño detallado del proyecto, el paso siguiente es elaborar un
plan de implementación del mismo.
Idealmente, el plan de implementación debe incorporar todos los aspectos de la
implementación del proyecto, incluyendo las estrategias descritas para lograr
sus resultados.
El proceso de elaboración de un plan de implementación de un proyecto es
esencialmente el mismo que el de un proyecto de desarrollo.
Fases que se utilizan en la Implantación de software de aplicación:
 Fase 1: Preparar un ambiente operacional y uno de prueba separados.
 Fase 2: Ofrecer capacitación a los usuarios, administradores y técnicos.
 Fase 3: Realizar la conversión de datos y el cambio de sistema.
 Fase 4: Efectuar una evaluación luego de la instalación del sistema.
 Fase 5: Presentar un reporte final a la administración.

2
Fase 1: Preparar un ambiente operacional y uno de prueba separados.
Se puede entender por ambiente o plataforma la combinación específica de
hardware y software que permite correr un sistema, por ambiente operacional,
la plataforma donde corre el sistema actual y por ambiente de test o de prueba,
la plataforma utilizada para desarrollar y dar mantenimiento a los sistemas.
El tener el ambiente operacional y el de prueba separados permite proteger el
sistema y evitar problemas que pudieran dañar los datos o interrumpir las
operaciones durante las tareas de prueba.
 La plataforma operacional del sistema de información incluye las
configuraciones de hardware y software apropiadas, utilidades del
sistema, recursos de telecomunicaciones y otros componentes. A esta
plataforma operacional sólo tienen acceso los usuarios bajo un control
estricto. Los analistas de sistemas y programadores no tienen acceso.
 El ambiente de test reduciendo probablemente a una estación de trabajo
o a un servidor, contiene copias de todos los programas y
procedimientos, así como de los archivos de datos de prueba.
Fase 2: Ofrecer capacitación a los usuarios, administradores y técnicos.
A los usuarios debe ofrecérseles una visión general del sistema y los términos
o palabras clave; los procedimientos de inicio y apagado del sistema; el menú
principal y los submenús; las funciones principales del sistema; una guía para
sacar adelante los problemas que se presenten y una lista de preguntas
frecuentes.
A los administradores, entre otros debe capacitárseles en la obtención de los
objetivos del negocio, los principales reportes que ofrece el sistema y como
requerir mejoras al mismo.
Al equipo de TI se le debe entrenar en la arquitectura del sistema y su
documentación, la resolución de problemas y en el entrenamiento de los
usuarios y del personal administrativo.
Fase 3: Realizar la conversión de datos y el cambio de sistema.
Es una parte importante de la implantación o instalación del sistema y que
consiste en cargar en el nuevo sistema los datos existentes. Dependiendo del
sistema puede hacerse antes, durante o después de completar el ambiente
operacional.
El proceso de cambio del sistema consiste en poner en línea el nuevo sistema
y en retirar el anterior. Puede realizarse de forma directa en paralelo, mediante
un piloteo o por etapas intercaladas dependiendo del riesgo implícito y del
tiempo disponible para realizar la tarea.
Fase 4: Efectuar una evaluación luego de la instalación del sistema.
Una vez instalado el sistema, debe permitir observar la calidad del nuevo
sistema de información de forma integral.

3
Se pone énfasis en determinar si el sistema efectivamente cumple ciertos
requisitos, permite lograr los objetivos de los usuarios y produce los beneficios
para los cuales fue aprobado.
Fase 5: Presentar un reporte final a la administración.
Se realiza un reporte final que debe incluir las versiones definitivas de toda la
documentación del sistema, las modificaciones o mejoras a realizar a futuro
que fueron detectadas, la recapitulación de los presupuestos y cronogramas
utilizados durante la instalación y los resultados de los test correspondientes a
la evaluación final.

5.2 Entradas para pruebas.

Condiciones de entrada.
Las condiciones de entrada vienen representadas por sentencias en la
especificación.
Un valor específico “… Introducir cinco valores…”
Un rango de valores “… Valores entre 0 y 10…”
Un conjunto de valores relacionados “… Palabras reservadas en un
lenguaje...”
Una condición lógica Condición “… debe ser…”

Clase de equivalencia.
Un conjunto de datos de entrada que definen estados válidos y no válidos del
sistema.
 Clase válida: genera un valor esperado
 Clase no válida: genera un valor inesperado
Se obtienen a partir de las condiciones de entrada descritas en las
especificaciones.
 Cada caso debe contemplar el máximo número de clases de
equivalencia válidas.
 Generar suficientes casos para cubrir todas las clases.
 Generar un caso de prueba por cada clase de equivalencia no válida
que haya sido identificada.
Entradas para las pruebas.
Representativas (datos comunes).
Incorrectas, incompletas e incongruentes.
Criterios de identificación de las clases de equivalencia.

4
5.3 Plan de pruebas (estrategia de prueba, ambientes, test
team, atacar y asegurar regresión).

Estrategias de prueba del software


 Proporcionan un plano o guía para el desarrollador del software, para la
organización de control de calidad y para el cliente.
 Es una guía que describe los pasos a llevar a cabo como parte de la
prueba, cuándo se deben planificar y realizar esos pasos, y cuánto
esfuerzo, tiempo y recursos que se van a requerir.
Por lo tanto, cualquier estrategia de prueba debe incorporar la planificación de
la prueba, el diseño de los casos de prueba, la ejecución de las pruebas y la
agrupación y evaluación de los datos resultantes.
Objetivos:
 Establecer la participación de los roles implicados.
 Definir el alcance, momento y características de las diferentes pruebas a
realizar.
 Definir los contenidos de los manuales de usuario y de administración.
 Establecer los requisitos necesarios para la aceptación del producto
antes de su promoción a la siguiente fase del ciclo de vida de desarrollo.
 Definir el ciclo de vida de gestión de un caso de prueba.
 Presentar técnicas y estrategias aplicables en la elaboración y ejecución
de las pruebas del software.
Enfoque estratégico para la prueba del software.
Generalmente se proporciona una plantilla para la prueba con las siguientes
características generales:

5
 La prueba comienza en el nivel de módulo y trabaja "hacia fuera", hacia
la integración de todo el sistema basado en computadora. Se usa el
enfoque “bottom-up”.
 En diferentes momentos se utilizarán diferentes técnicas de prueba.
 La prueba la lleva a cabo el que desarrolla el software y (para grandes
proyectos) un grupo de prueba independiente.
 La prueba y la depuración son actividades diferentes, pero la depuración
se puede incluir en cualquier estrategia de prueba.
Plan de pruebas.
Es un documento que tiene como objetivo señalar el enfoque, los recursos y el
esquema de actividades de prueba, así como los elementos a probar, las
características, las actividades de prueba, el personal responsable y los riesgos
asociados.
A continuación se presenta el contenido básico de un plan de pruebas:
 Identificar el documento
 Introducción y resumen de elementos y características a probar
 Elementos de software que se van a probar
 Características que se van a probar
 Características que no se prueban
 Enfoque general de la prueba (Actividades, técnicas, herramientas, etc.)
 Criterios de aprobación para cada elemento probado.
 Criterios para suspender y requisitos para reanudar actividad.
 Documentos a entregar
 Actividades de preparación y ejecución de pruebas
 Necesidades de entorno
 Responsabilidades en la organización y realización de las pruebas
 Necesidades de personal y de formación
 Cronograma de tiempos y actividades
 Riesgos asumidos por el plan
 Aprobaciones y firmas con nombre y puesto desempeñado.
Etapas de un plan de pruebas
a) Especificar los objetivos de las pruebas.
b) Determinar con precisión los criterios a seguir en su realización.
c) Integrar al personal y los elementos necesarios para el desarrollo de
las pruebas.
d) Aplicación de la prueba o pruebas según los criterios seleccionados.
e) Evaluación de los resultados y consideraciones para llevar a cabo
una nueva serie de pruebas.
Aspectos a tener en cuenta en la aplicación de una prueba.
 Operatividad. Cuanto mejor funcione el software, más eficientemente se
puede probar. Ningún error debe bloquear la ejecución de las pruebas.

6
 Observabilidad. Lo que ves es lo que pruebas. Un resultado incorrecto
se identifica fácilmente.
 Controlabilidad. Cuánto mejor podamos controlar el software más se
puede automatizar y optimizar. Las pruebas pueden especificarse,
automatizarse y reproducirse convenientemente.
 Capacidad de descomposición. Controlando el ámbito de las pruebas
podemos aislar más rápidamente los problemas y llevar a cabo mejores
pruebas de regresión. Los módulos de software se pueden probar
independientemente.
 Simplicidad. Cuanto menos haya que probar más rápidamente podemos
probarlo.
 Estabilidad. Cuánto menos cambios haya, menos interrupciones a las
pruebas.
 Facilidad de comprensión. Cuanta más información tengamos, mejores
serán las pruebas.
Sistema de pruebas
Los cuatro componentes principales de un sistema de pruebas son:
1. Equipo de pruebas: los ingenieros de pruebas, técnicos de pruebas y el
responsable de las pruebas, los cuales tienen habilidades, experiencia y
trabajan para diseñar, implementar, y usar componentes de pruebas.
2. Recursos de prueba: casos de prueba, datos de prueba, herramientas
de pruebas, y otro material de desarrollo.
3. Procesos de prueba: condiciones informales, formales, no
documentadas y documentadas en las que se realiza el trabajo de
pruebas.
4. Entorno de pruebas: hardware, software, infraestructura de redes, oficina
y laboratorio, y otros elementos que formen el lugar de trabajo.

5.4 Ejecución de tipos generales de pruebas.

La ejecución de pruebas debe iniciar con la creación de los datos de prueba


necesarios para ejecutar los casos de prueba diseñados.
La ejecución de estos casos, puede realizarse de manera manual o
automatizada; en cualquiera de los casos, cuando se detecte un fallo en el
sistema, este debe ser documentado y registrado en una herramienta que
permita gestionar los defectos (Bug Tracker).
Una vez el defecto ha sido corregido por la firma desarrolladora en su
respectivo proceso de depuración, es necesario realizar un re-test que permita
confirmar que el defecto fue solucionado de manera exitosa. Por último, es
indispensable ejecutar un ciclo de regresión que nos permita garantizar, que los
defectos corregidos en el proceso de depuración de la firma, no hayan
desencadenado otros tipos de defectos en el sistema.

7
5.5 Caja negra y caja blanca.

Caja blanca: Tipos de pruebas de software que se realiza sobre las funciones
internas de un módulo.
Caja negra: Así como las pruebas de caja negra ejercitan los requisitos
funcionales desde el exterior del módulo, las de caja blanca están dirigidas a
las funciones internas.
De una caja negra interesa su forma de interactuar con el medio que le rodea
(en ocasiones, otros elementos que también podrían ser cajas negras)
entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace.
Una caja negra debe estar muy bien definidas sus entradas y salidas, es decir,
su interfaz; en cambio, no se precisa en definir ni conocer los detalles internos
de su funcionamiento.
Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo
concreto, para luego realizar las de caja negra sobre varios subsistemas
(integración).
TECNICAS USADAS
Entre las técnicas usadas se encuentran:
 La cobertura de caminos (pruebas que hagan que se recorran todos los
posibles caminos de ejecución).
 Pruebas sobre las expresiones lógico aritméticas, pruebas de camino de
datos (definición-uso de variables).
 Comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones,
y luego para las iteraciones máximas, máximas menos uno y más uno.

5.6 Otros tipos de test.

Pruebas (test): Una actividad en la cual un sistema o uno de sus componentes


se ejecuta en circunstancias previamente especificadas, los resultados se
observan y registran y se realiza una evaluación de algún aspecto.
Caso de prueba (test case): Un conjunto de entradas, condiciones de
ejecución y resultados esperados desarrollados para un objetivo particular.
Defecto (defect, fault, «bug»): Un defecto en el software como, por ejemplo,
un proceso, una definición de datos o un paso de procesamiento incorrectos en
un programa.

5.7 GUI's y Zooming user interface

Interfaz de Usuario.

8
La interfaz de usuario es el medio con que el usuario puede comunicarse con
una máquina, un equipo o una computadora, y comprende todos los puntos de
contacto entre el usuario y el equipo.
Interfaz gráfica de usuario.
Es un programa informático que actúa de interfaz de usuario, utilizando un
conjunto de imágenes y objetos gráficos para representar la información y
acciones disponibles en la interfaz. Su principal uso, consiste en proporcionar
un entorno visual sencillo para permitir la comunicación con el sistema
operativo de una máquina o computador.
Tipos de Interfaces gráficas
GUI's y Zooming user interface
Los tipos de GUIs que se encuentran en juegos de computadora, y los GUIs
avanzados basados en realidad virtual, se usan con frecuencia en tareas de
investigación. La interfaz de enfoque del usuario o ZUI (Zooming User
Interface), que es un adelanto lógico de las GUI, mezclando 3D con 2D. Podría
expresarse como "2 dimensiones y media en objetos vectoriales de una
dimensión".
Interfaz de usuario de pantalla táctil.
Los "GUIs de uso específico." Un ejemplo de un GUI de uso específico es la
ahora familiar touch screen o pantalla táctil (pantalla que al ser tocada efectúa
los comandos del ratón en el software).
Ejemplos:

 Tabletas electrónicas.
 Smartphones.
 Laptop.
 Smart TV.
Interfaz natural de usuario.
Las NUI naturales son aquellas en las que se interactúa con un sistema,
aplicación, etc., sin utilizar dispositivos de entrada como ratón, teclado, lápiz
óptico, etc. En lugar de éstos se utilizan las manos o las yemas de los dedos.

5.7.1 Documentación (técnica y de usuario)


Documentación para el usuario.
La documentación para el usuario constituye un elemento de consulta para
toda aquella persona que va a usar el programa por primera vez o que trata de
saber si el programa servirá a sus objetivos. Igualmente es útil para usuarios
que ya realizan un manejo básico y quieren profundizar hacia un conocimiento
avanzado. Una documentación completa contendría:
• Portada con el nombre del programa, versión y autor o autores.

9
• Índice.
• Descripción muy breve de las funciones y posibilidades del programa.
• Descripción breve del método de cálculo principal.
• Explicación breve de cómo debe usarse el programa y de los datos de
entrada, opciones y resultados.
• Ejemplos paso a paso de uso del programa en número suficiente para
comprender las posibilidades que se brindan.
• Diagrama de flujo del programa de carácter sintético y descriptivo.
• Especificación detallada de todas las opciones contenidas en menús.
• Especificación detallada de todos los cálculos, principales y
secundarios.
La extensión de la documentación para el usuario será variable en función de la
complejidad y características del programa: puede ir desde un párrafo para
programas muy sencillos y de fácil uso hasta centenares de páginas para
programas comerciales complejos. Los puntos contenidos en la documentación
también son variables, siendo los enumerados anteriormente una orientación.
Para programas sencillos puede reducirse a un título, una explicación breve del
funcionamiento, entradas y salidas y un ejemplo de uso.
Documentación técnica.
La documentación para mantenimiento constituye el elemento de referencia
para el programador que haya de realizar cambios o ampliaciones del
programa en el futuro. La necesidad de mantenimiento deriva de:
• Defectos del programa no detectados y que es necesario corregir.
• Cambios externos de índole política, técnica, social, etc. que afectan
al programa: normativa, moneda, novedades de un sistema operativo,
etc.
• Solicitudes de los clientes o usuarios.

El mantenimiento de un programa puede afectar a su esqueleto o diseño


básico, a funciones importantes pero desligadas del núcleo del programa o a
cuestiones meramente estéticas. De cualquier forma, el mantenimiento debe
considerarse como programación en todos sus sentidos, debiendo partir del
conocimiento del problema y avanzar con detenimiento siguiendo las normas
para una programación sólida. Es ideal un mantenimiento que respete la
filosofía y el estilo del programa que se mantiene, de modo que un auditor no
pudiera detectar qué parte del programa corresponde al código original y qué
parte a la ampliación o corrección.
Por desgracia esto muchas veces no se cumple, por descuido o porque
simplemente realizar un mantenimiento de calidad puede ser muy costoso
frente a una opción rápida y que funciona. El problema surge cundo diversas
operaciones de mantenimiento con distintas formas de construcción y filosofía
empiezan a afectar a la lógica e interconectividad entre las distintas partes del
programa.

10
Una documentación de mantenimiento completa puede contener:
• Portada, número de versión, autor.
• Índice.
• Objeto y aspectos principales del programa.
• Diagrama de flujo modular.
• Diagrama de flujo para cada módulo, desarrollado y con enfoque a las
variables y procesos internos.
• Código completo del programa.
• Explicación de la gestión de errores del programa.
• Esquema o índice descendente del programa, actualizado.
• Explicación de variables, datos, archivos.
• Recomendaciones para el mantenimiento futuro.
• Cualquier información que se considere relevante para un
programador que haya de trabajar con el programa.
Al igual que en el caso de la documentación para el usuario, la extensión y
contenido de la documentación para mantenimiento será variable en función de
la complejidad y características del programa. Para programas sencillos puede
reducirse a un título, una explicación breve y unas recomendaciones, mientras
que para programas comerciales puede requerir cientos de páginas repartidas
en varios tomos.

5.7.2 Seguridad
ASVS tiene dos objetivos principales:
• Ayudar a las organizaciones en el desarrollo y mantenimiento
aplicaciones seguras
• Permitir la alineación entre las necesidades y ofertas de los servicios
de seguridad, proveedores de herramientas de seguridad y
consumidores
NIVELES DE VERIFICACIÓN DE SEGURIDAD DE APLICACIONES
El Estándar de Verificación de Seguridad en Aplicaciones define tres niveles de
verificación de seguridad, incrementando la profundidad con cada nivel.
• ASVS nivel 1 se encuentra dirigido a todo tipo de software.
• ASVS nivel 2 es para aplicaciones que contienen datos sensibles, que
requieren protección.
• ASVS nivel 3 es para las aplicaciones más críticas - aplicaciones que
realizan transacciones de alto valor, contienen datos médicos
confidenciales, o cualquier aplicación que requiera el más alto nivel de
confianza.
Cada nivel ASVS contiene una lista de requerimientos de seguridad. Cada uno
de estos requisitos pueden también corresponderse a funcionalidades
específicas de seguridad y capacidades que deben construirse por los
desarrolladores de software.

11
5.7.3 Diseño de las pruebas
 Principios de UCD
 Análisis del modelo ISO 13407
 Evaluación contextual
 Crear a una persona
 Manual de la página
 Crear Prototipo de Baja fidelidad
 Evaluación de usabilidad con el usuario:
– Diseño contextual
– Inspección de estándares
– Evaluación con un prototipo de baja fidelidad
– Cuestionarios de usabilidad del prototipo
– Formato de tareas y de observación del usuario
– Análisis de tareas usando KLM
 Evaluación de usabilidad sin usuarios:
– Elaboración de Escenarios
– Aplicación de Heurísticas
– Paseo Cognitivo
 Comparación de resultados
– Evaluación con usuarios
– Evaluación sin usuarios
 Presentación de la información
 Descripción de la página con las correcciones hechas

Bibliografía
(s.f.). Obtenido de http://www.itsch.edu.mx/media/oferta_educativa/sistemas/temario/5.-
%20Verificacion%20y%20Validacion%20del%20SW.pdf

Manico, J. (2017). Open Web Aplication Security Project. OWASP.

Prezi.com. (s.f.). Obtenido de https://prezi.com/k10rixkm6_md/unidad-5-implementacion-de-


la-estrategia/

Vivar, J. d. (02 de Junio de 2014). wordpress.com. Obtenido de


https://jddiosvivar.wordpress.com/2014/06/02/unidad-v/

wordpress.com. (Julio de 2014). Obtenido de https://anllhinsmorales.wordpress.com/unidad-


5-implementacion/

12