A continuación cito textualmente el resumen realizado por Ernesto Cuadros, que represento a Perú por la SPC.

- Introducción a cargo de Benjamín Barán (past president de CLEI). El CLEI se inicio en 1972 con el denominado “Panel de Topicos en Informatica” organizado en Chile. Luego en 1974 ya se organizo un encuentro latinoamericano en el Hotel Sheraton de Caracas. Esta es la fecha considerada como inicio de CLEI. En 79 se formalizo el nombre de CLEI. Luego se hicieron conferencias en diversas ciudades. (Acaban de mencionar todas las ciudades y la edicion de Peru de 1981 no fue mencionada pero todas las otras si).
- Habla Jorge Vidart (Uruguay) quien fuera pdte del CLEI al inicio de los 80’s. Menciona que vivio la historia en Uruguay desde sus inicios. Divide la historia en cuatro etapas.

1.- Prehistoria- del 63 al 73 al inicio era irregular. Ya en el 67 el pais reacciona y crean el instituto de computacion en el Uruguay. En 68 se funda la carrera. La base fue la ACM de aquella epoca. El arranque fue con una escuela organizada con Jean Paul Jacob que trajo docentes de Berkeley a
dictar cursos en convenio con la USP de Brasil. De ahi salieron varios de los que serian lideres en el area en Brasil y Uruguay tambien.
2.- Historia (73-85) dictadura en el pais. Los sacaron a todos de las universidades. Muchos fueron expulsados.
3.- Tiempos modernos (85) no habian profesores. La carrera estaba en la facultad de Ingenieria. El 86 consigue convencer que la informatica era tan importante como las ciencias basicas, se hicieron maestrias en ciencias computacionales atraves del ESLAI.
4.- Postmodernismo. (desde 2007) el nuevo gobierno decidio incursionar en el proyecto de darle una laptop a cada niño de colegios. En septiembre de 2009 se entregaron las ultimas de las laptops a todos los niños del Uruguay. Todos los colegios ya tienen Wi-Fi.
- Habla Diego Andrade (Ecuador). Ecuador recibia muchos recursos producto del petroleo en la decada de los 70’s. Al area de bancos aprovecho muy bien los ingresos producidos. Muchos Argentinos fueron a trabajar en el área privada. En los 80’s se comenzaron a crear las primeras carreras de Ing Informática e Ing de Sistemas. Antes de los 80’s habia formación de tecnólogos. Hubo mucha irresponsabilidad del gobeirno que aprobo muchas carreras y/o universidades sin calidad y todas ellas ponian al menos una carrera de Ing de Sistemas (Esto parece familiar). Eso ha generado un
atraso. Hoy se está trabajando en la acreditaciuon y eso va a provocar que muchas dejen de funcionar.
El siguiente paso ha sido crear maestrias, aun no se cuenta con doctorados.
El presidente Correa esta gestando una ley que obliga a que uno de los requisitos para ser docente universitario es tener un doctorado de nivel a tiempo completo fuera del pais. Es un hecho que la ley se va a aprobar pues el presidente tiene una gran mayoria en el congreso.
- Habla Ernesto Cuadros (Peru) Según un informe reciente del Colegio de Ingenieros del Perú el origen tuvo influencia de la IBM pero no hay un consenso debido a la falta de documentacion escrita de esa epoca. En la decada de los 80 hubo influencia europea creando Ing Informatica y luego hubo una proliferacion de nombres. nomenclaturas y contenidos que ahora ya se esta reorganizando. Peru observa con atencion las propuestas de IEEE-ACM y existe un gran interes en poder alinearse. Creo que las perspectivas son muy positivas debido a que las diversas conversaciones de los ultimos anhos han hecho notar la necesidad de un cambio. El ambiente es propicio y existe un numero interesante de universidades que estan apostando por la alineacion a las propuestas internacionales. La SPC ha venido trabajando por creasr un modelo de malla curricular que esta generando un buen interes de parte de las instituciones en el pais y que ya cuenta con el apoyo de IEEE y sera presentado en este CLEI como una charla.
- Jorge Aguirre (Uruguay). Comienza comentando que la computadora y la informática es el hito más importante del siglo XX e influye enormemente (con velocidad exponencial) en nuestra sociedad. Es nuestra responsabilidad mantener la memoria de los procesos.
- Felipe Navaux (Brasil) En 1950 las primeras calculadoras eran comercializadas. En 1959 se inicia la venda de computadores en Brasil. Esta area se inicio en 1960 en la PUC de Rio. En 1968 de abre la primera maestria seguido en 1975 de un doctorado. Las maestrias surgieron practicamente al mismo tiempo que los pregrados. En los 70 habia mucha gente que reclamaba a la informatica como parte del area de matematica y otros como parte de ingenieria. En 1972 se crea el Dpto de Ciencia de la Computacion en la UFMG. En la UFRGS se compra una maquina IBM en los 60’s, en 1972 se crea la
primera maestria y en 1979 el primer doctorado. En el ICMC de Sao Carlos se crea con influencia de los matematicos. La carrera de la UNICAMP fue posterior porque la universidad es mas reciente. Los números hasta 2006 son: hay 1764 carreras.
- Ramon Puigjaner (España). Visión externa sobre la informatica en América Latina (AL). Ha estado trabajando con AL en los ultimos 30 años. Esta involucrado con CLEI desde 1991. Su percepción es que ya se nota una fuerte exigencia en la selección de los articulos en los eventos latinoamericanos.
- Habla Raul Carnota (Argentina). Hay muchas historias oficiales que en muchos casos es solo una cronologia. En los ultimos 2 anhos hay un esfuerzo por revalorar y documentar la hiustoria del area en Argentina y Chile.
- Habla Ivan da Costa (Brasil) Hace menos de un mes fue publicado en la revista Veja de Brasil que una de las cosas mas estupoidas de la decada de los 80 fue la de intentar hacer una reserva de mercado para los computadores pretendiendo que los brasilenhos solo trabajasen con tecnologia
hecha en Brasil. Estaba prohibido traer tecnologia de fuera con el objetivo de sea creada en Brasil. Eso tuvo un efecto adverso. El mercado es global y no se puede pensar en capsulas cerradas.
- Habla Tomás Lópéz (Cuba). Erneso Che Guevara fue quien marco el inicio del desarrollo de estas areas en Cuba. la www.uci.cu tiene en la actualidad 11 mil estudiantes en la carrera de Informatica. (Ojo que es una sola institucion !!!!)
- Habla Gabriela Marín. Fue Clara Somer (Ing Civil) quien logro que IBM le diera una primera maquina de 70mil dolares.

A team of IBM researchers are working on building a new kind of memory. Ones that are smaller, faster, cheaper to build, and that use less power. In this Robert Scoble’s interview Stewart Parkin, team leader, describes how they are approaching to such thing. Funny thing, as most science developments are, is that they aren’t actually discovering something new. They are simply using physics rules, well known for years, for their purpose. What we’ll get in the future out of this are less power consuming, smaller, faster and cheaper memories. This opens the door for microdevices, nanotechnology, scientific computing and mass processing.

• IBM research: In search of smaller, faster, cheaper memories

  A team of IBM researchers who are working to build new kinds of memories. Ones that are smaller, faster, cheaper to build, and that use less power.

  tags: technology, ibm, emergingtechnologies, memory, research, video

Posted from Diigo. The rest of my favorite links are here.

En mi opinión es importante que se realicen este tipo de concursos para fomentar y desarrollar la investigación en nuestro país. A través de este post quiero invitar a los estudiantes, investigadores y emprendedores a participar del mismo. A continuación copio las partes más relevantes de la convocatoria. Puede descargar las bases y material relacionado desde la web del concurso.

I. COMPONENTES DEL CONCURSO

El concurso está organizado en dos categorías:

CATEGORÍA I

Estudios de prácticas exitosas de innovación empresarial

Seis (06) premios de investigación de 7,000 dólares americanos cada uno

Se seleccionarán las seis (06) mejores propuestas de investigación que documenten prácticas exitosas de innovación tecnológica en empresas peruanas. Para propósitos del presente concurso, se considera la innovación tecnológica tanto a nivel de productos como de procesos, la cual debe derivar necesariamente en la introducción de bienes y servicios en los mercados.

Los ganadores del concurso recibirán un premio de 7,000 dólares americanos, el cual deberá cubrir todos los gastos asociados a la investigación, incluídos los impuestos de ley. Los estudios deberán ser realizados en un lapso de tres (03) meses. Los estudios de caso deberán enfocarse en uno de los sectores priorizados por el FINCyT:

• Textil y confecciones
• Pesca: acuicultura y consumo humano directo
• Agroindustria
• Tecnologías de la Información y de la Comunicación (TICs)

Los estudios de caso ganadores deberán responder a los siguientes objetivos específicos:

• Presentar un breve diagnóstico sobre la situación de la innovación tecnológica en el sector seleccionado, con el fin de colocar al estudio de caso en contexto.
• Producir un perfil de la empresa seleccionada, que incluya, por ejemplo: procesos de formación de competencias internas, mapa general de procesos, capacidad de absorción tecnológica y valoración de la innovación tecnológica.
• Describir analíticamente los procesos y/o productos que forman parte de la innovación exitosa a documentarse.
• Identificar y analizar los factores endógenos y exógenos –tanto a nivel institucional como organizacional- que posibilitaron la incursión de la empresa en el proceso de la innovación exitosa.
• Evaluar la innovación exitosa lograda por la empresa en términos de los resultados y beneficios generados, replicabilidad, complejidad, nivel de generación de tecnologías propias, articulación con otros agentes del sistema nacional de innovación (por ejemplo, universidades) e impacto en la competitividad de la empresa.
• Presentar lecciones aprendidas derivadas del estudio de caso que puedan ser de utilidad para el sector empresarial, así como para elaborar recomendaciones de política pública.

Asimismo, se considerará favorablemente el cumplimiento de los siguientes objetivos:

• Esbozar/aproximar un análisis costo-beneficio de los recursos requeridos para implementar la innovación, incluyendo un costeo de las ganancias derivadas de la implementación de la innovación.
• Identificar y analizar las estrategias implementadas por la empresa para brindar sostenibilidad a la innovación seleccionada.

CATEGORÍA II

Estudios de comportamiento tecnológico empresarial

Tres (03) premios de investigación de 15,000 dólares americanos cada uno

Se seleccionarán las tres (03) mejores propuestas de investigación que analizen el comportamiento tecnológico empresarial de uno de los siguientes sectores priorizados el FINCyT:

• Textil y confecciones
• Pesca: acuicultura y consumo humano directo
• Agroindustria
• Tecnologías de la Información y de la Comunicación (TICs)

Los ganadores del concurso recibirán un premio de 15,000 dólares americanos, el cual deberá cubrir todos los gastos asociados a la investigación, incluídos los impuestos de ley. Los estudios deberán ser realizados en un lapso de cinco (05) meses.

Estos estudios tienen como propósito evidenciar el comportamiento tecnológico diferenciado de los sectores industriales del país, debiendo responder a los siguientes objetivos específicos:

• Proporcionar un diagnóstico exhaustivo sobre la situación de la innovación tecnológica en el sector seleccionado.
• Analizar la estructura del mercado y las características tecnológicas del sector seleccionado.
• Sistematizar los patrones de innovación tecnológica presentes en el sector, distinguiendo los tipos de innovación generadas (I+D, transferencia, adaptación) y los orígenes, orientación y objetivos de las actividades innovadoras.
• Analizar los factores institucionales y organizacionales que han facilitado y/o obstaculizado los procesos de cambio tecnológico en el sector seleccionado.
• Describir y analizar el proceso de gestión de la innovación tecnológica en empresas representativas del sector, detallando los procesos de generación y protección del conocimiento detrás de la innovación, el monitoreo de los resultados producidos por la innovación tecnológica, la difusión de innovación tecnológica, entre otros.
• Describir analíticamente las oportunidades y retos enfrentados por empresas representativas del sector para implementar procesos de innovación tecnológica.
• Identificar y analizar los comportamientos, percepciones y valoraciones empresariales sobre el rol, retorno y utilidad de la inversión en innovación tecnológica.
• Presentar lecciones aprendidas y recomendaciones de política útiles para informar los procesos de toma de decisiones vinculadas al fomento de la competitividad y crecimiento, tanto en el sector público como en el privado.

II. REQUISITOS PARA POSTULAR

Los investigadores interesados en postular al concurso deberán remitir la siguiente documentación en un solo correo electrónico a: innovacion@cies.org.pe. El plazo límite para presentar propuestas es el 01 de marzo 2009.

Acerca de FINCyT

El Programa de Ciencia y Tecnología (FINCyT) es una iniciativa de inversión pública del Poder Ejecutivo y su ejecución está a cargo de la Presidencia del Consejo de Ministros (PCM), a través de la Unidad Ejecutora del Programa.

El objetivo general del FINCyT es el mejoramiento de los niveles de competitividad del país, a través del fortalecimiento de las capacidades de investigación, desarrollo e innovación tecnológica. La presente convocatoria se enmarca en el cuarto objetivo del programa: (iv) promover las investigaciones en ciencia y tecnología de forma que contribuyan sustancialmente a la mejora de la competitividad empresarial.

El concurso FINCyT – CIES busca contribuir a dichos objetivos al promover la documentación de experiencias exitosas de innovación tecnológica en empresas peruanas, así como incentivar la investigación sobre los procesos de cambio tecnológico en el sector empresarial. Se espera que los nuevos conocimientos sean de utilidad para el sector empresarial, el sector público y la comunidad académica.

Computing disciplines

Perfiles de computación

La Computing Curricula, versión 2005-marzo, define 5 disciplinas o perfiles: Ciencia de la Computación (Computer Science) [Chang et al., 2001], que tiene por objetivos diseñar e implementar software, concebir nuevas formas de usar computadoras, y desarrollar métodos eficientes para resolver problemas de computación; Ingeniería de Computación (Computer Engineering) [Soldan et al., 2004], cuyo objetivo es el diseño y construcción de computadoras y sistemas basados en computadoras y tiene mayor énfasis en el estudio del hardware; Ingeniería de Software (Software Engineering) [Díaz-Herrera and Hilburn, 2004], cuyo foco es el desarrollo y mantenimiento de sistemas de software para que se commporten confiable y eficientemente, sean accesibles para desarrollar y mantener, y cumplan todos los requisitos que han definido los clientes; Sistemas de Información (Information Systems) [Gorgone et al., 2002], que se enfoca en la integración entre soluciones de tecnologías de información y procesos de negocio para cubrir las necesidades de información de las empresas, habilitandolas para cumplir sus objetivos de forma efectiva y eficiente; y Tecnología de la Información (Information Technology) [ACM and IEEE-CS, 2005], que tiene énfasis en la propia tecnología más que en la información que transporta, por ende su énfasis está en las necesidades prácticas, de día a día, de las empresas y otras organizaciones.

Programas de computación en el Perú

Desde la creación de la escuela de computación científica en San Marcos, que todavía existe, en el Perú se han creado un buen número de facultades referentes a computación. Sin embargo, la curricula de cada una de éstas, además de la denominación de las carreras, generalizada en los años 80, presentan una gran divergencia y variedad de enfoques. Tal es así que la carrera de “Ingeniería de Sistemas” tiene diverso enfoque y propósito de acuerdo a la facultad. En el caso de la UNI, está orientada a aspectos totalmente ajenos a la computación con un enfoque bajo el “pensamiento sistémico” propuesto por Ludwing Von Bertalanffy. Para otras facultades, está orientada a la gestión de tecnologías y sistemas de información. Estas divergencias representan un problema en diversos aspectos: identificación de perfiles, identificación de capacidades, orientación de desarrollo profesional, reconocimiento e identificación social de capacidades, saturación de mercado laboral, etc.

Durante los últimos años la Sociedad Peruana de Computación ha venido trabajando en dar a conocer esta irregular situación y los problemas que representa para el país. Parte de este trabajo ha sido la elaboración de una versión de la Computing Curricula adaptada a las necesidades del Perú, conocida como PCC. En complemento a esta labor, Marco Alvarez y José Baiocchi, estudiantes de postgrado, han elaborado una herramienta de software que permite mapear la CC2005-ACM frente a las curriculas de las carreras relacionadas con computación en el Perú.

Análisis de programas versus perfiles de computación

Gracias a este software y la contribución de profesores y estudiantes de las universidades del país, se puede ver gráficamente hasta que punto las curriculas de las carreras de computación cumplen con el estándar CC2005. Estos gráficos también permiten ver qué tipo de perfil tienen los egresados de estas facultades, pero, aún más importante, permiten conocer cual es el enfoque de la carrera. Para la creación del gráfico, conocido como “radar“, se contemplan todos los cursos de la curricula agrupados en: Ciencia de la Computación, Ingeniería de Software, Tecnologías de Información, Sistemas de Información, Organización y Negocios, Sistémica e Ingeniería, Formación Profesional y Humanidades, Ciencias Básicas, Electrónica, Harware y Arquitectura, y Matemática para Computación. Luego, en base al número de créditos y un cálculo de porcentaje se determina el cubrimiento de cada perfil.

Las últimas semanas concluí la tarea que me había propuesto realizar: mapear los perfiles de las carreras de Ingeniería de Software y Sistemas de Información de mi universidad, la UPC, para validarlas con esta herramienta de software. El resultado obtenido ha sido bastante interesante. Por un lado, muestra que los perfiles están definidos adecuadamente y el enfoque es diferenciado. Por otro lado, muestra que todavía existen algunos vacíos y excesos en la cobertura de temas y cursos para cada cada perfil.

UPC

Ingeniería de Software vs. Software Engineering CC2005

UPC - Ingeniería de Software vs. Software Engineering CC2005

Sistemas de Información vs. Information Systems CC2005

UPC - Ingeniería de Sistemas vs. Sistemas de Información CC2005

Para el caso de las otras universidades comparamos sus curriculas con los perfiles de Sistemas de Información y Ciencia de la Computación.

Lima

UNMSM – Ingeniería de Sistemas vs. Computer Science CC2005

UNMSM - Ingeniería de sistemas vs. Computer Science CC2005

UNMSM – Ingeniería de Sistemas vs. Information Systems CC2005

UNMSM - Ingeniería de Sistemas vs. Information Systems CC2005

PUCP – Ingeniería Informática vs. Computer Science CC2005

PUCP - Ingeniería Informática vs. Computer Science CC2005

PUCP – Ingeniería Informática vs. Information Systems CC2005

PUCP - Ingeniería Informática vs. Sistemas de Información CC2005

UNI – Ingeniería de Sistemas vs. Computer Science CC2005

UNI - Ingeniería de Sistemas vs. Computer Science CC2005

UNI – Ingeniería de Sistemas vs. Sistemas de Información CC2005

UNI - Ingeniería de Sistemas vs. Sistemas de Información CC2005

Arequipa

UCSP – Ingeniería Informática vs. Computer Science CC2005

PUCP - Ingeniería Informática vs. Computer Science CC2005

UCSP – Ingeniería Informática vs. Sistemas de Información CC2005

UCSP - Ingeniería Informática vs. Sistemas de Información CC2005

UNSA – Ingeniería de Sistemas vs. Computer Science CC2005

UNSA - Ingeniería Informática vs. Computer Science CC2005

UNSA – Ingeniería de Sistemas vs. Sistemas de Información CC2005

UNSA - Ingeniería Informática vs. Sistemas de Información CC2005

Trujillo

UNT – Ingeniería Informática vs. Computer Science CC2005

UNT - Ingeniería Informática vs. Computer Science CC2005

UNT – Ingeniería Informática vs. Sistemas de Información CC2005

UNT - Ingeniería Informática vs. Sistemas de Información CC2005

Que tal Rudy te saluda Cristian Villalta acabo de leer el articulo y me parece de mucha utilidad pues justo ando trabajando en una tesis relacionada a la gestion de proyectos y software libre. Queria hacerte un par de preguntas:
Que problemas son los mas comunes, desde tu punto de vista, en la gestion de proyectos … y … cual es el impacto del Sw libre en la gestion de proyectos, desde ya agradecido.

Saludos.

Originally posted as a comment by Criso on a subversive act of playful cleverness using Disqus.

Los problemas que he observado en los proyectos de software tienen que ver generalmente con respecto a la gestión de equipo y recursos. Por otro lado, uno de los temas que presenta muchas situaciones complicadas es la definición del ámbito del proyecto y los requisitos del mismo. De hecho, hoy, existe una rama de software que se dedica específicamente a la ingeniería de requisitos.

Para el primer caso, el software libre tiene la ventaja de que los integrantes del equipo o proyecto trabajan en aspectos que son de su interés, de esta manera el proyecto en global se beneficia teniendo mejores resultados, personas comprometidas y apasionadas con su trabajo. Sin embargo, esto presenta el problema de que, generalmente, se pierde un poco el sentido de visualización integral del proyecto, cosa que se suele mejorar con la incorporación de roles de coordinación, por ejm. lo que hace Linus Torvalds o Andrew Morton en el kernel linux.

Además, gracias a las herramientas que ha adoptado la comunidad de software libre para soportar su desarrollo, los procesos generalmente tiene un soporte adecuado por lo que se hacen, hasta cierto punto, eficientes. A medida de que una organización tenga sus procesos mejor estructurados y estandarizados podrá obtener mejor provecho de las herramientas que tiene disponibles, y no al contrario. Esto último es algo que observo en muchas organizaciones, generalmente adquieren software que puede ofrecerles infinidad de posibilidades, razón por la cual otras empresas lo emplean, sin embargo al no tener la base definida es poco el provecho que obtienen pues no se busca optimizar el proceso a través del empleo herramientas.

Respecto al tema de definición de requisitos y ámbito del proyecto, podemos tomar, del software libre, como aspecto relevante la constante interacción con el usuario final a través de sus procesos de retroalimentación y la publicación de versiones en etapa temprana (beta). Esto permite que el desarrollo se realice a medida que se encuentre una necesidad del usuario. Sea un informe de fallo, solicitud de características nuevas, modificación de funcionalidad, etc. estas incidencias son las que usualmente activan los esfuerzos de desarrollo y mantienen una línea de vida constante en el proyecto de software. Si se pierde el interés en el software o no se obtiene esta retroalimentación, usualmente el desarrollo se estanca y suele quedar abandonado.

Hoy, el desarrollo que ha alcanzado el ecosistema de software libre ha permitido que cada vez más organizaciones, empresas, e instituciones adopten las soluciones de software creadas por éste. Por un lado, estudios recientes, como los de Gartner, señalan que para el 2012 gran parte de los productos comerciales de software emplearán componentes de software libre y que por lo menos una tercera parte del presupuesto de las empresas para software de aplicación se destinará a servicios de suscripción.

IDC said “Open Source is the most significant all-encompassing and long-term trend that the software industry has seen since the early 1980’s.”

Gartner predict that “ By 2012, 80 per cent of all commercial software will include elements of open-source technology. ”

A survey of nearly 1000 IT staff in the UK, Germany, France and North America, commissioned by Actuate, showed that fifty four percent of businesses in the UK felt that the benefits of open source outweighed any negative aspects

Another Gartners top predictions for 2008 is that “by 2012, at least one-third of business application software spending will be as a service subscription instead of as a product licence”.

Por otro lado, esto también presenta una situación en la que la demanda de profesionales con conocimiento de tecnologías de software libre se incrementa, mientras que la oferta parece ser cada vez más escasa, según demuestran estudios de Actuate.

Research conducted for Actuate found that six in every ten respondents said there “were serious problems finding the right IT skills to implement and manage open source solutions”

El pasado sábado 22, tuve la oportunidad de ofrecer una charla en mi universidad, la UPC, en la que desarrolle estos temas. El enfoque tenia como objetivo el saber cómo aprovechar, inteligentemente, como estudiantes de computación, las oportunidades y recursos que existen hoy para desarrollarnos profesionalmente haciendo lo que nos apasiona: software libre. En este sentido, conversamos acerca del programa Google Summer of Code como una manera de avanzar hacia tal objetivo, por los beneficios que ofrece a nivel académico y profesional. Además, presenté el proyecto OSS Watch, cuyo objetivo es fortalecer el vínculo entre la comunidad académica y la de software libre a través del desarrollo de material académico que introduzca prácticas de desarrollo de la comunidad en los cursos de computación. A través de esto el proyecto busca mejorar las capacidades de los futuros profesionales que les permitan desarrollar soluciones basadas en tecnologías de software libre.

La charla estuvo organizada por el grupo GNU UPC, conformado por alumnos y ex-alumnos de la universidad, que está en un proceso de reactivación de actividades y retomando proyectos a futuro, de los cuales seguro tendré algún grado de culpa. Las diapositivas de mi presentación están en el wiki que he creado para publicar mis trabajos academicos y proyectos personales.

En mi charla, que duró un poco más de lo que pensé, me propuse a hablar algo en lo que estoy particularmente interesado hace algunos años: el emprendimiento en tecnología desde Perú. Este es un resumen de lo tratado en espera de comentarios e interacción con los interesados en el tema, y que sea de utilidad a quienes están evaluando seguir este camino.

¿Para qué estudiamos?

Es posible que en algún momento, previo o posterior, a nuestra actividad académica nos hayamos hecho esa pregunta. Porqué decidimos pasar 5 años, en promedio, de nuestra vida entre libros, café, insomnio y algo de stress. ¿Cuál es el objetivo de todo esto? Para algunos será tener una profesión; para otros, adquirir una posición ventajosa en el mercado laboral, obtener reconocimiento social, obtener un grado académico, etc.

¿Porqué trabajamos?

Son pocas la veces que nos ponemos a analizar el porqué decidimos destinar 8 horas diarias, 40 semanales, a una actividad que nos saca de nuestra camas muy temprano, se convierte muchas veces en el centro de nuestras actividades y puede ser el principal móvil de nuestras satisfacciones o frustraciones.

Respuestas hay muchas, generalmente todas difusas del punto principal. Para no revisar todas vamos a simplificarlo: trabajamos porque necesitamos el dinero. Validamos esta afirmación con el dato de que de tenerlo, muchas personas no trabajarían.

Esto deriva en otra pregunta: ¿trabajamos en lo que nos gusta?. En mis diapositivas muestro un aviso tipo de oferta laboral para estudiantes de computación (los errores ortográficos y gramaticales vienen gratis).

Profesional, con el siguiente perfil:
- Mínimo dos años de experiencia en el Desarrollo de Aplicaciones
- Conocimientos intermedios/avanzados de Power Builder
- Deseable, conocimientos de Sistemas Contables y Financieros
- Deseable, conocimientos de UML, RUP, PMI
La modalidad de trabajo inicial es para un proyecto de mediano plazo, bajo la modalidad de recibos por honorarios, con grandes posiblidades de permanecer en la empresa en forma permanente.

¿Qué nos apasiona?

Esto es un tema mucho más personal que los anteriores, en mi caso son 3 cosas, que derivan en otro tanto más: las mujeres guapas, sobretodo una en particular; la computación y la música.

Emprendimiento y academia

En nuestro medio, salvo iniciativas aisladas y todavía por madurar, este tema esta más ligado a la búsqueda de personal a poco costo a quien derivarle tareas complicadas que al mútuo aprovechamiento de las capacidades y fortalezas.

En mi opinión la academia debería ofrecer una formación para:

• Conocer cómo hacer tecnología,
• Estar habilitados en conceptos base de computación,
• Incorporar nuevas tendencias solo como complemento mas no como razón de ser,
• Dar capacidades para desarrollar habilidad de identificación de problemas por resolver,
• Conectarse al entorno académico global.

Emprender a través de proyectos de software libre

El participar de proyectos de software libre ofrece al estudiante de computación la posibilidad de aplicar sus conocimientos teóricos en problemas y casos reales, trabajar en problemas complejos e interesantes, interactuar con estudiantes y expertos en la industria, y, además, generar una reputación a través del trabajo realizado.

¿Cómo, donde, y cuando emprender?

Cada uno de los aspectos tiene una o muchas respuestas, sin embargo, la idea de la charla ha sido ofrecer un panorama sobre las posibilidades, retos y algunos consejos para quienes deciden lanzarse en este estilo de vida.

En nuestro país, al igual que en muchas actividades, el emprender es una decisión que implica muchos, muchos retos y situaciones difíciles. Si deseas emprender debes tener esto en cuenta en primer término.

Voy a comentar un poco sobre algunos de estos:

• Financiamiento, este es uno de los principales retos con los que se enfrenta el emprendedor local. No existe un mercado de capital de riesgo para emprendimientos en tecnología, como en otros paises, sin ir muy lejos Chile o Argentina. Existe sí capital de riesgo para emprendimientos de productos tangibles, generalmente exportación. En COFIDE también hay un fondo similar, que podría incluir productos intangibles (software) de ser lo suficientemente atractivos.
• No existe mercado desarrollado para productos de base tecnológica, es decir para componentes de software o hardware que forman parte de un producto final. En nuestro país todavía no vemos casos de empresas que desarrollen tecnología para otra empresa de tecnología. La mayor parte de empresas trabajan en aplicación de tecnología y ofrecen soluciones sobre estas. Por supuesto, al no existir demanda, no hay iniciativas de oferta.
• Mercado aún pequeño para productos de tecnología, esto es bastante claro, la tecnología todavía no es algo muy difundido en todo nuestro país, y algo que debemos tener en cuenta.
• Ausencia de modelos, nuevamente el tema de modelos; que es claro: no existen modelos de empresas o empresarios que hayan logrado desarrollar productos de tecnología exitosos a quienes los jóvenes puedan mirar, seguir y superar.

Sin embargo, también tenemos grandes oportunidades que nos da la nueva situación en la que nuestro país se encuentra.

El crecimiento económico de los últimos años ha ampliado la base de capacidad adquisitiva y nuevas empresas, ha desarrollado clusters de producción especializados, tecnología aplicada a la producción, entre otros. Aquí se presenta un nuevo escenario en donde la tecnología tiene un espacio en el que aportar al desarrollo del país. Lo acaba de decir el ex-ministro Carranza en la entrevista de El Comercio:

Muchas veces se percibe que el sector empresarial se acerca al Estado o para hacer un lobby o para influir en un asunto particular. Eso tiene que cambiar. Si tengo las mejores prácticas en compras, en sistemas de información, en ética puedo ayudar

La crisis mundial, llegue con fuerza o no, también representa una oportunidad para innovar, para ser creativos, para ofrecer productos de calidad que hagan igual o más con menos. Está claro para todos que en este momento las soluciones y productos de software libre van a tener gran demanda por sus características en cuanto a TCO.

Por otro lado, el mercado local todavía no explora algunos modelos de negocios en tecnología. Entre estos los modelos para la base de la piramide, el esquema “long-tail”, y los modelos “freemium” y la “gift economy”.

Por supuesto, nuestro enfoque no solo debe estar en el mercado local, sino también, mirar a un mercado global, cada vez más conectado y más inter-relacionado.

Finalmente ofrecí algunos consejos para quienes deseen emprender.

• Perder el miedo, saltar al vacío, dejar de pensar y hacer, ¡mandarse!. Esto es como cuando te gusta una chica o chico.
• Enfocarse en solucionar un problema específico y hacerlo de una manera creativa e innovadora que te diferncie de lo que hay. En computación resolvemos problemas, hagamos eso y bien.
• Enfocarse en lo importante (tecnología), no intentar jugar al administrador, contador, marketero, etc. Existen otras personas capacitadas en eso que estarán contentos con ayudarlos en esas tareas. Nuestra fortaleza es saber desarrollar tecnología, no lo otro.
• Ahorrar costos, que implica utilizar infraestructura disponible gratuitamente, servicios como Google Apps, y otros nos ofrecen la capacidad de montar toda nuestra infraestructura en la nube y no tener que incurrir en gastos innecesarios, sobretodo si, como cualquier startup, no disponemos de gran inversión. Ahorrar lo máximo posible es clave para el desarrollo de una nueva empresa. En cuanto a equipos y software GNU/Linux y Mac representan una alternativa bastante sólida en cuanto a cost-beneficio, que nos evita problemas al final del día, si Usted utiliza Windows sabrá a qué me refiero.
• Incorporar entusiastas en nuestro proyecto. Existen personas muy generosas que estarán felices de ayudarlo en el desarrollo de su idea de negocio, atraígalas y hágales partícipe de su emprendimiento.
• Difundir, difundir, difundir, en donde vaya, en donde sea, en cualquier momento del día, y noche, ¡cuente su idea a todo el mundo!. Si Usted la cuenta, no la pierde, contrariamente a lo que se suele pensar en nuestro medio, ¡ahora tiene alguien más trabajando en ella!

Creo que la charla ha sido bastante motivadora para los estudiantes participantes del SECICOMP, espero tener novedades de ellos ya que la feria de proyectos me dio muchos motivos para pensar que será así. Agradezco nuevamente a los organizadores del evento a través de Nils, Eduard, Jorge, Pedro, las chicas y todos los amigos de la UNT con quienes pasé un gran día.

Espero que esto sirva también para iniciar un diálogo sobre el tema aquí. Voy a ir publicando cosas que tengo en cartera sobre este tema cada vez que pueda.

Las diapositivas de la charla se pueden descargar aquí:

Emprendimiento y academia

Finalmente acepte y empece a trabajar precisamente el 1ro de enero del año siguiente. El entorno de la BVL era más tranquilo, no tenían grandes servidores ni cosas sofisticadas; sin embargo tenian algunos elementos que eran bastante interesantes para mi, y creo que claves en mi desarrollo: el proyecto era relativamente nuevo asi que había algunas cosas por construir, había un esquema de telecomunicaciones con los distintos agentes de bolsa a través de un sistema ATM usando el protocolo x25 (antecesor del modelo OSI, TCP) -también conocido como MEGANET en TdP-, el ambiente era tranquilo, teniamos acceso a Internet y el grupo era bastante ameno.

En este lugar es donde logre desarrollar un conocimiento de buen nivel sobre el sistema operativo OpenVMS, a punto que recibia constantes consultas de los nuevos operadores que ingresaban a GMD y de algunos desarrolladores. Mis inicios fueron en el turno de la noche, donde básicamente se procesaba información e imprimia reportes para el día siguiente, ejecutaban respaldos y se aprovechaba parte del tiempo para dormir. Recuerdo que mi primera noche me recoste sobre el sofá que mis compañeros me recomendaron y no desperte hasta las 7am, todavía no me adaptaba; de hecho antes de eso no acostumbraba a desvelarme.
En algún momento pase al turno de la tarde donde tenia que interactuar con usuarios, vestir formal (cosa que jamas me incomodo, salvo cuando me “sugirieron” que use el cabello más corto -obviamente me rebele!-), y sobretodo conocer en persona a los CVL$algo, osea los usuarios, de entre los cuales había algunas guapas chicas; cosa que felizmente parece ser una constante.

Con el pasar del tiempo logré automatizar algunos procesos en los servidores, escribi cientos de programas en DCL, y en algún punto practicamente tenia todo el tiempo libre consecuencia de eso. Logré configurar el stack TCP/IP (ya que esos equipos solo funcionaban en red con el protocolo DECNET), ejecutar y navegar en Mosaic desde el entorno Motif de los servidores Alpha para ingresar a Internet y los servicios en los que ya era ávido usuario (confesión). Descubri todo el mundo detrás de OpenVMS, las conferencias DEC, los grupos de usenet, de los que aprendi, además de incrementar mi interés en conocer el tema en más bajo nivel.

Ocurrio en algún momento que llevamos un curso de Unix, del que ya había oido porque un usuario del chat de Yahoo! lograba hacer cosas que otros no y me dijo que sabia Unix y que debería aprender puesto que todo ese chat estaba sobre Unix. Rápidamente busque en Altavista o Yahoo! y aprendi qué era este Unix.

Luego de la primera clase estuve más seguro de que si queria aprender esto. Lamentablemente desde mi sitio no tenia forma de acceder al servidor en la red de GMD que estaba en el otro edificio. No contento con esa limitación empece a investigar en Internet hasta que encontre la luz: Linux, un sistemas imilar a Unix que se podía ejecutar en una PC. Los siguientes pasos fueron reciclar unos discos duros de 500MB, reducir el espacio usado por Windows 95 en la PC (Pentium 33Mhz, 16MB RAM) que tenia asignado, descargar durante 1 mes -debido a que reiniciaban el equipo y la descarga FTP no tenia “resume”- una distribución de Linux (creo que RedHat 5.x), y tratar de instalar y configurarla, cosa que logré luego de algunos días.

Cierto día buscando información di con la página del Proyecto GNU y leí su manifesto, e inmediatamente coincidi con el mismo. Esto me animó bastante a conocer, usar y promover esto que ahora sabía que se llamaba software libre. Posteriormente supe que habían distribuciones y encontre a mi subsiguiente amor: el Proyecto Debian. Luego de leer su contrato social, manifesto y las directrices, en donde percibi claramente que cualquiera podría contribuir a éste, levante la mano y dije: yo también. Hasta antes de eso no había sentido tan cercano el hecho de que, además de usar algo, también podía hacer cosas para hacerlo mejor y que beneficie a otros como efecto secundario. Esto claramente fue amor a primera vista, de los cuales uno nunca se separa.

Reemplace el RedHat por Debian, que por ese tiempo era complicado de instalar; lo instale en la PC de mi casa, que había adquirido recientemente, y decidi enlistarme en el grupo de traducción como punto inicial de mi contribución.

De las anécdotas de ese tiempo recuerdo una cuando el nuevo jefe de sistemas, ex marino, ingreso al centro de cómputo para mostrarlo a una visita y empezo a describir las actividades y equipos que teniamos. Al señalar mi PC, ejecutando GNOME 1.x, con una terminal ejecutando top y alguna otra cosa, dijo: desde aquí monitoreamos todo. Tuve dos sensaciones, la primera la obvia (no tenia idea de lo que estaba pasando allí -ya que yo mismo me autorice a instalarlo-) y la segunda fue un poco de ego que me decia: exacto, tengo el control de todo esto (cosa que tampoco estaba lejos de ser cierto).

En algún momento, años después cuando ya había salido de GMD, fui a ayudar a mi amigo Oscar con un tema de backups y para sorpresa mía se trataba de uno de los programas que hice tiempo atrás. Finalmente llegaron a usarlo (Oscar era reacio porque no quería olvidarse las órdenes y sus parámetros) y replicarlo en otros proyectos, fue bastante halagador :)

La objetivo principal, más allá de dar a conocer el software libre como tal, era establecer y reconocer prácticas de gestión y procesos que se puedan rescatar e incorporarlos en el desarrollo de proyectos de software de las organizaciones.

La charla inicio ofreciendo un panorama general de los actores que participan en el desarrollo de proyectos de software libre, como podemos ver en el gráfico adjunto, a saber:

• Proyectos en sí,
• Usuarios finales: que incluye a personas, empresas, sector público, organizaciones sin ánimo de lucro,
• Asociados de los proyectos, que son las organizaciones que apoyan a dichos proyectos, caso gobiernos o empresas,
• Partners de los proyectos, que pueden ser empresas u otros proyectos que ofrecen infraestructura base a los mismos,
• Comercializadores de los proyectos, que son las empresas que se dedican a dar un soporte y canal comercial a los productos desarrollados bajo este modelo de licenciamiento.

Luego de esto explique el esquema de trabajo y gestión de los proyectos de software libre, la forma de organización, su estructura jerarquica, infraestructura de trabajo, interacción entre el grupo humano, etc.

A partir de esta información rescatamos algunos valores o prácticas que las organizaciones que realizan desarrollo de software pueden incorporar para mejorar su gestión y procesos de desarrollo.

Entre estos podemos mencionar a los siguientes:

Confía en tu equipo

Esto se refiere básicamente a que la información acerca del desarrollo, incidencias y progreso del proyecto se maneje de manera abierta, sin ocultar información a nigún integrante del equipo. Todos deben estar claros de lo que ocurre. Un esquema bastante similar al definido por Debian y lo que conocemos como el rol de «dictador benevolente».

Revisa todo, prueba todo

Que trata de resumir la necesidad de incorporar y establecer prácticas de testing en el proceso de desarrollo y aprovechar las herramientas de software, o construir las necesarias, para establecer un ciclo constante de auditoria general y automatización del proceso de pruebas de software. De esta manera a medida que se va desarrollando el proyecto también se tiene a la par un proceso que puede garantizar la validación de su funcionalidad.

Todos los desarrolladores son iguales

Algo que no se refiere a las características personales o de formación, sino a la equidad y valoración de las ideas o aportes de los desarrolladores, sean los más experimentados en el equipo o novatos que se acaban de incorporar. Cualquiera de ellos debe ser escuchandos y sus aportes o ideas respecto al desarrollo o diseño de los proyectos se debe tener en cuenta de la misma manera.

Y finalmente, la premisa que no debemos olvidar:

La mejor manera de finalizar un proyecto de forma exitosa es hacerlo de la forma correcta

Que básicamente nos recuerda que aunque tengamos los procesos definidos, las herramientas necesarias y la infraestructura de soporte para el desarrollo de nuestros proyectos; si los primeros se ignoran y no se siguen desde el inicio del proyecto, por razones de tiempo, urgencia, etc; es mucho más probable que a medida que se desarrolle el proyecto ocurran problemas que si se empieza de la forma correcta.

Esto es lo que cuenta al final del día y puede ser el factor crítico que conduce a pérdidas de tiempo, dinero y time-to-market para una organización. Para que un proyecto sea exitoso se requiere la participación de todos los actores involucrados, que va desde la gerencia hasta el desarrollador. No se trata simplemente de dar indicaciones al programador y encerrarlo un número de días esperando que entregue un resultado maravilloso.

Fue interesante el aprovechar que me antecedio una charla sobre  SCRUM, para vincular muchas de estas practicas que tambien son promovidas por frameworks de desarrollo ágil como éste, que fue expuesto por Tobias Mayer de AgileThinking.net.

Es posible que existan otras prácticas que los proyectos de desarrollo de software en las empresas puedan incorporar, si has identificado o aplicado alguno ¡dejanos saber!.

Existe más información sobre el tema que he tomado como referencia para esta charla. A continuación pongo algunos enlaces de referencia:

• Sitio web del MIT que reune trabajos de post-grado sobre temas de software libre. http://opensource.mit.edu
• Articulo sobre el tema en OnLamp de O’reilly. http://www.onlamp.com/pub/a/onlamp/2006/02/27/what-corp-projects-learn-from-open-source.html
• Consultora Stellman Greene: http://www.stellman-greene.com
• Consultora Construx: http://www.construx.com

Este trabajo de Steve McConnell, autor del libro «Rapid Development», recopila los errores más comunes en el proceso de desarrollo de software y tiene como objetivo el ofrecer un vistazo único a los factores de riesgo más comunes. Originalmente la lista se inició con 36 errores a partir de la publicación del libro en 1996, y a la fecha reune datos obtenidos del trabajo con más de 1000 clientes de Construx.

Entre las fuentes que han aportado para la elaboración de dicha actualización se encuentran Jefes o arquitectos de software (55%), gerentes (11%), Gerentes técnicos o con doble rol (6%), y técnicos (22%).

Entre los primeros 10 errores más frecuentes se identifico a los primeros 5 con el modo de «Casi siempre» y a los siguientes como «a menudo»:

1. Cronogramas demasiado optimistas
2. Expectativas irreales
3. Aseguramiento de calidad infimo
4. Oficinas ruidosas y hacinadas
5. Confusión de estimados con objetivos
6. Excesiva aplicación de multi-tarea
7. Pesadilla de características
8. Pensamiento iluso
9. Gestión de riesgo insuficiente
10. Omisión de tareas necesarias para estimados

Entre ellos se clasifico como de alto impacto con una criticidad de «Catastrófico» y «serio» en el siguiente orden.

1. Expectativas irreales (83%)
2. Personal inadecuado (78%)
3. Cronogramas demasiado optimistas (78%)
4. Pensamiento iluso (76%)
5. Aseguramiento de calidad infimo (72%)
6. Diseño inadecuado (72%)
7. Falta de auspicio del proyecto (71%)
8. Confusión de estimados con objetivos (71%)
9. Excesiva aplicación de multi-tarea (71%)
10. Falta de involucramiento del usuario (70%)

Es particularmente interesante observar que 35 de los 42 errores clásicos se clasificaron como de impacto catastrófico o serio por mas del 50% de participantes.

El paper ofrece además métrica de exposión al riesgo (RE) que mide la severidad y el impacto de forma aproximada, básicamente obtenida del producto de ambos criterios bajo la fórmula RE = severidad * impacto.

Una de las cosas que me llamo la atención fue el tema de «Whishful thinking» o pensamiento iluso, que ha sido calificado en la posición 4. A veces ocurre que en la gestión del proyecto se cierra totalmente en la idea de que va algo va a funcionar cuando no se tiene base concreta o razonable para pensar que así será. Costrux indica que esto puede llevar a grandes problemas si se da al inicio del proyecto, pero lo mas grave es que menoscaba el planeamiento adecuado y puede ser la raíz se otros problemas.

Como tantos de los temas en gestión de proyectos de diversa índole, este no deja de tener al factor humano como clave, fuera de buenas prácticas, métricas, procesos o metodologías, si el personal que lidera el proyecto se cierra bajo una visión irreal esta puede tener consecuencias serias para la organización.

El otro tema que me parece interesante es el multi-tarea excesivo. Generalmente se suele confundir al desarrollo de proyectos usando metodologías ágiles y etiquetarlos con cierta metodología, sin tomar en cuenta todos sus aspectos. El problema con el excesivo uso de multi-tarea es que, según los estudios, cada «switch» entre tareas puede tomar de 5 a 30 minutos de «para» de desarrollo mientras la persona cierra el flujo de trabajo de un proyecto y se inserta en otro.

Finalmente el tema del ambiente laboral resulta vital, ya que un entorno ruidoso o demasiado hacinado evita la concentración y el estado necesario que se requiere para trabajar y obtener altos niveles de productividad. Se ha determinado que los trabajadores que tienen oficinas silenciosas y privadas tienden a deempeñarse sinificativamente mejor que aquellos que ocupan cubículos o bahías ruidosas y demasiado hacinadas.

Recomiendo leer este trabajo si trabajas o te interesa el tema de desarrollo de software, en especial si estas a cargo de proyectos o su gestión.