Diagrama de Casos de Uso

Este diagrama muestra los casos que cada usuario, dependiendo de sus privilegios dentro del sistema, puede realizar.
En este caso, un Administrador, como en todo sistema, tiene los privilegios más altos, desde registrar un producto hasta registrar a proveedores, es decir un administrador es aquel que gestiona la mayor parte del sistema.
Un Administrador Gestiona:
Empleados: Registros, Bajas, Consultas y Modificaciones.
Proveedores: Registros, Bajas, Consultas y Modificaciones.
Productos: Registros, Bajas, Consultas y Modificaciones.
Películas: Registros, Bajas, Consultas y Modificaciones.
Un Empleado Gestiona:
Ventas: Registros y Modificaciones.
En el Caso de Imprimir boleto, es cuando algún cliente llega a comprar un boleto para alguna función, dependiendo de qué película y que horario el cliente desea ver la película, asi se le imprimirá el boleto.

Diagrama de Clases

Muestra las clases y las operaciones funcionales del sistemas.

1.-Clase pelicula .- en esta clase se realiza el registro,consultas,eliminacion,modificacion de sus elementos aparte de envio de parametro a boletos.
2.-Clase boleto,.- en esta clase realiza una verificacion de parametro ya que nesecita la existencia de pelicula para poder registrar,consultar y eliminar su elementos.
3.-Clase usuarios.- en esta clase se realiza registro,eliminacion,modificacion para que en el software se controle la seccion.
4.-Clase empleado.- en esta clase se realiza registro,eliminacion,modificacion para que en el software se controle el empleado.
5.-Clase proveedor.- en esta clase se realiza registro,eliminacion,modificacion para que en el software se controle el proveedor.
6.-Clase producto.- en esta clase se realiza el registro,consultas,eliminacion,modificacion de sus elementos aparte de envio de parametro a ventas.
7.-Clase ventas.- en esta clase realiza una verificacion de parametro ya que nesecita la existencia de productos para poder registrar,consultar y eliminar su elementos.

Diagrama de Secuencia

Muestra la secuencia de las actividades de las operaciones funcionales del sistema.

1.- El administrador pide acceso y manda a autentificacion de usurio de ahi se regresa a administrador mostrando la aplicacion para autentificarse
2.- El administrador ingresa los datos y los manda a autentificacion de usuario y de ahi para el control de registro para verificar los datos si no existen los datos los rechaza al andarlos a la autentificacion y de ahi manda un mensaje error al administrador de lo contrario si se acepta manda un mensaje deatos correctos al administrador
3.- El administrador ahora ya puede registrar empleados,usuarios,proveedores,peliculas y productos y tambien sus demas operaciones basicas (consultar,modificar,consultar)
4.- El administrador ahora ya puede registrar y realizar sus demas operaciones de boletos puesto que manda verificar pelicula existente para poder realizar sus operaciones.
5.- El administrador ahora ya puede registrar y realizar sus demas operaciones de ventas puesto que manda verificar productos existente para poder realizar sus operaciones.

Diagrama de Actividades (Ventas)

El diagrama muestra el procedimiento de las ventas, es decir que acciones tienen que pasar primero para poder almacenar una venta determinada.
Para ello las actividades que se realizan son las consultas de los productos y de las peliculas disponibles para vender y ser vistas por el usuario y no realizar una venta con existencia nula.

Este procedimiento se plantea por separado debido a que es necesario consultar en otra tabla para verificar existencia esto es debido a la dependencia en las tablas, dicho proceso se visualiza en el diagrama y en sus acciones.

Diagrama de Actividades (Usuario)

El diagrama muestra las acciones que realiza el usuario para ingresar al sistema, su autentificacion y cada una de las actividades que en base a los privilegios planteados puede desarrollar dentro del programa.
Dichas acciones implican el registro de ventas y el almacen de las mismas, ademas del registro del los boletos y la venta de los mismos.
Para estas actividades es importante realizar primero la consulta de los datos para determinar si existen o no y poder desarrollar las ventas.

Diagrama de Actividades (Administrador)

El diagrama muestra cada una de las actividades del sistema que son ejecutadas por el administrador, el cual contiene todos los privilegios, ya que puede almacenar datos en todas las tablas de la BD.
El administrador accesa al sistema e inmediatamente dicho software le pide una autentificacionpara conocer el tipo de usuario logeado que es, posteriormente entra al sistema y a partir de esta accion puede ejecutar culaquier operacion dentro de las tablas del sistema para que cada una de ellasfinalize en la salida del sistema.

El diagrama muestra cada una de las actividades que se realizan para el desarrollo del proyecto de software Cine Coffee Huetamo, para ello se determinaron las semanas en que se trabajaría en el proyecto, toman en cuenta 12 semanas hasta la finalización del proyecto.
El diagrama además permite visualizar el tiempo en el que se ha venido desarrollando el sistema, considerando además que se encuentra en la semana 9 de trabajo desde el primer proceso que es la obtención de requisitos hasta el desarrollo de la codificación del mismo, tomando en cuenta la semana 12 de entrega del mismo, estableciendo un periodo de tiempo determinado para completar cada acciones o actividad a llevar a cabo en el desarrollo del programa.

Diagrama de Paquetes

El diagrama muestra los subsistemas en los que se desglosa el sistema.
Es decir, muestra como un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones.
En el diagrama de paquetes se visualiza cada una de las interfaces que requiere para su adecuado funcionamiento
asi como las dependencias que son necesarias para determinar cada operacion ejecuta dentro del sistema.
Por ejemplo, para realizar la venta del boleto es necesario tener peliculas por lo que la dependencia
entre la tabla peliculas y boletos, del mismo modo surge en los productos.
Ademas se visualizar el procedimiento de los proveedores con su respectiva interfaz de usuario
requerida que es la ventana del formulario de proveedores con sus respectivas operaciones a ejecutar.

Se visualiza una dependencia aunque la tabla no muestre relacion
directa dentro de la otra, es decir aunque no exista dentro
de la tabla la clave del proveedor.
Esto significa que para que exista un producto es necesario
contactar un proveedor.
Esto se nota tambien dentro
del paquete empleado, es decir para
que los usuarios existan es necesarimente
estar registrado como empleado
esto a pesar de no tener una relacion directa entre tablas.

Diagrama de Colaboracion

El diagrama muestra el proceso de la venta de boletos y productos que realiza el sistema.
Para ello se visualiza primero una consulta de productos y peliculas disponibles para poder realizar la venta.
Ademas se muestra los procesos que realiza el sistema con el enlace entre las tablas del mismo, ya que para ello se tienen que enviar los datos al mismo sistema ya que este es el que necesariamente inserta los registros pedidos por los usuarios y administradores.
se visualiza ademas la colaboracion y dependencia que tienen las tablas entre si y por tanto la dependencia de sus datos y lo importante que son algunos de ellos para poder realizar ciertas acciones dentro del software.

Introduccion

La prueba de software es un conjunto de herramientas,
tecnicas y métodos que hacen a la excelencia del desempeño
de un programa, asi como tambien la mejor publicidad que
una empresa dedicada a la producción de software pueda
tener. Las tecnicas para encontrar problemas en un programa
son extensamente variadas y van desde el uso del ingenio por
parte del personal de prueba hasta herramientas
automatizadas que ayudan a aliviar el peso y el costo de
tiempo de esta actividad. Pero de nada serviría conocer todas
las tecnicas de prueba de software, si un programa carece de
documentación, el código es confuso, o no se han seguido
pasos para la planificación y desarrollo del software, ya que
seria como buscar una aguja en un pajar.
Es por eso que en este trabajo monográfico nos hemos
volcado a definir no solo las herramientas, tecnicas y metodos
de prueba sino que también a todo el trabajo previo de control
de calidad en el desarrollo de software, ya que sabemos que
mucho mejor que encontrar y solucionar un problema es
prevenir que no ocurra.
¿ Que es el control de calidad del software ?
El control de calidad del software incluye desde el monitoreo de desarrollo de
procesos haciendo respetar los estandares y procedimientos concordados
asegurandose un buen seguimiento de programa y la deteccion y correccion de
errores. El control de calidad del software esta orientado a la prevención.

4.1 Definion de Pruebas de Software

Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

4.1.1 Prueba, caso de prueba, defecto, falla, error, verificación, validación.

Prueba: La prueba de software es un conjunto de herramientas, técnicas y métodos que hacen a la excelencia del desempeño de un programa, así como también la mejor publicidad que una empresa dedicada a la producción de software pueda tener.
Inspecciones de software. Se ocupa del análisis de representaciones estáticas del sistema para describir problemas (verificación estática). Pueden ser complementadas por documentos basados en herramientas y análisis del código
Una prueba con éxito es aquella que muestra que un requerimiento se ha implementado correctamente.

Caso de prueba: Casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio. Un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular

Falla: Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. La denegación de un servicio causada por un error. La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Por ejemplo: Consultas erróneas

Error: una manifestación del defecto en el sistema en ejecución. Los errores se detectan o no. Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipo, una malinterpretación de un requerimiento o de la funcionalidad de un método. 􀂾La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o teóricamente correcto. Una acción humana que conduce a un resultado incorrecto. Por ejemplo: Divisiones entre cero.

Defecto: Un defecto de software (computer bug en inglés), es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software). El origen último o causa de mal comportamiento. El programador escribe mal el nombre de la bd.

Verificación: La verificación del software es el proceso a través del cual se corrobora que el software satisface sus objetivos.

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.
Verificación de software
Validación. ¿Estamos fabricando el producto correcto? Programa→ usuario
Verificación. ¿Estamos fabricando correctamente el producto? Programa → especificación
Todas las actividades que se emprenden para asegurar que el software cumple sus objetivos”
Tiene dos objetivos principales
ó El descubrimiento de defectos en el sistema
ó La evaluación de si el sistema es útil y utilizable en una situación operacional o no.

Metas de la V&V.
La verificación y la validación deberían establecer la confianza de que el software es adecuado al propósito.
Esto NO significa que esté completamente libre de defectos. Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinará el grado de confianza que se necesita.
Confianza de la V&V.
Depende del propósito del sistema, las expectativas del usuario y el entorno de marketing
-Función del software o propósito: El nivel de confianza depende de lo crítico que es el sistema para una organización.
- Expectativas del usuario: Los usuarios pueden tener bajas expectativas para ciertas clases de software.
- Entorno de marketing: Introducir un producto en el mercado pronto puede ser más importante que encontrar defectos en el programa.

4.1.2 Relación entre defecto-falla y error.

Como ya se menciono anteriormente el error es una equivocación cometida por el desarrollador o programador de sistemas, es una idea falsa o equivocada por lo que el error no es del programa sino de la mala codificación del programador. Un ejemplo de estos es: divisiones entre 0 o una inadecuada consulta a una BD.
Defecto: puede ser conducido por un error. Por ejemplo un defecto s haber usa el operador < en lugar de <=, falta de campos en una tabla de BD.
Falla: discrepancia visible que se produce la momento de ejecutar un programa con un defecto. Por ejemplo: una consulta que no arroje ningún resultado.

4.1.3 Pruebas estructurales, funcionales y aleatorias

Existen tres enfoques principales para el diseño de casos o pruebas

1.- El enfoque estructural o de caja blanca. Se centra en la estructura interna del programa (analiza los caminos de ejecución).
2.- El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas.
3.- El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba

CRITERIOS DE COBERTURA LÓGICA

- Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instrucción del programa se ejecute al menos una vez.
- Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias)
- Cobertura de condiciones. Se trata de diseñar tantos casos como sea necesario para que cada condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones)
- Criterio de decisión/condición. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla también el criterio de decisiones.
- Criterio de condición múltiple. En el caso de que se considere que la evaluación de las condiciones de cada decisión no se realiza de forma simultánea, se puede considerar que cada decisión multicondicional se descompone en varias condiciones unicondicionales.
- Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable).



PRUEBAS FUNCIONALES
Se centran en las funciones, entradas y salidas
Es impracticable probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba

Un caso de prueba funcional es bien elegido si se cumple que:
Reduce el número de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos.
*Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto específico de entradas que prueba, así como de otros conjuntos similares.

PRUEBAS ALEATORIAS
En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podrían aparecer en la Práctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automáticos de casos de prueba.

4.1.4 Documentación del diseño de las pruebas

PLAN DE PRUEBAS
Objetivo del documento
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

Estructura fijada en el estándar
1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeñado
ESPECIFICACION DEL DISEÑO DE PRUEBAS

Objetivo del documento
Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas

ESPECIFICACION DEL DISEÑO DE PRUEBAS
Estructura fijada en el estándar
* Identificador único para la especificación. Proporcionar también una referencia del plan asociado (si existe)
* Características a probar de los elementos software (y combinaciones de características)
* Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados

ESPECIFICACION DE CASO DE PRUEBA
Objetivo del documento
Definir uno de los casos de prueba identificado por una especificación del diseño de las pruebas

ESPECIFICACION DE CASO DE PRUEBA
Estructura fijada en el estándar
Elementos software (por ejemplo, módulos) que se van a probar: definir dichos elementos y las características que ejercitará este caso
* Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronización de las mismas)
* Especificaciones de todas las salidas y las características requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar
* Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal)

ESPECIFICACION DE PROCEDIMIENTO DE PRUEBA
Objetivo del documento
Especificar los pasos para la ejecución de un conjunto de casos de prueba o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito de evaluar un conjunto de características del mismo

Estructura fijada en el estándar
Identificador único de la especificación y referencia a la correspondiente especificación de diseño de prueba
* Objetivo del procedimiento y lista de casos que se ejecutan con él
* Requisitos especiales para la ejecución (por ejemplo, entorno especial o personal especial)
* Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar:
* La secuencia necesaria de acciones para preparar la ejecución
* Acciones necesarias para empezar la ejecución
* Acciones necesarias durante la ejecución
* Cómo se realizarán las medidas ( por ejemplo, el tiempo de respuesta)
* Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen)
* Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en estos puntos
* Acciones necesarias para detener ordenadamente la ejecución
* Acciones necesarias para restaurar el entorno y dejarlo en la situación existente antes de las pruebas
* Acciones necesarias para tratar los acontecimientos anómalos.