SG20 (Mayo-Julio 2008)

Software Guru CONOCIMIENTO EN PRÁCTICA

w

ww

.sg.

com

.mx

SG

SO

FT

WA

RE

GU

RU

- C

ON

OC

IMIE

NT

O E

N P

RÁ

CT

ICA

May

o-Ju

lio 2

00

8

No.20 • Mayo - Julio 2008 • www.sg.com.mx

[ Herramientas ] Visual Studio 2008Noticias • Eventos • Fundamentos • UML • Infraestructura • Tecnología

No.

20

• Data Warehouse Multidimensional

• Ruby on Rails

• Documentación de Arquitecturas

México. $65 MXN

[ ENTREVISTAS ]

Terry QuatraniJon "maddog" HallJohn CrupiKey speakers SG'08

MAY-JUL 2008 www.sg.com.mx

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Coordinación EditorialSonia Sánchez

Arte y DiseñoGrisel Otero

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.

ColaboradoresRigoberto 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 RPDafne Vidal

Circulación y Suscripciones Daniel Velázquez

AdministraciónAraceli Torres

[email protected]

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

directorio

Editorial

// CONTENIDO

02

Remontarnos a la época del Renacimien-to 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 lengua-jes de programación están retomando lo mejor de aquellos que sirvieron como base para los lenguajes modernos.

Este movimiento es similar al Renacimien-to 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.

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 ar-quitecturas, 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.

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

tentes al anterior congreso es junio. Dada esta preferencia, este año SG’08 Conferen-cia 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 ponen-cias y talleres ya la pueden consultar en el sitio web oficial: www.sg.com.mx/sg08

El equipo de SG está con miles de ocupa-ciones 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 esta ocasión tendremos la grata presen-cia 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!

» Equipo Editorial

MAY-JUL 2008www.sg.com.mx

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

Prueba de Software 36por Luis Vinicio León

Tendencias en Software 60por Luis Daniel Soto

Tierra Libre 61 por Emilio Osorio

Columna Invitada 62 por Tomás Helou

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

24

Productos

LO QUE VIENE 12JBuilder 2008, WebSphere sMash, Mingle 2.0 y Quest para Sharepoint. HERRAMIENTAS 14Visual Studio 2008 Herramientasde análisis y medición de código.

Prácticas

ARQUITECTURA 38Más allá del manual de usuarioConozcamos los diferentes tipos dedocumentación que debe considerarun arquitecto de software.

PROGRAMACIÓN 42Aprendiendo Ruby y RailsEn la tercera parte del tutorial, se hablarásobre el framework de Rails.

PROCESOS 46CMMI-SVCPara todas aquellas empresas dedicadasa los servicios, este nuevo modelo les seráde gran ayuda en su desempeño.

UML 48SysMLCon esta notación, el modelado de lossistemas se amplía al considerar nosolamente los componentes tipo Software.

PM CORNER 50El valor de las oficinas de proyectosNotemos el valor del lugar en el quese desarrolla toda la planeación de unproyecto en curso.

EN PORTADA

Lenguajes de Programación Conozcamos los orígenes de los nuevos paradigmas dentro de este campo.

Especial 18 Data Warehouse Multidimensional.

contenido may-jul 2008

03

En Cada Número

NOTICIAS y EVENTOS 04

FUNDAMENTOS 54

// CONTENIDO

EntrevistasTerry QuatraniJon “maddog“ HallJohn Crupi

INFRAESTRUCTURA 56

GADGETS 58


// NOTICIAS

04

IMPACT 2008La ciudad de Las Vegas fue sede de Impact 2008, la confe-rencia anual que IBM realiza para usuarios de Websphere a la cual asistieron más de 6 mil personas de todo el mun-do. El tema central a lo largo del evento fue SOA, e IBM dejó claro su liderazgo en este campo no solo en térmi-nos 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 empre-sas 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?” finalmen-te están quedado atrás, y por fin estamos entrando en el “¿Cómo aplicar SOA de forma efectiva?”.

Estamos con los HéroesBajo 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 dis-tintas 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úme-ro 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 dis-tribuidas, 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.0La 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. En-tre las novedades está la creación de un nuevo programa denominado PRO-MEDIA, el cual está dirigido a impulsar el sector de los medios interactivos.

De acuerdo con Sergio Carrera, Director General de Comercio Interior y Eco-nomí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 men-talidad es primero generar la gente para que así lleguen las oportunidades.


Conferencia Anual deAdministración deServicios de TIEn 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 intercam-biar ideas, aprender e integrarse en un medio ejecutivo. Las sesiones se dividieron en diferentes sectores: Ad-ministració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 certifi-cación en ISO 20000 en Latinoamé-rica, este honor lo tuvo la empresa colombiana Compuredes.

Mexico FirstCANIETI y ANIEI, con el apoyo de Secre-taría de Economía han creado la iniciati-va 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 reco-nocido globalmente como una excelen-te opción para satisfacer las necesida-des de la industria de TI.

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.

Tendencias 2008El 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 brin-dó a los asistentes la oportunidad de participar en seis talleres de bench-marking para identificar oportunidades e impulsar el desempeño de sus organizaciones.

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

// NOTICIAS

05

Gartner Enterprise Integration SummitAl 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 in-tegració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éxi-co 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.

Empresas recientemente evaluadas en CMMI:Empresa Evaluación Fecha Lead Appraiser Sinersys CMMI Nivel 3 marzo 2008 Alfredo Calvo, IteraVentus CMMI Nivel 3 marzo 2008 José Luis Iparraguirre, IteraIDS CMMI Nivel 3 marzo 2008 Ernesto R. Corona, Liveware


Infor Day México 2008Infor realizó los pasados 14 y 15 de febrero, en las instalacio-nes 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.

Las sesiones estuvieron enfocadas en las soluciones de nego-cios para varias industrias, incluyendo manufactura discreta, manufactura de proceso, minoristas, servicios y más. Los asis-tentes tuvieron la oportunidad de aprender las mejores prácti-cas del medio a través de pláticas sobre la dirección de produc-tos, casos de estudio de implementaciones innovadoras en voz directa de los clientes de Infor así como a las sesiones educati-vas enfocadas en las soluciones que ofrece esta compañía.

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

Circuito Tecnológico 2008Secretaría de Economía, mediante el PROSOFT, dió inicio al Cir-cuito 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.

El 4 de marzo dió inicio con el seminario “Generación de Demanda”, dirigido a desarrolladores y distribuidores de tecnología, revi-sando temas como el rol del gerente de marketing y experien-cias 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

0606

// EvENTOS

14 al 15 de Mayo 2008IDC WebSec Conference 2008Centro Banamex, Cd. de MéxicoInfo: www.idc-eventos.com

14 al 16 de Mayo 2008Expo Data Center 2008Salón Olmeca, WTC, Cd. de MéxicoInfo: www.expodatacenter.com/expo2008

17 de Mayo 2008BugCON Security ConferencesInstituto Politécnico Nacional, Cd. De MéxicoInfo: www.zonartm.org/BugCON

20 al 21 de Mayo 2008Information SecurityWTC, Cd. de MéxicoInfo: www.informationsecurity.com.mx

21 al 23 de Mayo 2008Sun Tech Days 2008Centro Banamex, Cd. de MéxicoInfo: www.suntechdays.com.mx

22 de Mayo 2008PRONET Heroes CoatzacoalcosSalón de la CANACO de Coatzacoalcos, VeracruzInfo: www.microsoft.com/latam/estamosconlosheroes

18 al 19 de Junio 2008Gartner 4ª Annual Outsourcing SummitCentro Banamex, Cd. de MéxicoInfo: www.gartner.com/mx/outsourcing

21 al 24 de Junio 2008SG’08 Conferencia y Expo /PMTOUR México 2008Hotel Sheraton Centro HistóricoInfo: www.sg.com.mx/sg08

24 al 25 de Junio 2008CutterMastering Personal Agility for ExecutivesHotel JW Marritott, Cd. de MéxicoInfo: www.cutter.com.mx


MAY-JUL 2008 www.sg.com.mx08

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

/*TEJIENDO NUESTRA RED*/// COLUMNA

El 8 de junio de 1958, gracias a las gestio-nes del Ing. Sergio Beltrán, se inauguró el Centro de Cálculo Electrónico en la Facultad de Ciencias, UNAM. Su primera computado-ra fue la IBM-650 de bulbos, con memoria de tambor magnético y con lectora y perfo-radora de tarjetas. Los primeros expertos en manejarla fueron José Luís Otalengo y Artemio Taboada, mientras que Manuel Or-tega fue su primer operador. Estos datos los tomé del artículo: “Primera Década de la Computación en México: 1958-1968 Pri-mera 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 tene-mos el programa PROSOFT, que tiene por objetivo fortalecer la industria de software en México. Como todos sabemos, para lo-grar este objetivo se requiere de una cola-boració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 suficien-te 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 docto-res 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ó

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.

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 si-guiente 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 concer-tado y una adecuada inversión por parte de las autoridades y de las instituciones involu-cradas, 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 inves-tigació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 presen-tar 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 lo-grado 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 in-vestigadores 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 pro-yectos 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 rega-dos 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 si-tuació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 Tecno-logías de Información como un área priori-taria 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 recono-cer 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).


/*TEJIENDO NUESTRA RED*/// COLUMNA

“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 investi-gadores y grupos de investigación de pri-mera 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 investi-gadores 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 in-vestigadores en el país, es necesario contar con grupos suficientemente grandes, com-puestos por investigadores y estudiantes de posgrado, que colaboren durante un tiempo razonable y con adecuada especialización para alcanzar niveles de continuidad, pro-ducció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á fomen-tarse también la formación y consolidación de grupos multinstitucionales y la incorpo-ración a éstos de investigadores que se en-cuentren aislados temática o institucional-mente. Sin grupos estables y productivos, las capacidades de formación y transferen-cia de tecnología son disfuncionales.

4. Reordenar los mecanismos de financia-miento 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 inves-

tigación ni para los propios investigadores. Es deseable instituir mecanismos de finan-ciamiento 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, eva-luación y seguimiento, así como incentivos que, en conjunto, impongan exigencias sen-satas y objetivas a investigadores e institu-ciones: den pie a una evaluación pertinente y oportuna y constituyan, en suma, instru-mentos para hacer eficiente la inversión. Es indispensable contar con mecanismos de eva-luación y estímulos adecuados al dinamis-mo 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 aten-ció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 tecno-logí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 forta-lecer la intervención de estos investigadores en los distintos órganos de evaluación de la actividad científica del país (como el CONA-CYT 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 investiga-ción y desarrollo en ciencias de la computa-ción y Tecnologías de Información.

6. Establecer una estrategia de vinculación internacional. Es necesario fomentar la par-ticipació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 esta-blezcan relaciones y alianzas que permitan colaboración en distintos tipos de actividad con contrapartes de otros países. Estas co-laboraciones deberán considerar también aspectos de formación que incluyan becas, visitas, estancias, dirección compartida de tesis doctorales, cursos y proyectos bina-cionales y multinacionales. Será necesario diseñar estrategias específicas para impul-sar las relaciones con los países con los que hay una historia exitosa de colaboración o con los que es importante tenerla, para for-talecer 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 asigna-turas 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 gobier-no, 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 investi-gación en computación tiene un impacto di-recto 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 tradu-ce 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

09


Calidadel CaMino haCia la RenovaCión

/*MEJORA CONTINUA*/// COLUMNA

En 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 marineroUna iniciativa de mejora continua solamente se puede implementar cuan-do 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 absolu-tamente 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 con-tinua, y apoyarse en ellos para implementaciones. A veces lo mejor es reducir el alcance de lo que queremos hacer para acelerar la implemen-tació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 tra-bajo, 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 NavaronEn los años setenta salió en los cines una película llamada Los Caño-nes 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 orga-nización que trataba de hacer un cambio y los participantes, al ser auditados, mencionaron que necesitaban capacitación para apren-der; 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 templa-tes, 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”.

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.

Tautologías y palabras mágicasCuántas veces hemos escuchado cosas como “el entrenamiento no es suficiente, se requiere gente con experiencia”, “somos una com-pañía que cree en la más alta calidad”. Muchas veces los intentos de mejorar procesos se detienen cuando se nos colocan palabras de-masiado 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 atenderteLas 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 entende-rá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 compromete-mos a un proyecto, los demás quedan desatendidos; hay que buscar el balance. También debemos tener mucho cuidado de no absorber-nos por completo en las tareas diarias y perder el objetivo.

Demasiado entrenamientoAl 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 asig-nados 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 im-portante 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 en-trenamiento 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



/* LO QUE VIENE*/// PRODUCTOS

JBuilder 2008Llegan los Application Factories

CodeGear anunció la disponibilidad de la versión 2008 de JBuil-der, la cual incorpora soporte para una estrategia de desarrollo denominada Application Factories. Este concepto es bastante in-teresante. Básicamente, parte del entendimiento de que la ma-yorí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 Applica-tion Factories es capturar estas modificaciones o ajustes a códi-go 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.

Desde su separación de Borland, CodeGear ha buscado distinguir-se 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.codegear.com

Websphere sMashIBM le entra a los mashups

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 incuba-ción denominado Project Zero, el cual seguirá disponible de forma gratuita para desarrolladores.

Junto con sMash también se lanzará el IBM Mashup Cen-ter, que es un repositorio de mashups donde los usua-rios 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 aplica-ciones 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.

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

QuestNuevas Herramientas para Sharepoint

Sharepoint ha cobrado gran popularidad en los últimos años. De acuerdo con Gartner, el 80% de las organiza-ciones utilizarán Sharepoint para el año 2010. Sin embar-go, 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.

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.

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

Thought WorksMingle

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 in-ternacionalmente 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 geo-gráficamente.

Recientemente fue liberada la versión 2.0 de Mingle, y entre sus capacidades más llamativas están el mane-jo 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 herra-mienta para colaborar y organizar el proyecto, Mingle es una excelente opción.

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

MAY-JUL 2008www.sg.com.mx PUBLICIDAD


Análisis y Medición de Código Administradocon Visual Studio® 2008 Caso database CoMMandeR y sQl buddy

Por Rigoberto Calleja Cervantes y Rajah James

14

/*HERRAMIENTAS*/// PRODUCTOS

Herramientas de análisis de códigoLas 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, es-tablecidas en los lineamientos de diseño del .NET Framework. Estas herramientas representan las verificaciones que se llevan a cabo du-rante 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 poste-riormente 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 eje-cutado; de esta manera solamente se podrá proteger una pieza de código. Si ésta pasó exitosamente aquél.

Herramientas de medición de códigoLas herramientas de medición son empleadas para generar métri-cas 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 desarrolla-dores pueden entender qué tipos y/o métodos deben ser escritos

En este trabajo se presentan los resultados de una prueba rea-lizada 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.

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 inclu-ye tipos primitivos o incorporados, tales como int32, object o string, y cuando es mayor, aumenta la probabilidad que los cambios reali-zados en otros tipos se propaguen al elemento que está siendo ana-lizado. 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 ra-mas (tales como switch, foreach y ciclos for) más uno. Esta métrica ge-neralmente 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 faci-lidad 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 interme-dio, 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 SuiteDespué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 vir-tud 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 embar-go, 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 propor-cionó 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 ([email protected]) 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.


/*HERRAMIENTAS*/// PRODUCTOS

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 archi-vos con extensión .MDX era un error trivial, ya que esta clase de ar-chivos 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.

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.Figura 1. Opciones de instalación de la Visual Studio Team Suite.

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

Database CommanderDespués de descargar el código fuente del DBCommander, en-contramos varios problemas. En virtud de que el código fuente delDBcommander 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 Figura 2. Métricas del código del Database Commander.


/*HERRAMIENTAS*///PRODUCTOS

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 elimina-mos el proyecto de instalación ya que no era de interés. Una vez he-cho 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 exclusiva-mente 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 in-dica 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 tie-ne 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.

Rajah James ([email protected]) 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.

Cuando miramos las métricas en Visual Studio® 2008, se nos difi-cultó un poco entender exactamente qué significaban, partiendo del hecho de que se presentan como un árbol, en donde el nivel del pro-yecto 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 toman-do 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 ensambla-do 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 adver-tencia, lo que involucró agregar la palabra mal escrita al diccionario personalizado contra el cual se realizan las verificaciones. El diccio-nario 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.

SQL BuddyTal 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 ad-vertencias. Esa ventana incluye la descripción de la alerta, el archivo y el número de línea donde está localizada.

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. Con-sideramos 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 no-menclatura de los lineamientos de diseño del .NET Framework.Figura 3. Reporte de conversión del código de SQL Buddy.


/*HERRAMIENTAS*///PRODUCTOS

Las herramientas de análisis de código inclu-yen información detallada acerca de cada ad-vertencia 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 ge-nere además de, una descripción de cuándo es conveniente suprimir una advertencia.

Para mirar esta información hicimos clic de-recho 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 descu-brimos 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 deta-lladas de estas advertencias y el código fuen-te, 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.

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]

ConclusiónEstas herramientas son intuitivas y fá-ciles de usar. La realización de la ma-yoría de las operaciones básicas tales como iniciar un análisis, mirar sus re-sultados, encontrar el código que tie-ne el problema y corregirlo, fue sen-cilla. 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ó te-ner un panorama claro acerca del nivel de facilidad de mantenimiento del códi-go fuente, a pesar de que no estábamos familiarizados con él. Adicionalmente, estas herramientas no requieren prác-ticamente ningún tipo de configura-ción. Asimismo la conversión de los

proyectos fue automática. Encontra-mos y corregimos advertencias sobre reglas de nomenclatura en los espa-cios 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 pue-den procesar código producido en otros lenguajes predominantes tales como C++ o Java. Las herramientas de Visual Studio® 2008 están empotra-das en el entorno de Visual Studio® la cual es un producto grande y comple-jo que en ocasiones puede ser difícil de instalar. Llevar a cabo la selección de un subconjunto de alertas relevan-tes 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 produ-ce. Asimismo, no existe la noción de severidad dentro de las advertencias obtenidas que pueda ayudar al desa-rrollador 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 depen-dencia de cuáles atributos de calidad estés tratando de dar seguimiento y mejorar en su proyecto, la suite puede ser de mucha utilidad.


El presente artículo pretende guiar al lector en las consideraciones que tiene que seguir para migrar de Data Warehouse como una so-lución para el análisis de la información financiera, el ejemplo esta referido para una empresa de Telecomunicaciones dedicada a ofre-cer equipo y servicios de telefonía celular.

~: Antecedentes :~

el alMaCenaMiento de datos en las eMpResas

Por Ernesto Ulianov Reyes Romero

Consideraciones Para Migrar un Modelode Data Warehouse Multidimensional

18 MAY-JUL 2008MAY-JUL 2008 www.sg.com.mx 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 basa-das en capturar y retener a los clientes más rentables, siendo ellos la mayoría de las veces los de mayor consumo. Las es-trategias tradicionales de ventas y comercialización son desa-fiadas 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, trans-misió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 informa-ción para su análisis.4. Se requiere de mejores indicadores que le den infor-mació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 Proce-dimientos 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 indica-dores que evalúan para el análisis financiero.6. Su crecimiento requiere de un modelo más acorde al vo-lumen de información que se está manejando, por lo que se cuestiona si el modelo actual y la plataforma actual sopor-tarán el crecimiento de toda la información que proporcionan las diferentes áreas de la compañía.

Por los motivos anteriores, se deben plantear las siguientes interro-gantes: ¿El modelo satisface la necesidad creciente del manejo de información que se tiene actualmente? ¿Se tiene una plataforma acor-de a las necesidades actuales del Data Warehouse? ¿Se tiene una efi-ciente 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 plata-forma tecnológica que soporte la estructura que se tiene actual-mente y que pueda crecer, ocupando herramientas orientadas a la consulta de grandes volúmenes de información histórica, pro-cesamiento 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 infor-mación diaria así como su extracción para generar niveles de agre-gació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 pro-ductos 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 in-formación y análisis definidos por la empresa de la industria de teleco-municaciones.• 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 com-portamiento 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 excep-ción, especialmente dada la feroz competencia que se está dando en este segmento.

19MAY-JUL 2008MAY-JUL 2008 www.sg.com.mx www.sg.com.mx


En primera instancia lo que se pretende es mejorar el modelo del Data Warehouse para migrar el contenido de la información utili-zando uno nuevo que permita tener el cre-cimiento de los datos que requiere la com-pañí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 ma-nera 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 merca-do, redundado en mejoras tecnológicas de comunicación para ofrecer mejores produc-tos 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 im-pacta 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 par-ticularidades de la información financiera que es utilizada por la compañía de Teleco-municaciones, es la aportación tecnológica que se ofrece para optimizar el análisis fi-nanciero de la compañía.

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 propiamen-te 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 di-mensionar el detalle de toda la información financiera que se tenía cargada.

Se pensó en considerar la plataforma tec-noló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ús-queda son más ágiles y por tener la capa-cidad de hacer modificaciones cuando la Base de Datos esta operando.

En la Base de Datos SQL Server por cada tipo de información se tiene una base de da-tos, 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 informa-ción se necesitaba obtener del detalle el nuevo consolidado, que por necesidades de la empresa, se ocupan y se van almacenan-do 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 si-guientes 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 tem-poral 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 des-criptivo del modelo, en donde la zona mar-cada 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 implanta-ción a partir de un modelo que establece la relación entre los clientes y el negocio y po-der realizar el análisis del comportamiento, permitirá representar y analizar de manera homogénea a los clientes, cuentas y las ter-minales de la compañía, ya se traten de Cor-poraciones, PyME’s o personas físicas.

Aunque pueda definirse de manera concep-tual la representación de los clientes de los distintos tipos de servicios ofrecidos, la im-plantació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).


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.

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

MAY-JUL 2008www.sg.com.mx 21

- 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 lla-mada 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 vo-lúmenes de información. Estos programas permitirán la validación, generación de re-sú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 contem-plar 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 indicado-res 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 permi-tir a los analistas conocer la situación detalla-da 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 com-portamiento, suscriptores a contactar en ini-ciativas 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 de-finició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 em-pleados fácilmente por parte de los analis-tas de la compañía. Además es el modelo de acceso que será instrumentado empleando las facilidades ofrecidas por una herramien-ta que permita tener el acceso más ágil y eficiente, donde se deberá proveer en forma oportuna la semántica correspondiente.

• 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. Ade-má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 im-portante 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 prime-ro desde un punto de vista abstracto y simpli-ficado 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 herramien-tas 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 su-biendo de nivel, hacia la Fuente de Datos, Construcción del Data Warehouse, Construc-ció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 impor-tantes: la de Refinamiento, Reingeniería y después de obtener el modelo de Data Warehouse otra fase de Refinamiento y Re-ingeniería, lo que no permite que se haga un modelo en poco tiempo, ya que requie-re 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 Alma-cenamiento, Administradores de Seguridad, Administración de Distribución, Administra-ció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 Agrega-ciones, por tal razón y debido a que el pro-yecto tiene un tiempo programado de tres meses se omite los puntos relacionados con la construcción.

Referencias[ Berthold, M.; Hand, D.J. Intelligent Data Analysis, An In-troduction. Springer 1999 ]

[ Corey, Michael J., Abbey, Michael. Oracle Data Ware-housing, Oracle Press. Osborne/Mc Graw-Hill. 1997 ]

[ Edwards, John. Building the Right Data Mart. Oracle Ma-gazine. 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 ware-housing. Prentice Hall Hispanoamérica, 1996, México ]

[ Inmon, W.H. et al. Managing the data warehouse, John Wiley, 1997 ]

Conclusión

Con lo antes propuesto para iniciar cualquier proyecto de Data Ware-house 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 me-todología. Se establecen los principios en los que se debe elaborar el diseño, presentando la propuesta a seguir.

MAY-JUL 2008MAY-JUL 2008 www.sg.com.mx www.sg.com.mx




// ENTREvISTA

Key Speakers de SG’08Conoce a los

John

Cru

pi

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

John es CTO en JackBe Corporation, y es reconocido como una de las mentes más influyentes en el área de cómputo empre-sarial 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 Soft-ware Development. Es co-autor del afamado libro “Core J2EE Patterns” y es un conferencista frecuente en congresos interna-cionales tales como JavaOne, AjaxWorld y SOAWorld.

Los departamentos de TI se han enfocado en generar almacenes de datos y normalizar/denormalizar grandes cantidades de infor-mació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 transaccio-nales. 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 ten-drá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

IBM recientemente formalizó su entrada al espacio de enterprise mashups. ¿Qué sig-nifica 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. Ade-má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/dis-puesta a hacer mashups?Los usuarios de negocio han estado hacien-do mashups desde hace más de 15 años; lo llaman Excel. El problema es que normal-mente dedican la mayoría de su tiempo a reunir, copiar, pegar y unir los datos que ne-cesitan para poder tomar decisiones. ¿Por qué realizan todo este esfuerzo? Porque no tienen opción. Los datos se encuentran en-cerrados en su ERP, aplicaciones internas y sistemas de información empresarial.

instalar algo simplemente para obtener nue-vos 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 disfru-to 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 traba-jado en una empresa tan grande como Sun?Es muy divertido, pero debes tener nervios de acero. Existen muchos factores desco-nocidos, pero tienes una visión que puede moldear el futuro. Da una enorme satisfac-ción cuando funciona.

¿Algunas palabras de sabiduría para nues-tros lectores?Empiecen a considerar los enterprise mash-ups 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.


¿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 in-volucrados, entender requerimientos, dirigir la implementación, entender el impacto del cambio, y asegurar que los recursos de infraestructura sean utilizados adecuadamente.

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 fre-cuente en la revista Dr. Dobbs Journal.

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!

Llevamos varios años sin llegar a un consenso sobre qué lenguaje/notación usar para modelar procesos de negocio. ¿Cuál es tu opi-nió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 pue-de ser de gran utilidad. Por ejemplo, actualmente existen herra-mientas 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.

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

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

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 modela-do. De hecho, creo que a la fecha ninguna herramienta soporta UML 2 por completo.

Aun así, cada vez hay más organizaciones que utilizan UML 2 y le en-cuentran 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 res-pecto. Tengo varios clientes que actualmente realizan transformacio-nes de MDA bastante sofisticadas. De hecho, en la arquitectura de Ra-tional 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-

Terry Quatrani


1626

// ENTREvISTA

Jon

“mad

dog”

Hal

l

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 de-bidamente protegidos.

Ellos le pidieron a Marcelo que los ayudara a resolver esto, así que creó Hackerteen, que es un programa de educación virtual, don-de 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, ade-má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 amiga-bles con el ambiente y con el usuario. La tec-nologí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

piloto de esto en Costa Rica, con un cliente llamado Datatell.

¿Cómo aporta Linux al “cómputo verde”?Linux tiene varias capacidades que contri-buyen al cómputo verde, tales como apagar discos y bancos de memoria cuando no es-tán en uso. Linux también es bastante fuer-te 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 refie-ro 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 Li-nuxMCE que están teniendo un gran impac-to tanto en las empresas como los hogares.

A pesar de los avances de Linux en otras áreas, en el desktop sigue con una parti-cipació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 escri-torio era básicamente un servidor de X Win-dows y un administrador de ventanas. Ahora tenemos un desktop completo con muchas aplicaciones sofisticadas. En ese entonces, los vendedores de computadoras ni de locu-ra hubieran vendido máquinas con Linux. En cambio, hoy muchas empresas venden Linux preinstalado. De hecho, en algunas compu-tadoras como la Eee PC es el default.

Lo que quiero decir es que seguimos avan-zando, y aunque todavía estamos lejos de ser el sistema dominante en el desktop, estamos muy cerca de ser un jugador im-portante (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 pro-barlo en sus computadoras.

Únanse a SoftwareFreedomDay.org y prego-nen sobre el software libre. Recuerden de-cirles que es “libre como en libertad”, y que no deberían ser esclavos de los vendedores de software propietario. Carpe Diem!.

Jon “maddog” Hall es Director Ejecutivo de Linux Interna-tional, 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.


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, ar-tículos y foros relacionados con desarrollo de software, nos encon-tramos 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 diver-sidad de lenguajes, desde Cobol hasta algo llamado C#, y continua-mente 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 mante-nerse como un lenguaje sólido, estable, con poca innovación, y por otro lado quienes consideran que debe incorporar nuevas caracte-rí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...



delos



o aprendí a programar usando una micro-computadora 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 secunda-rio, y venía de fábrica con un intérprete de Sin-clair BASIC. Este dialecto de Basic usaba núme-ros de línea frente a cada enunciado. Había que usar la instrucción GOTO para realizar repeti-ciones, 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 pro-gramación basado en la utilización de funciones matemáticas. El cálculo lambda, desarrolla-do 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 len-guajes funcionales.

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

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

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 conven-cionales, 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 des-conocido, pero una vez que se conoce, este ya no cambia. En contraste, en los lenguajes impe-rativos 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 refe-rencialmente transparente si puede ser rempla-zada por su valor, pero sin alterar los resultados producidos por el programa. La transparencia referencial es importante porque permite al pro-gramador, 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 im-portantes conceptos que han sido posterior-

mente incorporados en muchos otros lenguajes. Uno de los más notables es el referente a la re-colecció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, ocu-rriendo 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 gene-ró Java en la última década, hoy en día práctica-mente todos los lenguajes considerados “moder-nos” incorporan recolección de basura.

Otros conceptos importantes en que los lengua-jes funcionales han sido pioneros incluyen: fun-ciones 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 compila-ció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 Gro-ovy. Dada su naturaleza, los lenguajes dinámicos



son normalmente interpretados, aunque sí exis-ten compiladores para algunos de ellos.

Recientemente mucha gente ha tomado interés en los lenguajes dinámicos. Una de las principa-les 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 re-quiera 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 algu-nos inconvenientes. No es inusual que un pro-grama 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 len-guaje convencional compilado. Para cierto tipo de aplicaciones esto puede ser irrelevante.

Por ejemplo, imaginemos que tengo un cierto problema que debo resolver escribiendo un pro-grama. 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 tar-darí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.

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, segu-ramente 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 progra-mació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í ocu-rre, entonces el beneficio de usar un lenguaje más rápido es prácticamente imperceptible.

Otra desventaja que algunas personas han seña-lado con los lenguajes dinámicos es el relativa-mente 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 ex-plícitas de tipos, y esto complica significativa-mente cosas como la facilidad de autocompletar código y la refactorización.

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

del sistema operativo, o elementos de una in-terfaz 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 equi-pos 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, facili-tar 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 nue-vo hardware correría su programa, sin modifica-ción alguna, de manera más rápida (por eso el término almuerzo gratis). Sin embargo, las ve-locidades de los microprocesadores ya no se han estado incrementado como estábamos acostum-brados. La Ley de Moore establece que el núme-ro de transistores que se pueden retacar en un solo chip se duplica aproximadamente cada 18 meses. Esto típicamente se traducía en CPUs co-rriendo a más megahertz cada año. Sin embargo,



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 cum-pla, 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ási-camente una unidad de procesamiento, que incluye re-gistros, 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 ha-blando 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 di-señ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 reque-rido la gente de nichos muy específicos que utilizan su-percomputadoras, grids y clusters; 2) escribir programas paralelos correctos es considerablemente más difícil que escribir programas secuenciales, al menos usando la ma-yorí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 ca-rrera (los hilos intentan modificar el mismo contenido de memoria al mismo tiempo) se debe usar algún meca-nismo 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 exten-didos con bibliotecas y/o directivas especiales que simpli-fican 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 inte-ractuar con las primitivas de bajo nivel asociadas normal-mente con los hilos. El lenguaje Erlang soporta este mode-lo 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 re-presentativo 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 esta-ban acostumbrados. La programación orientada a obje-tos comenzó a tomarse en serio en la industria hasta que los lenguajes convencionales fueron modificados para so-portar 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 es-tilo o paradigma de programación sigue siendo la nor-ma 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, concurren-te y distribuido. El lenguaje Oz soporta programación lógica, funcional, orientada a objetos, basada en restric-ciones, 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 programa-dores 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



Parece que la época del programador mono-lin-güista está llegando a su fin. Por ejemplo, un de-sarrollador 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 programa-ción en particular, y un lenguaje de plantillas para la generación de contenido dinámico. ¿Por qué se requieren tantos lenguajes para desarro-llar una aplicación de este tipo? Porque cada len-guaje tiene una función particular que los otros simplemente no pueden hacer, o sí lo pueden hacer pero de manera menos conveniente.

En la actualidad, las plataformas Java y .NET reflejan también la importancia de poder com-binar 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 orien-tado a objetos y funcional, soporta el modelo de concurrencia por paso de mensajes. Usa un sistema de tipos estáticos pero con inferencia au-tomática. Puede usarse como lenguaje de script e interactuar con código de Java existente.

JRuby, Jython y Groovy son lenguajes dinámi-cos 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 vir-tual y su extensa biblioteca) y no tanto el lengua-je 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 lengua-je C, y todo se une con scripts y aplicaciones es-critas 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.

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 prin-cipio para soportar múltiples lenguajes y sus in-teracciones. Aunque C# es el caballito de batalla del CLI, existen decenas de lenguajes diseñados para esta plataforma. Por ejemplo, F# es un len-guaje 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 progra-mació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.

los que son el objeto de las quejas de todo mundo

Sólo hay dos tipos de lenguajes de programación:

/ Bjarne Stroustrup, autor de C++

y los que nadie usa.


MAY-JUL 2008 www.sg.com.mxwww.sg.com.mx28

urante muchos años los científicos de la computación han buscado diferentes paradig-mas que permitan una mejor y más efectiva comunicación entre el programador y la com-putadora. 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 Tu-ring formalizó matemáticamente el concepto de algoritmo, que es la base de la resolución de pro-blemas 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 pri-mero se describe el mundo (dominio) mediante la definición de ciertos tipos (clases), y luego se resuelve el problema deseado mediante la in-teracció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:

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

La figura 1, muestra una clasificación de lengua-jes de programación, de acuerdo a su paradigma.Figura 1. Clasificación de los lenguajes.

Haciendo una analogía con los lenguajes huma-nos, sabemos que la lengua española tiene fuer-tes 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ís-ticas 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 ca-pacidades de otra, generando lo que podríamos lla-mar 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.

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.

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

programador dotándolo de diferentes armas para resolver problemas de una manera más efectiva. Es-tos 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 ra-zón que cuando a una variable se le asigna un va-lor, é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 ex-tensivo 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-

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

Más allá de los Objetos

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. [email protected]



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

(\pintNum -> pintNum * pintNum)

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

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 expre-sió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 ConvertirMone-da regresará una función (específicamente un delegado) que a su vez será invocada para calcu-lar el tipo de cambio.

public static Func<int,int> ConvertirMoneda(string pstrMoneda) { return (int pintCantidad) => { return pstrMoneda == “EURO” ? pintCantidad * 15 : pintCantidad * 10;} };

Invocaciónvar 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 com-pilador asigna automáticamente el tipo de dato correcto al resultado de una función sin necesi-dad de que se especifique explícitamente.

Haskell:t “Hola”

Resultado:“Hola” :: String

Los lenguajes fuertemente tipificados son impor-tantes por la seguridad al disminuir errores en tiem-po de ejecución. Así, la inferencia de tipos conserva la fuerte tipificación del dato pero aumenta la flexi-bilidad y capacidad para generar polimorfismo.

~:Recursión como manejadorde 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 sumato-ria de los números del 1 al 100.

sum[1..100]

En C# podríamos implementar nuestro clási-co 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 fun-cional 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 infi-nitas 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 transparen-cia referencial, la cual se refiere a que una fun-ció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.

35

ConclusiónLos paradigmas alternos de programación representan una oportunidad para acercar-nos 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 orde-nado de las herramientas y tecnologías.

Por ejemplo, en el caso de .NET, estas nue-vas características del lenguaje son el meca-nismo 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 ca-rreras 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.

MAY-JUL 2008MAY-JUL 2008 www.sg.com.mx www.sg.com.mx

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

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

Resultado:System.String


// COLUMNA /*PRUEBA DE SOFTWARE*/

Se puede percibir que en los últimos años la industria de software mexicana ha estado invirtiendo en el trabajo de mejora de proce-sos, en la mayoría de los casos con los mo-delos 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 supues-to 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 comenta-mos 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 refe-rencia para:a) Medir las capacidades de una organización yb) Diseñar y llevar a cabo mejoras de esas capacidades.

Los MC deben mostrar al menos las siguien-tes características: • Completitud: el MC incluye todos los as-pectos relevantes al medir capacidades.

• Consistencia: el MC no contiene contradic-ciones internas.

• Objetividad: el MC tiene la precisión necesa-ria 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.

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 co-fundador. 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.

Además, los MC debieran mostrar validez es-tadística y proveer una manera rápida para ob-tener una evaluación inicial de capacidades.

Una estructura común de los MC (ver figu-ra 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 con-junto debiera facilitar la mejora de capaci-dades 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 pruebaLos MC que hemos utilizado en proyectos de mejora de capacidades de prueba (incluidas las nuestras) son: Test Process Improve-ment (TPI), de la empresa holandesa Polteq; Testing Maturity Model (TMM), del Illinois Institute of Technology (EEUU); y Test Apti-tude Model (TAM), de la empresa mexicana e-Quallity.

La tabla siguiente muestra algunas caracte-rísticas relevantes de cada uno de ellos:

Figura 1. Estructura de los modelos de calidad.


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

TMM

Busca subsanar carencias de CMM en el área de pruebas

Muy orientado a entidades de prueba den-tro de organizaciones desarrolladoras de software

Mediano: 13 metas, 5 niveles

Difícil de localizar proveedor

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

Se ha constituido como un estándar internacional de facto

TPI

Utilizado en la industria de prueba mexicana

TAM

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

Ligero: 13 áreas, 3 niveles

Inversión razonable en pesos

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

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

Inversión considerable en euros

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

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

ConclusiónAunque nosotros vemos con claridad que en el desarrollo de software la re-lació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 mejo-ra 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 mo-delo ligero como el TAM, que con costos moderados permite mejorar significativamente las capacidades y luego, si lo que se busca es una cer-tificación internacional, brincar a un modelo como TPI, aprovechando los ahorros económicos obtenidos de la mejora anterior.

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

inicial de capacidades”.

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

calidad TPI y TMM de e-Quallity.

// COLUMNA /*PRUEBA DE SOFTWARE*/

» Luis Vinicio León Carrillo / Elena Ruelas Minor

Pesado: 20 áreas, 4 niveles


Más Allá del Manual de Usuarioparte 1. doCuMentando La arquiteCtura de software

Por Omar Gómez

/*ARQUITECTURA*/// PRÁCTICAS

Principios básicosEn la actualidad, uno de los temas candentes del que se habla den-tro de la comunidad de desarrollo de software es el referente a las arquitecturas. Una arquitectura de software describe cómo un sis-tema se desglosa en componentes, cómo son interconectados y la manera en que se comunican e interactúan entre sí. Tras la defini-ción anterior se pueden formular un par de preguntas: ¿en qué gra-do cumplimos con ésta definición durante el rol que desempeñamos como arquitecto o diseñador?, o mejor dicho: ¿Qué tan bien docu-mentamos 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 considera-ciones 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ícu-los 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 pri-mero 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, toma-das 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 ele-mentos de diseño comunes a diversas partes del sistema.

• Vista de procesos. Trata los aspectos de concurrencia y distribu-ció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ódu-los de software en el ambiente de desarrollo. El software se empa-queta en partes pequeñas que pueden ser bibliotecas o subsistemas

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, en-tre otras más; y es ejecutado sobre varios nodos de procesamiento (hardware). Estos nodos son relacionados con los elementos identi-ficados de las vistas anteriores. Aquí se especifican varias configu-raciones 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 pe-queñ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 des-cubrir 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 ele-mentos principales de diseño y las relaciones entre ellos dentro de un dominio determinado. Esta vista es independiente de las decisio-nes 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 sub-sistemas, 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 lengua-jes de programación a utilizar, herramientas de desarrollo, la adminis-tración de la configuración y la estructura y organización del proyecto.


Es común que en la actualidad se utilice alguno de los 2 enfoques antes descritos. Sin embargo, la forma de documentar una arquitec-tura 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 utili-dad y no ajustarse a un número fijo como lo muestran las propuestas.

• Documentar la arquitectura tomando en cuenta los intereses y nece-sidades 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) elabora-do 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, re-laciones, propiedades, situaciones en las que no es recomendable aplicarlo, circunstancias en las que se recomienda usarlo, y posibles

enfoques analíticos que el arquitecto puede utilizar. Para la elabora-ció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 descri-ben el uso del marco de trabajo con los atributos de calidad: desem-peño, facilidad de modificación y disponibilidad.

La documentación de las vistas se realiza a través de lo que se deno-mina 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 mane-ra, 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 presen-tes 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 fi-las 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 par-ticipantes en el proyecto, los valores posibles para las celdas pueden ser: requerido a detalle, de manera general o ninguno. Este paso con-cluye 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 mane-ra 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:

“Comúnmente una arquitecturade software se documenta a través

de un conjunto de vistas”.


/*ARQUITECTURA*/// PRÁCTICAS

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 [email protected]

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

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

• Diagrama de contexto. Muestra la relación entre el sistema o por-ció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 arquitec-tura 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.

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

Referencias:[ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE Soft-ware, 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 Archi-tecture 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. ]



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

/*PROGRAMACIÓN*/// PRÁCTICAS

En esta ocasión se hablará del framework Ruby on Rails. Recomen-damos 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 ins-talado, en este caso se utilizó MySQL, por lo tanto, la sintaxis refe-rente 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.

Arquitectura de RailsComo 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 impor-tantes de una aplicación Rails se presentan en el siguiente esquema:

La arquitectura funciona de la siguiente manera: se genera una pe-tició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 pre-sentació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 con-trolador, pueden ser compartidos de manera automática con las vis-tas. ERb es un paquete que permite la manipulación de código Ruby

intercalado con HTML, de tal manera que aun cuando las vistas con-tienen 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.

Arrancando con RailsEl procedimiento que se describire a continuación es el proceso simple recomendado para la creación de cualquier aplicación basada en 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.

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 to-dos 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 alcan-ce de este artículo.

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 per-mitirán realizar cada una de estas fases.

Pasos1. Definimos un directorio de desarrollo llamado trabajo, dentro de él creamos la aplicación base en Rails (en nuestro caso la denomi-naremos railsass):

>cd trabajo>rails railsass

Al ejecutar este comando se crea la infraestructura base de la apli-cación, que es la estándar para cualquier aplicación formada de la siguiente manera:


Aprendiendo Ruby y Rails


2. Se crean en MySQL 3 bases de datos:

railsass_development,railsass_test yrailsass_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 railsasspath/trabajo/railsass>ruby script/generate model Usuario

“ERb es un paquete que permitela manipulación de código Ruby

intercalado con HTML”.



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: mysqldatabase: railsass_developmentusername: rootpassword:host: localhost

test:adapter: mysqldatabase: railsass_testusername: rootpassword:host: localhost

production:adapter: mysqldatabase: railsass_productionusername: rootpassword: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 es-tructura 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 contie-ne 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 obje-tivo 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 endend

def self.down drop_table :usuarios endend

6. Ejecutamos la migración a través del manejador de tareas rake:

cd path/trabajo/railsasspath/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, califi-cando 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 am-biente 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).


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

“A través de Ruby se puede manipularcódigo SQL resultando más cómodo,

sencillo y elegante”.

En este artículo exponemos brevemente la arquitectura gene-ral 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 Develop-ment 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 ]


/*PROCESOS*/// PRÁCTICAS

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 pro-porciona 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 enfo-cadas 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: CMMI-SVC (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 dete-nido su labor porque presentó un caso de es-tudio 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, re-solvié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 comu-nidad 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 actualmen-te el marco de referencia de CMMI-DEV— a transformar el desempeño de sus servicios en ofrecimientos maduros y exitosos. Preten-

CMMI-SVC®¿qué hay de nuevo bajo eL soL de Los serviCios?Por Elizabeth Almeraz

diendo acrecentar la inversión realizada en los proyectos de mejora de procesos, am-pliando su aplicación a otras áreas de la organización; de tal forma que permita que la operación de los diferentes modelos ope-ren 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 al-macenado, y por tanto, el modelo puede ser aplicado a cualquier organización que ofrez-ca servicios, lo cual incluye compañías de los más diversos sectores, desde las entida-des militares, pasando por las de tecnología de información, hasta las dedicadas al cui-dado 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 li-berados y en uso (CMMI-DEV y CMMI-ACQ); y se planea que el mismo método de evalua-ció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 cual-quiera 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 ser-vicios; 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 den-tro de las áreas de proceso base del modelo de CMMI (CMMI Model Foundation); las cua-les se comparten por los modelos de CMMI-DEV 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 Administra-ció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 adi-ciona 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 proce-so. 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 ca-tegorí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 si-guientes á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.


- Incident and Request Management (IRM).- Service Delivery (SD).- Service System Development (SSD) -opcional.- Service Transition (ST).

• Administración de Proyectos. Abarca nue-ve áreas de proceso. Esta categoría incluye todas las áreas de proceso de administra-ción dentro de CMMI-DEV, considernado la correspondiente a la Administración de Proveedores (SAM), así como la de Adminis-tració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.

El CMMI-SVC es un modelo que se distingue del CMMI-DEV debido a que permite direc-cionar la administración de punta a punta en servicios complejos o sistemas complejos de desarrollo; y en dónde el uso de los pro-cesos 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 ser-vicios tales como la entrega repetible a través del tiempo, y los cambios constantes de clien-tes 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 incre-menta la consistencia y la calidad de los servi-cios proporcionados.

Referencias[ sei.cmu.edu/cmmi ]

ConclusionesComo se ve, el CMMI-SVC es un mode-lo que bien puede ser el complemento perfecto para otras iniciativas de me-jora continua; sin importar que se ten-ga 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 in-terés por el nuevo concepto que aún se encuentra en gestación; aunque sin duda se espera que será una op-ción que puede romper algunos para-digmas ya establecidos… en fin, sólo el tiempo lo dirá.


SysmlModeLando sisteMas y sisteMas de sisteMas

Por Charlie Macías

// UML

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 for-mación en ingeniería mecánica ha venido llamando de manera cre-ciente mi atención y la de muchas empresas desde hace algunos años: SysML (omgsysml.org).

El mundo de los sistemasDí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 fun-cionamiento 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 ubi-carse dentro de otro sistema más grande conformado por las vías de comunicación sobre las que transita, lo cual impacta sobre el siste-ma ambiental y sobre la sociedad.

La especialización de UMLSysML (System Modeling Language) es un lenguaje de modelado de dominio específico para aplicaciones de sistemas de ingeniería. So-porta 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 respon-sabilidad 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, investi-gar 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.

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 re-lativamente madura (diez años) de UML 2.0.

¿No es suficiente con UML?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 modela-do que permita especificar sistemas complejos que incluyan no sólo componentes de software (por ejemplo: hardware, información, pro-cesos, personal e instalaciones). SysML reduce el tamaño e inclina-ció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 embebi-dos para los que desde 1998 existe una adaptación de UML conocida como Real Time UML, la cual no ha sido suficiente.

Ventajas sobre UMLEntre las principales ventajas que SysML ofrece, sobre UML, a los ingenieros de sistemas para especificar sistemas o sistemas de sis-temas se encuentran:

1. SysML expresa mejor que UML la semántica de la ingeniería de sis-temas. 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 medi-mos en diagramas todo el lenguaje es más pequeño: nueve diagra-mas, de SysML vs. 13 diagramas de UML.

3. Las tablas de asignación de SysML soportan varios tipos de asig-naciones (por ejemplo: asignación de requerimientos, asignación funcional, asignación estructural) facilitando, de esta manera, la ve-rificación y validación (V&V) automatizada y el análisis GAP.


“Los diagramas de estructura,comportamiento, requerimientos y

parámetros son la base de la especificación”.

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

UML + SysMLEn 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 importan-te señalar que en este ámbito se han iden-tificado 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 diagra-mas de Actividad o los de Bloques/Bloques Internos en SysML vs. los de Clases/Estruc-tura 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 Pa-ramétricos inyectan un modelo restricción-lógica en el modelo objeto-componente de UML. Al final del día, como siempre, la prác-tica 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. [email protected]

Figura 1. Estructura de SySML.

// UML


// PM CORNER

El VAlOR DE lAS OFICINAS DE PROYECTOSapaLanCar 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 vi-sualizar todos los proyectos en curso. Por lo tanto, es la entidad lógica para definir y reco-lectar un conjunto de indicadores comunes: y es el lugar lógico para recolectar informa-ción del estado de los proyectos para gene-rar 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 con-sumen mayor tiempo y sean los menos pre-feridos de los que la PMO desempeña.

Un servicio que típicamente está asociado con una PMO en el mercado, es la presen-tación de reportes del estado de todos los proyectos que se están ejecutando en la or-ganización. Dicho concepto puede extender-se 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 pa-trocina el proyecto para definir qué es lo que formará parte del reporte de estatus consoli-dado. Algunas organizaciones gustan de man-tener cada proyecto en una línea, con algún indicador tipo semáforo del estatus global, por ejemplo: verde (O.K.), amarillo (precau-ció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 repor-te 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 estatusLa PMO necesita recolectar información del estatus de cada proyecto, desarrollar un re-porte 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 ca-sos, 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 estatusDesde luego, dichos problemas necesitan superarse. La PMO puede atacar este tipo de problemas crónicos a través de las si-guientes actividades:

•Explicar quién está solicitando la informa-ció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á uti-lizada. 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 le-vantamiento de información del estatus en algún porcentaje de los equipos de proyecto, por lo tanto, debemos asegurarnos de no propi-ciar la excusa de que no saben cuándo era el com-promiso de entrega de los reportes de estatus.

•Dar seguimiento con los gerentes de pro-yecto a los temas que necesitan mayor explicación o clarificación. Al recibir infor-mación de estatus que no contenga el con-tenido o el formato requerido, se le debe dar seguimiento con el gerente del proyecto. Este seguimiento está diseñado para asegu-rar 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 pa-trocinador del programa, respaldándose en el proceso de gobierno de la organización. Las gerencia Senior debe mantener la res-ponsabilidad 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: [email protected]


Indicadores consolidadosExisten diferentes lugares donde las organiza-ciones 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á proporcio-nando. Los indicadores asociados con el valor de la dirección de proyectos, son también in-dicadores 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 for-ma, mostrarían el valor que ésta proporciona.

Indicadores organizacionalesUno de los temas más difíciles a los que se enfrenta la PMO, es el determinar el va-lor de la dirección de proyectos. Es una de las preguntas fundamentales que deben hacerse los patrocinadores y la alta direc-ció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

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 de-talle 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 desplie-gue (ya sea de una PMO o de un proceso for-mal de Dirección de Proyectos), se tendría la capacidad de obtener un valor similar.

El segundo es intentar calcular el valor asocia-do con el uso de la metodología. Por ejemplo: trabajar con los gerentes de proyecto en dife-rentes tipos de proyectos para determinar los ahorros asociados al mantener buenos pro-cedimientos 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 ten-dencias 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 geren-tes 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 suficien-te 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 po-drían apalancarse para asegurar un comien-zo con el pie derecho en este tema.

// PM CORNER


// PUBLIRREPORTAJE

IDS, Una Empresa Orientada a ProcesosexperienCia en aCreditaCión CMMi3Por José de J. Hernández

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. [email protected]

Ser una empresa orientada a procesos, implicaser fieles creyentes del beneficio de los proce-sos, anticiparse en la calidad de los productos que desarrolla y promover una filosofía de tra-bajo con prácticas estándar. IDS es una organi-zació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.

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

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

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.

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

¿Cuál ha sido la experiencia de IDS al traba-jar un programa de mejora continua? A conti-nuación, describiremos a grandes rasgos algunos de los factores, consideraciones importantes y lecciones aprendidas que IDS ha obtenido al im-plementar un programa de mejora continua.

Elementos importantesPara establecer un programa de mejora con-tinua y trabajar con orientación a procesos, primeramente debemos instaurar un en-foque 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 hacer-lo de esta manera (costo de la no calidad). Posteriormente implantar procesos y técni-cas definidas que nos guíen en la manera como desarrollaremos nuestros productos; y finalmente emplear herramientas de apo-yo a los procesos.

No debemos olvidar que los elementos ver-daderamente 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, procedimien-tos establecidos y herramientas de apoyo. Solamente combinando estos elementos podremos desarrollar productos de calidad.

Estrategia para la Alineación al modelo de referenciaPara 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.

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

•Planeación. Con base en lo anterior, defi-nimos 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 me-jora continua debe ejecutarse con las buenas prácticas de administración de proyectos.

•Definición. Su propósito fue desarrollar to-das 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 inte-grantes de los equipos de trabajo, conti-nuando en forma permanente con un mode-lo 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 deter-minar qué tan lejos nos encontrábamos del cumplimiento de las prácticas que marca CMMI® 1.2 para el nivel 3, y así observar nue-vamente 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.

52


Cabe resaltar que como parte de la estrate-gia, se definió el apoyo de entrenamiento in-formal y formal en el modelo CMMI, evalua-ciones informales (mini appraisal), así como consultoría de un externo, que permitiera aportarnos enfoques, revisiones técnicas a las definiciones (peer reviews), retroali-mentación y soporte en la preparación de la logística de la evaluación formal con la in-tenció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 aprendidasResulta 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 mejo-ra continua, quién tiene la visión de la mejo-ra, difunde la filosofía establecida y es res-ponsable 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 impor-tante: involucrar a la gente con más expe-riencia en el campo; tratar de hacer lo más sencillos y útiles los procesos; utilizar la tec-nología disponible; hacer partícipes de la definición a los integrantes de los equipos de trabajo; realizar talleres para revisar, re-troalimentar y validar los procesos; conside-rar 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

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

• Es necesario trabajar en una sólida estrategia de administración del cambio que considere: una campaña de difusión que busque ge-nerar identidad con la metodología y sensi-bilizació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 re-munerar (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.

• En la ejecución de los procesos en los pro-yectos, 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 pa-rámetro (umbral) más alto de apego a la meto-dología; fomentar un espíritu de competencia; e implementar un QA orientado a servicio.

• Los proyectos deben contar con una infra-estructura de procesos: repositorio de la defi-nición de procesos de donde puedan obtener los elementos metodológicos; mostrar ejem-plos de la elaboración de los artefactos; publi-car material de capacitación; difundir leccio-nes 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 producti-vidad, lo cual hasta cierto grado es normal, sin embargo, si el período de transición es

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

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 pla-near 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 metodo-logía, dando el tiempo adecuado para forta-lecer el nivel de madurez. Una vez logrado esto, será entonces cuando podremos vol-tear a un nuevo ciclo de mejora que tenga como meta el siguiente nivel del modelo.

ConclusionesImplementar un programa de mejora continua no depende del modelo de re-ferencia 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 mejo-rar: alinearnos a un modelo, optimizar algo, buscar un siguiente nivel, definir nuevos productos o servicios para nues-tros clientes, etcétera. Lo importante es saber qué queremos mejorar, por qué lo queremos mejorar y entonces mejorar-lo, utilizarlo, estabilizarlo y hacer de ello una filosofía de trabajo.

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

// PUBLIRREPORTAJE


¿Cuál es mi Password?La epideMia de Cuentas

Por Karina Okón

// fUNdAMENTOS

Figura 1. Arquitectura de autoridad única.

¿Cuántos nombres de usuario manejas para acceder a las distintas aplicaciones que uti-lizas 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 resi-den 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 acce-der a una determinada aplicación web, y la pérdida de tiempo (y dinero) mandando correos electrónicos o hablando por teléfo-no 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 pro-blemas graves de seguridad y acceso, al cre-cer 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 ade-cuadamente. Meta Group estima que duran-te 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 si-tios 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.

Los propietarios y gestores de los recursos, se dan cuenta a menudo que el manteni-miento de las cuentas de los usuarios es un difícil desafío. La gente cambia regularmen-te 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 funcio-nes, creándose las llamadas cuentas fantas-ma que pueden suponer un back door para que ex-empleados, por ejemplo, accedan a datos confidenciales de la compañía. Enton-ces, ¿cuál es la solución?

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

sistemas con una única acción de login, ali-viando 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 agru-pación de identidades?

Primero, examinar la cultura de la empresa. Recordemos que hasta ahora los propieta-rios 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.

Segundo, debe haber una confianza entre los propietarios de los recursos y los propietarios de los sistemas de identidades. Esta confian-za 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 informa-ció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 integra-

ció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.


Figura 2. Arquitectura en estrella.

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

Tercero, son necesarios componentes tecno-lógicos. Detrás de la agrupación está la ne-cesidad básica de comunicación entre cada sistema. Los sistemas están hechos por dis-tintos fabricantes, utilizando diferentes herra-mientas 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 in-ter-operar a una gran variedad de productos independientes. Estos estándares incluyen:

•SAML (Security Assertions Markup Lan-guage), estándar definido por OASIS ( Orga-nization for the Advancement of Structured Information Standards).

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

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

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

•Shibbolet, iniciativa de código abierto ba-sada en SAML.

La implementación de la agrupación de iden-tidades 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 en-tre 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 sa-car partido de la agrupación de identidades para servir mejor a nuestros usuarios, pro-veedores, socios y clientes.

Ejemplos prácticosEn 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 patro-nato, mientras que las cuatro entidades actúan como proveedores de servicios hacia el hub.

En la figura 2, podemos observar las distin-tas identidades del usuario en los diferentes puntos y las relaciones de confianza entre ellas. Gracias a estas relaciones una perso-na 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 almace-ne en ninguna entidad (solamente en el hub central) las relaciones entre los identificado-res de cuentas del usuario en las distintas entidades.

// fUNdAMENTOS


Software Appliances Los Mejores Amigos de las Empresas en CrecimientoPor Ariel García

// TECNOLOGÍA /*INFRAESTRUCTURA*/

Quienes hemos administrado sistemas co-nocemos la gran carga de trabajo que esto conlleva. La administración de licencias, servi-dores y equipos; contratos de mantenimiento, control de cambios e incidentes y garantías, son actividades típicas del día a día. Adicional-mente, cualquier actualización a la infraestruc-tura 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 Applica-tion 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 enton-ces en que consiste esta tendencia y como se compara con el modelo de ASP.

Application Service Provider:la primera alternativaBajo 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 ad-ministración del servicio de cómputo. Típica-mente 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, per-mitiéndole al cliente final contratar única-mente 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 ad-ministración de activo. El resto de la funcio-nalidad 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.

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 recur-sos y/o políticas necesarias para la pro-tección y seguridad de dicha información. Negocios con altos requerimientos de segu-ridad y privacidad pueden implementar una solución basada en Software Appliance.

Software Appliance: servicios de cómputo a la medidaUna solución basada en Software Appliance combina lo mejor del modelo ASP con la ro-bustez de una solución empresarial tradicional. El modelo del Software Appliance sigue el mismo principio de ofrecer módulos de fun-cionalidad 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 aplica-ció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 única-mente las funciones necesarias de la apli-cació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 vir-tual. (Un Software Appliance que se ejecuta en una maquina virtual se le conoce como Vir-tual Appliance). Empresas con altos reque-rimientos 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 infraes-tructura de cómputo.

Características principales de un Software ApplianceCompila, corre y ejecuta lo que tenía que ha-cer 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 co-rrida. Esto se debe a que no sólo el sistema operativo está parametrizado de forma es-pecifica 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ís-tica elimina tareas típicas que complican la implementación de un esquema tradicional como: configuraciones especiales para sis-tema 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 adminis-tración se ejecuta en un único grupo de herramientas que eliminan la capa de admi-nistración del sistema operativo e integran la administración de la base de datos, ser-vidor 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 ope-rativo y demás aplicaciones, son realizadas a través de las herramientas de administración del Software Appliance.

Un solo culpable con habilidades de rege-neración ... ¡Wow!. Existe una sola cara al cliente en la detección y solución de pro-blemas. El proveedor de servicio es el único responsable de identificar, aislar y resol-ver 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 mo-dificación en el hardware). Adicionalmente, el appliance tiene la capacidad de detectar y corregir problemas en su operación sin la in-tervención de un administrador. Debido a que los componentes de software están altamente


integrados y son administrados de forma cen-tralizada, 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 soft-ware, 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 pro-veedor de servicios es el único responsable del mantenimiento, instalación y configura-ción de parches, y la actualización a nuevas versiones en cualquiera de sus componen-tes del Software Appliance. De hecho, estas tareas se ejecutarían de forma remota a tra-vés de las herramientas de administración.

En resumen, los beneficios de una solu-ció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 admi-nistración. No obstante, esta solución tiene un mercado específico.

A continuación enumeramos algunos indi-cadores 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 perfec-ta 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-

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 soft-ware, 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 solu-ció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 ca-lifica 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 pro-veedores. Hoy por hoy, podemos encontrar servicios de Software Appliance con Google, Wikipedia, Zimbra, entre otros. SAP e IBM están trabajando conjuntamente en ser-vicios 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 resul-tados con menos recursos.

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

// TECNOLOGÍA /*INFRAESTRUCTURA*/


// TECNOLOGÍA /*GADGETS*/

Van Der Led

WM2 WatchphoneAl 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, pare-ciera 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.

Cámara Stylus 850 SWPara no perder detalle de los eventos, el equipo de SG tuvo la oportu-nidad 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.

Olympus

SuperchargerDe la mano con la ecología y para aprove-char 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 ajus-tarlo en algún soporte. Tampoco hay que preocuparse por la lluvia, viene con una pro-tección para todo tipo de clima, permitiéndo su uso constante.

Sólo cuatro horas de exposición al sol, bas-tan 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 funcio-nando.

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

Solar Technology


INDEX

Anunciante Páginas Sitio

Alpha 55 www.alpha-consultoria.comAvantare 17 www.avantare.comCA 7 www.ca.com/mxCompusoluciones 57 www.compusoluciones.comCutter 59 www.cutter.com.mxe-Quallity 27 www.e-quallity.netFone 45 www.juegodetalento.comGartner 11 www.gartner.com IDC 51 www.idc-eventos.comInformation Secutity 47 www.informationsecurity.com.mxItera 15 www.itera.com.mxKernel 63 www.kernel.com.mxManpower 49 www.manpowerprofessional.com.mxMicrosoft 2F, 1 www.microsoft.com/mexicoMilestone Consulting 4F www.milestone.com.mxSafe Net 3F www.safenet-inc.comSIE Center 41 ciisa.gda.itesm.mxSG’08 22, 23 www.sg.com.mx/sg08SUN 43 www.sun.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TISi deseas anunciarte contáctanosen el (55) 5239 5502 o en [email protected]

DIRECTORIO


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

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

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

60

/*TENDENCIAS EN SOFTWARE*/// COLUMNA

¿Hacia Dónde Vamos?refLexiones de La industria de software en aMériCa Latina

Recursos humanos

Oportunidades a ganar

Industria

Hace 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 rela-cionadas al desarrollo de la industria de software.

PerfilAun 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 clien-tes principales representan 64% del total de sus ventas y las áreas que requieren más for-talecimiento 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 orga-nismos internacionales se enfocan en empren-dedores (YABT) y nuevas empresas (RELAPI).

Las oportunidadesLo más importante es tener el recurso humano. Diversos estudios muestran que los me-jores 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-

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 entre-namiento para incorporarse a la realidad. El tiempo dedicado a decidir qué les ense-ñaré a los muchachos, ahoga realizar inter-cambios 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 de-sarrollo y exportación de software con un gran enfoque en normatividad que realmente bene-ficie a la mayoría. En mi opinión personal, debe alentar la neutralidad tecnológica, evitando te-mas que reduzcan el ámbito de opciones.

El rol de la mujer. Menos del 9% de desa-rrolladores profesionales de software son mujeres. Basta decir que estamos limitando el 50% de los recursos humanos existentes. Ellas continúan discriminadas sin ser con-sideradas para su rápido desarrollo. Este tema ha cobrado auge mundial. El paradig-ma 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 di-rectivo, 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 servi-cios, 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.

ConclusiónEn 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!

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

» Luis Daniel Soto

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


// COLUMNA/*TIERRA lIBRE*/

Software en la ComunidadsiMuLaCió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 [email protected]

En cuanto conocí el trabajo de simulación participativa para enseñar sustentabilidad ambiental del Dr. Luis García Barrios, inves-tigador en El Colegio de la Frontera Sur en San Cristóbal de las Casas, Chiapas; consi-deré imprescindible hablar de él. Luis y un equipo de voluntarios llevan varios años tra-tando de resolver el problema ambiental de raíz, capacitando, con ayuda de software, a las personas de las comunidades más apar-tadas 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 Indicado-res de Sustentabilidad (MESMIS). Este es un esfuerzo por crear una metodología de evalua-ción de prácticas de sustentabilidad para los recursos naturales, que permita indicar qué tan abastecidas o no son las prácticas de ex-plotación de los recursos naturales de un lugar determinado. Este trabajo ha sido reconocido a nivel mundial y es producto de varios inves-tigadores 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 educa-ción para la sustentabilidad rural.

El MESMIS interactivo cuenta con 4 capítu-los de los cuales 2 son simuladores de sus-tentabilidad. La idea es lograr que las perso-nas participen de una forma activa a través de un drama en tres actos que les muestre los problemas reales en la toma de decisio-nes de sustentabilidad combinando simula-ciones de software, elementos teatrales y de juegos de rol.

En el primer acto, se muestra una cuenca don-de todo era bosque, luego diez familias lle-gan y desmontan 100 hectáreas con siembra.

Al cabo de décadas con el crecimiento de la comunidad y los diversos apoyos guberna-mentales para el campo, la mayoría de ellos implementados sin tener en cuenta los prin-cipios de sustentabilidad, las ahora 1000 fa-milias deforestan 4000 hectáreas. El gobier-no en respuesta, crea una área protegida y reduce la superficie para las familias, por lo que los campesinos ahora tendrán que recu-rrir al uso de fertilizantes para poder sobrevi-vir con el terreno reducido. En el software, los usuarios van viendo simulaciones a través de series de tiempo, dinámicas, puntos de equi-librios y diversos umbrales para ver de que forma este sistema simulado reacciona ante estas estrategias de explotación.

En el segundo acto, aparecen nuevos per-sonajes, 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 ma-yor productividad afecta de forma muy clara la ecología del lago, que además es mucho mas difícil restaurar que un sistema terres-tre. 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 particu-lar 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 per-miten 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 volunta-rio con el grupo de investigadores de GIRA. Posteriormente se entera del trabajo de Luis con la propuesta de generar modelos inte-ractivos de MESMIS . Inspirado por el poten-cial 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 volunta-rios trabaja en el futuro de MESMIS Interac-tivo. Las próximas versiones incorporarán desde el diseño del sistema a todos los ac-tores sociales en una plataforma donde se puedan modelar los problemas en un terri-torio específico, y la gente pueda explorar las consecuencias y entender sus decisio-nes sobre sus ambientes a través de simu-laciones interconectadas en red. Se prevee usen tecnología de vanguardia en la simu-lació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 fuen-te de inspiración para quien escribe. Para ustedes, amigos lectores, la invitación a co-nocer, 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 co-mentarios, pueden checar mas información y fotos del proyecto en tecnonirvana.org

» Emilio Osorio


Del Buzón de Sugerenciasa la Colaboración Empresarialenterprise 2.0Por Tomás Helou

// COLUMNA INVITAdA

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 diferen-cia 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 escucha-do hablar sobre las tecnologías Web 2.0.

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

Cuando lo social generagananciasAntes de continuar, debemos de dar un vis-tazo a lo que realmente significa Web 2.0, el término se refiere a la segunda generación de servicios de Internet, donde la colabo-ración a los contenidos y las redes sociales son la innovación fundamental. Las princi-pales diferencias entre Web 1.0 y Web 2.0 las enmarcamos de la siguiente manera:

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, propi-cian la colaboración de los usuarios comunes y corrientes.

¿Qué es Web 2.0 y Enterprise 2.0?Diferencias y similitudes

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 comunicacio-nal 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 es-tratégicos, pues dentro de las funciones que se realizan en el área externa, se abarcan des-de investigación de mercados, lanzamiento y promoción de nuevos productos y la más im-portante: 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.


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 pos-teriormente son usadas en toda la organiza-ción. Sus áreas de mayor uso son gestión y planificación estratégica, desarrollo e innova-ció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 conoci-miento de la manera en cómo se construyen las aplicaciones, ya que usan códigos abier-tos a través de API’s (Interfase de Programa-ción de Aplicaciones) y servicios web.

No solamente la integración de clientes, so-cios 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 apli-cació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 reuti-lización de módulos, por ejemplo: para la creación de mashups.

Comunitario, pero no inseguroLa 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 vulne-rables 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 pre-vención para dichos ataques no es algo que salga de lo convencional; un buen sistema preventivo soluciona en gran parte estos ata-ques, 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.0Ya que facilita la descentralización de tecno-logías, Enterprise 2.0 entrega beneficios a las empresas que la implantan, como:

• 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 eficien-te, 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 DatosYa que se entendió qué es Enterprise 2.0, debemos cuestionarnos y analizar si es apli-cable para nuestra empresa o no, ya que hay ciertos factores antes, los cuales no es re-comendable a migrar a este tipo de tipo de tecnologías:•Cuando encontremos a los empleados rea-cios 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 tra-bas, debemos pensar mejor en seguir al-macenando 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 herra-mientas, éstas por sí solas no solucionarán nada, y por el contrario, no sabemos qué consecuencias negativas puede tener su mal uso o desconocimiento.

ConclusionesPodrí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 concen-tran 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 des-conocen 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.

// COLUMNA INVITAdA


SchemeEl Mundo entre Paréntesis

// COLUMNA /*CáTEDRA y MáS*/

Imagina que no hay ciclosen tu programaciónno existen for ni whiletan sólo recursión.Imagina a la genteentre 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 me-lodía de la canción Imagine de John Lennon. Era mediados de los noventa. Me encontra-ba 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 Mon-terrey. Esa canción, junto con el contenido exaltado y a veces autocomplaciente de al-gunas 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ába-mos pensando adoptarlo, no como un len-guaje 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 dis-cusiones 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 cu-riosidad; de modo que le dimos luz verde al proyecto. Scheme era un lenguaje definiti-vamente 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 com-plejas generaba entonces una cantidad de paréntesis que de inmediato se convirtió en el blanco de las bromas entre profesores y

alumnos. Sin embargo, descubrí que, enun-ciando 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 len-guaje 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 len-guaje. 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 lis-ta. 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 re-solver problemas típicos de un curso de estructuras de datos. Inventé ejercicios in-teresantes para ellos, fascinado por la liber-tad que el lenguaje me daba para enseñar algoritmos y lógica de programación.

Sin embargo, resultó que estábamos adelan-tados a nuestro tiempo. Algoritmos elegantes o no, los estudiantes extrañaban la deslum-brante interfaz visual de Java. Se preguntaban el por qué aprendían un lenguaje que no exis-tí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, es-taba 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 sorpren-dí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 desarro-llo 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 orien-tado a objetos y el imperativo. Me parece in-teresante 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 plata-forma .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”.

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

w

ww

.sg.

com

.mx

SG

SO

FT

WA

RE

GU

RU

- C

ON

OC

IMIE

NT

O E

N P

RÁ

CT

ICA

May

o-Ju

lio 2

00

8 N

o. 2

0

Documents

SG20 (Mayo-Julio 2008)