UNIVERSIDAD ADVENTISTA DE BOLIVIA FACULTAD DE INGENIERA CARRERA EN SISTEMAS

PLAN DE EVALUACION DE TESTEO.

SISTEMA DE MANEJO DE CONTENIDOS (CMS) PARA LA GESTIN, DIFUSIN Y VENTA DE CELULARES

Carrera Ingeniera de Sistemas

Por: Juan Eduardo Salazar Zambrana. Elias Goitia Cuellar. Remberto San Martin Suarez.

Catedrtico: Ivo Alberto Alabe.

2012

1. Identificador del plan de testeo. Se proceder a realizar los diferentes casos de pruebas al software CMS CellPhone.

2. Introduccin. La telefona mvil es una tendencia que crece cada da que pasa, por en cuanto la venta de celulares y sus accesorios crece de manera exponencial y para ese tipo de negocio la publicidad es un factor muy importante y sea por los distintos medios como ser peridicos, afiches y televisin y la accesibilidad a la informacin es muy importante como ser catlogos de los productos y accesorios disponibles para cada celular. Tambin es importante saber las caractersticas de los celulares es muy importante al momento de adquirir un celular. La mejor manera para satisfacer estas dos necesidades, podra ser una aplicacin web que aparte de las satisfacer dicha necesidades mencionadas anteriormente, nos puede brindar ms beneficios como ser la posibilidad de gestionar los productos, realizar reservas y ventas y muchas ms beneficios. La mercadotecnia en internet es un componente del comercio electrnico. Puede incluir la gestin de contenidos, relaciones pblicas, el servicio al cliente y las ventas. El comercio electrnico y la mercadotecnia en internet se han vuelto ms populares en la medida en que los proveedores de internet se estn volviendo ms accesibles. Ms de un tercio de los consumidores que tienen acceso a internet en sus hogares afirman haber utilizado internet como medio para realizar sus compras. El comercio electrnico, tambin conocido como e-commerce (electronic commerce). Consiste en la compra y venta de productos y servicios a travs de medios electrnicos, tales como internet y otras redes informativas. La cantidad de comercio llevado a cabo electrnicamente ha crecido de manera extraordinaria debido al internet. Una gran variedad de comercio se realiza de esta manera, estimulando la creacin y utilizacin de innovaciones como la transferencia de fondos electrnicos.

El comercio electrnico puede utilizarse en cualquier entorno en el que se intercambien productos o servicios. Se puede utilizar en la compra, adquisicin, finanzas, transporte, salud y en la recoleccin de impuestos. Las compaas que utilizan el comercio electrnico lo utilizan para desarrollar los siguientes aspectos:

Implantacin de un canal de marketing y ventas. Acceso interactivo a catlogos de productos, lista de precios y folletos publicitarios. Venta directa e interactiva de productos a los clientes. Soporte tcnico ininterrumpido, permitiendo que los clientes encuentren por s mismos y fcilmente las respuestas a su problemas mediante la obtencin de lo que buscan.

3. Elementos de testeo. 3.1. Identificacin de elementos de prueba. Las diferentes pruebas de software que se realizaran en esta fase del ciclo de vida permitir garantizan la entrega a produccin de una aplicacin con un nmero mnimo de fallas o con ninguna falla de error, aumentando la confiabilidad en las reas de desarrollo y la satisfaccin del cliente o del usuario (s), los elementos que se tomaran en cuenta para el test, sern los siguiente:

3.1.1. Funcionalidad Este se enfoca en verificar si el software cumple con las especificaciones aprobadas a travs de la utilizacin de una amplia variedad de escenarios que incluyen rangos de entradas normales y errneas, testing de interfaz.

Se asegura el trabajo apropiado de los requerimientos funcionales, incluyendo la navegacin, entre datos, procesamiento y obtencin de datos. En estas pruebas son:

Tareas 1

Descripcin

Verificar el procesamiento, recuperacin de las funcionalidades.

Verificar la aceptacin de los datos.

Para este apartado se utilizara la prueba de caja negra. Se ejecuta cada caso de uso, flujo de casos de uso o funcin, usando datos validos e invlidos, para verificar lo siguiente:

Tareas 1

Descripcin

Que los resultados esperados ocurran cuando se usen datos vlidos.

Que sean desplegados los mensajes de error y precauciones cuando se usan datos invlidos.

3.1.2. Fiabilidad.

3.1.3. Usabilidad. Es la facilidad con que las personas pueden utilizar una herramienta en particular, la usabilidad La prueba de usabilidad se realizara con usuarios finales con una porcin del sistema terminado y al finalizar con el sistema terminado. Se desarrollador un tipo de pruebas con dos personas una seria el comprador en la tienda virtual y el usuario administrador que se encargara de la gestin de los producto.
Tareas Pudo registrar los productos? Descripcin Usuario

Si el usuario pudo registrar los productos sin ningn problema

Administrador

Logro gestionar la

Si el usuario pudo por su

Administrador

publicidad sin ningn problema Encontr que buscaba?

propia cuenta gestionar la publicidad Si el usuario pudo encontrar lo que estaba buscando por su propia cuenta Cliente

Logro realizar la venta?

Si el usuario logro comprar algo sin ningn inconveniente

Cliente

Los link fueron de ayuda en su bsqueda

Si los link que estn en la pgina principal del sitio web fueron de ayuda

Cliente, Administrador

3.1.4. Eficiencia. 3.1.5. Mantenibilidad. 3.1.6. Portabilidad.

3.2. Requerimientos de hardware. En cuanto a requisitos o requerimientos hardware, se detallan lo mnimo que el sistema debe de tener el computador para el desarrollo del software y del testeo, que son: SO Windows Xp/Vista/Seven. Tarjeta Madre Asrock. 1 Gb de Memoria RAM. Disco duro de 200 Gb o ms. Unidad de Cd ROM / DVD Tarjeta de Red. Tarjeta de Video. Monitor Samsung u otro Teclado Mouse

3.3. Referencias de documentacin. 3.3.1. Caso de uso general.

3.3.2. Especificacin del caso de uso.

Especificacin de caso de uso: Ingresar al sistema. ID Nombre Descripcion Autor Fecha de creacin Autores Precondiciones Pos condiciones ECU_IS-01. Ingresar usuario. Permitir accedo al usuario. SRGSGP. Martes, 10 de abril de 2012 Administrador Sistema correctamente instalado. Ingreso de acceso realizado. Fecha de modificacin.

Flujo normal de eventos Validar: 1. El actor hace clic en el icono del sistema. 2. El sistema ingresa y permite el acceso. 3. Una vez accedido, el sisma muestra el tablero de opciones. Flujos alternos Acceso no correcto: En el paso 1 del Flujo normal, si el usuario no hace doble clic en el icono, entonces no podr acceder al sistema de manera correcta. Acceso correcto: En el paso 1 del Flujo normal, si el usuario accede al sistema de manera correcta, el sistema le da la bienvenida, y le invita que acceda a la gua que permite ver, las funcionalidades del sistema. Excepciones Si el usuario desea no se le d una gua por el sistema, entonces se le da la opcin de deshabilitar la gua. Referencias Anotaciones Solo se acceder al sistema personal autorizado para el control.

3.3.4. Gua de operaciones. Dentro del manual contendr las descripciones de actividades que deben seguirse en la realizacin de las funciones de una unidad administrativa dentro del software, o de dos ms de ellas. Contendr informacin y ejemplos de formularios, autorizaciones o documentos necesarios, mquinas o equipo de oficina que se deben de utilizar para que el software tenga un correcto desarrollo de las actividades.

3.3.5. Gua de instalacin. Este contendr las especificaciones de instalacin del software, en nuestro caso, ya que se trata de una pgina web que se encontrara alojada en un servidor, se explicara en breve como se accede a la pgina.

4. Caractersticas de ser testeado. Las caractersticas que se van a proceder a testar son las siguientes: Pruebas del CRUD de la base de datos en general: se testeara todas las tablas de la base de datos con las operaciones de crear, leer, actualizar y eliminar. Pruebas del envi de publicidad al correo electrnico: al momento de que el usuario se registre nos indicara sus preferencias entonces el sistema le mandara un mensaje a su correo electrnico con los productos que se tenga de acuerdo con sus preferencias ya mencionadas. Pruebas de registro de usuario: se testeara el registro de usuario y la verificacin del cdigo de activacin que se envi a su correo.

5. Caractersticas de no ser testeado. Todas ya mencionadas en el inciso anterior se reflejaran en este inciso, si no fuesen testeadas o probadas, el rendimiento de cada parte (BD, Cdigo, HTTP, estrs, carga, validacin) seria bajo y de poca confianza e inseguro para su uso.

6. Enfoque. 6.1. Enfoque general de la prueba. El enfoque general que se tiene para la realizacin de testeo del software es para identificar la correctitud, completitud, seguridad y calidad en el desarrollo de un software.

Dentro de este proceso se emplearan tcnica, mtodos y herramientas para poder tener un buen software.

6.2. Especificacin de herramientas de testeo. Ya que el software en una pgina web, se proceder a la obtencin de herramientas que nos permitan testear pginas web, dentro de estas herramientas, la que se utilizaran para la obtencin de un buen sistema, son: J-Meter: Esta es una aplicacin de escritorio, es un software de cdigo abierto, una aplicacin diseada para cargar el comportamiento de pruebas funcionales y medir el rendimiento. Es una aplicacin portable, que permite carga y rendimiento de muchos tipo de diferentes servidores: Web - HTTP, HTTP, SOAP, Database va JDBC, LDAP, JMS, Mail - SMTP(S), POP3(S) and IMAP(S). Validator W3C: Esta herramienta nos permitir comprobar la validez de marcado de documentos Web en HTML etc. Si se desea validar el contenido especfico, como feeds RSS / Atom o de hojas de estilo CSS o para encontrar enlaces rotos. BrowserShots: Este software nos permite testear la compatibilidad que se tendr al acceder de diferentes navegadores a nuestra pgina, es de licencia gratis, funciona en todos los navegadores, funciona en los OS de Windows, Os x y Linux. Permite Java, Flash, Javascript, y pruebas de profundidad de color.

6.3. Especificacin de herramientas de tcnicas o mtodos. Un unit test es un mtodo que prueba una unidad de cdigo, Unit Testing Framework: Brinda estado real de la aplicacin, ayuda a detectar bugs (mas cdigo hecho bien, menos ciclos de testing), contribuye a la calidad del

cdigo (Cdigo probado, cdigo que se ejecuta realmente, trazabilidad de requerimientos), anticipa problemas (integracin), este apoya las pruebas unitarias en Visual Studio.

7. Criterios de los elementos si pasa o no pasa. Las pruebas de los mdulos en general se consideraran aprobadas cuando: Todas las pruebas planificas se hayan ejecutado exitosamente. Todos los defectos identificados se han considerado. Todos los procedimientos y mtodos funcionan como se disearon y sin ningn error en los datos. El resultado de la realizacin de cada procedimiento quedara documentado en un informe de prueba. En caso de deteccin de algn error o anomala en los resultados arrojados, se dar el respectivo caso de prueba como NO aprobado, lo que ser registrado en el informe de la prueba, y se proceder a la solucin del problema, que estar a cargo del programador. Para dar al mdulo o componte por aprobado, procedimiento respectivo (ms de uno eventualmente) deber tener aprobados todos los casos de prueba que lo componen, y cada requisito deber ejecutarse exitosamente por lo menos una vez.

Al final de la etapa de prueba, se debe asegurar que las actividades de verificacin cumplen con: Satisfacer los requisitos sobre pruebas de aceptacin y verificacin establecidas en este documento. Verificar que el producto satisfaga al cliente. Ser suficientes para asegurar la calidad del producto.

8. Criterios de suspensin y reanudacin de Requerimientos. El software despus de ser testeado entrar o pasar a la etapa de integracin, despus de que todos los defectos crticos han sido corregidos, el software podra presentar algn error, pero este debe de ser menor, este error no debe de representar una obstaculizacin al desarrollo o trabajo del software y aun as no se suspender la prueba, despus de la prueba

se proceder a la correccin o dentro de la misma prueba, se irn corrigiendo los errores suscitados. El software entrar a la prueba de aceptacin, despus de que todos los errores representados en las pruebas se hayan corregido.

9. Entregas de prueba Las pruebas de entregas son el proceso de probar una entrega del sistema distribuida a los clientes. El principal objetivo de este proceso es incrementar la confianza del cliente en que el sistema satisface sus requerimientos.

Para demostrar que el sistema satisface sus requerimientos, se realizaran entregables de la funcionalidad del sistema como ser: funciones especificas, rendimiento, confiabilidad y que no falla durante su uso normal. Para ella se proceder a la muestra de resultados estadsticos, los cuales se pueden obtener mediante herramientas de testeo, que permiten la obtencin de graficas que determinan la funcionalidad del sistema.

Los datos de prueba de entrada y salida de datos de prueba deben ser identificados como los resultados finales. Los instrumentos de ensayo (por ejemplo, los conductores del mdulo y talones) tambin pueden ser incluidos

10. Tareas de prueba.

Tareas Tareas predecesora Habilidades especiales Responsabilidad Esfuerzo Fecha finalizacin

1. Preparar plan de testeo

Sistema de catlogo y venta a un 90% Tarea (1)

2. Preparar las especificaci ones del diseo de pruebas 3. Preparar las especificaci ones de caso de prueba 4. Preparar especificaci ones del procedimie nto de prueba 5. Ingresar los primeros datos al sistema (test) 6. Completar la prueba de transmisin de datos 7. Revisar resultados, verificar que todo est listo para ejecutar test 8. Todos los datos se

Conocimiento de las funcionalidade s principales del sistema Conocimiento del manejo de una tienda en lnea

Test manager, analista

11/06/2012

Analista de test

21/06/2012

Tarea (2)

Analista de test

26/06/2012

Tarea (3)

Analista de test

30/06/2012

Tarea (4)

Conocimiento del flujo de datos de la tienda -

Analista de test

05/07/2012

Tarea (5)

Analista de test

09/07/2012

Tarea (6)

Experiencia testeo unitario

Tcnico de test

12/07/2012

Tarea (7)

Tcnico de test

13/07/2012

ingresaron en la base de datos 9. Revisar los resultados del test 10. Resolver incidentes del test

Tarea (8)

Analista de test

15/07/2012

Tarea (9)

11. Reiniciar las tareas 5 al 10 12. Escribir informe de las pruebas del sistema 13. Pasar todos los documento s grupo de administra cin del proyecto

Tarea (10)

Conocimiento del funcionamient o interno del sistema -

Grupo de desarrollo, grupo de testeo,

16/07/2012

17//07/2012

Tarea (11)

Grupo de test

18/07/2012

Tarea (12)

Grupo de test

18/07/2012

11. Necesidades del medio ambiente. Los siguientes elementos son necesarios para apoyar el esfuerzo global de las pruebas en todos los niveles dentro del proyecto: 11.1. Recursos hardware 11.1.1. Administrador. SO Windows server 2008 Tarjeta Madre Asrock. 2 Gb de Memoria RAM. Disco duro de 200 Gb o ms. Unidad de Cd ROM / DVD Tarjeta de Red. Tarjeta de Video.

Monitor Samsung u otro Teclado Mouse

11.1.2. Cliente (s). Un cliente podra contar con una computadora es escritorio, que cuente con las siguientes caractersticas mnimas, para que la pagina web corra sin problema. SO Windows 97/Xp/Vista/Seven/Linux/Mac Tarjeta Madre Asrock. 1 Gb de Memoria RAM. Disco duro de 200 Gb o ms. Unidad de Cd ROM / DVD Tarjeta de Red. Tarjeta de Video. Monitor Samsung u otro Teclado Mouse

Por otra parte, un cliente podra acceder a la pgina web mediante algn dispositivo PDA, Tableta u telfono celular al sitio web, ya sea que tenga los siguiente OS.

Android Symbian IOS U otros, que soporten el uso de internet y su browser soporte la aplicacin.

11.2. Recursos de Software: Visual Studio 2010 (Desarrollo del proyecto) SQL Server 2008 o 2005 (Base de datos) Microsoft Proyect (Gestin del proyecto) Apache J-Meter (Test Stress) Validator W3C (Comprobar validez HTML, CSS) BrowserShots (Compatibilidad con diferentes navegadores) Unit Testing Framework (Detecta bugs) y modo de uso: Stand Alone

12. Responsabilidades. 12.1. Grupo responsable. La persona responsable del desarrollo de software es: Juan Eduardo Salazar.

12.2. Grupo de diseo. El encargado del diseo del test del plan es: Remberto San Martin Suarez.

12.3. Grupo de preparacin. La preparacin del software para el testeo ser todo el equipo: Juan Eduardo Salazar Zambrana. Elias Goitia Cuellar. Remberto San Martin Suarez.

12.4. Grupo de ejecucin. El encargado de ejecucin del testeo es: Elias Goitia Cuellar.

12.5. Grupo de preparacin. Dentro de este punto, se prepara un ambiente para el testeo del software.

13. Dotacin de personal y las necesidades de capacitacin. Es preferible que haya por lo menos una persona de testador asignado de tiempo completo al proyecto del sistema para la fase de integracin y pruebas de aceptacin del proyecto.

Esto requerir la asignacin de una persona de tiempo parcial en el inicio del proyecto para participar en las revisiones, aproximadamente cuatro meses que durara el desarrollos del sistema se asignara una persona de tiempo completo, si una persona encargada de las pruebas no est disponible, el director del proyecto o director de pruebas asumir esta funcin.

A fin de proporcionar una prueba completa y correcta las siguientes reas deben ser abordadas en trminos de informacin.

Los desarrolladores y testeadores debern estar capacitados en las operaciones bsicas de la interfaz. Antes de la aceptacin final del proyecto al personal de operaciones tambin se requiere una formacin completa sobre el proceso del proyecto. Los estudiantes requieren de capacitacin sobre las nuevas pantallas e informes. Al menos un vendedor tiene que ser capacitado en la manipulacin del sistema.

14. Calendario. Los Hitos marcados de acuerdo al cronograma son los siguientes: Plan de Testeo terminado Testeos de la Aplicacin terminado Proyecto Finalizado

ID H1

NOMBRE Plan de testeo Terminado

DESCRIPCION Hito principal del proyecto, una vez culminado el plan de testeo, los dems hitos se tienen que basar en este plan.

H2

Testeo de la BD terminado

Es un hito muy importante, ya que el sistema utiliza la BD

H3

Testeo del envi de publicidad al correo terminado

Este hito representa la finalizacin de uno de los productos software que representan el sistema. Este hito permite que las tareas dedicadas a la publicidad comiencen a desarrollarse.

H4

Testeo de registro de Usuario terminado

Este hito representa el documento de aceptacin por parte del cliente del sistema software presentado. Este producto representa el final del desarrollo sistema software hasta que se realicen las pruebas de integracin general del sistema

H5

Sistema instalado y aceptado

Se terminara el proyecto una vez instalado en el servidor, aceptado por los usuarios y por el docente

15. Los riesgos y contingencias. En el presente inciso se identificaran todos los riesgos y contingencias, cada respectivamente en su inciso indicado, estos nos permitir tener un mejor panorama de las posibles salidas de emergencia y como contenerlos. Se evaluaran cada escenario de los riesgos planteando medidas de prevencin, finalmente se especificara un plan de contingencias que contemple todo el anlisis del mbito.

15.1. Identificacin de posibles riesgos. En el siguiente cuadro se presenta la identificacin de los principales riesgos que puedan sucintarse en el proyecto, es importante mencionar que existen diversos agentes internos

como externos que influyen en el desarrollo del software, estos factores podran afectar de manera directa o indirecta al desarrollo, es por eso que se los detalla a continuacin.

RIESGO Arquitectura de software Base de datos. Enfermedad. Requerimientos de usuario. Huelga de trabajadores. Programacin Ambientes

LOCALIZACION Diseo bajo de la estructura del sistema. Diseo de la estructura no confiable. Retraso de tiempo para el desarrollo. Requerimientos cambiantes. Cualquier parte del proyecto puede verse afectado. Conocimientos poco extensos. No cmodos para el desenvolvimiento del software.

15.2. Evaluacin de escenario de riesgos. Para este inciso de proceder a disear una tabla donde se categorizaran cada riesgo, con un puntero que indicara el grado de peligro. CATEGORIA A B C D E F G Requerimientos cambiantes. Posibilidad de arquitectura poco acoplable. Posibilidad de Base de datos mal diseada Posibilidad de conocimientos poco extensos. Posible enfermedad en los desarrolladores o testeadores. Huelga de trabajadores. Ambientes no cmodos. DEFINICION

CATEGORIA SALUD

ALTERACION DEL SOFTWARE

IMPACTO FINACIERO

1 2 3 4

Fatalidad Serio Tratamiento No grave

Grande Mediano Pequeo Simple

Mayor Significativo Moderado Menor

15.2.1. Requerimientos. S = Salud de los trabajadores. AS = Alteracin de software. IF = Impacto financiero. Matriz de riesgos
A 1 2 3 4 B C D E F G

AS,IF

AS,IF

AS,IF

Descripcin: Posible descripcin de los requerimientos errneos, o que no satisfacen las necesidades del usuario o requerimientos que el usuario cambia al ver una parte de entrega del software. Medidas de Prevencin: Estableciendo una adecuada comunicacin entre el cliente y sus necesidades, la supervisin del encargado y del cliente.

15.2.2. Arquitectura acoplable. S = Salud de los trabajadores. AS = Alteracin de software. IF = Impacto financiero.

Matriz de riesgos
A 1 2 3 4 B C D E F G

AS,IF

Descripcin: Posible estructura de la arquitectura poco adaptable al tipo de aplicacin, provocando una prdida de datos. Medidas de Prevencin: Se tienen en reserva arquitecturas similares que podran mostrar una arquitectura solida para el desarrollo del proyecto.

15.2.3. Diseo BD. S = Salud de los trabajadores. AS = Alteracin de software. IF = Impacto financiero. Matriz de riesgos
A 1 2 3 4 B C D E F G

AS,IF

Descripcin: Posible diseo de la BD poco segura que produce perdida de datos. Medidas de Prevencin: La revisin constante de la BD, en cuanto a valores de entrada y de salida correctos para el buen funcionamiento,

15.2.4. Conocimientos. S = Salud de los trabajadores. AS = Alteracin de software. IF = Impacto financiero. Matriz de riesgos
A 1 2 3 4 B C D E F G

AS,IF

Descripcin: Posible falta de conocimientos en cuento a programacin, diseo de BD, arquitecturas y testing. Medidas de Prevencin: Se realizara capacitaciones en las 4 reas para evitar retrasos al momento del desarrollo del proyecto.

15.2.5. Enfermedad. S = Salud de los trabajadores. AS = Alteracin de software. IF = Impacto financiero.

Matriz de riesgos
A 1 2 3 4 B C D E F G

Descripcin: Posible contagio de algn tipo de enfermedad que afecta de manare al proyecto, retrasando su desarrollo. Medidas de Prevencin: Se habilitara a un remplazo en su lugar, para evitar la discontinuidad caso contrario los encargados y jefes tendr que ocupar el puesto.

15.2.6. Huelgas. S = Salud de los trabajadores. AS = Alteracin de software. IF = Impacto financiero.

Matriz de riesgos
A 1 2 3 4 B C D E F G

IF

Descripcin: Protestas a nivel regional o nacional que provocan la paralizacin de la produccin. Medidas de Prevencin: Establecer una adecuada comunicacin con los trabajadores.

15.2.7. Ambientes. S = Salud de los trabajadores. AS = Alteracin de software. IF = Impacto financiero.

Matriz de riesgos
A 1 2 3 4 B C D E F G

AS,IF

Descripcin: Posible disconformidad en cuento al ambiente en el cual se desarrolla. Medidas de Prevencin: Establecer una adecuada comunicacin con los trabajadores, tratando de obtener sugerencias de actividades que permitan crecer juntos y buscar un mismo objetivo para la misma comodidad.

15.2. Especificacin de plan de contingencia. El plan de contingencias debe proteger a todo mbito de intervencin del proyecto, el plan considera que todo incidente inesperado que se produzca en el rea tendr una oportuna accin de respuesta por los responsables del proyecto, teniendo en cuenta las prioridades siguientes: Garantizar la integridad fsica de las personas. Disminuir los estragos producidos sobre el software.

15.2.1. Unidad de contingencia. El objetivo de este inciso es la proteccin del sistema que se est desarrollando, este inciso se encarga de llevar tener el software en un lugar seguro, referentemente a tener con vida el sistema, aplicndole medidas que permitan su continuidad.

La unidad de contingencia deber de contar con los siguientes puntos: Personal capacitado para evitar la prdida de informacin al momento de ser atacados por va internet,

 Desplazamiento de todos los datos a un servidor externo al momento de ser atacados. Equipos de comunicacin eficientes. Herramientas, software y hardware de remplazo, listo para ser utilizados al momento de algn accidente o dao.

15.2.2. Implantacin del plan de contingencias. En este punto se implantara el plan que nos permita contener, los puntos ya descritos en el inciso anterior.

15.2.2.1. Capacitacin del personal. Es en este punto se deber de capacitar al personal en el manejo de herramientas y tecnologas que nos permitan proteger los datos de cualquier ataque externo o interno, que cause perdidas de informacin valiosa.

15.2.2.2. Desplazamiento o envi. Se deber de disear una arquitectura de red, que permita que los datos guardados en el servidor maestro sean re direccionados hacia otro cuando ocurre un ataque o se penetra a la informacin de manera brusca, rompiendo las barreras de seguridad.

15.2.2.3. Equipos de comunicacin y cmaras de seguridad. En este punto se deber de contar con equipo de comunicacin precisa y tambin cmaras para evitar el ingreso de personas ajenas a la empresa, con la intencin de robo de equipos o informacin valiosa, las cmaras permitirn tener imgenes de lo que sucede dentro y fuera de la empresa, cuando no se tiene actividad laboral.

15.2.2.4. Herramientas, software y hardware. El tener equipos dispuesto a ser usado cuando algn otro falla al momento del desarrollo del sistema, estos nos permitir reparar, sustituir de manera rpida para salvar informacin valiosa que afecta al sistema.

16. Las aprobaciones. A continuacin se presenta un modelo para las aprobaciones: Revisin: Juan Eduardo Salazar. Aprobacin: Remberto Sam Martin - Jefe de Proyecto Encargado de Proyecto: Elias Goitia. Anexos: Casos de Pruebas.

Especificaciones de los casos de prueba. En esta seccin se detalla los casos de prueba que se utilizan en los procedimientos para validacin y verificacin del software.

Nivel de Pruebas: Pruebas de Unidad. 1. Identificador de casos de prueba. Numero: 1 2. Descripcin de prueba. Gestin de los productos de la tienda. 3. Elemento de prueba. Ingresar un nuevo producto. 4. Especificacin de salida. El producto fue guardado correctamente.