Etiquetado: Ingeniería de software
Cierre de cuatrimestre en UNQ, tercera promoción
El lunes pasado tuvimos la última clase de Elementos de Ingeniería de Software la cual como de costumbre estuvo dedicada a la retrospectiva. Pero antes de entrar en las conclusiones de la retrospectiva, les comparto algunos números:
- Alumnos anotados: 8
- Alumnos aprobados: 7
- Alumnos pendientes de aprobación: 1
- Nota final promedio: 8,14
- Fueron un total de 27 clases
- Tuvimos la visita de un profesional de la industria (¡gracias Emilio!)
- Trabajamos exhaustivamente con Ruby, Sinatra y Cucumber
- Desarrollamos varias aplicaciones, las cuales publicamos en heroku y algunas incluso con dominio propio
Personalmente estoy muy conforme con como resultó el curso. A diferencia de cuatrimestres anteriores, puse mucho menos foco en cuestiones de arquitectura/diseño y más énfasis en cuestiones de análisis y especificación (Visual Story Mapping, BDD, etc).
- Mantener:
- Dinámica de las clases
- Lecturas
- Resumenes
- Herramientas
- Invitados
- Clase remota
- Probar/incrementar:
- Actividades de relación previas al comienzo de la clase
- Clases al aire libre
- Mejorar:
- La forma de feedback >> Action Item: ser más explicíto al setear expectativas de los entregables y ser más cuidados con el tono
Para cerrar el post, quiero agradecer a Natalia, una ex-alumna de la materia que colaboró conmigo durante todo el cuatrimestre.
Nota: el ícono representa una alumna que estuvo ausente el día de la retrospectiva.
Mi enfoque hacia la arquitectura de software
Cuando me tocó estudiar este tema formalmente como alumno, recuerdo que lo hice desde la perspectiva del proceso unificado. Luego por iniciativa propia estudié el tema desde otras perspectivas/fuentes. Pero creo que lo que realmente me hizo entender el tema fue poner manos a la obra. Con esto en mente, hace unos dias me senté a preparar mis clases sobre este tema para mi materia de UNQ. Revisé algunas fuentes tradicionales, notas personales y algunas fuentes más recientes y pensé algunos ejercicios para hacer con lo alumnos de cara a intentar bajar a concreto algunas cosas que pueden llegar a resultar abstractas.
Como mencioné en un post anterior, decidí encarar el tema presentando un problema, el cual nos fue guiando por los atributos de calidad hacia la arquitectura como disciplina. Luego en una segunda clase, vimos algunas definiciones formales y estilos de arquitectura con algunos ejemplos concretos razonando sobre código las implicancias de cada estilo. La tercer clase la decicamos a ver algunas técnicas concretas para atacar la definición de arquitectura de una aplicación. Finalmente en una cuarta clase, los alumnos realizaron presentaciones de ciertos estilos de arquitectura utilizando el mismo enfoque que habiamos utilizando previamente para presentar otros estilos.
Como material de estudio complementario a lo visto en clase elegí:
- El artículo An introduction to Software Architecture, de Garlan y Shaw
- El capítulo 3 de mi tesis de ingenieria, pues me pareció un buen resumen sobre atributos de calidad
- Los capítulo 3 y 4 de Applicacion Architecture Guide (v2) del equipo de Patterns and Practices de Microsoft
- El artículo Architectural Blueprints—The “4+1” View Model of Software Architecture de Philippe Kruchten
- El artículo Who need architects? de Martin Fowler
En algunas clases posteriores volveremos sobre algunas temas de arquitectura (por ejemplo para analizarla en el contexto de distintas metodologias de desarrollo), pero ya como cuestión colateral y no como tema central de una clase.
Nueva edición del curso de Ingeniería de Software de Berkeley
Hoy comienza una nueva edición del curso online de Berkely sobre el que estuve escribiendo tiempo atras: Software Engineering for Software as a Service. En esta ocasiónvoy a ser parte del staff del curso: puntualmente voy a estar colaborando en los foros y en el armado de los exámenes. Para esta nueva edición hay varias mejoras: nuevos videos, más ejercicios y bug fixes entre otros.
Los interesados pueden inscribirse gratuitamente en https://class.coursera.org/saas.
Algunos números sobre el curso de Ingeniería de Software de Berkeley
Ayer recibí el mail con el certificado de haber completado el curso y junto con ello, algunos datos interesantes.
- Unos 20 mil estudiantes vieron al menos una de las clases.
- Unos 10 mil estudiantes intentaron resulver al menos un questionario o uno de los ejericios.
- Unos 3 mil quinientos estudiantes completaron el curso.
El curso se repetirá hacia mediados de mayo y una segunda parte cubriendo Rails avanzado, trabajo en equipos, código légacy, performance y seguridad será ofrecida hacia finales de octubre.
Sobre el curso de Ingeniería de Software de Berkeley
Hace un tiempo comenté que estaba tomando un curso online de la Universidad de Berkeley ofrecido en la plataforma online de la Universidad de Standford. Ayer rendí el último examen y lo completé.
El curso me gustó, aprendí algunas cosas y reforcé otras, pero debo decir que esperaba algo distinto. El título del curso era “Software Engineering for SaaS” , pero de SaaS se vió muy poco. Respecto a esto algunos alumnos opinaban que el hecho de usar Ruby/Rails ya cumplia con el contenido de SaaS. Yo personalmente no comparto, creo que Ruby/Rails es un solo un framework, muy productivo sin duda, pero que implementa patrones que han estado en uso por varios años como MVC y Active Record y que pueden o no usarse para hacer aplicaciones SaaS. Al mismo tiempo, temas como escalabilidad, que resultan muy relevantes en aplicaciones SaaS, apenas fueron mencionados.
Más allá de los contenidos, me gustó mucho la dinámica y tengo ganas de hacer algo similar ofreciendo parte del contenido de la materia que estoy dictando en UNQ.
Ingenieria de software: ¿existe tal cosa?
¡Que pregunta! Se podrán imaginar que siendo profesor de una materia con este nombre mi respuesta es sí.
Pero no todo el mundo piensa lo mismo. Una de las personas que cuestiona la existencia de dicha disciplina no es más ni menos que David Parnas, quien el pasado octubre publicó un artículo titulado: “Software Engineering – Missing in Action: A Personal Perspective”. En dicho artículo Parnas repasa brevemente el surgimiento del término ingeniería de software y expone ciertas razones por la cuales duda de que el desarrollo de software tenga el caracter de ingenieria. El artículo me resultó por demás interesante, ya que también toca a la pasada cuestiones como ingenieria vs. ciencia, la estructura de la profesión y la educación del profesional del software.
Sumando a este argumento, mi colega Gabriel Falcone me compartió hace un tiempo este video de la conferencia Scotland Ruby, donde disertante afirma:
“Software engineering as it is taught in universities simply does not work. It does not produce software systems of high quality, and it does not produce them for low cost. Sometimes, even when practiced rigorously, it does not produce systems at all. That is odd, because in every other field, the term engineering is reserved for methods that work.”
¡uffff! Duro, pero bastante realista. En realidad si uno mira el video completo (unos 45 minutos), se encuentra que en realidad el punto de este individuo es que lo que realmente funciona para construir software son los métodos ágiles y que mucha gente tilda a los métodos ágiles como “anti-ingenieriles”. A pesar de no compartir algunos de los puntos expuestos en este video, la sesión me gustó y la recomiendo (de hecho he sacado algunos bullets para mis clases).
Personalmente creo que existe la ingenieria de software como disciplina, pero con una concepción distinta a la que le dan muchas universidades (en general a nivel académico hay cierta “creencia” de que por llamarse ingenieria debe tener una fuerte carga de ciencia básica,cosa que no comparto). Al mismo tiempo creo que es aún una disciplina joven ya que las prácticas/métodos que aumentan la probalidad de éxito de los proyectos – y que por ende podrian poner a la ingenieria de software a la altura de las otras ingenierias- recien se han comenzado a popularizar en los últimos 5 años.
Planificando Ing. de Software 2012
En base a la experiencia del último cuatrimestre, el feedback de los alumnos y algunas ideas que vengo trabajando desde hace ya un tiempo, este primer cuatrimestre de 2012 viene con varios cambios.
En primer lugar voy a dar un enfoque más práctico, o sea, vamos a programar, aunque aún no decido si Java, Smalltalk o Ruby (creo que es algo que puedo dejar decidir a los alumnos).
En segundo lugar voy a hacer algunos cambios en la profundidad de los contenidos: más agile, más calidad/testing y menos UP. De hecho no quiero dedicar más de 3 clases a UP y posiblemente algún trabajo individual (un questionario posiblemente).
En tercer lugar, pero no por ello menos importante, voy a dictar la materia en forma iterativa. Esto es un tema que he hablado con colegas en reiteradas ocaciones: bien probado está que el desarrollo iterativo es una de las prácticas de ingeniería de software más aceptadas y utilizadas en la actualidad, pero sin embargo la ingeniería de software sigue enseñanadose en forma secuencial. Entonces mi idea es dividir la materia en iteraciones, entre 4 y 6. Cada una de ellas time-boxed, con un entregable concreto. En cada iteración veremos todas las actividades del proceso de desarrollo, profundizando un poco más en cada iteración, al final de cada iteración tendremos un entregable de valor.
La excepción será primer iteración, que será más corta y en la que nos centraremos (al igual que el cuatrimestre pasado) en entender las particularidades de la disciplina. El entregable de esta primer iteración será el setup del portfolio individual (en futuros post voy a desarrollar este punto).
Cada una de las siguientes iteraciones tendrá un ejecutable de código con sus correspondientes pruebas, algunas de las cuales serán especificadas como parte de la consigna y otras deberán ser diseñadas por los alumnos.
Adicionalmente a la entrega de final de iteración, tendremos también algunas entregas intermedias.
Otro de los cambios será la utilización de un build server para verificación de los entregables.
También tengo la intención de utilizar una plataforma virtual, la cual espero nos permita tener una mejor dinámica de intercambio en el curso. Ya realicé el pedido al departamento con lo cual solo me queda esperar que acepten la petición, pues en general la plataforma virtual está solo disponible para la materias de las carreras virtuales.
Otro agregado de color que pienso hacer el tema “ejercicio profesional”. Con este nombre pretendo englobar varios consejos para el desempeño profesional como por ejemplo: como armar un CV, como prepararse para una entrevista laboral, etc, etc.
Al mismo tiempo quiero mantener varias de las prácticas del cuatrimestre anterior como por ejemplo el envio de mail de resumen después de cada clase, la planificación y estimación de las tareas por parte de los alumnos y visibilidad contínua sobre las asistencia a clase. Este última práctica tiene que ver con que si un alumno piensa faltar a clase, debe comunicarlo previamente, el obejtivo de esto es que se acostumbren a dar visiblidad a su equipo. También voy a repetir la experiencia de invitar a profesionales de la industria a contar sus experiencias (para este cuatrimestre ya tengo el compromiso de Manuel Trejo de Kinetia)
Por último estoy evaluando distintas alternativas tecnológicas para intentar grabar las clases, pero no estoy seguro que pueda implementar esto.
Si algún futuro alumno lee esto puede que se pregunte ¿pero cuanto voy a tener que trabajar para aprobar esta materia? Recuerdo que una vez un profesor me dijo que para hacer una carrera univesitaria hay que dedicar al menos la misma cantidad de horas de estudio que la cantidad de horas de clase. Yo no creo que para esta materia sea necesario tanto. Considerando que tenemos entre aproximadamente 5 horas netas de clase, estimo que con dedicar unas 3 horas semanales extra clase, deberia ser suficiente. Pero ojo, hablo de 3 horas netas, podes parate para ir al baño, tomar un vaso de agua o preparar el mate, pero nada de mail, ni chat, ni SMS, ni facebook, son 3 horas estudio posta.
Las clases empiezan en dos semanas y tengo muchas expectativas. Ya les iré contando más a medida que avance.
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:
- How to Misuse Code Coverage por Brian Marrick, lindo artículo sobre el tema escrito por uno de los firmantes del manifiesto ágil.
- Code Coverage Analysis, por Steve Cornett, artículo bastante completo, con bastante teoría sobre el tema
- Testivus on Test Coverage, del blog de Google Test, cuentito muy ilustrativo los criterios de Code Coverage
En el siguiente post voy hacer algunos comentarios sobre estos artículos.

