SG15 (Mayo-Junio 2007) by Revista Software Guru

• Análisis de Puntos de Función • Desarrollo de Juegos • Modelado de Negocio

Software Guru CONOCIMIENTO EN PRÁCTICA Año 03 No.03 • Mayo-Junio 2007

[ ENTREVISTA ]

Eduardo Ruiz Esparza Presidente de CANIETI

HERRAMIENTAS

Desarrollo de código seguro

México, $65.00

Outsourc

ing de TI

Noticias • Eventos • Fundamentos • UML • Infraestructura • Carrera

www.softwareguru.com.mx

[ A Fondo ] Genero 2.0

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Arte y Diseño David Gutiérrez Oscar Sámano Consejo Editorial Francisco Camargo, Ralf Eder, Raúl Trejo, Guillermo Rodríguez, ITESM-CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity - ITESO. Colaboradores Noé Huerta, Lacendi Nolasco, Juan Pablo Bernabé, Jorge Palacios, Marcos del Pozo, César Vázquez, Artemio Mendoza, Enrique Herrera, Carlos Aguilar Weber, Raúl Quiroz, Rodrigo García, Sergio Orozco, Carlos Macías, Luis Daniel Soto, Jorge Becerril, Ariel García, Susana Tamayo, Sonia Sánchez, Emilio Osorio, Lourdes Sánchez

Editorial Así de repente, hemos llegado al tercer número de este año. El tema principal que nos incumbe en esta ocasión es el de outsourcing, que sin duda es una de las tendencias que genera mayor interés en nuestra industria. De hecho, outsourcing y seguridad son posiblemente las dos áreas de TI sobre las que se genera mayor información. Hemos incluido diferentes artículos que abordan diferentes aspectos, desde la gestión de cambio al migrar hacia un esquema de outsourcing, hasta el rol que juega la arquitectura orientada a servicios en el desarrollo con equipos distribuidos globalmente. Sin embargo, quedan muchos otros temas por abordar que iremos cubriendo en ediciones posteriores de SG. Como se habrán dado cuenta, la entrevista de este número es con Eduardo Ruíz Esparza. Estamos muy entusiasmados de que una persona con su perfil haya quedado al frente de CANIETI. Confiamos en que habrá buenos resultados. Sin embargo, ya sabemos que la responsabilidad de desarrollar nuestra industria no solo es de una asociación, ni del gobierno, sino de todos.

MAY-JUN 2007

Un tema que lleva varios meses apareciendo en artículos, entrevistas y pláticas informales que tenemos con gente de la industria y academia, es el de si las universidades deben enfocarse en aspectos generales de conocimiento, o en aspectos técnicos específicos (como por ejemplo certificaciones). En el artículo de Carrera de este número, vemos que la ANIEI está consciente de este dilema, y ya ha propuesto una solución. Enhorabuena y nuestras felicitaciones. Agradecemos a todos los colaboradores de este número, así como a todos los lectores que nos hacen llegar retroalimentación. Ya saben que estamos a sus órdenes en editorial@softwareguru.com.mx PD - Como se habrán dado cuenta, ya nos estamos preparando para SG ’07 Conferencia y Expo del 29 al 31 de Octubre en la Ciudad de México. Les recomendamos que se vayan planeando para asistir, porque será un evento que no querrán perderse. — Equipo Editorial

Imágen de Portada y Principal myspace.com/kilodesign Fotografía Gabriel González Ventas Claudia Perea Natalia Sánchez Marketing y RP Dafne Vidal Circulación y Subscripciones Daniel Velázquez Contacto info@softwareguru.com.mx +52 55 5239 5502

SG Software Guru es una publicación bimestral 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 2007 en Litográfica Roma. Distribuido por Rrecca Comercializadora y Sepomex.

www.softwareguru.com.mx

contenido may-jun 2007

EN PORTADA Outsourcing

El outsourcing es una de las principales tendencias de la industria. Presentamos los principales modelos, tendencias y prácticas.

Productos LO QUE VIENE 10 Oracle Data Integrator, Google Ajax Feed API, OpenID, Debian Etch

Columnas Tejiendo Nuestra Red por Hanna Oktaba

Tendencias en Software por Luis Daniel Soto

Mejora Continua por Luis Cuellar

Tierra Libre por Sonia Sánchez

Cátedra y Más por Francisco Camargo

46 54

A FONDO Four J’s Genero 2.0

HERRAMIENTAS Desarrollo de código seguro con Visual Studio

Prácticas PROGRAMACiÓN Desarrollo de un Juego 2D

En esta segunda y última parte, aprendemos como crear las clases y texturas para nuestro videojuego de 2D.

ADMINISTRACIÓN DE PROYECTOS 36 Análisis de puntos función, parte 2 Continuamos con este caso de estudio, donde aprendemos a aplicar la técnica de análisis de puntos función a un caso real.

Entrevista

Eduardo Ruiz Esparza Presidente de CANIETI

30 Madurez de procesos en el IMSS

www.softwareguru.com.mx

En Cada Número Noticias y Eventos UML Fundamentos INFRAESTRUCTURA CARRERA

MAY-JUN 2007

04 42 48 50 56

// NOTICIAS

Gartner Enterprise Integration Summit El pasado 19 y 20 de abril se llevó acabo la edición 2007 del Gartner Enterprise Integration Summit, que es el evento de Gartner orientado a la integración de aplicaciones empresariales. Como era de esperarse, entre los temas que dominaron las conferencias estuvieron SOA y BPM. Sin embargo, la novedad este año fue la aparición del tema de Web 2.0, en el cual se hizo un gran énfasis. De acuerdo con Gartner, entre las tecnologías estratégicas para éste año y el próximo, destacan la virtualización, el open source, y el acceso ubicuo a la información.

Conferencia Anual de IT Service Management El 21 y 22 de marzo se realizó la Tercera Conferencia Anual de IT Service Management en la Ciudad de México, organizada por Pink Elephant. Las conferencias giraron alrededor de 3 temas que actualmente son de gran interés para los ejecutivos de Tecnología de Información: IT Service Management, Gobernabilidad de TI, y la nueva versión 3 de ITIL. En el evento estuvieron presentes varios autores de la versión 3 de ITIL, como Sharon Taylor, David Cannon y Majad Iqbal. Sharon Taylor tuvo a bien explicarnos algunos de los aspectos fundamentales de ITIL v3. Entre ellos, destaca que esta nueva versión tiene un espectro mucho más amplio, que va más allá de las operaciones e incluye toda la estrategia de administración de servicios dentro de un modelo de ciclo de vida en las organizaciones de TI.

IDC WebSec 07

LA Grid Research Summit

También en abril se llevó a cabo en la ciudad de México el WebSec 2007, que fue organizado por IDC en conjunto con Sm4rt Security Services.

El Tec de Monterrey, Campus Estado de México fue sede del encuentro LA Grid Research Summit, en el cual se reunieron representantes de siete universidades de Estados Unidos, España y América Latina que forman parte del programa LA Grid. Este programa, lanzado por IBM , consiste en una comunidad multidisciplinaria que a través de un grid de cómputo realizan investigación colaborativa, principalmente en las áreas de informática y biotecnología.

Se contó con la participación de ponentes de talla internacional y nacional como: Sahba Kazerooni de Canadá, quien habló sobre seguridad en web services y realizó una demostración básica de SQL Injection en webs vulnerables; Jess García de España, con el tema “Definiendo una correcta Arquitectura de Seguridad” donde dio sus recomendaciones para contar con buenos niveles de seguridad en las redes empresariales, así como tomar las medidas adecuadas cuando se presente un incidente; Víctor Chapela de México, cuya plática “Desde el Core: Reestructurando la Seguridad de las Bases de Datos” demostró que muchos administradores no cuentan con políticas de seguridad eficientes para prevenir robo de información.

Entre las universidades participantes en el encuentro, estuvieron la Universidad de Florida, Universidad de Miami, Florida Atlantic University, Universidad de Guadalajara y Universidad Autónoma de San Luis Potosí. La iniciativa del Tec de Monterrey se centra en generar grupos con el fin de crear sinergia entre universidades mexicanas y americanas y de ser posible extenderlo a Europa, logrando así posibilidades de intercambio para todos los alumnos de las universidades miembros del programa LA Grid. Mayor información en latinamericangrid.org

MAY-JUN 2007

www.softwareguru.com.mx

// EVENTOS

8 al 11 de Mayo 2007

15 y 16 de Mayo 2007

Moscone Center, San Francisco, CA Info: java.sun.com/javaone e-mail: javaoneinfo@eventreg.com

Hotel Camino Real, Cd. de México Info: www.informationsecurity.com.mx Tel: +52 (55) 1087 1650 e-mail: marcela@ejkrause.com

Java One Conference 2007

9na. Conferencia Anual Information Security

16 al 18 de Mayo 2007

Sun Tech Days México Centro Banamex, Cd. De México Info: www.suntechdays.com.mx Tel: +52 (55) 5261 7924 e-mail: info@suntechdays.com.mx

23 al 25 de Mayo 2007

Expo Data Center WTC, Cd. de México Info: www.expodatacenter.com Tel: +52 (55) 5659 9657 e-mail: sergio@expodatacenter.com

4 al 8 de Junio 2007

Microsoft Tech-Ed 2007 Orlando, Florida Info: www.microsoft.com/events/teched2007 e-mail: TechEd2007@microsoft.crgevents.com

6 al 8 de Junio 2007

Expo Electrónica Internacional Centro Banamex, Cd. de México Info: www.electronicaexpo.com.mx e-mail: ventas@vanexpo.com.mx

23 y 24 de Mayo 2007

Architecture: Strategy and Alignment to Achieve Business Value Strategic IT Training Cycle, Cutter Consortium 23 de Mayo - Hotel Camino Real, Monterrey, N.L. 24 de Mayo - Hotel JW Marriott, Cd. de México Info: www.cutter.com.mx/ciclo2007 Tel: +52 (81) 2282 6266 y +52 (55) 5336 0418 e-mail: eventos@cutter.com

10 al 14 de Junio 2007 27 y 28 de Junio 2007

III Cumbre Gartner Outsourcing Centro Banamex, Cd. de México Info: www.gartner.com/mx/outsourcing Tel: +52 (55) 5584 9370 e-mail: latin.america@gartner.com

IBM Rational Software Development Conference 2007 Orlando, Florida Info: www-306.ibm.com/software/rational/events/rsdc2007 e-mail: rsdcinfo@experient-inc.com

25 y 26 de Junio 2007 13 al 15 de Junio 2007

XVI Reunión Nacional de Directores de Escuelas y Facultades de Informática y Computación ANIEI Puerto de Veracruz, Veracruz Info: www.aniei.org.mx Tel: +52 (55) 5318 9358 e-mail: atencionasociados@aniei.org.mx

18 al 21 de Junio 2007

Better Software Conference and Expo Las Vegas, NV Info: www.sqe.com/BetterSoftwareConf e-mail: sqeinfo@sqe.com

www.softwareguru.com.mx

3er. Foro Nacional Innovación y Tendencias Tecnológicas CANIETI, ProduCen Grand Hotel Tijuana, Tijuana, B.C. Info: www.tendenciastecnologicas.com Tel: +52 (664) 686 2227 y 2627 e-mail: eventostijuana@canieti.com.mx

28 y 29 de Junio 2007

Leadership Strategies for a Collaborative High-Performing Culture Strategic IT Training Cycle, Cutter Consortium 28 de Junio - Hotel Camino Real, Monterrey, N.L. 29 de Junio - Hotel JW Marriott, Cd. de México Info: www.cutter.com.mx/ciclo2007 Tel: +52 (81) 2282 6266 y +52 (55) 5336 0418 e-mail: eventos@cutter.com

MAY-JUN 2007

// COLUMNA // COLUMNA

/*TEJIENDO NUESTRA RED*/

Tres Universidades, tres recuerdos Entre Culiacán, Hermosillo y Montevideo

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. Es fundadora de la AMCIS. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

principios de febrero, tuve oportunidad de visitar a la Facultad de Informática de la Universidad Autónoma de Sinaloa (UAS) en Culiacán. Los anfitriones prepararon una agenda muy variada. Una de las tareas que hicimos fue revisar con los profesores el contenido renovado del programa de estudios de la carrera de Ingeniería en Informática. La parte interesante que ofrece es la distinción de dos perfiles para los egresados: uno en Redes y otro en Desarrollo de Sistemas, acordes a las necesidades del mercado de trabajo local. La parte más discutida fue la integración de contenidos de cursos tales como Contabilidad, Administración o Economía para el contexto de las necesidades de la industria de software. A muchos nos queda clara la importancia de conocimientos básicos en estas áreas para los egresados. Sin embargo, los maestros que imparten los cursos, salvo notables excepciones, ofrecen el mismo contenido que en las carreras dedicadas a estos temas, lo que no siempre funciona. Uno de los puntos del nuevo programa donde más dudas tuve, es respecto a la inclusión de los cursos cuyo objetivo es preparar a los alumnos para ciertas certificaciones. En mi opinión, el deber de la universidad es preparar a los alumnos en fundamentos de tal manera que el esfuerzo adicional para pasar un examen de certificación no debería de ser grande, pero la universidad no debe enfocarse hacia certificaciones específicas. Otro tema importante es quién debe de cubrir los costos de la certificación. Creo que sería sano aplicar la regla “El que llama paga”, es decir el que quiere contratar y no el pobre (en ambos sentidos de la palabra) alumno. También tuve oportunidad de visitar dos incubadoras de empresas de desarrollo de software, una en la UAS y la otra en la Universidad de Occidente, ambas apoyadas con fondos PROSOFT. Me encontré con los alumnos o egresados muy inquietos y creativos, cuentan con el apoyo en capacitación, espacio, equipo y la supervisión de gente muy entusiasta asignada por FidSoftware de Sinaloa. Lo que yo agregaría al esquema de las incubadoras es la tutoría más directa de los maestros y/o de la propia industria en esa etapa inicial. También estuve sugiriendo que a los futuros empresarios se les pasen cuentas, de a mentiritas, por la renta de equipos, espacio, conexión a Internet, etc., para que estén concientes del valor económico del apoyo que reciben y les sirva de planeación de presupuestos a futuro. Tuve oportunidad de escuchar de primera mano el resumen de los avances y planes del cluster de Sinaloa FidSoftware. Tienen muchas iniciativas interesantes, por ejemplo, las de fomentar al mercado local. También me dio gusto escuchar que 10 empresas decidieron adoptar la norma mexicana. Las únicas sugerencias que podría hacerles son de aprovechar más a los maestros para la vinculación, y

MAY-JUN 2007

no solamente para la preparación de los egresados, e integrar los aspectos de calidad en el proceso educativo para no tener que cambiar ciertos hábitos después. Como anfitriones, los de la UAS se lucieron. Tuve una excelente atención y apertura en las pláticas. La comida, estupenda. Los huevos con chilorio o machaca, los camarones, las carnes, los mariscos y la brisa en Nuevo Altata quedaron muy grabados en mi memoria y en mi paladar. Al principio de marzo me tocó ir a la Universidad de Sonora en Hermosillo. En esta ocasión participé en una Semana de Matemáticas (¡!) con un curso sobre la norma mexicana para los alumnos y una conferencia general para los profesores. Un grupo de alrededor de 30 alumnos me sorprendió con sus conocimientos sobre MoProSoft, lo que nos permitió tener una comunicación más agradable y profunda. También los profesores de la carrera de Ciencias de la Computación me sorprendieron por su inclinación hacia la Ingeniería de Software y la preocupación por elevar sus conocimientos en esta área. Estuve con ellos nada más dos días pero logré confirmar que en Hermosillo las parrilladas son excelentes, las tortillas de harina son enormes y que el queso regional viene directo del rancho. COMPETISOFT me llevó a finales de marzo nuevamente a Montevideo, al lugar dónde se gestó este proyecto. La Universidad de la Republica de Uruguay me invitó a dar un curso intensivo de una semana para los alumnos de maestría. Aprovechando el viaje, organizaron un desayuno para la industria de software en el Club de Golf de Montevideo para presentar COMPETISOFT, CMMI e ISO9000. El interés que despertó este evento superó las expectativas de las organizadoras (que para variar fueron puras mujeres). El salón se llenó con más de 100 representantes de las empresas y áreas internas de informática y el calor de las preguntas me recordaba los tiempos de los Seminarios de Calidad de Software, que organizaba la AMCIS a finales de l os noventas. Nuestra propuesta y la experiencia mexicana llamaron mucho la atención, a tal grado que para el Taller de tres horas sobre el modelo de procesos se tuvo que buscar un salón para setenta personas. La Facultad de Ingeniería de la universidad me causó envidia por contar con el Instituto de Computación, lo que en la UNAM todavía es impensable. También tienen un Centro de Ensayo de Software. Este último, dedicado a pruebas de software, superó los dos primeros años de su vida subsidiada y está a punto de volverse autosuficiente. Quieren participar en pruebas de COMPETISOFT y parece que en esta nueva etapa los procesos de Gestión de Negocio, así como el resto de los procesos de Gerencia les caerán como anillo al dedo.

www.softwareguru.com.mx

Mis anfitrionas, Beatriz, Andrea y Raquel me llenaron de atenciones. Las carnes, pizzas y pastas acompañadas de buen Tannat aligeraron la carga de trabajo. El tiempo muy agradable de primeros días del otoño a la orilla del Río de la Plata, que parece más el mar que el río, permitió disfrutar las cenas al aire libre. Como observación general, veo con agrado el cambio generacional en los niveles directivos en las universidades visitadas. Gente entre 30 y 40 años, egresada de carreras y posgrados de Computación, empieza a salir con iniciativas que no siempre se ven con agrado por los viejitos como yo. Sin embargo, debo reconocer, que abren nuevas oportunidades para los alumnos y seguramente van a incidir en el futuro de la industria de software. Como feminista que soy, no puedo evitar mencionar la cantidad cada vez mayor de mujeres que están involucradas en estos esfuerzos, lo que me da enorme gusto y facilita los contactos. Por último, por más que nos digan que no es sana, la buena carne es lo que se puede disfrutar por igual en Sinaloa, Sonora y en Uruguay. — Hanna Oktaba

Foto del desayuno con la industria en Montevideo, Marzo 2007. Arriba: Abraham Davila, Juliana Herbert, Andrea Delgado, Hanna Oktaba, Jorge Triñanes, Ana Asuaga. Abajo: Raquel Abella, Monica Wodzislawski, Beatriz Pérez

// COLUMNA // COLUMNA

/*MEJORA CONTINUA*/

¿Área de calidad, o de cambio? La forma correcta de apagar incendios 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.

En el último par de meses he participado con algunas organizaciones para apoyarlas en su plan de calidad y mejora de procesos, y me preocupa mucho la frecuencia con la que me encuentro con áreas de calidad que se están dedicando a todo menos a lo que realmente deberían dedicarse. Comparto con ustedes un poco más de detalle sobre este fenómeno.

El rol del área de calidad Desgraciadamente, es común encontrarse con organizaciones donde se tiene la percepción de que el objetivo del área de calidad (AC) es el de asegurar la calidad de los proyectos. Esto no es correcto. Los líderes de proyecto y los encargados de la operación son los responsables de la calidad de los proyectos. La calidad de lo que hacemos no se puede delegar, es responsabilidad de la persona que ejecuta el trabajo. Entonces, ¿de qué se encarga el AC? El área de calidad se debe enfocar en cambiar la forma de trabajar de una organización para que refleje un mayor nivel de madurez en la forma de otorgar sus servicios. La problemática de AC tiene que ver con ¿cómo nos ponemos de acuerdo para coordinar lo que vamos a hacer de aquí en adelante, y cómo medimos la eficiencia de esos acuerdos? Este error no es meramente un problema de la dirección de la empresa. Muchas veces las personas que dirigen el AC se dejan llevar por lo urgente, olvidando su objetivo y su plan de trabajo. Desafortunadamente, una organización de nivel bajo de madurez dedica la mayor parte de sus esfuerzos a apagar fuegos, y las mismas personas del AC fungen como bomberos.

¿Cómo evitamos esto?

necesidad de un plan de trabajo y un análisis de riesgos es indispensable. Otra herramienta muy útil es el análisis de causas raíz, ya que nos ayuda a entender por qué las cosas están como están.

La forma correcta de apagar incendios Posiblemente ustedes ya hayan aplicado las recomendaciones anteriores, y aun así no hay forma de evitar que la organización los empuje a resolver incendios. En ese caso, lo que recomiendo es lo siguiente: • Dejar claro que aunque se va a apoyar el problema, lo que se está haciendo no es correcto. Hay ocasiones en que la organización está tan metida en apagar fuegos, que siente que esa es la forma normal de hacer las cosas y que nunca va a cambiar. Es responsabilidad del AC hacer visible el problema que se esta viviendo, y ayudar con la idea de que en un futuro cercano debe de resolverse el problema de raíz. • Tener siempre en cuenta la visión y objetivos. Debe de tenerse en cuenta el objetivo del área y buscar como es que el apoyo que se brindará, encaja con en el objetivo del AC. Por ejemplo, si vamos a ayudar a hacer el plan de trabajo de un proyecto, podríamos hacerlo junto con el líder, de forma que él aprenda como hacerlo de aquí en adelante. Si estamos ayudando a alguien, podríamos pedirle el favor de regreso cuando tengamos que implantar nuestras actividades en otra parte, etc. • Una vez resuelto el problema, debemos detenernos para que el equipo entienda que es lo que pasó y como prevenirlo en un futuro. Para cada una de estas situaciones necesitamos obtener las causas raíz del problema y comprometer a los encargados para asegurarnos de que el problema no vuelva a suceder.

Un AC con un bajo nivel de madurez, no puede llevar a una organización a mejorar. Es así que los mismos mecanismos que un AC está tratando de implantar en una organización, primero debe implementarlos internamente. Esto implica que el AC debe tener su propia misión y visión dentro de la organización, ¿a dónde van?, ¿por qué?, ¿cómo beneficia esto a la organización?, ¿cómo verificamos que lo estamos logrando?

• Finalmente, se debe de conversar con el “sponsor” del esfuerzo de calidad sobre lo que está pasando, y buscar su apoyo para solucionarlo. En muchas ocasiones él tiene la visión y el nivel dentro de la organización para que esto deje de suceder.

Esta visión debe de estar apoyada por objetivos claros y detallados. El objetivo más sencillo es “vamos a certificar a la organización en....”, pero desafortunadamente es demasiado general para lograr un movimiento real de la organización, y no puede competir contra emergencias que surgen en los proyectos. En cambio, un objetivo como: “estamos trabajando en como estimar los proyectos para que no se vuelva a vender un proyecto con pérdida” tiene mucho más posibilidades de tener éxito.

Creo que el nombre “área de calidad” es inadecuado y provoca confusión. Considero que sería mejor llamarla “área de cambio”, ya que esto deja mucho más claro su objetivo dentro de la organización. El cambio es algo que se debe de planear. La principal razón de que un esfuerzo de calidad no sea fructífero, además de falta de apoyo de la dirección, es que el área de calidad funcione como una organización de baja madurez.

Adicionalmente, el AC debe de tener claro su plan de trabajo. No importa que no se tenga un control directo de cuando nos van a dar tiempo para definir un proceso o lograr que todos sigan un proceso. La

MAY-JUN 2007

Conclusión

— Luis Cuellar www.softwareguru.com.mx

www.softwareguru.com.mx

MAR-ABR MAY-JUN 2007 2007

// PRODUCTOS

/* LO QUE VIENE*/

Google Ajax Feed API Oracle Data Integrator

Incorpora feeds a través de Javascript

Integración avanzada para ambientes complejos

Oracle anunció la disponibilidad de Oracle Data Integrator (ODI), un nuevo componente dentro de la familia de productos de Oracle Fusion Middleware. ODI es una herramienta para integración de datos diseñada para ambientes con grandes cantidades de datos dispersos en entornos heterogéneos. La herramienta está basada en la tecnología adquirida por Oracle mediante la compra de la compañía francesa Sunopsis el pasado mes de octubre. De acuerdo con Oracle, el objetivo de la herramienta es facilitar a las empresas la integración de datos para proyectos de business intelligence, data warehousing y master data management. Entre las fuentes de datos soportadas están aplicaciones de IBM, Microsoft, Netezza, Sybase, Teradata y Trillium. Para las organizaciones que requieren integrar sistemas en tiempo real, ODI brinda la flexibilidad de dar soporte a la sincronización de datos en tiempo real y batch mediante la tecnología change-data-capture. Mayor información en www.oracle.com/technology/products/oracle-data-integrator

Google lanzó el “Google AJAX Feed API”, el cual permite leer cualquier feed RSS o Atom público únicamente con javascript, además de que podemos interactuar con otras APIs de Google. Como sabemos, el uso de Javascript y XMLHttpRequest nos restringe el acceso únicamente a datos del mismo host que contiene la página HTML. En cambio, a través de este API podemos sobrepasar esta restricción, mediante el uso de los feeds. El API puede regresar los datos en formato JSON y XML e incluso podemos combinar ambos formatos. Para poder utilizar el API se requiere registrarse para contar con un API Key. Mayor información en code.google.com/apis/ajaxfeeds/

Debian Etch

Por fin llega la nueva versión

OpenID OpenID es un framework abierto y descentralizado para single sign-on. OpenID se basa en la idea de que los usuarios se identifiquen en Internet de la misma forma que lo hacen los sitios web, es decir a través de un URI. Al iniciar una sesión en Internet, el usuario se autentifica con el proveedor de su elección, y entonces es automáticamente reconocido por los sitios habilitados con OpenID. Para el usuario, esto implica el beneficio de tener una sola identidad digital y un solo mecanismo de autenticación (diferentes proveedores pueden utilizar diferentes mecanismos) para navegar en Internet, sin necesidad de estar haciendo “login” en cada sitio. Para los desarrolladores, el beneficio es que no necesitan crear una infraestructura de autenticación en su sitio, ya que delegan esto a los proveedores de OpenID. El concepto es similar a Windows Live Id. La diferencia con OpenID es que es un framework abierto y descentralizado.

Después de 21 meses de desarrollo finalmente fue liberada la versión 4.0 de Debian, un sistema operativo GNU/Linux reconocido por su estabilidad y solidez. Esta versión, que lleva el nombre clave “Etch”, soporta 11 diferentes arquitecturas de procesador e incluye capacidades muy atractivas. Uno de los aspectos en los que más se trabajó para esta versión fue el instalador. De hecho, el nuevo instalador soporta de forma fácil y transparente el uso de particiones encriptadas. Otra característica importante de esta versión es que el sistema de manejo de paquetes es mucho más seguro y eficiente. Etch viene con el kernel 2.6.18 e incluye versiones recientes de diversos paquetes de programas, tales como GNOME 2.14, KDE 3.5.5a, Xfce 4.4, GNUstep 5.2, X.Org 7.1, OpenOffice.org 2.0.4a, GIMP 2.2.13, Apache 2.2.3, Samba 3.0.24, Python 2.4.4 y 2.5, Perl 5.8.8, PHP 5.2.0, Asterisk 1.2.13, y más de otros 18.000 paquetes listos para usarse. Mayor información en www.debian.org

Mayor información en: openid.net

MAY-JUN 2007

www.softwareguru.com.mx

MAY-JUN 2007

// PRODUCTOS

/* A FONDO*/

Genero 2.0

Independencia para acelerar el desarrollo Por Pedro Galván

Genero 2.0 Four J’s www.4js.com, latin.4js.com

Calificación 4 de 5

Precio y disponibilidad •Ambiente de desarrollo: $5,000 USD por asiento. •Ambiente de ejecución: $400 USD por usuario concurrente. También hay licencias abiertas por servidor.

Requerimientos de sistema •Sistema operativo: Windows (2000/ XP/2003), Linux (Red Hat y SUSE), y OS X. •512 MB de RAM (recomendado por SG). •Procesador Pentium III o superior.

VEREDICTO Los 4GL han evolucionado y se mantienen vigentes como alternativa para desarrollar aplicaciones en aquellos casos donde no se necesite el control o flexibilidad de lenguajes de más bajo nivel. Genero destaca en este segmento debido a la independencia de plataforma, cliente y datos que provee. Genero Studio provee un ambiente integrado para facilitar y acelerar el desarrollo de aplicaciones Genero. Pros •Independencia de plataforma. •Las aplicaciones pueden ser generadas para diversos tipos de clientes •Soporta tecnologías modernas como XML y web services (SOAP). Contras •Lenguaje propietario. •Falta de soporte a Ajax.

MAY-JUN 2007

Como sabemos, los lenguajes de cuarta generación (4GL) tuvieron su auge hace poco más de una década, que es cuando tecnologías como Informix, Progress y Powerbuilder gozaron de mayor popularidad. Después, hacia finales de los 90s surgieron las aplicaciones web, que utilizaban nuevos lenguajes y tecnologías. Fue así que los 4GL comenzaron a ser relegados, hasta el punto de que muchos profesionistas de software los dieron por muertos. Pero los 4GL no se han ido. Siguen ahí. Y no solo se debe a que las empresas mantengan sus aplicaciones existentes, sino que también están haciendo nuevas aplicaciones con estas tecnologías. Es esta curiosidad de “¿por qué siguen existiendo los 4GL?” la que nos llevó a conocer más sobre estos productos, y evaluar uno de ellos. Analizando la oferta de proveedores de herramientas 4GL, vemos que aquellos que han sobrevivido, lo han hecho gracias a que han sabido evolucionar sus productos, incorporando las últimas tecnologías, de tal forma que puedan satisfacer las necesidades de los sistemas modernos. Uno de estos proveedores, que se ha mantenido vigente y actualmente goza de una buena posición en este mercado, es Four Js, y su producto insignia es Genero. Genero no es mercadeado como un 4GL –prácticamente ningún proveedor utiliza ese término hoy en día, debido a esa connotación de “extinto” que acarrea –, en cambio, es denominado como una “plataforma para el desarrollo acelerado de aplicaciones empresariales de alto desempeño”. Sin embargo, dado que podemos encontrar cientos de productos de muy distintas categorías que utilizan esa misma descripción, voy a evitarla. Es así que seguiré refiriéndome a Genero como un 4GL, obviamente con esa aclaración de que los 4GL modernos distan mucho de los 4GL que conocimos hace 15 años.

Obteniendo la versión de evaluación La gente de Four Js fue amable de proveernos un CD con una versión de evaluación. La verdad es que no quise usarla, ya que quería tener la misma experiencia que cualquier usuario. Así que fui al sitio web de Four Js para descargarlo y me encontré con una agradable sorpresa, y esta es que la versión de evaluación está disponible como instalable para Windows, instalable para Linux, imagen para VMWare, o como un .iso para crear un LiveCD. ¡Qué bien, a eso le llamo flexibilidad!

Panorama general de Genero El paradigma de desarrollo en Genero está orientado a lograr la independencia en tres sentidos: • Independencia de sistema operativo. • Independencia de tipo de cliente GUI. • Independencia de base de datos. Las aplicaciones en Genero son desarrolladas utilizando un lenguaje de alto nivel denominado Business Development Language (BDL), éste se compila hacia un bytecode independiente de plataforma, el cual es ejecutado por una máquina virtual, denominada Dynamic Virtual Machine (DMV). Este esquema de bytecode+máquina virtual es similar al que utiliza Java, y es así como Genero consigue la independencia de plataforma. Las aplicaciones de Genero pueden tener diferentes tipos de clientes, tales como un cliente desktop tradicional, cliente web a través de ActiveX o Java Applets, o cliente web puro a través de HTML y Javascript. La lógica de presentación se define a través de un

www.softwareguru.com.mx

Abstract Presentation Layer, que permite definir las pantallas y formas a través de XML, manteniéndolas así independientes de la lógica del negocio. En el caso de los datos, Genero incluye Genero DB, un motor de base de datos de alto desempeño. Sin embargo, Genero no nos obliga a tener que usar este motor, ya que a través de una interfase de acceso a datos denominada Open Database Interface (ODI), es posible que las aplicaciones en Genero tengan conectividad nativa a una variedad de bases de datos. De hecho, la lista de bases de datos me sorprendió, ya que no solo incluye los motores populares como Oracle o DB2, sino que también soporta bases de datos open source como MySQL y PostgreSQL. Entre las características que nos hacen ver que Genero busca mantenerse a la par de las tecnologías más recientes, está su capacidad para generar web services, de tal forma que las aplicaciones Genero pueden insertarse exitosamente dentro de un esquema de arquitectura orientada a servicios.

Genero Studio Genero Studio es el ambiente de desarrollo (IDE) para crear aplicaciones Genero. Provee todas las herramientas que podríamos esperar de un IDE moderno, tales como: • Un editor de código con chequeo de sintaxis y manejo de plantillas. • Una consola de proyecto para administrar los elementos de una aplicación. • Un depurador gráfico que se integra con el editor para dar seguimiento detallado a la ejecución del código. • Un diseñador de formas para editar visualmente las interfaces de usuario a través de drag-and-drop. • Un monitor de desempeño, que permite mapear el uso de CPU contra la ejecución de código, para así encontrar y resolver puntos problemáticos.

Genero Studio es el IDE para crear aplicaciones con BDL.

www.softwareguru.com.mx

MAY-JUN 2007

// PRODUCTOS

/* HERRAMIENTAS*/

Desarrollando código seguro con Visual Studio Explota las capacidades del Team Edition for Developers Por Marcos del Pozo

ctualmente somos testigos de la constante evolución del desarrollo de aplicaciones. Sin embargo, algo que también ha ido a la par de este crecimiento son las posibles amenazas que se pueden presentar, las cuales ponen en riesgo y hacen evidente las vulnerabilidades de una aplicación. Por esta razón, consideramos de vital importancia el incluir a la seguridad como parte del ciclo de vida del desarrollo de cualquier aplicación. Respondiendo a esta necesidad, los proveedores de herramientas de desarrollo están incorporando a sus productos capacidades para soportar la creación de código seguro. En el caso de Microsoft, podemos hacer referencia a Visual Studio Team System, y en específico a la edición “Team Edition for Developers”. Esta herramienta provee diversas capacidades para facilitar la escritura de código de mejor calidad, tales como: • Análisis de código. • Implementación de muestreo e instrumentación para el análisis dinámico de los programas en ejecución. • Análisis de cobertura de código. El análisis de código se enfoca en determinar “qué tan bien hecho” está un programa. Es decir, si se apega a estándares y buenas prácticas de programación y diseño. Adicionalmente, se pueden detectar posibles vulnerabilidades en el código, que serían difíciles de detectar en procesos de pruebas tradicionales. Cuando el análisis se realiza sobre código fuente u objetos compilados sin necesidad de ejecutarlos, se le denomina análisis estático de código. En contraste, el análisis dinámico requiere ejecutar el código para entonces monitorear su comportamiento. Team Edition for Developers incluye herramientas que analizan el código basándose en patrones de error que corresponden con reglas establecidas. Un detalle importante a distinguir con las reglas, es la flexibilidad que tenemos con la definición de las mismas, ya que podemos deshabilitar aquellas que no

apliquen a un proyecto en particular, o bien, crear nuestras reglas para buscar esquemas de código específicos. De esta manera, cuando ejecutamos el análisis y una regla detecta un problema en el código, se genera una advertencia o un mensaje de error, en función de la configuración de la regla. Veamos ahora a mayor detalle algunas herramientas que provee Visual Studio Team Edition for Developers para asistir el desarrollo de código seguro.

FxCop Es una herramienta para el análisis de código administrado que se encarga de checar “ensamblados” (assemblies) en .NET para ver si cumplen con los lineamientos de diseño del .NET Framework. Entre los principales aspectos que se verifican están: convenciones de nombre, diseño de bibliotecas, localización, seguridad y rendimiento. Para poder realizar esta tarea, FxCop se apoya de los espacios de nombre Reflection, la interpretación del MSIL y otros análisis. En cuanto a los aspectos de seguridad, FxCop se encarga de escanear el código en busca de vulnerabilidades, y también ayuda a prevenir que código malintencionado pueda aprovechar el desbordamiento del búfer en aplicaciones.

PreFast PreFast es otra herramienta incluida en el Team Edition for Developers que realiza análisis estático sobre código de C/C++, para detectar problemas como saturaciones de búfer, memoria no inicializada, problemas de secuencias de comandos de formato y comprobaciones de errores. Prefast es habilitado a través de la opción del compilador /analyze.

Application Verifier Para realizar análisis dinámico sobre código nativo o no administrado, podemos utilizar el Application Verifier. Esta herramienta analiza aplicaciones durante su ejecución para encontrar errores de programación. Su

propósito es detectar y ayudar a depurar corrupciones de memoria y vulnerabilidades críticas de seguridad. Application Verifier también se encarga de monitorear la interacción de la aplicación con el sistema operativo, midiendo el rendimiento del uso de objetos como el registry, el file system y APIs de Win32.

Comprobación de seguridad del búfer a través de /GS Las vulnerabilidades relacionadas con sobrecargas del búfer son bastante comunes, especialmente al usar lenguajes que permiten un control detallado de la memoria, como es el caso de C o C++. Para mitigar este riesgo, podemos recurrir a la opción del compilador de Visual C++ que se llama /GS. Esta opción se encargará de detectar saturaciones de búfer que sobrescriben la dirección de retorno, una técnica común para aprovechar código que no impone restricciones de tamaño de búfer. El mecanismo que utiliza es el de establecer un valor cifrado al final de un búfer. Este valor se comprueba durante la ejecución del código y si ha cambiado, se detiene la ejecución del programa y se genera una excepción de seguridad. Además, el uso de esta opción también protege frente a parámetros vulnerables pasados en una función. Un parámetro vulnerable es un puntero, referencia de C++ o estructura C que contiene un puntero, búfer de cadena o referencia de C++. Es importante expresar que de manera predeterminada, la opción de /GS está habilitada para el compilador.

SAL Además de las herramientas que hemos comentado, se puede realizar un análisis más exhaustivo a través del uso de una anotación especial como lo es SAL (Standard Annotation Language). A través de SAL podemos agregar anotaciones en los prototipos de las funciones, para describir en mayor detalle el comportamiento que esperamos de dicha

Marcos del Pozo Gómez actualmente colabora como Instructor Senior en la empresa Intersoftware. Cuenta con las certificaciones MCP, MCAD, y MCSD, y su especialidad es el desarrollo de código seguro y herramientas de desarrollo empresarial. Marcos es Ingeniero en Sistemas Computacionales egresado de la Universidad Tecnológica de México y su principal entusiasmo es poder sembrar semillas que impulsen el desarrollo de la tecnología en nuestro país.

MAY-JUN 2007

www.softwareguru.com.mx

función, sus parámetros y valores de retorno. Esto ayuda a que herramientas de análisis como PreFast, tengan mayor efectividad para encontrar errores y problemas de seguridad. El principal beneficio de usar SAL es que cualquier error que detecte, comúnmente será un error con alto grado de probabilidad de presentarse, y no solamente una suposición. El uso de cada una de estas herramientas está disponible a través de la configuración de las propiedades de cada proyecto en Visual Studio. Para revisarlo, vaya a la ventana Solution Explorer, seleccione la opción Properties del proyecto y después la opción de Code Analysis. Esto se aprecia en la siguiente figura.

Figura 1. Habilitando el análisis de código en Visual Studio.

Adicionalmente, cabe destacar que estas herramientas también están disponibles de manera gratuita e independiente, sin necesidad de recurrir a Visual Studio. Así que si les ha llamado la atención alguna de ellas, pueden comenzar a beneficiarse de su funcionalidad inmediatamente. Los invito a adoptar a la seguridad como parte del desarrollo de su próxima aplicación. Esto los beneficiará con aplicaciones menos vulnerables, y sobre todo más confiables.

Conclusión Es importante que veamos a la seguridad como un aspecto que debe ser incluido como parte del ciclo de vida del desarrollo de cualquier aplicación. Visual Studio Team Edition for Developers no es solamente una herramienta para la escritura de código sino también una de sus características principales será la de proveer un entorno que facilite la generación de código seguro.

Referencias •Security Guidance for .NET Framework 2.0. msdn2.microsoft.com/en-us/library/ms954725.aspx •Visual Studio Team Edition for Software Developers msdn2.microsoft.com/en-us/teamsystem/aa718809.aspx •Security Features and Tools msdn2.microsoft.com/en-us/security/aa570425.aspx www.softwareguru.com.mx

MAY-JUN 2007

Durante décadas, las empresas en México se han dedicado a copiar lo que se hace en otros países, o maquilar a un menor precio. Conforme nos insertamos en un mundo global, nos damos cuenta que esta es una fórmula perdedora, y que la única fórmula para el éxito sostenible es la innovación y la diferenciación. El problema es que no estamos acostumbrados a hacer esto, y mucho menos sabemos por donde empezar. Es en este momento que necesitamos líderes con mentalidad innovadora y experiencia haciéndolo, que nos ayuden a delinear ese camino. Probablemente esta la razón por la que Eduardo Ruiz Esparza fue recientemente elegido a la Presidencia Nacional de la Cámara Nacional de la Industria de Tecnología de Información (CANIETI). Para darnos una idea de quién es Eduardo y cuál es su mentalidad, basta con echar un vistazo a su trayectoria y antecedentes. Por lo pronto, estamos hablando de alguien con un doctorado en Ingeniería Industrial e Investigación de Operaciones por las Universidades de California Berkeley y Stanford, una maestría en Investigación de Operaciones de la Universidad de Karlsruhe en Alemania, y una maestría en Ingeniería Industrial por la Universidad de California Berkeley. Pero sus logros no se quedan en los estudios; después de haber ocupado cargos en Alfa Corporativo, Onexa-Grupo Telecomunicaciones y AT&T/Alestra, Eduardo fundó la compañía RFID México, una empresa de tecnología que tan solo con dos años de vida cuenta con seis desarrollos en proceso de obtener patente ante la United States Patent and Trademark Office (USPTO). Así que en resumen, podemos decir que Eduardo es un investigador, emprendedor, e innovador. Éste es el tipo de personas que queremos que nos ayude a delinear el camino.

Eduardo Ruiz Ezparza

MAY-JUN 2007

Investigador, emprendedor e innovador

www.softwareguru.com.mx

// ENTREVISTA

¿Por qué decidiste entrarle al reto de la presidencia de CANIETI? Se me hizo una oportunidad única de aportar algo al país. Siempre he sido muy mexicano, y no la podía desaprovechar. ¿La industria de TI en México debería buscar volumen o especialización? Se tiene que hacer una combinación. Al corto plazo tenemos la necesidad de generar empleos, pero al largo plazo debemos buscar nichos de mayor especialización y valor agregado. El gran atractivo de la industria de software es que con poca inversión es posible generar empleos de poca especialización, y eventualmente crecerlos hacia empleos de mayor valor agregado. ¿Crees que deberíamos especializarnos en algún nicho o alguna vertical específica? No te puedes especializar en todo. La única manera de competir con pocos recursos es siendo especialista en algún nicho. Puede ser una combinación vertical y nicho tecnológico. Es decir, te especializas en alguna tecnología específica, y ya dentro de eso buscas algún nicho vertical, como por ejemplo el sector automotriz, médico, o de enceres domésticos. ¿A nivel país deberíamos tener una especialización o buscar que cada región tenga su especialización? Al día de hoy, no podemos tener una oferta uniforme a nivel país, por la gran desigualdad que hay. Si te refieres a un plan a 10 o 15 años, entonces si podemos hablar de desarrollar capacidades similares en diferentes regiones, pero al día de hoy, ese no es el escenario. ¿Qué pasa con la innovación en México? Las organizaciones en México no estamos acostumbrados a innovar, ni a generar propiedad intelectual. Ni siquiera las universidades lo hacen. Ayer estaba leyendo que la UNAM hizo solamente 8 patentes en el 2006. Este número es casi el mismo que hizo mi empresa, una PyME minúscula. Por otro lado, veo el caso de algunos polos, como Nuevo León, Jalisco y Querétaro, donde se está generando un ecosistema con características que permiten romper ese paradigma de que la PyME no puede innovar y generar propiedad intelectual. Yo creo que sí se puede, pero tiene que ser buscando nichos, porque carecemos de los recursos para abarcar un espectro muy amplio. ¿Qué está haciendo la CANIETI para fomentar la innovación? La innovación es un aspecto de crucial importancia para CANIETI, y por esta razón hemos creado una nueva vicepresidencia dedicada a fomentar la innovación. Precisamente hoy tuve una plática ante la cámara de diputados, donde los exhorté a apoyar la innovación legislativamente. Mi petición fue que nos ayuden a liberar a México, a desencadenar nuestro potencial. Por otro lado, hemos estado hablando con gurús de innovación a nivel mundial para

www.softwareguru.com.mx

desarrollar y hacer llegar a las PyMES metodologías de innovación y diferenciación. ¿Qué podemos hacer para mejorar la formación de profesionistas? Creo que el sistema educativo debería hacer un énfasis mucho mayor en las ciencias básicas que el que se tiene actualmente. Lo que ha hecho a India exitosa es que su modelo educativo se enfoca fuertemente en ciencias básicas como las matemáticas y la física, y a eso agregan especialidades, como la del software. No debemos irnos con la finta de que la educación se debe enfocar exclusivamente al software. Las habilidades fundamentales las dan las ciencias básicas. El software es simplemente una especialización posible. El modelo Nearshore que ofertan varias empresas mexicanas se basa en la cercanía geográfica que tenemos con Estados Unidos, pero ¿qué tan sostenible es este diferenciador? Sabemos que la geografía es parte de la competencia de un país. En el caso de México, tenemos la bondad de ser vecinos del mercado más grande del mundo. Eso es sostenible, pero solo hasta cierto punto. Por ejemplo, tienes a Infosys, una empresa de la India que se establece en Nuevo León. Su estrategia mundial es colocar un grupo de gente en un país para aprovechar la cercanía geográfica con un mercado, pero buscando que la mayoría del trabajo se haga en India. Así que la ventaja del factor geográfico puede desaparecer. En balance a eso, empresas mexicanas como Softtek ya están buscando desarrollar en China, para tener las ventajas de diferencial de costo. ¿Qué recomendación le harías a un empresario mexicano? Yo le pediría que sin importar el tamaño de su empresa, siempre tenga en cuenta que eventualmente va a ser global. A lo mejor va a nacer en México, pero va a competir a nivel global. Para tener éxito en ese entorno requiere diferenciarse, y los diferenciadores se dan principalmente a través de innovación. Otra recomendación sería que no vea los recursos como algo que él debe tener todo el tiempo. Hay que tener una habilidad para manejar recursos sin necesidad de que estén bajo nuestra propiedad. Lo único que debe ser nuestro, es nuestro intelecto y lo que vayamos generando de propiedad intelectual. Todo lo demás (edificios, equipo, etc) puede ser prestado, rentado, o subcontratado. Palabras para los lectores Les pido que tengan mucha fe en sí mismos y en México. Somos un gran país, y con la participación de todos vamos a llegar muy lejos. Para esto, debemos ser innovadores y pensar globalmente.

MAY-JUN 2007

La Evolución del

Outsourcing en LATAM Staffing, Outsourcing y Servicios Compartidos Por César Vázquez

Actualmente, tanto la iniciativa privada como pública está muy familiarizada con la contratación de servicios externos para cubrir muy diversas actividades dentro de sus organizaciones. Sin embargo, el tipo de servicios y la clasificación de estos se encuentra en plena evolución en el mercado de América Latina.

César Vázquez es Product Manager para los Servicios de Outsourcing para la Región de México y Centroamérica con especialización en Servicios de Soporte y Mantenimiento de Aplicaciones Regionales y Globales en Softtek. Tiene 15 años de experiencia en Consultoría de TI. Es egresado de la Facultad de Ingeniería de la UNAM en la Carrera de Ingeniería en Computación. Su objetivo para los próximos 5 años es contribuir en el crecimiento y madurez de los servicios de outsourcing desde México para empresas regionales y globales.

MAY-JUN 2007

www.softwareguru.com.mx

n la industria de TI específicamente, la ampliación de las capacidades de las organizaciones a través de proveedores, inició con la incorporación de personal, mejor conocido como manpower o staffing, y ha evolucionado hacia modelos más maduros de Outsourcing, donde se cuenta con Acuerdos de Niveles de Servicio (SLAs). La adopción de estos modelos de Outsourcing en América Latina implica un cambio organizacional que no es sencillo, ya que contempla un cambio de paradigmas. Parte de la labor que deben efectuar los proveedores de servicios, es apoyar a implementar los cambios y estrategias necesarias para poder tomar ventaja de los beneficios que derivan los modelos de outsourcing, y así contribuir en los esfuerzos de madurar las organizaciones y los procesos de éstas. Entre las actividades que se recomiendan a un CEO, CIO o COO que busca establecer un esquema de outsourcing exitoso en su organización, destacan las siguientes: • Determinar el porque del outsourcing. ¿Por qué quiero llevar a cabo un programa de outsourcing como parte de mi estrategia organizacional? ¿Qué quiero lograr al implementar un programa de esta naturaleza? ¿Está lista la organización para llevarlo a cabo y obtener los beneficios que estoy buscando? Estos cuestionamientos son clave para poder darle dirección dentro de la organización, y así clarificar las expectativas tanto del cliente como del proveedor. Una estrategia de outsourcing cuyo propósito principal es minimizar costos varía radicalmente de aquella donde se busca un socio que colabore para incrementar la competitividad de una organización. • ¿Que área seleccionar para outsourcing? Más allá de las áreas evidentes como TI, una organización debe cuestionarse qué áreas tercerizar, tomando como base factores de valor agregado. Es decir, ¿donde están las áreas de oportunidad de mejora más evidentes, o las áreas de poco foco e interés? Recordemos que nunca se deben outsourcear las áreas estratégicas del negocio o de toma de decisiones. • ¿Cómo seleccionar a mi(s) proveedor(es) de servicios de outsourcing? El seleccionar al proveedor adecuado es el siguiente paso. Hoy en día, esta es una de las industrias más competidas a nivel mundial, y aún cuando la India es el líder indiscutible, existen en América Latina opciones como México, Brasil y Argentina, que se posicionan cada vez mejor. La selección ahora se ve afectada no solo por la madurez y éxito del proveedor, sino por el país que lo reswww.softwareguru.com.mx

palda (ambientes políticos, económicos y culturales principalmente), y cómo juega ese país en la estrategia de sourcing regional y/o global del cliente. Buscamos el servicio con los mejores recursos, en el lugar donde se genera más contribución a la cadena de valor del cliente y con un precio competitivo. De eso se trata el modelo de sourcing regional y/o global. Una vez establecida la estrategia y seleccionado el socio o proveedor, se define el ¿quién?, ¿cómo? y ¿dónde? En esta actividad podemos apoyarnos en la asesoría del proveedor de outsourcing, quien puede tomar un rol de mentor, dependiendo del servicio en cuestión, y la madurez de la organización que contrata. En el pasado era común ver a empresas determinar su estrategia de outsourcing basándose en su selección de proveedor de servicios como primer paso, sin haberse detenido a cuestionar el valor para su organización y los inminentes cambios que tendría que sufrir antes de ver los beneficios del programa realizado. Hoy en día sabemos que éste es el primer paso para ser exitosos en este ámbito. En los últimos cinco años, el incremento en los grupos de especialización en aplicaciones e infraestructura en los servicios de TI ha tomado gran importancia para las empresas en México y Brasil (líderes en la compra de estos servicios en la región). Esta tendencia manifiesta un claro nicho de mercado en el cual las empresas de TI han generado equipos de trabajo, de verdadero valor agregado para sus clientes. Aquí es donde algunas compañías de TI han logrado evolucionar el servicio de outsourcing a través de los modelos de “Servicios Compartidos”. Éstas han implementado con éxito grupos de especialistas focalizados a actividades y/o tecnologías que evolucionan rápidamente, y donde pueden brindar los servicios a diversas empresas al mismo tiempo, evitando los costos de la permanencia continua por la alta especialización de estos individuos. El outsourcing de servicios compartidos está siendo utilizado en un amplio espectro de necesidades, permitiendo que los objetivos de entrega, calidad y costo beneficien a las organizaciones que los utilizan. Los periodos de puesta en marcha y operación con beneficios tangibles varían entre uno y tres años, según el tipo y tamaño del modelo a implantar. Por ejemplo, si lo que se desea es simplemente generar un equipo base que se encargará de generar valor agregado a través del reuso de

conocimiento tecnológico de aplicaciones, procesos y metodología, un periodo de uno y medio a dos años será suficiente para ver redituados los beneficios del modelo. Sin embargo, si lo que se desea es que exista un grupo que trabaje como un “centro de excelencia” que provea servicios mundiales con autoaprendizaje, mejores prácticas y procesos de mejora continua, el tiempo de implantación con rendimientos cualitativos y cuantitativos no será menor a dos años y medio. Debo aclarar que la implantación de los servicios de outsourcing no ha sido un camino sencillo de recorrer para la mayoría de las organizaciones que los están utilizando y para los proveedores que los proporcionan. Sin embargo, precisamente aquí es donde se debe considerar la elección de un proveedor con la madurez suficiente que haya vivido buenas y malas experiencias, ya que sabría como administrar y mitigar los riesgos que se le presenten durante la implantación del modelo. No existe ningún proveedor de outsourcing que tenga el 100% de sus implantaciones exitosas, todos han tenido tropiezos y pocos han aprendido de estos.

Conclusión

Los beneficios de los servicios de outsourcing son reales y cuantificables, aunque típicamente el análisis de esto contemple actividades exhaustivas con diversas áreas de la organización, a las cuales nos les agrada la función de identificar los insumos y costos de las áreas o procesos a outsourcear, principalmente porque no son datos manejen cotidianamente. Los tomadores de decisiones deben tener identificadas y cuantificadas las mejoras tanto en servicio como en costo para sustentar y facilitar la adopción de una estrategia de outsourcing. Aunque actualmente más del 50% de las compras de servicios de TI en América Latina están relacionadas con staffing de personal, podemos concluir que las organizaciones de la región cada día están más abiertas a nuevos modelos de outsourcing, y menos lejos de la madurez del mercado más importante en la compra de estos servicios, por supuesto me refiero al de Estados Unidos. La madurez del outsourcing, seguirá residiendo en la práctica común de la compra de estos servicios y las organizaciones que no lo han iniciado tomarán ventaja de la experiencia que posean los proveedores experimentados, pero estarán postergando los beneficios que muchas otras organizaciones ya están recibiendo. MAY-JUN 2007

no todo lo que brilla es Escogiendo proyectos para offshore outsourcing

oro

Por Artemio Mendoza

l servicio de offshore IT outsourcing, como se conoce en Estados Unidos, puede definirse como la administración y desarrollo de la infraestructura de TI a distancia. Estos servicios abarcan distintas actividades, tales como: • Desarrollo de Software a distancia • Administración remota de aplicaciones • Desarrollo y mantenimiento de aplicaciones • Servicios de Internet El modelo de offshore outsourcing ha venido evolucionando significativamente a lo largo de las dos últimas décadas. La primera generación de estos servicios consistía típicamente en mantenimiento y migración de sistemas legacy. Después, a medida que la confianza en las capacidades de los proveedores offshore creció, los compromisos se movieron a la segunda generación, al punto de asignar proyectos comerciales offshore. Actualmente, la tercera generación de offshore outsourcing ofrece mejoras sustanciales en generación de valor y en la entrega. Así pues, a lo largo de los años este nuevo esquema fue consolidándose y actualmente es una industria madura.

El offshore outsourcing de servicios TI es sin duda un modelo al que cada vez recurren más y más empresas en todo el mundo. De acuerdo con estudios de NASSCOM y McKinsey, en el 2006 este mercado a nivel mundial rondó los 21 mil millones de dólares, manteniendo tasas de crecimiento superiores al 25% en los últimos tres años. Se espera que mantenga un crecimiento similar en los próximos cinco años, de tal forma que supere los 100 mil millones de dólares antes del año 2012. Como sabemos, India es el país lider en este mercado, con una participación cercana al 65%.

Tampoco todos los proyectos son elegibles para ser desarrollados en offshore outsourcing. La Figura 1 muestra una matriz que indica cuáles proyectos son buenos candidatos para hacer en outsourcing, y cuáles no. En el eje vertical tenemos el esfuerzo requerido, y en el eje horizontal la cantidad de interacción requerida con los usuarios. Esto nos da cuatro cuadrantes, y en cada cuadrante se tiene una recomendación acerca de la estrategia que se debería tomar. (Ver Figura 1)

Eligibilidad de los proyectos: enfoque empírico

Teoría de costos de transacción y el Outsourcing como estrategia interorganizacional

Aunque el outsourcing es muy popular, hay que tener en cuenta que no todas las organizaciones se pueden beneficiar de éste. Las desventajas de este modelo pueden acarrear serios problemas a aquellas organizaciones que no lo comprenden ni manejan adecuadamente. Adicionalmente, las empresas deberían tener mucho cuidado cuando se trata de dar en outsourcing aplicaciones o desarrollos que implican ventaja competitiva, ya que se corre el riesgo de perder ese conocimiento.

La teoría de costos de transacción explica la interacción entre las transacciones del ambiente y el diseño organizacional. Establece que la meta de una organización es minimizar los costos de intercambiar y administrar recursos dentro de la organización. De acuerdo a dicha teoría, cada dólar u hora invertida en las actividades que tienen que ver con el intercambio de recursos y su administración, es dinero y/o tiempo perdidos, pues no está siendo usado para crear valor, sino que es un “mal necesario”.

Artemio Mendoza es Director Global de Operaciones de Tae IT, empresa de la cual es socio fundador. Durante más de quince años se ha desempeñado como consultor, gerente y director en empresas de tecnología en México, Estados Unidos y España para clientes como GE Plastics, McKinsey & Company, Bancomer, AT&T, Goodyear y Bimbo. Artemio tiene el grado de Maestría en Administración de TI, otorgado por el Tec de Monterrey.

MAY-JUN 2007

www.softwareguru.com.mx

offshore-outsourcing, también existe el modelo de Charles Perrow. Este modelo se basa en dos dimensiones que identifican las diferencias de tareas y tecnologías, complejas o simples, rutinarias o no rutinarias. Dichas dimensiones son la variabilidad de las tareas y la capacidad de que sean analizadas. En la figura 2 se muestran las dos dimensiones, así como los cuadrantes que se generan debido al cruce de ellas. Cada uno de estos cuadrantes identifica un tipo de tecnología diferente. ( Ver Figura 2)

• Proyectos de Investigación no rutinaria. Este tipo de proyectos están principalmente compuestos por tareas de alta variabilidad y baja capacidad de ser analizadas. Son los proyectos más complejos y menos rutinarios dentro de este modelo. Cada nueva situación crea la necesidad de gastar recursos para resolverla. Los proyectos de desarrollo de software a la medida, y en particular de aplicaciones e-business, es un ejemplo de proyectos de este tipo. En resumen, los proyectos de manufactura rutinaria, así como los proyectos de Ingeniería de producción (utilizando ingeniería de software) son candidatos a ser desarrollados utilizando el modelo offshore outsourcing, mientras que los proyectos artesanales y los de investigación no rutinaria no son adecuados para ello.

Figura 1. Clasificación de proyectos de acuerdo a la factibilidad de ser desarrollados en outsourcing. Fuente: [Amoribieta, 2001].

La teoría de costos de transacción puede ayudar a escoger las estrategias interorganizacionales de las empresas. Permite hacer un balance entre el ahorro de costos de transacción y los costos burocráticos que se generan al utilizar diferentes mecanismos de vinculación interorganizacionales. Para ello, se propone seguir los siguientes pasos: 1. Localizar la fuente de costos de transacciones que pueden afectar una relación de intercambio y decidir cuan elevados pueden llegar a ser. 2. Estimar el ahorro en costos de transacción al utilizar diferentes mecanismos de vinculación 3. Estimar los costos burocráticos generados por operar los mecanismos de vinculación 4. Escoger el mecanismo de vinculación que produzca el mayor ahorro en costos de transacción al menor costo burocrático posible. De esta manera, una organización debería escoger realizar una fusión o adquisición con sus distribuidores o proveedores únicamente cuando el ahorro en los costos de transacción sea mayor que los costos burocráticos que se generarían debido a la nueva estructura. Desde este punto de vista, el outsourcing es un mecanismo de vinculación que le permite a las organizaciones evitar los costos burocráticos y minimizar los costos de transacción.

Teoría de Charles Perrow y los tipos de proyectos Mientras que en la figura 1 se presenta un modelo empírico de qué proyectos pueden ser candidatos para ser desarrollados en

www.softwareguru.com.mx

La variabilidad de la tarea se refiere al número de excepciones (situaciones nuevas o inesperadas) que una persona encuentra durante la ejecución de una tarea. La capacidad de que una tarea sea analizada es el grado de investigación requerido para resolver un problema. Extrapolando la teoría de Perrow a los proyectos de desarrollo de software, se obtiene una clasificación de cuatro tipos distintos de proyectos: • Proyectos de manufactura rutinaria. Caracterizada por tareas de baja variabilidad y alta capacidad de ser analizadas. Existen pocas excepciones en los procesos de trabajo y, cuando ocurre una excepción, se necesita un comportamiento inquisidor muy pequeño para lidiar con ella. La producción de software para consumo masivo es un ejemplo. • Proyectos Artesanales. Tareas de alta variabilidad y baja capacidad de ser analizadas. Existen muy pocas excepciones y se necesita mucha investigación para encontrar soluciones a los problemas. La implementación de paquetes tipo ERP es un ejemplo de este tipo de tecnología. • Proyectos de Ingeniería. Tareas de alta variabilidad pero alta capacidad de ser analizadas. Existen muchas posibles excepciones, sin embargo es relativamente fácil encontrar soluciones puesto que han sido estudiadas previamente y se encuentran documentadas. Los proyectos de help desk son un ejemplo de este tipo (aunque en estos proyectos hay un porcentaje muy pequeño de actividades que requieren una alta capacidad de investigación para encontrar la solución).

Figura 2. Cuatro tipos de tecnologías de acuerdo a la teoría de Charles Perrow.

Conclusión

A través de este artículo he presentado diferentes modelos para apoyar la elección de proyectos para ser desarrollados en un esquema de outsourcing. Espero que les sea de utilidad, ya que así como hay muchas historias de organizaciones que han obtenido grandes beneficios gracias al outsourcing de TI, también hay numerosas historias de malas experiencias, las cuales en gran parte se deben a que se seleccionaron proyectos inadecuados para trabajar en este esquema.

Referencias

• Amoribieta, I., et al. “Programmers Abroad: A Primer On Offshore Software Development”. McKinsey Quarterly, 2001. www.mckinseyquarterly.com • NASSCOM. Indian IT Industry 2007 Factsheet. www.nasscom.in

MAY-JUN 2007

modernización de

aplicaciones Otra posibilidad de outsourcing Por Enrique Herrera

Cómo modernizar un negocio de una manera rápida, fluida y no costosa? Esta es una pregunta que cada vez más gerentes –especialmente los de Tecnología de Información– se hacen. En la actualidad, casi 70 por ciento de los sistemas de TI empresariales corporativos son sistemas legados (es decir, sistemas con aplicaciones diversas que se van “heredando” con el tiempo y que se van acumulando de manera caótica). A pesar de que estos sistemas suelen ser críticos para el desempeño de funciones empresariales, comúnmente se encuentran en un estado de obsolescencia, son inflexibles y suelen estar bajo un alto riesgo de falla. Estas plataformas con frecuencia son el producto de más de 2 décadas de uso y abuso de aplicaciones, resultando en un ambiente de información caótico que nos vemos obligados a enfrentar cada vez que buscamos optimizar la seguridad de la información, la continuidad del negocio, la eficiencia y la eficacia.

Es respondiendo a esta necesidad que las empresas de servicios TI han desarrollado la oferta de modernización de aplicaciones. El objetivo es maximizar el valor de las aplicaciones descontinuadas mientras las mueven rápida y eficientemente a plataformas modernas. Es decir, diversos procesos son combinados con capacidades y herramientas tecnológicas para migrar aplicaciones desde ambientes obsoletos a tecnologías modernas. Estos servicios manejan todo el ciclo de vida del proyecto, apoyan plataformas específicas, y apalancan las mejores prácticas de las industrias a través de la infraestructura de migración acelerada. Los beneficios que traen estos servicios son: reducción de costos totales, preservación del valor comercial de activos descontinuados, retención del capital intelectual de la organización, reducción en los riesgos de usar sistemas avejentados, nueva funcionalidad y sistemas externos, y mejor competitividad usando tecnología moderna para aumentar los servicios del negocio, entre otros.

Enrique Herrera es actualmente el Director de Entrega de Aplicaciones para EDS México. Anteriormente fue responsable de los Centros de Soluciones en México, América Central y Región Andina. En este período, Enrique condujo el Centro de Soluciones en la Ciudad de México al nivel CMM 3 y el Centro de Soluciones de Ciudad Juárez al nivel CMM 4. Enrique se graduó de la Universidad Iberoamericana como Licenciado en Sistemas Administrativos de Computación, y cuenta con un Postgrado (AD-1) del IPADE.

MAY-JUN 2007

www.softwareguru.com.mx

El proceso de modernización Como primer paso, la racionalización de aplicaciones proporciona un meticuloso análisis del universo de aplicaciones (portafolio de aplicaciones) de un cliente, basándose en entrevistas y análisis a fondo de la estrategia empresarial, enfocándose en cálculos del valor de los sistemas para el negocio y en análisis técnicos cuantitativos de los programas. La racionalización de aplicaciones constituye un plan de acción para el portafolio de aplicaciones del cliente: cuáles aplicaciones deben retirarse, cuáles deben continuar operando, a cuáles hay que construirles una nueva arquitectura, a cuáles hay que proporcionarles una nueva interfaz y cuáles deben ser sustituidas con paquetes como parte del esfuerzo de modernización. Lo más probable es que las aplicaciones que deban modernizarse sean sistemas que tengan un valor crítico para el negocio, pero que operen a niveles tecnológicos relativamente bajos y/o con altos costos de propiedad. Como resultado del proceso de racionalización se genera un plan detallado de todas las aplicaciones que deberán ser modernizadas y un caso de negocio con el cual se muestren los beneficios que se obtendrán del proceso de modernización. Ambos elementos son estratégicos ya que es lo que proporciona certidumbre de que las acciones que se realizarán tienen una lógica, se minimizan los riesgos y sobre todo existe una razón de negocio (financiera, mercado, operativa, administrativa, entre otras) que lo justifica y donde quedan claros los beneficios esperados como pueden ser ahorros e incrementos de productividad. El siguiente paso es ejecutar el plan de modernización. Dependiendo del objetivo de la modernización, se puedan aplicar una o más de las siguientes técnicas: • Optimizar la aplicación. Se eliminan problemas y vicios que la aplicación tiene y donde el objetivo final es incrementar su desempeño y reducir los problemas que genera. • Incrementar el valor de la aplicación. Por medio de nuevas tecnologías se permite incrementar la funcionalidad la aplicación sin tener que modificarla. • Reubicar la aplicación. Se mueve la aplicación de un ambiente obsoleto, que es bastante caro de manera general, a un ambiente moderno cuyo costo es mucho más competitivo. • Reconstruir la aplicación. Por medio de herramientas de software se reconstruye la aplicación pero en una tecnología mas moderna y de un costo competitivo. • Remplazar la aplicación. Se remplaza la apliwww.softwareguru.com.mx

cación existente por paquetes ya existentes en el mercado y que tienen un reconocimiento a nivel internacional.

Servicios que acompañan a la modernización de aplicaciones Es muy común recurrir a una empresa externa que realice diferentes servicios de apoyo para la modernización de aplicaciones. Entre los servicios más comunes están: 1. Servicios para el outsourcing de aplicaciones. Estos servicios ofrecen la flexibilidad para los clientes que deseen aplicar el outsourcing en una o más aplicaciones de su portafolio. Se usa un enfoque de tres fases: evaluar las aplicaciones y su ambiente, transformar la organización de soporte a aplicaciones y administrar las aplicaciones para una mejora continua. Estos servicios permiten a los clientes evolucionar sus portafolios de aplicaciones, dando como resultado el enfoque total por parte de los clientes en el área central de sus negocios y conseguir mejores rendimientos de sus inversiones. 2. Servicios de racionalización de aplicaciones. Estos servicios ayudan al cliente a alinear sus portafolios para apoyar mejor a sus negocios. Se evalúa la colección de aplicaciones que tiene el cliente, e identifica áreas problemáticas, redundancias y oportunidades para hacer un mejor uso de los recursos. A su vez, se provee un mapa para simplificar y modernizar un portafolio de aplicaciones para optimizar la inversión en TI del cliente. Estos servicios se basan en la consolidación, transformación, y el alineamiento de recursos de aplicaciones, para así, identificar maneras de reducir costos y complejidad en el portafolio de aplicaciones, mejorar su rendimiento y disponibilidad, redirigir el presupuesto de TI del mantenimiento a nuevas iniciativas de TI, y finalmente alinear el portafolio con las metas del negocio, y no con restricciones tecnológicas. 3. Servicios de inteligencia comercial. Estos servicios comprenden procesos, tecnologías y herramientas para convertir datos en información, y de esta forma permitir a las compañías tomar mejores decisiones. Los servicios de inteligencia comercial se pueden enfocar en: • Determinar las necesidades analíticas y de información del cliente, identificando los datos requeridos. • Adquirir, limpiar, aumentar y transformar estos datos para que se puedan analizar. • Implementar e integrar las herramientas requeridas para adquirir, almacenar y analizar la información.

4. Aplicaciones compuestas y servicios de portal. Las aplicaciones compuestas son soluciones aplicativas cuya funcionalidad es tomada de varias fuentes dentro de una arquitectura orientada a servicios. Los componentes pueden ser servicios web individuales, funciones seleccionadas de otras aplicaciones, o sistemas completos cuya producción ha sido empaquetado como servicios web. De esta forma, se otorga un acceso fácil a aplicaciones y datos, brindando puntos de entrega claves para la automatización de procesos, acelerando la innovación, reduciendo costos, y produciendo más eficiencia en el desempeño de la compañía. 5. Servicios de integración comercial. Estos servicios permiten que la información sea compartida uniformemente entre varias compañías, integrando procesos, aplicaciones y datos, lo que permite intercambiar información entre consumidores, socios y proveedores. Estos servicios brindan una construcción de la arquitectura de TI más rápida, costo total más bajo, reducen el tiempo de interfaz y el costo de mantenimiento y de transacción de negocio a negocio, eliminan redundancia de aplicaciones, y mejoran la productividad del usuario.

Conclusión

La compilación de todos estos servicios hace que las compañías puedan modernizar sus aplicaciones de una manera eficaz, rápida, segura y de bajo costo de tal forma que se convierten en empresas ágiles. Esto permite: • Mejor manejo de costos y rendimiento de la inversión, con un menor costo de propiedad total. • Preservación del valor para el negocio de los activos legados y su capital intelectual. • Menor riesgo empresarial al minimizar los sistemas legados costosos de manejar. • Mejor posición de competitividad mediante servicios empresariales mejorados con base en la tecnología moderna. • Contar con un esquema de autofinanciamiento de una buena parte de la inversión debido a que los ahorros de las primeras etapas del programa contribuyen a financiar las mejoras subsecuentes. En esta era, donde la vida de los negocios es una constante carrera para mejorar los servicios y productos brindados a los clientes, la modernización de aplicaciones es un factor clave en la evolución de las empresas. Estos servicios dan una mano con experiencia que lleva paso a paso a las empresas hacia su meta final, la cual se basa en menores costos y mayor rendimiento. MAY-JUN 2007

haciendo

mas con menos

El Outsourcing cobra más fuerza que nunca Por Carlos Aguilar Weber

n la época del “do more with less” (hacer más con menos), el outsourcing cobra más fuerza que nunca, y en un país como México, donde los ejecutivos están continuamente presionados para generar mayor productividad, el outsourcing es una herramienta de gran utilidad. En los corporativos nacionales el outsourcing ya no solo se reduce a staffing o manpower, sino que ya podemos observar a empresas que sacan el máximo provecho a esta tendencia en sus áreas de TI, o subcontratando la realización procesos de negocio no críticos (BPO).

Beneficios del outsourcing Entre los principales beneficios del outsourcing, resaltan los siguientes: • Dedicación al negocio. La empresa logra enfocarse exclusivamente en los procesos de negocio que son su razón de existir. La contabilidad, la nómina, el transporte de mercancías, el servicio posventa, los procesos tecnológicos, etc., son servicios que pueden ser proporcionados por especialistas y a la larga pueden representar una mejor respuesta de la empresa a los mercados. • Acceso a nuevas tecnologías. Este tipo de servicios permite a las empresas tener acce-

so a tecnología actualizada y productiva que de otra manera les resultaría casi imposible de adquirir. En cambio, a través del outsourcing una empresa dispone de opciones de renta, asesoría y respaldo tecnológicos con tecnologías modernas, que le permiten estar a la vanguardia, a costos relativamente menores que si tuviera un departamento de informática interno. • Personal siempre capacitado y con experiencia. Al contratar a un especialista externo, la empresa está adquiriendo servicios de profesionales expertos en el área y con gran probabilidad de estar actualizados.

Carlos Aguilar Weber, es Director de Neoris México, compañía consultora en TI que maneja centros de nearshore en Argentina, Hungría y México, y que se ha posicionado como líder al prestar servicios a sus clientes en una extensa variedad de industrias. Carlos cuenta con más de 13 años de experiencia en todos los aspectos de TI así como en temas de outsourcing de aplicaciones para Latinoamérica y Estados Unidos.

MAY-JUN 2007

www.softwareguru.com.mx

• Eliminación de altos costos de entrenamiento y educación. Los profesionales externos son los primeros responsables de capacitarse a sí mismos. • Flexibilidad en el proceso. Al confiarse una tarea a un experto, la empresa puede tener la seguridad en que el proceso será mejor realizado que si lo hiciera ella misma. La implantación de los cambios en los procesos es inmediata, los especialistas pueden controlar los procesos en forma experimentada. En resumen, la suma de todos los puntos anteriores debe reflejarse en una disminución importante en el costo total de propiedad de un proceso o servicio de negocios a ser tercerizado.

Mercado y tendencias De acuerdo a Gartner, para el año 2015, un tercio de los trabajos relacionados con servicios tecnológicos se ubicarán en países emergentes, como China, India y México. Habrá mayor volumen de servicios por las relaciones de negocios en el mundo, experimentando un crecimiento de 7.3 por ciento en la tercerización tecnológica hasta el 2009. El BPO (Business Process Outsourcing) se vuelve una nueva área de crecimiento que añade más valor. Proyectos grandes, con varios años de duración, todavía son parte de los contratos importantes; sin embargo, para la empresa promedio, el crecimiento de outsourcing selectivo de corto plazo dará paso a un nuevo enfoque de “mejor en su tipo” a medida que las unidades de negocio influyan más sobre las decisiones en torno al outsourcing. La calidad, costo y tipo de servicios también está mejorando. Por ejemplo, en el 2006, los servicios de outsourcing en TI fueron hasta 50 por ciento más accesibles que en el 2001, ofreciendo muchos más valores agregados que los que se brindaban hace 5 años. Este crecimiento ha permitido que hoy en día, cualquier empresa en cualquier industria pueda acceder a infraestructura tecnológica de clase mundial y de última generación para elevar sus estándares de competitividad a niveles internacionales.

Definiendo la estrategia Más que moda o novedad, el outsourcing presenta hoy en día una mayor variedad de

www.softwareguru.com.mx

usos para ayudar a las empresas a cumplir con los niveles de eficiencia, innovación y productividad requeridos. Tendencias como el near-shore implican oportunidades, pero también retos. Los usuarios deben hacer una pausa para analizar su estrategia, elegir y explotar las cualidades del outsourcing de la manera más apta para su negocio y analizar los principales diferenciadores de los proveedores de este servicio, tales como la innovación para resolver problemas complejos, poseer el conocimiento sobre el tema en particular y combinar los procesos de negocio con la tecnología de última generación para crear valor. La perspectiva con que los tomadores de decisiones analizan el impacto de estos servicios va más allá de lo técnico. La visión es hacia el negocio; para lo cual es preciso mantenerse actualizados sobre sus novedades, cualidades y tendencias para que su empresa pueda sacar el mejor de los beneficios. Al momento de tercerizar un proceso es muy útil asesorarse con un experto para definir los alcances del mismo, garantizar la continuidad de las operaciones y la especialización en los servicios. Existen en el mercado prácticas enfocadas a la mejora continua que pueden ser de utilidad al momento de decidir qué se debe tercerizar, y con qué tipo de proveedor. Algo importante a considerar es que si en un momento dado la decisión no coincide con el objetivo, hay que revisar por qué. Probablemente las prioridades hayan cambiado, o las decisiones no fueron las correctas; y ese, es el momento para rectificar.

Diferentes modelos Existen múltiples connotaciones de los servicios que se pueden contratar así como diferentes modelos de gestión de los mismos; el pleno entendimiento de estas variaciones y particularidades puede representar la diferencia entre conseguir un contrato exitoso para su empresa o hacerse de un problema de gestión en su área de informática. Examinemos algunos modelos de outsourcing existentes: • Modelo On-Site . Bajo esta categoría, los servicios son entregados directamente en las instalaciones del cliente. En muchos casos los receptores finales del servicio ni

siquiera saben que la persona que los está atendiendo es un externo. Este modelo tiene un alto nivel de personalización, pero minimiza considerablemente la posibilidad de disminuir costos. • Modelo Off-Site. En este modelo el proveedor generalmente se encuentra ubicado geográficamente en la misma ciudad que el cliente. Lo servicios se proveen de forma remota, aunque dada la cercanía es posible atender servicios de campo bajo solicitud. Esta variable permite alcanzar un buen nivel de personalización. • Modelo Near-Shore. Los servicios son proporcionados desde un país cercano al país del cliente. Este esquema se utiliza cuando existen países vecinos con tarifas más atractivas que las que se pueden encontrar en el país propio, y existe el personal capacitado para proveer el servicio. Generalmente, se busca que ambos países compartan características similares tales como zona horaria, idioma y/o rasgos culturales que permitan una mejor integración cliente-proveedor. Con este modelo también se puede alcanzar un buen nivel de integración, con acceso a tarifas y costos muy atractivos, pero es complicado proveer servicios de campo si es necesario. • Modelo Off-Shore. Por lo general, este modelo es utilizado cuando se busca maximizar los beneficios económicos, ya que se puede buscar la mejor relación costo-valor prácticamente en cualquier parte del mundo. Los servicios se proveen de forma completamente remota, utilizando tecnologías de comunicación y colaboración de última generación. Antes de seleccionar un modelo de este tipo deben considerarse cuestiones geográficas, tecnológicas y culturales, ya que se pueden presentar barreras que impidan la entrega de servicios de alta calidad.

Resultados

De acuerdo con cifras de consultoras el 74% de los clientes con experiencia en outsourcing está satisfecho con los resultados de un acuerdo de terciarización obtenido el año anterior. Estos usuarios afirman que el grado de satisfacción va aumentando con el tiempo. Mi experiencia es que los clientes de outsourcing se concentran en tres objetivos: reducción de costos, mejora de los procesos y la capacidad de enfocarse en su negocio básico.

MAY-JUN 2007

Administrando el cambio para el éxito Por Raul Quiroz Betancourt

del insourcing al

outsourcing

xisten varios modelos de Outsourcing, pero de todos ellos podemos decir que hay uno en particular que conlleva una complejidad añadida. Este modelo hace referencia a la transición del Insourcing al Outsourcing. Su particularidad estriba en que casi siempre está asociado con el traspaso de personal de la empresa que contrata el servicio a la compañía que se hará cargo de su ejecución. Una transición como ésta, que no considere una gestión del cambio eficiente y controlada, puede generar riesgos y costos significativos, afectando así el logro de los niveles de servicio esperados. Este cambio es muy complicado, ya que los recursos de un día pasan de ser compañeros a proveedores, de amigos a consultores y en este cambio se debe jugar con la incertidumbre que produce el movimiento de compañías, las motivaciones, el cambio cultural de empresas, las expectativas de desarrollo profesional, sus nuevas condiciones contractuales y económicas…. Son variables que solemos olvidar o darles poca importancia y que son fundamentales para llevar a buen termino proyectos que pueden ser de alto riesgo. Hay variables importantes que se deben tomar en cuenta como la comunicación, los procesos, los recursos técnicos, la tecnología, los nuevos

sistemas de gestión. Si estas variables no son gestionadas eficientemente, podremos tener un gran proyecto fracasado en su toma de control y un conflicto continuo en el día a día. Para lograr éxito en este proceso de transformación operacional y cultural, no debemos olvidarnos que hay varias variables en juego y que todas y cada una de ellas deben ser tomadas en cuenta para que este proceso no falle y genere dudas en su viabilidad. La transición toma tiempo, que dependerá en su gran mayoría de la complejidad del negocio y de su infraestructura. Cuanto más tiempo, mayor será la incertidumbre en los recursos y un mayor nivel de gestión de cambio será necesario.

Iniciemos con un Diagnóstico El primer paso primordial a desarrollar, consiste en realizar un diagnostico de la situación, considerando al menos tres variables fundamentales: Procesos y Procedimientos, Tecnología, y Recursos Humanos El objetivo de este diagnostico es analizar la brecha entre la situación actual y la situación objetivo, recabando información que nos permitirá conocer en detalle cada uno de los puntos a evaluar. Con esta recopilación se deben elabo-

rar planes específicos para facilitar la evolución al nuevo esquema, determinar los riesgos que podrían afectar al proceso y preparar planes de contingencia o tener previstas acciones que permitan minimizar el riesgo en cada una de las fases del proceso. Procesos y Procedimientos. Es importante recolectar e inventariar los procesos y procedimientos de la organización, pues nos permite tener un conocimiento del nivel de maduración e ir completando un catalogo de los existentes y faltantes, así como ir desarrollando en paralelo un plan de implantación de los mismos. Tecnología. Un inventario de todo el Hardware y Software permite conocer la infraestructura sobre la cual se tomara el control (si este es el caso) y determinar los puntos de riesgo. Algunos puntos a analizar son los siguientes: • Regularización de Licenciamiento • Situación en cuanto a contratos de mantenimiento y nivel de los mismos • Obsolescencia de Infraestructura • Alta Disponibilidad • Planes de Contingencia La recolección y análisis de esta información permitirá definir desde un inicio: responsabilidades, planes de inversiones y acuerdos en cuanto a niveles de servicio.

Raúl Quiroz Betancourt es responsable de outsourcing en INDRA Mexico. Tiene más de 20 años de experiencia como consultor, de los cuales los últimos 8 han estado enfocados en proyectos de outsourcing en más de 7 países. Raúl es Ingeniero de Sistemas y Master en Sistemas por la Universidad Politecnica de Madrid, También cuenta con un MBA por la Universidad Autónoma de Madrid.

MAY-JUN 2007

www.softwareguru.com.mx

Recursos Humanos. Al ser la variable más sensitiva y la más afectada en el proceso de transición, debe ser el punto principal a tomar en cuenta. La gran incertidumbre de cada recurso de “¿que pasara conmigo?” es algo natural en estos procesos y el objetivo a cumplir es minimizar esta incertidumbre con una buena gestión del cambio. Lo que si debe quedar claro es que sin la colaboración de ellos, es imposible lograr los objetivos propuestos. El Diagnóstico no debe olvidar analizar los siguientes puntos • Organigrama • Nivel académico, formación, conocimientos y habilidades de cada recurso • Disposición Geográfica • Flujos de comunicación • Condiciones laborables (salarios, prestaciones, horarios…) Se debe planificar y preparar entrevistas con cada uno de los recursos involucrados en el cambio, lo que nos permitirá conocer la actitud de nuestros futuros colaboradores ante la nueva situación y detectar necesidades de formación, comunicación, problemas actuales y necesidades de apoyo. La ventaja de un diagnóstico temprano de cada uno de los recursos nos permite conocer su predisposición al cambio y actuar de acuerdo a su estado y nivel de resistencia, pudiéndose clasificar en Resistentes y Facilitadores, y determinar las formas de actuar en cada caso. • Si son afectados, hay que involucrarlos directamente en el proceso. • Si no son afectados directamente por el cambio, pero tienen una actitud negativa, hay que neutralizarlos, no asignándoles ningún rol en el plan de transición. • Si son afectados directamente por el cambio y están claramente en contra, se debe trabajar con técnicas de negociación basadas en los objetivos individuales de c/u • Si no son afectados pero tienen una actitud positiva, se debe trabajar con ellos integrándolos en los grupos de trabajo para motivar el cambio Para evitar en la medida de lo posible la incertidumbre, hay que definir rápidamente el nuevo esquema de organización asignando los nuevos roles de autoridad y creando formalmente los procesos de coordinación y control. También es deseable determinar qué recursos son necesarios en cada una de las etapas de implantación del modelo. Así por ejemplo, en la etapa de implantación suele ser importante contar con recursos altamente calificados que apoyen al nuevo equipo en la implantación de nuevos procedimientos, en conocimientos, en habilidades técnicas y en el proceso de adap-

www.softwareguru.com.mx

tación a la nueva cultura empresarial. Sin embargo, estos recursos no estarán asignados durante todo el tiempo ya que solo serán considerados apoyos puntuales. Una práctica altamente recomendable es la de realizar un histograma de los recursos requeridos a través de las diferentes etapas del proyecto (inicio, transición, estabilización, etc), identificando con tiempo las necesidades tanto actuales como futuras de recursos según su especialización. Esto nos permite tener una mejor planificación y asignación de recursos.

Plan de comunicación Hay que tener en cuenta que tanto una formación adecuada, como una comunicación eficiente, siempre apoyarán a facilitar la transición, por lo que es importante desarrollar planes de comunicación y formación. Es necesario que los recursos sean orientados de forma eficaz, lo que implica una coordinación eficiente de esfuerzos en comunicación y un continuo control en las diferentes etapas del proyecto. Es importante definir los objetivos generales del Plan de Comunicación, estructurándose según los niveles de actuación y responsabilidad. Para alcanzar una comunicación eficaz se debe tener un conocimiento claro de las necesidades de información de cada perfil. Un plan de comunicación debe considerar los siguientes aspectos: • A quién va dirigido. A qué niveles organizacionales queremos llegar. • Tipo de comunicación. Esta puede ser horizontal, descendente, ascendente, o personalizada. • Canal de comunicación. Por ejemplo: boletín interno, intranet, correo, tablón de anuncio, reuniones. • Distribución geográfica. Muchas veces estos recursos son olvidados e ignorados, ellos necesitan información de forma vertical y horizontal. • Definir un calendario de comunicación. Es importante comunicar la situación en cada fase de implantación. • Definir un responsable de la ejecución del plan. • Definir acciones de seguimiento del plan para determinar la eficiencia del mismo. Paralelamente, hay que diseñar un plan de inteligencia, que permita recolectar información crítica cuyo objetivo es neutralizar los posibles flujos de problemas. Este esquema debe estar asociado a un sistema de alertas tempranas que nos ayuden a la toma de acciones correctivas.

Plan de formación Como ya comenté, además de la comunicación eficaz, el otro factor crucial es una formación adecuada. Hay que determinar qué conocimientos y habilidades tiene cada uno de los recursos y cómo son usados en la operativa diaria. Esto permite por un lado definir que hará cada persona en el nuevo esquema, y por otro determinar las necesidades de formación para que puedan desarrollar sus nuevas funciones y actividades con eficiencia. La formación no debe limitarse a una formación técnica, sino que debe abordar todos los aspectos necesarios para que el recurso se adapte de la mejor forma a su nuevo modelo de trabajo y organización. Esto incluye: • Formación Técnica y planes de certificación • Formación en los nuevos sistemas de gestión de la empresa • Formación en la cultura empresarial • Formación en las nuevas metodologías de trabajo • Formación en el sistema de calidad Plan de carrera

Conclusión

El éxito en la transformación dependerá de la percepción y el grado de adhesión al nuevo escenario, es decir, dependerá de cómo se vea el proceso y cuán involucrados estén en el mismo. Hay que tomar en cuenta que el cambio es tanto cultural como operacional, y que mientras el primero afecta el lado emocional, el segundo afecta el lado racional de la innovación. En consecuencia, hay que tomar en cuenta que la transformación cultural es la revisión de las creencias actuales versus los nuevos valores. El cambio se debe ir generando y gestionando conforme el proyecto se desarrolla, de forma que podamos anticipar y superar las resistencias que se puedan presentar en las personas y por ende en la organización. Es necesario el crear una nueva estructura basada en un entramado de conceptos nuevos y distintos Todos los esfuerzos deben enfocarse en el nuevo programa de transformación. Los obstáculos no identificados, deben ser evaluados y medidos y definir los pasos y nuevas reglas de adaptación. Por ultimo, es importante verificar que el proceso de implantación y toma de control sea exitoso, es importante validar si las acciones y requisitos exigibles se han realizado de manera satisfactoria, para lo cual la elaboración de un checklist de verificación es de gran ayuda.

MAY-JUN 2007

Desarrollo de aplicaciones en un

entorno global Seguir el sol o seguir SOA Por Rodrigo García Perera

maginemos hace 25 años un área de sistemas en donde los empleados e integrantes del equipo se encontraban dentro de un cuarto trabajando en los diferentes proyectos de la empresa y donde la comunicación más distante entre ellos consistía en levantarse de su asiento y caminar al cuarto o en su defecto al piso siguiente para aclarar algunas dudas, y luego esta aclaración se enviaba al resto del equipo mediante un memorandum impreso. 15 años atrás, la comunicación entre estos dos personajes probablemente hubiera sido vía telefónica dentro de la misma ciudad o país, debido a que este podría ser entre el empleado de la organización y un consultor externo. Hoy en día, gracias a los avances de las telecomunicaciones y el Internet, los proyectos se pueden hacer desde el otro lado del planeta y prácticamente sin conocer a nadie del equipo que está trabajando en el proyecto. Los servicios de outsourcing de TI han evolucionado de forma importante en los últimos 10 años. Los grandes proveedores de servicios de TI son empresas globales, que cuentan con centros de servicios en diferentes localidades geográficas del planeta desde India, China, Europa del Este hasta Sudamérica. Estas empresas son capaces de generar una capacidad de trabajo continua, donde es posible generar una aplicación mediante sus diferentes centros de desarrollo usando una estrategia denominada “follow the sun” (siguiendo al sol). La idea de este concepto es que el desarrollo de un componente se inicie en Asia y se trabaje en él durante el turno de trabajo, para que al término de éste el código se envíe a un centro de desarrollo en Europa,

donde se continué el desarrollo, y al término de la jornada se continúe el trabajo en el continente americano, para luego reenviar al centro de Asia, logrando así el desarrollo continuo de aplicaciones durante las 24 horas del día. Infinidad de empresas han soñado con esta estrategia, y varias ya lo han intentado, pero los resultados típicamente son negativos. Si tomamos en cuenta que lo único constante en el desarrollo de software es el cambio, podemos ver que estar comunicando cambios a equipos que se encuentran distribuidos en todo el planeta puede ser una tarea realmente titánica. La cantidad de retrabajo provocado por la casi nula comunicación entre los equipos hace que las ganancias de tener equipos distribuidos prácticamente se nulifique. Entonces, ¿Cómo se podría generar un modelo de desarrollo que aprovechara todas las ventajas tanto del modelo nearshore como del modelo offshore? En este momento la manera más adecuada de llevar a cabo el desarrollo de aplicaciones usando este modelo es explotando las ventajas de ambos modelos, en conjunto con el paradigma de desarrollo orientado a servicios. La tendencia en el desarrollo de software actual está encaminada a la arquitectura orientada a servicios o SOA, y la manera de desarrollar esta misma es usando un enfoque de desarrollo orientado a servicios. Usando este enfoque, es posible generar el inventario de servicios que conforman la aplicación y después tomar este inventario y separarlo en diversos grupos o paquetes. Estos paquetes entonces pueden ser distribuidos a los diversos centros de desarrollo en base a la claridad de la documentación de los mismos. Esta división se hace para que los servicios más completos y documen-

tados puedan ser enviados a los centros de desarrollo offshore mientras que los que aun necesitan más trabajo en la definición, puedan ser desarrollados desde la localidad nearshore y que se aproveche la cercanía y el mismo horario del cliente. Otra ventaja del modelo es que aprovecha los bajos costos de desarrollo de las regiones asiáticas y de Europa del oeste, lo que genera que el modelo sea mejor que el solamente tener un equipo tres veces más grande en la localidad de América (en caso que el cliente se encontrara en Estados Unidos). La otra gran ventaja del modelo es que nos permite acceder a personal altamente calificado y especializado en diversos centros de desarrollo alrededor del mundo, lo cual es una gran ventaja cuando el proyecto es altamente especializado en alguna tecnología. Pero sin lugar a duda, la principal y gran ventaja del modelo es que nos permite reducir el tiempo de la codificación del producto y por lo tanto, tenerlo listo en el mercado más rápido. Ahora, no todos los proyectos de desarrollo podrán ser creados usando este modelo y mucho dependerá del grado de certidumbre y solidez de los requerimientos que se tengan. Entre más sólidos sean los requerimientos, será menos problemático el desarrollar bajo este modelo. Finalmente, la recomendación y el mensaje del artículo es que existe una gran variedad de opciones en el mercado para el desarrollo de aplicaciones, pero la decisión final sobre la manera en que el proyecto será desarrollado tiene que ser la que genere más valor, se acople a los objetivos de la organización y genere tranquilidad y confianza por parte del proveedor hacia la compañía que está comenzando este nuevo proyecto.

Rodrigo García Perera es Gerente de Producto de Desarrollo de aplicaciones para Softtek Near Shore Services en Estados Unidos y Europa. Cuenta con más de 10 años de experiencia trabajando para clientes Nacionales e Internacionales en las diferentes fases del ciclo de desarrollo de software. Cuenta con un MBA en Global eManagement por parte del la EGADE del ITESM y el título de Ingeniero en Sistemas Computacionales por la misma institución. Adicionalmente, imparte clases dentro del Bachillerato en Negocios Electrónicos (BANE) de la Universidad Regiomontana. rodrigo.garcia@softtek.com

MAY-JUN 2007

www.softwareguru.com.mx

// PUBLIRREPORTAJE

Coadyuvando a la calidad de la industria de T.I.

ormalización y Certificación Electrónica, A.C., NYCE, es una asociación civil sin fines de lucro creada en noviembre de 1994 por un grupo de empresas líderes de los sectores de Electrónica, Telecomunicaciones y Tecnologías de Información de México. NYCE está acreditado y autorizado por las instancias legales y las dependencias conducentes y forma parte del Sistema Mexicano de Metrología, Normalización y Evaluación de la Conformidad (SISMENEC). NYCE se ha enfocado siempre, tanto a la normalización como a la evaluación de la conformidad (certificación y verificación) de productos electrónicos, de telecomunicaciones y de tecnologías de información, sin embargo también ha incursionado en la certificación y verificación de productos de otras ramas, así como en la certificación de sistemas, personas, y en distintos ámbitos de la verificación, lo que lo ha hecho un organismo de servicio a la industria, cada vez más completo. Específicamente en el sector de Tecnologías de la Información NYCE ha enfocado sus esfuerzos a dotar a esta industria de un marco normativo que le permita comercializar sus productos y servicios y elevar su competitividad, dentro de los lineamientos internacionalmente aceptados, para lo cual se ha abocado a robustecer el acervo de normas de T.I., a través de la elaboración de estándares nacionales homologados con los internacionales. Actualmente cuenta con 38 Normas Mexicanas (NMX) de Tecnologías de Información; tiene en proceso la aprobación de 3 proyectos de normas más; y cuenta con otros 33 temas en desarrollo, con objeto de contar a mediano plazo con un acervo de 74 NMX de T.I. Hasta ahora lo que más se sabe del trabajo de NYCE en el ámbito de T.I., es lo relativo al estándar o norma MoProSoft (NMX-I-059NYCE Tecnología de la información – Software – Modelo de procesos y evaluación para desarrollo y mantenimiento de Software). Ello se debe a que como Organismo Nacional de Normalización de la rama, NYCE intervino para dar la legitimidad necesaria al modelo de evaluación de madurez de la capacidad de procesos que se es-

taba generando para las empresas pequeñas y medianas que desarrollan software, llevándolo a la categoría de norma, hoy estándar MoProSoft, cuyo origen viene de la necesidad de cumplir la estrategia 6 del Programa ProSoft de la Secretaría de Economía, relativa a “alcanzar niveles internacionales de capacidad de procesos”. Como Unidad de Verificación de Tecnologías de Información acreditada desde noviembre de 2005 por la Entidad Mexicana de Acreditación en los términos de la mencionada LFMN, la participación de NYCE ha sido en la evaluación del cumplimiento de la norma MoProSoft, determinando el nivel de madurez de la capacidad de procesos de 6 empresas, a las cuales otorgó el correspondiente Dictamen. Sin embargo, estas no han sido sus únicas tareas, NYCE también emitió la versión mexicana de la norma internacional ISO/IEC15504, denominada NMX-I-006-NYCE “Tecnología de la información – Evaluación de procesos”. Hoy día NYCE visualiza la importancia de la masificación de estos esfuerzos y por ello busca las alianzas necesarias, a fin de que las normas sean conocidas entre un número mayor de organizaciones y sean aprovechadas como herramientas de competitividad; no sólo el estándar MoProSoft y el equivalente a la ISO/IEC-15504, sino todas la normas del acervo mencionado. La experiencia y la especialidad de NYCE en T.I. confluyen para que la normalización y la evaluación de la conformidad en este ámbito trascienda: que el propio mercado exija el cumplimiento con estándares y que se genere una cultura de competitividad, transparencia y confianza al producir software mexicano con calidad internacional. En posteriores ediciones hablaremos más de las actividades de NYCE en estos aspectos, así como de los estándares mexicanos de T.I. que el organismo ha elaborado. La oferta es muy amplia y no sólo se enfoca a la normalización y verificación de procesos, sino también a la certificación de producto de software, pruebas de software y certificación de los profesionales en estos temas.

En diciembre del 2006, el Instituto Mexicano del Seguro Social (IMSS) se convirtió en el primer organismo del gobierno mexicano en alcanzar la evaluación nivel 3 de capacidad y nivel 2 de madurez del modelo CMMI. Conozcamos un poco sobre cómo se llevó a cabo este esfuerzo.

Antecedentes La Coordinación de Tecnología para la Incorporación y Recaudación del Seguro Social (CTIRSS) a cargo del Lic. Marco Gabriel Rojano, es parte de la Dirección de Innovación y Desarrollo Tecnológico del IMSS. Entre sus principales responsabilidades está el diseño, conceptualización, desarrollo e implementación de las soluciones tecnológicas y de sistemas de información para las funciones de incorporación de los derechohabientes a los servicios y prestaciones del IMSS así como del registro y mecanismos de recaudación de las cuotas obrero-patronales.

La Coordinación deseaba incorporar una metodología basada en un proceso unificado que contara con herramientas totalmente automatizadas y que a su vez agilizara, controlara y midiera los procesos de ingeniería de software y el ciclo de vida de las aplicaciones. La implantación de este proceso requería una visión de integración con la metodología adoptada para el desarrollo de sistemas y la arquitectura tecnológica del Instituto. Otro de los elementos clave para el cambio fue la necesidad de evolucionar la estructura organizacional, orientándola a una organización orientada a procesos. Esta nueva estructura debería permitir una especialización por actividad, donde se contemplen los roles necesarios para ubicar al personal de acuerdo al perfil y rol que desempeña; esta situación permite dotar a la estructura organizacional de flexibilidad para que pueda adecuarse a las cargas de trabajo.

Necesidades de cambio

Estrategia

Uno de los principales retos de la Dirección de Innovación y Desarrollo Tecnológico (DIDT) es evolucionar hacia un modelo que ofrezca servicios públicos personalizados como un único punto de contacto proporcionando servicios uniformes soportados por procesos, estructuras, tecnología y normas con una visión al ciudadano. Para sustentar la evolución de este modelo, se requiere que los sistemas de información desarrollados, se basen en procesos alineados a las mejores prácticas de la industria de software, que sean sustentados por métodos y herramientas de innovación tecnológica con la finalidad de dar información veraz y oportuna a los usuarios.

La CTIRSS encomendó a la División de Mejora Continua de Procesos, dirigida por el Ing. Juan Carlos Lass Bernal, un plan de acción para implantar en esta organización mejores prácticas de modelos como CMM, ISO 9001:2000 y PMBoK.

MAY-JUN 2007

Para lograr los objetivos planteados, se decidió incorporar a la organización una metodología basada en el Proceso Unificado. Ésta fue complementada con el uso de las herramientas Rational ClearQuest y Rational ClearCase para automatizar y organizar aspectos clave del proceso, tales como la gestión de requerimientos y el control de cambios.

www.softwareguru.com.mx

El equipo de la División de Mejora Continua de Procesos, llevó a cabo un importante esfuerzo para la implantación de estas prácticas dentro de la CTIRSS. A la par de éste, se implementó un plan de capacitación sobre el conocimiento y uso adecuado de estas nuevas técnicas y herramientas para las áreas usuarias.

Etapas del proyecto El programa inició con un diagnóstico de la madurez de los procesos identificando fortalezas y debilidades a través de una evaluación CBA-IPI. Con base en los resultados obtenidos, se definieron las iniciativas de mejora para incrementar el nivel de madurez. Como resultado de la evaluación previa se definió un plan de acción que apoyara a la CTIRSS a alcanzar un nivel 2 de CMMI, para lo cual se realizaron las siguientes actividades: •Ajuste y aprobación del proceso usado internamente (Proceso de Software Organizacional, o PSO) para cubrir con las brechas identificadas con respecto al modelo CMMI •Capacitación del personal en el proceso ajustado •Selección de proyectos pilotos •Soporte a la implementación en proyectos piloto •Evaluaciones de avance •Institucionalización del proceso en el resto de los proyectos de la coordinación

Madurez y Nivel 3 de Capacidad, ha establecido una mesa de ayuda que soporta algunos de los sistemas de la coordinación, una división de administración de proyectos para el seguimiento y control de los mismos, así como métodos y herramientas que han automatizado servicios de recepción de requerimientos de usuarios y aseguran la integridad de la información generada en la coordinación. Entre los principales logros de este programa están: •Definición del Proceso de Software Organizacional (PSO) cuyo propósito es establecer un proceso organizacional con prácticas de administración de proyectos e ingeniería de software para los proyectos de desarrollo y mantenimiento de aplicaciones logrando de esta forma: cumplir con las fechas de entrega comprometidas, cumplir con el presupuesto de los proyectos, reducir el retrabajo por corrección de defectos en los productos de software entregados •Entrenamiento en la CTIRSS sobre el CMMI y herramientas de RUP •Aseguramiento de Calidad sobre los proyectos vigentes •Se cuenta con una intranet de la CTIRSS para la difusión de: procedimientos del PSO, formatos de documentos, guías de llenado, ejemplos, manuales de procedimientos y herramientas automatizadas, proyectos vigentes de la coordinación La siguiente tabla resume los principales beneficios

En junio del 2006 se obtuvo una carta emitida por el Lead Appraiser, Giuseppe Magnani, la cual certificaba la alineación del Proceso de Software Organizacional (PSO Versión 6.0) al CMMI Nivel 2. La siguiente etapa, realizada de julio a octubre de 2006 consistió en implantar los procesos del PSO alineado al CMMI, en el resto de los proyectos de la coordinación. Finalmente, en noviembre del 2006 se llevó a cabo la evaluación formal SCAMPI A, donde se obtuvo el Nivel 2 (Administrado) de Madurez de procesos de ingeniería de software y el Nivel 3 (Definido) de Capacidad para los Procesos de Administración de Requerimientos, Planeación de Proyectos, Monitoreo y Control de Proyectos, Aseguramiento de la Calidad, Administración de la Configuración, Administración de Proveedores y Medición y Análisis.

Detalles significativos Para la realización del proyecto de mejora se recurrió al apoyo de consultores expertos en mejora de procesos. El programa de mejora involucra a cerca de 60 recursos, entre los cuales hay un líder del programa de mejora, un responsable de métricas y aseguramiento de calidad, un responsable de proveedores, y un responsable de capital intelectual. Desde abril del 2006, la CTIRSS se encuentra participando en el Premio IMSS Calidad alineándose a los estándares del Instituto, lo que le ha permitido confirmar su cultura organizacional, estableciendo una forma de trabajo que considera parámetros de calidad institucional complementados con modelos de referencia de calidad internacional.

Resultados Como resultado del programa de mejora, actualmente la CTIRSS ha logrado la evaluación satisfactoria en CMMI Nivel 2 de

www.softwareguru.com.mx

A pesar de los logros obtenidos la CTIRSS continúa su proceso de mejora, detectando estrategias que le permitan plantearse nuevos retos y desafíos para el perfeccionamiento de sus productos y servicios.

Lecciones aprendidas De acuerdo a un análisis retrospectivo es posible realizar recomendaciones para aquellos que deseen realizar una reestructura •Contar con el apoyo de la alta dirección, patrocinio. De esta forma se logra una mayor conciencia y una visión global. •Es importante identificar el nivel de madurez del área antes de comenzar un proceso de cambio. De esta manera se combate la resistencia al cambio de una manera más efectiva y gradual •La consultoría especializada para la administración del cambio debe estar presente desde el inicio del proceso para minimizar el impacto de los cambios dentro de la organización. •Contar el apoyo consultores especializados que brinden su experiencia en la implementación de procesos con un enfoque objetivo •Tener en cuenta en todo momento que no se trata de un esfuerzo separado. Es un beneficio para todos y por lo tanto todo el equipo debe tomarlo como propio

MAY-JUN 2007

// PRÁCTICAS

/* PROGRAMACIÓN*/

Desarrollo de un Juego 2D en OpenGL Parte 2. Creación de clases y texturas Por Joel Villagrana

n el número de Enero-Febrero 2007, publicamos un artículo donde establecíamos las bases teóricas y de configuración para desarrollar un videojuego 2D con OpenGL. En esta ocasión continuamos con dicho artículo, desarrollando las clases que le darán vida a nuestro juego.

Quadtree m_Quadtree; Nivel m_Nivel; //... mas atributos public: Juego(); ~Juego();

Lo primero que definiremos será precisamente de qué se tratará nuestro juego y posteriormente veremos aspectos como el diseño de algunas clases para representar los objetos dentro del juego y también como construir el mundo del juego e implementar diferentes aspectos de éste. Los juegos 2D son sencillos porque generalmente están basados en bloques (también conocidos como ‘Tiles’ o ‘Sprites’), es decir, a diferencia de los juegos 3D, la geometría de los juegos 2D son simplemente cuadrados texturizados.

bool Inicializa( void ); // Inicializa los diferentes objetos del juego void Termina( void ); // Libera los recursos antes de salir del juego void Frame( float tiempo_transcurrido ); // Metodo principal de procesamiento void MuestraMenu( void ); // Muestra el menu cuando el juego esta pausado bool Input( unsigned char key, int x, int y ); // Procesa el input del usuario //... mas metodos private: void IniciaFrame( void ); // Limpia la pantalla, actualiza la camara virtual, etc. void TerminaFrame( void ); // Procesamiento final del frame void Actualiza( float tiempo_transcurrido ); // Actualiza los objetos del juego bool CargaNivel( char *archivo ); void Render( void ); //... mas metodos };

A lo largo de este artículo mencionaré diferentes funciones de OpenGL, pero no iré a detalle en cuanto a cómo utilizar cada comando por razones de espacio en la revista, pero trataré de que todo quede bien comentado en el código, el cual estará disponible en el sitio web de SG, así como el archivo ejecutable para la plataforma Windows, los datos necesarios para el juego, y un pequeño manual de usuario. Definición del Juego “Crystal Forest Revenge” es un juego del tipo “side-scroller” (estilo Mario Bros. ó Megaman). El juego se centra en Bob, un extraño habitante del bosque que, al ver a sus amigos ser tomados prisioneros, se ve obligado a detener a Woody, un robot de otra galaxia que ha tomado el control del bosque y planea pronto tener el control de todo el planeta. Bob, con la ayuda de algunos elementos del bosque, deberá luchar a través de los niveles contra los ayudantes de Woody que poseen armas más poderosas. Creación de Clases de C++ Para un mejor manejo de la estructura, separaremos el código en Clases de C++. Como en muchos casos, hay varias formas en que se podría definir la estructura de un juego, pero la utilizada aquí será lo más sencilla posible. Utilizaremos una clase para representar el juego, y sus miembros serán objetos para representar los elementos principales, tales como un nivel del juego, el jugador principal, los enemigos y la cámara virtual. A continuación se muestran los elementos más importantes de esta clase. /// En Juego.h class Juego { private: bool m_Inicializado, m_MostrandoMenu, m_Teclado[ 256 ]; int m_NivelActual, m_UltimoNivel, m_NumFrames; Camara2D m_Camara; GLFont m_Fuente; Jugador m_Jugador; VecEnemigos m_Enemigos;

MAY-JUN 2007

El método de entrada de procesamiento de esta clase es el método Frame, ya que crearemos un objeto de tipo Juego en la función principal (main) y llamaremos al método Frame en las funciones asignadas a GLUT para hacer todo el procesamiento correspondiente cuando se necesita redibujar la pantalla. /// En main.cpp void SG_DisplayFunction() { float tiempoActual = ( float)timeGetTime(); if( g_pJuego != NULL ) { // Llama al metodo Frame, pasando el tiempo transcurrido // desde la ultima vez que se mando llamar al metodo Frame g_pJuego->Frame(( tiempoActual - g_ultimoTiempoDisplay ) / 1000.0f ); g_ultimoTiempoDisplay = tiempoActual; } glutSwapBuffers(); // Intercambia el front y back buffer } /// En Juego.cpp void Juego::Frame( float tiempo_transcurrido ) { IniciaFrame(); // Actualiza los objetos, detecta colisiones, detecta si el jugador // esta muerto, detecta si se completo un nivel, etc. Actualiza( tiempo_transcurrido ); if( m_Inicializado && m_NivelActual > 0 ) { if( m_MostrandoMenu || m_JugadorMuerto || ( m_NivelTerminado && ( m_NivelActual == m_UltimoNivel )))

www.softwareguru.com.mx

“A diferencia de los juegos 3D, la geometría de los juegos 2D son simplemente cuadrados texturizados”. { MuestraMenu(); } else if ( m_NivelTerminado && ( m_NivelActual < m_UltimoNivel )) { CargaSiguienteNivel(); } else { Render(); m_NumFrames++; } } TerminaFrame(); }

Los niveles del juego Podríamos definir internamente toda la parte gráfica del juego, pero esto tiene el inconveniente de que necesitaríamos recompilar el juego cada que se necesite una modificación y el crear diferentes niveles para el juego sería muy complicado. En su lugar, utilizaremos un editor creado en C# (disponible también en el archivo .zip) para crear nuestros niveles para el juego. En el editor, usaremos la opción para crear un nuevo mapa y en ésta definiremos el número de capas, así como el número de renglones y columnas que definirán que tanto espacio horizontal y vertical habrá en el juego. Las capas las utilizaremos para crear la ilusión de profundidad, las capas con valores menores en el eje Z representarán elementos que se encuentran más lejos.

La cámara virtual esta representada en la clase Camara2D, y su función principal es seguir al personaje dentro del juego y establecer la posición a donde se está viendo al hacer el Render. /// En Camara.h class Camara2D { private: vector2 m_Posicion; bool m_Moviendo; // ... otros atributos public: Camara2D(); ~Camara2D(); void Actualiza( vector2 pos ); void MueveCamara( bool mueveX, int direccionX, bool mueveY, int direccionY ); void GetPosicion( float *x, float *y ); // ... mas metodos }; /// En Juego.cpp void Juego::IniciaFrame() { float camx = 0.0f, camy = 0.0f; // Obtener la posicion actual de la camara m_Camara.GetPosicion( &camx, &camy ); // Limpia el bufer de color y el Z-buffer glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); // Cambiar a la ModelView Matrix glMatrixMode( GL_MODELVIEW ); // Establece la ModelView Matrix = Matriz Identidad glLoadIdentity(); // Establecer la posicion a donde ve la camara gluLookAt( camx, camy, 30.0f, // posicion de la camara camx, camy, -30.0f, // posicion a la que la camara esta viendo 0.0f, 1.0f, 0.0f // vector “up” de la camara ); }

www.softwareguru.com.mx

Para asignar un elemento gráfico a una zona del nivel, simplemente seleccionaremos con el mouse el área del nivel, luego una imagen de la ventana de recursos y entonces damos click al botón “Asignar Textura”; esto creará un billboard que se usará dentro del juego. Para facilitar el movimiento de los personajes dentro del juego, separaremos las gráficas de la detección de colisiones, es decir, los billboards creados no se usarán para la detección de colisiones. En su lugar, el editor nos permite crear zonas o bloques en las que los personajes pueden caminar. En juegos complejos, se utilizan niveles en formato binario, entre otras razones, para acelerar el tiempo de cargado. En nuestro caso no utilizaremos un formato binario, sino un archivo XML que nos permite tener cierto control para editarlo directamente si se necesita. Para cargar los archivos XML en el juego utilizaremos TinyXML,

MAY-JUN 2007

// PRÁCTICAS

/* PROGRAMACIÓN */

disponible en www.grinninglizard.com/tinyxml. TinyXML es una librería escrita en C++ que nos permite leer los diferentes elementos de un archivo XML. El código correspondiente a cargar el nivel se encuentra en el método CargaNivel( ) de la clase Juego. Texturas Para demostrar la creación de texturas, usaremos dos tipos de archivos de imagen, uno es el .TGA y otro es el .PNG, que tiene un muy buen esquema de compresión y también soporta el canal alfa en las imágenes. Para leer archivos .TGA utilizaremos nuestras propias funciones y para los archivos .PNG utilizaremos la librería gratuita libpng (libpng.sourceforge.net). El proceso para utilizar una imagen como textura dentro de un juego es el siguiente: 1. Leer el archivo que contiene la imagen y extraer los datos a un búfer. 2. Crear un “Texture Object” con la función glGenTextures( ), “enlazar” ese objeto como el objeto actual con la función glBindTexture( ), asignar los parámetros necesarios con las funciones glTexEnvf( ) y glTexParameteri( ) y finalmente, asignar el búfer leído como la fuente de datos del objeto con la función glTexImage2D( ). Esta última función manda los bytes de la imagen a la tarjeta gráfica y nos regresa un identificador para poder utilizar esa textura creada durante el juego, por lo que esta función, y el cargado de las texturas en general, debe hacerse al inicio del juego, o mejor aún, al inicio de cada nivel. 3. Durante el juego, habilitar el mapeado de texturas utilizando glEnable(GL_TEXTURE_2D), enlazar el texture object con la función glBindTexture( ), y asignar coordenadas de textura a los vértices de los objetos con glTexCoord2f( ). Para facilitar la creación de texturas, usaremos un objeto global de la clase CTextureManager que tiene métodos para cargar texturas desde archivos, cada identificador de la textura que carga es almacenado en un vector y nos regresa el índice donde fue almacenado. Otros recursos, texto y sonido No existe soporte para el texto como tal dentro de OpenGL, lo que haremos es crear una imagen con los caracteres de la fuente que queremos utilizar (existen programas gratis para hacer esto, como www.angelcode.com/products/bmfont), cargarlo como textura, y acceder las diferentes regiones de la textura dependiendo de los caracteres a mostrar en pantalla. Para esto utilizaremos Display Lists, que es una característica de OpenGL que nos permite “compilar” un grupo de comandos de Render para no tener que ejecutar todos esos comandos de Render cada Frame. La funcionalidad del manejo de texto dentro de nuestro juego está en la clase GLFont (glfont.h, glfont.cpp).

Para el sonido y reproducción utilizaremos FMOD, una librería multiplataforma gratis para productos no comerciales, disponible en www.fmod.org. Esta librería tiene muchas características interesantes, como soporte para sonido 3D, soporte para varios canales y soporte para cargar diferentes formatos, tales como asf, ogg, flac, wma, wav y mp3. Movimiento y detección de colisiones Para el movimiento de los personajes, utilizaremos diferentes billboards que representan cada frame de la animación, y en el método Render del juego determinaremos que billboard usar dependiendo del tiempo transcurrido desde que se inició la animación del personaje. La clase base que representa a un caracter tiene un atributo que representa su posición en pantalla (X, Y), este nos servirá en cada Frame para poder calcular la posición correspondiente en la pantalla respecto a los bloques en los que se puede caminar. Esta comparación no se puede hacer solo tomando el valor en el eje ‘Y’ de la posición del personaje porque los bloques pueden estar inclinados. El método utilizado será el siguiente: •En cada bloque o área en la que se pueda caminar, tendremos un punto A (inicio) y un punto B (fin), lo que matemáticamente lo convierte en un segmento de recta dirigido. •El hecho de que el segmento de recta sea dirigido es importante porque esto nos permite tomar un punto C (posición del personaje) y calcular la siguiente fórmula. int Area2Int( int aX, int aY, int bX, int bY, int cX, int cY ) { int area2 = ((( bX - aX ) * ( cY - aY )) (( cX - aX ) * ( bY - aY ))); return area2; }

Sin entrar en detalles matemáticos, lo interesante de esta fórmula es que nos regresará un valor mayor a cero si el punto C se encuentra a la “izquierda” del segmento AB, y un valor menor a cero si se encuentra a la “derecha” (y un valor igual a cero si el punto se encuentra en el segmento). Para utilizar esto, es importante que todos nuestros segmentos de recta sean dirigidos hacia la misma dirección. Sistemas de partículas Los sistemas de partículas son usados en los juegos para representar cosas como lluvia, humo, nieve, fuego, disparos, sangre, etc. En el juego usaremos sistemas de partículas para representar las explosiones cuando se destruyen a los enemigos. Un sistema de partículas es una colección precisamente de partículas. Cada partícula es independiente y tiene atributos individuales

Joel Villagrana es egresado de la Universidad de Guadalajara como Ingeniero en Computación, y estudió una maestría en Ambientes Virtuales en Inglaterra. Actualmente trabaja para IBM, y en su tiempo libre sigue aprendiendo las nuevas técnicas de gráficas 3D. Participó en el libro “More OpenGL Game Programming” publicado en 2005. La información de estos artículos representa su punto de vista y no necesariamente el de IBM Corporation.

MAY-JUN 2007

www.softwareguru.com.mx

tales como: posición, velocidad, tiempo de vida, tamaño, y color. Los sistemas de partículas tienen ciertos atributos que comparten todas las partículas generadas por el sistema, como el tipo de representación (líneas, puntos, o cuadrados texturizados), tasa de emisión (intervalo de tiempo que debe pasar para que se generen nuevas partículas), posición del sistema, fuerzas externas (gravedad, viento), entre otros. Hay diferentes enfoques en cuanto a los sistemas de partículas, para el juego usaremos una solución sencilla, definiremos una clase que representa un sistema de partículas genérico y una estructura que representa una partícula. No definiremos una clase separada para representar una partícula porque el sistema de partículas se encargará de inicializar, actualizar y renderizar las partículas. /// En SistemaParticulas.h struct Particula { vector2 m_Posicion, m_PosPrevia, m_Velocidad; float m_TiempoVida, m_Tamanio, m_Color[4]; }; class SistemaParticulas { protected: Particula *m_ListaParticulas; int m_MaxParticulas, m_NumParticulas; vector2 m_Posicion; float m_UltimaEmision; //... más atributos public: SistemaParticulas( int max_particulas, vector2 posicion ); ~SistemaParticulas(); virtual void Actualiza( float tiempo_transcurido ) = 0; virtual void Render() = 0; virtual int Emite(); virtual void Inicializa(); //... más métodos };

Visibilidad Durante el juego, solo una pequeña parte del nivel es visible en todo momento, y para tener un buen rendimiento, solo aquellas partes que son visibles deben ser renderizadas. Existen estructuras de datos especializadas utilizadas para el particionamiento espacial, tales como los Quadtrees para el caso en 2D, pero no podemos utilizar un Quadtree porque las dimensiones (ancho, alto) de nuestro nivel son muy diferentes. En su lugar, el editor de niveles separará cada capa en pequeños sectores. Cada sector almacenará índices a los billboards que contiene. El método Render( ) de la clase Juego llama al método Render( ) de la clase Nivel, pasando como parámetro la posición de la cámara virtual, este método se encargará de renderizar solo aquellos sectores que sean visibles.

Conclusión En este artículo concluimos el desarrollo de nuestro juego, espero que les haya sido interesante. Cualquier duda respecto al código me pueden contactar en joel.villagrana@gmail.com y trataré de responder lo más pronto posible. Solo me resta agradecer a Nell (nellfallcard@gmail.com) por su ayuda con algunas texturas para el juego y hacerles la invitación a participar en el concurso de videojuegos de Creanimax 2007! Las bases estarán disponibles pronto en www.creanimax.com

www.softwareguru.com.mx

MAY-JUN 2007

// PRÁCTICAS

/* ADMINISTRACION DE PROYECTOS*/

Caso Práctico sobre Análisis de Puntos de Función Parte 2. Determinando los puntos no ajustados Por Aquiles Santana

Bienvenidos a la segunda parte de este caso práctico sobre análisis de puntos de función. Como podrán recordar, el objetivo de este ejercicio es mostrar como se utiliza la técnica de puntos de función aplicada a un caso real. En nuestro caso, la aplicación consiste en un sistema para administrar las ventas de automóviles que realiza una empresa de compra-venta de autos usados. En la parte 1, publicada en el número de Marzo-Abril 2007, planteamos los requerimientos iniciales, en los cuales nos basaremos para realizar el análisis. Para poder dar seguimiento a este caso, es necesario tener a la mano dicho artículo, así que por favor rescaten su ejemplar impreso, o descarguen el PDF del sitio web de SG. Como se comentó en la parte anterior, el proceso para el análisis de puntos funcionales está formado por los siguientes pasos: 1. Determinar el tipo de conteo 2. Identificar el alcance, propósito y límites de la aplicación 3. Contar las funciones de datos 4. Contar las funciones transaccionales 5. Determinar los puntos de función no ajustados 6. Determinar el valor del factor de ajuste 7. Determinar los puntos de función ajustados

1. Determinar el tipo de Conteo El IFPUG distingue entre 3 tipos de conteos: • Conteo de Proyectos de Nuevo Desarrollo • Conteo de Proyectos de Mantenimiento • Conteo de Aplicaciones En el caso de nuestro ejemplo, no existe una aplicación ya desarrollada que se vaya a complementar o modificar, así que estamos hablando de un nuevo desarrollo.

2. Identificar el alcance, propósito y límites de la aplicación La identificación del alcance, es normalmente establecida en la fase de inicio o planeación del proyecto, y típicamente está documentada en forma de requerimientos de alto nivel, especificaciones funcionales, casos de uso, etc. Es común que al inicio del proceso no tengamos los requerimientos completos, pero esto no significa que no podamos continuar con el conteo. Lo que se hace en estas situaciones es complementar o llenar los vacíos de los requerimientos estableciendo supuestos que deberán ser documentados y validados con el experto de la aplicación o del negocio. La idea final es que el conteo de Puntos de Función sea reflejo fiel de los requerimientos y los supuestos. Si estos cambian, el conteo también deberá ser actualizado.

MAY-JUN 2007

Los límites de la aplicación, establecerán la funcionalidad que será considerada externa a la aplicación. Para establecer dichos límites se tomará el punto de vista del usuario y nunca un criterio técnico o de implementación. De esta forma, si tenemos una aplicación en donde la parte batch, obtiene y procesa información para crear tablas temporales que después serán utilizadas para generar reportes on-line, dicha aplicación será considerada como una sola aplicación para este propósito. Aplicación al caso Alcance. El alcance es todo lo documentado en la parte 1 de este artículo (pantallas y descripciones). Así mismo, hay cosas que no están documentadas y que deberán ser asumidas con base a nuestra experiencia. Por ejemplo, en los requerimientos no se indica si habrá un login y administración de usuarios y perfiles, entonces nuestro supuesto asociado al alcance será: • Se asume que no se requerirá funcionalidad para el manejo de seguridad. Este supuesto será documentado y se le dará seguimiento durante el ciclo de vida, con el fin de validarlo e identificar aquellas situaciones que lo invaliden, para que en su caso, se haga una actualización del conteo. Propósito. El conteo de puntos de función será utilizado como herramienta para la estimación, ejecución y control y cierre del proyecto. Precisamente, el propósito quedaría planteado de la forma siguiente: 1. Estimar el esfuerzo, duración y personal requeridos por el proyecto de desarrollo, utilizando algún modelo de estimación estadístico y una Base de Datos de Proyectos Históricos. 2. Controlar el crecimiento de tamaño a lo largo del ciclo de vida. 3. Controlar la cantidad de producto que es generado a lo largo del proyecto. 4. Evaluar productividad (Puntos de Funcion / Personas-Mes) y Calidad (Defectos / Puntos de Función) para dar información a los procesos de Mejora Continua del Desarrollo de Software y alimentar la Base de Datos de Proyectos Históricos que será utilizada en futuras estimaciones. Límites de la aplicación. En la descripción del caso práctico, se describe la funcionalidad para la venta de artículos por Internet y también se hace referencia al Sistema de Inventario de Vehículos. Desde el punto de vista del usuario, se trata de aplicaciones independientes, puesto que las necesidades de negocio son diferentes e incluso los usuarios que atienden son distintos. De esta forma, tenemos 2 aplicaciones: •Aplicación de Venta de Vehículos por Internet (la que vamos a desarrollar)

www.softwareguru.com.mx

“Los DET son los campos de datos únicos e identificables por el usuario”.

•Aplicación de Inventario de Vehículos (será referenciada por nuestra aplicación) Aunque parezca trivial, el correcto establecimiento de las fronteras es crítico para validar la completitud y consistencia del conteo.

3. Contar las Funciones de Datos En este paso, primero debemos identificar los almacenamientos lógicos (también conocidos como entidades de información), en cuanto a que sean totalmente independientes y que tengan un significado para el usuario. Por ejemplo, índices, tablas temporales son considerados almacenamientos técnicos creados con propósitos de implementación y no contribuyen al tamaño funcional de la aplicación. Así mismo, catálogos que contienen sólo un ID y una descripción, son almacenamientos considerados como “Code Table” y tampoco tendrán una contribución en el tamaño funcional. El punto clave para agrupar los almacenamientos lógicos, es verificando la dependencia entre ellos. Una pregunta clave, es respondernos si dicho almacenamiento puede existir de manera aislada, o si para tener significado debe formar parte de otro almacenamiento. Por ejemplo: Si tenemos la tabla de empleado, y la tabla telefonos_empleado, ambas son consideradas como un solo almacenamiento lógico, ya que telefonos_empleado no tiene significado por si sola. Otra forma de ver esta independencia es preguntarnos: Si desaparece un registro de la tabla de empleado ¿tiene sentido para el negocio conservar el registro asociado en telefonos_empleado?. Si la respuesta es positiva, entonces se considera que cada entidad puede existir de manera independiente y por lo tanto serán dos almacenamientos lógicos. Por el contrario, si la respuesta es negativa, los almacenamientos no existen de manera independiente, y por lo tanto son un solo almacenamiento lógico. Una vez agrupado e identificado el almacenamiento lógico, lo clasificaremos en ILF (Internal Logical File) o un EIF (External Interface File). Será ILF si dicho almacenamiento es mantenido por al menos una funcion transaccional dentro de la aplicación que contamos. Por otro lado, será un EIF si dicho almacenamiento es UNICAMENTE referenciado y no mantenido por la aplicación que estamos contando. Para determinar la complejidad de un almacenamiento, ya sea ILF o EIF, se debe hacer un conteo de lo que se conoce como DETs y RETs. Los DETs son los campos de datos únicos e identificables por el usuario y por otro lado, los RETs, son los subgrupos de datos en el mismo almacenamiento y que son identificables por el usuario, cuando en el almacenamiento no hay subgrupos de datos, se considera que el almacenamiento tiene un solo RET.

www.softwareguru.com.mx

Por último, la contribución en function points del almacenamiento, será obtenido con base a la complejidad y tipo de almacenamiento, utilizando las siguientes tablas: DET

1-19

20-50

51+

Baja

Media

2-5

Baja

Media

Alta

Media

Alta

RET

Tabla 1. Tabla para determinar complejidad de funciones de datos

Baja

Media

Alta

ILF

EIF

Tabla 2. Puntos de función correspondientes a funciones de datos de acuerdo a su complejidad

Aplicación al caso En nuestro caso práctico, vemos que el Sistema de Inventario de Vehículos, tiene responsabilidad de mantener las tablas de “vehículo” y “accesorios_vehículo”. Dichos almacenamientos forman un solo almacenamiento lógico llamado “vehículo”, puesto que el almacenamiento de “accesorios_vehículo” no tiene significado por sí solo. Dicho almacenamiento de “vehículo” es referenciado por nuestra aplicación, pero no es mantenido por esta, por lo cual es catalogado como un “EIF”. La complejidad de nuestro almacenamiento está en función de sus DETs y RETs. Para ver el número de DETs debemos ver los campos que son únicos e identificables por el usuario. En este caso tenemos número de serie, marca, modelo, año-modelo, color, kilometraje, condición, foto, precio, disponibilidad y nombre accesorio, para un total de 11 DETs. Para este almacenamiento, no existen subgrupos de información, por lo que el almacenamiento tendrá un solo RET. De acuerdo a esto, usando los valores de las tablas 1 y 2 determinamos que nuestro almacenamiento corresponde a una complejidad baja, y una contribución de 5 puntos de función. Por otro lado, existe otro almacenamiento que debemos considerar, y es el de “Compra”. En dicho almacenamiento, son guardados los datos del comprador, su financiera, su aseguradora, el ID

MAY-JUN 2007

// PRÁCTICAS

/* ADMINISTRACIÓN DE PROYECTOS */

de la compra y el número de serie del vehículo comprado. Al ser mantenido por la aplicación que estamos contando, dicho almacenamiento se clasifica como “ILF”, y al contar sus campos únicos identificables por el usuario, llegamos a un total de 13 DETs. No tenemos subgrupos de información identificables por el usuario, así que tenemos un solo RET. Buscando en las tablas, encontramos que dicho almacenamiento corresponde a una complejidad baja y corresponde a 7 puntos.

tar Empleado”, por ejemplo, podrían hacerse diversas validaciones sobre cada uno de los datos capturados (longitud del campo, formato de la fecha, etc), sin importar cuantas validaciones sean realizadas, sólo se contará un DET por la capacidad de generar mensajes en dicha función transaccional.

4. Contar las Funciones Transaccionales

Con el número de DETs y FTRs y además el tipo de cada función transaccional, se consultará en las siguientes tablas la complejidad:

Este es uno de los pasos que tienen mayor impacto en el conteo de los Puntos de Función y comienza con la identificación de los Procesos Elementales. Un proceso elemental es la unidad mínima de actividad significativa al usuario, que deja al negocio en un estado consistente y es autocontenido. Una vez identificado el proceso elemental, éste debe ser clasificado para convertirse en una función transaccional. Existen 3 tipos de funciones transaccionales: EI (External Input), EQ (External Inquiry), y EO (External Output). Dicha clasificación se hace con base al propósito principal de la función. Si el propósito principal de la función es recibir información para administrar (crear, modificar, eliminar) un almacenamiento, el tipo de función sera EI. Si, por el contrario, el propósito principal fuera sólo presentar información y no realizar ningún procesamiento adicional, la función es clasificada como EQ, y por último, si el propósito principal es presentar información y además realizar algún procesamiento adicional (como cálculos matemáticos, derivación de datos, etc) entonces la función se clasifica como un EO. La complejidad de las funciones transaccionales depende del número de DETs y FTRs. Los DETs, en las funciones transaccionales, son campos únicos de información que son identificables por el usuario y que entran o salen de la función transaccional. Por mencionar sólo algunos criterios de conteo, aplicables al conteo de DETs para las funciones transaccionales, se tienen los siguientes: •Para ser contado el DET debe entrar o salir de la aplicación, es decir un campo que sea utilizados internamente y que no entre o salga de la aplicación no es contado como DET. •Las etiquetas, nombres de campo, nombres de columna y variables de sistema como (fecha de sistema, número de página, número de columna, etc) no son contados. •En aplicaciones on-line, contamos 1 DET para la capacidad de ejecución sin importar de cuantas formas distintas se pueda ejecutar el proceso elemental. Por ejemplo, si podemos ejecutar la función de “Insertar Empleado” presionando el botón “Salvar” o presionando Ctrl-I o dando click en una opción de menú, sólo contaremos un DET por la capacidad para ejecutar dicha función. •En aplicaciones on-line, contamos 1 DET para la capacidad de envio de mensajes, sin importar cuantos mensajes sean enviados dentro de la misma función transaccional. Por ejemplo, en la función “Inser-

MAY-JUN 2007

Por otro lado los FTRs, son el número de funciones de datos que son mantenidas y/o referenciadas por la Función Transaccional.

DET

1-4

5-15

16+

FTR 0-1

Baja

Media

Baja

Media

Alta

Media

Alta

Tabla 3. Tabla para determinar complejidad de External Input (EI)

1-5

6-19

0-1

Baja

Media

2-3

Baja

Media

Alta

Media

Alta

FTR

DET

20+

Tabla 4. Tabla para determinar complejidad de E xternal Inquiry (EQ) y External Output (EO)

Una vez obtenida la complejidad, la contribución de la función transaccional en Puntos de Función No Ajustados, se obtiene con la siguiente tabla: Baja

Media

Alta

EI EQ EO Tabla 5. Puntos de función correspondientes a funciones transaccionales

Aplicación al caso El primer proceso elemental identificado en nuestro caso de estudio es “Consultar Listado de Vehículos”, el cual está implementado por las pantallas 1 y 2. La pantalla 1 no es un proceso elemental por sí sola, debido a que no tiene sentido para el usuario el solo ingre-

www.softwareguru.com.mx

sar los parámetros de consulta y no hacer nada más. El ingresar los parámetros de consulta y mostrar los resultados de dicha consulta forman un solo proceso elemental, puesto que es la unidad mínima de actividad que tiene significado para el usuario, deja al negocio en un estado consistente y es autocontenido. Este proceso elemental tiene el propósito principal de presentar información y no incluye procesamiento adicional, por lo que es catalogado como un EQ. Los campos únicos que son presentados en las pantallas 1 y 2 y que corresponden a la función “Consultar Listado de Vehículos” son 7: año_modelo, marca, modelo, accesorios, precio, color y condición. Adicionalmente, se cuenta un DET para la capacidad de ejecución (cuando se presiona el botón de “buscar”), y otro DET para la capacidad de envío de mensajes (cuando no es encontrado ningún vehículo con las características indicadas), resultando en un total de 9 DETs. La información requerida por esta función transaccional es obtenida de la Función de Datos “Vehículo”, por lo tanto el número de FTR es uno. La complejidad resultante de esta función EQ, con 9 DETs y 1 FTR, es “Baja” según lo indicado en la tabla 4 y su contribución es de 3 puntos, según lo indicado en la tabla 5.

www.softwareguru.com.mx

El segundo proceso elemental identificado es “Consultar Detalle de Vehículo”, el cual corresponde a una parte de la pantalla 2 (cuando se selecciona un vehículo y se presiona el botón “Ver Detalle”) y la pantalla 3. Dado que no se realiza procesamiento adicional, esta función se clasifica como un EQ con 7 DETs, correspondientes a: color, kilometraje, condición, número de serie, precio, accesorios (aunque el campo se repite, sólo se cuenta como un DET) y la capacidad de ejecución (cuando en la pantalla 2 se presiona el botón “Ver Detalle”). Toda la información se obtiene de la función de datos “Vehículo”, así que solo es un FTR. De esto, obtenemos que la complejidad de esta función tipo EQ, con 7 DETs y 1 FTR es baja y tiene una contribución de 3 Puntos de Función. El tercer proceso elemental identificado corresponde a la funcionalidad de comprar el vehículo o “Insertar Compra”. Dicha función está formada por el procesamiento que incluye permitir la captura, salvar la compra, actualizar el campo de estado en el inventario de vehículos y además enviar el correo al comprador. Aunque estos procesos parecieran ser funciones independientes, al analizarlos nos damos cuenta

MAY-JUN 2007

// PRÁCTICAS

/*ADMINISTRACIÓN DE PROYECTOS */

que no tienen sentido por sí solos o no dejan al negocio en un estado consistente. El proceso elemental de “Insertar Compra” se encarga de mantener la función de datos “Compra”, y por ello es clasificado como un “EI”. Los DETs únicos que entran o salen en los diferentes procesamientos que conforman esta función son: capturar los datos, salvar, almacenar el campo de estado del vehículo, y enviar el e-mail. Cuando se capturan los datos tenemos 11 DETs que aparecen en la pantalla 4, a lo que agregamos la capacidad de ejecución, para un total de 12 DETs. En el procesamiento de envío del e-mail al comprador, se tiene un DET que no ha sido contado en la función transaccional, que es: “número de compra”. Este nuevo DET mas los 12 previos, nos da un total de 13 DETs para esta función. Ahora bien, “Insertar Compra” requiere usar la función de datos “Compra” para insertar el nuevo registro y también requiere de la función de datos “Vehículo”, para actualizar el valor del campo “Estado de disponibilidad del Vehículo”, así que el FTR será igual a 2. La complejidad de la función EI con 13 DETs y 2 FTRs es igual a “Media” y su contribución es de 4 Puntos de Función.

de ejecución y rango). Todos estos drop downs tendrán un FTR igual a 1 dado que sólo consultan la función de datos “Vehículo”. Así que según nuestras tablas, los 3 procesos elementales tipo EQ que tenemos, tienen una complejidad baja que corresponde a 3 puntos cada uno, mientras que “Consultar Listado de Rango de Precios” también tiene complejidad baja, pero al ser una función del tipo “EO” contribuirá en 4 puntos de función.

5. Determinar los puntos de función no ajustados En este paso, simplemente determinamos el total de puntos de función no ajustados, sumando los puntos correspondientes a las funciones de datos encontradas en el paso 3, y las funciones transaccionales encontradas en el paso 4. La siguiente tabla refleja el total de puntos de función no ajustados para nuestro caso:

Por último, se cuentan los drop-downs como funcionalidades de “Consultar Listado de…”. Por lo que consideraremos los siguientes procesos elementales: •Consultar Listado de Año_Modelo. Drop Down •Consultar Listado de Marca/Modelo. Drop Down •Consultar Listado de Accesorios. Drop Down •Consultar Listado de Rango de Precios. Drop Down Los primeros 3 procesos solo presentan información y no realizan ningún procesamiento adicional, por lo que quedan clasificados como “EQs”. En cambio, “Consultar Listado de Rango de Precios”, requiere adicionalmente hacer algún procesamiento (calcular los rangos con base a los valores mínimos y máximos) para luego presentar los datos, por lo tanto dicho proceso es clasificado como un “EO”. Para calcular la complejidad de los drop-downs, se considera un DET para la capacidad de ejecución (cuando se presiona la flechita y se despliega el drop down) y los DETs de datos que son mostrados. En el caso del drop-down de año modelo contamos 2 DETs (capacidad de ejecución y el DET año-modelo), para el drop down de Marca-Modelo, contamos 3 DETs (Capacidad de ejecución, marca y modelo), para el de Accesorios contamos 2 DETs (capacidad de ejecución y el DET de accesorio) y para el de Rango de Precios contamos 2 DETs (capacidad

TOTAL

Tabla 6. Total de puntos función

Próximos pasos En el próximo artículo de esta serie, aprendemos a determinar el factor de ajuste, para poder determinar la cantidad de puntos de función ajustados que corresponde a nuestra aplicación. ¡Hasta entonces!

Aquiles Santana Álvarez es Certified Function Points Specialist por parte del IFPUG y Project Manager Professional por parte del PMI. Ha sido responsable de la estimación de proyectos de software críticos para EDS de México y Latinoamérica. Ha impartido entrenamiento en la técnica de Puntos de Función y estimaciones a más de 300 personas en 6 países. Actualmente se desempeña como consultor en Project Management e Ingeniería de Software.Rational. Sergio es Ingeniero en Electrónica con Especialidad en Computación por la Universidad Autónoma Metropolitana.

MAY-JUN 2007

www.softwareguru.com.mx

MAY-JUN 2007

// UML

BPD Diagrama de Actividades con Esteroides Por Charlie Macías y Sergio Orozco

El diagrama que se explicará en esta ocasión no se encuentra definido en la especificación de UML. Sin embargo, puede considerarse como una ramificación de UML hacia una disciplina en particular de mucho provecho para la ingeniería de software: el modelado de negocio. Es por eso que decidimos tratar el tema en esta sección.

Los Requerimientos y el Modelo del Negocio El objetivo de las aplicaciones de software, típicamente es el de automatizar uno o más procesos del negocio. Para esto, solemos prometerle al cliente (ya sea interno o externo) la construcción de un sistema de software “a la medida” de las necesidades del proceso de negocio que automatizará. Para determinar las características de dicho producto de software (que supuestamente cubrirá las necesidades del negocio), la técnica más común es la de cuestionar directamente a los usuarios cuál es la funcionalidad requerida. El problema es que si solamente hacemos esto, estamos dejando de lado los procesos de negocio que se desea automatizar. Basarnos exclusivamente en los requerimientos del sistema como la entrada para el proceso de desarrollo de software suele traducirse en una reducción sustantiva en la probabilidad de entregar un software que cubra las necesidades para las que se supone fue creado. Luego entonces, un factor crítico para el éxito de un proyecto de software, consiste en entender la estructura y dinámica del negocio o la parte del negocio que el producto automatizará, para entonces poder construir el producto que satisfaga su operación. En otras palabras, es indispensable partir de un modelo del negocio, ya sea que haya sido previamente definido por la gente de negocios (lo cual sería ideal, aunque por desgracia poco probable), o que nosotros como desarrolladores lo elaboremos previo al desarrollo del software. No importa quien asuma la responsabilidad de elaborar el modelo de negocio; como bien sabemos, si no partimos de la entrada correcta para nuestro proceso de desarrollo, la satisfacción del cliente al recibir el software desarrollado no será la óptima. Lo cual, de una forma u otra nos terminará afectando.

UML vs BPMN A lo largo de los años, UML se ha destacado por su utilidad para representar fenómenos del mundo real. Es por ello que desde hace varios años se desarrollaron y popularizaron una serie de extensiones para el modelado de los negocios. Entre los diagramas más útiles para este fin se encuentran: el de actividades, el de casos de uso de negocio, el de clases y el de secuencia. Por otro lado, la comunidad de ingeniería de negocios ha venido trabajando también por varios años en la definición de un estándar propio que satisfaga las necesidades de modelado de procesos de negocio, el estándar más conocido resultado de estos esfuerzos, es el denominado BPMN. BPMN es acrónimo de Business Process Modeling Notation, y fue adoptado como estándar regulado por el OMG en febrero del 2006. BPMN define un único diagrama: el llamado BPD (Business Process Diagram) o diagrama de procesos del negocio. En la especificación del mismo se plantean dos objetivos, el primero: ofrecer una notación sencilla de entender por todos los involucrados en el modelado del negocio y el segundo, no menos importante: asegurar que los lenguajes orientados a la automatización de procesos, como BPEL4WS, puedan visualizarse a través de esta notación.

Business Process Diagram (BPD): El Diagrama de Actividades con Esteroides El BPD toma las bases del diagrama de actividad de UML, así que para quienes ya conozcan este diagrama, la transición hacia el BPD será sencilla. Simplemente es cuestión de conocer y entender los elementos adicionales específicos para el modelado de negocios. Los elementos que se pueden modelar en un BPD se clasifican en las siguientes cuatro categorías: •Objetos de flujo: Eventos, Actividades y Gateways. •Objetos de conexión: Flujo de Secuencia, Flujo de Mensaje y Asociación. •Swimlanes: Pools y Lanes. •Artefactos: Objetos de Datos, Grupos y Anotaciones de Texto. La figura 1 muestra un BPD modelando un proceso simple de reclamación. En ella podemos identificar los principales elementos de BPMN.

Carlos Macías es instructor y arquitecto en jefe. Sergio Orozco es director general e instructor senior, ambos especializados en temas relacionados con UML en Milestone Consulting. Milestone Consulting (UML Value Added Training Center), es una empresa especializada en capacitación práctica-intensiva y consultoría en UML, BPMN y PM. Milestone Consulting es la primer empresa mexicana miembro de la OMG, además de ser REP del PMI. info@milestone.com.mx, www.milestone.com.mx

MAY-JUN 2007

www.softwareguru.com.mx

Figura 1. BPD modelando un proceso de reclamación

¿No Más UML para el Negocio? Lo natural es preguntarse si con esta nueva notación para negocio, BPMN, ya no es necesario utilizar los artefactos de UML para hacer modelado de negocio. En ese sentido hay opiniones variadas que debemos de considerar al tomar nuestra propia decisión al respecto. A menudo se menciona que una de las principales ventajas que posee BPMN frente a UML es que de origen fue concebida como una notación enfocada en procesos y no en objetos. Sin embargo, sugerimos no hacer a un lado a UML para estos fines. Lo que nosotros recomendamos, al igual que otros consultores de UML e ingeniería de negocio en el mundo, es combinar ambos estándares para así obtener los máximos beneficios. En nuestra experiencia modelando negocios, hemos constatado que UML aporta elementos muy valiosos, como la identificación inmediata de las responsabilidades de los trabajadores del negocio, y el comportamiento dependiente del estado de las entidades del negocio. Modelar este tipo de elementos en BPMN, si bien es posible, resulta impráctico. Por otro lado, a pesar de que tanto los diagramas de actividad de UML como los BPD soportan el modelado de los escenarios más comunes de negocio –por ejemplo, los 21 patrones que describen el comportamiento de los procesos de negocio –, hemos comprobado que la riqueza semántica y simplicidad de uso provista por BPD es superior. Finalmente, tampoco hay que dejar de lado la relación de BPMN con lenguajes como BPEL4WS como elemento importante en la implantación de soluciones que se adhieren a una Arquitectura Orientada a Servicios (SOA).

www.softwareguru.com.mx

MAY-JUN 2007

// COLUMNA

/*CÁTEDRA Y MÁS*/

Diseño de procesos y outsourcing Una reflexión

El Dr. Francisco José Camargo Santacruz es profesor investigador de los Departamentos de Sistemas de Información y Ciencias Computacionales en el Tec de Monterrey, Campus Estado de México. Su área de especialidad es la Integración de Tecnología de Información en las Organizaciones. Francisco está certificado como IT Service Management (ITIL Foundation), ha sido consultor de diversas organizaciones en Colombia y México, tiene diversas publicaciones en revistas de circulación internacional y pertenece al Sistema Nacional de Investigadores (SNI).

¿A qué le dedicamos nuestro tiempo? Esta es una pregunta recurrente en las organizaciones, y muchas veces nos preguntamos, ¿pero qué hace esta área?, ¿a qué dedica su tiempo? Si entramos a detalle y analizamos la situación, es muy probable que nos encontremos que dedica gran parte de su tiempo a realizar actividades y procesos que no generan valor a la organización, o no están alineados con alguno de los objetivos de negocios, o simplemente se realizan por que “siempre se han hecho así”.

Definiendo procesos clave El trabajo para definir procesos centrales (también llamados “core”) de un área inicia con la definición de la razón de ser de la misma (misión, objetivo estratégico, etc.), la cual debe estar alineada a los objetivos de negocio. Por ejemplo, si el foco de la organización está a servicio, éste es un factor central a resaltar en la definición de la misma. A partir de esta definición generamos un catálogo de procesos del área clasificados de acuerdo a la relevancia de los mismos y del impacto que tienen en la función central. Este catálogo pasa por un ciclo de revisión y alineación donde debemos cuestionar cuáles de ellos están conforme a la razón de ser del área, cuáles generan valor, cuáles deben transferirse a otra área y finalmente, cuáles deben eliminarse. Además, debemos cuestionar y definir cuáles de ellos son factibles de llevar a un esquema de outsourcing de procesos de negocio.

Definiendo el perfil del equipo de trabajo A partir de la razón de ser del área y el catálogo de procesos podemos iniciar con la definición del perfil de las personas requeridas para realizar el mismo acuerdo al enfoque deseado. Somos muy dados a “definir” procesos de acuerdo a la gente con que contamos, mas no a las competencias requeridas para ejecutar bien los procesos de acuerdo al diferencial establecido. Esto es vital en un esquema de BPO, ya que permite decidir qué equipo de trabajo se queda en la organización para realizar ciertos procesos clave y ser el punto de enlace con la empresa que ofrece los procesos en outsourcing, y además de verificar que se cumplan los acuerdos de niveles de servicio (SLA) establecidos en el contrato.

Administrando los procesos de negocio El proyecto de diseño de procesos de negocio requiere un gran esfuerzo y compromiso de todos y cada uno de los integrantes de la organización, iniciando por la alta dirección. Es aquí donde se define

MAY-JUN 2007

la estrategia y los procesos que se diseñarán en un inicio, buscando el mayor impacto al negocio, además de la estrategia de automatización de los mismos. El proceso de diseño de por sí, es de intenso trabajo y responsabilidad de cada una de las áreas involucradas. Se requiere de un equipo de personas que facilite el diseño, norme el proceso de documentación, realice el seguimiento al diseño y aporte soluciones y visiones diferentes. Un punto vital que debe quedar claro, es que el experto en el proceso es el área, ya que ellos conocen su negocio y cómo lo pueden hacer de la mejor manera posible. De ahí su compromiso y participación central como líderes y responsables del diseño de sus procesos y el impacto a los objetivos de la organización. La fase de implantación del proceso es crítica en la incorporación de nuevas prácticas en el mismo, además del monitoreo de las métricas de desempeño definidas, las cuales deben ser simples y sencillas de obtener para no generar un trabajo extra durante la ejecución del proceso.

Incorporando tecnología Una parte central como lo comentábamos, es la verificación de la implantación del proceso, o si es el caso, la implantación del proceso en outsourcing, donde debemos tener una fase de validación, por no llamarla de auditoria, que permita asegurar que el proceso esté “corriendo” como se diseñó, ya sea con nuestro equipo de trabajo o con una empresa externa. Existen diversas herramientas en el mercado especializadas en BPM (Administración de Procesos de Negocio) que pueden generar valor, de acuerdo a las necesidades de cada organización, en diferentes fases del proceso, incluyendo el monitoreo y control del mismo. También está siempre presente el desarrollo de software para automatizar el proceso y apoyar en el cumplimiento de los objetivos del proceso. La decisión final depende de cada empresa, de acuerdo a sus necesidades y recursos.

Reflexión final El esfuerzo vale la pena cuando los resultados son percibidos por los clientes internos y externos. Desde mi punto de vista, el diseño de procesos de negocio, no debe medirse por el número de procesos diseñados o la documentación obtenida, sino por el valor generado por cada proceso en la obtención de los objetivos de negocio. — Francisco Camargo www.softwareguru.com.mx

www.softwareguru.com.mx

MAY-JUN 2007

// COLUMNA

/*TENDENCIAS EN SW*/

Software + Servicios La evolución de SaaS, SOA y Web 2.0

Luis Daniel Soto es director de Evangelización en nuevas tecnologías en Microsoft México. Entre sus funciones actuales están la de administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Es jurado del “Gran Orden del Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Ganó el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn.com/luisdans

Software como servicio (SaaS), arquitectura orientada a servicios (SOA) y Web 2.0 tienen un común denominador: los “servicios”. Los clientes cada vez están menos interesados en “tener” su propio software, y en cambio prefieren utilizarlo como servicio. Se ha hecho la analogía de que el software eventualmente será un servicio similar a la entrega de corriente eléctrica o señal de radio. Por supuesto, este escenario implica retos abrumadores, y pensar en un esquema puro de servicios es irreal. Por ejemplo, nadie espera que al “encender” de una sesión a otra pueda existir una nueva versión de un sistema contable. Reconociendo esto, tiene sentido pensar que el futuro no está todo basado en servicios, sino en una combinación de software y servicios. Es esto lo que llamamos la plataforma de Software + Servicios. El principal representante del software empresarial, es SOA, mientras que el principal representante de los servicios en tiempo real es el Web 2.0. La convergencia de estos dos modelos es lo que habilitará la plataforma de Software + Servicios.

Oportunidades Son muchos los vectores de innovación alrededor del software, pero los que podemos considerar como más importantes para la evolución del “Software más servicios” son: •Experiencia. El acceso desde múltiples dispositivos es cada vez más importante. Es un verdadero reto construir software que tome las ventajas de cada punto de entrega al máximo. Se considera que hay tres clientes de alta importancia: el explorador de internet, el cliente interactivo para interfaz gráfica y más recientemente la suite de oficina (v.gr. Microsoft OBA). •Entrega. Se puede clasificar en tres niveles: bloque de construcción, incorporado y final. Los primeros son solo de interés para desarrolladores (S3 de Amazon), los segundos son entregados como parte del producto (v.gr. Windows Update) y los últimos se refieren a servicios 100% diseñados para ser entregados remotamente via internet (v.gr. Salesforce.com).

MAY-JUN 2007

•Federación. La capacidad de ofrecer un continuo entre organizaciones, empresas y redes de empresas. Los servicios de identidad tienden a ofrecer un componente que opera localmente, pero puede participar en una nube de mayor magnitud (v.gr. Microsoft Passport) •Composición. Los mashup son precursores de un nuevo modelo de desarrollo. Hoy no existen muchos ejemplos más allá de los mapas y visualización. Sin embargo, lo que está teniendo mayor resultado es de nuevo el acceso a back-end desde la suite de oficina. •Monetización. En mi columna anterior describí como la publicidad en línea ha demostrado ampliamente la capacidad de ser un modelo de negocios viable para el software. Las plataformas tecnológicas han tenido un desarrollo muy lento en cuanto a poder medir el uso del software, cobrarlo e integrar el rol de publicidad pagada. El software tanto personal como empresarial continúa en evolución. Las dimensiones son múltiples, tales como el acercamiento entre el mundo de trabajo al personal, el control del mundo digital, la experiencia de usuario, y otras. Sin duda “software más servicios” será un gran habilitador de este cambio. La adopción de este modelo implica un enorme reto para las organizaciones de TI. La era en la que los departamentos de TI son administrados como fortalezas de información pronto llegará a su fin. Los gerentes de TI deben aprender a administrar información en este esquema distribuido y asíncrono. Las organizaciones más exitosas serán aquellas que se reinventen para aprovechar las ventajas de este esquema. Hoy es momento de entender los retos que involucra este nuevo paradigma, y la forma en que podemos explotarlo. Pensemos ya en esto como la evolución y convergencia de SOA, SaaS y Web 2.0.

Referencias •msdn2.microsoft.com/en-us/library/aa905319.aspx •weblog.infoworld.com/realworldsoa/archives/2007/03/convergence_of.html

www.softwareguru.com.mx

MAY-JUN 2007

// FUNDAMENTOS

Reglas de negocio

Administrando la operación con reglas Por Jorge Becerril

Los sistemas de información empresariales, están orientados a automatizar la operación de una organización. La operación de toda organización cuenta con condicionantes, políticas o restricciones que ayudan al sistema de información a ejecutar alguna operación de manera correcta, de acuerdo a la exigencia del negocio. Por ello, parte fundamental dentro de los requerimientos de cualquier sistema de información, son las denominadas “reglas del negocio”, las cuales dan orden y disciplina a las operaciones de la organización. Las reglas del negocio son tan importantes que en los últimos años se han presentando diversas iniciativas y esfuerzos para estandarizarlas y automatizarlas a través de motores de reglas de negocio como es el caso de Biztalk Server de Microsoft, o de Oracle Business Rules.

¿Qué son? La siempre útil Wikipedia define las reglas de negocio como una descripción de las operaciones, definiciones y restricciones aplicables a una organización para lograr sus metas. Por otro lado, el Business Rules Group, que es una organización cuyo propósito es fomentar el entendimiento y estandarización del concepto de reglas de negocio, se basa en dos perspectivas para definir una regla de negocio: • Desde la perspectiva del negocio, es una orientación en la cual hay una obligación conducida por una acción, práctica o proceso, dentro de una particular actividad o giro. • Desde la perspectiva de sistemas de información, es una declaración que define o restringe algunos aspectos del negocio. Intenta hacer valer la estructura del negocio, o controlar o influir en la conducta del negocio.

Rol dentro de la estructura de requerimientos

Es importante saber ubicar a las reglas del negocio dentro de una estructura de requerimientos. Veamos la siguiente imagen.

de gerencia, ya que son ellos quiénes definen y avalan las reglas. Otra fuente importante son organismos por los que se rige una emprea, como puede ser el caso de la secretaría de salud que rige a los laboratorios farmacéuticos o como la secretaría de comunicaciones y transportes que rige a las empresas transportistas.

¿Donde especificarlas?

En la imagen se puede apreciar una estructura que inicia desde los requerimientos de negocio y termina en la especificación de requerimientos. Como se puede observar, las reglas del negocio son consideradas un aspecto no funcional y se clasifica como requerimiento de usuario.

Características El mismo Business Rules Group, ha redactado un manifiesto de reglas del negocio. De acuerdo con éste, una regla del negocio deberá cumplir con las siguientes características: • Se deben expresar de manera que pueda ser validada su exactitud por el personal conocedor del negocio. • Se deben expresar de manera que se pueda verificar recíprocamente su coherencia. • Las lógicas formales, como la lógica de predicados, son fundamentales para la expresión formal de reglas en términos de negocio, así como para las tecnologías que implementan dichas reglas.

¿Cómo encontrarlas? El identificar las reglas del negocio es parte de la labor del Ingeniero de Requerimientos, éste deberá tener la habilidad para poder encontrarlas dentro de un mar de información. Una buena fuente para encontrar reglas del negocio es la información provista por personal directivo o

Las reglas del negocio son parte de la columna vertebral del sistema de información, por lo cual deben estar perfectamente especificadas dentro del documento de requerimientos, y deben ser tomadas en cuenta para la fase de pruebas. Si alguna regla del negocio no está siendo aplicada se corre el riesgo de que el sistema arroje resultados incorrectos o permita errores que se traduzcan en perdidas para el negocio.

Algunos ejemplos Imaginemos un negocio de renta de autos. En este caso, vienen a la mente un par de reglas que podrían ser: • Los carros rentados en una sucursal pueden ser entregados en otra sucursal. • Un cliente puede tener varias reservaciones, pero solamente un carro rentado a la vez.

Conclusión Al momento de hacer el trabajo de requerimientos, es de vital importancia encontrar las reglas del negocio, ya que estas harán del sistema de información un repositorio de datos más seguro y confiable. Al buscar las reglas del negocio, debemos visualizar todo el ambiente que gira en torno al sistema, instituciones u organismos externos, reglamentos y hasta condiciones ambientales.

Referencias

• Business Rules Group www.businessrulesgroup.org/home-brg.shtml

Jorge Becerril actualmente se desempeña como consultor en Pounce Consulting, tiene 15 años de experiencia desarrollando software en donde ha desempeñado los roles de programador, analista y líder de proyecto, es egresado de la Universidad del Valle de Atemajac de la carrera de Sistemas Computacionales. bec.jorge@gmail.com, http://ingsoftware.blogspot.com

MAY-JUN 2007

www.softwareguru.com.mx

MAY-JUN 2007

// INFRAESTRUCTURA

SAS

La evolución de SCSI Por Ariel García

Como sabemos, SCSI (Small Computer System Interface) es un conjunto de estándares para conectar computadoras con dispositivos y transferir datos entre estos. Esta tecnología fue desarrollada en los años ochenta, por lo que lleva más de 20 años en el mercado. El protocolo SCSI es utilizado actualmente en diversas tecnologías de transporte de datos, como USB, 1394, Parallel SCSI e iSCSI. Una de las tecnologías más recientes basadas en SCSI es la denominada Serial Attached SCSI (SAS). SAS es una tecnología de bus para transferencia de datos hacia dispositivos de almacenamiento. SAS viene a reemplazar Parallel SCSI en los mercados empresariales, brindando una mayor tasa de transferencia de datos, además de ser compatible con discos SATA.

Características básicas de SCSI Para poder entender SAS y los beneficios que provee, considero pertinente que primero demos un repaso sobre las características básicas del estándar SCSI, y las limitaciones que encuentra la tecnología Parallel SCSI. El estándar SCSI define tres componentes clave: • Fault connection. Se debe asegurar que los datos puedan ser transferidos de un dispositivo SCSI hacia el controlador y de regreso, con la mayor velocidad e integridad de señal posible. Como sabemos, conforme aumenta la velocidad de transferencia, es más difícil mantener la integridad de la señal. Actualmente, debido al diseño del cableado así como la forma de operación del protocolo Parallel SCSI, éste trabaja a velocidades en el orden de los 320MB/sec, que difícilmente se pueden superar sin arriesgar la integridad de la señal. • Transporte de datos. La tecnología Parallel SCSI utiliza un bus de datos de tipo “multidrop”, donde todos los dispositivos están físicamente conectados con los mismos cables a un backplane comun, y cada dispositivo debe negociar el uso del medio por un determinado tiempo. Esto es orquestado por un controlador que habilita a los dispositivos para recibir o enviar datos. Podríamos decir que es como una línea de teléfono usada por varias personas para realizar llamadas. Obviamente, el problema de esto es que en periodos de alta transmisión de datos por parte de todos los dispositivos, se presentaran momentos de espera para poder acceder al bus o medio de transporte. Este problema se encuentra frecuentemente en aplicaciones que requieren de un alto número de discos. • Conectividad de dispositivos. Debido a las limitaciones generadas por el mecanismo de selección de dispositivos, así como al efecto negativo de agregar múltiples dispositivos a un mismo canal de comunicación, la tecnología Parallel SCSI esta limitada a un total de 16 dispositivos por bus. Esto limita la topología y escalabilidad de dispositivos que utilicen esta tecnología.

MAY-JUN 2007

La necesidad de una nueva tecnología Las implementaciones actuales de SCSI están llegando a su límite, y no podrán satisfacer las necesidades futuras de conectividad y transferencia de datos, especialmente para aplicaciones con grandes volúmenes de operación. Fue así que se decidió crear una nueva tecnología que se basara en los mismos estándares de SCSI y utilizara los mismos comandos, pero pudiera superar las limitantes de velocidad y conectividad de Parallel SCSI. El resultado es SAS.

Características de SAS •Entre las principales características de SAS, podemos resaltar las siguientes: • El cable tradicional para conectar dispositivos (ribbon cable) es reemplazado por cable de par trenzado punto a punto, lo que permite que la señal pueda viajar una mayor distancia y a frecuencias mucho mayores, sin comprometer su integridad. • Los dispositivos en SAS están interconectados al controlador utilizando líneas de cableado con una arquitectura de switching. Los dispositivos se encuentran ahora conectados a una red de switching llamados expanders. • Ahora que los dispositivos ya no se encuentran en un bus compartido, sino en una red de conexiones con switching, se incrementa considerablemente el ancho de banda que pueden manejar. Tan pronto como un dispositivo desee transmitir o recibir datos, la controladora habilita un canal de comunicación. La controladora deje de ser un policía que controla un canal y ahora funge como habilitador de conexiones. • SAS es compatible con el esquema de tecnología serial ATA (SATA), permitiendo así conectar dispositivos SAS o SATA al mismo canal. Este cambio abre un universo de posibilidades para la combinación de dispositivos y configuración de sistemas de almacenamiento para cualquier especificación deseada. • El número de dispositivos que podemos interconectar es prácticamente ilimitado (miles de dispositivos). • Las velocidades de conexión actuales están alrededor de los 3 GB por segundo, pero ya se está trabajando para llegar a 6 GB/seg. y en un futuro se espera llegar a 12 GB/seg. Por todas estas características, la tecnología SAS se vuelve una excelente opción para utilizar en sistemas de almacenamiento versátiles y de gran escalabilidad.

Referencias • en.wikipedia.org/wiki/Serial_Attached_SCSI • www.equallogic.com

www.softwareguru.com.mx

MAY-JUN 2007

////TECNOLOGÍA TECNOLOGÍA

/* GADGETS */

Samsung

Monitor LCD 932B Con la llegada de Windows Vista, los fabricantes se han dado a la tarea de desarrollar monitores que no sólo soporten el nuevo sistema operativo de Microsoft, sino que también saquen en el mayor provecho de sus capacidades visuales y gráficas, tal es el caso de éste con un área visible de 19 pulgadas, contraste de 700:1, resolución máxima de 1280 x 1024, 16.2 millones de colores y entradas de señal de video análoga RGB, digital DVI; señal de sincronía separada H/V, compuesta y SOG. Además cuentas con características especiales como lo son: seis modos de despliegue, calibración de color, fácil control de mouse, ajuste de un clic y optimizado para un mejor lugar de trabajo, es decir, según el lugar donde se coloque provee la visibilidad necesaria para evitar reflejos molestos.

Linksys

Wireless-G Game Adapter Este pequeño dispositivo es nada más y nada menos que un adaptador de red diseñado especialmente para las consolas de videojuegos, que permite a los usuarios conectar, sin necesidad de cables, consolas como PlayStation 2, Xbox o GameCube para jugar frente a frente, en juegos en línea y en vivo para varios jugadores. Por otra parte, ofrece mantener la conectividad de alta velocidad para varias consolas, por lo que el juego puede continuar sin tiempo de espera. Así pues, mientras que la consola está en la recámara o la sala, la conexión a Internet o DSL o cable, puede seguir en el estudio o cualquier otra habitación de la casa.

Research in Motion

BlackBerry 8800 El modelo 8800 de BlackBerry es un smartphone esbelto, elegante y de alto rendimiento. Ofrece las funciones características de BlackBerry, tales como teléfono, correo electrónico, organizador, mensajería instantánea y navegación Web. Sin embargo, la característica principal de este modelo y que es la distingue de otros BlackBerry es su capacidad GPS, la cual habilita aplicaciones y servicios de localización y mapeo. El 8800 viene con una súper conectividad, ya que incluye Bluetooth 2.0, WIFI 8002.11b/g, EDGE cuatribanda.

SanDisk

Extreme III SDHC Con 4GB de capacidad, esta tarjeta de memoria incluye un lector USB MicroMate para ofrecer a los usuarios una solución completa para capturar, guardar y transferir imágenes. En ella se puede almacenar más de 2 mil fotografías en alta resolución o hasta ocho horas de video MPEG4. Los principales fabricantes de cámaras digitales están brindando el formato SDHC diseñado para permitir capacidades mayores a 2GB. Esta tarjeta tiene una velocidad secuencial de lectura-escritura de 20MB por segundo, puede funcionar en temperaturas extremas y otras sitauciones exigentes.

Lenovo

ThinkPad X60 Tablet Es una tablet convertible que además de innovación provee portabilidad y rendimiento. Incluye dos nuevas opciones de pantalla y otras características como el Active Rotate que hace girar la pantalla de 12 pulgadas instantáneamente en la dirección deseada. Contiene un disco duro SATA de 2.5 pulgadas (100GB o 120GB a elegir) de alta velocidad y resistencia a los golpes, Batería de larga duración con más de 10 horas. Gracias a su peso de tan sólo 1,70 kilos es muy ligera y fácil de transportar. Algunos de estos modelos están listos para Windows Vista y Vista Premium. La X60 contiene varias funciones y tecnologías como Multiview y Multitouch; el primero para imágenes nítidas y de gran resolución; y le segundo para el fácil ingreso de información. Se le puede agregar un lector de huella dactilar para mantener seguro el contenido de la Tablet.

MAY-JUN 2007

www.softwareguru.com.mx

MAY-JUN 2007

// COLUMNA

/*TIERRA LIBRE*/

ViveLinux

Academia y profesionistas unen esfuerzos por Sonia Sánchez

Si bien es cierto que cada vez más personas y organizaciones se convencen de las bondades del software libre, también es cierto que difundirlo nunca estará de más. Esta es la razón de ser del proyecto ViveLinux, al que podemos describir como una campaña de promoción y difusión del uso de GNU/Linux y el Software Libre (SL) en instituciones educativas de nivel medio superior y superior en el estado de Morelos.

Origen Este proyecto surgió gracias al interés de una de las docentes del plantel Yecapixtla del Colegio de Estudios Científicos y Tecnológicos (CECYT) del Estado de Morelos de sembrar entre sus alumnos un interés por el software libre, ya que además de las ventajas de uso que ofrece, es una excelente herramienta de educación para el desarrollo de software. Fue así que la profesora se acercó a uno de los miembros del Grupo de Usuarios de Software Libre de Cuautla (GRUSLIC), y entonces surgió la iniciativa de este proyecto.

¿Y entonces? El primer paso fue redactar un manifiesto donde se establecieron los lineamientos del proyecto. Esto permite alinear esfuerzos y tener una mejor organización. El siguiente paso ha sido el de desarrollar materiales para sesiones educativas orientados al ámbito del SL. Las sesiones pueden tener alguna de las siguientes modalidades: •Pláticas de introducción. •Tutoriales. •Talleres. •Sesiones de Instalación, mejor conocido como InstallFest. •Integración a proyectos de Software Libre. Los temas son propuestos por los mismos profesores de los planteles y miembros del Gruslic, y típicamente se enfocan en alguna de las siguientes áreas de interés: •Introducción al SL. •Filosofía de la comunidad de SL. •Desarrollo Web. •Lenguajes de Programación. •Redes. •Diseño Gráfico. Dado que la audiencia de las sesiones puede tener diferentes niveles de conocimiento y experiencia, las sesiones son clasificadas de

acuerdo a los siguientes niveles de complejidad: •Básico: Temas fundamentales sobre el movimiento y uso del Software Libre. •Medio: Se enfocan en el uso y configuración de tecnologías y herramientas específicas, por lo que la audiencia debe al menos estar familiarizada con éstas. •Avanzado: Orientados a temas como seguridad, compilación, configuración de servicios, combinación e integración de tecnologías.

Resultados La primera visita a un CECYT se realizó en septiembre del 2006. A la fecha se han realizado 6 visitas a 4 diferentes planteles, siendo estos los de Yecapixtla, Tenextepango, Emiliano Zapata, y Tlayecac. Cabe destacar que en el plantel de Emiliano Zapata ya se realizó un InstallFest, y se habilitó una de sus CompuAulas con software libre. Estas visitas y la difusión de sus logros, han tenido como consecuencia que Universidades de otros estados contacten al grupo para llevar hasta sus aulas una sesión de pláticas adaptadas a las necesidades del auditorio, tomando en cuenta los lineamientos que señala el manifiesto.

¿Dónde encuentro más información? El wiki del manifiesto está disponible y esperando tu colaboración. Este lo puedes encontrar en http://wiki.gruslic.org.mx/Vive_linux Así mismo, el Grupo de Usuarios de Software Libre de Cuautla (www.gruslic.org.mx) espera tu participación y que te unas a nosotros para promover este manifiesto. Todos los comentarios son bien recibidos, y la ayuda aún más. Contáctanos en http://groups.google.com.mx/group/gruslic.

Conclusión La inquietud de una profesora de informática a nivel bachillerato dio pauta para el nacimiento del proyecto que en poco más de 6 meses de vida ha recorrido cuatro municipios del estado de Morelos, y está generando interés en otros estados. Esta es una muestra de cómo la academia y los profesionistas pueden trabajar en conjunto para llevar nuevas opciones de aprendizaje a los estudiantes de nuestro país.

Sonia Sánchez es Licenciada en Informática, dedicada al desarrollo de soluciones basadas en Software Libre. Es miembro activo del Grupo de Usuarios de Software Libre de Cuautla y ha sido ponente en congresos como ENLI en Puebla y CICOL en Morelos, y participa frecuentemente en los festivales de instalación de software libre que se realizan en estas entidades.

MAY-JUN 2007

www.softwareguru.com.mx

INDEX

DIRECTORIO

TENEMOS UN ESPACIO RESERVADO PARA TI

Anunciante

Pรกginas

Sitio

Avantare CIISA e-Quallity Four JS Gartner Intersoftware IDC Information Security Innevo Itera Microsoft Milestone Consulting NYCE SafeNet Softtek ExpoElectrรณnica

15 39 41 45 49 F3 51 07 35 13 F2-1 F4, 43 29 47 53 55

www.avantare.com ciisa.gda.itesm.mx www.e-quallity.net www.fourjs.com www.gartner.com www.intersoftware.com.mx www.idc-eventos.com www.informationsecurity.com.mx www.innevo.com www.itera.com.mx www.microsoft.com/mexico www.milestone.com.mx www.nyce.com.mx www.safenet-inc.com www.softtek.com www.electronicaexpo.com.mx

Si deseas anunciarte contรกctanos en el (55) 5239 5502 o en ventas@softwareguru.com.mx

www.softwareguru.com.mx

MAY-JUN 2007

// CARRERA

Un Modelo Paracurricular para la Industria de Software Atacando la brecha entre industria y academia Por Lourdes Sánchez

Es ampliamente reconocido que el capital humano es el activo más importante de la industria del software. Por ello, cualquier país que pretenda destacar en ella, debe garantizar un proceso formativo sólido para que los profesionistas desarrollen las competencias necesarias. En este sentido, una de las principales problemáticas que actualmente vivimos, es que la academia no está generando graduados con los conocimientos y habilidades que busca la industria. La industria está demandando profesionistas con un perfil técnico, especializados (e idealmente certificados) en tecnologías específicas. Sin embargo, las universidades consideran –y con justa razón– que su prioridad debe ser formar personas con capacidad de razonamiento, aprendizaje e innovación, ya que estas habilidades son las que les serán de mayor ayuda al largo plazo.

se complementa el modelo curricular tradicional, con el modelo paracurricular, cuyo objetivo es habilitar a los estudiantes con los conocimientos requeridos por la industria. Modelos Curriculares Perfiles

Planes y Programas de Estudio TI Nivel Superior

Modelo Paracurricular Desarrollo de Software Perfiles

Conocimientos y Competencias Áreas

Emprenedor de Negocios Administrador de proyectos y procesos

Desarrollo Empresarial Calidad

Arquitecto Nivel Técnico Superior Universitario Nivel Técnico Medio Superior Docentes/Tutores

Ingeniero Desarrollador

Sistemas Distribuidos Programación

Cursos

Herramientas

Esta disparidad de objetivos entre industria y academia provoca la gran brecha que actualmente existe entre lo que necesitan las empresas, y lo que provee la academia. Este es un problema que ha sido ampliamente discutido, y de hecho algunas universidades ya están tomando acciones, como es la de incluir en sus planes de estudios cursos orientados a la certificación en tecnologías específicas.

Fig.1. Modelo paracurricular como estrategia.

Presentando el modelo paracurricular

Implantación

Como parte de los esfuerzos de la estrategia 2 de ProSoft (“Educar y formar personal competente en el desarrollo de software, en cantidad y calidad convenientes.”), la ANIEI (Asociación de Instituciones de Educación en Tecnologías de la Información, A.C.) y el ILCE (Instituto Latinoamericano de la Comunicación Educativa) hemos desarrollado e implementado un modelo paracurricular para esta área. Éste consiste en un acervo de conocimientos y desarrollo de competencias complementarias a la formación profesional.

La implantación del modelo paracurricular se logrará por la vía de formación de docentes, alumnos y egresados de instituciones educativas; también mediante la formación del capital humano que se encuentra laborando en el sector productivo así como a través de la generación de contenidos y la creación de materiales pertinentes por modalidad de aprendizaje, por la impartición de cursos (presenciales y en línea) con el apoyo de tutores, y fundamentados en estrategias de innovación educativa dinamizada y enriquecida por el empleo de tecnologías de información para impartir los cursos.

El modelo paracurricular permite actualizar y capacitar al capital humano requerido por la industria del software de manera flexible, ágil y permanente. Estamos convencidos de que la brecha tecnológica puede ser disminuida al implementar este modelo, sobre todo si logramos incorporar las necesidades de la industria para complementar los perfiles académicos definidos en la actualidad. Las áreas de conocimiento que la industria del software requiere actualizar constantemente son las de: Programación, Calidad, Sistemas Distribuidos y Desarrollo Empresarial. De aquí surgen los cuatro perfiles que la industria requiere: Desarrollador, Ingeniero, Arquitecto, Administrador y Emprendedor.

Estructura del modelo

Acreditación

Instituciones Educativas

Certificación TI

Certificación

Vinculación Académica-IndustriaGobierno

Industria del Software

Conclusión La Academia, la Industria y el Gobierno deben estrechar sus mecanismos de colaboración con el fin de impactar de manera definitiva en la formación de capital humano en tecnologías de la información en México. El modelo paracurricular busca resolver un reto puntual que enfrentamos actualmente en la formación de profesionistas de software. Sin embargo, existen muchos otros esfuerzos y líneas de acción que están en curso como parte de la estrategia 2 de ProSoft. Esperamos poder compartirlos con ustedes en futuras publicaciones de SG.

La figura 1 refleja la estructura del modelo propuesto, donde se ve como

Ma. de Lourdes Sánchez es profesora investigadora del Departamento de Sistemas en la Universidad Autónoma Metropolitana Unidad Azcapotzalco. Sus áreas de especialidad incluyen sistemas operativos, seguridad informática, formación de recursos humanos en tecnologías de la información, modelos curriculares. Es presidenta de la Asociación Nacional de Instituciones de Educación en Tecnologías de la Información A.C. (ANIEI), responsable de la Estrategia 2 del Programa Prosoft y Representante de México en el Centro Latinoamericano de Estudios en Informática (CLEI).

MAY-JUN 2007

www.softwareguru.com.mx

Aﾃｱo 03 No. 03

www.softwareguru.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Mayo-Junio 2007