EN SERIE - desquer.ens.uabc.mxdesquer.ens.uabc.mx/afi/articulos/SG05_2_mar_abr.pdf · EN SERIE...

EN SERIECentros de Desarrollo de Software

ENTREVISTA:

Blanca TreviñoCEO de Softtek

EDUCACIÓNModelos y

Tendencias

• MoProSoft en la práctica

• La problemática de pruebas

• Estructura de paquetes J2EE

Software Guru CONOCIMIENTO EN PRÁCTICA

Además: Noticias • Eventos • Fundamentos • Biblioteca • Tecnología • Carrera

Año

01

No.

02

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

M

arzo

-Abr

il 2

005

Año 01 No.02 • Marzo-Abril 2005

A FondoXMLSpy 2005

DIRECTORIO

02 MAR-ABR 2005 www.softwareguru.com.mx 03MAR-ABR 2005www.softwareguru.com.mx

Edición EjecutivaPedro Galván

Coordinación EditorialMara Ruvalcaba

Edición y ProducciónEdgardo Domínguez

Dirección de ArteOscar Sámano

Consejo Editorial Francisco Camargo, Guillermo Rodríguez, Ralf Eder y Raúl Trejo, ITESM CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek.; Luis Vinicio León, e-Quallity

ColaboradoresOmar Ruvalcaba, Kendra Medina, Alfonsina Morgavi, Claudia Alquicira, Ma. Julia Orozco, Luz Ma. Luckie,Ramés Rodríguez, Ramón Hernández, Alfredo López, Ariel García, Karla García, Luis Daniel Soto

Ventas David González

Marketing Natalia Sánchez

Webmasterwww.aguilahosting.com

[email protected]+52 55 5239 5502

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. 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 conteni-do:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en febrero de 2005 en Litográfica Roma S.A. de C.V. Distribuido por Sepomex.

La noción de industrializar el desarrollo de software ha sido un tema bastante popular en los últimos años. Cada que escuchamos sobre un proveedor de ser-vicios que se autoproclama como fábrica de software, es difícil evitar pensar en qué tanto es realidad y qué tanto es moda. Definitivamente la evolución de esta industria hacia modelos de mayor productividad no es una moda, es una necesidad. Los centros de desarrollo de software son un paso importante en esta evolución, por lo que es importante conocer su modelo de trabajo. Para ejemplificar, hemos seleccionado tres empresas pioneras, que brindan un ser-vicio de clase mundial.

En este número también hablamos sobre los perfiles de carrera relacionados con TI, actualmente disponibles en México. Consideramos que este es un tema de vital importancia, dado que como todos sabemos, estamos en una industria alta-mente intensiva en capital humano, donde es fundamental una formación educa-tiva competitiva a nivel mundial.

Queremos agradecer las facilidades otorgadas por los diferentes centros de desa-rrollo, especialmente a: Blanca Treviño, Alejandro Camino, Alejandra Ancira y Yaneth Herrera en Softtek; Carlos Cevallos, Carlos López, Isabel Calderón y Vanessa Romero en IBM; Arnoldo Díaz, Sergio Durán y Alberto Balderas en Certum.

Equipo Editorial

P.D. Continuamos agradeciendo el apoyo por parte de todos ustedes. Estamos muy contentos por el gran recibimiento que ha tenido Software Guru, así como las ex-pectativas que estamos generando. Agradecemos el interés de nuestra audiencia en América Latina, especialmente de Alfonsina Morgavi, nuestra primera colabora-dora internacional.

A >

EDITORIAL

contenido mar-abr 2005 número 02

EN PORTADACentros de Desarrollo de Software: Un Nuevo Paradigma ¿Qué es un centro de desarrollo de software? ¿Cómo funcionan y cuáles son algunos ejemplos en nuestra región?

20

Productos

LO QUE VIENE 10Borland Core SDP y RFID

A FONDO 12Altova XMLSpy 2005

HERRAMIENTAS 14Object-Relational Mapping

Caso de Estudio

MoProSoft en la Práctica 32Ma. Julia Orozco y Claudia Alquicira comparten su experiencia en la implantación de MoProSoft en una empresa de desarrollo de software.

Prácticas

PRUEBAS 36Transitando hacia el CambioPoco a poco se valora mås el valor de las pruebas de software. Alfonsina Morgavi nos comparte su experiencia en la formación y reclutamiento de ingenieros de pruebas.

ARQUITECTURA 38Estructura de Paquetes para Sistemas J2EEOrganizar las clases en un sistema J2EE no es algo trivial. Ramsés Rodríguez nos recomienda una estrategia para definir una jerarquía de paquetes adecuada.

Columnas

Tejiendo Nuestra Red 06por Hanna Oktaba

Mejora Continua 08por Luis Cuellar

Cátedra y Más 41por Ralf Eder

Consideraciones Legales 16 en el Desarrollo de Software

Entrevista 18 Blanca Treviño, CEO de Softtek

En Cada Número

Noticias y Eventos 04Fundamentos 42Tecnología 44Biblioteca 46Carrera 48


Educación 28 Modelos y Tendencias


2-3 Marzo 2005Sun Tech DaysSun MicrosystemsWorld Trade CenterCiudad de MéxicoInfo: www.suntechdays.com.mx e-mail: [email protected]

2,3,4,9,10 y 11 Marzo, 13,14,19,27 y 29 AbrilDeveloper DaysMicrosoftMarzo: 2 y3 Cd. Juárez, 4 Chihuahua, 9 Los Mochis, 10 - Culiacán, 11 - Mazatlán. Abril: 13 - Cd. de México (por confirmar), 14 - Aguascalientes, 19 - Tuxtla Gtz., 27 - Zacatecas, 29 - PueblaInfo: www.microsoft.com/spanish/msdn

2 y 15 Marzo, 5 y 19 Abril 2005Talleres Software.net.mxSecretaría de Economía y MicrosoftAuditorio de la Secretaría de Economía (Condesa)Ciudad de MéxicoInfo: www.software.net.mxTel: 01800-849-9959e-mail: [email protected]

7-10 Marzo 2005SEPG 2005 - Deliver Winning Products Through Process ImprovementSoftware Engineering InstituteWashington State Convention & Trade CenterSeattle, WashingtonInfo: www.sei.cmu.edu/sepge-mail: [email protected]

14-18 Marzo 2005SD West 2005 – Develop an AdvantageCMP MediaSanta Clara Convention CenterSanta Clara, CaliforniaInfo: www.sdexpo.come-mail: [email protected]

18 Marzo 2005Diplomado en Calidad de SoftwareAsociación Mexicana para la Calidad en Ingeniería de Software (AMCIS)Ciudad de MéxicoInfo: www.amcis.org.mx Tel: (55) 5563-5039e-mail: [email protected]

Marzo-Abril 2005Eventos 18 Marzo 2005Seminario Proceso de Desarrollo de SoftwareUniversidad Autónoma de Nuevo León y KernelDirección General de InformáticaMonterrey, Nuevo LeónInfo: www.kernel.com.mx Tel: (81) 8625-2500e-mail: [email protected]

6-7 Abril 2005III Cumbre Gartner – Integración de Apli-caciones y Servicios WebGartnerCentro BanamexCiudad de MéxicoInfo: www.gartner.com/mx/appint Tel: (55) 5207-2695e-mail: [email protected]

28 Abril 2005Seminario Gratuito “Logrando Proyectos Exitosos con Subcontratistas de Software y Creando una Oficina deProyectos Práctica y Efectiva”IteraCd. de MéxicoInfo: www.itera.com.mxTel: (55) 5281-7670e-mail: [email protected]

16-20 Mayo 2005StarEast 2005 - Software Testing ConferenceSoftware Quality EngineeringThe Rosen Centre HotelOrlando, FloridaInfo: www.sqe.com/stareast e-mail: [email protected]

22-26 Mayo 2005Rational Development Conference 2005IBM Rational Software Mandalay Bay ResortLas Vegas, NVInfo: www.ibm.com/software/rational/events/rsdc2005/ Tel: +1(888) 889-0074e-mail: [email protected]

Mayo 2005

CASO DE ESTUDIO

IBM México obtuvo el máximo nivel del modelo Capability Maturity Model Integration (CMMI) para desarrollo de software

IBM de México, a través de la organiza-ción de Servicios de Gestión de Aplica-ciones (AMS, por sus siglas en inglés), obtuvo el Nivel 5 de capacidad y madurez bajo el modelo Capability Maturity Model Integration (CMMI) para desarrollo de software, que otorga el Instituto de Inge-niería de Software (SEI) de la Universidad Carnegie Mellon, Estados Unidos. “En la búsqueda por ofrecer mejores servicios y productos de alta calidad a nuestros clientes, decidimos evolucionar el pro-grama de mejora continua de procesos, reemplazando el modelo de referencia anterior por el más reciente modelo del SEI: CMMI, el cual está siendo adoptado por la industria de software a nivel mun-dial como el nuevo marco de referencia para evaluar la capacidad de las organi-zaciones para entregar productos y servi-cios de alta calidad”, señaló Carlos López Santibáñez, director AMS Latinoamérica de IBM de México.Para mayor información, visita:www.software.ibm.com

Se inaugura el Progama TechBA

El pasado 28 de febrero fue inaugurada la primera Aceleradora de Negocios de Tec-nología - México y Silicon Valley, conocida como el Programa TechBA. Dicha acelera-dora pertenece a un programa de la Se-cretaría de Economía y es administrada por la Fundación México-Estados Unidos para la Ciencia (FUMEC), en colaboración con The Enterprise Network (TEN), y apo-yada por el Instituto Tecnológico y de Es-tudios Superiores de Monterrey (ITESM), la Universidad Panamericana (UP) y el Instituto Politécnico Nacional (IPN). En el Programa TechBA ya están trabajan-do las primeras compañías, entre ellas 3dmx, productora de animación 3D para juegos y películas; Tralcom, proveedor de contenido de e-learning; Pess M&D Cen-ter, comisionados en plantas eléctricas, puesta en operación, y mantenimiento; BlockNetworks, proveedor de soluciones ERP y BPM; Stakeware, software de res-ponsabilidad social; y Azertia, proveedor de soluciones personalizadas para em-presas pequeñas. Todas estas compañías han desarrollado productos y servicios innovadores, y están listas para extender su mercado en Silicon Valley.Para mayor información visita:www.techba.com

Secretaría de Economía Publica las Reglas de Operación de ProSoft

El pasado viernes 18 de febrero, la Se-cretaría de Economía dio a conocer las Reglas de Operación del Programa para el Desarrollo de la Industria del Soft-ware (ProSoft), en el Diario Oficial de la Federación. Estas reglas especifican in-formación relacionada con organismos participantes, beneficiarios, criterios de elegibilidad y tipos de apoyo, como: capital humano, calidad y capacidad de procesos, innovación y desarrollo tecnológico, proyectos productivos, de-sarrollo de capacidades empresariales y de estrategia, acceso al financiamien-to, promoción y comercializacion, y de-sarrollo de masa crítica, entre otros. También lista a detalle el presupuesto asignado y montos de apoyos para las diferentes categorías, incluye el formato de la solicitud de apoyo, y muestra cada actividad a ejecutarse para llevar a cabo el proceso comple-to de evaluación, otorgamiento, y se-guimiento de fondos. Para mayor información visita: www.software.net.mx

ExpoComm México 2005consolida su liderazgoDel 8 al 11 de febrero se llevó a cabo con gran éxito EXPOCOMM MÉXICO 2005. Innovación y convergencia tecnológica fueron las principales características que 23,302 profesionales de Telecomu-nicaciones y Tecnologías de Información (TIC) pudieron presenciar durante este foro. Ésta fue la 14a edición de EXPOCOMM, que se consolidó como el foro de Telecomunicaciones y Tecnologías de Información más importante en México. En su interés por cubrir el ámbito de software, EXPOCOMM presentó los pabellones espe-cializados de Soluciones de Seguridad y Almacenamiento, y el de Consultores e Integradores. El programa de conferencias de EXPO-COMM incluyó conferencias magistrales de Motorola, Nortel, IBM e Intel y la realización en paralelo del Foro Tendencias de Select, lo cual reunió a expertos nacionales e internacionales para compartir su experiencia sobre retos y tendencias en México y el mundo.Para mayor información, visita: www.expocomm.com.mx

Noticias

Eventos

Barry Boehm

Victor Basili

En enero de este año me tocó viajar al sorpresiva-mente frío Orlando para participar en el segundo taller del International Process Research Con-

sortium (IPRC), cuyo objetivo es definir el mapa y la ruta (roadmap) de la investigación en el área de procesos de software para los próximos cinco-diez años. En esta oca-sión se incorporaron dos grandes figuras de la Ingeniería de Software, uno de ellos es Barry Boehm, el famoso autor del modelo espiral para el desarrollo de software, quien acaba de publicar, con Richard Turner, un nuevo libro bajo el muy llamativo título: Balancing Agility and Discipline, A Guide for the Perplexed. El segundo famoso es Victor Basili, conocido por su modelo GQM (Goal-Question-Metric), quien resultó ser una persona muy participativa y amena. En este taller también ya se cerró el grupo de patrocinadores, quienes por una módica cuota de $150,000 USD tienen derecho de mandar a un representante a cada taller. Entre ellos se encuen-tran Bosch de Alemania, Tata de la India y los demás provienen de organizaciones estadounidenses como Lockheed Martin, Florida IT Centres of Excellence, University of Pittsburgh y, por supuesto, Software Engineering Institute.

Para que nos ubicáramos en el tiempo y entendiéramos me-jor qué es lo que pueda pasar en un lapso de diez años, los organizadores nos pidieron recordar y compartir nuestras ex-periencias personales de hace diez años. Fue muy divertido y muy aleccionador escuchar experiencias personales, las cua-les, en su mayoría, fueron bastante lejanas de los intereses y quehaceres actuales de los participantes. Para cumplir con el encargo, revisé mi CV para constatar que hace diez años me dedicaba a dar cursos en la maestría de Diseño OO (ba-sada en libros y artículos de Booch, Dijkstra, Hoare y Brinch Hansen) y Tipos de Datos Abstractos y Estructuras de Datos con especificaciones algebraicas al estilo de John Guttag. ¡Ah, qué tiempos aquellos!

Una buena parte del tiempo del taller nos dedicamos a fa-miliarizarnos con la técnica de construir escenarios para imaginar lo que puede pasar dentro de diez años. Se ha hablado de grandes tensiones en el mundo entre Prospe-ridad & Pobreza (migración), Intangibles & Físicos (servi-cios, comunicación), Poder & Vulnerabilidad (más poder, más vulnerabilidad), Aceleración Tecnológica & Retroceso (problemas éticos), Laicismo & Sagrado (agnosticismo vs. religión), Gente & Planeta (en los próximos veinte años, 98% de la gente va a nacer en los países en desarrollo).

Se han mencionado algunas ideas emergentes, como por ejemplo:• Cambios en los modelos organizacionales (multi-sitios, virtuales)• Crecimiento de la economía informal (también en software)• Acercamiento de sistemas de software a los humanos

• Litigio y rechazo de los humanos con respecto al software • Programación por usuarios finales - ¿vamos a necesitar programadores?• Crecimiento inmenso del poder computacional.

Como anécdota, que confirma algunas de estas inquietu-des, les cuento que el mini-bar de mi cuarto en el hotel de Orlando era tan “inteligente” que bastaba sacar la botella, sin siquiera abrirla, para que te la cargaran a tu cuenta. Antes de retirarme del hotel me llevé la sorpresa de en-contrar en mi cuenta varias cosas nada más por tocarlas. Afortunadamente, el personal de la recepción demostró todavía su lado humano y me creyó cuando juré que so-lamente levante las botellas por pura curiosidad. Pero el disgustó que me llevé antes de que se aclararan las cosas, nadie me lo quita.

En el evento se han hecho preguntas importantes, como por ejemplo:• ¿Qué forma va a tener software en el futuro?• ¿Qué va a pasar si los procesos no progresan más?• ¿Quién controla a la tecnología? ¿Gobiernos, gente o mercado?

Estas preguntas quedaron sin respuesta pero nos abrieron los ojos a un abanico de incertidumbres que debemos anali-zar y tomar en cuenta para hacer propuestas o predicciones.

Para finalizar el taller se realizó una actividad que ya se repitió por segunda ocasión, y que se llama “chaos coc-ktail party”. Cada participante escribió en una tarjeta el tópico más importante, según su parecer, surgido durante este taller. Luego, durante unos minutos intercambiamos las tarjetas entre nosotros y, a la señal dada por la facilita-dora Suz García, nos juntamos en parejas para asignar las calificaciones de 1 a 5 a los dos tópicos comparados. La calificación más alta se asignaba al tópico más importan-te según la pareja. Este “baile” se repitió cuatro veces y, finalmente, se seleccionaron los tópicos mejor evaluados. Para la sorpresa de todos, los seis tópicos más importan-tes rondaban alrededor del tema: Relación clara entre el proceso y la calidad del producto. Sin duda, esta es la ma-yor preocupación de todos los que hoy en día creen en los procesos, y algunos que hasta viven de ellos, porque la evidencia de que realmente sirven es todavía débil.

Tal vez este último comentario suena un poco fuerte. Yo misma, en los últimos años, me he dedicado a predicar sobre procesos. Sin embargo, me parece importante que reflexionemos sobre este tema y nos esforcemos en de-mostrar que la utilidad de los procesos para lograr buenos productos es real.

- Hanna Oktaba

CO

LUM

NA

06 MAR-ABR 2005 www.softwareguru.com.mx

Proceso y Calidad del ProductoUna Preocupación Real

TEJIENDO NUESTRA RED

La Dra. Hanna Oktaba es profesora en la Facultad de Ciencias de la UNAM. Es fundadora y vicepre-sidenta de la Asociación Mexicana para la Calidad en la Ingeniería de Software. Actual-mente dirige el proyecto para la creación de una norma mexicana para la industria de software.

TEJIENDO NUESTRA RED

En nuestra charla anterior hablamos sobre el signifi-cado de crear una organización orientada a procesos con el objetivo de generar resultados repetibles en

forma eficaz y eficiente, facilitar la comunicación y generar un “framework” para administrar el conocimiento. Esto sue-na muy bien, pero si es tan buena idea, ¿por qué no se hace en todas las compañías? Esto se debe a problemas tanto de definición como de implantación. En esta ocasión hablare-mos de los problemas de definición y en nuestra siguiente charla hablaremos de problemas de implantación.

El Proceso PerfectoUn elemento que he encontrado en forma consistente en el área de sistemas, es lo mucho que nos maravilla defi-nir procesos, y a su vez la gran falta de entusiasmo para operar los mismos. El mercado está lleno de consultores, libros, maestros y “jefes” de corazón, vendiendo la solu-ción a todos nuestros problemas. Esto sugiere la idea de que existe un conocimiento mágico, un proceso perfecto o una única solución al problema de desarrollo de soft-ware. Creo que esta por demás decir que este proceso, ¡NO EXISTE!

En los últimos años he apoyado a varias organizaciones a alcanzar niveles de CMM y Seis Sigma. Una estrategia que he visto comúnmente es la de juntar a los grandes exper-tos de la organización para definir la metodología perfecta que servirá de guía sobre lo que tienen que hacer todos los demás. Esta estrategia tiene tres riesgos importantes:

1. Existen pocos incentivos a escuchar lo que actualmen-te sucede en los proyectos. La premisa de estos grupos acostumbra ser: “Todo lo que hacemos actualmente está mal y tenemos que definir algo nuevo para arreglar todos nuestros problemas”. Lo ideal es iniciar con aquello que actualmente funciona, asegurar que entrenamos a toda la organización para hacer el trabajo de la misma manera, y sólo cuando no estamos haciendo algo para controlar una práctica clave debemos definir algo nuevo. En la práctica, el problema de definir un proceso es diez por ciento del problema de implantarlo, por lo que si ya existe y se cono-ce es mejor sólo documentarlo.

2. Los nuevos procesos ya no se mejoran posteriormente. Después de todo, ¿quién puede mejorar el proceso si los mejores ya lo definieron? Desafortunadamente el proceso perfecto no existe, una de los características básicas de la definición debe de ser su facilidad de modificarse. Desde la definición se debe de estar consciente de la importancia de definir algo flexible y fácil de modificar, que se adecue a la problemática actual y futura.

3. La definición se tarda meses y después ya nadie tiene tiempo de implantar los procesos en la organización. El que define debe continuar con la implantación. Si la direc-ción define, es porque ellos van a implantar. Sino, enton-ces no deberían estar definiendo.

Otra estrategia es la de comprar un proceso en el mercado e implantarlo en la organización. En este caso es vital con-templar cómo se capacitará o modificará el proceso una vez que el consultor termine su trabajo.

En este punto permítanme ser lo más claro posible: NO EXISTE EL PROCESO PERFECTO. Muchas veces es mejor implantar un proceso que toda la organización esté dis-puesta a seguir, en lugar de uno que un consultor diga que es el mejor proceso jamás generado. En el momento en que estamos cambiando a una organización orientada a procesos, estamos trabajando con la idea de que estos procesos son dinámicos, por lo que se requiere gente en-cargada de mantenerlos actualizados constantemente y entrenando a los equipos de trabajo en forma constante.

Best PracticesPersonalmente siento que el término “Best Practice”, es uno de los grandes frenos de la industria de software. Creado con finalidad de mercadeo, el término lleva consigo la idea de una “solución mágica” que resuelve tus proble-mas; que de todas las soluciones que existen en el mun-do, es la mejor. Sin embargo, todas las prácticas tienen un valor con respecto a su contexto. Una práctica que fue exitosa en un ambiente abierto y con pocas restricciones puede ser inoperable en una organización con fuertes ni-veles de control. Desafortunadamente, cuando queremos definir nuestros procesos, todas estas grandes prácticas se atraviesan en nuestro camino generando dudas, ya que queremos que lo que definamos suene impactante cuan-do lo presentemos a nuestros clientes y empleados.

ConclusiónLo que busco decirles con todo esto es: no existe un proce-so perfecto; no existe la solución mágica que sólo tengan que copiar y obligar a su gente a seguir. El mejor proceso que podemos definir es uno que sea sencillo de aprender, operar y fácil de mejorar, que controle de alguna manera el trabajo que hacen actualmente, y que las personas estén dispuestas a implantar ellos mismos en sus proyectos.La próxima ocasión platicaremos sobre la implantación de los procesos, sus problemáticas y cómo beneficiarse al máximo de la estrategia de implantación.

- Luis Cuellar

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 CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.


CO

LUM

NA

El Proceso a SeguirProblemas en la Definición de Procesos

MEJORA CONTINUA

MEJORA CONTINUA

PRODUCTOS


PR

OD

UC

TO

S

Microsoft con Visual Studio Team System, que se espera para verano 2005.

Detrás del Core SDP están las herramientas que ya conocemos de Borland: Together (modelado visual), CaliberRM (administra-ción de requerimientos), StarTeam (gestión de configuración y cambio), JBuilder (de-sarrollo Java) y OptimizeIt (pruebas). Sin embargo, la nueva oferta consiste en una infraestructura unificada. Cada rol puede ver información de los demás roles sin tener que utilizar productos separados. Por ejemplo, desde Core Developer se pueden acceder los requerimientos.

De acuerdo con Patrick Kerpan, CTO de Borland, lo que puede llegar a diferenciar al Core SDP de sus competidores, son cier-tas piezas que serán liberadas en un futuro próximo y están dirigidas hacia los roles de gerencia y dirección.

El Core SDP es parte de la estrategia de Bor-land llamada Software Delivery Optimization

(SDO), que busca traer un enfoque indus-trializado al desarrollo de software. Según Borland, esta estrategia difiere de la de IBM y Microsoft en cuanto a que su alcance es mayor porque no sólo llega hasta los niveles de gerencia, sino que también involucra a los niveles directivos.

Además de proveer herramientas de soft-ware, la estrategia SDO busca proporcionar ayuda a las empresas en cuanto a cómo de-sarrollar software alineado con las metas de negocio. Para reafirmar esta iniciativa, Borland recientemente adquirió la empresa TeraQuest Metrics, una consultora especia-lizada en procesos de desarrollo.

Core SDP maneja dos versiones de Core De-veloper: una basada en JBuilder y otra en Eclipse. Próximamente se agregará soporte para Visual Studio.

C++Builder ha quedado fuera de Core SDP.Borland ha anunciado que este producto se manejará como parte de la familia Delphi.

Borland Core SDPPLATAFORMA BASADA EN ROLES

Borland lanzó al mercado su nue-va plataforma de productos llama-da Core SDP (Software Delivery Platform), anteriormente conoci-da con el nombre clave “Themis”. Core SDP es una plataforma inte-grada basada en roles que inclu-ye Core Analyst, Core Architect, Core Developer y Core Tester. Esta estrategia basada en roles, y no en productos, es similar a la que decidió aplicar tanto IBM con su Software Development Platform lanzada a finales del 2004, como

RFIDPREPARÁNDOSE PARA LA OLA

En los últimos meses hemos sido fuer-temente bombardeados acerca de la tecnología de identificación por radio-frecuencia (RFID), sus múltiples aplica-ciones y cómo cambiará la cadena de suministro. Probablemente ya estén cansados de tanto oír sobre el mismo tema —la verdad es que nosotros ya lo estamos—, sin embargo, dado que em-presas de la talla de Wal-Mart la están empujando y obligando a sus provee-dores a incorporar, debemos reconocer su importancia y prepararnos para ella. Es un hecho que pronto tendremos que desarrollar aplicaciones de software que soporten RFID.

Para comenzar, he aquí una lista de re-cursos para aquellos que quieran dar los primeros pasos hacia el desarrollo de aplicaciones para RFID:

RFID Journalwww.rfidjournal.com

RFID World 2005www.rfid-world.com/rfid05/

Kit de principiantes para RFID www.intensecomp.com/rfid_store_sf.html

SDK en Java para RFIDwww.sun.com/software/solutions/rfid/

LO QUE VIENE

Mustang disponible en java.netMÁS VERSIONES PREVIAS PARA DESARROLLADORES

Sun Microsystems ha hecho disponi-ble una versión previa de la siguiente versión de J2SE, nombre clave “Mus-tang”, a través de java.net, un sitio para la comunidad de desarrollado-res de Java.

En un esfuerzo por ser más abiertos, Sun al igual que Microsoft, están brin-dando acceso a los desarrolladores a versiones previas de sus productos. Microsoft ha mostrado a los desarro-lladores su disponibilidad a ser más transparente al brindar no solamente versiones beta de sus herramientas, sino también las llamadas CTPs (Com-munity Technology Previews) para que los desarrolladores puedan conocer-las y proveer retroalimentación.

PRODUCTOS

A FONDO


La tecnología XML (eXtensible Mar-kup Language) juega un rol clave en los sistemas de información que se

desarrollan actualmente y durante la próxi-ma década por lo menos. Para adoptar esta tecnología y mejorar la productividad de los desarrolladores, es útil contar con herra-mientas para crear, editar, validar y depurar documentos XML. Es por ello que en este número hemos decidido analizar a fondo el XMLSpy de Altova, una de las herramientas para XML más populares del mercado.

XMLSpy es conocido principalmente como un editor XML, pero tiene muchas otras ca-pacidades, como generación de schemas, DTDs y transformación utilizando XSL. Co-nozcamos las principales capacidades de este producto:

Edición en Diferentes VistasUna de las características más importantes de XMLSpy es que provee diferentes vistas para manejar documentos XML de acuerdo al perfil y propósito del usuario. Las cinco vistas que maneja XMLSpy son las siguientes:

• Texto.– Es la vista base para editar documen-tos XML. Contiene características útiles para la edición como sintaxis a color, auto-completar, expandir/colapsar elementos, bookmarking, y formateo automático para indentar los elemen-tos en estructura de árbol. Esta vista también soporta corrección de ortografía en diversos lenguajes, entre ellos el español.

• Grid.– La vista grid (malla o cuadrícula) permite trabajar con documentos XML de una manera similar a como si se estuviera usando una hoja de cálculo. Esto permite realizar operaciones en grupos de elemen-tos en vez de línea por línea.

• Schema/WSDL.– Utilizada para modelar in-terfases avanzadas de datos y web services. Los elementos de WSDL como operaciones, puertos y bindings se pueden visualizar y modificar fácilmente en esta vista.

• Browser.– Permite previsualizar en HTML el contenido generado a partir de datos XML.

• Authentic.– Esta vista está diseñada para que los usuarios finales, que no conocen XML, puedan administrar documentos en un ambiente similar al de un procesador de tex-to. Básicamente es una versión integrada de la herramienta Authentic de Altova, la cual está disponible de manera gratuita.

A través de la vista Schema/WSDL se pueden

modelar interfases avanzadas de datos

Soporte a EstándaresAltova siempre ha sido uno de los pioneros en cuanto a soporte de estándares. Además de soportar los tradicionales, como XQuery, XSLT 1.0 y XPath 1.0, XMLSpy es uno de los primeros en soportar los nuevos estándares XSLT 2.0 y XPath 2.0. Éstos proveen fuertes mejoras en términos de poder, flexibilidad y eficiencia en el manejo de XML.

Interacción conRDBMSXMLSpy interactúa conlos principales maneja-dores de bases de datosa través de interfa-se nativa. Esto permite conectarse a la BD, generar schemas XML en base a la estructu-ra de la BD y viceversa, e importar/exportar datos. Entre los principales manejadores soportados nativamente están Oracle, SQL Server, MySQL, Sybase y DB2.

Precio y Disponibilidad• Enterprise: 99 EUR• Professional: 49 EUR• Home: Gratuito• Disponible a través de la tienda en línea de Altova (http://shop.altova.com)

Requerimientos de Sistema*Windows NT, 2000, XP, 2003256 MB de RAMProcesador Pentium III o superior

*La documentación de XMLSpy no es-pecifica requerimientos mínimos más allá del sistema operativo. Los requeri-mientos de memoria y procesador son los recomendados por Software Guru.

XMLSpy 2005Altovawww.altova.com

VEREDICTO

No solamente XMLSpy es un produc-to muy completo, sino que también su uso es fácil y amigable. Con justa razón es reconocido como el líder en su segmento.

PROS:1. Amplia lista de capacidades.2. Interfaz de usuario amigable.3. Soporte a los estándares más recientes.

CONTRAS:1. Solamente funciona sobre Windows.2. No se manejan distribuidores locales, se debe adquirir en línea.

Altova XMLSpy 2005Líder Indiscutible

Calificación: 5 de 5

tegrar entre ambos documentos. Esta misma funcionalidad puede ser aplica-da a directorios enteros para comparar su contenido.

DepuraciónOtra de las fortalezas de este pro-ducto es su amplia capacidad para depuración (debugging), que segu-ramente ahorrará tiempo a los desa-rrolladores. XMLSpy revisa que los documentos estén bien formados y valida su contenido contra el DTD o schema correspondiente. En los am-bientes de depuración para XSLT y XQuery es posible definir puntos de observación (watches), puntos de rompimiento condicionales (breakpo-ints), y ejecutar las operaciones paso a paso (single-stepping).

Web ServicesA quienes trabajan con web services les interesará saber que este producto ofrece un fuerte soporte para SOAP. Además de las capacidades para edi-ción de documentos WSDL y depu-ración de SOAP, XMLSpy incluye un cliente a través del cual podemos pro-bar las respuestas a peticiones. Esto permite desarrollar, probar y depurar

web services con SOAP desde una sola herramienta.

Con todas estas capacidades, es fácil entender porqué XMLSpy ha sido re-conocido en diversas ocasiones como la mejor herramienta para desarrollo con XML. Los invitamos a que conoz-can este producto en alguna de sus diferentes ediciones:

Enterprise.– Funcionalidad completa para desarrollo empresarial.Professional.– Recomendable para proyectos sencillos. No incluye. so-porte a web services, generación de código ni gestión de schemas.Home.– Versión gratuita con funcio-nalidad básica.


Gestión Colaborativa de SchemasUna de las principales características de XML es la capacidad de generar schemas complejos a partir de otros más sencillos utilizando imports e includes. Esto permite extender y reutilizar fácilmente los schemas generados por diferentes áreas o personas en una organización. La edición Enterprise de XMLSpy inclu-ye SchemaAgent, un producto clien-te/servidor que administra el acceso y edición colaborativa de schemas.

Integración con IDEsXMLSpy se puede utilizar en modo independiente (stand-alone), pero también se integra con los IDEs más populares. En el caso de Eclipse y Vi-sual Studio, la integración es comple-ta ya que XMLSpy queda embebido dentro de estos. Después de instalar el producto, se instala un plug-in en el IDE para reemplazar su módulo de-fault de XML por XMLSpy.

Generación de CódigoXMLSpy puede generar automáti-camente clases en Java, C++ y C# a partir de elementos de datos defini-dos en un schema XML. Al modelar los elementos de datos en el Schema Editor, XMLSpy genera los archivos de las clases con los atributos y mé-todos get/set correspondientes.

Comparación de ElementosEs bastante común verse en la nece-sidad de encontrar diferencias entre elementos para conocer qué partes del código han cambiado de un archi-vo a otro. Para resolver esto, XMLSpy provee una utilería que compara y fu-siona documentos. La herramienta los analiza y despliega las diferencias en-tre ambos, permitiendo que el usuario escoja las estructuras que desea in-

En el caso de Eclipse y VisualStudio, la integración es completa ya que XMLSpy queda embebido dentro de estos.

La comparación de elementos permite visualizar las diferencias y decidir qué hacer con ellas

Es un hecho que la mayoría de los sistemas de información actuales se desarrollan utilizando lenguajes orientados a objetos. Dentro de este paradigma, los objetos en cierta manera representan objetos del mun-do real. Por ejemplo, imaginemos una agenda que contiene una lista de personas con cero o más direcciones y números telefónicos. En el mundo de objetos, éstos se representarían como objetos “persona”, con atribu-tos correspondientes a la información relevante a cada persona, como su nombre, una lista de teléfonos de diferentes tipos (casa, oficina, móvil) y otra lista de direcciones.

PR

OD

UC

TO

S

O.bject R.elational M.appingBrindando Persistencia a los ObjetosPor Pedro Galván

El problema llega cuando debe-mos almacenar esta infor-mación en algún medio per-

manente. Desde la perspectiva de un desarrollador, una posible solución sería utilizar un almacenamiento de objetos persistentes, en el que se al-macenan objetos que pueden ser en-contrados posteriormente. La mayoría de los lenguajes de objetos proveen algún mecanismo para lograr esto. Por ejemplo, en Java se pueden “serializar” los objetos y así almacenarlos en dis-co. Esto puede ser aceptable en la pro-gramación de sistemas de bajo nivel. Sin embargo, no sería útil en aplicacio-nes empresariales donde los usuarios deben poder acceder los datos de dife-rentes maneras y con diferentes clien-tes para obtener la información que requieran (reportes, análisis de datos, etc.). Adicionalmente, en aplicaciones empresariales el almacenamiento de información debe tener un alto des-empeño y confiabilidad.

Como sabemos, la solución a todas estas necesidades de almacena-miento ya existe, y son las bases de datos. La solución que podría pare-cer ideal en principio sería utilizar bases de datos orientadas a objetos. Sin embargo, éstas no han logrado penetrar el mercado en general, por lo que en la mayoría de las ocasiones nos vemos obligados a recurrir a ba-ses de datos relacionales (RDBMS). Como sabemos, casi todos los ma-nejadores de bases de datos relacio-nales son previos al paradigma de objetos y el soporte que tienen hacia éste es bastante pobre.

Diferencias EntreParadigmasEl mapeo entre objetos y relaciones no es algo trivial, ya que existen diferencias fundamentales entre estos modelos. La teoría relacional se centra en los datos, mientras que la de objetos se enfoca en el comportamiento. Estos son algunos de los aspectos en que difieren:• Los objetos tienen un claro sentido de identidad y de propiedad de sus atribu-tos. En cambio, en una base de datos es necesario construir queries utilizando llaves para relacionar y darle sentido a los datos que contienen las tablas.• Dado que la información de un objeto típicamente abarca varias tablas, se re-quiere de varias sentencias o del uso de JOINS para obtener toda la información de un objeto.• Las bases de datos realizan búsque-das a través de índices, pero no pueden ver objetos residentes en memoria.• Los tipos de datos manejados por am-bos modelos son diferentes.• Las relaciones soportados por ambos modelos son diferentes. Por ejemplo, los RDBMS no soportan directamente la herencia.• Los RDBMS proveen mecanismos para aislar y evitar cambios a ciertos registros (locking).

Object-Relational MappingDe todo esto surge la necesidad de uti-lizar algún mecanismo para integrar la información contenida en nuestros ob-jetos con los datos almacenados en el RDBMS. Esto típicamente se logra a tra-vés de una capa de traducción objeto-re-lacional. Tal estrategia es conocida como Object-Relational Mapping (ORM).

Dependiendo de que tanto se apoyan en ORM, podemos clasificar las aplica-ciones en las siguientes categorías:Puramente relacional - Todo el siste-ma, incluyendo la interfaz de usuario, está diseñado en base al modelo rela-cional, utilizando statements de SQL dentro de los programas. Los queries se pueden ajustar directamente, pero a costa de poca portabilidad y dificultad en el mantenimiento. Las aplicaciones en esta categoría típicamente utilizan mucho los stored procedures, llevando la mayoría del trabajo de procesamien-to hacia la capa de datos.Mapeo de objetos sencillo - Las entida-des se representan como clases que se mapean manualmente a las tablas en la base de datos. Las llamadas al RDBMS se separan de la lógica de negocio a través de algún patrón de diseño como el DAO (Data Access Object). Esta es-trategia es muy común y tiene éxito en aplicaciones con entidades sencillas.Mapeo de objetos medio - La aplica-ción se diseña en base a un modelo de objetos. Las sentencias SQL se generan en tiempo de ejecución a través un fra-mework o generadores de código. Las asociaciones entre objetos son mane-jadas por el mecanismo de persistencia y es posible refinar el acceso a datos a través de expresiones en un lenguaje orientado a objetos. Típicamente se maneja un cache de objetos en la capa de persistencia. La mayoría de los pro-ductos ORM y soluciones desarrolladas internamente (in-house) soportan este nivel de funcionalidad. Este nivel es adecuado para aplicaciones de com-plejidad media, donde es importante la portabilidad hacia diferentes RDBMS.


HERRAMIENTAS

Mapeo de objetos completo - Se soporta modelado de objetos complejo con composición, herencia, polimorfismo, etc. La capa de persistencia implementa persistencia transparente, esto es la capacidad de manipular los datos almacenados en el RDBMS directamente a tra-vés de objetos, sin tener que implementar alguna interfaz especial o heredar una clase. Se utilizan técnicas eficientes para la obtención y cacheo de información, las cuales son trans-parentes hacia la aplicación. Este nivel de funcionalidad es muy difícil de lograr a través de una solución in-house, ya que requiere meses o tal vez años de desarrollo.

Diferentes TécnicasEn el mercado existe una gran variedad de herramientas y productos para ORM. Conozcamos algunas de las técnicas más utilizadas por estas herramientas:

Mapeo directo sin identidad – El desarrollador crea clases con atributos de cuyo nombre se derivan las columnas de las tablas en la base de datos (o viceversa). Las herramientas examinan estas clases y generan los queries correspondientes. No se mantiene identidad basada en la llave primaria. Esto significa que es posible que en memoria existan dos objetos diferentes que corresponden a la misma hilera de una tabla. Si ambos objetos son actuali-zados, entonces se perderán los cambios en alguno de ellos. Esto implica que la lógica de la aplicación esté al pendiente de que esto no suceda.

Mapeo directo con identidad – Similar al anterior, pero se mantiene un índice (típicamente un hash table) de todos los registros residentes en memoria. De esta manera se asegura que no puedan existir dos objetos que correspondan a la misma hilera de una tabla. El inconve-niente de esta estrategia es que la capa ORM debe responsabilizarse de administrar el ciclo de vida de los objetos, ya que la lógica de la aplicación no tendrá forma de saber cuando se deba eliminar un objeto compartido. Esto puede presentar complicaciones dependiendo del lenguaje de programación utilizado y los mecanismos que provea para administrar el ciclo de vida de los objetos.

EJB CMP - En el caso de J2EE, se puede utilizar la persistencia administrada por el conte-nedor o CMP. El desarrollador define clases abstractas para cada atributo de los objetos, y se generan métodos get/set que encapsulan el acceso a las variables. Se utiliza EJB QL, un lenguaje similar a SQL, para definir statements para acceder información.

JDO – JDO (Java Data Objects) es un API creado por Sun para abstraer la persistencia en los objetos. Los desarrolladores se apoyan en este API para lograr que la información de su modelo de dominio se almacene en la base de datos. A diferencia de CMP, JDO está diseñado para funcionar con cualquier tipo de objetos Java, no solamente EJBs. JDO ha tenido un gran éxito y se espera que la versión 3 de EJB se base en JDO.

Generación a partir de XML – Consiste en generar código a partir de definiciones escritas en XML. Es recomendable que el código generado no sea modificado posteriormente.

Referencias:Autores varios, “Object Relational Mapping Articles” www.service-architecture.com/object-relational-mapping/articlesBerglas, Anthony. “Object Relational Mapping Tools”www.uq.net.au/~zzabergl/simpleorm/ORMTools.html

HerramientasExiste una gran cantidad de productos para ORM. Entre los más populares estan:

Hibernate (Java, Open Source) www.hibernate.orgCocobase (Java, Comercial) www.thoughtinc.comNEO (.NET, Open Source) neo.codehaus.orgNHibernate (.NET, Open Source)sourceforge.net/projects/nhibernate

ORM .NET (.NET, Open Source)sourceforge.net/projects/orm-netToplink (Java, Comercial)www.oracle.com/technology/products/ias/toplink

ObjectSpaces es un ORM de Microsoft que inicialmente se esperaba en conjunto con Visual Studio Team System. Sin embargo, recientemente se anunció que este no serå lanzado hasta que WinFS esté disponible.

www.softwareguru.com.mx

HERRAMIENTAS


El software, en tanto que es un bien, está sujeto a las reglas del derecho civil y, en tanto que es intangible, sujeto a las

reglas de propiedad intelectual. No obstante, la actividad humana de desarrollarlo y otras relacionadas, como lo son su comercialización, implementación, integración o mantenimiento, están o pueden estar sujetas a una multiplici-dad de reglas más, como lo son las del derecho mercantil, fiscal, de la propiedad industrial y de la protección al consumidor. Asimismo, en tan-to más amplia y compleja sea una organización dedicada al desarrollo de software, la aplicación de reglas adicionales se hace evidente, tales como las del derecho laboral y societario.

Protección LegalLa protección legal que se le otorga al soft-ware varia significativamente de país a país, dependiendo de cómo se perciba, el régimen legal aplicable, e incluso su historia y cultura económica. Por ejemplo, en Asia el desarrollo de software se percibe como una industria manufacturera, en donde los desarrolladores

son fabricantes y el software un bien de pro-ducción que juega un rol dentro de los pro-cesos de otras industrias. En Norteamérica se percibe una industria, como una actividad creativa, pero con fines meramente económi-cos. De ahí que la protección otorgada por el Copyright se limite precisamente al derecho de prohibir o autorizar su reproducción.

En México, al igual que en Europa, donde nuestro régimen legal tiene como base al lla-mado Civil Law o Derecho Romano-Germáni-co, el desarrollo de software es considerado como un arte y los programas en sí mismos son obras que merecen ser protegidas por el llamado Droit d’Auteur o Derecho de Autor, el cual no se limita únicamente al derecho de prohibir o autorizar su reproducción, sino que otorga al creador de una obra la protección al vínculo que lo une con su creación intelectual, tanto desde una perspectiva personal como real, toda vez que protege su autoría y sus de-rechos de propiedad sobre el mismo. Es por ello que nuestra legislación protege tanto los

derechos patrimoniales como morales de los desarrolladores de software.

El derecho patrimonial o económico es el que el autor tiene para explotar de forma exclusi-va su software o de permitir a otros explotarlo (copyright). Es decir, de autorizar o prohibir su reproducción, publicación o transmisión en cualquier medio (papel, CD, Internet). El autor de un software puede transmitir este derecho sobre su obra sin limitación alguna. Por su par-te, el derecho moral es el derecho que el autor tiene de decidir sobre si ha de divulgar o no su obra y la forma de hacerlo, así como de exigir su reconocimiento como autor de la misma, de modificarla y de oponerse a cualquier modifica-ción, deformación o mutilación. En este caso, este derecho es irrenunciable e intransferible.

Cabe señalar que la protección legal es inme-diata, sin necesidad de registro alguno, desde el momento en que la obra se fija en un soporte material, por ejemplo, en un papel o en un ar-chivo electrónico. El registro de un programa de

Kendra Medina Chávez es abogada del Área Legal Corporativa, en la especialidad de Telecomunicaciones & Tecnologías de Información de PricewaterhouseCoopers, S.C. Estudió Derecho en el Instituto Tecnológico Autónomo de México, cuenta con un postgrado de Telecomunicaciones por la misma institución y una Maestría en e-Law por la Universidad de Melbourne. Es miembro del Consejo Editorial de The Sci-Tech Lawyer, revista especializada de la American Bar Association y ha impartido clases de licenciatura, de maestría y conferencias sobre Derecho de Tecnologías de Información y Telecomunicaciones en el Instituto Tecnológico de Estudios Superiores de Monterrey (Campus Monterrey), la Universidad de Monterrey y el Instituto de Investigaciones Jurídicas de la Universidad Nacional Autónoma de México.

Desarrollode Software:

Consideraciones legalesPor Kendra Medina

Al hablar sobre desarrollo de software, comúnmente nos viene a la mente la creación de programas de cómputo que sirven para solucionar problemas específicos, mediante la conjunción de algoritmos bajo determinados lenguajes de programación. Para unos es un misterio, para otros es un arte, mientras que para algunos cuantos es cosa sencilla y de todos los días. Para nosotros, los abogados, hablar sobre desarrollo de software es hablar sobre una convergencia de múltiples derechos y obligaciones, tanto legales como contractuales.

derechos y secretos industriales, mediante sólidos contratos laborales y cláusulas de confidencialidad.

No hay que olvidar que la protección legal otorgada por la legislación en materia de de-rechos de autor se restringe a la protección de la obra tal cual es fijada sobre el soporte material (código fuente y código objeto), no a la idea. Por lo que debe también considerarse la protección adicional de elementos no visi-bles, tales como la estructura, organización, secuencia, interfaces (el llamado look & feel de un programa), así como las bases de datos y contenidos relacionados. De esta forma, en la manera de lo posible pueden tenerse ma-neras efectivas de combatir prácticas de clean room* de posibles competidores.

Finalmente, las nuevas formas de comer-cialización y distribución merecen una aten-ción legal especial. Por su naturaleza, la distribución y comercialización de software a través de medios electrónicos, como In-ternet, no sólo es conveniente, sino eficien-te. En estos casos, no deben considerarse únicamente los términos y condiciones de la licencia de uso de los programas de cóm-puto así distribuidos, sino la forma y sus-tancia de la contratación electrónica para fines de validez y como medio de prueba. Asimismo, hay que recordar que los usua-rios finales son consumidores y están am-parados bajo una regulación especial y fa-vorable en cuanto a contratación de bienes y servicios se refiere.

ConclusiónEs claro que la industria del software se co-noce como tal porque la evolución natural del desarrollo de la tecnología la ha llevado a ser no un arte, sino una industria gene-radora de inversión y de empleos. Por ello, es importante que los empresarios tengan en mente que la protección legal más im-portante de su principal activo no proviene exclusivamente de un registro ante el Ins-tituto de Derechos de Autor y que, para el sano desarrollo de su empresa, es necesa-rio considerar una diversidad de normas jurídicas, por lo que no sólo es aconsejable, sino necesario, allegarse de la asesoría le-gal adecuada oportunamente.

cómputo ante el Instituto Nacional del Derecho de Autor es meramente declarativo, más no constitutivo de derechos, por lo que su utilidad principal es como medio de prueba.

Consideraciones JurídicasSiendo el desarrollo de software una actividad que nuestros legisladores optaron por regular como un arte, no como una ciencia y mucho me-nos como una industria, los empresarios mexi-canos que buscan expandir el desarrollo de soft-ware bajo un esquema de negocios deben tomar en cuenta no sólo este enfoque regulatorio, sino muchas otras consideraciones jurídicas más.

Antes de constituirse como entidad legal, el em-presario mexicano debe definir el core business de su empresa y su mercado. Decidir desarrollar software a la medida o software empaquetado, o prestar servicios de integración o implementación de software, tiene una incidencia directa en el tipo legal más adecuado bajo el cual debe constituir su empresa. No pocas veces ha sucedido que por esta falta de enfoque se elija, por ejemplo, cons-tituir una sociedad anónima en vez de una socie-dad civil, sujetándose así, sin ninguna necesidad, a un régimen fiscal mucho más estricto.

Asimismo, por muy pequeña que parezca su empresa en un inicio, la integración de la definición del core business con la visión de crecimiento que se tenga a mediano o largo plazo, deben ir de la mano con el estableci-miento del objeto social de la empresa y la estructura corporativa idónea. En el mejor de los casos, una falta de previsión en cualquie-ra de estos sentidos puede implicar gastos innecesarios en modificaciones a los esta-tutos de su empresa o en su representación legal; pero en el peor de ellos, podría impedir la inclusión de nuevos inversionistas en el momento y lugar adecuados, dejando pasar así valiosas oportunidades de crecimiento.

Otra consideración de vital importancia es la aplicabilidad de legislación especial, como es el caso de la laboral. Hay que recordar que esta regulación es de orden público y en todo caso, en situación de conflicto, la carga de la prueba la tiene el empleador. Por lo anterior, es muy importante que queden bien documentadas to-das las obligaciones que los empleados de una empresa dedicada al desarrollo de software tienen, tanto los desarrolladores, como el per-sonal administrativo. Hay que tener en mente que la protección mínima que la ley otorga a los desarrolladores de software como empresarios es la presunción de que, salvo pacto en con-trario, los derechos patrimoniales del software desarrollado por el empleado —dentro de las funciones de su cargo y bajo instrucciones del empleador únicamente—, pertenecen a este último. Por lo anterior, esta protección mínima debe complementarse con disposiciones con-tractuales explícitas en materia de renuncia de


*Las tecnicas de “clean room” se utilizan para crear programas muy similares a los de los competidores, sin violar algún derecho de propiedad intelectual o conve-nio de confidencialidad. El proceso es el siguiente:

• Se aísla a uno o más programadores y se les dan unos requerimientos a alcanzar.• Se les da información que no es confidencial (cómo funcionan algunas herramientas del programa, qué tan amigable debe ser, etc.).• Se cuida mucho que esos programadores no tengan acceso al programa original que se pretende “copiar” e incluso se registra todo el proceso para que pueda com-probarse que en ningún momento se trató de ingeniería inversa o copia literal del programa.

ENTREVISTA

¿Sientes que el camino para las mujeres es más difícil?Reconozco que es complicado conforme van subiendo. Cuando trabajas en una oficina con-vencional, haces un compromiso de estar de 9 a 6, y ahí termina. Pero conforme creces pro-fesionalmente, ya no se traduce en un horario sino en compromiso. A la mejor vas a poder estar a las 9 en tu casa, pero no vas a poder estar el día de los premios del colegio. En las mujeres esto puede provocar que te cuestio-nes si ese compromiso no se contrapone con tu compromiso de mamá y de esposa. Debes tener un driver muy fuerte para decir “lo hago, y hay un sentido para hacerlo”, y traducirlo en términos de tus hijos, porque no puede ser meramente un desarrollo que te alimente a ti, sino un desarrollo que se traduzca en retos para la familia. Además, cuando encuentras estas respuestas, se lo logras transmitir a tus hijos para que ellos lo entiendan.

¿Qué tan difícil es crecer profesionalmente en esta industria?Yo creo que más bien depende de la empresa. Si tú te gradúas de esta carrera y te metes al área de sistemas de una empresa tradicional, va a ser difícil poder crecer. En cambio, si te

metes a una empresa dedicada a TI, eso te da muchas opciones de crecimiento. Creo que las oportunidades de crecimiento van más de la mano de la empresa que de la industria.

Cuéntanos sobre Softtek, ¿cuál es su alcance y presencia actual?Actualmente Softtek tiene cerca de 2,700 em-pleados y presencia en diez países. Somos la empresa privada de TI más grande con pre-sencia regional en Latinoamérica.

¿Qué implica el hecho de ser unaempresa privada?Ser una empresa privada tiene la connota-cion positiva de decir “es mío y lo voy a hacer y no me voy a poner límites”, pero también tiene limitaciones. No tener atrás un socio capitalista hace que al momento de llegar ciertas circunstancias, atravieses dificulta-des que otras empresas no. Es poco común que una empresa llegue a este tamaño sin un capital detrás. Pero yo estoy segura que hoy no tendríamos el alcance que tenemos si tuviéramos un socio capitalista. El dinero nos hubiera ayudado mucho para hacer frente a problemas financieros, pero no hubiéramos llegado a esto.

¿Cuál es tu mayor orgullo en Softtek?A mi todas las épocas de Softtek me han dado orgullo, pero donde más orgullosa me he sen-tido es donde hemos podido demostrar que nos sabemos levantar. Así como Softtek es muy conocido, también es bien sabido que tuvimos años muy difíciles. 1999 y 2000 fue-ron años muy duros, y el impacto de ellos se reflejó en 2001 y 2002. Que la empresa sea nuestra ha demostrado que en las crisis Sof-ttek sabe salir adelante. El proceso fue muy duro, nos ayudó mucha gente y afectamos a algunos otros ya que no teníamos atrás un socio capitalista que nos respaldara. Otras empresas cerraron sus puertas porque el ne-gocio ya no daba y su socio capitalista ya no estaba dispuesto a perder dinero. En nuestro caso eso no era una posibilidad. Yo creo que una empresa que nunca ha vivido una crisis no puede sentirse del todo orgullosa.

¿Cuáles son las razones para penetrar el mercado norteamericano de software?Nuestro principal motivo fue para soportar las crisis económicas que se daban cada sexenio en México. No te voy a negar que otro factor importante fue el simple gusto de decir “sí podemos”. Un beneficio que inicialmen-

Blanca TreviÑo

CEO de Softtek


La historia de Blanca Treviño está llena de retos. Conozcamos un poco más sobre quién es ella, la problemática que ha enfrentado y su opinión respecto a la industria de software.

Software Guru.- ¿Quien es Blanca Treviño?Blanca Treviño.- Soy regia, puedes empezar por ahí. Soy or-gullosa madre de dos niñas, una adolescente y otra de once años. Casada, como una señora casi normal.

¿Qué te motiva?Para mí el reto es una constante, y es algo que viene de fa-milia. Mi mamá estudió una carrera ya teniendo seis hijos. Mi papá nunca me permitió ponerme límites. Cuando es-cogí mi carrera, estaba interesada en estudiar sistemas, pero me dio miedo y me apunté en mercadotecnia. Él me dijo que no me podía salir, que aceptaba que pudiera te-ner una hija tonta pero no miedosa. Así que para mí el

reto siempre ha sido algo muy fuerte y continuo. No digo que deba ser profesional, sino que debes sentirte conti-nuamente en exigencia de mejorar, de aprender. Mis dos niñas también son un gran motor para mí. Cuando tienes hijos se te vuelve un compromiso el transmitirles esa bús-queda constante de retos.

Eres una mujer que dirige una empresa de 100 millones de dólares, ¿eso pasa por tu cabeza o no le das importancia?El hecho de que sea una mujer sí me hace muy consciente de tener el privilegio de estar en una empresa que me permita de-sarrollarme y estar aquí. Lo reconozco como un privilegio, pero no lo subo mucho a la cabeza, no en el contexto de limitarme.

te no contemplamos, es todo lo que hemos aprendido y nos hemos desarrollado. El grado de exigencia del mercado norteamericano te obliga a elevar tu nivel de calidad.

¿Consideras que el interés de las empresas nacionales por incursionar en el mercado norteamericano provoque que se descuide el mercado local?No lo veo así. Al contrario, el que las empre-sas busquen internacionalizarse hace que se desarrollen, mejorando su oferta y calidad, y eso beneficia al mercado interno.

¿Cuál es la principal dificultad que encuen-tran para vender en Estados Unidos?Nuestro principal reto es lograr que los clien-tes vean a México como un jugador en esta industria. Los clientes primero escogen el país al que van a enviar trabajo, y ya después escogen proveedores dentro de ese país. El mercado le apuesta a un país, porque con el país vienen una serie de factores como dis-tancia, horario, estabilidad, etc. Cuando se hacen las evaluaciones, el principal punto dé-bil de México es la poca cantidad de provee-dores. Softtek puede ser una buena opción, pero una empresa no hace una industria.

¿Qué opinas sobre la industria mexicana de software en términos de colaboración?Afortunadamente cada vez somos más los que nos damos cuenta de que para tener éxi-to a largo plazo, debemos colaborar. En nues-tro caso, tenemos un programa de apoyo a PyMEs desarrolladoras de software, en el que las integramos en proyectos y las capacita-mos para que se desarrollen. Al principio las empresas desconfían y piensan “algo ha de traer Softtek”, pero lo que pasa es que nece-sitamos desarrollar la industria nacional para poder vender en el extranjero. En sí, creo que la colaboración en esta industria ha mejorado bastante en los últimos años. Las asociacio-nes juegan un papel importante, y el gobierno también ha ido propiciando un ambiente ade-cuado a través de ProSoft.

¿Crees que en México se deberían dar apoyos gubernamentales a esta industria? Sí. Creo que lo más importante son apoyos financieros para sustentar el flujo de efecti-vo. Lo que pasa es que en esta industria, tú comienzas un proyecto y al mes de estar tra-bajando empiezas a facturar, y luego de ahí pasan sesenta días para que recibas tu pago. Entonces necesitas ver de dónde sacas dine-

ro para pagarle a la gente durante esas seis quincenas. Para las empresas de esta indus-tria es difícil obtener financiamiento por me-dios tradicionales, ya que no contamos con muchos activos que nos respalden, sino que al ser una industria intensiva en conocimiento los principales activos son intangibles.

El siguiente rubro tiene que ver con la promo-ción del país. Con esto me refiero a posicio-nar a México como un jugador en la industria mundial. Adicionalmente hay otras cosas que se pueden lograr si se tiene más en mente a esta industria. Por ejemplo, el año pasado Aeroméxico cerró un trato para comprar mu-chísimos aviones a Boeing. ¿No crees que se hubiera podido acordar algo de reciprocidad para que enviaran algo de trabajo a México?

¿Qué mensaje le dejas a nuestros lectores?Están en un sector con enormes oportunida-des, lo cual implica un gran reto y compromi-so. No necesitan irse al extranjero a buscar trabajos de alto nivel. Desde aquí pueden atraer oportunidades de desarrollo no sólo para ustedes sino para muchos otros. Todo esto no se da por sí solo, hay que cultivarlo y debemos hacerle frente a este reto.

“Nuestro principal reto es lograr que los clientes vean a

México como un jugador en esta industria”.


20 MAR-ABR 2005 www.softwareguru.com.mx 21MAR-ABR 2005

EN PORTADA

Un Nuevo ParadigmaPor Pedro Galván

Centros deDesarrollo

de SoftwareEl desarrollo de software actualmente es una actividad lenta, cara y propensa a errores que generan defectos y problemas de usabilidad, desempeño y seguridad. Según las estadísticas, menos de la tercera parte de los proyectos de software son exitosos en términos de alcance, calidad, tiempo y presupuesto. A lo largo de los años se han dado algunas mejoras en productividad, principalmente a través de la mejora de los lenguajes y herramientas, pero aún así seguimos desarrollando software casi de la misma manera que hace una década. Nuestros métodos y prácticas realmente no han cambiado, como tampoco lo han hecho los costos y riesgos.

La demanda global de software ha aumentado constante-mente en los últimos diez años, y aumentará a un ritmo mucho mayor durante la próxima década, dirigida por las fuerzas de la nueva economía, el creciente rol del software en la sociedad moderna y nuevas plataformas como dispositivos móviles y dispositivos inteligentes para el hogar.

Esto nos presenta un problema de capacidad para satisfacer la demanda. No somos la primera industria en enfrentar tal problema, otras ya lo han superado. Lo lograron al evolu-cionar de la artesanía, donde los productos se hacen desde cero por individuos o pequeños equipos, hacia la manu-factura, donde un amplio rango de variantes se ensambla rápidamente de acuerdo a componentes reutilizables crea-dos por diferentes proveedores y a través de máquinas se automatizan las tareas repetitivas. Estas industrias estanda-rizaron sus procesos, diseños y empacado, utilizando líneas de producción para facilitar la reutilización, y cadenas de suministro para distribuir el costo y riesgo. Esto es a lo que llamamos industrialización.

¿Se Puede Industrializar el Desarrollo de Software?Este ha sido un tema de amplia discusión desde hace tiempo. ¿Pueden aplicarse a la industria de software los patrones de industrialización comunes? ¿Somos una industria especial o diferente a las demás?

La clave para aclarar esta discusión es entender las diferencias entre las economías de escala y de alcance. La reutilización sistemática puede generar ambas. Estos dos efectos son bien conocidos en otras industrias; aunque reducen el tiempo y costo, y mejoran la calidad de los productos, difieren en la manera en la que producen estos beneficios.

• Las economías de escala surgen cuando se producen varias instancias idénticas o copias de un mismo producto. Se crea un diseño, junto con sus instancias iniciales (prototipos) a través de un proceso intensivo en recursos, llamado desa-rrollo, que es llevado a cabo por ingenieros. Posteriormente se crean muchas instancias adicionales, llamadas copias, a través de un proceso llamado producción, que es realizado por máquinas o mano de obra barata.

• Las economías de alcance surgen cuando varios diseños si-milares pero distintos se producen de manera colectiva. En la manufactura de automóviles, por ejemplo, se generan varios modelos de automóvil con ciertas similitudes al combinar di-seños existentes de subcomponentes como el chasis, interiores, transmisión, etc. Las variaciones entre modelos se generan por diferencias entre algunas características, como el motor, por ejemplo. Así que las mismas prácticas, procesos, herramientas y materiales se utilizan para diseñar distintos productos.

Ahora podemos entender los problemas en la comparación de otras industrias con la de software. No es posible generar economías de escala en el desarrollo de ningún producto, ya sea físico o virtual. Sin embargo, podemos buscar lograr economías de alcance a través de la industrialización del de-sarrollo de software.

Centros de Desarrollo de SoftwareCon el objetivo de aumentar la productividad, disminuir los costos y elevar la calidad de los productos y servicios ofre-cidos a los clientes, recientemente se ha hecho popular el modelo de operación de “centros de desarrollo de software”. Lo que busca este modelo es generar economías de alcance en el desarrollo y mantenimiento de software.

A continuación les presentamos tres ejemplos de empresas pioneras en México con el modelo de centro de desarrollo de software (CDS).

20 MAR-ABR 2005 www.softwareguru.com.mx 21MAR-ABR 2005

Centros deDesarrollo

de Software

¿Y las fábricas de software?El término fábricas de software se hizo popular hace unos años, cuan-do se inició el esfuerzo de industrializar el desarrollo de software para bajar costos y mejorar calidad. Sin embargo, en la mayoría de los casos, los proveedores que se etiquetaban como fábricas se limitaban a desarrollar software de manera tradicional, pero en sus propias insta-laciones en lugar de las del cliente. Este modelo puede llegar a brindar beneficios de costo, pero son marginales. Lo que diferencía un centro de desarrollo del concepto manejado como “fábrica de software”, es la búsqueda de economías de alcance.

Vale la pena notar que Microsoft también está usando el término fábri-cas de software para identificar su estrategia de desarrollo de software empresarial. Ver “Tendencias de Construcción” en la página 27.

La clave para aclarar esta discusión es entender la diferencia entre economías

de escala y economías de alcance.


EspecializaciónLos servicios de Softtek están divididos en tres grandes rubros:• Servicios Relativos a Aplicaciones, como desarrollo a la medi-da, mantenimiento de sistemas existentes, help desk y testing.• Servicios de Soporte a Infraestructura, como administra-ción de redes, servidores y seguridad.• Outsourcing de Procesos de Negocio, que gira alrededor de la mejora y digitalización de procesos de negocio.

Modelo de EntregaLos servicios de Centro de Desarrollo de Softtek están orientados primordialmente a atender las necesidades de empresas globales, mediante el modelo Near Shore.

Modelo de CalidadLos tres elementos de calidad de Softtek (CMM Nivel 5, Six Sigma y Digitalización) interactúan de manera tal que permiten entregar al cliente elementos de control, confiabi-lidad, predictibilidad y mejora continua. Las organizaciones CMM Nivel 5 son altamente maduras, debido a que siste-máticamente utilizan procesos cuantificables y controlables,

SofttekEN PORTADA

Con más de 2,500 personas en 10 países, Softtek es la empresa privada de servicios de TI más grande en Latinoamérica. La firma ha estado en operación por más de 20 años y da servicio a clientes corporativos en todos los mercados en los que opera.Softtek se ha convertido en una fuerte alternativa a los servicios offshore en el mercado de Estados Unidos, segmento dominado por empresas de la India. Al explotar el concepto Near Shore, Softtek es el líder de este seg-mento en América. Recientemente Softtek concluyó la integración de GE Ddemesis, empresa adquirida a General Electric a finales de 2003, realizó la apertura de un Centro de Entrega de Servicios en Azcapotzal-co, D.F., con lo cual suma ya tres centros de desarrollo en México (además de Monterrey y Aguascalientes), dos centros de desarrollo en Brasil y uno más en Espa-ña, destinado a atender el mercado europeo.

analizando los resultados para mejorar continuamente. El re-sultado es software de muy alta calidad, desarrollado en tiempo y costo. A nivel mundial, menos de 10% de las organizaciones evaluadas han alcanzado el nivel 5. La cultura Six Sigma, que se encuentra incrustada en Softtek, consiste en un método de administración orientado al cliente y sustentado en datos que permite lograr excelencia en procesos de negocio. La digitali-zación de los procesos se logra al utilizar la suite de productos de IT Governance Center de Mercury, lo cual permite tener consistencia en todos los procesos de la organización.

Principales RetosLa sola idea de una empresa mexicana de servicios de TI proporcionando servicios a empresas Fortune 100 en Es-tados Unidos, es una novedad. Softtek ha hecho frente exi-tosamente a las preocupaciones de sus clientes con respecto a la disponibilidad de recursos calificados en México, las barreras idiomáticas, entregas a tiempo y calidad. Los prin-cipales retos que Softtek enfrenta son:• Disponibilidad de profesionales con dominio del idioma inglés y el grado de especialización que se requiere en un ambiente globalizado.• Carencia de más jugadores en México con los niveles re-queridos para competir en un mercado global, ya que esto se ve reflejado en una baja percepción de México como ju-gador en la industria.

Asimismo, Softtek está aprendiendo a aprovechar el hecho de que México es el segundo socio comercial de Estados Unidos, comprando productos y servicios con un valor su-perior a $100 mil millones de dólares al año, lo que repre-senta más de veinte veces lo que adquiere India.

Perspectiva a FuturoAlejandro Camino, alto ejecutivo de Softtek, nos comenta lo siguiente: “Softtek continuará la estrategia de fortaleci-miento de su modelo Near Shore, mediante el robusteci-miento del modelo de calidad, y la apertura de más centros de desarrollo en los polos que proporcionen las condiciones de disponibilidad y fortalecimiento de recursos humanos competitivos a nivel mundial. Asimismo, continuaremos ampliando nuestro portafolio de servicios, principalmen-te en el segmento de outsourcing de Procesos de Negocio, donde vemos la mayor oportunidad de crecimiento. Nues-tro objetivo es continuar el rol de liderazgo de una nueva generación de profesionistas mexicanos altamente competi-tivos y con mentalidad global.”

23MAR-ABR 2005www.softwareguru.com.mx

certum es una empresa mexicana con más de dieciocho años de experiencia en desarrollo de software a la medida. Nació en la ciudad de Puebla en 1986 bajo el nombre de Servicios en Informática y Desarrollo de México. En 1988 cambió su domicilio a la ciudad de México, ya que sus clientes se encontraban en esta ciudad. En 1994 comienza a participar en un proyecto de la ISO llamado SPICE (Software Process Improvement and Capability dEtermination). El Director General, Arnoldo Díaz, fue nombrado ISO Project Editor y Miembro del Consejo de Administración del consorcio. Asimismo, la Herramienta de Evaluación de Procesos de Software desarrollada por esta empresa fue denominada Official SPICE As-sessment Instrument. Esta iniciativa a través del tiempo dio como resultado la creación del estándar internacional para la evaluación de procesos de software ISO/IEC 15504. En 1997 lanza la marca certum, que significa “certeza” en latín. El nombre obedece a la intención de atacar uno de los problema fundamentales de la industria del desarrollo de software: la incertidumbre. Incertidumbre alrededor de lo que llaman el trinomio: calidad, tiempo de entrega y costo.

certum

Especializacióncertum se ha enfocado desde su fundación al desarrollo de soft-ware a la medida, lo que los ha llevado a trabajar en diversos secto-res tanto en el mercado nacional como en el extranjero. La forma de trabajo es a través de proyectos, los cuales son cuidadosamente seleccionados, ya que siempre buscan se encuentren alineados a la estrategia de sus clientes expresada en su Red de Servicios. Sus soluciones son independientes de la plataforma, y cuentan con experiencia en una gran diversidad de tecnologías.

Modelo de trabajoExisten tres dimensiones de componentes estructurales: • Operación - planta física, herramientas de desarrollo y herra-mientas de soporte.• Control - procesos estándar para el desarrollo de los productos.• Desarrollo de Personas - evaluaciones de desempeño, planes de carrera y compensación.

certum ha desarrollado diversas herramientas propietarias para diseño de servicios, repositorio de activos, seguimiento a proyec-tos y administración de incidentes, por mencionar algunas.

La planta física fue diseñada bajo el paradigma de líneas de pro-ducción. A cada cliente se le dedica una línea, organizada siempre a través de proyectos, y trabajando bajo sistemas y herramientas comunes. Esta organización trabaja bajo el concepto de puertas abiertas (no hay privados ni para los Directores), lo que facilita la comunicación y crea un ambiente mucho más integrado.

Modelo de calidadDesde 1993 certum adoptó el paradigma de modelos de capa-cidad de procesos. A lo largo de su historia ha obtenido certi-ficaciones ISO 9001 y una evaluación Bootstrap - equivalente a SW-CMM nivel 3 gracias al estándar ISO 15504, siendo la primera empresa en Latinoamérica en obtenerlo. Su modelo de calidad se basa en métricas de: productividad (puntos de función por persona mes), calidad (defectos por puntos de función), sa-tisfacción de cliente, costos, etc. Esto es un elemento clave para lograr la mejora sostenible de sus procesos y productos.

Retos y Perspectiva a Futurocertum ha tenido una trayectoria complicada y retadora pero muy interesante y enriquecedora, que finalmente los ha posicio-nado con resultados exitosos, y por esta razón piensa continuar en la misma línea. Entre sus retos presentes está superar la lucha cultural alrededor de los procesos y métricas, continuar la bús-queda por mejorar aún más la capacidad de sus procesos, a fin de poder ver esto reflejado en valor superior para sus clientes a través de implementar con éxito los servicios que ofrecen.

Planta física de certum


IBM Centro de Diseño y Desarrollo de Software

EN PORTADA

Una de las mayores concentraciones de ingenieros de software del país se encuentra en el Centro de Diseño y Desarrollo de Software de IBM, el cual tiene más de 950 profesionistas dedicados al diseño, desarrollo y pruebas de software. Este centro tiene oficinas tanto en la ciudad de México como en Guadalajara y desde ellas atiende a múltiples clientes nacionales e internacionales. Esta historia comenzó hace quince años, cuando solamente había ocho personas desarrollando software de bajo nivel en la división de laboratorios de IBM. Los resultados que dieron, así como el aprendizaje de desarrollar software en base a una metodología con gran énfasis en calidad, provocaron que esta operación creciera poco a poco tanto en cantidad como en alcance. Desde hace cinco años operan dentro de la organización de AMS (Application Management Services), que a su vez es parte de la división IBM Global Services, ofreciendo una amplia variedad de servicios de TI.

OfertaLa oferta del centro de desarrollo de IBM es muy amplia. Aquí se diseña, desarrolla y da mantenimiento tanto a software para productos de IBM, como aplicaciones para clientes externos. En-tre los servicios provistos están:• Servicios profesionales especializados • Desarrollo de software a la medida• Integración de aplicaciones• Mantenimiento• Outsourcing de infraestructura, adminis-tración de aplicaciones y soporte técnico• Consultoría en desarrollo de software

Una parte vital de la oferta de valor de IBM es la red mun-dial que tiene a su disposición. Esto le permite conseguir recursos altamente especializados, así como acceso a la base de conocimiento de proyectos de todo el mundo.

Modelo de EntregaEl modelo de entrega realmente es una oferta muy flexible que se adapta a lo que los clientes necesitan. En algunos ca-sos IBM se encarga por completo de los proyectos, mientras que en otros solamente realiza funciones específicas como la coordinación, desarrollo o pruebas. En el caso de servicios como help desk, IBM puede hacerse cargo de todo el mane-jo, o solamente a partir de cierto nivel (por ejemplo, el clien-te maneja el primer nivel de soporte y los niveles posteriores son realizados por IBM).

Modelo de CalidadIBM es reconocida como una empresa pionera en modelos de calidad y procesos, y el Centro de AMS México no es la excepción. Fueron la primera organización en México en alcanzar el nivel 5 de SW-CMM, y en diciembre de 2004 fueron reconocidos con el nivel 5 de CMMi. La mejora con-tinua es parte fundamental de la operación diaria de IBM. Como comenta Carlos Cevallos, Gerente del Centro de De-sarrollo: “lo difícil no es desarrollar software, sino hacerlo con un proceso repetible y mejorarlo continuamente”.

Retos y Perspectiva a FuturoUno de los principales retos de IBM es responder a los re-querimientos de la economía globalizada. Para lograrlo, los centros de desarrollo de IBM en todo el mundo se integran bajo una misma forma de trabajo para ofrecer a sus clientes globales un mismo servicio en cualquier lugar del mundo.

Acerca de AMS LatinoaméricaLa organización de AMS se dedica al desarrollo, mantenimien-to y pruebas de aplicaciones de software, ayudando a com-plementar los múltiples ofrecimientos del área de servicios, enfocada tanto a clientes nacionales como internacionales. En Latinoamérica, AMS cuenta con aproximadamente 3 mil pro-fesionistas de TI trabajando en diferentes áreas de productos, aplicaciones y servicios de Software: 950 localizados en México, 1,200 en Brasil, y el resto en Argentina y la Región Andina. El Centro de AMS en México obtuvo el nivel CMMI 5 el pasado diciembre 2004, Brasil espera obtener el nivel CMMI 5 para el segundo cuarto del 2005, y Argentina y la Región Andina buscan obtener el nivel CMMI 4 durante el 2005.


Venimos de un pasado tormentoso, en donde un país con un apellido primor-dialmente energético y de agricultura, tiene hoy en día una producción de más de 20,000 egresados en carreras rela-cionadas con informática anualmente. Estos profesionistas en conjunto con el gobierno y empresas privadas, hemos trabajado incansablemente en cambiar percepciones a nivel global, mejorar idiomas, capacidades tecnológicas y de infraestructura, y lo más importan-te, definir ofertas que tengan sentido para el mercado. Reportes como los emitidos por Forrester Research en el 2004, donde llaman a México “una fuerte alternativa de solución global en outsourcing” avalan nuestro esfuerzo. Un mercado en crecimiento sostenible a pesar de toda la prensa negativa ge-nerada en el mercado norteamericano, donde por lo menos 30% de las em-presas con algún tipo de programa de outsourcing a nivel mundial continua-rán incrementando en por lo menos dos cifras porcentuales el volumen de trabajo enviado al extranjero.

¿Le apostamos como país a la oferta de Near Shore? Absolutamente. Y no sólo a Near Shore como el modelo pionero de trabajo remoto sino en general a la industria de TI hecho en México. El trabajo de tecnología desarrollado en lo que inicialmente conocimos como fá-bricas de software —hoy centros globa-les de desarrollo—, está evolucionando para poder satisfacer las diferentes ne-cesidades que demanda el mercado con sorprendentes resultados positivos.

Existen tres áreas primordiales asocia-das a los centros globales de desarrollo (CGD) que están cambiando de mane-ra drástica y moldeando este negocio: capital humano, la propuesta de valor y las ofertas.

Capital HumanoEn un mundo global donde ya la de-manda personal y de competitividad sobre los profesionistas es mucho más alta que hace cinco años, algunos de los aspectos críticos que deben de estar enfrentando los egresados hoy de ma-nera inmediata son: segundos idiomas en formas fluidas, foco en procesos de negocio, experiencia vertical por in-dustria, dominio tecnológico, visión de negocio, habilidades de negocia-ción, colaboración en equipo, trabajo remoto en tiempo real y comunicación en un mundo global, así como enten-dimiento de las diferencias culturales y su impacto en los negocios; esto por mencionar algunos.

El apoyo de las instituciones educativas es crítico para satisfacer la masa crítica demandada y hoy en día los centros de desarrollo debemos de trabajar pro-ac-tivamente en la alineación de los pro-gramas académicos con las necesidades del mercado, ya que la evolución tan vertiginosa de las soluciones tecnológi-cas hace que un programa tradicional de licenciatura ya no sea suficiente. La capacidad de proveer recursos a la misma velocidad que la India —la po-tencia mundial en offshore— puede “hacer o deshacer” un CGD.

Propuesta de ValorLa propuesta de valor es el mensaje más importante que un centro global de desarrollo puede llevar al mercado; es la oportunidad del proveedor de transformar sus ventajas y diferencia-dores a una expresión clara y cuantifi-cable; en valor para el cliente. ¿Cuál es nuestra propuesta de valor? ¿En qué so-mos únicos?, ¿Cómo proporcionamos valor a los clientes de nuestros clientes? ¿Cuál es nuestra práctica que más valor deriva a nuestros clientes en ahorro, satisfacción y optimización? Aspectos como riesgo, comunicación efectiva, costo, productividad, medidos en base a modelos estadísticos de Six Sigma, son hoy en día el mínimo estándar re-querido, tomado de la mano con mo-delos de CMM/CMMI, entre otros.

¿Qué tan fuerte y sostenible es nuestra propuesta de valor? Gigantes como Ge-neral Electric e IBM, quienes cuentan con sus propios centros de desarrollo cautivos en la India, y pioneros en las tendencias y modelos operativos globa-les de offshore, determinan el compor-tamiento del resto de los proveedores y por lo tanto obligan a nuestras pro-puestas de valor a modificarse y evo-lucionar rápidamente para responder a los cambios. Esto exige una estructura organizacional de CGD muy delgada donde podemos ver relaciones de staff a operación de 1 a 6 ó 1 a 7. En gene-ral, operaciones orientadas a procesos y muy agresivas en sus niveles de produc-tividad, para poder alinear estrategias cada año a bajo costo.

La lucha de las empresas de tecnología de información en México por exportar sus servicios y productos al mercado mundial y en particular a los Estados Unidos, no es un tema reciente pero definitivamente constante y en crecimiento. El proceso no ha sido sencillo para los que he-mos participado en esta transformación, pero definitivamente a los que hoy competimos con la India, Filipinas, Europa del Este, por mencionar algunos, nos es importante vernos finalmente mencionados. En un estudio reciente de Gartner Research, México aparece como una segunda alternativa después de la India para proveer outsourcing a nivel mundial.

MundoLa TI del Futuro se hace en México para el La Evolución de las Fábricas de SoftwarePor Karla García


EN PORTADA

Karla García es Directora de Product Management para Softtek US, donde es responsable de la definición de los productos y servicios para el mercado de Near Shore®. Sus principales actividades están enfocadas a promover el mercado de Tecnología en México hacia el extranjero, continuar el crecimiento en el mercado de Estados Unidos y desarrollar ofertas para los nuevos mercados de Near Shore® en Softtek como lo son Europa y Brasil. Karla es egresada de LSCA del Tecnológico de Monterrey.

OfertaEl tema de la oferta es algo que poco a poco se ha ido refinando. En la industria de tecnología de información, el área de Product Management tiene relativamen-te poco de haberse convertido en un área estratégica y que trabaja directamente con el CEO de la organización; ha tomado un significado importante y de resonancia. Hace siete años, cuando nace el concep-to de fábrica en Monterrey con Softtek Near Shore Services, el acercamiento inicial al mercado fue el de proporcionar manos calificadas y entrenadas para ha-cer trabajos de alto volumen, como co-dificaciones, validaciones, migraciones y pruebas repetitivas, todo a bajo costo o a una tarifa horaria competitiva en compa-ración con los consultores tradicionales. Aún y cuando esto ha representado un buen comienzo, ese modelo ha quedado en el pasado. Los clientes hoy en día bus-can un modelo que los lleve fase a fase a incrementar su productividad, lo cual va directamente relacionado con la oferta que compra a un proveedor.

De manera general, observemos las fa-ses a las cuales tendrá que responder un CGD para poder crecer y competir en este mercado:

1. La primera fase de servicio de un CGD es el outsourcing. En este esque-ma se ofrece al cliente optimizar costo a través de la subcontratación de su sta-ff de TI interno. Esto brinda beneficios inmediatos, ya que el costo directo es recortado a través de tarifas más bajas. El año que un cliente decide usar un programa de outsourcing (Near Shore u offshore) como estrategia de reduc-ción de costos, los resultados típica-mente son inmediatos y el retorno de inversión (ROI) es muy satisfactorio para los accionistas. La desventaja es que este beneficio es difícilmente me-jorable después de un par de años.

2. La segunda fase consiste en trans-formar el programa de outsourcing a

un modelo altamente efectivo opera-cionalmente para el negocio. Una vez que el cliente ha logrado su primera reducción de costos, estará buscando mejora y estabilización operacional y de proyectos, así como soluciones que mitiguen el riesgo de manera di-recta y que estén pensadas para atacar problemas específicos. Esto le traerá otra serie de beneficios que se darán a través de la optimización de procesos de negocio, minimización del riesgo y mejor desempeño de sus proveedores y CGD a través de todo su programa de outsourcing, así como a través del establecimiento de niveles de servicio más estrictos. Esta fase demanda ma-yor madurez por ambas partes e ini-ciativas más innovadoras en términos de digitalización de procesos y deci-siones basadas en métricas.

3. La tercera fase se da cuando ya se tiene capacidad de proveer soluciones globales para cualquier problema des-de cualquier región. El crecimiento estratégico y la globalización darán la pauta para establecer centros de desa-rrollo en donde tenga sentido para los clientes, con un modelo estándar de oferta y operativo. Estos modelos esta-rán soportados tanto por organizacio-nes físicas como virtuales y donde los expertos están disponibles de manera

presencial y remota en un tiempo de respuesta y calidad comparables para cualquier usuario de nuestros clientes, con conocimiento del proceso de ne-gocio. Este modelo de alta producti-vidad le traerá a las organizaciones la siguiente ola de valor a su negocio en su programa de outsourcing, donde la madurez de los mecanismos de comu-nicación y control en tiempo real, son lo que primordialmente sostendrán este modelo de entrega.

Hoy en día el mercado maduro está en la fase dos, buscando modelos híbridos de CGD y demandando métricas de control a sus proveedores; preparándo-se para dar el salto.

El reto hoy es vender México como potencia en la arena de TI, vender una propuesta de valor única que complemente, que compita y que reditúe en utilidad y poco riesgo; crecer la propuesta de valor de Near Shore, promocionar el costo total de la relación de negocio con un país en el mismo huso horario y proveer la masa crítica para satisfacer la necesi-dad del mercado de Estados Unidos. Un portafolio de ofertas competitivas y la creencia de que los profesionis-tas mexicanos podemos competir en cualquier plano con los profesionis-tas de la India, son las herramientas primordiales para nuestros centros globales de desarrollo.

Me preguntan constantemente en las Universidades, en foros gubernamen-tales estatales y federales y en algunas empresas de TI, si vale la pena apos-tarle a esto en los próximos diez años. Analistas predicen que para el 2007 el gasto en servicios de TI realizado a través de mecanismos globales de out-sourcing, como offshore y Near Shore, sobrepasará los 50 billones de dólares. Definitivamente quiero que México se lleve una rebanada de ese mercado. ¿Alguien gusta?

La propuesta de valor es el mensaje más importante que un Centro Global de Desarrollo puede llevar al mercado.


Luis Daniel Soto Maldonado es Director de Evangelización en Nuevas Tecnologías en Microsoft México. Entre sus funciones actuales están la administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Luis Daniel es jurado del “Gran Orden de Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de Tecnologías de Información (TI) relacionadas a inteligencia competitiva, administración del conocimiento y construcción de software. Luis Daniel Soto es Ingeniero en Sistemas de la Fundación Arturo Rosenblueth y ganó el primer lugar en el concurso nacional para software de exportación en 1989.

En Estados Unidos la construcción de software es un negocio, en Europa una ciencia y en Asia un arte. Lo que es claro es que la construcción de software es un proceso complejo. Muchos “nuevos alquimistas” han buscado la forma de industrializar el software, pero se ha determi-nado que crear software no es un proceso de manufactura; es una combinación de ciencia, arte, ingeniería y habilidades de administración de proyectos. Las tendencias son diversas:• Procesos para la construcción de software.• Plataformas, herramientas y lenguajes.• Esquemas de desarrollo: internamente, contratado al exterior, o por una comunidad.• Filosofía: el diseño es la aplicación; diseño in-dependiente de plataforma; descripción de la intención y no la secuencia de pasos; distintas formas de licenciar y distribuir el código, etc...

En este breve espacio, deseamos describir una tendencia a considerar: fábricas de software orientadas a dominios específicos. Aunque mucho se ha criticado el uso del término “fábri-ca de software”, lo que resulta evidente es que en todo caso una fábrica no produce por igual mesas que llantas o tazas.

Los generalistas recomiendan partir de un pro-ceso de desarrollo genérico (como es el caso del Rational Unified Process) para construir cualquier tipo de aplicaciones (v.gr. dispositi-vos portátiles, aplicaciones de misión crítica o aplicaciones para aviones comerciales).Existe otra visión: Microsoft, Unisys, Borland y otras empresas consideran que la simplificación en construir el software reside en una combina-ción de elementos acotados a un tipo de proble-ma en particular, llamado “dominio” específico:• Herramientas de construcción de software generales pero personalizadas con “diseñadores

visuales” orientados a un dominio específico (Di-chas herramientas además incluirán elementos de “nueva generación” como instrumentación, desa-rrollo en equipo, soporte asistido a metodologías para construcción de software, etc.).• Lenguajes de programación específicos a do-minio (Domain Specific Languages o DSL).• Arquitecturas de software probadas, para dominio específico y frameworks (Un fra-mework es la solución parcial a un tipo de problema particular).• Guías y procesos para dominios específicos.• Encapsular el conocimiento de negocio específico y conocimiento técnico asociado.

Por ejemplo, una fábrica de software para el sector financiero podrá producir soluciones de banca, aseguradoras, CRM y más con en-tidades de dicha vertical. Todo lo repetible se automatizará en lugar de crearse nuevamente para cada aplicación. Estos son algunos ejem-plos de empresas que están adoptando y pro-moviendo la estrategia de fábricas de software para dominios específicos: Unisys tiene fábri-cas de software para 20 industrias verticales; Borland desarrolló lenguajes específicos a do-minio basados en diagramas UML 2; Kinzan provee fábricas de software horizontales para desarrollo web; Nationwide tiene lenguajes específicos a dominio para desarrollos en sec-tor finanzas; y Siemens cuenta con fábricas de software para dispositivos médicos

Para mayor información sobre herramientas para dominio específico, pueden consultar:lab.msdn.microsoft.com/vs2005/teamsystem/workshop/dsltools/

Estimados lectores, ¿a ustedes cuál corriente les parece más sensata?

Tendencias en Construcción de Software Por Luis Daniel Soto

Bjarne Stroustrup, creador de C++, señaló: “Nuestra civilización opera sobre el Soft-ware”... Luego de una inversión global valorada en más de 10 mil billones de dólares, la Tecnología de Información está presente en nuestro día a día en forma transparente. Esto sin considerar la integración de procesos entre empresas, que apenas ha iniciado.


Las naciones latinoamericanas en particular, han mantenido un esquema de competencia

basado en mano de obra barata y abundancia de recursos naturales. Las consecuencias ya se han hecho sentir con gran impacto. La razón es muy sen-cilla, los recursos naturales son agota-bles y muy susceptibles a cambios de precio en el mercado mundial. Por otro lado, la mano de obra latinoamericana ya no se puede clasificar entre la más barata del mundo, aunque es lógico reconocer que hay grandes diferencias entre los países que constituyen este bloque. Los mercados internacionales demandan ahora que las empresas sean ágiles, basando su competitivi-dad en su capacidad de determinar lo que ocurre en su ambiente y adaptar-se al cambio de manera flexible y opor-tuna. Es así como se requiere que las empresas basen sus estrategias en la innovación y en la administración del conocimiento.

Muchas naciones consideradas como economías emergentes han reconoci-do esta necesidad y generado estra-tegias nacionales que les permitan enfocarse a nichos específicos de competitividad basada en el capital intelectual. ¿A qué podemos adjudi-car el gran éxito que han tenido estas iniciativas? Un factor común en ellas es el alto grado de articulación entre los sectores educativo, empresarial y gubernamental. Cada uno de estos sectores tiene muy claro su papel dentro de la estrategia nacional de desarrollo. En todos los casos se ha apostado muy fuertemente a la edu-cación como base de producción del

capital intelectual requerido para este tipo de iniciativas.

En el ramo de las tecnologías de infor-mación y electrónica, a través de los años se han diferenciado muchos per-files de acción de esta profesión. Sin embargo la relación entre ellas cada vez se hace más patente en cualquier campo profesional. Peter J. Denning, de la Universidad George Mason, hizo un análisis muy detallado de la necesi-dad que tienen los profesionistas en el corazón de la computación, como son los dedicados a las ciencias computa-cionales y la ingeniería de software, de relacionarse con otras disciplinas para poder ofrecer soluciones de calidad aplicables en la vida diaria.

Perfiles InternacionalesMuchas organizaciones en el mundo han realizado un gran esfuerzo por definir los parámetros mínimos que deben cumplir los perfiles profesiona-les en esta industria. Tal es el caso de la Association for Computer Machinery (ACM), la Association for Information Systems (AIS), el Institute for Electrical and Electronic Engineers (IEEE) y el modelo europeo de Career Space.

La orientación norteamericana, basa-da en los modelos producidos por los primeros tres organismos menciona-dos, identifica cinco perfiles profesio-nales, variando de la visión más física de la tecnología, hasta la visión más organizacional. Dichos modelos son:1. Ingeniería Computacional.– Orientada al funcionamiento y diseño de sistemas electrónicos computacionales, es decir al desarrollo y manejo óptimo de hardware.

2. Ciencias Computacionales.– Con una orientación científica matemática para la construcción y administración de software de base, que permita el funcionamiento óptimo del equipo y sus periféricos. Además, es el indicado para la producción de nuevo conoci-miento en las áreas de inteligencia ar-tificial, visualización y gráficas y otras áreas de corte matemático y científico.3. Ingeniería de Software.– Especia-lizado en la construcción de software de alto nivel de aplicación general o específica, orientado al usuario final.4. Tecnología de Información.– Res-ponsable de la planeación de ca-pacidades e implantación de una infraestructura tecnológica confiable y robusta. Tiene sólidas bases teóricas de la arquitectura tecnológica y bases administrativas para su optimización.5. Sistemas de Información.– Orienta-ción a la estrategia tecnológica como fundamento de la estrategia competiti-va de las organizaciones. Tiene sólidas bases administrativas y conocimiento aplicativo de las tecnologías.

Cabe señalar que la construcción de los perfiles de ACM/IEEE/AIS obedece a la visión primariamente académica de los integrantes de estas asociacio-nes. Sin embargo, existe un compo-nente importante de la industria.

A diferencia de la visión norteameri-cana, los perfiles europeos de Career Space no definen profesiones como tales, sino puestos necesarios en las organizaciones y basan su composi-ción en las opiniones de este consor-cio de empresas de alta tecnología, donde se encuentran representados

Educaciónen la Economía

del ConocimientoModelos y Tendencias

Por Guillermo Rodríguez

En tiempos como los nuestros, las reglas del juego han cambiado radicalmente con respecto al pasado cercano y lo único constante es el cambio. Cada vez más, la influen-cia de los mercados toma una vertiginosa importancia en el bienestar de una nación entera dentro del ambiente globalizado que nos envuelve.


los más importantes proveedores de tec-nologías de información en sus diferentes ramos. Career Space define 18 perfiles de puesto, clasificados dentro de cuatro grupos principales. La composición de los perfiles europeos es como se indica a continuación:1. Telecomunicaciones a. Ingeniería de radiofrecuencia b. Diseño digital c. Ingeniería de comunicación de datos d. Diseño de aplicaciones para el procesamiento digital de señales e. Diseño de redes de comunicación2. Productos y sistemas f. Diseño del producto g.Ingeniería de integración, implantación y pruebas h. Especialista en sistemas3. Software y servicios i. Desarrollo de software y aplicaciones j. Arquitectura y diseño de software k. Diseño de multimedia l. Consultoría de empresas de TI m. Asistencia técnica4. Intersectoriales n. Dirección de marketing de TI o. Dirección de proyectos de TI p. Desarrrollo de investigación y tecnología q. Dirección de TI r. Dirección de ventas de TI

La descripción de estos perfiles es muy com-pleta, incluyendo el perfil del aspirante a los

puestos, así como su actividad profesional y su posible ruta de desarrollo en las empre-sas. A diferencia de los perfiles norteameri-canos, no es importante la carrera cursada, sino las competencias que se requieren para una inserción laboral y un desarrollo profe-sional satisfactorios, desde una perspectiva principalmente originada en la industria.

Perfiles en MéxicoEn nuestro país, el principal responsable de la definición de perfiles profesionales es la Asociación Nacional de Instituciones de Edu-cación en Informática (ANIEI), que agrupa a cientos de instituciones de educación me-dia superior, técnica superior, universitaria y superior. Los perfiles de ANIEI muestran cierto grado de correspondencia con los de la visión norteamericana. Sin embargo, tiene contempladas las necesidades de la indus-tria por medio de la definición de perfiles paracurriculares que giran alrededor de los académicos y sugieren la formación de com-petencias específicas que demanda la indus-tria. Con esta estrategia, se busca disminuir el tiempo y dinero que invierten las organiza-ciones para convertir a los egresados de las universidades en profesionistas productivos dentro de las mismas. Los perfiles definidos por la ANIEI son los siguientes:1. Informática2. Ingeniería de Software3. Ciencias Computacionales4. Ingeniería Computacional

Actualmente, la ANIEI se encuentra traba-jando la definición de un quinto perfil, el de Ingeniería Telemática.

Los perfiles curriculares de estas organiza-ciones revisten una gran importancia, ya que sirven como referencia para mecanismos acreditadores y certificadores. Así, la acredi-tación nacional hecha por el Consejo Nacional de Acreditación en Informática y Computación (CONAIC) a programas educativos de calidad en México, se fundamenta en los perfiles de la ANIEI. De modo similar, las acreditaciones realizadas por la Accreditation Board for En-gineering and Technology (ABET) en Estados Unidos, hacen referencia a los perfiles de ACM/IEEE/AIS. En el ramo individual, el Cen-tro Nacional de Evaluación (Ceneval) también basa la composición de sus exámenes de cer-tificación en los perfiles de la ANIEI.

Cabe mencionar que todos los perfiles son meramente referenciales, no normativos. Existe el riesgo de que las instituciones edu-cativas tomen dichos perfiles como dogma y definan sus programas de estudio como una copia fiel de los perfiles. Esto constituye un gran error debido a que la intención muchas veces es asegurar la acreditación de sus pro-gramas. Un programa educativo debe consi-derar los perfiles como algo muy importante, pero no debe olvidar que es vital realizar un diagnóstico detallado de las necesidades de su propio contexto. Consultar a los empre-

Los programas educativos deben tomar en cuenta las

necesidades de su contexto


El Dr. Guillermo Rodríguez es Director de Sistemas de Información en el Tecnológico de Monterrey, Campus Estado de México, donde se especializa en temas como Sistemas Estratégicos, Administración del Conocimiento y Transferencia de Tecnología. Guillermo participa de manera continua en conferencias internacionales, y en 1999 recibió el reconocimiento a la mejor conferencia en el Americas Conference on Information Systems. Es presidente fundador de la Asociación de Sistemas de Información de América Latina y el Caribe.

sarios y gobierno de su región es un factor importantísimo para poder atender las nece-sidades de la misma. La construcción de un programa de estudios debe articular una es-trategia de impulso económico de la comuni-dad que la rodea. En el caso de universidades de corte nacional, la definición de programas debe obedecer la misma necesidad, pero to-mando en cuenta las oportunidades y estra-tegias de desarrollo del país. Asimismo, las instituciones deben identificar sus fortalezas para ofrecer un valor agregado a sus egresa-dos en los campos de especialidad en que posean un mayor dominio.

Es un común denominador en las recomenda-ciones de todas las organizaciones la inclu-sión de un esfuerzo muy grande por generar profesionistas cultos y con una gran visión humanista. Esto responde a la clara impor-tancia de proveer una visión de comunidad en los egresados, así como de proveerles una formación multidisciplinaria.

Hacia AdelanteLa Asociación Nacional de Universidades e Instituciones de Educación Superior (ANUIES) generó una visión de la educación superior en México para el año 2020, donde estos facto-res se encuentran claramente fundamenta-dos. Se enfatizan puntos neurálgicos como la necesidad de mecanismos que aseguren la calidad académica, el uso de modelos inno-vadores de educación y la importancia de la cooperación interinstitucional, tanto a nivel nacional como internacional. Asimismo, se destaca la importancia de facilitar la incorpo-ración de los egresados al mercado laboral y de proporcionar salidas intermedias.

En México existe una gran cantidad de pro-gramas relacionados con las tecnologías de información y electrónica que comparten nombres, pero carecen de homogenización en los objetivos y perfiles que abarcan. Esta con-fusión se transmite a los empleadores, quie-nes deben realizar su selección basándose en competencias, en lugar de en el nombre de las carreras. Las instituciones también deben ayudar al egresado a clarificar sus competen-cias, construyendo un portafolio de pruebas que permita evidenciar su perfil y facilite su certificación por organismos especializados.

Estas tendencias ya han empezado a ser in-corporadas por las instituciones educativas. Por ejemplo, después de más de 35 años de haber incursionado en el ámbito de la edu-cación de computación en México, el Tec-nológico de Monterrey ha evolucionado su oferta educativa con un paradigma radical-mente distinto a las renovaciones periódicas que realizaba al menos cada cinco años, así redefiniendo su oferta educativa en una pro-fesión integradora de Tecnologías de Infor-mación y Electrónica. Las carreras incluidas en esta oferta son las siguientes:

1. Ingeniería en Tecnologías Electrónicas, con concentraciones en Sistemas Digitales, Automatización y Robótica, Telecomunicacio-nes y Microelectrónica. Este profesionista es especialista en hardware y programación de bajo nivel y hace frente a los retos de inno-vación en dispositivos que permitan mejorar la competitividad en las industrias de manu-factura y comunicaciones.

2. Ingeniería en Tecnologías Computacionales, con concentraciones en Animación Digital, Ingeniería de Software, Redes y Seguridad, Sistemas Inteligentes y Arquitectura de Tec-nologías de Información. Este profesionista se especializa en aplicaciones de software, proveyendo a las empresas de la administra-ción adecuada de infraestructura que permita la continuidad de las operaciones de una or-ganización de manera óptima.3. Licenciatura en Administración de Tec-nologías de Información, con concentracio-nes en Aplicaciones Multimedia, Inteligencia de Negocios y Mercadotecnia de Productos y Servicios de Tecnologías de Información. Este profesionista es un estratega tecnoló-gico para las organizaciones, facilitando su competitividad y su adaptabilidad en merca-dos cambiantes.4. Ingeniería en Tecnologías de Información y Comunicaciones, con acentuaciones en Electrónica, Computación e Informática. Este profesionista atiende necesidades de integración en las disciplinas de electrónica, computación e informática, teniendo un valor muy particular en comunidades pequeñas, así como en la pequeña y mediana empresa, misma que tiene un gran impacto en la pro-ductividad de naciones en desarrollo.

Es vital desarrollar una estrategia educativa basada en el impulso de las tecnologías de

información y electrónica

Es importante notar que se incluyen núcleos muy importantes de formación humanística, además de mecanismos específicos de in-ternacionalización, experiencia profesional, investigación y desarrollo emprendedor. La fór-mula del Tecnológico de Monterrey no es para todos. Cada institución educativa debe actuar de acuerdo a las tradiciones positivas que la ca-racterizan, buscando capitalizar en sus logros y fortaleza, pero sin olvidar que los objetivos pri-mordiales deben ser los siguientes:

1. Atender las necesidades de su comunidad inmediata, formando los profesionistas ade-cuados a las mismas.2. Articular el desarrollo e implantación de sus programas con el sector productivo y gubernamental.3. Proveer competencias específicas que faci-liten su incorporación al sector productivo.4. Proveer una educación multidisciplinaria, ya que así son los problemas del mundo.5. Enfatizar la formación ética, humanística y de compromiso con la comunidad.6. Apoyar el impulso económico de la región y del país, considerando el capital intelec-tual como agente activo de desarrollo.

Sólo resta concluir que para garantizar el desarrollo nacional y poder enfrentar la competencia global, es vital desarrollar una estrategia basada en el impulso de las tec-nologías de información y electrónica en nuestro país. Esta estrategia debe apostar al mejoramiento del sistema educativo nacio-nal y a la formación de una verdadera socie-dad de conocimiento, con capital intelectual competitivo internacionalmente y con visión multidisciplinaria y comprometida.

Referencias• Denning, Peter J. (1998) Computing the Profession. Preparado para el libro Computer Science and Engineering Education, Tony Greening, Editor y para Educom Review, John Gehl, Editor.• Accreditation Board for Engineering and Technology (ABET)www.abet.org• Career Space www.career-space.com/cdguide/index.htm• Asociación Nacional de Instituciones de Educación en Informática (ANIEI)www.aniei.org.mx• Programas profesionales ITESMwww.sistema.itesm.mx/va/profesional.htm


CASO DE ESTUDIO

MoProSoft® es un modelo de procesos de reciente creación, para la industria de software en México que fomenta la estan-darización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. El objetivo de este modelo es mejorar la capacidad de los procesos de las empresas.

La estructura de MoProSoft® considera tres categorías: Alta Dirección, Gestión y Opera-ción. Establece un mecanismo para alinear las estrategias de las tres categorías. La categoría de Alta Dirección contiene el pro-ceso de Gestión de Negocio. La categoría de Gestión está integrada por los procesos de Gestión de Procesos, Gestión de Proyec-tos y Gestión de Recursos. Éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo, Bienes, Servicios e Infraestructura y Conocimiento de la Organización. La categoría de Opera-ción está integrada por los procesos de Ad-ministración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software.

MoProSoft® está disponible en la página www.software.net.mx

AntecedentesDesde hace varios años, ULTRASIST ha rea-lizado un esfuerzo de mejora incremental al adoptar las mejores prácticas de diferentes modelos internacionales. Como resultado, la Organización alcanzó el nivel de madurez 4 de SW-CMM®, utilizando a MoProSoft® como marco de referencia.

En la planeación estratégica del 2003, la Organización decidió buscar una evaluación en algún modelo reconocido en la industria. Entre los modelos candidatos se encontraban ISO 9000:2000, MoProSoft y SW-CMM®. En ese momento MoProSoft® tenía la caracte-rística de ser el documento base de la norma mexicana para la industria de software, pero por ser de reciente creación, no contaba con su método de evaluación, ni con un organis-mo que respaldara la aplicación del mismo. La decisión que se tomó para adoptar el mo-delo orientado en la industria mexicana y lo-grar una evaluación reconocida, fue obtener al menos un nivel 3 de SW-CMM® a través de MoProSoft®.

ProblemáticaLa Organización contaba con una serie de pro-cesos para el desarrollo y mantenimiento de software, administración de proyectos y para establecer la mejora continua de los mismos. El desempeño de los procesos de desarrollo y mantenimiento se medía a través de indicado-res, lo que permitió robustecer estos procesos pero no proporcionaban el tipo de información que necesitaba saber la alta dirección para medir el cumplimiento de los objetivos estra-tégicos. Durante varios años la Organización establecía un Plan Estratégico para definir las metas, pero no con base en un proceso docu-mentado. Existía una brecha entre las metas de negocio y las de los procesos de desarrollo de software por no contar con una retroalimen-tación bidireccional. Es decir, la dirección con-sideraba los resultados de la valoración de los procesos para realizar esta actividad de pla-

neación, mientras que el Grupo de Procesos se preocupaba por mejorar los procesos con base en los resultados de la evaluación anterior (defectos fugados, defectos por caso de uso, plataforma de trabajo, retrabajo, entre otros) pero no se consideraban las expectativas de la alta dirección (utilidad esperada, retorno de inversión, valor presente neto, tasa interna de retorno, entre otros).

Experiencia en la ImplantaciónMoProSoft® se utilizó para alinear las estra-tegias de la parte operativa con las expec-tativas de la alta dirección. El proceso de Gestión de Negocio se estableció formal-mente en la Organización. Una vez revisada la misión, visión y valores de la Organiza-ción, se revisaron los objetivos estratégicos y se definieron indicadores que permitieran evaluar el cumplimiento.

Los objetivos estratégicos se agruparon en cuatro perspectivas como sugiere el Cuadro de Mando Integral (Balanced ScoreCard).

Claudia Alquicira trabaja en Avantare Consutores como consultor en programas de mejora en organizaciones de desarrollo de software. Sus áreas de interés son la ingeniería de software, calidad y tecnología orientada a objetos. Claudia cuenta con una Maestría en Ciencias de la Computación y participó como ponente en el SEPG LA 2004

MoProSoften la PrácticaRecomendaciones para su ImplantaciónPor Ma. Julia Orozco y Claudia Alquicira

Este artículo presenta la experiencia de la implantación de MoPro-Soft® en una empresa de desarrollo de software y resume un ciclo de mejora considerando desde la planeación estratégica hasta su valoración. Se explica cómo se usó el modelo como marco de refe-rencia para las partes de gestión y operación y cómo se utilizó el qué y el cómo para la parte de Gestión de Negocio.

MoProSoft® es un posible medio para las organizaciones que deseen lograr

una evaluación exitosa en un modelo

internacional como SW-CMM®

Aborda las prácticas de Alta Dirección relacio-nadas con la gestión del negocio. Proporciona los lineamientos a los procesos de la Categoría de Gestión y se retroalimenta con la información generada por ellos.

<Categoría>Alta Dirección

<<Dir>>+ Gestión de Negocio

En la Perspectiva Financiera se agruparon aquellos objetivos que tienen que ver con el cumplimiento de las expectativas de los accio-nistas. En la Perspectiva del Cliente los objeti-vos que nos llevan a satisfacer las necesidades de nuestros clientes. En la Perspectiva Interna los relacionados con la mejora de aquellos procesos en los cuales debemos ser excelen-tes, y finalmente, la Perspectiva de Aprendiza-je y Crecimiento que considera los aspectos críticos para mantener la excelencia.

Se definieron los procesos de negocio requeridos en la Organización para dar cumplimiento a los elementos del Plan Estratégico, la estructura organizacional se revisó y actualizó principalmente en lo que respecta al Grupo de Procesos definiendo responsables de procesos y especialistas. El Plan de Comunicación se instituyó como un mecanismo de difusión de los Planes a los miembros de la Organización. Se consideró un Proyecto de Inversión y se identificaron los proyectos internos y externos para dar cumplimiento a los objetivos. Como pro-yectos internos se establecieron el Proyecto de Mejora y el de Infraestructura y Fortale-cimiento. Se establecieron las estrategias para dar cumplimiento a los objetivos estra-tégicos y se definieron metas e indicadores para poder valorar el avance.

La alta dirección dio la responsabilidad al Grupo de Procesos para detallar los Pro-cesos de Negocio y definir los procesos de apoyo para cumplir con los objetivos estra-tégicos planteados.

La implantación del proceso de Gestión de Negocio dio orden y disciplina a las activi-dades de la alta dirección, lo que permitió establecer la alineación de las metas de ne-gocio con las de Gestión y Operación.

Categoría de Gestión y OperaciónEl Grupo de Procesos realizó un análisis de brecha de las prácticas establecidas en la Organización con respecto a las estableci-das en las otras categorías de MoProSoft®. Como resultado se obtuvo que la Organiza-ción contaba con procesos que cubrían gran parte de la categoría de Gestión y toda la categoría de Operación.

Con base en el análisis realizado, se prio-rizaron los objetivos con la Dirección y se elaboró el Plan de Procesos que contiene la estrategia para definir, implantar, medir y evaluar los procesos. Las métricas que se es-

<<Categoría>>Gestión

Establecer los procesos de la organización, en función de los procesos requeridos identificados en el Plan Estratégico. Así como definir, planear, e implantar las actividades de mejora en los mismos.

<<Ges>>Gestión de Procesos

<<Ges>>Gestión de Proyectos

<<Ges>>Gestión de Recursos

tablecieron fueron aquellas que permitieran retroalimentar a la Organización en cuanto al cumplimiento de los objetivos estratégi-cos. El aspecto más importante que se tomó en cuenta para definir una métrica fue que el costo de producirla estuviera balanceado con el beneficio potencial que será ganado en la organización. El registrar, recolectar y evaluar métricas lleva implícito un costo, que para la mayoría de las empresas mexicanas de desarrollo de software puede resultar pro-hibitivo si no se garantiza un retorno de inver-sión a corto plazo. Si bien es sabido que no se puede mejorar lo que no se puede medir, también es cierto que hay que empezar por mejorar aquellos procesos que impacten a las metas prioritarias de la Organización.

La estrategia que estableció el Grupo de Proce-sos para implementar los cambios en la Orga-nización, consistió en realizar las actividades en forma iterativa e incremental de acuerdo a las prioridades establecidas.

Al finalizar cada incremento se evalúo el cum-plimiento de los objetivos establecidos en el Plan Estratégico. Estas evaluaciones fueron más frecuentes que las establecidas en los años anteriores por ser un modelo de procesos nuevo, que impactaba a toda la Organización. Para este proyecto, se acordó contar con el apoyo de consultores internos y externos con conocimientos en CMM® y MoProSoft® para asegurar el apego a los modelos. Durante la definición y el ajuste del proceso se estable-cieron las diferencias significativas entre los modelos MoProSoft® y SW-CMM®. Con res-pecto al proceso de Gestión de Proyectos, se dividió en dos procesos, Ventas y Oficina de

Categoría de Gestión

Proyectos, tomando como base las prácticas ya establecidas en la Organización.

Para los procesos de Gestión de Recursos y sus subprocesos asociados, se estableció una arquitectura diferente a la definida por MoProSoft®. La Organización contaba con un proceso que considera un Plan de Capaci-tación para cumplir con las metas planteadas en los objetivos estratégicos de aprendizaje y crecimiento; considera los requerimientos de los proyectos, las sugerencias del personal e incluye el desarrollar las habilidades que se desea que adquieran los miembros de la Organización, como es el trabajo en equipo, habilidades gerenciales, y manejo de con-flictos. La capacitación que plantea se ofrece en diferentes modalidades: interna, externa, seminarios sobre nuevas tendencias tecnoló-gicas y capacitación en la práctica.

El proceso de Recursos Humanos establecido por MoProSoft® se maneja dentro del Proce-so de Gestión de Proyectos por la Oficina de Proyectos. En él se establecen los elemen-tos a considerar en la selección, asignación, aceptación, evaluación y desempeño de los recursos humanos. Para la evaluación de los miembros de la Organización se provee un mecanismo que permite valorar su cre-cimiento en dos direcciones: la horizontal con respecto al desarrollo de habilidades y la vertical con respecto a los conocimientos y responsabilidades. El objetivo de esta eva-luación es permitir un crecimiento gradual de los miembros de la Organización para cumplir con los objetivos estratégicos planteados en la perspectiva de aprendizaje y crecimiento.

En cuanto al Plan de Infraestructura y Am-biente de Trabajo, se considera dentro del Proyecto de Infraestructura derivado del Plan Estratégico.

Si bien la Organización contaba con una Base de Conocimiento con la información referente a las Categorías de Gestión y de Operación, no consideraba la generada por la Alta Direc-ción. Hoy en día el repositorio considera toda la información de la Empresa.

SW-CMM® a Travésde MoProSoft®Como resultado de este esfuerzo, la empresa pudo comprobar que es factible implantar Mo-ProSoft® y que es un posible medio para las organizaciones que deseen lograr una evalua-ción exitosa en un modelo internacional como SW-CMM®. Para lograrlo es necesario cuidar las prácticas establecidas en CMM® y no con-sideradas en MoProSoft®, por ejemplo:

• En el proceso de Gestión de Negocio, escri-bir una política que contenga los lineamientos que rijan los procesos definidos consideran-


El aspecto más importante para definir una métrica fue que el costo de producirla estuviera balanceado con el beneficio potencial que será ganado en la organización

Ma. Julia Orozco ocupa la Dirección Técnica en la empresa Ultrasist. Es Matemática con estudios de Maestría en Ciencias de la Computación. Ha impartido cursos en universidades, gobierno e iniciativa privada y ha sido ponente en diversos foros internacionales.


CASO DE ESTUDIO

do los compromisos establecidos en el nivel que se desea alcanzar de SW-CMM®.• En el subproceso Recursos Humanos y Am-biente de Trabajo del proceso de Gestión de Recursos, definir un mecanismo de renuncia a la capacitación asignada.• En el subproceso de Conocimiento de la Or-ganización del proceso de Gestión de Recur-sos, incluir las prácticas de administración de configuración establecidas en CMM®.• MoProSoft® no considera el Grupo de SQA que maneja CMM®, pero sí establece verifi-caciones y validaciones a productos y a pro-cesos, sin embargo, para cumplir con CMM® hay que conformar un Grupo de SQA que sea independiente al proyecto.• En cada uno de los procesos de MoProSoft in-cluir las verificaciones de las actividades por el SQA de acuerdo a cada área clave de CMM®.• En las evaluaciones externas (proceso de ges-tión de procesos) considerar un SQA externo.

Ambos modelos llevan al mismo fin, pero cada uno sigue un camino diferente.

Fortalezas de MoProSoft®Gestión de Negocio, sirve como vínculo entre la parte de operación, gestión y dirección para que los esfuerzos de la organización estén ali-neados para alcanzar la misión y visión. Para empresas de reciente creación pueden utili-zar el qué y el cómo que define MoProSoft®

como un medio que facilite la transición a un modelo internacional.

Los modelos internacionales por lo general consideraran una gran variedad de roles que una micro y pequeña empresa mexicana no puede implantar. MoProSoft® no restringe a ningún rol para que pueda ser realizado por una misma persona, o por diferentes personas dentro del mismo proyecto y en la medida que la empresa crece, éstos pueden paulatinamen-te ser asignados a personas diferentes. Se recomienda cuidar en la medida de lo posible que una persona no sea juez y parte. Esto per-mite a la micro y pequeña empresa crear la cul-tura de procesos y fomentar la disciplina.

Aunque MoProSoft® fue pensado principal-mente para la pequeña y mediana empresa, puede ser usado como marco de referencia para toda empresa que se inicia en un programa de mejora, para asegurar que las estrategias a lo largo de la organización están alineadas y para asegurar que los procesos ya establecidos, con-templan las mejores prácticas.

Recomendaciones Generales para Implantar MoProSoft®Es importante conservar las mejores prác-ticas con las que cuenta una organización y, en caso de ser requerido, ajustarlas para el cumplimiento con el propósito, los

objetivos, la descripción del proceso esta-blecidos por el modelo MoProSoft®. Como ejemplo, definir un proceso de Gestión de Recursos que incorpore los elementos de los subprocesos de Recursos Humanos e Infraestructura, Bienes, Servicios y hacer un proceso en Gestión de Conocimiento de la Organización.

La participación de consultores con expe-riencia en el modelo que se desea implantar siempre es recomendable. En MoProSoft® por ser un modelo de reciente creación que no cuenta con experiencia documentada, se considera indispensable.

Para las organizaciones que inician un pro-grama de mejora, el proceso de Gestión de Procesos podría ser el primero a definir e im-plantar puesto que con este proceso se ge-nera el resto de los procesos. Se recomienda una estrategia incremental de acuerdo a las prioridades de la organización que permite reducir los riesgos que conlleva la introduc-ción de muchos cambios y permita a la Direc-ción observar resultados a corto plazo.

La responsabilidad de asignación de recur-sos humanos a los proyectos se puede atri-buir al responsable de Gestión de Proyectos y la parte de registro de recursos humanos a un área administrativa.

Diagrama 1:

MoProSoft® como

marco de referencia. CMMInicial

Repetible

Definido

Administrado

Optimizado

<<Categoría>>Gestión

<<Ges>>Gestión de Procesos

<<Ges>>Gestión de Proyectos

<<Ges>>Gestión de Recursos

<Categoría>Alta Dirección

<<Dir>>+ Gestión de Negocio

<<Categoría>>Operación

<<Oper>>

Administración de Proyectos Específicos

<<Oper>>

Desarrollo yMantenimiento

de Software

Cat

egor

ías


PRÁCTICAS

PRUEBAS

Mi intención al escribir artículos es poder com-partir con los lectores mis experiencias y visión sobre el control de calidad del software en la Ar-

gentina, su problemática, y lo que he observado sobre su evolución a lo largo de la última década.

Una Mirada RetrospectivaDurante los últimos años de mi trabajo en sistemas, me he dedicado con exclusividad al control de calidad de soft-ware. Una de mis principales actividades ha sido el reclu-tamiento y entrenamiento de ingenieros de pruebas. Esta tarea no me ha resultado sencilla, dado que es un mer-cado donde dicha actividad era considerada, hasta hace unos años, como una profesión de segunda categoría, a la cual se podía acceder:

• Como castigo por haber cometido algún error o tener un bajo rendimiento en otro área de sistemas de la organización.• Como la vía de ingreso de principiantes para trabajar en sis-temas y prepararse para mejorar su desarrollo profesional inci-piente, el cual desembocaría en el área de desarrollo.• Como pasajeros en tránsito, que colaboraban en el área de pruebas mientras el área de recursos humanos busca-ba para ellos un nuevo proyecto de desarrollo, porque su asignación anterior había terminado.

Sólo unos pocos accedimos por elección a esta singular profesión, recientemente considerada como tal.

A partir del año 2000, y como resultado de haber mostra-do a clientes internos y externos, el valor de la actividad, la percepción sobre la misma está cambiando considerable-mente. La industria comienza a reconocerla, a valorarla, y

a darle un lugar preponderante dentro del ciclo de vida de desarrollo del software. Sin embargo, aunque ya hemos recorrido un largo camino, no es poco ni simple lo que queda por delante.

La Problemática de la ActividadA pesar de que la actividad ya está en gran medida in-corporada al “quehacer cotidiano” de muchas de las or-ganizaciones, esto no significa que como disciplina esté madura, aún queda mucho por mejorar, refinar, expandir y aprender. Permítanme entonces, señalar algunos de los puntos sobre los que debemos trabajar.

El factor humano en la calidad.- La calidad debe ser lide-rada desde la cúpula de la organización. Necesita ser pa-trocinada y respaldada a lo largo del tiempo. Además, es responsabilidad de todos y de cada uno de los integrantes de la organización y no sólo del área de calidad.

El entrenamiento.- Pocas organizaciones tienen previsto un plan de capacitación para el área de pruebas. Es habitual capacitar a los desarrolladores, pero de alguna manera es como si realizar pruebas fuera un don con el que se nace, en lugar de tratarse de una disciplina que se aprende con ca-pacitación y trabajo metodológico. Realizar pruebas es una disciplina de la ingeniería y no un arte. Sigue persistiendo el prejuicio de que probar es algo que cualquiera puede realizar profesionalmente, sin entrenamiento. Pretender cambiar cer-teramente esta idea es difícil; aplica una cita de Einstein: “Es más fácil desintegrar un átomo que un prejuicio”.

Definitivamente cuanto mayor y mejor sea el entrenamien-to que recibe un ingeniero de pruebas, mejor será su des-

Por Alfonsina Morgavi

RANSITANDO HACIAEL CAMBIO

LA PROBLEMÁTICA DEL INGENIERO DE PRUEBASTAlfonsina Morgavi es socia fundadora de QASoft en Argentina, donde se desempeña como consultora en Aseguramiento de Calidad de Software. Dedicada desde el año 1989 exclusivamente a esta actividad. Uno de sus principales intereses es el entrenamiento de ingenieros de pruebas y el coaching en proyectos de la especialidad. Alfonsina está certificada por el Quality Assurance Institute como Ingeniera en Control de Calidad de Software, así también como Consultora en Implementación ISO 9001:2000 por la Fundación Cane. Es miembro activo del subcomité de normas de calidad de software del Instituto Argentino de Racionalización de Materiales (Miembro ISO, COPANT y AMN).

empeño y el valor que podrá agregar al producto a probar.

Los vínculos participativos.- No es fre-cuente que se genere una relación par-ticipativa entre ingenieros de pruebas y desarrolladores. Es usual, encontrar dos equipos enfrentados “pasando el juego (el software) del lado del campo del adversario”, lo que desde luego no es beneficioso para el proyecto.

¿Cuándo probar?.- La prueba, por lo general, es incluida sólo al final del desarrollo, cuando hay un “ejecutable” a evaluar. Entonces, por ser la última actividad (antes de la prueba de aceptación y de la entrega del producto), las etapas previas de desarrollo suelen tomar para sí, parte del tiempo destinado a la etapa de pruebas. Esto significa que es la actividad cuyo tiempo es más factible que se recorte, poniendo en peligro la cobertura de las prue-bas y, por ende, la calidad del producto.

Sin lugar a dudas, el momento más apropia-do para el comienzo de las actividades de pruebas es al inicio del proyecto, lo antes posible, y desde la etapa de requerimientos. Se trata de no llegar al final del desarrollo con un producto que por ejemplo, funciona correctamente “en el escritorio”, pero que no responde a los requerimientos especi-ficados y no le permitirá al usuario llevar

adelante la operatoria de su negocio en el “mundo real”.

El final del proyecto es, definitivamente, el mo-mento menos adecuado para enterarnos de esto. Por unanimidad, los libros de la especialidad di-cen claramente: “Test often and test soon”, “rea-lice pruebas con frecuencia y tempranamente”.

Acerca de los ProcesosEs prioritario definir la prueba como un proceso, a efectos que, toda la organización tenga en cla-ro cuál es su propósito, las actividades que se realizan, los roles y responsabilidades, dejando en claro que no es la solución “para enderezar” un proceso de desarrollo desordenado y caóti-co. Como contracara, un proceso de desarrollo ordenado y disciplinado permitirá realizar una mejor evaluación del estado de los productos, permitiendo a los ingenieros de pruebas poner el foco de atención sobre sus debilidades.

La calidad debe ser liderada desde la cúpula de la organización Algunas Conclusiones

Ya no buscamos la famosa bala de pla-ta, pero sólo porque ninguno de noso-tros ha conocido a alguien que alguna vez la haya visto, y sin ánimo de ser aguafiestas, tampoco deberíamos re-emplazar la ilusión de la bala de plata por fórmulas mágicas, porque tampoco nadie las ha visto.

Es tiempo de crecer y cambiar, de dise-ñar planes de acción realistas, que nos permitan mejorar nuestros procesos de control de calidad. Es tiempo de ca-pacitarnos para enfrentar un mercado que día a día, pide lo mejor.

Y por último y a modo de cierre, quisie-ra rescatar las palabras de John Rus-kin: “La calidad nunca es un accidente; siempre es el resultado del esfuerzo de la inteligencia”.

Ramés Rodríguez Vargas es Desarrollador de J2EE desde el 2002. Su especialidad es el empleo de software libre aplicado a Java y el diseño de arquitecturas orientadas a objetos. Actualmente se desempeña como Arquitecto de Sistemas en la Universidad Loyola del Pacífico.

PRÁCTICAS

ARQUITECTURA


La organización consiste en la estructura de paquetes que

agruparán a los elementos

En el número anterior expusi-mos la forma de abordar la complejidad de un sistema

J2EE a través de su organización en capas conceptuales. En esta ocasión aplicaremos este método para orga-nizar los elementos de un sistema. Es decir, definiremos una jerarquía de paquetes para contener las clases que componen el sistema. Aunado a la aplicación de las capas concep-tuales, y con el objeto de diseñar un Sistema J2EE de la vida real, apli-caremos el patrón MVC (ver Funda-mentos, pg. 42) a esta arquitectura que será diseñada. ¿Qué beneficios ofrece esto? Reducir la duplicidad del código, facilidad de mantenimiento y una arquitectura robusta, la cual pu-ede ser empleada como plantilla en el diseño de un Sistema J2EE.

Diseño de la ArquitecturaUna vez que hemos entendido la im-portancia del Patrón MVC en sistemas que poseen varios tipos de clientes, ha llegado el momento de mostrar en dónde encaja el método de orga-nización en capas conceptuales. La organización consiste en la estructu-ra de paquetes en que globalmente será dividido un sistema. Para esto nos apoyaremos en un sistema cuya arquitectura de referencia será basa-

da en los Patrones MVC y Fachada (un patrón donde se provee una interfaz sencilla hacia objetos o subsistemas complejos). La figura 1 muestra la ar-quitectura de este sistema. En la ima-gen se puede observar que se cuenta con un solo cliente, el cual es una aplicación JFC/Swing, y además de que el sistema, desde la perspectiva del cliente, sólo está dividido en tres partes: Vista, Controlador y Modelo.

Figura 1. Una arquitectura basada en los Pa-

trones MVC y Fachada.

Si analizamos con detalle la arqui-tectura encontraremos varios puntos interesantes. El objeto Modelo, desde la perspectiva del Controlador, fun-ciona como un Proxy de toda la Lógica de Negocios tanto local como remota (EJB’s). Gracias a esto, al Controlador le resulta transparente el hecho de que está obteniendo datos de una fuente local (un archivo a través del

ModeloLocal) o remota (Servidor de Aplicaciones a través del ModeloRe-moto); desde su perspectiva, debe de relacionarse exclusivamente con un solo objeto, el Modelo.

Ahora definiremos la estructura de paquetes que será organizada a través de las capas conceptuales. Primero definiremos el espacio de nombres, éste viene dado por el nombre de dominio en Internet de la organización, pero en orden in-vertido. Por ejemplo, mx.edu.loyola sería el espacio de nombres para el dominio loyola.edu.mx. Después hay que agregar el acrónimo del Sis-tema a nuestro espacio de nombres. Por ejemplo, SIL es el acrónimo de un proyecto que lleva por nombre “Sistema Integral Loyola”. Poste-riormente se define un paquete para cada una de las cinco capas concep-tuales. La plantilla se muestra en el Listado 1.

Listado 1. Esquema de paquetes genérico.

Por Ramés Rodríguez

ESTRUCTURA DE

PAQUETESORGANIZANDO LOSELEMENTOS DEL SISTEMA

mx.com.miempresa.misistema. Presentacion

Aplicacion

Servicios

Dominio

Persistencia


Un sistema suele dividirse en módulos cohesivos que encapsulan una funcionalidad muy específica

e independiente de otros módulos.

El Listado 2 muestra cómo sería la estructura de paquetes para el ‘SIL’, el Sistema de ejemplo:

mx.edu.loyola.sil.presentacion

mx.edu.loyola.sil.aplicacion

mx.edu.loyola.sil.servicios

mx.edu.loyola.sil.dominio

mx.edu.loyola.sil.persistencia

Listado 2. La estructura de paquetes en un Sistema Real.

Los paquetes para clientes y la Lógica de NegociosLos clientes cuya arquitectura está basada en el Patrón MVC sólo emplearán las tres primeras capas (presentación, aplicación y servicios) para almacenar las clases de los objetos Controlador, Vista y Modelo. Las otras dos capas son exclusivas para la pro-gramación del lado del servidor, sin em-bargo, la capa de servicios es compartida tanto por el cliente como por el servidor. El siguiente paso es agregar en cada una de estas tres capas un paquete para cada tipo de cliente. Por ejemplo, el Listado 3 muestra al SIL con dos tipos de cliente: uno de tipo inalámbrico basado en MIDP (Mobile Information Device Profile) y una aplicación JFC/Swing.

Listado 3. La estructura para dos tipos de cliente.

Como la Lógica de Negocios está progra-mada a través de EJBs, se declara el pa-quete ‘ejbcontainer’ en cada una de las tres últimas capas. En la de servicios se almacenarán nuestras fachadas; en la de dominio, el modelo conceptual; y en la de persistencia, todas aquellas clases que colaboran en el almacenamiento de nues-tro modelo conceptual.

Listado 4. El paquete para los EJB’s.

Los Paquetes para los Módulos del SistemaUn sistema suele dividirse en módulos co-hesivos que encapsulan una funcionalidad muy específica e independiente de otros módulos. El siguiente paso es agregar los paquetes para los módulos en cada uno los paquetes de tipo de cliente y en el de los EJBs. Por ejemplo, el SIL puede estar dividi-do en dos módulos: cobranza y control esco-lar. El Listado 5 muestra como deben estar organizados estos paquetes.

Listado 5. Los Módulos en cada uno de los clientes y

en el paquete de los EJB’s.

mx.edu.loyola.sil.

presentacion.

aplicacion.

servicios.

midp

jfc

midp

jfc

midp

jfc

mx.edu.loyola.sil.

servicios.ejbcontainer

dominio.ejbcontainer

persistencia.ejbcontainer

midp.

jfc.

ejbcontainer.

cobranza

controlEscolar

cobranza

controlEscolar

cobranza

controlEscolar

ConclusiónHemos mostrado la forma en que las capas conceptuales nos pueden auxiliar en la or-ganización de un sistema cuya arquitectu-ra referencial está basada en los patrones MVC y Fachada. Todo esto nos ofrece be-neficios tales como: mejorar la organiza-ción del código, desacoplar el modelo de negocios con el de presentación, un fácil mantenimiento, reutilización de código y facilidad al momento de agregar un nuevo tipo de cliente.

Lo que aquí se ha expuesto es una plan-tilla de referencia que puede servirnos como guía al momento de crear un nuevo Sistema J2EE. Esperamos que les pueda ser de utilidad.

PRÁCTICAS

ARQUITECTURA

Referencias:Marinescu, Floyd. EJBTM Desing Patterns. Wiley, 2002.Singh, Stearns, et al. Designing Enterprise Applications with the J2EE Platform, Second Edition. Addison-Wesley, 2002.

Lo que aquí se ha expuesto es una plantilla de referencia que puede servirnos como guía al momento

de crear un nuevo sistema J2EE

Figura 2. El módulo en operación.


Lo que resta es definir dónde se deben almacenar cada uno de los objetos que componen nuestro sistema en base al Patrón MVC. Las clases que componen las vistas son almacenadas en la capa de presentación; el contro-lador en la de aplicación; y el modelo en la de servicios. El Listado 6 muestra las clases que formarían parte de un módulo y de un cliente. La figura 2 muestra cómo se comportaría este módulo en tiempo de ejecución.

Las Vistas mx.edu.loyola.sil.presentacion.jfc.cobranza.Ventana1

mx.edu.loyola.sil.presentacion.jfc.cobranza.Ventana2

mx.edu.loyola.sil.presentacion.jfc.cobranza.Ventana3

El Controlador mx.edu.loyola.sil.aplicacion.jfc.cobranza.Controlador

El Modelo mx.edu.loyola.sil.servicios.jfc.cobranza.Modelo

mx.edu.loyola.sil.servicios.jfc.cobranza.ModeloLocal

mx.edu.loyola.sil.servicios.jfc.cobranza.ModeloRemoto

La Fachada mx.edu.loyola.sil.servicios.ejbcontainer.cobranza.ServiciosDeCobranza

El Modelo de Dominio mx.edu.loyola.sil.dominio.ejbcontainer.cobranza.Entidad1

mx.edu.loyola.sil.dominio.ejbcontainer.cobranza.Entidad2

mx.edu.loyola.sil.dominio.ejbcontainer.cobranza.Entidad3

La Persistencia mx.edu.loyola.sil.persistencia.ejbcontainer.cobranza.DACB1

mx.edu.loyola.sil.persistencia.ejbcontainer.cobranza.DACB2

mx.edu.loyola.sil.persistencia.ejbcontainer.cobranza.DACB3

Listado 6. Algunas de las clases que conforman un solo Módulo: cobranza.

ARQUITECTURA

CO

LUM

NACentros de Desarrollo de Software

La Opción para México

La industria del software interviene en todos los procesos que habilitan a la nueva “economía digi-tal”, siendo el software elemento inherente de las

tecnologías de información. De acuerdo a las caracterís-ticas de cada empresa, éstas desarrollarán su software o lo adquirirán de otras compañías o divisiones. Existen va-rios esquemas para adquirir software de manera externa: software general (off-the-shelf ), outsourcing, nearsour-cing y centros de desarrollo. El que me ocupa hoy es este último. Un centro de desarrollo de software (CDS) es una empresa que ofrece servicios de desarrollo de software a la medida, garantizando estándares internacionales. Ya se ha comentado anteriormente en esta columna sobre la necesidad de que en el país se fomente la industria del software. Dado esto, ¿qué tan apropiado o conveniente es que un desarrollador de software se consolide como CDS? Comento algunos hechos que se han estado dando sobre este tema en México:

a) La Secretaría de Economía de México lanzó en el año 2003 el Programa para el Desarrollo de la Industria del Software (ProSoft). El objetivo fijado es lograr exportacio-nes de cinco mil millones de dólares para el año 2010.

b) Tal como comenta Rocío Ruiz Chávez, Subsecretaria de Comercio Interior de la Secretaría de Economía, la industria a nivel mundial está interesada en encontrar países con bajos costos y mano de obra calificada. Están conscientes en la Secretaría de Economía que se debe crear primero el marco legal para los productos que de-sarrollen estos centros, así como un mercado interno que consuma los productos. Apunta también al hecho de que en México hay únicamente cuatro sectores compradores de soluciones de software: industria automotriz, bancos, gobierno y las grandes cadenas comerciales. Comenta que se ha creado el Instituto del Desarrollo de la Eco-nomía Digital, que promoverá la creación del mercado interno de productos.

c) Los datos de la Cámara Nacional de las Industrias Elec-trónicas de Telecomunicaciones e Informática (CANIETI), revelan que el gasto en TI como porcentaje del PIB ape-nas llega en México a 1.3%. Sin embargo, en países como Brasil y Argentina alcanza 2.7%; mientras que en Chile se eroga 2.2%. Ni hablar de economías grandes como la de Gran Bretaña, que destina 4.5%.

Se ha comentado anteriormente que la industria del soft-ware debe mirar primero hacia el mercado interno del país, antes de fijarse en objetivos de exportación. Ante

este punto de vista, la idea de establecer CDSs resulta atractiva, ya que un centro establecido puede entonces hacer el movimiento al mercado de exportación. En mi opinión, se requiere de un programa nacional de desa-rrollo en el que el gobierno mexicano se ocupe de ser el promotor de la industria mexicana, a la vez que también sea el principal consumidor de productos de software de-sarrollados a la medida. Se deben crear las condiciones, además de generar la demanda por productos, para que valga la pena el establecer estos centros en el país. Ya contamos con CDSs en Aguascalientes, Baja California, Guanajuato, Jalisco, Morelos, Nuevo León, Puebla, Sina-loa, Sonora y Yucatán.

Si el interés por apalancarse en Tecnologías de Infor-mación para apoyar la operación de sus negocios no se propaga entre las PyMEs, si por el otro lado no tenemos suficientes cuadros técnicos que estén egresando de las diversas opciones educativas en el país para satisfacer las necesidades de los CDSs, y si además tenemos un marco regulatorio incipiente para la creación de dichos centros con todo y los recursos requeridos, pienso que no habrá forma de exportar a los niveles que ProSoft se propone lograr en algunos años.

Deben primero generarse las condiciones internas en el país, que ayuden a madurar el modelo de negocios propio, que no copie o imite a otros países, para que en segundo término podamos incidir en exportaciones de productos de software. No podremos atraer suficientes inversiones en este sentido si no hay demanda interna y no hemos po-dido afinar un esquema de producción requerido para el exigente mercado exterior.

Estamos ante una oportunidad histórica de coordinar es-fuerzos, que esperamos nos rindan los frutos deseados. Nos debemos de poner a trabajar para orquestar un en-foque viable. Existe la necesidad y se requiere actuar a tiempo para cubrirla. La consolidación de CDSs en el país presenta un gran potencial económico y de desarrollo que no debe ser pasado por alto.

- Ralf Eder

El Dr. Ralf Eder Lange es Profesor Consultor-Extensionista del Departamento de Sistemas de Infor-mación en el Tec de Monterrey, Campus Estado de México, donde ha sido Direc-tor de los Programas de Graduados en Ciencias Computa-cionales y Sistemas de Información, y Director del Centro de Investigación en Infor-mática. Sus áreas de especialidad incluyen Reingeniería de Procesos y Adminis-tración de Innovación Tecnológica. Ralf es miembro fundador de la Asociación Latinoa-mericana y del Caribe de Sistemas de Infor-mación (LACAIS).


CÁTEDRA Y MÁS

ReferenciasFábricas de software: "Cómo se inventa una nueva industria" www.microsoft.com/mexico/gobierno/entrevistas/Rocio_Ruiz.aspVarela, Rogelio. "CANIETI propone inversión en TI para elevar productividad"www.canieti.net

En muchas ocasiones nos encontra-mos desarrollando aplicaciones donde toda las reglas del negocio, accesos a fuentes de datos y hasta código de presentación se encuentran en una sola clase, librería o, peor aún, en una sola página (hablando de JSP, ASP o similar). La experiencia nos ha demos-trado que estas aplicaciones son muy difíciles de mantener y casi imposibles de reutilizar adecuadamente.

SoluciónEl patrón MVC consiste en separar las diferentes responsabilidades en una aplicación, en elementos de tres tipos:

• Modelos que contengan el estado (da-tos) y los mecanismos para alterarlo.• Vistas que desplieguen información o la comuniquen a otros sistemas.• Controles que administren los eventos que afectan a los modelos y escojan las vistas adecuadas para desplegar los resultados.

Esto se aprecia en la siguiente figura.

AplicacionesEl MVC es muy útil cuando tenemos componentes o subsistemas con una o más de las siguientes características:

• Requiere desplegar su información en diferentes tipos de clientes. La figura 2 muestra un ejemplo de un sistema que requiere proveer infor-mación a través de clientes web, mó-viles, applets y web services.

• Tiene múltiples comportamientos debido a distintos usos que se pu-edan dar a la lógica de negocios.

• Se requiere readaptar o reutilizar bajo distintas circunstancias con un mínimo de trabajo adicional.

Ventajas y desventajasEl patrón MVC proporciona una forma excelente de hacer que un elemento sea flexible y adaptable a distintas situaciones. Esta flexibilidad puede ser aprovechada ya sea de manera estática o dinámica. Estática cuando se agregan nuevas clases de vistas o controladores, y dinámica cuando los objetos de vista o controlador se escogen en tiempo de ejecución.

Usualmente, el mayor desafío del MVC consiste en determinar la base;es decir, definir interfaces adecua-das para que interactúen modelo, vistas y controlador. A menudo, como en la mayor parte del software, un elemento MVC se desarrolla para satisfacer un conjunto específico de

necesidades. Es por esto que se ne-cesita visión y un análisis cuidadoso para implementar el elemento de forma que no se impongan restric-ciones específicas a una aplicación sobre él.

Variaciones del PatrónLas variaciones del MVC suelen girar en torno a las diferentes opciones de implementación para las vistas.

• Push vs. Pull.– Un esquema “push” (empujar) es aquel en que el modelo envía actualizaciones de datos hacia las vistas, mientras que “pull” (jalar) es cuando las vistas obtienen infor-mación del modelo conforme lo van requiriendo.• Vistas múltiples.– Un modelo pue-de proporcionar información a más de una vista. Esto resulta muy útil en algunas implementaciones de in-terfaces gráficas, porque los mismos datos deben llevar algunas veces a distintas representaciones.• Vistas de sólo lectura.– No todas las vistas necesitan un controlador. Algunas proporcionaran sólo una represtación visual de los datos del modelo, pero no soportan ningún cambio en el modelo.

Con esto concluimos nuestro estu-dio acerca de este patrón. Espera-mos que les traiga beneficios en sus próximos proyectos.

En general, un patrón es la descripción de una solución a un problema común. En el de-sarrollo de software se utilizan mucho los patrones, ya que nos permiten aprovechar y replicar las soluciones que los expertos han generado. Uno de los patrones más comunes y utilizados en las aplicaciones de software modernas es el patrón Modelo-Vista-Contro-lador (Model-View-Controller en inglés), conocido por sus siglas como MVC. Alfredo López nos explica cuál es el problema que resuelve este patrón y cómo es que lo logra.

Referencia:Stelting, Stephen & Maassen, Olav. Applied Java Patterns.Prentice Hall, 2002


FUN

DA

ME

NTO

S

El Patrón MVCSeparando Responsabilidades para Brindar FlexibilidadPor Alfredo I. López

Si la llave no está conectada o la respuesta es incorrecta, la aplicación no se ejecuta o se ejecuta en modo restringido, de acuerdo a la configuración. Esta verificación se reali-za continuamente durante la ejecución de la aplicación, y cada vez se envía un mensaje diferente para evitar su emulación. De he-cho, en los dispositivos más avanzados, la mitad de los mensajes son falsos, para así despistar a los crackers.

Algunos de estos productos cuentan con características avanzadas como relojes de tiempo, actualización remota y memoria no volátil, para almacenar información de dife-rentes aplicaciones. Estas características per-miten restringir la ejecución del software de diferentes formas, ya sea por tiempo, usua-rios concurrentes, o acceso a componentes específicos. Todo esto facilita la implementa-ción de diferentes modelos de licenciamiento, como renta de software, pago por uso, demos y compra por Internet, permitiendo así que los productores de software lleguen a más clien-tes potenciales sin tener que preocuparse por la protección de sus productos.

Las llaves normalmente se venden junto con un kit de herramientas para desarrollo —utilerías y APIs para que la aplicación de software pueda interactuar con la llave—. Antes de adquirir una solución de este tipo es importante asegurarse de que el kit de desarrollo soporte el lenguaje y ambiente deseados. Para casos en los cuales no se cuenta con el código fuente de una aplica-

ción o no se desea modificar éste, algunos pro-veedores ofrecen utilerías que pueden agregar una capa de seguridad a aplicaciones existen-tes, forzándolas de esta manera a requerir de una llave para su ejecución.

Las generaciones anteriores de los candados se conectaban a través del puerto de la im-presora, lo cual llegaba a provocar problemas de compatibilidad, sin embargo, las nuevas generaciones se conectan a través del puerto USB, facilitando así implantar esta solución en ambientes multiplataforma.

Dado el incremento de la piratería en nuestro país, es necesario implementar mecanismos dentro de nuestros desarrollos que prote-jan nuestra propiedad intelectual, nuestro modelo de licenciamiento y sea adaptable a cambios del mismo. Una solución que cumple con todos estos requisitos y ofrece una implementación sencilla y robusta son los candados o llaves físicas. Estos no sólo ofrecen una protección contra el uso ilegal de nuestro software, sino que tienen una fle-xibilidad asombrosa para el diseño de mo-delos de ventas y licenciamiento.

En el mercado existen diferentes marcas de estos productos. Típicamente se diferencian entre sí por la facilidad de adopción y nivel de protección que ofrecen. Las dos marcas líderes a nivel mundial son Sentinel de Safe-Net y HASP de Aladdin. Ambas tienen distri-bución en México y Latinoamérica.

L as grandes compañías de software han implementado nuevos esquemas de licencia-

miento y creado mecanismos de activa-ción de productos, como la distribución de actualizaciones o patches para con-trolar el software pirata. ¿Qué tipo de solución podemos adoptar aquellos desarrolladores que no contamos con la infraestructura de las grandes com-pañías? ¿Cómo podemos implementar mecanismos que no limiten la funcio-nalidad de nuestras aplicaciones y lo-gren protegernos de la piratería?

Una solución fácil de implementar y de gran robustez son los candados o llaves físicas. Esta solución se basa en hardware que se integra con aplicacio-nes de software. Este candado se distri-buye a los usuarios finales junto con la licencia de software. La aplicación pro-tegida verifica la presencia de esta llave durante la ejecución para asegurar que el software se utilice dentro de los pa-rámetros acordados en la licencia.

Estas llaves contienen un motor de cifrado impenetrable y de alta seguri-dad. Durante la ejecución, el software protegido envía secuencias cifradas que la llave descifra produciendo una respuesta que no se puede emular. Si la respuesta de la llave es correcta, la aplicación sigue funcionando.


TECNOLOGÍA

La piratería es un mal que aqueja a todas las compa-ñías dedicadas al desarrollo de software. Recientes estudios de la BSA (Business Software Alliance) in-dican que la piratería de software en México se ubi-ca en 56% y que va en aumento. En un estudio de impacto económico de abril de 2003, IDC concluyó que la reducción de la piratería en 10 puntos porcen-tuales en cuatro años agregaría más de un millón de nuevos trabajos y generaría 400 mil millones de dó-lares en crecimiento económico mundial.

Candados de HardwareProtección y FlexibilidadPor Ariel García

TECNOLOGÍA

ATI

FireGL X3-256El mercado de las estaciones de trabajo no es muy grande; los principales consumidores son los usuarios de CAD/CAM y las compañías de ingeniería y diseño. Las tarjetas de video que se utilizan en estas aplicaciones usualmente alcanzan precios muy altos, pero al ser el componente de hardware que puede mejorar el desempeño de un equipo de manera dramática, el costo es secundario. La ATI FireGL X3-256 es una tarjeta diseñada con las estaciones de trabajo de ran-go medio en mente, pero con el desempeño necesario para darle batalla a las más avanzadas en un par de pruebas. Ideal para trabajar con shaders HLSL o en el desarrollo de aplicaciones con animaciones complejas, esta es una opción de buen precio —alrededor de $800 dólares—, y ofrece una solución, por lo menos hasta que las tarjetas basadas en PCI Express se convierten en el estándar.

Buffalo

LinkStationEste pequeño disco duro es la propuesta de Buffalo Techno-logy al problema de almacenamiento que vivimos diariamen-te ya sea en el trabajo o en casa. Con capacidades desde 120 y hasta 300GB, el LinkStation se puede instalar fácilmente en cualquier red local vía ethernet o Wi-Fi, opera con un sim-ple pero efectivo sistema que permite a los usuarios utilizar un navegador para revisar los archivos almacenados.

Cuenta con dos puertos USB 2.0 para conexión directa y, dependiendo del modelo, también incorpora un servidor de impresión y un FTP, además se puede configurar para auto respaldar la información contenida en otro LinkStation o cualquier computadora de la red, por medio de calenda-rios predefinidos. Su fuente de poder es de bajo consumo de energía y además se puede programar para encendido y apagado automático.

Apple

Mac MiniLo más impresionante de la reciente MacWorld Expo, celebrada en enero pasado, fue la presentación de Mac Mini, la propuesta de Apple para competir en el mercado de las PCs de escritorio de precio acce-sible. Con un diseño minimal y todo el estilo tradicional de la mar-ca, esta computadora integra un procesador G4 de 1.25 ó 1.42GHz, disco duro de hasta 80GB, unidad CD-R/DVD-ROM y 256MB en RAM —expansible hasta 1GB—, en un espacio breve.

Dos puertos USB 2.0, un Firewire, entrada DVI/VGA, módem integrado y puerto ethernet 10/100 Base T, complementan la oferta, precisamen-te haciendo gala de un precio reducido; a pesar de esto, la Mac Mini tiene poder suficiente para trabajar con todo tipo de aplicaciones para desarrollo e incluso con software para diseño. Obviamente el paque-te no incluye monitor, teclado y mouse, pero es prudente aclarar que cualquier marca de periféricos funciona con la Mac Mini, con lo cual se puede obtener un equipo de buena capacidad por un bajo precio. Para los que necesiten algunas otras características, es posible incluir un SuperDrive (DVD-R/RW), Bluetooth integrado y una tarjeta AirPort Extreme para trabajar en redes Wi-Fi.


02 Software Factories: Assembling Applications

with Patterns, Models,Frameworks and ToolsJack GreenfieldWiley, Agosto 2004

No podrán negar que el mero título de este libro es bastante atractivo. La idea de en-samblar aplicaciones de software de una manera industrializada, apoyándose en patrones, modelos, marcos de referencia y herramientas, ha sido un tema recurrente de los últimos años. Tanto así que abarca el tema central de éste número de SG.

El autor principal de esta obra es Jack Greenfield, un reconocido Guru de la industria. Actualmente Jack es arquitecto de herramientas empresariales en Microsoft, y es la mente maestra detrás de Vi-sual Studio Team System, la próxima generación de herramientas de software de Microsoft para el desarrollo de software en equipo. Antes de eso Jack fue arquitecto en jefe en Rational Software

y también fue uno de los principales colaborado-res en el desarrollo de UML y J2EE.

En Software Factories el Sr. Greenfield y Cía. describen una nueva visión para el desarro-llo de software. Actualmente esta es una actividad altamente intensiva en mano de obra, que depende de una cantidad limitada de desarrolladores talentosos. Conforme la demanda de software global supere la capa-cidad de esta fuerza laboral, los métodos ac-tuales de desarrollo serán reemplazados por métodos automatizados, haciendo el desa-rrollo de software más rápido y barato.

Como explicamos en el artículo principal de este número, el término “Fábricas de Software”, se hizo popular hace unos años, aunque para mu-chas empresas simplemente significaba desa-rrollar software fuera de las instalaciones del cliente. En el caso de este libro, las fábricas de software representan un concepto mucho más completo y maduro, donde juegan un rol cru-cial los procesos y las herramientas.

En general, Software Factories es un libro in-teresante con contenido valioso para todos aquellos que dirigen áreas de sistemas o centros de desarrollo de software.

BIBLIOTECA


describe soluciones a diferentes problemas posibles. Conforme se vayan encontrando con tales problemas, entenderán las soluciones recomendadas y apreciarán su valor.

Uno de los inconvenientes de Design Patterns, es que dado que data de 1995, los ejemplos están modelados en una no-tación pre-UML y varios de los ejemplos de código están en Smalltalk. Si esto no es de su agrado, pueden recurrir al libro “Applied Java Patterns” de Stephen Selting, el cual describe los mismos patrones que el GoF (y otros más), modelados en UML y con ejemplos de código en Java. Design Patterns está disponible tanto en formato impreso como en edición electró-nica (CD-ROM). Adicionalmente existe una edición en español, pero solamente fue publicada en España.

01Design Patterns: Elements of Reusable Object Oriented DesignErich Gamma, Richard Helm, Ralph Johnson , John Vlissides

Addison Wesley, Enero 1995

Dado que en este número hemos comenzado a hablar de patrones, y con la esperanza de que haya quienes quieran aprender más so-bre el tema, les recomendamos este excelente libro que es consi-derado la biblia de patrones de diseño.

Citando a los autores, podemos decirles lo siguiente: “Cuando entiendan los patrones de diseño y digan ¡Aha!, en lugar de ¿Huh?, podrán diseñar sistemas más flexibles, modulares y reutiliza-bles, que a fin de cuentas es la razón por la que nos interesa la tec-nología orientada a objetos”. Debido a su largo nombre, este libro es comúnmente llamado como el “Gang of Four” o “GoF”, haciendo refe-rencia al cuarteto de autores. Así que si alguna vez alguien les pregunta sobre el “GoF”, ya saben de que les están hablando.

Les avisamos que el GoF no es un libro que puedan leer y pretender entender por completo a la primera. Es un material de referencia que

Recomienda un libro para esta sección, escribe a:

[email protected]

INDEX

Anunciante Páginas Sitio

AMCIS 47 www.amcis.org.mxAvantare 39 www.avantare.come-Quality 37 www.e-quallity.netGartner 07 www.gartner.comIBM F4 www.ibm.com/mxImexsoft 17 www.imexsoft.com.mxInnevo 09 www.innevo.comIntersoftware 11 www.intersoftware.com.mxItera 31 www.itera.com.mxMayen PM 15 www.mayen-project.com.mxMicrosoft F2-1 www.microsoft.com/mexicoSsistemas 26 www.ssistemas.comSofttek 35 www.softtek.comTec de Monterrey F3 www.itesm.mxTENEMOS UN ESPACIO

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

DIRECTORIO


de Proyectos, para ello deberán acumular al menos 60 Professional Development Units (PDUs) durante cada ciclo. El primer ciclo de un PMP termina el 31 de Diciembre del tercer año completo siguiente a su fecha de examen. Por ejemplo, una fecha de examen del 31 de Julio de 2004 tendría una fecha de expiración del 31 de Diciembre de 2007. El resto de los ciclos tiene una duración de tres años exactos iniciando al primer día de la expiración del ciclo anterior.

¿Qué son los PDUs?Es una unidad de medida utilizada para cuantificar el aprendizaje y actividades pro-fesionales relacionadas con la Dirección de Proyectos. Generalmente un PDU se obtiene por cada hora invertida en el aprendizaje o actividad profesional. Los PDUs están orga-nizados en cinco categorías:1. Educación Académica Formal.2. Actividades Profesionales y Auto-estudio.3. Educación recibida por REPs (Registered Education Providers).4. Educación recibida por otro proveedor.5. Servicio Voluntario a Organizaciones Profesionales o a la Comunidad.

Requisitos para Obtener la Certificación como PMPSe deben cubrir los siguientes requisitos:Educación y ExperienciaCategoría 1 • A la fecha de aplicación del examen, el candidato cuenta con un título profesional o el equivalente en su país. • Demostrar un mínimo de 4,500 horas de experiencia en Dirección de Proyectos con participación en los cinco Grupos de


CA

RR

ER

A

Project Manager ProfessionalLa Certificación para Directores de ProyectoPor Ramón Hernández

Ramón Hernández es gerente de proyecto con más de diez años de experiencia en Tecnología de Información, concentrado en proyectos para el sistema financiero. Ramón es PMP certificado desde 1999 y colabora en el capítulo del PMI en la Ciudad de México.

La certificación de PMP (Project Management Professional) es la credencial más importante para los individuos relacionados con la pro-fesión de Dirección de Proyectos, otorgada desde 1984 por el PMI (Project Management Institute), fundado en 1969 y reconocido como la asociación más importante a nivel mundial relacionada con la Dirección de Proyectos. El examen para obtener esta certificación está

basado en un estándar aceptado por la comunidad relacionada, llamado “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”, la traducción oficial al español se llama “Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK®)”.

Datos Enero 2005

MEMBRESIATotal de miembros 153,952

Total de países con miembros 146

COMPONENTES239 Capítulos - Grupos de miembros del PMI que

se localizan en un área geográfica específica.

31 SIGs (Specific Interest Groups) - Grupos de

miembros del PMI de industrias similares.

2 Colleges - Grupos de miembros del PMI

interesados en el estudio detallado de un área

de conocimiento.

INDUSTRIAS CON MAYOR NÚMERO DE MIEMBROS Tecnología de Información 22,172

Hardware/Software 21,551

Servicios Financieros 9,377

Servicios de Administración

de Negocios 9,088

Telecomunicaciones 9,000

CERTIFICACIÓNTotal de PMP’s 105,088

Procesos (Iniciación, Planeación, Ejecución, Seguimiento y Control, y Cierre) demostran-do una experiencia de al menos tres años. • Haber tomado 35 horas de capacitación re-lacionada con la Dirección de Proyectos. Las horas deberán incluir las nueve Áreas de Conocimiento de la Dirección de Proyectos (Calidad, Alcance, Tiempo, Costes, Recursos Humanos, Comunica-ciones, Riesgos, Adquisiciones e Integración).

Categoría 2 • A la fecha de aplicación del examen, el candidato no cuenta con un título profesional o equivalente, pero tiene al menos estudios de nivel medio superior o el equivalente. • Demostrar un mínimo de 7,500 horas de experiencia en Dirección de Proyectos, en los cinco Grupos de Procesos, demostrando una experiencia de al menos cinco años. • Haber tomado 35 horas de capacitación relacionada con la Dirección de Proyectos.

Aceptar el Código de Ética del PMI, que bá-sicamente contiene las responsabilidades para con la profesión, y las responsabilida-des para con los clientes y la sociedad.

Aprobar el Examen de Certificación como PMP, el cual se presenta en computadora en cualquiera de los sitios autorizados por el PMI. Para una lista completa visitar www.2test.com. En el caso de México, se cuenta con tres luga-res, ubicados en la Ciudad de México, Guada-lajara y Monterrey. El examen comprende 200 preguntas de opción múltiple, y para acreditar se requiere acertar 137 preguntas. Es posible presentar el examen en idioma español.

Requisitos para Mantener la Certificación como PMPAquellos individuos que hayan conseguido la certificación de PMP deberán demostrar su compromiso continuo con la Dirección

ConclusiónComo se puede apreciar en las estadís-ticas del PMI, la industria de TI han dado un gran impulso a la profesión de la Di-rección de Proyectos. México no podía quedarse atrás en esta gran iniciativa y en 1996 inició operaciones el PMI Capí-tulo México, que desde sus inicios se ha dedicado a promover la profesión de la Dirección de Proyectos en México.

ReferenciasThe Project Management Institute (PMI)www.pmi.org PMI Capítulo Méxicochapter.pmi.org/mexico/

Año

01

No.

02

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

M

arzo

-Abr

il 2

005

EN SERIE - desquer.ens.uabc.mxdesquer.ens.uabc.mx/afi/articulos/SG05_2_mar_abr.pdf · EN SERIE...

Documents

Transcript of EN SERIE - desquer.ens.uabc.mxdesquer.ens.uabc.mx/afi/articulos/SG05_2_mar_abr.pdf · EN SERIE...