Universidad Autnoma Metropolitana

Unidad Azcapotzalco
Divisin de Ciencias Bsicas e Ingeniera

La Ingeniera de Software: Una Discusin Epistemolgica

TESIS
como requisito parcial para obtener el ttulo de

Maestro en Ciencias de la Computacin

presenta

J. Jess Mara Zavala Ruiz

Asesora:

M. en C. Rafaela Blanca Silva Lpez

20 de julio de 2011

La tesis intitulada "La Ingenieria de Software: Una Discusion

Epistemologica", fue realizada como una Idonea Comunicacion de

Resu ltados , bajo la direccion del Honorable Jurado y ha sido revisada y

aprobada par el, como requisito parcial para que el alumna J. Jesus Maria

Zavala Ruiz obtenga el titulo de Maestro Computacion:

en

Ciencias de la

PRESIDENTE

M. en C. Hugo Pablo Leyva

SECRETARIO:

Dra. Hanna J adwiga Oktaba

VOCAL 1:

VOCAL 2 :

M. en C. Rafa fa Blanca Silva Lopez

Mexico, D. F.,

20

de J ulio de 2011.

(i) Abstract

Software Engineering: An Interdisciplinary Epistemological Discussion Software Engineering, as discipline, is on a profound crisis because it has not a clear-cut definition on its fundamentals for a better theory and practice fitting. The Software Engineering Method And Theory (SEMAT) Initiative that overrides the Guide to Software Engineering Body of Knowledge (SWEBoK), confirms this status which extends over more than 40 years. First, after a deep historical review and context discussion, using an interdisciplinary epistemological framework, founded on a basic element set, this research proposed to create the Science of Software. For that, an ontological four-level framework is propossed. The first ontological level, is organized nearby software as programming language, algorithm, calculus (computation) in a broad sense, and software system but constrained by hardware. The second level focuses on software development as a work organization process, a core subject in organization theory. The third level is software project as a social process and a temporary organization, a core domain in project management theory. And, fourth level addesses the software factory as a wide organizational and entrepreneurial enterprise, more magerial and administrative in nature. But, only the first one level is a computer domain in essence and the best choice for the core or essence on the proposed Science of Software. As an alternative, if the Science of Software pretends to be all-inclusive, then it requires be a multidisciplinary umbrella and approach. Next, two model-set has suggested, first to define the strategy for the paradigmatic change, and second, to integrate all these items in a well-defined and complimentary framework. Therefore, best practices are best fitted with knowledge, ethical behaviorbut, and rooted on its ontology. Keywords: computer science, software engineering, science of software, philosophy of science, philosophy of software, paradigm change

(i) Resumen

La Ingeniera de Software se encuentra en una crisis disciplinaria por la falta de fundamentos bien establecidos. El impulso de la iniciativa Software Engineering Method And Theory (SEMAT) ignorando la Guide to Software Engineering Body of Knowledge (SWEBoK) confirma esa situacin que se prolonga ya por ms de 40 aos. Partiendo de una propuesta epistemolgica interdisciplinaria, esta investigacin propuso la creacin de la Ciencia del Software. Despues de una profunda revisn histrica y del contexto, se propuso un marco conceptual de cuatro niveles ontolgicos complementarios. El primer nivel aborda el software como lenguaje de programacin, algoritmo, clculo y como sistema de software acotado por el hardware; es la dimesin tcnica. El segundo nivel ontolgico abord el proceso de produccin o desarrollo de software como un proceso de organizacin del trabajo, un tema central en la teora de la organizacin. El tercer nivel se centr en el proyecto de software como proceso social y organizacin temporal, dominio de la teora de la administracin de proyectos. Y el cuarto nivel abord la fbrica de software como una empresa de naturaleza organizacionl y empresarial. Se propusieron dos modelos en complemento, el primero originado en la psicologa social para delinear una estrategia de cambio paradigmtico y el segundo, un modelo filosfico originado en la administracin, para integrar todos los elementos en una propuesta integral. As, las mejores prcticas estarn basadas en fundamentos ontolgicos y epistemolgicos slidos y en un comportamiento tico, que lleve al establecimeinto de la filosofa de la ciencia del software. Palabras clave: ciencias de la computacin, ingeniera de software, ciencia del software, filosofa de la ciencia, crisis desciplinaria, filosfa del software, cambio paradigmtico.

xiii

(ii) Tabla de Contenido

Introduccin ........................................................................................................... 1 1. Contexto .......................................................................................................... 1 2. La investigacin .............................................................................................. 8 2.1. Pertinencia ............................................................................................... 8 2.2. Relevancia ............................................................................................... 11 2.3. Objetivos ................................................................................................ 13 3. Estructura del documento ............................................................................ 14 Captulo 1: Metodologa de investigacin .............................................................17 1.1. Introduccin ................................................................................................17 1.2. Estado del arte ........................................................................................... 19 1.3. El mtodo cientfico y la abduccin ........................................................... 24 1.4. Posturas epistemolgicas........................................................................... 30 1.5. Operacionalizacin de la investigacin ..................................................... 34 1.6. Conclusiones .............................................................................................. 36 Captulo 2: Qu son las Ciencias de la Computacin?: Una Interpretacin Eclctica ............................................................................................................... 38 2.1. Introduccin............................................................................................... 38 2.2. La revolucin de la computadora ..............................................................40 2.3. El origen de la nueva ciencia ..................................................................... 43 2.4. El reconocimiento cientfico ..................................................................... 47 2.5. La ciencia de los algoritmos y ms ............................................................ 52 2.6. La fractura por el impulso de la ingeniera de software ........................... 56 2.7. Las ciencias de la computacin hoy .......................................................... 64 2.8. Los modelos curriculares para Mxico ..................................................... 69 2.9. Discusin final ........................................................................................... 72 2.10. Conclusiones ............................................................................................ 74 Captulo 3: Qu es la Ingeniera de Software?: Una Visin Crtica ................... 77 3.1. Introduccin............................................................................................... 77 3.2. La industria del software y su importancia............................................... 78 3.3. El invento de una disciplina sui generis ................................................ 87 3.4. La legitimacin industrial ......................................................................... 97 3.5. La profesionalizacin ocupacional .......................................................... 106 3.6. La institucionalizacin acadmica .......................................................... 109 3.7. La otra ingeniera de software ............................................................... 111 3.8. Las crticas a la disciplina y a la profesin ............................................... 117 3.9. Discusin final ......................................................................................... 123 3.10. Conclusiones .......................................................................................... 125
xv

xvi

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

Captulo 4: Fundamentos para una Filosofa de la Ciencia del Software ......... 127 4.1. Introduccin ............................................................................................. 127 4.2. Antecedentes............................................................................................ 129 4.3. Ontologas del software ........................................................................... 132 4.3.1. Fundamentos ontolgicos ................................................................. 132 4.3.2. Los computers, las computadoras y el clculo .............................. 134 4.3.3. El hardware y el software ..................................................................141 4.3.4. El orgware y el software organizacional y el sistema ....................... 147 4.3.5. El desarrollo, mantenimiento y evolucin de software .................... 152 4.4. Epistemologas del software .................................................................... 159 4.4.1. Fundamentos epistemolgicos ......................................................... 159 4.4.1. Los sistemas y el anlisis de sistemas ............................................... 165 4.4.2. Los proyectos de software y la administracin de proyectos ........... 168 4.4.3. Una visin alterna al desarrollo de software: La semitica ............. 176 4.5. Metodologas del software ....................................................................... 182 4.5.1. Metodologa para la produccin de software.................................... 182 4.5.2. Metodologas cientficas para el software ........................................ 184 4.6. Discusin final ......................................................................................... 187 4.7. Conclusiones ............................................................................................ 194 Captulo 5: Discusin ......................................................................................... 197 5.1. Introduccin ............................................................................................. 197 5.2. La crisis y el agotamiento de la disciplina ............................................... 198 5.3. La jaula de hierro del racionalismo dominante .................................. 200 5.4. La dimensin gerencial y sus problemas ............................................... 205 5.5. El cambio paradigmtico y sus desafos .................................................. 214 5.6. Marco filosfico para la concepcin de la Ciencia del Software ............ 228 5.7. Conclusiones ............................................................................................239 Captulo 6. Reflexiones finales ...........................................................................243 6.1. Sobre las ciencias de la computacin ......................................................243 6.2. Sobre la ingeniera de software ...............................................................244 6.3. Sobre los aportes .................................................................................... 248 6.4. Prospeccin e investigacin futura ......................................................... 252 Referencias ......................................................................................................... 255

(iii) Lista de Figuras

Figura 3.1. Esquema lgico de LEO I ...................................................................80 Figura 3.2. Vieta sobre la computadora en 1960s ............................................. 89 Figura 3.3. Mensaje de correo electrnico del origen de Adempiere ................. 115 Figura 3.4. Esquema de pensamiento racional de ingeniera ............................ 121 Figura 4.1. Iceberg organizacional o sistema socio-tcnico .............................. 149 Figura 4.2. El corazn de la interdisciplinariedad ............................................ 164 Figura 5.1. La ingeniera de software en el Sistema de Clasificacin en Computacin de la ACM.................................................................206 Figura 5.2. reas clave de las ciencias de la computacin segn el Currculum 2008 de la ACM .............................................................................. 207 Figura 5.3. reas clave de la ingeniera de software ACM/IEEE ..................... 208 Figura 5.4. Ncleo de inteligibilidad de la ingeniera de software .................... 223 Figura 5.5. El Rombo Filosfico de Bdard aplicado a la Ciencia del Software 236

xvii

(iv) Prlogo

En 1995 emprend mis estudios de maestra en ciencias de la computacin en la Universidad Autnoma Metropolitana (UAM), Unidad Azcapotzalco, en la ciudad de Mxico, motivado por las necesidades laborales. Tan pronto como comenc a empaparme de los trminos de la disciplina, comenzaron a surgirme muchas interrogantes. En primer lugar, qued sorprendido cuando descubr que haba una manera cientfica o por lo menos tcnica, para desarrollar sistemas de software y de sus variadas metodologas de anlisis y diseo de sistemas. Vaya que era grande mi ignorancia sobre el tema! Luego, descubr lo fascinante de las matemticas discretas, de las tcnicas de programacin, de los algoritmos y del anlisis de la complejidad, de los lenguajes de programacin, de los autmatas finitos y la teora matemtica de los lenguajes, de los fractales y la teora del caos. En aquel entonces, slo saba lo elemental de programacin estructurada pues diez aos antes haba tomado, en la Universidad Autnoma Chapingo, el nico curso sobre computacin en la licenciatura Introduccin al Cmputo Electrnico, que fue suficiente para m por cerca de 15 aos. Despus de ese primer curso en 1984, en los siguientes tres aos llegu a dominar el Job Control Language (JCL), Fortran IV, Fortran 77 y lo elemental del Statistical Anlisis System del SAS Institute, junto con la perforacin de tarjetas y los listados de papel como resultado de las corridas de mis programas en la IBM 360 del Centro de Estadstica y Clculo (CEC) del Colegio de Postgraduados, en aquel entonces con sede en Chapingo, Mxico. Creo que en aquel entonces gastbamos ms papel que tiempo de CPU (Unidad Central de Procesamiento) pues hasta lo reciclbamos para tomar apuntes. En el CEC perforaba las tarjetas y corra mis programas en la madrugada y luego de algunos privilegios, los escriba con un editor de una sola lnea a la vez desde una de las terminales mbar de la sala del primer piso. Otra de las motivaciones de visitar el CEC,
xix

xx

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

pero de da, eran los hermosos jardines con rosales multicolores, pulcramente cuidados, hoy slo existentes en la memoria. Antes del advenimiento de las computadoras personales us una terminal HP-150, adaptada con un par de floppies de 3.5 y una CPU y con las computadoras personales (Personal Computers, PCs en ingls), todo se transform. Abandonamos el CEC y su mainframe y la computacin se volvi ms accesible a nosotros como estudiantes de licenciatura. En aquellos tiempos, llegu a programar todos los anlisis estadsticos para el diseo de experimentos de mi curso, algunos en una calculadora HP con lenguaje BASIC. En los lenguajes Fortran 77, BASIC y PASCAL program el anlisis estructural con el Mtodo de Hardy Cross y otros clculos estructurales, el balanceo de sistemas de redes de tuberas hidrulicas, los perfiles hidrulicos en canales para el diseo de estructuras, los clculos topogrficos y prcticamente todo aquello en lo que era posible ahorrar tiempo de clculo. Despus de mi nico curso elemental de programacin, fue gracias al Ing. Humberto Martnez vila (RIP) que me introduje es el mundo de la programacin en serio. Mi agradecimiento a l in memoriam. Algunos de los compaeros que socializaron su conocimiento sobre programacin conmigo fueron Jos Martnez El Ch, Odiln, Jaime, Esquivel y otros con quienes compartamos las noches y las madrugadas en aquella pequea sala de cmputo del edificio de Irrigacin en Chapingo. Pero regresemos al pasado ms inmediato. En el Programa de la Maestra en ciencias de la computacin siempre me pregunt qu era eso de Ingeniera de la Programtica. Luego me enter que se refera a ingeniera de software, hoy una asignatura o unidad de enseanza-aprendizaje (UU.EE.AA.) como se le conoce en la UAM, lamentablemente desaparecida del programa de estudios. En aquel entonces, esos trminos carecan de sentido para m. As que tom Ingeniera de la Programtica con el Dr. Ignacio Canals Navarrete (RIP), mi primera clase personalizada en la vida pues, para fortuna nuestra, ramos slo

Prlogo

xxi

tres alumnos. Lemos muchos artculos de tal suerte que la dinmica de la clase cambi comparada con aquellas muy tcnicas. La primera clase de esa materia fue sobre la llamada crisis del software y la ingeniera de software. Las estadsticas reportadas en la lectura del famoso Reporte Chaos y de un par de artculos proporcionados atinadamente por mi profesor eran apabullantes: cifras estratosfricas de inversin en proyectos de software y altas tasas de fracasos como consecuencia de la baja calidad. Aquello me inquiet tanto que partir de entonces, me obsesion con la bsqueda de las causas del fracaso de los proyectos de software. Primero incursion en las metodologas de anlisis y diseo de sistemas. Luego empec a comparar la ingeniera de software como disciplina con otras ingenieras y siempre encontr muchas diferencias. Eso fue ms impactante sobre todo al compararla con la irrigacin eje de mi formacin como ingeniero, una carrera interdisciplinaria entre agronoma e ingeniera civil que, dicho sea de paso, quizs es una de las ingenieras ms antiguas pues la historia la consigna como la creadora de las grandes obras de irrigacin en Mesopotamia hace ms de 5 mil aos. No est de ms recordar que mi maestro, el Dr. Canals, fue reconocido como Maestro Emrito en la UAM el 17 mayo de 1996, en una ceremonia solemne a la cual tuve el honor de asistir. A la par de que tomaba la materia de Ingeniera de la Programtica, tom el seminario de Anlisis y Diseo de Sistemas con el Dr. Rubn Caudillo Flix. Ese fue un excelente seminario que me proporcion las bases tericas y prcticas para complementar lo que aprenda en la otra materia. Luego de terminar esos cursos, segu de cerca la Guerra de Metodologas que se daba desde mediados de los 1990s en torno al Anlisis y Diseo de Sistemas. Despus de aprender los mtodos clsicos con el Dr. Caudillo, aprend el Lenguaje de Modelado Unificado (Unified Modeling Language, UML), til indudablemente, pero segua habiendo detalles sin resolver. Tiempo despus, apareci en el mercado el Proceso Unificado Rational (Rational Unified Process, RUP) que yo haba

xxii

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

estudiado como Objectory en mis clases y con ello surgi la esperanza de resolver la crisis del software. En este contexto, un ao despus de haber terminado mis crditos, en el ao 2000 y cuando la informacin en espaol era muy limitada sobre la ingeniera en software, escrib un ensayo sobre el tema, como parte de mi tesis de maestra, ensayo que por cierto, se ha mantenido en los primeros lugares en las bsquedas de Google bajo el tema ingeniera de software (Zavala, 2000). Luego, entre el ao 2000 y 2003, me involucr en la industria del software y viv de cerca el fracaso de varios proyectos o por lo menos, no resultaron tan exitosos como esperaba. As, confirm lo que aos antes haba estudiado al respecto y ese ao busqu en la administracin la solucin a mi deficiencia explicativa porque poco a poco, se vislumbraba que las causas de esos fracasos no eran la falta de tcnica, sino la complejidad organizacional. As fue como encontr el Programa de Posgrado en Estudios Organizacionales de la UAM en Iztapalapa al que concurs al nivel de maestra por no haber obtenido el grado en la maestra en ciencias de la computacin. Logr entrar a este fascinante campo, buscando respuestas a la compleja problemtica de los proyectos de software y a su fracaso. As, incursion en la teora de las organizaciones y escrib un breve ensayo (Zavala, 2004) donde deslic la hiptesis de que las causas del fracaso de los proyectos de software son ms de ndole organizacional que de otra naturaleza. As, de manera intencional me fui formando como interdisciplinario entre la ingeniera, la agronoma, la computacin y la administracin complementada por la experiencia laboral tambin mltiple.

Prlogo

xxiii

Este documento se defender pblicamente el 20 de julio de 2011 en la sala de juntas del Departamento de Sistemas de la Divisin de Ciencias Bsicas e Ingeniera de la Universidad Autnoma Metropolitana, Unidad Azcapotzalco. Finalmente, cierro este captulo acadmico, gracias al apoyo de mi amada Helicnide.

J. Jess Mara Zavala Ruiz

Ciudad de Mxico, D.F., 20 de julio de 2011.

Introduccin La frase ingeniera de software [en la Conferencia de Garmisch] fue elegida deliberadamente provocativa, implicando la necesidad de que la manufactura del software deba estar basada en los tipos de bases tericas y disciplinas prcticas, que son tradicionales en las ramas establecidas de la ingeniera. (Naur y Randell, 1969, p. 13) La situacin ha cambiado bastante desde entonces [1967-1968]; [] algunos de los fabricantes, a los que se dirigi la provocacin, claman que ya obedecen los principios de ingeniera de software, lo que sea que ellos quieran decir. (F. L. Bauer, citado por Blum, 1992, pp. 16-17). Nosotros apoyamos un proceso para refundar la ingeniera de software basada en una teora slida, unos principios probados y en mejores prcticas (Jacobson, Meyer y Soley, 2010, p. 1)
1. Contexto

En los proyectos nuevos de software, es frecuente encontrar que un proyecto dcil se pueda convertir en un verdadero monstruo que todo lo devore y que infunda el mismo temor cual criatura monstruosa. En este sentido, Fred Brooks (1995, p. 180-181) hizo el comparativo de un proyecto con el hombre lobo de la leyenda, para el cual, se anhela encontrar la mgica bala de plata (silver bullet, en ingls) que finalmente lo someta, lo mande a descansar. Poco a poco, los parches del software (patches) terminan convirtiendo a un sistema relativamente pulcro (que en realidad es raro), en un verdadero spaghetti de elementos tecnolgicos, en un autntico y nico Frankestein, como suele referirse irnicamente a ellos. A ese verdadero monstruo, ya ni sus creadores conocen a detalle pues sus secretos no se encuentran en los manuales o documentos, si es que alguna vez estuvieron ah, detalles que son indispensables para seguir mantenindolo con vida.

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

Tambin, con relativa frecuencia, uno observa o conoce ancdotas de project managers (gerentes de proyectos) de software (y de directivos) que desconocen la complejidad tcnica y organizacional involucrada y literalmente lloran cuando el proyecto se les est yendo de las manos, cuando escapa a su control. Lo mismo ocurre con los lderes tcnicos que ignoran la complejidad organizacional de este tipo de proyectos que sucumben ante su incapacidad de controlar a voluntad el curso de los acontecimientos, de las relaciones, los conflictos que frecuentemente ocurren. Sin exagerar, puedo afirmar que toda organizacin moderna tiene su propio monstruo similar al descrito, a veces, prendido con alfileres y que ante cualquier menor cambio, siempre habr la incertidumbre de que el monstruo despierte y se vuelva contra sus profanadores. Da tras da, el proyecto adquiere su propia dinmica organizacional y cuando se atrasa, por lo general, lo hace sin control. El escenario que he descrito es muy bien conocido por todos aquellos programadores y en general, por todos los trabajadores de la industria del software y cada vez ms por la gente encargada de definir las especificaciones de los proyectos de software que trabaja en las reas normativas u operativas de las organizaciones, que viven da a da muchos de estos desafos. La dinmica del proyecto no depende de su origen, es decir, no importa si el proyecto de software es un capricho de la alta direccin, la adopcin de una moda administrativa (management fad) del momento o si es una necesidad operativa. Frecuentemente, cuando el lder del proyecto (project manager, como se le llama en el medio) es un novato y tiene una orientacin tcnica, y a veces tambin le ocurre al ms experimentado, se aferra a encontrar una solucin mgica (una silver bullet en ingls) que lo saque de apuros y le apuesta a las matemticas y a la estadstica. Despus comienza a aplicar algunas de las

Introduccin

recetas de sus cursos de administracin de proyectos (project management1) y el project manager adopta a la rigidez de los controles de la administracin clsica para intentar que las cosas marchen como relojito y se vuelca sobre el control del famoso project (cronograma) y de los time sheets (como se le llama en el medio a los reportes de tiempo laboral) y de avances. Al mismo tiempo, el project manager intenta que el alcance u objetivo del proyecto no se crezca demasiado y frena lo ms que puede a sus usuarios o clientes, manteniendo, al mismo tiempo, al mnimo el tamao del equipo del proyecto. Cuando eso le falla, entonces el project manager le apuesta al proceso y a la disciplina intentando controlar el comportamiento de los miembros del equipo, primero con la persuasin y luego con amenazas y reprimendas, siempre en la bsqueda de esa silver bullet. En algn momento del tiempo, el project manager hace cambios en la estructura del equipo de proyecto pensando que ah est el problema y no en l mismo y algunos miembros saldrn y otros se integrarn provocando ms problemas al interior del equipo y ms retraso. Cuando le llegue la contralora, el project manager se coludir con ellos para pasar (aprobar) la supervisin y los problemas no saldrn a la luz. As, poco a poco, las jornadas de trabajo se incrementan, igual que el desgaste y el cansancio, con la promesa de una recompensa futura que no llegar y a la postre, minar la escasa confianza.

1 En este documento se considera a la palabra inglesa management como equivalente de los trminos utilizados en espaol, tales como: administracin, gerencia, direccin, manejo, y en menor grado, gestin. Por igual, la palabra manager se usa para designar al gerente, administrador, encargado o responsable de las actividades gerenciales. Tambin adopto la palabra inglesa managerial para designar a lo gerencial. Cabe sealar que la palabra inglesa management tambin tiene muchos significados, tal como existe en espaol. De hecho, los norteamericanos prefieren usar management a administration que se usa para designar la administracin pblica. Para una discusin al respecto ver la justificacin de la traduccin respectiva en Fayol (1949, p. iv-vi). La administracin como ocupacin tambin es muy variada (Cf. Mintzberg 2009).

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

Entonces, los fines de semana maratnicos se vuelven una regla a la que ningn miembro del equipo puede negarse ante la amenaza de una buena reprimenda disciplinaria, vestida en un discurso de profesionalismo barato. As, poco a poco el proyecto se vuelve un desastre en todos los sentidos. Sin embargo, tarde que temprano, el project manager caer en la cuenta de que la solucin mgica que esperaba no existe y de quizs no existir nunca, como categricamente lo afirm Fred Brooks y que contina siendo vlido 25 aos despus: No hay un solo desarrollo, en tecnologa o en tcnica de administracin [management], que por s misma prometa una mejora hasta de un orden de magnitud dentro de una dcada en la productividad, en la fiabilidad, en la simplicidad. [Respecto a la simplicidad en el diseo, ver la interesante propuesta de Maeda 2006] (Brooks, 1995, p. 179, traduccin libre). Por lo anterior, a veces se considera que los sistemas [de software] son sntomas de disfunciones organizacionales y que lo que hacen es conservar el desorden en vez de resolver los problemas (Lars Sdahl citado por Brooks, 1995, p. 211). En otras palabras, slo cuando se formalizan las reglas de operacin de un negocio se detectan las inconsistencias entre lo que debera ser y lo que es, que, en lo cotidiano, los empleados resuelven consciente o inconscientemente, y que quizs, sea la mayor fuente de innovacin y ventaja competitiva de las empresas. Esa dinmica relatada con anterioridad es la que intenta resolver la ingeniera de software que como puede apreciarse, prcticamente nada tiene que ver con aspectos tcnicos, o mejor dicho, estos estn embebidos en la dinmica organizacional. Por otro lado, indudablemente, el software se ha convertido en una mercanca, un producto y un servicio que hoy en da lo podemos encontrar embebido en prcticamente cualquier componente electrnico, desde un juguete hasta un avin, desde la casa y la escuela hasta en los negocios y en el gobierno. El software mueve datos entre dispositivos

Introduccin

electrnicos cercanos o a distancia. Con el incremento en la importancia del software y su uso en prcticamente todas las reas de conocimiento, desde las ciencias naturales, las matemticas hasta las ciencias sociales y el arte, el proceso de produccin del software, denominado desarrollo de software, se ha vuelto ms complicado. El software en su definicin tcnica son los programas de computadora, los procedimientos y posiblemente la documentacin asociada y los datos que pertenecen a la operacin de un sistema de cmputo (computer system). (IEEE, 1990, p. 66) est restringida exclusivamente a los aspectos tangibles, tales como el conjunto de instrucciones, la documentacin, los programas, los procedimientos y las reglas, es decir, lo que no es hardware. Esa definicin tcnica slo es vlida, para la operacin de sistemas y en parte para su desarrollo pero no ayuda mucho a comprender la complejidad de los sistemas de informacin embebidos en un entorno organizacional, ni de los aspectos del proceso de desarrollo distintos a la programacin, ni mucho menos, da cuenta de los complejos aspectos de administracin involucrados en su produccin. En este sentido, el software es una palabra polismica, es decir, con muchos significados. Respecto a la ingeniera de software es posible encontrar tantas definiciones como autores se han atrevido a acotarla. Barry Boehm, un autor clsico en el tema en 2006 segua sosteniendo su definicin esbozada en los aos 1970s. A ms de 40 aos de haberse propuesto como disciplina y como rea de conocimiento, la definicin oficial, que a partir de este momento identificaremos como la definicin clsica de la ingeniera de software, sigue siendo esencialmente la misma con dos acepciones: (1) la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software; eso es, la aplicacin de la ingeniera al software (Abran, Bourque, Dupuis, Moore, & Tripp, 2004, p. 1-1), es decir, la prctica o la

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

profesin y (2) el estudio de los enfoques en (1) (dem), es decir, la teora, la disciplina o la ciencia, si es que somos ms atrevidos. Esta definicin y sus tantas variaciones estn orientadas hacia dos aspectos: primero, hacia la aplicacin de los principios de ingeniera nunca identificados explcitamente, dando por hecho que tales principios son ampliamente conocidos, lo cual es falso, y segundo, que es una disciplina donde sus principios bsicos son un enfoque sistemtico, disciplinado y cuantificable que en el fondo significa orden, control, ser predecible, lo cual tampoco es completamente cierto. Por otro lado, los cientficos en computacin consideran a la ingeniera de software, una subdisciplina o un campo de las ciencias de la computacin y los ingenieros de distintas disciplinas que por dedicarse profesionalmente a desarrollar software se consideran a s mismos como ingenieros en software, la consideran una disciplina equiparable a las ciencias de la computacin o incluso una disciplina superior. En prcticamente todos los libros de texto los autores acotan que la ingeniera de software es otro tipo de ingeniera pero siguen sosteniendo como sus atributos caractersticos ese enfoque sistemtico, disciplinado y cuantificable a pesar de que en la prctica profesional esas caractersticas brillan por su ausencia, adems de que no hay ni siquiera una ligera crtica al respecto. En complemento, cuando en esos libros de texto se intentan abordar los fundamentos o principios cientficos subyacentes se deriva en la concepcin del proyecto y las tcnicas para realizar cada una de las fases, algunos, como Wang *(2008), con una elegancia matemtica que sorprende la construccin lgica de principios y corolarios, otros simplemente son principios enunciativos como en la Guide to Software Engineering Body of Knowledge (SWEBoK) (Gua del Cuerpo de Conocimientos de la Ingeniera de Software) (http://www.swebok.org).

Introduccin

La cosa se complica un poco ms cuando el panorama se amplifica. Tal pareciera que hay dos teoras, cualquier cosa que esto sea: una para el software propietario y comercial, producido por grandes equipos de desarrollo de software que emplean las herramientas, la tecnologa y la administracin de proyectos ms avanzada, que forman una industria liderada por las grandes empresas; y otra teora para el software libre (Free Libre Open Source Software (FLOSS) o Free Open Source Software (FOSS), que yo prefiero denominar FLOSS) producido por hackers o expertos en software, voluntarios e irreverentes en una organizacin anrquica sobre Internet, motivados por un ego insaciable y que les gusta regalar su trabajo. Tal pareciera que entre estos dos extremos ideales estn los proyectos de software desarrollados por las pequeas y medianas, que son la mayora de las empresas y que no pueden aplicar toda la tecnologa, ni toda la administracin tan rigurosa que recomiendan los estndares y que no les queda otra alternativa que conformarse con los proyectos de segunda o tercera categora o trabajar para las grandes empresas como simples maquiladores de software. Para estas pequeas y medianas empresas tambin se ha desarrollado una teora, por ejemplo, la expuesta en Oktaba y Piattini (2008). Como consecuencia, se percibe una confusin sobre todo si entendemos por teora los principios prescriptivos consignados en las llamadas best practices (mejores prcticas) en libros, manuales y guas. Para completar el cuadro anterior, las ciencias de la computacin han invadido a las otras ciencias, desde las matemticas, las ciencias naturales (fsicas, qumicas y biolgicas) y todas las ingenieras, hasta las ciencias sociales como la psicologa, la sociologa y la administracin, pero tambin las artes y las humanidades; a tantas disciplinas como aplicaciones de la computadora ha habido, ante lo cual se ha dado un collage disciplinario y una interdisciplinariedad. Sin embargo, no hay, ni siquiera, una breva gua que

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

indique cmo tejer tal interdisciplinariedad, lo que en mi opinin, es un problema ontolgico, epistemolgico y metodolgico fundamental. Como puede verse en esta breve discusin, la falta de la identificacin de los principios fundacionales de la ingeniera de software (su ontologa, epistemologa y metodologa), es decir, su filosofa, tiene muchas implicaciones para s misma, para las ciencias de la computacin y para la prctica porque abrira el campo a nuevas ideas en todos los planos y quizs, adquirira mayor capacidad predictiva.
2. La investigacin
2.1. Pertinencia

En primer lugar, hay que considerar que hay una marcada inconsistencia entre la supuesta teora de la ingeniera de software y su prctica profesional sin una explicacin pertinente. En segundo lugar, hay una aparente estabilidad discursiva con una mnima crtica al interior de la disciplina y sin cuestionar la posibilidad de que estn equivocados sus fundamentos. En tercer lugar, la ingeniera de software sufre una crisis disciplinaria (Zavala-Ruiz, 2008, p. 18), aunque no se ha reconocido abiertamente. En cuarto lugar, la ingeniera de software surgi en un contexto histrico especfico que la ha dotado de una caracterstica sui generis: pretender ser una disciplina tcnica, pero tambin administrativa (Mahoney, 1998, p. 120), similar a la ingeniera industrial, sin lograrlo an. En quinto lugar, las aspiraciones de la ingeniera de software, de descubrir las leyes que gobiernan la produccin de software, la han llevado a establecerse

Introduccin

como un oxmoron2 (oxymoron en ingls), es decir, una frase contradictoria que ha llevado a proponer a algunos autores, la hiptesis de que la ingeniera de software no es ingeniera (Ludewig, 1996, p. 1), sino de otra naturaleza. En sexto lugar, sorprendentemente, la investigacin cientfica crtica especfica sobre la ingeniera de software como disciplina es escasa. Es decir, ni la disciplina misma, ni las ciencias de la computacin hacen ese tipo de investigacin, ms bien son las ciencias sociales las que la estn haciendo, o bien, cuando la hay es investigacin de aplicacin y se centra sobre tcnicas, mtodos, estrategias, recetas y artefactos, con la pretensin de mejorar el proceso de desarrollo de software, no sobre sus fundamentos. En sptimo lugar, a la ingeniera de software se le considera una disciplina muy joven o algo inmadura a pesar de las innovaciones y a ello se le atribuye su incapacidad de establecer principios fundacionales. Sin embargo, tal parece que lo que ocurre es que, de manera deliberada, se evaden como ocurri con la redaccin de SWEBoK (Abran et al., 2004), una gua de las prcticas consensuadas, que se supone, se aplican, o mejor dicho, se debieran aplicar en la industria. La SWEBoK es tambin un intento por definir los principios de la

Oxmoron (Del griego ). Combinacin en una misma estructura sintctica de dos palabras o expresiones de significado opuesto, que originan un nuevo sentido; por ejemplo, un silencio atronador. (Diccionario de la Real Academia de la Lengua Espaola). http://buscon.rae.es/draeI/SrvltGUIBusUsual?LEMA=ox%C3%ADmoron Oxymoron. A rhetorical figure in which incongruous or contradictory terms are combined, as in a deafening silence and a mournful optimist; rhetoric an epigrammatic effect, by which contradictory terms are used in conjunction: living death fiend angelical. From Greek oxumron, from neuter of oxumros, pointedly foolish: oxus, sharp; see oxygen + mros, foolish, dull; Via New Latin from Greek oxumron, from oxus sharp + mros stupid. (Una figura retrica en la cual se combinan trminos incongruentes o contradictorios, como en silencio ensordecedor y un optimista triste; retrica un efecto epigramtico, por el cual los trminos contradictorios son utilizados en conjuncin: muerte angelical del demonio vivo. Del griego oxumron, del neutro de oxumros, acentuadamente absurdo: oxus, sostenido; ver oxgeno + mros, absurdo, opaco; Va nuevo latn del griego oxumron, de oxus sostenido + mros estpido.) http://www.thefreedictionary.com/oxymoron (traduccin libre)

10

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

disciplina que contina en la lnea del pensamiento clsico de la ingeniera de software. En esta hegemona de pensamiento sorprende que, slo algunos autores de la corriente alterna de la Empirical Software Engineering (Ingeniera de Software Emprica) en los pases escandinavos, se han atrevido a proponer nuevas tcnicas de investigacin hacia la recoleccin de datos para que en un horizonte de 10 o 15 aos se generen los datos que permitan soportar nuevos horizontes tericos (Shull, Singer y Sjberg, 2008). En octavo lugar, despus de la SWEBoK, la ltima propuesta mundial, surgida en 2010, preocupada por establecer los principios de la ingeniera de software es la iniciativa llamada Software Engineering Method And Theory (SEMAT) (http://www.semat.org), un proyecto liderado por Ivar Jacobson (el padre del Rational Unified Process, RUP), Bertrand Meyer (el creador del lenguaje de programacin Eiffel) y Richard Soley (Ejecutivo del Object Management Group, OMG) y que esencialmente coincide con lo ya apuntado y agrega la divergencia metodolgica y el predominio de las modas en la disciplina: La ingeniera de software hoy est gravemente obstaculizada por prcticas inmaduras. Los problemas especficos incluyen: (a). El predominio de las modas ms tpicas de industria de la moda que en una disciplina de la ingeniera; (b). La carencia de una sonada y extensamente base terica aceptada; (c). El gran nmero de mtodos y de variantes de mtodos, con pocas diferencias entendidas y magnificadas artificialmente. (d). La carencia de una evaluacin y validacin experimental creble; y (e). La separacin entre la prctica industrial y la investigacin acadmica. Nosotros apoyamos un proceso para refundar la ingeniera de software basada en una teora slida, unos principios probados y en mejores prcticas que: (a) Incluyan un kernel o ncleo de elementos ampliamente-convenidos, extensible para aplicaciones especficas; (b). Aborden tanto los problemas de la tecnologa como de la gente; (c) Sean apoyados por la industria, la academia, los investigadores y los usuarios; y (d). Apoyen la extensin frente a los requerimientos y la tecnologa cambiantes. (Jacobson, Meyer y Soley, 2010, p. 1, traduccin libre, nfasis agregado).

Introduccin

11

Como puede apreciarse, la SEMAT hizo un llamado a refundar la ingeniera de software basada en una teora slida, unos principios probados y en mejores prcticas, algo que no est probado empricamente. En mi opinin, esta iniciativa cometi el mismo error que todas las que la han antecedido: no establecer la naturaleza de su objeto de estudio, por lo que quizs, los avances no sean muchos. Ms delante discutir los puntos a favor y en contra de esta iniciativa. As que es claro que el problema de definir los fundamentos de la ingeniera de software no est resuelto, de ah su principal pertinencia. Por todo lo anterior, consider pertinente estudiar la ingeniera de software desde una perspectiva interdisciplinaria orientando mi investigacin hacia intentar establecer explcitamente los conceptos bsicos que son su esencia.
2.2. Relevancia

La investigacin o por lo menos la publicacin de libros y artculos relacionados sobre computacin e ingeniera de software, en general, tienen un gran auge. La computacin ha invadido otras esferas del conocimiento modificndolas y creando nuevas disciplinas computacionales como la bioinformtica. Por otro lado, la ingeniera de software ha alcanzado un nivel razonable de institucionalizacin pues hay suficientes investigadores acadmicos involucrados en el tema en las escuelas de ingeniera, de administracin, de negocios y de computacin en muchas universidades, hay grupos de investigacin y redes acadmicas sobre el tema, hay instituciones educativas que otorgan grados acadmicos tanto a nivel licenciatura como de posgrado en las facultades y escuelas de ingeniera y de computacin y hay revistas de investigacin acadmica, terica y prctica, con ms de 50 aos de historia disponibles en bibliotecas digitales. Adems, hay por lo menos una conferencia especializada sobre el tema y varios eventos y conferencias internacionales, prcticamente en todos los pases del mundo. Tambin, hay asociaciones profesionales que han contribuido a su desarrollo, principalmente

12

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

la Association for Computing Machinery (ACM) y el Institute of Electrical and Electronics Engineers (IEEE) con sede en los Estados Unidos pero con alcance global. Estas dos asociaciones mundiales se disputan el liderazgo de un mercado con tasas explosivas de crecimiento. La ACM impuls la adopcin de un cdigo de tica y la IEEE la certificacin como medios de regulacin profesional. En Mxico, se presenta una situacin similar aunque con dimensiones ms modestas. En resumen, en mi opinin, esta investigacin tiene relevancia por lo menos en tres sentidos: 1. Para la academia ante la escasa investigacin epistemolgica al respecto a nivel mundial, y nula en Mxico, lo que permitira, por lo menos, abrir el tema a una mayor discusin, sobretodo con las nuevas generaciones. 2. Para la economa dado que pequea industria de software en Mxico es la nica que crece a tasas superiores a dos dgitos comparada con el resto de la economa. Adems, las empresas de esta industria dependen de personal altamente calificado que requiere de mejores herramientas conceptuales, adems de capacitacin tcnica. Tambin, en Mxico, existe una poltica pblica gubernamental desde el 2002 mediante el Programa de Desarrollo de la Industria de Software (ProSoft) en Mxico, con fondos pblicos que apoya al sector y que, tan solo en 2010, invirti varios cientos de millones de pesos. Ante esto, la investigacin resulta ms relevante. 3. Para la prctica ya que el problema de la ingeniera de software an no est solucionado y sigue habiendo proyectos fracasados, en el gobierno, la industria y el comercio y esta investigacin puede tener implicaciones en ese sentido al aportar otras visiones poco consideradas hasta ahora.

Introduccin 2.3. Objetivos

13

De la observacin y reflexin anterior y dada la carencia de investigaciones empricas que den cuenta de esta problemtica, me propuse desarrollar un proyecto de investigacin que explorara las bases ontolgicas y epistemolgicas del software orientadas hacia la problemtica de los proyectos de software al establecer los siguientes objetivos: 1. Explorar las concepciones fundamentales sobre el software y establecer una propuesta bsica de ontologa cuya esencia est en las ciencias de la computacin. 2. Proponer una epistemologa de tal forma permita expandir los horizontes de los aspectos tcnicos de la ingeniera de software como disciplina. 3. Abrir una discusin epistemolgica desde la perspectiva interdisciplinaria de tal forma que permita expandir y aprovechar el marco de referencia creado en las ciencias de la computacin. 4. Explorar las implicaciones que tiene proponer un cambio en los aspectos fundamentales de la disciplina. Posiblemente estos objetivos fueron demasiado pretenciosos, sin embargo, considero que se han cumplido de manera satisfactoria. Ante la carencia de una compilacin de fuentes bibliogrficas, las referencias citadas permitirn abundar sobre el tema y junto con este trabajo posibilitarn el avance hacia la construccin social de una ontologa y una epistemologa del software que finalmente resulte aplicable a la prctica industrial y contribuya a la sustentabilidad del sector en la industria, la academia y sobre todo para los profesionales del software. Este trabajo est dirigido a los acadmicos, a los trabajadores de la industria del software y a los administradores de proyectos de software y puede resultar interesante para los tericos de las ciencias de la computacin y de la teora de

14

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

la organizacin. Quizs, tambin resulte interesante para los investigadores de la ciencia y la tecnologa y de la administracin, que en Mxico no han abordado este tipo de tecnologa. Para los profesionales del software puede resultar interesante y til, el repaso crtico de los fundamentos, la ontologa de la disciplina y la concepcin de la triada hardware, software, orgware y la concepcin del iceberg organizacional para mejorar el desarrollo e implantacin del software empresarial. La perspectiva semitica tambin puede ser de utilidad prctica para usuarios y analistas de requerimientos. Como complemento de este trabajo, estar la publicacin de mi tesis de doctorado a finales de 2011 que aborda la dinmica de los proyectos de software bajo outsourcing desde la perspectiva de la administracin en una visin crtica. Aclaro que la mayora de las ideas contenidas en el documento son de sus respectivos autores en los que he decidido apoyarme y que he referido con la mayor precisin posible. Agradezco las atinadas observaciones de mi asesora la M. en C. Rafaela Blanca Silva Lpez y mis lectores, la Dra. Silvia Beatriz Gonzlez Brambila y el M. en C. Hugo Pablo Leyva de la Universidad Autnoma Metropolitana, Unidad Azcapotzalco y de la Dra. Hanna Oktaba, de la Facultad de Ciencias de la Universidad Nacional Autnoma de Mxico (UNAM) y del Dr. Guillermo Levine que no pudo fungir como sinodal. La interpretacin de estas ideas, los errores y las omisiones son de mi exclusiva responsabilidad.
3. Estructura del documento

Este documento est estructurado como un conjunto de ensayos relativamente independientes y un captulo de reflexiones finales. En el primer captulo se aborda la metodologa de esta investigacin que se bas en la abduccin y el construccionismo social como epistemologas y el pluralismo epistemolgico y la transdisciplinariedad como posturas epistemolgicas complementarias.

Introduccin

15

En el segundo captulo se abordan las ciencias de la computacin como fenmeno cientfico-tcnico consecuente del invento de la computadora electrnica en los aos 1940s. Se hace un recorrido histrico que muestra cules fueron las fuerzas polticas y econmicas que estuvieron detrs de la nueva tecnologa, el invento ms revolucionario del siglo XX. Adems, se muestran las implicaciones ocupacionales y el surgimiento de los computer boys, imprescindibles hasta la fecha. Se ilustran las razones del surgimiento de la ingeniera de software como una nueva disciplina en competencia con las ciencias de la computacin y se cierra con una visin actual. En el tercer captulo se aborda la ingeniera de software como un movimiento poltico-cientfico-ocupacional-gerencial. Se identifican sus orgenes y sus caractersticas tcnico-gerenciales, con amplias implicaciones. Se ilustra el proceso de institucionalizacin que ha llevado a la disciplina a intentar erigirse como una disciplina con mritos propios, sin embargo, no reconoce que depende de los fundamentos custodiados por las ciencias de la computacin. Se hace una descripcin de su dimensin gerencial y sus implicaciones. En el cuarto captulo, primero, se desarrolla una ontologa fundamental bsica del software, al caracterizar la esencia del cmputo y el software y su desarrollo, que permite comprender cul es su esencia y sus implicaciones prcticas cuando se desarrolla software empresarial. Luego se desarrolla una epistemologa bsica que pretende abordar el corazn del desarrollo de software en un enfoque interdisciplinario. Al final se expone la perspectiva semitica del software y sus implicaciones prcticas. En el quinto captulo se desarrolla la discusin que aborda la racionalidad tradicional y sus limitaciones y aciertos, luego trata la dimensin gerencial y sus implicaciones y despus encuadra el desafo epistemolgico de la disciplina, su crisis y la necesidad de un cambio paradigmtico, por lo que se expone un

16

La ingeniera de software: Una discusin epistemolgica

Jess Zavala

esquema conceptual para lograrlo y el sexto captulo cierra con las conclusiones o reflexiones finales. Un ltimo punto, no menos importante que necesita aclaracin, es el estilo de redaccin que combina la utilizacin de la tercera persona de singular (impersonal) con la primera, para destacar, explcitamente cules son las afirmaciones de mi propia autora. Tipogrficamente utilic el estilo de citado y referencias de la American Psychological Association (APA) debido a que permite identificar con precisin las numerosas citas bibliogrficas para que al lector se le facilite su localizacin posterior. Utilic comillas () para citas textuales de palabras y frases relevantes que identifican el lenguaje utilizado y cuando la cita fue muy grande, la reemplac por una tipografa con sangra izquierda, con la referencia al final y para destacar la importancia o hacer nfasis utilic cursivas. Mis observaciones, opiniones y posicionamiento personal las escrib utilizando una redaccin en tiempo presente para distinguirlas de las citas.