Royce había comenzado su carrera como profesor asistente en el Instituto de Tecnología de California. En 1961 comenzó como gerente de proyectos en la división aeroespacial de TRW . Su primer proyecto se refería al diseño de un sistema de planificación de misiones y selección de órbitas para naves espaciales . En los años siguientes se involucró en la investigación y desarrollo de varios sistemas de software grandes y complejos, y comenzó a desarrollar nuevas metodologías para mejorar la gestión de proyectos de software. [5] En 1970 publicó su influyente artículo " Gestión del desarrollo de grandes sistemas de software ", en el que presentó varios modelos de gestión de proyectos , incluyendo lo que ahora conocemos como cascada , iterativo y ágil . [3] En 1985, recibió el Premio de Sistemas de Información de la AIAA . [6] Durante la década de 1980 fue director del Centro de Tecnología de Software de Lockheed en Austin, Texas. Se jubiló en 1994 y murió al año siguiente en su casa de Clifton, Virginia . [7]
Su hijo mayor es Walker Royce, economista jefe de software de la división Rational de IBM y autor de "Software Project Management, A Unified Framework", y un importante colaborador de la filosofía de gestión inherente al IBM Rational Unified Process . [8]
Trabajar
Gestión del desarrollo de grandes sistemas de software
El artículo de Royce de 1970 se considera generalmente el que definió el modelo de "cascada" por etapas del proceso de software, pero es sorprendente ver que los artículos anteriores de Benington y Hosier contenían buenas aproximaciones al modelo de cascada y que el artículo de Royce ya incorporaba la creación de prototipos como un paso esencial compatible con el modelo de cascada. [9]
De hecho, Royce demostró que, si bien el desarrollo de grandes sistemas de software requería un enfoque más exhaustivo, existía un riesgo inherente en un enfoque secuencial de una sola pasada. Propuso un enfoque iterativo y abogó por que los proyectos pasaran por este proceso al menos dos veces.
Modelo de figura 1 de RoyceModelo de figura 4 de Royce
Royce comenzó su artículo de 1970 'Gestión del desarrollo de grandes sistemas de software' con una declaración sobre el origen de sus ideas:
Voy a describir mis opiniones personales sobre la gestión de grandes desarrollos de software. He desempeñado diversas tareas durante los últimos nueve años, la mayoría relacionadas con el desarrollo de paquetes de software para la planificación de misiones espaciales, el mando y el análisis posterior al vuelo. En estas tareas he experimentado distintos grados de éxito con respecto a la consecución de un estado operativo a tiempo y dentro de los costes. Mis experiencias me han generado prejuicios y voy a relatar algunos de ellos en esta presentación. [3]
Royce había determinado que el desarrollo de programas informáticos independientemente de su tamaño o complejidad podía dividirse en dos etapas de desarrollo: Análisis y Codificación . Para proyectos de desarrollo de software pequeños estos dos pasos eran suficientes, pero no para el desarrollo de sistemas de software más grandes. Estos requieren muchos pasos adicionales de ida y vuelta, lo que le da al desarrollo un carácter iterativo. [3]
Para ilustrar este desarrollo iterativo, Royce propuso una serie de enfoques, aunque nunca utilizó el término cascada [10] ni lo defendió como una metodología eficaz . [11] El primer uso del término "cascada" puede haber sido un artículo de 1976 de Bell y Thayer. [12]
Royce imaginó el modelo de cascada con los siguientes siete pasos: [3]
Requisitos del sistema
Requisitos de software
Análisis
Diseño de programas
Codificación
Pruebas y
Operación
Los llamó "pasos de implementación para desarrollar un gran programa informático para su entrega a un cliente". Royce previó una deficiencia importante en esta metodología, que describió como:
La fase de prueba, que se produce al final del ciclo de desarrollo, es el primer evento en el que se experimentan los tiempos, el almacenamiento, las transferencias de entrada/salida, etc., en lugar de analizarlos. Estos fenómenos no se pueden analizar con precisión. 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 no satisfacen las diversas restricciones externas, invariablemente se requiere un rediseño importante. Un simple parche octal o la repetición de algún código aislado no solucionará este tipo de dificultades. Es probable que los cambios de diseño necesarios sean tan disruptivos que se violen los requisitos del software en los que se basa el diseño y que proporcionan la lógica para todo... [3]
Según Royce, en el modelo de proceso, “las iteraciones de diseño nunca se limitan a los pasos sucesivos”, y para ese modelo, sin iteración es “riesgoso e invita al fracaso”. [3] Como alternativa, Royce propuso un desarrollo más incremental, donde cada paso siguiente se vincula con el paso anterior. El modelo de cascada “clásico” es el de la figura 2. Los modelos se van refinando de forma incremental hasta llegar a la figura 10. Royce dice lo siguiente sobre el modelo de la figura 4:
Creo que el enfoque ilustrado es fundamentalmente sólido. [3]
Ingeniería de sistemas de software
A principios de la década de 1980, Winston Royce acuñó el término "ingeniería de sistemas de software" (SwSE) en uno de los seminarios del curso de Gestión de Adquisición de Software en el Defense Systems Management College en Fort Belvoir, Virginia. [13]
Según Richard H. Thayer, profesor emérito de ingeniería de software en la Universidad Estatal de California en Sacramento, la ingeniería de sistemas de software se ocupa de "aplicar los principios de ingeniería de sistemas específicamente al desarrollo de sistemas de software grandes y complejos, lo que proporciona una herramienta poderosa para la gestión de procesos y productos". [13] Los ingenieros de sistemas de software pueden asumir la responsabilidad de la "gestión técnica general del sistema y la verificación de los productos finales del sistema". [13]
Arquitectura de software
En el artículo de 1991 Arquitectura de software: integración de procesos y tecnología, Royce describió la conexión entre la arquitectura y el proceso de desarrollo de software. [14] Según Philippe Kruchten et al. (2006), este artículo fue el primero en "posicionar la arquitectura de software , tanto en el título como en la perspectiva, entre la tecnología y el proceso". [15]
Royce publicó varios libros y artículos. [16] Libros
1959. Flujo transónico sobre un cuerpo de revolución delgado y sin sustentación . Pasadena: Instituto Tecnológico de California, 1959.
1997. Gestión de proyectos de ingeniería de software . Segunda edición. Con R. Thayer y Ed Yourdon .
Artículos, una selección:
1970. "Gestión del desarrollo de grandes sistemas de software", Actas de IEEE WESCON 26 (agosto): 1–9.
1989. "Centro de tecnología de software de Lockheed". En: Ingeniería de software moderna, fundamentos y perspectivas actuales . Peter A. Ng (ed.). Van Nostrand Reinhold Co. pág. 561–578.
1990. "[2]", 'Mesa redonda sobre el proceso del Dr. Win Royce, 10 de agosto de 1990
1991. "Problemas actuales". En: Aerospace Software Engineering , editado por Christine Anderson y Merlin Dorfman, 5–15. Washington, DC: Instituto Americano de Aeronáutica y Astronáutica.
1991. "Arquitectura de software: integración de procesos y tecnología", con Walker Royce en TRW Quest , vol. 14, núm. 1, pág. 2–15.
1992. "Informe de situación: creación de prototipos asistida por ordenador". Con Walker Royce. En: IEEE Software Vol 9 (6): págs. 77–81
Referencias
^ Dr. Winston W. Royce (1929–1995) en www.informatik.uni-bremen.de. Consultado el 27 de octubre de 2008.
^ [1] El tío Bob Martin menciona la promoción falaz de la cascada en el minuto 49:41 de esta charla. Consultado el 23 de febrero de 2020
^ abcdefgh Winston W. Royce (1970). "Gestión del desarrollo de grandes sistemas de software" en: Documentos técnicos de la Western Electronic Show and Convention (WesCon) del 25 al 28 de agosto de 1970, Los Ángeles, EE. UU.
^ Christine Anderson, Merlin Dorfman (1991) Ingeniería de software aeroespacial: una colección de conceptos
^ Ellis Horowitz (1975) Estrategias prácticas para desarrollar grandes sistemas de software . p. xii
^ "Inicio: Instituto Americano de Aeronáutica y Astronáutica". www.aiaa.org . Archivado desde el original el 28 de abril de 2015.
^ Alan M. Davis, "Rastreo: una simple necesidad descuidada", en: IEEE Software , vol. 12, núm. 5, págs. 6-7, septiembre de 1995
^ Conozca a nuestros líderes de opinión en IBM Rational. Consultado el 27 de octubre de 2008.
^ Barry W. Boehm (1987). "Gestión de procesos de software: lecciones aprendidas de la historia" en Actas de la 9.ª conferencia internacional sobre ingeniería de software ICSE '87, págs. 296-298
^ Wasserfallmodell: Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Consultado en línea el 28 de noviembre de 2007.
^ Winston W. Royce en interaction-design.org. Consultado el 27 de octubre de 2008.
^ Bell, Thomas E. y TA Thayer. Requisitos de software: ¿son realmente un problema? Actas de la 2.ª conferencia internacional sobre ingeniería de software. IEEE Computer Society Press, 1976.
^ abc Richard Hall Thayer (2002). "Ingeniería de sistemas de software: un tutorial". En: Computer , abril de 2002.
^ WE Royce y W. Royce, “Arquitectura de software: integración de procesos y tecnología”, TRW Quest, vol. 14, núm. 1, 1991, págs. 2–15.
^ Philippe Kruchten , Henk Obbink y Judith Stafford (2006). "El pasado, el presente y el futuro de la arquitectura de software". IEEE Software Vol 23 (2). p. 23
^ Royce Winston y WW Royce Lista de publicaciones del servidor bibliográfico DBLP.
