lunes, 27 de septiembre de 2010

Metodologías

Estas son las metodologías/frameworks a analizar:

SCRUM
RUP

XP
METRICA
KANBAN

Espaguetis y nubes...

Hoy hemos realizado una actividad muy interesante para reflexionar acerca del trabajo en equipo, de como organizarnos, de como resolver diferencias de criterios... todo de una manera muy dulce!!














viernes, 24 de septiembre de 2010

Ya tenemos equipos!!!

A partir de los resultados del test Belbin, el equipo de profes de 2º de DAI ha configurado los siguientes equipos:

EQUIPO 1: Sergio Fresneda, Salva Peris, Juan Ballester, José López, Álex Argüelles, Albert Bresó y José Vte. Maldonado.

EQUIPO 2: Félix Perona, Vicente Soria, Rubén Albiach, Esteban Salmerón, Jesús Pérez, Vlad, Berna Ramón, Freyder Espinosa.

Esto marcha!

miércoles, 22 de septiembre de 2010

Especificación de requisitos

En estos archivos:

hay plantillas y ejemplos de la estructura que IEEE recomienda para la definición de requisitos de un sistema software.
Esta PEC nº3 consiste en que, por equipos, penséis en los requisitos que debe tener una aplicación (se os asignará por sorteo), poniéndoos en la piel del cliente y que, por otra parte, consigáis definir bien lo que el cliente quiere actuando como analistas.
Se actuará por turnos y al terminar cada ronda, se cambiará el rol desempeñado.

El deliverable de esta PEC será un documento que, siguiendo el esquema IEEE, detalle a la perfección la funcionalidad de la aplicación así como una presentación que la explique.

Liberación de código (desde Barrapunto)

Durante la reciente QuakeCon, John Carmack anunció la liberación del código de los juegos Return to Castle Wolfenstein y Enemy Territory . Los desarrolladores de ioquake3 (el proyecto libre basado en Quake 3) ya tienen funcionando los proyectos iowolfet e iortcw, con su serviodor de Mercurial hg.ioquake.org para quien quiera clonar el proyecto. Hay que recordar que lo que es libre es el código, mientras que los recursos del juego (modelos, texturas niveles) siguen siendo propiedad de id Software y Activision.

martes, 21 de septiembre de 2010

Presentacion ingeniería del software

Test Belbin

Hola a todos.
 Aquí tenéis el enlace al famoso test Belbin que utilizaremos para configurar equipos lo más armonizados que podamos.
 Cuando lo hayáis terminado, por favor, imprimidlo en PDF y colgadlo aquí.

A continuación, os dejo una breve explicación de los resultados del test:

CW: “Company Worker”. “Implementer”. Implantador.
CH: “Chairman”, “Co-ordinator”. Coordinador.
SH: “Shaper”.
PL: “Plant”.
RI: “Resource investigador”. Investigador de recursos.
ME: “Monitor”, “Evaluator”. Observador, evaluador.
TW: “Teamworker”. Trabajador de equipo.
CF: “Completer”, “Finisher”.Finalizador.

El rol dentro del equipo que presente la puntuación más alta indica cómo la persona que
ha contestado el cuestionario puede destacar en un equipo de gestión o de proyecto. Las
puntuaciones inmediatamente inferiores indican roles de soporte, los cuales deberían
asumirse por la persona en cuestión si por alguna razón el equipo tiene menos necesidad
del rol primario.

Los dos resultados más bajos representan posibles áreas de debilidad. Resulta
aconsejable que un directivo en vez de intentar mejorar en estas áreas debería buscar un
colega con fortalezas complementarias.


· “Plant”

Es el proveedor de ideas del equipo. Sabe como generar ideas para afrontar los
problemas que afectan al equipo. Tiene tendencia a trabaja mejor cuando se enfoca en
temas principales que en pequeños detalles.

· Investigador de recursos

Actúa como fuente de información e ideas. Sabe cómo establecer contactos con
personas externas al equipo que puedan ser útiles. Usualmente tienen una cartera de
contactos en continua expansión. Normalmente sacan provecho de estos contactos sin
consultar con el equipo.

· Coordinador

Provee liderazgo coordinando los esfuerzos y contribuciones de los miembros del
equipo.

· “Shaper”

Provee liderazgo dirigiendo y controlando los miembros del equipo. Ejerce una fuerte
influencia sobre el modo en que funciona el equipo. Tiende a impulsar al equipo hacia
sus objetivos. Es bueno en hacer que las cosas se hagan, pero puede agobiar a otros
miembros del equipo. Esta persona puede no ser el líder formal del equipo, pero sin
diplomacia sus características podrían ofender al líder formal.

· Evaluador

Sabe evaluar ideas y sugerencias. Tiende a ser objetivo y sabe analizar problemas y
evaluar alternativas. Comúnmente llamado también el “abogado del diablo”. Es
importante para estas personas señalar los problemas con tacto y no ser demasiado
crítico con las sugerencias de los demás.

· Miembro de equipo

Ayuda a mantener la armonía y el espíritu de equipo. Sabe mejorar la comunicación en
el equipo y hacer participar a las personas en debates. Es un rol importante dentro de un
equipo pero dado que la mayor parte de su trabajo se produce en un segundo plano, no
es fácil apreciar el valor de estas personas.

· Implantador

Es bueno en lograr resultados prácticos y detallados. Se le puede confiar la
responsabilidad de implantar las decisiones de equipo. Sabe como tomar ideas y planes
y convertirlos en procedimientos prácticos.

· Finalizador

Es el tipo de persona que presta especial atención a los detalles y se encarga de hacer un
seguimiento de las tareas inacabadas. Tiende a generar un sentimiento de urgencia
dentro del equipo y es bueno en mantener al equipo de acuerdo con la programación
establecida.

· Especialista

Provee conocimientos y habilidades singulares. En un entorno empresarial no suele ser
un miembro de equipo regular; habitualmente se le invita a participar en un equipo para
tratar temas o problemas específicos. No afecta directamente a la dinámica del equipo,
así que un equipo puede trabajar con éxito sin necesidad de un especialista. Es más un
papel que la persona puede jugar en un equipo que un tipo de personalidad. Un
especialista suele ser de ideas fijas e independiente, lo cual le hace adquirir sus
habilidades especiales.


lunes, 20 de septiembre de 2010

Caso de estudio: Errores clásicos en un proyecto de desarrollo de software

Hoy, me gustaría que dedicáramos un rato a analizar a fondo este caso, extraido del Code Complete, de McConell para que, por equipos, presentárais un informe conteniendo:
  • Errores detectados: quien lo comete, en qué consiste, etc...
  • Maneras alternativas de actuar: ¿cómo hubiérais actuado vosotros?
 El entregable, que deberá estar en el portafolio del equipo, debe incluir una presentación (en el formato que queráis, pero on-line) que deberéis utilizar en la próxima clase para mostrarla al resto de compañeros.

caso1

viernes, 17 de septiembre de 2010

Equipos

Anotad aquí la configuración de vuestros equipos.

Portafolios personales

Acceded a este documento y, por favor, poned el link a vuestro portafolio personal.

Preguntitas para conocernos mejor

Q1.- Tecnologías
Q2.- Futuro
Q3.- Expectativas

¡Bienvenidos!

Hola a todos. Es un placer compartir con vosotros este curso 2010-2011, el cual confío que sea fantástico para todos y que aprendamos mucho unos de otros.
Para ir tomando contacto con la asignatura, os dejo la siguiente mini-intro: