Hace pocos días terminamos la migración de kybeleconsulting.blogspot.com a un wordpress en la dirección www.javiergarzas.com. La madurez que actualmente ya tienen tanto el blog como Kybele Consulting me hizo pensar que era el momento de separar los temas corporativos de los personales. Y desde ahora en kybeleconsulting.blogspot.com pondremos información corporativa y en www.javiergarzas.com pondré información personal – profesional, muy del estilo a la que hasta ahora se mostraba en el blog.
Las actuales suscripciones a kybeleconsulting.blogspot.com, tanto por feeds como por correo electrónico, las hemos migrado, y ahora recibirán información sobre nuevas entradas en www.javiergarzas.com. De hecho, a los suscritos, está entrada os debe haber llegado ya desde www.javiergarzas.com; no obstante, estar atentos por si en el proceso, siempre delicado, hay algún problema. Para los que además de los temas de www.javiergarzas.com queráis estar al tanto de la información corporativa de Kybele Consulting tenéis que suscribiros de nuevo al feed de kybeleconsulting.blogspot.com.
domingo 18 de octubre de 2009
lunes 7 de septiembre de 2009
Sobre la guía para implantar ISO 15504 SPICE, mi ponencia en las XI JICS, y sobre www.iso15504.es
Como comentaba en el anterior post, en nuestra exposición en las XI jornadas de innovación y calidad del software (JICS) presentamos los resultados de un proyecto que hemos estado desarrollando un grupo formado por AENOR, la Universidad de Castilla – La Mancha, y nosotros, Universidad Rey Juan Carlos y Kybele Consulting, y cuyo objetivo es elaborar una guía para la evaluación, mejora y certificación (por parte de AENOR) de la calidad software según la norma ISO 15504 SPICE.
¿Por qué arrancamos en su día este proyecto? Pues principalmente porque queríamos mejorar los actuales métodos de implantación de ISO 15504 SPICE (no quiero entrar en muchos tecnicismos, que ya de por sí el tema es complicado, pero para el que conozca el tema, me estoy refiriendo a la parte 5 y los anexos de la parte 7) y resolver así los principales problemas que, en nuestra opinión, hacen que la norma no llegue a las empresas (sobre el porqué ISO 15504 siempre ha ido detrás de CMMI hablaré en un siguiente post). En resumen, con la elaboración de la guía para la evaluación de la calidad software según ISO 15504 hemos pretendido:
¿Por qué arrancamos en su día este proyecto? Pues principalmente porque queríamos mejorar los actuales métodos de implantación de ISO 15504 SPICE (no quiero entrar en muchos tecnicismos, que ya de por sí el tema es complicado, pero para el que conozca el tema, me estoy refiriendo a la parte 5 y los anexos de la parte 7) y resolver así los principales problemas que, en nuestra opinión, hacen que la norma no llegue a las empresas (sobre el porqué ISO 15504 siempre ha ido detrás de CMMI hablaré en un siguiente post). En resumen, con la elaboración de la guía para la evaluación de la calidad software según ISO 15504 hemos pretendido:
- Lograr mayor agilidad y operatividad en su implantación, incluyendo su adaptación a pequeños equipos de desarrollo y PYMES, y que el uso de métodos ágiles no sea un problema.
- Aplicar un modelo de procesos actualizado, y más específico de software, para lo que usamos la ISO 12207 del 2008 (las actuales partes de ISO 15504, cuando se aplican a software, utilizan una versión anterior).
- Potenciar una ISO que evalúe la calidad software por niveles de madurez y la mejora de procesos en base a una norma internacional.
- Facilitar la integración con otras ISO (9001, 27001, 20000) e ir alineándose con futuras (ISO 29110).
- Disponer de un modelo cuya implantación sea más económica: con menos necesidad de formación para las empresas, menos jornadas de auditoría, etc.
lunes 31 de agosto de 2009
En las XI jornadas de innovación y calidad del software (JICS)
Esta semana, jueves y viernes, días 3 y 4 de septiembre, se celebran en Alcalá de Henares las XI jornadas de innovación y calidad del software (JICS).
Por mi parte, el viernes a las 12:25, haré una ponencia en la que resumiré los resultados de un proyecto en el que estamos inmersos, y cuyo objetivo es la “aplicación de la norma ISO/IEC 15504 (ver nota más abajo) para la evaluación por niveles de madurez de Pymes y pequeños equipos de desarrollo”, y en el que participan AENOR, la Universidad de Castilla – La Mancha, y nosotros, Universidad Rey Juan Carlos y Kybele Consulting. El trabajo se ha centrado en elaborar una guía, y adaptaciones, para la aplicación, de manera ágil y operativa, de la 15504, contemplado también las particularidades de pequeños equipos y pymes, solventando los problemas que en estos tienen CMMI y la aplicación tradicional de la ISO/IEC 15504, usando niveles de madurez y con procesos más específicos del desarrollo software.
Lo más importante que vaya ocurriendo en la jornada del viernes os los contaré “on-line” por el Twitter, interfaz justo a la derecha, en la columna de menús. Y si alguien se pasa por allí, podemos aprovechar y saludarnos.
Nota: La ISO/IEC 15504 es una norma internacional para la evaluación de los procesos, similar a CMMI.
Enlaces relacionados:
Por mi parte, el viernes a las 12:25, haré una ponencia en la que resumiré los resultados de un proyecto en el que estamos inmersos, y cuyo objetivo es la “aplicación de la norma ISO/IEC 15504 (ver nota más abajo) para la evaluación por niveles de madurez de Pymes y pequeños equipos de desarrollo”, y en el que participan AENOR, la Universidad de Castilla – La Mancha, y nosotros, Universidad Rey Juan Carlos y Kybele Consulting. El trabajo se ha centrado en elaborar una guía, y adaptaciones, para la aplicación, de manera ágil y operativa, de la 15504, contemplado también las particularidades de pequeños equipos y pymes, solventando los problemas que en estos tienen CMMI y la aplicación tradicional de la ISO/IEC 15504, usando niveles de madurez y con procesos más específicos del desarrollo software.
Lo más importante que vaya ocurriendo en la jornada del viernes os los contaré “on-line” por el Twitter, interfaz justo a la derecha, en la columna de menús. Y si alguien se pasa por allí, podemos aprovechar y saludarnos.
Nota: La ISO/IEC 15504 es una norma internacional para la evaluación de los procesos, similar a CMMI.
Enlaces relacionados:
- Por qué las organizaciones no implantan CMMI
- ISO/IEC 15504 parte 7: La opción ISO para evaluar la calidad por niveles de madurez
- La certificación por niveles de madurez de ISO/IEC 15504 SPICE
- X Jornadas de innovación y calidad del software (JICS)
- La mejora de procesos en pequeñas empresas y la ISO/IEC 29110
jueves 27 de agosto de 2009
¿Son un gasto innecesario las herramientas para pruebas?
Cuestión que plantea el blog de Gartner, tan recurrente con antigua (aún más si cambiamos “herramientas de prueba” por “herramientas de apoyo al desarrollo”). Tan antigua como la existencia de las herramientas. Me llama la atención que un blog, como el de Gartner, plantee tal pregunta, parece que en ingeniería del software estamos destinados a hablar siempre de lo mismo cambiándole el nombre. Así, casi que de memoria, hay mucho escrito al respecto, y serio, como Hoffman (1999) o Marick (1999), que ya hablaban del tema hace 10 años, o Ramler (2006). En el blog comentan que, en su opinión (y también en la mía, y en la de muchos), la clave no está en la herramienta, está en el proceso y la cultura de desarrollo, que es donde está la raíz de los problemas de calidad. Lógico. Las herramientas detectan, no solucionan la raíz del problema.
¿Son un gasto en tiempo y dinero? No. O sí. O no sé, dependerá del caso. Si se utilizan bien ayudarán a detectar problemas (en un porcentaje, que no es poco) antes de que lo haga el usuario. Si se utilizan mal, pues no servirán de nada, por muy caras que sean. Recuerdo hace unos años una empresa que tenía serios problemas de calidad software, y que compró la “set” de herramientas XXX líder en pruebas (por más de 60k euros, cifra nada despreciable). Pero luego nadie la utilizó, porque “los errores detectados por la herramienta no son fiables, porque son de la versión xxx de nuestro software y no de la yyy que ya lo soluciona, y que liberamos la semana que viene”, o porque “nos lleva mucho tiempo hacer los scripts de prueba”, o porque “no se adapta a nosotros, nos bloquea el desarrollo ahora que hay que hacer una entrega y si no llegamos será culpa de hacer estas pruebas”, etc. En ese caso sí, fue un gasto, los errores software siguieron ahí y la herramienta en un armario.
¿Son un gasto en tiempo y dinero? No. O sí. O no sé, dependerá del caso. Si se utilizan bien ayudarán a detectar problemas (en un porcentaje, que no es poco) antes de que lo haga el usuario. Si se utilizan mal, pues no servirán de nada, por muy caras que sean. Recuerdo hace unos años una empresa que tenía serios problemas de calidad software, y que compró la “set” de herramientas XXX líder en pruebas (por más de 60k euros, cifra nada despreciable). Pero luego nadie la utilizó, porque “los errores detectados por la herramienta no son fiables, porque son de la versión xxx de nuestro software y no de la yyy que ya lo soluciona, y que liberamos la semana que viene”, o porque “nos lleva mucho tiempo hacer los scripts de prueba”, o porque “no se adapta a nosotros, nos bloquea el desarrollo ahora que hay que hacer una entrega y si no llegamos será culpa de hacer estas pruebas”, etc. En ese caso sí, fue un gasto, los errores software siguieron ahí y la herramienta en un armario.
lunes 24 de agosto de 2009
IBM compra Ounce Labs
Aún en pleno verano, ha habido movimientos interesantes en el sector. En julio IBM compró Ounce Labs, empresa dedicada, principalmente, al control y detección de vulnerabilidades de seguridad, y que para ello dispone de una herramienta propia, que realiza evaluaciones del nivel de seguridad del software operando sobre el código fuente (estrategia de caja blanca). Herramienta que será un añadido más a la plataforma Rational de IBM.
IBM continúa así con la estrategia de disponer de herramientas para el control de la calidad software para los diferentes métodos y dimensiones de la calidad. Y que con este último movimiento pretende fortalecer una parte en la que la plataforma Rational andaba un poco floja: la evaluación de la seguridad de los desarrollos software mediante estrategias estáticas y de caja blanca. Y de paso posicionarse frente HP, su principal competidor en el área, y que ya había estrechado lazos con Fortify Software, también especializada en la seguridad software.
IBM continúa así con la estrategia de disponer de herramientas para el control de la calidad software para los diferentes métodos y dimensiones de la calidad. Y que con este último movimiento pretende fortalecer una parte en la que la plataforma Rational andaba un poco floja: la evaluación de la seguridad de los desarrollos software mediante estrategias estáticas y de caja blanca. Y de paso posicionarse frente HP, su principal competidor en el área, y que ya había estrechado lazos con Fortify Software, también especializada en la seguridad software.
lunes 10 de agosto de 2009
Publicadas en el BOE las fichas de la ingeniería informática
Nada más volver de unas breves vacaciones, e inmerso en el arduo proceso de la reincorporación, a través del CPIICYL me encuentro con la grata noticia de que ya han sido publicadas en el BOE las fichas de la Ingeniería e Ingeniería Técnica en Informática, que describen los mínimos que deben cumplir dichos estudios universitarios y cuya carencia, en su día, tanta polémica produjo (no en vano dejaba en el caos a dichos estudios universitarios).
Y de paso aparece por primera vez en un texto oficial, el BoletÍn Oficial del Estado, una referencia explicita a la profesión de la ingeniería informática.
Y de paso aparece por primera vez en un texto oficial, el BoletÍn Oficial del Estado, una referencia explicita a la profesión de la ingeniería informática.
jueves 23 de julio de 2009
¿Quién certifica la calidad software? (1) (EN CMMI)
Esta entrada pretende ser la primera de una serie, en la que hablar, de vez en cuando, sobre quién (qué organización) certifica la calidad software (en CMMI, ISO 15504, el producto software, etc.).
La pregunta es tan típica como poco conocida es su respuesta, y se escucha sobre todo en los proyectos CMMI (en los proyectos ISO parece estar algo más claro), muchas veces al comienzo del proyecto, y casi siempre al final, cuando superado un nivel de madurez la organización evaluada se pregunta… “cuándo me enviarán el certificado”. Asunto nada claro, por sorprendente que parezca.
Antes de seguir, es importante aclarar que en calidad, general y ampliamente, por “certificación” se entiende (tomo como referencia y parafraseo de la norma ISO 17000) la acción por la que una entidad reconocida e independiente (por ejemplo, una entidad de certificación, AENOR, un laboratorio, un verificador, etc.) expresa y reconoce que una organización, proceso, persona, servicio o producto es conforme a los requisitos que define una norma, modelo o especificación técnica. Existe otro termino relacionado, que muchas veces se confunde con el anterior, y que es la “acreditación”, o la acción por la que un organismo autorizado (que, por ejemplo, en España es ENAC) reconoce formalmente que cierta organización es competente para certificar (y hay normas, como por ejemplo la serie ISO 17000 que tienen el objetivo de definir los requisitos que un organismo de certificación debe cumplir). Si alguien precisa de una definición más rigurosa y formal, la citada ISO 17000 es en mi opinión la mejor fuente.
Entonces, en el caso de CMMI, y según lo anterior… ¿Quién certifica que cierta organización es conforme a cierto nivel de madurez o capacidad? Seguro que a los que conozcan un poco CMMI lo primero que se les habrá venido a la cabeza es que es el SEI (el Software Engineering Institute, organismo que regula y del que es propiedad el modelo CMMI) el que emite un certificado de que cierta organización ha sido evaluada positivamente frente al modelo. Pero no es así, no hay tal certificación. El SEI no emite un certificado a las organizaciones evaluadas positivamente (ver, por ejemplo, aquí y aquí), sólo acredita a los auditores (los llamados “lead appraisers” en terminología CMMI). En ocasiones, voluntariamente, estos auditores 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 único documento oficial con los resultados de la evaluación es el que llaman “Appraisal Disclosure Statement”, que se rellena al final de la auditoría, contiene los datos (participantes, fechas, etc.), que elabora el auditor, que firma, principalmente, el responsable de la organización evaluada, y que se envía al SEI (se envía al SEI, no nos lo envía el SEI a nosotros) para que en su Web aparezca la organización evaluada (la cual estará presente en dicha Web durante tres años).
La pregunta es tan típica como poco conocida es su respuesta, y se escucha sobre todo en los proyectos CMMI (en los proyectos ISO parece estar algo más claro), muchas veces al comienzo del proyecto, y casi siempre al final, cuando superado un nivel de madurez la organización evaluada se pregunta… “cuándo me enviarán el certificado”. Asunto nada claro, por sorprendente que parezca.
Antes de seguir, es importante aclarar que en calidad, general y ampliamente, por “certificación” se entiende (tomo como referencia y parafraseo de la norma ISO 17000) la acción por la que una entidad reconocida e independiente (por ejemplo, una entidad de certificación, AENOR, un laboratorio, un verificador, etc.) expresa y reconoce que una organización, proceso, persona, servicio o producto es conforme a los requisitos que define una norma, modelo o especificación técnica. Existe otro termino relacionado, que muchas veces se confunde con el anterior, y que es la “acreditación”, o la acción por la que un organismo autorizado (que, por ejemplo, en España es ENAC) reconoce formalmente que cierta organización es competente para certificar (y hay normas, como por ejemplo la serie ISO 17000 que tienen el objetivo de definir los requisitos que un organismo de certificación debe cumplir). Si alguien precisa de una definición más rigurosa y formal, la citada ISO 17000 es en mi opinión la mejor fuente.
Entonces, en el caso de CMMI, y según lo anterior… ¿Quién certifica que cierta organización es conforme a cierto nivel de madurez o capacidad? Seguro que a los que conozcan un poco CMMI lo primero que se les habrá venido a la cabeza es que es el SEI (el Software Engineering Institute, organismo que regula y del que es propiedad el modelo CMMI) el que emite un certificado de que cierta organización ha sido evaluada positivamente frente al modelo. Pero no es así, no hay tal certificación. El SEI no emite un certificado a las organizaciones evaluadas positivamente (ver, por ejemplo, aquí y aquí), sólo acredita a los auditores (los llamados “lead appraisers” en terminología CMMI). En ocasiones, voluntariamente, estos auditores 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 único documento oficial con los resultados de la evaluación es el que llaman “Appraisal Disclosure Statement”, que se rellena al final de la auditoría, contiene los datos (participantes, fechas, etc.), que elabora el auditor, que firma, principalmente, el responsable de la organización evaluada, y que se envía al SEI (se envía al SEI, no nos lo envía el SEI a nosotros) para que en su Web aparezca la organización evaluada (la cual estará presente en dicha Web durante tres años).
domingo 5 de julio de 2009
Algunos datos del informe de ASIMELEC sobre el sector TIC en 2008
Leyendo el “informe 2009 del Sector TIC en España” que ASIMELEC presento recientemente, me han llamado la atención algunos datos, más curiosos aún en los tiempos de crisis que vivimos, y que muestran que el sector obtuvo un volumen de negocio de 77.431,5 millones de euros durante el 2008, un crecimiento del 0,1% respecto al 2007 (que no es mucho pero es algo), que aporta el 7,07% del PIB español y que genera más de 350.000 empleos directos.
Este denominado sector TIC está formado por muchos segmentos (telecomunicaciones, electrónica, audiovisual, etc.), por lo que entrando un poco más de detalle en los datos de los segmentos más “relacionados con el software”, principal temática del blog, en el informe se puede leer como el segmento del “software informático” (herramientas, licencias de aplicaciones, etc.) creció un 7,9% respecto al 2007 y los “servicios informáticos” un 7,1%. Y a su vez, en este último segmento, el de los “servicios informáticos”, podemos encontrar que:
Este denominado sector TIC está formado por muchos segmentos (telecomunicaciones, electrónica, audiovisual, etc.), por lo que entrando un poco más de detalle en los datos de los segmentos más “relacionados con el software”, principal temática del blog, en el informe se puede leer como el segmento del “software informático” (herramientas, licencias de aplicaciones, etc.) creció un 7,9% respecto al 2007 y los “servicios informáticos” un 7,1%. Y a su vez, en este último segmento, el de los “servicios informáticos”, podemos encontrar que:
- El “outsourcing” es ya el 40% del volumen de negocio de los servicios informáticos, con un 11,5% de crecimiento con respecto al 2007, lo que confirma la tendencia hacia la externalización.
- El “desarrollo e integración de sistemas” experimentó un incremento del 4,7% respecto a 2007.
- El “soporte” creció un 4%.
- La “consultoría” también creció un 4%.
- La “formación” se incrementó un 4,1% respecto al 2007.
domingo 28 de junio de 2009
¿Se miente en los proyectos software?
Según la RAE mentir es “decir o manifestar lo contrario de lo que se sabe, cree o piensa”, acto que encontramos con frecuencia en la vida cotidiana… y también en la profesional. Con el objetivo de estudiar la mentira en los proyectos software, en 2006 Glass, Rost y Matook realizaron un sondeo que muestra como el 86% de los encuestados constataban que se mentía en los proyectos software en que habían participado. Respecto a las razones para mentir en un proyecto software, el estudio identifica que las principales son:
- Para incrementar las ventas.
- Porque es más ventajosos que decir la verdad (por ejemplo para generar optimismo).
- Por imagen, frente a superiores o clientes.
- A raíz de haber tenido un exceso de confianza.
- Para ocultar errores.
- Para intentar que la carga de trabajo disminuya.
- Las relativas a estimación de costes y planificaciones (para un 66% de los encuestados).
- Las relativas a “informes de seguimiento” (65%).
- Las que refieren a “maniobras políticas”, para mejorar la posición personal dentro de la empresa (58%).
- La exageración, el aumento de la realidad (32%).
domingo 21 de junio de 2009
Los superprofesionales del software
Aunque han sido semanas complicadas, con muchos proyectos, reuniones, etc., pude leer algunas cosas que tenía pendientes, de entre las que me gustó mucho la columna de Erdogmus en la última IEEE Software, que trata sobre la profesionalidad en el software, donde comenta algunos de esos principios que deben guiarnos en el día a día, y que demasiadas veces se echan de menos. Erdogmus escribe sobre un reducido grupo de profesionales, que llama los “superprofesionales” y que distingue por siete rasgos:
Espero esta semana tener algún momento libre (que, como agudamente me recordaba hithwen, en un blog uno hace lo que puede con el tiempo que tiene) y completar esta entrada otro articulo.
- Responsabilidad. Todo superprofesional tiene un primordial sentido de la responsabilidad, y de la obligación de entregar aquellos resultados con que se hubiese comprometido.
- Conciencia. Tienen gran sensibilidad (empatía) de las necesidades e intereses de los diferentes participantes en un proyecto. Y para ello un superprofesional tiene autoconciencia de sus fortalezas y debilidades, se conoce a si mismo y reconoce que sabe y que no sabe hacer.
- Honestidad. Es demasiado frecuente observar como muchas veces no se dice toda la verdad en reuniones, estimaciones, informes de seguimiento, etc. Un superprofesional siempre se apoya en la verdad.
- Resistencia bajo presión. Mantener un compromiso muchas veces sólo es posible resistiendo la presión constante de compañeros, jefes, clientes, equipo e incluso de si mismo. Y esta resistencia no es posible sin sacrificio.
- Imparcialidad. Los conflictos de interés son constantes en el mundo del software, y la ética profesional debe ser la que guíe estas situaciones. Los superprofesionales tienen muy desarrollado el sentido de la objetividad y de la imparcialidad.
- Sin perder la perspectiva, prestar atención a los detalles. Conocen el impacto que pueden tener las pequeñas decisiones y los pequeños detalles, pero sin que esto les haga perder la perspectiva global.
- Pragmatismo. Cuando hay que tomar una decisión, con importantes pros y contras, pueden encontrar el mejor equilibrio, actuar de la mejor manera, teniendo incluso que dejar a un lado el orgullo, las convicciones, preferencias o tecnologías favoritas.
Espero esta semana tener algún momento libre (que, como agudamente me recordaba hithwen, en un blog uno hace lo que puede con el tiempo que tiene) y completar esta entrada otro articulo.
Suscribirse a:
Entradas (Atom)
