Existen dos enfoques radicalmente opuestos de entender el desarrollo de software. En un extremo encontramos empresas como Google, Apple o Valve, que tratan de retener a los desarrolladores más brillantes. En el otro se encuentran las empresas como Telefónica en España que externalizan y subcontratan el desarrollo de software a proveedores mediante empresas de servicios y consultoría, como por ejemplo Accenture.

Mientras en el primer caso los procesos y los métodos seguidos para el desarrollo de software suelen ser artesanales, ad hoc según el proyecto y escogidos por los propios desarrolladores, en el segundo caso nos encontramos con un enfoque mucho más industrializado, con roles, actividades, documentos y procesos formales fijados por la organización de acuerdo a las enseñanzas de una materia comúnmente denominada como Ingeniería de Software.

Uno de los objetivos de la Ingeniería de Software es industrializar el proceso de desarrollo de software, obteniendo resultados dentro de unos parámetros de calidad, costes y plazos determinados mediante un proceso repetible, predecible y controlable.

De acuerdo a los niveles del modelo CMM, las empresas que se basan en el talento individual y en procesos ad hoc definidos por los propios desarrolladores, como pueden ser Google o Apple, estarían en el nivel de “madurez” más bajo, ya que dependen de “héroes” y artesanos, mientras que empresas como Telefónica o Accenture estarían en los niveles más altos, con procesos documentados y repetibles, definidos de acuerdo a un estándar de negocio, medidos y gestionados dentro de un proceso continuo de mejora que garantiza resultados repetibles independientemente de las personas.

¿Ha logrado su objetivo la Ingeniería de Software?

Dos perfiles de desarrollador opuestos

Las empresas de servicios trabajan con personal que cobra varias veces menos que un desarrollador de software en Google o Valve. A menudo los programadores se encuentran deslocalizados en software factories dentro de regiones o países donde los sueldos son más bajos. Esto es así porque para la Ingeniería de Software la programación es una actividad de construcción, escasamente valorada, acometible por mano de obra barata y reemplazable.

No obstante, el coste por jornada que las consultoras facturan a sus clientes ronda entre 250 y 350 euros por día, es decir, unos 6000 euros por persona y mes, por lo que desde el punto de vista del cliente el coste por jornada es semejante a lo que cobra un desarrollador de software en Silicon Valley.

Este coste se ve encarecido por el hecho de que la productividad de esta clase de programadores es baja y la calidad del código que escriben subestándar, ya que se trata de personal de escasa vocación que generalmente considera su trabajo de programador como un paso transitorio hacia puestos más elevados de gestión. La baja calidad del código implica mayor número de defectos, retraso en la entrega y a la larga un coste de mantenimiento elevado, por lo que el Total Cost of Ownership es muy alto.

Dos modelos de gestión opuestos

La Ingeniería de Software Tradicional define diversos roles y procesos dentro del ciclo de vida del desarrollo de software. En España el Ministerio de Administraciones Públicas promueve una metodología de planificación y desarrollo de sistemas de información denominada MÉTRICA, basada a su vez en el modelo del ciclo de vida de desarrollo ISO/IEC 12207, que puede servirnos como referencia del estándar existente en cuanto estructura organizativa y procesos que son necesarios para acometer un proyecto de desarrollo de software para la Administración Pública. Esta metodología también es un referente en las universidades españolas, consultoras y grandes empresas.

Como todas las metodologías clásicas, MÉTRICA se basa en la separación de los procesos de Análisis, Diseño y Construcción, ejecutados por distintos roles de personas:

  • Directivos
  • Jefes de Proyecto
  • Consultores
  • Analistas
  • Programadores.

Dentro de esta organización los programadores ocupan el último peldaño en cuanto a responsabilidad y valoración, y en la práctica también son los menos numerosos, ya que como puede desprenderse de los siete procesos principales que define MÉTRICA hay bastante más carga de gestión que de programación. Estos procesos son los siguientes:

  • Planificación de Sistemas de Información (PSI).
  • Estudio de Viabilidad del Sistema (EVS).
  • Análisis del Sistema de Información (ASI).
  • Diseño del Sistema de Información (DSI).
  • Construcción del Sistema de Información (CSI).
  • Implantación y Aceptación del Sistema (IAS).
  • Mantenimiento de Sistemas de Información (MSI).

Cada proceso consta de diversas actividades, y cada actividad de varias tareas. Por ejemplo, el proceso de diseño (DSI) consta de las siguientes 12 actividades y 32 tareas:

  1. Definición de la arquitectura del sistema
    1. Definición de Niveles de Arquitectura
    2. Identificación de Requisitos de Diseño y Construcción
    3. Especificación de Excepciones
    4. Especificación de Estándares y Normas de Diseño y Construcción
    5. Identificación de Subsistemas de Diseño
    6. Especificación del Entorno Tecnológico
    7. Especificación de Requisitos de Operación y Seguridad
  2. Diseño de la arquitectura de soporte
    1. Diseño de Subsistemas de Soporte
    2. Identificación de Mecanismos Genéricos de Diseño
  3. Diseño de casos de uso reales
    1. Identificación de Clases Asociadas a un Caso de Uso
    2. Diseño de la Realización de los Casos de Uso
    3. Revisión de la Interfaz de Usuario
    4. Revisión de Subsistemas de Diseño e Interfaces
  4. Diseño de clases
    1. Identificación de Clases Adicionales
    2. Diseño de Asociaciones y Agregaciones
    3. Identificación de Atributos de las Clases
    4. Identificación de Operaciones de las Clases
    5. Diseño de la Jerarquía
    6. Descripción de Métodos de las Operaciones
    7. Especificación de Necesidades de Migración y Carga Inicial de Datos
  5. Diseño de la arquitectura de módulos del sistema
    1. Diseño de Módulos del Sistema
    2. Diseño de Comunicaciones entre Módulos
    3. Revisión de la Interfaz de Usuario
  6. Diseño físico de datos
    1. Diseño del Modelo Físico de Datos
    2. Especificación de los Caminos de Acceso a los Datos
    3. Optimización del Modelo Físico de Datos
    4. Especificación de la Distribución de Datos
  7. Verificación y aceptación de la arquitectura del sistema
    1. Verificación de las Especificaciones de Diseño
    2. Análisis de Consistencia de las Especificaciones de Diseño
    3. Aceptación de la Arquitectura del Sistema
  8. Generación de especificaciones de construcción
    1. Especificación del Entorno de Construcción
    2. Definición de Componentes y Subsistemas de Construcción
    3. Elaboración de Especificaciones de Construcción
    4. Elaboración de Especificaciones del Modelo Físico de Datos
  9. Diseño de la migración y carga inicial de datos
    1. Especificación del Entorno de Migración
    2. Diseño de Procedimientos de Migración y Carga Inicial
    3. Diseño Detallado de Componentes de Migración y Carga Inicial
    4. Revisión de la Planificación de la Migración
  10. Especificación técnica del plan de pruebas
    1. Especificación del Entorno de Pruebas
    2. Especificación Técnica de Niveles de Prueba
    3. Revisión de la Planificación de Pruebas
  11. Establecimiento de requisitos de implantación
    1. Especificación de Requisitos de Documentación de Usuario
    2. Especificación de Requisitos de Implantación
  12. Aprobación del diseño del sistema de información
    1. Presentación y Aprobación del Diseño del Sistema de Información

Esta enumeración es bastante larga pero creo que sirve para dar una idea de la carga de trabajo de gestión y documentación que implica la metodología. En la práctica los programadores son la base de una pirámide invertida donde hay más gestores que programadores y mucha más mano de obra indirecta que mano de obra directa.

En el extremo diametralmente opuesto a esta consideración del desarrollador como último mono se encuentran empresas como Valve, donde podría decirse que rige una tecnocracia que queda perfectamente retratada en su guía para nuevos empleados de Valve. Se trata de una texto que no creo que deje impasible a nadie por lo que recomiendo encarecidamente su lectura.

¿Qué procesos, metodologías o fases de desarrollo encontramos en las empresas lideradas por técnicos como Google, Apple o Valve? Google es bastante abierta respecto a algunos de sus proyectos internos como Android, Chrome o Go. Todos estos proyectos están muy bien documentados, pero ninguno de ellos tiene algún tipo de documentación previa de análisis o diseño que guarde el menor parecido con MÉTRICA o con la que el modelo CMMI espera de una organización madura. Las especificaciones cambian sobre la marcha y dichos proyectos parecen completamente dirigidos por los desarrolladores. Incluso encontramos a sus líderes tocando código, ejecutando pruebas y corrigiendo bugs, como si no hubiera distinción ente jefes de proyecto, analistas, programadores y testers.

Parece como si entre la elite de los programadores, entre aquellos que presuntamente deberíamos imitar, las prácticas y procesos no tuvieran absolutamente nada que ver con aquellos recomendados por los comités e impartidos por las universidades.

Caso de Estudio

En noviembre de 2012 se anunció el nuevo sitio web del Senado, cuyo coste ascendió a 448.819,25 euros, y que fue realizado según los medios por Vass Consultoría de Sistemas, GFI Informática e Ibermática. El desarrollo previsto era de seis meses pero se demoró otros tantos, y el resultado recibió bastantes críticas en la prensa aunque es un coste relativamente bajo comparado con el que suele tener un sitio web oficial.

Diez días después un ingeniero que trabaja como freelance anunció un clon de la web “en una semana de trabajo” para denunciar el elevado coste de las licencias de la página original, que ascendía a 250.000 euros. Tomando como referencia una encuesta en HackerNews, el coste de una semana de trabajo de un desarrollador freelance cualificado en Estados Unidos está en torno a 2.800 euros, que es considerablemente inferior a los más de 200.000 que costó la web excluyendo licencias.

La diferencia entre los 2.800 euros y los 200.000 se debe esencialmente a la diferente productividad y metodología de trabajo. De haber seguido una metodología como MÉTRICA para acometer el desarrollo de acuerdo a un modelo “maduro”, esta persona tendría que haber dejado constancia documental de innumerables procesos, actividades y tareas antes de escribir una sola línea de código, tal y como se ven obligadas a hacer las empresas de servicios para cualquier proyecto de la Administración.

Considerando la demora y los problemas derivados de la calidad del desarrollo, seguramente el proyecto no resultó muy rentable para ninguna de las empresas que lo abordaron.