MARTES20 PREPREPREENTREGA

November 20, 2007

MARTES13

November 13, 2007

SISTEMA COLGANTE LIGERO

November 6, 2007

SW3: FRIM / feria de Software 2007 UTFSM

November 2, 2007

FRIM / Frequently Required Information Module

DESCRIPCIÓN BREVE DEL PROBLEMA
Información repartida por toda la Universidad

Gran cantidad de información en los ficheros públicos

La información no está disponible si no se está en la Universidad o no se tiene acceso a Internet.

Gastos en tiempo y recursos en lapublicación de noticias.

REQUERIMIENTOS
FUNCIONALES PROPIOS DE LA APLICACIÓN
–Acceder a información a través interfaz GUI tipo fichero/panel.
–Ingresar información a través de interfaz Web.
–Mantener información en la base de datos de acuerdo a la fecha.
–Autentificar usuario mediante tecnología inalámbrica y/o login.
–Descargar información mediante tecnologías portátiles.
–Proveer acceso mediante mensajería de texto (SMS).
FUNCIONALES GENÉRICOS
–Control de acceso personalizado a usuarios.
–Mantenedor de una Base de datos.
FUNCIONAL DISTINTIVO
–Mezcla de tecnologías: Touchscreen, Bluetooth y SMS.
NO FUNCIONALES DISTINTIVOS DE LA APLICACIÓN
–Interfaz atrayente e intuitiva: ¾ de las personas que necesiten de información usarán el servicio.
–Tiempo de respuesta menor o igual a 2 segundos.

MODELOS

CASO DE USO

frim_caso-de-uso.jpg

MODELO CONCEPTUAL

frim_modelo-conceptual.jpg

SOLUCION RECOMENDADA

frim_solucion-recomendada.jpg


SW2: ALNUS / feria de Software 2007 UTFSM

November 2, 2007

ALNUS


DESCRIPCIÓN BREVE DEL PROBLEMA
Un grave problema en las aulas chilenas de la actualidad es la poca interacción, análisis y corrección de las actividades realizadas por los alumnos en el mismo horario de clases. Esta situación impide que ellos puedan aprender tanto de sus errores, como de los de sus compañeros, mediante la corrección efectuada por su profesor. De esta forma los computadores que tienen los liceos chilenos no son utilizados de una manera que sea útil para el aprendizaje, y terminan siendo usados en labores más bien administrativas o como buscadores de información para los alumnos. O sea, existe tecnología pero esta no ha podido ser utilizada para apoyar el proceso de aprendizaje sobre todo dentro de la sala de clases.

Los cambios que se esperan lograr a la situación actual en la sala de clases es permitir una interacción mucha más fluida entre el profesor y el alumno. Se trata de hacer que éste aproveche el tiempo que se encuentra en la sala para aprender lo máximo posible de los conocimientos que tiene su profesor. Alnus permitirá a sus alumnos ver y resolver en pantalla una actividad, almacenando su desarrollo para una posible corrección instantánea por parte del profesor. Además, el alumno podrá acceder a su trabajo o a las exposiciones del profesor cuando lo estime conveniente vía web.

REQUERIMIENTOS
FUNCIONALES PROPIOS DE LA APLICACIÓN

–Administrar preguntas y actividades, con sus respectivas fuentes de información y su asociación basada en las respuestas.
–Almacenar los desarrollos de los alumnos ingresados mediante tableta digitalizadora.
–Generar evaluaciones en base a preguntas almacenadas en la base de datos.
–Corrección automática de evaluaciones y facilidades para la corrección manual.
–Personalizar las fuentes de información disponibles para actividades según modalidades de trabajo.
–Permitir el acceso a los resultados de las actividades en forma remota, a través de Internet.
FUNCIONALES GENERICOS
–Control de acceso y funcionalidades basados en los roles de usuario (profesor y alumno).
–Informes históricos de evaluaciones, actividades y desarrollos del alumno.
FUNCIONAL DISTINTIVO

–Coordinar despliegue en tiempo real de datos ingresados mediante las tabletas digitalizadoras.
NO FUNCIONALES DISTINTIVOS DE LA APLICACIÓN
–Tiempo de respuesta <= 5 segundos en la sincronización de los datos ingresados por tableta.
–Funcionamiento en 90% de los navegadores del mercado.

MODELOS
Tablas integradas para la base de datos

alnus_tablas0.jpgalnus_tablas1.jpgalnus_tablas2.jpg

DIAGRAMA ENTIDAD-RELACION

alnus_entidad-relacion.jpg

VISTAS

alnus_vistas.jpg


SW1: SAV / feria de Software 2007 UTFSM

November 2, 2007

SAV/Sabor Audio Visual

DESCRIPCIÓN BREVE DEL PROBLEMA
El problema surge al no existir una herramienta audiovisual de apoyo, en tiempo real, al aprendizaje gastronómico que sea lo suficientemente atractiva y poderosa, para aprovechar todos los medios audiovisuales existentes. El no ser una simple receta para leer donde no se explican los detalles, ni tampoco un programa de televisión en donde se está atado a horarios y requerimientos de ingredientes.

REQUERIMIENTOS
FUNCIONALES PROPIOS DE LA APLICACIÓN

–Construir un generador automatizado de presentaciones para recetas.
–Permitir la creación de comunidades virtuales.
–Implementación de filtros múltiples de búsqueda.
–Presentación de la receta en formato imprimible.
–Desplegar información de los ingredientes (composición e información nutricional).
–Generar estadísticas con las posibles recetas a realizar, en base a una cierta cantidad de ingredientes ingresados por el usuario.
FUNCIONAL DISTINTIVO
–Implementación de un reloj multialarma.
FUNCIONALES GENÉRICOS
–Generar perfiles diferenciados de usuarios.
–Generar estadísticas sobre las preferencias de los usuarios.
NO FUNCIONALES DISTINTIVOS DE LA APLICACIÓN
–Proveer de una interfaz atractiva y de fácil uso por parte de sus usuarios finales.
–Facilidad de instalación.

MODELOS

MODELO CONCEPTUAL
Pretende sistematizar los conceptos del dominio del problema, es decir, aquellas entidades y relaciones que son significativas para la comprensión del problema. También sirve para limitar el alcance del problema y definir bien las fronteras de lo que debemos realizar.

modelo conceptual

MODELO DE DATOS
Se describen las tablas que representan las distintas entidades que pertenecen al dominio del problema y serán almacenadas en la base de datos. Este modelo de datos representa sólo la información que se maneja en el portal web, puesto que el software de escritorio no requiere de base de datos.

sav_modelo-datos.jpg

 

MODELO DE CLASES
Se describen las clases del dominio del problema que se implementan en el software de escritorio, cabe destacar que se excluyen las clases de soporte como por ejemplo, las clases que implementan la interfaz gráfica (ventanas, formulario, controles, etc.); esto es porque las clases de soporte, pueden ir cambiando a medida que cambia la presentación, lo que interesa es capturar bien el dominio del problema.

sav_modelo-clases.jpg

 

VISTAS

sav_portal.jpgsav_escritorio.jpg

 


estructura del curso/ “guia” de desarrollo del software

November 2, 2007
. REQUERIMIENTOS
                    LISTA DE REQUERIMIENTOS
                                    – R. Funcionales propios de la App.
                                    - R. Funcionales distintivos
                                    - R. Funcionales genéricos
                                    - R. No funcionales distintivos de la App.
                    ESPECIFICACION PRELIMINAR DEL SW
                     PRESENTACION DEL CLIENTE/USUARIO
. RIESGOS
                    TIPO DE RIESGOS
                    RIESGOS PRINCIPALES
                    MEDIDAS DE MITIGACION
                                    - Casos de uso
                                    - Diagramas de secuencia
                                    - Modelo conceptual
                                    - Prototipo
. MODELOS
                     CASOS DE USO
                                    - Curso normal de eventos
                                    - Cursos alternativos
                                    - Visualización
                                    - Estructura de Tabla a ingresar en base de datos
                     DEFINICION DETALLADA DE TABLAS
                     DIAGRAMA ENTIDAD-RELACION
. PROYECTO
                    SOLUCION CONCEPTUAL
                                    - Situación actual
                                    - Caracterización del cambio
                                    - Potencialidades deseadas
                                    - Restricciones
                                                    Tecnológicas
                                                    Económicas
                                                    Culturales
                                                    Legales
                                                    Institucionales
                                    - Análisis de alternativas
                                    - Solución recomendada
                     TECNICAS Y HERRAMIENTAS
                                     - Modelo de desarrollo
                                     - Herramientas y técnicas de soporte para el desarrollo
                                     - Personal y capacitación del grupo de desarrollo
                    GESTION DE RIESGOS
                    IMPLEMENTACION (ENTREGA Y OPERACIÓN)
                    PLANIFICACION DE ACTIVIDADES

charlas_para_monos.wav

October 23, 2007

aca estan los links de descarga de las charlas realizadas durante el semestre… aer si nos inspiran o nos cachetean los coagulos mentales una vez mas. (espero se pueda escuchar bien)

 

 

GLARIA
CASTRO (este tiene problemas, no lo puedo subir… Castro tenia que ser, jaja lo actualizare cuando este listo)

 

 

 

 

++ un regalo de google books, la version online de ME++, de William J. Mitchel (MIT Press, 2004)
creo que ninguno de nosotros podrá leerlo pronto, pero en favoritos se guardará bien.

si alguien lo lee… me lo cuenta

 

Vos Nemos

NEMO


…going surface

October 13, 2007

la idea era exportar desde arcview una malla en dxf y de esta forma fuera exportable a diferentes formatos pero, hasta ahora solo puedo tirar las curvas de nivel (cosa que era imposible con el plano original) de todas maneras, igual sirve pa tener una visualizacion del terreno en su totalidad desde playa ancha hasta laguna verde… estoy viendo la forma de pasar las curvas a poligonos sin que pierdan la elevacion (siempre hay formas de no perder el welooo….)

Ahora estan en *.wire (StudioTools12)

TERRENO // el unico layer con info en Z+ (Y+ pa que entienda el gore), con escala y norte

CAMINO PRINCIPAL

CAMINO SECUNDARIO

SENDERO

HUELLA

CONSTRUCCIONES // de playa ancha, laguna verde y algunas que aparecen dentro del parque, no se si son importantes

DRENAJES // tal vez aporten info sobre pendientes o evacuacion de aguas

cada uno en un archivo diferente todos agrupados y con pivote en (0,0,0)
asi uds. pueden bajar solo los que estimen necesarios y combinarlos (todos calzan en TOP VIEW)

aun queda pendiente la generacion de una superficie mas encachá, a ver si alguien se motiva, nos serviria a todos.

nos vemos :/

whistler1.jpg


William Gibson

August 14, 2007

Acá van dos textos que tienen relación con los temas que tratamos el dia viernes10

Neuromancer de 1984 (el texto que nos habló L.F, obra emblemática del Ciberpunk) donde W. Gibson desarrolla el termino Ciberespacio, que fue utilizado e inventado por él mismo en un cuento anterior llamado Burnin Chrome de 1982.
W.G – Neuromancer

y otro texo, al parecer, es un capitulo (5) de “Entre Blade Runner y Mickey Mouse“, tesis doctoral de José Pérez de Lama, Profesor Asociado del Departamento de Historia, Teoría y Composición Arquitectónicas, de la Universidad de Sevilla.
05 – Haciendo Rizoma con William Gibson

No lo he leido completo aún, pero hasta ahora… hace un analisis de la obra completa de W.G y la importancia de la literatura de “ciencia-ficcion” y el mundo hyperreal como forma o medio de generar/comprender nuevas emergencias.

aqui va el link con la tesis completa

Entre Blade Runner y Mickey Mouse
nuevas condiciones urbanas, una perspectiva desde Los Angeles, CA.

otro
Curso rápido de Ciberpunk para impostores

cyberpunk_symphony.jpg