Javier Garzás

• Algunos retos de los profesionales del software (1/4)
• Algunos retos de los profesionales del software. La memoria histórica (2/4)

Decía Boehmn que aquello de que “quienes no pueden recordar el pasado están condenados a repetirlo” es una verdad a medias, ya que el pasado también incluye historias de éxito, y “si no somos conscientes de ellas estaremos frecuentemente condenados a no repetirlas”. Y a este respecto, comentábamos en algunos retos de los profesionales del software (1/4) que uno de los, en mi opinión, retos de los profesionales del desarrollo software es mejorar nuestra “memoria histórica”, en el sentido de conocer algo más del pasado y evolución de nuestra ingeniería del software.

Conocer poco el pasado de la ingeniería del software nos lleva, por ejemplo, a ser más vulnerables frente una práctica demasiado común en nuestra profesión: que nos ofrezcan, e intenten “vender”, antiguas prácticas y técnicas como si fueran de reciente aparición, añadiendoles pequeños cambios y un nuevo nombre. Sorprende escuchar en foros, eventos, reuniones, etc., como antiguas prácticas de ingeniería software se mencionan como algo novedoso, que acaba de aparecer para resolver los problemas del desarrollo; y muchas veces sorprende enterarse de que, por ejemplo:

- Las fábricas de software… son un concepto que aparece en los años 60.

- El “pair programming”… comenzó a utilizarlo Brooks en los 50, como se cita en “Pair programming illuminated”.

- La buena práctica de que la documentación del código (o parte) esté en el propio código… es de 1984, práctica también llamada “literate programming” de Knuth.

- Las primeras prácticas ágiles… son de los años 60, y el primer método ágil fue DSDM de 1994, cinco años antes que XP.

-El ciclo de vida iterativo e incremental, que recomiendan metodologías ágiles como SCRUM… comienza a utilizarse en los 60.

- La importancia de la participación del usuario final durante el desarrollo software… comenzó a mencionarla Ehn en 1988.

- La cada vez más de moda ISO 15504 aparece hace 15 años, en 1995

- (si algun@ tiene otro dato que crea importante añadir a esta lista sería interesante añadirlo como comentario a este post)

Desconocer parte del pasado y evolución de nuestra ingeniería del software también provoca que, a veces, se siga aún creyendo en prácticas que hace mucho tiempo la experiencia dijo que no funcionaban, como el clásico de intentar solucionar los problemas de tiempo en proyectos software añadiendo más personas a un proyecto ya en marcha. O a que aún se siga creyendo en los “silver bullets”. O a que olvidemos buenas prácticas que llevan ahí desde hace mucho tiempo (como comentábamos en el post del veterano ciclo de vida iterativo e incremental).

La mayoría de las mejores y más prometedoras ideas de la ingeniería del software no vendrán en el futuro… llevan con nosotros desde hace mucho tiempo.

El número de febrero de la revista DINTEL publicó un artículo sobre el proyecto de I+D Kemis, desarrollado por Kybele Consulting, finanziado por el CDTI y cuyo objetivo es evaluar la calidad software siguiendo las normas ISO 9126 e ISO 25000. Os lo dejo el artículo más abajo, vía Slideshare.

He creado una página en el blog, “recursos y descargas”, para centralizar artículos, informes, etc., que han ido apareciendo en post por el blog, y que así sea más fácil localizarlos. Los documentos más destacados que vaya encontrando en el blog los iré colocando en “recursos y descargas”.

Con el crecimiento de las implantaciones de ISO 15504 SPICE, especialmente en España desde que apareció el modelo de AENOR para la evaluación y mejora de la calidad software con ISO 15504, junto con los requerimientos que por parte del Estado español se están pidiendo a las empresas que desarrollan software y que quieran entrar en catálogos y licitaciones públicas, las cuales deben estar certificadas en algún nivel de madurez de ISO 15504 o CMMI, cada vez más me encuentro con la pregunta… ¿qué deberíamos implantar? ¿CMMI o ISO 15504?

Como es obvio la respuesta es… “depende”. Y en este post voy a comentar los que, en mi opinión, son los principales aspectos a considerar en ese “depende” (si alguien tiene algún factor más sería ideal añadirlo a los comentarios del post). Si yo tuviera que decidir (o recomendar) entre implantar CMMI o ISO 15504 tendría en consideración:

-   El mercado objetivo de la empresa que se quiere certificar. Para una empresa que desarrolla software con clientes en EEUU mi recomendación es, sin duda, CMMI; en EEUU la norma ISO 15504 es prácticamente una norma desconocida. Si tenemos interés en que la certificación nos valga para presentarnos a licitaciones y concursos públicos, en España, ambas son igualmente validas.

-   El coste de la certificación. Aquí me baso exclusivamente en mi experiencia profesional, y percepción propia del mercado, de lo que he visto hasta la fecha en proyectos de certificación, donde por lo general la certificación en CMMI es ostensiblemente superior en precio a la certificación en ISO 15504 SPICE, más si añadimos aspectos como que en CMMI se requiere que personal de la empresa a certificar haga el curso oficial de CMMI, lo que aumenta aún más el coste, y que varias personas de la organización participen 100% en la auditoría CMMI, de varios días, lo que aumenta los costes internos, sobre todo en pequeñas empresas.

-   Las otras normas implantadas en la organización. Normas como ISO 27001 (para los sistemas de gestión de la seguridad de la información) o ISO 20000 (para la gestión de los servicios) han tenido una gran demanda en los últimos años. Ambas normas siguen el modelo PDCA, y, obviamente, son más cercanas a la “filosofía” de ISO 15504, por lo que, de disponer de dichas normas, ISO 15504 será más fácil de adoptar por la organización que CMMI.

-   El organismo certificador. Si bien hay varias organizaciones (e incluso empresas) que certifican ISO 15504, uno de los organismos de certificación más rigurosos y prestigiosos es AENOR, acreditado por ENAC, y que emite directamente un certificado si se ha superado cierto nivel ISO 15504. En el caso de CMMI la cosa es más ambigua, como comentábamos en “quien certifica la calidad software en CMMI”, la certificación de haber superado un nivel de CMMI no la emite el SEI (que es el organismo que regula CMMI); el SEI no emite un certificado a las organizaciones evaluadas positivamente, sólo acredita a los auditores (los llamados “lead appraisers” en terminología CMMI), “lead appraisers” que voluntariamente elaboran algo “similar” a una certificación (un diploma), en el que se muestran los datos y resultados de la auditoría, pero que no es un documento oficial.

-   El enfoque de la mejora de la calidad software. Cuando hablamos en este post de CMMI nos estamos refiriendo a CMMI “for development”, que según dice la teoría del modelo, sería aplicable a cualquier proceso de construcción (no sólo software), por lo que en algunos puntos CMMI es bastante genérico. ISO 15504, cuando se aplica a software, normalmente utiliza de respaldo una norma específica de ingeniería del software, la ISO 12207.

-   La madurez de las implantaciones del modelo. Ambos modelos, CMMI e ISO 15504, tienen, prácticamente, la misma antigüedad, son de mitad de los 90… pero las implantaciones de CMMI son muy superiores a las de ISO 15504, por lo que de CMMI hay mucha más información, es más conocido y popular, existe más documentación, traducciones del modelo, guías, herramientas, presentaciones, etc. ISO 15504 e ISO 12207 (la norma que conjuntamente se aplica con ISO 15504 al evaluar desarrollo software) aún están en Inglés y son documentos de pago (hay algunas traducciones – resumen, pero no son oficiales), en CMMI la documentación es gratuita.

Seguro que hay más puntos a tratar en la decisión de si CMMI o ISO 15504 SPICE, pero estos son, en mi experiencia, los más determinantes y que más suelen importar. Y, como comentaba, si alguien tiene algún factor más sería ideal añadirlo a los comentarios del post.

Juan Antonio Calles, alumno del “Master Oficial en Tecnologías de la Información y Sistemas Informáticos” de la Universidad Rey Juan Carlos, y de “fábricas software”, ha desarrollado para su proyecto fin de máster, de cual gustosamente soy el tutor, una herramienta muy útil y necesaria a la hora de realizar estudios y auditorías de seguridad, la herramienta Anubis, cuya primera versión beta puede descargarse libremente.

Anubis integra herramientas para realizar dos técnicas de búsqueda de información en auditorías de seguridad: el Footprinting y el Fingerprinting. El Footprinting, para la búsqueda de información pública, o publicada descuidadamente, como direcciones IP, servidores internos, cuentas de correo de los usuarios, y el Fingerprinting, para averiguar el sistema operativo de los servidores de la organización a la que se está realizando la auditoría.

Si estáis interesados podéis descargarla aquí.

Twitter: http://twitter.com/jgarzas