Criterios de clasificación

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Criterios de clasificación"

Transcripción

1 Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre un mismo conjunto podemos definir distintos criterios de clasificación, y los elementos pueden reagruparse según cada uno de éstos. Por ejemplo podemos clasificar a las personas según su estatura (alto, mediano, bajo) o su edad (niño, joven, adulto, anciano) y además podemos clasificar a un niño según su estatura. Cuando entramos en el mundo del testing comenzamos a oír y leer términos que refieren a distintos tipos de pruebas. Algunos de estos tipos de prueba son: En el ámbito del testing podemos distinguir también varios criterios de clasificación, algunos relativos a las pruebas, o tros al contexto. Podemos clasificar las pruebas según los siguientes criterios: -->El conocimiento del código -->La etapa de desarrollo del software -->El aspecto a evaluar del software

2 A continuación se definen y clasifican distintos tipos de testing. Clasificación según el conocimiento del código Pruebas de caja negra Se trata al sistema como una caja negra, de la que no se conoce ni su contenido ni su estructura interna. Para la ejecución de pruebas de caja negra, se suministran datos de entrada al sistema, se observa la salida obtenida y se compara con la salida esperada. Si bien no conocemos la estructura interna del sistema, sabemos cómo se espera que se comporte. Pruebas de caja blanca En las pruebas de caja blanca se piensan y diseñan casos de prueba conociendoel código del software. Se seleccionan los caminos del programa y el flujo de datos a ejercitar durante las pruebas. Comúnmente se conoce con el nombre de testing de caja blanca para contrastar con el testing de caja negra, pero sería más apropiado el nombre caja transparente, ya que a través de una caja blanca tampoco podemos ver lo que tiene adentro. Este tipo de testing también se denomina estructural. En general, el testing de caja transparente es realizado por el desarrollador que escribió el código o por otro desarrollador, ya que las pruebas están fuertemente ligadas al código. Sin embargo, puede darse el caso de que un equipo de testing interno o externo deba hacer este tipo de pruebas, por ejemplo para un módulo crítico. Es importante destacar que las pruebas de caja blanca están enfocadas a identificar debilidades en el diseño del código y no a detectar discrepancias entre los requerimientos y su implementación. En las pruebas de caja blanca los programas son vistos en términos de unidades de código que interactúan entre sí.

3 Pruebas de caja gris En las pruebas de caja gris se tiene un conocimiento limitado del código y la estructura interna del software. Se establece un diálogo programador-tester o bien se estudia la documentación técnica para conocer sobre la estructura interna del sistema. Por ejemplo, podemos ejecutar pruebas de cada gris si tenemos acceso a la base de datos del sistema, aunque no conozcamos el código. Clasificación según el conocimiento del código Según este criterio, dependiendo del grado de conocimiento que se tenga del código y la estructura interna del software, las pruebas se clasifican en: pruebas de caja negra, caja blanca o caja gris. Clasificación según la etapa de desarrollo Pruebas unitarias En este tipo de pruebas, se prueban de forma aislada las unidades o conjunto de unidades relacionadas de un software.

4 Podemos considerar una unidad como una clase, un método,un componente o un subsistema. Las pruebas unitarias intentan detectar discrepancias entre los requerimientos y el comportamiento real de la unidad. Se pone énfasis en verificar la especificación de la interfaz de las unidades. Estas pruebas pueden ser manuales, o automatizadas, pueden ser ejecutadas por quien desarrolló el software o por un tercero y pueden ser de caja negra, blanca o gris. Pruebas de integración La integración es el proceso en el cual los componentes son agregados para crear componentes más grandes. En las pruebas integración componentes de software y hardware son combinados para evaluar su interacción. Uno de los objetivos de este tipo de prueba es identificar problemas cuando se combinan los componentes. Las pruebas de integración pueden ser de caja negra, caja blanca o transparente o caja gris y pueden ser ejecutadas por distintos actores. En general requieren de la participación de los desarrolladores, que conocen los detalles de la integración: interfaces, tablas, servicios, mensajes, por ejemplo. Hay varias estrategias para las pruebas de integración, en las que ahora no entraremos en detalle. Pruebas del sistema Estas pruebas tienen como objetivo evaluar el comportamiento del sistema en su conjunto, verificando el cumplimiento de los requerimientos explícitos e implícitos. Son pruebas sobre la aplicación integrada. En estas pruebas se considera el hardware y el software definido, similar al de producción,y se tienen en cuenta las interfaces externas, los dispositivos de hardware, y el ambiente de ejecución. En las pruebas del sistema se evalúa: <!--[if!supportlists]--><!--[endif]-->funcionalidad: se evalúa si las funcionalidades definidas para el software se comportan como es esperado. <!--[if!supportlists]--><!--[endif]-->seguridad: se evalúa si el sistema protege los datos manipulados, maneja autenticación y autorización.

5 <!--[if!supportlists]--><!--[endif]-->usabilidad: se evalúa la facilidad con la que un usuario puede aprender a manejar, preparar las entradas e interpretar las salidas de un sistema o componente de software. <!--[if!supportlists]--><!--[endif]-->configuración e instalación: se evalúa que una versión del producto pueda ser instalada y configurada por el usuario. <!--[if!supportlists]--><!--[endif]-->escalabilidad: se estudian los cambios a nivel de hardware y de software. <!--[if!supportlists]--><!--[endif]-->desempeño: se evalúa el rendimiento o performance del sistema. <!--[if!supportlists]--><!--[endif]-->volumen: se evalúa el sistema funcionado con un gran volumen de datos. <!--[if!supportlists]--><!--[endif]-->carga: se evalúa el sistema con la máxima cantidad definida de usuarios concurrentes. <!--[if!supportlists]--><!--[endif]-->stress: Se evalúa el sistema más allá de los límites para los que fue diseñado, considerando volumen y carga simultáneamente. <!--[if!supportlists]--><!--[endif]-->y más.. Por ejemplo, las pruebas de un sistema web pueden incluir pruebas con diferentes navegadores, además de pruebas de desempeño en los servidores donde correrá la aplicación. También se prueban interfaces con otros sistemas, como por ejemplo la interacción entre Gmail y Google Docs Prueba de aceptación Las pruebas de aceptación son efectuadas por el cliente o una entidad que lo represente, para dar su conformidad con el producto liberado.

6 El objetivo de estas pruebas es evaluar si el software puede ser utilizado por el usuario final para realizar las funciones y tareas para las que fue construido o adquirido. Ejemplos de pruebas de aceptación pueden ser pruebas que hacen usuarios que trabajan en la empresa cliente, o pruebas de humo que ejecutan testers (en este caso los testers son los clientes del producto ) Este tipo de prueba se encuentra más ligado a la validación que a la verificación, ya que se trabaja más cerca de los requerimientos. La prueba de aceptación puede ser: <!--[if!supportlists]-->formal : extensión de la prueba del sistema. <!--[if!supportlists]--><!--[endif]-->informal: se identifican las funciones pero no hay casos de prueba a seguir. El usuario final determina qué hacer. <!--[if!supportlists]--><!--[endif]-->alfa: Pruebas realizadas por el usuario final en la organización de desarrollo. <!--[if!supportlists]--><!--[endif]-->beta: El usuario final es responsable de crear el ambiente, seleccionar sus datos y decidir qué funciones explorar. Es responsable por identificar su propio criterio de aceptación. Pueden participar testers y usuarios. Según Michel Bolton, las distintas organizaciones consideran las pruebas de aceptación de formas diversas, por ejemplo como: <!--[if!supportlists]-->una ceremonia, en la que no hay testing real... sino más bien, un paso protocolar que hay que cumplir para que se haga efectivo un cobro o un cierre de contrato. <!--[if!supportlists]--><!--[endif]-->una demostración, donde no se quiere que aparezcan errores, para convencer o capacitar a cierto auditorio. <!--[if!supportlists]--><!--[endif]-->un ejercicio suave, con pruebas simples, mediante las cuales se procura salir airoso del paso. <!--[if!supportlists]--><!--[endif]-->la búsqueda de un chivo expiatorio procurando detectar el error que provoque la no

7 aceptación. Este caso se da generalmente, cuando hay problemas entre las empresas y no se quiere aceptar el producto. Puede darse también como: <!--[if!supportlists]-->pruebas de sondeo <!--[if!supportlists]--><!--[endif]-->desafiando al software, buscando romperlo y al no hacerlo confirmar que éste funciona <!--[if!supportlists]--><!--[endif]-->investigación imparcial, crítica y de apoyo <!--[if!supportlists]--><!--[endif]-->buscando un software de alta calidad Diferentes formas podrían ser correctas según el contexto. Es fundamental entender la misión y adecuar el enfoque, la estrategia y las técnicas a utilizar. Las pruebas de aceptación entrañan un riesgo para un proyecto de software. Pueden surgir múltiples obstáculos, entre los cuales: Foco en detalles insignificantes en lugar de las funcionalidades y ciclos funcionales más significativos. Usuarios no adecuados o preparados para la tarea. Reacción negativa frente al cambio y no frente al software. Criterios de aceptación inciertos, funcionalidades y ciclos funcionales no priorizados. Perfiles de uso del producto no estudiados. Si se está en un proyecto que involucra pruebas de aceptación es recomendable considerarlas lo antes posible. Pruebas de regresión

8 Su objetivo es verificar que no ocurrió una regresión en la calidad del producto luego de un cambio. La modificación puede ser una nueva funcionalidad, la corrección de un error ya detectado o la actualización de uno o más componentes del software o hardware. En cualquier caso no es suficiente con probar la modificación solamente, porque ésta pudo haber tenido un impacto en otras "zonas" del producto. Las pruebas de regresión implican la reejecución de alguna o todas las pruebas ejecutadas anteriormente. Entre los tipos de pruebas de regresión podemos mencionar: <!--[if!supportlists]--><!--[endif]-->regresión de incidentes recientemente corregidos <!--[if!supportlists]--><!--[endif]-->regresión de antiguos incidentes, corregidos en versiones anteriores <!--[if!supportlists]--><!--[endif]-->regresión de efectos secundarios o <!--[if!supportlists]--><!--[endif]-->implica volver a probar una parte del producto o <!--[if!supportlists]--><!--[endif]-->el objetivo es probar que a raíz del cambio, algo que funcionaba ya no funciona La pregunta que surge inmediatamente es: Es posible reejecutar siempre todas las pruebas? La respuesta no es trivial y es un nuevo desafío para los testers. Existen varias estrategias para decidir qué casos de prueba reejecutar. Todas tienen ventajas y desventajas. Por ejemplo, si siempre reejecutamos las pruebas de las funcionalidades más críticas, podrían quedar funcionalidades que nunca volveríamos a probar. Lo que se recomienda y nosotros aplicamos es que antes de liberar un producto, se reejecuten todas las pruebas. La prueba de errores severos corregidos de forma urgente, constituye una

9 excepción, ya que es apremiante liberar el producto inmediatamente. Pero lo que no puede suceder es que esos casos de prueba se pierdan y no sea incorporados a las sucesivas pruebas de regresión del producto. Tanto en las pruebas unitarias, de integración, del sistema, o de aceptación pueden ejecutarse pruebas de regresión. <!--[endif]--> Ejemplo Por ejemplo en Gmail, los desarrolladores del módulo correo prueban el envío de correos, los desarrolladores de Chat prueban el envío de mensajes, y otro equipo prueba los filtros de búsqueda y cómo se visualizan. Todos estos son ejemplos de pruebas unitarias, considerando cada componente como una unidad. En las pruebas de integración, se verifica que los módulos interactúan como se esperaba, por ejemplo, haciendo una búsqueda en las conversaciones almacenadas y visualizándolas de la misma forma que se visualizan los mails. Supongamos que durante las pruebas se detecta un defecto en el módulo de correo y el defecto es solucionado por el equipo de desarrolladores. Luego, se ejecutarán pruebas de regresión (se vuelve a probar el módulo y la interacción con los otros módulos), para comprobar que el defecto fue solucionado y que no se introdujeron nuevos defectos. Clasificación según la etapa de desarrollo Según este criterio, dependiendo de en qué etapa del desarrollo de software se hacen las pruebas, se clasifican en:pruebas unitarias, de integración, de sistema, de regresión y de aceptación. Es importante destacar que el momento, la forma y la frecuencia con que se ejecutan estas pruebas depende del proceso de desarrollo que se utilice.

10 Clasificación según el aspecto a evaluar Pruebas funcionales Las pruebas funcionales se enfocan en verificar la capacidad del sistema de realizar ciertas funcionalidades. Se basan en qué hace el sistema y consideran el punto de vista del usuario y generalmente, se utiliza un enfoque de caja negra. Pruebas para-funcionales Las pruebas para-funcionales verifican otros atributos del sistema, enfocándose en cómo el sistema cumple con las funcionalidades. Usualmente a este tipo de pruebas se les llama pruebas no-funcionales, sin embargo el rendimiento y performance del sistema son parte del comportamiento de las funcionalidades del sistema. Por lo que decidimos llamarle pruebas para-funcionales a aquellas que tienen por objetivo evaluar aspectos relacionados a la rapidez (transacciones por seg.), el tamaño (KB) y a la fiabilidad (tiempo promedio entre fallas, recuperación ante errores), entre otros aspectos. Por ejemplo las pruebas de usabilidad, escalabilidad, rapidez, seguridad, tamaño, portabilidad (sistemas operativos, navegadores) se consideran pruebas parafuncionales. Clasificación según el aspecto a evaluar

11 Resumiendo Trabajamos con 3 criterios de clasificación, pero siempre podemos barajar y dar de nuevo. Por ejemplo: Estos son los únicos criterios posibles?

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Control de Calidad de Software. Ing. Jorge Montaño Párraga

Control de Calidad de Software. Ing. Jorge Montaño Párraga Control de Calidad de Software Ing. Jorge Montaño Párraga Agenda Contenido Porque es necesario controlar la calidad? Que es testear? 7 Principios de Control de Calidad Proceso Fundamental de SQA Porque

Más detalles

6.4 ESTRATEGIAS DE PRUEBA

6.4 ESTRATEGIAS DE PRUEBA Prueba del sistema Prueba de validación Prueba de integración Prueba de Unidad Código Diseño Requisitos Ingeniería del Sistema Las pruebas del software aplican similar estrategia moviéndonos de adentro

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1 Calidad y Software Evento ONGEI 29 mar 11 www.asistp.com 1 Agenda La Calidad y los Procesos El Proceso de Software Las pruebas de Software www.asistp.com 2 Calidad www.asistp.com 3 Calidad algunas definiciones

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Temario III Testing in the Large

Temario III Testing in the Large Temario III Testing in the Large 1ra Parte Verificación y Validación de Software UNS 1 Contenidos Testing de Integración Testing de Sistema Testing de Regresión Verificación y Validación de Software UNS

Más detalles

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS

CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS CLASE # 4 DESCRIPCIÓN GENERAL DE LAS PRUEBAS DINÁMICAS 750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA

Más detalles

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Pruebas Universidad Técnica del Norte Histórico

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

Sistemas de gestión de la calidad Requisitos

Sistemas de gestión de la calidad Requisitos Sistemas de gestión de la calidad Requisitos 1 Objeto y campo de aplicación 1.1 Generalidades Esta Norma Internacional especifica los requisitos para un sistema de gestión de la calidad, cuando una organización

Más detalles

Testing. Tipos, Planificación y Ejecución de Pruebas

Testing. Tipos, Planificación y Ejecución de Pruebas Testing Tipos, Planificación y Ejecución de Pruebas Contenido Definiciones del Testing de Software Objetivos, conceptos Tipos de Test Testing a-la RUP Rol del Testing en el proceso Artefactos Trabajadores

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones

Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0. Historia de revisiones Sistema de Gestión del Plan de Obras Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 22/08/2005 1.0 Versión preliminar Horacio Nova 25/08/2005 1.0 Versión

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

1. Descripción y objetivos

1. Descripción y objetivos Pruebas 1 1. Descripción y objetivos Las pruebas son prácticas a realizar en diversos momentos de la vida del sistema de información para verificar: El correcto funcionamiento de los componentes del sistema.

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010 SSTQB Nivel Fundamentos Examen ejemplo Página 1 de 12 Fecha publicación: 28 - octubre - 2015 Índice Preguntas... 3 Respuestas... 12 Página 2 de 12 Fecha publicación: 28 - octubre - 2015 Preguntas 1 2 Una

Más detalles

El Software. Es lo que se conoce como el ciclo de vida del software.

El Software. Es lo que se conoce como el ciclo de vida del software. El Software Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación, y mejora. Para construir un nuevo elemento software

Más detalles

E 2.4.1 Documento de entrega de Aplicación

E 2.4.1 Documento de entrega de Aplicación E 2.4.1 Documento de entrega de Aplicación Versión: 0.1 Fecha: 11/08/11 Autor: Email: Antoni Bertran Bellido abertran@opentrends.net Historial de cambios Versión Fecha Autor Cambios 0.1 11/08/11 Antoni

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL Página 1 de 23 CUALIFICACIÓN PROFESIONAL Familia Profesional Nivel 3 Código IFC363_3 Versión 5 Situación RD 1701/2007 Actualización ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS

Más detalles

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba Pruebas Pruebas en el PUD Las pruebas del software Diseño de casos de prueba Tipos de prueba Estrategias de prueba 1 2 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos

Más detalles

Q-flow 3.1: Introducción a Q-flow

Q-flow 3.1: Introducción a Q-flow Q-flow 3.1: Introducción a Q-flow Código del manual: Qf310001ESP Versión: 1.1 Se aplica a: Q-flow 3.1 Última revisión: 13/12/2010 i Q f 3 1 0 0 0 1 E S P v 1. 1 Q - f l o w 3.1 Introducción a Q-flow Urudata

Más detalles

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M No. REQUISITOS EXISTE ESTADO OBSERVACIONES 4. SISTEMA DE GESTION DE LA CALIDAD 4.1 Requisitos Generales La organización debe establecer, documentar, implementar y mantener un S.G.C y mejorar continuamente

Más detalles

Capítulo 11. Conclusiones y trabajo futuro

Capítulo 11. Conclusiones y trabajo futuro Capítulo 11. Conclusiones y trabajo futuro En esta tesis ha realizado un entorno de desarrollo Web que proporciona herramientas para la mejora de la calidad del código de los desarrolladores. Para conseguir

Más detalles

Extensión K2B proyectos para Smart Devices

Extensión K2B proyectos para Smart Devices Extensión K2B proyectos para Smart Devices Descripción de la Arquitectura Versión 2.0 15/10/2012 Historia de revisiones Fecha Versión Descripción Autor 28/08/2012 1.0 Creación del documento Diego Cardozo

Más detalles

NORMA TÉCNICA NTC- ISO COLOMBIANA 9001

NORMA TÉCNICA NTC- ISO COLOMBIANA 9001 NORMA TÉCNICA NTC- ISO COLOMBIANA 9001 2008-11-14 SISTEMA DE GESTIÓN DE LA CALIDAD. REQUISITOS E: QUALITY MANAGEMENT SYSTEMS. REQUIREMENTS CORRESPONDENCIA: esta norma es idéntica (IDT) a la norma ISO 9001:2008

Más detalles

Introducción a las Pruebas de Software

Introducción a las Pruebas de Software Introducción a las Pruebas de Software Contenido Contenido El ciclo de vida de la Calidad. Conceptos Generales de Pruebas. Proceso de Pruebas de So7ware. Obje;vos de las Pruebas de So7ware. Beneficios

Más detalles

2 Métodos combinatorios

2 Métodos combinatorios 2 Métodos combinatorios Las pruebas pueden aplicarse de muchas maneras, es decir, existen diferentes formas de preparar casos de prueba. En este capítulo se presentan dos formas de prueba muy fáciles de

Más detalles

NORMA ISO 9001:2008 Sistemas de Gestión de la Calidad - ÍNDICE. 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación.

NORMA ISO 9001:2008 Sistemas de Gestión de la Calidad - ÍNDICE. 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación. TEMA ÍNDICE PÁGINA 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación. 3 2 Referencias normativas. 3 3 Términos y definiciones.. 3 4 Sistema de gestión de la calidad. 4 4.1 Requisitos

Más detalles

cumple y hay evidencias objetivas

cumple y hay evidencias objetivas Lista de Verificación ISO :2008 LISTA DE VERIFICACIÓN ISO :2008 Sistemas de Gestión de la Calidad Pliego Objeto y campo de aplicación Esta lista de verificación tiene como objetivo conocer con mayor detalle

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Norma Internacional ISO 9001:2000

Norma Internacional ISO 9001:2000 Norma Internacional ISO 9001:2000 Esta norma ha sido traducida por el Grupo de Trabajo "Spanish Translation Task Group" del Comité Técnico ISO/TC 176, Gestión y aseguramiento de la calidad, en el que han

Más detalles

SIS 301 Operación y mantenimiento 15 minutos

SIS 301 Operación y mantenimiento 15 minutos SIS 301 Operación y mantenimiento 15 minutos O Generalidades 1 Planificación 2 Procedimientos 3 Responsabilidades del personal de operación 4 Responsabilidades del personal de mantenimiento 5 Mantenimiento

Más detalles

Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008

Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008 Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008 ISO 9001 CUATRO CAPÍTULOS BÁSICOS RESPONSABILIDADES DE LA DIRECCIÓN P D GESTIÓN DE RECURSOS REALIZACIÓN DEL PRODUCTO A C MEDICIÓN

Más detalles

Gestión de las Pruebas Funcionales

Gestión de las Pruebas Funcionales Gestión de las Pruebas Funcionales Beatriz Pérez Centro de Ensayos de Software Centro de Ensayos de Software Consorcio creado en Junio de 2004 entre Cámara Uruguaya de Tecnologías de la Información (CUTI)

Más detalles

Técnicas Avanzadas de Testing Automático

Técnicas Avanzadas de Testing Automático Técnicas Avanzadas de Testing Automático Marcelo Frias ITBA - Buenos Aires, Argentina CONICET Preliminares: Calidad Validación y Verificación Especificaciones y V&V Análisis estático y dinámico Inspecciones

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Implantación de Sistemas

Implantación de Sistemas Implantación de Sistemas Maria Ines Parnisari 17 de Diciembre de 2014 Índice Parte 1: Implantación... 2 Factores clave para una implantación exitosa... 2 Etapas de un proyecto de Sistemas... 2 Fases de

Más detalles

Ingeniería de Software Avanzada

Ingeniería de Software Avanzada Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Avanzada Dr. Marcello Visconti Z. Conceptos básicos de testing Una falla (failure) ocurre cuando un programa

Más detalles

LEY QUE NORMA EL USO, ADQUISICIÓN Y ADECUACIÓN DEL SOFTWARE EN LA ADMINISTRACIÓN PUBLICA

LEY QUE NORMA EL USO, ADQUISICIÓN Y ADECUACIÓN DEL SOFTWARE EN LA ADMINISTRACIÓN PUBLICA ADQUISICIÓN DE SOFTWARE DE CORREO 1. Nombre del Área :. Responsable de la Evaluación : Aldo Quispe Santa María. Cargo : Director (e) de Tecnología de la Información y Sistemas 4. Fecha : de Julio de 007

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

CUALIFICACIÓN OPERACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN OPERACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 23 CUALIFICACIÓN OPERACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC300_2 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Contenido. Tipos y niveles de pruebas de software Pruebas de caja negra

Contenido. Tipos y niveles de pruebas de software Pruebas de caja negra Hoy, la caja negra Aseguramiento de la calidad y pruebas de software 5- Pruebas del software Niveles y Caja Negra Blanca A. Vargas Govea vargasgovea@itesm.mx Marzo 1, 2013 Contenido Tipos y niveles de

Más detalles

POLÍTICAS DE SEGURIDAD PARA EL DESARROLLO DE SISTEMAS DE CAPUFE

POLÍTICAS DE SEGURIDAD PARA EL DESARROLLO DE SISTEMAS DE CAPUFE SISTEMAS DE ÍNDICE PÁGINA INTRODUCCIÓN OBJETIVO 3 FUNDAMENTO LEGAL 4 DEFINICIONES 5 POLÍTICAS 6 De la base de datos Del acceso a los sistemas De los sistemas Web Ambientes de Desarrollo, Calidad o Pruebas,

Más detalles

UTN Proyecto. Testing de Software - Calidad de productos de Software. Autor: Gabriela Muñoz

UTN Proyecto. Testing de Software - Calidad de productos de Software. Autor: Gabriela Muñoz UTN Proyecto Testing de Software - Calidad de productos de Software Autor: Gabriela Muñoz Índice ÍNDICE 2 1 FUNDAMENTOS DEL TESTING 7 1.1 CALIDAD DE SOFTWARE 7 1.2 CALIDAD 7 1.3 POR QUÉ ES NECESARIA LA

Más detalles

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... Tabla de Contenido PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... 2 1. LA PRESENCIA DE INFORMACIÓN Y AYUDA ÚTIL PARA COMPLETAR LOS TRÁMITES EN LÍNEA.... 2 2. LA DISPONIBILIDAD DE DIVERSOS

Más detalles

Actualización de la Norma ISO 9001:2008

Actualización de la Norma ISO 9001:2008 Actualización de la Norma ISO 9001:2008 Porqué se actualiza la norma? Existe un ciclo para revisar las normas ISO para mantener las normas actualizadas. Se debe mantener la actualización con desarrollos

Más detalles

TESTING. Universidad Simón Bolívar. Ing. de Software. Profa. Marlene Goncalves

TESTING. Universidad Simón Bolívar. Ing. de Software. Profa. Marlene Goncalves TESTING Universidad Simón Bolívar. Ing. de Software. Profa. Marlene Goncalves Definiciones Error: Equivocación cometida por un desarrollador. Ejemplos: un error de tipeo, una mal interpretación de un requerimiento

Más detalles

Gestión de las Pruebas Funcionales

Gestión de las Pruebas Funcionales Gestión de las Pruebas Funcionales Beatriz Pérez Lamancha (bperez@fing.edu.uy) Centro de Ensayos de Software Universidad de la República, Montevideo, Uruguay Resumen Se presenta en este artículo una estrategia

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Procedimiento de Paso a Producción de un Sistema Existente

Procedimiento de Paso a Producción de un Sistema Existente SERVICIO NACIONAL PARA LA PREVENCIÓN Y REHABILITACIÓN DEL CONSUMO DE DROGAS Y ALCOHOL Procedimiento de Paso a Producción de un Sistema Sistema de Gestión de la Seguridad de la Información Código: SSI-10-07.2

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

LX8_022 Requisitos técnicos de. instalación para el usuario

LX8_022 Requisitos técnicos de. instalación para el usuario LX8_022 Requisitos técnicos de instalación para el usuario FECHA NOMBRE FORMATO COMENTARIO AUTOR 28/04/2011 LX8_019 Requisitos técnicos de instalación para el usuario Grupo de desarrollo LexNet 24/04/2012

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA CUALIFICACIÓN PROFESIONAL: OPERACIÓN DE SISTEMAS INFORMÁTICOS. Código: IFC300_2 NIVEL: 2

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA CUALIFICACIÓN PROFESIONAL: OPERACIÓN DE SISTEMAS INFORMÁTICOS. Código: IFC300_2 NIVEL: 2 MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Calidad de Sistemas de Información

Calidad de Sistemas de Información Calidad de Sistemas de Información Introducción (2) Concepto de calidad Conjunto de propiedades y características de un producto, proceso o servicio que le hace satisfacer las necesidades establecidas

Más detalles

A continuación enlistamos estos pasos y seguido a ello describimos detalladamente cada uno de ellos:

A continuación enlistamos estos pasos y seguido a ello describimos detalladamente cada uno de ellos: Manual de Implementación del módulo de Contabilidad en Openbravo ERP. Como sabemos una de las características más importantes de un ERP es la capacidad de poder administrar de forma integrada la contabilidad

Más detalles

LABORATORIO 10. ADMINISTRACIÓN DE COPIAS DE SEGURIDAD EN SQL SERVER

LABORATORIO 10. ADMINISTRACIÓN DE COPIAS DE SEGURIDAD EN SQL SERVER LABORATORIO 10. ADMINISTRACIÓN DE COPIAS DE SEGURIDAD EN SQL SERVER GUÍA DE LABORATORIO Nº 1O Actividad de Proyecto No. 12: ESTABLECER PLANES DE RESGUARDO, RESTAURACION Y CONTINGENCIA. Estructura de contenidos.

Más detalles

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

Práctica de Evaluación de Cortafuegos personales

Práctica de Evaluación de Cortafuegos personales Práctica de Evaluación de Cortafuegos personales Objetivo El objetivo de esta práctica es que el alumno aprenda a configurar y evaluar cuál es la mejor opción de producto en relación a los cortafuegos

Más detalles

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR Ignacio.bayugar@mercadolibre.com, i id nachobayugar@gmail.com NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE El desarrollo ágil El nuevo rol de

Más detalles

Capítulo 4: Diseño de la solución basada en software. 4.1 Diseño general del sistema y especificaciones de los componentes

Capítulo 4: Diseño de la solución basada en software. 4.1 Diseño general del sistema y especificaciones de los componentes Capítulo 4: Diseño de la solución basada en software 4.1 Diseño general del sistema y especificaciones de los componentes El sistema constará de tres elementos fundamentales: los clientes, el punto de

Más detalles

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

6.3 CASOS DE PRUEBA CAJA BLANCA

6.3 CASOS DE PRUEBA CAJA BLANCA Tipos de Prueba: 6.3 CASOS DE PRUEBA CAJA BLANCA Prueba de la Ruta Básica Pruebas de la estructura de control Prueba de condición Prueba del flujo de datos Prueba de bucles 6.3.1 PRUEBA DE LA RUTA BASICA

Más detalles

ASIS Technology Partners. www.asistp.com 1

ASIS Technology Partners. www.asistp.com 1 ASIS Technology Partners www.asistp.com 1 Organización para el Testing de Software www.asistp.com 2 Por qué Testing? A nivel mundial cada año se pierden más de 500 billones de dólares en fallas de software

Más detalles

SISTEMAS DE ARCHIVOS DISTRIBUIDOS

SISTEMAS DE ARCHIVOS DISTRIBUIDOS SISTEMAS DE ARCHIVOS DISTRIBUIDOS Tema # VII Sistemas de operación II Abril-Julio 2008 Yudith Cardinale Introducción Requisitos Aspectos de Diseño Servicios de archivos Servicios de directorios Módulo

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

Prueba de software. Ingeniería de software Eduardo Ferreira, Martín Solari

Prueba de software. Ingeniería de software Eduardo Ferreira, Martín Solari Prueba de software Ingeniería de software Eduardo Ferreira, Martín Solari 1 Temario Prueba de software Estrategias, niveles y tipos de prueba Pruebas de caja blanca Pruebas de caja negra Proceso de prueba

Más detalles

Parte 1 Múltiple Opción

Parte 1 Múltiple Opción Cada pregunta de la parte múltiple opción contestada correctamente tiene un valor de 1,5 puntos. Cada pregunta incorrecta de la múltiple opción resta 0,5 puntos. Esta parte consta de 25 preguntas por lo

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Estructura de Bases de datos. Leonardo Víquez Acuña

Estructura de Bases de datos. Leonardo Víquez Acuña Estructura de Bases de datos Leonardo Víquez Acuña Lenguajes de Bases de Datos Un sistema de bases de datos proporciona Un lenguaje de definición de datos para especificar el esquema de la base de datos

Más detalles

DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO

DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO DIRECCIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO PROCEDIMIENTO PARA GESTIÓN DE DESARROLLO TECNOLÓGICO n Objetivo

Más detalles

ESTE EJERCICIO ES DE TIPO MIXTO.

ESTE EJERCICIO ES DE TIPO MIXTO. junio, 1ª semana, nacional 2012 ESTE EJERCICIO ES DE TIPO MIXTO. ES IRRELEVANTE SI CONTESTA A LA PREGUNTA DE TEST O NO. SIN EMBARGO, SE DEBE ESCANEAR DICHA HOJA JUNTO CON EL RESTO DE LA CONTESTACIÓN DEL

Más detalles

Guía de resolución de problemas de firma con certificado en la Sede Electrónica del CIEMAT

Guía de resolución de problemas de firma con certificado en la Sede Electrónica del CIEMAT Guía de resolución de problemas de firma con certificado en la Sede Electrónica del CIEMAT CONTENIDO El presente documento recoge una serie de indicaciones para poder resolver los problemas más comunes

Más detalles

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05

18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 18 y 19 Sistemas de Archivos Distribuidos y Tarea 05 Prof. Edgardo Adrián Franco Martínez http://computacion.cs.cinvestav.mx/~efranco efranco.docencia@gmail.com Estructuras de datos (Prof. Edgardo A. Franco)

Más detalles

CURSO DE SQL SERVER 2005

CURSO DE SQL SERVER 2005 CURSO DE SQL SERVER 2005 Una vez finalizado el curso, el alumno estará preparado para: Instalar y configurar SQL Server 2005. Comprender los conceptos más importantes del diseño de bases de datos. Crear

Más detalles

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Dr. Marcello Visconti Z. Programa Proceso de Software y Paradigmas de Desarrollo Gestión de Proyectos Fases del

Más detalles

APLICACIÓN DE ACCESO REMOTO PARA POCKET PC. MANUAL DE USUARIO (Release 1.42)

APLICACIÓN DE ACCESO REMOTO PARA POCKET PC. MANUAL DE USUARIO (Release 1.42) APLICACIÓN DE ACCESO REMOTO PARA POCKET PC MANUAL DE USUARIO () Índice INTRODUCCIÓN... 3 MANUAL INSTALACIÓN DEL SOFTWARE... 4 GUIA USUARIO... 5 Iniciar la Aplicación Control Remoto... 5 Bienvenido... 5

Más detalles

DOCUMENTO DE REFERENCIA MECI SISTEMA INTEGRADO DE GESTIÓN. Contenido DOCUMENTO MECI - CALIDAD... 3 1. ARMONIZACIÓN CONCEPTUAL... 3

DOCUMENTO DE REFERENCIA MECI SISTEMA INTEGRADO DE GESTIÓN. Contenido DOCUMENTO MECI - CALIDAD... 3 1. ARMONIZACIÓN CONCEPTUAL... 3 Contenido DOCUMENTO MECI - CALIDAD... 3 1. ARMONIZACIÓN CONCEPTUAL... 3 1.1 SISTEMA DE GESTIÓN... 3 1.2 SISTEMA DE GESTIÓN EN EL ESTADO COLOMBIANO... 4 2. : MODELO ESTANDAR DE CONTROL INTERNO MECI Y SISTEMA

Más detalles

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte

AUDITORIA DE SISTEMAS. Jorge Alberto Blanco Duarte AUDITORIA DE SISTEMAS Jorge Alberto Blanco Duarte QUE ES LA AUDITORIA DE SISTEMAS? La auditoria en informática es la revisión y la evaluación de los controles, sistemas, procedimientos de informática;

Más detalles

GUIA DE AUTOEVALUACION PARA LA IMPLEMENTACION DE SISTEMA DE GESTIÓN DE CALIDAD

GUIA DE AUTOEVALUACION PARA LA IMPLEMENTACION DE SISTEMA DE GESTIÓN DE CALIDAD GUA DE AUTOEVALUACON PARA LA MPLEMENTACON DE SSTEMA DE GESTÓN DE CALDAD SERVCO NACONAL DE CAPACTACON Y EMPLEO DEPARTAMENTO DE CAPACTACÓN EN EMPRESAS PROGRAMA GESTÓN DE CALDAD PARA OTEC Versión 2004 NTRODUCCON

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

Escogiendo un sistema host

Escogiendo un sistema host 2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en www.plantwebuniversity.com. Fieldbus 402 Escogiendo un sistema host Generalidades Experiencia del proveedor

Más detalles

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

Más detalles

Norma Internacional ISO 9001:2008: Sistemas de Gestión de la Calidad- Requisitos. 4. Sistema de Gestión de la Calidad

Norma Internacional ISO 9001:2008: Sistemas de Gestión de la Calidad- Requisitos. 4. Sistema de Gestión de la Calidad Norma Internacional ISO 9001:2008: Sistemas de Gestión de la Calidad- Requisitos 4. Sistema de Gestión de la Calidad Figura N 1. Estructura del capítulo 4, Norma ISO 9001:2008. La Norma ISO 9001: 2008

Más detalles