Estas son las distribuciones de actividades para el III Parcial:
Jean Carlo:
- Empezar el Documento explicando los actores
- Incluir las imagenes de los casos de uso en el Documento
- Explicar en detalle que hace cada caso de uso
Lenin:
- Llenar los Diagramas de Casos de Uso para cada caso de uso de los tres diagramas de caso de uso presentados en el documento.
- Incluir en el Documento con Impresiones de Pantalla todos los casos de uso terminados.
Fausto:
- Realizar el diagrama de entidad relacion para el modelo.
- Incluir el diagrama de actividades en el documento.
Jefry:
- Realizar la investigacion de Diagramas de Clases.
- Entregar investigacion en la fecha indicada.
lunes, 9 de agosto de 2010
Preguntas Capitulo 7
7.1 Mencione quienes podrían ser los skateholders en un sistema de registro de estudiantes universitarios. Explique porque es casi inevitable que los requerimientos de diferentes skateholders entren en conflicto de alguna forma.
R-/ Pues los skateholder son las personas o grupos que se verán afectados por el sistema, directa o indirectamente. En un sistema de registro de estudiantes podrían ser los estudiantes, los catedráticos, las personas de administración, las instituciones bancarias. Es inevitable que los requerimientos de los skateholders entren en conflicto porque los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos
7.5 Utilizando su conocimiento de cómo funciona un cajero automático de un banco, desarrolle un conjunto de casos de uso que podrían servir como una base para entender los requerimientos de un sistema de un cajero automático.
R-/ Los casos de uso para un cajero automático podrían ser:
1. Identificación
2. Realizar Retiro
3. Obtener Saldo de Cuenta
4. Obtener Últimos Movimientos
5. Cambiar de PIN
6. Realizar otras transacciones bancarias
7.6 De un ejemplo de un tipo de sistema en el que los factores sociales y políticos pueden influir fuertemente en los requerimientos del sistema. Explique por que estos factores son importantes en el ejemplo.
R-/ Para mí un tipo de sistema en el que los requerimientos políticos y sociales pueden influir podría ser un sistema para control de registro de personas en el cual sus necesidades de toma de información pueda cambiar de acuerdo a las legislaciones del gobierno. Otro podría ser un sistema de control de votaciones electorales en el cual los datos a registrar puedan cambiar de acuerdo al cambio en las planillas y las papeletas de votación.
7.8 ¿Por qué las matrices de rastreo son difíciles de manejar cuando existen muchos requerimientos en el sistema? Diseñe un mecanismo de estructuración de requerimientos, basado en puntos de vista, que pueda ayudar a reducir el tamaño del problema.
R-/ Las matrices de rastreo pueden utilizarse cuando se tienen que gestionar un número pequeño de requerimientos, pero son difíciles de manejar y caras de mantener para sistemas grandes con muchos requerimientos. Para sistemas con requerimientos grandes, se debería de captar la información de rastreo en una base de datos de requerimientos en la que cada requerimiento este explícitamente vinculado a los requerimientos relacionadas
7.9 Cuando se hacen cambios de emergencia en los sistemas, el sistema software puede tener que modificarse antes de que los cambios en los requerimientos se aprueben. Sugiera un modelo de proceso para hacer estas modificaciones que asegure que el documento de requerimientos y la implementación del sistema no sean compatibles.
R-/ Pues sugeriría un modelo de proceso denominado por componentes o versiones, en el cual se puedan desarrollar paralelamente los requerimientos pendientes de modificar en un componente aparate del sistema actual para que no perjudique el desempeño actual de la aplicación y al momento de aprobarlos y adaptarlos a producción ya solo se integre el componente que fue desarrollado y probado antes de ser puesto en producción.
R-/ Pues los skateholder son las personas o grupos que se verán afectados por el sistema, directa o indirectamente. En un sistema de registro de estudiantes podrían ser los estudiantes, los catedráticos, las personas de administración, las instituciones bancarias. Es inevitable que los requerimientos de los skateholders entren en conflicto porque los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos
7.5 Utilizando su conocimiento de cómo funciona un cajero automático de un banco, desarrolle un conjunto de casos de uso que podrían servir como una base para entender los requerimientos de un sistema de un cajero automático.
R-/ Los casos de uso para un cajero automático podrían ser:
1. Identificación
2. Realizar Retiro
3. Obtener Saldo de Cuenta
4. Obtener Últimos Movimientos
5. Cambiar de PIN
6. Realizar otras transacciones bancarias
7.6 De un ejemplo de un tipo de sistema en el que los factores sociales y políticos pueden influir fuertemente en los requerimientos del sistema. Explique por que estos factores son importantes en el ejemplo.
R-/ Para mí un tipo de sistema en el que los requerimientos políticos y sociales pueden influir podría ser un sistema para control de registro de personas en el cual sus necesidades de toma de información pueda cambiar de acuerdo a las legislaciones del gobierno. Otro podría ser un sistema de control de votaciones electorales en el cual los datos a registrar puedan cambiar de acuerdo al cambio en las planillas y las papeletas de votación.
7.8 ¿Por qué las matrices de rastreo son difíciles de manejar cuando existen muchos requerimientos en el sistema? Diseñe un mecanismo de estructuración de requerimientos, basado en puntos de vista, que pueda ayudar a reducir el tamaño del problema.
R-/ Las matrices de rastreo pueden utilizarse cuando se tienen que gestionar un número pequeño de requerimientos, pero son difíciles de manejar y caras de mantener para sistemas grandes con muchos requerimientos. Para sistemas con requerimientos grandes, se debería de captar la información de rastreo en una base de datos de requerimientos en la que cada requerimiento este explícitamente vinculado a los requerimientos relacionadas
7.9 Cuando se hacen cambios de emergencia en los sistemas, el sistema software puede tener que modificarse antes de que los cambios en los requerimientos se aprueben. Sugiera un modelo de proceso para hacer estas modificaciones que asegure que el documento de requerimientos y la implementación del sistema no sean compatibles.
R-/ Pues sugeriría un modelo de proceso denominado por componentes o versiones, en el cual se puedan desarrollar paralelamente los requerimientos pendientes de modificar en un componente aparate del sistema actual para que no perjudique el desempeño actual de la aplicación y al momento de aprobarlos y adaptarlos a producción ya solo se integre el componente que fue desarrollado y probado antes de ser puesto en producción.
miércoles, 21 de julio de 2010
Actividades de Tarea II Parcial
Las asignaciones de desarrollo de la Tarea de Desarrollo Diagramas de Actividades y Casos de Uso de la Propuesta UTH Virtual Grupo CALIF son:
FAUSTO A. MORAZAN:
Diagramas de Actividades
Desarrollo de Informe de Actividades y Casos de Uso
JEAN CARLO MOLINERO:
Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA:
Defiinicion de Plantillas de Caso de Uso
Exposicion de la Tarea:
LENIN RICARDO PINEDA Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA Diagramas de Actividades y Plantillas de Casos de Uso
Entrega de Informacion al Catedratico:
JEFFRY RAMON ZELAYA
FAUSTO A. MORAZAN:
Diagramas de Actividades
Desarrollo de Informe de Actividades y Casos de Uso
JEAN CARLO MOLINERO:
Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA:
Defiinicion de Plantillas de Caso de Uso
Exposicion de la Tarea:
LENIN RICARDO PINEDA Diagramas de Casos de Uso
JEFFRY RAMON ZELAYA Diagramas de Actividades y Plantillas de Casos de Uso
Entrega de Informacion al Catedratico:
JEFFRY RAMON ZELAYA
lunes, 19 de julio de 2010
Diagrama de Caso de Uso Alarma
Un Sistema sencillo de alarma contra ladrones Capitulo 2 Figura 2.6 de Libro de Texto
miércoles, 14 de julio de 2010
Ejercicios del Capítulo 6
6.1 Identifique y comente brevemente cuatro tipos de requerimientos que se pueden definir para un sistema informático.
R-/ Requerimientos del Usuario:
Son declaraciones de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
Requerimientos Funcionales:
Son declaraciones de los servicios que debe proporcionar el sistema.
Requerimientos no Funcionales:
Son restricciones de los servicios o funciones ofrecidas por el sistema.
Requerimientos del Dominio:
Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y las restricciones de ese dominio.
6.2 Comente los problemas de la utilización del lenguaje natural para definir los requerimientos del usuario y del sistema, y muestre, utilizando pequeños ejemplos, como el estructurar el lenguaje natural en formularios puede ayudar a evitar algunas de estas dificultades.
R-/ Falta de Claridad:
A veces es difícil utilizar el lenguaje de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer.
Confusión de Requerimientos:
No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la información para el diseño.
Conjunción de Requerimientos:
Diversos requerimientos diferentes se pueden expresar de forma conjunta como un único requerimiento.
6.3 Descubra las ambigüedades u omisiones en la siguiente declaración de requerimientos de una parte de un sistema expendedor de billetes.
Un sistema automático de expedición de billetes vende billetes de tren. Los usuarios seleccionan su destino e introducen una tarjeta de crédito y un número de identificación personal. El billete de tren se expide y se carga su cuenta a la tarjeta de crédito. Cuando el usuario presiona el botón de inicio, se activa un menú que muestra los posibles destinos, junto con un mensaje para el usuario que le indica que seleccione el destino. Una vez que se ha seleccionado un destino, se pide a los usuarios que introduzcan su tarjeta de crédito. Se comprueba su validez y entonces se le pide introducir un identificador personal. Cuando la transacción de crédito se haya validado, se expide el billete.
R-/ Creo que la ambigüedad es saber si la tarjeta se debe pedir antes o después, porque para emitir el billete sin saber los datos de la persona o sin saber si su tarjeta cubre el valor del destino donde desea viajar o si el emisor de la tarjeta no está en línea, etc No se puede continuar una transacción si no se dispone de ciertos factores que la final podrían causar desgaste o malestar por los usuarios del sistema.
6.4 Vuelva a redactar la descripción anterior utilizando el enfoque estructurado descrito en este capítulo. Resuelva de forma apropiada las ambigüedades identificadas
R-/ Función: Expedición de Billetes de Tren a Clientes de forma automatizada
Descripción: Emitir billetes de tren a un destino especificado por el usuario y cancelado con el uso de una tarjeta de crédito.
Entradas: Selección del Destino del Viaje.
Salida: La impresión del boleto hacia el destino respectivo.
Acción: El cliente introduce la tarjeta de crédito para validar su identificación, selecciona el destino al que quiere viajar y una vez realizado esto verifica el monto del boleto y lo carga a su tarjeta de crédito para luego imprimir el boleto
6.7 Describa 4 tipos de requerimientos no funcionales que pueden existir en un sistema. De ejemplos de cada uno de estos tipos de requerimientos.
R-/ Requerimientos del Producto:
Ejemplo: los requerimientos de rendimiento en la rapidez de ejecución del sistema.
Requerimientos Organizacionales:
Ejemplo: Los Estándares en los procesos que deben utilizarse; los requerimientos de implementación, como los lenguajes de programación
Requerimientos Externos:
Ejemplo: No se debe revelar al personal del sistema ninguna información personal de los usuarios
6.8 Redacte un conjunto de requerimientos no funcionales para el sistema expendedor de billetes, especificando su fiabilidad y su respuesta en el tiempo.
R-/ Requerimientos del Producto:
La interfaz del usuario se puede implementar de forma táctil de manera que el usuario no utilice ni teclado o más y en ambiente de navegador de internet.
Requerimientos Organizacionales:
La Documentación del Desarrollo y Manejo del Sistema debe entregarse en un formato de fácil lectura y de compresión sencilla para el usuario pueda consultarlos en línea.
Requerimientos Externos:
El sistema debe tener conectividad con los sistemas externos de control de tarjetas de crédito para validar la información del usuario en línea.
6.10 Ha obtenido un trabajo con un usuario de software quien ha contratado a su anterior compañía para desarrollar un sistema. Usted descubre que la interpretación de su compañía actual de requerimientos es diferente de la tomada por su anterior compañía. Comente que haría en tal situación. Usted sabe que los costes de su compañía actual se incrementaran si las ambigüedades no se resuelven. También tiene una responsabilidad de confidencialidad para su anterior compañía.
R-/ Pues lo que haría es evaluar la experiencia con mi compañía anterior de desarrollo que esta mas empapada de los requerimientos que exige como usuario y la experiencia de implementación de la misma para tratar de transmitir estos requerimientos a la compañía de desarrollo nueva y así llegar a la unificación de requerimientos sin ambigüedades
R-/ Requerimientos del Usuario:
Son declaraciones de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
Requerimientos Funcionales:
Son declaraciones de los servicios que debe proporcionar el sistema.
Requerimientos no Funcionales:
Son restricciones de los servicios o funciones ofrecidas por el sistema.
Requerimientos del Dominio:
Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y las restricciones de ese dominio.
6.2 Comente los problemas de la utilización del lenguaje natural para definir los requerimientos del usuario y del sistema, y muestre, utilizando pequeños ejemplos, como el estructurar el lenguaje natural en formularios puede ayudar a evitar algunas de estas dificultades.
R-/ Falta de Claridad:
A veces es difícil utilizar el lenguaje de forma precisa y no ambigua sin hacer el documento poco conciso y difícil de leer.
Confusión de Requerimientos:
No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la información para el diseño.
Conjunción de Requerimientos:
Diversos requerimientos diferentes se pueden expresar de forma conjunta como un único requerimiento.
6.3 Descubra las ambigüedades u omisiones en la siguiente declaración de requerimientos de una parte de un sistema expendedor de billetes.
Un sistema automático de expedición de billetes vende billetes de tren. Los usuarios seleccionan su destino e introducen una tarjeta de crédito y un número de identificación personal. El billete de tren se expide y se carga su cuenta a la tarjeta de crédito. Cuando el usuario presiona el botón de inicio, se activa un menú que muestra los posibles destinos, junto con un mensaje para el usuario que le indica que seleccione el destino. Una vez que se ha seleccionado un destino, se pide a los usuarios que introduzcan su tarjeta de crédito. Se comprueba su validez y entonces se le pide introducir un identificador personal. Cuando la transacción de crédito se haya validado, se expide el billete.
R-/ Creo que la ambigüedad es saber si la tarjeta se debe pedir antes o después, porque para emitir el billete sin saber los datos de la persona o sin saber si su tarjeta cubre el valor del destino donde desea viajar o si el emisor de la tarjeta no está en línea, etc No se puede continuar una transacción si no se dispone de ciertos factores que la final podrían causar desgaste o malestar por los usuarios del sistema.
6.4 Vuelva a redactar la descripción anterior utilizando el enfoque estructurado descrito en este capítulo. Resuelva de forma apropiada las ambigüedades identificadas
R-/ Función: Expedición de Billetes de Tren a Clientes de forma automatizada
Descripción: Emitir billetes de tren a un destino especificado por el usuario y cancelado con el uso de una tarjeta de crédito.
Entradas: Selección del Destino del Viaje.
Salida: La impresión del boleto hacia el destino respectivo.
Acción: El cliente introduce la tarjeta de crédito para validar su identificación, selecciona el destino al que quiere viajar y una vez realizado esto verifica el monto del boleto y lo carga a su tarjeta de crédito para luego imprimir el boleto
6.7 Describa 4 tipos de requerimientos no funcionales que pueden existir en un sistema. De ejemplos de cada uno de estos tipos de requerimientos.
R-/ Requerimientos del Producto:
Ejemplo: los requerimientos de rendimiento en la rapidez de ejecución del sistema.
Requerimientos Organizacionales:
Ejemplo: Los Estándares en los procesos que deben utilizarse; los requerimientos de implementación, como los lenguajes de programación
Requerimientos Externos:
Ejemplo: No se debe revelar al personal del sistema ninguna información personal de los usuarios
6.8 Redacte un conjunto de requerimientos no funcionales para el sistema expendedor de billetes, especificando su fiabilidad y su respuesta en el tiempo.
R-/ Requerimientos del Producto:
La interfaz del usuario se puede implementar de forma táctil de manera que el usuario no utilice ni teclado o más y en ambiente de navegador de internet.
Requerimientos Organizacionales:
La Documentación del Desarrollo y Manejo del Sistema debe entregarse en un formato de fácil lectura y de compresión sencilla para el usuario pueda consultarlos en línea.
Requerimientos Externos:
El sistema debe tener conectividad con los sistemas externos de control de tarjetas de crédito para validar la información del usuario en línea.
6.10 Ha obtenido un trabajo con un usuario de software quien ha contratado a su anterior compañía para desarrollar un sistema. Usted descubre que la interpretación de su compañía actual de requerimientos es diferente de la tomada por su anterior compañía. Comente que haría en tal situación. Usted sabe que los costes de su compañía actual se incrementaran si las ambigüedades no se resuelven. También tiene una responsabilidad de confidencialidad para su anterior compañía.
R-/ Pues lo que haría es evaluar la experiencia con mi compañía anterior de desarrollo que esta mas empapada de los requerimientos que exige como usuario y la experiencia de implementación de la misma para tratar de transmitir estos requerimientos a la compañía de desarrollo nueva y así llegar a la unificación de requerimientos sin ambigüedades
jueves, 1 de julio de 2010
Ejercicios del Capítulo 5
5.1 ¿Explique porque la intangibilidad de los sistemas de software plantea problemas para la gestión de proyectos de software.
R-/ Porque no se puede ver ni tocar, los gestores de proyectos no pueden ver el progreso, confían en otros para elaborar la documentación necesaria para revisar el progrreso.
5.2 Explique porque los mejores programadores no siempre son los mejores gestores de software. La respuesta puede tener como base la lista de actividades de gestión dadas en la sección 5.1.
R-/ Porque los gestores de software debe tener la capacidad y experiencia para crear y validar los planes de desarrollo de software y para ello deberían tener experiencia de cada una de esas labores, por lo tanto es bien difícil que un programador se involucre en todas esas labores a menos que ya tenga un buen tiempo de interactuar en diferentes áreas del proceso de desarrollo de software.
5.3Explique porque el proceso de planificación de proyectos es iterativo y porque un plan se debe revisar continuamente durante el proyecto de software.
R-/Es un proceso iterativo porque mientras dure el proyecto se deben repetir como un While: la revisión de la programación, el inicio de las actividades, revisar el progreso, revisar las estimaciones de los parámetros del proyecto, actualizar la programación del proyecto, todo esto se debe repetir hasta que se de por terminado el proyecto. El plan debe revisarse continuamente conforme la información se hace disponible acerca del progreso del proyecto, Mientras las metas globales del negocio cambien en necesario cambios en el proyecto.
5.7 La Figura 5.5 señala la duración de las tareas para las actividades del proyecto de software. Suponga que hay un serio retraso no anticipado y que en lugar de requerir 10 dias, la tarea T5 requiere 40 días. Revise la red de actividades resultante, resaltando el nuevo camino critico. Diseñe un nuevo grafico de barras que muestre como se podría reorganizar el proyecto
R-/
5.9 Además de los riesgos que se muestran en la figura 5.11, identifique otros seis posibles riesgos en los proyectos de software.
R-/ Otros Riesgos Posibles pueden ser:
Renuncia: La Posible renuncia de uno o parte del equipo de trabajo, encargado de el desarrollo del proyecto o de la programación de componentes.
Feriados o Vacaciones: La no inclusión de las vacaciones de los empleados o los días feriados que son derechos laborales de los empleados de la empresa desarrolladora.
Enfermedad: Enfermedades eventuales a los miembros del equipo de desarrollo del software que atrase la continuidad de una tarea.
5.10 Los contratos de precio prefijado, donde el contratista ofrece un precio fijo para completar el sistema, pueden ser utilizados para traspasar los riesgos del proyecto del cliente al contratista. Si algo va mal, el contratista asumirá la diferencia. Indique de qué modo el uso de contratos puede incrementar la probabilidad de aparición de riesgos.
R-/ Pues de tal forma que si los riesgos que aparecen en el transcurso del proyecto de desarrollo, no están estipulados en el contrato, el cliente no está obligado a ser responsable del atraso por los mismos y la espera de ellos. Por lo tanto es necesario consensuar una clausula en la cual se estipule un margen de tiempo mínimo y máximo para poder entregar el proyecto y asi pueda quedar un tiempo prudencial por posibles eventualidades fuera del control de ambas partes.
5.11 Su jefe le ha solicitado que entregue un software en un tiempo que solo puede ser posible cumplir preguntando al equipo del proyecto se desea trabajar horas extras sin pago alguno. Todos los miembros del equipo tienen hijos pequeños. Comente si debería aceptar esta petición de su jefe o si debería persuadir al equipo para dar su tiempo a la organización más que a sus familias. ¿Qué factores podrían ser significativos en la decisión?
R-/ Pues creo que en los casos de los programadores esto no sería muy aceptable, ya que el cansancio y agotamiento mental pueden influir en la velocidad en la que avanza el proyecto. Además los factores familiares, siempre son indispensables atender como primera urgencia más que cualquier otra cosa. En mi caso personal no aceptaría esta petición de forma continua sino de forma alternada y platicada con el equipo para programar a voluntad que todos se puedan quedar ciertos días en tiempo extra sin pago alguno pero con incentivos como la comida y el transporte.
5.12 Como programador, se le ofrece un ascenso como gestor de proyecto, pero su sensación es que puede tener una contribución más efectiva en un papel técnico que en uno administrativo. Comente cuando debería aceptar ese ascenso.
R-/ Creo que si como técnico he desarrollado varios proyectos de desarrollo, sería aceptable tomar el ascenso ya que si estoy bien empapado de la labor técnica es posible aprender lo necesario a la gestión del proyecto siempre y cuando se dé un tiempo de prueba para poder entender cuáles son las responsabilidades de mi puesto.
R-/ Porque no se puede ver ni tocar, los gestores de proyectos no pueden ver el progreso, confían en otros para elaborar la documentación necesaria para revisar el progrreso.
5.2 Explique porque los mejores programadores no siempre son los mejores gestores de software. La respuesta puede tener como base la lista de actividades de gestión dadas en la sección 5.1.
R-/ Porque los gestores de software debe tener la capacidad y experiencia para crear y validar los planes de desarrollo de software y para ello deberían tener experiencia de cada una de esas labores, por lo tanto es bien difícil que un programador se involucre en todas esas labores a menos que ya tenga un buen tiempo de interactuar en diferentes áreas del proceso de desarrollo de software.
5.3Explique porque el proceso de planificación de proyectos es iterativo y porque un plan se debe revisar continuamente durante el proyecto de software.
R-/Es un proceso iterativo porque mientras dure el proyecto se deben repetir como un While: la revisión de la programación, el inicio de las actividades, revisar el progreso, revisar las estimaciones de los parámetros del proyecto, actualizar la programación del proyecto, todo esto se debe repetir hasta que se de por terminado el proyecto. El plan debe revisarse continuamente conforme la información se hace disponible acerca del progreso del proyecto, Mientras las metas globales del negocio cambien en necesario cambios en el proyecto.
5.7 La Figura 5.5 señala la duración de las tareas para las actividades del proyecto de software. Suponga que hay un serio retraso no anticipado y que en lugar de requerir 10 dias, la tarea T5 requiere 40 días. Revise la red de actividades resultante, resaltando el nuevo camino critico. Diseñe un nuevo grafico de barras que muestre como se podría reorganizar el proyecto
R-/
5.9 Además de los riesgos que se muestran en la figura 5.11, identifique otros seis posibles riesgos en los proyectos de software.
R-/ Otros Riesgos Posibles pueden ser:
Renuncia: La Posible renuncia de uno o parte del equipo de trabajo, encargado de el desarrollo del proyecto o de la programación de componentes.
Feriados o Vacaciones: La no inclusión de las vacaciones de los empleados o los días feriados que son derechos laborales de los empleados de la empresa desarrolladora.
Enfermedad: Enfermedades eventuales a los miembros del equipo de desarrollo del software que atrase la continuidad de una tarea.
5.10 Los contratos de precio prefijado, donde el contratista ofrece un precio fijo para completar el sistema, pueden ser utilizados para traspasar los riesgos del proyecto del cliente al contratista. Si algo va mal, el contratista asumirá la diferencia. Indique de qué modo el uso de contratos puede incrementar la probabilidad de aparición de riesgos.
R-/ Pues de tal forma que si los riesgos que aparecen en el transcurso del proyecto de desarrollo, no están estipulados en el contrato, el cliente no está obligado a ser responsable del atraso por los mismos y la espera de ellos. Por lo tanto es necesario consensuar una clausula en la cual se estipule un margen de tiempo mínimo y máximo para poder entregar el proyecto y asi pueda quedar un tiempo prudencial por posibles eventualidades fuera del control de ambas partes.
5.11 Su jefe le ha solicitado que entregue un software en un tiempo que solo puede ser posible cumplir preguntando al equipo del proyecto se desea trabajar horas extras sin pago alguno. Todos los miembros del equipo tienen hijos pequeños. Comente si debería aceptar esta petición de su jefe o si debería persuadir al equipo para dar su tiempo a la organización más que a sus familias. ¿Qué factores podrían ser significativos en la decisión?
R-/ Pues creo que en los casos de los programadores esto no sería muy aceptable, ya que el cansancio y agotamiento mental pueden influir en la velocidad en la que avanza el proyecto. Además los factores familiares, siempre son indispensables atender como primera urgencia más que cualquier otra cosa. En mi caso personal no aceptaría esta petición de forma continua sino de forma alternada y platicada con el equipo para programar a voluntad que todos se puedan quedar ciertos días en tiempo extra sin pago alguno pero con incentivos como la comida y el transporte.
5.12 Como programador, se le ofrece un ascenso como gestor de proyecto, pero su sensación es que puede tener una contribución más efectiva en un papel técnico que en uno administrativo. Comente cuando debería aceptar ese ascenso.
R-/ Creo que si como técnico he desarrollado varios proyectos de desarrollo, sería aceptable tomar el ascenso ya que si estoy bien empapado de la labor técnica es posible aprender lo necesario a la gestión del proyecto siempre y cuando se dé un tiempo de prueba para poder entender cuáles son las responsabilidades de mi puesto.
martes, 8 de junio de 2010
Tareas Asignadas en Proycto UTH-Vitual GRUPO CALIF
Estas son las labores asignadas a los integantes de nuestro grupo(CALIF)
Integrantes del Grupo (CALIF):
Fausto A. Morazan (Coordinador)
Lenin Ricardo Pineda
Jeffry Zelaya
Jean Carlo Molinero
SITUACION ACTUAL DEL CLIENTE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En este punto estaremos realizando un estudio completo de los servicios actuales que ofrece la universidad y así mismo se describirá cuales de estos servicios se ofrecen de forma virtual y cuáles no. También se realizara un estudio de las necesidades actuales y la manera de realizar más eficientemente tales operaciones a través de la ayuda de una solución virtual.
Este estudio comprende también la investigación de equipo actual con el que se cuenta para desarrollar la propuesta, software actual y necesidades de inversión, así como investigación de la infraestructura actual para ver si existe la necesidad de realizar alguna inversión para el desarrollo de la propuesta en cada una de las áreas.
HISTORIA DEL SOFTWARE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En esta sección se realizara una investigación del software actual con el que cuenta actualmente la institución así como la tecnología de información que se tiene para realizar las interfaces necesarias para el acceso de UTH Virtual
DISEÑO DE LA PROPUESTA
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
De acuerdo a la revisión de la situación actual del cliente y realizando una revisión de lo que existe y lo que no, la Propuesta UTH-Virtual tendrá las siguientes áreas de acceso específico de acuerdo a la necesidad de cada usuario.
TIEMPO ESTIMADO DE DESARROLLO
El Desarrollo de tal propuesta se realizara en base al siguiente cronograma:
1. Investigación sobre la Información a Publicar
ASIGANDO AL INTEGRANTE (JEAN CARLO MOLINERO)
2. Investigación sobre Servicios Actuales (Lenin Pineda)
ASIGANDO AL INTEGRANTE (LENIN PINEDA)
3. Diseño de Pantallas Finales que serán desarrolladas para cada una de las propuestas finales en el desarrollo de la la Propuesta.
ASIGANDO A LOS INTEGRANTES (LENIN PINEDA Y JEAN CARLO MOLNERO)
4. Diseño de Propuesta Final
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
Integrantes del Grupo (CALIF):
Fausto A. Morazan (Coordinador)
Lenin Ricardo Pineda
Jeffry Zelaya
Jean Carlo Molinero
SITUACION ACTUAL DEL CLIENTE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En este punto estaremos realizando un estudio completo de los servicios actuales que ofrece la universidad y así mismo se describirá cuales de estos servicios se ofrecen de forma virtual y cuáles no. También se realizara un estudio de las necesidades actuales y la manera de realizar más eficientemente tales operaciones a través de la ayuda de una solución virtual.
Este estudio comprende también la investigación de equipo actual con el que se cuenta para desarrollar la propuesta, software actual y necesidades de inversión, así como investigación de la infraestructura actual para ver si existe la necesidad de realizar alguna inversión para el desarrollo de la propuesta en cada una de las áreas.
HISTORIA DEL SOFTWARE
ASIGANDO AL INTEGRANTE (JEFFRY ZELAYA)
En esta sección se realizara una investigación del software actual con el que cuenta actualmente la institución así como la tecnología de información que se tiene para realizar las interfaces necesarias para el acceso de UTH Virtual
DISEÑO DE LA PROPUESTA
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
De acuerdo a la revisión de la situación actual del cliente y realizando una revisión de lo que existe y lo que no, la Propuesta UTH-Virtual tendrá las siguientes áreas de acceso específico de acuerdo a la necesidad de cada usuario.
TIEMPO ESTIMADO DE DESARROLLO
El Desarrollo de tal propuesta se realizara en base al siguiente cronograma:
1. Investigación sobre la Información a Publicar
ASIGANDO AL INTEGRANTE (JEAN CARLO MOLINERO)
2. Investigación sobre Servicios Actuales (Lenin Pineda)
ASIGANDO AL INTEGRANTE (LENIN PINEDA)
3. Diseño de Pantallas Finales que serán desarrolladas para cada una de las propuestas finales en el desarrollo de la la Propuesta.
ASIGANDO A LOS INTEGRANTES (LENIN PINEDA Y JEAN CARLO MOLNERO)
4. Diseño de Propuesta Final
ASIGANDO AL INTEGRANTE (FAUSTO MORAZAN)
Ejercicios del Capitulo 1
1.2 ¿Cuáles son las diferencias entre el desarrollo de un producto de software genérico y el desarrollo de un software personalizados.
R-/ Los productos genéricos son sistemas producidos por una organización de desarrollo y que su operación particular cumple con los requerimientos de varios clientes . Mientras que los productos personalizados son sistemas desarrollados por un contratista de software para requerimientos particulares de un cliente especifico .
1.3 ¿Cuáles son los cuatro atributos importantes que todos los productos de software deben tener? Sugiera otros cuatro atributos que puedan ser significativos.
R-/ Mantenibilidad, Confiabilidad, Eficiencia, Usabilidad
Otros atributos que debería tener son:
Multiplataforma: Que pueda correr en cualquier Sistema Operativo
Documentación: Que tenga Manuales de usuario para su uso.
Dinámico: Que pueda interactuar fácilmente con el usuario
Conectividad: Que pueda conectarse con otras Herramientas para ayuda de gestión y consulta de reportes
1.4 ¿Cuál es la diferencia entre un modelo del proceso del software y un proceso del software? Sugiera dos formas en las que un modelo del proceso del software ayuda en la identificación de posibles mejoras del proceso.
R-/ Un modelo de procesos del software es una descripción simplificada de un proceso del software que presenta una visión de ese proceso, mientras que el proceso de software son las actividades y resultados asociados que producen un producto de software.
1.5 Explique porque los costos de prueba de software son particularmente altos para productos de software genéricos que se venden en un mercado amplio.
R-/ Debido a que se pretenden utilizar en diferentes configuraciones, deben ser probados a fondo y por lo tanto necesitan más tiempo de prueba.
1.8 Comente si los ingenieros profesionales deben atestiguar de la misma forma que los doctores o los abogados.
R-/Si claro se debe respetar la confidencialidad de los clientes independientemente que se haya pactado en un contrato o no ya que es parte de una ética profesional, igual como lo hacen los abogados y los doctores con sus clientes. Esta debe ser una relación de confianza y respeto mutuo
R-/ Los productos genéricos son sistemas producidos por una organización de desarrollo y que su operación particular cumple con los requerimientos de varios clientes . Mientras que los productos personalizados son sistemas desarrollados por un contratista de software para requerimientos particulares de un cliente especifico .
1.3 ¿Cuáles son los cuatro atributos importantes que todos los productos de software deben tener? Sugiera otros cuatro atributos que puedan ser significativos.
R-/ Mantenibilidad, Confiabilidad, Eficiencia, Usabilidad
Otros atributos que debería tener son:
Multiplataforma: Que pueda correr en cualquier Sistema Operativo
Documentación: Que tenga Manuales de usuario para su uso.
Dinámico: Que pueda interactuar fácilmente con el usuario
Conectividad: Que pueda conectarse con otras Herramientas para ayuda de gestión y consulta de reportes
1.4 ¿Cuál es la diferencia entre un modelo del proceso del software y un proceso del software? Sugiera dos formas en las que un modelo del proceso del software ayuda en la identificación de posibles mejoras del proceso.
R-/ Un modelo de procesos del software es una descripción simplificada de un proceso del software que presenta una visión de ese proceso, mientras que el proceso de software son las actividades y resultados asociados que producen un producto de software.
1.5 Explique porque los costos de prueba de software son particularmente altos para productos de software genéricos que se venden en un mercado amplio.
R-/ Debido a que se pretenden utilizar en diferentes configuraciones, deben ser probados a fondo y por lo tanto necesitan más tiempo de prueba.
1.8 Comente si los ingenieros profesionales deben atestiguar de la misma forma que los doctores o los abogados.
R-/Si claro se debe respetar la confidencialidad de los clientes independientemente que se haya pactado en un contrato o no ya que es parte de una ética profesional, igual como lo hacen los abogados y los doctores con sus clientes. Esta debe ser una relación de confianza y respeto mutuo
Herramientas CASE
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.
Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
Clasificación de las Herramientas Case
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior), orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior), dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de Herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
Ejemplos de Herramientas Case más utilizadas.
ERwin:
ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidad _ relación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.
ERwin soporta principalmente bases de datos relacionales SQL y bases de datos que incluyen Oracle, Microsoft SQL Server, Sybase. El mismo modelo puede ser usado para generar múltiples bases de datos, o convertir una aplicación de una plataforma de base de datos a otra.
EasyCASE
EasyCASE Profesional, una herramienta multi-usuario, es ideal para aquellos que necesitan compartir datos y trabajar en un proyecto con otros departamentos. El equipo completo puede acceder proyectos localizados en el servidor de la red concurrentemente. Para asegurar la seguridad de los datos, existe el diagrama y diccionario de los datos que bloquean por niveles al registro, al archivo y al proyecto, y niveles de control de acceso.
Oracle Designer:
Oracle Designer es un conjunto de herramientas para guardar las definiciones que necesita el usuario y automatizar la construcción rápida de aplicaciones cliente/servidor gráficas. Integrado con Oracle Developer, Oracle Designer, que provee una solución para desarrollar sistemas empresariales de segunda generación.
System Architect
Esta herramienta posee un repositorio único que integra todas las herramientas, y metodologías usadas. En la elaboración de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos asociados, comentarios, reglas de validaciones, normalización, etc.
Posee control automático de diagramas y datos, normalizaciones y balanceamiento entre diagramas "Padre e Hijo", además de balanceamiento horizontal, que trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo Funcional.
Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
Clasificación de las Herramientas Case
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior), orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior), dirigidas a las últimas fases del desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más simple de Herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.
Ejemplos de Herramientas Case más utilizadas.
ERwin:
ERwin hace fácil el diseño de una base de datos. Los diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del modelo E-R (Entidad _ relación) de todos sus requerimientos de datos y capturar las reglas de negocio en un modelo lógico, mostrando todas las entidades, atributos, relaciones, y llaves importantes.
ERwin soporta principalmente bases de datos relacionales SQL y bases de datos que incluyen Oracle, Microsoft SQL Server, Sybase. El mismo modelo puede ser usado para generar múltiples bases de datos, o convertir una aplicación de una plataforma de base de datos a otra.
EasyCASE
EasyCASE Profesional, una herramienta multi-usuario, es ideal para aquellos que necesitan compartir datos y trabajar en un proyecto con otros departamentos. El equipo completo puede acceder proyectos localizados en el servidor de la red concurrentemente. Para asegurar la seguridad de los datos, existe el diagrama y diccionario de los datos que bloquean por niveles al registro, al archivo y al proyecto, y niveles de control de acceso.
Oracle Designer:
Oracle Designer es un conjunto de herramientas para guardar las definiciones que necesita el usuario y automatizar la construcción rápida de aplicaciones cliente/servidor gráficas. Integrado con Oracle Developer, Oracle Designer, que provee una solución para desarrollar sistemas empresariales de segunda generación.
System Architect
Esta herramienta posee un repositorio único que integra todas las herramientas, y metodologías usadas. En la elaboración de los diagramas, el System Architect conecta directamente al diccionario de datos, los elementos asociados, comentarios, reglas de validaciones, normalización, etc.
Posee control automático de diagramas y datos, normalizaciones y balanceamiento entre diagramas "Padre e Hijo", además de balanceamiento horizontal, que trabaja integrado con el diccionario de datos, asegurando la compatibilidad entre el Modelo de Datos y el Modelo Funcional.
jueves, 3 de junio de 2010
Ejercicios del Capitulo 2
2.4 Explique porque es importante presentar una descripción completa de una arquitectura del sistema en una etapa inicial del proceso de especificación del Sistema.
R-/Porque la fase de definición de requerimientos es establecer un conjunto competo de objetivos que el sistema debe cumplir, y si esta no se muestra en un contexto general es posible que se tenga que retroceder para realizar cambios los cuales implican tiempo de atraso y costo monetario.
2.5 Considere un sistema de seguridad que es una versión extendida del sistema mostrado en la Figura 2.6, que está pensado para proteger contra la intrusión y para detectar fuego. Contiene sensores de humo, de movimiento y de puerta, videocámaras controladas por computadora, que se encuentran en varios lugares del edificio, una consola de operación donde se informa del estado del sistema, y facilidad de comunicación externa para llamar a los servicios apropiados como la policía y los bomberos. Dibuje un diagrama de bloques de un posible diseño de dicho sistema.
2.8 Explique por qué los sistemas heredados pueden ser críticos en el funcionamiento de un negocio.
R-/ Son Críticos ya que se mantienen porque es demasiado arriesgado reemplazarlos. Esto es si una empresa si un sistema depende de otro y se pretende reemplaza el sistema dependiente podría haber un serio riesgo de negocio si el sistema de recambio no funcionara adecuadamente
2.9 Explique por qué los sistemas heredados pueden causar dificultades para las compañías que desean reorganizar sus procesos de negocio.
R-/ Porque un proceso de negocio que es diseñado alrededor de un sistema heredado , pueden ser restringidos por la funcionalidad que este proporciona
2.10 ¿Cuáles son los argumentos a favor y en contra para considerar que la ingeniería de sistemas es una profesión, como la ingeniería eléctrica o la de software?.
R-/La ingeniería de sistemas es una actividad interdisciplinaria que conjunta equipos de personas con diferentes bases de conocimiento.
Para muchos sistemas existen posibilidades casi infinitas de equilibrio entre los diferentes tipos de subsistemas. Las diferentes disciplinas negocian para decidir que funcionalidad debe proporcionarse.
R-/Porque la fase de definición de requerimientos es establecer un conjunto competo de objetivos que el sistema debe cumplir, y si esta no se muestra en un contexto general es posible que se tenga que retroceder para realizar cambios los cuales implican tiempo de atraso y costo monetario.
2.5 Considere un sistema de seguridad que es una versión extendida del sistema mostrado en la Figura 2.6, que está pensado para proteger contra la intrusión y para detectar fuego. Contiene sensores de humo, de movimiento y de puerta, videocámaras controladas por computadora, que se encuentran en varios lugares del edificio, una consola de operación donde se informa del estado del sistema, y facilidad de comunicación externa para llamar a los servicios apropiados como la policía y los bomberos. Dibuje un diagrama de bloques de un posible diseño de dicho sistema.
2.8 Explique por qué los sistemas heredados pueden ser críticos en el funcionamiento de un negocio.
R-/ Son Críticos ya que se mantienen porque es demasiado arriesgado reemplazarlos. Esto es si una empresa si un sistema depende de otro y se pretende reemplaza el sistema dependiente podría haber un serio riesgo de negocio si el sistema de recambio no funcionara adecuadamente
2.9 Explique por qué los sistemas heredados pueden causar dificultades para las compañías que desean reorganizar sus procesos de negocio.
R-/ Porque un proceso de negocio que es diseñado alrededor de un sistema heredado , pueden ser restringidos por la funcionalidad que este proporciona
2.10 ¿Cuáles son los argumentos a favor y en contra para considerar que la ingeniería de sistemas es una profesión, como la ingeniería eléctrica o la de software?.
R-/La ingeniería de sistemas es una actividad interdisciplinaria que conjunta equipos de personas con diferentes bases de conocimiento.
Para muchos sistemas existen posibilidades casi infinitas de equilibrio entre los diferentes tipos de subsistemas. Las diferentes disciplinas negocian para decidir que funcionalidad debe proporcionarse.
miércoles, 26 de mayo de 2010
Sistemas de Computo Ubiquos
Es la integración de la informática en el entorno de la persona, de forma que los ordenadores no se perciban como objetos extraños. Algunas de las aplicaciones ubicuas son:
e-Medicina
Monitoreo y procesamiento de señales medicas remotas
Context –aware systems
Monitoreo de actividades en ancianos.
Tele-Diagnostico Movil
Computación Ubicua:
La idea de la computación ubicua es de proveer acceso a los ordenadores de forma sencilla y no de la forma tradicional utilizada hoy en día. Es decir, permitir que hagas tu trabajo con la ayuda de los ordenadores sin tener que preocuparse por trabajar con los mismos. Por lo tanto la computación móvil es de fundamental relevancia para el desarrollo de esta nueva tendencia de la computación. La idea es que podremos usar sensores y otros periféricos (cámaras o micrófonos) en vez de las manos.
Una definición formal de “Computación Ubicua” (ubicom): la integración de la informática en el entorno de la persona, de forma que los ordenadores no se perciban como objetos diferenciados. Esta disciplina se conoce en ingles por otros términos como: pervasive-computing, calm technology, things that think y everyware y desde hace unos años se le denomina “Inteligencia Ambiental”.
El objetivo es insertar dispositivos inteligentes tanto en el entorno como en aparatos de uso diario para que las personas puedan interactuar con ellos de una manera natural y desinhibida en todo tipo de situaciones y circunstancias.
e-Medicina
Monitoreo y procesamiento de señales medicas remotas
Context –aware systems
Monitoreo de actividades en ancianos.
Tele-Diagnostico Movil
Computación Ubicua:
La idea de la computación ubicua es de proveer acceso a los ordenadores de forma sencilla y no de la forma tradicional utilizada hoy en día. Es decir, permitir que hagas tu trabajo con la ayuda de los ordenadores sin tener que preocuparse por trabajar con los mismos. Por lo tanto la computación móvil es de fundamental relevancia para el desarrollo de esta nueva tendencia de la computación. La idea es que podremos usar sensores y otros periféricos (cámaras o micrófonos) en vez de las manos.
Una definición formal de “Computación Ubicua” (ubicom): la integración de la informática en el entorno de la persona, de forma que los ordenadores no se perciban como objetos diferenciados. Esta disciplina se conoce en ingles por otros términos como: pervasive-computing, calm technology, things that think y everyware y desde hace unos años se le denomina “Inteligencia Ambiental”.
El objetivo es insertar dispositivos inteligentes tanto en el entorno como en aparatos de uso diario para que las personas puedan interactuar con ellos de una manera natural y desinhibida en todo tipo de situaciones y circunstancias.
Wearable Computing Systems
Este término se deriva de “Wearable Computers” o Computadoras usables, son computadoras que se usan en el cuerpo. O sea son computadoras portátiles de diseños compactos para ser adaptadas a las necesidades de los usuarios y de manera discreta e invisible para los demás, es decir para ser usadas en ropa, relojes, joyas, etc. Una de las Características de estos equipos es la consistencia, es decir hay una constante interacción entre el ordenador y el usuario, es decir no hay necesidad de encender el dispositivo.
MIT Media Lab es uno de los investigadores clave en el campo de ordenadores portátiles
Uno de los campos primarios utilizando ordenadores llevables o portátiles son los militares, que siempre han sido una organización tecnológica más avanzada. Por ejemplo muchos soldados utilizan dispositivos adaptados al cuerpo para monitorear ellos mismos y sobre el terreno como ordenadores portátiles usados como PC de muñeca y de armadura completa así como visores adaptados para el ojo, etc.
El término “Wearable Computing Systems” o Sistemas de Computación Usable, son aplicaciones de computación portátil, es decir para equipos portátiles de diseños compactos, son sistemas diseñados para estos equipos usables cuya utilidad es para el usuario final es decir donde el usuario va, ya sea la oficina, la casa, el banco, etc.
MIT Media Lab es uno de los investigadores clave en el campo de ordenadores portátiles
Uno de los campos primarios utilizando ordenadores llevables o portátiles son los militares, que siempre han sido una organización tecnológica más avanzada. Por ejemplo muchos soldados utilizan dispositivos adaptados al cuerpo para monitorear ellos mismos y sobre el terreno como ordenadores portátiles usados como PC de muñeca y de armadura completa así como visores adaptados para el ojo, etc.
El término “Wearable Computing Systems” o Sistemas de Computación Usable, son aplicaciones de computación portátil, es decir para equipos portátiles de diseños compactos, son sistemas diseñados para estos equipos usables cuya utilidad es para el usuario final es decir donde el usuario va, ya sea la oficina, la casa, el banco, etc.
Objetivos Personales de la Clase
Saludos
Me parece muy buena la idea de crear estos blogs y poder comentar sobre la clase y los avances de la misma. Es una manera de sacar el maximo provecho a las herramientas que tenemos como profesionales de Sistemas.
De manera personal los objetivos de esta clase es aprender las tecnicas necesarias para poder presentar una propuesta de desarrollo de Sistema como profesional e Ingenierio en Sistemas.
He recibido cursos de Programacion y Metodologias de Diseño de Modelos Entidad Relacion y espero que esto me ayude mas a afinar el concepto de Diseño y Desarrollo de Sistemas.
Gracias al Catedratico por permitir exponer nuestras ideas
Me parece muy buena la idea de crear estos blogs y poder comentar sobre la clase y los avances de la misma. Es una manera de sacar el maximo provecho a las herramientas que tenemos como profesionales de Sistemas.
De manera personal los objetivos de esta clase es aprender las tecnicas necesarias para poder presentar una propuesta de desarrollo de Sistema como profesional e Ingenierio en Sistemas.
He recibido cursos de Programacion y Metodologias de Diseño de Modelos Entidad Relacion y espero que esto me ayude mas a afinar el concepto de Diseño y Desarrollo de Sistemas.
Gracias al Catedratico por permitir exponer nuestras ideas
Suscribirse a:
Entradas (Atom)
