Universidad Autnoma Metropolitana Unidad Azcapotzalco

Divisin de Ciencias Bsicas e Ingeniera

La Ingeniera de Software: Una Discusin Epistemolgica

T E S I S

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 en Ciencias de la

Computacion:

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., 2 0 de Julio 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

xiii

(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.

xv

(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

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

xvii

(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

xix

(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,

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.

1

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.

2 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 3

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).

4 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 5

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

6 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 7

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

8 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 9

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

2 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 13

2.3. Objetivos

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.