Royce comenzó su carrera como profesor asistente en el Instituto Tecnológico de California. En 1961 empezó como gerente de proyecto en la división aeroespacial de TRW. Su primer proyecto trató sobre el diseño de un sistema de planificación de misión y de selección de la órbita de una nave espacial. En los siguientes años él estuvo involucrado en la investigación y desarrollo de varios sistemas de software, en especial largos y complejos, y comenzó a desarrollar nuevas metodologías para mejorar la administración de los proyectos de software.[4] En 1970 publicó su artículo influyente “Administrando el desarrollo de grandes sistemas de software”, en el cual presentó varios modelos de administración de proyectos, incluyendo, como ahora los conocemos, cascada, iterativo, and ágil.[2] En 1985 recibió el Premio de sistemas de información AIAA.[5] Durante los 1980s él fue director de Centro de Tecnología de Software Lockheed en Austin, Texas. Se retiró en 1994 y murió el año siguiente en su casa en Clifton (Virginia).[6]
Su hijo mayor Walker Royce, jefe de Software Economista en la división racional de IBM, y autor de “Administración de proyectos de software, Una Estructura Unificada”, y principal contribuidor a la administración filosófica inherente en Proceso Unificado de Rational de IBM.[7]
Trabajo
Administración de desarrollo de software en grandes sistemas
El papel de Royce de 1970 es generalmente considerado como el papel en el cual se definen las etapas del modelo “cascada” del proceso de software. Pero es sorprendente ver que los papeles de Benington y Hosier tenían una buena aproximación al modelo cascada, y que el papel de Royce ya tenía incorporado un paso esencial que es la creación de prototipos.[8]
De hecho Royce demostró que mientras el desarrollo de grandes sistemas de software necesitaran un enfoque más a fondo, no habría riesgo en un solo paso del enfoque secuencial. Él propuso un enfoque iterativo e incremental y abogó para que los proyectos tengan que pasar por esto al menos 2 veces.
El "modelo cascada" sin modificar. El progreso fluye de arriba hacia abajo, como una cascada.
Royce comenzó su artículo en 1970 'Administrando el desarrollo de grandes sistemas de software' con una declaración sobre el origen de sus ideas:
Yo voy a describir mi opinión personal sobre la administración de grandes desarrollos de software. Yo he tenido varias tareas durante los últimos nueve años, la mayoría preocupado por el desarrollo de paquetes de software para la planeación de misiones en el espacio, comandando y análisis post-vuelo. En estas tareas he experimentado diferentes grados de éxito con respecto a la llegar a un estado funcional, a tiempo y dentro de los costos. He sido perjudicado por mis experiencias y ahora en esta presentación les voy a contar algunos de estos prejuicios.[2]
Royce determinó que el desarrollo de programas de computadora, sin importar el tamaño o complejidad, se podían separar en 2 etapas de desarrollo: Análisis y programación. Para pequeños proyectos de desarrollo de software estos 2 pasos eran suficientes, pero no para el desarrollo de grandes sistemas de software. Estos requerían muchos pasos adicionales de ida y vuelta, el cual le da al desarrolló un carácter iterativo.[2]
Para representar este desarrollo iterativo Royce propuso una serie de enfoques, aunque él nunca utilizó el término cascada[9] y tampoco lo defendió como una metodología eficaz.[10] El primer uso del término cascada pudo haber sido un documento de 1976 por Bell y Thayer.[11]
Royce representó el modelo cascada con los siguiente 7 pasos:[2]
Requerimientos de sistema
Requerimientos de software
Análisis
Diseño del programa
Programación
Pruebas, y
Operación
Las llamó “Pasos de implementación para desarrollar un programa de computadora grande para entregarlo al cliente”. Royce previó una gran deficiencia en esta metodología, la cual describió como:
La fase de prueba la cual ocurre al final del ciclo de desarrollo, es el primer evento para cual tiempo, almacenamiento, transferencias de entrada/salida, etc., son experiencias distinguibles de analizar. Este fenómeno no es precisamente analizable. No son las soluciones a las ecuaciones diferenciales parciales estándar de la física matemática, por ejemplo. Sin embargo si estos fenómenos fallan al satisfacer las diversas limitaciones externas, entonces requiere invariablemente un importante re-diseño. Un simple parche octal o rehacer algo de código aislado no solucionará este tipo de dificultades. Los cambios del diseño requeridos son propensos a ser tan perturbadores que los requisitos del software sobre en el cual el diseño se basa y proporciona la importancia para todo es violado…[2]
De acuerdo a Royce en el proceso del modelo “las iteraciones del diseño nunca son limitados a la etapa sucesiva” y por eso el modelo sin iteración es “un riesgo e invita al fracaso”.[2] Como alternativa Royce propuso un desarrollo más incremental, donde cada siguiente paso está ligado con el paso anterior.
Ingeniería de sistemas de software
A principios de 1980 Winston Royce inventó el término “Ingeniería en sistemas de software" (SwSE, por sus siglas en inglés) en uno de los seminarios del curso de adquisición de administración de software en la Universidad de Administración de Defensa de Sistemas (DSMC, por sus siglas en inglés) en Fort Belvoir, Va.[12]
De acuerdo a Richard H Thayer, profesor en ingeniería de software en la Universidad Estatal de California, Sacramento, ingeniería en sistemas de software está preocupado con “aplicar los principios de ingeniería en sistemas específicamente para desarrollar grandes y complejos sistemas de software que proporcionan una herramienta poderosa para el proceso y la administración del producto”.[12] Ingenieros en sistemas de software pueden tomar la "responsabilidad por la administración técnica global y la verificación de los productos finales del sistema."[12]
Arquitectura de Software
En el artículo de 1991 Arquitectura de Software: Integración de Procesos y Tecnología, Royce y Royce describen la conexión entre arquitectura y el proceso de desarrollo de software.[13] De acuerdo con Philippe Kruchten et al. (2006) este artículo fue el primero “en posicionar arquitectura de software entre tecnología y proceso, tanto como en título y como perspectiva.”[14]
1989. "Lockheed's Software Technology Center". In: Modern software engineering, foundations and current perspectives. Peter A. Ng (ed.). Van Nostrand Reinhold Co. p. 561–578.
1991. "Current Problems." In: Aerospace Software Engineering, edited by Christine Anderson and Merlin Dorfman, 5–15. Washington, D.C.: American Institute of Aeronautics and Astronautics.
1991. "Software Architecture: Integrating Process and Technology", with Walker Royce in TRW Quest, vol. 14, no. 1, p. 2–15.
↑Barry W. Boehm (1987). "Software Process Management: Lessons Learned from History" in ICSE '87 Proceedings of the 9th international conference on Software Engineering pp 296-298
