lunes, 23 de marzo de 2009

3.5 DEFINIR LOS DIAGRAMAS DE IDENTIDAD/RELACION.

DEFINIR EL DIAGRAMA DE ENTIDAD / RELACION.

Un DER es una herramienta de modelado de sistemas, que se concentra en los datos almacenados en el sistema y las relaciones entre éstos.Un diagrama de entidad-relación o DER es un modelo de red que describe la distribución de los datos almacenados en un sistema de forma abstracta. EL modelo entidad-relación vendría a ser el "lenguaje" utilizado para crear diagramas de entidad-relación.Componentes de un DER* TIPOS DE OBJETOS o ENTIDADES.* RELACIONES: conectan los objetos o entidades.Desarrollo de sistemas informáticosLos DER se emplean para modelar bases de datos que pertenecen a un sistema informático.Relacionado:• Herramientas de modelado.• Modelo de entidad-relación.

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, sus inter-relaciones y propiedades.

Modelado Entidad-Relación
El Modelo Entidad-Relación es un concepto 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 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:
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.
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).
Etc.
Base Teórica y Conceptual
El modelo entidad-relación se basa en los conceptos descritos a continuación para representar un modelo de la vida real.
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.
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 motor).
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, un 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, Sexo, Estatura, Peso, Fecha de nacimiento, etc...


BIBLIOGRAFIA
http://www.alegsa.com.ar/Dic/diagrama%20de%20entidad-relacion.php

3.4 ESTABLECER LOS ESQUEMAS PARA LOS ENUNCIADOS SEMANTICOS

ESTABLECER 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. Esos mismos mecanismos fueron aplicados para determinar los esquemas agentivos y clasificarlos 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 de
los 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 especificaprincipalmente 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 lasconsideraciones 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 la
calidad 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 modelamiento, 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.0
quienes 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.pdf

http://dialnet.unirioja.es/servlet/libro?codigo=267510

3.3 DEFINIR LOS ENUNCIADOS SEMANTICOS

DEFINIR LOS ENUNCIADOS SEMANTICOS
El término semántica se refiere a los aspectos del significado o interpretación del significado de un determinado 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.

Por su naturaleza las variables semánticas no tienen las cualidades aritméticas que permitan su agregación o el cálculo de indicadores. Aunque existe la posibilidad de reducir a categorías mas simples dichas variables, de tal manera de poder asignarles un valor numérico, en este proceso de reducción y simplificación de se pierden los valores explicativos intrínsecos a dichas variables.
Para construir indicadores es necesario agregar las variables, esto es el equivalente a la suma en los datos numéricos. Esta agregación se hace por etapas, dependiendo del grado de síntesis que se requiera en la construcción del indicador. En el sistema propuesto, la agregación se efectuará por tipo de fuente, lugar y total.
Para la agregación por tipo de fuente o lugares se deben listar los valores de todas las fuentes que integran el tipo, o el lugar, dependiendo del caso y se procede a elaborar un enunciado semántico que sintetice el conjunto des enunciados en uno solo. Para esto se deben tomar en cuenta los valores modales de los enunciados.
Los valores modales, única medida de tendencia central, en el caso de las variables semánticas, se establecen a partir de la lectura del conjunto de enunciados y la identificación de las tendencias explicativas.
Los enunciados semánticos pueden apoyar o descartar en diferentes grados, una situación dada, estar a favor o en contra, identificar o no un problema o situación, o simplemente expresar una opinión sobre una situación dada.
Cuando se efectúa la agregación semántica, es necesario identificar estas diferentes tendencias y tratar de incluirlas en el enunciado síntesis. Estas tendencias pueden ser, centrales (la mayoría de los enunciados coinciden en una apreciación central y descartan los extremos posibles), izquierdos o derechos (la mayoría de los enunciados coinciden en una apreciación en uno de los extremos posibles), bimodal (una parte de los enunciados coinciden en una apreciación en uno de los extremos posibles y los otros en el extremo opuesto).
Para obtener un valor total, es necesario agregar los enunciados por tipo de fuente y después, los valores obtenidos sintetizarlos en un enunciado total.
Para la construcción de indicadores semánticos se listan los valores de las variables que lo integran, estos pueden ser semánticos, numéricos y lógicos, y el operador debe elaborar una síntesis de los valores observados, en un enunciado semántico que siga las siguientes normas:
1. El enunciado debe estar contenido en un solo párrafo.
2. Pueden haber hasta un máximo de tres oraciones por párrafo.
3. Cada oración debe seguir las reglas de la construcción gramatical (sujeto, verbo y complemento).
Acumulación secuencial
La acumulación secuencial es la agregación, de indicadores semánticos o numéricos por medio de procedimientos de agregación acordes con su naturaleza, pertenecientes a varios momentos evaluativos consecutivos, de una periodicidad menor a una mayor, por ejemplo, de trimestres a año.

Bases de datos
Miller y Fellbaum diseñaron un programa conocido como WordNet, una base de datos para la lengua inglesa.[] Su estudio, a partir de un escueto análisis de las capacidades mentales del léxico descubiertas por la psicología, se concentra en su aplicación en la lexicografía.[] Su organización del léxico en cinco categorías básicas como sustantivos (jerarquía tópica), verbos (relaciones de encabalgamiento), adjetivos, adverbios (espacios dimensionales) y palabras funcionales, y su posterior aplicación a WordNet, les llevó a ser redundantes en algunos aspectos. Sin embargo, las diferencias importantes entre estas partes del discurso se pueden identificar de manera más fácil que en los diccionarios tradicionales. Según Fellbaum, la diferencia entre un campo semántico y WordNet es que en el primero los lexemas se diferencian de otros lexemas, mientras que en el segundo, los lexemas se organizan de forma conjunta como sinónimos (synsets). Además, explica, las relaciones sintagmáticas no se consideran en las bases de datos, donde se emplean inventarios de clases semánticas y se sitúan a los lexemas dentro de ellas, mientras que en el campo semántico sí entran en consideración. Por tanto, los dominios no son importantes, pues el significado de un lexema se expresa por su relación de similitud con otros lexemas

BIBLIOGRAFIA:

http://es.wikipedia.org/wiki/Usuario:G%C3%B3ngora/Sem%C3%A1ntica#Bases_de_datos

http://www.grupoanubis.net/wiki/tiki-index.php?page=Tratamiento+de+Datos

http://www.mati.unam.mx/index.php?option=com_content&task=view&id=88&Itemid=51

domingo, 22 de marzo de 2009

3.2 ESTABLECER ATRIBUTOS

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, Sophie, 18 años, 2)
(2, Penny, 19 años, 5)
(3, Sophie, 20 años, 2)

Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por el valor de sus atributos. Nótese que dos o más entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.

En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su número de id.

Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que será almacenado o a restricciones en los valores que el atributo puede tomar (Cadenas de caracteres, números, solo dos letras, solo números mayores que cero, solo números enteros...).
Cuando una entidad no tiene un valor para un atributo dado, este toma el valor nulo, bien sea que no se conoce, que no existe o que no se sabe nada al respecto del mismo


Claves

Es un subconjunto del conjunto de atributos comunes en una colección de entidades, que permite identificar unívocamente cada una de las entidades pertenecientes a dicha colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto de relaciones
Dentro de los conjuntos de entidades existen los siguientes tipos de claves:
Superclave: Es un subconjunto de atributos que permite distinguir unívocamente cada una de las entidades de un conjunto de entidades. Si otro atributo unido al anterior subconjunto, el resultado seguirá siendo una superclave.
  • Clave candidata: Dada una superclave, si ésta deja de serlo removiendo únicamente uno de los atributos que la componen, entonces ésta es una clave candidata.
  • Clave primaria: Es una clave candidata, elegida por el diseñador de la base de datos, para identificar unívocamente las entidades en un conjunto de entidades.

Los valores de los atributos de una clave, no pueden ser todos iguales para dos o más entidades.
Para poder distinguir unívocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos:

  • R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unión de las claves primarias de todos los conjuntos de entidades participantes.
  • R tiene atributos asociados: En este caso, se usa como clave primaria de R la unión de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.

Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria está compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, según sus cardinalidades:

  • R es de muchos a uno de A a B entonces sólo se toma la clave primaria de A, como clave primaria de R.
  • R es de uno a muchos de A a B entonces se toma sólo la clave primaria de B, como clave primaria de R.
  • R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R

Atributos: es una característica (adjetivo) de una entidad que puede hacer 1 de tres cosas:

  • Identificar
  • Relacionar
  • Describir

Ejemplos de entidades con sus atributos

En el diseño se pueden considerar 3 categorías de atributos

  • Simples o compuestos: ya sea que el atributo sea un todo o bien este compuesto
    Color es simple, toma valores rojo, azul, etc
  • Nombre es compuesto, contiene nombre de pila, apellido materno, apellido materno
    Con valores simples o multivaluados: en base a si consisten de un solo valor o un conjunto de valores.
    Telefono o Teléfonos
  • Derivados: que se pueden calcular en base a otros atributos
    El promedio de préstamos se puede derivar si tenemos los valores de cada préstamo realizado a un persona

Conjuntos de relaciones

Relaciones: la conexión que existe entre 2 entidades (verbo).




Relación entre 2 entidades

Relación entre 2 entidades incluyendo un atributo en la relación

BIBLIOGRAFIA

3.1 DEFINIR ENTIDADES Y RELACIONES

Entidades y Relaciones

El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el modelo E/R se parte de una situación real a partir de la cual se definen entidades y relaciones entre dichas entidades:
  • Entidad.- Objeto del mundo real sobre el que queremos almacenar información (Ej: una persona). Las entidades están compuestas de atributos que son los datos que definen el objeto (para la entidad persona serían DNI, nombre, apellidos, dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estará formada por todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas:
  • Que sea única.
  • Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se asigna a cada cliente un número de cliente?.
  • Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
  • Relación.- Asociación entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:
  • Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO).
  • Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relación TRABAJAR-EN).
  • Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA

Un modelo lógico representa los conceptos reales que ha de cubrir la aplicación y permite asegurar que el software cubrirá dichos conceptos.


El modelado de funciones de objetos (Object Role Modeling - ORM) es el proceso de representar conceptos del mundo real que definen ó influyen en el software. Los diagramas ORM incluyen unos objetos primarios llamados entidades, las relaciones entre esas entidades y los atributos que definen esos objetos. Estos diagramas se crean descomponiendo los requerimientos de usuario y los casos de uso en entidades, relaciones y atributos

La notación ORM ofrece un número de formas y conectores para definir el modelo lógico:

  • Objetos ORM: Entidades. Son representados con forma oval y el nombre de la entidad, definen los elementos que toman parte en el desempeño de la aplicación.
  • Relación ORM: Se representan como una linea que conecta las entidades, en medio hay un rectangulo dividido en tantos segmentos como relaciones haya, definen como dos ó más entidades se relacionan unas con otras.
  • Hecho ORM: Se representan como un pequeño texto bajo el rectangulo de una relación, definen como dos ó más entidades se relacionan. Utilizan "..." y "/" para indicar que papel toma cada parte de la relación, de forma que se debe poder leer en ambos sentidos (ie: un hecho "puede ser / es " indica Producto puede ser Mechero, Mechero es Producto).
  • Restricciones ORM: Definen como las entidades participan en la relación, cuales son dominantes y su cantidad. Un pequeño circulo relleno en la conexión entidad-relación indica que dicha relación es dominante. Unas flechas encima del rectangulo de la relación indica su cardinalidad.

Los diagramas ORM deben ser una vista lógica de las entidades de la aplicación, no representar clases ó bases de datos


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.

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 motor).
  • 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, un 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, Sexo, 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.
Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, Un Huésped (entidad), se aloja (relación) en una habitación (entidad)

BIBLIOGRAFIA

3 DISEÑAR UNA BASE DE DATOS EN BASE AL MODELO ENTIDAD/RELACION

Como muchos sabemos, ponerse a desarrollar una base de datos con cierta complejidad y tamaño “a ojo” es perder el tiempo.

Para que la aplicación cumpla eficientemente sus objetivos y los resultados sean buenos, debemos seguir un proceso:

Análisis.

Diseño del modelo entidad / relación.

Definir entidades y relación.

1. Análisis
Debemos comenzar estudiando a fondo el mundo real que deseamos representar en la aplicación y base de datos.Por ejemplo: una universidad, un hospital, una empresa tecnológica.
A partir de este estudio, debemos crear el UD, que es simplemente la visión del mundo real bajo unos determinados objetivos.

2. Diseño del modelo entidad / relación
El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas.
Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad, relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías de generalización, en lo que se ha denominado modelo entidad-relación extendido.


Entidad

Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual.

Hay dos tipos de entidades: fuertes y débiles.

  • Una entidad débil es una entidad cuya existencia depende de la existencia de otra entidad.
  • Una entidad fuerte es una entidad que no es débil.

Relación (interrelación)

Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior.


Las entidades que están involucradas en una determinada relación se denominan entidades participantes. El número de participantes en una relación es lo que se denomina grado de la relación. Por lo tanto, una relación en la que participan dos entidades es una relación binaria; si son tres las entidades participantes, la relación es ternaria; etc.
Una relación recursiva es una relación donde la misma entidad participa más de una vez en la relación con distintos papeles. El nombre de estos papeles es importante para determinar la función de cada participación.


La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad. La participación de una entidad en una relación es obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad participante. Si no, la participación es opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas de negocio.


A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos problemas, denominados trampas, suelen producirse a causa de una mala interpretación en el significado de alguna relación, por lo que es importante comprobar que el esquema conceptual carece de dichas trampas. En general, para encontrar las trampas, hay que asegurarse de que se entiende completamente el significado de cada relación. Si no se entienden las relaciones, se puede crear un esquema que no represente fielmente la realidad.


Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una relación entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de resolverla es reestructurando el esquema para representar la asociación entre las entidades correctamente.


Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación entre entidades, pero el camino entre una y otra no existe para algunas de sus ocurrencias. En este caso, se produce una pérdida de información que se puede subsanar introduciendo la relación que sugería el esquema y que no estaba representada.


Atributo

Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Toda la información extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen.
Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio define todos los valores posibles que puede tomar un atributo. Puede haber varios atributos definidos sobre un mismo dominio.


Los atributos pueden ser simples o compuestos. Un atributo simple es un atributo que tiene un solo componente, que no se puede dividir en partes más pequeñas que tengan un significado propio. Un atributo compuesto es un atributo con varios componentes, cada uno con un significado por sí mismo. Un grupo de atributos se representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Un atributo compuesto se representa gráficamente mediante un óvalo.


Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o relación a la que pertenece. Un atributo polivalente es aquel que tiene varios valores para cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos también se les denomina multivaluados, y pueden tener un número máximo y un número mínimo de valores. La cardinalidad de un atributo indica el número mínimo y el número máximo de valores que puede tomar para cada ocurrencia de la entidad o relación a la que pertenece. El valor por omisión es .
Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que representa un valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente deben pertenecer a la misma entidad o relación.

Identificador


Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos condiciones:
No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador.
Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las relaciones no tienen identificadores.

Jerarquía de generalización

Una entidad E es una generalización de un grupo de entidades E, E, ... E, si cada ocurrencia de cada una de esas entidades es también una ocurrencia de E. Todas las propiedades de la entidad genérica E son heredadas por las subentidades.


Cada jerarquía es total o parcial, y exclusiva o superpuesta. Una jerarquía es total si cada ocurrencia de la entidad genérica corresponde al menos con una ocurrencia de alguna subentidad. Es parcial si existe alguna ocurrencia de la entidad genérica que no corresponde con ninguna ocurrencia de ninguna subentidad. Una jerarquía es exclusiva si cada ocurrencia de la entidad genérica corresponde, como mucho, con una ocurrencia de una sola de las subentidades. Es superpuesta si existe alguna ocurrencia de la entidad genérica que corresponde a ocurrencias de dos o más subentidades diferentes.


Un subconjunto es un caso particular de generalización con una sola entidad como subentidad. Un subconjunto siempre es una jerarquía parcial y exclusiva.

miércoles, 18 de marzo de 2009

2.4 Determinar los programas a dessrrollar

2.3 Determinar 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 tips de usuarios

La intención de post es identificar los tipos de usuario MoSoSo-ero, en cuanto a “uso” se refiere. No pretende ser ningún dogma ni nada por el estilo, es más que nada una autorreflexión.

Para tipificar usuarios, debería hablar de cómo participa un usuario en el sistema, o mejor dicho como interactúa con el sistema en un momento dado. Y digo en un “momento” porque quiero recalcar que todos los usuarios pueden pasar a ser de un tipo a otro dependiendo del “momento”


Actitud activa:Servicios que se originan cuando el mismo usuario inicia la petición de uso. Tienen bastante que ver con la interación - petición a tiempo real.

Ejemplos: Hacer una búsqueda de resultados, mandar un mensaje, saber quien tengo cerca.

Este tipo de servicios en un LBS-MOSOSO es muy crítica la localización. Los servicios a ofrecer deben estar sumamente ligados a su posición geográfica, son rabiosamente a tiempo real donde la información debe estar accesible al momento, de forma ágil y rápida. Un elemento crítico aquí seria no infoxicar (dar exceso de información) al usuario, saber darle justo lo que necesita, ni más ni menos. No olvidemos que la información a mostrar en una o varias pantallas de móvil es bastante limitada.

¿Serían servicios de aquí te pillo aquí te mato? ¿Servicios de impulso = servicios monetizables?. Lo dejo a libre elección de cada uno de los lectores. Estos servicios son de gran valor si saben ejecutarse en tiempo oportuno, de nada sirve que tarden o vayan con retraso.

Actitud pasiva:

Se trata de aquellos servicios latentes, que se originan por sistemas automáticos, otros usuarios o el propio usuario de indirecta (normalmente con un espacio temporal). En este sentido no son tanto de interacción con el usuario.

Ejemplos: Recepción de una alerta, alguien quiere contactar contigo

Esto son servicios de stickness y de asegurar el retorno del usuario. No son servicios de impulso y deberían asegurar la vuelta del usuario a largo plazo. Tienen que reportarle algun tipo de beneficio al usuario. ¿Son los servicios gratuitos? Lo dejo a vuestra elección.

2.1 Identificar tipo de información

A partir de las técnicas de análisis y recolección de información, se reconocen cuatro grandes tipos de estudios en la investigación de mercados:
  • investigación cuantitativa o numérica
  • investigación cualitativa
  • investigación documental o de fuentes secundarias
  • investigación secundaria de marketing

Proceso


Los pasos para el desarrollo de una investigación de mercados son:

  • Definir el problema a investigar
  • Seleccionar y establecer el diseño de la investigación
  • Recolección de datos y análisis
  • Formular hallazgos
  • Definir el problema a investigar

En este paso es donde se define el problema existente y esta constituido por dos procesos básicos:

(1) Formulación del problema y

(2) Establecimiento de objetivos de la investigación.


Definir el problema es un paso simple, pero de una gran importancia en el proceso de investigación de mercados, ya que una claridad en lo que se desea investigar es básico para saber como hacerlo. Una empresa puede invertir miles de dólares en investigación, sin embargo, si no se tiene claro el problema a investigar esos dólares serán un desperdicio.


Después de formular el problema, es necesario formular las preguntas de la investigación. Cuales son las preguntas básicas que se necesitan responder y sus posibles sub. preguntas que se tienen.
Con el problema o la oportunidad definida, el siguiente paso es determinar los objetivos de la investigación, definiendo y determinando de esta manera que información es necesaria para resolver las preguntas. Una buena manera de establecer los objetivos de una investigación es preguntándose, “¿Qué información se necesita para resolver el problema?”.
Se debe entender que: “Objetivos claros ayudan a obtener resultados claros”.
Luego de describir y formular el problema y los objetivos, el siguiente paso es preparar un detallado cronograma especificando los diferentes pasos de la investigación.

Seleccionar y establecer el diseño de la investigación
Este paso esta constituido por 4 procesos básicos:

(1) Seleccionar el diseño de la investigación,

(2) Identificar los tipos de información necesaria y las fuentes

(3) Determinar diseñar los instrumentos de medición

(4)Recopilación de Datos.


Seleccionar el diseño de la investigación

Lo primero que se tiene que recordar es que cada investigación en cada tipo de negocio es diferente, por lo que el diseño puede variar, existiendo infinitos tipos. Los tipos “genéricos” de diseño en investigación son:

  • Exploratoria
  • Descriptiva
  • Causal
  • Exploratoria: La investigación Exploratoria se define como la recolección de información mediante mecanismos informales y no estructurados.
  • Descriptiva: Esta investigación se refiere a un conjunto de métodos y procedimientos que describen a las variables de Marketing. Este tipo de estudio ayuda a determinar las preguntas básicas para cada variable, contestando Quién, Cómo, Qué y Cuándo. Este tipo de estudios puede describir cosas como, las actitudes de los clientes, sus intenciones y comportamientos, al igual que describir el número de competidores y sus estrategias.
  • Causal: En este tipo de investigación se enfoca en controlar varios factores para determinar cual de ellos es el causante del problema. Esto permite aislar las causas del problema, al mismo tiempo que entrega un nivel de conocimiento superior acerca de la variable que se estudia. Este tipo de estudio es el más complejo y por ende costoso.

Identificar los tipos de información necesaria y las fuentes
Existen dos tipos de información en investigación de mercados, la primaria y la secundaria.

  • La información PrimariaTítulo del enlace es aquella que se releva directamente para un propósito específico.
  • La información Secundaria se refiere a aquella que ya existe en algún lugar y se recolectó para otro propósito. Por lo general este tipo de información es menos costosa que la primaria y en ocasiones basta con la revisión de Internet o con una visita a la biblioteca local.

Determinar y diseñar los instrumentos de medición


Luego de determinar que tipo de información es necesaria, se debe determinar el método en que se logrará obtener dicha información. Existen múltiples métodos dentro de los que se encuentran las encuestas telefónicas, las encuestas por correo o E-Mail, encuestas personales o encuestas en grupo.


Por otra parte, existen dos métodos básicos de recolección de información; mediante preguntas o mediante observación; siendo el instrumento más común el cuestionario.
Cuando es necesario diseñar un cuestionario se deben tener en cuenta los objetivos específicos de la investigación y seguir una secuencia lógica de pasos que permiten elaborar una buena herramienta de medición. Dichos pasos podrían enumerarse como sigue:


1. Planear lo que se va a medir: Consiste en especificar exactamente los que se quiere obtener de cada entrevistado así como las características que tiene la población fijada como meta. Al realizar este paso es necesario analizar los objetivos de la investigación; ya establecidos previamente, corroborando que estos sean lo suficientemente claros como para que describan; lo más completamente posible, la información que necesita el encargado de tomar decisiones, la o las hipótesis y el alcance de la investigación. Se debe implementar también, una investigación exploratoria, la cual sugerirá variables pertinentes adicionales y ayudará al investigador a asimilar el vocabulario y el punto de vista del entrevistado típico.


2. Elaborar el fromato de la pregunta: Se tienen tres tipos de formatos para la recolección; el estructurado, el no estructurado y el mixto.
Estructurado: Son listados con preguntas especificas cerradas, en las que se incluyen preguntas de opción múltiple con selección simple o selección múltiple. También se incluyen escalas de referencia y ordenamientos.
No Estructurados: Son preguntas abiertas, donde el encuestado puede contestar con sus propias palabras.
Mixto: Las preguntas de respuesta abierta pueden usarse conjuntamente con preguntas de respuesta cerrada para obtener información adicional, de ahí que en ocasiones se de el uso de preguntas abiertas para dar seguimiento a una de respuesta cerrada (por ejemplo conocer la opinión expresa del encuestado acerca del tema que se está tratando), lo que se conoce propiamente como sondeo.


3. Redacción y Distribución del Cuestionario: Las palabras utilizadas en preguntas partículares pueden tener un gran impacto en la forma en que un entrevistado las interpreta, lo que puede ocasionar el cambio en las respuestas que éste proporcione al encuestador. Por tal motivo, la redacción de las preguntas debe ser sencilla, directa, clara, debe evitar sugerir toda o parte de la respuesta que se pretenda obtener, debe evitar utilizar palabras con significados vagos o ambiguos, deben ser los sificientemente cortas como para que no confundan al entrevistado y debe ser aplicable a todas las personas a quienes se les va a preguntar. En cuanto a las decisiones de secuencia y distribución, se debe tomar en cuenta que se debe inciar por preguntas sencillas de responder y que no causen un impacto negativo en el encuestado y de esta forma ir introduciendo a la persona al cuestionario, es importante evitar preguntas que puedan resultar repetitivas.


4. Prueba preliminar o piloto: Una vez establecido el orden y la redaccion de las preguntas se crea un cuestionario preliminar el cual se aplicará a una pequeña muestra (de 15 a 25 personas aproximadamente) que represente razonablemente a la población que se tiene como meta. A esto se le conoce como "Aplicación de Prueba Piloto". El propósito de esta prueba es asegurar que el cuestionario realizado cumple con las expectativas de la investigación en términos de información obtenida así como, identíficar y corregir las deficiencias que pudieran provocar un sesgo en la misma.


5. Corrección de los problemas: Es la etapa final del proceso de diseño de cuestionarios. Consiste en revisar y rectificar los posibles errores que se hayan presentado durante la apliciación de las pruebas piloto, con el fin de llegar a un cuestionario definitivo. Los pasos 4 y 5; se pueden repetir tantas veces se considere necesario hasta que se obtenga un cuestionario lo mas libre de errores posible, esto sin perder de vista que implica un costo importante en la investigación; por lo que los investigadores deben tener la capacidad de detectar los errores lo más rápido posible.
Recolección de datos y análisis


Lo primero que se tiene que hacer es entrenar a los encuestadores, quienes serán los encargados de contactar a los encuestados y vaciar las preguntas en un formato para su posterior análisis.
El análisis se debe iniciar con la limpieza de la información, con la confirmación de las escalas, verificación del correcto llenado de las encuestas y en ocasiones con pretabulaciones (en el caso de preguntas abiertas). Una vez se tiene codificada toda la información el análisis como tal puede dar inicio.


La información también puede ser en una pequeña escala y obtenida mediante información cualitativa, siendo las Sesiones de Grupo la herramienta más usada..
Formular hallazgos


Luego de analizar la información se puede hacer deducciones acerca de lo que sucede en el mercado, lo cual se le conoce como “hallazgos”. Estos deben presentarse de una manera ordenada y lógica ante las personas encargadas de tomar las decisiones.
Los reportes de investigación deben tener un capítulo de resumen, el cual será la guía para las personas que no conocen de investigación, haciendo el informe mucho más fácil de leer y seguir una continuidad, según Katy R.

2. Determinar los elementos de un sistema de base de datos

♣ Base de datos:
El término de bases de datos fue escuchado por primera vez en 1963, en un simposio celebrado en California –USA.Una
base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada.desde un punto informático, la base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos.

Los elementos básicos de una base de datos son:
entidades (entities)
campos (fields)
records
archivos (files)
llaves (keys)

1. Entidad – Persona, lugar, objeto u evento para el cual se obtiene y mantiene datos. Ejemplo: Cliente, Orden, Producto, Suplidor.

2. Campo – Atributo o característica de la entidad. Ejemplo: en la entidad Cliente, algunos campos pueden ser Nombre, Apellido, Dirección.

3. Record – Es una colección o grupo de campos que describen un miembro de una entidad. Ejemplo, el record de un cliente, o de un producto.

4. Archivo – Es un grupo de records que contienen datos sobre una entidad en específico. Ejemplo: el archivo de clientes, es archivo de productos, o de empleados.

5. Llave o "Key" – Es un campo que se usa para localizar, acceder o identificar un record en específico. Hay cuatro tipos de “key”:

a. "Primary key" – es un campo u combinación de campos que en forma única y mínima identifica un miembro en particular de una entidad. Es único porque no hay dos miembros con el mismo "key". Es mínimo porque contiene tan solo la información necesaria para identificar al miembro de la entidad. Si el "primary key" es una combinación de varios campos se conoce como “multivalue key".
b. "Candidate key" – cualquier campo que pueda servir como "primary key". Para seleccionar al "primary key", se escoge el campo que tenga menos datos y sea más fácil de usar. Cualquier campo que no es un "primary key" o un "candidate key" se llama "nonkey field."
c. "Foreign key" – es un cambo en un archivo que debe parear con el valor del "primary key" de otro archivo para que se pueda establecer una relación o “link” entre ambos archivos.
d. "Secondary key" – es un campo u combinación de campos que se puede usa para acceder records. Los "secondary keys" no necesitan ser únicos. Ejemplo: nombre del cliente, código postal (zipcode).


bibliografia:

CAMPBELl, Mary. base IV Guía de Autoenseñanza.
España. Editorial McGraw Hill – Interamericana. 1990. pp110/111,121/122,161,169, 179-191/192.
HARWRYSZKIEWYCZ, I T. Análisis y diseño de base de datos. Editorial Megabyte. Noriega Editores.
México. 1994. pp29/31LAUDON, Kenneth C. Administración de los sistemas de información. 3ra. Edición. México. 1996. pp 271/295 Aprende computación. Editorial océano. España. Pp36/39 Búsquedas en Internet:monografias.com/trabajos5/tipbases/tipbases.shtmlmonografias.com/trabajos5/basede/basede.shtmlmonografias.com/trabajos5/desor/desor.shtmlinei.gob.pe/cpi/bancopub/libfree/lib607/cap01.htmet.gob.peelizabethpeguero.8m.com/enza.htm learnthenet.com/spanish/glossary/database.htmipyme.org/sie/

lunes, 2 de marzo de 2009

Requerimientos de un sistema


Requerimientos de un sistemaLos requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y además contienen múltiples relaciones entre sí. Lo que nos da a concluir, de acuerdo a lo expuesto en el capítulo de complejidad en el software, que el conjunto de requerimientos de un sistema computacional es complejo.

El análisis de requerimientos consiste brevemente en los siguientes pasos:


En ingeniería de sistemas existen tres tipos de requerimientos.

  • 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.


Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.


En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.

Características


Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo

  • Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
  • No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
  • Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
  • Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
  • Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
  • Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
  • Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.


Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema. Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden sustituir o mapear con esta lista de características.


En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requerimientos de los inversores, que pueden entrar en conflicto entre ellos.


Una terminología usada a veces pero no completamente análoga es "Ingeniería de Requisitos". Esta ingeniería comprende, básicamente, todo el proceso y tareas involucradas en la Captura, Elicitación, Análisis y Especificación de Requisitos o requerimientos. La comunidad internacional se decantó por el uso de la palabra Requerimientos en lugar de Requisitos, para resolver una posible ambigüedad en el uso de los términos. Actualmente el usar la palabra "Requisito" debe ser documentado explicando el motivo su uso en lugar del término consensuado.


El propósito de la ingeniería de requerimientos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos Requerimientos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.


Fases de implementación


Desde un punto de vista conceptual, las actividades son de 5 clases.

  • Obtener requerimientos: A través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
  • Analizar requerimientos: Detectar y corregir las falencias comunicativas, transformando los requerimientos obtenidos de entrevistas y requerimientos, en condiciones apropiadas para ser tratados por el diseño.
  • Documentar requerimientos: Igual que todas las etapas, los requerimientos deben estar debidamente documentados.
  • Verificar los requerimientos: Consiste en comprobar el correcto funcionamiento de un requerimiento en la aplicación
  • Validar los requerimientos: Comprobar que los requerimientos implementados se corresponden con lo que inicialmente se pretendia.

APLICACIÓN DE LA TOMA DE DECICISONES EN LOS SISTEMAS



Toma de decisiones: acción de elegir entre varias alternativas. Procedimiento interactivo un ciclo que incluye varios ciclos sucesivos de alternativas y decisiones.

Modelos de Toma de decisiones

Modelos físicos: representan la entidad estudiada en cuanto a su apariencia y, hasta cierto punto, en cuanto a sus funciones. Los modelos físicos pueden ser:
  • icónicos: Tienen aspecto de realidad pero no se comportan efectivamente en la forma real.
  • analógicos: Exhiben el comportamiento real de la entidad estudiada pero no tiene el mismo aspecto.
  • Modelos simbólicos: Reproducen sistemas o entidades mediante el uso de símbolos para representar los objetos físicos. Los tipos de modelos simbólicos son:
  • Narrativos: Descripciones en lenguaje natural que indican las relaciones entre las variables de un proceso o de un sistema.
  • Gráficos: Describen partes o pasos de una entidad o proceso mediante una representación gráfica (diagrama de flujo).
  • Matemáticos: Se valen de variables cuantitativas (fórmulas) para representar las partes de un proceso o de un sistema. También son los más abstractos y, a la vez, los más fáciles de usar debido a que todas las relaciones están expresadas con precisión, reduciendo así la posibilidad de malas interpretaciones por los usuarios del modelo.


Sistemas expertos y bases de conocimiento


Un sistema experto es un programa de software diseñado para replicar el proceso de toma de decisiones de un experto humano. Los sistemas expertos dependen del conocimiento objetivo, pero confían también en el conocimiento heurístico como la intuición, el discernimiento y las inferencias. Para simplificar el proceso existen los shells de sistemas expertos que contienen las interfaces humanas y las máquinas de inferencias. Los principales componentes de la envoltura de sistema experto son:

  • Instalaciones de aprendizaje: permiten la construcción de la base de conocimiento.
  • Base del conocimiento: para completar la base de conocimiento se captura la siguiente información:
  • Identificación del problema;
  • Soluciones posibles; y
  • Cómo avanzar del problema a la solución a través de hechos y reglas.
    Interfaz para usuario: permite la interacción necesaria entre el usuario y el sistema experto para el procesamiento heurístico; permite que el usuario describa el problema u objetivo y que tanto el usuario como el sistema experto estructuren preguntas y respuestas.


Funciones de la probabilidad


La toma de una decisión, fundamentalmente, tiene que ver con combinar información sobre probabilidades con información sobre deseos e intereses. Significa que tenemos que compensar el valor de un cierto resultado contra su probabilidad. Para operar la decisión debemos hacer cálculos del valor de un cierto resultado y sus probabilidades, y a partir de allí de las consecuencias de las elecciones.


BIBLIOGRAFIA:

domingo, 1 de marzo de 2009

Requerimientos de un sistema


Estudio de factibilidad


Estudio de factibilidad es el análisis comprensivo 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).

En general los análisis de factibilidad más profundos, o los estudios de factibilidad, se completan durante la fase de diseño de sistemas, en general durante la consideración de la evaluación de las diferentes alternativas de solución propuestas. Los estudios de factibilidad consideran la factibilidad técnica, económica y operacional de cada alternativa, así como si el proyecto es o no apropiado dados los factores políticos y otros del contexto institucional.

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.

Objetivo de un Estudio de Factibilidad.

1.- Auxiliar a una organización a lograr sus objetivos.

2.- Cubrir la metas con los recursos actuales en las siguientes áreas.

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.

¿CUÁLES SON LOS PASOS A SEGUIR PARA UN PROYECTO DE FACTIBILIDAD?


La investigación de factibilidad en un proyecto consiste en descubrir cuáles son los objetivos de la organización, luego determinar si el proyecto es útil para que la empresa logre sus objetivos.La búsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar.En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos.Estos objetivos son los siguientes:

  • Reducción de errores y mayor precisión en los procesos.
  • Reducción de costos mediante la optimización o eliminación de recursos no necesarios.
  • Integración de todas las áreas y subsistemas de la empresa.
  • Actualización y mejoramiento de los servicios a clientes o usuarios.
  • Aceleración en la recopilación de datos.
  • Reducción en el tiempo de procesamiento y ejecución de tareas.
  • Automatización optima de procedimientos manuales.

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.


El éxito de un proyecto está determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores.


BIBLIOGRAFIA

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


1.1 INVESTIGACIÓN PRELIMINAR

INVESTIGACIÓN PRELIMINAR


La investigación preliminar es la obtención de conocimientos básicos sobre un tema; requiere determinar las necesidades de investigación con el objeto de evitar errores y encontrar soluciones viables a cualquier problema que se presente y se le conoce también como investigación exploratoria o sondeo de mercado.

Si un proyecto de sistema parece ser viable y tiene suficiente prioridad, se comienza la investigación preliminar. Esta investigación requiere uno o más analistas de sistemas analizando el “system request” para determinar la verdadera naturaleza, el alcance del problema y recomendar si es que se debe continuar con el proyecto. El propósito de la investigación preliminar 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 preliminar debe cumplir con los siguientes cinco objetivos:


1.
Entender la naturaleza del problema Es el 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, o sea, 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. La limitación 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 – y 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.



BIBLIOGRAFIA