Modelo de Investigación en Ingeniería del Software: Una propuesta de investigación tecnológica Jaime A. Chavarriaga L. Hugo F. Arboleda J. Grupo LIDIS Universidad San Buenaventura, Cali, Colombia {jaime,huarbole}@usb.edu.co Resumen La Ingeniería de Software es una profesión de naturaleza tecnológica, que retoma teorías y conocimientos de diversas fuentes y aborda el desarrollo de software de calidad y a nivel industrial. Como tal, la Ingeniería de Software construye conocimiento en torno a estas prácticas de desarrollo de software, concretado en la definición métodos, modelos y esquemas de funcionamiento que pueden ser aplicados por los ingenieros en sus actividades profesionales. La forma como se construyen estos métodos, modelos y esquemas de funcionamiento que constituyen el conocimiento propio de la Ingeniería de Software se basa en la revisión y formalización de heurísticas surgidas de la experiencia real en procesos y productos de software. Situación esta que obliga a definir métodos de investigación que aborden problemas y situaciones reales de la Industria de Software, que busquen identificar, formalizar y teorizar sobre las mejores prácticas de la misma y sobre su aplicabilidad general en diferentes empresas a nivel regional y mundial. Con el fin de acometer las tareas de investigación, los grupos de investigación deben definir una estrategia de trabajo que permita combinar el trabajo académico en laboratorio con experiencias reales de aplicación de tecnología en empresas de la industria de software. El grupo de investigación LIDIS ha propuesto un esquema en donde se sintetizan algunos de las estrategias y clasificaciones definidas en los últimos años por diversos autores, ofreciendo orientaciones básicas sobre el desarrollo de estas actividades. Palabras claves Ingeniería, Método de Investigación, Ingeniería del Software. 1. Antecedentes La investigación en ingeniería de software es un tema que requiere de una reflexión permanente por parte de los grupos que desean acometer su realización. Máxime aún cuando en algunos ámbitos este tipo de actividad no es considerada algún tipo de investigación en estricto o se confunde con cualquier tipo de proceso de desarrollo de software [3][8].

Conscientes de esta situación, un proceso permanente de reflexión se inició al interior del grupo de investigación LIDIS desde mediados del 2000. En principio, basado en una reflexión epistemológica en torno al conocimiento propio de la ingeniería, de la ingeniería de software, los métodos que se han desarrollado en la historia de la ingeniería [13] [24] y sus posibilidades de aplicación en la Ingeniería de Software [5]. Esta reflexión se ha visto complementada por una serie de trabajos realizados por la comunidad científica internacional sobre caracterizaciones de los trabajos investigativos que se realizan en ingeniería de software [9] [14], los atributos de calidad deseables de este tipo de trabajo [19][20][21] y las bases conceptuales para la realización de diseños de investigación en el área [25][26]. Al interior del grupo, y a partir de una serie de talleres realizados a finales de 2002, un modelo de las actividades de investigación fue definido, identificando las estrategias de trabajo que se aplicarían para desarrollar las tareas investigativas y estableciendo también algunas áreas conceptuales en donde es necesario lograr mayores definiciones. 2. Consideraciones para una Estrategia de Investigación La Ingeniería de Software, como cualquier otra ingeniería, es una profesión tecnológica [5], centrada en la elaboración de productos tecnológicos de software de calidad. Por su propia naturaleza, la ingeniería de software se encuentra estrechamente ligada a la industria de software. En realidad, tanto la industria necesita de la ingeniería para desarrollar sus productos, como los ingenieros requieren de una industria para realizar sus proyectos y tecnofactos. Sin embargo, desde hace algún tiempo se han observado diferencias entre el conocimiento generado en el ámbito académico e investigativo, y su aplicación real en las empresas [7][8]. En muchos casos, problemas y situaciones analizadas y solucionadas en el plano investigativo siguen sin trascender al plano empresarial. Uno de los ejemplos de esta situación, y de la necesidad de adaptaciones de la teoría a la práctica, fue planteada por Jacobson al establecer diferencias entre el método y el proceso [10]. El método hace referencia a la secuencia de actividades que permiten lograr un desarrollo específico en el laboratorio. El método, como tal, no puede ser aplicado directamente y sin diferencias en todas las organizaciones. El proceso representa el conjunto de actividades que se definen para su realización al interior de un grupo de trabajo, considerando su cultura organizacional, su recurso humano y sus experiencias tecnológicas. Aunque podría pensarse que la aplicación de las investigaciones en el plano empresarial es un proceso lineal, en realidad es un proceso iterativo. Por ejemplo, aunque podría pensarse que la secuencia se presenta llevando la teoría a la práctica (Teoría Práctica) o adaptando el método al proceso (Método Proceso), en realidad la teoría se alimenta de la práctica y el método de las adaptaciones a procesos (Método Proceso Método). Las diferentes tecnologías, teorías y métodos sufren un proceso de “maduración” que solo puede lograrse a través de su aplicación en entornos empresariales reales. Algunos métodos de ingeniería

de software, como por ejemplo el Rational Unified Process (RUP), ha evolucionado a través de diferentes versiones fruto de un proceso iterativo establecido desde su creación a mediados de los noventa. Las diferentes etapas de este proceso de maduración han sido analizadas por diferentes autores. Una de las primeras propuestas, elaborada por Martin y McClure [15], establece primordialmente tres fases: (1) Crisis y reconocimiento, (2) Énfasis Académico y (3) Asimilación y Madurez. Siguiendo estos lineamientos, los centros de investigación deben realizar una estrategia de investigación que permita desarrollar y madurar las tecnologías a través del trabajo conjunto de universidades, grupos de investigación, empresas de la industria de software y entidades gubernamentales relacionadas con el sector [4][25]. El Instituto de Ingeniería de Software [23] en Estados Unidos define tres etapas en su estrategia de investigación: (1) Creación, donde se identifican las tendencias y necesidades del departamento de defensa de los Estados Unidos, y se maduran las tecnologías en el ámbito académico, (2) Aplicación, donde se aplica en entornos empresariales reales mediante proyectos de desarrollo y consultoría con el soporte del grupo de investigación para continuar madurando la tecnología, y (3) Amplificación, donde se definen estrategias de transferencia, como cursos, conferencias, libros y licencias de uso. 3. Propuesta de Estrategia de Investigación La estrategia de investigación propuesta, basada en los modelos de Martin y McClure y del SEI, y consiste en tres grandes fases: (1) investigación y desarrollo inicial, (2) Investigación aplicada, y (3) Transferencia. Cada iniciativa o línea de investigación debe cumplir con estas tres fases, en el proceso de maduración de la tecnología. Cada una de ellas involucrando el desarrollo de varios proyectos de investigación, posiblemente cada uno de ellos con métodos y técnicas diferentes.

- Tendencias de la tecnología - Necesidades del entorno - Casos de éxito - Soluciones en casos concretos

- Diagnósticos - Revisión del estado del arte - Investigación académica en laboratorio - Pruebas de concepto

- Proyectos piloto - Uso en proyectos reales - Desarrollo de productos

- Cursos - Conferencias - Licenciamiento

Transferencia

Investigación aplicada

Investigación y desarrollo inicial Retroalimentación a partir de experiencias en proyectos reales

Figura 1. Esquema de la estrategia de investigación 3.1. La investigación y desarrollo inicial: representa el comienzo de cualquier iniciativa o línea de investigación. En ella se delimita el área de trabajo investigativo que se busca desarrollar en la iniciativa. Normalmente surge a partir de una serie de lluvia de ideas en las cuales se busca determinar las principales necesidades de la industria o las tendencias de la tecnología que deben ser analizadas al interior del grupo. En algunos casos, puede surgir también a partir de una solución innovadora e interesante encontrada en la industria o por alguno de los investigadores. Para el desarrollo de esta etapa, normalmente se requieren varios tipos de investigaciones: diagnósticos, revisiones del estado del arte, investigaciones académicas y desarrollo de soluciones en el laboratorio (pruebas de concepto). Una iniciativa culminará esta etapa cuando pueda establecer, por lo menos en ambientes controlados, la factibilidad técnica de una solución al problema propuesto. En algunos centros de investigación [23] existen procedimientos definidos para establecer las nuevas iniciativas o líneas de investigación. Algunas de estas, de hecho, pueden no superar la etapa inicial y no desarrollarse a través de proyectos piloto en empresas reales. En algunos casos se define un etapa de estudio de factibilidad que puede durar unos ocho o nueve meses antes de constituirse una nueva iniciativa. 3.2. La investigación aplicada: es la etapa en donde se busca madurar la tecnología definida en la etapa inicial, trabajando en el desarrollo de la tecnología y en su aplicación en situaciones reales. A medida que se tienen experiencias de aplicación de la tecnología por parte del grupo de investigación y empresas de la industria, se encuentran las posibles fallas en el modelo de solución propuesto y se definen las adaptaciones que puedan ser requeridas para su aplicación en empresas. En esta etapa normalmente se desarrollan proyectos investigativos de naturaleza más empírica y aplicada, en muchos casos siguiendo también esquemas de investigación-acción-participativa. Una iniciativa culminará esta etapa cuando pueda configurar una solución madura a alguna problemática en ingeniería de

software, incluyendo consideraciones sobre las limitaciones e implicaciones de su implementación en empresas reales que realicen procesos de desarrollo de software. 3.3. La transferencia: es la etapa que busca amplificar el impacto de las nuevas tecnologías, prácticas y conocimientos, más allá de las empresas con las cuales se trabajó en el proceso de investigación aplicada. Para cumplir su objetivo, los grupos de investigación desarrollan otros tipos de actividades, tales como cursos, conferencias, y licenciamiento de la tecnología. 4. Consideraciones para los Tipos de Investigaciones En la actualidad se ha logrado un consenso en la comunidad científica sobre el reducido nivel de impacto de las investigaciones en el ámbito empresarial. En parte debido a la falta de evidencia sustancial sobre el valor derivable de la aplicación de estos nuevos conocimientos [7]. Situación que ha motivado la definición de modelos y esquemas de investigación empírica [18] y cualitativa [6]. Algunos de los trabajos iniciales de Basili, Taschi y Zelkowitz [1] [2] se centraron en el carácter experimental de los proyectos de investigación en ingeniería de software y los diseños que deberían emplearse para su ejecución. Zelkowitz y Wallace definieron una clasificación de doce (12) modelos diferentes de verificación experimental en ingeniería de software [25][26].

Otros autores han propuesto clasificaciones sobre los tipos de investigaciones aplicados en Ingeniería de Software. Basili [2] propuso clasificar las investigaciones a partir de los experimentos que se definen en su interior : (1) “in vivo”, cuando se desarrollan al interior de organizaciones que desarrollan software e (2) in vitro” cuando se realizan en entornos controlados. Kitchenham [12] por otra parte, clasificó los modelos experimentales en (1) cuantitativos, cuando se analizan variables cuantificables en los experimentos, (2) cualitativos, cuando se realizan revisión intersubjetiva de algunos atributos (por ejemplo, atributos de calidad) y (3) benchmarking, cuando se realizan pruebas comparativas de diferentes tecnologíaj 6.72 0 Td (a)Tj 6 0 Td (r)Tj 5.28 0 Td (a)Tj 5.4 0 Td (r)Tj 3.96 0 Td (Tj 5.28 0 Td ( )Tj

Para diseñar los diferentes proyectos de investigación, es necesario considerar el conjunto de elementos básicos de evaluación de la investigación establecidos por Shaw [19]: (1) el tipo de pregunta, (2) el producto final, y (3) el mecanismo de verificación. De acuerdo a la clasificación de Shaw, el tipo de pregunta puede corresponder a: (1) Método de desarrollo, cuando se desea definir la forma de construir un tipo de producto particular o desarrollar alguna actividad específica, (2) Método de análisis o evaluación, cuando se establecen mecanismos para evaluar alternativas o determinar el nivel de algún atributo del producto, (3) Diseño, evaluación o análisis de una instancia particular, cuando se analiza alguna propiedad de un producto o proyecto, o se hacen comparaciones entre las mismas, (4) Generalización o caracterización, cuando se busca definir reglas o heurísticas que apliquen en un dominio de la ingeniería, y (5) Estudio de factibilidad o exploración, cuando se busca vislumbrar alguna forma o técnica que no ha sido posible hasta el momento. Según la misma clasificación el tipo de resultado de cada proyecto puede ser: (1) Procedimiento o técnica, cuando se define un conjunto de pasos para acometer una tarea, (2) Modelo cualitativo o descriptivo, cuando se define una estructura o taxonomía para algún área problema, (3) Modelo empírico, cuando se define un modelo predictivo basado en datos observados, (4) Modelo analítico, cuando se define un modelo estructural que permite un análisis formal o la manipulación automática, (5) Herramienta o notación, cuando se implementa una herramienta que apoya algún procedimiento o técnica, (6) Solución específica o prototipo, cuando se desarrolla una aplicación problema que permite observar algún principio de ingeniería, y (7) Reporte de experiencia, cuando se muestra resultados preliminares y observaciones que no han sido suficientemente generalizadas o sistematizadas. El Mecanismo de validación, que garantiza la aplicabilidad de los resultados en otros ámbitos y empresas, puede ser: (1) Análisis, cuando se aplica algún mecanismo riguroso de verificación formal o empírica, (2) Evaluación, cuando se revisan los resultados a partir unos criterios predefinidos, (3) Experiencia, cuando se usan evidencias encontradas en varias aplicaciones reales, (4) Ejemplo, cuando se muestra una sola aplicación que sirve de verificación, (5) Persuasión, cuando se pretende confirmar la validez de la propuesta solo con argumentos no verificables, y (6) Afirmación evidente, cuando no se plantea ninguna argumento de validez. Como es de suponer, los dos últimos mecanismos de verificación son inaceptables (o, por lo menos, los menos deseables) para los investigadores en el área. El investigador, de acuerdo a la fase de la estrategia de investigación, debe seleccionar la combinación adecuada de los elementos de la investigación que le permita cumplir con los objetivos propuestos. Al conjugar el tipo de pregunta, el tipo de resultado y el mecanismote validación, se configura el método o el diseño concreto de la investigación.

Tipo de pregunta

Tipo de Resultado

Mecanismo de Validación

Pregunta

Resultado

Validación

Patrones de diseño de la investigación

Diseño (Método) de la investigación

Figura 2. Esquema de los diseño de investigación Con el fin diseñar sus proyectos, el investigador puede utilizar alguno de los arquetipos o patrones de diseño de investigación utilizados a nivel internacional. Zelkowitz y Wallace [25] [26] definen tres categorías para los diferentes arquetipos de métodos de investigación y verificación en ingeniería de software: (1) Métodos de Observación, donde se recopila información durante la ejecución de los proyectos, (2) Métodos Históricos, cuando se revisa información de proyectos ya terminados, y (3) Métodos controlados, cuando se establecen mecanismos con múltiples observaciones para hacer verificación estadística o de otro tipo. Los métodos de Observación normalmente son mecanismos que permiten detectar aspectos interesantes al interior de proyectos de software y podrían servir de base para nuevos proyectos experimentales. Este tipo de métodos incluyen: (1) Monitoreo de proyecto, donde se recopila información sin ánimo de influir en el desarrollo del mismo, (2) Estudio de caso, donde la información se recopila siguiendo un método y un propósito especial, (3) aserción, cuando se recopila información para demostrar algún planteamiento o idea, y (4) estudio de campo, cuando se revisan de forma simultánea varios proyectos. Los métodos Históricos permiten recopilar experiencias y conocimientos de proyectos y productos ya elaborados, permitiendo reconocer y recopilar patrones y heurísticas, así como definir bases para nuevos proyectos experimentales. Los métodos Históricos son: (1) Investigación literaria, cuando se revisa información de documentos y artículos públicamente disponibles, (2) datos legados, cuando se revisan los artefactos y documentos productos de un proyecto de desarrollo ya terminado, (3) lecciones aprendidas, cuando se analizan los resultados de un proyecto para establecer aspectos cualitativos que puedan aplicarse a nuevos desarrollos, y (4) análisis estático, cuando la revisión se hace sobre productos terminados y no sobre los documentos generados en su construcción.

Los métodos Controlados, están diseñados para establecer conclusiones fácilmente verificables, normalmente permitiendo corroborar descubrimientos, técnicas o modelos encontrados mediante las otras técnicas. Los métodos controlados son: (1) experimento replicado, cuando se aplican métodos o técnicas diferentes en varios proyectos de forma simultánea para realizar comparaciones, (2) experimento en entorno sintético, cuando se utilizan proyectos “simulados” en laboratorio o en ambientes controlados, (3) análisis dinámico, cuando se modifica un producto para analizar su comportamiento y hacer comparaciones, y (4) simulación, cuando se hacen simulaciones de los proyectos o productos en modelos del mundo real. 5. Experiencias utilizando el Modelo de Investigación La primera iniciativa del grupo de investigación LIDIS en donde se ha intentado aplicar parte de este modelo general de investigación, se inició a finales de 2001 en el tema de “diseño y reutilización de arquitecturas de software”. Esta iniciativa surgió con el fin de apoyar los procesos de fortalecimiento en temas de diseño de software y mejoramiento de productos de la red de Parques Tecnológicos de Software (ParqueSoft) y algunas empresas de desarrollo de software en Colombia. Durante su desarrollo, la iniciativa ha incluido una gran variedad de proyectos, incluyendo la definición de dominios de aplicación, el diagnóstico sobre los productos y prácticas al interior de ParqueSoft, el establecimiento de nuevos estilos de arquitectura utilizando herramientas opensource, la documentación de patrones de diseño, la elaboración de librerías y marcos de trabajo (frameworks) y la construcción de herramientas de desarrollo y generación de código. En su primera etapa, Investigación y desarrollo inicial, el grupo de investigadores trabajó en la configuración varios proyectos que nos permitieran caracterizar mejor el problema y encontrar soluciones a los mismos. Muchos de estas investigaciones requirieron diseños variados: investigación literaria, estudio de campo, estudio de caso, experimento replicado y monitoreo de proyectos, entre otros. En esta primera etapa, desarrollada en el transcurso de un año y medio, se realizaron algunas actividades tanto en el laboratorio, como en dos de las empresas de desarrollo de software. En esta primera etapa se buscaron proyectos que, por sus propias características, permitieran cubrir el más amplio espectro de posibilidades en términos de tipos de requerimientos funcionales y no funcionales aplicables a ese contexto. Al final de esta etapa se definió con un conjunto de métodos, técnicas, patrones, estilos y herramientas de software que podrían resolver el problema en una gran variedad de empresas con características similares. En la segunda etapa de la estrategia, Investigación aplicada, una gran variedad de proyectos piloto fueron propuestos y realizados. En total se han desarrollado hasta el momento unos siete proyectos piloto con empresas reales en donde los modelos, esquemas y herramientas propuestos se han colocado a prueba y han servido como retroalimentación a las investigaciones. Proyectos que nos han permitido constatar y comparar los resultados y hacer modificaciones y mejoras sobre los planteamientos.

En la actualidad, la iniciativa se halla revisando muchos de los resultados de los proyectos piloto, trabajando en refinar las soluciones planteadas, definir modelos predicativos más confiables y establecer una tecnología madura que pueda solucionar algunos de los problemas y pueda aplicarse en otros entornos. Seguramente, la iniciativa tendrá que seguir desarrollando investigaciones aplicadas durante algún tiempo más antes de consolidar un paquete tecnológico maduro que pueda ser presentado a la comunidad científica o licenciado a la industria. A partir de este trabajo, nuevas ideas de investigación han surgido, en especial en el campo de la “migración de aplicaciones” y “rediseño de arquitectura”. Situación que podrá conducir en un futuro al establecimiento de nuevas iniciativas de investigación y a un nuevo conjunto de etapas de una estrategia de investigación en esa área. 6. Conclusiones La Ingeniería de Software no es una ciencia, es una profesión tecnológica. Una profesión que aborda la construcción e implementación de un tipo particular de tecnología, el software, y genera conocimientos relacionados con el desarrollo de estas prácticas en proyectos y situaciones reales. Por esta razón, esta profesión, como cualquier profesión tecnológica, se encuentra íntimamente relacionada con la industria de software y sus procesos de mejoramiento y fortalecimiento. Plantear una estrategia de trabajo investigativo que considere el desarrollo de la tecnología, la puesta a prueba de la misma en situaciones reales y su transferencia a las empresas de la industria de software, debe ser un aspecto clave en el proceso de consolidación de los grupos y líneas de investigación. El involucrar actividades al interior de empresas de software, incluyendo proyectos piloto de algunas tecnologías y/o proyectos de consultoría o desarrollo, no significa que la estrategia de investigación no involucre el rigor apropiado o no se convierta solamente en una estrategia comercial. Involucrar a las empresas de software en realidad es una necesidad en el desarrollo de tecnologías realmente utilizables en la industria. El desarrollo de las investigaciones debe realizarse con un rigor apropiado, buscando mecanismos de verificación que posibiliten determinar la veracidad y aplicabilidad de sus resultados. Comprendiendo que los métodos no aplican indistintamente a todo tipo de proyectos u organizaciones y que una mayor comprensión sobre la forma como ellos aplican en un caso determinado o no es necesaria. La reflexión permanente sobre la estrategia y sobre los métodos de investigación apropiados, son en sí mismas, actividades que buscan definir el rigor apropiado a las actividades de los grupos de investigación. En la actualidad, una gran variedad de autores e investigadores han desarrollado algunos modelos y teorías relacionadas con los procesos de investigación en ingeniería de software.

Lamentablemente, muchos de ellos parecen esquemas aislados o no articulados apropiadamente. Los grupos de investigación pueden establecer su propio esquema de trabajo a partir de la articulación de las diferentes teorías y modelos existentes, buscando establecer con claridad (1) la estrategia general para el trabajo investigativo, (2) las áreas temáticas que deben ser abordadas, (3) los elementos básicos del diseño de la investigación y (4) una serie de arquetipos o patrones de diseño de las investigaciones. Bibliografía [1] Basili, V. The experimental paradigm in software engineering en Rombach, D., Basili, V., Selby, R. Experimental Software Engineering Issues: Critical Assessment and Future Directives. Proceedings of Dagstuhl-Workshop. publicado en Lecture Notes in Computer Science #706. Springer-Verlag. 1993. [2] Basili, V. R., The Role of Experimentation: Past, Present, Future, (Keynote presentation), 18th International Conference on Software Engineering, Berlin, Germany, March, 1996. [3] Campos, F. J. Reingeniería de la Metodología en MIFISIS 2002. En MIFISIS 2002. I Workshop sobre Métodos de Investigación y Fundamentos Filosóficos en Ingeniería del Software y Sistemas de Información. Universidad Rey Juan Carlos. Noviembre 18 de 2002. http://kybele.escet.urjc.es/MIFISIS/Articulos/Art10.pdf [4] Consortium for Software Engineering Research. http://www.cser.ca [5] Chavarriaga, J. La Ingeniería de Software como profesión tecnológica: Implicaciones en la investigación. Métodos de Investigación y Fundamentos Filosóficos en Ingeniería del Software y Sistemas de Información. Madrid: Universidad Rey Juan Carlos, 2003. p.162 178 [6] Dewayne, P. Porter, A. Votta, L. Empirical Studies of Software Engineering: A roadmap. en Finkelstein, A. (editor) Proceedings of the Conference on The Future of Software Engineering. ACM Press. 2002. http://www.softwaresystems.org/front.html [7] Finkelstein, A. Kramer, J. Software Engineering: a roadmap en Finkelstein, A. (editor) Proceedings of the Conference on The Future of Software Engineering. ACM Press. 2002. http://www.softwaresystems.org/front.html [8] Glass, R. The Software Research Crisis, IEEE Software, Noviembre 1994. http://csdl.computer.org/comp/mags/so/1994/06/s6042abs.htm [9] Galan, F.J. Cañete, J.M. ¿Qué se entiende en España por Investigación en Ingeniería de Software? En MIFISIS 2002. I Workshop sobre Métodos de Investigación y Fundamentos Filosóficos en Ingeniería del Software y Sistemas de Información. Universidad Rey Juan Carlos. Noviembre 18 de 2002. http://kybele.escet.urjc.es/MIFISIS/Articulos/Art09.pdf [10] Jacobson, I. Object Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley. 1992. [11] Johnson, R. Beck, K. Booch. G. Cook, W. Gabriel, R. Wirfs-Brock, R. How to get a Paper Accepted at OOPSLA. Panel. OOPSLA’93. http://www.acm.org/sigs/sigplan/oopsla/oopsla96/how93.html [12] Kitchenham B. A., Evaluating software engineering methods and tool, ACM SIGSOFT Software Engineering Notes, (January, 1996) 11-15.

[13] Koen, B. Definition of the Engineering Method. American Society for Engineering Education. Washington. 1985. [14] Marcos, E. Investigación en Ingeniería de Software vs. Desarrollo de Software en MIFISIS 2002. I Workshop sobre Métodos de Investigación y Fundamentos Filosóficos en Ingeniería del Software y Sistemas de Información. Universidad Rey Juan Carlos. Noviembre 18 de 2002. http://kybele.escet.urjc.es/MIFISIS/Articulos/Art11.pdf [15] Martin, J. y McClure, C. Structured Techniques for Computing. Prentice-Hall / Englewood Cliffs, NJ, EE.UU. 1985 [16] Parnas, D. "Successful Software Engineering Research". Software Engineering Notes, Vol. 23, No. 3, May 1998, pp. 64-68 [17] Potts, C. Software Engineering Research Revisited, IEEE Software. Septiembre 1993. [18] Seaman, C., Conradi, R. Qualitative Methods in Software Engineering Research. en la Conferencia ISERN, Octubre 2000. http://csdl.ics.hawaii.edu/isern/slides/seaman.qual.ppt [19] Shaw, M. What makes Good Research in Software Engineering?. European Joint Conference on Theory and Practice of Software ETAPS 2002. Abril 2002. http://www2.cs.cmu.edu/~Compose/ftp/shaw-fin-etaps.pdf [20] Shaw, M. Designing Good Research Projects in Software Engineering… and getting results accepted for publication. Carnegie Mellon University. http://www.csc.calpoly.edu/~csturner/courses/shaw.pdf [21] Shaw, M. Writing Good Software Engineering Research Papers. Minitutorial. Internacional Conference on Software Engineering, ICSE 2003. Mayo 2003. http://www2.cs.cmu.edu/~Compose/shaw-icse03.pdf [22] Snyder, A. How to get a Paper Accepted at OOPSLA. OOPSLA’91 Proceedings. http://www.acm.org/sigs/sigplan/oopsla/oopsla96/how91.html [23] Software Engineering Institute. Carnegie Mellon University. http://www.sei.cmu.edu [24] Sprague de Camp, L. The Ancient Engineers. Barnes & Noble. New Cork. 1993. [25] Zelkowitz, M. Wallace, D. Experimental Models for Validating Technology. IEEE Computer . Mayo 1998, pp 23-31. [26] Zelkowitz, M. Wallace, D. Experimental Validation in Software Engineering. Conference of Empirical Assessment & Evaluation in Software Engineering, Keele University. Marzo 1997. http://hissa.nist.gov/exper/ease.html