Etiqueta: Ingeniería de software

Interesante curso de Ingenieria de Software

La semana pasada empecé un curso online ofrecido por la Universidad de Standford en forma gratuita. El nombre del curso es Software Engineering for Software as a Service. El mismo tiene una duración de 5 semanas y es dictado por dos profesores de Berkeley: Armando Fox y Dave Patterson. El curso tiene foco en métodos agiles y la parte técnica está basada en Ruby on Rails.

La dinámica del curso consiste en clases teóricas en formato de video de 10 minutos de duración en promedio.  Al mismo tiempo hay un libro (pago, cuesta unos 10 dólares) escrito por los profesores del curso. La plataforma onlien también cuenta varios foros de discusión. En cuanto al aspecto práctico, hay 4 tareas de programación con un timeframe de 1 semana y por otro lado tambien hay 3 Quiz a lo largo de todo el curso.Según los profesores, alumnos anteriores han reportado una carga de trabajo semanal de entre 5 y 10 horas para completar el curso.

Luego de completar la primer semana, estoy muy entusiasmado, hasta el momento nada nuevo para mi, pero a pesar de ello me gusta la forma en que estan presentados los temas.

No estoy seguro si aún es posible sumarse al curso, pero de todas formas los video son de acceso público.

Les dejo el link al curso: https://www.coursera.org/saas.

¡Que lo disfruten!

¿Y si tu sueldo dependiera de la cobertura de tu código?

Definitivamente algunos meses habría pasado hambre  y  creo que algunos otros no habrían cobrado ni un solo peso, ja!

Más allá de lo chistoso (o lo triste) del título, este post es una continuación  de otro que escribí hace un par de dias sobre esta misma temática. En dicho post compartí algo de teoría junto con algunos links interesantes (el de artículo de Marrick es excelente) y en los cuales he encontrado justificación para algunas de las ideas que compartiré a continuación. Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en el tema de la cobertura de código lo cual me ha llevado a una reflexión profunda sobre el tema.

Si desarrollamos nuestra aplicación siguiendo un enfoque TDD extremo, siempre mantendremos un alto grado de cobertura, pues solo agregaremos código cuando haya una prueba que lo ejercite.

Si procuramos seguir las buenas prácticas de diseño la relación entre nuestros componentes será por medio de interfaces, lo cual nos permitirá utilizar mocking y asi superar la infantil excusa «No lo puedo testear porque tiene dependencias».

Si nuestros métodos son cohesivos y hacen usa sola cosa, entonces será más simple testearlos.

Si hechamos mano del polimorfirmo, seguramente podamos evitar algunos «if» en nuestro código lo cual también ayudará con la cobertura.

Para cerrar este post, les comparto una situación que viví hace unos dias. Resulta que una de las personas que estuve capacitando durante la semana pasada hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja!  a lo que le pregunto: ¿y los tests? adivinen….no había tests para esa funcionalidad. Y cuando pregunto por el porcentaje de cobertura de la aplicación, resulta que no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.

Por último quiero agradecer a David Frassoni quien la semana pasada me dió la idea de escribir este post.

El siguiente post de esta serie lo dedicaré a analizar las implicancias/consecuencias de tener una alta cobertura y de definir un shipping criteria en base al mismo.

Continuará…

Code Coverage

Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en la cobertura de código. Esto me ha motivado a compartir algunas ideas sobre este tema y para setear el contexto y las expectativas, voy comenzar este post compartiendo algunos conceptos básicos y luego en otro post voy a volcar algunas ideas/experiencias personales.

¿Qué es la cobertura de código?

La cobertura código es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas. O sea, ejecuto las pruebas de mi aplicación y si hay alguna línea de mi código que nunca fue ejecutada en el contexto de las pruebas, entonces dicha línea no está cubierta. Si mi código consta te 100 líneas y solo 50 líneas están siendo ejecutadas al correr las pruebas, entonces mi cobertura es del 50%. La pregunta que viene a continuación es:

¿Qué beneficio tiene medir la cobertura? y más específicamente ¿que beneficios tiene tener una alta cobertura?.

Una respuesta genérica podría ser que aumenta la calidad de mi aplicación. Siendo más concreto podría decir que si tengo una alta cobertura, significa que gran parte me mi código está siendo probado y por consiguiente podria tener cierta certeza sobre el correcto funcionamiento de mi aplicación. Al mismo tiempo medir la cobertura podria ayudarme a detectar código innecesario en mi aplicación, ya que no se ejecuta.

La pregunta que surge a continuación es:

¿Qué porcentaje de cobertura es suficiente?

La respuesta no es única, existen distintos criterios y pueden resultar bastante polémicos por eso voy a tratarlos en otro post. Pero por ahora solo diré que para SimpleCov, lo idea es de al menos 90% y en Southworks soliamos perseguir el 80%.

¿Una cobertura del 100% asegura que mi código no tiene bugs?

De ninguna manera, una cobertura del 100% solo nos dice que todo nuestro código está siendo cubierto por pruebas, pero puede que las pruebas no esten contemplando algunas situaciones, o sea, me falta pruebas.

¿Qué necesito para poder medir la cobertura?

En primer lugar  es necesario escribir pruebas y en segundo lugar contar con alguna herramienta que permita medir la cobertura.En la actualidad los lenguajes más populares cuentan con herramientas para medir la cobertura. Si trabajamos con C# y escribimos nuestras pruebas con MSTest, entonces el Visual Studio nos ofrece la posibilidad de habilitar la medición de cobertura de código. Si en cambio trabajamos con Ruby, podríamos utilizar RSpec para escribir nuestras pruebas y SimpleCov para medir la cobertura.

Esto es todo por ahora, les algunos links interesantes sobre el tema:

En el siguiente post voy hacer algunos comentarios sobre estos artículos.

Eventos (académicos) 2012

Durante el año pasado mientras estudiaba para las materias que cursé en la maestría de la UNLP, se me ocurrieron dos artículos que me gustaría desarrollar para presentar en algún congreso y casualmente recien empezado el año tengo tres posibles eventos donde presentarlos.

El primero es ArgenCon, organizado por la sección argentina de IEEE. El mismo se desarrollará del 9 al 13 de Junio  en Córdoba. La fecha límite para el envío de trabajos es el 15 de Marzo.

El segundo evento es la edición 41 de las JAIIO, este año organizadas en conjunto con la UNLP entre el 27 y 31 de Agosto. La convocatoria de trabajos trabajos esta abierta hasta el 30 de Abril.

Finalmente el tercer evento que tengo en el radar es Foro Mundial de Educación en Ingenieria (WEEF: World Engineering Education Forum). Sinceramente nunca había nunca había escuchado hablar de este evento (tal vez porque no siempre se realiza en Argentina). El mismo será organizado por UTN y se desarrollará en Buenos Aires del 15 al 18 de Octubre. La fecha límite para el envio de trabajo es el 2 de Marzo.

Volviendo a los trabajos que tengo en mente, el primero es sobre el enfoque que estoy utilizando en UNQ para dictar ingeniería de software. El otro es sobre algunas ideas que he venido madurando para la enseñanza de la programación en los cursos introductorios de programación.

Práctica de estimación en UNQ

(parte 5 de la serie: Ingeniería de Software en UNQ)

El jueves pasado en Ing. Soft, hicimos un ejercicio de estimación basado en la dinámica de fábrica de aviones (no voy a entrar en como es la dinámica pues si un futuro alumno lo lee, va a perder «punch»). Hicimos 3 iteraciones y en la última metimos algunas variaciones (rotación de gente, nuevos requerimientos, etc) para representar algunas situaciones comunes proyectos reales.
Creo que todos nos divertimos y me parece que algo aprendieron. De todas formas, estimación es un tema que vamos a seguir trabajando. Les dejo algunas fotos de la actividad.

Primera semana Ing. Soft – UNQ

(parte 4 de la serie: Ingeniería de Software en UNQ)

Pasó la primer semana, o sea, las primeras dos clases. En el curso hay 15 inscriptos, pero solo 14 asistieron a clase. En su gran mayoría sin experiencia laboral en desarrollo de software, pero con sólidos conocimientos de programación y conocimientos al menos básicos en temas relacionados como patrones de diseño, base de datos y uso de controladores de versiones.

Durante esta primera semana el foco estuvo en establecer las expectativas del curso, entender el contexto profesional de un técnico en programación y algunas características y fundamentos de la ingeniería de software. El libro de la semana fue The Mythical Man-Month de Fred Brooks.

Por último, al finalizar la primera clase pedí feedback con la clásica técnica de las caritas y este fue el resultado.

continuará…

Elementos de Ingeniería de Software

(parte 3 de la serie: Ingeniería de Software en UNQ)

Este es el nombre formal de la materia que voy a dictar el próximo cuatrimestre en UNQ. La materia está en el contexto de la Tecnicatura en Programación Informática, una carrera de pre-grado de 6 cuatrimestres de duración cuyo objetivo es:

Formar técnicos/as capaces de elucidar e implementar soluciones en un amplio espectro de problemas asociados a las tareas de diseño/programación dentro del desarrollo de software, en un alcance razonable para un egresado/a pre-universitario, siendo capaces de aprovechar los conceptos aprehendidos en la carrera para pensar y resolver situaciones concretas, y basados en una amplia experiencia práctica obtenida durante el recorrido de la carrera.

He resaltado con negritas algunos puntos importantes que se reflejan claramente en el dictado de las materias, según me he hablado com docentes y alumnos.

Si bien en la UNQ no existen correlatividades, en el plan sugerido de cursada, la materia está ubicada en el 4 to cuatrimestre de la carrera. Al mismo tiempo, la inscripción en la materias se realiza personalmente con un docente tutor, quien tiene la posibilidad de no anotar al alumno en un materia, si considera que el alumno no está en condiciones de cursarla. El punto es que en general, los alumnos que llegan a cursar esta materia, vienen con sólidos conocimientos de  en lo que respecta a programación orientada a objetos, patrones, algoritmia y base de datos, pero sin conocimientos en cuanto a requerimientos, arquitectura, gestión de proyectos y demás cuestiones «blandas» de la ingeniería de software. Otro punto a considerar es que en el resto de las materias de la carrera, los alumnos siguen aprendiendo cuestiones técnicas como programación concurrente, construcción de interfaces de usuario y tienen una materia llamada Desarrollo de aplicaciones que auspicia en cierto modo como materia integradora. Esto hace que Elementos de Ingeniería de Software sea la única materia en la que ven cuestiones generales de ingeniería de software que no son de índole técnica.

Luego de haber analizado todas estas cuestiones y  haber consultado con varios profesores, ya tengo una idea como encarar la materia. Como libros de texto voy a utilizar Software Engineering de Pressman y The Art of Agile Development de Shore. Dado el contexto de la materia, no voy enfocarme en cuestiones de management (aunque si las vamos a ver) si no más bien en cuestiones de self-management que todo programador tiene que poder hacer:

  • Entender el contexto de su trabajo
  • Entender los requerimientos e incluso poder modelarlos y transmitirlos.
  • Organizar su trabajo y estimarlo.
  • Comunicar su trabajo: progreso, dudas, impedimientos y siguientes pasos.
  • Identificar potenciales inconvenientes relacionados a su trabajo.

Para todos estos puntos voy a tomar como referencia complementaria el Personal Software Process de Humphrey. Tengo la intención de que estos temas no queden solo en la teoría y para ello planeo hacer un par de coding dojos/katas y algunas otras actividades de índole práctica para poner justamente en práctica cada uno de los temas que vayamos viendo.

Por otro lado, también voy a dar algunas cuestiones un poco más técnicas relacionadas a arquitectura, atributos de calidad y diseño de alto nivel, principalmente porque no hay ninguna otra materia en la que se vean.

Finalmente hay una serie de temas complementarios que quiero dar como ser:

  • Modelos de calidad (CMMI, ISO, etc)
  • Administración de servicios de sofware
  • Emprendedurismo
  • Desarrollo Open source

Para todos estos temas complentarios y también para algunos de los temas principales, pienso convocar a algunos profesores invitados. En particular quiero invitar a gente de la industria a contar como llevan a la práctica las cuestiones que vamos a estudiar en la materia. Y para esto mi idea es traer representantes de empresas de distintos tamaños:

  • Un pequeño emprendimiento (entre 3 y 8 personas)
  • Un empresa mediadiana (unos 200 empleados)
  • Una empresa grande/multinacional (más de 500 empleados)

Bien, creo que esto es todo por el momento. A medida que se me vayan ocurriendo más cosas las iré publicando.

Software, Hardware y Peopleware

(parte 2 de la serie: Ingeniería de Software en UNQ)

Como ya mencioné en una entrada anterior, durante la segunda mitad de este año voy a dictar ingeniería de software en UNQ. Esto me ha llevado a plantearme explícitamente mi visión de esta disciplina.

Estoy absolutamente convencido que la ingeniería de software es una disciplina con un gran contenido social/humano más allá del contenido técnico. Si bien seguramente haya gente desarrollando software en «forma aislada», creo que no es lo más común, en general el software se desarrolla en equipos de personas. En forma más o menos directa el software es utilizado por personas. Y aunque no suene muy lindo, podríamos decir que la materia prima del software son las ideas/experiencias de las personas que participan en el proceso de construcción.

Del párrafo anterior se desprenden algunos corolarios.

El trabajo en equipo requiere de ciertas habilidades «blandas» que en determinados contextos pasan a ser incluso más relevantes que las habilidades «duras o técnicas».

Puede que las personas sean más importantes de lo que parece a simple vista. Y ya que hablamos de las personas no puedo dejar de recomendar este sorprendente video sobre motivación.

No estoy solo en esta posición, pues de hecho no la «invité» yo sino que la «escuche» de Tom De Marco y Fred Brooks y he tenido la posibilidad de confirmarla día a día en los años que llevo trabajando tanto en la industria.

Por último repito la frase que puse en mi página personal

Estoy absolutamente convencido de que el principal factor para el éxito de los proyectos no es ni el software ni el hardware, sino el peopleware, y es por eso que adhiero fervientemente al manifiesto ágil.

continuará…

Sobre el inicio de los proyectos

Si analizamos como surge un proyecto de desarrollo de software, nos encontraremos que la motivación principal es una necesidad de una organización. Puede que el resultado del proyecto represente una mejora directa al negocio o bien que permita soportar al negocio de una forma más «óptima».

Yendo un paso más allá nos encontraremos que previo al inicio del proyecto y antes que el mismo sea concebido como tal, debería hacerse un análisis para determinar si vale la pena o no hacer el proyecto.  Como desarrolladores muchas veces pasamos por alto este hecho ya que generalmente somos convocados cuando la decisión de hacer el proyecto ha sido tomada. El análisis de si debe o hacerse el proyecto suele conocerse como «caso de negocio» (Business case) y debería contemplar minimamente las siguientes cuestiones: descripción del proyecto, objetivos, alineamiento con la estrategia del negocio, impacto en la operaciones, costos, beneficios y riesgos.

Una vez presentado el caso de negocio y decidido que se avanzará con la ejecución del proyecto se procede a iniciar el mismo. Independientemente del tipo de proyecto y el proceso de desarrollo a utilizar, absolutamente todo proyecto debe comenzar con un documento de visión y alcance que deje en claro para todos los involucrados el porque del proyecto y a grandes rasgos cual es la funcionalidad que se espera del mismo. En algunos casos dependiendo de las características del proyecto es conveniente tener documentado en forma separada la visión y el alcance, pero independientemente de ello es necesario para poder comenzar con el proyecto que todos los involucrados tengan en claro los siguientes puntos:

  • Objetivos del proyecto
  • Beneficios para el negocio que traerá el proyecto
  • Quienes son los involucrados en el proyecto detallando al menos: sponsor, usuarios clave, experto de negocio y líder del proyecto
  • Relación del proyecto con otros proyectos
  • Alcance esperado de la solución a implementar
  • Plan de alto nivel con principales hitos y entregables

Toda esta información es lo que suele volcarse en el documento de visión y alcance. Adicionalmente dicho documento también contiene la lista de riesgos del proyecto.

continuará….