Está en la página 1de 85

INSTITUTO TECNOLOGICO DE

CD.MADERO

Desarrollo de Proyectos de Software.


Documentación, Manual de Usuario y Plan de
pruebas del:
“Sistema de Control de Desecho Computacional”.

Maestra:

Laura Taide Contreras Álvarez.


Hora:

09:00 – 10:00 a.m.


Alumnos:
Caloca Castillo José Jesús.

Carrillo Ibarra Jesús Eduardo.


Del Ángel Morales José Rafael.

Saucedo Enríquez Violeta.

Cd. Madero Tamaulipas, Enero-Junio 2009

.
i
Índice
Capítulo 1

1 Planteamiento del problema…………………………………………….....…..…..1

Capítulo 2

2 Metodología…………………………..….…………………………………….….…2

2.1 Selección de proyecto……………...……………………...…………….2

2.2 Personas disponibles para el desarrollo del proyecto…………….....4

2.3 Herramientas de Hardware y Software……………...………………..5

2.4 Diagrama de las tres R del desecho computacional………………...6

2.5 Organigrama del sistema…………….……………..….………………..7

2.6 Desarrollo del ciclo de vida del Modelo Incremental…….……………………8

2.6.1 Modelo Incremental…………………………………...……………….8

2.6.1.1 Análisis de los requerimientos del software……………………...9

2.6.1.2 Diseño……………………………………………………………..…13

2.6.1.3 Generación de código………………………………………..……..44

2.6.1.4 Pruebas………………………………….…………………………...53

Anexos…………………………………………………………………………………80

ii
Capítulo 1

Planteamiento del problema.

En México como la mayoría de los países latinoamericanos el rehúso, la reutilización y el


reciclado de los desechos tecnológicos, computadoras televisiones; y teléfonos celulares
no es un tópico de importancia. Y no es que carezca de ella, sino que en la sociedad no
se proporciona información sobre qué hacer con ellos una vez que ya no sean usados.

En la red así como en el entorno existe escasa información sobre lo que se está haciendo
en el país para involucrarse en el tema.

En otros países encontramos campañas para el manejo de los desechos electrónicos y


computacionales, donde se pretende contribuir a la mejora del medio ambiente así como
ahorrar en la inversión en nuevos productos.

Aquí en México éste tipo de campañas son poco aplicadas. Existe un programa donde se
devuelven artículos de impresión y es para clientes de negocios selectos.

Aunque los datos encontrados no son los más halagadores en cuestión de los desechos
computacionales; estos solo nos demuestran que hay un gran campo de oportunidad para
ponernos a trabajar en el.

Mientras nosotros seguimos guardando arriba de algún ropero o vitrina los desechos
computacionales otros ya los hacen productivos; es una gran oportunidad en el aspecto
económico y es una buena idea iniciar por un entorno local.

El proyecto que se realizará consistirá en desarrollar un sistema de control de los


desechos computacionales. Éste estará regido por el principio de las 3 “R’”: reducir,
reutilizar y reciclar.

Para el desarrollo del sistema deberemos de considerar el tiempo de vida de los equipos,
el cual va desde los 8 hasta los 10 años. Además consideraremos las áreas de las que
proceden dichos equipos, el uso que se le dieron, las razones por las cuales dejaron de
usarse, etc.

También es necesario determinar qué componentes pueden ser usados, los cuales van
desde memorias, lectores de cd’s, ventiladores, mouse, teclado, así como los demás

1
componentes que puedan ser ensamblados para no desechar todo el equipo en caso de
que ya no pueda ser reutilizado.

Como fue mencionado antes, el tiempo de vida de los dispositivos es importante, ya que
no es de mucha utilidad rehusar piezas que en cuestión de “días” dejarán de funcionar.

Es necesario considerar la cantidad de memoria tipo del procesador, numero de bahías


de expansión, la arquitectura, la compatibilidad entre las placas y los demás
componentes. Para esto el sistema a desarrollar cumplirá con las funciones de un
inventario. Además se llevara un control de cada uno de los componentes, de modo que
sabremos que componentes son reutilizados, reducidos o reciclados.

Capítulo 2

Metodología.

Para la realización del sistema es necesario seleccionar algún modelo de desarrollo del
mismo. Hemos seleccionado usar el modelo de desarrollo de prototipos, comenzando con
la recolección de requisitos. Definiremos los objetivos globales para el software, para
poder hacer un diseño, lo que nos llevará a la construcción de un prototipo. El cual nos
ayudará a refinar los requisitos del software a desarrollar.

Además queremos adoptar características del modelo incremental, ya que nos permitirá ir
por partes en el momento de estar desarrollando el sistema. Cuya característica es que
cada incremento es funcional.

De tal forma, adoptaremos características de los dos modelos.

2.1 Selección de proyecto.

o Respaldo de los directivos de la organización.

Dado que contamos con el respaldo de la escuela y de organizaciones como el


ayuntamiento municipal, quienes han mostrado un gran interés en administrar sus
desechos computacionales a través del sistema, por lo que este punto de los criterios
para la selección de proyectos queda cubierto.

2
o Periodo adecuado de compromiso para el proyecto:

Este proyecto está contemplado para su desarrollo en un año, la primera fase está
contemplada para el 30 de noviembre de 2008 incluyendo la entrega de las primeras
interfaces con la ayuda de algún programa de diseño y/o programación y la segunda fase
del 26 de enero al 27 de mayo de 2009 el sistema terminado con documentación y la
implementación completas.

o Posibilidad de mejorar la consecución de las metas organizacionales:

Consideramos que el sistema ayudara de forma eficiente al proyecto del control de


desechos computacionales.

o Factibilidad en cuanto a los recursos del analista de sistemas y la organización.

La factibilidad de los recursos está garantizada dado que los recursos a utilizar serán los
propios de los integrantes del equipo de desarrollo y los recursos del ITCM.

o Rentabilidad del proyecto en comparación de otras formas en comparación a


otras formas en las que la organización podría invertir sus recursos

Consideramos que pude ser rentable dado que se manejaran grandes cantidades de
información del equipo computacional que serian difíciles de procesar de forma manual.

o Viabilidad

Técnica: Este aspecto de la viabilidad existe en nuestro proyecto dado que contamos con
el equipo de cómputo necesario para la realización del software.

3
Operativa: Dado que contamos con cuatro integrantes consideramos que son los
suficientes como para que se aboquen a una actividad específica y además puedan
intervenir en otras actividades propias del desarrollo.

2.2 Personas disponibles para el desarrollo del proyecto.

Cuatro personas con las siguientes asignaciones de acuerdo con sus conocimientos y
habilidades:

Aunque todos los miembros del equipo nos daremos a la tarea de participar en las
actividades que el proyecto requiera, cada uno se enfocará más en un área específica, de
acuerdo a las fortalezas con las que se cuente.

Funciones de los miembros del equipo.

CALOCA CASTILLO JESÚS.

Posee cierto conocimiento en programación como PHP, Java, y servidor web.

Colaborará en la codificación del software.

CARRILLO IBARRA JESÚS EDUARDO.

Posee cierto conocimiento en programación como Visual Basic y Java.

Colaborará en la codificación del software y documentación del mismo.

DEL ÁNGEL MORALES JOSÉ RAFAEL

Posee cierto conocimiento en programación como Java, y servidor web.

Colaborará en el análisis de los equipos computacionales.

Elaborará la documentación necesaria.

SAUCEDO ENRÍQUEZ VIOLETA

Conocimientos respecto a hardware y dispositivos externos y en programación como


Java. Colaborará en el análisis de los equipos computacionales.

Elaborará la documentación necesaria.

4
2.3 Herramientas de Hardware y Software

Entornos de Desarrollo Integrado

 Eclipse
 NetBeans 5.0 o 6.0
Manejadores de base de datos:

 Microsoft SQL 2005


 Access 2003
 MySQL

Hardware disponible.

1 Computadora de Escritorio y 3 Laptops con las siguientes características:

o Computadora 1
 Memoria RAM: 1 Gb
 Disco duro: 40 Gb.
Procesador: Intel Pentium 4 a 1.8 GHz.

o Computadora 2:
 Memoria RAM: 1Gb
 Disco duro: 120 Gb.
 Procesador: Intel Core 2 duo, 2.1 GHz.

o Computadora 3:
 Memoria RAM: 1Gb
 Disco duro: 120 Gb.
 Procesador: Intel Core 2 duo, 2.1 GHz.

o Computadora 4:
 Memoria RAM: 1Gb
 Disco duro: 120 Gb.
 Procesador: Intel Core 2 duo, 2.1 GHz.

5
2.4 Diagrama de Rehúso, reutilización y Reciclaje del Deshecho Computacional.

6
2.5 Organigrama del sistema.

7
2.6 Desarrollo del ciclo de vida del modelo incremental.

Incluye las fases del modelo lineal secuencial de forma iterativa (Análisis de los
requerimientos del software, Diseño, Generación del código y Pruebas). Por cada
iteración se realizará un incremento, puede ser una hoja de papel (diagramas, interfaces)
y/o mejoras al proyecto.

2.6.1 Modelo incremental.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño código y


Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en
cadena o "Pipeline", utilizado en muchas otras formas de programación. Con esto se
mantiene al cliente en constante contacto con los resultados obtenidos en cada
incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso
se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega
se reduce considerablemente.

Al igual que los otros modos de modelado, el Modelo Incremental es de naturaleza


interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un
producto completamente operacional.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de


personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de
personas y en cada incremento se añadirán personal, de ser necesario. Por otro lado los
incrementos se pueden planear para gestionar riesgos técnicos.

Esquema Modelo Incremental:

Análisi Diseño Códig Prueb Entrega de


1er.

Análisi Diseño Códig Prueb Entrega de


Análisi Diseño Códig Prueb Entrega de


3er.

Tiempo de

8
2.6.1.1 Análisis de los requerimientos del software.

Es la fase en la cual se reúnen todos los requisitos que debe cumplir el software. En esta
etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos.

Elegiremos los instrumentos de recolección de datos, entre las cuales encontramos la


encuesta, entrevista, muestreo, observación.

Dado que la población corresponde a los equipos de desecho, es muy probable que las
entrevistas y las encuestas no sean necesarias, por lo tanto se trabajará con la
observación.

A través de la observación, se clasificará a los equipos y se aplicará el principio de las tres


R (reducción, reutilización, reciclable).

Se elaborará un formato para registrar el aspecto físico de cómo llegan los equipos,
considerando los dispositivos con lo que llegaron, si vienen completos o con partes
ausentes, si están dañados, color, marca, etc.

Caso de uso 1: Capturista- Registro

9
Caso de uso 2: Capturista- Consultas y Salidas (Destino final)

10
Caso de uso 3 :Capturista-Bajas

11
Caso de uso 4: Director del proyecto - Sistema (Consultas)

Caso de uso Presidencia- Sistema (proyecto)

12
2.6.1.2 Diseño

Es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las
representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se
hace un esbozo de lo solicitado y se documenta haciéndose parte del software.

En esta etapa del proceso se elaborarán las interfaces del sistema, así como los
diagramas E/R (Entidad-Relación) en el diseño de la Base de Datos. Diagramas UML de
las clases que incluirá el programa, Modelos de caso de uso, diagramas de interacción.

Vista lógica.

En ésta vista se representan los diferentes objetos del sistema, apoyando principalmente
los requisitos funcionales que el sistema puede brindar como servicio a los usuarios.

13
Vista de procesos

14
Vista Física

Diagrama UML.

Diagrama de clases.

15
Diagrama de Estados.

Diagrama de Secuencia

16
17
Diagrama de Colaboración.

Main

0. ir a Login

18
Arquitectura del sistema de control de desechos computacionales.

Después de haber leído y documentado las ventajas y desventajas de las diferentes


arquitecturas para el desarrollo de software, hemos determinado que usaremos la
arquitectura centrada en datos dado que de acuerdo con su definición esta arquitectura:

“En el centro de ésta arquitectura se encuentra un almacén de datos al que otros


componentes acceden con frecuencia para actualizar, añadir, borrar o bien modificar los
datos del almacén”

Y esto ocurrirá en nuestro sistema básicamente ya que se almacenarán datos como: las
máquinas que llegan, los componentes reutilizables de las máquinas que ya no sean
reutilizables, además también se tendrá que hacer el borrado lógico de las piezas que
serian usadas para probar si serían útiles para cierto equipo y además, si resultan útiles
hacer la baja definitiva.

Estos son solo algunos de los ejemplos de por qué se eligió esta arquitectura.

Component
es

Servidor
19
Diseño de interfaz de usuario.

En vista que estamos desarrollando un sistema de control el cual utilizarán varios actores
y de acuerdo con las fuentes bibliográficas del tema hemos tratado de hacer la interfaz
con:

 Familiaridad
 Uniformidad
 Recuperabilidad

A continuación una muestra

Las instrucciones reflejadas en las etiquetas son


familiares para personas en contacto continuo con
equipo de cómputo y en específico con los que utilizan el
sistema

20
El aspecto de la uniformidad se podría reflejar de la siguiente manera:

Como se resalta en los óvalos con línea negra los botones se ordenaron de la sig. manera
a la derecha de la pantalla aparece el botón ACEPTAR luego un espacio y enseguida el
botón CANCELAR ambos como lo refleja este mismo escrito con su etiqueta en letras
mayúsculas con el propósito de hacerlo más fácil de leer al usuario

21
Por otro lado en lo que se refiere a estas mismas interfaces de captura determinamos que
primero viene la etiqueta con la instrucción y Luego el componente donde se introducirá la
información. Así como la uniformidad en los cuadros de diálogo.

En lo que se refiere a las pantallas de consulta deben tener la siguiente estructura:

 Un letrero de instrucción
 Un componente para introducir un criterio de búsqueda (combobox,
textfield,combobox,etc)
 Un botón con la Palabra CONSULTAR + xxxx es decir algún otro texto
 Un componente para desplegar la información (textarea, etiqueta, textfield,etc)

22
Teoría del color aplicada a las interfaces del sistema

Hemos decidido que nuestras ventanas tengan el color RGB configurado de la siguiente
manera: (Rojo: 233, Verde 236, Azul: 216) este color viene como uno de los
predeterminados en la ficha System Palette en NetBeans y lo denomina control.

Una de las rezones es que es uno de los colores más comunes en el desarrollo de
interfaces en la mayoría de las aplicaciones de Microsoft y dado que muchos de los
usuarios están acostumbrados a ellas elegimos este color.

Otra razón por la que este color secundario obtenido a través de RGB ha sido elegido es
porque es un color frío, dado que nuestro sistema es un sistema de control y la persona
quien lo maneje requiere que los colores no sean tan alegres en el caso de que
permanezca o tenga que permanecer mucho usando un tiempo considerable el sistema

Además de elegir el color negro con el fin de tener un mayor contraste de de luminosidad
y saturación que le permitan al operador del sistema hacer uso de él con comodidad.

Aquí la ventana de ejemplo:

23
MANUAL DE USUARIO

En este manual de usuario se muestra una forma detallada de cómo utilizar el Software
“Sistema de Control de Desecho Computacional”.

Mostrando cada uno de los módulos que integran el sistema por separado, ejemplificando
con descripción escrita y visual (imágenes) cada uno de los posibles casos que se
pudieran presentar durante la ejecución de éste, detallando cada interfaz y los pasos a
seguir para el buen funcionamiento de éstas, para permitir la obtención de los resultados
esperados.

Al final del manual se agregó una sección de Anexos, cuyo contenido son los atajos de
teclado (teclas de acceso rápido), que el usuario puede tener de uso opcional en caso de
falta o familiaridad con el uso del mouse, así como una breve descripción y ejemplificación
de algunos de los casos especiales que pudieran ocasionar problemas al usuario durante
el uso del sistema.

24
Instalación de Sistema_Control

Requisitos:

Para que sistema control funcione adecuadamente en su maquina requiere dos


herramientas adicionales:

1. MySQL 5.0 o superior (lo puede descargar en www.mysql.com )

2. Java (TM) SE Development Kit Uptdate 13 (o 12) y Java (TM) Update 13 (aunque
no es indispensable si ha descargado la primera) (www.java.com )

25
*La instalación de las herramientas solo requiere seguir instrucciones en pantalla

* El entorno de desarrollo fue Windows XP Professional , asegurese de descargar


la versión adecuada para su Sistema operativo

3. Para desarrolladores

Si es parte del equipo de mantenimiento del software tal vez le interese descargar
EMS Manager o SQL Front son entornos gráficos para el desarrollo y modificación
de bases de datos MySQL

Instalación de Sistema_ Control

1. Introduzca su CD en la unidad lectora

2. Vaya a inicio MiPC en Windows XP / AplicacionesEquipo en Linux abra el


CD

3. Copie la carpeta Sistema_ Control en su equipo

4. Ábrala- Vaya a la carpeta dist de doble Clic en Sistema_Control Executable Jar


File

26
5. Si lo desea copilo a otro sitio o preferiblemente Botón secundario  crear acceso
directo/ Botón secundario-crear lanzador

6. Listo para ejecutar

27
Inicio de sesión

Como primer paso vamos registrarnos en la base de datos del sistema (es necesario estar
como usuarios existentes, para poder accesar a él), como el software es usado por vez
primera se ha agregado un nombre de usuario por default, para poder iniciar sesión y
agregar más usuarios para su uso continuo, Introduzca el nombre del usuario
“Administrador” y contraseña “administrador”.

*.- Caracteres inválidos: (todos los caracteres que no se encuentren entre la A-Z, a-z y 0-
9). Por ejemplo: ¡,”,#,$,%,&,/,(,),=,?,!,+,~,{,], espacios en blanco, números no enteros etc.

28
Si el nombre de Usuario y/o Contraseña ingresados fueron incorrectos aparecerán las
siguientes pantallas, la primera si el usuario no se encuentra registrado y la segunda
imagen muestra el cuadro de dialogo que aparecerá si la contraseña no coincide con el
usuario ingresado:

Si después de tres intentos fallidos no se ingresaron los datos correctamente, el sistema


se cerrara automáticamente apareciendo un cuadro de diálogo indicando el siguiente
mensaje “superaste el número de intentos”.

29
Una vez ingresado el nombre de usuario y contraseña correcta, podrá ingresar al sistema
y aparecerá la siguiente pantalla.

Registro de Computadoras

En este módulo del sistema se darán de alta las computadoras que lleguen, ingresando el
número de serie antiguo (con el que llegó nuestro PC), la fecha de llegada, verificar si
prende, de ser así es que si funciona de lo contrario no funciona, dar click en el botón
“aceptar”, si el ingreso es correcto aparecerá la siguiente pantalla.

Se aceptan
únicamente los
caracteres entre A-Z,
a-z y 0-9.

30
Si nuestro número de serie ingresado es de alguna computadora ya registrada nos
arrojara el siguiente mensaje:

Registro de Componentes

En este módulo del sistema se registrarán uno por uno los componentes con los que
cuente la PC, agregándoles un número de serie a cada componente, nombre,
especificación, capacidad y un dato muy importante si es o no Reutilizable, dando click en
el botón “aceptar” para guardar la inserción y si fue correcto el registro aparecerá el
siguiente mensaje.

Se aceptan
únicamente los
caracteres entre A-Z,
a-z y 0-9.

31
Si el número de serie del componente ingresado ya se encuentra registrado, el sistema
nos arrojara el siguiente mensaje “Numero de serie repetido” como se muestra en la
siguiente pantalla.

Equipo Reensamblado.

En este módulo del sistema se agregaran equipos reensamblados, computadoras que


fueron creadas con componentes anteriormente registrados, aquí se ingresará un nuevo
número de serie para la computadora recién armada, con fecha de creación y número de
serie de cada componente a utilizar, una vez ingresados los datos se procederá a dar
click en el botón “aceptar” y aparecerá la siguiente pantalla.

Se aceptan
todos los
caracteres de
entre A-Z, a-z y
0-9. 32
Si el número de serie asignado a la computadora que se desea registrar ya existe, el
sistema arrojará el siguiente mensaje:

Una observación importante: Cada componente que fue utilizado para el reensamble de la
PC tiene un “número de serie” que le fue asignado en el registro de componentes.

El sistema verifica que el número de serie ingresado para cada componente este dado de
alta en el sistema, es decir, que se encuentre registrado en la base de datos, para así
poder utilizarlo, de lo contrario el sistema arrojará un mensaje “Número de serie no
existe”.

33
Mantenimiento

En este módulo del sistema se darán de alta las computadoras que estén funcionando
correctamente para darles el mantenimiento necesario para su uso posterior, se
agregarán datos de número de serie con el cual la PC ya esté registrada, la fecha de
llegada, el Sistema Operativo y el tipo de Software que se le instalarán para su uso
continuo, una vez ingresados todos los datos correctamente se procederá a dar click al
botón “aceptar” y aparecerá la siguiente pantalla.

Se aceptan
únicamente los
caracteres
entre A-Z, a-z y
0-9.

Si el número de serie ingresado para la computadora en mantenimiento ya está


registrado, el sistema mostrará el siguiente mensaje:

34
Destino Final

En este módulo del sistema se registrara el destino final al que enviará nuestra PC ya
armada y lista para ser usada, ingresaremos el número de serie con el que la
computadora haya sido registrada anteriormente, seguido de la fecha de salida y por
último el destino al cual será enviada la computadora, una vez ingresados los datos se
procederá a dar click al botón “aceptar” y aparecerá la siguiente pantalla.

Se aceptan
únicamente los
caracteres entre A-Z,
a-z y 0-9.

Si el número de serie ingresado para la computadora en Destino Final ya está registrado,


el sistema arrojará el siguiente mensaje:

35
Consultas

Para realizar consultas por Número de serie, ingrese al menú Consultas – Consultar – Por
Número de Serie mostrará la siguiente pantalla, ingrese el número de serie del
componente que desea consultar y pulse el botón “Consultar información” y a
continuación se desplegará la lista del componentes solicitado.

Se aceptan
únicamente los
caracteres entre
A-Z, a-z y 0-9.

Para separar un componente debe seleccionar el componente deseado y pulsar el botón


“Separar”.

36
Si el componente no se encuentra registrado le aparecerá el siguiente cuadro de diálogo.

Para realizar una consulta por nombre de componente ingrese al menú Consultas –
Consultar – Por componente, mostrará la siguiente pantalla, seleccione el nombre del
componente que desea consultar y pulse el botón “disponibles” y a continuación se
desplegará la lista de los componentes existentes.

37
Para apartar un componente, deberá seleccionarlo de la lista desplegada de
componentes disponibles, como se muestra en la siguiente pantalla y a continuación
pulsar el botón “Apartar”.

Ya que de lo contrario arrojará el siguiente cuadro de diálogo, pulse “aceptar” para poder
efectuar su apartado satisfactoriamente.

38
Registrar Usuario

Para registrar o dar de alta un nuevo usuario ingrese al menú Usuarios – Registrar
usuario, le aparecerá la siguiente pantalla donde deberá llenar todos los campos con los
datos requeridos y pulse aceptar, el sistema le mostrará un cuadro de diálogo de que el
usuario se ha registrado exitosamente.

Se aceptan
únicamente los
caracteres entre A-Z,
a-z y 0-9.

En el caso de que el usuario que usted ingresó ya exista le mostrará el siguiente cuadro
de diálogo, deberá pulsar aceptar y posteriormente limpiar para poder volver a ingresar
los datos

39
Eliminar Usuario

Para eliminar algún usuario del sistema pulse en el menú Usuarios - Eliminar usuario, e
ingrese el nombre del usuario que desea eliminar, si el usuario se encuentra registrado le
aparecerá el siguiente cuadro de diálogo:

Se aceptan
únicamente los
caracteres entre A-Z,
a-z y 0-9.

Y finalmente da click en “Aceptar” y aparecerá la siguiente pantalla indicando que el


usuario ha sido eliminado de su base de datos.

40
Salir

Para salir del sistema debe ingresar al menú operaciones y pulsar la opción “Salir” o
presionar la tecla Alt+F4.

41
Atajos o Teclas de acceso rápido.

 Registro de computadoras:
Ctrl+N
 Registro de componentes:
Ctrl+C
 Equipo reensamblado:
Mayúsculas+R
 Mantenimiento: Ctrl+M
 Destino Final: Ctrl+S
 Consultas por número de
serie: Ctrl+F1
 Consultas por nombre de
componente: Ctrl+Q
 Registrar usuario: Ctrl+U
 Eliminar usuario: Ctrl+X
 Salir: Alt+F4

Restricciones o casos Especiales.

En ninguno de los campos de los diferentes módulos del sistema se permite que los datos
ingresados rebasen una longitud de 50 caracteres y que sean caracteres no válidos.

*.- Caracteres inválidos: (todos los caracteres que no se encuentren entre la A-Z, a-z y 0-
9). Por ejemplo: ¡,”,#,$,%,&,/,(,),=,?,!,+,~,{,], espacios en blanco, números no enteros etc.

42
Casos Especiales

Las siguientes pantallas son ejemplos de cuadros de diálogo que mostrará el sistema al
encontrarse con cualquiera de éstos casos especiales.

Un caso especial relevante es cuando no todos los campos de algún módulo han sido
llenados. Es necesario ingresar todos los datos que requiere la interfaz en uso.

43
Otro caso especial que arrojará cuadros de diálogo como se muestra en la siguiente
pantalla, es cuando los campos sean llenados con otro tipo de dato diferente al requerido,
por ejemplo, si el campo pide ingresar un número, solo son permitidos los caracteres del
0-9, ningún otro carácter es válido para éste campo en especial.

44
Diccionario de datos

Atributo Descripción Tipo de dato


numero_de_serie Presenta el número de serie del Varchar(50)
equipo que llega
fecha_de_llegada Fecha de llegada del equipo Varchar(50)
donado
numero_de_componentes_reu Es el número de componentes Varchar(50)
reutilizables
Estado Condiciones en las que llega la Varchar(50)

Registro Componentes

Atributo Descripción Tipo de dato


No_serie_comp No de serie del componente que Varchar(50)
se obtuvo
Componente Tipo de componente que se está Varchar(50)
registrando
Capacidad Capacidad en MB GB o MHz Varchar(50)
,etc del componente registrado
Reutilizable Da a conocer el estado el Varchar(50)
componente

Equipo reensamblado

Atributo Descripción Tipo de dato


No_serie_nuevo No de serie del equipo que se Varchar(50)
acaba de reensamblar
fecha_reensamble Presenta la fecha en que Varchar(50)
ensamblo el equipo
no_serie_procesador Presenta el número de serie del Varchar(50)
procesador que se instaló
no_serie_ram Presenta el numero del serie de Varchar(50)
la memoria RAM que se instaló
no_serie_dd Presenta el numero del serie del Varchar(50)
disco duro que se instaló
no_serie_monitor Presenta el numero del serie del Varchar(50)
monitor que se instaló
no_serie_teclado Presenta el numero del serie del Varchar(50)
teclado que se instaló
no_serie_mouse Presenta el numero del serie del Varchar(50)
ratón que se instaló
no_serie_gabinete Presenta el numero del serie del Varchar(50)
gabinete donde se instalaron los
componentes

45
Mantenimiento

Atributo Descripción Tipo de dato


No_serie Es el número de serie de la Varchar(50)
computadora a la que se da
mantenimiento
fechamantenimiento Es la fecha en la que se ha Varchar(50)
realizado el mantenimiento
sistemaoperativo Presenta el sistema operativo Varchar(50)
que se instaló
software Presenta las aplicaciones que se Varchar(50)
le instalaron

Destino_ final

Atributo Descripción Tipo de dato


No_serie Numero de serie del equipo Varchar(50)
donado
Fecha_de_salida Fecha donación del equipo Varchar(50)
Destino Institución a la que será donada Varchar(50)

Usuarios

Atributo Descripción Tipo de dato


Nombre Nombre real del usuario Varchar(50)
Dirección Domicilio del usuario Varchar(50)

Teléfono Número telefónico del usuario Varchar(50)


nom_us Nombre de usuario en el sistema Varchar(50)
contraseña Número confidencial de acceso Varchar(50)

46
2.6.1.3 Generación de Código.

Es la etapa en la cual se traduce el diseño para que sea comprensible por la máquina.
Esta etapa va a depender estrechamente de lo detallado del diseño.

A continuación se muestra el código de los métodos principales utilizados en el sistema.

*.- Login

public class Login extends javax.swing.JFrame {

private Connection conexion;

public static String user;

private String contrasena;

private static int contintentos=0;

private int VK_ENTER=13;

/** Creates new form Login */

public Login()

setTitle("Log in");

crearConexion();

initComponents();

*.- Registro de componentes.

public void componentesbd() throws SQLException {

st = conexion.createStatement();

ResultSet tabla = st.executeQuery("select * from componentes where


No_Serie_Comp = '"+numserie.getText()+"'");

if(!(tabla.next()))

st.executeUpdate("INSERT INTO componentes


(No_Serie_Comp,Componente,Capacidad,Reutilizable,Especificacion) VALUES
('"+numserie.getText()+"','" +tipo.getText() +

47
"','"+capacidad.getText()+"','"+jComboBox1.getItemAt(jComboBox1.getSelectedIndex())+"',
'"+especificacion.getText()+"')");

JOptionPane.showMessageDialog(null, "Se ha Registrado Exitosamente",


"Registro Completo", JOptionPane.INFORMATION_MESSAGE);

}else

JOptionPane.showMessageDialog(null, "Numero De Serie Repetido", "Error",


JOptionPane.ERROR_MESSAGE);

//st.executeUpdate("INSERT INTO contacto (nombre, apellidos, telefono)


VALUES ('"+nombres[i]+"','"+apellidos[i]+"','"+telefonos[i]+"' )");

System.out.println("Inserted data Componentes");

*.- Consultas

public void consultarutilizados() throws SQLException

botonapartar.setEnabled(false);

botonconfirmar.setEnabled(false);

botonregresar.setEnabled(false);

Statement instruccion = conexion.createStatement();

ResultSet tabla = instruccion.executeQuery("SELECT count(*) FROM componentes


WHERE Componente='"+jComboBox1.getItemAt(jComboBox1.getSelectedIndex())+"'&&
Disponibilidad = 'no disponible'");

int RenglonesResultantes=0;

if(tabla.next())

RenglonesResultantes=Integer.parseInt(tabla.getString(1));

if(RenglonesResultantes==0)

48
JOptionPane.showMessageDialog(null,"No hay componentes utilizados",
"Resultados de la consulta", JOptionPane.INFORMATION_MESSAGE);

}else

tabla = instruccion.executeQuery("SELECT
No_Serie_Comp,Componente,Capacidad,Especificacion,Disponibilidad,solicitante FROM
componentes WHERE
Componente='"+jComboBox1.getItemAt(jComboBox1.getSelectedIndex())+"'&&
Disponibilidad = 'no disponible'");

ResultSetMetaData metaDatos = tabla.getMetaData();

int renglon=0;

String registro[]=new String[metaDatos.getColumnCount()];

for(int j=0;j<RenglonesResultantes;j++)

if (tabla.next())

for(int i=0;i<metaDatos.getColumnCount();i++)

registro[i]=new String(tabla.getString(i+1));

//jTable1.setValueAt((Object)tabla.getString(i+1), renglon, i);

renglon++;

mimodelo.addRow(registro);

else

JOptionPane.showMessageDialog(null,"No se encontro el componente",


"Resultados de la consulta", JOptionPane.INFORMATION_MESSAGE);

49
public void consultarprestados() throws SQLException {

Statement instruccion = conexion.createStatement();

ResultSet tabla = instruccion.executeQuery("SELECT count(*) FROM componentes


WHERE Componente='"+jComboBox1.getItemAt(jComboBox1.getSelectedIndex())+"'&&
disponibilidad='prestado'");

int RenglonesResultantes=0;

if(tabla.next())

RenglonesResultantes=Integer.parseInt(tabla.getString(1));

if(RenglonesResultantes==0)

botonapartar.setEnabled(false);

botonconfirmar.setEnabled(false);

botonregresar.setEnabled(false);

JOptionPane.showMessageDialog(null,"No hay componentes prestados",


"Resultados de la consulta", JOptionPane.INFORMATION_MESSAGE);

}else

tabla = instruccion.executeQuery("SELECT
No_Serie_Comp,Componente,Capacidad,Especificacion,Disponibilidad,solicitante FROM
componentes WHERE
Componente='"+jComboBox1.getItemAt(jComboBox1.getSelectedIndex())+"'&&
disponibilidad='prestado'");

ResultSetMetaData metaDatos = tabla.getMetaData();

int renglon=0;

String registro[]=new String[metaDatos.getColumnCount()];

for(int j=0;j<RenglonesResultantes;j++)

if (tabla.next())

for(int i=0;i<metaDatos.getColumnCount();i++)

50
registro[i]=new String(tabla.getString(i+1));

//mimodelo.setValueAt((Object)tabla.getString(i+1), renglon, i);

mimodelo.addRow(registro);

renglon++;

botonapartar.setEnabled(false);

botonconfirmar.setEnabled(true);

botonregresar.setEnabled(true);

*.- Eliminar.

public class Eliminar_usuario extends javax.swing.JPanel {

static Connection conexion;

static Statement st1;

/** Creates new form Eliminar_usuario */

public Eliminar_usuario() {

initComponents();

public void setConexion(Connection conexion) {

this.conexion = conexion;

51
*.- Métodos de restricciones del sistema. (Validaciones).

package sistema_control;

import javax.swing.JOptionPane;

import javax.swing.JOptionPane;

import java.sql.*;

import java.sql.ResultSet;

import java.sql.Statement;

import java.util.logging.Level;

import java.util.logging.Logger;

* @author Administrador

*/

public class Validaciones {

static Connection conexion;

static Statement st1;

public void setConexion(Connection conexion) {

this.conexion = conexion;

public void verificans(javax.swing.JTextField tf) throws SQLException {

// Statement st = conexion.createStatement();

st1 = conexion.createStatement();

ResultSet rs=null;

//Un objeto ResultSet, almacena los datos de resultados de una consulta2

rs = st1.executeQuery("SELECT Nombre FROM usuarios WHERE


Nombre!='"+tf.getText()+"'");

if(rs.next())

52
{

JOptionPane.showMessageDialog(null, "El numero de serie no existe. No


puedes elegirlo", "Error", JOptionPane.ERROR_MESSAGE);

public static boolean validavacios (javax.swing.JTextField nom){

if(nom.getText().length() < 1)

JOptionPane.showMessageDialog(null, "faltan datos en los campos", "Error",


JOptionPane.ERROR_MESSAGE);

return false;

return true;

//METODO PARA VALIDAR CARACTERES DE ENTRADA

public static boolean validarcaracteres(javax.swing.JTextField caracter)

String CadenaAValidar=caracter.getText();

for(int i=0;i<CadenaAValidar.length();i++)

if((CadenaAValidar.charAt(i)<'0' || CadenaAValidar.charAt(i)>'9')&&
(CadenaAValidar.charAt(i)<'a' ||
CadenaAValidar.charAt(i)>'z')&&(CadenaAValidar.charAt(i)<'A' ||
CadenaAValidar.charAt(i)>'Z')&&CadenaAValidar.charAt(i)!=' ')

JOptionPane.showMessageDialog(null, "caracter invalido", "Error",


JOptionPane.ERROR_MESSAGE);

caracter.setText("");

return false;

53
}

return true;

public static boolean validarnumeros(javax.swing.JTextField caracter)

String CadenaAValidar=caracter.getText();

for(int i=0;i<CadenaAValidar.length();i++)

if((CadenaAValidar.charAt(i)<'0' || CadenaAValidar.charAt(i)>'9'))

JOptionPane.showMessageDialog(null, "caracter invalido", "Error",


JOptionPane.ERROR_MESSAGE);

caracter.setText("");

return false;

return true;

public static boolean validarlongitudes(javax.swing.JTextField caracter)

String CadenaAValidar=caracter.getText();

if(CadenaAValidar.length()>49)

JOptionPane.showMessageDialog(null, "Maxima Longitud=50 Caracteres",


"Error", JOptionPane.ERROR_MESSAGE);

return false;

54
}

return true;

public static boolean limpiarcampos(javax.swing.JTextField campo)

campo.setText("");

return true;

public static boolean validarcadenaliteral(javax.swing.JTextField caracter)

String CadenaAValidar=caracter.getText();

for(int i=0;i<CadenaAValidar.length();i++)

if((CadenaAValidar.charAt(i)<'a' ||
CadenaAValidar.charAt(i)>'z')&&(CadenaAValidar.charAt(i)<'A' ||
CadenaAValidar.charAt(i)>'Z')&&CadenaAValidar.charAt(i)!=' ')

JOptionPane.showMessageDialog(null, "Este campo no acepta caracteres


numericos", "Error", JOptionPane.ERROR_MESSAGE);

return false;

return true;

55
2.6.1.4 Pruebas.

Esta etapa se centra en los procesos lógicos internos del software, asegurando que todas
las sentencias se han comprobado, y en la detección de errores.

A continuación se muestra el formato del Plan Global de Proceso de Pruebas.

No. de documento:1

I.T.C.M. Revisión No.: 1


FECHA: TP-Global 1
Hoja: Página 1 de 27
27 de Abril de 2009
Proceso Global de Pruebas

PROPONE

_____________________

NOMBRE Y PUESTO.

REVISAN

_____________________ _____________________

NOMBRE Y PUESTO. NOMBRE Y


PUESTO.

AUTORIZA

_____________________

NOMBRE Y PUESTO.

56
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Proceso Global de Pruebas
Hoja: Página 2 de 27
27 de Abril de 2009

TP-Global
Plan Global de Proceso de Pruebas

57
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 3 de 27
27 de Abril de 2009

INTRODUCCIÓN

En este documento trataremos las distintas pruebas que se le aplicarán al sistema


de control de desecho Computacional del R. Ayuntamiento de Cd. Madero,
Tamaulipas, donde se especificará el objetivo del plan de pruebas para
posteriormente identificar el alcance del mismo, los módulos del sistema que se
probarán así como las estrategias a seguir para cada uno de ellos.

Especificaremos los recursos con que se debe contar al momento de realizar las
pruebas, para que no se presenten contratiempos técnicos y se respete la
calendarización especificada para las mismas.

Se analizarán los riesgos más comunes a los que se pudiera enfrentar el equipo
encargado de realizar las pruebas para que se tomen las medidas necesarias en
caso de algún incidente y se especificará las personas responsables del plan de
pruebas.

En caso de encontrar anomalías en el sistema durante el periodo de pruebas, se


notificará al equipo de desarrollo del software los errores encontrados para su
corrección y posteriormente se continuará con el desarrollo del plan de pruebas.

58
No. de documento:1

I.T.C.M.
Revisión No.: 1
FECHA:
TP-Global
Hoja: Página 4 de 27
27 de Abril de 2009 Plan Global de Proceso de

OBJETIVO

El objetivo principal del presente plan de pruebas es probar que cada módulo probado realice la
función deseada y esperada, y que cada uno de sus componentes esté funcionando
correctamente en cuanto a interfaz y funcionalidad.

Encontrar el mayor número de errores posibles en el software y así poder informar al equipo
encargado del desarrollo del mismo para que puedan hacer las correcciones pertinentes.

Las pruebas que utilizaremos en este caso para probar el software son las pruebas de:

 Caja blanca
 Caja negra
 Pruebas unitarias
 Pruebas de integración
 Pruebas de sistema
 prueba de recuperación
 prueba de seguridad
 prueba de resistencia

59
No. de documento:1

I.T.C.M.
Revisión No.: 1
FECHA: TP-Global
Hoja: Página 5 de 27
27 de Abril de 2009 Plan Global de Proceso de

ALCANCE

Como se mencionó anteriormente aplicaremos las pruebas de la caja blanca y la caja negra a
cada uno de los módulos del sistema que probaremos.

En esta etapa probaremos todos los módulos que componen nuestro software que son:

 Consultas.
 Registro de computadoras.
 Registro de componentes.
 Registros de usuarios.
 Equipo reensamblado.
 Mantenimiento.

Al realizar la prueba de la caja blanca nos enfocaremos en ver cómo funciona el código, es
decir como toma decisiones el sistemas, cómo reacciona al introducir valores inesperados,
etc.

Al realizar la prueba de la caja negra veremos cómo se comporta el sistema ya instalado y


funcionando, en esta prueba no veremos el código ya que supondremos que está en estado
óptimo y nos enfocaremos y guiaremos por la interfaz.

60
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 6 de 27
27 de Abril de 2009

ITEMS A PROBAR

En el sistema que se va a probar se observan los siguientes módulos, los cuales forman parte
del sistema control con el siguiente tipo de configuración:

*.-Consultas: se aplicarán por consulta de número de serie y por nombre de componente.


Requisitos mínimos para poner en marcha el plan en éste ítem: contar con registros en la
base de datos.

*.- Registro de computadoras: verificar que las inserciones se realizan correctamente con los
datos ingresados por el usuario. Requisitos mínimos para poner en marcha el plan en éste
ítem: Que en la base de datos esté la tabla Registro de computadoras.

*.- Registro de componentes: verificar que las inserciones se realizan correctamente con los
datos ingresados por el usuario. Requisitos mínimos para poner en marcha el plan en éste
ítem: verificar que no haya claves principales repetidas. Que en la base de datos esté la tabla
Registro de componentes.

*.- Registro de usuarios: verificar que las inserciones sean correctas y que la llave primaria del
nombre usuario no se repita. Requisitos mínimos para poner en marcha el plan en éste ítem:
que exista la tabla registro de usuarios esté en la base de datos.

*.- Equipo reensamblado: verificar que las inserciones sean correctas y que los datos sean
correctos para cada atributo. Requisitos mínimos para poner en marcha el plan en éste ítem:
que exista la tabla equipo re ensamblado esté en la base de datos.

*.- Mantenimiento: verificar que las inserciones sean correctas y que los datos sean correctos
para cada atributo. Requisitos mínimos para poner en marcha el plan en éste ítem: que exista
la tabla mantenimiento esté en la base de datos.

61
No. de documento:1
TP-Global
I.T.C.M.
Plan Global de Proceso de
Pruebas Revisión No.: 1
FECHA:
Hoja: Página 7 de 27
27 de Abril de 2009

ESTRATEGIAS.

Caja Negra:
Utilizaremos la técnica de la caja negra, en la cual especificaremos las entradas y
esperaremos los resultados arrojados por el sistema, los cuales serán evaluados y
comparados con los resultados esperados. Se probará el 80% de los módulos del sistema
puesto que varios de ellos utilizan la misma plantilla de programación, por lo que al probar y
estar seguros de que un módulo no tiene problemas, los demás similares a él, se pueden
considerar como correctos.

En cada módulo se utilizan campos muy similares en la captura de datos, por lo mismo, de los
campos similares que utilicen las mismas técnicas de programación sólo será evaluado uno,
esto en realidad representa un 60-65% del total de los campos del módulo. Si se presenta un
problema o error, o el resultado mostrado no es el que se esperaba, mandaremos el reporte
del error para que dicho módulo sea corregido, pero también será necesario revisar los
módulos similares, ya que podrían presentar el mismo error.

Caja Blanca:
Para evaluar cada módulo del sistema utilizaremos la técnica de los caminos ciclomáticos, es
decir exploraremos la mayoría de los posibles caminos que se podrían tomar durante cada
ejecución del sistema. Puesto que no se trata de un sistema en el que se puedan considerar
demasiados caminos, se tomará en cuenta para su evaluación el 100% de los mismos, que
principalmente radican en algunas validaciones y autentificaciones del sistema.

Unitarias:
Para la realización de la prueba de unidad, se tomará cada módulo como una unidad
independiente a la que se analizará tanto su interfaz como su estructura interna. Se probará
serán los campos de datos que llevan la información hacia la base de datos. Se evaluarán los
tipos de datos gráfica, su alineación, información que brinda con las acciones
del mouse, etc.
62
No. de documento:1

I.T.C.M.
TP-Global Revisión No.: 1
FECHA:
Plan Global de Proceso Hoja: Página 8 de 27
27 de Abril de 2009
de Pruebas

Posteriormente, se analizarán las estructuras de datos que se utilizan en dicho módulo tales
como vectores y matrices entre otras, también se evaluarán sus límites y su recuperación ante
errores y por último, se evaluarán las condicionales y los diversos caminos que contemplen el
manejo de errores del sistema, así como los avisos de advertencia, información o error que
deben ser visibles para el usuario final.

Integridad
Dentro de las variantes posibles para la prueba de integración, hemos decidido aplicar la
técnica de la integración descendente, ya que se acopla al proceso de desarrollo de software
utilizado, en el cual primero se desarrolló la estructura del sistema, y posteriormente se
desarrollaron los componentes que interactúan directamente con el usuario.

Comenzaremos por evaluar los módulos de mayor jerarquía dentro del diagrama del sistema,
que en este caso se trata del módulo que sirve de conexión entre el sistema y la base de
datos. Posteriormente se analizarán los módulos de inicio de sesión y de configuración, que
son los que almacenan y verifican los datos para el correcto funcionamiento del sistema y por
último se probarán los módulos de altas, bajas y cambios, que forman parte de los módulos
subordinados de los anteriores.

Sistema
Dentro de las pruebas de sistema, debemos tomar en cuenta varios tipos:

 Pruebas de Recuperación
 Pruebas de Seguridad
 Pruebas de Rendimiento

Para llevar a cabo las pruebas de recuperación, forzaremos a que el sistema falle, ya sea por
conexión a la base de datos, error en el tipo de dato introducido, respaldo y restauración de la
base de datos.

63
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 9 de 27
27 de Abril de 2009

Volumen
Para llevar a cabo las pruebas de volumen, deberemos sobrecargar la base de datos para que
el sistema interactúe con mucha información, como por ejemplo ingresar nombres o valores
que exceden el límite permitido por los campos de las tablas. También podemos incluir una
gran cantidad de registros en la base de datos para que sean tratados por el sistema.

Estrés
Para la realización de la prueba de estrés, trataremos de “romper” la ejecución de la
aplicación, una de las formas es probar sobrecargando el número de usuarios que se
conectan al mismo tiempo a la base de datos, o también podemos intentar hacer que varios
usuarios intenten acceder a la misma información al mismo tiempo.

Performance
Para la realización de las pruebas de performance (Rendimiento), también sobrecargaremos
la base de datos del sistema, pero en esta ocasión mediremos la velocidad de respuesta
cuando varios usuarios intentan acceder a gran cantidad de información. En caso de que el
sistema no sea capaz de operarse bajo estas circunstancias, verificaremos la forma en que se
advierte al usuario acerca de esta situación, así como la recuperación de este error.

Configuración
Para llevar a cabo las pruebas de configuración, modificaremos y trataremos con
configuraciones extraordinarias para el sistema y probaremos su funcionamiento tanto de
performance como de volumen. Por ejemplo, en el módulo de configuración podemos ingresar
direcciones IP (para el manejo en red) erróneas y verificar la recuperación ante este tipo de
errores.

64
No. de documento:1
TP-Global
I.T.C.M.
Plan Global de Proceso de
Pruebas Revisión No.: 1
FECHA:
Hoja: Página 10 de 27
27 de Abril de 2009

ESTRATEGIAS.

*.- Para las pruebas que se realizarán al módulo de consultas, se realizará el ejercicio de los
caminos ciclomáticos, para cada uno de los comandos SQL que se realizarán.

Dado el conjunto de instrucciones reducido de éste módulo se revisará el 100% de los


caminos ciclo máticos. Además se le aplicará la prueba de caja negra para verificar que los
resultados de la consulta solicitada sean adecuados.

*.- Estrategias para las pruebas que se realizarán a los módulos de registro de componentes,
registros de usuarios, equipo reensamblado y mantenimiento: Dado que estos módulos no
utilizan ningún ciclo, no se realizarían pruebas de complejidad ciclomáticas. Por tanto las
pruebas a realizar serían sólo para enfoque de las demás pruebas enlistadas en puntos
anteriores, validando que el registro toda su funcionalidad se efectúe de forma correcta.

65
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 11 de 27
27 de Abril de 2009

CATEGORIZACIÓN DE LA CONFIGURACIÓN:

- Suspendido: la ejecución del plan de pruebas se va a suspender en el caso de que


surja un error, en la bitácora se registrará el error, documentando las condiciones
actuales que suscitaron el error, con la fecha, hora, usuario y descripción del
problema.

Las pruebas también podrán ser suspendidas por condiciones especiales tales como:

 Fenómenos naturales (tormentas, terremotos, etc.)


 Incendios
 Fallas eléctricas
 Fallas en la red
 Virus
 Fallas en el hardware

Al presentarse alguna de las condiciones especiales del tipo de fenómenos naturales se


respaldará la información en su mayor medida posible, se desconectarán los equipos,
resguardándolos.

En caso de un incendio se intentará salvar los equipos siguiendo las medidas de seguridad
indicadas. Al presentarse una falla en el suministro eléctrico, recurrir a los respaldos una vez
que la energía eléctrica se haya normalizado. Si se pierde la comunicación con el servidor
(falla en la red) se suspenderán las pruebas hasta lograr la conexión nuevamente. La
problemática de virus, se considera que no se presentará ya que será probado bajo la
plataforma de Linux. En caso de falla del hardware en el que se esté probando actualmente,
se procederá a seguir con las pruebas de un equipo computacional adicional.

66
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 133 de 27
27 de Abril de 2009

- Repetido: Una vez que se hayan verificado y corregido los errores detectados en el
plan de pruebas, éste se reanudará, tomando en cuenta la bitácora, para poder comenzar las
pruebas en el módulo en el que se encontró el error.

- Culminado: Se ha culminado el proceso de pruebas cuando no se ha detectado


errores en ninguno de los módulos y los resultados sean los correctos y esperados.

TANGIBLES.

Los documentos que se entregarán al culminar el proceso de pruebas serán los siguientes:

 Especificación de prueba
 Casos de prueba
 Bitácora de prueba

67
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 13 de 27
27 de Abril de 2009

PROCEDIMIENTOS ESPECIALES.

Inicio

Realizar la
documentación de
pruebas

Revisión del plan


de pruebas

Entrenamiento de
los usuarios del
sistema

Implementación
parcial del código

Ejecución de las
pruebas sobre los
módulos creados

Fin

68
No. de documento:1

I.T.C.M.
TP-Global Revisión No.: 1
FECHA:
Plan Global de Proceso Hoja: Página 14 de 27
27 de Abril de 2009
de

RECURSOS PARA IMPLEMENTAR ELPLAN DE PRUEBAS

Para la puesta en marcha del plan de pruebas sobre el sistema desarrollado será necesario
como condiciones mínimas para efecto:

Una computadora con las siguientes características:

Disco duro: 20 GB

Memoria RAM: 128 MB

Procesador: 512 MHz.

Sistema operativo: Windows/ EduLinux (preferentemente)

Además será necesario considerar las condiciones de los puntos anteriores lo mas a la letra
posible para probar inicialmente sobre condiciones ideales.

Las pruebas iniciales podrán realizarse fuera del entorno de trabajo del sistema en este caso
será probado en el entorno de desarrollo en el sistema operativo Windows XP en un hardware
con las siguientes características:

Disco duro: 120 GB

Memoria RAM: 1GB

Procesador: 2 GHz

Sistema operativo: WindowsXP

69
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 15 de 27
27 de Abril de 2009

Disco Duro: 40 GB

Memoria RAM: 1GB

Procesador: 1.8 GHz

Sistema operativo: Windows XP

Será requerido el uso y la prueba de almacenamiento en CD para el respaldo de la base de


datos control y una impresora para la impresión de reportes.

En el entorno de trabajo del sistema para su puesta en marcha serán necesarias las siguientes
condiciones para la fase de pruebas

3 Computadoras en red para las siguientes funciones:

1 servidor con las siguientes características:

Disco duro: 120 GB

Memoria RAM: 512MB a 1Gb

Procesador: 512 a 1GHz como mínimo

Sistema operativo: EduLinux

70
No. de documento:1

I.T.C.M.
TP-Global Revisión No.: 1
FECHA:
Plan Global de Proceso Hoja: Página 16 de 27
27 de Abril de 2009

En el entorno de trabajo del sistema para su puesta en marcha serán necesarias las
siguientes condiciones para la fase de pruebas

3 Computadoras en red para las siguientes funciones:

1 servidor con las siguientes características:

Disco duro: 120 GB

Memoria RAM: 512MB a 1Gb

Procesador: 512 a 1GHz como mínimo

Sistema operativo: EduLinux

2 Computadoras terminales:

La primera será para el registro de los componentes y las computadoras que son recibidas.

La segunda seria para la consulta de los componentes ya registrados.

Ambas computadoras deberán tener como características mínimas las siguientes:

Disco duro: 20 GB

Memoria RAM: 128 MB

Procesador: 512 MHz.

Sistema operativo: EduLinux (preferentemente) También será requerido en la red un servidor


de impresión para los reportes. Y Cd´s para el respaldo de la información de la base de datos
control.

71
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 17 de 27
27 de Abril de 2009

Evidentemente será requerido el software de la impresora empleada que sea del modelo que se
está utilizando y de no ser así el mas similar posible a la marca empleada.

Serán necesarias como mínimo dos personas, una para el registro y manejo del servidor y la
otra para el manejo de las consultas (lo ideal 3 o 4). El tiempo estimado para las pruebas será
el periodo del 27 al 30 de abril de 2009 y de 6 al 7 de mayo de 2009.

CALENDARIO.

Un calendario de las actividades completas del sistema se encuentra anteriormente descrito


mediante un diagrama de Gantt, a continuación se muestra una tabla donde únicamente se
calendarizaron las fechas asignadas a pruebas.

72
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 18 de 27
27 de Abril de 2009

MANEJO DE RIESGOS.

Algunos de los riesgos que se podrían presentar durante el plan de pruebas es la falta de
equipo necesario para llevarlas a cabo, es decir que no se cuente con el hardware cuyas
características sean las requeridas, las acciones mitigantes y de contingencia que se
proponen es documentar la problemática y proseguir con el plan hasta que se cuente con el
equipo necesario. Otro riesgo potencial es el lugar y espacio deseable para llevar a cabo el
plan, que el acondicionamiento del lugar tenga el espacio necesario y las condiciones
deseables en cuanto a ventilación, iluminación y conectores de electricidad necesarios para
conectar todos los equipos. Si no se cuentan con dicha facilidad del lugar se hará una prueba
piloto solo probando los módulos del sistema en un solo equipo (Pc). Otro riesgo de suma
importancia es que no se cuente con la instalación adecuada de la red, en caso de ser así, se
procederá a realizar la acción de contingencia propuesta para el riesgo anterior, hasta que se
cuente con la red deseable.

RESPONSABLES.

Las personas responsables de la ejecución de las pruebas previstas en el plan será un grupo
de trabajo asignado de acuerdo a un sorteo grupal.

73
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 19 de 27
27 de Abril de 2009

DISEÑO DE PRUEBAS ESPECÍFICAS.

Pruebas unitarias: se llevaran a cabo a cada uno de los módulos antes mencionados.

Objetivo: que el módulo probado realice la función deseada, y que cada uno de sus
componentes este funcionando correctamente en cuanto a interfaz y funcionalidad.

*.- Interfaz: nombre de los campos correctos.

*.- Funcionalidad: que acepte datos adecuados y arroje resultados esperados y correctos.

**.-Módulo de consultas:

Técnica: en el modulo de consultas el enfoque para el diseño de este caso de prueba será el
enfoque funcional o de caja negra, para verificar que los resultados de la consulta sean los
esperados ya sea por nombre de componente o numero de serie, también se recomienda
realizar los caminos ciclomáticos para cada comando de SQL que se tienen en el modulo.

Consideraciones especiales: que la base de datos cuente con registros, para poder realizar la
prueba en este modulo. También se debe tener establecida la conexión Sistema-BD.

Casos de prueba: una vez establecidos correctamente las consideraciones especiales para
efectuar esta prueba, se realizaran las consultas eligiendo cada una de las opciones que
ofrece la interfaz para verificar que las consultas se realicen como se espera por número de
serie o por nombre de componente.

74
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 330 de 27
27 de Abril de 2009

Criterios de evaluación: la prueba será aprobada si los resultados son los esperados, es decir
si las dos opciones de consulta arrojan los resultados correctos, en caso contrario, la prueba
será rechazada.

Supuestos: alguna de las consideraciones especiales que no estén en el estado requerido.


Que no se cuente con las herramientas necesarias en cuanto a hardware y software
mencionados en el punto 8 del plan de pruebas.

*.-Módulo de Registro de componentes, registro de computadoras, registro de usuarios;


equipo Reensamblado y Mantenimiento:

Técnica: en este módulo se aplicara el enfoque funcional o de caja negra, validando y


verificando que las inserciones sean las correctas de acuerdo al tipo de longitud de los datos.

Consideraciones especiales: las tablas y registros en las bases de datos, establecida la


conexión del sistema con las bases de datos.

Casos de prueba: verificar cada uno de los campos en cada módulo que funcione como se
espera, introduciendo los datos del tipo y longitud indicados en el documento de pruebas,
validando que funcionen correctamente, que las inserciones se lleven a cabo y que los datos
sean los correctos para cada atributo.

75
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 331 de 27
27 de Abril de 2009

Criterios de terminación: la prueba será aprobada si los resultados de los casos de pruebas son
exitosos, es decir de cada uno de los módulos probados realizan inserciones concretas, y si se
cumplen todas las validaciones necesarias para cada atributo.

Supuestos: alguna de las consideraciones especiales que no estén en el estado requerido. Que
no se cuente con las herramientas necesarias en cuanto a hardware y software mencionados en
el plan de pruebas.

76
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 332 de 27
27 de Abril de 2009

Prueba de integración: se aplicará la integración no incremental, ya que es la prueba de unidad


se propone probar cada modulo por separado: (Módulo de consultas, Módulo de Registro de
componentes, registro de computadoras, registro de usuarios; equipo Reensamblado y
Mantenimiento:) y posteriormente se integra todo de una vez para probarse el programa completo.

Esquema:

Registro

Consulta

Registro de Registro de Registro de Equipo Mantenimiento


Computadoras Componentes Usuarios Reensamblado

Objetivo: que el módulo probado tengo una coherencia en cuanto a interfaz, datos y orden que
posee un modulo con otro una vez integrados todos los módulos.

Técnicas: Se probará la funcionalidad de la interfaz, los atributos correctos y la funcionalidad de


cada botón y de cada campo de los módulos en conjunto ya integrados.

77
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 333 de 27
27 de Abril de 2009

Consideraciones especiales: que los módulos estén integrados en un solo software y que
estén en condiciones ideales, es decir que tengan conexión con la base de datos, que todos
sus atributos tengan nombres claros y únicos para facilitar al usuario el ingreso de datos.

Casos de prueba: verificar que cada atributo de la interfaz corresponda al campo indicado, y
que la secuencia de los módulos e interfaces correspondan al esquema de software según el
tipo de integración elegida.

Criterios de terminación: la prueba será aprobada solo si los módulos una vez integrados
siguen trabajando de manera correcta como se espera, que cada modulo tenga la relación y
secuencia esperada en el software.

Supuestos: alguna de las consideraciones especiales que no estén en el estado requerido.


Que no se cuente con las herramientas necesarias en cuanto a hardware y software
mencionados en el plan de pruebas.

78
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 334 de 27
27 de Abril de 2009

Prueba de sistema

Prueba de recuperación

Objetivo: verificar que al presentarse algún fallo, o al cerrarse el sistema de una forma no
esperada la recuperación se efectúe apropiadamente.

Técnicas: comprobar que el archivo en Excel (extensión.xls) fue generado y que coincidan con
las tablas del sistema.

Consideraciones especiales: cada vez que se cierre el sistema y que se realice alguna
actividad de modificación en alguna de las tablas del sistema se realizara la técnica antes
mencionada. La carpeta de ubicación con los archivos de recuperación se encuentra en la
misma dirección donde seta instalado el sistema.

Casos de prueba: se iniciara el sistema, se agregaran datos y enseguida se cerrara el sistema


para posteriormente buscar la ubicación de la carpeta para verificar que se generaron los
archivos de recuperación.

Criterios de determinación: la prueba será aprobada si los archivos de Excel son generados
automáticamente.

Supuestos: alguna de las consideraciones especiales que no estén en el estado requerido.


Que no se cuente con las herramientas necesarias en cuanto a hardware y software
mencionados en el plan de pruebas.

79
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 335 de 27
27 de Abril de 2009

Prueba de seguridad:

Objetivo: que el sistema cumpla con las normas de seguridad para prever el mal uso del
sistema.

Técnicas: verificar que el nombre de usuario coincida con la contraseña, que el usuario se
encuentre dado de alta en la base de datos. Al tercer intento de contraseña errónea el sistema
se cierra automáticamente.

Condiciones especiales: inicialmente el único usuario que estará registrado en la base de


datos será el usuario Administrador con contraseña Administrador para permitir agregar a
otros usuarios.

Casos de prueba: el usuario administrador agregara a mas usuarios y se probara que estos
tengan acceso al sistema según su contraseña y nombre de usuario dada.

Criterios de determinación: la prueba será aprobada si los casos de prueba resultan ser
exitosos.

Supuestos: alguna de las consideraciones especiales que no estén en el estado requerido.


Que no se cuente con las herramientas necesarias en cuanto a hardware y software
mencionados en el plan de pruebas.

80
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Pruebas Hoja: Página 336 de 27
27 de Abril de 2009

Prueba de resistencia:

Objetivo: que la capacidad del sistema propuesta o requerida sea real para las características
de los equipos.

Técnicas: realizar un grupo de inserciones de gran volumen en todos los módulos del sistema,
el caso ideal es llegar hasta el tope de las unidades de almacenamiento para que los
resultados de las pruebas sean más confiables.

Condiciones especiales: que en la base de datos se cuente con registros y que las inserciones
se realicen adecuadamente para poder agregar más registros.

Supuestos: alguna de las consideraciones especiales que no estén en el estado requerido.


Que no se cuente con las herramientas necesarias en cuanto a hardware y software
mencionados en el plan de pruebas.

81
No. de documento:1

I.T.C.M.
TP-Global
Revisión No.: 1
FECHA: Plan Global de Proceso de
Hoja: Página 337 de 27
27 de Abril de 2009 Pruebas

Prueba de aceptación:

Objetivo: comprobar que el software es efectivamente lo que el cliente esperaba, que cumpla
con todos los requisitos funcionales que fueron requeridos.

Técnicas: enlistar los errores encontrados y contabilizarlos, igualmente contabilizar las


pruebas aprobadas.

Condiciones especiales: Haber realizado en su totalidad las pruebas.

Casos de prueba: una vez enlistados y contabilizados los errores y las pruebas aprobadas se
determinara el porcentaje de aprobación en cuanto a los resultados obtenidos o reales contra
los resultados que se esperaban.

Criterios de determinación: la prueba será aprobada si las pruebas realizadas al sistema


anteriormente fueron exitosas en su totalidad y cumple con los requerimientos del cliente.

Supuestos: Que no se cuente con las herramientas necesarias en cuanto a hardware y


software mencionados en el plan de pruebas. Y que no se llevaron a cabo las pruebas
previstas en el plan.

82
Anexos. Diagrama de Pert.

Diagrama de Gantt.

83