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.