Este blog corresponde a la materia Proyecto Final de la Escuela Tecnica Ort al grupo tutoreado por la Profesora Lic. Silvia Herzovich
lunes, 30 de mayo de 2011
Sólo para juegos
Además, cuando vayan a la charla de XNA tienen que hacer un post sobre qué aprendieron.
Bitácora
En las breves descripciones cambiar la terminología muy técnica por otra más entendible por un usuario.
Está programando.
Le falta la propuesta, ya que no tiene usuario le propuse hacerla como para un potencial inversor que pueda producir el juego a gran escala.
Bitácora
Diagrama de clases agregar items de pedido y ver las relaciones entre clases.
Bitácora
Informe de relevamiento agregar en los requerimientos funcionales lo que te pidieron específicamente (el himno, canciones en español, etc.)
Bitácora
Terminar todo lo necesario para aprobar el trimestre.
Bitácora
Falta incluir cobranza, ver si existe un pedido previo a la venta.
Subir los requisitos al blog SIN scribd.
Reformular los módulos de la propuesta y aclarar qué hace y cuál es el beneficio.
Describir en detalle y hacer interfases de: Fabricación, Venta y Cobranza.
Bitácora
Diagrama de clases: Ver de plantearlo en la charla de XNA.
Separar los diagramas en distintas solapas del rational
Bitácora
Subirlo con scribd. Postear los requisitos sin scribd.
En la propuesta se describen los módulos (función y beneficio).
Diagrama de CU separar roles y rehacer
Relevamiento
-Registrar compra
-Emitir factura
-Registrar venta
-Emitir ticket
-Consultar el stock
-Advertir mínimo
-Registrar cambios
-Emitir nota de crédito
-Administrando artículos
-Administrando personal
-Administrando proveedores
-Registrar pagos
-Registrar cheques
-Consultar cuentas corrientes
-Consultar deudas con el personal
-Consultar estadísticas
-Registrar salidas
-Emitir comprobante
Bitácora
Terminar todo lo que se necesita para aprobar el trimestre!!
domingo, 29 de mayo de 2011
Encuesta: preguntas y Resultado
• a) Sí
• b) No.
• c) No, y nunca jugué al ajedrez.
2) Marcá las variantes que jugaste con un tablero físico (hay que usar checkboxes):
• Atómico.
• De Alicia.
• Pasapiezas.
• Cometodo.
• Progresivo.
• Global.
• Alienígena.
• Aleatorio (sea de Fisher o no).
• Gótico.
• Sin jaques.
• Con reloj.
• Hexagonal.
• Arriba abajo.
• Juego de peones.
• Republicano.
3) Marcá las variantes que jugaste en una computadora (hay que usar checkboxes):
• Atómico.
• De Alicia.
• Pasapiezas.
• Cometodo.
• Progresivo.
• Global.
• Alienígena
• Aleatorio (sea de Fisher o no)
• Gótico
• Sin jaques.
• Con reloj.
• Hexagonal.
• Arriba abajo.
• Juego de peones.
• Republicano.
4) ¿Te resulta fácil encontrar un programa que te permita jugar variantes de ajedrez?
• Sí.
• No.
• No me interesa el ajedrez directamente.
5) ¿Cuántos años tenés? (comboBox con edad)
Acá está la encuesta publicada. Los resultados me llegan por e-mail (por ahora no me llega una tabla con un promedio, o todos los resultados)
http://www.jotform.com/form/11483531242
Acà estan los resultados:
https://spreadsheets.google.com/spreadsheet/ccc?key=0AotZLdzjjwqzdFJ3Rm9uMThMeDRrcjFzcFVTaDhFZVE&hl=en_US
Gente que… Cantidad
Juega una variante de ajedrez 66
No juega una variante de ajedrez 52
No juega al ajedrez 43
Le resulta fácil encontrar un programa para jugar al ajedrez 27
No resulta fácil encontrar un programa para jugar al ajedrez 69
Edad promedio de la gente: 27
jueves, 26 de mayo de 2011
Juegos - Charla de XNA
Traigan todas las inquietudes, diagramas de estado, plan de juego y diagrama de clases por si existe la posibilidad de discutir sobre los mismos.
A
Karcevas, Jeniffer
Katz, Milton
Lifshitz, Itai
Lifszyc, Eric
B
Gonzalo, Lomba
Guillermo, Mosse
Mauro, Huayta
C
Blaer, Diego
Gullerian, Ari
Kan, Jonas
Otero, Alejandro
lunes, 23 de mayo de 2011
Bitácora
- Subir al blog con scribd.
Requisitos
- Ver si es necesario incorporar cancelar, anular, etc.
Diagrama de CU
- Analizar el login cómo se relaciona con los demás casos de uso. Es precondición para todos.
- Breve descripción revisar para que digan qué se hace y no cómo se hace.
Propuesta técnica, funcional y la económica subir al blog con scribd.
Bitácora
- No actualizó los procedimientos según lo pedido la clase anterior.
- Ampliar
Requisitos subirlos al blog (sin scribd)
- Agregar requisitos relacionados con cheques (Consulta x fechas, x estado, etc.)
- Revisar y completar
- Agregar Estadísticas.
Diagrama de CU completar y pasar a rational
Propuesta técnica y funcional
- En los módulos marcar la función (qué, NO cómo) y el beneficio.
- Revisar los módulos (Administración, Pagos, Cobranzas, Ventas, Compras, Estadísticas, etc.)
Propuesta económica aclarar el cálculo por módulo (horas de programación, horas de análisis) y el costo por hora de programación y de análisis.
Bitácora
Requisitos
- Los proveedores se administran, no se registran
- Ampliar el tema de cheques (consultas por fechas, estado, etc.)
- Con quien tienen cuenta corriente??
- Donde se administran los artículos??? y los precios???
- Agregar los comprobantes que se emiten.
- Administrar personal y sueldos (no se liquidan). Pensar en todos los requisitos involucrados.
- Agregar los movimientos de caja si lo crees necesario.
- Registrar los adelantos y emitir comprobante.
- Agregar estadísticas!!!! (Vtas x vendedora entre dos fechas, etc.)
- Subir al blog (sin scribd).
Diagrama de CU
- Completar con los nuevos requisitos
- Las breves descripciones estan Bien.
Propuesta técnica y funcional
- Ampliar módulos
Nota : B+
Bitácora
Subir la investigación de diagrama de estado y de actividades al blog.
Hacer encuesta y subirla + los resultados.
Armar propuesta (adaptar estructura a tus necesidades)
Armar diagrama de clases en el mismo proyecto de rational donde tenes el diagrama de estado y el diagrama de CU.
Traer carpeta completa la próxima semana.
Programar!! y llevar la bitácora actualizada con los avances de tu proyecto.
Bitácora
Nota: MB-
- Agregar saltos de página
- Analizar el diagrama de actividad y ver si diseñas uno. Ver información de ayuda del blog del C pf2011c.blogspot.com
- Describir los estados.
- Armar propuesta técnica, funcional y económica.
Hacer el diagrama de clases y programar!!!
Bitácora
- Revisar las acciones involucradas en los cambios de estado.
- Analizar el diagrama de actividad y ver si diseñas uno. Ver información de ayuda del blog del C pf2011c.blogspot.com
Después de la entrevista en Provolo completar informe de relevamiento, requisitos, propuesta, etc.
Hacer el diagrama de clases y empezar a programar!!
Bitácora Ausente
Seguí adelante, recordá que falta poco para cerrar el trimestre.
Bitácora
- Procedimientos actuales: sólo los enuncia, explicar detalladamente cómo se llevan a cabo en la actualidad y qué comprobantes avalan cada procedimiento. Adjuntar comprobantes completos.
- Averiguar la categoría de iva del negocio.
- Averiguar si maneja cheques, listados de iva ventas e iva compras, pagos a proveedores.
Requisitos
- Usar administrar para alta, baja, modificación y consulta.
- Modificar según las correcciones hechas en clase.
- Ampliar con: el manejo de cheques (consultar según fechas y/o estados).
- Agregar emisión de listados de iva.
Diagrama de CU: no lo tiene
Propuesta sigue incompleta.
domingo, 22 de mayo de 2011
Requisitos tecnicos y funcionales
- Registrando ventas
- Realizando pedidos
- Consultando
- Registrando usuarios
- Consultando stock
- Consultando estadísticas
- Administrando catálogos
- Sistema de Log In
Requisitos técnicos
- El sitio se podrá visualizar desde plataformas Windows, Macintosh o alguna otra.
- Aunque es preferible disponer de una conexión de alta velocidad, los usuarios normalmente podrán acceder a la mayor parte de los materiales con conexiones por MODEM como 28.8kbps. No obstante, con estas últimas, se tardará más tiempo en visualizar los materiales.
- Software necesario para visualizar los materiales: Adobe Flash (versión actualizada)
- Para ver los materiales multimedia que contendrá el sitio se recomienda tener alguno de estos programas: QuickTime, Windows Media Player o Real Media Player.
lunes, 16 de mayo de 2011
Bitácora
- Subir al blog con scribd.Requisitos t y f .
- Revisar los funcionales y subir al blog.
- Hacer una breve descripción de cada caso de uso (3 líneas) en Word.
- Dejar la carga inicial a cargo del cliente.
- Nota: MB-
- Discriminar el cálculo por horas de programación y de análisis con el costo por hora.
- Revisar los costos opcionales, plantearlos por hora o digitación en el caso de la carga inicial.
Hacer el diagrama de clases!!
Diseñar las interfaces.
Bitácora
- Los requerimientos priorizarlos.
- Hacer la lista de requisitos.
- Revisar el diagrama de CU según la corrección hecha en clase.
- Ver cómo funcionan las cuentas corrientes (proveedores y/o clientes).
- Buscar nuevos actores (roles).
- Subir al blog una vez corregido. (con scribd)
Propuesta t y f
- Marcar los beneficios de cada módulo. (Qué se hace y en qué lo beneficia al cliente).
- Reforzar los módulos.
- Subirla al blog.
- Nota: MB-
Propuesta económica
- Aclarar por módulo horas de análisis y programación.
- Costo x hora.
- Nota: B
Seguir con las descripciones de detalle y el diseño de las interfaces.
A futuro Diagrama de Clases.
Bitácora
- Investigación del diagrama de estado.
- Decripción de las burbujas del diagrama de estado.
- Investigar el diagrama de actividad y explicar cómo se articula con el de estado.
- Continuar con la programación.
Nota: MB+
Bitácora - Ausente
Espero te mejores!!!.
Mirá las novedades y los requisitos para aprobar el trimestre. Seguí adelante con tu proyecto y nos vemos el próximo lunes.
Saludos,
Silvia
Bitácora
- Separar los procedimientos (compras, pagos, fabricación, venta y cobranza).
- Ver si se pueden ampliar más.
- Requerimientos completar con las palabras del usuario.
- Requisitos muestran las funcionalidad del sistema.
- Diagrama de CU: Corregir según nuevos requisitos.
Propuesta (modificar según pasos anteriores)
Bitácora
- Averiguar si trabajan con nota de crédito.
- Traer una fotocopia de recibo de proveedor.
- Requerimientos funcionales están bien, revisar los técnicos.
- Lista priorizada de requisitos (de los más a los menos importantes).
- Diagrama de Cu. Buscar más actores (roles). Ver si existen extend e include.
- Subir el informe al blog.
- Nota: MB-
Carpeta para proyectos de JUEGOS
Todas las hojas con encabezado (Nombre del Sistema) y pie de página (Alumno, curso, año y número de página)
1. Carátula
1.1. Materia
1.2. Apellido, Nombre
1.3. Curso
1.4. Año
1.5. Usuario / Destinatario (target al que apunta el juego)
1.6. Objetivo
1.7. Profesor
2. Indice
3. INFORME DE RELEVAMIENTO
3.0. Investigación de mercado.
3.1. Entrevista (preguntas y respuestas) / Encuesta (diseño, resultados y análisis)
3.2. Informe
3.2.1. Descripción
3.2.2. Organigrama (Opcional)
3.2.3. Requerimientos Técnicos
3.2.4. Requerimientos Funcionales (priorizados)
3.3. Requisitos
3.3.1. Técnicos
3.3.2. Funcionales (priorizados)
4. PROPUESTA Técnica y Funcional
4.1. Introducción (Resumen)
4.1.1. Principales intereses detectados
4.2. Solución
4.2.1. Propuesta funcional
4.2.2. Descripción de los módulos (funciones, beneficios)
4.3. Fechas de entrega
4.4. Garantía (qué cosas garantizas y que no)
4.5. Capacitación
4.5.1. Dónde se da la capacitación.
4.5.2. Cómo se da la capacitación.
4.5.3. Cuántas personas pueden estar involucradas.
4.5.4. Cuánto tiempo.
4.6. Documentación incluida
4.6.1. Manual de usuario (aclaración de para que sirve el sistema)
4.6.2. Ayuda para la operación (cómo se utiliza el sistema)
4.7. Equipamiento propuesto (Mínimo y Recomendado)
4.7.1. Hardware
4.7.2. Software
5. Propuesta Económica
5.1. Costo Total
5.2. Formas de Pago.
5.3. Costo del Equipamiento Recomendado
5.4. Validez de la propuesta
6. ANEXO - CALCULO DE LA PROPUESTA ECONOMICA.
6.1. Detalle del importe total presupuestado
6.1.1. Cantidad de horas requeridas (análisis, diseño y programación)
6.1.2. Valor/es hora
6.1.3. Otros
7. Diseño
7.1. Casos de uso
7.1.1. Diagrama de Casos de Uso con breve descripción.
7.2. Plan de Juego
7.2.1. Modelaje y texturado (es decir, los elementos, objetos que serán utilizados).
7.2.2. Menúes e interfaces Presentación (la presentación no es la pantalla de "cargando"; sino una descripción de las pantallas, del fondo por ejemplo, que verá el jugador).
7.2.3. Jugabilidad (instrucciones, objetivo del juego).
7.2.4. Motor (si necesita uno), se debe explicar el sistema de audio, el de entrada de datos, el de renderización, y los que deban ser comentados dependiendo del proyecto correspondiente.
7.2.5. Desafíos potenciales.
7.3. Diagrama de Estado.
Requisitos para aprobar el primer trimestre
Para los proyectos de Gestión
NO INCLUYE POR EL MOMENTO DIAGRAMA DE SECUENCIA Y DIAGRAMA DE CLASES.
CARPETA de PROYECTO FINAL
Todas las hojas con encabezado (Nombre del Sistema) y pie de página (Alumno, curso, año y número de página)
1. Carátula
1.1. Materia
1.2. Apellido, Nombre
1.3. Curso
1.4. Año
1.5. Usuario / Destinatario
1.6. Objetivo
1.7. Profesor
2. Indice
3. INFORME DE RELEVAMIENTO
3.0. Investigación de mercado.
3.1. Entrevista (preguntas y respuestas)
3.2. Informe (descripción)
3.2.1. Descripción
3.2.2. Organigrama (Opcional)
3.2.3. Requerimientos Técnicos
3.2.4. Requerimientos Funcionales (priorizados)
3.3. Requisitos
3.3.1. Técnicos
3.3.2. Funcionales (priorizados)
3.4. Anexo de documentación completa propia de la empresa (Fotocopias de Facturas, Recibos, etc.)
4. PROPUESTA Técnica y Funcional
4.1. Introducción (Resumen)
4.1.1. Principales problemas detectados
4.2. Solución
4.2.1. Propuesta funcional
4.2.2. Descripción de los módulos (funciones, beneficios)
4.3. Fechas de entrega (de cada módulo/s)
4.4. Garantía (qué cosas garantizas y que no)
4.5. Capacitación
4.5.1. Donde se da la capacitación.
4.5.2. Como se da la capacitación.
4.5.3. Cuantas personas pueden estar involucradas.
4.5.4. Cuanto tiempo.
4.6. Documentación incluida
4.6.1. Manual de usuario (aclaración de para que sirve el sistema)
4.6.2. Ayuda en línea (dentro del sistema) para la operación (cómo se utiliza el sistema)
4.7. Equipamiento propuesto (Mínimo y Recomendado)
4.7.1. Hardware
4.7.2. Software
4.8. Descripción de Servicios Opcionales
4.8.1. Mantenimiento (definición de que es. Es posterior a la garantía)
4.8.2. Carga inicial
4.8.3. Capacitación extra.
5. Propuesta Económica
5.1. Costo Total
5.2. Formas de Pago. Ej.: % adelanto (20-30), % contra entrega de módulos (hasta cubrir un 60-70), % con la aprobación del sistema o con un plazo límite (5-10)
5.3. Costo de los Servicios Opcionales (Punto 4.5)
5.4. Costo del Equipamiento Recomendado
5.5. Validez de la propuesta
6. ANEXO - CALCULO DE LA PROPUESTA ECONOMICA.
6.1. Detalle del importe total presupuestado
6.1.1. Cantidad de horas requeridas con detalle por módulo
6.1.2. Valor/es hora
6.1.3. Otros
7. Diseño
7.1. Casos de uso
7.1.1. Diagrama de Casos de Uso con breve descripción.
7.1.2. Selección de 2 o 3 casos de uso.
7.1.2.1. Descripción de Casos de Uso
7.1.2.2. Interfaz gráfica de cada uno
7.1.2.3. Diagrama de Secuencia
7.2. Diagrama de Clases.
domingo, 15 de mayo de 2011
Teoria de Diagrama de Estados
Permite identificar bajo que argumentos se ejecuta cada uno de los procesos y en que momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.
viernes, 13 de mayo de 2011
Teoria de diagrama de estados
En cuanto a la representación, un diagrama de estados es un grafico cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.
Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transición se representa como una flecha desde el estado origen al estado destino.
La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas.
lunes, 9 de mayo de 2011
Bitácora
- Subir investigación al blog.
- Al diagrama agregarle las cancelaciones.
- Se puede pausar?
- Pasar el diagrama de estado a rational.
- Hacer una especificación de cada burbuja que muestre el funcionamiento.
- A medida que esten listas las descripciones empezar a programar.
Tareas a hacer
Chicos, tienen que hacer una investigación sobre Diagramas de Estado!
Bitácora
Propuesta y plan de juego mostrarselo al usuario.
Diagrama de estado
- Pasar el diagrama a Rational
- Escribir una especificación del funcionamiento de cada burbuja.
- Usar gerundio para nombres de burbujas.
- A medida que las descripciones están listas se puede ir programando la funcionalidad.
Bitácora
Diagrama de estado.
- Hacer una descripción sobre el funcionamiento interno de la burbuja.
- Explotar "Lanzando juego con modo seleccionado". (Otro diagrama o texto)
- Pasar a Rational el diagrama de estado.
Bitácora
Nota: Incompleto!!!
Completar los procedimientos actuales.
Un procedimiento nace con una necesidad y termina cuando esa necesidad queda satisfecha. Cada uno de estos es avalado por comprobantes cuyas fotocopias debe conseguirse.
Ej.: Ventas, Cobranzas, Pagos, Compras, Cuentas con Corrientes (Proveedores), Devoluciones, Reparaciones (Pedido).
Otros temas a averiguar
Manejo de Stock.
Al estar incompleto el informe, también lo está la propuesta.
Previo a la propuesta plantear los requisitos (técnicos y funcionales) y hacer el diagrama de Casos de Uso con una breve descripción de cada caso.
Hacer el 20% de descripciones de casos de uso (Pedido de Servicio técnico y Facturación). Rehacer Informe y Propuesta.
Bitácora
- Averiguar más sobre el código de artículo.
- Información sobre el catálogo.
- Qué pasa con lo que se pide y no hay en stock? Conviene dejar alguna información para evaluar estadísticas de pedidos no satisfechos, artículos faltantes.
- Ampliar sobre cómo se manejaría el negocio on line.
Cómo se actualiza el stock??
Nota: MB-
Propuesta
- Ampliar con más opciones.
- Averiguar donde residen los archivos.
Diseñar las interfaces.
Bitácora
- Cada procedimiento está avalado por un comprobante. Conseguir copia de ellos.
- Ampliar los procedimientos. Ej.: Pedido de service.
- Los requerimientos funcionales expresarlos en la terminología del usuario.
- Los requerimientos técnicos son los No funcionales que haya pedido el usuario.
Diagrama de Casos de Uso
- Los actores van afuera y los ovalos adentro.
- Separar roles (Vendedor, Comprador, Técnico, Gerente, etc.).
- Las flechas no son las adecuadas.
- Sólo poner los casos de uso que correspondan a la funcionalidad del sistema relacionada con las reglas de negocio.
- Actualizar el diagrama y hacer breve descripción de cada caso.
- Completar.
Nota: B
- No usar "administrando" para las transacciones.
Bitácora
- Corregir errores ortográficos!!!
- Hacer oraciones más cortas y releer el informe para ver si se entiende.
- En el organigrama usar rectángulos NO ovalos.
- Separar los procedimientos con títulos.
- El cliente no le quiere dar comprobantes. Verlos in situ y tomar nota de los datos.
- Los procedimientos nacen con una necesidad y terminan cuando esa necesidad está satisfecha. Ver cómo se llevan a cabo. Cada procedimeinto es avalado por un documento, verlos y traer información.
- Los requerimientos funcionales expresarlos como lo hizo el cliente.
- Los requisitos funcionales surgen a partir de los requerimientos y dan idea de la funcionalidad del sistema a desarrollar.
- Nota: B-
- Usar gerundios para los casos de uso.
- La impresión de factura puede estar incluida en "Registrando Ventas".
- Las ventas No se eliminan, en todo caso se Anulan.
- Replantear los requisitos funcionales para mejorar el diagrama.
- Agregar una breve descripción de cada caso de uso.
- Rehacer en función de los cambios efectuados en los puntos anteriores.
Bitácora
Nota: Incompleto!!!
Completar los procedimientos actuales. Ej.: Ventas, Cobranzas, Pagos, Compras, Cuentas con Corrientes (Proveedores), Devoluciones.
Otros temas a averiguar
Manejo de Stock (artículo, talle, color), Comisiones sobre ventas, Manejo de Caja, etc..
Traer todo tipo de comprobante completo.
Al estar incompleto el informe, también lo está la propuesta.
Previo a la propuesta plantear los requisitos (técnicos y funcionales) y hacer el diagrama de Casos de Uso con una breve descripción de cada caso.
Hacer el 20% de descripciones de casos de uso. Rehacer Informe y Propuesta.
domingo, 8 de mayo de 2011
miércoles, 4 de mayo de 2011
Bitácora
-Haga otra entrevista para saber cuales son los procedimientos actuales que utilizan para llegar a lo que llegaria a tener que hacer el juego.
-Completar el informe
-Correguir los errores ortograficos de la propuesta tecnica y funcional y del plan de juego
-Subir a Scribd la Propuesta Tecnica y Funcional y el Plan de Juego
-Presentar propuesta y plan de juego al usuario.
lunes, 2 de mayo de 2011
Bitacora
Luego de hablar con silvia lo que tengo que tener para la siguiente clase es:
- 20% de las descripciones de casos de uso.
Bitácora
Bitacora
- En la encuesta aclarar el tipo de juego del que se trata.
- Subir la encuesta al blog.
- Analizar los resultados.
- Subir el plan de juego.
- Hacer el diagrama de estado.
Nota: B+
Bitácora
• Subí todos los archivos que tenía que subir al blog, excepto las descripciones de casos de uso, y la explicación de cómo usar el Rational, porque no anda en ORT.
• Investigué sobre Diagramas de Estado.
• Averigué cómo programar el juego para mandar información por internet (tuve una entrevista con Pablo Zaidenvoren, profesor de programación de ORT). Ahora voy a hacer un programa simple para testearlo.
Entonces, cosas para hacer:
• Programa para testear Wcf y Pockets.
• Explicación de cómo usar el Rational XDE Java.
• Diagrama de estados.
• Diagrama de Casos de uso.
(ambos diagramas en papel).
• Tratar de concertar una entrevista con Reides.
Desafío
Cómo usar el Rational
domingo, 1 de mayo de 2011
Cómo hacer un Plan de Juego
Menúes e interfaces
Presentación (la presentación no es la pantalla de "cargando"; sino una descripción de las pantallas, del fondo por ejemplo, que verá el jugador)
Jugabilidad (instrucciones, objetivo del juego)
Si necesita un motor, se debe explicar el sistema de audio, el de entrada de datos, el de renderización, y los que deban ser comentados dependiendo del proyecto correspondiente.
Equipamiento propuesto
Desafíos potenciales.
