programación Construcción y Prueba de los si. La programación es un proceso que se utiliza para idear y ordenar las acciones que se realizarán en el marco de un proyecto; al anuncio de las partes que componen un acto o espectáculo; a la preparación de máquinas para que cumplan con una cierta tarea en un momento determinado; a la elaboración de programas para la resolución de problemas mediante ordenadores; y a la preparación de los datos necesarios para obtener una solución de un problema.
Programación estructurada (PE) La programación estructurada esta compuesta por un conjunto de técnicas que han ido evolucionando aumentando considerablemente la productividad del programa reduciendo el tiempo de depuración y mantenimiento del mismo. Esta programación estructurada utiliza un número limitado de estructuras de control, reduciendo así considerablemente los errores. Esta técnica incorpora: Diseño descendente (top-dow): el problema se descompone en etapas o estructuras jerárquicas. Recursos abstractos (simplicidad): consiste en descompones las acciones complejas en otras más simples capaces de ser resueltas con mayor facilidad. Estructuras básicas: existen tres tipos de estructuras básicas: Estructuras secuénciales: cada acción sigue a otra acción secuencialmente. La salida de una acción es la entrada de otra . Estructuras selectivas: en estas estructuras se evalúan las condiciones y en función del resultado de las mismas se realizan unas acciones u otras. Se utilizan expresiones lógicas. Estructuras repetitivas: son secuencias de instrucciones que se repiten un número determinado de veces.
Programación modular En la programación modular consta de varias secciones dividas de forma que interactúan a través de llamadas a procedimientos, que integran el programa en su totalidad. En la programación modular, el programa principal coordina las llamadas a los módulos secundarios y pasa los datos necesarios en forma de parámetros. A su vez cada modulo puede contener sus propios datos y llamar a otros módulos o funciones. Programación orientada a objetos (POO) Se trata de una técnica que aumenta considerablemente la velocidad de desarrollo de los programas gracias a la reutilización de los objetos. El elemento principal de la programación orientada a objetos es el objeto. El objeto es un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización. Un objeto contiene varios datos bien estructurados y pueden ser visibles o no dependiendo del programador y las acciones del programa en ese momento. Programación concurrente Este tipo de programación se utiliza cuando tenemos que realizar varias acciones a la vez. Se suele utilizar para controlar los accesos de usuarios y programas a un recurso de forma simultanea. Se trata de una programación más lenta y laboriosa, obteniendo unos resultados lentos en las acciones. Programación funcional Se caracteriza principalmente por permitir declarar y llamar a funciones dentro de otras funciones. Programación lógica Se suele utilizar en la inteligencia artificial y pequeños programas infantiles. Se trata de una programación basada en el cálculo de predicados (una teoría matemática que permite lograr que un ordenador basándose en hecho y reglas lógicas, pueda dar soluciones inteligentes).
manuales Construcción y Prueba de los si.
El Manual de Usuario expone los procesos que el usuario puede realizar con el sistema implantado, instruyéndolo en su uso y en la solución de los problemas que puedan suceder durante la operación. Para lograr esto, es necesario que se detallen todas las características que tienen los programas y la forma de acceder e introducir la información. Permite a los usuarios conocer en detalle qué actividades deberán desarrollar para la consecución de los objetivos del sistema. Reúne la información, normas y documentación necesarias para que el usuario conozca y utilice adecuadamente la aplicación desarrollada. Para la elaboración de un manual de usuario se deberán de integrar los siguientes apartados normativos. 1. Nombre del Sistema: Nombre del sistema al que se refiere el manual. 2. Versión del Sistema: La versión del sistema en el manual nos permitirá mantener un control sobre las modificaciones que han afectado al sistema original. 3. Tipo de Manual: Se especifica el tipo de manual al que se hace referencia, ya permitiendo tener un control en nuestros manuales, además de una fácil identificación. 4. Poner una Imagen: Es recomendable ilustrar el manual con una imagen representativa del sistema. 5. Fecha de Elaboración: Es importante el incluir la fecha de elaboración, pues representa un punto de referencia y control. 6. Área donde fue elaborado: Incluir el nombre del área en donde fue elaborado el manual
III.II. Organización del Manual: Enumerar de forma general el contenido del manual, con la finalidad de orientar y facilitar al usuario la búsqueda de temas. 7.2. Generalidades del Sistema I. Descripción del Producto: Muestra las secciones que integran el sistema, la seguridad del mismo y su alcance. II. Uso de Teclas: Se ilustrará con imágenes y se mencionará el uso que tiene
7. Índice del Contenido del Manual: Deberá contar con un índice y/o contenido
cada una de las teclas del teclado que intervienen en el sistema.
del manual para facilitar su manejo e identificación de los puntos importantes,
III. Botones Generales usados en el Sistema: Mostrar con imágenes todos los
pues si sólo se busca un punto en específico con el índice es fácil identificarlo.
botones, explicando su funcionamiento dentro del sistema.
7.1. Presentación: Breve descripción general del manual. I. Antecedentes: Describir las razones principales que propician la elaboración
IV. Ayudas del Sistema: Describir las diferentes formas en las que se puede obtener ayuda mientras se trabaja con el sistema.
del sistema.
7.3. Requerimientos Técnicos del Sistema, Instalación y Configuración
II. Objetivos del Sistema: Establecer los puntos importantes que cubrirá el
I. Definición de los Requerimientos Técnicos del Sistema: Especificar las
sistema.
herramientas y plataformas necesarias para la instalación de la aplicación.
III. Introducción: Fundamentar la razón de ser del Sistema. III.I A quién está dirigido el Manual: Tipo de usuario al cual se dirige la información.
II. Instalación: Establecer los pasos para la instalación del sistema. III. Configuración: Definir los pasos para la configuración del sistema.
manuales Construcción y Prueba de los si.
7.4. Entrada y Salida del Sistema I. Entrada al Sistema: Explicar detalladamente las pantallas principales que aparecen al momento de entrar a la aplicación. Se recomienda ilustrar con imágenes las ventanas para un mejor entendimiento, lo cual puede ser: I.I. Por medio de un ICONO que represente el acceso directo al sistema. I.II Explicando al usuario la ruta en la que se encuentra el archivo ejecutable.
7.6. Manejo de Errores
II. Salida del Sistema: En esta sección se explicará la forma de cómo salir del
Tabla de Errores: En esta sección se presentará una lista con los posibles
sistema, describiendo detalladamente las pantallas principales que aparecen
errores que maneja el sistema, seguido de una propuesta de solución.
al momento de salir de la aplicación. Se recomienda ilustrar con imágenes las
7.7. Contingencias y Soporte Técnico
ventanas para un mejor entendimiento.
En esta sección se especificarán los contactos asociados a las labores de
7.5. Uso de la Aplicación
soporte técnico, incluyendo nombre, e-mail y teléfonos.
I. Diagrama Conceptual General de Funcionamiento: Representar gráficamente
7.8. Glosario de Términos
la forma en que funciona el sistema, con sus diferentes conexiones e intervenciones por el usuario, acompañada de una breve explicación.
Incluye una lista con el significado de los términos, conceptos o tecnicismos, usados en este manual y que no son del dominio público. 7.9. Anexos
II. Módulo: Especificar para cada uno de los módulos que contemple el sistema
Este punto se utilizará en caso de ser necesario, para ilustrar con mayor
el nombre y la descripción, incluyendo un diagrama de flujo de la información
profundidad aspectos asociados a las funcionalidades del sistema.
mediante el cual se represente el funcionamiento y uso de cada una de las funcionalidades que lo conforman. III. Ventana o Pantalla: Utilizar imágenes o capturas de pantalla, para describir el uso y funcionamiento de cada uno de los elementos que conforman cada funcionalidad del módulo.
7.10. Encabezado y Pie de Página Cada página del manual tendrá un encabezado y pie con información representativa. Pueden incluir datos importantes como el nombre de dicho manual, el número de la versión, fecha de modificación, el número de página, entre otros elementos. Esto permitirá al usuario entre otras cosas la rápida navegación e identificación de temas.
Metodología de Pruebas Construcción y Prueba de los si.
Los procesos de aseguramiento de calidad de un producto de softare suelen dividirse en lo que respecta a su componente analítco en pruebas estátcas y dinámicas. La diferencia fundamental entre estos tpos de pruebas, radica en que las pruebas estátcas se centran en evaluar la calidad con la que se está generando la documentación del proyecto, por medio de revisiones periódicas, mientras que las pruebas dinámicas, requieren de la ejecución del softare con el fn de medir el nivel de calidad. Realizar pruebas dinámicas a un producto de softare, suele en la mayoría de los casos confundirse con una simple actvidad 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 frma desarrolladora. Para procesos de desarrollo basados en la metodología RUP o métodos tradicionales, implementar una metodología de pruebas es totalmente viable, teniendo en cuenta que estas metodologías están orientadas a la documentación y a la formalización de todas las actvidades ejecutadas. Si por el contrario, la frma desarrolladora guía su proceso bajo lineamientos basados en metodologías ágiles, será necesario reevaluar la conveniencia de ejecutar todas las actvidades que implica un proceso de pruebas formal, lo que en la mayoría de los casos, conlleva a reducir al mínimo las actvidades relacionadas con un proceso de pruebas, circunstancia que naturalmente puede desencadenar en la liberación de productos con bajos niveles de calidad. Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5 tpicas 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.
Planeación de Pruebas. Es la etapa en donde se ejecutan las primeras actvidades correspondientes al proceso de pruebas y tene como resultado un entregable denominado plan de pruebas el cual debe estar conformado en cuando menos por aspectos tales como: Alcance de la prueba: determina que funcionalidades del producto y/o softare serán probadas durante el transcurso de la prueba. Este listado de funcionalidades a probar se extrae con base a un análisis de riesgos realizado de manera previa, que tenen en cuenta variables tales como el impacto que podría ocasionar la falla de una funcionalidad y la probabilidad de falla de una funcionalidad. Tipos de Prueba: en este punto se debe determinar qué tpos de pruebas requeriría el producto. Estrategia de Pruebas: teniendo en cuenta que no es viable probar con base a todas las posibles combinaciones de datos, es necesario determinar a través de un análisis de riesgos sobre que funcionalidades debemos centrar nuestra atención. Adicionalmente, una buena estrategia de pruebas debe indicar los niveles de pruebas (ciclos) que aplicaremos y la intensidad o profundidad a aplicar para cada nivel de pruebas defnido. En este punto también es importante defnir los criterios de entrada y salida para cada ciclo de pruebas a ejecutar. Criterios de Salida: entre las partes involucradas en el proceso, se defne de manera formal, bajo qué condiciones se puede considerar que una actvidad de pruebas fue fnalizada. Los criterios de salida se deben defnir para cada nivel de pruebas a ejecutar. Algunos ejemplos de criterios de salida que pueden ser utlizados son: porcentaje de funcionalidades de alto riesgo probadas con éxito, número defectos crítcos y/o mayores aceptados, etc. Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una estmación de tempos, los roles y/o recursos que harán parte del proceso, la preparación del entorno de pruebas, cronograma base, etc.
Diseño de Pruebas: una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo debe iniciar el análisis de toda la documentación existente con respecto al sistema, con el objeto de iniciar el diseño de los casos de prueba. Los entregables claves para iniciar este diseño pueden ser: casos de uso, historias de usuario, arquitectura del sistema, diseños, manuales de usuario (si existen), manuales técnicos (si existen). El diseño de los casos, debe considerar la elaboración de casos positvos y negatvos. Los casos de prueba negatvos permiten validar cómo se comporta el sistema ante situaciones atpicas y permite verifcar la robustez del sistema, atributo que consttuye unos de los requerimientos no funcionales indispensable para cualquier softare. Por últmo, es necesario defnir cuáles son los datos de prueba necesarios para la ejecución de los casos de prueba diseñados. Implementación y Ejecución de Pruebas: la ejecución de pruebas debe iniciar con la creación de los datos de prueba necesarios para ejecutar los casos de prueba diseñados. La ejecución de estos casos, puede realizarse de manera manual o automatzada; en cualquiera de los casos, cuando se detecte un fallo en el sistema, este debe ser documentado y registrado en una herramienta que permita gestonar los defectos (Bug Tracker). Una vez el defecto ha sido corregido por la frma desarrolladora en su respectvo proceso de depuración, es necesario realizar un re-test que permita confrmar que el defecto fue solucionado de manera exitosa. Por últmo, es indispensable ejecutar un ciclo de regresión que nos permita garantzar, que los defectos corregidos en el proceso de depuración de la frma, no hayan desencadenado otros tpos de defectos en el sistema. Evaluación de Criterios de Salida: los criterios de salida son necesarios para determinar si es posible dar por fnalizado un ciclo de pruebas. Para esto, es conveniente defnir una serie de métricas que permitrán al fnalizar un proceso de pruebas, comparar los resultados obtenidos contra las métricas defnidas, sí los resultados obtenidos no superan la métricas defnidas, no es posible contnuar con el siguiente ciclo de pruebas. Existen varios tpos de criterios de salida dentro de los cuales se pueden mencionar: cubrimiento de funcionalidades en general, cubrimiento de funcionalidades crítcas para el sistema, Número de defectos crítcos y mayores detectados, etc.
TIPOS DE PRUEBAS Construcción y Prueba de los si.
Errar es humano y la etapa de pruebas tene como objetvo detectar los errores que se hayan podido cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos). Lo suyo, además, es hacerlo antes de que el usuario fnal del sistema los tenga que sufrir. De hecho, una prueba es un éxito cuando se detecta un error (y no al revés, como nos gustaría pensar). Las pruebas de Softare tenen 2 objetvos: Demostrar al desarrollador y al cliente que el softare alcanza sus requisitos. En el caso de: softare hecho a la medida esto representa que debe existr al menos 1 prueba por cada requerimiento. Para softare preempaquetado signifca que debe existr al menos 1 prueba por cada funcionalidad y sus combinaciones Descubrir situaciones donde el comportamiento del softare es incorrecto, indeseable o no esta ajustado a las especifcaciones. Estas son las consecuencias de defectos del softare.
TIPOS DE PRUEBAS Construcción y Prueba de los si.
PRUEBAS DE VALIDACIÓN
PRUEBAS DE INTEGRACIÓN
Las pruebas de validación en la ingeniería de software son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.
Pruebas integrales o 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.
Las pruebas de validación empiezan tras la culminación de las pruebas de integración, cuándo se han ejercitado los componentes individuales.se han terminado de ensamblar el software como paquete y se ha descubierto y corregido los errores de interfaz Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere? Enfoques a la verificación • Dinámica de verificación, también conocido como ensayos o experimentación. • Estática de verificación, también conocido como análisis. Tipos • Pruebas de aceptación: desarrolladas por el cliente. • 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 Características Comprobar que se satisfacen los requisitos: • Se usan la mismas técnicas, pero con otro objetivo. • No hay programas de prueba, sino sólo el código final de la aplicación. • Se prueba el programa completo. • Uno o varios casos de prueba por cada requisito o caso de uso especificado. • Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos). • Pruebas alfa (desarrolladores) y beta (usuarios).
Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos. Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema. PRUEBAS FUNCIONALES Una 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. Las pruebas funcionales están desarrolladas bajo la perspectiva del usuario, confirmando que el sistema hace lo que los usuarios esperan que haga. Un error funcional en su aplicación puede tener consecuencias catastróficas, desde la pérdida de credibilidad de sus clientes, hasta grandes pérdidas económicas. Los consultores de pruebas funcionales de Testhouse tienen amplia experiencia en multitud de mercados a nivel global, adaptándose a todo tipo de metodologías de desarrollo y habiendo realizado pruebas funcionales en aplicaciones críticas de empresas líderes en el sector de finanzas, telecomunicaciones y media, entre otros.