DSN_XP y Winston W. Royce en gratitud

 Escuelas de diseño para sistemas grandes

DSN_XP descubre a Royce, como el referente de un modelo de desarrollo de software para el diseño de soluciones que implican mayor cobertura funcional o macro sistemas.

Este es el escrito original sobre el cual se derivará un modelo más general que usualmente se lo denomina como el modelo en cascada, sin embargo, si el lector lee esta entrada, notará que Royce tiene ideas interesantes sobre establecer un modelo general para desarrollo de software en sistemas grandes.

Gestión del desarrollo de grandes sistemas de software

Dr. Winston W. Rovce

1974

Peimpreso de Proceedings, IEEE WESCON, agosto de 1970, páginas 1-9. 

Copyright © 1970 por The Institute of Electrical and Electronics Engineers 

.328 Inc. Publicado originalmente por TRW

Introducción

Personalmente voy a describir mis puntos de vista sobre la gestión de grandes desarrollos de software. Yo he tenido varias asignaciones durante los últimos años, principalmente relacionadas con el desarrollo de paquetes de software para la planificación de la misión de la nave espacial, el mando y el análisis posterior al vuelo. En estas asignaciones he experimentado diferentes grados de éxito con respecto a llegar a un estado operativo, a tiempo y dentro de los costos. He llegado a tener prejuicios por mis experiencias y voy a relatar algunos de estos prejuicios en esta presentación.

Funciones para el desarrollo de programas computables

Hay dos pasos esenciales comúnmente a todos los desarrollos de programas software, independientemente del tamaño o complejidad. Primero hay un paso de análisis, seguido de un paso de codificación como se muestra en la Figura 1. 

Esta clase de concepto de implementación muy simple es de hecho todo lo que se requiere si el esfuerzo es suficientemente pequeño y si el producto final debe ser operado por quienes lo construyeron, como se hace típicamente con programas de computadora para uso interno. 

También es el tipo de esfuerzo de desarrollo por el que la mayoría de los clientes están felices de pagar, ya que ambos pasos implican un trabajo genuinamente creativo que contribuya directamente a la utilidad del producto final. Un plan de implementación para fabricar largos sistemas de software y codificado solo por estos pasos, sin embargo, está condenado al fracaso. Se requieren muchos pasos de desarrollo adicionales, ninguno contribuye tan directamente al producto final como el análisis y la codificación y todos aumentan los costos de desarrollo. 

El personal del cliente normalmente preferiría no pagar por ellos y el personal de desarrollo preferiría no implementarlos. La función principal de la gestión es vender estos conceptos a ambos grupos y luego hacer el cumplimiento por parte del personal de desarrollo.

En la Figura 2 se ilustra un enfoque más grandioso del desarrollo de software. El análisis y la codificación los pasos todavía están en la imagen, pero están precedidos por dos niveles de análisis de requisitos, están separados por un paso de diseño del programa, seguido de un paso de prueba. Estas adiciones se tratan por separado del análisis y codificación porque son claramente diferentes en la forma en que se ejecutan. 

Deben ser planificados y dotados de personal de manera diferente para la mejor utilización de los recursos del programa. 

La Figura 3 muestra la relación iterativa entre las sucesivas fases de desarrollo de este esquema. El orden de los pasos se basa en el siguiente concepto: que a medida que avanza cada paso y el diseño avanza detallado, hay una iteración con los pasos anteriores y posteriores, pero rara vez con los pasos más remotos en la secuencia. La virtud de todo esto es que a medida que avanza el diseño, el proceso de cambio se reduce a límites manejables.  

En cualquier punto del proceso de diseño después de que se completa el análisis de requisitos, existe una línea de base firme y segura que se mueve hacia donde quiera girar en el caso de dificultades de diseño imprevistas y tener una posición de respaldo efectiva que tiende a maximizar la extensión del trabajo inicial que se puede salvar y preservarlo.

Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso.

El problema se ilustra en la Figura 4. La fase de prueba que ocurre al final del ciclo de desarrollo es el primer evento para el cual se experimentan transferencias de tiempo, almacenamiento, entrada / salida, etc., a diferencia del analizado. Estos fenómenos no son precisamente analizables. No son las soluciones al estándar parcial de ecuaciones diferenciales de la física matemática, por ejemplo. Sin embargo, si estos fenómenos no logran satisfacer las diversas restricciones externas, entonces invariablemente se requiere un rediseño importante. Un simple parche octal o rehacer de algunos códigos aislados no solucionará este tipo de dificultades. Es probable que los cambios de diseño necesarios sean tan perjudiciales que los requisitos de software en los que se basa el diseño y que proporcionan la justificación de todo son violados. O se deben modificar los requisitos o se requiere un cambio sustancial en el diseño. 

En efecto, el proceso de desarrollo ha regresado al origen y se puede esperar hasta un 10 por ciento de sobrepaso en el cronograma y / o costos. 

Uno podría notar que ha habido un salto en las fases de análisis y código. Uno no puede, por supuesto, producir software sin estos pasos, pero generalmente estas fases se gestionan con relativa facilidad y tienen poco impacto en los requisitos, el diseño y las pruebas. En mi experiencia hay departamentos enteros consumidos con el análisis de la mecánica de la órbita, determinación de la actitud de la nave espacial, optimización matemática de la actividad de carga útil y así sucesivamente, pero cuando estos departamentos han completado su trabajo difícil y complejo, los pasos del programa resultantes implican unas pocas líneas de código aritmético en serie. Si en la ejecución de su difícil trabajo es complejo, los analistas han cometido un error, la corrección es invariablemente implementada por un menor cambio en el código sin retroalimentación disruptiva en las otras bases de desarrollo. 

Sin embargo, creo que el enfoque ilustrado es fundamentalmente sólido. El resto de esta discusión presenta cinco características adicionales que deben agregarse a este enfoque básico para eliminar la mayoría de las riesgos de desarrollo.

Paso 1: El diseño del programa es lo primero 

El primer paso hacia una solución se ilustra en la Figura 5. Se ha realizado una fase de diseño preliminar del programa, insertado entre la fase de generación de requisitos de software y la fase de análisis. Este procedimiento puede ser criticado sobre la base de que el diseñador del programa se ve obligado a diseñar en el vacío relativo del software inicial, requisitos sin ningún análisis existente. 

Como resultado, su diseño preliminar puede estar sustancialmente en error como en comparación con su diseño si tuviera que esperar hasta que el análisis estuviera completo. Esta crítica es correcta pero falla el punto. Mediante esta técnica, el diseñador del programa asegura que el software no fallará debido al almacenamiento, razones de tiempo y flujo de datos. 

A medida que avanza el análisis en la fase siguiente, el diseñador del programa debe imponer al analista las restricciones de almacenamiento, tiempo y funcionamiento de tal manera que perciba las consecuencias. Cuando necesita justificadamente más de este tipo de recursos para implementar sus ecuaciones, deben arrebatarse simultáneamente a sus compatriotas analistas. De esta forma todos los analistas y todos los diseñadores de programas contribuirán a un proceso de diseño significativo que culminará en la asignación adecuada de tiempo de ejecución y recursos de almacenamiento. Si los recursos totales por aplicar son insuficientes o si el embrión del diseño operacional es incorrecto, se reconocerá en esta etapa anterior y la iteración con requisitos y el diseño preliminar se pueden rehacer antes de que comience el diseño final, la codificación y la prueba. 

¿Cómo se implementa este procedimiento? Se requieren los siguientes pasos. 

1. Inicie el proceso de diseño con diseñadores de programas, no analistas ni programadores. 
2. Diseñar, definir y asignar los modos de procesamiento de datos incluso a riesgo de equivocarse. Asignar procesamiento, funciones, diseñar la base de datos, definir el procesamiento de la base de datos, asignar tiempo de ejecución, definir interfaces y modos de procesamiento con el sistema operativo, describir el procesamiento de entrada y salida, y definir procedimientos operativos preliminares. 
3. Escriba un documento de descripción general que sea comprensible, informativo y actual. Todos y cada uno de los trabajadores debe tener un conocimiento elemental del sistema. Al menos una persona debe tener un profundo conocimiento del sistema que proviene en parte de haber tenido que escribir un documento de resumen.

Paso 2: Documentar el diseño 

En este punto es apropiado plantear la cuestión de "¿cuánta documentación?" Mi propio punto de vista es "bastante;" ciertamente más de lo que la mayoría de los programadores, analistas o diseñadores de programas están dispuestos a hacer si se les deja sus propios dispositivos. La primera regla para administrar el desarrollo de software es la aplicación despiadada de la documentación de requisitos. 

De vez en cuando se me pide que revise el progreso de otros esfuerzos de diseño de software. Mi primer paso es investigar el estado de la documentación, si la documentación está en grave incumplimiento mi primera recomendación es simple. Reemplazar la gestión de proyectos. Detenga todas las actividades no relacionadas con la documentación. 

Lleve la documentación a niveles aceptables. La gestión del software es simplemente imposible sin muy alto grado de documentación. Como ejemplo, permítanme ofrecer las siguientes estimaciones para comparar. Para adquirir un dispositivo de hardware de 5 millones de dólares, esperaría una especificación de 30 páginas que proporcionara el detalle adecuado para controlar la contratación. Para adquirir 5 millones de dólares en software, calcularía 1000 páginas de especificaciones correctas para lograr un control comparable, 

¿Por qué tanta documentación? 

1. Cada diseñador debe comunicarse con los diseñadores de interfaz, con su gerencia y posiblemente con el cliente. Un registro verbal es demasiado intangible para proporcionar una base adecuada para una interfaz o gestionar decisiones. Una descripción escrita aceptable obliga al diseñador a adoptar una posición inequívoca y proporcionar evidencia tangible de finalización. Evita que el diseñador se esconda detrás de "estamos a 90 porciento terminado"- síndrome de mes tras mes. 
2. Durante la fase inicial del desarrollo de software, la documentación es la especificación y el diseño. Hasta que comience la codificación, estos tres sustantivos (documentación, especificación, diseño) denotan algo. Si la documentación es mala el diseño es malo. Si la documentación aún no existe, aún no hay diseño, sólo gente que piensa y habla sobre el diseño, que tiene cierto valor, pero no mucho. 
3. El valor monetario real de una buena documentación comienza en el proceso de desarrollo durante la fase de prueba y continúa a través de operaciones y rediseño. El valor de la documentación puede ser descrita en términos de tres situaciones concretas y tangibles a las que se enfrenta todo director de programa. 
• Durante la fase de prueba, con buena documentación, el gerente puede concentrar al personal en los errores en el programa. Sin una buena documentación, cada error, grande o pequeño, es analizado por un solo hombre quien probablemente cometió el error en primer lugar porque es el único hombre que comprende el área del programa. 
• Durante la fase operativa, con una buena documentación, el gerente puede utilizar personal para operar el programa y hacer un mejor trabajo, más barato. Sin una buena documentación, el software debe ser operado por quienes lo construyeron. Generalmente estas personas están relativamente desinteresadas en las operaciones y no hacen un trabajo tan eficaz como el personal orientado a las operaciones. Cabe señalar a este respecto que en una situación operativa, si hay algún bloqueo, siempre se culpa primero al software. Para absolver al software o para corregir la culpa, la documentación del software debe hablar claramente. 
• Después de las operaciones iniciales, cuando las mejoras del sistema están en orden, una buena documentación permite el rediseño, actualización y adaptación efectivos en el campo. Si no existe documentación, generalmente todo el marco existente de software operativo debe desecharse, incluso para cambios relativamente modestos. 

La Figura 6 muestra un plan de documentación que se ajusta a los pasos mostrados anteriormente. Tenga en cuenta que seis documentos se producen y en el momento de la entrega del producto final, Documentos No, 1, No 3, No 4, los números 5 y 6 debe ser vigentes y actualizados.

Paso 3: Hazlo dos veces 

Después de la documentación, el segundo criterio más importante para el éxito gira en torno a si el producto es totalmente original. Si el programa informático en cuestión se está desarrollando por primera vez, importa que se organice para que la versión finalmente entregada al cliente para la implementación operativa sea en realidad la segunda versión en lo que respecta a las áreas críticas de diseño / operaciones. 

La figura 7 ilustra cómo podría llevarse a cabo mediante una simulación. Tenga en cuenta que es simplemente todo el proceso realizado en miniatura, a escala de tiempo que es relativamente pequeña con respecto al esfuerzo total. 

La naturaleza de este esfuerzo puede variar ampliamente dependiendo principalmente en la escala de tiempo general y la naturaleza de las áreas críticas del problema que se modelarán. Si el esfuerzo corre 30 meses, entonces este desarrollo temprano del modelo piloto podría programarse para 10 meses. 

Para este horario, se pueden utilizar controles bastante formales, procedimientos de documentación, etc. Sin embargo, si el esfuerzo general fuera reducido a 12 meses, entonces el esfuerzo piloto podría comprimirse a tres meses quizás, con el fin de ganar suficiente apalancamiento en el desarrollo de la línea principal. 

En este caso, un tipo muy especial de amplia competencia es requerido por parte del personal involucrado. Deben tener una sensación intuitiva para el análisis, la codificación y diseño del programa. Deben detectar rápidamente los puntos problemáticos en el diseño, modelarlos, modelar sus alternativas, olvídese de los aspectos sencillos del diseño que no vale la pena estudiar en este punto inicial y finalmente llegar a un programa sin errores. 

En cualquier caso, el punto de todo esto, como con una simulación, son las cuestiones de tiempo, el almacenamiento, etc., que de otro modo serían cuestiones de juicio, ahora se pueden estudiar con precisión. Sin esta simulación, el director del proyecto está a merced del juicio humano. 

Con la simulación puede al menos realizar pruebas experimentales de algunas hipótesis clave y analizar lo que queda para el juicio humano, que en el área del diseño de programas de computadora (como en la estimación del peso bruto de despegue, los costos diarios para completar al doble) es invariable y seriamente optimista.

Paso 4: Planificar , controlar y monitorear las pruebas 

Sin duda, el mayor usuario de los recursos del proyecto, ya sea mano de obra, tiempo de computadora o juicio de la gerencia, es la fase de prueba. Es la fase de mayor riesgo en términos de dólares y cronograma. Eso ocurre en el último punto de la programación cuando las alternativas de respaldo están menos disponibles, si es que las hay. 

Las tres recomendaciones anteriores para diseñar el programa antes de comenzar el análisis y la codificación, para documentarlo por completo y para construir un modelo piloto, todos tienen como objetivo descubrir y resolver problemas antes entrando en la fase de prueba. Sin embargo, incluso después de hacer estas cosas, hay una fase más tranquila y todavía hay cosas importantes por hacer. La Figura 8 enumera algunos aspectos adicionales de las pruebas. 

Al planificar las pruebas, sugiera lo siguiente para su consideración. 

1. Muchas partes del proceso de prueba son manejadas mejor por especialistas en pruebas que no necesariamente contribuyeron al diseño original. Si se argumenta que solo el diseñador puede realizar una prueba exhaustiva porque solo él entiende el área que construyó, esto es un signo seguro de que no se documenta correctamente. Con buena documentación es factible utilizar especialistas en garantía de productos de software que, a mi juicio, harán un mejor trabajo de prueba que el diseñador.
2. La mayoría de los errores son de naturaleza obvia, por lo que pueden detectarse fácilmente mediante una inspección visual. Cada pedacito de un análisis y cada fragmento de código debe ser sometido a un simple escaneo visual por una segunda parte que no hizo el análisis o el código original, pero quién detectaría cosas como signos negativos caídos, factores faltantes de dos, salta a direcciones incorrectas, etc., que tienen la naturaleza de corregir el análisis y el código. No utilice el computador para detectar este tipo de cosas, es demasiado caro.
3. Pruebe cada ruta lógica en el programa de computadora al menos una vez con algún tipo de verificación numérica. Si soy cliente, no aceptaré la entrega hasta que este procedimiento haya sido completado y certificado. Este paso descubre la mayoría de los errores de codificación. Si bien este procedimiento de prueba parece simple, para un programa de computadora grande y complejo es relativamente difícil para recorrer cada camino lógico con valores controlados de entrada. De hecho, hay quienes argumentarán que es casi imposible. A pesar de esto, persistiría en mi recomendación de que todo camino lógico sea sometido al menos a un control auténtico.
4. Después de eliminar los errores simples (que son la mayoría y que oscurecen a los grandes errores), entonces es el momento de entregar el software al área de prueba para fines de pago. En el momento adecuado durante el curso de desarrollo y en manos de la persona adecuada, la computadora en sí es el mejor dispositivo para revisa. Las decisiones clave de gestión son: ¿Cuándo es el momento y quién es la persona que realizará el pago final?

Paso 5: Involucrar al cliente 

Por alguna razón, lo que va a hacer un diseño de software está sujeto a una amplia interpretación incluso después de acuerdo previo. Es importante involucrar al cliente de manera formal para que se haya comprometido él mismo en puntos anteriores antes de la entrega final. Dar rienda suelta al contratista entre requisitos la definición y el funcionamiento invitan a los problemas. La figura 9 indica tres puntos siguiendo la definición de requisitos donde el conocimiento, el juicio y el compromiso del cliente pueden reforzar el esfuerzo de desarrollo. 

Resumen 

La Figura 10 resume los cinco pasos que considero necesarios para transformar un proceso de desarrollo riesgoso en uno que proporcione el producto deseado. Destacaría que cada artículo cuesta una suma adicional de dinero. Si el proceso relativamente más simple sin las cinco complejidades descritas aquí funcionara con éxito, entonces, por supuesto, el dinero adicional no está bien gastado. En mi experiencia, sin embargo, el método más simple nunca ha funcionado en grandes esfuerzos de desarrollo de software y los costos de recuperación superaron con creces los necesarios para financiar el proceso de cinco pasos enumerado.