SG20 (Mayo-Julio 2008)

• Data Warehouse Multidimensional • Ruby on Rails • Documentación de Arquitecturas

Software Guru CONOCIMIENTO EN PRÁCTICA No.20 • Mayo - Julio 2008 • www.sg.com.mx

[ ENTREVISTAS ]

Terry Quatrani Jon "maddog" Hall John Crupi Key speakers SG'08

México. $65 MXN

Noticias • Eventos • Fundamentos • UML • Infraestructura • Tecnología

[ Herramientas ]

Visual Studio 2008

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Sonia Sánchez

Editorial

Arte y Diseño Grisel Otero

Remontarnos a la época del Renacimiento sería hablar de la Capilla Sixtina o La Gioconda pero, ¿qué relación hay entre las artes con la tecnología?. La respuesta es sencilla, las nuevas tendencias en lenguajes de programación están retomando lo mejor de aquellos que sirvieron como base para los lenguajes modernos.

tentes al anterior congreso es junio. Dada esta preferencia, este año SG’08 Conferencia y Expo ya tiene fecha, no solamente eso; paralelamente a nuestro evento, se realizará el PMTOUR México 2008, organizado por el PMI Capítulo México. La agenda de ponencias y talleres ya la pueden consultar en el sitio web oficial: www.sg.com.mx/sg08

Este movimiento es similar al Renacimiento en las Bellas Artes, no solamente porque marca un estilo, además señala el inicio de una nueva generación de opciones para aplicar los conocimientos aprendidos en las clases de estructuras de datos. Para los jóvenes estudiantes, se les presenta la oportunidad de aprender la sintaxis de los nuevos lenguajes, para los profesionistas con cierta trayectoria en el medio, el reto de actualizarse y saber qué es lo que viene atrás de ellos.

El equipo de SG está con miles de ocupaciones organizando el evento, para que por tercera vez consecutiva se realice con éxito.

El lugar ya es conocido por ustedes Hotel Sheraton Centro Histórico, escuchando sus propuestas, ahora arrancamos con dos días de tutoriales. Como pueden darse cuenta, los cambios nacen de sus sugerencias, sin olvidar mencionarles que fue difícil escoger las pláticas paralelas, llegaron propuestas muy interesantes pero lamentablemente el tiempo es poco. Gracias a todos aquellos que se tomaron un tiempo para registrar su propuesta de charla.

En este número invitamos a nuestros fieles lectores, a conocer un poco más sobre este renacimiento tecnológico y sus tendencias.

Sin pasar por alto las columnas que se han vuelto un clásico en cada edición. Temas que hablan sobre la documentación de arquitecturas, la locura que pasa un usuario cuando tiene muchas cuentas de acceso para diferentes servicios, el framework de Rails y otros temas que sabemos serán de su completo agrado.

En esta ocasión tendremos la grata presencia de Terry Quatrani, Jon “Maddog” Hall y John Cupri, 3 grandes celebridades dentro de sus áreas de desarrollo profesional, y para terminar la noche, relajar los nervios, descansar la mente y sacar al niño geek que todos llevan dentro, el evento social estará encabezado por una sesión de Rock Band. ¡Nos vemos en SG’08 Conferencia y Expo!

Tocando otros temas, mediante una encuesta realizada en el sitio web, sabemos que la fecha preferida por la mayoría de los asis-

02

MAY-JUL 2008

» Equipo Editorial

Consejo Editorial Jorge Valdés - PMI; Francisco Camargo, Luis Daniel Soto - Microsoft; Ralf Eder, Raúl Trejo, Guillermo Rodríguez, ITESM-CEM; Hanna Oktaba, UNAM; Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity, Emilio Osorio.

Colaboradores Rigoberto Calleja, Rajah James, Omar Gómez, Carlos Ortega, Charlie Macías, Elizabeth Almeraz, José de J. Hernández, Karina Okón, Ariel García, Tom Mochal, José L. Flores, Tomás Helou, Ernesto Reyes, Elena Ruelas, Miguel A. Morán, Ariel Ortiz.

Ventas Claudia Perea, Natalia Sánchez Marketing y RP Dafne Vidal Circulación y Suscripciones Daniel Velázquez Administración Araceli Torres Contacto info@softwareguru.com.mx +52 55 5239 5502

SG Software Guru es una publicación trimestral editada por Brainworx S.A. de C.V., Malinche no.

6, Col. El Parque, C.P. 53398, Naucalpan, México.

Queda prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400-102.

Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888.

Registro Postal: PP15-5106. Se imprimió en abril de 2008 en El universal, Compañía Periodística Nacional.

Distribuido por Comercializadora Alieri y Sepomex.

www.sg.com.mx

contenido may-jul 2008 EN PORTADA Lenguajes de Programación

Conozcamos los orígenes de los nuevos paradigmas dentro de este campo.

Especial

Data Warehouse Multidimensional.

18

Productos LO QUE VIENE 12 JBuilder 2008, WebSphere sMash, Mingle 2.0 y Quest para Sharepoint.

Herramientas Visual Studio 2008 Herramientas de análisis y medición de código.

Columnas

Prácticas

Tejiendo Nuestra Red por Hanna Oktaba

08

Tierra Libre por Emilio Osorio

61

Mejora Continua por Luis Cuellar

10

Columna Invitada por Tomás Helou

62

Prueba de Software por Luis Vinicio León

36

Cátedra y Más por Raúl Trejo

64

Tendencias en Software por Luis Daniel Soto

60

04

INFRAESTRUCTURA

56

FUNDAMENTOS

54

GADGETS

58

Terry Quatrani Jon “maddog“ Hall John Crupi

www.sg.com.mx

38

Conozcamos los diferentes tipos de documentación que debe considerar un arquitecto de software.

PROGRAMACIÓN Aprendiendo Ruby y Rails

42

46

PROCESOS CMMI-SVC

Noticias y Eventos

Entrevistas

ARQUITECTURA Más allá del manual de usuario

En la tercera parte del tutorial, se hablará sobre el framework de Rails.

En Cada Número

24

14

Para todas aquellas empresas dedicadas a los servicios, este nuevo modelo les será de gran ayuda en su desempeño.

48

UML SysML Con esta notación, el modelado de los sistemas se amplía al considerar no solamente los componentes tipo Software.

PM CORNER 50 El valor de las oficinas de proyectos Notemos el valor del lugar en el que se desarrolla toda la planeación de un proyecto en curso.

MAY-JUL 2008

03

// NOTICIAS

IMPACT 2008 La ciudad de Las Vegas fue sede de Impact 2008, la conferencia anual que IBM realiza para usuarios de Websphere a la cual asistieron más de 6 mil personas de todo el mundo. El tema central a lo largo del evento fue SOA, e IBM dejó claro su liderazgo en este campo no solo en términos de tecnología, sino también en cantidad de clientes.

Prueba de ello fueron las más de 250 sesiones impartidas directamente por clientes de IBM que hablaron sobre su experiencia con SOA, destacando las pláticas de empresas como Harley Davidson, Aetna y United Airlines.

El slogan del evento fue “Smart SOA”, y el objetivo era hacer ver que los tiempos del “¿Qué es SOA?” finalmente están quedado atrás, y por fin estamos entrando en el “¿Cómo aplicar SOA de forma efectiva?”.

Estamos con los Héroes Bajo el lema “estamos con los héroes” se realizó el lanzamiento en México de Visual Studio 2008, Windows Server 2008 y SQL Server 2008. Durante varias semanas se realizó un tour por distintas ciudades del país, y el 17 de abril fue el evento en Ciudad de México con más de 2 mil asistentes, así como la participación del Hijo del Santo.

Las nuevas versiones de estos productos proveen un gran número de mejoras y nuevas capacidades, orientadas a hacer realidad la visión de Microsoft de “Software + Servicios”. En el caso de Visual Studio, el énfasis está en el desarrollo de aplicaciones distribuidas, así como el aprovechamiento de nuevas tecnologías como LINQ. Por su parte, tal parece que la principal fortaleza de Windows Server 2008 estará en la facilidad que provee para el manejo de virtualización.

PROSOFT 2.0 La Secretaría de Economía dio a conocer la segunda generación del Programa para la Industria de Software (PROSOFT) bajo el nombre de PROSOFT 2.0. Entre las novedades está la creación de un nuevo programa denominado PROMEDIA, el cual está dirigido a impulsar el sector de los medios interactivos.

De acuerdo con Sergio Carrera, Director General de Comercio Interior y Economía Digital en Secretaría de Economía, la principal diferencia con PROSOFT 2.0 es que maneja un enfoque de mayor proactividad, especialmente en el desarrollo de capital humano. En lugar de esperar a que se presenten las oportunidades para entonces comenzar a desarrollar la gente, ahora la mentalidad es primero generar la gente para que así lleguen las oportunidades.

04

MAY-JUL 2008

www.sg.com.mx

// noticias

Gartner Enterprise Integration Summit Al igual que cada año, este mes de abril se celebró la Cumbre de Integración Empresarial de Gartner, en la cual se analizan las tendencias en cuanto a arquitecturas empresariales e integración de datos y aplicaciones. Los temas que dominaron la conferencia fueron SOA, BPM y enterprise mashups.

De acuerdo con los analistas de Gartner, lo que ven en México es que estamos haciendo un gran énfasis en la gestión de procesos (BPM), pero nos está costando trabajo habilitar esto en el contexto de arquitecturas orientadas a servicios, por lo cual estamos obteniendo beneficios marginales.

Mexico First

Tendencias 2008

CANIETI y ANIEI, con el apoyo de Secretaría de Economía han creado la iniciativa Mexico First. Esta es una asociación civil operada por CANIETI cuya misión es aumentar la cantidad de personas certificadas en nuestro país, de forma que nuestro recurso humano sea reconocido globalmente como una excelente opción para satisfacer las necesidades de la industria de TI.

El pasado 26 de febrero se llevó a cabo el evento Tendencias 2008: Arquitectura para organizaciones de alto desempeño, durante el cual se identificaron las prácticas que los empresarios deben adoptar para ser competitivos. Se brindó a los asistentes la oportunidad de participar en seis talleres de benchmarking para identificar oportunidades e impulsar el desempeño de sus organizaciones.

A grandes rasgos, lo que Mexico First hará es captar las necesidades de certificación en TI de los diferentes estados, y unificar el poder de compra para mejorar la calidad y el costo. Esto acelerará los proyectos que solicitan Fondos PROSOFT para certificación de personal, ya que los beneficiarios no tendrán que buscar proveedores y obtener cotizaciones, sino que Mexico First se encargará de esto.

El cierre del evento estuvo a cargo del Dr. Ricardo Zermeño González, director general de Select, quién en su conferencia magistral señaló las oportunidades para un crecimiento competitivo en México, destacando que no solo se requieren las conocidas reformas estructurales, sino también de una reforma empresarial llamándola: la reforma estructural olvidada.

Conferencia Anual de Administración de Servicios de TI En el pasado mes de abril, en el WTC de la Ciudad de México, se realizaron dos días de conferencias organizados por Pink Elephant. Los participantes tuvieron la oportunidad de intercambiar ideas, aprender e integrarse en un medio ejecutivo. Las sesiones se dividieron en diferentes sectores: Administración de TI Ejecutiva y Estratégica, reuniones informativas de ITIL, Gobernabilidad, ¿Dónde comenzar a implementar ITIL?, Implementación de Herramientas y Tecnología. Cabe destacar que en dicho evento se hizo la presentación de la primera certificación en ISO 20000 en Latinoamérica, este honor lo tuvo la empresa colombiana Compuredes.

Empresas recientemente evaluadas en CMMI: Empresa Sinersys Ventus IDS

www.sg.com.mx

Evaluación CMMI Nivel 3 CMMI Nivel 3 CMMI Nivel 3

Fecha marzo 2008 marzo 2008 marzo 2008

Lead Appraiser Alfredo Calvo, Itera José Luis Iparraguirre, Itera Ernesto R. Corona, Liveware

MAY-JUL 2008

05

// Eventos

14 al 15 de Mayo 2008

22 de Mayo 2008

Centro Banamex, Cd. de México Info: www.idc-eventos.com

Salón de la CANACO de Coatzacoalcos, Veracruz Info: www.microsoft.com/latam/estamosconlosheroes

IDC WebSec Conference 2008

PRONET Heroes Coatzacoalcos

14 al 16 de Mayo 2008

Expo Data Center 2008 Salón Olmeca, WTC, Cd. de México Info: www.expodatacenter.com/expo2008

18 al 19 de Junio 2008

Gartner 4ª Annual Outsourcing Summit Centro Banamex, Cd. de México Info: www.gartner.com/mx/outsourcing

17 de Mayo 2008

BugCON Security Conferences Instituto Politécnico Nacional, Cd. De México Info: www.zonartm.org/BugCON

20 al 21 de Mayo 2008

Information Security

21 al 24 de Junio 2008

SG’08 Conferencia y Expo / PMTOUR México 2008 Hotel Sheraton Centro Histórico Info: www.sg.com.mx/sg08

WTC, Cd. de México Info: www.informationsecurity.com.mx 24 al 25 de Junio 2008

Cutter 21 al 23 de Mayo 2008

Sun Tech Days 2008 Centro Banamex, Cd. de México Info: www.suntechdays.com.mx

Mastering Personal Agility for Executives Hotel JW Marritott, Cd. de México Info: www.cutter.com.mx

Infor Day México 2008

Circuito Tecnológico 2008

Infor realizó los pasados 14 y 15 de febrero, en las instalaciones del Hotel Sheraton Centro Histórico, el primer Infor Day en América Latina. Este evento, como parte de la serie Infor Day a nivel mundial, celebró el crecimiento de los clientes en México y norteamérica ofreciendo un foro interactivo para las compañías interesadas en aprender más sobre la empresa y sus soluciones.

Secretaría de Economía, mediante el PROSOFT, dió inicio al Circuito Tecnológico 2008, programa de capacitación que a través de la impartición de talleres y conferencias, tiene como objetivo hacer extensivo el conocimiento que Empresas, Organizaciones y Gobierno involucrado con las TI, desean dar a conocer.

Las sesiones estuvieron enfocadas en las soluciones de negocios para varias industrias, incluyendo manufactura discreta, manufactura de proceso, minoristas, servicios y más. Los asistentes tuvieron la oportunidad de aprender las mejores prácticas del medio a través de pláticas sobre la dirección de productos, casos de estudio de implementaciones innovadoras en voz directa de los clientes de Infor así como a las sesiones educativas enfocadas en las soluciones que ofrece esta compañía.

El vicepresidente de Infor en México, comentó que estableciendo este evento anualmente en nuestro país, se demuestra el compromiso de la empresa para servir a sus clientes de Latinoamérica resaltando la etapa de crecimiento en este mercado.

El 4 de marzo dió inicio con el seminario “Generación de Demanda”, dirigido a desarrolladores y distribuidores de tecnología, revisando temas como el rol del gerente de marketing y experiencias reales en la generación de demanda. Las conferencias estuvieron a cargo de Christian Zuili de ZUiLi University, Daniel Hernández de ActionCOACH, y Ernesto Herrera López de HLO. El 11 de abrilse presentó el seminario “CMMI ACQ - Modelo para la mejora en las áreas de Adquisiciones”, donde Carlos Pérez y Mariana Pérez-Vargas, de la empresa Avantare, presentaron el modelo y su método de evaluación. Como parte del programa, AMITI presentó una metodología para el apoyo de ventas de TI a gobierno, y posteriormente se contó con una mesa redonda sobre la problemática y perspectiva de las adquisiones.

Para conocer la agenda visita: www.software.net.mx/circuito

06

MAY-JUL 2008

www.sg.com.mx

www.sg.com.mx

MAY-JUL 2008

// COLUMNA

/*TEJIENDO NUESTRA RED*/

50 Años de la Computación en México Manifiesto de REMIDEC

La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

E

l 8 de junio de 1958, gracias a las gestiones del Ing. Sergio Beltrán, se inauguró el Centro de Cálculo Electrónico en la Facultad de Ciencias, UNAM. Su primera computadora fue la IBM-650 de bulbos, con memoria de tambor magnético y con lectora y perforadora de tarjetas. Los primeros expertos en manejarla fueron José Luís Otalengo y Artemio Taboada, mientras que Manuel Ortega fue su primer operador. Estos datos los tomé del artículo: “Primera Década de la Computación en México: 1958-1968 Primera y Segunda parte”, escrito por Miguel M. Soriano L. y Christian Lemaitre, publicado en Ciencia y Desarrollo, vol. 60 y 61, 1985.

Pasaron 50 años y afortunadamente tenemos el programa PROSOFT, que tiene por objetivo fortalecer la industria de software en México. Como todos sabemos, para lograr este objetivo se requiere de una colaboración muy estrecha entre el gobierno, la industria y la academia. El papel de la academia, hasta este momento, se está viendo principalmente como proveedor de recursos humanos sin apreciar lo suficiente la parte de investigación como la fuente de innovación.

El año pasado, el Dr. Christian Lemaitre de la UAM-Cuajimalpa, uno de los Decanos de la computación en México, empezó a convocar a la comunidad académica para aprovechar este aniversario y hablar de la importancia de fomentar la investigación en computación.

Como resultado, se ha conformado la Red Mexicana de Investigación y Desarrollo en Computación (REMIDEC) cuyas primeras tareas fueron hacer el censo de los doctores en computación en México y elaborar un manifiesto. El censo nos sorprendió a nosotros mismos, ya somos más de 500 doctores en diversas áreas de computación en México. Elaborar el manifiesto nos costó

08

MAY-JUL 2008

un poco más de trabajo, pero finalmente lo concretamos.

En esta columna quiero compartir con los lectores de SG los puntos más importantes del Manifiesto de la Comunidad Científica de la Computación que empieza con el siguiente preámbulo: Hoy, México tiene un número importante de especialistas en Ciencias de la Computación con alta calificación.

Juzgamos que si se da un esfuerzo concertado y una adecuada inversión por parte de las autoridades y de las instituciones involucradas, estos especialistas pueden producir mucha más investigación de primera calidad con un mayor impacto para el desarrollo de México.

El documento cuenta con ocho páginas y su contenido está estructurado de la siguiente manera: i. ¿En qué consiste y por qué es importante hacer

investigación en Ciencias de la Computación? ii. La necesidad de hacer investigación en Ciencias de la Computación en México. iii. Barreras para el florecimiento de la investigación y desarrollo de la computación en México. iv. Líneas de acción claves para promover la investigación en Ciencias de la Computación en México.

Creo que para los lectores, los primeros dos puntos no requieren de mayor explicación, por lo tanto voy a concentrarme en presentar las barreras y las líneas de acción que se proponen.

Con respecto a las barreras, cito la parte más importante del manifiesto:

…las Ciencias de la Computación no han logrado un reconocimiento que corresponda a su importancia y características específicas, ni entre las autoridades del ramo, ni en el resto de la comunidad científica. Aun con el crecimiento importante de profesores investigadores en computación en los últimos 15 años, su número es insuficiente ante las necesidades del país. No hay suficientes grupos con la masa crítica requerida, ni se dan suficientes apoyos para desarrollar proyectos con la magnitud y plazos adecuados para lograr el posicionamiento e impactos convenientes para el país.

En pocas palabras: somos relativamente muchos, pero pulverizados. El mejor ejemplo es la UNAM. Somos bastantes, pero regados entre múltiples instituciones de esta enorme Universidad. En la propia Facultad de Ciencias, cuna de la computación en México, existe la carrera de Ciencias de la Computación, pero no el departamento con el mismo nombre, porque nuestros colegas biólogos, físicos y matemáticos consideran que todavía estamos “peques”.

Entonces, ¿qué hacer para cambiar esta situación? Cito a continuación la propuesta de las principales líneas de acción: 1. Establecer la investigación y desarrollo en Ciencias de la Computación y las Tecnologías de Información como un área prioritaria para el país. Esto se debe incluir en el Plan Nacional de Desarrollo, estableciendo la necesidad de asignar recursos específicos para promover la investigación a mediano y largo plazo. También, es necesario reconocer a las Ciencias de la Computación como una especialidad en sí misma en todas las instancias académicas y gubernamentales, en particular en el Sistema Nacional de Investigadores (SNI). www.sg.com.mx

“Hoy, México tiene un número importante de especialistas en Ciencias de la Computación con alta calificación”.

2. Contar con una masa crítica de investigadores y grupos de investigación de primera calidad. Para ello, es necesario hacer un esfuerzo en la formación de nuevos científicos, así como en la actualización de maestros, profesionales e investigadores consolidados. Se deben crear, además, las condiciones para atraer y retener investigadores de primera calidad y, sobre todo, instituir las condiciones que les permitan trabajar de forma productiva. En particular, se requieren, tanto la apertura de plazas para los nuevos investigadores que se están formando, como la existencia de esquemas atractivos para promover la contratación de investigadores consolidados con interés en instalarse en México.

3. Consolidar los grupos de investigación.

No basta con la existencia de numerosos investigadores en el país, es necesario contar con grupos suficientemente grandes, compuestos por investigadores y estudiantes de posgrado, que colaboren durante un tiempo razonable y con adecuada especialización para alcanzar niveles de continuidad, producción y calidad comparables a los de los mejores grupos del mundo. Estos grupos se deben formar, por lo general, dentro de las distintas instituciones pero deberá fomentarse también la formación y consolidación de grupos multinstitucionales y la incorporación a éstos de investigadores que se encuentren aislados temática o institucionalmente. Sin grupos estables y productivos, las capacidades de formación y transferencia de tecnología son disfuncionales.

4. Reordenar los mecanismos de financiamiento y estímulo a la investigación. Para lograr los objetivos anteriores es necesario contar con recursos previsibles suficientes, cuya obtención y gestión no supongan una carga excesiva ni para los grupos de inveswww.sg.com.mx

tigación ni para los propios investigadores.

Es deseable instituir mecanismos de financiamiento que propicien la conformación de grupos sólidos orientados a la investigación y desarrollo en las áreas prioritarias y con una visión a largo plazo. Asímismo, deben diseñarse mecanismos de asignación, evaluación y seguimiento, así como incentivos que, en conjunto, impongan exigencias sensatas y objetivas a investigadores e instituciones: den pie a una evaluación pertinente y oportuna y constituyan, en suma, instrumentos para hacer eficiente la inversión. Es indispensable contar con mecanismos de evaluación y estímulos adecuados al dinamismo y características particulares del área.

5. Establecer una estrategia de articulación nacional. Esta articulación debe realizarse en distintos ámbitos. Hay que prestar atención a la integración de la investigación en Ciencias de la Computación con la docencia por un lado y con la transferencia de tecnología por el otro, además de la integración de los investigadores en esta área como una comunidad y su coordinación con las otras comunidades científicas. Es necesario fortalecer la intervención de estos investigadores en los distintos órganos de evaluación de la actividad científica del país (como el CONACYT y el SNI), así como en los de política científica (Academia Mexicana de Ciencias y el Foro Consultivo). Se deben consolidar los mecanismos de transferencia de tecnología y capital de riesgo que permitan transferir para potenciar el producto de la investigación y desarrollo en ciencias de la computación y Tecnologías de Información.

6. Establecer una estrategia de vinculación internacional. Es necesario fomentar la participación en redes internacionales de las distintas especialidades con la colaboración de científicos mexicanos en los comités edi-

toriales, los organismos de evaluación, los órganos de gobierno de las asociaciones, la organización de eventos. Se debe fomentar que los grupos de investigación mexicanos y las instituciones que los abriguen establezcan relaciones y alianzas que permitan colaboración en distintos tipos de actividad con contrapartes de otros países. Estas colaboraciones deberán considerar también aspectos de formación que incluyan becas, visitas, estancias, dirección compartida de tesis doctorales, cursos y proyectos binacionales y multinacionales. Será necesario diseñar estrategias específicas para impulsar las relaciones con los países con los que hay una historia exitosa de colaboración o con los que es importante tenerla, para fortalecer los vínculos con los investigadores mexicanos establecidos en el extranjero, así como con asociaciones profesionales y organismos de promoción y coordinación internacionales.

Como pueden ver tenemos muchas asignaturas pendientes, que no se van a resolver de la noche a la mañana, pero que bueno que ya se formularon y pueden servirnos de orientación en los esfuerzos de cada quien.

Hay que tocar muchas puertas de gobierno, de industria; medios de comunicación y las propias instituciones de investigación y educativas. Hay que difundir, evangelizar y convencer de que la mejora de la investigación en computación tiene un impacto directo en la formación de recursos humanos, éstos en la innovación de la industria de software y, en general, de la Tecnología de Información. Finalmente, todo esto se traduce en el mejor bienestar de la sociedad en su conjunto. Otros países ya lo entendieron perfectamente desde hace tiempo, ahora le toca a México. » Hanna Oktaba

MAY-JUL 2008

09

// COLUMNA

/*MEJORA CONTINUA*/

Calidad

El camino hacia la renovación Luis R. Cuellar es director de calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

E

n el número pasado hablábamos de generar algunas ideas de apoyo para crear y darle seguimiento a sus planes para 2008. En esta ocasión continuaremos con la segunda y última parte del artículo.

Donde manda capitán, no gobierna marinero Una iniciativa de mejora continua solamente se puede implementar cuando es apoyada por la dirección de la organización, para todos aquellos que no cuentan con esta ayuda, temo decirles que lo anterior es absolutamente cierto y hasta ahora nunca he visto una excepción a la regla. Sin los directivos, solamente tenemos dos posibles estrategias: 1) Identificar a la persona o personas que sí crean en la mejora continua, y apoyarse en ellos para implementaciones. A veces lo mejor es reducir el alcance de lo que queremos hacer para acelerar la implementación, es muy probable que cuando otras personas vean lo que se ha logrado, entiendan mucho mejor por qué ellos también deben hacerlo.

2) Muchas veces no es que las personas no quieran mejorar su trabajo, simplemente no entienden qué es lo que deben hacer o cómo es qué mejorar les conviene, siempre se debe de vislumbrar el rol de un agente de cambio como un educador. El trabajo muchas veces no es sólo ayudar a mejorar, es enseñar cómo hacerlo.

Los Cañones de Navaron En los años setenta salió en los cines una película llamada Los Cañones de Navaron, la cual habla de un equipo especial en la Segunda Guerra Mundial con la misión de destruir una barrera de tanques estratégicamente colocados para que la marina no pudiera entrar y atacar. Cuando vi esta película me recordó otra historia: una organización que trataba de hacer un cambio y los participantes, al ser auditados, mencionaron que necesitaban capacitación para aprender; durante el curso mencionaron que requerían de los templates adecuados, después de eso solicitaron los checklists para llenar los templates, después requerían ejemplos de cómo llenar los templates, finalmente al terminarlos, había pasado tanto tiempo que los ingenieros solicitaron que se les diera un curso para poder aprender.

Suena divertido, ¿no?

Pero este es un problema sumamente común, sobre todo cuando no se incluye a las personas al definir los procesos, y es una trampa muy difícil de brincar sin ayuda de la dirección de la compañía. A fin de cuentas a lo que se tiene que llegar es a un compromiso por parte de los involucrados, es decir, tenemos que llegar a un punto en donde se pueda decir: “yo me comprometo a darte esto, a cambio de que tú te comprometas a hacerlo”.

Tautologías y palabras mágicas Cuántas veces hemos escuchado cosas como “el entrenamiento no es suficiente, se requiere gente con experiencia”, “somos una compañía que cree en la más alta calidad”. Muchas veces los intentos de mejorar procesos se detienen cuando se nos colocan palabras demasiado grandes para poder hacer algo con ellas. Esto es tan común que a veces, ni siquiera nos damos cuenta que lo estamos haciendo, por lo que siempre tenemos que estar al tanto de dichas expresiones dentro de toda la conversación, buscando aclarar qué es exactamente lo que se quiere decir. Lo importante es que quede claro qué es lo que se esta buscando resolver antes de solucionarlo.

Demasiado trabajo para atenderte Las organizaciones que trabajan con pocos estándares de calidad siempre están de prisa, atrasadas y nunca tienen tiempo para alguien fuera del proyecto que les diga cómo hacer las cosas. Normalmente tienen la idea de que si no estas físicamente con ellos, no entenderás los problemas y sólo les quitarás el tiempo. Esta es otra situación difícil de resolver, muchas veces lo ideal es dejar a un lado nuestros planes de certificación y enfocarnos en resolver los problemas de los proyectos. Lograr masa crítica con otros y después regresar a nuestro objetivo inicial. Debemos tener presente que si solo nos comprometemos a un proyecto, los demás quedan desatendidos; hay que buscar el balance. También debemos tener mucho cuidado de no absorbernos por completo en las tareas diarias y perder el objetivo.

Demasiado entrenamiento Al implementar un plan de calidad, la cantidad de entrenamiento que se requiere, normalmente es el problema principal. Se espera que los ingenieros de software y lleguen entrenados para hacer lo que tienen que hacer. Se entrenen en ratos libres o al no estar asignados en algún proyecto. Y el entrenamiento normalmente se enfoca en lenguajes de programación o técnicas de ingeniería de software.

Al implementar una serie de procesos en una organización, es importante tomar en cuenta que para todo proceso se debe entrenar a todos los involucrados, cuando ingresan a la compañía o cuando cambian su rol de trabajo. Se requiere tener un claro plan de entrenamiento por lo que es importante conocer sobre sus técnicas, modelos y cualquier cosa que nos permite hacerlo más flexible y efectivo. Adicionalmente, la rotación es el enemigo número uno del entrenamiento. Es importante mantener la rotación al mínimo.

Espero que todo esto les ayude con su planeación y la ejecución de sus planes, a trabajar. Hagamos de 2008 el año del cambio. » Luis R. Cuellar

10

MAY-JUL 2008

www.sg.com.mx

www.sg.com.mx

MAY-JUL 2008

// PRODUCTOS

/* LO QUE VIENE*/

Websphere sMash

IBM le entra a los mashups

JBuilder 2008

Llegan los Application Factories

CodeGear anunció la disponibilidad de la versión 2008 de JBuilder, la cual incorpora soporte para una estrategia de desarrollo denominada Application Factories. Este concepto es bastante interesante. Básicamente, parte del entendimiento de que la mayoría de las aplicaciones que desarrollamos actualmente no se hacen desde cero, sino que partimos de una base de aplicaciones existentes (ya sean internas, de software libre, o componentes comerciales). Entonces, lo que se hace a través de los Application Factories es capturar estas modificaciones o ajustes a código existente y describirlas como metadatos independientes de un lenguaje de programación. Posteriormente se pueden tomar estos metadatos y aplicarlos a una base de código diferente, e incluso capturar cambios adicionales. En pocas palabras, lo que se está haciendo es “civililizar” el proceso de tomar código que ya tenemos y ajustarlo a nuestras necesidades.

IBM anunció el lanzamiento de WebSphere sMash, una plataforma para el desarrollo y ejecución de mashups. sMash es la versión comercial del proyecto de incubación denominado Project Zero, el cual seguirá disponible de forma gratuita para desarrolladores.

Junto con sMash también se lanzará el IBM Mashup Center, que es un repositorio de mashups donde los usuarios no técnicos podrán fácilmente escoger y utilizar widgets por medio de drag and drop para ensamblar sus propios mashups. sMash estará disponible en junio de 2008, y se espera que en el segundo semestre del año, también se ofrezca un servicio de hosting donde se puedan ejecutar aplicaciones de Project Zero. Otra innovación que se espera próximamente como parte de esta plataforma es un IDE 100% en web para desarrollo de mashups.

Desde su separación de Borland, CodeGear ha buscado distinguirse como una empresa que conoce a los desarrolladores y les da las herramientas que realmente necesitan. Tal parece que JBuilder 2008 con Application Factories es una excelente prueba de esto.

Más información en www.projectzero.org y www-306.ibm.com/software/webservers/smash

Más información en www.codegear.com

Thought Works Mingle

Quest

Nuevas Herramientas para Sharepoint

Sharepoint ha cobrado gran popularidad en los últimos años. De acuerdo con Gartner, el 80% de las organizaciones utilizarán Sharepoint para el año 2010. Sin embargo, solo el 40% lo utilizarán efectivamente. Con esto en mente, Quest Software ha desarrollado un conjunto de herramientas que facilitan y mejoran distintos aspectos relacionados con Sharepoint, tales como la migración de información, desarrollo e integración de aplicaciones, y gestión de la base de datos.

12

Mingle es una herramienta web para colaboración y administración de proyectos. Mingle es un producto de Thoughtworks, una de las empresas más reconocidas internacionalmente en el área de consultoría y desarrollo con metodologías ágiles. Es así que Mingle está diseñado para soportar las características de los proyectos de software modernos, tales como desarrollo iterativo e incremental, y equipos con miembros distribuidos geográficamente.

Entre los nuevos productos hay una herramienta para migración de Notes a Sharepoint, otra para desarrollo de aplicaciones Sharepoint, y otra para migración de archivos desde carpetas públicas.

Recientemente fue liberada la versión 2.0 de Mingle, y entre sus capacidades más llamativas están el manejo de historias de usuarios, wikis para la colaboración entre desarrolladores, alertas por RSS y dashboards para visualizar el estatus del proyecto. Pero lo mejor de Mingle es que es gratis para equipos con 5 usuarios o menos. Así que si tienes un proyecto de software donde el equipo está distribuido y andas buscando una herramienta para colaborar y organizar el proyecto, Mingle es una excelente opción.

Más información en www.quest.com

Más información en studios.thoughtworks.com

MAY-JUL 2008

www.sg.com.mx

www.sg.com.mx

publicidad MAY-JUL 2008

// PRODUCTOS

/*HERRAMIENTAS*/

Análisis y Medición de Código Administrado con Visual Studio® 2008 Caso Database Commander y SQL Buddy Por Rigoberto Calleja Cervantes y Rajah James

En este trabajo se presentan los resultados de una prueba realizada con las herramientas de análisis y medición de código administrado de Visual Studio® 2008. El análisis se aplicó a dos piezas de código abierto: Database Commander y SQL Buddy, que están enfocadas a crear un entorno para acceder a diversos backends de bases de datos, y se describen los datos cualitativos obtenidos acerca de qué tan fácil se instalan las herramientas para analizar los proyectos designados y qué tan rápido se encuentran errores empleándolas.

Herramientas de análisis de código Las herramientas de análisis llevan a cabo diversas verificaciones para determinar la presencia de defectos en el código, analizando los ensamblados y reportando cierta información acerca de aquéllos, tal como violaciones de reglas de programación y diseño, establecidas en los lineamientos de diseño del .NET Framework. Estas herramientas representan las verificaciones que se llevan a cabo durante el análisis como advertencias. Los mensajes de advertencias identifican cualquier problema de diseño o programación relevante y cuando es posible, dan información acerca de cómo corregirlo.

Las advertencias antes mencionadas indican violaciones de reglas en bibliotecas de código administrado y están organizadas en una serie de áreas tales como diseño, desempeño, seguridad, etcétera.

Este tipo de herramientas tienen la capacidad de permitir al usuario indicar que una determinada advertencia no es aplicable, con lo cual se informa a los desarrolladores, a quienes revisen el código posteriormente que esa advertencia ya fue investigada.

Finalmente, permiten que uno se asegure de que el código que esta siendo protegido esté limpio, mediante el establecimiento de una política de protección que requiera que el análisis de código sea ejecutado; de esta manera solamente se podrá proteger una pieza de código. Si ésta pasó exitosamente aquél.

Herramientas de medición de código Las herramientas de medición son empleadas para generar métricas del código, referentes a su complejidad y la facilidad para darle mantenimiento, que permiten a los programadores entender mejor lo que están desarrollando. Al emplear las métricas, los desarrolladores pueden entender qué tipos y/o métodos deben ser escritos

nuevamente o probados con mayor profundidad. Asimismo, pueden identificar riesgos, entender mejor el estado actual del proyecto y dar seguimiento al progreso del mismo. Sin embargo, estas métricas no sirven a menos que tengan sentido para la persona que las está usando, en este caso el desarrollador, por lo que a continuación se presenta una breve descripción del significado de algunas de las cinco métricas ofrecidas por las herramientas.

• Acoplamiento de clases. Indica el número total de dependencias de otros tipos que un determinado nivel tiene. Este número no incluye tipos primitivos o incorporados, tales como int32, object o string, y cuando es mayor, aumenta la probabilidad que los cambios realizados en otros tipos se propaguen al elemento que está siendo analizado. Un valor más bajo de acoplamiento de clases generalmente indica un candidato para reutilización.

• Complejidad ciclomática. Mide el número total de rutas individuales a lo largo del código en cada nivel, y se calcula contando el número ramas (tales como switch, foreach y ciclos for) más uno. Esta métrica generalmente es una buena indicación del número de pruebas unitarias que se requerirán para obtener una completa cobertura del código.

• Índice de facilidad de mantenimiento. Es un número que va de 0 a 100, se calcula para cada miembro y nivel de tipo, e indica su facilidad de mantenimiento en general. Se calcula en base a otras métricas incluyendo la complejidad ciclomática y el número de líneas de código, e incluye un indicador icónico. Un número menor indica que el código es complejo y difícil de darle mantenimiento. El rango menor, 0-9, muestra un círculo rojo, mientras que el rango intermedio, 10-19, muestra un triángulo amarillo y por último, una caja verde indica alta facilidad de mantenimiento con valores entre 20 y 100.

Instalación de Visual Studio® 2008 Team Suite Después de descargar la versión de evaluación por 90 días de la Visual Studio® 2008 Team Suite, se inicia el proceso de instalación. En virtud de que se quiso hacer el proceso de instalación lo más ligero y ágil posible, se seleccionaron solamente aquellas opciones que eran absolutamente necesarias para que las herramientas de análisis y medición de código funcionaran sobre proyectos de C#. Sin embargo, el proceso de instalación tuvo problemas, la instalación del .NET Framework versión 3.5 falló. La bitácora de instalación no proporcionó suficiente información para determinar cuál era el problema, probablemente hubo un conflicto entre el mencionado componente y otro no identificado que ya estaba instalado en el equipo. La solu-

Rigoberto Calleja Cervantes (rcervant@andrew.cmu.edu) tiene cuatro años de experiencia como consultor en ingeniería de software, impartiendo cursos y participando en proyectos de adopción de herramientas de gestión del ciclo de vida de desarrollo de software. Rigoberto tiene un posgrado en ingeniería de software de la Universidad Carnegie Mellon.

14

MAY-JUL 2008

www.sg.com.mx

ción fue crear una máquina virtual desde cero instalando únicamente el sistema operativo y Visual Studio®.

cuales era crítico. Por ejemplo: la imposibilidad de respaldar archivos con extensión .MDX era un error trivial, ya que esta clase de archivos constituyen un tipo de base de datos.

Después de la conversión, intentamos compilar el proyecto, para lo cual fue necesario compilar un proyecto dependiente (que estaba incluido en el código fuente, pero no en la solución) que proveía un control para la aplicación. Una vez que concluimos lo anterior, fuimos capaces de compilar el código fuente en Visual Studio® 2008 por primera vez.

Figura 1. Opciones de instalación de la Visual Studio Team Suite.

Ya con el proyecto cargado, intentamos invocar el análisis. En base a una entrada de blog que identificamos, sabíamos que era necesario intentar obtener primero las métricas de código. A pesar de que en un principio no entendimos por completo el significado de las métricas, fue gratificante observar que los resultados se produjeron muy fácil y rápidamente. El hecho de que todos los proyectos se hayan mostrado en color verde nos transmitió confianza acerca del estado del código fuente.

El proceso de instalación de la documentación fue sencillo, bastó con invocar un asistente de instalación por separado.

Database Commander Después de descargar el código fuente del DBCommander, encontramos varios problemas. En virtud de que el código fuente del DBcommander no fue escrito originalmente con Visual Studio® 2008, fue necesario invocar el asistente de conversión de soluciones que viene incluido. Lo anterior produjo algunos errores, ninguno de los

www.sg.com.mx

Figura 2. Métricas del código del Database Commander.

MAY-JUL 2008

//PRODUCTOS

/*HERRAMIENTAS*/

Cuando miramos las métricas en Visual Studio® 2008, se nos dificultó un poco entender exactamente qué significaban, partiendo del hecho de que se presentan como un árbol, en donde el nivel del proyecto constituye la raíz, y cada nivel de éste puede representar un tipo diferente. Es decir, las métricas tienen un significado diferente en función al tipo de un nivel en particular.

Posteriormente probamos el análisis de código. Esta función está disponible seleccionando el proyecto de inicio en el explorador de proyectos y la opción “Ejecutar Análisis de Código” del menú de análisis. De esta manera se ejecuta el análisis que verifica el código contra los lineamientos de diseño de Microsoft que mencionamos anteriormente. ¡Este análisis generó 159 advertencias! Sólo tomando en cuenta el proyecto de arranque. Sin embargo, nos tranquilizó el hecho de que no se encontraron errores. Después de ejecutar el mismo análisis en cada uno de los otros dos proyectos, obtuvimos un total de 509 advertencias.

La primera advertencia se debía a que el nombre de un ensamblado estaba mal escrito. Al hacer clic derecho sobre el error se nos permitió seleccionar la opción mostrar Ayuda del Error. Lo anterior nos proporcionó una descripción acerca de cómo corregir la advertencia, lo que involucró agregar la palabra mal escrita al diccionario personalizado contra el cual se realizan las verificaciones. El diccionario personalizado es un archivo llamado CustomDictionary.xml. En el ejemplo de la ayuda, fue interesante ver que el archivo todavía tiene referencias al sitio anterior de FXCop. Todo este proceso nos pareció incómodo. Lo que esperábamos era encontrar una opción que nos permitiera agregar una palabra directamente al diccionario personalizado.

La solución está compuesta de dos proyectos: el principal y el de instalación. Después de realizar la conversión de la solución eliminamos el proyecto de instalación ya que no era de interés. Una vez hecho lo anterior fuimos capaces de compilar el código fuente en Visual Studio® 2008 por primera vez.

Para calcular las métricas de código simplemente accedimos al menú analizar y seleccionamos la opción “Calcular Métricas de Código para SQL Buddy”. La ventana de métricas de código muestra los datos que son generados por el análisis. Decidimos enfocarnos exclusivamente en el índice de facilidad de mantenimiento para el proyecto.

Recordemos qué, un icono verde indicia un grado relativamente alto de facilidad de mantenimiento, mientras un icono amarillo indica un grado moderado de facilidad de mantenimiento, por último, que un icono rojo indica baja facilidad de mantenimiento y un área potencialmente problemática. Los resultados del índice de facilidad de mantenimiento indican que el código fuente del SQL Buddy tiene relativamente un alto grado de facilidad de mantenimiento y no contiene áreas que puedan ser problemáticas. Antes de analizar el código del proyecto decidimos activar únicamente la categoría de reglas de nomenclatura.

SQL Buddy Tal y como ocurre en el caso del DBCommander, el código fuente de SQL Buddy no fue escrito empleando Visual Studio® 2008, de modo que fue necesario hacer una conversión. Afortunadamente, el proceso de conversión se inició automáticamente cuando abrimos la solución de SQL Buddy la primera vez y concluyó sin errores.

Figura 4. Selección de categorías de reglas para el análisis de SQL Buddy.

La ejecución del análisis de código fue una operación muy intuitiva, desde el menú analizar seleccionamos la opción “Ejecutar el Análisis de Código en SQL Buddy”. Después de que el análisis fue concluido, la ventana lista de errores fue desplegada mostrando todas las advertencias. Esa ventana incluye la descripción de la alerta, el archivo y el número de línea donde está localizada.

Figura 3. Reporte de conversión del código de SQL Buddy.

Al dar doble clic sobre ésta, se mostró el archivo y la línea de código que contiene el problema. El análisis produjo 297 advertencias. Consideramos que este es un número alto de advertencias, tomando en cuenta el hecho de que la cantidad de código fuente de SQL Buddy es relativamente pequeña. A partir de estos resultados pudimos concluir que el código fuente tiene un bajo nivel de apego a las reglas de nomenclatura de los lineamientos de diseño del .NET Framework.

Rajah James (rjames@andrew.cmu.edu) es ingeniero senior en Yellowstone Hotel Systems y está trabajando en la última versión de su software principal OpenBook; antes trabajó durante seis años para Rockwell Software y Rockwell Automation, donde estuvo involucrado con sus soluciones de manufactura e integración empresarial basadas en .NET. Rajah tiene un posgrado en ingeniería de software de la Universidad Carnegie Mellon.

16

MAY-JUL 2008

www.sg.com.mx

Las herramientas de análisis de código incluyen información detallada acerca de cada advertencia incluyendo: el código específico que provoca su generación, una descripción de los problemas detrás de la advertencia, una explicación de cómo cambiar el código fuente para satisfacer la regla y prevenir que se genere además de, una descripción de cuándo es conveniente suprimir una advertencia.

Para mirar esta información hicimos clic derecho en una advertencia y seleccionamos la opción “Mostrar Ayuda del Error”. Gracias a esta información, la tarea de entender el significado de las advertencias fue muy fácil.

Por otro lado notamos que un número pequeño de las primeras advertencias en la lista tenían valores en blanco para el archivo y el número de línea. Al principio no entendimos porqué, sin embargo posteriormente descubrimos que el problema estaba relacionado con varios archivos. Las advertencias antes mencionadas estaban relacionadas con el uso de letras mayúsculas y minúsculas en el nombre de algunos espacios de nombres.

Después de analizar las explicaciones detalladas de estas advertencias y el código fuente, llegamos a la conclusión de que estas eran válidas y decidimos corregirlas, para hacerlo empleamos la capacidad de refactorización del entorno. Finalmente, ejecutamos el análisis de código nuevamente y verificamos que las advertencias ya no aparecieran. En este caso encontramos que el proceso fue fácil y las capacidades del entorno que empleamos resultaron ser muy intuitivas.

Conclusión Estas herramientas son intuitivas y fáciles de usar. La realización de la mayoría de las operaciones básicas tales como iniciar un análisis, mirar sus resultados, encontrar el código que tiene el problema y corregirlo, fue sencilla. La documentación del producto es muy abundante lo cual facilita el entendimiento de las advertencias. La funcionalidad de métricas de código es muy poderosa, porque permitió tener un panorama claro acerca del nivel de facilidad de mantenimiento del código fuente, a pesar de que no estábamos familiarizados con él. Adicionalmente, estas herramientas no requieren prácticamente ningún tipo de configuración. Asimismo la conversión de los www.sg.com.mx

proyectos fue automática. Encontramos y corregimos advertencias sobre reglas de nomenclatura en los espacios de nombres del código fuente de SQL Buddy. Por último, éstas pueden hacer una excelente combinación con las herramientas de pruebas unitarias, ya que soportan el establecimiento de una política de protección de código.

Por otro lado, las herramientas de análisis y medición de código únicamente pueden ser aplicadas a ensamblados administrados, lo cual constituye una limitación importante ya que no pueden procesar código producido en otros lenguajes predominantes tales como C++ o Java. Las herramientas de Visual Studio® 2008 están empotradas en el entorno de Visual Studio® la cual es un producto grande y complejo que en ocasiones puede ser difícil de instalar. Llevar a cabo la selección de un subconjunto de alertas relevantes para un proyecto en particular no es una tarea trivial ya que requiere conocimiento de los lineamientos de diseño de la compañía que los produce. Asimismo, no existe la noción de severidad dentro de las advertencias obtenidas que pueda ayudar al desarrollador a decidir por dónde comenzar a corregir las advertencias.

Por último, las herramientas de análisis de Visual Studio® 2008 son por mucho las más fáciles de instalar de todas las que hemos usado hasta el momento. De modo que, en dependencia de cuáles atributos de calidad estés tratando de dar seguimiento y mejorar en su proyecto, la suite puede ser de mucha utilidad.

Referencias: [blogs.msdn.com/fxcop/archive/2007/10/03/ new-for-visual-studio-2008-code-metrics.aspx] [ dbcommander.sourceforge.net] [msdn2.microsoft.com/en-us/library/ czefa0ke(VS.71).aspx] [msdn2.microsoft.com/en-us/vstudio/ products/aa700831.aspx] [sqlbuddy.sourceforge.net] MAY-JUL 2008

Consideraciones Para Migrar un Modelo de Data Warehouse Multidimensional El Almacenamiento de Datos en las Empresas Por Ernesto Ulianov Reyes Romero

E

l presente artículo pretende guiar al lector en las consideraciones que tiene que seguir para migrar de Data Warehouse como una solución para el análisis de la información financiera, el ejemplo esta referido para una empresa de Telecomunicaciones dedicada a ofrecer equipo y servicios de telefonía celular. ~: Antecedentes :~

18

MAY-JUL 2008

www.sg.com.mx

~: Antecedentes :~ Las empresas en el mercado de las Telecomunicaciones que actualmente es un medio muy dinámico y competitivo, deben considerar mejores estrategias comerciales que estén basadas en capturar y retener a los clientes más rentables, siendo ellos la mayoría de las veces los de mayor consumo. Las estrategias tradicionales de ventas y comercialización son desafiadas por estas características del mercado: • La explosión de tecnología de comunicaciones ha cambiado rápidamente los tipos de ofertas de servicio disponibles. Hoy se cuenta con tecnologías de comunicación inalámbricas que ofrecen capacidades de transmisión suficiente como para ofrecer servicios tradicionales de voz, TV On Demand, transmisión de datos e Internet móvil en un mismo canal.

• La variedad en ofertas y precios ha llevado el poder de compra al consumidor que cada vez exige mayor valor a un menor precio.

• Las decisiones de lealtad, están volviéndose rápidamente a ser manejadas por el valor.

• Las empresas están cada vez más enfocadas en la captura y retención de clientes más rentables lo que implica detectar a tiempo estas oportunidades.

~: Descripción del problema :~ Se deben exponer la problemática dadas las características actuales del Data Warehouse y algunas de las razones del por qué se requiere hacer este proyecto (migración): 1. Se debe visualizar si se requiere migrar tanto de modelo como la información para tener una mejor integridad de ésta y que sea más ágil la carga diaria de la información.

2. El modelo debe soportar la estructura actual del Data Warehouse con la posibilidad de darle un crecimiento a nuevos nichos de información por la creación de nuevos servicios que ofrece la compañía.

3. Hacer más eficiente y versátil la extracción de la información para su análisis.

4. Se requiere de mejores indicadores que le den información puntual a los directivos de cuáles son los productos y servicios que están funcionando.

5. Este tipo de proyectos requiere de la experiencia de un Líder de Proyecto que conozca de Bases de Datos y que tenga conocmiento en la elaboración de procesos mediante Procedimientos Almacenados (SP) y la Extracción Transformación y Carga (ETL). Además requiere de la experiencia en el negocio de la telefonía celular y el análisis financiero que se hace de los productos y servicios que ofrecen las compañías de Telecomunicaciones, así como la obtención de los indicadores que evalúan para el análisis financiero.

6. Su crecimiento requiere de un modelo más acorde al volumen de información que se está manejando, por lo que se cuestiona si el modelo actual y la plataforma actual soportarán el crecimiento de toda la información que proporcionan las diferentes áreas de la compañía.

www.sg.com.mx

Por los motivos anteriores, se deben plantear las siguientes interrogantes: ¿El modelo satisface la necesidad creciente del manejo de información que se tiene actualmente? ¿Se tiene una plataforma acorde a las necesidades actuales del Data Warehouse? ¿Se tiene una eficiente extracción de la información para el análisis financiero de forma que esté disponible para las diferentes áreas de la compañía?

De estos tres cuestionamientos esenciales se determina que se necesita plantear una solución a las necesidades actuales del Data Warehouse.

~: Propósito de Desarrollo de un Data Warehouse:~ El propósito en el desarrollo de este tipo de modelos es encontrar uno que represente una solución al problema y permita hacer la migración del actual a un modelo multidimensional en una plataforma tecnológica que soporte la estructura que se tiene actualmente y que pueda crecer, ocupando herramientas orientadas a la consulta de grandes volúmenes de información histórica, procesamiento masivo de información, con estructuras dinámicas y abundantes cambios.

Se debe elaborar un modelo de Data Warehouse acorde al negocio de las Telecomunicaciones, creando los métodos de carga de información diaria así como su extracción para generar niveles de agregación de la información financiera del comportamiento del negocio que permita al equipo de analistas de la compañía, estudiar todo aquello que le permita conocer como están las ventas de sus productos y servicios, a través del tiempo y visualizar que ocurre con los movimientos de las terminales, estatus en cuanto a servicios, planes tarifarios, promociones, etcétera.

~: Particulares del Proyecto de Data Warehouse :~ Para tal fin se deben plantear los siguientes objetivos particulares: • Implantar un modelo de datos conforme a los requerimientos de información y análisis definidos por la empresa de la industria de telecomunicaciones.

• Utilizar una herramienta de extracción y administración de datos, como puede ser la plataforma de Oracle Warehouse Builder para el Proceso de Adquisición y Transformación de datos.

• Utilizar herramientas de explotación de datos, para ser empleadas por los ejecutivos de negocio de la compañía.

• Desarrollar los ambientes de datos significativos para realizar pruebas de funcionalidad de los procesos de extracción de datos.

• Estudiar los patrones de ingreso por el tipo de tráfico, así como su comportamiento en cuanto a saldos y abonos de tiempo aire realizados.

~: Justificación del Data Warehouse :~ Para cualquier compañía, la conveniencia de tener un gran depósito de información histórica es de suma importancia y sobre todo si esta información es la financiera, de donde pueden hacer un análisis del comportamiento de ventas y costos de operación de sus productos o servicios.Las compañías de Telecomunicaciones no son la excepción, especialmente dada la feroz competencia que se está dando en este segmento.

MAY-JUL 2008

19

En primera instancia lo que se pretende es mejorar el modelo del Data Warehouse para migrar el contenido de la información utilizando uno nuevo que permita tener el crecimiento de los datos que requiere la compañía y acrecentar la información financiera para saber cómo está operando día con día.

Entre mejor y más oportuno sea el análisis de la información se podrá encontrar de manera más oportuna los errores o fallas en los que se está incurriendo con el fin de mejorar el ofrecimiento de un bien o servicio que se le esta brindando al usuario por un costo más competitivo de lo que ofrece el mercado, redundado en mejoras tecnológicas de comunicación para ofrecer mejores productos y servicios al alcance de otros sectores de la población en general.

Poder tener un mejor modelo para el Data Warehouse resuelve en primera instancia una problemática de la compañía que impacta de manera mas amplia a la operación general de ésta y a los beneficios que se le puede ofrecer al usuario final. El modelo de Data Warehouse que se vincula con las particularidades de la información financiera que es utilizada por la compañía de Telecomunicaciones, es la aportación tecnológica que se ofrece para optimizar el análisis financiero de la compañía.

En la Base de Datos SQL Server por cada tipo de información se tiene una base de datos, de la cual no se tiene el control de los espacios ocupados en disco y no permitía su fácil acceso a pesar de estar partida en entidades por mes de información. Además no se contaba con niveles de agregación y siempre que se requería obtener información se necesitaba obtener del detalle el nuevo consolidado, que por necesidades de la empresa, se ocupan y se van almacenando en las diferentes bases de datos.

Para poder instrumentar el modelo, se plantea que la Meta Data (depósito de gran volumen de información) se basará en los siguientes aspectos: • Metadata Funcional. Modelo de acceso de datos, que traduce las definiciones de la estructura física de la base de datos en términos del negocio que son entendidos y empleados fácilmente por los analistas de la compañía.

• Metadata Técnica. Control y monitoreo de los procesos de Extracción, Transformación y Carga (ETL) de la solución (desde el área temporal de archivos o fuentes de información hasta las estructuras del Data Warehouse de la compañía), así como el manejo de errores.

En la figura 1, se muestra un diagrama descriptivo del modelo, en donde la zona marcada como la 2, es fundamentalmente la Meta Data Técnica y la Meta Data Funcional esta ligada a la zona 1 y 3 que conforman toda la estructura del modelo en términos del negocio.

El empleo de una plantilla para la implantación a partir de un modelo que establece la relación entre los clientes y el negocio y poder realizar el análisis del comportamiento, permitirá representar y analizar de manera homogénea a los clientes, cuentas y las terminales de la compañía, ya se traten de Corporaciones, PyME’s o personas físicas.

Aunque pueda definirse de manera conceptual la representación de los clientes de los distintos tipos de servicios ofrecidos, la implantación se debe acotar, por ejemplo a las terminales del servicio de prepago, donde los aspectos que pueden ser estudiados son: - Ingresos por tráfico.

- Activaciones de terminales.

- Movimientos de terminales.

- Abonos de tiempo aire.

- Comportamiento del saldo de terminales.

- Política saldo cero (estatus de una terminal después de sesenta días de tener saldo cero y no haber abonado tiempo aire).

Se trabajó en un proyecto donde el Data Warehouse de una compañía de telefonía celular se encontraba en una Base de Datos de SQL Server, donde no había propiamente un modelo y no cumplía con una relación entre sus entidades, es decir, no existía un modelo entidad-relación. Aunque existían algunos catálogos, no se ocupaban para dimensionar el detalle de toda la información financiera que se tenía cargada.

Se pensó en considerar la plataforma tecnológica de Oracle 10g para almacenar la información por tener un motor de bases de datos más eficaz, su métodos de búsqueda son más ágiles y por tener la capacidad de hacer modificaciones cuando la Base de Datos esta operando.

Figura 1. Diagrama descriptivo de un modelo de Data Warehouse.

Ernesto Ulianov Reyes Romero, es Maestro en Ciencias de la Computación egresado de la Fundación Arturo Rosenblueth. Profesor de Tiempo Completo de la Universidad Politécnica de San Luís Potosí y Consultor de Grupo Bizcorp. Por la experiencia como Líder de Proyecto, DBA, Analista y Diseñador se elaboro un Modelo de Migración de Información a un Data Warehouse Multidimensional para una empresa de Telecomunicaciones. Debido a la relevancia del Proyecto de DW se desarrollaron habilidades directivas proporcionando información ejecutiva para análisis financieros del negocio, mediante BI.

20

MAY-JUL 2008

www.sg.com.mx

- Churn (estatus de una terminal que esta en política de saldo cero y que no tiene tráfico entrante, es decir, no recibe llamadas a su teléfono del tipo el que llama paga).

- ARPU (ingreso obtenido por el tráfico de llamada entrante y/o saliente a una terminal).

- Financieros.

La solución debe contar con un conjunto de programas y procesos de manejo de los datos construidos y validados para altos volúmenes de información. Estos programas permitirán la validación, generación de resúmenes e indicadores de gestión a partir del área de interfaz.

~: Acceso a los datos (aplicación de análisis) ;~ Con el fin de satisfacer las necesidades de análisis de la información almacenada en el Data Warehouse, la solución debe contemplar la implantación de un portal de análisis que apoye en los siguientes niveles: 1. Análisis General. Esta área debe permitir a los analistas conocer la situación general del negocio a través del empleo de indicadores de gestión que les apoyará en responder preguntas relacionadas a la situación actual, las tendencias, causas, entre otras.

2. Análisis Detallado. Esta área debe permitir a los analistas conocer la situación detallada de cada uno de las terminales, así podrán identificarse patrones de comportamiento de tráfico e ingresos, movimientos, saldos y tiempo aire de las terminales, identificación de perfiles de terminales según cierto comportamiento, suscriptores a contactar en iniciativas de mercadeo, entre otras.

~: Manejo de Metadata :~ La implantación de la meta data de la solución se debe basar en los siguientes aspectos: • Metadata Funcional. Consistirá en la definición de un modelo de acceso a los datos de la Base de Datos del Data Warehouse que traduzca las definiciones de las estructuras físicas de la base de datos en términos del negocio que puedan ser entendidos y empleados fácilmente por parte de los analistas de la compañía. Además es el modelo de acceso que será instrumentado empleando las facilidades ofrecidas por una herramienta que permita tener el acceso más ágil y eficiente, donde se deberá proveer en forma oportuna la semántica correspondiente.

www.sg.com.mx

• Metadata Técnica. Apoyará el control y monitoreo de los procesos de Extracción, Transformación y Carga (ETL) de la solución (desde el área temporal de archivos planos hasta las estructuras del Data Warehouse de la compañía), así como el manejo de errores, será implantado una entidad que de seguimiento de los procesos de carga. Además se implantarán reportes predefinidos que permitirán analizar la ejecución de los programas, con los siguientes datos: Para Control y monitoreo de carga: - Identificador del proceso ejecutado.

- Fecha, hora de inicio/ Fecha, hora de fin.

- Cantidad de registros leídos.

- Cantidad de registros procesados.

- Cantidad de registros rechazados.

- Estatus final de ejecución.

Para el manejo de errores: - Identificador del proceso ejecutado.

- Fecha, hora de inicio.

- Descripción del error.

- Cantidad de registros rechazados.

La arquitectura de referencia se vuelve importante porque aporta: - Ofrece un diagrama de un anteproyecto común - Crea una base duradera para implantar la visión de la empresa.

- Proporciona alternativas en la implantación - Permite ubicar las ofertas y distribuidores en el diagrama de la arquitectura de referencia.

- Destaca los componentes de una solución que son valiosos para la producción.

La arquitectura de referencia describe primero desde un punto de vista abstracto y simplificado a alto nivel, del modo siguiente: - Un conjunto de datos extraídos de la base de datos operacionales - Un software que prepara los datos para que los usuarios accedan - Un conjunto de aplicaciones y herramientas que ejecutan un conjunto de consultas y análisis complejos Una arquitectura que propone Harjnder es descomponer sistemáticamente en detalles, partiendo de la Infraestructura, Transporte, Administración de Meta datos, para ir subiendo de nivel, hacia la Fuente de Datos, Construcción del Data Warehouse, Construcción de los niveles de agregación, Acceso de Datos y Administración de Datos.

El planteamiento de dicha arquitectura contempla en su proceso tres fases importantes: la de Refinamiento, Reingeniería y después de obtener el modelo de Data Warehouse otra fase de Refinamiento y Reingeniería, lo que no permite que se haga un modelo en poco tiempo, ya que requiere de varias etapas y fases en cada una de las etapas, añadiéndole que propone otros sistemas importantes dentro de la capa de infraestructura como son: Administradores de Configuración, Administradores de Almacenamiento, Administradores de Seguridad, Administración de Distribución, Administración de Licencias, Vigilantes de desempeño y Analizadores de la Capacidad.

Todo esto hace que construir el modelo a implantar se vuelva un proyecto complicado y largo por lo que sólo se considera el diseño del Data Warehouse y el de las Agregaciones, por tal razón y debido a que el proyecto tiene un tiempo programado de tres meses se omite los puntos relacionados con la construcción.

Conclusión Con lo antes propuesto para iniciar cualquier proyecto de Data Warehouse se debe tener bien definido la problemática, objetivos y alcances del proyecto, exponiendo los justificantes que lleven a emprender y satisfacer las necesidades del proyecto con una metodología. Se establecen los principios en los que se debe elaborar el diseño, presentando la propuesta a seguir.

Referencias [ Berthold, M.; Hand, D.J. Intelligent Data Analysis, An Introduction. Springer 1999 ] [ Corey, Michael J., Abbey, Michael. Oracle Data Warehousing, Oracle Press. Osborne/Mc Graw-Hill. 1997 ] [ Edwards, John. Building the Right Data Mart. Oracle Magazine. U.S. Marzo/Abril 1998 ] [ Harjner, S. Gil y Prakash C. Rao. La integración de la información para la mejor toma de decisiones data warehousing. Prentice Hall Hispanoamérica, 1996, México ] [ Inmon, W.H. et al. Managing the data warehouse, John Wiley, 1997 ]

MAY-JUL 2008

21

MAY-JUL 2008

www.sg.com.mx

www.sg.com.mx

MAY-JUL 2008

// ENTREVISTA

Conoce a los

Key Speakers de SG’08

John Crupi

John es CTO en JackBe Corporation, y es reconocido como una de las mentes más influyentes en el área de cómputo empresarial distribuido. Durante su carrera ha sido reconocido como Sun Distinguished Engineer, y seleccionado como miembro del “Dream Team” de desarrollo de software por la revista Software Development. Es co-autor del afamado libro “Core J2EE Patterns” y es un conferencista frecuente en congresos internacionales tales como JavaOne, AjaxWorld y SOAWorld.

¿Donde se encuentra la industria en cuanto a estándares para mashups?

El concepto de mashups empresariales todavía es nuevo, y no hay estándares “oficiales” todavía. Ante esto, lo que nosotros (JackBe) hemos hecho es crear tecnologías en base a estándares existentes. Por ejemplo, creamos un metalenguaje para definir mashups llamado Enterprise Mashup Markup Language (EMML) el cual está basado en estándares como XML, Xpath y Xquery.

IBM recientemente formalizó su entrada al espacio de enterprise mashups. ¿Qué significa esto para ustedes?

El hecho de que empresas como IBM entren en este segmento confirma su importancia y validez. Si ellos están entrando, es porque ven que hay un valor para sus clientes. Además de JackBe, IBM es el único proveedor de software que ha creado su tecnología para mashups desde cero. Pero el problema que enfrentan es lograr integrarlas exitosamente en los universos de Websphere y Lotus, que son grandes, complejos, y algo viejos. ¿Dónde nos encontramos en términos de una base de usuarios acostumbrada/dispuesta a hacer mashups?

Los usuarios de negocio han estado haciendo mashups desde hace más de 15 años; lo llaman Excel. El problema es que normalmente dedican la mayoría de su tiempo a reunir, copiar, pegar y unir los datos que necesitan para poder tomar decisiones. ¿Por qué realizan todo este esfuerzo? Porque no tienen opción. Los datos se encuentran encerrados en su ERP, aplicaciones internas y sistemas de información empresarial.

24

MAY-JUL 2008

Los departamentos de TI se han enfocado en generar almacenes de datos y normalizar/ denormalizar grandes cantidades de información. Pero esto no es lo que requieren los usuarios, ellos necesitan pequeñas rebanadas de información combinada. Pero como cada uno requiere un pequeño conjunto, TI no les hace caso porque son cosas muy pequeñas y no pueden dedicarles tiempo.

Java EE ya no suena tanto como antes. ¿Crees que esté perdiendo importancia? ¿Qué crees que suceda con Java EE en el futuro cercano?

Yo creo que Java EE seguirá dominando el segmento de aplicaciones web transaccionales. Sin embargo, para web services y mashups que no manejan estado (stateless), Java EE no tiene mucho sentido. De hecho, con Tomcat tienes todo lo que necesitas. ¿Crees que los lenguajes y frameworks como Ruby/Rails, Python/Django, Groovy/ Grails penetrarán el mercado empresarial?

Creo que todos los lenguajes dinámicos tendrán una penetración importante en el espacio empresarial en los próximos años. Es de gran utilidad no tener que compilar, empaquetar e

instalar algo simplemente para obtener nuevos datos. Los lenguajes estáticos están en recesión, los dinámicos son el siguiente paso. ¿Qué te gusta más, desarrollar tecnologías o evangelizarlas?

Me apasiona evangelizar sobre lo que mis colegas y yo desarrollamos. También disfruto mucho construir demos para demostrar posibilidades de solución a un problema. ¿Qué se siente trabajar en una empresa startup, sobre todo después de haber trabajado en una empresa tan grande como Sun? Es muy divertido, pero debes tener nervios de acero. Existen muchos factores desconocidos, pero tienes una visión que puede moldear el futuro. Da una enorme satisfacción cuando funciona. ¿Algunas palabras de sabiduría para nuestros lectores?

Empiecen a considerar los enterprise mashups y widgets como la nueva generación de micro-soluciones. Los mashups le quitan muchos dolores de cabeza a la integración y pueden traer grandes beneficios tanto a desarrolladores como a usuarios. www.sg.com.mx

Terry Quatrani Terry Quatrani es evangelista en jefe de UML en IBM Corporation.

Como tal, es responsable de entrenar y asistir a los principales clientes de IBM para adoptar prácticas de modelado visual y orientación a objetos. Terry es una conferencista frecuente en eventos como el Rational User Conference, OOPSLA, y SD West/East. Es autora de la serie de libros “Visual Modeling with Rational Rose and UML”, y también es colaboradora frecuente en la revista Dr. Dobbs Journal.

¿Qué disciplinas del desarrollo de software se benefician más del uso de modelado visual?

Creo que el modelado visual trae beneficios a un proyecto de software a lo largo de todo su ciclo de vida, para: administrar complejidad, detectar errores y omisiones, comunicar a los involucrados, entender requerimientos, dirigir la implementación, entender el impacto del cambio, y asegurar que los recursos de infraestructura sean utilizados adecuadamente.

Qué tanto modelado se haga, y durante qué actividades, ya dependerá del proceso, proyecto y experiencia de los modeladores.

gación para un front end sencillo de una base de datos. Simplemente aplico la transformación, ¡y la aplicación se genera por completo!

UML 2 ya tiene varios años en el mercado, pero la mayoría de las organizaciones todavía utilizan UML 1.x ¿A qué se debe esto?

El principal problema que retrasó la adopción de UML 2 en un principio fue la falta de soporte en las herramientas de modelado. De hecho, creo que a la fecha ninguna herramienta soporta UML 2 por completo.

Llevamos varios años sin llegar a un consenso sobre qué lenguaje/ notación usar para modelar procesos de negocio. ¿Cuál es tu opinión al respecto?

Creo que el estándar que prevalecerá es BPMN. Esta es la notación con la que la gente de negocio se siente cómoda, ellos no quieren usar UML. Habiendo dicho eso, creo que aquí es donde MDA puede ser de gran utilidad. Por ejemplo, actualmente existen herramientas que pueden leer un modelo creado por una herramienta de modelado de negocios en BPMN, y hacer la transformación en tiempo real hacia UML. De esta forma, se obtiene lo mejor de dos mundos: BPMN para la gente de negocio y UML para la gente de software y sistemas.

Aun así, cada vez hay más organizaciones que utilizan UML 2 y le encuentran ventajas. Una de las fortalezas de UML 2 es el soporte para diagramas de secuencia, que me parece maravilloso. Otra fortaleza de UML 2 son las clases estructuradas. Sin embargo, la adopción de estas capacidades no es muy amplia, ya que solo tienen sentido para aquellos que están modelando arquitecturas orientadas a servicios, o sistemas de tiempo real. Creo que conforme más organizaciones se muevan a SOA, aumentará significativamente el uso de UML 2. ¿Qué está sucediendo en el área de MDA (Model Driven Architecture)?

Hace un par de años era un tema muy popular y hoy casi no se escucha nada al respecto.

La industria está adoptando MDA sin que se haga mucho ruido al respecto. Tengo varios clientes que actualmente realizan transformaciones de MDA bastante sofisticadas. De hecho, en la arquitectura de Rational Software Architect hacemos uso extensivo de transformaciones.

Ya no “generamos” código, sino que lo “transformamos”. Yo tengo un demo que doy en algunas pláticas, el cual tiene un modelo de nave-

www.sg.com.mx

¿Qué libros le recomiendas a los lectores de SG? ¡Por supuesto que mi libro (Visual Modeling with Rational Rose)!

Jaja. Ya en serio, el libro que más recomiendo sobre UML es “UML Distilled” de Martin Fowler. ¿Has estado previamente en México?

No, esta será mi primera visita y estoy bastante emocionada por conocer el país y ver qué están haciendo las organizaciones de software allá. ¿Alguna recomendación final para los lectores?

Sigan modelando, pero solo utilicen lo que necesitan. No modelen simplemente por modelar.

MAY-JUL 2008

25

Jon “maddog” Hall

// ENTREVISTA

Ellos le pidieron a Marcelo que los ayudara a resolver esto, así que creó Hackerteen, que es un programa de educación virtual, donde enseña a los adolescentes a aplicar esa curiosidad y tiempo en Internet hacia algo de provecho. Se les enseña sobre seguridad computacional, ética de hacking, y cómo ser emprendedores. Está diseñado de forma que es muy atractivo para los adolescentes, ya que combina elementos de juegos de rol, anime, y un esquema de progresión como el del Karate donde los alumnos van subiendo de cinta.

Yo he sido consultor para el programa desde hace varios años y he visto el cambio positivo que genera en los jóvenes que participan, además de que les da una excelente base en caso de que quieran trabajar en el área de computación.

Sabemos que eres CTO en una empresa llamada Koolu, ¿puedes hablarnos un poco sobre ella?

El propósito de Koolu es llevar a los países en desarrollo sistemas de cómputo amigables con el ambiente y con el usuario. La tecnología de Koolu utiliza clientes delgados en conjunto con aplicaciones Web 2.0 para que los usuarios puedan dedicar todo su tiempo a hacer lo que quieren, y no pierdan tiempo en cosas como instalar/actualizar programas, eliminar virus, etcétera. Parte de la visión de Koolu es generar empleos de tecnología bien pagados en las economías locales. Actualmente estamos haciendo un

26

16

MAY-JUL 2008

Jon “maddog” Hall es Director Ejecutivo de Linux International, una asociación dedicada a promover el software libre, y CTO de Koolu, una empresa canadiense dedicada a llevar cómputo verde a países en desarrollo. El señor Hall es un conferencista altamente solicitado, y ha fungido como asesor en el tema de uso y aprovechamiento de software libre para los gobiernos de China, Malasia y Brasil, así como para las Naciones Unidas.

Nos enteramos que estás involucrado con un programa llamado Hackerteen. ¿Podrías decirnos de que se trata?

Hackerteen es un programa educativo creado por mi buen amigo Marcelo Marques en Brasil. Lo que sucedió es que la policia se dio cuenta que una buena parte de las personas que “craqueaban” los sistemas en realidad eran niños que usaban scripts de Internet para entrar a sistemas que no estaban debidamente protegidos.

piloto de esto en Costa Rica, con un cliente llamado Datatell. ¿Cómo aporta Linux al “cómputo verde”?

Linux tiene varias capacidades que contribuyen al cómputo verde, tales como apagar discos y bancos de memoria cuando no están en uso. Linux también es bastante fuerte en el área de virtualización, y a través de ésta se puede lograr una mayor eficiencia.

Por otro lado, el software libre es mucho más que Linux, y aquí la comunidad puede tener una gran contribución, desarrollando software más eficiente, que haga mejor uso de la energía. ¿En qué áreas de TIC dirías que Linux está liderando el camino?

Creo que la pregunta adecuada sería ¿en qué áreas no está liderando el camino? Y otra vez, me gustaría puntualizar que no solo me refiero a Linux, sino al software libre en general.

En el último par de años hemos atestiguado el surgimiento de tecnologías basadas en software libre como Asterisk, MythTV, y LinuxMCE que están teniendo un gran impacto tanto en las empresas como los hogares.

A pesar de los avances de Linux en otras áreas, en el desktop sigue con una participación pequeña. ¿Consideras que esto cambiará pronto o seguiremos viendo un avance lento de Linux en el desktop?

La vida es un río. Hace 15 años, que es cuando yo me involucré con Linux, el escritorio era básicamente un servidor de X Windows y un administrador de ventanas. Ahora tenemos un desktop completo con muchas aplicaciones sofisticadas. En ese entonces, los vendedores de computadoras ni de locura hubieran vendido máquinas con Linux. En cambio, hoy muchas empresas venden Linux preinstalado. De hecho, en algunas computadoras como la Eee PC es el default.

Lo que quiero decir es que seguimos avanzando, y aunque todavía estamos lejos de ser el sistema dominante en el desktop, estamos muy cerca de ser un jugador importante (que yo estimo que sería cuando lleguemos a un 25% del mercado). Cuando esto suceda, muchas cosas cambiarán. ¿Alguna recomendación para los lectores de SG? Sí. Lleven a un usuario de Windows a su próximo evento de software libre. Mejor que sean dos. Muéstrenle software libre en el desktop, servidores, etcétera y denles un live-CD para que ellos mismos puedan probarlo en sus computadoras. Únanse a SoftwareFreedomDay.org y pregonen sobre el software libre. Recuerden decirles que es “libre como en libertad”, y que no deberían ser esclavos de los vendedores de software propietario. Carpe Diem!. www.sg.com.mx

agamos un viaje en el tiempo hacia principios de esta década …

Acabábamos de sobrevivir el año 2000 sin que se cayera el mundo, y en el campo de la programación la palabra que más sonaba tenía cuatro letras y su logo era una taza de café. Java era EL lenguaje de programación y reunía lo mejor de lo mejor ya que era orientado a objetos, multiplataforma, y abierto (todavía no era libre, pero había acceso al código fuente). Además, con J2EE y J2ME se cubría el espectro desde dispositivos móviles hasta sistemas empresariales distribuidos. Todo parecía indicar que hacia el futuro Java sería el lenguaje de programación que se utilizaría para todo, y por lo tanto el único que sería necesario aprender.

Regresamos al presente, y si echamos un vistazo a las noticias, artículos y foros relacionados con desarrollo de software, nos encontramos con cosas como Ruby (con su framework Rails), Python, Erlang o Scala. En el frente de Microsoft, resulta que tienen una plataforma llamada .NET sobre la cual se ejecutan una gran diversidad de lenguajes, desde Cobol hasta algo llamado C#, y continuamente se agregan nuevos lenguajes (F#, IronPython) y capacidades para los lenguajes (LINQ). En el frente de Java, encontramos que hay un gran debate sobre las características que se deben incluir en Java 7, y que por un lado hay quienes creen que este debería mantenerse como un lenguaje sólido, estable, con poca innovación, y por otro lado quienes consideran que debe incorporar nuevas características que le permitan mantenerse a la vanguardia.

La conclusión es que de pronto los lenguajes de programación son relevantes otra vez. No es que hubieran dejado de ser importantes, sino que llegamos a pensar que ya eran un tema resuelto. Es así que dedicamos las siguientes páginas a estudiar las tendencias que están marcando este denominado...

28

MAY-JUL 2008

www.sg.com.mx

de los

www.sg.com.mx

MAY-JUL 2008

29

¿Hacia dónde van los lenguajes de programación?

Un Vistazo al Pasado, Presente y Futuro Por Ariel Ortiz Ramírez

o aprendí a programar usando una microcomputadora Timex Sinclair 2068 a mediados de los años ochenta. Esta maquinita tenía 72 KB de memoria, usaba una grabadora convencional como dispositivo de almacenamiento secundario, y venía de fábrica con un intérprete de Sinclair BASIC. Este dialecto de Basic usaba números de línea frente a cada enunciado. Había que usar la instrucción GOTO para realizar repeticiones, GOSUB para llamar subrutinas, y todas las variables eran globales. Comparado con las herramientas que tenemos disponibles hoy en día, este era un ambiente muy primitivo, pero aún así podía pasar largas horas programando felizmente ese aparatito.

Muchas cosas han cambiado en las últimas dos décadas. Sin embargo, los avances en el campo de los lenguajes de programación han sido más una evolución que una revolución.

En las siguientes secciones describo brevemente las tendencias más importantes que, desde mi punto de vista, marcarán las pautas en el diseño de los lenguajes computacionales que estaremos utilizando en los años por venir.

~:Programación funcional :~ La programación funcional es un estilo de programación basado en la utilización de funciones matemáticas. El cálculo lambda, desarrollado por el matemático norteamericano Alonzo Church en la primera mitad del siglo veinte, es la base teórica de este estilo de programación.

Lisp, Haskell, ML y Erlang son ejemplos de lenguajes funcionales.

30

MAY-JUL 2008

Las operaciones de cómputo en la programación funcional se llevan a cabo a través de la evaluación de expresiones que producen valores y que están libres de efectos secundarios. Por el contrario, en el estilo de programación imperativa, al cual pertenecen la mayoría de los lenguajes convencionales, el énfasis está en ejecutar enunciados que precisamente producen efectos laterales. En este caso, el principal efecto lateral es la mutación explícita de los valores contenidos en memoria.

Las variables en los lenguajes funcionales son parecidas a las variables de álgebra. Esto es, una variable representa un valor inicialmente desconocido, pero una vez que se conoce, este ya no cambia. En contraste, en los lenguajes imperativos una variable es simplemente el nombre de una localidad de memoria cuyo contenido puede ser arbitrariamente leído y/o modificado.

Gracias a que las variables son asignables una sola vez, los programas funcionales cuentan con una propiedad conocida como transparencia referencial. Se dice que una expresión es referencialmente transparente si puede ser remplazada por su valor, pero sin alterar los resultados producidos por el programa. La transparencia referencial es importante porque permite al programador, o al traductor del lenguaje, razonar sobre el comportamiento del programa. Este tipo de razonamiento es útil para probar que un programa es correcto, optimizar código a través de cachés, eliminar sub-expresiones comunes, simplificar algoritmos, e incluso parelelizar la evaluación de sub-expresiones.

Los lenguajes funcionales han introducido importantes conceptos que han sido posterior-

mente incorporados en muchos otros lenguajes.

Uno de los más notables es el referente a la recolección de basura, en donde el ambiente de ejecución, y no el programador, es responsable de determinar cuando cierto objeto de memoria ya no es usado por el programa y por lo tanto puede ser reutilizado en alguna otra parte. Lisp fue el primer lenguaje que usó esta técnica, ocurriendo esto a finales de los años cincuenta. Sin embargo, todavía a inicios de la década de los años noventa había poco respeto por parte de la industria de software hacia los lenguajes que hacían uso extensivo de recolección de basura, debido principalmente al costo de ejecución en el que se incurre. Gracias a la atención que generó Java en la última década, hoy en día prácticamente todos los lenguajes considerados “modernos” incorporan recolección de basura.

Otros conceptos importantes en que los lenguajes funcionales han sido pioneros incluyen: funciones como objetos de primera clase, cerraduras léxicas, recursión, tipos dinámicos, inferencia de tipos, y meta-programación.

~:Lenguajes dinámicos :~ Un lenguaje de programación dinámico es un lenguaje de alto nivel que lleva a cabo en tiempo de ejecución muchas acciones que otros lenguajes típicamente llevan a cabo en tiempo de compilación. Estas acciones incluyen cosas como agregar y evaluar código, modificar el sistema de tipo de datos, añadir propiedades a objetos, etcétera. En esta categoría de lenguajes están Lisp, Smalltalk, Tcl, JavaScript, Python, Ruby, Perl, PHP y Groovy. Dada su naturaleza, los lenguajes dinámicos

www.sg.com.mx

son normalmente interpretados, aunque sí existen compiladores para algunos de ellos.

Recientemente mucha gente ha tomado interés en los lenguajes dinámicos. Una de las principales razones es el incremento en la productividad que se logra al usarlos. Por ejemplo, es común que un programa escrito en Ruby o Python requiera entre 2 a 10 veces menos código que su equivalente en lenguaje C o Java. Usualmente un programa que es más pequeño toma menos tiempo en escribirse, es más fácil de comprender y modificar, y contiene menos errores que uno de mayor tamaño. Claro, esto no viene sin algunos inconvenientes. No es inusual que un programa escrito en un lenguaje dinámico llegue a ser decenas o incluso hasta centenas de veces más lento que un programa escrito en un lenguaje convencional compilado. Para cierto tipo de aplicaciones esto puede ser irrelevante.

Por ejemplo, imaginemos que tengo un cierto problema que debo resolver escribiendo un programa. Supongamos que si lo escribo en Python me llevaría dos horas, pero si lo hago en lenguaje C me llevaría diez. Por otro lado, supongamos que si ejecutara el programa en Python, éste tardaría cinco segundos mientras que el que está escrito en C tardaría 0.01 segundos. Bajo estos escenarios hipotéticos, tardaría cinco veces más en escribir mi programa en C en lugar de Python, pero al momento de ejecución el programa de C sería 500 veces más rápido. Entonces, ¿qué escenario me ofrece el mejor beneficio? Cuando una computadora costaba millones de dólares, el costo del tiempo de un programador era desdeñable. Pero hoy en día es generalmente al revés.

www.sg.com.mx

Si mi programa hipotético sólo va a ser ejecutado una vez por semana, me conviene más usar un lenguaje en donde pueda ser más productivo y donde el tiempo de ejecución es prácticamente insignificante. Por otro lado, si el programa lo van a usar miles de usuarios varias veces por día, seguramente debo reconsiderar mis prioridades.

Existen también ocasiones cuando hay factores externos al programa mismo que constituyen cuellos de botella que difícilmente se pueden eliminar con la elección del lenguaje de programación a usar. Por ejemplo, el desempeño de una aplicación Web puede estar sujeto al ancho de banda de los clientes, el tiempo de respuesta del manejador de base de datos o los servicios Web que se utilizan, etcétera. Si estos factores corresponden a la mayor parte del tiempo de ejecución de la aplicación, y a menudo así ocurre, entonces el beneficio de usar un lenguaje más rápido es prácticamente imperceptible.

Otra desventaja que algunas personas han señalado con los lenguajes dinámicos es el relativamente limitado soporte que existe para ellos en las herramientas de desarrollo, particularmente los IDEs. Esto se debe a que la mayoría de los lenguajes dinámicos no usan declaraciones explícitas de tipos, y esto complica significativamente cosas como la facilidad de autocompletar código y la refactorización.

Muchos de los lenguajes dinámicos son considerados también como lenguajes de script, o guiones. Un lenguaje de script sirve como pegamento para combinar diversos componentes, los cuales pueden ser otros programas, utilerías

del sistema operativo, o elementos de una interfaz gráfica de usuario. El término script hace alusión a los guiones que su usan en el cine o teatro. En el pasado, los lenguajes de script eran llamados batch languages (lenguajes de lotes) o job control languages (lenguajes de control de trabajos), y probablemente los ejemplos más representativos de éstos eran JCL en los equipos mainframe, los shell scripts de Unix, y los archivos .BAT de DOS. Hoy en día,este tipo de lenguajes se usan extensivamente para realizar tareas de mantenimiento de un sistema, facilitar la adecuación de la funcionalidad de alguna aplicación, enriquecer la interacción de usuario desde un browser, o simplificar la programación de páginas con contenido dinámico generadas por un servidor de web.

~:Programación paralela :~ La comercialización masiva de los primeros chips con múltiples núcleos (multi-core) en el año 2005 dio lugar a lo que se conoce como el fin del almuerzo gratis. En el pasado no muy lejano, un desarrollador podía escribir un programa sin preocuparse mucho sobre su desempeño, pues sabía que en relativamente poco tiempo el nuevo hardware correría su programa, sin modificación alguna, de manera más rápida (por eso el término almuerzo gratis). Sin embargo, las velocidades de los microprocesadores ya no se han estado incrementado como estábamos acostumbrados. La Ley de Moore establece que el número de transistores que se pueden retacar en un solo chip se duplica aproximadamente cada 18 meses. Esto típicamente se traducía en CPUs corriendo a más megahertz cada año. Sin embargo,

MAY-JUL 2008

31

este aumento en velocidad de reloj ya no es sostenible por cuestiones de calentamiento y consumo de energía.

Esto no quiere decir que la Ley de Moore ya no se cumpla, pero ahora lo que están haciendo los fabricantes de microprocesadores es usar esos transistores adicionales para añadir más núcleos a los CPUs. Un núcleo es básicamente una unidad de procesamiento, que incluye registros, unidades de ejecución y memoria caché. Hoy en día, muchos servidores, equipos de escritorio y de cómputo portátil cuentan con CPUs con 2, 4 o más núcleos. Incluso empresas como Intel, IBM y Sun Microsystems ya están hablando de procesadores many-core, con decenas o centenas de núcleos para los años venideros.

Ahora bien, hay un problema muy grande: un programa no se beneficia del nuevo nivel de paralelismo inherente en los sistemas multi-core, a no ser que haya sido diseñado explícitamente para ello. Lamentablemente, la mayoría de los programadores no saben cómo escribir programas paralelos. Esto se debe probablemente a dos causas: 1) esta es una habilidad que sólo habían requerido la gente de nichos muy específicos que utilizan supercomputadoras, grids y clusters; 2) escribir programas paralelos correctos es considerablemente más difícil que escribir programas secuenciales, al menos usando la mayoría de las herramientas disponibles en la actualidad.

Desde hace un par de décadas han existido dos modelos de programación concurrente: * Hilos con estado compartido. Se tiene una región de memoria compartida por dos o más hilos de ejecución.

Para evitar que dos hilos entren en una condición de carrera (los hilos intentan modificar el mismo contenido de memoria al mismo tiempo) se debe usar algún mecanismo de candados para garantizar una exclusión mutua.

Los candados pueden ser semáforos, monitores, etcétera.

Sin embargo, el uso de candados conlleva a otro tipo de problemas potenciales como son los candados mortales (deadlocks) y la inanición. * Paso de mensajes. Los procesos se comunican entre sí a través del envío y recepción de mensajes asíncronos.

No hay memoria compartida entre los procesos, por lo tanto no se requieren candados.

Casi todos los lenguajes usados en la industria usan hilos con estado compartido. Debido a la complejidad inhe-

rente de este modelo, diversos lenguajes han sido extendidos con bibliotecas y/o directivas especiales que simplifican la escritura de programas paralelos. OpenMP, por ejemplo, es un API para C++ y Fortran que permite de manera relativamente sencilla paralelizar ciclos. El Task Parallel Library (TPL), disponible para C# 3.5, ofrece facilidades similares.

El paso de mensajes, por otro lado, ofrece un mayor nivel de abstracción ya que el programador no tiene que interactuar con las primitivas de bajo nivel asociadas normalmente con los hilos. El lenguaje Erlang soporta este modelo de programación y ha sido usado de manera extensiva en el dominio de las telecomunicaciones para alcanzar un alto grado de paralelismo. Un programa en Erlang que haga uso de cientos o hasta miles de procesos puede en principio tener una excelente escalabilidad en cuanto se ejecute en un sistema con un mayor número de núcleos.

~: Lenguajes multi-paradigmas :~ En los años ochenta Smalltalk era el lenguaje más representativo de la programación orientada a objetos.

Pero para la mayoría de los programadores de esa época, Smalltalk era simplemente muy diferente a lo que estaban acostumbrados. La programación orientada a objetos comenzó a tomarse en serio en la industria hasta que los lenguajes convencionales fueron modificados para soportar dicho estilo de programación. Así surgieron C++ y Object Pascal, sólo por nombrar los más populares.

Este esquema de lenguajes que soportan más de un estilo o paradigma de programación sigue siendo la norma hasta nuestros días. Ruby y Python son lenguajes dinámicos y orientados a objetos, pero también tienen elementos que les permiten ser usados como lenguajes funcionales. Erlang es un lenguaje funcional, concurrente y distribuido. El lenguaje Oz soporta programación lógica, funcional, orientada a objetos, basada en restricciones, distribuida y concurrente.

~: Plataformas de programación :~ Hoy en día, el desarrollo de software tiende a ser algo más enfocado a programar en una plataforma y no tan solo en un lenguaje. Es decir, tenemos ahora programadores y/o desarrolladores de web, de JEE y de .NET.

Ariel Ortiz Ramírez es profesor de planta del Departamento de Tecnologías de Información y Computación del Tecnológico de Monterrey, Campus Estado de

México. Desde 1988 ha estado impartiendo una gran variedad de cursos relacionados con programación en donde ha utilizado los lenguajes Basic, Pascal, C, C++, C#, Java, JavaScript, Scheme, Prolog, Python, Ruby, Erlang y diversos ensambladores. Sus principales áreas de interés son los lenguajes de programa-

ción, la educación en ciencia de la computación y el software libre. www.arielortiz.com

32

MAY-JUL MAY-JUL 2008 2008

www.sg.com.mx www.sg.com.mx

Parece que la época del programador mono-lingüista está llegando a su fin. Por ejemplo, un desarrollador de web debe conocer varios lenguajes para hacer su trabajo, incluyendo HTML, CSS, JavaScript, y algún framework para usar Ajax como JQuery o Prototype, y todo esto sólo para la programación del lado del cliente; del lado del servidor probablemente requiera saber SQL, un framework para algún lenguaje de programación en particular, y un lenguaje de plantillas para la generación de contenido dinámico. ¿Por qué se requieren tantos lenguajes para desarrollar una aplicación de este tipo? Porque cada lenguaje tiene una función particular que los otros simplemente no pueden hacer, o sí lo pueden hacer pero de manera menos conveniente.

JRuby, Jython y Groovy son lenguajes dinámicos diseñados también para simplificar y agilizar el desarrollo sobre la plataforma Java, sin perder la facilidad de operación con código de Java. Es claro ahora más que nunca que lo valioso de la tecnología Java es su plataforma (la máquina virtual y su extensa biblioteca) y no tanto el lenguaje de programación en sí. Algunos han afirmado que Java se ha convertido en el nuevo Cobol. A mi me parece mas bien que Java es el nuevo C. Así como en Unix la infraestructura básica (núcleo, utilerías, bibliotecas) está escrita en lenguaje C, y todo se une con scripts y aplicaciones escritas en lenguajes de más alto nivel (tales como Perl, Tcl o Python), así también podría ocurrir con Java y los otros lenguajes ya mencionados.

En la actualidad, las plataformas Java y .NET reflejan también la importancia de poder combinar lenguajes, y así ofrecer al desarrollador la opción de usar la mejor herramienta para el problema en cuestión. Por ejemplo, Scala es un lenguaje que corre en la plataforma Java, y que reúne lo mejor de muchos mundos. Es orientado a objetos y funcional, soporta el modelo de concurrencia por paso de mensajes. Usa un sistema de tipos estáticos pero con inferencia automática. Puede usarse como lenguaje de script e interactuar con código de Java existente.

Algo similar ocurre en la plataforma .NET. De hecho, a diferencia de la máquina virtual de Java, que fue diseñada específicamente para ese lenguaje de programación, la máquina virtual de .NET, conocida como el Common Language Infrastructure (CLI), fue diseñada desde el principio para soportar múltiples lenguajes y sus interacciones. Aunque C# es el caballito de batalla del CLI, existen decenas de lenguajes diseñados para esta plataforma. Por ejemplo, F# es un lenguaje funcional y orientado a objetos, derivado principalmente del lenguaje ML. También hay implementaciones de Python y Ruby para el CLI, llamadas respectivamente IronPython e IronRuby.

Conclusión En la actualidad hay muchas cosas interesantes ocurriendo en el área de lenguajes de programación. Después de años de estar estudiando diferentes lenguajes, me resulta claro que difícilmente encontraremos un lenguaje único y perfecto. Lo mejor que podemos hacer es sacarle el mayor provecho a lo que tenemos disponible hoy en día, y estar en la mejor disposición de aprender las nuevas herramientas que vayan apareciendo.

Sólo hay dos tipos de lenguajes de programación: los que son el objeto de las quejas de todo mundo

y los que nadie usa. / Bjarne Stroustrup, autor de C++

www.sg.com.mx www.sg.com.mx

MAY-JUL MAY-JUL 2008 2008

33

Más allá de los Objetos

C# Desde un Punto de Vista Funcional Por Miguel Ángel Morán

urante muchos años los científicos de la computación han buscado diferentes paradigmas que permitan una mejor y más efectiva comunicación entre el programador y la computadora. De hecho, los principios que rigen la programación actual fueron diseñados aún antes de que existieran físicamente las computadoras.

Por ejemplo, en la década de los treinta Alan Turing formalizó matemáticamente el concepto de algoritmo, que es la base de la resolución de problemas mediante máquinas y antecedente directo de la programación imperativa, y Alonzo Church presentó el cálculo lambda que proporciona el fundamento de la programación funcional.

El paradigma de la programación orientada a objetos (POO) básicamente consiste en que primero se describe el mundo (dominio) mediante la definición de ciertos tipos (clases), y luego se resuelve el problema deseado mediante la interacción entre los objetos (que son instancias de las clases). Es evidente que la programación POO se ha convertido en un estándar de facto para muchas de las plataformas de programación comerciales y esto no es casualidad, debido a su marcada analogía con el mundo real. Aun así, es necesario que nos hagamos la pregunta:

Haciendo una analogía con los lenguajes humanos, sabemos que la lengua española tiene fuertes similitudes con aquellas de origen común al latín. Algo similar sucede con los lenguajes de programación, ya que 2 lenguajes provenientes de la misma familia comparten muchas características en común, mientras que lenguajes de distintas familias funcionan de forma muy diferente y por lo tanto es más difícil poder dominar ambos.

A pesar de esta gran diferencia, en los últimos años los lenguajes de una familia están incorporando capacidades de otra, generando lo que podríamos llamar lenguajes híbridos (o multi-paradigma). Tal es el caso de C#, el cual conforme su evolución, ha ido incorporando capacidades de lenguajes funcionales.

… ¿y qué hay más allá de los objetos?

Entonces, para contestar la pregunta original, al parecer lo que está más allá de los objetos es la programación multiparadigma, especialmente la incorporación de capacidades funcionales en lenguajes orientados a objetos.

La figura 1, muestra una clasificación de lenguajes de programación, de acuerdo a su paradigma.

¿Y a qué se debe tanto interés? El motivo principal sin duda es aumentar la productividad del

Figura 1. Clasificación de los lenguajes.

programador dotándolo de diferentes armas para resolver problemas de una manera más efectiva. Estos conceptos existen desde hace muchos años, pero actualmente toman gran importancia al reencarnar en plataformas de programación comerciales.

~: Programación funcional :~ Los lenguajes funcionales son aquellos en los que en lugar de proporcionar instrucciones imperativas (diciendo como se deben hacer las cosas), se especifican condiciones y criterios que deben cumplirse para lograr un objetivo (otros ejemplos de lenguajes declarativos son HTML, XML, ASP.NET, SQL etccétera).

La programación funcional, propone que los programas deben componerse exclusivamente de funciones, y este concepto va más allá de la idea general que tenemos de un subconjunto de código (procedimiento o método.) Al referirnos de que todo es una función debemos entender que los lenguajes funcionales puros eliminan las asignaciones, y todos los valores y resultados se encuentran en función de otros. Es por esta razón que cuando a una variable se le asigna un valor, éste jamás se modifica, de forma que se pueda asegurar la llamada transparencia referencial.

Uno de los lenguajes funcionales más conocidos es Haskell, y muchos de sus elementos han sido retomados en C#. ~: Expresiones lambda :~ En la programación funcional se hace uso extensivo de las expresiones lambda, que no son más que funciones declaradas anónimamente (es decir sin un nombre explícito) y cuyo uso disminuye la verbosidad del lenguaje (menos líneas de código) y la potencia del mismo, al po-

Miguel Ángel Morán B. es Microsoft Most Valuable Professional (MVP) en C# y Microsoft Certified Trainer (MCT). Es Licenciado en Informática por la UNITEC y cuenta con 11 años

de experiencia desarrollando profesionalmente. Es socio fundador de DevWorx, empresa de alta innovación tecnológica, y participa en la comunidad DevelopersDotNet.com donde frecuente-

mente escribe y organiza eventos sobre tecnología. miguel.moran@devworx.com.mx

34 28

MAY-JUL 2008

www.sg.com.mx www.sg.com.mx

der incrustar en cualquier parte del código una función que resuelva determinada tarea.

Ejemplo en Haskell (\pintNum -> pintNum * pintNum)

Haskell

:t “Hola”

Resultado:

“Hola” :: String

En ambos casos si invocamos la función nos regresará el cuadrado del parámetro invocado.

En el caso de Haskell, la indicación de la expresión lambda se obtiene mediante la partícula \ mientras que en C# se indica mediante => que se puede leer como va a. ~: Funciones de orden superior (FOS) :~ Las funciones de orden superior básicamente se refieren a aquellas funciones que reciben como argumentos otras funciones, o bien regresan otra función como resultado.

En el siguiente listado podemos ver la definición de una FOS, donde la función ConvertirMoneda regresará una función (específicamente un delegado) que a su vez será invocada para calcular el tipo de cambio. public static Func<int,int> ConvertirMoneda(string pstrMoneda) { return (int pintCantidad) => { return pstrMoneda == “EURO” ? pintCantidad * 15 : pintCantidad * 10;} };

Invocación

var lobjConvertidor = ConvertirMoneda(“PESO”); Console.WriteLine(lobjConvertidor(20)); // Regresará 200 var lobjConvertidor = ConvertirMoneda(“EURO”); Console.WriteLine(lobjConvertidor(20)); //Regresará 300

~:Inferencia de tipos :~ Como pudimos ver, en el listado anterior se hace uso de la palabra clave var, esta palabra reservada no implica late binding sino inferencia. El compilador asigna automáticamente el tipo de dato correcto al resultado de una función sin necesidad de que se especifique explícitamente.

www.sg.com.mx

var lobjMsg= “Hola”; lobjMsg.GetType().ToString();

Resultado:

System.String

Ejemplo en C# Func<int,int> lintResultado = (pintNum) => { return pintNum * pintNum; };

C#

Los lenguajes fuertemente tipificados son importantes por la seguridad al disminuir errores en tiempo de ejecución. Así, la inferencia de tipos conserva la fuerte tipificación del dato pero aumenta la flexibilidad y capacidad para generar polimorfismo. ~:Recursión como manejador de control de flujo :~ En los lenguajes imperativos tenemos instrucciones como if, for, while para manejar el control de flujo.

En la programación funcional el control de flujo se da mediante el uso exhaustivo de listas, tuplas, etcétera y el manejo efectivo de la recursividad.

El siguiente código Haskell devuelve la sumatoria de los números del 1 al 100. sum[1..100]

En C# podríamos implementar nuestro clásico arreglo y/o contador, además de un ciclo de repetición para lograr lo mismo. Sin embargo, usando las nuevas características del lenguaje podemos hacer esto: Enumerable.Range(1, 100).Sum();

En ambos casos obtengo 5050. ~: Limitaciones de C# como lenguaje funcional :~ Existen otros conceptos de la programación funcional que no se cumplen al pie de la letra en C#, dado que es un lenguaje híbrido. Sin embargo, hay soluciones funcionales por si se desea seguir estrictamente un paradigma. Un ejemplo de esto es el de la evaluación perezosa. Ésta se refiere a la capacidad de un lenguaje de programación en la cual las expresiones de determinada sentencia no se evalúan hasta que es exclusivamente necesario.

En el caso de la programación funcional esto es útil toda vez de que es posible asignar listas infinitas sin provocar un desbordamiento. Con C#

podemos usar evaluación perezosa mediante el uso de listas, sin embargo el CLR por naturaleza evalúa las expresiones al momento de asignarlas.

Por otro lado, tenemos el caso de la transparencia referencial, la cual se refiere a que una función dados determinados parámetros (firmas) siempre regresará el mismo resultado. Esto no se puede asegurar en C# toda vez que tenemos operadores de asignación y manejo de estado, por lo que un estado específico (en una variable o propiedad) podría modificar el resultado de una función aun con la misma firma.

Conclusión

Los paradigmas alternos de programación representan una oportunidad para acercarnos a formas de trabajo que aumentarán nuestra productividad. La tendencia va hacia los lenguajes híbridos que incorporen capacidades de distintos paradigmas. El objetivo debe ser lograr patrones y prácticas que permitan un mejor software y un menor tiempo de desarrollo mediante el uso ordenado de las herramientas y tecnologías.

Por ejemplo, en el caso de .NET, estas nuevas características del lenguaje son el mecanismo habilitador de la tecnología LINQ. Es necesario aprender a detalle lo que existe detrás de esta implementación para poder explotar la plataforma de la mejor manera.

Para los maestros y estudiantes de las carreras de sistemas, la oportunidad que nos brindan estos lenguajes es doble ya que es posible cumplir con los objetivos académicos y además al aprender estas técnicas también es posible salir preparado con un lenguaje extensivamente utilizado en el ámbito laboral.

Referencias

[msdn2.microsoft.com/es-es/library/bb943915.aspx] [haskell.org] [squad.devworx.com.mx/blogs/miguel]

MAY-JUL 2008

35 29

// COLUMNA

/*PRUEBA DE SOFTWARE*/

La Calidad del Proceso de Prueba de Software Los Modelos de Calidad especializados en Prueba de Software

Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es cofundador. Fue profesor-investigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de dicha disciplina. Fue co-fundador del Capítulo Jalisco de la AMCIS.

S

e puede percibir que en los últimos años la industria de software mexicana ha estado invirtiendo en el trabajo de mejora de procesos, en la mayoría de los casos con los modelos de calidad CMMI y MoProSoft.

Podemos ver dos motivaciones importantes para esa inversión: por un lado mejorar las capacidades de la empresa, bajo el supuesto implícito de que la calidad del proceso determina en buena medida la calidad del software que se construye con ese proceso (supuesto un tanto débil, como lo comentamos en otro número); y por otro, tener más credenciales que faciliten el vender más.

De manera general, los modelos de calidad (MC) deben proporcionar un marco de referencia para: a) Medir las capacidades de una organización y b) Diseñar y llevar a cabo mejoras de esas capacidades.

Los MC deben mostrar al menos las siguientes características: • Completitud: el MC incluye todos los aspectos relevantes al medir capacidades.

• Consistencia: el MC no contiene contradicciones internas.

• Objetividad: el MC tiene la precisión necesaria para que cuando lo apliquen dos personas diferentes para medir las capacidades de una misma organización en un mismo periodo, los resultados sean prácticamente los mismos.

36

MAY-JUL 2008

Figura 1. Estructura de los modelos de calidad.

Además, los MC debieran mostrar validez estadística y proveer una manera rápida para obtener una evaluación inicial de capacidades.

Una estructura común de los MC (ver figura 1) es la de una matriz que considera por una parte áreas a medir y por otra niveles de madurez para cada una, lo que en conjunto debiera facilitar la mejora de capacidades con saltos manejables (retadores, pero alcanzables en un tiempo y con una inversión razonables).

Aquí haremos un breve análisis de varios MC especializados en prueba de software que han mostrado su utilidad en varios pro-

yectos de mejora de capacidades en los que hemos participado en los últimos años.

Algunos modelos de calidad especializados en prueba Los MC que hemos utilizado en proyectos de mejora de capacidades de prueba (incluidas las nuestras) son: Test Process Improvement (TPI), de la empresa holandesa Polteq; Testing Maturity Model (TMM), del Illinois Institute of Technology (EEUU); y Test Aptitude Model (TAM), de la empresa mexicana e-Quallity.

La tabla siguiente muestra algunas características relevantes de cada uno de ellos:

www.sg.com.mx

“Los MC deben mostrar validez estadística y proveer una manera rápida para obtener una evaluación inicial de capacidades”.

TMM

TPI

TAM

Se ha constituido como un estándar internacional de facto

Utilizado en la industria de prueba mexicana

Muy orientado a entidades de prueba dentro de organizaciones desarrolladoras de software

Considera la entidad de pruebas, independientemente de su inclusión o no dentro de una organización desarrolladora

Como TPI, pero haciendo énfasis en los primeros pasos de mejora (usualmente los más difíciles)

Mediano: 13 metas, 5 niveles

Pesado: 20 áreas, 4 niveles

Ligero: 13 áreas, 3 niveles

Difícil de localizar proveedor

Inversión considerable en euros

Inversión razonable en pesos

Calificación de la organización evaluada en términos del nivel en cada meta

Calificación de la organización evaluada en términos de (sub) nivel por cada área

Calificación entre 1 y 100 representando la cobertura en cada área y la global

Busca subsanar carencias de CMM en el área de pruebas

En la siguiente tabla mostramos la relación aproximada entre las distintas calificaciones que se emiten con estos MC. Cabe resaltar que no se trata de una equivalencia estricta, pero brinda una idea aproximada.

» Luis Vinicio León Carrillo / Elena Ruelas Minor

Conclusión Aunque nosotros vemos con claridad que en el desarrollo de software la relación entre la calidad del proceso y la calidad de producto no es tan fuerte como en la manufactura, también lo estamos de que el trabajo en la mejora de los procesos de prueba es una labor que no debe dejar de hacerse.

En nuestra experiencia, hemos visto que resulta útil iniciar con un modelo ligero como el TAM, que con costos moderados permite mejorar significativamente las capacidades y luego, si lo que se busca es una certificación internacional, brincar a un modelo como TPI, aprovechando los ahorros económicos obtenidos de la mejora anterior.

Referencias: Elena Ruelas Minor es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. En su trayectoria ha actuado como tester senior y administradora de proyectos de prueba; como consultora, ha aplicado el modelo de calidad TAM, y fue la champion del proyecto de certificación en los modelos de

[ tmmifoundation.org ] [ e-quallity.net ] [ polteq.com ]

calidad TPI y TMM de e-Quallity.

www.sg.com.mx

MAY-JUL 2008

37

// PRÁCTICAS

/*ARQUITECTURA*/

Más Allá del Manual de Usuario Parte 1. Documentando la Arquitectura de Software Por Omar Gómez

Principios básicos En la actualidad, uno de los temas candentes del que se habla dentro de la comunidad de desarrollo de software es el referente a las arquitecturas. Una arquitectura de software describe cómo un sistema se desglosa en componentes, cómo son interconectados y la manera en que se comunican e interactúan entre sí. Tras la definición anterior se pueden formular un par de preguntas: ¿en qué grado cumplimos con ésta definición durante el rol que desempeñamos como arquitecto o diseñador?, o mejor dicho: ¿Qué tan bien documentamos una arquitectura de software?

La finalidad de este artículo es contar con un punto de referencia sobre esta práctica, abordando dos de los enfoques más relevantes que han sido usados para realizar la tarea; también se describe su tendencia actual, y por último se menciona una serie de consideraciones que se deben tener en cuenta al momento de documentar.

Comúnmente una arquitectura de software se documenta a través de un conjunto de vistas, en donde cada una de ellas representa un aspecto o comportamiento particular del sistema. Dos de los artículos de mayor relevancia que abordan el tema del uso de vistas son los de Philippe B. Kruchten y el de Robert L. Nord y compañía. El primero es el más conocido porque la propuesta es parte fundamental de la metodología del Proceso Unificado, que en la actualidad es una de las metodologías que goza de cierto grado de popularidad.

Kruchten propone el uso de cinco vistas: • Vista lógica. Apoya principalmente los requisitos funcionales, es decir, lo que el sistema debe brindar en términos de servicios a sus usuarios, desglozado en una serie de abstracciones primarias, tomadas principalmente del dominio del problema en la forma de objetos o clases de objetos. Aquí se aplican los principios de abstracción, encapsulación y herencia. Esta descomposición no sólo enfatiza el análisis funcional, también sirve para identificar mecanismos y elementos de diseño comunes a diversas partes del sistema.

• Vista de procesos. Trata los aspectos de concurrencia y distribución, integridad del sistema, y tolerancia a fallas. También especifica en cuál hilo de control se ejecuta efectivamente una operación de una clase identificada en la vista lógica. Esta vista puede ser descrita como un conjunto de redes lógicas de procesos que son ejecutados de forma independiente, y distribuidos a lo largo de varios recursos de hardware conectados mediante un bus o a una red de datos.

• Vista de desarrollo. Se centra en la organización real de los módulos de software en el ambiente de desarrollo. El software se empaqueta en partes pequeñas que pueden ser bibliotecas o subsistemas

38

MAY-JUL 2008

creados por un desarrollador o un grupo de ellos, y se organizan en una jerarquía de capas, cada una brinda una interfaz estrecha y bien definida hacia las capas superiores.

• Vista física. Se toma en cuenta los requisitos no funcionales del sistema tales como: disponibilidad, confiabilidad y desempeño, entre otras más; y es ejecutado sobre varios nodos de procesamiento (hardware). Estos nodos son relacionados con los elementos identificados de las vistas anteriores. Aquí se especifican varias configuraciones físicas, por ejemplo: una para el desarrollo y las pruebas, o para el despliegue del sistema en plataformas distintas.

Kruchten define una última vista en la que propone el uso de un pequeño subconjunto de escenarios que son instancias de casos de uso. Su función es relacionar las cuatro vistas entre sí, de esta forma se cuenta con una perspectiva general del sistema, que ayuda a descubrir nuevos elementos o validar la arquitectura.

Por su parte, Nord y compañía realizaron un estudio para conocer en una arquitectura las estructuras que son de mayor importancia, y el uso de éstas. El estudio se efectuó sobre varios sistemas de software de ámbito industrial. Tras el estudio realizado propusieron cuatro categorías o vistas para agrupar las estructuras principales de una arquitectura, estas son: • Vista conceptual. Se describe el sistema en términos de sus elementos principales de diseño y las relaciones entre ellos dentro de un dominio determinado. Esta vista es independiente de las decisiones de implementación y enfatiza en los protocolos de interacción entre los elementos de diseño.

• Vista de módulos. El sistema se descompone lógicamente en subsistemas, módulos, y unidades abstractas. Cada capa representa las distintas interfaces de comunicación permitidas entre los módulos.

• Vista de ejecución. Se describe la estructura dinámica del sistema en términos de sus elementos en tiempo de ejecución. Por ejemplo, se modela las tareas operativas del sistema, procesos, mecanismos de comunicación y asignación de recursos. Algunos de los aspectos que se consideran en esta vista son: el desempeño y el entorno de ejecución.

• Vista de código. Se organiza el código fuente en directorios, archivos y bibliotecas. Algunos de los aspectos que se incluyen son: los lenguajes de programación a utilizar, herramientas de desarrollo, la administración de la configuración y la estructura y organización del proyecto.

www.sg.com.mx

“Comúnmente una arquitectura de software se documenta a través de un conjunto de vistas”.

Es común que en la actualidad se utilice alguno de los 2 enfoques antes descritos. Sin embargo, la forma de documentar una arquitectura ha evolucionado significativamente. Ahora la tendencia sobre esta práctica se centra en dos aspectos principales: • Los arquitectos deben documentar las vistas que sean de mayor utilidad y no ajustarse a un número fijo como lo muestran las propuestas.

• Documentar la arquitectura tomando en cuenta los intereses y necesidades de las personas involucradas en el proyecto, estos intereses se traducen como las cualidades que el sistema resultante debe poseer.

Esta nueva tendencia está respaldada por dos grandes institutos, uno de ellos es el Instituto de Ingeniería del Software (SEI) y el otro es el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) elaborado por el comité de estándares del IEEE Software. A continuación se describen los dos enfoques.

El SEI en su propuesta define tres categorías denominadas tipos de vista, en las que prácticamente cualquier vista, dependiendo del tipo de información que contenga, puede pertenecer a una de estas categorías. Los tipos de vista pueden ser: • Vista de módulo. Describe cómo el sistema es estructurado en un conjunto de unidades de código.

• Vista de conectores y componentes. Describe cómo el sistema es estructurado en un conjunto de elementos que están en tiempo de ejecución así como su interacción.

• Vista de asignación. Describe la relación entre las unidades de software y los elementos del entorno como hardware, sistemas de archivos o la organización de los equipos de desarrollo de software.

Es importante señalar que cada tipo de vista viene acompañado de un conjunto predefinido de estilos, de así los arquitectos pueden hacer uso de éstos para documentarlas. De acuerdo a Shaw y Garlan, un estilo arquitectónico es una descripción de los elementos, conectores, topología, y un conjunto de restricciones sobre la interacción de los elementos. El uso de estilos promueve la satisfacción de los intereses definidos por parte del personal involucrado en el proyecto.

El SEI recomienda contar con una guía de estilos que contenga entre otros aspectos: la descripción relevante del estilo, elementos, relaciones, propiedades, situaciones en las que no es recomendable aplicarlo, circunstancias en las que se recomienda usarlo, y posibles

www.sg.com.mx

enfoques analíticos que el arquitecto puede utilizar. Para la elaboración de la guía de estilos se puede tomar como referencia el informe técnico realizado por Mark Klein y Rick Kazman, en el que los autores proponen un marco de trabajo para llevar acabo un razonamiento cualitativo o cuantitativo de los atributos de calidad presentes en un estilo arquitectónico, a través de una serie de ejemplos que describen el uso del marco de trabajo con los atributos de calidad: desempeño, facilidad de modificación y disponibilidad.

La documentación de las vistas se realiza a través de lo que se denomina paquetes de vista. Los paquetes de vista contienen un número reducido de elementos, logrando así una mejor comprensión ya que sólo se muestra un fragmento particular del sistema. De esta manera, una vista se descompone en uno o más paquetes de vista.

Para seleccionar las vistas a documentar, se sigue un procedimiento basado con respecto a las estructuras que se encuentran presentes de manera inherente en el sistema a construir, y en los intereses primarios del personal involucrado. El procedimiento consta de los siguientes pasos: 1) Elaborar una lista de vistas candidatas. En este paso se elabora una tabla con la siguiente información: en las columnas se enumera el conjunto de posibles vistas a documentar, mientras que en las filas se hace con el personal involucrado. En cada una de las celdas se especifica el grado de información que requiere cada una de los participantes en el proyecto, los valores posibles para las celdas pueden ser: requerido a detalle, de manera general o ninguno. Este paso concluye una vez que se han seleccionado las vistas de mayor interés.

2) Combinar las vistas. Posiblemente las vistas elegidas en el paso anterior sean imprácticas de documentar debido al número de vistas seleccionadas, en este paso se reduce la lista de vistas de una manera que pueda ser manejable por el arquitecto. La reducción se lleva acabo combinando varias vistas, de este modo una vista combinada muestra la información nativa de dos o más vistas separadas.

3) Priorizar las vistas. Aquí, el arquitecto debe tener el conjunto mínimo de vistas que satisfacen los intereses del personal involucrado.

Después, en conjunto con el administrador del proyecto se procede a priorizar cada una de las vistas resultantes.

Una vez que las vistas se han seleccionado y priorizado, se inicia su documentación. El SEI cuenta con una plantilla que se puede utilizar de referencia para dicho propósito. De acuerdo al SEI, la documentación de una arquitectura debe contener los siguientes apartados:

MAY-JUL 2008

39

// PRÁCTICAS

/*ARQUITECTURA*/

Figura 1. Relación de conceptos de la propuesta “vistas y más allá de éstas” del SEI.

• Presentación primaria. Muestra los elementos y sus relaciones entre sí, usualmente se representa de manera gráfica.

• Catálogo de elementos. Contiene los detalles de éstos, sus propiedades e interfaces.

• Diagrama de contexto. Muestra la relación entre el sistema o porción de éste y su entorno.

• Guía de variabilidad. Muestra los posibles puntos de variación en caso de que las vistas sean modificadas.

• Antecedentes de la arquitectura. Explica la justificación de la arquitectura así como los supuestos, y los resultados de los análisis realizados.

• Otra información. En esta sección se incluyen prácticas y políticas de la organización.

• Paquetes de vista relacionados. Básicamente, en esta sección se definen las relaciones entre los distintos paquetes de vista.

Para concluir con la propuesta del SEI, en la figura 1 se muestra los principales conceptos de este enfoque.

En el siguiente número continuaremos con la propuesta del IEEE, así como las propuestas a considerar en la documentación de arquitecturas.

Referencias: [ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE Software, Los Alamitos, CA, USA. Vol. 12, No. 6, págs. 42-50. IEEE Computer Society Press. 1995. ] [ Dilip Soni; Robert L. Nord & Christine Hofmeister. “Software Architecture in Industrial Applications”. ICSE ‘95: Proceedings of the 17th international conference on Software Engineering, New York, NY, USA. págs. 196-207. ACM. 1995. ] [ Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Robert Nord & Judith Stafford. “Documenting Software Architectures: Views and Beyond”. Addison Wesley Professional. 2002. ] [ Software Engineering Institute, SEI. “Views and Beyond Architecture Documentation Template”.Template 05 febrero 2006. ] [ sei.cmu.edu/architecture/rcgh_doc.html ] [ Omar Gómez. “Evaluando la Arquitectura de Software, Métodos de Evaluación”. Revista Software Gurú. Año 03 No. 02. 2007. ]

Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software, en el Centro de Investigación en Matemáticas (CIMAT). Actualmente se encuentra trabajando como estudiante de postgrado en el área de Ingeniería del Software Empírica en la Facultad de Informática de la Universidad Politécnica de Madrid. Es miembro del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org

40

MAY-JUL 2008

www.sg.com.mx

www.sg.com.mx

MAY-JUL 2008

39

// PRÁCTICAS

/*PROGRAMACIÓN*/

Aprendiendo Ruby y Rails Parte 3. El Framework Rails Por Carlos Ortega

En esta ocasión se hablará del framework Ruby on Rails. Recomendamos al lector revisar la siguiente referencia para que realice la instalación adecuada a su plataforma favorita: rubyonrails.org.

También, es importante señalar que se requiere de un RDBMS instalado, en este caso se utilizó MySQL, por lo tanto, la sintaxis referente a la Base de Datos es propia de esta última. Los comandos que se indican toman como base el ambiente Windows; para Linux se sugiere observar el cambio de sintaxis en las líneas de comandos correspondientes y el web server a utilizar es WEBrick.

intercalado con HTML, de tal manera que aun cuando las vistas contienen código híbrido (HTML y Ruby), ERb toma dicha combinación, interpreta los resultados y valores del lenguaje generando al final sólo HTML, así, éste puede ser reenviado por el web server para su interpretación limpia dentro del browser.

Arquitectura de Rails

1) Creación del modelo de datos. En esta etapa se generan las bases de datos de desarrollo, prueba y producción, adicionalmente se crean los objetos de negocio que representan al dominio que estemos tratando.

Como ya se mencionó, Rails es un framework para desarrollo web con base en el patrón arquitectónico MVC 2, es decir, la capa del frente (presentación) es totalmente independiente de la capa de lógica de negocio, la cual es representada por un controlador que manipula al modelo (capa de datos). Los elementos arquitectónicos más importantes de una aplicación Rails se presentan en el siguiente esquema:

Arrancando con Rails El procedimiento que se describire a continuación es el proceso simple recomendado para la creación de cualquier aplicación basada en Rails:

2) Creación de la lógica de negocio. Aquí se desarrolla toda la lógica de negocio de la aplicación.

3) Creación de la presentación. En esta etapa se generarán todos los elementos que permitirán interactuar al usuario con el sistema.

Es posible que uno pueda preguntarse que, no necesariamente todos los actores de un sistema son humanos. En este caso Ruby y Rails proporcionan una gran variedad de recursos y librerías que permiten interactuar con otros elementos externos, tales como el correo electrónico o el uso de web services. La forma de cómo se puede interactuar con este tipo de elementos queda fuera del alcance de este artículo.

La arquitectura funciona de la siguiente manera: se genera una petición desde el navegador, el web server al recibirla la redirecciona a un recurso específico a traves de la librería CGI, posteriormente, éste manda la petición a un controlador que vive dentro de la capa de ActionPack; el controlador por su parte no conoce a la capa de presentación, definida por las vistas/Action View, sin embargo puede manipular y administrar los objetos de negocio, los cuales a su vez son representados por objetos que derivan de la clase Active Record, que es la capa que une los datos contenidos en el RDBMS. Una vez que dichos objetos de negocio son manipulados por el controlador, pueden ser compartidos de manera automática con las vistas. ERb es un paquete que permite la manipulación de código Ruby

42

MAY-JUL 2008

Asumiendo que Rails y el manejador relacional se han instalado correctamente, iniciaremos la generación del modelo creando las bases de datos correpondientes, siguiendo las convenciones que los diseñadores de Rails pensaron al contemplar un ciclo de vida de desarrollo completo (desarrollo, pruebas, distribución). Crearemos tres bases de datos con características y nombres similares que permitirán realizar cada una de estas fases.

Pasos 1. Definimos un directorio de desarrollo llamado trabajo, dentro de él creamos la aplicación base en Rails (en nuestro caso la denominaremos railsass): >cd trabajo >rails railsass

Al ejecutar este comando se crea la infraestructura base de la aplicación, que es la estándar para cualquier aplicación formada de la siguiente manera: www.sg.com.mx

“ERb es un paquete que permite la manipulación de código Ruby intercalado con HTML”.

2. Se crean en MySQL 3 bases de datos: railsass_development, railsass_test y railsass_deployment

3 - Una vez creadas las bases, se genera el modelo en Rails. En una sesión de consola Ruby, nos cambiamos al directorio recien creado railsass e invocamos el generador de modelos estándar utilizando como nombre del modelo Usuario: path/trabajo>cd railsass path/trabajo/railsass>ruby script/generate model Usuario

www.sg.com.mx

MAY-JUL 2008

// PRÁCTICAS

/*PROGRAMACIÓN*/

Una vez creado el modelo es necesario realizar su integración con la infrastructura de la base de datos. Para ello, Rails proporciona un mecanismo que permite definir las conexiones para dar persitencia a los objetos del modelo. Este mecanismo es un archivo de tipo YAML denominado database.yml, que reside en el subdirectorio config dentro del directorio railsass.

4. Editamos el archivo database.yml e incorporamos los parámetros del nombre host, los nombres de las bases de datos, los usuarios y los passwords de acceso. Para nuestro caso emplearemos los siguientes: development: adapter: mysql database: railsass_development username: root password: host: localhost test: adapter: mysql database: railsass_test username: root password: host: localhost production: adapter: mysql database: railsass_production username: root password: host: localhost

5. El acoplamiento entre los objetos de negocio y la base de datos se realiza a través de una migración, la cual se realiza por medio de un archivo con código Ruby (extensión .rb) que se encuentra localizado dentro del subdirectorio db/migrate. Típicamente el nombre de este archivo sigue la convención: <numeroVersión>_create_<nombreEnPluralDelModelo>.rb

Así entonces el nombre del archivo de migración es 001_create_usuarios.rb Como este archivo contiene la sintaxis de Ruby que describe la estructura de la tabla asociada al modelo en la base de datos, permite manipular código SQL a través de Ruby, resultando más cómodo, sencillo y elegante. Adicionalmente una migración permite modificar la estructura de las tablas conforme evolucione el desarrollo, de ahí el número de versión como parte del nombre del archivo.

Al inspeccionar 001_create_usuarios.rb podemos corroborar que contiene la definición de una clase que sigue la siguiente convención: class Create<NombreEnPluralDelModelo>

Normalmente esta clase posee 2 metodos: self.up y self.down. El objetivo de self.up es realizar las acciones correspondientes al ejecutar la migración. Por su parte self.down es un método pensado para realizar ajustes de reversa, es decir, deshacer acciones sobre la tabla en cuestión, en caso de tener que regresar a esa versión en particular.

Editamos 001_create_usuarios.rb asegurando que tenga las siguientes definiciones: class CreateUsuarios < ActiveRecord::Migration def self.up create_table :usuarios do |t| t.column :nombre, :string t.column :apellido, :string t.column :tipo, :integer t.column :permisos, :string end end

def self.down drop_table :usuarios end end

6. Ejecutamos la migración a través del manejador de tareas rake: cd path/trabajo/railsass path/trabajo/railsass>rake db:migrate

Como parte de la comprobación del correcto funcionamiento de la migración, generaremos un objeto de negocio de tipo Usuario, calificando sus atributos, y guardando todo el objeto en la base de datos.

Esto lo realizaremos a través de una consola interactiva irb Ruby y el propio manejador MySQL. 7. Arranquemos la consola interactiva irb Ruby para cargar el ambiente y la base de datos en memoria: path/trabajo/railsass>ruby script/console

8. Creamos un objeto Usuario y cambiamos el valor a sus atributos (a continuación la sesión correspondiente).

Carlos Ortega es consultor en metodologías y prácticas ágiles (XP, TDD, Refactoring, Pair Programming), cuenta con certificaciones en RUP, OOAD, UML, etcétera. Es Certified ATAM Evaluator y Certified Professional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como Banco de México, Elektra, Banco Azteca, Fandelli, Oracle, IMSS, Heinson, Accenture, EDS. Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Crystal).

44

MAY-JUL 2008

www.sg.com.mx

“A través de Ruby se puede manipular código SQL resultando más cómodo, sencillo y elegante”. >> tipo_usuario = 0 => 0 >>tipo_admin = 1 => 1 >>tipo_auditor = 2 => 2 >>unUsuario = Usuario.new => #<Usuario:0x4932e94 @attributes={“permisos”=>nil, “apellido”=>nil, “nombre”=> nil, “tipo”=>nil}, @new_record=true> >>unUsuario.nombre = “David” => “David” >>unUsuario.apellido = “HeineMeier” => “HeineMeier” >>unUsuario.tipo = tipo_admin => 1 >>unUsuario.permisos = “rwx rwx rwx” => “rwx rwx rwx” >>unUsuario.save =>true

9. Podemos corroborar a través de MySQL que después del último comando, el objeto unUsuario ha quedado registrado en la base.

www.sg.com.mx

En este artículo exponemos brevemente la arquitectura general de Rails, además de explicar cómo generar el modelo de negocios aplicando el concepto de migraciones. En la próxima de nuestras entregas terminaremos el tutorial con el uso de controladores y vistas.

Referencias [ Thomas David, Fowler Chad, Hunt Andy. “Programming Ruby” 2nd Edition. The Pragmatic Bookshelf. 2005. ] [ Thomas David, Heinemeier Hanson David, et al. “Agile Web Development with Rails”. 2nd Edition. The Pragmatic Bookshelf, 2006. ] [ Black, David A. “Ruby for Rails”. Manning Publications Co. 2006 ] [ ruby-lang.org/en ] [ rubyonrails.org ] [ mysql.com ]

MAY-JUL 2008

// PRÁCTICAS

/*PROcesos*/

CMMI-SVC®

¿Qué hay de Nuevo Bajo el Sol de los Servicios?

Por Elizabeth Almeraz

La industria de servicios abarca una porción muy amplia del mercado mundial, sin embargo el modelo de CMMI-DEV (Capability Maturity Model Integrated for Development), no proporciona un marco de referencia adecuado para aquellas compañías que han expandido su visión más allá del desarrollo de sistemas y han incursionado en el mercado de los servicios.

Para ellas, así como para empresas enfocadas principalmente al área de servicios, cualquiera que éstos sean, el SEI (Software Engineering Institute) se ha dado a la tarea de formular un modelo de capacidad que ofrezca el marco de referencia adecuado para administrar y entregar los servicios ofertados, al cual ha denominado: CMMISVC (Capability Maturity Model Integrated for Services), actualmente éste se encuentra todavía en su etapa de pruebas piloto, el SEI espera liberar el nuevo modelo durante la primera mitad de 2008.

Recientemente el grupo de trabajo había detenido su labor porque presentó un caso de estudio al comité que coordina la realización del modelo, como respuesta a varias inquietudes que fueron expresadas por el Departmento de Defensa de Estados Unidos a mitad de año, resolviéndose a través del voto por la inclusión del modelo a la Suite de Productos de CMMI; por lo que se está trabajando actualmente en incorporar los cambios sugeridos por la comunidad experta; así como las recomendaciones realizadas en respuesta a las inquietudes del Departamento de Defensa.

Este modelo está pensado para ayudar a las organizaciones —que usen o no actualmente el marco de referencia de CMMI-DEV— a transformar el desempeño de sus servicios en ofrecimientos maduros y exitosos. Preten-

diendo acrecentar la inversión realizada en los proyectos de mejora de procesos, ampliando su aplicación a otras áreas de la organización; de tal forma que permita que la operación de los diferentes modelos operen de manera síncrona con otras iniciativas existentes. En pocas palabras, el modelo es una nueva constelación dentro de la suite de CMMI que pretende cubrir las necesidades de la industria de servicios y reconoce que éstos son un catalizador en el crecimiento económico mundial, y la necesidad de establecer un marco de referencia, que proporcione guía para desarrollar y mejorar las prácticas de provisión de servicios de las organizaciones como un medio para mejorar la satisfacción del cliente, el desempeño y la rentabilidad de las organizaciones que proveen servicios.

En el contexto de esta nueva constelación de CMMI, un servicio es simplemente un producto intangible, que no puede ser almacenado, y por tanto, el modelo puede ser aplicado a cualquier organización que ofrezca servicios, lo cual incluye compañías de los más diversos sectores, desde las entidades militares, pasando por las de tecnología de información, hasta las dedicadas al cuidado de la salud, finanzas y transportes. De ahí que, la aplicabilidad de este modelo, sea un complemento más que una competencia para el ITIL, ya que resumen las mejores prácticas de este último en un conjunto de prácticas específicas; al mismo tiempo que reutiliza aproximadamente el 77% de las tareas contenidas en los modelos CMMI liberados y en uso (CMMI-DEV y CMMI-ACQ); y se planea que el mismo método de evaluación SCAMPI sea utilizado, lo que permitirá a las empresas trabajar con un método de evaluación estándar, independientemente de las constelaciones de CMMI que cualquiera de ellas adopte.

El modelo de CMMI-SVC, contiene prácticas que cubren los procesos de: administración de proyectos, administración de procesos, establecimiento de servicios, entrega de servicios; así como otros procesos de soporte.

Todos estos procesos están representados en 22 PA’s (áreas de proceso) obligatorias más tres PA’s opcionales, las cuales están conformadas de la siguiente manera: • Se utilizan 16 PA’s que están incluidas dentro de las áreas de proceso base del modelo de CMMI (CMMI Model Foundation); las cuales se comparten por los modelos de CMMIDEV y CMMI-ACQ. • Se definieron cinco PA’s para servicios.

• Se tiene una PA compartida con el modelo de CMMI-DEV (que es el área de Administración de Proveedores) y...

• Para la adición de servicios tres PA’s.

El modelo comprende cuatro categorías de áreas de proceso: • Administración de Procesos. Incluye seis áreas de proceso, de las cuales sólo se adiciona Organizational Service Management (OSM) de las ya incluidas en esta categoría para el CMMI-DEV; y la cual es una de las PA’s opcionales a ser aplicadas.

• Soporte de Servicio. Con seis áreas de proceso. Esta categoría incluye las áreas de proceso de soporte dentro de CMMI-DEV, y adiciona solamente el área de Problem Management.

• Establecimiento y entrega de servicios.

Con sólo cuatro áreas de proceso. Esta categoría realmente representa el fundamento del modelo; ya que todas las áreas de proceso de la misma están enfocadas a los servicios.

Dentro de esta categoría se incluyen las siguientes áreas de proceso:

Elizabeth Almeraz cursó estudios de MBA en Theseus Institute en Francia, es Lic. en Ciencias de la Informática en el IPN. Pionera en temas de aseguramiento de calidad y mejora continua, iniciando grupo de SQA de Tecnosys-IBM para alcanzar el nivel 3 de madurez de CMM. Ha realizado diagnósticos, planes de mejora, revisiones, evaluaciones, capacitaciones, verificaciones y asesorías sobre la implantación del programa de mejora con clientes. Actualmente es socia y se desempeña como Coordinadora Técnica de Consultoría en Avantare.

46

MAY-JUL 2008

www.sg.com.mx

- Incident and Request Management (IRM).

- Service Delivery (SD).

- Service System Development (SSD) -opcional.

- Service Transition (ST).

• Administración de Proyectos. Abarca nueve áreas de proceso. Esta categoría incluye todas las áreas de proceso de administración dentro de CMMI-DEV, considernado la correspondiente a la Administración de Proveedores (SAM), así como la de Administración de Requerimientos (REQM, la cual se encuentra modificada para la aplicación en el área de servicios). Sin embargo, dentro de esta categoría se incluyen dos áreas de proceso específicas para servicios: - Capacity and Availabiltiy Management (CAM).

- Service Continuity (SCON), la cual es opcional.

www.sg.com.mx

El CMMI-SVC es un modelo que se distingue del CMMI-DEV debido a que permite direccionar la administración de punta a punta en servicios complejos o sistemas complejos de desarrollo; y en dónde el uso de los procesos de ingeniería puede ser aplicable; por lo cual, el primero puede ser utilizado para robustecer el uso de CMMI-DEV. Otras ventajas de CMMI-SVC es que el modelo direcciona los problemas comunes en los servicios tales como la entrega repetible a través del tiempo, y los cambios constantes de clientes y requerimientos. Adicionando mejores prácticas enfocadas a servicios, con lo cual se pretende reducir el número de fallas en ellos, mientras se mantiene la disponibilidad de los mismos. Así como mejorar la continuidad del servicio y reducir los costos e incidentes de manera efectiva y eficiente; mientras se incrementa la consistencia y la calidad de los servicios proporcionados.

Conclusiones Como se ve, el CMMI-SVC es un modelo que bien puede ser el complemento perfecto para otras iniciativas de mejora continua; sin importar que se tenga ya en marcha una iniciativa basada en algún otro modelo de CMMI, ITIL u otro modelo enfocado a la mejora de servicios. Habrá que esperar a tener los resultados en el siguiente año. Por lo pronto, se ha mostrado un gran interés por el nuevo concepto que aún se encuentra en gestación; aunque sin duda se espera que será una opción que puede romper algunos paradigmas ya establecidos… en fin, sólo el tiempo lo dirá.

Referencias [ sei.cmu.edu/cmmi ]

MAY-JUL 2008

// UML

Sysml Modelando Sistemas y Sistemas de Sistemas Por Charlie Macías

En esta ocasión hablaremos de un estándar regulado por la OMG, recién salido del horno (septiembre de 2007) que quizá por mi formación en ingeniería mecánica ha venido llamando de manera creciente mi atención y la de muchas empresas desde hace algunos años: SysML (omgsysml.org).

Mientras que UML es un lenguaje de modelado de propósito general (GPML), SysML es un lenguaje de modelado de dominio específico (DSML) definido como un perfil (adaptación) de UML 2.0. Esto es una ventaja, ya que le permite reutilizar la notación y semántica relativamente madura (diez años) de UML 2.0.

El mundo de los sistemas

¿No es suficiente con UML?

Día a día interactuamos con un sinnúmero de artefactos que están conformados por un conglomerado de sistemas compuestos por otros sistemas. Nuestro automóvil por ejemplo: está compuesto por un motor que es un sistema complejo de piezas mecánicas, hidráulicas, electrónicas y de software, que hacen posible su funcionamiento como unidad. Todas estas piezas obedecen a distintos modelos en el ámbito de la termodinámica, la mecánica de fluidos, la cinemática, la dinámica, la tecnología de materiales, etcéctera. Si ampliamos aún más la frontera de control, el automóvil puede ubicarse dentro de otro sistema más grande conformado por las vías de comunicación sobre las que transita, lo cual impacta sobre el sistema ambiental y sobre la sociedad.

Si SysML está basado en UML, entonces, ¿para qué otro lenguaje? El problema con UML es que está fuertemente enfocado al software y los ingenieros de sistemas están buscando un lenguaje de modelado que permita especificar sistemas complejos que incluyan no sólo componentes de software (por ejemplo: hardware, información, procesos, personal e instalaciones). SysML reduce el tamaño e inclinación hacia el software que caracteriza a UML al tiempo que amplía su aplicación para modelar requerimientos y restricciones paramétricas a fin de soportar la ingeniería de requerimientos y el análisis de desempeño, que son esenciales en la ingeniería de sistemas. Un ejemplo emblemático lo conforman los llamados sistemas embebidos para los que desde 1998 existe una adaptación de UML conocida como Real Time UML, la cual no ha sido suficiente.

La especialización de UML SysML (System Modeling Language) es un lenguaje de modelado de dominio específico para aplicaciones de sistemas de ingeniería. Soporta la especificación, análisis, diseño, verificación y validación de un amplio rango de sistemas y sistemas de sistemas. Estos sistemas pueden incluir hardware, software, información, procesos, personal e instalaciones.

¿Qué es la ingeniería de sistemas?

INCONSE (International Council on Systems Engineering) define a la ingeniería de sistemas como una rama de la ingeniería cuya responsabilidad es crear y ejecutar un proceso interdisciplinario que tiene como objetivo asegurar que las necesidades de los clientes y grupos de interés sean satisfechas con alta calidad, de manera confiable, rentable y apegada a calendario a lo largo de todo el ciclo de vida del sistema, que va desde su desarrollo, pasando por su operación y hasta su eliminación. Este proceso está conformado normalmente por las siguientes siete actividades: delimitar el problema, investigar alternativas, modelar el sistema, integrar, implantar el sistema, evaluar el desempeño y volver a evaluar. El proceso de ingeniería de sistemas no es secuencial: las actividades son desarrolladas de forma paralela e iterativa.

48

MAY-JUL 2008

Ventajas sobre UML Entre las principales ventajas que SysML ofrece, sobre UML, a los ingenieros de sistemas para especificar sistemas o sistemas de sistemas se encuentran: 1. SysML expresa mejor que UML la semántica de la ingeniería de sistemas. SysML reduce la predilección por el software propia de UML, y agrega dos diagramas para la administración de requerimientos y análisis de desempeño: diagramas de Requerimientos y diagramas Paramétricos, respectivamente.

2. SysML es más pequeño y sencillo de aprender que UML. SysML remueve varias construcciones centradas en el software, si lo medimos en diagramas todo el lenguaje es más pequeño: nueve diagramas, de SysML vs. 13 diagramas de UML. 3. Las tablas de asignación de SysML soportan varios tipos de asignaciones (por ejemplo: asignación de requerimientos, asignación funcional, asignación estructural) facilitando, de esta manera, la verificación y validación (V&V) automatizada y el análisis GAP.

www.sg.com.mx

“Los diagramas de estructura, comportamiento, requerimientos y parámetros son la base de la especificación”.

Figura 1. Estructura de SySML.

4. Las construcciones de administración del modelo de SysML soportan la especificación de modelos, vistas y puntos de vista; y están arquitectónicamente alineadas con las IEEE-Std-1471-2000 (Practicas Recomendadas por el IEEE para la Descripción Arquitectónica de Sistemas Intensivos en Software).

UML + SysML En un proyecto grande, por supuesto se pueden utilizar ambos lenguajes, de hecho, esta fue la intención de los diseñadores del lenguaje SysML. Sin embargo, es importante señalar que en este ámbito se han identificado dos problemas típicos que hay que

enfrentar: la superposición lingüística y la divergencia lingüística. El primer problema se deriva de que varios diagramas de SysML extienden el significado o se derivan de los definidos en UML (por ejemplo: los diagramas de Actividad o los de Bloques/Bloques Internos en SysML vs. los de Clases/Estructura Compuesta/Componentes en UML). El segundo es el cambio de enfoque necesario para adaptarse al ámbito de la ingeniería de sistemas, por ejemplo: los diagramas Paramétricos inyectan un modelo restricciónlógica en el modelo objeto-componente de UML. Al final del día, como siempre, la práctica está en la experiencia.

Charlie Macías es consultor e instructor senior, especializado en temas relacionados con UML en Milestone Consulting, empresa especializada en capacitación práctica-intensiva y consultoría en UML, BPMN, SysML, Arquitectura de SW y PM. Milestone Consulting fue la primera empresa mexicana miembro de la OMG, y actualmente es REP del PMI. info@milestone.com.mx www.milestone.com.mx

www.sg.com.mx

MAY-JUL 2008

// PM CORNER

EL VALOR DE LAS OFICINAS DE PROYECTOS Apalancar la PMO para Consolidar el Estatus y las Métricas del Proyecto Por Tom Mochal Traducción y Adaptación: José Luis Flores

La PMO (Project Management Office) dentro de la organización es la única capaz de visualizar todos los proyectos en curso. Por lo tanto, es la entidad lógica para definir y recolectar un conjunto de indicadores comunes: y es el lugar lógico para recolectar información del estado de los proyectos para generar reportes consolidados. Esas actividades pueden ser triviales si todos los proyectos recolectan indicadores e información de estatus con apego a los requerimientos. Lo cual provoca que estos valiosos servicios se conviertan en los que potencialmente consumen mayor tiempo y sean los menos preferidos de los que la PMO desempeña.

Un servicio que típicamente está asociado con una PMO en el mercado, es la presentación de reportes del estado de todos los proyectos que se están ejecutando en la organización. Dicho concepto puede extenderse de tal forma que la PMO dé seguimiento completo a una vista global del portafolio de proyectos activos, así como a los pendientes de iniciar y a la historia de los terminados.

Desde un punto de vista muy simple, esto podría parecer un ejercicio superficial, pero puede consumir bastante tiempo. Primero, la PMO debe trabajar con la gerencia que patrocina el proyecto para definir qué es lo que formará parte del reporte de estatus consolidado. Algunas organizaciones gustan de mantener cada proyecto en una línea, con algún indicador tipo semáforo del estatus global, por ejemplo: verde (O.K.), amarillo (precaución) o rojo (problemático). Si es necesaria más información, se puede dar seguimiento en conjunto con el gerente del proyecto. Otras organizaciones gustan más de ver un reporte completo con el estatus detallado de cada uno; si se presentan preguntas o inquietudes, el reporte de estatus puede contener las res-

puestas que se están buscando, entonces no será necesario dar seguimiento adicional con el gerente del proyecto.

Problemas para la obtención del estatus La PMO necesita recolectar información del estatus de cada proyecto, desarrollar un reporte consolidado y exponerlo. Sin embargo, como todas las actividades que recaen en las personas, esto puede ser más fácil de decir que de lograrse. Su PMO probablemente se encontrará con los siguientes retos: •Puntualidad. Primero, la posibilidad de que todos los gerentes de proyecto no envíen la información del estatus dentro del tiempo establecido que se necesita.

•Precisión. En muchos casos, la información no será exacta. Por ejemplo: el gerente del proyecto puede hacer parecer que su trabajo se encuentra dentro del plan, aún cuando no todas las actividades esquemadas están concluidas. Esto se pude identificar si los logros a completar en el periodo previo, no reflejan la misma actividad que se suponía debería estar terminada de acuerdo con el reporte de estatus anterior.

•Compleción o completitud. En muchos casos, la información en el reporte de estatus es precisa, y puede inclusive estar en tiempo.

Sin embargo, puede encontrarse incompleta.

Por ejemplo: la información proporcionada puede ser demasiado breve y no representar el estatus real del proyecto.

Superar los problemas del reporte de estatus Desde luego, dichos problemas necesitan superarse. La PMO puede atacar este tipo de problemas crónicos a través de las siguientes actividades:

•Explicar quién está solicitando la información y para qué será utilizada. Este es un aspecto clave para la presentación de reportes de estatus consolidado. A las personas no les gusta invertir tiempo para proporcionar información, si no sienten que ésta será utilizada. Si las personas entienden quién está solicitando la información, se puede convertir en una alta prioridad para ellos.

•Ser claro cuando solicitemos información que necesitaremos y utilizaremos. Asegúrarse de no solicitar información que no sea necesaria para crear el reporte de estatus consolidado.

•Comunicar claramente cuándo deberán entregarse o presentarse los reportes de estatus. La PMO tendrá dificultad en el levantamiento de información del estatus en algún porcentaje de los equipos de proyecto, por lo tanto, debemos asegurarnos de no propiciar la excusa de que no saben cuándo era el compromiso de entrega de los reportes de estatus.

•Dar seguimiento con los gerentes de proyecto a los temas que necesitan mayor explicación o clarificación. Al recibir información de estatus que no contenga el contenido o el formato requerido, se le debe dar seguimiento con el gerente del proyecto.

Este seguimiento está diseñado para asegurar que los usuarios saben qué se requiere, para evitar las reuniones continuas con ellos.

•Usar el proceso de gobierno en caso de ser necesario. Si la PMO está invirtiendo mucho tiempo para obtener la información cada mes, se tiene que solicitar ayuda al patrocinador del programa, respaldándose en el proceso de gobierno de la organización.

Las gerencia Senior debe mantener la responsabilidad en caso de que los gerentes de proyecto no puedan generar los reportes de estatus en tiempo y forma.

José Luis Flores es Director Editorial de TenStep Latinoamérica y tiene más de 25 años de experiencia en Dirección de Proyectos de TI, cuenta con una Maestría en Desarrollo Organizacional y actualmente es Doctorando en Ciencias de la Administración. Puede ser contactado en: jflores@tenstep.com.mx

50

MAY-JUL 2008

www.sg.com.mx

Indicadores consolidados Existen diferentes lugares donde las organizaciones obtienen valor con la implantación de un proceso formal de Dirección de Proyectos.

Si no se intenta dar seguimiento y cuantificar algunos de esos beneficios, la organización no tendrá idea del valor que se le está proporcionando. Los indicadores asociados con el valor de la dirección de proyectos, son también indicadores indirectos del valor de la PMO. Por ejemplo: si hay más proyectos que se finalizan dentro de las expectativas de la organización, esto sería un indicador del valor asociado con la Dirección de Proyectos, y de la misma forma, mostrarían el valor que ésta proporciona.

Indicadores organizacionales Uno de los temas más difíciles a los que se enfrenta la PMO, es el determinar el valor de la dirección de proyectos. Es una de las preguntas fundamentales que deben hacerse los patrocinadores y la alta dirección en la ejecución de los proyectos de la organización, y es una de las más difíciles de contestar exitosamente. Esto parece ser un valor intuitivo al implantar una metodología estándar de Dirección de Proyectos, pero se

www.sg.com.mx

intenta cuantificar el valor, se encontrará rápidamente bloqueado. Es un poco parecido a tomar una nube. Desde otra perspectiva, parece como si debiese existir algo sólido que pudiera tomarse con las manos. Sin embargo, en cuanto más cerca o más detalle se consiga, todo se vuelve más vago y confuso. Existen un par de enfoques para estos indicadores organizacionales. Uno es dejarlo a la investigación de la industria, y buscar compañías y casos de estudio que son similares a los de su organización para establecer comparativos adecuados. La idea resultante de este proceso es que, si alguien más fue capaz de medir el valor y estamos inmersos en un proceso similar de despliegue (ya sea de una PMO o de un proceso formal de Dirección de Proyectos), se tendría la capacidad de obtener un valor similar.

El segundo es intentar calcular el valor asociado con el uso de la metodología. Por ejemplo: trabajar con los gerentes de proyecto en diferentes tipos de proyectos para determinar los ahorros asociados al mantener buenos procedimientos de cambio de alcance, gestión de riesgos proactivo y gestión efectiva de las

expectativas del cliente. Al realizar la práctica continua de entrevistar un subconjunto de gerentes, se comienzan a ver algunas tendencias que puede aplicarse al resto de los proyectos dentro de su organización.

Y como tercer tema, buscar la reutilización del valor asociado haciendo uso de un proceso común de la gestión de proyectos. De nuevo, este enfoque requiere el solicitar a los gerentes de proyecto la estimación de los ahorros asociados con el uso de procesos similares en múltiples proyectos y obteniendo así los beneficios estimados en tiempo y costo por la reutilización continua de procesos comunes, obtenidos en diferentes proyectos.

Hay algunas áreas de servicio donde la PMO no tiene suficiente nivel de experiencia. Los indicadores podrían ser una de esas áreas.

Muchas compañías no conocen lo suficiente acerca de la definición y la captura de un buen conjunto de métricas. En este sentido, algunas firmas de consultoría tienen una gran experiencia en esta área con la cuál podrían apalancarse para asegurar un comienzo con el pie derecho en este tema.

MAY-JUL 2008

// PUBLIRREPORTAJE

IDS, Una Empresa Orientada a Procesos Experiencia en Acreditación CMMI3 Por José de J. Hernández

Ser una empresa orientada a procesos, implica ser fieles creyentes del beneficio de los procesos, anticiparse en la calidad de los productos que desarrolla y promover una filosofía de trabajo con prácticas estándar. IDS es una organización que ha trabajado y trabajará fuertemente en ello. Este ha sido el espíritu que lo llevó a alcanzar su siguiente eslabón en la mejora de procesos: ser una empresa CMMI® nivel 3.

Antecedentes IDS Comercial es una empresa 100% mexicana fundada en 1982 que ofrece servicios de consultoría, desarrollo y capacitación en Tecnologías de Información. Tiene participación en un gran número de proyectos dentro de los sectores financiero, de seguros, comercial, manufactura, telecomunicaciones, servicios y gobierno.

Uno de los principales factores que IDS ha considerado como importante desde sus inicios para lograr el éxito, es fomentar una cultura orientada a procesos para la ingeniería de software, apegados a las mejores prácticas, estándares internacionales y modelos de la industria.

Elementos importantes Para establecer un programa de mejora continua y trabajar con orientación a procesos, primeramente debemos instaurar un enfoque de calidad que nos permita trabajar con una filosofía de desarrollo de productos libre de defectos; así como comprender el costo del re-trabajo asociado al no hacerlo de esta manera (costo de la no calidad).

Posteriormente implantar procesos y técnicas definidas que nos guíen en la manera como desarrollaremos nuestros productos; y finalmente emplear herramientas de apoyo a los procesos.

No debemos olvidar que los elementos verdaderamente importantes para trabajar con una orientación a procesos son: gente, procesos y tecnología. El proceso en sí, es la mezcla de gente capacitada, procedimientos establecidos y herramientas de apoyo.

Solamente combinando estos elementos podremos desarrollar productos de calidad.

Estrategia para la Alineación al modelo de referencia

Después de alcanzar el nivel 3 de SW-CMM® en el año 2004, IDS comenzó un importante ciclo de mejora en el año 2006 para alinear su metodología de desarrollo de software al modelo CMMI® versión 1.2 en su nivel 3.

Para describir las diferentes aristas en las que debemos trabajar en un programa de mejora continua, expondremos brevemente en qué consistió el proyecto que culminó con la evaluación CMMI de IDS.

Como resultado de este esfuerzo, en marzo de 2008 IDS realizó su evaluación formal, obteniendo la acreditación como una empresa CMMI® con nivel de madurez 3.

Las grandes etapas que consideró el proyecto fueron: • Mini Appraisal tipo C. Su objetivo fue ejecutar una evaluación informal tipo C que permitiera conocer la brecha entre la definición vigente de la metodología alineada a SWCMM® nivel 3 con respecto a CMMI® nivel 3; así como identificar oportunidades de mejora.

¿Cuál ha sido la experiencia de IDS al trabajar un programa de mejora continua? A continuación, describiremos a grandes rasgos algunos de los factores, consideraciones importantes y lecciones aprendidas que IDS ha obtenido al implementar un programa de mejora continua.

•Planeación. Con base en lo anterior, definimos la estrategia y las etapas en las que se dividiría el proyecto, realizando una pla-

neación detallada al inicio de cada una. Es importante resaltar que un programa de mejora continua debe ejecutarse con las buenas prácticas de administración de proyectos.

•Definición. Su propósito fue desarrollar todas y cada una de las prácticas que hacían falta incorporar a la metodología de IDS, así como las mejoras detectadas conforme a las áreas de proceso de CMMI®. Las definiciones y mejoras realizadas fueron guiadas, revisadas, retroalimentadas y validadas por un comité que para IDS es sumamente importante: el SEPG (Software Engineering Process Group).

•Implantación. Esta etapa comenzó con fuertes trenes de capacitación a los integrantes de los equipos de trabajo, continuando en forma permanente con un modelo de mentoría hacia los proyectos, lo cual tiene como objetivo apoyarlos en el correcto uso de los elementos metodológicos.

•Mini Appraisal tipo B. Después de haber ejecutado durante cierto tiempo la nueva versión de nuestra metodología, realizamos una evaluación informal tipo B para determinar qué tan lejos nos encontrábamos del cumplimiento de las prácticas que marca CMMI® 1.2 para el nivel 3, y así observar nuevamente posibles oportunidades de mejora.

•Ajustes y preparación para la evaluación.

Su enfoque fue realizar ajustes a nuestra metodología de acuerdo a la etapa anterior, así como una fase de preparación para llevar a cabo toda la logística que conlleva una evaluación formal.

•SCAMPI A. Finalmente, ejecutamos nuestra evaluación formal, teniendo como objetivo evaluar nuestro nivel de madurez, detectar nuevas oportunidades de mejora, así como obtener nuestra acreditación CMMI® nivel 3.

José de J. Hernández Suárez es Lic. en Informática por la UNAM y Maestro en Ingeniería de Software por el Centro de Investigación en Matemáticas (CIMAT).

Desde 1998 ha trabajado en el campo de la ingeniería de software asumiendo diferentes roles como: desarrollador, analista, líder de proyecto y gerencia de proyectos, mismos que desempeñó en la Dirección General de Servicios de Cómputo Académico de la UNAM. En los últimos 2 años y medio desempeñó el puesto de gerente de procesos y calidad de software, estando a cargo de la implementación de CMMI®3 en IDS. Actualmente es director de tecnología y calidad de IDS Comercial. jjhernandez@ids.com.mx

52

MAY-JUL 2008

www.sg.com.mx

Cabe resaltar que como parte de la estrategia, se definió el apoyo de entrenamiento informal y formal en el modelo CMMI, evaluaciones informales (mini appraisal), así como consultoría de un externo, que permitiera aportarnos enfoques, revisiones técnicas a las definiciones (peer reviews), retroalimentación y soporte en la preparación de la logística de la evaluación formal con la intención de que IDS no actuara como juez y parte en su implementación. Este apoyo fue dado por la empresa Innevo.

Consideraciones importantes y lecciones aprendidas Resulta importante comprender que para trabajar dentro de un programa de mejora continua deben conocerse, contemplarse y trabajar los siguientes aspectos: • Definición e involucramiento correcto de los roles participantes en el programa de mejora continua: sponsor, quien patrocina el proyecto. SEPG, quien analiza, propone, define, implementa, revisa, retroalimenta y valida las mejoras; mentores, quienes actúan como coach de los equipos de trabajo en la implantación de las mejoras. QA, quienes aseguran la calidad de los procesos y los productos de trabajo; champion de la mejora continua, quién tiene la visión de la mejora, difunde la filosofía establecida y es responsable del programa de mejora continua; agentes de cambio, actores en la operación de los proyectos, convencidos de la mejora y que contribuyen a permear lo establecido.

• En la definición de las mejoras es importante: involucrar a la gente con más experiencia en el campo; tratar de hacer lo más sencillos y útiles los procesos; utilizar la tecnología disponible; hacer partícipes de la definición a los integrantes de los equipos de trabajo; realizar talleres para revisar, retroalimentar y validar los procesos; considerar en los procesos las bases de definición de los siguientes niveles de madurez del modelo; definir las políticas que regirán a los procesos de la organización acorde a la misma; capacitación constante en donde se www.sg.com.mx

sensibilice y palpe la utilidad y beneficio de un nuevo proceso; realizar workshops para reforzar el conocimiento; dividir el aprendizaje en módulos, y reconocer a la gente capacitada y acreditada en los procesos.

sumamente largo, el cambio y el esfuerzo se abandonan, se pierde la motivación y falla el proceso de mejora. El secreto consiste en delimitar y administrar bien esa transición, buscando construir el compromiso de todos .

• Es necesario trabajar en una sólida estrategia de administración del cambio que considere: una campaña de difusión que busque generar identidad con la metodología y sensibilización sobre la aplicación de la misma; distribuir estratégicamente en el tiempo la comunicación; mantener informada a toda la organización sobre el trabajo del SEPG; comunicar cómo va el proyecto; medir y remunerar (no de manera monetaria); reforzar el reconocimiento a través de tips y elementos adicionales para el uso de los procesos; hacer el beneficio tangible, motivacional; evidenciar el beneficio individual derivado del cambio.

El obtener una acreditación en el modelo, no significa haber finalizado y que podemos bajar la guardia en los elementos que aquí exponemos. Tampoco es bueno pensar en planear de inmediato la implantación del siguiente nivel. Primeramente debemos comprender las oportunidades de mejora detectadas, y planear un nuevo ciclo para atacarlas; trabajar en una estabilización de la utilización de la metodología, dando el tiempo adecuado para fortalecer el nivel de madurez. Una vez logrado esto, será entonces cuando podremos voltear a un nuevo ciclo de mejora que tenga como meta el siguiente nivel del modelo.

• En la ejecución de los procesos en los proyectos, es importante considerar: un proceso definido para el proyecto, que el equipo identifique los procesos que va a ejecutar; asignar un mentor que apoye al proyecto en todo momento; instaurar diferentes canales para las propuestas de mejora de procesos; reconocer a los proyectos que mantengan el parámetro (umbral) más alto de apego a la metodología; fomentar un espíritu de competencia; e implementar un QA orientado a servicio.

• Los proyectos deben contar con una infraestructura de procesos: repositorio de la definición de procesos de donde puedan obtener los elementos metodológicos; mostrar ejemplos de la elaboración de los artefactos; publicar material de capacitación; difundir lecciones aprendidas; recolectar activos de proceso (artefactos reales de proyectos finalizados).

Con todos los elementos anteriores debemos comprender que durante una transición del cambio, lo viejo y lo nuevo coexiste y la gente pasa por un momento complicado al tratar de atravesar del pasado al presente.

Este conflicto puede producir baja productividad, lo cual hasta cierto grado es normal, sin embargo, si el período de transición es

Basado en: Boria, Jorge, “Change does not Happen”, febrero, 2002.

1

Conclusiones Implementar un programa de mejora continua no depende del modelo de referencia adoptado para desarrollar una metodología de trabajo. Es importante buscar y combinar de manera asertiva, un enfoque de orientación a procesos.

Debemos planear ciclos de mejora que nos permitan alcanzar a corto y mediano plazo las metas propuestas, al lado de una clara y robusta estrategia de administración del cambio.

Como su nombre lo indica, un programa de mejora continua nunca termina, pues siempre existen posibilidades de mejorar: alinearnos a un modelo, optimizar algo, buscar un siguiente nivel, definir nuevos productos o servicios para nuestros clientes, etcétera. Lo importante es saber qué queremos mejorar, por qué lo queremos mejorar y entonces mejorarlo, utilizarlo, estabilizarlo y hacer de ello una filosofía de trabajo.

MAY-JUL 2008

53

// fundamentos

¿Cuál es mi Password?

La Epidemia de Cuentas Por Karina Okón ¿Cuántos nombres de usuario manejas para acceder a las distintas aplicaciones que utilizas en tu trabajo diario? Dependiendo del tamaño y características de tu empresa, la respuesta puede variar, pero en general en organizaciones medianas o grandes, el número tiende a ser elevado; pero ¿alguna vez has pensado en las aplicaciones que residen fuera del área laboral, pero con las que tienes una relación de negocio?

Casi todos nosotros hemos experimentado la frustración que supone olvidar una de las muchas contraseñas necesarias para acceder a una determinada aplicación web, y la pérdida de tiempo (y dinero) mandando correos electrónicos o hablando por teléfono con el personal de soporte técnico para cambiar la contraseña olvidada. Aunque los repositorios únicos de identidades han dado a los propietarios y gestores de los recursos control sobre los mismos, han aparecido problemas graves de seguridad y acceso, al crecer el número de aplicaciones y recursos tanto dentro como fuera de las organizaciones.

Los usuarios finales tienen demasiadas cuentas y contraseñas para mantener adecuadamente. Meta Group estima que durante el tiempo de estancia en una empresa, a un empleado se le asigna una media de 16 contraseñas para acceder a aplicaciones críticas. Para ser capaces de recordar estas contraseñas, los usuarios las guardan en sitios poco seguros (como un archivo llamado contraseñas en su PC, post-its debajo del teclado, etcétera), utilizan la misma clave en varios sistemas o simplemente esperan hasta necesitar una determinada cuenta/ contraseña para llamar a soporte técnico.

Todo lo anterior supone una gran pérdida de tiempo y dinero además de los evidentes riesgos en la seguridad de la organización.

Figura 1. Arquitectura de autoridad única.

Los propietarios y gestores de los recursos, se dan cuenta a menudo que el mantenimiento de las cuentas de los usuarios es un difícil desafío. La gente cambia regularmente de jefe y/o puesto de trabajo dentro de la organización, muy frecuentemente sus accesos a cuentas y aplicaciones no son deshabilitados con los cambios de funciones, creándose las llamadas cuentas fantasma que pueden suponer un back door para que ex-empleados, por ejemplo, accedan a datos confidenciales de la compañía. Entonces, ¿cuál es la solución?

sistemas con una única acción de login, aliviando la carga que supone recordar un gran número de cuentas y contraseñas.

Pasos para el tratamiento ¿Qué debemos hacer para llegar a la agrupación de identidades?

La agrupación de identidades

Primero, examinar la cultura de la empresa.

Recordemos que hasta ahora los propietarios y gestores de recursos se sienten bien con el control autónomo sobre los mismos.

Ahora deben estar dispuestos a renunciar a algún grado de autonomía para conseguir mejorar el servicio a los usuarios.

La solución al problema de la epidemia de cuentas viene de la mano de la agrupación de identidades, que es esencialmente la unificación de datos dispares de identidades o cuentas de usuario. Este modelo unificado permite que los datos, a través de diferentes aplicaciones, estén disponibles dónde y cuándo se necesiten. Para los usuarios, esto supone la capacidad de acceder a múltiples

Segundo, debe haber una confianza entre los propietarios de los recursos y los propietarios de los sistemas de identidades. Esta confianza debe ser formalizada en acuerdos legales y de negocio, que marquen claramente las responsabilidades de cada uno a la hora de proporcionar, aceptar y gestionar la información de identidades. Este paso es a menudo

Karina Okon. IdM Specialist en BMC Software de México. Especialista en seguridad, ha coordinado y desarrollado proyectos para el aprovisionamiento e integración de los recursos de seguridad de las corporaciones a las diferentes unidades del negocio; responsable de dar soporte e información al área comercial, socios de negocio y área técnica acerca de la estrategia del área de seguridad en BMC Software. Ha apoyado al área de ventas a través de capacitación para asegurar una penetración de mercado más rápida, manteniendo la calidad del servicio a clientes.

54

MAY-JUL 2008

www.sg.com.mx

el mayor reto. Evidentemente, las primeras relaciones de agrupación de identidades, serán más sencillas en aquellas organizaciones con las que exista ya una buena relación.

Tercero, son necesarios componentes tecnológicos. Detrás de la agrupación está la necesidad básica de comunicación entre cada sistema. Los sistemas están hechos por distintos fabricantes, utilizando diferentes herramientas sobre plataformas heterogéneas, todo lo cual conduce a barreras de comunicación al implementar la agrupación de identidades.

La buena noticia es que hay un número de estándares de la industria, que permiten inter-operar a una gran variedad de productos independientes. Estos estándares incluyen: •SAML (Security Assertions Markup Language), estándar definido por OASIS ( Organization for the Advancement of Structured Information Standards).

•WS-Federation, especificación promulgada por Microsoft, IBM y otros.

•ID-FF (Liberty Federated Identity Management Framework). Especificación de Liberty

Alliance, consorcio de la industria dedicado a la gestión de entidades federadas.

•Shibbolet, iniciativa de código abierto basada en SAML. La implementación de la agrupación de identidades no es trivial, pero el beneficio supera con creces los desafíos que tendremos que vencer. A las mejoras de la seguridad y los ahorros de costos citados anteriormente, se une la posibilidad de hacer nuevos negocios mediante el establecimiento de alianzas entre empresas de distintos sectores. Cuanto antes se empiecen a examinar los procesos de negocio, los procesos de TI asociados y la cultura interna de la compañía, estaremos en disposición de abordar nuevos retos y sacar partido de la agrupación de identidades para servir mejor a nuestros usuarios, proveedores, socios y clientes.

Ejemplos prácticos En las gráficas podemos ver dos ejemplos de agrupación de identidades. En la figura 1 se trata de diversas compañías públicas (un organismo, una agencia, una delegación y un patronato) pertenecientes a una misma tarea. La arquitectura elegida (denominada autoridad única de gestión de identidades) está basada en un hub central que actúa como proveedor de identidades, a excepción del patronato, el resto de las organizaciones actúan como proveedoras de datos.

Asimismo, el hub actúa como suministrador de servicios para todas ellas, menos para el patronato, mientras que las cuatro entidades actúan como proveedores de servicios hacia el hub.

Figura 2. Arquitectura en estrella.

www.sg.com.mx

En la figura 2, podemos observar las distintas identidades del usuario en los diferentes puntos y las relaciones de confianza entre ellas. Gracias a estas relaciones una persona puede validarse en el organismo dónde trabaja, y acceder a una aplicación web de la agencia con la misma sesión. La arquitectura en estrella hace posible que no se almacene en ninguna entidad (solamente en el hub central) las relaciones entre los identificadores de cuentas del usuario en las distintas entidades.

MAY-JUL 2008

// TECNOLOGÍA

/*INFRAESTRUCTURA*/

Software Appliances

Los Mejores Amigos de las Empresas en Crecimiento Por Ariel García Quienes hemos administrado sistemas conocemos la gran carga de trabajo que esto conlleva. La administración de licencias, servidores y equipos; contratos de mantenimiento, control de cambios e incidentes y garantías, son actividades típicas del día a día. Adicionalmente, cualquier actualización a la infraestructura puede implicar días o incluso semanas trabajando a marchas forzadas para dejar los sistemas trabajando adecuadamente.

Hace unos años surgió el modelo de Application Service Provider (ASP) como una opción para minimizar la carga de trabajo ligada con la administración de TI. Aunque este modelo se mantiene válido, tiene sentido que veamos más allá, y es aquí donde nos encontramos con las software appliances. Veamos entonces en que consiste esta tendencia y como se compara con el modelo de ASP.

Application Service Provider: la primera alternativa Bajo el modelo de ASP, una empresa contrata un servicio –como puede ser el correo electrónico, o el uso de alguna aplicación– a un tercero, el cual se encarga de toda la parte de administración del servicio de cómputo. Típicamente se paga una renta mensual, posiblemente ajustada al número de usuarios del servicio.

Los distintos servicios ofertados por el proveedor típicamente son modulares, permitiéndole al cliente final contratar únicamente la funcionalidad que necesita para su trabajo. Por ejemplo: el departamento de contabilidad podría adquirir un servicio de ERP únicamente con el módulo para la administración de activo. El resto de la funcionalidad del ERP no es habilitada y el cliente solamente pagará por el servicio que utiliza y no por un producto completo.

La ventaja para el cliente es evidente: se ahorra costos de administración en los servicios de cómputo, invierte únicamente en la funcionalidad que necesita y tiene la capacidad de activar nueva funcionalidad conforme la requiera.

56

MAY-JUL 2008

Desafortunadamente, la implementación de servicios de cómputo con un ASP tiene un inconveniente, este modelo obliga al cliente a tener información crítica y/o confidencial del negocio, socios de negocio y/o clientes fuera de la empresa en manos de compañías que posiblemente no cuenten con los recursos y/o políticas necesarias para la protección y seguridad de dicha información.

Negocios con altos requerimientos de seguridad y privacidad pueden implementar una solución basada en Software Appliance.

Software Appliance: servicios de cómputo a la medida Una solución basada en Software Appliance combina lo mejor del modelo ASP con la robustez de una solución empresarial tradicional.

El modelo del Software Appliance sigue el mismo principio de ofrecer módulos de funcionalidad independiente, accesibles a través de un navegador de Internet, habilitados acorde a las necesidades del cliente final.

La principal característica del Software Appliance que lo diferencia de un modelo ASP es su diseño, el cual consiste en una capa de software proveedora de la aplicación para el usuario final, corriendo bajo un sistema operativo modificado y configurado específicamente para esta aplicación. Este diseño de alta integración permite que los componentes de la capa de software y el sistema operativo puedan configurarse con mayor seguridad dado que soportan únicamente las funciones necesarias de la aplicación, eliminando servicios innecesarios.

No obstante, ambos componentes (capa de software y sistema operativo) pueden correr en cualquier servidor estándar de la industria (Wintel, RISC, etcétera) o una maquina virtual. (Un Software Appliance que se ejecuta en una maquina virtual se le conoce como Virtual Appliance). Empresas con altos requerimientos de seguridad pueden utilizar este modelo para obtener los beneficios de una baja administración y contar con la seguridad de tener la aplicación dentro de su infraestructura de cómputo.

Características principales de un Software Appliance Compila, corre y ejecuta lo que tenía que hacer a la primera. La instalación y configuración de los componentes de la capa de software se ejecutan sin errores en la primera y única corrida. Esto se debe a que no sólo el sistema operativo está parametrizado de forma especifica a la aplicación, también lo están el servidor web y las bases de datos. Además se utilizan servicios estándar web XML API para la carga y descarga de datos. Esta característica elimina tareas típicas que complican la implementación de un esquema tradicional como: configuraciones especiales para sistema operativo, configuración de seguridad servidores de web, tunning de bases de datos, compatibilidades entre versiones de software, instalación de parches, etcétera.

Lo sentimos mucho, no habrá capacitación en este proyecto. Su operación y administración se ejecuta en un único grupo de herramientas que eliminan la capa de administración del sistema operativo e integran la administración de la base de datos, servidor web y la aplicación. Un administrador de sistemas no necesitará capacitarse para administrar un Software Appliance corriendo en una versión de Linux, con Apache y MySQL, dado que las configuraciones del sistema operativo y demás aplicaciones, son realizadas a través de las herramientas de administración del Software Appliance.

Un solo culpable con habilidades de regeneración ... ¡Wow!. Existe una sola cara al cliente en la detección y solución de problemas. El proveedor de servicio es el único responsable de identificar, aislar y resolver cualquier problema dentro de algunos de los módulos de la aplicación, la capa de software o el sistema operativo (usualmente estas actualizaciones no requieren de una modificación en el hardware). Adicionalmente, el appliance tiene la capacidad de detectar y corregir problemas en su operación sin la intervención de un administrador. Debido a que los componentes de software están altamente

www.sg.com.mx

integrados y son administrados de forma centralizada, permitiendo que tenga la capacidad de ser auto-administrable y auto-corregible.

Esto se traduce en la eliminación de las eternas batallas entre consultores de software, administradores de bases de datos y administradores de sistemas operativos. El cliente final sabe que la única persona con la que tendría que trabajar es el proveedor de servicio, esto en caso de que el Software Appliance no haya podido corregir por sí mismo un error en su operación.

Ahora sí es en serio, habrá un control de cambios documentado. La administración de cambios se vuelve más sencilla. El proveedor de servicios es el único responsable del mantenimiento, instalación y configuración de parches, y la actualización a nuevas versiones en cualquiera de sus componentes del Software Appliance. De hecho, estas tareas se ejecutarían de forma remota a través de las herramientas de administración.

En resumen, los beneficios de una solución de servicios de cómputo basada en Software Appliance es clara. Es una solución con un costo total de propiedad bajo, dado los bajos costos de mantenimiento y administración. No obstante, esta solución tiene un mercado específico.

A continuación enumeramos algunos indicadores que nos permiten entender si una solución basada en Software Appliance es adecuada para nuestro negocio.

1. Infraestructura de sistemas. Es claro que un software appliance es la solución perfecta para pequeñas empresas que carecen de un área de sistemas como tal. El mercado de estas soluciones está orientado típicamente a compañías de cinco a 500 empleados.

2. Política de compras de la empresa. Esta solución se comercializa ya sea a través de una renta por uso o modo prepago. Es claro que el cliente delega el servicio y manteni-

www.sg.com.mx

miento al proveedor del Software Appliance con los beneficios ya mencionados.

3. Desempeño. Servicios con un alto grado de desempeño no son recomendables para una solución con Software Appliance. En tal caso es preferible un Hardware Appliance donde el proveedor entrega el servicio en una caja negra que integra la capa de software, el sistema operativo y el hardware.

4. Estrategia de compras. Para compañías que acostumbran adquirir equipos con una expectativa de uso de largo plazo, una solución basada en Software Appliance es ideal, dado que es posible ubicar la aplicación en cualquier servidor estándar.

5. Seguridad. Un software Appliance tiende a ser más seguro que su contraparte en un esquema tradicional ya que las capas de software y sistema operativo son protegidas de forma más sencilla dado que cuenta con menos servicios o elementos a ser atacados.

Una vez definiendo si nuestra empresa califica para el uso de soluciones basadas en Software Appliance, podemos analizar las soluciones existentes en el mercado para iniciar nuestro análisis y selección de proveedores. Hoy por hoy, podemos encontrar servicios de Software Appliance con Google, Wikipedia, Zimbra, entre otros. SAP e IBM están trabajando conjuntamente en servicios que podrían ser accesibles en corto plazo. El mensaje clave de este artículo es no perder de vista esta tecnología, que con sus múltiples beneficios, puede ser de gran valor para la pequeña o mediana empresa que busca cumplir con el credo de todos los días: la entrega de mayores y mejores resultados con menos recursos.

Referencias: [en.wikipedia.org/wiki/Software_appliance ] [networkworld.com/buzz/2005/092605softapp.html ] [files.zimbra.com/website/docs/Zimbra% 20rPath%20Installation.pdf ]

MAY-JUL 2008

// TECNOLOGÍA

/*gadgets*/

Van Der Led

WM2 Watchphone Al parecer los diseñadores industriales quieren sorprender el mercado geek con sus nuevas aportaciones. Remontándonos a la época de los ochenta con Michael Knight y a la era de los noventa con Dick Tracy (la película). Y es que para usar este reloj, pareciera que el atuendo adecuado es una chamarra de piel o una gabardina amarilla.

Y no es para menos si vemos sus características: GSM, 1.3 pulgadas de tamaño, 260k TFT touchscreen, radio FM, capacidad de almacenamiento de 1GB, Bluetooth y si eso no es suficiente, un USB para la transmisión de datos. Además cuenta con una cámara a 1.3 megapixeles y como plus se puede ver la hora.

Así que no hay que sorprenderse si un día con solo doblar la muñeca, llamamos a Kitt para que nos recoja en la puerta de la oficina.

Solar Technology

Supercharger De la mano con la ecología y para aprovechar la energía solar, aparece este nuevo cargador. Con celdas cristalinas de 1.5 watts y un peso de 200 gramos se puede llevar en la mochila, la bicicleta o cualquier otro lugar porque sus bandas de velcro permiten ajustarlo en algún soporte. Tampoco hay que preocuparse por la lluvia, viene con una protección para todo tipo de clima, permitiéndo su uso constante.

Olympus

Cámara Stylus 850 SW Para no perder detalle de los eventos, el equipo de SG tuvo la oportunidad de realizar pruebas con esta nueva cámara de 8.0 megapixeles.

Viene con cable USB, cable de audio/video, batería recargable de litio y cargador a prueba de congelación. Cuenta con detección de rostros.

Ya no tenemos pretexto de salir de vacaciones y perdernos todos esos paisajes que la naturaleza nos regala. Con este modelo, podremos sacar fotografías debajo del agua hasta 3m, además es a prueba de golpes, caídas y otras eventualidades. Sin importar cuál sea tu estilo de vida, esta cámara por su tamaño la puedes traer en cualquier momento.

58

MAY-JUL 2008

Sólo cuatro horas de exposición al sol, bastan para tenerlo listo y darle vida extra al teléfono, iPod o cualquier otro dispositivo que sabemos en algún momento necesitará energía para seguir funcionando.

Ahora sí, no hay excusa para no tener energía.

www.sg.com.mx

INDEX

DIRECTORIO

TENEMOS UN ESPACIO RESERVADO PARA TI Si deseas anunciarte contáctanos en el (55) 5239 5502 o en ventas@softwareguru.com.mx www.sg.com.mx

Anunciante Alpha Avantare CA Compusoluciones Cutter e-Quallity Fone Gartner IDC Information Secutity Itera Kernel Manpower Microsoft Milestone Consulting Safe Net SIE Center SG’08 SUN

Páginas 55 17 7 57 59 27 45 11 51 47 15 63 49 2F, 1 4F 3F 41 22, 23 43

Sitio www.alpha-consultoria.com www.avantare.com www.ca.com/mx www.compusoluciones.com www.cutter.com.mx www.e-quallity.net www.juegodetalento.com www.gartner.com www.idc-eventos.com www.informationsecurity.com.mx www.itera.com.mx www.kernel.com.mx www.manpowerprofessional.com.mx www.microsoft.com/mexico www.milestone.com.mx www.safenet-inc.com ciisa.gda.itesm.mx www.sg.com.mx/sg08 www.sun.com.mx

MAY-JUL 2008

31 59

// COLUMNA

/*tendencias en SOFTWARE*/

¿Hacia Dónde Vamos?

Reflexiones de la Industria de Software en América Latina Luis Daniel Soto es director regional de desarrolladores y difusión de pvlataforma en Microsoft para América Latina. Es miembro de la orden nacional al mérito de México (ministro de educación). Luis Daniel obtuvo el primer lugar en el Concurso Nacional para Software de Exportación en 1989. blogs.msdn.com/luisdans

H

ace doce meses acepté la oportunidad de dirigir la cuarta área del mundo para Microsoft relacionada a construcción de software en América Latina. Por este conducto deseo resumir y compartir con ustedes mis observaciones relacionadas al desarrollo de la industria de software.

Perfil Aun cuando América Latina cuenta con el 15% de estudiantes del mundo, representa el 7% de desarrolladores de software a nivel mundial y el 1% en cuanto a empresas de software empaquetado. Nuestra actividad en la región de inicio usuario de integración de software internacional, desarrollo a la medida, educación y mínimamente software empaquetado.

De acuerdo a Mauricio Santillán de Visionaria, la utilidad anual de estas empresas es del 10% en promedio (muestra de 200), los tres clientes principales representan 64% del total de sus ventas y las áreas que requieren más fortalecimiento son ventas (74%), mercadotecnia (54%), servicio a cliente (32%), operaciones (27%) y perfeccionamiento directivo (17%).

Incluso cuando la parte técnica se considera robusta y no aparece en la lista, el 85% aún no incorpora elementos de calidad en construcción de software, ni el cliente final los demanda.

Muy pocos países tienen programas reales de apoyo a la industria de software. Hay diversas asociaciones regionales, por ejemplo en Costa Rica existe un club de investigación tecnológica (desde hace 20 años). Los organismos internacionales se enfocan en emprendedores (YABT) y nuevas empresas (RELAPI).

Las oportunidades Lo más importante es tener el recurso humano.

Diversos estudios muestran que los mejores desarrolladores inician a los 13 años.

Los programas académicos deben interesar desde esa edad a los jóvenes y llevarlos de la mano desde ahí hasta la culminación de la carrera. Se deben crear modelos a seguir que impulsen a otros adolescentes. La mer-

60

MAY-JUL 2008

cadotecnia de los exitosos es un ingrediente que ha faltado en los esfuerzos recientes.

Debemos incorporar mucho más educación basada por proyecto desarrollado, siempre en equipo y olvidarnos de tantos exámenes.

Vinculación academia-industria. Es triste, pero el sector académico está convencido de que está enseñando lo correcto cuando más del 80% de egresados requieren entrenamiento para incorporarse a la realidad.

El tiempo dedicado a decidir qué les enseñaré a los muchachos, ahoga realizar intercambios en los centros de oportunidades apoyados por el gobierno. La industria y la academia, requieren hablar mucho más para identificar las grandes áreas de desarrollo.

El rol del gobierno. Éste, debe favorecer el desarrollo y exportación de software con un gran enfoque en normatividad que realmente beneficie a la mayoría. En mi opinión personal, debe alentar la neutralidad tecnológica, evitando temas que reduzcan el ámbito de opciones.

El rol de la mujer. Menos del 9% de desarrolladores profesionales de software son mujeres. Basta decir que estamos limitando el 50% de los recursos humanos existentes.

Ellas continúan discriminadas sin ser consideradas para su rápido desarrollo. Este tema ha cobrado auge mundial. El paradigma errado de muchos gobiernos es fomentar que las mujeres hagan negocio en bisutería.

Para la industria existente. Hay que tomar en serio el negocio. En Israel, las empresas más pequeñas de software con frecuencia contratan a un doctor en mercadotecnia y cuentan con procesos formales de venta. En este sentido, se están creando programas apropiados para el perfeccionamiento directivo, hay que continuar a la búsqueda de los recursos externos que puede darle alto valor a la empresa.

Montar las grandes oleadas. El cambio más grande al que nos enfrentamos es a la trans-

formación a una era de software como servicios, pero sin duda la habilitación de la nueva mercadotecnia o mercadotecnia cercana a costo cero, es un tema que tiene que ser digerido por las empresas de todo tipo.

Recursos humanos • Crear “iconos” para atraer talento • Incorporar a las mujeres • Educación por proyecto • La academia debe producir recursos útiles y quitarse la falsa ilusión de que hoy lo hace

Industria • Dejar de creer que el gobierno debe resolver todo • Reforzar ventas y mercadotecnia • Eliminar la rivalidad entre los nacionales

Oportunidades a ganar • Infraestructura y capacidades para el Software más servicios (TI) • Ser habilitadores de la “nueva mercadotecnia”

Conclusión En México, el PROSOFT apunta en la dirección correcta, debemos permitirle avanzar rápido. Aunque cada región tenga vocaciones particulares, deben ser construidas sobre una base común.

El futuro de las tecnologías es muy brillante en cuanto a novedades, pero sobre todo en cuanto a aplicaciones para mejorar nuestras vidas diarias y la misión de nuestras empresas. ¡Participa como agente de cambio!

» Luis Daniel Soto

Referencias: [ visionaria.com ] [ clubdeinvestigacion.com ] [ relapi.org ] [ myybiz.net ] www.sg.com.mx

/*tierra libre*/

// columna

Software en la Comunidad Simulación Participativa para la Sustentabilidad Ambiental Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones.

Ferviente entusiasta de la aplicación social de la tecnología, a últimas fechas está involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en oemilio@tecnonirvana.org

E

n cuanto conocí el trabajo de simulación participativa para enseñar sustentabilidad ambiental del Dr. Luis García Barrios, investigador en El Colegio de la Frontera Sur en San Cristóbal de las Casas, Chiapas; consideré imprescindible hablar de él. Luis y un equipo de voluntarios llevan varios años tratando de resolver el problema ambiental de raíz, capacitando, con ayuda de software, a las personas de las comunidades más apartadas de Chiapas para que utilicen los recursos de sus tierras sin daño al ambiente.

El ejemplo más interesante de estos trabajos, es el realizado con el Marco de Evaluación de Sistemas de Manejo Incorporando Indicadores de Sustentabilidad (MESMIS). Este es un esfuerzo por crear una metodología de evaluación de prácticas de sustentabilidad para los recursos naturales, que permita indicar qué tan abastecidas o no son las prácticas de explotación de los recursos naturales de un lugar determinado. Este trabajo ha sido reconocido a nivel mundial y es producto de varios investigadores mexicanos agrupados en el Grupo Interdisciplinario de Tecnología Rural Aplicada (GIRA). El trabajo de Luis en este equipo ha sido introducir un elemento dinámico y sistémico con la finalidad de enriquecer a MESMIS logrando extenderlo más allá de un marco de evaluación hacia una herramienta de educación para la sustentabilidad rural.

El MESMIS interactivo cuenta con 4 capítulos de los cuales 2 son simuladores de sustentabilidad. La idea es lograr que las personas participen de una forma activa a través de un drama en tres actos que les muestre los problemas reales en la toma de decisiones de sustentabilidad combinando simulaciones de software, elementos teatrales y de juegos de rol.

En el primer acto, se muestra una cuenca donde todo era bosque, luego diez familias llegan y desmontan 100 hectáreas con siembra. www.sg.com.mx

Al cabo de décadas con el crecimiento de la comunidad y los diversos apoyos gubernamentales para el campo, la mayoría de ellos implementados sin tener en cuenta los principios de sustentabilidad, las ahora 1000 familias deforestan 4000 hectáreas. El gobierno en respuesta, crea una área protegida y reduce la superficie para las familias, por lo que los campesinos ahora tendrán que recurrir al uso de fertilizantes para poder sobrevivir con el terreno reducido. En el software, los usuarios van viendo simulaciones a través de series de tiempo, dinámicas, puntos de equilibrios y diversos umbrales para ver de que forma este sistema simulado reacciona ante estas estrategias de explotación.

En el segundo acto, aparecen nuevos personajes, los pescadores del lago al final de la cuenca y los dueños comunitarios de una villa eco turista. En esta etapa, se aprende que el uso de fertilizantes para lograr mayor productividad afecta de forma muy clara la ecología del lago, que además es mucho mas difícil restaurar que un sistema terrestre. Mostrando el escenario de la cuenca, los participantes pronto descubren que es imposible encontrar una combinación del manejo de recursos que deje satisfechos a todos los actores. El drama de la utilización de los recursos naturales que tanto nos esta afectado de forma global se manifiesta.

La resolución se obtiene en el tercer acto, donde los participantes aprenden que los diferentes actores deben de ayudar a crear un sistema equilibrado. En el caso particular de la cuenca, la solución del problema proviene de apoyos que las comunidades del lago y la villa eco turista proveen a los productores del campo cuenca arriba, para utilizar combinaciones de árboles que permiten reducir los fertilizantes.

Una de las historias más inspiradoras es la del programador que ayudó a realizarla, un

voluntario llamado Max Pimm; matemático inglés, residente en Barcelona desde hace 5 años, quien se entera del proyecto MESMIS y viaja a México para trabajar como voluntario con el grupo de investigadores de GIRA. Posteriormente se entera del trabajo de Luis con la propuesta de generar modelos interactivos de MESMIS . Inspirado por el potencial del proyecto trabajó por 3 meses en los cuales logró generar todo el sistema. Según sus propias palabras, lo mas importante fue la posibilidad de ver su conocimiento aplicado en un trabajo participativo con gran significado.

Actualmente, el equipo con nuevos voluntarios trabaja en el futuro de MESMIS Interactivo. Las próximas versiones incorporarán desde el diseño del sistema a todos los actores sociales en una plataforma donde se puedan modelar los problemas en un territorio específico, y la gente pueda explorar las consecuencias y entender sus decisiones sobre sus ambientes a través de simulaciones interconectadas en red. Se prevee usen tecnología de vanguardia en la simulación de agentes autónomos y motores de inferencia para las reglas del sistema.

De mi parte, un agradecimiento sincero a Luis García Barrios por su trabajo y ser fuente de inspiración para quien escribe. Para ustedes, amigos lectores, la invitación a conocer, en sus entornos locales, qué trabajos de investigación se están haciendo, para que además de que haya voluntarios que cruzan de otro continente a colaborar, existan también voluntarios mexicanos aportando en tan valiosos esfuerzos.

Si desean obtener datos de como contactar al Dr. Luis Garcia Barrios o dejarnos sus comentarios, pueden checar mas información y fotos del proyecto en tecnonirvana.org » Emilio Osorio

MAY-JUL 2008

61 31

// columna INVITADA

Del Buzón de Sugerencias a la Colaboración Empresarial Enterprise 2.0 Por Tomás Helou El término Web 2.0 cada día se encuentra más arraigado en el vocabulario tecnológico de nuestros días, pero ¿nos hemos cuestionado qué significa realmente? ¿Cuál es la diferencia entre Web 2.0 y Web 1.0? ¿Qué ventajas ofrece a nivel corporativo? La mayoría de los CEOs de las grandes empresas han escuchado hablar sobre las tecnologías Web 2.0.

El uso de Web 1.0 a nivel empresarial, inició tal como la conocemos con la creación de páginas para las empresas, donde detallaban servicios y contenidos; esto lo realizaba un programador de la misma empresa, es decir, la generación de los contenidos recaía en unas cuantas manos y eran esas manos las que decidían lo que debía incluirse en sus sitios, ya sea empresariales o personales. Esto ha ido cambiando, y en la actualidad sitios como You Tube o MySpace, propician la colaboración de los usuarios comunes y corrientes.

¿Qué es Web 2.0 y Enterprise 2.0?

Diferencias y similitudes

Hace algunos meses se dieron a conocer los resultados de una investigación realizada por Forrest Research, dicho sondeo se realizó con 275 compradores de TI, de los cuales 16% de los encuestados dicen que han escuchado acerca del tema, ya que los fabricantes hablan mucho sobre él. En ocasiones el 50% escucha hablar a los proveedores, 20% esporádicamente o casi nulo ha sido su contacto con la Web 2.0: y 11% restante jamás ha recibido comentarios acerca de esta tecnología por parte de sus distribuidores.

Cuando lo social genera ganancias Antes de continuar, debemos de dar un vistazo a lo que realmente significa Web 2.0, el término se refiere a la segunda generación de servicios de Internet, donde la colaboración a los contenidos y las redes sociales son la innovación fundamental. Las principales diferencias entre Web 1.0 y Web 2.0 las enmarcamos de la siguiente manera: La Web Empresarial 2.0 se puede dividir en dos, una cuya finalidad es el uso interno y otra que va hacia el exterior. Ambas tienen mucho que ver con el aspecto comunicacional de la empresa, ya que una se dirige a los clientes y otra a los empleados.

Las características externas o de relaciones públicas de Enterprise 2.0 son aplicables a marketing, relaciones públicas, servicio al

cliente, entre otras. Por lo que tiene un alto impacto en la relación con clientes y socios estratégicos, pues dentro de las funciones que se realizan en el área externa, se abarcan desde investigación de mercados, lanzamiento y promoción de nuevos productos y la más importante: la retroalimentación con los clientes, así como la visión y opinión corporativa ante los temas que evitan información tergiversada dentro de los medios de comunicación.

Tomás Helou es actualmente Director Regional BID de BEA Systems, graduado de la Universidad de Ciencias Empresariales y Sociales (UCES) de Buenos Aires, Argentina con una maestría en Marketing. Anteriormente fue Vicepresidente Internacional de Operaciones de Fuego, Inc. Vicepresidente para Latinoamérica de Business Objects SA, Vicepresidente para Latinoamérica de MRO Software Inc. entre algunos otros cargos, siempre destacando por sus conocimientos sobre Business Process Management BPM, dictando conferencias y participando en diferentes eventos referentes a este tema.

62

MAY-JUL 2008

www.sg.com.mx

Las características internas se enfocan más a lo que se refiere a Gestión del Conocimiento, es decir, está enfocado a las comunicaciones dentro de la empresa, ya sea en toda ella o por células, donde pasan su prueba y posteriormente son usadas en toda la organización. Sus áreas de mayor uso son gestión y planificación estratégica, desarrollo e innovación tecnológica y gestión de proyectos.

Para poder implementar los servicios de Web 2.0 y transformar nuestra compañía en una Enterprise 2.0, debemos tener conocimiento de la manera en cómo se construyen las aplicaciones, ya que usan códigos abiertos a través de API’s (Interfase de Programación de Aplicaciones) y servicios web.

No solamente la integración de clientes, socios y empleados es una ventaja de este tipo de herramientas, pues las aplicaciones son reutilizables y combinables. Las interfaces usadas deben de funcionar como una aplicación tradicional que otorgue al usuario un manejo sencillo y por consecuencia otorgue mayor productividad, haciéndola rentable para las empresas. La arquitectura de estas aplicaciones, debe permitir la utilización de estándares que faciliten el manejo de datos y la comunicación, para que permita la reutilización de módulos, por ejemplo: para la creación de mashups.

Comunitario, pero no inseguro La seguridad tiene un papel decisivo para que las empresas pasen a engrosar las filas de Web 2.0 y sean Enterprise 2.0, ya que piensan que estas herramientas son vulnerables y propician la propagación de virus y troyanos; nada lejos de la realidad, estas son igual de vulnerables que las usadas dentro de la web tradicional, y la solución o prevención para dichos ataques no es algo que salga de lo convencional; un buen sistema preventivo soluciona en gran parte estos ataques, de tal manera que las empresas deben de implementar soluciones de productos de seguridad tradicionales como anti-spyware, anti-phishing, filtrado de URLs y contenido; antivirus, anti-spam y políticas de limpieza centralizadas (para ayudar a reducir el daño).

Seguir una protección de múltiples capas y múltiples vertientes permite la protección total contra las amenazas virtuales.

Beneficios de Enterprise 2.0 Ya que facilita la descentralización de tecnologías, Enterprise 2.0 entrega beneficios a las empresas que la implantan, como: www.sg.com.mx

• Aceleración en el desarrollo del mercado de las empresas que la implementan.

• Reduce costos en infraestructura, ya que su arquitectura es escalable.

• Su intercambio de información es eficiente, lo que se traduce en un mejor enlace con el cliente y mejor producción.

• El ROI se consigue en menor tiempo.

No siempre es bueno cambiar el papel por Bases de Datos Ya que se entendió qué es Enterprise 2.0, debemos cuestionarnos y analizar si es aplicable para nuestra empresa o no, ya que hay ciertos factores antes, los cuales no es recomendable a migrar a este tipo de tipo de tecnologías: •Cuando encontremos a los empleados reacios al uso de estas innovaciones, ya que no se logrará sacarle jugo como es debido.

•Cuando se desconoce lo que es un email o una página web.

•Y quizás los factores más importantes: cuando una sola persona se encarga de tomar las decisiones, sin tomar en cuenta opiniones de gente de menor rango en la empresa y no acepta opiniones del personal a su cargo.

Cuando encontramos alguna de estas trabas, debemos pensar mejor en seguir almacenando nuestra información en papel, y continuar con la estrategia de negocios que se tenía, sin buscar la innovación. Ya que si no conocemos el uso de las nuevas herramientas, éstas por sí solas no solucionarán nada, y por el contrario, no sabemos qué consecuencias negativas puede tener su mal uso o desconocimiento.

Conclusiones Podríamos decir que las organizaciones que adoptan las tecnologías Web 2.0 fortalecen su red interna, de manera que la colaboración se hace similar a un clúster (lugares físicos donde se concentran industrias que unen fuerzas para colaborar entre sí). Así que cualquier empresa que adopte los principios de esta tecnología, da un peso específico a la relación que debe de tener con sus clientes, empleados, socios, etcétera.

Ya que al permitirles colaborar, se desconocen jerarquías con el afán de seguir todos una misma dirección que resulte benéfica para todos los involucrados en el proceso de negocio.

MAY-JUL 2008

// columna

/*cátedra y más*/

Scheme

El Mundo entre Paréntesis Dr. Raúl A. Trejo es profesor investigador del Instituto Tecnológico y de Estudios Superiores de Monterrey, campus Estado de México. Su área de especialidad es la inteligencia artificial, con una particular pasión por la programación. Conoció el paradigma funcional con Basic y Pascal, se graduó en objetos con Eiffel, Ada y Java, y probó la lógica de Prolog. Pero siempre admiró la elegancia de Scheme: (define infinito (λ ( ) ((λ (f) (f f)) (λ (f) (f f))))). El significado de esta expresión se encuentra en: tech-o-potamus.blogspot.com

Imagina que no hay ciclos en tu programación no existen for ni while tan sólo recursión.

Imagina a la gente entre paréntesis…

Este es un fragmento de una canción que me encontré en un foro de discusión para el lenguaje Scheme (en Usenet), junto con la instrucción de que debía cantarse con la melodía de la canción Imagine de John Lennon.

Era mediados de los noventa. Me encontraba aprendiendo y recolectando información sobre lenguajes funcionales en general, y de Scheme en particular para un proyecto educativo de mi campus en el Tec de Monterrey. Esa canción, junto con el contenido exaltado y a veces autocomplaciente de algunas entradas en el foro, formó mi primera impresión del lenguaje, la cual no difería mucho de la opinión de la mayoría de los programadores de los paradigmas clásicos: parecía un lenguaje académico, orientado a estudiantes de posgrado en inteligencia artificial. Sólo que en mi institución estábamos pensando adoptarlo, no como un lenguaje para materias avanzadas, sino para los cursos de computación básica, en lugar de C o el cada vez más popular Java. Las discusiones no se hicieron esperar. Recibimos una gran cantidad de cejas levantadas, pero en mi departamento éramos un pequeño grupo con espíritu visionario y mucha curiosidad; de modo que le dimos luz verde al proyecto. Scheme era un lenguaje definitivamente extraño. Su estructura sintáctica se basaba en expresiones funcionales escritas en notación prefija, rodeada por paréntesis.

De modo que para expresar, por ejemplo: la suma entre dos números, se debía escribir la siguiente sentencia: (+ 5 7) La construcción de expresiones más complejas generaba entonces una cantidad de paréntesis que de inmediato se convirtió en el blanco de las bromas entre profesores y

64

MAY-JUL 2008

alumnos. Sin embargo, descubrí que, enunciando las expresiones de manera funcional, la sintaxis resultaba intuitiva. Así, (raizCuadrada (+ (cuadrado a) (cuadrado b)))

se leía como “la raíz cuadrada de la suma del cuadrado de a con el cuadrado de b”, con los paréntesis definiendo de manera exacta el significado de la expresión. El corazón del lenguaje era la definición de nuevas funciones por medio del operador lambda. De este modo, la función cuadrado se declaraba como: (define cuadrado (λ(x) (* x x)))

1

Fue aquí que decidí que me agradaba el lenguaje. No había tipos de datos (o más bien, para los puristas, sólo hay tipos débiles), lo que permitía escribir funciones interesantes a tan solo horas de conocer el lenguaje. Los números eran verdaderamente polimórficos, permitiendo operaciones entre enteros y reales sin distinción, sin riesgo de overflow.

Existía una única estructura de datos: la lista. Y como estructura de control, se utilizaba la recursividad. Comenzamos a utilizar Scheme en los cursos de computación básica, y para mitad del semestre los alumnos podían resolver problemas típicos de un curso de estructuras de datos. Inventé ejercicios interesantes para ellos, fascinado por la libertad que el lenguaje me daba para enseñar algoritmos y lógica de programación.

Sin embargo, resultó que estábamos adelantados a nuestro tiempo. Algoritmos elegantes o no, los estudiantes extrañaban la deslumbrante interfaz visual de Java. Se preguntaban el por qué aprendían un lenguaje que no existía en la industria. Y definitivamente, odiaban los paréntesis. El escepticismo ganó, dimos por terminado el proyecto y Java ocupó su lugar como el lenguaje reinante en el aula.

Para entonces yo estaba fascinado con el lenguaje. La razón era que, desde su diseño, incorporaba características que facilita-

ban la labor del programador. Por ejemplo, los lenguajes funcionales ya incluían el uso de algoritmos de recolección de basura y la pre-compilación de funciones (el antecedente de la máquina virtual) desde antes de que Java popularizara los conceptos. Además, estaba la alta capacidad de abstracción de estos lenguajes: aprendí, por ejemplo, que podía definir funciones que operaban sobre listas de tamaño infinito, que las funciones mismas no eran diferentes de los tipos de datos básicos, y que podían utilizarse como entradas o salidas de otra función. De modo que lo utilicé en mis proyectos durante mis estudios de doctorado, creando soluciones elegantes que sorprendían a mis compañeros por su simplicidad y corto tiempo de desarrollo. Esto era un triunfo pequeño dado que, mi uso del lenguaje había regresado al ambiente académico.

Diez años después, la industria de desarrollo ha pasado por la programación orientada a objetos, la programación por eventos y la programación orientada a servicios. ¿Cuál es el siguiente paso en la evolución de los lenguajes? Al parecer, es la aparición de lenguajes multi-paradigma, que incorporan finalmente el paradigma funcional, el orientado a objetos y el imperativo. Me parece interesante que la comunidad en general esté adoptando estos lenguajes, y que finalmente el paradigma funcional pudiera salir del ámbito académico. Python es uno de estos lenguajes, con una popularidad en aumento. La plataforma .NET contará con F#, y para el desarrollo web se tiene Perl 6. Todos estos lenguajes están basados en Haskell, un sucesor de Scheme.

Me siento optimista de que puedo volver a programar en un lenguaje funcional. Y esta vez, con una sintaxis menos extraña: Haskell no tiene paréntesis. » Dr. Raúl A. Trejo 1

Para el lector curioso, esta expresión se lee como “define

cuadrado como la función que recibe el parámetro x, y regresa la multiplicación de x por x”.

www.sg.com.mx

No. 20

www.sg.com.mx

SG SOFTWARE GURU - CONOCIMIENTO EN PRﾃ，TICA

Mayo-Julio 2008