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.