Fábrica de software

Un modelo de negocio certificable basado en Estructura y

Capacidades
“Dime qué tienes, qué produces y te diré qué eres”.

Alberto Balderas Padrón

Arnoldo Díaz Olavarrieta
certum

1 Introducción

En este artículo se presenta una breve semblanza del origen del concepto fábrica
de software incluyendo tres ejemplos de fábricas en los Estados Unidos y Japón.
Además, proponemos una taxonomía para los diferentes tipos de fábricas de
software basada en componentes estructurales y niveles de capacidad de procesos
ISO 15504. Para concluir se presenta brevemente la fábrica mexicana de software
certum.

2 Origen de las fábricas de software

A fines de los años 60´s e inicios de los 70´s, surge en la industria del software el
concepto de fábrica de software. Este nace como una respuesta a la necesidad de
aliviar la incertidumbre que se tenía en el desarrollo de proyectos de software en
aspectos como:

• Confiabilidad de los productos.

• Mantener en presupuesto y calendario los proyectos de desarrollo de software.
• Falta de una definición y seguimiento adecuado a los procesos de producción,
así como un medio efectivo de medirsu desempeño y la productividad de las
personas que lo ejecutan.
• Falta de estandarización en los métodos y herramientas empleados en los
procesos. Esto provocaba reinventar el “hilo negro” cada vez, además del nulo
reuso de los productos que los mismos procesos de producción generan.
• Falta de herramientas para ser rastreables los productos (requerimientos,
especificaciones de productos, etc.) que generan los procesos.

El fundamento para establecer fábricas de software, fue basado en tratar de

obtener los beneficios que las líneas de producción industrial produjeron en la
calidad de los productos así como la productividad lograda. Dichas líneas de
producción se basan en tener definido un proceso y el flujo que sigue cada
operación del proceso, además de proveer las herramientas necesarias para llevar
a cabo la acción deseada. Entre más segmentado es el proceso, mas simple se
vuelve cada operación logrando con esto una división del trabajo orientada a la
especialización. Esto logra elevar la productividad, sin embargo, trae situaciones
que en un momento determinado hay que afrontar como el contar con personas
que tienen un dominio restringido de acción.
Vista de esta forma, la cadena de producción es un mecanismo que permite a un
trabajador estar habilitado para tomar una acción, altamente eficaz y eficiente, en
un momento adecuado del proceso. A esto se le llama “situación de resolución”.
En este sentido, aprovechando las tecnologías de información es posible crear
cadenas virtuales de producción en donde el proceso y su flujo estén claramente
definidos de tal forma que generen situaciones de resolución para cada trabajador.
(Para mayor detalle consulte Soluciones Avanzadas, Febrero1996: “La Cadena
Virtual: Hacia la fundamentación de la Reingeniería”, Bracho, Díaz.)

Fue entre otras por estas causas, que varias empresas en el mundo
principalmente Norteamericanas y Japonesas, invirtieron recursos en la definición
y puesta en marcha de sus fábricas de software.

Entre las empresas Norteamericanas pioneras en este ámbito, se encuentra

System Development Corporation (SDC), que en los años 70´s concibió un modelo
de fábrica de software para tratar de resolver los problemas antes mencionados.
Su modelo giró alrededor de dos partes: El control que incluía las áreas de control
de proyectos y aseguramiento de calidad y el área de implementación que incluía
las áreas de diseño, construcción y pruebas de sistema, ambos coordinados a
través de procedimientos y estándares.

Este modelo retroalimentándose a través de diversos proyectos, desembocó en lo

que sería el manual de desarrollo de software SDC. El resultado que trajo el
esfuerzo de contar con dicho manual, fue que los proyectos comenzaron a
converger en productos con menos defectos y en el tiempo y presupuesto
establecidos.

El modelo de SDC, rápidamente influenció a empresas del Japón que comenzaron

a definir su propio modelo de fábrica de software. Una de las fabricas pioneras es
Hitachi que es la más grande y antigua, se estima que en 1991 contaba con 7,000
empleados trabajando en el desarrollo de diversos tipos de aplicaciones para
instituciones financieras, de seguros, control de inventarios, recursos humanos,
etc. Durante los años 70´s Hitachi trabajó arduamente en la definición y medición
de los procesos de desarrollo de software, incorporando elementos de medición y
control de calidad. Sólo que no todo funcionó a la primera, entre los múltiples
problemas que tuvieron que resolver fue la incapacidad de incorporar conceptos
de fabrica de software como la estandarización del ciclo de desarrollo del proyecto
y el reuso de componentes. Un problema adicional fue que trataron de
estandarizar un sólo proceso de desarrollo para cualquier tipo de aplicaciones.
Esto provocó proyectos fuera de fecha y presupuesto establecido.

Fue a finales de los años 70´s que lograron organizar su fábrica de software
alrededor de un manual que contenía enfoques de ingeniería y fábrica. En el, se
incorporaron diversas técnicas del diseño y codificación estructurados así como
tiempos estándares para cada actividad, inspecciones de productos y análisis de
defectos del proceso entre otros elementos. Fue después de este esfuerzo que
decidieron invertir en el desarrollo de sus propias herramientas de software para
soportar sus funciones. A partir de este momento la fábrica logró una mejora
impresionante en su desempeño, pasan de atrasos en la entrega de proyectos al
departamento de aseguramiento de calidad de 72% a 12%.
Otra fábrica de software pionera en el Japón es Toshiba. Durante los años 70´s, se
enfocó en la definición de su modelo de fábrica de software alrededor de cuatro
puntos: Estandarizar los procesos de desarrollo para reducir variaciones entre
proyectos; Reuso exhaustivo de diseños y programas para construir nuevos
sistemas a fin de reducir el trabajo redundante y maximizar la productividad;
Introducir el uso de herramientas estándar a fin de elevar los niveles de
desempeño de las personas; Proveer entrenamiento extensivo en las personas.

Para poder realizar lo anterior, Toshiba se centró fuertemente en el reuso de

componentes como una medida estratégica para incrementar la productividad.
Desarrolló diversas herramientas estandarizadas para soportar el diseño,
identificación y control de componentes reusables, generadores de código,
pruebas del software y control de proyectos. Estas herramientas permitieron elevar
la productividad de una manera impresionante, pasaron de 1,400 líneas de código
fuente ensambladas en 1976 a mas de 3,000 en 1986. Para Toshiba, gran parte
de su éxito se debe al reuso de componentes.

Estas experiencias han llevado a varias definiciones o acepciones del término

“fabrica de software” y a enfatizar alguno de los elementos que aparecen o
explican parte de los éxitos referidos. Tal es el caso de una definición que declara
como elemento esencial de una fábrica a los componentes de reuso. Hace falta
una definición, que al aplicarla, lleguemos todos a la misma conclusión y que
incluya los elementos que han sido reconocidos y aceptados por la industria como
esenciales. Lo ideal sería llegar a algo así de claro como… Activo = Pasivo +
Capital. Más aún, tal como los estados financieros, debería poder ser dictaminable
o certificable por un tercero.
3 Definición, componentes estructurales, capacidades del
proceso y tipos de fábricas de software.

3.1 Antecedentes.

No existe en la literatura una definición explícita, completa y clara del concepto

fábrica de software ni de las partes que la componen. El concepto ha venido
madurando desde los años 60´s y ha evolucionado a medida que se han definido
técnicas y métodos, además de la aparición de diversas herramientas de software.
También debemos reconocer que se ha venido desvirtuando y abusando del
término en perjuicio de la claridad y de los clientes.

Desde el punto de vista de la intención, podríamos definir una fábrica de software

como un conjunto de elementos que busca entregar productos con una
confiabilidad, tiempo de entrega y costo predecible y administrable involucrando
gran cantidad de personas, o mejor aún, ingenieros para tal efecto. Para ello
pareciera ser necesario contar con un enfoque industrial, de procesos de
producción claramente definidos y medibles, de tal forma en que puedan ser
auditados y mejorados. Sin embargo esta definición, muy socorrida por cierto en el
medio para efectos de mercadotecnia junto con los anuncios iluminados y las
inauguraciones pomposas, no es suficiente para distinguir inequívocamente una
empresa de otra.

Proponemos una definición de fabrica de software en términos de:

• componentes estructurales y,
• de capacidades de los procesos.

Con esto podremos llegar a una definición cuantitativa inequívoca y una tipificación
clara de diversos tipos de empresas y fábricas de software que distinguimos.
3.2 Componentes estructurales.

Por componentes estructurales nos referimos a aquellos elementos fundamentales

sobre los cuales se basa una empresa de diseño y construcción de software a la
medida. La ausencia de alguno de ellos tendría un impacto en la tipificación que
pudiéramos hacer de la empresa. Proponemos que hay tres tipos de
componentes estructurales que conforman una empresa de esta especialidad:

3.2.1 Componentes de Operación.

Componente Características

Planta Física. Infraestructura de soporte (mobiliario, equipo, horarios, etc.)

que contenga espacios de trabajo que garanticen las
condiciones de ambiente necesarias para que las personas
puedan desarrollar su trabajo.
Administración Herramientas y repositorio que contenga los productos que se
de la generan en el proceso de producción así como un
Configuración. procedimiento de administración claramente definido.
Librerías de Una de las formas que más dramáticamente incrementan la
Componentes. confiabilidad, disminuyen los tiempos y costo de desarrollo,
es el reuso de componentes. Por tal razón se debe habilitar
una librería en donde se tengan claramente identificados,
accesibles y disponibles cualquier componente reusable
(diseños, procesos, programas fuente, datos, planes de
proyectos, bases de datos, etc.)
Base de Es necesario contar con una librería técnica donde se
Conocimientos. registren todo incidente técnico relacionado con los procesos
de producción, las herramientas de desarrollo o el dominio de
especialidad del producto.
3.2.2 Componentes de Control.

Componente Características

Estimación y Es indispensable contar con técnicas y métodos para poder

Planeación. estimar, planear y medir el avance de los proyectos. Entre las
métricas que se tienen en la industria se encuentran
Presupuesto contra real, Puntos de función por persona mes.
Administración Es indispensable contar con:
de Procesos. À Procesos de producción claramente definidos de tal forma
que puedan ser rastreables y medidos a fin de ser
mejorados.
À Metodologías, técnicas y herramientas para llevar a cabo
los procesos de producción.
Aseguramiento Es indispensable contar con:
de Calidad y À Funciones de aseguramiento de calidad de tal forma que
Productividad. los productos cumplan con los requerimientos solicitados
por el cliente.
À Métricas claramente definidas para medir la productividad
de los procesos. Entre estas tenemos puntos de función
por persona-mes (Function Points)[1] y Defectos por Punto
de Función.
À Métricas para medir la satisfacción del cliente.

Administración Es necesario contar con un sistema para medir los costos de

de Costos. Producción por operación, proceso, persona y proyecto.

3.2.3 Componentes de Desarrollo de Personas.

Componente Características

Programas de Es necesario definir de una manera clara el plan de carrera

Carrera. de las personas, así como un procedimiento que administre
su crecimiento.
Entrenamiento. Para mejorar la productividad de las personas, es necesario
proveer y medir el entrenamiento necesario.
Evaluación. A fin de elevar la productividad de las personas es necesario
medir en términos cualitativos y cuantitativos su desempeño
dentro de los procesos de producción.
Planes de Es necesario contar con un procedimiento definido sobre la
Compensación. política de compensaciones de las personas, de tal forma que
incentive el desarrollo personal de una manera sostenida.

[1] Puntos de función (function points) es una unidad de medida del tamaño de la funcionalidad de un programa.
Fue estandarizada internacionalmente en Junio de 1995 como la norma ISO 14143 Functional Size
Measurement. México fue uno de los países participantes que votó a favor de esta norma.
3.3 Capacidad de procesos.

3.3.1 Definición.

Un elemento fundamental en las fábricas de software es el poder medir la

capacidad de sus procesos de producción. Por capacidad de proceso entendemos
el rango de resultados esperados, en los dominios de confiabilidad, tiempo de
entrega y costo, que pueden lograrse al seguir un proceso determinado. Una de
las formas actuales de medir las capacidades de los procesos es a través de los
modelos como el del ISO 15504[2]. Este provee un marco de evaluación que puede
ser usado por las organizaciones en la planeación, administración, monitoreo,
control y mejora de la adquisición, oferta, desarrollo, operación, evolución y
soporte del software.

3.3.2 Estructura.

La arquitectura de los modelos de evaluación de capacidad de procesos

compatibles con el futuro estándar internacional ISO 15504, como el Bootstrap 3.0,
están diseñados alrededor de dos dimensiones:

Dimensión Definición

Proceso. Entendido como una serie de operaciones con propósitos

definidos y medibles que producen productos con ciertas
características tipificadas.
Capacidad del Es caracterizado por una serie de atributos de efectividad
Proceso. aplicables a cualquier proceso para manejar y mejorar su
desempeño.

[2] ISO15504 ha sido publicado recientemente como reporte técnico. Para mayor referencia consulte: “Un
estándar Internacional para la evaluación del proceso de desarrollo del software ISO/SPICE”, Soluciones
Avanzadas Marzo 1996.
Los procesos de las organizaciones son organizados en cinco categorías de
procesos:

Categoría Definición

Cliente- Agrupa los procesos que impactan directamente al cliente,

Proveedor. soporte al desarrollo del software así como la entrega,
operación y soporte del mismo.
Ingeniería. Agrupa a los procesos con los que se especifica, implementa
y mantiene el software así como su documentación.
Proyecto. Agrupa a los procesos para la administración del proyecto, la
calidad, el manejo de riesgos así como para el manejo de
subcontratos a lo largo del ciclo de vida del producto.
Organización. Agrupa a los procesos que establecen las metas del negocio
y la definición y mejora de los procesos en sí, así como los
recursos humanos y herramientas existentes, asignados y
utilizados en el proyecto para la realización del producto(s).
Soporte. Agrupa a los procesos empleados por cualquier otro proceso
del proyecto. Se incluyen: documentación, control de
configuración, aseguramiento de calidad, verificación y
validación de productos así como inspecciones.
3.3.3 Niveles de Capacidad.

Un nivel de capacidad es un conjunto de atributos de efectividad que trabajan

juntos a fin de caracterizar la capacidad de desempeño de un proceso. El modelo
define seis niveles de madurez para cada proceso:

Nivel Nombre Definición

0 Incompleto Hay una falla general al tratar de conseguir el propósito

del proceso. No fácilmente se pueden identificar los
productos que generan los procesos.
1 Ejecutado El propósito del proceso es generalmente llevado a
cabo. Algunas veces dicho propósito no es conseguido
apegado totalmente al plan de trabajo. Hay consenso
entre el equipo de trabajo que se ejecuta el trabajo
cuando es requerido. Es posible identificar los
productos que fueron generados por los procesos y
esto testifica que se consiguió el propósito.
2 Administrado El proceso entrega productos de calidad aceptable
dentro del plan de trabajo definido. El proceso es
llevado a cabo con el plan definido. Los productos se
apegan a estándares y requerimientos. La distinción
primaría de este nivel respecto al “Ejecutado” es que el
desempeño del proceso es planeado y administrado.
3 Establecido El proceso es llevado a cabo usando un proceso
establecido usando las mejores prácticas de la
ingeniería de software. El proceso es adecuado y
documentado para cada proyecto. La distinción
primaría de este nivel respecto al “Administrado” es que
el proceso establecido es planeado y administrado
partiendo de un proceso estándar.
4 Predecible El proceso definido es llevado a cabo consistentemente
dentro de sus límites de control y consigue sus metas.
Existen métricas detalladas del desempeño que son
analizadas. Esto lleva a entender cuantitativamente la
capacidad del proceso y a mejorar la habilidad de
predecir su desempeño. El desempeño es manejado
objetivamente. La calidad de los productos es conocida
cuantitativamente. La distinción primaría de este nivel
respecto al “Establecido” es que el proceso es
cuantitativamente entendido y controlado.
Nivel Nombre Definición

5 Optimizando El desempeño del proceso es optimizado de acuerdo a

las necesidades del actuales y futuras del negocio. La
eficacia de la medición cuantitativa del proceso y metas
eficientes son establecidas basadas en las metas de
negocio de la organización.

El contínuo monitoreo contra esas metas habilita la

retroalimentación cuantitativa y la mejora proviene del
análisis de resultados.

La optimización del proceso envuelve el pilotear ideas

innovadoras y cambiar procesos no efectivos acorde a
las metas establecidas.

La diferencia primaria de este nivel respecto al

“Predecible” es que el proceso definido y el proceso
estándar entran en un ciclo de refinamiento y mejora
continua, basados en un entendimiento cuantitativo del
impacto de los cambios en el proceso.

3.4 Tipos de fábrica de software.

En base a los elementos, definiciones y conceptos anteriores proponemos que

para que una empresa pueda ser considerada una fábrica de software debe,
además de contar con ciertos componentes estructurales contar con un cierto nivel
de capacidad en sus procesos. La detección y caracterización de los componentes
estructurales es relativamente fácil y directa. Existen un consenso en la industria,
más o menos maduro y profesional, respecto de estos elementos y su adecuación
al contexto y propósito de proyecto. Sin embargo la evaluación de las capacidades
de los procesos es más complejo y hasta cierto punto sofisticado. Es por ello que
es fuertemente recomendable certificarlas por un tercero especializado,
competente, e imparcial. Aclarando posibles confusiones por el uso del término
certificación señalamos desde ahora que ISO 9001 no es compatible con ISO
15504 precisamente por su carencia de especialidad en ingeniería de software.
Así mismo cabe hacer la aclaración, que estos elementos son totalmente
independientes del tamaño que tenga la empresa.
Combinando estos elementos, es posible caracterizar a las empresas desde un
taller artesanal hasta una fábrica avanzada de software en función de la
existencia/adecuación de sus componentes estructurales y del nivel de capacidad
de sus procesos como se ilustra en el siguiente diagrama:

OPTIMIZANDO FABRICA
DESARROLLO Nivel 4-5 AVANZADA
PERSONAL
FABRICA BASICA
CONTROL

PREDECIBLE
Nivel 3-4
Cuantitativo
Cualitativo
ESTABLECIDO TALLER
Nivel 2-3 INDUSTRIAL

OPERACION
ADMINISTRADO TALLER
Nivel 1-2 ARTESANAL

ESTRUCTURA + CAPACIDAD = TIPO

No hemos definido para niveles de capacidad de 0 algún tipo de fábrica, ya que el

nivel implica resultados totalmente inciertos. Corriendo el riesgo de pecar de
optimistas, tenemos pues una definición con la claridad estructural, y debemos
reconocer que también con las complejidades operativas, como la de Activo =
Pasivo + Capital para el tema que nos ocupa: Tipo = Estructura + Capacidades.
4 , una fábrica de software de tipo Básica.

certum[3], es el nombre de nuestra marca, nace en Puebla en 1986 y se traslada a

la ciudad de México en 1988 a causa de que sus clientes se encontraban en esta
ciudad. El nombre de nuestra marca obedece a la resolución que tomó la empresa
de atacar el problema fundamental en la industria del desarrollo de software: la
incertidumbre; certum significa certeza en latín.

certum en este momento, cuenta con todos los componentes estructurales que las
fábricas de software requieren, además, obtuvimos una evaluación de tercera parte
realizado por el Bootstrap Institute con sede en Finlandia[4] que ubica nuestro nivel
de capacidades promedio en 3.75. Nuestro perfil de capacidades equivale a un
nivel 3 CMM que es el modelo/métrica norteamericana. Esto dada nuestra
definición, nos ubica como una Fábrica de software de tipo Básica.

Consideramos llegar a un nivel de capacidad 4 durante durante el primer semestre

de 1999, con esto llegaremos en nuestra definición a ser la primera fábrica de
software de tipo Avanzada en México y muy probablemente de América latina.

5 CONCLUSIONES

La industria está madurando a pasos acelerados. Es nuestra responsabilidad como

proveedores y como compradores acelerar y profesionalizar nuestras ofertas y
demandas. Los proyectos nacionales en informática requieren de empresas con
capacidades reales y funcionarios/ejecutivos competentes y exigentes. La
definición propuesta se basa en elementos, que aunque desconocidos aún para
muchos en México, se encuentran en aplicación en países, clientes y proveedores
de avanzada. Es nuestra oportunidad de avanzar más que polemizar.

[1] www.certum.com
[2] Bootstrap 3.0 es compatible con ISO 15504
BIBLIOGRAFIA

1. Schulmeyer Gordon, Zero Defect Software, McGraw Hill 1990.

2. Marciniak John, Encyclopedia of software engineering, John Wiley&Sons,

Inc 1994.

3. Capers Jones, Assessment and control of software risks, Yourdon Press

1994.

4. Material del estudio de MCC/SEI en el Tour a fábricas japonesas sobre

ingeniería de software de 1996 (www.mcc.com/projects/ilo/wais/stt/sejapan)

5. Reporte sobre el estado del mercado de software japonés de 1994, Japan

economic institute report (www.gwjapan.com/ftp/pub/policy/jei/1994/a-
series/0401-94a.txt)

6. Proceedings of the First World Congress for Software Quality, 1995.

7. Bracho Felipe, Díaz Arnoldo, “La cadena virtual de producción: Hacia una
fundamentación de la Reingeniería”, Soluciones Avanzadas, XXX 1995.

8. Cadena Eduardo, “ISO 9000, una visión general”, Soluciones Avanzadas,

Abril 1996.

9. Diaz Arnoldo, “Un estándar Internacional para la evaluación de procesos de

desarrollo de software ISO/SPICE”, Soluciones Avanzadas, Marzo 1996.

10. Durán Sergio, “Bootstrap, El Estándar Europeo para Evaluación y Mejoras

de Procesos de Desarrollo de Software”, Soluciones Avanzadas, Octubre
1996.

11. Padua Marcela, “certum”, Soluciones Avanzadas, Marzo

1998.(http://www.certum.com).

Alberto Balderas es Licenciado en Ciencias de la Computación de la BUAP-

Puebla, Diplomado en Arquitecturas Avanzadas de LANIA. Es Director de
Desarrollo de Negocios en certum.
Email: [email protected]

Arnoldo Díaz es Maestro en Dirección de Empresas del IPADE y representante de

México ante ISO en materia de tecnologías de información e ingeniería de
software. En Junio de 1995 fue votado por unanimidad ISO 15504-5 Project Editor.
Es Director General de certum.
Email: [email protected]