Modelo de Investigación en Ingeniería del Software: Una propuesta

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ías para analizar su rendimiento y beneficio relativo.
Trabajos posteriores centrados en la estructura de los documentos técnicos que se presentan
a las conferencias internacionales motivaron una serie de nuevas clasificaciones y
consideraciones [11][22]. Shaw definió una serie de atributos de calidad que podrían
evaluarse en un proyecto de investigación, así como una serie de recomendaciones para su
diseño [19][20] [21].
4.1. Tipos de Investigaciones
Al interior de cada una de las fases de la estrategia de una iniciativa o línea de investigación
deben diseñarse proyectos de investigación y desarrollo que permitan madurar la tecnología
apropiada y solucionar los problemas específicos definidos en cada una de las iniciativas o
línea de investigación.
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