domingo, 22 de junio de 2008

Curso: Introducción a la Ingeniería del Software

Voy a dar un curso sobre Ingeniería de Software en la Facultad de Ingeniería de la UBA con algo más que un toque Ágil!

Objetivo del curso

Conocer los conceptos y herramientas de la ingeniería del software.

Dirigido a

Personas que cubren roles de Analistas de Negocio, Tester Funcionales, Administradores de Proyectos, Escritores Técnicos, Diseñadores Gráficos y otros roles, que tienen relación con proyectos de desarrollo de software sin tener educación formal en el área de software.
Personas que desear comenzar una carrera de especialización sobre Ingeniería de Software.

Al finalizar el curso

Los asistentes habrán conocido las áreas de la Ingeniería del Software, teniendo un entendimiento inicial de cada una de ellas, manejando la terminología relacionada. Habrán realizado prácticas en computadores y conocido alguna herramienta de soporte en cada una de las áreas.
Esto les permitirá interactuar en forma más efectiva en equipos de desarrollo de productos en los que el software es un componente importante.
Servirá como base para profundizar en los temas de interés.

Detalle de los contenidos

Conceptos

Detalle

Conceptos generales

Concepto de Proceso y Modelo. Características de producto (software), y de los procesos de desarrollo. Prácticas. La ingeniería del software y su relación con la ingeniería de sistemas y procesos de negocio.

Modelos de proceso

RUP, Incremental, Ágil. Métricas.

Requerimientos

Obtención de requerimientos, escritura, herramientas y modelización. Modelado de datos, modelado de dominio. User stories, Use Cases, especificación basada en ejemplos.

Herramientas y práctica.

Diseño y Arquitectura

Niveles de diseño. Concepto de patrones de diseño. Modelos lógicos y físicos. Patrones de arquitectura: cliente / servidor, multicapas, Orientado a Servicios. UML básico. Diseño de interfase usuaria. Modelos ejecutables. Diseño orientado a la prueba.

Herramientas y práctica.

Codificación

Compiladores e interpretados. Tipos: fuerte y débilmente tipados, procedurales, orientados a objetos, programación por eventos. Herencia y encapsulamiento. Cohesión y acoplamiento. Inversión del control.

Herramientas y práctica.

Calidad y Prueba

Inspecciones, desarrollo en pares, técnicas de prueba: caja blanca, caja negra, orientada a riesgos. Administración y métricas: cobertura, densidad de defectos.

Herramientas y práctica.

Procesos de soporte

Control de configuraciones y versiones. Build e integración continua. Administración de proyectos de software.

Herramientas y práctica.

Fecha de inicio

45 hs, 15 clases semanales de 3hs cada una.
Inicio: 1ro de Septiembre (lunes de 19 a 22 hs)

Curso Introducción al Testing de Software

Como comenté en otra entrada, creemos que hay pocas personas con la mezcla de capacidades más apropiada para Tester Técnicos (que son muy importantes en equipos ágiles).
Por eso Lucas Campos y yo daremos este curso en la Facultad de Ingeniería de la UBA. Si querés, podes usar parte del material.


OBJETIVO DEL CURSO

Entrenar a miembros de equipos de desarrollo de software en las técnicas y prácticas relacionadas con la prueba automática de software y ampliar sus conocimientos en relación a aspectos técnicos de la prueba de software. Esto es particularmente importante en equipos que aplican metodologías ágil (Scrum, XP).

PUBLICO AL QUE VA DIRIGIDO

Miembros de equipo de desarrollo de software, tanto a desarrolladores como a testers y analistas, que deben incorporar técnicas y práctica de la Ingeniería de Software relacionada con la prueba y la calidad, con fuerte énfasis en la automatización.

MOTIVO POR EL CUAL DEBERÍA HACERSE

Actualmente se hace imprescindible que la prueba del software sea realizada de manera automatizada y con comprensión de las tecnologías involucradas en el desarrollo. Para esto ser requiere una combinación de conocimiento funcional, de dominio del negocio, conocimiento de técnicas de prueba y conocimientos técnicos.

Esta combinación de características es poco común en el mercado, ya que los profesionales de sistemas generalmente desarrollan un área de conocimiento (dominio, prueba) u otra (programación, conocimiento técnico).

Este curso permitirá a los asistentes:

  • Mejorar la participación en equipos de desarrollo multidisciplinarios donde se requiere que los involucrados posean un alto compromiso con la calidad y a la vez posean conocimientos técnicos.
  • Complementar las habilidades de quienes tienen conocimiento funcional (testers, analistas, etc.) con otros orientados a pruebas de software técnicas.
  • Comprender y poder llevar adelante pruebas de alta carga en forma automatizada (Performance, stress, volumen, etc.)
  • Cubrir perfiles relacionados con la automatización de las pruebas de software (tanto para los perfiles de origen más técnicos como para los más funcionales).


PRERREQUISITOS

Los asistentes deberán tener conocimientos de programación. Es recomendable que además tengan al menos un año de experiencia laboral.

FECHA DE INICIO

A partir del 12/8/2008 (martes de 18:30 a 22:30hs)
Duración: 51 hs

domingo, 1 de junio de 2008

FIUBA - Trabajos Profesionales

Este es un aviso para los estudientes de la Fac. de Ingeniería de la UBA

Para los que quieran hacer Trabajo Profesional, estoy tomando propuesta y tengo temas disponibles que están alineados con la siguiente línea:

Desarrollar mejoras en herramientas de código libre (FLOSS) de soporte para equipos de desarrollo de software, incluyendo pero no limitada a herramientas para:

- automatizar la prueba,

- medir cobertura de la prueba,

- automatizar build e integración continua.

-

Pueden ver como ejemplo el Trabajo Profesional que realizó Carlos Duplaá (Cover@age), que surgió de la necesidade de la empresa Kayxo para probar su producto Kayxo Insight. Ese producto permite medir la cobertura basada en los archivos de configuración XML y los correspondientes XSD.

Todos los trabajos deberán concluir con mejoras en productos existentes o desarrollo de productos nuevos (sólo admisible si no hay un producto equivalente) , y deben tener alta calidad, incluyendo alto nivel de cobertura con pruebas automatizadas, generación de builds automatizado, UAT (pruebas de aceptación) automatizadas, documentación de usuario al menos en inglés.

No hay restricción en cuanto a tecnologías (.NET, Java, …).

Los trabajos son focalizados, con alcances definidos y deben ser hechos en el plazo de 6 meses, con entregas intermedias. Esto es relevante debido a que los productos FLOSS evolucionan, por lo que si se dura más tiempo, o no se hacen entregas incrementales, es posible que el resultado sea obsoleto o redundante al finalizar el plazo.

Si están interesados, les pido se comuniquen conmigo


Saludos

Juan Gabardini

miércoles, 21 de mayo de 2008

¿Documentación en ambientes ágiles?

Ezequiel Glinsky nos invitó a Nicolás Páez y a mi a hablar sobre la documentación de arquitectura en desarrollo de software usando métodos ágiles, en la materia Metodologías de Documentación de la Maestria en Tecnología de la Información de la Universidad de Palermo.
¡Qué desafio!

Es acaso la documentación contraria a las ideas ágiles (Working software over comprehensive documentation)?
Evidentemente no. Pero como comenté en una entrada anterior en relación a la administación de proyectos, me acostumbre a hablar del "lado izquierdo" del Manifiesto Ágil, que es donde hacemos foco por considerarse más valioso, pero lo de la derecha también tiene valor, y por lo tanto a muchas personas les interesa saber que forma toman en un ambiente con metodologías ágiles la documentación, los procesos, las herramientas, los contratos, etc.
Después de darle un par de vueltas al tema, lo plantee de la siguiente manera:
  • Motivos para implementar metodologías ágiles: la forma de documentación es una herramienta para lograr un objetivo, entonces debo entender los objetivos.
  • Cómo cambian los roles y tareas relacionados con arquitectura: no pudiendo asumir que la gente conoce la forma de trabajo en ambientes ágiles, es necesario comentar como es afectada la definición de arquitectura, y por ende la documentación correspondiente.
  • ¿Documentación?: y finalmente, ¿estamos hablando de documentación, o acaso nos referimos a Comunicación de la arquitectura? Es una diferencia interesante, ya que este diferente punto de vista nos cambia la perspectiva. Pair programing es una forma de comunicar la Arquitectura, como así también las reuniones de diseño ante un pizarrón. Con esta punto de vista, la documentación (wiki, documento, herramienta) es una forma más de comunicar. Sobre esto ha escrito Rebecca Wirfs-Brock. Por otro lado, también podemos consideramos que la Arquitectura es un idioma (o al menos un dialecto), que nos sirve para expresar la solución a la necesidad del cliente; con este punto de vista la pregunta es como hacer para que los miembros del equipo y otras perso.

La charla se dió en poco más de una hora, con 15 min de preguntas. Pueden encontrar la presentación
acá.

Luego Nico comentó la experiencia de Snoop, lo que permitió bajar a tierra varias de las ideas y creo que logro un buena mezcla de ideas y práctica. Lo interesante es que nos pusimos de acuerdo a altisimo nivel, y sin embargo las presentaciones se complementaron muy bien. Para más información, pueden ver el grupo de la materia.

Preregistración a cursos en Agiles 2008

Hemos iniciado la pre-registración para los cursos que se dictarán los días 20 y 21 de Octubre.
Los cursos disponibles actualmente son (más información en
http://agiles2008.org):

  • Curso de Lean Development, dictado por Mary y Tom Poppendieck
  • Curso de CSM, dictado por Tobias Mayer
  • Curso de TDD, dictado por Dave Astels

En todos los casos, el costo del curso es de usd 600, pero en caso de pre-registro el costo es de usd 500. La pre-registración, con lo que se reserva una vacante, se realizará hasta el 30 de junio. El pago se realizará a partir del 1 de Julio.
Todos los cursos tienen una duración de dos días, 8hs por día e incluyen práctica, que en el caso de TDD es práctica con computadoras. Los cursos tienen cupo limitado y son en inglés, aunque habrá personas para ayudar con temas de idioma.
Los cursos se dictan en forma simultánea, por lo que debe elegirse uno de ellos. Si lo desean, pueden elegir uno adicional para el caso que el primero esté completo.
Los asistentes a los cursos tendrán derecho a acceder a las Jornadas, sin costo adicional. Para información obtener más información de las jornadas, consultar
http://agiles2008.org
En el caso de sponsors, se aplica el mismo criterio, al indicar su participación reservan las vacantes correspondientes a su categoría, pero deben realizar el pago para confirmar su lugar. Para consultas sobre registración, cursos y oportunidades de sponsoreo, contactarse con
info@...


Para pre-registrar, enviar un mail a registro@... con el siguiente formato
Subject: nombre

Body
Nombre:
Email:
Empresa: // opcional
Curso 1ra opción: Lean/CSM/TDD // elegir uno
Curso 2da opción: Lean/CSM/TDD // elegir uno
Procedencia: país/provincia/estado

miércoles, 14 de mayo de 2008

IEEE CS - Reedición del curso Páctico de Scrum Q&A

Hola
Algunos de los asistentes al curso me hicieron llegar comentarios que me gustaría compartir

Adrian Ariza me comenta del sitio http://www.navegapolis.net/ donde hay mucho material en español de Scrum y metodologías ágiles en general.

Por otro lado
Victoria Pocladova me acercó un documento con las notas sobre algunas de las preguntas y respuestas que tuvimos en el curso. Muchas gracias por pasarlo Victoria!
Algunas de las preguntas:

  • Como planifico y hago contratos con Scrum?
  • Scrum vs RUP?
  • Scrum vs CMMI?
  • Niveles de planificación en Scrum
  • Importancia de Product Owner
  • Scrum con desarrollo de terceros (soy cliente de una factory de desarrollo)
  • Uso de reglas para disminuir conflictos en el equipo
  • Tips para definir duración de los sprints
Saludos

jueves, 8 de mayo de 2008

IEEE CS - Reedición del curso Páctico de Scrum

En esta segunda vez hubo más ida y vuelta, con algunas preguntas muy interesantes, que muchas veces son fuente de discusión en scrumdevelopment y en laasd
  • Convivencia de Scrum y CMMI
  • Como manejo la mega tarea indivisible
  • Puede le Product Owner ser el superior jerárquico de los Scrum Masters
  • El
Con respecto a la organización general, mantuve algo muy parecido a lo anterior, pero la presentación está actualizada, sobre todo la primera parte.
Espero postear lo que hablamos sobre las preguntas en breve.