SG #05 (Septiembre - Octubre 2005) by Revista Software Guru

• Conﬁabilidad del Software • ebXML • Administración con Cadena Crítica

Software Guru CONOCIMIENTO EN PRÁCTICA Año 01 No.05 • Septiembre-Octubre 2005 • www.softwareguru.com.mx

ENTREVISTA:

Rafael Funes Director de Dynaware

CASO DE ESTUDIO:

Pruebas Controladas

de MoProSoft

Inteligencia Artiﬁcial Base Tecnológica de las Empresas

MIPS para llevar

Desarrollo de Aplicaciones Móviles

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

PROGRAMACIÓN:

J2ME

DIRECTORIO Edición Ejecutiva Pedro Galván

EDITORIAL

Coordinación Editorial Mara Ruvalcaba Edición y Producción Edgardo Domínguez Dirección de Arte Oscar Sámano Ilustración Luis Pérez

“Para el año 2009, más de la mitad de los microprocesadores fabricados en el mundo estarán destinados a dispositivos móviles. “ “El software que hará realmente útiles a los dispositivos móviles todavía no es desarrollado.” Para la mayoría de la gente, este par de aﬁrmaciones no son algo más que un dato curioso. Sin embargo, para los lectores de SG, la situación es diferente. No son un dato curioso, sino una oportunidad, ... una gran oportunidad. Por ello en este número hemos incluido diversos artículos para ayudarlos a iniciarse en el desarrollo de aplicaciones móviles. Hemos buscado abarcar diferentes plataformas y perspectivas, para darles un panorama lo suﬁcientemente amplio. Esperamos que sea de su agrado, pero sobre todo que les sea de utilidad. Estamos muy orgullosos porque ya tenemos Norma Mexicana de Software. Estamos convencidos de que esto es ya un diferenciador para la industria mexicana de software, que demuestra nuestro nivel de competitividad. Felicidades a todos los involucrados en este esfuerzo. La entrevista de este número es con Rafael Funes. Como ustedes saben, el negocio de la mayoría de las empresas mexicanas de software gira alrededor de proveer servicios a la medida o revender productos desarrollados en otros países. Desgraciadamente son muy pocas las empresas locales que logran desarrollar y comercializar exitosamente productos de software. Dynaware, empresa que preside Rafael, es una de ellas. Durante su entrevista, Rafael comparte con nosotros las razones por las que decidió formar una empresa basada en productos, y los retos que ha encontrado a lo largo del camino. Le damos las gracias a Rafael, Ignacio Gallegos y Heidy Obregón por el tiempo y asistencia que nos brindaron. Agradecemos el entusiasmo de todos los colaboradores que se interesaron en participar en este número. Gracias a Sean Maloney y el equipo de Intel México. A todos los lectores les pedimos que por favor nos hagan llegar su retroalimentación y comentarios a través del sitio web, o en editorial@softwareguru.com.mx Equipo Editorial

SEP-OCT 2005

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 - ITESO Colaboradores Ariel García, Jorge Palacios, Paulina Olivares, Rodolfo García, Hector Obregón, Oscar Esqueda, Ulises Martínez, Ángel Mendoza, Amaury Perea, Jorge Jasso, Claudia Alquicira, Angelica Su, Víctor Quijano, Martín Olguín, Atanacio Reyes, Sergio Orozco, Mariana Perez-Vargas, Cuauhtémoc Lemus, Enrique Villa, Joaquín Arellano, Jorge Becerril, Luis Daniel Soto, J. Antonio García, Christian P. García, Omar Ruvalcaba Ventas Claudia Perea Marketing Natalia Sánchez Contacto info@softwareguru.com.mx +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: 042004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en agosto de 2005 en Litográfica Roma. Distribuido por Sepomex.

www.softwareguru.com.mx

contenido sep-oct 2005

número 05

EN PORTADA

Desarrollo de Aplicaciones Móviles

Elementos a considerar en el desarrollo de software para PDAs y teléfonos celulares: tecnologías, plataformas y perspectiva de la industria.

Productos

Inteligencia Artiﬁcial

14 Base Tecnológica de las Empresas

Prácticas

LO QUE VIENE Tivoli CDP, SQL Server 2005 y Red Hat Network

NOVEDADES Windows Vista

PROGRAMACIÓN Java 2 Micro Edition (J2ME)

Víctor Quijano nos enseña como hacer un "Hola Mundo"en J2ME.

ARQUITECTURA ebXML

Entrevista 18 Rafael Funes, Director de Dynaware

En la primera parte de esta serie de dos artículos, Atanacio Reyes explica en que consiste ebXML y cuales son sus pilares.

Columnas Tejiendo Nuestra Red por Hanna Oktaba

Mejora Continua por Luis Cuellar

Prueba de Software por Luis Vinicio León

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

ADMINISTRACIÓN DE PROYECTOS Cadena Crítica

Martín Olguín comparte los secretos de la administración de proyectos utilizando cadena crítica.

PROCESOS De SW-CMM a CMMI

Mariana Perez-Vargas nos habla sobre CMMI y la transición desde SW-CMM.

ASEGURAMIENTO DE CALIDAD Conﬁabilidad del Software

En Cada Número 42

¿En qué consiste la conﬁabilidad del software? ¿Como se mide? Esto y más nos responde un grupo de investigadores del CIMAT.

www.softwareguru.com.mx

Caso de Estudio 28 Pruebas controladas de MoProSoft

Noticias y Eventos UML Fundamentos Tecnología Carrera

04 46 48 50 56

SEP-OCT 2005

NOTICIAS

Noticias XpoLinux 2005 Del 11 al 13 de agosto tuvo lugar XpoLinux 2005 en la Ciudad de México, cuyo objetivo fue mostrar a los empresarios y gerentes de sistemas que Linux y el software libre son una opción viable para utilizar en las empresas. Una de las conferencias centrales fue la otorgada por Jon “maddog” Hall, de Linux International, una organización que promueve el uso de Linux a nivel mundial. Durante su plática, maddog mostró diferentes escenarios de negocio donde Linux es utilizado actualmente, desde sistemas embebidos en cajeros automáticos, hasta clusters de supercomputadoras para procesamiento masivo de información. Entre otros conferencistas presentes, estuvieron Carlos Muñoz, de Linux Center Latinoamérica, Alfredo Santana, quien habló sobre los nuevos Centros de Soluciones Linux, y Jose Luis Chiquete de la Asociación Mexicana de Software Libre.

MoProSoft: Alto desempeño

a bajo costo

El pasado 12 de agosto se llevó cabo el evento “MoProSoft: Alto desempeño a bajo costo para empresas Mexicanas de Software”, con el objetivo de presentar a MoProSoft como la norma mexicana para la industria de software que: • Da resultados con un esfuerzo y costo razonable. • Permite avanzar hacia la adopción de CMM-I. • Provee una alternativa para seleccionar proveedores de desarrollo de software. Al evento acudieron más de 200 personas de 17 diferentes estados de la República, provenientes de la empresa privada, academia y entidades de gobierno. Durante el evento se contó con exposiciones por parte de la Dra. Hanna Oktaba, Ana Vázquez y Francisco López Lira de la AMCIS, e Ivette García de la Secretaría de Economía. Se llevaron a cabo interesantes paneles en los que participaron representantes de empresas como ARTEC, E-Genium, Magnabyte, SGA, ITERA, Kernel, Innevo, Ultrasist, ESI Center, entidades federativas como SEP, SER, CJF, y consultores independientes. Para mayor información, visita: www.amcis.org.mx

SEP-OCT 2005

ProSoft El 12 de agosto Aguascalientes fue anfitrión del Evento “Mejores prácticas del ProSoft y el Desarrollo de la Industria de Tecnologías de Información en México”, con la visión de desarrollar y fortalecer la Industria de TI como aceleradora de la economía del país. El evento fue presidido por el Dr. Armando Jiménez Sanvicente, Secretario de Desarrollo Económico de Aguascalientes, y el Lic. Javier Díaz Guerra, Presidente del “Cluster de Tecnologías de Información de Aguascalientes”, Innovatia, con la presencia de Sergio Carrera Riva Palacio, Director General de Comercio Interior y Economía Digital de la Secretaría de Economía. Participaron representantes de Chiapas, Distrito Federal, Durango, Estado de México, Guanajuato, Jalisco, Nuevo León, Oaxaca, Querétaro, Quintana Roo, Tamaulipas, Tlaxcala, Veracruz, Yucatán y Zacatecas. La primer parte fue la realización de paneles, tratando temas como: las mejores prácticas de las empresas desarrolladoras de software; el éxito de las empresas al invertir en las TI; el ofrecimiento para las Pymes; y, los canales de distribución. La segunda parte del evento fue la presentación de las mejores prácticas de los clusters consolidados, que han sido apoyados por ProSoft, entre ellos Jalisco, Yucatán y Aguascalientes. Los conceptos en que se han aplicado los apoyos de ProSoft son incubación de empresas, capital humano, y capacidad de procesos.

Décimo Congreso de CANIETI El Décimo Congreso de CANIETI: Innovación, la clave para avanzar, celebrado en Vallarta el pasado 29 y 30 de Julio, contó con una gran participación de empresas y organismos. El primer día de actividades se llevó a cabo una mesa redonda, con el tema “Desarrollo de la Industria de Software en Jalisco”, y donde se identificaron acciones para el desarrollo de la industria, y se incluyeron en el plan de trabajo de la Vicepresidencia de Software. Durante el segundo día se llevaron a cabo tres conferencias, la primera mostrando el avance de la política estatal de ciencia y tecnología, la segunda respecto al avance de ProSoft, y la tercera fue una excelente conferencia presentada por Rodolfo Bermejo con el tema “La innovación Tecnológica y la Apertura Comercial de la India”. Posteriormente Ricardo Gómez presentó siete casos de éxito de la Industria de Software en Jalisco. Para mayor información, visita: www.canieti.org www.softwareguru.com.mx

Eventos 5 y 6 Septiembre 2005

12 al 15 Octubre 2005

Centro Banamex, Cd. de México Info: www.idc-eventos.com/cumbregobierno05 Tel: (55) 5661 - 3791 e-mail: mmunoz@apsis.org.mx

Hotel Presidente Intercontinental. Monterrey, NL Info: www.canieti.org Tel: 01 (55) 5264 0808 e-mail: afuertes@canieti.com.mx

17 al 22 Septiembre 2005

17 Octubre 2005

Moscone Center. San Francisco, California Info: www.oracle.com/openworld e-mail: OpenWorld@eventreg.com

World Trade Center, Cd. de México Info: www.idc-eventos.com/directions05 Tel: (55) 5523 9910

21 Septiembre 2005

18 y 19 Octubre 2005

Centro Banamex. Cd. de México Info: www.idc-eventos.com/ip05 Tel: (55) 5661 - 3791 e-mail: mmunoz@apsis.org.mx

World Trade Center, Cd. de México Info: www.congresoamiti.com Tel: (55) 5523 9910

1ra. Cumbre de Gobierno y Tecnología – IDC

Oracle Open World

IP Business Communications Conference 2005 - IDC

XXVI Convención Nacional Anual CANIETI

Directions 2005 – IDC

Congreso AMITI 2005 – TI Evolucionando los Negocios

23 al 26 Octubre 2005 26 al 30 Septiembre 2005

Encuentro Internacional de Ciencias de la Computación Universidad Autónoma de Puebla. Puebla, México Info: www.enc.smcc.org.mx Tel: (222) 229 21 38 e-mail: smcc@mail.udlap.mx

II Conferencia Latinoamericana de Interacción Humano-Computadora ITESM, Cuernavaca, Morelos Info: www.clihc2005.org e-mail: clihc2005-registration@create-net.it

26 al 28 Octubre 2005 7 Octubre 2005

Seminario Admón. Integral de TI con ITIL y Creando una Oficina de Proyectos Práctica y Efectiva Itera. Cd. de México

XVIII Congreso Nacional y IV Congreso Intl. de Informática y Computación ANIEI Universidad Autónoma de la Laguna. Torreón, Coahuila Info: www.aniei.org.mx Tel: (871) 729 0101 e-mail: aniei@ual.mx

Info: www.itera.com.mx Tel. (55) 5281 7670 e-mail: contactsalescenter@itera.com.mx

Lanzamiento de TI Sonora En las instalaciones del Instituto Tecnológico de Sonora, Alberto Reyes Pinedo, director del Proyecto de Fortalecimiento de la Industria del Software en Sonora, dio el banderazo de inicio para las actividades del conglomerado de empresas y universidades conjuntadas en TI Sonora. La conforman 60 empresas que producen distintos tipos de software y 12 universidades. Manuel Rivera Ibarra, Director Ejecutivo de TI Sonora, subrayó que uno de los objetivos de este proyecto es generar cinco mil empleos en el Estado de Sonora, que se espera sean ocupados www.softwareguru.com.mx

por los egresados de las universidades locales. Mencionó que varias de las empresas que integran la asociación ya están exportando software, y que se tienen alianzas con empresarios de Arizona, con quienes comercializan productos y servicios relacionados con el software. De acuerdo con un estudio realizado por la Secretaría de Economía, el estado de Sonora está entre los cinco estados con mayor potencial de desarrollo de la industria del software. Para mayor información, visita: www.tisonora.org SEP-OCT 2005

COLUMNA

TEJIENDO NUESTRA RED

MoProSoft

Nuestra Ventaja Competitiva

La Dra. Hanna Oktaba es profesora en la Facultad de Ciencias de la UNAM. Es fundadora y vicepresidenta de la Asociación Mexicana para la Calidad en la Ingeniería de Software. Actualmente dirige el proyecto con el cual se creó la norma mexicana para la industria de software.

l 5 de julio fue aprobada por el NYCE la norma mexicana Tecnología de la Información-Software-Modelos de procesos y evaluación para desarrollo y mantenimiento de software Parte 01: Definición de conceptos y productos, Parte 02: Requisitos de procesos (MoProSoft), Parte03: Guía de implantación de procesos, Parte 04: Directrices para la evaluación (EvalProSoft). En estas fechas ya debe ser disponible a través del NYCE. El trabajo creativo de tres años de varias personas se volvió realidad. Ahora empieza otra etapa, mucho más difícil, de acercar la norma a las empresas y de convencerlas que la usen, no por la obligación, sino por su propio bien. Como dice el refrán, nadie es profeta en su tierra, por lo tanto decidí contarles algunos eventos que me han sucedido, o de los que me he enterado, en los últimos meses para animar a los escépticos de echarle un ojo a MoProSoft, por lo menos por curiosidad. Abril 2005. Software Engineering Institute (SEI), a raíz de las discusiones en las primeras reuniones del International Process Research Consortium, decide organizar un Workshop adicional dedicado a Process Improvement in Small Settings. Para mí esto es una evidencia de que se están dando cuenta que el “mercado” de micro y pequeñas empresas (o grupos) no está atendido debidamente. Como se pueden imaginar, mandé el resumen de nuestro trabajo de la norma mexicana y ya me informaron que fue aceptado. Así que en octubre de este año presentaremos a MoProSoft, EvalProSoft y los resultados de pruebas controladas en la “sociedad” o, si prefieren, “en la cueva del león”, es decir, en la sede del SEI en Pittsburg. Junio 2005. La red académica iberoamericana Ritos2, a la cual pertenezco desde el año 2000, convoca a una reunión en Montevideo donde se decide crear un proyecto para definir un marco metodológico común de procesos y su evaluación para la industria de software de esta zona. Para mi sorpresa, los argentinos, españoles, chilenos, venezolanos, brasileños, colombianos, paraguayos y ecuatorianos quieren probar MoProSoft y EvalProSoft para ver si se adaptan a sus contextos. Todos están de acuerdo que se necesita algo más apropiado para nuestra forma de pensar y trabajar. El proyecto se presentará en septiembre al Programa Iberoamericano de CYTED (Ciencia y Tecnología para el Desarrollo) y, en el caso de ser aprobado, durante los próximos tres años vamos a probar lo “Hecho en México” en los países con idiosincrasia similar. Junio 2005. Un colega brasileño, a quien le gustó MoProSoft cuando lo presenté en el evento de SEPG LA en Guadalajara en noviembre pasado, me mandó un mensaje desde Helsinki. Resulta que en esta bella y tranquila ciudad, se

SEP-OCT 2005

llevó a cabo una reunión rutinaria del grupo de trabajo SC7 de ISO/IEC, en la cual se decidió crear un nuevo proyecto para una norma internacional de Software Life Cycle Proﬁles and Guidelines for use in Very Small Enterprises (VSE). Este trabajo será dirigido por un tailandés. El objetivo del mensaje del brasileño fue preguntarme si se podría usar el documento de MoProSoft como uno de los puntos de partida para este trabajo. No tengo que explicarles que me quedé con los ojos cuadrados. Tanta coincidencia de interés en procesos de software para la pequeña industria en tantos lugares distintos es de pensarse. Lo bueno de esto es que en muchos lugares apenas quieren empezar a cocer las habas y nosotros ya las tenemos medio cocidas. ¿Será esta nuestra oportunidad? En México, en el mismo junio de 2005, tuve la oportunidad de experimentar el primer taller de interpretación de MoProSoft en Mexicali. A pesar de muy altas temperaturas, encontré un entusiasmo y una dedicación sorprendente. Los participantes provenían del triangulo bajacaliforniano Mexicali-Tijuana-Ensenada y representaban a la academia, las empresas y el gobierno. Lo que más me gustó de ellos fue su entendimiento de que se requiere juntar los esfuerzos de los tres sectores y para eso no necesitan esperar directrices de ningún lado. Ellos se enteraron de MoProSoft y decidieron conseguir recursos para escuchar de primera mano de qué se trata. Trabajamos de lunes a jueves ocho horas diarias, más las discusiones a la hora de la comida o cena. Ya no sé quién aprendió más, ellos o yo. Me di cuenta que los académicos de allá tienen conocimiento para capacitar a las empresas, los empresarios están concientes de sus carencias y, en vez de quejarse, tienen ganas de aprender, además el gobierno estatal ve una gran oportunidad de desarrollo para la industria de TI gracias a la cercanía del mercado de EEUU. Esto se ve reﬂejado en las actividades diarias y en los ambiciosos planes del Cluster de TI de Baja California, dirigido por Antonio Abad Silva. Antonio me sorprendió con su muy participativa asistencia al taller durante los cuatro días sin falta alguna. Además, el viernes organizó un desayuno con los empresarios y académicos de Ensenada, volvió a escuchar mi plática en una reunión con mis colegas de CICESE y terminamos, con todos los participantes del taller, en el Valle de Guadalupe probando vinos. Pero de esto último ya no les contaré nada. - Hanna Oktaba www.softwareguru.com.mx

COLUMNA

MEJORA CONTINUA

Agentes de Cambio de Calidad Acerca de Héroes y Agentes

a semana pasada me preguntaba un amigo sobre las cualidades de las personas que deben de integrar el equipo de calidad. Esto despertó en mí la inquietud de averiguar el criterio que utilizan otras empresas y complementarlo con ideas propias. La información que obtuve fue muy variada, desde: “es la persona con más experiencia en el modelo de calidad”, hasta “mostró mucho interés en el puesto”. Aun así, la mayoría se agrupan en los siguientes puntos: 1. Conocimiento de Administración de proyectos y/o modelos de calidad. La persona debe saber manejar un proyecto exitosamente, para poder enseñar a otros como hacerlo. Esto es comprensible, sin embargo hay que cuidar lo siguiente:

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.

a) Ser responsable de un cambio organizacional es más una labor de venta que una labor de administración. El trabajo es mucho menos de dirigir y mucho más de influenciar. b) Si la compañía esta buscando mejorar la forma en que hace las cosas, quiere decir que lo que hizo exitoso a un proyecto no necesariamente hará exitoso a los proyectos futuros. Es posible que alguien muy experimentado en la forma de operación tradicional tenga poca flexibilidad hacia nuevas ideas. 2. Amor por hacer las cosas bien. Una persona sin pasión no vende. El único punto de cuidado es la inflexibilidad con la definición de la palabra “bien”. En ocasiones veo a personas altamente técnicas ocupando el puesto de directores de calidad, debido a su gran conocimiento. Pero su nivel de entrega a la perfección en ocasiones los lleva a definiciones muy rígidas. Es muy fácil defender un modelo porque está publicado en un libro o porque la industria dice utilizarlo, pero en general la realidad es mucho más complicada que la teoría. 3. Estudioso y apasionado de su trabajo. Existen muchos modelos de calidad y formas de mejorar un proceso o estructura. Los individuos dedicados a la calidad deben estar conscientes de esto y en constante aprendizaje. Recuerden siempre mantener un balance entre lo que se aprende y lo que se aplica.

Agentes de Cambio Lo que realmente debe buscarse en estas personas es que sean verdaderos “Agentes de Cambio”, individuos que apoyen a su organización a iniciar una nueva aventura utilizando modelos y metodologías de mejora. Además de los puntos anteriores, un agente de cambio requiere: 1. Foco. En el área de calidad es muy fácil perder el foco. ¿Quién es tu cliente? ¿Qué quieres lograr? ¿Cómo ayuda esta actividad a avanzar el plan? Si esto no se tiene presente en

SEP-OCT 2005

todo momento, la presión y problemáticas del día con día los guiarán por diferentes caminos al grado de perder la claridad de hacia donde se va o como se llegó a la situación actual. 2. Humildad. Un Agente de Cambio no tiene todas las respuestas, y debe estar conciente de esto. Su labor es de conciliación y de lograr un acuerdo dentro de la organización que refleje las necesidades de su compañía. Nuevamente, todas las definiciones son buenas y malas dependiendo del grado en que son realistas y pueden aplicarse a la organización en forma exitosa dando un resultado mejor al anterior. 3. Habilidad para escuchar y ser flexible. Esta es posiblemente la habilidad más importante. Al mismo tiempo de conocer bien el modelo con el que se trabaja, el escuchar y modificar tus ideas, actitudes y estrategias de acuerdo a las limitantes del ambiente es fundamental. Es mejor un proceso bueno bien implantado, a un proceso excelente que nadie conoce, entiende o quiere llevar acabo. 4. Paciencia, persistencia y optimismo. El trabajo de un Agente de Cambio nunca termina. Siempre hay una mejor forma de hacer las cosas, y es parte de su trabajo descubrirla y mover a la organización en esa dirección. Esto puede llegar a ser frustrante y deprimente, por lo que se requiere perseverancia, optimismo y muy buen humor para salir adelante. Siempre debe verse al cambio como un reto para mejorar. 5. Habilidades de Negociación. Influir sobre las personas requiere de una constante negociación. Muchas veces escucho a personas del grupo de calidad diciendo cosas como: “Lo que pasa es que nadie me hace caso” o “No entienden lo que esto les puede ayudar”. La realidad es que si no se ha logrado un cambio, es porque no se ha sabido vender y negociar con todos los involucrados.

Conclusión “Todos los cambios, aun los más deseados, tienen su melancolía; ya que lo que dejamos atrás es parte de nosotros mismos; debemos de morir a una vida antes de entrar a la otra.” —Anatole France Si estás buscando a alguien para que lleve tu área de calidad, busca entre los Agentes de Cambio de tu organización. Busca gente que sabe operar pero también sabe vender. Si por otra parte tu participas en el área de calidad de tu compañía pregúntate como ves tu rol, ¿eres la persona con todas las respuestas, que va a corregir a los demás?, o ¿eres un Agente de Cambio? Alguien que ayuda a su organización a crear una nueva vida y dejar atrás la anterior para que descanse en paz. - Luis Cuellar www.softwareguru.com.mx

PRODUCTOS

LO QUE VIENE

Tivoli CDP Protección Automática de Información

IBM lanzará un nuevo producto para protección de datos, llamado Tivoli Continuous Data Protection (CDP) for Files, que provee respaldo de archivos en tiempo real a través de la red. Con esto, un usuario puede recuperar el estado de sus archivos en cualquier punto del tiempo, protegiéndose así de pérdidas de información por virus, corrup-

ción de archivos, borrado accidental o robo de computadoras portátiles. Cada que se realizan cambios a un archivo, el software genera una copia local, agrega un “timestamp”, y opcionalmente envía una copia a un disco en la red. Si el usuario no se encuentra conectado a la red, las copias se envían automáticamente en cuanto la conexión se reestablece. Todo esto se realiza de manera transparente y sin intervención del usuario.

El Tivoli CDP estará disponible en Estados Unidos a partir de la segunda mitad de septiembre y tendrá un precio de $35 dólares por computadora personal y $995 por cada procesador en el servidor. La disponibilidad y precio para la región de América Latina debe ser similar. Para estar en contacto con las tecnologías emergentes de IBM, puedes visitar el sitio alphaWorks. www.alphaworks.ibm.com

Este producto se une a una nueva ola de productos CDP. Otros proveedores que pronto ofrecerán soluciones similares son Microsoft, EMC y Veritas.

SQL Server y Visual Studio 2005 Al Fin Llegan las Nuevas Versiones

Durante su conferencia Tech Ed 2005 en Orlando, Microsoft finalmente anunció que el 7 de noviembre será el lanzamiento de SQL Server 2005 y Visual Studio 2005. Esta actualización de SQL Server será la más importante desde el año 2000, e incluye grandes mejoras tanto en funcionalidad como en desempeño. SQL Server 2005 provee una fuerte integración con el .NET Framework, lo cual se traducirá en ventajas para los desarrolladores. Microsoft también ha puesto gran énfasis en el desempeño y seguridad de este producto, con lo que espera eliminar la noción de que su base de datos no es suficientemente robusta para aplicaciones empresariales de misión crítica. Microsoft también dio a conocer que durante la primera mitad del 2006 lanzará software para facilitar la recolección y procesamiento de datos generados por dispositivos de radio frecuencia (RFID). Para mayor información, visita MSDN, el sitio de Microsoft para desarrolladores: msdn.microsoft.com o la versión en español: www.microsoft.com/spanish/msdn/

SEP-OCT 2005

PRODUCTOS

Red Hat Network Administración de Ambientes Heterogéneos

Que Red Hat agregue capacidades de monitoreo a su Red Hat Network (RHN), no es gran noticia. Pero el hecho de que vaya a soportar Solaris, sí es de llamar la atención. RHN es una plataforma para administración de sistemas operativos, típicamente utilizado para cuestiones como instalar parches y administrar configuraciones a través de la red. A esto se le agrega ahora un módulo para monitoreo de aplicaciones y de redes, con lo que su funcionalidad es comparable a la de ZENWorks para Linux, de Novell. Red Hat también agregará soporte a ambientes con Windows y otras ediciones de Unix, a través de una alianza con BMC Software. Así, los clientes podrán administrar ambientes heterogéneos con un solo producto.

www.softwareguru.com.mx

PRODUCTOS

NOVEDADES

Windows Vista

Panorama para los Desarrolladores Por Luis Daniel Soto

Históricamente, las mejores oportunidades para creadores de aplicaciones se han dado con cambios de plataforma tecnológica.

l escuchar “Windows Vista” (anteriormente conocido con el nombre clave Longhorn), producirá en el lector un gran escepticismo. De forma análoga, si nos recomiendan un “buen vino”, no importa la abundancia de alabanzas que nos mencionen... Es necesario degustarlo para conocerlo. No es posible reconocer el valor de un software sin utilizarlo, pero trataremos de describir a una vista de 10,000Km de altura la visión para desarrolladores de software para Windows Vista. Iniciemos con una breve descripción de la motivación para esta nueva versión: • Primero que nada, es una mejor versión que Windows XP SP2 o Server 2003 en lo referente a lo básico: confiabilidad, privacidad, seguridad, respuesta. • En segundo lugar, hay numerosas áreas de innovación tanto para el desarrollador como para el usuario final.

sistema operativo de ubicación geográfica, encendido y apagado instantáneo, estándares actualizados (v.gr. IP v6), diagnóstico para fallas en disco, descubrimiento de información, etc. Windows Vista operará en el hardware actual, pero idealmente 512Mb de RAM y se espera una compatibilidad con aplicaciones y drivers superior al noventa y cinco por ciento.

Los Fundamentos El beta 1 de Windows Vista es primariamente para desarrolladores de software —más de 250 nuevas características tan sólo de la interfaz gráfica no se encuentran habilitadas actualmente—. Los fundamentos incluyen muy diversas áreas, por ejemplo: • Calidad de aplicaciones. Windows Vista ofrece mejoras en el manejo de errores, recuperación de documentos, mecanismos de recuperación y protección del sistema operativo. Es posible alterar el sistema operativo sin interferir en la experiencia del usuario. Hay nuevas APIs para envío de comentarios de usuarios y para instrumentación y monitoreo de aplicaciones. • Seguridad. Windows Vista ofrece un nuevo modelo de seguridad que reduce vulnerabilidades del sistema: elevación temporal de privilegios, control de integridad del sistema, protección de recursos privados de Windows, aislamiento de la red de máquinas no actualizadas, y experiencias consistentes de identidad para múltiples dispositivos, entre otras cosas. • Resto de fundamentos. Una lista muy extensa referente a capacidad de generar imágenes para instalación masiva, migración de instalaciones, descubrimiento del

Mayor control en redes compartidas.

Desarrollo de Software Construir software para Windows Vista significa poder tomar ventaja de: • Plataforma Windows Vista. No sólo los fundamentos, sino también los nuevos servicios de la plataforma: instalación mejorada, funcionalidad peer-to-peer, quality of services (QoS), administrador de sincronizaciones, manejo de desplegados auxiliares y muchos servicios adicionales. • Windows Presentation Foundation (antes conocido como Avalon). El sistema que unifica la forma que se crean, se muestran y se manipulan documentos, permite crear aplicaciones muy atractivas visualmente.

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. http://blogs.msdn.com/luisdans

SEP-OCT 2005

www.softwareguru.com.mx

Se compone de una maquinaria y un framework con nuevos controles y extensibilidad: soporte a reconocimiento y síntesis de voz, especificación de papel electrónico XML independiente de aplicaciones y con firma digital. • Windows Communication Foundation (antes conocido como Indigo). Esto es el subsistema que unifica y extiende las tecnologías actuales de cómputo distribuido para crear sistemas conectados en forma consistente, software orientado a servicios. Habilita la creación de experiencias basadas en servicios web compuestos. • Aero. Es una nueva filosofía para el diseño de aplicaciones, incluye una interfaz de programación para ayudar a los desarrolladores a crear una experiencia emocional más fuerte con usuarios finales: permite manipular los controles del sistema operativo y el administrador integrado de ventanas.

do en “código administrado”, en donde se elimina el uso de manipulación directa de memoria. El WinFX SDK es un conjunto de herramientas, demostraciones y documentación que facilita la creación de aplicaciones y aumenta la calidad del software que se escribe. Algunas tecnologías planeadas originalmente para Windows Vista se pueden utilizar en la plataforma actual Windows XP y Windows Server 2003. Particularmente el Windows Presentation Foundation y el Windows Communication Foundation. Las tecnologías de plataforma base y otras tecnologías se liberarán gradualmente, pero estarán únicamente disponibles para Windows Vista. Tal es el caso del almacenamiento altamente descriptivo (nombre clave WinFS), que permitirá establecer reglas en base a los datos y las relaciones de los mismos, ofrecer nuevos mecanismos complejos de consulta de datos y sincronización compleja, entre otras cosas.

Capacidad de correr múltiples videos simultáneos con texto y formas irregulares.

WinFX es la evolución del modelo de programación que extiende el .net framework a todas las funciones del nuevo sistema operativo, remplazando al Win32 y basa-

Organización de archivos por diferentes criterios.

Conclusiones No se deje guiar por rumores. Intente escribir varias aplicaciones web, Windows, de dispositivos electrónicos portátiles, así como servicios web utilizando el WinFX SDK —recuerde que estas tecnologías se soportarán para Windows XP y Windows Server 2003; posteriormente explore los <nuevos fundamentos> o la funcionalidad específica que únicamente estará disponible para Windows Vista.

www.softwareguru.com.mx

ESPECIAL

En todas las actividades productivas, las empresas líderes obtienen ventajas competitivas a través de la investigación y el desarrollo tecnológico. Por desgracia, en nuestro país la mayoría de las empresas asocian la inversión en este rubro con la adquisición de hardware o paquetería, en vez de centrar sus esfuerzos en estudiar sus propios procesos productivos y administrativos para mejorarlos, automatizarlos e integrarlos en sistemas de apoyo a la toma de decisiones. En este artículo se demuestra que la Inteligencia Artificial es un componente crucial de la base tecnológica de las empresas de software más exitosas y una gran oportunidad para las empresas mexicanas.

Inteligencia Artiﬁcial

Base Tecnológica de las Empresas Desarrolladoras de Software Por Rodolfo García Flores El éxito de una empresa basada en tecnología depende de manera decisiva de su base tecnológica, que es su capacidad para explotar la tecnología como una competencia medular, invertir en tecnología futura, incorporar tecnología más avanzada en productos y servicios, y hacerlo en menos tiempo y con menos dinero que los competidores. Los siguientes ejemplos ilustran las ventajas que diversas empresas han obtenido al aprovechar su base tecnológica.

SEP-OCT 2005

• La institución financiera KPMG International enfrentó (como muchas otras) la necesidad de automatizar el proceso de revisión de nuevos solicitantes de crédito a partir de historiales crediticios para tomar una decisión. Actualmente la empresa utiliza un sistema experto llamado Loan Probe para este fin. • Los casinos en Estados Unidos enfrentan a posibles estafadores utilizando el sistema NORA (Non-Obvious Relationship Awareness) que busca conexiones entre jugadores, trabajadores y organizaciones. La empresa desarrolladora de NORA, Systems Research and Development, hoy es proveedora del gobierno de los EEUU ya que su tecnología se considera útil para la seguridad nacional. • Empresas multinacionales como Ford, encuentran frecuentemente que su expertise en áreas específicas se encuentra repartido en diferentes países. Para reducir costos y facilitar el entrenamiento de sus empleados, han buscado recopilar esta experiencia al desarrollar sistemas como POM (Prototype Optimization Model), que reúne reglas para coordinar, www.softwareguru.com.mx

planear y presupuestar los programas de prueba de prototipos. POM ahorra hoy a Ford más de USD 250 millones al año.Todos estos desarrollos han producido beneficios probados y cuantificables aplicando técnicas de Inteligencia Artificial (AI). La investigación en el área de AI intenta explicar la forma en que los seres humanos razonan. Siendo ésta una meta muy ambiciosa, en la práctica es necesario acotar las funciones del razonamiento a áreas específicas como la visión, el lenguaje, el reconocimiento de patrones y el aprendizaje. La ventaja tecnológica que AI ofrece a la industria radica en que permite automatizar estas funciones, y si bien no hace innecesario al experto humano, sí facilita su labor y genera ahorros considerables en horas-hombre. Cuando una empresa basada en tecnología considera un cambio estratégico como los citados anteriormente o evalúa su estrategia actual, debe efectuar un análisis crítico de su capacidad para explotar el cambio. El concepto de base tecnológica provee un marco teórico para evaluar esta capacidad. Este artículo presenta sus componentes y demuestra la viabilidad de la adopción de la AI como ventaja tecnológica esencial para incrementar el valor agregado del software hecho en México.

Los Componentes de la Base Tecnológica La Figura 1 muestra los elementos que se deben tomar en cuenta para evaluar la base tecnológica de una empresa.

Figura 1. La base tecnológica de la empresa. [1]

• Ventajas tecnológicas esenciales.– Reflejan el aprendizaje colectivo en áreas técnicas específicas y el acervo resultante de know-how, con la consiguiente propiedad intelectual. Estas ventajas dependen de la experiencia acumulada en el desarrollo y explotación de tecnología. Una evaluación detallada de las ventajas tecnológicas esenciales debe distinguir entre las tecnologías de producto y de proceso. Una clasificación útil para las ventajas tecnológicas es www.softwareguru.com.mx

la que las divide en tecnologías clave, de base, de paso y emergentes. Las tecnologías clave son indispensables para la ventaja competitiva ya que ofrecen la oportunidad de lograr una diferenciación significativa en el producto o proceso. Las tecnologías de base son necesarias para permanecer en el mercado, aunque no ofrecen ninguna ventaja competitiva; todos los participantes tienen acceso a ellas. Por ejemplo, todas las empresas de software tienen acceso a lenguajes de programación, compiladores, ambientes de desarrollo, etc. Las tecnologías de paso todavía no se han establecido en la industria, pero tienen el potencial comprobado para convertirse en tecnologías clave. Las tecnologías emergentes están en el horizonte y todavía no se han probado siquiera. Como se imaginarán, no se puede contar con tecnologías clave sin haber desarrollado y probado tecnologías de paso y emergentes. Por ejemplo, antes de Google, los buscadores de Internet contaban la frecuencia con que los términos buscados aparecían en las páginas, y consideraban que, mientras más veces apareciera el término, más relevante era la página. En 1996, Larry Page y Serguei Brin, pensaron que sería mejor definir la relevancia de la búsqueda como la “popularidad” de las páginas, esto es, mientras más veces la página fuera visitada, más relevante sería. El motor de búsqueda es hoy tecnología clave de Google, y sigue siendo materia de investigación. • Ventajas organizacionales.– Son los factores que permiten a la empresa crear y explotar nuevas tecnologías. Incluyen cinco elementos: las aptitudes del personal, los procedimientos para toma de decisiones y distribución de información, la estructura organizacional, las estrategias que guían la acción, y la cultura que moldea suposiciones y valores compartidos. • Ventajas externas.– Es la red de conexiones que la empresa establece con su entorno. Incluye contactos con proveedores, clientes, competidores, asociaciones, comunidad, etc. De estos contactos depende la capacidad de la organización para encontrar, construir y explotar la tecnología propia. Innumerables desarrollos tecnológicos son producto de la colaboración entre estos grupos. • Procesos de desarrollo.– El desarrollo de productos y procesos genera valor agregado para la supervivencia de la empresa, mientras que el desarrollo de tecnología genera diferenciadores que con el tiempo se volverán clave. • Ventajas complementarias.– Aquí se incluyen disciplinas como mercadotecnia, distribución, manufactura, servicio al cliente. Aunque pueden no representar propiedad

intelectual en el mismo sentido que una patente o un registro, son decisivas para el éxito comercial de las empresas, y también se benefician de la aplicación de AI. Por ejemplo, es sabido que American Airlines pudo obtener una importante ventaja a partir de sus avanzados sistemas de información para la expedición de boletos, diseño de rutas mediante programación matemática y asignación de reservas, codificado en un sistema de nombre Sabre. La minería de datos, que es el proceso automático de identificación de patrones en bases de datos, puede apoyar de manera importante a la mercadotecnia. El autor realizó un estudio de este tipo para una pequeña industria química [2]. Evidentemente, la labor de las empresas desarrolladoras de software consiste en crear programas para automatizar las ventajas complementarias, organizacionales y los procesos de desarrollo de sus clientes. Sin embargo, la gran ventaja de los desarrolladores de software de los países primermundistas sobre sus competidores, ha sido la investigación en AI y otras áreas de las matemáticas aplicadas como la estadística. Como lo indica la Figura 2, las empresas con desarrollos tecnológicos y conocimientos propios pueden formar una base de clientes más numerosa y fuerte que aquellas pobres en conocimiento y carentes de propiedad intelectual, pues las primeras pueden ofrecer productos y servicios que representan valor real para sus clientes.

Figura 2. El ambiente de negocios de las empresas de software. VTE – ventaja tecnológica esencial, VE – ventaja externa, PD – procesos de desarrollo, VC – ventaja complementaria, VO – ventaja organizacional.

SEP-OCT 2005

ESPECIAL

Las Funciones de la Inteligencia ¿Qué ventajas concretas ofrece AI a las empresas desarrolladoras de software? La emulación del comportamiento inteligente ha permitido automatizar las siguientes tareas: [3] • Aprendizaje a partir de la experiencia.– El aprendizaje es una habilidad fundamental de la mente humana y se ha logrado emular con éxito en programas que juegan al ajedrez o que eliminan virus informáticos, por citar tan sólo dos ejemplos. IBM, que se ha transformado de fabricante de hardware a desarrollador de software, creó el programa Deep Blue para retar y vencer al campeón mundial de ajedrez. IBM también ha creado programas para eliminar virus que emplean redes neuronales que generalizan aprendiendo a partir de ejemplos de virus conocidos. • Manejo de situaciones complejas.– Todos los seres humanos estamos envueltos en ambientes complejos y cambiantes, por lo que es importante desarrollar herramientas para apoyar la toma de decisiones de los líderes de las organizaciones. Existen sistemas para apoyo a toma

de decisiones (DSS, por sus siglas en inglés) en diversas áreas como comercio, lucha contra la pobreza, agricultura, economía, medio ambiente, terrorismo, etc. • Resolución de problemas con información faltante.– Rara vez conocemos toda la información relacionada a un problema antes de resolverlo. Todos los días nos topamos con situaciones que implican tomar decisiones con información imprecisa o faltante. Esta área de investigación ha producido resultados de gran importancia, como el famoso sistema experto MYCIN, desarrollado en Stanford, que apoya a los médicos en el diagnóstico y tratamiento de infecciones en la sangre.

• Identificación de información prioritaria.– Hoy en día se cuenta con vastas bases de datos con todo tipo de información. Por ello se ha vuelto indispensable filtrarla y procesarla, para eliminar los datos innecesarios y explotar inteligentemente el conocimiento. Un ejemplo es LSI Indicator, un sistema experto creado por la empresa de bienes raíces LSI, que ayuda a determinar el valor real de una propiedad utilizando bases de datos compartidas por la industria [4]. • Prevención y diagnóstico de situaciones indeseables.– Dada la complejidad de las modernas plantas industriales, la información producida por los sistemas de control se ha vuelto difícil de interpretar con la velocidad requerida. Por ello, se han aplicado técnicas de reconocimiento de patrones a los datos producidos por estos sistemas para identificar fallas antes de que éstas ocurran, lo cual ha generado ahorros significativos. En China existen aplicaciones de este tipo para la identificación de fallas en redes eléctricas. • Interpretación de imágenes.– Esta tarea es difícil de automatizar, pues la naturaleza de las computadoras no les permite identificar patrones visuales u objetos con la misma facilidad que los seres vivos. Sin embargo, existen numerosas aplicaciones que realizan esta labor, como el sistema de identificación y análisis de huellas digitales del Departamento de Justicia de Estados Unidos, o el sistema de organización del correo del servicio postal del mismo país, que “lee” las direcciones de los destinatarios escritas en los sobres de las cartas. • Procesamiento simbólico.– Existen programas que apoyan a los matemáticos en manipulaciones simbólicas, como por ejemplo General Problem Solver (GPS) de la Universidad Carnegie Mellon, que combina reglas de inferencia y heurísticas para automatizar la comprobación de teoremas. • Uso de heurísticas.– Innumerables empresas tratan de optimizar sus operaciones utilizando modelos matemáticos cuya solución exacta es difícil y computacionalmente costosa. En el campo de AI se han desarrollado heurísticas que permiten la solución aproximada de estos problemas en un tiempo razonable y a bajo costo. Problemas de logística, secuenciamiento de tareas de manufactura y optimización de portafolios de inversión, ente otros, han sido resueltos satisfactoriamente de esta forma. Es claro que no puede decirse que ninguna de estas aplicaciones sea “inteligente” en el sentido en que lo es un ser humano, ni mucho

menos que ayude a resolver las preguntas trascendentales sobre la inteligencia. Pero definitivamente sí resuelven problemas prácticos que las empresas y los gobiernos enfrentan todos los días, y automatizan actividades específicas que comúnmente se asocian con la inteligencia. Por ello, AI es un área de la ingeniería en constante desarrollo y que beneficia directamente a la industria del software, como han demostrado los ejemplos expuestos.

Pensando en el Futuro Las empresas líderes en el desarrollo de software (como en todas las actividades productivas) obtienen ventajas competitivas a través de la investigación y el desarrollo. En este artículo se presentaron los componentes de la base tecnológica de las empresas y se proponen las técnicas de la Inteligencia Artificial como ventaja tecnológica esencial en el desarrollo de software, más allá de la tecnología de base a la que todos los competidores tienen acceso. De ninguna manera AI aspira a eliminar al experto humano, sino más bien a apoyar al personal para facilitar su labor, tomar mejores decisiones y producir ahorros cuantificables. Todos los desarrolladores de software compiten en automatizar los procesos de negocio de sus clientes, pero la ventaja tecnológica esencial de los desarrolladores de software mexicanos debe provenir de la investigación y desarrollo tecnológico en matemáticas aplicadas e ingeniería de sistemas, pues con ellas es posible lograr diferenciación real ante la competencia de cualquier país.

Referencias • [1] Shenhar, A.J. y Adler, P.S. La base tecnológica de la empresa, en Gaynor, G. (editor) Manual de gestión en tecnología, Tomo I. Una estrategia para la competitividad de las empresas. Mc Graw-Hill Interamericana, Bogotá, 1999. • [2] Garcia-Flores, R., Wang, X.Z. y Burgess, T.F. Tuning inventory policy parameters in a small chemical company. Journal of the Operations Research Society, 54:350-361, 2003. • [3] Stair, R.M. y Reynolds G.W. Principles of information systems, Thomson Course Technology, Canada, 2003. • [4] Rozmus, P. LSI and ATSI provide link for collateral assessment services, Business Wire, December 21st, 2001.

Rodolfo García Flores es Ing. Químico por la Facultad de Química de la UNAM y Doctor por la Universidad de Leads (Reino Unido), con especialidad en Inteligencia Artificial aplicada a la toma de decisiones. Trabajó para una empresa química en Pudsey, Inglaterra, donde empleó técnicas de AI para la investigación de operaciones. Fue catedrático en la Facultad de Ingeniería Mecánica de la Universidad de Nuevo León. Actualmente es candidato al SNI y colaborador de Sistemas Lógicos SisLogic S.A.

SEP-OCT 2005

www.softwareguru.com.mx

ENTREVISTA

RAFAEL FUNES Director General de Dynaware Rafael Funes es Presidente y Director General de Dynaware, empresa mexicana creadora del ERP Dynaware Empresarial. Dynaware es una de las empresas con mayor crecimiento en este sector en los últimos años, y compite frente a frente con gigantes como SAP, Oracle y Microsoft. En este número, Rafael comparte con nosotros su experiencia como empresario en la industria de software, y particularmente como productor de software empaquetado. Cuéntanos un poco sobre ti y tu background Mi background es un lugar común en esta industria. Soy Ingeniero Industrial del Tec de Monterrey, y aprendí a programar en la escuela y me encantó. Combiné la Ingeniería Industrial con este gusto por la programación y empecé a crear sistemas de planeación de requerimientos de materiales (MRP). Vi que había una oportunidad de negocio con las empresas pequeñas y medianas, y empecé a buscar clientes, y hacer desarrollo a la medida principalmente para áreas productivas, de manufactura. Esto fue en 1985, y después de nueve años, en 1994, decidí cambiar el modelo e integrar el software como un producto, no como desarrollo a la medida. ¿Que características o habilidades debe tener un empresario? Para ser empresario se requiere tener “estomago” de empresario, y esto requiere ciertos atributos. Lo primero es tener una idea de

SEP-OCT 2005

a dónde quieres llegar. Tener calidad en todo lo que haces, desde la llamada, hasta cualquier documento que prepares. Otra cosa clave es verse continuamente en frente del espejo de la verdad. Es difícil cuando nos dicen nuestras verdades, pero es todavía más difícil cuando uno mismo las tiene que ver. Este es un proceso al que todo emprendedor debe someterse continuamente. Por último, se requiere de una gran perseverancia. El proceso es un “largo y sinuoso camino”, como dice la canción de los Beatles. Yo muchas veces estuve tentado a claudicar, me despertaba viendo al techo, y mi mujer alguna vez me dijo “oye, que te parece si ya dejas de jugar al negocito y te pones a trabajar de manera ordenada, seria y formal, y traes dinero a la casa”. Así que se requiere perseverancia y fuerza de voluntad para salir adelante. Nosotros llevamos veinte años de trayectoria, once años como producto, y todavía hay muchísimo trabajo por hacer. www.softwareguru.com.mx

“Mi única alternativa era hacer un producto incuestionable, matar el cuestionamiento de origen” ¿Es mejor arrancar tu empresa desde un inicio, o primero ser empleado y posteriormente poner tu empresa? Cualquiera de los dos caminos es válido. Tiene mucho que ver tu voz interior. A mi me decía “emprende”. En la escuela había bolsa de trabajo, y entrevistas con empresas, pero yo nunca fui, ya tenía muy claro por donde me quería ir. Quiero aclarar que no se trata de que ser emprendedor es mejor, y no ser emprendedor es algo malo. Ambos cumplen un rol. Por cada emprendedor, se necesita una buena cantidad de personas que se sumen al enfoque y visión del emprendedor, y que estén dispuestos a rifársela. Yo creo que cada persona debe preguntarse con que escenario se siente más confortable, y si está dispuesto a correr los riesgos que implica emprender, versus los riesgos que implica ser colaborador. ¿Qué te motivó a ser una empresa basada en producto, y no basada en servicios? Mi experiencia personal, es que llegué a un momento en el cual los costos de tratar de resolver la parte final del proyecto 1, eran subsidiados por los ingresos del proyecto 2, y luego el 3 subsidiaba parte del 1 y del 2. Esto porque la expectativa del cliente de desarrollo a la medida no era muy fácil de acotar, sobre todo en ese entonces. Así que el último 3% del proyecto me costaba más que 97% inicial. Esto me provocaba mucho estrés —soy el mayor de mi familia, y por definición según los libros, soy el más perfeccionista—, ya que aunque lográramos terminar los proyectos, a mí me molestaba que el círculo no quedara cerrado como yo quería. Entonces decidí que mi única alternativa era tener un producto incuestionable, matar el cuestionamiento de origen. No pelearme al final, sino desde el principio ganar la batalla. Como dice Sun Tzu “las batallas se ganan antes de pelearlas”. Así que mi camino fue: hago un producto que funcione bien, lo entrego, y el cliente no me puede cuestionar el producto, entonces nos preocupamos nada más por el proceso. No fue tan simple, pasaron varios años, pero llegue a ese nivel. Así que moví el pleito hacia la instrumentación. Entonces los pleitos eran sobre la instrumentación, que si no avanzábamos, que si el tiempo, etc. Así que apliqué el mismo enfoque, hice una metodología para la instrumentación. Posteriormente un amigo me convenció de www.softwareguru.com.mx

que el negocio está en hacer algo repetible. Para entonces yo ya estaba orientado a producto, así que siguiendo su consejo me enfoque en que mis procesos para venderlo e implantarlo fueran repetibles. ¿En qué se basa la estrategia de Dynaware? El principio fundamental de Dynaware como producto, es que sea muy poderoso y flexible, pero a través de parametrización, y no de modificar el código. En lugar de construirle la misma función a cada cliente de formas distintas, construyes una función que contiene las variantes que se necesitan, y lo controlas a través de modificar parámetros ya en la operación. Esto da pie al segundo elemento de la estrategia, que es un proceso de consultoría totalmente orientado a los procesos de negocio, y no al desarrollo del software. Esto nos ha llevado a tener un producto muy completo, totalmente orientado a la operación de la empresa, no a la tecnología. Todo esto permite un proceso más rápido y predecible. Gracias a esto, en proyectos donde el promedio de nuestros competidores andarían en 40 semanas con un alto grado de incertidumbre, nosotros estamos en 20 semanas con total certidumbre. Nuestro rango de proyectos hoy va de 18 a 26 semanas casi sin importar el tamaño del cliente. ¿Qué barreras has encontrado como empresario? La barrera más grande que encontré durante los primeros 18 años, fue un profundo malinchismo. Todavía hoy me lo encuentro, pero ha ido transformándose y cada vez me encuentro más empresas a las que les atrae la idea de que somos una empresa mexicana, contra invertir con una empresa extranjera. Sobre todo en las PyMEs mexicanas, por supuesto. Creo que el mexicano está empezando a cambiar, a cuestionar ese malinchismo, especialmente en ciertos segmentos. No es un nacionalismo trasnochado de “me enredo en la bandera y me aviento”, o “me tomo cuarenta tequilas porque soy mexicano y muy macho”. No es eso, es un nacionalismo bien entendido, donde hay una verdadera comprensión de que tenemos un gran valor y podemos hacer cosas tan buenas o mejores como las que hacen los extranjeros. La segunda barrera es que en México hay una reducida propensión a invertir en general, y esta es más reducida en tecnología, y todavía más cuando se trata de un intangible como el software. Esto es muy importante, y

quizás el verdadero mal. El mexicano por cultura quiere ver cosas tangibles. El servidor lo agarra, ve el foquito que prende y apaga, pero el software dice “¿donde está?”. ¿Qué opinas sobre los apoyos para mejorar la competitividad de la industria? ProSoft está apoyando el desarrollo de la industria de software, y el subsecretario Sergio García de Alba con la subsecretaría de PyMEs y el fondo PyME también está haciendo un trabajo muy valioso para que las PyMEs puedan invertir en tecnología. Sin embargo, viene una variable clave, que es la famosa competitividad. La verdad es que no somos un país culturalmente enfocado a la competitividad. Yo mexicano, no lucho por ser mejor que el otro, lucho porque el otro sea peor que yo. Cuando yo lucho por ser mejor que el otro y le gano, es válido. Pero si lucho porque el otro sea peor que yo, entonces todos perdemos. Por más que se generen incentivos e infraestructura, si no resolvemos este problema de fondo, vamos a seguir bajando en nuestra competitividad. Cuando yo luche por ser mejor que el de al lado y él luche por ser mejor que yo, entonces y sólo entonces tendremos la posibilidad de transformarnos en un país competitivo. ¿Qué mensaje dejas a nuestros lectores? Les recomiendo que se acerquen a las asociaciones de su industria. Yo me he involucrado muchísimo con la AMITI. Esto requiere de mucho tiempo, que no le estoy dedicando directamente a mi empresa, pero que yo se que está muy bien invertido. Por un lado, en la parte egoísta, me permite posicionar mi marca y relacionarme con personas muy valiosas. Pero por otro lado, también me permite ayudar a que el tamaño de la industria, de la inversión en TI, crezca. Así que hay que involucrarse en las asociaciones. No se vale esperar que nuestras empresas crezcan sustancialmente y sean exitosas sin meter una parte del tiempo, dinero y esfuerzo a contribuir para que la industria se desarrolle. Por último, voy a recurrir a un pasaje de la historia: Cuando Luis XIV le preguntó a su consejero lo que debía hacer para convertir a Francia en una potencia, éste le contestó: “confíe en su pueblo”. Eso es lo que yo pediría a los lectores de SG, que confíen en sí mismos y en los demás mexicanos. SEP-OCT 2005

EN PORTADA

DESARROLLO DE APLICACIONES MÓVILES

Elementos a Considerar Por Héctor Obregón

Conforme se ha generalizado el uso de dispositivos móviles por los consumidores en los últimos años, las áreas de TI cada vez están volteando más hacia éstos como un recurso que ofrece varias ventajas sobre las opciones de movilidad tradicionales. Por dispositivos móviles nos referimos fundamentalmente a asistentes personales digitales (PDAs por sus siglas en inglés) y a teléfonos inteligentes o SmartPhones. Estos dispositivos hoy contienen el poder de cómputo de una laptop de hace unos cinco años, pero en un formato altamente atractivo por su portabilidad y facilidad de uso.

SEP-OCT 2005

www.softwareguru.com.mx

l primer ámbito donde han venido surgiendo soluciones empresariales muy interesantes es en las aplicaciones verticales. Algunos ejemplos concretos son: automatización de fuerza de ventas, levantamiento de información en campo, administración de servicios de mantenimiento, administración de almacén, y cobranza. Un segundo ámbito, más reciente, es el relacionado con proporcionar información ejecutiva a mandos medios capaces de tomar decisiones sobre la operación del negocio en instantes. Ajustes a una línea de producción, modificaciones a una frecuencia de salidas de viaje, o balanceo de cargas entre equipos de trabajo en tiempo real. En ambos casos, las áreas de TI se enfrentan a retos particulares al crear o comprar este tipo de soluciones. En este espacio identificaremos cuáles son los principales puntos a considerar al buscar desarrollar una solución que funcione sobre dispositivos móviles.

Conectividad

Una solución móvil en una empresa jamás es una solución aislada. Normalmente es una extensión de los sistemas empresariales existentes, como ERPs o CRMs. Por lo tanto, es fundamental entender las opciones de conectividad disponibles en el mercado y el impacto que tienen en nuestra posible aplicación. En primer lugar, podemos clasificar las aplicaciones móviles en línea y fuera de línea. Una aplicación fuera de línea es aquella que se sincroniza mediante una conexión física ocasional, ya sea cuando el personal móvil regresa a la empresa o a través de un modem. Por otro lado, una aplicación en línea puede ser de gran ancho de banda (Wi-Fi) o bien de bajo ancho de banda (GPRS).

Sincronización de Datos

Precisamente para una aplicación ocasionalmente conectada, se vuelve crucial contar con una buena estrategia de sincronización de datos. Lo más recomendable es aprovechar la infraestructura de sincronización existente en motores de base de datos ya maduros. Entre las mejores opciones encontramos a Microsoft SQL Server Mobile, Oracle Lite y SQL Anywhere Studio. A mi juicio, la experiencia más completa e integrada para desarrollar aplicaciones móviles con sincronización de datos es ofrecida por la combinación de Microsoft SQL Server Mobile, SQL Server 2005 y Visual Studio 2005. Estas herramientas se encargan de resolver los aspectos más importantes para sincronizar datos en una solución móvil y nos ahorrarán mucho trabajo. Comprimen la información para ambientes de bajo ancho de banda, particionan nuestra base de datos maestra para cada usuario móvil, y se encargan de replicar los cambios entre el servidor y los dispositivos móviles. Adicionalmente, nos permiten monitorear el estatus de la sincronización y resolver problemas. Finalmente, nos ofrecen una forma de programar basada en SQL en el dispositivo móvil. Una opción muy interesante para los servicios en línea (por ejemplo, para checar un nivel de inventario a través de GPRS) son los servicios web basados en SOAP (Simple Object Access Protocol) mediante los cuales es muy sencillo realizar una transacción simple contra nuestros sistemas empresariales.

Soporte

Para una aplicación de gran ancho de banda podemos elegir el utilizar una interfaz web optimizada para el formato pequeño del dispositivo móvil, si es que el navegador nos ofrece la flexibilidad de diseño que necesitamos.

Por definición, es muy probable que nuestros usuarios se encuentren dispersos geográficamente y que sea complicado darles soporte. Actividades como la actualización de nuestra aplicación, o otorgar apoyo para resolver un problema, pueden resultar complicadas y costosas, elevando innecesariamente el costo total de propiedad de la solución.

En los demás patrones, lo más recomendable es una arquitectura ocasionalmente conectada donde planeamos la aplicación para que funcione con o sin conectividad, aunque algunos de nuestros servicios estén restringidos en el segundo caso. De esta manera no dejaremos a nuestros usuarios abandonados cuando no tengan una conexión a la mano.

Por esta razón, es indispensable contar desde un inicio con una estrategia de soporte basada en herramientas que nos permitan administrar fácilmente nuestros dispositivos de forma remota. Debemos ser capaces de actualizar nuestra aplicación de forma remota, de obtener información de fallas de forma automática y de atender remotamente a nuestros usuarios y a sus dispositivos.

Interfaz de Usuario

Uno de los errores más comunes cuando un programador que viene del mundo de las computadoras personales aborda un proyecto para dispositivos móviles, es subestimar las diferencias en la interfaz de usuario. Los dispositivos móviles están restringidos en el área de la pantalla y en las formas en que aceptan entradas de sus usuarios. Esto implica que debemos pensar siempre en una interfaz lo más sencilla posible y parecida a la de las demás aplicaciones que existen en la PDA o en el SmartPhone. Debemos limitar la información presentada a aquella que sea indispensable. También minimizar el número de entradas que deba hacer el usuario, aprovechando los métodos de entrada que nos ofrezca el dispositivo. Nuestra aplicación debe estar preparada para que el dispositivo se apague o encienda en cualquier momento sin pérdida de información.

Plataforma

Las plataformas más comunes para desarrollo de aplicaciones móviles son J2ME (Java 2 Micro Edition), y el .NET Compact Framework para Windows Mobile. Personalmente, para el desarrollo de aplicaciones corporativas, he elegido especializarme en este último, ya que considero que ofrece varias ventajas sobre las alternativas disponibles: • Capacidad de rehusar el conocimiento de desarrollo existente en lenguajes .NET para el escritorio. • Excelente desempeño y velocidad de desarrollo. • Facilidad para interactuar con aplicaciones corporativas gracias a una infraestructura muy completa para manejo de XML y desarrollo de clientes SOAP. • Integración simple con SQL Server CE. • Posibilidad de desarrollar en Visual Studio .NET Java 2 Micro Edition también es atractivo, dado el número de teléfonos celulares que lo soportan. Sin embargo, siento que está más orientado a aplicaciones de entretenimiento que a aplicaciones para empresas.

Herramientas de Desarrollo

Las opciones de IDE dependen de la elección de plataforma: CodeWarrior es una herramienta muy popular para aplicaciones en PalmOS, NetBeans parece ser la opción default en el caso de J2ME, y para el .NET Compact Framework, la mejor opción la ofrece Visual Studio.

Héctor Obregón es Director General de emLink (www.emlink.com.mx), una empresa mexicana enfocada a desarrollar soluciones y servicios para la automatización basados en tecnología .NET. Héctor también es Microsoft MSDN Regional Director y Microsoft MVP para Windows Embedded. hectoror@emlink.com.mx

www.softwareguru.com.mx

SEP-OCT 2005

EN PORTADA

Código Administrado y No Administrado Una Visión General Por Óscar Esqueda

Al igual que para las aplicaciones empresariales y de escritorio, en el desarrollo de software para dispositivos móviles tenemos dos opciones de esquemas de codificación: código administrado y no administrado. Aunque esta terminología es propia de la plataforma .NET de Microsoft, estos conceptos también aplican a otras plataformas.

típicamente es más seguro, estable, rápido de desarrollar y fácil de mantener. Todo esto puede ser englobado en una sola frase: mejora en la productividad.

Código Administrado

Código administrado es un término que describe al código de una aplicación que corre o se ejecuta bajo un ambiente administrado. Esto significa que el código de la aplicación no corre directamente sobre el sistema operativo del dispositivo, sino que en vez de ello, se apoya de un ambiente de ejecución (runtime engine) para ser ejecutado. El ambiente de ejecución se encarga de asignar recursos y servicios de soporte como seguridad, administración de la memoria, etc., por lo que decimos que la aplicación está siendo administrada por el ambiente de ejecución. Contar con un ambiente administrado nos permite tener aplicaciones que son independientes tanto del procesador como del sistema operativo.

Código No Administrado

Código no administrado es aquel que al compilarse genera un binario que es ejecutado directamente por la máquina, fuera de algún ambiente de ejecución, y que por ende no obtiene servicios de soporte a través del mismo. ¿Esto significa que la implementación es insegura y que hace mal uso de la memoria? No necesariamente, es sólo que si el desarrollador requiere de estos servicios, debe de hacer peticiones explicitas al sistema operativo, o a componentes COM que implementen los servicios deseados.

¿Cuál es la Mejor Opción?

No existe una respuesta única a esta pregunta, todo depende de las necesidades específicas de cada desarrollo. En la manera que sea posible, es recomendable desarrollar utilizando código administrado. Además de su portabilidad, el código administrado

Studio .Net 2003 y eMbedded VisualC++ 4.0 las opciones más comunes, respectivamente. Sin embargo, Visual Studio 2005, que está próximo a salir al mercado, soporta ambos esquemas de codificación, facilitando así la vida para los desarrolladores. Además, esta herramienta incluye la nueva versión de .NET Compact Framework (versión 2.0), un ambiente de ejecución mejorado y con mayores capacidades.

Conclusión

Figura 1.– Diferencia entre esquemas

Sin embargo, existen desarrollos que solamente pueden ser implementados como código administrado, como es el caso de los controladores de dispositivos (device drivers). Si por la naturaleza del proyecto es imposible usar código administrado al cien por ciento, puede ser recomendable combinar ambos esquemas: se desarrollan como código no administrado los componentes que así lo requieran, y el resto se implementa como código administrado. Las tecnologías: Platform Invoke (P/Invoke), COM interop y C++ interop pueden ser de utilidad en este caso. En cuanto a desempeño de la aplicación se refiere, los mejores resultados se pueden obtener usando código no administrado. Otra vez, esto nos puede llevar a un esquema combinado, donde los componentes sensibles a desempeño se implementen como código no administrado, y el resto como código administrado.

Herramientas para Ambos Esquemas

En el caso de la plataforma .NET, tradicionalmente los desarrolladores han requerido de una herramienta para código administrado, y otra para código no administrado. Siendo Visual

Seleccionar un esquema de codificación para implementar una aplicación es, sin duda alguna, una tarea importante. Esta selección puede ser de gran influencia en la buena o mala aceptación de nuestro producto. En general, la tendencia va hacia esquemas de código administrado, ya que permiten a los desarrolladores implementar una vez e instalar en múltiples dispositivos sus aplicaciones, lo cual se traduce en una mejor productividad. La decisión para hacer uso de uno u otro esquema de codificación depende básicamente de los requerimientos específicos de la aplicación y de los resultados que esperamos obtener; resultados asociados a factores tales como el desempeño, la seguridad y el buen manejo de los recursos.

Referencias • Keserovic, Mortenson, Nathan. An Overview of Managed/Unmanaged Code Interoperability. MSDN. www.msdn.com • Boling, Douglas. Programming Microsoft Windows CE .NET. 3a Edición, Microsoft Press, 2003. • Gregory, Kate. “Managed, Unmanaged, Native: What Kind of Code Is This?” www.codeguru.com

Oscar Esqueda Dávalos es Ingeniero en Sistemas Computacionales egresado del Tecnológico de Monterrey, actualmente se desempeña como coordinador del área de Diseño de Software del Centro de Diseño Electrónico (CDE) del Tecnológico de Monterrey, cuya meta principal es desarrollar plataformas tecnológicas y aplicaciones móviles, todo ello bajo un mismo denominador común: usar tecnologías de punta. oesda@itesm.mx

SEP-OCT 2005

www.softwareguru.com.mx

Sean Maloney

Siguiendo el Paso de los MIPS Recientemente estuvo en México Sean Maloney, director del grupo de movilidad en Intel. Aprovechando la oportunidad, le pedimos que compartiera con los lectores de SG su perspectiva respecto a la industria móvil.

WiMAX y su Estandarización

La industria de TI da por hecho las conexiones estandarizadas y a bajo costo. Por ejemplo, en el caso de Ethernet, todo mundo da por hecho que una computadora tiene un puerto de conexión en la parte de atrás y que si lo conecta a un hub de cualquier marca, va a funcionar. Esta tecnología la desarrollamos en conjunto con Digital y Xerox en los ochenta y ahora su costo es menor a un dólar. En México, menos de 3% de los hogares tienen Internet de banda ancha. La forma de resolver este problema es desarrollar un estándar que pueda ser producido en masa, y así alterar la ecuación de costo radicalmente. Lo que necesitamos para los próximos quince años, es un equivalente a Ethernet, pero en el aire.

y COFETEL facilitándoles información y experiencia de otros países, para que puedan tomar la mejor decisión. Una discusión que tenemos actualmente en varios países, incluido México, es que se pretende regular en base a tecnología. Por ejemplo, “este espectro se va a utilizar para cierta tecnología (3G, WiMAX, etc.)”. Esto es una mala idea porque la tecnología está en constante evolución y siempre viene algo nuevo. Los gobiernos deben tener una mentalidad de “Ok, queremos que nuestro país se conecte al Internet, así que vamos a tomar este espectro de frecuencia y utilizarlo para ese propósito, independiente de la tecnología”. En cuanto a la elección de espectros específicos, creo que el de los 700MHz es excelente por su eficiencia. En muchos países van a pasar varios años antes de que esté disponible. Sin embargo, yo creo que la decisión inteligente para cualquier país que quiera tomar ventaja, sería crear espacio en este espectro, y utilizarlo para conexión de banda ancha al Internet”.

rrolladores se distraigan en asuntos de plataforma y no se enfoquen en crear aplicaciones nuevas.

Tecnología vs. Aplicaciones

Lo que siempre sucede es que primero se instala la tecnología, y posteriormente se desarrollan las aplicaciones que la hacen útil. Compartiré una anécdota con ustedes: en 1992, durante una sesión de trabajo con el CEO de Intel, estábamos revisando las ventas de procesadores, que tenían incrementos de 30% anual, y juntamos esto con que cada 18 meses se duplicaba el poder de procesamiento. Al graficar esto, nos dimos cuenta que la cantidad total de procesamiento que se fabricaría en 1995, sería igual al total acumulado en la historia del hombre. Nos sentamos sorprendidos y dijimos “wow, algo realmente grande tiene que pasar ...” y unos años después se dio el boom del Internet. Algo similar sucede ahora con los dispositivos móviles. La mayoría de las personas pronto traerán consigo una buena cantidad de poder de procesamiento, que estará con ellos todo el día. Eso nunca ha sucedido, y alguna consecuencia debe tener. Los desarrolladores deben imaginar ese mundo y pensar: ¿qué aplicación escribiría si supiera que el usuario siempre estará disponible?”.

Mensaje para Lectores de SG

En inglés hay una frase que dice “hay que seguir el sonido de los tambores” (para saber donde está la guerra). Actualmente alrededor del 35% de los microprocesadores fabricados son para dispositivos móviles. Para el 2009 se espera que esto supere el 50%. Así que mi recomendación para ustedes es “sigan los MIPS” (millones de instrucciones por segundo), y los MIPS se están haciendo móviles. La mayoría del buen software móvil aún está por desarrollarse. Esa es una gran oportunidad para ustedes..

Espectro de Frecuencia y Regulaciones

La asignación del espectro de frecuencia es un tema de gran importancia. Tarde o temprano todo mundo estará conectado al Internet, y esto sucederá a través del espectro de frecuencia. Así que es un tema de importancia social, no sólo tecnológica. En México, estamos trabajando junto con la SCT

Killer Applications

Las killer applications para dispositivos móviles todavía están por llegar. La velocidad con que se genera un killer app, es una función de cuántos desarrolladores de software creativos están pensando en ello. Conforme hay mayor estandarización en la plataforma, este número será mayor. Uno de los problemas de la industria de software es su fragmentación. Esto ocasiona que los desaPorcentaje de procesadores para dispositivos móviles.

www.softwareguru.com.mx

SEP-OCT 2005

EN PORTADA

Software para Teléfonos Celulares

Una Realidad Por Ulises Martínez, Ángel Mendoza y Amaury Perea Matsumura

Actualmente el número de líneas celulares en México asciende a 60 millones, con un incremento de casi 25% en el 2004. Esto significa que existen más teléfonos que usuarios de Internet. El Internet ha tenido un gran avance, pero existe un factor que ha cambiado: el usuario. Ahora, el usuario es móvil, y tiene la facilidad de poder hacer desde su teléfono muchas de las cosas que antes hacía en su computadora personal. Hoy en día abundan los servicios de mensajes escritos. Sin embargo, la siguiente generación de servicios son las aplicaciones que hagan uso de los recursos de los teléfonos nuevos como conexiones de banda ancha, pantallas de mayor tamaño y definición, mayor almacenamiento, etc. En este artículo, gracias a nuestra experiencia en el desarrollo de software para este sector, hablaremos sobre algunas de las tecnologías más usadas para el desarrollo de aplicaciones en teléfonos celulares, así como algunos puntos importantes a considerar.

Tecnologías para Transmisión de Datos

En el mundo, la tecnología predominante de los operadores celulares es GSM, un estándar desarrollado en Europa que permite la transmisión de datos a una tasa promedio de alrededor de 8Kbps. En contraparte, los norteamericanos desarrollaron su propio estándar: CDMA One, que ofrece capacidades similares a GSM. Conforme los servicios de valor agregado fueron tomando el lugar que actualmente tienen en el mundo móvil, la necesidad de mayor velocidad de transmisión fue evidente, y ambas tecnologías han ido evolucionando para cubrir esta necesidad. La siguiente tabla muestra la evolución de estos estándares:

GSM

CDMA

GPRS 114 kbps

EDGE 384 kbps

WCDMA 2 Mbps

CDMA 2000 1X

CDMA 2000 EV-DO

CDMA 2000 EV-DV

114 kbps

2.4 Mbps

3.1 Mbps

Actualmente en México, los operadores GSM (Telcel y Movistar) empiezan a evolucionar a EDGE, en tanto que los operadores CDMA (Iusacell y Unefon) tienen redes CDMA 2000 1x y empiezan a evolucionar a EV-DO. Recuerden que una conexión a Internet por teléfono típicamente es de 56Kbps.

J2ME

J2ME (Java 2 Micro Edition) está enfocado para ser usado en dispositivos con recursos limitados. Tiene una sola parte de las clases de J2SE, las necesarias para poder manejar los recursos de un teléfono celular. La tecnología J2ME se ha difundido ampliamente en los últimos años en más de 110 operadores telefónicos alrededor del mundo, tanto GSM como CDMA, gracias a que es independiente de la estructura de red o de un modelo de negocios determinado. Además, existe una gran base de programadores Java, que sin mucho esfuerzo dan el salto a J2ME. Debido a la gran variedad de marcas y modelos de teléfonos, SUN definió el MIDP (Mo-

bile Information Device Profile) para establecer los requisitos con los cuales las compañías productoras de dispositivos deben cumplir para poder ser catalogados como dispositivos que soportan J2ME. En una primera etapa se definió MIDP 1.0, el cual era muy general y por eso no incluía algunas características de los teléfonos más recientes. Debido a esto, compañías como Nokia y Samsung, lanzaron clases propias para sacar mayor provecho de los recursos de sus teléfonos, no contemplados en la versión MIDP 1.0. Posteriormente se definió a través del JCP (Java Community Process), la versión 2.0 del MIDP, que contiene más clases para utilizar los recursos del teléfono. Además de las clases estándar del MIDP, existen “clases opcionales” que permiten ocupar más recursos de los dispositivos actuales, como son: multimedia, graficación 3D, manejo de los archivos del teléfono, envío y recepción de mensajes de texto y multimedia, implementar web services, entre otros.

Ulises Martínez Gilbón, Angel Mendoza Ruíz y Amaury Perea Matsumura son parte de nGWiSE® Comunicaciones, empresa mexicana formada por un grupo de ingenieros egresados de la Facultad de Ingeniería de la UNAM, y están dedicados a la integración de servicios web y móviles, así como a la capacitación de personal en estas áreas. www.ngwise.com, contacto@ngwise.com

SEP-OCT 2005

www.softwareguru.com.mx

Existen herramientas de desarrollo gratuitas que pueden ser descargadas del portal de Sun Microsystems (ver Programación – J2ME, pg. 32). Además, compañías como Nokia, Motorola, Sony-Ericsson, entre otras, cuentan con sitios para desarrolladores, donde es posible descargar especificaciones técnicas, emuladores y herramientas de desarrollo.

BREW (Binary Runtime Environment for Wireless)

BREW es una plataforma para el desarrollo de aplicaciones móviles creada por Qualcomm. Consiste en un SDK y un modelo de distribución, es decir, dentro de las funcionalidades que ofrece BREW se tiene el kit de desarrollo de software (SDK), para la creación de aplicaciones, y el sistema de distribución que controla el operador, por lo que BREW ya cuenta con un sistema para los procesos de descarga, tarifa y pago de servicios que el proveedor de telefonía celular no tendrá que implementar independientemente. El SDK que BREW ofrece se encuentra basado en el lenguaje de programación C++, por lo que hereda todas las ventajas y desventajas que se tienen al programar en este lenguaje. Esta herramienta brinda APIs para interactuar con los recursos del teléfono, como pantalla, teclado, audio, conexiones, sistema de archivos, etc. El sistema de distribución y tarifa que implementa BREW permite al usuario ver las aplicaciones que ofrece el Operador, así como su descripción y precio, y si así lo desea, comprar y descargar la aplicación. La compra puede ser por uso o por periodo de tiempo, y el cobro se hace automáticamente al tiempo aire del usuario o a su saldo. En México, Iusacell ya ofrece BREW, y próximamente Unefon lo agregará a sus servicios. Hace dos años se formó en la Facultad de Ingeniería de la UNAM un laboratorio de desarrollo de aplicaciones móviles, en el cual se creó IUSAGOL, un servicio para la consulta de información de fútbol que permite recibir los marcadores de los juegos y el video de los goles al momento que suceden, actualmente es distribuida para los usuarios de 3G de Iusacell.

Consideraciones al Crear una Aplicación

Algunos de los principales aspectos a tener en cuenta al desarrollar aplicaciones móviles son: • Tamaño de pantalla. El principal limitante de una aplicación para dispositivo móvil es el tamaño de la pantalla. Por esto es importante delimitar la aplicación para mostrar al usuario solamente los elementos indispensables. Lo aconsejable es acomodar de una manera óptima todos los elementos gráficos para que sean www.softwareguru.com.mx

claros y legibles al usuario. Es necesario también en la aplicación poder ajustar en tiempo de ejecución el entorno gráfico, ya que con esto será posible hacer una sola aplicación que funcione en teléfonos con diferentes tamaños de pantalla, en vez de hacer una con cada una de las dimensiones. Esto es aconsejable, sin embargo, no siempre es posible. • Teclado. La interacción con el usuario se hace mediante las teclas tanto alfanuméricas como los llamados SoftKeys, que están junto a la pantalla, por lo tanto se deben considerar todos los eventos cuando el usuario apriete estas teclas, reconocer qué es lo que desea hacer y determinar si se ignora o se hace algo en el programa. • Capacidad de almacenamiento. Las aplicaciones deben hacerse con códigos eficientes y compactos, además de tener un buen manejo de las imágenes, ya que son las que acostumbran tener el mayor impacto en el tamaño de la aplicación. Las aplicaciones en BREW ocupan de 50 hasta 300Kb de espacio, mientras que las aplicaciones J2ME deben de ser de menos de 60Kb para los teléfonos con MIDP1.0 y pueden ser de más en los teléfonos nuevos con memorias externas. • Conexión de datos. Las conexiones de datos harán más versátiles a las aplicaciones móviles, ya que permiten hacer consultas a bases de datos externas, usar servicios web, audio y video, entre otras muchas cosas. Cuando se diseñe la comunicación entre el dispositivo móvil y un servidor, debe considerarse el ancho de banda del medio y procurar solamente enviar la información más relevante, pensando en tiempo y dinero del usuario.

Conclusión

En un futuro próximo, hablando de redes de datos, la necesidad de clientes robustos móviles, llevarán a la creación de aplicaciones que residan en los teléfonos, quizá en una primera etapa para el sector comercial y empresarial, como pueden ser aplicaciones bancarias, colecta de pedidos de venta, vigilancia de cámaras de seguridad, etc. Después, de entretenimiento e información, como consulta de noticias, información de tráfico, buscador de calles y lugares, comercio móvil (M-Commerce). Las herramientas de desarrollo existen, el conocimiento en programación sobra, sólo falta poner manos a la obra y encontrar la llamada killer application, que marcará el inicio de las aplicaciones móviles como algo indispensable. JUL-AGO 2005

EN PORTADA

WAP y WML El Dúo Dinámico Por Jorge Jasso

Una de las tecnologías más utilizadas para conectar dispositivos móviles a Internet es la combinación de WAP/WML. En este artículo echamos un vistazo a estas tecnologías y la forma en que se utilizan para desarrollar aplicaciones para dispositivos móviles.

guaje para crear páginas que puedan ser desplegadas en los móviles a través de interfases visuales de los micro-navegadores (WAP Browsers) hechos para tal fin. WML está definido como una aplicación XML 1.0. y se ejecuta dentro del protocolo WAP 1.0.

WAP

WML utiliza tags (etiquetas) —justo como lo hace HTML—, pero su sintaxis, como hemos mencionado, es mucho mas estricta que la de un documento HTML. Por ejemplo, los tags WML son sensibles a mayúsculas y minúsculas. Muchos de los tags de WML son muy similares a los utilizados en HTML, por lo que podemos afirmar que dada la naturaleza de ser una aplicación XML y su similitud con HTML, las páginas WAP 1.0 con WML caen en el terreno de XHTML 1.0; mientras que las páginas WAP 2.0 son del terreno XHTML 2.0.

El Protocolo WAP (Wireless Application Protocol) fue diseñado para mostrar contenido Internet en dispositivos inalámbricos, especialmente en teléfonos celulares. WAP está basado en estándares como HTML, XML y TCP/IP; e incluye las especificaciones WML, WML Script y la interfaz de aplicación para teléfonos móviles de última generación (Wireless Telephone Application Interface). WAP actualmente se utiliza entre otras cosas para operaciones bancarias, consulta de itinerario de vuelos, entretenimiento, y compras por Internet. La especificación 1.0 de WAP estuvo regida por el WAP Forum, que se fundó en 1997 por compañías como Ericsson, Motorola, y Nokia. Actualmente, y aproximadamente desde el año 2002, el WAP Forum no trabaja más como organización independiente, y se consolida como el Open Mobile Alliance (OMA), el cual es encargado de regir la especificación 2.0 de WAP y sus aplicaciones por área funcional, entre las cuales están: ÁREA FUNCIONAL Arquitectura

Multimedia Messaging Service (MMS)

ESPECIFICACIÓN WAP 2.0 Wireless Application Protocol Architecture Specification Multimedia Messaging Service Architecture Overview Multimedia Messaging Service Client Transaction Specification Multimedia Messaging Service Client Transaction SIN 101 Multimedia Messaging Service Encapsulation Specification

WML

WML (Wireless Markup Language) es el len-

Actualmente la mayoría de los teléfonos en México tienen navegadores XHTML 1.0, por lo que utilizan WAP 1.0; no obstante, los celulares con WAP 2.0 con XHTML pueden ejecutar aplicaciones WAP 1.0 hechas con WML. Celulares como el Nokia 3300 o el 6600 poseen micro navegadores XHTML versiones. 1.0 y 2.0 respectivamente.

Los decks WML

Las páginas WAP en WML son llamadas decks. Los decks se construyen en base a un conjunto de cards (el cuerpo del documento). Cuando una página WAP es accedida por un teléfono celular a través de una dirección Internet, todas las cards son descargadas desde el sitio WAP al equipo celular. Una vez cargadas en el celular, la navegación y utilización de estas páginas es por cuenta del micronavegador, por lo que, mientras no se haga referencia a otra liga WAP o no se ejecute alguna llamada a un módulo externo, no hay conexión permanente entre el celular y el sitio WAP. El siguiente es un ejemplo de un deck con su correspondiente card. Aquí se muestra la es-

tructura mínima que un documento WML debe tener: 1 <?xml version=”1.0”?> 2 <!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTDwml_1.1.xml”> 3 <wml> 4 <card id=”card1” title=”Principal”> 5 <p> 6 En este articulo de SG, 7 hablamos de WML 8 </p> 9 </card> 10 </wml>

Explicación del Código

La primera línea es la especificación del tipo de documento, en este caso, XML 1.0. Posteriormente se liga hacia la definición de tipo de documento, o DTD, de WAP 1.0. Para el caso de WAP 2.0, la sentencia sería: <!DOCTYPE html PUBLIC “-//WAPFORUM//DTD WML 2.0//EN” “http://www.wapforum.org/dtd/wml20.dtd” >

La línea 3 marca el inicio del documento WML, y en la siguiente línea se realiza la definición de la card, con su identificador y título. Este identificador permite diferenciar y hacer referencia a cards múltiples. Posteriormente creamos un párrafo con la etiqueta <p>, y dentro de él desplegamos un mensaje. Por último, cerramos los elementos, el card y el documento WML con las etiquetas de cierre correspondientes (</card>, </wml>). Noten que los documentos WML requieren que todas las etiquetas que marcan un inicio, tengan su cierre correspondiente.

Ventajas de WAP

Es de destacar la importancia de la comunicación en equipos móviles. En el caso de los celulares de última generación, este es un valor agregado con ventajas indiscutibles, ya que entre otras cosas se pueden utilizar para acceder información corporativa a través de su pantalla.

Jorge Jasso es Licenciado en ciencias de la informática por el IPN. Actualmente labora para el Instituto Mexicano del Seguro Social como responsable y líder del proyecto funcional del módulo de Salud en el Trabajo del nuevo sistema de Prestaciones Económicas. Ha colaborado como consultor independiente realizando proyectos de integración de tecnología wireless con aplicaciones Web y sistemas distribuidos utilizando Java y PHP. Su experiencia incluye desarrollo de software comercial y educativo.

SEP-OCT 2005

www.softwareguru.com.mx

cálculo de los procesadores de celulares, por ejemplo, a la fecha, la mayoría de los celulares no cuentan con capacidad para operaciones de manejo de punto flotante.

Portales WAP

El auge de los portales WAP está aún por venir, no hay muchos actualmente, dadas las limitaciones de los equipos celulares en cuanto a presentación. Los portales WAP se están enfocando a proveer funcionalidad limitada de un portal http, así como para ocio y diversión. Algunos ejemplos de portales WAP son:

Figura 1. Conexión de un dispositivo celular a Internet.

Desventajas

La primera desventaja a destacar en la comunicación a Internet por medio de WAP, es la seguridad. Este es un punto crítico, ya que a la fecha, la seguridad en este tipo de conexión está a cargo de la red GSM del proveedor del servicio; y en el caso de aplicaciones empresariales, a través de los servidores de la empresa, a los que se accede por Internet (Ver figura 1).

Sin embargo, el panorama no es tan malo, ya que en general las compañías celulares tienen una infraestructura de seguridad bastante buena, lo que ayuda a mantener a salvo las políticas de seguridad y confidencialidad de las llamadas, datos y todo lo que pueda haber en un equipo celular. Otra desventaja de WAP son sus limitaciones para proveer capacidades ricas de presentación, además de la ya citada poca potencia de

www.infoclima.com/wap – Pronóstico del tiempo. mobile.google.com – Google para dispositivos inalámbricos. mail2web.com/wap – Portal para acceder servidores de correo. Recuerden que para acceder a estos sitios, su celular debe contar con acceso a Internet vía GPRS (General Packet Radio Service).

CASO DE ESTUDIO

Pruebas Controladas de

MoProSoft Experiencia en la Implantación Por Claudia Alquicira y Angélica Su

Como ustedes saben, una de las estrategias de ProSoft es alcanzar niveles internacionales en capacidad de procesos, y como parte de esta estrategia se creó MoProSoft (ver “Tejiendo Nuestra Red”, pg. 6). La preocupación posterior fue cómo demostrar que realmente se está cumplimiento con lo establecido en MoProSoft. Fue así que surgió el Método de Evaluación, EvalProSoft, desarrollado en conjunto por miembros del grupo editor de MoProSoft, y expertos en evaluaciones en estándares internacionales. En este artículo, las autoras, quienes forman parte del grupo editor de MoProSoft y EvalProSoft, comparten su experiencia en el proyecto de pruebas controladas de este modelo. Proyecto de Pruebas Controladas Podríamos decir que la creación de MoProSoft y de su Método de Evaluación, fue la parte fácil de todo este esfuerzo. El reto ahora era comprobar que el modelo funcionaba en la vida real, es decir que era aplicable a empresas mexicanas dedicadas al desarrollo de software. Estas pruebas del modelo se realizaron con apoyo de la Secretaría de Economía, en un proyecto denominado Pruebas Controladas de MoProSoft. La parte fundamental de este proyecto fue la participación de las cuatro empresas mexicanas seleccionadas: Magnabyte, E-Genium, Arquitectura en Tecnología de México (ARTEC), y Sistemas de Gestión Administrativa (SGA).

Estrategia de Implantación de MoProSoft Por ser MoProSoft un modelo de reciente creación, lo importante era definir la estrategia de implantación en las empresas. Una estrategia de implantación para cualquier modelo de referencia tiene que estar basada en lo que se quiere alcanzar. Bajo esta premisa, era importante definir MoProSoft por Niveles de Capacidad, para poder indicar a las empresas piloto, cual era el camino a seguir. Para este trabajo utilizamos como base la sección 5. Marco de Medición de Capacidades del Proceso del estándar ISO/IEC 15504-2. La razón de realizar este trabajo fue porque el Método de Evaluación se basa en este estándar para evaluar los niveles de capacidad de los procesos. El resultado de este trabajo lo bautizamos de cariño como “MoProSoft Coloreado”. Los factores que fundamentan la definición de esta estrategia son: • La definición del nivel de capacidad a alcanzar en cada uno de los procesos. La regla consistía en que cada proceso debía estar un nivel

SEP-OCT 2005

arriba del resultado que se obtuviera en el diagnóstico inicial. • La definición de las reglas de ajuste de los procesos. Se utilizaron los procesos de MoProSoft como base, se establecieron las secciones del proceso sobre las cuales podrían hacer adaptaciones, así como recomendaciones de ajustes genéricos que aplicaban a todos los procesos. El siguiente elemento fue definir el Plan de Procesos y el Plan General de Implantación que utilizaríamos. En estos documentos se estableció el orden de definición e implantación de los procesos. Dado que Gestión de Procesos es el motor del modelo, fue el primer proceso por definir en conjunto con el proceso de Conocimiento de la Organización, ya que éste permite que se mantenga la integridad de la información generada por la organización. Posteriormente el proceso que establece orden y da lineamientos a nivel organización y debe mostrar su compromiso en este esfuerzo, era Gestión de Negocio, así que este es el siguiente en la lista. Una de las restricciones con las que se contaba era el tiempo, por lo que se decidió definir los procesos de la categoría de operación: Administración de Proyectos Específicos y Desarrollo y Mantenimiento. Adicionalmente era importante motivar a la organización a definir y mejorar procesos que ya utilizaban en la práctica por ser parte de su experiencia y conocimiento, y para poder aplicarlo en proyectos piloto, que les permitiera empezar a ver resultados a corto plazo. Posteriormente para poder ligar la operación con la administración, se definió Gestión de Proyectos, y el proceso de Gestión de Recursos. www.softwareguru.com.mx

Como hemos mencionado, la definición de la estrategia de implantación se basó en la propia aplicación del proceso de Gestión de Procesos y de la experiencia propia de consultoría. La estrategia de implantación que se utilizó en cada empresa está constituida por las siguientes fases: • Planeación del proyecto de mejora (Plan de Procesos) • Definición de los procesos (Documentación de Procesos) • Implantación

Definición de los Procesos

Una de las decisiones que se tomó, fue que la definición e implantación se realizaría en forma iterativa. Es decir, se define el proceso, se capacita en éste y se pone en marcha en la organización. La capacitación y puesta en marcha se hacía en paralelo con la definición del proceso de la siguiente iteración. Esta decisión de realizar la implantación de forma iterativa permite a la organización madurar y mejorar sus procesos, e ir realizando el despliegue de los procesos de forma escalonada.

La verificación del ajuste al proceso, era una actividad de nuestra responsabilidad como consultoras, e incluía la revisión del cumplimiento de reglas de ajuste de procesos, y la verificación de la consistencia entre los documentos definidos para el proceso, y entre todos los procesos.

Experiencia en la Empresa Para iniciar con el pie derecho en el proyecto de Pruebas Controladas, primero realizamos la reunión de inicio, con la finalidad de confirmar el compromiso del director de la empresa y los miembros de la organización. Sin embargo, era importante que supieran de qué se trataba el modelo en el que se acaban de comprometer, por tanto se dio una capacitación introductoria. En la mayoría de las empresas participó un alto porcentaje de los involucrados directamente en el desarrollo de software, y la parte directiva de la misma.

Planeación del Proyecto de Mejora La planeación del proyecto se realizó en una reunión con el responsable de Gestión de Procesos para el establecimiento del alcance del proyecto de mejora en su organización, definiendo los responsables de cada proceso, los recursos que se iban a requerir para la implantación, el plan de manejo de riesgos, la definición de los proyectos pilotos candidatos y la fecha de la evaluación final. Toda esta información se consolidó en el Plan de Procesos. El Plan de Procesos se validó con el director de la empresa, para obtener su apoyo y compromiso de que lo establecido en éste se llevara a cabo. www.softwareguru.com.mx

Para definir los procesos, primero se presentaba el proceso al responsable del mismo, y en caso de existir, al equipo de definición. El ajuste al proceso estaba a cargo del responsable, y consistió en la integración de las prácticas (actividades, herramientas, procesos, procedimientos o metodología) de la organización a los procesos MoProSoft, así como la definición o ajuste de plantillas, que sustentarían los productos establecidos en el modelo.

Implantación Para iniciar con la implantación de los procesos se confirmaron los proyectos candidatos a pilotos para poner en marcha los procesos definidos. Los responsables de los procesos definidos proporcionaron la capacitación del proceso ajustado al resto de la organización. Las consultoras asesorábamos en dudas que surgían en la organización en llevar a cabo a los procesos, que en ocasiones implicaba realizar ajustes a los mismos. Adicionalmente, se realizaban sesiones con los responsables de procesos, para verificar que sus actividades se realizaran conforme a lo definido. Durante esta etapa, fue de gran importancia la participación de los equipos de trabajo involucrados en los diferentes proyectos.

Experiencia en Consultoría Como resultado del esfuerzo realizado, en las cuatro empresas piloto se elevaron los niveles de capacidad de procesos. Esto se pudo comprobar mediante la aplicación de evaluaciones (assessments). Este resultado significó lo siguiente: • El modelo MoProSoft puede ser utilizado exitosamente en empresas pequeñas de desarrollo de software. • Establecer el camino a seguir utilizando MoProSoft por niveles de capacidad, permite a las empresas definir metas alcanzables que los motiva a continuar con la mejora de procesos. • Se verificó que para poder implantar exitosamente MoProSoft es necesario implantar en primera instancia el proceso de Gestión de Procesos, a pesar de que en un principio fue difícil conseguir este compromiso. • Las empresas piloto entendieron que es importante no sólo tener bien definidos los procesos relacionados con la operación de la administración y desarrollo de software, sino SEP-OCT 2005

CASO DE ESTUDIO

Dado que Gestión de Procesos es el motor del modelo, fue el primer proceso en implantarse.

Magnabyte es una de las empresas que participó en el proyecto de pruebas controladas. Esta es la narración de la gente de Magnabyte involucrada en el proyecto: Magnabyte, siendo una empresa “típica” mexicana, decidió participar en el concurso de selección de las cuatro empresas “piloto” para implantar MoProSoft y tuvo la fortuna de ser seleccionada. Para iniciar con el proyecto piloto, se realizaron pruebas controladas utilizando el modelo de EvalProSoft. En esta etapa, el equipo de consultores y evaluadores le dio a conocer el método de evaluación al personal de Magnabyte. Posteriormente, se realizó la evaluación inicial mediante entrevistas al personal de la empresa, documentos como encuestas, evidencias de procesos y de productos, etc. a los evaluadores. La información obtenida les permitió que demostraran la capacidad y nivel de madurez real de los procesos y productos de nuestra organización según MoProSoft. Después, el equipo evaluador nos dio a conocer los resultados obtenidos y el nivel inicial de madurez de nuestros procesos. Al conocer los resultados nos llevamos una gran sorpresa; definitivamente, no logramos los resultados que se esperaban. Realmente, creíamos tener un mejor control en nuestros procesos pero gracias a esta evaluación nos dimos cuenta de que tenemos grandes áreas de oportunidad en la empresa. De nueve procesos evaluados, sólo alcanzamos el nivel 1 en 2 de ellos, en los demás salimos en 0. El objetivo propuesto por el equipo evaluador para la implantación de MoProSoft en Magnabyte fue subir un nivel en cada proceso evaluado.

que es básico establecer una planeación estratégica y soportarla con la gestión de recursos. • Después de haber realizado las primeras iteraciones, las empresas realizaban tareas por cuenta propia y la parte de consultoría sólo la verificaba, por lo que demostraba el compromiso de la organización. • Con base en la experiencia de este proyecto se documentaron las sugerencias de mejora desde el punto de vista de consultoría. • Se obtuvo una retroalimentación bidireccional entre organizaciones y consultoras, por la misma concepción del proyecto. Es decir, se estableció un acuerdo de colaboración mutuo y no como tradicionalmente

se realiza, la contratación de consultores para proveer un servicio. • Al término de la consultoría, las empresas mostraron su interés de continuar con el esfuerzo de mejora basándose en MoProSoft.

Para la implantación del proyecto piloto se asignaron tres consultores: un consultor capacitado en MoProSoft y dos consultores en formación, quienes nos apoyaron en la capacitación, planeación, definición e implantación de nuestros procesos de acuerdo a MoProSoft. La consultoría se realizo a través de visitas en sitio una vez a la semana, durante 6 meses. En Magnabyte, también se formó un excelente equipo de trabajo, que contó en todo momento con el compromiso de la alta dirección y con el apoyo de todo el personal. Este apoyo se tornó imprescindible conforme avanzó el proyecto.

Herramientas

Los avances y beneficios obtenidos, se observaron en poco tiempo. Los más notables fueron la mejoría de la comunicación en la organización, la concentración y fácil acceso a la información. Esto nos permitió aprovechar mejor los recursos y nos está dando muy buenas bases de crecimiento.

Evaluación final

Ya que finalizó el periodo de implantación, se presentó nuevamente el equipo evaluador. Nos dio una capacitación breve de Evalprosoft, el método para realizar la evaluación final, y nos comunicó la agenda para realizarla. En este momento, y después de haberlo platicado con nuestros consultores, Magnabyte le comentó al equipo de evaluación que creíamos haber alcanzado un nivel más alto al esperado en cinco de los nueve procesos. Después de una larga semana de evaluación, finalmente nos entregaron los resultados y efectivamente logramos nivel dos en cinco de los nueve procesos, con lo cual superamos el objetivo inicial.

Finalmente, es importante mencionar que por ser un proyecto de mejora, algunos elementos presentados en este trabajo pueden variar con base al contexto de cada organización. En este caso, por ser un proyecto de Pruebas Controladas, se utilizó la misma estrategia en las cuatro empresas, teniendo buenos resultados en todas ellas.

Durante la implantación de MoProSoft, nos apoyamos en algunos productos que Magnabyte comercializa: • QPMX – Administración de procesos • SINA – Control de las actividades administrativas. • Gestar – Administración de flujos de trabajo (Workflow).

Dificultades Encontradas

No todo fue fácil, en un inicio sí tuvimos algunos contratiempos y confusiones. Nos enfrentamos a la resistencia al cambio en algunas áreas, pero la adaptación a las nuevas formas de trabajo se dio relativamente rápido. También hubo problemas de comunicación y entendimiento en algunas áreas del desarrollo de software. Una de las situaciones especiales que tuvimos que resolver, fue como manejar los desarrollos que se dan como mantenimiento a nuestros productos, sin tener un requerimiento formal de un cliente.

Siguientes Pasos

Actualmente seguimos trabajando para que toda la organización alcance el nivel 2 y de ahí continuar elevando la madurez de nuestros procesos, para ofrecer mayor calidad en nuestros servicios. Ah, y claro, también estamos apoyando a la SE y a la AMCIS para que MoProSoft se convierta en Norma Mexicana lo más pronto posible.* Dení García y Claudia Ramos, Control de Calidad y Capacitación. Magnabyte * Este texto fue escrito antes de que MoProSoft fuera aprobado como norma mexicana

Claudia Alquicira trabaja en Avantare Consutores como consultor en programas de mejora en organizaciones de desarrollo de software. Claudia cuenta con una Maestría en Ciencias de la Computación y sus áreas de interés son la ingeniería de software, calidad y tecnología orientada a objetos. Angélica Su es Consultor en Procesos de Software y Administrador de Proyectos. Participó en la elaboración de MoProSoft y EvalProSoft, en la implantación de MoProSoft en proyectos pilotos, en el proyecto de Pruebas Controladas. Ha trabajado en proyectos de mejora en la realización de diagnósticos y evaluación formal CBA-IPI y asesoría en procesos basados en SW-CMM, CMMI e ISO 9000.

SEP-OCT 2005

www.softwareguru.com.mx

PRÁCTICAS PROGRAMCIÓN

J2ME

Los Midlets han dejado de ser aplicaciones sólo para juegos.

DESARROLLO DE APLICACIONES PARA TELÉFONOS CELULARES Por Víctor M. Quijano

n este artículo hablaremos de conceptos básicos de J2ME, la versión de Java para dispositivos móviles, y aprenderemos a hacer un “hola mundo”.

Los dispositivos móviles están en todas partes, en particular los teléfonos celulares; tan simple como mirar a las personas en la calle, 4 de cada 10 tiene un teléfono celular. Gartner estima que en el 2005 se venderán 750 millones de unidades en todo el mundo, lo que significa un 13% de aumento respecto al 2004. Más que una evolución, es una explosión de dispositivos móviles. Existen varios lenguajes (tecnologías) para programar teléfonos celulares, como BREW, Symbian C++, J2ME, etc. Para fines de este artículo vamos a experimentar con J2ME. La Tabla 1 muestra un pequeño listado de diferentes aparatos y sus capacidades.

Modelo

Marca

Memoria

Pantalla

J2ME?

3220

Nokia

3 Mb

65K colores

MIDP 2.0,

128 x 128 pixels,

128 kb tamaño

5 líneas

máx. de archivo JAR

Z600

Sony

V3 Razr

K700i

2 Mb

Ediciones de Java La plataforma Java está compuesta por tres ediciones distintas: • Java 2 Edición Empresarial (J2EE), para servidores empresariales y estaciones de trabajo que integran sus operaciones entre clientes, proveedores y empleados. • Java 2 Edición Estándar (J2SE), para su uso en computadoras personales y servidores. • Java 2 Edición Micro (J2ME), para dispositivos móviles.

Conceptos básicos en J2ME ¿Cómo puede correr Java en un refrigerador, en un celular, en un PDA? Para responder a esta pregunta se requiere explicar cuatro elementos importantes: (Ver Fig. 1)

TFD, 65K colores. MIDP 1.0 128x160 pixels

Motorola 5.5 Mb

TFT, 256K colores.

MIDP 2.0, 100 kb

176x220 pixels,

tamaño máx de

9 líneas

archivo JAR

Figura 1. Conceptos en J2ME.

TFT, 65k colores.

MIDP 2.0

Sistema Operativo - Sistema que controla las funciones básicas del dispositivo, por lo general cerrado y propiedad del fabricante. Maquina virtual (JVM) - Java es un lenguaje interpretado que requiere de una

41 Mb

Ericson

176x220 pixels, 7 líneas

3320

Nokia

S40

Siemens -

Figura 2. Configuraciones en J2ME.

Perfiles (profiles) - Son librerías de alto nivel que se agregan a la configuración o también por tipos de aplicación; los perfiles son específicos al tipo de dispositivo. Un perfil puede ser agregado a otro perfil. De ahí que los fabricantes como Nokia provean APIs de programación para sus modelos más recientes.

Ericson

Sony

máquina virtual, sin embargo, la JVM de un PDA no es la misma que un servidor corporativo, intervienen factores como el recolector de basura, el tamaño de la pila, entre otros. Configuraciones - La configuración define el núcleo de J2ME (runtime environment) en la JVM. Se incluye un subconjunto de clases de la edición estándar de Java (J2SE), mas las clases específicas de J2ME por familias (dispositivos con características similares). (Ver Fig. 2)

Al mencionar las siglas CLDC/MIDP nos referimos a la configuración (CLDC) y el perfil (MIDP) para programar aplicaciones Midlets en teléfonos celulares. Existe una natural resistencia a programar Midlets. Por ejemplo, alguien

Víctor Manuel Quijano Abán es candidato al grado en la maestría en sistemas computacionales, egresado del Instituto Tecnológico de Mérida. Actualmente trabaja en un corporativo de medios de comunicación y ha trabajado en centros de investigación, gobierno federal y conservación en medio ambiente. Empezó a programar antes de que aparecieran las primeras PCs y es aficionado a los lenguajes scripts y código multiplataforma.

SEP-OCT 2005

www.softwareguru.com.mx

puede decir “yo soy un programador Java de aplicaciones corporativas”, ¿cómo afecta al ciclo de desarrollo Java el uso de configuraciones y perfiles? Las configuraciones aceptan archivos Java (.class) y JAR, la diferencia está en el compilador y la forma de compilar. El principal cambio es no usar la versión más reciente de Java; SUN recomienda JSDK 1.3 (sí, leyó usted bien); en sí, con Java 2 es suficiente. Recuerde que si maneja adecuadamente sus variables de ambiente, como JAVA_HOME, es posible tener varias versiones de JDK instaladas en una computadora.

Hola Mundo Midlet Ahora vamos a hacer el ejemplo clásico, un hola mundo (HolaMidlet). El código lo vamos a comentar y razonar línea por línea. Favor de verificar que tenga la versión 2 de Java instalado en su computadora (se probó con buenos resultados JSDK 1.4.2 para Windows). Luego se debe instalar la herramienta Wireless Toolkit 2.2 (WTK) de Sun. Una vez instalados, pruebe el buen funcionamiento al correr un proyecto demo (ej. Demo3D) con el programa Ktoolbar localizado en Inicio/ Programas/J2ME Wireless Toolkit. *Nota: Al momento de escribir este artículo ya estaba disponible la versión 2.3 beta, para los aventureros.

nos pedirá nombre del proyecto y clase principal para ejecutar nuestra aplicación. Los pasos en orden son: 1. Crear un nuevo proyecto (New Project) o abrir uno existente (Open Project). 2. Configurar la aplicción Midlet (Preferences). 3. Compilar (Build). 4. Ejecutar (Build). 5. Empacar en archivos JAR y JAD (Project/ Package/Create Package).

La configuración es importante para distribuir la aplicación (Preferences en el paso 2), y son parte de la especificación del archivo JAD: Opciones Midlet-JAR-Size

Midlet-JAR-URL Midlet-Name Midlet-Vendor Midlet-Version MicroEditionConfiguration MicroEdition-Profile

Descripción Tamaño del archivo JAR. El WTK lo pone en automático Dirección Web donde se descarga el archivo Nombre de aplicación Autor CLDC 1.0 en nuestro caso MIDP 1.0 en nuestro caso

Las configuraciones opcionales son: Opciones Midlet-Data-Size

En la figura 3 se observa que es un entorno bastante simple pero carece de un editor de texto. Para el ejemplo es suficiente NotePad. Este entorno está basado en proyectos, por lo que se requiere crear uno. A continuación, www.softwareguru.com.mx

Al crear un proyecto, el WTK, también crea una estructura de directorios. En este caso en el directorio c:\WTK2.2\HelloMidlet con los siguientes subdirectorios: Carpeta Bin Classes Lib Res

*Nota: La mayoría de los equipos con MIDP 1.0 sólo soportan archivos JAR máximo 64K. Sin embargo, los equipos más recientes vienen con MIDP 2.0 y mayor capacidad de almacenamiento, algunos incluso utilizan tarjetas de ampliación de memoria.

Tabla 2. Archivo JAD.

Figura 3. Ktoolbar.

Con la opción User Defined el usuario puede ingresar sus configuraciones personales o que dependan del equipo.

Descripción Cantidad de memoria (mínima) que requiere utilizar la aplicación en el equipo Midlet-DeleteMensaje que se mostrara cuando Confirm se intente eliminar la aplicación del equipo Midlet-Description Breve descripción Midlet-Icon Asociado a la aplicación en formato PNG Midlet-Info-URL Liga de la empresa desarrolladora Liga de notificación Midlet-InstallNotify MicroEdition-Profile MIDP 1.0 en nuestro caso

Tabla 3. Configuración en WTK.

Src Tmplib, tmpclasses

Contenido Archivos JAD y JAR *.class de Java Otras clases ya compiladas Imágenes y otros datos que se utilizaran *.java Archivos temporales

Programar Midlets recuerda mucho a programar Applets, los cuales cayeron en desuso (mejor dicho, se perdió el gusto de programarlos). Un MIDlet hereda o extiende la clase javax. microedition.midlet.MIDlet. Los métodos requeridos son: • startApp - Inicia la aplicación. • pauseApp – Pausa la aplicación. • destroyApp – Destruye la aplicación, para que pueda ser eliminada de memoria. Como pueden ver, un Midlet incluso tiene un comportamiento más simple que el de un Applet (arranca, para y se detiene). El siguiente código muestra el esqueleto mínimo de un MIDlet: 1

import javax.microedition.midlet. MIDlet;

2 3

public class HolaMidlet extends MIDlet

{

5 6

public HolaMidlet (){}

public void startApp(){}

public void pauseApp(){}

public void destroyApp(boolean unconditional){}

10 }

El código anterior es un código zombie, camina pero no reacciona. Para corregir esto SEP-OCT 2005

PRÁCTICAS PROGRAMCIÓN

falta el manejo de eventos, lo cual requiere implementar la interface CommandListener y esto nos lleva a definir el método CommandAction(). Para hacer esto, agregamos el import correspondiente: import javax.microedition.lcdui. CommandListener;

En nuestro constructor vamos a inicializar el valor de los objetos display y cmdExit.

1 import javax.microedition.midlet.MIDlet; 2 import javax.microedition.lcdui.

display = Display.getDisplay(this);

CommandListener;

cmdExit = new Command(“Salir”, Command.

3 import javax.microedition.lcdui.Display;

EXIT, 1);

4 import javax.microedition.lcdui.Command; 5 import javax.microedition.lcdui.

La instancia de clase cmdExit muestra en pantalla la palabra “Salir” con la función de más alta prioridad (1) y que sea del tipo EXIT.

Displayable; 6 import javax.microedition.lcdui.TextBox; 7 8 public class HolaMidlet extends MIDlet

y modificamos la definición de la clase: public class HolaMidlet extends MIDlet implements CommandListener {

¿Qué nos falta? Implementar el método CommandAction. public void commandAction(Command c,

implements CommandListener {

Falta agregar el texto “Hola mundo móvil”, lo cual haremos utilizando un objeto TextBox, que permite al usuario ingresar y editar texto.

Primero importamos la clase correspondiente import javax.microedition.lcdui.TextBox;

Displayable s)

private Display display;

private Command cmdExit;

12 13

private TextBox tbxMain;

// constructor

public HolaMidlet () {

display = Display.getDisplay(this);

cmdExit = new Command(“Exit”,

tbxMain = new TextBox( “HelloMidlet”

y definimos el objeto

{ if (c == cmdExit) { destroyApp(false);

private TextBox tbxMain;

notifyDestroyed(); } }

Para que esto funcione, es necesario importar las clases correspondientes a Command y Displayable.

Command.EXIT, 1); , “Hola mundo movil”, 50, 0); 19

Posteriormente creamos la instancia de la clase TextBox, lo cual se hace indicando el título, texto de mensaje, y tamaño

tbxMain.addCommand(cmdExit);

20 21

tbxMain.setCommandListener(this); }

22 23

tbxMain = new TextBox(“HelloMidlet”, “Hola

Mundo Móvil”, 50, 0);

public void startApp() { display.setCurrent(tbxMain); }

26 import javax.microedition.lcdui.Command; import javax.microedition.lcdui.Displayable;

Por último agregamos el comando de salida, y preparamos al programa que esté al pendiente de este evento.

public void pauseApp(){}

public void destroyApp( boolean unconditional){}

Así como definir la variable cmdExit, la cual representa al comando para el botón de salida (exit). private Command cmdExit;

Ahora declaramos un objeto display, que utilizaremos como referencia a la pantalla. Primero importamos la clase correspondiente: import javax.microedition.lcdui.Display;

y luego definimos la variable a nivel de clase: private Display display;

SEP-OCT 2005

tbxMain.addCommand(cmdExit);

tbxMain.setCommandListener(this);

public void commandAction(Command c,

Después de compilar la aplicación y generar el archivo JAR correspondiente, la forma más simple para instalarla en el dispositivo es usar un cable de datos, o transmisión inalámbrica (IR o bluetooth). Como recomendación final verifique las versiones de CLDC y MIDP de su teléfono para que pueda correr en su teléfono.

{

Displayable s) 33

if (c == cmdExit) {

destroyApp(false);

notifyDestroyed();

36 37

} }

38 }

El listado final del código queda de la siguiente manera: www.softwareguru.com.mx

Conclusión ¿Por qué usar J2ME? Algunas ventajas reportadas: • Es un estándar actual de la industria respaldado por Sun Microsystems. • Puede correr en el escritorio y en dispositivos móviles. • Continuas versiones de actualización a través de un comité JCP (Java Community Process). • APIs de desarrollo de terceros para nuevas características en los equipos de nueva generación. Sin embargo, J2ME también puede tener algunas desventajas, entre las cuales están: • Es un lenguaje interpretado, una aplicación Midlet mal planeada puede ser lenta. • La memoria libre de cada teléfono y el ta-

maño máximo del archivo JAR/JAD. • Aritmética de punto flotante no implementada en versiones anteriores. Los Midlets han dejado de ser aplicaciones sólo para juegos, pasando por aplicaciones personales y ahora llegan al ambiente corporativo con acceso a bases de datos. J2ME es una tecnología madura. Lleva seis años de vida y se dice que lo mejor está por venir. ¿Usted qué opina?

Referencias • “J2ME Building Blocks for Mobile Devices”. KVM and the CLDC. SUN. USA. 2000 • “J2ME technology turns 5!”. developers.sun.com

• Sun Java Wireless Toolkit java.sun.com/products/sjwtoolkit/ • “Gartner Says Mobile Phone Sales Rose 17 percent ...” www.gartner.com/press_releases/asset_ 127760_11.html • J2ME Polish: Device Database www.j2mepolish.org/devices-overview.html

Recuerda veriﬁcar las versiones MIDP y CLDC de tu teléfono

PRÁCTICAS ARQUITECTURA

ebXML

EL FUTURO DE LA INTEGRACIÓN ENTRE EMPRESAS Por Atanacio Reyes

urante más de veinte años, el intercambio electrónico de datos (EDI) ha permitido a las empresas realizar transacciones electrónicas, minimizando costos y errores ocasionados por capturas múltiples, y mejorando la eficiencia en el intercambio de información comercial. A pesar de estos beneficios, EDI tiene varias inconveniencias. Las empresas chicas no siempre tienen la capacidad de integrarlo con sus sistemas internos. Adicionalmente, se requiere la contratación de redes de valor agregado o VANs (Value Added Networks), lo cual eleva los costos. Por otro lado, EDI se basa en el modelado de información usada en transacciones, lo cual provoca que la sintaxis no siempre se ajuste con la semántica de los procesos usados en todas las empresas, dificultando una integración completa. ebXML (Electronic Business using eXtensible Markup Language), es un conjunto de especificaciones que habilitan a las empresas para realizar negocios a través del Internet. ebXML viene a convertirse en la evolución de EDI, aprovechando sus ventajas y corrigiendo sus debilidades. Aprovecha la extensibilidad y flexibilidad de XML en la estructura, sintaxis y semántica de documentos, facilitará la negociación de acuerdos, y brindará una mejor alineación al negocio, ya que se basa en el modelado de procesos, en vez del modelado de información. En pocas palabras, se ve como la gran promesa de unificación para transacciones de cualquier tipo, no necesariamente comerciales. Los principales patrocinadores de ebXML son UN/CEFACT (United Nations Center for Trade Facilitation and Electronic Business) y OASIS (Organization for the Advancement of Structured Information Standards). Sin embargo, cientos de compañías y agencias gubernamentales alrededor del mundo apoyan esta iniciativa y contribuyen a su desarrollo. De hecho, cualquiera puede contribuir al desarrollo de las especificaciones, haciendo de ebXML algo universal y abierto. La primera versión de la especificación se liberó en mayo del 2001 y a la fecha es bastante madura y con gran aceptación.

Tipos de Integración Con integración nos referimos a aplicaciones que funcionan por separado, pero que comparten información de

forma automática. Existen dos tipos de integración: • Integración de aplicaciones empresariales (EAI) - Integración del software que automatiza los procesos internos de una empresa, que no son visibles al exterior. Estos procesos, sumados a la estructura empresarial, constituyen el sistema. • Integración Interempresarial (B2Bi) Concierne a la integración del software que automatiza las interacciones de los procesos externos entre empresas. Estos procesos constituyen el ambiente del sistema. En el mundo real no existen sistemas cerrados, por lo que en la práctica se deben considerar ambos tipos de integración. El software no es otra cosa que la representación lógica o simulación de un modelo, y este a su vez, es la representación del mundo real. Por otro lado, no es posible aprovechar todos los beneficios que implica la transferencia electrónica de información entre empresas asociadas, si no se cuenta con una apropiada integración hacia el interior. El modelo clásico cliente-servidor acostumbra centrarse en datos, típicamente administrados por un DBMS. Debido a que la información contenida en la BD constituye la razón de ser de una empresa, y muchas veces su ventaja competitiva no puede exponerse al exterior ni compartirse con otras empresas. Por esta razón, este modelo no puede ser empleado tal cual en B2Bi. Es aquí

donde se da cabida a otros paradigmas basados en procesos, tales como Web Services, Rosetta Net, y ebXML.

UMM UN/CEFACT Modelling Methodology (UMM) es un conjunto de reglas y procedimientos cuya visión es capturar el conocimiento de una organización, orientado a la adopción de prácticas de comercio electrónico. Se enfoca en desarrollar procesos de negocio y modelos de información en un protocolo neutral. No se enfoca en una implementación específica, ni en aspectos tecnológicos. UMM utiliza UML como lenguaje visual para modelar procesos. UMM define un meta-modelo, que provee la semántica de los procesos de negocio y sirve a la vez como patrón para desarrollar el modelo específico de una organización. Los procedimientos empleados en UMM son muy semejantes a los de MoProSoft, por lo que usar este modelo puede servir de base para entender el otro o viceversa.

Los proyectos de ingeniería de software típicamente conllevan una serie de pasos que se mueven desde un modelo independiente de la tecnología a una implementación tecnológicamente dependiente.

Atanacio Reyes Valenzuela es Lic. en Ciencias Computacionales de la Universidad Autónoma de B.C. Tiene más de 10 años de experiencia en el desarrollo de software para integración de procesos de manufactura, interconectividad entre maquinaria y equipo para la automatización, procesamiento, control, administración, cálculo geométrico y matemático. Actualmente trabaja para la empresa Augen Ópticos, dedicada a la industria óptica oftálmica en México.

SEP-OCT 2005

www.softwareguru.com.mx

UMM contempla sólo aquellos flujos de trabajo que son independientes de tecnología, tales como modelado de negocio, requerimientos, análisis, y diseño de alto nivel. Adicionalmente, UMM provee una serie de patrones con soluciones comunes para el intercambio de información entre organizaciones.

Componentes de ebXML La visión de ebXML es crear un mercado global, donde empresas de cualquier medida y en cualquier lugar puedan encontrarse y realizar negocios mediante el intercambio de mensajes basados en XML. Para que una empresa pueda realizar negocios electrónicamente con otra, primero debe descubrir los productos y servicios que la otra ofrece, después averiguar qué procesos y documentos son necesarios para acceder a tales productos y servicios, determinar cómo realizar el intercambio de información, y entonces convenir los acuerdos y condiciones necesarias para realizar las transacciones. Para facilitar el proceso, ebXML provee una infraestructura compuesta por un conjunto de especificaciones, que pueden ser adoptadas total o parcialmente: • Business Process Specification Schema (BPSS), provee una estructura estándar para la especificación de procesos de negocio. Es la semántica de un subconjunto del meta-modelo UMM. El objetivo de la especificación es que los usuarios de negocio puedan crear modelos de procesos de negocio e información visualmente (en UML), y que éstos sean interpretados semánticamente como XML por una máquina. Para lograr esto, la especificación provee un conjunto de reglas para la correspondencia entre UML y XML. • Core Components (CC). Son “bloques de construcción” que contienen piezas de información acerca de conceptos simples, que aparecen comúnmente en diferentes áreas de negocios. El trabajo en CC no está etiquetado formalmente como una especificación ebXML, sin embargo, su objetivo es facilitar el diseño de la información usada en las transacciones entre socios de negocios. • Collaboration Protocol Profiles and Agreement (CPP/A). Un CPP es un documento XML que describe las capacidades de un socio de negocios, así como su interfaz de servicios y requerimientos necesarios para la interacción. El CPP contiene información esencial incluyendo pero no limitado a: datos de contacto, clasificación industrial, transacciones posibles, protocolos posibles (HTTP, SMTP, FTP etc), propiedades adicionales (encripción, validación, verificación de autenticidad etc.). Un CPP también puede tener referencias a BPSS u otros documentos que definan los procesos y mensajes que intervienen en estos. El CPP es el mecanismo a través del cual se puede descubrir a un socio de negocios, y llegar a un acuerdo de colaboración. El acuerdo de colaboración se establece mediante otro documento llamado Collaboration Protocol Agreement (CPA), el cual captura la intersección entre los CPP en cuestión. www.softwareguru.com.mx

• Messaging Service Specification (MS). Define las interfaces necesarias para atender el empaquetado, enrutamiento y transporte de mensajes y las operaciones que deben realizar los objetos de esas interfaces. La especificación es independiente del contenido y del protocolo usado, aunque proporciona enlace con HTTP y SMTP. Se fundamenta en SOAP with Attachments (SWA), para definir la estructura y significado de los elementos que componen los documentos que se van a intercambiar, al cual le adiciona extensiones necesarias para seguridad y confiabilidad. Emplea SWA con el propósito de que el contenido útil del mensaje pueda ser definido en cualquier formato (ASC X12, HL7, EDIFACT, binarios, etc.), no necesariamente XML. • Registry/Repository (RR). Provee almacenamiento, búsqueda y recuperación de documentos y artefactos. La especificación determina qué tipo de objetos deben almacenarse en los repositorios, y la forma en que están organizados. Se establece una distinción entre registro y repositorio, de esta forma es posible implementar repositorios distribuidos accedidos a través de un registro. La implementación más común de un repositorio es mediante una base de datos relacional, aunque no está limitado a este esquema. Los objetos predefinidos para hospedaje en el repositorio son: CPP, CPA, procesos, componentes de software (EJB, bibliotecas de clases), modelos UML, esquemas XML, servicios, información de usuarios y organizaciones, además de otros objetos definidos por el usuario. El registro lo constituyen las interfaces de servicios que proveen el acceso al repositorio. Éstas son: Life Cycle Management (LM), conocida también como Object Manager. Formada por métodos necesarios para registrar, clasificar, asociar y remover objetos almacenados en el repositorio. Query Management (QM), conocida también como Object Query Manager. Controla el descubrimiento y recuperación de información del repositorio.

Los servicios de cualquiera de estas dos interfaces pueden ser exhibidos de dos formas: a) Usando la infraestructura de Web Services, para lo cual es necesario registrar un documento WSDL en un UDDI, mediante el cual se definen los servicios. La comunicación que provee este esquema es de naturaleza síncrona y usa el protocolo HTTP. b) Mediante la infraestructura de MS definida por ebXML, para lo cual es necesario el establecimiento de un acuerdo entre el cliente y el registro (CPA), en el cual se establece el protocolo, y las condiciones de seguridad y confiabilidad del intercambio de información. La comunicación en este esquema puede ser síncrona o asíncrona dependiendo del protocolo usado (HTTP, SMTP, etc). La implementación de registros y repositorios se recomienda a empresas con giros relacionados, con el fin de que puedan conducir e integrar sus procesos externos mediante los cuales se relacionan. El registro/repositorio permite a estas empresas agruparse en una comunidad o asociación.

Conclusión Tal como se mencionó anteriormente, no es obligatorio que la estructura ebXML se adopte en su totalidad. Muchos autores y empresas recomiendan implementar primero el transporte de mensajes (MS), y posteriormente implementar las otras especificaciones conforme se vayan necesitando. En un artículo próximo hablaremos con mayor detalle sobre la estructuración de especificaciones ebXML, así como la relación entre ebXML, web services y RosettaNet.

Referencias • Eric Newcomer. Understanding Web Services. Addison Wesley • ebXML. www.ebxml.org • UNECE. www.unece.org SEP-OCT 2005

PRÁCTICAS ADMINISTRACIÓN DE PROYECTOS

CADENA CRÍTICA SEGUIMIENTO Y CONTROL EFICIENTE DE PROYECTOS Por José Martín Olguín

3. Multitareas. Lo peor que puede hacer un administrador de proyectos es asignar múltiples tareas simultáneas a un mismo recurso, y todas con la misma prioridad.

uan, el administrador del proyecto, pregunta al grupo de desarrollo —¿por qué nos estamos atrasando?, y añade —No estamos cumpliendo con el calendario propuesto. Con una expresión de extrema preocupación marcada en el rostro hace “la pregunta” —¿de cuanto va a ser el retraso? — Seguramente este escenario le resulta familiar. La administración de proyectos consta de actividades clasificadas en tres áreas fundamentales: planificación, seguimiento y control. Estas tratan con el personal, el proceso y el producto involucrados en un proyecto en particular. Dentro de la planificación, la actividad crítica es la estimación, para la cual existen muchos métodos, entre los que destaca COCOMO II (ver Estimación de Proyectos, SG No. 1, 2005). Pero aun con una excelente estimación, ¿estamos asegurando el éxito del proyecto?, por supuesto que no. Tener una buena planificación no garantiza que se llevará a cabo al pie de la letra, ¿qué puede pasar?

Tiempos de Protección Los proyectos de software se caracterizan por el alto nivel de incertidumbre asociada, debido principalmente a la naturaleza intangible e intelectual del producto esperado. Por ello, es obligado tomar en consideración las actitudes del ser humano en el desarrollo de una actividad dentro de un plan de trabajo. Volvamos con nuestro atribulado administrador de proyecto, Juan. Durante la estimación, es probable que su grupo de desarrollo haya agregado un “colchón” de tiempo de protección para cada una de las actividades del plan de trabajo. Como es probable que Juan no se haya dado cuenta de eso, a su vez él agregó otro “colchón” de protección para todo el proyecto, esto lo podemos ver en la Figura 1.

En conclusión, agregar tiempo de protección a las actividades, no sirve de mucho si no se puede aprovechar el tiempo de las terminaciones anticipadas.

Cadena Crítica Figura 1. Red de actividades de un proyecto con protecciones por actividad.

La pregunta es: ¿por qué si todos agregan tiempo de protección, el proyecto inevitablemente se atrasa? Para responder esto, analizemos algunos aspectos que afectan las actividades del plan de trabajo: 1. El “síndrome del estudiante”. Como los programadores saben que cuentan con un colchón de protección, es probable que no inicien de inmediato la actividad, sino que consuman ese tiempo en otras actividades, de tal manera que empezarán hasta que sólo tengan disponible el tiempo que originalmente habían estimado. Es decir, se gastan el “colchón” antes de iniciar. Por lo tanto, si surge algún problema en el desarrollo de la actividad, al no tener protección se producirá un retraso. Es así que en el mejor de los casos, la actividad terminará en el tiempo establecido originalmente. 2. La Ley de Parkinson. Cualquier trabajo se expande hasta ocupar todo el tiempo destinado para él. ¿Cuál es el incentivo para un programador que termina su actividad con anticipación? ¿más trabajo? Si una actividad se termina antes de lo calendarizado y no existe un incentivo por terminación anticipada, el responsable de la actividad encontrará la forma de seguir trabajando en ella hasta llegar a la fecha límite. El resultado de esto, es que los retrasos se acumulan a lo largo del proyecto, pero los adelantos no impactan significativamente.

Entre las metodologías orientadas al seguimiento del progreso de los proyectos, existe una denominada Cadena Crítica (CC), enfocada al manejo de la incertidumbre inherente a todo proyecto. Se define como una cadena crítica a la secuencia de eventos dependientes que evitan que el proyecto se complete en un intervalo más corto de tiempo, donde un evento dependiente es aquel que utiliza como insumo tareas que otro evento produce, o utiliza recursos que otro ocupa. Esta última restricción es lo que establece la diferencia con la tradicional “ruta crítica”, ya que ésta última no toma en cuenta la competencia por los recursos. La metodología CC inicia con la construcción de una red de actividades compuesta por varias cadenas de actividades dependientes. Una de estas será definida como la cadena crítica y las demás como cadenas alimentadoras, que se unen a la cadena crítica en algún punto del calendario. Una característica de CC es que evita agregar tiempo de protección, o “colchón” a cada actividad. Se inicia con una estimación de la duración de cada actividad (sin “colchón”). Al final de cada cadena, ya sea crítica o alimentadora, se agrega un “amortiguador” que proteja a toda la cadena. En la figura 2 vemos un ejemplo de la ubicación de los “amortiguadores” en la secuencia de actividades y podemos apreciar que no cambia la fecha de terminación del proyecto, simplemente quitamos la protección individual de las actividades y la ubicamos al final.

José Martín Olguín tiene una maestría en ciencias de la computación y 15 años de experiencia dirigiendo desarrollos de software. Actualmente es coordinador de la maestría en computación de la UABC campus Mexicali e imparte cursos relacionados con la Ingeniería de Software a nivel licenciatura y maestría.

SEP-OCT 2005

www.softwareguru.com.mx

disponibilidad entre proyectos. 3. Identificar la cadena crítica por proyecto. 4. Ubicar amortiguadores en cada proyecto. La principal diferencia entre manejar uno o varios proyectos al mismo tiempo, es la competencia por los recursos. De esta forma, el reto más importante para CC es calendarizar los recursos compartidos de manera que estén enfocados en una tarea al mismo tiempo. Figura 2. Red de actividades con amortiguadores.

El control del proyecto se hace monitoreando el consumo de los “amortiguadores”, con este mecanismo se evita que el equipo de desarrollo tenga que reaccionar a falsas alarmas debido a pequeñas variaciones en las estimaciones del calendario inherentes a la incertidumbre de todo desarrollo de software, y se pueda concentrar cuando el peligro de no terminar en tiempo sea real. Para el seguimiento del progreso, CC se apega a las siguiente reglas: • No se establecen fechas fijas de inicio y fin de cada actividad, sólo se define la fecha de inicio de cada cadena de actividades y la fecha final de entrega del proyecto. • Las personas participantes estarán concentradas en una sola actividad a la vez. Es decir, no es posible participar en varias actividades simultáneamente. • Cada persona tendrá que reportar periódicamente el tiempo estimado para completar su actividad actual. • Cada persona deberá iniciar la actividad que le corresponda en cuanto la actividad de la cual depende sea completada. • El administrador se enfocará en la supervisión del consumo de los amortiguadores de tiempo, tomando las acciones pertinentes cuando estos consumos sobrepasen límites establecidos de antemano.

Conclusiones Aunque el método de Cadena Crítica implica más aspectos que los aquí presentados, ahora Juan ya tiene una mejor manera de organizar y darle seguimiento a su proyecto, para lo cual aprendió que: 1. No debe incluir tiempos de protección por actividad, debe hacerlo al final de las cadenas de actividades. 2. No debe establecer fechas límite por actividad para evitar el “síndrome del estudiante” y la Ley de Parkinson. Sólo se deben manejar tiempos estimados de duración por actividad. 3. Debe tomar en cuenta la competencia por los recursos y no calendarizar actividades simultáneas para un recurso. 4. Debe pedir reportes periódicos de estimados de conclusión de las actividades en curso. 5. Si una actividad se retrasa, no debe alarmarse. Los retrasos en una actividad le restan tiempo a los “amortiguadores”, pero las terminaciones anticipadas le suman tiempo. De manera que unas se compensan con las otras. 6. Sólo se preocupará cuando el consumo de los “amortiguadores” sobrepase un límite que él mismo establece. Una de las principales limitantes en la adopción de CC en las organizaciones es el cambio de cultura que implica trabajar con este concepto, particularmente en la eliminación del “colchón” de protección, mecanismo al que las personas están acostumbradas.

Cadena Crítica en Ambientes Multi-proyectos Una de las ventajas de CC es que se utiliza tanto para ambientes de un sólo proyecto como para ambientes multi-proyectos. Los pasos para la construcción de la red de actividades para este tipo de ambientes son: 1. Desarrollar la red de actividades para cada proyecto. 2. Priorizar recursos tomando en cuenta la www.softwareguru.com.mx

Referencias • Goldratt, Eliyahu. “Cadena Crítica”, Ediciones Castillo, 2000. México. • Miranda, Eduardo. “Planning and Executing Time-Bound Projects”. IEEE Computer. Marzo 2002. • Reel, John. “Critical Success Factors in Software Projects”, IEEE Software, May-June 1999.

PRÁCTICAS PROCESOS

Transición de

SW-CMM a CMMI Por Mariana Pérez-Vargas

“En la carrera por la calidad no hay línea de meta.”

ucho se ha escuchado sobre el “sunset” (ocaso) del modelo SW-CMM (Software Capability Maturity Model) para este año, así como de su reemplazo, el CMMI (Capability Maturity Model Integration). Esto ha sido motivo para generar muchas inquietudes en la industria de TI. En nuestro país, al igual que en el resto de América Latina, esta preocupación ha sido muy marcada, ya que el tema de la mejora de procesos de software es reciente. Mientras que la industria de TI en Estados Unidos tiene alrededor de veinte años utilizando SW-CMM como modelo de referencia para establecer una disciplina de procesos en las organizaciones desarrolladoras de software, en México esto tiene menos de diez años. Actualmente en nuestro país existen alrededor de diez organizaciones con algún nivel de madurez igual o superior al nivel 2 del modelo SW-CMM. Así que la industria de TI en México, apenas está empezando a dar sus primeros pasos en este tema, cuando de pronto se ve obligada a apresurar la marcha y cambiar un poco el rumbo de lo que se había contemplado seguir. Las inquietudes surgen principalmente en aquellas organizaciones que están en proceso de alcanzar determinado nivel de madurez con respecto al SW-CMM, o bien que ya lo han logrado. La preocupación de estas organizaciones, se refiere a si deben iniciar todo el proceso nuevamente y si el esfuerzo realizado fue en vano. La respuesta es no, ya que la buena noticia es que el modelo SW-CMM está contenido dentro del CMMI. Otra preocupación de las organizaciones que a través de una evaluación CBA-IPI (CMM Based Appraisal for Internal Process Improvement), lograron obtener algún nivel de madurez, es si el nivel obtenido se pierde automáticamente. La respuesta es no. Un nivel de madurez y capacidad alcanzado por una organización o área interna, no se pierde a causa del nuevo modelo. El resultado de una evaluación para determinar un nivel de madurez o capacidad, es

como una foto, que refleja en ese momento como estaba la organización, después de que la foto se reveló, se colocó en un marco y se colgó en la pared, la organización debe trabajar intensamente para conservarse “en forma” y no perder la institucionalización de las prácticas.

tegrarlos y combinarlos en un programa de mejora. El proyecto para desarrollar el CMMI fue patrocinado por el DoD (Department of Defense) y el NDIA (National Defense Industrial Association) de Estados Unidos de América, y participaron más de 100 personas del gobierno, la industria y del SEI.

¿Por qué surgió CMMI?

El modelo SW-CMM está contenido dentro del CMMI, ya que la versión 2.0 draft C, se utilizó como uno de los modelos fuente para desarrollar el nuevo modelo junto con el EAI Interim Standard 731, SECM (System Engineering Capability Model) y el IPD-CMM (Integrated Product Development Capability Maturity Model) draft versión 0.98.

Este modelo surge como una alternativa para dar solución a los siguientes cuestionamientos: • Productos más complejos que requieren de un mejor desarrollo, más rápido y a menor costo. • Modelos, estándares, metodologías y guías orientadas a áreas específicas. • Reducción de costos y eliminación de confusiones derivadas de programas de mejora basados en múltiples modelos. • Cobertura para diferentes tipos de organizaciones y proyectos • Cobertura completa del diseño y producto o del ciclo de vida del servicio y/o producto. • Administración por métricas.

La Razón de la “I” Existían muchos modelos de referencia (SW-CMM, SA-CMM, People CMM, Systems Security CMM, IPC CMM, etc.), los cuales tenían diferentes estructuras, formatos, términos y formas distintas de medir la madurez. Esto causaba confusión, especialmente cuando una organización estaba utilizando más de un modelo de referencia y era difícil de in-

La integración de estos tres modelos en el CMMI se hizo para eliminar inconsistencias, reducir la duplicidad y el costo de implantación de un modelo basado en procesos de mejora. Adicionalmente se obtuvieron otros beneficios importantes como la consistencia con ISO/ IEC 15504, uniformidad de términos y optimización de la redacción.

Mariana Pérez-Vargas, es Directora General de Avantare y Lead Assessor Certiﬁcada y Autorizada por el SEI. Cuenta con amplia experiencia para proporcionar consultoría estratégica a diferentes empresas desarrolladoras de software, áreas de desarrollo de software y organismos gubernamentales. Pionera en el área de calidad y procesos, entre sus principales logros está haber sido responsable de coordinar exitosamente el programa de mejora en la primer organización en México que se evaluó en CMM.

SEP-OCT 2005

www.softwareguru.com.mx

Las Disciplinas El CMMI integró las disciplinas de ingeniería de sistemas (SE – System Engineering) y software (SW – Software Engineering) dentro de un solo marco para la mejora de procesos y otras disciplinas como el desarrollo integrado de procesos y productos (IPPD – Integrated Process and Product Development) y la de atención a proveedores (SS – Supplier Sourcing). La estructura del modelo permite la incorporación de otras disciplinas en el futuro. • SE cubre el desarrollo completo de un sistema que puede o no incluir software. Un ejemplo de esto son los sistemas de operación que manejan instituciones financieras, aseguradoras y de aviación. • SW cubre el desarrollo, operación y mantenimiento de software. • IPPD considera la colaboración entre los diferentes involucrados durante el ciclo de vida del producto para satisfacer las necesidades, expectativas y requerimientos de los usuarios. Por ejemplo la fabricación de un teléfono celular donde se integran muchas áreas como hardware, software, diseño y mercadotecnia. • SS cubre la adquisición de productos suministrados por los proveedores. Tanto SS como IPPD se deben de utilizar en conjunto con las otras disciplinas del modelo (SE/SW). Cada una de las disciplinas tiene prácticas específicas en el modelo y deben ser consideradas en el momento de establecer el alcance del programa de mejora con base en objetivos de negocio y las necesidades de la organización.

¿Escalonada o Continua? Con la integración de los modelos en el CMMI, se encontraron con que el modelo SECM seguía la representación continua, mientras que SW-CMM utilizaba la escalonada. Y por si fuera poco, había otros que utilizaban una representación híbrida, como el IPD CMM. Esto generó una disyuntiva para el equipo que desarrolló el CMMI... seleccionar una representación. Como esto resultaba una tarea difícil, la conclusión fue dejar dos posibilidades para la representación del modelo, la escalonada y la continua para que cada organización dewww.softwareguru.com.mx

pendiendo de las necesidades del negocio y de la experiencia en la mejora de procesos seleccione la más adecuada. Ambas representaciones tienen sus ventajas: • La representación escalonada provee una ruta pre-definida para la implantación de grupos de áreas de proceso, así como una secuencia específica de implantación. Su estructura es familiar para aquellas organizaciones que están haciendo la transición de SW-CMM. • La representación continua proporciona la máxima flexibilidad para enfocarse en áreas de proceso específicas de acuerdo a las metas y los objetivos del negocio. Para las organizaciones maduras, proporciona los “siguientes pasos” para la mejora de procesos... Su estructura es familiar para aquellos que están haciendo la transición de ingeniería de sistemas.

SW-CMM vs. CMMI SE/SW El modelo CMMI SE/SW en su representación escalonada es muy similar al SW-CMM versión 1.1., esto permite que las empresas que actualmente cuentan con algún nivel de madurez de SW-CMM puedan lograr que la transición de un modelo a otro no cause un impacto fuerte en la organización y ésta se realice “suavemente” ya que pocas prácticas son nuevas en el CMMI. Más bien se trata de una re-organización y de la consideración de algunos elementos importantes que en el SW-CMM estaban ambiguos o no existían. Para lograr esta transición, las organizaciones deberán enfocarse en realizar una serie de cambios, dependiendo del nivel de madurez: Para nivel 2 la organización deberá fortalecer la

administración de requerimientos para incluir los requerimientos de software, hardware, servicios (de alto nivel), así como definir los canales de comunicación formales para obtener el entendimiento de los requerimientos. Establecer un programa de métricas, fortaleciendo las mediciones definidas para la característica común de acuerdo a SW-CMM, definiendo los procesos para la recolección y análisis. Es importante identificar las métricas que son relevantes para la organización y que deberán ir evolucionando. Definir, implantar e institucionalizar los procesos para administrar los acuerdos con proveedores, siempre y cuando sea aplicable o bien la organización adquiera algún componente que integre en el desarrollo de su producto (COTS). Adicionalmente es importante hacer explícita la revisión de la calidad a productos a través del grupo de aseguramiento de calidad. Para nivel 3, las organizaciones deberán establecer, implantar e institucionalizar un proceso pro-activo para la administración de riesgos. Definir un proceso de evaluación que permita analizar y decidir sobre las posibles alternativas, con la finalidad de reducir los riesgos en la toma de decisiones. Expandir y robustecer el proceso de ingeniería de software para el desarrollo y mantenimiento de sistemas, de acuerdo a las cinco áreas de proceso (PAs) que establece el modelo. Para los niveles 4 y 5, se obtuvo mayor claridad y organización de las áreas de proceso. Las organizaciones deberán dar mayor énfasis en la administración cuantitativa, implantando las técnicas cuantitativas de medición que utiliza la organización. Reforzar la capacitación proporcionada sobre las técnicas de análisis cuantitativo. Mejorar los datos obtenidos de las métricas mediante varias iteraciones del proceso y hacer énfasis en la innovación y despliegue organizacional, creando un grupo responsable de la recolección de las sugerencias de mejora para los procesos y la tecnología. Lo importante es definir el “cómo” con base en las necesidades del negocio, el modelo sólo es una referencia. SEP-OCT 2005

PRÁCTICAS ASEGURAMIENTO DE CALIDAD

CONFIABILIDAD DEL SOFTWARE DESARROLLANDO PRODUCTOS CONFIABLES Por Cuauhtémoc Lemus, Enrique Villa y Joaquín Arellano

oy en día encontramos software en automóviles, armamento militar, celulares, refrigeradores, etc., cada vez dependemos más de él. Sin embargo, éste no es 100% confiable y libre de errores. Todos conocemos ejemplos de software defectuoso y los daños que éste causa. Las empresas desarrolladoras de software, al igual que los consumidores de sus productos tienen un interés común, los primeros en producir y los segundos en consumir productos de software confiables. El concepto de calidad depende fuertemente del factor humano: qué es lo que nuestro cliente espera y cómo atacar esas expectativas. Esta tendencia se ha fortalecido con el paso del tiempo, debido a que las iniciativas de calidad en los negocios se han orientado al cliente y además la globalización ha propiciado una fuerte competencia entre los productores. El presente artículo tienen la finalidad de identificar las implicaciones que con llevan en desarrollar un software confiable desde la perspectiva de la empresa. Consideramos el caso en que una organización desarrolladora de software no tiene datos recolectados sobre su proceso de desarrollo y desean determinar qué tan confiable es su producto. Para ello presentamos una breve introducción sobre la dicotomía de un producto de software vs. un producto de manufactura en el plano de la confiabilidad, identificando los aspectos y conceptos principales que son la base para predecir y/o estimar la confiabilidad de un sistema o aplicación, con el objetivo de mejorar el proceso de desarrollo. Para finalizar presentamos los esfuerzos del Grupo de Confiabilidad

en Software y Sistemas de Software del CIMAT contrastando brevemente el panorama de la confiabilidad de software en México.

¿Que es la Confiabilidad de Software? El estudio de la confiabilidad del software surge en la década de los 70s con autores como Jelinski y Moranda [1], Goel y Okumoto [2] que basaban y proponían estimar la confiabilidad del software mediante modelos matemáticos basados en Procesos de Poisson No Homogéneos, (NHPP) por sus siglas en inglés. A lo largo de los años numerosos autores han propuesto diversas alternativas para medir y mejorar la confiabilidad del software. Estas son algunas definiciones populares: • “Confiabilidad de software es una de las medidas para evaluar cuantitativamente la calidad de un producto de software” [3] • “la probabilidad de que el software opere libre de fallas en un periodo de tiempo y ambiente específico” [4] Estas definiciones permiten puntualizar dos cosas: 1) la meta de la confiabilidad del software es permitir que éste funcione con el menor número de fallas posibles. 2) existe una relación estrecha entre confiabilidad y calidad del software, ya que define a la confiabilidad del software como un mecanismo cuantitativo para evaluar la calidad del software. Entonces surge la siguiente pregunta ¿cómo se puede lograr una alta confiabilidad? No hay una respuesta única, todo depende del proyecto, de la organización, del ambiente de operación y de los desarrolladores, por mencionar algunos factores. Sabemos que en la actualidad

es casi imposible desarrollar software completamente libre de errores, por lo que es claro que al medir la confiabilidad del software, los resultados son una aproximación a la realidad, por lo que los resultados de estimación o predicción de los modelos matemáticos deben de ser considerados como información para la toma de decisiones (por ejemplo, continuar o no continuar con la fase de pruebas). Sin embargo, para elevar la confiabilidad de software en un proyecto determinado, un buen inicio es modelar el proceso de inserción, detección y corrección de defectos en las diferentes fases de desarrollo. Una vez que tenemos este modelo, si contamos con la información adecuada, podemos estimar y predecir la confiabilidad del software. Este modelo puede ser de gran utilidad en la toma de decisiones relacionada con la liberación del producto, ya que permite determinar de manera óptima el tiempo de terminación de pruebas y entrega del producto. Cabe mencionar que además del amplio trabajo de modelación matemática desarrollado hasta hoy, también, pero en menor número, hay varios autores que buscan otras alternativas, que no sean modelos matemáticos, que permitan alcanzar una mayor confiabilidad del software. La literatura científica sobre confiabilidad de software contiene un gran número de procedimientos e ideas que provienen de un campo más maduro, la confiabilidad de manufactura. Esto no significa que ambos campos sean iguales y deban ser tratados de la misma forma, las ideas generales son comunes en ambos campos, pero el patrón de confiabilidad se desenvuelve de forma diferente a través del tiempo y la génesis de las fallas es muy diferente en

Cuauhtémoc Lemus Olalde se desempeña como profesor e investigador en el Departamento de Ciencias de la Computación en el CIMAT, donde es miembro de los grupos de Ingeniería de Software y Conﬁabilidad en Software y Sistemas. Se ha desempeñado como Director de Centro de Cálculo e Informática, líder de proyecto, y consultor en sistemas computacionales. Recibió su título de Doctor en Ciencias Computacionales de la Universidad de Tulane en Nueva Orléans, y realizó una estancia postdoctoral como parte del programa aéreo-espacial en el NASA-Johnson Space Center.

SEP-OCT 2005

www.softwareguru.com.mx

ambos dominios. En manufactura las fallas están asociadas a procesos de desgaste y en el software las fallas están ligadas a un proceso de inserción y corrección de defectos. Esta diferencia se expresa gráficamente en las siguientes curvas de confiabilidad para manufactura y software a continuación.

Figura 1. Curva de confiabilidad de Manufactura

La Figura 1 muestra que en la manufactura inicialmente se posee una alta tasa de fallas, que disminuye hasta alcanzar un nivel estable durante cierto tiempo y finalmente aumenta hacia el final del tiempo de vida. Observamos tres etapas en la vida de un producto de manufactura, al inicio tenemos la fase conocida como infancia o mortalidad infantil, en donde tenemos una alta proporción de fallas, debido a la presencia de componentes con fallas latentes, que lograron pasar en forma inadvertida el control de calidad pero que fallaran al empezar a trabajar. La segunda etapa, conocida como vida útil, es el período de tiempo en donde no tenemos componentes con fallas latentes y el desgaste no se manifiesta aún, ocurriendo fallas aleatorias a un ritmo estable. Finalmente tenemos el período conocido como desgaste, en donde las fallas se presentan con una tasa creciente debido al envejecimiento de los componentes por el uso constante.

Figura 2. Curva de confiabilidad del Software [6]

La confiabilidad del software típicamente se comporta como se muestra en la Figura 2. Inicialmente la tasa de errores es alta y con el tiempo va disminuyendo, debido a que el software se encuentra en su etapa de desarrollo. Esto es, cuando el software es liberado y puesto en manos del cliente, es posible hacerle correcciones, actualizaciones y mejoras, lo que provoca que la tasa de errores en la mayoría de los casos vuelva a surgir pero en menor tamaño conforme pasa el tiempo y así sigue mientras el software siga siendo funcional. Como se puede apreciar, la confiabilidad no va en aumento conforme pasa el tiempo, ésta depende totalmente del número de errores y fallas que se presenten en el software en un momento dado y cuando el software es corregido, actualizado o mejorado el grado de confiabilidad vuelve a variar y así se repite el mismo fenómeno hasta que el software se vuelve obsoleto y es remplazado por otro.

basada en información del software. Podemos hablar de la predicción de confiabilidad, en diferentes etapas del software y la manera de determinarla dependerá de la información que se tenga. De esta manera, si el software se encuentra en la etapa de prueba u operación y contamos con tiempos de inserción, detección y corrección de defectos, entonces es posible estimar los parámetros de un modelo de confiabilidad y posteriormente hacer predicciones, estimando las métricas de interés en diferentes tiempos futuros. En cambio, cuando no contamos con datos de falla del software, debido a que nos encontramos en la etapa de diseño o desarrollo, utilizamos algunas métricas y medidas obtenidas en la etapa de desarrollo del software para determinar la confiabilidad que el software tendrá en la etapa de prueba o en la liberación. A ésta se le conoce como predicción temprana de confiabilidad.

Métricas de Confiabilidad

Cuando tenemos un modelo de confiabilidad para un proyecto de software, propuesto en base al conocimiento del equipo de trabajo y a experiencia previa, podemos utilizar métodos de simulación basados en técnicas de MonteCarlo para simular los patrones de inserción, detección y corrección de defectos.

Cuando tenemos un modelo de confiabilidad de un producto de software, que describe adecuadamente los procesos de inserción, detección y corrección de defectos, entonces podemos determinar diferentes métricas relacionadas con la confiabilidad, como por ejemplo, el tiempo medio entre fallas o MTBF, (Mean Time Between Failures), la tasa de fallas y la confiabilidad. La precisión de las métricas estimadas dependerá de la calidad de los datos disponibles. Tenemos dos tipos de medición de la confiabilidad: estimación y predicción. Cuando hablamos de estimación de la confiabilidad, nos referimos a la determinación actual de la confiabilidad, haciendo un análisis estadístico de los datos de falla tomados durante las etapas de prueba y/o operación del sistema. Al estimar la confiabilidad obtenemos el valor de ésta que el sistema ha alcanzado. Además, podemos evaluar el ajuste del modelo de confiabilidad a los datos de fallas del software. La predicción de confiabilidad del software, es la determinación a futuro de esta métrica,

La aplicación de modelos de confiabilidad de software en los diferentes proyectos de una organización, además de servir para pronosticar la confiabilidad en cualquier tiempo futuro, puede ser de utilidad para calificar a los desarrolladores, ya que para cada proyecto puede determinarse el patrón de inserción de defectos, y con esto podemos evaluar a los desarrolladores de acuerdo a la tasa de defectos que introducen en el software. Esta calificación puede servir para determinar programas de capacitación o para la distribución de estímulos.

Confiabilidad de SW en México El requerimiento de software confiable se ha acentuado con el paso del tiempo, debido a que el tamaño y su complejidad son cada vez mayores, y por otro lado las exigencias de los

Enrique Villa Diharce es investigador en el Departamento de Estadística y miembro de los grupos de Estadística Industrial y Conﬁabilidad en Software y Sistemas (SOSYR) del CIMAT. Además, es instructor de cursos de licenciatura, maestría y doctorado, así como de cursos de capacitación de alto nivel en la industria, donde ha brindado asesoría a empresas como PEMEX, IMP, CFE, Mabe, e IG entre otras. Enrique recibió el grado de doctor en Ciencias con especialidad en Probabilidad y Estadística del CIMAT en 1999.

www.softwareguru.com.mx

SEP-OCT 2005

PRÁCTICAS ASEGURAMIENTO DE CALIDAD

En México, los centros de investigación y algunas empresas tendrán un papel fundamental en el desarrollo de la conﬁabilidad del software. clientes y la competencia van en aumento. En México, la investigación en confiabilidad de software es una tarea pendiente en la que tendrán un papel fundamental algunos centros de investigación y las empresas productoras de software medianas y grandes en una interacción sinérgica. Esta relación academia-industria es un factor importante para el impulso de la investigación de confiabilidad de software, debido a que una buena investigación necesita enfrentarse a problemas reales con un nivel de complejidad importante. Esta complejidad requiere de herramientas provenientes de la probabilidad y la estadística, que tienen un nivel de sofisticación notable, debido a que los modelos requeridos para analizar los patrones de falla en un determinado software, deben considerar el carácter aleatorio de la interacción desarrolladores-software-usuarios. Las empresas medianas de software en México, utilizan algunas métricas para medir la calidad de software, pero no modelan los procesos de inserción, detección y corrección de defectos. Las grandes empresas trasnacionales, tienen sus centros de investigación y desarrollo en sus países de origen, por lo cual no impulsan en nuestro país esta actividad. Esto último ocurre también en el área de confiabilidad en manufactura, en donde el trabajo de confiabilidad se lleva a cabo con frecuencia de manera mecánica, siguiendo procedimientos elaborados en los centros de investigación y desarrollo, ubicados en el extranjero. Para desarrollar investigación en confiabilidad de software se requiere de la conjunción de conocimientos de las áreas de estadística, probabilidad, ingeniería de software y control estadístico de procesos.

Estas áreas existen en el Centro de Investigación en Matemáticas (CIMAT), por lo que en tiempos recientes se ha formado el Grupo de Confiabilidad en Software y Sistemas (SOSYR) con la intención de aprovechar los recursos humanos y líneas de investigación y del conocimiento con las que cuenta el CIMAT. El grupo reúne a investigadores en las áreas anteriormente mencionadas así como con líneas de investigación establecidas en confiabilidad, estadística, probabilidad e ingeniería de software, además de contar con profesionistas a la vanguardia en calidad (control estadístico, diseño de experimento, seis sigma, etc). Los objetivos de este grupo son: impulsar el interés en confiabilidad de software en el medio académico, establecer la interacción con la industria de software con el fin de aplicar los conocimientos y hacer desarrollos orientados a coadyuvar en la solución de problemas.

Conclusión Actualmente es difícil encontrar empresas que apliquen la modelación matemática para mejorar la calidad de sus productos de software. El común denominador es más bien la falta de recolección de datos de sus procesos de desarrollo o de sus productos. Esta actitud repercute negativamente en el negocio, ya que impide el mejoramiento de la calidad de sus productos. Un panorama diferente puede lograrse a mediano o largo plazo si se siguen marcos de trabajo que implementen un proceso de recolección de datos para el análisis y su evaluación. Esto permitiría establecer un modelo de confiabilidad de software predictivo, con lo cual sería posible optimizar los procesos. El establecimiento de un sistema adecuado de recopilación de datos, requiere de un cambio cultural, que permita entender que la

toma de decisiones debe basarse en datos y no en supuestos. Independientemente de la forma en que una empresa desarrolle software, ya sea por costumbre, imposición o forma de trabajo, la calidad del software que produce es vital. Por ello, no solo es recomendable adoptar modelos y procesos como TSP/PSP, CMM, y MoProSoft, sino también reforzarlos con herramientas de calidad como el enfoque a procesos, mejora continua, control estadístico, etc., que en conjunto permitirían lograr que se desarrollara software de calidad y por ende, más confiable.

Referencias [1] Jelinski, Z., and Moranda, P.B.: “Software Reliability Research,” Proceedings of the Statistical Methods for the Evaluation of Computer System Per formance, Academic Press, 1972, pp. 465-484. [2] Goel, A.L., and Okumoto, K., “Time-Dependent Error -Detection Rate Model for Software and Other Performance Measures,” IEEE Transactions on Reliability, vol. R-28, no. 3, August 1979, pp. 206-211. [3] Yi-Ping Chang, “An Alternative reliability evaluation of non-homogeneous poisson process models for Software Reliebility”, Emerald Group Publishing Limited, 2000, pp. 800-811. [4] Kanoun, K., “Measurements for Managing Software Reliability”, Proceedings of the 1999 IEEE Symposium on Application - Specific Systems and Software Engineering and Technology, March 24 - 27, 1999. [5] Pan, Jiantao, Software Reliability, Carnegie Mellon University, 18-849b Dependable Embedded Systems. Spring 1999.

Joaquín A. Arellano Ramírez es desarrollador y administrador de sistemas de información. Sus áreas de interés incluyen plataforma WEB, aplicaciones Windows y la aplicación e investigación de Técnicas de Producción de Sistemas Computacionales y Confiabilidad del Software. Joaquín cursa el octavo semestre de la carrera de Ingeniero en Sistemas de Información en el Instituto Tecnológico de Monterrey Campus Zacatecas y es miembro de la comunidad NetSewers ubicada en la ciudad de Guadalupe, Zacatecas.

SEP-OCT 2005

www.softwareguru.com.mx

UML

Especificaciones de Casos de Uso LO QUE BIEN COMIENZA, BIEN ACABA Por Sergio Orozco

i entra basura, sale basura... una gran verdad en cualquier proceso, a menos que te dediques al reciclaje de desechos. Los proyectos de software no son la excepción; si no iniciamos el desarrollo partiendo de requerimientos correctamente establecidos, tendremos muchos problemas para lograr que al final todos los involucrados queden satisfechos.

Evitando Malentendidos Como es bien sabido, la mayoría de las fallas en los proyectos de software se debe a una mala administración de requerimientos. Un ejemplo en este sentido suele ser un mal entendimiento de los requerimientos entre usuarios y desarrolladores. Aún y cuando el equipo de desarrollo cree comprender lo que el cliente le está solicitando, existe una buena probabilidad de que no sea así. Incluso me atrevo a decir que en la mayoría de las ocasiones lo que yo he visto es que en las primeras etapas ni siquiera el cliente está totalmente consciente de qué es lo que quiere o necesita. Ahí es donde el analista entra al rescate, pues debe facilitarle al usuario expresar sus necesidades para validarlas posteriormente mediante mecanismos eficientes de comunicación que ambos entiendan. Un ejemplo excelente de estos mecanismos son las especificaciones de casos de uso.

Aclarando el Panorama Partiendo de la premisa de que ya se identificaron los actores y casos de uso apropiados del sistema (ver número anterior: Casos de Uso y el Valor del Sistema) lo que corresponde es detallar los pasos necesarios para cumplir con dicho caso de uso. Para especificar cada caso de uso deberíamos de tomar en consideración los siguientes aspectos: 1. Interacciones.- Mencionar la participación

del actor primario y la de cada actor secundario desde que inicia el caso de uso hasta que termina. 2. Eventos.- Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos, etc.). 3. Nivel de detalle.- Los casos de uso y sus especificaciones son la base del contrato que establecemos con nuestro cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la funcionalidad del sistema, más precisas serán las estimaciones de nuestro plan de trabajo. 4. Escenarios.- Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de explicar cada uno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y de excepción. 5. Claridad y Enfoque de Usuario.- Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la hora de redactarlo, sin mencionar detalles técnicos a los que el usuario está acostumbrado. Sobre todo te interesa poder validar con éste que lo documentado en las especificaciones de casos de uso es lo que requiere para su sistema, así que si no los entiende no cumplirán su propósito principal. Vale la pena recalcar que durante los cursos y consultoría que impartimos a los analistas, les pido que me “platiquen” de qué se trata el caso de uso solicitado por su cliente, y después escribimos eso mismo en las especificaciones, generalmente logramos así un documento más claro que cuando lo escriben directamente sin platicarlo. La experiencia me dice que, por lo menos en sistemas, la gente explica mejor las cosas oralmente que de forma escrita.

He aquí el ejemplo de la descripción del flujo para el caso de uso “Registrar venta”: Flujo principal del caso de uso “Registrar Venta” • El vendedor solicita el registro de una nueva venta. • El sistema solicita los datos de cada uno de los productos de la venta. • El vendedor registra la cantidad y clave de cada uno de los productos. • El sistema muestra la lista de productos con su cantidad, clave, descripción, subtotal, IVA y total. • El sistema solicita el tipo de pago. • El vendedor indica pago al contado o con tarjeta de crédito. • Dependiendo de la selección, comienza el flujo alterno “Pago al contado” o “Pago con tarjeta de crédito”. • Una vez realizado el pago, se registra la venta, se actualiza el inventario e imprime el ticket correspondiente. • Termina el caso de uso. Flujo Alterno: Pago al Contado • El vendedor registra el monto recibido de parte del cliente. • El sistema calcula y muestra el cambio a devolver. • El vendedor devuelve el cambio al cliente.

* Debido a las limitantes de espacio, este ejemplo es una versión simplificada de la especificación de un caso de uso, ya que sólo incluye el flujo principal y uno de los flujos alternos. La versión completa de la especificación se encuentra disponible en www.milestone.com.mx/EjemplosUML/ EspecificacionCU.htm

Sergio Orozco es director general e instructor senior en Milestone Consulting, empresa especializada en capacitación práctica, consultoría y venta de herramientas en UML, CMM y orientación a objetos. Su experiencia proviene desde que UML se convirtió en estándar internacional por la OMG; Milestone es miembro de dicho organismo. www.milestone.com.mx, info@milestone.com.mx

SEP-OCT 2005

www.softwareguru.com.mx

Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso. Sin embargo, puedo asegurarte que la esencia es lo mencionado anteriormente. Algunos de esos elementos extra con los que puedes complementar tu plantilla para documentar tus especificaciones de casos de uso son: • Propósito. Si comienzas por este punto se te facilitará definir los pasos más relevantes para ejecutar el caso de uso. • Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El estado en que se debe encontrar el sistema antes de ejecutarlo. (Ej: Algún catálogo debe estar actualizado, debe estar en conexión con otro sistema, el usuario debe estar conectado con cierto perfil específico). • Postcondiciones. Te indica como queda

el sistema después de ejecutar el caso de uso. Imagina que eres un tester y quieres comprobar si alguien acaba de ejecutar el caso de uso. ¿Qué cosas buscarías en el sistema? Seguramente datos nuevos, modificados, eliminados o la posibilidad de elegir nuevas opciones en el sistema. • Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado. • Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>. En los cursos prácticos de UML que impartimos, una de las inquietudes que nos expresan más frecuentemente los analistas es el hecho de que el cliente no está dispuesto a pagar el esfuerzo requerido para realizar la “documentación” que implica especificar los casos de uso. El error,

en primer lugar, es que no lo deberíamos de ver como “la documentación” del sistema, sino como una herramienta para esclarecer lo que quiere que le construyamos. Si no se especifica claramente qué es lo que quiere/desea/necesita el cliente entonces resulta una adivinanza saber cuánto nos vamos a tardar, y por lo tanto cuánto nos va a costar desarrollarlo. En este sentido dependerá del contexto del proyecto el nivel de detalle a realizar, y por lo tanto la cantidad de “documentación” generada para especificar los casos de uso. Sólo hay que tomar en cuenta que entre menos precisión y detalle haya, mayor será el riesgo de no tener un proyecto exitoso. Así que no nos debe de sorprender que si entra basura, con bastante probabilidad, saldrá basura.

FUNDAMENTOS

Ingeniería de Requerimientos Una Especificación Necesaria Por Jorge Becerril

“No hay nada más difícil de conseguir, más arriesgado de mantener ni más inseguro de tener éxito, que estar a la cabeza en la introducción de un nuevo orden de cosas...” —Maquiavelo

Hasta hace pocos años no sabía de la importancia de la ingeniería de requerimientos, hasta que me di cuenta de que gran parte de las fallas de los sistemas que desarrollaba el equipo de trabajo se debía a la pobre o nula especificación de requerimientos. De acuerdo con el Standish Group, los requerimientos incorrectos o incompletos son la principal causa de fracaso en los proyectos de software. Otro dato importante es que siempre resultará más barato la identificación y corrección de errores en la etapa de requerimientos que en posteriores etapas de desarrollo, tal como se refleja en la figura 1. Todo esto resalta la importancia de un correcto trabajo de ingeniería de requerimientos.

Obtención Consiste en averiguar y capturar las funcionalidades que deberá proveer el sistema de información a sus usuarios. Para obtener los requerimientos, el ingeniero de requerimientos interactúa con los usuarios y se vale de técnicas como: • Entrevistas • Observación de la operación • Revisión de sistemas actuales • Revisión de documentos existentes como formas, reportes, procedimientos, descripciones de puesto entre otras. • Escenarios • Reuniones

Análisis y Negociación Una vez recabados los datos, el ingeniero de requerimientos le dará forma y orden, clasificará cada uno de los requerimientos, resolverá conflictos encontrados en la información y opcionalmente modelará los procesos para poder tener un mejor entendimiento del problema.

Especificación

Cuando realicé mis estudios universitarios, recuerdo que dentro de las carreras de sistemas computacionales no existían materias donde se abarcará el tema de requerimientos. Creo que es parte vital de la formación de los profesionales en Ingeniería de Software, y debe ser tomado en cuenta por las instituciones académicas. ¿Y qué es lo que abarca la ingeniería de requerimientos? De acuerdo con el SWEBOK (Software Engineering Body of Knowledge), el área de conocimiento de requerimientos de software se preocupa por la obtención, análisis, especificación y validación de requerimientos de software. Analicemos cada uno de estos subprocesos:

Esta es la parte más importante del proceso de requerimientos. Aquí es donde se documenta la información basándose en estándares como lo es el IEEE Std 830 (estándar para la especificación de requerimientos de software). Uno de los productos más importantes que se genera en este subproceso es la especificación de requerimientos de software, o SRS (Software Requirements Specification), documento muy conocido dentro de la industria de software, ya que no se puede concebir una buena documentación de sistemas sino existe un SRS.

Validación La validación de requerimientos se lleva a cabo en varios pasos. El primer

paso es la revisión por parte de varios grupos de interés mejor conocidos como stakeholders y por parte del grupo de desarrollo. Lo que se intenta lograr es que la especificación se lleve a cabo correctamente en base a los estándares existentes. El siguiente paso es la elaboración de prototipos. Las imágenes dicen más que mil palabras, y el desarrollo de software no es la excepción. Un prototipo ayuda a verificar que se han entendido bien los requerimientos, y a su vez es una herramienta que acerca a los usuarios a lo que será el software. Bien podríamos decir que el prototipo es “la maqueta” de lo que será el sistema terminado. En lo particular también me ha servido para hacer el esqueleto de la aplicación.

Otras Consideraciones Es importante recordar que la ingeniería de requerimientos es un proceso continuo que se lleva a cabo a lo largo de todo un proyecto, y no simplemente un conjunto de actividades que se realizan una sola vez al inicio del proyecto. Conforme el proyecto avanza, los requerimientos se pueden ir refinando y validando, y hasta es posible que surjan algunos nuevos. Por ello, una buena administración del cambio en los requerimientos es un factor indispensable para el éxito de un proyecto de software.

Referencias • Leffingwell, Widrig, Managing Software Requirements, Addison Wesley, 1999 • Software Engineering Body of Knowledge. www.swebok.org

Jorge Becerril es Líder de Proyecto de Grupo Carbel Laboratorios Farmacéuticos, tiene 10 años de experiencia como desarrollador de software, es egresado de la Universidad del Valle de Atemajac de la Carrera de Sistemas Computacionales con Orientación a Ingeniería de Software. jorge_becerril@yahoo.com

SEP-OCT 2005

www.softwareguru.com.mx

PRUEBA DE SOFTWARE

COLUMNA

Caracterización de la Prueba de Software Clasificación y Técnicas

n este número esbozaré algunas de las técnicas más comunes de prueba de software, de acuerdo con los criterios de clasificación más usuales. En www.e-quallity.net pestaña Definiciones → Conceptos puede encontrarse mayor profundidad.

Composición Interna del Componente Se refiere al nivel de conocimiento de la estructura interna del sistema a probar (SUT: System Under Testing), que el tester requiere para realizar la prueba. Técnicas comunes son: • Pruebas de caja negra (black-box testing, o “pruebas de funcionalidad”): centradas en verificar si los requerimientos son satisfechos. Las pruebas de volumen y de stress (rendimiento con grandes cantidades de datos, y con bloques de datos por unidad de tiempo, respectivamente), son casos especiales de este tipo de prueba; otras técnicas son la de clases de equivalencia y la de valores límite. • Pruebas de caja blanca (white-box testing, o pruebas “de código/diseño”): se revisan, entre otras cosas, el diseño y código fuente para verificar que sigan los estándares especificados, los algoritmos sean adecuados, y la arquitectura sea apropiada. Técnicas comunes son el análisis de algoritmos, la cobertura de decisiones, las revisiones entre pares y las recorridas.

Granularidad del Componente Se refiere al tamaño de los elementos del SUT que se van probando. Hablamos de: • Pruebas de unidad: se prueba por separado cada “elemento mínimo de procesamiento” definido por la organización (objetos, componentes, módulos, funciones). Las técnicas más utilizadas son las de caja blanca. Típicamente, son realizadas por el equipo desarrollador. • Pruebas de integración: se verifica la interacción entre unidades con técnicas como pruebas de interacción y de mutación. Suelen ser ejecutadas por el equipo de prueba. www.softwareguru.com.mx

• Pruebas de sistema: se verifica el sistema como un todo, aplicando pruebas de caja negra utilizando perfiles de usuario, haciendo v.gr. pruebas como configuración, seguridad, confiabilidad y recuperación. Debieran ser ejecutadas por el equipo de prueba. • Pruebas de aceptación: se verifica la satisfacción de requerimientos con técnicas como pruebas-α y pruebasβ, descritas más abajo. Debieran ser llevadas a cabo por un equipo que incluya al cliente, usuario(s) y testers. Es común que en los esfuerzos de desarrollo se aplique un solo subconjunto de estas técnicas, guardando el orden en que se acaban de describir.

“Dirección de Avance” en la Prueba Para probar el SUT se diseñan casos de prueba; llamamos pruebas progresivas a la primera vez que éstos son aplicados. Esa primera fase detecta defectos que luego son corregidos por el equipo desarrollador. A la versión corregida debieran aplicársele nuevamente los casos de prueba, o al menos un subconjunto de ellas, porque puede ocurrir que en realidad no se realicen las correcciones necesarias, o que las correcciones generaren otros defectos. A la repetición de la aplicación de un subconjunto de casos de prueba la llamamos pruebas regresivas. La elección del subconjunto es muy importante y debe realizarse bajo criterios bien definidos y en acuerdo con el responsable general del proyecto. Aún cuando en principio se pudieran tener cuantos ciclos regresivos se quisiera, en realidad un número pequeño de ellos muestra tendencias que permiten tomar decisiones (como rehacer un componente). Para aprovechar al máximo la inversión en las pruebas, en todo proyecto debiera ejecutarse al menos un ciclo de pruebas de regresión, que per-

mitiera revisar los resultados de las correcciones realizadas.

Control sobre el Ambiente de Prueba Distinguimos dos ambientes: • Pruebas-α (α-testing), llevadas a cabo de manera controlada en un laboratorio de pruebas que trata de reproducir el ambiente en que corre el SUT. • Pruebas-β, realizadas al SUT en su ambiente real de aplicación. Es deseable llevar a cabo ambas fases en este orden, o en el peor de los casos, en paralelo. Sin embargo, hay ocasiones en que es difícil reproducir el ambiente de aplicación y sólo se llevan a cabo las pruebas-β.

Otros Criterios Otras características del SUT que llegan a imponer restricciones al probar son la plataforma de desarrollo y el dominio de aplicación en que opera. La primera puede requerir ciertas técnicas/herramientas de prueba (v.gr. para probar firmware); la segunda puede exigir cierta profundidad en la prueba que facilite alguna certificación (v.gr. en equipos médicos). La aplicación apropiada de estas técnicas constituyen actividades centrales del proceso de prueba de software; cuales de ellas se apliquen es una decisión crucial que depende de las características de cada proyecto.

Luis Vinicio León Carrillo es profesorinvestigador del Departamento de Electrónica, Sistemas e Informática del ITESO, y director general de e-Quallity S.A. de C.V., empresa especializada en prueba de software. Luis Vinicio es doctorando por la Universidad Técnica de Clausthal, Alemania; su trabajo predoctoral giró alrededor a la aplicación de los lenguajes formales en la Ingeniería de Software. Es coautor de un marco tecnológico que hoy permite a e-Quallity desarrollar empresas de prueba de software. Luis Vinicio es co-fundador y Secretario actual del Capítulo Guadalajara de la AMCIS.

- Luis Vinicio León Carrillo

Referencias • www.e-quallity.net pestaña Definiciones → Conceptos. • Jorgensen, P.: Software Testing. CRC Press; 2002. • Beizer, B.: Software Testing Techniques. International Thompson Computer Press; 1990. • Kit, E.: Software Testing in the Real World. ACM Press; 1995. SEP-OCT 2005

TECNOLOGÍA

WSN

Redes Inalámbricas de Sensores Por J. Antonio García y Christian P. García

Desde hace más de una década, visionarios como Mark Weiser han hablado de ambientes saturados de elementos con capacidades de cómputo y comunicación totalmente integrados a nuestras actividades cotidianas, los cuales proporcionan información y servicios “cuando sea y donde sea”. En estos ambientes —llamados de cómputo ubicuo—, cuando se habla de dispositivos con capacidad de computación y comunicación, no sólo se refiere a los dispositivos portátiles tales como PDAs y smartphones, sino también a dispositivos embebidos en el entorno físico de los usuarios, es decir, automóviles, casas, carreteras, centros comerciales, etc. Un elemento importante para hacer realidad estos escenarios que parecen de ciencia ficción, lo constituyen las redes inalámbricas de sensores (WSN, por sus siglas en inglés). En efecto, si el entorno debe reaccionar a ciertas condiciones que se presenten, primeramente se deben conocer dichas condiciones, siendo ahí donde entran en juego los sensores.

Aplicaciones Los elementos necesarios para conformar las WSN se encuentran ya disponibles comercialmente. Por lo tanto, ya se están aplicando dichas redes en ámbitos tan diversos como la agricultura, el sector militar, la geofísica, etc. Una aplicación interesante se ha dado en los países escandinavos, donde al colocar sensores de movimiento sobre cerdos y otros animales de corral se sabe, con base en el patrón de movilidad, cuando dichos animales están en época reproductiva. En California y Nevada se han hecho estudios para determinar la propagación de incendios, medir la intensidad de los mismos y cuantificar los niveles de contaminación consecuentes. En el noroeste de Estados Unidos y sur de Canadá se utilizan redes para censar parámetros que influyen en la calidad de la uva para vino, tales como la temperatura y la humedad. De hecho, no necesitamos ir tan lejos para buscar ejemplos, pues este tipo de aplicaciones de monitoreo de campos agrícolas también se está gestando ya en nuestro país, particularmente en Baja California; en efecto, mediante una colaboración entre Instituto Nacional de Investigaciones Forestales, Agrícolas y Pecuarias (INIFAP) y el Centro de Integración de la Innovación Tecnológica (CENI2T), se está desarrollando el hardware, el software y las aplicaciones específicas para mejorar la calidad de los cultivos, minimizar la ocurrencia de plagas y optimizar el uso de recursos como pesticidas y, sobre todo, agua.

¿Qué las hace diferentes? Existen diferencias significativas que hacen a las WSN muy diferentes de las redes tradicionales, inalámbricas o no. Tal vez la diferencia más notoria, de donde derivan muchas otras, se encuentra en el hecho de

Aplicación agrícola de WSN

que los nodos de las redes no son computadoras, impresoras, dispositivos de conmutación u otros similares. En el caso de las WSN, los nodos son pequeñas unidades (del tamaño de una caja de cerillos) que tienen solamente unos pocos kilobytes de memoria, un procesador de unos cuantos MHz, una unidad de radiocomunicación de pocos metros de alcance, y una fuente de poder consistente en una o dos baterías tipo AA. Y lo más interesante es que, con tan limitados recursos, se espera que estas redes sean capaces de realizar enrutamiento, hacer agregación de datos, correr aplicaciones, autoconfigurarse y operar en forma desatendida por varios meses o incluso años. Resulta fácil imaginar entonces, que desarrollar algoritmos, protocolos y sistemas para este tipo de redes presenta retos muy interesantes.

Programación de las WSN Actualmente los desarrolladores tienen que programar casi directamente sobre la plataforma de hardware (sensores), pues no existen bibliotecas, APIs, middleware, frameworks, toolkits, ni otras herramientas de software que permitan abocarse al problema en cuestión sin que la plataforma constituya otro problema más. Por otra parte, las arquitecturas tradicionales de sistemas operativos para sistemas empotrados

J. Antonio García Macías es investigador en el CICESE (www.cicese.mx) y director de un proyecto sobre WSN en el CENI2T (www.ceni2t.com). Christian P. García Martínez es ingeniero senior en el CENI2T.

SEP-OCT 2005

www.softwareguru.com.mx

no resultan ser siempre las más adecuadas cuando se piensa en WSN, esto es debido al espacio de almacenamiento y capacidad de memoria que requieren, así como a la carga que representa la implementación de funcionalidades que resultan ser innecesarias para aplicaciones específicas; además, el manejo del hardware resulta costoso en términos de complejidad y consumo de energía. Es por ello que surgen nuevas propuestas como el sistema operativo TinyOS, cuya finalidad es la de reducir el uso de espacio en memoria y el “overhead” del sistema. El TinyOS es un sistema operativo basado en eventos, desarrollado para correr en WSN, y actualmente es el más utilizado en este tipo de sistemas. Se distingue entre otros ya que permite a las aplicaciones manejar el hardware directamente, no existe el concepto de kernel, no maneja memoria virtual ni memoria dinámica, se compila junto con la aplicación incluyendo sólo los módulos requeridos por la aplicación evitando así agregar funcionalidad innecesaria al sistema operativo. Para implementar aplicaciones en TinyOS se utiliza una extensión del lenguaje C que se denomina nesC. Los programas en nesC básicamente están hechos con componentes, los cuales están ligados entre sí mediante interfaces claramente definidas; estas interfaces permiten a cada componente ofrecer servicios a otros componentes o bien utilizar servicios de otros componentes. Así, TinyOS no

es otra cosa más que un conjunto de componentes predefinidos que permiten manipular el hardware. Luego, los servicios que estos componentes ofrecen a través de sus interfaces pueden ser utilizados por cualquier otro conjunto de componentes creados por cualquier programador y así es como se crea una aplicación en TinyOS con nesC.

Conclusión Las redes inalámbricas de sensores no son solamente un tópico de investigación en la academia, pues ya existen productos disponibles comercialmente que permiten establecerlas y utilizarlas. El desarrollo de este tipo de redes plantea nuevos problemas en ingeniería de software y hardware, pero a su vez acerca más a la realidad escenarios que antes se pensaron como ciencia ficción. En nuestro país se están dando los primeros pasos no solo para la utilización de las WSN, sino también para su desarrollo.

Referencias • M. Weiser. “The Computer for the Twenty-First Century”. Scientific American, vol 265, no 3, Septiempre. 1991. • Ian F. Akyildiz, et al. “A Survey on Sensor Networks”. IEEE Communications Magazine, Agosto. 2002.

TECNOLOGÍA

Hewlett-Packard

iPAQ hx4700 Una PDA perfecta para el ejecutivo de hoy, elegante y poderosa. Seguramente lo mejor y más atractivo de la 4700 es su pantalla LCD de 4 pulgadas, que ofrece colores profundos y vibrantes, aún en luz directa. Un procesador de 624MHz es el responsable del poder de esta miniatura. El problema es que no hay muchas aplicaciones en el mercado que tomen ventaja de su poder de procesamiento y la pantalla VGA, aunque esto cambiará en un futuro cercano. En otros detalles, en lugar del tradicional botón de navegación, tiene un touchpad con funciones similares, pero no es muy amigable para los usuarios con manos grandes, por lo que se puede optar por el stylus. El acceso al escritorio de la PC funciona sin problemas por la conexión Wi-Fi, al igual que la navegación en Internet con Pocket Internet Explorer. Para finales de año las aplicaciones que aprovecharán todo el poder de esta iPAQ estarán disponibles en el mercado, convirtiéndola, efectivamente, en la PDA más poderosa que se puede adquirir.

Kingston

Data Traveler Elite Aunque no es exactamente lo más sobresaliente en cuanto a diseño, este dispositivo de memoria flash no sólo ofrece desde 256MB y hasta 4GB de espacio para almacenamiento, sino que además, gracias a un procesador de 32-bit, puede manejar un proceso de encripción y decripción. Para hacer uso de esta característica, se incluye el programa TravelerSafe+, que puede convertir hasta 99% del espacio en una partición encriptada con el protocolo 128-bit AES. MyTraveler, otra aplicación incluida, permite sincronizar a través de un sencillo panel de control, las carpetas Mis Documentos, Mis Favoritos y una tercera, definida por el usuario. Estos beneficios adicionales, una alta velocidad de transferencia y la reconocida calidad a nivel mundial de la marca en cuanto a memoria se refiere, hacen de la Elite Traveler una de las mejores opciones en cuanto a dispositivos de almacenamiento compacto en la actualidad.

SEP-OCT 2005

Samsung

SyncMaster 241MP Los televisores LCD son una herencia del mundo de las PC, y como tal, los fabricantes buscan que el próximo TV que llegue a los hogares sea delgado y plano. La vanguardia en equipos LCD es la entrada de la computadora a los electrónicos de consumo y un ejemplo son los monitores de doble función. El SyncMaster 241 MP es un display widescreen de 24 pulgadas, que incluye las conexiones requeridas para su uso en una computadora y un sintonizador de televisión, así que es perfecto para trabajar o tenerlo en una pequeña habitación de medios. Su resolución es de 1920x1200 pixeles, por lo que puede usarse para trabajar en aplicaciones de diseño. www.softwareguru.com.mx

COLUMNA

CÁTEDRA Y MÁS

Conectividad Continua La Sociedad de los Dispositivos Móviles

El Dr. Raúl A. Trejo es profesor investigador del Departamento de Sistemas de Información en el Tecnológico de Monterrey, Campus Estado de México. Sus áreas de especialidad incluyen Ingeniería de Software, Representación del Conocimiento y Algoritmos Computacionales. El Dr. Trejo gusta de participar en proyectos que involucren el trabajo cercano con estudiantes, como el Proyecto Principia de Integración Curricular del Campus Estado de México, o el Concurso FIRST de Robótica de la NASA. Ha presentado ponencias en conferencias tales como Americas Conference on Information Systems, Internacional Joint Conference on Artificial Intelligence y el Internacional Symposium on Scientific Computing, Computer Arithmetic and Validated Numerics y publicado artículos en la revista Artificial Intelligence. Es miembro fundador de la Asociación de Sistemas de Información de América Latina y el Caribe.

ace unos días me encontraba en la sala de espera para abordar el avión que me llevaría de vacaciones al norte del país. Como ya acostumbro, envié un mensaje de texto a mi hermano para avisar que el vuelo saldría a tiempo y podría pasar por mí a la hora acordada. Y antes de que la azafata anunciara que los teléfonos celulares debían ser apagados, envié un mensaje intrascendente para despedirme de una amiga. La confirmación de mi hermano y el mensaje de buen viaje de mi amiga llegaron antes de que finalmente apagara el teléfono. Ya en mi destino, un mensaje de mi jefe me hizo consultar mi correo electrónico en mi computadora portátil para resolver un asunto de último minuto en el trabajo. Durante mis vacaciones mi jefe enviaría un mensaje más para verificar que el pendiente quedara solucionado, mi amiga insistiría en más de una ocasión en enviar un mensaje matutino para saber si ya estaba despierto, y utilizaría el programa de chat en mi computadora de mano para decidir junto con mi hermano la mejor opción para cenar. Lo anterior es quizá sólo un pequeño ejemplo de la manera en que los dispositivos móviles se han integrado en nuestras vidas, proporcionando información inmediata y facilitando transacciones comerciales. Los bancos envían mensajes al celular cuando hay un movimiento poco usual en las cuentas, en Europa el envío de publicidad a celulares (con opción de compra inmediata del producto) se está convirtiendo en la nueva modalidad del correo no deseado, los centros comerciales permiten cargar el mapa del lugar y ofertas en las computadoras de mano, y la relativa facilidad para el intercambio de multimedios, información y datos entre dispositivos permite su integración aumentando la productividad o desempeño de los mismos. Si vivíamos en una era de información, ahora la vemos potenciada por la facilidad con que la información nos llega literalmente a las manos. Y nuestra sociedad está, lenta pero definitivamente, adoptando este flujo de información. El impacto social aún está por definirse. No estoy seguro de querer ser tan fácilmente localizable por mi jefe en vacaciones.

SEP-OCT 2005

Recuerdo una época en que mis compañeros de trabajo podían sobrevivir sin mí. Por otro lado, debo reconocer que los relativamente poco intrusivos mensajes nos han ahorrado problemas mayores o han facilitado las actividades del trabajo. Quizá puedo vivir sin las ofertas del centro comercial en mi palm, pero considero muy valioso poder modificar mi agenda, cambiar mis citas y localizar un restaurante cuando mi vuelo se ha retrasado. Pero es un hecho que con el desarrollo constante de las tecnologías móviles, la tendencia al uso de información localizada sólo puede aumentar. Estas son buenas noticias para los desarrolladores de software, pues pueden explotar el mercado de aplicaciones para dispositivos móviles. Como las aplicaciones web (webapps), las aplicaciones móviles (m-applications) tienen un ciclo de desarrollo ágil y restricciones de uso de recursos y seguridad que deben plantear un atractivo reto para los lectores de esta revista. Ya empresas como Microsoft y PalmOne buscan fomentar la capacitación de programadores para tecnologías móviles, por medio de concursos estudiantiles y programas de capacitación. Los desarrolladores de software seremos parte entonces de esta sobrecarga de información. Es un buen momento para ser desarrollador. Lo que hagamos con la información generada dependerá de nuestra sociedad. Por lo pronto, le he dicho a mi amiga que no necesita despertarme con un mensaje de texto... y que de vez en cuando una llamada por teléfono es bien recibida. -Raúl A. Trejo www.softwareguru.com.mx

INDEX

DIRECTORIO

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

www.softwareguru.com.mx

Anunciante

Pรกginas

Sitio

AMITI AMCIS ARTech Avantare SEPG LA e-Quallity Gopac Grupo STI IBM IDC Imexsoft Itera MGE Microsoft Milestone Roca Sistemas Ssistemas Vision Consulting Vision Training

09 55 17 39 07 47 27 29 F4 F3 13 11 53 F2-1 45 31 25 35 35

www.amiti.org.mx www.amcis.org.mx www.artech-mexico.com www.avantare.com www.esi.es/SEPGLA www.e-quallity.net www.gopac.com.mx www.gsti.com.mx www.ibm.com/mx www.idc-eventos.com www.imexsoft.com.mx www.itera.com.mx www.mgeups.com www.microsoft.com/mexico www.milestone.com.mx www.rocasistemas.com.mx www.ssistemas.com www.visionconsulting.com.mx www.visiontraining.com.mx

SEP-OCT 2005

CARRERA

Certiﬁcación de Habilidades Cinco Pasos Hacia el Éxito

a certificación es una excelente oportunidad para desarrollarte profesionalmente y lograr una mejor posición. Para maximizar las oportunidades de éxito, te recomendamos seguir los siguientes cinco pasos:

1. Escoger un Plan de Carrera Escoger un plan de carrera no es algo tan complicado como parece. Por un lado, explora tus intereses y habilidades, y piensa qué temas son los que más te atraen. Por otro lado, investiga las tendencias tecnológicas con mayor proyección. Al balancear lo que te interesa con lo que las empresas buscan, obtendrás más y mejores oportunidades de crecimiento. Algunas de las preguntas que te debes hacer son: ¿qué logros me han dado mayor satisfacción en mi carrera? ¿En qué áreas necesito desarrollarme más? ¿Qué pretendo lograr en los siguientes años? El objetivo de este análisis es identificar una carrera que coincida tus habilidades, intereses, objetivos, y oportunidades. Las revistas especializadas (como SG) son una excelente opción para estar al tanto de las tendencias y necesidades en la industria. Los eventos y conferencias también son una buena forma de convivir con otros profesionistas y colegas que pueden compartir su experiencia y opinión. Una vez que decides una carrera y te comprometes con ella, el resto del proceso de preparación es sencillo.

2. Selecciona Material de Aprendizaje Existe una gran variedad de opciones para aprender lo que necesitas para una certificación, desde libros y material en línea, hasta clases presenciales. Entre los factores a tomar en cuenta para escoger el modelo de aprendizaje adecuado para ti, está tu habilidad, nivel de motivación, presupuesto, y tiempo disponible.

SEP-OCT 2005

En caso de ser posible, toma un examen de pre-evaluación. Con esto, conocerás tu nivel actual, y podrás decidir en qué áreas puedes dedicar más tiempo y recursos para desarrollarte, a diferencia de en cuales solamente necesitas repasar. Analiza cuanto tiempo tienes disponible para estudiar. Los expertos recomiendan sesiones de 45 a 60 minutos. Haz un plan con metas y fechas, para que te sea más fácil dar seguimiento a tu entrenamiento y mantenerte motivado. Algunos expertos recomiendan planearse para terminar de estudiar cualquier material nuevo con cuatro días de anticipación al examen. Esto te dará tres días para revisar todo, y el día anterior para relajarte.

3. La Práctica hace al Maestro Una vez que has terminado con el aprendizaje, estás listo para tomar exámenes de práctica. Mientras practicas, acostúmbrate a no perderte en las preguntas difíciles o enredadas. Si sientes que estás perdiendo mucho tiempo en alguna, sáltatela. Es preferible saltarse unas pocas preguntas, y concentrarse en aquellas cuya respuesta conoces, a no poder completar el examen por dedicar demasiado tiempo a las preguntas complejas. Mide tu tiempo mientras realizas los exámenes de práctica. Esto te acostumbrará a pensar de manera rápida y eficiente, además de simular la experiencia del examen real.

4. Preparación para el Día del Examen La ansiedad previa al examen es bastante común. La mayoría de la gente siente mariposas en el estomago antes de cualquier examen

importante. Un poco de ansiedad es buena, ya que estimulará tus sentidos y te ayudará a concentrarte. Sin embargo, demasiada ansiedad puede interferir con tu habilidad para enfocarte y contestar correctamente. Una buena herramienta para reducir la ansiedad, es imaginar lo que sucederá el día del examen. Haz una lista de todo lo que necesitarás. Prepara los materiales e identificación. Planéate para llegar 15 minutos antes de tu examen. A algunas personas les ayuda realizar ejercicios de relajamiento previo al examen. Esto puede ser algo tan sencillo como sentarte en una silla, cerrar los ojos, y contar despacio hasta 5 mientras respiras lentamente.

5. Nunca Dejes de Aprender Si realizaste un examen por computadora, al terminarlo aparecerán los resultados en la pantalla. Probablemente también recibas una copia impresa. Esto sirve de comprobante en lo que recibes el reporte completo por correo. Si llevaste a cabo estos pasos correctamente, seguramente aprobaste tu examen y obtuviste tu certificación. ¡Felicidades! Ya te puedes vender mejor con tu empleador actual, o con otros. Sin embargo, recuerda que la industria de TI requiere estar en aprendizaje continuo. Así que siempre debes mantenerte actualizado. Aquellos que se duermen en sus laureles, pronto quedan obsoletos. Contar con la dedicación necesaria para un aprendizaje continuo no sólo te ayudará a asegurar tu trabajo, sino que también te abrirá las puertas a nuevas oportunidades. www.softwareguru.com.mx

Aﾃｱo 01 No. 05

www.softwareguru.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Septiembre-Octubre2005