Dato

Unidad mínima de información, sin sentido en sí misma, pero que adquiere significado en conjunción con otras
precedentes de la aplicación que las creó.

Conjunto de símbolos que unidos de cierta forma dan un significado coherente y lógico.

Manejador de Bases de Datos

El sistema manejador de bases de datos es la porción más importante del
software de un sistema de base de datos. Un DBMS es una colección de numerosas
rutinas de software interrelacionadas, cada una de las cuales es responsable de
alguna tarea específica.

Las funciones principales de un DBMS son:

Crear y organizar la Base de datos.

Establecer y mantener las trayectorias de acceso a la base

de datos de tal forma que los datos puedan ser accesados
rápidamente.

Manejar los datos de acuerdo a las peticiones de los usuarios.

Registrar el uso de las bases de datos.

Interacción con el manejador de archivos.

Esto a través de las sentencias en DML al comando de el
sistema de archivos. Así el Manejador de base de datos es el
responsable del verdadero almacenamiento de los datos.

Respaldo y recuperación.
Consiste en contar con mecanismos implantados que
permitan la recuperación fácilmente de los datos en caso
de ocurrir fallas en el sistema de base de datos.

Control de concurrencia.
Consiste en controlar la interacción entre los usuarios
concurrentes para no afectar la inconsistencia de los datos.

Seguridad e integridad.
Consiste en contar con mecanismos que permitan el
control de la consistencia de los datos evitando que estos
se vean perjudicados por cambios no autorizados o previstos

Atributos

Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.

Un conjunto de entidades dentro de una entidad, tiene valores específicos asignados para cada uno de sus
atributos, de esta forma, es posible su identificación unívoca.

Ejemplos:

A la colección de entidades Alumnos, con el siguiente conjunto de atributos en común, (id, nombre, edad,
semestre), pertenecen las entidades:
 • (1, Sofía, 18 años, 2)
• (2, Josefa, 19 años, 5)
• (3, Gabriela, 20 años, 2)
• ...

Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus
características llamadas atributos. Las entidades pueden ser concretas como una
persona o abstractas como una fecha.

Una entidad débil es aquella que no puede existir sin participar en la relación, es decir,
aquella que no puede ser unívocamente identificada solamente por sus atributos

Se representan- mediante un doble rectángulo, es de

Una entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser
identificada unívocamente. En los casos en que se requiera, se puede dar que una entidad
fuerte "preste" algunos de sus atributos a una entidad débil para que, esta última, se pueda
identificar.

El Modelo Entidad-Relación, también conocido como DER (diagramas entidad-relación) es una

herramienta de modelado para bases de datos, propuesto por Peter Chen en 1976, mediante el cual se
pretende 'visualizar' los objetos que pertenecen a la Base de Datos como entidades (se corresponde al
concepto de clase, cada tupla representaría un objeto, de la Programación Orientada a Objetos) las cuales
tienen unos atributos y se vinculan mediante relaciones.

Es una representación conceptual de la información. Mediante una serie de procedimientos se puede pasar
del modelo E-R a otros, como por ejemplo el modelo relacional.

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:

1. Se parte de una descripción textual del problema o sistema de información a automatizar (los
requisitos).
2. Se hace una lista de los sustantivos y verbos que aparecen.
3. Los sustantivos son posibles entidades o atributos.
4. Los verbos son posibles relaciones.
5. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles.
6. Se elabora el diagrama (o diagramas) entidad-relación.
7. Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se
pueden reflejar en el diagrama.

Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr buenos
modelos de datos.

El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un
modelo directamente implementable en una base de datos. Brevemente:

• Transformación de relaciones múltiples en binarias.

• Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en
atributos y viceversa).

Conversión en tablas (en caso de utilizar una base de datos relacional

Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración de
datos e información, organizados y listos para su posterior uso, generados para cubrir una necesidad
(objetivo). Dichos elementos formarán parte de alguna de estas categorías:

Elementos de un sistema de información

• Personas.
• Datos.
• Actividades o técnicas de trabajo.
• Recursos materiales en general (típicamente recursos informáticos y de comunicación, aunque no
tienen por qué ser de este tipo obligatoriamente).

Todos estos elementos interactúan entre sí para procesar los datos (incluyendo procesos manuales y
automáticos) dando lugar a información más elaborada y distribuyéndola de la manera más adecuada posible
en una determinada organización en función de sus objetivos.

Normalmente el término es usado de manera errónea como sinónimo de sistema de información informático,
en parte porque en la mayoría de los casos los recursos materiales de un sistema de información están
constituidos casi en su totalidad por sistemas informáticos, pero siendo estrictos, un sistema de información
no tiene por qué disponer de dichos recursos (aunque en la práctica esto no suela ocurrir). Se podría decir
entonces que los sistemas de información informáticos son una subclase o un subconjunto de los sistemas de
información en general

Los sistemas abiertos son aquellos sistemas informáticos que proporcionan alguna
combinación de interoperabilidad, portabilidad y uso de estándares abiertos. (También puede
referirse a los sistemas configurados para permitir el acceso sin restricciones por parte de
personas y otros sistemas, si bien este artículo sólo discute la primera acepción.) cmom
messenger y portales de se prototipo

Objetivo del proyecto

Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y
planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un
proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto.
El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a
estimaciones razonables.
El análisis económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la
inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del
producto o sistema.
Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco dificultoso
evaluarlo, esto varia de acuerdo a la características del Sistema. El análisis de costos – beneficios es una fase muy
importante de ella depende la posibilidad de desarrollo del Proyecto
En el Análisis Técnico, el Analista evalúa los principios técnicos del Sistema y al mismo tiempo recoge
información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad.
Los resultados obtenidos del análisis técnico son la base para determinar sobre si continuar o abandonar el
proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan
perfectamente unas con otras
Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o usuario (un
representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las
perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación temporal y presupuestal, líneas
de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto.
Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y lo dividen en cinco partes:
• Reconocimiento del problema.
• Evaluación y Síntesis.
• Modelado.
• Especificación.
• Revisión

Antes de su reunión con el analista, el cliente prepara un documento conceptual del proyecto, aunque es
recomendable que este se elabore durante la comunicación Cliente – analista, ya que de hacerlo el cliente solo de
todas maneras tendría que ser modificado, durante la identificación de las necesidades.
2.2.2 Estudio de Viabilidad.
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son
realistas para su materialización sin tener perdidas económicas y frustración profesional. La viabilidad y el
análisis de riesgos están relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de
producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro áreas principales de
interés:
1. Una evaluación de los costos de desarrollo, comparados con los ingresos netos o beneficios
obtenidos del producto o Sistema desarrollado.
2. Viabilidad económica.

Un estudio de funciones, rendimiento y restricciones que puedan afectar la realización de un sistema

aceptable.
3. Viabilidad Técnica.
4. Viabilidad Legal.

Es determinar cualquier posibilidad de infracción, violación o responsabilidad legal en que se podría incurrir al
desarrollar el Sistema.
Alternativas. Una evaluación de los enfoques alternativos del desarrollo del producto o Sistema.
El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia

requerimientos

Se pueden identificar dos formas de requisitos:

• Requisitos de usuario: Los requisitos de usuario son frases en lenguaje natural junto a
diagramas con los servicios que el sistema debe proporcionar, así como las
restricciones bajo las que debe operar.
• Requisitos de sistema: Los requisitos de sistema determinan los servicios del
sistema y pero con las restricciones en detalle. Sirven como contrato.

Es decir, ambos son lo mismo, pero con distinto nivel de detalle.

Ejemplo de requisito de usuario: El sistema debe hacer préstamos Ejemplo de requisito de sistema: Función
préstamo: entrada código socio, código ejemplar; salida: fecha devolución; etc.

Se clasifican en tres los tipos de requisitos de sistema:

• Requisitos funcionales

Los requisitos funcionales describen:

• Los servicios que proporciona el sistema (funciones).

• La respuesta del sistema ante determinadas entradas.
• El comportamiento del sistema en situaciones particulares.

• Requisitos no funcionales

Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema (ej. cotas
de tiempo, proceso de desarrollo, rendimiento, etc.)

Ejemplo 1. La biblioteca Central debe ser capaz de atender simultáneamente a todas

las bibliotecas de la Universidad

Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2 s

A su vez, hay tres tipos de requisitos no funcionales:

• Requisitos del producto. Especifican el comportamiento del producto (Ej. prestaciones,

memoria, tasa de fallos, etc.)
• Requisitos organizativos. Se derivan de las políticas y procedimientos de las
organizaciones de los clientes y desarrolladores (Ej. estándares de proceso, lenguajes
de programación, etc.)
• Requisitos externos. Se derivan de factores externos al sistema y al proceso de
desarrollo (Ej. requisitos legislativos, éticos, etc.)

• Requisitos del dominio.

Los requisitos del dominio se derivan del dominio de la aplicación y reflejan características de dicho
dominio.

Pueden ser funcionales o no funcionales.

Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos mediante el Lenguaje de
Intercomunicación de Bibliotecas de España (LIBE). Ej. El sistema de biblioteca no podrá acceder a
bibliotecas con material censurado.