editorial - sitio web dcc · alejandro hevia entrevista a nuestro exa- ... la saga del profesor...

1

Editorial

Alejandro Hevia entrevista a nuestro exa-lumno Roberto Opazo sobre cómo fue suexperiencia en nuestro Departamento y losorígenes de su capacidad de innovaciónen diferentes empresas.Finalmente, nuestro exalumno de Doctora-do Alcides Quispe nos presenta un Surveysobre buenas prácticas de desarrollo desoftware para pequeñas empresas.

Esperamos que disfruten la Revista. Como siem-pre quedamos a disposición de sus consultasy comentarios a través de nuestro [email protected]

PABLOBARCELÓEditor GeneralRevista Bits de Ciencia

Esta vez tenemos una gran razón para celebrar:nuestro Departamento - el Departamento deCiencias de la Computación de la Universidadde Chile - ha cumplido 40 años. Lo que comenzóen 1975 como la apuesta liderada por un grupode jóvenes para instalar a la Computación comouna nueva área de la Ciencia y la Ingeniería, hadado paso hoy en día a un Departamento depunta a nivel latinoamericano en docencia, trans-ferencia e investigación. Orgullosos como esta-mos de esta historia, comenzamos esta nuevaedición de la "Bits de Ciencia" con textos y fotosextraídas de la celebración de estos 40 años, laque se realizó en diciembre de 2015 con presen-cia de autoridades, académicos, funcionarios, yexalumnos, entre otros.

Por otro lado, el tema principal de la Bits en estaocasión es la industria del software y TIC en Chile.Hemos congregado a varios expertos de la aca-demia y la industria para que hablen del tema,en algunos casos aportándonos con su visiónsobre ésta y en otros relatándonos el trabajoque han realizado para que esta industria crezcay aumente aún más en calidad. Parece ser untema común a todos estos artículos el hechoque la industria chilena de software y TIC tieneun buen nivel y potencial para desarrollarse, enparticular producto de la calidad de sus profe-sionales. Por otra parte, el tamaño de tal industriaes pequeño, y parece necesario desarrollar polí-ticas de gran escala que la impulsen a convertirseen real motor de desarrollo para Chile.

La sección dedicada a la industria nacional delsoftware y TIC incluye lo siguiente:

Un artículo de José Miguel Piquer que res-ponde a las preguntas de si esta industriarealmente existe y por qué no se ha desa-rrollado plenamente.Una radiografía a la industria del softwarenacional y sus desafíos, realizada por MaríaEugenia Riquelme de GECHS.Un artículo de varios académicos y alumnosde postgrado de nuestro Departamento(proyecto GEMS) analizando los desafíos yoportunidades que esta industria tienepara generar impacto país.Un artículo de Pablo García, de TelefónicaI+D, contándonos los esfuerzos que estánrealizando para desarrollar transferencia através de la combinación TIC/data science.Una reseña de Erika Madariaga sobre SPIN-Chile, la red nacional de mejoramiento delproceso de software.Por último, una breve descripción de algu-nos postítulos en el área que se impartenen nuestro país.

Tenemos además nuestras secciones tradiciona-les:

En Investigación Destacada, el académicoGonzalo Navarro nos habla sobre su inves-tigación en Big Data y repetitividad.En Computación y Sociedad seguimos conla saga del Profesor Juan Álvarez sobre laHistoria de la Computación en Chile. Eneste caso su artículo trata de los primerosaños de ECOM, la Empresa Nacional deComputación fundada en 1970.En la sección Conversaciones, el académico

2

Especial Aniversario40 años DCC

En una emotiva ceremonia que congregó a egresados, estudiantes,académicos y funcionarios, el Departamento de Ciencias de laComputación (DCC) de la FCFM celebró cuarenta años de historia.

3


En 1975 un grupo de jóvenes y entusiastas inge-nieros creó el Departamento de Ciencias de laComputación (DCC), como una iniciativa quebuscaba explorar esta nueva área del conoci-miento y abrir oportunidades para el uso detecnologías digitales en el país. Cuarenta añoshan transcurrido desde entonces, en los que elDCC ha recorrido un largo camino que fue recor-dado el 11 de diciembre de 2015 en una ceremo-nia que contó con la presencia de los fundadoresdel DCC: Fernando Silva, Alfredo Piquer, JoséPino y Patricio Poblete, así como de las autorida-des de la FCFM, académicos, funcionarios, alum-nos y egresados del Departamento.

Previo a esta ceremonia, y como parte de la ce-lebración, se realizaron diversas actividades. Laprimera actividad fue un “Puertas Abiertas” quebuscó mostrar la carrera de Ingeniería Civil enComputación. Allí los profesores José MiguelPiquer y Nancy Hitschfeld realizaron charlas sobrelas tecnologías que revolucionan la humanidad,y sobre cómo la Computación puede ser un cam-po laboral atractivo para mujeres. Luego el Pro-fesor Ricardo Baeza Yates, académico DCC y ChiefResearch Scientist Yahoo! Labs, dictó la charla“Big Data en la Web”. También se realizaron visitasguiadas a las instalaciones del Departamentodonde, entre otras actividades, los asistentespudieron ver el trabajo que se realiza en el áreade robótica y conocer el Museo DCC.

Durante la ceremonia oficial de aniversario, elDirector del DCC, Prof. Sergio Ochoa resaltó di-ferentes hitos del Departamento, como la crea-ción de programas de pre y postgrado, el envíodel primer mail, la primera conexión a Internetdel país y la creación de NIC Chile. Asimismo,destacó la participación en iniciativas guberna-mentales y otras de impacto país, el trabajo deinvestigación de punta que se ha realizado enlas últimas dos décadas, que le han dado visibili-dad internacional al DCC y el hecho que en 2015,el ranking QS posicionó al Departamento en eltercer lugar, entre los departamentos de Compu-tación de Latinoamérica, detrás de las universi-dades de Sao Paulo y Campinas de Brasil.

“Hoy tenemos un DCC un poco distinto a aquelque creó aquel grupo de ingeniosos ingenierospor allá por 1975 y que hoy le rendimos home-naje. Aquellos que tomamos la posta seguimoscompartiendo los mismos valores y poniéndole

el mismo empeño para que nuestra casa sea cadadía mejor, más inclusiva, solidaria y preocupadade los problemas de Chile y de su gente”, señalóel Prof. Ochoa.

También tomó la palabra el fundador y primerDirector del DCC Fernando Silva, quien ademásde recordar los inicios del Departamento, expresósu orgullo por la evolución del DCC: “Trabajé enla Facultad por 16 años. Tuve el privilegio detrabajar con jóvenes con gran capacidad y verlosimpartir sus conocimientos con una generosidadsin límites. Al cumplir 40 años el Departamento,nos llena de orgullo ver que ha llegado a ser unode los más reconocidos de Latinoamérica”.

A continuación, los profesores José Miguel Piquery Patricio Poblete, pioneros del desarrollo deInternet en Chile, recordaron los años inicialesdel DCC. El profesor Piquer afirmó que “de esteDepartamento ha salido una enorme cantidadde generaciones y de gente que hoy está hacien-do la Computación de este país. Comparto conustedes la nostalgia y emoción de reencon-trarnos”.

Por su parte, la egresada Marcela Calderón afirmóque ser ingeniera del DCC “es una marca. Másallá del conocimiento y habilidades técnicas des-taca el genuino interés por saber más por resol-verlo todo y por aprender”. Agregó que hoy “elDCC enfrenta grandes desafíos y oportunidades.El primero es el de mantener esta marca. Perotambién sería positivo contar con más mujeresen este campo. Atraer más mujeres es una tareaposible y demostrar que ésta es no sólo unacarrera para hombres”.

Tras estas intervenciones, se realizó un reconoci-miento a los fundadores del Departamento: Fer-nando Silva, Alfredo Piquer, José Pino y PatricioPoblete; a los profesores José Miguel Piquer,Ricardo Baeza Yates, Jorge Olivos y a quien fuerapor largo tiempo jefa administrativa, MargaritaSerei, todos como artífices del desarrollo del DCC.También se reconoció al primer egresado de cadaprograma: Ronald Corovic (Ingeniería Civil enComputación), José Benguria (Magíster en Cien-cias mención Computación), José Miguel Rodrigo(Magíster en TI), Gonzalo Navarro (Doctorado enCiencias mención Computación) y RigobertoMolina (Ingeniería en Ejecución en Procesamientode la Información).

4

5

1 2 3

4

6 7

98

1. El Director del DCC, Prof. Sergio Ochoa. 2. Fernando Silva, fundador y primer Director del DCC. 3. El Decano de la FCFM, Prof. Patricio Aceituno. 4. Los profesores José Miguel Piquer y Patricio Poblete, recordaron los años iniciales del DCC. 5. Marcela Calderón, profesora y egresada del DCC. 6. Margarita Serei, Jefa Administrativa del DCC hasta 2011, recibió el reconocimiento “Artífices del Desarrollo del DCC”, de manos del Director delDCC, Prof. Sergio Ochoa. 7. De izquierda a derecha, los profesores José Miguel Piquer y Ricardo Baeza-Yates, recibieron el reconocimiento “Artíficesdel Desarrollo del DCC”, de manos del Director del DCC, Prof. Sergio Ochoa. 8. Los fundadores del DCC. De izquierda a derecha: Fernando Silva, JoséPino, Alfredo Piquer y Patricio Poblete. 9. Entrega de reconocimiento a los primeros graduados de nuestros programas de estudio. De izquierda aderecha: Ronald Corovic (Ingeniería Civil en Computación), el Director del DCC, Prof. Sergio Ochoa, José Benguria (Magíster en Ciencias menciónComputación), José Miguel Rodrigo (Magíster en TI) y Gonzalo Navarro (Doctorado en Ciencias mención Computación).


Cerró la ceremonia el Decano de la FCFM, Prof.Patricio Aceituno, quien reconoció la innovaciónque hubo de parte de los fundadores del DCC,al vislumbrar la Computación como un área adesarrollar. “Cuando miro 40 años atrás y el re-

nacer del DCC, qué era eso sino innovación. Ypara hacerla requiere: dedicación, pasión y mu-cho esfuerzo. La Universidad de Chile y la Facul-tad deben reconocer que si este país tiene lacapacidad que tiene en Computación e Infor-

mática es por esa pasión, dedicación y esfuerzoque puso un grupo de pioneros que llevó ladisciplina al nivel que está en Chile”, concluyó lamáxima autoridad.

5

EN UN EMOTIVO ENCUENTRO GENERACIONAL, EL ANIVERSARIO DELDCC REUNIÓ A SUS ACADÉMICOS, ALUMNOS, EGRESADOS Y FUN-CIONARIOS.


6


7


8*Financiado por el Proyecto Fondecyt 1-140796

Uno de los aspectos que mejor caracteriza nuestro desarrollo tecno-lógico en las últimas décadas es el rápido crecimiento de los datosdisponibles digitalmente. En pocos años, hemos pasado de es tarpreocupados por la cantidad de cómputo que debíamos realizar apreocuparnos más bien por el volumen de datos que debemosprocesar, incluso cuando los cálculos son relativamente simples .

9

GONZALONAVARROProfesor Titular Departamento de Ciencias de laComputación, Universidad de Chile. Doctor en Cienciasmención Computación y Magíster en Ciencias menciónComputación, Universidad de Chile; Licenciatura enInformática, Universidad Nacional de La Plata y ESLAI,Argentina. Líneas de investigación: Diseño y Análisis deAlgoritmos, Bases de Datos Textuales, Búsqueda porSimilitud, Compresió[email protected]

EL DILUVIO DE DATOSTenemos por un lado los datos que podríamosllamar “científicos”: los datos astronómicos, don-de Chile es una fuente generadora predilecta;datos de clima obtenidos por sensores de todotipo, que en varios casos deben ser usados entiempo real para ser útiles; datos geográficos,incorporados a la vida diaria gracias a los satélitese intermediarios como Google Maps; secuenciasbiológicas, cada vez más baratas de obtener ypor ello más abundantes; etc.

Tenemos también datos que podríamos llamar“contenidos”: grabaciones de voz, imágenes,fotos, música, vídeos, libros, revistas, páginasweb, emails, blogs, tweets, y un largo etcétera,todos ellos incorporando la necesidad de encon-trar el contenido deseado en formatos no siem-pre amigables para el procesamiento automáti-co.

En una tercera categoría, que podríamos llamar“comportamiento”, tenemos evolución de mer-cados, de compras online, tráfico en redes, clicksde usuarios, patrones de navegación en la Web,búsquedas en la Web, “likes” en Facebook, diná-mica de redes sociales, etc. Estos datos se anali-zan permanentemente para predecir el compor-tamiento económico, mejorar máquinas debúsqueda, ofrecer mejores interfaces, estudiarcomportamientos sociales, etc.

Tal cantidad de datos genera inmensas posibili-dades de mejorar muchos aspectos de nuestravida, y ya lo han hecho en gran medida. Dudoque quienes nacieron en la era de los buscadorespuedan siquiera imaginar cómo era vivir cuandoesa fuente instantánea e inagotable de informa-ción no estaba disponible. Mucho más está porvenir también. Por ejemplo, la posibilidad dedescubrir efectos de medicamentos no porquealgún científico se ilumine y lo pruebe sino por-que surja automáticamente del análisis y corre-lación de miles de historias clínicas, la posibilidadde que el automóvil se conduzca solo a travésde una ciudad desconocida mediante interactuarcon dispositivos inteligentes de la ciudad quelo guíen con información extraída automática-mente de la Web, y muchos otros ejemplos quehace una década eran ciencia ficción hoy estána la vuelta de la esquina.

Con las grandes posibilidades vienen los grandesdesafíos. En cada una de las áreas mencionadas,hemos aprendido que es mucho más fácil gene-rar datos que darles un uso útil. La humanidadgenera unos cuantos zettabytes de datos al año,de acuerdo a un estudio de 2011 de la Interna-tional Data Corporation (un zettabyte son 2 70

bytes, aproximadamente 10 21), y el volumencrece a más del doble por año, más rápido quela Ley de Moore, que gobierna (en el mejor delos casos) el crecimiento de las capacidades dehardware. El libro “Algorithms and Data Structu-

10

res for External Memory” de Jeff Vitter comienzacon una sentencia que resume la situación: Theworld is drowning in data! El término data deluge,o la inundación en datos, se ha puesto de modapara indicar que tenemos muchos más datos delos que podemos manejar.

Por lo pronto, no parece que nuestras capacida-des de mero almacenamiento de datos esténaún comprometidas. Pero como decía, el proble-ma no es realmente almacenar los datos sinodarles algún uso. Incluso transmitirlos puede serun problema: la compañía BGI, que secuenciadatos en China, les envía a sus clientes las secuen-cias en una cinta por correo normal, ya que Inter-net no tiene el ancho de banda necesario paratransmitirlas más rápidamente. ¿Qué esperarentonces de nuestras capacidades de procesarestos datos para obtener información útil? Rea-lizar minería de textos o de datos en general paraencontrar patrones relevantes, recorrer grafospara detectar comunidades de interés, buscarsimilitudes en secuencias genómicas, etc. sonprocesos que requieren ejecutar sofisticadosalgoritmos que recorran los datos, una o variasveces, con patrones de recorrido impredecibles.¿Podemos realizar este procesamiento sobredatos almacenados en memoria secundaria (dis-cos, SSDs) o terciaria (cintas)?

Lamentablemente, no todos los componentesdel hardware mejoran según la Ley de Moore(que establece que la capacidad y/o la velocidadse duplica cada dos años aproximadamente). Lohace la capacidad de la memoria externa (secun-daria y terciaria), pero no su velocidad. Desdehace unos años, ya no lo hace la velocidad de losprocesadores, aunque a cambio lo ha empezadoa hacer la cantidad de procesadores en la CPU.La memoria interna (RAM) crece en capacidad,pero no mucho en velocidad, aunque aparecencada vez más y mayores memorias caché rápidasentre la CPU y la memoria RAM. La diferenciaentre procesar datos en memoria interna o ex-terna es cada vez mayor, lo que ha hecho atrac-tivo usar clusters de computadores para simularuna gran memoria RAM.

LA REPETITIVIDAD:NUESTRA TABLA DESALVACIÓNMuchas de las secuencias, fotos, series de tiem-po, etc. de las fuentes más prolíficas de datosson altamente repetitivas. Esto significa que esposible obtener cada nuevo elemento mediantecombinar unas pocas partes de elementos vistospreviamente. La repetitividad parece llamada aser nuestra tabla de salvación frente al diluviode datos. Un buen ejemplo son las coleccionesde genomas. Existen muchas especies distintas,pero tampoco tantas. Las grandes coleccionesde genomas se forman secuenciando muchosindividuos de la misma especie. Dos genomasde individuos de la misma especie difieren enun porcentaje muy bajo, cercano al 0.1%. Otroejemplo son los sistemas de versiones (de soft-ware, de documentos, etc.), con el casopúblicamente disponible de Wikipedia y la Inter-net Wayback Machine (que almacena copias depáginas web a través del tiempo). Otra son laspublicaciones de series de tiempo, financieras,climatológicas, etc., que en muchos casos tienenperiodicidad con pocas variaciones. Los datosastronómicos suelen incluir “fotos” de la mismazona del cielo en distintos momentos

Se conocen buenas técnicas para tratar condatos muy repetitivos. Los sistemas que manejanversionamiento en edición colaborativa, comoCVS, Subversion, y otros, almacenan solamentelas diferencias de versiones menores con respec-to a la versión anterior. Compresores genéricoscomo la familia Lempel-Ziv buscan, en el textoya visto, copias del nuevo texto que deben com-primir. Elementos de esta familia como p7zipfuncionan muy bien en colecciones altamenterepetitivas, donde los compresores clásicos fallanen aprovechar la repetitividad.

Pero nuevamente estamos hablando de alma-cenar los datos eficientemente, permitiendo a

lo sumo recrear una versión específica. Si quere-mos tratar estas grandes colecciones repetitivasen forma eficiente, debemos ser capaces de ope-rar sobre los datos directamente en forma compri-mida, sin necesidad de descomprimirlos previa-mente.

ESTRUCTURAS DEDATOS COMPACTASAquí entran en juego las estructuras de datoscompactas, que combinan compresión y teoríade la información con estructuras de datos, demodo de representar los datos usando espaciocercano a lo que usaría un compresor, pero aúnpermitiendo navegar, operar y buscar en losdatos sin descomprimirlos. En este aspecto vanmás allá de la compresión, que busca solamenterepresentar los datos en menos espacio de modode poder recuperarlos, y generalmente requieredescomprimirlos del todo antes de poder usarlos.

Las estructuras de datos compactas se han veni-do desarrollando cada vez con más fuerza desdefines de los ochenta, y hoy permiten representaruna amplia gama de estructuras en espacio re-ducido: árboles, grafos, textos, grillas de puntos,etc. Pueden llegar a usar, en la práctica, treintaveces menos espacio que la estructura clásicacorrespondiente, y si eso permite que los datosque normalmente se almacenarían en memoriaexterna quepan en RAM, entonces la gananciaen tiempo de procesamiento es de órdenes demagnitud, incluso cuando manejar las estructu-ras compactas requiera bastantes más operacio-nes que las clásicas. En el caso de una memoriaRAM distribuida en clusters, las estructuras com-pactas permiten reducir el número de computa-dores necesarios, su tiempo de comunicación, ysu costo de hardware y de energía.

El desarrollo de estructuras de datos compactasespecíficas para explotar la repetitividad de losdatos es bastante más reciente, y tiene todavíamucho terreno por explorar. Para ejemplificar el

InvestigaciónDestacada

11

FIGURA 2.ÁRBOL DE SUFIJOS PARA UNA COLECCIÓN DE VARIOS STRINGS SIMILARES.

FIGURA 1.ÁRBOL DE SUFIJOS PARA UN SOLO STRING. COMO LOSSTRINGS QUE LLEGAN A LAS HOJAS SON MUY LARGOS,ALMACENAMOS SÓLO SU PRIMERA LETRA.

tipo de problemas que enfrentamos al explotarla repetitividad, describiré el desarrollo de índicespara colecciones de texto repetitivas, uno de lostemas que se abordan en mi actual proyectoFondecyt. Lo haré maximizando la intuición através de ejemplos, evitando demostraciones oargumentos complejos.

COLECCIONESREPETITIVAS DETEXTOPara permitir búsquedas de diversa complejidaden colecciones de secuencias (por ejemplosecuencias de ADN), los índices favoritos son losárboles de sufijos, inventados en 1973 por PeterWeiner. Considere una colección formada portextos T1, T2, …, Td, sobre un alfabeto .Usaremos un símbolo extra, $, para terminar lostextos y los concatenaremos en un único textoT[1,n] = T1 $ T2 $ … Td $. Los árboles de sufijos seconstruyen sobre este texto concatenado T. Unsufijo de T es cualquier substring de T quetermina en un $. El trie de sufijos de T se obtieneinsertando todos sus sufijos en un árbol digital,de modo que cualquier sufijo T[i...] se puede leerrecorriendo el árbol desde la raíz hasta la hojaasociada al sufijo que empieza en la posición “i”y concatenando las letras que rotulan las aristas.

El árbol de sufijos se obtiene compactando loscaminos “unarios” (es decir, donde cada nodotiene un único hijo) en el trie de sufijos. Ahora

cada arista está rotulada con un string y losstrings que rotulan las aristas de cada nodo asus hijos difieren en su primera letra. Como tienen hojas y todo nodo interno tiene al menos doshijos, el árbol de sufijos tiene menos de 2n nodos.También se puede construir en tiempo lineal,O(n). La Figura 1 muestra un árbol de sufijospara un solo string.

Podríamos dedicar muchas páginas a mostrarlas virtudes y potencialidades del árbol de sufijos,pero nos contentaremos con un ejemplo simplee ilustrativo. Considere un problema de análisisde textos (para determinar autoría o plagio entextos de lenguaje natural, para buscar secuen-cias repetidas de ADN, etc.): encuentre el subs-tring más largo de T que aparece dos veces. Enun árbol de sufijos, esto corresponde simple-mente a recorrer los nodos y encontrar el nodointerno que representa el string más largo, locual puede hacerse fácilmente en tiempo lineal(en nuestro ejemplo, el resultado es “ATA”). Su-mado a que este árbol se puede construir entiempo lineal, tenemos que este problema sepuede resolver en tiempo O(n). Pues bien, antesde que existieran los árboles de sufijos, inclusoel legendario Donald Knuth creía que tal cosano era posible. Esto ilustra la facilidad con la queel árbol de sufijos permite resolver problemasmuy complejos.

Asimismo, podemos usar el árbol de sufijos parabuscar las ocurrencias de un nuevo patrón,P[1,m], en T. Simplemente hay que bajar por lasletras de P hasta que (1) no se pueda continuar,en cuyo caso P no aparece en T; (2) lleguemos

a una hoja, en cuyo caso hay que comparar elresto de P con esa posición del texto, para versi P aparece allí o no aparece; o (3) se nos acabenlas letras de P, en cuyo caso el nodo en queestamos, o donde nos lleva la arista en queestamos, corresponde a todas las ocurrenciasde P en T, una por hoja (y las posiciones dondeocurre P son los valores asociados a las hojas).En nuestro ejemplo, tenemos búsquedas detipo (1), (2) o (3) cuando buscamos “TT”, “CGA”,o “AT”, respectivamente. El árbol de sufijos rea-liza esta búsqueda en tiempo O(m), indepen-dientemente del largo del texto, lo que es nota-ble.

Esta poderosa herramienta tiene, sin embargo,un serio problema: ocupa mucho espacio. Enuna implementación típica, el árbol de sufijospuede ocupar 20n bytes. Si tenemos un genomahumano (unos 3 mil millones de bases), el árbolde sufijos requiere unos 60GB de memoria. Ade-más los recorridos en el árbol siguen caminosimpredecibles (no todos los problemas se re-suelven con recorridos top-down, por lo que elárbol debe mantenerse en memoria para quelos recorridos funcionen eficientemente). Si 60GB de RAM parece una exigencia considerable,piense en la razonable aspiración de manejaruna colección de 1000 genomas: ¡requeriría 60terabytes de RAM!

Sin embargo, la repetitividad es un poderosoaliado para reducir el espacio de los árboles desufijos de colecciones repetitivas. La Figura 2muestra una colección de varios stringssimilares.


12

FIGURA 3.ARREGLO DE SUFIJOS PARA NUESTRA COLECCION.

FIGURA 4.ARREGLO LCP PARA NUESTRA COLECCION.

Hemos mostrado, en celeste y amarillo, dos zo-nas del árbol que son topológicamente idénticas.La repetitividad en los textos induce zonas topoló-gicamente idénticas en el árbol de sufijos. Veremosluego cómo explotar esa repetitividad. Veamos,por lo pronto, lo que ocurre con las posicionesasociadas a las hojas del árbol, como se muestraen la Figura 3.

Las áreas del mismo color son iguales, exceptoque sus valores difieren en una unidad (estasáreas se traslapan, como puede verse). Nueva-mente, veremos luego cómo explotar este he-cho: La repetitividad en los textos induce largasáreas en las posiciones del árbol de sufijos cuyosvalores difieren en una unidad.

La primera representación compacta de árbolesde sufijos fue propuesta por Kunihiko Sadakaneen 2007. Consta de tres partes: la topología com-primida, la secuencia de posiciones (que se llamaarreglo de sufijos) y otro arreglo de prefijos co-munes más largos ( LCP, por longest commonprefix). Este arreglo indica el largo del prefijocomún que comparten dos hojas consecutivasdel árbol. Estos tres componentes son suficientespara simular todas las operaciones en un árbolde sufijos. Ni siquiera se necesita el texto. Inclusose puede extraer de la estructura cualquier subs-tring del texto que se desee, ¡por lo que el textopuede borrarse!

La Figura 4 muestra el arreglo LCP de nuestracolección. Como puede verse, persiste el mismotipo de repetitividad que en el arreglo de sufijos,a veces con excepción del primer elemento delas áreas. La repetitividad en los textos inducelargas áreas en el arreglo LCP cuyos valores difierenen una unidad.

El árbol de sufijos compacto de Sadakane obtie-ne un espacio cercano a unos 10 n bits para elcaso de ADN. Esto es 1,25 bytes por símbolo,muy inferior a los 20 de las implementacionesclásicas. Un genoma humano cabe en menos de4GB, que es muy razonable para una memoriaprincipal. Sin embargo, para nuestro razonableobjetivo de 1000 genomas, una memoria princi-pal de 4TB es todavía de muy alta gama. Mostra-remos cómo se ha logrado reducir este espacioa unos 2n bits para el caso de las coleccionesrepetitivas, con lo cual los 1000 genomas huma-nos cabrían en menos de 700GB.

ÁRBOLES DE SUFIJOSPARA COLECCIONESREPETITIVASMostraremos cómo aprovechamos la repetitivi-dad para obtener un árbol de sufijos tan pe-

queño. La idea es compactar cada uno de loscomponentes utilizando distintas herramientas.Una idea genérica que es útil es la compresiónbasada en gramáticas libres del contexto . Estasrepresentan una secuencia de símbolos comouna serie de reglas, donde un símbolo no terminalse reescribe como una secuencia de símbolosterminales (los de la secuencia) y otros no termi-nales. Los no terminales, a su vez, se reescribenusando las reglas, hasta que la secuencia contie-ne sólo símbolos terminales. Las secuencias re-petitivas pueden así representarse como la ca-dena que se deriva de un cierto símbolo noterminal, que se llama símbolo inicial, y la gramá-tica puede ser mucho menor que la secuencia.

Para ilustrar esta idea, apliquémosla a la versióndiferencial de nuestro arreglo de sufijos. En laversión diferencial, cada elemento se escribecomo la diferencia con el anterior. Esto hace quelas zonas largas que se repetían en otra partecon una diferencia de una unidad, ahora se con-vierten en zonas idénticas.

Nuestro arreglo de sufijos diferencial se ve asítal como se muestra en la Figura 5.

Como se puede ver, las repeticiones se han con-servado (excepto por los primeros símbolos).Gracias a estas repeticiones, el arreglo se puederepresentar con una gramática bastante más

FIGURA 6.REPRESENTACIÓN CON PARÉNTESIS DE LA TOPOLOGÍA DE NUESTRO ÁRBOL DE SUFIJOS.

FIGURA 5.ARREGLO DE SUFIJOS DIFERENCIAL PARA NUESTRA COLECCIÓN.


713

tro árbol de sufijos sobre la colección repetitivaes lo que se muestra en la Figura 6.

Como puede verse, los subárboles idénticos setraducen en substringsidénticos en la secuenciade paréntesis. Podemosentonces representarlausando una gramática, yasociar la información so-bre excesos a los no ter-minales de la gramática.

Esto produce una representación mucho menorque los 2N bits cuando la secuencia es repetitiva(nótese que nuestro árbol de sufijos tiene hastaN=2n nodos, por lo que puede ocupar hasta 4nbits). Con una representación de gramáticas, elespacio para colecciones repetitivas ocupa unosn bits. Una gramática para generar nuestra se-cuencia de paréntesis podría ser como sigue:

Existen incluso representaciones de árboles desufijos que no utilizan en absoluto los paréntesis,

sino que los deducen de los otros componentes,especialmente del arreglo LCP, el que se alma-cena en forma de gramática para agilizar lasoperaciones. Para secuencias muy repetitivas,pueden llegar a necesitar sólo 1.5n bits en total,pudiendo almacenar 1000 genomas en casi500GB. Sin embargo, son también varios órde-nes de magnitud más lentos.

Exploramos la vía de eliminar del todo la topo-logía del árbol con mi exalumno memorista An-drés Abeliuk en 2012, obteniendo el menor árbolde sufijos hasta el momento. Con mi alumno deDoctorado Alberto Ordóñez, de la Universidadeda Coruña, exploramos la variante de usar gra-máticas para comprimir la topología en 2014,resultando en una estructura algo mayor, perohasta mil veces más rápida que la que prescindecompletamente del árbol.

ARREGLO DE SUFIJOS: es posible obtener unarepresentación compacta del arreglo de sufijosusando gramáticas, como vimos en el ejemplo.Probamos esta idea en 2007 con mi alumno deDoctorado Rodrigo González. Si bien el accesoal arreglo de sufijos es muy rápido, la compresiónque se alcanza no es competitiva con otras téc-nicas. Una que funciona mucho mejor, propuestapor Sadakane en 2000, es reemplazar el arreglode sufijos A[1,n] por otro que se llama [1,n],que contiene en [i] la posición j donde

corta, de 33 símbolos (contando los largos delos lados derechos de las reglas, que es cercanoal costo real de almacenarla) en vez de 40, dondeS es el símbolo inicial:

La diferencia sería más impresionante en unejemplo más largo, claro. Veremos ahora cómorepresentar cada componente del árbol de sufijoscompacto.

TOPOLOGÍA DEL ÁRBOL: la representacióncompacta clásica de un árbol de N nodos usa 2Nbits: se recorre el árbol en preorden abriendo unparéntesis al llegar a un nodo y cerrándolo aldejarlo definitivamente. Esta secuencia se parteen bloques, y se construye una jerarquía sobrelos bloques. Para cada nodo de esta jerarquía sealmacenan datos como el exceso total (suma deparéntesis que abren menos paréntesis que cie-rran), el mínimo y máximo exceso al recorrer elárea de izquierda a derecha, etc. Esta jerarquíaes suficiente para permitir navegar los paréntesiseficientemente, como si tuviéramos el árbol. Lasecuencia de paréntesis correspondiente a nues-

FIGURA 8.ARREGLO PLCP Y SU REPRESENTACIÓN COMO BITS PARA NUESTRA COLECCIÓN.

FIGURA 7.ARREGLO Ψ DE NUESTRA COLECCION.


14

A[j]=A[i]+1 (excepto si A[i]=n, en cuyo caso con-tiene la posición j donde A[j]=1). Requeriría mu-cho espacio explicar cómo este nuevo arreglopuede reemplazar al arreglo de sufijos. En cam-bio, nos centraremos en sus propiedades.La Figura 7 , muestra el arreglo de nuestroejemplo.

Hay dos cosas importantes que resaltar: primero,el arreglo es creciente en la zona de los sufijosque empiezan con cada letra (las letras inicialesse indican abajo). Con un poco de cuidado esopuede valer para la zona de los $ también. Estovale para cualquier tipo de texto y permite codi-ficar el arreglo en un espacio cercano al textocomprimido con un compresor simple, tipo Hu-ffman. Esto representa mucho menos espacioque el arreglo de sufijos original.

El segundo hecho es relevante para las coleccio-nes repetitivas: las zonas coloreadas se convier-ten en áreas de donde el arreglo crece de auna unidad, y por lo tanto es muy fácil de codi-ficar en muy poco espacio. Esto ocurre en todaslas zonas de cada color excepto en una, dondelos números son mayores. Nuevamente, no te-nemos suficiente espacio para explicar las razo-nes por las que esto ocurre. Con Veli Mäkinen ysus alumnos, de la University of Helsinki, publi-

camos en 2008 el Run-Length Compressed SuffixArray, que usa esta idea y se ha convertido en laprincipal estructura para utilizar en esta situación.En colecciones repetitivas, esta estructura usaunos 0.7n bits.

ARREGLO LCP: como mencionamos, el arregloLCP se puede comprimir usando una gramáticay eso es buena idea cuando no se representa latopología del árbol, pues se necesita accederlomuy frecuentemente. Cuando se tiene la topo-logía, los accesos a LCP son mucho más esporádi-cos y se puede utilizar una representación máscompacta. Sadakane propuso en 2007 utilizar acambio el arreglo PLCP (Permuted LCP), dondePLCP[i] = LCP[A[i]], es decir, almacena los mismosvalores pero en orden de texto. Esto es conve-niente porque, en ese orden, vale quePLCP[i+1] >= PLCP[i]-1. Esto permite marcar losvalores PLCP[i]+2i (que es una secuencia estric-tamente creciente) como 1s en un vector de 2nbits, y recuperar eficientemente la posición deli-ésimo 1 del vector para encontrar el valor dePLCP[i]. Además de esta notable reducción deespacio, se puede ganar aún más en las colec-ciones repetitivas. El arreglo PLCP y el vector debits para nuestro ejemplo se muestran en laFigura 8.

Obsérvese cómo aparecen largas zonas decre-cientes en una unidad en PLCP, que se traducenen largas zonas de 1s (y por lo tanto de 0s, yaque hay n de cada uno) en el vector de bits. Estapropiedad, que demostramos con Veli Mäkineny Johannes Fischer, del KIT Alemania, en 2008,hace al vector de bits mucho menor que 2n bitsen colecciones repetitivas, como confirmamoscon mi exalumno Andrés Abeliuk: ¡se llega a usarunos 0.2n bits!

Sumando los n bits de los paréntesis, los 0.7 nbits del arreglo de sufijos, y los 0.2n bits del LCP,tenemos los 2n bits mencionados. Sacando losparéntesis y agregando una compresión de gra-máticas para LCP, obtenemos los 1,5 n bits yamencionados también. Cuando se incluye latopología del árbol, la estructura realiza las ope-raciones en microsegundos, mientras que cuan-do no, se llega a los milisegundos. Para ponerestos resultados en contexto, la representaciónque usa 2n bits es aún diez veces más lenta queel árbol de sufijos compacto de Sadakane (perotambién ocupa cinco veces menos espacio, y vaocupando menos a medida que la repetitividadaumenta). Un árbol de sufijos clásico ¡ocupa 320veces más espacio que la representación usandoparéntesis comprimidos con gramáticas!


15

CONCLUSIONESEXPLOTAR LA REPETITIVIDAD DE LOS DATOS PUEDE SER LA CLAVE PARA AFRONTAR EL DILUVIO DE DATOS QUE SE AVECINA RÁPIDAMENTE.EL ENTENDER CÓMO LA REPETITIVIDAD EN LOS DATOS SE MANIFIESTA EN LAS DISTINTAS ESTRUCTURAS DE DATOS QUE USAMOS PARAACCEDER EFICIENTEMENTE A ELLOS PERMITE DISEÑAR VARIANTES DE ESTA S ESTRUCTURAS QUE REDUCEN SU ESPACIO EN ÓRDENES DEMAGNITUD. MOSTRAMOS CON CIERTO DETALLE EL CASO DE LOS ÁRBOLES DE SUFIJOS, UNA HERRAMIENTA MUY IMPORTANTE PARA ELANÁLISIS DE SECUENCIAS. EL SEGUIR EL MISMO CAMINO CON OTRAS ESTR UCTURAS Y OTROS TIPOS DE DATOS REQUIERE UN TRABAJOALGORÍTMICO MUY ESTIMULANTE EN UN ÁREA QUE SE CONSTRUYE SOBRE UN A LARGA TRADICIÓN DE INVESTIGACIÓN EN ALGORITMOS YESTRUCTURAS DE DATOS Y TEORÍA DE LA INFORMACIÓN, PERO QUE A LA VEZ ESTÁ CASI INEXPLORADA, ESPERANDO LA CONTRIBUCIÓN DENUEVOS INVESTIGADORES.

16

“Empresa Nacional de Computación e Informática” (ECOM) fue elnombre que recibió en diciembre de 1970 la “Empresa de Servicio deComputación” (EMCO) creada anteriormente en septiembre de 1968como filial de CORFO, Endesa y Entel. En el período 1971-1973 ECOMamplió su cobertura más allá de los servicios y la capacitación, desa-rrollando investigación aplicada que permitió transitar desde el desa-rrollo de proyectos “a la medida” hacia la construcción de paqu etesde software genéricos y la participación en la realización de proyectosde gran envergadura e impacto nacional (Censo, RUN, Synco).

Computacióny Sociedad

17

JUANÁLVAREZAcadémico Departamento de Ciencias de la Computación,Universidad de Chile. Master of Mathematics (ComputerScience), University of Waterloo. Ingeniero de Ejecución enProcesamiento de la Información, Universidad de Chile.Junto a su labor como docente, trabaja en reconstruir laHistoria de la Computación en [email protected]


INTRODUCCIÓNLa Empresa de Servicio de Computación (EMCO),fue creada en septiembre de 1968 con el propó-sito de: 1) proporcionar servicios de procesa-miento de datos a entidades del Estado; 2) di-fundir el uso de sistemas de procesamiento dedatos y de equipos electrónicos; y 3) prepararpersonal técnico en análisis y programación desistemas para los Servicios del Estado [1]. En abrilde 1970, un balance de la operación [2] mostrabaque EMCO:

Cubre el servicio del 30% de la demanda consólo un 17% del gasto total del país.Ofrece el 81% del servicio de la demanda delsector público, con una inversión del 55% deltotal del sector.Atiende a 41 instituciones del Estado que seproyectan a 50 para fines de 1970.De 40 funcionarios en diciembre de 1968, pasóa 120 en diciembre de 1969 y se proyecta con-tar con 230 en 1970.Cuenta con 3 computadores propios conUS$84.500 de gasto mensual.

Considerando que las actividades proyectadaspara la empresa superarían las de un servicio decomputación, el 24 de diciembre de 1970 EMCOcambió su nombre a “Empresa Nacional deComputación e Informática” (ECOM). En otraspalabras se eliminó la palabra “servicio” y seincorporó “nacional” en consistencia con supretensión de operar en todo el país. “Informá-tica”, término nuevo en la época, se agregó paraenmarcar el tipo de actividades de la empresa:“La informática se dedica a la investigación

de las propiedades, el comportamiento y lasleyes que gobiernan los procesos de transferen-cia y la tecnología para el procesamiento de lainformación con el objeto de optimizar su accesoy uso” [3].

A continuación, se presentan los principalesrecursos y proyectos realizados por ECOM en elcorto e intenso período comprendido entrediciembre de 1970 y septiembre de 1973.

ESTRUCTURAY PERSONALEn 1970, una vez que el Dr. Salvador Allendeasumió la presidencia del país, se designó a losejecutivos de ECOM: Raimundo Beca, economis-ta de la Universidad Católica, como gerentegeneral y como Presidente del Directorio; HéctorHugo Segovia, ingeniero industrial de la Univer-sidad de Chile, como gerente de Ingeniería; Gon-zalo Vargas, ingeniero industrial de la Universi-dad de Chile, como gerente de operaciones. Losdepartamentos de la Gerencia de Ingenieríacontinuaron a cargo de René Barros (Análisis),Jorge Gutiérrez (Programación), Germán Munita(Investigación y Desarrollo) y Mario Pardo (Ca-pacitación). Posteriormente, se creó la Gerenciade Planificación y Desarrollo a cargo de HéctorHugo Segovia y en el Departamento de Investi-gación y Desarrollo asumió Isaquino Benadof.

Respecto del personal, a fines de 1971 se contabacon 253 personas (que se proyectaban a 373para 1972), distribuidos en 12 directivos (15 para

18


FIGURA 1.COMPUTADOR BURROUGHS 3500 DE ECOM.

FIGURA 2.COMPUTADOR IRIS-80 DE CII QUE LLEGARÍA A ECOM A FINES DE 1973.

1972), 67 profesionales/técnicos (98), 41 admi-nistrativos (50), 109 calificados (178) y 24 nocalificados (32) [4].

COMPUTADORESEn 1971 ECOM disponía de tres computadoresIBM/360 [1] y las estadísticas de uso, en compa-ración con el año 1970, fueron las siguientes [5]:

El IBM/360 modelo 40 con 256K de memoriase usó 6036 horas (6360 en 1970).El IBM/360-50 con 384K de memoria se utilizó5429 horas (3988 en 1970).El IBM/360-40 con 128K (instalado en Endesa)se usó 4308 horas (3213 en 1970).

En 1972 ECOM adquirió un computador Bu-rroughs 3500 (Figura 1) orientado al procesa-miento de datos de tipo administrativo del sectorfinanciero del Gobierno. El total del monto dela inversión fue de E°8.200.000 y fue pagado porCORFO. La configuración, similar a la del com-putador Burroughs 3500 de la Universidad Ca-tólica con quien se estableció un convenio derespaldo mutuo, era la siguiente [6]:

Procesador central B3501 con 120 Kilobytesde memoria.Consola (SPO) B9340.Unidad electrónica de 20.000KD.Unidad electrónica de 40.000KD.Impresora B9243.2 unidades de cinta B9381 para densidadde grabación de 800 bytes por pulgada.4 unidades de cinta B9393 para 1600 bytespor pulgada.Unidad lectora de tarjetas B9112.

Por otra parte, a fines de 1973 iniciaría su opera-ción el sistema IRIS-80 adquirido por ECOM a lacompañía francesa CII (Compagnie Internatio-nale pour l’Informatique) en US$3.100.000 (Fi-gura 2). El computador “será instalado en unedificio que está construyendo la empresa a lospies del cerro Manquehue” y “pasaría a ser en elmediano plazo el núcleo de una red nacional de

19


FIGURA 3.PORTADA DE MATERIAL DE CURSO DE CAPACITACIÓN.

UNIDAD VELOCIDAD IRIS-80 IRIS-60

Unidad Central de Proceso 1.200.00 instrucciones por segundo 2 1

Memoria Ciclo de 650 nanosegundos 768K 192K

Procesador multiplexor de E/S 42000 kilobytes por segundo 2 1

Unidad de Cinta de 1600bpi 120 kilobytes por segundo 10 4

Unidad de Cinta de 800bpi 60 kilobytes por segundo 2 1

Disco magnético Tiempo acceso: 17-50 mili segundos 600M bytes 150M bytes

Impresora 1200 líneas por minuto 4 2

Lectora de tarjetas 1000 tarjetas por minuto 2 1

Perforadora de tarjetas 200 tarjetas por minuto 1 1

Terminal teletipo 10 caracteres por segundo 16

TABLA 1.CONFIGURACIONES DE LOS COMPUTADORES IRIS-80 E IRIS-60.

CURSO 1969 1970 1971 1972

Programación 30 57 38 75

Análisis 23 73 53 75

Interlocución 75 155 120

Total 53 205 246 270

TABLA 2.ESTADÍSTICAS DE CURSOS DE CAPACITACIÓN.

computadores” [7]. Además se adquirió un com-putador IRIS-60 en US$1.240.000 destinado a laZona de Concepción (Tabla 1).

Adicionalmente se contaría con minicomputado-res MITRA-15 de CII: dos en Santiago y uno enConcepción. Estarían equipados con lectora detarjetas (de 300 tarjetas por minuto) e impresora(de 200 líneas por minuto) y serían utilizadoscomo procesadores independientes y como ter-minales inteligentes. En el caso de Concepciónse conectaría también como terminal al sistemaIRIS-80 de Santiago.

Con la llegada del nuevo computador, uno de losya existentes en Santiago sería trasladado a Val-paraíso principalmente para las aplicaciones dela Superintendencia de Aduanas, Emporchi y Sud-americana de Vapores. Por otra parte, se adquiriríaun computador IBM/370-145 que sería propiedadde la Universidad Técnica del Estado (UTE, hoyUSACH) y ECOM cancelaría como arriendo aproxi-madamente un 77% del valor del equipo (aproxi-madamente 1,1 millones de dólares). La UTE en-tregaría a ECOM la administración ycomercialización del tiempo de computador y laUniversidad tendría derecho a uso liberado hastapor un 23% de su capacidad horaria [4].

CAPACITACIÓNY SERVICIOSEn consistencia con sus propósitos fundacionales,ECOM continuó ofreciendo servicios decapacitación y procesamiento de datos adiferentes instituciones del Estado. En el área decapacitación, y en comparación con añosanteriores ( Tabla 2 ), creció notoriamente laformación de interlocutores, concebidos comoejecutivos medios que pueden intermediar entrelos usuarios y los técnicos especialistas[5][4].

20


FIGURA 4.RESULTADOS GENERALES DEL CENSO 1970 PROCESADO POR ECOM.

El curso básico de análisis de sistemas ( Figura3) duraba cinco meses a tiempo completo y de-dicación exclusiva. El plan estaba basado en uncurso del National Computing Centre de GranBretaña y comprendía las siguientes unidades:Fundamentos de Computación (cinco semanas),Introducción al Sistema 360 (dos semanas), Básicode Programación Cobol (cuatro semanas), Orien-tación administrativa (tres semanas) y Básico deAnálisis de Sistemas (siete semanas). Los postu-lantes debían tener 25 o más años, ser egresadosde la universidad y al menos dos años de trabajoen cargos de responsabilidad administrati-va/financiera y/o en procesamiento electrónicode datos. Adicionalmente debían aprobar el sis-tema de selección de ECOM en base a entrevistasy un test de aptitudes [8].

Por otra parte, ECOM prestó servicios de tiempode computador (en modalidad “Service” y “BlockTime”), de perfo-verificación, y de asesoría enanálisis de sistemas. El servicio de procesamientode datos se extendió a más instituciones delEstado, siendo los principales usuarios Enap, ElTeniente, Instituto Nacional de Estadísticas, Cen-tral de Informaciones del Ministerio de Vivienda,Endesa, Caja de Previsión de Empleados Particu-lares, Sector Financiero del Gobierno, Ministeriode Justicia, Ministerio de Educación, Ferrocarrilesdel Estado, Servicio Médico Nacional de Emplea-dos, Servicio de Seguro Social, Caja de EmpleadosPúblicos, Registro Electoral, Oficina de Planifica-ción Agrícola, Municipalidad de Providencia,Fondo de Extensión y Educación Sindical, Com-pañías del Cobre y usuarios de Valparaíso y Con-cepción [9].

CENSO Y PROYECTORUN-RNPEn el período 1971-1973 ECOM participó en pro-yectos nacionales de gran envergadura. Al res-pecto, el martes 21 de abril de 1970 se realizó elXIV Censo de Población y el III de Vivienda. Eldiario La Nación tituló en su portada “El censo alas computadoras – Alimentado con 10 millonesde tarjetas, cerebro electrónico analizará datos

del Censo 1970” informando que, gracias a quepor primera vez se utilizaría un computador, eldetalle se conocería en un plazo de dos a tresaños [10]. Posteriormente, al presentar los resul-tados (Figura 4) el Instituto Nacional de Estadís-ticas expresó [11]:

Deseamos dejar constancia que el procedimien-to computacional de los datos estuvo a cargode la Empresa Nacional de Computación(ECOM). Una de las etapas más importantes deeste proceso fue la confección de un programade validación y asignación automática de datos(ASIG), el que permite la presentación de la in-formación sin errores de consistencia estadísti-ca. Este programa fue el producto del trabajoconjunto de ambas instituciones y se elaborósobre la base de criterios estadísticos, que ase-guran la plena validez cuantitativa de la infor-mación que se presenta.

Por otra parte, ECOM participó activamente enel “Proyecto Rol Único Nacional y Registro Nacio-nal de Población” realizado en conjunto con laSubsecretaría de Justicia, la Dirección de Presu-puesto, el Registro Civil e Identificación y el Ser-vicio de Impuestos Internos. La Comisión Técnicadel Proyecto “fue creada a mediados de 1971, ytuvo como principal objetivo el formular las po-líticas y programas de trabajo para iniciar durante1972 la creación de un Registro Nacional de Po-blación (RNP) y la implantación de un númeroúnico de identificación para todos los habitantesdel país (RUN)” [12].

Para alcanzar el normal funcionamiento de lossistemas computacionales y administrativos seestimó un período de aproximadamente cuatroaños. ECOM participó con dos de los seis inte-grantes en la Comisión Técnica (Hugo Segovia yRené Barros) y destinó un equipo de nueve per-sonas para construir un proyecto piloto y diseñare implementar los sistemas computacionalesdefinitivos. Adicionalmente se contó con la ase-soría de Pinchas Stern, experto de Naciones Uni-das en Sistemas de Información.

Cabe señalar que el proyecto RUN-RNP necesitóinvestigación acerca del diseño de números deidentificación con dígitos verificadores y respectodel procesamiento de consultas y de la recupe-ración de información utilizando y adaptandocódigos SOUNDEX. El trabajo de investigación ylos desarrollos realizados permitieron la publica-ción de artículos, reportes técnicos y presenta-ciones en seminarios nacionales [13] y congresosinternacionales [14].

SYNCOEn noviembre de 1971 el Presidente Allende,después de una reunión con el cibernético inglésStafford Beer propiciada por el subgerente téc-nico de CORFO Fernando Flores, aprobó iniciarel proyecto Synco (inicialmente llamado Cyber-syn) cuyo objetivo era desarrollar “Sistemas deInformación y Control” de la producción de las

empresas del área social [15]. El proyecto fueconcebido en la Dirección Industrial de CORFO,involucró también al Instituto Tecnológico (INTEC)y a ECOM y contempló cuatro componentes [16]:

Establecimiento de una Red de Comunicacio-nes (Cybernet) entre las principales empresasdel Área Social y CORFO a través de un SistemaTélex.

El desarrollo de un Sistema Computacionalpara el control de la gestión operativa del ÁreaSocial en tiempo real (Cyberstride).

La simulación dinámica de sistemas, con elobjetivo de apoyar las actividades de desarrolloy planificación del aparato industrial (CHECO).

La construcción de una Sala de Operaciones(Opsroom) con el objetivo de facilitar la tomade decisiones, a través de crear condicionesfavorables para la trasmisión y uso de la infor-mación que generan los sistemas anteriores.

En un trabajo colaborativo con un grupo de in-vestigadores en Inglaterra, ECOM desarrolló Cy-berstride y destinó algunos investigadores aCHECO. Cyberstride se implementó inicialmenteen el computador IBM/360-50, pero debido aexigencias de alta disponibilidad fue portado,en muy poco tiempo y no sin dificultades, porIsaquino Benadof y su equipo al computadorBurroughs 3500 donde finalmente estuvo dispo-nible en los últimos meses de 1972, realizándoseuna demostración para el presidente Allende eldía 30 de diciembre [17].

El propósito de Cyberstride se difundió a losusuarios de las industrias y de CORFO a travésde un dibujo (Figura 5) y una descripción sencilla:“Lo que hará el computador es recolectar cadadía la información e informar a los interesadoscuando esté ocurriendo alguna anormalidad,anormalidad que es preestablecida antes deenviar la información al computador” [18]. Lasventajas se resumían precisando que la utilizacióndel sistema:

Elimina los informes, cuadros con excesivosdatos que nadie es capaz de asimilar ni recor-

21


2 .

3 .

4 .

FIGURA 5.DIFUSIÓN DEL COMPONENTE CYBERSTRIDE DEL PROYECTO SYNCO.

dar por mucho tiempo. El sistema informa so-bre lo que hay que preocuparse, es decir, sobrelos problemas y anormalidades actuales.

Elimina papeles y datos que no tenganninguna actualidad.

Los problemas serán solucionados en loslugares mismos en que estos se produzcan.

Los informes son fácilmente comprensiblespuesto que en ningún caso representan mu-chas cifras.

El funcionamiento inicial del proyecto Synco tuvoimplicancias importantes. Por una parte, y conel propósito de lograr “una dirección eficaz delsector industrial que requiere del respaldo per-manente de una corriente apropiada deinformación”, el 30 de abril de 1973 se creó laDirección de Informática en la CORFO y se desig-nó a su cargo al gerente general de ECOM Rai-mundo Beca [19].

Por otra parte, se concluyó que era necesarioimplementar una red de teleprocesamiento [15].Para este efecto, en junio de 1973 se establecióun convenio entre ECOM y ENTEL para planificare implementar un servicio de trasmisión y tele-procesamiento de datos [20]. Así, “un computa-dor distante puede tener acceso a un archivo dedatos centralizados, así como también hay laposibilidad de una comunicación de alta veloci-

dad entre computadores. En este último casopuede señalarse, a modo de ejemplo, que uncomputador instalado en Concepción podríadialogar con otro de mayor capacidad ubicadoen la capital”.

DESARROLLO DEPAQUETESEn el período 1971-1973 ECOM transitó desdeel desarrollo de proyectos “a la medida” hacia laconstrucción de paquetes de software genéricos.Por ejemplo, debido a la gran cantidad de siste-mas de pagos de sueldos, cuentas corrientes ycontabilidad; y la necesidad de ahorrar esfuerzosde programación, análisis y diseño; ECOM deci-dió desarrollar sistemas genéricos entonces lla-mados paquetes: “Sistema Generalizado de Pagode Sueldos”, “Sistema Normalizado de CuentasCorrientes Bancarias”, “Sistema Contable”.

La primera versión del “Sistema Generalizadode Pago de Sueldos” estuvo disponible en sep-tiembre de 1971 y una segunda versión optimi-zada se liberó en junio de 1973. El modelo básicodistinguió como elementos fundamentales loshaberes (pagos), los descuentos legales o impo-sitivos y los descuentos varios (compromisos delfuncionario). El sistema contempló los archivosMaestro y de Movimiento y los subsistemas deconfección y actualización correspondientes

1.

2.

3.

4.

1.

22


FIGURA 6.ESTRUCTURA DEL SISTEMA CONTABLE.

(ACTAM y ACTAMOV). Un tercer subsistema(PROSUELDO) procesaba los archivos y producíael Archivo de Liquidación con los sueldos de losfuncionarios. La construcción modular y el usode tablas permitían adaptar la estructura centralcon subsistemas optativos para casos particulares[21].

El “Sistema Normalizado de Cuentas CorrientesBancarias” se desarrolló por iniciativa de la Co-misión Bancaria de Procesamiento de Datos, através de un convenio entre el Banco del Estadoy ECOM y la participación de la Superintendenciade Bancos. La motivación era normalizar parafacilitar el proceso de fusiones, estandarizar enla banca estatizada y actualizar algunos bancoscon déficit y mal estado de las máquinas espe-cializadas de “registro directo”. Las funciones delsistema eran: control de cuentas corrientes, ac-tualización diaria, control de retenciones, liqui-dación a fines de ejercicio, emisión de estadosde cuentas y de informes relativos a balances,estadísticas, etc. Respecto del Sistema, ECOMprestaba los siguientes servicios: preparación dedatos, operación, análisis y programación, man-tención y capacitación para funcionarios de losusuarios [22].

El “Sistema Contable” abordó el problema quedeben enfrentar los ejecutivos para la toma dedecisiones. La aplicación fue diseñada de maneraque la CORFO y sus filiales uniformaran los pro-cedimientos contables. En una primera etapa sedesarrolló un Sistema Contable Básico con algu-nos agregados: presupuesto de caja, cuadros decosto, y algunos indicadores económicos finan-cieros [23]. La segunda etapa, Contabilidad deGestión, permitiría comparar la producción consu costo detectando los puntos débiles y permi-tiendo corregir a tiempo. El Sistema se estructurócon los subsistemas de Validación y Cuadraturade documentos contables, Maestro de Cuentas,Diario-Mayor y Balance, Análisis de Cuentas, Ló-gica y Nombre de Análisis [24] (Figura 6).

Otra línea de desarrollo fue la ProgramaciónAutomática, es decir, la construcción de softwareque generaba programas de aplicación de usohabitual. Los generadores de programas tradu-cían una especificación en un “lenguaje orienta-

do a problema” a instrucciones en un lenguajede programación tradicional. Al respecto sedesarrollaron generadores de programas devalidación (GENEVAL) [25], de edición de infor-mes y de analizadores sintácticos. Su generali-zación se logró automatizando la producciónde los programas generadores [26].

DEPARTAMENTO DEINVESTIGACIÓN YDESARROLLO

Muchos de los proyectos más importantes deECOM fueron desarrollados o contaron con elapoyo del Departamento de Investigación yDesarrollo (INDE) de la Gerencia de Ingeniería.El Departamento fue fundamental en la investi-gación aplicada que se necesitó para desarrollarlos proyectos y para su divulgación a través dereportes técnicos, boletines y cursos.

Los reportes técnicos se publicaron desde el año1970 y en ellos se encuentran los fundamentosy los avances del desarrollo de los diferentesproyectos (Tabla 3). Los documentos permitenapreciar el trabajo de los investigadores e inge-nieros en los distintos proyectos: sueldos, pro-cesamiento de encuestas, bibliotecas, controlde proyectos, RUN, recuperación de información,generación automática de programas, telepro-cesamiento, etc.

El Boletín del INDE comenzó a publicarse enjunio de 1972 con un propósito de divulgaciónmás extensa que los reportes técnicos. Por esamisma razón la extensión de los artículos es másbreve y sus contenidos son más generales. Losíndices de los primeros seis boletines (Tabla 4),permiten apreciar prácticamente a los mismosautores y los mismos temas de los reportes téc-nicos pero dirigidos a un público más amplio,incluso fuera de ECOM. De hecho, en noviembrede 1972 el boletín alcanzó un tiraje de 900 ejem-plares convirtiéndose en un importante mediode información de la comunidad informática

23


TABLA 3.REPORTES TÉCNICOS DEPARTAMENTO DE INVESTIGACIÓN Y DESARROLLO.

AUTOR TÍTULO FECHAAvilés, H. Norma de presentación de informes 72/04Brokering, E. Procesamiento de encuestas mediante computador 70/12Munita, G.Brokering, E. Alternativas de Teleprocesamiento. Proyecto Dirección Industrial CORFO 72/07Calderón, B. Documentación general del paquete de sueldos 72/03Brokering, E.Calderón, B. Estudio preliminar sobre programas generalizados de aplicación estadística 72/05Duffau, E. Recuperación de Información 71/05

Programa graficador de cartas Gantt 72/05Gamboa, F. Reglas prácticas para el uso del generador de validación 72/05Letelier, G. Programa generador de programas de validación 72/06Gamboa, F.Munita, G. Documentación de Sistemas. VI: tablas de decisiones 70/06

Norma sobre preparación de publicaciones 72/04Pinedo, J. Sistema generalizado para procesamiento de encuestas por computador, SISTAB 72/07Segal, S. PCS, un sistema integrado para el control de proyectos 70/09

Los métodos de trayectoria crítica y su relación con el proceso administrativo 71/09Características de PROMIS y comparación con CPS 72/05Ejemplos de PCS 72/05Manual de PCS 72/05Ejemplo PROMIS 72/06Modelo de ubicación de satélites. Unesco. Descripción general del sistema computacional 72/07

Stern, P. Comparación de datos de alumnos contra un archivo del Registro Civil 71/11Duffaut, E.Vázquez, R. Resolución de problemas de Bibliotecas por medio de computadores. Sistema BIB1 72/03

Sistema BIB1 para el control de bibliotecas. Documentación para usuarios 72/03Aspectos básicos del control de inventario 72/05

nacional, razón por la cual se abrió a la publica-ción de contribuciones provenientes desde fuerade ECOM.

Por otra parte, durante 1971 y 1972 el Departa-mento realizó diversas charlas y cursos destina-dos a difundir el empleo de programas de usogeneral. Particularmente en 1972 se realizaroncursos sobre PCS, MPS, GPSS y GENEVAL, tantodentro como fuera de ECOM. En 1973 se realizóel programa “Capacitación IRIS-80” [27]. El pro-grama contempló un ciclo de difusión y un cicloregular de cursos. El ciclo de difusión se realizóa través de seminarios de diez horas orientadosfundamentalmente a ejecutivos. El ciclo regularestuvo dirigido a personas que deberían trabajardirectamente en los sistemas que serían proce-sados en el equipo IRIS-80. Al respecto, se ofreció

un programa por tipo de especialistas: jefes deservicios (2.5 días), analista (20.5 días), progra-mador (33 días) y programador y analista avan-zado (63 días).

RELACIÓN CONUNIVERSIDADESDurante el período 1971-1973 ECOM se relacionópermanentemente con las universidades. En elcaso de la Universidad de Chile esa relación semanifestó principalmente en docencia y en me-morias de título. Varios ingenieros e investiga-dores de ECOM fueron profesores de cursos deComputación en la Escuela de Ingeniería. En

particular Hugo Segovia fue profesor de“Sistemas de Información”, Pablo Fritis de“Estructuras y Procesos de la Información”, RenéBarros y Víctor Canales de “Introducción a laComputación” y Alberto Ulriksen y Hernán Avilésde “Simulación”.

ECOM fue también el lugar donde varios estu-diantes de la Universidad de Chile trabajaron yrealizaron sus memorias en el período 1971-1973 aunque sus titulaciones fueron posteriores(Tabla 5). Las memorias estuvieron asociadas alos proyectos Synco, Censo, Generación Automá-tica de Programas, Inventarios, etc. Y cubrierondistintas carreras de Ingeniería: Civil, Industrial,Matemática, y de Ejecución en Procesamientode la Información (la primera carrera de inge-niería en el área en Chile).

AÑO NOMBRE TÍTULO ESPECIALIDAD73 Avilés, Hernán Dinámica de sistemas una técnica de simulación Matemática73 Stern, Luis Estudio, prueba e implementación de un sistema de Industrial

control de proyectos con nivelación de recursos74 Cárdenas, Hernán Evaluación de técnicas de organización de archivos Industrial74 Gamboa, Fernando Programación automática de generadores de Procesamiento

programas y analizadores sintácticos Información74 Castro, Eduardo Algoritmos de corrección de errores aplicados Procesamiento

Ibáñez, Pablo al procesamiento de personas del XIV Censo Información75 Brain, Hernán Un sistema computacional generalizado de control Industrial

físico y valorizado de inventarios75 Letelier, Gabriel Diseño y construcción de un generador de programas Civil

de validación


16

TABLA 4.ÍNDICES BOLETÍN DEL DEPARTAMENTO DE INVESTIGACIÓN Y DESARROLLO.

TABLA 5.MEMORIAS REALIZADAS EN ECOM POR ESTUDIANTES DE LA UNIVERSIDAD DE CHILE.

24

N° FECHA AUTOR TÍTULO ARTÍCULO1 26/06/72 Calderón, Benjamín Sistema generalizado de pago de sueldos

Letelier, Gabriel GENEVAL2 26/07/72 Munita, Germán Análisis histórico del rendimiento de equipos computacionales

Letelier, Gabriel Estado actual de GENEVAL3 28/08/72 Avilés, Hernán Sistemas, modelos y simulación

Duffau, Etienne Corrección de claves numéricas mediante el uso de dos dígitos verificadoresCabrera, Carlos Sistema normalizado de cuentas corrientesCalderón, Benjamín Programas relacionados al paquete de sueldosLetelier, Gabriel Datos estadísticos acerca de la utilización del generador de programasGamboa, Fernando de validaciónGuzmán, Felipe Proposición de sistema de información para mantención de equiposBenadof, Isaquino ¿Qué es la Cibernética?

4 26/09/72 Avilés, Hernán Dinámica de sistemasDuffau, Etienne Versión preliminar de un soundex españolCalderón, Benjamín Sistema de identificación del paquete de sueldosLetelier, Gabriel Evaluación de un programa generado por GENEVAL mediante “PPE”Benadof, Isaquino Herramientas y cibernéticaCárdenas, Hernán Modelo de simulación de estructura de archivos

5 26/10/72 Munita, Germán Las economías de escala y la ley de GroschBrain, Hernán Conceptos generales del control de inventariosStern, Luis PROMIS, un sistema de control de proyectosCalderón, Benjamín Sistema básico de codificación del paquete de sueldosLetelier, Gabriel Aplicabilidad de META-POL a la generación de programasBenadof, Isaquino ¿Qué es la ergonomía?

6 24/11/72 Munita, Germán Los nuevos computadores de ECOMDuffau, Etienne Sistemas de Identificación ISegal, Sergio Formulación y solución computacional del problema de la dietaCabrera, Carlos Sistema normalizado de cuentas corrientesCalderón, Benjamín Registros de entrada al paquete de sueldosLetelier, Gabriel Características de una 3ra. Versión de GENEVAL

CONCLUSIONESLA REVISIÓN DE LA ESTRUCTURA, LOS RECURSOS Y LOS PROYECTOS DE LA EMPRESA NACIONAL DE COMPUTACIÓN E INFORMÁTICA (ECOM)DURANTE EL PERÍODO 1971-1973, PERMITE DISTINGUIR ELEMENTOS DE CONTINUIDAD Y CAMBIO CON RESPECTO AL PERÍODO INICIAL 1968-1970DE LA EMPRESA DE SERVICIO DE COMPUTACIÓN (EMCO).

ECOM CONTINUÓ CUMPLIENDO LOS PROPÓSITOS FUNDACIONALES DE PROPORCIONAR SERVICIOS COMPUTACIONALES A LAS INSTITUCIONALESESTATALES Y CAPACITAR PERSONAL. EN ESTAS DOS DIMENSIONES ECOM RE PRESENTÓ UN SALTO CUANTITATIVO, AUMENTANDO, TANTO LACANTIDAD DE COMPUTADORES Y USUARIOS, COMO EL NÚMERO DE PERSONAS ENTRENADAS EN PROGRAMACIÓN, ANÁLISIS E INTERLOCUCIÓN.

POR OTRA PARTE, EL QUEHACER DE ECOM SIGNIFICÓ UN SALTO CUALITATIVO RESPECTO DE LO REALIZADO POR EMCO. EN EFECTO, ENTRE LOSAÑOS 1971 Y 1973, ECOM TRANSITÓ DESDE LA CONSTRUCCIÓN DE SOFTWARE “A LA MEDIDA”, HACIA EL DESARROLLO DE SISTEMAS GENÉRICOS(SUELDOS, CUENTAS CORRIENTES, CONTABILIDAD, GENERADORES DE PROGRAMAS) Y DE PROYECTOS DE IMPACTO NACIONAL EN CONJUNTO CONOTRAS INSTITUCIONES ESTATALES, POR EJEMPLO EL CENSO CON EL INE, EL RUN-RNP CON EL REGISTRO CIVIL Y EL MINISTERIO DE JUSTICIA, ELEMBLEMÁTICO PROYECTO SYNCO CON LA CORFO E INTEC, Y LOS PROYECTOS CON LAS INDUSTRIAS DE LA REGIÓN DEL BIOBÍO.

EL SALTO CUALITATIVO SE SUSTENTÓ EN EL TRABAJO DE LAS GERENCIAS DE INGENIERÍA Y DE PLANIFICACIÓN Y DESARROLLO Y DEL DEPARTAMENTODE INVESTIGACIÓN Y DESARROLLO. ALLÍ SE REALIZARON LOS ESTUDIOS, LA INVESTIGACIÓN APLICADA Y LAS PRUEBAS DE LOS PROTOTIPOS DELOS SISTEMAS DE SOFTWARE. SUS RESULTADOS FUERON DIFUNDIDOS EN EL MEDIO NACIONAL A TRAVÉS DE REPORTES TÉCNICOS, BOLETINES YCURSOS. ESTE QUEHACER SE RELACIONÓ TAMBIÉN CON LAS UNIVERSIDADES A TRAVÉS DE MEMORIAS, DOCENCIA Y COORDINACIÓN CON SUSCENTROS DE COMPUTACIÓN.

EN SÍNTESIS, EL QUEHACER DE ECOM EN EL PERÍODO COMPRENDIDO ENTRE DICIEMBRE DE 1970 Y SEPTIEMBRE DE 1973 DEJÓ UN VALIOSO LEGADOAL MEDIO COMPUTACIONAL Y TECNOLÓGICO NACIONAL. LA MAYORÍA DE LOS PROYECTOS Y SISTEMAS CONTINUARON VIGENTES, OTROS QUEDARONPENDIENTES Y FUERON REALIZADOS POSTERIORMENTE (NUEVO EDIFICIO, C OMPUTADOR PARA LA UTE), Y UNOS POCOS FUERON CANCELADOS(LA COMPRA DE LOS COMPUTADORES FRANCESES, EL PROYECTO SYNCO). POR ÚLTIMO, Y QUIZÁS LO MÁS IMPORTANTE, ECOM LEGÓ AL PAÍS UNCONJUNTO DE PERSONAS DOTADAS DE UNA EXPERIENCIA, UNA MÍSTICA DE TRABAJO Y UN ESPÍRITU DE SERVICIO PÚBLICO QUE CONTRIBUYERONAL DESARROLLO Y PROGRESO DE LA DISCIPLINA INFORMÁTICA EN CHILE Y EN ALGUNOS PAÍSES DEL EXTRANJERO.

25


La relación con las universidades se produjotambién en el marco de la Asociación Chilenade Centros Universitarios de Computación(ACUC), creada en diciembre de 1970, dondeECOM participó como miembro invitado conderecho a voz. De hecho, en el primer boletínde la ACUC, de julio de 1973, Germán Munitaescribió un artículo respecto de los computado-res disponibles en ECOM y de los futuros com-putadores IRIS [6].

SUBGERENCIA ENCONCEPCIÓNEn 1971 CORFO Biobío aprobó la idea de crearuna instalación informática regional para apoyar

las empresas del Área Social, algunas de lascuales ya poseían computadores y personal ca-pacitado [28]. ECOM acogió la iniciativa y creóuna subgerencia que dependía del Gerente Ge-neral, y contó con el apoyo de la Gerencia deAdministración y Finanzas. Posteriormente, en1972, ECOM aprobó el proyecto “Centro de In-formática Lautaro” que albergaría un IRIS-60 yminicomputadores MITRA-15 para teleproceso.El proyecto contempló un edificio de mil metroscuadrados con empleo de acero, vidrio y cemen-to y con un mural de Julio Escámez en el hall deacceso.

La subgerencia estuvo a cargo del ingenieroÓscar Sáez y se contrató una docena de funcio-narios, la mayoría ingenieros y técnicos (entreellos siete analistas y un programador) y fueron

capacitados en las herramientas de los IRIS yMITRA. Dos de ellos fueron enviados a capacitar-se a Francia.

La subgerencia realizó proyectos en el marco deconvenios con la siderúrgica CAP, la mineraENACAR y la textil Bellavista Tomé. En este últimocaso, en 1973 ECOM propuso un proyecto deinformatización integral de la fábrica textil quefue aprobado por la Asamblea de Trabajadoresde la empresa. El proyecto incluía tanto funcio-nes administrativas como de apoyo a la produc-ción.

26


El 11 en ECOM: La experiencia de uno de sus trabajadoresNN comenzó a trabajar en la Empresa Nacionalde Computación (ECOM) en el año 1971. Siendoaún estudiante de Ingeniería de la Universidadde Chile, su situación económica lo obligó a dejarsus estudios y aprovechó una oportunidad quese presentó para trabajar como operador de equi-pos periféricos del computador. Su primer día detrabajo consistió en vigilar el normal funciona-miento de una impresora 1403 de uno de loscomputadores IBM/360, evitando los atascos yalimentándola de papel que entonces se elabora-ba en hojas con prepicado y en formularios con-tinuos.

Por su buen desempeño y dedicación al trabajoasumió prontamente responsabilidades mayoresen la operación de los computadores de la em-presa y le correspondió supervisar sistemas com-putacionales que apoyaban la administración delas empresas del Estado y que se procesaban enalguno de los tres computadores IBM (uno de loscuales residía en Endesa). Eran los años del go-bierno del Presidente Salvador Allende y NN con-tribuía con su trabajo a apoyar entusiastamentela construcción del socialismo en Chile.

La empresa, tratando de diversificar la procedenciade sus equipos y evitar la dependencia de unúnico fabricante, adquirió un computador Bu-rroughs 3500 y encargó dos computadores fran-ceses CII (Iris-80 e Iris-60). La operación de losequipos de entonces era compleja y muy delicadapor lo que se requería actualización y entrena-miento permanente. El día 11 de septiembre de1973, NN, que vivía en la comuna de San Miguel,acudió muy temprano a un curso de capacitaciónque se realizaba en el edificio “Sol de Chile” en lacalle Huérfanos. Se extrañó que sus compañerosno llegaran, hasta que alguien le informó que seestaba produciendo un golpe de Estado.

Estando muy cerca de La Moneda, instintivamentese dirigió hacia allá y observó que estaba siendorodeada de tanquetas. Desde una de ellas se

disparó una ráfaga por lo que decidió regresaral edificio principal de ECOM. Las horas fueronmostrando la brutalidad del golpe y desde lasoficinas observó a militares sacando y apresandotrabajadores en los edificios cercanos, especial-mente en el Ministerio del Trabajo ubicado enla esquina de las calles Huérfanos y Morandé.

NN, junto a una veintena de funcionarios, lamayoría (pero no todos) simpatizantes del go-bierno de Allende, decidió quedarse y tratar deproteger y defender las instalaciones. El toquede queda duró varios días y la permanencia sehizo peligrosa y difícil. Cerraron las ventanas ydurante la noche apagaban las luces para nodespertar la atención de las patrullas militares.Para alimentarse tuvieron que aprovisionarsede tallarines desde un casino que se encontrabaen el último piso del edificio y los prepararonen una cocinilla. En una ocasión fueron sorpre-sivamente interrumpidos por el sonido de unmensaje que llegó a un terminal de télex, exi-giéndoles que reportaran la cantidad y la listade personas que permanecían en la empresa.

Decidieron no responder. La espera se hizo infruc-tuosa y se retiraron sigilosamente al levantarse eltoque de queda.

El regreso al trabajo fue muy tenso. NN decidiópresentarse, a pesar de que eran conocidas sussimpatías por el Gobierno de Allende. Algunaspersonas no regresaron y otras fueron despedidas.Esperando lo peor, NN fue gratamente sorprendidopor el encargado del equipo Burroughs 3500 que,conociendo su experiencia técnica, le ofreció tra-bajar en la operación de ese computador. NN acep-tó la propuesta y durante un par de años tuvo undesempeño que fue destacado y reconocido. Dehecho, llegó a estar a cargo de dos computadores3500, de los más grandes y sofisticados de la época.

Lamentablemente, esta historia no tuvo un finalfeliz. Uno de los computadores 3500 fue asignadoa una de las ramas de las fuerzas armadas, queexigió la expulsión de NN. En una reunión surrea-lista, el Gerente no encontraba la justificación paradespedir a un funcionario que tenía una impecabley muy destacada trayectoria laboral.

AGRADECIMIENTOS Y DEDICATORIAAl personal de las Bibliotecas de las Escuelas de Ingeniería y de Economía de la Universidad de Chile, de CORFO, del CongresoNacional y de la Biblioteca Nacional por facilitar el acceso a las fuentes escritas. Gracias también a Germán Munita y Óscar Sáez porla valiosa información acerca del Departamento de Investigación y Desarrollo y de la Subgerencia del Biobío. Finalmente, un especialreconocimiento a mi profesor Hugo Segovia (Q.E.P.D.) por su dise rtación en el año 2008 (en un acto de conmemoración de loscuarenta años de la creación de ECOM) y por una entrevista en 20 09. A su memoria dedicamos este artículo, personalizando enél, el gran aporte que realizó al país ECOM y sus trabajadores entre los años 1971 y 1973.


[20] Diario El Mercurio. “Convenio ENTEL-ECOM:Planifica Servicio de Transmisión y Teleprocesa-miento de Datos”. 27 de junio de 1973.

[21] ECOM. “Sistema generalizado de pago desueldos”. Actas Conferencia “Facilidades de pro-cesamiento electrónico de datos para empresasy organismo gubernamentales”. Junio 1973.

[22] ECOM. “Sistema normalizado de cuentascorrientes bancarias”. Actas Conferencia“Facilidades de procesamiento electrónico dedatos para empresas y organismo guberna-mentales”. Junio 1973.

[23] ECOM. “Sistema Contable Computacional”.12 de junio de 1972.

[24] ECOM. “Sistema contable”. Actas Conferen-cia “Facilidades de procesamiento electrónicode datos para empresas y organismogubernamentales”. Junio 1973.

[25] Letelier, Gabriel. “Diseño y Construcción deun Generador de Programas de Validación”. Me-moria para optar al título de Ingeniero Civil dela Universidad de Chile. 1975.

[26] Gamboa, Fernando. “Programación Automá-tica de Generadores de Programas y Analizado-res Sintácticos”. Informe para optar al título deIngeniero de Ejecución en Procesamiento de laInformación de la Universidad de Chile. 1974.

[27] ECOM. “Programa capacitación IRIS-80”.Actas Conferencia “Facilidades de procesamientoelectrónico de datos para empresas y organismogubernamentales”. Junio 1973.

[28] Sáez, Óscar. Comunicación personal. Junio2015.

[10] Diario La Nación. “El Censo, a las computa-doras”. 23 de abril de 1970.

[11] Instituto Nacional de Estadísticas. “XIV CensoNacional de Población y II de Vivienda 1970”.http://www.ine.cl/canales/usuarios/cedoc_online/censos/pdf/censo_1970.pdf

[12] OCOM; ECOM. “Proyecto Rol Único Nacionaly Registro Nacional de Población”. Agosto 1972.

[13] OCOM; ECOM; Subsecretaría de Justicia.“Antecedentes para la creación de un registroautomatizado de población en Chile”. Actas Se-minario “Sistemas de Información Adminis-trativos”, U. de Chile. Julio 1971.

[14] Stern, Pinchas; Duffau, Etienne. “Un proyectopiloto para la creación de un archivo depersonas”. Actas I Congreso Iberoamericano deInformática”. Buenos Aires, mayo – junio 1972.

[15] CORFO. “Proyecto Synco. Conceptos y Prác-tica del Control; una experiencia concreta: laDirección Industrial en Chile”. Febrero 1973.

[16] Presidencia de la República. “Mensaje delPresidente Allende ante el Congreso Pleno”.Páginas 412-415. 21 de mayo de 1973.

[17] Medina, Eden. “Revolucionarios ciberné-ticos”. Editorial LOM. 2013.

[18] ECOM. “Proyecto Synco – SistemaCyberstride”. Actas Conferencia “Facilidades deprocesamiento electrónico de datos para empre-sas y organismo gubernamentales”. Junio 1973.

[19] Diario El Mercurio. “Cinco nuevas reparticio-nes creó Vuskovic en la CORFO”. 30 de abril de1973.

REFERENCIAS[1] Álvarez, Juan. “Empresa Nacional deComputación: antecedentes, creación yprimeros años”. Revista Bits de Ciencia N° 9,Primer Semestre 2014.

[2] Marfán, Álvaro; Friedmann, Efraín; Sáenz,Ricardo. “Experiencia en el sector público deChile sobre el procesamiento electrónico dedatos con computadores electrónicos”. ActasI Conferencia Latinoamericana de autoridadesgubernamentales de Informática”. BuenosAires, abril 1970.

[3] Diario La Nación. “ECOM: nuevo nombrepara una empresa que surge”, 16 de enero de1971.

[4] CORFO. “Información presupuestariaempresas e institutos filiales CORFO Año 1972”.Julio 1971.

[5] Presidencia de la República. “Mensaje delPresidente Allende ante el Congreso Pleno”.21 de mayo de 1972.

[6] ACUC. “Revista de la Asociación Chilena deCentros Universitarios de Computación”. N°1,julio 1973.

[7] ECOM. “Características principales de lossistemas IRIS-80 e IRIS-60”. Actas Conferencia“Facilidades de procesamiento electrónico dedatos para empresas y organismogubernamentales”. Junio 1973.

[8] EMCO. “EMCO Capacitación”. 1970.

[9] Segovia, Hugo. “Gerencia de Ingeniería,Gerencia de Investigación y Desarrollo 1971-1973”. Presentación en acto “A 40 años de lacreación de la Empresa Nacional deComputación”. DCC, U. de Chile, diciembre2008.

27

28

"No me parece mal ser maestro chasquilla, desatornillador en manoandar arreglando entuertos con mucha imaginación. De hecho esa esuna de mis formas de ganarme la vida. La pregunta es si podremosdesarrollar este país hacia el futuro, con competitividad internacional,en base a pura artesanía. Ojalá que cuando la tecnología nacional sehaga necesaria al borde de una catástrofe, podamos encontrarla e nalgún lado".

José Miguel Piquer, Columna en Revista Informática, 1996.

La Industria del Softwarey TIC en Chile

29

JOSÉ MIGUELPIQUERProfesor Asociado Departamento de Ciencias de laComputación, Universidad de Chile. Director Técnico deNIC Chile y socio fundador de la consultora IT-Talk Ltda. yde E-voting Chile SpA, dedicada a servicios de votaciónelectrónica. Entre 2011 y 2013, fue el encargado deldesarrollo de proyectos científicos de transferencia en INRIAChile, centro de excelencia internacional, donde se buscaestablecer un puente entre la investigación y el [email protected]

Por más de veinte años he albergado la esperan-za que la industria TI chilena un día se transformeen motor del desarrollo y posicione a Chile enla lista de los países líderes en generación desoftware en el mundo. A comienzos de los no-venta, mi generación de profesores estaba reciénllegando de sus doctorados a instalarse en lanaciente democracia chilena, y soñamos quepodíamos cooperar con la industria para lograreste liderazgo [1]. Fue obviamente una ilusiónpasajera y un sueño muy inocente, pero siemprehe creído que, en el largo plazo, es posible: nues-tras universidades forman profesionales de nivelmundial, nuestros departamentos de computa-ción son de los mejores en América Latina yestán en una buena posición en el mundo. Ade-más, llevan haciendo esto ya por muchos años,creando varias generaciones de profesionales.Entre tanto, el país se ha desarrollado enorme-mente, y tenemos varias industrias que hoy com-piten por los primeros lugares en el mundo.

Es decir, debiera estar todo lo necesario para eléxito: una oferta de profesionales y de investi-gación entregada por buenas universidades, yuna demanda de alto nivel y complejidad basadaen industrias líderes a nivel mundial. Es el planque estuvo en la base de la creación de los clusterpropuestos por el Consejo Nacional para la In-novación en 2005, y que buscaba impulsar lainnovación y el emprendimiento para cambiarel modelo de desarrollo del país, pasando de lasmaterias primas a productos con valor agregado.Aunque las TI nunca fueron un cluster, justamen-te porque nuestra industria no es una de las quecompite a nivel mundial, siempre estuvieron enla lista de lo que llamaron "tecnologías habilitan-tes", cuya demanda debía aumentar mucho aldesarrollar los verdaderos cluster.

Al mirar el escenario actual, diez años de esfuer-zos en innovación en Chile no parecen haberdado los frutos esperados. Seguimos siendo elmismo país esclavo de los recursos naturales ysus precios, como lo demuestra la desaceleracióneconómica que sufrimos desde 2014, simple-mente debido a una baja sostenida en el valorinternacional de los commodities. Esto se reflejaigualmente en la industria TI chilena: nuestrosgrandes proveedores son muy buenos integra-dores de sistemas, que hoy funcionan comosocios estratégicos de las empresas al mantenersus sistemas operando, pero casi no existenejemplos de servicios o desarrollos de softwareinnovadores que compitan a nivel mundial. ¿Te-nemos alguna esperanza aún?

Algunas luces quedan en el sistema, que parecenindicar que Chile no ha perdido todas sus opor-tunidades. Veamos las razones que nos dan es-peranzas:

1) La exportación de servicios TI ha crecido enlos últimos años, posicionando a Chile comopunto de destino de inversiones interesantes[2], así también como un país plataforma denearshoring con varias transnacionales instalan-do sus centros de desarrollo TI e incluso algunoscentros de I+D en Chile. Aunque los númerostodavía son pequeños (100 millones de dólaresen 2010) parece una tendencia al alza importan-te. Esta tendencia, de producir software para elmundo, es muy positiva, dado que uno de losgrandes frenos a la industria local siempre hasido la falta de sofisticación de los clientes locales.No es posible desarrollar software de clase mun-dial para un cliente que quiere que le amarrecon alambritos un sistema a la rápida (y eso eslo que está dispuesto a pagar).



2) La demanda por aplicaciones móviles volvióa generar un mercado emergente, parecido a loque era la demanda por aplicaciones web en losnoventa. En esos mercados siempre nos hemosmovido bien, porque requieren productos rápi-dos y sucios, pero que funcionen bien. Esta vezno fue la excepción (y creo que Startup Chileayudó mucho a esto). El tema es que Chile apa-rece en las listas de países donde es bueno man-dar a hacer aplicaciones móviles, y hemos ganadocierta fama en ese nicho. Lo difícil es mantenerese empuje en el tiempo, y saber ir migrandohacia sistemas más maduros y estables, dondela improvisación y la suciedad ya no son acepta-bles.

3) He visto a varios de nuestros exalumnos invo-lucrados en emprendimientos cada vez más so-fisticados, innovadores y riesgosos. En los viejostiempos fueron Tecnonautica (comprado porTelefónica), Mapcity, Acepta.com y Atentus. Hoyexisten muchos más como esos, en juegos paramóviles, medios de pago, y varios otros. De todoeste ecosistema de gente innovadora, algo muybueno terminará saliendo.

Tal vez era necesario que pasara el tiempo, quelos grupos se consolidaran, que el país madurara.Pero estamos de vuelta en lo mismo: una tem-prana infancia de una industria emergente queno parece lograr consolidarse nunca. O tal vezuno de estos días…

Ojalá que, de todos estos proyectos, salga eseejemplo de éxito que necesitamos, que demues-tre que se puede desarrollar tecnología de nivelmundial en este perdido lugar al fin del mundo(¡pero con buena conexión a Internet!).

REFERENCIAS

[1] Baeza-Yates, R. A., Fuller, D. A., Pino, J. A., Goodman, S. E. (1995). Computing in Chile: the jaguar of thePacific Rim?. Communications of the ACM, 38(9), 23-28.

[2] R. A. Hernández, N. Mulder, K. Fernandez-Stark, P. Sauvé, D. L. Giral, F. M. Navia (Eds.), Latin America’semergence in global services (pp. 177–195). Santiago: UN, 2014.

30

En todo este sueño, el Departamento de Cienciasde la Computación (DCC) de la Universidad deChile hizo sus aportes: formamos muy temprana-mente profesionales en tecnologías innovadorase importantes, ayudamos en las conexiones aInternet del país y hemos difundido las tecnolo-gías relevantes cada vez que podemos. Sin em-bargo, me parece que podríamos hacer muchomás, incentivando a nuestros estudiantes a em-prender, apoyando el despliegue de nuevas tec-nologías en el país, y acompañando a la industriaen el difícil camino de la innovación tecnológica.

Hoy el DCC no se ve muy presente en los esfuer-zos de transferencia que la misma Facultad deCiencias Físicas y Matemáticas de la Universidadde Chile ha comenzado, como el área de innova-ción del Proyecto 2030 o proyectos concretosinternos como el Fab Lab. En algún momentotuvimos roces con la Facultad porque nuestrosacadémicos hacían muchos proyectos aplicadosy poca investigación. Parece que ahora se invir-tieron los roles, tal vez se nos pasó la mano eninsistir tanto en las publicaciones internacionales,el asunto es que nadie parece tener el tiempoque estos esfuerzos requieren.

Cooperar con las empresas y con los emprende-dores no es fácil ni eficiente. El entorno chilenoes todavía adverso a la innovación y al riesgo,nadie cree que realmente hay valor en desarrollartecnología y arriesgarse en áreas inexploradas.Por lo tanto, no existe ningún incentivo concretopara ir en esa dirección, siendo lo normal hoydormirse en los laureles y revisar cuál es el próxi-mo concurso CONICYT donde postular. Si norompemos esa rutina, demoraremos veinte añosmás en tener una verdadera industria TI.

31


El mercado tecnológico chileno es uno de los más desarrollados deLatinoamérica, representando un 1,7% del PIB, según informes recientesde IDC. No obstante, su potencial de crecimiento es aún extenso siconsideramos que en los países desarrollados, el porcentaje invertidoen tecnología llega al 2,5% del PIB.

32

En Chile, la industria del software está formadapor PyMEs que en general realizan venta deproductos tecnológicos e integración, pero noalta tecnología, que es lo que en Gechs comoAsociación estamos buscando cambiar. Históri-camente hemos sido un gremio de servicios,pero en el último año, gracias a un proyectoejecutado junto a Corfo, denominado SaaS Ge-neration, estamos buscando pasar de ser desa-rrolladores a medida a ser desarrolladores de“productos” tecnológicos que se puedan vendercomo servicios escalables a nivel global.

ESTRUCTURA DELA INDUSTRIA TICEn Chile, de las aproximadamente 950 mil em-presas registradas en el Servicio de ImpuestosInternos, hay 4.700 con giro TIC, de las cualeshay desde microempresas que se dedican a ven-der insumos para equipos, hasta empresas másformales que desarrollan software.

De esas 4.700, estimamos que deben haber unas1.600 empresas que realizan servicios mássofisticados, tanto servicios tecnológicos, comodesarrollo a medida o empresas de basetecnológica, que son las que pueden crecerexponencialmente si logramos abrirnos a nuevosmercados. El modelo de Software as a Service(SaaS), que estamos promoviendo entre losmiembros de la Asociación, así como en jóvenesinnovadores y emprendedores, va en esa línea.

MARÍA EUGENIARIQUELMEIngeniero en Comercio Internacional, con Diplomado en Gestión y Desarrollo de Negocios. Cuenta con 18 añosde experiencia en gestión de Asociaciones Gremiales, actualmente dirige la Asociación de Empresas de Softwarey Servicios, GECHS (9 años), siendo responsable de las relaciones institucionales de la Asociación con el sectorgubernamental, privado, académico y medios de comunicación, a ef ecto de contribuir a una mejor imagen,posicionamiento y concreción de los objetivos del sector de las Tecnologías de la Información. Interactúa conlas empresas socias y representa sus intereses. Participa en act ividades a nivel nacional e internacional paragenerar redes. Posee amplio conocimiento de la industria, lo que le ha permitido gestionar diversos proyectosasociativos para empresas tecnológicas. Ha preparado y participa do en diversos eventos de networking ymeetup, con invitados nacionales e [email protected]

FIGURA 1.COMPOSICIÓN DE LA INDUSTRIA TECNOLÓGICA CHILENA.


investigación, difusión, promoción y desarrollode los distintos aspectos relacionados con lasciencias tecnológicas.

NUESTRO DESAFÍOEn Gechs aspiramos a que Chile sea la Californiade Sudamérica, con servicios más sofisticados.

Económicamente contamos con empresas ex-tractivas que son agregadoras de valor, perotenemos que generar una industria creadora devalor, para atraer a profesionales TIC que seancapaces de cambiar nuestra realidad.

Según datos de IDC, de las empresas TIC enChile, un 95% de ellas son nacionales y un 5%son de origen internacional, principalmente enel segmento de mayor tamaño.

Al desagregar la Industria tecnológica chilena,podemos ver que está compuesta por los sub-sectores: Software con un 9,3% de participación,Servicios con un 27,1% y Hardware, el más rele-vante, con un 63,6% (Figura 1).

Para contar con una industria tecnológica mejormapeada y con datos estadísticos certeros –pueshoy ninguna entidad los genera de manera sis-temática– es que comenzamos a trabajar en unproyecto estadístico con País Digital, fundaciónsin fines de lucro que tiene como finalidad la

Hardware 63,60%

Software 9,30%

Servicios 27,10%

33


En esta línea, buscamos hacer crecer a las em-presas de tecnología para que mediante la aper-tura de mercados internos y externos facturenmás; para lo cual contamos con una mesa denegociación con el Gobierno y otra de interna-cionalización, en la cual estamos generandodistintas misiones a otros países, para mostrarlo que hacen nuestras empresas y empaparnosde experiencias internacionales.

Hemos dicho que la industria de las tecnologíasdigitales y sobre todo el software tiene un granpotencial, que todavía nos falta por desarrollar.Todos tenemos claro, partiendo por el Ministeriode Economía, la importancia del uso de las tec-nologías de la información como motor de desa-rrollo de las economías modernas y es por esoque actualmente está en curso el Programa Es-tratégico de Gobierno para la Industria Nacionalde TIC y Servicios Globales que busca generarcapacidades de empaquetamiento y escalamien-to, de manera de convertir las soluciones parti-culares actuales en productos que puedan sercomercializados a nivel mundial.

con un 8% y la Región de Concepción con un 4,7%de las empresas. Sin duda este es un aspecto quedebiéramos mejorar como país, poniendo másénfasis en generar apoyos para emprendimientose innovaciones que destaquen en regiones, dadoque se han visto ejemplos muy buenos de proyec-tos tecnológicos y aplicaciones (por ejemplo deSmart Cities) provenientes de esas regiones.

En lo referido a la participación del mundo feme-nino en la industria TIC, durante 2014, esta parti-cipación no alcanzó el 5%. Por ello resulta funda-mental identificar y visibilizar las barreras culturales,que no están permitiendo que las mujeres se mo-tiven a formar parte de esta industria, que se ca-racteriza por ser meritocrática.

Esperemos que este año la participación femeninacrezca a tasas muchísimo mayores, tanto por ladiversidad de opciones laborales que hay en estemundo tecnológico como por la fuerte necesidadde contar con las habilidades blandas que otorganlas mujeres a las distintas áreas laborales.

El Programa SaaS Generation, cofinanciado porCorfo, se desarrollará durante todo el 2015 yconsiste en buscar nuevas oportunidades decrecimiento de nuestra industria, a través deldesarrollo de capacidades en modelos de nego-cio diferentes a los que caracteriza a la industriachilena del software (basada en la tecnología amedida). De esta manera, las empresas partici-pantes, podrán capturar mejor el valor de sutrabajo, más allá del mercado nacional, de modode convertir a Chile en un líder en el desarrollotecnológico. Todo ello a través de la adquisiciónde capacidades en el desarrollo de Software asa Service para crear negocios escalables a nivelinternacional.

En cuanto a otros desafíos que nos restan porvencer, dos de los principales son descentralizarla industria TIC y aumentar el porcentaje de par-ticipación femenina.

La industria TIC se encuentra altamente concen-trada en la Región Metropolitana con un 87% delas empresas, seguida por la Región de Valparaíso

34


35

MARÍA CECILIABASTARRICAProfesora Asociada Departamento de Ciencias de la Computación,Universidad de Chile.PhD Computer Science and Engineering,University of Connecticut; Magíster en Ciencias de la Ingeniería,Universidad Católica de Chile; Ingeniera en Informática,Universidad Católica del Uruguay. Líneas de investigación:Ingeniería de software - arquitectura de software, líneas deproductos de software, mejora de procesos de software, desarrollode software dirigido por [email protected]

SERGIOOCHOAProfesor Asociado Departamento de Ciencias de la Computación,Universidad de Chile. Doctor en Ciencias de la Computación,Pontificia Universidad Católica de Chile; Ingeniero de Sistemas,UNICEN, Argentina. Líneas de investigación: SistemasColaborativos, Ingeniería de Software -arquitectura de software,mejora de procesos en micro y pequeñas empresas de software,ingeniería de requisitos, educación apoyada con tecnologí[email protected]

MAIRAMARQUESCandidata a Doctora en Ciencias mención Computación yMagíster en Ciencias mención Computación, Universidad deChile; Ingeniera Química de la Universidad Federal de São Carlos,Brasil. Líneas de investigación: Ingeniería de Software - educaciónen ingeniería de software, procesos de software y [email protected]


DANIELPEROVICHProfesor Adjunto de Jornada Parcial Departamento de Cienciasde la Computación, Universidad de Chile. Doctor en Cienciasmención Computación, Universidad de Chile. Magíster enInformática e Ingeniero en Computación, Universidad de laRepública, Uruguay. Líneas de investigación: Ingeniería deSoftware, Arquitectura de Software, Procesos de Desarrollo yDesarrollo Dirigido por [email protected]

36

JOCELYNSIMMONDSProfesora Asistente Departamento de Ciencias de laComputación, Universidad de Chile. Doctora en ComputerScience, University of Toronto, Canadá; Master of Science enComputer Science, Vrije Universiteit Brussel, Bélgica y ÉcoleDes Mines de Nantes, Francia. Líneas de Investigación: Análisisy Diseño de Software, en especial aplicaciones Web y móviles;Validación y Verificación de Sistemas; Educación Apoyada conTecnología, y cómo atraer mujeres a Ingeniería y [email protected]


ALCIDESQUISPEProfesor Asistente Departamento de Ingeniería Informática,Universidad de Santiago de Chile. Doctor en Ciencias menciónComputación, Universidad de Chile; Ingeniero de Sistemas,Universidad Católica de Santa María, Perú. Líneas de investigación:Ingeniería de Software - ingeniería de requisitos, procesos desoftware, e investigación empírica en ingeniería de [email protected]

MOTIVACIÓNNo hay un consenso general acerca de cómoclasificar a las empresas de software según sutamaño. En este artículo llamaremos microem-presa a aquellas con hasta 10 empleados, pe-queñas a las que tienen entre 11 y 50 empleados,medianas si tienen entre 51 y 100, y grandes aaquellas con más de 100 empleados. La principalfuerza laboral de la industria del software mun-dial está concentrada en las micro, pequeñas y

medianas empresas de software, y particular-mente en las dos primeras. Diversos reportesindican que en Chile más del 40% de las empre-sas de software tiene menos de 10 empleados(o sea, son microempresas) [Inn03], en Brasil el70% corresponde a micro o pequeñas empresas[Wan06], en Canadá [Lap08] y en Estados Unidos[Fay00] las microempresas representan el 50%y el 78% de las organizaciones desarrolladoras

de software respectivamente. En el caso de Es-tados Unidos, el 95% de ellas tiene menos de 50empleados [Ara10].

La realidad de las micro y pequeñas empresasde software es diferente a la de las medianas, yesta diferencia es aún mayor en relación con lasgrandes. Las primeras tienden a ser más vulne-rables, pues usualmente tienen poco capital deriesgo y, por lo tanto, están obligadas a aceptarcasi cualquier proyecto que se les presente, in-dependientemente de su nivel de riesgo y delbeneficio económico potencial que les represen-te.

Dado que la mayoría de las empresas nacencomo micro o pequeñas organizaciones, cuandoéstas llegan a ser medianas es porque ya estánconsolidadas. La mayoría de éstas hace softwarepara nichos específicos y tienen procesos y per-sonal estables. Esta realidad también está pre-sente en las grandes empresas de software; sinembargo estas últimas son las únicas capacesde enfrentar el desarrollo de proyectos grandes,dada su capacidad financiera y de desarrollo desoftware. Esto también les permite escoger losproyectos que les son más atractivos, tanto desdeel punto de vista tecnológico como económico.

En este sentido, vemos que la mayor parte de laindustria de software chilena, o sea las micro ypequeñas empresas, es vulnerable. Por lo tanto,si se pretende que la industria del software tengaun impacto país, es en estas empresas donde sedeben concentrar los mayores esfuerzos. Si con-sideramos que el desarrollo de software es unaactividad transversal que permite que diversasáreas puedan brindar más y mejores servicios(por ejemplo, salud, sector productivo, seguri-dad, comercio y ocio), la mejora de la industriadel software redundará directamente en la me-jora de estos servicios y, por lo tanto, en el bien-estar de nuestra sociedad.

En las siguientes secciones se analizan los dife-rentes aspectos vinculados al desarrollo de soft-ware, y los desafíos que enfrenta la industria enestos ámbitos. La información provista en esteartículo fue obtenida principalmente a partir de

37


En el caso de las empresas medianas la situaciónes usualmente distinta, pues éstas trabajan ennichos o en productos específicos sobre los cua-les tienen un conocimiento más profundo. Porlo tanto, sus proyectos tienden a ser menosriesgosos y además estas empresas tienen ciertacapacidad de elegir, no sólo porque ya han cons-truido una cartera de clientes, sino porque tienenrespaldo financiero. Algo similar sucede con lasempresas grandes, que claramente tienen unaposición privilegiada en el mercado de softwareactual. Ellas son más apropiadas para abordargrandes proyectos, que les aseguran la susten-tabilidad por varios años.

LOS PROCESOSDE DESARROLLOAproximadamente el 80% de las PyMEs de soft-ware declaran tener definido su proceso organi-zacional de desarrollo de software, aunque sóloel 50% dice aplicarlo. Las empresas de menosde cinco años desarrollan proyectos de tres me-ses en promedio, y las de más de cinco añostrabajan en proyectos un poco más grandes(cinco meses en promedio). Estos desarrollosestán enfocados esencialmente en la construc-ción del software en sí, reduciendo al máximoposible las actividades relativas a la gestión delproyecto. Esta realidad fue constatada duranteel desarrollo del proyecto Tutelkán [Val10], elcual buscó ayudar a las PyMEs de software chi-lenas a definir sus procesos organizacionales.

LOS DESARROLLADORESY LOS EQUIPOS DETRABAJO

De acuerdo al estudio recientemente realizado,prácticamente el 50% de los desarrolladorestiene entre 25 y 30 años, y el 30% tiene entre 30y 35 años. Por lo tanto son gente joven, con pocaexperiencia, pero con conocimiento sobre lasnuevas tecnologías. Estas personas cuestan me-

nos, son relativamente fáciles de reclutar y tienengran entusiasmo por surgir profesionalmente.

La cantidad de graduados de carreras de Com-putación e Informática en Chile parece estar pordebajo de las necesidades del mercado. Estedéficit de desarrolladores ha atraído a muchosprofesionales de países vecinos.

Usualmente, cuánto más chica es la empresa,menos puede pagar por sus desarrolladores, ypor lo tanto, la selección de personal que puederealizar es más acotada y menos exigente[Cole05, Mond05, Rich07]. En este sentido, lasmicro y pequeñas empresas son las más desfa-vorecidas, dada su limitada capacidad financiera.

En general estas empresas declaran que sus tra-bajadores participan en un solo proyecto a lavez, aunque aproximadamente el 25% indica quepueden llegar a trabajar hasta en cuatro proyec-tos en paralelo. Esto atenta contra la productivi-dad de los trabajadores y también de la empresa.

LOS PRODUCTOSDE SOFTWARELa calidad de los productos de software dependede muchos factores. Sin embargo, las empresasde nicho o bien aquellas que trabajan en pro-ductos puntuales tienen ventajas importantesrespecto a las que desarrollan software para unámbito más general, como es el caso de las microy pequeñas empresas de software. Las empresasde nicho usualmente cuentan con el conoci-miento tanto del propio del negocio, como delos aspectos técnicos requeridos para construirel producto. Esto les permite desarrollar softwaresólido desde el punto de vista técnico, y efectivoen la resolución de los problemas abordados.

Por su parte, las empresas que trabajan sobreproductos específicos también cuentan con estaventaja comparativa, pero además tienen laposibilidad de ir mejorando sus productos enforma evolutiva, lo cual hace que sus proyectostengan baja incertidumbre y alto impacto.

un estudio reciente, sobre las micro, pequeñasy medianas empresas (PyMEs) de software chi-lenas, el cual se desarrolló como parte del pro-yecto GEMS 1.

LOS PROYECTOSA REALIZAR Y LACAPACIDAD DE ELEGIRUn estudio realizado por Quispe y otros [Qui10]en micro y pequeñas empresas de software chi-lenas, muestra que más del 80% de los proyectosque ellas realizan parten con objetivos pococlaros y, por lo tanto, con un riesgo muy alto.Esto se ve reflejado también en la baja efectivi-dad que tienen las soluciones que éstas imple-mentan (solamente el 25-30% terminan siendoefectivas).

La poca claridad en el alcance y objetivos de losproyectos se debe a que muchos de estos nacena partir de un problema que se requiere solucio-nar con urgencia. Por lo tanto, el cliente no tuvotiempo suficiente de pensarlo en profundidady detalle, y en consecuencia, la solución se vadescubriendo durante la ejecución del proyecto.Por otra parte, es poco probable que las microy pequeñas empresas de software conozcanbien el nicho de negocio en el que se enmarcael problema del cliente, por lo tanto general-mente es poco lo que éstas pueden hacer porayudar a descubrir la solución al problema plan-teado. Dada la premura que usualmente hay porcontar con la solución, los proyectos terminandesarrollándose contra reloj, con poco análisisy poca ingeniería. Lamentablemente, estas em-presas de software tienen una casi nula capaci-dad de elegir sus proyectos, por lo que a pesarde las condiciones adversas, igual deben aceptardesarrollarlos. De otra forma ponen en riesgosu supervivencia. En un reciente estudio com-probamos que alrededor del 30% de las microy pequeñas empresas tienen menos de cincoaños de antigüedad, mientras que un poco másdel 30% tiene entre cinco y diez años. Esto indicaque no muchas pequeñas empresas subsistenfácilmente en el tiempo.

1 http://www.dcc.uchile.cl/gems/


38

La otra cara de la moneda la constituyen losproductos desarrollados por las micro y pe-queñas empresas que desarrollan software paracualquier nicho de mercado, dado que no tienenla capacidad de elegir sus proyectos. Estas em-presas usualmente cuentan con conocimientotécnico, pero no del ámbito de negocio en elque se insertan sus proyectos, ya que estos ám-bitoss son muy diversos. Esto implica que aunquesus productos sean técnicamente buenos, espoco probable que impacten en forma significa-tiva las organizaciones que reciben dichos pro-ductos. Si a esto le sumamos el escaso margende tiempo y presupuesto con las que estas em-presas operan, es muy difícil poder garantizar lacalidad del producto final obtenido. Dado queeste tipo de empresa son la mayor parte de laindustria del software tanto en Chile como enel mundo, es explicable entonces por qué lamayoría de los desarrollos de software son tanpoco efectivos.

LAS OPORTUNIDADESPARA GENERAR UNIMPACTO PAÍS

Hay diversas oportunidades de mejora de lafuerza laboral en el ámbito del desarrollo desoftware. Sin embargo, la falta de políticas gu-bernamentales en este sentido hace que cadaempresa busque la forma de solucionar suspropios problemas, utilizando métodos ad-hocque no aportan demasiado a la mejora de laindustria de software local.

Una forma posible de aumentar el número degraduados en carreras de Computación e Infor-mática, sin sacrificar la calidad de los mismos,radica en focalizar la formación de los mismos,reduciendo así la duración de los programas talcomo se ha hecho en Europa. Otra posibilidades fomentar la educación continua, facilitandola actualización periódica y focalizada de nuevosconocimientos, por parte de desarrolladores quepodrían estar comenzando a salir del mercadopor la obsolescencia de su conocimiento. Dada

en Chile 2003. White Paper, 2003, URL:h t t p : / / w w w . e s t r a t e g i a d i g i t a l . g o b . c l/files/DIAGNOSTICO%20INDUSTRIA%20TIC%202003.pdf

[Lapo08] C.Y. Laporte, S. Alexandre, A. Renault.Developing International Standards for VerySmall Enterprises. IEEE Computer, Vol. 41, No. 3,pp. 98-101, Mar. 2008.

[Mond05] O. Mondragon. Addressinginfrastructure issues in very small settings. FirstInternational Research Workshop for ProcessImprovement in Small Settings, Pittsburgh, PA,2005.

[Quis01] A. Quispe, M. Marques, L. Silvestre, S.F.Ochoa, R. Robbes. Requirements EngineeringPractices in Very Small Software Enterprises: ADiagnostic Study. Proceedings of the XXIXInternational Conference of the ChileanComputer Science Society, pp. 81-87. IEEE Press.Antofagasta, Chile, Nov. 15-19, 2010.

[Rich07] I. Richardson, C. G. von Wangenheim.Why Are Small Software Organizations Different?IEEE Software, Vol. 24, No 1, pp. 18–22, Jan./Feb.2007.

[Ryan15] K. Ryan. The experience of the IrishSoftware Sector – Successes, Failures and LessonsLearned. Keynote Speech at the ComputerScience Department of the University of Chile.May 29th, 2015.

[Vald10] G. Valdés, H. Astudillo, M. Visconti, C.López. The Tutelkan SPI Framework for SmallSettings: A Methodology Transfer Vehicle.Proceedings of EuroSPI’2010: Communicationsin Computer and Information Science, Vol. 99,pp. 142-152, 2010.

[Wang06] C. G. von Wangenheim, A. Anacleto,C. F. Salviano. Helping Small Companies AssessSoftware Processes. IEEE Software, Vol. 23, No 1,pp. 91 – 98, Jan./Feb. 2006

REFERENCIAS

[Ara10] J. Aranda (2010) Playing to the strengthsof small organizations. 1st Workshop onRequirements Engineering in Small Companies(RESC2010), at the 16th International WorkingConference on Requirements Engineering:Foundation for Software Quality (REFSQ’10),Essen, Germany, 2010.

[Ben08] J.M. Benavente, C. Kulzer. Creación ydestrucción de empresas en Chile. Estudios deEconomía [online]. 2008, vol.35, n.2, pp. 215-239.

[Cole205] K. Coleman, P. Larsen, M. Shaw, M.V.Zelkowitz. Software Process Improvement inSmall Organizations: A Case Study. IEEE Software,Vol. 22, No. 6, pp. 68-75, Nov./Dec. 2005.

[Gech08] GECHS AG y Escuela de Ingeniería dela Universidad de Viña del Mar. Sexta versión delEstudio Diagnóstico de la Industria Nacional deSoftware y Servicios, 2008.

[Inn03] Programa CHILE INNOVA. Diagnósticode la industria de tecnologías de la información

39


la velocidad a la que avanza la tecnología, losperíodos de caducidad del conocimiento se vuel-ven cada vez más cortos.

En este sentido existe una oportunidad real derobustecer la industria local de software y gene-rar un impacto país. Sin embargo, esto requiereasumir compromisos por parte de las empresas,los profesionales involucrados, el gobierno y lasinstituciones que forman a estos profesionales.Un ejemplo a seguir es la iniciativa llevada a cabopor Irlanda, la cual generó en menos de quinceaños una industria de software capaz de compe-

tir a nivel global [Ryan15], pero en nichos espe-cializados. En ese sentido, enfocarse en el desa-rrollo de software para nichos específicos podríaayudar a la industria chilena a mejorar su com-petitividad, tanto en la región como a nivel glo-bal.

Enfocarse en la implantación y mejora de proce-sos, pero de cara a las PyMEs, podría traer gran-des beneficios a la industria local. Muchas em-presas buscan alcanzar certificacionesinternacionales que están pensadas para com-

pañías que compiten a nivel global, y que no lesayudan a las PyMEs a ser más competitivas. Porlo tanto, cualquier esfuerzo invertido en esesentido tendrá poco o ningún impacto en lasupervivencia de la mayor parte de la industriachilena del software. Es tiempo de comenzar amirar hacia adentro, y también a nuestros veci-nos, buscando identificar recetas para el éxitoque puedan ser replicadas en Chile. En este sen-tido, la academia, la industria y el gobierno tienena la mano la oportunidad de trabajar juntas paragenerar un impacto país.

40


Quizás algunas de las referencias que se mencionan en este artículosólo sean memorables para los que nos peinamos con canas blancas.Desde ya le pido disculpas a las jóvenes mentes que lean este texto.Aun así deseo aportar a la conversación sobre esta interesante historiaque incluye integración de los data scientists, utilización de datosabiertos y la evolución de plataformas tecnológicas, entre otr osentremeces.

41

PABLOGARCÍAGerente de Investigación y Arquitecto Jefe de TelefónicaInvestigación y Desarrollo de Chile. Anteriormente sedesempeñó como arquitecto principal en Microsoft durantemás de una década y anteriormente como líder técnico ydirector de la empresa Urudata. Es profesor de Programación,Estructuras de Datos y Algoritmos para el Programa deDesarrollo de las Ciencias Básicas de Uruguay. Es Máster enComputación y sus áreas de interés principales son laautomatización de procesos y el procesamiento de secuenciasplanas de [email protected] / @pc_garcia


Hace algunos años vi una presentación de JimGray –un científico que la mayoría de la genterecuerda por sus trabajos en transacciones distri-buidas o por el ACID test–, donde trataba de di-fundir un concepto que había expuesto en laAcademia de Ciencias Americana, en un discursoante el Congreso. En esa charla, él hablaba que laciencia había pasado por varios paradigmas.

El primero, que supuso un nuevo mecanismo deavance sustancial para la ciencia, lo establecióGalileo con el establecimiento de la ciencia expe-rimental. El segundo es la de la ciencia teórica.Ésta aparece con el trabajo de Newton sobre losplanetas, el que establece que en su movimientode traslación estos recorrían áreas iguales en tiem-pos iguales.

Luego, la teoría atómica nos ayudó a establecerel paradigma de las simulaciones. En ello primerose teorizaba, luego se construía una simulación yposteriormente se la contrastaba con el experi-mento. Finalmente, ya en nuestros días, llegamosa un nuevo paradigma, caracterizado por el volu-men enorme de datos. Fuentes como el secuen-ciamiento de ADN, la ciencia del clima y la tele-metría de muchísimos dispositivos conectados,hace que la aplicación de técnicas computaciona-les de descubrimiento de patrones, establezca unnuevo paradigma para el avance de la ciencia. Aeste nuevo paradigma podemos llamarle la Cien-cia de los Datos o en su acepción anglosajona:Data Science.

Ese nuevo paradigma ya traspasó las fronteras dela ciencia y hoy vemos una enorme curiosidaddentro de las empresas por mutar su estrategiade datawarehousing a un modelo que los alejede los costosísimos procesos de Extracción, Trans-

formación y Carga, eliminando la Transformacióny cargando los datos en bruto, aplicando luegofuerza de procesamiento para transformarlos almomento de analizarlos.

Como todo en la vida, este nuevo paradigma tieneventajas y desventajas. La principal utilidad es quela tecnología que se usa para estos procesos, enel día de hoy, es un commodity. También se haconvertido en un commodity el tener enormescapacidades de almacenamiento y de procesa-miento on-demand, a precios ridículamente bajos,aunque esto es la parte menos importante de laecuación.

Lo que hoy complica es que el equipo de BusinessIntelligence (BI) no puede hacer la transición deordenador de la información a data scientist, siendoéste el dilema en que se encuentran hoy las orga-nizaciones: todos miran los reportes de las consul-toras como Gartner, y muchos desean abordareste tema dentro de su organización, pero seencuentran con que los data scientists son pocosy a la mayoría no les gusta hacer reportes sofisti-cados de marketing.

DATA SCIENTISTSINTEGRADOS ALNEGOCIOPara aplicar Data Science hay que dejar claro queesto implica muchos requerimientos, pero pode-mos establecer algunas bases mínimas, tales co-mo: saber procesar grandes volúmenes de datos,

42


saber analizarlos en forma rigurosa, comprenderla relevancia estadística de los resultados obtenidosy saber del negocio para poder interpretar losresultados.

Hace unos años atrás hice un Magíster en Bioinfor-mática, y cuando tomé las materias electivas delárea biológica no me pareció relevante tomar Evo-lución. Sin embargo, al avanzar en la maestría, mepasó que los biólogos descartaban rápidamenteresultados aplicando la teoría de la evolución conun razonamiento que resultaba muy difícil de for-malizar. Era su conocimiento de cómo cambianorganismos y poblaciones, influenciados por laevolución, lo que les permitía rápidamente descar-tar un grupo de resultados que parecían matemá-ticamente relevantes, y concentrarse en los quetenían sentido biológico.

Me refiero con esto a que, para poder aplicar téc-nicas y conocimiento de estadísticas y machinelearning en el procesamiento de bases de datosde un negocio y entregar algo útil como salida, senecesita conocer del negocio en particular. Nobasta simplemente con traer un experto y que élrealice el reporte, es necesario integrarlo a la orga-nización y empaparlo en el negocio para que apa-rezcan los mejores resultados.

Podemos tentarnos a armar un equipo multidisci-plinario, pero con esto no alcanza. Por ello, de lascosas que estamos realizando en el Centro deExcelencia Internacional de Investigación y Desa-rrollo de Telefónica (en alianza con Corfo y la Uni-versidad del Desarrollo) además de integrar equi-pos de data scientists con especialistas en minería,agricultura de precisión y ciudades inteligentes,es a no escatimar recursos para que nuestros datascientists aprendan en profundidad el contexto enel que están desarrollando su trabajo.

Existen enormes oportunidades de hacer mineríade procesos y aplicar diversas técnicas de mineríade datos, pero para hacer la diferencia profundadentro de la organización se necesitan recursoshumanos, tiempo para dominar las técnicas y ma-durar el conocimiento del negocio. Todavía esta-mos en etapas muy iniciales, lejos de recoger losenormes beneficios que promete el estado del artede la tecnología.

LOS DESAFÍOS ENDATA SCIENCESHay muchísimo por hacer en la tarea de cimentarla importancia de la aplicación de data science enel desarrollo tecnológico. En Telefónica I+D Chileencontramos a diario lindos problemas para resol-ver: desde la falta de arquitecturas que soportenimplementar soluciones confiables y escalables,pasando por la configuración de redes de sensores,hasta la aplicación masiva de técnicas de machinelearning que hace muchos años están consolida-das, pero que todavía no están adecuadamenteimplementadas en las plataformas de código abier-to que usamos en nuestros proyectos.

Hoy en día, los grandes proveedores de cloudcomputing están implementando soluciones inte-resantes para integrarlas al gran volúmen de datosque están acumulando. Por ejemplo, el trabajoque hace Microsoft con Revolution Analytics yAzure Machine Learning, son extremadamenteprometedores, así como las soluciones de Googley Amazon. Sin embargo, todas ellas, a pesar de lointeresante y prometedoras, todavía son platafor-mas que carecen de modelos que se adapten au-tomáticamente a la casuística de una organizaciónparticular y que sean efectivas para la misma.

En la actualidad se requiere de alguien altamenteespecializado para que genere un modelo predic-tivo eficiente, que haga la diferencia para el nego-cio de la organización. En este sentido, aparecenstartups prometedoras que venden servicios paradeterminadas verticales y protegen sus modelosdetrás de la venta del servicio, llevando los datosdel cliente a su entorno de procesamiento. Noobstante, deberíamos ver una evolución en elsentido inverso, donde se puedan portar y adaptarlos modelos en el entorno de ejecución del cliente,llevando el procesamiento a los datos y sirviéndosede la nube como una fuente más de información,donde las empresas del mismo rubro aportan anó-nimamente sus datos para evolucionar los modelospredictivos y donde se integran fuentes de datosque tiene sentido procesarlas en la nube en supropia fuente, tales como dato de redes sociales,por ejemplo.

EVOLUCIÓN DEPLATAFORMASTECNOLÓGICASEstamos viendo madurar y evolucionar diversasplataformas tecnológicas. En particular, hace al-gunos años, tecnologías como Hadoop competíancon otras plataformas, mientras los grandes de laindustria desarrollaban sus propios modelos decomputación distribuida, y hoy en día esa discu-sión ya es cosa del pasado. Así como también lofue en un momento la existencia de diversos pro-tocolos de redes LAN, hasta que se impuso elTCP/IP, hoy pasa algo similar con Hadoop y todoel ecosistema que corre sobre él: Storm, Spark,cascading, Scala, Hive, Hbase, etc. Vemos variasdistribuciones consolidadas, la separación delalmacenamiento de los data nodes, la evoluciónbasada en yarn, todas las cuales permiten crearsoluciones de órdenes de magnitud más eficientesy pensar en soluciones que operen en tiempo real.

Estas distribuciones permiten a personas con pocoentrenamiento aprender la parte de manipulaciónde datos de Hadoop con sólo bajar una imagende máquina virtual, trabajar con una solución quese despliega muy rápido y que permite, en lasversiones de nube, almacenar los datos con elcluster apagado, y prenderlo para procesar losdatos sólo cuando uno lo necesita (en algunoscasos, pagando por minuto procesado).

Esta tecnología se ha convertido en algo baratoy abundante, además de tener un ritmo de evolu-ción vertiginoso. La plataforma va a seguir evolu-cionando más y más rápido, incluso de forma másapresurada de lo que las organizaciones puedendigerir. Tenía un profesor en la universidad quesolía decir “la historia acelera”. Creo que es muycierto.

La abundancia de capacidad de cómputo y dealmacenamiento a costos muy bajos en las solu-ciones cloud, más el alineamiento de la comunidadacadémica y la industria a nivel mundial, paraevolucionar sobre plataformas como Hadoop,

43


LA EXPERIENCIA ENTELEFÓNICA I+DNosotros trabajamos con una visión muy pragmá-tica y partimos de problemas reales, enfocadosprincipalmente en los desafíos referidos de mi-nería, agricultura y urbanismo que enfrentan nues-tros clientes (Market Pull). Sobre esos inconvenien-tes, nos preocupamos de capturar toda lainformación existente y de integrar sensores paracapturar y poner toda la información en una pla-taforma de Internet of Thinks (IoT).

Esto implica que cada objeto instrumentado ten-drá una existencia física en el mundo real y otravirtual, contextualizada y conectada con la instan-cia física, existiendo dentro de nuestra plataforma.Adicionalmente, capturamos toda la historia decada elemento y agregamos la información desistemas existentes y fuentes externas que seanrelevantes para darle contexto al elemento.

Podemos tener la telemetría de un camión, peroes relevante para el contexto tener, por ejemplo,la condición climatológica en el lugar por dondecircula el camión. Los equipos de desarrollo tra-bajan en los problemas de integración, visualiza-ción de los datos de los sensores, integracionesdiversas y hasta el procesamiento de eventoscomplejos de primer nivel.

Los datos nos hablan. Por ejemplo, si aumentanlas señales alternadas en un período de tiempoes indicación de que el sensor está haciendo malcontacto; un aumento repentino de consumo deenergía implica una manguera de presión conpérdidas; un aumento sostenido del consumo deenergía, en general indica falta de lubricación, etc.

LA APERTURADE LOS DATOSOtro tema muy importante que mencioné al co-mienzo es la disponibilidad de los datos. Respe-tando en primera instancia los elementos de pri-

vacidad de datos, siempre hay espacios para com-partir información.

Esta arista sobre compartir los datos es muy claray común en el caso de las ciudades: hay múltiplesiniciativas de ciudades digitales y todas tienenun componente de datos abiertos. Sin embargo,a nivel empresarial no existe casi apertura y sibien esto obedece en general a políticas internasde seguridad de la información, hay datos queson valiosos por su transversalidad y porque alintegrarlos, esto genera redes de información queaportan más valor que las islas (nodos) que lacomponen. Por ejemplo, si tengo una estaciónagroclimatológica, debería ser fácil para mí com-partir los datos de la misma y para otros, encontraresos datos y consumirlos, porque el poder deajuste de predicciones que da el tener las estacio-nes de mis vecinos y de los vecinos de mis vecinos,es enorme.

Si somos capaces de ver el valor de la informaciónagregada y compartida, aparecerá la necesidadde tener una plataforma transversal, e idealmenteabierta, en donde agregarla y explotarla. Por ello,en Telefónica I+D montamos todas las solucionessobre la plataforma FIWARE. Esta plataforma escreada como proyecto abierto por la comunidadeconómica europea, y si bien hoy la discusión desoftware comercial o abierto es un tema casi delpasado, sí es relevante el tema de tener la facilidadde manejar datos abiertos, es decir, que mis datosestén en un formato que los pueda consultar einterpretar tanto un humano, como una máquina,con acceso simple y basado en tecnologías estan-dar (acceso REST, transmisión sobre http, encap-sulación en json, etc).

Para nosotros resulta esencial el poder compartirlos datos abiertos que dispongamos. Si queremostener un ecosistema de IoT activo y dinámico, esnecesario que podamos darle de forma sencillaacceso a los datos a los emprendedores. El poderde entregar permiso de lectura al usuario “Juan”sobre todos los sensores del tipo “estación declima” del grupo “Región de Coquimbo”, y quecon esta simple acción le demos todas las facili-dades de consulta y procesamiento, es una de lascapacidades “out of the box” que queremos teneren corto plazo con esta plataforma.

genera, sin dudas, espacios para que aparezcanlas soluciones que logren explotar esos datos,aportando con una diferencia significativa al ne-gocio.

Sin embargo, si vuelvo a mis tiempos de arquitectode una organización, hay dos decisiones de arqui-tectura, tres fundaciones sobre las cuales construi-ría la estrategia de datos de la organización y queme parece son elementos previos de los cualescarecen la mayoría de las organizaciones hoy.

Primero, almacenaría todos los datos que generanlos sistemas de la organización en su forma origi-nal, sin ningún tipo de transformación y en laforma más sencilla posible. Todo, no se descartani resume, nada.

Segundo, no permitiría que se comprara ningúnsistema que no entregue, en forma de datos abier-tos (datos de los cuales se puede interpretar susignificado en forma integral), todos y cada unode los datos que captura de mi organización. Yéste, aunque parezca menor, es un punto críticohoy en Chile. Al realizar un proyecto a una mineraimportante y cuando pide la telemetría de algotan simple como una pala mecánica y dice queno, sólo el proveedor puede leer los datos de lamáquina, si se conecta algo a la interfaz de lacomputadora de la máquina se pierde la garantía.Y en último punto, no sólo se requiere de hard-wares, sino también es indispensable que todoesté en la nube.

En este tiempo donde el más desinformado delos gerentes entiende que hay valor en los datos,en el concepto de Big Data, la situación de datosabiertos es inadmisible y es una decisión innego-ciable que tiene que imponer la arquitectura dela información; no aceptar islas de datos dentrode la organización, no aceptar proveedores quese quedan con nuestros propios datos y no noslos entreguen.

Antes hablaba de lo que se necesita para hacerdata science. En un nivel más básico, para hacermachine learning se necesitan datos, patronesexistentes en los datos y que estos no sean formu-lables en forma matemática. Bueno, estas son lastres bases para hacer machine learning, pero lamás básica de todas es… ¡tener datos!

44


Entre 1995 y 1997 la Corporación de Investigación Tecnológica (INTEC),en el contexto del proyecto “Herramientas de productividad para laindustria de software” realizó las primeras acciones nacionales condu-centes a mejorar la calidad de desarrollo de software nacional. Unade sus primeras actividades fue realizar una gira para conocer el estadodel arte internacional, momento en el cual se conoció de la existenciade SPIN (Software Process Improvement Network) creándose en elaño 1995 el organismo nacional, denominado “Club CMM”.

45

ERIKAMADARIAGAIngeniero Civil en Informática, Universidad de Santiago de Chile ;Magíster en Educación Basada en Competencias, Universidad de Talca;Diplomado en Gestión de Negocios, Pontificia Universidad Católica deChile. Actualmente Directora de la Escuela de Computación eInformática de la Universidad Bernardo O'Higgins, y Directora Secretariade SPIN-Chile A.G. Con más de 15 años de experiencia docente ydirectiva en diversas instituciones de educación superior. Especialistaen formación y gestión por competencias en el área [email protected]

1 http://www.sei.cmu.edu/spin/2 http://www.spin-chile.cl/

Dentro de las actividades de ese proyecto estuvoel acuerdo con el CRIQ de Canadá para usar unaherramienta de evaluación de riesgos de desarrolloS:Prime, evaluaciones piloto y capacitación de con-sultores en la herramienta. Este proyecto finalizó ennoviembre de 1997 con la realización del “PrimerSimposio Latinoamericano de Calidad y Productivi-dad en Desarrollo de Software”.

En sus inicios esta agrupación de profesionales, ClubCMM, comenzó a funcionar bajo el alero de INTEC-Chile, y su principal objetivo fue introducir técnicasy métodos útiles a los desarrolladores de software,apuntando a la mejora de sus competencias. En1996 esta agrupación se integró formalmente a lared mundial de SPIN liderado por el SEI (SoftwareEngineering Institute) de la Universidad de CarnegieMellon, y pasó a llamarse SPIN-Chile, cuyo objetivofue compartir conocimientos y experiencias, en elámbito chileno, y relacionarse con quienes trabajanpor similares intereses en el mundo.

Al término del proyecto en 1997, SPIN-Chile se se-paró de INTEC y comenzó a funcionar bajo el alerode la Universidad de Chile, dado que no tenía per-sonalidad jurídica. En enero de 2003, luego de cum-plir con los procesos legales vigentes de la época,el grupo se constituye y consolida como una aso-ciación gremial, pasando a ser denominado SPIN-Chile A.G.

Grupos SPIN existen en todo el mundo, bajo unmodelo propuesto y respaldado por el SEI. CadaSPIN tiene una misión y visión diferentes, basadasen las necesidades de la comunidad donde se de-sarrollan. La característica común a todos ellos es elaporte de tiempo y recursos de sus miembros parael desarrollo de las actividades y el logro de susobjetivos1.

SPIN-Chile A.G.2 actualmente es una agrupaciónde empresas, universidades y profesionales en torno

al mejoramiento de los procesos en las prácticas deIngeniería de Software en el mercado TIC chileno,que conforman el capítulo local de SPIN, realizandosus actividades regulares en Santiago de Chile.

SPIN-Chile A.G. organiza anualmente un conjuntode actividades tendientes a promover la interacciónentre sus miembros, y la orientación está relacionadacon las características, capacidades y requerimientosde cada uno de los tipos de socios que congrega.Las principales actividades son: tutoriales, reunionespresenciales, mesas redondas, seminarios, cursos,talleres, workshop, entre otros. Todas estas activi-dades son organizadas con la colaboración de losdistintos miembros que conforman la red, y el ob-jetivo principal es mostrar el estado del arte, buenasprácticas, experiencias de empresas en el procesode mejoramiento de la calidad, éxitos y fracasos.Destaca en 2007, la realización del evento interna-cional realizado en Santiago de Chile, SoftwareEngineering Process Group Latin America (SEPGLA2007) organizado por SPIN-Chile A.G., EuropeanSoftware Institute (ESI), y patrocinado por SoftwareEngineering Institute (SEI), el cual contó con la par-ticipación de profesionales de distintos países deLatinoamérica y conferencistas de reconocimientomundial.

Actualmente, SPIN-Chile A.G. está potenciando susalianzas con universidades e instituciones afines, ydesarrollando nuevos proyectos, entre los cualesdestaca el realizar estudios que permitan entregara la comunidad chilena antecedentes locales sobrela calidad en el desarrollo de las soluciones, sistemasy servicios de software. Lo importante es que estosestudios estén debidamente respaldados y quepermitan sustentar con información actualizadadecisiones de mejoras en las prácticas de ingenieríade software y en la enseñanza impartida a sus pro-fesionales en formación, en pos de la excelencia dela industria TIC en Chile.


46


47

MARÍA CECILIABASTARRICAProfesor Asociada del Departamento de Cien-cias de la Computación (DCC), Universidad deChile; coordinadora académica Diplomadosen Ingeniería de [email protected]

JOSÉPINOProfesor Titular del Departamento de Cienciasde la Computación (DCC), Universidad de Chile;coordinador académico del Magíster en Tec-nologías de la Informació[email protected]

El Departamento de Ciencias de la Computación de la Universidad deChile ofrece desde 2004 el Programa de Magíster en Tecnologías de laInformación (MTI). Este Programa está orientado a profesionales del áreaque estén trabajando en empresas e instituciones. Se ofrece en un formatovespertino y los cursos tienen un marcado énfasis en temas práct icos,tecnológicos y de educación continua.

La mayor parte de los cursos del MTI son electivos, clasificados en cuatroáreas: Gestión Informática, Ingeniería y Calidad de Software, Ingenieríade Datos, y Seguridad Computacional. El resto de los cursos (obligatorios)se refieren al desarrollo del Proyecto de Grado final. La duración estimadade los estudios es de dos años.

El Programa tiene otra característica interesante: al cursar un ciertonúmero de cursos de una cierta área se obtiene un Diploma de Postítulo.La mayoría de los alumnos del Programa obtiene dos Postítulos de lDepartamento como beneficio adicional de seguir el MTI. Los profesoresdel Programa son académicos de jornada completa del Departamentoy profesores de jornada parcial que laboran en empresas o instituciones.

Los requisitos de postulación son: estar en posesión de una Licenciaturaen Computación o equivalente, tener buenos antecedentes académicos,tener alguna experiencia laboral.

Mayores antecedentes pueden encontrarse en:http://www.dcc.uchile.cl/magister_ti y las consultas pueden dirigirsea: [email protected]

El Postítulo en Ingeniería y Calidad de Software se dicta en el Departa-mento de Ciencias de la Computación (DCC) de la Universidad de Chiledesde 2004, y cuenta ya con más de 120 titulados. Solamente se admitepara este Programa a personas que tengan un título de Ingeniero Civilen Computación, o bien algún título afín y varios años de experi enciacomprobable en el desarrollo de software.

Este Postítulo se divide en dos módulos: Ingeniería de Software y Calidadde Software, cada uno de los cuales constituye un diploma por sí mismo.Los cursos de este programa son todos válidos como parte del Magísteren Tecnologías de la Información que imparte el DCC.

Gran parte de los alumnos son ingenieros que obtuvieron su título hacemás de diez años y muchos de ellos hace ya años que no programan niestán familiarizados con nuevas tecnologías y metodologías de desarrollode software. En la primera parte del Postítulo de Ingeniería y Calidad deSoftware –Ingeniería de Software- se actualizan los conocimien tos delos alumnos en temas tales como análisis, diseño y programación orien-tada a objetos, arquitecturas de software, desarrollo de software basadoen modelos o en aspectos, o métodos ágiles de desarrollo, entre otros.En los últimos años se ha agregado también un curso de programaciónPython que ha sido altamente valorado por los alumnos.

El módulo de Calidad de Software se centra tanto en la productividadde los procesos de desarrollo de software como en la calidad de losproductos de software en sí. En cuanto a la definición de proces os dedesarrollo de software, se introducen conceptos básicos, técnica s de


48

El Programa de Magíster en Tecnologías de Información y Gestión (MTIG)nació en 2005 en el Departamento de Ciencia de la Computación (DCC)de la Escuela de Ingeniería de la Universidad Católica. La motivación fuepoder transferir rápidamente habilidades técnicas y de gestión a ingenierosque trabajan directamente con tecnologías de información (TI), o inge-nieros con responsabilidades de gestión en empresas donde es tas tec-nologías juegan un rol importante.

definición y estándares internacionales propuestos en relación a estetema. En cuanto a la calidad del software, se centra en formas de realizarpruebas de la calidad del software, así como un taller de aplic ación detodo el contenido impartido.

En términos generales, los alumnos que se han titulado de este Programalo han encontrado muy valioso y útil para su vida profesional en cuantoa los contenidos impartidos, pero también reconocen que requiere grandedicación y estudio, ya que es muy exigente.

YADRANETEROVICProfesor Asociado Departamento de Cienciade la Computación (DCC), Pontificia Universi-dad Católica de Chile. Director del Postítuloen Gestión Informática (INGES)y y coordinadordocente del DCC [email protected]

JAIMENAVÓNProfesor Asociado Departamento de Cienciade la Computación (DCC), Pontificia Universi-dad Católica de Chile. Director del DCC UC ydel Magíster en Tecnologías de Información yGestión (MTIG)[email protected]

El sello del Programa es la dualidad tecnología-gestión. En un mismocurso suelen encontrarse ingenieros comerciales que saben poco de TI,ingenieros de software que saben poco de negocios e ingenieros eléctricosque saben poco de ambas cosas. El currículum es, por lo tanto, balanceadoe incluye cursos técnicos sobre ingeniería de software o tecnologías dela Web, cursos de gestión estratégica o de personas, y cursos que unenambas cosas, tales como Inteligencia de Negocios y Minería d e Datos.


49

RAÚLMONGEDirector Departamento de Informática UniversidadTécnica Federico Santa María (UTFSM), Valparaí[email protected]


Los profesores del MTIG son en su mayoría profesores del DCC, perotambién se cuenta con profesores part-time con amplia experiencia enla industria que aportan la otra componente.

El Programa incluye 24 cursos más una actividad de graduación en quelos participantes tienen la oportunidad de aplicar sus nuevos conocimien-tos en un caso concreto. La mayoría de las veces, el tema para e staactividad surge de la empresa donde el alumno se desempeña profesio-nalmente y corresponde a un problema real.

En los diez años de vida del MTIG hemos graduado a cientos de profesio-nales que vuelven a sus respectivas empresas habiendo adquirido nuevascompetencias y herramientas. Más relevante aún, vuelven a sus empresascon una nueva visión del rol crucial de las TI como habilitador de nuevosnegocios. Gerentes de negocios aprenden, por un lado, sobre el tremendopoder de estas tecnologías, y, por otro, que se requiere conocim ientos

técnicos, esfuerzo y tiempo para construir algo que finalmente parecerelativamente simple desde la perspectiva del usuario.

Si bien el MTIG no ofrece especializaciones, en la práctica los estudiantespueden tomar cuatro cursos del área de Ingeniería de Software (y hacerasí una "miniespecialización"): Procesos de Desarrollo de Software, Tallerde Ingeniería de Software I, Taller de Ingeniería de Software II, y Arquitec-tura de Sistemas. Estos cursos tienen una clara orientación al desarrollode competencias por la vía del trabajo práctico (incluso, en cla ses) engrupos y en contextos de problemas, proyectos y aplicaciones r eales,algo que los estudiantes valoran mucho: en los últimos tres años , estoscursos han tenido una inscripción promedio de casi veinte estudi antescada uno. Por supuesto, los estudiantes complementan estos cursos conotros, en áreas tales como Bases de Datos, Tecnologías de la WWW oGestión de Proyectos.

El Departamento de Informática creó en 1994 su primer Programa dePostítulo, un Diplomado en Ingeniería de Software. Actualmente, existencuatro programas vigentes, a saber: en Gestión de Procesos de Negocios,Gestión de Proyectos, Base de Datos e Inteligencia de Negocios. Estoscuatro programas se describen a continuación.

a) Diploma en Business Process Management (DBPM)Este Programa está orientado a profesionales en el área de Negocios yTecnologías de la Información, con el propósito de formar especialistasen Business Process Management y en las TI que los soportan. El Diplomaabarca el ciclo completo de la gestión de procesos; desde el alineamiento

estratégico, modelos de negocio, arquitectura de procesos, diseño deprocesos de negocio, optimización de procesos, la implementación enentornos modernos de workflow, hasta la formulación de indicador esy el monitoreo en línea de la ejecución de los procesos integrados. EstePrograma se inició en 2009, y ha logrado titular a 88 profesionales.

b) Diploma en Gestión de Proyectos en Tecnologías de la InformaciónEste Programa está orientado a profesionales que se desempeñan e ndistintos ámbitos de las TI, para formarlos en las mejores práct icas dedirección de proyectos y, al mismo tiempo, los enfrenta a casos dondeestos conceptos deben ser aplicados para lograr un desarrollo exitoso.El Diploma se imparte desde en 2007 y siempre ha tenido una muy altademanda.

c) Diploma en Diseño y Administración de Bases de DatosEste Programa se orienta a profesionales que se desempeñan en elcampo de las tecnologías de la información y disciplinas afines, y querequieren especializarse en el área de Bases de Datos. El Pro grama losprepara mejor para enfrentar problemáticas propias de las organizacionesmodernas, como el modelado de datos a partir de una especifica ciónde requisitos, diseño lógico y físico de datos, administración de las basesde datos, integración entre sistemas operacionales y los siste mas deapoyo a la toma de decisiones, entre otros. Este Programa se ini ció en2008 con el nombre de Diploma en Gestión de Datos, siendo actualizadoen 2013 y recibiendo entonces el nombre actual.

d) Diploma en Inteligencia de NegociosA partir de 2015, derivado de la actualización del Programa anterior en2013, el Departamento de Informática ofrece este Programa, que s eorienta a profesionales de las tecnologías de la información y disciplinasafines con el propósito de especializarlos en el área de la Inteligencia deNegocios.

50

Por Alejandro Hevia

Conversaciones

51

ROBERTOOPAZOIngeniero Civil en Computación y Magíster en Ciencias de laIngeniería Industrial de la Universidad de Chile. Directorejecutivo y socio fundador de Khipu, una empresa que nacióen Chile para competir en la industria de los medios de pagoy que ya vendió su primera franquicia a Bolivia. Antes fuesocio fundador y gerente general de Acepta.com, la empresaque partió en Chile con la firma y la factura electrónica.Durante su vida como emprendedor, también ha destinadotiempo a dictar las cátedras de "Seguridad de datos y firmasdigitales" y "Emprendimiento en negocios digitales" en laUniversidad de Chile. Inició su trayectoria como emprendedordespués de haber sido empleado diez años en consultorasespecializadas en la banca, el desarrollo de sistemas y laindustria forestal. De estudiante cultivó el desarrollo dehabilidades blandas en el teatro, como dirigente estudiantil,profesor auxiliar y consultor.

¿Seguiste la especialidad de Ciencias de laComputación y luego hiciste el Magíster enIngeniería Industrial. Puedes resumir tu vidaluego de la Escuela, contarnos un poco cómollegaste a emprender?

Te respondo desde un poco antes. El DCC mecambió la vida en el primer semestre. Tuve clasescon Juan Álvarez, en Introducción a la Computa-ción, y ese fue el momento en que descubrí mivocación por la Computación. Entré pensandoen ser Ingeniero Civil Industrial y en ser político.Pero en ese semestre decidí ser "computín". Des-pués me siguió gustando, si bien entremediomantuve una "pata" en el Departamento de Inge-niería Industrial y hoy pertenezco alos exalumnos de ambos departamentos.

La verdad es que empecé a trabajar en el segundoaño de Ingeniería. Trabajé tres años en el grupode consultoría del Centro de Computación, luegotres años en investigación operativa en el grupode Andrés Weintraub en el Departamento deIngeniería Industrial de la Universidad de Chile.En el proceso, egresé y trabajé varios años. Y allírecién emprendí. Aunque no tenía tantos añosde trabajo, ya tenía mucha experiencia. Mi primeremprendimiento estuvo asociado a mi tema detesis, que era una solución al problema de asig-nación de horarios ¡y fracasó por completo! Lemandé cartas a 400 colegios, muchos respondie-

ron pero quienes querían la solución no podíanpagar por ella. Al final, aunque gasté plata y tiem-po en ello, fracasó. Luego mi siguiente empren-dimiento, por allá por 1998, fue algo que partimosen conjunto con Jorge Claro: un mall virtual. Laidea era hacer un mall virtual grandote, pero esotambién fracaso. Y en ese contexto fue cuandopartimos Acepta.com, proyecto que era un plande contingencia, que terminó siendo una historiade doce años para mí como emprendedor, dondetransformamos a Chile en el primer país del mun-do en emitir una factura electrónica en que laseguridad estaba dada por una firma electrónica.Después de Acepta.com partí Khipu.

Ya con tu experiencia, ¿qué conclusiones sacasrespecto a qué te ayudó y que no te ayudó dela formación del Departamento de Ciencias dela Computación (DCC) y la Escuela de Inge-niería y Ciencias de la Universidad de Chile,en el proceso de emprender?

Mi respuesta es respecto a la formación en laEscuela en general, mi análisis no es exclusivo alDCC. En mi primera prueba de la Escuela me saquéun rojo, esencialmente porque la prueba no teníanada que ver con lo que me habían enseñado.Esto es, lo que me preguntaron no se parecía aninguno de los ejercicios que había hecho antes.Sin embargo, con el tiempo uno termina dándosecuenta que eso está bien, es normal, a ti te en-

Conversaciones

52

IMAGEN 1.EN 2013 KIPHU GANÓ EL DEMO DAY DE START UP CHILE.

señan las cosas de una manera pero las tienesque usar de otra. Y ese es un sello muy profundoen la Escuela, el cual ha marcado muchísimo miejercicio como emprendedor e innovador. Sientoque el DCC entrena a sus estudiantes en esteproceso. En aprender a adaptarse. En usar el co-nocimiento y no repetir simplemente "pares or-denados" de preguntas y respuestas.

Y en tu opinión, ¿fuiste una anomalía o eresrepresentativo de un estudiante tipo en elDCC? ¿Ser innovador es algo que se puedeenseñar o es simplemente una característicade ciertos estudiantes que solo se puede ali-mentar y quizás potenciar?

Creo que el DCC no es una escuela de negocios.Entonces, como emprendedor, es normal y estábien que sea una anomalía. Pero lo que el DCC síhace, y su sello está en muchos exalumnos de migeneración, es forjar la capacidad de crear y pen-sar cosas de una manera distinta, lo cual puedesrealizar en grupos chicos o en grupos grandes.No creo que el DCC tenga que ponerse la metade formar muchos emprendedores. El conoci-miento que te entrega se puede aprovechar enel emprendimiento como también en muchosotros ámbitos.

¿Qué iniciativa puede implementar un depar-tamento para fomentar que salgan más deestos profesionales que "eligen creer" que sela pueden, que pueden tomar ideas y tecnolo-

gía "de las nubes" y bajarlas a tierra paragenerar un emprendimiento exitoso?

Soy muy fan del DCC así que no creo que debatener un giro en 180 grados, pues ya lo está ha-ciendo muy bien. Sin embargo, algo que no vimucho en mi formación (no sé si habrá cambiadoahora) es enseñarle a la gente a fallar, a permitirsefallar. Entender que en el error y en los fracasoshay un aprendizaje que nunca vas a tener en loséxitos. Estos últimos solo refuerzan lo que túcreíste. Pero al fallar tienes una posibilidad deaprendizaje gigante, y quedas mucho mejor cuan-do lo sabes digerir y cuando hay un ecosistemaque permite la falla. Creo que eso es un elementomuy importante a cultivar. Lo que haces conrespecto a tus fracasos determina muchísimo loque vas a poder hacer después, especialmentecomo emprendedor.

Cambiando de tema, tus emprendimientosfueron tecnológicos. ¿Podrías hablar un pocode cómo armaste tus equipos en ellos, en par-ticular, de cómo usaste ingeniería de softwarepara lograr producir tus objetivos? ¿Cómo esen Chile hoy emprender a partir de hacer soft-ware?

Hoy es muchísimo más fácil que hace diez años.El ecosistema ha mejorado una brutalidad estosúltimos años. Cuando comencé Acepta.com lasposibilidades de financiar una empresa de esascaracterísticas eran bajas. Era todo absurdo, cuan-

do nos juntábamos los pocos emprendedores enesa época comentábamos cosas como "llevo cincomeses emprendiendo y planeo seguir haciéndo-lo". ¡Parecía una reunión de Alcohólicos Anóni-mos! Hoy día hay grupos grandes de emprende-dores. Todo lo que se ha armado en Start-Up Chile,todo el financiamiento de capitales semilla, delas distintas incubadoras en universidades essignificativo.

Hoy en día, en etapas tempranas de tu empren-dimiento hay muchos fondos a los cuales puedesacceder. Levantar fondos de entre 40 a 60 milloneses algo que logran no menos de mil emprendi-mientos al año. En mi época, no eran más de diez.Partir hoy es extraordinariamente más fácil. Sinembargo, continuar es muy difícil. De los milemprendimientos que levantaron capital e inten-taron algo seriamente el año pasado, no más deunos cincuenta tienen evidencia que su negociopuede ser bueno y continuar. Para esos cincuentafinanciarse es muy difícil. Corfo ha hecho cosasinteresantes como el capital semilla "expansión",liberado en 2014, pero lamentablemente los mon-tos que se necesitan son mucho más grandes quelos provistos por Corfo. Además, hay un problemano muy fácil de ver para un “computín”, pero quemi lado "industrial" me lo permite detectar: enChile, las rentabilidades en industrias como lasinmobiliarias, mineras y similares, de muy bajoriesgo, son muy altas. Entonces, la rentabilidadversus riesgo de nuevas industrias (como la tec-nológica) hace que no tenga mucho sentido in-

Conversaciones

53

mucha velocidad para desarrollar, para adaptar-nos, para incorporar características nuevas alsoftware. Esto es fundamental pues somos unequipo muy chico. Nuestro competidor más chicotiene diez veces más ingenieros en desarrollo quenosotros. Un competidor grande cien veces.

Mirando números, nuestro presupuesto de co-mercialización llega a 300 millones de pesos.Transbank, en lo mismo, va a gastar 20 millonesde dólares. En otras áreas se tiene algo similar:diferencias en presupuesto de 1 a 200. Por lotanto, para competir, tienes que lograr producti-vidades que hagan una diferencia gigante. Y esono es algo que te lo de una persona genial, sinoque depende de las metodologías. Notemos quelas metodologías de integración continua sonprácticamente imposibles de implementar enuna empresa que ya está andando. Así, si partesdesde cero una empresa con integración continuay mantienes esa capacidad, entonces tienes unaventaja sustentable en el largo plazo. Eso es unaventaja estratégica para nosotros.

¿Cómo ha sido tu experiencia en términos téc-nicos de este proceso de desarrollar tecnolo-gía? Porque tú vendes algo poco frecuente enun país como Chile.

Aquí vale la pena contrastar mi experiencia enarmar Acepta.com versus armar Khipu. Son dosempresas muy distintas. La tecnología de Acep-ta.com era muy innovadora en su tiempo y, porlo tanto, vender esa tecnología era muy difícil. Latecnología de Khipu es muy innovadora en sudiseño, en su concepto, y “hacia adentro”, peroel problema que resuelve afuera, la solución queuno le ofrece a los clientes es algo que todo elmundo entiende y la verdad es que es bien fácilde vender. Efectivamente, luego de decir “te ofrez-co una solución que te va a permitir cobrar pormás canales, que te van a pagar más personas,que te va a costar menos dinero y va a ser másestable” ya estás listo, ¡has terminado de vender!Ahora, producirlo y financiar su producción, esmucho más complejo porque el inversionistatiene muchas más dificultades para entender quese puede producir algo tanto mejor que lo queya existe para resolver el mismo problema. Y ahísí es importante entrar en los detalles técnicosde por qué simplificar transferencias permitellegar a más personas que los pagos con tarjetasde crédito, permite entrar a una industria quetodos creen es de los bancos pero que, en reali-dad, no lo es. Y es ahí donde vas abriendo muchoscaminos que parecían cerrados.

vertir en capital de riesgo. Es un asunto meramen-te económico. Si uno acepta que un inversionistaquiere maximizar su rentabilidad minimizandoel riesgo, no es claro que sea buena idea invertiren capital de riesgo en Chile. Cierto, aquí hay doscosas: hay reglas del juego en Chile que hacendemasiado más fácil enriquecerse en industriascomo las inmobiliarias, y por ende hay algo quecorregir allí, lo cual se está discutiendo hoy endía. Pero por otro lado, se requieren políticaspúblicas mucho más fuertes para que haya dis-posición a, y hagan más fácil, invertir en empren-dimientos tecnológicos. Hay rentabilidades muyaltas en áreas de la economía que no favorecenal país.

Desde un punto de vista más técnico, ¿cómofue esto de armar un emprendimiento dondeel valor estaba dado por un software, por so-bre quizás el grupo de gente que desarrollóese software?

Esto fue fundamental en Khipu. Allí logramosarmar un equipo humano cuyos méritos van mu-cho más allá de mi aporte. Este grupo implementabuena parte de las metodologías de integracióncontinua, incluyendo pruebas unitarias, pruebasde integración, y pasos a producción semiauto-matizados. En Khipu podemos pasar a producciónnuevas versiones dos veces al día en forma bas-tante segura. Nosotros gastamos el 50% de nues-tro esfuerzo en producir código y el otro 50% enque éste viva en un entorno que nos permitaconfiar en dicho código. Por lo tanto, tenemos

Conversaciones

IMAGEN 3.EL TERMINAL DE PAGOS KHIPU.

IMAGEN 2.KHIPU EN LAS REDES SOCIALES.

54

Se habla mucho que para un país pequeñocomo Chile lo mejor es diversificarse e invertiren tecnología. ¿Tiene sentido emprender enChile trayendo tecnología de un nivel teóricoa un nivel práctico, hacer lo que antiguamentese llamaba “transferencia tecnológica”?

Tengo un problema con el término “transferenciatecnológica”. Creo que debiera dársele otro nom-bre a la misma actividad. Ella consiste en queuniversidades y el mundo académico colaborencon empresas para producir innovación.“Colaboración para innovación” me parece unmucho mejor término. Cuando se habla de“transferencia tecnológica” queda la impresiónque el conocimiento está en un lado y simple-mente lo vas a transferir al otro. Suena infinita-mente soberbio. Y a las empresas les carga, puesde partida miran en menos al mundo académico(el típico argumento de “quien enseña no tieneexperiencia” o no sabe lo que realmente estápasando). Así que esta idea de que el conocimien-to está en el mundo académico y se transfiere alas empresas les cae como “patá en la guata” aestas últimas. Como concepto de marketing, naciómuerto. Pero sí creo en la innovación. Y sí creoen la colaboración entre el mundo académico ylas empresas para la innovación.

¿Y cómo crees que esa colaboración puedeconcretarse mejor en un país como Chile, don-de los tiempos e incentivos que tienen las em-presas y el mundo académico son distintos?

La clave se llama “osmosis” (se ríe). ¿Cuáles sonlas fuentes de osmosis? Una es cuando alguiendel mundo académico forma parte de un equipode trabajo en una empresa, por ejemplo, cuandohay un grupo de estudiantes que van a ayudaren ciertos temas. Otra forma de osmosis es cuan-do gente de las empresas hacen docencia, comoun profesor part-time que va a hacer clases a unauniversidad. Se debe buscar osmosis en ambasformas, para así finalmente conformar equiposde trabajo que estén en ambos lugares. El proble-ma es que en esos equipos de trabajo la discusiónsiempre está en quién es el dueño de lo que seproduzca. Ese es un problema natural entre lasempresas y la universidad. Ambos quieren que-

darse con una parte, al menos, de la propiedadde lo que se produzca. Creo que las universidadesno deberían aspirar más que al mérito. Y las em-presas debieran quedarse con la propiedad. Sim-plemente porque lo otro no funciona.

También la “rotación” (profesores que temporal-mente migran a la empresa privada y luego re-tornan al mundo académico) es una forma deosmosis que el tipo de evaluación docente actualno favorece. Un académico que decide hacer esoestá perdido, muere académicamente. Desde lamirada de la empresa no es tan malo.

Creo que en general la visión que las empresastienen de los académicos es equivocada. Creoque los académicos saben muchas cosas que sonútiles para las empresas y, a su vez, las empresasno los aprovechan. El respeto por los académicosno está inculcado en la cultura de las empresas.De hecho, ¡ese respeto los estudiantes lo pierdencuando se titulan! Mientras uno es estudiante,valora mucho a sus profesores, pero cuando setitula y entra a una empresa, lo primero que tedicen es que “los profesores no saben nada” y“ahora vas a aprender” (se ríe).

En otras latitudes es común que un grupo deestudiantes en un rato de ocio inventen algoque transformó al mundo. Y en términos decalidad de estudiantes, no creo que los nues-tros tengan algo que envidiarles a los de esetipo de instituciones. Sin embargo, ese tipode creaciones no surge tan seguido acá. ¿Hayalgo que quizás podríamos hacer mejor, con-vencerlos más que innovar es posible?

Primero que nada, cada vez se innova más enChile. Y la gente cada vez se atreve más. No loveo tan crítico como “allá sí y acá no”. Siento queestamos en un momento de transición, dondeantes ocurría allá y acá no, pero ahora ocurre alláy acá poco, pero cada vez ocurre más. Y vamosen esa dirección, siento que todo el mundo quiereempujar en esa dirección. No hay mucha duda.Estamos descubriendo, experimentando cómohacerlo. Ese es un proceso en marcha. Y comotal, de repente hay una tendencia a buscar leyes.Por ejemplo, “fail fast”: si tienes una idea, haz la

Conversaciones

IMAGEN 4.SECCIÓN “YO PAGO” EN LA APP DE KHIPU.

IMAGEN 5.SECCIÓN “YO COBRO” EN LA APP DE KHIPU.

55

¿Algún comentario final?

Políticas públicas. Como país, como comunidad,tenemos que subirnos todos al carro de las polí-ticas públicas. Ellas no son algo que decidan losgobiernos de turno, se determinan por la acade-mia, las empresas, la ciudadanía, a través de laprensa, en redes sociales. Entonces, empujar yempezar a pensar en términos de cuál es la políticapública necesaria para resolver los distintos pro-blemas que enfrentamos. Como individuos ocomo universidades quizá no somos lo suficien-temente grandes como para producir grandescambios, y por ello es necesario definir la políticapública que va a empujar a esos grandes cambios.

Un ejemplo de política pública sería que las uni-versidades no tengan la propiedad intelectual oindustrial de las cosas que inventan sus académi-cos, o de las cosas que en colaboración con lasempresas se producen. Eso facilitaría el tenernegocios con empresas. Y es muy simple, unaregla no más. Otra sería que en la evaluacióndocente se reconozca la experiencia que las per-

sonas tienen en la empresa. Es muy simple perohay que ponerse de acuerdo en aceptar esa regla.

¿Cuál política crees que fomentaría la innova-ción?

El financiamiento hoy día es fundamental. Se hahecho mucho en la capa inicial, pero ahora haymucho por hacer en la segunda o tercera fase delciclo de vida de un emprendimiento. Otra estáasociada a qué enseñarle a los emprendedores.Los emprendedores siempre están orientados adesarrollar su producto, tienen una cierta fascina-ción por su producto. Pero para que su empren-dimiento tenga éxito, necesitan gastar muchotiempo en lograr resultados a través de otros, engestionar gente, en financiar su emprendimiento,que no tiene que ver con abordar directamenteel producto sino indirectamente: darle recursoshumanos que lo produzcan y dar financiamientopara tener insumos. Y eso tiende a ser “una lata”pero probablemente es lo más determinante enel éxito de un emprendimiento.

maqueta lo más rápido posible para salir al mer-cado, pruébala, y si falla, ningún problema, te vasa la próxima. Para algunas ideas eso puede ser unabuena práctica, pero para la mayoría encuentroque no. Uno tiene que tener un poquito más deconvicción, probar con más prudencia, empujarcon más ganas. Apurarse en el fracaso no es lomismo que no tenerle miedo al fracaso y aprenderde la derrota. Hay otras ideas que efectivamenteson bastante simples, y la única duda es si tienenmercado. Y allí es correcto: empaquetar rápidouna muestra y ver cómo la recibe la gente.

Ahora bien, cuando uno quiere ser el primer paísdel mundo en usar firma electrónica para darlevalor probatorio a los documentos tributarios, eseproyecto no es posible de realizar “fallando rápido”.Tienes que cambiar la ley, tienes que convencer amucha gente, a muchas empresas. Yo creo queuno no debe estar demasiado desesperado porbuscar las leyes universales del emprendimientoy de la innovación. Uno debe entender que esemundo es tan diverso que en algunos casos aplicanunas reglas y en otros casos, aplican otras.

Conversaciones

IMAGEN 6.PARTE DEL “EKHIPU” O EQUIPO DE KHIPU.

56

El éxito de un proyecto es vital y crítico para la supervivencia de lasPequeñas Empresas de Desarrollo de Software (PEDS). Usualmenteestas empresas no tienen una buena liquidez. No tienen muchorespaldo financiero. Muchas veces el fracaso de un solo proyectopuede significar la bancarrota total de estas empresas. Son muyfrágiles. Por lo tanto, necesitan tener éxito en sus proyectos. Necesitanconstruir productos de software que satisfagan las necesidadesreales de sus clientes dentro de los tiempos y presupuestos planifi-cados. Uno de los factores que contribuye positivamente en dichoéxito es el uso de buenas prácticas de desarrollo de software. P oreste motivo, existen diversas propuestas donde las PEDS puedenrecurrir en busca de buenas prácticas que les ayuden a mejorar sustasas de éxito.

Surveys

57

ALCIDESQUISPEProfesor Asistente Departamento de Ingeniería Informática,Universidad de Santiago de Chile. Doctor en Cienciasmención Computación, Universidad de Chile; Ingeniero deSistemas, Universidad Católica de Santa María, Perú. Líneasde investigación: Ingeniería de Software - ingeniería derequisitos, procesos de software, e investigación empíricaen ingeniería de [email protected]

Actualmente nadie puede negar el importanterol que vienen jugando las PEDS dentro de laindustria del software. Diversos estudios mues-tran que este tipo de empresas representan unaamplia y creciente parte de la industria del soft-ware. En muchos casos son una pieza fundamen-tal del crecimiento económico de un país [9, 27].Sin embargo muchas de ellas tienen serios pro-blemas con el éxito de sus proyectos. Terminanfuera de los plazos, excedidos en el presupuestoo las soluciones que entregan no satisfacen lasnecesidades reales del cliente [13].

¿QUÉ ES UNA PEDS?Definir qué es una PEDS no es tarea fácil. Actual-mente no hay un consenso sobre una únicadefinición. Algunos estudios consideran comoPEDS a aquellas empresas con menos de 100empleados [32]. Otros las consideran como aque-llas empresas con menos de 50 empleados [8].Y otros las consideran como aquellas que tienenmenos de 20 empleados [21, 33]. Otro criteriousado para definir una PEDS es el monto defacturación; sin embargo el número deempleados pareciera ser el más usado [3].

En Chile, según los resultados del diagnósticode la industria TI desarrollado en 2003 [35], unaPEDS es definida como aquella empresa quetiene entre 11 y 50 empleados. Según esta defi-nición, este estudio muestra que en Chile almenos el 44% de las empresas pueden ser con-

sideradas como PEDS. Tomando en consideraciónesta misma definición, podemos ver que en Brasillas PEDS representan al menos un 50% [1]; enCanadá ellas son al menos el 28% [19], y en Fin-landia ellas son al menos 23% [28]. Estos da tosmuestran que las PEDS representan un porcen-taje no menor dentro de la industria de software.

CARACTERÍSTICASDE LAS PEDSLas PEDS tienen características que las distinguencompletamente de las medianas y grandes em-presas. Estas características hacen que cualquiersolución propuesta para las medianas o grandescompañías no sea adecuada para este tipo deempresas. Por lo tanto, cualquier esfuerzo enproveer soluciones para éste tipo de empresasdebería considerar las características de ellas.

Tipo de proyecto: las PEDS desarrollan proyec-tos que usualmente duran hasta seis meses [31,24]. Sus proyectos están enfocados hacia nichosde negocio específicos debido a que se van es-pecializando en ciertos dominios de negocio [2].

Tamaño del equipo de desarrollo: los equiposde desarrollo usualmente son pequeños. Varíanentre tres a diez personas [29, 2]. El beneficio deusar equipos de desarrollo pequeños es que elcosto de la coordinación se reduce considera-blemente [17].

Surveys

58

Recursos: las PEDS usualmente tienen accesolimitado a recursos humanos, tecnológicos yeconómicos [27, 5]. Los recursos económicosson considerados los más críticos para este tipode empresas. Su liquidez depende mucho de lasganancias de sus proyectos [18, 20].

Personal de trabajo: Su personal tiene un nivelde preparación medio a bajo. Las PEDS no siem-pre pueden contratar personal altamente califi-cado y experimentado [22]. Usualmente contra-tan profesionales con un know-how general envez de especialistas [7]. Su personal, principal-mente aquellos dedicados al desarrollo de soft-ware, frecuentemente trabajan en diferentesroles en los proyectos [24, 17].

Procesos de software: el proceso de desarrollode software de las PEDS es típicamente informaly muchas veces es un proceso ad-hoc [12, 36].

Administración de proyectos: las PEDS pla-nean, organizan, dirigen, monitorean y controlansus proyectos con un alto nivel de informalidad[4, 23].

Complejidad de sus productos: los proyectosde software ejecutados por las PEDS usualmenteson para construir productos de software simples

Existen muchos factores que influyen en el éxitode los proyectos de software. Sin embargo, esbien reconocido que el uso de buenas prácticasde desarrollo de software contribuye positiva-mente al éxito de los proyectos. Por lo tanto, eluso de estas prácticas debería ser motivo deatención por parte de las PEDS.

Varios países y algunas organizaciones han he-cho esfuerzos con el objetivo de proponer unconjunto de buenas prácticas de desarrollo desoftware para las pequeñas empresas de soft-ware (ver Tabla 1 ). Estas propuestas fuerondiseñadas tomando en consideración las carac-terísticas de las PEDS.

ISO/IEC 29110(BASIC PROFILE)El standard ISO/IEC 29110 (Basic Profile) [15] fuediseñado exclusivamente para empresas de de-sarrollo de software con menos de 25 empleados.Fue desarrollado por la Organización Internacio-nal para la Normalización (ISO) en conjunto conla Comisión Electrónica Internacional (IEC). Elobjetivo de este nuevo estándar es que las

[12]. En consecuencia, estas empresas puedenabordar estos proyectos con procesos simples.

Estructura organizacional: comúnmente lasPEDS tienen una estructura organizacional infor-mal con roles y responsabilidades vagamentedefinidos [24, 23, 17]. La estructura organizacio-nal es casi siempre plana o tiene pocos nivelesde jerarquía [7, 6].

PROPUESTAS DEBUENAS PRÁCTICASDE DESARROLLO DESOFTWARE PARALAS PEDSComo fue mencionado en la sección anterior,una de las características más críticas de las PEDSes su ajustada liquidez. No tienen un fuerte res-paldo financiero. Para muchas de ellas el fracasode un solo proyecto podría significar la banca-rrota total de la empresa. Son empresas frágiles.Por lo tanto, necesitan tener éxito en sus proyec-tos para seguir siendo parte activa de la industriadel software.

Surveys

1 DD : documentación disponible desde Internet.2 Idioma : idioma en la que está redactada la documentación.3 #AP : número de áreas de proceso.

TABLA 1.PROPUESTAS DE PRÁCTICAS PARA PEDS.

ID PROPUESTA TIPO AÑO PÚBLICO OBJETIVO BASADO EN DD1 IDIOMA2 # AP3

1 ISO/IEC 29110 Estándar de Software 2011 Todos los países MoproSoft , ISO/IEC 12207, Si Español 2(Basic Profile) [15] ISO/IEC 15504, ISO 9000

2 Tutelkan [34] Proceso de Software 2009 Chile CMMI-Dev, ISO 9001, Si Español 18de Referencia ISO/IEC 15504

3 Competisoft [26] Proceso de Software 2007 Países MoproSoft, MPS.BR, Métrica, Si Español 10de Referencia Iberoamerica Mantema, AgileSPI

4 MPS.BR [37] Estándar de Software 2003 Brasil ISO/IEC 12207, ISO/IEC 15504, Si Español 19CMMI-DEV

5 MoproSoft [25] Estándar de Software 2002 México ISO/IEC 12207, ISO/IEC, No Español 9ISO/IEC 15504, ISO 9000, CMMI, PMBOK

59

pequeñas empresas de software puedan mejorarel desempeño de sus procesos y de esta maneralogren un reconocimiento internacional dentro dela industria del software. Propone que una PEDSdebería implementar dos áreas de proceso, Gestióndel Proyecto e Implementación del Software. Paracada una de estas áreas de proceso, el estándar29110 provee un conjunto detallado de buenasprácticas [16].

TUTELKANEl proyecto Tutelkan [34] propone una estrategiade mejoramiento de procesos de software para laspequeñas empresas de desarrollo de software deChile. Fue el resultado de un proyecto financiadopor el Gobierno chileno. En dicho proyecto partici-paron dos universidades chilenas (Universidad Téc-nica Federico Santa María y la Universidad de Chile),la Sociedad Chilena de Software y Servicios (GECHS),la Asociación Chilena de Empresas de Tecnologíade Información (ACTI), el Software Process Impro-vement Network (SPIN Chile) y la empresa KeplerTechnology S.A. El objetivo de este proyecto fuedesarrollar un proceso de software de referenciade acceso público, el cual podría ser usado por laspequeñas empresas de software chilenas para de-finir y documentar sus propios procesos de desa-rrollo de software que les permitiera lograr unafutura certificación ISO 9001 y CMMI. Esta propuestapresenta una serie de buenas prácticas de desarrollode software para cada una de las 18 áreas de pro-ceso que propone [10, 11] (ver Tabla 2).

COMPETISOFTCompetisoft es un marco metodológico orientadoa mejorar los procesos de las pequeñas y medianasempresas de desarrollo de software de Iberoamérica[26]. Su desarrollo fue financiado por el ProgramaIberoamericano de Ciencia y Tecnología para elDesarrollo (CYTED). Fue el resultado de un trabajoconjunto de investigadores provenientes de másde diez universidades iberoamericanas, el Instituto

TABLA 2.ÁREAS DE PROCESO DE TUTELKAN.

Argentino de Normalización y Certificación(IRAM), y pequeñas empresas de desarrollo desoftware de ocho países de Iberoamérica. Com-petisoft incluye buenas prácticas de desarrollo

de software para cada una de las diez áreas deprocesos que propone [14] (ver Tabla 3).

Surveys

CATEGORÍA ÁREAS DE PROCESO

Gestión de Proyectos • Administración de Requerimientos

• Planificación del Proyecto

• Monitoreo y Control del Proyecto

• Administración de Acuerdos con Proveedores

• Medición y Análisis

• Administración de Calidad de Procesos y Productos

• Administración de Configuraciones

Desarrollo y Mantención de Software • Desarrollo de Requerimientos

• Análisis y Diseño

• Programación

• Pruebas

• Instalación

Gestión Avanzada de Proyectos • Gestión de Riesgos

• Evaluación Formal de Decisiones

• Administración Integrada del Proyecto

Gestión de Procesos • Definición de Procesos Organizacionales

• Mejoramiento de Procesos Organizacionales

• Entrenamiento Organizacional

TABLA 3.ÁREAS DE PROCESO DE COMPETISOFT.


Alta Dirección • Gestión de Negocio

Gerencia • Gestión de Procesos

• Gestión de Cartera de Proyectos

• Gestión de Recursos

• Gestión de Recursos Humanos

• Gestión de Bienes, Servicios e Infraestructura

• Gestión de Conocimiento

Operación • Administración del Proyecto

• Desarrollo de Software

• Mantenimiento de Software

MPS.BRMPS.BR es un programa de mejoramiento de pro-cesos de desarrollo de software para las pequeñasy medianas empresas de la industria de softwarebrasileña [37]. Este programa es coordinado porla Asociación para Promoción de la Excelencia delSoftware Brasileño (SOFTEX). Cuenta con el apoyodel Ministerio de Ciencia, Tecnología e Innovación(MCTI), del Servicio Brasileñode Apoyo a las Microy Pequeñas Empresas (SEBRAE) y del Banco Inte-ramericano de Desarrollo (BID/FUMIN). Esta normadescribe en detalle un conjunto de buenas prácti-cas para cada uno de las 19 áreas de procesos quepropone [30] (ver Tabla 4).

directamente. En consecuencia, no se requiereque las PEDS tengan que invertir dinero en suadquisición.

También se puede observar que todas ellas estánredactadas en idioma español. En consecuencia,las PEDS no tendrían problemas para leerlas ycomprenderlas.

mejorar sus procesos de software, es iniciar conel standard ISO/IEC 29110. Incluye un númerominimal de buenas prácticas.

Todas las propuestas, con excepción de Mopro-soft, proporcionan acceso libre a su documenta-ción. Dichas propuestas pueden ser bajadas (sincosto alguno) desde sus sitios web y usadas

TABLA 5.ÁREAS DE PROCESO DE MOPROSOFT

Surveys


Alta dirección • Gestión de Negocio

Gerencia • Gestión de Procesos

• Gestión de Proyectos

• Gestión de Recursos

- Recursos Humanos y Ambiente de Trabajo

- Bienes Servicios e Infraestructura

- Conocimiento de la Organización

Operación • Administración de Proyectos Específicos

• Desarrollo y Mantenimiento de Software

MOPROSOFTMoprosoft [25] es un standard mexicano creadopara ayudar a las pequeñas empresas de desarro-llo de software mexicanas a mejorar sus procesosde software. Fue desarrollado a solicitud de laSecretaría de Economía de México con el apoyode la Facultad de Ciencias de la Universidad Na-cional Autónoma de México (UNAM). Moprosoftincluye una serie de prácticas para cada una desus nueve áreas de procesos que propone ( verTabla 5).

De las cinco propuestas descritas anteriormentese puede observar que Tutelkan y MPS.BR tienencasi el mismo número de áreas de proceso (18 y19 respectivamente). Lo mismo ocurre con Mo-prosoft y Competisoft (9 y 10 respectivamente).Solamente el estándar ISO/IEC 29110 proponeun número muy reducido de áreas de proceso (2procesos). Estos resultados sugieren que quizásla mejor opción, para aquellas PEDS que desean

60

• Gestión de Reutilización

• Desarrollo de Requisitos

• Integración del Producto

• Diseño y Construcción del Producto

• Validación

TABLA 4.ÁREAS DE PROCESO DE MPS.BR.

• Gestión de Proyectos

• Gestión de Requisitos

• Adquisición

• Gestión de Configuración

• Aseguramiento de la Calidad

• Gestión de Portafolios de Proyectos

• Medición

• Evaluación y Mejora del Proceso Organizacional

• Definición del Proceso Organizacional

• Gestión de Recursos Humanos

• Verificación

• Desarrollo para Reutilización

• Gestión de Decisiones

• Gestión de Riesgos

61

content/uploads/2009/06/trp-v20-basico.pdf(última visita: junio 2015).

[11] Federico Santa María Technical University(Chile). “Tutelkan Reference Process (TRP) Versión2.0 Parte 3: TRP Básico”, 2009.http://www.tutelkan.info/blog/wp-content/uploads/2009/06/trp-v20-avanzado.pdf(última visita: junio 2015).

[12] M. Harris, K. Aebischer, T. Klaus. “The whi-tewater process: software product developmentin small IT businesses”. Communications of theACM, Vol. 50, No. 5, pp. 89–93, 2007.

[13] C. Hofer. “Software development in Austria:results of an empirical study among small andvery small enterprises”. Proc. of the 28th IEEEEUROMICRO Conference, pp. 361–366, 2002.

[14] Ibero-American Program of Science andTechnology (CYTED). “Competisoft Document–Process Improvement to Promote the Competi-tiveness of the Ibero-American Small and Me-

[6] K. El Emam. “Multi-Method Evaluation of thePractices of Small Software Projects”. Proc. of the1st Int. Research Workshop for Process Improve-ment in Small Settings, pp. 12–17, 2005.

[7] L. Estrin, J. Foreman, S. Garcia. “OvercomingBarriers to Technology Adoption in Small Manu-facturing Enterprises (SME)”. Technical ReportCMU/SEI-2003-TR-012, 2003.

[8] European Commission. “The new SME defini-tion User guide and model declaration”. WhitePaper, May 2003. http://ec.europa.eu/ enterpri-se/policies/sme/files/sme_definition/sme_user_guide_en.pdf (última visita: junio 2015).

[9] M.E. Fayad, M. Laitinen, R.P. Ward. “SoftwareEngineering in the Small”. Communications ofthe ACM, Vol. 43, No 3, pp. 115–118, Mar. 2000.

[10] Federico Santa María Technical University(Chile). “Tutelkan Reference Process (TRP) Versión2.0 Parte 2: TRP Básico”, 2009.http://www.tutelkan.info/blog/wp-

REFERENCIAS

[1] ABES Software. “Brazilian Software MarketScenario and Trends”, 2014.

[2] J. Aranda, S. Easterbrook, G. Wilson.“Requirements in the wild: How small companiesdo it”. Proc. of the 15th IEEE Requirements Engi-neering Conference, pp. 39–48, 2007.

[3] M. Ayyagari, T. Beck, A. Demirguc-Kunt. “Smalland medium enterprises across the globe”. Jour-nal of Small Business Economics, Springer, Vol.29, No. 4, pp. 415–434, 2007.

[4] J. Batista, A.D. De Figueiredo. “SPI in a VerySmall Team: a Case with CMM”. Journal of Soft-ware Process: Improvement and Practice, JohnWiley & Sons, Ltd., Vol. 5, No. 4, pp. 243–250,2000.

[5] J. Dorr, S. Adam, M. Eisenbarth, M. Ehresmann.“Implementing Requirements Engineering Pro-cesses: Using Cooperative Self-Assessment andImprovement”. IEEE Software, Vol. 25, No. 3, pp.71–77, May/Jun. 2008.

CONCLUSIONES

LAS CARACTERÍSTICAS PARTICULARES DE LAS PEQUEÑAS EMPRESAS DE DESARROLLO DE SOFTWARE (PEDS) MUESTRAN QUEESTE TIPO DE COMPAÑÍAS SON TOTALMENTE DISTINTAS DE LAS MEDIANAS Y GRANDES COMPAÑÍAS. POR LO TANTO, ESTASCARACTERÍSTICAS DEBERÍAN SER TOMADAS EN CONSIDERACIÓN AL MOMENTO DE DISEÑAR SOLUCIONES PARA ESTE TIPO DEEMPRESAS.

ACTUALMENTE EXISTEN PROPUESTAS DE PRÁCTICAS DE DESARROLLO DE SOFTWARE QUE PUEDEN AYUDAR A ESTASEMPRESAS A MEJORAR LA FORMA EN QUE DESARROLLAN SUS PRODUCTOS Y DE ESTA MANERA INCREMENTAR SU TASA DEÉXITO. LA VENTAJA DE ESTAS PROPUESTAS ES QUE HAN SIDO DESARROLLA DAS TOMANDO EN CONSIDERACIÓN LASCARACTERÍSTICAS DE ESTAS COMPAÑÍAS. POR LO TANTO, LAS PEDS PUEDEN RECURRIR A ELLAS CON LA CERTEZA DE QUEESTARÁN USANDO SOLUCIONES QUE CALZAN CON LAS CARACTERÍSTICAS QUE LAS HACEN DISTINTAS DE LAS MEDIANASY GRANDES COMPAÑÍAS.

Surveys

Scenario”. Engineering Thesis (In Spanish), Com-puter Science Department, University of Chile,2003.

[32] A. Tahir, R. Ahmad. "Requirements Enginee-ring Practices - An Empirical Study". Proc. of theIEEE Int. Conf. on Computational Intelligenceand Software Engineering, pp. 1–5, 2010.

[33] A. Talbot, A. Connor. “Requirements Engi-neering Current Practice and Capability in Smalland Medium Software Development Enterprisesin New Zealand”. Proc. of the 9th IEEE Int. Conf.on Software Engineering Research, Managementand Applications, pp. 17–25, 2011.

[34] G. Valdés, H. Astudillo, M. Visconti, C. López.“The Tutelkan SPI Framework for Small Settings:A Methodology Transfer Vehicle”. Journal ofSystems, Software and Services Process Impro-vement, Springer, Vol. 99, pp. 142–152, 2010.

[35] M. Varela. “Diagnosis of the Chilean IT Indus-try – 2003. Diagnóstico de la industria de lastecnologías de la información en Chile 2003”. (inSpanish). White Paper, CHILE INNOVA Program.2003.http://www.dcc.uchile.cl/~aquispe/docs/tics_chile_2003.pdf (última visita: junio 2015).

[36] C.G. von Wangenheim, T. Varkoi, C.F. Salvia-no. “Standard based software process assess-ments in small companies”. Journal of SoftwareProcess: Improvement and Practice, John Wiley& Sons, Ltd., Vol. 11, No. 3, pp. 329–335, 2006.

[37] K.C. Weber, E. Araújo, A. Rocha, C.A.F. Machado,D. Scalet, and C.F. Salviano. “Brazilian SoftwareProcess Reference Model and Assessment Method”.LNCS Computer and Information Sciences, Sprin-ger, Vol. 3733, pp. 402–411, 2005.

Research Workshop for Process Improvement inSmall Settings, pp. 5–10, 2005.

[23] J. Montilva, J. Barrios, M. Rivero. “Trainingrequirements and profiles for software engineersin Micro and Small Enterprises” (in Sspanish). CLEI2009.

[24] S.F. Ochoa, J.A. Pino, L.A. Guerrero, C. Collazos.“SSP: A Simple Software Process for Small-SizeSoftware Development Projects”. Proc. of the IFIPInternational Workshop on Advanced SoftwareEngineering, Springer Science + Busi-ness Media, Vol. 219, pp. 94–107, 2006.

[25] H. Oktaba. “MoProSoft: A Software ProcessModel for Small Enterprises”. Proc. of the 1st Int.Research Workshop for Process Improvement inSmall Settings. Special Report CMU/SEI-2006-SR-001.

[26] H. Oktaba, F. García, M. Piattini, F. Ruiz, F.J.Pino, C. Alquicira. “Software process improvement:The Competisoft project”. IEEE Computer, Vol. 40,No. 10, pp. 21–28, 2007.

[27] I. Richardson, C.G. von Wangenheim. “WhyAre Small Software Organizations Different?”. IEEESoftware, Vol. 24, No. 1, pp. 18–22, Jan./Feb. 2007.

[28] M. Rönkkö, E. Eloranta, H. Mustaniemi, O. Mu-tanen, J. Kontio. “National Software Industry Survey2008: The Finnish Software Industry in 2007”. Hel-sinki University of Technology, 2007.

[29] S. Rowe. “Project Management for SmallProjects”. Management Concepts, 2006.

[30] Association to Promote Excellence in BrazilianSoftware (SOFTEX). “Modelo de Referencia MR-MPS Reference Model” (in Spanish), 2011. URL:h t t p : / / w w w . s o f t e x . b r / m p s b r / g u i a - e m -espanhol/ (última visita: junio 2015).

[31] W. Stein. “A Web Software Process for Smallor Medium-Sized Projects Focused on the Chilean

dium Software Industry” (in Spanish), 2008.http://alarcos.esi.uclm.es/ipsw/doc/Competisoft-modelo_v1.pdf (última visita: junio 2015).

[15] ISO/IEC. “ISO/IEC 29110 (Basic Profile)”,2011.http://profs.etsmtl.ca/claporte/English/VSE/index.html (última visita: junio 2015).

[16] ISO/IEC. DTR 29110-5-1-2 Software Enginee-ring - Lifecycle Profiles for Very Small Entities(VSEs) - Part 5: Management and EngineeringG u i d e - B a s i c V S E P r o f i l e , 2 0 1 1 .http://standards.iso.org/ittf/PubliclyAvailableStandards/c051153_ISO_IEC_TR_29110-5-1_2011.zip (última visita: junio 2015).

[17] S. Jantunen. “Exploring software engineeringpractices in small and medium-sizedorganizations”. Proc. of the 2010 ICSE Workshopon Cooperative and Human Aspects ofSoftware Engineering, ACM, pp. 96–101, 2010.

[18] B. Keane, I. Richardson. “Quality: Attitudesand Experience Within the Irish SoftwareIndustry”. LNCS Software Process Improvement,Springer, Vol. 3792, pp. 49–58, 2005.

[19] C.Y. Laporte, S. Alexandre, A. Renault.“Developing International Standards for VerySmall Enterprises” IEEE Computer, Vol. 41, No.3, pp. 98–101, Mar. 2008.

[20] C.Y. Laporte, S. Alexandre, R.V. O’Connor.,“A software engineering lifecycle standard forvery small enterprises”, Proc. of the 15th Euro-pean System & Software Process Improvementand Innovation, Springer, Vol. 16, pp. 129–141,2008.

[21] R. Matulevicius. “Survey of RequirementsEngineering Practice in Lithuanian SoftwareDevelopment Companies”. Information SystemsDevelopment, Springer, pp. 327–339, 2005.

[22] O. Mondragon. “Addressing infrastructureissues in very small settings”. Proc. of the 1st Int.

Surveys

62

editorial - sitio web dcc · alejandro hevia entrevista a nuestro exa- ... la saga del profesor...

Documents