CMM6

Capítulo 6: Un Ejemplo de Alta Madurez: Software de a
Bordo de una Cámara Espacial.
6.1 Introducción
Antes de cualquier lanzamiento de una cámara espacial, los administradores del
proyecto de Software de a bordo de la Cámara Espacial (de aquí en más llamado
Onboard Shuttle) en IBM-Houston1 firman un Certificado de Aptitud para el Vuelo, en
donde dan testimonio que no hay fallas conocidas en el software de vuelo de la cámara
que pondría en riesgo a la cámara o a su tripulación. Durante más de una década el
equipo del proyecto Onboard Shuttle ha luchado para asegurar que no hubiera fallas en
el Sistema de Software de Aviación Primaria de Cámaras Orbitales Espaciales (software
de vuelo) cuando se entregan nuevas ediciones al Centro espacial Johnson de la NASA.
Para satisfacer los requerimientos de la NASA de software que cumpla con los
estándares más altos de seguridad y confiabilidad, el proyecto Onboard Shuttle
evolucionó un proceso de software que arroja un resultado de calidad altamente
predecible. El equipo creyó que, dado un proceso definido que produce productos a un
nivel de calidad conocido, la mejor forma de asegurar que el próximo producto exhibirá
la misma calidad es ejecutar el proceso fielmente de acuerdo a un estándar de proceso.
Después de dos décadas de trabajo, el software de vuelo de la cámara se está
desarrollando usando un proceso que exhibe algunas de las mismas características
exhibidas por los procesos de fabricación bajo control de calidad estadística. Como
resultado, el software de vuelo producido por este proceso predeciblemente tiene cerca
de cero defectos, lo que le da a los administradores del Onboard Shuttle la confianza de
que han cumplido con los requerimientos para firmar el Certificado de Aptitud para el
Vuelo.
La última falla conocida relacionada con la seguridad que ocurrió a bordo
durante una misión se detectó en Octubre de 1986, y sólo una falla de software (un
anuncio benigno de falla en 1989) ha ocurrido durante en vuelo desde 1985. La Figura
6.1 muestra la historia de fallas desde 1988 del software del Onboard Shuttle después de
ser entregado a la NASA. Estos datos incluyen fallas que ocurrieron durante las pruebas
de la NASA, durante su uso en simuladores de vuelo, durante el vuelo, o durante
cualquier uso por otros contratistas. Cualquier comportamiento del software que se
desvíe de los requerimientos de cualquier manera, por más benigno que sea, constituye
una falla. Haga un contraste entre este nivel de compromiso con la actitud arrogante
expresada hacia los usuarios en la mayoría de las garantías que ofrecen los vendedores
de software de computadoras personales.
Gracias a las mejoras continuas al proceso de software, el proyecto Onboard
Shuttle logró dos órdenes de reducción de magnitud en los defectos que entregaba por
1
En este capítulo describiremos el trabajo que originalmente se desarrolló en la Compañía de Sistemas
Federales de IBM en Houston, Texas. En la primavera de 1994 está organización se vendió a Loral
Corporation y se ha fusionado con la División de Sistemas de Información Espacial de Loral. Los
primeros tres autores de este libro visitaron este proyecto durante tres días en Septiembre de 1993, y este
capítulo se desarrolló a partir de sus observaciones. Estamos en deuda con Ted Keller, quien arregló esta
visita y proporcionó oportunidades para ver de primera mano el proceso en funcionamiento. También le
estamos agradecidos a Julie Bernard, Shirley Demerson, Barry Eiland, Maureen Judd, Karen Kelley,
Barbara Kolkhorst, bla bla bla, por sus informes y observaciones. Los números que se presentan en este
capítulo se usan con permiso del proyecto Onboard Shuttle. Para información adicional sobre este
proyecto recomendamos un artículo excelente en el IBM Systems Journal [Billings94].
cada mil líneas de código, y un 300% de mejora en la productividad desde que comenzó
las mejoras a mediados de 1970. Recientemente la NASA le otorgó la continuación de
10 años del contrato al proyecto Onboard Shuttle sin una licitación de competencia. Esta
recompensa se justificó con el argumento de que el contratista actual poseía cualidades
únicas y que era la única entidad que se supiera que podía realizar el proceso que estaba
produciendo los resultados que la NASA requería.
Los resultados de la evaluación de la capacidad del software realizada en 1989 se
informaron de la siguiente manera: “El equipo de Relevo SRM&QA de los Cuarteles
Generales de la NASA ha determinado que el Proyecto de Software de Vuelo está en el
Nivel 5”. El proyecto Onboard Shuttle ha sido nombrado dos veces como Mejor
Laboratorio de Software de IBM y es el único contratista que ha recibido dos veces el
Premio a la Excelencia de la NASA. Para comprender cómo se comporta una
organización en los niveles de madurez más altos, este capítulo describe el proyecto
Onboard Shuttle según ha evolucionado en las 2 últimas décadas.
6.2 Background
6.2.1 El Producto
El software de vuelo de la cámara (Sistema de Software de Aviación Primaria) es
responsable de las funciones de guía, navegación y control de vuelo realizadas durante
todas las fases del vuelo de la cámara (Fig. 6.2). Además, el software soporta todas las
funciones de interfaz entre la cámara y las operaciones de piso, monitorea y administra
todos los sistemas de a bordo, realiza la detección y el anuncio de las fallas, y realiza la
verificación y procedimientos de seguridad de la cámara. El software de vuelo consiste
de aproximadamente 420.000 líneas de código que se ejecutan en las computadoras de a
bordo de la cámara. Aunque el componente del sistema operativo está escrito en
assembler, el resto del software de vuelo está escrito en HAL/S.
Durante las fases críticas del vuelo de la cámara (por ejemplo ascenso,
re-entrada) el software de vuelo se ejecuta en redundancia en 4 o 5 de las computadoras
de a bordo de la cámara, creando requerimientos extraordinarios de sincronización en
tiempo real. En caso de que el software primario de vuelo experimente una falla seria
hay un sistema de vuelo de respaldo desarrollado en forma independiente por otro
contratista. Debido a la confiabilidad del sistema primario, este sistema de respaldo
nunca se ha usado durante el vuelo.
El proyecto Onboard Shuttle también desarrolla y mantiene 1,7 millones de
líneas de Herramientas de Aplicación del Software de Vuelo que soportan la
administración de la configuración, construcciones de software, pruebas y simulaciones,
verificación automática, y re-configuración del software. Estas herramientas corren en
una computadora equivalente a una IBM S/370 y se necesitan para desarrollar, probar,
integrar y administrar el software de vuelo.
6.2.2 El Ciclo de Vida
El proyecto Onboard Shuttle consiste de una serie evolutiva de ediciones, llamada
incrementos operacionales, cada uno de los cuales agrega una funcionalidad incremental
al software de vuelo. El software de vuelo para cada una de las seis primeras misiones
de la cámara consistía del software de la misión previa más funciones agregadas. A
medida que la frecuencia de vuelos aumentó, se volvió necesario desacoplar el proceso
de desarrollo del software de las operaciones de la cámara. De esta manera, en 1986 el
desarrollo de nuevas funcionalidades se separó de la reconfiguración del software para
soportar cada lanzamiento. Las nuevas funcionalidades se agregan a través del proceso
de desarrollar nuevos incrementos operacionales. Una organización separada es
responsable de las operaciones de la cámara (no el proyecto Onboard Shuttle) y de
reconfigurar el incremento operacional actualmente en uso al perfil de misión único de
cada lanzamiento.
Hacia fines de 1993 se habían entregado 17 incrementos operacionales a la
NASA. Mientras que cada incremento operacional se desarrolla siguiendo el modelo de
cascada, el modelo operacional para el proyecto es evolucionario e iterativo. Cada
incremento operacional se desarrolla en tres fases:
1. Definición de los requerimientos del cliente
2. Diseño, desarrollo e integración del software
3. Verificación independiente
Cada incremento operacional tarda unos dos años en desarrollarse, y su
desarrollo se superpone de manera que haya una edición cada 12 meses. Estas fases son
seguidas por un soporte operacional continuo del software de vuelo editado. Antes de
cada lanzamiento de la cámara, otro contratista reconfigura el software genérico de
vuelo para soportar los requerimientos específicos de la misión del vuelo venidero. El
personal del Onboard Shuttle prueba y certifica la corrección del software reconfigurado
a ser cargado en la cámara antes de firmar el Certificado de Aptitud para el Vuelo.
6.2.3 Características del Proyecto
El proyecto Onboard Shuttle emplea aproximadamente 270 personas. Debido a los
requerimientos de confiabilidad y seguridad extremos, el 26% de este personal está
involucrado en la verificación del software de vuelo, pero sólo un 18% está involucrado
en su desarrollo (Fig. 6.3). El equipo de verificación es independiente del equipo de
desarrollo, y tiene su propia cadena de informes a la administración. Muchos de los
integrantes del personal son jóvenes y extremadamente diversos. Las nuevas
contrataciones se asignan inicialmente al proyecto Onboard Shuttle para adquirir los
hábitos de desarrollo rigurosos que luego pueden pasar a otros proyectos. Generalmente
el personal permanece con el proyecto Onboard Shuttle de 5 a 7 años antes de ser
transferido a otro proyecto.
El entorno que rodea al proyecto Onboard Shuttle constantemente cambia los
requerimientos. Ocasionalmente la NASA cambia los requerimientos tarde en un
incremento operacional debido a prioridades funcionales para un vuelo venidero. Las
fechas de los vuelos también cambian. Para responder efectivamente en este entorno sin
sacrificar la calidad del producto, el proyecto Onboard Shuttle encontró que tenía que
haber un proceso definido formalmente para asegurar que los pasos cruciales no se
saltearan en un intento de satisfacer al cliente. El equipo encontró que la mayoría de las
herramientas de administración automatizadas del proyecto no eran suficientes para tal
entorno dinámico, y que muchas funciones de administración se realizaban de una
manera más efectiva de forma manual.
6.3 Enfoques a la Mejora del Proceso
6.3.1 Historia de Mejoras
Para satisfacer los requerimientos de la NASA de un software con efectos cercanos a
cero, el proyecto Onboard Shuttle hizo mejoras continuas a su proceso de software
comenzando en la década de 1970 (Fig. 6.4). Estos cambios, a veces apareados con
mejoras en la tecnología, se consideraron como el medio más efectivo para que el
producto cumpliera con los requerimientos de la NASA en cuanto a un desempeño libre
de fallas. Algunos de los cambios más importantes se describen en las secciones
siguientes.
El proyecto Onboard Shuttle identificó 4 obstáculos primarios que inhibían la
producción de software de alta calidad. El primer inhibidor era una pobre
administración del proyecto, especialmente la incapacidad de administrar con
limitaciones establecidas por el costo, cronograma, funcionalidad y calidad. El segundo
era sacar los proyectos por el cronograma y no por la calidad. El tercer inhibidor era la
falla al controlar los contenidos de los requerimientos y líneas base del producto de
software. El cuarto era la falla en el rastreo de errores y en hacer cambios al proyecto
que eliminaran sus causas.
El programa de mejoras continuadas al proceso que implementó el proyecto
Onboard Shuttle durante las dos últimas décadas ha sido diseñado para superar y
eliminar estos inhibidores de manera sistemática. En algunos casos, los cambios al
proceso tardaron hasta dos años en demostrar resultados. Sin embargo, los cambios
agregados en las diferentes áreas a lo largo del tiempo se combinan para demostrar una
mejora continua y estable en los resultados del proyecto. El proyecto informó un 300%
de mejoras en la productividad y una reducción de dos órdenes de magnitud en las tasas
de defectos.
6.3.2 Planeamiento de la Administración del Proyecto y Rastreo y
Coordinación Entre Grupos
El proyecto Onboard Shuttle heredó una gran capacidad de administración de
proyectos de la Compañía Federal de Sistemas de IBM que había sido desarrollada en
otros programas de la NASA desde la década de 1960. El proyecto Onboard Shuttle se
administra con una serie de paneles de control que son un paralelo de paneles de control
similares establecidos por la NASA (Fig. 6.5). Esta estructura paralela entre los paneles
del proyecto y del cliente establece un único punto de contacto para cada una de las
funciones cruciales para el cliente. Los paneles de nivel superior en esta estructura son
el Panel de Control de Línea Base del proyecto Onboard Shuttle y el Panel de Control de
Configuración de la NASA.
Cada uno de los paneles de control del proyecto Onboard Shuttle proporciona un
punto de coordinación sobre un tema crucial a lo largo de todo el proyecto. Cada panel
tiene un titular y representantes de cada área funcional relevante en el proyecto Onboard
Shuttle. A través de esta estructura funcional cruzada, los equipos del Onboard Shuttle
pueden comprender mejor las interdependencias de sus decisiones en todo el proyecto.
Los paneles proporcionan un foro de apoyo común para presentar inquietudes que
afectan a otros grupos.
Estos paneles contrarrestan la tendencia natural de construir feudos funcionales
en los que los managers pueden tratar de proteger sus propias operaciones a expensas de
todo el proyecto. Los titulares de estos paneles presentan su informe al administrador
del personal, que es independiente de los administradores operacionales. De esta manera
el proyecto Onboard Shuttle tiene una estructura de administración tanto vertical como
horizontal, cada una de las cuales tiene diferentes roles y áreas de autoridad. Los
managers senior del proyecto creen que esta estructura es necesaria en cualquier
proyecto que involucre a tres o más administradores funcionales (o sea, cualquier
proyecto de aproximadamente 60 personas).
Los miembros del Panel de Control de Línea Base del proyecto son managers de
segunda línea, titulares de panel de otros paneles, y coordinadores de proyectos
específicos. Con responsabilidad para compromisos para contenido de software,
cronogramas y recursos, este panel tiene la autoridad de establecer prioridades de
proyectos, de resolver temas técnicos entre proyectos, de coordinar posiciones de
proyectos integrados, y de supervisar los procesos de software.
Cuando se aprueba la línea base de un incremento operacional, los coordinadores
líderes del software esbozan un plan de construcción que consiste de los contenidos y
fechas para diversas construcciones. Esto se coordina con los administradores de línea y
se negocia con el cliente si es necesario. El Panel de Control de la Línea Base resuelve
cualquier conflicto y hace la línea base del plan. Las fechas se proponen sólo después de
que cada organización ha opinado sobre la fecha propuesta.
El Panel de Control de la Línea Base se reúne todas las semanas para revisar el
estado del proyecto y de las áreas de interés. Los contenidos de las construcciones de
software cuyos constituyentes vienen de grupos diferentes se alteran sólo con la
aprobación del panel, lo mismo que los cambios en la fecha de construcción. El panel
tiene la responsabilidad de asegurar que nunca se sacrifica la calidad por presiones de
cronograma. El titular del Panel de Control de la Línea Bases responsable de monitorear
el uso de recursos en todo el proyecto y de determinar los impactos del esfuerzo y del
cronograma de los cambios de requerimientos.
El proyecto Onboard Shuttle mantiene un buffer de esfuerzo de proyecto no
comprometido para poder absorber cambios que requieran un esfuerzo adicional sin
tener que renegociar las bases de la entrega. Cuando este buffer parece estar a punto de
agotarse, el Panel de Control de la Línea Base es el responsable de renegociar con la
NASA y de revisar los planes del proyecto. Como el proyecto Onboard Shuttle es un
contrato de nivel de esfuerzo (costo fijo), las negociaciones se hacen en cuanto a las
bases de la entrega o a la funcionalidad entregada. Con el tiempo, el proyecto y la
NASA han aprendido a equilibrar las cargas de trabajo a través de los incrementos
operacionales de una manera más efectiva para evitar un sobre-compromiso contra el
nivel de esfuerzo contratado.
El Panel de Revisión del Informe de Discrepancia maneja los problemas
informados con respecto al software de vuelo. Estos informes pueden venir de
miembros del proyecto Onboard Shuttle, de otros contratistas o de la NASA. El panel
determina la posición del proyecto Onboard Shuttle en un problema y su resolución, y
desarrolla una posición acerca de cuándo y cómo debe solucionarse el problema (por
ejemplo, el siguiente vuelo, el siguiente incremento operacional, etc.) El panel presenta
su recomendación al Panel de Control de Configuración de la NASA y le da a la NASA
un único punto de contacto con el proyecto Onboard Shuttle para resolver problemas
potenciales del software.
El Panel de Revisión de Requerimientos es responsable de asegurar un equilibrio
adecuado entre el contenido de la línea base operacional y la disponibilidad de los
recursos requeridos para construirla y verificarla. Este panel revisa los contenidos
propuestos para cada incremento operacional y asegura que haya recursos adecuados
disponibles para implementarlo en el tiempo propuesto. En cada incremento operacional
este panel monitorea los contenidos de la línea base, los cambios propuestos a la línea
base, y la utilización de recursos par asegurar que el proyecto Onboard Shuttle no se
sobrecomprometa. Este panel revisa cada cambio propuesto del software y determina los
riesgos asociados si se hace el cambio en el contexto de la disponibilidad de recursos y
otros cambios propuestos.
A medida que fue necesario se fueron creando otros paneles. Por ejemplo, hay un
panel para controlar “parches” al software. Más aun, se ha construido un conjunto
similar de paneles para el software de soporte. Los paneles se crean cuando hay un tema
fundamental que debe manejarse cuidadosamente y coordinarse entre varios grupos
diferentes que forman parte del proyecto.
El rol de los administradores del proyecto ha evolucionado dramáticamente a
medida que estos paneles de control asumieron sus responsabilidades. La administración
ahora está menos involucrada con el seguimiento del progreso (los paneles hacen eso
ahora) y más involucrada con los recursos y la administración del personal. Por ejemplo,
aseguran continuamente que haya personal apropiadamente entrenado como refuerzo
para cualquier posición crítica del proyecto.
Las responsabilidades tradicionales de la administración han sido delegadas a los
paneles de control. Los administradores se sienten cómodos delegando estas
responsabilidades debido al poder del sistema de medición. Las mediciones les
proporcionan información continua sobre el estado del proyecto y les permiten tomar
acción sobre una base de excepción. Debido a su confianza en las mediciones y a los
sistemas de panel de control, los administradores le han dado poder a los niveles más
bajos de la organización para manejar los procesos ordinarios que se realizan en el
proyecto. La administración del proceso se libera para enfocarse en temas estratégicos y
operacionales a largo plazo.
Los administradores del proyecto Onboard Shuttle se desarrollan a partir del
personal existente del proyecto. Los estilos tradicionales de administración son
inconsistentes con el nivel de poder dado al personal técnico del proyecto. Por ejemplo,
en organizaciones de baja madurez, la mejora del proceso es de arriba hacia abajo (top
down), mientras que en el proyecto Onboard Shuttle la mejora del proceso es de abajo
hacia arriba (bottom up), ya que el proceso ha sido internalizado y el personal tiene
poder para mejorarlo. Incluso las personas que han administrado en otros lados no
tienen permitido asumir responsabilidades de administración inmediatamente después
de haberse unido al proyecto. Primero deben trabajar en el proyecto durante varios años
para entender el proceso y el rol de los managers dentro de un ambiente participativo.
6.3.3 Control de la Configuración
La medición y el control de la configuración se establecieron en los comienzos del
proyecto Onboard Shuttle. El control de la configuración se hizo riguroso y formal en
1980. No obstante, una gran parte del rastreo o seguimiento se seguía haciendo
manualmente. En 1982 se estableció una base de datos para la administración de la
configuración, diseñada alrededor de buenas prácticas de administración de software.
Un año más tarde las construcciones de software se automatizaron usando la base de
datos de administración de la configuración para definir las entradas y salidas adecuadas
con respecto a los requerimientos. En donde era posible, la automatización del control
de la configuración y de la verificación de errores mejoró la productividad porque liberó
al personal de tener que realizar estas tareas.
Es notable que el proyecto Onboard Shuttle haya implementado originalmente la
administración de la configuración sin una biblioteca (library) automatizada. En vez de
eso, los datos de la configuración se mantenían en papel. No obstante, el objetivo de
controlar la configuración de los productos de trabajo se lograba. Con el tiempo se
agregó un refuerzo tecnológico cuando hubo herramientas adecuadas. Sin embargo, el
enfoque primario era lograr los objetivos de la administración de la configuración más
que esperar a que hubiera herramientas automatizadas.
Los procedimientos del control de la configuración rastrean varios atributos
relacionados con el proceso para cada línea individual. Por ejemplo, para cada línea de
código en el software de vuelo es posible determinar en qué edición fue creado el código
y su historial de cambios en todas las ediciones siguientes. De esta manera es posible
identificar durante qué incremento operacional se inyectó una falla recientemente
descubierta. Aproximadamente el 8% de las fallas detectadas por la NASA está en
líneas de código que han estado en el sistema por más de 10 años. Los métodos de
verificación y desarrollo mejorados han sido extremadamente efectivos al sacar las
fallas en las funciones agregadas durante los incrementos operacionales siguientes.
6.3.4 Administración de Requerimientos
En 1979 el grupo de análisis de requerimientos y el grupo de verificación de la
performance se combinaron en una única función. De esta manera, los que analizan los
requerimientos también verifican el desempeño del sistema implementado. En 1984 el
proceso de análisis de requerimientos se definió y requirió formalmente. El análisis se
enfocó en determinar si los requerimientos eran implementables, permitiendo que los
temas y problemas de requerimientos se trataran con el cliente mucho antes de ser
implementados.
En 1986 se implementaron inspecciones formales sobre los requerimientos. Los
moderadores no firmaron las inspecciones hasta que todos los temas hubieran estado
cerrados o hasta que hubiera una resolución lo suficientemente clara que indicara que el
riesgo que representaba ese tema había sido mitigado. En el proyecto Onboard Shuttle
se comenzaron a rastrear datos sobre temas y problemas internamente. Dentro del año
de la instalación de las inspecciones de requerimientos la cantidad de problemas y temas
presentados había disminuido en un 75%, en parte porque el cliente se concientizó de
los temas relacionados con los requerimientos. Las inspecciones de requerimientos se
realizaban ahora antes de aprobar la línea base para el incremento operacional.
A mediados de los 80 ocurrió un cambio en la actitud hacia los requerimientos
por parte de los analistas de requerimientos. Anteriormente los requerimientos se habían
tratado como un producto de la NASA que había que comprender y analizar para ver si
era correcto. Después de la introducción del proceso de inspección de los
requerimientos, los analistas de los requerimientos aceptaban la calidad de los
requerimientos como su propia responsabilidad. Aceptar la propiedad de la calidad de
los requerimientos era parte de un cambio cultural mayor. Dentro de esta cultura, un
pedido de cambio se considera un problema de requerimientos y se analiza para
determinar cómo podría mejorarse el proceso de escribir los requerimientos para reducir
cambios en el futuro.
Un estudio a mediados de los 80 indicó que el 20% de los errores eran causados
por una mala interpretación de los requerimientos. Como resultado, los analistas de
requerimientos comenzaron a asegurarse que los requerimientos estuvieran
documentados de manera que el comportamiento esperado por parte del sistema no
fuera ambiguo. Los problemas de requerimientos o ambigüedades que solían aceptarse
ahora se escriben en informes de discrepancia para asegurarse de eliminarlos en una
etapa temprana como fuente de fallas. Para asegurar una comunicación precisa de
intenciones entre los clientes y los desarrolladores se usan métodos como reuniones
conjuntas para facilitar el diálogo. También sirven como puntos de unión entre los
clientes y los desarrolladores a lo largo de todo el proyecto.
En 1990 se instituyeron inspecciones basadas en el escenario para ayudar a las
organizaciones de verificación y desarrollo a comprender mejor los requerimientos y la
capacidad que se espera que creen. Un año más tarde el proceso de requerimientos fue
formalmente documentado por un equipo que tomó la responsabilidad por los procesos
de requerimientos. En la Fig. 6.6 se presenta un resumen del proceso de administración
de los requerimientos. Se agregó un postmortem de requerimientos para determinar las
fortalezas y las debilidades del proceso de manera que se pudieran implementar cambios
al proceso en el siguiente incremento operacional. Los procesos de requerimientos
cambiados eran la línea base en el inicio de los incrementos operacionales más
recientemente editados.
Las mejoras más recientes al proceso de administración de requerimientos
incluyen el estudio de los beneficios potenciales de adoptar métodos formales para
enunciar los requerimientos e inspeccionar las interfaces para tratar temas relacionados
con la interfaz durante el análisis de requerimientos. El proyecto continúa buscando una
metodología más consistente para documentar los requerimientos. Los métodos de
escribir los requerimientos se han investigado como una forma de reducir diferencias
innecesarias en estilos de documentar los requerimientos por parte de diferentes
escritores.
6.3.5 Inspecciones y Revisiones de los Pares
El software de vuelo se desarrolló usando flujos estructurados desde el comienzo del
proyecto Onboard Shuttle. Se impuso la programación estructurada, y sólo se
permitieron construcciones bien definidas. Sin embargo, la programación estructurada
no fue suficiente para eliminar los defectos del producto. En 1978 se requirieron
inspecciones formales del software tanto para el diseño como para el código. En 1979 se
requirió que todas las inspecciones tuvieran moderadores entrenados en cómo conducir
inspecciones del estilo Fagan [Fagan76].
A comienzos de la década del 80 se designó un moderador jefe, y los equipos de
moderadores y personal líder de software comenzaron a analizar las debilidades de la
inspección que permitían que algunos defectos del software no fueran detectados en el
proceso de inspección. Este fue un ejemplo temprano de análisis del proceso de
software. Aunque el proceso de inspección está formalmente definido con roles
explícitos, se puede ajustar para atender los atributos únicos de las diferentes áreas
funcionales.
Las inspecciones han probado ser una de las técnicas más poderosas empleadas
para mejorar la calidad del producto. El enfoque en la detección temprana de errores
cambió los costos del proyecto de las fases de testeo y verificación a las fases de
diseño e implementación, en donde los costos de arreglar los errores eran menores. El
proyecto ha establecido que si el costo de reparar un error es de $1 durante una
inspección , se elevará a $13 durante el testeo del sistema y a $92 si debe arreglarse
después de la entrega. Como puede verse en la Fig. 6.7, el porcentaje total de fallas
inyectadas detectadas antes de las pruebas de verificación ha crecido continuamente
desde menos del 50% hasta justo por encima del 80%. Esta mejora en el porcentaje es
aun más impresionante, ya que la cantidad de defectos inyectados en el software por
cada mil líneas de código ha caído continuamente con los incrementos operacionales.
De esta manera es claro que el proyecto Onboard Shuttle ha estado instalando procesos
que resultan en menos defectos que los que se detectaban antes.
6.3.6 Ingeniería del Producto de Software
6.3.6.1 Prototyping
En 1985 el proyecto Onboard Shuttle comenzó en conjunto con la NASA a explorar el
uso de los cambios propuestos por el prototyping al software crítico antes de hacer un
compromiso fuerte a un nuevo conjunto de requerimientos. Cada prototipo era una
versión exploratoria de un incremento operacional que había sido desarrollado usando
una versión expeditada del proceso de desarrollo estándar. El prototipo permitía que el
proyecto y el cliente identificaran los errores en los requerimientos antes de
comprometerse con los requerimientos formales para un incremento operacional y que
identificaran algunos errores de diseño y de codificación a ser evitados durante la
implementación completa. El proyecto informó mejoras sustanciales de calidad debido a
haber encontrado fallas en los requerimientos, diseño y codificación en los prototipos y
no en el código producto.
El prototipo nunca se tomó como punto de partida para el producto, sólo como
una base para clarificar los requerimientos. Cuando los requerimientos habían sido
determinados, el prototipo se ponía a un lado. El software de vuelo entregable se
desarrollaba a partir de los requerimientos revisados usando el proceso de desarrollo
definido y estándar del proyecto.
6.3.6.2 Verificación Independiente
Una gran parte del costo del software de vuelo estaba en la verificación de la existencia
para certificar la aptitud del software de la cámara. En la década del 70 la verificación
del software de vuelo se asignó a una organización que era independiente desde el punto
de vista de la administración con respecto al equipo de desarrollo del software. O sea,
aunque eran parte del proyecto Onboard Shuttle, su cadena de administración presentaba
sus informes directamente al administrados general del proyecto, y era lateral e
independiente de la del personal de desarrollo.
El proceso de verificación fue diseñado para lograr los objetivos aparentemente
contradictorios de proporcionar verificadores con conocimiento sobre el software y los
requerimientos y asegurar que condujeran las pruebas como si estuvieran testeando un
software no testeado. Por ejemplo, en la década del 80 el personal de verificación estaba
incluido en las inspecciones de código y diseño, pero para proteger su independencia no
asistían a revisiones de temas relacionados con el testeo del desarrollo como por
ejemplo planes de tests funcionales y unitarios. La inclusión de testeadores de
verificación en las revisiones de código y diseño aumentó considerablemente la
detección temprana de defectos, ya que los testeadores encontraron tanto como un 20%
de problemas de revisión. Los productos producidos por testeadores de verificación
como planes de testeo, documentos de testeo, y casos de testeo se mantuvieron bajo el
control de la configuración.
En 1981 se documentaron las técnicas de verificación, y un año más tarde se
implementó el almacenamiento de datos de error en el sistema de administración de la
configuración. Se almacenaron prólogos (comentarios) en módulos de códigos que
describían la autorización de cambios, las líneas cambiadas, etc. Más tarde también se
almacenaron prólogos similares con casos de prueba, y se volvieron datos importantes
para identificar las causas de los defectos de los procesos. El personal de verificación
comenzó a asistir a las inspecciones de diseño y de código cuando se observó que más
del 50% de todos los defectos se encontraban a través del análisis estático y de las
inspecciones de código. En 1984 se desarrolló un sistema de prueba del estado del caso
para ayudar en el proceso de rastreo, y un año más tarde se desarrolló una biblioteca
(library) automatizada de los casos de prueba. Al mismo tiempo se comenzaron
inspecciones de los procedimientos de las pruebas de verificación. En 1986 se adoptó
una herramienta de análisis de cubrimiento de prueba en el proceso de verificación.
Hacia fines de la década del 80 se estableció una comunicación más amplia entre
el personal de verificación a través de foros electrónicos para intercambiar consejos,
soluciones y cosas por el estilo. También se realizaron reuniones para asegurar que se
cubrieran y coordinaran todas las interfaces entre las áreas funcionales. También se hizo
más énfasis en una definición más temprana del plan de prueba de verificación y de su
completado sobre la base de los puntos más importantes del proyecto.
En 1991 se formó un equipo de propiedad del proceso de verificación. El Panel
de Control de las Herramientas proporcionó una mayor visibilidad y acceso a las
herramientas de análisis y prueba desarrolladas por miembros del personal de
verificación. Un año más tarde se desarrollaron equipos de pruebas funcionales para
asegurar que los nuevos miembros del personal aprendieran las técnicas de verificación
aplicables a su área particular de los miembros experimentados del personal. Por medio
de este mecanismo se desarrollaron capacidades de respaldo para áreas importantes, y
pudo balancearse mejor la carga laboral. Para expandir el conocimiento y los casos de
pruebas disponibles para áreas menos activas del software de vuelo que pudieran ser
candidatas a futuros cambios, se está explorando la realización de pruebas más allá que
las requeridas por el incremento operacional actual.
El enfoque estructurado llevado al proceso de verificación contribuyó
fuertemente a encontrar esencialmente todos los defectos antes de entregarlo al cliente.
La Fig. 6.8 muestra la marcada disminución en la cantidad de defectos por cada mil
líneas de código que se detectan durante las pruebas de verificación. Estos datos deben
interpretarse en el contexto de una cantidad decreciente de defectos que pasan
inadvertidos durante el desarrollo y a la pronunciada disminución de la cantidad de
defectos entregados a la NASA. El proceso de verificación definido incluía el desarrollo
e inspección de un plan de pruebas de verificación, el control formal de los casos de
prueba, y la documentación y revisión del cliente de los resultados de los casos de
prueba y de los cerramientos de temas.
6.3.7 Administración de la Calidad del Software y Prevención de Defectos
Para el proyecto Onboard Shuttle, una falla del software es cualquier desempeño del
software que se desvíe de los requerimientos especificados, sin importar cuán
insignificante sea. Sin embargo, si ocurre un problema que puede rastrearse hasta un
requerimiento incorrecto más que a una falla en el software, entonces se cuenta como
falla de requerimientos, no como una falla del software. Esta separación estricta entre
fallas de los requerimientos y las fallas genéricas de software del software de vuelo es
crucial, ya que los datos del proyecto pueden usarse sólo para determinar la fidelidad
con la que se han implementado los requerimientos en un producto de software. Estos
datos no son relevantes para la calidad de los requerimientos o del proceso mediante el
cual se desarrollaron los requerimientos, ya que estos procesos están fuera del alcance
del proyecto Onboard Shuttle. Sin embargo, el proyecto Onboard Shuttle ha dado pasos
para mejorar el proceso de desarrollo de los requerimientos.
Cada tanto el Panel de Informes de Discrepancia conducía análisis de fallas
detallados que eran de particular interés para la NASA. En 1983 se estableció un
análisis general formal. Las fallas se analizaban ahora por sus causas y las razones por
las que las inspecciones, pruebas y actividades de verificación siguientes fallaron en
detectar las fallas. Esta práctica ha evolucionado hasta llegar al proceso de prevención
de defectos de cuatro etapas que se presenta en la Fig. 6.9.
En la primera etapa se analizan las fallas en cuanto a su causa técnica y se hacen
las correcciones para eliminarlas. En la segunda etapa se identifica la causa del proceso
de la falla, y se cambia el proceso para eliminar la posibilidad de un error subyacente
que ocurra en el futuro. En la tercera etapa se mejoran todas las inspecciones pruebas y
procedimientos de verificación que no detectaron la falla, de manera de detectar fallas
similares en el futuro. En la etapa final si se usaron funciones similares en otras partes
del software de vuelo, esas áreas del producto se vuelven a inspeccionar para determinar
si una falla similar ha pasado sin detectar en otro lugar del sistema. Los resultados de
estos análisis se registran, y se investigan las tendencias en los datos.
Parte del análisis de las causas raíz de las fallas del software requiere la
construcción de un escenario detallado de cómo usó el software la persona que
experimentó la falla. Las lecciones aprendidas basándose en estos escenarios se
retroalimentan al proceso de desarrollo. La identificación de los escenarios de uso ha
sido especialmente efectiva para mejorar la capacidad del proceso de verificación para
detectar fallas que podrían ocurrir bajo condiciones de baja probabilidad. El poder de los
escenarios de uso ha sido tan grande que ahora se generan como parte del análisis de
requerimientos y del proceso de inspección.
Debido al tiempo necesario, este nivel de prevención y análisis de defectos es
difícil de aplicar cuando el producto está lleno de fallas. Más aun, sería extremadamente
difícil analizar los datos en un entorno en donde los procesos se realicen de una manera
inconsistente. Sin embargo, a medida que el proceso madura y las fallas se capturan
mucho más cerca del punto en que se inyectaron, hay menos fallas y más tiempo
disponible para analizarlas.
En la Fig. 6.10 se presenta el poder de estas actividades de administración de la
calidad. El proyecto Onboard Shuttle comienza rastreando la cantidad de fallas
detectadas durante todas las diversas inspecciones y actividades de prueba comenzando
aproximadamente unos 400 días antes de la entrega de cada incremento operacional. El
resultado de casi dos décadas de mejoras al proceso es que el proceso se lleva a cabo
dentro de límites cuantitativos conocidos. De esta manera el equipo del proyecto espera
encontrar una cierta cantidad de fallas durante cada fase de prueba o inspección. Cuando
no detectan la cantidad de fallas que esperaban encontrar basándose en las tendencias
históricas, el personal del Onboard Shuttle tiene razones para sospechar la posibilidad
de un problema ya sea en el producto o en el proceso.
En la Fig. 6.10 es evidente que el proyecto Onboard Shuttle estaba operando
cerca de los límites superiores de su experiencia en la detección de defectos
comenzando alrededor de 210 días antes de la entrega del Incremento Operacional 22.
Después de analizar su proceso, el personal del proyecto encontró que no habían
actualizado sus intervalos de confianza para la detección de defectos para acomodarse a
la capacidad de detección de defectos acelerada que resultó de las mejoras hechas al
proceso de pruebas. Estas mejoras de las pruebas se hicieron como resultado de
lecciones aprendidas en incrementos operacionales previos.
En 1984 los managers de todos los niveles fueron entrenados en los principios de
administración de calidad y técnicas desarrolladas por Deming, Juran y Crosby. Se
estableció un coordinador de calidad, y se destinaron recursos para mejorar la calidad
tanto del proceso como del producto. Ahora son ejecutivos los que deciden qué medidas
y objetivos de calidad deben establecerse para el proyecto y deben ser informados por
los ejecutivos y administradores responsables cada trimestre. Estos objetivos de calidad
se actualizan periódicamente para reflejar las lecciones aprendidas en incrementos
operacionales recientemente desarrollados. Los objetivos también se actualizan para
desafiar al proyecto a mejorar su desempeño y capacidad de proceso.
Cada grupo o departamento desarrolla las mediciones de calidad para medir los
procesos de los que son responsables. Las definiciones de las mediciones se desarrollan
desde abajo hacia arriba más que de arriba hacia abajo para asegurar su fidelidad al
proceso que miden y la aceptación por parte del responsable del equipo para realizar el
proceso. Se ha encontrado que las definiciones de las mediciones tienen un tiempo de
asentamiento de unos 6 meses. Durante este tiempo se gana experiencia en el uso e
interpretación de las mediciones, y sus definiciones se revisan para mejorar su valor. En
el tiempo, las mediciones se llevan a niveles de granularidad más finos para llevar las
mejoras del proceso más profundo en el proceso en consideración.
Los datos de calidad y del proceso nunca se usan para evaluar a integrantes
individuales del personal del proyecto. El uso de los datos exclusivamente para el
análisis del proceso en una cultura de mejoras continuas al proceso reduce la tendencia
de jugar con el proceso para que las mediciones salgan bien. Los problemas con los
integrantes del personal se ponen en evidencia en otras áreas como incumplimiento del
cronograma. Si un individuo continuamente causa problemas de coordinación en el
proyecto por incumplimiento del cronograma establecido, entonces la administración
tomará cartas en el asunto y administrará el problema de performance. La
administración considerará una cantidad de factores como por ejemplo si el individuo
recibió una tarea para la que no estaba preparado de la manera necesaria.
La NASA se ha involucrado integralmente en la calidad del proyecto Onboard
Shuttle, así como en las actividades de mejora del proceso. La NASA revisa los
resultados de estas actividades por lo menos cada tres meses. Las reuniones de revisión
ocasionalmente se extienden más de lo programado porque el personal de la NASA se
involucra en la interpretación y uso de los datos. El personal de la NASA
frecuentemente pide datos adicionales y nuevas formas de considerar los datos
existentes. Las actividades de mejoras continuas han producido un entorno de confianza
entre el cliente y el proveedor que soporta una sociedad en la mejora de la calidad.
El cliente NASA del proyecto Onboard Shuttle ha hecho cambios basándose en
lecciones que aprendió en el programa de mejoras continuas del proyecto. Han adoptado
una filosofía de proceso y han implementado estructuras de paneles de control con otros
contratistas de manera similar a la que usan en la administración del proyecto Onboard
Shuttle.
En 1988 se inició la modelación de la confiabilidad usando el modelo SMERFS
porque era conservador y funcionaba bien con los datos producidos en el proyecto. Una
vez validados, los resultados se compartían con la NASA. Más recientemente se ha
iniciado la investigación en métricas del software para identificar las características del
software que predicen las fallas o calidad del software. Han observado que la frecuencia
de los problemas de inspección predice la frecuencia de los informes de discrepancia.
Los informes de discrepancia también se predicen por la frecuencia de los cambios de
requerimientos en un área particular.
6.3.8 Administración de Cambios al Proceso
En 1984 un equipo de BM liderado por Ron Radice realzó una revisión de 2 semanas
del proyecto Onboard Shuttle. El procedimiento que se usó en esta revisión fue el
predecesor del método de Evaluación del Proceso de Software que Watts Humphrey
desarrollaría en el SEI. El proyecto sacó 3 de 5 puntos en una escala que era similar,
pero no exactamente igual, al cuestionario SEI de 1987 o al CMM. En 1988 un equipo
de evaluación de proyectos de software integrado por miembros de la NASA, del
Laboratorio de Propulsión Jet, y del SEI, evaluó el proyecto Onboard Shuttle en un nivel
5 usando el cuestionario pre-CMM de 1987. Como resultado de esta evaluación el
proyecto comenzó a enfocarse en formalizar la documentación del proceso y en mejorar
el proceso de educación. En 1990 el personal del proyecto comenzó esfuerzos conjuntos
con expertos académicos y de la industria para marcar las mejores prácticas y adoptar
las que demostraran un potencial para contribuir a la calidad del proceso o del producto.
Otras revisiones contra el criterio del Premio Baldrige hicieron notar la necesidad de
definir procesos para conducir mejoras al proceso.
En 1990 se formaron los equipos de propiedad del proceso para volverse los
dueños técnicos de los procesos. Se han formado equipos de propiedad en 9 áreas:
evaluación de requerimientos, diseño y código, inspección, pruebas de desarrollo,
verificación funcional, herramientas de aplicación, y paneles. Estos equipos de
propiedad de proceso están formados por la gente que lleva a cabo el proceso y que por
lo tanto está en la mejor posición de saber qué mejoras deben hacerse. Los equipos son
responsables de documentar y marcar el proceso, recolectando y analizando las
medidas del proceso; mejorando el proceso y proporcionando educación con respecto al
proceso. Una vez documentados, los procesos se colocan bajo el control de
configuración, y para cambiar el proceso debe ejecutarse un proceso formal de pedido y
aprobación de cambios.
Los líderes de los equipos de propiedad del proceso también participan en un
Equipo de Evaluación del Proceso que incluye a un ingeniero senior como titular, un
representante de la garantía de la calidad, y proveedores y clientes del proceso (a veces
incluso un cliente externo). El rol del Equipo de Evaluación del Proyecto es determinar
el nivel de varios procesos estableciendo un criterio para su madurez. Mientras que el
CMM trata la madurez como un atributo organizacional, esta forma de evaluación del
proceso extiende el concepto de madurez hasta los procesos técnicos. La Tabla 6.1
presenta los criterios generales a partir de los cuales se desarrollan criterios explícitos en
cada una de la 9 áreas de procesos.
TABLA 6.1
Criterios de Evaluación de Procesos
Nivel 1:
- Se documenta y define el proceso.
- Se establecen mediciones de calidad con objetivos realistas para procesos internos y
los que usan los subcontratistas.
- Se acuerdan las mediciones de calidad con el cliente.
- Se establece el equipo de propiedad técnica y comienza a funcionar.
- Se establece un mecanismo de control de la configuración y comienza a funcionar.
- Las debilidades del proceso se consideran contenibles sobre la base de severidades y
tasas de error.
Nivel 2:
- Se establecen las mediciones de satisfacción del cliente con objetivos realistas.
- Se establecen las mediciones de productividad con objetivos realistas tanto para
procesos de subcontratistas como internos.
- El análisis de defectos y el mecanismo de retroalimentación están en su lugar.
-
Los equipos de mejoras al proceso están funcionando.
Se demuestra el progreso en las acciones del proceso.
Se están juntando datos de mediciones de calidad y se establecen tendencias
positivas.
- El programa de entrenamiento para nuevos analistas / programadores está
establecido y funcionando.
- El proceso es efectivo y no existen exposiciones de control u operacionales de
importancia.
Nivel 3:
- Las mediciones de satisfacción del cliente muestran una tendencia positiva hacia un
objetivo aceptable.
- Las mediciones de productividad muestran una tendencia positiva haca un objetivo
aceptable.
- Se logran tendencias positivas continuas en todas las mediciones de calidad.
- Se evalúan nuevas tecnologías o metodologías para el uso del proceso.
- La mayoría de los empleados están involucrados en las mejoras al proceso.
- Se llevan acciones del análisis del proceso / defectos a la implementación.
- Hay un programa de auto-educación continua del proceso.
- Se identifican y aplican métodos de reconocimiento.
- Se establecen mediciones para la simplificación del proceso y reducción de la
duración del ciclo.
- Puede proyectarse la efectividad del proceso.
Nivel 4:
- Se logran tendencias positivas continuas en las medidas de la productividad.
- Se logran tendencias positivas continuas en las medidas de satisfacción del cliente.
- Mediciones de simplificación del proceso y de reducción de la duración del ciclo
muestran una tendencia positiva hacia la aceptación del objetivo.
- Hay planes para comenzar a usar nuevas tecnologías y metodologías.
- Se establecen datos clave y se usan para establecer objetivos de productividad y de
calidad.
- Se incluyen métodos de reconocimiento en el proceso.
- Todos los empleados están involucrados en la búsqueda de una mejora al proceso.
Nivel 5:
- Los productos están libres de defectos (6 sigma)
- Se logran tendencias positivas continuadas en la reducción de la duración del ciclo y
en la simplificación del proceso.
- El proceso es un recurso de industria en tecnología y metodología.
- Las proyecciones del proceso se validan por dos años de comparaciones de
performance real.
- Los datos de la industria indican que este proceso es de excelente raza.
Estos criterios se desarrollaron a partir del CMM, el Premio Baldrge y las guías
internas de IBM. Aunque los criterios de evaluación del proceso están agrupados en 5
niveles como el CMM, una inspección más de cerca indica que estas escalas son
bastante diferentes de la organización de las prácticas clave en el CMM. De hecho,
muchos de los criterios de los niveles más bajos del marco de evaluación del proceso
Onboard Shuttle representan temas que se tratan en los niveles 4 y 5 del CMM. La
definición final de estos criterios para cada área del proceso hace impacto en el nivel de
control esperado en el proceso y la agresividad con la que se persigue la innovación del
proceso.
El Equipo de Evaluación del Proceso establece un nivel de rating esperado para
cada proceso a través de la negociación con los propietarios técnicos del proceso.
Dependiendo de la criticalidad del proceso para la eliminación de defectos, se permite
que algunos procesos se auto-auditen. Si un proceso no cumple los estándares mínimos
en la evaluación debe suspenderse su desempeño hasta que se mejore.
Los propietarios del proceso establecen un nivel de evaluación para cada proceso
y desarrollan un plan para mejorar el proceso de manera de satisfacer esos criterios. Los
cambios recomendados al proceso pueden pilotearse contra el criterio de evaluación
para determinar antes de su implementación si beneficiarán al proceso. Los propietarios
del proceso tiene autoridad total sobre los cambios al proceso siempre y cuando el
resultado final sea la mejora. Sin embargo, el Equipo de Evaluación del Proceso
también puede servir como un foro para desarrollar un consenso sobre cambios
controversiales al proceso. El progreso sobre las mejoras al proceso se informa a los
managers del software, del programa, y general, y también al cliente durante las
revisiones periódicas de calidad.
El Equipo de Evaluación del Proceso proporciona un foro para sugerencias de
mejoras no solicitadas al proceso, así como para aquellas recibidas de fuera del equipo
del proyecto Onboard Shuttle. También rastrean las acciones que se han tomado para
mejorar los procesos. Este equipo trata de balancear el poder que reciben los miembros
del personal para cambiar el proceso con la necesidad de alentar las mejoras al proceso
que cumplan con los criterios de la organización y con la necesidad de mantener la
coordinación entre los diferentes procesos.
Para extender los procesos, métodos y tecnologías mejorados por todo el sitio, se
formó un Concejo de la Ingeniería del Software del Sitio. El concejo hace la política
relacionada con temas de la ingeniería del software en los distintos proyectos ejecutados
en Houston y proporciona la interfaz con los otros sitios en la Compañía de Sistemas
Federales sobre estos mismos temas. El concejo está formado por representantes
técnicos y de la administración de todos los proyectos de software; representantes de los
grupos de educación, garantía de la calidad, y otros grupos de apoyo; y representantes de
otros grupos y paneles relevantes como ser el Grupo del Proceso de la Ingeniería del
Software, El Panel de Ingeniería del Sistema y el Concejo de Ingeniería de Pruebas.2
En años recientes el proyecto Onboard Shuttle ha participado en varias
actividades evaluativas para identificar oportunidades adicionales para mejoras.
Algunos de estos esfuerzos involucran una modelación orientada a los objetos y mejoras
al entorno de desarrollo para poner algunos procesos en funcionamiento. La
documentación de los procesos se ha usado más seriamente para evaluar subprocesos,
resultando en la definición e implementación de estos subprocesos.
6.3.9 Entrenamiento y Mentores
En 1993 se formaron 4 equipos para mejorar la educación en el proyecto Onboard
Shuttle: proceso de educación, base de conocimientos, currículum, e interfaz con el
usuario. El equipo del currículum realizó un análisis de las necesidades de
entrenamiento y desarrolló objetivos de entrenamiento para 116 necesidades. Este
2
Desde la venta a Loral, esta función se ha redefinido como un Grupo de Proceso de Ingeniería del
Software.
equipo también desarrolló currículums para seis tipos de empleos. El equipo del proceso
desarrolló un sistema on-line que proporcionaba acceso a toda la información de
entrenamiento del proyecto. El objetivo era permitir el almacenamiento y la
recuperación de cursos y materiales desarrollados de tanto en tanto en el proyecto.
Originalmente se condujo un programa informal de mentores usando
compañeros de oficina o pares para ayudar a los nuevos miembros del proyecto a
ajustarse y aprender su trabajo. En 1993 se estableció un programa formal de mentores
para educar a las nuevas personas contratadas por medio de un currículum planeado
asistido por un mentor entrenado. Se solicitaron voluntarios para realizar la tarea de
mentor, y se evaluó a los solicitantes para asegurarse que tuvieran los conocimientos y
experiencia necesarios. Los seleccionados pasaron por un programa de entrenamiento y
recibieron un manual de mentores. El éxito del programa se monitoreó evaluando la
naturaleza de los informes de problemas y análisis de causas de defectos, conduciendo
encuestas de opinión sobre la educación, evaluando el programa de mentores, y
rastreando el progreso de la extensión del desarrollo educacional en el proyecto.
El currículum de los mentores consiste de un mapa de carretera del conocimiento
que la persona en formación debe recibir durante el mes 1 y 2, el mes 3 y 4, el mes 5 y 6,
y la educación continua después de seis meses en el proyecto. El conocimiento a
impartir se agrupa en 6 categorías: Shuttle general, conocimientos generales, procesos y
procedimientos, lenguajes, herramientas, y misceláneos. De esta manera el mapa de
carretera define los requerimientos primarios y secundarios de conocimiento durante
cada uno de varios períodos de tiempo. Los managers del Onboard Shuttle informan que
mientras que solía tomar unos 12 meses para adquirir un status de oficial y 18 meses
para ser verdaderamente un experto en realzar las tareas asignadas en el proyecto, el
proceso de mentores ha disminuido este período de aprendizaje y ha aumentado la
productividad.
El programa de mentores es parte del proceso de mejora de calidad del Onboard
Shuttle. Cuando se identifica la causa raíz de una falla como una falta de conocimiento
por parte del programador, se analiza el proceso de mentores para determinar si falló en
proporcionar el conocimiento requerido a tiempo como para evitar el error. Cualquier
defecto identificado en el programa de mentores pasa a ser tema de la mejora del
proceso. De esta manera el proceso hace que la culpa de un defecto de conocimiento
recaiga sobre el proceso y no sobre una persona. La filosofía del proyecto es que nadie
debe ser asignado a una tarea hasta que haya sido adecuadamente preparado para
realizarla. Un proceso bien ejecutado no deja que la gente desarrolle sus capacidades por
su cuenta.
6.4 Lecciones Generales
6.4.1 Lecciones de Administración
En su esfuerzo por desarrollar un proceso que produzca un producto de una calidad
predeciblemente alta, el proyecto Onboard Shuttle ha aprendido muchas lecciones sobre
cómo usar las mejoras del proceso para lograr objetivos técnicos y de negocios. La más
importante de estas lecciones es que las mejoras del proceso deben aplicarse con una
atención constante a su impacto en los resultados. Cuando se aplican de una manera no
flexible, el proceso se vuelve más una cuestión de dogma que de mejora de
productividad o calidad.
El proyecto Onboard Shuttle encontró que algunas de las prácticas adoptadas
cuando el proyecto estaba funcionando en el equivalente a los niveles 1, 2 y 3 del CMM
podrían arraigarse tanto que se volverían un impedimento para la mejora continua. Por
ejemplo, la forma en la que se administraba el proyecto y el rol de los managers cambió
a medida que evolucionó la estructura del panel de coordinación y control. Algunas
funciones que en una época realizaban los managers ahora las realiza el personal técnico
a través de sus roles en los paneles de control del proyecto.
En una organización de alta madurez, el proceso se vuelve tan internalizado por
parte del personal que están dispuestos a hacerse responsables de él. El personal a
menudo es el lugar más efectivo de la administración del proceso, ya que son los más
cercanos a ésta y los que mejor pueden interpretar los datos del proceso. Por ejemplo, la
mayoría de los temas de garantía de calidad se resuelven en niveles más bajos del
proyecto Onboard Shuttle.
El proyecto Onboard Shuttle presenta un excelente ejemplo de lo que describió
Humphrey [Humphrey 89] como el desacople de los conceptos de administración y
administradores. Los administradores tienen roles con responsabilidades asignadas, y
hay fenómenos que necesitan administrarse. La administración de algunos de estos
fenómenos puede asignarse a los administradores, y la administración de otros
fenómenos puede asignarse a personas que no sean administradores. El tema importante
desde la perspectiva del proceso es que existe un rol o roles en algún lugar en el
proyecto con responsabilidad para ejercer una administración de supervisión y control
en cada área donde se necesita. La separación de los conceptos de administrador y
administración permite que la organización le de más poder a su personal para
administrar las actividades de las que están más cerca y libera a la administración para
que pueda preocuparse por temas estratégicos a un plazo más largo.
Los ejecutivos del proyecto Onboard Shuttle han encontrado que no necesitan
preocuparse por la necesidad de excelencia por parte de los integrantes individuales del
personal, ya que se ha internalizado una cultura de excelencia. Sin embargo, se enfocan
en asegurar que el personal no se vuelva complaciente, y constantemente se enfocan en
mejorar la performance del proceso del proyecto. Tienden a no preocuparse tanto por
temas centrales sino más bien por tasas de errores, ya que éstos son un indicador
primario de cuán eficientemente está funcionando el proceso.
En organizaciones de baja madurez debe controlarse el proceso antes de poder
mejorarlo. Hacer que el proceso de desarrollo esté bajo el control de la administración a
veces deja a los ingenieros menos flexibilidad para implementar el proceso de software.
Los ingenieros de organizaciones maduras que tienen su proceso bajo control pueden
hacerle mejoras debido a su experticia en el proceso. El poder que tienen los ingenieros
de organizaciones maduras de cambiar el proceso es crucial, ya que el proceso debe
continuar para responder a las condiciones cambiantes del proyecto. Un proceso
inflexible quedará desactualizado rápidamente con el avance de la tecnología, de la
competencia o del desarrollo.
6.4.2 Lecciones de Gente
El éxito de las organizaciones inmaduras a menudo depende de héroes que realizan
milagros técnicos bajo condiciones no favorables. El proyecto Onboard Shuttle ha
evolucionado un proceso que no depende de héroes para que tenga éxito. Esto nunca
debe interpretarse de manera de implicar una falta de énfasis en la excelencia técnica del
personal. De hecho, el programa de mentores está diseñado para acelerar el desarrollo de
las capacidades técnicas.
El proceso Onboard Shuttle está diseñado para eliminar puntos de falla en el
proyecto. O sea, si una falla no se detecta y se entrega al cliente, no se puede culpar a
ningún individuo en particular por el problema. Cada línea de código del software de
vuelo es revisada por lo menos por 6 personas diferentes antes de la entrega al cliente.
El proceso de inspección está diseñado para asegurar que cada línea de código nueva o
cambiada sea revisada por personas que tengan en cuenta diferentes perspectiva de
temas relacionados con la calidad.
Los programadores saben que el proceso los protegerá de cometer errores que
serán entregados al cliente. De esta manera ninguna entrega con fallas es una falla del
equipo. Puede ser que el error haya sido cometido por un programador en particular,
pero hubo varios que no lo detectaron. Por esta razón, el análisis de las fallas se enfoca
en el proceso y no en los individuos.
El diseño del proyecto Onboard Shuttle ha ayudado a superar variaciones en las
capacidades de los miembros del personal de dos maneras. El proceso se ve menos
afectado si hay alguien que no tiene la capacidad suficiente, porque cada elemento del
producto es revisado por varios miembros del proyecto. Es extremadamente poco
probable que los resultados de una performance pobre escapen la detección y se
entreguen al cliente. Sin embargo, es más importante el diseño del conocimiento y
capacidades de las transferencias del proceso a través del personal mucho más rápido
que en un proceso menos maduro. De esta manera, a través del conocimiento obtenido
de los mentores, inspecciones y otros procesos, el proyecto Onboard Shuttle está
aumentando el promedio de capacidad en todos los miembros del personal a una
velocidad mayor que la que se observaría en un proceso menos maduro. Más aun, el
proceso detecta evidencia de una performance no efectiva mucho más rápido que lo que
lo haría un proceso menos maduro, y se pueden tomar medidas para corregirlo mucho
antes.
6.4.3 Lecciones de Costos
El proyecto Onboard Shuttle ha desarrollado la capacidad de predecir sus costos en
forma consistente hasta dentro de un 10% de los gastos reales, y sólo han fallado en una
fecha límite en 15 años. El costo del software de vuelo del Onboard Shuttle es alto
debido al proceso necesario para lograr los requerimientos excepcionales de
confiabilidad para software de aviación evaluados para humanos. Los administradores
del proyecto informan que creen que los requerimientos de seguridad y confiabilidad
evaluados para humanos aumentan el costo del software en un factor de 3 o 4. Sin
embargo, no cambiarían la arquitectura del proceso si comenzaran un proyecto de
software no evaluado para humanos con menos requerimientos de confiabilidad. El
costo de tal sistema disminuiría porque se reduciría la cantidad de actividades de
verificación.
Como el proyecto Onboard Shuttle puede cuantificar el desempeño de su
proceso de una manera tan efectiva, pueden caracterizar el costo de diferentes niveles de
confiabilidad. La Figura 6.11 presenta una comparación desarrollada por Kyle Rone del
costo del software desarrollado por medio del proceso del Onboard Shuttle con relación
a diferentes niveles de densidad de defectos. A medida que los niveles de densidad de
defectos requerida se mueve por debajo de 1 defecto por cada mil líneas de código, el
costo comienza a ascender rápidamente. Los costos dramáticamente superiores para el
software evaluado para humanos deriva de la mayor dificultad de diseñar casos de
prueba para detectar fallas que ocurrirían sólo bajo condiciones de baja probabilidad.
Para desarrollar los escenarios subyacentes a estos casos de prueba se requiere en
esfuerzo extraordinario.
6.4.4 Lecciones de Transferencia de Procesos
¿Con qué nivel de éxito puede transferirse un proceso maduro a otra organización? Las
cosas más difíciles de transferir son



El proceso de software exacto para toda la organización a una organización en un
área de aplicación diferente,
las lecciones aprendidas acerca de cómo ejecutar mejor los procesos,
los datos históricos, que pueden no ser aplicables a una nueva área.
Sin embargo, los principios detrás del crecimiento de la madurez del proceso
pueden transferirse y usarse como guía para mejorar otra organización.
El proyecto Onboard Shuttle ha intentado transferir sus métodos y procesos de
software a otros proyectos. Asociado con el proyecto Onboard Shuttle hay un proyecto
para construir herramientas de soporte llamado Herramientas de Aplicación del
Software de Vuelo (FSWAT). Este proyecto comenzó adoptando algunos de los
métodos de los que el proyecto Onboard Shuttle fue pionero. Como su implementación
de estos procesos es más joven y menos madura, el FSWAT está más influenciado por
variaciones en la capacidad de su personal técnico que el proyecto Onboard Shuttle.
A través de la mejora del proceso, el proyecto FSWAT ha mejorado
continuamente la calidad del software entregado. Por ejemplo, la transferencia de los
procesos de análisis de requerimientos e inspección de código al FSWAT en 1980
redujo las tasas de defectos en los productos de 0,72 defectos por cada mil líneas de
código en 1986 a 0,30 en 1993. Sin embargo, la confiabilidad requerida del software del
FSWAT es menor que la del software de vuelo porque no está verificado para humanos.
Por lo tanto los costos del proyecto FSWAT son menores en un factor de 3. Estos costos
son menores debido al nivel reducido de verificación y pruebas independientes
requerido. Algunos procesos de desarrollo son más simples en el FSWAT. Por ejemplo,
donde puede haber 50 ítems en una lista de inspección para el software de vuelo, puede
haber sólo 10 para el FSWAT.
El proyecto Onboard Shuttle también ha transferido algo de su conocimiento
sobre el proceso al proyecto de software Space Station Freedom (Libertad de la Estación
Espacial) que se inició durante la década del 80 (este proyecto ha sido cancelado debido
a recortes en el presupuesto hechos en el Congreso de los EE.UU.). Como el proyecto
Space Station era substancialmente diferente tanto en aplicación como en tipo de
contrato en comparación con el proyecto Onboard Shuttle, era difícil aplicar el proceso
definido de software usado para el software de vuelo. El Grupo del Proceso de la
Ingeniería del Software del sitio ha desarrollado procesos de software para el sitio y ha
adoptado algunas definiciones de procesos de otras áreas de la compañía madre. Sin
embargo, no fue posible aplicar un proceso común a ambos proyectos. En algunas
circunstancias de negocios puede ser necesario que la organización soporte dos o más
procesos estándar de software a partir de los cuales nuevos proyectos puedan ajustar sus
procesos definidos de software.
No obstante, los principios para desarrollar procesos maduros pueden transferirse
para ser aplicados en nuevos proyectos. El método para transferir estos principios a la
práctica en nuevos proyectos era transferir a los administradores y al personal técnico.
De esta manera, más que simplemente transferir documentos estáticos, la transferencia
más efectiva ocurría con la reasignación de gente que poseía el conocimiento dinámico
sobre cómo aplicar procesos maduros y métodos de mejoras. Una de las lecciones más
importantes de este proyecto es que mientras que las organizaciones con un bajo nivel
de madurez miran al personal talentoso como la mejor forma de salvar proyectos con
problemas, las organizaciones maduras miran al personal talentoso como la mejor forma
de transferir la cultura y los métodos a nuevas aplicaciones.