El Blog de Pablo Fernando Sanchez

Esta es mi bitácora personal, en la cual trato, sin limitarme a ello, sobre ingeniería de software, ingeniería de sistemas, gestión estratégica, modelado de procesos, metodología, aseguramiento de la calidad, gestión del conocimiento y todos esos asuntos que hacen, desde la gerencia y la técnica, a las empresas que asesoro.

Herramientas

KPI Dashboard

Blogs Amigos

En Otros Blogs

Estas son algunas entradas en otros blogs inscriptos en Bitacoras.com en las cuales me citan:
Mostrando las entradas con la etiqueta Desarrollo de Software. Mostrar todas las entradas

Luego de haber respondido a algunas preguntas que planteó Ángel en esta entrada en la que conté acerca de RCL, el proyecto del IEEE que busca desarrollar un lenguaje estándar para la captura de requerimientos bajo el código IEEE P1805™, y habiendo recabado más información, escribo esta entrada para ampliar el asunto.

Ampliemos. El propósito del resultado final de este proyecto de estandarización, la mencionada guía estándar "Guide for Requirements Capture Language (RCL)", es:

  • Definir un nuevo lenguaje, el mencionado RCL, para la captura de requerimientos de TI.
  • Facilitar la estimación automática del tamaño de los requerimientos luego de finalizada su captura mediante el empleo de la técnica de Puntos de Función.
  • Mostrar que la captura de los requerimientos basada en una estructura de árbol es lo que mejor se ajusta a la captura de requerimientos de TI debido a que está más cerca a cómo se estructura el mundo que nos rodea —es por ello que se necesita un nuevo lenguaje.
  • Estandarizar la estructura de árbol de tal forma que sea compatible con Puntos de Función, es decir, que sea posible aplicar la técnica de Puntos de Función sobre los elementos del árbol una vez finalizada la captura de los requerimientos.
  • Permitir la captura de requerimientos tanto funcionales como no funcionales dentro de la estructura del lenguaje.
  • Permitir la captura de la dinámica del sistema, como eventos y lógica, dentro del mismo árbol.
  • Permitir un análisis rápido de impacto para así poder tomar decisiones inmediata y correctamente.
  • Permitir el versionado de requerimientos a medida que la captura vaya progresando por su cuenta como una estructura de árbol.
  • Permitir la traducción de RCL a otros estándares como diagramas UML.
  • Asegurar que este árbol de requerimientos sea "a prueba del futuro" en la medida en que se pueda mejorar fácilmente mediante la posterior inclusión de nuevas capturas de requerimientos, tanto por la evolución propia del sistema como por la ampliación del alcance, hasta llegar a cubrir la totalidad de la organización o empresa —con requerimientos que no sean de TI además de los de TI.

O sea, en un futuro se espera que el lenguaje evolucione hacia un nivel estratégico para que sea capaz de capturar desde la misión del negocio, las oportunidades y las amenazas, las decisiones, la visión, las jerarquías entre la gente, los sitemas de TI —que es el alcance actual—, los procesos manuales, eventos y todo otro requerimiento que posiblemente pueda surgir dentro de la organización.

Ángel también me preguntó sobre la fecha en que este estándar estará disponible. Contesté que "seguirá el camino estandarizado del proceso de estandarización del IEEE, valga la redundancia. Esto es que posiblemente haya un borrador el año entrante, algunas evoluciones y una liberación definitiva para 2012. En estos días voy a escribir sobre dicho proceso, para que quede más claro el por qué de los tiempos".

Los mantendré al tanto, a la vez que pronto escribiré sobre el citado proceso de estandarización del IEEE.

Sí señoras y señores, nuevamente The Institute of Electrical and Electronics Engineers (el IEEE) en la coordinación de un proyecto que, sin lugar a dudas, nos terminará dando una herramienta más que necesaria para quienes estamos de alguna forma en la industria del software.

Resulta que la IEEE Standards Association aprobó que se comience a trabajar en el proyecto IEEE P1805™, "Guide for Requirements Capture Language (RCL)" —o "Guía para Lenguaje de Captura de Requerimientos". Dicho proyecto cuenta con el patrocinio del Software & Systems Engineering Standards Committee (S2ESC) de la IEEE Computer Society. Su intención es que, cuando el proyecto sea finalmente liberado como estándar, ayude a facilitar la estimación automática del tamaño del software.

RCL es un concepto novedoso que apunta a proveer un medio efectivo para trasferir la perspectiva de negocios a los equipos que trabajan del lado tecnológico del desarrollo. Una vez completa, la guía aplicará para escenarios en los que se necesite:

  • capturar requerimientos de TI para la creación o el mantenimiento de sistemas basados en software;
  • transferir la perspectiva de negocios en forma rápida, fluida, completa y clara entre los grupos de negocios y los departamentos y/o empresas de servicios de TI; y
  • establecer en forma automática el tamaño de los requerimientos de TI una vez concluida su captura, empleando la técnica de Puntos de Función y, en consecuencia, permitiendo agilidad en los procesos de estimación de tamaño y esfuerzo al comienzo del ciclo de vida.

La información correspondiente a RCL será presentada en una estructura de árbol, la cual se ajustará a las necesidades de los requerimientos de TI mejor que los otros sistemas empleados en la actualidad.

Al margen de la noticia, creo que es interesante pues permitiría romper con algunas de las críticas típicas que se le hacen a las técnicas de estimación como la de Puntos de Función, la cual por el momento es especialmente adecuada para desarrollos de gran envergadura y empleando métodos conducidos por plan, como ser que:

  • requiera una dedicación adicional en los proyectos de desarrollo de software,
  • resulte arduo formar al personal en su utilización,
  • resulte arduo mantener unos criterios homogéneos de recuento,
  • carezca de precisión cuando se trata de proyectos pequeños,
  • resulte muy costoso tener recontada la mayor parte de la base instalada de la organización o
  • el factor de ajuste calculado a partir de las características generales del sistema resulte de dudosa utilidad, entre otras.

Si vemos estas críticas y las contrastamos con la idea de contar con un estándar real, formalizado y con el consenso de la industria, como será RCL, creo que podríamos ir superándolas, así como extender la aplicación de este estándar a un rango metodológico superior. Ya veremos en sucesivos avances cuánto podremos abarcar de dicho espectro con este estándar.

Ya escribí en este blog sobre extender los modelos que nos dan ejemplos de procesos y prácticas a nivel organizacional, como el CMMI, con modelos de un nivel más bajo que provean detalles específicos para los desarrolladores de software y los equipos que ellos integran, y creo que RCL es un caso de muy bajo nivel que podría aplicarse a dicho planteo.

En estos días estuve hablando ante algunos colegas sobre el SWEBOK y los métodos ágiles, comentando sobre los próximos cambios en la Guía. Aprovecho, entonces, para traducir y adaptar esta noticia de IEEE Computer Society que descuento será especialmente interesante para los lectores de mi blog.

Tal parece que algunos voluntarios están llevando adelante el proyecto de refresco de la Guía al Cuerpo de Conocimiento de Ingeniería de Software o Guide to the Software Engineering Body of Knowledge (SWEBOK), agregando nuevas áreas de conocimiento y revisando otras para alinear la guía con los planes de estudio actuales y las prácticas de la industria.

Este refresco, cuya liberación está prevista para mediados del año entrante, buscará alinear en forma más estrecha a la Guía al SWEBOK con los programas de certificación de IEEE Computer Society, además de definir a la Ingeniería de Software como profesión y ayudar a minimizar la brecha entre la industria y la academia.

Lo que IEEE Computer Society pretende con esta actualización es claro. Al respecto, Jim Moore, Ingeniero Principal en MITRE Corporation y Vice Presidente de Actividades Profesionales de la Sociedad, palabras más, palabras menos, manifestó:

“La creación de una única definición oficial del alcance de la Ingeniería de Software, facilitará que los empleadores ajusten sus expectativas, que los desarrolladores cumplan con esas expectativas y que las universidades preparen a sus graduados para las mismas.”
Pierre Bourque, co-editor de la versión 2010 de la Guía al SWEBOK, así como de las dos versiones previas, dijo que este refresco es esencial para mantener la utilidad del documento. Bourque, Profesor Asociado y Director de Programa del Master en Ingeniería de Software de la École de Technologie Supérieure de la Université du Québec, Canadá, dijo:

“Mantener la Guía al SWEBOK actualizada con las prácticas de la industria es esencial para garantizar que sigue siendo pertinente y utilizada por todas las partes interesadas. La Guía al SWEBOK desempeña actualmente un papel destacado en la maduración de la Ingeniería de Software como una disciplina legítima y una profesión reconocida en todo el mundo.”

La actualización fue aprobada por el Comité de Prácticas Profesionales de IEEE Computer Society en 2008. Puntualmente, algunos de los cambios aceptados por el momento son:

  • agregado de una nueva área de conocimiento o knowledge area (KA) sobre “Práctica Profesional”;
  • agregado de cuatro nuevas KAs de educación: “Fundamentos de Economía Ingenieril”, “Fundamentos de Computación”, “Fundamentos Matemáticos” y “Fundamentos de Ingeniería”, todas ellas procedentes de los lineamientos de 2004 para programas de grado en Ingeniería de Software;
  • remoción de tres disciplinas relacionadas: “Ciencias de la Computación”, “Matemática” y “Ergonomía del Software” —obviadas por otros cambios—;
  • agregado material sobre Interfaces Humano-Computadora en las KAs de “Diseño de Software” y “Prueba de Software”;
  • remoción de la sección de “Herramientas de Software” del KA de “Herramientas y Métodos de Ingeniería de Software” para distribuir su contenido en otras KAs;
  • renombrado del KA de “Métodos de Ingeniería de Software” para enfocarse en los métodos que afectan a más de una KA; y
  • redistribución de otros ítems en diferentes KAs.

El SWEBOK cubre conocimientos generalmente aceptados sobre Ingeniería de Software. Sus 10 áreas de conocimiento resumen los conceptos básicos e incluyen una lista de referencia que apunta a la información detallada. Como conclusión de la Guía al SWEBOK de 2004, los miembros del equipo SWEBOK 2010 recibieron y respondieron a casi 10.000 comentarios de más de 500 revisores en 42 países. La Guía al SWEBOK es también reconocida como un Informe Técnico de la ISO. La transparencia y el consenso son valores esenciales para su desarrollo. Este otoño boreal, IEEE Computer Society buscará voluntarios de todo el mundo para revisar los cambios y adiciones incorporadas a la versión 2010.

El esfuerzo está siendo liderado por cinco co-editores voluntarios, incluyendo a:

  • Bourque,
  • Alain Abran, Profesor y Director del Laboratorio de Investigación en Ingeniería de Software de la École de Technologie Supérieure de la Université du Québec,
  • Juan Garbajosa, Profesor de Ingeniería de Software en la Escuela de Informática de la Universidad Politécnica de Madrid,
  • Gargi Keeni, Vice Presidente de Tata Consultancy Services y miembro del Advisory Board de la revista IEEE Software, y
  • Beijun Shen, Profesor Asociado de la Universidad Shanghai Jiaotong.

En este interesante artículo, Xavier Albaladejo plantea una serie de métricas aplicables a proyectos basados en Scrum y sugiere su inclusión en lo que denomina Agile Balanced Scorecard, que interpreto como una extensión del típico Balanced Scorecard (BSC), Cuadro de Mando Integral o Tablero de Comando, de cuya aplicación en sistemas ya he escrito en este espacio. Aunque escribí dicho artículo doble hace un par de años, lo comparto porque estimo puede ser útil para apoyar la mención de esta técnica en el marco de proyectos ágiles.

En tal contexto, creo importante indicar que el Balanced Scorecard, como filosofía práctica de gerencia, puede emplearse en todos los niveles de gerencia, incluso en equipos auto gestionados o en modelos de gestión individual.

Mi recomendación es desplegar el BSC a nivel individual, uno por persona, pero todo depende de cuán abierta sea la política empresarial en cuanto al modelo gerencial y las posibilidades de acceso a la información estratégica por parte de los integrantes de la organización que de dicha política se desprende.

Me llegó una invitación para participar en este encuentro, del cual posiblemente participe después de organizar un par de temas personales. Me pareció interesante, por lo cual cumplo en compartir el mismo con la comunidad.

En este mes de noviembre de 2008 se está realizando la 6ª edición de la WhyFLOSS Conference, con entrada libre y gratuita y con certificados de asistencia y ponencia. Un evento internacional organizado por Neurowork que se realiza en Argentina y España y que esta vez se realizará por primera vez en la ciudad de La Plata, Provincia de Buenos Aires, Argentina. Otras ciudades dónde se realizó el evento son, por ejemplo, Buenos Aires y Madrid.

Con un importante apoyo de la Universidad Tecnológica Nacional, Facultad Regional La Plata, se presentarán conferencias variadas en torno a las tecnologías abiertas de TI.

Se encuentra abierta la convocatoria a propuestas de ponencias, la inscripción en línea gratuita y también el patrocinio.

Cualquier consulta contactarse por correo electrónico a conference@whyfloss.com.

En este artículo de InfoQ se habla sobre el debate que se ha venido dando en los últimos tiempos en miras de intentar comprender el significado del apoyo de Microsoft al Lenguaje Unificado de Modelado —o Unified Modeling Language (UML). ¿Estará Microsoft dejando de lado los Lenguajes Específicos del Dominio —o Domain Specific Languages (DSL)— o tomarán a UML y DSL en forma complementaria? ¿UML se está convirtiendo más en una notación que en un lenguaje?

Para seguir discutiendo, como corresponde... :)

Ed Yourdon está dando la interesante charla “User Reactions to XP/Agile Development” esta noche en Moscú, ciudad capital de la Federación Rusa. Para quienes no podemos estar presentes, Yourdon puso a disposición de la comunidad el archivo PDF con la presentación que usará en dicho evento —pesa unos 2,7 MiB— y podemos descargarla desde este enlace.

Al margen, cabe que destaque algo que no recuerdo haber mencionado públicamente, pero que creo justo expresar: mi agradecimiento a Ed Yourdon. Ocurre que la primera guía que he tenido hacia una visión metodológica de los sistemas de información en mis primeros años de estudiante universitario fue un libro de Yourdon: “Modern Structured Analysis”. Se trataba de análisis estructurado, por supuesto, y es uno de esos libros que uno tiende a atesorar más allá de si hoy en día lo aplique o no. Lo cierto es que partir de la lectura de dicho libro hubo un cambio favorable y muy importante en mi vida profesional —este enfoque fue definitorio para la evolución de la ingeniería de software como la conocemos en la actualidad. Entonces, una y mil veces, ¡gracias Ed!

Desde este enlace al sitio web de Expértika ya se puede acceder a la presentación en línea correspondiente a la charla introductoria «Mejora de Procesos para Desarrollar Software Mejor» que, tal como anuncié en este mismo espacio, tuve el gusto de brindar ayer 28 de junio de 2007 en el Auditorio Menor de la Sede Bucaramanga de la Universidad Cooperativa de Colombia (UCC), en el marco de las actividades de SPIN Colombia.

En general, todo salió bastante bien, a pesar que un partido de fútbol entre las selecciones Colombia y Paraguay jugado a la misma hora que la charla provocó que la asistencia no fuera la esperada. De todas formas, fue importante para comenzar a difundir y planear los siguientes pasos para activar la SPIN en la ciudad colombiana de Bucaramanga y su área metropolitana.

Esta semana entrante daré una charla gratuita en el marco de las actividades de SPIN Colombia en la ciudad de Bucaramanga, Departamento de Santander, Colombia.

En resumidas cuentas, SPIN —siglas que corresponden a «Software and Systems Process Improvement Network»— es una red de empresas, universidades y profesionales que trabajan en pro del mejoramiento de procesos en ingenierías de software y de sistemas, apoyados por el Software Engineering Institute (SEI) de la Carnegie-Mellon University (CMU) y otros grupos de la SPIN alrededor del mundo.

Por tal motivo, a partir del presente mes de junio de 2007, se realizarán en Bucaramanga una serie de conferencias mensuales gratuitas para toda la comunidad, que garantizarán contacto permanente con un gran número de expertos en el tema, el intercambio de ideas, información y soporte mutuo en tópicos referentes al mejoramiento de procesos y las ingenierías de software y de sistemas.

En este primer evento de la serie, tendré el gusto de brindar una charla titulada «Mejora de Proceso para Desarrollar Software Mejor», que no abarcará otra cosa que una introducción a la mejora de procesos de software y a la SPIN.

Este evento se realizará el próximo día jueves 28 de junio de 2007 a las 19:00 horas en el Auditorio Menor de la Universidad Cooperativa de Colombia (UCC), Sede Bucaramanga, Calle 30A #33-51, piso 8.

El cupo es limitado, por lo cual sugiero llegar a tiempo para no quedarse afuera. Por información adicional pueden dirigirse al correo electrónico anacevedo@cidlisuis.org.

El modelo ha sido bastante difundido en los últimos años. Básicamente, la práctica conocida como offshoring se basa en la reubicación de procesos de negocio —tales como producción, manufactura o servicios— de un país a otro. Hay varios elementos que lo refuerzan en relación con la industria del software, como la diferencia de costos en la producción de software en los diferentes países, la imposibilidad de algunos países de autosatisfacer la demanda de software, etcétera. En parte por ello es que los países cuyos mercados necesitan adquirir este tipo de servicios a empresas de otros países, promueven la certificación o evaluación en modelos —como el Capability Maturity Model Integration (CMMI)— a empresas de estos otros países para que puedan proveer algún tipo de garantía en los procesos de producción —¿o creías que era de buenos nomás?

Sin embargo y más allá de cualquier certificación y/o evaluación, debemos hacer las cosas bien. Resulta que me han llegado algunos comentarios, uno de ellos de alguien que estuvo allí, sobre una charla titulada «Extreme Programming (XP) and Productivity Measures — What the Numbers Say» que dio Michael Mah y fue organizada por el grupo de la Software Process Improvement Network (SPIN) de la ciudad de New York. Para quien no sepa quién es, Mah es un referente en materia de Ingeniería de Software que mantiene su propio blog, Optimal Friction, y está al frente de QSM Associates.

En esta charla y entre otras cosas, Mah manifestó, tal como nos confirma el propio Ed Yourdon, que la enorme base de datos de proyectos que su empresa mantiene arroja un resultado preocupante: los desarrollos contratados off-shore poseen una tasa de defectos de 2,8x —¡un 280%!— con respecto al promedio. Casi nada, considerando que esta base de datos contiene información sobre 7.300 proyectos que representan unas 685 millones de líneas de codígo (LOCs), de 500 empresas en 18 países y escritas en 600 lenguajes de programación distintos.

Por supuesto, toda estadística tiene un margen de error, pero de todas formas este resultado es preocupante, tanto para el mercado que compra este tipo de servicios como para la industria mundial que los vende —o que pretende venderlos.

Entonces... ¿qué hacemos? ¿Seguimos cumpliendo como podemos los requisitos que tenemos que cumplir según normas, modelos, etcétera, o además hacemos lo que es bueno para el proceso de desarrollo? Sí, señores, no se trata sólo de certificarse y/o evaluarse en modelos —lo cual es necesario, no lo dudo—, sino pensar en lo que estamos haciendo y hacerlo mejor, empleando también modelos de bajo nivel y estándares, sin eludir responsabilidades para reducir costos, respetando a la gente, siendo éticos, sin «fabricar» evidencias y haciendo lo que se debe hacer para producir software. Les aseguro que funciona y da beneficios de todo tipo. Es más difícil, no es para cualquiera, pero funciona...

Así se traduce el nombre de un modelo que Jim Heumann para IBM/Rational desarrolló en 2003, Requirements Management Maturity (RMM), y que Scott Sehlhorst yuxtapone y compara en Tyner Blain con el Capability Maturity Model Integration (CMMI).

Esta comparación es lógica, pues también se trata de un modelo de cinco niveles —aunque no hay una relación paralela entre un mismo nivel para ambos modelos—, los cuales son:

  • RMM Nivel 1: Requerimientos Escritos.
  • RMM Nivel 2: Requerimientos Organizados.
  • RMM Nivel 3: Requerimientos Estructurados.
  • RMM Nivel 4: Requerimientos Trazados.
  • RMM Nivel 5: Requerimientos Integrados.
Aclaro que no cuento la indefinición como nivel, aunque el modelo lo menciona.

Además, RMM también promete cubrir los aspectos relacionados con la gestión de los requerimientos necesarios para evaluarse, al menos, en los primeros tres niveles de CMMI, por lo cual considero interesante su análisis por parte de las empresas para emplearlo como modelo de bajo nivel y complementar al CMMI.

El documento completo en inglés, de título «The Five Levels of Requirements Management Maturity», puede descargarse desde el sitio de IBM.

Según el Software Engineering Institute (SEI) de la Carnegie Mellon University (CMU), la transición a la versión 1.2 del Capability Maturity Model Integration (CMMI) fue un reto mayor debido al significativo aumento en usuarios y aliados en comparación con la anterior transición entre las versiones 1.0 y 1.1. Así lo indica Mike Phillips, Director de Proyectos Especiales del SEI y encargado de liderar el proyecto CMMI, en su interesante artículo «CMMI: A New Transition», publicado en la columna CMMI in Focus de la edición de enero de 2007 de News@SEI. Por supuesto, el artículo está en inglés.

Tal como menciona Phillips, la versión 1.2 incluye varias modificaciones en todo el paquete de productos CMMI para hacer esta herramienta de mejora de procesos más útil y aumentar la confianza en los resultados de la mejora de procesos basada en CMMI.

Por último, recuerda que los períodos de transición siempre presentan retos conocidos e inesperados, ante lo cual agradece personalmente a la comunidad de aliados y usuarios de CMMI por la ayuda para hacer esta transición lo más rápida y efectiva posible.

Hace tiempo me preguntaron sobre los estándares que The Institute of Electrical and Electronics Engineers (IEEE) ha desarrollado en torno a la disciplina Ingeniería de Software, por lo cual aprovecho este espacio para responder.

Primero, cabe una aclaración. El IEEE desarrolla sus estándares a través de una de sus entidades, la IEEE Standards Association (IEEE-SA). Asimismo, este desarrollo se potencia mediante otras entidades técnicas abarcadas por el Instituto. En el caso puntual de este conjunto de estándares, estas entidades técnicas son la IEEE Computer Society (IEEE-CS) y el IEEE Technical Council on Software Engineering (TCSE), las cuales participan de esta actividad mediante un comité: el Software & Systems Engineering Standards Committee (S2ESC).

Lo mencionado es desde lo institucional relacionado directamente con el IEEE. Sin embargo, no debemos olvidar que en el desarrollo de estos estándares también participan organizaciones de todo tipo, como empresas del sector privado, universidades, otras organizaciones no gubernamentales y gobierno. He hablado sobre el procedimiento completo y cómo participar de estas actividades en alguna que otra de mis charlas en los diferentes eventos de los cuales he participado.

Este conjunto de estándares abarcan todos los aspectos técnicos relacionados con la Ingeniería de Software. Son un excelente complemento para modelos de alto nivel como el Capability Maturity Model Integration (CMMI) aunque, por supuesto, deben ser interpretados y adaptados a las necesidades particulares de cada organización para sacarles el máximo provecho.

Ahora bien, para quien desee tener un listado completo de este conjunto de estándares, siempre actualizado a la fecha con sus respectivos estados, puede acceder mediante este enlace. Se trata sólo del listado con su estado y descripción, no del texto completo pues, como ocurre con la mayoría de los estándares, acceder a ellos tiene un costo —el cual es preferencial para los miembros del IEEE.

Desde que comencé con este blog me han venido preguntando sobre las comunidades virtuales que menciono en la barra lateral de este sitio o menciono cuando aplica en mis artículos. Es por ello que se me ocurrió publicar el siguiente listado de comunidades virtuales alineadas a la temática de este espacio y con las que, de alguna forma, tuve y/o tengo algo que ver:

Gestión y Gerencia (Management)

Ingeniería

Desarrollo

Bases de Datos

Aplicaciones

Espero que estas referencias les sean útiles. Cuentas con múltiples funcionalidades, como publicación de mensajes tipo foro, espacio para almacenamiento de archivos —en los que suele haber documentación relacionada con el tema que se trata—, álbumes de fotos, enlaces, encuestas, etcétera.
Si quieren recomendar alguna otra comunidad virtual, pueden hacerlo mediante comentarios a este artículo.

Permitiéndome copiar humildemente la costumbre de Mariano Amartino en el excelente Denker Über, uno de los blogs que leo, aunque sin pretender establecerlo como un hábito semanal —como en dicho caso— y tal vez siendo escueto, presento a continuación una serie de enlaces a artículos en blogs que me han resultado interesantes y que están relacionados con la temática del mío. Por lo general son blogs que tengo enlazados en mi agregador; entonces, les comparto mi índice:

Blog Widget by LinkWithin

Seguime

Suscribite al feed de mi blog Suscribite para recibir las actualizaciones de mi blog por correo electrónico Seguime en twitter

Seguidores

Etiquetas

Últimos Artículos

Herramientas

IBSN