Kelvin Goncalvez CI: 21.203.379 Sección “1”
Es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final. Proporcionando una retroalimentación temprana por parte de los usuarios acerca del Sistema.
Es un proceso que desde principio hasta el fin del proyecto se estará llevando a cabo. Durante las etapas de diseño y construcción, hay que tener la precaución de someter a prueba su funcionamiento, para que si alguna falla se llega a presentar no afecte al conjunto de elementos que conforman el prototipo. Por lo tanto, la evaluación es un proceso sistemático que prueba los elementos del prototipo y que debe realizarse durante las diferentes etapas de su desarrollo. Su propósito es recopilar información sobre las posibles fallas del modelo, con el fin de superarlas, tomando en cuenta tanto las características de los elementos del prototipo como sus efectos en la reacción de los Usuarios cuando lo utilizan. Una vez que todos los elementos en forma individual han sido probados, se procede a la prueba en conjunto de los mismos, esto para comprobar que funcionan perfectamente; en este momento pueden surgir problemas, que quizás lleven a rediseñar alguna parte del modelo, o incluso a desecharlo completamente por no ajustarse a los requerimientos señalados.
Consisten en la dinámica de la verificación del comportamiento de un programa en un conjunto finito de casos de prueba, debidamente seleccionados de por lo general infinitas ejecuciones de dominio, contra la del comportamiento esperado. Son una serie de actividades que se realizan con el propósito de encontrar los posibles fallos de implementación, calidad o usabilidad de un programa u ordenador; probando el comportamiento del mismo.
Prueba Unitaria: Es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Prueba Funcional: Es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático. Pruebas de Integración: Son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez. Prueba de Validación: Son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería. Tipos:
Pruebas Alfa: Realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).
Pruebas Beta: Realizadas por el usuario en su entorno de trabajo y sin observadores.
Caja Blanca: Un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas. Caja Negra: Elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea
Probar si el software no hace lo que debe. Probar si el software hace lo que no debe, es decir, si provoca efectos secundarios adversos. Descubrir un error que aún no ha sido descubierto. Encontrar el mayor número de errores con la menor cantidad de tiempo y esfuerzo posibles. Mostrar hasta qué punto las funciones del software operan de acuerdo con las especificaciones y requisitos del cliente.
Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los casos confundirse con una simple actividad de ejecución de pruebas y reporte de incidencias, sin embargo, para productos de complejidad media en adelante, lo recomendable es implementar de manera formal una metodología de pruebas que se ajuste y acople uniformemente con la metodología de desarrollo seleccionada por la firma desarrolladora.
Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5 típicas etapas:
1- Planeación de pruebas. 2- Diseño de pruebas. 3- Implementación de pruebas. 4- Evaluación de criterios de salida. 5- Cierre del proceso.
Para la realización del informe se debe de recopilar los resultados. Para poder hacer cualquier tipo de análisis, no basta con probar, ni siquiera basta con apuntar los resultados, hace falta que esos resultados estén consolidados en un repositorio. Una vez se han analizado los resultados de las pruebas, llega la parte comunicación de resultados. La comunicación se hace a varios destinatarios:
de la
Al equipo de desarrollo: Es importante que sepan el estado del producto en cuanto a defectos encontrados, y una comparación respecto a fases anteriores o si es posible, respecto a otros proyectos más o menos similares.
Al gerente y otros responsables del proyecto: Aquí es crucial dar un sentido de "vamos bien" o "hay que mejorar". Tratar de engañarse con un "no es tan malo como parece", es la mejor forma de llevar un proyecto al fracaso. Si los resultados son buenos, hay que ser realistas y no dejarse llevar por un falso entusiasmo, acortando plazos.
Al cliente: En numerosas situaciones, sobre todo en los entornos de testing y preproducción, el cliente estará al tanto del estado de defectos, y de los resultados de las pruebas. Es importante transmitir seguridad, y sobre todo, franqueza.
La documentación de sistemas es el conjunto de información que nos dice qué hacen los sistemas, cómo lo hacen y para quién lo hacen. La documentación consiste en material que explica las características técnicas y la operación de un sistema. Es esencial para proporcionar entendimiento de un sistema a quien lo vaya a usar para mantenerlo, para permitir auditoria del sistema y para enseñar a los usuarios como interactuar con el sistema y a los operandos como hacerlo funcionar. Existen varios tipos de documentación, la de programas, que explica la lógica de un programa e incluye descripciones, diagramas de flujo, listados de programas y otros documentos, la del usuarios, en forma general la naturaleza y capacidades del sistema y cómo usarlo. Muchas organizaciones tienen lo que se conoce como un "programa de documentación", el cual consiste en una política formal cuya documentación se muestra como algo que debe prepararse en forma rutinaria para cada programa de cómputo, archivo y nuevos sistemas. La importancia de la documentación bien podría ser comparada con la importancia de la existencia de una Póliza de Seguro; mientras todo va bien no existe la precaución de confirmar si nuestra Póliza de Seguros está o no vigente. La documentación adecuada y completa, de una aplicación que se desea implantar, mantener y actualizar en forma satisfactoria, es esencial en cualquier Sistema de Información, sin embargo, frecuentemente es la parte a la cual se dedica el menor tiempo y se le presta menos atención.
Manual de Usuario: Expone los procesos que el usuario puede realizar con el sistema implantado. Para lograr esto, es necesario que se detallen todas y cada una de las características que tienen los programas y la forma de acceder e introducir información. Permite a los usuarios conocer el detalle de qué actividades ellos deberán desarrollar para la consecución de los objetivos del sistema. Reúne la información, normas y documentación necesaria para que el usuario conozca y utilice adecuadamente la aplicación desarrollada. Manual de Operación: Contiene la información necesaria para llevar a cabo de manera precisa y secuencial, las tareas y actividades operativas que son asignadas a cada una de las unidades administrativas, de la misma forma, determina la responsabilidad e identifica los mecanismos básicos para la instrumentación y el adecuado desarrollo, con el propósito de generalizar y unificar los criterios básicos para el análisis de los procedimientos que realicen las distintas unidades administrativas de la empresa, señalando lo que se pretende obtener con la ejecución de los mismos. Manual de Procedimiento: Es el documento que contiene la descripción de actividades que deben seguirse en la realización de las funciones de una unidad administrativa, o de dos ò mas de ellas. El manual incluye además los puestos o unidades administrativas que intervienen precisando su responsabilidad y participación.
Para implementar un sistema es necesario crear un prototipo que será una visión prematura del resultado final. Este prototipo deberá pasar por diferentes inspecciones que garantizaran el buen desenvolvimiento del programa y proporcionara así una confianza en el mismo por parte del cliente. Deberán realizarse cierta cantidad de rigurosas pruebas para poner al prototipo en diferentes situaciones que se le podrían presentar en un futuro. Una vez realizadas cada una de estas pruebas es necesario crear un informe que describa los resultados de las mismas para ser presentado principalmente al cliente y realizar así las correcciones necesarias al sistema para su posterior implementación. Una vez realizada la evaluación del prototipo se procede a documentar el sistema, es decir, plasmar en papel el sistema en sí, explicando en diferentes manuales el funcionamiento del mismo para sus futuros usos.
http://www.slideshare.net/BENHUR2010/manuales-sistemas-de-informacin http://calidadysoftware.blogspot.com/2012/06/testing-iii-analisis-y-resultados-de.html http://ciclodevidasoftware.wikispaces.com/Tipos+de+Pruebas http://www.fao.org/docrep/007/y5471s/Y5471S05.htm http://www.monografias.com/trabajos6/dosi/dosi.shtml http://pruebasdelsoftware.wordpress.com/tag/implementacion-de-pruebas/ http://es.wikipedia.org/wiki/Pruebas_de_validaci贸n http://www.ecured.cu/index.php/Pruebas_de_software