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 Industria del 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.

A continuación, comparto con todos ustedes una gacetilla de prensa que me llegó haciendo referencia a la charla que Richard Stallman brindará el próximo martes 25 de agosto en el Teatro Presidente Alvear:

Charla Abierta y Gratuita Pre-Wikimanía 2009 en Buenos Aires

Wikimedia Argentina, el capítulo local de la Fundación Wikimedia, invita a la charla abierta y gratuita que ofrecerá Richard Stallman, el padre del movimiento de Software Libre, a realizarse en el Teatro Presidente Alvear, Avenida Corrientes 1659, el martes 25 de agosto desde las 12:00 horas.

Stallman llega a Argentina para participar de la 5ª Conferencia Internacional de los Proyectos de Wikimedia (Wikimanía 2009), que tendrá lugar entre el 26 y 28 de agosto en el Centro Cultural General San Martín de la Ciudad de Buenos Aires. En este marco, Stallman ofrecerá esta charla abierta y gratuita para todo público, en particular para todos aquellos interesados en conocer la cultura que dio origen al movimiento copyleft, su fundación, sus bases filosóficas, y los principios que reúnen al movimiento de software libre, programas de computadora que se pueden usar con cualquier propósito, estudiar, adaptar a las propias necesidades, copiar y distribuir las copias, incluso las versiones mejoradas.

Este movimiento que comenzó con Stallman a mediados de la década del 80, se ha extendido a otros campos de la cultura. Justamente este concepto de copyleft, y las licencias de libre distribución de obras culturales son la base de la enciclopedia libre Wikipedia, y de todos los proyectos que alberga hoy la Fundación Wikimedia.

Este evento es posible gracias a la gentileza del Complejo Teatral de Buenos Aires y el Gobierno de la Ciudad que cedieron las instalaciones del Teatro Presidente Alvear, y el apoyo de organizaciones de la comunidad de cultura libre local como Fundación Vía Libre, Buenos Aires Libre, Colectivo La Tribu, CaFeLUG (Grupo de usuarios de software libre de Capital Federal) y RedPanal, que promete un cierre con músicos en escena.

Más información en www.wikimedia.org.ar y en los sitios de las organizaciones amigas.

La idea de esta entrada en el blog es reunir alguna que otra ayuda audiovisual para aquellos que no tengan bien en claro esto de la Web 2.0. Aclaremos que no es ninguna novedad y que, incluso, hace tiempo que se está trabajando en la Web 3.0 y ya se está hablando de la Web 4.0. Sí, aún muchos de los usuarios de Internet no tienen arraigada la filosofía inherente a la Web 2.0 y ya está quedando en el pasado... Pero tiempo al tiempo, vamos paso a paso.

El video que sigue, titulado “Web 2.0: The Machine Is Us” —“Web 2.0: Nosotros Somos La Máquina”—, ha sido cedido gentilmente por Michael Wesch, Profesor de la Kansas State University, Estados Unidos de América, y subtitulado por Mario Nel Villamizar Ochoa, Comunicador Social, Blogger y Profesor de Nuevas Tecnologías en Colombia.



El siguiente es un cortometraje documental sobre los nuevos usos de la red basado en el libro blanco de la Publicidad 2.0, de Paul Beelen, con información adicional de varios artículos de Wikipedia en particular y de otros sitios web en general.



Ya hablaremos más en detalle de las generaciones que siguen, pero consideré importante tener una pequeña introducción para adentrarnos luego en la Web 3.0 —la web semántica— y 4.0 —el sistema operativo en la nube.

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.

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... :)

Jornadas Regionales de Software Libre 2008
Entre el 20 y el 22 de agosto de 2008 se llevarán a cabo las Jornadas Regionales de Software Libre 2008 en Buenos Aires, Argentina. Se trata de un evento regional, internacional e itinerante donde líderes y seguidores del software libre trabajan para integrar proyectos, lanzar nuevas ideas y superar los límites de los programas que utilizan.

Estas jornadas serán la octava edición del evento, están organizadas por CaFeLUG, el Grupo de Usuarios de Software Libre de Capital Federal y cuenta con el apoyo y participación de organizaciones afines.

Durante las jornadas se reunirán programadores, desarrolladores, estrategas, expertos en tecnologías, emprendedores involucrados en el software libre para intercambiar ideas, compartir técnicas, discutir y explorar tecnologías libres tales como Perl, MySQL, Java, PHP, Python, Linux, Apache y muchas otras.

Jornadas Regionales de Software Libre 2008

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!

Ayer jueves 26 de julio hemos tenido la segunda reunión ordinaria de la Software and Systems Process Improvement Network de Colombia (SPIN Colombia) en las instalaciones de la Sede Bucarica de la Universidad Industrial de Santander (UIS) en la ciudad de Bucaramanga, Departamento de Santander.

En la misma se desarrolló un panel en torno al modelado de procesos que, inevitablemente, nos llevó a discutir sobre el Capability Maturity Model Integration (CMMI) y en particular sus áreas de proceso relacionadas directamente con la mejora de procesos:

  • OPF u Organizational Process Focus (nivel 3).
  • OPD u Organizational Process Definition (nivel 3) y su nueva denominación para CMMI versión 1.2: OPD +IPPD u Organizational Process Definition +IPPD.
  • OT u Organizational Training (nivel 3).
  • OPP u Organizational Process Performance (nivel 4).
  • OID u Organizational Innovation and Deployment (nivel 5).
Se mencionaron también los cambios que afectan en forma directa a las áreas de proceso de mejora de procesos ante el salto de versiones del CMMI desde la 1.1 a la 1.2.

Asimismo, se discutió sobre el grado de interacción entre CMMI e ISO 9001, además de sugerirse caminos a seguir en torno a la implementación de estos modelos en las distintas organizaciones.

Pueden acercarse a SPIN Colombia accediendo a nuestro blog y a nuestra wiki. Además, pueden consultar por correo electrónico sobre cómo ser miembro de nuestra red, cosa que pueden hacer los profesionales practicantes, empresas, organizaciones técnico-profesionales y comerciales, instituciones académicas, docentes y estudiantes.

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...

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.

Seguro que el lector experimentado en la industria del software no necesita que se lo mencione, pero lo hago de todas formas para quienes no estén concientes del asunto: el viejo adagio que, refiriéndose a los posibles clientes de nuestro producto software, versa «constrúyelo y vendrán» es una completa falacia. Muchas veces, la gente de abstracción técnica fascinada por, precisamente, los retos, logros y demás cuestiones estrictamente ingenieriles, ni siquiera piensan en el resto o simplemente lo toman como un mal necesario menor en lo cual ocuparse «luego».

Pues... la experiencia dice otra cosa muy distinta. En lo personal y habiéndolo discutido miles de veces con empresarios del software, creo que el esfuerzo de construir software —escribir el código y hacerlo funcionar— es tal vez de entre un 15% y un 20% del esfuerzo requerido para tener un producto software exitoso. Las actividades de investigación, planeación, diseño, pruebas, mercadeo —o marketing— y comunicación son, en gran medida, aquellas a las cuales se debe dirigir la mayor parte del esfuerzo. Piensa «fuera de la caja». Piensa en el usuario y no sólo en la tecnología. Lo que te diferenciará, en definitiva, será proveer más que sólo una pieza de software.

Reconozcámoslo... no siempre se gana el mercado el mejor bolígrafo, sino que es el bolígrafo mejor mercadeado el que lo gana. Escribir el producto software es una parte muy pequeña de la batalla. El negocio, en realidad, es sobre mercadear y vender. Todos hemos visto pésimos productos software, repletos de defectos de todo tipo, siendo mundialmente reconocidos y haciendo toneladas de dinero, mientras que productos software técnicamente avanzados se pierden en el olvido porque la empresa simplemente asume que el producto es tan bueno que se venderá sólo.

En particular, el mercadeo debe ser visto como una actividad constante de tiempo completo, ya sea en línea, fuera de línea, a través de revendedores, correo directo, avisos publicitarios impresos, en línea, en Google, etcétera. El mercadeo, como sucesión de prueba y error, termina constituyendo la diferenciación en tu producto software mediante la construcción de la marca, marca que tienes que amar. Finalmente, lo que harás incansablemente para vender tu producto software al resto será vender tu marca al resto.

Sólo si tienes suerte y tienes el próximo YouTube o Digg, la gente instintiva y multitudinariamente se referirá a tu marca. Pero lo cierto es que la enorme mayoría no lo logra de esta manera, por lo cual hay que trabajar duro para conseguir una cantidad tal de clientes que te dé la suficiente cantidad de dinero para mantener tu negocio operando.

Tómate el tiempo de hacer un listado de tus competidores y sus productos. Para cada uno, considera datos básicos como precio, modelo de licenciamiento, una impresión superficial de su calidad —esa primera impresión—, popularidad y mercado objetivo, por ejemplo. A partir de ello puede hacerse un poco de inteligencia de negocios para llegar a dos conclusiones básicas:

  • qué es lo que funciona o qué hace exitosos a los productos exitosos y
  • cuál es el nicho de mercado insatisfecho al cual vas a tomar como objetivo o si tienes que crear un mercado.
Si llegas a estas conclusiones y encuentras un buen nicho, trabaja nuevamente en:
  • el plan de mercadeo de tu producto software,
  • el sitio web mediante el cual muestras lo que tienes y
  • tu producto software...
Sí... es muy probable que llegues a nuevas conclusiones relacionadas con la forma en que has construido tu producto, por lo cual debas hacerle reingeniería pues, entre otras cosas, ese nicho de mercado debe sentir que tu producto software fue diseñado especialmente para satisfacer sus necesidades.

En cuanto a la estrategia de comunicación, todo depende de lo anterior: las características del producto y el nicho de mercado. Muchas veces, por desconocimiento, se tiende a comunicar por comunicar y por el medio que sea, cosa que en la mayoría de los casos no es adecuada. Por ejemplo, productos como Skype o YouTube no necesitan de una fuerte campaña de comunicación, sino que dependen de las sugerencias dentro de redes sociales —en línea o fuera de línea—, lo que conocemos como el «boca a boca».

Si has construido un producto software sin tomar en cuenta consideraciones de este tipo, es tiempo de que te calces el sombrero de mercadeo y que te pongas a trabajar —o, si no te gusta el asunto, que alguien más lo haga por tí. Y espera que sea duro. Mucho más duro que escribir software...

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.

Con resultados exitosos considera la Federación de Software Colombiana (Fedesoft) que se desarrolló la conferencia que di ayer miércoles 11 de octubre de 2006 en las instalaciones de la Cámara de Comercio Colombo Americana en Bogotá, Colombia, de título «Desarrollando Software de Clase Mundial: ¿Cuál es la Clave?» y que anuncié en este mismo espacio hace unos días.

En esta ocasión tuvimos la oportunidad de hacer planteos y reflexionar con un selecto auditorio conformado mayormente por empresarios, directivos e ingenieros con capacidad de toma de decisiones en sus respectivas empresas, sobre los asuntos que desde el lado estratégico se le imponen como reto a los participantes de la pujante industria del software colombiana de cara a las nuevas oportunidades de negocio que brinda la apertura de mercados internacionales mediante los tratados de libre comercio que se están estableciendo con distintos países.

Muchos de los temas son los que acostumbro a tratar en mi blog y, por supuesto, sobre los mismos asesoramos a empresas del sector desde Expértika, nuestra firma de consultoría.

Comparto con todos algunas de las fotografías que se tomaron durante el evento. Las memorias del mismo pueden descargarse desde el sitio web de la Federación.

Luego de unos días arduos abocado a la fundación de una firma de consultoría, Expértika Compañía Ltda., en la cual ejerzo como Gerente General, vuelvo al ruedo con mi blog y les cuento que el próximo miércoles 11 de octubre de 2006 de 8:30 a 11:00 horas estaré dando en la ciudad de Bogotá, Colombia, mi conferencia «Desarrollando Software de Clase Mundial: ¿Cuál es la Clave?», orientada principal aunque no excluyentemente a empresarios, directivos e ingenieros con capacidad de toma de decisiones en sus respectivas empresas de la industria del software.

Con el patrocinio y la organización de la Federación de Software Colombiana (Fedesoft) y la Cámara de Comercio Colombo Americana, el evento tendrá lugar en las instalaciones de la Cámara, sitas en Calle 98 N° 22-64, oficina 1209, Bogotá, Colombia.

Esta vez, enfocaré la disertación según la perspectiva empresarial y de gerencia. El planteo introductorio de esta conferencia es que para desarrollar software de clase mundial, este debe pensarse para serlo. Pero ello no basta. Las empresas deben adaptarse a la proyección internacional y descubrir la importancia de su interacción gremio-industrial. Compartiré en esta charla experiencias propias y de terceros relacionadas con el tema, y de aspectos como el aseguramiento de la calidad, cuestiones a tener en cuenta relacionadas con el producto software, software propietario y libre, metodología, organización y equipos de trabajo, usabilidad y accesibilidad, entre otros asuntos que adoptan carácter estratégico para los participantes de la industria del software de clase mundial de cara a las oportunidades de negocio que se le presentan a la industria colombiana del software.

Pueden obtener más información en esta página del sitio web de Fedesoft. Por consultas y para inscribirse, comunicarse con el Departamento Comercial de la Cámara, al teléfono +57 1 623 7088 o por correo electrónico.

Al margen, les comento que es posible que también dé esta conferencia más adelante en Bucaramanga, Medellín, Cali y Cartagena —o Barranquilla—, pero esto está por confirmarse. Por supuesto, los tendré al tanto por medio de este espacio.

Tal como comenté antes, participé como conferencista de la «Segunda Jornada Técnica IEEE del Oriente Colombiano», organizada por IEEE Sección Colombia y la Rama Estudiantil del IEEE en la Universidad Francisco de Paula Santander (IEEE-UFPS). Este evento que se desarrolló el día viernes 1° de septiembre de 2006 en la ciudad de Cúcuta, Departamento de Norte de Santander.

Tal como se ve en las fotografías que acompañan a estas líneas de texto, diserté en una conferencia dentro de las áreas de incumbencia de IEEE Computer Society, de título «Desarrollando Software de Clase Mundial: ¿Cuál es la Clave?».

En esta conferencia planteé que para desarrollar software de clase mundial, el producto software debe pensarse para serlo. Pero ello no basta. Las empresas deben adaptarse a la proyección internacional y descubrir la importancia de su interacción gremio-industrial. Compartí en esta charla experiencias propias y de terceros relacionadas con el tema, cubriendo aspectos como el aseguramiento de la calidad, cuestiones a tener en cuenta relacionadas con el producto software, software propietario y libre, metodología, organización y equipos de trabajo, usabilidad y accesibilidad, entre otros asuntos que adoptan caracter estratégico para los participantes de la industria del software de clase mundial.

Algo antiguo y que ha dado vueltas por toda la web, pero que vale la pena recordar. Fue hace poco más de un año atrás, más precisamente el 12 de junio de 2005, y Steve Jobs, Chief Executive Officer (CEO) de Apple Computer y de Pixar Animation Studios, y a mi entender uno de los empresarios más interesantes de la Computación, daba un glorioso discurso para la apertura de la ceremonia de graduación en la Stanford University, en la ciudad de Stanford, California, Estados Unidos de América. La transcripción al castellano del mismo está disponible en esta página. En fin, nada novedoso, estoy seguro que la mayoría lo ha leído a estas alturas.

Sin embargo, me han hecho llegar un enlace a una grabación en video de dicha intervención —que también lo han referenciado en varios sitios web— y estimo apropiado compartirlo con todos ustedes. Por supuesto, está en inglés...



Sin lugar a dudas, un gran discurso; como lo califiqué antes, simplemente glorioso.

Si me lo permiten, incluyo también algunas fotografías que me parecieron interesantes para complementar la nota.

En la primera vemos a Steve Jobs junto a Steve Wozniak —conocido también como «The Woz»— allá por 1975, época en la cual se dedicaban a armar computadoras en el garage de Jobs, que a partir de 1976 fue la humilde primera sede de lo que hoy conocemos como Apple Computer. Como curiosidad del caso, en esa época Woz estaba en la nómina de Hewlett-Packard, por lo cual se vio obligado por contrato a presentar la idea primero a esta firma. La respuesta que obtuvo fue un rotundo rechazo: «¿Para qué quiere la gente una computadora?», le contestaron... Algo que nos enseña a no aceptar tan fácilmente los rechazos con respecto a las cosas en las que creemos, vengan de quien vengan...

En la segunda tenemos a la misma dupla, pero en esta oportunidad treinta años más tarde, en 2005.

La tercera y última muestra a Steve Jobs durante el almuerzo en un evento, sentado a la mesa y en charla con su colega Bill Gates. Esta fotografía me recuerda cómo muchos de los usuarios de los productos de sus respectivas empresas, literal y fanáticamente se pelean por defender el producto que usan y atacan insistentemente al otro. Veamos... Ellos, como competencia, no están para nada trenzados en una discusión enardecida arruinando su almuerzo... Aprendamos de esto también; así es esto de la competencia, que para muchas cosas puede ser una rica fuente de grandes aliados...

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