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
miércoles, 23 de junio de 2010
4.3 Establecer Relacion Entre las Tablas Creadas
Establecer Relacion Entre las Tablas Creadas
Una vez creadas tablas independientes para cada tema de la base de datos, se necesita una forma de indicar a Access cómo debe combinar la información. El primer paso de este proceso consiste en definir relaciones entre las tablas. Una vez realizada esta operación, ya se puede comenzar a crear otros tipos de objetos, como consultas, formularios e informes para mostrar información de varias tablas a la vez.
En una relación se hacen coincidir los datos de los campos clave (normalmente un campo con el mismo nombre en ambas tablas). En la mayoría de los casos, estos campos coincidentes son la //clave principal// de una tabla, que proporciona un identificador único para cada registro, y una clave externa de la otra tabla.
Por ejemplo, una tabla con información sobre empleados puede relacionarse con otra con datos de pedidos a través de un campo común que podría ser id. de empleado.A la hora de establecer relaciones entre tablas pueden presentarse tres situaciones diferentes:
====== Relación un======
La relación uno a varios es el tipo de relación más común. En este tipo de relación, un registro de la Tabla A puede tener muchos registros coincidentes en la Tabla B, pero un registro de la Tabla B sólo tiene un registro coincidente en la Tabla A.
Relación uno a uno En una relación uno a uno, cada registro de la Tabla A sólo puede tener un registro coincidente en la Tabla V, y viceversa. Este tipo de relación no es habitual, debido a que la mayoría de la información relacionada de esta forma estaría en una sola tabla. Puede utilizar la relación uno a uno para dividir una tabla con muchos campos, para aislar parte de una tabla puto por razones de seguridad o para almacenar información que sólo se aplica a un subconjunto de la tabla principal. Por ejemplo, puede crear una tabla que registre los empleados acogidos a un determinado plan de jubilación.
Una relación varios a varios es, en realidad, dos relaciones uno a varios con una tercera tabla cuya clave principal consta de dos campos: las claves externas de las otras dos tablas.Pero veamos cuáles son los pasos a seguir para definir una relación entre tablas:
1. Cierre todas las tablas que estén abiertas. No es posible crear ni modificar relaciones entre tablas abiertas.
2. Si se encuentra en otra ventana, cámbiese a la ventana Base de datos. Puede pulsar F11 para cambiar a la ventana Base de datos desde cualquier otra ventana.3. Pulse en el botón Relaciones de la barra de herramientas.
4.Pueden darse los siguientes casos:Si la base de datos no tiene ninguna relación definida, se mostrará automáticamente el cuadro de diálogo Mostrar tabla·
Si necesita agregar las tablas que desea relacionar y no aparece el cuadro de diálogo Mostrar tabla, pulse en el botón Mostrar tabla de la barra de herramientas.·
Si las tablas que desea relacionar ya están a la vista en el cuadro Mostrar tabla, continúe en el paso
5.Pulse dos veces en los nombres de las tablas que desea relacionar y, a continuación, cierre el cuadro de diálogo Mostrar tabla. Esto le situará en el cuadro de diálogo Relaciones
6.Arrastre el campo que desea relacionar de una tabla al campo relacionado de la otra tabla. Si desea arrastrar en una sola operación varios campos, mantenga pulsada la tecla CTRL mientras pulsa en cada uno de los campos para seleccionarlos antes de efectuar el arrastre. A la hora de asociar campos, tenga esto en cuenta· En la mayoría de los casos, se arrastra el campo de clave principal (mostrado en texto en negrita) de una tabla a un campo similar (normalmente con el mismo nombre) denominado la clave externa de la otra tabla.· Los campos relacionados no tienen que tener los mismos nombres, pero deben tener el mismo tipo de datos (con dos excepciones, como se explica en el punto cuatro) y deben contener el mismo tipo de información.· Cuando los campos coincidentes son campos Numéricos, deben tener el mismo valor de la propiedad Tamaño del campo.· Las dos excepciones a los tipos de datos coincidentes son que se pude hacer coincidir un campo Autonumérico con un campo Numérico si ambos campos tienen la propiedad Tamaños de campo establecida en id. de réplica.
7.Aparecerá el cuadro de diálogo Relaciones.Compruebe los nombres de los campos mostrados en las dos columnas para asegurarse de que son correctos. Puede cambiarlos si es necesario. Si es necesario, establezca las opciones de relación. Para obtener información acerca de un elemento específico del cuadro de diálogo Relaciones, pulse en el botón de signo de interrogación y después en el elemento en cuestión.
8.Pulse en el botón Crear para establecer la relación de forma efectiva.
9.Repita los pasos del 5 al 8 para cada pareja de tablas que desee relacionar.Al cerrar la ventana Relaciones, Access pregunta si desea guardar el diseño. Independientemente de si lo guarda o no, las relaciones creadas se guardan en la base de datos.En la ventana Relaciones puede realizar lo siguiente:
Si necesita ver todas las relaciones definidas en la base de datos, pulse en Mostrar todas las relaciones en la barra de herramientas. Para ver sólo las relaciones definidas para una tabla determinada, pulse en la tabla y después en el botón Mostrar relaciones directas en la barra de herramientas.
Si necesita realizar un cambio en el diseño de una tabla. Puede pulsar con el botón secundario del ratón en la tabla que desea modificar y seleccionar Diseño de tabla en el menú contextual.· Para crear una relación entre una tabla y si misma, agregue esa tabla dos veces. Esto resulta útil en situaciones en las que necesita realizar una búsqueda dentro de la misma tabla.
===== Definir una relación varios a varios entre tablas =====
Si necesita definir una relación varios a varios entre tablas, siga estos pasos:
1.Cree las dos tablas que tendrán una relación varios a varios.
2.Cree una tercera tabla, denominada //tabla de unión//, y agregue a ésta los campos con las mismas definiciones que los campos de clave principal de cada una de las otra dos tablas. En la tabla de unión, los campos de clave principal funcionan como claves externas. También puede agregar otros campos a la tabla de unión, exactamente igual que lo haría con cualquier otra tabla.
3.En la tabla de unión, establezca una clave principal que incluya los campos de clave principal de las otras dos tablas. He aquí un resumen de los pasos a seguir para conseguir esto:· Abra la tabla de unión en la vista Diseño.· Seleccione los campos que desea definir como clave principal (utilice CTRL para seleccionar ambos campos).· Pulse en el botón Clave principal de la barra de herramientas.
4.Defina una relación uno a varios entre cada una de las dos tablas principales y la tabla de unión, como se ha visto en el apartado anterior.Cuando necesite agregar datos a las tablas, tiene dos opciones:· Crear una consulta basada en ambas tablas.· Crear un formulario basado en las dos tablas.
===== Modificar una relación existente =====
Una vez definidas las relaciones, pueden modificarse éstas siguiendo estos pasos:
1. Cierre todas las tablas abiertas. Tenga presente que no se pueden modificar relaciones entre tablas que se encuentren abiertas.
2. Cambie a la ventana Base de datos (F11), si no estuviese ya en ella.
3. Pulse en le botón Relaciones de la barra de herramientas.
4. Si las tablas cuya relación desea modificar no están a la vista en la ventana Relaciones, pulse en el botón Mostrar tabla en la barra de herramientas y pulse dos veces en cada una de las tablas que desee agregar.
5. Para eliminar una relación, pulse dos veces en la línea correspondiente a la misma en la ventana Relaciones.
6. Establezca en el cuadro de diálogo Relaciones las nuevas opciones de las relaciones y pulse finalmente en el botón Aceptar.
http://www.wikilearning.com/curso_gratis/tablas_en_access-relacionar_tablas/3766-1
Una vez creadas tablas independientes para cada tema de la base de datos, se necesita una forma de indicar a Access cómo debe combinar la información. El primer paso de este proceso consiste en definir relaciones entre las tablas. Una vez realizada esta operación, ya se puede comenzar a crear otros tipos de objetos, como consultas, formularios e informes para mostrar información de varias tablas a la vez.
En una relación se hacen coincidir los datos de los campos clave (normalmente un campo con el mismo nombre en ambas tablas). En la mayoría de los casos, estos campos coincidentes son la //clave principal// de una tabla, que proporciona un identificador único para cada registro, y una clave externa de la otra tabla.
Por ejemplo, una tabla con información sobre empleados puede relacionarse con otra con datos de pedidos a través de un campo común que podría ser id. de empleado.A la hora de establecer relaciones entre tablas pueden presentarse tres situaciones diferentes:
====== Relación un======
La relación uno a varios es el tipo de relación más común. En este tipo de relación, un registro de la Tabla A puede tener muchos registros coincidentes en la Tabla B, pero un registro de la Tabla B sólo tiene un registro coincidente en la Tabla A.
Relación uno a uno En una relación uno a uno, cada registro de la Tabla A sólo puede tener un registro coincidente en la Tabla V, y viceversa. Este tipo de relación no es habitual, debido a que la mayoría de la información relacionada de esta forma estaría en una sola tabla. Puede utilizar la relación uno a uno para dividir una tabla con muchos campos, para aislar parte de una tabla puto por razones de seguridad o para almacenar información que sólo se aplica a un subconjunto de la tabla principal. Por ejemplo, puede crear una tabla que registre los empleados acogidos a un determinado plan de jubilación.
Una relación varios a varios es, en realidad, dos relaciones uno a varios con una tercera tabla cuya clave principal consta de dos campos: las claves externas de las otras dos tablas.Pero veamos cuáles son los pasos a seguir para definir una relación entre tablas:
1. Cierre todas las tablas que estén abiertas. No es posible crear ni modificar relaciones entre tablas abiertas.
2. Si se encuentra en otra ventana, cámbiese a la ventana Base de datos. Puede pulsar F11 para cambiar a la ventana Base de datos desde cualquier otra ventana.3. Pulse en el botón Relaciones de la barra de herramientas.
4.Pueden darse los siguientes casos:Si la base de datos no tiene ninguna relación definida, se mostrará automáticamente el cuadro de diálogo Mostrar tabla·
Si necesita agregar las tablas que desea relacionar y no aparece el cuadro de diálogo Mostrar tabla, pulse en el botón Mostrar tabla de la barra de herramientas.·
Si las tablas que desea relacionar ya están a la vista en el cuadro Mostrar tabla, continúe en el paso
5.Pulse dos veces en los nombres de las tablas que desea relacionar y, a continuación, cierre el cuadro de diálogo Mostrar tabla. Esto le situará en el cuadro de diálogo Relaciones
6.Arrastre el campo que desea relacionar de una tabla al campo relacionado de la otra tabla. Si desea arrastrar en una sola operación varios campos, mantenga pulsada la tecla CTRL mientras pulsa en cada uno de los campos para seleccionarlos antes de efectuar el arrastre. A la hora de asociar campos, tenga esto en cuenta· En la mayoría de los casos, se arrastra el campo de clave principal (mostrado en texto en negrita) de una tabla a un campo similar (normalmente con el mismo nombre) denominado la clave externa de la otra tabla.· Los campos relacionados no tienen que tener los mismos nombres, pero deben tener el mismo tipo de datos (con dos excepciones, como se explica en el punto cuatro) y deben contener el mismo tipo de información.· Cuando los campos coincidentes son campos Numéricos, deben tener el mismo valor de la propiedad Tamaño del campo.· Las dos excepciones a los tipos de datos coincidentes son que se pude hacer coincidir un campo Autonumérico con un campo Numérico si ambos campos tienen la propiedad Tamaños de campo establecida en id. de réplica.
7.Aparecerá el cuadro de diálogo Relaciones.Compruebe los nombres de los campos mostrados en las dos columnas para asegurarse de que son correctos. Puede cambiarlos si es necesario. Si es necesario, establezca las opciones de relación. Para obtener información acerca de un elemento específico del cuadro de diálogo Relaciones, pulse en el botón de signo de interrogación y después en el elemento en cuestión.
8.Pulse en el botón Crear para establecer la relación de forma efectiva.
9.Repita los pasos del 5 al 8 para cada pareja de tablas que desee relacionar.Al cerrar la ventana Relaciones, Access pregunta si desea guardar el diseño. Independientemente de si lo guarda o no, las relaciones creadas se guardan en la base de datos.En la ventana Relaciones puede realizar lo siguiente:
Si necesita ver todas las relaciones definidas en la base de datos, pulse en Mostrar todas las relaciones en la barra de herramientas. Para ver sólo las relaciones definidas para una tabla determinada, pulse en la tabla y después en el botón Mostrar relaciones directas en la barra de herramientas.
Si necesita realizar un cambio en el diseño de una tabla. Puede pulsar con el botón secundario del ratón en la tabla que desea modificar y seleccionar Diseño de tabla en el menú contextual.· Para crear una relación entre una tabla y si misma, agregue esa tabla dos veces. Esto resulta útil en situaciones en las que necesita realizar una búsqueda dentro de la misma tabla.
===== Definir una relación varios a varios entre tablas =====
Si necesita definir una relación varios a varios entre tablas, siga estos pasos:
1.Cree las dos tablas que tendrán una relación varios a varios.
2.Cree una tercera tabla, denominada //tabla de unión//, y agregue a ésta los campos con las mismas definiciones que los campos de clave principal de cada una de las otra dos tablas. En la tabla de unión, los campos de clave principal funcionan como claves externas. También puede agregar otros campos a la tabla de unión, exactamente igual que lo haría con cualquier otra tabla.
3.En la tabla de unión, establezca una clave principal que incluya los campos de clave principal de las otras dos tablas. He aquí un resumen de los pasos a seguir para conseguir esto:· Abra la tabla de unión en la vista Diseño.· Seleccione los campos que desea definir como clave principal (utilice CTRL para seleccionar ambos campos).· Pulse en el botón Clave principal de la barra de herramientas.
4.Defina una relación uno a varios entre cada una de las dos tablas principales y la tabla de unión, como se ha visto en el apartado anterior.Cuando necesite agregar datos a las tablas, tiene dos opciones:· Crear una consulta basada en ambas tablas.· Crear un formulario basado en las dos tablas.
===== Modificar una relación existente =====
Una vez definidas las relaciones, pueden modificarse éstas siguiendo estos pasos:
1. Cierre todas las tablas abiertas. Tenga presente que no se pueden modificar relaciones entre tablas que se encuentren abiertas.
2. Cambie a la ventana Base de datos (F11), si no estuviese ya en ella.
3. Pulse en le botón Relaciones de la barra de herramientas.
4. Si las tablas cuya relación desea modificar no están a la vista en la ventana Relaciones, pulse en el botón Mostrar tabla en la barra de herramientas y pulse dos veces en cada una de las tablas que desee agregar.
5. Para eliminar una relación, pulse dos veces en la línea correspondiente a la misma en la ventana Relaciones.
6. Establezca en el cuadro de diálogo Relaciones las nuevas opciones de las relaciones y pulse finalmente en el botón Aceptar.
http://www.wikilearning.com/curso_gratis/tablas_en_access-relacionar_tablas/3766-1
4.2 Asignar las Claves Principales a las Tablas Creadas
Asignar las Claves Principales a las Tablas Creadas
Antes de guardar la tabla tendremos que asignar una clave principal.
La clave principal proporciona un valor único para cada fila de la tabla y nos sirve de identificador de registros de forma que con esta clave podamos saber sin ningún tipo de equivocación el registro al cual identifica. No podemos definir más de una clave principal, pero podemos tener una clave principal compuesta por más de un campo.
Para asignar una clave principal a un campo, seguir los siguientes pasos:
Hacer clic sobre el nombre del campo que será clave principal.
Hacer clic sobre el botón Clave principal en el marco Herramientas de la pestaña Diseño.
A la izquierda del nombre del campo aparecerá una llave indicándonos que dicho campo es la clave principal de la tabla.
Si queremos definir una clave principal compuesta (basada en varios campos), seleccionar los campos pulsando simultaneamente la tecla Ctrl y el campo a seleccionar y una vez seleccionados todos los campos hacer clic en el borón anterior .
Importante: Recordar que un campo o combinación de campos que forman la clave principal de una tabla no puede contener valores nulos y no pueden haber dos filas en la tabla con el mismo valor en el campo/s clave principal.
Cuando intentemos insertar una nueva fila con valores que infrinjan estas dos reglas, el sistema no nos deja crear la nueva fila y nos devuelve un error de este tipo:
.
La clave principal proporciona un valor único para cada fila de la tabla y nos sirve de identificador de registros de forma que con esta clave podamos saber sin ningún tipo de equivocación el registro al cual identifica. No podemos definir más de una clave principal, pero podemos tener una clave principal compuesta por más de un campo.
Para asignar una clave principal a un campo, seguir los siguientes pasos:
Hacer clic sobre el nombre del campo que será clave principal.
Hacer clic sobre el botón Clave principal en el marco Herramientas de la pestaña Diseño.
A la izquierda del nombre del campo aparecerá una llave indicándonos que dicho campo es la clave principal de la tabla.
Si queremos definir una clave principal compuesta (basada en varios campos), seleccionar los campos pulsando simultaneamente la tecla Ctrl y el campo a seleccionar y una vez seleccionados todos los campos hacer clic en el borón anterior .
Importante: Recordar que un campo o combinación de campos que forman la clave principal de una tabla no puede contener valores nulos y no pueden haber dos filas en la tabla con el mismo valor en el campo/s clave principal.
Cuando intentemos insertar una nueva fila con valores que infrinjan estas dos reglas, el sistema no nos deja crear la nueva fila y nos devuelve un error de este tipo:
.
4.1 Crear Tablas de Acuerdo a los Atributos de Diseño
Crear Tablas de Acuerdo a los Atributos de Diseño
Para crear una tabla de datos tenemos que hacer clic en la pestaña Crear para visualizar sus opciones. En el marco Tablas podremos seleccionar estas opciones:
El botón Tabla abre la Vista Hoja de datos, consiste en introducir directamente los datos en la tabla y según el valor que introduzcamos en la columna determinará el tipo de datos que tiene la columna.
Vista diseño es el método que detallaremos en esta unidad didáctica
Plantillas de tabla crea una tabla de entre un listado que tiene predefinido, abre una tabla de este tipo y sólo tendrás que rellenarla con sus datos.
Listas de SharePoint consiste en crear un objeto compatible con un sitio SharePoint desde el que podrás compartir los datos almacenados en la lista o tabla con otras personans con acceso al mismo sitio.
Explicaremos a continuación la forma de crear una tabla en vista diseño. Este método consiste en definir la estructura de la tabla, es decir, definir las distintas columnas que esta tendrá y otras consideraciones como claves, etc...Otra forma rápida de llegar a la vista Diseño es seleccionando la vista desde la pestaña Hoja de datos, o haciendo clic en el botón de Vista de Diseño en la barra de estado:
Aparecerá la vista de Diseño de la tabla:
En la pestaña tenemos el nombre de la tabla (como todavía no hemos asignado un nombre a la tabla, Access le ha asignado un nombre por defecto Tabla1).
A continuación tenemos la rejilla donde definiremos las columnas que componen la tabla, se utiliza una línea para cada columna, así en la primera línea (fila) de la rejilla definiremos la primera columna de la tabla y así sucesivamente.
En la parte inferior tenemos a la izquierda dos pestañas (General y Búsqueda) para definir propiedades del campo es decir características adicionales de la columna que estamos definiendo.
Y a la derecha tenemos un recuadro con un texto que nos da algún tipo de ayuda sobre lo que tenemos que hacer, por ejemplo en este momento el cursor se encuentra en la primera fila de la rejilla en la columna Nombre del campo y en el recuadro inferior derecho Access nos indica que el nombre de un campo puede tener hasta 64 caracteres.
Vamos rellenando la rejilla definiendo cada una de las columnas que compondrá la tabla:
En la primera fila escribir el nombre del primer campo, al pulsar la tecla INTRO pasamos al tipo de datos, por defecto nos pone Texto como tipo de dato. Si queremos cambiar de tipo de datos, hacer clic sobre la flecha de la lista desplegable de la derecha y elegir otro tipo.
Para más información sobre los diferentes tipos de datos haz clic aquí .
Si deseas información sobre el asistente para búsquedas haz clic aquí .
Observa como una vez tengamos algún tipo de dato en la segunda columna, la parte inferior de la ventana, la correspondiente a Propiedades del campo se activa para poder indicar más características del campo, características que veremos con detalle en la unidad temática siguiente.
A continuación pulsar la tecla INTRO para ir a la tercera columna de la rejilla.
Esta tercera columna no es obligatorio utilizarla ya que únicamente sirve para introducir un comentario, normalmente una descripción del campo de forma que la persona que tenga que introducir datos en la tabla sepa qué debe escribir ya que este cometario aparecerá en la barra de estado de la hoja de datos.
Repetir el proceso hasta completar la definición de todos los campos (columnas) de la tabla.
Bibliografía:
http://www.aulaclic.es/access2007/t_3_1.htm
Para crear una tabla de datos tenemos que hacer clic en la pestaña Crear para visualizar sus opciones. En el marco Tablas podremos seleccionar estas opciones:
El botón Tabla abre la Vista Hoja de datos, consiste en introducir directamente los datos en la tabla y según el valor que introduzcamos en la columna determinará el tipo de datos que tiene la columna.
Vista diseño es el método que detallaremos en esta unidad didáctica
Plantillas de tabla crea una tabla de entre un listado que tiene predefinido, abre una tabla de este tipo y sólo tendrás que rellenarla con sus datos.
Listas de SharePoint consiste en crear un objeto compatible con un sitio SharePoint desde el que podrás compartir los datos almacenados en la lista o tabla con otras personans con acceso al mismo sitio.
Explicaremos a continuación la forma de crear una tabla en vista diseño. Este método consiste en definir la estructura de la tabla, es decir, definir las distintas columnas que esta tendrá y otras consideraciones como claves, etc...Otra forma rápida de llegar a la vista Diseño es seleccionando la vista desde la pestaña Hoja de datos, o haciendo clic en el botón de Vista de Diseño en la barra de estado:
Aparecerá la vista de Diseño de la tabla:
En la pestaña tenemos el nombre de la tabla (como todavía no hemos asignado un nombre a la tabla, Access le ha asignado un nombre por defecto Tabla1).
A continuación tenemos la rejilla donde definiremos las columnas que componen la tabla, se utiliza una línea para cada columna, así en la primera línea (fila) de la rejilla definiremos la primera columna de la tabla y así sucesivamente.
En la parte inferior tenemos a la izquierda dos pestañas (General y Búsqueda) para definir propiedades del campo es decir características adicionales de la columna que estamos definiendo.
Y a la derecha tenemos un recuadro con un texto que nos da algún tipo de ayuda sobre lo que tenemos que hacer, por ejemplo en este momento el cursor se encuentra en la primera fila de la rejilla en la columna Nombre del campo y en el recuadro inferior derecho Access nos indica que el nombre de un campo puede tener hasta 64 caracteres.
Vamos rellenando la rejilla definiendo cada una de las columnas que compondrá la tabla:
En la primera fila escribir el nombre del primer campo, al pulsar la tecla INTRO pasamos al tipo de datos, por defecto nos pone Texto como tipo de dato. Si queremos cambiar de tipo de datos, hacer clic sobre la flecha de la lista desplegable de la derecha y elegir otro tipo.
Para más información sobre los diferentes tipos de datos haz clic aquí .
Si deseas información sobre el asistente para búsquedas haz clic aquí .
Observa como una vez tengamos algún tipo de dato en la segunda columna, la parte inferior de la ventana, la correspondiente a Propiedades del campo se activa para poder indicar más características del campo, características que veremos con detalle en la unidad temática siguiente.
A continuación pulsar la tecla INTRO para ir a la tercera columna de la rejilla.
Esta tercera columna no es obligatorio utilizarla ya que únicamente sirve para introducir un comentario, normalmente una descripción del campo de forma que la persona que tenga que introducir datos en la tabla sepa qué debe escribir ya que este cometario aparecerá en la barra de estado de la hoja de datos.
Repetir el proceso hasta completar la definición de todos los campos (columnas) de la tabla.
Bibliografía:
http://www.aulaclic.es/access2007/t_3_1.htm
3.5 Realiza el Diagrama Entidad Relacion (E/R)
Diagrama Entidad-Relación
Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de un esquema gráfico empleando los terminología de entidades, que son objetos que existen y son los elementos principales que se identifican en el problema a resolver con el diagramado y se distinguen de otros por sus características particulares denominadas atributos, el enlace que que rige la unión de las entidades esta representada por la relación del modelo.
Recordemos que un rectángulo nos representa a las entidades; una elipse a los atributos de las entidades, y una etiqueta dentro de un rombo nos indica la relación que existe entre las entidades, destacando con líneas las uniones de estas y que la llave primaria de una entidad es aquel atributo que se encuentra subrayado.
A continuación mostraremos algunos ejemplos de modelos E-R, considerando las cordialidades que existen entre ellos:
Relación Uno a Uno.
Problema:
Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en obtener la tarjeta de circulación de un automóvil con los siguientes datos:- Automóvil- Modelo, Placas, Color - Tarjeta de circulación -Propietario, No_serie, Tipo.
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una tarjeta de circulación registrada por cada automóvil.
En este ejemplo, representamos que existe un solo presidente para cada país.
En este ejemplo, representamos que existe un solo presidente para cada país.
Relación muchos a muchos.
El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor de más de una persona).
Bibliografia
martes, 22 de junio de 2010
3.4 Establecer los Esquemas Para los Enunciados Semanticos
Establecer los Esquemas Para los Enunciados Semanticos
Los objetivos de este trabajo fueron de entrada argumentar acerca de los mecanismos para establecer esquemas sintácticos a partir de enunciados y para adscribirles a sus formantes etiquetas de carácter semántico.en grupos y subgrupos con el fin de compararlos y oponerlos a partir de propiedades combinatorias y características aspectuales.
Se trató de buscar, en fin, algunos criterios adecuados para justificar y elaborar un sistema de oposición paradigmática entre una muestra representativa de esquemas oracionales abstractos del español, en este caso de los correspondientes a esquemas agentivos.
Se presenta un enfoque para el diseño de esquemas de bases de datos de calidad. Este enfoque está basado en el trabajo colaborativo e incremental entre usuarios y diseñadores, además de la medición sistemática de la calidad delos esquemas conceptuales.
Se define un conjunto de criterios de calidad con sus correspondientes métricas para apoyar este enfoque.Además se introduce el criterio de economía y se redefine el criterio de expresividad. Las bases de datos poseen diversos componentes.
Uno de ellos es el esquema conceptual, el cual especifica principalmente los componentes estáticos de la base de datos, incluyendo las estructuras y restricciones estáticas.Esta componente es fundamental para todo el sistema y posee la propiedad de ser independiente de las consideraciones de implementación.
El desarrollo de una base de datos considera mucho más que aspectos estáticos, e involucra otros niveles de abstracción que el conceptual, pero aquellos aspectos escapan del ámbito de este artículo, por lo que no serán tratados aquí (para detalles sobre niveles de abstracción y dimensiones de una base de datos, vea el enfoque de codiseño propuesto por Thalheim [Thalheim2000] ).
Un esquema conceptual se especifica en un lenguaje de modelación, tal como el modelo entidad interrelación [Chen76] o UML [Booch98], pudiendo incluir algunas especificaciones extra, expresadas en lenguaje natural o alguna lógica.Este esquema es un modelo de una realidad o la especificación de una solución a un problema, dependiendo de si se utiliza el lenguaje para análisis o diseño respectivamente.
La entrada al proceso de diseño conceptual es el documento de especificación de requisitos, el cual es el resultado principal de la etapa de análisis. Como todo producto de ingeniería, las bases de datos deben ser desarrolladas de modo de asegurar ciertos niveles mínimos de calidad.El problema radica en que la definición del concepto de calidad debe ser previo a su medición. Ambos asuntos han sido cubiertos en el ámbito del software, pero no en el ámbito específico del diseño conceptual de bases de datos.
En este trabajo se han considerado algunos de los aportes realizados por Batini [Batini94], Moody [Moody94] yKesh [Kesh95], quienes han definido criterios de calidad y algunas métricas para poder medirlos. Para cada uno de los criterios de calidad bajo consideración, se propone una métrica, con lo que se puede obtener una medida de localidad de un esquema conceptual.El proceso de diseño conceptual es una tarea humano-dependiente, en el sentido que requiere de habilidades que son muy difíciles de automatizar.
El diseñador debe analizar la realidad bajo modela miento, documentar los hechos relevantes para satisfacer un conjunto de requerimientos, y complementar el documento de especificación de requisitos una vez que obtiene nueva información a través del proceso de diseño.En cada etapa se utilizan distintas políticas para tomar decisiones de diseño, las cuales pueden variar su importancia (ponderación o peso) dependiendo del diseñador o la etapa del desarrollo en que se encuentre.Esto hace que este proceso sea muy dependiente de 1 Investigación parcialmente financiada por Dirección de Investigación, Universidad de Concepción, Proyecto 99.093.003-1.
0quienes lo desarrollen, y que en la práctica, sea difícil justificar una determinada decisión de diseño, si es que no se cuenta con herramientas adecuadas (parte de las cuales proveemos en este trabajo).
BIBLIOGRAFIA:http://www.inf.udec.cl/~mvaras/papers/2001/mvaras-wisw.pdfhttp://dialnet.unirioja.es/servlet/libro?codigo=267510
Los objetivos de este trabajo fueron de entrada argumentar acerca de los mecanismos para establecer esquemas sintácticos a partir de enunciados y para adscribirles a sus formantes etiquetas de carácter semántico.en grupos y subgrupos con el fin de compararlos y oponerlos a partir de propiedades combinatorias y características aspectuales.
Se trató de buscar, en fin, algunos criterios adecuados para justificar y elaborar un sistema de oposición paradigmática entre una muestra representativa de esquemas oracionales abstractos del español, en este caso de los correspondientes a esquemas agentivos.
Se presenta un enfoque para el diseño de esquemas de bases de datos de calidad. Este enfoque está basado en el trabajo colaborativo e incremental entre usuarios y diseñadores, además de la medición sistemática de la calidad delos esquemas conceptuales.
Se define un conjunto de criterios de calidad con sus correspondientes métricas para apoyar este enfoque.Además se introduce el criterio de economía y se redefine el criterio de expresividad. Las bases de datos poseen diversos componentes.
Uno de ellos es el esquema conceptual, el cual especifica principalmente los componentes estáticos de la base de datos, incluyendo las estructuras y restricciones estáticas.Esta componente es fundamental para todo el sistema y posee la propiedad de ser independiente de las consideraciones de implementación.
El desarrollo de una base de datos considera mucho más que aspectos estáticos, e involucra otros niveles de abstracción que el conceptual, pero aquellos aspectos escapan del ámbito de este artículo, por lo que no serán tratados aquí (para detalles sobre niveles de abstracción y dimensiones de una base de datos, vea el enfoque de codiseño propuesto por Thalheim [Thalheim2000] ).
Un esquema conceptual se especifica en un lenguaje de modelación, tal como el modelo entidad interrelación [Chen76] o UML [Booch98], pudiendo incluir algunas especificaciones extra, expresadas en lenguaje natural o alguna lógica.Este esquema es un modelo de una realidad o la especificación de una solución a un problema, dependiendo de si se utiliza el lenguaje para análisis o diseño respectivamente.
La entrada al proceso de diseño conceptual es el documento de especificación de requisitos, el cual es el resultado principal de la etapa de análisis. Como todo producto de ingeniería, las bases de datos deben ser desarrolladas de modo de asegurar ciertos niveles mínimos de calidad.El problema radica en que la definición del concepto de calidad debe ser previo a su medición. Ambos asuntos han sido cubiertos en el ámbito del software, pero no en el ámbito específico del diseño conceptual de bases de datos.
En este trabajo se han considerado algunos de los aportes realizados por Batini [Batini94], Moody [Moody94] yKesh [Kesh95], quienes han definido criterios de calidad y algunas métricas para poder medirlos. Para cada uno de los criterios de calidad bajo consideración, se propone una métrica, con lo que se puede obtener una medida de localidad de un esquema conceptual.El proceso de diseño conceptual es una tarea humano-dependiente, en el sentido que requiere de habilidades que son muy difíciles de automatizar.
El diseñador debe analizar la realidad bajo modela miento, documentar los hechos relevantes para satisfacer un conjunto de requerimientos, y complementar el documento de especificación de requisitos una vez que obtiene nueva información a través del proceso de diseño.En cada etapa se utilizan distintas políticas para tomar decisiones de diseño, las cuales pueden variar su importancia (ponderación o peso) dependiendo del diseñador o la etapa del desarrollo en que se encuentre.Esto hace que este proceso sea muy dependiente de 1 Investigación parcialmente financiada por Dirección de Investigación, Universidad de Concepción, Proyecto 99.093.003-1.
0quienes lo desarrollen, y que en la práctica, sea difícil justificar una determinada decisión de diseño, si es que no se cuenta con herramientas adecuadas (parte de las cuales proveemos en este trabajo).
BIBLIOGRAFIA:http://www.inf.udec.cl/~mvaras/papers/2001/mvaras-wisw.pdfhttp://dialnet.unirioja.es/servlet/libro?codigo=267510
3.3 Definirlos enunciados semanticos
Definirlos enunciados semanticos
El término semántica se refiere a los aspectos del significado, sentido o interpretación del significado de un determinado elemento, símbolo, palabra, lenguaje o representación formal. En principio cualquier medio de expresión (lenguaje formal o natural) admite una correspondencia entre expresiones de símbolos o palabras y situaciones o conjuntos de cosas que se encuentran en el mundo físico o abstracto que puede ser descrito por dicho medio de expresión.La semántica puede estudiarse desde diferentes perspectivas:
• Semántica lingüística, trata de la codificación y decodificación de los contenidos semánticos en las estructuras lingüísticas.
• Semántica lógica, desarrolla una serie de problemas lógicos de significación, estudia la relación entre el signo lingüístico y la realidad. Las condiciones necesarias para que un signo pueda aplicarse a un objeto, y las reglas que aseguran una significación exacta. • Semántica en ciencias cognitivas, intenta explicar por qué nos comunicamos, y cuál es el mecanismo psíquico que se establece entre hablante y oyente durante este proceso.
www.betoo-charolastras.blogspot.com/2009/03/definir-los-enunciados-semanticos.html
3.2 Establecer Atributos
Establecer Atributos
Los siguientes atributos son necesarios para definir un proyecto:
· El proyecto debe de tener bien definido su objetivo, así como el resultado esperado. Los objetivos de un proyecto se definen en términos de alcance, costo y programa.
· Un proyecto se realiza mediante varias series de tareas independientes, se podría decir que un numero de tareas no repetitivas que es necesario realizar en un cierto orden con el fin de llegar al objetivo esperado del proyecto.
· Al realizar las tareas antes mencionadas se necesitan usar recursos varios, los cuales pueden llegar a incluir diferentes personas, organizaciones, equipos, instalación y materiales.
· El proyecto debe de tener un margen de tiempo específico.
· Cada proyecto tiene un cliente. La entidad cliente, ya sea una persona, empresa, organización o grupo de 2 o mas personas u organizaciones, es la que se encarga de proporcionar los recursos necesarios para el logro del proyecto.
· Ya para terminar un proyecto tiene un nivel de incertidumbre, antes de comenzar un proyecto se debe de tener plan, el cual será la base para ciertos supuestos y estimandos.
http://html.rincondelvago.com/atributos-de-un-proyecto.html
Los siguientes atributos son necesarios para definir un proyecto:
· El proyecto debe de tener bien definido su objetivo, así como el resultado esperado. Los objetivos de un proyecto se definen en términos de alcance, costo y programa.
· Un proyecto se realiza mediante varias series de tareas independientes, se podría decir que un numero de tareas no repetitivas que es necesario realizar en un cierto orden con el fin de llegar al objetivo esperado del proyecto.
· Al realizar las tareas antes mencionadas se necesitan usar recursos varios, los cuales pueden llegar a incluir diferentes personas, organizaciones, equipos, instalación y materiales.
· El proyecto debe de tener un margen de tiempo específico.
· Cada proyecto tiene un cliente. La entidad cliente, ya sea una persona, empresa, organización o grupo de 2 o mas personas u organizaciones, es la que se encarga de proporcionar los recursos necesarios para el logro del proyecto.
· Ya para terminar un proyecto tiene un nivel de incertidumbre, antes de comenzar un proyecto se debe de tener plan, el cual será la base para ciertos supuestos y estimandos.
http://html.rincondelvago.com/atributos-de-un-proyecto.html
3.1 Definir Entidad y Relacion
Definicion Entidar y Relacion
Un diagrama o modelo entidad-relación (a veces denominado por su siglas, E-R "Entity relationship", o, "DER" Diagrama de Entidad Relación) es una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información así como sus interrelaciones y propiedades
El modelado entidad-relación es una técnica para el modelado de datos utilizando diagramas entidad relación. No es la única técnica pero sí la más utilizada. Brevemente consiste en los siguientes pasos:
Se parte de una descripción textual del problema o sistema de información a automatizar (los requisitos).
Se hace una lista de los sustantivos y verbos que aparecen.
Los sustantivos son posibles entidades o atributos.
Los verbos son posibles relaciones.
Analizando las frases se determina la cardinalidad de las relaciones y otros detalles.
Se elabora el diagrama (o diagramas) entidad-relación.
Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.
Entidad
Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.
Algunos Ejemplos:
Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de bastidor).
Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).
Una entidad puede ser un objeto con existencia física como: una persona, un animal, una casa, etc. (entidad concreta), o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta).
Una entidad está descrita y se representa por sus características o atributos. Por ejemplo, la entidad Persona puede llevar consigo las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento, etc...
Relación
Describe cierta dependencia entre entidades o permite la asociación de las mismas.
Ejemplo:
Dadas dos entidades "Habitación 502" y "Mark", es posible relacionar que la
habitacion 502 se encuentra ocupada por el huésped de nombre Mark.
Bibliografia
3 Diseñar una Base de Datos de Acuerdo al Modelo Entidad Relacion (E/R)
Diseñar una Base de Datos de Acuerdo al Modelo Entidad Relacion (E/R)
lunes, 21 de junio de 2010
2.4 Determinar los Programas a Desarrollar
Determinar los Programas a Desarrollar
Al igual que cualquier otro tipo de software de oficina, hay un montón de programas de diseño de bases de datos disponibles para uso personal o profesional. Idealmente, un usuario de base de datos busca el objetivo de su base de datos posibles antes de elegir un programa de diseño. Sin embargo, todo aquél que busque un diseño innovador de bases de datos sin conocer los datos concretos que entran en el sistema puede utilizar varios criterios para encontrar el programa óptimo diseño de bases de datos para sus necesidades.
Los usuarios potenciales de bases de datos necesitan buscar primero la sencillez del software de base de datos. Normalmente, una compañía de software permitirá que un cliente potencial eche un vistazo a las capturas de pantalla o incluso descargue una versión demo del programa para la obtención de muestras.
Con la excepción de las personas instruidas en diseño de bases de datos, más sencillo siempre es mejor y un interfaz desarrollado con muchas campanas y silbidos puede ser desaconsejable.La cuestión que los compradores deben considerar es si una persona con una mínima cantidad de conocimientos o ideas preconcebidas puede utilizar el programa. Además de facilidad de uso, los diseñadores de bases de datos necesitan ver algunos pequeños factores.
La compatibilidad con los sistemas de computación de la oficina esta dada pero los profesionales de un negocio, deben considerar si el programa cumple con los requerimientos de desarrollo de un futuro próximo.
Además, siempre hay una consideración de precio en la compra de software de bases de datos. Algunos programas pueden ser prohibitivamente caros, pero otros pueden ser demasiado costosos para el servicio que prestan. Los compradores deben mirar primero su funcionalidad y luego determinar si el precio es demasiado grande para sus presupuestos.
Bibliografía
2.3 Identificar el Equipo a Utilizar
Identificar el Equipo a Utilizar
Una base de datos (cuya abreviatura es BD) es una entidad en la cual se pueden almacenar datos de manera estructurada, con la menor redundancia posible. Diferentes programas y diferentes usuarios deben poder utilizar estos datos. Por lo tanto, el concepto de base de datos generalmente está relacionado con el de red ya que se debe poder compartir esta información. De allí el término base. "Sistema de información" es el término general utilizado para la estructura global que incluye todos los mecanismos para compartir datos que se han instalado.
Aplicación de escritorio para proceso simple (con módulos de extensión de plug-ins).Cliente-servidor con clientes delgados y servidor personalizados.
Aplicación Web de 2-puertos: servidor web/servidor de aplicaciones, base de datos.Aplicación Web de 3-puertos: servidor web/servidor de aplicaciones, base de datos.
Servicio web simple: servidor de aplicaciones, base de datos.Servicios de Red o Web.Cliente-a-cliente sin servidor central.Con tuberías y filtros.Malla de computadoras / servidores distribuidos.
BIBLIOGRAFIA
2.2 Identificar Tipos de Ususario
Identificar Tipos de Usuarios
·Usuario Final: es la persona que utiliza los datos, esta persona ve datos convertidos en información:
·Desarrollador de Aplicaciones: es la persona que desarrolla los sistemas que interactuàn con la Base de Datos.
·DBA: es la persona que asegura integridad, consistencia, redundancia, seguridadeste es el Administrador de Base de Datos quien sed encarga de realizar el mantenimiento diario o periòdico de los datos.
Las personas tienen acceso DBMS se clasifican de la siguiente manera:
USUARIOS INGENUOS. – Son aquellos que interactuan con el sistema por medio de aplicaciones permanentes.
USUARIOS SOFISTICADOS.- son aquellos con la capacidad de acceder a la información por medios de lenguajes de consulta.
PROGRAMADORES DE APLICACIÓN.- son aquellos con un amplio dominio del DML capaces de generar nuevos módulos o utilerias capaces de manejar nuevos datos en el sistema.
USUARIOS ESPECIALIZADOS.- son aquellos que desarrollan módulos que no se refieren precisamente al manejo de los datos, si no a aplicaciones avanzadas como sistemas expertos, reconocimientos de imágenes, procesamiento de audio y demás.
Conceptos Bàsicos de Base de datos
·Desarrollador de Aplicaciones: es la persona que desarrolla los sistemas que interactuàn con la Base de Datos.
·DBA: es la persona que asegura integridad, consistencia, redundancia, seguridadeste es el Administrador de Base de Datos quien sed encarga de realizar el mantenimiento diario o periòdico de los datos.
Las personas tienen acceso DBMS se clasifican de la siguiente manera:
USUARIOS INGENUOS. – Son aquellos que interactuan con el sistema por medio de aplicaciones permanentes.
USUARIOS SOFISTICADOS.- son aquellos con la capacidad de acceder a la información por medios de lenguajes de consulta.
PROGRAMADORES DE APLICACIÓN.- son aquellos con un amplio dominio del DML capaces de generar nuevos módulos o utilerias capaces de manejar nuevos datos en el sistema.
USUARIOS ESPECIALIZADOS.- son aquellos que desarrollan módulos que no se refieren precisamente al manejo de los datos, si no a aplicaciones avanzadas como sistemas expertos, reconocimientos de imágenes, procesamiento de audio y demás.
Conceptos Bàsicos de Base de datos
· Archivo: son conjuntos de registros.
·
· Registros:son conjuntos de campos.
·
· Campos: es la minìma unidad de referencia.
Externo:esa es la visiòn del usuario final, se ve como se maneja los datos ya convertidos en información.
Es aquel en el que se presenta al usuario final y que puede combinaciones o relaciones entre los datos que conforman a la base de datos global. Puede definirse como la forma en el que el usuario aprecia la información y sus relaciones.
Conceptual:se ve como esta estructurado la Base Datos, equipos de campo tiene como estan estructurado los registros.
Es aquel en el que se definen las estructuras lógicas de almacenamiento y las relaciones que se darán entre ellas. Ejemplos comunes de este nivel son el diseño de los registros y las ligas que permitirán la conexión entre registros de un mismo archivo, de archivos distintos incluso, de ligas hacia archivos.
Interno: se ve como se almacena los datos fisicamente.Es aquel en el que se determinan las características de almacenamiento en el medio secundario. Los diseñadores de este nivel poseen un amplio dominio de cuestiones técnicas y de manejo de hardware. Muchas veces se opta por mantener el nivel físico proporcionado por el sistema operativo para facilitar y agilizar el desarrollo.
BIBLIOGRAFIA
:http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml#tipos
2.1 Identificar Tipos de Informacion
Indetificar tipos de informacion
Una base de datos está formada por:Los datos: Que deben ser INTEGRADOS, es decir, que en la unión de los archivos que forman el sistema no exista redundancia de datos Veamos el ejemplo de la gestión de los libros de una biblioteca. Una ficha con datos de un libro, una ficha con datos de un lector y una ficha mostrando el listado de lecturas de un libro, esa ficha que nos entregan junto al libro cuándo nos lo prestan en la biblioteca. Si hacemos un listado con el nombre de los campos que hemos introducido en esas fichas obtendríamos:
Título Autor Editorial Año Idioma Lector Fecha préstamo Fecha
Devolución Nombre Apellidos Domicilio Teléfono DNI
Cada dato de ese listado suma , aparece en una ficha junto a otros con los que se relaciona, y ningún dato se repite en el resto de las fichas, por lo tanto los datos están integrados. Hardware:
Es el soporte físico que permite almacenar la información de la base de datos. Nosotros por el momento trabajaremos con un solo soporte físico, pero hay que saber que una base de datos puede estar formada por varios sistemas, entonces se llama base de datos distribuida. El manejo de este tipo de bases de datos compartidas se complica ya que se necesita comunicación entre los sistemas. Software:
Es el que permite trabajar y gestionar la B.D. de la forma más eficiente. El SGBD (Sistema gestor de bases de datos) es el encargado de gestionar la B.D. por lo tanto todas las operaciones que se realicen sobre las mismas han de pasar por el SGBD.
Devolución Nombre Apellidos Domicilio Teléfono DNI
Cada dato de ese listado suma , aparece en una ficha junto a otros con los que se relaciona, y ningún dato se repite en el resto de las fichas, por lo tanto los datos están integrados. Hardware:
Es el soporte físico que permite almacenar la información de la base de datos. Nosotros por el momento trabajaremos con un solo soporte físico, pero hay que saber que una base de datos puede estar formada por varios sistemas, entonces se llama base de datos distribuida. El manejo de este tipo de bases de datos compartidas se complica ya que se necesita comunicación entre los sistemas. Software:
Es el que permite trabajar y gestionar la B.D. de la forma más eficiente. El SGBD (Sistema gestor de bases de datos) es el encargado de gestionar la B.D. por lo tanto todas las operaciones que se realicen sobre las mismas han de pasar por el SGBD.
Bibliografía:
http://albertoluisaguilar.blogspot.com/2009/03/21-identificar-tipo-de-informacion.html
2 Determinar los elementos de un sistema de base de datos
Determinar los elementos de un sistema de base de datos.
1.6 Obtener los datos del sistema empleando herramientas analiticas
Obtener los datos del sistema empleando herramientas analiticas
1.-Técnicas de búsqueda dedatos
2.-Recolección de datos.
3.-Análisis de la información.
4.-Análisis costo-beneficio.
5.-Informe de resultados a la administración
Bibliografia
www.wikipedia/datos-sistemas/ifo.com
1.-Técnicas de búsqueda dedatos
2.-Recolección de datos.
3.-Análisis de la información.
4.-Análisis costo-beneficio.
5.-Informe de resultados a la administración
Bibliografia
www.wikipedia/datos-sistemas/ifo.com
1.5 Requerimiento de un Sistema
Requerimiento de un Sistema
Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto.
Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para un proyecto.En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los requerimientos viene antecedida de la etapa de factibilidad del sistema/software y precedida por la etapa de diseño del sistema/software.
Etapas de la fase de requerimientos
* Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los grupos de interés.* Análisis: comprobación de la consistencia y completitud de los requerimientos.* Verificación: constatación de que los requerimientos especificados son correctos.
Clasificación de los requerimientos
Requerimientos funcionales
qué debe hacer el sistema o software.*
Requerimientos no funcionales
cómo debe funcionar el sistema o software (no su implementación), por ej. Calidad, rendimiento, facilidad de uso, etc.*
Requerimientos externos:
a qué se debe atener el sistema o software con respecto a su entorno: compatibilidad con otros sistemas, adecuación a determinadas leyes, etc.
Características que deberían cumplir los requerimientos
* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.* Cohesión: el requerimiento debe dirigirse a solo una única cosa.* Completo: el requerimiento debe estar completamente declarado en un único lugar, sin información faltante.* Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe ser completamente consistente con toda la documentación.* Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los interesados en el sistema/software.* Factible/viable: el requerimiento debe poder ser implementado.* No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar hechos objetivos, no opiniones subjetivas. Debe poder ser interpretado de una única manera.* Obligatorio: el requerimiento debe representar una característica definida por el grupo interesado en el desarrollo del sistema/software, su ausencia no puede ser reemplazada. * Observable externamente: el requerimiento debe especificar una característica observable externa o experimentable por el usuario del producto.* Verificable/demostrable: La implementación del requerimiento debe poder ser resuelta en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba.
Bibliografía
http://es.wikipedia.org/wiki/Requerimiento_(sistemas)
Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto.
Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. En otras palabras, los requerimientos muestran qué elementos y funciones son necesarias para un proyecto.En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de los requerimientos viene antecedida de la etapa de factibilidad del sistema/software y precedida por la etapa de diseño del sistema/software.
Etapas de la fase de requerimientos
* Obtención de requerimientos: búsqueda y obtención de los requerimientos desde los grupos de interés.* Análisis: comprobación de la consistencia y completitud de los requerimientos.* Verificación: constatación de que los requerimientos especificados son correctos.
Clasificación de los requerimientos
Requerimientos funcionales
qué debe hacer el sistema o software.*
Requerimientos no funcionales
cómo debe funcionar el sistema o software (no su implementación), por ej. Calidad, rendimiento, facilidad de uso, etc.*
Requerimientos externos:
a qué se debe atener el sistema o software con respecto a su entorno: compatibilidad con otros sistemas, adecuación a determinadas leyes, etc.
Características que deberían cumplir los requerimientos
* Actual: el requerimiento no debe volverse obsoleto con el paso del tiempo.* Cohesión: el requerimiento debe dirigirse a solo una única cosa.* Completo: el requerimiento debe estar completamente declarado en un único lugar, sin información faltante.* Consistente: el requerimiento no debe contradecir ningún otro requerimiento y debe ser completamente consistente con toda la documentación.* Correcto/necesario: el requerimiento debe cumplir con la necesidad declarada por los interesados en el sistema/software.* Factible/viable: el requerimiento debe poder ser implementado.* No ambiguo: el requerimiento debe estar concisamente declarado. Debe expresar hechos objetivos, no opiniones subjetivas. Debe poder ser interpretado de una única manera.* Obligatorio: el requerimiento debe representar una característica definida por el grupo interesado en el desarrollo del sistema/software, su ausencia no puede ser reemplazada. * Observable externamente: el requerimiento debe especificar una característica observable externa o experimentable por el usuario del producto.* Verificable/demostrable: La implementación del requerimiento debe poder ser resuelta en alguno de estos cuatro métodos: inspección, análisis, demostración o prueba.
Bibliografía
http://es.wikipedia.org/wiki/Requerimiento_(sistemas)
1.4 Toma de Desicion
Toma de decisiones:
Es el proceso mediante el cual se realiza una elección entre las alternativas o formas para resolver diferentes situaciones de la vida, utilizando metodologías cuantitativas que brinda la administración), etc., en todo momento se toman decisiones, la diferencia entre cada una de estas es el proceso o la forma en la cual se llega a ellas. La toma de decisiones consiste, en elegir una alternativa entre las disponibles, a los efectos de resolver un problema actual o potencial, (aún cuando no se evidencie un conflicto latente). Los SI y la toma de decisiones. Los SI van mucho más allá que el diseño y desarrollo del subsistema informático. Un SI puede definirse, como "un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir información para apoyar la toma de decisiones y el control de una institución", además de ayudar a dichos directivos y personal a analizar problemas, visualizar cuestiones complejas y crear nuevos productos en un ambiente intensivo de información. La gestión de la información está orientada al control, preservación y retención de la información. Las necesidades de información pueden ser relativas a hechos presentes o a situaciones futuras, con el objetivo de realizar una dirección proactiva. Las necesidades de información se agrupan según las unidades organizativas de la institución y las aplicaciones que cada una de ellas lleve a cabo. Resulta importante la necesidad de información sobre el entorno, implicando un mecanismo de observación que provea constantemente información relativa a los principales factores estratégicos: competencia, tecnología y política, entre otros. Igualmente, resulta una constante el análisis de información sobre aspectos claves de la organización como I+D, producción, recursos humanos y finanzas, entre otros. La elección o combinación de diversos procedimientos, lógicamente dependerá de las condiciones específicas de cada institución y de los individuos que la componen.
Bibliografía
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
Es el proceso mediante el cual se realiza una elección entre las alternativas o formas para resolver diferentes situaciones de la vida, utilizando metodologías cuantitativas que brinda la administración), etc., en todo momento se toman decisiones, la diferencia entre cada una de estas es el proceso o la forma en la cual se llega a ellas. La toma de decisiones consiste, en elegir una alternativa entre las disponibles, a los efectos de resolver un problema actual o potencial, (aún cuando no se evidencie un conflicto latente). Los SI y la toma de decisiones. Los SI van mucho más allá que el diseño y desarrollo del subsistema informático. Un SI puede definirse, como "un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir información para apoyar la toma de decisiones y el control de una institución", además de ayudar a dichos directivos y personal a analizar problemas, visualizar cuestiones complejas y crear nuevos productos en un ambiente intensivo de información. La gestión de la información está orientada al control, preservación y retención de la información. Las necesidades de información pueden ser relativas a hechos presentes o a situaciones futuras, con el objetivo de realizar una dirección proactiva. Las necesidades de información se agrupan según las unidades organizativas de la institución y las aplicaciones que cada una de ellas lleve a cabo. Resulta importante la necesidad de información sobre el entorno, implicando un mecanismo de observación que provea constantemente información relativa a los principales factores estratégicos: competencia, tecnología y política, entre otros. Igualmente, resulta una constante el análisis de información sobre aspectos claves de la organización como I+D, producción, recursos humanos y finanzas, entre otros. La elección o combinación de diversos procedimientos, lógicamente dependerá de las condiciones específicas de cada institución y de los individuos que la componen.
Bibliografía
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
viernes, 18 de junio de 2010
1.3 Estudio de Factivilidad
Estudio de factibilidad
Es el análisis amplio de los resultados financieros, económicos y sociales de una inversión (dada una opción tecnológica -estudio de pre-factibilidad). En la fase de pre-inversión la eventual etapa subsiguiente es el diseño final del proyecto (preparación del documento de proyecto), tomando en cuenta los insumos de un proceso productivo, que tradicionalmente son: tierra, trabajo y capital (que generan ingreso: renta, salario y ganancia). Objetivo de un Estudio de Factibilidad. 1.- Auxiliar a una organización a lograr sus objetivos. 2.- Cubrir las metas con los recursos actuales en las siguientes áreas. Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación. Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos básicos: · Operativo. · Técnico. · Económico.
a). Factibilidad Técnica. - Mejora del sistema actual. - Disponibilidad de tecnología que satisfaga las necesidades.
b).- Factibilidad Económica. - Tiempo del analista. - Costo de estudio. - Costo del tiempo del personal. - Costo del tiempo. - Costo del desarrollo / adquisición.
c).- Factibilidad Operativa. - Operación garantizada. - Uso garantizado.
Bibliografia:
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
Es el análisis amplio de los resultados financieros, económicos y sociales de una inversión (dada una opción tecnológica -estudio de pre-factibilidad). En la fase de pre-inversión la eventual etapa subsiguiente es el diseño final del proyecto (preparación del documento de proyecto), tomando en cuenta los insumos de un proceso productivo, que tradicionalmente son: tierra, trabajo y capital (que generan ingreso: renta, salario y ganancia). Objetivo de un Estudio de Factibilidad. 1.- Auxiliar a una organización a lograr sus objetivos. 2.- Cubrir las metas con los recursos actuales en las siguientes áreas. Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación. Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos básicos: · Operativo. · Técnico. · Económico.
a). Factibilidad Técnica. - Mejora del sistema actual. - Disponibilidad de tecnología que satisfaga las necesidades.
b).- Factibilidad Económica. - Tiempo del analista. - Costo de estudio. - Costo del tiempo del personal. - Costo del tiempo. - Costo del desarrollo / adquisición.
c).- Factibilidad Operativa. - Operación garantizada. - Uso garantizado.
Bibliografia:
http://www.angelfire.com/dragon2/informatica/estudio_de_factibilidad.htm
1.2 Propuesta de Solucion
Propuesta de Solucion
Esta fase se ocupa de la reunión y estudio a detalle de los datos del sistema en operación y la especificación de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del análisis. Con la recopilación de datos se completan los datos resultantes de la fase 1:
añadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilación: Las entrevistas, cuestionarios, encuestas a usuarios finales, así como también, las consultas a documentos y manuales que contengan lineamientos de funcionamiento o normas de procedimientos de operación. Existen varias técnicas y herramientas útiles para el análisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organización de manera grafica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definición de los datos usados en el sistema, así como sus características de tipo, tamaño, limitaciones o especificaciones especiales. La documentación de la etapa de análisis recoge la descripción del sistema de información en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido ala gerencia. Este reporte permite tomar la decisión de proseguir o no con el proyecto. El aspecto más importante de cualquier propuesta es identificar y comprender el problema que el cliente busca resolver. Uno de los puntos del desarrollo de una propuesta de solución es presentar una noción propia del problema, así como la propuesta para resolverlo, con el fin de convencer al cliente de que tal propuesta es la mejor. Para ello, se presentara lo que implica una descripción de los problemas:
1.- La Naturaleza del problema.
2.- La historia del problema.
3.- Las características del problema.
4.- Las soluciones alternas consideradas.
5.- La solución o la técnica seleccionada
BIBLIOGRAFIA
http://www.miespacio.org/cont/invest/invmer.htm#tipos
Esta fase se ocupa de la reunión y estudio a detalle de los datos del sistema en operación y la especificación de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del análisis. Con la recopilación de datos se completan los datos resultantes de la fase 1:
añadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilación: Las entrevistas, cuestionarios, encuestas a usuarios finales, así como también, las consultas a documentos y manuales que contengan lineamientos de funcionamiento o normas de procedimientos de operación. Existen varias técnicas y herramientas útiles para el análisis de datos. Una de estas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organización de manera grafica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definición de los datos usados en el sistema, así como sus características de tipo, tamaño, limitaciones o especificaciones especiales. La documentación de la etapa de análisis recoge la descripción del sistema de información en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido ala gerencia. Este reporte permite tomar la decisión de proseguir o no con el proyecto. El aspecto más importante de cualquier propuesta es identificar y comprender el problema que el cliente busca resolver. Uno de los puntos del desarrollo de una propuesta de solución es presentar una noción propia del problema, así como la propuesta para resolverlo, con el fin de convencer al cliente de que tal propuesta es la mejor. Para ello, se presentara lo que implica una descripción de los problemas:
1.- La Naturaleza del problema.
2.- La historia del problema.
3.- Las características del problema.
4.- Las soluciones alternas consideradas.
5.- La solución o la técnica seleccionada
BIBLIOGRAFIA
http://www.miespacio.org/cont/invest/invmer.htm#tipos
1.1 Investigacion Preliminar
Investigación Preliminar
Si un proyecto de sistema parece ser viable y tiene suficiente prioridad, comienza la investigación preliminar. Requiere uno o más analistas de sistemas analizando el “system request” para determinar la verdadera naturaleza y alcance del problema y recomendar si es que se debe continuar con el proyecto. El propósito es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación debe de cumplir con los siguientes objetivos:
1. Entender la naturaleza del problema – Primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer, puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas fases de desarrollo – Se debe presentar un estimado del tiempo que tomará realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
Si un proyecto de sistema parece ser viable y tiene suficiente prioridad, comienza la investigación preliminar. Requiere uno o más analistas de sistemas analizando el “system request” para determinar la verdadera naturaleza y alcance del problema y recomendar si es que se debe continuar con el proyecto. El propósito es buscar información suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. La investigación no es una actividad de recolección de datos; no se espera que se definan todos los problemas ni que se propongan todas las posibles soluciones. La investigación debe de cumplir con los siguientes objetivos:
1. Entender la naturaleza del problema – Primer objetivo de la investigación preliminar. Muchas veces, el problema presentado en el “system request” no es el problema real, sino un síntoma. Al interaccionar con los usuarios, se debe evitar el uso de la palabra problema, ya que puede generar una impresión negativa. Es mejor hablar sobre mejoras que necesita el sistema.
2. Definir el alcance y las restricciones o limitaciones del sistema – El alcance del proyecto es la extensión del proyecto o del sistema, hasta dónde se debe llegar. Se debe determinar quién es afectado por el problema o por la solución. También es importante definir las limitaciones del sistema. Una limitación es una condición, restricción o requisito que el sistema debe satisfacer, puede tener que ver con el equipo, programas, tiempo, leyes, costos y otros.
3. Identificar los beneficios que se obtendrían si el sistema propuesto es completado – Se debe identificar los beneficios tangibles e intangibles que se esperan como resultado del “system request”. Estos beneficios, junto a los estimados de costo, serán usado por la gerencia para decidir si se continúa con el proyecto. Los beneficios tangibles son aquellos que se pueden expresar en términos de dinero. Los beneficios intangibles son difíciles de contabilizar en dólares y centavos, pero son igualmente importantes. Tienen que ver con la satisfacción del empleado, mayor información disponible para tomar decisiones, mejorar la imagen de la compañía y otros aspectos que no se miden en término de dinero.
4. Especificar un estimado de tiempo y costo para las próximas fases de desarrollo – Se debe presentar un estimado del tiempo que tomará realizar cada uno de las siguientes fases del desarrollo del sistema y del costo que la compañía debe incurrir para completar el sistema. Se debe incluir los costos de desarrollo – costos que ocurren una sola vez – los costos continuos – costos pagados periódicamente.
5. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de análisis del sistema – Debe incluir la evaluación del “system request”, estimado de tiempo y costo-beneficios y las recomendaciones.
Pasos para realizar la investigación preliminar:
Obtener la autorización de la gerencia.
Identificar la información necesaria para el proyecto para cumplir con los cinco objetivos de la investigación.
Realizar las acciones que sean necesarias para conseguir la información, por ejemplo:
a. Analizar el organigrama para conocer la estructura de los departamentos y las personas claves para el sistema.
b. Realizar entrevistas a los usuarios, éste es el método principal de obtener información.
c. Revisar la documentación actual, verificando con los usuarios si la documentación es correcta y completa.
d. Observar la operación actual para identificar fuentes de Input y Output.
e. Realizar encuestas, método usado cuando se necesita información de muchas personas.
Analizar la información obtenida, identificando alternativas con sus costos y beneficios y recomendando la acción que se debe tomar.
Presentar los resultados y recomendaciones a la gerencia.
Obtener la autorización de la gerencia.
Identificar la información necesaria para el proyecto para cumplir con los cinco objetivos de la investigación.
Realizar las acciones que sean necesarias para conseguir la información, por ejemplo:
a. Analizar el organigrama para conocer la estructura de los departamentos y las personas claves para el sistema.
b. Realizar entrevistas a los usuarios, éste es el método principal de obtener información.
c. Revisar la documentación actual, verificando con los usuarios si la documentación es correcta y completa.
d. Observar la operación actual para identificar fuentes de Input y Output.
e. Realizar encuestas, método usado cuando se necesita información de muchas personas.
Analizar la información obtenida, identificando alternativas con sus costos y beneficios y recomendando la acción que se debe tomar.
Presentar los resultados y recomendaciones a la gerencia.
bibliografia
Diseños de Sistemas de Informacion
Hernandez Lopez Citlally
Monroy Monroy Mariela
Blazquez Garcia Daniel
Lienzo Trejo Gabriela Yazmin
Sanchez Uribe Mariano Valentin
Monroy Monroy Mariela
Blazquez Garcia Daniel
Lienzo Trejo Gabriela Yazmin
Sanchez Uribe Mariano Valentin
Suscribirse a:
Entradas (Atom)