martes, 18 de mayo de 2010

APLICACION DEL SEMESTRE A EL PROYECTO

FORMATO FORMULACION BLOG




LO SIGUENTE ESTA APLICADO AL PROYECTO FINAL


EL PAPEL DE LA TEORIA DE INFORMACION

El objetivo global de la ingeniería de la información es aplicar tecnología de información de la mejor manera que satisfaga las necesidades del cliente. Para conseguirlo, la ingeniería de la información debe empezar por analizar los objetivos y metas, después debe definir las necesidades de la información. Solo después de hacer esto la ingeniería de la información hace la transición al dominio más técnico de la ingeniería de software; el proceso, donde los sistemas de información, aplicaciones y programas son analizados, diseñados y construidos.



EL PAPEL DEL ANALISTA DE SISTEMAS

El analista de sistemas generalmente valora la manera que funcionan los negocios de nuestra empresa examinando la entrada, el procesamiento de datos y la salida de información con el propósito de mejorar los procesos organizacionales de COLGAMES.



HOMEOSTASIS

EN COLGAMES LA HOMEOSTASIS SERIA UN SISTEMA ABIERTO YA QUE SON JUEGOS QUE ESTÁN DISPONIBLES PARA TODO EL PÚBLICO SIN NINGUNA RESTRICCIÓN


ENTROPIA

LA ENTROPÍA PODRÁ TOMARSE COMO EL SOFTWARE QUE SE USARA PARA LA CREACIÓN DE LOS JUEGOS DE NUESTRA EMPRESA, SON SISTEMAS CERRADOS Y AISLADOS QUE NO PERMITEN SER MODIFICADOS Y REVENDIDOS



NEGENTROPIA

COLGAMES NO SE RINDE ANTE LA OPOSICIÓN NI LOS MEDIO QUE QUIERAN CANCÉLALO, NUESTRA EMPRESA SE PREOCUPA POR EL USUARIO Y POR SATISFACERLO ANTE CUALQUIER COMPETENCIA QUE SE LE COLOQUE EN FRENTE


RETROALIMENTACION

EN COLGAMES NUESTRA RETROALIMENTACIÓN ES QUE AL DISEÑAR UN JUEGO LOS USUARIOS CON SUS COMENTAROS PODRÁN SUGERIR ALGÚN CAMBIO AL JUEGO ENTONCES EL JUEGO VUELVE A NOSOTROS Y ASÍ SALDRÁ OTRA VEZ AL MERCADO ACTUALIZADO


CAJA NEGRA

LAS ENTRADAS SON LAS IDEAS DE LOS DESARROLLADORES O SUGERENCIAS DE LOS CLIENTES PARA LA CREACION DE LOS JUEGOS DE COLGAMES Y LAS SALIDAS EL FUNCIONAMIENTO DE LOS MISMOS.



INGENIERIA DE REQUISITOS

Muchas veces se habla de requerimientos en vez de requisitos, esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

el proposito es que un requisito que se le solicita al usuario es que el tipo de juego que desee sea compatible con su telefono celular par asi no tener inconvenientes futuros.

BIBLIOTECA

martes, 11 de mayo de 2010

DISEÑO DE SISTEMAS

DISEÑO ORIENTADO A OBJETOS

1.¿En que se basa el enfoque de diseño orientado a objetos?

R// se basa en una descripción del problema el lenguaje natural.

2.¿Cuales son los tipos de datos abstractos?

R// Dividir el documento en palabras.
Revisar si las palabras que no están en el diccionario.
Formar listas de palabras que no están en el diccionario.
Intercalar las palabras buenas en el diccionario, para obtener un nuevo diccionario.

3. En que se basa el diseño orientado a objeto

R// El diseño orientado a objetos se basa en la idea de utilizar ocultamiento de información
como criterio de descomposición y en la noción de los tipos de datos abstractos.



DISEÑO DE LA SALIDA

1. ¿Cual es el diseño de salida?

R// es esencialmente para asegurar el uso y aceptación del sistema de información.

2. ¿Cómo seleccionar la tecnología de salida?

R// El analista necesita reconocer los compromisos involucrados en la sección de un método de salida.
así como la flexibilidad, tiempo de vida, distribución almacenamiento y posibilidades de recuperación,
transportabilidad e impacto general sobre los datos para el usuario.

3. ¿Cómo debe ser la relación del contenido de la salida con el método de salida?

R// debe considerarse interrelacionado con el método de salida. Cada vez que se diseña una salida, es necesario
pensar sobre cómo la función influencia la forma y cómo el propósito influencia la salida que se escoge.

4. ¿Cuáles son los factores a considerar cuando se selecciona la tecnología de salida?

R// A. Descubrir quien usara la salida.
B. se aplican diferentes estándares, dependiendo si el receptor de la salida es interno.
c. se les debe proporcionar salida impresa a desarrollar otra interfaz común
D. La salida puede tomar virtualmente cualquier forma, incluyendo la impresión, pantallas, audio, microformas,
CD-ROM y electrónica.



DISEÑO DE ENTRADA

1. ¿Cual es el diseño de entrada?

R// Es el que determina la calidad de la salida del sistema.

2. ¿Cuales son algunas desventajas del uso de formas especiales?

R// A. debe esforzarse para darse cuenta de las cualidades únicas de las pantallas de desplegado
B. deben parecer organizadas y lógicas
C. deben solicitar la información en el orden esperado

3. ¿Cómo debe ser el diseño de formas atractivas?

R// -Las formas no deben verse amontonadas
-Par ser atractivas, las formas deben solicitar la información en el orden esperado.
-El uso de diferentes tipos de letra dentro de la misma forma puede ayudar a hacer atractivo el llenarla
-separar categorías y subcategorias con líneas gruesas y delgadas

4. ¿Cuáles son las secciones de una pantalla?

R// -La parte superior de la pantalla
-La sección media de la pantalla
-La tercera sección de la pantalla

DISEÑO DE BASES DE DATOS


1. ¿Cual es el diseño de base de datos?

R// ESTA ESTRUCTURADA DE LA SIGUIENTE FORMA:
A. INTEGRIDA DE DATOS
B. DISPONIBILIDAD DE DATOS
C. ALMACENAMIENTO DE DATOS EXISTENTES
D. RECUPERACION DE INFORMACION PARA UN PROPOSITO


2. ¿Qué son las bases de datos?

R// FUENTE CENTRAL DE DATOS QUE ESTA PENSADA PARA QUE SEA COMPARTIDA Y ES CONSIDERADA COMO LA PARTE MEDULAR
DEL SISTEMA DE INFORMACION

3. ¿cuáles son los tipos de archivos?

R// LOS TIPOS DE ARCHIVOS SON:
A. MAESTROS
B. TABLAS
C. TRANSACCION
D. DE REPORTE

4. ¿En que consiste la organización secuencial?

R// CONSISTE QUE CUANDO LOS REGISTROS ESTAN FISICAMENTE EN ORDEN EN UN ARCHIVO QUIERE DECIR QUE SI COINCIDE
Y SE ACTUALIZAN RECORRIENDO TODO EL ARCHIVO


5. ¿Cuáles son las listas encadenadas?

R// SON AQUELLOS ARCHIVOS QUE SE GUARDAN EN ACCESO DIRECTO TALES COMO DISCOS, TAMBOR, ETC. LOS REGISTROS PUEDEN
SER ORDENADOS EN FORMA LOGICA USANDO LISTAS ENCADENADAS



DISEÑO DE LA INTERFAZ HOMBRE-MAQUINA


1. ¿Qué es el diseño de la interfaz hombre-máquina?

R// El proceso general para diseñar la interfaz de usuario empieza con la creación de diferentes modelos de función
del sistema (tal y como se percibe desde fuera). Se definen las tareas orientadas al hombre y a la maquina, requeridas
para conseguir la función del sistema; se consideran los aspectos de diseño aplicables a todos los diseños del sistema;
se consideran los aspectos del diseño aplicables a todos los diseños de interfaz; se usan herramientas para crear el prototipo
e implementar el modelo de diseño y se evalúa la calidad del resultado.

2. ¿Para qué sirven los modelos de diseño de interfaz?

R// Un modelo de usuario muestra el perfil de los usuarios finales del sistema. Para construir una interfaz de usuario eficaz,
"todo diseño debería empezar con el conocimiento de los usuarios a los que va dirigido, incluyendo perfiles con el conocimiento de su edad,
sexo, capacidades físicas, estudios, historial cultural o étnico, motivación, metas y personalidad". Además, los usuarios se pueden categorizar.

3. ¿Cuáles son los 4 aspectos comunes del diseño que casa siempre emergen a medida que evoluciona el diseño
de la interfaz del usuario?

R//A.El ingeniero de software crea un modelo de diseño.
B.El "ingeniero del software" establece un modelo de usuario.
C.El usuario final desarrolla una imagen mental que se denomina a menudo el modelo del usuario o la percepción del sistema.
D.Los creadores del sistema crean una imagen del sistema.

4. ¿Cuál es el papel de diseñador de interfaces?

R// Para construir una interfaz de usuario eficaz, "todo diseño debería empezar con el conocimiento de los usuarios a los que va dirigido,
incluyendo perfiles con el conocimiento de su edad, sexo, capacidades físicas, estudios, historial cultural o étnico, motivación, metas y personalidad".



ESTRUCTURA CLIENTE/SERVIDOR


1. ¿En qué consiste el diseño en ambiente de redes?

R// Un sistema raíz típicamente será una gran computadora, actúa como deposito de los datos corporativos.
El sistema raíz esta conectado con servidores (típicamente son estaciones de trabajo potentes, o PC) y
que poseen un doble papel. Los servidores actúan para actualizar y solicitar los datos corporativos mantenidos
por el sistema raíz. Además mantienen sistemas departamentales locales y desempeñan un papel clave al poner en
red los PC de nivel de usuario a través de una red de área local (LAN).


2. ¿Cómo se debe ser la estructura de los sistemas cliente / servidor?
R// Servidores de archivos. El cliente solicita registros específicos de un archivo. El servidor transmite estos registros al cliente a través de la red.
Servidores de base de datos. El cliente envía solicitudes en lenguaje de consulta estructurado (SQL) al servidor. Estas se transmiten como mensajes a
través de la red. El servidor procesa la solicitud SQL y halla la información solicitada, pasando únicamente los resultados al cliente.
Servidores de transacciones. El cliente envía una solicitud que invoca procedimientos remotos en el centro servidor. Los procedimientos remotos pueden
ser una conjunto de sentencias SQL. Se produce una transacción cuando una solicitud da lugar a la ejecución de procedimientos remotos y a la transmisión del resultado devuelto al cliente.
Servidores de grupos de trabajo. Cuando el servidor proporciona un conjunto de aplicaciones que hacen posible la comunicación entre clientes (y entre las
personas que los usan) mediante el uso de texto, imágenes, boletines electrónicos, vídeo y otras representaciones, existe una arquitectura de grupos de trabajo.


3. ¿Cuáles son las cinco configuraciones diferentes para la asignación de componentes de software?
R//A. Presentación distribuida.
B. Presentación remota.
C. Lógica distribuida.
D. Gestión de datos remota.



4. ¿Cómo debe ser el diseño para sistemas cliente/servidor?

R//• El diseño de datos domina el proceso de diseño. Para utilizar efectivamente las capacidades de un sistema de gestión de bases de datos relacional (SGBDR) o un sistema de gestión de bases de datos orientado a objetos (SGBDOO) el diseño de los datos pasa a ser todavía más significativo que en las aplicaciones convencionales.
• Cuando se selecciona el paradigma controlado por sucesos, el modelado del comportamiento (una actividad de análisis), deberá de realizarse y será preciso traducir los aspectos orientados al control implícitos en el modelo de comportamiento al modelo de diseño.
• El componente de interacción/presentación del usuario de un sistema C/S implementa todas aquellas funciones que se asocian típicamente con una interfaz gráfica de usuario (IGU).
• Suele seleccionarse un punto de vista orientado a objetos para el diseño. En lugar de la estructura secuencial que proporciona un lenguaje de procedimientos se proporciona una estructura de objetos mediante la vinculación entre los sucesos iniciados en la IGU y una función de gestión de sucesos que reside en el software basado en el cliente.

5. ¿Para qué es necesario el diseño de bases de datos en el ambiente de redes?

R// Un sistema de base de datos relacional (SGBDR) hace fácil el acceso a datos distribuidos mediante el uso del lenguaje de consulta estructurado (SQL).
La ventaja de SQL en una arquitectura C/S es que "no requiere navegar". La implicación de esto es que el sistema de base de datos relacional debe de ser suficientemente sofisticado
para mantener la ubicación de todos los datos y tiene que ser capaz de definir la mejor ruta hasta ella. En sistemas de bases de datos menos sofisticados, una solicitud de datos debe de indicar a que hay que acceder y donde se encuentra. Si el software de aplicación debe de mantener la información de navegación, entonces la gestión de datos se vuelve mucho más complicada por los sistemas C/S.

martes, 13 de abril de 2010

martes, 6 de abril de 2010

INGENIERIA DE REQUISITOS

En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requisitos 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 requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos, esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos 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 requisitos: A través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
-Analizar requisitos: Detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
-Documentar requisitos: Igual que todas las etapas, los requisitos deben estar debidamente documentados.
-Verificar los requisitos: Consiste en comprobar el correcto funcionamiento de un requisito en la aplicación
-Validar los requisitos: Comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.

Técnicas principales

Entrevistas:
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización
Talleres:
pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas.

Forma de contrato :
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.


Objetivos medibles:
Los requisitos formulados por los usuarios se toman como objetivos generales,a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno
Prototipos:
Un prototipo es una pequeña muestra, de funcionalidad limitada.
Casos de uso:
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas.

REQUERIMIENTO (sistemas)

En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.

En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.

La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.



¿Que es un requerimiento?
-Condición o capacidad que un usuario necesita para poder resolver un problema o
lograr un objetivo (IEEE).
-Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un
contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
-Una condición o capacidad que debe ser conformada por el sistema (RUP).
-Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).

Requerimientos en ingeniería de software y sistemas

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

martes, 16 de marzo de 2010

MODELADO DE DATOS

Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un modelo de datos permite describir:
  • Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.
  • Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.
  • Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.

Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software.

TIPOS DE MODELADO DE DATOS

1. Modelos de Datos Conceptuales

Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.

2. Modelos de Datos Lógicos

Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos).

3. Modelos de Datos Físicos

Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.

Sublenguajes de un Modelo de Datos

  1. Un Lenguaje de Definición de Datos o DDL (Data definition Language), orientado a describir de una forma abstracta las estructuras de datos y las restricciones de integridad.
  2. Un Lenguaje de Manipulación de Datos o DML (Data Manipulation Language), orientado a describir las operaciones de manipulación de los datos.

A la parte del DML orientada a la recuperación de datos, usualmente se le llama Lenguaje de Consulta o QL (Query Language).

RECOLECCION DE DATOS


ENCUESTA







sábado, 6 de marzo de 2010

DEFINICIONES

Homeostasis
(Del griego homos que que significa "similar", y estasis "posición", "estabilidad") es la característica de un sistema abierto o de un sistema cerrado, especialmente en un organismo vivo, mediante la cual se regula el ambiente interno para mantener una condición estable y constante. Los múltiples ajustes dinámicos del equilibrio y los mecanismos de autorregulación hacen la homeostasis posible. El concepto fue creado por Walter Cannon y usado por Claude Bernard, considerado a menudo como el padre de la fisiología, y publicado en 1865.También significa medio interno. Tradicionalmente se ha aplicado en biología, pero dado el hecho de que no sólo lo biológico es capaz de cumplir con esta definición, otras ciencias y técnicas han adoptado también este término.

Entropía
Aunque la entropía expresa sus propiedades de forma evidente en sistemas cerrados y aislados, también se evidencian, aunque de forma más discreta, a sistemas abiertos; éstos últimos tienen la capacidad de prolongar la expresión de sus propiedades a partir de la importación y exportación de cargas desde y hacia el ambiente, con este proceso generan neguentropía (entropía negativa), y la variación que existe dentro del sistema en el instante A de tiempo con la existente en el B, se denomina variación de la entalpía.

Negentropía
La podemos definir como el paquete de energía que emerje ante la oposición del medio que tiende a cancelarlo. La onda portadora de la información, deberá armonízar y resonar con otras formas de onda, como resultado de la coincidencia en el tiempo y el espacio de distintas formas de expresión que han sido despreciadas por los sistemas colindantes.En apariencia, se opone al segundo principio de la termodinámica, pero es una fuerza que tiende a fomentar la emergencia de nuevas propiedades. Ello da base a la evolución de los sistemas, pues su resultado son más paquetes de energía que son cuantificables por los sistemas existentes y por lo tanto los condicionan a adaptarse a la "nueva moneda" que marca el ritmo de la economíoa del sistema. Según opiniones, hay quien lo catalogaría de mayores niveles de orden en los sistemas abiertos.

Retroalimentación
La realimentación es un mecanismo, un proceso cuya señal se mueve dentro de un sistema, y vuelve al principio de éste sistema ella misma como en un bucle. Este bucle se llama "bucle de realimentación". En un sistema de control, éste tiene entradas y salidas del sistema; cuando parte de la señal de salida del sistema, vuelve de nuevo al sistema como parte de su entrada, a esto se le llama"realimentación" o retroalimentación.

Caja Negra
En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

SISTEMA SOLAR


Es un sistema planetario de la galaxia Vía Láctea que se encuentra en uno de los brazos de ésta, conocido como el Brazo de Orión. Según las últimas estimaciones, el Sistema Solar se encuentra a unos 28 mil años-luz del centro dela Vía Láctea.

Está formado por una única estrella llamada Sol, que da nombre a este Sistema, más ocho planetas que orbitan alrededor de la estrella: Mercurio, Venus, la Tierra, Marte, Júpiter, Saturno, Urano y Neptuno; más un conjunto deotros cuerpos menores: planetas enanos (Plutón, Eris, Makemake, Haumea, Sedna y Ceres), asteroides, satélites naturales, cometas... así como el espacio interplanetario comprendido entre ellos.

Características generalesLos planetas y los asteroides orbitan alrededor del Sol, en la misma dirección siguiendo órbitas elípticas en sentido antihorario si se observa desde encima del polo norte del Sol. El plano aproximado en el que giran todos estos sedenomina eclíptica. Algunos objetos orbitan con un grado de inclinación considerable, como Plutón con una inclinación con respecto al eje de la eclíptica de 18º, así como una parte importante de los objetos del cinturón de Kuiper. Según sus características, y avanzando del interior al exterior, los cuerpos que forman el Sistema Solar se clasifican en:


  • Sol

  • Planetas

  • Planetas enanos (Esta nueva categoria inferior a planeta la creo la union astronomica internacional. se trata de cuerpos cuya masa les permite tener la forma esperica, pero no es la suficiente para haber atraído o expulsado a todos los cuerpos a su alrededor. Cuerpos como Plutón (hasta 2006 considerado noveno planeta del Sistema Solar), Ceres, Makemake y Eris están dentro de esta categoría.))

  • Satelites

  • Asteroides

  • Objetos del cinturón de Kuiper

  • Cometas

martes, 9 de febrero de 2010

EL PAPEL DE LA TEORIA DE INFORMACION

El objetivo global de la ingeniería de la información es aplicar tecnología de información de la mejor manera que satisfaga las necesidades generales del negocio. Para conseguirlo la ingeniería de la información debe empezar por analizar los objetivos y metas del negocio, después debe definir las necesidades de la información de cada área de negocio y del negocio en su totalidad. Solo después de hacer esto la ingeniería de la información hace la transición al dominio más técnico de la ingeniería de software; el proceso, donde los sistemas de información, aplicaciones y programas son analizados, diseñados y construidos.

EL PAPEL DEL ANALISTA DE SISTEMAS

El analista de sistemas generalmente valora la manera que funcionan los negocios examinando la entrada, el procesamiento de datos y la salida de información con el propósito de mejorar los procesos organizacionales.
Muchas mejoras involucran mejor apoyo para las funciones de los negocios por medio del uso de sistemas de información computarizados. Esta definición enfatiza un enfoque sistemático y metódico para analizar, y posiblemente mejorar, lo que esta sucediendo con el contexto especifico creado por un negocio.
Se requiere que los analistas de sistemas desempeñen muchos paquetes en el curso de su trabajo. Algunos de estos papeles son:
  1. Consultores externos para negocios.
  2. Experto de soporte dentro de un negocio.
  3. Agente de cambio en situaciones tanto internas como externas.


Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta funcional. Los analistas de sistemas requieren habilidades de comunicación que les permitan relacionarse en forma significativa con muchos tipos de gente diariamente, así como habilidades de computación. Para su éxito es necesario que se involucre el usuario final.
Los analistas proceden sistemáticamente. El marco de referencia para su enfoque sistemático es proporcionado por lo que es llamado el ciclo de vida del desarrollo de sistemas (SDLC). Este puede ser dividido en siete fases secuenciales, aunque en realidad las fases están interrelacionadas y frecuentemente se llevan a cabo simultáneamente. Las siete fases son:

  1. Identificación de problemas.
  2. Oportunidades y objetivos
  3. Determinación de los requerimientos de información
  4. Análisis de las necesidades de sistemas
  5. Diseño del sistema recomendado
  6. Desarrollo y documentación del software
  7. Prueba y mantenimiento del sistema e implementación del mismo.

Los paquetes de software basados en microcomputadora automatizado para el análisis y diseño de sistemas son llamados herramientas CASE. Las cuatro razones para la adopción de herramientas CASE son:

  1. El incremento de la productividad del analista
  2. La mejora de la comunicación entre analistas y usuarios
  3. La integración de actividades del ciclo de vida y el análisis.
  4. La valoración del impacto de los cambios por mantenimiento.

Los analistas también usan enfoque CARE (Reingeniería Asistida por Computadora) para hacer ingeniería inversa y reingeniería de software para extender la vida del software legado.
Un enfoque nuevo y diferente al análisis y diseño de sistemas es el análisis y diseño de sistemas orientados a objetos (O-O). Estas técnicas están basadas en conceptos de programación orientada a objetos en los cuales los objetos, que son creados incluyen no solamente código acerca de los datos sino también instrucciones acerca de las operaciones que se pueden realizar con ellos.
Cuando la situación organizacional lo demanda, el analista puede apartarse del SDLC para intentar una metodología alterna, tal como la elaboración de prototipos, ETHICS, el enfoque de campeón de proyecto, la metodología Soft Systems o Multiview.

martes, 2 de febrero de 2010

ANALISIS Y DISEÑO DE SISITEMAS .DEFINICION

ANALISIS DE SISTEMAS



trata básicamente de determinar los objetivos y límites del sistema objeto de análisis, caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar sus consecuencias. Dependiendo de los objetivos del análisis, podemos encontrarnos ante dos problemáticas distintas:


  • Análisis de un sistema ya existente para comprender, mejorar, ajustar y/o predecir su comportamiento

  • Análisis como paso previo al diseño de un nuevo sistema-producto


DISEÑO DE SISTEMAS


se ocupa de desarrollar las directrices propuestas durante el análisis en función de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones). El proceso de diseño de un sistema complejo se suele realizar de forma descendente:



  • Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos)

  • Diseño e implementación de cada uno de los subsistemas:

  • Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis

  • Desarrollo según la especificación

  • Prueba

  • Integración de todos los subsistemas

  • Validación del diseño

ANALISIS Y DISEÑOS DE SISTEMAS. DEFINICION