lunes, 30 de mayo de 2011

Sólo para juegos

Chicos, tienen que hacer las interfaces de los juegos.
Además, cuando vayan a la charla de XNA tienen que hacer un post sobre qué aprendieron.

Bitácora

Hacer diagrama de clases y llevarlo a la reunión de XNA.

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

Completar interfaces.
Diagrama de clases agregar items de pedido y ver las relaciones entre clases.

Bitácora

Hacer el diagrama de clases y llevarlo junto con el de estado a la reunión de XNA.

Informe de relevamiento agregar en los requerimientos funcionales lo que te pidieron específicamente (el himno, canciones en español, etc.)

Bitácora

Diagrama de CU. Completar las breves descripciones. Agregar estadísticas más específicas.
Terminar todo lo necesario para aprobar el trimestre.

Bitácora

Ajustar diagrama de CU según correcciones de los requisitos. Agregar en word una breve descripción de cada caso de uso.
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

Propuesta Técnica y funcional. MB
Diagrama de clases: Ver de plantearlo en la charla de XNA.
Separar los diagramas en distintas solapas del rational

Bitácora

Informe de relevamiento Nota: B
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

REQUISITOS FUNCIONALES:
-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

Informe de relevamiento Nota B- No trajo las últimas correcciones.
Terminar todo lo que se necesita para aprobar el trimestre!!

domingo, 29 de mayo de 2011

Propuesta técnica y funcional

Propuesta Tecnica y Funcional Corregida

Propuesta económica

Propuesta Economica

Encuesta: preguntas y Resultado

1)Alguna vez jugaste alguna variante de dicho juego?

• 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

Investigación Diagramas de Estado y Actividades

diagrama de actividades





Investigación Diagrama de Estados

Informe de relevamiento

Informe de Relevamiento Corregido

jueves, 26 de mayo de 2011

Juegos - Charla de XNA

A continuación detallo la lista de los alumnos a mi cargo que, el próximo jueves 2 de junio en el segundo bloque, tendrán una charla del uso de XNA a cargo del ex alumno que hizo LeBallon y Gutes.
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

Informe de relevamiento




  • 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

Informe de relevamiento





  • 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

Falta subir el informe de relevamiento al blog.

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

Diseño
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

CARPETA

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

Diagrama de estado


  • 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

Eric,
Seguí adelante, recordá que falta poco para cerrar el trimestre.

Bitácora

Informe de relevamiento Nota B-


  • 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

Requisitos 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

Informe de relevamiento.


  • Subir al blog con scribd.Requisitos t y f .

  • Revisar los funcionales y subir al blog.
Diagrama de CU



  • Hacer una breve descripción de cada caso de uso (3 líneas) en Word.
Propuesta técnica y funcional.





  • Dejar la carga inicial a cargo del cliente.


  • Nota: MB-
Propuesta económica.





  • 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

Informe de relevamiento


  • 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

Avances:


  • 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

Sebi,
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

Informe de relevamiento


  • 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

Informe de relevamiento


  • 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

Para el proyecto de PF es obligatorio llevar una carpeta cuyo diseño se adjunta, y es responsabilidad del alumno tenerla en todas las clases y entregarla cuando se lo solicite. Dicha carpeta deberá presentarse también en el coloquio.
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

Carpeta de Proyecto completa!!!


Para los proyectos de Gestión
NO INCLUYE POR EL MOMENTO DIAGRAMA DE SECUENCIA Y DIAGRAMA DE CLASES.

CARPETA de PROYECTO FINAL

Para el proyecto de PF es obligatorio llevar una carpeta cuyo diseño se adjunta, y es responsabilidad del alumno tenerla en todas las clases y entregarla cuando se lo solicite. Dicha carpeta deberá presentarse también en el coloquio.
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

Un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de informacion luego de ejecutarse cada proceso.
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

Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso de uso, un objeto a lo largo de su vida o todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera.
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

Diagrama de Estado.
  • 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.
Nota: B+

Tareas a hacer

ESTO SOLO VA PARA LOS QUE HACEN JUEGOS:

Chicos, tienen que hacer una investigación sobre Diagramas de Estado!

Bitácora

Hacer el informe de la investigación del diagrama de estado.
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

Hacer el informe de la investigación de UML - diagrama de estado.
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.
Nota: MB

Bitácora

Informe de relevamiento
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

Informe de relevamiento
  • 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.
Plantear los requisitos funcionales para hacer el diagrama completo.
Cómo se actualiza el stock??
Nota: MB-

Propuesta
  • Ampliar con más opciones.
  • Averiguar donde residen los archivos.
Descripciones 20% . Ver UML y Patrones para ver como hacer una descripción completa.
Diseñar las interfaces.

Bitácora

Informe de Relevamiento
  • 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.
Plantear los requisitos funcionales

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.
Propuesta técnica y funcional.
  • Completar.
Hacer 20% de descripciones (Pedido de Service y Facturación)

Nota: B
  • No usar "administrando" para las transacciones.

Bitácora

Informe de relevamiento
  • 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-
Diagrama de Casos de uso.
  • 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.
Propuesta
  • Rehacer en función de los cambios efectuados en los puntos anteriores.

Plan de Juego

Plan de Juego

Bitácora

Informe de relevamiento
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

Plan de Juego

Plan de Juego

Encuesta

Encuesta

Plantilla vacía

registrando cliente

miércoles, 4 de mayo de 2011

Bitácora

Tuve la entrevista con Silvia y me dijo que:
-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

Tuve la entrevista con silvia y me dijo que haga descripción del caso de uso acerca de la producción de aerosoles.

Bitacora

Hoy en la entrevista con Silvia y me dijo que tenía que:


  • 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

• Estuve intercambiando e-mails con mi contacto del programa de Ajedrez del GCBA.

• 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


Yo elegí el nombre Service Gestión ya que es un sistema diseñado para un service de electrodomésticos de audio y video.

Cómo usar el Rational

Chicos, el Rational XDE For Java (el que hay que usar), no anda en ORT! cuando se pueda abrir explico cómo usarlo!

domingo, 1 de mayo de 2011

Plan de Juegos por Guillermo Mosse

Plan de Juegos

Cómo hacer un Plan de Juego

El Plan de Juego debe tener los siguientes items:

Modelaje y texturado (es decir, los elementos, objetos que serán utilizados)

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.
Bueno chicos, acá les mando la teoría de Casos de Uso. Es un powerpoint que subí a Google Docs. Google Docs sirve para subir diferentes tipos de archivos (como .doc, por ejemplo, así que lo pueden usar para subir Words) ¿Cómo se hace? Van a docs.google.com, si necesitan registrarse se registran, uplodean el archivo, van a la página donde se muestra (es todo muy intuitivo), y hacen click en EL TRIANGULITO a la derecha de "Share", o "compartir". la última opción es "Publicar" o "Embed", eso les da un código HTML que pegan en el post del blog y listo el pollo!