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.
Objetivos
Que el usuario conozca cómo preparar los datos de entrada.Que el usuario aprenda a obtener los resultados y los datos de salida.Servir como manual de aprendizaje.Servir como manual de referencia.Definir las funciones que debe realizar el usuario.Informar al usuario de la respuesta a cada mensaje de error.
Pasos a seguir para definir como desarrollar el manual de usuario.
Identificar los usuarios del sistema: personal que se relacionará con el sistema.Definir los diferentes tipo de usuarios: se presentan los diferentes tipos de usuarios que usarían el sistema. Ejemplo: usuarios directos, indirectos.Definir los módulos en que cada usuario participará: Se describen los módulos o procesos que se ejecutarán por cada usuario en forma narrativa breve y clara.
Importancia Del Manual De Usuario
El Manual de Usuario facilita el conocimiento de:
Los documentos a los que se puede dar entrada por computadora.Los formatos de los documentos.Las operaciones que utiliza de entrada y salida de los datos.El orden del tratamiento de la computadora con los datos introducidos.El momento en que se debe solicitar una operación deseada.Los resultados de las operaciones realizadas a partir de los datos introducidos.
Al elaborar el Manual de Usuario, hay que tener en cuenta a quién va dirigido es decir, el manual puede ser manejado desde el director de la empresa hasta el introductor de datos. Por consiguiente, debe redactarse de forma clara y sencilla para que lo entienda cualquier tipo de usuario.
Contenido
Diagrama general del sistema
Muestra en forma condensada el flujo general de la información y de las actividades que se realizan en el sistema. Proporciona una visión general del sistema. Representar los diagramas utilizando para ello diagramas de bloques.
Diagrama particular detallado.
Presentar gráficamente todos los pasos que se efectúen dentro del departamento usuario a quien está dirigido este manual. Deben especificarse los archivos de entrada, salida, los resultados, revisiones y procesos manuales.
Explicación Genérica De Las Fases Del Sistema
En este punto se explica en forma específica y detallada todas las operaciones que aparecen representadas en forma gráfica en el diagrama particular. Se analizan cada una de las fases señalando:
El proceso principal que se desarrolla.La entrada de la información.La obtención de un resultado parcial.El envío de información a otra dependencia.
Instalación Del Sistema
La instalación del sistema proporciona detalles completos sobre la forma de instalar el sistema en un ambiente particular.
Iniciación Al Uso Del Sistema
En este punto se explica cómo iniciarse en el sistema y cómo se pueden utilizar sus cualidades comunes. Esta documentación debe decir al usuario cómo salir de un problema cuando las cosas funcionan mal.
Manual De Referencia
Es el documento definitivo de cara al usuario y debe ser completo. Describe con detalle las cualidades del sistema y su uso, los informes de error generados y las situaciones en que surgen esos errores.
Dependiendo del sistema, los documentos al usuario se pueden proporcionar por separado o reunidos en varios volúmenes. Los sistemas de ayuda en línea evitan que el usuario pierda tiempo en consultas manuales.
Caducidad De Documento Fuente Y Destino Final
Como el usuario trabajará con documentos fuentes, éstos podrán tener un período de retención y un destino especificado.
http://www.monografias.com/trabajos6/dosi/dosi.shtml#usuario
jueves, 1 de julio de 2010
6.1 Elaborar el Manual Tecnico
Elaborar el Manual Tecnico
Este documento contiene toda la información sobre los recursos utilizados por el proyecto, llevan una descripción muy bien detallada sobre las características físicas y técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad, dimensiones del equipo, garantías, soporte, proveedores y equipo adicional.
Su extensión depende de la cantidad de recursos y equipo utilizado y generalmente se presenta en forma de fichas técnicas en donde se describe en cada una las características de cada recurso.
CONSIDERACIONES GENERALES PARA LA DOCUMENTACIÓN DE EL DESARROLLO DE APLICACIONES INFORMÁTICAS:
1. Toda documentación que se genere para un proyecto específico, que haya sido revisada y aprobada, debe poseer lo siguiente:
A) Identificación del documento
Este documento debe incorporar la siguiente información:
• Logotipo de la organización.
• Nombre oficial de la organización.
• Denominación y extensión. De corresponder a una unidad en particular debe anotarse el nombre de la misma.
• Lugar y fecha de elaboración.
• Número de revisión (en su caso).
• Unidades responsables de su elaboración, revisión y/o autorización.
• Clave de la forma. En primer término, las siglas de la organización, en segundo lugar las siglas de la unidad administrativa donde se utiliza la forma y, por último, el número de la forma. Entre las siglas y el número debe colocarse un guión o diagonal. (en su caso)
B) Estructura del documento.
2. Por cada documento final deberá entregarse copias al personal involucrado en el proyecto.
3. Una vez concluido el desarrollo de un sistema, considerando para esto los posibles cambios que se efectúen durante la etapa de garantía de que lo cubre (si así fuera el caso), el usuario final del sistema debe recibir una versión actualizada final del documento manual técnico.
Estructura del documento MANUAL TÉCNICO
1. Índice
Relación de los capítulos y páginas correspondientes que forman parte del documento
2. Introducción. Se debe presentar una breve descripción del sistema desarrollado, que contemple el ámbito abarcado, cual es su función principal y un detalle de las funciones macros o partes que lo componen. Puede incluir un mensaje de la máxima autoridad de las áreas comprendidas en el manual.
2.1. Objetivo general del sistema
Se debe de describir el objetivo general del sistema.
2.2. Objetivos específicos
Se deben describir brevemente los objetivos específicos que se cumplieron con el desarrollo del sistema.
3. Contenido técnico
3.1. Definición de reglas del negocio implementadas en el sistema desarrollado.
3.2. Diagramas de flujo de datos, junto con su respectivo diccionario de datos.
3.3. Controles de auditoria implementados en el sistema.
3.4. Descripción de campos requeridos por pantalla con presentación de pantallas.
3.5. Diagrama de navegación del sistema.
3.6. Requerimientos de interfase con otros sistemas.
3.7. Modelo lógico de datos, diagrama entidad-relación.
3.8. Modelo de datos físico, junto con su respectivo diccionario de datos.
3.9. Matriz de procesos versus organización.
3.10. Matriz de programas versus entidades.
3.11. Plataforma de usuario. Aquí se describen los requerimientos mínimos que se deben tener tanto de hardware como de software para que el sistema se pueda instalar y ejecutar correctamente (en caso de que se considere necesario).
3.12. Áreas de aplicación y/o alcance de los procedimientos. Esfera de acción que cubren los procedimientos
4. Responsables.
Para iniciar los trabajos que conducen a la integración de un manual, es indispensable prever que no queda diluida la responsabilidad de la conducción de las acciones en diversas personas, sino que debe designarse a un coordinador, auxiliado por un equipo técnico, al que se le debe encomendar la conducción del proyecto en sus fases de diseño, implantación y actualización. De esta manera se logra homogeneidad en el contenido y presentación de la información. Por lo que respecta a las características del equipo técnico, es conveniente que sea personal con un buen manejo de las relaciones humanas y que conozca a la organización en lo que concierne a sus objetivos, estructura, funciones y personal. Para este tipo de trabajo, una organización puede nombrar a la persona que tenga los conocimientos y la experiencia necesarios para llevarlo a cabo. Por la naturaleza de sus funciones puede encargarlo al titular de el área específica. Asimismo, puede contratar los servicios de consultores externos.
4.1. Mapa de navegación. muestra de forma gráfica la interconexión entre cada una de las pantallas del sistema, lo que serviría para saber como llegar a determinada parte de la aplicación. En este se muestran los menús, submenús y pantallas a las que nos lleva cada uno de ellos
4.2. Descripción gráfica del mapa de navegación. En el anterior aparece de forma de diagrama de flujo y en esta sección deberá aparecer ya con las respectivas pantallas.
4.3. Describe paso a paso los procesos, así como pantallas, botones, cuadros de texto, etc., pero también se muestra el código de cada rutina, pantalla, botón, etc. es decir, se muestra lo que hay detrás de la interfaz del usuario
http://www.mitecnologico.com/Main/ElaboracionManualTecnico
Este documento contiene toda la información sobre los recursos utilizados por el proyecto, llevan una descripción muy bien detallada sobre las características físicas y técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad, dimensiones del equipo, garantías, soporte, proveedores y equipo adicional.
Su extensión depende de la cantidad de recursos y equipo utilizado y generalmente se presenta en forma de fichas técnicas en donde se describe en cada una las características de cada recurso.
CONSIDERACIONES GENERALES PARA LA DOCUMENTACIÓN DE EL DESARROLLO DE APLICACIONES INFORMÁTICAS:
1. Toda documentación que se genere para un proyecto específico, que haya sido revisada y aprobada, debe poseer lo siguiente:
A) Identificación del documento
Este documento debe incorporar la siguiente información:
• Logotipo de la organización.
• Nombre oficial de la organización.
• Denominación y extensión. De corresponder a una unidad en particular debe anotarse el nombre de la misma.
• Lugar y fecha de elaboración.
• Número de revisión (en su caso).
• Unidades responsables de su elaboración, revisión y/o autorización.
• Clave de la forma. En primer término, las siglas de la organización, en segundo lugar las siglas de la unidad administrativa donde se utiliza la forma y, por último, el número de la forma. Entre las siglas y el número debe colocarse un guión o diagonal. (en su caso)
B) Estructura del documento.
2. Por cada documento final deberá entregarse copias al personal involucrado en el proyecto.
3. Una vez concluido el desarrollo de un sistema, considerando para esto los posibles cambios que se efectúen durante la etapa de garantía de que lo cubre (si así fuera el caso), el usuario final del sistema debe recibir una versión actualizada final del documento manual técnico.
Estructura del documento MANUAL TÉCNICO
1. Índice
Relación de los capítulos y páginas correspondientes que forman parte del documento
2. Introducción. Se debe presentar una breve descripción del sistema desarrollado, que contemple el ámbito abarcado, cual es su función principal y un detalle de las funciones macros o partes que lo componen. Puede incluir un mensaje de la máxima autoridad de las áreas comprendidas en el manual.
2.1. Objetivo general del sistema
Se debe de describir el objetivo general del sistema.
2.2. Objetivos específicos
Se deben describir brevemente los objetivos específicos que se cumplieron con el desarrollo del sistema.
3. Contenido técnico
3.1. Definición de reglas del negocio implementadas en el sistema desarrollado.
3.2. Diagramas de flujo de datos, junto con su respectivo diccionario de datos.
3.3. Controles de auditoria implementados en el sistema.
3.4. Descripción de campos requeridos por pantalla con presentación de pantallas.
3.5. Diagrama de navegación del sistema.
3.6. Requerimientos de interfase con otros sistemas.
3.7. Modelo lógico de datos, diagrama entidad-relación.
3.8. Modelo de datos físico, junto con su respectivo diccionario de datos.
3.9. Matriz de procesos versus organización.
3.10. Matriz de programas versus entidades.
3.11. Plataforma de usuario. Aquí se describen los requerimientos mínimos que se deben tener tanto de hardware como de software para que el sistema se pueda instalar y ejecutar correctamente (en caso de que se considere necesario).
3.12. Áreas de aplicación y/o alcance de los procedimientos. Esfera de acción que cubren los procedimientos
4. Responsables.
Para iniciar los trabajos que conducen a la integración de un manual, es indispensable prever que no queda diluida la responsabilidad de la conducción de las acciones en diversas personas, sino que debe designarse a un coordinador, auxiliado por un equipo técnico, al que se le debe encomendar la conducción del proyecto en sus fases de diseño, implantación y actualización. De esta manera se logra homogeneidad en el contenido y presentación de la información. Por lo que respecta a las características del equipo técnico, es conveniente que sea personal con un buen manejo de las relaciones humanas y que conozca a la organización en lo que concierne a sus objetivos, estructura, funciones y personal. Para este tipo de trabajo, una organización puede nombrar a la persona que tenga los conocimientos y la experiencia necesarios para llevarlo a cabo. Por la naturaleza de sus funciones puede encargarlo al titular de el área específica. Asimismo, puede contratar los servicios de consultores externos.
4.1. Mapa de navegación. muestra de forma gráfica la interconexión entre cada una de las pantallas del sistema, lo que serviría para saber como llegar a determinada parte de la aplicación. En este se muestran los menús, submenús y pantallas a las que nos lleva cada uno de ellos
4.2. Descripción gráfica del mapa de navegación. En el anterior aparece de forma de diagrama de flujo y en esta sección deberá aparecer ya con las respectivas pantallas.
4.3. Describe paso a paso los procesos, así como pantallas, botones, cuadros de texto, etc., pero también se muestra el código de cada rutina, pantalla, botón, etc. es decir, se muestra lo que hay detrás de la interfaz del usuario
http://www.mitecnologico.com/Main/ElaboracionManualTecnico
5.4 Realizar Mantenimiento en el SI
Realizar Mantenimiento en el SI
Mantenimiento de los sistemas de información
Con posterioridad a la fase de implementación de los sistemas, se impone la fase de mantenimiento.
El mantenimiento de sistemas es el mantenimiento continuo después del inicio del funcionamiento.
Cuando se elaboran planes para la estrategia de información, las organizaciones no pueden dejar de
Considerar que el mantenimiento de sistemas es la fase más prolongada y costosa del ciclo de vida
De los sistemas. Las implicaciones del volumen de trabajo para mantenimiento para los planes de
Estrategia de información en una organización es un tema que merece atención especial. La
Estructura de organización necesita flexibilidad para apoyar el mantenimiento de los sistemas
Existentes concurrentemente con la ejecución de nuevas tecnologías.
Es importante considerar la evaluación y el monitoreo de un sistema en términos del mantenimiento
Necesario y, en consecuencia, reducir o contener los costos implícitos. El mantenimiento de sistemas
Puede clasificarse en cuatro grupos, cada uno de los cuales repercute en el plan estratégico de
Información institucional de diferentes maneras:
Con posterioridad a la fase de implementación de los sistemas, se impone la fase de mantenimiento.
El mantenimiento de sistemas es el mantenimiento continuo después del inicio del funcionamiento.
Cuando se elaboran planes para la estrategia de información, las organizaciones no pueden dejar de
Considerar que el mantenimiento de sistemas es la fase más prolongada y costosa del ciclo de vida
De los sistemas. Las implicaciones del volumen de trabajo para mantenimiento para los planes de
Estrategia de información en una organización es un tema que merece atención especial. La
Estructura de organización necesita flexibilidad para apoyar el mantenimiento de los sistemas
Existentes concurrentemente con la ejecución de nuevas tecnologías.
Es importante considerar la evaluación y el monitoreo de un sistema en términos del mantenimiento
Necesario y, en consecuencia, reducir o contener los costos implícitos. El mantenimiento de sistemas
Puede clasificarse en cuatro grupos, cada uno de los cuales repercute en el plan estratégico de
Información institucional de diferentes maneras:
· Mantenimiento correctivo. Independientemente de cuán bien diseñado, desarrollado y
Probado está un sistema o aplicación, ocurrirán errores inevitablemente. Este tipo de
Mantenimiento se relaciona con la solución o la corrección de problemas del sistema. Atañe
Generalmente a problemas no identificados durante la fase de ejecución. Un ejemplo de
Mantenimiento correctivo es la falta de una característica requerida por el usuario, o suFuncionamiento defectuoso.
Probado está un sistema o aplicación, ocurrirán errores inevitablemente. Este tipo de
Mantenimiento se relaciona con la solución o la corrección de problemas del sistema. Atañe
Generalmente a problemas no identificados durante la fase de ejecución. Un ejemplo de
Mantenimiento correctivo es la falta de una característica requerida por el usuario, o suFuncionamiento defectuoso.
· Mantenimiento para fines específicos. Este tipo de mantenimiento se refiere a la creación de
Características nuevas o a la adaptación de las existentes según lo requieren los cambios en
La organización o los usuarios, por ejemplo, los cambios en el código tributario o los
Reglamento internos de la organización.
Características nuevas o a la adaptación de las existentes según lo requieren los cambios en
La organización o los usuarios, por ejemplo, los cambios en el código tributario o los
Reglamento internos de la organización.
· Mantenimiento para mejoras. Se trata de la extensión o el mejoramiento del desempeño del
Sistema, ya sea mediante el agregado de nuevas características, o el cambio de las
Existentes. Un ejemplo de este tipo de mantenimiento es la conversión de los sistemas de
Texto a GUI (interfaz gráfica de usuarios).
· Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los más
Eficaces en función de los costos, ya que si se realiza de manera oportuna y adecuada,
Puede evitar serios problemas en el sistema. Un ejemplo de este mantenimiento es la
Corrección del problema del año 2000.
Sistema, ya sea mediante el agregado de nuevas características, o el cambio de las
Existentes. Un ejemplo de este tipo de mantenimiento es la conversión de los sistemas de
Texto a GUI (interfaz gráfica de usuarios).
· Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los más
Eficaces en función de los costos, ya que si se realiza de manera oportuna y adecuada,
Puede evitar serios problemas en el sistema. Un ejemplo de este mantenimiento es la
Corrección del problema del año 2000.
5.3 Implantar el SI
Implantar el SI
En la fase de implantación, las especificaciones del diseño del sistema sirven como base para la construcción del nuevo sistema. En este punto, los programadores y los analistas de sistemas asumen diferentes responsabilidades. El analista debe proveer especificaciones claras y correctas al programador.
El programador codifica, prueba y documenta los módulos de programas, mientras que el analista de sistema planifica la integración de los programas y asegura que trabajen unidos para satisfacer las necesidades de la organización.
Un nuevo sistema requiere planificación, construcción y prueba. Los programas y módulos deben ser diseñados, codificados, probados y documentados. Cuando se planifica el sistema, muchas veces se usa un estilo de arriba-hacia-abajo (top-down), que procede de un diseño general a una estructura detallada siguiendo unos pasos lógicos.
En el estilo top-down, el analista de sistemas define los objetivos generales, y luego los descompone en subsistemas y módulos en un proceso llamado “partitioning”. Este estilo también se conoce como diseño modular. Un módulo es un conjunto de instrucciones de programas que se pueden ejecutar como un grupo. Asignando módulos a diferentes programadores se agiliza el desarrollo del programa.
1.- Adiestramiento a usuarios
Debe de ser a nivel de escuela; se debe llevar a cabo usando los manuales e instructivos obtenidos del diseño de sistemas.
Debe de ser a nivel de escuela; se debe llevar a cabo usando los manuales e instructivos obtenidos del diseño de sistemas.
2.- Prueba del sistema por usuarios
Es la actividad que reafirma a cada uno de ellos lo que aprendió en el adiestramiento. Es muy importante que ellos produzcan los datos de prueba de acuerdo con el plan de la misma.
Es la actividad que reafirma a cada uno de ellos lo que aprendió en el adiestramiento. Es muy importante que ellos produzcan los datos de prueba de acuerdo con el plan de la misma.
3.- Aprobación de resultados de la prueba
La aprobación de los resultados de la prueba la deberán hacer los usuarios a la luz de los que su grupo de prueba les reporte al finalizar el tiempo de prueba.
La aprobación de los resultados de la prueba la deberán hacer los usuarios a la luz de los que su grupo de prueba les reporte al finalizar el tiempo de prueba.
4.- Conversión al sistema
Consiste en la implantación de los procedimientos contenidos en los diferentes manuales e instructivos obtenidos en el paso del diseño de sistemas.
Consiste en la implantación de los procedimientos contenidos en los diferentes manuales e instructivos obtenidos en el paso del diseño de sistemas.
5.- Liberación del sistema
Consiste en la entrega formal del sistema al usuario por parte de los comités de factibilidad y técnico.
Consiste en la entrega formal del sistema al usuario por parte de los comités de factibilidad y técnico.
5.2 Validar el SI
Validar el SI
validar el sistema de información
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iníciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?
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).
http://es.wikipedia.org/wiki/Pruebas_de_validaci%C3%B3n
5.1 Realizar pruebas del SI
Realizar pruebas del SI
2. Prueba de Unidades
¿Cómo se prueban módulos sueltos?
Normalmente cabe distinguir una fase informal antes de entrar en la fase de pruebas propiamente dicha. La fase informal la lleva a cabo el propio codificador en su despacho, y consiste en ir ejecutando el código para convencerse de que "básicamente, funciona". Esta fase suele consistir en pequeños ejemplos que se intentan ejecutar. Si el módulo falla, se suele utilizar un depurador para observar la evolución dinámica del sistema, localizar el fallo, y repararlo.
En lenguajes antiguos, poco rigurosos en la sintaxis y/o en la semantica de los programas, esta fase informal llega a ser muy dura, laboriosa, y susceptible de dejar pasar grandes errores sin que se note. En lenguajes modernos, con reglas estrictas, hay herramientas que permiten análisis exhaustivos de los aspectos estáticos de la semántica de los programas: tipado de las variables, ámbitos de visibilidad, parámetros de llamada a procedimientos, etc etc
Hay asimismo herramientas más sofisticadas capaces de emitir "opiniones" sobre un programa y alertar de construcciones arriesgadas, de expresiones muy complicadas (que se prestan a equivocaciones), etc. etc. A veces pueden prevenir sobre variables que pueden usarse antes de tomar algún valor (no inicializadas), variables que se cargan pero luego no se usan, y otras posibilidades que, sin ser necesariamente errores en sí mismas, sí suelen apuntar a errores de verdad.
Más adelante, cuando el módulo parece presentable, se entra en una fase de prueba sistemática. En esta etapa se empieza a buscar fallos siguiendo algún criterio para que "no se escape nada". Los criterios más habituales son los denominados de caja negra y de caja blanca.
Se dice que una prueba es de caja negra cuando prescinde de los detalles del código y se limita a lo que se ve desde el exterior. Intenta descubrir casos y circunstancias en los que el módulo no hace lo que se espera de él.
Por oposición al término "caja negra" se suele denominar "caja blanca" al caso contrario, es decir, cuando lo que se mira con lupa es el código que está ahí escrito y se intenta que falle. Quizás sea más propio la denominación de "pruebas de caja transparente".
2.1. Caja blanca
Sinónimos:
Pruebas estructurales
Pruebas de caja transparente
En estas pruebas estamos siempre observando el código, que las pruebas se dedican a ejecutar con ánimo de "probarlo todo". Esta noción de prueba total se formaliza en lo que se llama "cobertura" y no es sino una medida porcentual de ¿cuánto código hemos cubierto?
Hay diferentes posibilidades de definir la cobertura. Todas ellas intentan sobrevivir al hecho de que el número posible de ejecuciones de cualquier programa no trivial es (a todos los efectos prácticos) infinito. Pero si el 100% de cobertura es infinito, ningún conjunto real de pruebas pasaría de un infinitésimo de cobertura. Esto puede ser muy interesante para los matemáticos; pero no sirve para nada.
Cobertura de segmentos
A veces también denominada "cobertura de sentencias". Por segmento se entiende una secuencia de sentencias sin puntos de decisión. Como el ordenador está obligado a ejecutarlas una tras otra, es lo mismo decir que se han ejecutado todas las sentencias o todos los segmentos.
El número de sentencias de un programa es finito. Basta coger el código fuente e ir contando. Se puede diseñar un plan de pruebas que vaya ejercitando más y más sentencias, hasta que hayamos pasado por todas, o por una inmensa mayoría.
En la práctica, el proceso de pruebas termina antes de llegar al 100%, pues puede ser excesivamente laborioso y costoso provocar el paso por todas y cada una de las sentencias. A la hora de decidir el punto de corte antes de llegar al 100% de cobertura hay que ser precavido y tomar en consideración algo más que el índice conseguido. En efecto, ocurre con harta frecuencia que los programas contienen código muerto o inalcanzable. Puede ser que este trozo del programa, simplemente "sobre" y se pueda prescindir de él; pero a veces significa que una cierta funcionalidad, necesaria, es inalcanzable: esto es un error y hay que corregirlo.
2.2. Caja negra
Sinónimos:
Pruebas de caja opaca
Pruebas funcionales
Pruebas de entrada/salida
Pruebas inducidas por los datos
Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.
Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc etc) Este comentario no obsta para que sean útiles en cualquier módulo del sistema.
Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. Es fácil obtener coberturas del 100% en módulos internos, aunque puede ser más laborioso en módulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura en esta línea.
El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables); sino en los datos que se le pasan a estas funciones. El conjunto de datos posibles suele ser muy amplio (por ejemplo, un entero).
A la vista de los requisitos de un módulo, se sigue una técnica algebráica conocida como "clases de equivalencia". Esta técnica trata cada parámetro como un modelo algebráico donde unos datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia, entonces es suficiente probar un caso de cada clase, pues los demás datos de la misma clase son equivalentes.
El problema está pues en identificar clases de equivalencia, tarea para la que no existe una regla de aplicación universal; pero hay recetas para la mayor parte de los casos prácticos:
si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.
si una entrada es booleana, hay 2 clases: si o no. los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.
3. Pruebas de Integración
Las pruebas de integración se llevan a cabo durante la construcción del sistema, involucran a un número creciente de módulos y terminan probando el sistema como conjunto.
Estas pruebas se pueden plantear desde un punto de vista estructural o funcional.
Las pruebas estructurales de integración son similares a las pruebas de caja blanca; pero trabajan a un nivel conceptual superior. En lugar de referirnos a sentencias del lenguaje, nos referiremos a llamadas entre módulos. Se trata pues de identificar todos los posibles esquemas de llamadas y ejercitarlos para lograr una buena cobertura de segmentos o de ramas.
Las pruebas funcionales de integración son similares a las pruebas de caja negra. Aquí trataremos de encontrar fallos en la respuesta de un módulo cuando su operación depende de los servicios prestados por otro(s) módulo(s). Según nos vamos acercando al sistema total, estas pruebas se van basando más y más en la especificación de requisitos del usuario.
Las pruebas finales de integración cubren todo el sistema y pretenden cubrir plenamente la especificación de requisitos del usuario. Además, a estas alturas ya suele estar disponible el manual de usuario, que también se utiliza para realizar pruebas hasta lograr una cobertura aceptable.
En todas estas pruebas funcionales se siguen utilizando las técnicas de partición en clases de equivalencia y análisis de casos límite (fronteras).
4. Pruebas de Aceptación
Estas pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sería impresentable de cara al cliente; sino una vez pasada todas las pruebas de integración por parte del desarrollador.
La experiencia muestra que aún después del más cuidadoso proceso de pruebas por parte del desarrollador, quedan una serie de errores que sólo aparecen cuando el cliente se pone a usarlo. Los desarrolladores se suelen llevar las manos a la cabeza:
"Pero, ¿a quién se le ocurre usar así mi programa?"
Sea como sea, el cliente siempre tiene razón. Decir que los requisitos no estaban claros, o que el manual es ambiguo puede salvar la cara; pero ciertamente no deja satisfecho al cliente. Alegar que el cliente es un inútil es otra tentación muy fuerte, que conviene reprimir.
Por estas razones, muchos desarrolladores ejercitan unas técnicas denominadas "pruebas alfa" y "pruebas beta". Las pruebas alfa consisten en invitar al cliente a que venga al entorno de desarrollo a probar el sistema. Se trabaja en un entorno controlado y el cliente siempre tiene un experto a mano para ayudarle a usar el sistema y para analizar los resultados.
Las pruebas beta vienen después de las pruebas alfa, y se desarrollan en el entorno del cliente, un entorno que está fuera de control. Aquí el cliente se queda a solas con el producto y trata de encontrarle fallos (reales o imaginarios) de los que informa al desarrollador.
Las pruebas alfa y beta son habituales en productos que se van a vender a muchos clientes. Algunos de los potenciales compradores se prestan a estas pruebas bien por ir entrenando a su personal con tiempo, bien a cambio de alguna ventaja económica (mejor precio sobre el producto
final, derecho a mantenimiento gratuito, a nuevas versiones, etc etc). La experiencia muestra que estas prácticas son muy eficaces.
Prueba Funcional.
‡ Objetivo:
Se asegura el trabajo apropiado de los requisitos funcionales,
Incluyendo la navegación, entrada de datos, procesamiento y
Obtención de resultados.
Pruebas Funcionales – Software II – Mayo 2005
‡ Metas de estas pruebas son:
Verificar el procesamiento, recuperación e
Implementación adecuada de las reglas del
Negocio.
Verificar la apropiada aceptación de datos.
‡ Enfoque:
Los requisitos funcionales (Casos de Uso)
Y las reglas del negocio.
Prueba de Seguridad.
‡ Objetivo:
Nivel de Seguridad de la Aplicación: Verifica que un actor solo
Pueda acceder a las funciones y datos que su usuario tiene
Permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores
Con acceso al sistema y a la aplicación están habilitados para
Accederla.
Pruebas Funcionales – Software II – Mayo 2005
‡ Áreas:
Seguridad del sistema, incluyendo
Acceso a datos o Funciones de negocios.
Seguridad del sistema, incluyendo
Ingresos y accesos remotos al sistema.
http://carolina.terna.net/ingsw3/datos/Pruebas_Funcionales.pdf
2. Prueba de Unidades
¿Cómo se prueban módulos sueltos?
Normalmente cabe distinguir una fase informal antes de entrar en la fase de pruebas propiamente dicha. La fase informal la lleva a cabo el propio codificador en su despacho, y consiste en ir ejecutando el código para convencerse de que "básicamente, funciona". Esta fase suele consistir en pequeños ejemplos que se intentan ejecutar. Si el módulo falla, se suele utilizar un depurador para observar la evolución dinámica del sistema, localizar el fallo, y repararlo.
En lenguajes antiguos, poco rigurosos en la sintaxis y/o en la semantica de los programas, esta fase informal llega a ser muy dura, laboriosa, y susceptible de dejar pasar grandes errores sin que se note. En lenguajes modernos, con reglas estrictas, hay herramientas que permiten análisis exhaustivos de los aspectos estáticos de la semántica de los programas: tipado de las variables, ámbitos de visibilidad, parámetros de llamada a procedimientos, etc etc
Hay asimismo herramientas más sofisticadas capaces de emitir "opiniones" sobre un programa y alertar de construcciones arriesgadas, de expresiones muy complicadas (que se prestan a equivocaciones), etc. etc. A veces pueden prevenir sobre variables que pueden usarse antes de tomar algún valor (no inicializadas), variables que se cargan pero luego no se usan, y otras posibilidades que, sin ser necesariamente errores en sí mismas, sí suelen apuntar a errores de verdad.
Más adelante, cuando el módulo parece presentable, se entra en una fase de prueba sistemática. En esta etapa se empieza a buscar fallos siguiendo algún criterio para que "no se escape nada". Los criterios más habituales son los denominados de caja negra y de caja blanca.
Se dice que una prueba es de caja negra cuando prescinde de los detalles del código y se limita a lo que se ve desde el exterior. Intenta descubrir casos y circunstancias en los que el módulo no hace lo que se espera de él.
Por oposición al término "caja negra" se suele denominar "caja blanca" al caso contrario, es decir, cuando lo que se mira con lupa es el código que está ahí escrito y se intenta que falle. Quizás sea más propio la denominación de "pruebas de caja transparente".
2.1. Caja blanca
Sinónimos:
Pruebas estructurales
Pruebas de caja transparente
En estas pruebas estamos siempre observando el código, que las pruebas se dedican a ejecutar con ánimo de "probarlo todo". Esta noción de prueba total se formaliza en lo que se llama "cobertura" y no es sino una medida porcentual de ¿cuánto código hemos cubierto?
Hay diferentes posibilidades de definir la cobertura. Todas ellas intentan sobrevivir al hecho de que el número posible de ejecuciones de cualquier programa no trivial es (a todos los efectos prácticos) infinito. Pero si el 100% de cobertura es infinito, ningún conjunto real de pruebas pasaría de un infinitésimo de cobertura. Esto puede ser muy interesante para los matemáticos; pero no sirve para nada.
Cobertura de segmentos
A veces también denominada "cobertura de sentencias". Por segmento se entiende una secuencia de sentencias sin puntos de decisión. Como el ordenador está obligado a ejecutarlas una tras otra, es lo mismo decir que se han ejecutado todas las sentencias o todos los segmentos.
El número de sentencias de un programa es finito. Basta coger el código fuente e ir contando. Se puede diseñar un plan de pruebas que vaya ejercitando más y más sentencias, hasta que hayamos pasado por todas, o por una inmensa mayoría.
En la práctica, el proceso de pruebas termina antes de llegar al 100%, pues puede ser excesivamente laborioso y costoso provocar el paso por todas y cada una de las sentencias. A la hora de decidir el punto de corte antes de llegar al 100% de cobertura hay que ser precavido y tomar en consideración algo más que el índice conseguido. En efecto, ocurre con harta frecuencia que los programas contienen código muerto o inalcanzable. Puede ser que este trozo del programa, simplemente "sobre" y se pueda prescindir de él; pero a veces significa que una cierta funcionalidad, necesaria, es inalcanzable: esto es un error y hay que corregirlo.
2.2. Caja negra
Sinónimos:
Pruebas de caja opaca
Pruebas funcionales
Pruebas de entrada/salida
Pruebas inducidas por los datos
Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.
Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc etc) Este comentario no obsta para que sean útiles en cualquier módulo del sistema.
Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. Es fácil obtener coberturas del 100% en módulos internos, aunque puede ser más laborioso en módulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura en esta línea.
El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables); sino en los datos que se le pasan a estas funciones. El conjunto de datos posibles suele ser muy amplio (por ejemplo, un entero).
A la vista de los requisitos de un módulo, se sigue una técnica algebráica conocida como "clases de equivalencia". Esta técnica trata cada parámetro como un modelo algebráico donde unos datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia, entonces es suficiente probar un caso de cada clase, pues los demás datos de la misma clase son equivalentes.
El problema está pues en identificar clases de equivalencia, tarea para la que no existe una regla de aplicación universal; pero hay recetas para la mayor parte de los casos prácticos:
si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.
si una entrada es booleana, hay 2 clases: si o no. los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.
3. Pruebas de Integración
Las pruebas de integración se llevan a cabo durante la construcción del sistema, involucran a un número creciente de módulos y terminan probando el sistema como conjunto.
Estas pruebas se pueden plantear desde un punto de vista estructural o funcional.
Las pruebas estructurales de integración son similares a las pruebas de caja blanca; pero trabajan a un nivel conceptual superior. En lugar de referirnos a sentencias del lenguaje, nos referiremos a llamadas entre módulos. Se trata pues de identificar todos los posibles esquemas de llamadas y ejercitarlos para lograr una buena cobertura de segmentos o de ramas.
Las pruebas funcionales de integración son similares a las pruebas de caja negra. Aquí trataremos de encontrar fallos en la respuesta de un módulo cuando su operación depende de los servicios prestados por otro(s) módulo(s). Según nos vamos acercando al sistema total, estas pruebas se van basando más y más en la especificación de requisitos del usuario.
Las pruebas finales de integración cubren todo el sistema y pretenden cubrir plenamente la especificación de requisitos del usuario. Además, a estas alturas ya suele estar disponible el manual de usuario, que también se utiliza para realizar pruebas hasta lograr una cobertura aceptable.
En todas estas pruebas funcionales se siguen utilizando las técnicas de partición en clases de equivalencia y análisis de casos límite (fronteras).
4. Pruebas de Aceptación
Estas pruebas las realiza el cliente. Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sería impresentable de cara al cliente; sino una vez pasada todas las pruebas de integración por parte del desarrollador.
La experiencia muestra que aún después del más cuidadoso proceso de pruebas por parte del desarrollador, quedan una serie de errores que sólo aparecen cuando el cliente se pone a usarlo. Los desarrolladores se suelen llevar las manos a la cabeza:
"Pero, ¿a quién se le ocurre usar así mi programa?"
Sea como sea, el cliente siempre tiene razón. Decir que los requisitos no estaban claros, o que el manual es ambiguo puede salvar la cara; pero ciertamente no deja satisfecho al cliente. Alegar que el cliente es un inútil es otra tentación muy fuerte, que conviene reprimir.
Por estas razones, muchos desarrolladores ejercitan unas técnicas denominadas "pruebas alfa" y "pruebas beta". Las pruebas alfa consisten en invitar al cliente a que venga al entorno de desarrollo a probar el sistema. Se trabaja en un entorno controlado y el cliente siempre tiene un experto a mano para ayudarle a usar el sistema y para analizar los resultados.
Las pruebas beta vienen después de las pruebas alfa, y se desarrollan en el entorno del cliente, un entorno que está fuera de control. Aquí el cliente se queda a solas con el producto y trata de encontrarle fallos (reales o imaginarios) de los que informa al desarrollador.
Las pruebas alfa y beta son habituales en productos que se van a vender a muchos clientes. Algunos de los potenciales compradores se prestan a estas pruebas bien por ir entrenando a su personal con tiempo, bien a cambio de alguna ventaja económica (mejor precio sobre el producto
final, derecho a mantenimiento gratuito, a nuevas versiones, etc etc). La experiencia muestra que estas prácticas son muy eficaces.
Prueba Funcional.
‡ Objetivo:
Se asegura el trabajo apropiado de los requisitos funcionales,
Incluyendo la navegación, entrada de datos, procesamiento y
Obtención de resultados.
Pruebas Funcionales – Software II – Mayo 2005
‡ Metas de estas pruebas son:
Verificar el procesamiento, recuperación e
Implementación adecuada de las reglas del
Negocio.
Verificar la apropiada aceptación de datos.
‡ Enfoque:
Los requisitos funcionales (Casos de Uso)
Y las reglas del negocio.
Prueba de Seguridad.
‡ Objetivo:
Nivel de Seguridad de la Aplicación: Verifica que un actor solo
Pueda acceder a las funciones y datos que su usuario tiene
Permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores
Con acceso al sistema y a la aplicación están habilitados para
Accederla.
Pruebas Funcionales – Software II – Mayo 2005
‡ Áreas:
Seguridad del sistema, incluyendo
Acceso a datos o Funciones de negocios.
Seguridad del sistema, incluyendo
Ingresos y accesos remotos al sistema.
http://carolina.terna.net/ingsw3/datos/Pruebas_Funcionales.pdf
Suscribirse a:
Entradas (Atom)